diff --git a/.editorconfig b/.editorconfig
index e49c89c4e8..bc1dfe40c8 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -5,6 +5,9 @@ charset = utf-8
 max_line_length = 80
 trim_trailing_whitespace = true
 
+[*.md]
+trim_trailing_whitespace = false
+
 [*.{css,html,js,json,sass,md,mmark,toml,yaml}]
 indent_style = space
 indent_size = 2
diff --git a/.github/ISSUE_TEMPLATE/support.md b/.github/ISSUE_TEMPLATE/support.md
index 0363c0837d..fd223c8991 100644
--- a/.github/ISSUE_TEMPLATE/support.md
+++ b/.github/ISSUE_TEMPLATE/support.md
@@ -2,7 +2,7 @@
 name: Support Request
 about: Support request or question relating to Kubernetes Website project
 labels:
-- triage/support
+- kind/support
 ---
 **This is Support**
 
diff --git a/.github/OWNERS b/.github/OWNERS
new file mode 100644
index 0000000000..594352be83
--- /dev/null
+++ b/.github/OWNERS
@@ -0,0 +1,7 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+reviewers:
+- sig-docs-en-reviews # Defined in OWNERS_ALIASES
+
+approvers:
+- sig-docs-en-owners # Defined in OWNERS_ALIASES
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 795b340ba3..785257142d 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -14,9 +14,11 @@
  Use the default base branch, “master”, if you're documenting existing
  features in the English localization.
 
- If you're working on a different localization (not English), or you
- are documenting a feature that will be part of a future release, see
+ If you're working on a different localization (not English), see
  https://kubernetes.io/docs/contribute/new-content/overview/#choose-which-git-branch-to-use
  for advice.
 
+ If you're documenting a feature that will be part of a future release, see
+ https://kubernetes.io/docs/contribute/new-content/new-features/ for advice.
+
 -->
diff --git a/.github/workflows/OWNERS b/.github/workflows/OWNERS
new file mode 100644
index 0000000000..404875fc2e
--- /dev/null
+++ b/.github/workflows/OWNERS
@@ -0,0 +1,11 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+# When modifying this file, consider the security implications of
+# allowing listed reviewers / approvals to modify or remove any
+# configured GitHub Actions.
+
+reviewers:
+- sig-docs-leads
+
+approvers:
+- sig-docs-leads
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d5f2c4ce05..e14c07a89c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -18,7 +18,7 @@ The [Kubernetes SIG Docs Discussion Group](https://groups.google.com/forum/#!for
 
 ### Style Guides and Templates
 
-Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/home/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/home/contribute/page-templates/).
+Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/home/contribute/style-guide/) and follow the [instructions for using page templates](https://kubernetes.io/docs/contribute/style/page-content-types/).
 
 
 ## Contributing to Documentation
@@ -35,3 +35,5 @@ Note that code issues should be filed against the main kubernetes repository, wh
 ### Submitting Documentation Pull Requests
 
 If you're fixing an issue in the existing documentation, you should submit a PR against the master branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
+
+For more information, see [contributing to Kubernetes docs](https://kubernetes.io/docs/contribute/).
diff --git a/Dockerfile b/Dockerfile
index 3e3335076c..e168c3e6dc 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -16,7 +16,7 @@ RUN apk add --no-cache \
     build-base \
     libc6-compat \
     npm && \
-    npm install -G autoprefixer postcss-cli
+    npm install -D autoprefixer postcss-cli
 
 ARG HUGO_VERSION
 
@@ -29,4 +29,6 @@ RUN mkdir -p /usr/local/src && \
 
 WORKDIR /src
 
+USER hugo:hugo
+
 EXPOSE 1313
diff --git a/Makefile b/Makefile
index 56ec8410f4..58babc3627 100644
--- a/Makefile
+++ b/Makefile
@@ -65,10 +65,10 @@ container-image:
 		--build-arg HUGO_VERSION=$(HUGO_VERSION)
 
 container-build: module-check
-	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --minify
+	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify"
 
 container-serve: module-check
-	$(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0
+	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
 
 test-examples:
 	scripts/test_examples.sh install
diff --git a/OWNERS b/OWNERS
index 3dd8f337ba..f352793ec1 100644
--- a/OWNERS
+++ b/OWNERS
@@ -7,10 +7,11 @@ approvers:
 - sig-docs-en-owners # Defined in OWNERS_ALIASES
 
 emeritus_approvers:
-# chenopis, you're welcome to return when you're ready to resume PR wrangling
-# jaredbhatti, you're welcome to return when you're ready to resume PR wrangling
-# stewart-yu, you're welcome to return when you're ready to resume PR wrangling
+# - chenopis, commented out to disable PR assignments
+# - jaredbhatti, commented out to disable PR assignments
+# - steveperry-53, commented out to disable PR assignments
 - stewart-yu 
+- zacharysarah
 
 labels:
 - sig/docs
diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index c39698ba81..eea832a762 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -22,18 +22,18 @@ aliases:
     - mkorbi
     - rlenferink
   sig-docs-en-owners: # Admins for English content
+    - annajung
     - bradtopol
     - celestehorgan
+    - irvifa
     - jimangel
     - kbarnard10
     - kbhawkey
-    - makoscafee
     - onlydole
     - savitharaghunathan
     - sftim
     - steveperry-53
     - tengqm
-    - xiangpengzhao
     - zacharysarah
     - zparnold
   sig-docs-en-reviews: # PR reviews for English content
@@ -43,14 +43,11 @@ aliases:
     - jimangel
     - kbarnard10
     - kbhawkey
-    - makoscafee
     - onlydole
     - rajeshdeshpande02
     - sftim
     - steveperry-53
     - tengqm
-    - xiangpengzhao
-    - zacharysarah
     - zparnold
   sig-docs-es-owners: # Admins for Spanish content
     - raelga
@@ -123,17 +120,17 @@ aliases:
     - bells17
     # cstoku
     - inductor
+    - kakts
     - makocchi-git
     # MasayaAoyama
     - nasa9084
-    - oke-py
+    # oke-py
   sig-docs-ko-owners: # Admins for Korean content
     - ClaudiaJKang
     - gochist
     - ianychoi
     - seokho-son
     - ysyukr
-    - zacharysarah
   sig-docs-ko-reviews: # PR reviews for Korean content
     - ClaudiaJKang
     - gochist
@@ -142,35 +139,34 @@ aliases:
     - ysyukr
     - pjhwa
   sig-docs-leads: # Website chairs and tech leads
+    - irvifa
     - jimangel
     - kbarnard10
     - kbhawkey
     - onlydole
     - sftim
-    - zacharysarah
   sig-docs-zh-owners: # Admins for Chinese content
-    - chenopis
+    # chenopis
     - chenrui333
-    - dchen1107
-    - haibinxie
-    - hanjiayao
-    - lichuqiang
-    - SataQiu
-    - tengqm
-    - xiangpengzhao
-    - xichengliudui
-    - zacharysarah
-    - zhangxiaoyu-zidif
-  sig-docs-zh-reviews: # PR reviews for Chinese content
-    - chenrui333
-    - idealhack
+    # dchen1107
+    # haibinxie
+    # hanjiayao
+    # lichuqiang
     - SataQiu
     - tanjunchen
     - tengqm
-    - xiangpengzhao
     - xichengliudui
-    - zhangxiaoyu-zidif
+    # zhangxiaoyu-zidif
+  sig-docs-zh-reviews: # PR reviews for Chinese content
+    - chenrui333
+    - howieyuen
+    - idealhack
     - pigletfly
+    - SataQiu
+    - tanjunchen
+    - tengqm
+    - xichengliudui
+    # zhangxiaoyu-zidif
   sig-docs-pt-owners: # Admins for Portuguese content
     - femrtnz
     - jcjesus
diff --git a/README-de.md b/README-de.md
index bf647d828f..9efc1fb597 100644
--- a/README-de.md
+++ b/README-de.md
@@ -40,13 +40,13 @@ Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein speziel
 Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstellen Sie das Docker-Image `kubernetes-hugo` lokal:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Nachdem das Image erstellt wurde, können Sie die Site lokal ausführen:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
diff --git a/README-es.md b/README-es.md
index ba2f13a80f..cc4a6cefa0 100644
--- a/README-es.md
+++ b/README-es.md
@@ -33,13 +33,13 @@ El método recomendado para levantar una copia local del sitio web kubernetes.io
 Una vez tenga Docker [configurado en su máquina](https://www.docker.com/get-started), puede construir la imagen de Docker `kubernetes-hugo` localmente ejecutando el siguiente comando en la raíz del repositorio:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Una vez tenga la imagen construida, puede levantar el sitio web ejecutando:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Abra su navegador y visite http://localhost:1313 para acceder a su copia local del sitio. A medida que vaya haciendo cambios en el código fuente, Hugo irá actualizando la página y forzará la actualización en el navegador.
diff --git a/README-fr.md b/README-fr.md
index b493ea60f0..c5cf5de786 100644
--- a/README-fr.md
+++ b/README-fr.md
@@ -16,13 +16,13 @@ Faites tous les changements que vous voulez dans votre fork, et quand vous êtes
 Une fois votre pull request créée, un examinateur de Kubernetes se chargera de vous fournir une revue claire et exploitable.
 En tant que propriétaire de la pull request, **il est de votre responsabilité de modifier votre pull request pour tenir compte des commentaires qui vous ont été fournis par l'examinateur de Kubernetes.**
 Notez également que vous pourriez vous retrouver avec plus d'un examinateur de Kubernetes pour vous fournir des commentaires ou vous pourriez finir par recevoir des commentaires d'un autre examinateur que celui qui vous a été initialement affecté pour vous fournir ces commentaires.
-De plus, dans certains cas, l'un de vos examinateur peut demander un examen technique à un [examinateur technique de Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) au besoin.
+De plus, dans certains cas, l'un de vos examinateurs peut demander un examen technique à un [examinateur technique de Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) au besoin.
 Les examinateurs feront de leur mieux pour fournir une revue rapidement, mais le temps de réponse peut varier selon les circonstances.
 
 Pour plus d'informations sur la contribution à la documentation Kubernetes, voir :
 
 * [Commencez à contribuer](https://kubernetes.io/docs/contribute/start/)
-* [Apperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Aperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
 * [Utilisation des modèles de page](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Traduction de la documentation Kubernetes](https://kubernetes.io/docs/contribute/localization/)
@@ -38,13 +38,13 @@ La façon recommandée d'exécuter le site web Kubernetes localement est d'utili
 Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Une fois l'image construite, vous pouvez exécuter le site localement :
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Ouvrez votre navigateur à l'adresse: http://localhost:1313 pour voir le site.
diff --git a/README-hi.md b/README-hi.md
index e572cfc738..01d119a22b 100644
--- a/README-hi.md
+++ b/README-hi.md
@@ -17,7 +17,7 @@
 
 * [योगदान देना शुरू करें](https://kubernetes.io/docs/contribute/start/)
 * [परिवर्तनों को अंतिम चरण में लेजाएं](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [पेज टेम्पलेट](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [पेज टेम्पलेट](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [प्रलेखन शैली गाइड](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [स्थानीयकरण कुबरनेट्स प्रलेखन](https://kubernetes.io/docs/contribute/localization/)
 
@@ -41,13 +41,13 @@
 यदि आप [डॉकर](https://www.docker.com/get-started) चला रहे हैं, तो स्थानीय रूप से `कुबेरनेट्स-ह्यूगो` Docker image बनाएँ:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 एक बार image बन जाने के बाद, आप साइट को स्थानीय रूप से चला सकते हैं:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 साइट देखने के लिए अपने browser को `http://localhost:1313` पर खोलें। जैसा कि आप source फ़ाइलों में परिवर्तन करते हैं, Hugo साइट को अपडेट करता है और browser को refresh करने पर मजबूर करता है।
@@ -81,4 +81,4 @@ make serve
 
 कुबरनेट्स सामुदायिक भागीदारी पर पनपती है, और हम वास्तव में हमारी साइट और हमारे प्रलेखन में आपके योगदान की सराहना करते हैं!
 
-कुबरनेट्स आपकी भागीदारी पर निर्भर है, और हम हमारी साइट और प्रलेखन में आपके योगदान का मान करते हैं!
\ No newline at end of file
+कुबरनेट्स आपकी भागीदारी पर निर्भर है, और हम हमारी साइट और प्रलेखन में आपके योगदान का मान करते हैं!
diff --git a/README-id.md b/README-id.md
index 1d6b830f2e..992adf7ed5 100644
--- a/README-id.md
+++ b/README-id.md
@@ -15,7 +15,7 @@ Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat
 
 * [Petunjuk Melakukan Kontribusi](https://kubernetes.io/docs/contribute/start/)
 * [Melakukan Tahap Staging pada Konten Dokumentasi yang telah Kamu Sediakan](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Petunjuk Menggunakan Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Petunjuk Menggunakan Page Templates](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Petunjuk untuk Documentation Style](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Petunjuk untuk Melakukan Lokalisasi Dokumentasi Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
@@ -30,13 +30,13 @@ Petunjuk yang disarankan untuk menjalankan Dokumentasi Kubernetes pada mesin lok
 Jika kamu sudah memiliki **Docker** [yang sudah dapat digunakan](https://www.docker.com/get-started), kamu dapat melakukan **build** `kubernetes-hugo` **Docker image** secara lokal:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Setelah **image** berhasil di-**build**, kamu dapat menjalankan website tersebut pada mesin lokal-mu:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi. Selama kamu melakukan penambahan konten, **Hugo** akan secara otomatis melakukan perubahan terhadap laman dokumentasi apabila **browser** melakukan proses **refresh**.
diff --git a/README-it.md b/README-it.md
index 5530a673e5..dea728cba5 100644
--- a/README-it.md
+++ b/README-it.md
@@ -15,7 +15,7 @@ Per maggiori informazioni su come contribuire alla documentazione Kubernetes, ve
 
 * [Cominciare a contribuire](https://kubernetes.io/docs/contribute/start/)
 * [Vedere le modifiche localmente](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Utilizzare i template delle pagine](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Utilizzare i template delle pagine](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Guida Stilistica per la documentazione di Kubernetes](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Tradurre la documentazione di Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
@@ -30,13 +30,13 @@ Il modo consigliato per eseguire localmente il sito Web Kubernetes prevede l'uti
 Se hai Docker [attivo e funzionante](https://www.docker.com/get-started), crea l'immagine Docker `kubernetes-hugo` localmente:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Dopo aver creato l'immagine, è possibile eseguire il sito Web localmente:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Apri il tuo browser su http://localhost:1313 per visualizzare il sito Web. Mentre modifichi i file sorgenti, Hugo aggiorna automaticamente il sito Web e forza un aggiornamento della pagina visualizzata nel browser.
diff --git a/README-ja.md b/README-ja.md
index 8fab3900c8..49d0dd1bad 100644
--- a/README-ja.md
+++ b/README-ja.md
@@ -4,34 +4,100 @@
 
 このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！
 
-## Hugoを使ってローカル環境でWebサイトを動かす
+# リポジトリの使い方
 
-Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
+Hugo(Extended version)を使用してWebサイトをローカルで実行することも、コンテナランタイムで実行することもできます。コンテナランタイムを使用することを強くお勧めします。これにより、本番Webサイトとのデプロイメントの一貫性が得られます。
 
-Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
+## 前提条件
 
-```bash
+このリポジトリを使用するには、以下をローカルにインストールする必要があります。
+
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo(Extended version)](https://gohugo.io/)
+- [Docker](https://www.docker.com/)などのコンテナランタイム
+
+開始する前に、依存関係をインストールしてください。リポジトリのクローンを作成し、ディレクトリに移動します。
+
+```
 git clone https://github.com/kubernetes/website.git
 cd website
+```
+
+KubernetesのWebサイトではDocsyというHugoテーマを使用しています。コンテナでWebサイトを実行する場合でも、以下を実行して、サブモジュールおよびその他の開発依存関係をプルすることを強くお勧めします。
+
+```
+# pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
 
-**注意:** Kubernetesのウェブサイトでは[DocsyというHugoのテーマ](https://github.com/google/docsy#readme)を使用しています。リポジトリを更新していない場合、 `website/themes/docsy`ディレクトリは空です。 このサイトはテーマのローカルコピーなしでは構築できません。
+## コンテナを使ってウェブサイトを動かす
 
-テーマをアップデートするには以下のコマンドを実行します:
+コンテナ内でサイトを構築するには、以下を実行してコンテナイメージを構築し、実行します。
 
-```bash
-git submodule update --init --recursive --depth 1
+```
+make container-image
+make container-serve
 ```
 
-サイトをローカルでビルドしてテストするには以下のコマンドを実行します:
+お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
+
+## Hugoを使ってローカル環境でWebサイトを動かす
+
+[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じExtended versionのHugoをインストールするようにしてください。
+
+ローカルでサイトを構築してテストするには、次のコマンドを実行します。
 
 ```bash
-hugo server --buildFuture
+# install dependencies
+npm ci
+make serve
 ```
 
 これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
 
+## トラブルシューティング
+
+### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
+
+Hugoは、技術的な理由から2種類のバイナリがリリースされています。現在のウェブサイトは**Hugo Extended**バージョンのみに基づいて運営されています。[リリースページ](https://github.com/gohugoio/hugo/releases)で名前に「extended」が含まれるアーカイブを探します。確認するには、`hugo version`を実行し、「extended」という単語を探します。
+
+### macOSにてtoo many open filesというエラーが表示される
+
+macOS上で`make serve`を実行した際に以下のエラーが表示される場合
+
+```
+ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
+make: *** [serve] Error 1
+```
+
+OS上で同時に開けるファイルの上限を確認してください。
+
+`launchctl limit maxfiles`
+
+続いて、以下のコマンドを実行します(https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c より引用)。
+
+```
+#!/bin/sh
+
+# These are the original gist links, linking to my gists now.
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
+
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist
+
+sudo mv limit.maxfiles.plist /Library/LaunchDaemons
+sudo mv limit.maxproc.plist /Library/LaunchDaemons
+
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
+
+sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+こちらはmacOSのCatalinaとMojaveで動作を確認しています。
+
 ## SIG Docsに参加する
 
 [コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。
diff --git a/README-ko.md b/README-ko.md
index f0b13168e3..e23027c32a 100644
--- a/README-ko.md
+++ b/README-ko.md
@@ -15,7 +15,7 @@
 
 * [기여 시작하기](https://kubernetes.io/docs/contribute/start/)
 * [문서화 변경 사항 스테이징하기](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [페이지 템플릿 사용하기](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [페이지 템플릿 사용하기](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [쿠버네티스 문서화 로컬라이징](https://kubernetes.io/docs/contribute/localization/)
 
@@ -41,13 +41,13 @@
 도커 [동작 및 실행](https://www.docker.com/get-started) 환경이 있는 경우, 로컬에서 `kubernetes-hugo` 도커 이미지를 빌드 합니다:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 해당 이미지가 빌드 된 이후, 사이트를 로컬에서 실행할 수 있습니다:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
diff --git a/README-pl.md b/README-pl.md
index f8bffdb0b2..7d89d518cb 100644
--- a/README-pl.md
+++ b/README-pl.md
@@ -17,7 +17,7 @@ Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz
 
 * [Jak rozpocząć współpracę](https://kubernetes.io/docs/contribute/start/)
 * [Podgląd wprowadzanych zmian w dokumentacji](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Szablony stron](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Szablony stron](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
@@ -49,13 +49,13 @@ choco install make
 Jeśli [zainstalowałeś i uruchomiłeś](https://www.docker.com/get-started) już Dockera, zbuduj obraz `kubernetes-hugo` lokalnie:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Po zbudowaniu obrazu, możesz uruchomić serwis lokalnie:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
diff --git a/README-pt.md b/README-pt.md
index 8ce121a792..3154b77bab 100644
--- a/README-pt.md
+++ b/README-pt.md
@@ -35,13 +35,13 @@ A maneira recomendada de executar o site do Kubernetes localmente é executar um
 Se você tiver o Docker [em funcionamento](https://www.docker.com/get-started), crie a imagem do Docker do `kubernetes-hugo` localmente:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Depois que a imagem foi criada, você pode executar o site localmente:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Abra seu navegador para http://localhost:1313 para visualizar o site. Conforme você faz alterações nos arquivos de origem, Hugo atualiza o site e força a atualização do navegador.
diff --git a/README-ru.md b/README-ru.md
index bb290654a8..d999e1cc88 100644
--- a/README-ru.md
+++ b/README-ru.md
@@ -38,8 +38,8 @@ hugo server --buildFuture
 Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
 
 * [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/)
-* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/)
-* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Использование шаблонов страниц](https://kubernetes.io/docs/contribute/style/page-content-types/)
+* [Руководство по оформлению документации](https://kubernetes.io/docs/contribute/style/style-guide/)
 * [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
 ## Файл `README.md` на других языках
diff --git a/README-vi.md b/README-vi.md
index b06b6df368..cd89b74725 100644
--- a/README-vi.md
+++ b/README-vi.md
@@ -15,7 +15,7 @@ Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách n
 
 * [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/)
 * [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Sử dụng các trang templates](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Hướng dẫn biểu mẫu tài liệu](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
@@ -31,13 +31,13 @@ Cách được đề xuất để chạy trang web Kubernetes cục bộ là dù
 Nếu bạn có Docker đang [up và running](https://www.docker.com/get-started), build `kubernetes-hugo` Docker image cục bộ:
 
 ```bash
-make docker-image
+make container-image
 ```
 
 Khi image đã được built, bạn có thể chạy website cục bộ:
 
 ```bash
-make docker-serve
+make container-serve
 ```
 
 Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
diff --git a/README-zh.md b/README-zh.md
index 5b4353127f..a1532f37a3 100644
--- a/README-zh.md
+++ b/README-zh.md
@@ -13,52 +13,94 @@ This repository contains the assets required to build the [Kubernetes website an
 我们非常高兴您想要参与贡献！
 
 <!--
-## Running the website locally using Hugo
+# Using this repository
 
-See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file.
+You can run the website locally using Hugo (Extended version), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.
 -->
-## 在本地使用 Hugo 来运行网站
+## 使用这个仓库
 
-请参考 [Hugo 的官方文档](https://gohugo.io/getting-started/installing/)了解 Hugo 的安装指令。
-请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的
-Hugo 扩展版本。
+可以使用 Hugo（扩展版）在本地运行网站，也可以在容器中运行它。强烈建议使用容器，因为这样可以和在线网站的部署保持一致。
 
 <!--
-Before building the site, clone the Kubernetes website repository:
--->
-在构造网站之前，先克隆 Kubernetes website 仓库：
+## Prerequisites
 
-```bash
+To use this repository, you need the following installed locally:
+
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo (Extended version)](https://gohugo.io/)
+- A container runtime, like [Docker](https://www.docker.com/).
+
+-->
+## 前提条件
+
+使用这个仓库，需要在本地安装以下软件：
+
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo (Extended version)](https://gohugo.io/)
+- 容器运行时，比如 [Docker](https://www.docker.com/).
+
+<!--
+Before you start, install the dependencies. Clone the repository and navigate to the directory:
+-->
+开始前，先安装这些依赖。克隆本仓库并进入对应目录：
+
+```
 git clone https://github.com/kubernetes/website.git
 cd website
-git submodule update --init --recursive
 ```
 
 <!--
-**Note:**  The Kubernetes website deploys the [Docsy Hugo theme](https://github.com/google/docsy#readme).
-If you have not updated your website repository, the `website/themes/docsy` directory is empty.
-The site cannot build without a local copy of the theme.
-
-Update the website theme:
+The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
 -->
-**注意：** Kubernetes 网站要部署 [Docsy Hugo 主题](https://github.com/google/docsy#readme).
-如果你还没有更新你本地的 website 仓库，目录 `website/themes/docsy`
-会是空目录。
-在本地没有主题副本的情况下，网站无法正常构造。
 
-使用下面的命令更新网站主题：
+Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项：
 
-```bash
+```
+# pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
 
 <!--
+## Running the website using a container
+
+To build the site in a container, run the following to build the container image and run it:
+
+-->
+## 在容器中运行网站
+
+要在容器中构建网站，请通过以下命令来构建容器镜像并运行：
+
+```
+make container-image
+make container-serve
+```
+
+<!--
+Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+-->
+启动浏览器，打开 http://localhost:1313 来查看网站。
+当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。
+
+<!--
+## Running the website locally using Hugo
+
+Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file.
+
 To build and test the site locally, run:
 -->
+## 在本地使用 Hugo 来运行网站
+
+请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的
+Hugo 扩展版本。
+
 若要在本地构造和测试网站，请运行：
 
 ```bash
-hugo server --buildFuture
+# install dependencies
+npm ci
+make serve
 ```
 
 <!--
@@ -68,6 +110,63 @@ This will start the local Hugo server on port 1313. Open up your browser to http
 启动浏览器，打开 http://localhost:1313 来查看网站。
 当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。
 
+<!--
+## Troubleshooting
+### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
+
+Hugo is shipped in two set of binaries for technical reasons. The current website runs based on the **Hugo Extended** version only. In the [release page](https://github.com/gohugoio/hugo/releases) look for archives with `extended` in the name. To confirm, run `hugo version` and look for the word `extended`.
+
+-->
+## 故障排除
+
+###  error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
+
+由于技术原因，Hugo 会发布两套二进制文件。
+当前网站仅基于 **Hugo Extended** 版本运行。
+在 [发布页面](https://github.com/gohugoio/hugo/releases) 中查找名称为 `extended` 的归档。可以运行 `huge version` 查看是否有单词 `extended` 来确认。
+
+<!--
+### Troubleshooting macOS for too many open files
+
+If you run `make serve` on macOS and receive the following error:
+
+-->
+### 对 macOs 上打开太多文件的故障排除
+
+如果在 macOS 上运行 `make serve` 收到以下错误：
+
+```
+ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
+make: *** [serve] Error 1
+```
+
+试着查看一下当前打开文件数的限制：
+
+`launchctl limit maxfiles`
+
+然后运行以下命令（参考https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c）：
+
+```
+#!/bin/sh
+
+# These are the original gist links, linking to my gists now.
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
+
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist
+
+sudo mv limit.maxfiles.plist /Library/LaunchDaemons
+sudo mv limit.maxproc.plist /Library/LaunchDaemons
+
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
+
+sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+这适用于 Catalina 和 Mojave macOS。
+
 <!--
 ## Get involved with SIG Docs
 
@@ -78,7 +177,7 @@ You can also reach the maintainers of this project at:
 - [Slack](https://kubernetes.slack.com/messages/sig-docs)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 -->
-## 参与 SIG Docs 工作
+# 参与 SIG Docs 工作
 
 通过 [社区页面](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)
 进一步了解 SIG Docs Kubernetes 社区和会议信息。
@@ -95,7 +194,7 @@ You can click the **Fork** button in the upper-right area of the screen to creat
 
 Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.  As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
 -->
-## 为文档做贡献
+# 为文档做贡献
 
 你也可以点击屏幕右上方区域的 **Fork** 按钮，在你自己的 GitHub
 账号下创建本仓库的拷贝。此拷贝被称作 *fork*。
@@ -133,7 +232,7 @@ For more information about contributing to the Kubernetes documentation, see:
 * [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
 
-## 中文本地化
+# 中文本地化
 
 可以通过以下方式联系中文本地化的维护人员：
 
@@ -146,15 +245,15 @@ For more information about contributing to the Kubernetes documentation, see:
 
 Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
 -->
-### 行为准则
+# 行为准则
 
-参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)约束。
+参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 约束。
 
 <!--
 ## Thank you!
 
 Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
 -->
-## 感谢！
+# 感谢！
 
 Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！
diff --git a/README.md b/README.md
index 9ff0c14e53..c19aae489c 100644
--- a/README.md
+++ b/README.md
@@ -6,16 +6,15 @@ This repository contains the assets required to build the [Kubernetes website an
 
 # Using this repository
 
-You can run the website locally using Hugo, or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.
+You can run the website locally using Hugo (Extended version), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.
 
 ## Prerequisites
 
 To use this repository, you need the following installed locally:
 
-- [yarn](https://yarnpkg.com/)
 - [npm](https://www.npmjs.com/)
 - [Go](https://golang.org/)
-- [Hugo](https://gohugo.io/)
+- [Hugo (Extended version)](https://gohugo.io/)
 - A container runtime, like [Docker](https://www.docker.com/).
 
 Before you start, install the dependencies. Clone the repository and navigate to the directory:
@@ -28,9 +27,6 @@ cd website
 The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
 
 ```
-# install dependencies
-yarn
-
 # pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
@@ -53,11 +49,18 @@ Make sure to install the Hugo extended version specified by the `HUGO_VERSION` e
 To build and test the site locally, run:
 
 ```bash
+# install dependencies
+npm ci
 make serve
 ```
 
 This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
 
+## Troubleshooting
+### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
+
+Hugo is shipped in two set of binaries for technical reasons. The current website runs based on the **Hugo Extended** version only. In the [release page](https://github.com/gohugoio/hugo/releases) look for archives with `extended` in the name. To confirm, run `hugo version` and look for the word `extended`.
+
 ### Troubleshooting macOS for too many open files
 
 If you run `make serve` on macOS and receive the following error:
@@ -71,7 +74,7 @@ Try checking the current limit for open files:
 
 `launchctl limit maxfiles`
 
-Then run the following commands:
+Then run the following commands (adapted from https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c):
 
 ```
 #!/bin/sh
@@ -101,7 +104,7 @@ Learn more about SIG Docs Kubernetes community and meetings on the [community pa
 
 You can also reach the maintainers of this project at:
 
-- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
 # Contributing to the docs
diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS
index c87673847c..5b0cc85b45 100644
--- a/SECURITY_CONTACTS
+++ b/SECURITY_CONTACTS
@@ -10,6 +10,7 @@
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
+irvifa
 jimangel
 kbarnard10
-zacharysarah
+sftim
\ No newline at end of file
diff --git a/assets/js/search.js b/assets/js/search.js
index 3d6e9d9447..40e1797d5a 100644
--- a/assets/js/search.js
+++ b/assets/js/search.js
@@ -17,14 +17,22 @@ limitations under the License.
   var Search = {
     init: function () {
       $(document).ready(function () {
+        // Fill the search input form with the current search keywords
+        const searchKeywords = new URLSearchParams(location.search).get('q');
+        if (searchKeywords !== null && searchKeywords !== '') {
+          const searchInput = document.querySelector('.td-search-input');
+          searchInput.focus();
+          searchInput.value = searchKeywords;
+        }
+
+        // Set a keydown event
         $(document).on("keypress", ".td-search-input", function (e) {
           if (e.keyCode !== 13) {
             return;
           }
 
           var query = $(this).val();
-          var searchPage = "{{ "docs/search/" | absURL }}?q=" + query;
-          document.location = searchPage;
+          document.location = "{{ "search/" | absURL }}?q=" + query;
 
           return false;
         });
diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss
index 4b9125bcd9..1bf749b67a 100644
--- a/assets/scss/_base.scss
+++ b/assets/scss/_base.scss
@@ -42,6 +42,10 @@ $video-section-height: 200px;
 
 body {
   background-color: white;
+
+  a {
+    color: $blue;
+  }
 }
 
 section {
@@ -71,6 +75,7 @@ footer {
     background-color: $blue;
     text-decoration: none;
     font-size: 1rem;
+    border: 0px;
   }
 
   #cellophane {
@@ -83,6 +88,20 @@ footer {
   }
 }
 
+main {
+  .button {
+    display: inline-block;
+    border-radius: 6px;
+    padding: 6px 20px;
+    line-height: 1.3rem;
+    color: white;
+    background-color: $blue;
+    text-decoration: none;
+    font-size: 1rem;
+    border: 0px;
+  }
+}
+
 // HEADER
 
 #hamburger {
@@ -336,7 +355,6 @@ dd {
     width: 100%;
     height: 45px;
     line-height: 45px;
-    font-family: "Roboto", sans-serif;
     font-size: 20px;
     color: $blue;
   }
@@ -612,7 +630,6 @@ section#cncf {
   padding-top: 30px;
   padding-bottom: 80px;
   background-size: auto;
-  // font-family: "Roboto Mono", monospace !important;
   font-size: 24px;
   // font-weight: bold;
 
diff --git a/assets/scss/_case-studies.scss b/assets/scss/_case-studies.scss
index d61d24189c..4f44864127 100644
--- a/assets/scss/_case-studies.scss
+++ b/assets/scss/_case-studies.scss
@@ -2,6 +2,7 @@
 
 hr {
   background-color: #999999;
+  margin-top: 0;
 }
 
 h2 {
@@ -10,7 +11,7 @@ h2 {
 
 .subhead {
   padding-bottom: 2% !important;
-  padding-top: 0% !important;
+  padding-top: 0.75em !important;
 }
 
 .details {
diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss
index 563d87272f..5eb26c2e54 100644
--- a/assets/scss/_custom.scss
+++ b/assets/scss/_custom.scss
@@ -11,15 +11,19 @@ $announcement-size-adjustment: 8px;
       max-width: 100%;
     }
 
-    table {
-      margin-bottom: 1rem;
-      display: initial;
-    }
-
     @media only screen and (min-width: 768px) {
       padding-top: 2rem !important;
     }
   }
+
+  .ui-widget {
+    font-family: inherit;
+    font-size: inherit;
+  }
+
+  .ui-widget-content a {
+    color: $blue;
+  }
 }
 
 section {
@@ -34,6 +38,14 @@ section {
   padding: 0 !important;
 }
 
+
+/* Emphasize first paragraph of running text on site front page */
+body.td-home main[role="main"] > section:first-of-type .content p:first-child {
+  line-height: 1.3em;
+  font-size: 1.4em;
+  margin-bottom: 1.5em;
+}
+
 #desktopShowVideoButton {
   border: none
 }
@@ -44,6 +56,39 @@ section {
   }
 }
 
+body.td-404 main .error-details {
+  max-width: 1100px;
+  margin-left: auto;
+  margin-right: auto;
+  margin-top: 4em;
+  margin-bottom: 0;
+}
+
+/* Global - Mermaid.js diagrams */
+
+.mermaid {
+  overflow-x: auto;
+  max-width: 80%;
+  border: 1px solid rgb(222, 226, 230);
+  border-radius: 5px;
+  margin-bottom: 1rem;
+  padding-top: 1rem;
+  padding-bottom: 1rem;
+
+  // mermaid diagram - sequence diagram
+  .actor {
+    fill: #326ce5 !important;
+  }
+  text.actor {
+    font-size: 18px !important;
+    stroke: white !important;
+    fill: white !important;
+  }
+  .activation0 {
+    fill: #c9e9ec !important;
+  }
+}
+
 /* HEADER */
 
 .td-navbar {
@@ -268,22 +313,34 @@ main {
 
 // blockquotes and callouts
 
-blockquote {
-  padding: 0.4rem 0.4rem 0.4rem 1rem !important;
-}
+.td-content, body {
+  blockquote.callout {
+    padding: 0.4rem 0.4rem 0.4rem 1rem;
+    border: 1px solid #eee;
+    border-left-width: 0.5em;
+    background: #fff;
+    color: #000;
+    margin-top: 0.5em;
+    margin-bottom: 0.5em;
+  }
+  blockquote.callout {
+    border-radius: calc(1em/3);
+  }
+  .callout.caution {
+    border-left-color: #f0ad4e;
+  }
 
-// callouts are contained in static CSS as well. these require override.
+  .callout.note {
+    border-left-color: #428bca;
+  }
 
-.caution {
-  border-left-color: #f0ad4e !important;
-}
+  .callout.warning {
+    border-left-color: #d9534f;
+  }
 
-.note {
-  border-left-color: #428bca !important;
-}
-
-.warning {
-  border-left-color: #d9534f !important;
+  h1:first-of-type + blockquote.callout {
+    margin-top: 1.5em;
+  }
 }
 
 .deprecation-warning {
@@ -393,6 +450,7 @@ body.cid-community > #deprecation-warning > .deprecation-warning > * {
       }
 
       color: $blue;
+      margin: 1rem;
     }
   }
 }
@@ -512,3 +570,11 @@ body.td-documentation {
     }
   }
 }
+
+/* glossary tooltip */
+.glossary-tooltip {
+  display: inline-block;
+  border-bottom: 1px dotted black; /* If you want dots under the hoverable text */
+  color: black;
+  text-decoration: none !important;
+}
diff --git a/assets/scss/_variables_project.scss b/assets/scss/_variables_project.scss
index da42c07367..fd1dddd607 100644
--- a/assets/scss/_variables_project.scss
+++ b/assets/scss/_variables_project.scss
@@ -11,3 +11,17 @@ Add styles or override variables from the theme here. */
 @import "base";
 @import "tablet";
 @import "desktop";
+
+$primary: #3371e3;
+
+// tooltip
+$tooltip-bg: #555;
+$tooltip-arrow-color: $tooltip-bg !default;
+$tooltip-arrow-width: 10px !default;
+$tooltip-opacity: 1 !default;
+$tooltip-color: #fff !default;
+$tooltip-max-width: 300px !default;
+$tooltip-font-size: 1rem;
+$tooltip-padding: 5px 8px;
+$tooltip-border-radius: 6px;
+$tooltip-font-weight: 400;
diff --git a/config.toml b/config.toml
index 0915eeb4c3..a59fcbd678 100644
--- a/config.toml
+++ b/config.toml
@@ -33,6 +33,23 @@ enableGitInfo = true
 # Hindi is disabled because it's currently in development.
 disableLanguages = ["hi", "no"]
 
+[caches]
+ [caches.assets]
+  dir = ":cacheDir/_gen"
+  maxAge = -1
+ [caches.getcsv]
+  dir = ":cacheDir/:project"
+  maxAge = "60s"
+ [caches.getjson]
+  dir = ":cacheDir/:project"
+  maxAge = "60s"
+ [caches.images]
+  dir = ":cacheDir/_images"
+  maxAge = -1
+ [caches.modules]
+  dir = ":cacheDir/modules"
+  maxAge = -1
+
 [markup]
  [markup.goldmark]
    [markup.goldmark.extensions]
@@ -66,6 +83,10 @@ date = ["date", ":filename", "publishDate", "lastmod"]
 [permalinks]
 blog = "/:section/:year/:month/:day/:slug/"
 
+[sitemap]
+  filename = "sitemap.xml"
+  priority = 0.75
+
 # Be explicit about the output formats. We (currently) only want an RSS feed for the home page.
 [outputs]
 home = [ "HTML", "RSS", "HEADERS" ]
@@ -112,6 +133,8 @@ copyright_linux =  "Copyright © 2020 The Linux Foundation ®."
 version_menu = "Versions"
 
 time_format_blog = "Monday, January 02, 2006"
+time_format_default = "January 02, 2006 at 3:04 PM PST"
+
 description = "Production-Grade Container Orchestration"
 showedit = true
 
@@ -124,9 +147,13 @@ docsbranch = "master"
 deprecated = false
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
-githubWebsiteRepo = "github.com/kubernetes/website"
+
+# See codenew shortcode
 githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"
 
+# GitHub repository link for editing a page and opening issues.
+github_repo = "https://github.com/kubernetes/website"
+
 # param for displaying an announcement block on every page.
 # See /i18n/en.toml for message text and title.
 announcement = true
@@ -149,8 +176,7 @@ offlineSearch = false
 [params.pushAssets]
 css = [
   "callouts",
-  "styles",
-  "custom-jekyll/tags"
+  "styles"
 ]
 js = [
   "script"
diff --git a/content/de/docs/reference/kubectl/cheatsheet.md b/content/de/docs/reference/kubectl/cheatsheet.md
index 15b8d0bda3..bce7eeefb3 100644
--- a/content/de/docs/reference/kubectl/cheatsheet.md
+++ b/content/de/docs/reference/kubectl/cheatsheet.md
@@ -54,7 +54,8 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
 # Zeigen Sie das Passwort für den e2e-Benutzer an
 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
 
-kubectl config view -o jsonpath='{.users[].name}'    # eine Liste der Benutzer erhalten
+kubectl config view -o jsonpath='{.users[].name}'    # den ersten Benutzer anzeigen
+kubectl config view -o jsonpath='{.users[*].name}'    # eine Liste der Benutzer erhalten
 kubectl config current-context                       # den aktuellen Kontext anzeigen
 kubectl config use-context my-cluster-name           # Setzen Sie den Standardkontext auf my-cluster-name
 
diff --git a/content/de/docs/tasks/tools/install-kubectl.md b/content/de/docs/tasks/tools/install-kubectl.md
index d7fb7aa759..2354fad25f 100644
--- a/content/de/docs/tasks/tools/install-kubectl.md
+++ b/content/de/docs/tasks/tools/install-kubectl.md
@@ -334,7 +334,7 @@ Sie müssen nun sicherstellen, dass das kubectl-Abschlussskript in allen Ihren S
     ```
 
 {{< note >}}
-bash-completion bezieht alle Verfollständigungsskripte aus `/etc/bash_completion.d`.
+bash-completion bezieht alle Vervollständigungsskripte aus `/etc/bash_completion.d`.
 {{< /note >}}
 
 Beide Ansätze sind gleichwertig. Nach dem erneuten Laden der Shell sollte kubectl autocompletion funktionieren.
diff --git a/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index a8e40fad5e..7a5fe0ce4f 100644
--- a/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Um mit dem Terminal zu interagieren, verwenden Sie bitte die Desktop- / Tablet-Version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index f6c836c6c4..8c74aafd78 100644
--- a/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -23,7 +23,7 @@ weight: 20
                 Um mit dem Terminal zu interagieren, verwenden Sie bitte die Desktop- / Tablet-Version
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/de/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/de/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index 9d4026933e..d3fb05eff5 100644
--- a/content/de/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/de/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 Um mit dem Terminal zu interagieren, verwenden Sie bitte die Desktop- / Tablet-Version
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 2c6ebd5ecd..ab5b880397 100644
--- a/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Um mit dem Terminal zu interagieren, verwenden Sie bitte die Desktop- / Tablet-Version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/de/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/de/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index 1ea0c1a70d..648623339f 100644
--- a/content/de/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/de/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Um mit dem Terminal zu interagieren, verwenden Sie bitte die Desktop- / Tablet-Version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 8971b0dd17..448ddc81b9 100644
--- a/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Um mit dem Terminal zu interagieren, verwenden Sie bitte die Desktop- / Tablet-Version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/en/_common-resources/images/kub_video_banner_homepage.jpg b/content/en/_common-resources/images/kub_video_banner_homepage.jpg
index 57582e4938..e40d92a503 100644
Binary files a/content/en/_common-resources/images/kub_video_banner_homepage.jpg and b/content/en/_common-resources/images/kub_video_banner_homepage.jpg differ
diff --git a/content/en/_index.html b/content/en/_index.html
index e5b4f1922c..13a3c069be 100644
--- a/content/en/_index.html
+++ b/content/en/_index.html
@@ -2,11 +2,13 @@
 title: "Production-Grade Container Orchestration"
 abstract: "Automated container deployment, scaling, and management"
 cid: home
+sitemap:
+  priority: 1.0
 ---
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications.
+[Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
 
 It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community.
 {{% /blocks/feature %}}
@@ -26,7 +28,7 @@ Whether testing locally or running a global enterprise, Kubernetes flexibility g
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="suitcase" %}}
-#### Run Anywhere
+#### Run K8s Anywhere
 
 Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.
 
@@ -41,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon EU virtually on August 17-20, 2020</a>
-        <br>
-        <br>
-        <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Attend KubeCon EU virtually on May 4 – 7, 2021</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
diff --git a/content/en/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes_28.md b/content/en/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes_28.md
index b778d8eec1..5509e8666a 100644
--- a/content/en/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes_28.md
+++ b/content/en/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes_28.md
@@ -9,57 +9,37 @@ url: /blog/2016/01/Kubernetes-Community-Meeting-Notes_28
 
 Note taker: Rob Hirshfeld
   - Use Case (10 min): [SFDC Paul Brown](https://docs.google.com/a/google.com/presentation/d/1MEI97efplr3f-GDX1GcWGfkEuGKKV-4niu27kHOeMLk/edit?usp=sharing_eid&ts=56a114f8)
-  - SIG Report - SIG-config and the story of [#18215](https://github.com/kubernetes/kubernetes/pull/18215)
+  
+  - SIG Report - SIG-config and the story of [#18215](https://github.com/kubernetes/kubernetes/pull/18215).
+    - Application config IN K8s not deployment of K8s
+    - Topic has been reuse of configuration,specifically parameterization(aka templates). Needs:
+      - include scoping(cluster namespace)
+      - slight customization (naming changes, but not major config)
+      - multiple positions on how todo this including allowing external or simple extensions
+    - PetSet creates instances w/stable namespace
 
-    - A[p](https://github.com/kubernetes/kubernetes/pull/18215)p[l](https://github.com/kubernetes/kubernetes/pull/18215)i[c](https://github.com/kubernetes/kubernetes/pull/18215)a[t](https://github.com/kubernetes/kubernetes/pull/18215)i[o](https://github.com/kubernetes/kubernetes/pull/18215)n[](https://github.com/kubernetes/kubernetes/pull/18215)c[o](https://github.com/kubernetes/kubernetes/pull/18215)n[f](https://github.com/kubernetes/kubernetes/pull/18215)i[g](https://github.com/kubernetes/kubernetes/pull/18215) [I](https://github.com/kubernetes/kubernetes/pull/18215)N[](https://github.com/kubernetes/kubernetes/pull/18215)K[8](https://github.com/kubernetes/kubernetes/pull/18215)s[,](https://github.com/kubernetes/kubernetes/pull/18215) [n](https://github.com/kubernetes/kubernetes/pull/18215)o[t](https://github.com/kubernetes/kubernetes/pull/18215) [d](https://github.com/kubernetes/kubernetes/pull/18215)e[p](https://github.com/kubernetes/kubernetes/pull/18215)l[o](https://github.com/kubernetes/kubernetes/pull/18215)y[m](https://github.com/kubernetes/kubernetes/pull/18215)e[n](https://github.com/kubernetes/kubernetes/pull/18215)t[](https://github.com/kubernetes/kubernetes/pull/18215)o[f](https://github.com/kubernetes/kubernetes/pull/18215) [K](https://github.com/kubernetes/kubernetes/pull/18215)8[s](https://github.com/kubernetes/kubernetes/pull/18215)
-    - [T](https://github.com/kubernetes/kubernetes/pull/18215)o[p](https://github.com/kubernetes/kubernetes/pull/18215)i[c](https://github.com/kubernetes/kubernetes/pull/18215) [h](https://github.com/kubernetes/kubernetes/pull/18215)a[s](https://github.com/kubernetes/kubernetes/pull/18215) [b](https://github.com/kubernetes/kubernetes/pull/18215)e[e](https://github.com/kubernetes/kubernetes/pull/18215)n[](https://github.com/kubernetes/kubernetes/pull/18215)r[e](https://github.com/kubernetes/kubernetes/pull/18215)u[s](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)o[f](https://github.com/kubernetes/kubernetes/pull/18215) [c](https://github.com/kubernetes/kubernetes/pull/18215)o[n](https://github.com/kubernetes/kubernetes/pull/18215)f[i](https://github.com/kubernetes/kubernetes/pull/18215)g[u](https://github.com/kubernetes/kubernetes/pull/18215)r[a](https://github.com/kubernetes/kubernetes/pull/18215)t[i](https://github.com/kubernetes/kubernetes/pull/18215)o[n](https://github.com/kubernetes/kubernetes/pull/18215),[](https://github.com/kubernetes/kubernetes/pull/18215)s[p](https://github.com/kubernetes/kubernetes/pull/18215)e[c](https://github.com/kubernetes/kubernetes/pull/18215)i[f](https://github.com/kubernetes/kubernetes/pull/18215)i[c](https://github.com/kubernetes/kubernetes/pull/18215)a[l](https://github.com/kubernetes/kubernetes/pull/18215)l[y](https://github.com/kubernetes/kubernetes/pull/18215) [p](https://github.com/kubernetes/kubernetes/pull/18215)a[r](https://github.com/kubernetes/kubernetes/pull/18215)a[m](https://github.com/kubernetes/kubernetes/pull/18215)e[t](https://github.com/kubernetes/kubernetes/pull/18215)e[r](https://github.com/kubernetes/kubernetes/pull/18215)i[z](https://github.com/kubernetes/kubernetes/pull/18215)a[t](https://github.com/kubernetes/kubernetes/pull/18215)i[o](https://github.com/kubernetes/kubernetes/pull/18215)n[](https://github.com/kubernetes/kubernetes/pull/18215)([a](https://github.com/kubernetes/kubernetes/pull/18215)k[a](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)e[m](https://github.com/kubernetes/kubernetes/pull/18215)p[l](https://github.com/kubernetes/kubernetes/pull/18215)a[t](https://github.com/kubernetes/kubernetes/pull/18215)e[s](https://github.com/kubernetes/kubernetes/pull/18215))[. Needs:](https://github.com/kubernetes/kubernetes/pull/18215)
+  - Workflow proposal
+    - Distributed Chron. Challenge is that configs need to create multiple objects in sequence
+    - Trying to figure out how balance the many config options out there (compose, terraform,ansible/etc)
+    - Goal is to “meet people where they are” to keep it simple
+    - Q: is there an opinion for the keystore sizing
+      - large size / data blob would not be appropriate
+      - you can pull data(config) from another store for larger objects
 
-      - n[e](https://github.com/kubernetes/kubernetes/pull/18215)e[d](https://github.com/kubernetes/kubernetes/pull/18215)s[](https://github.com/kubernetes/kubernetes/pull/18215)i[n](https://github.com/kubernetes/kubernetes/pull/18215)c[l](https://github.com/kubernetes/kubernetes/pull/18215)u[d](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)s[c](https://github.com/kubernetes/kubernetes/pull/18215)o[p](https://github.com/kubernetes/kubernetes/pull/18215)i[n](https://github.com/kubernetes/kubernetes/pull/18215)g[](https://github.com/kubernetes/kubernetes/pull/18215)([c](https://github.com/kubernetes/kubernetes/pull/18215)l[u](https://github.com/kubernetes/kubernetes/pull/18215)s[t](https://github.com/kubernetes/kubernetes/pull/18215)e[r](https://github.com/kubernetes/kubernetes/pull/18215) [n](https://github.com/kubernetes/kubernetes/pull/18215)a[m](https://github.com/kubernetes/kubernetes/pull/18215)e[s](https://github.com/kubernetes/kubernetes/pull/18215)p[a](https://github.com/kubernetes/kubernetes/pull/18215)c[e](https://github.com/kubernetes/kubernetes/pull/18215))
-      - s[l](https://github.com/kubernetes/kubernetes/pull/18215)i[g](https://github.com/kubernetes/kubernetes/pull/18215)h[t](https://github.com/kubernetes/kubernetes/pull/18215) [c](https://github.com/kubernetes/kubernetes/pull/18215)u[s](https://github.com/kubernetes/kubernetes/pull/18215)t[o](https://github.com/kubernetes/kubernetes/pull/18215)m[i](https://github.com/kubernetes/kubernetes/pull/18215)z[a](https://github.com/kubernetes/kubernetes/pull/18215)t[i](https://github.com/kubernetes/kubernetes/pull/18215)o[n (naming changes, but not major config)](https://github.com/kubernetes/kubernetes/pull/18215)
-      - [m](https://github.com/kubernetes/kubernetes/pull/18215)u[l](https://github.com/kubernetes/kubernetes/pull/18215)t[i](https://github.com/kubernetes/kubernetes/pull/18215)p[l](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)p[o](https://github.com/kubernetes/kubernetes/pull/18215)s[i](https://github.com/kubernetes/kubernetes/pull/18215)t[i](https://github.com/kubernetes/kubernetes/pull/18215)o[n](https://github.com/kubernetes/kubernetes/pull/18215)s[](https://github.com/kubernetes/kubernetes/pull/18215)o[n](https://github.com/kubernetes/kubernetes/pull/18215) [h](https://github.com/kubernetes/kubernetes/pull/18215)o[w](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)d[o](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)h[i](https://github.com/kubernetes/kubernetes/pull/18215)s[](https://github.com/kubernetes/kubernetes/pull/18215)i[n](https://github.com/kubernetes/kubernetes/pull/18215)c[l](https://github.com/kubernetes/kubernetes/pull/18215)u[d](https://github.com/kubernetes/kubernetes/pull/18215)i[n](https://github.com/kubernetes/kubernetes/pull/18215)g[](https://github.com/kubernetes/kubernetes/pull/18215)
-
-        -
-a[l](https://github.com/kubernetes/kubernetes/pull/18215)l[o](https://github.com/kubernetes/kubernetes/pull/18215)w[i](https://github.com/kubernetes/kubernetes/pull/18215)n[g](https://github.com/kubernetes/kubernetes/pull/18215) [e](https://github.com/kubernetes/kubernetes/pull/18215)x[t](https://github.com/kubernetes/kubernetes/pull/18215)e[r](https://github.com/kubernetes/kubernetes/pull/18215)n[a](https://github.com/kubernetes/kubernetes/pull/18215)l[](https://github.com/kubernetes/kubernetes/pull/18215)o[r](https://github.com/kubernetes/kubernetes/pull/18215) [s](https://github.com/kubernetes/kubernetes/pull/18215)i[m](https://github.com/kubernetes/kubernetes/pull/18215)p[l](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)e[x](https://github.com/kubernetes/kubernetes/pull/18215)t[e](https://github.com/kubernetes/kubernetes/pull/18215)n[s](https://github.com/kubernetes/kubernetes/pull/18215)i[o](https://github.com/kubernetes/kubernetes/pull/18215)n[s](https://github.com/kubernetes/kubernetes/pull/18215).
-        -
-P[e](https://github.com/kubernetes/kubernetes/pull/18215)t[S](https://github.com/kubernetes/kubernetes/pull/18215)e[t](https://github.com/kubernetes/kubernetes/pull/18215) [c](https://github.com/kubernetes/kubernetes/pull/18215)r[e](https://github.com/kubernetes/kubernetes/pull/18215)a[t](https://github.com/kubernetes/kubernetes/pull/18215)e[s](https://github.com/kubernetes/kubernetes/pull/18215) [i](https://github.com/kubernetes/kubernetes/pull/18215)n[s](https://github.com/kubernetes/kubernetes/pull/18215)t[a](https://github.com/kubernetes/kubernetes/pull/18215)n[c](https://github.com/kubernetes/kubernetes/pull/18215)e[s](https://github.com/kubernetes/kubernetes/pull/18215) [w](https://github.com/kubernetes/kubernetes/pull/18215)/[](https://github.com/kubernetes/kubernetes/pull/18215)s[t](https://github.com/kubernetes/kubernetes/pull/18215)a[b](https://github.com/kubernetes/kubernetes/pull/18215)l[e](https://github.com/kubernetes/kubernetes/pull/18215) [n](https://github.com/kubernetes/kubernetes/pull/18215)a[m](https://github.com/kubernetes/kubernetes/pull/18215)e[s](https://github.com/kubernetes/kubernetes/pull/18215)p[a](https://github.com/kubernetes/kubernetes/pull/18215)c[e](https://github.com/kubernetes/kubernetes/pull/18215)
-        -
-[W](https://github.com/kubernetes/kubernetes/pull/18215)o[r](https://github.com/kubernetes/kubernetes/pull/18215)k[f](https://github.com/kubernetes/kubernetes/pull/18215)l[o](https://github.com/kubernetes/kubernetes/pull/18215)w[](https://github.com/kubernetes/kubernetes/pull/18215)p[r](https://github.com/kubernetes/kubernetes/pull/18215)o[p](https://github.com/kubernetes/kubernetes/pull/18215)o[s](https://github.com/kubernetes/kubernetes/pull/18215)a[l](https://github.com/kubernetes/kubernetes/pull/18215)
-        -
-[D](https://github.com/kubernetes/kubernetes/pull/18215)i[s](https://github.com/kubernetes/kubernetes/pull/18215)t[r](https://github.com/kubernetes/kubernetes/pull/18215)i[b](https://github.com/kubernetes/kubernetes/pull/18215)u[t](https://github.com/kubernetes/kubernetes/pull/18215)e[d](https://github.com/kubernetes/kubernetes/pull/18215) [C](https://github.com/kubernetes/kubernetes/pull/18215)h[r](https://github.com/kubernetes/kubernetes/pull/18215)o[n](https://github.com/kubernetes/kubernetes/pull/18215).
-      -
-C[h](https://github.com/kubernetes/kubernetes/pull/18215)a[l](https://github.com/kubernetes/kubernetes/pull/18215)l[e](https://github.com/kubernetes/kubernetes/pull/18215)n[g](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)i[s](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)h[a](https://github.com/kubernetes/kubernetes/pull/18215)t[](https://github.com/kubernetes/kubernetes/pull/18215)c[o](https://github.com/kubernetes/kubernetes/pull/18215)n[f](https://github.com/kubernetes/kubernetes/pull/18215)i[g](https://github.com/kubernetes/kubernetes/pull/18215)s[](https://github.com/kubernetes/kubernetes/pull/18215)n[e](https://github.com/kubernetes/kubernetes/pull/18215)e[d](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)c[r](https://github.com/kubernetes/kubernetes/pull/18215)e[a](https://github.com/kubernetes/kubernetes/pull/18215)t[e](https://github.com/kubernetes/kubernetes/pull/18215) [m](https://github.com/kubernetes/kubernetes/pull/18215)u[l](https://github.com/kubernetes/kubernetes/pull/18215)t[i](https://github.com/kubernetes/kubernetes/pull/18215)p[l](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)o[b](https://github.com/kubernetes/kubernetes/pull/18215)j[e](https://github.com/kubernetes/kubernetes/pull/18215)c[t](https://github.com/kubernetes/kubernetes/pull/18215)s[](https://github.com/kubernetes/kubernetes/pull/18215)i[n](https://github.com/kubernetes/kubernetes/pull/18215) [s](https://github.com/kubernetes/kubernetes/pull/18215)e[q](https://github.com/kubernetes/kubernetes/pull/18215)u[e](https://github.com/kubernetes/kubernetes/pull/18215)n[c](https://github.com/kubernetes/kubernetes/pull/18215)e
-      -
-T[r](https://github.com/kubernetes/kubernetes/pull/18215)y[i](https://github.com/kubernetes/kubernetes/pull/18215)n[g](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)f[i](https://github.com/kubernetes/kubernetes/pull/18215)g[u](https://github.com/kubernetes/kubernetes/pull/18215)r[e](https://github.com/kubernetes/kubernetes/pull/18215) [o](https://github.com/kubernetes/kubernetes/pull/18215)u[t](https://github.com/kubernetes/kubernetes/pull/18215) [h](https://github.com/kubernetes/kubernetes/pull/18215)o[w](https://github.com/kubernetes/kubernetes/pull/18215) [b](https://github.com/kubernetes/kubernetes/pull/18215)a[l](https://github.com/kubernetes/kubernetes/pull/18215)a[n](https://github.com/kubernetes/kubernetes/pull/18215)c[e](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)h[e](https://github.com/kubernetes/kubernetes/pull/18215) [m](https://github.com/kubernetes/kubernetes/pull/18215)a[n](https://github.com/kubernetes/kubernetes/pull/18215)y[](https://github.com/kubernetes/kubernetes/pull/18215)c[o](https://github.com/kubernetes/kubernetes/pull/18215)n[f](https://github.com/kubernetes/kubernetes/pull/18215)i[g](https://github.com/kubernetes/kubernetes/pull/18215) [o](https://github.com/kubernetes/kubernetes/pull/18215)p[t](https://github.com/kubernetes/kubernetes/pull/18215)i[o](https://github.com/kubernetes/kubernetes/pull/18215)n[s](https://github.com/kubernetes/kubernetes/pull/18215) [o](https://github.com/kubernetes/kubernetes/pull/18215)u[t](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)h[e](https://github.com/kubernetes/kubernetes/pull/18215)r[e](https://github.com/kubernetes/kubernetes/pull/18215) [(](https://github.com/kubernetes/kubernetes/pull/18215)c[o](https://github.com/kubernetes/kubernetes/pull/18215)m[p](https://github.com/kubernetes/kubernetes/pull/18215)o[s](https://github.com/kubernetes/kubernetes/pull/18215)e[,](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)e[r](https://github.com/kubernetes/kubernetes/pull/18215)r[a](https://github.com/kubernetes/kubernetes/pull/18215)f[o](https://github.com/kubernetes/kubernetes/pull/18215)r[m](https://github.com/kubernetes/kubernetes/pull/18215),[](https://github.com/kubernetes/kubernetes/pull/18215)a[n](https://github.com/kubernetes/kubernetes/pull/18215)s[i](https://github.com/kubernetes/kubernetes/pull/18215)b[l](https://github.com/kubernetes/kubernetes/pull/18215)e[/](https://github.com/kubernetes/kubernetes/pull/18215)e[t](https://github.com/kubernetes/kubernetes/pull/18215)c[)](https://github.com/kubernetes/kubernetes/pull/18215)
-      -
-[G](https://github.com/kubernetes/kubernetes/pull/18215)o[a](https://github.com/kubernetes/kubernetes/pull/18215)l[](https://github.com/kubernetes/kubernetes/pull/18215)i[s](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)“[m](https://github.com/kubernetes/kubernetes/pull/18215)e[e](https://github.com/kubernetes/kubernetes/pull/18215)t[](https://github.com/kubernetes/kubernetes/pull/18215)p[e](https://github.com/kubernetes/kubernetes/pull/18215)o[p](https://github.com/kubernetes/kubernetes/pull/18215)l[e](https://github.com/kubernetes/kubernetes/pull/18215) [w](https://github.com/kubernetes/kubernetes/pull/18215)h[e](https://github.com/kubernetes/kubernetes/pull/18215)r[e](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)h[e](https://github.com/kubernetes/kubernetes/pull/18215)y[](https://github.com/kubernetes/kubernetes/pull/18215)a[r](https://github.com/kubernetes/kubernetes/pull/18215)e[”](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)k[e](https://github.com/kubernetes/kubernetes/pull/18215)e[p](https://github.com/kubernetes/kubernetes/pull/18215) [i](https://github.com/kubernetes/kubernetes/pull/18215)t[](https://github.com/kubernetes/kubernetes/pull/18215)s[i](https://github.com/kubernetes/kubernetes/pull/18215)m[p](https://github.com/kubernetes/kubernetes/pull/18215)l[e](https://github.com/kubernetes/kubernetes/pull/18215)
-      -
-[Q](https://github.com/kubernetes/kubernetes/pull/18215): is there an opinion for the keystore sizing
-
-        -
-large size / data blob would not be appropriate
-        -
-you can pull data(config) from another store for larger objects
-  -
-[SIG Report - SIG-federation - progress on Ubernetes-Lite & Ubernetes design](https://github.com/kubernetes/kubernetes/pull/18215)
-
-    -
-[G](https://github.com/kubernetes/kubernetes/pull/18215)o[a](https://github.com/kubernetes/kubernetes/pull/18215)l[](https://github.com/kubernetes/kubernetes/pull/18215)i[t](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)b[e](https://github.com/kubernetes/kubernetes/pull/18215) [a](https://github.com/kubernetes/kubernetes/pull/18215)b[l](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)t[o](https://github.com/kubernetes/kubernetes/pull/18215) [h](https://github.com/kubernetes/kubernetes/pull/18215)a[v](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)a[](https://github.com/kubernetes/kubernetes/pull/18215)c[l](https://github.com/kubernetes/kubernetes/pull/18215)u[s](https://github.com/kubernetes/kubernetes/pull/18215)t[e](https://github.com/kubernetes/kubernetes/pull/18215)r[](https://github.com/kubernetes/kubernetes/pull/18215)m[a](https://github.com/kubernetes/kubernetes/pull/18215)n[a](https://github.com/kubernetes/kubernetes/pull/18215)g[e](https://github.com/kubernetes/kubernetes/pull/18215)r[,](https://github.com/kubernetes/kubernetes/pull/18215) [s](https://github.com/kubernetes/kubernetes/pull/18215)o[](https://github.com/kubernetes/kubernetes/pull/18215)y[o](https://github.com/kubernetes/kubernetes/pull/18215)u[](https://github.com/kubernetes/kubernetes/pull/18215)c[a](https://github.com/kubernetes/kubernetes/pull/18215)n[](https://github.com/kubernetes/kubernetes/pull/18215)f[e](https://github.com/kubernetes/kubernetes/pull/18215)d[e](https://github.com/kubernetes/kubernetes/pull/18215)r[a](https://github.com/kubernetes/kubernetes/pull/18215)t[e](https://github.com/kubernetes/kubernetes/pull/18215) [c](https://github.com/kubernetes/kubernetes/pull/18215)l[u](https://github.com/kubernetes/kubernetes/pull/18215)s[t](https://github.com/kubernetes/kubernetes/pull/18215)e[r](https://github.com/kubernetes/kubernetes/pull/18215)s[. &nbsp;They will automatically distribute the pods.](https://github.com/kubernetes/kubernetes/pull/18215)
-    -
-P[l](https://github.com/kubernetes/kubernetes/pull/18215)a[n](https://github.com/kubernetes/kubernetes/pull/18215) [i](https://github.com/kubernetes/kubernetes/pull/18215)s[](https://github.com/kubernetes/kubernetes/pull/18215)t[o](https://github.com/kubernetes/kubernetes/pull/18215) [u](https://github.com/kubernetes/kubernetes/pull/18215)s[e](https://github.com/kubernetes/kubernetes/pull/18215) [t](https://github.com/kubernetes/kubernetes/pull/18215)h[e](https://github.com/kubernetes/kubernetes/pull/18215) [s](https://github.com/kubernetes/kubernetes/pull/18215)a[m](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)A[P](https://github.com/kubernetes/kubernetes/pull/18215)I[](https://github.com/kubernetes/kubernetes/pull/18215)f[o](https://github.com/kubernetes/kubernetes/pull/18215)r[](https://github.com/kubernetes/kubernetes/pull/18215)t[h](https://github.com/kubernetes/kubernetes/pull/18215)e[](https://github.com/kubernetes/kubernetes/pull/18215)m[a](https://github.com/kubernetes/kubernetes/pull/18215)s[t](https://github.com/kubernetes/kubernetes/pull/18215)e[r](https://github.com/kubernetes/kubernetes/pull/18215) [c](https://github.com/kubernetes/kubernetes/pull/18215)l[u](https://github.com/kubernetes/kubernetes/pull/18215)s[te](https://github.com/kubernetes/kubernetes/pull/18215)r
-    - Quinton's Ubernetes Talk: &nbsp;https://youtu.be/L2ZK24JojB4
-    - Design for Ubernetes: https://github.com/kubernetes/kubernetes/pull/19313
+  - SIG Report - SIG-federation - progress on Ubernetes-Lite & Ubernetes design
+   - Goal is to be able to have a cluster manager, so you can federate clusters. They will automatically distribute the pods.
+   - Plan is to use the same API for the master cluster
+   - [Quinton's Kubernetes Talk](https://youtu.be/L2ZK24JojB4)
+   - [Design for Kubernetes:](https://github.com/kubernetes/kubernetes/pull/19313)
 
 
-  - Conformance testing Q+A [Isaac Hollander McCreery]
-
+  - Conformance testing Q+A Isaac Hollander McCreery
     - status on conformance testing for release process
-
-      - expect to be forward compatible but not backwards
+    - expect to be forward compatible but not backwards
     - is there interest for a sig-testing meeting
     - testing needs to a higher priority for the project
     - lots of focus on trying to make this a higher priority
-To get involved in the Kubernetes community consider joining our [Slack channel](http://slack.k8s.io/), taking a look at the [Kubernetes project](https://github.com/kubernetes/) on GitHub, or join the [Kubernetes-dev Google group](https://groups.google.com/forum/#!forum/kubernetes-dev). If you’re really excited, you can do all of the above and join us for the next community conversation -- January 27th, 2016. Please add yourself or a topic you want to know about to the [agenda](https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit) and get a calendar invitation by joining [this group](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat).  
-
+To get involved in the Kubernetes community consider joining our [Slack channel](http://slack.k8s.io/), taking a look at the [Kubernetes project](https://github.com/kubernetes/) on GitHub, or join the [Kubernetes-dev Google group](https://groups.google.com/forum/#!forum/kubernetes-dev). If you’re really excited, you can do all of the above and join us for the next community conversation -- January 27th, 2016. Please add yourself or a topic you want to know about to [the agenda](https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit) and get a calendar invitation by joining [this group](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat).  
 
 
 Still want more Kubernetes? Check out the [recording](https://www.youtube.com/watch?v=izQLFx_6kwY&feature=youtu.be&list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ) of this meeting and the growing of the archive of [Kubernetes Community Meetings](https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ).
diff --git a/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md
index 4614421d1b..a5d9f8b4d0 100644
--- a/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md
+++ b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md
@@ -45,7 +45,7 @@ Support for [dynamic maximum volume count](https://github.com/kubernetes/feature
 
 The StorageObjectInUseProtection feature is now stable and prevents the removal of both [Persistent Volumes](https://github.com/kubernetes/features/issues/499) that are bound to a Persistent Volume Claim, and [Persistent Volume Claims](https://github.com/kubernetes/features/issues/498) that are being used by a pod. This safeguard will help prevent issues from deleting a PV or a PVC that is currently tied to an active pod.
 
-Each Special Interest Group (SIG) within the community continues to deliver the most-requested enhancements, fixes, and functionality for their respective specialty areas. For a complete list of inclusions by SIG, please visit the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#111-release-notes).
+Each Special Interest Group (SIG) within the community continues to deliver the most-requested enhancements, fixes, and functionality for their respective specialty areas. For a complete list of inclusions by SIG, please visit the [release notes](https://github.com/kubernetes/kubernetes/blob/release-1.11/CHANGELOG-1.11.md#111-release-notes).
 
 ## Availability
 
@@ -88,7 +88,7 @@ Is Kubernetes helping your team? Share your story with the community.
 * The CNCF recently expanded its certification offerings to include a Certified Kubernetes Application Developer exam. The CKAD exam certifies an individual's ability to design, build, configure, and expose cloud native applications for Kubernetes. More information can be found [here](https://www.cncf.io/blog/2018/03/16/cncf-announces-ckad-exam/).
 * The CNCF recently added a new partner category, Kubernetes Training Partners (KTP). KTPs are a tier of vetted training providers who have deep experience in cloud native technology training. View partners and learn more [here](https://www.cncf.io/certification/training/).
 * CNCF also offers [online training](https://www.cncf.io/certification/training/) that teaches the skills needed to create and configure a real-world Kubernetes cluster.
-* Kubernetes documentation now features [user journeys](https://k8s.io/docs/home/): specific pathways for learning based on who readers are and what readers want to do. Learning Kubernetes is easier than ever for beginners, and more experienced users can find task journeys specific to cluster admins and application developers.  
+* Kubernetes documentation now features [user journeys](https://k8s.io/docs/home/): specific pathways for learning based on who readers are and what readers want to do. Learning Kubernetes is easier than ever for beginners, and more experienced users can find task journeys specific to cluster admins and application developers.
 
 ## KubeCon
 
diff --git a/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md b/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md
index d7989ed65b..49516da96a 100644
--- a/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md
+++ b/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md
@@ -12,7 +12,7 @@ Kubernetes is well-known for running scalable workloads. It scales your workload
 
 ## Guaranteed scheduling with controlled cost
 
-[Kubernetes Cluster Autoscaler](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) is an excellent tool in the ecosystem which adds more nodes to your cluster when your applications need them. However, cluster autoscaler has some limitations and may not work for all users:
+[Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/) is an excellent tool in the ecosystem which adds more nodes to your cluster when your applications need them. However, cluster autoscaler has some limitations and may not work for all users:
 
 - It does not work in physical clusters.
 - Adding more nodes to the cluster costs more.
diff --git a/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md b/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
index 49519cef15..3561203548 100644
--- a/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
+++ b/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
@@ -89,7 +89,7 @@ Volume cloning enables users to specify another PVC as a "DataSource" when provi
 - ExecutionHook API [designed to trigger hook commands](https://github.com/kubernetes/enhancements/issues/962) in the containers for different use cases is now Alpha.
 - Continued deprecation of extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs; these extensions will be retired in 1.16!
 
-Check the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#kubernetes-v115-release-notes) for a complete list of notable features and fixes.
+Check the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#kubernetes-v115-release-notes) for a complete list of notable features and fixes.
 
 **Availability**
 
diff --git a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
index 42b6a3c5a0..0a84075aaf 100644
--- a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
+++ b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
@@ -153,7 +153,7 @@ And as sources are always important to mention, we will follow (partially) the h
 
 ```bash
 # Download the latest version of KinD
-curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.7.0/kind-$(uname)-amd64
+curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.7.0/kind-linux-amd64
 # Make the binary executable
 chmod +x ./kind
 # Move the binary to your executable path
diff --git a/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md b/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md
index 3be4481954..1d82e67fb2 100644
--- a/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md
+++ b/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md
@@ -61,7 +61,7 @@ mind.
 ## Avoiding permanent beta
 
 For Kubernetes REST APIs, when a new feature's API reaches beta, that starts a countdown.
-The beta-quality API now has **nine calendar months** to either:
+The beta-quality API now has **three releases** (about nine calendar months) to either:
 - reach GA, and deprecate the beta, or
 - have a new beta version (_and deprecate the previous beta_).
 
@@ -69,9 +69,10 @@ To be clear, at this point **only REST APIs are affected**. For example, _APILis
 a beta feature but isn't itself a REST API. Right now there are no plans to automatically
 deprecate _APIListChunking_ nor any other features that aren't REST APIs.
 
-If a REST API reaches the end of that 9 month countdown, then the next Kubernetes release
-will deprecate that API version. There's no option for the REST API to stay at the same
-beta version beyond the first Kubernetes release to come out after the 9 month window.
+If a beta API has not graduated to GA after three Kubernetes releases, then the
+next Kubernetes release will deprecate that API version. There's no option for
+the REST API to stay at the same beta version beyond the first Kubernetes
+release to come out after the release window.
 
 ### What this means for you
 
diff --git a/content/en/blog/_posts/2020-08-26-kubernetes-release-1.19.md b/content/en/blog/_posts/2020-08-26-kubernetes-release-1.19.md
index 5f2d162eaf..6f7a4c4096 100644
--- a/content/en/blog/_posts/2020-08-26-kubernetes-release-1.19.md
+++ b/content/en/blog/_posts/2020-08-26-kubernetes-release-1.19.md
@@ -1,27 +1,27 @@
 ---
-layout: blog 
+layout: blog
 title: 'Kubernetes  1.19: Accentuate the Paw-sitive'
-date: 2020-08-26 
+date: 2020-08-26
 slug: kubernetes-release-1.19-accentuate-the-paw-sitive
 ---
 
 **Authors:** [Kubernetes 1.19 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.19/release_team.md)
 
-Finally, we have arrived with Kubernetes 1.19, the second release for 2020, and by far the longest release cycle lasting 20 weeks in total. It consists of 33 enhancements: 12 enhancements are moving to stable, 18 enhancements in beta, and 13 enhancements in alpha. 
+Finally, we have arrived with Kubernetes 1.19, the second release for 2020, and by far the longest release cycle lasting 20 weeks in total. It consists of 34 enhancements: 10 enhancements are moving to stable, 15 enhancements in beta, and 9 enhancements in alpha.
 
-The 1.19 release was quite different from a regular release due to COVID-19, the George Floyd protests, and several other global events that we experienced as a release team. Due to these events, we made the decision to adjust our timeline and allow the SIGs, Working Groups, and contributors more time to get things done. The extra time also allowed for people to take time to focus on their lives outside of the Kubernetes project, and ensure their mental wellbeing was in a good place. 
+The 1.19 release was quite different from a regular release due to COVID-19, the George Floyd protests, and several other global events that we experienced as a release team. Due to these events, we made the decision to adjust our timeline and allow the SIGs, Working Groups, and contributors more time to get things done. The extra time also allowed for people to take time to focus on their lives outside of the Kubernetes project, and ensure their mental wellbeing was in a good place.
 
-Contributors are the heart of Kubernetes, not the other way around. The Kubernetes code of conduct asks that people be excellent to one another and despite the unrest in our world, we saw nothing but greatness and humility from the community. 
+Contributors are the heart of Kubernetes, not the other way around. The Kubernetes code of conduct asks that people be excellent to one another and despite the unrest in our world, we saw nothing but greatness and humility from the community.
 
 ## Major Themes
 ### Increase Kubernetes support window to one year
 
-A survey conducted in early 2019 by the [Long Term Support (LTS) working group](https://github.com/kubernetes/community/tree/master/wg-lts#readme) showed that a significant subset of Kubernetes end-users fail to upgrade within the current 9-month support period. 
+A survey conducted in early 2019 by the [Long Term Support (LTS) working group](https://github.com/kubernetes/community/tree/master/wg-lts#readme) showed that a significant subset of Kubernetes end-users fail to upgrade within the current 9-month support period.
 This, and other responses from the survey, suggest that 30% of users would be able to keep their deployments on supported versions if the patch support period were extended to 12-14 months. This appears to be true regardless of whether the users are on self build or commercially vendored distributions. An extension would thus lead to more than 80% of users being on supported versions, instead of the 50-60% we have now.
 A yearly support period provides the cushion end-users appear to desire, and is more in harmony with familiar annual planning cycles.
 From Kubernetes version 1.19 on, the support window will be extended to one year.
 
-### Storage capacity tracking 
+### Storage capacity tracking
 
 Traditionally, the Kubernetes scheduler was based on the assumptions that additional persistent storage is available everywhere in the cluster and has infinite capacity. Topology constraints addressed the first point, but up to now pod scheduling was still done without considering that the remaining storage capacity may not be enough to start a new pod. [Storage capacity tracking](/docs/concepts/storage/storage-capacity/), a new alpha feature, addresses that by adding an API for a CSI driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod. This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained.
 
@@ -35,7 +35,7 @@ All features supported with PersistentVolumeClaims are supported, such as storag
 The alpha version of CSI health monitoring is being released with Kubernetes 1.19. This feature enables CSI Drivers to share abnormal volume conditions from the underlying storage systems with Kubernetes so that they can be reported as events on PVCs or Pods. This feature serves as a stepping stone towards programmatic detection and resolution of individual volume health issues by Kubernetes.
 
 ### Ingress graduates to General Availability
-In terms of moving the Ingress API towards GA, the API itself has been available in beta for so long that it has attained de facto GA status through usage and adoption (both by users and by load balancer / ingress controller providers). Abandoning it without a full replacement is not a viable approach. It is clearly a useful API and captures a non-trivial set of use cases. At this point, it seems more prudent to declare the current API as something the community will support as a V1, codifying its status, while working on either a V2 Ingress API or an entirely different API with a superset of features. 
+In terms of moving the Ingress API towards GA, the API itself has been available in beta for so long that it has attained de facto GA status through usage and adoption (both by users and by load balancer / ingress controller providers). Abandoning it without a full replacement is not a viable approach. It is clearly a useful API and captures a non-trivial set of use cases. At this point, it seems more prudent to declare the current API as something the community will support as a V1, codifying its status, while working on either a V2 Ingress API or an entirely different API with a superset of features.
 
 ### Structured logging
 Before v1.19, logging in the Kubernetes control plane couldn't guarantee any uniform structure for log messages and references to Kubernetes objects in those logs. This makes parsing, processing, storing, querying and analyzing logs hard and forces administrators and developers to rely on ad-hoc solutions in most cases based on some regular expressions. Due to those problems any analytical solution based on those logs is hard to implement and maintain.
@@ -45,13 +45,13 @@ This Kubernetes release introduces new methods to the _klog_ library that provid
 
 ### Client TLS certificate rotation for kubelet
 
-A kubelet authenticates the kubelet to the kube-apiserver using a private key and certificate. The certificate is supplied to the kubelet when it is first booted, via an out-of-cluster mechanism. Since Kubernetes v1.8, clusters have included a (beta) process for obtaining the initial cert/key pair and rotating it as expiration of the certificate approaches. In Kubernetes v1.19 this graduates to stable. 
+A kubelet authenticates the kubelet to the kube-apiserver using a private key and certificate. The certificate is supplied to the kubelet when it is first booted, via an out-of-cluster mechanism. Since Kubernetes v1.8, clusters have included a (beta) process for obtaining the initial cert/key pair and rotating it as expiration of the certificate approaches. In Kubernetes v1.19 this graduates to stable.
 
 During the kubelet start-up sequence, the filesystem is scanned for an existing cert/key pair, which is managed by the certificate manager. In the case that a cert/key is available it will be loaded. If not, the kubelet checks its config file for an encoded certificate value or a file reference in the kubeconfig. If the certificate is a bootstrap certificate, this will be used to generate a key, create a certificate signing request and request a signed certificate from the API server.
 
 When an expiration approaches the cert manager takes care of providing the correct certificate, generating new private keys and requesting new certificates. With the kubelet requesting certificates be signed as part of its boot sequence, and on an ongoing basis, certificate signing requests from the kubelet need to be auto approved to make cluster administration manageable.
 
-## Other Updates 
+## Other Updates
 ### Graduated to Stable
 * [Seccomp](https://github.com/kubernetes/enhancements/issues/135)
 * [Kubelet client TLS certificate rotation](https://github.com/kubernetes/enhancements/issues/266)
@@ -76,20 +76,20 @@ Check out the full details of the Kubernetes 1.19 release in our [release notes]
 
 ## Availability
 
-Kubernetes 1.19 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/) or run local Kubernetes clusters using Docker container “nodes” with [KinD](https://kind.sigs.k8s.io/) (Kubernetes in Docker). You can also easily install 1.19 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). 
+Kubernetes 1.19 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/) or run local Kubernetes clusters using Docker container “nodes” with [KinD](https://kind.sigs.k8s.io/) (Kubernetes in Docker). You can also easily install 1.19 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.19/release_team.md) led by Taylor Dolezal, Senior Developer Advocate at HashiCorp. The 34 release team members coordinated many aspects of the release, from documentation to testing, validation, and feature completeness. 
+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.19/release_team.md) led by Taylor Dolezal, Senior Developer Advocate at HashiCorp. The 34 release team members coordinated many aspects of the release, from documentation to testing, validation, and feature completeness.
 
 As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid pace. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. Kubernetes has had over [49,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 3,000 people.
 
 ## Release Logo
-All of you inspired this Kubernetes 1.19 release logo! This release was a bit more of a marathon and a testament to when the world is a wild place, we can come together and do unbelievable things. 
+All of you inspired this Kubernetes 1.19 release logo! This release was a bit more of a marathon and a testament to when the world is a wild place, we can come together and do unbelievable things.
 
 ![Kubernetes 1.19 Release Logo](/images/blog/2020-08-26-kubernetes-1.19-release-announcement/accentuate.png)
 
 
-"Accentuate the Paw-sitive" was chosen as the release theme because it captures the positive outlook that the release team had, despite the state of the world. The characters pictured in the 1.19 logo represent everyone's personalities on our release team, from emo to peppy, and beyond! 
+"Accentuate the Paw-sitive" was chosen as the release theme because it captures the positive outlook that the release team had, despite the state of the world. The characters pictured in the 1.19 logo represent everyone's personalities on our release team, from emo to peppy, and beyond!
 
 About the designer: Hannabeth Lagerlof is a Visual Designer based in Los Angeles, California, and she has an extensive background in Environments and Graphic Design. Hannabeth creates art and user experiences that inspire connection. You can find Hannabeth on Twitter as @emanate_design.
 
@@ -105,10 +105,10 @@ The milestone until which contributors implement the features was extended from
 * The CNCF just concluded its very first Virtual KubeCon. All talks are [on-demand]( https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) for anyone registered, it's not too late!
 * The [Certified Kubernetes Security Specialist](https://www.cncf.io/blog/2020/07/15/certified-kubernetes-security-specialist-cks-coming-in-november/) (CKS) coming in November! CKS focuses on cluster & system hardening, minimizing microservice vulnerabilities and the security of the supply chain.
 * CNCF published the second [State of Cloud Native Development](https://www.cncf.io/blog/2020/08/14/state-of-cloud-native-development/), showing the massively growing number of cloud native developer using container and serverless technology.
-* [Kubernetes.dev](https://www.kubernetes.dev), a Kubernetes contributor focused website has been launched. It brings the  contributor documentation, resources and project event information into one central location.  
+* [Kubernetes.dev](https://www.kubernetes.dev), a Kubernetes contributor focused website has been launched. It brings the  contributor documentation, resources and project event information into one central location.
 
 ## Project Velocity
-The [Kubernetes DevStats dashboard](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) illustrates the breakdown of contributions from major company contributors, as well as an impressive set of preconfigured reports on everything from individual contributors to pull request lifecycle times. If you want to gather numbers, facts and figures from Kubernetes and the CNCF community it is the best place to start. 
+The [Kubernetes DevStats dashboard](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) illustrates the breakdown of contributions from major company contributors, as well as an impressive set of preconfigured reports on everything from individual contributors to pull request lifecycle times. If you want to gather numbers, facts and figures from Kubernetes and the CNCF community it is the best place to start.
 
 During this release cycle from April till August, 382 different companies and over 2,464 individuals contributed to Kubernetes. [Check out DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All&from=1585692000000&to=1598392799000) to learn more about the overall velocity of the Kubernetes project and community.
 
diff --git a/content/en/blog/_posts/2020-08-31-increase-kubernetes-support-one-year.md b/content/en/blog/_posts/2020-08-31-increase-kubernetes-support-one-year.md
new file mode 100644
index 0000000000..91bc4660a5
--- /dev/null
+++ b/content/en/blog/_posts/2020-08-31-increase-kubernetes-support-one-year.md
@@ -0,0 +1,30 @@
+---
+layout: blog 
+title: 'Increasing the Kubernetes Support Window to One Year'
+date: 2020-08-31 
+slug: kubernetes-1-19-feature-one-year-support
+---
+
+**Authors:** Tim Pepper (VMware), Nick Young (VMware)
+
+Starting with Kubernetes 1.19, the support window for Kubernetes versions [will increase from 9 months to one year](https://github.com/kubernetes/enhancements/issues/1498). The longer support window is intended to allow organizations to perform major upgrades at a time of the year that works the best for them.
+
+This is a big change. For many years, the Kubernetes project has delivered a new minor release (e.g.: 1.13 or 1.14) every 3 months. The project provides bugfix support via patch releases (e.g.: 1.13.Y) for three parallel branches of the codebase. Combined, this led to each minor release (e.g.: 1.13) having a patch release stream of support for approximately 9 months. In the end, a cluster operator had to upgrade at least every 9 months to remain supported. 
+
+A survey conducted in early 2019 by the WG LTS showed that a significant subset of Kubernetes end-users fail to upgrade within the 9-month support period. 
+
+![Versions in Production](/images/blog/2020-08-31-increase-kubernetes-support-one-year/versions-in-production-text-2.png)
+
+This, and other responses from the survey, suggest that a considerable portion of our community would better be able to manage their deployments on supported versions if the patch support period were extended to 12-14 months. It appears to be true regardless of whether the users are on DIY builds or commercially vendored distributions. An extension in the patch support length of time would thus lead to a larger percentage of our user base running supported versions compared to what we have now.
+
+A yearly support period provides the cushion end-users appear to desire, and is more aligned with familiar annual planning cycles.
+There are many unknowns about changing the support windows for a project with as many moving parts as Kubernetes. Keeping the change relatively small (relatively being the important word), gives us the chance to find out what those unknowns are in detail and address them.
+From Kubernetes version 1.19 on, the support window will be extended to one year. For Kubernetes versions 1.16, 1.17, and 1.18, the story is more complicated.
+
+All of these versions still fall under the older “three releases support” model, and will drop out of support when 1.19, 1.20 and 1.21 are respectively released. However, because the 1.19 release has been delayed due to the events of 2020, they will end up with close to a year of support (depending on their exact release dates).
+
+For example, 1.19 was released on the 26th of August 2020, which is 11 months since the release of 1.16. Since 1.16 is still under the old release policy, this means that it is now out of support.
+
+![Support Timeline](/images/blog/2020-08-31-increase-kubernetes-support-one-year/support-timeline.png)
+
+If you’ve got thoughts or feedback, we’d love to hear them. Please contact us on [#wg-lts](https://kubernetes.slack.com/messages/wg-lts/) on the Kubernetes Slack, or to the [kubernetes-wg-lts mailing list](https://groups.google.com/g/kubernetes-wg-lts).
diff --git a/content/en/blog/_posts/2020-09-01-generic-ephemeral-volumes.md b/content/en/blog/_posts/2020-09-01-generic-ephemeral-volumes.md
new file mode 100644
index 0000000000..49b0d3b26f
--- /dev/null
+++ b/content/en/blog/_posts/2020-09-01-generic-ephemeral-volumes.md
@@ -0,0 +1,394 @@
+---
+layout: blog
+title: 'Ephemeral volumes with storage capacity tracking: EmptyDir on steroids'
+date: 2020-09-01
+slug: ephemeral-volumes-with-storage-capacity-tracking
+---
+
+**Author:** Patrick Ohly (Intel)
+
+Some applications need additional storage but don't care whether that
+data is stored persistently across restarts. For example, caching
+services are often limited by memory size and can move infrequently
+used data into storage that is slower than memory with little impact
+on overall performance. Other applications expect some read-only input
+data to be present in files, like configuration data or secret keys.
+
+Kubernetes already supports several kinds of such [ephemeral
+volumes](/docs/concepts/storage/ephemeral-volumes), but the
+functionality of those is limited to what is implemented inside
+Kubernetes.
+
+[CSI ephemeral volumes](https://kubernetes.io/blog/2020/01/21/csi-ephemeral-inline-volumes/)
+made it possible to extend Kubernetes with CSI
+drivers that provide light-weight, local volumes. These [*inject
+arbitrary states, such as configuration, secrets, identity, variables
+or similar
+information*](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190122-csi-inline-volumes.md#motivation).
+CSI drivers must be modified to support this Kubernetes feature,
+i.e. normal, standard-compliant CSI drivers will not work, and
+by design such volumes are supposed to be usable on whatever node
+is chosen for a pod.
+
+This is problematic for volumes which consume significant resources on
+a node or for special storage that is only available on some nodes.
+Therefore, Kubernetes 1.19 introduces two new alpha features for
+volumes that are conceptually more like the `EmptyDir` volumes:
+- [*generic* ephemeral volumes](/docs/concepts/storage/ephemeral-volumes#generic-ephemeral-volumes) and
+- [CSI storage capacity tracking](/docs/concepts/storage/storage-capacity).
+
+The advantages of the new approach are:
+- Storage can be local or network-attached.
+- Volumes can have a fixed size that applications are never able to exceed.
+- Works with any CSI driver that supports provisioning of persistent
+  volumes and (for capacity tracking) implements the CSI `GetCapacity` call.
+- Volumes may have some initial data, depending on the driver and
+  parameters.
+- All of the typical volume operations (snapshotting,
+  resizing, the future storage capacity tracking, etc.)
+  are supported.
+- The volumes are usable with any app controller that accepts
+  a Pod or volume specification.
+- The Kubernetes scheduler itself picks suitable nodes, i.e. there is
+  no need anymore to implement and configure scheduler extenders and
+  mutating webhooks.
+
+This makes generic ephemeral volumes a suitable solution for several
+use cases:
+
+# Use cases
+
+## Persistent Memory as DRAM replacement for memcached
+
+Recent releases of memcached added [support for using Persistent
+Memory](https://memcached.org/blog/persistent-memory/) (PMEM) instead
+of standard DRAM. When deploying memcached through one of the app
+controllers, generic ephemeral volumes make it possible to request a PMEM volume
+of a certain size from a CSI driver like
+[PMEM-CSI](https://intel.github.io/pmem-csi/).
+
+## Local LVM storage as scratch space
+
+Applications working with data sets that exceed the RAM size can
+request local storage with performance characteristics or size that is
+not met by the normal Kubernetes `EmptyDir` volumes. For example,
+[TopoLVM](https://github.com/cybozu-go/topolvm) was written for that
+purpose.
+
+## Read-only access to volumes with data
+
+Provisioning a volume might result in a non-empty volume:
+- [restore a snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)
+- [cloning a volume](/docs/concepts/storage/volume-pvc-datasource)
+- [generic data populators](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20200120-generic-data-populators.md)
+
+Such volumes can be mounted read-only.
+
+# How it works
+
+## Generic ephemeral volumes
+
+The key idea behind generic ephemeral volumes is that a new volume
+source, the so-called
+[`EphemeralVolumeSource`](/docs/reference/generated/kubernetes-api/#ephemeralvolumesource-v1alpha1-core)
+contains all fields that are needed to created a volume claim
+(historically called persistent volume claim, PVC). A new controller
+in the `kube-controller-manager` waits for Pods which embed such a
+volume source and then creates a PVC for that pod. To a CSI driver
+deployment, that PVC looks like any other, so no special support is
+needed.
+
+As long as these PVCs exist, they can be used like any other volume claim. In
+particular, they can be referenced as data source in volume cloning or
+snapshotting. The PVC object also holds the current status of the
+volume.
+
+Naming of the automatically created PVCs is deterministic: the name is
+a combination of Pod name and volume name, with a hyphen (`-`) in the
+middle. This deterministic naming makes it easier to
+interact with the PVC because one does not have to search for it once
+the Pod name and volume name are known. The downside is that the name might
+be in use already. This is detected by Kubernetes and then blocks Pod
+startup.
+
+To ensure that the volume gets deleted together with the pod, the
+controller makes the Pod the owner of the volume claim. When the Pod
+gets deleted, the normal garbage-collection mechanism also removes the
+claim and thus the volume.
+
+Claims select the storage driver through the normal storage class
+mechanism. Although storage classes with both immediate and late
+binding (aka `WaitForFirstConsumer`) are supported, for ephemeral
+volumes it makes more sense to use `WaitForFirstConsumer`: then Pod
+scheduling can take into account both node utilization and
+availability of storage when choosing a node. This is where the other
+new feature comes in.
+
+## Storage capacity tracking
+
+Normally, the Kubernetes scheduler has no information about where a
+CSI driver might be able to create a volume. It also has no way of
+talking directly to a CSI driver to retrieve that information. It
+therefore tries different nodes until it finds one where all volumes
+can be made available (late binding) or leaves it entirely to the
+driver to choose a location (immediate binding).
+
+The new [`CSIStorageCapacity` alpha
+API](/docs/reference/generated/kubernetes-api/v1.19/#csistoragecapacity-v1alpha1-storage-k8s-io)
+allows storing the necessary information in etcd where it is available to the
+scheduler. In contrast to support for generic ephemeral volumes,
+storage capacity tracking must be [enabled when deploying a CSI
+driver](https://github.com/kubernetes-csi/external-provisioner/blob/master/README.md#capacity-support):
+the `external-provisioner` must be told to publish capacity
+information that it then retrieves from the CSI driver through the normal
+`GetCapacity` call.
+<!-- TODO: update the link with a revision once https://github.com/kubernetes-csi/external-provisioner/pull/450 is merged -->
+
+When the Kubernetes scheduler needs to choose a node for a Pod with an
+unbound volume that uses late binding and the CSI driver deployment
+has opted into the feature by setting the [`CSIDriver.storageCapacity`
+flag](/docs/reference/generated/kubernetes-api/v1.19/#csidriver-v1beta1-storage-k8s-io)
+flag, the scheduler automatically filters out nodes that do not have
+access to enough storage capacity. This works for generic ephemeral
+and persistent volumes but *not* for CSI ephemeral volumes because the
+parameters of those are opaque for Kubernetes.
+
+As usual, volumes with immediate binding get created before scheduling
+pods, with their location chosen by the storage driver. Therefore, the
+external-provisioner's default configuration skips storage
+classes with immediate binding as the information wouldn't be used anyway.
+
+Because the Kubernetes scheduler must act on potentially outdated
+information, it cannot be ensured that the capacity is still available
+when a volume is to be created. Still, the chances that it can be created
+without retries should be higher.
+
+# Security
+
+## CSIStorageCapacity
+
+CSIStorageCapacity objects are namespaced. When deploying each CSI
+drivers in its own namespace and, as recommended, limiting the RBAC
+permissions for CSIStorageCapacity to that namespace, it is
+always obvious where the data came from. However, Kubernetes does
+not check that and typically drivers get installed in the same
+namespace anyway, so ultimately drivers are *expected to behave* and
+not publish incorrect data.
+
+## Generic ephemeral volumes
+
+If users have permission to create a Pod (directly or indirectly),
+then they can also create generic ephemeral volumes even when they do
+not have permission to create a volume claim. That's because RBAC
+permission checks are applied to the controller which creates the
+PVC, not the original user. This is a fundamental change that must be
+[taken into
+account](/docs/concepts/storage/ephemeral-volumes#security) before
+enabling the feature in clusters where untrusted users are not
+supposed to have permission to create volumes.
+
+# Example
+
+A [special branch](https://github.com/intel/pmem-csi/commits/kubernetes-1-19-blog-post)
+in PMEM-CSI contains all the necessary changes to bring up a
+Kubernetes 1.19 cluster inside QEMU VMs with both alpha features
+enabled. The PMEM-CSI driver code is used unchanged, only the
+deployment was updated.
+
+On a suitable machine (Linux, non-root user can use Docker - see the
+[QEMU and
+Kubernetes](https://intel.github.io/pmem-csi/0.7/docs/autotest.html#qemu-and-kubernetes)
+section in the PMEM-CSI documentation), the following commands bring
+up a cluster and install the PMEM-CSI driver:
+
+```console
+git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
+cd pmem-csi
+export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
+make start && echo && test/setup-deployment.sh
+```
+
+If all goes well, the output contains the following usage
+instructions:
+
+```
+The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
+kubectl once logged in.  Alternatively, use kubectl directly with the
+following env variable:
+   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config
+
+secret/pmem-csi-registry-secrets created
+secret/pmem-csi-node-secrets created
+serviceaccount/pmem-csi-controller created
+...
+To try out the pmem-csi driver ephemeral volumes:
+   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
+   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
+```
+
+The CSIStorageCapacity objects are not meant to be human-readable, so
+some post-processing is needed. The following Golang template filters
+all objects by the storage class that the example uses and prints the
+name, topology and capacity:
+
+```console
+kubectl get \
+        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
+{{end}}{{end}}' \
+        csistoragecapacities
+```
+
+```
+csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
+csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
+csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
+```
+
+One individual object has the following content:
+
+```console
+kubectl describe csistoragecapacities/csisc-6cw8j
+```
+
+```
+Name:         csisc-sqdnt
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>
+API Version:  storage.k8s.io/v1alpha1
+Capacity:     30716Mi
+Kind:         CSIStorageCapacity
+Metadata:
+  Creation Timestamp:  2020-08-11T15:41:03Z
+  Generate Name:       csisc-
+  Managed Fields:
+    ...
+  Owner References:
+    API Version:     apps/v1
+    Controller:      true
+    Kind:            StatefulSet
+    Name:            pmem-csi-controller
+    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
+  Resource Version:  2994
+  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
+  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
+Node Topology:
+  Match Labels:
+    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
+Storage Class Name:           pmem-csi-sc-late-binding
+Events:                       <none>
+```
+
+Now let's create the example app with one generic ephemeral
+volume. The `pmem-app-ephemeral.yaml` file contains:
+
+```yaml
+# This example Pod definition demonstrates
+# how to use generic ephemeral inline volumes
+# with a PMEM-CSI storage class.
+kind: Pod
+apiVersion: v1
+metadata:
+  name: my-csi-app-inline-volume
+spec:
+  containers:
+    - name: my-frontend
+      image: intel/pmem-csi-driver-test:v0.7.14
+      command: [ "sleep", "100000" ]
+      volumeMounts:
+      - mountPath: "/data"
+        name: my-csi-volume
+  volumes:
+  - name: my-csi-volume
+    ephemeral:
+      volumeClaimTemplate:
+        spec:
+          accessModes:
+          - ReadWriteOnce
+          resources:
+            requests:
+              storage: 4Gi
+          storageClassName: pmem-csi-sc-late-binding
+```
+
+After creating that as shown in the usage instructions above, we have one additional Pod and PVC:
+
+```console
+kubectl get pods/my-csi-app-inline-volume -o wide
+```
+
+```
+NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
+my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
+```
+
+```console
+kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
+```
+
+```
+NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
+my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s
+```
+
+That PVC is owned by the Pod:
+
+```console
+kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
+```
+
+```
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  annotations:
+    pv.kubernetes.io/bind-completed: "yes"
+    pv.kubernetes.io/bound-by-controller: "yes"
+    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
+    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
+  creationTimestamp: "2020-08-11T15:44:57Z"
+  finalizers:
+  - kubernetes.io/pvc-protection
+  managedFields:
+    ...
+  name: my-csi-app-inline-volume-my-csi-volume
+  namespace: default
+  ownerReferences:
+  - apiVersion: v1
+    blockOwnerDeletion: true
+    controller: true
+    kind: Pod
+    name: my-csi-app-inline-volume
+    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
+...
+```
+
+Eventually, the storage capacity information for `pmem-csi-pmem-govm-worker1` also gets updated:
+
+```
+csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
+csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
+csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
+```
+
+If another app needs more than 26620Mi, the Kubernetes
+scheduler will not pick `pmem-csi-pmem-govm-worker1` anymore.
+
+
+# Next steps
+
+Both features are under development. Several open questions were
+already raised during the alpha review process. The two enhancement
+proposals document the work that will be needed for migration to beta and what
+alternatives were already considered and rejected:
+
+* [KEP-1698: generic ephemeral inline
+volumes](https://github.com/kubernetes/enhancements/blob/9d7a75d/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)
+* [KEP-1472: Storage Capacity
+Tracking](https://github.com/kubernetes/enhancements/tree/9d7a75d/keps/sig-storage/1472-storage-capacity-tracking)
+
+Your feedback is crucial for driving that development. SIG-Storage
+[meets
+regularly](https://github.com/kubernetes/community/tree/master/sig-storage#meetings)
+and can be reached via [Slack and a mailing
+list](https://github.com/kubernetes/community/tree/master/sig-storage#contact).
diff --git a/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md b/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md
new file mode 100644
index 0000000000..eebf88a1f1
--- /dev/null
+++ b/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md
@@ -0,0 +1,46 @@
+---
+layout: blog
+title: 'Scaling Kubernetes Networking With EndpointSlices'
+date: 2020-09-02
+slug: scaling-kubernetes-networking-with-endpointslices
+---
+
+**Author:** Rob Scott (Google)
+
+EndpointSlices are an exciting new API that provides a scalable and extensible alternative to the Endpoints API. EndpointSlices track IP addresses, ports, readiness, and topology information for Pods backing a Service.
+
+In Kubernetes 1.19 this feature is enabled by default with kube-proxy reading from [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) instead of Endpoints. Although this will mostly be an invisible change, it should result in noticeable scalability improvements in large clusters. It also enables significant new features in future Kubernetes releases like [Topology Aware Routing](/docs/concepts/services-networking/service-topology/).
+
+## Scalability Limitations of the Endpoints API 
+With the Endpoints API, there was only one Endpoints resource for a Service. That meant that it needed to be able to store IP addresses and ports (network endpoints) for every Pod that was backing the corresponding Service. This resulted in huge API resources. To compound this problem, kube-proxy was running on every node and watching for any updates to Endpoints resources. If even a single network endpoint changed in an Endpoints resource, the whole object would have to be sent to each of those instances of kube-proxy.
+
+A further limitation of the Endpoints API is that it limits the number of network endpoints that can be tracked for a Service. The default size limit for an object stored in etcd is 1.5MB. In some cases that can limit an Endpoints resource to 5,000 Pod IPs. This is not an issue for most users, but it becomes a significant problem for users with Services approaching this size.
+
+To show just how significant these issues become at scale it helps to have a simple example. Think about a Service which has 5,000 Pods, it might end up with a 1.5MB Endpoints resource. If even a single network endpoint in that list changes, the full Endpoints resource will need to be distributed to each Node in the cluster. This becomes quite an issue in a large cluster with 3,000 Nodes. Each update would involve sending 4.5GB of data (1.5MB Endpoints * 3,000 Nodes) across the cluster. That's nearly enough to fill up a DVD, and it would happen for each Endpoints change. Imagine a rolling update that results in all 5,000 Pods being replaced - that's more than 22TB (or 5,000 DVDs) worth of data transferred.
+
+## Splitting endpoints up with the EndpointSlice API
+The EndpointSlice API was designed to address this issue with an approach similar to sharding. Instead of tracking all Pod IPs for a Service with a single Endpoints resource, we split them into multiple smaller EndpointSlices. 
+
+Consider an example where a Service is backed by 15 pods. We'd end up with a single Endpoints resource that tracked all of them. If EndpointSlices were configured to store 5 endpoints each, we'd end up with 3 different EndpointSlices:
+![EndpointSlices](/images/blog/2020-09-02-scaling-kubernetes-networking-endpointslices/endpoint-slices.png)
+
+By default, EndpointSlices  store as many as 100 endpoints each, though this can be configured with the `--max-endpoints-per-slice` flag on kube-controller-manager.
+
+## EndpointSlices provide 10x scalability improvements
+This API dramatically improves networking scalability. Now when a Pod is added or removed, only 1 small EndpointSlice needs to be updated. This difference becomes quite noticeable when hundreds or thousands of Pods are backing a single Service. 
+
+Potentially more significant, now that all Pod IPs for a Service don't need to be stored in a single resource, we don't have to worry about the size limit for objects stored in etcd. EndpointSlices have already been used to scale Services beyond 100,000 network endpoints.
+
+All of this is brought together with some significant performance improvements that have been made in kube-proxy. When using EndpointSlices at scale, significantly less data will be transferred for endpoints updates and kube-proxy should be faster to update iptables or ipvs rules. Beyond that, Services can now scale to at least 10 times beyond any previous limitations.
+
+## EndpointSlices enable new functionality
+Introduced as an alpha feature in Kubernetes v1.16, EndpointSlices were built to enable some exciting new functionality in future Kubernetes releases. This could include dual-stack Services, topology aware routing, and endpoint subsetting.
+
+Dual-Stack Services are an exciting new feature that has been in development alongside EndpointSlices. They will utilize both IPv4 and IPv6 addresses for Services and rely on the addressType field on EndpointSlices to track these addresses by IP family. 
+
+Topology aware routing will update kube-proxy to prefer routing requests within the same zone or region. This makes use of the topology fields stored for each endpoint in an EndpointSlice. As a further refinement of that, we're exploring the potential of endpoint subsetting. This would allow kube-proxy to only watch a subset of EndpointSlices. For example, this might be combined with topology aware routing so that kube-proxy would only need to watch EndpointSlices containing endpoints within the same zone. This would provide another very significant scalability improvement.
+
+## What does this mean for the Endpoints API?
+Although the EndpointSlice API is providing a newer and more scalable alternative to the Endpoints API, the Endpoints API will continue to be considered generally available and stable. The most significant change planned for the Endpoints API will involve beginning to truncate Endpoints that would otherwise run into scalability issues.
+
+The Endpoints API is not going away, but many new features will rely on the EndpointSlice API. To take advantage of the new scalability and functionality that EndpointSlices provide, applications that currently consume Endpoints will likely want to consider supporting EndpointSlices in the future.
diff --git a/content/en/blog/_posts/2020-09-03-warnings/index.md b/content/en/blog/_posts/2020-09-03-warnings/index.md
new file mode 100644
index 0000000000..d88dd8328d
--- /dev/null
+++ b/content/en/blog/_posts/2020-09-03-warnings/index.md
@@ -0,0 +1,333 @@
+---
+layout: blog
+title: "Warning: Helpful Warnings Ahead"
+date: 2020-09-03
+slug: warnings
+---
+
+**Author**: Jordan Liggitt (Google)
+
+As Kubernetes maintainers, we're always looking for ways to improve usability while preserving compatibility.
+As we develop features, triage bugs, and answer support questions, we accumulate information that would be helpful for Kubernetes users to know.
+In the past, sharing that information was limited to out-of-band methods like release notes, announcement emails, documentation, and blog posts.
+Unless someone knew to seek out that information and managed to find it, they would not benefit from it.
+
+In Kubernetes v1.19, we added a feature that allows the Kubernetes API server to
+[send warnings to API clients](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1693-warnings).
+The warning is sent using a [standard `Warning` response header](https://tools.ietf.org/html/rfc7234#section-5.5),
+so it does not change the status code or response body in any way.
+This allows the server to send warnings easily readable by any API client, while remaining compatible with previous client versions.
+
+Warnings are surfaced by `kubectl` v1.19+ in `stderr` output, and by the `k8s.io/client-go` client library v0.19.0+ in log output.
+The `k8s.io/client-go` behavior can be [overridden per-process or per-client](#customize-client-handling).
+
+## Deprecation Warnings
+
+The first way we are using this new capability is to send warnings for use of deprecated APIs.
+
+Kubernetes is a [big, fast-moving project](https://www.cncf.io/cncf-kubernetes-project-journey/#development-velocity).
+Keeping up with the [changes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md#changelog-since-v1180)
+in each release can be daunting, even for people who work on the project full-time. One important type of change is API deprecations.
+As APIs in Kubernetes graduate to GA versions, pre-release API versions are deprecated and eventually removed.
+
+Even though there is an [extended deprecation period](/docs/reference/using-api/deprecation-policy/),
+and deprecations are [included in release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md#deprecation),
+they can still be hard to track. During the deprecation period, the pre-release API remains functional,
+allowing several releases to transition to the stable API version. However, we have found that users often don't even realize
+they are depending on a deprecated API version until they upgrade to the release that stops serving it.
+
+Starting in v1.19, whenever a request is made to a deprecated REST API, a warning is returned along with the API response.
+This warning includes details about the release in which the API will no longer be available, and the replacement API version.
+
+Because the warning originates at the server, and is intercepted at the client level, it works for all kubectl commands,
+including high-level commands like `kubectl apply`, and low-level commands like `kubectl get --raw`:
+
+<img alt="kubectl applying a manifest file, then displaying a warning message 'networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress'."
+     src="kubectl-warnings.png"
+     style="width:637px;max-width:100%;">
+
+This helps people affected by the deprecation to know the request they are making is deprecated,
+how long they have to address the issue, and what API they should use instead.
+This is especially helpful when the user is applying a manifest they didn't create,
+so they have time to reach out to the authors to ask for an updated version.
+
+We also realized that the person *using* a deprecated API is often not the same person responsible for upgrading the cluster,
+so we added two administrator-facing tools to help track use of deprecated APIs and determine when upgrades are safe.
+
+### Metrics 
+
+Starting in Kubernetes v1.19, when a request is made to a deprecated REST API endpoint,
+an `apiserver_requested_deprecated_apis` gauge metric is set to `1` in the kube-apiserver process.
+This metric has labels for the API `group`, `version`, `resource`, and `subresource`,
+and a `removed_version` label that indicates the Kubernetes release in which the API will no longer be served.
+
+This is an example query using `kubectl`, [prom2json](https://github.com/prometheus/prom2json),
+and [jq](https://stedolan.github.io/jq/) to determine which deprecated APIs have been requested
+from the current instance of the API server:
+
+```sh
+kubectl get --raw /metrics | prom2json | jq '
+  .[] | select(.name=="apiserver_requested_deprecated_apis").metrics[].labels
+'
+```
+
+Output:
+
+```json
+{
+  "group": "extensions",
+  "removed_release": "1.22",
+  "resource": "ingresses",
+  "subresource": "",
+  "version": "v1beta1"
+}
+{
+  "group": "rbac.authorization.k8s.io",
+  "removed_release": "1.22",
+  "resource": "clusterroles",
+  "subresource": "",
+  "version": "v1beta1"
+}
+```
+
+This shows the deprecated `extensions/v1beta1` Ingress and `rbac.authorization.k8s.io/v1beta1` ClusterRole APIs
+have been requested on this server, and will be removed in v1.22.
+
+We can join that information with the `apiserver_request_total` metrics to get more details about the requests being made to these APIs:
+
+```sh
+kubectl get --raw /metrics | prom2json | jq '
+  # set $deprecated to a list of deprecated APIs
+  [
+    .[] | 
+    select(.name=="apiserver_requested_deprecated_apis").metrics[].labels |
+    {group,version,resource}
+  ] as $deprecated 
+  
+  |
+  
+  # select apiserver_request_total metrics which are deprecated
+  .[] | select(.name=="apiserver_request_total").metrics[] |
+  select(.labels | {group,version,resource} as $key | $deprecated | index($key))
+'
+```
+
+Output:
+
+```json
+{
+  "labels": {
+    "code": "0",
+    "component": "apiserver",
+    "contentType": "application/vnd.kubernetes.protobuf;stream=watch",
+    "dry_run": "",
+    "group": "extensions",
+    "resource": "ingresses",
+    "scope": "cluster",
+    "subresource": "",
+    "verb": "WATCH",
+    "version": "v1beta1"
+  },
+  "value": "21"
+}
+{
+  "labels": {
+    "code": "200",
+    "component": "apiserver",
+    "contentType": "application/vnd.kubernetes.protobuf",
+    "dry_run": "",
+    "group": "extensions",
+    "resource": "ingresses",
+    "scope": "cluster",
+    "subresource": "",
+    "verb": "LIST",
+    "version": "v1beta1"
+  },
+  "value": "1"
+}
+{
+  "labels": {
+    "code": "200",
+    "component": "apiserver",
+    "contentType": "application/json",
+    "dry_run": "",
+    "group": "rbac.authorization.k8s.io",
+    "resource": "clusterroles",
+    "scope": "cluster",
+    "subresource": "",
+    "verb": "LIST",
+    "version": "v1beta1"
+  },
+  "value": "1"
+}
+```
+
+The output shows that only read requests are being made to these APIs, and the most requests have been made to watch the deprecated Ingress API.
+
+You can also find that information through the following Prometheus query,
+which returns information about requests made to deprecated APIs which will be removed in v1.22:
+
+```promql
+apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource)
+group_right() apiserver_request_total
+```
+
+### Audit Annotations
+
+Metrics are a fast way to check whether deprecated APIs are being used, and at what rate,
+but they don't include enough information to identify particular clients or API objects.
+Starting in Kubernetes v1.19, [audit events](/docs/tasks/debug-application-cluster/audit/)
+for requests to deprecated APIs include an audit annotation of `"k8s.io/deprecated":"true"`.
+Administrators can use those audit events to identify specific clients or objects that need to be updated.
+
+## Custom Resource Definitions
+
+Along with the API server ability to warn about deprecated API use, starting in v1.19, a CustomResourceDefinition can indicate a 
+[particular version of the resource it defines is deprecated](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#version-deprecation).
+When API requests to a deprecated version of a custom resource are made, a warning message is returned, matching the behavior of built-in APIs.
+
+The author of the CustomResourceDefinition can also customize the warning for each version if they want to.
+This allows them to give a pointer to a migration guide or other information if needed.
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+  name: crontabs.example.com
+spec:
+  versions:
+  - name: v1alpha1
+    # This indicates the v1alpha1 version of the custom resource is deprecated.
+    # API requests to this version receive a warning in the server response.
+    deprecated: true
+    # This overrides the default warning returned to clients making v1alpha1 API requests.
+    deprecationWarning: "example.com/v1alpha1 CronTab is deprecated; use example.com/v1 CronTab (see http://example.com/v1alpha1-v1)"
+    ...
+
+  - name: v1beta1
+    # This indicates the v1beta1 version of the custom resource is deprecated.
+    # API requests to this version receive a warning in the server response.
+    # A default warning message is returned for this version.
+    deprecated: true
+    ...
+
+  - name: v1
+    ...
+```
+
+## Admission Webhooks
+
+[Admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers)
+are the primary way to integrate custom policies or validation with Kubernetes.
+Starting in v1.19, admission webhooks can [return warning messages](/docs/reference/access-authn-authz/extensible-admission-controllers/#response)
+that are passed along to the requesting API client. Warnings can be returned with allowed or rejected admission responses.
+
+As an example, to allow a request but warn about a configuration known not to work well, an admission webhook could send this response:
+
+```json
+{
+  "apiVersion": "admission.k8s.io/v1",
+  "kind": "AdmissionReview",
+  "response": {
+    "uid": "<value from request.uid>",
+    "allowed": true,
+    "warnings": [
+      ".spec.memory: requests >1GB do not work on Fridays"
+    ]
+  }
+}
+```
+
+If you are implementing a webhook that returns a warning message, here are some tips:
+
+* Don't include a "Warning:" prefix in the message (that is added by clients on output)
+* Use warning messages to describe problems the client making the API request should correct or be aware of
+* Be brief; limit warnings to 120 characters if possible
+
+There are many ways admission webhooks could use this new feature, and I'm looking forward to seeing what people come up with.
+Here are a couple ideas to get you started:
+
+* webhook implementations adding a "complain" mode, where they return warnings instead of rejections,
+  to allow trying out a policy to verify it is working as expected before starting to enforce it
+* "lint" or "vet"-style webhooks, inspecting objects and surfacing warnings when best practices are not followed
+
+## Customize Client Handling
+
+Applications that use the `k8s.io/client-go` library to make API requests can customize
+how warnings returned from the server are handled. By default, warnings are logged to
+stderr as they are received, but this behavior can be customized 
+[per-process](https://godoc.org/k8s.io/client-go/rest#SetDefaultWarningHandler)
+or [per-client](https://godoc.org/k8s.io/client-go/rest#Config).
+
+This example shows how to make your application behave like `kubectl`,
+overriding message handling process-wide to deduplicate warnings 
+and highlighting messages using colored output where supported:
+
+```go
+import (
+  "os"
+  "k8s.io/client-go/rest"
+  "k8s.io/kubectl/pkg/util/term"
+  ...
+)
+
+func main() {
+  rest.SetDefaultWarningHandler(
+    rest.NewWarningWriter(os.Stderr, rest.WarningWriterOptions{
+        // only print a given warning the first time we receive it
+        Deduplicate: true,
+        // highlight the output with color when the output supports it
+        Color: term.AllowsColorOutput(os.Stderr),
+      },
+    ),
+  )
+
+  ...
+```
+
+The next example shows how to construct a client that ignores warnings.
+This is useful for clients that operate on metadata for all resource types
+(found dynamically at runtime using the discovery API)
+and do not benefit from warnings about a particular resource being deprecated.
+Suppressing deprecation warnings is not recommended for clients that require use of particular APIs.
+
+```go
+import (
+  "k8s.io/client-go/rest"
+  "k8s.io/client-go/kubernetes"
+)
+
+func getClientWithoutWarnings(config *rest.Config) (kubernetes.Interface, error) {
+  // copy to avoid mutating the passed-in config
+  config = rest.CopyConfig(config)
+  // set the warning handler for this client to ignore warnings
+  config.WarningHandler = rest.NoWarnings{}
+  // construct and return the client
+  return kubernetes.NewForConfig(config)
+}
+```
+
+## Kubectl Strict Mode
+
+If you want to be sure you notice deprecations as soon as possible and get a jump start on addressing them,
+`kubectl` added a `--warnings-as-errors` option in v1.19. When invoked with this option,
+`kubectl` treats any warnings it receives from the server as errors and exits with a non-zero exit code:
+
+<img alt="kubectl applying a manifest file with a --warnings-as-errors flag, displaying a warning message and exiting with a non-zero exit code."
+     src="kubectl-warnings-as-errors.png"
+     style="width:637px;max-width:100%;">
+
+This could be used in a CI job to apply manifests to a current server,
+and required to pass with a zero exit code in order for the CI job to succeed.
+
+## Future Possibilities
+
+Now that we have a way to communicate helpful information to users in context,
+we're already considering other ways we can use this to improve people's experience with Kubernetes.
+A couple areas we're looking at next are warning about [known problematic values](http://issue.k8s.io/64841#issuecomment-395141013)
+we cannot reject outright for compatibility reasons, and warning about use of deprecated fields or field values
+(like selectors using beta os/arch node labels, [deprecated in v1.14](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-arch-deprecated)).
+I'm excited to see progress in this area, continuing to make it easier to use Kubernetes.
+
+---
+
+_[Jordan Liggitt](https://twitter.com/liggitt) is a software engineer at Google, and helps lead Kubernetes authentication, authorization, and API efforts._
\ No newline at end of file
diff --git a/content/en/blog/_posts/2020-09-03-warnings/kubectl-warnings-as-errors.png b/content/en/blog/_posts/2020-09-03-warnings/kubectl-warnings-as-errors.png
new file mode 100644
index 0000000000..5171eca6bc
Binary files /dev/null and b/content/en/blog/_posts/2020-09-03-warnings/kubectl-warnings-as-errors.png differ
diff --git a/content/en/blog/_posts/2020-09-03-warnings/kubectl-warnings.png b/content/en/blog/_posts/2020-09-03-warnings/kubectl-warnings.png
new file mode 100644
index 0000000000..967bc591bf
Binary files /dev/null and b/content/en/blog/_posts/2020-09-03-warnings/kubectl-warnings.png differ
diff --git a/content/en/blog/_posts/2020-09-04-introducing-structured-logs.md b/content/en/blog/_posts/2020-09-04-introducing-structured-logs.md
new file mode 100644
index 0000000000..e466711aa4
--- /dev/null
+++ b/content/en/blog/_posts/2020-09-04-introducing-structured-logs.md
@@ -0,0 +1,56 @@
+---
+layout: blog
+title: 'Introducing Structured Logs'
+date: 2020-09-04
+slug: kubernetes-1-19-Introducing-Structured-Logs
+---
+
+**Authors:** Marek Siarkowicz (Google), Nathan Beach (Google)
+
+Logs are an essential aspect of observability and a critical tool for debugging. But Kubernetes logs have traditionally been unstructured strings, making any automated parsing difficult and any downstream processing, analysis, or querying challenging to do reliably.
+
+In Kubernetes 1.19, we are adding support for structured logs, which natively support (key, value) pairs and object references. We have also updated many logging calls such that over 99% of logging volume in a typical deployment are now migrated to the structured format.
+
+To maintain backwards compatibility, structured logs will still be outputted as a string where the string contains representations of those "key"="value" pairs. Starting in alpha in 1.19, logs can also be outputted in JSON format using the `--logging-format=json` flag.
+
+## Using Structured Logs
+
+We've added two new methods to the klog library: InfoS and ErrorS. For example, this invocation of InfoS:
+
+```golang
+klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", status)
+```
+
+will result in this log:
+
+```
+I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
+```
+
+Or, if the --logging-format=json flag is set, it will result in this output:
+
+```json
+{
+  "ts": 1580306777.04728,
+  "msg": "Pod status updated",
+  "pod": {
+    "name": "coredns",
+    "namespace": "kube-system"
+  },
+  "status": "ready"
+}
+```
+
+This means downstream logging tools can easily ingest structured logging data and instead of using regular expressions to parse unstructured strings. This also makes processing logs easier, querying logs more robust, and analyzing logs much faster.
+
+With structured logs, all references to Kubernetes objects are structured the same way, so you can filter the output and only log entries referencing the particular pod. You can also find logs indicating how the scheduler was scheduling the pod, how the pod was created, the health probes of the pod, and all other changes in the lifecycle of the pod.
+
+Suppose you are debugging an issue with a pod. With structured logs, you can filter to only those log entries referencing the pod of interest, rather than needing to scan through potentially thousands of log lines to find the relevant ones.
+
+Not only are structured logs more useful when manual debugging of issues, they also enable richer features like automated pattern recognition within logs or tighter correlation of log and trace data.
+
+Finally, structured logs can help reduce storage costs for logs because most storage systems are more efficiently able to compress structured key=value data than unstructured strings.
+
+## Get Involved
+
+While we have updated over 99% of the log entries by log volume in a typical deployment, there are still thousands of logs to be updated. Pick a file or directory that you would like to improve and [migrate existing log calls to use structured logs](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md). It's a great and easy way to make your first contribution to Kubernetes!
diff --git a/content/en/blog/_posts/2020-09-16-gsoc‘20 -building-operators-for-cluster-addons.md b/content/en/blog/_posts/2020-09-16-gsoc‘20 -building-operators-for-cluster-addons.md
new file mode 100644
index 0000000000..377fb5fbff
--- /dev/null
+++ b/content/en/blog/_posts/2020-09-16-gsoc‘20 -building-operators-for-cluster-addons.md	
@@ -0,0 +1,118 @@
+---
+layout: blog
+title: "GSoC 2020 - Building operators for cluster addons"
+date: 2020-09-16
+slug: gsoc20-building-operators-for-cluster-addons
+---
+
+**Author**: Somtochi Onyekwere
+
+# Introduction
+
+[Google Summer of Code](https://summerofcode.withgoogle.com/) is a global program that is geared towards introducing students to open source. Students are matched with open-source organizations to work with them for three months during the summer.
+
+My name is Somtochi Onyekwere from the Federal University of Technology, Owerri (Nigeria) and this year, I was given the opportunity to work with Kubernetes (under the CNCF organization) and this led to an amazing summer spent learning, contributing and interacting with the community.
+
+Specifically, I worked on the _Cluster Addons: Package all the things!_ project. The project focused on building operators for better management of various cluster addons, extending the tooling for building these operators and making the creation of these operators a smooth process.
+
+# Background
+
+Kubernetes has progressed greatly in the past few years with a flourishing community and a large number of contributors. The codebase is gradually moving away from the monolith structure where all the code resides in the [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository to being split into multiple sub-projects. Part of the focus of cluster-addons is to make some of these sub-projects work together in an easy to assemble, self-monitoring, self-healing and Kubernetes-native way. It enables them to work seamlessly without human intervention.
+
+The community is exploring the use of operators as a mechanism to monitor various resources in the cluster and properly manage these resources. In addition to this, it provides self-healing and it is a kubernetes-native pattern that can encode how best these addons work and manage them properly.
+
+What are cluster addons? Cluster addons are a collection of resources (like Services and deployment) that are used to give a Kubernetes cluster additional functionalities. They range from things as simple as the Kubernetes dashboards (for visualization) to more complex ones like Calico (for networking). These addons are essential to different applications running in the cluster and the cluster itself. The addon operator provides a nicer way of managing these addons and understanding the health and status of the various resources that comprise the addon. You can get a deeper overview in this [article](https://kubernetes.io/docs/concepts/overview/components/#addons).
+
+Operators are custom controllers with custom resource definitions that encode application-specific knowledge and are used for managing complex stateful applications. It is a widely accepted pattern. Managing addons via operators, with these operators encoding knowledge of how best the addons work, introduces a lot of advantages while setting standards that will be easy to follow and scale. This [article](https://kubernetes.io/docs/concepts/extend-kubernetes/operator) does a good job of explaining operators.
+
+The addon operators can solve a lot of problems, but they have their challenges. Those under the [cluster-addons project](https://github.com/kubernetes-sigs/cluster-addons) had missing pieces and were still a proof of concept. Generating the RBAC configuration for the operators was a pain and sometimes the operators were given too much privilege. The operators weren’t very extensible as it only pulled manifests from local filesystems or HTTP(s) servers and a lot of simple addons were generating the same code.
+I spent the summer working on these issues, looking at them with fresh eyes and coming up with solutions for both the known and unknown issues.
+
+# Various additions to kubebuilder-declarative-pattern
+
+The [kubebuilder-declarative-pattern](https://github.com/kubernetes-sigs/kubebuilder-declarative-pattern) (from here on referred to as KDP) repo is an extra layer of addon specific tooling on top of the [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) SDK that is enabled by passing the experimental `--pattern=addon` flag to `kubebuilder create` command. Together, they create the base code for the addon operator. During the internship, I worked on a couple of features in KDP and cluster-addons.
+
+## Operator version checking
+Enabling version checks for operators helped in making upgrades/downgrades safer to different versions of the addon, even though the operator had complex logic. It is a way of matching the version of an addon to the version of the operator that knows how to manage it well. Most addons have different versions and these versions might need to be managed differently. This feature checks the custom resource for the `addons.k8s.io/min-operator-version` annotation which states the minimum operator version that is needed to manage the version against the version of the operator. If the operator version is below the minimum version required, the operator pauses with an error telling the user that the version of the operator is too low. This helps to ensure that the correct operator is being used for the addon.
+
+## Git repository for storing the manifests
+Previously, there was support for only local file directories and HTTPS repositories for storing manifests. Giving creators of addon operators the ability to store manifest in GitHub repository enables faster development and version control.  When starting the controller, you can pass a flag to specify the location of your channels directory. The channels directory contains the manifests for different versions, the controller pulls the manifest from this directory and applies it to the cluster. During the internship period, I extended it to include Git repositories.
+
+## Annotations to temporarily disable reconciliation
+The reconciliation loop that ensures that the desired state matches the actual state prevents modification of objects in the cluster. This makes it hard to experiment or investigate what might be wrong in the cluster as any changes made are promptly reverted. I resolved this by allowing users to place an `addons.k8s.io/ignore` annotation on the resource that they don’t want the controller to reconcile. The controller checks for this annotation and doesn’t reconcile that object. To resume reconciliation, the annotation can be removed from the resource.
+
+## Unstructured support in kubebuilder-declarative-pattern
+One of the operators that I worked on is a generic controller that could manage more than one cluster addon that did not require extra configuration. To do this, the operator couldn’t use a particular type and needed the kubebuilder-declarative-repo to support using the [unstructured.Unstructured](https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured#Unstructured) type. There were various functions in the kubebuilder-declarative-pattern that couldn’t handle this type and returned an error if the object passed in was not of type `addonsv1alpha1.CommonObject`. The functions were modified to handle both `unstructured.Unstructured` and `addonsv1alpha.CommonObject`.
+
+# Tools and CLI programs
+There were also some command-line programs I wrote that could be used to make working with addon operators easier. Most of them have uses outside the addon operators as they try to solve a specific problem that could surface anywhere while working with Kubernetes. I encourage you to [check them out](https://github.com/kubernetes-sigs/cluster-addons/tree/master/tools) when you have the chance!
+
+## RBAC Generator
+One of the biggest concerns with the operator was RBAC. You had to manually look through the manifest and add the RBAC rule for each resource as it needs to have RBAC permissions to create, get, update and delete the resources in the manifest when running in-cluster. Building the [RBAC generator](https://github.com/kubernetes-sigs/cluster-addons/blob/master/tools/rbac-gen) automated the process of writing the RBAC roles and role bindings. The function of the RBAC generator is simple. It accepts the file name of the manifest as a flag. Then, it parses the manifest and gets the API group and resource name of the resources and adds it to a role. It outputs the role and role binding to stdout or a file if the `--out` flag is parsed.
+
+Additionally, the tool enables you to split the RBAC by separating the cluster roles in the manifest. This lessened the security concern of an operator being over-privileged as it needed to have all the permissions that the clusterrole has. If you want to apply the clusterrole yourself and not give the operator these permissions, you can pass in a `--supervisory` boolean flag so that the generator does not add these permissions to the role. The CLI program resides [here](https://github.com/kubernetes-sigs/cluster-addons/blob/master/tools/rbac-gen).
+
+## Kubectl Ownerref
+It is hard to find out at a glance which objects were created by an addon custom resource. This kubectl plugin alleviates that pain by displaying all the objects in the cluster that a resource has ownerrefs on. You simply pass the kind and the name of the resource as arguments to the program and it checks the cluster for the objects and gives the kind, name, the namespace of such an object. It could be useful to get a general overview of all the objects that the controller is reconciling by passing in the name and kind of custom resource. The CLI program resides [here](https://github.com/kubernetes-sigs/cluster-addons/tree/master/tools/kubectl-ownerref).
+
+# Addon Operators
+To fully understand addons operators and make changes to how they are being created, you have to try creating and using them. Part of the summer was spent building operators for some popular addons like the Kubernetes dashboard, flannel, NodeLocalDNS and so on. Please check the [cluster-addons](https://github.com/kubernetes-sigs/cluster-addons) repository for the different addon operators. In this section, I will just highlight one that is a little different from the others.
+
+## Generic Controller
+The generic controller can be shared between addons that don’t require much configuration. This minimizes resource consumption on the cluster as it reduces the number of controllers that need to be run. Also instead of building your own operator, you can just use the generic controller and whenever you feel that your needs have grown and you need a more complex operator, you can always scaffold the code with kubebuilder and continue from where the generic operator stopped. To use the generic controller, you can generate the CustomResourceDefinition(CRD) using this tool ([generic-addon](https://github.com/kubernetes-sigs/cluster-addons/blob/master/tools/generic-addon/README.md)). You pass in the kind, group, and the location of your channels directory (it could be a Git repository too!). The tool generates the - CRD, RBAC manifest and two custom resources for you.
+
+The process is as follows:
+- Create the Generic CRD
+- Generate all the manifests needed with the [`generic-addon tool`](https://github.com/kubernetes-sigs/cluster-addons/blob/master/tools/generic-addon/README.md).
+
+This tool creates:
+1. The CRD for your addon
+2. The RBAC rules for the CustomResourceDefinitions
+3. The RBAC rules for applying the manifests
+4. The custom resource for your addon
+5. A Generic custom resource
+
+The Generic custom resource looks like this:
+
+```yaml
+apiVersion: addons.x-k8s.io/v1alpha1
+kind: Generic
+metadata:
+ 	name: generic-sample
+spec:
+  objectKind:
+  kind: NodeLocalDNS
+  version: "v1alpha1"
+  group: addons.x-k8s.io
+channel: "../nodelocaldns/channels"
+```
+
+Apply these manifests but ensure to apply the CRD before the CR.
+Then, run the Generic controller, either on your machine or in-cluster.
+
+
+If you are interested in building an operator, Please check out [this guide](https://github.com/kubernetes-sigs/cluster-addons/blob/master/dashboard/README.md).
+
+# Relevant Links
+- [Detailed breakdown of work done during the internship](https://github.com/SomtochiAma/gsoc-2020-meta-k8s)
+- [Addon Operator (KEP)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/addons/0035-20190128-addons-via-operators.md)
+- [Original GSoC Issue](https://github.com/kubernetes-sigs/cluster-addons/issues/39)
+- [Proposal Submitted for GSoC](https://github.com/SomtochiAma/gsoc-2020-meta-k8s/blob/master/GSoC%202020%20PROPOSAL%20-%20PACKAGE%20ALL%20THINGS.pdf)
+- [All commits to kubernetes-sigs/cluster-addons](https://github.com/kubernetes-sigs/cluster-addons/commits?author=SomtochiAma)
+- [All commits to kubernetes-sigs/kubebuidler-declarative-pattern](https://github.com/kubernetes-sigs/kubebuilder-declarative-pattern/commits?author=SomtochiAma)
+
+# Further Work
+A lot of work was definitely done on the cluster addons during the GSoC period. But we need more people building operators and using them in the cluster. We need wider adoption in the community. Build operators for your favourite addons and tell us how it went and if you had any issues. Check out this [README.md](https://github.com/kubernetes-sigs/cluster-addons/blob/master/dashboard/README.md) to get started.
+
+# Appreciation
+I really want to appreciate my mentors [Justin Santa Barbara](https://github.com/justinsb) (Google) and [Leigh Capili](https://github.com/stealthybox) (Weaveworks). My internship was awesome because they were awesome. They set a golden standard for what mentorship should be. They were accessible and always available to clear any confusion. I think what I liked best was that they didn’t just dish out tasks, instead, we had open discussions about what was wrong and what could be improved. They are really the best and I hope I get to work with them again!
+  Also, I want to say a huge thanks to [Lubomir I. Ivanov](https://github.com/neolit123) for reviewing this blog post!
+
+# Conclusion
+So far I have learnt a lot about Go, the internals of Kubernetes, and operators. I want to conclude by encouraging people to contribute to open-source (especially Kubernetes :)) regardless of your level of experience. It has been a well-rounded experience for me and I have come to love the community. It is a great initiative and it is a great way to learn and meet awesome people. Special shoutout to Google for organizing this program.
+
+If you are interested in cluster addons and finding out more on addon operators, you are welcome to join our slack channel on the Kubernetes [#cluster-addons](https://kubernetes.slack.com/messages/cluster-addons).
+
+---
+
+_[Somtochi Onyekwere](https://twitter.com/SomtochiAma) is a software engineer that loves contributing to open-source and exploring cloud native solutions._
diff --git a/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/index.md b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/index.md
new file mode 100644
index 0000000000..5c2940c1a7
--- /dev/null
+++ b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/index.md
@@ -0,0 +1,107 @@
+---
+title: "Contributing to the Development Guide"
+linkTitle: "Contributing to the Development Guide"
+Author: Erik L. Arneson
+Description: "A new contributor describes the experience of writing and submitting changes to the Kubernetes Development Guide."
+date: 2020-10-01
+canonicalUrl: https://www.kubernetes.dev/blog/2020/09/28/contributing-to-the-development-guide/
+resources:
+- src: "jorge-castro-code-of-conduct.jpg"
+  title: "Jorge Castro announcing the Kubernetes Code of Conduct during a weekly SIG ContribEx meeting."
+---
+
+When most people think of contributing to an open source project, I suspect they probably think of
+contributing code changes, new features, and bug fixes. As a software engineer and a long-time open
+source user and contributor, that's certainly what I thought. Although I have written a good quantity
+of documentation in different workflows, the massive size of the Kubernetes community was a new kind 
+of "client." I just didn't know what to expect when Google asked my compatriots and me at
+[Lion's Way](https://lionswaycontent.com/) to make much-needed updates to the Kubernetes Development Guide.
+
+*This article originally appeared on the [Kubernetes Contributor Community blog](https://www.kubernetes.dev/blog/2020/09/28/contributing-to-the-development-guide/).*
+
+## The Delights of Working With a Community
+
+As professional writers, we are used to being hired to write very specific pieces. We specialize in
+marketing, training, and documentation for technical services and products, which can range anywhere from relatively fluffy marketing emails to deeply technical white papers targeted at IT and developers. With 
+this kind of professional service, every deliverable tends to have a measurable return on investment. 
+I knew this metric wouldn't be present when working on open source documentation, but I couldn't
+predict how it would change my relationship with the project.
+
+One of the primary traits of the relationship between our writing and our traditional clients is that we
+always have one or two primary points of contact inside a company. These contacts are responsible
+for reviewing our writing and making sure it matches the voice of the company and targets the
+audience they're looking for. It can be stressful -- which is why I'm so glad that my writing
+partner, eagle-eyed reviewer, and bloodthirsty editor [Joel](https://twitter.com/JoelByronBarker)
+handles most of the client contact.
+
+I was surprised and delighted that all of the stress of client contact went out the window when
+working with the Kubernetes community.
+
+"How delicate do I have to be? What if I screw up? What if I make a developer angry? What if I make
+enemies?" These were all questions that raced through my mind and made me feel like I was
+approaching a field of eggshells when I first joined the `#sig-contribex` channel on the Kubernetes
+Slack and announced that I would be working on the
+[Development Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md).
+
+{{< imgproc jorge-castro-code-of-conduct Fit "800x450" >}}
+"The Kubernetes Code of Conduct is in effect, so please be excellent to each other." &mdash; Jorge
+Castro, SIG ContribEx co-chair
+{{< /imgproc >}}
+
+My fears were unfounded. Immediately, I felt welcome. I like to think this isn't just because I was
+working on a much needed task, but rather because the Kubernetes community is filled
+with friendly, welcoming people. During the weekly SIG ContribEx meetings, our reports on progress
+with the Development Guide were included immediately. In addition, the leader of the meeting would
+always stress that the [Kubernetes Code of Conduct](https://www.kubernetes.dev/resources/code-of-conduct/) was in
+effect, and that we should, like Bill and Ted, be excellent to each other.
+
+## This Doesn't Mean It's All Easy
+
+The Development Guide needed a pretty serious overhaul. When we got our hands on it, it was already
+packed with information and lots of steps for new developers to go through, but it was getting dusty
+with age and neglect. Documentation can really require a global look, not just point fixes.
+As a result, I ended up submitting a gargantuan pull request to the
+[Community repo](https://github.com/kubernetes/community): 267 additions and 88 deletions.
+
+The life cycle of a pull request requires a certain number of Kubernetes organization members to review and approve changes
+before they can be merged. This is a great practice, as it keeps both documentation and code in
+pretty good shape, but it can be tough to cajole the right people into taking the time for such a hefty
+review. As a result, that massive PR took 26 days from my first submission to final merge. But in
+the end, [it was successful](https://github.com/kubernetes/community/pull/5003).
+
+Since Kubernetes is a pretty fast-moving project, and since developers typically aren't really
+excited about writing documentation, I also ran into the problem that sometimes, the secret jewels
+that describe the workings of a Kubernetes subsystem are buried deep within the [labyrinthine mind of
+a brilliant engineer](https://github.com/amwat), and not in plain English in a Markdown file. I ran headlong into this issue
+when it came time to update the getting started documentation for end-to-end (e2e) testing. 
+
+This portion of my journey took me out of documentation-writing territory and into the role of a
+brand new user of some unfinished software. I ended up working with one of the developers of the new
+[`kubetest2` framework](https://github.com/kubernetes-sigs/kubetest2) to document the latest process of
+getting up-and-running for e2e testing, but it required a lot of head scratching on my part. You can
+judge the results for yourself by checking out my
+[completed pull request](https://github.com/kubernetes/community/pull/5045).
+
+## Nobody Is the Boss, and Everybody Gives Feedback
+
+But while I secretly expected chaos, the process of contributing to the Kubernetes Development Guide
+and interacting with the amazing Kubernetes community went incredibly smoothly. There was no
+contention. I made no enemies. Everybody was incredibly friendly and welcoming. It was *enjoyable*.
+
+With an open source project, there is no one boss. The Kubernetes project, which approaches being
+gargantuan, is split into many different special interest groups (SIGs), working groups, and
+communities. Each has its own regularly scheduled meetings, assigned duties, and elected
+chairpersons. My work intersected with the efforts of both SIG ContribEx (who watch over and seek to
+improve the contributor experience) and SIG Testing (who are in charge of testing). Both of these
+SIGs proved easy to work with, eager for contributions, and populated with incredibly friendly and
+welcoming people.
+
+In an active, living project like Kubernetes, documentation continues to need maintenance, revision,
+and testing alongside the code base. The Development Guide will continue to be crucial to onboarding
+new contributors to the Kubernetes code base, and as our efforts have shown, it is important that
+this guide keeps pace with the evolution of the Kubernetes project.
+
+Joel and I really enjoy interacting with the Kubernetes community and contributing to
+the Development Guide. I really look forward to continuing to not only contributing more, but to
+continuing to build the new friendships I've made in this vast open source community over the past
+few months.
diff --git a/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/jorge-castro-code-of-conduct.jpg b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/jorge-castro-code-of-conduct.jpg
new file mode 100644
index 0000000000..aeea042a7a
Binary files /dev/null and b/content/en/blog/_posts/2020-10-01-contributing-to-the-development-guide/jorge-castro-code-of-conduct.jpg differ
diff --git a/content/en/blog/_posts/2020-10-12-steering-committee-results.md b/content/en/blog/_posts/2020-10-12-steering-committee-results.md
new file mode 100644
index 0000000000..2acbb6d6e4
--- /dev/null
+++ b/content/en/blog/_posts/2020-10-12-steering-committee-results.md
@@ -0,0 +1,43 @@
+---
+layout: blog
+title: "Announcing the 2020 Steering Committee Election Results"
+date: 2020-10-12
+slug: steering-committee-results-2020
+---
+
+**Author**: Kaslin Fields
+
+The [2020 Steering Committee Election](https://github.com/kubernetes/community/tree/master/events/elections/2020) is now complete. In 2019, the committee arrived at its final allocation of 7 seats, 3 of which were up for election in 2020. Incoming committee members serve a term of 2 years, and all members are elected by the Kubernetes Community.
+
+This community body is significant since it oversees the governance of the entire Kubernetes project. With that great power comes great responsibility. You can learn more about the steering committee’s role in their [charter](https://github.com/kubernetes/steering/blob/master/charter.md).
+
+## Results
+
+Congratulations to the elected committee members whose two year terms begin immediately (listed in alphabetical order by GitHub handle):
+
+* **Davanum Srinivas ([@dims](https://github.com/dims)), VMware**
+* **Jordan Liggitt ([@liggitt](https://github.com/liggitt)), Google**
+* **Bob Killen ([@mrbobbytables](https://github.com/mrbobbytables)), Google**
+
+They join continuing members Christoph Blecker ([@cblecker](https://github.com/cblecker)), Red Hat; Derek Carr ([@derekwaynecarr](https://github.com/derekwaynecarr)), Red Hat; Nikhita Raghunath ([@nikhita](https://github.com/nikhita)), VMware; and Paris Pittman ([@parispittman](https://github.com/parispittman)), Apple. Davanum Srinivas is returning for his second term on the committee.
+
+## Big Thanks!
+
+* Thank you and congratulations on a successful election to this round’s election officers:
+  * Jaice Singer DuMars ([@jdumars](https://github.com/jdumars)), Apple
+  * Ihor Dvoretskyi ([@idvoretskyi](https://github.com/idvoretskyi)), CNCF
+  * Josh Berkus ([@jberkus](https://github.com/jberkus)), Red Hat
+* Thanks to the Emeritus Steering Committee Members. Your prior service is appreciated by the community:
+  * Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)), Google
+  * and Lachlan Evenson([@lachie8e)](https://github.com/lachie8e)), Microsoft
+* And thank you to all the candidates who came forward to run for election. As [Jorge Castro put it](https://twitter.com/castrojo/status/1315718627639820288?s=20): we are spoiled with capable, kind, and selfless volunteers who put the needs of the project first.
+
+## Get Involved with the Steering Committee
+
+This governing body, like all of Kubernetes, is open to all. You can follow along with Steering Committee [backlog items](https://github.com/kubernetes/steering/projects/1) and weigh in by filing an issue or creating a PR against their [repo](https://github.com/kubernetes/steering). They have an open meeting on [the first Monday of the month at 6pm UTC](https://github.com/kubernetes/steering) and regularly attend Meet Our Contributors. They can also be contacted at their public mailing list steering@kubernetes.io.
+
+You can see what the Steering Committee meetings are all about by watching past meetings on the [YouTube Playlist](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM).
+
+----
+
+_This post was written by the [Upstream Marketing Working Group](https://github.com/kubernetes/community/tree/master/communication/marketing-team#contributor-marketing). If you want to write stories about the Kubernetes community, learn more about us._
diff --git a/content/en/blog/_posts/2020-11-02-remembering-dan-kohn.md b/content/en/blog/_posts/2020-11-02-remembering-dan-kohn.md
new file mode 100644
index 0000000000..b8ffb8686a
--- /dev/null
+++ b/content/en/blog/_posts/2020-11-02-remembering-dan-kohn.md
@@ -0,0 +1,16 @@
+---
+layout: blog
+title: "Remembering Dan Kohn"
+date: 2020-11-02
+slug: remembering-dan-kohn
+---
+
+**Author**: The Kubernetes Steering Committee
+
+Dan Kohn was instrumental in getting Kubernetes and CNCF community to where it is today. He shared our values, motivations, enthusiasm, community spirit, and helped the Kubernetes community to become the best that it could be. Dan loved getting people together to solve problems big and small. He enabled people to grow their individual scope in the community which often helped launch their career in open source software.
+
+Dan built a coalition around the nascent Kubernetes project and turned that into a cornerstone to build the larger cloud native space. He loved challenges, especially ones where the payoff was great like building worldwide communities, spreading the love of open source, and helping diverse, underprivileged communities and students to get a head start in technology.
+
+Our heart goes out to his family. Thank you, Dan, for bringing your boys to events in India and elsewhere as we got to know how great you were as a father. Dan, your thoughts and ideas will help us make progress in our journey as a community. Thank you for your life's work!
+
+If Dan has made an impact on you in some way, please consider adding a memory of him in his [CNCF memorial](https://github.com/cncf/memorials/blob/master/dan-kohn.md).
diff --git a/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/cloud-native-app-lifecycle-phases.svg b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/cloud-native-app-lifecycle-phases.svg
new file mode 100644
index 0000000000..8ae1c26c57
--- /dev/null
+++ b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/cloud-native-app-lifecycle-phases.svg
@@ -0,0 +1 @@
+<svg version="1.1" viewBox="440.0 180.0 2020.0 1140.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"><clipPath id="g962b052c40_4_0.0"><path d="m0 0l2560.0 0l0 1440.0l-2560.0 0l0 -1440.0z" clip-rule="nonzero"/></clipPath><g clip-path="url(#g962b052c40_4_0.0)"><path fill="#ffffff" d="m0 0l2560.0 0l0 1440.0l-2560.0 0z" fill-rule="evenodd"/><path fill="#e7e6e6" d="m451.36877 216.14076l1657.2626 0l0 749.58l-1657.2626 0z" fill-rule="evenodd"/><path fill="#ffdccd" fill-opacity="0.698" d="m504.60275 281.3547l767.22 0l0 908.5388l-767.22 0z" fill-rule="evenodd"/><path fill="#023850" d="m1271.0511 281.3529l235.55005 0l0 545.13l-235.55005 0z" fill-rule="evenodd"/><path fill="#0792b9" d="m1505.6777 281.3529l235.55005 0l0 545.13l-235.55005 0z" fill-rule="evenodd"/><path fill="#00ad97" d="m1740.9767 281.3529l235.55005 0l0 545.13l-235.55005 0z" fill-rule="evenodd"/><path fill="#f15a29" d="m555.0702 322.5303l666.27 0l0 170.43735l-666.27 0z" fill-rule="evenodd"/><path fill="#f15a29" d="m554.7341 539.67755l311.26245 0l0 279.29504l-311.26245 0z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m556.4151 714.1349l309.29132 0l0 69.88977l-309.29132 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m646.46497 747.29553q-5.46875 -1.578125 -7.96875 -3.859375q-2.484375 -2.296875 -2.484375 -5.65625q0 -3.8125 3.046875 -6.296875q3.046875 -2.5 7.921875 -2.5q3.3125 0 5.90625 1.296875q2.609375 1.28125 4.03125 3.546875q1.4375 2.25 1.4375 4.921875l-4.28125 0q0 -2.921875 -1.859375 -4.59375q-1.859375 -1.671875 -5.234375 -1.671875q-3.140625 0 -4.90625 1.390625q-1.765625 1.375 -1.765625 3.828125q0 1.96875 1.671875 3.34375q1.671875 1.359375 5.6875 2.484375q4.015625 1.125 6.28125 2.484375q2.28125 1.359375 3.375 3.1875q1.09375 1.8125 1.09375 4.265625q0 3.921875 -3.0625 6.28125q-3.046875 2.34375 -8.15625 2.34375q-3.328125 0 -6.203125 -1.265625q-2.875 -1.28125 -4.4375 -3.484375q-1.5625 -2.21875 -1.5625 -5.03125l4.28125 0q0 2.921875 2.15625 4.625q2.15625 1.6875 5.765625 1.6875q3.359375 0 5.15625 -1.375q1.796875 -1.375 1.796875 -3.734375q0 -2.375 -1.671875 -3.671875q-1.65625 -1.296875 -6.015625 -2.546875zm22.313293 -15.390625l0 5.796875l4.46875 0l0 3.171875l-4.46875 0l0 14.84375q0 1.4375 0.59375 2.171875q0.59375 0.71875 2.03125 0.71875q0.71875 0 1.953125 -0.265625l0 3.3125q-1.609375 0.4375 -3.140625 0.4375q-2.75 0 -4.140625 -1.65625q-1.390625 -1.65625 -1.390625 -4.71875l0 -14.84375l-4.359375 0l0 -3.171875l4.359375 0l0 -5.796875l4.09375 0zm7.723572 17.5625q0 -3.53125 1.375 -6.34375q1.390625 -2.8125 3.859375 -4.328125q2.46875 -1.53125 5.625 -1.53125q4.890625 0 7.90625 3.390625q3.03125 3.375 3.03125 9.0l0 0.296875q0 3.484375 -1.34375 6.265625q-1.328125 2.78125 -3.828125 4.328125q-2.484375 1.546875 -5.71875 1.546875q-4.859375 0 -7.890625 -3.375q-3.015625 -3.390625 -3.015625 -8.96875l0 -0.28125zm4.109375 0.484375q0 3.984375 1.84375 6.390625q1.859375 2.40625 4.953125 2.40625q3.125 0 4.953125 -2.4375q1.84375 -2.453125 1.84375 -6.84375q0 -3.953125 -1.875 -6.390625q-1.859375 -2.453125 -4.96875 -2.453125q-3.03125 0 -4.890625 2.421875q-1.859375 2.40625 -1.859375 6.90625zm34.39807 -8.578125q-0.921875 -0.140625 -2.015625 -0.140625q-4.03125 0 -5.46875 3.421875l0 17.0l-4.09375 0l0 -23.953125l3.984375 0l0.078125 2.765625q2.0 -3.203125 5.703125 -3.203125q1.1875 0 1.8125 0.3125l0 3.796875zm17.671448 20.28125q-0.359375 -0.703125 -0.578125 -2.515625q-2.859375 2.953125 -6.828125 2.953125q-3.53125 0 -5.8125 -2.0q-2.265625 -2.0 -2.265625 -5.078125q0 -3.734375 2.84375 -5.796875q2.84375 -2.078125 8.0 -2.078125l3.984375 0l0 -1.890625q0 -2.140625 -1.28125 -3.40625q-1.28125 -1.28125 -3.78125 -1.28125q-2.1875 0 -3.671875 1.109375q-1.484375 1.109375 -1.484375 2.671875l-4.109375 0q0 -1.78125 1.265625 -3.453125q1.265625 -1.671875 3.453125 -2.640625q2.1875 -0.984375 4.796875 -0.984375q4.140625 0 6.484375 2.078125q2.34375 2.0625 2.4375 5.6875l0 11.03125q0 3.296875 0.828125 5.234375l0 0.359375l-4.28125 0zm-6.796875 -3.125q1.921875 0 3.640625 -0.984375q1.734375 -1.0 2.5 -2.59375l0 -4.921875l-3.203125 0q-7.53125 0 -7.53125 4.40625q0 1.921875 1.28125 3.015625q1.296875 1.078125 3.3125 1.078125zm15.687256 -9.046875q0 -5.59375 2.578125 -8.90625q2.59375 -3.3125 6.875 -3.3125q4.375 0 6.84375 3.09375l0.1875 -2.65625l3.75 0l0 23.375q0 4.65625 -2.765625 7.328125q-2.75 2.671875 -7.40625 2.671875q-2.578125 0 -5.0625 -1.109375q-2.484375 -1.09375 -3.78125 -3.015625l2.125 -2.46875q2.625 3.265625 6.4375 3.265625q2.984375 0 4.65625 -1.6875q1.671875 -1.6875 1.671875 -4.734375l0 -2.0625q-2.453125 2.828125 -6.703125 2.828125q-4.203125 0 -6.8125 -3.375q-2.59375 -3.390625 -2.59375 -9.234375zm4.109375 0.46875q0 4.046875 1.65625 6.359375q1.671875 2.3125 4.65625 2.3125q3.875 0 5.6875 -3.515625l0 -10.9375q-1.875 -3.4375 -5.640625 -3.4375q-2.984375 0 -4.671875 2.328125q-1.6875 2.328125 -1.6875 6.890625zm32.22754 12.140625q-4.859375 0 -7.921875 -3.1875q-3.046875 -3.203125 -3.046875 -8.5625l0 -0.75q0 -3.5625 1.359375 -6.359375q1.359375 -2.796875 3.796875 -4.375q2.453125 -1.59375 5.3125 -1.59375q4.671875 0 7.25 3.078125q2.59375 3.078125 2.59375 8.8125l0 1.703125l-16.21875 0q0.078125 3.53125 2.0625 5.71875q1.984375 2.171875 5.03125 2.171875q2.171875 0 3.671875 -0.875q1.515625 -0.890625 2.640625 -2.34375l2.5 1.9375q-3.0 4.625 -9.03125 4.625zm-0.5 -21.46875q-2.484375 0 -4.171875 1.8125q-1.671875 1.796875 -2.078125 5.046875l12.0 0l0 -0.296875q-0.171875 -3.125 -1.6875 -4.84375q-1.5 -1.71875 -4.0625 -1.71875z" fill-rule="nonzero"/><path fill="#f15a29" d="m911.54816 539.67755l309.58002 0l0 279.29504l-309.58002 0z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m910.67664 714.1349l309.95276 0l0 70.6142l-309.95276 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m1000.9292 751.43616q-0.59375 5.109375 -3.765625 7.890625q-3.171875 2.765625 -8.4375 2.765625q-5.71875 0 -9.15625 -4.09375q-3.4375 -4.09375 -3.4375 -10.953125l0 -3.09375q0 -4.5 1.59375 -7.90625q1.609375 -3.40625 4.546875 -5.234375q2.953125 -1.828125 6.828125 -1.828125q5.125 0 8.21875 2.875q3.109375 2.859375 3.609375 7.921875l-4.265625 0q-0.546875 -3.84375 -2.40625 -5.5625q-1.84375 -1.734375 -5.15625 -1.734375q-4.078125 0 -6.390625 3.015625q-2.3125 3.0 -2.3125 8.5625l0 3.125q0 5.234375 2.1875 8.34375q2.1875 3.09375 6.140625 3.09375q3.53125 0 5.421875 -1.59375q1.890625 -1.609375 2.515625 -5.59375l4.265625 0zm4.081238 -1.96875q0 -3.53125 1.375 -6.34375q1.390625 -2.8125 3.859375 -4.328125q2.46875 -1.53125 5.625 -1.53125q4.890625 0 7.90625 3.390625q3.031311 3.375 3.031311 9.0l0 0.296875q0 3.484375 -1.34375 6.265625q-1.328125 2.78125 -3.828186 4.328125q-2.484375 1.546875 -5.71875 1.546875q-4.859375 0 -7.890625 -3.375q-3.015625 -3.390625 -3.015625 -8.96875l0 -0.28125zm4.109375 0.484375q0 3.984375 1.84375 6.390625q1.859375 2.40625 4.953125 2.40625q3.125 0 4.953125 -2.4375q1.84375 -2.453125 1.84375 -6.84375q0 -3.953125 -1.875 -6.390625q-1.859375 -2.453125 -4.96875 -2.453125q-3.03125 0 -4.890625 2.421875q-1.859375 2.40625 -1.859375 6.90625zm26.679382 -12.25l0.109375 2.65625q2.625 -3.09375 7.109375 -3.09375q5.015625 0 6.828125 3.84375q1.203125 -1.71875 3.109375 -2.78125q1.921875 -1.0625 4.53125 -1.0625q7.875 0 8.015625 8.34375l0 16.046875l-4.09375 0l0 -15.796875q0 -2.578125 -1.171875 -3.84375q-1.171875 -1.28125 -3.953125 -1.28125q-2.265625 0 -3.78125 1.375q-1.5 1.359375 -1.75 3.65625l0 15.890625l-4.109375 0l0 -15.6875q0 -5.234375 -5.109375 -5.234375q-4.03125 0 -5.515625 3.4375l0 17.484375l-4.09375 0l0 -23.953125l3.875 0zm56.103516 12.25q0 5.46875 -2.5 8.8125q-2.5 3.328125 -6.78125 3.328125q-4.359375 0 -6.859375 -2.765625l0 11.53125l-4.09375 0l0 -33.15625l3.75 0l0.1875 2.65625q2.515625 -3.09375 6.953125 -3.09375q4.3125 0 6.828125 3.25q2.515625 3.25 2.515625 9.0625l0 0.375zm-4.09375 -0.46875q0 -4.046875 -1.734375 -6.390625q-1.71875 -2.359375 -4.734375 -2.359375q-3.71875 0 -5.578125 3.296875l0 11.453125q1.84375 3.265625 5.625 3.265625q2.953125 0 4.6875 -2.328125q1.734375 -2.328125 1.734375 -6.9375zm24.086914 9.796875q-2.390625 2.8125 -7.015625 2.8125q-3.84375 0 -5.84375 -2.21875q-2.0 -2.21875 -2.015625 -6.578125l0 -15.59375l4.09375 0l0 15.46875q0 5.453125 4.421875 5.453125q4.6875 0 6.234375 -3.5l0 -17.421875l4.109375 0l0 23.953125l-3.90625 0l-0.078125 -2.375zm15.753662 -27.375l0 5.796875l4.46875 0l0 3.171875l-4.46875 0l0 14.84375q0 1.4375 0.59375 2.171875q0.59375 0.71875 2.03125 0.71875q0.71875 0 1.953125 -0.265625l0 3.3125q-1.609375 0.4375 -3.140625 0.4375q-2.75 0 -4.140625 -1.65625q-1.390625 -1.65625 -1.390625 -4.71875l0 -14.84375l-4.359375 0l0 -3.171875l4.359375 0l0 -5.796875l4.09375 0zm19.181885 30.1875q-4.859375 0 -7.921875 -3.1875q-3.046875 -3.203125 -3.046875 -8.5625l0 -0.75q0 -3.5625 1.359375 -6.359375q1.359375 -2.796875 3.796875 -4.375q2.453125 -1.59375 5.3125 -1.59375q4.671875 0 7.25 3.078125q2.59375 3.078125 2.59375 8.8125l0 1.703125l-16.21875 0q0.078125 3.53125 2.0625 5.71875q1.984375 2.171875 5.03125 2.171875q2.171875 0 3.671875 -0.875q1.515625 -0.890625 2.640625 -2.34375l2.5 1.9375q-3.0 4.625 -9.03125 4.625zm-0.5 -21.46875q-2.484375 0 -4.171875 1.8125q-1.671875 1.796875 -2.078125 5.046875l12.0 0l0 -0.296875q-0.171875 -3.125 -1.6875 -4.84375q-1.5 -1.71875 -4.0625 -1.71875z" fill-rule="nonzero"/><path fill="#000000" fill-opacity="0.0" d="m2002.7522 871.27905l0 -656.69293l69.259766 0l0 656.69293z" fill-rule="evenodd"/><path fill="#454345" d="m2042.0897 614.497l0 -13.46875l3.0625 0l0 17.25l-28.4375 0l0 -3.78125l25.375 0zm3.0625 -21.101562l0 3.609375l-21.140625 0l0 -3.609375l21.140625 0zm-26.734375 3.90625q-0.890625 0 -1.484375 -0.53125q-0.609375 -0.546875 -0.609375 -1.59375q0 -1.0625 0.609375 -1.609375q0.59375 -0.546875 1.484375 -0.546875q0.875 0 1.46875 0.546875q0.578125 0.546875 0.578125 1.609375q0 1.046875 -0.578125 1.59375q-0.59375 0.53125 -1.46875 0.53125zm26.734375 -11.472656l-18.34375 0l0 3.34375l-2.796875 0l0 -3.34375l-2.15625 0q-3.40625 0 -5.25 -1.8125q-1.859375 -1.8125 -1.859375 -5.140625q0 -1.25 0.328125 -2.484375l2.921875 0.203125q-0.171875 0.921875 -0.171875 1.953125q0 1.75 1.03125 2.71875q1.015625 0.953125 2.9375 0.953125l2.21875 0l0 -4.515625l2.796875 0l0 4.515625l18.34375 0l0 3.609375zm0.390625 -20.402344q0 4.296875 -2.8125 7.0q-2.828125 2.6875 -7.5625 2.6875l-0.65625 0q-3.15625 0 -5.625 -1.203125q-2.46875 -1.203125 -3.859375 -3.359375q-1.40625 -2.15625 -1.40625 -4.6875q0 -4.109375 2.71875 -6.390625q2.71875 -2.296875 7.78125 -2.296875l1.5 0l0 14.3125q3.125 -0.078125 5.046875 -1.8125q1.921875 -1.75 1.921875 -4.453125q0 -1.90625 -0.78125 -3.234375q-0.78125 -1.328125 -2.0625 -2.328125l1.71875 -2.203125q4.078125 2.65625 4.078125 7.96875zm-18.953125 0.4375q0 2.1875 1.59375 3.671875q1.59375 1.484375 4.46875 1.84375l0 -10.59375l-0.28125 0q-2.75 0.15625 -4.265625 1.484375q-1.515625 1.328125 -1.515625 3.59375zm16.0 -21.347656q0 -1.921875 -1.171875 -3.359375q-1.171875 -1.453125 -2.921875 -1.609375l0 -3.421875q1.8125 0.09375 3.453125 1.25q1.640625 1.15625 2.625 3.078125q0.96875 1.921875 0.96875 4.0625q0 4.328125 -2.875 6.875q-2.890625 2.546875 -7.890625 2.546875l-0.609375 0q-3.078125 0 -5.484375 -1.125q-2.40625 -1.140625 -3.734375 -3.25q-1.328125 -2.125 -1.328125 -5.015625q0 -3.5625 2.140625 -5.90625q2.125 -2.359375 5.515625 -2.515625l0 3.421875q-2.046875 0.15625 -3.359375 1.546875q-1.328125 1.390625 -1.328125 3.453125q0 2.75 1.984375 4.265625q1.984375 1.515625 5.734375 1.515625l0.6875 0q3.65625 0 5.625 -1.5q1.96875 -1.515625 1.96875 -4.3125zm-2.734375 -19.375l-15.84375 -4.921875l0 -3.859375l24.406128 8.5q5.265625 1.96875 5.265625 6.265625l-0.046875 0.6875l-0.265625 1.34375l-2.921875 0l0.078125 -0.984375q0 -1.828125 -0.75 -2.84375q-0.734375 -1.03125 -2.703003 -1.703125l-2.15625 -0.796875l-20.90625 7.53125l0 -3.9375l15.84375 -5.28125zm2.734375 -20.234375q0 -1.921875 -1.171875 -3.359375q-1.171875 -1.453125 -2.921875 -1.609375l0 -3.421875q1.8125 0.09375 3.453125 1.25q1.640625 1.15625 2.625 3.078125q0.96875 1.921875 0.96875 4.0625q0 4.328125 -2.875 6.875q-2.890625 2.546875 -7.890625 2.546875l-0.609375 0q-3.078125 0 -5.484375 -1.125q-2.40625 -1.140625 -3.734375 -3.25q-1.328125 -2.125 -1.328125 -5.015625q0 -3.5625 2.140625 -5.90625q2.125 -2.359375 5.515625 -2.515625l0 3.421875q-2.046875 0.15625 -3.359375 1.546875q-1.328125 1.390625 -1.328125 3.453125q0 2.75 1.984375 4.265625q1.984375 1.515625 5.734375 1.515625l0.6875 0q3.65625 0 5.625 -1.5q1.96875 -1.515625 1.96875 -4.3125zm2.5625 -16.375l0 3.609375l-30.0 0l0 -3.609375l30.0 0zm0.390625 -14.550781q0 4.296875 -2.8125 7.0q-2.828125 2.6875 -7.5625 2.6875l-0.65625 0q-3.15625 0 -5.625 -1.203125q-2.46875 -1.203125 -3.859375 -3.359375q-1.40625 -2.15625 -1.40625 -4.6875q0 -4.109375 2.71875 -6.390625q2.71875 -2.296875 7.78125 -2.296875l1.5 0l0 14.3125q3.125 -0.078125 5.046875 -1.8125q1.921875 -1.75 1.921875 -4.453125q0 -1.90625 -0.78125 -3.234375q-0.78125 -1.328125 -2.0625 -2.328125l1.71875 -2.203125q4.078125 2.65625 4.078125 7.96875zm-18.953125 0.4375q0 2.1875 1.59375 3.671875q1.59375 1.484375 4.46875 1.84375l0 -10.59375l-0.28125 0q-2.75 0.15625 -4.265625 1.484375q-1.515625 1.328125 -1.515625 3.59375z" fill-rule="nonzero"/><path fill="#ffffff" d="m1046.3835 584.04803l0 13.291809l-13.460083 0c-7.402954 0 -13.291809 6.057007 -13.291809 13.291687l0 13.291809l-13.291626 0l0 13.291687l13.291626 0l0 13.291809l-13.291626 0l0 13.291687l13.291626 0l0 13.291809c0 7.403015 6.05719 13.291687 13.291809 13.291687l13.291748 0l0 13.291809l13.291748 0l0 -13.291809l13.29187 0l0 13.291809l13.291748 0l0 -13.291809l13.291626 0c7.402954 0 13.29187 -6.057007 13.29187 -13.291687l0 -13.291809l13.291626 0l0 -13.291687l-13.291626 0l0 -13.291809l13.291626 0l0 -13.291687l-13.291626 0l0 -13.291809c0 -7.403015 -6.057007 -13.291687 -13.29187 -13.291687l-13.291626 0l0 -13.291809l-13.291748 0l0 13.291809l-13.29187 0l0 -13.291809l-13.123413 0zm-7.234741 94.893005c-4.206299 0 -7.739624 -3.5332031 -7.739624 -7.739502l7.739624 0l0 7.739502zm0 -15.479004l-7.907837 0l0 -7.739502l7.739502 0l0 7.739502zm0 -15.647217l-7.907837 0l0 -7.739441l7.739502 0l0 7.739441zm0 -15.478943l-7.907837 0l0 -7.739502l7.739502 0l0 7.739502zm0 -15.479004l-7.907837 0c0 -4.20636 3.5332031 -7.739502 7.739502 -7.739502l0 7.739502zm54.344727 -7.907837c4.2061768 0 7.739502 3.5333252 7.739502 7.739502l-7.739502 0l0 -7.739502zm0 15.647339l7.739502 0l0 7.739502l-7.739502 0l0 -7.739502zm0 15.479004l7.739502 0l0 7.739441l-7.739502 0l0 -7.739441zm0 15.647156l7.739502 0l0 7.739502l-7.739502 0l0 -7.739502zm0 15.479004l7.739502 0c0 4.206299 -3.5333252 7.739502 -7.739502 7.739502l0 -7.739502zm-46.605347 -62.252502l7.739502 0l0 7.739502l-7.739502 0l0 -7.739502zm7.739502 69.992004l-7.739502 0l0 -7.739502l7.739502 0l0 7.739502zm15.647339 0l-7.739502 0l0 -7.739502l7.739502 0l0 7.739502zm15.479004 0l-7.739502 0l0 -7.739502l7.739502 0l0 7.739502zm-7.739502 -69.992004l7.739502 0l0 7.739502l-7.739502 0l0 -7.739502zm-15.647339 0l7.739502 0l0 7.739502l-7.739502 0l0 -7.739502zm23.38684 15.647339l0 38.86566l-38.865845 0l0 -38.86566l38.865845 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m667.17145 608.065c3.529541 3.1932373 7.5632324 5.0421143 11.933044 6.3864746c5.882324 2.0170288 11.764893 3.0252686 17.983398 3.6976929c6.5548096 0.67230225 12.941467 0.840271 19.496094 0.5041504c8.907837 -0.5041504 17.47931 -1.6807251 25.882812 -4.7059937c3.8656616 -1.3445435 7.3950806 -3.1934204 10.588501 -6.050476c0 0.3361206 0 0.6722412 0 0.84039307c0 6.3865356 0 12.773315 0 19.159851c0 2.1849976 -0.8404541 3.8656616 -2.3530273 5.210266c-2.1849976 2.0167847 -4.8740845 3.3613892 -7.731201 4.537781c-4.8740845 2.0168457 -9.916199 3.1934204 -15.126282 3.8656616c-7.731201 1.1764526 -15.462463 1.5125732 -23.193665 1.1764526c-8.739624 -0.33599854 -17.31128 -1.5125732 -25.54663 -4.36969c-3.0252686 -1.1765747 -6.050537 -2.3531494 -8.571655 -4.369812c-0.840271 -0.6722412 -1.6807251 -1.5126953 -2.3529663 -2.3529663c-0.67230225 -0.8404541 -1.0084229 -2.0170288 -1.0084229 -3.0254517c0 -6.7227783 0 -13.277405 0 -20.000244c0 0 0 -0.16815186 0 -0.50408936z" fill-rule="evenodd"/><path fill="#ffffff" d="m667.17145 667.56177c4.537964 4.0336914 10.252319 6.050537 16.134705 7.731262c5.210266 1.3445435 10.420349 2.1848145 15.630615 2.520935c6.3866577 0.5043335 12.605103 0.67230225 18.991821 0.16796875c8.235474 -0.50408936 16.302856 -1.6806641 24.034058 -4.369629c3.6975708 -1.3447266 7.05896 -2.8572388 10.0842285 -5.378235c0.16796875 -0.16815186 0.50408936 -0.50427246 0.840271 -0.8404541c0 0.33618164 0 0.5041504 0 0.67230225c0 6.5546265 0 13.277466 0 19.832275c0 2.0168457 -1.0084229 3.529358 -2.3530273 4.8740845c-2.520935 2.3530273 -5.5462036 3.6973877 -8.907593 5.0421143c-4.8741455 1.8486938 -9.916199 2.8571167 -15.126282 3.6973877c-6.7228394 1.0084229 -13.61377 1.1765747 -20.504578 1.0084229c-8.907776 -0.33599854 -17.6474 -1.3444214 -26.050903 -4.20166c-3.529419 -1.1764526 -6.890808 -2.689148 -9.748108 -5.0421143c-0.84020996 -0.67230225 -1.5125122 -1.5125732 -2.1848145 -2.3529663c-0.6722412 -0.840271 -0.84039307 -1.848877 -0.84039307 -2.8572998c0 -6.7227783 0 -13.613586 0 -20.336365c0 0 0 0 0 -0.16802979z" fill-rule="evenodd"/><path fill="#ffffff" d="m667.17145 637.8131c3.6975098 3.3614502 8.235474 5.210266 12.941467 6.7228394c5.378235 1.6806641 10.924438 2.689087 16.638855 3.3613892c5.8825073 0.67230225 11.596863 0.8404541 17.479248 0.67230225c9.411926 -0.33618164 18.823853 -1.5125732 27.731628 -4.537842c4.7059937 -1.6806641 7.899231 -3.3613892 11.092651 -6.050476c0 0.16796875 0 0.50408936 0 0.6722412c0 6.5546265 0 13.277466 0 19.832275c0 1.6807251 -0.8404541 3.0252686 -2.0168457 4.369629c-2.1849976 2.1849976 -4.8741455 3.529541 -7.731262 4.8741455c-4.8740845 2.0168457 -9.916199 3.1934204 -15.126282 4.0336914c-6.7227783 1.0084229 -13.61377 1.5126953 -20.504517 1.3445435c-9.2439575 -0.16815186 -18.319702 -1.1763916 -27.059387 -4.0336914c-3.529358 -1.1765747 -6.890747 -2.520935 -9.748047 -4.7059326c-0.840271 -0.67230225 -1.6807251 -1.5127563 -2.3529663 -2.1848755c-0.840271 -1.0085449 -1.3445435 -2.1849976 -1.3445435 -3.529541c0 -6.5546265 0 -13.277405 0 -19.832275c0 -0.50408936 0 -0.6722412 0 -1.0084229z" fill-rule="evenodd"/><path fill="#ffffff" d="m710.1973 585.0391c8.571655 -0.16796875 17.143127 0.67230225 25.54663 2.689148c4.369812 1.1765747 8.571655 2.5211182 12.269226 4.8740845c1.5125122 0.840271 2.8570557 2.0168457 3.8654785 3.3614502c1.5127563 2.1848145 1.5127563 4.20166 0 6.3866577c-1.3445435 1.6806641 -3.0252075 2.8570557 -4.8739014 4.0336304c-4.2018433 2.3530273 -8.739624 3.6975708 -13.445618 4.7059937c-5.5463867 1.1765747 -11.260803 2.0168457 -17.143127 2.1848145c-4.369812 0.16815186 -8.907776 0.16815186 -13.445618 0c-8.403503 -0.3361206 -16.807007 -1.6807251 -24.70636 -4.537781c-2.8571167 -1.0084229 -5.7144165 -2.3530273 -7.899231 -4.2018433c-0.84039307 -0.67211914 -1.5126953 -1.3446045 -2.1849976 -2.1848145c-1.5125122 -2.0168457 -1.5125122 -3.8657227 0 -5.8825684c1.3446045 -1.8486938 3.1934204 -3.1932373 5.0421143 -4.20166c4.0336914 -2.1849976 8.403503 -3.529358 12.941467 -4.537964c5.8823853 -1.3445435 11.764893 -2.0168457 17.81543 -2.3528442c2.0168457 -0.50427246 4.0336914 -0.3363037 6.218506 -0.3363037z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m881.6864 392.3858l255.52759 0l0 47.62204l-255.52759 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m912.21765 431.49954l-13.5 0l-3.03125 8.40625l-4.375 0l12.296875 -32.21875l3.71875 0l12.328125 32.21875l-4.359375 0l-3.078125 -8.40625zm-12.21875 -3.5l10.96875 0l-5.5 -15.078125l-5.46875 15.078125zm32.960144 9.0q2.1875 0 3.828125 -1.328125q1.640625 -1.328125 1.8125 -3.3125l3.875 0q-0.109375 2.0625 -1.421875 3.921875q-1.296875 1.859375 -3.484375 2.96875q-2.171875 1.09375 -4.609375 1.09375q-4.890625 0 -7.78125 -3.265625q-2.890625 -3.265625 -2.890625 -8.921875l0 -0.6875q0 -3.5 1.28125 -6.21875q1.296875 -2.71875 3.6875 -4.21875q2.40625 -1.515625 5.6875 -1.515625q4.015625 0 6.6875 2.421875q2.671875 2.40625 2.84375 6.25l-3.875 0q-0.171875 -2.3125 -1.765625 -3.8125q-1.578125 -1.5 -3.890625 -1.5q-3.125 0 -4.84375 2.25q-1.71875 2.25 -1.71875 6.5l0 0.765625q0 4.140625 1.703125 6.375q1.71875 2.234375 4.875 2.234375zm23.72644 0q2.1875 0 3.828125 -1.328125q1.640625 -1.328125 1.8125 -3.3125l3.875 0q-0.109375 2.0625 -1.421875 3.921875q-1.296875 1.859375 -3.484375 2.96875q-2.171875 1.09375 -4.609375 1.09375q-4.890625 0 -7.78125 -3.265625q-2.890625 -3.265625 -2.890625 -8.921875l0 -0.6875q0 -3.5 1.28125 -6.21875q1.296875 -2.71875 3.6875 -4.21875q2.40625 -1.515625 5.6875 -1.515625q4.015625 0 6.6875 2.421875q2.671875 2.40625 2.84375 6.25l-3.875 0q-0.171875 -2.3125 -1.765625 -3.8125q-1.578125 -1.5 -3.890625 -1.5q-3.125 0 -4.84375 2.25q-1.71875 2.25 -1.71875 6.5l0 0.765625q0 4.140625 1.703125 6.375q1.71875 2.234375 4.875 2.234375zm24.054565 3.34375q-4.859375 0 -7.921875 -3.1875q-3.046875 -3.203125 -3.046875 -8.5625l0 -0.75q0 -3.5625 1.359375 -6.359375q1.359375 -2.796875 3.796875 -4.375q2.453125 -1.59375 5.3125 -1.59375q4.671875 0 7.25 3.078125q2.59375 3.078125 2.59375 8.8125l0 1.703125l-16.21875 0q0.078125 3.53125 2.0625 5.71875q1.984375 2.171875 5.03125 2.171875q2.171875 0 3.671875 -0.875q1.515625 -0.890625 2.640625 -2.34375l2.5 1.9375q-3.0 4.625 -9.03125 4.625zm-0.5 -21.46875q-2.484375 0 -4.171875 1.8125q-1.671875 1.796875 -2.078125 5.046875l12.0 0l0 -0.296875q-0.171875 -3.125 -1.6875 -4.84375q-1.5 -1.71875 -4.0625 -1.71875zm28.529785 14.671875q0 -1.65625 -1.25 -2.5625q-1.25 -0.921875 -4.359375 -1.578125q-3.109375 -0.671875 -4.9375 -1.59375q-1.828125 -0.9375 -2.703125 -2.21875q-0.875 -1.296875 -0.875 -3.0625q0 -2.9375 2.484375 -4.96875q2.5 -2.046875 6.375 -2.046875q4.0625 0 6.59375 2.109375q2.546875 2.09375 2.546875 5.375l-4.125 0q0 -1.6875 -1.4375 -2.90625q-1.421875 -1.21875 -3.578125 -1.21875q-2.234375 0 -3.5 0.984375q-1.265625 0.96875 -1.265625 2.546875q0 1.46875 1.171875 2.234375q1.171875 0.75 4.234375 1.4375q3.078125 0.6875 4.96875 1.640625q1.90625 0.9375 2.828125 2.28125q0.921875 1.34375 0.921875 3.265625q0 3.203125 -2.578125 5.140625q-2.5625 1.9375 -6.65625 1.9375q-2.875 0 -5.09375 -1.015625q-2.203125 -1.015625 -3.453125 -2.84375q-1.25 -1.828125 -1.25 -3.953125l4.09375 0q0.109375 2.0625 1.640625 3.265625q1.546875 1.203125 4.0625 1.203125q2.328125 0 3.734375 -0.9375q1.40625 -0.9375 1.40625 -2.515625zm23.372253 0q0 -1.65625 -1.25 -2.5625q-1.25 -0.921875 -4.359375 -1.578125q-3.109314 -0.671875 -4.937439 -1.59375q-1.828125 -0.9375 -2.703125 -2.21875q-0.875 -1.296875 -0.875 -3.0625q0 -2.9375 2.484375 -4.96875q2.5 -2.046875 6.374939 -2.046875q4.0625 0 6.59375 2.109375q2.546875 2.09375 2.546875 5.375l-4.125 0q0 -1.6875 -1.4375 -2.90625q-1.421875 -1.21875 -3.578125 -1.21875q-2.234375 0 -3.499939 0.984375q-1.265625 0.96875 -1.265625 2.546875q0 1.46875 1.171875 2.234375q1.171814 0.75 4.234314 1.4375q3.078125 0.6875 4.96875 1.640625q1.90625 0.9375 2.828125 2.28125q0.921875 1.34375 0.921875 3.265625q0 3.203125 -2.578125 5.140625q-2.5625 1.9375 -6.65625 1.9375q-2.875 0 -5.093689 -1.015625q-2.203125 -1.015625 -3.453125 -2.84375q-1.25 -1.828125 -1.25 -3.953125l4.09375 0q0.109375 2.0625 1.640625 3.265625q1.546814 1.203125 4.062439 1.203125q2.328125 0 3.734375 -0.9375q1.40625 -0.9375 1.40625 -2.515625z" fill-rule="nonzero"/><path fill="#ffffff" d="m796.24927 459.50598l-2.3529663 0c0.3361206 -0.5041199 0.3361206 -1.0084229 0.3361206 -1.5127258l0 -28.739868c0 -1.6806946 -1.3445435 -3.0252686 -3.0252075 -3.0252686l-37.983826 0c-1.6807251 0 -3.0252686 1.344574 -3.0252686 3.0252686l0 28.739868c0 0.504303 0.16796875 1.008606 0.3361206 1.5127258l-1.6806641 0c-1.3446045 0 -2.3530273 1.0084229 -2.3530273 2.3529968l0 0.16815186c0 1.3445435 1.0084229 2.3529663 2.3530273 2.3529663l47.56372 0c1.3447266 0 2.3531494 -1.0084229 2.3531494 -2.3529663l0 -0.16815186c-0.16815186 -1.1764221 -1.1765747 -2.3529968 -2.5211792 -2.3529968zm-43.69818 -30.588745l39.66455 0l0 28.06778l-39.66455 0l0 -28.06778z" fill-rule="evenodd"/><path fill="#ffffff" d="m850.704 433.28708l-14.958313 0c-1.6807251 0 -3.0252686 1.344574 -3.0252686 3.0252686l0 26.891205c0 1.6806946 1.3445435 3.025238 3.0252686 3.025238l14.958313 0c1.6807251 0 3.0252686 -1.3445435 3.0252686 -3.025238l0 -26.891205c0 -1.6806946 -1.3445435 -3.0252686 -3.0252686 -3.0252686zm0.840271 28.740051l-16.807007 0l0 -26.218903l16.807007 0l0 26.218903z" fill-rule="evenodd"/><path fill="#ffffff" d="m837.93066 400.34537l0 28.403748l6.050537 0l0 -31.765137c0 -2.8572998 -2.3529663 -5.210266 -5.210083 -5.210266l-61.17749 0c-2.8572388 0 -5.210266 2.3529663 -5.210266 5.210266l0 24.87436l6.050537 0l0 -21.51297c0 -1.344574 1.1763916 -2.5211487 2.5211182 -2.5211487l54.454712 0c1.5125122 0 2.520935 1.1765747 2.520935 2.5211487z" fill-rule="evenodd"/><path fill="#ffffff" d="m814.905 441.69058l13.445557 0l0 -2.6891174l-30.420532 0l0 2.6891174l3.529358 0l0 8.067352l-3.529358 0l0 6.722809l23.697754 0l0 -6.722809l-6.7227783 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m844.4853 376.3114c-2.0168457 -9.916046 -10.924622 -17.143127 -21.00885 -17.143127c-3.529358 0 -7.058777 0.8404236 -10.0841675 2.5211487c-5.210083 -7.8993835 -13.781616 -12.605347 -23.361694 -12.605347c-15.294434 0 -27.731445 12.101044 -28.067749 27.227325c-9.747864 2.1849976 -16.974976 10.924469 -16.974976 20.840698c0 11.260773 8.739624 20.336365 19.832275 21.34497l0.16815186 -0.16815186l0 -3.0252686c-8.067566 -2.1848145 -14.11792 -9.411926 -14.11792 -18.15155c0 -9.075775 6.890808 -16.975006 15.798584 -18.487701l1.1763916 -0.16799927l0 -1.3447266c0 -13.949707 8.067383 -22.01709 22.01709 -22.01709c9.075806 0 17.14331 4.705963 21.849121 12.437195l0.67230225 1.1763916l1.1765747 -0.6720886c3.0252686 -1.848877 6.3866577 -2.8572998 9.748047 -2.8572998c9.075745 0 17.143127 6.8907776 18.48767 15.798584l0.16815186 1.0084229l1.0084229 0.16799927c9.075806 1.5126953 12.773376 6.0506897 12.773376 15.126282c0 3.6975403 -1.0084229 6.218689 -2.8572998 8.571655l0 8.403503l0.16815186 0.16799927c5.378235 -3.8655396 8.739624 -10.0842285 8.739624 -17.143158c0.16796875 -10.084198 -7.227112 -18.991821 -17.31128 -21.008667z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m1744.6743 590.8095l230.8977 0l0 69.25989l-230.8977 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m1792.1993 633.20953l0 -28.4375l8.03125 0q3.71875 0 6.5625 1.640625q2.859375 1.640625 4.40625 4.671875q1.546875 3.015625 1.578125 6.953125l0 1.8125q0 4.015625 -1.5625 7.046875q-1.546875 3.03125 -4.4375 4.65625q-2.875 1.609375 -6.703125 1.65625l-7.875 0zm3.75 -25.359375l0 22.296875l3.953125 0q4.328125 0 6.734375 -2.6875q2.421875 -2.703125 2.421875 -7.6875l0 -1.65625q0 -4.84375 -2.28125 -7.53125q-2.265625 -2.6875 -6.453125 -2.734375l-4.375 0zm30.683594 25.75q-4.296875 0 -7.0 -2.8125q-2.6875 -2.828125 -2.6875 -7.5625l0 -0.65625q0 -3.15625 1.203125 -5.625q1.203125 -2.46875 3.359375 -3.859375q2.15625 -1.40625 4.6875 -1.40625q4.109375 0 6.390625 2.71875q2.296875 2.71875 2.296875 7.78125l0 1.5l-14.3125 0q0.078125 3.125 1.8125 5.046875q1.75 1.921875 4.453125 1.921875q1.90625 0 3.234375 -0.78125q1.328125 -0.78125 2.328125 -2.0625l2.203125 1.71875q-2.65625 4.078125 -7.96875 4.078125zm-0.4375 -18.953125q-2.1875 0 -3.671875 1.59375q-1.484375 1.59375 -1.84375 4.46875l10.59375 0l0 -0.28125q-0.15625 -2.75 -1.484375 -4.265625q-1.328125 -1.515625 -3.59375 -1.515625zm19.578125 13.65625l5.234375 -16.234375l3.703125 0l-7.578125 21.140625l-2.765625 0l-7.65625 -21.140625l3.703125 0l5.359375 16.234375zm20.917969 5.296875q-4.296875 0 -7.0 -2.8125q-2.6875 -2.828125 -2.6875 -7.5625l0 -0.65625q0 -3.15625 1.203125 -5.625q1.203125 -2.46875 3.359375 -3.859375q2.15625 -1.40625 4.6875 -1.40625q4.109375 0 6.390625 2.71875q2.296875 2.71875 2.296875 7.78125l0 1.5l-14.3125 0q0.078125 3.125 1.8125 5.046875q1.75 1.921875 4.453125 1.921875q1.90625 0 3.234375 -0.78125q1.328125 -0.78125 2.328125 -2.0625l2.203125 1.71875q-2.65625 4.078125 -7.96875 4.078125zm-0.4375 -18.953125q-2.1875 0 -3.671875 1.59375q-1.484375 1.59375 -1.84375 4.46875l10.59375 0l0 -0.28125q-0.15625 -2.75 -1.484375 -4.265625q-1.328125 -1.515625 -3.59375 -1.515625zm16.785156 18.5625l-3.609375 0l0 -30.0l3.609375 0l0 30.0zm4.8320312 -10.765625q0 -3.109375 1.21875 -5.578125q1.21875 -2.484375 3.390625 -3.828125q2.1875 -1.359375 4.984375 -1.359375q4.3125 0 6.96875 3.0q2.671875 2.984375 2.671875 7.9375l0 0.265625q0 3.078125 -1.1875 5.53125q-1.171875 2.453125 -3.375 3.828125q-2.1875 1.359375 -5.046875 1.359375q-4.296875 0 -6.96875 -2.984375q-2.65625 -3.0 -2.65625 -7.921875l0 -0.25zm3.625 0.4375q0 3.515625 1.625 5.640625q1.640625 2.125 4.375 2.125q2.75 0 4.375 -2.15625q1.625 -2.15625 1.625 -6.046875q0 -3.46875 -1.65625 -5.625q-1.640625 -2.171875 -4.375 -2.171875q-2.6875 0 -4.328125 2.140625q-1.640625 2.125 -1.640625 6.09375zm38.0 0q0 4.8125 -2.21875 7.765625q-2.203125 2.953125 -5.96875 2.953125q-3.84375 0 -6.0625 -2.4375l0 10.171875l-3.609375 0l0 -29.265625l3.296875 0l0.1875 2.34375q2.203125 -2.734375 6.125 -2.734375q3.8125 0 6.03125 2.875q2.21875 2.875 2.21875 7.984375l0 0.34375zm-3.625 -0.421875q0 -3.5625 -1.53125 -5.625q-1.515625 -2.078125 -4.171875 -2.078125q-3.28125 0 -4.921875 2.90625l0 10.09375q1.625 2.890625 4.96875 2.890625q2.59375 0 4.125 -2.0625q1.53125 -2.0625 1.53125 -6.125z" fill-rule="nonzero"/><path fill="#ffffff" d="m1860.1666 454.60333c-33.673096 0 -60.97046 27.297363 -60.97046 60.97052c0 33.67334 27.297363 60.97046 60.97046 60.97046c33.67334 0 60.97058 -27.29712 60.97058 -60.97046c0 -33.673157 -27.297241 -60.97052 -60.97058 -60.97052zm-14.545288 81.29401l-5.3796387 5.379822l-22.91394 -22.913818l22.91394 -22.913666l5.3796387 5.379669l-17.533813 17.533997l17.533813 17.533997zm11.954956 13.3498535l-7.77063 -1.793335l14.9436035 -61.36902l7.770874 1.793335l-14.943848 61.36902zm22.51538 -7.9700317l-5.379883 -5.379822l17.53418 -17.533997l-17.53418 -17.533997l5.379883 -5.379669l22.913696 22.913666l-22.913696 22.913818z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m1266.6814 590.8095l238.99207 0l0 70.6142l-238.99207 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m1328.9664 633.20953l0 -28.4375l8.03125 0q3.71875 0 6.5625 1.640625q2.859375 1.640625 4.40625 4.671875q1.546875 3.015625 1.578125 6.953125l0 1.8125q0 4.015625 -1.5625 7.046875q-1.546875 3.03125 -4.4375 4.65625q-2.875 1.609375 -6.703125 1.65625l-7.875 0zm3.75 -25.359375l0 22.296875l3.953125 0q4.328125 0 6.734375 -2.6875q2.421875 -2.703125 2.421875 -7.6875l0 -1.65625q0 -4.84375 -2.28125 -7.53125q-2.265625 -2.6875 -6.453125 -2.734375l-4.375 0zm30.683594 25.75q-4.296875 0 -7.0 -2.8125q-2.6875 -2.828125 -2.6875 -7.5625l0 -0.65625q0 -3.15625 1.203125 -5.625q1.203125 -2.46875 3.359375 -3.859375q2.15625 -1.40625 4.6875 -1.40625q4.109375 0 6.390625 2.71875q2.296875 2.71875 2.296875 7.78125l0 1.5l-14.3125 0q0.078125 3.125 1.8125 5.046875q1.75 1.921875 4.453125 1.921875q1.90625 0 3.234375 -0.78125q1.328125 -0.78125 2.328125 -2.0625l2.203125 1.71875q-2.65625 4.078125 -7.96875 4.078125zm-0.4375 -18.953125q-2.1875 0 -3.671875 1.59375q-1.484375 1.59375 -1.84375 4.46875l10.59375 0l0 -0.28125q-0.15625 -2.75 -1.484375 -4.265625q-1.328125 -1.515625 -3.59375 -1.515625zm30.722656 8.234375q0 4.8125 -2.21875 7.765625q-2.203125 2.953125 -5.96875 2.953125q-3.84375 0 -6.0625 -2.4375l0 10.171875l-3.609375 0l0 -29.265625l3.296875 0l0.1875 2.34375q2.203125 -2.734375 6.125 -2.734375q3.8125 0 6.03125 2.875q2.21875 2.875 2.21875 7.984375l0 0.34375zm-3.625 -0.421875q0 -3.5625 -1.53125 -5.625q-1.515625 -2.078125 -4.171875 -2.078125q-3.28125 0 -4.921875 2.90625l0 10.09375q1.625 2.890625 4.96875 2.890625q2.59375 0 4.125 -2.0625q1.53125 -2.0625 1.53125 -6.125zm12.128906 10.75l-3.609375 0l0 -30.0l3.609375 0l0 30.0zm4.8320312 -10.765625q0 -3.109375 1.21875 -5.578125q1.21875 -2.484375 3.390625 -3.828125q2.1875 -1.359375 4.984375 -1.359375q4.3125 0 6.96875 3.0q2.671875 2.984375 2.671875 7.9375l0 0.265625q0 3.078125 -1.1875 5.53125q-1.171875 2.453125 -3.375 3.828125q-2.1875 1.359375 -5.046875 1.359375q-4.296875 0 -6.96875 -2.984375q-2.65625 -3.0 -2.65625 -7.921875l0 -0.25zm3.625 0.4375q0 3.515625 1.625 5.640625q1.640625 2.125 4.375 2.125q2.75 0 4.375 -2.15625q1.625 -2.15625 1.625 -6.046875q0 -3.46875 -1.65625 -5.625q-1.640625 -2.171875 -4.375 -2.171875q-2.6875 0 -4.328125 2.140625q-1.640625 2.125 -1.640625 6.09375zm26.769531 5.03125l4.921875 -15.84375l3.859375 0l-8.5 24.40625q-1.96875 5.265625 -6.265625 5.265625l-0.6875 -0.046875l-1.34375 -0.265625l0 -2.921875l0.984375 0.078125q1.828125 0 2.84375 -0.75q1.03125 -0.734375 1.703125 -2.703125l0.796875 -2.15625l-7.53125 -20.90625l3.9375 0l5.28125 15.84375z" fill-rule="nonzero"/><path fill="#ffffff" d="m1382.8496 502.85596c0.7943115 0 1.3901367 -0.794281 1.3901367 -1.3901062c0 -0.794281 -0.7943115 -1.3898621 -1.3901367 -1.3898621c-0.7943115 0 -1.3898926 0.59558105 -1.3898926 1.3898621c0 0.794281 0.59558105 1.3901062 1.3898926 1.3901062z" fill-rule="evenodd"/><path fill="#ffffff" d="m1388.0126 502.85596c0.7940674 0 1.3898926 -0.5958252 1.3898926 -1.3901062c0 -0.794281 -0.5958252 -1.3898621 -1.3898926 -1.3898621c-0.79455566 0 -1.3901367 0.59558105 -1.3901367 1.3898621c-0.19848633 0.794281 0.59558105 1.3901062 1.3901367 1.3901062z" fill-rule="evenodd"/><path fill="#ffffff" d="m1388.0126 487.96307c0.7940674 0 1.3898926 -0.5957947 1.3898926 -1.3900757c0 -0.794281 -0.5958252 -1.3898926 -1.3898926 -1.3898926c-0.79455566 0 -1.3901367 0.5956116 -1.3901367 1.3898926c-0.19848633 0.794281 0.59558105 1.3900757 1.3901367 1.3900757z" fill-rule="evenodd"/><path fill="#ffffff" d="m1377.6869 487.96307c0.7943115 0 1.3898926 -0.5957947 1.3898926 -1.3900757c0 -0.794281 -0.59558105 -1.3898926 -1.3898926 -1.3898926c-0.79455566 0 -1.3901367 0.5956116 -1.3901367 1.3898926c0 0.794281 0.59558105 1.3900757 1.3901367 1.3900757z" fill-rule="evenodd"/><path fill="#ffffff" d="m1377.6869 502.85596c0.7943115 0 1.3898926 -0.5958252 1.3898926 -1.3901062c0 -0.794281 -0.59558105 -1.3898621 -1.3898926 -1.3898621c-0.79455566 0 -1.3901367 0.59558105 -1.3901367 1.3898621c0 0.794281 0.59558105 1.3901062 1.3901367 1.3901062z" fill-rule="evenodd"/><path fill="#ffffff" d="m1382.8496 487.96307c0.7943115 0 1.3901367 -0.794281 1.3901367 -1.3900757c0 -0.794281 -0.7943115 -1.3898926 -1.3901367 -1.3898926c-0.7943115 0 -1.3898926 0.5956116 -1.3898926 1.3898926c0 0.794281 0.59558105 1.3900757 1.3898926 1.3900757z" fill-rule="evenodd"/><path fill="#ffffff" d="m1383.0483 514.9686c-0.7944336 0 -1.3900146 0.59558105 -1.3900146 1.3898926c0 0.7942505 0.59558105 1.3900757 1.3900146 1.3900757c0.7940674 0 1.3898926 -0.7943115 1.3898926 -1.3900757c0 -0.7943115 -0.7943115 -1.3898926 -1.3898926 -1.3898926z" fill-rule="evenodd"/><path fill="#ffffff" d="m1388.0126 514.9686c-0.7944336 0 -1.3900146 0.59558105 -1.3900146 1.3898926c0 0.7942505 0.59558105 1.3900757 1.3900146 1.3900757c0.7940674 0 1.3898926 -0.5958252 1.3898926 -1.3900757c0 -0.7943115 -0.5958252 -1.3898926 -1.3898926 -1.3898926z" fill-rule="evenodd"/><path fill="#ffffff" d="m1389.6012 454.60333c-33.756958 0 -60.96118 27.402649 -60.96118 60.96112c0 33.756897 27.40271 60.960876 60.96118 60.960876c33.756836 0 60.960815 -27.402649 60.960815 -60.960876c0 -33.55847 -27.20398 -60.96112 -60.960815 -60.96112zm-17.672852 27.998474c0 -1.588562 1.1914062 -2.5815125 2.7799072 -2.5815125c5.9571533 0 11.914307 0 17.871338 0c5.9571533 0 14.495728 0 20.25415 0c2.1843262 0 2.9786377 0.99295044 2.9786377 2.9786682c0 2.3828125 0 4.7656555 0 7.1484985c0 1.7870178 -0.9929199 2.7799988 -2.7799072 2.7799988c-0.39746094 0 -0.5958252 0 -0.993042 0c-11.3186035 0 -25.41687 0 -36.73535 0c-0.39733887 0 -0.79418945 0 -1.1914062 0c-1.588501 -0.19869995 -2.3828125 -0.99298096 -2.3828125 -2.5815125c0.19848633 -2.382843 0.19848633 -4.9641724 0.19848633 -7.7441406zm0 14.892639c0 -1.588562 1.1914062 -2.5812988 2.7799072 -2.5812988c5.9571533 0 11.914307 0 17.871338 0c5.9571533 0 15.290039 0 21.24707 0c2.184204 0 2.9785156 0.9927368 2.9785156 2.9784546c0 2.382843 0 4.765686 0 7.1484985c0 1.787262 -0.99279785 2.7799988 -2.7800293 2.7799988c-0.39709473 0 -0.59558105 0 -0.9926758 0c-11.3186035 0 -26.211548 0 -37.728394 0c-0.39733887 0 -0.79418945 0 -1.1914062 0c-1.588501 -0.19848633 -2.3828125 -0.9927368 -2.3828125 -2.5812988c0.19848633 -2.382843 0.19848633 -5.162842 0.19848633 -7.7443542zm45.273926 15.289978c0 2.3828735 0 4.765686 0 7.1485596c0 1.7869873 -0.9926758 2.7799683 -2.7800293 2.7799683c-0.39709473 0 -0.59558105 0 -0.9926758 0c-11.3186035 0 -26.211304 0 -37.72827 0c-0.3972168 0 -0.79455566 0 -1.1914062 0c-1.5888672 -0.19866943 -2.3829346 -0.99298096 -2.3829346 -2.581543c0 -2.5812988 0 -5.361267 0 -7.942749c0 -1.5885925 1.1914062 -2.5813293 2.7797852 -2.5813293c5.9571533 0 11.914185 0 17.871338 0c5.9570312 0 15.290039 0 21.24707 0c2.1844482 0.19845581 3.177124 0.9927368 3.177124 3.1770935zm7.347046 15.488464c-0.39697266 0.9927368 -0.99279785 1.9857178 -1.7871094 2.5812988c-2.9783936 2.581543 -6.1557617 5.162842 -9.332642 7.5457153c-2.9786377 2.3828125 -6.751587 3.5742188 -10.325684 4.765625c-2.581421 0.99298096 -5.162842 1.9857178 -7.942749 2.581543c-2.3830566 0.59558105 -4.765747 0.7942505 -7.347168 0.9927368c-3.5743408 0.19866943 -7.1485596 0 -10.722778 0c-1.7871094 0 -3.3756104 0.5958252 -4.9642334 1.588562c-3.177246 2.1843872 -6.354248 4.765686 -9.332886 7.5456543c-0.19848633 0.19866943 -0.19848633 0.19866943 -0.59558105 0.39715576c-3.9714355 -4.765686 -8.1414795 -9.531372 -12.112915 -14.495483c0.19873047 -0.19873047 0.5958252 -0.39715576 0.7943115 -0.5958252c3.177124 -2.184204 6.354248 -4.3685303 9.332886 -6.5527344c1.1914062 -0.7942505 2.184204 -1.9857178 2.9785156 -3.177124c3.3757324 -3.9713745 7.7441406 -5.5599365 12.9071045 -4.9643555c4.169922 0.39715576 8.141235 1.7872314 11.914185 3.5742798c1.3898926 0.5958252 2.7797852 0.7942505 4.169922 0.7942505c3.5742188 0.19873047 6.9500732 0.39715576 10.524048 0.7943115c0.19873047 0 0.19873047 0 0.39733887 0c1.1914062 0.39715576 2.3828125 0.5958252 2.5812988 1.9857178c0.19873047 1.588562 -0.39709473 2.7799683 -1.588501 3.5742188c-1.588623 0.99298096 -3.5742188 1.3901367 -5.5599365 1.7872314c-2.9785156 0.5956421 -5.9571533 0.19848633 -9.134277 0c-2.7799072 -0.19866943 -5.5599365 -0.19866943 -8.339966 -0.39709473c-0.39709473 0 -0.79418945 0 -0.9926758 0.1984253c0 0 0 0.19866943 0 0.19866943c0.7940674 0 1.588501 0.19848633 2.3828125 0.19848633c2.9783936 0.39715576 5.758423 0.7942505 8.737061 0.99298096c4.169922 0.39709473 8.141235 0.1984253 12.112671 -1.1914673c2.581543 -0.9929199 4.170044 -2.7799683 4.170044 -5.758606c0 -0.19848633 0.19848633 -0.5956421 0.3972168 -0.7943115c0.39709473 -0.39709473 0.7940674 -0.59558105 1.1914062 -0.7942505c3.772705 -1.7870483 7.346924 -3.772705 11.119873 -5.5599365c0.7943115 -0.39715576 1.588623 -0.5956421 2.3826904 -0.7943115c1.3900146 0.19866943 2.581421 1.3900757 1.9857178 2.9786377z" fill-rule="evenodd"/><path fill="#ffffff" d="m1377.8854 514.9686c-0.7943115 0 -1.3898926 0.59558105 -1.3898926 1.3898926c0 0.7942505 0.59558105 1.3900757 1.3898926 1.3900757c0.7943115 0 1.3901367 -0.5958252 1.3901367 -1.3900757c0 -0.7943115 -0.5958252 -1.3898926 -1.3901367 -1.3898926z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m1510.0477 590.8095l231.84253 0l0 69.25989l-231.84253 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m1543.4553 633.20953l0 -28.4375l8.03125 0q3.71875 0 6.5625 1.640625q2.859375 1.640625 4.40625 4.671875q1.546875 3.015625 1.578125 6.953125l0 1.8125q0 4.015625 -1.5625 7.046875q-1.546875 3.03125 -4.4375 4.65625q-2.875 1.609375 -6.703125 1.65625l-7.875 0zm3.75 -25.359375l0 22.296875l3.953125 0q4.328125 0 6.734375 -2.6875q2.421875 -2.703125 2.421875 -7.6875l0 -1.65625q0 -4.84375 -2.28125 -7.53125q-2.265625 -2.6875 -6.453125 -2.734375l-4.375 0zm25.839844 25.359375l-3.609375 0l0 -21.140625l3.609375 0l0 21.140625zm-3.90625 -26.734375q0 -0.890625 0.53125 -1.484375q0.546875 -0.609375 1.59375 -0.609375q1.0625 0 1.609375 0.609375q0.546875 0.59375 0.546875 1.484375q0 0.875 -0.546875 1.46875q-0.546875 0.578125 -1.609375 0.578125q-1.046875 0 -1.59375 -0.578125q-0.53125 -0.59375 -0.53125 -1.46875zm22.003906 21.125q0 -1.46875 -1.109375 -2.265625q-1.109375 -0.8125 -3.859375 -1.390625q-2.734375 -0.59375 -4.34375 -1.40625q-1.609375 -0.828125 -2.390625 -1.953125q-0.765625 -1.140625 -0.765625 -2.703125q0 -2.609375 2.1875 -4.40625q2.203125 -1.796875 5.625 -1.796875q3.59375 0 5.828125 1.859375q2.234375 1.859375 2.234375 4.75l-3.625 0q0 -1.484375 -1.265625 -2.5625q-1.25 -1.078125 -3.171875 -1.078125q-1.96875 0 -3.09375 0.859375q-1.109375 0.859375 -1.109375 2.25q0 1.3125 1.03125 1.984375q1.046875 0.65625 3.75 1.265625q2.703125 0.59375 4.375 1.4375q1.6875 0.84375 2.5 2.03125q0.8125 1.171875 0.8125 2.875q0 2.828125 -2.265625 4.546875q-2.265625 1.703125 -5.875 1.703125q-2.546875 0 -4.5 -0.890625q-1.953125 -0.90625 -3.0625 -2.515625q-1.09375 -1.609375 -1.09375 -3.484375l3.609375 0q0.09375 1.8125 1.453125 2.875q1.359375 1.0625 3.59375 1.0625q2.046875 0 3.28125 -0.828125q1.25 -0.828125 1.25 -2.21875zm13.21875 -20.640625l0 5.109375l3.9375 0l0 2.796875l-3.9375 0l0 13.109375q0 1.265625 0.515625 1.90625q0.53125 0.625 1.8125 0.625q0.625 0 1.71875 -0.234375l0 2.9375q-1.4375 0.390625 -2.78125 0.390625q-2.421875 0 -3.65625 -1.46875q-1.21875 -1.46875 -1.21875 -4.15625l0 -13.109375l-3.859375 0l0 -2.796875l3.859375 0l0 -5.109375l3.609375 0zm18.378906 8.359375q-0.828125 -0.140625 -1.78125 -0.140625q-3.546875 0 -4.828125 3.03125l0 15.0l-3.609375 0l0 -21.140625l3.515625 0l0.0625 2.453125q1.78125 -2.84375 5.03125 -2.84375q1.0625 0 1.609375 0.28125l0 3.359375zm7.2382812 17.890625l-3.609375 0l0 -21.140625l3.609375 0l0 21.140625zm-3.90625 -26.734375q0 -0.890625 0.53125 -1.484375q0.546875 -0.609375 1.59375 -0.609375q1.0625 0 1.609375 0.609375q0.546875 0.59375 0.546875 1.484375q0 0.875 -0.546875 1.46875q-0.546875 0.578125 -1.609375 0.578125q-1.046875 0 -1.59375 -0.578125q-0.53125 -0.59375 -0.53125 -1.46875zm27.582031 16.40625q0 4.84375 -2.234375 7.78125q-2.21875 2.9375 -5.96875 2.9375q-4.0 0 -6.1875 -2.828125l-0.171875 2.4375l-3.328125 0l0 -30.0l3.609375 0l0 11.1875q2.1875 -2.71875 6.03125 -2.71875q3.859375 0 6.046875 2.921875q2.203125 2.90625 2.203125 7.96875l0 0.3125zm-3.609375 -0.421875q0 -3.6875 -1.4375 -5.6875q-1.421875 -2.015625 -4.09375 -2.015625q-3.578125 0 -5.140625 3.3125l0 9.140625q1.671875 3.328125 5.1875 3.328125q2.59375 0 4.03125 -2.015625q1.453125 -2.015625 1.453125 -6.0625zm21.207031 8.65625q-2.109375 2.484375 -6.1875 2.484375q-3.375 0 -5.15625 -1.953125q-1.765625 -1.96875 -1.78125 -5.828125l0 -13.75l3.609375 0l0 13.65625q0 4.8125 3.90625 4.8125q4.140625 0 5.515625 -3.09375l0 -15.375l3.609375 0l0 21.140625l-3.4375 0l-0.078125 -2.09375zm13.910156 -24.15625l0 5.109375l3.9375 0l0 2.796875l-3.9375 0l0 13.109375q0 1.265625 0.515625 1.90625q0.53125 0.625 1.8125 0.625q0.625 0 1.71875 -0.234375l0 2.9375q-1.4375 0.390625 -2.78125 0.390625q-2.421875 0 -3.65625 -1.46875q-1.21875 -1.46875 -1.21875 -4.15625l0 -13.109375l-3.859375 0l0 -2.796875l3.859375 0l0 -5.109375l3.609375 0zm16.925781 26.640625q-4.296875 0 -7.0 -2.8125q-2.6875 -2.828125 -2.6875 -7.5625l0 -0.65625q0 -3.15625 1.203125 -5.625q1.203125 -2.46875 3.359375 -3.859375q2.15625 -1.40625 4.6875 -1.40625q4.109375 0 6.390625 2.71875q2.296875 2.71875 2.296875 7.78125l0 1.5l-14.3125 0q0.078125 3.125 1.8125 5.046875q1.75 1.921875 4.453125 1.921875q1.90625 0 3.234375 -0.78125q1.328125 -0.78125 2.328125 -2.0625l2.203125 1.71875q-2.65625 4.078125 -7.96875 4.078125zm-0.4375 -18.953125q-2.1875 0 -3.671875 1.59375q-1.484375 1.59375 -1.84375 4.46875l10.59375 0l0 -0.28125q-0.15625 -2.75 -1.484375 -4.265625q-1.328125 -1.515625 -3.59375 -1.515625z" fill-rule="nonzero"/><path fill="#ffffff" d="m1645.9504 502.0177c1.9921875 0 3.5859375 -1.59375 3.5859375 -3.5859375c0 -1.992218 -1.59375 -3.585968 -3.5859375 -3.585968c-1.9921875 0 -3.5859375 1.59375 -3.5859375 3.585968c0 1.9921875 1.59375 3.5859375 3.5859375 3.5859375z" fill-rule="evenodd"/><path fill="#ffffff" d="m1601.1261 511.58026c0 1.760437 -1.4272461 3.1875 -3.1875 3.1875c-1.760498 0 -3.187622 -1.427063 -3.187622 -3.1875c0 -1.7604675 1.4273682 -3.1875305 3.187622 -3.1875305c1.760376 0 3.1875 1.427063 3.1875 3.1875305z" fill-rule="evenodd"/><path fill="#ffffff" d="m1600.3292 525.52563c-3.984375 0 -7.371216 3.187561 -7.371216 7.371277c0 3.984375 3.1875 7.3710327 7.371216 7.3710327c3.984375 0 7.3710938 -3.1875 7.3710938 -7.3710327c0 -4.183716 -3.3867188 -7.371277 -7.3710938 -7.371277z" fill-rule="evenodd"/><path fill="#ffffff" d="m1661.888 523.33417c0 4.070984 -3.300293 7.371216 -7.371338 7.371216c-4.070923 0 -7.3709717 -3.300232 -7.3709717 -7.371216c0 -4.070984 3.3000488 -7.3710327 7.3709717 -7.3710327c4.071045 0 7.371338 3.3000488 7.371338 7.3710327z" fill-rule="evenodd"/><path fill="#ffffff" d="m1623.6378 454.60333c-33.66809 0 -60.961304 27.293243 -60.961304 60.961304c0 33.668274 27.293213 60.961365 60.961304 60.961365c33.668213 0 60.961304 -27.29309 60.961304 -60.961365c0 -33.66806 -27.29309 -60.961304 -60.961304 -60.961304zm30.87915 80.48486c-6.375 0 -11.554932 -5.1796875 -11.554932 -11.554749l-9.761719 -2.390625c-0.796875 1.7930908 -1.9921875 3.1875 -3.5859375 4.183716l3.5859375 12.351624c0 0 0 0 0 0c4.183716 0 7.5704346 3.3866577 7.5704346 7.5703735c0 4.1835327 -3.3867188 7.5703735 -7.5704346 7.5703735c-4.183716 0 -7.5703125 -3.3868408 -7.5703125 -7.5703735c0 -2.5899658 1.1953125 -4.78125 3.3865967 -6.1759033l-3.5856934 -12.351685c-0.19934082 0 -0.39868164 0 -0.5977783 0c-1.9921875 0 -3.984375 -0.5975342 -5.3789062 -1.7928467l-7.7696533 4.58197c0.3984375 1.1953125 0.5977783 2.1915283 0.5977783 3.3868408c0 6.375 -5.1799316 11.554749 -11.55481 11.554749c-6.375 0 -11.554932 -5.1797485 -11.554932 -11.554749c0 -6.375061 5.1799316 -11.554749 11.554932 -11.554749c3.5860596 0 6.7735596 1.59375 8.964844 4.3828125l6.9727783 -4.183716c-0.3984375 -0.9959717 -0.796875 -2.1913452 -0.796875 -3.3866577l-11.15625 -2.7890625c-1.3946533 2.390625 -3.7852783 3.7850952 -6.574341 3.7850952c-4.1835938 0 -7.5704346 -3.3866577 -7.5704346 -7.5703735c0 -4.1835327 3.3868408 -7.5703735 7.5704346 -7.5703735c3.984375 0 7.171875 3.1875305 7.5703125 6.972809l10.957153 2.789093c0.5975342 -1.1953125 1.3945312 -2.3906555 2.390503 -3.1875305l-3.3867188 -5.976593c-0.9959717 0.3984375 -2.1912842 0.5975342 -3.3865967 0.5975342c-6.375 0 -11.55481 -5.179718 -11.55481 -11.554749c0 -6.3750305 5.1798096 -11.554749 11.55481 -11.554749c6.375 0 11.55481 5.179718 11.55481 11.554749c0 3.585968 -1.59375 6.972809 -4.3829346 9.164124l3.3867188 5.976593c0.796875 -0.19909668 1.59375 -0.3984375 2.390625 -0.3984375c2.1915283 0 4.3828125 0.796875 5.9765625 2.1915283l8.36731 -8.566559c-0.5977783 -1.1953125 -0.99609375 -2.3906555 -0.99609375 -3.7850952c0 -4.3828125 3.5860596 -7.9687805 7.968872 -7.9687805c4.3825684 0 7.96875 3.585968 7.96875 7.9687805c0 4.382843 -3.5861816 7.968811 -7.96875 7.968811c-1.3946533 0 -2.7890625 -0.3984375 -3.984375 -1.1953125l-8.765747 8.964783c0.3984375 0.796875 0.5975342 1.7930908 0.5975342 2.7890625l9.761963 2.390686c1.7928467 -4.58197 5.9765625 -7.5703735 10.956909 -7.5703735c6.375122 0 11.55481 5.1796875 11.55481 11.554749c-0.5975342 6.574341 -5.777466 11.953186 -12.152344 11.953186z" fill-rule="evenodd"/><path fill="#ffffff" d="m1611.6847 501.0217c3.984497 0 7.3710938 -3.3868408 7.3710938 -7.3712463c0 -3.984375 -3.3865967 -7.3710327 -7.3710938 -7.3710327c-3.984375 0 -7.371216 3.3866577 -7.371216 7.3710327c0 3.9844055 3.3868408 7.3712463 7.371216 7.3712463z" fill-rule="evenodd"/><path fill="#ffffff" d="m1633.0012 541.8617c-1.7928467 0 -3.1875 1.3944702 -3.1875 3.187561c0 1.7930908 1.3946533 3.1875 3.1875 3.1875c1.7930908 0 3.1875 -1.3944092 3.1875 -3.1875c0 -1.7930908 -1.3944092 -3.187561 -3.1875 -3.187561z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m817.7978 1047.7086l283.4859 0l0 70.60742l-283.4859 0z" fill-rule="evenodd"/><path fill="#444345" d="m848.7509 1080.338l-13.96875 0l0 11.421875l16.234375 0l0 3.46875l-20.484375 0l0 -32.21875l20.25 0l0 3.484375l-16.0 0l0 10.359375l13.96875 0l0 3.484375zm10.77832 -9.0625l0.140625 3.015625q2.734375 -3.453125 7.171875 -3.453125q7.59375 0 7.65625 8.5625l0 15.828125l-4.09375 0l0 -15.84375q-0.03125 -2.59375 -1.1875 -3.828125q-1.15625 -1.25 -3.625 -1.25q-1.984375 0 -3.5 1.0625q-1.5 1.0625 -2.34375 2.796875l0 17.0625l-4.09375 0l0 -23.953125l3.875 0zm29.041382 18.390625l5.9375 -18.390625l4.171875 0l-8.578125 23.953125l-3.125 0l-8.671875 -23.953125l4.171875 0l6.09375 18.390625zm18.502686 5.5625l-4.09375 0l0 -23.953125l4.09375 0l0 23.953125zm-4.421875 -30.296875q0 -1.0 0.609375 -1.6875q0.609375 -0.6875 1.796875 -0.6875q1.203125 0 1.8125 0.6875q0.625 0.6875 0.625 1.6875q0 1.0 -0.625 1.671875q-0.609375 0.65625 -1.8125 0.65625q-1.1875 0 -1.796875 -0.65625q-0.609375 -0.671875 -0.609375 -1.671875zm22.546936 10.015625q-0.921875 -0.140625 -2.015625 -0.140625q-4.03125 0 -5.46875 3.421875l0 17.0l-4.09375 0l0 -23.953125l3.984375 0l0.078125 2.765625q2.0 -3.203125 5.703125 -3.203125q1.1875 0 1.8125 0.3125l0 3.796875zm2.2391357 8.09375q0 -3.53125 1.375 -6.34375q1.390625 -2.8125 3.859375 -4.328125q2.46875 -1.53125 5.625 -1.53125q4.890625 0 7.90625 3.390625q3.03125 3.375 3.03125 9.0l0 0.296875q0 3.484375 -1.34375 6.265625q-1.328125 2.78125 -3.828125 4.328125q-2.484375 1.546875 -5.71875 1.546875q-4.859375 0 -7.890625 -3.375q-3.015625 -3.390625 -3.015625 -8.96875l0 -0.28125zm4.109375 0.484375q0 3.984375 1.84375 6.390625q1.859375 2.40625 4.953125 2.40625q3.125 0 4.953125 -2.4375q1.84375 -2.453125 1.84375 -6.84375q0 -3.953125 -1.875 -6.390625q-1.859375 -2.453125 -4.96875 -2.453125q-3.03125 0 -4.890625 2.421875q-1.859375 2.40625 -1.859375 6.90625zm26.694946 -12.25l0.140625 3.015625q2.734375 -3.453125 7.171875 -3.453125q7.59375 0 7.65625 8.5625l0 15.828125l-4.09375 0l0 -15.84375q-0.03125 -2.59375 -1.1875 -3.828125q-1.15625 -1.25 -3.625 -1.25q-1.984375 0 -3.5 1.0625q-1.5 1.0625 -2.34375 2.796875l0 17.0625l-4.09375 0l0 -23.953125l3.875 0zm24.994507 0l0.109375 2.65625q2.625 -3.09375 7.109375 -3.09375q5.015625 0 6.828125 3.84375q1.203125 -1.71875 3.109375 -2.78125q1.921875 -1.0625 4.53125 -1.0625q7.875 0 8.015625 8.34375l0 16.046875l-4.09375 0l0 -15.796875q0 -2.578125 -1.171875 -3.84375q-1.171875 -1.28125 -3.953125 -1.28125q-2.265625 0 -3.78125 1.375q-1.5 1.359375 -1.75 3.65625l0 15.890625l-4.109375 0l0 -15.6875q0 -5.234375 -5.109375 -5.234375q-4.03125 0 -5.515625 3.4375l0 17.484375l-4.09375 0l0 -23.953125l3.875 0zm45.80664 24.390625q-4.859375 0 -7.921875 -3.1875q-3.046875 -3.203125 -3.046875 -8.5625l0 -0.75q0 -3.5625 1.359375 -6.359375q1.359375 -2.796875 3.796875 -4.375q2.453125 -1.59375 5.3125 -1.59375q4.671875 0 7.25 3.078125q2.59375 3.078125 2.59375 8.8125l0 1.703125l-16.21875 0q0.078125 3.53125 2.0625 5.71875q1.984375 2.171875 5.03125 2.171875q2.171875 0 3.671875 -0.875q1.515625 -0.890625 2.640625 -2.34375l2.5 1.9375q-3.0 4.625 -9.03125 4.625zm-0.5 -21.46875q-2.484375 0 -4.171875 1.8125q-1.671875 1.796875 -2.078125 5.046875l12.0 0l0 -0.296875q-0.171875 -3.125 -1.6875 -4.84375q-1.5 -1.71875 -4.0625 -1.71875zm18.45166 -2.921875l0.140625 3.015625q2.734375 -3.453125 7.171875 -3.453125q7.59375 0 7.65625 8.5625l0 15.828125l-4.09375 0l0 -15.84375q-0.03125 -2.59375 -1.1875 -3.828125q-1.15625 -1.25 -3.625 -1.25q-1.984375 0 -3.5 1.0625q-1.5 1.0625 -2.34375 2.796875l0 17.0625l-4.09375 0l0 -23.953125l3.875 0zm26.697632 -5.796875l0 5.796875l4.46875 0l0 3.171875l-4.46875 0l0 14.84375q0 1.4375 0.59375 2.171875q0.59375 0.71875 2.03125 0.71875q0.71875 0 1.953125 -0.265625l0 3.3125q-1.609375 0.4375 -3.140625 0.4375q-2.75 0 -4.140625 -1.65625q-1.390625 -1.65625 -1.390625 -4.71875l0 -14.84375l-4.359375 0l0 -3.171875l4.359375 0l0 -5.796875l4.09375 0z" fill-rule="nonzero"/><path fill="#6d6d6d" d="m786.0886 1045.8226c-1.6807251 -10.924927 -11.261108 -19.496582 -22.690002 -19.496582c-4.370056 0 -8.403687 1.1763916 -12.101501 3.3614502c-5.5463867 -9.244202 -15.294678 -14.95874 -26.219604 -14.95874c-16.807495 0 -30.589417 13.7821045 -30.589417 30.5896c0 0.16809082 0 0.16809082 0 0.33605957c-10.924927 1.848999 -19.328613 11.261108 -19.328613 22.690186c0 12.605469 10.588562 23.026123 23.194275 23.026123l1.3446045 0l0 -38.152832c0 -4.369873 3.6976318 -8.067505 8.067566 -8.067505l64.37244 0c4.369934 0 8.067749 3.6976318 8.067749 8.067505l0 38.321045l2.520996 0c12.605713 0 23.194275 -10.252686 23.194275 -23.026367c-0.16815186 -11.429077 -8.907837 -20.841187 -19.832764 -22.689941z" fill-rule="evenodd"/><path fill="#f15a27" d="m708.3697 1073.2186c0.67230225 0 1.3445435 0 2.0168457 0c18.99237 0 37.984863 0 56.977173 0c0.5043335 0 1.0084839 0 1.5127563 0c3.0253296 -0.16809082 4.537964 -1.6806641 4.537964 -4.7060547c0 -4.0338135 0 -7.899414 0 -11.93335c0 -3.6976318 -1.5126343 -5.210205 -5.0422363 -5.210205c-9.748169 0 -19.664673 0 -29.412964 0c-9.916504 0 -20.000977 0 -29.917236 0c-2.8573608 0 -4.7061157 1.5125732 -4.7061157 4.2019043c0 4.369751 0 8.907837 0 13.277832c0 2.689209 1.5125732 4.201782 4.0338135 4.369873zm1.0084229 -18.65625c19.832764 0 39.66559 0 59.330383 0c1.3444214 0 2.0167236 0.6722412 2.0167236 2.0168457c0 4.0339355 0 7.899536 0 11.93335c0 1.6807861 -1.0083008 2.0169678 -2.5210571 2.0169678c-9.748291 0 -19.328613 0 -29.076965 0c-9.748291 0 -19.328491 0 -29.076782 0c-2.5211792 0 -2.689209 -0.16821289 -2.689209 -2.689209c0 -3.6976318 0 -7.3952637 0 -11.0928955c0 -1.6807861 0.5041504 -2.1850586 2.0169067 -2.1850586z" fill-rule="evenodd"/><path fill="#f15a27" d="m713.916 1085.4883c-1.1765747 0 -2.3530273 1.1765137 -2.3530273 2.3530273c0 1.3446045 1.1764526 2.3530273 2.5212402 2.3530273c1.3444214 0 2.3528442 -1.0084229 2.3528442 -2.3530273c0 -1.3446045 -1.1764526 -2.3530273 -2.5210571 -2.3530273z" fill-rule="evenodd"/><path fill="#f15a27" d="m722.6559 1085.4883c-1.3446045 0 -2.3530273 0.8404541 -2.3530273 2.1848145c-0.16815186 1.3446045 1.0084229 2.5212402 2.3530273 2.5212402c1.1764526 0 2.3530273 -1.0084229 2.5210571 -2.1849365c-0.16802979 -1.3446045 -1.3446045 -2.5211182 -2.5210571 -2.5211182z" fill-rule="evenodd"/><path fill="#f15a27" d="m731.05963 1085.4883c-1.3446045 0 -2.3530273 1.0084229 -2.3530273 2.3530273c0 1.3446045 1.0084229 2.3530273 2.1849976 2.3530273c1.3444214 0 2.3529053 -1.0084229 2.3529053 -2.3530273c0.16815186 -1.3446045 -0.840271 -2.3530273 -2.1848755 -2.3530273z" fill-rule="evenodd"/><path fill="#f15a27" d="m722.48773 1109.8589c-1.3446045 0 -2.3530273 1.1766357 -2.3530273 2.3530273c0 1.3446045 0.8404541 2.1850586 2.1850586 2.3530273c1.3446045 0.16809082 2.520996 -1.0084229 2.520996 -2.3530273c0.16821289 -1.1763916 -1.0084229 -2.3530273 -2.3530273 -2.3530273z" fill-rule="evenodd"/><path fill="#f15a27" d="m714.0842 1109.8589c-1.1766357 0 -2.5212402 1.0084229 -2.5212402 2.3530273c0 1.1765137 1.1764526 2.3530273 2.3530273 2.3530273c1.3446045 0 2.3530884 -1.0084229 2.3530884 -2.3530273c0 -1.3446045 -1.0084839 -2.3530273 -2.1848755 -2.3530273z" fill-rule="evenodd"/><path fill="#f15a27" d="m730.8915 1109.8589c-1.3446045 0 -2.3530273 1.1766357 -2.1848755 2.5212402c0 1.3446045 1.1763916 2.1848145 2.3530273 2.1848145c1.3446045 0 2.3530273 -1.1763916 2.1848755 -2.520996c0 -1.1766357 -1.0084229 -2.3532715 -2.3530273 -2.1850586z" fill-rule="evenodd"/><path fill="#f15a27" d="m722.48773 1064.815c1.3446045 0 2.3530273 -1.1763916 2.3530273 -2.520996c0 -1.1766357 -1.1763916 -2.1850586 -2.3530273 -2.1850586c-1.3446045 0 -2.3530273 1.1766357 -2.3530273 2.5212402c0.16815186 1.1763916 1.1764526 2.1848145 2.3530273 2.1848145z" fill-rule="evenodd"/><path fill="#f15a27" d="m713.916 1064.815c1.3446045 0 2.3530884 -1.0084229 2.3530884 -2.3530273c0 -1.3446045 -1.0084839 -2.3530273 -2.1848755 -2.3530273c-1.3447876 0 -2.5212402 1.0084229 -2.5212402 2.3530273c0 1.1766357 1.1764526 2.1850586 2.3530273 2.3530273z" fill-rule="evenodd"/><path fill="#f15a27" d="m731.05963 1064.815c1.3446045 0 2.1848755 -1.0084229 2.1848755 -2.3530273c0 -1.3446045 -1.0084839 -2.3530273 -2.3529053 -2.3530273c-1.3445435 0 -2.1849976 1.0084229 -2.1849976 2.3530273c0 1.1766357 1.0084229 2.3530273 2.3530273 2.3530273z" fill-rule="evenodd"/><path fill="#f15a27" d="m768.87646 1076.9164c-9.916443 0 -19.832764 0 -29.917236 0c-9.916504 0 -19.832825 0 -29.917236 0c-3.1935425 0 -4.7061157 1.6806641 -4.7061157 4.7060547c0 3.8657227 0 7.7314453 0 11.597168c0 4.0338135 1.3446045 5.378418 5.54657 5.378418c7.227112 0 14.6223755 0 21.84967 0l0 0c2.520996 0 4.8740845 0 7.3950806 0c2.5212402 0 4.8742676 0 7.3952637 0l0 0c7.227295 0 14.62262 0 21.849731 0c4.0337524 0 5.546509 -1.3446045 5.546509 -5.378418c0 -3.8657227 0 -7.7314453 0 -11.597168c-0.3361206 -3.0253906 -2.0169067 -4.7060547 -5.0422363 -4.7060547zm1.6807861 16.135132c0 2.689209 0 2.689209 -2.689209 2.689209c-9.580322 0 -19.328491 0 -28.908813 0c-9.580322 0 -19.328674 0 -28.908813 0c-2.689209 0 -2.689209 0 -2.689209 -2.689209c0 -3.6976318 0 -7.227173 0 -10.924805c0 -1.5126953 0.33618164 -2.1850586 2.0169067 -2.1850586c7.3952637 0 14.790527 0 22.185852 0l0 0c2.520996 0 4.8740234 0 7.3952637 0c2.520996 0 4.8740845 0 7.3952637 0l0 0c7.3952637 0 14.790588 0 22.185852 0c1.6807251 0 2.0169067 0.6723633 2.0169067 2.1850586c0 3.6976318 0 7.227173 0 10.924805z" fill-rule="evenodd"/><path fill="#f15a27" d="m740.63995 1134.3977c0 -0.16796875 -0.16815186 -0.16796875 -0.16815186 -0.33605957c0 -4.0338135 0 -6.7230225 0 -10.924927c0.67230225 0 1.1765747 0 1.848877 0c0 0 0 0 0.16802979 0c8.571838 0 17.311584 0 25.883423 0c3.8658447 0 5.378418 -1.5125732 5.378418 -5.378296c0 -3.8657227 0 -7.5633545 0 -11.429199c0 -3.529419 -1.6807251 -5.210205 -5.210205 -5.210205c-6.5549927 0 -12.9418335 0 -19.496643 0c-0.8404541 0 -1.6807861 0 -2.5212402 0l0 0c-2.520996 0 -4.8740845 0 -7.3952637 0c-2.520996 0 -4.8740845 0 -7.3952637 0l0 0c-0.840271 0 -1.6807251 0 -2.5210571 0c-6.5549927 0 -12.9418335 0 -19.496643 0c-3.6976318 0 -5.210388 1.6807861 -5.210388 5.210205c0 3.8658447 0 7.5634766 0 11.429199c0 3.6975098 1.5127563 5.210327 5.378418 5.378296c8.571838 0 17.311768 0 25.883423 0c0 0 0 0 0.16821289 0c0.67230225 0 1.1763916 0 1.8486938 0c0 4.2019043 0 6.8911133 0 10.924927c0 0.16809082 0 0.16809082 -0.16796875 0.33605957m32.942566 -16.807373c0 2.3530273 -0.16815186 2.520996 -2.5211792 2.520996c-9.748291 0 -19.328491 0 -29.076782 0c-9.748352 0 -19.328674 0 -29.076965 0c-2.3530884 0 -2.5210571 -0.16796875 -2.5210571 -2.520996c0 -3.8656006 0 -7.5634766 0 -11.429077c0 -1.3446045 0.5041504 -2.0168457 1.6807251 -2.0168457c9.916321 0 19.832825 0 29.917297 0c10.084473 0 20.000732 0 29.917236 0c1.3446045 0 1.8487549 0.6722412 1.6807251 2.0168457c0 3.8656006 0 7.5634766 0 11.429077z" fill-rule="evenodd"/><path fill="#f15a27" d="m738.9592 1133.0532c-3.1933594 0 -5.7145386 2.5211182 -5.7145386 5.7144775c0 3.1933594 2.5211792 5.7144775 5.7145386 5.7144775c3.1932983 0 5.7144775 -2.5211182 5.7144775 -5.7144775c0 -3.1933594 -2.5211792 -5.7144775 -5.7144775 -5.7144775zm0 9.075928c-1.8487549 0 -3.3615112 -1.5125732 -3.3615112 -3.3614502c0 -1.848877 1.5127563 -3.3614502 3.3615112 -3.3614502c1.848877 0 3.3614502 1.5125732 3.3614502 3.3614502c0 1.848877 -1.5125732 3.3614502 -3.3614502 3.3614502z" fill-rule="evenodd"/><path fill="#f15a27" d="m733.917 1138.5997c0 -0.5041504 0 -1.0084229 0.16796875 -1.3446045l-15.126709 0c-0.840271 0 -1.5125732 0.6723633 -1.5125732 1.5128174l0 0c0 0.84020996 0.67230225 1.5125732 1.5125732 1.5125732l15.126709 0c0 -0.5041504 -0.16796875 -1.1766357 -0.16796875 -1.6807861z" fill-rule="evenodd"/><path fill="#f15a27" d="m758.62384 1137.2551l-14.6223755 0c0.16796875 0.5041504 0.16796875 0.8404541 0.16796875 1.3446045c0 0.5041504 -0.16796875 1.1766357 -0.33618164 1.6807861l14.790588 0c0.8404541 0 1.5127563 -0.6723633 1.5127563 -1.5125732l0 0c0 -0.8404541 -0.67230225 -1.5128174 -1.5127563 -1.5128174z" fill-rule="evenodd"/><path fill="#f1c232" fill-opacity="0.2291" d="m502.0667 282.49356l767.22003 0l0 1005.83887l-767.22003 0z" fill-rule="evenodd"/><path stroke="#666666" stroke-width="3.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="12.0,9.0" d="m502.0667 282.49356l767.22003 0l0 1005.83887l-767.22003 0z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m506.3071 1210.8289l767.08655 0l0 56.031494l-767.08655 0z" fill-rule="evenodd"/><path fill="#434343" d="m829.69806 1241.7289l-6.6875 0l0 11.5l-3.765625 0l0 -28.4375l9.421875 0q4.796875 0 7.375 2.1875q2.59375 2.1875 2.59375 6.359375q0 2.65625 -1.4375 4.640625q-1.421875 1.96875 -3.984375 2.9375l6.671875 12.078125l0 0.234375l-4.015625 0l-6.171875 -11.5zm-6.6875 -3.078125l5.765625 0q2.796875 0 4.4375 -1.4375q1.65625 -1.453125 1.65625 -3.875q0 -2.625 -1.578125 -4.03125q-1.5625 -1.40625 -4.53125 -1.4375l-5.75 0l0 10.78125zm33.36328 12.484375q-2.109375 2.484375 -6.1875 2.484375q-3.375 0 -5.15625 -1.953125q-1.765625 -1.96875 -1.78125 -5.828125l0 -13.75l3.609375 0l0 13.65625q0 4.8125 3.90625 4.8125q4.140625 0 5.515625 -3.09375l0 -15.375l3.609375 0l0 21.140625l-3.4375 0l-0.078125 -2.09375zm12.425781 -19.046875l0.109375 2.65625q2.421875 -3.046875 6.328125 -3.046875q6.703125 0 6.765625 7.5625l0 13.96875l-3.609375 0l0 -13.984375q-0.03125 -2.28125 -1.0625 -3.375q-1.015625 -1.09375 -3.1875 -1.09375q-1.75 0 -3.078125 0.9375q-1.328125 0.9375 -2.078125 2.453125l0 15.0625l-3.609375 0l0 -21.140625l3.421875 0zm23.554688 -5.109375l0 5.109375l3.9375 0l0 2.796875l-3.9375 0l0 13.109375q0 1.265625 0.515625 1.90625q0.53125 0.625 1.8125 0.625q0.625 0 1.71875 -0.234375l0 2.9375q-1.4375 0.390625 -2.78125 0.390625q-2.421875 0 -3.65625 -1.46875q-1.21875 -1.46875 -1.21875 -4.15625l0 -13.109375l-3.859375 0l0 -2.796875l3.859375 0l0 -5.109375l3.609375 0zm12.082031 26.25l-3.609375 0l0 -21.140625l3.609375 0l0 21.140625zm-3.90625 -26.734375q0 -0.890625 0.53125 -1.484375q0.546875 -0.609375 1.59375 -0.609375q1.0625 0 1.609375 0.609375q0.546875 0.59375 0.546875 1.484375q0 0.875 -0.546875 1.46875q-0.546875 0.578125 -1.609375 0.578125q-1.046875 0 -1.59375 -0.578125q-0.53125 -0.59375 -0.53125 -1.46875zm13.097656 5.59375l0.09375 2.34375q2.328125 -2.734375 6.265625 -2.734375q4.4375 0 6.03125 3.40625q1.0625 -1.53125 2.75 -2.46875q1.6875 -0.9375 4.0 -0.9375q6.953125 0 7.0625 7.375l0 14.15625l-3.609375 0l0 -13.953125q0 -2.265625 -1.046875 -3.375q-1.03125 -1.125 -3.46875 -1.125q-2.015625 0 -3.34375 1.203125q-1.328125 1.1875 -1.53125 3.21875l0 14.03125l-3.640625 0l0 -13.84375q0 -4.609375 -4.515625 -4.609375q-3.546875 0 -4.859375 3.015625l0 15.4375l-3.609375 0l0 -21.140625l3.421875 0zm40.41797 21.53125q-4.296875 0 -7.0 -2.8125q-2.6875 -2.828125 -2.6875 -7.5625l0 -0.65625q0 -3.15625 1.203125 -5.625q1.203125 -2.46875 3.359375 -3.859375q2.15625 -1.40625 4.6875 -1.40625q4.109375 0 6.390625 2.71875q2.296875 2.71875 2.296875 7.78125l0 1.5l-14.3125 0q0.078125 3.125 1.8125 5.046875q1.75 1.921875 4.453125 1.921875q1.90625 0 3.234375 -0.78125q1.328125 -0.78125 2.328125 -2.0625l2.203125 1.71875q-2.65625 4.078125 -7.96875 4.078125zm-0.4375 -18.953125q-2.1875 0 -3.671875 1.59375q-1.484375 1.59375 -1.84375 4.46875l10.59375 0l0 -0.28125q-0.15625 -2.75 -1.484375 -4.265625q-1.328125 -1.515625 -3.59375 -1.515625z" fill-rule="nonzero"/><path fill="#444345" d="m451.36877 870.121l1656.2699 0l0 93.702576l-1656.2699 0z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m451.74164 890.23987l1656.7244 0l0 70.6142l-1656.7244 0z" fill-rule="evenodd"/><path fill="#ffffff" d="m1183.0531 920.0774l-11.9375 0l0 12.5625l-3.75 0l0 -28.4375l17.625 0l0 3.078125l-13.875 0l0 9.734375l11.9375 0l0 3.0625zm4.4960938 1.796875q0 -3.109375 1.21875 -5.578125q1.21875 -2.484375 3.390625 -3.828125q2.1875 -1.359375 4.984375 -1.359375q4.3125 0 6.96875 3.0q2.671875 2.984375 2.671875 7.9375l0 0.265625q0 3.078125 -1.1875 5.53125q-1.171875 2.453125 -3.375 3.828125q-2.1875 1.359375 -5.046875 1.359375q-4.296875 0 -6.96875 -2.984375q-2.65625 -3.0 -2.65625 -7.921875l0 -0.25zm3.625 0.4375q0 3.515625 1.625 5.640625q1.640625 2.125 4.375 2.125q2.75 0 4.375 -2.15625q1.625 -2.15625 1.625 -6.046875q0 -3.46875 -1.65625 -5.625q-1.640625 -2.171875 -4.375 -2.171875q-2.6875 0 -4.328125 2.140625q-1.640625 2.125 -1.640625 6.09375zm33.1875 8.234375q-2.109375 2.484375 -6.1875 2.484375q-3.375 0 -5.15625 -1.953125q-1.765625 -1.96875 -1.78125 -5.828125l0 -13.75l3.609375 0l0 13.65625q0 4.8125 3.90625 4.8125q4.140625 0 5.515625 -3.09375l0 -15.375l3.609375 0l0 21.140625l-3.4375 0l-0.078125 -2.09375zm12.425781 -19.046875l0.109375 2.65625q2.421875 -3.046875 6.328125 -3.046875q6.703125 0 6.765625 7.5625l0 13.96875l-3.609375 0l0 -13.984375q-0.03125 -2.28125 -1.0625 -3.375q-1.015625 -1.09375 -3.1875 -1.09375q-1.75 0 -3.078125 0.9375q-1.328125 0.9375 -2.078125 2.453125l0 15.0625l-3.609375 0l0 -21.140625l3.421875 0zm17.773438 10.390625q0 -4.859375 2.296875 -7.8125q2.3125 -2.96875 6.046875 -2.96875q3.703125 0 5.875 2.546875l0 -11.015625l3.609375 0l0 30.0l-3.3125 0l-0.1875 -2.265625q-2.15625 2.65625 -6.03125 2.65625q-3.671875 0 -5.984375 -3.0q-2.3125 -3.015625 -2.3125 -7.859375l0 -0.28125zm3.609375 0.421875q0 3.59375 1.484375 5.625q1.484375 2.03125 4.109375 2.03125q3.4375 0 5.015625 -3.09375l0 -9.703125q-1.625 -2.984375 -4.984375 -2.984375q-2.65625 0 -4.140625 2.046875q-1.484375 2.046875 -1.484375 6.078125zm32.871094 10.328125q-0.3125 -0.625 -0.5 -2.234375q-2.53125 2.625 -6.015625 2.625q-3.125 0 -5.140625 -1.765625q-2.0 -1.765625 -2.0 -4.484375q0 -3.296875 2.515625 -5.125q2.515625 -1.828125 7.0625 -1.828125l3.515625 0l0 -1.65625q0 -1.90625 -1.140625 -3.015625q-1.125 -1.125 -3.328125 -1.125q-1.9375 0 -3.25 0.984375q-1.3125 0.96875 -1.3125 2.34375l-3.625 0q0 -1.578125 1.125 -3.046875q1.125 -1.484375 3.046875 -2.34375q1.921875 -0.859375 4.21875 -0.859375q3.65625 0 5.71875 1.828125q2.078125 1.828125 2.15625 5.03125l0 9.734375q0 2.90625 0.75 4.625l0 0.3125l-3.796875 0zm-6.0 -2.75q1.703125 0 3.21875 -0.875q1.53125 -0.890625 2.21875 -2.296875l0 -4.328125l-2.828125 0q-6.640625 0 -6.640625 3.875q0 1.703125 1.125 2.671875q1.140625 0.953125 2.90625 0.953125zm19.617188 -23.5l0 5.109375l3.9375 0l0 2.796875l-3.9375 0l0 13.109375q0 1.265625 0.515625 1.90625q0.53125 0.625 1.8125 0.625q0.625 0 1.71875 -0.234375l0 2.9375q-1.4375 0.390625 -2.78125 0.390625q-2.421875 0 -3.65625 -1.46875q-1.21875 -1.46875 -1.21875 -4.15625l0 -13.109375l-3.859375 0l0 -2.796875l3.859375 0l0 -5.109375l3.609375 0zm12.082031 26.25l-3.609375 0l0 -21.140625l3.609375 0l0 21.140625zm-3.90625 -26.734375q0 -0.890625 0.53125 -1.484375q0.546875 -0.609375 1.59375 -0.609375q1.0625 0 1.609375 0.609375q0.546875 0.59375 0.546875 1.484375q0 0.875 -0.546875 1.46875q-0.546875 0.578125 -1.609375 0.578125q-1.046875 0 -1.59375 -0.578125q-0.53125 -0.59375 -0.53125 -1.46875zm8.738281 15.96875q0 -3.109375 1.21875 -5.578125q1.21875 -2.484375 3.390625 -3.828125q2.1875 -1.359375 4.984375 -1.359375q4.3125 0 6.96875 3.0q2.671875 2.984375 2.671875 7.9375l0 0.265625q0 3.078125 -1.1875 5.53125q-1.171875 2.453125 -3.375 3.828125q-2.1875 1.359375 -5.046875 1.359375q-4.296875 0 -6.96875 -2.984375q-2.65625 -3.0 -2.65625 -7.921875l0 -0.25zm3.625 0.4375q0 3.515625 1.625 5.640625q1.640625 2.125 4.375 2.125q2.75 0 4.375 -2.15625q1.625 -2.15625 1.625 -6.046875q0 -3.46875 -1.65625 -5.625q-1.640625 -2.171875 -4.375 -2.171875q-2.6875 0 -4.328125 2.140625q-1.640625 2.125 -1.640625 6.09375zm23.5625 -10.8125l0.109375 2.65625q2.421875 -3.046875 6.328125 -3.046875q6.703125 0 6.765625 7.5625l0 13.96875l-3.609375 0l0 -13.984375q-0.03125 -2.28125 -1.0625 -3.375q-1.015625 -1.09375 -3.1875 -1.09375q-1.75 0 -3.078125 0.9375q-1.328125 0.9375 -2.078125 2.453125l0 15.0625l-3.609375 0l0 -21.140625l3.421875 0zm31.695312 21.140625q-0.3125 -0.625 -0.5 -2.234375q-2.53125 2.625 -6.015625 2.625q-3.125 0 -5.140625 -1.765625q-2.0 -1.765625 -2.0 -4.484375q0 -3.296875 2.515625 -5.125q2.515625 -1.828125 7.0625 -1.828125l3.515625 0l0 -1.65625q0 -1.90625 -1.140625 -3.015625q-1.125 -1.125 -3.328125 -1.125q-1.9375 0 -3.25 0.984375q-1.3125 0.96875 -1.3125 2.34375l-3.625 0q0 -1.578125 1.125 -3.046875q1.125 -1.484375 3.046875 -2.34375q1.921875 -0.859375 4.21875 -0.859375q3.65625 0 5.71875 1.828125q2.078125 1.828125 2.15625 5.03125l0 9.734375q0 2.90625 0.75 4.625l0 0.3125l-3.796875 0zm-6.0 -2.75q1.703125 0 3.21875 -0.875q1.53125 -0.890625 2.21875 -2.296875l0 -4.328125l-2.828125 0q-6.640625 0 -6.640625 3.875q0 1.703125 1.125 2.671875q1.140625 0.953125 2.90625 0.953125zm18.632812 2.75l-3.609375 0l0 -30.0l3.609375 0l0 30.0z" fill-rule="nonzero"/></g></svg>
\ No newline at end of file
diff --git a/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md
new file mode 100644
index 0000000000..900f8b07ee
--- /dev/null
+++ b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md
@@ -0,0 +1,57 @@
+---
+layout: blog
+title: "Cloud native security for your clusters"
+date: 2020-11-18
+slug: cloud-native-security-for-your-clusters
+---
+
+**Author**: [Pushkar Joglekar](https://twitter.com/pudijoglekar)
+
+Over the last few years a small, security focused community has been working diligently to deepen our understanding of security, given the evolving cloud native infrastructure and corresponding iterative deployment practices. To enable sharing of this knowledge with the rest of the community, members of [CNCF SIG Security](https://github.com/cncf/sig-security) (a group which reports into [CNCF TOC](https://github.com/cncf/toc#sigs) and who are friends with [Kubernetes SIG Security](https://github.com/kubernetes/community/tree/master/sig-security)) led by Emily Fox, collaborated on a whitepaper outlining holistic cloud native security concerns and best practices. After over 1200 comments, changes, and discussions from 35 members across the world, we are proud to share [cloud native security whitepaper v1.0](https://www.cncf.io/blog/2020/11/18/announcing-the-cloud-native-security-white-paper) that serves as essential reading for security leadership in enterprises, financial and healthcare industries, academia, government, and non-profit organizations.
+
+The paper attempts to _not_ focus on any specific [cloud native project](https://www.cncf.io/projects/). Instead, the intent is to model and inject security into four logical phases of cloud native application lifecycle: _Develop, Distribute, Deploy, and Runtime_.
+
+<img alt="Cloud native application lifecycle phases"
+     src="cloud-native-app-lifecycle-phases.svg"
+     style="width:60em;max-width:100%;">
+
+
+## Kubernetes native security controls
+When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are:
+* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster
+* [Resource requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits): Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU
+* [Audit log analysis](/docs/tasks/debug-application-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events
+* [Control plane authentication and certificate root of trust](/docs/concepts/architecture/control-plane-node-communication/): Enable mutual TLS authentication with a trusted CA for communication within the cluster
+* [Secrets management](/docs/concepts/configuration/secret/): Integrate with a built-in or external secrets store
+
+## Cloud native complementary security controls
+
+Kubernetes has direct involvement in the _deploy_ phase and to a lesser extent in the _runtime_ phase. Ensuring the artifacts are securely _developed_ and _distributed_ is necessary for, enabling workloads in Kubernetes to run “secure by default”. Throughout all phases of the Cloud native application life cycle, several complementary security controls exist for Kubernetes orchestrated workloads, which includes but are not limited to:
+* Develop:
+  - Image signing and verification
+  - Image vulnerability scanners
+* Distribute:
+  - Pre-deployment checks for detecting excessive privileges
+  - Enabling observability and logging
+* Deploy:
+  - Using a service mesh for workload authentication and authorization
+  - Enforcing “default deny” network policies for inter-workload communication via [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+* Runtime:
+  - Deploying security monitoring agents for workloads
+  - Isolating applications that run on the same node using SELinux, AppArmor, etc.
+  - Scanning configuration against recognized secure baselines for node, workload and orchestrator
+
+## Understand first, secure next
+The cloud native way, including containers, provides great security benefits for its users: immutability, modularity, faster upgrades and consistent state across the environment. Realizing this fundamental change in “the way things are done”, motivates us to look at security with a cloud native lens. One of the things that was evident for all the authors of the paper was the fact that it’s tough to make smarter decisions on how and what to secure in a cloud native ecosystem if you do not understand the tools, patterns, and frameworks at hand (in addition to knowing your own critical assets). Hence, for all the security practitioners out there who want to be partners rather than a gatekeeper for your friends in Operations, Product Development, and Compliance, let’s make an attempt to _learn more so we can secure better_.
+
+We recommend following this **7 step R.U.N.T.I.M.E. path** to get started on cloud native security:
+1. <b>R</b>ead the paper and any linked material in it
+2. <b>U</b>nderstand challenges and constraints for your environment
+3. <b>N</b>ote the content and controls that apply to your environment
+4. <b>T</b>alk about your observations with your peers
+5. <b>I</b>nvolve your leadership and ask for help
+6. <b>M</b>ake a risk profile based on existing and missing security controls
+7. <b>E</b>xpend time, money, and resources that improve security posture and reduce risk where appropriate.
+
+## Acknowledgements
+Huge shout out to _Emily Fox, Tim Bannister (The Scale Factory), Chase Pettet (Mirantis), and Wayne Haber (GitLab)_ for contributing with their wonderful suggestions for this blog post.
diff --git a/content/en/case-studies/adform/index.html b/content/en/case-studies/adform/index.html
index be35a2d837..1de43d0637 100644
--- a/content/en/case-studies/adform/index.html
+++ b/content/en/case-studies/adform/index.html
@@ -3,116 +3,84 @@ title: Adform Case Study
 linkTitle: Adform
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: adform_featured_logo.png
 draft: false
 featured: true
 weight: 47
 quote: >
   Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/adform/banner1.jpg
+heading_title_logo: /images/adform_logo.png
+subheading: >
+  Improving Performance and Morale with Cloud Native
+case_study_details:
+  - Company: AdForm
+  - Location: Copenhagen, Denmark
+  - Industry: Adtech
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/adform/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/adform_logo.png" style="width:15%;margin-bottom:0%" class="header_logo"><br> <div class="subhead">Improving Performance and Morale with Cloud Native
+<h2>Challenge</h2>
 
-</div></h1>
+<p><a href="https://site.adform.com/">Adform's</a> mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company's growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn't have self-healing infrastructure."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>AdForm</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Copenhagen, Denmark</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Adtech</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    <a href="https://site.adform.com/">Adform’s</a> mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."
-
-
-<br>
-
- <h2>Solution</h2>
-    The team, which had already been using <a href="https://prometheus.io/">Prometheus</a> for monitoring, embraced <a href="https://kubernetes.io/">Kubernetes</a> and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."
-
-
-</div>
-
-<div class="col2">
+<p>The team, which had already been using <a href="https://prometheus.io/">Prometheus</a> for monitoring, embraced <a href="https://kubernetes.io/">Kubernetes</a> and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."</p>
 
 <h2>Impact</h2>
- "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in <a href="https://grafana.com/">Grafana</a> dashboards provides great insight on your systems."
 
+<p>"Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in <a href="https://grafana.com/">Grafana</a> dashboards provides great insight on your systems."</p>
 
-</div>
+{{< case-studies/quote author="Edgaras Apšega, IT Systems Engineer, Adform" >}}
+"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier."  
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
+{{< case-studies/lead >}}
+Adform made <a href="https://www.wsj.com/articles/fake-ad-operation-used-to-steal-from-publishers-is-uncovered-1511290981">headlines</a> last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
+<p>With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a <a href="https://site.adform.com/media/85132/hyphbot_whitepaper_.pdf">white paper</a> revealing what it did—and others could too—to limit customers' exposure to the scam.</p>
 
+<p>In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>Adform made <a href="https://www.wsj.com/articles/fake-ad-operation-used-to-steal-from-publishers-is-uncovered-1511290981">headlines</a> last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day.</h2>With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a <a href="https://site.adform.com/media/85132/hyphbot_whitepaper_.pdf">white paper</a> revealing what it did—and others could too—to limit customers’ exposure to the scam. <br><br>
-In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.<br><br>
-The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."
+<p>The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company's growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn't have self-healing infrastructure."</p>
 
+{{< case-studies/quote
+  image="/images/case-studies/adform/banner3.jpg"
+  author="Edgaras Apšega, IT Systems Engineer, Adform"
+>}}
+"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it's open source, you can contribute."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/adform/banner3.jpg')">
-  <div class="banner3text">
-    "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."</p>
 
-The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."<br><br>
-A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.
-Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they’re still doing it."
-<br><br>
-The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."
+<p>A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.</p>
 
+<p>Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they're still doing it."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/adform/banner4.jpg')">
-  <div class="banner4text">
-"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Andrius Cibulskis, IT Systems Engineer, Adform</span>
-  </div>
-</div>
+<p>The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."</p>
 
-<section class="section5">
-<div class="fullcol">
-This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before. <br><br>
-The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines. <br><br>
-Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."
+{{< case-studies/quote
+  image="/images/case-studies/adform/banner4.jpg"
+  author="Andrius Cibulskis, IT Systems Engineer, Adform"
+>}}
+"Releases are really nice for them, because they just push their code to Git and that's it. They don't have to worry about their virtual machines anymore."  
+{{< /case-studies/quote >}}
 
+<p>This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before.</p>
 
+<p>The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines.</p>
 
-</div>
+<p>Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."</p>
 
-<div class="banner5">
-  <div class="banner5text">
- "I think that our company just started our cloud native journey. It seems like a huge road ahead, but we’re really happy that we joined it." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
-  </div>
-</div>
+{{< case-studies/quote author="Edgaras Apšega, IT Systems Engineer, Adform" >}}
+"I think that our company just started our cloud native journey. It seems like a huge road ahead, but we're really happy that we joined it."  
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they’re happy because they can easily inspect the containers."
-The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it’s cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we’re interested in is the <a href="https://github.com/virtual-kubelet/virtual-kubelet">Virtual Kubelet</a> that lets you spin up the working nodes on different clouds to do some computing."
-<br><br>
-Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we’re really happy that we joined it."
+<p>All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that's it. They don't have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they're happy because they can easily inspect the containers."</p>
 
+<p>The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it's cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we're interested in is the <a href="https://github.com/virtual-kubelet/virtual-kubelet">Virtual Kubelet</a> that lets you spin up the working nodes on different clouds to do some computing."</p>
 
-
-</div>
-
-</section>
+<p>Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we're really happy that we joined it."</p>
diff --git a/content/en/case-studies/adidas/index.html b/content/en/case-studies/adidas/index.html
index 5f9d0da24a..3a95a5aa1b 100644
--- a/content/en/case-studies/adidas/index.html
+++ b/content/en/case-studies/adidas/index.html
@@ -3,106 +3,76 @@ title: adidas Case Study
 linkTitle: adidas
 case_study_styles: true
 cid: caseStudies
-css: /css/case-studies-gradient.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/adidas/banner1.png
+heading_title_text: adidas
+use_gradient_overlay: true
+subheading: >
+  Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year
+case_study_details:
+  - Company: adidas
+  - Location: Herzogenaurach, Germany
+  - Industry: Fashion
 ---
-​
 
+<h2>Challenge</h2>
+
+<p>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."</p>
+
+<h2>Solution</h2>
+
+<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. They found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus.</p>
 
-<div class="article image overlay" style="background-image: url('/images/case-studies/adidas/banner1.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/case-studies/adidas/banner2.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/case-studies/adidas/banner3.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>
+
+<p>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.</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/adidas/banner2.png"
+  author="FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS"
+>}}
+"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."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+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.
+{{< /case-studies/lead >}}
+
+<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>
+
+{{< case-studies/quote author="DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS" >}}
+"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."
+{{< /case-studies/quote >}}
+
+<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>
+
+{{< case-studies/quote 
+  image="/images/case-studies/adidas/banner3.png"
+  author="DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS"
+>}}
+"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."
+{{< /case-studies/quote >}}
+
+<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>
diff --git a/content/en/case-studies/amadeus/index.html b/content/en/case-studies/amadeus/index.html
index 8b6294d4f9..bd647003ec 100644
--- a/content/en/case-studies/amadeus/index.html
+++ b/content/en/case-studies/amadeus/index.html
@@ -1,105 +1,84 @@
 ---
 title: Amadeus Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_amadeus.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/amadeus/banner1.jpg
+heading_title_logo: /images/amadeus_logo.png
+subheading: >
+  Another Technical Evolution for a 30-Year-Old Company
+case_study_details:
+  - Company: Amadeus IT Group
+  - Location: Madrid, Spain
+  - Industry: Travel Technology
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/amadeus_logo.png" class="header_logo"><br> <div class="subhead">Another Technical Evolution for a 30-Year-Old Company
-</div></h1>
-</div>
-<div class="details">
-    Company &nbsp;<b>Amadeus IT Group</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Madrid, Spain</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Travel Technology</b>
-</div>
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-      In the past few years, Amadeus, which provides IT solutions to the travel industry around the world, found itself in need of a new platform for the 5,000 services supported by its service-oriented architecture. The 30-year-old company operates its own data center in Germany, and there were growing demands internally and externally for solutions that needed to be geographically dispersed. And more generally, "we had objectives of being even more highly available," says Eric Mountain, Senior Expert, Distributed Systems at Amadeus. Among the company’s goals: to increase automation in managing its infrastructure, optimize the distribution of workloads, use data center resources more efficiently, and adopt new technologies more easily.
-      </div>
-<div class="col2">
-  <h2>Solution</h2>
-      Mountain has been overseeing the company’s migration to <a href="http://kubernetes.io/">Kubernetes</a>, using <a href="https://www.openshift.org/">OpenShift</a> Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>’s enterprise container platform.
-<br><br>
+<h2>Challenge</h2>
+
+<p>In the past few years, Amadeus, which provides IT solutions to the travel industry around the world, found itself in need of a new platform for the 5,000 services supported by its service-oriented architecture. The 30-year-old company operates its own data center in Germany, and there were growing demands internally and externally for solutions that needed to be geographically dispersed. And more generally, "we had objectives of being even more highly available," says Eric Mountain, Senior Expert, Distributed Systems at Amadeus. Among the company's goals: to increase automation in managing its infrastructure, optimize the distribution of workloads, use data center resources more efficiently, and adopt new technologies more easily.</p>
+
+<h2>Solution</h2>
+
+<p>Mountain has been overseeing the company's migration to <a href="http://kubernetes.io/">Kubernetes</a>, using <a href="https://www.openshift.org/">OpenShift</a> Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>'s enterprise container platform.</p>
+
 <h2>Impact</h2>
-      One of the first projects the team deployed in Kubernetes was the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume. "It’s now handling in production several thousand transactions per second, and it’s deployed in multiple data centers throughout the world," says Mountain. "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."
-</div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "We want multi-data center capabilities, and we want them for our mainstream system as well. We didn’t think that we could achieve them with our existing system. We need new automation, things that Kubernetes and OpenShift bring."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Eric Mountain, Senior Expert, Distributed Systems at Amadeus IT Group</span>
-  </div>
-</div>
-<section class="section2">
+<p>One of the first projects the team deployed in Kubernetes was the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume. "It's now handling in production several thousand transactions per second, and it's deployed in multiple data centers throughout the world," says Mountain. "It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."</p>
 
-<div class="fullcol">
-    <h2>In his two decades at Amadeus, Eric Mountain has been the migrations guy. </h2>
-    Back in the day, he worked on the company’s move from Unix to Linux, and now he’s overseeing the journey to cloud native. "Technology just keeps changing, and we embrace it," he says. "We are celebrating our 30 years this year, and we continue evolving and innovating to stay cost-efficient and enhance everyone’s travel experience, without interrupting workflows for the customers who depend on our technology."<br><br>
-    That was the challenge that Amadeus—which provides IT solutions to the travel industry around the world, from flight searches to hotel bookings to customer feedback—faced in 2014. The technology team realized it was in need of a new platform for the 5,000 services supported by its service-oriented architecture.<br><br>
-    The tipping point occurred when they began receiving many requests, internally and externally, for solutions that needed to be geographically outside the company’s main data center in Germany. "Some requests were for running our applications on customer premises," Mountain says. "There were also new services we were looking to offer that required response time to the order of a few hundred milliseconds, which we couldn’t achieve with transatlantic traffic. Or at least, not without eating into a considerable portion of the time available to our applications for them to process individual queries."<br><br>
-    More generally, the company was interested in leveling up on high availability, increasing automation in managing infrastructure, optimizing the distribution of workloads and using data center resources more efficiently. "We have thousands and thousands of servers," says Mountain. "These servers are assigned roles, so even if the setup is highly automated, the machine still has a given role. It’s wasteful on many levels. For instance, an application doesn’t necessarily use the machine very optimally. Virtualization can help a bit, but it’s not a silver bullet. If that machine breaks, you still want to repair it because it has that role and you can’t simply say, ‘Well, I’ll bring in another machine and give it that role.’ It’s not fast. It’s not efficient. So we wanted the next level of automation."<br><br>
-</div>
-</section>
+{{< case-studies/quote author="Eric Mountain, Senior Expert, Distributed Systems at Amadeus IT Group" >}}
+"We want multi-data center capabilities, and we want them for our mainstream system as well. We didn't think that we could achieve them with our existing system. We need new automation, things that Kubernetes and OpenShift bring."
+{{< /case-studies/quote >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    "We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."
-  </div>
-</div>
+{{< case-studies/lead >}}
+In his two decades at Amadeus, Eric Mountain has been the migrations guy.
+{{< /case-studies/lead >}}
 
-<section class="section3">
-<div class="fullcol">
-  While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like <a href="https://www.python.org/">Python</a> and databases like <a href="https://www.couchbase.com/">Couchbase</a>, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.
-  <br><br>
-  All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of <a href="http://kubernetes.io/">Kubernetes</a> whatever happens to be missing from our point of view, or go with <a href="https://www.openshift.com/">OpenShift</a> and build whatever remains there."
-<br><br>
-  The team decided against building everything themselves—though they’d done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.
-<br><br>
-  Ultimately, they went with OpenShift Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>’s Kubernetes-based enterprise offering, instead of building on top of Kubernetes because "there was a lot of synergy between what we wanted and the way Red Hat was anticipating going with OpenShift," says Mountain. "They were clearly developing Kubernetes, and developing certain things ahead of time in OpenShift, which were important to us, such as more security."
-<br><br>
-  The hope was that those particular features would eventually be built into Kubernetes, and, in the case of security, Mountain feels that has happened. "We realize that there’s always a certain amount of automation that we will probably have to develop ourselves to compensate for certain gaps," says Mountain. "The less we do that, the better for us. We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."
-</div>
-</section>
+<p>Back in the day, he worked on the company's move from Unix to Linux, and now he's overseeing the journey to cloud native. "Technology just keeps changing, and we embrace it," he says. "We are celebrating our 30 years this year, and we continue evolving and innovating to stay cost-efficient and enhance everyone's travel experience, without interrupting workflows for the customers who depend on our technology."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."
-  </div>
-</div>
+<p>That was the challenge that Amadeus—which provides IT solutions to the travel industry around the world, from flight searches to hotel bookings to customer feedback—faced in 2014. The technology team realized it was in need of a new platform for the 5,000 services supported by its service-oriented architecture.</p>
 
-<section class="section4">
-<div class="fullcol">
-  The first project the team tackled was one that they knew had to run outside the data center in Germany. Because of the project’s needs, "We couldn’t rely only on the built-in Kubernetes service discovery; we had to layer on top of that an extra service discovery level that allows us to load balance at the operation level within our system," says Mountain. They also built a stream dedicated to monitoring, which at the time wasn’t offered in the Kubernetes or OpenShift ecosystem. Now that <a href="https://www.prometheus.io/">Prometheus</a> and other products are available, Mountain says the company will likely re-evaluate their monitoring system: "We obviously always like to leverage what Kubernetes and OpenShift can offer."
-<br><br>
-  The second project ended up going into production first: the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume and was deployed in public cloud. Launched in early 2016, it is "now handling in production several thousand transactions per second, and it’s deployed in multiple data centers throughout the world," says Mountain. "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."
-<br><br>
-  Having been through this kind of technical evolution more than once, Mountain has advice on how to handle the cultural changes. "That’s one aspect that we can tackle progressively," he says. "We have to go on supplying our customers with new features on our pre-existing products, and we have to keep existing products working. So we can’t simply do absolutely everything from one day to the next. And we mustn’t sell it that way."
-<br><br>
-  The first order of business, then, is to pick one or two applications to demonstrate that the technology works. Rather than choosing a high-impact, high-risk project, Mountain’s team selected a smaller application that was representative of all the company’s other applications in its complexity: "We just made sure we picked something that’s complex enough, and we showed that it can be done."
-</div>
-</section>
+<p>The tipping point occurred when they began receiving many requests, internally and externally, for solutions that needed to be geographically outside the company's main data center in Germany. "Some requests were for running our applications on customer premises," Mountain says. "There were also new services we were looking to offer that required response time to the order of a few hundred milliseconds, which we couldn't achieve with transatlantic traffic. Or at least, not without eating into a considerable portion of the time available to our applications for them to process individual queries."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don’t think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."
-  </div>
-</div>
+<p>More generally, the company was interested in leveling up on high availability, increasing automation in managing infrastructure, optimizing the distribution of workloads and using data center resources more efficiently. "We have thousands and thousands of servers," says Mountain. "These servers are assigned roles, so even if the setup is highly automated, the machine still has a given role. It's wasteful on many levels. For instance, an application doesn't necessarily use the machine very optimally. Virtualization can help a bit, but it's not a silver bullet. If that machine breaks, you still want to repair it because it has that role and you can't simply say, 'Well, I'll bring in another machine and give it that role.' It's not fast. It's not efficient. So we wanted the next level of automation."</p>
 
-<section class="section5">
-<div class="fullcol">
-  Next comes convincing people. "On the operations side and on the R&D side, there will be people who say quite rightly, ‘There is a system, and it works, so why change?’" Mountain says. "The only thing that really convinces people is showing them the value." For Amadeus, people realized that the Airline Cloud Availability product could not have been made available on the public cloud with the company’s existing system. The question then became, he says, "Do we go into a full-blown migration? Is that something that is justified?"
-<br><br>
-  "The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don’t think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."
-<br><br>
-  So how do you get everyone on board? "Make sure you have good links between your R&D and your operations," he says. "Also make sure you’re going to talk early on to the investors and stakeholders. Figure out what it is that they will be expecting from you, that will convince them or not, that this is the right way for your company."
-<br><br>
-  His other advice is simply to make the technology available for people to try it. "Kubernetes and OpenShift Origin are open source software, so there’s no complicated license key for the evaluation period and you’re not limited to 30 days," he points out. "Just go and get it running." Along with that, he adds, "You’ve got to be prepared to rethink how you do things. Of course making your applications as cloud native as possible is how you’ll reap the most benefits: 12 factors, CI/CD, which is continuous integration, continuous delivery, but also continuous deployment."
-<br><br>
-  And while they explore that aspect of the technology, Mountain and his team will likely be practicing what he preaches to others taking the cloud native journey. "See what happens when you break it, because it’s important to understand the limits of the system," he says. Or rather, he notes, the advantages of it. "Breaking things on Kube is actually one of the nice things about it—it recovers. It’s the only real way that you’ll see that you might be able to do things."
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/amadeus/banner3.jpg" >}}
+"We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."
+{{< /case-studies/quote >}}
+
+<p>While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like <a href="https://www.python.org/">Python</a> and databases like <a href="https://www.couchbase.com/">Couchbase</a>, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.</p>
+
+<p>All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of <a href="http://kubernetes.io/">Kubernetes</a> whatever happens to be missing from our point of view, or go with <a href="https://www.openshift.com/">OpenShift</a> and build whatever remains there."</p>
+
+<p>The team decided against building everything themselves—though they'd done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.</p>
+
+<p>Ultimately, they went with OpenShift Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>'s Kubernetes-based enterprise offering, instead of building on top of Kubernetes because "there was a lot of synergy between what we wanted and the way Red Hat was anticipating going with OpenShift," says Mountain. "They were clearly developing Kubernetes, and developing certain things ahead of time in OpenShift, which were important to us, such as more security."</p>
+
+<p>The hope was that those particular features would eventually be built into Kubernetes, and, in the case of security, Mountain feels that has happened. "We realize that there's always a certain amount of automation that we will probably have to develop ourselves to compensate for certain gaps," says Mountain. "The less we do that, the better for us. We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."</p>
+
+{{< case-studies/quote image="/images/case-studies/amadeus/banner4.jpg" >}}
+"It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."
+{{< /case-studies/quote >}}
+
+<p>The first project the team tackled was one that they knew had to run outside the data center in Germany. Because of the project's needs, "We couldn't rely only on the built-in Kubernetes service discovery; we had to layer on top of that an extra service discovery level that allows us to load balance at the operation level within our system," says Mountain. They also built a stream dedicated to monitoring, which at the time wasn't offered in the Kubernetes or OpenShift ecosystem. Now that <a href="https://www.prometheus.io/">Prometheus</a> and other products are available, Mountain says the company will likely re-evaluate their monitoring system: "We obviously always like to leverage what Kubernetes and OpenShift can offer."
+</p>
+
+<p>The second project ended up going into production first: the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume and was deployed in public cloud. Launched in early 2016, it is "now handling in production several thousand transactions per second, and it's deployed in multiple data centers throughout the world," says Mountain. "It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."</p>
+
+<p>Having been through this kind of technical evolution more than once, Mountain has advice on how to handle the cultural changes. "That's one aspect that we can tackle progressively," he says. "We have to go on supplying our customers with new features on our pre-existing products, and we have to keep existing products working. So we can't simply do absolutely everything from one day to the next. And we mustn't sell it that way."</p>
+
+<p>The first order of business, then, is to pick one or two applications to demonstrate that the technology works. Rather than choosing a high-impact, high-risk project, Mountain's team selected a smaller application that was representative of all the company's other applications in its complexity: "We just made sure we picked something that's complex enough, and we showed that it can be done."</p>
+
+{{< case-studies/quote >}}
+"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don't think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."
+{{< /case-studies/quote >}}
+
+<p>Next comes convincing people. "On the operations side and on the R&D side, there will be people who say quite rightly, 'There is a system, and it works, so why change?'" Mountain says. "The only thing that really convinces people is showing them the value." For Amadeus, people realized that the Airline Cloud Availability product could not have been made available on the public cloud with the company's existing system. The question then became, he says, "Do we go into a full-blown migration? Is that something that is justified?"</p>
+
+<p>"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don't think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."</p>
+
+<p>So how do you get everyone on board? "Make sure you have good links between your R&D and your operations," he says. "Also make sure you're going to talk early on to the investors and stakeholders. Figure out what it is that they will be expecting from you, that will convince them or not, that this is the right way for your company."</p>
+
+<p>His other advice is simply to make the technology available for people to try it. "Kubernetes and OpenShift Origin are open source software, so there's no complicated license key for the evaluation period and you're not limited to 30 days," he points out. "Just go and get it running." Along with that, he adds, "You've got to be prepared to rethink how you do things. Of course making your applications as cloud native as possible is how you'll reap the most benefits: 12 factors, CI/CD, which is continuous integration, continuous delivery, but also continuous deployment."</p>
+
+<p>And while they explore that aspect of the technology, Mountain and his team will likely be practicing what he preaches to others taking the cloud native journey. "See what happens when you break it, because it's important to understand the limits of the system," he says. Or rather, he notes, the advantages of it. "Breaking things on Kube is actually one of the nice things about it—it recovers. It's the only real way that you'll see that you might be able to do things."</p>
diff --git a/content/en/case-studies/ancestry/index.html b/content/en/case-studies/ancestry/index.html
index a992a284ac..8cab3c19c6 100644
--- a/content/en/case-studies/ancestry/index.html
+++ b/content/en/case-studies/ancestry/index.html
@@ -1,117 +1,92 @@
 ---
 title: Ancestry Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_ancestry.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ancestry/banner1.jpg
+heading_title_logo: /images/ancestry_logo.png
+subheading: >
+  Digging Into the Past With New Technology
+case_study_details:
+  - Company: Ancestry
+  - Location: Lehi, Utah
+  - Industry: Internet Company, Online Services
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/ancestry_logo.png" width="22%" style="margin-bottom:-12px;margin-left:3px;"><br> <div class="subhead">Digging Into the Past With New Technology</div></h1>
-
-</div>
-
-<div class="details">
-  Company &nbsp;<b>Ancestry</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Lehi, Utah</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Internet Company, Online Services</b>
-</div>
-
-<hr>
-
-<section class="section1">
-<div class="cols">
-<div class="col1">
-
 <h2>Challenge</h2>
-Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. <a href="https://www.ancestry.com">Ancestry</a> currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, <a href="https://www.ancestry.com">ancestry.com</a>, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our&nbsp;products."
 
-<br>
+<p>Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. <a href="https://www.ancestry.com">Ancestry</a> currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, <a href="https://www.ancestry.com">ancestry.com</a>, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our&nbsp;products."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="col2">
-  <h2>Solution</h2>
+<p>The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.</p>
 
-  The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.<br>
-<br>
 <h2>Impact</h2>
-  "Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
-</div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'"<br><br><span style="font-size:16px">- PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY</span>
-  </div>
-</div>
+<p>"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We've truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>It started with a Shaky Leaf.</h2>
+{{< case-studies/quote author="PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY" >}}
+"At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'"  
+{{< /case-studies/quote >}}
 
-    Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.<br><br>
-    So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on <a href="https://kubernetes.io">Kubernetes</a>, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."<br><br>
-    And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."<br><br>
-    The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."
-</div>
-</section>
+{{< case-studies/lead >}}
+It started with a Shaky Leaf.
+{{< /case-studies/lead >}}
 
-<div class="banner3">
-  <div class="banner3text">
+<p>Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.</p>
+
+<p>So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on <a href="https://kubernetes.io">Kubernetes</a>, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."</p>
+
+<p>And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."</p>
+
+<p>The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."</p>
+
+{{< case-studies/quote image="/images/case-studies/ancestry/banner3.jpg" >}}
 "And when it [Kubernetes] went live smoothly in early 2016, 'our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes,' MacKay adds. 'The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation.'"
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section3">
-<div class="fullcol">
-  That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like <a href="https://www.java.com/en/">Java</a> and <a href="https://www.python.org">Python</a> on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.<br><br>
-  His team looked at orchestration platforms offered by <a href="https://docs.docker.com/compose/">Docker Compose</a>, <a href="http://mesos.apache.org">Mesos</a> and <a href="https://www.openstack.org/software/">OpenStack</a>, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."<br><br>
-  <div class="quote">
-  Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since."</div><br>
-  Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."<br><br>
-  Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."<br><br>
-  Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.
-<br><br>
-</div>
-</section>
+<p>That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like <a href="https://www.java.com/en/">Java</a> and <a href="https://www.python.org">Python</a> on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.</p>
 
-<div class="banner4">
-<div class="banner4text">
+<p>His team looked at orchestration platforms offered by <a href="https://docs.docker.com/compose/">Docker Compose</a>, <a href="http://mesos.apache.org">Mesos</a> and <a href="https://www.openstack.org/software/">OpenStack</a>, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."</p>
 
+{{< case-studies/lead >}}
+Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since."
+{{< /case-studies/lead >}}
+
+<p>Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."</p>
+
+<p>Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."</p>
+
+<p>Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.
+</p>
+
+{{< case-studies/quote image="/images/case-studies/ancestry/banner4.jpg" >}}
 "The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology."
+{{< /case-studies/quote >}}
 
-</div>
-</div>
+<p>With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."</p>
 
-<section class="section4">
-<div class="fullcol">
-  With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."<br><br>
-  The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."<br><br>
-  A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."<br><br>
-  The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."
-</div>
-</section>
+<p>The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "... 'I believe in Kubernetes. I believe in containerization. I think
-    if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about,
-    and it'll&nbsp;go&nbsp;forward.'"
-  </div>
-</div>
+<p>A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."</p>
 
-<section class="section5">
-<div class="fullcol">
+<p>The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."</p>
 
+{{< case-studies/quote >}}
+"... 'I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll&nbsp;go&nbsp;forward.'"
+{{< /case-studies/quote >}}
 
-Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."<br><br>
-That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."<br><br>
-As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending <a href="https://www.meetup.com/Utah-Kubernetes-Meetup/">meetups</a> to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."
-<br><br>When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."<br><br>
-With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.<br><br>
-"I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."<br><br>
-He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"
+<p>Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."</p>
 
+<p>That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."</p>
 
-</div>
-</section>
+<p>As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending <a href="https://www.meetup.com/Utah-Kubernetes-Meetup/">meetups</a> to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."</p>
+
+<p>When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."</p>
+
+<p>With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.</p>
+
+<p>"I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."</p>
+
+<p>He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"</p>
diff --git a/content/en/case-studies/ant-financial/index.html b/content/en/case-studies/ant-financial/index.html
index 1711ef97b8..542352902d 100644
--- a/content/en/case-studies/ant-financial/index.html
+++ b/content/en/case-studies/ant-financial/index.html
@@ -3,94 +3,80 @@ title: Ant Financial Case Study
 linkTitle: ant-financial
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/antfinancial/banner1.jpg
+heading_title_logo: /images/antfinancial_logo.png
+subheading: >
+  Ant Financial's Hypergrowth Strategy Using Kubernetes
+case_study_details:
+  - Company: Ant Financial
+  - Location: Hangzhou, China
+  - Industry: Financial Services
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/antfinancial/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/antfinancial_logo.png" class="header_logo" style="width:20%;margin-bottom:-2.5%"><br> <div class="subhead" style="margin-top:1%">Ant Financial’s Hypergrowth Strategy Using Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>Officially founded in October 2014, <a href="https://www.antfin.com/index.htm?locale=en_us">Ant Financial</a> originated from <a href="https://global.alipay.com/">Alipay</a>, the world's largest online payment platform that launched in 2004. The company also offers numerous other services leveraging technology innovation. With the volume of transactions Alipay handles for its 900+ million users worldwide (through its local and global partners)—256,000 transactions per second at the peak of Double 11 Singles Day 2017, and total gross merchandise value of $31 billion for Singles Day 2018—not to mention that of its other services, Ant Financial faces "data processing challenge in a whole new way," says Haojie Hang, who is responsible for Product Management for the Storage and Compute Group. "We see three major problems of operating at that scale: how to provide real-time compute, storage, and processing capability, for instance to make real-time recommendations for fraud detection; how to provide intelligence on top of this data, because there's too much data and then we're not getting enough insight; and how to apply security in the application level, in the middleware level, the system level, even the chip level." In order to provide reliable and consistent services to its customers, Ant Financial embraced containers in early 2014, and soon needed an orchestration solution for the tens-of-thousands-of-node clusters in its data centers.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Ant Financial</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Hangzhou, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Financial Services</b>
-</div>
+<p>After investigating several technologies, the team chose <a href="https://kubernetes.io/">Kubernetes</a> for orchestration, as well as a number of other CNCF projects, including <a href="https://prometheus.io/">Prometheus</a>, <a href="https://opentracing.io/">OpenTracing</a>, <a href="https://coreos.com/etcd/">etcd</a> and <a href="https://coredns.io/">CoreDNS</a>. "In late 2016, we decided that Kubernetes will be the de facto standard," says Hang. "Looking back, we made the right bet on the right technology. But then we needed to move the production workload from the legacy infrastructure to the latest Kubernetes-enabled platform, and that took some time, because we are very careful in terms of reliability and consistency." All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    Officially founded in October 2014, <a href="https://www.antfin.com/index.htm?locale=en_us">Ant Financial</a> originated from <a href="https://global.alipay.com/">Alipay</a>, the world’s largest online payment platform that launched in 2004. The company also offers numerous other services leveraging technology innovation. With the volume of transactions Alipay handles for its 900+ million users worldwide (through its local and global partners)—256,000 transactions per second at the peak of Double 11 Singles Day 2017, and total gross merchandise value of $31 billion for Singles Day 2018—not to mention that of its other services, Ant Financial faces “data processing challenge in a whole new way,” says Haojie Hang, who is responsible for Product Management for the Storage and Compute Group. “We see three major problems of operating at that scale: how to provide real-time compute, storage, and processing capability, for instance to make real-time recommendations for fraud detection; how to provide intelligence on top of this data, because there’s too much data and then we’re not getting enough insight; and how to apply security in the application level, in the middleware level, the system level, even the chip level.” In order to provide reliable and consistent services to its customers, Ant Financial embraced containers in early 2014, and soon needed an orchestration solution for the tens-of-thousands-of-node clusters in its data centers.
-
-    <h2>Solution</h2>
-    After investigating several technologies, the team chose <a href="https://kubernetes.io/">Kubernetes</a> for orchestration, as well as a number of other CNCF projects, including <a href="https://prometheus.io/">Prometheus</a>, <a href="https://opentracing.io/">OpenTracing</a>, <a href="https://coreos.com/etcd/">etcd</a> and <a href="https://coredns.io/">CoreDNS</a>. “In late 2016, we decided that Kubernetes will be the de facto standard,” says Hang. “Looking back, we made the right bet on the right technology. But then we needed to move the production workload from the legacy infrastructure to the latest Kubernetes-enabled platform, and that took some time, because we are very careful in terms of reliability and consistency.” All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing.
-<br>
 <h2>Impact</h2>
-    “We’ve seen at least tenfold in improvement in terms of the operations with cloud native technology, which means you can have tenfold increase in terms of output,” says Hang. Ant also provides its fully integrated financial cloud platform to business partners around the world, and hopes to power the next generation of digital banking with deep experience in service innovation and technology expertise. Hang says the team hasn’t begun to focus on optimizing the Kubernetes platform, either: “Because we’re still in the hyper growth stage, we’re not in a mode where we do cost saving yet.”
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "In late 2016, we decided that Kubernetes will be the de facto standard. Looking back, we made the right bet on the right technology."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>A spinoff of the multinational conglomerate Alibaba, Ant Financial boasts a $150+ billion valuation and the scale to match. The fintech startup, launched in 2014, is comprised of Alipay, the world’s largest online payment platform, and numerous other services leveraging technology innovation.</h2>
-  And the volume of transactions that Alipay handles for over 900 million users worldwide (through its local and global partners) is staggering: 256,000 per second at the peak of Double 11 Singles Day 2017, and total gross merchandise value of $31 billion for Singles Day 2018. With the mission of “bringing the world equal opportunities,” Ant Financial is dedicated to creating an open, shared credit system and financial services platform through technology innovations.
-<br><br>
-  Combine that with the operations of its other properties—such as the Huabei online credit system, Jiebei lending service, and the 350-million-user <a href="https://en.wikipedia.org/wiki/Ant_Forest">Ant Forest</a> green energy mobile app—and Ant Financial faces “data processing challenge in a whole new way,” says Haojie Hang, who is responsible for Product Management for the Storage and Compute Group. “We see three major problems of operating at that scale: how to provide real-time compute, storage, and processing capability, for instance to make real-time recommendations for fraud detection; how to provide intelligence on top of this data, because there’s too much data and we’re not getting enough insight; and how to apply security in the application level, in the middleware level, the system level, even the chip level.”
-<br><br>
-  To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced <a href="https://www.docker.com/">Docker</a> containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/antfinancial/banner3.jpg')">
-  <div class="banner3text">
-    "On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL</span>
+<p>"We've seen at least tenfold in improvement in terms of the operations with cloud native technology, which means you can have tenfold increase in terms of output," says Hang. Ant also provides its fully integrated financial cloud platform to business partners around the world, and hopes to power the next generation of digital banking with deep experience in service innovation and technology expertise. Hang says the team hasn't begun to focus on optimizing the Kubernetes platform, either: "Because we're still in the hyper growth stage, we're not in a mode where we do cost saving yet."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  The team investigated several technologies, including Docker Swarm and Mesos. “We did a lot of POCs, but we’re very careful in terms of production systems, because we want to make sure we don’t lose any data,” says Hang. “You cannot afford to have a service downtime for one minute; even one second has a very, very big impact. We operate every day under pressure to provide reliable and consistent services to consumers and businesses in China and globally.”
-<br><br>
-  Ultimately, Hang says Ant chose Kubernetes because it checked all the boxes: a strong community, technology that “will be relevant in the next three to five years,” and a good match for the company’s engineering talent. “In late 2016, we decided that Kubernetes will be the de facto standard,” says Hang. “Looking back, we made the right bet on the right technology. But then we needed to move the production workload from the legacy infrastructure to the latest Kubernetes-enabled platform. We spent a lot of time learning and then training our people to build applications on Kubernetes well.”
-<br><br>
-  All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing. Ant’s platform also leverages a number of other CNCF projects, including <a href="https://prometheus.io/">Prometheus</a>, <a href="https://opentracing.io/">OpenTracing</a>, <a href="https://coreos.com/etcd/">etcd</a> and <a href="https://coredns.io/">CoreDNS</a>.  “On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress,” says Ranger Yu, Global Technology Partnership & Development.
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/antfinancial/banner4.jpg')">
-  <div class="banner4text">
-  "We’re very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We’re definitely embracing the community and open source more in the future." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL</span>
-  </div>
-</div>
+{{< case-studies/quote author="HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL" >}}
+"In late 2016, we decided that Kubernetes will be the de facto standard. Looking back, we made the right bet on the right technology."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Still, there has already been an impact. “Cloud native technology has benefited us greatly in terms of efficiency,” says Hang. “In general, we want to make sure our infrastructure is nimble and flexible enough for the work that could happen tomorrow. That’s the goal. And with cloud native technology, we’ve seen at least tenfold improvement in operations, which means you can have tenfold increase in terms of output. Let’s say you are operating 10 nodes with one person. With cloud native, tomorrow you can have 100 nodes.”
-<br><br>
-  Ant also provides its financial cloud platform to partners around the world, and hopes to power the next generation of digital banking with deep experience in service innovation and technology expertise. Hang says the team hasn’t begun to focus on optimizing the Kubernetes platform, either: “Because we’re still in the hyper growth stage, we’re not in a mode where we do cost-saving yet.”
-<br><br>
-  The CNCF community has also been a valuable asset during Ant Financial’s move to cloud native. “If you are applying a new technology, it’s very good to have a community to discuss technical problems with other users,” says Hang. “We’re very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We’re definitely embracing the community and open sourcing more in the future.”
-</div>
+{{< case-studies/lead >}}
+A spinoff of the multinational conglomerate Alibaba, Ant Financial boasts a $150+ billion valuation and the scale to match. The fintech startup, launched in 2014, is comprised of Alipay, the world's largest online payment platform, and numerous other services leveraging technology innovation.
+{{< /case-studies/lead >}}
 
-<div class="banner5" >
-  <div class="banner5text">
-"In China, we are the North Star in terms of innovation in financial and other related services,” says Hang. “We definitely want to make sure we’re still leading in the next 5 to 10 years with our investment in technology."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL</span></div>
-</div>
+<p>And the volume of transactions that Alipay handles for over 900 million users worldwide (through its local and global partners) is staggering: 256,000 per second at the peak of Double 11 Singles Day 2017, and total gross merchandise value of $31 billion for Singles Day 2018. With the mission of "bringing the world equal opportunities," Ant Financial is dedicated to creating an open, shared credit system and financial services platform through technology innovations.</p>
 
-<div class="fullcol">
-  In fact, the company has already started to open source some of its <a href="https://github.com/alipay">cloud native middleware</a>. “We are going to be very proactive about that,” says Yu. “CNCF provided a platform so everyone can plug in or contribute components. This is very good open source governance.”
-<br><br>
-  Looking ahead, the Ant team will continue to evaluate many other CNCF projects. Building a service mesh community in China, the team has brought together many China-based companies and developers to discuss the potential of that technology. “Service mesh is very attractive for Chinese developers and end users because we have a lot of legacy systems running now, and it’s an ideal mid-layer to glue everything together, both new and legacy,” says Hang. “For new technologies, we look very closely at whether they will last.”
-<br><br>
-  At Ant, Kubernetes passed that test with flying colors, and the team hopes other companies will follow suit. “In China, we are the North Star in terms of innovation in financial and other related services,” says Hang. “We definitely want to make sure we’re still leading in the next 5 to 10 years with our investment in technology.”
+<p>Combine that with the operations of its other properties—such as the Huabei online credit system, Jiebei lending service, and the 350-million-user <a href="https://en.wikipedia.org/wiki/Ant_Forest">Ant Forest</a> green energy mobile app—and Ant Financial faces "data processing challenge in a whole new way," says Haojie Hang, who is responsible for Product Management for the Storage and Compute Group. "We see three major problems of operating at that scale: how to provide real-time compute, storage, and processing capability, for instance to make real-time recommendations for fraud detection; how to provide intelligence on top of this data, because there's too much data and we're not getting enough insight; and how to apply security in the application level, in the middleware level, the system level, even the chip level."</p>
 
-</div>
-</section>
+<p>To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced <a href="https://www.docker.com/">Docker</a> containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company's data centers.</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/antfinancial/banner3.jpg"
+  author="RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL"
+>}}
+"On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress."
+{{< /case-studies/quote >}}
+
+<p>The team investigated several technologies, including Docker Swarm and Mesos. "We did a lot of POCs, but we're very careful in terms of production systems, because we want to make sure we don't lose any data," says Hang. "You cannot afford to have a service downtime for one minute; even one second has a very, very big impact. We operate every day under pressure to provide reliable and consistent services to consumers and businesses in China and globally."</p>
+
+<p>Ultimately, Hang says Ant chose Kubernetes because it checked all the boxes: a strong community, technology that "will be relevant in the next three to five years," and a good match for the company's engineering talent. "In late 2016, we decided that Kubernetes will be the de facto standard," says Hang. "Looking back, we made the right bet on the right technology. But then we needed to move the production workload from the legacy infrastructure to the latest Kubernetes-enabled platform. We spent a lot of time learning and then training our people to build applications on Kubernetes well."</p>
+
+<p>All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing. Ant's platform also leverages a number of other CNCF projects, including <a href="https://prometheus.io/">Prometheus</a>, <a href="https://opentracing.io/">OpenTracing</a>, <a href="https://coreos.com/etcd/">etcd</a> and <a href="https://coredns.io/">CoreDNS</a>.  "On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress," says Ranger Yu, Global Technology Partnership & Development.</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/antfinancial/banner4.jpg"
+  author="HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL"
+>}}
+"We're very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We're definitely embracing the community and open source more in the future."
+{{< /case-studies/quote >}}
+
+<p>Still, there has already been an impact. "Cloud native technology has benefited us greatly in terms of efficiency," says Hang. "In general, we want to make sure our infrastructure is nimble and flexible enough for the work that could happen tomorrow. That's the goal. And with cloud native technology, we've seen at least tenfold improvement in operations, which means you can have tenfold increase in terms of output. Let's say you are operating 10 nodes with one person. With cloud native, tomorrow you can have 100 nodes."</p>
+
+<p>Ant also provides its financial cloud platform to partners around the world, and hopes to power the next generation of digital banking with deep experience in service innovation and technology expertise. Hang says the team hasn't begun to focus on optimizing the Kubernetes platform, either: "Because we're still in the hyper growth stage, we're not in a mode where we do cost-saving yet."</p>
+
+<p>The CNCF community has also been a valuable asset during Ant Financial's move to cloud native. "If you are applying a new technology, it's very good to have a community to discuss technical problems with other users," says Hang. "We're very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We're definitely embracing the community and open sourcing more in the future."</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/antfinancial/banner4.jpg"
+  author="RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL"
+>}}
+"In China, we are the North Star in terms of innovation in financial and other related services," says Hang. "We definitely want to make sure we're still leading in the next 5 to 10 years with our investment in technology."
+{{< /case-studies/quote >}}
+
+<p>In fact, the company has already started to open source some of its <a href="https://github.com/alipay">cloud native middleware</a>. "We are going to be very proactive about that," says Yu. "CNCF provided a platform so everyone can plug in or contribute components. This is very good open source governance."</p>
+
+<p>Looking ahead, the Ant team will continue to evaluate many other CNCF projects. Building a service mesh community in China, the team has brought together many China-based companies and developers to discuss the potential of that technology. "Service mesh is very attractive for Chinese developers and end users because we have a lot of legacy systems running now, and it's an ideal mid-layer to glue everything together, both new and legacy," says Hang. "For new technologies, we look very closely at whether they will last."</p>
+
+<p>At Ant, Kubernetes passed that test with flying colors, and the team hopes other companies will follow suit. "In China, we are the North Star in terms of innovation in financial and other related services," says Hang. "We definitely want to make sure we're still leading in the next 5 to 10 years with our investment in technology."</p>
diff --git a/content/en/case-studies/appdirect/index.html b/content/en/case-studies/appdirect/index.html
index ca6b0b8fe9..ffb06c67b9 100644
--- a/content/en/case-studies/appdirect/index.html
+++ b/content/en/case-studies/appdirect/index.html
@@ -1,99 +1,85 @@
 ---
 title: AppDirect Case Study
-
 linkTitle: AppDirect
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: appdirect_featured_logo.png
 featured: true
 weight: 4
 quote: >
    We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/appdirect/banner1.jpg
+heading_title_logo: /images/appdirect_logo.png
+subheading: >
+  AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess
+case_study_details:
+  - Company: AppDirect
+  - Location: San Francisco, California
+  - Industry: Software
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/appdirect/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/appdirect_logo.png" class="header_logo" style="margin-bottom:-2%"><br> <div class="subhead" style="margin-top:1%;font-size:0.5em">AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p><a href="https://www.appdirect.com/">AppDirect</a> provides an end-to-end commerce platform for cloud-based products and services. When Director of Software Development Pierre-Alexandre Lacerte began working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature, then another team picking up the change. So you had bottlenecks in the pipeline to ship a feature to production." At the same time, the engineering team was growing, and the company realized it needed a better infrastructure to both support that growth and increase velocity.</p>
 
-<div class="details">
-    Company &nbsp;<b>AppDirect</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>San Francisco, California
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Software</b>
-</div>
+<h2>Solution</h2>
+
+<p>"My idea was: Let's create an environment where teams can deploy their services faster, and they will say, 'Okay, I don't want to build in the monolith anymore. I want to build a service,'" says Lacerte. They considered and prototyped several different technologies before deciding to adopt <a href="https://kubernetes.io/">Kubernetes</a> in early 2016. Lacerte's team has also integrated <a href="https://prometheus.io/">Prometheus</a> monitoring into the platform; tracing is next. Today, AppDirect has more than 50 microservices in production and 15 Kubernetes clusters deployed on <a href="https://aws.amazon.com/">AWS</a> and on premise around the world.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    <a href="https://www.appdirect.com/">AppDirect</a> provides an end-to-end commerce platform for cloud-based products and services. When Director of Software Development Pierre-Alexandre Lacerte began working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature, then another team picking up the change. So you had bottlenecks in the pipeline to ship a feature to production." At the same time, the engineering team was growing, and the company realized it needed a better infrastructure to both support that growth and increase velocity.
-<br><br>
-    <h2>Solution</h2>
-    "My idea was: Let’s create an environment where teams can deploy their services faster, and they will say, ‘Okay, I don’t want to build in the monolith anymore. I want to build a service,’" says Lacerte. They considered and prototyped several different technologies before deciding to adopt <a href="https://kubernetes.io/">Kubernetes</a> in early 2016. Lacerte’s team has also integrated <a href="https://prometheus.io/">Prometheus</a> monitoring into the platform; tracing is next. Today, AppDirect has more than 50 microservices in production and 15 Kubernetes clusters deployed on <a href="https://aws.amazon.com/">AWS</a> and on premise around the world.
-<br><br>
 <h2>Impact</h2>
-    The Kubernetes platform has helped support the engineering team’s 10x growth over the past few years. Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn’t have this new infrastructure." Moving to Kubernetes and services has meant that deployments have become much faster due to less dependency on custom-made, brittle shell scripts with SCP commands. Time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require <a href="https://www.atlassian.com/software/jira">Jira</a> tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before. The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Alexandre Gervais, Staff Software Developer, AppDirect</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>With its end-to-end commerce platform for cloud-based products and services, <a href="https://www.appdirect.com/">AppDirect</a> has been helping organizations such as Comcast and GoDaddy simplify the digital supply chain since 2009. </h2>
-<br>
-  When Director of Software Development Pierre-Alexandre Lacerte started working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature then creating a pull request, and a QA or another engineer validating the feature. Then it gets merged and someone else will take care of the deployment. So we had bottlenecks in the pipeline to ship a feature to production."  <br><br>
-  At the same time, the engineering team of 40 was growing, and the company wanted to add an increasing number of features to its products. As a member of the platform team, Lacerte began hearing from multiple teams that wanted to deploy applications using different frameworks and languages, from <a href="https://nodejs.org/">Node.js</a> to <a href="http://spring.io/projects/spring-boot">Spring Boot Java</a>. He soon realized that in order to both support growth and increase velocity, the company needed a better infrastructure, and a system in which teams are autonomous, can do their own deploys, and be responsible for their services in production.
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/appdirect/banner3.jpg')">
-  <div class="banner3text">
-  "We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Alexandre Gervais, Staff Software Developer, AppDirect
-</span>
+<p>The Kubernetes platform has helped support the engineering team's 10x growth over the past few years. Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn't have this new infrastructure." Moving to Kubernetes and services has meant that deployments have become much faster due to less dependency on custom-made, brittle shell scripts with SCP commands. Time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn't require <a href="https://www.atlassian.com/software/jira">Jira</a> tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before. The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  From the beginning, Lacerte says, "My idea was: Let’s create an environment where teams can deploy their services faster, and they will say, ‘Okay, I don’t want to build in the monolith anymore. I want to build a service.’" (Lacerte left the company in 2019.)<br><br>
-  Working with the operations team, Lacerte’s group got more control and access to the company’s <a href="https://aws.amazon.com/">AWS infrastructure</a>, and started prototyping several orchestration technologies. "Back then, Kubernetes was a little underground, unknown," he says. "But we looked at the community, the number of pull requests, the velocity on GitHub, and we saw it was getting traction. And we found that it was much easier for us to manage than the other technologies."
-  They spun up the first few services on Kubernetes using <a href="https://www.chef.io/">Chef</a> and <a href="https://www.terraform.io/">Terraform</a> provisioning, and as more services were added, more automation was, too. "We have clusters around the world—in Korea, in Australia, in Germany, and in the U.S.," says Lacerte. "Automation is critical for us." They’re now largely using <a href="https://github.com/kubernetes/kops">Kops</a>, and are looking at managed Kubernetes offerings from several cloud providers.<br><br>
-  Today, though the monolith still exists, there are fewer and fewer commits and features. All teams are deploying on the new infrastructure, and services are the norm. AppDirect now has more than 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on premise around the world.<br><br>
-  Lacerte’s strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require <a href="https://www.atlassian.com/software/jira">Jira</a> tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/appdirect/banner4.jpg');width:100%;">
-  <div class="banner4text">
-  "I think our velocity would have slowed down a lot if we didn’t have this new infrastructure."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect</span>
-  </div>
-</div>
+{{< case-studies/quote author="Alexandre Gervais, Staff Software Developer, AppDirect" >}}
+"It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
+{{< case-studies/lead >}}
+With its end-to-end commerce platform for cloud-based products and services, <a href="https://www.appdirect.com/">AppDirect</a> has been helping organizations such as Comcast and GoDaddy simplify the digital supply chain since 2009.
+{{< /case-studies/lead >}}
 
-<div class="fullcol">
-  Additionally, the Kubernetes platform has helped support the engineering team’s 10x growth over the past few years. "Ownership, a core value of AppDirect, reflects in our ability to ship services independently of our monolith code base," says Staff Software Developer Alexandre Gervais, who worked with Lacerte on the initiative. "Small teams now own critical parts of our business domain model, and they operate in their decoupled domain of expertise, with limited knowledge of the entire codebase. This reduces and isolates some of the complexity." Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn’t have this new infrastructure."
-  The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.<br><br>
-  AppDirect’s cloud native stack also includes <a href="https://grpc.io/">gRPC</a> and <a href="https://www.fluentd.org/">Fluentd</a>, and the team is currently working on setting up <a href="https://opencensus.io/">OpenCensus</a>. The platform already has <a href="https://prometheus.io/">Prometheus</a> integrated, so "when teams deploy their service, they have their notifications, alerts and configurations," says Lacerte. "For example, in the test environment, I want to get a message on Slack, and in production, I want a <a href="https://slack.com/">Slack</a> message and I also want to get paged. We have integration with pager duty. Teams have more ownership on their services."
+<p>When Director of Software Development Pierre-Alexandre Lacerte started working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature then creating a pull request, and a QA or another engineer validating the feature. Then it gets merged and someone else will take care of the deployment. So we had bottlenecks in the pipeline to ship a feature to production."</p>
 
-</div>
+<p>At the same time, the engineering team of 40 was growing, and the company wanted to add an increasing number of features to its products. As a member of the platform team, Lacerte began hearing from multiple teams that wanted to deploy applications using different frameworks and languages, from <a href="https://nodejs.org/">Node.js</a> to <a href="http://spring.io/projects/spring-boot">Spring Boot Java</a>. He soon realized that in order to both support growth and increase velocity, the company needed a better infrastructure, and a system in which teams are autonomous, can do their own deploys, and be responsible for their services in production.</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-"We moved from a culture limited to ‘pushing code in a branch’ to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect</span></div>
-</div>
+{{< case-studies/quote 
+  image="/images/case-studies/appdirect/banner3.jpg"
+  author="Alexandre Gervais, Staff Software Developer, AppDirect"
+>}}
+"We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  That of course also means more responsibility. "We asked engineers to expand their horizons," says Gervais. "We moved from a culture limited to ‘pushing code in a branch’ to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed." <br><br>
-  As the engineering ranks continue to grow, the platform team has a new challenge, of making sure that the Kubernetes platform is accessible and easily utilized by everyone. "How can we make sure that when we add more people to our team that they are efficient, productive, and know how to ramp up on the platform?" Lacerte says. So we have the evangelists, the documentation, some project examples. We do demos, we have AMA sessions. We’re trying different strategies to get everyone’s attention."<br><br>
-  Three and a half years into their Kubernetes journey, Gervais feels AppDirect "made the right decisions at the right time," he says. "Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team. Going forward, our focus will really be geared towards benefiting from the ecosystem by providing added business value in our day-to-day operations."
+<p>From the beginning, Lacerte says, "My idea was: Let's create an environment where teams can deploy their services faster, and they will say, 'Okay, I don't want to build in the monolith anymore. I want to build a service.'" (Lacerte left the company in 2019.)</p>
 
+<p>Working with the operations team, Lacerte's group got more control and access to the company's <a href="https://aws.amazon.com/">AWS infrastructure</a>, and started prototyping several orchestration technologies. "Back then, Kubernetes was a little underground, unknown," he says. "But we looked at the community, the number of pull requests, the velocity on GitHub, and we saw it was getting traction. And we found that it was much easier for us to manage than the other technologies."</p>
 
-</div>
-</section>
+<p>They spun up the first few services on Kubernetes using <a href="https://www.chef.io/">Chef</a> and <a href="https://www.terraform.io/">Terraform</a> provisioning, and as more services were added, more automation was, too. "We have clusters around the world—in Korea, in Australia, in Germany, and in the U.S.," says Lacerte. "Automation is critical for us." They're now largely using <a href="https://github.com/kubernetes/kops">Kops</a>, and are looking at managed Kubernetes offerings from several cloud providers.</p>
+
+<p>Today, though the monolith still exists, there are fewer and fewer commits and features. All teams are deploying on the new infrastructure, and services are the norm. AppDirect now has more than 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on premise around the world.</p>
+
+<p>Lacerte's strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn't require <a href="https://www.atlassian.com/software/jira">Jira</a> tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/appdirect/banner4.jpg"
+  author="Pierre-Alexandre Lacerte, Director of Software Development, AppDirect"
+>}}
+"I think our velocity would have slowed down a lot if we didn't have this new infrastructure."
+{{< /case-studies/quote >}}
+
+<p>Additionally, the Kubernetes platform has helped support the engineering team's 10x growth over the past few years. "Ownership, a core value of AppDirect, reflects in our ability to ship services independently of our monolith code base," says Staff Software Developer Alexandre Gervais, who worked with Lacerte on the initiative. "Small teams now own critical parts of our business domain model, and they operate in their decoupled domain of expertise, with limited knowledge of the entire codebase. This reduces and isolates some of the complexity." Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn't have this new infrastructure."</p>
+
+<p>The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.</p>
+
+<p>AppDirect's cloud native stack also includes <a href="https://grpc.io/">gRPC</a> and <a href="https://www.fluentd.org/">Fluentd</a>, and the team is currently working on setting up <a href="https://opencensus.io/">OpenCensus</a>. The platform already has <a href="https://prometheus.io/">Prometheus</a> integrated, so "when teams deploy their service, they have their notifications, alerts and configurations," says Lacerte. "For example, in the test environment, I want to get a message on Slack, and in production, I want a <a href="https://slack.com/">Slack</a> message and I also want to get paged. We have integration with pager duty. Teams have more ownership on their services."</p>
+
+{{< case-studies/quote author="Pierre-Alexandre Lacerte, Director of Software Development, AppDirect" >}}
+"We moved from a culture limited to 'pushing code in a branch' to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."
+{{< /case-studies/quote >}}
+
+<p>That of course also means more responsibility. "We asked engineers to expand their horizons," says Gervais. "We moved from a culture limited to 'pushing code in a branch' to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."</p>
+
+<p>As the engineering ranks continue to grow, the platform team has a new challenge, of making sure that the Kubernetes platform is accessible and easily utilized by everyone. "How can we make sure that when we add more people to our team that they are efficient, productive, and know how to ramp up on the platform?" Lacerte says. So we have the evangelists, the documentation, some project examples. We do demos, we have AMA sessions. We're trying different strategies to get everyone's attention."</p>
+
+<p>Three and a half years into their Kubernetes journey, Gervais feels AppDirect "made the right decisions at the right time," he says. "Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team. Going forward, our focus will really be geared towards benefiting from the ecosystem by providing added business value in our day-to-day operations."</p>
diff --git a/content/en/case-studies/babylon/index.html b/content/en/case-studies/babylon/index.html
index dce0612175..6b86096b02 100644
--- a/content/en/case-studies/babylon/index.html
+++ b/content/en/case-studies/babylon/index.html
@@ -3,107 +3,82 @@ title: Babylon Case Study
 linkTitle: Babylon
 case_study_styles: true
 cid: caseStudies
-css: /css/case-studies-gradient.css
 logo: babylon_featured_logo.svg
 featured: true
 weight: 1
 quote: >
    Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/babylon/banner4.jpg
+heading_title_text: Babylon
+use_gradient_overlay: true
+subheading: >
+  AppDirect: How Cloud Native Is Enabling Babylon's Medical AI Innovations
+case_study_details:
+  - Company: Babylon
+  - Location: United Kingdom
+  - Industry: AI, Healthcare
 ---
 
+<h2>Challenge</h2>
 
-<div class="article image overlay" style="background-image: url('/images/case-studies/babylon/banner4.jpg')">
-  <h1> CASE STUDY: Babylon</h1>
-  <div class="subhead">How Cloud Native Is Enabling Babylon’s Medical AI Innovations</div>
-</div>
+<p>A large number of Babylon's products leverage machine learning and artificial intelligence, and in 2019, there wasn't enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries.</p>
 
-<div class="details">
-    Company &nbsp;<b>Babylon</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>United Kingdom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>AI, Healthcare</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="colsgradient">
-  <div class="col1">
-    <h2>Challenge</h2>
-   A large number of Babylon’s products leverage machine learning and artificial intelligence, and in 2019, there wasn’t enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries.
-
-
-    <h2>Solution</h2>
-    Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. “We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success,” says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes.
+<p>Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes.</p>
 
 <h2>Impact</h2>
-    Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.</div>
-</div>
-</section>
-<div class="article image overlay" style="background-image: url('/images/case-studies/babylon/banner1.jpg');">
-  <div class="quotetext">
-    “Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.”
-<p><div class="quoteauthortext">- JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON</div></p>
-  </div>
-</div>
 
+<p>Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.</p>
 
-<section class="section2">
-<div class="fullcol">
-  <h4>Babylon’s mission is to put accessible and affordable healthcare services in the hands of every person on earth.</h4>
+{{< case-studies/quote
+  image="/images/case-studies/babylon/banner1.jpg"
+  author="JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON"
+>}}
+"Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need."
+{{< /case-studies/quote >}}
 
-  <p>Since its launch in the U.K. in 2013, the startup has facilitated millions of digital consultations around the world. In the U.K., patients were typically waiting a week or two for a doctor’s appointment. Through Babylon’s NHS service, GP at Hand—which has more than 75,000 registered patients—39% get an appointment through their phone within 30 minutes, and 89% within 6 hours.  </p>
+{{< case-studies/lead >}}
+Babylon's mission is to put accessible and affordable healthcare services in the hands of every person on earth.
+{{< /case-studies/lead >}}
 
-  <p>That’s just the start. “We try to combine different types of technology with the medical expertise that we have in-house to build products that will help patients manage and understand their health, and also help doctors be more efficient at what they do,” says Jérémie Vallée, AI Infrastructure Lead at Babylon. </p>
+<p>Since its launch in the U.K. in 2013, the startup has facilitated millions of digital consultations around the world. In the U.K., patients were typically waiting a week or two for a doctor's appointment. Through Babylon's NHS service, GP at Hand—which has more than 75,000 registered patients—39% get an appointment through their phone within 30 minutes, and 89% within 6 hours.</p>
 
-<p>A large number of these products leverage machine learning and artificial intelligence, and in 2019, researchers hit a pain point. “We have some servers in-house where our researchers were doing a lot of AI experiments and some training of models, and we came to a point where we didn’t have enough compute in-house to run a particular experiment,” says Vallée. </p>
- <p>
-    Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, “and we had a lot of Kubernetes knowledge thanks to the migration,” he adds. To optimize some of the models that had been created, the team turned to Kubeflow, a toolkit for machine learning on Kubernetes. “We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success,” he says.</p>
-  <p>
-   Based on that experience, Vallée’s team was tasked with building a self-service platform to help Babylon’s AI teams become more efficient, and by extension help get products to market faster. The main requirements: (1) the ability to give researchers and engineers access to the compute they needed, regardless of the size of the experiments they may need to run; (2) a way to provide teams with the best tools that they needed to do their work, on demand and in a centralized way; and (3) the training platform had to be close to the data that was being managed, because of the company’s expansion into different countries.</p>
+<p>That's just the start. "We try to combine different types of technology with the medical expertise that we have in-house to build products that will help patients manage and understand their health, and also help doctors be more efficient at what they do," says Jérémie Vallée, AI Infrastructure Lead at Babylon. </p>
 
+<p>A large number of these products leverage machine learning and artificial intelligence, and in 2019, researchers hit a pain point. "We have some servers in-house where our researchers were doing a lot of AI experiments and some training of models, and we came to a point where we didn't have enough compute in-house to run a particular experiment," says Vallée. </p>
 
-</div>
-</section>
+<p>Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, "and we had a lot of Kubernetes knowledge thanks to the migration," he adds. To optimize some of the models that had been created, the team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," he says.</p>
 
-<div class="greybanner">
-  <div class="greyquotetext">
-     “Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation.”<p><div class="quoteauthortext">- CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON</div></p>
-  </div>
-</div>
+<p>Based on that experience, Vallée's team was tasked with building a self-service platform to help Babylon's AI teams become more efficient, and by extension help get products to market faster. The main requirements: (1) the ability to give researchers and engineers access to the compute they needed, regardless of the size of the experiments they may need to run; (2) a way to provide teams with the best tools that they needed to do their work, on demand and in a centralized way; and (3) the training platform had to be close to the data that was being managed, because of the company's expansion into different countries.</p>
 
-<section class="section3">
-<div class="fullcol">
-   <p>
-    Kubernetes was an enabler on every count. “Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need,” says Vallée. The need to keep data in every country in which Babylon operates requires a multi-region, multi-cloud strategy, and some countries might not even have a public cloud provider at all. “We wanted to make this platform portable so that we can run training jobs anywhere,” he says. “Kubernetes offered a base layer that allows you to deploy the platform outside of the cloud provider, and then deploy whatever tooling you need. That was a very good selling point for us.” </p>
- <p>
-   Once the team decided to build the Babylon AI Research platform on top of Kubernetes, they referred to the Cloud Native Landscape to build out the stack: Prometheus and Grafana for monitoring; an Istio service mesh to control the network on the training platform and control what access all of the workflows would have; Helm to deploy the stack; and Flux to manage the GitOps part of the pipeline. </p>
-  <p>
-  The cloud native AI platform has had a huge impact at Babylon. The first research projects run on the platform mostly involved machine learning and natural language processing. These experiments required a huge amount of compute—1600 CPU, 3.2 TB RAM—which was much more than Babylon had in-house. Plus, access to compute used to take hours, or sometimes even days, depending on how busy the platform team was. “Now, with Kubernetes and the self-service platform that we provide, it’s pretty much instantaneous,” says Vallée. </p>
-  <p>
-  Another important type of work that’s done on the platform is clinical validation for new applications such as Babylon’s Symptom Checker, which calculates the probability of a disease given the evidence input by the user. “Being in healthcare, we want all of our models to be safe before they’re going to hit production,” says Vallée. Using Argo for GitOps “enabled us to scale the process massively.”  </p>
+{{< case-studies/quote author="CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON" >}}
+"Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation."
+{{< /case-studies/quote >}}
 
-  </p>
-</div>
-</section>
+<p>Kubernetes was an enabler on every count. "Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need," says Vallée. The need to keep data in every country in which Babylon operates requires a multi-region, multi-cloud strategy, and some countries might not even have a public cloud provider at all. "We wanted to make this platform portable so that we can run training jobs anywhere," he says. "Kubernetes offered a base layer that allows you to deploy the platform outside of the cloud provider, and then deploy whatever tooling you need. That was a very good selling point for us."</p>
 
+<p>Once the team decided to build the Babylon AI Research platform on top of Kubernetes, they referred to the Cloud Native Landscape to build out the stack: Prometheus and Grafana for monitoring; an Istio service mesh to control the network on the training platform and control what access all of the workflows would have; Helm to deploy the stack; and Flux to manage the GitOps part of the pipeline.</p>
 
-  <div class="article image overlay" style="background-image: url('/images/case-studies/babylon/banner2.jpg');">
-  <div class="quotetext">
- “Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.” <p><div class="quoteauthortext">- JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON</div></p>
-  </div>
-</div>
+<p>The cloud native AI platform has had a huge impact at Babylon. The first research projects run on the platform mostly involved machine learning and natural language processing. These experiments required a huge amount of compute—1600 CPU, 3.2 TB RAM—which was much more than Babylon had in-house. Plus, access to compute used to take hours, or sometimes even days, depending on how busy the platform team was. "Now, with Kubernetes and the self-service platform that we provide, it's pretty much instantaneous," says Vallée.</p>
 
-<section class="section5">
-<div class="fullcol">
-   <p>
-  Researchers used to have to wait up to 10 hours to get results on new versions of their models. With Kubernetes, that time is now down to under 20 minutes. Plus, previously they could only run one clinical validation at a time, now they can run many parallel ones if they need to—a huge benefit considering that in the past three years, Babylon has grown from 100 to 1,600 employees. </p>
-  <p>
-  “Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation,” says Chief Technology Officer Caroline Hargrove.</p>
-  <p>
- Adds Director of Platform Operations Jean Marie Ferdegue: “Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.” </p>
-  <p>
- Plus, as Babylon continues to expand, “it will be very easy to onboard new countries,” says Vallée. “Fifteen months ago when we deployed this platform, we had one big environment in the U.K., but now we have one in Canada, we have one in Asia, and we have one coming in the U.S. This is one of the things that Kubernetes and the other cloud native projects have enabled for us.”
-  </p>
-  <p>
-  Babylon’s road map for cloud native involves onboarding all of the company’s AI efforts to the platform. Increasingly, that includes AI services of care. “I think this is going to be an interesting field where AI and healthcare meet,” Vallée says. “It’s kind of a complex problem and there’s a lot of issues around this. So with our platform, we want to say, ‘What can we do to make this less painful for our developers and machine learning engineers?’”
-</p>
-</div>
-</section>
-</body>
+<p>Another important type of work that's done on the platform is clinical validation for new applications such as Babylon's Symptom Checker, which calculates the probability of a disease given the evidence input by the user. "Being in healthcare, we want all of our models to be safe before they're going to hit production," says Vallée. Using Argo for GitOps "enabled us to scale the process massively."</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/babylon/banner2.jpg"
+  author="JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON"
+>}}
+"Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases."
+{{< /case-studies/quote >}}
+
+<p>Researchers used to have to wait up to 10 hours to get results on new versions of their models. With Kubernetes, that time is now down to under 20 minutes. Plus, previously they could only run one clinical validation at a time, now they can run many parallel ones if they need to—a huge benefit considering that in the past three years, Babylon has grown from 100 to 1,600 employees.</p>
+
+<p>"Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation," says Chief Technology Officer Caroline Hargrove.</p>
+
+<p>Adds Director of Platform Operations Jean Marie Ferdegue: "Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases."</p>
+
+<p>Plus, as Babylon continues to expand, "it will be very easy to onboard new countries," says Vallée. "Fifteen months ago when we deployed this platform, we had one big environment in the U.K., but now we have one in Canada, we have one in Asia, and we have one coming in the U.S. This is one of the things that Kubernetes and the other cloud native projects have enabled for us."</p>
+
+<p>Babylon's road map for cloud native involves onboarding all of the company's AI efforts to the platform. Increasingly, that includes AI services of care. "I think this is going to be an interesting field where AI and healthcare meet," Vallée says. "It's kind of a complex problem and there's a lot of issues around this. So with our platform, we want to say, 'What can we do to make this less painful for our developers and machine learning engineers?'"</p>
diff --git a/content/en/case-studies/blablacar/index.html b/content/en/case-studies/blablacar/index.html
index 2d55ffb8d0..e6537a672f 100644
--- a/content/en/case-studies/blablacar/index.html
+++ b/content/en/case-studies/blablacar/index.html
@@ -1,98 +1,85 @@
 ---
 title: BlaBlaCar Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_blablacar.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/blablacar/banner1.jpg
+heading_title_logo: /images/blablacar_logo.png
+subheading: >
+  Turning to Containerization to Support Millions of Rideshares
+case_study_details:
+  - Company: BlaBlaCar
+  - Location: Paris, France
+  - Industry: Ridesharing Company
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/blablacar_logo.png" class="header_logo"><br /> <div class="subhead">Turning to Containerization to Support Millions of Rideshares</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The world's largest long-distance carpooling community, <a href="https://www.blablacar.com/">BlaBlaCar</a>, connects 40 million members across 22 countries. The company has been experiencing exponential growth since 2012 and needed its infrastructure to keep up. "When you're thinking about doubling the number of servers, you start thinking, 'What should I do to be more efficient?'" says Simon Lallemand, Infrastructure Engineer at BlaBlaCar. "The answer is not to hire more and more people just to deal with the servers and installation." The team knew they had to scale the platform, but wanted to stay on their own bare metal servers.</p>
 
-<div class="details">
-    Company &nbsp;<b>BlaBlaCar</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Paris, France</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Ridesharing Company</b>
-</div>
+<h2>Solution</h2>
 
-<hr />
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The world’s largest long-distance carpooling community, <a href="https://www.blablacar.com/">BlaBlaCar</a>, connects 40 million members across 22 countries. The company has been experiencing exponential growth since 2012 and needed its infrastructure to keep up. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Simon Lallemand, Infrastructure Engineer at BlaBlaCar. "The answer is not to hire more and more people just to deal with the servers and installation." The team knew they had to scale the platform, but wanted to stay on their own bare metal servers.
-    <br />
-    <br />
-      <h2>Solution</h2>
-        Opting not to shift to cloud virtualization or use a private cloud on their own servers, the BlaBlaCar team became early adopters of containerization, using the CoreOs runtime <a href="https://coreos.com/rkt">rkt</a>, initially deployed using <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> cluster manager. Last year, the company switched to <a href="http://kubernetes.io/">Kubernetes</a> orchestration, and now also uses <a href="https://prometheus.io/">Prometheus</a> for monitoring.
-      </div>
+<p>Opting not to shift to cloud virtualization or use a private cloud on their own servers, the BlaBlaCar team became early adopters of containerization, using the CoreOs runtime <a href="https://coreos.com/rkt">rkt</a>, initially deployed using <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> cluster manager. Last year, the company switched to <a href="http://kubernetes.io/">Kubernetes</a> orchestration, and now also uses <a href="https://prometheus.io/">Prometheus</a> for monitoring.</p>
 
-<div class="col2">
 <h2>Impact</h2>
-        "Before using containers, it would take sometimes a day, sometimes two, just to create a new service," says Lallemand. "With all the tooling that we made around the containers, copying a new service now is a matter of minutes. It’s really a huge gain. We are better at capacity planning in our data center because we have fewer constraints due to this abstraction between the services and the hardware we run on. For the developers, it also means they can focus only on the features that they’re developing, and not on the infrastructure."
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "When you’re switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br />- Simon Lallemand, Infrastructure Engineer at BlaBlaCar</span>
-  </div>
-</div>
 
-<section class="section2">
-<div class="fullcol">
-  <h2>For the 40 million users of <a href="https://www.blablacar.com/">BlaBlaCar</a>, it’s easy to find strangers headed in the same direction to share rides and costs. You can even choose how much "bla bla" chatter you want from a long-distance ride mate.</h2>
-  Behind the scenes, though, the infrastructure was falling woefully behind the rider community’s exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."<br /><br />
-  By 2015, the company had about 50 bare metal servers. The team was using a <a href="https://www.mysql.com/">MySQL</a> database and <a href="http://php.net/">PHP</a>, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, <a href="https://www.chef.io/chef/">Chef</a>, but had little automation in its process. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."<br /><br />
-  Instead, BlaBlaCar began its cloud-native journey but wasn’t sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn’t want to go to virtualization on premise.<br /><br />
-  The solution: containerization. This was early 2015 and containers were still relatively new. "It was a bold move at the time," says Lallemand. "We decided that the next servers that we would buy in the new data center would all be the same model, so we could outsource the maintenance of the servers. And we decided to go with containers and with <a href="https://coreos.com/">CoreOS</a> Container Linux as an abstraction for this hardware. It seemed future-proof to go with containers because we could see what companies were already doing with containers."
-</div>
-</section>
+<p>"Before using containers, it would take sometimes a day, sometimes two, just to create a new service," says Lallemand. "With all the tooling that we made around the containers, copying a new service now is a matter of minutes. It's really a huge gain. We are better at capacity planning in our data center because we have fewer constraints due to this abstraction between the services and the hardware we run on. For the developers, it also means they can focus only on the features that they're developing, and not on the infrastructure."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "With all the tooling that we made around the containers, copying a new service is a matter of minutes. It’s a huge gain. For the developers, it means they can focus only on the features that they’re developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
-  </div>
-</div>
+{{< case-studies/quote author="Simon Lallemand, Infrastructure Engineer at BlaBlaCar" >}}
+"When you're switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before."
+{{< /case-studies/quote >}}
 
-<section class="section3">
-<div class="fullcol">
-    Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with <a href="https://www.docker.com/">Docker</a> but decided to go with <a href="https://coreos.com/rkt">rkt</a>. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time,  the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.<br /><br />
-    Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand’s team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you’re focused on your product sometimes you forget if it’s really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."<br /><br />
-    After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as <a href="https://github.com/blablacar/dgr">dgr</a>, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools <a href="https://github.com/airbnb/nerve">Nerve</a> and <a href="http://airbnb.io/projects/synapse/">Synapse</a>; their versions, <a href="https://github.com/blablacar/go-nerve">Go-Nerve</a> and <a href="https://github.com/blablacar/go-synapse">Go-Synapse</a>, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.<br /><br />
-    At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It’s now at 100 percent.) "It’s a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."<br /><br />
-    In the middle of that peak season for carpooling, everything worked well. "The biggest impact that we had was for the deployment of new services," says Lallemand. "Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it’s really a huge gain. For the developers, it means they can focus only on the features that they’re developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
-</div>
-</section>
+{{< case-studies/lead >}}
+For the 40 million users of <a href="https://www.blablacar.com/">BlaBlaCar</a>, it's easy to find strangers headed in the same direction to share rides and costs. You can even choose how much "bla bla" chatter you want from a long-distance ride mate.
+{{< /case-studies/lead >}}
 
-<div class="banner4">
-  <div class="banner4text">
-    "We realized that there was a really strong community around it [Kubernetes], which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes."
-  </div>
-</div>
+<p>Behind the scenes, though, the infrastructure was falling woefully behind the rider community's exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."</p>
 
-<section class="section4">
-<div class="fullcol">
-    In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> tool from CoreOS to deploy their containers. (They did build a tool called <a href="https://github.com/blablacar/ggn">GGN</a>, which they’ve open-sourced, to make it more manageable for their system engineers to use.)<br /><br />
-    Still, the team knew that they’d want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don’t want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in <a href="http://kubernetes.io/">Kubernetes</a>, which had just begun supporting rkt implementation.<br /><br />
-    After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using <a href="https://prometheus.io/">Prometheus</a>, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.<br /><br />
-    BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It’s really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."<br /><br />
-    The team is particularly happy that they’re now able to plan capacity better in the company’s data center. "We have fewer constraints since we have this abstraction between the services and the hardware we run on," says Lallemand. "If we lose a server because there’s a hardware problem on it, we just move the containers onto another server. It’s much more efficient. We do that by just changing a line in the configuration file. And with Kubernetes, it should be automatic, so we would have nothing to do."
-</div>
-</section>
+<p>By 2015, the company had about 50 bare metal servers. The team was using a <a href="https://www.mysql.com/">MySQL</a> database and <a href="http://php.net/">PHP</a>, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, <a href="https://www.chef.io/chef/">Chef</a>, but had little automation in its process. "When you're thinking about doubling the number of servers, you start thinking, 'What should I do to be more efficient?'" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "If we lose a server because there’s a hardware problem on it, we just move the containers onto another server. It’s much more efficient. We do that by just changing a line in the configuration file. With Kubernetes, it should be automatic, so we would have nothing to do."
-  </div>
-</div>
+<p>Instead, BlaBlaCar began its cloud-native journey but wasn't sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn't want to go to virtualization on premise.</p>
 
-<section class="section5">
-<div class="fullcol">
-    And these advances ultimately trickle down to BlaBlaCar’s users. "We have improved availability overall on our website," says Lallemand. "When you’re switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."<br /><br />
-    Within BlaBlaCar’s technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different ‘tribes’—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster." <br /><br />
-    This DevOps transformation turned out to be a positive one for the company’s staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants." <br /><br />
-    With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don’t say microservices because they’re not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have." <br /><br />
-    When Lallemand speaks to other European companies curious about what BlaBlaCar has done with its infrastructure, he tells them to come along for the ride. "I tell them that it’s such a pleasure to deal with the infrastructure that we have today compared to what we had before," he says. "They just need to keep in mind their real motive, whether it’s flexibility in development or reliability or so on, and then go step by step towards reaching those objectives. That’s what we’ve done. It’s important not to do technology for the sake of technology. Do it for a purpose. Our focus was on helping the developers."
-</div>
-</section>
+<p>The solution: containerization. This was early 2015 and containers were still relatively new. "It was a bold move at the time," says Lallemand. "We decided that the next servers that we would buy in the new data center would all be the same model, so we could outsource the maintenance of the servers. And we decided to go with containers and with <a href="https://coreos.com/">CoreOS</a> Container Linux as an abstraction for this hardware. It seemed future-proof to go with containers because we could see what companies were already doing with containers."</p>
+
+{{< case-studies/quote image="/images/case-studies/blablacar/banner3.jpg">}}
+"With all the tooling that we made around the containers, copying a new service is a matter of minutes. It's a huge gain. For the developers, it means they can focus only on the features that they're developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
+{{< /case-studies/quote >}}
+
+<p>Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with <a href="https://www.docker.com/">Docker</a> but decided to go with <a href="https://coreos.com/rkt">rkt</a>. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time,  the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.</p>
+
+<p>Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand's team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you're focused on your product sometimes you forget if it's really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."</p>
+
+<p>After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as <a href="https://github.com/blablacar/dgr">dgr</a>, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools <a href="https://github.com/airbnb/nerve">Nerve</a> and <a href="http://airbnb.io/projects/synapse/">Synapse</a>; their versions, <a href="https://github.com/blablacar/go-nerve">Go-Nerve</a> and <a href="https://github.com/blablacar/go-synapse">Go-Synapse</a>, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.</p>
+
+<p>At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It's now at 100 percent.) "It's a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."</p>
+
+<p>In the middle of that peak season for carpooling, everything worked well. "The biggest impact that we had was for the deployment of new services," says Lallemand. "Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it's really a huge gain. For the developers, it means they can focus only on the features that they're developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."</p>
+
+{{< case-studies/quote image="/images/case-studies/blablacar/banner4.jpg" >}}
+"We realized that there was a really strong community around it [Kubernetes], which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> tool from CoreOS to deploy their containers. (They did build a tool called <a href="https://github.com/blablacar/ggn">GGN</a>, which they've open-sourced, to make it more manageable for their system engineers to use.)</p>
+
+<p>Still, the team knew that they'd want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don't want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in <a href="http://kubernetes.io/">Kubernetes</a>, which had just begun supporting rkt implementation.</p>
+
+<p>After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using <a href="https://prometheus.io/">Prometheus</a>, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.</p>
+
+<p>BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It's really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."</p>
+
+<p>The team is particularly happy that they're now able to plan capacity better in the company's data center. "We have fewer constraints since we have this abstraction between the services and the hardware we run on," says Lallemand. "If we lose a server because there's a hardware problem on it, we just move the containers onto another server. It's much more efficient. We do that by just changing a line in the configuration file. And with Kubernetes, it should be automatic, so we would have nothing to do."</p>
+
+{{< case-studies/quote >}}
+"If we lose a server because there's a hardware problem on it, we just move the containers onto another server. It's much more efficient. We do that by just changing a line in the configuration file. With Kubernetes, it should be automatic, so we would have nothing to do."
+{{< /case-studies/quote >}}
+
+<p>And these advances ultimately trickle down to BlaBlaCar's users. "We have improved availability overall on our website," says Lallemand. "When you're switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."</p>
+
+<p>Within BlaBlaCar's technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different 'tribes'—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster."</p>
+
+<p>This DevOps transformation turned out to be a positive one for the company's staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants."</p>
+
+<p>With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don't say microservices because they're not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have."</p>
+
+<p>When Lallemand speaks to other European companies curious about what BlaBlaCar has done with its infrastructure, he tells them to come along for the ride. "I tell them that it's such a pleasure to deal with the infrastructure that we have today compared to what we had before," he says. "They just need to keep in mind their real motive, whether it's flexibility in development or reliability or so on, and then go step by step towards reaching those objectives. That's what we've done. It's important not to do technology for the sake of technology. Do it for a purpose. Our focus was on helping the developers."</p>
diff --git a/content/en/case-studies/blackrock/index.html b/content/en/case-studies/blackrock/index.html
index 6bef0ec708..725d6bc057 100644
--- a/content/en/case-studies/blackrock/index.html
+++ b/content/en/case-studies/blackrock/index.html
@@ -1,112 +1,83 @@
 ---
 title: BlackRock Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_blackrock.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/blackrock/banner1.jpg
+heading_title_logo: /images/blackrock_logo.png
+subheading: >
+  Rolling Out Kubernetes in Production in 100 Days
+case_study_details:
+  - Company: BlackRock
+  - Location: New York, NY
+  - Industry: Financial Services
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY: <img src="/images/blackrock_logo.png" class="header_logo"><br>
-    <div class="subhead">Rolling Out Kubernetes in Production in 100 Days</div>
-  </h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The world's largest asset manager, <a href="https://www.blackrock.com/investing">BlackRock</a> operates a very controlled static deployment scheme, which has allowed for scalability over the years. But in their data science division, there was a need for more dynamic access to resources. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Michael Francis, a Managing Director in BlackRock's  Product Group, which runs the company's investment management platform. "Managing complex Python installations on users' desktops is really hard because everyone ends up with slightly different environments. We have existing environments that do these things, but we needed to make it real, expansive and scalable. Being able to spin that up on demand, tear it down, make that much more dynamic, became a critical thought process for us. It's not so much that we had to solve our main core production problem, it's how do we extend that? How do we evolve?"</p>
 
-<div class="details">
-    Company &nbsp;<b>BlackRock</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, NY</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Financial Services</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>Drawing from what they learned during a pilot done last year using <a href="https://www.docker.com">Docker</a> environments, Francis put together a cross-sectional team of 20 to build an investor research web app using <a href="https://kubernetes.io">Kubernetes</a> with the goal of getting it into production within one quarter.</p>
 
-<section class="section1">
-
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The world’s largest asset manager, <a href="https://www.blackrock.com/investing">BlackRock</a> operates a very controlled static deployment scheme, which has allowed for scalability over the years. But in their data science division, there was a need for more dynamic access to resources. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Michael Francis, a Managing Director in BlackRock’s  Product Group, which runs the company’s investment management platform. "Managing complex Python installations on users’ desktops is really hard because everyone ends up with slightly different environments. We have existing environments that do these things, but we needed to make it real, expansive and scalable. Being able to spin that up on demand, tear it down, make that much more dynamic, became a critical thought process for us. It’s not so much that we had to solve our main core production problem, it’s how do we extend that? How do we evolve?"
-      </div>
-
-<div class="col2">
-  <h2>Solution</h2>
-    Drawing from what they learned during a pilot done last year using <a href="https://www.docker.com">Docker</a> environments, Francis put together a cross-sectional team of 20 to build an investor research web app using <a href="https://kubernetes.io">Kubernetes</a> with the goal of getting it into production within one quarter.
-<br><br>
 <h2>Impact</h2>
-        "Our goal was: How do you give people tools rapidly without having to install them on their desktop?" says Francis. And the team hit the goal within 100 days. Francis is pleased with the results and says, "We’re going to use this infrastructure for lots of other application workloads as time goes on. It’s not just data science; it’s this style of application that needs the dynamism. But I think we’re 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues. What’s interesting is that just having this technology there is changing the way our developers are starting to think about their future development."
 
-</div>
-</div>
+<p>"Our goal was: How do you give people tools rapidly without having to install them on their desktop?" says Francis. And the team hit the goal within 100 days. Francis is pleased with the results and says, "We're going to use this infrastructure for lots of other application workloads as time goes on. It's not just data science; it's this style of application that needs the dynamism. But I think we're 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues. What's interesting is that just having this technology there is changing the way our developers are starting to think about their future development."</p>
 
-</section>
+{{< case-studies/quote author="Michael Francis, Managing Director, BlackRock">}}
+"My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don't have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."
+{{< /case-studies/quote >}}
 
-<div class="banner2">
-  <div class="banner2text">
-    "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don’t have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Michael Francis, Managing Director, BlackRock</span>
-  </div>
-</div>
+<p>One of the management objectives for BlackRock's  Product Group employees in 2017 was to "build cool stuff." Led by Managing Director Michael Francis, a cross-sectional group of 20 did just that: They rolled out a full production Kubernetes environment and released a new investor research web app on it. In 100 days.</p>
 
-<section class="section2">
+<p>For a company that's the world's largest asset manager, "just equipment procurement can take 100 days sometimes, let alone from inception to delivery," says Karl Wieman, a Senior System Administrator. "It was an aggressive schedule. But it moved the dial." In fact, the project achieved two goals: It solved a business problem (creating the needed web app) as well as provided real-world, in-production experience with Kubernetes, a cloud-native technology that the company was eager to explore. "It's not so much that we had to solve our main core production problem, it's how do we extend that? How do we evolve?" says Francis. The ultimate success of this project, beyond delivering the app, lies in the fact that "we've managed to integrate a radically new thought process into a controlled infrastructure that we didn't want to change."</p>
 
-<div class="fullcol">
-  One of the management objectives for BlackRock’s  Product Group employees in 2017 was to "build cool stuff." Led by Managing Director Michael Francis, a cross-sectional group of 20 did just that: They rolled out a full production Kubernetes environment and released a new investor research web app on it. In 100 days.<br><br>
-  For a company that’s the world’s largest asset manager, "just equipment procurement can take 100 days sometimes, let alone from inception to delivery," says Karl Wieman, a Senior System Administrator. "It was an aggressive schedule. But it moved the dial."
-  In fact, the project achieved two goals: It solved a business problem (creating the needed web app) as well as provided real-world, in-production experience with Kubernetes, a cloud-native technology that the company was eager to explore. "It’s not so much that we had to solve our main core production problem, it’s how do we extend that? How do we evolve?" says Francis. The ultimate success of this project, beyond delivering the app, lies in the fact that "we’ve managed to integrate a radically new thought process into a controlled infrastructure that we didn’t want to change."<br><br>
-  After all, in its three decades of existence, BlackRock has "a very well-established environment for managing our compute resources," says Francis. "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that’s very cloudish in concept. We’re able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."<br><br>
-  Though that works well for the core production, the company has found that some data science workloads require more dynamic access to resources. "It’s a very bursty process," says Francis, who is head of data for the company’s Aladdin investment management platform division.<br><br>
-  Aladdin, which connects the people, information and technology needed for money management in real time, is used internally and is also sold as a platform to other asset managers and insurance companies. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Francis. But "managing complex Python installations on users’ desktops is really hard because everyone ends up with slightly different environments. Docker allows us to flatten that environment."
-</div>
-</section>
+<p>After all, in its three decades of existence, BlackRock has "a very well-established environment for managing our compute resources," says Francis. "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that's very cloudish in concept. We're able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that’s very cloudish in concept. We’re able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."
-  </div>
-</div>
+<p>Though that works well for the core production, the company has found that some data science workloads require more dynamic access to resources. "It's a very bursty process," says Francis, who is head of data for the company's Aladdin investment management platform division.</p>
 
-<section class="section3">
-<div class="fullcol">
-  Still, challenges remain. "If you have a shared cluster, you get this storming herd problem where everyone wants to do the same thing at the same time," says Francis. "You could put limits on it, but you’d have to build an infrastructure to define limits for our processes, and the Python notebooks weren’t really designed for that. We have existing environments that do these things, but we needed to make it real, expansive, and scalable. Being able to spin that up on demand, tear it down, and make that much more dynamic, became a critical thought process for us."<br><br>
-  Made up of managers from technology, infrastructure, production operations, development and information security, Francis’s team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using <a href="https://www.ansible.com">Ansible</a> and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don’t understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn’t build anywhere near the amount we thought we were going to end up building."<br><br>
-  In search of a solution in which they could manage usage on a user-by-user level, Francis’s team gravitated to Red Hat’s <a href="https://www.openshift.com">OpenShift</a> Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years’ time, in some form. And right now, in this space, Kubernetes feels like the one that’s going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that’s an indicator of the momentum."<br><br>
-  Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock’s existing framework. "It’s about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"<br><br>
-  The first (anticipated) speed bump was working around issues behind BlackRock’s corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn’t necessarily work." The team ran into these types of problems using <a href="/docs/getting-started-guides/minikube/">Minikube</a> and did a few small pushes back to the open source project.
+<p>Aladdin, which connects the people, information and technology needed for money management in real time, is used internally and is also sold as a platform to other asset managers and insurance companies. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Francis. But "managing complex Python installations on users' desktops is really hard because everyone ends up with slightly different environments. Docker allows us to flatten that environment."</p>
 
+{{< case-studies/quote image="/images/case-studies/blackrock/banner3.jpg">}}
+"We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that's very cloudish in concept. We're able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>Still, challenges remain. "If you have a shared cluster, you get this storming herd problem where everyone wants to do the same thing at the same time," says Francis. "You could put limits on it, but you'd have to build an infrastructure to define limits for our processes, and the Python notebooks weren't really designed for that. We have existing environments that do these things, but we needed to make it real, expansive, and scalable. Being able to spin that up on demand, tear it down, and make that much more dynamic, became a critical thought process for us."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "Typically we make technology choices that we believe are going to be here in 5-10 years’ time, in some form. And right now, in this space, Kubernetes feels like the one that’s going to be there."
-  </div>
-</div>
+<p>Made up of managers from technology, infrastructure, production operations, development and information security, Francis's team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using <a href="https://www.ansible.com">Ansible</a> and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don't understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn't build anywhere near the amount we thought we were going to end up building."</p>
 
-<section class="section4">
-<div class="fullcol">
-  There were also questions about service discovery. "You can think of Aladdin as a cloud of services with APIs between them that allows us to build applications rapidly," says Francis. "It’s all on a proprietary message bus, which gives us all sorts of advantages but at the same time, how does that play in a third party [platform]?"<br><br>
-  Another issue they had to navigate was that in BlackRock’s existing system, the messaging protocol has different instances in the different development, test and production environments. While Kubernetes enables a more DevOps-style model, it didn’t make sense for BlackRock. "I think what we are very proud of is that the ability for us to push into production is still incredibly rapid in this [new] infrastructure, but we have the control points in place, and we didn’t have to disrupt everything," says Francis. "A lot of the cost of this development was thinking how best to leverage our internal tools. So it was less costly than we actually thought it was going to be."<br><br>
-  The project leveraged tools associated with the messaging bus, for example. "The way that the Kubernetes cluster will talk to our internal messaging platform is through a gateway program, and this gateway program already has built-in checks and throttles," says Morris. "We can use them to control and potentially throttle the requests coming in from Kubernetes’s very elastic infrastructure to the production infrastructure. We’ll continue to go in that direction. It enables us to scale as we need to from the operational perspective."<br><br>
-  The solution also had to be complementary with BlackRock’s centralized operational support team structure. "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools," Morris explains. "That means that I don’t need to hire more people."<br><br>
-  With those points established, the team created a procedure for the project: "We rolled this out first to a development environment, then moved on to a testing environment and then eventually to two production environments, in that sequential order," says Maskallis. "That drove a lot of our learning curve. We have all these moving parts, the software components on the infrastructure side, the software components with Kubernetes directly, the interconnectivity with the rest of the environment that we operate here at BlackRock, and how we connect all these pieces. If we came across issues, we fixed them, and then moved on to the different environments to replicate that until we eventually ended up in our production environment where this particular cluster is supposed to live."<br><br>
-  The team had weekly one-hour working sessions with all the members (who are located around the world) participating, and smaller breakout or deep-dive meetings focusing on specific technical details. Possible solutions would be reported back to the group and debated the following week. "I think what made it a successful experiment was people had to work to learn, and they shared their experiences with others," says Vice President and Software Developer Fouad Semaan. Then, Francis says, "We gave our engineers the space to do what they’re good at. This hasn’t been top-down."
+<p>In search of a solution in which they could manage usage on a user-by-user level, Francis's team gravitated to Red Hat's <a href="https://www.openshift.com">OpenShift</a> Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years' time, in some form. And right now, in this space, Kubernetes feels like the one that's going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that's an indicator of the momentum."</p>
 
+<p>Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock's existing framework. "It's about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"</p>
 
-</div>
-</section>
+<p>The first (anticipated) speed bump was working around issues behind BlackRock's corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn't necessarily work." The team ran into these types of problems using <a href="/docs/getting-started-guides/minikube/">Minikube</a> and did a few small pushes back to the open source project.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools. That means that I don’t need to hire more people."
+{{< case-studies/quote image="/images/case-studies/blackrock/banner4.jpg">}}
+"Typically we make technology choices that we believe are going to be here in 5-10 years' time, in some form. And right now, in this space, Kubernetes feels like the one that's going to be there."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
+<p>There were also questions about service discovery. "You can think of Aladdin as a cloud of services with APIs between them that allows us to build applications rapidly," says Francis. "It's all on a proprietary message bus, which gives us all sorts of advantages but at the same time, how does that play in a third party [platform]?"</p>
 
-<section class="section5">
-<div class="fullcol">
-  They were led by one key axiom: To stay focused and avoid scope creep. This meant that they wouldn’t use features that weren’t in the core of Kubernetes and Docker. But if there was a real need, they’d build the features themselves. Luckily, Francis says, "Because of the rapidity of the development, a lot of things we thought we would have to build ourselves have been rolled into the core product. [The package manager<a href="https://helm.sh"> Helm</a> is one example]. People have similar problems."<br><br>
-  By the end of the 100 days, the app was up and running for internal BlackRock users. The initial capacity of 30 users was hit within hours, and quickly increased to 150. "People were immediately all over it," says Francis. In the next phase of this project, they are planning to scale up the cluster to have more capacity.<br><br>
-  Even more importantly, they now have in-production experience with Kubernetes that they can continue to build on—and a complete framework for rolling out new applications. "We’re going to use this infrastructure for lots of other application workloads as time goes on. It’s not just data science; it’s this style of application that needs the dynamism," says Francis. "Is it the right place to move our core production processes onto? It might be. We’re not at a point where we can say yes or no, but we felt that having real production experience with something like Kubernetes at some form and scale would allow us to understand that. I think we’re 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues."<br><br>
-  For other big companies considering a project like this, Francis says commitment and dedication are key: "We got the signoff from [senior management] from day one, with the commitment that we were able to get the right people. If I had to isolate what makes something complex like this succeed, I would say senior hands-on people who can actually drive it make a huge difference." With that in place, he adds, "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don’t have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."
+<p>Another issue they had to navigate was that in BlackRock's existing system, the messaging protocol has different instances in the different development, test and production environments. While Kubernetes enables a more DevOps-style model, it didn't make sense for BlackRock. "I think what we are very proud of is that the ability for us to push into production is still incredibly rapid in this [new] infrastructure, but we have the control points in place, and we didn't have to disrupt everything," says Francis. "A lot of the cost of this development was thinking how best to leverage our internal tools. So it was less costly than we actually thought it was going to be."</p>
 
-</div>
-</section>
+<p>The project leveraged tools associated with the messaging bus, for example. "The way that the Kubernetes cluster will talk to our internal messaging platform is through a gateway program, and this gateway program already has built-in checks and throttles," says Morris. "We can use them to control and potentially throttle the requests coming in from Kubernetes's very elastic infrastructure to the production infrastructure. We'll continue to go in that direction. It enables us to scale as we need to from the operational perspective."</p>
+
+<p>The solution also had to be complementary with BlackRock's centralized operational support team structure. "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools," Morris explains. "That means that I don't need to hire more people."</p>
+
+<p>With those points established, the team created a procedure for the project: "We rolled this out first to a development environment, then moved on to a testing environment and then eventually to two production environments, in that sequential order," says Maskallis. "That drove a lot of our learning curve. We have all these moving parts, the software components on the infrastructure side, the software components with Kubernetes directly, the interconnectivity with the rest of the environment that we operate here at BlackRock, and how we connect all these pieces. If we came across issues, we fixed them, and then moved on to the different environments to replicate that until we eventually ended up in our production environment where this particular cluster is supposed to live."</p>
+
+<p>The team had weekly one-hour working sessions with all the members (who are located around the world) participating, and smaller breakout or deep-dive meetings focusing on specific technical details. Possible solutions would be reported back to the group and debated the following week. "I think what made it a successful experiment was people had to work to learn, and they shared their experiences with others," says Vice President and Software Developer Fouad Semaan. Then, Francis says, "We gave our engineers the space to do what they're good at. This hasn't been top-down."</p>
+
+{{< case-studies/quote >}}
+"The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools. That means that I don't need to hire more people."
+{{< /case-studies/quote >}}
+
+<p>They were led by one key axiom: To stay focused and avoid scope creep. This meant that they wouldn't use features that weren't in the core of Kubernetes and Docker. But if there was a real need, they'd build the features themselves. Luckily, Francis says, "Because of the rapidity of the development, a lot of things we thought we would have to build ourselves have been rolled into the core product. [The package manager<a href="https://helm.sh"> Helm</a> is one example]. People have similar problems."</p>
+
+<p>By the end of the 100 days, the app was up and running for internal BlackRock users. The initial capacity of 30 users was hit within hours, and quickly increased to 150. "People were immediately all over it," says Francis. In the next phase of this project, they are planning to scale up the cluster to have more capacity.</p>
+
+<p>Even more importantly, they now have in-production experience with Kubernetes that they can continue to build on—and a complete framework for rolling out new applications. "We're going to use this infrastructure for lots of other application workloads as time goes on. It's not just data science; it's this style of application that needs the dynamism," says Francis. "Is it the right place to move our core production processes onto? It might be. We're not at a point where we can say yes or no, but we felt that having real production experience with something like Kubernetes at some form and scale would allow us to understand that. I think we're 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues."</p>
+
+<p>For other big companies considering a project like this, Francis says commitment and dedication are key: "We got the signoff from [senior management] from day one, with the commitment that we were able to get the right people. If I had to isolate what makes something complex like this succeed, I would say senior hands-on people who can actually drive it make a huge difference." With that in place, he adds, "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don't have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."</p>
diff --git a/content/en/case-studies/booking-com/index.html b/content/en/case-studies/booking-com/index.html
index 99369a2bf9..74d5b282b1 100644
--- a/content/en/case-studies/booking-com/index.html
+++ b/content/en/case-studies/booking-com/index.html
@@ -3,115 +3,84 @@ title: Booking.com Case Study
 linkTitle: Booking.com
 case_study_styles: true
 cid: caseStudies
-css: /css/case-studies-gradient.css
 logo: booking.com_featured_logo.png
 featured: true
 weight: 3
 quote: >
   We realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/booking/banner1.jpg
+heading_title_text: Booking.com
+use_gradient_overlay: true
+subheading: >
+  After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own
+case_study_details:
+  - Company: Booking.com
+  - Location: Netherlands
+  - Industry: Travel
 ---
 
-​
+<h2>Challenge</h2>
 
+<p>In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a "knowledge bottleneck" when challenges arose. Trying to scale that support wasn't sustainable.</p>
 
-<div class="article image overlay" style="background-image: url('/images/case-studies/booking/banner1.jpg')">
-  <h1> CASE STUDY: Booking.com</h1>
-  <div class="subhead">After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own</div>
-</div>
-​
-​
-<div class="details">
-    Company &nbsp;<b>Booking.com</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Netherlands</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Travel</b>
-</div>
-​
-<hr>
-<section class="section1">
-<div class="colsgradient">
-  <div class="col1">
-    <h2>Challenge</h2>
-  In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a “knowledge bottleneck” when challenges arose. Trying to scale that support wasn’t sustainable.
+<h2>Solution</h2>
 
+<p>After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. "This is not a magical platform," says Ben Tyler, Principal Developer, B Platform Track. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge."</p>
 
-    <h2>Solution</h2>
-    After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. “This is not a magical platform,” says Ben Tyler, Principal Developer, B Platform Track. “We’re not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we’re going to do everything we can to make sure they have access to that knowledge.”
-​
 <h2>Impact</h2>
-   Despite the learning curve, there’s been a great uptick in adoption of the new Kubernetes platform. Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn’t. On the new platform, it can take as few as 10 minutes. About 500 new services were built on the platform in the first 8 months.
-</div>
-</div>
-</section>
-<div class="article image overlay" style="background-image: url('/images/case-studies/booking/banner2.jpg');">
-  <div class="quotetext">
-    “As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.”
-<p><div class="quoteauthortext">- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM</div></p>
-  </div>
-</div>
-​
-​
-<section class="section2">
-<div class="fullcol">
-  <h4>Booking.com has a long history with Kubernetes: In 2015, a team at the travel platform prototyped a container platform based on Mesos and Marathon.
-</h4>
 
-  <p>Impressed by what the technology offered, but in need of enterprise features at its scale—the site handles more than 1.5 million room-night reservations a day on average—the team decided to adopt an OpenShift platform.</p>
+<p>Despite the learning curve, there's been a great uptick in adoption of the new Kubernetes platform. Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn't. On the new platform, it can take as few as 10 minutes. About 500 new services were built on the platform in the first 8 months.</p>
 
-  <p>This platform, which was wrapped in a Heroku-style, high-level CLI interface, “was definitely popular with our product developers,” says Ben Tyler, Principal Developer, B Platform Track. “We gave them faster access to infrastructure.”</p>
+{{< case-studies/quote
+  image="/images/case-studies/booking/banner2.jpg"
+  author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM"
+>}}
+"As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It's a super healthy dynamic."
+{{< /case-studies/quote >}}
 
-<p>But, he adds, “anytime something went slightly off the rails, developers didn’t have any of the knowledge required to support themselves.”</p>
+​{{< case-studies/lead >}}
+Booking.com has a long history with Kubernetes: In 2015, a team at the travel platform prototyped a container platform based on Mesos and Marathon.
+{{< /case-studies/lead >}}
 
- <p>And after a year of operating this platform, the infrastructure team found that it had become “a knowledge bottleneck,” he says. “Most of the developers who used it did not know it was Kubernetes underneath. An application failure and a platform failure both looked like failures of that Heroku-style tool.”</p>
-  <p>
-   Scaling the necessary support did not seem feasible or sustainable, so the platform team needed a new solution. The understanding of Kubernetes that they had gained operating the OpenShift platform gave them confidence to build a vanilla Kubernetes platform of their own and customize it to suit the company’s needs.</p>
+<p>Impressed by what the technology offered, but in need of enterprise features at its scale—the site handles more than 1.5 million room-night reservations a day on average—the team decided to adopt an OpenShift platform.</p>
 
+<p>This platform, which was wrapped in a Heroku-style, high-level CLI interface, "was definitely popular with our product developers," says Ben Tyler, Principal Developer, B Platform Track. "We gave them faster access to infrastructure."</p>
 
-</div>
-</section>
-​
-<div class="greybanner">
-  <div class="greyquotetext">
-     “For entering the landscape, OpenShift was definitely very helpful. It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge.”<p><div class="quoteauthortext">- EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM</div></p>
-  </div>
-</div>
-​
-<section class="section3">
-<div class="fullcol">
-   <p>
-    “For entering the landscape, OpenShift was definitely very helpful,” says Eduard Iacoboaia, Senior System Administrator, B Platform Track. “It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge.” </p>
- <p>
-   Iacoboaia’s team had customized a lot of OpenShift tools to make them work at Booking.com, and “those integrations points were kind of fragile,” he says. “We spent much more time understanding all the components of Kubernetes, how they work, how they interact with each other.” That research led the team to switch from OpenShift’s built-in Ansible playbooks to Puppet deployments, which are used for the rest of Booking’s infrastructure. The control plane was also moved from inside the cluster onto bare metal, as the company runs tens of thousands of bare-metal servers and a large infrastructure for running applications on bare metal. (Booking runs Kubernetes in multiple clusters in multiple data centers across the various regions where it has compute.) “We decided to keep it as simple as possible and to also use the tools that we know best,” says Iacoboaia. </p>
-   <p>
-  The other big change was that product engineers would have to learn Kubernetes in order to onboard. “This is not a magical platform,” says Tyler. “We’re not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we’re going to do everything we can to make sure they have access to that knowledge.” That includes trainings, blog posts, videos, and Udemy courses. </p>
-  <p>
-  Despite the learning curve, there’s been a great uptick in adoption of the new Kubernetes platform. “I think the reason we’ve been able to strike this bargain successfully is that we’re not asking them to learn a proprietary app system,” says Tyler. “We’re asking them to learn something that’s open source, where the knowledge is transferable. They’re investing in their own careers by learning Kubernetes.”</p>
-  <p>
- One clear sign that this strategy has been a success is that in the support channel, when users have questions, other product engineers are jumping in to respond. “I haven’t seen that kind of community engagement around a particular platform product internally before,” says Tyler. “It helps a lot that it’s visibly an ecosystem standard outside of the company, so people feel value in investing in that knowledge and sharing it with others, which is really, really powerful.” </p>
+<p>But, he adds, "anytime something went slightly off the rails, developers didn't have any of the knowledge required to support themselves."</p>
 
+<p>And after a year of operating this platform, the infrastructure team found that it had become "a knowledge bottleneck," he says. "Most of the developers who used it did not know it was Kubernetes underneath. An application failure and a platform failure both looked like failures of that Heroku-style tool."</p>
 
-</div>
-</section>
-​
-​
-  <div class="article image overlay" style="background-image: url('/images/case-studies/booking/banner3.jpg');">
-  <div class="quotetext">
- “We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time. The time to gain access to resources is decreased enormously.” <p><div class="quoteauthortext">- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM</div></p>
-  </div>
-</div>
-​
-<section class="section5">
-<div class="fullcol">
-  <p>
- There’s other quantifiable evidence too: Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn’t. On the new platform, it takes 10 minutes. “We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time,” says Tyler. “The time to gain access to resources is decreased enormously.” About 500 new services were built in the first 8 months on the platform, with hundreds of releases per day.  </p>
-  <p>
-  The platform offers different “layers of contracts, so to speak,” says Tyler. “At the very base, it’s just Kubernetes. If you’re a pro Kubernetes user, here’s a Kubernetes API, just like you get from GKE or AKS. We’re trying to be a provider on that same level. But our whole job inside the company is to be a bigger value add than just vanilla infrastructure, so we provide a set of base images for our main stacks, Perl and Java.”
-</p>
-<p>
-  And “as our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better more native Kubernetes experience, which is great,” says Tyler. “It’s a super healthy dynamic.”</p>
-<p>
-  The platform also includes other CNCF technologies, such as Envoy, Helm, and Prometheus. Most of the critical service traffic for Booking.com is routed through Envoy, and Prometheus is used primarily to monitor infrastructure components. Helm is consumed as a packaging standard. The team also developed and open sourced Shipper, an extension for Kubernetes to add more complex rollout strategies and multi-cluster orchestration.
-</p>
-<p>
-  To be sure, there have been internal discussions about the wisdom of building a Kubernetes platform from the ground up. “This is not really our core competency—Kubernetes and travel, they’re kind of far apart, right?” says Tyler. “But we’ve made a couple of bets on CNCF components that have worked out really well for us. Envoy and Kubernetes, in particular, have been really beneficial to our organization. We were able to customize them, either because we could look at the source code or because they had extension points, and we were able to get value out of them very quickly without having to change any paradigms internally.”
-</p>
-</div>
-</section>
-</body>
+<p>Scaling the necessary support did not seem feasible or sustainable, so the platform team needed a new solution. The understanding of Kubernetes that they had gained operating the OpenShift platform gave them confidence to build a vanilla Kubernetes platform of their own and customize it to suit the company's needs.</p>
+
+{{< case-studies/quote author="EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM" >}}
+"For entering the landscape, OpenShift was definitely very helpful. It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge."
+{{< /case-studies/quote >}}
+
+<p>"For entering the landscape, OpenShift was definitely very helpful," says Eduard Iacoboaia, Senior System Administrator, B Platform Track. "It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge."</p>
+
+<p>Iacoboaia's team had customized a lot of OpenShift tools to make them work at Booking.com, and "those integrations points were kind of fragile," he says. "We spent much more time understanding all the components of Kubernetes, how they work, how they interact with each other." That research led the team to switch from OpenShift's built-in Ansible playbooks to Puppet deployments, which are used for the rest of Booking's infrastructure. The control plane was also moved from inside the cluster onto bare metal, as the company runs tens of thousands of bare-metal servers and a large infrastructure for running applications on bare metal. (Booking runs Kubernetes in multiple clusters in multiple data centers across the various regions where it has compute.) "We decided to keep it as simple as possible and to also use the tools that we know best," says Iacoboaia.</p>
+
+<p>The other big change was that product engineers would have to learn Kubernetes in order to onboard. "This is not a magical platform," says Tyler. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge." That includes trainings, blog posts, videos, and Udemy courses.</p>
+
+<p>Despite the learning curve, there's been a great uptick in adoption of the new Kubernetes platform. "I think the reason we've been able to strike this bargain successfully is that we're not asking them to learn a proprietary app system," says Tyler. "We're asking them to learn something that's open source, where the knowledge is transferable. They're investing in their own careers by learning Kubernetes."</p>
+
+<p>One clear sign that this strategy has been a success is that in the support channel, when users have questions, other product engineers are jumping in to respond. "I haven't seen that kind of community engagement around a particular platform product internally before," says Tyler. "It helps a lot that it's visibly an ecosystem standard outside of the company, so people feel value in investing in that knowledge and sharing it with others, which is really, really powerful."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/booking/banner3.jpg"
+  author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM"
+>}}
+"We have a tutorial. You follow the tutorial. Your code is running. Then, it's business-logic time. The time to gain access to resources is decreased enormously."
+{{< /case-studies/quote >}}
+
+<p>There's other quantifiable evidence too: Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn't. On the new platform, it takes 10 minutes. "We have a tutorial. You follow the tutorial. Your code is running. Then, it's business-logic time," says Tyler. "The time to gain access to resources is decreased enormously." About 500 new services were built in the first 8 months on the platform, with hundreds of releases per day.</p>
+
+<p>The platform offers different "layers of contracts, so to speak," says Tyler. "At the very base, it's just Kubernetes. If you're a pro Kubernetes user, here's a Kubernetes API, just like you get from GKE or AKS. We're trying to be a provider on that same level. But our whole job inside the company is to be a bigger value add than just vanilla infrastructure, so we provide a set of base images for our main stacks, Perl and Java."</p>
+
+<p>And "as our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better more native Kubernetes experience, which is great," says Tyler. "It's a super healthy dynamic."</p>
+
+<p>The platform also includes other CNCF technologies, such as Envoy, Helm, and Prometheus. Most of the critical service traffic for Booking.com is routed through Envoy, and Prometheus is used primarily to monitor infrastructure components. Helm is consumed as a packaging standard. The team also developed and open sourced Shipper, an extension for Kubernetes to add more complex rollout strategies and multi-cluster orchestration.</p>
+
+<p>To be sure, there have been internal discussions about the wisdom of building a Kubernetes platform from the ground up. "This is not really our core competency—Kubernetes and travel, they're kind of far apart, right?" says Tyler. "But we've made a couple of bets on CNCF components that have worked out really well for us. Envoy and Kubernetes, in particular, have been really beneficial to our organization. We were able to customize them, either because we could look at the source code or because they had extension points, and we were able to get value out of them very quickly without having to change any paradigms internally."</p>
diff --git a/content/en/case-studies/booz-allen/index.html b/content/en/case-studies/booz-allen/index.html
index fdda5e976a..7b53dc01ae 100644
--- a/content/en/case-studies/booz-allen/index.html
+++ b/content/en/case-studies/booz-allen/index.html
@@ -3,101 +3,78 @@ title: Booz Allen Case Study
 linkTitle: Booz Allen Hamilton
 case_study_styles: true
 cid: caseStudies
-css: /css/case-studies-gradient.css
 logo: booz-allen-featured-logo.svg
 featured: true
 weight: 2
 quote: >
-  Kubernetes is a great solution for us. It allows us to rapidly iterate on our clients’ demands.
+  Kubernetes is a great solution for us. It allows us to rapidly iterate on our clients' demands.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/booz-allen/banner4.jpg
+heading_title_text: Booz Allen Hamilton
+use_gradient_overlay: true
+subheading: >
+  How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes
+case_study_details:
+  - Company: Booz Allen Hamilton
+  - Location: United States
+  - Industry: Government
 ---
-​
 
+<h2>Challenge</h2>
 
-<div class="article image overlay" style="background-image: url('/images/case-studies/booz-allen/banner4.jpg')">
-  <h1> CASE STUDY: Booz Allen Hamilton</h1>
-  <div class="subhead">How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes</div>
-</div>
-​
-​
-<div class="details">
-    Company &nbsp;<b>Booz Allen Hamilton</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>United States</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Government</b>
-</div>
-​
-<hr>
-<section class="section1">
-<div class="colsgradient">
-  <div class="col1">
-    <h2>Challenge</h2>
-    In 2017, Booz Allen Hamilton’s Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton’s customers.
+<p>In 2017, Booz Allen Hamilton's Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers.</p>
+
+<h2>Solution</h2>
+
+<p>"The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff's team looked to Kubernetes for orchestration.</p>
 
-    <h2>Solution</h2>
-    “The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have,” says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff’s team looked to Kubernetes for orchestration.
-​
 <h2>Impact</h2>
-    With the recreation.gov Kubernetes platform, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. With monitoring, security, and logging built in, developers can create and publish new services to production within a week. Additionally, Folkoff says, “supporting the large, existing monoliths in the government is extremely expensive,” and migrating into a more modern platform has resulted in perhaps 50% cost savings.
-</div>
-</div>
-</section>
-<div class="article image overlay" style="background-image: url('/images/case-studies/booz-allen/banner2.jpg');">
-  <div class="quotetext">
-    "When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes."
-<p><div class="quoteauthortext">- JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON</div></p>
-  </div>
-</div>
-​
-​
-<section class="section2">
-<div class="fullcol">
-  <h4>The White House launched an IT modernization effort in 2017, and in addition to improving cybersecurity and shifting to the public cloud and a consolidated IT model, “the federal government is looking to provide a better experience to citizens in every way that we interact with the government through every channel,” says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff.</h4>
 
-  <p>To that end, Folkoff’s Strategic Innovation Group worked with the federal government last year to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country.</p>
+<p>With the recreation.gov Kubernetes platform, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. With monitoring, security, and logging built in, developers can create and publish new services to production within a week. Additionally, Folkoff says, "supporting the large, existing monoliths in the government is extremely expensive," and migrating into a more modern platform has resulted in perhaps 50% cost savings.</p>
 
-  <p>The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton’s customers. “The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have,” says Folkoff.</p>
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/booz-allen/banner2.jpg"
+  author="JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON"
+>}}
+"When there's a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that's the problem we're trying to help the government solve with tools like Kubernetes."
+{{< /case-studies/quote >}}
 ​
-<div class="greybanner">
-  <div class="greyquotetext">
-     "With CNCF, there’s a lot of focus on scale, and so there’s a lot of comfort knowing that as the project grows, we’re going to be comfortable using that tool set."<p><div class="quoteauthortext">- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON</div></p>
-  </div>
-</div>
+​{{< case-studies/lead >}}
+The White House launched an IT modernization effort in 2017, and in addition to improving cybersecurity and shifting to the public cloud and a consolidated IT model, "the federal government is looking to provide a better experience to citizens in every way that we interact with the government through every channel," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff.
+{{< /case-studies/lead >}}
+
+<p>To that end, Folkoff's Strategic Innovation Group worked with the federal government last year to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country.</p>
+
+<p>The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers. "The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Folkoff.</p>
+
+{{< case-studies/quote author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON" >}}
+"With CNCF, there's a lot of focus on scale, and so there's a lot of comfort knowing that as the project grows, we're going to be comfortable using that tool set."
+{{< /case-studies/quote >}}
+
+<p>Booz Allen Hamilton, which has provided consulting services to the federal government for more than a century, introduced microservices, Docker containers, and AWS to its federal agency clients about five years ago. The next logical step was Kubernetes for orchestration. "Knowing that we had to be really agile and really reliable and scalable, we felt that the only technology that we know that can enable those kinds of things are the ones the CNCF provides," Folkoff says. "One of the things that is always important for the government is to make sure that the things that we build really endure. Using technology that is supported across multiple different companies and has strong governance gives people a lot of confidence."</p>
+
+<p>Kubernetes was also aligned with the government's open source and IT modernization initiatives, so there has been an uptick in its usage at federal agencies over the past two years. "Now that Kubernetes is becoming offered as a service by the cloud providers like AWS and Microsoft, we're starting to see even more interest," says Chief Technologist Josh Boyd. Adds Folkoff: "With CNCF, there's a lot of focus on scale, and so there's a lot of comfort knowing that as the project grows, we're going to be comfortable using that tool set."</p>
+
+<p>The greenfield recreation.gov project allowed the team to build a new Kubernetes-enabled site running on AWS, and the migration lasted only a week, when the old site didn't take bookings. "For the actual transition, we just swapped a DNS server, and it only took about 35 seconds between the old site being down and our new site being up and available," Folkoff adds. </p>
 ​
-<section class="section3">
-<div class="fullcol">
-  <p>
-    Booz Allen Hamilton, which has provided consulting services to the federal government for more than a century, introduced microservices, Docker containers, and AWS to its federal agency clients about five years ago. The next logical step was Kubernetes for orchestration. “Knowing that we had to be really agile and really reliable and scalable, we felt that the only technology that we know that can enable those kinds of things are the ones the CNCF provides,” Folkoff says. “One of the things that is always important for the government is to make sure that the things that we build really endure. Using technology that is supported across multiple different companies and has strong governance gives people a lot of confidence.”</p>
-  <p>
-    Kubernetes was also aligned with the government’s open source and IT modernization initiatives, so there has been an uptick in its usage at federal agencies over the past two years. “Now that Kubernetes is becoming offered as a service by the cloud providers like AWS and Microsoft, we’re starting to see even more interest,” says Chief Technologist Josh Boyd. Adds Folkoff: “With CNCF, there’s a lot of focus on scale, and so there’s a lot of comfort knowing that as the project grows, we’re going to be comfortable using that tool set.” </p>
-  <p>
-    The greenfield recreation.gov project allowed the team to build a new Kubernetes-enabled site running on AWS, and the migration lasted only a week, when the old site didn’t take bookings. “For the actual transition, we just swapped a DNS server, and it only took about 35 seconds between the old site being down and our new site being up and available,” Folkoff adds. </p>
-  </p>
-</div>
-</section>
-​
-​
-  <div class="article image overlay" style="background-image: url('/images/case-studies/booz-allen/banner1.png');">
-  <div class="quotetext">
-  "Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event" <p><div class="quoteauthortext">- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON</div></p>
-  </div>
-</div>
-​
-<section class="section5">
-<div class="fullcol">
-  <p>
-    In addition to its work with the Department of Interior for recreation.gov, Booz Allen Hamilton has brought Kubernetes to various Defense, Intelligence, and civilian agencies. Says Boyd: “When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes.”</p>
-  <p>
-  For recreation.gov, the impact was clear and immediate. With the Kubernetes platform, Folkoff says, “if a new requirement for a permit comes out, we have the ability to design and develop and implement that completely independently of reserving a campsite. It provides a much better experience to users.” Today, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. </p>
-  <p>
-  Developer velocity has been improved. “When I want to do monitoring or security or logging, I don’t have to do anything to my services or my application to enable that anymore,” says Boyd. “I get all of this magic just by being on the Kubernetes platform.” With all of those things built in, developers can create and publish new services to production within one week. </p>
-  <p>
-  Additionally, Folkoff says, “supporting the large, existing monoliths in the government is extremely expensive,” and migrating into a more modern platform has resulted in perhaps 50% cost savings. “Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event,” he says. “For example, during a popular campsite release, camping-related services are scaled out while permit services are scaled down.”</p>
-  <p>
-  So far, “Kubernetes is a great solution for us,” says Folkoff. “It allows us to rapidly iterate on our clients’ demands.” Looking ahead, the team sees further adoption of the Kubernetes platform across federal agencies. Says Boyd: “You get the ability for the rapid delivery of business value for your customers. You now have observability into everything that you’re doing. You don’t have these onesies and twosies unicorn servers anymore. Now everything that you deploy is deployed in the same way, it’s all instrumented the same way, and it’s all built and deployed the same way through our CI/CD processes.”</p>
-  <p>
-  They also see a push toward re-platforming. “There’s still a lot of legacy workloads out there,” says Boyd. “We’ve got the new challenges of greenfield development and integration with legacy systems, but also that brown field of ‘Hey, how do I take this legacy monolith and get it onto a platform where now it’s instrumented with all the magic of the Kubernetes platform without having to do a whole lot to my application?’ I think re-platforming is a pretty big use case for the government right now.”</p>
-  <p>
-  And given the success that they’ve had with Kubernetes so far, Boyd says, “I think at this point that technology is becoming pretty easy to sell.” Adds Folkoff: “People are really excited about being able to deploy, scale, be reliable, and do cheaper maintenance of all of this.”
-  </p>
-</div>
-</section>
-</body>
+{{< case-studies/quote
+  image="/images/case-studies/booz-allen/banner1.png"
+  author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON"
+>}}
+"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event"
+{{< /case-studies/quote >}}
+
+<p>In addition to its work with the Department of Interior for recreation.gov, Booz Allen Hamilton has brought Kubernetes to various Defense, Intelligence, and civilian agencies. Says Boyd: "When there's a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that's the problem we're trying to help the government solve with tools like Kubernetes."</p>
+
+<p>For recreation.gov, the impact was clear and immediate. With the Kubernetes platform, Folkoff says, "if a new requirement for a permit comes out, we have the ability to design and develop and implement that completely independently of reserving a campsite. It provides a much better experience to users." Today, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day.</p>
+
+<p>Developer velocity has been improved. "When I want to do monitoring or security or logging, I don't have to do anything to my services or my application to enable that anymore," says Boyd. "I get all of this magic just by being on the Kubernetes platform." With all of those things built in, developers can create and publish new services to production within one week. </p>
+
+<p>Additionally, Folkoff says, "supporting the large, existing monoliths in the government is extremely expensive," and migrating into a more modern platform has resulted in perhaps 50% cost savings. "Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event," he says. "For example, during a popular campsite release, camping-related services are scaled out while permit services are scaled down."</p>
+
+<p>So far, "Kubernetes is a great solution for us," says Folkoff. "It allows us to rapidly iterate on our clients' demands." Looking ahead, the team sees further adoption of the Kubernetes platform across federal agencies. Says Boyd: "You get the ability for the rapid delivery of business value for your customers. You now have observability into everything that you're doing. You don't have these onesies and twosies unicorn servers anymore. Now everything that you deploy is deployed in the same way, it's all instrumented the same way, and it's all built and deployed the same way through our CI/CD processes."</p>
+
+<p>They also see a push toward re-platforming. "There's still a lot of legacy workloads out there," says Boyd. "We've got the new challenges of greenfield development and integration with legacy systems, but also that brown field of 'Hey, how do I take this legacy monolith and get it onto a platform where now it's instrumented with all the magic of the Kubernetes platform without having to do a whole lot to my application?' I think re-platforming is a pretty big use case for the government right now."</p>
+
+<p>And given the success that they've had with Kubernetes so far, Boyd says, "I think at this point that technology is becoming pretty easy to sell." Adds Folkoff: "People are really excited about being able to deploy, scale, be reliable, and do cheaper maintenance of all of this."</p>
diff --git a/content/en/case-studies/bose/index.html b/content/en/case-studies/bose/index.html
index c77f416c13..70deb6ce68 100644
--- a/content/en/case-studies/bose/index.html
+++ b/content/en/case-studies/bose/index.html
@@ -3,101 +3,85 @@ title: Bose Case Study
 linkTitle: Bose
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: bose_featured_logo.png
 featured: false
 weight: 2
 quote: >
-   The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles.
+   The CNCF Landscape quickly explains what's going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/bose/banner1.jpg
+heading_title_logo: /images/bose_logo.png
+subheading: >
+  Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes
+case_study_details:
+  - Company: Bose Corporation
+  - Location: Framingham, Massachusetts
+  - Industry: Consumer Electronics
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/bose/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/bose_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>A household name in high-quality audio equipment, <a href="https://www.bose.com/en_us/index.html">Bose</a> has offered connected products for more than five years, and as that demand grew, the infrastructure had to change to support it. "We needed to provide a mechanism for developers to rapidly prototype and deploy services all the way to production pretty fast," says Lead Cloud Engineer Josh West. In 2016, the company decided to start building a platform from scratch. The primary goal: "To be one to two steps ahead of the different product groups so that we are never scrambling to catch up with their scale," says Cloud Architecture Manager Dylan O'Mahony.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Bose Corporation</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Framingham, Massachusetts
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Consumer Electronics</b>
-</div>
+<p>From the beginning, the team knew it wanted a microservices architecture. After evaluating and prototyping a couple of orchestration solutions, the team decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> for its scaled IoT Platform-as-a-Service running on AWS. The platform, which also incorporated Prometheus monitoring, launched in production in 2017, serving over 3 million connected products from the get-go. Bose has since adopted a number of other CNCF technologies, including <a href="https://www.fluentd.org/">Fluentd</a>, <a href="https://coredns.io/">CoreDNS</a>, <a href="https://www.jaegertracing.io/">Jaeger</a>, and <a href="https://opentracing.io/">OpenTracing</a>.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    A household name in high-quality audio equipment, <a href="https://www.bose.com/en_us/index.html">Bose</a> has offered connected products for more than five years, and as that demand grew, the infrastructure had to change to support it. "We needed to provide a mechanism for developers to rapidly prototype and deploy services all the way to production pretty fast,” says Lead Cloud Engineer Josh West. In 2016, the company decided to start building a platform from scratch. The primary goal: "To be one to two steps ahead of the different product groups so that we are never scrambling to catch up with their scale,” says Cloud Architecture Manager Dylan O’Mahony.
-<br><br>
-    <h2>Solution</h2>
-    From the beginning, the team knew it wanted a microservices architecture. After evaluating and prototyping a couple of orchestration solutions, the team decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> for its scaled IoT Platform-as-a-Service running on AWS. The platform, which also incorporated Prometheus monitoring, launched in production in 2017, serving over 3 million connected products from the get-go. Bose has since adopted a number of other CNCF technologies, including <a href="https://www.fluentd.org/">Fluentd</a>, <a href="https://coredns.io/">CoreDNS</a>, <a href="https://www.jaegertracing.io/">Jaeger</a>, and <a href="https://opentracing.io/">OpenTracing</a>.
-<br><br>
 <h2>Impact</h2>
-    With about 100 engineers onboarded, the platform is now enabling 30,000 non-production deployments across dozens of microservices per year. In 2018, there were 1250+ production deployments. Just one production cluster holds 1,800 namespaces and 340 worker nodes. "We had a brand new service taken from concept through coding and deployment all the way to production, including hardening, security testing and so forth, in less than two and a half weeks,” says O’Mahony.
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "At Bose we’re building an IoT platform that has enabled our physical products. If it weren’t for Kubernetes and the rest of the CNCF projects being free open source software with such a strong community, we would never have achieved scale, or even gotten to launch&nbsp;on&nbsp;schedule."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Josh West, Lead Cloud Engineer, Bose</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>A household name in high-quality audio equipment, <a href="https://www.bose.com/en_us/index.html">Bose</a> has offered connected products for more than five years, and as that demand grew, the infrastructure had to change to support it. </h2>
-  "We needed to provide a mechanism for developers to rapidly prototype and deploy services all the way to production pretty fast,” says Lead Cloud Engineer Josh West. "There were a lot of cloud capabilities we wanted to provide to support our audio equipment and experiences.”<br><br>
-In 2016, the company decided to start building an IoT platform from scratch. The primary goal: "To be one to two steps ahead of the different product groups so that we are never scrambling to catch up with their scale,” says Cloud Architecture Manager Dylan O’Mahony. "If they release a new connected product, we want to be already well ahead of being able to handle whatever scale that they’re going to throw at us.”<br><br>
-From the beginning, the team knew it wanted a microservices architecture and platform as a service. After evaluating and prototyping orchestration solutions, including Mesos and Docker Swarm, the team decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> for its platform running on AWS. Kubernetes was still in 1.5, but already the technology could do much of what the team wanted and needed for the present and the future. For West, that meant having storage and network handled. O’Mahony points to Kubernetes’ portability in case Bose decides to go multi-cloud.<br><br>
-"Bose is a company that looks out for the long term,” says West. "Going with a quick commercial off-the-shelf solution might’ve worked for that point in time, but it would not have carried us forward, which is what we needed from Kubernetes and the CNCF.”
+<p>With about 100 engineers onboarded, the platform is now enabling 30,000 non-production deployments across dozens of microservices per year. In 2018, there were 1250+ production deployments. Just one production cluster holds 1,800 namespaces and 340 worker nodes. "We had a brand new service taken from concept through coding and deployment all the way to production, including hardening, security testing and so forth, in less than two and a half weeks," says O'Mahony.</p>
 
+{{< case-studies/quote author="Josh West, Lead Cloud Engineer, Bose" >}}
+"At Bose we're building an IoT platform that has enabled our physical products. If it weren't for Kubernetes and the rest of the CNCF projects being free open source software with such a strong community, we would never have achieved scale, or even gotten to launch on schedule."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/bose/banner3.jpg')">
-  <div class="banner3text">
-    "Everybody on the team thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we’ve built with them is a huge piece of that."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dylan O’Mahony, Cloud Architecture Manager, Bose</span>
+{{< case-studies/lead >}}
+A household name in high-quality audio equipment, <a href="https://www.bose.com/en_us/index.html">Bose</a> has offered connected products for more than five years, and as that demand grew, the infrastructure had to change to support it. 
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  The team spent time working on choosing tooling to make the experience easier for developers. "Our developers interact with tools provided by our Ops team, and the Ops team run all of their tooling on top of Kubernetes,” says O’Mahony. "We try not to make direct Kubernetes access the only way. In fact, ideally, our developers wouldn’t even need to know that they’re running on Kubernetes.”<br><br>
-  The platform, which also incorporated <a href="https://prometheus.io/">Prometheus</a> monitoring from the beginning, backdoored its way into production in 2017, serving over 3 million connected products from the get-go. "Even though the speakers and the products that we were designing this platform for were still quite a ways away from being launched, we did have some connected speakers on the market,” says O’Mahony. "We basically started to point certain features of those speakers and the apps that go with those speakers to this platform.”<br><br>
-  Today, just one of Bose’s production clusters holds 1,800 namespaces/discrete services and 340 nodes. With about 100 engineers now onboarded, the platform infrastructure is now enabling 30,000 non-production deployments across dozens of microservices per year. In 2018, there were 1250+ production deployments.. It’s a staggering improvement over some of Bose’s previous deployment processes, which supported far fewer deployments and services.
+<p>"We needed to provide a mechanism for developers to rapidly prototype and deploy services all the way to production pretty fast," says Lead Cloud Engineer Josh West. "There were a lot of cloud capabilities we wanted to provide to support our audio equipment and experiences."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/bose/banner4.jpg');width:100%">
-  <div class="banner4text">
-  "The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Josh West, Lead Cloud Engineer, Bose</span>
-  </div>
-</div>
+<p>In 2016, the company decided to start building an IoT platform from scratch. The primary goal: "To be one to two steps ahead of the different product groups so that we are never scrambling to catch up with their scale," says Cloud Architecture Manager Dylan O'Mahony. "If they release a new connected product, we want to be already well ahead of being able to handle whatever scale that they're going to throw at us."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  "We had a brand new service deployed from concept through coding and deployment all the way to production, including hardening, security testing and so forth, in less than two and a half weeks,” says O’Mahony. "Everybody thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we’ve built is a huge piece of that.”<br><br>
-  Many of those technologies—such as <a href="https://www.fluentd.org/">Fluentd</a>, <a href="https://coredns.io/">CoreDNS</a>, <a href="https://www.jaegertracing.io/">Jaeger</a>, and <a href="https://opentracing.io/">OpenTracing</a>—come from the <a href="https://landscape.cncf.io/">CNCF Landscape</a>, which West and O’Mahony have relied upon throughout Bose’s cloud native journey. "The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth,” says West. "This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles.” <br><br>
-  And, he adds, "If it weren’t for Kubernetes and the rest of the CNCF projects being free open source software with such a strong community, we would never have achieved scale, or even gotten to launch on schedule.”<br><br>
-  Another benefit of going cloud native: "We are even attracting much more talent into Bose because we’re so involved with the <a href="http://careers.bose.com">CNCF Landscape</a>,” says West. (Yes, they’re hiring.) "It’s just enabled so many people to do so many great things and really brought Bose into the future of cloud.”
+<p>From the beginning, the team knew it wanted a microservices architecture and platform as a service. After evaluating and prototyping orchestration solutions, including Mesos and Docker Swarm, the team decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> for its platform running on AWS. Kubernetes was still in 1.5, but already the technology could do much of what the team wanted and needed for the present and the future. For West, that meant having storage and network handled. O'Mahony points to Kubernetes' portability in case Bose decides to go multi-cloud.</p>
 
+<p>"Bose is a company that looks out for the long term," says West. "Going with a quick commercial off-the-shelf solution might've worked for that point in time, but it would not have carried us forward, which is what we needed from Kubernetes and the CNCF."</p>
 
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/bose/banner3.jpg"
+  author="Dylan O'Mahony, Cloud Architecture Manager, Bose"
+>}}
+"Everybody on the team thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we've built with them is a huge piece of that."
+{{< /case-studies/quote >}}
 
-<div class="banner5" >
-  <div class="banner5text">
-"We have a lot going on to support many more of our business units at Bose in addition to the consumer electronics division, which we currently do. It’s only because of the cloud native landscape and the tools and the features that are available that we can provide such a fantastic cloud platform for all the developers and divisions that are trying to enable some pretty amazing experiences."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dylan O’Mahony, Cloud Architecture Manager, Bose</span></div>
-</div>
+<p>The team spent time working on choosing tooling to make the experience easier for developers. "Our developers interact with tools provided by our Ops team, and the Ops team run all of their tooling on top of Kubernetes," says O'Mahony. "We try not to make direct Kubernetes access the only way. In fact, ideally, our developers wouldn't even need to know that they're running on Kubernetes."</p>
 
-<div class="fullcol">
-  In the coming year, the team wants to work on service mesh and serverless, as well as expansion around the world. "Getting our latency down by going multi-region is going to be a big focus for us,” says O’Mahony. "In order to make sure that our customers in Japan, Australia, and everywhere else are having a good experience, we want to have points of presence closer to them. It’s never been done at Bose before.”<br><br>
-  That won’t stop them, because the team is all about lofty goals. "We want to get to billions of connected products!” says West. "We have a lot going on to support many more of our business units at Bose in addition to the consumer electronics division, which we currently do. It’s only because of the cloud native landscape and the tools and the features that are available that we can provide such a fantastic cloud platform for all the developers and divisions that are trying to enable some pretty amazing experiences.”<br><br>
-  In fact, given the scale the platform is already supporting, says O’Mahony, "doing anything other than Kubernetes, I think, would be folly at this point.”
+<p>The platform, which also incorporated <a href="https://prometheus.io/">Prometheus</a> monitoring from the beginning, backdoored its way into production in 2017, serving over 3 million connected products from the get-go. "Even though the speakers and the products that we were designing this platform for were still quite a ways away from being launched, we did have some connected speakers on the market," says O'Mahony. "We basically started to point certain features of those speakers and the apps that go with those speakers to this platform."</p>
 
+<p>Today, just one of Bose's production clusters holds 1,800 namespaces/discrete services and 340 nodes. With about 100 engineers now onboarded, the platform infrastructure is now enabling 30,000 non-production deployments across dozens of microservices per year. In 2018, there were 1250+ production deployments.. It's a staggering improvement over some of Bose's previous deployment processes, which supported far fewer deployments and services.</p>
 
-</div>
-</section>
-</body>
-</html>
+{{< case-studies/quote
+  image="/images/case-studies/bose/banner4.jpg"
+  author="Josh West, Lead Cloud Engineer, Bose"
+>}}
+"The CNCF Landscape quickly explains what's going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles."
+{{< /case-studies/quote >}}
+
+<p>"We had a brand new service deployed from concept through coding and deployment all the way to production, including hardening, security testing and so forth, in less than two and a half weeks," says O'Mahony. "Everybody thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we've built is a huge piece of that."</p>
+
+<p>Many of those technologies—such as <a href="https://www.fluentd.org/">Fluentd</a>, <a href="https://coredns.io/">CoreDNS</a>, <a href="https://www.jaegertracing.io/">Jaeger</a>, and <a href="https://opentracing.io/">OpenTracing</a>—come from the <a href="https://landscape.cncf.io/">CNCF Landscape</a>, which West and O'Mahony have relied upon throughout Bose's cloud native journey. "The CNCF Landscape quickly explains what's going on in all the different areas from storage to cloud providers to automation and so forth," says West. "This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles."</p>
+
+<p>And, he adds, "If it weren't for Kubernetes and the rest of the CNCF projects being free open source software with such a strong community, we would never have achieved scale, or even gotten to launch on schedule."</p>
+
+<p>Another benefit of going cloud native: "We are even attracting much more talent into Bose because we're so involved with the <a href="http://careers.bose.com">CNCF Landscape</a>," says West. (Yes, they're hiring.) "It's just enabled so many people to do so many great things and really brought Bose into the future of cloud."</p>
+
+{{< case-studies/quote author="Dylan O'Mahony, Cloud Architecture Manager, Bose" >}}
+"We have a lot going on to support many more of our business units at Bose in addition to the consumer electronics division, which we currently do. It's only because of the cloud native landscape and the tools and the features that are available that we can provide such a fantastic cloud platform for all the developers and divisions that are trying to enable some pretty amazing experiences."
+{{< /case-studies/quote >}}
+
+<p>In the coming year, the team wants to work on service mesh and serverless, as well as expansion around the world. "Getting our latency down by going multi-region is going to be a big focus for us," says O'Mahony. "In order to make sure that our customers in Japan, Australia, and everywhere else are having a good experience, we want to have points of presence closer to them. It's never been done at Bose before."</p>
+
+<p>That won't stop them, because the team is all about lofty goals. "We want to get to billions of connected products!" says West. "We have a lot going on to support many more of our business units at Bose in addition to the consumer electronics division, which we currently do. It's only because of the cloud native landscape and the tools and the features that are available that we can provide such a fantastic cloud platform for all the developers and divisions that are trying to enable some pretty amazing experiences."</p>
+
+<p>In fact, given the scale the platform is already supporting, says O'Mahony, "doing anything other than Kubernetes, I think, would be folly at this point."</p>
diff --git a/content/en/case-studies/box/index.html b/content/en/case-studies/box/index.html
index bead8eb01a..058ff7f9a2 100644
--- a/content/en/case-studies/box/index.html
+++ b/content/en/case-studies/box/index.html
@@ -2,113 +2,99 @@
 title: Box Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_box.css
 video: https://www.youtube.com/embed/of45hYbkIZs?autoplay=1
 quote: >
   Kubernetes has the opportunity to be the new cloud platform. The amount of innovation that's going to come from being able to standardize on Kubernetes as a platform is incredibly exciting - more exciting than anything I've seen in the last 10 years of working on the cloud.
 
+new_case_study_styles: true
+heading_background: /images/case-studies/box/banner1.jpg
+heading_title_logo: /images/box_logo.png
+subheading: >
+  An Early Adopter Envisions a New Cloud Platform
+case_study_details:
+  - Company: Box
+  - Location: Redwood City, California
+  - Industry: Technology
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/box_logo.png" width="10%" style="margin-bottom:-6px"><br>
-    <div class="subhead">An Early Adopter Envisions
-      a New Cloud Platform</div>
-  </h1>
-</div>
+<h2>Challenge</h2>
 
+<p>Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company's own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It's been a huge challenge because of different clouds, especially bare metal, have very different interfaces."</p>
 
-<div class="details">
-    Company &nbsp;<b>Box</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Redwood City, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Technology</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box's developers to "target a universal set of concepts that are portable across all clouds."</p>
 
-<section class="section1">
+<h2>Impact</h2>
 
-<div class="cols">
-  <div class="col1">
+<p>"Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Today, a new microservice takes less than five days to deploy. And we're working on getting it to an hour."</p>
 
-      <h2>Challenge</h2>
-        Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company’s own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It’s been a huge challenge because of different clouds, especially bare metal, have very different interfaces."
-        <br>
-  </div>
+{{< case-studies/quote author="SAM GHOUDS, CO-FOUNDER AND SERVICES ARCHITECT OF BOX" >}}
+"We looked at a lot of different options, but Kubernetes really stood out....the fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as&nbsp;well."
+{{< /case-studies/quote >}}
 
-  <div class="col2">
-    <h2>Solution</h2>
-      Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box’s developers to "target a universal set of concepts that are portable across all clouds."<br><br>
+{{< case-studies/lead >}}
+In the summer of 2014, Box was feeling the pain of a decade's worth of hardware and software infrastructure that wasn't keeping up with the company's needs.
+{{< /case-studies/lead >}}
 
-    <h2>Impact</h2>
-      "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Today, a new microservice takes less than five days to deploy. And we’re working on getting it to an hour."
-  </div>
-</div>
+<p>A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It's been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."</p>
 
-</section>
+<p>Box's cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.</p>
 
-<div class="banner2">
-  <div class="banner2text">
-      "We looked at a lot of different options, but Kubernetes really stood out....the fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as&nbsp;well."<br><br><span style="font-size:15px;letter-spacing:0.08em">- SAM GHOUDS, CO-FOUNDER AND SERVICES ARCHITECT OF BOX</span>
-  </div>
-</div>
+<p>At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google's internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."</p>
 
-<section class="section2">
+<p>Another plus: Ghods liked that <a href="https://kubernetes.io/">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."</p>
 
-  <div class="fullcol">
-      <h2>In the summer of 2014, Box was feeling the pain of a decade’s worth of hardware and software infrastructure that wasn’t keeping up with the company’s needs.</h2>
+<p>Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods's team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn't fail synchronous incoming requests from customers."</p>
 
-      A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."<br><br>
-      Box’s cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.<br><br>
-      At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google’s internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."<br><br>
-      Another plus: Ghods liked that <a href="https://kubernetes.io/">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."<br><br>
-      Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods’s team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn’t fail synchronous incoming requests from customers."
+{{< case-studies/quote image="/images/case-studies/box/banner3.jpg">}}
+"As we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we [can have Kubernetes help] run our workload across many different environments and many different cloud infrastructure providers."
+{{< /case-studies/quote >}}
 
-  </div>
-</section>
+<p>The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that's ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that's going to be expanding a lot over the next 12 months, probably too many hundreds if not thousands."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "As we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we [can have Kubernetes help] run our workload across many different environments and many different cloud infrastructure providers."
-  </div>
-</div>
+<p>While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods&nbsp;notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</p>
 
-<section class="section3">
-  <div class="fullcol">
-    The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that’s ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that’s going to be expanding a lot over the next 12 months, probably too many hundreds if not thousands."<br><br>
-    While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods&nbsp;notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
-    <br><br><div class="quote">"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</div><br>
-    Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we’d upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."<br><br>
-    In any case, Box didn’t have to make too many modifications to Kubernetes for it to work for the company. "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing (and often legacy) infrastructure," says Ghods, "such as upgrading our base operating system from RHEL6 to RHEL7 or integrating it into <a href="https://www.nagios.org/">Nagios</a>, our monitoring infrastructure. But overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."<br><br>
-    Perhaps the bigger challenge for Box was a cultural one. "Kubernetes, and cloud native in general, represents a pretty big paradigm shift, and it’s not very incremental," Ghods says. "We’re essentially making this pitch that Kubernetes is going to solve everything because it does things the right way and everything is just suddenly better. But it’s important to keep in mind that it’s not nearly as proven as many other solutions out there. You can’t say how long this or that company took to do it because there just aren’t that many yet. Our team had to really fight for resources because our project was a bit of a moonshot."
-  </div>
-</section>
+{{< case-studies/lead >}}
+"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
+{{< /case-studies/lead >}}
 
-  <div class="banner4">
-    <div class="banner4text">
-    "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing [and often legacy] infrastructure....overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."
-    </div>
-  </div>
+<p>Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we'd upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."</p>
 
-<section class="section4">
-  <div class="fullcol">
-    Having learned from experience, Ghods offers these two pieces of advice for companies going through similar challenges:
-    <h2>1. Deliver early and often.</h2> Service discovery was a huge problem for Box, and the team had to decide whether to build an interim solution or wait for Kubernetes to natively satisfy Box’s unique requirements. After much debate, "we just started focusing on delivering something that works, and then dealing with potentially migrating to a more native solution later," Ghods says. "The above-all-else target for the team should always be to serve real production use cases on the infrastructure, no matter how trivial. This helps keep the momentum going both for the team itself and for the organizational perception of the project." </br></br>
-    <h2>2. Keep an open mind about what your company has to abstract away from developers and what it&nbsp;doesn’t.</h2> Early on, the team built an abstraction on top of Docker files to help ensure that images had the right security updates.
-    This turned out to be superfluous work, since container images are considered immutable and you can easily scan them post-build to ensure they do not contain vulnerabilities. Because managing infrastructure through containerization is such a discontinuous leap, it’s better to start by interacting directly with the native tools and learning their unique advantages and caveats. An abstraction should be built only after a practical need for it arises.</br></br>
-    In the end, the impact has been powerful. "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Now a new microservice takes less than five days to deploy. And we’re working on getting it to an hour. Granted, much of that six months was due to how broken our systems were, but bare metal is intrinsically a difficult platform to support unless you have a system like Kubernetes to help manage&nbsp;it."</br></br>
-    By Ghods’s estimate, Box is still several years away from his goal of being a 90-plus percent Kubernetes shop. "We’re very far along on having a mission-critical, stable Kubernetes deployment that provides a lot of value," he says. "Right now about five percent of all of our compute runs on Kubernetes, and I think in the next six months we’ll likely be between 20 to 50 percent. We’re working hard on enabling all stateless service use cases, and shift our focus to stateful services after&nbsp;that."
-  </div>
-</section>
+<p>In any case, Box didn't have to make too many modifications to Kubernetes for it to work for the company. "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing (and often legacy) infrastructure," says Ghods, "such as upgrading our base operating system from RHEL6 to RHEL7 or integrating it into <a href="https://www.nagios.org/">Nagios</a>, our monitoring infrastructure. But overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we've been running it very successfully on our bare metal infrastructure."</p>
 
-  <div class="banner5">
-    <div class="banner5text">
-    "Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. '...because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure.'"
-    </div>
-  </div>
+<p>Perhaps the bigger challenge for Box was a cultural one. "Kubernetes, and cloud native in general, represents a pretty big paradigm shift, and it's not very incremental," Ghods says. "We're essentially making this pitch that Kubernetes is going to solve everything because it does things the right way and everything is just suddenly better. But it's important to keep in mind that it's not nearly as proven as many other solutions out there. You can't say how long this or that company took to do it because there just aren't that many yet. Our team had to really fight for resources because our project was a bit of a moonshot."</p>
 
-<section class="section5">
-  <div class="fullcol">
-    In fact, that’s what he envisions across the industry: Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. Kubernetes provides an API consistent across different cloud platforms including bare metal, and "I don’t think people have seen the full potential of what’s possible when you can program against one single interface," he says. "The same way <a href="https://aws.amazon.com/">AWS</a> changed infrastructure so that you don’t have to think about servers or cabinets or networking equipment anymore, Kubernetes enables you to focus exclusively on the containers that you’re running, which is pretty exciting. That’s the vision."</br></br>
-    Ghods points to projects that are already in development or recently released for Kubernetes as a cloud platform: cluster federation, the Dashboard UI, and <a href="https://coreos.com/">CoreOS</a>’s etcd operator. "I honestly believe it’s the most exciting thing I’ve seen in cloud infrastructure," he says, "because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</br></br>
-    Box, with its early decision to use bare metal, embarked on its Kubernetes journey out of necessity. But Ghods says that even if companies don’t have to be agnostic about cloud providers today, Kubernetes may soon become the industry standard, as more and more tooling and extensions are built around the API.</br></br>
-    "The same way it doesn’t make sense to deviate from Linux because it’s such a standard," Ghods says, "I think Kubernetes is going down the same path. It is still early days—the documentation still needs work and the user experience for writing and publishing specs to the Kubernetes clusters is still rough. When you’re on the cutting edge you can expect to bleed a little. But the bottom line is, this is where the industry is going. Three to five years from now it’s really going to be shocking if you run your infrastructure any other way."
-  </div>
-</section>
+{{< case-studies/quote image="/images/case-studies/box/banner4.jpg">}}
+"The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing [and often legacy] infrastructure....overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we've been running it very successfully on our bare metal infrastructure."
+{{< /case-studies/quote >}}
+
+<p>Having learned from experience, Ghods offers these two pieces of advice for companies going through similar challenges:</p>
+
+{{< case-studies/lead >}}
+1. Deliver early and often.
+{{< /case-studies/lead >}}
+
+<p>Service discovery was a huge problem for Box, and the team had to decide whether to build an interim solution or wait for Kubernetes to natively satisfy Box's unique requirements. After much debate, "we just started focusing on delivering something that works, and then dealing with potentially migrating to a more native solution later," Ghods says. "The above-all-else target for the team should always be to serve real production use cases on the infrastructure, no matter how trivial. This helps keep the momentum going both for the team itself and for the organizational perception of the project."</p>
+
+{{< case-studies/lead >}}
+2. Keep an open mind about what your company has to abstract away from developers and what it doesn't.
+{{< /case-studies/lead >}}
+
+<p>Early on, the team built an abstraction on top of Docker files to help ensure that images had the right security updates. This turned out to be superfluous work, since container images are considered immutable and you can easily scan them post-build to ensure they do not contain vulnerabilities. Because managing infrastructure through containerization is such a discontinuous leap, it's better to start by interacting directly with the native tools and learning their unique advantages and caveats. An abstraction should be built only after a practical need for it arises.</p>
+
+<p>In the end, the impact has been powerful. "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Now a new microservice takes less than five days to deploy. And we're working on getting it to an hour. Granted, much of that six months was due to how broken our systems were, but bare metal is intrinsically a difficult platform to support unless you have a system like Kubernetes to help manage it."</p>
+
+<p>By Ghods's estimate, Box is still several years away from his goal of being a 90-plus percent Kubernetes shop. "We're very far along on having a mission-critical, stable Kubernetes deployment that provides a lot of value," he says. "Right now about five percent of all of our compute runs on Kubernetes, and I think in the next six months we'll likely be between 20 to 50 percent. We're working hard on enabling all stateless service use cases, and shift our focus to stateful services after that."</p>
+
+{{< case-studies/quote >}}
+"Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. '...because it's a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure.'"
+{{< /case-studies/quote >}}
+
+<p>In fact, that's what he envisions across the industry: Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. Kubernetes provides an API consistent across different cloud platforms including bare metal, and "I don't think people have seen the full potential of what's possible when you can program against one single interface," he says. "The same way <a href="https://aws.amazon.com/">AWS</a> changed infrastructure so that you don't have to think about servers or cabinets or networking equipment anymore, Kubernetes enables you to focus exclusively on the containers that you're running, which is pretty exciting. That's the vision."</p>
+
+<p>Ghods points to projects that are already in development or recently released for Kubernetes as a cloud platform: cluster federation, the Dashboard UI, and <a href="https://coreos.com/">CoreOS</a>'s etcd operator. "I honestly believe it's the most exciting thing I've seen in cloud infrastructure," he says, "because it's a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</p>
+
+<p>Box, with its early decision to use bare metal, embarked on its Kubernetes journey out of necessity. But Ghods says that even if companies don't have to be agnostic about cloud providers today, Kubernetes may soon become the industry standard, as more and more tooling and extensions are built around the API.</p>
+
+<p>"The same way it doesn't make sense to deviate from Linux because it's such a standard," Ghods says, "I think Kubernetes is going down the same path. It is still early days—the documentation still needs work and the user experience for writing and publishing specs to the Kubernetes clusters is still rough. When you're on the cutting edge you can expect to bleed a little. But the bottom line is, this is where the industry is going. Three to five years from now it's really going to be shocking if you run your infrastructure any other way."</p>
diff --git a/content/en/case-studies/buffer/index.html b/content/en/case-studies/buffer/index.html
index 333db6a74e..bcf0896445 100644
--- a/content/en/case-studies/buffer/index.html
+++ b/content/en/case-studies/buffer/index.html
@@ -1,112 +1,83 @@
 ---
 title: Buffer Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_buffer.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/buffer/banner3.jpg
+heading_title_logo: /images/buffer.png
+subheading: >
+  Making Deployments Easy for a Small, Distributed Team
+case_study_details:
+  - Company: Buffer
+  - Location: Around the World
+  - Industry: Social Media Technology
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/buffer.png" width="18%" style="margin-bottom:-5px;margin-left:10px;"><br>
-  <div class="subhead">Making Deployments Easy for a Small, Distributed Team</div>
-</h1>
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company&nbsp;<b>Buffer</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Around the World</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Social Media Technology</b>
-</div>
+<p>With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary."</p>
 
-<hr>
+<h2>Solution</h2>
 
-<section class="section1">
-  <div class="cols">
-    <div class="col1">
+<p>Embracing containerization, Buffer moved its infrastructure from Amazon Web Services' Elastic Beanstalk to Docker on AWS, orchestrated with Kubernetes.</p>
 
-    <h2>Challenge</h2>
-      With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as&nbsp;necessary."
-</div>
-
-<div class="col2">
-  <h2>Solution</h2>
-      Embracing containerization, Buffer moved its infrastructure from Amazon Web Services’ Elastic Beanstalk to Docker on AWS, orchestrated with&nbsp;Kubernetes.
-      <br>
-      <br>
 <h2>Impact</h2>
-      The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it’s going to work has shortened things up a lot. Our feedback cycles are a lot faster now&nbsp;too."
-    </div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it’s there in the next release or it’s coming in the next few months."<br><br><span style="font-size:16px;letter-spacing:2px;">- DAN FARRELLY, BUFFER ARCHITECT</span>
-  </div>
-</div>
+<p>The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it's going to work has shortened things up a lot. Our feedback cycles are a lot faster now too."</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>Dan Farrelly uses a carpentry analogy to explain the problem his company, <a href="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.</h2>
+{{< case-studies/quote author="DAN FARRELLY, BUFFER ARCHITECT" >}}
+"It's amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it's there in the next release or it's coming in the next few months."
+{{< /case-studies/quote >}}
 
-    "If you’re building a table by yourself, it’s fine," the company’s architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you’re sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.<br><br>
-    Since around 2012, Buffer had already been using <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <a href="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <a href="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn’t spend too much time on it. If things were getting a little bit slow, we’d maybe use a faster server or just scale up one instance, and it would be good enough. We’d move on."<br><br>
-    But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer’s then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company’s team was already successfully using <a href="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn’t see real user traffic. They wanted to go further with Docker, and the next step was looking at options for&nbsp;orchestration.
-</div>
-</section>
+{{< case-studies/lead >}}
+Dan Farrelly uses a carpentry analogy to explain the problem his company, <a href="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.
+{{< /case-studies/lead >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it&nbsp;[Kubernetes]."
-  </div>
-</div>
+<p>"If you're building a table by yourself, it's fine," the company's architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you're sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.</p>
 
-<section class="section3">
-<div class="fullcol">
-    First they considered <a href="https://mesosphere.com">Mesosphere</a>, <a href="https://dcos.io">DC/OS</a> and <a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn’t need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes’ controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."<br><br>
-    And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."<br><br>
-    Above all, it provided a powerful solution for one of the company’s most distinguishing characteristics: their remote team that’s spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It’s been really cool to see people moving much faster."
-    <br><br>
-    With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies&nbsp;might."
-</div>
-</section>
+<p>Since around 2012, Buffer had already been using <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <a href="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <a href="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn't spend too much time on it. If things were getting a little bit slow, we'd maybe use a faster server or just scale up one instance, and it would be good enough. We'd move on."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the&nbsp;door."
-  </div>
-</div>
+<p>But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer's then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company's team was already successfully using <a href="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn't see real user traffic. They wanted to go further with Docker, and the next step was looking at options for orchestration.</p>
 
-<section class="section4">
-<div class="fullcol">
-    To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <a href="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <a href="https://slack.com">Slack</a> command, ‘/deploy,’ and it goes out instantly. They don’t need to wait on these slow turnaround times. They don’t even know where it’s running; it doesn’t matter."
-    <br><br>
-    One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.
-    <br><br>
-    To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door."
-    <br><br>
-    Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."
-    <br><br>
-    Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing&nbsp;risk."
+{{< case-studies/quote image="/images/case-studies/buffer/banner1.jpg" >}}
+And all the things Kubernetes did well suited Buffer's needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>First they considered <a href="https://mesosphere.com">Mesosphere</a>, <a href="https://dcos.io">DC/OS</a> and <a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn't need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes' controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this&nbsp;way."
-  </div>
-</div>
+<p>And all the things Kubernetes did well suited Buffer's needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."</p>
 
-<section class="section5">
-<div class="fullcol">
-    By October 2016, 54 percent of Buffer’s traffic was going through their Kubernetes cluster. "There’s a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."
-    <br><br>
-    The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they’ve pulled out of their old infrastructure, plus the new services they’re developing in Kubernetes, on another cluster. "I want to bring all the benefits that we’ve seen on our early services to everyone on the team," says Farrelly.
-    <br><br>
-    <h2>For Buffer’s engineers, it’s an exciting process. "Every time we’re deploying a new service, we need to figure out: OK, what’s the architecture? How do these services communicate? What’s the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It’s enabling us to experiment as we’re learning how to design a service-oriented architecture. Before, we just wouldn’t have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it."
-    </h2>
-    Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It’s cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We’re very deep in Amazon but it’s nice to know we could move away if we need to."
-    <br><br>
-    At this point, the team at Buffer can’t imagine running their infrastructure any other way—and they’re happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this&nbsp;way."
-  <br><br>
-</div>
-</section>
+<p>Above all, it provided a powerful solution for one of the company's most distinguishing characteristics: their remote team that's spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It's been really cool to see people moving much faster."</p>
+
+<p>With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies might."</p>
+
+{{< case-studies/quote image="/images/case-studies/buffer/banner4.jpg" >}}
+"In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it's out the door."
+{{< /case-studies/quote >}}
+
+<p>To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <a href="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <a href="https://slack.com">Slack</a> command, '/deploy,' and it goes out instantly. They don't need to wait on these slow turnaround times. They don't even know where it's running; it doesn't matter."</p>
+
+<p>One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.</p>
+
+<p>To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it's out the door."</p>
+
+<p>Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."</p>
+
+<p>Another thing they weren't able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of 'fingers crossed.' And this is something that gets run 800,000 times a day, the core of our business. If it doesn't work, our business doesn't work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn't working. This has leveled up our ability to deploy and roll out new changes quickly while reducing risk."</p>
+
+{{< case-studies/quote >}}
+"If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We're a relatively small team that's actually running Kubernetes, and we've never run anything like it before. So it's more approachable than you might think. That's the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."
+{{< /case-studies/quote >}}
+
+<p>By October 2016, 54 percent of Buffer's traffic was going through their Kubernetes cluster. "There's a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."</p>
+
+<p>The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they've pulled out of their old infrastructure, plus the new services they're developing in Kubernetes, on another cluster. "I want to bring all the benefits that we've seen on our early services to everyone on the team," says Farrelly.</p>
+
+{{< case-studies/lead >}}
+For Buffer's engineers, it's an exciting process. "Every time we're deploying a new service, we need to figure out: OK, what's the architecture? How do these services communicate? What's the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It's enabling us to experiment as we're learning how to design a service-oriented architecture. Before, we just wouldn't have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it."
+{{< /case-studies/lead >}}
+
+<p>Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It's cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We're very deep in Amazon but it's nice to know we could move away if we need to."</p>
+
+<p>At this point, the team at Buffer can't imagine running their infrastructure any other way—and they're happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We're a relatively small team that's actually running Kubernetes, and we've never run anything like it before. So it's more approachable than you might think. That's the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."</p>
diff --git a/content/en/case-studies/capital-one/index.html b/content/en/case-studies/capital-one/index.html
index f95fb2acc7..22e7322ea0 100644
--- a/content/en/case-studies/capital-one/index.html
+++ b/content/en/case-studies/capital-one/index.html
@@ -2,95 +2,61 @@
 title: Capital One Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/capitalone/banner1.jpg
+heading_title_logo: /images/capitalone-logo.png
+subheading: >
+  Supporting Fast Decisioning Applications with Kubernetes
+case_study_details:
+  - Company: Capital One
+  - Location: McLean, Virginia
+  - Industry: Retail banking
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/capitalone/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/capitalone-logo.png" style="margin-bottom:-2%" class="header_logo"><br> <div class="subhead">Supporting Fast Decisioning Applications with Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>The team set out to build a provisioning platform for <a href="https://www.capitalone.com/">Capital One</a> applications deployed on AWS that use streaming, big-data decisioning, and machine learning. One of these applications handles millions of transactions a day; some deal with critical functions like fraud detection and credit decisioning. The key considerations: resilience and speed—as well as full rehydration of the cluster from base AMIs.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Capital One</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>McLean, Virginia</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Retail banking</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    The team set out to build a provisioning platform for <a href="https://www.capitalone.com/">Capital One</a> applications deployed on AWS that use streaming, big-data decisioning, and machine learning. One of these applications handles millions of transactions a day; some deal with critical functions like fraud detection and credit decisioning. The key considerations: resilience and speed—as well as full rehydration of the cluster from base AMIs.
-
-<br>
-    <h2>Solution</h2>
-    The decision to run <a href="https://kubernetes.io/">Kubernetes</a> "is very strategic for us," says John Swift, Senior Director Software Engineering. "We use Kubernetes as a substrate or an operating system, if you will. There’s a degree of affinity in our product development."
-</div>
-
-<div class="col2">
+<p>The decision to run <a href="https://kubernetes.io/">Kubernetes</a> "is very strategic for us," says John Swift, Senior Director Software Engineering. "We use Kubernetes as a substrate or an operating system, if you will. There's a degree of affinity in our product development."</p>
 
 <h2>Impact</h2>
-  "Kubernetes is a significant productivity multiplier," says Lead Software Engineer Keith Gasser, adding that to run the platform without Kubernetes would "easily see our costs triple, quadruple what they are now for the amount of pure AWS expense." Time to market has been improved as well: "Now, a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer." Deployments increased by several orders of magnitude. Plus, the rehydration/cluster-rebuild process, which took a significant part of a day to do manually, now takes a couple hours with Kubernetes automation and declarative configuration.
+
+<p>"Kubernetes is a significant productivity multiplier," says Lead Software Engineer Keith Gasser, adding that to run the platform without Kubernetes would "easily see our costs triple, quadruple what they are now for the amount of pure AWS expense." Time to market has been improved as well: "Now, a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer." Deployments increased by several orders of magnitude. Plus, the rehydration/cluster-rebuild process, which took a significant part of a day to do manually, now takes a couple hours with Kubernetes automation and declarative configuration.</p>
+
+{{< case-studies/quote author="Jamil Jadallah, Scrum Master" >}}
+<iframe width="560" height="315" src="https://www.youtube.com/embed/UHVW01ksg-s" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<br>
+"With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."
+{{< /case-studies/quote >}}
+
+<p>As a top 10 U.S. retail bank, Capital One has applications that handle millions of transactions a day. Big-data decisioning—for fraud detection, credit approvals and beyond—is core to the business. To support the teams that build applications with those functions for the bank, the cloud team led by Senior Director Software Engineering John Swift embraced Kubernetes for its provisioning platform. "Kubernetes and its entire ecosystem are very strategic for us," says Swift. "We use Kubernetes as a substrate or an operating system, if you will. There's a degree of affinity in our product development."</p>
+
+<p>Almost two years ago, the team embarked on this journey by first working with Docker. Then came Kubernetes. "We wanted to put streaming services into Kubernetes as one feature of the workloads for fast decisioning, and to be able to do batch alongside it," says Lead Software Engineer Keith Gasser. "Once the data is streamed and batched, there are so many tool sets in <a href="https://flink.apache.org/">Flink</a> that we use for decisioning. We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."</p>
+
+{{< case-studies/quote image="/images/case-studies/capitalone/banner3.jpg" >}}
+"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
+{{< /case-studies/quote >}}
+
+<p>In this first year, the impact has already been great. "Time to market is really huge for us," says Gasser. "Especially with fraud, you have to be very nimble in the way you respond to threats in the marketplace—being able to add and push new rules, detect new patterns of behavior, detect anomalies in account and transaction flows." With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."</p>
+
+<p>Teams now have the tools to be autonomous in their deployments, and as a result, deployments have increased by two orders of magnitude. "And that was with just seven dedicated resources, without needing a whole group sitting there watching everything," says Scrum Master Jamil Jadallah. "That's a huge cost savings. With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."</p>
+
+{{< case-studies/quote image="/images/case-studies/capitalone/banner4.jpg" >}}
+With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
+{{< /case-studies/quote >}}
+
+<p>Kubernetes has also been a great time-saver for Capital One's required period "rehydration" of clusters from base AMIs. To minimize the attack vulnerability profile for applications in the cloud, "Our entire clusters get rebuilt from scratch periodically, with new fresh instances and virtual server images that are patched with the latest and greatest security patches," says Gasser. This process used to take the better part of a day, and personnel, to do manually. It's now a quick Kubernetes job.</p>
+
+<p>Savings extend to both capital and operating expenses. "It takes very little to get into Kubernetes because it's all open source," Gasser points out. "We went the DIY route for building our cluster, and we definitely like the flexibility of being able to embrace the latest from the community immediately without waiting for a downstream company to do it. There's capex related to those licenses that we don't have to pay for. Moreover, there's capex savings for us from some of the proprietary software that we get to sunset in our particular domain. So that goes onto our ledger in a positive way as well." (Some of those open source technologies include Prometheus, Fluentd, gRPC, Istio, CNI, and Envoy.)</p>
+
+{{< case-studies/quote >}}
+"If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn't account for personnel to deploy and maintain all the additional infrastructure."
+{{< /case-studies/quote >}}
 
 
-</div>
+<p>And on the opex side, Gasser says, the savings are high. "We run dozens of services, we have scores of pods, many daemon sets, and since we're data-driven, we take advantage of EBS-backed volume claims for all of our stateful services. If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn't account for personnel to deploy and maintain all the additional infrastructure."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-<iframe width="560" height="315" src="https://www.youtube.com/embed/UHVW01ksg-s" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe><br><br>
-"With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before." <span style="font-size:16px;text-transform:uppercase">— Jamil Jadallah, Scrum Master</span>
-</div>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2></h2>
-  As a top 10 U.S. retail bank, Capital One has applications that handle millions of transactions a day. Big-data decisioning—for fraud detection, credit approvals and beyond—is core to the business. To support the teams that build applications with those functions for the bank, the cloud team led by Senior Director Software Engineering John Swift embraced Kubernetes for its provisioning platform. "Kubernetes and its entire ecosystem are very strategic for us," says Swift. "We use Kubernetes as a substrate or an operating system, if you will. There’s a degree of affinity in our product development."<br><br>
-  Almost two years ago, the team embarked on this journey by first working with Docker. Then came Kubernetes. "We wanted to put streaming services into Kubernetes as one feature of the workloads for fast decisioning, and to be able to do batch alongside it," says Lead Software Engineer Keith Gasser. "Once the data is streamed and batched, there are so many tool sets in <a href="https://flink.apache.org/">Flink</a> that we use for decisioning. We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
-
-
-
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/capitalone/banner3.jpg')">
-  <div class="banner3text">
-    "We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
-
-
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  In this first year, the impact has already been great. "Time to market is really huge for us," says Gasser. "Especially with fraud, you have to be very nimble in the way you respond to threats in the marketplace—being able to add and push new rules, detect new patterns of behavior, detect anomalies in account and transaction flows." With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."<br><br>
-  Teams now have the tools to be autonomous in their deployments, and as a result, deployments have increased by two orders of magnitude. "And that was with just seven dedicated resources, without needing a whole group sitting there watching everything," says Scrum Master Jamil Jadallah. "That’s a huge cost savings. With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."
-
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/capitalone/banner4.jpg')">
-  <div class="banner4text">
-    With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
-  </div>
-</div>
-
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-    Kubernetes has also been a great time-saver for Capital One’s required period "rehydration" of clusters from base AMIs. To minimize the attack vulnerability profile for applications in the cloud, "Our entire clusters get rebuilt from scratch periodically, with new fresh instances and virtual server images that are patched with the latest and greatest security patches," says Gasser. This process used to take the better part of a day, and personnel, to do manually. It’s now a quick Kubernetes job.<br><br>
-  Savings extend to both capital and operating expenses. "It takes very little to get into Kubernetes because it’s all open source," Gasser points out. "We went the DIY route for building our cluster, and we definitely like the flexibility of being able to embrace the latest from the community immediately without waiting for a downstream company to do it. There’s capex related to those licenses that we don’t have to pay for. Moreover, there’s capex savings for us from some of the proprietary software that we get to sunset in our particular domain. So that goes onto our ledger in a positive way as well." (Some of those open source technologies include Prometheus, Fluentd, gRPC, Istio, CNI, and Envoy.)
-
-</div>
-
-<div class="banner5">
-  <div class="banner5text">
-   "If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn’t account for personnel to deploy and maintain all the additional infrastructure."
-  </div>
-</div>
-
-<div class="fullcol">
-  And on the opex side, Gasser says, the savings are high. "We run dozens of services, we have scores of pods, many daemon sets, and since we’re data-driven, we take advantage of EBS-backed volume claims for all of our stateful services. If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn’t account for personnel to deploy and maintain all the additional infrastructure."<br><br>
-  The team is confident that the benefits will continue to multiply—without a steep learning curve for the engineers being exposed to the new technology. "As we onboard additional tenants in this ecosystem, I think the need for folks to understand Kubernetes may not necessarily go up. In fact, I think it goes down, and that’s good," says Gasser. "Because that really demonstrates the scalability of the technology. You start to reap the benefits, and they can concentrate on all the features they need to build for great decisioning in the business— fraud decisions, credit decisions—and not have to worry about, ‘Is my AWS server broken? Is my pod not running?’"
-</div>
-
-</section>
+<p>The team is confident that the benefits will continue to multiply—without a steep learning curve for the engineers being exposed to the new technology. "As we onboard additional tenants in this ecosystem, I think the need for folks to understand Kubernetes may not necessarily go up. In fact, I think it goes down, and that's good," says Gasser. "Because that really demonstrates the scalability of the technology. You start to reap the benefits, and they can concentrate on all the features they need to build for great decisioning in the business— fraud decisions, credit decisions—and not have to worry about, 'Is my AWS server broken? Is my pod not running?'"</p>
diff --git a/content/en/case-studies/cern/index.html b/content/en/case-studies/cern/index.html
index 48e965d7fb..461aa8fb84 100644
--- a/content/en/case-studies/cern/index.html
+++ b/content/en/case-studies/cern/index.html
@@ -3,91 +3,79 @@ title: CERN Case Study
 linkTitle: cern
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: cern_featured_logo.png
+
+new_case_study_styles: true
+heading_background: /images/case-studies/cern/banner1.jpg
+heading_title_text: CERN
+subheading: >
+  CERN: Processing Petabytes of Data More Efficiently with Kubernetes
+case_study_details:
+  - Company: CERN
+  - Location: Geneva, Switzerland
+  - Industry: Particle physics research
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/cern/banner1.jpg')">
-  <h1> CASE STUDY: CERN<br> <div class="subhead" style="margin-top:1%">CERN: Processing Petabytes of Data More Efficiently with Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>At CERN, the European Organization for Nuclear Research, physicists conduct experiments to learn about fundamental science. In its particle accelerators, "we accelerate protons to very high energy, close to the speed of light, and we make the two beams of protons collide," says CERN Software Engineer Ricardo Rocha. "The end result is a lot of data that we have to process." CERN currently stores 330 petabytes of data in its data centers, and an upgrade of its accelerators expected in the next few years will drive that number up by 10x. Additionally, the organization experiences extreme peaks in its workloads during periods prior to big conferences, and needs its infrastructure to scale to those peaks. "We want to have a more hybrid infrastructure, where we have our on premise infrastructure but can make use of public clouds temporarily when these peaks come up," says Rocha. "We've been looking to new technologies that can help improve our efficiency in our infrastructure so that we can dedicate more of our resources to the actual processing of the data."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>CERN</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Geneva, Switzerland
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Particle physics research</b>
-</div>
+<p>CERN's technology team embraced containerization and cloud native practices, choosing Kubernetes for orchestration, Helm for deployment, Prometheus for monitoring, and CoreDNS for DNS resolution inside the clusters. Kubernetes federation has allowed the organization to run some production workloads both on premise and in public clouds.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    At CERN, the European Organization for Nuclear Research, physicists conduct experiments to learn about fundamental science. In its particle accelerators, "we accelerate protons to very high energy, close to the speed of light, and we make the two beams of protons collide," says CERN Software Engineer Ricardo Rocha. "The end result is a lot of data that we have to process." CERN currently stores 330 petabytes of data in its data centers, and an upgrade of its accelerators expected in the next few years will drive that number up by 10x. Additionally, the organization experiences extreme peaks in its workloads during periods prior to big conferences, and needs its infrastructure to scale to those peaks. "We want to have a more hybrid infrastructure, where we have our on premise infrastructure but can make use of public clouds temporarily when these peaks come up," says Rocha. "We’ve been looking to new technologies that can help improve our efficiency in our infrastructure so that we can dedicate more of our resources to the actual processing of the data."
-<br><br>
-    <h2>Solution</h2>
-    CERN’s technology team embraced containerization and cloud native practices, choosing Kubernetes for orchestration, Helm for deployment, Prometheus for monitoring, and CoreDNS for DNS resolution inside the clusters. Kubernetes federation has allowed the organization to run some production workloads both on premise and in public clouds.
-<br><br>
 <h2>Impact</h2>
-  "Kubernetes gives us the full automation of the application," says Rocha. "It comes with built-in monitoring and logging for all the applications and the workloads that deploy in Kubernetes. This is a massive simplification of our current deployments." The time to deploy a new cluster for a complex distributed storage system has gone from more than 3 hours to less than 15 minutes. Adding new nodes to a cluster used to take more than an hour; now it takes less than 2 minutes. The time it takes to autoscale replicas for system components has decreased from more than an hour to less than 2 minutes. Initially, virtualization gave 20% overhead, but with tuning this was reduced to ~5%. Moving to Kubernetes on bare metal would get this to 0%. Not having to host virtual machines is expected to also get 10% of memory capacity back.
 
-</div>
+<p>"Kubernetes gives us the full automation of the application," says Rocha. "It comes with built-in monitoring and logging for all the applications and the workloads that deploy in Kubernetes. This is a massive simplification of our current deployments." The time to deploy a new cluster for a complex distributed storage system has gone from more than 3 hours to less than 15 minutes. Adding new nodes to a cluster used to take more than an hour; now it takes less than 2 minutes. The time it takes to autoscale replicas for system components has decreased from more than an hour to less than 2 minutes. Initially, virtualization gave 20% overhead, but with tuning this was reduced to ~5%. Moving to Kubernetes on bare metal would get this to 0%. Not having to host virtual machines is expected to also get 10% of memory capacity back.</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "Kubernetes is something we can relate to very much because it’s naturally distributed. What it gives us is a uniform API across heterogeneous resources to define our workloads. This is something we struggled with a lot in the past when we want to expand our resources outside our infrastructure."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Ricardo Rocha, Software Engineer, CERN</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>With a mission of researching fundamental science, and a stable of extremely large machines, the European Organization for Nuclear Research (CERN) operates at what can only be described as hyperscale.  </h2>
-  Experiments are conducted in particle accelerators, the biggest of which is 27 kilometers in circumference. "We accelerate protons to very high energy, to close to the speed of light, and we make the two beams of protons collide in well-defined places," says CERN Software Engineer Ricardo Rocha. "We build experiments around these places where we do the collisions. The end result is a lot of data that we have to process."<br><br>
-  And he does mean a lot: CERN currently stores and processes 330 petabytes of data—gathered from 4,300 projects and 3,300 users—using 10,000 hypervisors and 320,000 cores in its data centers. <br><br>
-  Over the years, the CERN technology department has built a large computing infrastructure, based on OpenStack private clouds, to help the organization’s physicists analyze and treat all this data. The organization experiences extreme peaks in its workloads. "Very often, just before conferences, physicists want to do an enormous amount of extra analysis to publish their papers, and we have to scale to these peaks, which means overcommitting resources in some cases," says Rocha. "We want to have a more hybrid infrastructure, where we have our on premise infrastructure but can make use of public clouds temporarily when these peaks come up."<br><br>
-  Additionally, few years ago, CERN announced that it would be doing a big upgrade of its accelerators, which will mean a ten-fold increase in the amount of data that can be collected. "So we’ve been looking to new technologies that can help improve our efficiency in our infrastructure, so that we can dedicate more of our resources to the actual processing of the data," says Rocha.
+{{< case-studies/quote author="Ricardo Rocha, Software Engineer, CERN" >}}
+"Kubernetes is something we can relate to very much because it's naturally distributed. What it gives us is a uniform API across heterogeneous resources to define our workloads. This is something we struggled with a lot in the past when we want to expand our resources outside our infrastructure."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/cern/banner3.jpg')">
-  <div class="banner3text">
-    "Before, the tendency was always: ‘I need this, I get a couple of developers, and I implement it.’ Right now it’s ‘I need this, I’m sure other people also need this, so I’ll go and ask around.’ The CNCF is a good source because there’s a very large catalog of applications available. It’s very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It’s much easier for us to try it out, and if we see it’s a good solution, we try to reach out to the community and start working with that community." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Ricardo Rocha, Software Engineer, CERN</span>
+{{< case-studies/lead >}}
+With a mission of researching fundamental science, and a stable of extremely large machines, the European Organization for Nuclear Research (CERN) operates at what can only be described as hyperscale.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Rocha’s team started looking at Kubernetes and containerization in the second half of 2015. "We’ve been using distributed infrastructures for decades now," says Rocha. "Kubernetes is something we can relate to very much because it’s naturally distributed. What it gives us is a uniform API across heterogeneous resources to define our workloads. This is something we struggled with a lot in the past when we want to expand our resources outside our infrastructure."<br><br>
-  The team created a prototype system for users to deploy their own Kubernetes cluster in CERN’s infrastructure, and spent six months validating the use cases and making sure that Kubernetes integrated with CERN’s internal systems. The main use case is batch workloads, which represent more than 80% of resource usage at CERN. (One single project that does most of the physics data processing and analysis alone consumes 250,000 cores.) "This is something where the investment in simplification of the deployment, logging, and monitoring pays off very quickly," says Rocha. Other use cases include Spark-based data analysis and machine learning to improve physics analysis. "The fact that most of these technologies integrate very well with Kubernetes makes our lives easier," he adds.<br><br>
-  The system went into production in October 2016, also using Helm for deployment, Prometheus for monitoring, and CoreDNS for DNS resolution within the cluster. "One thing that Kubernetes gives us is the full automation of the application," says Rocha. "So it comes with built-in monitoring and logging for all the applications and the workloads that deploy in Kubernetes. This is a massive simplification of our current deployments." The time to deploy a new cluster for a complex distributed storage system has gone from more than 3 hours to less than 15 minutes.<br><br> Adding new nodes to a cluster used to take more than an hour; now it takes less than 2 minutes. The time it takes to autoscale replicas for system components has decreased from more than an hour to less than 2 minutes.
+<p>Experiments are conducted in particle accelerators, the biggest of which is 27 kilometers in circumference. "We accelerate protons to very high energy, to close to the speed of light, and we make the two beams of protons collide in well-defined places," says CERN Software Engineer Ricardo Rocha. "We build experiments around these places where we do the collisions. The end result is a lot of data that we have to process."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/cern/banner4.jpg')">
-  <div class="banner4text">
-  "With Kubernetes, there’s a well-established technology and a big community that we can contribute to. It allows us to do our physics analysis without having to focus so much on the lower level software. This is just exciting. We are looking forward to keep contributing to the community and collaborating with everyone."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Ricardo Rocha, Software Engineer, CERN</span>
-  </div>
-</div>
+<p>And he does mean a lot: CERN currently stores and processes 330 petabytes of data—gathered from 4,300 projects and 3,300 users—using 10,000 hypervisors and 320,000 cores in its data centers.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Rocha points out that the metric used in the particle accelerators may be events per second, but in reality "it’s how fast and how much of the data we can process that actually counts." And efficiency has certainly been improved with Kubernetes. Initially, virtualization gave 20% overhead, but with tuning this was reduced to ~5%. Moving to Kubernetes on bare metal would get this to 0%. Not having to host virtual machines is expected to also get 10% of memory capacity back.<br><br>
-  Kubernetes federation, which CERN has been using for a portion of its production workloads since February 2018, has allowed the organization to adopt a hybrid cloud strategy. And it was remarkably simple to do. "We had a summer intern working on federation," says Rocha. "For many years, I’ve been developing distributed computing software, which took like a decade and a lot of effort from a lot of people to stabilize and make sure it works. And for our intern, in a couple of days he was able to demo to me and my team that we had a cluster at CERN and a few clusters outside in public clouds that were federated together and that we could submit workloads to. This was shocking for us. It really shows the power of using this kind of well-established technologies." <br><br>
-  With such results, adoption of Kubernetes has made rapid gains at CERN, and the team is eager to give back to the community. "If we look back into the ’90s and early 2000s, there were not a lot of companies focusing on systems that have to scale to this kind of size, storing petabytes of data, analyzing petabytes of data," says Rocha. "The fact that Kubernetes is supported by such a wide community and different backgrounds, it motivates us to contribute back."
+<p>Over the years, the CERN technology department has built a large computing infrastructure, based on OpenStack private clouds, to help the organization's physicists analyze and treat all this data. The organization experiences extreme peaks in its workloads. "Very often, just before conferences, physicists want to do an enormous amount of extra analysis to publish their papers, and we have to scale to these peaks, which means overcommitting resources in some cases," says Rocha. "We want to have a more hybrid infrastructure, where we have our on premise infrastructure but can make use of public clouds temporarily when these peaks come up."</p>
 
-</div>
+<p>Additionally, few years ago, CERN announced that it would be doing a big upgrade of its accelerators, which will mean a ten-fold increase in the amount of data that can be collected. "So we've been looking to new technologies that can help improve our efficiency in our infrastructure, so that we can dedicate more of our resources to the actual processing of the data," says Rocha.</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-This means that the physicist can build his or her analysis and publish it in a repository, share it with colleagues, and in 10 years redo the same analysis with new data. If we looked back even 10 years, this was just a dream."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Ricardo Rocha, Software Engineer, CERN</span></div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/cern/banner3.jpg"
+  author="Ricardo Rocha, Software Engineer, CERN"
+>}}
+"Before, the tendency was always: 'I need this, I get a couple of developers, and I implement it.' Right now it's 'I need this, I'm sure other people also need this, so I'll go and ask around.' The CNCF is a good source because there's a very large catalog of applications available. It's very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It's much easier for us to try it out, and if we see it's a good solution, we try to reach out to the community and start working with that community."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  These new technologies aren’t just enabling infrastructure improvements. CERN also uses the Kubernetes-based <a href="https://github.com/recast-hep">Reana/Recast</a> platform for reusable analysis, which is "the ability to define physics analysis as a set of workflows that are fully containerized in one single entry point," says Rocha. "This means that the physicist can build his or her analysis and publish it in a repository, share it with colleagues, and in 10 years redo the same analysis with new data. If we looked back even 10 years, this was just a dream."<br><br>
-  All of these things have changed the culture at CERN considerably. A decade ago, "The tendency was always: ‘I need this, I get a couple of developers, and I implement it,’" says Rocha. "Right now it’s ‘I need this, I’m sure other people also need this, so I’ll go and ask around.’ The CNCF is a good source because there’s a very large catalog of applications available. It’s very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It’s much easier for us to try it out, and if we see it’s a good solution, we try to reach out to the community and start working with that community."
+<p>Rocha's team started looking at Kubernetes and containerization in the second half of 2015. "We've been using distributed infrastructures for decades now," says Rocha. "Kubernetes is something we can relate to very much because it's naturally distributed. What it gives us is a uniform API across heterogeneous resources to define our workloads. This is something we struggled with a lot in the past when we want to expand our resources outside our infrastructure."</p>
 
-</div>
-</section>
+<p>The team created a prototype system for users to deploy their own Kubernetes cluster in CERN's infrastructure, and spent six months validating the use cases and making sure that Kubernetes integrated with CERN's internal systems. The main use case is batch workloads, which represent more than 80% of resource usage at CERN. (One single project that does most of the physics data processing and analysis alone consumes 250,000 cores.) "This is something where the investment in simplification of the deployment, logging, and monitoring pays off very quickly," says Rocha. Other use cases include Spark-based data analysis and machine learning to improve physics analysis. "The fact that most of these technologies integrate very well with Kubernetes makes our lives easier," he adds.</p>
+
+<p>The system went into production in October 2016, also using Helm for deployment, Prometheus for monitoring, and CoreDNS for DNS resolution within the cluster. "One thing that Kubernetes gives us is the full automation of the application," says Rocha. "So it comes with built-in monitoring and logging for all the applications and the workloads that deploy in Kubernetes. This is a massive simplification of our current deployments." The time to deploy a new cluster for a complex distributed storage system has gone from more than 3 hours to less than 15 minutes.</p>
+
+<p>Adding new nodes to a cluster used to take more than an hour; now it takes less than 2 minutes. The time it takes to autoscale replicas for system components has decreased from more than an hour to less than 2 minutes.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/cern/banner4.jpg"
+  author="Ricardo Rocha, Software Engineer, CERN"
+>}}
+"With Kubernetes, there's a well-established technology and a big community that we can contribute to. It allows us to do our physics analysis without having to focus so much on the lower level software. This is just exciting. We are looking forward to keep contributing to the community and collaborating with everyone."
+{{< /case-studies/quote >}}
+
+<p>Rocha points out that the metric used in the particle accelerators may be events per second, but in reality "it's how fast and how much of the data we can process that actually counts." And efficiency has certainly been improved with Kubernetes. Initially, virtualization gave 20% overhead, but with tuning this was reduced to ~5%. Moving to Kubernetes on bare metal would get this to 0%. Not having to host virtual machines is expected to also get 10% of memory capacity back.</p>
+
+<p>Kubernetes federation, which CERN has been using for a portion of its production workloads since February 2018, has allowed the organization to adopt a hybrid cloud strategy. And it was remarkably simple to do. "We had a summer intern working on federation," says Rocha. "For many years, I've been developing distributed computing software, which took like a decade and a lot of effort from a lot of people to stabilize and make sure it works. And for our intern, in a couple of days he was able to demo to me and my team that we had a cluster at CERN and a few clusters outside in public clouds that were federated together and that we could submit workloads to. This was shocking for us. It really shows the power of using this kind of well-established technologies."</p>
+
+<p>With such results, adoption of Kubernetes has made rapid gains at CERN, and the team is eager to give back to the community. "If we look back into the '90s and early 2000s, there were not a lot of companies focusing on systems that have to scale to this kind of size, storing petabytes of data, analyzing petabytes of data," says Rocha. "The fact that Kubernetes is supported by such a wide community and different backgrounds, it motivates us to contribute back."</p>
+
+{{< case-studies/quote author="Ricardo Rocha, Software Engineer, CERN" >}}
+This means that the physicist can build his or her analysis and publish it in a repository, share it with colleagues, and in 10 years redo the same analysis with new data. If we looked back even 10 years, this was just a dream."
+{{< /case-studies/quote >}}
+
+<p>These new technologies aren't just enabling infrastructure improvements. CERN also uses the Kubernetes-based <a href="https://github.com/recast-hep">Reana/Recast</a> platform for reusable analysis, which is "the ability to define physics analysis as a set of workflows that are fully containerized in one single entry point," says Rocha. "This means that the physicist can build his or her analysis and publish it in a repository, share it with colleagues, and in 10 years redo the same analysis with new data. If we looked back even 10 years, this was just a dream."</p>
+
+<p>All of these things have changed the culture at CERN considerably. A decade ago, "The tendency was always: 'I need this, I get a couple of developers, and I implement it,'" says Rocha. "Right now it's 'I need this, I'm sure other people also need this, so I'll go and ask around.' The CNCF is a good source because there's a very large catalog of applications available. It's very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It's much easier for us to try it out, and if we see it's a good solution, we try to reach out to the community and start working with that community."</p>
diff --git a/content/en/case-studies/chinaunicom/index.html b/content/en/case-studies/chinaunicom/index.html
index 4479d60e67..4327e5c6a3 100644
--- a/content/en/case-studies/chinaunicom/index.html
+++ b/content/en/case-studies/chinaunicom/index.html
@@ -1,95 +1,77 @@
 ---
 title: China Unicom Case Study
-
 linkTitle: chinaunicom
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/chinaunicom/banner1.jpg
+heading_title_logo: /images/chinaunicom_logo.png
+subheading: >
+  China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency and Lower IT Costs
+case_study_details:
+  - Company: China Unicom
+  - Location: Beijing, China
+  - Industry: Telecom
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/chinaunicom/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/chinaunicom_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;line-height:1.4em">China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency<br>and Lower IT&nbsp;Costs
+<h2>Challenge</h2>
 
-</div></h1>
+<p>China Unicom is one of the top three telecom operators in China, and to serve its 300 million users, the company runs several data centers with thousands of servers in each, using <a href="https://www.docker.com/">Docker</a> containerization and <a href="https://www.vmware.com/">VMWare</a> and <a href="https://www.openstack.org/">OpenStack</a> infrastructure since 2016. Unfortunately, "the resource utilization rate was relatively low," says Chengyu Zhang, Group Leader of Platform Technology R&D, "and we didn't have a cloud platform to accommodate our hundreds of applications." Formerly an entirely state-owned company, China Unicom has in recent years taken private investment from BAT (Baidu, Alibaba, Tencent) and JD.com, and is now focusing on internal development using open source technology, rather than commercial products. As such, Zhang's China Unicom Lab team began looking for open source orchestration for its cloud infrastructure.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>China Unicom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Beijing, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Telecom</b>
-</div>
+<p>Because of its rapid growth and mature open source community, Kubernetes was a natural choice for China Unicom. The company's Kubernetes-enabled cloud platform now hosts 50 microservices and all new development going forward. "Kubernetes has improved our experience using cloud infrastructure," says Zhang. "There is currently no alternative technology that can replace it." China Unicom also uses <a href="https://istio.io/">Istio</a> for its microservice framework, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://coredns.io/">CoreDNS</a>, and <a href="https://www.fluentd.org/">Fluentd</a>.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    China Unicom is one of the top three telecom operators in China, and to serve its 300 million users, the company runs several data centers with thousands of servers in each, using <a href="https://www.docker.com/">Docker</a> containerization and <a href="https://www.vmware.com/">VMWare</a> and <a href="https://www.openstack.org/">OpenStack</a> infrastructure since 2016. Unfortunately, "the resource utilization rate was relatively low," says Chengyu Zhang, Group Leader of Platform Technology R&D, "and we didn’t have a cloud platform to accommodate our hundreds of applications." Formerly an entirely state-owned company, China Unicom has in recent years taken private investment from BAT (Baidu, Alibaba, Tencent) and JD.com, and is now focusing on internal development using open source technology, rather than commercial products. As such, Zhang’s China Unicom Lab team began looking for open source orchestration for its cloud infrastructure.
-<br><br>
-    <h2>Solution</h2>
-    Because of its rapid growth and mature open source community, Kubernetes was a natural choice for China Unicom. The company’s Kubernetes-enabled cloud platform now hosts 50 microservices and all new development going forward. "Kubernetes has improved our experience using cloud infrastructure," says Zhang. "There is currently no alternative technology that can replace it." China Unicom also uses <a href="https://istio.io/">Istio</a> for its microservice framework, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://coredns.io/">CoreDNS</a>, and <a href="https://www.fluentd.org/">Fluentd</a>.
-<br><br>
 <h2>Impact</h2>
-    At China Unicom, Kubernetes has improved both operational and development efficiency. Resource utilization has increased by 20-50%, lowering IT infrastructure costs, and deployment time has gone from a couple of hours to 5-10 minutes. "This is mainly because of the self-healing and scalability, so we can increase our efficiency in operation and maintenance," Zhang says. "For example, we currently have only five people maintaining our multiple systems. We could never imagine we can achieve this scalability in such a short time."
 
-</div>
+<p>At China Unicom, Kubernetes has improved both operational and development efficiency. Resource utilization has increased by 20-50%, lowering IT infrastructure costs, and deployment time has gone from a couple of hours to 5-10 minutes. "This is mainly because of the self-healing and scalability, so we can increase our efficiency in operation and maintenance," Zhang says. "For example, we currently have only five people maintaining our multiple systems. We could never imagine we can achieve this scalability in such a short time."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "Kubernetes has improved our experience using cloud infrastructure. There is currently no alternative technology that can replace it."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>With more than 300 million users, China Unicom is one of the country’s top three telecom operators. </h2>
+{{< case-studies/quote author="Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom" >}}
+"Kubernetes has improved our experience using cloud infrastructure. There is currently no alternative technology that can replace it."
+{{< /case-studies/quote >}}
 
-  Behind the scenes, the company runs multiple data centers with thousands of servers in each, using Docker containerization and VMWare and OpenStack infrastructure since 2016. Unfortunately, "the resource utilization rate was relatively low," says Chengyu Zhang,  Group Leader of Platform Technology R&D, "and we didn’t have a cloud platform to accommodate our hundreds of applications." <br><br>
-  Zhang’s team, which is responsible for new technology, R&D and platforms, set out to find an IT management solution. Formerly an entirely state-owned company, China Unicom has in recent years taken private investment from BAT (Baidu, Alibaba, Tencent) and JD.com, and is now focusing on homegrown development using open source technology, rather than commercial products. For that reason, the team began looking for open source orchestration for its cloud infrastructure.
+{{< case-studies/lead >}}
+With more than 300 million users, China Unicom is one of the country's top three telecom operators.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/chinaunicom/banner3.jpg');width:100%;padding-left:0;">
-  <div class="banner3text">
-    "We could never imagine we can achieve this scalability in such a short time."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom</span>
+<p>Behind the scenes, the company runs multiple data centers with thousands of servers in each, using Docker containerization and VMWare and OpenStack infrastructure since 2016. Unfortunately, "the resource utilization rate was relatively low," says Chengyu Zhang,  Group Leader of Platform Technology R&D, "and we didn't have a cloud platform to accommodate our hundreds of applications."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Though China Unicom was already using Mesos for a core telecom operator system, the team felt that Kubernetes was a natural choice for the new cloud platform. "The main reason was that it has a mature community," says Zhang. "It grows very rapidly, and so we can learn a lot from others’ best practices." China Unicom also uses Istio for its microservice framework, Envoy, CoreDNS, and Fluentd.<br><br>
-  The company’s Kubernetes-enabled cloud platform now hosts 50 microservices and all new development going forward. China Unicom developers can easily leverage the technology through APIs, without doing the development work themselves. The cloud platform provides 20-30 services connected to the company’s data center PaaS platform, as well as supports things such as big data analysis for internal users in the branch offices across the 31 provinces in China.<br><br>
-  "Kubernetes has improved our experience using cloud infrastructure," says Zhang. "There is currently no alternative technology that can replace it."
+<p>Zhang's team, which is responsible for new technology, R&D and platforms, set out to find an IT management solution. Formerly an entirely state-owned company, China Unicom has in recent years taken private investment from BAT (Baidu, Alibaba, Tencent) and JD.com, and is now focusing on homegrown development using open source technology, rather than commercial products. For that reason, the team began looking for open source orchestration for its cloud infrastructure.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/chinaunicom/banner4.jpg');width:100%">
-  <div class="banner4text">
-  "This technology is relatively complicated, but as long as developers get used to it, they can enjoy all the benefits." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Jie Jia, Member of Platform Technology R&D, China Unicom</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/chinaunicom/banner3.jpg"
+  author="Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom"
+>}}
+"We could never imagine we can achieve this scalability in such a short time."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  In fact, Kubernetes has boosted both operational and development efficiency at China Unicom. Resource utilization has increased by 20-50%, lowering IT infrastructure costs, and deployment time has gone from a couple of hours to 5-10 minutes. "This is mainly because of the self-healing and scalability of Kubernetes, so we can increase our efficiency in operation and maintenance," Zhang says. "For example, we currently have only five people maintaining our multiple systems."<br><br>
-  With the wins China Unicom has experienced with Kubernetes, Zhang and his team are eager to give back to the community. That starts with participating in meetups and conferences, and offering advice to other companies that are considering a similar path. "Especially for those companies who have had traditional cloud computing system, I really recommend them to join the cloud native computing community," says Zhang.
+<p>Though China Unicom was already using Mesos for a core telecom operator system, the team felt that Kubernetes was a natural choice for the new cloud platform. "The main reason was that it has a mature community," says Zhang. "It grows very rapidly, and so we can learn a lot from others' best practices." China Unicom also uses Istio for its microservice framework, Envoy, CoreDNS, and Fluentd.</p>
 
-</div>
+<p>The company's Kubernetes-enabled cloud platform now hosts 50 microservices and all new development going forward. China Unicom developers can easily leverage the technology through APIs, without doing the development work themselves. The cloud platform provides 20-30 services connected to the company's data center PaaS platform, as well as supports things such as big data analysis for internal users in the branch offices across the 31 provinces in China.</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-"Companies can use the managed services offered by companies like Rancher, because they have already customized this technology, you can easily leverage this technology."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Jie Jia, Member of Platform Technology R&D, China Unicom</span></div>
-</div>
+<p>"Kubernetes has improved our experience using cloud infrastructure," says Zhang. "There is currently no alternative technology that can replace it."</p>
 
-<div class="fullcol">
-  Platform Technology R&D team member Jie Jia adds that though "this technology is relatively complicated, as long as developers get used to it, they can enjoy all the benefits." And Zhang points out that in his own experience with virtual machine cloud, "Kubernetes and these cloud native technologies are relatively simpler."<br><br>
-  Plus, "companies can use the managed services offered by companies like <a href="https://rancher.com/">Rancher</a>, because they have already customized this technology," says Jia. "You can easily leverage this technology."<br><br>
-  Looking ahead, China Unicom plans to develop more applications on Kubernetes, focusing on big data and machine learning. The team is continuing to optimize the cloud platform that it built, and hopes to pass the conformance test to join CNCF’s <a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">Certified Kubernetes Conformance Program</a>. They’re also hoping to someday contribute code back to the community. <br><br>
-  If that sounds ambitious, it’s because the results they’ve gotten from adopting Kubernetes have been beyond even their greatest expectations. Says Zhang: "We could never imagine we can achieve this scalability in such a short time."
+{{< case-studies/quote 
+  image="/images/case-studies/chinaunicom/banner4.jpg"
+  author="Jie Jia, Member of Platform Technology R&D, China Unicom"
+>}}
+"This technology is relatively complicated, but as long as developers get used to it, they can enjoy all the benefits."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-</body>
-</html>
+<p>In fact, Kubernetes has boosted both operational and development efficiency at China Unicom. Resource utilization has increased by 20-50%, lowering IT infrastructure costs, and deployment time has gone from a couple of hours to 5-10 minutes. "This is mainly because of the self-healing and scalability of Kubernetes, so we can increase our efficiency in operation and maintenance," Zhang says. "For example, we currently have only five people maintaining our multiple systems."</p>
+
+<p>With the wins China Unicom has experienced with Kubernetes, Zhang and his team are eager to give back to the community. That starts with participating in meetups and conferences, and offering advice to other companies that are considering a similar path. "Especially for those companies who have had traditional cloud computing system, I really recommend them to join the cloud native computing community," says Zhang.</p>
+
+{{< case-studies/quote author="Jie Jia, Member of Platform Technology R&D, China Unicom" >}}
+"Companies can use the managed services offered by companies like Rancher, because they have already customized this technology, you can easily leverage this technology."
+{{< /case-studies/quote >}}
+
+<p>Platform Technology R&D team member Jie Jia adds that though "this technology is relatively complicated, as long as developers get used to it, they can enjoy all the benefits." And Zhang points out that in his own experience with virtual machine cloud, "Kubernetes and these cloud native technologies are relatively simpler."</p>
+
+<p>Plus, "companies can use the managed services offered by companies like <a href="https://rancher.com/">Rancher</a>, because they have already customized this technology," says Jia. "You can easily leverage this technology."</p>
+
+<p>Looking ahead, China Unicom plans to develop more applications on Kubernetes, focusing on big data and machine learning. The team is continuing to optimize the cloud platform that it built, and hopes to pass the conformance test to join CNCF's <a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">Certified Kubernetes Conformance Program</a>. They're also hoping to someday contribute code back to the community.</p>
+
+<p>If that sounds ambitious, it's because the results they've gotten from adopting Kubernetes have been beyond even their greatest expectations. Says Zhang: "We could never imagine we can achieve this scalability in such a short time."</p>
diff --git a/content/en/case-studies/city-of-montreal/index.html b/content/en/case-studies/city-of-montreal/index.html
index 55378c649e..f639a30bde 100644
--- a/content/en/case-studies/city-of-montreal/index.html
+++ b/content/en/case-studies/city-of-montreal/index.html
@@ -3,97 +3,79 @@ title: City of Montreal Case Study
 linkTitle: city-of-montreal
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/montreal/banner1.jpg
+heading_title_logo: /images/montreal_logo.png
+subheading: >
+  City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed Architecture with Kubernetes
+case_study_details:
+  - Company: City of Montréal
+  - Location: Montréal, Québec, Canada
+  - Industry: Government
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/montreal/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/montreal_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed&nbsp;Architecture&nbsp;with&nbsp;Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>Like many governments, Montréal has a number of legacy systems, and "we have systems that are older than some developers working here," says the city's CTO, Jean-Martin Thibault. "We have mainframes, all flavors of Windows, various flavors of Linux, old and new Oracle systems, Sun servers, all kinds of databases. Like all big corporations, some of the most important systems, like Budget and Human Resources, were developed on mainframes in-house over the past 30 years." There are over 1,000 applications in all, and most of them were running on different ecosystems. In 2015, a new management team decided to break down those silos, and invest in IT in order to move toward a more integrated governance for the city. They needed to figure out how to modernize the architecture.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>City of Montréal</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Montréal, Québec, Canada</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Government</b>
-</div>
+<p>The first step was containerization. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins to deploy. "We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things," says Solutions Architect Marc Khouzam. They soon realized they needed orchestration as well, and opted for Kubernetes. Says Enterprise Architect Morgan Martinet: "Kubernetes offered concepts on how you would describe an architecture for any kind of application, and based on those concepts, deploy what's required to run the infrastructure. It was becoming a de facto standard."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    Like many governments, Montréal has a number of legacy systems, and “we have systems that are older than some developers working here,” says the city’s CTO, Jean-Martin Thibault. “We have mainframes, all flavors of Windows, various flavors of Linux, old and new Oracle systems, Sun servers, all kinds of databases. Like all big corporations, some of the most important systems, like Budget and Human Resources, were developed on mainframes in-house over the past 30 years.” There are over 1,000 applications in all, and most of them were running on different ecosystems. In 2015, a new management team decided to break down those silos, and invest in IT in order to move toward a more integrated governance for the city. They needed to figure out how to modernize the architecture.
-
-    <h2>Solution</h2>
-    The first step was containerization. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins to deploy. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. They soon realized they needed orchestration as well, and opted for Kubernetes. Says Enterprise Architect Morgan Martinet: “Kubernetes offered concepts on how you would describe an architecture for any kind of application, and based on those concepts, deploy what’s required to run the infrastructure. It was becoming a de facto standard.”
-<br>
 <h2>Impact</h2>
-    The time to market has improved drastically, from many months to a few weeks. Deployments went from months to hours. “In the past, you would have to ask for virtual machines, and that alone could take weeks, easily,” says Thibault. “Now you don’t even have to ask for anything. You just create your project and it gets deployed.” Kubernetes has also improved the efficiency of how the city uses its compute resources: “Before, the 200 application components we currently run on Kubernetes would have required hundreds of virtual machines, and now, if we’re talking about a single environment of production, we are able to run them on 8 machines, counting the masters of Kubernetes,” says Martinet. And it’s all done with a small team of just 5 people operating the Kubernetes clusters.
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We realized the limitations of having a non-orchestrated Docker environment. Kubernetes came to the rescue, bringing in all these features that make it a lot easier to manage and give a lot more benefits to the users."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- JEAN-MARTIN THIBAULT, CTO, CITY OF MONTRÉAL</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>The second biggest municipality in Canada, Montréal has a large number of legacy systems keeping the government running. And while they don’t quite date back to the city’s founding in 1642, “we have systems that are older than some developers working here,” jokes the city’s CTO, Jean-Martin Thibault.</h2>
-  “We have mainframes, all flavors of Windows, various flavors of Linux, old and new Oracle systems, Sun servers, all kinds of databases. Some of the most important systems, like Budget and Human Resources, were developed on mainframes in-house over the past 30 years.”
-<br><br>
-  In recent years, that fact became a big pain point. There are over 1,000 applications in all, running on almost as many different ecosystems. In 2015, a new city management team decided to break down those silos, and invest in IT in order to move toward a more integrated governance. “The organization was siloed, so as a result the architecture was siloed,” says Thibault. “Once we got integrated into one IT team, we decided to redo an overall enterprise architecture.”
-<br><br>
-  The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/montreal/banner3.jpg')">
-  <div class="banner3text">
-    "Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It’s no longer dependent on deployment. Deployment is so fast that it’s negligible."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MARC KHOUZAM, SOLUTIONS ARCHITECT, CITY OF MONTRÉAL</span>
+<p>The time to market has improved drastically, from many months to a few weeks. Deployments went from months to hours. "In the past, you would have to ask for virtual machines, and that alone could take weeks, easily," says Thibault. "Now you don't even have to ask for anything. You just create your project and it gets deployed." Kubernetes has also improved the efficiency of how the city uses its compute resources: "Before, the 200 application components we currently run on Kubernetes would have required hundreds of virtual machines, and now, if we're talking about a single environment of production, we are able to run them on 8 machines, counting the masters of Kubernetes," says Martinet. And it's all done with a small team of just 5 people operating the Kubernetes clusters.</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  But this Docker farm setup had some limitations, including the lack of self-healing and dynamic scaling based on traffic, and the effort required to optimize server resources and scale to multiple instances of the same container. The team soon realized they needed orchestration as well. “Kubernetes came to the rescue,” says Thibault, “bringing in all these features that make it a lot easier to manage and give a lot more benefits to the users.”
-<br><br>
-  The team had evaluated several orchestration solutions, but Kubernetes stood out because it addressed all of the pain points. (They were also inspired by Yahoo! Japan’s use case, which the team members felt came close to their vision.) “Kubernetes offered concepts on how you would describe an architecture for any kind of application, and based on those concepts, deploy what’s required to run the infrastructure,” says Enterprise Architect Morgan Martinet. “It was becoming a de facto standard. It also promised portability across cloud providers. The choice of Kubernetes now gives us many options such as running clusters in-house or in any IaaS provider, or even using Kubernetes-as-a-service in any of the major cloud providers.”
-<br><br>
-  Another important factor in the decision was vendor neutrality. “As a government entity, it is essential for us to be neutral in our selection of products and providers,” says Thibault. “The independence of the Cloud Native Computing Foundation from any company provides this.”
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/montreal/banner4.jpg')">
-  <div class="banner4text">
-  "Kubernetes has been great. It’s been stable, and it provides us with elasticity, resilience, and robustness. While re-architecting for Kubernetes, we also benefited from the monitoring and logging aspects, with centralized logging, Prometheus logging, and Grafana dashboards. We have enhanced visibility of what’s being deployed." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL</span>
-  </div>
-</div>
+{{< case-studies/quote author="JEAN-MARTIN THIBAULT, CTO, CITY OF MONTRÉAL" >}}
+"We realized the limitations of having a non-orchestrated Docker environment. Kubernetes came to the rescue, bringing in all these features that make it a lot easier to manage and give a lot more benefits to the users."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  The Kubernetes implementation began with the deployment of a small cluster using an internal Ansible playbook, which was soon replaced by the Kismatic distribution. Given the complexity they saw in operating a Kubernetes platform, they decided to provide development groups with an automated CI/CD solution based on Helm. “An integrated CI/CD solution on Kubernetes standardized how the various development teams designed and deployed their solutions, but allowed them to remain independent,” says Khouzam.
-<br><br>
-  During the re-architecting process, the team also added Prometheus for monitoring and alerting, Fluentd for logging, and Grafana for visualization. “We have enhanced visibility of what’s being deployed,” says Martinet. Adds Khouzam: “The big benefit is we can track anything, even things that don’t run inside the Kubernetes cluster. It’s our way to unify our monitoring effort.”
-<br><br>
-  All together, the cloud native solution has had a positive impact on velocity as well as administrative overhead. With standardization, code generation, automatic deployments into Kubernetes, and standardized monitoring through Prometheus, the time to market has improved drastically, from many months to a few weeks. Deployments went from months and weeks of planning down  to hours. “In the past, you would have to ask for virtual machines, and that alone could take weeks to properly provision,” says Thibault. Plus, for dedicated systems, experts often had to be brought in to install them with their own recipes, which could take weeks and months.
-<br><br>
-  Now, says Khouzam, “we can deploy pretty much any application that’s been Dockerized without any help from anybody. Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It’s no longer dependent on deployment. Deployment is so fast that it’s negligible.”
+{{< case-studies/lead >}}
+The second biggest municipality in Canada, Montréal has a large number of legacy systems keeping the government running. And while they don't quite date back to the city's founding in 1642, "we have systems that are older than some developers working here," jokes the city's CTO, Jean-Martin Thibault.
+{{< /case-studies/lead >}}
 
-</div>
+<p>"We have mainframes, all flavors of Windows, various flavors of Linux, old and new Oracle systems, Sun servers, all kinds of databases. Some of the most important systems, like Budget and Human Resources, were developed on mainframes in-house over the past 30 years."</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-"We’re working with the market when possible, to put pressure on our vendors to support Kubernetes, because it’s a much easier solution to manage"<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL</span></div>
-</div>
+<p>In recent years, that fact became a big pain point. There are over 1,000 applications in all, running on almost as many different ecosystems. In 2015, a new city management team decided to break down those silos, and invest in IT in order to move toward a more integrated governance. "The organization was siloed, so as a result the architecture was siloed," says Thibault. "Once we got integrated into one IT team, we decided to redo an overall enterprise architecture."</p>
 
-<div class="fullcol">
-  Kubernetes has also improved the efficiency of how the city uses its compute resources: “Before, the 200 application components we currently run in Kubernetes would have required hundreds of virtual machines, and now, if we’re talking about a single environment of production, we are able to run them on 8 machines, counting the masters of Kubernetes,” says Martinet. And it’s all done with a small team of just five people operating the Kubernetes clusters. Adds Martinet: “It’s a dramatic improvement no matter what you measure.”
-<br><br>
-  So it should come as no surprise that the team’s strategy going forward is to target Kubernetes as much as they can. “If something can’t run inside Kubernetes, we’ll wait for it,” says Thibault. That means they haven’t moved any of the city’s Windows systems onto Kubernetes, though it’s something they would like to do. “We’re working with the market when possible, to put pressure on our vendors to support Kubernetes, because it’s a much easier solution to manage,” says Martinet.
-<br><br>
-  Thibault sees a near future where 60% of the city’s workloads are running on a Kubernetes platform—basically any and all of the use cases that they can get to work there. “It’s so much more efficient than the way we used to do things,” he says. “There’s no looking back.”
+<p>The first step to modernize the architecture was containerization. "We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things," says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.</p>
 
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/montreal/banner3.jpg"
+  author="MARC KHOUZAM, SOLUTIONS ARCHITECT, CITY OF MONTRÉAL"
+>}}
+"Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It's no longer dependent on deployment. Deployment is so fast that it's negligible."
+{{< /case-studies/quote >}}
+
+<p>But this Docker farm setup had some limitations, including the lack of self-healing and dynamic scaling based on traffic, and the effort required to optimize server resources and scale to multiple instances of the same container. The team soon realized they needed orchestration as well. "Kubernetes came to the rescue," says Thibault, "bringing in all these features that make it a lot easier to manage and give a lot more benefits to the users."</p>
+
+<p>The team had evaluated several orchestration solutions, but Kubernetes stood out because it addressed all of the pain points. (They were also inspired by Yahoo! Japan's use case, which the team members felt came close to their vision.) "Kubernetes offered concepts on how you would describe an architecture for any kind of application, and based on those concepts, deploy what's required to run the infrastructure," says Enterprise Architect Morgan Martinet. "It was becoming a de facto standard. It also promised portability across cloud providers. The choice of Kubernetes now gives us many options such as running clusters in-house or in any IaaS provider, or even using Kubernetes-as-a-service in any of the major cloud providers."</p>
+
+<p>Another important factor in the decision was vendor neutrality. "As a government entity, it is essential for us to be neutral in our selection of products and providers," says Thibault. "The independence of the Cloud Native Computing Foundation from any company provides this."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/montreal/banner4.jpg"
+  author="MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL"
+>}}
+"Kubernetes has been great. It's been stable, and it provides us with elasticity, resilience, and robustness. While re-architecting for Kubernetes, we also benefited from the monitoring and logging aspects, with centralized logging, Prometheus logging, and Grafana dashboards. We have enhanced visibility of what's being deployed."
+{{< /case-studies/quote >}}
+
+<p>The Kubernetes implementation began with the deployment of a small cluster using an internal Ansible playbook, which was soon replaced by the Kismatic distribution. Given the complexity they saw in operating a Kubernetes platform, they decided to provide development groups with an automated CI/CD solution based on Helm. "An integrated CI/CD solution on Kubernetes standardized how the various development teams designed and deployed their solutions, but allowed them to remain independent," says Khouzam.</p>
+
+<p>During the re-architecting process, the team also added Prometheus for monitoring and alerting, Fluentd for logging, and Grafana for visualization. "We have enhanced visibility of what's being deployed," says Martinet. Adds Khouzam: "The big benefit is we can track anything, even things that don't run inside the Kubernetes cluster. It's our way to unify our monitoring effort."</p>
+
+<p>All together, the cloud native solution has had a positive impact on velocity as well as administrative overhead. With standardization, code generation, automatic deployments into Kubernetes, and standardized monitoring through Prometheus, the time to market has improved drastically, from many months to a few weeks. Deployments went from months and weeks of planning down  to hours. "In the past, you would have to ask for virtual machines, and that alone could take weeks to properly provision," says Thibault. Plus, for dedicated systems, experts often had to be brought in to install them with their own recipes, which could take weeks and months.</p>
+
+<p>Now, says Khouzam, "we can deploy pretty much any application that's been Dockerized without any help from anybody. Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It's no longer dependent on deployment. Deployment is so fast that it's negligible."</p>
+
+{{< case-studies/quote author="MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL">}}
+"We're working with the market when possible, to put pressure on our vendors to support Kubernetes, because it's a much easier solution to manage"
+{{< /case-studies/quote >}}
+
+<p>Kubernetes has also improved the efficiency of how the city uses its compute resources: "Before, the 200 application components we currently run in Kubernetes would have required hundreds of virtual machines, and now, if we're talking about a single environment of production, we are able to run them on 8 machines, counting the masters of Kubernetes," says Martinet. And it's all done with a small team of just five people operating the Kubernetes clusters. Adds Martinet: "It's a dramatic improvement no matter what you measure."</p>
+
+<p>So it should come as no surprise that the team's strategy going forward is to target Kubernetes as much as they can. "If something can't run inside Kubernetes, we'll wait for it," says Thibault. That means they haven't moved any of the city's Windows systems onto Kubernetes, though it's something they would like to do. "We're working with the market when possible, to put pressure on our vendors to support Kubernetes, because it's a much easier solution to manage," says Martinet.</p>
+
+<p>Thibault sees a near future where 60% of the city's workloads are running on a Kubernetes platform—basically any and all of the use cases that they can get to work there. "It's so much more efficient than the way we used to do things," he says. "There's no looking back."</p>
diff --git a/content/en/case-studies/crowdfire/index.html b/content/en/case-studies/crowdfire/index.html
index 227a5c0839..98caae2830 100644
--- a/content/en/case-studies/crowdfire/index.html
+++ b/content/en/case-studies/crowdfire/index.html
@@ -1,101 +1,85 @@
 ---
 title: Crowdfire Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_crowdfire.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/crowdfire/banner1.jpg
+heading_title_logo: /images/crowdfire_logo.png
+subheading: >
+  How to Keep Iterating a Fast-Growing App With a Cloud-Native Approach
+case_study_details:
+  - Company: Crowdfire
+  - Location: Mumbai, India
+  - Industry: Social Media Software
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/crowdfire_logo.png" class="header_logo"><br> <div class="subhead">How to Keep Iterating a Fast-Growing App With a Cloud-Native Approach</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p><a href="https://www.crowdfireapp.com/">Crowdfire</a> helps content creators create their content anywhere on the Internet and publish it everywhere else in the right format. Since its launch in 2010, it has grown to 16 million users. The product began as a monolith app running on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, and in 2015, the company began a transformation to microservices running on Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>. "It was okay for our use cases initially, but as the number of services, development teams and scale increased, the deploy times, self-healing capabilities and resource utilization started to become problems for us," says Software Engineer Amanpreet Singh, who leads the infrastructure team for Crowdfire.</p>
 
-<div class="details">
-    Company &nbsp;<b>Crowdfire</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Mumbai, India</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Social Media Software</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        <a href="https://www.crowdfireapp.com/">Crowdfire</a> helps content creators create their content anywhere on the Internet and publish it everywhere else in the right format. Since its launch in 2010, it has grown to 16 million users. The product began as a monolith app running on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, and in 2015, the company began a transformation to microservices running on Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>. "It was okay for our use cases initially, but as the number of services, development teams and scale increased, the deploy times, self-healing capabilities and resource utilization started to become problems for us," says Software Engineer Amanpreet Singh, who leads the infrastructure team for Crowdfire.<br>
-        <h2>Solution</h2>
-            "We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>.
-      <br>
-      </div>
-
-<div class="col2">
+<p>"We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>.</p>
 
 <h2>Impact</h2>
-      "Kubernetes has helped us reduce the deployment time from 15 minutes to less than a minute," says Singh. "Due to Kubernetes’s self-healing nature, the operations team doesn’t need to do any manual intervention in case of a node or pod failure." Plus, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it’s finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines."
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-  "In the 15 months that we’ve been using Kubernetes, it has been amazing for us. It enabled us to iterate quickly, increase development speed, and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Amanpreet Singh, Software Engineer at Crowdfire</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-    <h2>"If you build it, they will come."</h2>
-    For most content creators, only half of that movie quote may ring true. Sure, platforms like Wordpress, YouTube and Shopify have made it simple for almost anyone to start publishing new content online, but attracting an audience isn’t as easy. Crowdfire "helps users publish their content to all possible places where their audience exists," says Amanpreet Singh, a Software Engineer at the company based in Mumbai, India. Crowdfire has gained more than 16 million users—from bloggers and artists to makers and small businesses—since its launch in 2010.<br><br>
-    With that kind of growth—and a high demand from users for new features and continuous improvements—the Crowdfire team struggled to keep up behind the scenes. In 2015, they moved their monolith Java application to Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a> and started breaking it down into microservices.<br><br>
-    It was a good first step, but the team soon realized they needed to go further down the cloud-native path, which would lead them to Kubernetes. "It was okay for our use cases initially, but as the number of services and development teams increased and we scaled further, deploy times, self-healing capabilities and resource utilization started to become problematic," says Singh, who leads the infrastructure team at Crowdfire. "We realized that we needed a more cloud-native approach to deal with these issues."<br><br>
-    As he looked around for solutions, Singh had a checklist of what Crowdfire needed. "We wanted to keep some things separate so they could be shipped independent of other things; this would help remove blockers and let different teams work at their own pace," he says. "We also make a lot of data-driven decisions, so shipping a feature and its iterations quickly was a must."<br><br>
-    Kubernetes checked all the boxes and then some. "One of the best things was the built-in service discovery," he says. "When you have a bunch of microservices that need to call each other, having internal DNS readily available and service IPs and ports automatically set as environment variables help a lot." Plus, he adds, "Kubernetes’s opinionated approach made it easier to get started."
+<p>"Kubernetes has helped us reduce the deployment time from 15 minutes to less than a minute," says Singh. "Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." Plus, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines."</p>
 
-</div>
-</section>
-<div class="banner3">
-  <div class="banner3text">
-    "We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on Terraform and Ansible."
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  There was another compelling business reason for the cloud-native approach. "In today’s world of ever-changing business requirements, using cloud native technology provides a variety of options to choose from—even the ability to run services in a hybrid cloud environment," says Singh. "Businesses can keep services in a region closest to the users, and thus benefit from high-availability and resiliency."<br><br>
-  So in February 2016, Singh set up a test Kubernetes cluster using the kube-up scripts provided. "I explored the features and was able to deploy an application pretty easily," he says. "However, it seemed like a black box since I didn’t understand the components completely, and had no idea what the kube-up script did under the hood. So when it broke, it was hard to find the issue and fix it." <br><br>
-  To get a better understanding, Singh dove into the internals of Kubernetes, reading the docs and even some of the code. And he looked to the Kubernetes community for more insight. "I used to stay up a little late every night (a lot of users were active only when it’s night here in India) and would try to answer questions on the Kubernetes community Slack from users who were getting started," he says. "I would also follow other conversations closely. I must admit I was able to avoid a lot of issues in our setup because I knew others had faced the same issues."<br><br>
-  Based on the knowledge he gained, Singh decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>. "I wrote Terraform to launch Kubernetes master and nodes (Auto Scaling Groups) and an Ansible playbook to install the required components," he says. (The company recently switched to using prebaked <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html">AMIs</a> to make the node bringup faster, and is planning to change its networking layer.) <br><br>
+{{< case-studies/quote author="Amanpreet Singh, Software Engineer at Crowdfire" >}}
+"In the 15 months that we've been using Kubernetes, it has been amazing for us. It enabled us to iterate quickly, increase development speed, and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4">
-  <div class="banner4text">
-    "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes’s self-healing nature, the operations team doesn’t need to do any manual intervention in case of a node or pod failure."
-  </div>
-</div>
+{{< case-studies/lead >}}
+"If you build it, they will come."
+{{< /case-studies/lead >}}
 
-<section class="section4">
-<div class="fullcol">
-  First, the team migrated a few staging services from Elastic Beanstalk to the new Kubernetes staging cluster, and then set up a production cluster a month later to deploy some services. The results were convincing. "By the end of March 2016, we established that all the new services must be deployed on Kubernetes," says Singh. "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes’s self-healing nature, the operations team doesn’t need to do any manual intervention in case of a node or pod failure." On top of that, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it’s finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines. This brings more visibility into the changes being made, and keeping an audit trail."<br><br>
-  Over the next six months, the team worked on migrating all the services from Elastic Beanstalk to Kubernetes, except for the few that were deprecated and would soon be terminated anyway. The services were moved one at a time, and their performance was monitored for two to three days each. Today, "We’re completely migrated and we run all new services on Kubernetes," says Singh. <br><br>
-  The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.<br><br>
-  All 30 engineers at Crowdfire were onboarded at once. "I gave an internal talk where I shared the basic components and demoed the usage of kubectl," says Singh. "Everyone was excited and happy about using Kubernetes. Developers have more control and visibility into their applications running in production now. Most of all, they’re happy with the low deploy times and self-healing services." <br><br>
-  And they’re much more productive, too. "Where we used to do about 5 deployments per day," says Singh, "now we’re doing 30+ production and 50+ staging deployments almost every day."
+<p>For most content creators, only half of that movie quote may ring true. Sure, platforms like Wordpress, YouTube and Shopify have made it simple for almost anyone to start publishing new content online, but attracting an audience isn't as easy. Crowdfire "helps users publish their content to all possible places where their audience exists," says Amanpreet Singh, a Software Engineer at the company based in Mumbai, India. Crowdfire has gained more than 16 million users—from bloggers and artists to makers and small businesses—since its launch in 2010.</p>
 
+<p>With that kind of growth—and a high demand from users for new features and continuous improvements—the Crowdfire team struggled to keep up behind the scenes. In 2015, they moved their monolith Java application to Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a> and started breaking it down into microservices.</p>
 
-</div>
-</section>
-<div class="banner5">
-  <div class="banner5text">
-    The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.
+<p>It was a good first step, but the team soon realized they needed to go further down the cloud-native path, which would lead them to Kubernetes. "It was okay for our use cases initially, but as the number of services and development teams increased and we scaled further, deploy times, self-healing capabilities and resource utilization started to become problematic," says Singh, who leads the infrastructure team at Crowdfire. "We realized that we needed a more cloud-native approach to deal with these issues."</p>
 
-  </div>
-</div>
-<section class="section5">
-<div class="fullcol">
+<p>As he looked around for solutions, Singh had a checklist of what Crowdfire needed. "We wanted to keep some things separate so they could be shipped independent of other things; this would help remove blockers and let different teams work at their own pace," he says. "We also make a lot of data-driven decisions, so shipping a feature and its iterations quickly was a must."</p>
 
-   Singh notes that almost all of the engineers interact with the staging cluster on a daily basis, and that has created a cultural change at Crowdfire. "Developers are more aware of the cloud infrastructure now," he says. "They’ve started following cloud best practices like better health checks, structured logs to stdout [standard output], and config via files or environment variables."<br><br>
-  With Crowdfire’s commitment to Kubernetes, Singh is looking to expand the company’s cloud-native stack. The team already uses <a href="https://prometheus.io/">Prometheus</a> for monitoring, and he says he is evaluating <a href="https://linkerd.io/">Linkerd</a> and <a href="https://envoyproxy.github.io/">Envoy Proxy</a> as a way to "get more metrics about request latencies and failures, and handle them better." Other CNCF projects, including <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://grpc.io/">gRPC</a> are also on his radar.<br><br>
-  Singh has found that the cloud-native community is growing in India, too, particularly in Bangalore. "A lot of startups and new companies are starting to run their infrastructure on Kubernetes," he says. <br><br>
-  And when people ask him about Crowdfire’s experience, he has this advice to offer: "Kubernetes is a great piece of technology, but it might not be right for you, especially if you have just one or two services or your app isn’t easy to run in a containerized environment," he says. "Assess your situation and the value that Kubernetes provides before going all in. If you do decide to use Kubernetes, make sure you understand the components that run under the hood and what role they play in smoothly running the cluster. Another thing to consider is if your apps are ‘Kubernetes-ready,’ meaning if they have proper health checks and handle termination signals to shut down gracefully."<br><br>
-  And if your company fits that profile, go for it. Crowdfire clearly did—and is now reaping the benefits. "In the 15 months that we’ve been using Kubernetes, it has been amazing for us," says Singh. "It enabled us to iterate quickly, increase development speed and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."
+<p>Kubernetes checked all the boxes and then some. "One of the best things was the built-in service discovery," he says. "When you have a bunch of microservices that need to call each other, having internal DNS readily available and service IPs and ports automatically set as environment variables help a lot." Plus, he adds, "Kubernetes's opinionated approach made it easier to get started."</p>
 
+{{< case-studies/quote image="/images/case-studies/crowdfire/banner3.jpg" >}}
+"We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on Terraform and Ansible."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>There was another compelling business reason for the cloud-native approach. "In today's world of ever-changing business requirements, using cloud native technology provides a variety of options to choose from—even the ability to run services in a hybrid cloud environment," says Singh. "Businesses can keep services in a region closest to the users, and thus benefit from high-availability and resiliency."</p>
+
+<p>So in February 2016, Singh set up a test Kubernetes cluster using the kube-up scripts provided. "I explored the features and was able to deploy an application pretty easily," he says. "However, it seemed like a black box since I didn't understand the components completely, and had no idea what the kube-up script did under the hood. So when it broke, it was hard to find the issue and fix it."</p>
+
+<p>To get a better understanding, Singh dove into the internals of Kubernetes, reading the docs and even some of the code. And he looked to the Kubernetes community for more insight. "I used to stay up a little late every night (a lot of users were active only when it's night here in India) and would try to answer questions on the Kubernetes community Slack from users who were getting started," he says. "I would also follow other conversations closely. I must admit I was able to avoid a lot of issues in our setup because I knew others had faced the same issues."</p>
+
+<p>Based on the knowledge he gained, Singh decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>. "I wrote Terraform to launch Kubernetes master and nodes (Auto Scaling Groups) and an Ansible playbook to install the required components," he says. (The company recently switched to using prebaked <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html">AMIs</a> to make the node bringup faster, and is planning to change its networking layer.)</p>
+
+{{< case-studies/quote image="/images/case-studies/crowdfire/banner4.jpg" >}}
+"Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure."
+{{< /case-studies/quote >}}
+
+<p>First, the team migrated a few staging services from Elastic Beanstalk to the new Kubernetes staging cluster, and then set up a production cluster a month later to deploy some services. The results were convincing. "By the end of March 2016, we established that all the new services must be deployed on Kubernetes," says Singh. "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." On top of that, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines. This brings more visibility into the changes being made, and keeping an audit trail."</p>
+
+<p>Over the next six months, the team worked on migrating all the services from Elastic Beanstalk to Kubernetes, except for the few that were deprecated and would soon be terminated anyway. The services were moved one at a time, and their performance was monitored for two to three days each. Today, "We're completely migrated and we run all new services on Kubernetes," says Singh.</p>
+
+<p>The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.</p>
+
+<p>All 30 engineers at Crowdfire were onboarded at once. "I gave an internal talk where I shared the basic components and demoed the usage of kubectl," says Singh. "Everyone was excited and happy about using Kubernetes. Developers have more control and visibility into their applications running in production now. Most of all, they're happy with the low deploy times and self-healing services."</p>
+
+<p>And they're much more productive, too. "Where we used to do about 5 deployments per day," says Singh, "now we're doing 30+ production and 50+ staging deployments almost every day."</p>
+
+{{< case-studies/quote >}}
+The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.
+{{< /case-studies/quote >}}
+
+<p>Singh notes that almost all of the engineers interact with the staging cluster on a daily basis, and that has created a cultural change at Crowdfire. "Developers are more aware of the cloud infrastructure now," he says. "They've started following cloud best practices like better health checks, structured logs to stdout [standard output], and config via files or environment variables."</p>
+
+<p>With Crowdfire's commitment to Kubernetes, Singh is looking to expand the company's cloud-native stack. The team already uses <a href="https://prometheus.io/">Prometheus</a> for monitoring, and he says he is evaluating <a href="https://linkerd.io/">Linkerd</a> and <a href="https://envoyproxy.github.io/">Envoy Proxy</a> as a way to "get more metrics about request latencies and failures, and handle them better." Other CNCF projects, including <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://grpc.io/">gRPC</a> are also on his radar.</p>
+
+<p>Singh has found that the cloud-native community is growing in India, too, particularly in Bangalore. "A lot of startups and new companies are starting to run their infrastructure on Kubernetes," he says.</p>
+
+<p>And when people ask him about Crowdfire's experience, he has this advice to offer: "Kubernetes is a great piece of technology, but it might not be right for you, especially if you have just one or two services or your app isn't easy to run in a containerized environment," he says. "Assess your situation and the value that Kubernetes provides before going all in. If you do decide to use Kubernetes, make sure you understand the components that run under the hood and what role they play in smoothly running the cluster. Another thing to consider is if your apps are 'Kubernetes-ready,' meaning if they have proper health checks and handle termination signals to shut down gracefully."</p>
+
+<p>And if your company fits that profile, go for it. Crowdfire clearly did—and is now reaping the benefits. "In the 15 months that we've been using Kubernetes, it has been amazing for us," says Singh. "It enabled us to iterate quickly, increase development speed and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."</p>
diff --git a/content/en/case-studies/denso/index.html b/content/en/case-studies/denso/index.html
index 27ef1c77ed..31fb1279b9 100644
--- a/content/en/case-studies/denso/index.html
+++ b/content/en/case-studies/denso/index.html
@@ -3,108 +3,80 @@ title: Denso Case Study
 linkTitle: Denso
 case_study_styles: true
 cid: caseStudies
-css: /css/case-studies-gradient.css
 logo: denso_featured_logo.svg
 featured: true
 weight: 4
 quote: >
   We got Kubernetes experts involved on our team, and it dramatically accelerated development speed.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/denso/banner2.jpg
+heading_title_text: Denso
+use_gradient_overlay: true
+subheading: >
+  How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
+case_study_details:
+  - Company: Denso
+  - Location: Japan
+  - Industry: Automotive, Edge
 ---
 
+<h2>Challenge</h2>
 
-<div class="article image overlay" style="background-image: url('/images/case-studies/denso/banner2.jpg')">
-  <h1> CASE STUDY: Denso</h1>
-  <div class="subhead">How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes</div>
-</div>
+<p>DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi.</p>
 
-<div class="details">
-    Company &nbsp;<b>Denso</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Japan</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Automotive, Edge</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="colsgradient">
-  <div class="col1">
-    <h2>Challenge</h2>
-    DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi.
-
-
-    <h2>Solution</h2>
-    Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS).
+<p>Koizumi's team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS).</p>
 
 <h2>Impact</h2>
-    Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.
-</div>
-</section>
-<div class="article image overlay" style="background-image: url('/images/case-studies/denso/banner1.png');">
-  <div class="quotetext">
-    "Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."
-<p><div class="quoteauthortext">- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO</div></p>
-  </div>
-</div>
 
+<p>Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there's a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.</p>
 
-<section class="section2">
-<div class="fullcol">
-  <h4>Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion.
-</h4>
+{{< case-studies/quote
+  image="/images/case-studies/denso/banner1.png"
+  author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO"
+>}}
+"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."
+{{< /case-studies/quote >}}
 
-  <p>The company’s mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.</p>
+{{< case-studies/lead >}}
+Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion.
+{{< /case-studies/lead >}}
 
-  <p>With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver’s preferences. Thus "we need a flexible application platform," he says. </p>
+<p>The company's mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.</p>
+
+<p>With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver's preferences. Thus "we need a flexible application platform," he says.</p>
 
 <p>But working on vehicle edge and vehicle cloud products meant there were several technical challenges: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says Koizumi. "We are tackling these challenges to create an integrated vehicle edge/cloud platform."</p>
 
+{{< case-studies/quote author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO" >}}
+"We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>Koizumi's team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.</p>
 
-<div class="greybanner">
-  <div class="greyquotetext">
-    "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."<p><div class="quoteauthortext">— SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO</div></p>
-  </div>
-</div>
+<p>After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds.</p>
 
-<section class="section3">
-<div class="fullcol">
-   <p>
-    Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.</p>
- <p>
-   After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds. </p>
-  <p>
-  One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."</p>
+<p>One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."</p>
 
-  </p>
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/denso/banner4.jpg"
+  author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO"
+>}}
+"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."
+{{< /case-studies/quote >}}
 
+<p>Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."</p>
 
-  <div class="article image overlay" style="background-image: url('/images/case-studies/denso/banner4.jpg');">
-  <div class="quotetext">
- "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation." <p><div class="quoteauthortext">- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO</div></p>
-  </div>
-</div>
+<p>Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It's like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."</p>
 
-<section class="section5">
-<div class="fullcol">
-   <p>
-  Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."</p>
-  <p>
-  Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It’s like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."</p>
-  <p>
- The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department’s scrum-style development, a new prototype is introduced every week. </p>
-  <p>
- Application portability has also led to greater developer efficiency. "There’s no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform."
-  </p>
-  <p>
-  Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says.
-</p>
-<p>
-Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah’s Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they’re doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture."
-</p>
-<p>
-Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure."
-</p>
-</div>
-</section>
-</body>
+<p>The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there's a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department's scrum-style development, a new prototype is introduced every week.</p>
+
+<p>Application portability has also led to greater developer efficiency. "There's no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform."</p>
+
+<p>Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says.</p>
+
+<p>Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah's Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they're doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture."</p>
+
+<p>Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure."</p>
diff --git a/content/en/case-studies/golfnow/index.html b/content/en/case-studies/golfnow/index.html
index f4bf4d4f27..9e82d90cd1 100644
--- a/content/en/case-studies/golfnow/index.html
+++ b/content/en/case-studies/golfnow/index.html
@@ -1,125 +1,89 @@
 ---
 title: GolfNow Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_golfnow.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/golfnow/banner1.jpg
+heading_title_logo: /images/golfnow_logo.png
+subheading: >
+  Saving Time and Money with Cloud Native Infrastructure
+case_study_details:
+  - Company: GolfNow
+  - Location: Orlando, Florida
+  - Industry: Golf Industry Technology and Services Provider
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/golfnow_logo.png" width="20%" style="margin-bottom:-6px"><br>
-    <div class="subhead">Saving Time and Money with Cloud Native Infrastructure</div>
-  </h1>
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company&nbsp;<b>GolfNow</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location&nbsp;<b>Orlando, Florida</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry&nbsp;<b>Golf Industry Technology and Services Provider</b>
-</div>
+<p>A member of the <a href="http://www.nbcunicareers.com/our-businesses/nbc-sports-group">NBC Sports Group</a>, <a href="https://www.golfnow.com/">GolfNow</a> is the golf industry's technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow's monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow's Director, Architecture. "We wanted the ability to more easily expand globally."</p>
 
-<hr>
+<h2>Solution</h2>
 
-<section class="section1">
-  <div class="cols">
-    <div class="col1">
+<p>Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on <a href="https://www.docker.com/">Docker</a> and <a href="http://kubernetes.io/">Kubernetes.</a></p>
 
-    <h2>Challenge</h2>
-      A member of the <a href="http://www.nbcunicareers.com/our-businesses/nbc-sports-group">NBC Sports Group</a>, <a href="https://www.golfnow.com/">GolfNow</a> is the golf industry’s technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow’s monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow’s Director, Architecture. "We wanted the ability to more easily expand globally."
-      <br>
-  </div>
+<h2>Impact</h2>
 
-  <div class="col2">
-    <h2>Solution</h2>
-      Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on <a href="https://www.docker.com/">Docker</a> and <a href="http://kubernetes.io/">Kubernetes.</a><br><br>
+<p>The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.</p>
 
-    <h2>Impact</h2>
-      The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.
-    </div>
-  </div>
-</section>
+{{< case-studies/quote author="SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW" >}}
+"With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."
+{{< /case-studies/quote >}}
 
+{{< case-studies/lead >}}
+It's not every day that you can say you've slashed an operating expense by half.
+{{< /case-studies/lead >}}
 
-<div class="banner2">
-  <div class="banner2text">
-      "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."<br><br><span style="font-size:15px;letter-spacing:0.08em">- SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW</span>
-  </div>
-</div>
+<p>But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, <a href="https://www.golfnow.com/">GolfNow</a>, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.</p>
 
-<section class="section2">
-  <div class="fullcol">
-      <h2>It’s not every day that you can say you’ve slashed an operating expense by half.</h2>
+<p>A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow's Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we'd have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."</p>
 
-      But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, <a href="https://www.golfnow.com/">GolfNow</a>, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.
-      <br> <br>
-      A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow’s Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we’d have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."
-      <br> <br>
-      In moving just the first of GolfNow’s important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.
-      <br> <br>
-      The path to those stellar results began in late 2014. In order to support GolfNow’s global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from <a href="https://www.microsoft.com/net">C#.NET</a> and <a href="https://www.microsoft.com/en-cy/sql-server/sql-server-2016">SQL Server</a> since it didn’t run very well on Linux, where everything container was running smoothly."
-      <br> <br>
-      To that end, the team shifted to working with <a href="https://nodejs.org/">Node.js</a>, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and <a href="https://www.mongodb.com/">MongoDB</a>, the open-source database program. At the time, <a href="https://www.docker.com/">Docker</a>, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that’s the way the industry is heading."
-  </div>
-</section>
+<p>In moving just the first of GolfNow's important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all.'"
-  </div>
-</div>
+<p>The path to those stellar results began in late 2014. In order to support GolfNow's global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from <a href="https://www.microsoft.com/net">C#.NET</a> and <a href="https://www.microsoft.com/en-cy/sql-server/sql-server-2016">SQL Server</a> since it didn't run very well on Linux, where everything container was running smoothly."</p>
 
-<section class="section3">
-  <div class="fullcol">
-    GolfNow’s dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? ‘It worked on my machine!’ But then we started getting to the point of, ‘How do we make sure that these things stay up and running?’" <br><br>
-    That led the team on a quest to find the right orchestration system for the company’s needs. Sheriff says the first few options they tried were either too heavy or "didn’t feel quite right." In late summer 2015, they discovered the just-released <a href="http://kubernetes.io/">Kubernetes</a>, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."
-    <br><br>
-    But before they could go with Kubernetes, <a href="http://www.nbc.com/">NBC</a>, GolfNow’s parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company’s platform user interface, but didn’t like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff’s VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who’s now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company’s platform.
-    <br><br>
-    "We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."
-    <br><br>
-    At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, ‘Alright, it’s over. Kubernetes wins.’"
-    <br><br>
-    The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn’t quite finished yet. At the time, it was running in <a href="https://devcenter.heroku.com/articles/mongohq">Heroku Compose</a> and other third-party services—resulting in a large monthly bill.
+<p>To that end, the team shifted to working with <a href="https://nodejs.org/">Node.js</a>, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and <a href="https://www.mongodb.com/">MongoDB</a>, the open-source database program. At the time, <a href="https://www.docker.com/">Docker</a>, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that's the way the industry is heading."</p>
 
-  </div>
-</section>
+{{< case-studies/quote image="/images/case-studies/golfnow/banner3.jpg" >}}
+"The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn't have to pay extra money at all.'"
+{{< /case-studies/quote >}}
 
-  <div class="banner4">
-    <div class="banner4text">
-    "'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night.'"
-    </div>
-  </div>
+<p>GolfNow's dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? 'It worked on my machine!' But then we started getting to the point of, 'How do we make sure that these things stay up and running?'"</p>
 
-<section class="section4">
-  <div class="fullcol">
-    "The goal was to take all of that out and put it within this new platform we’ve created with Kubernetes on <a href="https://cloud.google.com/compute/">Google Compute Engine (GCE)</a>," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We’d take the config, change it and make it hit the database that was running in our cluster."
-    <br><br>
-    Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."
-    <br><br>
-    After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all."
-    <br><br>
-    Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night."
-    <br><br>
-    A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into <a href="https://www.microsoft.com/net/core">.NET Core</a> [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.
-    <br><br>
-    Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with <a href="https://github.com/drone/drone">Drone</a>, an open-source continuous delivery platform, to make it more developer-centric. "Now they’re able to manage configuration, they’re able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."
+<p>That led the team on a quest to find the right orchestration system for the company's needs. Sheriff says the first few options they tried were either too heavy or "didn't feel quite right." In late summer 2015, they discovered the just-released <a href="http://kubernetes.io/">Kubernetes</a>, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."</p>
 
-  </div>
-</section>
+<p>But before they could go with Kubernetes, <a href="http://www.nbc.com/">NBC</a>, GolfNow's parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company's platform user interface, but didn't like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff's VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who's now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company's platform.</p>
 
-  <div class="banner5">
-    <div class="banner5text">
-    "Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient.'"
-    </div>
-  </div>
+<p>"We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."</p>
 
-<section class="section5">
-  <div class="fullcol">
-    And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We’re actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."
-    <br><br>
-    The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that’s more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We’ve tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you’ve given us."
-    <br><br>
-    Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they’ve learned: "You’ve got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can’t have people who are half in, half out." And if you don’t have buy-in from the get go, proving it out will get you there.
-    <br><br>
-    "This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient."
+<p>At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, 'Alright, it's over. Kubernetes wins.'"</p>
 
-  </div>
-</section>
+<p>The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn't quite finished yet. At the time, it was running in <a href="https://devcenter.heroku.com/articles/mongohq">Heroku Compose</a> and other third-party services—resulting in a large monthly bill.</p>
+
+{{< case-studies/quote image="/images/case-studies/golfnow/banner4.jpg" >}}
+"'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven't come from the Kubernetes world you wouldn't believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn't sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I've been sleeping at night.'"
+{{< /case-studies/quote >}}
+
+<p>"The goal was to take all of that out and put it within this new platform we've created with Kubernetes on <a href="https://cloud.google.com/compute/">Google Compute Engine (GCE)</a>," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We'd take the config, change it and make it hit the database that was running in our cluster."</p>
+
+<p>Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."</p>
+
+<p>After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn't have to pay extra money at all."</p>
+
+<p>Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven't come from the Kubernetes world you wouldn't believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn't sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I've been sleeping at night."</p>
+
+<p>A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into <a href="https://www.microsoft.com/net/core">.NET Core</a> [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.</p>
+
+<p>Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with <a href="https://github.com/drone/drone">Drone</a>, an open-source continuous delivery platform, to make it more developer-centric. "Now they're able to manage configuration, they're able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."</p>
+
+{{< case-studies/quote >}}
+"Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They're faster, they're more resilient.'"
+{{< /case-studies/quote >}}
+
+<p>And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We're actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."</p>
+
+<p>The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that's more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We've tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you've given us."</p>
+
+<p>Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they've learned: "You've got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can't have people who are half in, half out." And if you don't have buy-in from the get go, proving it out will get you there.</p>
+
+<p>"This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They're faster, they're more resilient."</p>
diff --git a/content/en/case-studies/haufegroup/index.html b/content/en/case-studies/haufegroup/index.html
index f4256ff569..580a282683 100644
--- a/content/en/case-studies/haufegroup/index.html
+++ b/content/en/case-studies/haufegroup/index.html
@@ -1,112 +1,85 @@
 ---
 title: Haufe Group Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_haufegroup.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/haufegroup/banner1.jpg
+heading_title_logo: /images/haufegroup_logo.png
+subheading: >
+  Paving the Way for Cloud Native for Midsize Companies
+case_study_details:
+  - Company: Haufe Group
+  - Location: Freiburg, Germany
+  - Industry: Media and Software
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/haufegroup_logo.png" class="header_logo"><br> <div class="subhead">Paving the Way for Cloud Native for Midsize Companies</div></h1>
+<p>Founded in 1930 as a traditional publisher, Haufe Group has grown into a media and software company with 95 percent of its sales from digital products. Over the years, the company has gone from having "hardware in the basement" to outsourcing its infrastructure operations and IT. More recently, the development of new products, from Internet portals for tax experts to personnel training software, has created demands for increased speed, reliability and scalability. "We need to be able to move faster," says Solution Architect Martin Danielsson. "Adapting workloads is something that we really want to be able to do."</p>
 
-</div>
+<h2>Solution</h2>
+<p>Haufe Group began its cloud-native journey when <a href="https://azure.microsoft.com/">Microsoft Azure</a> became available in Europe; the company needed cloud deployments for its desktop apps with bandwidth-heavy download services. "After that, it has been different projects trying out different things," says Danielsson. Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy.</p>
 
-<div class="details">
-    Company &nbsp;<b>Haufe Group</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Freiburg, Germany</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Media and Software</b>
-</div>
+<p>A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. The company is now getting ready to go live with two services in production using <a href="https://kubernetes.io/">Kubernetes</a> orchestration on <a href="https://azure.microsoft.com/">Microsoft Azure</a> and <a href="https://aws.amazon.com/">Amazon Web Services</a>. The team is also working on breaking up one of their core Java Enterprise desktop products into microservices to allow for better evolvability and dynamic scaling in the cloud.</p>
 
-<hr>
-
-<section class="section1">
-
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        Founded in 1930 as a traditional publisher, Haufe Group has grown into a media and software company with 95 percent of its sales from digital products. Over the years, the company has gone from having "hardware in the basement" to outsourcing its infrastructure operations and IT. More recently, the development of new products, from Internet portals for tax experts to personnel training software, has created demands for increased speed, reliability and scalability. "We need to be able to move faster," says Solution Architect Martin Danielsson. "Adapting workloads is something that we really want to be able to do."
-    <br>
-    <br>
-      <h2>Solution</h2>
-      Haufe Group began its cloud-native journey when <a href="https://azure.microsoft.com/">Microsoft Azure</a> became available in Europe; the company needed cloud deployments for its desktop apps with bandwidth-heavy download services. "After that, it has been different projects trying out different things," says Danielsson. Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy.
-      </div>
-<div class="col2">
-  A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. The company is now getting ready to go live with two services in production using <a href="https://kubernetes.io/">Kubernetes</a> orchestration on <a href="https://azure.microsoft.com/">Microsoft Azure</a> and <a href="https://aws.amazon.com/">Amazon Web Services</a>. The team is also working on breaking up one of their core Java Enterprise desktop products into microservices to allow for better evolvability and dynamic scaling in the cloud.
-<br>
-<br>
 <h2>Impact</h2>
-        With the ability to adapt workloads, Danielsson says, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." Plus, shorter release times have had a major impact. "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," he says. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."
+<p>With the ability to adapt workloads, Danielsson says, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." Plus, shorter release times have had a major impact. "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," he says. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."</p>
 
-</div>
-</div>
+{{< case-studies/quote author="Martin Danielsson, Solution Architect, Haufe Group" >}}
+"Over the next couple of years, people won't even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution."
+{{< /case-studies/quote >}}
 
-</section>
+{{< case-studies/lead >}}
+More than 80 years ago, Haufe Group was founded as a traditional publishing company, printing books and commentary on paper.
+{{< /case-studies/lead >}}
 
-<div class="banner2">
-  <div class="banner2text">
-     "Over the next couple of years, people won’t even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Martin Danielsson, Solution Architect, Haufe Group</span>
-  </div>
-</div>
+<p>By the 1990s, though, the company's leaders recognized that the future was digital, and to their credit, were able to transform Haufe Group into a media and software business that now gets 95 percent of its sales from digital products. "Among the German companies doing this, we were one of the early adopters," says Martin Danielsson, Solution Architect for Haufe Group.</p>
 
-<section class="section2">
+<p>And now they're leading the way for midsize companies embracing cloud-native technology like Kubernetes. "The really big companies like Ticketmaster and Google get it right, and the startups get it right because they're faster," says Danielsson. "We're in this big lump of companies in the middle with a lot of legacy, a lot of structure, a lot of culture that does not easily fit the cloud technologies. We're just 1,500 people, but we have hundreds of customer-facing applications. So we're doing things that will be relevant for many companies of our size or even smaller."</p>
 
-<div class="fullcol">
-    <h2>More than 80 years ago, Haufe Group was founded as a traditional publishing company, printing books and commentary on paper.</h2> By the 1990s, though, the company’s leaders recognized that the future was digital, and to their credit, were able to transform Haufe Group into a media and software business that now gets 95 percent of its sales from digital products. "Among the German companies doing this, we were one of the early adopters," says Martin Danielsson, Solution Architect for Haufe Group.<br><br>
-    And now they’re leading the way for midsize companies embracing cloud-native technology like Kubernetes. "The really big companies like Ticketmaster and Google get it right, and the startups get it right because they’re faster," says Danielsson. "We’re in this big lump of companies in the middle with a lot of legacy, a lot of structure, a lot of culture that does not easily fit the cloud technologies. We’re just 1,500 people, but we have hundreds of customer-facing applications. So we’re doing things that will be relevant for many companies of our size or even smaller."<br><br>
-    Many of those legacy challenges stemmed from simply following the technology trends of the times. "We used to do full DevOps," he says. In the 1990s and 2000s, "that meant that you had your hardware in the basement. And then 10 years ago, the hype of the moment was to outsource application operations, outsource everything, and strip down your IT department to take away the distraction of all these hardware things. That’s not our area of expertise. We didn’t want to be an infrastructure provider. And now comes the backlash of that."<br><br>
-    Haufe Group began feeling the pain as they were developing more new products, from Internet portals for tax experts to personnel training software, that have created demands for increased speed, reliability and scalability. "Right now, we have this break in workflows, where we go from writing concepts to developing, handing it over to production and then handing that over to your host provider," he says. "And then when things go bad we have no clue what went wrong. We definitely want to take back control, and we want to move a lot faster. Adapting workloads is something that we really want to be able to do."<br><br>
-    Those needs led them to explore cloud-native technology. Their first foray into the cloud was doing deployments in <a href="https://azure.microsoft.com/">Microsoft Azure</a>, once it became available in Europe, for desktop products that had built-in download services. Hosting expenses for such bandwidth-heavy services were too high, so the company turned to the cloud. "After that, it has been different projects trying out different things," says Danielsson.
-</div>
-</section>
+<p>Many of those legacy challenges stemmed from simply following the technology trends of the times. "We used to do full DevOps," he says. In the 1990s and 2000s, "that meant that you had your hardware in the basement. And then 10 years ago, the hype of the moment was to outsource application operations, outsource everything, and strip down your IT department to take away the distraction of all these hardware things. That's not our area of expertise. We didn't want to be an infrastructure provider. And now comes the backlash of that."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn’t fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."
-  </div>
-</div>
+<p>Haufe Group began feeling the pain as they were developing more new products, from Internet portals for tax experts to personnel training software, that have created demands for increased speed, reliability and scalability. "Right now, we have this break in workflows, where we go from writing concepts to developing, handing it over to production and then handing that over to your host provider," he says. "And then when things go bad we have no clue what went wrong. We definitely want to take back control, and we want to move a lot faster. Adapting workloads is something that we really want to be able to do."</p>
 
-<section class="section3">
-<div class="fullcol">
+<p>Those needs led them to explore cloud-native technology. Their first foray into the cloud was doing deployments in <a href="https://azure.microsoft.com/">Microsoft Azure</a>, once it became available in Europe, for desktop products that had built-in download services. Hosting expenses for such bandwidth-heavy services were too high, so the company turned to the cloud. "After that, it has been different projects trying out different things," says Danielsson.</p>
 
-      Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy. A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker.
-      Some experiments went further than others; German regulations about sensitive data proved to be a road block in moving some workloads to Azure and Amazon Web Services. "Due to our history, Germany is really strict with things like personally identifiable data," Danielsson says.<br><br>
-      These experiments took on new life with the arrival of the Azure Sovereign Cloud for Germany (an Azure clone run by the German T-Systems provider). With the availability of Azure.de—which conforms to Germany’s privacy regulations—teams started to seriously consider deploying production loads in Docker into the cloud. "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn’t fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."<br><br>
-      In parallel, Danielsson had built an API management system with the aim of supporting CI/CD scenarios, aspects of which were missing in off-the-shelf API management products. With a foundation based on <a href="https://getkong.org/">Mashape’s Kong</a> gateway, it is open-sourced as <a href="http://wicked.haufe.io/">wicked.haufe.io</a>. He put wicked.haufe.io to use with his product team.<br><br> Otherwise, Danielsson says his philosophy was "don’t try to reinvent the wheel all the time. Go for what’s there and 99 percent of the time it will be enough. And if you think you really need something custom or additional, think perhaps once or twice again. One of the things that I find so amazing with this cloud-native framework is that everything ties in."<br><br>
-      Currently, Haufe Group is working on two projects using Kubernetes in production. One is a new mobile application for researching legislation and tax laws. "We needed a way to take out functionality from a legacy core and put an application on top of that with an API gateway—a lot of moving parts that screams containers," says Danielsson. So the team moved the build pipeline away from "deploying to some old, huge machine that you could deploy anything to" and onto a Kubernetes cluster where there would be automatic CI/CD "with feature branches and all these things that were a bit tedious in the past."
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/haufegroup/banner3.jpg" >}}
+"We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn't fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."
+{{< /case-studies/quote >}}
 
-<div class="banner4">
-  <div class="banner4text">
-     "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."
-  </div>
-</div>
+<p>Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy. A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. Some experiments went further than others; German regulations about sensitive data proved to be a road block in moving some workloads to Azure and Amazon Web Services. "Due to our history, Germany is really strict with things like personally identifiable data," Danielsson says.</p>
 
-<section class="section4">
-<div class="fullcol">
-      It was a proof of concept effort, and the proof was in the pudding. "Everyone was really impressed at what we accomplished in a week," says Danielsson. "We did these kinds of integrations just to make sure that we got a handle on how Kubernetes works. If you can create optimism and buzz around something, it’s half won. And if the developers and project managers know this is working, you’re more or less done." Adds Reinhardt: "You need to create some very visible, quick wins in order to overcome the status quo."<br><br>
-      The impact on the speed of deployment was clear: "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days." <br><br>
-      The potential impact on cost was another bonus. "Hosting applications is quite expensive, so moving to the cloud is something that we really want to be able to do," says Danielsson. With the ability to adapt workloads, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." <br><br>
-      Just as importantly, Danielsson says, there’s added flexibility: "When we try to move or rework applications that are really crucial, it’s often tricky to validate whether the path we want to take is going to work out well. In order to validate that, we would need to reproduce the environment and really do testing, and that’s prohibitively expensive and simply not doable with traditional host providers. Cloud native gives us the ability to do risky changes and validate them in a cost-effective way."<br><br>
-      As word of the two successful test projects spread throughout the company, interest in Kubernetes has grown. "We want to be able to support our developers in running Kubernetes clusters but we’re not there yet, so we allow them to do it as long as they’re aware that they are on their own," says Danielsson. "So that’s why we are also looking at things like [the managed Kubernetes platform] <a href="https://coreos.com/tectonic/">CoreOS Tectonic</a>, <a href="https://azure.microsoft.com/en-us/services/container-service/">Azure Container Service</a>, <a href="https://aws.amazon.com/ecs/">ECS</a>, etc. These kinds of services will be a lot more relevant to midsize companies that want to leverage cloud native but don’t have the IT departments or the structure around that."<br><br>
-      In the next year and a half, Danielsson says the company will be working on moving one of their legacy desktop products, a web app for researching legislation and tax laws originally built in Java Enterprise, onto cloud-native technology. "We’re doing a microservice split out right now so that we can independently deploy the different parts," he says. The main website, which provides free content for customers, is also moving to cloud native.
+<p>These experiments took on new life with the arrival of the Azure Sovereign Cloud for Germany (an Azure clone run by the German T-Systems provider). With the availability of Azure.de—which conforms to Germany's privacy regulations—teams started to seriously consider deploying production loads in Docker into the cloud. "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn't fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."</p>
 
-</div>
-</section>
+<p>In parallel, Danielsson had built an API management system with the aim of supporting CI/CD scenarios, aspects of which were missing in off-the-shelf API management products. With a foundation based on <a href="https://getkong.org/">Mashape's Kong</a> gateway, it is open-sourced as <a href="http://wicked.haufe.io/">wicked.haufe.io</a>. He put wicked.haufe.io to use with his product team.<br><br> Otherwise, Danielsson says his philosophy was "don't try to reinvent the wheel all the time. Go for what's there and 99 percent of the time it will be enough. And if you think you really need something custom or additional, think perhaps once or twice again. One of the things that I find so amazing with this cloud-native framework is that everything ties in."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-     "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."
+<p>Currently, Haufe Group is working on two projects using Kubernetes in production. One is a new mobile application for researching legislation and tax laws. "We needed a way to take out functionality from a legacy core and put an application on top of that with an API gateway—a lot of moving parts that screams containers," says Danielsson. So the team moved the build pipeline away from "deploying to some old, huge machine that you could deploy anything to" and onto a Kubernetes cluster where there would be automatic CI/CD "with feature branches and all these things that were a bit tedious in the past."</p>
 
-  </div>
-</div>
+{{< case-studies/quote image="/images/case-studies/haufegroup/banner4.jpg" >}}
+"Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."
+{{< /case-studies/quote >}}
 
-<section class="section5">
-<div class="fullcol">
-  But with these goals, Danielsson believes there are bigger cultural challenges that need to be constantly addressed. The move to new technology, not to mention a shift toward DevOps, means a lot of change for employees. "The roles were rather fixed in the past," he says. "You had developers, you had project leads, you had testers. And now you get into these really, really important things like test automation. Testers aren’t actually doing click testing anymore, and they have to write automated testing. And if you really want to go full-blown CI/CD, all these little pieces have to work together so that you get the confidence to do a check in, and know this check in is going to land in production, because if I messed up, some test is going to break. This is a really powerful thing because whatever you do, whenever you merge something into the trunk or to the master, this is going live. And that’s where you either get the people or they run away screaming."
-  Danielsson understands that it may take some people much longer to get used to the new ways.<br><br>
-  "Culture is nothing that you can force on people," he says. "You have to live it for yourself. You have to evangelize. You have to show the advantages time and time again: This is how you can do it, this is what you get from it." To that end, his team has scheduled daylong workshops for the staff, bringing in outside experts to talk about everything from API to Devops to cloud. <br><br>
-  For every person who runs away screaming, many others get drawn in. "Get that foot in the door and make them really interested in this stuff," says Danielsson. "Usually it catches on. We have people you never would have expected chanting, ‘Docker Docker Docker’ now. It’s cool to see them realize that there is a world outside of their Python libraries. It’s awesome to see them really work with Kubernetes."<br><br>
-  Ultimately, Reinhardt says, "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."
+<p>It was a proof of concept effort, and the proof was in the pudding. "Everyone was really impressed at what we accomplished in a week," says Danielsson. "We did these kinds of integrations just to make sure that we got a handle on how Kubernetes works. If you can create optimism and buzz around something, it's half won. And if the developers and project managers know this is working, you're more or less done." Adds Reinhardt: "You need to create some very visible, quick wins in order to overcome the status quo."</p>
 
-</div>
-</section>
+<p>The impact on the speed of deployment was clear: "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."</p>
+
+<p>The potential impact on cost was another bonus. "Hosting applications is quite expensive, so moving to the cloud is something that we really want to be able to do," says Danielsson. With the ability to adapt workloads, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost."</p>
+
+<p>Just as importantly, Danielsson says, there's added flexibility: "When we try to move or rework applications that are really crucial, it's often tricky to validate whether the path we want to take is going to work out well. In order to validate that, we would need to reproduce the environment and really do testing, and that's prohibitively expensive and simply not doable with traditional host providers. Cloud native gives us the ability to do risky changes and validate them in a cost-effective way."</p>
+
+<p>As word of the two successful test projects spread throughout the company, interest in Kubernetes has grown. "We want to be able to support our developers in running Kubernetes clusters but we're not there yet, so we allow them to do it as long as they're aware that they are on their own," says Danielsson. "So that's why we are also looking at things like [the managed Kubernetes platform] <a href="https://coreos.com/tectonic/">CoreOS Tectonic</a>, <a href="https://azure.microsoft.com/en-us/services/container-service/">Azure Container Service</a>, <a href="https://aws.amazon.com/ecs/">ECS</a>, etc. These kinds of services will be a lot more relevant to midsize companies that want to leverage cloud native but don't have the IT departments or the structure around that."</p>
+
+<p>In the next year and a half, Danielsson says the company will be working on moving one of their legacy desktop products, a web app for researching legislation and tax laws originally built in Java Enterprise, onto cloud-native technology. "We're doing a microservice split out right now so that we can independently deploy the different parts," he says. The main website, which provides free content for customers, is also moving to cloud native.</p>
+
+{{< case-studies/quote >}}
+"the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."
+{{< /case-studies/quote >}}
+
+<p>But with these goals, Danielsson believes there are bigger cultural challenges that need to be constantly addressed. The move to new technology, not to mention a shift toward DevOps, means a lot of change for employees. "The roles were rather fixed in the past," he says. "You had developers, you had project leads, you had testers. And now you get into these really, really important things like test automation. Testers aren't actually doing click testing anymore, and they have to write automated testing. And if you really want to go full-blown CI/CD, all these little pieces have to work together so that you get the confidence to do a check in, and know this check in is going to land in production, because if I messed up, some test is going to break. This is a really powerful thing because whatever you do, whenever you merge something into the trunk or to the master, this is going live. And that's where you either get the people or they run away screaming." Danielsson understands that it may take some people much longer to get used to the new ways.</p>
+
+<p>"Culture is nothing that you can force on people," he says. "You have to live it for yourself. You have to evangelize. You have to show the advantages time and time again: This is how you can do it, this is what you get from it." To that end, his team has scheduled daylong workshops for the staff, bringing in outside experts to talk about everything from API to Devops to cloud.</p>
+
+<p>For every person who runs away screaming, many others get drawn in. "Get that foot in the door and make them really interested in this stuff," says Danielsson. "Usually it catches on. We have people you never would have expected chanting, 'Docker Docker Docker' now. It's cool to see them realize that there is a world outside of their Python libraries. It's awesome to see them really work with Kubernetes."</p>
+
+<p>Ultimately, Reinhardt says, "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."</p>
diff --git a/content/en/case-studies/huawei/index.html b/content/en/case-studies/huawei/index.html
index 29de86f5c4..ec1cd212f2 100644
--- a/content/en/case-studies/huawei/index.html
+++ b/content/en/case-studies/huawei/index.html
@@ -1,101 +1,73 @@
 ---
 title: Huawei Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_huawei.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/huawei/banner1.jpg
+heading_title_logo: /images/huawei_logo.png
+subheading: >
+  Embracing Cloud Native as a User – and a Vendor
+case_study_details:
+  - Company: Huawei
+  - Location: Shenzhen, China
+  - Industry: Telecommunications Equipment
 ---
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/huawei_logo.png" class="header_logo"><br> <div class="subhead">Embracing Cloud Native as a User – and a Vendor</div></h1>
 
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>Huawei</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Shenzhen, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Telecommunications Equipment</b>
-</div>
+<p>A multinational company that's the largest telecommunications equipment manufacturer in the world, Huawei has more than 180,000 employees. In order to support its fast business development around the globe, <a href="http://www.huawei.com/">Huawei</a> has eight data centers for its internal I.T. department, which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. With the rapid increase of new applications, the cost and efficiency of management and deployment of VM-based apps all became critical challenges for business agility. "It's very much a distributed system so we found that managing all of the tasks in a more consistent way is always a challenge," says Peixin Hou, the company's Chief Software Architect and Community Director for Open Source. "We wanted to move into a more agile and decent practice."</p>
 
-<hr>
+<h2>Solution</h2>
 
-<section class="section1">
+<p>After deciding to use container technology, Huawei began moving the internal I.T. department's applications to run on <a href="http://kubernetes.io/">Kubernetes</a>. So far, about 30 percent of these applications have been transferred to cloud native.</p>
 
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        A multinational company that’s the largest telecommunications equipment manufacturer in the world, Huawei has more than 180,000 employees. In order to support its fast business development around the globe, <a href="http://www.huawei.com/">Huawei</a> has eight data centers for its internal I.T. department, which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. With the rapid increase of new applications, the cost and efficiency of management and deployment of VM-based apps all became critical challenges for business agility. "It’s very much a distributed system so we found that managing all of the tasks in a more consistent way is always a challenge," says Peixin Hou, the company’s Chief Software Architect and Community Director for Open Source. "We wanted to move into a more agile and decent practice."
-      </div>
-
-<div class="col2">
-  <h2>Solution</h2>
-      After deciding to use container technology, Huawei began moving the internal I.T. department’s applications to run on <a href="http://kubernetes.io/">Kubernetes</a>. So far, about 30 percent of these applications have been transferred to cloud native.
-<br>
-<br>
 <h2>Impact</h2>
-      "By the end of 2016, Huawei’s internal I.T. department managed more than 4,000 nodes with tens of thousands containers using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou. "The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold." For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent, which we think is very helpful for our business." Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies into <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a>, the PaaS solution it offers its customers.
-</div>
 
-</div>
+<p>"By the end of 2016, Huawei's internal I.T. department managed more than 4,000 nodes with tens of thousands containers using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou. "The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold." For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent, which we think is very helpful for our business." Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies into <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a>, the PaaS solution it offers its customers.</p>
 
-</section>
+{{< case-studies/quote author="Peixin Hou, chief software architect and community director for open source" >}}
+"If you're a vendor, in order to convince your customer, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology."
+{{< /case-studies/quote >}}
 
-<div class="banner2">
-  <div class="banner2text">
-    "If you’re a vendor, in order to convince your customer, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Peixin Hou, chief software architect and community director for open source</span>
-  </div>
-</div>
+<p>Huawei's Kubernetes journey began with one developer. Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested in <a href="http://kubernetes.io/">Kubernetes</a>, the technology for managing application containers across clusters of hosts, and started contributing to its open source community. As the technology developed and the community grew, he kept telling his managers about it.</p>
 
-<section class="section2">
+<p>And as fate would have it, at the same time, Huawei was looking for a better orchestration system for its internal enterprise I.T. department, which supports every business flow processing. "We have more than 180,000 employees worldwide, and a complicated internal procedure, so probably every week this department needs to develop some new applications," says Peixin Hou, Huawei's Chief Software Architect and Community Director for Open Source. "Very often our I.T. departments need to launch tens of thousands of containers, with tasks running across thousands of nodes across the world. It's very much a distributed system, so we found that managing all of the tasks in a more consistent way is always a challenge."</p>
 
-<div class="fullcol">
-      Huawei’s Kubernetes journey began with one developer.
-    Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested in <a href="http://kubernetes.io/">Kubernetes</a>, the technology for managing application containers across clusters of hosts, and started contributing to its open source community. As the technology developed and the community grew, he kept telling his managers about it.<br><br>
-    And as fate would have it, at the same time, Huawei was looking for a better orchestration system for its internal enterprise I.T. department, which supports every business flow processing. "We have more than 180,000 employees worldwide, and a complicated internal procedure, so probably every week this department needs to develop some new applications," says Peixin Hou, Huawei’s Chief Software Architect and Community Director for Open Source. "Very often our I.T. departments need to launch tens of thousands of containers, with tasks running across thousands of nodes across the world. It’s very much a distributed system, so we found that managing all of the tasks in a more consistent way is always a challenge."<br><br>
-    In the past, Huawei had used virtual machines to encapsulate applications, but "every time when we start a VM," Hou says, "whether because it’s a new service or because it was a service that was shut down because of some abnormal node functioning, it takes a lot of time."  Huawei turned to containerization, so the timing was right to try Kubernetes. It took a year to adopt that engineer’s suggestion – the process "is not overnight," says Hou – but once in use, he says, "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."<br><br>
-    Hou sees great benefits to the company that come with using this technology: "Kubernetes brings agility, scale-out capability, and DevOps practice to the cloud-based applications," he says. "It provides us with the ability to customize the scheduling architecture, which makes possible the affinity between container tasks that gives greater efficiency. It supports multiple container formats. It has extensive support for various container networking solutions and container storage."
-</div>
-</section>
+<p>In the past, Huawei had used virtual machines to encapsulate applications, but "every time when we start a VM," Hou says, "whether because it's a new service or because it was a service that was shut down because of some abnormal node functioning, it takes a lot of time."  Huawei turned to containerization, so the timing was right to try Kubernetes. It took a year to adopt that engineer's suggestion – the process "is not overnight," says Hou – but once in use, he says, "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."
-  </div>
-</div>
+<p>Hou sees great benefits to the company that come with using this technology: "Kubernetes brings agility, scale-out capability, and DevOps practice to the cloud-based applications," he says. "It provides us with the ability to customize the scheduling architecture, which makes possible the affinity between container tasks that gives greater efficiency. It supports multiple container formats. It has extensive support for various container networking solutions and container storage."</p>
 
-<section class="section3">
-<div class="fullcol">
-      And not least of all, there’s an impact on the bottom line. Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent, which is very helpful for our business."<br><br>
-    Pleased with those initial results, and seeing a demand for cloud native technologies from its customers, Huawei doubled down on Kubernetes. In the spring of 2016, the company became not only a user but also a vendor.<br><br>
-    "We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei’s <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a> PaaS offering. "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them. We’ve started to work with some Chinese banks, and we see a lot of interest from our customers like <a href="http://www.chinamobileltd.com/">China Mobile</a> and <a href="https://www.telekom.com/en">Deutsche Telekom</a>."<br><br>
-    "If you’re just a user, you’re just a user," adds Hou. "But if you’re a vendor, in order to even convince your customers, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology. We provide customer wisdom." While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei’s solutions. It’s a big selling point that most of the public cloud providers now support Kubernetes. "This makes the cross-cloud transition much easier than with other solutions," says Hou.<br><br>
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/huawei/banner3.jpg" >}}
+"Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."
+{{< /case-studies/quote >}}
 
-<div class="banner4">
-  <div class="banner4text">
-    "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them."
-  </div>
-</div>
+<p>And not least of all, there's an impact on the bottom line. Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent, which is very helpful for our business."</p>
 
-<section class="section4">
-<div class="fullcol">
-  Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes, Hou is looking to convince more departments to move over to the cloud native development cycle and practice. "We have a lot of software developers, so we will provide them with our platform as a service solution, our own product," he says. "We would like to see significant cuts in their iteration cycle."<br><br>
-    Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology: "When you start to design the architecture of your application, think about cloud native, think about microservice architecture from the beginning," he says. "I think you will benefit from that."<br><br>
-  But if you already have legacy applications, "start from some microservice-friendly part of those applications first, parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says. "Don’t think from day one that within how many days I want to move the whole architecture, or move everything into microservices. Don’t put that as a kind of target. You should do it in a gradual manner. And I would say for legacy applications, not every piece would be suitable for microservice architecture. No need to force it."<br><br>
-  After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There’s still 20 percent that’s not, but it’s fine. If we can make 80 percent of our workload really be cloud native, to have agility, it’s a much better world at the end of the day."
+<p>Pleased with those initial results, and seeing a demand for cloud native technologies from its customers, Huawei doubled down on Kubernetes. In the spring of 2016, the company became not only a user but also a vendor.</p>
 
-</div>
-</section>
+<p>"We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei's <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a> PaaS offering. "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them. We've started to work with some Chinese banks, and we see a lot of interest from our customers like <a href="http://www.chinamobileltd.com/">China Mobile</a> and <a href="https://www.telekom.com/en">Deutsche Telekom</a>."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "In the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There’s still 20 percent that’s not, but it’s fine. If we can make 80 percent of our workload really be cloud native, to have agility, it’s a much better world at the end of the day."
+<p>"If you're just a user, you're just a user," adds Hou. "But if you're a vendor, in order to even convince your customers, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology. We provide customer wisdom." While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei's solutions. It's a big selling point that most of the public cloud providers now support Kubernetes. "This makes the cross-cloud transition much easier than with other solutions," says Hou.</p>
 
-  </div>
-</div>
-<section class="section5">
-<div class="fullcol">
-  In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes, not least of all the ones that Huawei is contributing to. Huawei engineers have worked on the federation feature (which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling, container networking and storage, and a just-announced technology called <a href="http://containerops.org/">Container Ops</a>, which is a DevOps pipeline engine. "This will put every DevOps job into a container," he explains. "And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes. With that mechanism, we can make the containerized DevOps jobs be created, shared and managed much more easily than before."<br><br>
-  Still, Hou sees this technology as only halfway to its full potential. First and foremost, he’d like to expand the scale it can orchestrate, which is important for supersized companies like Huawei –  as well as some of its customers.<br><br>
-  Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes, Huawei is now a top contributor to the community. "We’ve learned that the more you contribute to the community," he says, "the more you get back."
+{{< case-studies/quote image="/images/case-studies/huawei/banner4.jpg" >}}
+"Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes, Hou is looking to convince more departments to move over to the cloud native development cycle and practice. "We have a lot of software developers, so we will provide them with our platform as a service solution, our own product," he says. "We would like to see significant cuts in their iteration cycle."</p>
+
+<p>Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology: "When you start to design the architecture of your application, think about cloud native, think about microservice architecture from the beginning," he says. "I think you will benefit from that."</p>
+
+<p>But if you already have legacy applications, "start from some microservice-friendly part of those applications first, parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says. "Don't think from day one that within how many days I want to move the whole architecture, or move everything into microservices. Don't put that as a kind of target. You should do it in a gradual manner. And I would say for legacy applications, not every piece would be suitable for microservice architecture. No need to force it."</p>
+
+<p>After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There's still 20 percent that's not, but it's fine. If we can make 80 percent of our workload really be cloud native, to have agility, it's a much better world at the end of the day."</p>
+
+{{< case-studies/quote >}}
+"In the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There's still 20 percent that's not, but it's fine. If we can make 80 percent of our workload really be cloud native, to have agility, it's a much better world at the end of the day."
+{{< /case-studies/quote >}}
+
+<p>In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes, not least of all the ones that Huawei is contributing to. Huawei engineers have worked on the federation feature (which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling, container networking and storage, and a just-announced technology called <a href="http://containerops.org/">Container Ops</a>, which is a DevOps pipeline engine. "This will put every DevOps job into a container," he explains. "And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes. With that mechanism, we can make the containerized DevOps jobs be created, shared and managed much more easily than before."</p>
+
+<p>Still, Hou sees this technology as only halfway to its full potential. First and foremost, he'd like to expand the scale it can orchestrate, which is important for supersized companies like Huawei –  as well as some of its customers.</p>
+
+<p>Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes, Huawei is now a top contributor to the community. "We've learned that the more you contribute to the community," he says, "the more you get back."</p>
diff --git a/content/en/case-studies/ibm/index.html b/content/en/case-studies/ibm/index.html
index e9a78a9443..aa3f108e1c 100644
--- a/content/en/case-studies/ibm/index.html
+++ b/content/en/case-studies/ibm/index.html
@@ -1,108 +1,80 @@
 ---
 title: IBM Case Study
-
 linkTitle: IBM
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: ibm_featured_logo.svg
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ibm/banner1.jpg
+heading_title_logo: /images/ibm_logo.png
+subheading: >
+  Building an Image Trust Service on Kubernetes with Notary and TUF
+case_study_details:
+  - Company: IBM
+  - Location: Armonk, New York
+  - Industry: Cloud Computing
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/ibm/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ibm_logo.png" class="header_logo" style="width:10%"><br> <div class="subhead">Building an Image Trust Service on Kubernetes with Notary and TUF</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p><a href="https://www.ibm.com/cloud/">IBM Cloud</a> offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed <a href="https://kubernetes.io">Kubernetes</a> and containers, to <a href="https://www.cloudfoundry.org">Cloud Foundry</a> platform as a service (PaaS). These runtimes are combined with the power of the company's enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM's Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service.</p>
 
-<div class="details">
-    Company &nbsp;<b>IBM</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Armonk, New York</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Cloud Computing</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:95%">
-    <h2>Challenge</h2>
-        <a href="https://www.ibm.com/cloud/">IBM Cloud</a> offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed <a href="https://kubernetes.io">Kubernetes</a> and containers, to <a href="https://www.cloudfoundry.org">Cloud Foundry</a> platform as a service (PaaS). These runtimes are combined with the power of the company’s enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM’s Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service.
-<br><br>
- <h2>Solution</h2>
-      The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the <a href="https://www.cncf.io">Cloud Native Computing Foundation (CNCF)</a> open source project <a href="https://github.com/theupdateframework/notary">Notary</a>, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM’s trust story, since it makes it possible for users to consume the company’s Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM’s cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they're loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification.
-
-      </div>
-
-<div class="col2" style="width:95%">
+<h2>Solution</h2>
 
+<p>The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the <a href="https://www.cncf.io">Cloud Native Computing Foundation (CNCF)</a> open source project <a href="https://github.com/theupdateframework/notary">Notary</a>, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM's trust story, since it makes it possible for users to consume the company's Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM's cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they're loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification.</p>
 
 <h2>Impact</h2>
-     IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose."
 
+<p>IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose."</p>
 
-</div>
+{{< case-studies/quote author="Michael Hough, a software developer with the IBM Container Registry team" >}}
+"We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-   "We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Michael Hough, a software developer with the IBM Container Registry team</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Docker had already created the Notary project as an implementation of <a href="https://github.com/theupdateframework/specification" style="text-decoration:underline">The Update Framework (TUF)</a>, and this implementation of TUF provided the capabilities for Docker Content Trust.</h2> "After contribution to CNCF of both TUF and Notary, we perceived that it was becoming the de facto standard for image signing in the container ecosystem", says Michael Hough, a software developer with the IBM Cloud Container Registry team.
-<br><br>
-The key reason for selecting Notary was that it was already compatible with the existing authentication stack IBM’s container registry was using. So was the design of TUF, which does not require the registry team to have to enter the business of key management. Both of these were "attractive design decisions that confirmed our choice of Notary," he says.
-<br><br>
-The introduction of Notary to implement image signing capability in IBM Cloud encourages increased security across IBM's cloud platform, "where we expect it will include both the signing of official IBM images as well as expected use by security-conscious enterprise customers," Hough says. "When combined with security policy implementations, we expect an increased use of deployment policies in CI/CD pipelines that allow for fine-grained control of service deployment based on image signers."
-The availability of image signing "is a huge benefit to security-conscious customers who require this level of image provenance and security," Hough says. "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."
+{{< case-studies/lead >}}
+Docker had already created the Notary project as an implementation of <a href="https://github.com/theupdateframework/specification">The Update Framework (TUF)</a>, and this implementation of TUF provided the capabilities for Docker Content Trust.
+{{< /case-studies/lead >}}
 
+<p>"After contribution to CNCF of both TUF and Notary, we perceived that it was becoming the de facto standard for image signing in the container ecosystem", says Michael Hough, a software developer with the IBM Cloud Container Registry team.</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ibm/banner3.jpg')">
-  <div class="banner3text">
-    "Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-    Now that the Notary-implemented service is generally available in IBM’s public cloud as a component of its existing IBM Cloud Container Registry, it is deployed as a highly available service across five IBM Cloud regions. This high-availability deployment has three instances across two zones in each of the five regions, load balanced with failover support. "We have also deployed it with end-to-end TLS support through to our back-end IBM Cloudant persistence storage service," Hough says.
-<br><br>
-    The IBM team has created and open sourced a Kubernetes admission controller called Portieris, which uses Notary signing information combined with customer-defined security policies to control image deployment into their cluster. "We are hoping to drive adoption of Portieris through its use of our Notary offering," Hough says.
-    <br><br>
-    IBM has been a key player in the creation and support of open source foundations, including CNCF. Todd Moore, IBM's vice president of Open Technology, is the current CNCF governing board chair and a number of IBMers are active across many of the CNCF member projects.
+<p>The key reason for selecting Notary was that it was already compatible with the existing authentication stack IBM's container registry was using. So was the design of TUF, which does not require the registry team to have to enter the business of key management. Both of these were "attractive design decisions that confirmed our choice of Notary," he says.</p>
 
+<p>The introduction of Notary to implement image signing capability in IBM Cloud encourages increased security across IBM's cloud platform, "where we expect it will include both the signing of official IBM images as well as expected use by security-conscious enterprise customers," Hough says. "When combined with security policy implementations, we expect an increased use of deployment policies in CI/CD pipelines that allow for fine-grained control of service deployment based on image signers."</p>
 
+<p>The availability of image signing "is a huge benefit to security-conscious customers who require this level of image provenance and security," Hough says. "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ibm/banner4.jpg')">
-  <div class="banner4text">
-     "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span>
-  </div>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ibm/banner3.jpg"
+  author="Michael Hough, a software developer with the IBM Cloud Container Registry team"
+>}}
+"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"
+{{< /case-studies/quote >}}
 
-<section class="section4">
-<div class="fullcol">
-  "Given that, we see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project," Hough says. Because the entire cloud native world is a fast-moving area with many competing vendors and solutions, "we see the CNCF model as an arbiter of openness and fair play across the ecosystem," he says.
-<br><br>
-With both TUF and Notary as part of CNCF, IBM expects there to be standardization around these capabilities beyond just de facto standards for signing and provenance. IBM has determined to not simply consume Notary, but also to contribute to the open source project where applicable. "IBMers have contributed a CouchDB backend to support our use of IBM Cloudant as the persistent store; and are working on generalization of the pkcs11 provider, allowing support of other security hardware devices beyond Yubikey," Hough says.
+<p>Now that the Notary-implemented service is generally available in IBM's public cloud as a component of its existing IBM Cloud Container Registry, it is deployed as a highly available service across five IBM Cloud regions. This high-availability deployment has three instances across two zones in each of the five regions, load balanced with failover support. "We have also deployed it with end-to-end TLS support through to our back-end IBM Cloudant persistence storage service," Hough says.</p>
 
-</div>
-</section>
-<div class="banner5">
-  <div class="banner5text">
-   "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span>
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-The company has used other CNCF projects <a href="https://containerd.io">containerd</a>, <a href="https://www.envoyproxy.io">Envoy</a>, <a href="https://prometheus.io">Prometheus</a>, <a href="https://grpc.io">gRPC</a>, and <a href="https://github.com/containernetworking">CNI</a>, and is looking into <a href="https://github.com/spiffe">SPIFFE</a> and <a href="https://github.com/spiffe/spire">SPIRE</a> as well for potential future use.
-<br><br>
-What advice does Hough have for other companies that are looking to deploy Notary or a cloud native infrastructure?
-<br><br>
-"While this is true for many areas of cloud native infrastructure software, we found that a high-availability, multi-region deployment of Notary requires a solid implementation to handle certificate management and rotation," he says. "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."
+<p>The IBM team has created and open sourced a Kubernetes admission controller called Portieris, which uses Notary signing information combined with customer-defined security policies to control image deployment into their cluster. "We are hoping to drive adoption of Portieris through its use of our Notary offering," Hough says.</p>
 
-</div>
+<p>IBM has been a key player in the creation and support of open source foundations, including CNCF. Todd Moore, IBM's vice president of Open Technology, is the current CNCF governing board chair and a number of IBMers are active across many of the CNCF member projects.</p>
 
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/ibm/banner4.jpg"
+  author="Michael Hough, a software developer with the IBM Cloud Container Registry team"
+>}}
+"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."
+{{< /case-studies/quote >}}
+
+<p>"Given that, we see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project," Hough says. Because the entire cloud native world is a fast-moving area with many competing vendors and solutions, "we see the CNCF model as an arbiter of openness and fair play across the ecosystem," he says.</p>
+
+<p>With both TUF and Notary as part of CNCF, IBM expects there to be standardization around these capabilities beyond just de facto standards for signing and provenance. IBM has determined to not simply consume Notary, but also to contribute to the open source project where applicable. "IBMers have contributed a CouchDB backend to support our use of IBM Cloudant as the persistent store; and are working on generalization of the pkcs11 provider, allowing support of other security hardware devices beyond Yubikey," Hough says.</p>
+
+{{< case-studies/quote author="Michael Hough, a software developer with the IBM Cloud Container Registry team" >}}
+"There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."
+{{< /case-studies/quote >}}
+
+<p>The company has used other CNCF projects <a href="https://containerd.io">containerd</a>, <a href="https://www.envoyproxy.io">Envoy</a>, <a href="https://prometheus.io">Prometheus</a>, <a href="https://grpc.io">gRPC</a>, and <a href="https://github.com/containernetworking">CNI</a>, and is looking into <a href="https://github.com/spiffe">SPIFFE</a> and <a href="https://github.com/spiffe/spire">SPIRE</a> as well for potential future use.</p>
+
+<p>What advice does Hough have for other companies that are looking to deploy Notary or a cloud native infrastructure?</p>
+
+<p>"While this is true for many areas of cloud native infrastructure software, we found that a high-availability, multi-region deployment of Notary requires a solid implementation to handle certificate management and rotation," he says. "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."</p>
diff --git a/content/en/case-studies/ing/index.html b/content/en/case-studies/ing/index.html
index 943daec2de..037ba9775d 100644
--- a/content/en/case-studies/ing/index.html
+++ b/content/en/case-studies/ing/index.html
@@ -5,95 +5,74 @@ case_study_styles: true
 cid: caseStudies
 weight: 50
 featured: true
-css: /css/style_case_studies.css
 quote: >
-  The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that’s quite feasible to us.
+  The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ing/banner1.jpg
+heading_title_logo: /images/ing_logo.png
+subheading: >
+  Driving Banking Innovation with Cloud Native
+case_study_details:
+  - Company: ING
+  - Location: Amsterdam, Netherlands
+  - Industry: Finance
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/ing/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ing_logo.png" style="margin-bottom:-1.5%;" class="header_logo"><br> <div class="subhead"> Driving Banking Innovation with Cloud Native
-</div></h1>
+<p>After undergoing an agile transformation, <a href="https://www.ing.com/">ING</a> realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with <a href="https://www.docker.com/">Docker</a>, Docker Swarm, <a href="https://kubernetes.io/">Kubernetes</a>, <a href="https://mesosphere.com/">Mesos</a>. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>ING</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Amsterdam, Netherlands
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Finance</b>
-</div>
+<p>Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app <a href="https://www.yolt.com/">Yolt</a> in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.</p>
 
-<hr>
-<section class="section1">
-<div class="cols" style="width:85% !important;margin-left:10% !important">
-  <div class="col1" style="width:100% !important;">
-    <h2>Challenge</h2>
-    After undergoing an agile transformation, <a href="https://www.ing.com/">ING</a> realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with <a href="https://www.docker.com/">Docker</a>, Docker Swarm, <a href="https://kubernetes.io/">Kubernetes</a>, <a href="https://mesosphere.com/">Mesos</a>. Well, it’s not really useful for a company to have one hundred wheels, instead of one good wheel.
-<br>
-    <br>
-    <h2>Solution</h2>
-    Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app <a href="https://www.yolt.com/">Yolt</a> in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based&nbsp;platform.
+<h2>Impact</h2>
 
-    <br>
-    </div>
+<p>"Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."</p>
 
-<div class="col2"  style="width:100% !important;padding-right:8%">
-<br>
-  <h2>Impact</h2>
-    "Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."
-  <br>
-</div>
-</div>
-</section>
-  <div class="banner2" style="padding-top:% !important">
-    <div class="banner2text" style="width:70% !important">
-      "The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that’s quite feasible to us."
-      <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Thijs Ebbers, Infrastructure Architect, ING</span>
-    </div>
-  </div>
-<section class="section2">
-<div class="fullcol">
-  <h2>ING has long embraced innovation in banking, launching the internet-based ING Direct in&nbsp;1997. </h2>In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it’s not really useful for a company to have one hundred wheels, instead of one good wheel." <br><br>
-  Looking to standardize the deployment process within the company’s strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."<br><br>
-  They also embraced Docker to address a major pain point in ING’s CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they’ve done the work, the containers get killed again."
+{{< case-studies/quote author="Thijs Ebbers, Infrastructure Architect, ING">}}
+"The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ing/banner3.jpg')">
-  <div class="banner3text">
-  "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."
-  <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Thijs Ebbers, Infrastructure Architect, ING</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex." For that reason, ING has chosen to start on the <a href="https://www.openshift.org/">OpenShift Origin</a> Kubernetes distribution. <br><br>
-  Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."<br><br>
-  The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.
+{{< case-studies/lead >}}
+ING has long embraced innovation in banking, launching the internet-based ING Direct in 1997.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ing/banner4.jpg')">
-  <div class="banner4text">
-    "We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Onno Van der Voort,  Infrastructure Architect, ING</span>
-  </div>
-</div>
+<p>In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel."</p>
 
+<p>Looking to standardize the deployment process within the company's strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."</p>
 
-<div class="fullcol">
-  The team, however, doesn’t see the bank’s back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn’t hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it’s not about how cool this technology is, it’s about finding the right technology and the right approach."<br><br>
-  The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to <a href="https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en">PSD2</a>, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called <a href="https://www.yolt.com/">Yolt</a>, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We’ve been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.
+<p>They also embraced Docker to address a major pain point in ING's CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they've done the work, the containers get killed again."</p>
 
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="banner5">
-  <div class="banner5text">
-Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING</span></div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ing/banner3.jpg"
+  author="Thijs Ebbers, Infrastructure Architect, ING"
+>}}
+"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran. <br><br>
-  The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that’s quite feasible to us."
+<p>Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." For that reason, ING has chosen to start on the <a href="https://www.openshift.org/">OpenShift Origin</a> Kubernetes distribution.</p>
 
-</div>
+<p>Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."</p>
 
-</section>
+<p>The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ing/banner4.jpg"
+  author="Onno Van der Voort,  Infrastructure Architect, ING"
+>}}
+"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex."
+{{< /case-studies/quote >}}
+
+<p>The team, however, doesn't see the bank's back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn't hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it's not about how cool this technology is, it's about finding the right technology and the right approach."</p>
+
+<p>The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to <a href="https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en">PSD2</a>, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called <a href="https://www.yolt.com/">Yolt</a>, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We've been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.</p>
+
+{{< case-studies/quote author="Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING" >}}
+Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology."
+{{< /case-studies/quote >}}
+
+<p>Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran.</p>
+
+<p>The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that's quite feasible to us."</p>
diff --git a/content/en/case-studies/jd-com/index.html b/content/en/case-studies/jd-com/index.html
index aed12fc54b..ae3360216b 100644
--- a/content/en/case-studies/jd-com/index.html
+++ b/content/en/case-studies/jd-com/index.html
@@ -3,95 +3,77 @@ title: JD.com Case Study
 linkTitle: jd-com
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/jdcom/banner1.jpg
+heading_title_logo: /images/jdcom_logo.png
+subheading: >
+  JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale
+case_study_details:
+  - Company: JD.com
+  - Location: Beijing, China
+  - Industry: eCommerce
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/jdcom/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/jdcom_logo.png" class="header_logo" style="width:17%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%">JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale
+<h2>Challenge</h2>
 
-</div></h1>
+<p>With more than 300 million active users and total 2017 revenue of more than $55 billion, <a href="https://corporate.JD.com/home">JD.com</a> is China's largest retailer, and its operations are the epitome of hyperscale. For example, there are more than a trillion images in JD.com's product databases—with 100 million being added daily—and this enormous amount of data needs to be instantly accessible. In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with tens of thousands of nodes running in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," says Liu. "We needed infrastructure for the next five years of development, now."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>JD.com</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Beijing, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>eCommerce</b>
-</div>
+<p>JD.com turned to Kubernetes to accommodate its clusters. At the beginning of 2016, the company began to transition from OpenStack to Kubernetes, and today, JD.com runs the world's largest Kubernetes cluster. "Kubernetes has provided a strong foundation on top of which we have customized the solution to suit our needs as China's largest retailer."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    With more than 300 million active users and total 2017 revenue of more than $55 billion, <a href="https://corporate.JD.com/home">JD.com</a> is China’s largest retailer, and its operations are the epitome of hyperscale. For example, there are more than a trillion images in JD.com’s product databases—with 100 million being added daily—and this enormous amount of data needs to be instantly accessible. In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com’s Chief Architect. But by the end of 2015, with tens of thousands of nodes running in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," says Liu. "We needed infrastructure for the next five years of development, now."
-
-    <h2>Solution</h2>
-    JD.com turned to Kubernetes to accommodate its clusters. At the beginning of 2016, the company began to transition from OpenStack to Kubernetes, and today, JD.com runs the world’s largest Kubernetes cluster. "Kubernetes has provided a strong foundation on top of which we have customized the solution to suit our needs as China’s largest retailer."
-<br>
 <h2>Impact</h2>
-    "We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform," says Liu. Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. With the further optimizations the team is working on, Liu believes there is the potential to save hundreds of millions of dollars a year. But perhaps the best indication of success was the annual Singles Day shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes’s scalability, we were able to handle an extremely high level of demand."
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable. Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That’s the&nbsp;big&nbsp;win."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAIFENG LIU, CHIEF ARCHITECT, JD.com</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>With more than 300 million active users and $55.7 billion in annual revenues last year, JD.com is China’s largest retailer, and its operations are the epitome of hyperscale.</h2>
-  For example, there are more than a trillion images in JD.com’s product databases for customers, with 100 million being added daily. And this enormous amount of data needs to be instantly accessible to enable a smooth online customer experience.
-<br><br>
-  In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com’s Chief Architect. But by the end of 2015, with hundreds of thousands of nodes in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," Liu adds. "We needed infrastructure for the next five years of development, now."
-<br><br>
-  After considering a number of orchestration technologies, JD.com decided to adopt Kubernetes to accommodate its ever-growing clusters. "The main reason is because Kubernetes can give us more efficient, scalable and much simpler application deployments, plus we can leverage it to do flexible platform scheduling," says Liu.
+<p>"We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform," says Liu. Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. With the further optimizations the team is working on, Liu believes there is the potential to save hundreds of millions of dollars a year. But perhaps the best indication of success was the annual Singles Day shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes's scalability, we were able to handle an extremely high level of demand."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/jdcom/banner3.jpg')">
-  <div class="banner3text">
-    "We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAIFENG LIU, CHIEF ARCHITECT, JD.com</span>
+{{< case-studies/quote author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" >}}
+"Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable. Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That's the big win."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  The fact that Kubernetes is based on Google’s Borg also gave the company confidence. The team liked that Kubernetes has a clear and simple architecture, and that it’s developed mostly in Go, which is a popular language within JD.com.  Though he felt that at the time Kubernetes "was not mature enough," Liu says, "we adopted it anyway."
-<br><br>
-  The team spent a year developing the new container engine platform based on Kubernetes, and at the end of 2016, began promoting it within the company. "We wanted the cluster to be the default way for creating services, so scalability is easier," says Liu. "We talked to developers, interest grew, and we solved problems together." Some of these problems included networking performance and etcd scalability. "But during the past two years, Kubernetes has become more mature and very stable," he adds.
-<br><br>
-  Today, the company runs the world’s largest Kubernetes cluster. "We customized Kubernetes and built a modern system on top of it," says Liu. "This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time. We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform."
+{{< case-studies/lead >}}
+With more than 300 million active users and $55.7 billion in annual revenues last year, JD.com is China's largest retailer, and its operations are the epitome of hyperscale.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/jdcom/banner4.jpg');width:100%">
-  <div class="banner4text">
-  "My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAIFENG LIU, CHIEF ARCHITECT, JD.com</span>
-  </div>
-</div>
+<p>For example, there are more than a trillion images in JD.com's product databases for customers, with 100 million being added daily. And this enormous amount of data needs to be instantly accessible to enable a smooth online customer experience.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  The results are clear: Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. But perhaps the best indication of success was the annual <a href="https://JD.comcorporateblog.com/shoppers-snap-up-quality-and-imported-products-on-JD.com-com-for-record-breaking-singles-day-festival/">Singles Day</a> shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes’s scalability, we were able to handle an extremely high level of demand."
-<br><br>
-  JD.com is now in its second stage with Kubernetes: The platform is already stable, scalable, and flexible, so the focus is on how to run things much more efficiently to further reduce costs. With the optimizations the team is working on with resource management, Liu believes there is the potential to save hundreds of millions of dollars a year.
-<br><br>
-  "We run Kubernetes and container clusters on roughly tens of thousands of physical bare metal nodes," he says. "Using Kubernetes and leveraging our own machine learning pipeline to predict how many resources we need for each application we use, and our own intelligent scaling algorithm, we can improve our resource usage. If we boost the resource usage, for example, by several percent, that means we can reduce huge hardware costs. Then we don’t need that many servers to get that same amount of workload. That can save us a lot of resources."
-</div>
+<p>In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with hundreds of thousands of nodes in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," Liu adds. "We needed infrastructure for the next five years of development, now."</p>
 
-<div class="banner5" style="width:100%">
-  <div class="banner5text">
-"We can share our successful experience with the community, and we also receive good feedback from others. So it’s mutually beneficial."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAIFENG LIU, CHIEF ARCHITECT, JD.com</span></div>
-</div>
+<p>After considering a number of orchestration technologies, JD.com decided to adopt Kubernetes to accommodate its ever-growing clusters. "The main reason is because Kubernetes can give us more efficient, scalable and much simpler application deployments, plus we can leverage it to do flexible platform scheduling," says Liu.</p>
 
-<div class="fullcol">
-  JD.com, which won CNCF’s 2018 End User Award, is also using <a href="https://helm.sh/">Helm</a>, <a href="https://github.com/containernetworking">CNI</a>, <a href="https://goharbor.io/">Harbor</a>, and <a href="https://vitess.io/">Vitess</a> on its platform. JD.com developers have made considerable contributions to Vitess, the CNCF project for scalable MySQL cluster management, and the company hopes to donate its own project to CNCF in the near future. Community participation is a priority for JD.com. "We have a good partnership with this community," says Liu. "We can share our successful experience with the community, and we also receive good feedback from others. So it’s mutually beneficial."
-<br><br>
-  To that end, Liu offers this advice for other companies considering adopting cloud native technology. "First you need to combine this technology with your own businesses, and the second is you need clear goals," he says. "You cannot just use the technology because others are using it. You need to consider your own objectives."
-<br><br>
-  For JD.com’s objectives, these cloud native technologies have been an ideal fit with the company’s own homegrown innovation. "Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable," says Liu. "Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That’s the big win."
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/jdcom/banner3.jpg"
+  author="HAIFENG LIU, CHIEF ARCHITECT, JD.com"
+>}}
+"We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time."
+{{< /case-studies/quote >}}
+
+<p>The fact that Kubernetes is based on Google's Borg also gave the company confidence. The team liked that Kubernetes has a clear and simple architecture, and that it's developed mostly in Go, which is a popular language within JD.com.  Though he felt that at the time Kubernetes "was not mature enough," Liu says, "we adopted it anyway."</p>
+
+<p>The team spent a year developing the new container engine platform based on Kubernetes, and at the end of 2016, began promoting it within the company. "We wanted the cluster to be the default way for creating services, so scalability is easier," says Liu. "We talked to developers, interest grew, and we solved problems together." Some of these problems included networking performance and etcd scalability. "But during the past two years, Kubernetes has become more mature and very stable," he adds.</p>
+
+<p>Today, the company runs the world's largest Kubernetes cluster. "We customized Kubernetes and built a modern system on top of it," says Liu. "This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time. We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/jdcom/banner4.jpg"
+  author="HAIFENG LIU, CHIEF ARCHITECT, JD.com"
+>}}
+"My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives."
+{{< /case-studies/quote >}}
+
+<p>The results are clear: Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. But perhaps the best indication of success was the annual <a href="https://JD.comcorporateblog.com/shoppers-snap-up-quality-and-imported-products-on-JD.com-com-for-record-breaking-singles-day-festival/">Singles Day</a> shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes's scalability, we were able to handle an extremely high level of demand."</p>
+
+<p>JD.com is now in its second stage with Kubernetes: The platform is already stable, scalable, and flexible, so the focus is on how to run things much more efficiently to further reduce costs. With the optimizations the team is working on with resource management, Liu believes there is the potential to save hundreds of millions of dollars a year.</p>
+
+<p>"We run Kubernetes and container clusters on roughly tens of thousands of physical bare metal nodes," he says. "Using Kubernetes and leveraging our own machine learning pipeline to predict how many resources we need for each application we use, and our own intelligent scaling algorithm, we can improve our resource usage. If we boost the resource usage, for example, by several percent, that means we can reduce huge hardware costs. Then we don't need that many servers to get that same amount of workload. That can save us a lot of resources."</p>
+
+{{< case-studies/quote author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" >}}
+"We can share our successful experience with the community, and we also receive good feedback from others. So it's mutually beneficial."
+{{< /case-studies/quote >}}
+
+<p>JD.com, which won CNCF's 2018 End User Award, is also using <a href="https://helm.sh/">Helm</a>, <a href="https://github.com/containernetworking">CNI</a>, <a href="https://goharbor.io/">Harbor</a>, and <a href="https://vitess.io/">Vitess</a> on its platform. JD.com developers have made considerable contributions to Vitess, the CNCF project for scalable MySQL cluster management, and the company hopes to donate its own project to CNCF in the near future. Community participation is a priority for JD.com. "We have a good partnership with this community," says Liu. "We can share our successful experience with the community, and we also receive good feedback from others. So it's mutually beneficial."</p>
+
+<p>To that end, Liu offers this advice for other companies considering adopting cloud native technology. "First you need to combine this technology with your own businesses, and the second is you need clear goals," he says. "You cannot just use the technology because others are using it. You need to consider your own objectives."</p>
+
+<p>For JD.com's objectives, these cloud native technologies have been an ideal fit with the company's own homegrown innovation. "Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable," says Liu. "Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That's the big win."</p>
diff --git a/content/en/case-studies/naic/index.html b/content/en/case-studies/naic/index.html
index 3deb91e480..23955bdef8 100644
--- a/content/en/case-studies/naic/index.html
+++ b/content/en/case-studies/naic/index.html
@@ -1,113 +1,87 @@
 ---
 title: NAIC Case Study
-
 linkTitle: NAIC
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: naic_featured_logo.png
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/naic/banner1.jpg
+heading_title_logo: /images/naic_logo.png
+subheading: >
+  A Culture and Technology Transition Enabled by Kubernetes
+case_study_details:
+  - Company: NAIC
+  - Location: Washington, DC
+  - Industry: Regulatory
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/naic/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/naic_logo.png" class="header_logo" style="width:18%"><br> <div class="subhead" style="margin-top:1%">A Culture and Technology Transition Enabled by Kubernetes</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The <a href="http://www.naic.org/">National Association of Insurance Commissioners (NAIC)</a>, the U.S. standard-setting and regulatory support organization, was looking for a way to deliver new services faster to provide more value for members and staff. It also needed greater agility to improve productivity internally.</p>
 
-<div class="details" style="font-size:1em">
-    Company &nbsp;<b>National Association of Insurance Commissioners (NAIC)</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Washington, DC</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Regulatory</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The <a href="http://www.naic.org/">National Association of Insurance Commissioners (NAIC)</a>, the U.S. standard-setting and regulatory support organization, was looking for a way to deliver new services faster to provide more value for members and staff. It also needed greater agility to improve productivity internally.
-<br><br>
- <h2>Solution</h2>
-     Beginning in 2016, they started using <a href="https://www.cncf.io/">Cloud Native Computing Foundation (CNCF)</a> tools such as <a href="https://prometheus.io/">Prometheus</a>. NAIC began hosting internal systems and development systems on <a href="https://kubernetes.io/">Kubernetes</a> at the beginning of 2018, as part of a broad move toward the public cloud. "Our culture and technology transition is a strategy embraced by our top leaders," says Dan Barker, Chief Enterprise Architect. "It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."
-
-
-
-      </div>
-
-<div class="col2">
+<h2>Solution</h2>
 
+<p>Beginning in 2016, they started using <a href="https://www.cncf.io/">Cloud Native Computing Foundation (CNCF)</a> tools such as <a href="https://prometheus.io/">Prometheus</a>. NAIC began hosting internal systems and development systems on <a href="https://kubernetes.io/">Kubernetes</a> at the beginning of 2018, as part of a broad move toward the public cloud. "Our culture and technology transition is a strategy embraced by our top leaders," says Dan Barker, Chief Enterprise Architect. "It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."</p>
 
 <h2>Impact</h2>
-     Leveraging Kubernetes, "our development teams can create rapid prototypes far faster than they used to," Barker said. Applications running on Kubernetes are more resilient than those running in other environments. The deployment of open source solutions is helping influence company culture, as NAIC becomes a more open and transparent organization.
-    <br><br>
-    "We completed a small prototype in two days that would have previously taken at least a month," Barker says. Resiliency is currently measured in how much downtime systems have. "They’ve basically had none, and the occasional issue is remedied in minutes," he says.
 
+<p>Leveraging Kubernetes, "our development teams can create rapid prototypes far faster than they used to," Barker said. Applications running on Kubernetes are more resilient than those running in other environments. The deployment of open source solutions is helping influence company culture, as NAIC becomes a more open and transparent organization.</p>
 
-</div>
+<p>"We completed a small prototype in two days that would have previously taken at least a month," Barker says. Resiliency is currently measured in how much downtime systems have. "They've basically had none, and the occasional issue is remedied in minutes," he says.</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-   "Our culture and technology transition is a strategy embraced by our top leaders. It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- NAIC—which was created and overseen by the chief insurance regulators from the 50 states, the District of Columbia and five U.S. territories—provides a means through which state insurance regulators establish standards and best practices, conduct peer reviews, and coordinate their regulatory oversight. Their staff supports these efforts and represents the collective views of regulators in the United States and internationally. NAIC members, together with the organization’s central resources, form the national system of state-based insurance regulation in the United States.<br><br>
-The organization has been using the cloud for years, and wanted to find more ways to quickly deliver new services that provide more value for members and staff. They looked to Kubernetes for a solution. Within NAIC, several groups are leveraging Kubernetes, one being the Platform Engineering Team. "The team building out these tools are not only deploying and operating Kubernetes, but they’re also using them," Barker says. "In fact, we’re using GitLab to deploy Kubernetes with a pipeline using <a href="https://github.com/kubernetes/kops">kops</a>. This team was created from developers, operators, and quality engineers from across the company, so their jobs have changed quite a bit."<br><br>
-In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they’re starting to use Kubernetes to deploy simple applications that help their internal processes.
+{{< case-studies/quote author="Dan Barker, Chief Enterprise Architect, NAIC" >}}
+"Our culture and technology transition is a strategy embraced by our top leaders. It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."
+{{< /case-studies/quote >}}
 
+<p>NAIC—which was created and overseen by the chief insurance regulators from the 50 states, the District of Columbia and five U.S. territories—provides a means through which state insurance regulators establish standards and best practices, conduct peer reviews, and coordinate their regulatory oversight. Their staff supports these efforts and represents the collective views of regulators in the United States and internationally. NAIC members, together with the organization's central resources, form the national system of state-based insurance regulation in the United States.</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/naic/banner3.jpg')">
-  <div class="banner3text">
- "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-    "We needed greater agility to enable our own productivity internally," he says. "We decided it was right for us to move everything to the public cloud [Amazon Web Services] to help with that process and be able to access many of the native tools that allows us to move faster by not needing to build everything."
-The NAIC also wanted to be cloud-agnostic, "and Kubernetes helps with this for our compute layer," Barker says. "Compute is pretty standard across the clouds, and now we can take advantage of any of them while getting all of the other features Kubernetes offers."<br><br>
-The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."
-The native integrations into Kubernetes at NAIC has made it easy to write code and have it running in minutes instead of weeks. Applications running on Kubernetes have also proven to be more resilient than those running in other environments. "We even have teams using this to create more internal tools to help with communication or automating some of their current tasks," Barker says.
-<br><br>
-"We knew that Kubernetes had become the de facto standard for container orchestration," he says. "Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."
-<br><br>
-As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes to continue using it moving forward because of the seamless integration with Kubernetes. The Association also is considering <a href="https://grpc.io/">gRPC</a> as its internal communications standard, <a href="https://www.envoyproxy.io/">Envoy</a> in conjunction with Istio for service mesh, <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://www.jaegertracing.io">Jaeger</a> for tracing aggregation, and <a href="https://www.fluentd.org/">Fluentd</a> with its Elasticsearch cluster.
+<p>The organization has been using the cloud for years, and wanted to find more ways to quickly deliver new services that provide more value for members and staff. They looked to Kubernetes for a solution. Within NAIC, several groups are leveraging Kubernetes, one being the Platform Engineering Team. "The team building out these tools are not only deploying and operating Kubernetes, but they're also using them," Barker says. "In fact, we're using GitLab to deploy Kubernetes with a pipeline using <a href="https://github.com/kubernetes/kops">kops</a>. This team was created from developers, operators, and quality engineers from across the company, so their jobs have changed quite a bit."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/naic/banner4.jpg')">
-  <div class="banner4text">
-     "We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
-  </div>
-  </div>
-</div>
+<p>In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they're starting to use Kubernetes to deploy simple applications that help their internal processes.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
+{{< case-studies/quote
+  image="/images/case-studies/naic/banner3.jpg"
+  author="Dan Barker, Chief Enterprise Architect, NAIC"
+>}}
+"In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community."
+{{< /case-studies/quote >}}
 
-The open governance and broad industry participation in CNCF provided a comfort level with the technology, Barker says. "We also see it as helping to influence our own company culture," he says. "We’re moving to be a more open and transparent company, and we are encouraging our staff to get involved with the different working groups and codebases. We recently became CNCF members to help further our commitment to community contribution and transparency."<br><br>
-Factors such as vendor-neutrality and cross-industry investment were important in the selection. "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community," Barker says.<br><br>
-NAIC is a largely Oracle shop, Barker says, and has been running mostly Java on JBoss. "However, we have years of history with other applications," he says. "Some of these have been migrated by completely rewriting the application, while others are just being modified slightly to fit into this new paradigm."<br><br>
-Running on AWS cloud, the Association has not specifically taken a microservices approach. "We are moving to microservices where practical, but we haven’t found that it’s a necessity to operate them within Kubernetes," Barker says<br><br>
-All of its databases are currently running within public cloud services, but they have explored eventually running those in Kubernetes, as it makes sense. "We’re doing this to get more reuse from common components and to limit our failure domains to something more manageable and observable," Barker says.
+<p>"We needed greater agility to enable our own productivity internally," he says. "We decided it was right for us to move everything to the public cloud [Amazon Web Services] to help with that process and be able to access many of the native tools that allows us to move faster by not needing to build everything."
+The NAIC also wanted to be cloud-agnostic, "and Kubernetes helps with this for our compute layer," Barker says. "Compute is pretty standard across the clouds, and now we can take advantage of any of them while getting all of the other features Kubernetes offers."</p>
 
+<p>The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."</p>
 
-</div>
+<p>The native integrations into Kubernetes at NAIC has made it easy to write code and have it running in minutes instead of weeks. Applications running on Kubernetes have also proven to be more resilient than those running in other environments. "We even have teams using this to create more internal tools to help with communication or automating some of their current tasks," Barker says.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
+<p>"We knew that Kubernetes had become the de facto standard for container orchestration," he says. "Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."</p>
 
-  </div>
-</div>
-<div class="fullcol">
+<p>As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes to continue using it moving forward because of the seamless integration with Kubernetes. The Association also is considering <a href="https://grpc.io/">gRPC</a> as its internal communications standard, <a href="https://www.envoyproxy.io/">Envoy</a> in conjunction with Istio for service mesh, <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://www.jaegertracing.io">Jaeger</a> for tracing aggregation, and <a href="https://www.fluentd.org/">Fluentd</a> with its Elasticsearch cluster.</p>
 
-NAIC has seen a significant business impact from its efforts. "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."
-He says the organization is moving toward continuous deployment "because the business case makes sense. The research is becoming very hard to argue with. We want to reduce our batch sizes and optimize on delivering value to customers and not feature count. This is requiring a larger cultural shift than just a technology shift."
-NAIC is "becoming more open and transparent, as well as more resilient to failure," Barker says. "Even our customers are wanting more and more of this and trying to figure out how they can work with us to accomplish our mutual goals faster. Members of the insurance industry have reached out so that we can better learn together and grow as an industry."
+{{< case-studies/quote
+  image="/images/case-studies/naic/banner4.jpg"
+  author="Dan Barker, Chief Enterprise Architect, NAIC"
+>}}
+"We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."
+{{< /case-studies/quote >}}
 
-</div>
+<p>The open governance and broad industry participation in CNCF provided a comfort level with the technology, Barker says. "We also see it as helping to influence our own company culture," he says. "We're moving to be a more open and transparent company, and we are encouraging our staff to get involved with the different working groups and codebases. We recently became CNCF members to help further our commitment to community contribution and transparency."</p>
 
-</section>
+<p>Factors such as vendor-neutrality and cross-industry investment were important in the selection. "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community," Barker says.</p>
+
+<p>NAIC is a largely Oracle shop, Barker says, and has been running mostly Java on JBoss. "However, we have years of history with other applications," he says. "Some of these have been migrated by completely rewriting the application, while others are just being modified slightly to fit into this new paradigm."</p>
+
+<p>Running on AWS cloud, the Association has not specifically taken a microservices approach. "We are moving to microservices where practical, but we haven't found that it's a necessity to operate them within Kubernetes," Barker says.</p>
+
+<p>All of its databases are currently running within public cloud services, but they have explored eventually running those in Kubernetes, as it makes sense. "We're doing this to get more reuse from common components and to limit our failure domains to something more manageable and observable," Barker says.</p>
+
+{{< case-studies/quote author="Dan Barker, Chief Enterprise Architect, NAIC" >}}
+"We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."
+{{< /case-studies/quote >}}
+
+<p>NAIC has seen a significant business impact from its efforts. "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."</p>
+
+<p>He says the organization is moving toward continuous deployment "because the business case makes sense. The research is becoming very hard to argue with. We want to reduce our batch sizes and optimize on delivering value to customers and not feature count. This is requiring a larger cultural shift than just a technology shift."</p>
+
+<p>NAIC is "becoming more open and transparent, as well as more resilient to failure," Barker says. "Even our customers are wanting more and more of this and trying to figure out how they can work with us to accomplish our mutual goals faster. Members of the insurance industry have reached out so that we can better learn together and grow as an industry."</p>
\ No newline at end of file
diff --git a/content/en/case-studies/nav/index.html b/content/en/case-studies/nav/index.html
index bd606e7314..6be206b5e3 100644
--- a/content/en/case-studies/nav/index.html
+++ b/content/en/case-studies/nav/index.html
@@ -1,95 +1,81 @@
 ---
 title: Nav Case Study
-
 linkTitle: Nav
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nav/banner1.jpg
+heading_title_logo: /images/nav_logo.png
+subheading: >
+  How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes
+case_study_details:
+  - Company: Nav
+  - Location: Salt Lake City, Utah, and San Mateo, California
+  - Industry: Financial services for businesses
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/nav/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/nav_logo.png" class="header_logo" style="width:15%"><br> <div class="subhead" style="margin-top:1%">How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>Founded in 2012, <a href="https://www.nav.com/">Nav</a> provides small business owners with access to their business credit scores from all three major commercial credit bureaus—Equifax, Experian and Dun & Bradstreet—and financing options that best fit their needs. Five years in, the startup was growing rapidly, and "our cloud environments were getting very large, and our usage of those environments was extremely low, like under 1%," says Director of Engineering Travis Jeppson. "We wanted our usage of cloud environments to be more tightly coupled with what we actually needed, so we started looking at containerization and orchestration to help us be able to run workloads that were distinct from one another but could share a similar resource pool."</p>
 
-<div class="details">
-    Company &nbsp;<b>Nav</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Salt Lake City, Utah, and San Mateo, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Financial services for businesses</b>
-</div>
+<h2>Solution</h2>
+
+<p>After evaluating a number of orchestration solutions, the Nav team decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> running on <a href="https://aws.amazon.com/">AWS</a>. The strength of the community around Kubernetes was a strong draw, as well as its Google provenance. Plus, "the other solutions tended to be fairly heavy-handed, really complex, really large, and really hard to manage just off the bat," says Jeppson. "Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but also the extensibility of it allowed us to be able to grow with it and be able to build in more features and functionality later on."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%;margin-left:-1.5%">
-<br><br>
-    <h2>Challenge</h2>
-    Founded in 2012, <a href="https://www.nav.com/">Nav</a> provides small business owners with access to their business credit scores from all three major commercial credit bureaus—Equifax, Experian and Dun & Bradstreet—and financing options that best fit their needs. Five years in, the startup was growing rapidly, and “our cloud environments were getting very large, and our usage of those environments was extremely low, like under 1%,” says Director of Engineering Travis Jeppson. “We wanted our usage of cloud environments to be more tightly coupled with what we actually needed, so we started looking at containerization and orchestration to help us be able to run workloads that were distinct from one another but could share a similar resource pool.”
-    <br><br>
-    <h2>Solution</h2>
-    After evaluating a number of orchestration solutions, the Nav team decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> running on <a href="https://aws.amazon.com/">AWS</a>. The strength of the community around Kubernetes was a strong draw, as well as its Google provenance. Plus, “the other solutions tended to be fairly heavy-handed, really complex, really large, and really hard to manage just off the bat,” says Jeppson. “Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but also the extensibility of it allowed us to be able to grow with it and be able to build in more features and functionality later on.”
-    <br><br>
 <h2>Impact</h2>
-    The four-person team got Kubernetes up and running in six months, and the full migration of Nav’s 25 microservices was completed in another six months. The results have been impressive: Resource utilization, which led the company on this path in the first place, has increased from 1% to 40%. Launching a new service used to take two developers two weeks; now it takes only one developer less than 10 minutes. Deployments have increased 5x. And the company is saving 50% in infrastructure costs.
 
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-        <iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
-        <br><br>
-    "Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but also the extensibility of it allowed us to be able to grow with it and be able to build in more features and functionality&nbsp;later&nbsp;on."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson, Director of Engineering, Nav</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Founded in 2012, <a href="https://www.nav.com/">Nav</a> provides small business owners with access to their business credit scores from all three major commercial credit bureaus—Equifax, Experian and Dun & Bradstreet—as well as details on their businesses’ financial health and financing options that best fit their needs. Its mission boils down to this, says Director of Engineering Travis Jeppson: “to increase the success rate of small businesses.”</h2>
-  A couple of years ago, Nav recognized an obstacle in its own path to success. The business was growing rapidly, and “our cloud environments were getting very large, and our usage of those environments was extremely low, like under 1%,” says Jeppson. “Most of the problem was around the ability to scale. We were just throwing money at it. ‘Let’s just spin up more servers. Let’s just do more things in order to handle an increased load.’ And with us being a startup, that could lead to our demise. We don’t have the money to burn on that kind of stuff.”<br><br>
-  Plus, every new service had to go through 10 different people, taking an unacceptably long two weeks to launch. “All of the patch management and the server management was done very manually, and so we all had to watch it and maintain it really well,” adds Jeppson. “It was just a very troublesome system.”
+<p>The four-person team got Kubernetes up and running in six months, and the full migration of Nav's 25 microservices was completed in another six months. The results have been impressive: Resource utilization, which led the company on this path in the first place, has increased from 1% to 40%. Launching a new service used to take two developers two weeks; now it takes only one developer less than 10 minutes. Deployments have increased 5x. And the company is saving 50% in infrastructure costs.</p>
 
+{{< case-studies/quote author="Travis Jeppson, Director of Engineering, Nav" >}}
+<iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<br>
+"Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but also the extensibility of it allowed us to be able to grow with it and be able to build in more features and functionality later on."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nav/banner3.jpg')">
-  <div class="banner3text">
-    "The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson, Director of Engineering, Nav</span>
+{{< case-studies/lead >}}
+Founded in 2012, <a href="https://www.nav.com/">Nav</a> provides small business owners with access to their business credit scores from all three major commercial credit bureaus—Equifax, Experian and Dun & Bradstreet—as well as details on their businesses' financial health and financing options that best fit their needs. Its mission boils down to this, says Director of Engineering Travis Jeppson: "to increase the success rate of small businesses."
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Jeppson had worked with containers at his previous job, and pitched that technology to Nav’s management as a solution to these problems. He got the green light in early 2017. “We wanted our usage of cloud environments to be more tightly coupled with what we actually needed, so we started looking at containerization and orchestration to help us be able to run workloads that were distinct from one another but could share a similar resource pool,” he says.<br><br>
-  After evaluating a number of orchestration solutions, the company decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> running on <a href="https://aws.amazon.com/">AWS</a>. The strength of the community around Kubernetes was a strong draw, as was its Google origins. Additionally, “the other solutions tended to be fairly heavy-handed, really complex, really large, and really hard to manage just off the bat,” says Jeppson. “Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but the extensibility of it would also allow us to grow with it and build in more features and functionality later on.”<br><br>
-  Jeppson’s four-person Engineering Services team got Kubernetes up and running in six months (they decided to use <a href="http://kubespray.io/">Kubespray</a> to spin up clusters), and the full migration of Nav’s 25 microservices and one primary monolith was completed in another six months. “We couldn’t rewrite everything; we couldn’t stop,” he says. “We had to stay up, we had to stay available, and we had to have minimal amount of downtime. So we got really comfortable around our building pipeline, our metrics and logging, and then around Kubernetes itself: how to launch it, how to upgrade it, how to service it. And we moved little by little.”
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nav/banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-  “Kubernetes has brought so much value to Nav by allowing all of these new freedoms that we had just never had before.” <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson, Director of Engineering, Nav</span>
-  </div>
-</div>
+<p>A couple of years ago, Nav recognized an obstacle in its own path to success. The business was growing rapidly, and "our cloud environments were getting very large, and our usage of those environments was extremely low, like under 1%," says Jeppson. "Most of the problem was around the ability to scale. We were just throwing money at it. 'Let's just spin up more servers. Let's just do more things in order to handle an increased load.' And with us being a startup, that could lead to our demise. We don't have the money to burn on that kind of stuff."</p>
 
-<section class="section5" style="padding:0px !important">
+<p>Plus, every new service had to go through 10 different people, taking an unacceptably long two weeks to launch. "All of the patch management and the server management was done very manually, and so we all had to watch it and maintain it really well," adds Jeppson. "It was just a very troublesome system."</p>
 
-<div class="fullcol">
-  A crucial part of the process involved educating Nav’s 50 engineers and being transparent regarding the new workflow as well as the roadmap for the migration. Jeppson did regular presentations along the way, and a week of four-hours-a-day labs for the entire staff of engineers. He then created a repository in <a href="https://gitlab.com/">GitLab</a> to house all of the information. “We showed all the frontend and backend developers how to go in, create their own namespace using <a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>, all themselves,” he says. “Now, a lot of times, they just come to us and say, ‘This is ready.’ We click a little button in GitLab to allow it to release into production, and they’re off to the races.”<br><br>
-  Since the migration was completed in early 2018, the results have been impressive: Resource utilization, which led the company on this path in the first place, has increased from 1% to 40%. Launching a new service used to take two developers two weeks; now it takes only one developer less than 10 minutes. Deployments have increased 5x, from 10 a day to 50 a day. And the company is saving 50% in infrastructure costs on the computational side. “Next we want to go in to address the database side, and once we do that, then we’re going to continue to drop that cost quite a bit more,” says Jeppson.<br><br>
-  Kubernetes has also helped Nav with its compliance needs. Before, “we had to map one application to one server, mostly due to different compliance regulations around data,” Jeppson says. “With the Kubernetes API, we could add in network policies and segregate that data and restrict it if needed.” The company segregates its cluster into an unrestricted zone and a restricted zone, which has its own set of nodes where data protection happens. The company also uses the <a href="https://www.twistlock.com/">Twistlock</a> tool to ensure security, “and that makes it a lot easier to sleep at night,” he adds.
+{{< case-studies/quote
+  image="/images/case-studies/nav/banner3.jpg"
+  author="Travis Jeppson, Director of Engineering, Nav"
+>}}
+"The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we're all facing, and just get help. I like that we're able to tackle the same problems for different reasons but help each other along the way."
+{{< /case-studies/quote >}}
 
-</div>
+<p>Jeppson had worked with containers at his previous job, and pitched that technology to Nav's management as a solution to these problems. He got the green light in early 2017. "We wanted our usage of cloud environments to be more tightly coupled with what we actually needed, so we started looking at containerization and orchestration to help us be able to run workloads that were distinct from one another but could share a similar resource pool," he says.</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-"We’re talking four to 10 times the amount of traffic that we handle now, and it’s just like, 'Oh, yeah. We’re good. Kubernetes handles this for us.'"<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson, Director of Engineering, Nav</span></div>
-</div>
+<p>After evaluating a number of orchestration solutions, the company decided to adopt <a href="https://kubernetes.io/">Kubernetes</a> running on <a href="https://aws.amazon.com/">AWS</a>. The strength of the community around Kubernetes was a strong draw, as was its Google origins. Additionally, "the other solutions tended to be fairly heavy-handed, really complex, really large, and really hard to manage just off the bat," says Jeppson. "Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but the extensibility of it would also allow us to grow with it and build in more features and functionality later on."</p>
 
-<div class="fullcol">
-  With Kubernetes in place, the Nav team also started improving the system’s metrics and logging by adopting <a href="https://prometheus.io/">Prometheus</a>. “Prometheus created a standard around metrics that was really easy for a developer to adopt,” says Jeppson. “They have the freedom to display what they want, to do what they need, and keep their codebase clean, and that to us was absolutely a must.”<br><br>
-  Next up for Nav in the coming year: looking at tracing, storage, and service mesh. They’re currently evaluating <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://opentracing.io/">OpenTracing</a>, and <a href="https://www.jaegertracing.io/">Jaeger</a> after spending much of KubeCon talking to other companies. “The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way,” says Jeppson. “There’s still so, so much to do around scalability, around being able to really fully adopt a cloud native solution.”<br><br>
-  Of course, it all starts with Kubernetes. With that technology, Jeppson’s team has built a platform that allows Nav to scale, and that “has brought so much value to Nav by allowing all of these new freedoms that we had just never had before,” he says. <br><br>
-  Conversations about new products used to be bogged down by the fact they’d have to wait six months to get an environment set up with isolation and then figure out how to handle spikes of traffic. “But now it’s just nothing to us,” says Jeppson. “We’re talking four to 10 times the amount of traffic that we handle now, and it’s just like, ‘Oh, yeah. We’re good. Kubernetes handles this for us.’”
+<p>Jeppson's four-person Engineering Services team got Kubernetes up and running in six months (they decided to use <a href="http://kubespray.io/">Kubespray</a> to spin up clusters), and the full migration of Nav's 25 microservices and one primary monolith was completed in another six months. "We couldn't rewrite everything; we couldn't stop," he says. "We had to stay up, we had to stay available, and we had to have minimal amount of downtime. So we got really comfortable around our building pipeline, our metrics and logging, and then around Kubernetes itself: how to launch it, how to upgrade it, how to service it. And we moved little by little."</p>
 
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/nav/banner4.jpg"
+  author="Travis Jeppson, Director of Engineering, Nav"
+>}}
+"Kubernetes has brought so much value to Nav by allowing all of these new freedoms that we had just never had before."
+{{< /case-studies/quote >}}
+
+<p>A crucial part of the process involved educating Nav's 50 engineers and being transparent regarding the new workflow as well as the roadmap for the migration. Jeppson did regular presentations along the way, and a week of four-hours-a-day labs for the entire staff of engineers. He then created a repository in <a href="https://gitlab.com/">GitLab</a> to house all of the information. "We showed all the frontend and backend developers how to go in, create their own namespace using <a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>, all themselves," he says. "Now, a lot of times, they just come to us and say, 'This is ready.' We click a little button in GitLab to allow it to release into production, and they're off to the races."</p>
+
+<p>Since the migration was completed in early 2018, the results have been impressive: Resource utilization, which led the company on this path in the first place, has increased from 1% to 40%. Launching a new service used to take two developers two weeks; now it takes only one developer less than 10 minutes. Deployments have increased 5x, from 10 a day to 50 a day. And the company is saving 50% in infrastructure costs on the computational side. "Next we want to go in to address the database side, and once we do that, then we're going to continue to drop that cost quite a bit more," says Jeppson.</p>
+
+<p>Kubernetes has also helped Nav with its compliance needs. Before, "we had to map one application to one server, mostly due to different compliance regulations around data," Jeppson says. "With the Kubernetes API, we could add in network policies and segregate that data and restrict it if needed." The company segregates its cluster into an unrestricted zone and a restricted zone, which has its own set of nodes where data protection happens. The company also uses the <a href="https://www.twistlock.com/">Twistlock</a> tool to ensure security, "and that makes it a lot easier to sleep at night," he adds.</p>
+
+{{< case-studies/quote author="Travis Jeppson, Director of Engineering, Nav" >}}
+"We're talking four to 10 times the amount of traffic that we handle now, and it's just like, 'Oh, yeah. We're good. Kubernetes handles this for us.'"
+{{< /case-studies/quote >}}
+
+<p>With Kubernetes in place, the Nav team also started improving the system's metrics and logging by adopting <a href="https://prometheus.io/">Prometheus</a>. "Prometheus created a standard around metrics that was really easy for a developer to adopt," says Jeppson. "They have the freedom to display what they want, to do what they need, and keep their codebase clean, and that to us was absolutely a must."</p>
+
+<p>Next up for Nav in the coming year: looking at tracing, storage, and service mesh. They're currently evaluating <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://opentracing.io/">OpenTracing</a>, and <a href="https://www.jaegertracing.io/">Jaeger</a> after spending much of KubeCon talking to other companies. "The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we're all facing, and just get help. I like that we're able to tackle the same problems for different reasons but help each other along the way," says Jeppson. "There's still so, so much to do around scalability, around being able to really fully adopt a cloud native solution."</p>
+
+<p>Of course, it all starts with Kubernetes. With that technology, Jeppson's team has built a platform that allows Nav to scale, and that "has brought so much value to Nav by allowing all of these new freedoms that we had just never had before," he says.</p>
+
+<p>Conversations about new products used to be bogged down by the fact they'd have to wait six months to get an environment set up with isolation and then figure out how to handle spikes of traffic. "But now it's just nothing to us," says Jeppson. "We're talking four to 10 times the amount of traffic that we handle now, and it's just like, 'Oh, yeah. We're good. Kubernetes handles this for us.'"</p>
diff --git a/content/en/case-studies/nerdalize/index.html b/content/en/case-studies/nerdalize/index.html
index 2756ce431c..d961c0a289 100644
--- a/content/en/case-studies/nerdalize/index.html
+++ b/content/en/case-studies/nerdalize/index.html
@@ -3,94 +3,79 @@ title: Prowise Case Study
 linkTitle: prowise
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nerdalize/banner1.jpg
+heading_title_logo: /images/nerdalize_logo.png
+subheading: >
+  Nerdalize: Providing Affordable and Sustainable Cloud Hosting with Kubernetes
+case_study_details:
+  - Company: Nerdalize
+  - Location: Delft, Netherlands
+  - Industry: Cloud Provider
 ---
-<div class="banner1" style="background-image: url('/images/case-studies/nerdalize/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/nerdalize_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%">Nerdalize: Providing Affordable and Sustainable Cloud Hosting with Kubernetes
-</div></h1>
 
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>Nerdalize</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Delft, Netherlands  </b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Cloud Provider</b>
-</div>
+<p>Nerdalize offers affordable cloud hosting for customers—and free heat and hot water for people who sign up to house the heating devices that contain the company's servers. The savings Nerdalize realizes by not running data centers are passed on to its customers. When the team began using Docker to make its software more portable, it realized it also needed a container orchestration solution. "As a cloud provider, we have internal services for hosting our backends and billing our customers, but we also need to offer our compute to our end users," says Digital Product Engineer Ad van der Veer. "Since we have these heating devices spread across the Netherlands, we need some way of tying that all together."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
+<h2>Solution</h2>
+
+<p>After briefly using a basic scheduling setup with another open source tool, Nerdalize switched to Kubernetes. "On top of our heating devices throughout the Netherlands, we have a virtual machine layer, and on top of that we run Kubernetes clusters for our customers," says van der Veer. "As a small company, we have to provide a rock solid story in terms of the technology. Kubernetes allows us to offer a hybrid solution: 'You can run this on our cloud, but you can run it on other clouds as well. It runs in your internal hardware if you like.' And together with the Docker image standard and our multi-cloud dashboard, that allows them peace of mind."</p>
 
-    <h2>Challenge</h2>
-    Nerdalize offers affordable cloud hosting for customers—and free heat and hot water for people who sign up to house the heating devices that contain the company’s servers. The savings Nerdalize realizes by not running data centers are passed on to its customers. When the team began using Docker to make its software more portable, it realized it also needed a container orchestration solution. “As a cloud provider, we have internal services for hosting our backends and billing our customers, but we also need to offer our compute to our end users,” says Digital Product Engineer Ad van der Veer. “Since we have these heating devices spread across the Netherlands, we need some way of tying that all together.”
-    <h2>Solution</h2>
-    After briefly using a basic scheduling setup with another open source tool, Nerdalize switched to Kubernetes. “On top of our heating devices throughout the Netherlands, we have a virtual machine layer, and on top of that we run Kubernetes clusters for our customers,” says van der Veer. “As a small company, we have to provide a rock solid story in terms of the technology. Kubernetes allows us to offer a hybrid solution: ‘You can run this on our cloud, but you can run it on other clouds as well. It runs in your internal hardware if you like.’ And together with the Docker image standard and our multi-cloud dashboard, that allows them peace of mind.”
 <h2>Impact</h2>
-    Nerdalize prides itself on being a Kubernetes-native cloud provider that charges its customers prices 40% below that of other cloud providers. “Every euro that we have to invest for licensing of software that’s not open source comes from that 40%,” says van der Veer. If they had used a non-open source orchestration platform instead of Kubernetes, “that would reduce this proposition that we have of 40% less cost to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage.” Nerdalize customers also benefit from time savings: One went from spending a day to set up VMs, network, and software, to spinning up a Kubernetes cluster in minutes. And for households using the heating devices, they save an average of 200 euro a year on their heating bill. The environmental impact? The annual reduction in CO2 emissions comes out to be 2 tons per Nerdalize household, which is equivalent to a car driving 8,000 km.
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-  “We can walk into a boardroom and put a Kubernetes logo up, and people accept it as an established technology. It becomes this centerpiece where other cloud native projects can tie in, so there’s a network effect that each project empowers each other. This is something that has a lot of value when we have to talk to customers and convince them that our cloud fits their&nbsp;needs.”
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Nerdalize is a cloud hosting provider that has no data centers. Instead, the four-year-old startup places its servers in homes across the Netherlands, inside heating devices it developed to turn the heat produced by the servers into heating and hot water for the residents.
- </h2>
- “Households save on their gas bills, and cloud users have a much more sustainable cloud solution,” says Maaike Stoops, Customer Experience Queen at Nerdalize. “And we don’t have the overhead of building a data center, so our cloud is up to 40% more affordable.”
-<br><br>
-  That business model has been enabled by the company’s adoption of containerization and Kubernetes. “When we just got started, Docker was just introduced,” says Digital Product Engineer Ad van der Veer. “We began with a very basic bare metal setup, but once we developed the business, we saw that containerization technology was super useful to help our customers. As a cloud provider, we have internal services for hosting our backends and billing our customers, but we also need to offer our compute to our end users. Since we have these heating devices spread across the Netherlands, we need some way of tying that all together.”
-<br><br>
-  After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. “Kubernetes provided us with more functionality out of the gate,” says van der Veer.
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nerdalize/banner3.jpg')">
-  <div class="banner3text">
-    “We always try to get a working version online first, like minimal viable products, and then move to stabilize that,” says van der Veer. “And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes.”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE</span>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  The team first experimented with a basic use case to run customers’ workloads on Kubernetes. “Getting the data working was kind of difficult, and at the time the installation wasn’t that simple,” says van der Veer. “Then CNCF started, we saw the community grow, these problems got solved, and from there it became a very easy decision.”
-<br><br>
-  The first Nerdalize product that was launched in 2017 was “100% containerized and Kubernetes native,” says van der Veer. “On top of our heating devices throughout the Netherlands, we have a virtual machine layer, and on top of that we run Kubernetes clusters for our customers. As a small company, we have to provide a rock solid story in terms of the technology. Kubernetes allows us to offer a hybrid solution: ‘You can run this on our cloud, but you can run it on other clouds as well. It runs in your internal hardware if you like.’ And together with the Docker image standard and our multi-cloud dashboard, that gives them peace of mind.”
-<br><br>
-  Not to mention the 40% cost savings. “Every euro that we have to invest for licensing of software that’s not open source comes from that 40%,” says van der Veer. If Nerdalize had used a non-open source orchestration platform instead of Kubernetes, “that would reduce our cost savings proposition to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage.”
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nerdalize/banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-    “One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud. On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes.”
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE</span>
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Nerdalize now has customers, from individual engineers to data-intensive startups and established companies, all around the world. (For the time being, though, the heating devices are exclusive to the Netherlands.) One of the most common use cases is batch workloads used by data scientists and researchers, and the time savings for these end users is profound. “One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud,” says Stoops. “On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes.”
-<br><br>
-  As for households using the heating devices, they save an average of 200 euro a year on their heating bill. The environmental impact? The annual reduction in CO2 emissions comes out to 2 tons per Nerdalize household, which is equivalent to a car driving 8,000 km.
-<br><br>
-  For the Nerdalize team, feature development—such as the accessible command line interface called Nerd, which recently went live—has also been sped up by Kubernetes. “We always try to get a working version online first, like minimal viable products, and then move to stabilize that,” says van der Veer. “And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes.”
-<br><br>
-  Another unexpected benefit has been the growing influence and reputation of Kubernetes. “We can walk into a boardroom and put a Kubernetes logo up, and people accept it as an established technology,” says van der Veer. “It becomes this centerpiece where other cloud native projects can tie in, so there’s a network effect that each project empowers each other. This is something that has a lot of value when we have to convince customers that our cloud fits their needs.”
-</div>
+<p>Nerdalize prides itself on being a Kubernetes-native cloud provider that charges its customers prices 40% below that of other cloud providers. "Every euro that we have to invest for licensing of software that's not open source comes from that 40%," says van der Veer. If they had used a non-open source orchestration platform instead of Kubernetes, "that would reduce this proposition that we have of 40% less cost to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage." Nerdalize customers also benefit from time savings: One went from spending a day to set up VMs, network, and software, to spinning up a Kubernetes cluster in minutes. And for households using the heating devices, they save an average of 200 euro a year on their heating bill. The environmental impact? The annual reduction in CO2 emissions comes out to be 2 tons per Nerdalize household, which is equivalent to a car driving 8,000 km.</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-“It shouldn’t be too big of a hassle and too large of a commitment. It should be fun and easy for end users. So we really love Kubernetes in that way.”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE</span></div>
-</div>
+{{< case-studies/quote author="AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE" >}}
+"We can walk into a boardroom and put a Kubernetes logo up, and people accept it as an established technology. It becomes this centerpiece where other cloud native projects can tie in, so there's a network effect that each project empowers each other. This is something that has a lot of value when we have to talk to customers and convince them that our cloud fits their needs."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
+{{< case-studies/lead >}}
+Nerdalize is a cloud hosting provider that has no data centers. Instead, the four-year-old startup places its servers in homes across the Netherlands, inside heating devices it developed to turn the heat produced by the servers into heating and hot water for the residents.
+{{< /case-studies/lead >}}
 
-  In fact, Nerdalize is currently looking into implementing other CNCF projects, such as <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://rook.io/">Rook</a>, “which should help us with some of the data problems that we want to solve for our customers,” says van der Veer.
-  <br><br>
-  In the coming year, Nerdalize will scale up the number of households running its hardware to 50, or the equivalent of a small scale data center. Geographic redundancy and greater server ability for customers are two main goals. Spreading the word about Kubernetes is also in the game plan. “We offer a free namespace on our sandbox, multi-tenant Kubernetes cluster for anyone to try,” says van der Veer. “What’s more cool than trying your first Kubernetes project on houses, to warm a shower?”
-  <br><br>
-  Ultimately, this ties into Nerdalize’s mission of supporting affordable and sustainable cloud hosting. “We want to be the disrupter of the cloud space, showing organizations that running in the cloud is easy and affordable,” says Stoops. “It shouldn’t be too big of a hassle and too large of a commitment. It should be fun and easy for end users. So we really love Kubernetes in that way.”
-</div>
+<p>"Households save on their gas bills, and cloud users have a much more sustainable cloud solution," says Maaike Stoops, Customer Experience Queen at Nerdalize. "And we don't have the overhead of building a data center, so our cloud is up to 40% more affordable."</p>
 
-</section>
+<p>That business model has been enabled by the company's adoption of containerization and Kubernetes. "When we just got started, Docker was just introduced," says Digital Product Engineer Ad van der Veer. "We began with a very basic bare metal setup, but once we developed the business, we saw that containerization technology was super useful to help our customers. As a cloud provider, we have internal services for hosting our backends and billing our customers, but we also need to offer our compute to our end users. Since we have these heating devices spread across the Netherlands, we need some way of tying that all together."</p>
+
+<p>After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. "Kubernetes provided us with more functionality out of the gate," says van der Veer.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/nerdalize/banner3.jpg"
+  author="AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE"
+>}}
+"We always try to get a working version online first, like minimal viable products, and then move to stabilize that," says van der Veer. "And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>The team first experimented with a basic use case to run customers' workloads on Kubernetes. "Getting the data working was kind of difficult, and at the time the installation wasn't that simple," says van der Veer. "Then CNCF started, we saw the community grow, these problems got solved, and from there it became a very easy decision."</p>
+
+<p>The first Nerdalize product that was launched in 2017 was "100% containerized and Kubernetes native," says van der Veer. "On top of our heating devices throughout the Netherlands, we have a virtual machine layer, and on top of that we run Kubernetes clusters for our customers. As a small company, we have to provide a rock solid story in terms of the technology. Kubernetes allows us to offer a hybrid solution: 'You can run this on our cloud, but you can run it on other clouds as well. It runs in your internal hardware if you like.' And together with the Docker image standard and our multi-cloud dashboard, that gives them peace of mind."</p>
+
+<p>Not to mention the 40% cost savings. "Every euro that we have to invest for licensing of software that's not open source comes from that 40%," says van der Veer. If Nerdalize had used a non-open source orchestration platform instead of Kubernetes, "that would reduce our cost savings proposition to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/nerdalize/banner4.jpg"
+  author="MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE"
+>}}
+"One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud. On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes."
+{{< /case-studies/quote >}}
+
+<p>Nerdalize now has customers, from individual engineers to data-intensive startups and established companies, all around the world. (For the time being, though, the heating devices are exclusive to the Netherlands.) One of the most common use cases is batch workloads used by data scientists and researchers, and the time savings for these end users is profound. "One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud," says Stoops. "On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes."</p>
+
+<p>As for households using the heating devices, they save an average of 200 euro a year on their heating bill. The environmental impact? The annual reduction in CO2 emissions comes out to 2 tons per Nerdalize household, which is equivalent to a car driving 8,000 km.</p>
+
+<p>For the Nerdalize team, feature development—such as the accessible command line interface called Nerd, which recently went live—has also been sped up by Kubernetes. "We always try to get a working version online first, like minimal viable products, and then move to stabilize that," says van der Veer. "And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes."</p>
+
+<p>Another unexpected benefit has been the growing influence and reputation of Kubernetes. "We can walk into a boardroom and put a Kubernetes logo up, and people accept it as an established technology," says van der Veer. "It becomes this centerpiece where other cloud native projects can tie in, so there's a network effect that each project empowers each other. This is something that has a lot of value when we have to convince customers that our cloud fits their needs."</p>
+
+{{< case-studies/quote author="MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE" >}}
+"It shouldn't be too big of a hassle and too large of a commitment. It should be fun and easy for end users. So we really love Kubernetes in that way."
+{{< /case-studies/quote >}}
+
+<p>In fact, Nerdalize is currently looking into implementing other CNCF projects, such as <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://rook.io/">Rook</a>, "which should help us with some of the data problems that we want to solve for our customers," says van der Veer.</p>
+
+<p>In the coming year, Nerdalize will scale up the number of households running its hardware to 50, or the equivalent of a small scale data center. Geographic redundancy and greater server ability for customers are two main goals. Spreading the word about Kubernetes is also in the game plan. "We offer a free namespace on our sandbox, multi-tenant Kubernetes cluster for anyone to try," says van der Veer. "What's more cool than trying your first Kubernetes project on houses, to warm a shower?"</p>
+
+<p>Ultimately, this ties into Nerdalize's mission of supporting affordable and sustainable cloud hosting. "We want to be the disrupter of the cloud space, showing organizations that running in the cloud is easy and affordable," says Stoops. "It shouldn't be too big of a hassle and too large of a commitment. It should be fun and easy for end users. So we really love Kubernetes in that way."</p>
diff --git a/content/en/case-studies/netease/index.html b/content/en/case-studies/netease/index.html
index 6cba5579ab..3a3a8ab3a7 100644
--- a/content/en/case-studies/netease/index.html
+++ b/content/en/case-studies/netease/index.html
@@ -3,87 +3,74 @@ title: NetEase Case Study
 linkTitle: NetEase
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: netease_featured_logo.png
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/netease/banner1.jpg
+heading_title_logo: /images/netease_logo.png
+subheading: >
+  How NetEase Leverages Kubernetes to Support Internet Business Worldwide
+case_study_details:
+  - Company: NetEase
+  - Location: Hangzhou, China
+  - Industry: Internet technology
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> How NetEase Leverages Kubernetes to Support Internet Business Worldwide</div></h1>
+<p>Its gaming business is one of the largest in the world, but that's not all that <a href="https://netease-na.com/">NetEase</a> provides to Chinese consumers. The company also operates e-commerce, advertising, music streaming, online education, and email platforms; the last of which serves almost a billion users with free email services through sites like <a href="https://www.163.com/">163.com</a>. In 2015, the NetEase Cloud team providing the infrastructure for all of these systems realized that their R&D process was slowing down developers. "Our users needed to prepare all of the infrastructure by themselves," says Feng Changjian, Architect for NetEase Cloud and Container Service. "We were eager to provide the infrastructure and tools for our users automatically via serverless container service."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details" style="font-size:1em">
-    Company &nbsp;<b>NetEase</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Hangzhou, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Internet technology</b>
-</div>
+<p>After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase's scale. "After our 2-to-3-month evaluation, we believed it could satisfy our needs," says Feng. The team started working with Kubernetes in 2015, before it was even 1.0. Today, the NetEase internal cloud platform—which also leverages the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>—runs 10,000 nodes in a production cluster and can support up to 30,000 nodes in a cluster. Based on its learnings from its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="margin-left:-1.5% !important">
-    <h2>Challenge</h2>
-         Its gaming business is one of the largest in the world, but that’s not all that <a href="https://netease-na.com/">NetEase</a> provides to Chinese consumers. The company also operates e-commerce, advertising, music streaming, online education, and email platforms; the last of which serves almost a billion users with free email services through sites like <a href="https://www.163.com/">163.com</a>. In 2015, the NetEase Cloud team providing the infrastructure for all of these systems realized that their R&D process was slowing down developers. “Our users needed to prepare all of the infrastructure by themselves,” says Feng Changjian, Architect for NetEase Cloud and Container Service. “We were eager to provide the infrastructure and tools for our users automatically via serverless container service.”
-<br><br>
- <h2>Solution</h2>
-      After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng. The team started working with Kubernetes in 2015, before it was even 1.0. Today, the NetEase internal cloud platform—which also leverages the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>—runs 10,000 nodes in a production cluster and can support up to 30,000 nodes in a cluster. Based on its learnings from its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers.
-
-
-<br><br>
 <h2>Impact</h2>
-      The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. “In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments,” says Feng. “We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes.” The new platform also allows for mixed deployments using GPU and CPU resources. “Before, if we put all the resources toward the GPU, we won’t have spare resources for the CPU. But now we have improvements thanks to the mixed deployments,” he says. Those improvements have also brought an increase in resource utilization.
-</div>
-</div>
 
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "The system can support 30,000 nodes in a single cluster. In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— Zeng Yuxing, Architect, NetEase</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- <h2>Its gaming business is the <a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">fifth-largest</a> in the world, but that’s not all that <a href="https://netease-na.com/">NetEase</a> provides consumers.</h2>The company also operates e-commerce, advertising, music streaming, online education, and email platforms in China; the last of which serves almost a billion users with free email services through popular sites like <a href="https://www.163.com/">163.com</a> and <a href="https://www.126.com/">126.com</a>. With that kind of scale, the NetEase Cloud team providing the infrastructure for all of these systems realized in 2015 that their R&D process was making it hard for developers to keep up with demand. “Our users needed to prepare all of the infrastructure by themselves,” says Feng Changjian, Architect for NetEase Cloud and Container Service. “We were eager to provide the infrastructure and tools for our users automatically via serverless container service.”<br><br>
- After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng.
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/netease/banner3.jpg')">
-  <div class="banner3text">
-    "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  The team started adopting Kubernetes in 2015, before it was even 1.0, because it was relatively easy to use and enabled DevOps at the company. “We abandoned some of the concepts of Kubernetes; we only wanted to use the standardized framework,” says Feng. “We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment.”<br><br>
-  The team first focused on building the container platform to manage resources better, and then turned their attention to improving its support of microservices by adding internal systems such as monitoring. That has meant integrating the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>. “We are trying to provide a simplified and standardized process, so our users and customers can leverage our best practices,” says Feng.<br><br>
-  And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/netease/banner4.jpg')">
-  <div class="banner4text">
-    "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."
-<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span>
-  </div>
-  </div>
-</div>
+<p>The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. "In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments," says Feng. "We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes." The new platform also allows for mixed deployments using GPU and CPU resources. "Before, if we put all the resources toward the GPU, we won't have spare resources for the CPU. But now we have improvements thanks to the mixed deployments," he says. Those improvements have also brought an increase in resource utilization.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Today, the NetEase internal cloud platform “can support 30,000 nodes in a single cluster,” says Architect Zeng Yuxing. “In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production.” <br><br>
-  The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. “In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments,” says Feng. “We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes.” The new platform also allows for mixed deployments using GPU and CPU resources. “Before, if we put all the resources toward the GPU, we won’t have spare resources for the CPU. But now we have improvements thanks to the mixed deployments.” Those improvements have also brought an increase in resource utilization.
+{{< case-studies/quote author="Zeng Yuxing, Architect, NetEase" >}}
+"The system can support 30,000 nodes in a single cluster. In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."
+{{< /case-studies/quote >}}
 
-</div>
+{{< case-studies/lead >}}
+Its gaming business is the <a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">fifth-largest</a> in the world, but that's not all that <a href="https://netease-na.com/">NetEase</a> provides consumers.
+{{< /case-studies/lead >}}
 
-<div class="banner5">
-  <div class="banner5text">
-  "By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span>
+<p>The company also operates e-commerce, advertising, music streaming, online education, and email platforms in China; the last of which serves almost a billion users with free email services through popular sites like <a href="https://www.163.com/">163.com</a> and <a href="https://www.126.com/">126.com</a>. With that kind of scale, the NetEase Cloud team providing the infrastructure for all of these systems realized in 2015 that their R&D process was making it hard for developers to keep up with demand. "Our users needed to prepare all of the infrastructure by themselves," says Feng Changjian, Architect for NetEase Cloud and Container Service. "We were eager to provide the infrastructure and tools for our users automatically via serverless container service."</p>
 
-  </div>
-</div>
-<div class="fullcol">
-  Based on the results and learnings from using its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. “The idea is that we can find the problems encountered by our game and e-commerce and cloud music providers, so we can integrate their experiences and provide a platform to satisfy the needs of our users,” says Zeng. <br><br>
-  With or without the use of the NetEase product, the team encourages other companies to try Kubernetes. “As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them,” says Kubernetes developer Li Lanqing.<br><br>
-  As an end user as well as a vendor, NetEase has become more involved in the community, learning from other companies and sharing what they’ve done. The team has been contributing to the Harbor and Envoy projects, providing feedback as the technologies are being tested at NetEase scale. “We are a team focusing on addressing the challenges of microservices architecture,” says Feng. “By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved.”
-</div>
-</section>
+<p>After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase's scale. "After our 2-to-3-month evaluation, we believed it could satisfy our needs," says Feng.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/netease/banner3.jpg"
+  author="Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase"
+>}}
+"We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."
+{{< /case-studies/quote >}}
+
+<p>The team started adopting Kubernetes in 2015, before it was even 1.0, because it was relatively easy to use and enabled DevOps at the company. "We abandoned some of the concepts of Kubernetes; we only wanted to use the standardized framework," says Feng. "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."</p>
+
+<p>The team first focused on building the container platform to manage resources better, and then turned their attention to improving its support of microservices by adding internal systems such as monitoring. That has meant integrating the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>. "We are trying to provide a simplified and standardized process, so our users and customers can leverage our best practices," says Feng.</p>
+
+<p>And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/netease/banner4.jpg"
+  author="Li Lanqing, Kubernetes Developer, NetEase"
+>}}
+"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."
+{{< /case-studies/quote >}}
+
+<p>Today, the NetEase internal cloud platform "can support 30,000 nodes in a single cluster," says Architect Zeng Yuxing. "In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."</p>
+
+<p>The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. "In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments," says Feng. "We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes." The new platform also allows for mixed deployments using GPU and CPU resources. "Before, if we put all the resources toward the GPU, we won't have spare resources for the CPU. But now we have improvements thanks to the mixed deployments." Those improvements have also brought an increase in resource utilization.</p>
+
+{{< case-studies/quote author="Li Lanqing, Kubernetes Developer, NetEase">}}
+"By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."
+{{< /case-studies/quote >}}
+
+<p>Based on the results and learnings from using its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. "The idea is that we can find the problems encountered by our game and e-commerce and cloud music providers, so we can integrate their experiences and provide a platform to satisfy the needs of our users," says Zeng.</p>
+
+<p>With or without the use of the NetEase product, the team encourages other companies to try Kubernetes. "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them," says Kubernetes developer Li Lanqing.</p>
+
+<p>As an end user as well as a vendor, NetEase has become more involved in the community, learning from other companies and sharing what they've done. The team has been contributing to the Harbor and Envoy projects, providing feedback as the technologies are being tested at NetEase scale. "We are a team focusing on addressing the challenges of microservices architecture," says Feng. "By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."</p>
diff --git a/content/en/case-studies/newyorktimes/index.html b/content/en/case-studies/newyorktimes/index.html
index 53dbd06a55..74bc5af627 100644
--- a/content/en/case-studies/newyorktimes/index.html
+++ b/content/en/case-studies/newyorktimes/index.html
@@ -2,107 +2,72 @@
 title: New York Times Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/newyorktimes/banner1.jpg
+heading_title_logo: /images/newyorktimes_logo.png
+subheading: >
+  The New York Times: From Print to the Web to Cloud Native
+case_study_details:
+  - Company: New York Times
+  - Location: New York, N.Y.
+  - Industry: News Media
 ---
 
-<div class="banner1" style="padding-left:8% !important;background-image: url('/images/case-studies/newyorktimes/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/newyorktimes_logo.png" class="header_logo"><br> <div class="subhead">The New York Times: From Print to the Web to Cloud Native
+<h2>Challenge</h2>
 
-</div></h1>
+<p>When the company decided a few years ago to move out of its data centers, its first deployments on the public cloud were smaller, less critical applications managed on virtual machines. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center," says Deep Kapadia, Executive Director, Engineering at The New York Times. Kapadia was tapped to lead a Delivery Engineering Team that would "design for the abstractions that cloud providers offer us."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details" style="padding-left:6% !important">
-    Company &nbsp;<b>New York Times</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, N.Y.
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>News Media</b>
-</div>
+<p>The team decided to use <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.</p>
 
-<hr />
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    When the company decided a few years ago to move out of its data centers, its first deployments on the public cloud were smaller, less critical applications managed on virtual machines. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center," says Deep Kapadia, Executive Director, Engineering at The New York Times. Kapadia was tapped to lead a Delivery Engineering Team that would "design for the abstractions that cloud providers offer us."
+<h2>Impact</h2>
 
-    <br><br>
-    <h2>Solution</h2>
-    The team decided to use <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.
-    <br />
-    </div>
+<p>Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.</p>
 
-<div class="col2">
+{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}}
+{{< youtube DqS_IPw-c6o youtube-quote-sm >}}
+{{< youtube Tm4VfJtOHt8 youtube-quote-sm >}}
+"I think once you get over the initial hump, things get a lot easier and actually a lot faster."
+{{< /case-studies/quote >}}
 
-  <h2>Impact</h2>
-  Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.
-  <br />
-</div>
+<p>Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.</p>
 
-</div>
-</section>
-<div class="banner2" style="padding-bottom:0% !important;padding-left:10% !important;">
-    <div class="banner2text" style="width:100% !important;padding-left:5% !important;padding-right:5% !important">
-    <div class="video" style="float:left;width:90%;">
-    <iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-      <iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-    </div>
-  </div>
-  </div>
-  <br><br>
-  <div class="banner2" style="padding-top:10% !important;padding-left:5% !important;">
-    <div class="banner2text" style="padding-top:5% !important">
-<br>
-      "I think once you get over the initial hump, things get a lot easier and actually a lot faster." — Deep Kapadia, Executive Director, Engineering at The&nbsp;New&nbsp;York&nbsp;Times</div>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.<br /><br />
-  At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on <a href="https://aws.amazon.com/">AWS</a> as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."<br /><br />
-  To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.<br /><br />
-  At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"<br /><br />
-  In early 2017, the first production application—the nytimes.com mobile homepage—began running on Kubernetes, serving just 1% of the traffic. Today, almost 100% of the nytimes.com site’s end-user facing applications run on GCP, with the majority on Kubernetes.
+<p>At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on <a href="https://aws.amazon.com/">AWS</a> as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/newyorktimes/banner3.jpg')">
-  <div class="banner3text">
-  "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.</p>
 
-  The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."<br /><br />
-  The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, which has been the main platform for the company’s experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I’m really excited about experimenting with deploying those on App Engine Flex and <a href="https://aws.amazon.com/fargate/">AWS Fargate</a> and seeing how that feels, because that’s a great migration path."<br /><br />
-  There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they’re using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."<br /><br />
-  Kapadia acknowledges that there was a steep learning curve for some engineers, but "I think once you get over the initial hump, things get a lot easier and actually a lot faster."
+<p>At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/newyorktimes/banner4.jpg')">
-  <div class="banner4text">
-    "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
+<p>In early 2017, the first production application—the nytimes.com mobile homepage—began running on Kubernetes, serving just 1% of the traffic. Today, almost 100% of the nytimes.com site's end-user facing applications run on GCP, with the majority on Kubernetes.</p>
 
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  At The New York Times, they did. As teams started sharing their own best practices with each other, "We’re no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We’ve sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, ‘If this works for you as is, great! If not, come talk to us and we’ll figure out how to make it work for you.’"<br /><br />
-  As a result, "It’s really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."<br /><br />
-  Another benefit to adopting Kubernetes: allowing for a more unified approach to deployment across the engineering staff. "Before, many teams were building their own tools for deployment," says Balser. With Kubernetes—as well as the other CNCF projects The New York Times uses, including Fluentd to collect logs for all of its AWS servers, gRPC for its <a href="https://open.nytimes.com/publishing-with-apache-kafka-at-the-new-york-times-7f0e3b7d2077">Publishing Pipeline</a>, Prometheus, and Envoy—"we can benefit from the advances that each of these technologies make, instead of trying to catch up."
+{{< case-studies/quote image="/images/case-studies/newyorktimes/banner3.jpg" >}}
+"We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
+{{< /case-studies/quote >}}
 
-</div>
+<p>The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."</p>
 
-<div class="banner5">
-  <div class="banner5text">
+<p>The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, which has been the main platform for the company's experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I'm really excited about experimenting with deploying those on App Engine Flex and <a href="https://aws.amazon.com/fargate/">AWS Fargate</a> and seeing how that feels, because that's a great migration path."</p>
 
-Li calls the Cloud Native Computing Foundation’s projects "a northern star that we can all look at and follow."
-  </div>
-</div>
+<p>There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they're using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."</p>
 
-<div class="fullcol">
-  These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We’re running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."<br /><br />
-  Li calls the Cloud Native Computing Foundation’s projects "a northern star that we can all look at and follow." Led by that star, the team is looking ahead to a year of onboarding the remaining half of the 40 or so product engineering teams to extract even more value out of the technology. "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
+<p>Kapadia acknowledges that there was a steep learning curve for some engineers, but "I think once you get over the initial hump, things get a lot easier and actually a lot faster."</p>
 
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/newyorktimes/banner4.jpg" >}}
+"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
+{{< /case-studies/quote >}}
+
+<p>At The New York Times, they did. As teams started sharing their own best practices with each other, "We're no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We've sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, 'If this works for you as is, great! If not, come talk to us and we'll figure out how to make it work for you.'"</p>
+
+<p>As a result, "It's really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."</p>
+
+<p>Another benefit to adopting Kubernetes: allowing for a more unified approach to deployment across the engineering staff. "Before, many teams were building their own tools for deployment," says Balser. With Kubernetes—as well as the other CNCF projects The New York Times uses, including Fluentd to collect logs for all of its AWS servers, gRPC for its <a href="https://open.nytimes.com/publishing-with-apache-kafka-at-the-new-york-times-7f0e3b7d2077">Publishing Pipeline</a>, Prometheus, and Envoy—"we can benefit from the advances that each of these technologies make, instead of trying to catch up."</p>
+
+{{< case-studies/quote >}}
+Li calls the Cloud Native Computing Foundation's projects "a northern star that we can all look at and follow."
+{{< /case-studies/quote >}}
+
+<p>These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We're running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."</p>
+
+<p>Li calls the Cloud Native Computing Foundation's projects "a northern star that we can all look at and follow." Led by that star, the team is looking ahead to a year of onboarding the remaining half of the 40 or so product engineering teams to extract even more value out of the technology. "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."</p>
diff --git a/content/en/case-studies/nokia/index.html b/content/en/case-studies/nokia/index.html
index f824685327..0de1426853 100644
--- a/content/en/case-studies/nokia/index.html
+++ b/content/en/case-studies/nokia/index.html
@@ -3,91 +3,75 @@ title: Nokia Case Study
 linkTitle: Nokia
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: nokia_featured_logo.png
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nokia/banner1.jpg
+heading_title_logo: /images/nokia_logo.png
+subheading: >
+  Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes
+case_study_details:
+  - Company: Nokia
+  - Location: Espoo, Finland
+  - Industry: Telecommunications
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/nokia/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/nokia_logo.png" class="header_logo" style="width:20%;margin-bottom:-2.2%"><br> <div class="subhead" style="margin-top:1%">Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes
+<p><a href="https://www.nokia.com/en_int">Nokia</a>'s core business is building telecom networks end-to-end; its main products are related to the infrastructure, such as antennas, switching equipment, and routing equipment. "As telecom vendors, we have to deliver our software to several telecom operators and put the software into their infrastructure, and each of the operators have a bit different infrastructure," says Gergely Csatari, Senior Open Source Engineer. "There are operators who are running on bare metal. There are operators who are running on virtual machines. There are operators who are running on <a href="https://cloud.vmware.com/">VMware Cloud</a> and <a href="https://www.openstack.org/">OpenStack</a> Cloud. We want to run the same product on all of these different infrastructures without changing the product itself."</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
+<p>The company decided that moving to cloud native technologies would allow teams to have infrastructure-agnostic behavior in their products. Teams at Nokia began experimenting with Kubernetes in pre-1.0 versions. "The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes," says Csatari. The first Kubernetes-based product, the <a href="https://networks.nokia.com/products/telecom-application-server">Nokia Telephony Application Server</a>, went live in early 2018. "Now, all the products are doing some kind of re-architecture work, and they're moving to Kubernetes."</p>
 
-<div class="details">
-    Company &nbsp;<b>Nokia</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Espoo, Finland
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Telecommunications</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    <a href="https://www.nokia.com/en_int">Nokia</a>’s core business is building telecom networks end-to-end; its main products are related to the infrastructure, such as antennas, switching equipment, and routing equipment. "As telecom vendors, we have to deliver our software to several telecom operators and put the software into their infrastructure, and each of the operators have a bit different infrastructure," says Gergely Csatari, Senior Open Source Engineer. "There are operators who are running on bare metal. There are operators who are running on virtual machines. There are operators who are running on <a href="https://cloud.vmware.com/">VMware Cloud</a> and <a href="https://www.openstack.org/">OpenStack</a> Cloud. We want to run the same product on all of these different infrastructures without changing the product itself."
-
-    <h2>Solution</h2>
-    The company decided that moving to cloud native technologies would allow teams to have infrastructure-agnostic behavior in their products. Teams at Nokia began experimenting with Kubernetes in pre-1.0 versions. "The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes," says Csatari. The first Kubernetes-based product, the <a href="https://networks.nokia.com/products/telecom-application-server">Nokia Telephony Application Server</a>, went live in early 2018. "Now, all the products are doing some kind of re-architecture work, and they’re moving to Kubernetes."
-<br>
 <h2>Impact</h2>
-    Kubernetes has enabled Nokia’s foray into 5G. "When you develop something that is part of the operator’s infrastructure, you have to develop it for the future, and Kubernetes and containers are the forward-looking technologies," says Csatari. The teams using Kubernetes are already seeing clear benefits. "By separating the infrastructure and the application layer, we have less dependencies in the system, which means that it’s easier to implement features in the application layer," says Csatari. And because teams can test the exact same binary artifact independently of the target execution environment, "we find more errors in early phases of the testing, and we do not need to run the same tests on different target environments, like VMware, OpenStack, or bare metal," he adds. As a result, "we save several hundred hours in every release."
 
-</div>
+<p>Kubernetes has enabled Nokia's foray into 5G. "When you develop something that is part of the operator's infrastructure, you have to develop it for the future, and Kubernetes and containers are the forward-looking technologies," says Csatari. The teams using Kubernetes are already seeing clear benefits. "By separating the infrastructure and the application layer, we have less dependencies in the system, which means that it's easier to implement features in the application layer," says Csatari. And because teams can test the exact same binary artifact independently of the target execution environment, "we find more errors in early phases of the testing, and we do not need to run the same tests on different target environments, like VMware, OpenStack, or bare metal," he adds. As a result, "we save several hundred hours in every release."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "When people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Nokia was the first name in mobile phones when they were becoming ubiquitous in the late 1990s and early 2000s. But by 2014, the company had sold off its mobile device division and was focusing its core business not on the handhelds used for calls, but on the networks.</h2>
-  Today, Nokia is building telecom networks end-to-end—from antennas to switching and routing equipment—serving operators in more than 120 countries. "As telecom vendors, we have to deliver our software to several telecom operators and put the software into their infrastructure, and each of the operators have a bit different infrastructure," says Gergely Csatari, Senior Open Source Engineer at Nokia. "There are operators who are running on bare metal. There are operators who are running on virtual machines. There are operators who are running on VMware Cloud and OpenStack Cloud. We want to run the same product on all of these different infrastructures without changing the product itself."<br><br>
-  Looking for a way to allow its teams to build products with infrastructure-agnostic behavior, the company decided to embrace containerization, Kubernetes, and other cloud native technologies, a move that is being made across the telecom industry. Since early 2018, "when people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes," says Csatari. "Now, all the products are doing some kind of re-architecture work, and they’re moving to Kubernetes."
+{{< case-studies/quote author="Gergely Csatari, Senior Open Source Engineer, Nokia" >}}
+"When people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nokia/banner3.jpg')">
-  <div class="banner3text">
-    "Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span>
+{{< case-studies/lead >}}
+Nokia was the first name in mobile phones when they were becoming ubiquitous in the late 1990s and early 2000s. But by 2014, the company had sold off its mobile device division and was focusing its core business not on the handhelds used for calls, but on the networks.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Nokia’s cloud native journey began about two years ago, when Csatari’s team was building the company’s Telephony Application Server (TAS). "We wanted to have a service execution engine in the product, which was a totally separate function from all other parts," he says. "There, we had the possibility to think about new architectures and new tools that we could use. We created this particular product based on Kubernetes, and we liked the work, so we started to talk about cloud native and containers and all of these things. We did a very extensive research of different container orchestration tools. We knew that we have some, let’s say, strange or different requirements because of the special environment that our software is running on."<br><br>
-  For one thing, Nokia’s software serves millions of people, and is required to have the carrier-grade "five nines" availability: to be up 99.999% of the time. "If you turn it to minutes, this means we’re allowed to have only 10 minutes of downtime in a whole year," says Csatari. "Downtime here means that you are not able to serve the person to full capacity, which means that we cannot fail. This includes software upgrades, everything, because when you call 911, you’re using our software, and you expect that it will work."<br><br>
-  That meant that they needed to be able to set affinity and anti-affinity rules in their orchestration tools. "You cannot put all of the functions to the same physical host because physical hosts are failing," Csatari explains. "If you fail with one physical host, then you lose all of the core processing processes. Then there are no calls going through. So we have to divide them among the different physical hosts. At that time, only Kubernetes was able to provide these features. The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes."
+<p>Today, Nokia is building telecom networks end-to-end—from antennas to switching and routing equipment—serving operators in more than 120 countries. "As telecom vendors, we have to deliver our software to several telecom operators and put the software into their infrastructure, and each of the operators have a bit different infrastructure," says Gergely Csatari, Senior Open Source Engineer at Nokia. "There are operators who are running on bare metal. There are operators who are running on virtual machines. There are operators who are running on VMware Cloud and OpenStack Cloud. We want to run the same product on all of these different infrastructures without changing the product itself."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nokia/banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-  "Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span>
-  </div>
-</div>
+<p>Looking for a way to allow its teams to build products with infrastructure-agnostic behavior, the company decided to embrace containerization, Kubernetes, and other cloud native technologies, a move that is being made across the telecom industry. Since early 2018, "when people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes," says Csatari. "Now, all the products are doing some kind of re-architecture work, and they're moving to Kubernetes."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  The TAS went live in early 2018, and now Kubernetes is also enabling Nokia’s foray into 5G. The company is introducing microservices architecture and Kubernetes while adding 5G features to existing products. And all new 5G product development will be on top of Kubernetes. "When you develop something that is part of the operator’s infrastructure, you have to develop it for the future, and Kubernetes and containers are the forward-looking technologies," says Csatari. <br><br>
-  There have been real time savings thanks to Kubernetes. "By separating the infrastructure and the application layer, we have less dependencies in the system, which means that it’s easier to implement features in the application layer," says Csatari. Because teams can test the exact same binary artifact independently of the target execution environment, "we find more errors in early phases of the testing, and we do not need to run the same tests on different target environments, like VMware, OpenStack or bare metal," he adds. As a result, "we save several hundred hours in every release."<br><br>
-  Moving from Nokia’s legacy cluster management system, which had been built in-house more than thirty years ago, to a Kubernetes platform also meant that "we started using Linux as a base operating system, so we just opened the window to all of these open source projects instead of implementing everything in house," says Csatari. (From CNCF’s ecosystem, the team is already using <a href="https://helm.sh/">Helm</a>, <a href="https://grpc.io/">gRPC</a>, <a href="https://github.com/containernetworking">CNI</a>, <a href="https://prometheus.io/">Prometheus</a>, and <a href="https://www.envoyproxy.io/">Envoy</a>, and plans to implement <a href="https://coredns.io/">CoreDNS</a>.) "Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."
+{{< case-studies/quote
+  image="/images/case-studies/nokia/banner3.jpg"
+  author="Gergely Csatari, Senior Open Source Engineer, Nokia"
+>}}
+"Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm."
+{{< /case-studies/quote >}}
 
-</div>
+<p>Nokia's cloud native journey began about two years ago, when Csatari's team was building the company's Telephony Application Server (TAS). "We wanted to have a service execution engine in the product, which was a totally separate function from all other parts," he says. "There, we had the possibility to think about new architectures and new tools that we could use. We created this particular product based on Kubernetes, and we liked the work, so we started to talk about cloud native and containers and all of these things. We did a very extensive research of different container orchestration tools. We knew that we have some, let's say, strange or different requirements because of the special environment that our software is running on."</p>
 
-<div class="banner5" style="width:100%">
-  <div class="banner5text">
-"I had some discussions at KubeCon with people from the networking SIG and the resource management working group, to work together on our requirements, and that’s very exciting for me and my colleagues,"<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span></div>
-</div>
+<p>For one thing, Nokia's software serves millions of people, and is required to have the carrier-grade "five nines" availability: to be up 99.999% of the time. "If you turn it to minutes, this means we're allowed to have only 10 minutes of downtime in a whole year," says Csatari. "Downtime here means that you are not able to serve the person to full capacity, which means that we cannot fail. This includes software upgrades, everything, because when you call 911, you're using our software, and you expect that it will work."</p>
 
-<div class="fullcol">
-  The company has a long-term goal of moving the entire product portfolio into the Kubernetes platform. To that end, Nokia teams are working together with other companies to add the features needed to use Kubernetes with the real-time, nanosecond-sensitive applications close to the edge of the radio network. <br><br>
-  And the CNCF community is proving to be a great forum for that collaboration. "I had some discussions at KubeCon with people from the networking SIG and the resource management working group, to work together on our requirements, and that’s very exciting for me and my colleagues," says Csatari. "Previously, everybody had the same problem, but everybody just did it in his own, and now we are trying to solve the same problem together."<br><br>
-  Perhaps the biggest impact that Kubernetes is having on Nokia, Csatari believes, is that people are starting to think about how a telecom company can do DevOps. "We are building a DevOps pipeline, which reaches from the actual developer to the customers, and thinking about new ways how can we digitally deliver our software to our customers and get feedback from the customers right to the engineers," he says. "This is something that will fundamentally change how telecom companies are delivering software, and how quickly can we develop new features. This is because of the usage of containers and, of course, the usage of Kubernetes."
+<p>That meant that they needed to be able to set affinity and anti-affinity rules in their orchestration tools. "You cannot put all of the functions to the same physical host because physical hosts are failing," Csatari explains. "If you fail with one physical host, then you lose all of the core processing processes. Then there are no calls going through. So we have to divide them among the different physical hosts. At that time, only Kubernetes was able to provide these features. The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes."</p>
 
-</div>
-</section>
+{{< case-studies/quote 
+  image="/images/case-studies/nokia/banner4.jpg"
+  author="Gergely Csatari, Senior Open Source Engineer, Nokia"
+>}}
+"Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."
+{{< /case-studies/quote >}}
+
+<p>The TAS went live in early 2018, and now Kubernetes is also enabling Nokia's foray into 5G. The company is introducing microservices architecture and Kubernetes while adding 5G features to existing products. And all new 5G product development will be on top of Kubernetes. "When you develop something that is part of the operator's infrastructure, you have to develop it for the future, and Kubernetes and containers are the forward-looking technologies," says Csatari.</p>
+
+<p>There have been real time savings thanks to Kubernetes. "By separating the infrastructure and the application layer, we have less dependencies in the system, which means that it's easier to implement features in the application layer," says Csatari. Because teams can test the exact same binary artifact independently of the target execution environment, "we find more errors in early phases of the testing, and we do not need to run the same tests on different target environments, like VMware, OpenStack or bare metal," he adds. As a result, "we save several hundred hours in every release."</p>
+
+<p>Moving from Nokia's legacy cluster management system, which had been built in-house more than thirty years ago, to a Kubernetes platform also meant that "we started using Linux as a base operating system, so we just opened the window to all of these open source projects instead of implementing everything in house," says Csatari. (From CNCF's ecosystem, the team is already using <a href="https://helm.sh/">Helm</a>, <a href="https://grpc.io/">gRPC</a>, <a href="https://github.com/containernetworking">CNI</a>, <a href="https://prometheus.io/">Prometheus</a>, and <a href="https://www.envoyproxy.io/">Envoy</a>, and plans to implement <a href="https://coredns.io/">CoreDNS</a>.) "Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."</p>
+
+{{< case-studies/quote author="Gergely Csatari, Senior Open Source Engineer, Nokia" >}}
+"I had some discussions at KubeCon with people from the networking SIG and the resource management working group, to work together on our requirements, and that's very exciting for me and my colleagues,"
+{{< /case-studies/quote >}}
+
+<p>The company has a long-term goal of moving the entire product portfolio into the Kubernetes platform. To that end, Nokia teams are working together with other companies to add the features needed to use Kubernetes with the real-time, nanosecond-sensitive applications close to the edge of the radio network.</p>
+
+<p>And the CNCF community is proving to be a great forum for that collaboration. "I had some discussions at KubeCon with people from the networking SIG and the resource management working group, to work together on our requirements, and that's very exciting for me and my colleagues," says Csatari. "Previously, everybody had the same problem, but everybody just did it in his own, and now we are trying to solve the same problem together."</p>
+
+<p>Perhaps the biggest impact that Kubernetes is having on Nokia, Csatari believes, is that people are starting to think about how a telecom company can do DevOps. "We are building a DevOps pipeline, which reaches from the actual developer to the customers, and thinking about new ways how can we digitally deliver our software to our customers and get feedback from the customers right to the engineers," he says. "This is something that will fundamentally change how telecom companies are delivering software, and how quickly can we develop new features. This is because of the usage of containers and, of course, the usage of Kubernetes."</p>
diff --git a/content/en/case-studies/nordstrom/index.html b/content/en/case-studies/nordstrom/index.html
index 788453de35..73bc4e147e 100644
--- a/content/en/case-studies/nordstrom/index.html
+++ b/content/en/case-studies/nordstrom/index.html
@@ -2,109 +2,74 @@
 title: Nordstrom Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nordstrom/banner1.jpg
+heading_title_logo: /images/nordstrom_logo.png
+subheading: >
+  Finding Millions in Potential Savings in a Tough Retail Climate
+case_study_details:
+  - Company: Nordstrom
+  - Location: Seattle, Washington
+  - Industry: Retail
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">Finding Millions in Potential Savings in a Tough Retail Climate
+<h2>Challenge</h2>
 
+<p>Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
+<p>After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>.</p>
 
-<div class="details">
-    Company &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Seattle, Washington</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Retail</b>
-</div>
+<h2>Impact</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.
+<p>Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren't effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."</p>
 
-<br>
-    <h2>Solution</h2>
-    After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>.
+{{< case-studies/quote author="Dhawal Patel, senior engineer at Nordstrom" >}}
+"We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It's a win-win."
+{{< /case-studies/quote >}}
 
-  <br>
+<p>When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer's website, he realized there was an opportunity to help speed up development cycles.</p>
 
+<p>In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."</p>
 
-      </div>
+<p>The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom's cloud native journey.</p>
 
-<div class="col2">
+<p>Dev and Ops team members built a CI/CD pipeline, working with the company's servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."</p>
 
-  <h2>Impact</h2>
-  Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren’t effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."
+<p>But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company's 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.</p>
 
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It’s a win-win."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-— Dhawal Patel, senior engineer at Nordstrom</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer’s website, he realized there was an opportunity to help speed up development cycles.
-<br><br>
-    In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."
-<br><br>
-    The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom’s cloud native journey.
-<br><br>
-    Dev and Ops team members built a CI/CD pipeline, working with the company’s servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."
-    <br><br>But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company’s 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
+"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')">
-  <div class="banner3text">
-    "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>"The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."</p>
 
-"The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."
-<br><br>
-Nordstrom’s first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.
-While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."
-<br><br>
-The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
+<p>Nordstrom's first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')">
-  <div class="banner4text">
- "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
-  </div>
-</div>
+<p>While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."</p>
 
-<section class="section5">
-<div class="fullcol">
-  To support these early adopters, Patel’s team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.
- <br><br>
-There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."
- <br><br>
-For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications.  One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.
-</div>
+<p>The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead."
-  </div>
-</div>
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
+"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead."
-<br><br>
-  Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they’re only working with Kubernetes."
-  For that reason, Patel is eagerly following Kubernetes’ development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."
-<br><br>
-  That kind of possibility—as well as the impact that Grigoriu and Patel’s team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu.  "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It’s a win-win."
+<p>To support these early adopters, Patel's team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.</p>
 
-</div>
-</section>
+<p>There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."</p>
+
+<p>For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications.  One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.</p>
+
+{{< case-studies/quote >}}
+"With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."
+{{< /case-studies/quote >}}
+
+<p>Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."</p>
+
+<p>Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they're only working with Kubernetes."</p>
+
+<p>For that reason, Patel is eagerly following Kubernetes' development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."</p>
+
+<p>That kind of possibility—as well as the impact that Grigoriu and Patel's team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu.  "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It's a win-win."</p>
diff --git a/content/en/case-studies/northwestern-mutual/index.html b/content/en/case-studies/northwestern-mutual/index.html
index 47b4bbc7be..a25d25484c 100644
--- a/content/en/case-studies/northwestern-mutual/index.html
+++ b/content/en/case-studies/northwestern-mutual/index.html
@@ -2,98 +2,68 @@
 title: Northwestern Mutual Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/northwestern/banner1.jpg
+heading_title_logo: /images/northwestern_logo.png
+subheading: >
+  Cloud Native at Northwestern Mutual
+case_study_details:
+  - Company: Northwestern Mutual
+  - Location: Milwaukee, WI
+  - Industry: Insurance and Financial Services
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/northwestern/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/northwestern_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Cloud Native at Northwestern Mutual
+<h2>Challenge</h2>
 
+<p>In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual's leading products and services and meld it with LearnVest's digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company's existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
-
-<div class="details">
-    Company &nbsp;<b>Northwestern Mutual</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Milwaukee, WI</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Insurance and Financial Services</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.
-<br>
-    <h2>Solution</h2>
-    The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced <a href="https://github.com/northwesternmutual/kanali">Kanali</a>, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC.
-
-
-</div>
-
-<div class="col2">
+<p>The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they're building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced <a href="https://github.com/northwesternmutual/kanali">Kanali</a>, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC.</p>
 
 <h2>Impact</h2>
-  Before, infrastructure deployments could take weeks; now, it is done in a matter of minutes. The number of deployments has increased dramatically, from about 24 a year to over 500 in just the first 10 months of 2017. Availability has also increased: There used to be a six-hour control window for commits every Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now we have eliminated the planned outage windows," says Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. Kanali has had an impact on the bottom line. The vendor API management product that the company previously used required 23 servers, "dedicated, to only API management," says Pfremmer. "Now it’s all integrated in the existing stack and running as another deployment on Kubernetes. And that’s just one environment. Between the three that we had plus the test, that’s hard dollar savings."
-  <br>
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text" style="width:70% !important;padding-left:15%">
-"In a large enterprise, you’re going to have people using Kubernetes, but then you’re also going to have people using WAS and .NET. You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff." <span style="font-size:16px;text-transform:uppercase">— Frank Greco Jr., Cloud Native Engineer at Northwestern Mutual</span></div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>For more than 160 years, Northwestern Mutual has maintained its industry leadership in part by keeping a strong focus on risk management. </h2>
-  For many years, the company took a similar approach to managing its technology and has recently undergone a digital transformation to advance the company’s digital strategy - including making a lot of noise in the cloud-native world.<br><br>
-In the spring of 2015, this insurance and financial services company acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on an on-premise datacenter; deployments were very traditional and had to many manual steps that were error prone. <br><br>
-In order to give the company’s 4.5 million clients the digital experience they’d come to expect, says Williams, "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website. We essentially said, 'You build the system that you think is necessary to support a new, modern-facing one.’ That’s why we departed from anything legacy."
+<p>Before, infrastructure deployments could take weeks; now, it is done in a matter of minutes. The number of deployments has increased dramatically, from about 24 a year to over 500 in just the first 10 months of 2017. Availability has also increased: There used to be a six-hour control window for commits every Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now we have eliminated the planned outage windows," says Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. Kanali has had an impact on the bottom line. The vendor API management product that the company previously used required 23 servers, "dedicated, to only API management," says Pfremmer. "Now it's all integrated in the existing stack and running as another deployment on Kubernetes. And that's just one environment. Between the three that we had plus the test, that's hard dollar savings."</p>
 
+{{< case-studies/quote author="Frank Greco Jr., Cloud Native Engineer at Northwestern Mutual">}}
+"In a large enterprise, you're going to have people using Kubernetes, but then you're also going to have people using WAS and .NET. You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/northwestern/banner3.jpg')">
-  <div class="banner3text">
-    "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."
+{{< case-studies/lead >}}
+For more than 160 years, Northwestern Mutual has maintained its industry leadership in part by keeping a strong focus on risk management.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."<br><br>
-As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board.
-The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
+<p>For many years, the company took a similar approach to managing its technology and has recently undergone a digital transformation to advance the company's digital strategy - including making a lot of noise in the cloud-native world.</p>
 
+<p>In the spring of 2015, this insurance and financial services company acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual's leading products and services and meld it with LearnVest's digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company's existing infrastructure had been optimized for batch workflows hosted on an on-premise datacenter; deployments were very traditional and had to many manual steps that were error prone.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/northwestern/banner4.jpg')">
-  <div class="banner4text">
+<p>In order to give the company's 4.5 million clients the digital experience they'd come to expect, says Williams, "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website. We essentially said, 'You build the system that you think is necessary to support a new, modern-facing one.' That's why we departed from anything legacy."</p>
+
+{{< case-studies/quote image="/images/case-studies/northwestern/banner3.jpg" >}}
+"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they're building and deliver very quickly and frequently."
+{{< /case-studies/quote >}}
+
+<p>Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they're building and deliver very quickly and frequently."</p>
+
+<p>As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company's 1,500 engineers are using it and more are eager to get on board.</p>
+
+<p>The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.</p>
+
+{{< case-studies/quote image="/images/case-studies/northwestern/banner4.jpg" >}}
 "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it."
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important;">
-<div class="fullcol">
-  The process used to be so cumbersome that minor bug releases would be bundled with feature releases. With the new streamlined system enabled by Kubernetes, the number of deployments has increased from about 24 a year to more than 500 in just the first 10 months of 2017. Availability has also been improved: There used to be a six-hour control window for commits every early Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now there’s no planned outage window," notes Pfremmer.<br><br>
-Northwestern Mutual built that API management tool—called <a href="https://github.com/northwesternmutual/kanali">Kanali</a>—and open sourced it in the summer of 2017. The team took on the project because it was a key capability for what they were building and prior the solution worked in an "anti-cloud native way that was different than everything else we were doing," says Greco. Now API management is just another container deployed to Kubernetes along with a separate Jaeger deployment.<br><br>
-Now the engineers using the Kubernetes deployment platform have the added benefit of visibility in production—and autonomy. Before, a centralized team and would have to run a trace. "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." says Greco.
+<p>The process used to be so cumbersome that minor bug releases would be bundled with feature releases. With the new streamlined system enabled by Kubernetes, the number of deployments has increased from about 24 a year to more than 500 in just the first 10 months of 2017. Availability has also been improved: There used to be a six-hour control window for commits every early Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now there's no planned outage window," notes Pfremmer.</p>
 
+<p>Northwestern Mutual built that API management tool—called <a href="https://github.com/northwesternmutual/kanali">Kanali</a>—and open sourced it in the summer of 2017. The team took on the project because it was a key capability for what they were building and prior the solution worked in an "anti-cloud native way that was different than everything else we were doing," says Greco. Now API management is just another container deployed to Kubernetes along with a separate Jaeger deployment.</p>
 
-</div>
+<p>Now the engineers using the Kubernetes deployment platform have the added benefit of visibility in production—and autonomy. Before, a centralized team and would have to run a trace. "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." says Greco.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-  "We’re trying to make what we’re doing known so that we can find people who are like, 'Yeah, that’s interesting. I want to come do it!’"
-  </div>
-</div>
+{{< case-studies/quote >}}
+"We're trying to make what we're doing known so that we can find people who are like, 'Yeah, that's interesting. I want to come do it!'"
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  But the team didn’t stop there. "In a large enterprise, you’re going to have people using Kubernetes, but then you’re also going to have people using WAS and .NET," says Greco. "You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."<br><br>
-  As the team continues to improve its stack and share its Kubernetes best practices, it feels that Northwestern Mutual’s reputation as a technology-first company is evolving too. "No one would think a company that’s 160-plus years old is foraying this deep into the cloud and infrastructure stack," says Pfremmer. And they’re hoping that means they’ll be able to attract new talent. "We’re trying to make what we’re doing known so that we can find people who are like, 'Yeah, that’s interesting. I want to come do it!’"
+<p>But the team didn't stop there. "In a large enterprise, you're going to have people using Kubernetes, but then you're also going to have people using WAS and .NET," says Greco. "You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."</p>
 
-
-</div>
-
-</section>
+<p>As the team continues to improve its stack and share its Kubernetes best practices, it feels that Northwestern Mutual's reputation as a technology-first company is evolving too. "No one would think a company that's 160-plus years old is foraying this deep into the cloud and infrastructure stack," says Pfremmer. And they're hoping that means they'll be able to attract new talent. "We're trying to make what we're doing known so that we can find people who are like, 'Yeah, that's interesting. I want to come do it!'"</p>
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html
index 79ac9bf3a8..4c4018009a 100644
--- a/content/en/case-studies/ocado/index.html
+++ b/content/en/case-studies/ocado/index.html
@@ -1,99 +1,83 @@
 ---
 title: Ocado Case Study
-
 linkTitle: Ocado
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: ocado_featured_logo.png
 featured: true
 weight: 4
 quote: >
- People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing.
+ People at Ocado Technology have been quite amazed. They ask, 'Can we do this on a Dev cluster?' and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ocado/banner1.jpg
+heading_title_logo: /images/ocado_logo.png
+subheading: >
+  Ocado: Running Grocery Warehouses with a Cloud Native Platform
+case_study_details:
+  - Company: Ocado Technology
+  - Location: Hatfield, England
+  - Industry: Grocery retail technology and platforms
 ---
-<div class="banner1" style="background-image: url('/images/case-studies/ocado/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ocado_logo.png" class="header_logo"><br> <div class="subhead">Ocado: Running Grocery Warehouses with a Cloud Native Platform</div></h1>
 
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>Ocado Technology</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Hatfield, England</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Grocery retail technology and platforms</b>
-</div>
+<p>The world's largest online-only grocery retailer, <a href="http://www.ocadogroup.com/">Ocado</a> developed the Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other retailers such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses for the platform, Ocado shifted from virtual machines and <a href="https://puppet.com/">Puppet</a> infrastructure to <a href="https://www.docker.com/">Docker</a> containers, using CoreOS's <a href="https://github.com/coreos/fleet">fleet</a> scheduler to provision all the services on its <a href="https://www.openstack.org/">OpenStack</a>-based private cloud on bare metal. As the Smart Platform grew and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The world’s largest online-only grocery retailer, <a href="http://www.ocadogroup.com/">Ocado</a> developed the Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other retailers such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses for the platform, Ocado shifted from virtual machines and <a href="https://puppet.com/">Puppet</a> infrastructure to <a href="https://www.docker.com/">Docker</a> containers, using CoreOS’s <a href="https://github.com/coreos/fleet">fleet</a> scheduler to provision all the services on its <a href="https://www.openstack.org/">OpenStack</a>-based private cloud on bare metal. As the Smart Platform grew and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."<br><br>
- <h2>Solution</h2>
-      The team decided to migrate from fleet to <a href="https://www.kubernetes.io">Kubernetes</a> on Ocado’s private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm/">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing. The first app on Kubernetes, a business-critical service in the warehouses, went into production in the summer of 2017, with a mass migration continuing into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes.
-
-      </div>
-
-<div class="col2">
+<h2>Solution</h2>
 
+<p>The team decided to migrate from fleet to <a href="https://www.kubernetes.io">Kubernetes</a> on Ocado's private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm/">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing. The first app on Kubernetes, a business-critical service in the warehouses, went into production in the summer of 2017, with a mass migration continuing into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes.</p>
 
 <h2>Impact</h2>
-     With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments."
 
-</div>
+<p>With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I'd estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-   "People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Mike Bryant, Platform Engineer, Ocado</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-    <h2>When it was founded in 2000, Ocado was an online-only grocery retailer in the U.K. In the years since, it has expanded from delivering produce to families to providing technology to other grocery retailers.</h2>
-The company began developing its Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other grocery chains around the world, such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses on the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS’s fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew, and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."<br><br>
-Bryant had already been using Kubernetes with <a href="https://www.codeforlife.education/">Code for Life</a>, a children’s education project that’s part of Ocado’s charity arm. "We really liked it, so we started looking at it seriously for our production workloads," says Bryant. The team that managed fleet had researched orchestration solutions and landed on Kubernetes as well. "We were looking for a platform with wide adoption, and that was where the momentum was," says DevOps Team Leader Kevin McCormack. The two paths converged, and "We didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose," says Bryant.
+{{< case-studies/quote author="Mike Bryant, Platform Engineer, Ocado" >}}
+"People at Ocado Technology have been quite amazed. They ask, 'Can we do this on a Dev cluster?' and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ocado/banner3.jpg')">
-  <div class="banner3text">
-    "We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose," <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Kevin McCormack, DevOps Team Leader, Ocado</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-    In the summer of 2016, the team began migrating from fleet to <a href="https://kubernetes.io/">Kubernetes</a> on Ocado’s private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing. <br><br>
-    The first app on Kubernetes, a business-critical service in the warehouses, went into production a year later. Once that app was running smoothly, a mass migration continued into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes, and the platform is live in Ocado’s warehouses, managing tens of thousands of orders a week. At full capacity, Ocado’s latest warehouse in Erith, southeast London, will deliver more than 200,000 orders per week, making it the world’s largest facility for online grocery. <br><br>
-    There are about 150 microservices now running on Kubernetes, with multiple instances of many of them. "We’re not just deploying all these microservices at once. We’re deploying them all for one warehouse, and then they’re all being deployed again for the next warehouse, and again and again," says Bryant.<br><br>
-    The move to Kubernetes was eye-opening for many people at Ocado Technology. "In the early days of putting the platform into our test infrastructure, the technical architect asked what network performance was like on <a href="https://www.weave.works/oss/net/">Weave Net</a> with encryption turned on," recalls Bryant. "So we found a Docker container for <a href="https://iperf.fr/">iPerf</a>, wrote a daemon set, deployed it. A few moments later, we’ve deployed the entire thing across this cluster. He was pretty blown away by that."
+{{< case-studies/lead >}}
+When it was founded in 2000, Ocado was an online-only grocery retailer in the U.K. In the years since, it has expanded from delivering produce to families to providing technology to other grocery retailers.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ocado/banner4.jpg')">
-  <div class="banner4text">
-     "The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Mike Bryant, Platform Engineer, Ocado</span>
-  </div>
-  </div>
-</div>
+<p>The company began developing its Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other grocery chains around the world, such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses on the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS's fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew, and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Indeed, the impact has been profound. "Prior to containerization, we had quite restrictive deployment windows in our warehouses," says Bryant. "Moving to microservices, we’ve been able to deploy much more frequently. We’ve been able to move towards continuous delivery in a number of areas. In our older warehouse, new application deployments involve talking to a bunch of different teams for different levels of the stack: from VM provisioning, to storage, to load balancers, and so on. The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."<br><br>
-  The rate of deployment has gone from as few as two per week to dozens per week. "With Kubernetes, some of our development teams have been able to deploy their application to production on the new platform without us noticing," says Bryant, "which means they’re faster at doing what they need to do and we have less work."<br><br>
-  Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. "That lets us shrink quite a lot of our deployments from being per-core VM deployments to having fractions of the core," says Bryant. Adds McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster. This means we use our hardware better since if we have to always have two nodes of excess capacity available in case of node failures then we only need two extra instead of 20."
+<p>Bryant had already been using Kubernetes with <a href="https://www.codeforlife.education/">Code for Life</a>, a children's education project that's part of Ocado's charity arm. "We really liked it, so we started looking at it seriously for our production workloads," says Bryant. The team that managed fleet had researched orchestration solutions and landed on Kubernetes as well. "We were looking for a platform with wide adoption, and that was where the momentum was," says DevOps Team Leader Kevin McCormack. The two paths converged, and "We didn't even go through any proof-of-concept stage. The Code for Life work served that purpose," says Bryant.</p>
 
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ocado/banner3.jpg"
+  author="Kevin McCormack, DevOps Team Leader, Ocado"
+>}}
+"We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn't even go through any proof-of-concept stage. The Code for Life work served that purpose,"
+{{< /case-studies/quote >}}
 
-<div class="banner5">
-  <div class="banner5text">
-    "CNCF have provided us with support of different technologies. We’ve been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We’re not being asked to commit to this one way of doing things. The vast diversity of viewpoints in CNCF lead to better technology." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Mike Bryant, Platform Engineer, Ocado</span>
+<p>In the summer of 2016, the team began migrating from fleet to <a href="https://kubernetes.io/">Kubernetes</a> on Ocado's private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing.</p>
 
-  </div>
-</div>
+<p>The first app on Kubernetes, a business-critical service in the warehouses, went into production a year later. Once that app was running smoothly, a mass migration continued into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes, and the platform is live in Ocado's warehouses, managing tens of thousands of orders a week. At full capacity, Ocado's latest warehouse in Erith, southeast London, will deliver more than 200,000 orders per week, making it the world's largest facility for online grocery.</p>
 
-<div class="fullcol">
-  The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resource to host the same applications in Kubernetes in our test environments."<br><br>
-  One of the broader benefits of cloud native, says Bryant, is the unified API. "We have one method of doing our deployments that covers the wide range of things we need to do, and we can extend the API," he says. In addition to using Prometheus Operator, the Ocado team has started writing its own operators, some of which have been <a href="https://github.com/ocadotechnology">open sourced</a>. Plus, "CNCF has provided us with support of these different technologies. We’ve been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We’re not being asked to commit to this one way of doing things. The vast diversity of viewpoints in the CNCF leads to better technology."<br><br>
-  Ocado’s own technology, in the form of its Smart Platform, will soon be used <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">around</a> the world. And cloud native plays a crucial role in this global expansion. "I wouldn’t have wanted to try it without Kubernetes," says Bryant. "Kubernetes has made it so much nicer, especially to have that consistent way of deploying all of the applications, then taking the same thing and being able to replicate it. It’s very valuable."
+<p>There are about 150 microservices now running on Kubernetes, with multiple instances of many of them. "We're not just deploying all these microservices at once. We're deploying them all for one warehouse, and then they're all being deployed again for the next warehouse, and again and again," says Bryant.</p>
 
-</div>
-</section>
+<p>The move to Kubernetes was eye-opening for many people at Ocado Technology. "In the early days of putting the platform into our test infrastructure, the technical architect asked what network performance was like on <a href="https://www.weave.works/oss/net/">Weave Net</a> with encryption turned on," recalls Bryant. "So we found a Docker container for <a href="https://iperf.fr/">iPerf</a>, wrote a daemon set, deployed it. A few moments later, we've deployed the entire thing across this cluster. He was pretty blown away by that."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ocado/banner4.jpg"
+  author="Mike Bryant, Platform Engineer, Ocado"
+>}}
+"The unified API of Kubernetes means this is all in one place, and it's one flow for approval and rollout. I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."
+{{< /case-studies/quote >}}
+
+<p>Indeed, the impact has been profound. "Prior to containerization, we had quite restrictive deployment windows in our warehouses," says Bryant. "Moving to microservices, we've been able to deploy much more frequently. We've been able to move towards continuous delivery in a number of areas. In our older warehouse, new application deployments involve talking to a bunch of different teams for different levels of the stack: from VM provisioning, to storage, to load balancers, and so on. The unified API of Kubernetes means this is all in one place, and it's one flow for approval and rollout. I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."</p>
+
+<p>The rate of deployment has gone from as few as two per week to dozens per week. "With Kubernetes, some of our development teams have been able to deploy their application to production on the new platform without us noticing," says Bryant, "which means they're faster at doing what they need to do and we have less work."</p>
+
+<p>Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. "That lets us shrink quite a lot of our deployments from being per-core VM deployments to having fractions of the core," says Bryant. Adds McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster. This means we use our hardware better since if we have to always have two nodes of excess capacity available in case of node failures then we only need two extra instead of 20."</p>
+
+{{< case-studies/quote author="Mike Bryant, Platform Engineer, Ocado" >}}
+"CNCF have provided us with support of different technologies. We've been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We're not being asked to commit to this one way of doing things. The vast diversity of viewpoints in CNCF lead to better technology."
+{{< /case-studies/quote >}}
+
+<p>The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I'd estimate that we use about 15-25% less hardware resource to host the same applications in Kubernetes in our test environments."</p>
+
+<p>One of the broader benefits of cloud native, says Bryant, is the unified API. "We have one method of doing our deployments that covers the wide range of things we need to do, and we can extend the API," he says. In addition to using Prometheus Operator, the Ocado team has started writing its own operators, some of which have been <a href="https://github.com/ocadotechnology">open sourced</a>. Plus, "CNCF has provided us with support of these different technologies. We've been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We're not being asked to commit to this one way of doing things. The vast diversity of viewpoints in the CNCF leads to better technology."</p>
+
+<p>Ocado's own technology, in the form of its Smart Platform, will soon be used <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">around</a> the world. And cloud native plays a crucial role in this global expansion. "I wouldn't have wanted to try it without Kubernetes," says Bryant. "Kubernetes has made it so much nicer, especially to have that consistent way of deploying all of the applications, then taking the same thing and being able to replicate it. It's very valuable."</p>
diff --git a/content/en/case-studies/openAI/index.html b/content/en/case-studies/openAI/index.html
index 1b95ec5f35..543c1dee64 100644
--- a/content/en/case-studies/openAI/index.html
+++ b/content/en/case-studies/openAI/index.html
@@ -2,98 +2,68 @@
 title: OpenAI Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/openAI/banner1.jpg
+heading_title_logo: /images/openAI_logo.png
+subheading: >
+  Launching and Scaling Up Experiments, Made Simple
+case_study_details:
+  - Company: OpenAI
+  - Location: San Francisco, California
+  - Industry: Artificial Intelligence Research
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/openAI/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/openAI_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Launching and Scaling Up Experiments, Made Simple
+<h2>Challenge</h2>
 
-</div></h1>
+<p>An artificial intelligence research lab, OpenAI needed infrastructure for deep learning that would allow experiments to be run either in the cloud or in its own data center, and to easily scale. Portability, speed, and cost were the main drivers.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>OpenAI</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>San Francisco, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Artificial Intelligence Research</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    An artificial intelligence research lab, OpenAI needed infrastructure for deep learning that would allow experiments to be run either in the cloud or in its own data center, and to easily scale. Portability, speed, and cost were the main drivers.
-<br>
-    <h2>Solution</h2>
-    OpenAI began running Kubernetes on top of AWS in 2016, and in early 2017 migrated to Azure. OpenAI runs key experiments in fields including robotics and gaming both in Azure and in its own data centers, depending on which cluster has free capacity. "We use Kubernetes mainly as a batch scheduling system and rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster," says Christopher Berner, Head of Infrastructure. "This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."
-</div>
-
-<div class="col2">
+<p>OpenAI began running Kubernetes on top of AWS in 2016, and in early 2017 migrated to Azure. OpenAI runs key experiments in fields including robotics and gaming both in Azure and in its own data centers, depending on which cluster has free capacity. "We use Kubernetes mainly as a batch scheduling system and rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster," says Christopher Berner, Head of Infrastructure. "This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."</p>
 
 <h2>Impact</h2>
-  The company has benefited from greater portability: "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. Being able to use its own data centers when appropriate is "lowering costs and providing us access to hardware that we wouldn’t necessarily have access to in the cloud," he adds. "As long as the utilization is high, the costs are much lower there." Launching experiments also takes far less time: "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days. In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
 
+<p>The company has benefited from greater portability: "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. Being able to use its own data centers when appropriate is "lowering costs and providing us access to hardware that we wouldn't necessarily have access to in the cloud," he adds. "As long as the utilization is high, the costs are much lower there." Launching experiments also takes far less time: "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days. In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."</p>
 
-</div>
+{{< case-studies/quote >}}
+<iframe width="560" height="315" src="https://www.youtube.com/embed/v4N3Krzb8Eg" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<br>
+Check out "Building the Infrastructure that Powers the Future of AI" presented by  Vicki Cheung, Member of Technical Staff & Jonas Schneider, Member of Technical Staff at OpenAI from KubeCon/CloudNativeCon Europe 2017.
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
+{{< case-studies/lead >}}
+From experiments in robotics to old-school video game play research, OpenAI's work in artificial intelligence technology is meant to be shared.
+{{< /case-studies/lead >}}
 
-<div class="video">
-<iframe width="560" height="315" src="https://www.youtube.com/embed/v4N3Krzb8Eg" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe><br>
-<span style="font-size:21px;line-height:0.5em !important;width:60%;">Check out "Building the Infrastructure that Powers the Future of AI" presented by  Vicki Cheung, Member of Technical Staff & Jonas Schneider, Member of Technical Staff at OpenAI from KubeCon/CloudNativeCon Europe 2017.</span>
-</div>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>From experiments in robotics to old-school video game play research, OpenAI’s work in artificial intelligence technology is meant to be shared.</h2>
-  With a mission to ensure powerful AI systems are safe, OpenAI cares deeply about open source—both benefiting from it and contributing safety technology into it. "The research that we do, we want to spread it as widely as possible so everyone can benefit," says OpenAI’s Head of Infrastructure Christopher Berner. The lab’s philosophy—as well as its particular needs—lent itself to embracing an open source, cloud native strategy for its deep learning infrastructure.<br><br>
-  OpenAI started running Kubernetes on top of AWS in 2016, and a year later, migrated the Kubernetes clusters to Azure. "We probably use Kubernetes differently from a lot of people," says Berner. "We use it for batch scheduling and as a workload manager for the cluster. It’s a way of coordinating a large number of containers that are all connected together. We rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster. This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration." <br><br>
-  In the past year, Berner has overseen the launch of several Kubernetes clusters in OpenAI’s own data centers. "We run them in a hybrid model where the control planes—the Kubernetes API servers, <a href="https://github.com/coreos/etcd">etcd</a> and everything—are all in Azure, and then all of the Kubernetes nodes are in our own data center," says Berner. "The cloud is really convenient for managing etcd and all of the masters, and having backups and spinning up new nodes if anything breaks. This model allows us to take advantage of lower costs and have the availability of more specialized hardware in our own data center."
+<p>With a mission to ensure powerful AI systems are safe, OpenAI cares deeply about open source—both benefiting from it and contributing safety technology into it. "The research that we do, we want to spread it as widely as possible so everyone can benefit," says OpenAI's Head of Infrastructure Christopher Berner. The lab's philosophy—as well as its particular needs—lent itself to embracing an open source, cloud native strategy for its deep learning infrastructure.</p>
 
+<p>OpenAI started running Kubernetes on top of AWS in 2016, and a year later, migrated the Kubernetes clusters to Azure. "We probably use Kubernetes differently from a lot of people," says Berner. "We use it for batch scheduling and as a workload manager for the cluster. It's a way of coordinating a large number of containers that are all connected together. We rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster. This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/openAI/banner3.jpg')">
-  <div class="banner3text">
-    OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..."
+<p>In the past year, Berner has overseen the launch of several Kubernetes clusters in OpenAI's own data centers. "We run them in a hybrid model where the control planes—the Kubernetes API servers, <a href="https://github.com/coreos/etcd">etcd</a> and everything—are all in Azure, and then all of the Kubernetes nodes are in our own data center," says Berner. "The cloud is really convenient for managing etcd and all of the masters, and having backups and spinning up new nodes if anything breaks. This model allows us to take advantage of lower costs and have the availability of more specialized hardware in our own data center."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Different teams at OpenAI currently run a couple dozen projects. While the largest-scale workloads manage bare cloud VMs directly, most of OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. The on-prem clusters are generally "used for workloads where you need lots of GPUs, something like training an ImageNet model. Anything that’s CPU heavy, that’s run in the cloud. But we also have a number of teams that run their experiments both in Azure and in our own data centers, just depending on which cluster has free capacity, and that’s hugely valuable."<br><br>
-  Berner has made the Kubernetes clusters available to all OpenAI teams to use if it’s a good fit. "I’ve worked a lot with our games team, which at the moment is doing research on classic console games," he says. "They had been running a bunch of their experiments on our dev servers, and they had been trying out Google cloud, managing their own VMs. We got them to try out our first on-prem Kubernetes cluster, and that was really successful. They’ve now moved over completely to it, and it has allowed them to scale up their experiments by 10x, and do that without needing to invest significant engineering time to figure out how to manage more machines. A lot of people are now following the same path."
+{{< case-studies/quote image="/images/case-studies/openAI/banner3.jpg" >}}
+OpenAI's experiments take advantage of Kubernetes' benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/openAI/banner4.jpg')">
-  <div class="banner4text">
+<p>Different teams at OpenAI currently run a couple dozen projects. While the largest-scale workloads manage bare cloud VMs directly, most of OpenAI's experiments take advantage of Kubernetes' benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. The on-prem clusters are generally "used for workloads where you need lots of GPUs, something like training an ImageNet model. Anything that's CPU heavy, that's run in the cloud. But we also have a number of teams that run their experiments both in Azure and in our own data centers, just depending on which cluster has free capacity, and that's hugely valuable."</p>
+
+<p>Berner has made the Kubernetes clusters available to all OpenAI teams to use if it's a good fit. "I've worked a lot with our games team, which at the moment is doing research on classic console games," he says. "They had been running a bunch of their experiments on our dev servers, and they had been trying out Google cloud, managing their own VMs. We got them to try out our first on-prem Kubernetes cluster, and that was really successful. They've now moved over completely to it, and it has allowed them to scale up their experiments by 10x, and do that without needing to invest significant engineering time to figure out how to manage more machines. A lot of people are now following the same path."</p>
+
+{{< case-studies/quote image="/images/case-studies/openAI/banner4.jpg" >}}
 "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important;">
-<div class="fullcol">
-  That path has been simplified by frameworks and tools that two of OpenAI’s teams have developed to handle interaction with Kubernetes. "You can just write some Python code, fill out a bit of configuration with exactly how many machines you need and which types, and then it will prepare all of those specifications and send it to the Kube cluster so that it gets launched there," says Berner. "And it also provides a bit of extra monitoring and better tooling that’s designed specifically for these machine learning projects."<br><br>
-  The impact that Kubernetes has had at OpenAI is impressive. With Kubernetes, the frameworks and tooling, including the autoscaler, in place, launching experiments takes far less time. "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."  <br><br>
-  Plus, the flexibility they now have to use their on-prem Kubernetes cluster when appropriate is "lowering costs and providing us access to hardware that we wouldn’t necessarily have access to in the cloud," he says. "As long as the utilization is high, the costs are much lower in our data center. To an extent, you can also customize your hardware to exactly what you need."
+<p>That path has been simplified by frameworks and tools that two of OpenAI's teams have developed to handle interaction with Kubernetes. "You can just write some Python code, fill out a bit of configuration with exactly how many machines you need and which types, and then it will prepare all of those specifications and send it to the Kube cluster so that it gets launched there," says Berner. "And it also provides a bit of extra monitoring and better tooling that's designed specifically for these machine learning projects."</p>
 
+<p>The impact that Kubernetes has had at OpenAI is impressive. With Kubernetes, the frameworks and tooling, including the autoscaler, in place, launching experiments takes far less time. "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."</p>
 
-</div>
+<p>Plus, the flexibility they now have to use their on-prem Kubernetes cluster when appropriate is "lowering costs and providing us access to hardware that we wouldn't necessarily have access to in the cloud," he says. "As long as the utilization is high, the costs are much lower in our data center. To an extent, you can also customize your hardware to exactly what you need."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "Research teams can now take advantage of the frameworks we’ve built on top of Kubernetes, which make it easy to launch experiments, scale them by 10x or 50x, and take little effort to manage." <br><span style="font-size:14px;letter-spacing:0.12em;padding-top:20px">— CHRISTOPHER BERNER, HEAD OF INFRASTRUCTURE FOR OPENAI</span>
-  </div>
-</div>
+{{< case-studies/quote author="CHRISTOPHER BERNER, HEAD OF INFRASTRUCTURE FOR OPENAI" >}}
+"Research teams can now take advantage of the frameworks we've built on top of Kubernetes, which make it easy to launch experiments, scale them by 10x or 50x, and take little effort to manage."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
+<p>OpenAI is also benefiting from other technologies in the CNCF cloud-native ecosystem. <a href="https://grpc.io/">gRPC</a> is used by many of its systems for communications between different services, and <a href="https://prometheus.io/">Prometheus</a> is in place "as a debugging tool if things go wrong," says Berner. "We actually haven't had any real problems in our Kubernetes clusters recently, so I don't think anyone has looked at our Prometheus monitoring in a while. If something breaks, it will be there."</p>
 
-  OpenAI is also benefiting from other technologies in the CNCF cloud-native ecosystem. <a href="https://grpc.io/">gRPC</a> is used by many of its systems for communications between different services, and <a href="https://prometheus.io/">Prometheus</a> is in place "as a debugging tool if things go wrong," says Berner. "We actually haven’t had any real problems in our Kubernetes clusters recently, so I don’t think anyone has looked at our Prometheus monitoring in a while. If something breaks, it will be there."<br><br>
-  One of the things Berner continues to focus on is Kubernetes’ ability to scale, which is essential to deep learning experiments. OpenAI has been able to push one of its Kubernetes clusters on Azure up to more than <a href="https://blog.openai.com/scaling-kubernetes-to-2500-nodes/">2,500 nodes</a>. "I think we’ll probably hit the 5,000-machine number that Kubernetes has been tested at before too long," says Berner, adding, "We’re definitely <a href="https://jobs.lever.co/openai">hiring</a> if you’re excited about working on these things!"
-</div>
-
-</section>
+<p>One of the things Berner continues to focus on is Kubernetes' ability to scale, which is essential to deep learning experiments. OpenAI has been able to push one of its Kubernetes clusters on Azure up to more than <a href="https://blog.openai.com/scaling-kubernetes-to-2500-nodes/">2,500 nodes</a>. "I think we'll probably hit the 5,000-machine number that Kubernetes has been tested at before too long," says Berner, adding, "We're definitely <a href="https://jobs.lever.co/openai">hiring</a> if you're excited about working on these things!"</p>
diff --git a/content/en/case-studies/peardeck/index.html b/content/en/case-studies/peardeck/index.html
index 688754a620..4398277677 100644
--- a/content/en/case-studies/peardeck/index.html
+++ b/content/en/case-studies/peardeck/index.html
@@ -1,111 +1,87 @@
 ---
 title: Pear Deck Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_peardeck.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/peardeck/banner3.jpg
+heading_title_logo: /images/peardeck_logo.png
+subheading: >
+  Infrastructure for a Growing EdTech Startup
+case_study_details:
+  - Company: Pear Deck
+  - Location: Iowa City, Iowa
+  - Industry: Educational Software
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/peardeck_logo.png"  width="22%" style="margin-bottom:-0px"><br> <div class="subhead">Infrastructure for a Growing EdTech Startup</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript app was built on Google's web app development platform <a href="https://firebase.google.com/">Firebase</a>, using <a href="https://www.heroku.com/">Heroku</a>. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn't have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.</p>
 
-<div class="details">
-    Company &nbsp;<b>Pear Deck</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Iowa City, Iowa</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Educational Software</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>In 2016, the company began moving their code from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.</p>
 
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-      The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript app was built on Google’s web app development platform <a href="https://firebase.google.com/">Firebase</a>, using <a href="https://www.heroku.com/">Heroku</a>. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
-</div>
-
-<div class="col2">
-  <h2>Solution</h2>
-    In 2016, the company began moving their code from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.
-    <br>
-    <br>
 <h2>Impact</h2>
-      The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."
-</div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app. I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."<br><br><span style="font-size:16px;letter-spacing:2px;">– RILEY EYNON-LYNCH, CEO OF PEAR DECK</span>
-  </div>
-</div>
+<p>The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating.</h2>
-As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It’s a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."<br><br>
-Eynon-Lynch and his partners quickly built a JavaScript web app on Google’s web app development platform <a href="https://firebase.google.com/">Firebase</a>, and launched the minimum viable product [MVP] on <a href="https://www.heroku.com/">Heroku</a> "because it was fast and easy," he says. "We made everything as easy as we could."
-<br><br>
-But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version. Tracing and monitoring became basically impossible."
-<br><br>
-On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
-<br><br>
-The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.
-</div>
-</section>
+{{< case-studies/quote author="RILEY EYNON-LYNCH, CEO OF PEAR DECK" >}}
+"We didn't even realize how stressed out we were about our lack of insight into what was happening with the app. I'm really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."
+{{< /case-studies/quote >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch.
-  </div>
-</div>
+{{< case-studies/lead >}}
+With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating.
+{{< /case-studies/lead >}}
 
-<section class="section3">
-<div class="fullcol">
-  They had considered other options like Google’s App Engine (which they were already using for one service) and Amazon’s <a href="https://aws.amazon.com/ec2/">Elastic Compute Cloud</a> (EC2), while experimenting with running one small service that wasn’t accessible to the Internet in Kubernetes. "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn’t really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."<br><br>
-  Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never   staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that’s always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it’s become invisible how great it is."
-  <br><br>
-  Along with Kubernetes came Prometheus. "Until pretty recently we didn’t have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use Google Kubernetes Engine’s <a href="https://cloud.google.com/stackdriver/">Stackdriver</a> monitoring, but had problems making it work, and considered <a href="https://newrelic.com/">New Relic</a>. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.<br><br>
-  The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
-</div>
-</section>
+<p>As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It's a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
-  </div>
-</div>
+<p>Eynon-Lynch and his partners quickly built a JavaScript web app on Google's web app development platform <a href="https://firebase.google.com/">Firebase</a>, and launched the minimum viable product [MVP] on <a href="https://www.heroku.com/">Heroku</a> "because it was fast and easy," he says. "We made everything as easy as we could."</p>
 
-<section class="section4">
-<div class="fullcol">
-  With Pear Deck’s specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn’t working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.<br><br>
-  To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren’t going to have to figure out, ‘Where do we send these metrics? How do we aggregate the metrics? How do we understand them?’"<br><br>
-  Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day’s loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we’re using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."<br><br>
-  Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it’s not a widespread problem. "Just to be sure, we can go and double check the graphs and say, ‘Yep, there’s currently 10,000 people connected to that Firebase node. It’s definitely working. Let’s investigate your network settings, customer,’" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."<br><br>
-  Pear Deck is also giving back to the community, building and open-sourcing a <a href="https://github.com/peardeck/prometheus-user-metrics">metrics aggregator</a> that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."<br><br>
-  Most of Pear Deck’s services have now been moved onto Kubernetes. And all of the team’s new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.
-</div>
-</section>
+<p>But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn't have the developers quickly stage a version. Tracing and monitoring became basically impossible."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says.
-  </div>
-</div>
+<p>On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.</p>
 
-<section class="section5">
-<div class="fullcol">
-  Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that’s still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there’s autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it’s definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it’s such a pain to deploy it."
-<br><br>
-They’re also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we’re interested in building our own web-socket solution that doesn’t have to be super stateful but will have maybe an hour’s worth of state on it."
-<br><br>
-That project will also involve Prometheus, for a dark launch of web socket connections. "We don’t know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don’t know what work Firebase has done to make them more reliable. So I’m really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it’s working. That’s our next new adventure, into stateful servers."
-<br><br>
-As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven’t instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they’re down, which sometimes they don’t do for a long time. So I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."
-<br><br>
-For a spry startup that’s continuing to grow rapidly—and yes, they’re <a href="https://www.peardeck.com/careers/">hiring</a>!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."
+<p>The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.</p>
 
-  <br><br>
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/peardeck/banner1.jpg" >}}
+"When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch.
+{{< /case-studies/quote >}}
+
+<p>They had considered other options like Google's App Engine (which they were already using for one service) and Amazon's <a href="https://aws.amazon.com/ec2/">Elastic Compute Cloud</a> (EC2), while experimenting with running one small service that wasn't accessible to the Internet in Kubernetes. "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn't really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."</p>
+
+<p>Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never   staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that's always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it's become invisible how great it is."</p>
+
+<p>Along with Kubernetes came Prometheus. "Until pretty recently we didn't have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use Google Kubernetes Engine's <a href="https://cloud.google.com/stackdriver/">Stackdriver</a> monitoring, but had problems making it work, and considered <a href="https://newrelic.com/">New Relic</a>. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.</p>
+
+<p>The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"</p>
+
+{{< case-studies/quote image="/images/case-studies/peardeck/banner2.jpg" >}}
+"We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
+{{< /case-studies/quote >}}
+
+<p>With Pear Deck's specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn't even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn't working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.</p>
+
+<p>To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren't going to have to figure out, 'Where do we send these metrics? How do we aggregate the metrics? How do we understand them?'"</p>
+
+<p>Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day's loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we're using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."</p>
+
+<p>Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it's not a widespread problem. "Just to be sure, we can go and double check the graphs and say, 'Yep, there's currently 10,000 people connected to that Firebase node. It's definitely working. Let's investigate your network settings, customer,'" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."</p>
+
+<p>Pear Deck is also giving back to the community, building and open-sourcing a <a href="https://github.com/peardeck/prometheus-user-metrics">metrics aggregator</a> that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."</p>
+
+<p>Most of Pear Deck's services have now been moved onto Kubernetes. And all of the team's new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.</p>
+
+{{< case-studies/quote >}}
+"A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says.
+{{< /case-studies/quote >}}
+
+<p>Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that's still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there's autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it's definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it's such a pain to deploy it."</p>
+
+<p>They're also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we're interested in building our own web-socket solution that doesn't have to be super stateful but will have maybe an hour's worth of state on it."</p>
+
+<p>That project will also involve Prometheus, for a dark launch of web socket connections. "We don't know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don't know what work Firebase has done to make them more reliable. So I'm really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it's working. That's our next new adventure, into stateful servers."</p>
+
+<p>As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven't instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they're down, which sometimes they don't do for a long time. So I'm really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."</p>
+
+<p>For a spry startup that's continuing to grow rapidly—and yes, they're <a href="https://www.peardeck.com/careers/">hiring</a>!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."</p>
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html
index 78f70228e5..501bcea8e7 100644
--- a/content/en/case-studies/pearson/index.html
+++ b/content/en/case-studies/pearson/index.html
@@ -3,85 +3,81 @@ title: Pearson Case Study
 linkTitle: Pearson
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
 quote: >
-  We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
+  We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/pearson/banner1.jpg
+heading_title_logo: /images/pearson_logo.png
+subheading: >
+  Reinventing the World's Largest Education Company With Kubernetes
+case_study_details:
+  - Company: Pearson
+  - Location: Global
+  - Industry: Education
 ---
-<div class="banner1" style="background-image: url('/images/case-studies/pearson/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/pearson_logo.png" style="margin-bottom:-1.5%;" class="header_logo"><br> <div class="subhead">Reinventing the World’s Largest Education Company With Kubernetes
-  </div></h1>
-</div>
-<div class="details">
-  Company &nbsp;<b>Pearson</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Global
-  </b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Education</b>
-</div>
-<hr>
-<section class="section1">
-  <div class="cols">
-    <div class="col1">
-      <h2>Challenge</h2>
-      A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.
-      <br>
-      <h2>Solution</h2>
-      "To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity."
-      <br>
-    </div>
-    <div class="col2">
-      <h2>Impact</h2>
-      With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they’ve achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there’s high confidence in their ability to meet aggressive customer SLAs.
-      <br>
-    </div>
-  </div>
-</section>
-<div class="banner2" style="padding-top:% !important">
-  <div class="banner2text" style="width:70% !important">
-    "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."<br><br><span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;">— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span>
-  </div>
-</div>
-<section class="section2">
-  <div class="fullcol">
-    In 2015, Pearson was already serving 75 million learners as the world’s largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.<br><br>
-    That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." <br><br>
-    With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity," he says.<br><br>
-    The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
-  </div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/pearson/banner3.jpg')">
-  <div class="banner3text">
-    "Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."<span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span>
-  </div>
-</div>
-<section class="section3">
-  <div class="fullcol">
-    That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We’re an education company, so we want to share what we can," says Somogyi.<br><br>
-    Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.  <br><br>
-    According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers’ preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."<br><br>
-    Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
-  </div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/pearson/banner4.jpg')">
-  <div class="banner4text">
-    "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!" <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span>
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-  <div class="fullcol">
-    Availability has also been positively impacted. The back-to-school period is the company’s busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.
-    <br><br>
-    "You can’t even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."
-    <br><br>
-    The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."
-    <br><br>
-    Guided by Pearson’s overarching goal of getting to 200 million users, the team has run internal tests of the platform’s scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to <a href="https://locust.io/">Locust</a>for that one. So that’s amazing."
-  </div>
-  <div class="banner5">
-    <div class="banner5text">
-      "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can’t even begin to put a price on how much that saves the company." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Benjamin Somogyi, Principal Systems Architect at Pearson</span></div>
-    </div>
-    <div class="fullcol">
-      In just two years, "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."<br><br>
-      So far, about 15 production products are running on the new platform, including Pearson’s new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley. <br><br>
-      But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven’t started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."
-    </div>
-  </section>
+
+<h2>Challenge</h2>
+
+<p>A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.</p>
+
+<h2>Solution</h2>
+
+<p>"To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers' productivity."</p>
+
+<h2>Impact</h2>
+
+<p>With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we've gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they've achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there's high confidence in their ability to meet aggressive customer SLAs.</p>
+
+{{< case-studies/quote author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson" >}}
+"We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
+{{< /case-studies/quote >}}
+
+<p>In 2015, Pearson was already serving 75 million learners as the world's largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.</p>
+
+<p>That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way."</p>
+
+<p>With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers' productivity," he says.</p>
+
+<p>The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes' benefits are huge. We're trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/pearson/banner3.jpg"
+  author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson"
+>}}
+"Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."
+{{< /case-studies/quote >}}
+
+<p>That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We're an education company, so we want to share what we can," says Somogyi.</p>
+
+<p>Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we've gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.</p>
+
+<p>According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers' preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."</p>
+
+<p>Jackson estimates they've achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/pearson/banner4.jpg"
+  author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson"
+>}}
+"Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
+{{< /case-studies/quote >}}
+
+<p>Availability has also been positively impacted. The back-to-school period is the company's busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We're not worried about 9s. There aren't any. It's 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.</p>
+
+<p>"You can't even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."</p>
+
+<p>The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."</p>
+
+<p>Guided by Pearson's overarching goal of getting to 200 million users, the team has run internal tests of the platform's scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to <a href="https://locust.io/">Locust</a>for that one. So that's amazing."</p>
+
+{{< case-studies/quote author="Benjamin Somogyi, Principal Systems Architect at Pearson" >}}
+"We have 100% uptime. We're not worried about 9s. There aren't any. It's 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can't even begin to put a price on how much that saves the company."
+{{< /case-studies/quote >}}
+
+<p>In just two years, "We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."</p>
+
+<p>So far, about 15 production products are running on the new platform, including Pearson's new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley.</p>
+
+<p>But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven't started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."</p>
diff --git a/content/en/case-studies/pingcap/index.html b/content/en/case-studies/pingcap/index.html
index 8d032c7a8b..07c1e3e086 100644
--- a/content/en/case-studies/pingcap/index.html
+++ b/content/en/case-studies/pingcap/index.html
@@ -3,94 +3,77 @@ title: pingcap Case Study
 linkTitle: pingcap
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/pingcap/banner1.jpg
+heading_title_logo: /images/pingcap_logo.png
+subheading: >
+  PingCAP Bets on Cloud Native for Its TiDB Database Platform
+case_study_details:
+  - Company: PingCAP
+  - Location: Beijing, China, and San Mateo, CA
+  - Industry: Software
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/pingcap/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/pingcap_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.5%"><br> <div class="subhead" style="margin-top:1%">PingCAP Bets on Cloud Native for Its TiDB Database Platform
+<h2>Challenge</h2>
 
-</div></h1>
+<p>PingCAP is the company leading the development of the popular open source NewSQL database <a href="https://github.com/pingcap/tidb">TiDB</a>, which is MySQL-compatible, can handle hybrid transactional and analytical processing (HTAP) workloads, and has a cloud native architectural design. "Having a hybrid multi-cloud product is an important part of our global go-to-market strategy," says Kevin Xu, General Manager of Global Strategy and Operations. In order to achieve that, the team had to address two challenges: "how to deploy, run, and manage a distributed stateful application, such as a distributed database like TiDB, in a containerized world," Xu says, and "how to deliver an easy-to-use, consistent, and reliable experience for our customers when they use TiDB in the cloud, any cloud, whether that's one cloud provider or a combination of different cloud environments." Knowing that using a distributed system isn't easy, they began looking for the right orchestration layer to help reduce some of that complexity for end users.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>PingCAP</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Beijing, China, and San Mateo, CA</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Software</b>
-</div>
+<p>The team started looking at Kubernetes for orchestration early on. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature." In early 2018, PingCAP began integrating Kubernetes into its internal development as well as in its TiDB product. At that point, the team has already had experience using other cloud native technologies, having integrated both <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grpc.io/">gRPC</a> as parts of the TiDB platform earlier on.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    PingCAP is the company leading the development of the popular open source NewSQL database <a href="https://github.com/pingcap/tidb">TiDB</a>, which is MySQL-compatible, can handle hybrid transactional and analytical processing (HTAP) workloads, and has a cloud native architectural design. "Having a hybrid multi-cloud product is an important part of our global go-to-market strategy," says Kevin Xu, General Manager of Global Strategy and Operations. In order to achieve that, the team had to address two challenges: "how to deploy, run, and manage a distributed stateful application, such as a distributed database like TiDB, in a containerized world," Xu says, and "how to deliver an easy-to-use, consistent, and reliable experience for our customers when they use TiDB in the cloud, any cloud, whether that’s one cloud provider or a combination of different cloud environments." Knowing that using a distributed system isn’t easy, they began looking for the right orchestration layer to help reduce some of that complexity for end users.
-    <h2>Solution</h2>
-    The team started looking at Kubernetes for orchestration early on. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature." In early 2018, PingCAP began integrating Kubernetes into its internal development as well as in its TiDB product. At that point, the team has already had experience using other cloud native technologies, having integrated both <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grpc.io/">gRPC</a> as parts of the TiDB platform earlier on.
-<br>
 <h2>Impact</h2>
-    Xu says that PingCAP customers have had a "very positive" response so far to Kubernetes being the tool to deploy and manage TiDB. Prometheus, with <a href="https://grafana.com/">Grafana</a> as the dashboard, is installed by default when customers deploy TiDB, so that they can monitor performance and make any adjustments needed to reach their target before and while deploying TiDB in production. That monitoring layer "makes the evaluation process and communication much smoother," says Xu.
-<br><br>
-    With the company’s <a href="https://github.com/pingcap/tidb-operator">Kubernetes-based Operator implementation</a>, which is open sourced, customers are now able to deploy, run, manage, upgrade, and maintain their TiDB clusters in the cloud with no downtime, and reduced workload, burden and overhead. And internally, says Xu, "we’ve completely switched to Kubernetes for our own development and testing, including our data center infrastructure and <a href="https://thenewstack.io/chaos-tools-and-techniques-for-testing-the-tidb-distributed-newsql-database/">Schrodinger</a>, an automated testing platform for TiDB. With Kubernetes, our resource usage is greatly improved. Our developers can allocate and deploy clusters themselves, and the deploying process has gone from hours to minutes, so we can devote fewer people to manage IDC resources. The productivity improvement is about 15%, and as we gain more Kubernetes knowledge on the debugging and diagnosis front, the productivity should improve to more than 20%."
 
-</div>
+<p>Xu says that PingCAP customers have had a "very positive" response so far to Kubernetes being the tool to deploy and manage TiDB. Prometheus, with <a href="https://grafana.com/">Grafana</a> as the dashboard, is installed by default when customers deploy TiDB, so that they can monitor performance and make any adjustments needed to reach their target before and while deploying TiDB in production. That monitoring layer "makes the evaluation process and communication much smoother," says Xu.</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We knew Kubernetes had the promise of helping us solve our problems. We were just waiting for it to mature, so we can fold it into our own development and product roadmap."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Since it was introduced in 2015, the open source NewSQL database TiDB has gained a following for its compatibility with MySQL, its ability to handle hybrid transactional and analytical processing (HTAP) workloads—and its cloud native architectural design.</h2>
-  PingCAP, the company behind TiDB, designed the platform with cloud in mind from day one, says Kevin Xu, General Manager of Global Strategy and Operations, and "having a hybrid multi-cloud product is an important part of our global go-to-market strategy."
-<br><br>
-  In order to achieve that, the team had to address two challenges: "how to deploy, run, and manage a distributed stateful application, such as a distributed database like TiDB, in a containerized world," Xu says, and "how to deliver an easy-to-use, consistent, and reliable experience for our customers when they use TiDB in the cloud, any cloud, whether that’s one cloud provider or a combination of different cloud environments."
-<br><br>
-  Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/pingcap/banner3.jpg')">
-  <div class="banner3text">
-    "With the governance process being so open, it’s not hard to find out what’s the latest development in the technology and community, or figure out who to reach out to if we have problems or issues."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP</span>
+<p>With the company's <a href="https://github.com/pingcap/tidb-operator">Kubernetes-based Operator implementation</a>, which is open sourced, customers are now able to deploy, run, manage, upgrade, and maintain their TiDB clusters in the cloud with no downtime, and reduced workload, burden and overhead. And internally, says Xu, "we've completely switched to Kubernetes for our own development and testing, including our data center infrastructure and <a href="https://thenewstack.io/chaos-tools-and-techniques-for-testing-the-tidb-distributed-newsql-database/">Schrodinger</a>, an automated testing platform for TiDB. With Kubernetes, our resource usage is greatly improved. Our developers can allocate and deploy clusters themselves, and the deploying process has gone from hours to minutes, so we can devote fewer people to manage IDC resources. The productivity improvement is about 15%, and as we gain more Kubernetes knowledge on the debugging and diagnosis front, the productivity should improve to more than 20%."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  That time came in early 2018, when PingCAP began integrating Kubernetes into its internal development as well as in its TiDB product. "Having Kubernetes be part of the CNCF, as opposed to having only the backing of one individual company, was valuable in having confidence in the longevity of the technology," says Xu. Plus, "with the governance process being so open, it’s not hard to find out what’s the latest development in the technology and community, or figure out who to reach out to if we have problems or issues."
-<br><br>
-  TiDB’s cloud native architecture consists of a stateless SQL layer (also called TiDB) and a persistent key-value storage layer that supports distributed transactions (<a href="https://github.com/tikv/tikv">TiKV</a>, which is now in the CNCF Sandbox), which are loosely coupled. "You can scale both out or in depending on your computation and storage needs, and the two scaling processes can happen independent of each other," says Xu. The PingCAP team also built the <a href="https://github.com/pingcap/tidb-operator">TiDB Operator</a> based on Kubernetes, which helps bootstrap a TiDB cluster on any cloud environment and simplifies and automates deployment, scaling, scheduling, upgrades, and maintenance. The company also recently previewed its fully-managed <a href="https://www.pingcap.com/blog/announcing-tidb-cloud-managed-as-a-service-and-in-the-marketplace/">TiDB Cloud</a> offering.
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/pingcap/banner4.jpg')">
-  <div class="banner4text">
-  "A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It’s both a cost reducer and a money maker." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP</span>
-  </div>
-</div>
+{{< case-studies/quote author="KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP" >}}
+"We knew Kubernetes had the promise of helping us solve our problems. We were just waiting for it to mature, so we can fold it into our own development and product roadmap."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  The entire TiDB platform leverages Kubernetes and other cloud native technologies, including <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://grpc.io/">gRPC</a> for interservice communication.
-<br><br>
-  So far, the customer response to the Kubernetes-enabled platform has been "very positive." Prometheus, with <a href="https://grafana.com/">Grafana</a> as the dashboard, is installed by default when customers deploy TiDB, so that they can monitor and make any adjustments needed to reach their performance requirements before deploying TiDB in production. That monitoring layer "makes the evaluation process and communication much smoother," says Xu. With the company’s Kubernetes-based Operator implementation, customers are now able to deploy, run, manage, upgrade, and maintain their TiDB clusters in the cloud with no downtime, and reduced workload, burden and overhead.
-<br><br>
-  These technologies have also had an impact internally. "We’ve completely switched to Kubernetes for our own development and testing, including our data center infrastructure and <a href="https://thenewstack.io/chaos-tools-and-techniques-for-testing-the-tidb-distributed-newsql-database/">Schrodinger</a>, an automated testing platform for TiDB," says Xu. "With Kubernetes, our resource usage is greatly improved. Our developers can allocate and deploy clusters themselves, and the deploying process takes less time, so we can devote fewer people to manage IDC resources.
-</div>
+{{< case-studies/lead >}}
+Since it was introduced in 2015, the open source NewSQL database TiDB has gained a following for its compatibility with MySQL, its ability to handle hybrid transactional and analytical processing (HTAP) workloads—and its cloud native architectural design.
+{{< /case-studies/lead >}}
 
-<div class="banner5" >
-  <div class="banner5text">
-"The entire cloud native community, whether it’s Kubernetes, CNCF in general, or cloud native vendors like us, have all gained enough experience—and have the battle scars to prove it—and are ready to help you succeed."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP</span></div>
-</div>
+<p>PingCAP, the company behind TiDB, designed the platform with cloud in mind from day one, says Kevin Xu, General Manager of Global Strategy and Operations, and "having a hybrid multi-cloud product is an important part of our global go-to-market strategy."</p>
 
-<div class="fullcol">
-  The productivity improvement is about 15%, and as we gain more Kubernetes knowledge on the debugging and diagnosis front, the productivity should improve to more than 20%."
-<br><br>
-  Kubernetes is now a crucial part of PingCAP’s product roadmap. For anyone else considering going cloud native, Xu has this advice: "There’s no better time to get started," he says. "The entire cloud native community, whether it’s Kubernetes, CNCF in general, or cloud native vendors like us, have all gained enough experience—and have the battle scars to prove it—and are ready to help you succeed."
-<br><br>
-  In fact, the PingCAP team has seen more and more customers moving toward a cloud native approach, and for good reason. "IT infrastructure is quickly evolving from a cost-center and afterthought, to the core competency and competitiveness of any company," says Xu. "A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It’s both a cost reducer and a money maker."
+<p>In order to achieve that, the team had to address two challenges: "how to deploy, run, and manage a distributed stateful application, such as a distributed database like TiDB, in a containerized world," Xu says, and "how to deliver an easy-to-use, consistent, and reliable experience for our customers when they use TiDB in the cloud, any cloud, whether that's one cloud provider or a combination of different cloud environments."</p>
 
-</div>
-</section>
+<p>Knowing that using a distributed system isn't easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/pingcap/banner3.jpg"
+  author="KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP"
+>}}
+"With the governance process being so open, it's not hard to find out what's the latest development in the technology and community, or figure out who to reach out to if we have problems or issues."
+{{< /case-studies/quote >}}
+
+<p>That time came in early 2018, when PingCAP began integrating Kubernetes into its internal development as well as in its TiDB product. "Having Kubernetes be part of the CNCF, as opposed to having only the backing of one individual company, was valuable in having confidence in the longevity of the technology," says Xu. Plus, "with the governance process being so open, it's not hard to find out what's the latest development in the technology and community, or figure out who to reach out to if we have problems or issues."</p>
+
+<p>TiDB's cloud native architecture consists of a stateless SQL layer (also called TiDB) and a persistent key-value storage layer that supports distributed transactions (<a href="https://github.com/tikv/tikv">TiKV</a>, which is now in the CNCF Sandbox), which are loosely coupled. "You can scale both out or in depending on your computation and storage needs, and the two scaling processes can happen independent of each other," says Xu. The PingCAP team also built the <a href="https://github.com/pingcap/tidb-operator">TiDB Operator</a> based on Kubernetes, which helps bootstrap a TiDB cluster on any cloud environment and simplifies and automates deployment, scaling, scheduling, upgrades, and maintenance. The company also recently previewed its fully-managed <a href="https://www.pingcap.com/blog/announcing-tidb-cloud-managed-as-a-service-and-in-the-marketplace/">TiDB Cloud</a> offering.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/pingcap/banner4.jpg"
+  author="KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP"
+>}}
+"A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It's both a cost reducer and a money maker."
+{{< /case-studies/quote >}}
+
+<p>The entire TiDB platform leverages Kubernetes and other cloud native technologies, including <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://grpc.io/">gRPC</a> for interservice communication.</p>
+
+<p>So far, the customer response to the Kubernetes-enabled platform has been "very positive." Prometheus, with <a href="https://grafana.com/">Grafana</a> as the dashboard, is installed by default when customers deploy TiDB, so that they can monitor and make any adjustments needed to reach their performance requirements before deploying TiDB in production. That monitoring layer "makes the evaluation process and communication much smoother," says Xu. With the company's Kubernetes-based Operator implementation, customers are now able to deploy, run, manage, upgrade, and maintain their TiDB clusters in the cloud with no downtime, and reduced workload, burden and overhead.</p>
+
+<p>These technologies have also had an impact internally. "We've completely switched to Kubernetes for our own development and testing, including our data center infrastructure and <a href="https://thenewstack.io/chaos-tools-and-techniques-for-testing-the-tidb-distributed-newsql-database/">Schrodinger</a>, an automated testing platform for TiDB," says Xu. "With Kubernetes, our resource usage is greatly improved. Our developers can allocate and deploy clusters themselves, and the deploying process takes less time, so we can devote fewer people to manage IDC resources.</p>
+
+{{< case-studies/quote author="KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP" >}}
+"The entire cloud native community, whether it's Kubernetes, CNCF in general, or cloud native vendors like us, have all gained enough experience—and have the battle scars to prove it—and are ready to help you succeed."
+{{< /case-studies/quote >}}
+
+<p>The productivity improvement is about 15%, and as we gain more Kubernetes knowledge on the debugging and diagnosis front, the productivity should improve to more than 20%."</p>
+
+<p>Kubernetes is now a crucial part of PingCAP's product roadmap. For anyone else considering going cloud native, Xu has this advice: "There's no better time to get started," he says. "The entire cloud native community, whether it's Kubernetes, CNCF in general, or cloud native vendors like us, have all gained enough experience—and have the battle scars to prove it—and are ready to help you succeed."</p>
+
+<p>In fact, the PingCAP team has seen more and more customers moving toward a cloud native approach, and for good reason. "IT infrastructure is quickly evolving from a cost-center and afterthought, to the core competency and competitiveness of any company," says Xu. "A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It's both a cost reducer and a money maker."</p>
diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html
index e4be7031bb..b95fff054a 100644
--- a/content/en/case-studies/pinterest/index.html
+++ b/content/en/case-studies/pinterest/index.html
@@ -3,106 +3,82 @@ title: Pinterest Case Study
 linkTitle: Pinterest
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
 weight: 30
 quote: >
   We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/pinterest/banner1.jpg
+heading_title_logo: /images/pinterest_logo.png
+subheading: >
+  Pinning Its Past, Present, and Future on Cloud Native
+case_study_details:
+  - Company: Pinterest
+  - Location: San Francisco, California
+  - Industry: Web and Mobile App
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/pinterest/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/pinterest_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Pinning Its Past, Present, and Future on Cloud Native
+<p>After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
-
-<div class="details">
-    Company &nbsp;<b>Pinterest</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>San Francisco, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Web and Mobile App</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-<br><br>
-    <h2>Challenge</h2>
-    After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.
-
-<br><br>
-
- <h2>Solution</h2>
-    The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.
-
-<br><br>
+<p>The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.</p>
 
 <h2>Impact</h2>
-  "By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
 
-</div>
-</div>
+<p>"By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."</p>
 
-</section>
-<div class="banner2" style="text-align:center">
-  <iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
-  <div class="banner2text"><br><br>
-"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we&nbsp;were&nbsp;pushing&nbsp;for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest</span>
+{{< case-studies/quote author="Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest" >}}
+<iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<br>
+"So far it's been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- <h2></h2>Pinterest was born on the cloud—running on <a href="https://aws.amazon.com/">AWS</a> since day one in 2010—but even cloud native companies can experience some growing pains.</h2> Since its launch, Pinterest has become a household name, with more than 200 million active monthly users and 100 billion objects saved. Underneath the hood, there are 1,000 microservices running and hundreds of thousands of data jobs.<br><br>
-With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production.
-So in 2016, the company launched a roadmap toward a new compute platform, led by the vision of having the fastest path from an idea to production, without making engineers worry about the underlying infrastructure. <br><br>
-The first phase involved moving to Docker. "Pinterest has been heavily running on virtual machines, on EC2 instances directly, for the longest time," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group. "To solve the problem around packaging software and not make engineers own portions of the fleet and those kinds of challenges, we standardized the packaging mechanism and then moved that to the container on top of the VM. Not many drastic changes. We didn’t want to boil the ocean at that point."
+{{< case-studies/lead >}}
+Pinterest was born on the cloud—running on <a href="https://aws.amazon.com/">AWS</a> since day one in 2010—but even cloud native companies can experience some growing pains.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/pinterest/banner3.jpg')">
-  <div class="banner3text">
-    "Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>Since its launch, Pinterest has become a household name, with more than 200 million active monthly users and 100 billion objects saved. Underneath the hood, there are 1,000 microservices running and hundreds of thousands of data jobs.</p>
 
-The first service that was migrated was the monolith API fleet that powers most of Pinterest. At the same time, Benedict’s infrastructure governance team built chargeback and capacity planning systems to analyze how the company uses its virtual machines on AWS. "It became clear that running on VMs is just not sustainable with what we’re doing," says Benedict. "A lot of resources were underutilized. There were efficiency efforts, which worked fine at a certain scale, but now you have to move to a more decentralized way of managing that. So orchestration was something we thought could help solve that piece."<br><br>
-That led to the second phase of the roadmap. In July 2017, after an eight-week evaluation period, the team chose Kubernetes over other orchestration platforms. "Kubernetes lacked certain things at the time—for example, we wanted Spark on Kubernetes," says Benedict. "But we realized that the dev cycles we would put in to even try building that is well worth the outcome, both for Pinterest as well as the community. We’ve been in those conversations in the Big Data SIG. We realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."<br><br>
-At the beginning of 2018, the team began onboarding its first use case into the Kubernetes system: Jenkins workloads. "Although we have builds happening during a certain period of the day, we always need to allocate peak capacity," says Benedict. "They don’t have any auto-scaling capabilities, so that capacity stays constant. It is difficult to speed up builds because ramping up takes more time. So given those kind of concerns, we thought that would be a perfect use case for us to work on."
+<p>With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production. So in 2016, the company launched a roadmap toward a new compute platform, led by the vision of having the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.</p>
 
+<p>The first phase involved moving to Docker. "Pinterest has been heavily running on virtual machines, on EC2 instances directly, for the longest time," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group. "To solve the problem around packaging software and not make engineers own portions of the fleet and those kinds of challenges, we standardized the packaging mechanism and then moved that to the container on top of the VM. Not many drastic changes. We didn't want to boil the ocean at that point."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/pinterest/banner4.jpg')">
-  <div class="banner4text">
-"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/pinterest/banner3.jpg"
+  author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST"
+>}}
+"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we'll be able to leverage what the community is doing."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
- They ramped up the cluster, and working with a team of four people, got the Jenkins Kubernetes cluster ready for production. "We still have our static Jenkins cluster," says Benedict, "but on Kubernetes, we are doing similar builds, testing the entire pipeline, getting the artifact ready and just doing the comparison to see, how much time did it take to build over here. Is the SLA okay, is the artifact generated correct, are there issues there?" <br><br>
-"So far it’s been good," he adds, "especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."<br><br>
-By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the <a href="https://github.com/jenkinsci/kubernetes-plugin">Jenkins Kubernetes Plugin</a> to manage the lifecycle of workers. "We’re currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
+<p>The first service that was migrated was the monolith API fleet that powers most of Pinterest. At the same time, Benedict's infrastructure governance team built chargeback and capacity planning systems to analyze how the company uses its virtual machines on AWS. "It became clear that running on VMs is just not sustainable with what we're doing," says Benedict. "A lot of resources were underutilized. There were efficiency efforts, which worked fine at a certain scale, but now you have to move to a more decentralized way of managing that. So orchestration was something we thought could help solve that piece."</p>
 
+<p>That led to the second phase of the roadmap. In July 2017, after an eight-week evaluation period, the team chose Kubernetes over other orchestration platforms. "Kubernetes lacked certain things at the time—for example, we wanted Spark on Kubernetes," says Benedict. "But we realized that the dev cycles we would put in to even try building that is well worth the outcome, both for Pinterest as well as the community. We've been in those conversations in the Big Data SIG. We realized that by the time we get to productionizing many of those things, we'll be able to leverage what the community is doing."</p>
 
-</div>
+<p>At the beginning of 2018, the team began onboarding its first use case into the Kubernetes system: Jenkins workloads. "Although we have builds happening during a certain period of the day, we always need to allocate peak capacity," says Benedict. "They don't have any auto-scaling capabilities, so that capacity stays constant. It is difficult to speed up builds because ramping up takes more time. So given those kind of concerns, we thought that would be a perfect use case for us to work on."</p>
 
-<div class="banner5">
-  <div class="banner5text">
- "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/pinterest/banner4.jpg"
+  author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST"
+>}}
+"So far it's been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
- Benedict points to a "pretty robust roadmap" going forward. In addition to the Pinterest big data team’s experiments with Spark on Kubernetes, the company collaborated with Amazon’s EKS team on an ENI/CNI plug in. <br><br>
-Once the Jenkins cluster is up and running out of dark mode, Benedict hopes to establish best practices, including having governance primitives established—including integration with the chargeback system—before moving on to migrating the next service. "We have a healthy pipeline of use-cases to be on-boarded. After Jenkins, we want to enable support for Tensorflow and Apache Spark. At some point, we aim to move the company’s monolithic API service. If we move that and understand the complexity around that, it builds our confidence," says Benedict. "It sets us up for migration of all our other services."<br><br>
-After years of being a cloud native pioneer, Pinterest is eager to share its ongoing journey. "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do," says Benedict. "We’re in a great position to contribute back some of those learnings."
+<p>They ramped up the cluster, and working with a team of four people, got the Jenkins Kubernetes cluster ready for production. "We still have our static Jenkins cluster," says Benedict, "but on Kubernetes, we are doing similar builds, testing the entire pipeline, getting the artifact ready and just doing the comparison to see, how much time did it take to build over here. Is the SLA okay, is the artifact generated correct, are there issues there?"</p>
 
+<p>"So far it's been good," he adds, "especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."</p>
 
+<p>By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the <a href="https://github.com/jenkinsci/kubernetes-plugin">Jenkins Kubernetes Plugin</a> to manage the lifecycle of workers. "We're currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."</p>
 
-</div>
+{{< case-studies/quote author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST">}}
+"We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do."
+{{< /case-studies/quote >}}
 
-</section>
+<p>Benedict points to a "pretty robust roadmap" going forward. In addition to the Pinterest big data team's experiments with Spark on Kubernetes, the company collaborated with Amazon's EKS team on an ENI/CNI plug in.</p>
+
+<p>Once the Jenkins cluster is up and running out of dark mode, Benedict hopes to establish best practices, including having governance primitives established—including integration with the chargeback system—before moving on to migrating the next service. "We have a healthy pipeline of use-cases to be on-boarded. After Jenkins, we want to enable support for Tensorflow and Apache Spark. At some point, we aim to move the company's monolithic API service. If we move that and understand the complexity around that, it builds our confidence," says Benedict. "It sets us up for migration of all our other services."</p>
+
+<p>After years of being a cloud native pioneer, Pinterest is eager to share its ongoing journey. "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do," says Benedict. "We're in a great position to contribute back some of those learnings."</p>
diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html
index 2f0beda5ae..b8b584aa41 100644
--- a/content/en/case-studies/prowise/index.html
+++ b/content/en/case-studies/prowise/index.html
@@ -3,97 +3,81 @@ title: Prowise Case Study
 linkTitle: prowise
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/prowise/banner1.jpg
+heading_title_logo: /images/prowise_logo.png
+subheading: >
+  Prowise: How Kubernetes is Enabling the Edtech Solution's Global Expansion
+case_study_details:
+  - Company: Prowise
+  - Location: Budel, The Netherlands
+  - Industry: Edtech
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/prowise/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/prowise_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%">Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion
-</div></h1>
+<p>A Dutch company that produces educational devices and software used around the world, <a href="https://www.prowise.com/en/">Prowise</a> had an infrastructure based on Linux services with multiple availability zones in Europe, Australia, and the U.S. "We've grown a lot in the past couple of years, and we started to encounter problems with versioning and flexible scaling," says Senior DevOps Engineer Victor van den Bosch, "not only scaling in demands, but also in being able to deploy multiple products which all have their own versions, their own development teams, and their own problems that they're trying to solve. To be able to put that all on the same platform without much resistance is what we were looking for. We wanted to future proof our infrastructure, and also solve some of the problems that are associated with just running a normal Linux service."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Prowise</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Budel, The Netherlands  </b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Edtech</b>
-</div>
+<p>The Prowise team adopted containerization, spent time improving its CI/CD pipelines, and chose Microsoft Azure's managed Kubernetes service, <a href="https://azure.microsoft.com/en-us/services/kubernetes-service/">AKS</a>, for orchestration. "Kubernetes solves things like networking really well, in a way that fits our business model," says van den Bosch. "We want to focus on our core products, and that's the software that runs on it and not necessarily the infrastructure itself."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-
-    <h2>Challenge</h2>
-    A Dutch company that produces educational devices and software used around the world, <a href="https://www.prowise.com/en/">Prowise</a> had an infrastructure based on Linux services with multiple availability zones in Europe, Australia, and the U.S. “We’ve grown a lot in the past couple of years, and we started to encounter problems with versioning and flexible scaling,” says Senior DevOps Engineer Victor van den Bosch, “not only scaling in demands, but also in being able to deploy multiple products which all have their own versions, their own development teams, and their own problems that they’re trying to solve. To be able to put that all on the same platform without much resistance is what we were looking for. We wanted to future proof our infrastructure, and also solve some of the problems that are associated with just running a normal Linux service.”
-    <h2>Solution</h2>
-    The Prowise team adopted containerization, spent time improving its CI/CD pipelines, and chose Microsoft Azure’s managed Kubernetes service, <a href="https://azure.microsoft.com/en-us/services/kubernetes-service/">AKS</a>, for orchestration. “Kubernetes solves things like networking really well, in a way that fits our business model,” says van den Bosch. “We want to focus on our core products, and that’s the software that runs on it and not necessarily the infrastructure itself.”
 <h2>Impact</h2>
-    With its first web-based applications now running in beta on Prowise’s Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. “The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it’s a couple of seconds,” says Senior Developer Bart Haalstra. As a result, adds van den Bosch, “We’ve gone from quarterly releases to a release every month in production. We’re pretty much deploying every hour or just when we find that a feature is ready for production; before, our releases were mostly done on off-hours, where it couldn’t impact our customers, as our confidence in the process was relatively low. Kubernetes has also enabled us to follow up quickly on bugs and implement tweaks to our users with zero downtime between versions. For some bugs we’ve pushed code fixes to production minutes after detection.” Recently, the team launched a new single sign-on solution for use in an internal application. “Due to the resource based architecture of the Kubernetes platform, we were able to bring that application into an entirely new production environment in less than a day, most of that time used for testing after applying the already well-known resource definitions from staging to the new environment,” says van den Bosch. “On a traditional VM this would have likely cost a day or two, and then probably a few weeks to iron out the kinks in our provisioning scripts as we apply updates.”
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "Because of Kubernetes, things have been much easier, our individual applications are better, and we can spend more time on functional implementation. We do not want to go back."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>If you haven’t set foot in a school in awhile, you might be surprised by what you’d see in a digitally connected classroom these days: touchscreen monitors, laptops, tablets, touch tables, and more.</h2>
-  One of the leaders in the space, the Dutch company Prowise, offers an integrated solution of hardware and software to help educators create a more engaging learning environment.
-<br><br>
-  As the company expanded its offerings beyond the Netherlands in recent years—creating multiple availability zones in Europe, Australia, and the U.S., with as many as nine servers per zone—its Linux service-based infrastructure struggled to keep up. “We’ve grown a lot in the past couple of years, and we started to encounter problems with versioning and flexible scaling,” says Senior DevOps Engineer Victor van den Bosch, who was hired by the company in late 2017 to build a new platform.
-<br><br>
-  Prowise’s products support ten languages, so the problem wasn’t just scaling in demands, he adds, “but also in being able to deploy multiple products which all have their own versions, their own development teams, and their own problems that they’re trying to solve. To be able to put that all on the same platform without much resistance is what we were looking for. We wanted to future proof our infrastructure, and also solve some of the problems that are associated with just running a normal Linux service.”
-<br><br>
-  The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/prowise/banner3.jpg')">
-  <div class="banner3text">
-    "You don’t have to go all-in immediately. You can just take a few projects, a service, run it alongside your more traditional stack, and build it up from there. Kubernetes scales, so as you add applications and services to it, it will scale with you. You don’t have to do it all at once, and that’s really a secret to everything, but especially true to Kubernetes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE</span>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  After researching possible solutions, he opted for containerization and Kubernetes orchestration. “Containerization is the future,” van den Bosch says. “Kubernetes solves things like networking really well, in a way that fits our business model. We want to focus on our core products, and that’s the software that runs on it and not necessarily the infrastructure itself.” Plus, the Prowise team liked that there was no vendor lock-in. “We don’t want to be limited to one platform,” he says. “We try not to touch products that are very proprietary and can’t be ported easily to another vendor.”
-<br><br>
-  The time to market with Kubernetes was very short: The first web-based applications on the platform went into beta within a few months. That was largely made possible by van den Bosch’s decision to use Azure’s managed Kubernetes service, AKS. The team then had to figure out which components to keep and which to replace. Monitoring tools like New Relic were taken out “because they tend to become very expensive when you scale it to different availability zones, and it’s just not very maintainable,” he says.
-<br><br>
-  A lot of work also went into improving Prowise’s CI/CD pipelines. “We wanted to make sure that the pipelines are automated and easy to use,” he says. “We have a lot of settings and configurations figured out for the pipelines, and it’s just applying those scripts and those configurations to new projects from here on out.”
-<br><br>
-  With its first web-based applications now running in beta on Prowise’s Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. “The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it’s a couple of seconds,” says Senior Developer Bart Haalstra. As a result, adds van den Bosch, “We’ve gone from quarterly releases to a release every month in production. We’re pretty much deploying every hour or just when we find that a feature is ready for production. Before, our releases were mostly done on off-hours, where it couldn’t impact our customers, as our confidence the process itself was relatively low. With Kubernetes, we dare to deploy in the middle of a busy day with high confidence the deployment will succeed.”
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/prowise/banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-  "Kubernetes allows us to really consider the best tools for a problem. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE</span>
-  </div>
-</div>
+<p>With its first web-based applications now running in beta on Prowise's Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. "The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it's a couple of seconds," says Senior Developer Bart Haalstra. As a result, adds van den Bosch, "We've gone from quarterly releases to a release every month in production. We're pretty much deploying every hour or just when we find that a feature is ready for production; before, our releases were mostly done on off-hours, where it couldn't impact our customers, as our confidence in the process was relatively low. Kubernetes has also enabled us to follow up quickly on bugs and implement tweaks to our users with zero downtime between versions. For some bugs we've pushed code fixes to production minutes after detection." Recently, the team launched a new single sign-on solution for use in an internal application. "Due to the resource based architecture of the Kubernetes platform, we were able to bring that application into an entirely new production environment in less than a day, most of that time used for testing after applying the already well-known resource definitions from staging to the new environment," says van den Bosch. "On a traditional VM this would have likely cost a day or two, and then probably a few weeks to iron out the kinks in our provisioning scripts as we apply updates."</p>
 
-<section class="section5" style="padding:0px !important">
+{{< case-studies/quote author="VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE" >}}
+"Because of Kubernetes, things have been much easier, our individual applications are better, and we can spend more time on functional implementation. We do not want to go back."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  Plus, van den Bosch says, “Kubernetes has enabled us to follow up quickly on bugs and implement tweaks to our users with zero downtime between versions. For some bugs we’ve pushed code fixes to production minutes after detection.”
-<br><br>
-  Recently, the team launched a new single sign-on solution for use in an internal application. “Due to the resource based architecture of the Kubernetes platform, we were able to bring that application into an entirely new production environment in less than a day, most of that time used for testing after applying the already well-known resource definitions from staging to the new environment,” says van den Bosch. “On a traditional VM this would have likely cost a day or two, and then probably a few weeks to iron out the kinks in our provisioning scripts as we apply updates.”
-<br><br>
-  Legacy applications are also being moved to Kubernetes. Not long ago, the team needed to set up a Java-based application for compiling and running a frontend. “On a traditional VM, it would have taken quite a bit of time to set it up and keep it up to date, not to mention maintenance for that setup down the line,” says van den Bosch. Instead, it took less than half a day to Dockerize it and get it running on Kubernetes. “It was much easier, and we were able to save costs too because we didn’t have to spin up new VMs specially for it.”
-</div>
+{{< case-studies/lead >}}
+If you haven't set foot in a school in awhile, you might be surprised by what you'd see in a digitally connected classroom these days: touchscreen monitors, laptops, tablets, touch tables, and more.
+{{< /case-studies/lead >}}
 
-<div class="banner5" >
-  <div class="banner5text">
-"We’re really trying to deliver integrated solutions with our hardware and software and making it as easy as possible for users to use and collaborate from different places,” says van den Bosch. And, says Haalstra, “We cannot do it without Kubernetes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE</span></div>
-</div>
+<p>One of the leaders in the space, the Dutch company Prowise, offers an integrated solution of hardware and software to help educators create a more engaging learning environment.</p>
 
-<div class="fullcol">
-  Perhaps most importantly, van den Bosch says, “Kubernetes allows us to really consider the best tools for a problem and take full advantage of microservices architecture. Got a library in Node.js that excels at solving a certain problem? Use it. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night.”
-<br><br>
-  Looking ahead, all new web development, platforms, and APIs at Prowise will be on Kubernetes. One of the big greenfield projects is a platform for teachers and students that is launching for back-to-school season in September. Users will be able to log in and access a wide variety of educational applications. With the <a href="https://www.prowise.com/en/press-release-largest-dutch-education-innovators-join-forces/">recent acquisition</a> of the software company Oefenweb, Prowise plans to provide adaptive software that allows teachers to get an accurate view of their students’ progress and weak points, and automatically adjusts the difficulty level of assignments to suit individual students. “We will be leveraging Kubernetes’ power to integrate, supplement, and support our combined application portfolio and bring our solutions to more classrooms,” says van den Bosch.
-<br><br>
-  Collaborative software is also a priority. With the single sign-in software, users’ settings and credentials are saved in the cloud and can be used on any screen in the world. “We’re really trying to deliver integrated solutions with our hardware and software and making it as easy as possible for users to use and collaborate from different places,” says van den Bosch. And, says Haalstra, “We cannot do it without Kubernetes.”
-</div>
+<p>As the company expanded its offerings beyond the Netherlands in recent years—creating multiple availability zones in Europe, Australia, and the U.S., with as many as nine servers per zone—its Linux service-based infrastructure struggled to keep up. "We've grown a lot in the past couple of years, and we started to encounter problems with versioning and flexible scaling," says Senior DevOps Engineer Victor van den Bosch, who was hired by the company in late 2017 to build a new platform.</p>
 
-</section>
+<p>Prowise's products support ten languages, so the problem wasn't just scaling in demands, he adds, "but also in being able to deploy multiple products which all have their own versions, their own development teams, and their own problems that they're trying to solve. To be able to put that all on the same platform without much resistance is what we were looking for. We wanted to future proof our infrastructure, and also solve some of the problems that are associated with just running a normal Linux service."</p>
+
+<p>The company's existing infrastructure on Microsoft Azure Cloud was all on virtual machines, "a pretty traditional setup," van den Bosch says. "We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn't really want the hassle of trying to keep those servers in a particular state."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/prowise/banner3.jpg"
+  author="VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE"
+>}}
+"You don't have to go all-in immediately. You can just take a few projects, a service, run it alongside your more traditional stack, and build it up from there. Kubernetes scales, so as you add applications and services to it, it will scale with you. You don't have to do it all at once, and that's really a secret to everything, but especially true to Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>After researching possible solutions, he opted for containerization and Kubernetes orchestration. "Containerization is the future," van den Bosch says. "Kubernetes solves things like networking really well, in a way that fits our business model. We want to focus on our core products, and that's the software that runs on it and not necessarily the infrastructure itself." Plus, the Prowise team liked that there was no vendor lock-in. "We don't want to be limited to one platform," he says. "We try not to touch products that are very proprietary and can't be ported easily to another vendor."</p>
+
+<p>The time to market with Kubernetes was very short: The first web-based applications on the platform went into beta within a few months. That was largely made possible by van den Bosch's decision to use Azure's managed Kubernetes service, AKS. The team then had to figure out which components to keep and which to replace. Monitoring tools like New Relic were taken out "because they tend to become very expensive when you scale it to different availability zones, and it's just not very maintainable," he says.</p>
+
+<p>A lot of work also went into improving Prowise's CI/CD pipelines. "We wanted to make sure that the pipelines are automated and easy to use," he says. "We have a lot of settings and configurations figured out for the pipelines, and it's just applying those scripts and those configurations to new projects from here on out."</p>
+
+<p>With its first web-based applications now running in beta on Prowise's Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. "The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it's a couple of seconds," says Senior Developer Bart Haalstra. As a result, adds van den Bosch, "We've gone from quarterly releases to a release every month in production. We're pretty much deploying every hour or just when we find that a feature is ready for production. Before, our releases were mostly done on off-hours, where it couldn't impact our customers, as our confidence the process itself was relatively low. With Kubernetes, we dare to deploy in the middle of a busy day with high confidence the deployment will succeed."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/prowise/banner4.jpg"
+  author="VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE"
+>}}
+"Kubernetes allows us to really consider the best tools for a problem. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night."
+{{< /case-studies/quote >}}
+
+<p>Plus, van den Bosch says, "Kubernetes has enabled us to follow up quickly on bugs and implement tweaks to our users with zero downtime between versions. For some bugs we've pushed code fixes to production minutes after detection."</p>
+
+<p>Recently, the team launched a new single sign-on solution for use in an internal application. "Due to the resource based architecture of the Kubernetes platform, we were able to bring that application into an entirely new production environment in less than a day, most of that time used for testing after applying the already well-known resource definitions from staging to the new environment," says van den Bosch. "On a traditional VM this would have likely cost a day or two, and then probably a few weeks to iron out the kinks in our provisioning scripts as we apply updates."</p>
+
+<p>Legacy applications are also being moved to Kubernetes. Not long ago, the team needed to set up a Java-based application for compiling and running a frontend. "On a traditional VM, it would have taken quite a bit of time to set it up and keep it up to date, not to mention maintenance for that setup down the line," says van den Bosch. Instead, it took less than half a day to Dockerize it and get it running on Kubernetes. "It was much easier, and we were able to save costs too because we didn't have to spin up new VMs specially for it."</p>
+
+{{< case-studies/quote author="VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE" >}}
+"We're really trying to deliver integrated solutions with our hardware and software and making it as easy as possible for users to use and collaborate from different places," says van den Bosch. And, says Haalstra, "We cannot do it without Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>Perhaps most importantly, van den Bosch says, "Kubernetes allows us to really consider the best tools for a problem and take full advantage of microservices architecture. Got a library in Node.js that excels at solving a certain problem? Use it. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night."</p>
+
+<p>Looking ahead, all new web development, platforms, and APIs at Prowise will be on Kubernetes. One of the big greenfield projects is a platform for teachers and students that is launching for back-to-school season in September. Users will be able to log in and access a wide variety of educational applications. With the <a href="https://www.prowise.com/en/press-release-largest-dutch-education-innovators-join-forces/">recent acquisition</a> of the software company Oefenweb, Prowise plans to provide adaptive software that allows teachers to get an accurate view of their students' progress and weak points, and automatically adjusts the difficulty level of assignments to suit individual students. "We will be leveraging Kubernetes' power to integrate, supplement, and support our combined application portfolio and bring our solutions to more classrooms," says van den Bosch.</p>
+
+<p>Collaborative software is also a priority. With the single sign-in software, users' settings and credentials are saved in the cloud and can be used on any screen in the world. "We're really trying to deliver integrated solutions with our hardware and software and making it as easy as possible for users to use and collaborate from different places," says van den Bosch. And, says Haalstra, "We cannot do it without Kubernetes."</p>
diff --git a/content/en/case-studies/ricardo-ch/index.html b/content/en/case-studies/ricardo-ch/index.html
index 2863ceac75..26a1975ab4 100644
--- a/content/en/case-studies/ricardo-ch/index.html
+++ b/content/en/case-studies/ricardo-ch/index.html
@@ -3,96 +3,77 @@ title: ricardo.ch Case Study
 linkTitle: ricardo-ch
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ricardoch/banner1.png
+heading_title_logo: /images/ricardoch_logo.png
+subheading: >
+  ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony
+case_study_details:
+  - Company: ricardo.ch
+  - Location: Zurich, Switzerland
+  - Industry: E-commerce
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/ricardoch/banner1.png')">
-  <h1> CASE STUDY:<img src="/images/ricardoch_logo.png" class="/images/header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%">ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>A Swiss online marketplace, <a href="https://www.ricardo.ch/de/">ricardo.ch</a> was experiencing problems with velocity, as well as a "classic gap" between Development and Operations, with the two sides unable to work well together. "They wanted to, but they didn't have common ground," says Cedric Meury, Head of Platform Engineering. "This was one of the root causes that slowed us down." The company began breaking down the legacy monolith into microservices, and needed orchestration to support the new architecture in its own data centers—as well as bring together Dev and Ops.</p>
 
-<div class="details">
-    Company &nbsp;<b>ricardo.ch</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Zurich, Switzerland  </b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>E-commerce</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
+<p>The company adopted <a href="https://kubernetes.io/">Kubernetes</a> for cluster management, <a href="https://prometheus.io/">Prometheus</a> for monitoring, and <a href="https://www.fluentd.org/">Fluentd</a> for logging. The first cluster was deployed on premise in December 2016, with the first service in production three months later. The migration is about half done, and the company plans to move completely to <a href="https://cloud.google.com/">Google Cloud Platform</a> by the end of 2018.</p>
 
-    <h2>Challenge</h2>
-    A Swiss online marketplace, <a href="https://www.ricardo.ch/de/">ricardo.ch</a> was experiencing problems with velocity, as well as a "classic gap" between Development and Operations, with the two sides unable to work well together. "They wanted to, but they didn’t have common ground," says Cedric Meury, Head of Platform Engineering. "This was one of the root causes that slowed us down." The company began breaking down the legacy monolith into microservices, and needed orchestration to support the new architecture in its own data centers—as well as bring together Dev and Ops.
-    <h2>Solution</h2>
-    The company adopted <a href="https://kubernetes.io/">Kubernetes</a> for cluster management, <a href="https://prometheus.io/">Prometheus</a> for monitoring, and <a href="https://www.fluentd.org/">Fluentd</a> for logging. The first cluster was deployed on premise in December 2016, with the first service in production three months later. The migration is about half done, and the company plans to move completely to <a href="https://cloud.google.com/">Google Cloud Platform</a> by the end of 2018.
 <h2>Impact</h2>
-    Splitting up the monolith into microservices "allowed higher velocity, and Kubernetes was crucial to support that," says Meury. The number of deployments to production has gone from fewer than 10 a week to 30-60 per day. Before, "when there was a problem with something in production, tickets or complaints would be thrown over the wall to operations, the classical problem. Now, people have the chance to look into operations and troubleshoot for themselves first because everything is deployed in a standardized way," says Meury. He sees the impact in everyday interactions:  "A couple of weeks ago, I saw a product manager doing a pull request for a JSON file that contains some variables, and someone else accepted it. And it was deployed after a couple of minutes or seconds even, which was unthinkable before. There used to be quite a chain of things that needed to happen, the whole monolith was difficult to understand, even for engineers. So, previously requests would go into large, inefficient Kanban boards and hopefully someone will have done the change after weeks and months." Before, infrastructure- and platform-related projects took months or years to complete; now developers and operators can work together to deploy infrastructure parts via Kubernetes in a matter of weeks and sometimes days. In the long run, the company also expects to notch 50% cost savings going from custom data center and virtual machines to containerized infrastructure and cloud services.
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-  "Splitting up the monolith allowed higher velocity, and Kubernetes was crucial to support that. Containerization and orchestration by Kubernetes helped us to drastically reduce the conflict between Dev and Ops and also allowed us to speak the same language on both sides of the aisle."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  <h2>When Cedric Meury joined ricardo.ch in 2016, he saw a clear divide between Operations and Development. In fact, there was literal distance between them: The engineering team worked in France, while the rest of the org was based in Switzerland.
- </h2><br><br>
- "It was a classic gap between those departments and even some anger and frustration here and there," says Meury. "They wanted to work together, but they didn’t have common ground. This was one of the root causes that slowed us down."
-<br><br>
-  That gap was hurting velocity at ricardo.ch, a Swiss online marketplace. The website processes up to 2.6 million searches on a peak day from both web and mobile apps, serving 3.2 million members with its live auctions. The technology team’s main challenge was to make sure that "the bids for items come in the right order, and before the auction is finished, and that this works in a fair way," says Meury. "We have a real-time requirement. We also provide an automated system to bid, and it needs to be accurate and correct. With a distributed system, you have the challenge of making sure that the ordering is right. And that’s one of the things we’re currently dealing with."
-<br><br>
-  To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ricardoch/banner3.png')">
-  <div class="banner3text">
-    "Being in the End User Community demonstrates that we stand behind these technologies. In Switzerland, if all the companies see that ricardo.ch’s using it, I think that will help adoption. I also like that we’re connected to the other end users, so if there is a really heavy problem, I could go to the Slack channel, and say, ‘Hey, you guys…’ Like Reddit, Github and New York Times or whoever can give a recommendation on what to use here or how to solve that. So that’s kind of a superpower."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH</span>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>Splitting up the monolith into microservices "allowed higher velocity, and Kubernetes was crucial to support that," says Meury. The number of deployments to production has gone from fewer than 10 a week to 30-60 per day. Before, "when there was a problem with something in production, tickets or complaints would be thrown over the wall to operations, the classical problem. Now, people have the chance to look into operations and troubleshoot for themselves first because everything is deployed in a standardized way," says Meury. He sees the impact in everyday interactions:  "A couple of weeks ago, I saw a product manager doing a pull request for a JSON file that contains some variables, and someone else accepted it. And it was deployed after a couple of minutes or seconds even, which was unthinkable before. There used to be quite a chain of things that needed to happen, the whole monolith was difficult to understand, even for engineers. So, previously requests would go into large, inefficient Kanban boards and hopefully someone will have done the change after weeks and months." Before, infrastructure- and platform-related projects took months or years to complete; now developers and operators can work together to deploy infrastructure parts via Kubernetes in a matter of weeks and sometimes days. In the long run, the company also expects to notch 50% cost savings going from custom data center and virtual machines to containerized infrastructure and cloud services.</p>
 
-  The company also began breaking down the legacy monolith into more than 100 microservices, and needed orchestration to support the new architecture in its own data centers. "Splitting up the monolith allowed higher velocity, and Kubernetes was crucial to support that," says Meury. "Containerization and orchestration by Kubernetes helped us to drastically reduce the conflict between Dev and Ops and also allowed us to speak the same language on both sides of the aisle."
-<br><br>
-  Meury put together a platform engineering team to choose the tools—including Fluentd for logging and Prometheus for monitoring, with Grafana visualization—and lay the groundwork for the first Kubernetes cluster, which was installed on premise in December 2016. Within a few weeks, the new platform was available to teams, who were given training sessions and documentation. The platform engineering team then embedded with engineers to help them deploy their applications on the new platform. The first service in production was the ricardo.ch jobs page. "It was an exercise in front-end development, so the developers could experiment with a new stack," says Meury.
-<br><br>
-  Meury estimates that half of the application has been migrated to Kubernetes. And the plan is to move everything to the Google Cloud Platform by the end of 2018. "We are still running some servers in our own data centers, but all of the containerization efforts and describing our services as Kubernetes manifests will allow us to quite easily make that shift," says Meury.
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ricardoch/banner4.png')" style="width:100%">
-  <div class="banner4text">
-    "One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH</span>
-  </div>
-</div>
+{{< case-studies/quote author="CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH" >}}
+"Splitting up the monolith allowed higher velocity, and Kubernetes was crucial to support that. Containerization and orchestration by Kubernetes helped us to drastically reduce the conflict between Dev and Ops and also allowed us to speak the same language on both sides of the aisle."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  The impact has been great. Moving from custom data center and virtual machines to containerized infrastructure and cloud services is expected to result in 50% cost savings for the company. The number of deployments to production has gone from fewer than 10 a week to 30-60 per day. Before, "when there was a problem with something in production, tickets or complaints would be thrown over the wall to operations, the classical problem," says Meury. "Now, people have the chance to look into operations and troubleshoot for themselves first because everything is deployed in a standardized way. That reduces time and uncertainty."
-<br><br>
-  Meury also sees the impact in everyday interactions:  "A couple of weeks ago, I saw a product manager doing a pull request for a JSON file that contains some variables, and someone else accepted it. And it was deployed after a couple of minutes or seconds even, which was unthinkable before. There used to be quite a chain of things that needed to happen, the whole monolith was difficult to understand, even for engineers. So, previously requests would go into large, inefficient Kanban boards and hopefully someone will have done the change after weeks and months."
-<br><br>
-  The divide between Dev and Ops has also diminished. "After a couple of months, I got requests by people saying, ‘Hey, could you help me install the Kubernetes client? I want to actually look at what’s going on,’" says Meury. "People were directly looking at the state of the system, bringing them much, much closer to the operations." Before, infrastructure- and platform-related projects took months or years to complete; now developers and operators can work together to deploy infrastructure parts via Kubernetes in a matter of weeks and sometimes days.
-</div>
+{{< case-studies/lead >}}
+When Cedric Meury joined ricardo.ch in 2016, he saw a clear divide between Operations and Development. In fact, there was literal distance between them: The engineering team worked in France, while the rest of the org was based in Switzerland.
+{{< /case-studies/lead >}}
 
-<div class="banner5" >
-  <div class="banner5text">
-"One of my colleagues was listening to all the talks at KubeCon, and he was overwhelmed by all the tools, technologies, frameworks out there that are currently lacking on our platform, but at the same time, he’s very happy to know that in the future there is so much that we can still explore and we can improve and we can work on."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH</span></div>
-</div>
+<p>"It was a classic gap between those departments and even some anger and frustration here and there," says Meury. "They wanted to work together, but they didn't have common ground. This was one of the root causes that slowed us down."</p>
 
-<div class="fullcol">
+<p>That gap was hurting velocity at ricardo.ch, a Swiss online marketplace. The website processes up to 2.6 million searches on a peak day from both web and mobile apps, serving 3.2 million members with its live auctions. The technology team's main challenge was to make sure that "the bids for items come in the right order, and before the auction is finished, and that this works in a fair way," says Meury. "We have a real-time requirement. We also provide an automated system to bid, and it needs to be accurate and correct. With a distributed system, you have the challenge of making sure that the ordering is right. And that's one of the things we're currently dealing with."</p>
 
+<p>To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.</p>
 
-  The ability to have insight into the system has extended to other parts of the company, too. "I found out that one of our customer support representatives looks at Grafana metrics to find out whether the system is running fine, which is fantastic," says Meury. "Prometheus is directly hooked into customer care."
-<br><br>
-  The ricardo.ch cloud native journey has perhaps had the most impact on the Ops team. "We have an operations team that comes from a hardware-based background, and right now they are relearning how to operate in a more virtualized and cloud native world, with great success so far," says Meury. "So besides still operating on-site data center firewalls, they learn to code in Go or do some Python scripting at the same time. Former network administrators are writing Go code. It’s just really cool.
-<br><br>
-  For Meury, the journey boils down to this. "One of my colleagues was listening to all the talks at KubeCon, and he was overwhelmed by all the tools, technologies, frameworks out there that are currently lacking on our platform," says Meury. "But at the same time, he’s very happy to know that in the future there is so much that we can still explore and we can improve and we can work on. We’re transitioning from seeing problems everywhere—like, ‘This is broken’ or ‘This is down, and we have to fix it’—more to, ‘How can we actually improve and automate more, and make it nicer for developers and ultimately for the end users?’"
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ricardoch/banner3.png"
+  author="CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH"
+>}}
+"Being in the End User Community demonstrates that we stand behind these technologies. In Switzerland, if all the companies see that ricardo.ch's using it, I think that will help adoption. I also like that we're connected to the other end users, so if there is a really heavy problem, I could go to the Slack channel, and say, 'Hey, you guys…' Like Reddit, Github and New York Times or whoever can give a recommendation on what to use here or how to solve that. So that's kind of a superpower."
+{{< /case-studies/quote >}}
 
-</section>
+<p>The company also began breaking down the legacy monolith into more than 100 microservices, and needed orchestration to support the new architecture in its own data centers. "Splitting up the monolith allowed higher velocity, and Kubernetes was crucial to support that," says Meury. "Containerization and orchestration by Kubernetes helped us to drastically reduce the conflict between Dev and Ops and also allowed us to speak the same language on both sides of the aisle."</p>
+
+<p>Meury put together a platform engineering team to choose the tools—including Fluentd for logging and Prometheus for monitoring, with Grafana visualization—and lay the groundwork for the first Kubernetes cluster, which was installed on premise in December 2016. Within a few weeks, the new platform was available to teams, who were given training sessions and documentation. The platform engineering team then embedded with engineers to help them deploy their applications on the new platform. The first service in production was the ricardo.ch jobs page. "It was an exercise in front-end development, so the developers could experiment with a new stack," says Meury.</p>
+
+<p>Meury estimates that half of the application has been migrated to Kubernetes. And the plan is to move everything to the Google Cloud Platform by the end of 2018. "We are still running some servers in our own data centers, but all of the containerization efforts and describing our services as Kubernetes manifests will allow us to quite easily make that shift," says Meury.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ricardoch/banner4.png"
+  author="CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH"
+>}}
+"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, 'Wow, that's all I need to do?' He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."
+{{< /case-studies/quote >}}
+
+<p>The impact has been great. Moving from custom data center and virtual machines to containerized infrastructure and cloud services is expected to result in 50% cost savings for the company. The number of deployments to production has gone from fewer than 10 a week to 30-60 per day. Before, "when there was a problem with something in production, tickets or complaints would be thrown over the wall to operations, the classical problem," says Meury. "Now, people have the chance to look into operations and troubleshoot for themselves first because everything is deployed in a standardized way. That reduces time and uncertainty."</p>
+
+<p>Meury also sees the impact in everyday interactions:  "A couple of weeks ago, I saw a product manager doing a pull request for a JSON file that contains some variables, and someone else accepted it. And it was deployed after a couple of minutes or seconds even, which was unthinkable before. There used to be quite a chain of things that needed to happen, the whole monolith was difficult to understand, even for engineers. So, previously requests would go into large, inefficient Kanban boards and hopefully someone will have done the change after weeks and months."</p>
+
+<p>The divide between Dev and Ops has also diminished. "After a couple of months, I got requests by people saying, 'Hey, could you help me install the Kubernetes client? I want to actually look at what's going on,'" says Meury. "People were directly looking at the state of the system, bringing them much, much closer to the operations." Before, infrastructure- and platform-related projects took months or years to complete; now developers and operators can work together to deploy infrastructure parts via Kubernetes in a matter of weeks and sometimes days.</p>
+
+{{< case-studies/quote author="CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH" >}}
+"One of my colleagues was listening to all the talks at KubeCon, and he was overwhelmed by all the tools, technologies, frameworks out there that are currently lacking on our platform, but at the same time, he's very happy to know that in the future there is so much that we can still explore and we can improve and we can work on."
+{{< /case-studies/quote >}}
+
+<p>The ability to have insight into the system has extended to other parts of the company, too. "I found out that one of our customer support representatives looks at Grafana metrics to find out whether the system is running fine, which is fantastic," says Meury. "Prometheus is directly hooked into customer care."</p>
+
+<p>The ricardo.ch cloud native journey has perhaps had the most impact on the Ops team. "We have an operations team that comes from a hardware-based background, and right now they are relearning how to operate in a more virtualized and cloud native world, with great success so far," says Meury. "So besides still operating on-site data center firewalls, they learn to code in Go or do some Python scripting at the same time. Former network administrators are writing Go code. It's just really cool.</p>
+
+<p>For Meury, the journey boils down to this. "One of my colleagues was listening to all the talks at KubeCon, and he was overwhelmed by all the tools, technologies, frameworks out there that are currently lacking on our platform," says Meury. "But at the same time, he's very happy to know that in the future there is so much that we can still explore and we can improve and we can work on. We're transitioning from seeing problems everywhere—like, 'This is broken' or 'This is down, and we have to fix it'—more to, 'How can we actually improve and automate more, and make it nicer for developers and ultimately for the end users?'"</p>
diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html
index 86ebe15f91..e34bf2bd08 100644
--- a/content/en/case-studies/slamtec/index.html
+++ b/content/en/case-studies/slamtec/index.html
@@ -3,86 +3,69 @@ title: Slamtec Case Study
 linkTitle: slamtec
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/slamtec/banner1.jpg
+heading_title_logo: /images/slamtec_logo.png
+case_study_details:
+  - Company: Slamtec
+  - Location: Shanghai, China
+  - Industry: Robotics
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/slamtec/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/slamtec_logo.png" class="header_logo" style="width:17%;margin-bottom:%"><br> </h1>
-<br><br>
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>Slamtec</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Shanghai, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Robotics</b>
-</div>
+<p>Founded in 2013, SLAMTEC provides service robot autonomous localization and navigation solutions. The company's strength lies in its R&D team's ability to quickly introduce, and continually iterate on, its core products. In the past few years, the company, which had a legacy infrastructure based on Alibaba Cloud and VMware vSphere, began looking to build its own stable and reliable container cloud platform to host its Internet of Things applications. "Our needs for the cloud platform included high availability, scalability and security; multi-granularity monitoring alarm capability; friendliness to containers and microservices; and perfect CI/CD support," says Benniu Ji, Director of Cloud Computing Business Division.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    Founded in 2013, SLAMTEC provides service robot autonomous localization and navigation solutions. The company’s strength lies in its R&D team’s ability to quickly introduce, and continually iterate on, its core products. In the past few years, the company, which had a legacy infrastructure based on Alibaba Cloud and VMware vSphere, began looking to build its own stable and reliable container cloud platform to host its Internet of Things applications. "Our needs for the cloud platform included high availability, scalability and security; multi-granularity monitoring alarm capability; friendliness to containers and microservices; and perfect CI/CD support," says Benniu Ji, Director of Cloud Computing Business Division.
+<h2>Solution</h2>
+
+<p>Ji's team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for <a href="https://kubernetes.io/">Kubernetes</a>, which is very important for the wide application of Kubernetes," says Ji. Thus Slamtec decided to adopt other CNCF projects as well: <a href="https://prometheus.io/">Prometheus</a> monitoring, <a href="https://www.fluentd.org/">Fluentd</a> logging, <a href="https://goharbor.io/">Harbor</a> registry, and <a href="https://helm.sh/">Helm</a> package manager.</p>
 
-    <h2>Solution</h2>
-    Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for <a href="https://kubernetes.io/">Kubernetes</a>, which is very important for the wide application of Kubernetes," says Ji. Thus Slamtec decided to adopt other CNCF projects as well: <a href="https://prometheus.io/">Prometheus</a> monitoring, <a href="https://www.fluentd.org/">Fluentd</a> logging, <a href="https://goharbor.io/">Harbor</a> registry, and <a href="https://helm.sh/">Helm</a> package manager.
-<br>
 <h2>Impact</h2>
-    With the new platform, Ji reports that Slamtec has experienced "18+ months of 100% stability!" For users, there is now zero service downtime and seamless upgrades. "Kubernetes with third-party service mesh integration (Istio, along with Jaeger and Envoy) significantly reduced the microservice configuration and maintenance efforts by 50%," he adds. With centralized metrics monitoring and log aggregation provided by Prometheus on Fluentd, teams are saving 50% of time spent on troubleshooting and debugging. Harbor replication has allowed production/staging/testing environments to cross public cloud and the private Kubernetes cluster to share the same container registry, resulting in 30% savings of CI/CD efforts. Plus, Ji says, "Helm has accelerated prototype development and environment setup with its rich sharing charts."
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "Cloud native technology helps us ensure high availability of our business, while improving development and testing efficiency, shortening the research and development cycle and enabling rapid product delivery."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Founded in 2013, Slamtec provides service robot autonomous localization and navigation solutions. In this fast-moving space, the company built its success on the ability of its R&D team to quickly introduce, and continually iterate on, its core products.
- </h2>
-   To sustain that development velocity, the company over the past few years began looking to build its own stable and reliable container cloud platform to host its Internet of Things applications. With a legacy infrastructure based on <a href="https://www.alibabacloud.com/">Alibaba Cloud</a> and <a href="https://www.vmware.com/products/vsphere.html">VMware vSphere</a>, Slamtec teams had already adopted microservice architecture and continuous delivery, for "fine granularity on-demand scaling, fault isolation, ease of development, testing, and deployment, and for facilitating high-speed iteration," says Benniu Ji, Director of Cloud Computing Business Division. So "our needs for the cloud platform included high availability, scalability and security; multi-granularity monitoring alarm capability; friendliness to containers and microservices; and perfect CI/CD support."
-<br><br>
-  After an evaluation of existing technologies, Ji’s team chose <a href="https://kubernetes.io/">Kubernetes</a> for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/slamtec/banner3.jpg')">
-  <div class="banner3text">
-    "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION</span>
+<p>With the new platform, Ji reports that Slamtec has experienced "18+ months of 100% stability!" For users, there is now zero service downtime and seamless upgrades. "Kubernetes with third-party service mesh integration (Istio, along with Jaeger and Envoy) significantly reduced the microservice configuration and maintenance efforts by 50%," he adds. With centralized metrics monitoring and log aggregation provided by Prometheus on Fluentd, teams are saving 50% of time spent on troubleshooting and debugging. Harbor replication has allowed production/staging/testing environments to cross public cloud and the private Kubernetes cluster to share the same container registry, resulting in 30% savings of CI/CD efforts. Plus, Ji says, "Helm has accelerated prototype development and environment setup with its rich sharing charts."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Thus Slamtec decided to adopt other CNCF projects as well. "We built a monitoring and logging system based on <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">Fluentd</a>," says Ji. "The integration between Prometheus/Fluentd and Kubernetes is convenient, with multiple dimensions of data monitoring and log collection capabilities."
-<br><br>
-  The company uses <a href="https://goharbor.io/">Harbor</a> as a container image repository. "Harbor’s replication function helps us implement CI/CD on both private and public clouds," says Ji. "In addition, multi-project support, certification and policy configuration, and integration with Kubernetes are also excellent functions." <a href="https://helm.sh/">Helm</a> is also being used as a package manager, and the team is evaluating the Istio framework. "We’re very pleased that Kubernetes and these frameworks can be seamlessly integrated," Ji adds.
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/slamtec/banner4.jpg')">
-  <div class="banner4text">
-  "Cloud native is suitable for microservice architecture, it’s suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION</span>
-  </div>
-</div>
+{{< case-studies/quote author="BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION" >}}
+"Cloud native technology helps us ensure high availability of our business, while improving development and testing efficiency, shortening the research and development cycle and enabling rapid product delivery."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  With the new platform, Ji reports that Slamtec has experienced "18+ months of 100% stability!" For users, there is now zero service downtime and seamless upgrades. "We benefit from the abstraction of Kubernetes from network and storage," says Ji. "The dependence on external services can be decoupled from the service and placed under unified management in the cluster."
-<br><br>
-  Using Kubernetes and Istio "significantly reduced the microservice configuration and maintenance efforts by 50%," he adds. With centralized metrics monitoring and log aggregation provided by Prometheus on Fluentd, teams are saving 50% of time spent on troubleshooting and debugging. Harbor replication has allowed production/staging/testing environments to cross public cloud and the private Kubernetes cluster to share the same container registry, resulting in 30% savings of CI/CD efforts. Plus, Ji adds, "Helm has accelerated prototype development and environment setup with its rich sharing charts."
-<br><br>
-In short, Ji says, Slamtec’s new platform is helping it achieve one of its primary goals: the quick and easy release of products. With multiple release models and a centralized control interface, the platform is changing developers’ lives for the better. Slamtec also offers a unified API for the development of automated deployment tools according to users’ specific needs.
-</div>
+{{< case-studies/lead >}}
+Founded in 2013, Slamtec provides service robot autonomous localization and navigation solutions. In this fast-moving space, the company built its success on the ability of its R&D team to quickly introduce, and continually iterate on, its core products.
+{{< /case-studies/lead >}}
 
-<div class="banner5" style="width:100%">
-  <div class="banner5text">
-"We benefit from the abstraction of Kubernetes from network and storage, the dependence on external services can be decoupled from the service and placed under unified management in the cluster."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION</span></div>
-</div>
+<p>To sustain that development velocity, the company over the past few years began looking to build its own stable and reliable container cloud platform to host its Internet of Things applications. With a legacy infrastructure based on <a href="https://www.alibabacloud.com/">Alibaba Cloud</a> and <a href="https://www.vmware.com/products/vsphere.html">VMware vSphere</a>, Slamtec teams had already adopted microservice architecture and continuous delivery, for "fine granularity on-demand scaling, fault isolation, ease of development, testing, and deployment, and for facilitating high-speed iteration," says Benniu Ji, Director of Cloud Computing Business Division. So "our needs for the cloud platform included high availability, scalability and security; multi-granularity monitoring alarm capability; friendliness to containers and microservices; and perfect CI/CD support."</p>
 
-<div class="fullcol">
-  Given its own success with cloud native, Slamtec has just one piece of advice for organizations considering making the leap. "For already containerized services, you should migrate them to the cloud native architecture as soon as possible and enjoy the advantages brought by the cloud native ecosystem," Ji says. "To migrate traditional, non-containerized services, in addition to the architecture changes of the service itself, you need to fully consider the operation and maintenance workload required to build the cloud native architecture."
-<br><br>
-  That said, the cost-benefit analysis has been simple for Slamtec. "Cloud native technology is suitable for microservice architecture, it’s suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community," says Ji. "It helps us ensure high availability of our business, while improving development and testing efficiency, shortening the research and development cycle and enabling rapid product delivery."
-</div>
-</section>
+<p>After an evaluation of existing technologies, Ji's team chose <a href="https://kubernetes.io/">Kubernetes</a> for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/slamtec/banner3.jpg"
+  author="BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION"
+>}}
+"CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>Thus Slamtec decided to adopt other CNCF projects as well. "We built a monitoring and logging system based on <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">Fluentd</a>," says Ji. "The integration between Prometheus/Fluentd and Kubernetes is convenient, with multiple dimensions of data monitoring and log collection capabilities."</p>
+
+<p>The company uses <a href="https://goharbor.io/">Harbor</a> as a container image repository. "Harbor's replication function helps us implement CI/CD on both private and public clouds," says Ji. "In addition, multi-project support, certification and policy configuration, and integration with Kubernetes are also excellent functions." <a href="https://helm.sh/">Helm</a> is also being used as a package manager, and the team is evaluating the Istio framework. "We're very pleased that Kubernetes and these frameworks can be seamlessly integrated," Ji adds.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/slamtec/banner4.jpg"
+  author="BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION"
+>}}
+"Cloud native is suitable for microservice architecture, it's suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community."
+{{< /case-studies/quote >}}
+
+<p>With the new platform, Ji reports that Slamtec has experienced "18+ months of 100% stability!" For users, there is now zero service downtime and seamless upgrades. "We benefit from the abstraction of Kubernetes from network and storage," says Ji. "The dependence on external services can be decoupled from the service and placed under unified management in the cluster."</p>
+
+<p>Using Kubernetes and Istio "significantly reduced the microservice configuration and maintenance efforts by 50%," he adds. With centralized metrics monitoring and log aggregation provided by Prometheus on Fluentd, teams are saving 50% of time spent on troubleshooting and debugging. Harbor replication has allowed production/staging/testing environments to cross public cloud and the private Kubernetes cluster to share the same container registry, resulting in 30% savings of CI/CD efforts. Plus, Ji adds, "Helm has accelerated prototype development and environment setup with its rich sharing charts."</p>
+
+<p>In short, Ji says, Slamtec's new platform is helping it achieve one of its primary goals: the quick and easy release of products. With multiple release models and a centralized control interface, the platform is changing developers' lives for the better. Slamtec also offers a unified API for the development of automated deployment tools according to users' specific needs.</p>
+
+{{< case-studies/quote author="BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION" >}}
+"We benefit from the abstraction of Kubernetes from network and storage, the dependence on external services can be decoupled from the service and placed under unified management in the cluster."
+{{< /case-studies/quote >}}
+
+<p>Given its own success with cloud native, Slamtec has just one piece of advice for organizations considering making the leap. "For already containerized services, you should migrate them to the cloud native architecture as soon as possible and enjoy the advantages brought by the cloud native ecosystem," Ji says. "To migrate traditional, non-containerized services, in addition to the architecture changes of the service itself, you need to fully consider the operation and maintenance workload required to build the cloud native architecture."</p>
+
+<p>That said, the cost-benefit analysis has been simple for Slamtec. "Cloud native technology is suitable for microservice architecture, it's suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community," says Ji. "It helps us ensure high availability of our business, while improving development and testing efficiency, shortening the research and development cycle and enabling rapid product delivery."</p>
diff --git a/content/en/case-studies/slingtv/index.html b/content/en/case-studies/slingtv/index.html
index 349ed8c2de..6de46f35ff 100644
--- a/content/en/case-studies/slingtv/index.html
+++ b/content/en/case-studies/slingtv/index.html
@@ -3,108 +3,77 @@ title: SlingTV Case Study
 linkTitle: Sling TV
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: true
 weight: 49
 quote: >
   I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/slingtv/banner1.jpg
+heading_title_logo: /images/slingtv_logo.png
+subheading: >
+  Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale
+case_study_details:
+  - Company: Sling TV
+  - Location: Englewood, Colorado
+  - Industry: Streaming television
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/slingtv/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/slingtv_logo.png" style="margin-bottom:-1.5%;width:15% !important" class="header_logo"><br> <div class="subhead" style="padding-top:1% !important">Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale
+<p>Launched by DISH Network in 2015, Sling TV experienced great customer growth from the beginning. After just a year, "we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future," says Brad Linder, Sling TV's Cloud Native & Big Data Evangelist. The company has particular challenges: "We take live TV and distribute it over the internet out to a user's device that we do not control," says Linder. "In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer's service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and good customer experience at web scale."</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
-
-<div class="details">
-    Company &nbsp;<b>Sling TV</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Englewood, Colorado</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Streaming television</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:95% !important;padding-left:5%">
-    <h2>Challenge</h2>
-    Launched by DISH Network in 2015, Sling TV experienced great customer growth from the beginning. After just a year, “we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future,” says Brad Linder, Sling TV’s Cloud Native & Big Data Evangelist. The company has particular challenges: “We take live TV and distribute it over the internet out to a user’s device that we do not control,” says Linder. “In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer’s service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and good customer experience at web scale.”
-
-<br><br>
-
- <h2>Solution</h2>
-   Led by the belief that “the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of that sort of customer base,” Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build Sling TV’s next-generation platform around Kubernetes. “We are going to need to enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business at some point, so getting that sort of abstraction was a real goal,” he says. “That is one of the biggest reasons why we picked Kubernetes.” The team launched its first applications on Kubernetes in Sling TV’s two internal data centers. The push to enable AWS as a data center option is underway and should be available by the end of 2018. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.
-
-</div>
-<br><br>
-<div class="col2" style="width:95% !important;padding-left:5%;padding-top:2% !important">
+<p>Led by the belief that "the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of that sort of customer base," Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build Sling TV's next-generation platform around Kubernetes. "We are going to need to enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business at some point, so getting that sort of abstraction was a real goal," he says. "That is one of the biggest reasons why we picked Kubernetes." The team launched its first applications on Kubernetes in Sling TV's two internal data centers. The push to enable AWS as a data center option is underway and should be available by the end of 2018. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company's existing tool sets: Zenoss, New Relic and ELK.</p>
 
 <h2>Impact</h2>
- “We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale.”
+
+<p>"We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps," says Linder. "We have really enabled a platform thinking based approach to allowing applications to consume common tools.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale."</p>
+
+{{< case-studies/quote author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV" >}}
+"I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+The beauty of streaming television, like the service offered by <a href="https://www.sling.com/">Sling TV</a>, is that you can watch it from any device you want, wherever you want.
+{{< /case-studies/lead >}}
 
 
-</div>
+<p>Of course, from the provider side of things, that creates a particular set of challenges "We take live TV and distribute it over the internet out to a user's device that we do not control," says Brad Linder, Sling TV's Cloud Native & Big Data Evangelist. "In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer's service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and we have to do it at web scale."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
- “I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span>
+<p>Indeed, Sling TV experienced great customer growth from the beginning of its launch by <a href="https://www.dish.com/">DISH Network</a> in 2015. After just a year, "we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future," says Linder. Tasked with building a next-generation web scale platform for the "personalized customer experience," Linder has spent the past year bringing Kubernetes to Sling TV.</p>
 
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- <h2>The beauty of streaming television, like the service offered by <a href="https://www.sling.com/" style="text-decoration:underline">Sling TV</a>, is that you can watch it from any device you want, wherever you want.</h2> Of course, from the provider side of things, that creates a particular set of challenges
-“We take live TV and distribute it over the internet out to a user’s device that we do not control,” says Brad Linder, Sling TV’s Cloud Native & Big Data Evangelist. “In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer’s service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and we have to do it at web scale.”<br><br>
-Indeed, Sling TV experienced great customer growth from the beginning of its launch by <a href="https://www.dish.com/">DISH Network</a> in 2015. After just a year, “we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future,” says Linder. Tasked with building a next-generation web scale platform for the “personalized customer experience,” Linder has spent the past year bringing Kubernetes to Sling TV.<br><br>
-Led by the belief that “the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of our customers,” Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build the platform around Kubernetes. “They have really helped us get our head around how to use Kubernetes,” he says. “We needed the flexibility to enable our use case versus just a simple orchestrater.  Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”
+<p>Led by the belief that "the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of our customers," Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build the platform around Kubernetes. "They have really helped us get our head around how to use Kubernetes," he says. "We needed the flexibility to enable our use case versus just a simple orchestrater.  Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition."</p>
 
+{{< case-studies/quote
+  image="/images/case-studies/slingtv/banner3.jpg"
+  author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV"
+>}}
+"We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/slingtv/banner3.jpg')">
-  <div class="banner3text">
-    “We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value&nbsp;proposition.” <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to "enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business," he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. "We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications' well-being," says Linder. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company's existing tool sets: Zenoss, New Relic and ELK.</p>
 
-One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to “enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business,” he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. “We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications’ well-being,” says Linder. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.<br><br>
-With the emphasis on common tooling, “We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools and services.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web&nbsp;scale.”<br><br>
+<p>With the emphasis on common tooling, "We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps," says Linder. "We have really enabled a platform thinking based approach to allowing applications to consume common tools and services.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/slingtv/banner4.jpg')">
-  <div class="banner4text">
-“We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/slingtv/banner4.jpg"
+  author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV"
+>}}
+"We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
+<p>The team launched its first applications on Kubernetes in Sling TV's two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.</p>
 
-<div class="fullcol">
- The team launched its first applications on Kubernetes in Sling TV’s two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.
-The first application that went into production is a web socket-based back-end notification service. “It allows back-end changes to trigger messages to our clients in the field without the polling,” says Linder. “We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”<br><br>
- Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. “We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer.  That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly,” says Linder.
+<p>The first application that went into production is a web socket-based back-end notification service. "It allows back-end changes to trigger messages to our clients in the field without the polling," says Linder. "We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables."</p>
 
+<p>Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. "We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer.  That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly," says Linder.</p>
 
-</div>
+{{< case-studies/quote author="BRAD LINDER, CLOUD NATIVE & BIG DATA EVANGELIST FOR SLING TV">}}
+This undertaking is about "trying to marry Kubernetes with AI to enable web scale that just works".
+{{< /case-studies/quote >}}
 
-<div class="banner5">
-  <div class="banner5text">
-  This undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works". <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— BRAD LINDER, CLOUD NATIVE & BIG DATA EVANGELIST FOR SLING TV </span>
-  </div>
-</div>
+<p>Ultimately, this undertaking is about "trying to marry Kubernetes with AI to enable web scale that just works," he adds. "We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, 'Hey we need more capacity for this service so please add more nodes.' From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a 'millions of users' sort of environment, that implosion is going to be catastrophic.  We are on our way to this goal and have learned a lot along the way."</p>
 
-<div class="fullcol">
- Ultimately, this undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works,” he adds. “We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, ‘Hey we need more capacity for this service so please add more nodes.’ From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a ‘millions of users’ sort of environment, that implosion is going to be catastrophic.  We are on our way to this goal and have learned a lot along the way.”<br><br>
-For Sling TV, moving to cloud native has been exactly what they needed. “We have to be able to react to changes and hiccups in the matrix,” says Linder. “It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect.”
-
-
-
-
-
-</div>
-
-</section>
+<p>For Sling TV, moving to cloud native has been exactly what they needed. "We have to be able to react to changes and hiccups in the matrix," says Linder. "It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect."</p>
diff --git a/content/en/case-studies/sos/index.html b/content/en/case-studies/sos/index.html
index becf486413..ff0e3f2322 100644
--- a/content/en/case-studies/sos/index.html
+++ b/content/en/case-studies/sos/index.html
@@ -3,97 +3,81 @@ title: SOS International Case Study
 linkTitle: SOS International
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: sos_featured_logo.png
+
+new_case_study_styles: true
+heading_background: /images/case-studies/sos/banner1.jpg
+heading_title_logo: /images/sos_logo.png
+subheading: >
+  SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World
+case_study_details:
+  - Company: SOS International
+  - Location: Frederiksberg, Denmark
+  - Industry: Medical and Travel Assistance
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/sos/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/sos_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World
+<p>For the past six decades, SOS International has been providing reliable medical and travel assistance in the Nordic region. In recent years, the company's business strategy has required increasingly intense development in the digital space, but when it came to its IT systems, "SOS has a very fragmented legacy," with three traditional monoliths (Java, .NET, and IBM's AS/400) and a waterfall approach, says Martin Ahrentsen, Head of Enterprise Architecture.  "We have been forced to institute both new technology and new ways of working, so we could be more efficient with a shorter time to market. It was a much more agile approach, and we needed to have a platform that can help us deliver that to the business."</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
+<p>After an unsuccessful search for a standard system, the company decided to take a platform approach and look for a solution that rolls up Kubernetes and the container technology. <a href="https://www.openshift.com/">RedHat OpenShift</a> proved to be a perfect fit for SOS's fragmented systems. "We have a lot of different technologies that we use, both code languages and others, and all of them could use the resources on the new platform," says Ahrentsen. Of the company's three monoliths, "we can provide this new bleeding edge technology to two of them (.NET and Java)." The platform went live in the spring of 2018; there are now six greenfield projects based on microservices architecture underway, plus all of the company's Java applications are currently going through a "lift and shift" migration.</p>
 
-<div class="details">
-    Company &nbsp;<b>SOS International</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Frederiksberg, Denmark
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Medical and Travel Assistance</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    For the past six decades, SOS International has been providing reliable medical and travel assistance in the Nordic region. In recent years, the company’s business strategy has required increasingly intense development in the digital space, but when it came to its IT systems, "SOS has a very fragmented legacy," with three traditional monoliths (Java, .NET, and IBM’s AS/400) and a waterfall approach, says Martin Ahrentsen, Head of Enterprise Architecture.  "We have been forced to institute both new technology and new ways of working, so we could be more efficient with a shorter time to market. It was a much more agile approach, and we needed to have a platform that can help us deliver that to the business."
-
-<br><br>
-    <h2>Solution</h2>
-    After an unsuccessful search for a standard system, the company decided to take a platform approach and look for a solution that rolls up Kubernetes and the container technology. <a href="https://www.openshift.com/">RedHat OpenShift</a> proved to be a perfect fit for SOS’s fragmented systems. "We have a lot of different technologies that we use, both code languages and others, and all of them could use the resources on the new platform," says Ahrentsen. Of the company’s three monoliths, "we can provide this new bleeding edge technology to two of them (.NET and Java)." The platform went live in the spring of 2018; there are now six greenfield projects based on microservices architecture underway, plus all of the company’s Java applications are currently going through a "lift and shift" migration.
-
-<br><br>
 <h2>Impact</h2>
-    Kubernetes has delivered "improved time to market, agility, and the ability to adapt to changes and new technologies," says Ahrentsen. "Just the time between when the software is ready for release and when it can be released has dramatically been improved." The way of thinking at SOS International has also changed for the better: "Since we have Kubernetes and easy access to scripts that can help us automate, creating CI/CD pipelines easily, that has spawned a lot of internal interest in how to do this fully automated, all the way. It creates a very good climate in order to start the journey," he says. Moreover, being part of the cloud native community has helped the company attract talent. "They want to work with the cool, new technologies," says Ahrentsen. "During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."
 
-</div>
+<p>Kubernetes has delivered "improved time to market, agility, and the ability to adapt to changes and new technologies," says Ahrentsen. "Just the time between when the software is ready for release and when it can be released has dramatically been improved." The way of thinking at SOS International has also changed for the better: "Since we have Kubernetes and easy access to scripts that can help us automate, creating CI/CD pipelines easily, that has spawned a lot of internal interest in how to do this fully automated, all the way. It creates a very good climate in order to start the journey," he says. Moreover, being part of the cloud native community has helped the company attract talent. "They want to work with the cool, new technologies," says Ahrentsen. "During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "The speed of the changes that cloud native software and technologies drive right now is amazing, and following and adopting it is very crucial for us. The amazing technology provided by Kubernetes and cloud native has started the change for SOS towards a digital future."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Martin Ahrentsen, Head of Enterprise Architecture, SOS International</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>For six decades, SOS International has provided reliable emergency medical and travel assistance for customers in the Nordic countries.</h2>
-  SOS operators handle a million cases and over a million phone calls a year. But in the past four years, the company’s business strategy has required increasingly intense development in the digital space.<br><br>
-  When it comes to its IT systems, "SOS has a very fragmented legacy," with three traditional monoliths running in the company’s own data centers and a waterfall approach, says Martin Ahrentsen, Head of Enterprise Architecture. "We had to institute both new technology and new ways of working so we could be more efficient, with a shorter time to market. It was a much more agile approach, and we needed to have a platform that can help us deliver that to the business."<br><br>
-  For a long time, Ahrentsen and his team searched for a standard solution that could work at SOS. "There aren’t that many assistance companies like us, so you cannot get a standard system that fits for that; there is no perfect match," he says. "We would have to take a standard system and twist it too much so it is not standard anymore. Based on that, we decided to find a technology platform instead, with some common components that we could use to build the new digital systems and core systems."
+{{< case-studies/quote author="Martin Ahrentsen, Head of Enterprise Architecture, SOS International" >}}
+"The speed of the changes that cloud native software and technologies drive right now is amazing, and following and adopting it is very crucial for us. The amazing technology provided by Kubernetes and cloud native has started the change for SOS towards a digital future."
+{{< /case-studies/quote >}}
 
+{{< case-studies/lead >}}
+For six decades, SOS International has provided reliable emergency medical and travel assistance for customers in the Nordic countries.
+{{< /case-studies/lead >}}
 
+<p>SOS operators handle a million cases and over a million phone calls a year. But in the past four years, the company's business strategy has required increasingly intense development in the digital space.</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/sos/banner3.jpg')">
-  <div class="banner3text">
-    "We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform. One of the reasons why we chose this technology is that we could build new digital services while changing the old one."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Martin Ahrentsen, Head of Enterprise Architecture, SOS International</span>
+<p>When it comes to its IT systems, "SOS has a very fragmented legacy," with three traditional monoliths running in the company's own data centers and a waterfall approach, says Martin Ahrentsen, Head of Enterprise Architecture. "We had to institute both new technology and new ways of working so we could be more efficient, with a shorter time to market. It was a much more agile approach, and we needed to have a platform that can help us deliver that to the business."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Sold on what Kubernetes could do, Ahrentsen zeroed in on platforms that could meet the business’s needs right away. The company opted to use RedHat’s OpenShift container platform, which incorporates Docker containers and Kubernetes, as well as a whole stack of technologies, including RedHat Hyperconverged Infrastructure and some midware components, all from the open source community.<br><br>
-  Based on the company’s criteria—technology fit, agility fit, legal requirements, and competencies—the OpenShift solution seemed like a perfect fit for SOS’s fragmented systems. "We have a lot of different technologies that we use, both code languages and others, and all of them could use the resources on the new platform," says Ahrentsen. Of the company’s three monoliths, "we can provide this new bleeding edge technology to two of them (.NET and Java)."<br><br>
-  The platform went live in the spring of 2018; six greenfield projects based on microservices architecture were initially launched, plus all of the company’s Java applications are currently going through a "lift and shift" migration. One of the first Kubernetes-based projects to go live is Remote Medical Treatment, a solution in which customers can contact the SOS alarm center via voice, chat, or video. "We managed to develop it in quite a short timeframe with focus on full CI/CD pipelining and a modern microservice architecture all running in a dual OpenShift cluster setup," says Ahrentsen. Onsite, which is used for dispatching rescue trucks around the Nordic countries, and Follow Your Truck, which allows customers to track tow trucks, are also being rolled out.
+<p>For a long time, Ahrentsen and his team searched for a standard solution that could work at SOS. "There aren't that many assistance companies like us, so you cannot get a standard system that fits for that; there is no perfect match," he says. "We would have to take a standard system and twist it too much so it is not standard anymore. Based on that, we decided to find a technology platform instead, with some common components that we could use to build the new digital systems and core systems."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/sos/banner4.jpg');width:100%">
-  <div class="banner4text">
-  "During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Martin Ahrentsen, Head of Enterprise Architecture, SOS International</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/sos/banner3.jpg"
+  author="Martin Ahrentsen, Head of Enterprise Architecture, SOS International"
+>}}
+"We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform. One of the reasons why we chose this technology is that we could build new digital services while changing the old one."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  The platform is still running on premise, because some of SOS’s customers in the insurance industry, for whom the company handles data, don’t yet have a cloud strategy. Kubernetes is allowing SOS to start in the data center and move to the cloud when the business is ready. "Over the next three to five years, all of them will have a strategy, and we could probably take the data and go to the cloud," says Ahrentsen. There’s also the possibility of moving to a hybrid cloud setup for sensitive and non-sensitive data. <br><br>
-  SOS’s technology is certainly in a state of transition. "We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform," says Ahrentsen. "One of the reasons why we chose this technology is that we could build new digital services while changing the old one."<br><br>
-  But already, Kubernetes has delivered improved time to market, as evidenced by how quickly the greenfield projects were developed and released. "Just the time between when the software is ready for release and when it can be released has dramatically been improved," says Ahrentsen.<br><br>
-  Moreover, being part of the cloud native community has helped the company attract talent as it pursues a goal of growing the ranks of engineers, operators, and architects from 60 to 100 this year. "They want to work with the cool, new technologies," says Ahrentsen. "During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."
+<p>Sold on what Kubernetes could do, Ahrentsen zeroed in on platforms that could meet the business's needs right away. The company opted to use RedHat's OpenShift container platform, which incorporates Docker containers and Kubernetes, as well as a whole stack of technologies, including RedHat Hyperconverged Infrastructure and some midware components, all from the open source community.</p>
 
-</div>
+<p>Based on the company's criteria—technology fit, agility fit, legal requirements, and competencies—the OpenShift solution seemed like a perfect fit for SOS's fragmented systems. "We have a lot of different technologies that we use, both code languages and others, and all of them could use the resources on the new platform," says Ahrentsen. Of the company's three monoliths, "we can provide this new bleeding edge technology to two of them (.NET and Java)."</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-"The future world where everything is connected and sends data will create a big potential for us in terms of new market opportunities. But it will also set a big demand on the IT platform and what we need to deliver."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Martin Ahrentsen, Head of Enterprise Architecture, SOS International</span></div>
-</div>
+<p>The platform went live in the spring of 2018; six greenfield projects based on microservices architecture were initially launched, plus all of the company's Java applications are currently going through a "lift and shift" migration. One of the first Kubernetes-based projects to go live is Remote Medical Treatment, a solution in which customers can contact the SOS alarm center via voice, chat, or video. "We managed to develop it in quite a short timeframe with focus on full CI/CD pipelining and a modern microservice architecture all running in a dual OpenShift cluster setup," says Ahrentsen. Onsite, which is used for dispatching rescue trucks around the Nordic countries, and Follow Your Truck, which allows customers to track tow trucks, are also being rolled out.</p>
 
-<div class="fullcol">
-  The way of thinking at SOS International has also changed dramatically: "Since we have Kubernetes and easy access to scripts that can help us automate, creating CI/CD pipelines easily, that has spawned a lot of internal interest in how to do this fully automated, all the way. It creates a very good climate in order to start the journey." <br><br>
-  For this journey at SOS, digitalization and optimization are the key words. "For IT to deliver this, we need to improve, and that is not just on the way of using Kubernetes and the platform," says Ahrentsen. "It’s also a way of building the systems to be ready for automation, and afterwards, machine learning and other interesting technologies that are on the way."<br><br>
-  Case in point: the introduction of the internet of things into automobiles. The European Commission now mandates all new cars to be equipped with <a href="https://ec.europa.eu/transport/themes/its/road/action_plan/ecall_en">eCall</a>, which transmits location and other data in case of a serious traffic accident. SOS provides this service as smart auto assistance. "We receive the call and find out if an emergency response team needs to be sent, or if it’s not heavy impact," says Ahrentsen. "The future world where everything is connected and sends data will create a big potential for us in terms of new market opportunities. But it will also set a big demand on the IT platform and what we need to deliver."<br><br>
-  Ahrentsen feels that SOS is well equipped for the challenge, given the technology choices the company has made. "The speed of the changes that cloud native software and technologies drive right now is amazing, and following it and adopting it is very crucial for us," he says. "The amazing technology provided by Kubernetes and cloud native has started the change for SOS towards a digital future."
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/sos/banner4.jpg"
+  author="Martin Ahrentsen, Head of Enterprise Architecture, SOS International"
+>}}
+"During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."
+{{< /case-studies/quote >}}
+
+<p>The platform is still running on premise, because some of SOS's customers in the insurance industry, for whom the company handles data, don't yet have a cloud strategy. Kubernetes is allowing SOS to start in the data center and move to the cloud when the business is ready. "Over the next three to five years, all of them will have a strategy, and we could probably take the data and go to the cloud," says Ahrentsen. There's also the possibility of moving to a hybrid cloud setup for sensitive and non-sensitive data.</p>
+
+<p>SOS's technology is certainly in a state of transition. "We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform," says Ahrentsen. "One of the reasons why we chose this technology is that we could build new digital services while changing the old one."</p>
+
+<p>But already, Kubernetes has delivered improved time to market, as evidenced by how quickly the greenfield projects were developed and released. "Just the time between when the software is ready for release and when it can be released has dramatically been improved," says Ahrentsen.</p>
+
+<p>Moreover, being part of the cloud native community has helped the company attract talent as it pursues a goal of growing the ranks of engineers, operators, and architects from 60 to 100 this year. "They want to work with the cool, new technologies," says Ahrentsen. "During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."</p>
+
+{{< case-studies/quote author="Martin Ahrentsen, Head of Enterprise Architecture, SOS International" >}}
+"The future world where everything is connected and sends data will create a big potential for us in terms of new market opportunities. But it will also set a big demand on the IT platform and what we need to deliver."
+{{< /case-studies/quote >}}
+
+<p>The way of thinking at SOS International has also changed dramatically: "Since we have Kubernetes and easy access to scripts that can help us automate, creating CI/CD pipelines easily, that has spawned a lot of internal interest in how to do this fully automated, all the way. It creates a very good climate in order to start the journey."</p>
+
+<p>For this journey at SOS, digitalization and optimization are the key words. "For IT to deliver this, we need to improve, and that is not just on the way of using Kubernetes and the platform," says Ahrentsen. "It's also a way of building the systems to be ready for automation, and afterwards, machine learning and other interesting technologies that are on the way."</p>
+
+<p>Case in point: the introduction of the internet of things into automobiles. The European Commission now mandates all new cars to be equipped with <a href="https://ec.europa.eu/transport/themes/its/road/action_plan/ecall_en">eCall</a>, which transmits location and other data in case of a serious traffic accident. SOS provides this service as smart auto assistance. "We receive the call and find out if an emergency response team needs to be sent, or if it's not heavy impact," says Ahrentsen. "The future world where everything is connected and sends data will create a big potential for us in terms of new market opportunities. But it will also set a big demand on the IT platform and what we need to deliver."</p>
+
+<p>Ahrentsen feels that SOS is well equipped for the challenge, given the technology choices the company has made. "The speed of the changes that cloud native software and technologies drive right now is amazing, and following it and adopting it is very crucial for us," he says. "The amazing technology provided by Kubernetes and cloud native has started the change for SOS towards a digital future."</p>
diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html
index 63243b08f6..7448b40939 100644
--- a/content/en/case-studies/spotify/index.html
+++ b/content/en/case-studies/spotify/index.html
@@ -3,96 +3,77 @@ title: Spotify Case Study
 linkTitle: Spotify
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/spotify/banner1.jpg
+heading_title_text: Spotify
+subheading: >
+  Spotify: An Early Adopter of Containers, Spotify Is Migrating from Homegrown Orchestration to Kubernetes
+case_study_details:
+  - Company: Spotify
+  - Location: Global
+  - Industry: Entertainment
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/spotify/banner1.jpg')">
-  <h1> CASE STUDY: Spotify<br> <div class="subhead" style="margin-top:1%">Spotify: An Early Adopter of Containers, Spotify Is Migrating from Homegrown Orchestration to Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>Launched in 2008, the audio-streaming platform has grown to over 200 million monthly active users across the world. "Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today—and hopefully the consumers we'll have in the future," says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations. An early adopter of microservices and Docker, Spotify had containerized microservices running across its fleet of VMs with a homegrown container orchestration system called <a href="https://github.com/spotify/helios">Helios</a>. By late 2017, it became clear that "having a small team working on the features was just not as efficient as adopting something that was supported by a much bigger community," he says.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Spotify</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Global
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Entertainment</b>
-</div>
+<p>"We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that," says Chakrabarti. Kubernetes was more feature-rich than Helios. Plus, "we wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools." At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community. The migration, which would happen in parallel with Helios running, could go smoothly because "Kubernetes fit very nicely as a complement and now as a replacement to Helios," says Chakrabarti.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    Launched in 2008, the audio-streaming platform has grown to over 200 million monthly active users across the world. "Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today—and hopefully the consumers we’ll have in the future," says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations. An early adopter of microservices and Docker, Spotify had containerized microservices running across its fleet of VMs with a homegrown container orchestration system called <a href="https://github.com/spotify/helios">Helios</a>. By late 2017, it became clear that "having a small team working on the features was just not as efficient as adopting something that was supported by a much bigger community," he says.
-
-<br><br>
-    <h2>Solution</h2>
-    "We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that," says Chakrabarti. Kubernetes was more feature-rich than Helios. Plus, "we wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools." At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community. The migration, which would happen in parallel with Helios running, could go smoothly because "Kubernetes fit very nicely as a complement and now as a replacement to Helios," says Chakrabarti.
-<br><br>
 <h2>Impact</h2>
-    The team spent much of 2018 addressing the core technology issues required for a migration, which started late that year and is a big focus for 2019. "A small percentage of our fleet has been migrated to Kubernetes, and some of the things that we’ve heard from our internal teams are that they have less of a need to focus on manual capacity provisioning and more time to focus on delivering features for Spotify," says Chakrabarti. The biggest service currently running on Kubernetes takes about 10 million requests per second as an aggregate service and benefits greatly from autoscaling, says Site Reliability Engineer James Wen. Plus, he adds, "Before, teams would have to wait for an hour to create a new service and get an operational host to run it in production, but with Kubernetes, they can do that on the order of seconds and minutes." In addition, with Kubernetes’s bin-packing and multi-tenancy capabilities, CPU utilization has improved on average two- to threefold.
 
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We saw the amazing community that’s grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Jai Chakrabarti, Director of Engineering, Infrastructure and Operations, Spotify</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>"Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today—and hopefully the consumers we’ll have in the future," says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations at Spotify. Since the audio-streaming platform launched in 2008, it has already grown to over 200 million monthly active users around the world, and for Chakrabarti’s team, the goal is solidifying Spotify’s infrastructure to support all those future consumers too.</h2>
-  <br><br>
-  An early adopter of microservices and Docker, Spotify had containerized microservices running across its fleet of VMs since 2014. The company used an open source, homegrown container orchestration system called Helios, and in 2016-17 completed a migration from on premise data centers to Google Cloud. Underpinning these decisions, "We have a culture around autonomous teams, over 200 autonomous engineering squads who are working on different pieces of the pie, and they need to be able to iterate quickly," Chakrabarti says. "So for us to have developer velocity tools that allow squads to move quickly is really important."<br><br>
-  But by late 2017, it became clear that "having a small team working on the <a href="https://github.com/spotify/helios">Helios</a> features was just not as efficient as adopting something that was supported by a much bigger community," says Chakrabarti. "We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools." At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community.
+<p>The team spent much of 2018 addressing the core technology issues required for a migration, which started late that year and is a big focus for 2019. "A small percentage of our fleet has been migrated to Kubernetes, and some of the things that we've heard from our internal teams are that they have less of a need to focus on manual capacity provisioning and more time to focus on delivering features for Spotify," says Chakrabarti. The biggest service currently running on Kubernetes takes about 10 million requests per second as an aggregate service and benefits greatly from autoscaling, says Site Reliability Engineer James Wen. Plus, he adds, "Before, teams would have to wait for an hour to create a new service and get an operational host to run it in production, but with Kubernetes, they can do that on the order of seconds and minutes." In addition, with Kubernetes's bin-packing and multi-tenancy capabilities, CPU utilization has improved on average two- to threefold.</p>
 
+{{< case-studies/quote author="Jai Chakrabarti, Director of Engineering, Infrastructure and Operations, Spotify" >}}
+"We saw the amazing community that's grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/spotify/banner3.jpg')">
-  <div class="banner3text">
-    "The community has been extremely helpful in getting us to work through all the technology much faster and much easier. And it’s helped us validate all the things we’re doing." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dave Zolotusky, Software Engineer, Infrastructure and Operations, Spotify</span>
+{{< case-studies/lead >}}
+"Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today—and hopefully the consumers we'll have in the future," says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations at Spotify. Since the audio-streaming platform launched in 2008, it has already grown to over 200 million monthly active users around the world, and for Chakrabarti's team, the goal is solidifying Spotify's infrastructure to support all those future consumers too.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Another plus: "Kubernetes fit very nicely as a complement and now as a replacement to Helios, so we could have it running alongside Helios to mitigate the risks," says Chakrabarti. "During the migration, the services run on both, so we’re not having to put all of our eggs in one basket until we can validate Kubernetes under a variety of load circumstances and stress circumstances."<br><br>
-  The team spent much of 2018 addressing the core technology issues required for the migration. "We were able to use a lot of the Kubernetes APIs and extensibility features of Kubernetes to support and interface with our legacy infrastructure, so the integration was straightforward and easy," says Site Reliability Engineer James Wen. <br><br>
-  Migration started late that year and has accelerated in 2019. "Our focus is really on stateless services, and once we address our last remaining technology blocker, that’s where we hope that the uptick will come from," says Chakrabarti. "For stateful services there’s more work that we need to do."<br><br>
-  A small percentage of Spotify’s fleet, containing over 150 services, has been migrated to Kubernetes so far. "We’ve heard from our customers that they have less of a need to focus on manual capacity provisioning and more time to focus on delivering features for Spotify," says Chakrabarti. The biggest service currently running on Kubernetes takes over 10 million requests per second as an aggregate service and benefits greatly from autoscaling, says Wen. Plus, Wen adds, "Before, teams would have to wait for an hour to create a new service and get an operational host to run it in production, but with Kubernetes, they can do that on the order of seconds and minutes." In addition, with Kubernetes’s bin-packing and multi-tenancy capabilities, CPU utilization has improved on average two- to threefold.
+<p>An early adopter of microservices and Docker, Spotify had containerized microservices running across its fleet of VMs since 2014. The company used an open source, homegrown container orchestration system called Helios, and in 2016-17 completed a migration from on premise data centers to Google Cloud. Underpinning these decisions, "We have a culture around autonomous teams, over 200 autonomous engineering squads who are working on different pieces of the pie, and they need to be able to iterate quickly," Chakrabarti says. "So for us to have developer velocity tools that allow squads to move quickly is really important."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/spotify/banner4.jpg')">
-  <div class="banner4text">
-  "We were able to use a lot of the Kubernetes APIs and extensibility features to support and interface with our legacy infrastructure, so the integration was straightforward and easy."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- James Wen, Site Reliability Engineer, Spotify</span>
-  </div>
-</div>
+<p>But by late 2017, it became clear that "having a small team working on the <a href="https://github.com/spotify/helios">Helios</a> features was just not as efficient as adopting something that was supported by a much bigger community," says Chakrabarti. "We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools." At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Chakrabarti points out that for all four of the top-level metrics that Spotify looks at—lead time, deployment frequency, time to resolution, and operational load—"there is impact that Kubernetes is having."<br><br>
-  One success story that’s come out of the early days of Kubernetes is a tool called Slingshot that a Spotify team built on Kubernetes. "With a pull request, it creates a temporary staging environment that self destructs after 24 hours," says Chakrabarti. "It’s all facilitated by Kubernetes, so that’s kind of an exciting example of how, once the technology is out there and ready to use, people start to build on top of it and craft their own solutions, even beyond what we might have envisioned as the initial purpose of it."<br><br>
-  Spotify has also started to use <a href="https://grpc.io/">gRPC</a> and <a href="https://www.envoyproxy.io/">Envoy</a>, replacing existing homegrown solutions, just as it had with Kubernetes. "We created things because of the scale we were at, and there was no other solution existing," says Dave Zolotusky, Software Engineer, Infrastructure and Operations. "But then the community kind of caught up and surpassed us, even for tools that work at that scale."
+{{< case-studies/quote
+  image="/images/case-studies/spotify/banner3.jpg"
+  author="Dave Zolotusky, Software Engineer, Infrastructure and Operations, Spotify"
+>}}
+"The community has been extremely helpful in getting us to work through all the technology much faster and much easier. And it's helped us validate all the things we're doing."
+{{< /case-studies/quote >}}
 
-</div>
+<p>Another plus: "Kubernetes fit very nicely as a complement and now as a replacement to Helios, so we could have it running alongside Helios to mitigate the risks," says Chakrabarti. "During the migration, the services run on both, so we're not having to put all of our eggs in one basket until we can validate Kubernetes under a variety of load circumstances and stress circumstances."</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-    "It’s been surprisingly easy to get in touch with anybody we wanted to, to get expertise on any of the things we’re working with. And it’s helped us validate all the things we’re doing."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- James Wen, Site Reliability Engineer, Spotify</span></div>
-</div>
+<p>The team spent much of 2018 addressing the core technology issues required for the migration. "We were able to use a lot of the Kubernetes APIs and extensibility features of Kubernetes to support and interface with our legacy infrastructure, so the integration was straightforward and easy," says Site Reliability Engineer James Wen.</p>
 
-<div class="fullcol">
-  Both of those technologies are in early stages of adoption, but already "we have reason to believe that gRPC will have a more drastic impact during early development by helping with a lot of issues like schema management, API design, weird backward compatibility issues, things like that," says Zolotusky. "So we’re leaning heavily on gRPC to help us in that space."<br><br>
-  As the team continues to fill out Spotify’s cloud native stack—tracing is up next—it is using the CNCF landscape as a helpful guide. "We look at things we need to solve, and if there are a bunch of projects, we evaluate them equivalently, but there is definitely value to the project being a CNCF project," says Zolotusky. <br><br>
-  Spotify’s experiences so far with Kubernetes bears this out. "The community has been extremely helpful in getting us to work through all the technology much faster and much easier," Zolotusky says. "It’s been surprisingly easy to get in touch with anybody we wanted to, to get expertise on any of the things we’re working with. And it’s helped us validate all the things we’re doing."
+<p>Migration started late that year and has accelerated in 2019. "Our focus is really on stateless services, and once we address our last remaining technology blocker, that's where we hope that the uptick will come from," says Chakrabarti. "For stateful services there's more work that we need to do."</p>
 
-</div>
-</section>
-</body>
-</html>
+<p>A small percentage of Spotify's fleet, containing over 150 services, has been migrated to Kubernetes so far. "We've heard from our customers that they have less of a need to focus on manual capacity provisioning and more time to focus on delivering features for Spotify," says Chakrabarti. The biggest service currently running on Kubernetes takes over 10 million requests per second as an aggregate service and benefits greatly from autoscaling, says Wen. Plus, Wen adds, "Before, teams would have to wait for an hour to create a new service and get an operational host to run it in production, but with Kubernetes, they can do that on the order of seconds and minutes." In addition, with Kubernetes's bin-packing and multi-tenancy capabilities, CPU utilization has improved on average two- to threefold.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/spotify/banner4.jpg"
+  author="James Wen, Site Reliability Engineer, Spotify"
+>}}
+"We were able to use a lot of the Kubernetes APIs and extensibility features to support and interface with our legacy infrastructure, so the integration was straightforward and easy."
+{{< /case-studies/quote >}}
+
+<p>Chakrabarti points out that for all four of the top-level metrics that Spotify looks at—lead time, deployment frequency, time to resolution, and operational load—"there is impact that Kubernetes is having."</p>
+
+<p>One success story that's come out of the early days of Kubernetes is a tool called Slingshot that a Spotify team built on Kubernetes. "With a pull request, it creates a temporary staging environment that self destructs after 24 hours," says Chakrabarti. "It's all facilitated by Kubernetes, so that's kind of an exciting example of how, once the technology is out there and ready to use, people start to build on top of it and craft their own solutions, even beyond what we might have envisioned as the initial purpose of it."</p>
+
+<p>Spotify has also started to use <a href="https://grpc.io/">gRPC</a> and <a href="https://www.envoyproxy.io/">Envoy</a>, replacing existing homegrown solutions, just as it had with Kubernetes. "We created things because of the scale we were at, and there was no other solution existing," says Dave Zolotusky, Software Engineer, Infrastructure and Operations. "But then the community kind of caught up and surpassed us, even for tools that work at that scale."</p>
+
+{{< case-studies/quote author="James Wen, Site Reliability Engineer, Spotify" >}}
+"It's been surprisingly easy to get in touch with anybody we wanted to, to get expertise on any of the things we're working with. And it's helped us validate all the things we're doing."
+{{< /case-studies/quote >}}
+
+<p>Both of those technologies are in early stages of adoption, but already "we have reason to believe that gRPC will have a more drastic impact during early development by helping with a lot of issues like schema management, API design, weird backward compatibility issues, things like that," says Zolotusky. "So we're leaning heavily on gRPC to help us in that space."</p>
+
+<p>As the team continues to fill out Spotify's cloud native stack—tracing is up next—it is using the CNCF landscape as a helpful guide. "We look at things we need to solve, and if there are a bunch of projects, we evaluate them equivalently, but there is definitely value to the project being a CNCF project," says Zolotusky.</p>
+
+<p>Spotify's experiences so far with Kubernetes bears this out. "The community has been extremely helpful in getting us to work through all the technology much faster and much easier," Zolotusky says. "It's been surprisingly easy to get in touch with anybody we wanted to, to get expertise on any of the things we're working with. And it's helped us validate all the things we're doing."</p>
\ No newline at end of file
diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html
index 27340835f4..461e466d8c 100644
--- a/content/en/case-studies/squarespace/index.html
+++ b/content/en/case-studies/squarespace/index.html
@@ -2,100 +2,70 @@
 title: Squarespace Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/squarespace/banner1.jpg
+heading_title_logo: /images/squarespace_logo.png
+subheading: >
+  Squarespace: Gaining Productivity and Resilience with Kubernetes
+case_study_details:
+  - Company: Squarespace
+  - Location: New York, N.Y.
+  - Industry: Software as a Service, Website-Building Platform
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/squarespace/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/squarespace_logo.png" class="header_logo"><br> <div class="subhead">Squarespace: Gaining Productivity and Resilience with Kubernetes
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>Moving from a monolith to microservices in 2014 "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace. "The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."</p>
 
-<div class="details">
-    Company &nbsp;<b>Squarespace</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, N.Y.</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Software as a Service, Website-Building Platform</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    Moving from a monolith to microservices in 2014 "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace. "The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."
-<br>
 <h2>Solution</h2>
-The team experimented with container orchestration platforms, and found that Kubernetes "answered all the questions that we had," says Lynch. The company began running Kubernetes in its data centers in&nbsp;2016.
 
-      </div>
-
-<div class="col2">
+<p>The team experimented with container orchestration platforms, and found that Kubernetes "answered all the questions that we had," says Lynch. The company began running Kubernetes in its data centers in 2016.</p>
 
 <h2>Impact</h2>
-Since Squarespace moved to Kubernetes, in conjunction with modernizing its networking stack, deployment time has been reduced by almost 85%. Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes, and have actual instances containerized, running in our staging environment at that point." Because of that, "productivity time is the big cost saver," he adds. "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on." Resilience has also been improved with Kubernetes: "If a node goes down, it’s rescheduled immediately and there’s no performance&nbsp;impact."
 
-</div>
+<p>Since Squarespace moved to Kubernetes, in conjunction with modernizing its networking stack, deployment time has been reduced by almost 85%. Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes, and have actual instances containerized, running in our staging environment at that point." Because of that, "productivity time is the big cost saver," he adds. "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on." Resilience has also been improved with Kubernetes: "If a node goes down, it's rescheduled immediately and there's no performance impact."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    <iframe width="560" height="315" src="https://www.youtube.com/embed/feQkzJkW-SA" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-    <br><br>"Once you prove that Kubernetes solves one problem, everyone immediately starts solving other problems without you even having to evangelize it."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Since it was started in a dorm room in 2003, Squarespace has made it simple for millions of people to create their own websites.</h2> Behind the scenes, though, the company’s monolithic Java application was making things not so simple for its developers to keep improving the platform. So in 2014, the company decided to "go down the microservices path," says Kevin Lynch, staff engineer on Squarespace’s Site Reliability team. "But we were always deploying our applications in vCenter VMware VMs [in our own data centers]. Microservices solved a problem on the development side, but it pushed that problem to the Infrastructure team. The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."<br><br>
-  After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." Deploying it in the data center rather than the public cloud was their biggest challenge, and at the time, not a lot of other companies were doing that. "We had to figure out how to deploy this in our infrastructure for ourselves, and we had to integrate it with our other applications," says Lynch.<br><br>
-  At the same time, Squarespace’s Network Engineering team was modernizing its networking stack, switching from a traditional layer-two network to a layer-three spine-and-leaf network. "It mapped beautifully with what we wanted to do with Kubernetes," says Lynch. "It gives us the ability to have our servers communicate directly with the top-of-rack switches. We use Calico for <a href="https://github.com/containernetworking/cni">CNI networking for Kubernetes</a>, so we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs."
+{{< case-studies/quote author="Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace" >}}
+<iframe width="560" height="315" src="https://www.youtube.com/embed/feQkzJkW-SA" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<br>
+"Once you prove that Kubernetes solves one problem, everyone immediately starts solving other problems without you even having to evangelize it."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/squarespace/banner3.jpg')">
-  <div class="banner3text">
-    After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
+{{< case-studies/lead >}}
+Since it was started in a dorm room in 2003, Squarespace has made it simple for millions of people to create their own websites.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">fluentd</a> to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."
-<br><br>
-  And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that’s not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there’s some business delay in there as well."
-<br><br>
-  With faster deployments, "productivity time is the big cost saver," says Lynch. "We had a team that was implementing a new file storage service, and they just started integrating that with our storage back end without our involvement"—which wouldn’t have been possible before Kubernetes. He adds: "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on."
+<p>Behind the scenes, though, the company's monolithic Java application was making things not so simple for its developers to keep improving the platform. So in 2014, the company decided to "go down the microservices path," says Kevin Lynch, staff engineer on Squarespace's Site Reliability team. "But we were always deploying our applications in vCenter VMware VMs [in our own data centers]. Microservices solved a problem on the development side, but it pushed that problem to the Infrastructure team. The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."</p>
 
+<p>After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." Deploying it in the data center rather than the public cloud was their biggest challenge, and at the time, not a lot of other companies were doing that. "We had to figure out how to deploy this in our infrastructure for ourselves, and we had to integrate it with our other applications," says Lynch.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/squarespace/banner4.jpg')">
-  <div class="banner4text">
-  "We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
-  </div>
-</div>
+<p>At the same time, Squarespace's Network Engineering team was modernizing its networking stack, switching from a traditional layer-two network to a layer-three spine-and-leaf network. "It mapped beautifully with what we wanted to do with Kubernetes," says Lynch. "It gives us the ability to have our servers communicate directly with the top-of-rack switches. We use Calico for <a href="https://github.com/containernetworking/cni">CNI networking for Kubernetes</a>, so we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  There’s also been a positive impact on the application’s resilience. "When we’re deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it’s rescheduled immediately and there’s no performance impact."
-<br><br>
-  Another big benefit is autoscaling. "It wasn’t really possible with the way we’ve been using VMware," says Lynch, "but now we can just add the appropriate autoscaling features via Kubernetes directly, and boom, it’s scaling up as demand increases. And it worked out of the box."
-<br><br>
-  For others starting out with Kubernetes, Lynch says his best advice is to "fail fast": "Once you’ve planned things out, just execute. Kubernetes has been really great for trying something out quickly and seeing if it works or not."
+{{< case-studies/quote image="/images/case-studies/squarespace/banner3.jpg" >}}
+After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
+{{< /case-studies/quote >}}
 
+<p>Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">fluentd</a> to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."</p>
 
-</div>
+<p>And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that's not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there's some business delay in there as well."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "When we’re deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it’s rescheduled immediately and there’s no performance impact."
-  </div>
-</div>
+<p>With faster deployments, "productivity time is the big cost saver," says Lynch. "We had a team that was implementing a new file storage service, and they just started integrating that with our storage back end without our involvement"—which wouldn't have been possible before Kubernetes. He adds: "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on."</p>
 
-<div class="fullcol">
-  Lynch and his team are planning to open source some of the tools they’ve developed to extend Kubernetes and use it as an API itself. The first tool injects dependent applications as containers in a pod. "When you ship an application, usually it comes along with a whole bunch of dependent applications that need to be shipped with that, for example, fluentd for logging," he explains. With this tool, the developer doesn’t need to worry about the configurations.
-<br><br>
-  Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can. About a quarter of existing services have been migrated. "Our monolithic application is going to be the last one, just because it’s so big and complex," says Lynch. "But now I’m seeing other services get moved over, like the file storage service. Someone just did it and it worked—painlessly. So I believe if we tackle it, it’s probably going to be a lot easier than we fear. Maybe I should just take my own advice and fail fast!"
+{{< case-studies/quote image="/images/case-studies/squarespace/banner4.jpg" >}}
+"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
+{{< /case-studies/quote >}}
 
-</div>
+<p>There's also been a positive impact on the application's resilience. "When we're deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it's rescheduled immediately and there's no performance impact."</p>
 
-</section>
+<p>Another big benefit is autoscaling. "It wasn't really possible with the way we've been using VMware," says Lynch, "but now we can just add the appropriate autoscaling features via Kubernetes directly, and boom, it's scaling up as demand increases. And it worked out of the box."</p>
+
+<p>For others starting out with Kubernetes, Lynch says his best advice is to "fail fast": "Once you've planned things out, just execute. Kubernetes has been really great for trying something out quickly and seeing if it works or not."</p>
+
+{{< case-studies/quote >}}
+"When we're deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it's rescheduled immediately and there's no performance impact."
+{{< /case-studies/quote >}}
+
+<p>Lynch and his team are planning to open source some of the tools they've developed to extend Kubernetes and use it as an API itself. The first tool injects dependent applications as containers in a pod. "When you ship an application, usually it comes along with a whole bunch of dependent applications that need to be shipped with that, for example, fluentd for logging," he explains. With this tool, the developer doesn't need to worry about the configurations.</p>
+
+<p>Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can. About a quarter of existing services have been migrated. "Our monolithic application is going to be the last one, just because it's so big and complex," says Lynch. "But now I'm seeing other services get moved over, like the file storage service. Someone just did it and it worked—painlessly. So I believe if we tackle it, it's probably going to be a lot easier than we fear. Maybe I should just take my own advice and fail fast!"</p>
diff --git a/content/en/case-studies/thredup/index.html b/content/en/case-studies/thredup/index.html
index ad990356ff..fb2cae26d5 100644
--- a/content/en/case-studies/thredup/index.html
+++ b/content/en/case-studies/thredup/index.html
@@ -3,92 +3,75 @@ title: ThredUp Case Study
 linkTitle: thredup
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/thredup/banner1.jpg
+heading_title_logo: /images/thredup_logo.png
+case_study_details:
+  - Company: ThredUp
+  - Location: San Francisco, CA
+  - Industry: eCommerce
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/thredup/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/thredup_logo.png" class="header_logo" style="width:17%;margin-bottom:%"><br> </h1>
-<br><br>
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>ThredUp</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>San Francisco, CA</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>eCommerce</b>
-</div>
+<p>The largest online consignment store for women's and children's clothes, ThredUP launched in 2009 with a monolithic application running on Amazon Web Services. Though the company began breaking up the monolith into microservices a few years ago, the infrastructure  team was still dealing with handcrafted servers, which hampered productivity. "We've configured them just to get them out as fast as we could, but there was no standardization, and as we kept growing, that became a bigger and bigger chore to manage," says Cofounder/CTO Chris Homer. The infrastructure, they realized, needed to be modernized to enable the velocity the company needed. "It's really important to a company like us who's disrupting the retail industry to make sure that as we're building software and getting it out in front of our users, we can do it on a fast cycle and learn a ton as we experiment," adds Homer. "We wanted to make sure that our engineers could embrace the DevOps mindset as they built software. It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    The largest online consignment store for women’s and children’s clothes, ThredUP launched in 2009 with a monolithic application running on Amazon Web Services. Though the company began breaking up the monolith into microservices a few years ago, the infrastructure  team was still dealing with handcrafted servers, which hampered productivity. "We’ve configured them just to get them out as fast as we could, but there was no standardization, and as we kept growing, that became a bigger and bigger chore to manage," says Cofounder/CTO Chris Homer. The infrastructure, they realized, needed to be modernized to enable the velocity the company needed. "It’s really important to a company like us who’s disrupting the retail industry to make sure that as we’re building software and getting it out in front of our users, we can do it on a fast cycle and learn a ton as we experiment," adds Homer. "We wanted to make sure that our engineers could embrace the DevOps mindset as they built software. It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-<br><br>
+<h2>Solution</h2>
+
+<p>In early 2017, the company adopted Kubernetes for container orchestration, and in the course of a year, the entire infrastructure was moved to Kubernetes.</p>
 
-    <h2>Solution</h2>
-    In early 2017, the company adopted Kubernetes for container orchestration, and in the course of a year, the entire infrastructure was moved to Kubernetes.
-<br><br>
 <h2>Impact</h2>
-    Before, "even considering that we already have all the infrastructure in the cloud, databases and services, and all these good things," says Infrastructure Engineer Oleksandr Snagovskyi, setting up a new service meant waiting 2-4 weeks just to get the environment. With Kubernetes, new application roll-out time has decreased from several days or weeks to minutes or hours. Now, says Infrastructure Engineer Oleksii Asiutin, "our developers can experiment with existing applications and create new services, and do it all blazingly fast." In fact, deployment time has decreased about 50% on average for key services. "Lead time" for all applications is under 20 minutes, enabling engineers to deploy multiple times a day. Plus, 3200+ ansible scripts have been deprecated in favor of helm charts. And impressively, hardware cost has decreased 56% while the number of services ThredUP runs has doubled.
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    <iframe width="504" height="296" src="https://www.youtube.com/embed/t0csOf-uDrk" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><br><br>
-    "Moving towards cloud native technologies like Kubernetes really unlocks our ability to experiment quickly and learn from customers along the way."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- CHRIS HOMER, COFOUNDER/CTO, THREDUP</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>The largest online consignment store for women’s and children’s clothes, ThredUP is focused on getting consumers to think second-hand first. "We’re disrupting the retail industry, and it’s really important to us to make sure that as we’re building software and getting it out in front of our users, we can do it on a fast cycle and learn a ton as we experiment," says Cofounder/CTO Chris Homer.
- </h2>
-   But over the past few years, ThredUP, which was launched in 2009 with a monolithic application running on Amazon Web Services, was feeling growing pains as its user base passed the 20- million mark. Though the company had begun breaking up the monolith into microservices, the infrastructure team was still dealing with handcrafted servers, which hampered productivity. "We’ve configured them just to get them out as fast as we could, but there was no standardization, and as we kept growing, that became a bigger and bigger chore to manage," says Homer. The infrastructure, Homer realized, needed to be modernized to enable the velocity—and the culture—the company wanted.
-<br><br>
-  "We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/thredup/banner3.jpg')">
-  <div class="banner3text">
-    "Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday. We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- CHRIS HOMER, COFOUNDER/CTO, THREDUP</span>
+<p>Before, "even considering that we already have all the infrastructure in the cloud, databases and services, and all these good things," says Infrastructure Engineer Oleksandr Snagovskyi, setting up a new service meant waiting 2-4 weeks just to get the environment. With Kubernetes, new application roll-out time has decreased from several days or weeks to minutes or hours. Now, says Infrastructure Engineer Oleksii Asiutin, "our developers can experiment with existing applications and create new services, and do it all blazingly fast." In fact, deployment time has decreased about 50% on average for key services. "Lead time" for all applications is under 20 minutes, enabling engineers to deploy multiple times a day. Plus, 3200+ ansible scripts have been deprecated in favor of helm charts. And impressively, hardware cost has decreased 56% while the number of services ThredUP runs has doubled.</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  In early 2017, Homer found the solution with Kubernetes container orchestration. In the course of a year, the company migrated its entire infrastructure to Kubernetes, starting with its website applications and concluding with its operations backend. Teams are now also using Fluentd and Helm. "Initially there were skeptics about the value that this move to cloud native technologies would bring, but as we went through the process, people very quickly started to realize the benefit of having seamless upgrades and easy rollbacks without having to worry about what was happening," says Homer. "It unlocks the developers’ confidence in being able to deploy quickly, learn, and if you make a mistake, you can roll it back without any issue."
-<br><br>
-  According to the infrastructure team, the key improvement was the consistent experience Kubernetes enabled for developers. "It lets developers work in the same environment that their application will be running in production," says Infrastructure Engineer Oleksandr Snagovskyi. Plus, "It became easier to test, easier to refine, and easier to deploy, because everything’s done automatically," says Infrastructure Engineer Oleksii Asiutin. "One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/thredup/banner4.jpg')">
-  <div class="banner4text">
-  "One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- OLEKSII ASIUTIN, INFRASTRUCTURE ENGINEER, THREDUP</span>
-  </div>
-</div>
+{{< case-studies/quote author="CHRIS HOMER, COFOUNDER/CTO, THREDUP" >}}
+<iframe width="504" height="296" src="https://www.youtube.com/embed/t0csOf-uDrk" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<br>
+"Moving towards cloud native technologies like Kubernetes really unlocks our ability to experiment quickly and learn from customers along the way."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Before, "even considering that we already have all the infrastructure in the cloud, databases and services, and all these good things," says Snagovskyi, setting up a new service meant waiting 2-4 weeks just to get the environment. With Kubernetes, because of simple configuration and minimal dependency on the infrastructure team, the roll-out time for new applications has decreased from several days or weeks to minutes or hours.
-<br><br>
-  In fact, deployment time has decreased about 50% on average for key services. "Fast deployment and parallel test execution in Kubernetes keep a ‘lead time’ for all applications under 20 minutes," allowing engineers to do multiple releases a day, says Director of Infrastructure Roman Chepurnyi. The infrastructure team’s jobs, he adds, have become less burdensome, too: "We can execute seamless upgrades frequently and keep cluster performance and security up-to-date because OS-level hardening and upgrades of a Kubernetes cluster is a non-blocking activity for production operations and does not involve coordination with multiple engineering teams."
-<br><br>
-  More than 3,200 ansible scripts have been deprecated in favor of Helm charts. And impressively, hardware cost has decreased 56% while the number of services ThredUP runs has doubled.
-  </div>
+{{< case-studies/lead >}}
+The largest online consignment store for women's and children's clothes, ThredUP is focused on getting consumers to think second-hand first. "We're disrupting the retail industry, and it's really important to us to make sure that as we're building software and getting it out in front of our users, we can do it on a fast cycle and learn a ton as we experiment," says Cofounder/CTO Chris Homer.
+{{< /case-studies/lead >}}
 
-<div class="banner5" style="width:100%">
-  <div class="banner5text">
-"Our future’s all about automation, and behind that, cloud native technologies are going to unlock our ability to embrace that and go full force towards the future."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- CHRIS HOMER, COFOUNDER/CTO, THREDUP</span></div>
-</div>
+<p>But over the past few years, ThredUP, which was launched in 2009 with a monolithic application running on Amazon Web Services, was feeling growing pains as its user base passed the 20- million mark. Though the company had begun breaking up the monolith into microservices, the infrastructure team was still dealing with handcrafted servers, which hampered productivity. "We've configured them just to get them out as fast as we could, but there was no standardization, and as we kept growing, that became a bigger and bigger chore to manage," says Homer. The infrastructure, Homer realized, needed to be modernized to enable the velocity—and the culture—the company wanted.</p>
 
-<div class="fullcol">
-  Perhaps the impact is most evident on the busiest days in retail. "Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday," says Homer. "We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work. That’s handled for us, and instead we can actually have some turkey, drink some wine and enjoy our families."
-<br><br>
-  For ThredUP, Kubernetes fits perfectly with the company’s vision for how it’s changing retail. Some of what ThredUP does is still very manual: "As our customers send bags of items to our distribution centers, they’re photographed, inspected, tagged, and put online today," says Homer.
-<br><br>
-  But in every other aspect, "we use different forms of technology to drive everything we do," Homer says. "We have machine learning algorithms to help predict the likelihood of sale for items, which drives our pricing algorithm. We have personalization algorithms that look at the images and try to determine style and match users’ preferences across our systems."
-<br><br>
-  Count Kubernetes as one of those drivers. "Our future’s all about automation," says Homer, "and behind that, cloud native technologies are going to unlock our ability to embrace that and go full force towards the future."
-</div>
-</section>
+<p>"We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/thredup/banner3.jpg"
+  author="CHRIS HOMER, COFOUNDER/CTO, THREDUP"
+>}}
+"Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday. We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work."
+{{< /case-studies/quote >}}
+
+<p>In early 2017, Homer found the solution with Kubernetes container orchestration. In the course of a year, the company migrated its entire infrastructure to Kubernetes, starting with its website applications and concluding with its operations backend. Teams are now also using Fluentd and Helm. "Initially there were skeptics about the value that this move to cloud native technologies would bring, but as we went through the process, people very quickly started to realize the benefit of having seamless upgrades and easy rollbacks without having to worry about what was happening," says Homer. "It unlocks the developers' confidence in being able to deploy quickly, learn, and if you make a mistake, you can roll it back without any issue."</p>
+
+<p>According to the infrastructure team, the key improvement was the consistent experience Kubernetes enabled for developers. "It lets developers work in the same environment that their application will be running in production," says Infrastructure Engineer Oleksandr Snagovskyi. Plus, "It became easier to test, easier to refine, and easier to deploy, because everything's done automatically," says Infrastructure Engineer Oleksii Asiutin. "One of the main goals of our team is to make developers' lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/thredup/banner4.jpg"
+  author="OLEKSII ASIUTIN, INFRASTRUCTURE ENGINEER, THREDUP"
+>}}
+"One of the main goals of our team is to make developers' lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."
+{{< /case-studies/quote >}}
+
+<p>Before, "even considering that we already have all the infrastructure in the cloud, databases and services, and all these good things," says Snagovskyi, setting up a new service meant waiting 2-4 weeks just to get the environment. With Kubernetes, because of simple configuration and minimal dependency on the infrastructure team, the roll-out time for new applications has decreased from several days or weeks to minutes or hours.</p>
+
+<p>In fact, deployment time has decreased about 50% on average for key services. "Fast deployment and parallel test execution in Kubernetes keep a 'lead time' for all applications under 20 minutes," allowing engineers to do multiple releases a day, says Director of Infrastructure Roman Chepurnyi. The infrastructure team's jobs, he adds, have become less burdensome, too: "We can execute seamless upgrades frequently and keep cluster performance and security up-to-date because OS-level hardening and upgrades of a Kubernetes cluster is a non-blocking activity for production operations and does not involve coordination with multiple engineering teams."</p>
+
+<p>More than 3,200 ansible scripts have been deprecated in favor of Helm charts. And impressively, hardware cost has decreased 56% while the number of services ThredUP runs has doubled.</p>
+
+{{< case-studies/quote author="CHRIS HOMER, COFOUNDER/CTO, THREDUP">}}
+"Our future's all about automation, and behind that, cloud native technologies are going to unlock our ability to embrace that and go full force towards the future."
+{{< /case-studies/quote >}}
+
+<p>Perhaps the impact is most evident on the busiest days in retail. "Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday," says Homer. "We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work. That's handled for us, and instead we can actually have some turkey, drink some wine and enjoy our families."</p>
+
+<p>For ThredUP, Kubernetes fits perfectly with the company's vision for how it's changing retail. Some of what ThredUP does is still very manual: "As our customers send bags of items to our distribution centers, they're photographed, inspected, tagged, and put online today," says Homer.</p>
+
+<p>But in every other aspect, "we use different forms of technology to drive everything we do," Homer says. "We have machine learning algorithms to help predict the likelihood of sale for items, which drives our pricing algorithm. We have personalization algorithms that look at the images and try to determine style and match users' preferences across our systems."</p>
+
+<p>Count Kubernetes as one of those drivers. "Our future's all about automation," says Homer, "and behind that, cloud native technologies are going to unlock our ability to embrace that and go full force towards the future."</p>
diff --git a/content/en/case-studies/vsco/index.html b/content/en/case-studies/vsco/index.html
index c2ac2a2a72..95d8ae011c 100644
--- a/content/en/case-studies/vsco/index.html
+++ b/content/en/case-studies/vsco/index.html
@@ -3,95 +3,77 @@ title: vsco Case Study
 linkTitle: vsco
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/vsco/banner1.jpg
+heading_title_logo: /images/vsco_logo.png
+subheading: >
+  VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native
+case_study_details:
+  - Company: VSCO
+  - Location: Oakland, CA
+  - Industry: Photo Mobile App
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/vsco/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/vsco_logo.png" class="header_logo" style="width:17%;margin-bottom:-2%"><br> <div class="subhead" style="margin-top:1%">VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>After moving from <a href="https://www.rackspace.com/">Rackspace</a> to <a href="https://aws.amazon.com/">AWS</a> in 2015, <a href="https://vsco.co/">VSCO</a> began building <a href="https://nodejs.org/en/">Node.js</a> and <a href="https://golang.org/">Go</a> microservices in addition to running its <a href="http://php.net/">PHP monolith</a>. The team containerized the microservices using <a href="https://www.docker.com/">Docker</a>, but "they were all in separate groups of <a href="https://aws.amazon.com/ec2/">EC2</a> instances that were dedicated per service," says Melinda Lu, Engineering Manager for the Machine Learning Team. Adds Naveen Gattu, Senior Software Engineer on the Community Team: "That yielded a lot of wasted resources. We started looking for a way to consolidate and be more efficient in the AWS EC2 instances."</p>
 
-<div class="details">
-    Company &nbsp;<b>VSCO</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Oakland, CA</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Photo Mobile App</b>
-</div>
+<h2>Solution</h2>
+
+<p>The team began exploring the idea of a scheduling system, and looked at several solutions including Mesos and Swarm before deciding to go with <a href="https://kubernetes.io/">Kubernetes</a>. VSCO also uses <a href="https://grpc.io/">gRPC</a> and <a href="https://www.envoyproxy.io/">Envoy</a> in their cloud native stack.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Challenge</h2>
-    After moving from <a href="https://www.rackspace.com/">Rackspace</a> to <a href="https://aws.amazon.com/">AWS</a> in 2015, <a href="https://vsco.co/">VSCO</a> began building <a href="https://nodejs.org/en/">Node.js</a> and <a href="https://golang.org/">Go</a> microservices in addition to running its <a href="http://php.net/">PHP monolith</a>. The team containerized the microservices using <a href="https://www.docker.com/">Docker</a>, but "they were all in separate groups of <a href="https://aws.amazon.com/ec2/">EC2</a> instances that were dedicated per service," says Melinda Lu, Engineering Manager for the Machine Learning Team. Adds Naveen Gattu, Senior Software Engineer on the Community Team: "That yielded a lot of wasted resources. We started looking for a way to consolidate and be more efficient in the AWS EC2 instances."
-    <h2>Solution</h2>
-    The team began exploring the idea of a scheduling system, and looked at several solutions including Mesos and Swarm before deciding to go with <a href="https://kubernetes.io/">Kubernetes</a>. VSCO also uses <a href="https://grpc.io/">gRPC</a> and <a href="https://www.envoyproxy.io/">Envoy</a> in their cloud native stack.
-<br>
 <h2>Impact</h2>
-    Before, deployments required "a lot of manual tweaking, in-house scripting that we wrote, and because of our disparate EC2 instances, Operations had to babysit the whole thing from start to finish," says Senior Software Engineer Brendan Ryan. "We didn't really have a story around testing in a methodical way, and using reusable containers or builds in a standardized way." There's a faster onboarding process now. Before, the time to first deploy was two days' hands-on setup time; now it's two hours. By moving to continuous integration, containerization, and Kubernetes, velocity was increased dramatically. The time from code-complete to deployment in production on real infrastructure went from one to two weeks to two to four hours for a typical service. Adds Gattu: "In man hours, that's one person versus a developer and a DevOps individual at the same time." With an 80% decrease in time for a single deployment to happen in production, the number of deployments has increased as well, from 1200/year to 3200/year. There have been real dollar savings too: With Kubernetes, VSCO is running at 2x to 20x greater EC2 efficiency, depending on the service, adding up to about 70% overall savings on the company's EC2 bill. Ryan points to the company's ability to go from managing one large monolithic application to 50+ microservices with "the same size developer team, more or less. And we've only been able to do that because we have increased trust in our tooling and a lot more flexibility, so we don't need to employ a DevOps engineer to tune every service." With Kubernetes, gRPC, and Envoy in place, VSCO has seen an 88% reduction in total minutes of outage time, mainly due to the elimination of JSON-schema errors and service-specific infrastructure provisioning errors, and an increased speed in fixing outages.
 
-</div>
+<p>Before, deployments required "a lot of manual tweaking, in-house scripting that we wrote, and because of our disparate EC2 instances, Operations had to babysit the whole thing from start to finish," says Senior Software Engineer Brendan Ryan. "We didn't really have a story around testing in a methodical way, and using reusable containers or builds in a standardized way." There's a faster onboarding process now. Before, the time to first deploy was two days' hands-on setup time; now it's two hours. By moving to continuous integration, containerization, and Kubernetes, velocity was increased dramatically. The time from code-complete to deployment in production on real infrastructure went from one to two weeks to two to four hours for a typical service. Adds Gattu: "In man hours, that's one person versus a developer and a DevOps individual at the same time." With an 80% decrease in time for a single deployment to happen in production, the number of deployments has increased as well, from 1200/year to 3200/year. There have been real dollar savings too: With Kubernetes, VSCO is running at 2x to 20x greater EC2 efficiency, depending on the service, adding up to about 70% overall savings on the company's EC2 bill. Ryan points to the company's ability to go from managing one large monolithic application to 50+ microservices with "the same size developer team, more or less. And we've only been able to do that because we have increased trust in our tooling and a lot more flexibility, so we don't need to employ a DevOps engineer to tune every service." With Kubernetes, gRPC, and Envoy in place, VSCO has seen an 88% reduction in total minutes of outage time, mainly due to the elimination of JSON-schema errors and service-specific infrastructure provisioning errors, and an increased speed in fixing outages.</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "I've been really impressed seeing how our engineers have come up with creative solutions to things by just combining a lot of Kubernetes primitives. Exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>A photography app for mobile, VSCO was born in the cloud in 2011. In the beginning, "we were using Rackspace and had one PHP monolith application talking to MySQL database, with FTP deployments, no containerization, no orchestration," says Software Engineer Brendan Ryan, "which was sufficient at the time."</h2>
-  After VSCO moved to AWS in 2015 and its user base passed the 30 million mark, the team quickly realized that set-up wouldn't work anymore. Developers had started building some Node and Go microservices, which the team tried containerizing with Docker. But "they were all in separate groups of EC2 instances that were dedicated per service," says Melinda Lu, Engineering Manager for the Machine Learning Team. Adds Naveen Gattu, Senior Software Engineer on the Community Team: "That yielded a lot of wasted resources. We started looking for a way to consolidate and be more efficient in the EC2 instances."
-<br><br>
-  With a checklist that included ease of use and implementation, level of support, and whether it was open source, the team evaluated a few scheduling solutions, including Mesos and Swarm, before deciding to go with Kubernetes. "Kubernetes seemed to have the strongest open source community around it," says Lu. Plus, "We had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes."
+{{< case-studies/quote author="MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM" >}}
+"I've been really impressed seeing how our engineers have come up with creative solutions to things by just combining a lot of Kubernetes primitives. Exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/vsco/banner2.jpg')">
-  <div class="banner3text">
-    "Kubernetes seemed to have the strongest open source community around it, plus, we had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM</span>
+{{< case-studies/lead >}}
+A photography app for mobile, VSCO was born in the cloud in 2011. In the beginning, "we were using Rackspace and had one PHP monolith application talking to MySQL database, with FTP deployments, no containerization, no orchestration," says Software Engineer Brendan Ryan, "which was sufficient at the time."
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  At the time, there were few managed Kubernetes offerings and less tooling available in the ecosystem, so the team stood up its own cluster and built some custom components for its specific deployment needs, such as an automatic ingress controller and policy constructs for canary deploys. "We had already begun breaking up the monolith, so we moved things one by one, starting with pretty small, low-risk services," says Lu. "Every single new service was deployed there." The first service was migrated at the end of 2016, and after one year, 80% of the entire stack was on Kubernetes, including the rest of the monolith.
-<br><br>
-  The impact has been great. Deployments used to require "a lot of manual tweaking, in-house scripting that we wrote, and because of our disparate EC2 instances, Operations had to babysit the whole thing from start to finish," says Ryan. "We didn't really have a story around testing in a methodical way, and using reusable containers or builds in a standardized way." There's a faster onboarding process now. Before, the time to first deploy was two days' hands-on setup time; now it's two hours.
-<br><br>
-  By moving to continuous integration, containerization, and Kubernetes, velocity was increased dramatically. The time from code-complete to deployment in production on real infrastructure went from one to two weeks to two to four hours for a typical service. Plus, says Gattu, "In man hours, that's one person versus a developer and a DevOps individual at the same time." With an 80% decrease in time for a single deployment to happen in production, the number of deployments has increased as well, from 1200/year to 3200/year.
+<p>After VSCO moved to AWS in 2015 and its user base passed the 30 million mark, the team quickly realized that set-up wouldn't work anymore. Developers had started building some Node and Go microservices, which the team tried containerizing with Docker. But "they were all in separate groups of EC2 instances that were dedicated per service," says Melinda Lu, Engineering Manager for the Machine Learning Team. Adds Naveen Gattu, Senior Software Engineer on the Community Team: "That yielded a lot of wasted resources. We started looking for a way to consolidate and be more efficient in the EC2 instances."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/vsco/banner4.jpg')">
-  <div class="banner4text">
-  "I've been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives, exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MELINDA LU, ENGINEERING MANAGER FOR VSCO’S MACHINE LEARNING TEAM</span>
-  </div>
-</div>
+<p>With a checklist that included ease of use and implementation, level of support, and whether it was open source, the team evaluated a few scheduling solutions, including Mesos and Swarm, before deciding to go with Kubernetes. "Kubernetes seemed to have the strongest open source community around it," says Lu. Plus, "We had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  There have been real dollar savings too: With Kubernetes, VSCO is running at 2x to 20x greater EC2 efficiency, depending on the service, adding up to about 70% overall savings on the company’s EC2 bill.
-<br><br>
-  Ryan points to the company’s ability to go from managing one large monolithic application to 50+ microservices with “the same size developer team, more or less. And we’ve only been able to do that because we have increased trust in our tooling and a lot more flexibility when there are stress points in our system. You can increase CPU memory requirements of a service without having to bring up and tear down instances, and read through AWS pages just to be familiar with a lot of jargon, which isn’t really tenable for a company at our scale.”
-<br><br>
-  Envoy and gRPC have also had a positive impact at VSCO. “We get many benefits from gRPC out of the box: type safety across multiple languages, ease of defining services with the gRPC IDL, built-in architecture like interceptors, and performance improvements over HTTP/1.1 and JSON,” says Lu.
-<br><br>
-  VSCO was one of the first users of Envoy, getting it in production five days after it was open sourced. “We wanted to serve gRPC and HTTP/2 directly to mobile clients through our edge load balancers, and Envoy was our only reasonable solution,” says Lu. “The ability to send consistent and detailed stats by default across all services has made observability and standardization of dashboards much easier.” The metrics that come built in with Envoy have also “greatly helped with debugging,” says DevOps Engineer Ryan Nguyen.
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/vsco/banner2.jpg"
+  author="MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM"
+>}}
+"Kubernetes seemed to have the strongest open source community around it, plus, we had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes."
+{{< /case-studies/quote >}}
 
-<div class="banner5" style="width:100%">
-  <div class="banner5text">
-"Because there’s now an organization that supports Kubernetes, does that build confidence? The answer is a resounding yes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- NAVEEN GATTU, SENIOR SOFTWARE ENGINEER ON VSCO’S COMMUNITY TEAM</span></div>
-</div>
+<p>At the time, there were few managed Kubernetes offerings and less tooling available in the ecosystem, so the team stood up its own cluster and built some custom components for its specific deployment needs, such as an automatic ingress controller and policy constructs for canary deploys. "We had already begun breaking up the monolith, so we moved things one by one, starting with pretty small, low-risk services," says Lu. "Every single new service was deployed there." The first service was migrated at the end of 2016, and after one year, 80% of the entire stack was on Kubernetes, including the rest of the monolith.</p>
 
-<div class="fullcol">
-  With Kubernetes, gRPC, and Envoy in place, VSCO has seen an 88% reduction in total minutes of outage time, mainly due to the elimination of JSON-schema errors and service-specific infrastructure provisioning errors, and an increased speed in fixing outages.
-<br><br>
-  Given its success using CNCF projects, VSCO is starting to experiment with others, including <a href="https://github.com/containernetworking">CNI</a> and Prometheus. “To have a large organization backing these technologies, we have a lot more confidence trying this software and deploying to production,” says Nguyen.
-<br><br>
-  The team has made contributions to gRPC and Envoy, and is hoping to be even more active in the CNCF community. “I’ve been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives,” says Lu. “Exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it.”
+<p>The impact has been great. Deployments used to require "a lot of manual tweaking, in-house scripting that we wrote, and because of our disparate EC2 instances, Operations had to babysit the whole thing from start to finish," says Ryan. "We didn't really have a story around testing in a methodical way, and using reusable containers or builds in a standardized way." There's a faster onboarding process now. Before, the time to first deploy was two days' hands-on setup time; now it's two hours.</p>
 
-</div>
-</section>
+<p>By moving to continuous integration, containerization, and Kubernetes, velocity was increased dramatically. The time from code-complete to deployment in production on real infrastructure went from one to two weeks to two to four hours for a typical service. Plus, says Gattu, "In man hours, that's one person versus a developer and a DevOps individual at the same time." With an 80% decrease in time for a single deployment to happen in production, the number of deployments has increased as well, from 1200/year to 3200/year.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/vsco/banner4.jpg"
+  author="MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM"
+>}}
+"I've been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives, exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it."
+{{< /case-studies/quote >}}
+
+<p>There have been real dollar savings too: With Kubernetes, VSCO is running at 2x to 20x greater EC2 efficiency, depending on the service, adding up to about 70% overall savings on the company's EC2 bill.</p>
+
+<p>Ryan points to the company's ability to go from managing one large monolithic application to 50+ microservices with "the same size developer team, more or less. And we've only been able to do that because we have increased trust in our tooling and a lot more flexibility when there are stress points in our system. You can increase CPU memory requirements of a service without having to bring up and tear down instances, and read through AWS pages just to be familiar with a lot of jargon, which isn't really tenable for a company at our scale."</p>
+
+<p>Envoy and gRPC have also had a positive impact at VSCO. "We get many benefits from gRPC out of the box: type safety across multiple languages, ease of defining services with the gRPC IDL, built-in architecture like interceptors, and performance improvements over HTTP/1.1 and JSON," says Lu.</p>
+
+<p>VSCO was one of the first users of Envoy, getting it in production five days after it was open sourced. "We wanted to serve gRPC and HTTP/2 directly to mobile clients through our edge load balancers, and Envoy was our only reasonable solution," says Lu. "The ability to send consistent and detailed stats by default across all services has made observability and standardization of dashboards much easier." The metrics that come built in with Envoy have also "greatly helped with debugging," says DevOps Engineer Ryan Nguyen.</p>
+
+{{< case-studies/quote author="NAVEEN GATTU, SENIOR SOFTWARE ENGINEER ON VSCO'S COMMUNITY TEAM" >}}
+"Because there's now an organization that supports Kubernetes, does that build confidence? The answer is a resounding yes."
+{{< /case-studies/quote >}}
+
+<p>With Kubernetes, gRPC, and Envoy in place, VSCO has seen an 88% reduction in total minutes of outage time, mainly due to the elimination of JSON-schema errors and service-specific infrastructure provisioning errors, and an increased speed in fixing outages.</p>
+
+<p>Given its success using CNCF projects, VSCO is starting to experiment with others, including <a href="https://github.com/containernetworking">CNI</a> and Prometheus. "To have a large organization backing these technologies, we have a lot more confidence trying this software and deploying to production," says Nguyen.</p>
+
+<p>The team has made contributions to gRPC and Envoy, and is hoping to be even more active in the CNCF community. "I've been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives," says Lu. "Exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it."</p>
diff --git a/content/en/case-studies/wikimedia/index.html b/content/en/case-studies/wikimedia/index.html
index abc74e3ee3..b10002af83 100644
--- a/content/en/case-studies/wikimedia/index.html
+++ b/content/en/case-studies/wikimedia/index.html
@@ -1,96 +1,66 @@
 ---
 title: Wikimedia Case Study
-
-class: gridPage
+case_study_styles: true
 cid: caseStudies
+
+new_case_study_styles: true
+heading_title_text: Wikimedia
+use_gradient_overlay: true
+subheading: >
+  Using Kubernetes to Build Tools to Improve the World's Wikis
+case_study_details:
+  - Company: Wikimedia
+  - Location: San Francisco, CA
 ---
 
-<section id="hero" class="light-text">
-    <h1> Wikimedia Case Study</h1>
-</section>
+<p>The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.</p>
 
-<section id="mainContent">
-    <main>
-        <div class="content">
-            <h3 id="caseStudyTitle">Using Kubernetes to Build Tools to Improve the World's Wikis</h3>
-            <p>
-                The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.
-            </p>
-            <div class="feature">
-                <img src="/images/wikimedia_logo.png" alt="Wikimedia">
-                <p class="quote">
-                    "Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better."
-                </p>
-                <p class="attrib">— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs</p>
-            </div>
-        </div>
-    </main>
-</section>
+{{< case-studies/quote author="Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs">}}
+<img src="/images/wikimedia_logo.png" alt="Wikimedia">
+<br>
+<br>
+"Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better."
+{{< /case-studies/quote >}}
 
-<section class="bullets">
-    <main>
-        <div class="content">
-            <div class="bullet">
-                <h4>Challenges:</h4>
-                <ul>
-                    <li>Simplify a complex, difficult-to-manage infrastructure</li>
-                    <li>Allow developers to continue writing tools and bots using existing techniques</li>
-                </ul>
-            </div>
-            <div class="bullet">
-                <h4>Why Kubernetes:</h4>
-                <ul>
-                    <li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
-                </ul>
-            </div>
-            <div class="bullet">
-                <h4>Approach:</h4>
-                <ul>
-                    <li>Migrate old systems and a complex infrastructure to Kubernetes</li>
-                </ul>
-            </div>
-            <div class="bullet">
-                <h4>Results:</h4>
-                <ul>
-                    <li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
-                    <li>A 25-node cluster that keeps up with each new Kubernetes release</li>
-                    <li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
-                </ul>
-            </div>
-        </div>
-    </main>
-</section>
+<h2>Challenges</h2>
 
-<section class="details">
-    <main>
-        <div class="content">
-            <h4>Using Kubernetes to provide tools for maintaining wikis</h4>
-            <p>
-                Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It's incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."
-            </p>
-            <p>
-                To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.
-            </p>
-            <p>
-                "With Kubernetes, I've been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users' code also runs in a more stable way than previously," says Yuvi.
-            </p>
-        </div>
-    </main>
-</section>
+<ul>
+  <li>Simplify a complex, difficult-to-manage infrastructure</li>
+  <li>Allow developers to continue writing tools and bots using existing techniques</li>
+</ul>
 
-<section class="details">
-    <main>
-        <div class="content">
-            <h4>Simplifying infrastructure and keeping wikis running better</h4>
-            <p>
-                Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don't have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.
-            </p>
-            <p>
-                In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs' web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.
-            </p>
-            <p>
-                "Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.
-            </p>
-        </div>
-    </main>
-</section>
+<h2>Why Kubernetes</h2>
+
+<ul>
+  <li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
+</ul>
+
+<h2>Approach</h2>
+
+<ul>
+  <li>Migrate old systems and a complex infrastructure to Kubernetes</li>
+</ul>
+
+<h2>Results</h2>
+
+<ul>
+  <li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
+  <li>A 25-node cluster that keeps up with each new Kubernetes release</li>
+  <li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
+</ul>
+
+<h2>Using Kubernetes to provide tools for maintaining wikis</h2>
+
+<p>Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It's incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."</p>
+
+<p>To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.</p>
+
+<p>"With Kubernetes, I've been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users' code also runs in a more stable way than previously," says Yuvi.</p>
+
+<h2>Simplifying infrastructure and keeping wikis running better</h2>
+
+<p>Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don't have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.</p>
+
+<p>In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs' web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.</p>
+
+<p>"Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.</p>
diff --git a/content/en/case-studies/wink/index.html b/content/en/case-studies/wink/index.html
index 3f47f8c779..1f8ea4c89d 100644
--- a/content/en/case-studies/wink/index.html
+++ b/content/en/case-studies/wink/index.html
@@ -1,109 +1,87 @@
 ---
 title: Wink Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_wink.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/wink/banner1.jpg
+heading_title_logo: /images/wink_logo.png
+subheading: >
+  Cloud-Native Infrastructure Keeps Your Smart Home Connected
+case_study_details:
+  - Company: Wink
+  - Location: New York, N.Y.
+  - Industry: Internet of Things Platform
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/wink_logo.png" width="13%" style="margin-bottom:-4px"><br>
-    <div class="subhead">Cloud-Native Infrastructure Keeps Your Smart Home Connected</div>
-  </h1>
-</div>
+<h2>Challenge</h2>
 
+<p>Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company's consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.</p>
 
-<div class="details">
-    Company &nbsp;<b>Wink</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, N.Y.</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Internet of Things Platform</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.</p>
 
-<section class="section1">
-<div class="cols">
-  <div class="col1">
+<h2>Impact</h2>
 
-      <h2>Challenge</h2>
-        Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company’s consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.
-        <br><br>
-      <h2>Solution</h2>
-        Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.<br><br>
-  </div>
+<p>"Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware," Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink's workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively easy."</p>
 
-  <div class="col2">
-    <h2>Impact</h2>
-      "Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware,” Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink’s workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively&nbsp;easy.”
-  </div>
+{{< case-studies/quote author="KIT KLEIN, HEAD OF ENGINEERING, WINK" >}}
+"It's not proprietary, it's totally open, it's really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That's the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+{{< case-studies/lead >}}
+How many people does it take to turn on a light bulb?
+{{< /case-studies/lead >}}
 
+<p>Kit Klein whips out his phone to demonstrate. With a few swipes, the head of engineering at Wink pulls up the smart-home app created by the New York City-based company and taps the light button. "Honestly when you're holding the phone and you're hitting the light," he says, "by the time you feel the pressure of your finger on the screen, it's on. It takes as long as the signal to travel to your brain."</p>
 
-<div class="banner2">
-  <div class="banner2text">
-      "It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><span style="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
-  </div>
-</div>
+<p>Sure, it takes just one finger and less than 200 milliseconds to turn on the light – or lock a door or change a thermostat. But what allows Wink to help consumers manage their connected smart-home products with such speed and ease is a sophisticated, cloud native infrastructure that Klein and his team built and continue to develop using a unified stack of CoreOS, the open-source operating system designed for clustered deployments, and Kubernetes, an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. "When you have a big, complex network of interdependent microservices that need to be able to discover each other, and need to be horizontally scalable and tolerant to failure, that's what this is really optimized for," says Klein. "A lot of people end up relying on proprietary services [offered by some big cloud providers] to do some of this stuff, but what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate."</p>
 
+<p>Indeed, Wink did. The company's mission statement is to make the connected home accessible – that is, user-friendly for non-technical owners, affordable and perhaps most importantly, reliable. "If you can't trust that when you hit the switch, you know a light is going to go on, or if you're remote and you're checking on your house and that information isn't accurate, then the convenience of the system is lost," says Klein. "So that's where the infrastructure comes in."</p>
 
-<section class="section2">
-  <div class="fullcol">
-      <h2>How many people does it take to turn on a light bulb?</h2>
+<p>Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.</p>
 
-      Kit Klein whips out his phone to demonstrate. With a few swipes, the head of engineering at Wink pulls up the smart-home app created by the New York City-based company and taps the light button. "Honestly when you’re holding the phone and you’re hitting the light,” he says, "by the time you feel the pressure of your finger on the screen, it’s on. It takes as long as the signal to travel to your brain.”<br><br>
-      Sure, it takes just one finger and less than 200 milliseconds to turn on the light – or lock a door or change a thermostat. But what allows Wink to help consumers manage their connected smart-home products with such speed and ease is a sophisticated, cloud native infrastructure that Klein and his team built and continue to develop using a unified stack of CoreOS, the open-source operating system designed for clustered deployments, and Kubernetes, an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. "When you have a big, complex network of interdependent microservices that need to be able to discover each other, and need to be horizontally scalable and tolerant to failure, that’s what this is really optimized for,” says Klein. "A lot of people end up relying on proprietary services [offered by some big cloud providers] to do some of this stuff, but what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate.”<br><br>
-      Indeed, Wink did. The company’s mission statement is to make the connected home accessible – that is, user-friendly for non-technical owners, affordable and perhaps most importantly, reliable. "If you can’t trust that when you hit the switch, you know a light is going to go on, or if you’re remote and you’re checking on your house and that information isn’t accurate, then the convenience of the system is lost,” says Klein. "So that’s where the infrastructure comes in.”<br><br>
-      Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.<br><br>
-      "When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product,” says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it.”
+<p>"When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product," says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it."</p>
 
-  </div>
-</section>
+{{< case-studies/quote image="/images/case-studies/wink/banner3.jpg">}}
+"...what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate."
+{{< /case-studies/quote >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    "...what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate.”
-  </div>
-</div>
+<p>Concern number one: Wink's products need to connect to consumer devices in people's homes, behind a firewall. "You don't have an end point like a URL, and you don't even know what ports are open behind that firewall," Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it's really, really important that it's persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights."</p>
 
-<section class="section3">
-  <div class="fullcol">
-    Concern number one: Wink’s products need to connect to consumer devices in people’s homes, behind a firewall. "You don’t have an end point like a URL, and you don’t even know what ports are open behind that firewall,” Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights.”<br><br>
-    With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink’s software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.
-    <br><br>
-    <h2>"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent...you never know when someone is going to turn on the&nbsp;lights.”</h2>
-    In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service,” says Klein. "We’ve always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker.”<br><br>
-    At the time – just over two years ago – Docker wasn’t yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn’t really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads.”<br><br>
-    Once Wink’s backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can’t just start the containers and hope everything goes well,” Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure.”
+<p>With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink's software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.</p>
 
-  </div>
-</section>
+{{< case-studies/lead >}}
+"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it's really, really important that it's persistent...you never know when someone is going to turn on the lights."
+{{< /case-studies/lead >}}
 
-  <div class="banner4">
-    <div class="banner4text">
-    "Obviously you can’t just start the containers and hope everything goes well,” Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure.”
-    </div>
-  </div>
+<p>In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service," says Klein. "We've always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker."</p>
 
-<section class="section4">
-  <div class="fullcol">
-    Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed,” he says. "We didn’t have to futz around with trying to take something like a Linux distro and install everything. It’s got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It’s not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed.”<br><br>
-    Wink’s hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they’ve moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters. <br><br>
-    Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn’t take care of routing, sharing configurations, secrets, et cetera, among instances of a service,” Klein says. "All of those layers of functionality can be implemented, of course, but if you don’t want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did.”<br><br>
-    Wink quickly embraced the Kubernetes container cluster manager when it was launched in 2015 and integrated with CoreOS core technology, and as promised, it ended up providing the features Wink wanted and had planned to build. "If not for Kubernetes, we likely would have taken the logic and library we implemented for the automation tool that we created, and would have used it in a higher level abstraction and tool that could be used by non-DevOps engineers from the command line to create and manage clusters,” Klein says. "But Kubernetes made that totally unnecessary – and is written and maintained by people with a lot more experience in cluster management than us, so all the better.” Now, an estimated 80 percent of Wink’s workload is run on Kubernetes on top of CoreOS Container Linux.
+<p>At the time – just over two years ago – Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."</p>
 
-  </div>
-</section>
+<p>Once Wink's backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."</p>
 
-  <div class="banner5">
-    <div class="banner5text">
-      "Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”
-    </div>
-  </div>
+{{< case-studies/quote image="/images/case-studies/wink/banner4.jpg" >}}
+"Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."
+{{< /case-studies/quote >}}
 
-<section class="section5">
-  <div class="fullcol">
-    Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
-    Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people,” he says. "In order to take advantage of this, you really have to keep up with the technology. You can’t treat it like it’s a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”<br><br>
-    Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What’s next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware,” Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has have built.<br><br>
-    Wink’s engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs,” he says. "It’s like data pipelines as microservices.” Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You’re not reinventing the wheel every time,” he says. "You can just get down to work.”  </div>
-</section>
+<p>Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed," he says. "We didn't have to futz around with trying to take something like a Linux distro and install everything. It's got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It's not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed."</p>
+
+<p>Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.</p>
+
+<p>Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn't take care of routing, sharing configurations, secrets, et cetera, among instances of a service," Klein says. "All of those layers of functionality can be implemented, of course, but if you don't want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did."</p>
+
+<p>Wink quickly embraced the Kubernetes container cluster manager when it was launched in 2015 and integrated with CoreOS core technology, and as promised, it ended up providing the features Wink wanted and had planned to build. "If not for Kubernetes, we likely would have taken the logic and library we implemented for the automation tool that we created, and would have used it in a higher level abstraction and tool that could be used by non-DevOps engineers from the command line to create and manage clusters," Klein says. "But Kubernetes made that totally unnecessary – and is written and maintained by people with a lot more experience in cluster management than us, so all the better." Now, an estimated 80 percent of Wink's workload is run on Kubernetes on top of CoreOS Container Linux.</p>
+
+{{< case-studies/quote >}}
+"Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it."
+{{< /case-studies/quote >}}
+
+<p>Wink's reasons for going all in are clear: "It's not proprietary, it's totally open, it's really portable," Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That's the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time."</p>
+
+<p>Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people," he says. "In order to take advantage of this, you really have to keep up with the technology. You can't treat it like it's a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it."</p>
+
+<p>Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What's next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware," Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has have built.</p>
+
+<p>Wink's engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs," he says. "It's like data pipelines as microservices." Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You're not reinventing the wheel every time," he says. "You can just get down to work."</p>
diff --git a/content/en/case-studies/woorank/index.html b/content/en/case-studies/woorank/index.html
index fbb86bdd24..d83240d878 100644
--- a/content/en/case-studies/woorank/index.html
+++ b/content/en/case-studies/woorank/index.html
@@ -3,94 +3,77 @@ title: Woorank Case Study
 linkTitle: woorank
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/woorank/banner1.jpg
+heading_title_logo: /images/woorank_logo.png
+subheading: >
+  Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with 12 Engineers—At 30% Less Cost
+case_study_details:
+  - Company: Woorank
+  - Location: Brussels, Belgium
+  - Industry: Digital marketing tool
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/woorank/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/woorank_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%">Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with<br>12 Engineers—At 30% Less Cost
-</div></h1>
+<p>Founded in 2011, Woorank embraced microservices and containerization early on, so its core product, a tool that helps digital marketers improve their websites' visibility on the internet, consists of 50 applications developed and maintained by a technical team of 12. For two years, the infrastructure ran smoothly on Mesos, but "there were still lots of our own libraries that we had to roll and applications that we had to bring in, so it was very cumbersome for us as a small team to keep those things alive and to update them," says CTO/Cofounder Nils De Moor. So he began looking for a new solution with more automation and self-healing built in, that would better suit the company's human resources.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Woorank</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Brussels, Belgium</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Digital marketing tool</b>
-</div>
+<p>De Moor decided to switch to <a href="https://kubernetes.io/">Kubernetes</a> running on <a href="https://aws.amazon.com/">AWS</a>, which "allows us to just define applications, how they need to run, how scalable they need to be, and it takes pain away from the developers thinking about that," he says. "When things fail and errors pop up, the system tries to heal itself, and that's really, for us, the key reason to work with Kubernetes." The company now also uses <a href="https://www.fluentd.org/">Fluentd</a>, <a href="https://prometheus.io/">Prometheus</a>, and <a href="http://opentracing.io/">OpenTracing</a>.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-
-    <h2>Challenge</h2>
-    Founded in 2011, Woorank embraced microservices and containerization early on, so its core product, a tool that helps digital marketers improve their websites’ visibility on the internet, consists of 50 applications developed and maintained by a technical team of 12. For two years, the infrastructure ran smoothly on Mesos, but “there were still lots of our own libraries that we had to roll and applications that we had to bring in, so it was very cumbersome for us as a small team to keep those things alive and to update them,” says CTO/Cofounder Nils De Moor. So he began looking for a new solution with more automation and self-healing built in, that would better suit the company’s human resources.
-    <h2>Solution</h2>
-    De Moor decided to switch to <a href="https://kubernetes.io/">Kubernetes</a> running on <a href="https://aws.amazon.com/">AWS</a>, which “allows us to just define applications, how they need to run, how scalable they need to be, and it takes pain away from the developers thinking about that,” he says. “When things fail and errors pop up, the system tries to heal itself, and that’s really, for us, the key reason to work with Kubernetes.” The company now also uses <a href="https://www.fluentd.org/">Fluentd</a>, <a href="https://prometheus.io/">Prometheus</a>, and <a href="http://opentracing.io/">OpenTracing</a>.
 <h2>Impact</h2>
-    The company’s number one concern was immediately erased: Maintaining Kubernetes takes just one person on staff, and it’s not a fulltime job. Infrastructure updates used to take two active working days; now it’s just a matter of “a few hours of passively following the process,” says De Moor. Implementing new tools—which once took weeks of planning, installing, and onboarding—now only takes a few days. “We were already pretty flexible in our costs and taking on traffic peaks and higher load in general,” adds De Moor, “but with Kubernetes and the other CNCF tools we use, we have achieved about 30% in cost savings.” Plus, the rate of deployments per day has nearly doubled.
 
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    “It was definitely important for us to have CNCF as an umbrella above everything. We’ve always been working with open source libraries and tools and technologies. It works very well for us, but sometimes things can drift, maintainers drop out, and projects go haywire. For us, it was indeed important to know that whatever project gets taken under this umbrella, it’s taken very seriously. Our way of contributing back is also by joining this community. It’s, for us, a way to show our appreciation for what’s going on in this framework.”
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— NILS DE MOOR, CTO/COFOUNDER, WOORANK</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Woorank’s core product is a tool that enables digital marketers to improve their websites’ visibility on the internet.</h2>
-  “We help them acquire lots of data and then present it to them in meaningful ways so they can work with it,” says CTO/Cofounder Nils De Moor. In its seven years as a startup, the company followed a familiar technological path to build that product: starting with a monolithic application, breaking it down into microservices, and then embracing containerization. “That’s where our modern infrastructure started out,” says De Moor.
-<br><br>
-  As new features have been added to the product, it has grown to consist of 50 applications under the hood. Though Docker had made things easier to deploy, and the team had been using Mesos as an orchestration framework on AWS since 2015, De Moor realized there was still too much overhead to managing the infrastructure, especially with a technical team of just 12.
-<br><br>
-  “The pain point was that there were still lots of our own libraries that we had to roll and applications that we had to bring in, so it was very cumbersome for us as a small team to keep those things alive and to update them,” says De Moor. “When things went wrong during deployment, someone manually had to come in and figure it out. It wasn’t necessarily that the technology or anything was wrong with Mesos; it was just not really fitting our model of being a small company, not having the human resources to make sure it all works and can be updated.”
+<p>The company's number one concern was immediately erased: Maintaining Kubernetes takes just one person on staff, and it's not a fulltime job. Infrastructure updates used to take two active working days; now it's just a matter of "a few hours of passively following the process," says De Moor. Implementing new tools—which once took weeks of planning, installing, and onboarding—now only takes a few days. "We were already pretty flexible in our costs and taking on traffic peaks and higher load in general," adds De Moor, "but with Kubernetes and the other CNCF tools we use, we have achieved about 30% in cost savings." Plus, the rate of deployments per day has nearly doubled.</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/woorank/banner3.jpg')">
-  <div class="banner3text">
-    "Cloud native technologies have brought to us a transparency on everything going on in our system, from the code to the server. It has brought huge cost savings and a better way of dealing with those costs and keeping them under control. And performance-wise, it has helped our team understand how we can make our code work better on the cloud native infrastructure."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— NILS DE MOOR, CTO/COFOUNDER, WOORANK</span>
+{{< case-studies/quote author="NILS DE MOOR, CTO/COFOUNDER, WOORANK" >}}
+"It was definitely important for us to have CNCF as an umbrella above everything. We've always been working with open source libraries and tools and technologies. It works very well for us, but sometimes things can drift, maintainers drop out, and projects go haywire. For us, it was indeed important to know that whatever project gets taken under this umbrella, it's taken very seriously. Our way of contributing back is also by joining this community. It's, for us, a way to show our appreciation for what's going on in this framework."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
+{{< case-studies/lead >}}
+Woorank's core product is a tool that enables digital marketers to improve their websites' visibility on the internet.
+{{< /case-studies/lead >}}
 
-<section class="section3">
-<div class="fullcol">
-  Around the time Woorank was grappling with these issues, Kubernetes was emerging as a technology. De Moor knew that he wanted a platform that would be more automated and self-healing, and when he began experimenting with Kubernetes, he found that it checked all those boxes. “Kubernetes allows us to just define applications, how they need to run, how scalable they need to be, and it takes pain away from the developers thinking about that,” he says. “When things fail and errors pop up, the system tries to heal itself, and that’s really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It’s made people’s lives much easier. It’s quite a big mindset change.”
-<br><br>
-  Once one small Kubernetes cluster was up and running, the team began moving over a few applications at a time, gradually increasing the load over the course of several months. By early 2017, Woorank was 100% deployed on Kubernetes.
-<br><br>
-  The company’s number one concern was immediately erased: Maintaining Kubernetes is the responsibility of just one person on staff, and it’s not his fulltime job. Updating the old infrastructure “was always a pain,” says De Moor: It used to take two active working days, “and it was always a bit scary when we did that.” With Kubernetes, it’s just a matter of “a few hours of passively following the process.”
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/woorank/banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-  "When things fail and errors pop up, the system tries to heal itself, and that’s really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It’s made people’s lives much easier. It’s quite a big mindset change." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- NILS DE MOOR, CTO/COFOUNDER, WOORANK</span>
-  </div>
-</div>
+<p>"We help them acquire lots of data and then present it to them in meaningful ways so they can work with it," says CTO/Cofounder Nils De Moor. In its seven years as a startup, the company followed a familiar technological path to build that product: starting with a monolithic application, breaking it down into microservices, and then embracing containerization. "That's where our modern infrastructure started out," says De Moor.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Transparency on all levels, from the code to the servers, has also been a byproduct of the move to Kubernetes. “It’s easier for the entire team to get a better understanding of the infrastructure, how it’s working, how it looks like, what’s going on,” says De Moor. “It’s not that thing that’s running, and no one really knows how it works except this one person. Now it’s really a team effort of everyone knowing, ‘Okay, when something goes wrong, it’s probably in this area or we need to check this.’”
-<br><br>
-  To that end, Woorank has begun implementing other cloud native tools that help with visibility, such as Fluentd for logging, Prometheus for monitoring, and OpenTracing for distributed tracing. Implementing these new tools—which once took weeks of planning, installing, and onboarding—now only takes a few days. “With all the tools and projects under the CNCF umbrella, it’s easier for us to test and play with technology than it used to be,” says De Moor. “With Prometheus, we used it fairly early and couldn’t get it fairly stable. A couple of months ago, the question reappeared, so we set it up in two days, and now everyone is using it.”
-<br><br>
-  Deployments, too, have been impacted: The rate has more than doubled, which De Moor partly attributes to the transparency of the new process. “With Kubernetes, you see that these three containers didn’t start for this reason,” he says. Plus, “now we bring deployment messages into Slack. If you see deployments rolling by every day, it does somehow indirectly enforce you, okay, I need to be part of this train, so I also need to deploy.”
-</div>
+<p>As new features have been added to the product, it has grown to consist of 50 applications under the hood. Though Docker had made things easier to deploy, and the team had been using Mesos as an orchestration framework on AWS since 2015, De Moor realized there was still too much overhead to managing the infrastructure, especially with a technical team of just 12.</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-"We can plan those things over a certain timeline, try to fit our resource usage to that, and then bring in spot instances, which will hopefully drive the costs&nbsp;down&nbsp;more."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- NILS DE MOOR, CTO/COFOUNDER, WOORANK</span></div>
-</div>
+<p>"The pain point was that there were still lots of our own libraries that we had to roll and applications that we had to bring in, so it was very cumbersome for us as a small team to keep those things alive and to update them," says De Moor. "When things went wrong during deployment, someone manually had to come in and figure it out. It wasn't necessarily that the technology or anything was wrong with Mesos; it was just not really fitting our model of being a small company, not having the human resources to make sure it all works and can be updated."</p>
 
-<div class="fullcol">
-  Perhaps the biggest impact, though, has been on the bottom line. “We were already pretty flexible in our costs and taking on traffic peaks and higher load in general, but with Kubernetes and the other CNCF tools we use, we have achieved about 30% in cost savings,” says De Moor.
-<br><br>
-  And there’s room for even greater savings. Currently, most of Woorank’s infrastructure is running on AWS on demand; the company pays a fixed price and makes some reservations for its planned amount of resources needed. De Moor is planning to experiment more with spot instances with certain resource-heavy workloads such as web crawls: “We can plan those things over a certain timeline, try to fit our resource usage to that, and then bring in spot instances, which will hopefully drive the costs down more.”
-<br><br>
-  Moving to Kubernetes has been so beneficial to Woorank that the company is doubling down on both cloud native technologies and the community. “It was definitely important for us to have CNCF as an umbrella above everything,” says De Moor. “We’ve always been working with open source libraries and tools and technologies. It works very well for us, but sometimes things can drift, maintainers drop out, and projects go haywire. For us, it was indeed important to know that whatever project gets taken under this umbrella, it’s taken very seriously. Our way of contributing back is also by joining this community. It’s, for us, a way to show our appreciation for what’s going on in this framework.”
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/woorank/banner3.jpg"
+  author="NILS DE MOOR, CTO/COFOUNDER, WOORANK"
+>}}
+"Cloud native technologies have brought to us a transparency on everything going on in our system, from the code to the server. It has brought huge cost savings and a better way of dealing with those costs and keeping them under control. And performance-wise, it has helped our team understand how we can make our code work better on the cloud native infrastructure."
+{{< /case-studies/quote >}}
+
+<p>Around the time Woorank was grappling with these issues, Kubernetes was emerging as a technology. De Moor knew that he wanted a platform that would be more automated and self-healing, and when he began experimenting with Kubernetes, he found that it checked all those boxes. "Kubernetes allows us to just define applications, how they need to run, how scalable they need to be, and it takes pain away from the developers thinking about that," he says. "When things fail and errors pop up, the system tries to heal itself, and that's really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It's made people's lives much easier. It's quite a big mindset change."</p>
+
+<p>Once one small Kubernetes cluster was up and running, the team began moving over a few applications at a time, gradually increasing the load over the course of several months. By early 2017, Woorank was 100% deployed on Kubernetes.</p>
+
+<p>The company's number one concern was immediately erased: Maintaining Kubernetes is the responsibility of just one person on staff, and it's not his fulltime job. Updating the old infrastructure "was always a pain," says De Moor: It used to take two active working days, "and it was always a bit scary when we did that." With Kubernetes, it's just a matter of "a few hours of passively following the process."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/woorank/banner4.jpg"
+  author="NILS DE MOOR, CTO/COFOUNDER, WOORANK"
+>}}
+"When things fail and errors pop up, the system tries to heal itself, and that's really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It's made people's lives much easier. It's quite a big mindset change."
+{{< /case-studies/quote >}}
+
+<p>Transparency on all levels, from the code to the servers, has also been a byproduct of the move to Kubernetes. "It's easier for the entire team to get a better understanding of the infrastructure, how it's working, how it looks like, what's going on," says De Moor. "It's not that thing that's running, and no one really knows how it works except this one person. Now it's really a team effort of everyone knowing, 'Okay, when something goes wrong, it's probably in this area or we need to check this.'"</p>
+
+<p>To that end, Woorank has begun implementing other cloud native tools that help with visibility, such as Fluentd for logging, Prometheus for monitoring, and OpenTracing for distributed tracing. Implementing these new tools—which once took weeks of planning, installing, and onboarding—now only takes a few days. "With all the tools and projects under the CNCF umbrella, it's easier for us to test and play with technology than it used to be," says De Moor. "With Prometheus, we used it fairly early and couldn't get it fairly stable. A couple of months ago, the question reappeared, so we set it up in two days, and now everyone is using it."</p>
+
+<p>Deployments, too, have been impacted: The rate has more than doubled, which De Moor partly attributes to the transparency of the new process. "With Kubernetes, you see that these three containers didn't start for this reason," he says. Plus, "now we bring deployment messages into Slack. If you see deployments rolling by every day, it does somehow indirectly enforce you, okay, I need to be part of this train, so I also need to deploy."</p>
+
+{{< case-studies/quote author="NILS DE MOOR, CTO/COFOUNDER, WOORANK" >}}
+"We can plan those things over a certain timeline, try to fit our resource usage to that, and then bring in spot instances, which will hopefully drive the costs down more."
+{{< /case-studies/quote >}}
+
+<p>Perhaps the biggest impact, though, has been on the bottom line. "We were already pretty flexible in our costs and taking on traffic peaks and higher load in general, but with Kubernetes and the other CNCF tools we use, we have achieved about 30% in cost savings," says De Moor.</p>
+
+<p>And there's room for even greater savings. Currently, most of Woorank's infrastructure is running on AWS on demand; the company pays a fixed price and makes some reservations for its planned amount of resources needed. De Moor is planning to experiment more with spot instances with certain resource-heavy workloads such as web crawls: "We can plan those things over a certain timeline, try to fit our resource usage to that, and then bring in spot instances, which will hopefully drive the costs down more."</p>
+
+<p>Moving to Kubernetes has been so beneficial to Woorank that the company is doubling down on both cloud native technologies and the community. "It was definitely important for us to have CNCF as an umbrella above everything," says De Moor. "We've always been working with open source libraries and tools and technologies. It works very well for us, but sometimes things can drift, maintainers drop out, and projects go haywire. For us, it was indeed important to know that whatever project gets taken under this umbrella, it's taken very seriously. Our way of contributing back is also by joining this community. It's, for us, a way to show our appreciation for what's going on in this framework."</p>
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html
index 1c09503bfb..d8945bfd34 100644
--- a/content/en/case-studies/workiva/index.html
+++ b/content/en/case-studies/workiva/index.html
@@ -3,111 +3,91 @@ title: Workiva Case Study
 linkTitle: Workiva
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 draft: true
 featured: true
 weight: 20
 quote: >
   With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/workiva/banner1.jpg
+heading_title_logo: /images/workiva_logo.png
+subheading: >
+  Using OpenTracing to Help Pinpoint the Bottlenecks
+case_study_details:
+  - Company: Workiva
+  - Location: Ames, Iowa
+  - Industry: Enterprise Software
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/workiva/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/workiva_logo.png" style="margin-bottom:0%" class="header_logo"><br> <div class="subhead">Using OpenTracing to Help Pinpoint the Bottlenecks
+<h2>Challenge</h2>
 
-</div></h1>
+<p><a href="https://www.workiva.com/">Workiva</a> offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company's first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva's existing system, Broad's team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn't impact overall speed.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Workiva</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Ames, Iowa</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Enterprise Software</b>
-</div>
+<p>Broad's team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    <a href="https://www.workiva.com/">Workiva</a> offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed.
-
-<br>
-
-</div>
-
-<div class="col2">
- <h2>Solution</h2>
-    Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.
-<br>
 <h2>Impact</h2>
-  Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
 
-</div>
+<p>Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-"With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MacLeod Broad, Senior Software Architect at Workiva</span>
+{{< case-studies/quote author="MacLeod Broad, Senior Software Architect at Workiva" >}}
+"With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Last fall, MacLeod Broad’s platform team at Workiva was prepping one of the company’s first products utilizing <a href="https://aws.amazon.com/">Amazon Web Services</a> when they ran into a roadblock.</h2>
-  Early on, Workiva’s backend had run mostly on <a href="https://cloud.google.com/appengine/">Google App Engine</a>. But things changed along the way as Workiva’s SaaS offering, <a href="https://www.workiva.com/wdesk">Wdesk</a>, a cloud-based platform for managing and reporting business data, grew its customer base to more than 70 percent of the Fortune 500 companies. "As customer needs grew and the product offering expanded, we started to leverage a wider offering of services such as Amazon Web Services as well as other Google Cloud Platform services, creating a multi-vendor environment."<br><br>
-With this new product, there was a "sync and link" feature by which data "went through a whole host of services starting with the new spreadsheet system [<a href="https://aws.amazon.com/rds/aurora/">Amazon Aurora</a>] into what we called our linking system, and then pushed through http to our existing system, and then a number of calculations would go on, and the results would be transmitted back into the new system," says Broad. "We were trying to optimize that for speed. We thought we had made this great optimization and then it would turn out to be a micro optimization, which didn’t really affect the overall speed of things." <br><br>
-The challenges faced by Broad’s team may sound familiar to other companies that have also made the shift from monoliths to more distributed, microservice-based systems. "We had a number of people working on this, all on different teams, so it was difficult to get our head around what the issues were and where the bottlenecks were," says Broad.<br><br>
- "Each service team was going through different iterations of their architecture and it was very hard to follow what was actually going on in each teams’ system," he adds. "We had circular dependencies where we’d have three or four different service teams unsure of where the issues really were, requiring a lot of back and forth communication. So we wasted a lot of time saying, ‘What part of this is slow? Which part of this is sometimes slow depending on the use case? Which part is degrading over time? Which part of this process is asynchronous so it doesn’t really matter if it’s long-running or not? What are we doing that’s redundant, and which part of this is buggy?’"
+{{< case-studies/lead >}}
+Last fall, MacLeod Broad's platform team at Workiva was prepping one of the company's first products utilizing <a href="https://aws.amazon.com/">Amazon Web Services</a> when they ran into a roadblock.
+{{< /case-studies/lead >}}
 
+<p>Early on, Workiva's backend had run mostly on <a href="https://cloud.google.com/appengine/">Google App Engine</a>. But things changed along the way as Workiva's SaaS offering, <a href="https://www.workiva.com/wdesk">Wdesk</a>, a cloud-based platform for managing and reporting business data, grew its customer base to more than 70 percent of the Fortune 500 companies. "As customer needs grew and the product offering expanded, we started to leverage a wider offering of services such as Amazon Web Services as well as other Google Cloud Platform services, creating a multi-vendor environment."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/workiva/banner3.jpg')">
-  <div class="banner3text">
-    "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>With this new product, there was a "sync and link" feature by which data "went through a whole host of services starting with the new spreadsheet system [<a href="https://aws.amazon.com/rds/aurora/">Amazon Aurora</a>] into what we called our linking system, and then pushed through http to our existing system, and then a number of calculations would go on, and the results would be transmitted back into the new system," says Broad. "We were trying to optimize that for speed. We thought we had made this great optimization and then it would turn out to be a micro optimization, which didn't really affect the overall speed of things."</p>
 
-Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."<br><br>
-With Workiva’s back-end code running on <a href="https://cloud.google.com/compute/">Google Compute Engine</a> as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."<br><br>
-Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"<br><br>
-Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it’s doing a SQL call or it’s making an RPC. And so it was really easy to say, ‘OK, we know that it’s going to page through all these requests. Do the work once and stuff it in cache.’ And we were done basically. All those calls became sub-second calls immediately."<br><br>
+<p>The challenges faced by Broad's team may sound familiar to other companies that have also made the shift from monoliths to more distributed, microservice-based systems. "We had a number of people working on this, all on different teams, so it was difficult to get our head around what the issues were and where the bottlenecks were," says Broad.</p>
 
+<p>"Each service team was going through different iterations of their architecture and it was very hard to follow what was actually going on in each teams' system," he adds. "We had circular dependencies where we'd have three or four different service teams unsure of where the issues really were, requiring a lot of back and forth communication. So we wasted a lot of time saying, 'What part of this is slow? Which part of this is sometimes slow depending on the use case? Which part is degrading over time? Which part of this process is asynchronous so it doesn't really matter if it's long-running or not? What are we doing that's redundant, and which part of this is buggy?'"</p>
 
+{{< case-studies/quote
+  image="/images/case-studies/workiva/banner3.jpg"
+  author="MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA"
+>}}
+"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it's a lot faster than never figuring out the problem and just moving on."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/workiva/banner4.jpg')">
-  <div class="banner4text">
-"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to&nbsp;use." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA</span>
-  </div>
-</div>
+<p>Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it's a lot faster than never figuring out the problem and just moving on."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  After the success of the first use case, everyone involved in the trial went back and fully instrumented their products. Tracing was added to a few more use cases. "We wanted to get through the initial implementation pains early without bringing the whole department along for the ride," says Broad. "Now, a lot of teams add it when they’re starting up a new service. We’re really pushing adoption now more than we were before." <br><br>
-Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." <br><br>
-Most of Workiva’s major products are now traced using OpenTracing, with data pushed into <a href="https://cloud.google.com/stackdriver/">Google StackDriver</a>. Even the products that aren’t fully traced have some components and libraries that are. <br><br>
-Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."<br><br>
-But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing."
-In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."
+<p>With Workiva's back-end code running on <a href="https://cloud.google.com/compute/">Google Compute Engine</a> as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn't want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."</p>
 
+<p>Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva's existing code that was slowing things down, that wasn't exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, 'Why is it doing all this work again?'"</p>
 
-</div>
+<p>Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it's doing a SQL call or it's making an RPC. And so it was really easy to say, 'OK, we know that it's going to page through all these requests. Do the work once and stuff it in cache.' And we were done basically. All those calls became sub-second calls immediately."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-   "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in&nbsp;a&nbsp;single&nbsp;fix." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— Michael Davis, Software Engineer, Workiva </span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/workiva/banner4.jpg"
+  author="MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA"
+>}}
+"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn't want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
- For Workiva, OpenTracing has become an essential tool for zeroing in on optimizations and determining what’s actually a micro-optimization by observing usage patterns. "On some projects we often assume what the customer is doing, and we optimize for these crazy scale cases that we hit 1 percent of the time," says Broad. "It’s been really helpful to be able to say, ‘OK, we’re adding 100 milliseconds on every request that does X, and we only need to add that 100 milliseconds if it’s the worst of the worst case, which only happens one out of a thousand requests or one out of a million requests."<br><br>
-Unlike many other companies, Workiva also traces the client side. "For us, the user experience is important—it doesn’t matter if the RPC takes 100 milliseconds if it still takes 5 seconds to do the rendering to show it in the browser," says Broad. "So for us, those client times are important. We trace it to see what parts of loading take a long time. We’re in the middle of working on a definition of what is ‘loaded.’ Is it when you have it, or when it’s rendered, or when you can interact with it? Those are things we’re planning to use tracing for to keep an eye on and to better understand."<br><br>
-That also requires adjusting for differences in external and internal clocks. "Before time correcting, it was horrible; our traces were more misleading than anything," says Broad. "So we decided that we would return a timestamp on the response headers, and then have the client reorient its time based on that—not change its internal clock but just calculate the offset on the response time to when the client got it. And if you end up in an impossible situation where a client RPC spans 210 milliseconds but the time on the response time is outside of that window, then we have to reorient that."<br><br>
-Broad is excited about the impact OpenTracing has already had on the company, and is also looking ahead to what else the technology can enable. One possibility is using tracing to update documentation in real time. "Keeping documentation up to date with reality is a big challenge," he says. "Say, we just ran a trace simulation or we just ran a smoke test on this new deploy, and the architecture doesn’t match the documentation. We can find whose responsibility it is and let them know and have them update it. That’s one of the places I’d like to get in the future with tracing."
+<p>After the success of the first use case, everyone involved in the trial went back and fully instrumented their products. Tracing was added to a few more use cases. "We wanted to get through the initial implementation pains early without bringing the whole department along for the ride," says Broad. "Now, a lot of teams add it when they're starting up a new service. We're really pushing adoption now more than we were before."</p>
 
-</div>
+<p>Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."</p>
 
-</section>
+<p>Most of Workiva's major products are now traced using OpenTracing, with data pushed into <a href="https://cloud.google.com/stackdriver/">Google StackDriver</a>. Even the products that aren't fully traced have some components and libraries that are.</p>
+
+<p>Broad points out that because some of the engineers were working on App Engine and already had experience with the platform's Appstats library for profiling performance, it didn't take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they're working on. Questions about passing the context around and how that's done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they'd used other systems that didn't require that."But the benefits clearly outweighed the concerns, and today, Workiva's official policy is to use tracing."</p>
+
+<p>In fact, Broad believes that tracing naturally fits in with Workiva's existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it's being created and when it's being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."</p>
+
+{{< case-studies/quote author="Michael Davis, Software Engineer, Workiva" >}}
+"Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
+{{< /case-studies/quote >}}
+
+<p>For Workiva, OpenTracing has become an essential tool for zeroing in on optimizations and determining what's actually a micro-optimization by observing usage patterns. "On some projects we often assume what the customer is doing, and we optimize for these crazy scale cases that we hit 1 percent of the time," says Broad. "It's been really helpful to be able to say, 'OK, we're adding 100 milliseconds on every request that does X, and we only need to add that 100 milliseconds if it's the worst of the worst case, which only happens one out of a thousand requests or one out of a million requests."</p>
+
+<p>Unlike many other companies, Workiva also traces the client side. "For us, the user experience is important—it doesn't matter if the RPC takes 100 milliseconds if it still takes 5 seconds to do the rendering to show it in the browser," says Broad. "So for us, those client times are important. We trace it to see what parts of loading take a long time. We're in the middle of working on a definition of what is 'loaded.' Is it when you have it, or when it's rendered, or when you can interact with it? Those are things we're planning to use tracing for to keep an eye on and to better understand."</p>
+
+<p>That also requires adjusting for differences in external and internal clocks. "Before time correcting, it was horrible; our traces were more misleading than anything," says Broad. "So we decided that we would return a timestamp on the response headers, and then have the client reorient its time based on that—not change its internal clock but just calculate the offset on the response time to when the client got it. And if you end up in an impossible situation where a client RPC spans 210 milliseconds but the time on the response time is outside of that window, then we have to reorient that."</p>
+
+<p>Broad is excited about the impact OpenTracing has already had on the company, and is also looking ahead to what else the technology can enable. One possibility is using tracing to update documentation in real time. "Keeping documentation up to date with reality is a big challenge," he says. "Say, we just ran a trace simulation or we just ran a smoke test on this new deploy, and the architecture doesn't match the documentation. We can find whose responsibility it is and let them know and have them update it. That's one of the places I'd like to get in the future with tracing."</p>
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html
index c07443249a..9afc1ec45b 100644
--- a/content/en/case-studies/ygrene/index.html
+++ b/content/en/case-studies/ygrene/index.html
@@ -1,111 +1,82 @@
 ---
 title: Ygrene Case Study
-
 linkTitle: Ygrene
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: ygrene_featured_logo.png
 featured: true
 weight: 48
 quote: >
-  We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company.
+  We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ygrene/banner1.jpg
+heading_title_logo: /images/ygrene_logo.png
+subheading: >
+  Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry
+case_study_details:
+  - Company: Ygrene
+  - Location: Petaluma, Calif.
+  - Industry: Clean energy financing
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/ygrene/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ygrene_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry
+<h2>Challenge</h2>
 
-</div></h1>
+<p>A PACE (Property Assessed Clean Energy) financing company, Ygrene has funded more than $1 billion in loans since 2010. In order to approve and process those loans, "We have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data," says Ygrene Development Manager Austin Adams. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically. We had a really unstable system that became overwhelmed with requests just for doing background data processing in real time. The performance the users saw was very poor. We needed a solution that wouldn't require us to make huge refactors to the code base." As a finance company, Ygrene also needed to ensure that they were shipping their applications securely.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Ygrene</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Petaluma, Calif.</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Clean energy financing</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    A PACE (Property Assessed Clean Energy) financing company, Ygrene has funded more than $1 billion in loans since 2010. In order to approve and process those loans, "We have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data," says Ygrene Development Manager Austin Adams. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically. We had a really unstable system that became overwhelmed with requests just for doing background data processing in real time. The performance the users saw was very poor. We needed a solution that wouldn’t require us to make huge refactors to the code base." As a finance company, Ygrene also needed to ensure that they were shipping their applications securely.
-
-<br>
-
- <h2>Solution</h2>
-    Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: <a href="https://kubernetes.io/">Kubernetes</a> to help scale out vertically and distribute workloads, <a href="https://github.com/theupdateframework/notary">Notary</a> to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and <a href="https://www.fluentd.org/">Fluentd</a> for "observing every part of our stack," all running on <a href="https://aws.amazon.com/ec2/spot/">Amazon EC2 Spot</a>.
-
-</div>
-
-<div class="col2">
+<p>Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: <a href="https://kubernetes.io/">Kubernetes</a> to help scale out vertically and distribute workloads, <a href="https://github.com/theupdateframework/notary">Notary</a> to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and <a href="https://www.fluentd.org/">Fluentd</a> for "observing every part of our stack," all running on <a href="https://aws.amazon.com/ec2/spot/">Amazon EC2 Spot</a>.</p>
 
 <h2>Impact</h2>
-  Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on."
 
+<p>Before, deployments typically took three to four hours, and two or three months' worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we're able to deploy three or four times a week, with just one week's or two days' worth of work," Adams says. "We're deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we're adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn't tell our investors and team members that we knew what was going on."</p>
 
-</div>
+{{< case-studies/quote author="Austin Adams, Development Manager, Ygrene Energy Fund" >}}
+"CNCF projects are helping Ygrene determine the security and observability standards for the entire PACE industry. We're an emerging finance industry, and without these projects, especially Kubernetes, we couldn't be the industry leader that we are today."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-"CNCF projects are helping Ygrene determine the security and observability standards for the entire PACE industry. We’re an emerging finance industry, and without these projects, especially Kubernetes, we couldn’t be the industry leader that we are today." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Austin Adams, Development Manager, Ygrene Energy Fund</span>
+{{< case-studies/lead >}}
+In less than a decade, <a href="https://ygrene.com/">Ygrene</a> has funded more than $1 billion in loans for renewable energy projects.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
+<p>A <a href="https://www.energy.gov/eere/slsc/property-assessed-clean-energy-programs">PACE</a> (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams.</p>
 
-<div class="fullcol">
- <h2>In less than a decade, <a href="https://ygrene.com/" style="text-decoration:underline">Ygrene</a> has funded more than $1 billion in loans for renewable energy&nbsp;projects.</h2> A <a href="https://www.energy.gov/eere/slsc/property-assessed-clean-energy-programs">PACE</a> (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams. <br><br>
-In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time." <br><br>
-By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn’t solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn’t handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."
+<p>In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ygrene/banner3.jpg')">
-  <div class="banner3text">
-    "CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Austin Adams, Development Manager, Ygrene Energy Fund</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn't solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn't handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."</p>
 
-Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn’t require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams. <br><br>
-With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."<br><br>
-How? Cloud native has "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on." <br><br>
-Notary, in particular, "has been a godsend," says Adams. "We need to know that our attack surface on third-party dependencies is low, or at least managed. We use it as a trust system and we also use it as a separation, so production images are signed by Notary, but some development images we don’t sign. That is to ensure that they can’t get into the production cluster. We’ve been using it in the test cluster to feel more secure about our builds."
+{{< case-studies/quote
+  image="/images/case-studies/ygrene/banner3.jpg"
+  author="Austin Adams, Development Manager, Ygrene Energy Fund"
+>}}
+"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It's actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
+{{< /case-studies/quote >}}
 
+<p>Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn't require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams.</p>
 
+<p>With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ygrene/banner4.jpg')">
-  <div class="banner4text">
-"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."</span>
-  </div>
-</div>
+<p>How? Cloud native has "changed the game for scalability, observability, and security—we're adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn't tell our investors and team members that we knew what was going on."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
- By using the kops project, Ygrene was able to move from Elastic Beanstalk to running its Kubernetes clusters on AWS EC2 Spot, at a tenth of the previous cost. "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."<br><br>
-That also helped them mitigate the risk that comes with running in the public cloud. "We figured out, essentially, that if we’re able to select instance classes using EC2 Spot that had an extremely low likelihood of interruption and zero history of interruption, and we’re willing to pay a price high enough, that we could virtually get the same guarantee using Kubernetes because we have enough nodes," says Software Engineer Zach Arnold, who led the migration to Kubernetes. "Now that we’ve re-architected these pieces of the application to not live on the same server, we can push out to many different servers and have a more stable deployment."<br><br>
-As a result, the team can now ship code any time of day. "That was risky because it could bring down your whole loan management software with it," says Arnold. "But we now can deploy safely and securely during the day."
+<p>Notary, in particular, "has been a godsend," says Adams. "We need to know that our attack surface on third-party dependencies is low, or at least managed. We use it as a trust system and we also use it as a separation, so production images are signed by Notary, but some development images we don't sign. That is to ensure that they can't get into the production cluster. We've been using it in the test cluster to feel more secure about our builds."</p>
 
+{{< case-studies/quote image="/images/case-studies/ygrene/banner4.jpg">}}
+"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company."
+{{< /case-studies/quote >}}
 
-</div>
+<p>By using the kops project, Ygrene was able to move from Elastic Beanstalk to running its Kubernetes clusters on AWS EC2 Spot, at a tenth of the previous cost. "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."</p>
 
-<div class="banner5">
-  <div class="banner5text">
- "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."</span>
-  </div>
-</div>
+<p>That also helped them mitigate the risk that comes with running in the public cloud. "We figured out, essentially, that if we're able to select instance classes using EC2 Spot that had an extremely low likelihood of interruption and zero history of interruption, and we're willing to pay a price high enough, that we could virtually get the same guarantee using Kubernetes because we have enough nodes," says Software Engineer Zach Arnold, who led the migration to Kubernetes. "Now that we've re-architected these pieces of the application to not live on the same server, we can push out to many different servers and have a more stable deployment."</p>
 
-<div class="fullcol">
- Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for an overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down for 30 minutes to an hour, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed."<br><br>
-Cloud native also affected how Ygrene’s 50+ developers and contractors work. Adams and Arnold spent considerable time "teaching people to think distributed out of the box," says Arnold. "We ended up picking what we call the Four S’s of Shipping: safely, securely, stably, and speedily." (For more on the security piece of it, see their <a href="https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/">article</a> on their "continuous hacking" strategy.) As for the engineers, says Adams, "they have been able to advance as their software has advanced. I think that at the end of the day, the developers feel better about what they’re doing, and they also feel more connected to the modern software development community."<br><br>
-Looking ahead, Adams is excited to explore more CNCF projects, including SPIFFE and SPIRE. "CNCF has been an amazing incubator for so many projects," he says. "Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
+<p>As a result, the team can now ship code any time of day. "That was risky because it could bring down your whole loan management software with it," says Arnold. "But we now can deploy safely and securely during the day."</p>
 
+{{< case-studies/quote >}}
+"In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."
+{{< /case-studies/quote >}}
 
+<p>Before, deployments typically took three to four hours, and two or three months' worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for an overall deploy with smoke testing. And "we're able to deploy three or four times a week, with just one week's or two days' worth of work," Adams says. "We're deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down for 30 minutes to an hour, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed."</p>
 
-</div>
+<p>Cloud native also affected how Ygrene's 50+ developers and contractors work. Adams and Arnold spent considerable time "teaching people to think distributed out of the box," says Arnold. "We ended up picking what we call the Four S's of Shipping: safely, securely, stably, and speedily." (For more on the security piece of it, see their <a href="https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/">article</a> on their "continuous hacking" strategy.) As for the engineers, says Adams, "they have been able to advance as their software has advanced. I think that at the end of the day, the developers feel better about what they're doing, and they also feel more connected to the modern software development community."</p>
 
-</section>
+<p>Looking ahead, Adams is excited to explore more CNCF projects, including SPIFFE and SPIRE. "CNCF has been an amazing incubator for so many projects," he says. "Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It's actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."</p>
diff --git a/content/en/case-studies/zalando/index.html b/content/en/case-studies/zalando/index.html
index 49bad6ff9e..23363da401 100644
--- a/content/en/case-studies/zalando/index.html
+++ b/content/en/case-studies/zalando/index.html
@@ -1,101 +1,83 @@
 ---
 title: Zalando Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_zalando.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/zalando/banner1.jpg
+heading_title_logo: /images/zalando_logo.png
+subheading: >
+  Europe's Leading Online Fashion Platform Gets Radical with Cloud Native
+case_study_details:
+  - Company: Zalando
+  - Location: Berlin, Germany
+  - Industry: Online Fashion
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/zalando_logo.png" class="header_logo"><br> <div class="subhead">Europe’s Leading Online Fashion Platform Gets Radical with Cloud Native
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>Zalando, Europe's leading online fashion platform, has experienced exponential growth since it was founded in 2008. In 2015, with plans to further expand its original e-commerce site to include new services and products, Zalando embarked on a <a href="https://jobs.zalando.com/tech/blog/radical-agility-study-notes/">radical transformation</a> resulting in autonomous self-organizing teams. This change requires an infrastructure that could scale with the growth of the engineering organization. Zalando's technology department began rewriting its applications to be cloud-ready and started moving its infrastructure from on-premise data centers to the cloud. While orchestration wasn't immediately considered, as teams migrated to <a href="https://aws.amazon.com/">Amazon Web Services</a> (AWS): "We saw the pain teams were having with infrastructure and Cloud Formation on AWS," says Henning Jacobs, Head of Developer Productivity. "There's still too much operational overhead for the teams and compliance. " To provide better support, cluster management was brought into play.</p>
 
-<div class="details">
-    Company &nbsp;<b>Zalando</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Berlin, Germany</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Online Fashion</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    Zalando, Europe’s leading online fashion platform, has experienced exponential growth since it was founded in 2008. In 2015, with plans to further expand its original e-commerce site to include new services and products, Zalando embarked on a <a href="https://jobs.zalando.com/tech/blog/radical-agility-study-notes/">radical transformation</a> resulting in autonomous self-organizing teams. This change requires an infrastructure that could scale with the growth of the engineering organization. Zalando’s technology department began rewriting its applications to be cloud-ready and started moving its infrastructure from on-premise data centers to the cloud. While orchestration wasn’t immediately considered, as teams migrated to <a href="https://aws.amazon.com/">Amazon Web Services</a> (AWS): "We saw the pain teams were having with infrastructure and Cloud Formation on AWS," says Henning Jacobs, Head of Developer Productivity. "There’s still too much operational overhead for the teams and compliance. " To provide better support, cluster management was brought into play.
+<p>The company now runs its Docker containers on AWS using Kubernetes orchestration.</p>
 
-      </div>
-
-<div class="col2">
-  <h2>Solution</h2>
-      The company now runs its Docker containers on AWS using Kubernetes orchestration.
-<br>
 <h2>Impact</h2>
-      With the old infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs on the Linux kernel. This makes a lot of people pretty happy. The engineers love autonomy."
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We envision all Zalando delivery teams running their containerized applications on a state-of-the-art, reliable and scalable cluster infrastructure provided by Kubernetes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Henning Jacobs, Head of Developer Productivity at Zalando</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-    <h2>When Henning Jacobs arrived at Zalando in 2010, the company was just two years old with 180 employees running an online store for European shoppers to buy fashion items.</h2>
-    "It started as a PHP e-commerce site which was easy to get started with, but was not scaling with the business' needs" says Jacobs, Head of Developer Productivity at Zalando.<br><br>
-    At that time, the company began expanding beyond its German origins into other European markets. Fast-forward to today and Zalando now has more than 14,000 employees, 3.6 billion Euro in revenue for 2016 and operates across 15 countries. "With growth in all dimensions, and constant scaling, it has been a once-in-a-lifetime experience," he says.<br><br>
-    Not to mention a unique opportunity for an infrastructure specialist like Jacobs. Just after he joined, the company began rewriting all their applications in-house. "That was generally our strategy," he says. "For example, we started with our own logistics warehouses but at first you don’t know how to do logistics software, so you have some vendor software. And then we replaced it with our own because with off-the-shelf software you’re not competitive. You need to optimize these processes based on your specific business needs."<br><br>
-    In parallel to rewriting their applications, Zalando had set a goal of expanding beyond basic e-commerce to a platform offering multi-tenancy, a dramatic increase in assortments and styles, same-day delivery and even <a href="https://www.zalon.de">your own personal online stylist</a>.<br><br>
-    The need to scale ultimately led the company on a cloud-native journey. As did its embrace of a microservices-based software architecture that gives engineering teams more autonomy and ownership of projects. "This move to the cloud was necessary because in the data center you couldn’t have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app," Jacobs says.
 
-</div>
-</section>
-<div class="banner3">
-  <div class="banner3text">
-    "This move to the cloud was necessary because in the data center you couldn’t have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app."
+<p>With the old infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs on the Linux kernel. This makes a lot of people pretty happy. The engineers love autonomy."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Zalando began moving its infrastructure from two on-premise data centers to the cloud, requiring the migration of older applications for cloud-readiness. "We decided to have a clean break," says Jacobs. "Our <a href="https://aws.amazon.com/">Amazon Web Services</a> infrastructure was set up like so: Every team has its own AWS account, which is completely isolated, meaning there’s no ‘lift and shift.’ You basically have to rewrite your application to make it cloud-ready even down to the persistence layer. We bravely went back to the drawing board and redid everything, first choosing Docker as a common containerization, then building the infrastructure from there."<br><br>
-  The company decided to hold off on orchestration at the beginning, but as teams were migrated to AWS, "we saw the pain teams were having with infrastructure and cloud formation on AWS," says Jacobs. <br><br>
-  Zalandos 200+ autonomous engineering teams decide what technologies to use and could operate their own applications using their own AWS accounts. This setup proved to be a compliance challenge. Even with strict rules-of-play and automated compliance checks in place, engineering teams and IT-compliance were overburdened addressing compliance issues. "Violations appear for non-compliant behavior, which we detect when scanning the cloud infrastructure," says Jacobs. "Everything is possible and nothing enforced, so you have to live with violations (and resolve them) instead of preventing the error in the first place. This means overhead for teams—and overhead for compliance and operations. It also takes time to spin up new EC2 instances on AWS, which affects our deployment velocity." <br><br>
-  The team realized they needed to "leverage the value you get from cluster management," says Jacobs. When they first looked at Platform as a Service (PaaS) options in 2015, the market was fragmented; but "now there seems to be a clear winner. It seemed like a good bet to go with Kubernetes."<br><br>
-  The transition to Kubernetes started in 2016 during Zalando’s <a href="https://jobs.zalando.com/tech/blog/hack-week-5-is-live/?gh_src=4n3gxh1">Hack Week</a> where participants deployed their projects to a Kubernetes cluster. From there 60 members of the tech infrastructure department were on-boarded - and then engineering teams were brought on one at a time. "We always start by talking with them and make sure everyone’s expectations are clear," says Jacobs. "Then we conduct some Kubernetes training, which is mostly training for our CI/CD setup, because the user interface for our users is primarily through the CI/CD system. But they have to know fundamental Kubernetes concepts and the API. This is followed by a weekly sync with each team to check their progress. Once they have something in production, we want to see if everything is fine on top of what we can improve."
+{{< case-studies/quote author="Henning Jacobs, Head of Developer Productivity at Zalando" >}}
+"We envision all Zalando delivery teams running their containerized applications on a state-of-the-art, reliable and scalable cluster infrastructure provided by Kubernetes."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4">
-  <div class="banner4text">
-  Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs.
-  </div>
-</div>
+{{< case-studies/lead >}}
+When Henning Jacobs arrived at Zalando in 2010, the company was just two years old with 180 employees running an online store for European shoppers to buy fashion items.
+{{< /case-studies/lead >}}
 
-<section class="section4">
-<div class="fullcol">
-  At the moment, Zalando is running an initial 40 Kubernetes clusters with plans to scale for the foreseeable future.
-  Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs. "The self-healing infrastructure provides a frictionless experience with higher-level abstractions built upon low-level best practices. We envision all Zalando delivery teams will run their containerized applications on a state-of-the-art reliable and scalable cluster infrastructure provided by Kubernetes."<br><br>
-  With the old on-premise infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs in the Linux kernel. This makes a lot of people pretty happy. The engineers love the autonomy."
-  There were a few challenges in Zalando’s Kubernetes implementation. "We are a team of seven people providing clusters to different engineering teams, and our goal is to provide a rock-solid experience for all of them," says Jacobs. "We don’t want pet clusters. We don’t want to have to understand what workload they have; it should just work out of the box. With that in mind, cluster autoscaling is important. There are many different ways of doing cluster management, and this is not part of the core. So we created two components to provision clusters, have a registry for clusters, and to manage the whole cluster life cycle."<br><br>
-  Jacobs’s team also worked to improve the Kubernetes-AWS integration. "Thus you're very restricted. You need infrastructure to scale each autonomous team’s idea.""<br><br>
-  Plus, "there are still a lot of best practices missing," says Jacobs. The team, for example, recently solved a pod security policy issue. "There was already a concept in Kubernetes but it wasn’t documented, so it was kind of tricky," he says. The large Kubernetes community was a big help to resolve the issue. To help other companies start down the same path, Jacobs compiled his team’s learnings in a document called <a href="http://kubernetes-on-aws.readthedocs.io/en/latest/admin-guide/kubernetes-in-production.html">Running Kubernetes in Production</a>.
+<p>"It started as a PHP e-commerce site which was easy to get started with, but was not scaling with the business' needs" says Jacobs, Head of Developer Productivity at Zalando.</p>
 
-</div>
-</section>
+<p>At that time, the company began expanding beyond its German origins into other European markets. Fast-forward to today and Zalando now has more than 14,000 employees, 3.6 billion Euro in revenue for 2016 and operates across 15 countries. "With growth in all dimensions, and constant scaling, it has been a once-in-a-lifetime experience," he says.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years... We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."
-  </div>
-</div>
-<section class="section5">
-<div class="fullcol">
-  In the end, Kubernetes made it possible for Zalando to introduce and maintain the new products the company envisioned to grow its platform. "<a href="https://www.zalon.de/">The fashion advice</a> product used Scala, and there were struggles to make this possible with our former infrastructure," says Jacobs. "It was a workaround, and that team needed more and more support from the platform team, just because they used different technologies. Now with Kubernetes, it’s autonomous. Whatever the workload is, that team can just go their way, and Kubernetes prevents other bottlenecks."<br><br>
-  Looking ahead, Jacobs sees Zalando’s new infrastructure as a great enabler for other things the company has in the works, from its new logistics software, to a platform feature connecting brands, to products dreamed up by data scientists. "One vision is if you watch the next James Bond movie and see the suit he’s wearing, you should be able to automatically order it, and have it delivered to you within an hour," says Jacobs. "It’s about connecting the full fashion sphere. This is definitely not possible if you have a bottleneck with everyone running in the same data center and thus very restricted. You need infrastructure to scale each autonomous team’s idea."<br><br>
-  For other companies considering this technology, Jacobs says he wouldn’t necessarily advise doing it exactly the same way Zalando did. "It’s okay to do so if you’re ready to fail at some things," he says. "You need to set the right expectations. Not everything will work. Rewriting apps and this type of organizational change can be disruptive. The first product we moved was critical. There were a lot of dependencies, and it took longer than expected. Maybe we should have started with something less complicated, less business critical, just to get our toes wet."<br><br>
-  But once they got to the other side "it was clear for everyone that there’s no big alternative," Jacobs adds. "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years. Zalando Technology benefits from migrating to Kubernetes as we are able to leverage our existing knowledge to create an engineering platform offering flexibility and speed to our engineers while significantly reducing the operational overhead. We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."
+<p>Not to mention a unique opportunity for an infrastructure specialist like Jacobs. Just after he joined, the company began rewriting all their applications in-house. "That was generally our strategy," he says. "For example, we started with our own logistics warehouses but at first you don't know how to do logistics software, so you have some vendor software. And then we replaced it with our own because with off-the-shelf software you're not competitive. You need to optimize these processes based on your specific business needs."</p>
 
-</div>
+<p>In parallel to rewriting their applications, Zalando had set a goal of expanding beyond basic e-commerce to a platform offering multi-tenancy, a dramatic increase in assortments and styles, same-day delivery and even <a href="https://www.zalon.de">your own personal online stylist</a>.</p>
 
-</section>
+<p>The need to scale ultimately led the company on a cloud-native journey. As did its embrace of a microservices-based software architecture that gives engineering teams more autonomy and ownership of projects. "This move to the cloud was necessary because in the data center you couldn't have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app," Jacobs says.</p>
+
+{{< case-studies/quote image="/images/case-studies/zalando/banner3.jpg" >}}
+"This move to the cloud was necessary because in the data center you couldn't have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app."
+{{< /case-studies/quote >}}
+
+<p>Zalando began moving its infrastructure from two on-premise data centers to the cloud, requiring the migration of older applications for cloud-readiness. "We decided to have a clean break," says Jacobs. "Our <a href="https://aws.amazon.com/">Amazon Web Services</a> infrastructure was set up like so: Every team has its own AWS account, which is completely isolated, meaning there's no 'lift and shift.' You basically have to rewrite your application to make it cloud-ready even down to the persistence layer. We bravely went back to the drawing board and redid everything, first choosing Docker as a common containerization, then building the infrastructure from there."</p>
+
+<p>The company decided to hold off on orchestration at the beginning, but as teams were migrated to AWS, "we saw the pain teams were having with infrastructure and cloud formation on AWS," says Jacobs.</p>
+
+<p>Zalandos 200+ autonomous engineering teams decide what technologies to use and could operate their own applications using their own AWS accounts. This setup proved to be a compliance challenge. Even with strict rules-of-play and automated compliance checks in place, engineering teams and IT-compliance were overburdened addressing compliance issues. "Violations appear for non-compliant behavior, which we detect when scanning the cloud infrastructure," says Jacobs. "Everything is possible and nothing enforced, so you have to live with violations (and resolve them) instead of preventing the error in the first place. This means overhead for teams—and overhead for compliance and operations. It also takes time to spin up new EC2 instances on AWS, which affects our deployment velocity."</p>
+
+<p>The team realized they needed to "leverage the value you get from cluster management," says Jacobs. When they first looked at Platform as a Service (PaaS) options in 2015, the market was fragmented; but "now there seems to be a clear winner. It seemed like a good bet to go with Kubernetes."</p>
+
+<p>The transition to Kubernetes started in 2016 during Zalando's <a href="https://jobs.zalando.com/tech/blog/hack-week-5-is-live/?gh_src=4n3gxh1">Hack Week</a> where participants deployed their projects to a Kubernetes cluster. From there 60 members of the tech infrastructure department were on-boarded - and then engineering teams were brought on one at a time. "We always start by talking with them and make sure everyone's expectations are clear," says Jacobs. "Then we conduct some Kubernetes training, which is mostly training for our CI/CD setup, because the user interface for our users is primarily through the CI/CD system. But they have to know fundamental Kubernetes concepts and the API. This is followed by a weekly sync with each team to check their progress. Once they have something in production, we want to see if everything is fine on top of what we can improve."</p>
+
+{{< case-studies/quote image="/images/case-studies/zalando/banner4.jpg" >}}
+Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs.
+{{< /case-studies/quote >}}
+
+<p>At the moment, Zalando is running an initial 40 Kubernetes clusters with plans to scale for the foreseeable future. Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs. "The self-healing infrastructure provides a frictionless experience with higher-level abstractions built upon low-level best practices. We envision all Zalando delivery teams will run their containerized applications on a state-of-the-art reliable and scalable cluster infrastructure provided by Kubernetes."</p>
+
+<p>With the old on-premise infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs in the Linux kernel. This makes a lot of people pretty happy. The engineers love the autonomy."</p>
+
+<p>There were a few challenges in Zalando's Kubernetes implementation. "We are a team of seven people providing clusters to different engineering teams, and our goal is to provide a rock-solid experience for all of them," says Jacobs. "We don't want pet clusters. We don't want to have to understand what workload they have; it should just work out of the box. With that in mind, cluster autoscaling is important. There are many different ways of doing cluster management, and this is not part of the core. So we created two components to provision clusters, have a registry for clusters, and to manage the whole cluster life cycle."</p>
+
+<p>Jacobs's team also worked to improve the Kubernetes-AWS integration. "Thus you're very restricted. You need infrastructure to scale each autonomous team's idea." Plus, "there are still a lot of best practices missing," says Jacobs. The team, for example, recently solved a pod security policy issue. "There was already a concept in Kubernetes but it wasn't documented, so it was kind of tricky," he says. The large Kubernetes community was a big help to resolve the issue. To help other companies start down the same path, Jacobs compiled his team's learnings in a document called <a href="http://kubernetes-on-aws.readthedocs.io/en/latest/admin-guide/kubernetes-in-production.html">Running Kubernetes in Production</a>.</p>
+
+{{< case-studies/quote >}}
+"The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years... We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."
+{{< /case-studies/quote >}}
+
+<p>In the end, Kubernetes made it possible for Zalando to introduce and maintain the new products the company envisioned to grow its platform. "<a href="https://www.zalon.de/">The fashion advice</a> product used Scala, and there were struggles to make this possible with our former infrastructure," says Jacobs. "It was a workaround, and that team needed more and more support from the platform team, just because they used different technologies. Now with Kubernetes, it's autonomous. Whatever the workload is, that team can just go their way, and Kubernetes prevents other bottlenecks."</p>
+
+<p>Looking ahead, Jacobs sees Zalando's new infrastructure as a great enabler for other things the company has in the works, from its new logistics software, to a platform feature connecting brands, to products dreamed up by data scientists. "One vision is if you watch the next James Bond movie and see the suit he's wearing, you should be able to automatically order it, and have it delivered to you within an hour," says Jacobs. "It's about connecting the full fashion sphere. This is definitely not possible if you have a bottleneck with everyone running in the same data center and thus very restricted. You need infrastructure to scale each autonomous team's idea."</p>
+
+<p>For other companies considering this technology, Jacobs says he wouldn't necessarily advise doing it exactly the same way Zalando did. "It's okay to do so if you're ready to fail at some things," he says. "You need to set the right expectations. Not everything will work. Rewriting apps and this type of organizational change can be disruptive. The first product we moved was critical. There were a lot of dependencies, and it took longer than expected. Maybe we should have started with something less complicated, less business critical, just to get our toes wet."</p>
+
+<p>But once they got to the other side "it was clear for everyone that there's no big alternative," Jacobs adds. "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years. Zalando Technology benefits from migrating to Kubernetes as we are able to leverage our existing knowledge to create an engineering platform offering flexibility and speed to our engineers while significantly reducing the operational overhead. We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."</p>
diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
index e06ebf76a5..dc42c2d158 100644
--- a/content/en/docs/_index.md
+++ b/content/en/docs/_index.md
@@ -1,4 +1,6 @@
 ---
 linktitle: Kubernetes Documentation
 title: Documentation
+sitemap:
+  priority: 1.0
 ---
diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md
index 9a731b684a..d97fc94a4c 100644
--- a/content/en/docs/concepts/architecture/cloud-controller.md
+++ b/content/en/docs/concepts/architecture/cloud-controller.md
@@ -23,7 +23,7 @@ mechanism that allows different cloud providers to integrate their platforms wit
 
 ## Design
 
-![Kubernetes components](/images/docs/components-of-kubernetes.png)
+![Kubernetes components](/images/docs/components-of-kubernetes.svg)
 
 The cloud controller manager runs in the control plane as a replicated set of processes
 (usually, these are containers in Pods). Each cloud-controller-manager implements
diff --git a/content/en/docs/concepts/architecture/control-plane-node-communication.md b/content/en/docs/concepts/architecture/control-plane-node-communication.md
index 8040213495..2e7235a89f 100644
--- a/content/en/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/en/docs/concepts/architecture/control-plane-node-communication.md
@@ -21,7 +21,7 @@ This document catalogs the communication paths between the control plane (really
 Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
 One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed.
 
-Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
+Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
 
 Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated.
 The `kubernetes` service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.
@@ -49,7 +49,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to pro
 If that is not possible, use [SSH tunneling](#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an
 untrusted or public network.
 
-Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
+Finally, [Kubelet authentication and/or authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
 
 ### apiserver to nodes, pods, and services
 
diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md
index 2705cdfcb7..d6897d2978 100644
--- a/content/en/docs/concepts/architecture/controller.md
+++ b/content/en/docs/concepts/architecture/controller.md
@@ -92,9 +92,18 @@ Controllers that interact with external state find their desired state from
 the API server, then communicate directly with an external system to bring
 the current state closer in line.
 
-(There actually is a controller that horizontally scales the
-nodes in your cluster. See
-[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)).
+(There actually is a [controller](https://github.com/kubernetes/autoscaler/)
+that horizontally scales the nodes in your cluster.)
+
+The important point here is that the controller makes some change to bring about
+your desired state, and then reports current state back to your cluster's API server.
+Other control loops can observe that reported data and take their own actions.
+
+In the thermostat example, if the room is very cold then a different controller
+might also turn on a frost protection heater. With Kubernetes clusters, the control
+plane indirectly works with IP address management tools, storage services,
+cloud provider APIS, and other services by
+[extending Kubernetes](/docs/concepts/extend-kubernetes/) to implement that.
 
 ## Desired versus current state {#desired-vs-current}
 
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index b1e1f0dc24..337b2107fb 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -261,7 +261,7 @@ a Lease object.
 
 #### Reliability
 
- In most cases, node controller limits the eviction rate to
+ In most cases, the node controller limits the eviction rate to
 `--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
 from more than 1 node per 10 seconds.
 
@@ -338,5 +338,4 @@ for more information.
 * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
   section of the architecture design document.
 * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
-* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
 
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
index e35c8e0ebc..14b8165ebf 100644
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -39,8 +39,6 @@ Before choosing a guide, here are some considerations:
 
 ## Managing a cluster
 
-* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster's master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
-
 * Learn how to [manage nodes](/docs/concepts/architecture/nodes/).
 
 * Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
@@ -51,7 +49,7 @@ Before choosing a guide, here are some considerations:
 
 * [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
 
-* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes how Kubernetes implements access control for its own API.
 
 * [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
 
diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md
index 05a65a1efc..8a356a826a 100644
--- a/content/en/docs/concepts/cluster-administration/addons.md
+++ b/content/en/docs/concepts/cluster-administration/addons.md
@@ -5,12 +5,12 @@ content_type: concept
 
 <!-- overview -->
 
+{{% thirdparty-content %}}
+
 Add-ons extend the functionality of Kubernetes.
 
 This page lists some of the available add-ons and links to their respective installation instructions.
 
-Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.
-
 <!-- body -->
 
 ## Networking and Network Policy
@@ -25,6 +25,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
 * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md
deleted file mode 100644
index 89bd0be3f6..0000000000
--- a/content/en/docs/concepts/cluster-administration/cloud-providers.md
+++ /dev/null
@@ -1,362 +0,0 @@
----
-title: Cloud Providers
-content_type: concept
-weight: 30
----
-
-<!-- overview -->
-This page explains how to manage Kubernetes running on a specific
-cloud provider. There are many other third-party cloud provider projects, but this list is specific to projects embedded within, or relied upon by Kubernetes itself.
-
-<!-- body -->
-### kubeadm
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters.
-kubeadm has configuration options to specify configuration information for cloud providers. For example a typical
-in-tree cloud provider can be configured using kubeadm as shown below:
-
-```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: InitConfiguration
-nodeRegistration:
-  kubeletExtraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
----
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
-apiServer:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-controllerManager:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-```
-
-The in-tree cloud providers typically need both `--cloud-provider` and `--cloud-config` specified in the command lines
-for the [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
-[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) and the
-[kubelet](/docs/reference/command-line-tools-reference/kubelet/).
-The contents of the file specified in `--cloud-config` for each provider is documented below as well.
-
-For all external cloud providers, please follow the instructions on the individual repositories,
-which are listed under their headings below, or one may view [the list of all repositories](https://github.com/kubernetes?q=cloud-provider-&type=&language=)
-
-## AWS
-This section describes all the possible configurations which can
-be used when running Kubernetes on Amazon Web Services.
-
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)
-
-### Node Name
-
-The AWS cloud provider uses the private DNS name of the AWS instance as the name of the Kubernetes Node object.
-
-### Load Balancers
-You can setup [external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/)
-to use specific features in AWS by configuring the annotations as shown below.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: example
-  namespace: kube-system
-  labels:
-    run: example
-  annotations:
-     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
-     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
-spec:
-  type: LoadBalancer
-  ports:
-  - port: 443
-    targetPort: 5556
-    protocol: TCP
-  selector:
-    app: example
-```
-Different settings can be applied to a load balancer service in AWS using _annotations_. The following describes the annotations supported on AWS ELBs:
-
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: Used to specify access log emit interval.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: Used on the service to enable or disable access logs.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: Used to specify access log s3 bucket name.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix.
-* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`.
-* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
-* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services.
-* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
-* `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: Used on the service to specify a comma-separated list of ports that will use SSL/HTTPS listeners. Defaults to `*` (all)
-
-The information for the annotations for AWS is taken from the comments on [aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)
-
-## Azure
-
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)
-
-### Node Name
-
-The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Azure VM name.
-
-## GCE
-
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
-
-### Node Name
-
-The GCE cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the first segment of the Kubernetes Node name must match the GCE instance name (e.g. a Node named `kubernetes-node-2.c.my-proj.internal` must correspond to an instance named `kubernetes-node-2`).
-
-## HUAWEI CLOUD
-
-If you wish to use the external cloud provider, its repository is [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud).
-
-## OpenStack
-This section describes all the possible configurations which can
-be used when using OpenStack with Kubernetes.
-
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)
-
-### Node Name
-
-The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object.
-Note that the instance name must be a valid Kubernetes Node name in order for the kubelet to successfully register its Node object.
-
-### Services
-
-The OpenStack cloud provider
-implementation for Kubernetes supports the use of these OpenStack services from
-the underlying cloud, where available:
-
-| Service                  | API Version(s) | Required |
-|--------------------------|----------------|----------|
-| Block Storage (Cinder)   | V1†, V2, V3    | No       |
-| Compute (Nova)           | V2             | No       |
-| Identity (Keystone)      | V2‡,  V3       | Yes      |
-| Load Balancing (Neutron) | V1§, V2        | No       |
-| Load Balancing (Octavia) | V2             | No       |
-
-† Block Storage V1 API support is deprecated, Block Storage V3 API support was
-added in Kubernetes 1.9.
-
-‡ Identity V2 API support is deprecated and will be removed from the provider in
-a future release. As of the "Queens" release, OpenStack will no longer expose the
-Identity V2 API.
-
-§ Load Balancing V1 API support was removed in Kubernetes 1.9.
-
-Service discovery is achieved by listing the service catalog managed by
-OpenStack Identity (Keystone) using the `auth-url` provided in the provider
-configuration. The provider will gracefully degrade in functionality when
-OpenStack services other than Keystone are not available and simply disclaim
-support for impacted features. Certain features are also enabled or disabled
-based on the list of extensions published by Neutron in the underlying cloud.
-
-### cloud.conf
-Kubernetes knows how to interact with OpenStack via the file cloud.conf. It is
-the file that will provide Kubernetes with credentials and location for the OpenStack auth endpoint.
-You can create a cloud.conf file by specifying the following details in it
-
-#### Typical configuration
-This is an example of a typical configuration that touches the values that most
-often need to be set. It points the provider at the OpenStack cloud's Keystone
-endpoint, provides details for how to authenticate with it, and configures the
-load balancer:
-
-```yaml
-[Global]
-username=user
-password=pass
-auth-url=https://<keystone_ip>/identity/v3
-tenant-id=c869168a828847f39f7f06edd7305637
-domain-id=2a73b8f597c04551a0fdc8e95544be8a
-
-[LoadBalancer]
-subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
-```
-
-##### Global
-These configuration options for the OpenStack provider pertain to its global
-configuration and should appear in the `[Global]` section of the `cloud.conf`
-file:
-
-* `auth-url` (Required): The URL of the keystone API used to authenticate. On
-  OpenStack control panels, this can be found at Access and Security > API
-  Access > Credentials.
-* `username` (Required): Refers to the username of a valid user set in keystone.
-* `password` (Required): Refers to the password of a valid user set in keystone.
-* `tenant-id` (Required): Used to specify the id of the project where you want
-  to create your resources.
-* `tenant-name` (Optional): Used to specify the name of the project where you
-  want to create your resources.
-* `trust-id` (Optional): Used to specify the identifier of the trust to use for
-  authorization. A trust represents a user's (the trustor) authorization to
-  delegate roles to another user (the trustee), and optionally allow the trustee
-  to impersonate the trustor. Available trusts are found under the
-  `/v3/OS-TRUST/trusts` endpoint of the Keystone API.
-* `domain-id` (Optional): Used to specify the id of the domain your user belongs
-  to.
-* `domain-name` (Optional): Used to specify the name of the domain your user
-  belongs to.
-* `region` (Optional): Used to specify the identifier of the region to use when
-  running on a multi-region OpenStack cloud. A region is a general division of
-  an OpenStack deployment. Although a region does not have a strict geographical
-  connotation, a deployment can use a geographical name for a region identifier
-  such as `us-east`. Available regions are found under the `/v3/regions`
-  endpoint of the Keystone API.
-* `ca-file` (Optional): Used to specify the path to your custom CA file.
-
-
-When using Keystone V3 - which changes tenant to project - the `tenant-id` value
-is automatically mapped to the project construct in the API.
-
-#####  Load Balancer
-These configuration options for the OpenStack provider pertain to the load
-balancer and should appear in the `[LoadBalancer]` section of the `cloud.conf`
-file:
-
-* `lb-version` (Optional): Used to override automatic version detection. Valid
-  values are `v1` or `v2`. Where no value is provided automatic detection will
-  select the highest supported version exposed by the underlying OpenStack
-  cloud.
-* `use-octavia`(Optional): Whether or not to use Octavia for LoadBalancer type
-    of Service implementation instead of using Neutron-LBaaS. Default: true
-   Attention: Openstack CCM use Octavia as default load balancer implementation since v1.17.0
-* `subnet-id` (Optional): Used to specify the id of the subnet you want to
-  create your loadbalancer on. Can be found at Network > Networks. Click on the
-  respective network to get its subnets.
-* `floating-network-id` (Optional): If specified, will create a floating IP for
-  the load balancer.
-* `lb-method` (Optional): Used to specify an algorithm by which load will be
-  distributed amongst members of the load balancer pool. The value can be
-  `ROUND_ROBIN`, `LEAST_CONNECTIONS`, or `SOURCE_IP`. The default behavior if
-  none is specified is `ROUND_ROBIN`.
-* `lb-provider` (Optional): Used to specify the provider of the load balancer.
-  If not specified, the default provider service configured in neutron will be
-  used.
-* `create-monitor` (Optional): Indicates whether or not to create a health
-  monitor for the Neutron load balancer. Valid values are `true` and `false`.
-  The default is `false`. When `true` is specified then `monitor-delay`,
-  `monitor-timeout`, and `monitor-max-retries` must also be set.
-* `monitor-delay` (Optional): The time between sending probes to
-  members of the load balancer. Ensure that you specify a valid time unit. The valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h"
-* `monitor-timeout` (Optional): Maximum time for a monitor to wait
-  for a ping reply before it times out. The value must be less than the delay
-  value. Ensure that you specify a valid time unit. The valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h"
-* `monitor-max-retries` (Optional): Number of permissible ping failures before
-  changing the load balancer member's status to INACTIVE. Must be a number
-  between 1 and 10.
-* `manage-security-groups` (Optional): Determines whether or not the load
-  balancer should automatically manage the security group rules. Valid values
-  are `true` and `false`. The default is `false`. When `true` is specified
-  `node-security-group` must also be supplied.
-* `node-security-group` (Optional): ID of the security group to manage.
-
-##### Block Storage
-These configuration options for the OpenStack provider pertain to block storage
-and should appear in the `[BlockStorage]` section of the `cloud.conf` file:
-
-* `bs-version` (Optional): Used to override automatic version detection. Valid
-  values are `v1`, `v2`, `v3` and `auto`. When `auto` is specified automatic
-  detection will select the highest supported version exposed by the underlying
-  OpenStack cloud. The default value if none is provided is `auto`.
-* `trust-device-path` (Optional): In most scenarios the block device names
-  provided by Cinder (e.g. `/dev/vda`) can not be trusted. This boolean toggles
-  this behavior. Setting it to `true` results in trusting the block device names
-  provided by Cinder. The default value of `false` results in the discovery of
-  the device path based on its serial number and `/dev/disk/by-id` mapping and is
-  the recommended approach.
-* `ignore-volume-az` (Optional): Used to influence availability zone use when
-  attaching Cinder volumes. When Nova and Cinder have different availability
-  zones, this should be set to `true`. This is most commonly the case where
-  there are many Nova availability zones but only one Cinder availability zone.
-  The default value is `false` to preserve the behavior used in earlier
-  releases, but may change in the future.
-* `node-volume-attach-limit` (Optional): Maximum number of Volumes that can be
-  attached to the node, default is 256 for cinder.
-
-If deploying Kubernetes versions <= 1.8 on an OpenStack deployment that uses
-paths rather than ports to differentiate between endpoints it may be necessary
-to explicitly set the `bs-version` parameter. A path based endpoint is of the
-form `http://foo.bar/volume` while a port based endpoint is of the form
-`http://foo.bar:xxx`.
-
-In environments that use path based endpoints and Kubernetes is using the older
-auto-detection logic a `BS API version autodetection failed.` error will be
-returned on attempting volume detachment. To workaround this issue it is
-possible to force the use of Cinder API version 2 by adding this to the cloud
-provider configuration:
-
-```yaml
-[BlockStorage]
-bs-version=v2
-```
-
-##### Metadata
-These configuration options for the OpenStack provider pertain to metadata and
-should appear in the `[Metadata]` section of the `cloud.conf` file:
-
-* `search-order` (Optional): This configuration key influences the way that the
-  provider retrieves metadata relating to the instance(s) in which it runs. The
-  default value of `configDrive,metadataService` results in the provider
-  retrieving metadata relating to the instance from the config drive first if
-  available and then the metadata service. Alternative values are:
-  * `configDrive` - Only retrieve instance metadata from the configuration
-    drive.
-  * `metadataService` - Only retrieve instance metadata from the metadata
-    service.
-  * `metadataService,configDrive` - Retrieve instance metadata from the metadata
-    service first if available, then the configuration drive.
-
-  Influencing this behavior may be desirable as the metadata on the
-  configuration drive may grow stale over time, whereas the metadata service
-  always provides the most up to date view. Not all OpenStack clouds provide
-  both configuration drive and metadata service though and only one or the other
-  may be available which is why the default is to check both.
-
-##### Route
-
-These configuration options for the OpenStack provider pertain to the [kubenet]
-Kubernetes network plugin and should appear in the `[Route]` section of the
-`cloud.conf` file:
-
-* `router-id` (Optional): If the underlying cloud's Neutron deployment supports
-  the `extraroutes` extension then use `router-id` to specify a router to add
-  routes to.  The router chosen must span the private networks containing your
-  cluster nodes (typically there is only one node network, and this value should be
-  the default router for the node network).  This value is required to use
-  [kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)
-  on OpenStack.
-
-[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
-
-## vSphere
-
-{{< tabs name="vSphere cloud provider" >}}
-{{% tab name="vSphere >= 6.7U3" %}}
-For all vSphere deployments on vSphere >= 6.7U3, the [external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere), along with the [vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver) is recommended. See [Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html) for a quick start guide.
-{{% /tab %}}
-{{% tab name="vSphere < 6.7U3" %}}
-If you are running vSphere < 6.7U3, the in-tree vSphere cloud provider is recommended. See [Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html) for a quick start guide.
-{{% /tab %}}
-{{< /tabs >}}
-
-For in-depth documentation on the vSphere cloud provider, visit the [vSphere cloud provider docs site](https://cloud-provider-vsphere.sigs.k8s.io).
diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md
index 2d2abb7b26..f40a86bab4 100644
--- a/content/en/docs/concepts/cluster-administration/flow-control.md
+++ b/content/en/docs/concepts/cluster-administration/flow-control.md
@@ -426,7 +426,7 @@ poorly-behaved workloads that may be harming system health.
     {{< /note >}}
 
 * `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector
-  hoding the computed concurrency limit (based on the API server's
+  holding the computed concurrency limit (based on the API server's
   total concurrency limit and PriorityLevelConfigurations' concurrency
   shares), broken down by the label `priorityLevel`.
 
@@ -495,7 +495,7 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves
   system,            system-nodes,   12,         0,                   system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
   ```
   
-  In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation.
+  In addition to the queued requests, the output includes one phantom line for each priority level that is exempt from limitation.
 
   You can get a more detailed listing with a command like this:
   ```shell
diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md
index 3e7f398e66..6915a11ed4 100644
--- a/content/en/docs/concepts/cluster-administration/logging.md
+++ b/content/en/docs/concepts/cluster-administration/logging.md
@@ -24,8 +24,8 @@ the description of how logs are stored and handled on the node to be useful.
 
 In this section, you can see an example of basic logging in Kubernetes that
 outputs data to the standard output stream. This demonstration uses
-a [pod specification](/examples/debug/counter-pod.yaml) with
-a container that writes some text to standard output once per second.
+a pod specification with a container that writes some text to standard output
+once per second.
 
 {{< codenew file="debug/counter-pod.yaml" >}}
 
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index ff30e60b12..184b40c8dc 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -79,6 +79,8 @@ as an introduction to various technologies and serves as a jumping-off point.
 The following networking options are sorted alphabetically - the order does not
 imply any preferential status.
 
+{{% thirdparty-content %}}
+
 ### ACI
 
 [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf).
@@ -112,7 +114,7 @@ Additionally, the CNI can be run alongside [Calico for network policy enforcemen
 [Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.
 
 Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
- 
+
 
 ### Big Cloud Fabric from Big Switch Networks
 
@@ -122,6 +124,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c
 
 BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
 
+### Calico
+
+[Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
+
 ### Cilium
 
 [Cilium](https://github.com/cilium/cilium) is open source software for
@@ -152,6 +158,11 @@ 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
 network complexity required to deploy Kubernetes at scale within AWS.
 
+### Coil
+
+[Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
+Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
+
 ### Contiv
 
 [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
@@ -289,14 +300,6 @@ stateful ACLs, load-balancers etc to build different virtual networking
 topologies.  The project has a specific Kubernetes plugin and documentation
 at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
 
-### Project Calico
-
-[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
-
-Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)).  Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking.  Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
-
-Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
-
 ### Romana
 
 [Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
@@ -314,4 +317,3 @@ to run, and in both cases, the network provides one IP address per pod - as is s
 The early design of the networking model and its rationale, and some future
 plans are described in more detail in the
 [networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
-
diff --git a/content/en/docs/concepts/cluster-administration/system-metrics.md b/content/en/docs/concepts/cluster-administration/system-metrics.md
index e727aa17ce..3dba687f4e 100644
--- a/content/en/docs/concepts/cluster-administration/system-metrics.md
+++ b/content/en/docs/concepts/cluster-administration/system-metrics.md
@@ -104,7 +104,7 @@ The kubelet collects accelerator metrics through cAdvisor. To collect these metr
 
 The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus).
 
-The [`DisableAcceleratorUsageMetrics` feature gate](/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
+The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
 
 ## Component metrics
 
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index f40c99fbc4..d9889604ce 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -16,7 +16,6 @@ or use additional (third party) tools to keep your data private.
 {{< /caution >}}
 
 
-
 <!-- body -->
 ## Motivation
 
@@ -24,25 +23,38 @@ Use a ConfigMap for setting configuration data separately from application code.
 
 For example, imagine that you are developing an application that you can run on your
 own computer (for development) and in the cloud (to handle real traffic).
-You write the code to
-look in an environment variable named `DATABASE_HOST`. Locally, you set that variable
-to `localhost`. In the cloud, you set it to refer to a Kubernetes
-{{< glossary_tooltip text="Service" term_id="service" >}} that exposes the database
-component to your cluster.
-
+You write the code to look in an environment variable named `DATABASE_HOST`.
+Locally, you set that variable to `localhost`. In the cloud, you set it to
+refer to a Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}}
+that exposes the database component to your cluster.
 This lets you fetch a container image running in the cloud and
 debug the exact same code locally if needed.
 
+A ConfigMap is not designed to hold large chunks of data. The data stored in a
+ConfigMap cannot exceed 1 MiB. If you need to store settings that are
+larger than this limit, you may want to consider mounting a volume or use a
+separate database or file service.
+
 ## ConfigMap object
 
 A ConfigMap is an API [object](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
 that lets you store configuration for other objects to use. Unlike most
-Kubernetes objects that have a `spec`, a ConfigMap has a `data` section to
-store items (keys) and their values.
+Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
+fields. These fields accepts key-value pairs as their values.  Both the `data`
+field and the `binaryData` are optional. The `data` field is designed to
+contain UTF-8 byte sequences while the `binaryData` field is designed to
+contain binary data.
 
 The name of a ConfigMap must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
+Each key under the `data` or the `binaryData` field must consist of
+alphanumeric characters, `-`, `_` or `.`. The keys stored in `data` must not
+overlap with the keys in the `binaryData` field.
+
+Starting from v1.19, you can add an `immutable` field to a ConfigMap
+definition to create an [immutable ConfigMap](#configmap-immutable).
+
 ## ConfigMaps and Pods
 
 You can write a Pod `spec` that refers to a ConfigMap and configures the container(s)
@@ -62,7 +74,7 @@ data:
   # property-like keys; each key maps to a simple value
   player_initial_lives: "3"
   ui_properties_file_name: "user-interface.properties"
-  #
+
   # file-like keys
   game.properties: |
     enemy.types=aliens,monsters
@@ -76,7 +88,7 @@ data:
 There are four different ways that you can use a ConfigMap to configure
 a container inside a Pod:
 
-1. Command line arguments to the entrypoint of a container
+1. Inside a container command and args
 1. Environment variables for a container
 1. Add a file in read-only volume, for the application to read
 1. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap
@@ -94,6 +106,7 @@ when that happens. By accessing the Kubernetes API directly, this
 technique also lets you access a ConfigMap in a different namespace.
 
 Here's an example Pod that uses values from `game-demo` to configure a Pod:
+
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -102,7 +115,8 @@ metadata:
 spec:
   containers:
     - name: demo
-      image: game.example/demo-game
+      image: alpine
+      command: ["sleep", "3600"]
       env:
         # Define the environment variable
         - name: PLAYER_INITIAL_LIVES # Notice that the case is different here
@@ -134,7 +148,6 @@ spec:
           path: "user-interface.properties"
 ```
 
-
 A ConfigMap doesn't differentiate between single line property values and
 multi-line file-like values.
 What matters is how Pods and other objects consume those values.
@@ -153,7 +166,6 @@ ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
 parts of the system, without being directly exposed to the Pod. For example,
 ConfigMaps can hold data that other parts of the system should use for configuration.
 
-{{< note >}}
 The most common way to use ConfigMaps is to configure settings for
 containers running in a Pod in the same namespace. You can also use a
 ConfigMap separately.
@@ -162,16 +174,23 @@ For example, you
 might encounter {{< glossary_tooltip text="addons" term_id="addons" >}}
 or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
 adjust their behavior based on a ConfigMap.
-{{< /note >}}
 
 ### Using ConfigMaps as files from a Pod
 
 To consume a ConfigMap in a volume in a Pod:
 
-1. Create a config map or use an existing one. Multiple Pods can reference the same config map.
-1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object.
-1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear.
-1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`.
+1. Create a ConfigMap or use an existing one. Multiple Pods can reference the
+   same ConfigMap.
+1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name
+   the volume anything, and have a `.spec.volumes[].configMap.name` field set
+   to reference your ConfigMap object.
+1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the
+   ConfigMap. Specify `.spec.containers[].volumeMounts[].readOnly = true` and
+   `.spec.containers[].volumeMounts[].mountPath` to an unused directory name
+   where you would like the ConfigMap to appear.
+1. Modify your image or command line so that the program looks for files in
+   that directory. Each key in the ConfigMap `data` map becomes the filename
+   under `mountPath`.
 
 This is an example of a Pod that mounts a ConfigMap in a volume:
 
@@ -201,8 +220,8 @@ own `volumeMounts` block, but only one `.spec.volumes` is needed per ConfigMap.
 
 #### Mounted ConfigMaps are updated automatically
 
-When a config map currently consumed in a volume is updated, projected keys are eventually updated as well.
-The kubelet checks whether the mounted config map is fresh on every periodic sync.
+When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well.
+The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync.
 However, the kubelet uses its local cache for getting the current value of the ConfigMap.
 The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in
 the [KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
@@ -213,6 +232,9 @@ when new keys are projected to the Pod can be as long as the kubelet sync period
 propagation delay, where the cache propagation delay depends on the chosen cache type
 (it equals to watch propagation delay, ttl of cache, or zero correspondingly).
 
+ConfigMaps consumed as environment variables are not updated automatically and require a pod restart. 
+## Immutable ConfigMaps {#configmap-immutable}
+
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set
@@ -222,11 +244,13 @@ data has the following advantages:
 
 - protects you from accidental (or unwanted) updates that could cause applications outages
 - improves performance of your cluster by significantly reducing load on kube-apiserver, by
-closing watches for config maps marked as immutable.
+  closing watches for ConfigMaps marked as immutable.
+
+This feature is controlled by the `ImmutableEphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+You can create an immutable ConfigMap by setting the `immutable` field to `true`.
+For example:
 
-To use this feature, enable the `ImmutableEphemeralVolumes`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
-your Secret or ConfigMap `immutable` field to `true`. For example:
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -237,17 +261,13 @@ data:
 immutable: true
 ```
 
-{{< note >}}
-Once a ConfigMap or Secret is marked as immutable, it is _not_ possible to revert this change
-nor to mutate the contents of the `data` field. You can only delete and recreate the ConfigMap.
-Existing Pods maintain a mount point to the deleted ConfigMap - it is recommended to recreate
-these pods.
-{{< /note >}}
-
+Once a ConfigMap is marked as immutable, it is _not_ possible to revert this change
+nor to mutate the contents of the `data` or the `binaryData` field. You can
+only delete and recreate the ConfigMap. Because existing Pods maintain a mount point
+to the deleted ConfigMap, it is recommended to recreate these pods.
 
 ## {{% heading "whatsnext" %}}
 
-
 * Read about [Secrets](/docs/concepts/configuration/secret/).
 * Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
 * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index 1f907ad0d0..df8fb1310f 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -47,6 +47,13 @@ Limits can be implemented either reactively (the system intervenes once it sees
 or by enforcement (the system prevents the container from ever exceeding the limit). Different
 runtimes can have different ways to implement the same restrictions.
 
+{{< note >}}
+If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
+automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
+CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
+the limit.
+{{< /note >}}
+
 ## Resource types
 
 *CPU* and *memory* are each a *resource type*. A resource type has a base unit.
@@ -134,7 +141,6 @@ spec:
   containers:
   - name: app
     image: images.my-company.example/app:v4
-    env:
     resources:
       requests:
         memory: "64Mi"
@@ -439,7 +445,7 @@ If you want to use project quotas, you should:
   [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
   in the kubelet configuration.
 
-* Ensure that the the root filesystem (or optional runtime filesystem)
+* Ensure that the root filesystem (or optional runtime filesystem)
   has project quotas enabled. All XFS filesystems support project quotas.
   For ext4 filesystems, you need to enable the project quota tracking feature
   while the filesystem is not mounted.
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index f8e7c85311..d6acc80a71 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -11,7 +11,7 @@ weight: 70
 
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
-[Pods](/docs/concepts/workloads/pods/pod/) can have _priority_. Priority indicates the
+[Pods](/docs/concepts/workloads/pods/) can have _priority_. Priority indicates the
 importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
 scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
 pending Pod possible.
@@ -271,7 +271,7 @@ preempted. Here's an example:
 *   Pod P is being considered for Node N.
 *   Pod Q is running on another Node in the same Zone as Node N.
 *   Pod P has Zone-wide anti-affinity with Pod Q (`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`).
+    topology.kubernetes.io/zone`).
 *   There are no other cases of anti-affinity between Pod P and other Pods in
     the Zone.
 *   In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
@@ -321,9 +321,7 @@ Pod may be created that fits on the same Node. In this case, the scheduler will
 schedule the higher priority Pod instead of the preemptor.
 
 This is expected behavior: the Pod with the higher priority should take the place
-of a Pod with a lower priority. Other controller actions, such as
-[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling),
-may eventually provide capacity to schedule the pending Pods.
+of a Pod with a lower priority.
 
 ### Higher priority Pods are preempted before lower priority pods
 
diff --git a/content/en/docs/concepts/configuration/resource-bin-packing.md b/content/en/docs/concepts/configuration/resource-bin-packing.md
deleted file mode 100644
index 9d6ab31889..0000000000
--- a/content/en/docs/concepts/configuration/resource-bin-packing.md
+++ /dev/null
@@ -1,197 +0,0 @@
----
-reviewers:
-- bsalamat
-- k82cn
-- ahg-g
-title: Resource Bin Packing for Extended Resources
-content_type: concept
-weight: 50
----
-
-<!-- overview -->
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs. 
-
-
-
-<!-- body -->
-
-## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
-
-Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
-consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
-
-Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
-
-```json
-{
-    "kind" : "Policy",
-    "apiVersion" : "v1",
-
-    ...
-
-    "priorities" : [
-
-       ...
-
-      {
-        "name": "RequestedToCapacityRatioPriority",
-        "weight": 2,
-        "argument": {
-          "requestedToCapacityRatioArguments": {
-            "shape": [
-              {"utilization": 0, "score": 0},
-              {"utilization": 100, "score": 10}
-            ],
-            "resources": [
-              {"name": "intel.com/foo", "weight": 3},
-              {"name": "intel.com/bar", "weight": 5}
-            ]
-          }
-        }
-      }
-    ],
-  }
-```
-
-**This feature is disabled by default**
-
-### Tuning RequestedToCapacityRatioResourceAllocation Priority Function
-
-`shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
-
-```yaml
- {"utilization": 0, "score": 0},
- {"utilization": 100, "score": 10}
-```
-
-The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
-
-```yaml
- {"utilization": 0, "score": 100},
- {"utilization": 100, "score": 0}
-```
-
-`resources` is an optional parameter which by defaults is set to:
-
-``` yaml
-"resources": [
-              {"name": "CPU", "weight": 1},
-              {"name": "Memory", "weight": 1}
-            ]
-```
-
-It can be used to add extended resources as follows: 
-
-```yaml
-"resources": [
-              {"name": "intel.com/foo", "weight": 5},
-              {"name": "CPU", "weight": 3},
-              {"name": "Memory", "weight": 1}
-            ]
-```
-
-The weight parameter is optional and is set to 1 if not specified. Also, the weight cannot be set to a negative value.
-
-### How the RequestedToCapacityRatioResourceAllocation Priority Function Scores Nodes
-
-This section is intended for those who want to understand the internal details
-of this feature.
-Below is an example of how the node score is calculated for a given set of values.
-
-```
-Requested Resources
-
-intel.com/foo : 2
-Memory: 256MB
-CPU: 2
-
-Resource Weights
-
-intel.com/foo : 5
-Memory: 1
-CPU: 3
-
-FunctionShapePoint {{0, 0}, {100, 10}}
-
-Node 1 Spec
-
-Available:
-intel.com/foo : 4
-Memory : 1 GB
-CPU: 8
-
-Used:
-intel.com/foo: 1
-Memory: 256MB
-CPU: 1
-
-
-Node Score:
-
-intel.com/foo  = resourceScoringFunction((2+1),4)
-               = (100 - ((4-3)*100/4)
-               = (100 - 25)
-               = 75                       # requested + used = 75% * available
-               = rawScoringFunction(75) 
-               = 7                        # floor(75/10) 
-
-Memory         = resourceScoringFunction((256+256),1024)
-               = (100 -((1024-512)*100/1024))
-               = 50                       # requested + used = 50% * available
-               = rawScoringFunction(50)
-               = 5                        # floor(50/10)
-
-CPU            = resourceScoringFunction((2+1),8)
-               = (100 -((8-3)*100/8))
-               = 37.5                     # requested + used = 37.5% * available
-               = rawScoringFunction(37.5)
-               = 3                        # floor(37.5/10)
-
-NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
-            =  5
-
-
-Node 2 Spec
-
-Available:
-intel.com/foo: 8
-Memory: 1GB
-CPU: 8
-
-Used:
-
-intel.com/foo: 2
-Memory: 512MB
-CPU: 6
-
-
-Node Score:
-
-intel.com/foo  = resourceScoringFunction((2+2),8)
-               =  (100 - ((8-4)*100/8)
-               =  (100 - 50)
-               =  50
-               =  rawScoringFunction(50)
-               = 5
-
-Memory         = resourceScoringFunction((256+512),1024)
-               = (100 -((1024-768)*100/1024))
-               = 75
-               = rawScoringFunction(75)
-               = 7
-
-CPU            = resourceScoringFunction((2+6),8)
-               = (100 -((8-8)*100/8))
-               = 100
-               = rawScoringFunction(100)
-               = 10
-
-NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
-            =  7
-
-```
-
-
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index 8c4dbcadb0..572072dd3e 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -15,438 +15,387 @@ weight: 30
 Kubernetes Secrets let you store and manage sensitive information, such
 as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
 is safer and more flexible than putting it verbatim in a
-{{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
-
+{{< glossary_tooltip term_id="pod" >}} definition or in a
+{{< glossary_tooltip text="container image" term_id="image" >}}.
+See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
 
+A Secret is an object that contains a small amount of sensitive data such as
+a password, a token, or a key. Such information might otherwise be put in a
+Pod specification or in an image. Users can create Secrets and the system
+also creates some Secrets.
 
 <!-- body -->
 
 ## Overview of Secrets
 
-A Secret is an object that contains a small amount of sensitive data such as
-a password, a token, or a key. Such information might otherwise be put in a
-Pod specification or in an image. Users can create secrets and the system
-also creates some secrets.
-
-To use a secret, a Pod needs to reference the secret.
-A secret can be used with a Pod in three ways:
+To use a Secret, a Pod needs to reference the Secret.
+A Secret can be used with a Pod in three ways:
 
 - As [files](#using-secrets-as-files-from-a-pod) in a
-{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
-its containers.
+  {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
+  its containers.
 - As [container environment variable](#using-secrets-as-environment-variables).
 - By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
 
-### Built-in Secrets
+The name of a Secret object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+You can specify the `data` and/or the `stringData` field when creating a
+configuration file for a Secret.  The `data` and the `stringData` fields are optional.
+The values for all keys in the `data` field have to be base64-encoded strings.
+If the conversion to base64 string is not desirable, you can choose to specify
+the `stringData` field instead, which accepts arbitrary strings as values.
 
-#### Service accounts automatically create and attach Secrets with API credentials
+The keys of `data` and `stringData` must consist of alphanumeric characters,
+`-`, `_` or `.`. All key-value pairs in the `stringData` field are internally
+merged into the `data` field. If a key appears in both the `data` and the
+`stringData` field, the value specified in the `stringData` field takes
+precedence.
 
-Kubernetes automatically creates secrets which contain credentials for
-accessing the API and automatically modifies your Pods to use this type of
-secret.
+## Types of Secret {#secret-types}
 
-The automatic creation and use of API credentials can be disabled or overridden
-if desired.  However, if all you need to do is securely access the API server,
-this is the recommended workflow.
+When creating a Secret, you can specify its type using the `type` field of
+the [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+resource, or certain equivalent `kubectl` command line flags (if available).
+The Secret type is used to facilitate programmatic handling of the Secret data.
+
+Kubernetes provides several builtin types for some common usage scenarios.
+These types vary in terms of the validations performed and the constraints
+Kubernetes imposes on them.
+
+| Builtin Type | Usage |
+|--------------|-------|
+| `Opaque`     |  arbitrary user-defined data |
+| `kubernetes.io/service-account-token` | service account token |
+| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file |
+| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file |
+| `kubernetes.io/basic-auth` | credentials for basic authentication |
+| `kubernetes.io/ssh-auth` | credentials for SSH authentication |
+| `kubernetes.io/tls` | data for a TLS client or server |
+| `bootstrap.kubernetes.io/token` | bootstrap token data |
+
+You can define and use your own Secret type by assigning a non-empty string as the
+`type` value for a Secret object. An empty string is treated as an `Opaque` type.
+Kubernetes doesn't impose any constraints on the type name. However, if you
+are using one of the builtin types, you must meet all the requirements defined
+for that type.
+
+### Opaque secrets
+
+`Opaque` is the default Secret type if omitted from a Secret configuration file.
+When you create a Secret using `kubectl`, you will use the `generic`
+subcommand to indicate an `Opaque` Secret type. For example, the following
+command creates an empty Secret of type `Opaque`.
+
+```shell
+kubectl create secret generic empty-secret
+kubectl get secret empty-secret
+```
+
+The output looks like:
+
+```
+NAME           TYPE     DATA   AGE
+empty-secret   Opaque   0      2m6s
+```
+
+The `DATA` column shows the number of data items stored in the Secret.
+In this case, `0` means we have just created an empty Secret.
+
+###  Service account token Secrets
+
+A `kubernetes.io/service-account-token` type of Secret is used to store a
+token that identifies a service account. When using this Secret type, you need
+to ensure that the `kubernetes.io/service-account.name` annotation is set to an
+existing service account name. An Kubernetes controller fills in some other
+fields such as the `kubernetes.io/service-account.uid` annotation and the
+`token` key in the `data` field set to actual token content.
+
+The following example configuration declares a service account token Secret:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: secret-sa-sample
+  annotations:
+    kubernetes.io/service-account.name: "sa-name"
+type: kubernetes.io/service-account-token
+data:
+  # You can include additional key value pairs as you do with Opaque Secrets
+  extra: YmFyCg==
+```
+
+When creating a `Pod`, Kubernetes automatically creates a service account Secret
+and automatically modifies your Pod to use this Secret. The service account token
+Secret contains credentials for accessing the API.
+
+The automatic creation and use of API credentials can be disabled or
+overridden if desired. However, if all you need to do is securely access the
+API server, this is the recommended workflow.
 
 See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
 documentation for more information on how service accounts work.
+You can also check the `automountServiceAccountToken` field and the
+`serviceAccountName` field of the
+[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+for information on referencing service account from Pods.
 
-### Creating your own Secrets
+### Docker config Secrets
 
-#### Creating a Secret Using `kubectl`
+You can use one of the following `type` values to create a Secret to
+store the credentials for accessing a Docker registry for images.
 
-Secrets can contain user credentials required by Pods to access a database.
-For example, a database connection string
-consists of a username and password. You can store the username in a file `./username.txt`
-and the password in a file `./password.txt` on your local machine.
+- `kubernetes.io/dockercfg`
+- `kubernetes.io/dockerconfigjson`
 
-```shell
-# Create files needed for the rest of the example.
-echo -n 'admin' > ./username.txt
-echo -n '1f2d1e2e67df' > ./password.txt
-```
+The `kubernetes.io/dockercfg` type is reserved to store a serialized
+`~/.dockercfg` which is the legacy format for configuring Docker command line.
+When using this Secret type, you have to ensure the Secret `data` field
+contains a `.dockercfg` key whose value is content of a `~/.dockercfg` file
+encoded in the base64 format.
 
-The `kubectl create secret` command packages these files into a Secret and creates
-the object on the API server.
-The name of a Secret object must be a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+The `kubernetes/dockerconfigjson` type is designed for storing a serialized
+JSON that follows the same format rules as the `~/.docker/config.json` file
+which is a new format for `~/.dockercfg`.
+When using this Secret type, the `data` field of the Secret object must
+contain a `.dockerconfigjson` key, in which the content for the
+`~/.docker/config.json` file is provided as a base64 encoded string.
 
-```shell
-kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
-```
-
-The output is similar to:
-
-```
-secret "db-user-pass" created
-```
-
-Default key name is the filename. You may optionally set the key name using `[--from-file=[key=]source]`.
-
-```shell
-kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
-```
-
-{{< note >}}
-Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping.
-In most shells, the easiest way to escape the password is to surround it with single quotes (`'`).
-For example, if your actual password is `S!B\*d$zDsb=`, you should execute the command this way:
-
-```shell
-kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
-```
-
-You do not need to escape special characters in passwords from files (`--from-file`).
-{{< /note >}}
-
-You can check that the secret was created:
-
-```shell
-kubectl get secrets
-```
-
-The output is similar to:
-
-```
-NAME                  TYPE                                  DATA      AGE
-db-user-pass          Opaque                                2         51s
-```
-
-You can view a description of the secret:
-
-```shell
-kubectl describe secrets/db-user-pass
-```
-
-The output is similar to:
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-{{< note >}}
-The commands `kubectl get` and `kubectl describe` avoid showing the contents of a secret by
-default. This is to protect the secret from being exposed accidentally to an onlooker,
-or from being stored in a terminal log.
-{{< /note >}}
-
-See [decoding a secret](#decoding-a-secret) to learn how to view the contents of a secret.
-
-#### Creating a Secret manually
-
-You can also create a Secret in a file first, in JSON or YAML format,
-and then create that object.
-The name of a Secret object must be a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-The [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
-contains two maps:
-`data` and `stringData`. The `data` field is used to store arbitrary data, encoded using
-base64. The `stringData` field is provided for convenience, and allows you to provide
-secret data as unencoded strings.
-
-For example, to store two strings in a Secret using the `data` field, convert
-the strings to base64 as follows:
-
-```shell
-echo -n 'admin' | base64
-```
-
-The output is similar to:
-
-```
-YWRtaW4=
-```
-
-```shell
-echo -n '1f2d1e2e67df' | base64
-```
-
-The output is similar to:
-
-```
-MWYyZDFlMmU2N2Rm
-```
-
-Write a Secret that looks like this:
+Below is an example for a `kubernetes.io/dockercfg` type of Secret:
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  name: mysecret
-type: Opaque
+  name: secret-dockercfg
+type: kubernetes.io/dockercfg
 data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
+  .dockercfg: |
+    "<base64 encoded ~/.dockercfg file>"
 ```
 
-Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply):
+{{< note >}}
+If you do not want to perform the base64 encoding, you can choose to use the
+`stringData` field instead.
+{{< /note >}}
+
+When you create these types of Secrets using a manifest, the API
+server checks whether the expected key does exists in the `data` field, and
+it verifies if the value provided can be parsed as a valid JSON. The API
+server doesn't validate if the JSON actually is a Docker config file.
+
+When you do not have a Docker config file, or you want to use `kubectl`
+to create a Docker registry Secret, you can do:
 
 ```shell
-kubectl apply -f ./secret.yaml
+kubectl create secret docker-registry secret-tiger-docker \
+  --docker-username=tiger \
+  --docker-password=pass113 \
+  --docker-email=tiger@acme.com
 ```
 
-The output is similar to:
+This command creates a Secret of type `kubernetes.io/dockerconfigjson`.
+If you dump the `.dockerconfigjson` content from the `data` field, you will
+get the following JSON content which is a valid Docker configuration created
+on the fly:
 
-```
-secret "mysecret" created
+```json
+{
+  "auths": {
+    "https://index.docker.io/v1/": {
+      "username": "tiger",
+      "password": "pass113",
+      "email": "tiger@acme.com",
+      "auth": "dGlnZXI6cGFzczExMw=="
+    }
+  }
+}
 ```
 
-For certain scenarios, you may wish to use the `stringData` field instead. This
-field allows you to put a non-base64 encoded string directly into the Secret,
-and the string will be encoded for you when the Secret is created or updated.
+### Basic authentication Secret
 
-A practical example of this might be where you are deploying an application
-that uses a Secret to store a configuration file, and you want to populate
-parts of that configuration file during your deployment process.
+The `kubernetes.io/basic-auth` type is provided for storing credentials needed
+for basic authentication. When using this Secret type, the `data` field of the
+Secret must contain the following two keys:
 
-For example, if your application uses the following configuration file:
+- `username`: the user name for authentication;
+- `password`: the password or token for authentication.
 
-```yaml
-apiUrl: "https://my.api.com/api/v1"
-username: "user"
-password: "password"
-```
+Both values for the above two keys are base64 encoded strings. You can, of
+course, provide the clear text content using the `stringData` for Secret
+creation.
 
-You could store this in a Secret using the following definition:
+The following YAML is an example config for a basic authentication Secret:
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  name: mysecret
-type: Opaque
+  name: secret-basic-auth
+type: kubernetes.io/basic-auth
 stringData:
-  config.yaml: |-
-    apiUrl: "https://my.api.com/api/v1"
-    username: {{username}}
-    password: {{password}}
+  username: admin
+  password: t0p-Secret
 ```
 
-Your deployment tool could then replace the `{{username}}` and `{{password}}`
-template variables before running `kubectl apply`.
+The basic authentication Secret type is provided only for user's convenience.
+You can create an `Opaque` for credentials used for basic authentication.
+However, using the builtin Secret type helps unify the formats of your credentials
+and the API server does verify if the required keys are provided in a Secret
+configuration.
 
-The `stringData` field is a write-only convenience field. It is never output when
-retrieving Secrets. For example, if you run the following command:
+### SSH authentication secrets
+
+The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in
+SSH authentication. When using this Secret type, you will have to specify a
+`ssh-privatekey` key-value pair in the `data` (or `stringData`) field.
+as the SSH credential to use.
+
+The following YAML is an example config for a SSH authentication Secret:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: secret-ssh-auth
+type: kubernetes.io/ssh-auth
+data:
+  # the data is abbreviated in this example
+  ssh-privatekey: |
+     MIIEpQIBAAKCAQEAulqb/Y ...
+```
+
+The SSH authentication Secret type is provided only for user's convenience.
+You can create an `Opaque` for credentials used for SSH authentication.
+However, using the builtin Secret type helps unify the formats of your credentials
+and the API server does verify if the required keys are provided in a Secret
+configuration.
+
+### TLS secrets
+
+Kubernetes provides a builtin Secret type `kubernetes.io/tls` for to storing
+a certificate and its associated key that are typically used for TLS . This
+data is primarily used with TLS termination of the Ingress resource, but may
+be used with other resources or directly by a workload.
+When using this type of Secret, the `tls.key` and the `tls.crt` key must be provided
+in the `data` (or `stringData`) field of the Secret configuration, although the API
+server doesn't actually validate the values for each key.
+
+The following YAML contains an example config for a TLS Secret:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: secret-tls
+type: kubernetes.io/tls
+data:
+  # the data is abbreviated in this example
+  tls.crt: |
+    MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
+  tls.key: |
+    MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
+```
+
+The TLS Secret type is provided for user's convenience. You can create an `Opaque`
+for credentials used for TLS server and/or client. However, using the builtin Secret
+type helps ensure the consistency of Secret format in your project; the API server
+does verify if the required keys are provided in a Secret configuration.
+
+When creating a TLS Secret using `kubectl`, you can use the `tls` subcommand
+as shown in the following example:
 
 ```shell
-kubectl get secret mysecret -o yaml
+kubectl create secret tls my-tls-secret \
+  --cert=path/to/cert/file \
+  --key=path/to/key/file
 ```
 
-The output is similar to:
+The public/private key pair must exist before hand. The public key certificate
+for `--cert` must be .PEM encoded (Base64-encoded DER format), and match the
+given private key for `--key`.
+The private key must be in what is commonly called PEM private key format,
+unencrypted. In both cases, the initial and the last lines from PEM (for
+example, `--------BEGIN CERTIFICATE-----` and `-------END CERTIFICATE----` for
+a cetificate) are *not* included.
+
+### Bootstrap token Secrets
+
+A bootstrap token Secret can be created by explicitly specifying the Secret
+`type` to `bootstrap.kubernetes.io/token`. This type of Secret is designed for
+tokens used during the node bootstrap process. It stores tokens used to sign
+well known ConfigMaps.
+
+A bootstrap token Secret is usually created in the `kube-system` namespace and
+named in the form `bootstrap-token-<token-id>` where `<token-id>` is a 6 character
+string of the token ID.
+
+As a Kubernetes manifest, a bootstrap token Secret might look like the
+following:
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  creationTimestamp: 2018-11-15T20:40:59Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7225"
-  uid: c280ad2e-e916-11e8-98f2-025000000001
-type: Opaque
+  name: bootstrap-token-5emitj
+  namespace: kube-system
+type: bootstrap.kubernetes.io/token
 data:
-  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
+  auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
+  expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
+  token-id: NWVtaXRq
+  token-secret: a3E0Z2lodnN6emduMXAwcg==
+  usage-bootstrap-authentication: dHJ1ZQ==
+  usage-bootstrap-signing: dHJ1ZQ==
 ```
 
-If a field, such as `username`, is specified in both `data` and `stringData`,
-the value from `stringData` is used. For example, the following Secret definition:
+A bootstrap type has the following keys specified under `data`:
+
+- `token_id`: A random 6 character string as the token identifier. Required.
+- `token-secret`: A random 16 character string as the actual token secret. Required.
+- `description1`: A human-readable string that describes what the token is
+  used for. Optional.
+- `expiration`: An absolute UTC time using RFC3339 specifying when the token
+  should be expired. Optional.
+- `usage-bootstrap-<usage>`: A boolean flag indicating additional usage for
+  the bootstrap token.
+- `auth-extra-groups`: A comma-separated list of group names that will be
+  authenticated as in addition to system:bootstrappers group.
+
+The above YAML may look confusing because the values are all in base64 encoded
+strings. In fact, you can create an identical Secret using the following YAML
+which results in an identical Secret object:
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  name: mysecret
-type: Opaque
-data:
-  username: YWRtaW4=
+  # Note how the Secret is named
+  name: bootstrap-token-5emitj
+  # A bootstrap token Secret usually resides in the kube-system namespace
+  namespace: kube-system
+type: bootstrap.kubernetes.io/token
 stringData:
-  username: administrator
+  auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
+  expiration: "2020-09-13T04:39:10Z"
+  # This token ID is used in the name
+  token-id: "5emitj"
+  token-secret: "kq4gihvszzgn1p0r"
+  # This token can be used for authentication
+  usage-bootstrap-authentication: "true"
+  # and it can be used for signing
+  usage-bootstrap-signing: "true"
 ```
 
-Results in the following Secret:
+## Creating a Secret
 
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2018-11-15T20:46:46Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7579"
-  uid: 91460ecb-e917-11e8-98f2-025000000001
-type: Opaque
-data:
-  username: YWRtaW5pc3RyYXRvcg==
-```
+There are several options to create a Secret:
 
-Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
+- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
 
-The keys of `data` and `stringData` must consist of alphanumeric characters,
-'-', '_' or '.'.
-
-{{< note >}}
-The serialized JSON and YAML values of secret data are
-encoded as base64 strings. Newlines are not valid within these strings and must
-be omitted. When using the `base64` utility on Darwin/macOS, users should avoid
-using the `-b` option to split long lines. Conversely, Linux users *should* add
-the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if
-the `-w` option is not available.
-{{< /note >}}
-
-#### Creating a Secret from a generator
-
-Since Kubernetes v1.14, `kubectl` supports [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/). Kustomize provides resource Generators to
-create Secrets and ConfigMaps. The Kustomize generators should be specified in a
-`kustomization.yaml` file inside a directory. After generating the Secret,
-you can create the Secret on the API server with `kubectl apply`.
-
-#### Generating a Secret from files
-
-You can generate a Secret by defining a `secretGenerator` from the
-files ./username.txt and ./password.txt:
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
-- name: db-user-pass
-  files:
-  - username.txt
-  - password.txt
-EOF
-```
-
-Apply the directory, containing the `kustomization.yaml`, to create the Secret.
-
-```shell
-kubectl apply -k .
-```
-
-The output is similar to:
-
-```
-secret/db-user-pass-96mffmfh4k created
-```
-
-You can check that the secret was created:
-
-```shell
-kubectl get secrets
-```
-
-The output is similar to:
-
-```
-NAME                             TYPE                                  DATA      AGE
-db-user-pass-96mffmfh4k          Opaque                                2         51s
-```
-
-You can view a description of the secret:
-
-```shell
-kubectl describe secrets/db-user-pass-96mffmfh4k
-```
-
-The output is similar to:
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-#### Generating a Secret from string literals
-
-You can create a Secret by defining a `secretGenerator`
-from literals `username=admin` and `password=secret`:
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
-- name: db-user-pass
-  literals:
-  - username=admin
-  - password=secret
-EOF
-```
-
-Apply the directory, containing the `kustomization.yaml`, to create the Secret.
-
-```shell
-kubectl apply -k .
-```
-
-The output is similar to:
-
-```
-secret/db-user-pass-dddghtt9b5 created
-```
-
-{{< note >}}
-When a Secret is generated, the Secret name is created by hashing
-the Secret data and appending this value to the name. This ensures that
-a new Secret is generated each time the data is modified.
-{{< /note >}}
-
-#### Decoding a Secret
-
-Secrets can be retrieved by running `kubectl get secret`.
-For example, you can view the Secret created in the previous section by
-running the following command:
-
-```shell
-kubectl get secret mysecret -o yaml
-```
-
-The output is similar to:
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2016-01-22T18:41:56Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "164619"
-  uid: cfee02d6-c137-11e5-8d73-42010af00002
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-Decode the `password` field:
-
-```shell
-echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
-```
-
-The output is similar to:
-
-```
-1f2d1e2e67df
-```
-
-#### Editing a Secret
+## Editing a Secret
 
 An existing Secret may be edited with the following command:
 
@@ -717,37 +666,6 @@ A container using a Secret as a
 Secret updates.
 {{< /note >}}
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
-The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set
-individual Secrets and ConfigMaps as immutable. For clusters that extensively use Secrets
-(at least tens of thousands of unique Secret to Pod mounts), preventing changes to their
-data has the following advantages:
-
-- protects you from accidental (or unwanted) updates that could cause applications outages
-- improves performance of your cluster by significantly reducing load on kube-apiserver, by
-closing watches for secrets marked as immutable.
-
-To use this feature, enable the `ImmutableEphemeralVolumes`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
-your Secret or ConfigMap `immutable` field to `true`. For example:
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  ...
-data:
-  ...
-immutable: true
-```
-
-{{< note >}}
-Once a Secret or ConfigMap is marked as immutable, it is _not_ possible to revert this change
-nor to mutate the contents of the `data` field. You can only delete and recreate the Secret.
-Existing Pods maintain a mount point to the deleted Secret - it is recommended to recreate
-these pods.
-{{< /note >}}
-
 ### Using Secrets as environment variables
 
 To use a secret in an {{< glossary_tooltip text="environment variable" term_id="container-env-variables" >}}
@@ -808,6 +726,40 @@ The output is similar to:
 1f2d1e2e67df
 ```
 
+## Immutable Secrets {#secret-immutable}
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set
+individual Secrets and ConfigMaps as immutable. For clusters that extensively use Secrets
+(at least tens of thousands of unique Secret to Pod mounts), preventing changes to their
+data has the following advantages:
+
+- protects you from accidental (or unwanted) updates that could cause applications outages
+- improves performance of your cluster by significantly reducing load on kube-apiserver, by
+closing watches for secrets marked as immutable.
+
+This feature is controlled by the `ImmutableEphemeralVolumes` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/),
+which is enabled by default since v1.19. You can create an immutable
+Secret by setting the `immutable` field to `true`. For example,
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+Once a Secret or ConfigMap is marked as immutable, it is _not_ possible to revert this change
+nor to mutate the contents of the `data` field. You can only delete and recreate the Secret.
+Existing Pods maintain a mount point to the deleted Secret - it is recommended to recreate
+these pods.
+{{< /note >}}
+
 ### Using imagePullSecrets
 
 The `imagePullSecrets` field is a list of references to secrets in the same namespace.
@@ -1272,3 +1224,11 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
    by impersonating the kubelet. It is a planned feature to only send secrets to
    nodes that actually require them, to restrict the impact of a root exploit on a
    single node.
+
+
+## {{% heading "whatsnext" %}}
+
+- Learn how to [manage Secret using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+
diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md
index edee4eccc4..746e1b7fc9 100644
--- a/content/en/docs/concepts/containers/_index.md
+++ b/content/en/docs/concepts/containers/_index.md
@@ -31,7 +31,7 @@ and default values for any essential settings.
 
 By design, a container is immutable: you cannot change the code of a
 container that is already running. If you have a containerized application
-and want to make changes, you need to build a new container that includes
+and want to make changes, you need to build a new image that includes
 the change, then recreate the container to start from the updated image.
 
 ## Container runtimes
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index 09d5530a29..fa74d94221 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -38,7 +38,7 @@ No parameters are passed to the handler.
 
 This hook is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention and others. A call to the preStop hook fails if the container is already in terminated or completed state.
 It is blocking, meaning it is synchronous,
-so it must complete before the call to delete the container can be sent.
+so it must complete before the signal to stop the container can be sent.
 No parameters are passed to the handler.
 
 A more detailed description of the termination behavior can be found in
@@ -56,7 +56,8 @@ Resources consumed by the command are counted against the Container.
 ### Hook handler execution
 
 When a Container lifecycle management hook is called,
-the Kubernetes management system executes the handler in the Container registered for that hook. 
+the Kubernetes management system execute the handler according to the hook action,
+`exec` and `tcpSocket` are executed in the container, and `httpGet` is executed by the kubelet process.
 
 Hook handler calls are synchronous within the context of the Pod containing the Container.
 This means that for a `PostStart` hook,
@@ -64,10 +65,21 @@ the Container ENTRYPOINT and hook fire asynchronously.
 However, if the hook takes too long to run or hangs,
 the Container cannot reach a `running` state.
 
-The behavior is similar for a `PreStop` hook.
-If the hook hangs during execution,
-the Pod phase stays in a `Terminating` state and is killed after `terminationGracePeriodSeconds` of pod ends.
-If a `PostStart` or `PreStop` hook fails,
+`PreStop` hooks are not executed asynchronously from the signal
+to stop the Container; the hook must complete its execution before
+the signal can be sent.
+If a `PreStop` hook hangs during execution,
+the Pod's phase will be `Terminating` and remain there until the Pod is
+killed after its `terminationGracePeriodSeconds` expires.
+This grace period applies to the total time it takes for both
+the `PreStop` hook to execute and for the Container to stop normally.
+If, for example, `terminationGracePeriodSeconds` is 60, and the hook
+takes 55 seconds to complete, and the Container takes 10 seconds to stop
+normally after receiving the signal, then the Container will be killed
+before it can stop normally, since `terminationGracePeriodSeconds` is
+less than the total time (55+10) it takes for these two things to happen.
+
+If either a `PostStart` or `PreStop` hook fails,
 it kills the Container.
 
 Users should make their hook handlers as lightweight as possible.
@@ -121,4 +133,3 @@ Events:
 * Get hands-on experience
   [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
 
-
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index ddd294feda..be25fd4e14 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -47,7 +47,7 @@ to roll back to a working version.
 Instead, specify a meaningful tag such as `v1.42.0`.
 {{< /caution >}}
 
-## Updating Images
+## Updating images
 
 The default pull policy is `IfNotPresent` which causes the
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
@@ -61,13 +61,13 @@ you can do one of the following:
 
 When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
 
-## Multi-architecture Images with Manifests
+## Multi-architecture images with image indexes
 
-As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
+As well as providing binary images, a container registry can also serve a [container image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md). An image index can point to multiple [image manifests](https://github.com/opencontainers/image-spec/blob/master/manifest.md) for architecture-specific versions of a container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
 
 Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
 
-## Using a Private Registry
+## Using a private registry
 
 Private registries may require keys to read images from them.  
 Credentials can be provided in several ways:
@@ -86,7 +86,7 @@ Credentials can be provided in several ways:
 
 These options are explaind in more detail below.
 
-### Configuring Nodes to authenticate to a Private Registry
+### Configuring nodes to authenticate to a private registry
 
 If you run Docker on your nodes, you can configure the Docker container
 runtime to authenticate to a private container registry.
@@ -178,7 +178,7 @@ template needs to include the `.docker/config.json` or mount a drive that contai
 All pods will have read access to images in any private registry once private
 registry keys are added to the `.docker/config.json`.
 
-### Pre-pulled Images
+### Pre-pulled images
 
 {{< note >}}
 This approach is suitable if you can control node configuration.  It
@@ -197,7 +197,7 @@ This can be used to preload certain images for speed or as an alternative to aut
 
 All pods will have read access to any pre-pulled images.
 
-### Specifying ImagePullSecrets on a Pod
+### Specifying imagePullSecrets on a Pod
 
 {{< note >}}
 This is the recommended approach to run containers based on images
@@ -206,7 +206,7 @@ in private registries.
 
 Kubernetes supports specifying container image registry keys on a Pod.
 
-#### Creating a Secret with a Docker Config
+#### Creating a Secret with a Docker config
 
 Run the following command, substituting the appropriate uppercase values:
 
@@ -266,7 +266,7 @@ Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-cont
 You can use this in conjunction with a per-node `.docker/config.json`.  The credentials
 will be merged.
 
-## Use Cases
+## Use cases
 
 There are a number of solutions for configuring private registries.  Here are some
 common use cases and suggested solutions.
diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md
index 8f685e35f3..6589590bc4 100644
--- a/content/en/docs/concepts/containers/runtime-class.md
+++ b/content/en/docs/concepts/containers/runtime-class.md
@@ -181,9 +181,9 @@ are accounted for in Kubernetes.
 ## {{% heading "whatsnext" %}}
 
 
-- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
-- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
-- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
+- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
+- Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept
 - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
 
 
diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md
index 4ffb0a831f..429912a9ed 100644
--- a/content/en/docs/concepts/extend-kubernetes/_index.md
+++ b/content/en/docs/concepts/extend-kubernetes/_index.md
@@ -130,7 +130,7 @@ Adding an API does not directly let you affect the behavior of existing APIs (e.
 
 ### API Access Extensions
 
-When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
 
 Each of these steps offers extension points.
 
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 9a84267445..dcfef3f6b6 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -16,7 +16,7 @@ methods for adding custom resources and how to choose between them.
 <!-- body -->
 ## Custom resources
 
-A *resource* is an endpoint in the [Kubernetes API](/docs/reference/using-api/api-overview/) that stores a collection of
+A *resource* is an endpoint in the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) that stores a collection of
 [API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) of a certain kind; for example, the built-in *pods* resource contains a collection of Pod objects.
 
 A *custom resource* is an extension of the Kubernetes API that is not necessarily available in a default
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 441d3bd871..314a01354a 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -37,7 +37,7 @@ During the registration, the device plugin needs to send:
   * The name of its Unix socket.
   * The Device Plugin API version against which it was built.
   * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
-    [extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources)
+    [extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
     as `vendor-domain/resourcetype`.
     (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
 
@@ -210,7 +210,7 @@ Support for the "PodResources service" requires `KubeletPodResources` [feature g
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-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.
+The Topology Manager is a Kubelet component that allows resources to be co-ordinated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
 
 
 ```gRPC
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index b32bce83dd..0384754e35 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -11,21 +11,17 @@ weight: 10
 
 <!-- overview -->
 
-{{< feature-state state="alpha" >}}
-{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
-
 Network plugins in Kubernetes come in a few flavors:
 
-* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
+* CNI plugins: adhere to the [Container Network Interface](https://github.com/containernetworking/cni) (CNI) specification, designed for interoperability.
+  * Kubernetes follows the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) release of the CNI specification.
 * Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
 
-
-
 <!-- body -->
 
 ## Installation
 
-The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
+The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as CRI manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
 
 * `cni-bin-dir`: Kubelet probes this directory for plugins on startup
 * `network-plugin`: The network plugin to use from `cni-bin-dir`.  It must match the name reported by a plugin probed from the plugin directory.  For CNI plugins, this is simply "cni".
@@ -166,9 +162,4 @@ This option is provided to the network-plugin; currently **only kubenet supports
 * `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
 * `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
 
-
-
 ## {{% heading "whatsnext" %}}
-
-
-
diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
index 76c72e74e4..d70f5cc9ff 100644
--- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -131,7 +131,7 @@ Adding an API does not directly let you affect the behavior of existing APIs (e.
 
 ### API Access Extensions
 
-When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
 
 Each of these steps offers extension points.
 
diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md
index 14ed2d5233..140cf2557a 100644
--- a/content/en/docs/concepts/extend-kubernetes/operator.md
+++ b/content/en/docs/concepts/extend-kubernetes/operator.md
@@ -35,7 +35,7 @@ Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
 concept lets you extend the cluster's behaviour without modifying the code
 of Kubernetes itself.
 Operators are clients of the Kubernetes API that act as controllers for
-a [Custom Resource](/docs/concepts/api-extension/custom-resources/).
+a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 
 ## An example Operator {#example}
 
@@ -122,7 +122,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
   * using [kubebuilder](https://book.kubebuilder.io/)
   * using [Metacontroller](https://metacontroller.app/) along with WebHooks that
     you implement yourself
-  * using the [Operator Framework](https://github.com/operator-framework/getting-started)
+  * using the [Operator Framework](https://operatorframework.io)
 * [Publish](https://operatorhub.io/) your operator for other people to use
 * Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
 * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
index b40ca7ee14..3aa9675788 100644
--- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
@@ -229,7 +229,7 @@ The following example describes how to map secret values into application enviro
 
 * If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
 * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
+* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
 * View [svc-cat.io](https://svc-cat.io/docs/).
 
 
diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md
index a52c470446..fb6351ec67 100755
--- a/content/en/docs/concepts/overview/_index.md
+++ b/content/en/docs/concepts/overview/_index.md
@@ -2,4 +2,6 @@
 title: "Overview"
 weight: 20
 description: Get a high-level outline of Kubernetes and the components it is built from.
+sitemap:
+  priority: 0.9
 ---
diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md
index 53e6b84c16..eb17e2dd7e 100644
--- a/content/en/docs/concepts/overview/components.md
+++ b/content/en/docs/concepts/overview/components.md
@@ -21,7 +21,7 @@ a complete and working Kubernetes cluster.
 
 Here's the diagram of a Kubernetes cluster with all the components tied together.
 
-![Components of Kubernetes](/images/docs/components-of-kubernetes.png)
+![Components of Kubernetes](/images/docs/components-of-kubernetes.svg)
 
 
 
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index aa09776753..ed89d1f5d1 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -16,30 +16,23 @@ card:
 
 The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
 is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server
-exposes an HTTP API that lets end users, different parts of your cluster, and external components
-communicate with one another.
+exposes an HTTP API that lets end users, different parts of your cluster, and
+external components communicate with one another.
 
 The Kubernetes API lets you query and manipulate the state of objects in the Kubernetes API
 (for example: Pods, Namespaces, ConfigMaps, and Events).
 
-API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
+Most operations can be performed through the
+[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
+command-line tools, such as
+[kubeadm](/docs/reference/setup-tools/kubeadm/), which in turn use the
+API. However, you can also access the API directly using REST calls.
+
+Consider using one of the [client libraries](/docs/reference/using-api/client-libraries/)
+if you are writing an application using the Kubernetes API.
 
 <!-- body -->
 
-## API changes
-
-Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
-Therefore, Kubernetes has design features to allow the Kubernetes API to continuously change and grow.
-The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
-compatibility for a length of time so that other projects have an opportunity to adapt.
-
-In general, new API resources and new resource fields can be added often and frequently.
-Elimination of resources or fields requires following the
-[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-
-What constitutes a compatible change, and how to change the API, are detailed in
-[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
-
 ## OpenAPI specification {#api-specification}
 
 Complete API details are documented using [OpenAPI](https://www.openapis.org/).
@@ -48,6 +41,7 @@ The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
 You can request the response format using request headers as follows:
 
 <table>
+  <caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
   <thead>
      <tr>
         <th>Header</th>
@@ -75,98 +69,69 @@ You can request the response format using request headers as follows:
         <td><em>serves </em><code>application/json</code></td>
      </tr>
   </tbody>
-  <caption>Valid request header values for OpenAPI v2 queries</caption>
 </table>
 
-Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
+Kubernetes implements an alternative Protobuf based serialization format that
+is primarily intended for intra-cluster communication. For more information
+about this format, see the [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) design proposal and the
+Interface Definition Language (IDL) files for each schema located in the Go
+packages that define the API objects.
 
-## API versioning
+## API changes
 
-To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
-multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/rbac.authorization.k8s.io/v1alpha1`.
+Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
+Therefore, Kubernetes has designed its features to allow the Kubernetes API to continuously change and grow.
+The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
+compatibility for a length of time so that other projects have an opportunity to adapt.
 
-Versioning is done at the API level rather than at the resource or field level to ensure that the
-API presents a clear, consistent view of system resources and behavior, and to enable controlling
-access to end-of-life and/or experimental APIs.
+In general, new API resources and new resource fields can be added often and frequently.
+Elimination of resources or fields requires following the
+[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
 
-The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
+What constitutes a compatible change, and how to change the API, are detailed in
+[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
 
-Note that API versioning and Software versioning are only indirectly related.  The
-[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
-proposal describes the relationship between API versioning and software versioning.
+## API groups and versioning
 
-Different API versions imply different levels of stability and support.  The criteria for each level are described
-in more detail in the
-[API Changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
-documentation.  They are summarized here:
+To make it easier to eliminate fields or restructure resource representations,
+Kubernetes supports multiple API versions, each at a different API path, such
+as `/api/v1` or `/apis/rbac.authorization.k8s.io/v1alpha1`.
 
-- Alpha level:
-  - The version names contain `alpha` (e.g. `v1alpha1`).
-  - May be buggy.  Enabling the feature may expose bugs.  Disabled by default.
-  - Support for feature may be dropped at any time without notice.
-  - The API may change in incompatible ways in a later software release without notice.
-  - Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
-- Beta level:
-  - The version names contain `beta` (e.g. `v2beta3`).
-  - Code is well tested.  Enabling the feature is considered safe.  Enabled by default.
-  - Support for the overall feature will not be dropped, though details may change.
-  - The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release.  When this happens,
-    we will provide instructions for migrating to the next version.  This may require deleting, editing, and re-creating
-    API objects.  The editing process may require some thought.   This may require downtime for applications that rely on the feature.
-  - Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases.  If you have
-    multiple clusters which can be upgraded independently, you may be able to relax this restriction.
-  - **Please do try our beta features and give feedback on them!  Once they exit beta, it may not be practical for us to make more changes.**
-- Stable level:
-  - The version name is `vX` where `X` is an integer.
-  - Stable versions of features will appear in released software for many subsequent versions.
+Versioning is done at the API level rather than at the resource or field level
+to ensure that the API presents a clear, consistent view of system resources
+and behavior, and to enable controlling access to end-of-life and/or
+experimental APIs.
 
-## API groups
+To make it easier to evolve and to extend its API, Kubernetes implements
+[API groups](/docs/reference/using-api/#api-groups) that can be
+[enabled or disabled](/docs/reference/using-api/#enabling-or-disabling).
 
-To make it easier to extend its API, Kubernetes implements [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
-The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
+API resources are distinguished by their API group, resource type, namespace
+(for namespaced resources), and name. The API server may serve the same
+underlying data through multiple API version and handle the conversion between
+API versions transparently. All these different versions are actually
+representations of the same resource. For example, suppose there are two
+versions `v1` and `v1beta1` for the same resource. An object created by the
+`v1beta1` version can then be read, updated, and deleted by either the
+`v1beta1` or the `v1` versions.
 
-There are several API groups in a cluster:
+Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
+for more details on the API version level definitions.
 
-1. The *core* group, also referred to as the *legacy* group, is at the REST path `/api/v1` and uses `apiVersion: v1`.
+## API Extension
 
-1. *Named* groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
-   (e.g. `apiVersion: batch/v1`). The Kubernetes [API reference](/docs/reference/kubernetes-api/) has a
-   full list of available API groups.
-
-There are two paths to extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/):
-
-1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
-   lets you declaratively define how the API server should provide your chosen resource API.
-1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/)
-   and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
-   to make it seamless for clients.
-
-## Enabling or disabling API groups
-
-Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `--runtime-config`
-as a command line option to the kube-apiserver.
-
-`--runtime-config` accepts comma separated values. For example: to disable batch/v1, set
-`--runtime-config=batch/v1=false`; to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`.
-The flag accepts comma separated set of key=value pairs describing runtime configuration of the API server.
-
-{{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
-kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
-
-## Persistence
-
-Kubernetes stores its serialized state in terms of the API resources by writing them into
-{{< glossary_tooltip term_id="etcd" >}}.
+The Kubernetes API can be extended in one of two ways:
 
+1. [Custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+   let you declaratively define how the API server should provide your chosen resource API.
+1. You can also extend the Kubernetes API by implementing an
+   [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 
 ## {{% heading "whatsnext" %}}
 
-[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes
-how the cluster manages authentication and authorization for API access.
-
-Overall API conventions are described in the
-[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
-document.
-
-API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
+- Learn how to extend the Kubernetes API by adding your own
+  [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
+- [Controlling Access To The Kubernetes API](/docs/concepts/security/controlling-access/) describes
+  how the cluster manages authentication and authorization for API access.
+- Learn about API endpoints, resource types and samples by reading
+  [API Reference](/docs/reference/kubernetes-api/).
diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md
index 418ee3d644..f3c4a1da02 100644
--- a/content/en/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/en/docs/concepts/overview/what-is-kubernetes.md
@@ -10,6 +10,8 @@ weight: 10
 card:
   name: concepts
   weight: 10
+sitemap:
+  priority: 0.9
 ---
 
 <!-- overview -->
@@ -36,7 +38,7 @@ Virtualization allows better utilization of resources in a physical server and a
 
 Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware.
 
-**Container deployment era:** Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
+**Container deployment era:** Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
 
 Containers have become popular because they provide extra benefits, such as:
 
@@ -92,4 +94,3 @@ Kubernetes:
 
 *   Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
 *   Ready to [Get Started](/docs/setup/)?
-
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index ab447cdcd6..716955ca06 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -91,9 +91,9 @@ and the `spec` format for a Deployment can be found in
 
 ## {{% heading "whatsnext" %}}
 
-* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
 * Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
-* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
+* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
+* [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.
 
 
 
diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md
index 822935978c..f8530ce546 100644
--- a/content/en/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/labels.md
@@ -188,7 +188,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
 Some Kubernetes objects, such as [`services`](/docs/concepts/services-networking/service/)
 and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationcontroller/),
 also use label selectors to specify sets of other resources, such as
-[pods](/docs/concepts/workloads/pods/pod/).
+[pods](/docs/concepts/workloads/pods/).
 
 #### Service and ReplicationController
 
diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
index 004c18ad2c..f078cb8636 100644
--- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
@@ -28,9 +28,6 @@ resource can only be in one namespace.
 
 Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
 
-In future versions of Kubernetes, objects in the same namespace will have the same
-access control policies by default.
-
 It is not necessary to use multiple namespaces just to separate slightly different
 resources, such as different versions of the same software: use
 [labels](/docs/concepts/overview/working-with-objects/labels) to distinguish
diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md
index 22cac5f2a2..299d681d1d 100644
--- a/content/en/docs/concepts/policy/pod-security-policy.md
+++ b/content/en/docs/concepts/policy/pod-security-policy.md
@@ -140,13 +140,17 @@ For a complete example of authorizing a PodSecurityPolicy, see
 
 ### Troubleshooting
 
-- The [Controller Manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) must be run
-against [the secured API port](/docs/reference/access-authn-authz/controlling-access/),
-and must not have superuser permissions. Otherwise requests would bypass
-authentication and authorization modules, all PodSecurityPolicy objects would be
-allowed, and users would be able to create privileged containers. For more details
-on configuring Controller Manager authorization, see
-[Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
+- The [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+  must be run against the secured API port and must not have superuser permissions. See
+  [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
+  to learn about API server access controls.  
+  If the controller manager connected through the trusted API port (also known as the
+  `localhost` listener), requests would bypass authentication and authorization modules;
+  all PodSecurityPolicy objects would be allowed, and users would be able to create grant
+  themselves the ability to create privileged containers.
+
+  For more details on configuring controller manager authorization, see
+  [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
 
 ## Policy Order
 
diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md
index 6a29cb1741..8758603fed 100644
--- a/content/en/docs/concepts/policy/resource-quotas.md
+++ b/content/en/docs/concepts/policy/resource-quotas.md
@@ -18,17 +18,17 @@ Resource quotas are a tool for administrators to address this concern.
 A resource quota, defined by a `ResourceQuota` object, provides constraints that limit
 aggregate resource consumption per namespace.  It can limit the quantity of objects that can
 be created in a namespace by type, as well as the total amount of compute resources that may
-be consumed by resources in that project.
+be consumed by resources in that namespace.
 
 Resource quotas work like this:
 
 - Different teams work in different namespaces.  Currently this is voluntary, but
   support for making this mandatory via ACLs is planned.
 
-- The administrator creates one `ResourceQuota` for each namespace.
+- The administrator creates one ResourceQuota for each namespace.
 
 - Users create resources (pods, services, etc.) in the namespace, and the quota system
-  tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`.
+  tracks usage to ensure it does not exceed hard resource limits defined in a ResourceQuota.
 
 - If creating or updating a resource violates a quota constraint, the request will fail with HTTP
   status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
@@ -40,7 +40,7 @@ Resource quotas work like this:
   See the [walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
   for an example of how to avoid this problem.
 
-The name of a `ResourceQuota` object must be a valid
+The name of a ResourceQuota object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 Examples of policies that could be created using namespaces and quotas are:
@@ -58,11 +58,11 @@ Neither contention nor changes to quota will affect already created resources.
 ## Enabling Resource Quota
 
 Resource Quota support is enabled by default for many Kubernetes distributions.  It is
-enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as
+enabled when the API server `--enable-admission-plugins=` flag has `ResourceQuota` as
 one of its arguments.
 
 A resource quota is enforced in a particular namespace when there is a
-`ResourceQuota` in that namespace.
+ResourceQuota in that namespace.
 
 ## Compute Resource Quota
 
@@ -76,6 +76,9 @@ The following resource types are supported:
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
+| `hugepages-<size>` | Across all pods in a non-terminal state, the number of huge page requests of the specified size cannot exceed this value. |
+| `cpu` | Same as `requests.cpu` |
+| `memory` | Same as `requests.memory` |
 
 ### Resource Quota For Extended Resources
 
@@ -103,8 +106,8 @@ In addition, you can limit consumption of storage resources based on associated
 | Resource Name | Description |
 | --------------------- | ----------------------------------------------------------- |
 | `requests.storage` | Across all persistent volume claims, the sum of storage requests cannot exceed this value. |
-| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value. |
+| `persistentvolumeclaims` | The total number of [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the `<storage-class-name>`, the sum of storage requests cannot exceed this value. |
 | `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | Across all persistent volume claims associated with the storage-class-name, the total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
 
 For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
@@ -119,12 +122,15 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f
 | ------------------------------- |----------------------------------------------------------- |
 | `requests.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage requests cannot exceed this value. |
 | `limits.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage limits cannot exceed this value. |
+| `ephemeral-storage` | Same as `requests.ephemeral-storage`. |
 
 ## Object Count Quota
 
-The 1.9 release added support to quota all standard namespaced resource types using the following syntax:
+You can set quota for the total number of certain resources of all standard,
+namespaced resource types using the following syntax:
 
-* `count/<resource>.<group>`
+* `count/<resource>.<group>` for resources from non-core groups
+* `count/<resource>` for resources from the core group
 
 Here is an example set of resources users may want to put under object count quota:
 
@@ -138,33 +144,30 @@ Here is an example set of resources users may want to put under object count quo
 * `count/statefulsets.apps`
 * `count/jobs.batch`
 * `count/cronjobs.batch`
-* `count/deployments.extensions`
 
-The 1.15 release added support for custom resources using the same syntax.
+The same syntax can be used for custom resources.
 For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`.
 
 When using `count/*` resource quota, an object is charged against the quota if it exists in server storage.
 These types of quotas are useful to protect against exhaustion of storage resources.  For example, you may
-want to quota the number of secrets in a server given their large size.  Too many secrets in a cluster can
-actually prevent servers and controllers from starting!  You may choose to quota jobs to protect against
-a poorly configured cronjob creating too many jobs in a namespace causing a denial of service.
-
-Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources.
-In addition, it is possible to further constrain quota for particular resources by their type.
+want to limit the number of Secrets in a server given their large size. Too many Secrets in a cluster can
+actually prevent servers and controllers from starting. You can set a quota for Jobs to protect against
+a poorly configured CronJob. CronJobs that create too many Jobs in a namespace can lead to a denial of service.
 
+It is also possible to do generic object count quota on a limited set of resources.
 The following types are supported:
 
 | Resource Name | Description |
 | ------------------------------- | ------------------------------------------------- |
-| `configmaps` | The total number of config maps that can exist in the namespace. |
-| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `pods` | The total number of pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
-| `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. |
-| `resourcequotas` | The total number of [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) that can exist in the namespace. |
-| `services` | The total number of services that can exist in the namespace. |
-| `services.loadbalancers` | The total number of services of type load balancer that can exist in the namespace. |
-| `services.nodeports` | The total number of services of type node port that can exist in the namespace. |
-| `secrets` | The total number of secrets that can exist in the namespace. |
+| `configmaps` | The total number of ConfigMaps that can exist in the namespace. |
+| `persistentvolumeclaims` | The total number of [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
+| `pods` | The total number of Pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
+| `replicationcontrollers` | The total number of ReplicationControllers that can exist in the namespace. |
+| `resourcequotas` | The total number of ResourceQuotas that can exist in the namespace. |
+| `services` | The total number of Services that can exist in the namespace. |
+| `services.loadbalancers` | The total number of Services of type `LoadBalancer` that can exist in the namespace. |
+| `services.nodeports` | The total number of Services of type `NodePort` that can exist in the namespace. |
+| `secrets` | The total number of Secrets that can exist in the namespace. |
 
 For example, `pods` quota counts and enforces a maximum on the number of `pods`
 created in a single namespace that are not terminal. You might want to set a `pods`
@@ -173,7 +176,7 @@ exhausts the cluster's supply of Pod IPs.
 
 ## Quota Scopes
 
-Each quota can have an associated set of scopes.  A quota will only measure usage for a resource if it matches
+Each quota can have an associated set of `scopes`. A quota will only measure usage for a resource if it matches
 the intersection of enumerated scopes.
 
 When a scope is added to the quota, it limits the number of resources it supports to those that pertain to the scope.
@@ -185,22 +188,60 @@ Resources specified on the quota outside of the allowed set results in a validat
 | `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` |
 | `BestEffort` | Match pods that have best effort quality of service. |
 | `NotBestEffort` | Match pods that do not have best effort quality of service. |
+| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). |
 
-The `BestEffort` scope restricts a quota to tracking the following resource: `pods`
+The `BestEffort` scope restricts a quota to tracking the following resource:
 
-The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources:
-
-* `cpu`
-* `limits.cpu`
-* `limits.memory`
-* `memory`
 * `pods`
+
+The `Terminating`, `NotTerminating`, `NotBestEffort` and `PriorityClass`
+scopes restrict a quota to tracking the following resources:
+
+* `pods`
+* `cpu`
+* `memory`
 * `requests.cpu`
 * `requests.memory`
+* `limits.cpu`
+* `limits.memory`
+
+Note that you cannot specify both the `Terminating` and the `NotTerminating`
+scopes in the same quota, and you cannot specify both the `BestEffort` and
+`NotBestEffort` scopes in the same quota either.
+
+The `scopeSelector` supports the following values in the `operator` field:
+
+* `In`
+* `NotIn`
+* `Exists`
+* `DoesNotExist`
+
+When using one of the following values as the `scopeName` when defining the
+`scopeSelector`, the `operator` must be `Exists`. 
+
+* `Terminating`
+* `NotTerminating`
+* `BestEffort`
+* `NotBestEffort`
+
+If the `operator` is `In` or `NotIn`, the `values` field must have at least
+one value. For example:
+
+```yaml
+  scopeSelector:
+    matchExpressions:
+      - scopeName: PriorityClass
+        operator: In
+        values:
+          - middle
+```
+
+If the `operator` is `Exists` or `DoesNotExist`, the `values` field must *NOT* be
+specified.
 
 ### Resource Quota Per PriorityClass
 
-{{< feature-state for_k8s_version="v1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.17" state="stable" >}}
 
 Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority).
 You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector`
@@ -208,6 +249,19 @@ field in the quota spec.
 
 A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod.
 
+When quota is scoped for priority class using `scopeSelector` field, quota object is restricted to track only following resources:
+
+* `pods`
+* `cpu`
+* `memory`
+* `ephemeral-storage`
+* `limits.cpu`
+* `limits.memory`
+* `limits.ephemeral-storage`
+* `requests.cpu`
+* `requests.memory`
+* `requests.ephemeral-storage`
+
 This example creates a quota object and matches it with pods at specific priorities. The example
 works as follows:
 
@@ -270,7 +324,7 @@ Apply the YAML using `kubectl create`.
 kubectl create -f ./quota.yml
 ```
 
-```shell
+```
 resourcequota/pods-high created
 resourcequota/pods-medium created
 resourcequota/pods-low created
@@ -282,7 +336,7 @@ Verify that `Used` quota is `0` using `kubectl describe quota`.
 kubectl describe quota
 ```
 
-```shell
+```
 Name:       pods-high
 Namespace:  default
 Resource    Used  Hard
@@ -347,7 +401,7 @@ the other two quotas are unchanged.
 kubectl describe quota
 ```
 
-```shell
+```
 Name:       pods-high
 Namespace:  default
 Resource    Used  Hard
@@ -375,13 +429,6 @@ memory      0     20Gi
 pods        0     10
 ```
 
-`scopeSelector` supports the following values in the `operator` field:
-
-* `In`
-* `NotIn`
-* `Exist`
-* `DoesNotExist`
-
 ## Requests compared to Limits {#requests-vs-limits}
 
 When allocating compute resources, each container may specify a request and a limit value for either CPU or memory.
@@ -445,7 +492,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
 kubectl get quota --namespace=myspace
 ```
 
-```shell
+```
 NAME                    AGE
 compute-resources       30s
 object-counts           32s
@@ -455,7 +502,7 @@ object-counts           32s
 kubectl describe quota compute-resources --namespace=myspace
 ```
 
-```shell
+```
 Name:                    compute-resources
 Namespace:               myspace
 Resource                 Used  Hard
@@ -471,7 +518,7 @@ requests.nvidia.com/gpu  0     4
 kubectl describe quota object-counts --namespace=myspace
 ```
 
-```shell
+```
 Name:                   object-counts
 Namespace:              myspace
 Resource                Used    Hard
@@ -493,7 +540,7 @@ kubectl create namespace myspace
 ```
 
 ```shell
-kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
+kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
 ```
 
 ```shell
@@ -504,29 +551,29 @@ kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
 kubectl describe quota --namespace=myspace
 ```
 
-```shell
+```
 Name:                         test
 Namespace:                    myspace
 Resource                      Used  Hard
 --------                      ----  ----
-count/deployments.extensions  1     2
+count/deployments.apps        1     2
 count/pods                    2     3
-count/replicasets.extensions  1     4
+count/replicasets.apps        1     4
 count/secrets                 1     4
 ```
 
 ## Quota and Cluster Capacity
 
-`ResourceQuotas` are independent of the cluster capacity. They are
+ResourceQuotas are independent of the cluster capacity. They are
 expressed in absolute units.  So, if you add nodes to your cluster, this does *not*
 automatically give each namespace the ability to consume more resources.
 
 Sometimes more complex policies may be desired, such as:
 
-  - Proportionally divide total cluster resources among several teams.
-  - Allow each tenant to grow resource usage as needed, but have a generous
-    limit to prevent accidental resource exhaustion.
-  - Detect demand from one namespace, add nodes, and increase quota.
+- Proportionally divide total cluster resources among several teams.
+- Allow each tenant to grow resource usage as needed, but have a generous
+  limit to prevent accidental resource exhaustion.
+- Detect demand from one namespace, add nodes, and increase quota.
 
 Such policies could be implemented using `ResourceQuotas` as building blocks, by
 writing a "controller" that watches the quota usage and adjusts the quota
@@ -537,14 +584,16 @@ restrictions around nodes: pods from several namespaces may run on the same node
 
 ## Limit Priority Class consumption by default
 
-It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists.
+It may be desired that pods at a particular priority, eg. "cluster-services", 
+should be allowed in a namespace, if and only if, a matching quota object exists.
 
-With this mechanism, operators will be able to restrict usage of certain high priority classes to a limited number of namespaces and not every namespace will be able to consume these priority classes by default.
+With this mechanism, operators are able to restrict usage of certain high
+priority classes to a limited number of namespaces and not every namespace
+will be able to consume these priority classes by default.
 
-To enforce this, kube-apiserver flag `--admission-control-config-file` should be used to pass path to the following configuration file:
+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
@@ -560,30 +609,10 @@ plugins:
         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:
-    - resource: pods
-      matchScopes:
-      - scopeName: PriorityClass
-        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:
+
 ```yaml
     scopeSelector:
       matchExpressions:
@@ -592,13 +621,9 @@ For example:
         values: ["cluster-services"]
 ```
 
-See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information.
-
-## Example
-
-See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
-
 ## {{% heading "whatsnext" %}}
 
 - See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
-
+- See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
+- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md).
+- See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
index a30efc6ef6..5123f34ca3 100644
--- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -73,17 +73,7 @@ verify that it worked by running `kubectl get pods -o wide` and looking at the
 ## Interlude: built-in node labels {#built-in-node-labels}
 
 In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
-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-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)
+with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/) for a list of these.
 
 {{< note >}}
 The value of these labels is cloud provider specific and is not guaranteed to be reliable.
@@ -210,8 +200,8 @@ The affinity on this pod defines one pod affinity rule and one pod anti-affinity
 while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The
 pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone
 as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run
-on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V
-such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and
+on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V
+such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and
 value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
 rule says that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
 label having key "security" and value "S2". See the
diff --git a/content/en/docs/concepts/scheduling-eviction/eviction-policy.md b/content/en/docs/concepts/scheduling-eviction/eviction-policy.md
new file mode 100644
index 0000000000..b63c729696
--- /dev/null
+++ b/content/en/docs/concepts/scheduling-eviction/eviction-policy.md
@@ -0,0 +1,24 @@
+---
+title: Eviction Policy
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+This page is an overview of Kubernetes' policy for eviction.
+
+<!-- body -->
+
+## Eviction Policy
+
+The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} proactively monitors for
+and prevents total starvation of a compute resource. In those cases, the `kubelet` can reclaim
+the starved resource by failing one or more Pods. When the `kubelet` fails
+a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
+If the evicted Pod is managed by a Deployment, the Deployment creates another Pod
+to be scheduled by Kubernetes.
+
+## {{% heading "whatsnext" %}}
+
+- Learn how to [configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) with eviction signals and thresholds.
diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
index 19e22707b8..a3e548d237 100644
--- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -33,7 +33,7 @@ kube-scheduler is designed so that, if you want and need to, you can
 write your own scheduling component and use that instead.
 
 For every newly created pod or other unscheduled pods, kube-scheduler
-selects an optimal node for them to run on.  However, every container in
+selects an optimal node for them to run on. However, every container in
 pods has different requirements for resources and every pod also has
 different requirements. Therefore, existing nodes need to be filtered
 according to the specific scheduling requirements.
@@ -77,12 +77,9 @@ one of these at random.
 There are two supported ways to configure the filtering and scoring behavior
 of the scheduler:
 
-1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to
-  configure _Predicates_ for filtering and _Priorities_ for scoring.
-1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you
-  to configure Plugins that implement different scheduling stages, including:
-  `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
-  can also configure the kube-scheduler to run different profiles.
+
+1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to configure _Predicates_ for filtering and _Priorities_ for scoring.
+1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you to configure Plugins that implement different scheduling stages, including: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You can also configure the kube-scheduler to run different profiles.
 
 
 ## {{% heading "whatsnext" %}}
@@ -92,7 +89,7 @@ of the scheduler:
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
 * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
-* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
+* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
 * Learn about scheduling of Pods that use volumes in:
   * [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
   * [Storage Capacity Tracking](/docs/concepts/storage/storage-capacity/)
diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md
similarity index 100%
rename from content/en/docs/concepts/configuration/pod-overhead.md
rename to content/en/docs/concepts/scheduling-eviction/pod-overhead.md
diff --git a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md
new file mode 100644
index 0000000000..0679e1fd8b
--- /dev/null
+++ b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -0,0 +1,223 @@
+---
+reviewers:
+- bsalamat
+- k82cn
+- ahg-g
+title: Resource Bin Packing for Extended Resources
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+The kube-scheduler can be configured to enable bin packing of resources along
+with extended resources using `RequestedToCapacityRatioResourceAllocation`
+priority function. Priority functions can be used to fine-tune the
+kube-scheduler as per custom needs. 
+
+<!-- body -->
+
+## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
+
+Kubernetes allows the users to specify the resources along with weights for
+each resource to score nodes based on the request to capacity ratio. This
+allows users to bin pack extended resources by using appropriate parameters
+and improves the utilization of scarce resources in large clusters. The
+behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
+can be controlled by a configuration option called
+`requestedToCapacityRatioArguments`. This argument consists of two parameters
+`shape` and `resources`. The `shape` parameter allows the user to tune the
+function as least requested or most requested based on `utilization` and
+`score` values.  The `resources` parameter consists of `name` of the resource
+to be considered during scoring and `weight` specify the weight of each
+resource.
+
+Below is an example configuration that sets
+`requestedToCapacityRatioArguments` to bin packing behavior for extended
+resources `intel.com/foo` and `intel.com/bar`.
+
+```yaml
+apiVersion: v1
+kind: Policy
+# ...
+priorities:
+  # ...
+  - name: RequestedToCapacityRatioPriority
+    weight: 2
+    argument:
+      requestedToCapacityRatioArguments:
+        shape:
+          - utilization: 0
+            score: 0
+          - utilization: 100
+            score: 10
+        resources:
+          - name: intel.com/foo
+            weight: 3
+          - name: intel.com/bar
+            weight: 5
+```
+
+**This feature is disabled by default**
+
+### Tuning the Priority Function
+
+`shape` is used to specify the behavior of the
+`RequestedToCapacityRatioPriority` function.
+
+```yaml
+shape:
+ - utilization: 0
+   score: 0
+ - utilization: 100
+   score: 10
+```
+
+The above arguments give the node a `score` of 0 if `utilization` is 0% and 10 for
+`utilization` 100%, thus enabling bin packing behavior. To enable least
+requested the score value must be reversed as follows.
+
+```yaml
+shape:
+  - utilization: 0
+    score: 100
+  - utilization: 100
+    score: 0
+```
+
+`resources` is an optional parameter which defaults to:
+
+``` yaml
+resources:
+  - name: CPU
+    weight: 1
+  - name: Memory
+    weight: 1
+```
+
+It can be used to add extended resources as follows: 
+
+```yaml
+resources:
+  - name: intel.com/foo
+    weight: 5
+  - name: CPU
+    weight: 3
+  - name: Memory
+    weight: 1
+```
+
+The `weight` parameter is optional and is set to 1 if not specified. Also, the
+`weight` cannot be set to a negative value.
+
+### Node scoring for capacity allocation
+
+This section is intended for those who want to understand the internal details
+of this feature.
+Below is an example of how the node score is calculated for a given set of values.
+
+Requested resources:
+
+```
+intel.com/foo : 2
+Memory: 256MB
+CPU: 2
+```
+
+Resource weights:
+
+```
+intel.com/foo : 5
+Memory: 1
+CPU: 3
+```
+
+FunctionShapePoint {{0, 0}, {100, 10}}
+
+Node 1 spec:
+
+```
+Available:
+  intel.com/foo: 4
+  Memory: 1 GB
+  CPU: 8
+
+Used:
+  intel.com/foo: 1
+  Memory: 256MB
+  CPU: 1
+```
+
+Node score:
+
+```
+intel.com/foo  = resourceScoringFunction((2+1),4)
+               = (100 - ((4-3)*100/4)
+               = (100 - 25)
+               = 75                       # requested + used = 75% * available
+               = rawScoringFunction(75) 
+               = 7                        # floor(75/10) 
+
+Memory         = resourceScoringFunction((256+256),1024)
+               = (100 -((1024-512)*100/1024))
+               = 50                       # requested + used = 50% * available
+               = rawScoringFunction(50)
+               = 5                        # floor(50/10)
+
+CPU            = resourceScoringFunction((2+1),8)
+               = (100 -((8-3)*100/8))
+               = 37.5                     # requested + used = 37.5% * available
+               = rawScoringFunction(37.5)
+               = 3                        # floor(37.5/10)
+
+NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
+            =  5
+```
+
+Node 2 spec:
+
+```
+Available:
+  intel.com/foo: 8
+  Memory: 1GB
+  CPU: 8
+Used:
+  intel.com/foo: 2
+  Memory: 512MB
+  CPU: 6
+```
+
+Node score:
+
+```
+intel.com/foo  = resourceScoringFunction((2+2),8)
+               =  (100 - ((8-4)*100/8)
+               =  (100 - 50)
+               =  50
+               =  rawScoringFunction(50)
+               = 5
+
+Memory         = resourceScoringFunction((256+512),1024)
+               = (100 -((1024-768)*100/1024))
+               = 75
+               = rawScoringFunction(75)
+               = 7
+
+CPU            = resourceScoringFunction((2+6),8)
+               = (100 -((8-8)*100/8))
+               = 100
+               = rawScoringFunction(100)
+               = 10
+
+NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
+            =  7
+
+```
+
+## {{% heading "whatsnext" %}}
+
+- Read more about the [scheduling framework](/docs/concepts/scheduling-eviction/scheduling-framework/)
+- Read more about [scheduler configuration](/docs/reference/scheduling/config/)
+
diff --git a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
index 06f535a574..932e076dfc 100644
--- a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@@ -3,7 +3,7 @@ reviewers:
 - bsalamat
 title: Scheduler Performance Tuning
 content_type: concept
-weight: 70
+weight: 80
 ---
 
 <!-- overview -->
@@ -48,17 +48,13 @@ To change the value, edit the kube-scheduler configuration file (this is likely
 to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
 
 After you have made this change, you can run
+
 ```bash
-kubectl get componentstatuses
-```
-to verify that the kube-scheduler component is healthy. The output is similar to:
-```
-NAME                 STATUS    MESSAGE             ERROR
-controller-manager   Healthy   ok
-scheduler            Healthy   ok
-...
+kubectl get pods -n kube-system | grep kube-scheduler
 ```
 
+to verify that the kube-scheduler component is healthy.
+
 ## Node scoring threshold {#percentage-of-nodes-to-score}
 
 To improve scheduling performance, the kube-scheduler can stop looking for
diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
index de67c75016..61b6619d01 100644
--- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
+++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
@@ -3,7 +3,7 @@ reviewers:
 - ahg-g
 title: Scheduling Framework
 content_type: concept
-weight: 60
+weight: 70
 ---
 
 <!-- overview -->
@@ -18,7 +18,7 @@ scheduling "core" simple and maintainable. Refer to the [design proposal of the
 scheduling framework][kep] for more technical information on the design of the
 framework.
 
-[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
+[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md
 
 
 
@@ -78,7 +78,7 @@ called for that node. Nodes may be evaluated concurrently.
 ### PostFilter {#post-filter}
 
 These plugins are called after Filter phase, but only when no feasible nodes
-were found for the node. Plugins are called in their configured order. If
+were found for the pod. Plugins are called in their configured order. If
 any postFilter plugin marks the node as `Schedulable`, the remaining plugins
 will not be called. A typical PostFilter implementation is preemption, which
 tries to make the pod schedulable by preempting other Pods.
diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
index 03b628be86..079024c9d6 100644
--- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -32,15 +32,15 @@ You add a taint to a node using [kubectl taint](/docs/reference/generated/kubect
 For example,
 
 ```shell
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes node1 key1=value1:NoSchedule
 ```
 
-places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
+places a taint on node `node1`. The taint has key `key1`, value `value1`, and taint effect `NoSchedule`.
 This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
 
 To remove the taint added by the command above, you can run:
 ```shell
-kubectl taint nodes node1 key:NoSchedule-
+kubectl taint nodes node1 key1=value1:NoSchedule-
 ```
 
 You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
@@ -49,15 +49,15 @@ to schedule onto `node1`:
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Equal"
-  value: "value"
+  value: "value1"
   effect: "NoSchedule"
 ```
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Exists"
   effect: "NoSchedule"
 ```
@@ -80,7 +80,7 @@ There are two special cases:
 An empty `key` with operator `Exists` matches all keys, values and effects which means this
 will tolerate everything.
 
-An empty `effect` matches all effects with key `key`.
+An empty `effect` matches all effects with key `key1`.
 
 {{< /note >}}
 
diff --git a/content/en/docs/reference/access-authn-authz/controlling-access.md b/content/en/docs/concepts/security/controlling-access.md
similarity index 58%
rename from content/en/docs/reference/access-authn-authz/controlling-access.md
rename to content/en/docs/concepts/security/controlling-access.md
index e0273177aa..62dc273cf7 100644
--- a/content/en/docs/reference/access-authn-authz/controlling-access.md
+++ b/content/en/docs/concepts/security/controlling-access.md
@@ -4,7 +4,6 @@ reviewers:
 - lavalamp
 title: Controlling Access to the Kubernetes API
 content_type: concept
-weight: 5
 ---
 
 <!-- overview -->
@@ -12,7 +11,7 @@ This page provides an overview of controlling access to the Kubernetes API.
 
 
 <!-- body -->
-Users [access the API](/docs/tasks/access-application-cluster/access-cluster/) using `kubectl`,
+Users access the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) using `kubectl`,
 client libraries, or by making REST requests.  Both human users and
 [Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
 authorized for API access.
@@ -21,45 +20,46 @@ following diagram:
 
 ![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
 
-## Transport Security
+## Transport security
 
-In a typical Kubernetes cluster, the API serves on port 443.
-The API server presents a certificate. This certificate is
-often self-signed, so `$USER/.kube/config` on the user's machine typically
-contains the root certificate for the API server's certificate, which when specified
-is used in place of the system default root certificate.  This certificate is typically
-automatically written into your `$USER/.kube/config` when you create a cluster yourself
-using `kube-up.sh`.  If the cluster has multiple users, then the creator needs to share
-the certificate with other users.
+In a typical Kubernetes cluster, the API serves on port 443, protected by TLS.
+The API server presents a certificate. This certificate may be signed using
+a private certificate authority (CA), or based on a public key infrastructure linked
+to a generally recognized CA.
+
+If your cluster uses a private certificate authority, you need a copy of that CA
+certifcate configured into your `~/.kube/config` on the client, so that you can
+trust the connection and be confident it was not intercepted.
+
+Your client can present a TLS client certificate at this stage.
 
 ## Authentication
 
 Once TLS is established, the HTTP request moves to the Authentication step.
 This is shown as step **1** in the diagram.
 The cluster creation script or cluster admin configures the API server to run
-one or more Authenticator Modules.
-Authenticators are described in more detail [here](/docs/reference/access-authn-authz/authentication/).
+one or more Authenticator modules.
+Authenticators are described in more detail in
+[Authentication](/docs/reference/access-authn-authz/authentication/).
 
-The input to the authentication step is the entire HTTP request, however, it typically
+The input to the authentication step is the entire HTTP request; however, it typically
 just examines the headers and/or client certificate.
 
-Authentication modules include Client Certificates, Password, and Plain Tokens,
-Bootstrap Tokens, and JWT Tokens (used for service accounts).
+Authentication modules include client certificates, password, and plain tokens,
+bootstrap tokens, and JSON Web Tokens (used for service accounts).
 
 Multiple authentication modules can be specified, in which case each one is tried in sequence,
 until one of them succeeds.
 
-On GCE, Client Certificates, Password, Plain Tokens, and JWT Tokens are all enabled.
-
 If the request cannot be authenticated, it is rejected with HTTP status code 401.
 Otherwise, the user is authenticated as a specific `username`, and the user name
 is available to subsequent steps to use in their decisions.  Some authenticators
 also provide the group memberships of the user, while other authenticators
 do not.
 
-While Kubernetes uses `usernames` for access control decisions and in request logging,
-it does not have a `user` object nor does it store usernames or other information about
-users in its object store.
+While Kubernetes uses usernames for access control decisions and in request logging,
+it does not have a `User` object nor does it store usernames or other information about
+users in its API.
 
 ## Authorization
 
@@ -101,16 +101,16 @@ If Bob makes a request to write (`create` or `update`) to the objects in the `pr
 
 Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
 
-Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configured the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403).
+Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configure the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403).
 
-To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization Overview](/docs/reference/access-authn-authz/authorization/).
+To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization](/docs/reference/access-authn-authz/authorization/).
 
 
-## Admission Control
+## Admission control
 
-Admission Control Modules are software modules that can modify or reject requests.
-In addition to the attributes available to Authorization Modules, Admission
-Control Modules can access the contents of the object that is being created or modified.
+Admission Control modules are software modules that can modify or reject requests.
+In addition to the attributes available to Authorization modules, Admission
+Control modules can access the contents of the object that is being created or modified.
 
 Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
 Admission controllers do not act on requests that merely read objects.
@@ -118,26 +118,26 @@ When multiple admission controllers are configured, they are called in order.
 
 This is shown as step **3** in the diagram.
 
-Unlike Authentication and Authorization Modules, if any admission controller module
+Unlike Authentication and Authorization modules, if any admission controller module
 rejects, then the request is immediately rejected.
 
 In addition to rejecting objects, admission controllers can also set complex defaults for
 fields.
 
-The available Admission Control Modules are described [here](/docs/reference/access-authn-authz/admission-controllers/).
+The available Admission Control modules are described in [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
 
 Once a request passes all admission controllers, it is validated using the validation routines
 for the corresponding API object, and then written to the object store (shown as step **4**).
 
 
-## API Server Ports and IPs
+## API server ports and IPs
 
 The previous discussion applies to requests sent to the secure port of the API server
 (the typical case).  The API server can actually serve on 2 ports:
 
 By default the Kubernetes API server serves HTTP on 2 ports:
 
-  1. `Localhost Port`:
+  1. `localhost` port:
 
       - is intended for testing and bootstrap, and for other components of the master node
         (scheduler, controller-manager) to talk to the API
@@ -148,7 +148,7 @@ By default the Kubernetes API server serves HTTP on 2 ports:
       - request handled by admission control module(s).
       - protected by need to have host access
 
-  2. `Secure Port`:
+  2. “Secure port”:
 
       - use whenever possible
       - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
@@ -158,8 +158,27 @@ By default the Kubernetes API server serves HTTP on 2 ports:
       - request handled by admission control module(s).
       - authentication and authorization modules run.
 
-When the cluster is created by `kube-up.sh`, on Google Compute Engine (GCE),
-and on several other cloud providers, the API server serves on port 443.  On
-GCE, a firewall rule is configured on the project to allow external HTTPS
-access to the API. Other cluster setup methods vary.
+## {{% heading "whatsnext" %}}
 
+Read more documentation on authentication, authorization and API access control:
+
+- [Authenticating](/docs/reference/access-authn-authz/authentication/)
+   - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+   - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [Authorization](/docs/reference/access-authn-authz/authorization/)
+   - [Role Based Access Control](/docs/reference/access-authn-authz/rbac/)
+   - [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/)
+   - [Node Authorization](/docs/reference/access-authn-authz/node/)
+   - [Webhook Authorization](/docs/reference/access-authn-authz/webhook/)
+- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
+     and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
+- Service accounts
+  - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
+  - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
+
+You can learn about:
+- how Pods can use
+  [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
+  to obtain API credentials.
diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md
index 98776c7199..fe9129c109 100644
--- a/content/en/docs/concepts/security/overview.md
+++ b/content/en/docs/concepts/security/overview.md
@@ -103,7 +103,7 @@ areas of security concerns and recommendations for securing workloads running in
 Area of Concern for Workload Security | Recommendation |
 ------------------------------ | --------------------- |
 RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
-Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
+Authentication | https://kubernetes.io/docs/concepts/security/controlling-access/
 Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
 Pod Security Policies | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
 Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
@@ -147,8 +147,8 @@ Learn about related Kubernetes security topics:
 
 * [Pod security standards](/docs/concepts/security/pod-security-standards/)
 * [Network policies for Pods](/docs/concepts/services-networking/network-policies/)
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
 * [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
-* [API access control](/docs/reference/access-authn-authz/controlling-access/)
 * [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
 * [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
 * [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 2dddc711a9..18c1b7e862 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -292,7 +292,7 @@ Containers at runtime. Security contexts are defined as part of the Pod and cont
 in the Pod manifest, and represent parameters to the container runtime.
 
 Security policies are control plane mechanisms to enforce specific settings in the Security Context,
-as well as other parameters outside the Security Contex. As of February 2020, the current native
+as well as other parameters outside the Security Context. As of February 2020, the current native
 solution for enforcing these security policies is [Pod Security
 Policy](/docs/concepts/policy/pod-security-policy/) - a mechanism for centrally enforcing security
 policy on Pods across a cluster. Other alternatives for enforcing security policy are being
diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md
index a4b8211043..1a55acf3d8 100644
--- a/content/en/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/en/docs/concepts/services-networking/dns-pod-service.md
@@ -181,7 +181,7 @@ When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the P
 {{< note >}}
 In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
 
-If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FDQN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
+If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
 {{< /note >}}
 
 ### Pod's DNS Policy
diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md
index aa249566b9..234e16dc25 100644
--- a/content/en/docs/concepts/services-networking/dual-stack.md
+++ b/content/en/docs/concepts/services-networking/dual-stack.md
@@ -47,6 +47,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
 
    * kube-apiserver:
       * `--feature-gates="IPv6DualStack=true"`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
    * kube-controller-manager:
       * `--feature-gates="IPv6DualStack=true"`
       * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
@@ -97,7 +98,7 @@ On cloud providers which support IPv6 enabled external load balancers, setting t
 
 ## Egress Traffic
 
-The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
+The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
 
 ## Known Issues
 
diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md
index 5f2522ae7e..b028139c1d 100644
--- a/content/en/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/en/docs/concepts/services-networking/endpoint-slices.md
@@ -23,7 +23,7 @@ Endpoints.
 
 The Endpoints API has provided a simple and straightforward way of
 tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
-and {{< glossary_tooltip text="Services" term_id="service" >}} have grown to handle
+and {{< glossary_tooltip text="Services" term_id="service" >}} have grown to handle and
 send more traffic to more backend Pods, limitations of that original API became
 more visible.
 Most notably, those included challenges with scaling to larger numbers of
@@ -114,8 +114,8 @@ of the labels with the same names on the corresponding Node.
 Most often, the control plane (specifically, the endpoint slice
 {{< glossary_tooltip text="controller" term_id="controller" >}}) creates and
 manages EndpointSlice objects. There are a variety of other use cases for
-EndpointSlices, such as service mesh implementations, that could result in othe
-rentities or controllers managing additional sets of EndpointSlices.
+EndpointSlices, such as service mesh implementations, that could result in other
+entities or controllers managing additional sets of EndpointSlices.
 
 To ensure that multiple entities can manage EndpointSlices without interfering
 with each other, Kubernetes defines the
diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md
index 3b375f7421..dcfba66a40 100644
--- a/content/en/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/en/docs/concepts/services-networking/ingress-controllers.md
@@ -22,12 +22,14 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
 
 ## Additional controllers
 
+{{% thirdparty-content %}}
+
 * [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/).
 * [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](https://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). 
-* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
+* [AWS Load Balancer Controller](https://github.com/kubernetes-sigs/aws-load-balancer-controller) (formerly known as AWS ALB Ingress Controller) enables ingress using [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/).
 * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
   provided and supported by VMware.
 * Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
@@ -44,9 +46,9 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
 * [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
   [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
-* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
+* [Traefik](https://github.com/traefik/traefik) is a fully featured ingress controller
   ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
-  support by [Containous](https://containo.us/services).
+  support by [Traefik Labs](https://traefik.io).
 
 ## Using multiple Ingress controllers
 
@@ -72,4 +74,3 @@ Make sure you review your ingress controller's documentation to understand the c
 * Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
 * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
 
-
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index d3e60cccbe..3977cbc233 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -29,15 +29,26 @@ For clarity, this guide defines the following terms:
 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
 Traffic routing is controlled by rules defined on the Ingress resource.
 
-```none
-    internet
-        |
-   [ Ingress ]
-   --|-----|--
-   [ Services ]
-```
+Here is a simple example where an Ingress sends all its traffic to one Service:
+{{< mermaid >}}
+graph LR;
+  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress];
+  ingress-->|routing rule|service[Service];
+  subgraph cluster
+  ingress;
+  service-->pod1[Pod];
+  service-->pod2[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service,pod1,pod2 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
-An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
+
+An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
 
 An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
 uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) or
@@ -45,7 +56,7 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
 
 ## Prerequisites
 
-You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
+You must have an [Ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
 
 You may need to deploy an Ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). You can choose from a number of
 [Ingress controllers](/docs/concepts/services-networking/ingress-controllers).
@@ -107,7 +118,7 @@ routed to your default backend.
 ### Resource backends {#resource-backend}
 
 A `Resource` backend is an ObjectRef to another Kubernetes resource within the
-same namespace of the Ingress object. A `Resource` is a mutually exclusive
+same namespace as the Ingress object. A `Resource` is a mutually exclusive
 setting with Service, and will fail validation if both are specified. A common
 usage for a `Resource` backend is to ingress data to an object storage backend
 with static assets.
@@ -235,7 +246,7 @@ IngressClass resource will ensure that new Ingresses without an
 If you have more than one IngressClass marked as the default for your cluster,
 the admission controller prevents creating new Ingress objects that don't have
 an `ingressClassName` specified. You can resolve this by ensuring that at most 1
-IngressClasses are marked as default in your cluster.
+IngressClass is marked as default in your cluster.
 {{< /caution >}}
 
 ## Types of Ingress
@@ -274,10 +285,25 @@ A fanout configuration routes traffic from a single IP address to more than one
 based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
 down to a minimum. For example, a setup like:
 
-```
-foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
-                                 / bar    service2:8080
-```
+{{< mermaid >}}
+graph LR;
+  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress, 178.91.123.132];
+  ingress-->|/foo|service1[Service service1:4200];
+  ingress-->|/bar|service2[Service service2:8080];
+  subgraph cluster
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 would require an Ingress such as:
 
@@ -321,11 +347,26 @@ you are using, you may need to create a default-http-backend
 
 Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
 
-```none
-foo.bar.com --|                 |-> foo.bar.com service1:80
-              | 178.91.123.132  |
-bar.foo.com --|                 |-> bar.foo.com service2:80
-```
+{{< mermaid >}}
+graph LR;
+  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress, 178.91.123.132];
+  ingress-->|Host: foo.bar.com|service1[Service service1:80];
+  ingress-->|Host: bar.foo.com|service2[Service service2:80];
+  subgraph cluster
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
+
 
 The following Ingress tells the backing load balancer to route requests based on
 the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
@@ -370,7 +411,14 @@ type: kubernetes.io/tls
 Referencing this secret in an Ingress tells the Ingress controller to
 secure the channel from the client to the load balancer using TLS. You need to make
 sure the TLS secret you created came from a certificate that contains a Common
-Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `sslexample.foo.com`.
+Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `https-example.foo.com`.
+
+{{< note >}}
+Keep in mind that TLS will not work on the default rule because the
+certificates would have to be issued for all the possible sub-domains. Therefore,
+`hosts` in the `tls` section need to explicitly match the `host` in the `rules`
+section.
+{{< /note >}}
 
 {{< codenew file="service/networking/tls-example-ingress.yaml" >}}
 
@@ -491,9 +539,8 @@ You can achieve the same outcome by invoking `kubectl replace -f` on a modified
 
 ## Failing across availability zones
 
-Techniques for spreading traffic across failure domains differs between cloud providers.
+Techniques for spreading traffic across failure domains differ between cloud providers.
 Please check the documentation of the relevant [Ingress controller](/docs/concepts/services-networking/ingress-controllers) for details.
-for details on deploying Ingress in a federated cluster.
 
 ## Alternatives
 
@@ -509,4 +556,3 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
 * Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
 * Learn about [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/)
 * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
-
diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md
index 21f9f596ce..7d417e4df1 100644
--- a/content/en/docs/concepts/services-networking/network-policies.md
+++ b/content/en/docs/concepts/services-networking/network-policies.md
@@ -10,12 +10,12 @@ weight: 50
 
 <!-- overview -->
 
-If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. 
+If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network.
 
 The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers:
 
 1. Other pods that are allowed (exception: a pod cannot block access to itself)
-2. Namespaces that are allowed 
+2. Namespaces that are allowed
 3. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node)
 
 When defining a pod- or namespace- based NetworkPolicy, you use a {{< glossary_tooltip text="selector" term_id="selector">}} to specify what traffic is allowed to and from the Pod(s) that match the selector.
@@ -219,14 +219,14 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
 You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
 {{< /note >}}
 
-# What you CAN'T do with network policy's (at least, not yet)
+## What you can't do with network policies (at least, not yet)
 
 As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.  Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API.
 
 - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy).
 - Anything TLS related (use a service mesh or ingress controller for this).
 - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically).
-- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their{{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
+- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
 - Creation or management of "Policy requests" that are fulfilled by a third party.
 - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this).
 - Advanced policy querying and reachability tooling.
diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md
index b7253a5bef..83b7850364 100644
--- a/content/en/docs/concepts/services-networking/service.md
+++ b/content/en/docs/concepts/services-networking/service.md
@@ -24,8 +24,8 @@ and can load-balance across them.
 
 ## Motivation
 
-Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are mortal.
-They are born and when they die, they are not resurrected.
+Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed
+to match the state of your cluster. Pods are nonpermanent resources.
 If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app,
 it can create and destroy Pods dynamically.
 
@@ -45,9 +45,9 @@ Enter _Services_.
 In Kubernetes, a Service is an abstraction which defines a logical set of Pods
 and a policy by which to access them (sometimes this pattern is called
 a micro-service). The set of Pods targeted by a Service is usually determined
-by a {{< glossary_tooltip text="selector" term_id="selector" >}}
-(see [below](#services-without-selectors) for why you might want a Service
-_without_ a selector).
+by a {{< glossary_tooltip text="selector" term_id="selector" >}}.
+To learn about other ways to define Service endpoints,
+see [Services _without_ selectors](#services-without-selectors).
 
 For example, consider a stateless image-processing backend which is running with
 3 replicas.  Those replicas are fungible&mdash;frontends do not care which backend
@@ -129,12 +129,12 @@ Services most commonly abstract access to Kubernetes Pods, but they can also
 abstract other kinds of backends.
 For example:
 
-  * You want to have an external database cluster in production, but in your
-    test environment you use your own databases.
-  * You want to point your Service to a Service in a different
-    {{< glossary_tooltip term_id="namespace" >}} or on another cluster.
-  * You are migrating a workload to Kubernetes. Whilst evaluating the approach,
-    you run only a proportion of your backends in Kubernetes.
+* You want to have an external database cluster in production, but in your
+  test environment you use your own databases.
+* You want to point your Service to a Service in a different
+  {{< glossary_tooltip term_id="namespace" >}} or on another cluster.
+* You are migrating a workload to Kubernetes. While evaluating the approach,
+  you run only a proportion of your backends in Kubernetes.
 
 In any of these scenarios you can define a Service _without_ a Pod selector.
 For example:
@@ -151,7 +151,7 @@ spec:
       targetPort: 9376
 ```
 
-Because this Service has no selector, the corresponding Endpoint object is *not*
+Because this Service has no selector, the corresponding Endpoint object is not
 created automatically. You can manually map the Service to the network address and port
 where it's running, by adding an Endpoint object manually:
 
@@ -188,6 +188,7 @@ selectors and uses DNS names instead. For more information, see the
 [ExternalName](#externalname) section later in this document.
 
 ### EndpointSlices
+
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 EndpointSlices are an API resource that can provide a more scalable alternative
@@ -204,9 +205,8 @@ described in detail in [EndpointSlices](/docs/concepts/services-networking/endpo
 
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-The AppProtocol field provides a way to specify an application protocol to be
-used for each Service port. The value of this field is mirrored by corresponding
-Endpoints and EndpointSlice resources.
+The `AppProtocol` field provides a way to specify an application protocol for each Service port.
+The value of this field is mirrored by corresponding Endpoints and EndpointSlice resources.
 
 ## Virtual IPs and service proxies
 
@@ -224,20 +224,19 @@ resolution?
 
 There are a few reasons for using proxying for Services:
 
- * There is a long history of DNS implementations not respecting record TTLs,
-   and caching the results of name lookups after they should have expired.
- * Some apps do DNS lookups only once and cache the results indefinitely.
- * Even if apps and libraries did proper re-resolution, the low or zero TTLs
-   on the DNS records could impose a high load on DNS that then becomes
-   difficult to manage.
+* There is a long history of DNS implementations not respecting record TTLs,
+  and caching the results of name lookups after they should have expired.
+* Some apps do DNS lookups only once and cache the results indefinitely.
+* Even if apps and libraries did proper re-resolution, the low or zero TTLs
+  on the DNS records could impose a high load on DNS that then becomes
+  difficult to manage.
 
 ### User space proxy mode {#proxy-mode-userspace}
 
 In this mode, kube-proxy watches the Kubernetes master for the addition and
 removal of Service and Endpoint objects. For each Service it opens a
 port (randomly chosen) on the local node.  Any connections to this "proxy port"
-are
-proxied to one of the Service's backend Pods (as reported via
+are proxied to one of the Service's backend Pods (as reported via
 Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into
 account when deciding which backend Pod to use.
 
@@ -255,7 +254,7 @@ In this mode, kube-proxy watches the Kubernetes control plane for the addition a
 removal of Service and Endpoint objects. For each Service, it installs
 iptables rules, which capture traffic to the Service's `clusterIP` and `port`,
 and redirect that traffic to one of the Service's
-backend sets.  For each Endpoint object, it installs iptables rules which
+backend sets. For each Endpoint object, it installs iptables rules which
 select a backend Pod.
 
 By default, kube-proxy in iptables mode chooses a backend at random.
@@ -298,12 +297,12 @@ higher throughput of network traffic.
 IPVS provides more options for balancing traffic to backend Pods;
 these are:
 
-- `rr`: round-robin
-- `lc`: least connection (smallest number of open connections)
-- `dh`: destination hashing
-- `sh`: source hashing
-- `sed`: shortest expected delay
-- `nq`: never queue
+* `rr`: round-robin
+* `lc`: least connection (smallest number of open connections)
+* `dh`: destination hashing
+* `sh`: source hashing
+* `sed`: shortest expected delay
+* `nq`: never queue
 
 {{< note >}}
 To run kube-proxy in IPVS mode, you must make IPVS available on
@@ -389,7 +388,7 @@ compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
 and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
 where the Service name is upper-cased and dashes are converted to underscores.
 
-For example, the Service `"redis-master"` which exposes TCP port 6379 and has been
+For example, the Service `redis-master` which exposes TCP port 6379 and has been
 allocated cluster IP address 10.0.0.11, produces the following environment
 variables:
 
@@ -423,19 +422,19 @@ Services and creates a set of DNS records for each one.  If DNS has been enabled
 throughout your cluster then all Pods should automatically be able to resolve
 Services by their DNS name.
 
-For example, if you have a Service called `"my-service"` in a Kubernetes
-Namespace `"my-ns"`, the control plane and the DNS Service acting together
-create a DNS record for `"my-service.my-ns"`. Pods in the `"my-ns"` Namespace
+For example, if you have a Service called `my-service` in a Kubernetes
+namespace `my-ns`, the control plane and the DNS Service acting together
+create a DNS record for `my-service.my-ns`. Pods in the `my-ns` namespace
 should be able to find it by simply doing a name lookup for `my-service`
-(`"my-service.my-ns"` would also work).
+(`my-service.my-ns` would also work).
 
-Pods in other Namespaces must qualify the name as `my-service.my-ns`. These names
+Pods in other namespaces must qualify the name as `my-service.my-ns`. These names
 will resolve to the cluster IP assigned for the Service.
 
 Kubernetes also supports DNS SRV (Service) records for named ports.  If the
-`"my-service.my-ns"` Service has a port named `"http"` with the protocol set to
+`my-service.my-ns` Service has a port named `http` with the protocol set to
 `TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover
-the port number for `"http"`, as well as the IP address.
+the port number for `http`, as well as the IP address.
 
 The Kubernetes DNS server is the only way to access `ExternalName` Services.
 You can find more information about `ExternalName` resolution in
@@ -467,9 +466,9 @@ For headless Services that do not define selectors, the endpoints controller doe
 not create `Endpoints` records. However, the DNS system looks for and configures
 either:
 
-  * CNAME records for [`ExternalName`](#externalname)-type Services.
-  * A records for any `Endpoints` that share a name with the Service, for all
-    other types.
+* CNAME records for [`ExternalName`](#externalname)-type Services.
+* A records for any `Endpoints` that share a name with the Service, for all
+  other types.
 
 ## Publishing Services (ServiceTypes) {#publishing-services-service-types}
 
@@ -481,26 +480,26 @@ The default is `ClusterIP`.
 
 `Type` values and their behaviors are:
 
-   * `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
-     makes the Service only reachable from within the cluster. This is the
-     default `ServiceType`.
-   * [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
-     (the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
-     routes, is automatically created.  You'll be able to contact the `NodePort` Service,
-     from outside the cluster,
-     by requesting `<NodeIP>:<NodePort>`.
-   * [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
-     provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
-     load balancer routes, are automatically created.
-   * [`ExternalName`](#externalname): Maps the Service to the contents of the
-     `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
+* `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
+  makes the Service only reachable from within the cluster. This is the
+  default `ServiceType`.
+* [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
+  (the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
+  routes, is automatically created.  You'll be able to contact the `NodePort` Service,
+  from outside the cluster,
+  by requesting `<NodeIP>:<NodePort>`.
+* [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
+  provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
+  load balancer routes, are automatically created.
+* [`ExternalName`](#externalname): Maps the Service to the contents of the
+  `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
+  with its value. No proxying of any kind is set up.
+  {{< note >}}You need either `kube-dns` version 1.7 or CoreDNS version 0.0.8 or higher
+  to use the `ExternalName` type.
+  {{< /note >}}
 
-     with its value. No proxying of any kind is set up.
-     {{< note >}}
-     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.
+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.
 
 ### Type NodePort {#nodeport}
 
@@ -509,7 +508,6 @@ allocates a port from a range specified by `--service-node-port-range` flag (def
 Each node proxies that port (the same port number on every Node) into your Service.
 Your Service reports the allocated port in its `.spec.ports[*].nodePort` field.
 
-
 If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s); this is supported since Kubernetes v1.10.
 This flag takes a comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 192.0.2.0/25) to specify IP address ranges that kube-proxy should consider as local to this node.
 
@@ -530,6 +528,7 @@ Note that this Service is visible as `<NodeIP>:spec.ports[*].nodePort`
 and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
 
 For example:
+
 ```yaml
 apiVersion: v1
 kind: Service
@@ -606,19 +605,21 @@ Specify the assigned IP address as loadBalancerIP. Ensure that you have updated
 {{< /note >}}
 
 #### Internal load balancer
+
 In a mixed environment it is sometimes necessary to route traffic from Services inside the same
 (virtual) network address block.
 
 In a split-horizon DNS environment you would need two Services to be able to route both external and internal traffic to your endpoints.
 
-You can achieve this by adding one the following annotations to a Service.
-The annotation to add depends on the cloud Service provider you're using.
+To set an internal load balancer, add one of the following annotations to your Service
+depending on the cloud Service provider you're using.
 
 {{< tabs name="service_tabs" >}}
 {{% tab name="Default" %}}
 Select one of the tabs.
 {{% /tab %}}
 {{% tab name="GCP" %}}
+
 ```yaml
 [...]
 metadata:
@@ -627,8 +628,10 @@ metadata:
         cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -637,8 +640,10 @@ metadata:
         service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -647,8 +652,10 @@ metadata:
         service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -657,8 +664,10 @@ metadata:
         service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -667,8 +676,10 @@ metadata:
         service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -677,8 +688,10 @@ metadata:
         service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Tencent Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -686,8 +699,10 @@ metadata:
     service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Alibaba Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -695,10 +710,10 @@ metadata:
     service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
 [...]
 ```
+
 {{% /tab %}}
 {{< /tabs >}}
 
-
 #### TLS support on AWS {#ssl-support-on-aws}
 
 For partial TLS / SSL support on clusters running on AWS, you can add three
@@ -823,7 +838,6 @@ to the value of `"true"`. The annotation
 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` can
 also be used to set maximum time, in seconds, to keep the existing connections open before deregistering the instances.
 
-
 ```yaml
     metadata:
       name: my-service
@@ -867,6 +881,10 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
         # health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
         # value. Defaults to 5, must be between 2 and 60
 
+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
+        # A list of existing security groups to be added to ELB created. Unlike the annotation
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB.
+
         service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
         # A list of additional security groups to be added to the ELB
 
@@ -991,6 +1009,7 @@ spec:
   type: ExternalName
   externalName: my.database.example.com
 ```
+
 {{< note >}}
 ExternalName accepts an IPv4 address string, but as a DNS names comprised of digits, not as an IP address. ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName
 is intended to specify a canonical DNS name. To hardcode an IP address, consider using
@@ -1045,7 +1064,7 @@ spec:
 
 ## Shortcomings
 
-Using the userspace proxy for VIPs, work at small to medium scale, but will
+Using the userspace proxy for VIPs works at small to medium scale, but will
 not scale to very large clusters with thousands of Services.  The
 [original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107)
 has more details on this.
@@ -1173,12 +1192,12 @@ of the Service.
 
 {{< note >}}
 You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service
-to expose HTTP / HTTPS Services.
+to expose HTTP/HTTPS Services.
 {{< /note >}}
 
 ### PROXY protocol
 
-If your cloud provider supports it (eg, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
+If your cloud provider supports it,
 you can use a Service in LoadBalancer mode to configure a load balancer outside
 of Kubernetes itself, that will forward connections prefixed with
 [PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
@@ -1189,6 +1208,7 @@ incoming connection, similar to this example
 ```
 PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 ```
+
 followed by the data from the client.
 
 ### SCTP
@@ -1227,13 +1247,8 @@ SCTP is not supported on Windows based nodes.
 The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
 {{< /warning >}}
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 * Read about [Ingress](/docs/concepts/services-networking/ingress/)
 * Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
-
-
diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md
index 26e60eb775..30029eae12 100644
--- a/content/en/docs/concepts/storage/ephemeral-volumes.md
+++ b/content/en/docs/concepts/storage/ephemeral-volumes.md
@@ -39,17 +39,16 @@ simplifies application deployment and management.
 
 Kubernetes supports several different kinds of ephemeral volumes for
 different purposes:
-- [emptyDir](/docs/concepts/volumes/#emptydir): empty at Pod startup,
+- [emptyDir](/docs/concepts/storage/volumes/#emptydir): empty at Pod startup,
   with storage coming locally from the kubelet base directory (usually
   the root disk) or RAM
-- [configMap](/docs/concepts/volumes/#configmap),
-  [downwardAPI](/docs/concepts/volumes/#downwardapi),
+- [configMap](/docs/concepts/storage/volumes/#configmap),
+  [downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
   [secret](/docs/concepts/storage/volumes/#secret): inject different
   kinds of Kubernetes data into a Pod
-- [CSI ephemeral
-  volumes](docs/concepts/storage/volumes/#csi-ephemeral-volumes):
-  similar to the previous volume kinds, but provided by special [CSI
-  drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
+- [CSI ephemeral volumes](#csi-ephemeral-volume):
+  similar to the previous volume kinds, but provided by special
+  [CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
   which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)
 - [generic ephemeral volumes](#generic-ephemeral-volumes), which
   can be provided by all storage drivers that also support persistent volumes
@@ -92,7 +91,7 @@ Conceptually, CSI ephemeral volumes are similar to `configMap`,
 scheduled onto a node. Kubernetes has no concept of rescheduling Pods
 anymore at this stage. Volume creation has to be unlikely to fail,
 otherwise Pod startup gets stuck. In particular, [storage capacity
-aware Pod scheduling](/docs/concepts/storage-capacity/) is *not*
+aware Pod scheduling](/docs/concepts/storage/storage-capacity/) is *not*
 supported for these volumes. They are currently also not covered by
 the storage resource usage limits of a Pod, because that is something
 that kubelet can only enforce for storage that it manages itself.
@@ -147,7 +146,7 @@ flexible:
   ([snapshotting](/docs/concepts/storage/volume-snapshots/),
   [cloning](/docs/concepts/storage/volume-pvc-datasource/),
   [resizing](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims),
-  and [storage capacity tracking](/docs/concepts/storage-capacity/).
+  and [storage capacity tracking](/docs/concepts/storage/storage-capacity/).
 
 Example:
 
@@ -181,8 +180,8 @@ spec:
 
 ### Lifecycle and PersistentVolumeClaim
 
-The key design idea is that the [parameters for a
-volume claim](/docs/reference/generated/kubernetes-api/#ephemeralvolumesource-v1alpha1-core)
+The key design idea is that the
+[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)
 are allowed inside a volume source of the Pod. Labels, annotations and
 the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
 created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index 8c2ad3ddb1..cf915bfa52 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -174,6 +174,47 @@ spec:
 
 However, the particular path specified in the custom recycler Pod template in the `volumes` part is replaced with the particular path of the volume that is being recycled.
 
+### Reserving a PersistentVolume
+
+The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) in the
+cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them.
+
+By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a binding between that specific PV and PVC.
+If the PersistentVolume exists and has not reserved PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and PersistentVolumeClaim will be bound.
+
+The binding happens regardless of some volume matching criteria, including node affinity.
+The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: foo-pvc
+  namespace: foo
+spec:
+  storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set
+  volumeName: foo-pv
+  ...
+```
+
+This method does not guarantee any binding privileges to the PersistentVolume. If other PersistentVolumeClaims could use the PV that you specify, you first need to reserve that storage volume. Specify the relevant PersistentVolumeClaim in the `claimRef` field of the PV so that other PVCs can not bind to it.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: foo-pv
+spec:
+  storageClassName: ""
+  claimRef:
+    name: foo-pvc
+    namespace: foo
+  ...
+```
+
+This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set
+to `Retain`, including cases where you are reusing an existing PV.
+
 ### Expanding Persistent Volumes Claims
 
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
index f2c8589db4..e6846c7ea4 100644
--- a/content/en/docs/concepts/storage/storage-classes.md
+++ b/content/en/docs/concepts/storage/storage-classes.md
@@ -94,7 +94,7 @@ run, what volume plugin it uses (including Flex), etc. The repository
 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 houses a library for writing external provisioners that implements the bulk of
 the specification. Some external provisioners are listed under the repository
-[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).
 
 For example, NFS doesn't provide an internal provisioner, but an external
 provisioner can be used. There are also cases when 3rd party storage
@@ -415,6 +415,21 @@ This internal provisioner of OpenStack is deprecated. Please use [the external c
 
 ### vSphere
 
+There are two types of provisioners for vSphere storage classes: 
+
+- [CSI provisioner](#csi-provisioner): `csi.vsphere.vmware.com`
+- [vCP provisioner](#vcp-provisioner): `kubernetes.io/vsphere-volume`
+
+In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#csi-migration-5).
+
+#### CSI Provisioner {#vsphere-provisioner-csi}
+
+The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml).
+
+#### vCP Provisioner 
+
+The following examples use the VMware Cloud Provider (vCP) StorageClass provisioner.  
+
 1. Create a StorageClass with a user specified disk format.
 
     ```yaml
@@ -819,4 +834,3 @@ Delaying volume binding allows the scheduler to consider all of a Pod's
 scheduling constraints when choosing an appropriate PersistentVolume for a
 PersistentVolumeClaim.
 
-
diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md
index 51da1b05ae..a93ea27e05 100644
--- a/content/en/docs/concepts/storage/volume-snapshots.md
+++ b/content/en/docs/concepts/storage/volume-snapshots.md
@@ -31,6 +31,8 @@ A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is simila
 
 `VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attributes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
 
+Volume snapshots provide Kubernetes users with a standardized way to copy a volume's contents at a particular point in time without creating an entirely new volume. This functionality enables, for example, database administrators to backup databases before performing edit or delete modifications.
+
 Users need to be aware of the following when using this feature:
 
 * API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
@@ -152,6 +154,4 @@ You can provision a new volume, pre-populated with data from a snapshot, by usin
 the *dataSource* field in the `PersistentVolumeClaim` object.
 
 For more details, see
-[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
-
-
+[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
\ No newline at end of file
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index 4ed310f6df..39410ec2e5 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -11,120 +11,80 @@ weight: 10
 
 <!-- overview -->
 
-On-disk files in a Container are ephemeral, which presents some problems for
-non-trivial applications when running in Containers.  First, when a Container
-crashes, kubelet will restart it, but the files will be lost - the
-Container starts with a clean state.  Second, when running Containers together
-in a `Pod` it is often necessary to share files between those Containers.  The
-Kubernetes `Volume` abstraction solves both of these problems.
-
-Familiarity with [Pods](/docs/concepts/workloads/pods/pod/) is suggested.
+On-disk files in a container are ephemeral, which presents some problems for
+non-trivial applications when running in containers. One problem
+is the loss of files when a container crashes. The kubelet restarts the container
+but with a clean state. A second problem occurs when sharing files
+between containers running together in a `Pod`.
+The Kubernetes {{< glossary_tooltip text="volume" term_id="volume" >}} abstraction
+solves both of these problems.
+Familiarity with [Pods](/docs/concepts/workloads/pods/) is suggested.
 
 <!-- body -->
 
 ## Background
 
-Docker also has a concept of
+Docker has a concept of
 [volumes](https://docs.docker.com/storage/), though it is
-somewhat looser and less managed.  In Docker, a volume is simply a directory on
-disk or in another Container.  Lifetimes are not managed and until very
-recently there were only local-disk-backed volumes.  Docker now provides volume
-drivers, but the functionality is very limited for now (e.g. as of Docker 1.7
-only one volume driver is allowed per Container and there is no way to pass
-parameters to volumes).
+somewhat looser and less managed. A Docker volume is a directory on
+disk or in another container. Docker provides volume
+drivers, but the functionality is somewhat limited.
 
-A Kubernetes volume, on the other hand, has an explicit lifetime - the same as
-the Pod that encloses it.  Consequently, a volume outlives any Containers that run
-within the Pod, and data is preserved across Container restarts. Of course, when a
-Pod ceases to exist, the volume will cease to exist, too.  Perhaps more
-importantly than this, Kubernetes supports many types of volumes, and a Pod can
-use any number of them simultaneously.
+Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}}
+can use any number of volume types simultaneously.
+Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond
+the lifetime of a pod. Consequently, a volume outlives any containers
+that run within the pod, and data is preserved across container restarts. When a
+pod ceases to exist, the volume is destroyed.
 
 At its core, a volume is just a directory, possibly with some data in it, which
-is accessible to the Containers in a Pod.  How that directory comes to be, the
+is accessible to the containers in a pod. How that directory comes to be, the
 medium that backs it, and the contents of it are determined by the particular
 volume type used.
 
-To use a volume, a Pod specifies what volumes to provide for the Pod (the
-`.spec.volumes`
-field) and where to mount those into Containers (the
-`.spec.containers[*].volumeMounts`
-field).
-
+To use a volume, specify the volumes to provide for the Pod in `.spec.volumes`
+and declare where to mount those volumes into containers in `.spec.containers[*].volumeMounts`.
 A process in a container sees a filesystem view composed from their Docker
-image and volumes.  The [Docker
-image](https://docs.docker.com/userguide/dockerimages/) is at the root of the
-filesystem hierarchy, and any volumes are mounted at the specified paths within
-the image.  Volumes can not mount onto other volumes or have hard links to
-other volumes.  Each Container in the Pod must independently specify where to
+image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/)
+is at the root of the filesystem hierarchy. Volumes mount at the specified paths within
+the image. Volumes can not mount onto other volumes or have hard links to
+other volumes. Each Container in the Pod's configuration must independently specify where to
 mount each volume.
 
-## Types of Volumes
+## Types of Volumes {#volume-types}
 
-Kubernetes supports several types of Volumes:
-
-   * [awsElasticBlockStore](#awselasticblockstore)
-   * [azureDisk](#azuredisk)
-   * [azureFile](#azurefile)
-   * [cephfs](#cephfs)
-   * [cinder](#cinder)
-   * [configMap](#configmap)
-   * [csi](#csi)
-   * [downwardAPI](#downwardapi)
-   * [emptyDir](#emptydir)
-   * [fc (fibre channel)](#fc)
-   * [flexVolume](#flexVolume)
-   * [flocker](#flocker)
-   * [gcePersistentDisk](#gcepersistentdisk)
-   * [gitRepo (deprecated)](#gitrepo)
-   * [glusterfs](#glusterfs)
-   * [hostPath](#hostpath)
-   * [iscsi](#iscsi)
-   * [local](#local)
-   * [nfs](#nfs)
-   * [persistentVolumeClaim](#persistentvolumeclaim)
-   * [projected](#projected)
-   * [portworxVolume](#portworxvolume)
-   * [quobyte](#quobyte)
-   * [rbd](#rbd)
-   * [scaleIO](#scaleio)
-   * [secret](#secret)
-   * [storageos](#storageos)
-   * [vsphereVolume](#vspherevolume)
-
-We welcome additional contributions.
+Kubernetes supports several types of volumes.
 
 ### awsElasticBlockStore {#awselasticblockstore}
 
-An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS) [EBS
-Volume](https://aws.amazon.com/ebs/) into your Pod.  Unlike
-`emptyDir`, which is erased when a Pod is removed, the contents of an EBS
-volume are preserved and the volume is merely unmounted.  This means that an
-EBS volume can be pre-populated with data, and that data can be "handed off"
-between Pods.
+An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS)
+[EBS volume](https://aws.amazon.com/ebs/) into your pod. Unlike
+`emptyDir`, which is erased when a pod is removed, the contents of an EBS
+volume are persisted and the volume is unmounted. This means that an
+EBS volume can be pre-populated with data, and that data can be shared between pods.
 
-{{< caution >}}
-You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
-{{< /caution >}}
+{{< note >}}
+You must create an EBS volume by using `aws ec2 create-volume` or the AWS API before you can use it.
+{{< /note >}}
 
 There are some restrictions when using an `awsElasticBlockStore` volume:
 
-* the nodes on which Pods are running must be AWS EC2 instances
-* those instances need to be in the same region and availability-zone as the EBS volume
+* the nodes on which pods are running must be AWS EC2 instances
+* those instances need to be in the same region and availability zone as the EBS volume
 * EBS only supports a single EC2 instance mounting a volume
 
-#### Creating an EBS volume
+#### Creating an AWS EBS volume
 
-Before you can use an EBS volume with a Pod, you need to create it.
+Before you can use an EBS volume with a pod, you need to create it.
 
 ```shell
 aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2
 ```
 
-Make sure the zone matches the zone you brought up your cluster in.  (And also check that the size and EBS volume
-type are suitable for your use!)
+Make sure the zone matches the zone you brought up your cluster in. Check that the size and EBS volume
+type are suitable for your use.
 
-#### AWS EBS Example configuration
+#### AWS EBS configuration example
 
 ```yaml
 apiVersion: v1
@@ -142,37 +102,39 @@ spec:
   - name: test-volume
     # This AWS EBS volume must already exist.
     awsElasticBlockStore:
-      volumeID: <volume-id>
+      volumeID: "<volume id>"
       fsType: ext4
 ```
 
-#### CSI Migration
+#### AWS EBS CSI migration
 
 {{< 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)
+The `CSIMigration` feature for `awsElasticBlockStore`, when enabled, redirects
+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`
-Beta features must be enabled.
+beta features must be enabled.
+
+#### AWS EBS CSI migration complete
 
-#### 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.
+To disable the `awsElasticBlockStore` storage plugin from being loaded by the controller manager
+and the kubelet, set the `CSIMigrationAWSComplete` flag to `true`. This feature requires the `ebs.csi.aws.com` Container Storage Interface (CSI) driver installed on all worker nodes.
 
 ### azureDisk {#azuredisk}
 
-A `azureDisk` is used to mount a Microsoft Azure [Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) into a Pod.
+The `azureDisk` volume type mounts a Microsoft Azure [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) into a pod.
 
-More details can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md).
+For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md).
 
-#### CSI Migration
+#### azureDisk CSI migration
 
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-The CSI Migration feature for azureDisk, when enabled, shims all plugin operations
+The `CSIMigration` feature for `azureDisk`, when enabled, redirects all plugin operations
 from the existing in-tree plugin to the `disk.csi.azure.com` Container
 Storage Interface (CSI) Driver. In order to use this feature, the [Azure Disk CSI
 Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
@@ -181,47 +143,46 @@ features must be enabled.
 
 ### azureFile {#azurefile}
 
-A `azureFile` is used to mount a Microsoft Azure File Volume (SMB 2.1 and 3.0)
-into a Pod.
+The `azureFile` volume type mounts a Microsoft Azure File volume (SMB 2.1 and 3.0)
+into a pod.
 
-More details can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md).
+For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md).
 
-#### CSI Migration
+#### azureFile CSI migration
 
 {{< feature-state for_k8s_version="v1.15" state="alpha" >}}
 
-The CSI Migration feature for azureFile, when enabled, shims all plugin operations
+The `CSIMigration` feature for `azureFile`, when enabled, redirects all plugin operations
 from the existing in-tree plugin to the `file.csi.azure.com` Container
 Storage Interface (CSI) Driver. In order to use this feature, the [Azure File CSI
 Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile`
-Alpha features must be enabled.
+alpha features must be enabled.
 
-### cephfs {#cephfs}
+### cephfs
 
 A `cephfs` volume allows an existing CephFS volume to be
-mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is
+mounted into your Pod. Unlike `emptyDir`, which is erased when a pod is
 removed, the contents of a `cephfs` volume are preserved and the volume is merely
-unmounted.  This means that a CephFS volume can be pre-populated with data, and
-that data can be "handed off" between Pods.  CephFS can be mounted by multiple
+unmounted. This means that a `cephfs` volume can be pre-populated with data, and
+that data can be shared between pods. The `cephfs` volume can be mounted by multiple
 writers simultaneously.
 
-{{< caution >}}
+{{< note >}}
 You must have your own Ceph server running with the share exported before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) for more details.
 
-### cinder {#cinder}
+### cinder
 
 {{< note >}}
-Prerequisite: Kubernetes with OpenStack Cloud Provider configured. For cloudprovider
-configuration please refer [cloud provider openstack](/docs/concepts/cluster-administration/cloud-providers/#openstack).
+Kubernetes must be configured with the OpenStack cloud provider.
 {{< /note >}}
 
-`cinder` is used to mount OpenStack Cinder Volume into your Pod.
+The `cinder` volume type is used to mount the OpenStack Cinder volume into your pod.
 
-#### Cinder Volume Example configuration
+#### Cinder volume configuration example
 
 ```yaml
 apiVersion: v1
@@ -239,33 +200,32 @@ spec:
   - name: test-volume
     # This OpenStack volume must already exist.
     cinder:
-      volumeID: <volume-id>
+      volumeID: "<volume id>"
       fsType: ext4
 ```
 
-#### CSI Migration
+#### OpenStack CSI migration
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-The CSI Migration feature for Cinder, when enabled, shims all plugin operations
+The `CSIMigration` feature for Cinder, when enabled, redirects all plugin operations
 from the existing in-tree plugin to the `cinder.csi.openstack.org` Container
 Storage Interface (CSI) Driver. In order to use this feature, the [Openstack Cinder CSI
 Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack`
-Beta features must be enabled.
+beta features must be enabled.
 
-### configMap {#configmap}
+### configMap
 
-The [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) resource
-provides a way to inject configuration data into Pods.
-The data stored in a `ConfigMap` object can be referenced in a volume of type
-`configMap` and then consumed by containerized applications running in a Pod.
+A [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)
+provides a way to inject configuration data into pods.
+The data stored in a ConfigMap can be referenced in a volume of type
+`configMap` and then consumed by containerized applications running in a pod.
 
-When referencing a `configMap` object, you can simply provide its name in the
-volume to reference it. You can also customize the path to use for a specific
-entry in the ConfigMap.
-For example, to mount the `log-config` ConfigMap onto a Pod called `configmap-pod`,
-you might use the YAML below:
+When referencing a ConfigMap, you provide the name of the ConfigMap in the
+volume. You can customize the path to use for a specific
+entry in the ConfigMap. The following configuration shows how to mount
+the `log-config` ConfigMap onto a Pod called `configmap-pod`:
 
 ```yaml
 apiVersion: v1
@@ -289,65 +249,61 @@ spec:
 ```
 
 The `log-config` ConfigMap is mounted as a volume, and all contents stored in
-its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`".
+its `log_level` entry are mounted into the Pod at path `/etc/config/log_level`.
 Note that this path is derived from the volume's `mountPath` and the `path`
 keyed with `log_level`.
 
-{{< caution >}}
-You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
-{{< /caution >}}
-
 {{< note >}}
-A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
-receive ConfigMap updates.
-{{< /note >}}
+* You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)
+  before you can use it.
 
-{{< note >}}
-Text data is exposed as files using the UTF-8 character encoding. To use some other character encoding, use binaryData.
-{{< /note >}}
+* A container using a ConfigMap as a [`subPath`](#using-subpath) volume mount will not
+  receive ConfigMap updates.
 
+* Text data is exposed as files using the UTF-8 character encoding. For other character encodings, use `binaryData`.
+{{< /note >}}
 
 ### downwardAPI {#downwardapi}
 
-A `downwardAPI` volume is used to make downward API data available to applications.
+A `downwardAPI` volume makes downward API data available to applications.
 It mounts a directory and writes the requested data in plain text files.
 
 {{< note >}}
-A Container using Downward API as a [subPath](#using-subpath) volume mount will not
-receive Downward API updates.
+A container using the downward API as a [`subPath`](#using-subpath) volume mount will not
+receive downward API updates.
 {{< /note >}}
 
-See the [`downwardAPI` volume example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)  for more details.
+See the [downward API example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) for more details.
 
 ### emptyDir {#emptydir}
 
-An `emptyDir` volume is first created when a Pod is assigned to a Node, and
-exists as long as that Pod is running on that node.  As the name says, it is
-initially empty.  Containers in the Pod can all read and write the same
+An `emptyDir` volume is first created when a Pod is assigned to a node, and
+exists as long as that Pod is running on that node. As the name says, the
+`emptyDir` volume is initially empty. All containers in the Pod can read and write the same
 files in the `emptyDir` volume, though that volume can be mounted at the same
-or different paths in each Container.  When a Pod is removed from a node for
-any reason, the data in the `emptyDir` is deleted forever.
+or different paths in each container. When a Pod is removed from a node for
+any reason, the data in the `emptyDir` is deleted permanently.
 
 {{< note >}}
-A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
+A container crashing does *not* remove a Pod from a node. The data in an `emptyDir` volume
+is safe across container crashes.
 {{< /note >}}
 
 Some uses for an `emptyDir` are:
 
 * scratch space, such as for a disk-based merge sort
 * checkpointing a long computation for recovery from crashes
-* holding files that a content-manager Container fetches while a webserver
-  Container serves the data
+* holding files that a content-manager container fetches while a webserver
+  container serves the data
 
-By default, `emptyDir` volumes are stored on whatever medium is backing the
-node - that might be disk or SSD or network storage, depending on your
-environment.  However, you can set the `emptyDir.medium` field to `"Memory"`
-to tell Kubernetes to mount a tmpfs (RAM-backed filesystem) for you instead.
+Depending on your environment, `emptyDir` volumes are stored on whatever medium that backs the
+node such as disk or SSD, or network storage. However, if you set the `emptyDir.medium` field
+to `"Memory"`, Kubernetes mounts a tmpfs (RAM-backed filesystem) for you instead.
 While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on
-node reboot and any files you write will count against your Container's
+node reboot and any files you write count against your container's
 memory limit.
 
-#### Example Pod
+#### emptyDir configuration example
 
 ```yaml
 apiVersion: v1
@@ -368,69 +324,72 @@ spec:
 
 ### fc (fibre channel) {#fc}
 
-An `fc` volume allows an existing fibre channel volume to be mounted in a Pod.
-You can specify single or multiple target World Wide Names using the parameter
-`targetWWNs` in your volume configuration. If multiple WWNs are specified,
+An `fc` volume type allows an existing fibre channel block storage volume
+to mount in a Pod. You can specify single or multiple target world wide names (WWNs)
+using the parameter `targetWWNs` in your Volume configuration. If multiple WWNs are specified,
 targetWWNs expect that those WWNs are from multi-path connections.
 
-{{< caution >}}
-You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
-{{< /caution >}}
+{{< note >}}
+You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs
+beforehand so that Kubernetes hosts can access them.
+{{< /note >}}
 
-See the [FC example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details.
+See the [fibre channel example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details.
 
-### flocker {#flocker}
+### flocker (deprecated) {#flocker}
 
-[Flocker](https://github.com/ClusterHQ/flocker) is an open-source clustered Container data volume manager. It provides management
+[Flocker](https://github.com/ClusterHQ/flocker) is an open-source, clustered
+container data volume manager. Flocker provides management
 and orchestration of data volumes backed by a variety of storage backends.
 
 A `flocker` volume allows a Flocker dataset to be mounted into a Pod. If the
 dataset does not already exist in Flocker, it needs to be first created with the Flocker
 CLI or by using the Flocker API. If the dataset already exists it will be
-reattached by Flocker to the node that the Pod is scheduled. This means data
-can be "handed off" between Pods as required.
+reattached by Flocker to the node that the pod is scheduled. This means data
+can be shared between pods as required.
 
-{{< caution >}}
+{{< note >}}
 You must have your own Flocker installation running before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) for more details.
 
-### gcePersistentDisk {#gcepersistentdisk}
+### gcePersistentDisk
 
 A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE)
-[Persistent Disk](https://cloud.google.com/compute/docs/disks) into your Pod.  Unlike
-`emptyDir`, which is erased when a Pod is removed, the contents of a PD are
-preserved and the volume is merely unmounted.  This means that a PD can be
-pre-populated with data, and that data can be "handed off" between Pods.
+[persistent disk](https://cloud.google.com/compute/docs/disks) (PD) into your Pod.
+Unlike `emptyDir`, which is erased when a pod is removed, the contents of a PD are
+preserved and the volume is merely unmounted. This means that a PD can be
+pre-populated with data, and that data can be shared between pods.
 
-{{< caution >}}
+{{< note >}}
 You must create a PD using `gcloud` or the GCE API or UI before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 There are some restrictions when using a `gcePersistentDisk`:
 
 * the nodes on which Pods are running must be GCE VMs
-* those VMs need to be in the same GCE project and zone as the PD
+* those VMs need to be in the same GCE project and zone as the persistent disk
 
-A feature of PD is that they can be mounted as read-only by multiple consumers
-simultaneously.  This means that you can pre-populate a PD with your dataset
-and then serve it in parallel from as many Pods as you need.  Unfortunately,
-PDs can only be mounted by a single consumer in read-write mode - no
-simultaneous writers allowed.
+One feature of GCE persistent disk is concurrent read-only access to a persistent disk.
+A `gcePersistentDisk` volume permits multiple consumers to simultaneously
+mount a persistent disk as read-only. This means that you can pre-populate a PD with your dataset
+and then serve it in parallel from as many Pods as you need. Unfortunately,
+PDs can only be mounted by a single consumer in read-write mode. Simultaneous
+writers are not allowed.
 
-Using a PD on a Pod controlled by a ReplicationController will fail unless
+Using a GCE persistent disk with a Pod controlled by a ReplicaSet will fail unless
 the PD is read-only or the replica count is 0 or 1.
 
-#### Creating a PD
+#### Creating a GCE persistent disk {#gce-create-persistent-disk}
 
-Before you can use a GCE PD with a Pod, you need to create it.
+Before you can use a GCE persistent disk with a Pod, you need to create it.
 
 ```shell
 gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk
 ```
 
-#### Example Pod
+#### GCE persistent disk configuration example
 
 ```yaml
 apiVersion: v1
@@ -452,18 +411,26 @@ spec:
       fsType: ext4
 ```
 
-#### Regional Persistent Disks
-The [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#repds) feature allows the creation of Persistent Disks that are available in two zones within the same region. In order to use this feature, the volume must be provisioned as a PersistentVolume; referencing the volume directly from a pod is not supported.
+#### Regional persistent disks
+
+The [Regional persistent disks](https://cloud.google.com/compute/docs/disks/#repds)
+feature allows the creation of persistent disks that are available in two zones
+within the same region. In order to use this feature, the volume must be provisioned
+as a PersistentVolume; referencing the volume directly from a pod is not supported.
 
 #### Manually provisioning a Regional PD PersistentVolume
-Dynamic provisioning is possible using a [StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce).
-Before creating a PersistentVolume, you must create the PD:
+
+Dynamic provisioning is possible using a
+[StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce).
+Before creating a PersistentVolume, you must create the persistent disk:
+
 ```shell
 gcloud compute disks create --size=500GB my-data-disk
-    --region us-central1
-    --replica-zones us-central1-a,us-central1-b
+  --region us-central1
+  --replica-zones us-central1-a,us-central1-b
 ```
-Example PersistentVolume spec:
+
+#### Regional persistent disk configuration example
 
 ```yaml
 apiVersion: v1
@@ -489,29 +456,28 @@ spec:
           - us-central1-b
 ```
 
-#### CSI Migration
+#### GCE CSI migration
 
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
-The CSI Migration feature for GCE PD, when enabled, shims all plugin operations
+The `CSIMigration` feature for GCE PD, when enabled, redirects 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`
-Beta features must be enabled.
+beta features must be enabled.
 
 ### gitRepo (deprecated) {#gitrepo}
 
 {{< warning >}}
-The gitRepo volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
+The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
 {{< /warning >}}
 
-A `gitRepo` volume is an example of what can be done as a volume plugin.  It
-mounts an empty directory and clones a git repository into it for your Pod to
-use.  In the future, such volumes may be moved to an even more decoupled model,
-rather than extending the Kubernetes API for every such use case.
+A `gitRepo` volume is an example of a volume plugin. This plugin
+mounts an empty directory and clones a git repository into this directory
+for your Pod to use.
 
-Here is an example of gitRepo volume:
+Here is an example of a `gitRepo` volume:
 
 ```yaml
 apiVersion: v1
@@ -532,19 +498,19 @@ spec:
       revision: "22f1d8406d464b0c0874075539c1f2e96c253775"
 ```
 
-### glusterfs {#glusterfs}
+### glusterfs
 
 A `glusterfs` volume allows a [Glusterfs](https://www.gluster.org) (an open
-source networked filesystem) volume to be mounted into your Pod.  Unlike
+source networked filesystem) volume to be mounted into your Pod. Unlike
 `emptyDir`, which is erased when a Pod is removed, the contents of a
-`glusterfs` volume are preserved and the volume is merely unmounted.  This
+`glusterfs` volume are preserved and the volume is merely unmounted. This
 means that a glusterfs volume can be pre-populated with data, and that data can
-be "handed off" between Pods.  GlusterFS can be mounted by multiple writers
+be shared between pods. GlusterFS can be mounted by multiple writers
 simultaneously.
 
-{{< caution >}}
+{{< note >}}
 You must have your own GlusterFS installation running before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) for more details.
 
@@ -556,17 +522,16 @@ powerful escape hatch for some applications.
 
 For example, some uses for a `hostPath` are:
 
-* running a Container that needs access to Docker internals; use a `hostPath`
+* running a container that needs access to Docker internals; use a `hostPath`
   of `/var/lib/docker`
-* running cAdvisor in a Container; use a `hostPath` of `/sys`
+* running cAdvisor in a container; use a `hostPath` of `/sys`
 * allowing a Pod to specify whether a given `hostPath` should exist prior to the
   Pod running, whether it should be created, and what it should exist as
 
-In addition to the required `path` property, user can optionally specify a `type` for a `hostPath` volume.
+In addition to the required `path` property, you can optionally specify a `type` for a `hostPath` volume.
 
 The supported values for field `type` are:
 
-
 | Value | Behavior |
 |:------|:---------|
 | | Empty string (default) is for backward compatibility, which means that no checks will be performed before mounting the hostPath volume. |
@@ -580,16 +545,14 @@ The supported values for field `type` are:
 
 Watch out when using this type of volume, because:
 
-* Pods with identical configuration (such as created from a podTemplate) may
+* Pods with identical configuration (such as created from a PodTemplate) may
   behave differently on different nodes due to different files on the nodes
-* when Kubernetes adds resource-aware scheduling, as is planned, it will not be
-  able to account for resources used by a `hostPath`
-* the files or directories created on the underlying hosts are only writable by root. You
+* The files or directories created on the underlying hosts are only writable by root. You
   either need to run your process as root in a
   [privileged Container](/docs/tasks/configure-pod-container/security-context/) or modify the file
   permissions on the host to be able to write to a `hostPath` volume
 
-#### Example Pod
+#### hostPath configuration example
 
 ```yaml
 apiVersion: v1
@@ -613,10 +576,13 @@ spec:
 ```
 
 {{< caution >}}
-It should be noted that the `FileOrCreate` mode does not create the parent directory of the file. If the parent directory of the mounted file does not exist, the pod fails to start. To ensure that this mode works, you can try to mount directories and files separately, as shown below.
+The `FileOrCreate` mode does not create the parent directory of the file. If the parent directory
+of the mounted file does not exist, the pod fails to start. To ensure that this mode works,
+you can try to mount directories and files separately, as shown in the
+[`FileOrCreate`configuration](#hostpath-fileorcreate-example).
 {{< /caution >}}
 
-#### Example Pod FileOrCreate
+#### hostPath FileOrCreate configuration example {#hostpath-fileorcreate-example}
 
 ```yaml
 apiVersion: v1
@@ -644,48 +610,46 @@ spec:
       type: FileOrCreate
 ```
 
-### iscsi {#iscsi}
+### iscsi
 
 An `iscsi` volume allows an existing iSCSI (SCSI over IP) volume to be mounted
-into your Pod.  Unlike `emptyDir`, which is erased when a Pod is removed, the
+into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the
 contents of an `iscsi` volume are preserved and the volume is merely
-unmounted.  This means that an iscsi volume can be pre-populated with data, and
-that data can be "handed off" between Pods.
+unmounted. This means that an iscsi volume can be pre-populated with data, and
+that data can be shared between pods.
 
-{{< caution >}}
+{{< note >}}
 You must have your own iSCSI server running with the volume created before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 A feature of iSCSI is that it can be mounted as read-only by multiple consumers
-simultaneously.  This means that you can pre-populate a volume with your dataset
-and then serve it in parallel from as many Pods as you need.  Unfortunately,
-iSCSI volumes can only be mounted by a single consumer in read-write mode - no
-simultaneous writers allowed.
+simultaneously. This means that you can pre-populate a volume with your dataset
+and then serve it in parallel from as many Pods as you need. Unfortunately,
+iSCSI volumes can only be mounted by a single consumer in read-write mode.
+Simultaneous writers are not allowed.
 
 See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) for more details.
 
-### local {#local}
-
-{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+### local
 
 A `local` volume represents a mounted local storage device such as a disk,
 partition or directory.
 
 Local volumes can only be used as a statically created PersistentVolume. Dynamic
-provisioning is not supported yet.
+provisioning is not supported.
 
-Compared to `hostPath` volumes, local volumes can be used in a durable and
-portable manner without manually scheduling Pods to nodes, as the system is aware
+Compared to `hostPath` volumes, `local` volumes are used in a durable and
+portable manner without manually scheduling pods to nodes. The system is aware
 of the volume's node constraints by looking at the node affinity on the PersistentVolume.
 
-However, local volumes are still subject to the availability of the underlying
+However, `local` volumes are subject to the availability of the underlying
 node and are not suitable for all applications. If a node becomes unhealthy,
-then the local volume will also become inaccessible, and a Pod using it will not
-be able to run. Applications using local volumes must be able to tolerate this
+then the `local` volume becomes inaccessible by the pod. The pod using this volume
+is unable to run. Applications using `local` volumes must be able to tolerate this
 reduced availability, as well as potential data loss, depending on the
 durability characteristics of the underlying disk.
 
-The following is an example of PersistentVolume spec using a `local` volume and
+The following example shows a PersistentVolume using a `local` volume and
 `nodeAffinity`:
 
 ```yaml
@@ -713,19 +677,19 @@ spec:
           - example-node
 ```
 
-PersistentVolume `nodeAffinity` is required when using local volumes. It enables
-the Kubernetes scheduler to correctly schedule Pods using local volumes to the
-correct node.
+You must set a PersistentVolume `nodeAffinity` when using `local` volumes.
+The Kubernetes scheduler uses the PersistentVolume `nodeAffinity` to schedule
+these Pods to the correct node.
 
 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
-[example](/docs/concepts/storage/storage-classes/#local). Delaying volume binding ensures
-that the PersistentVolumeClaim binding decision will also be evaluated with any
-other node constraints the Pod may have, such as node resource requirements, node
-selectors, Pod affinity, and Pod anti-affinity.
+`volumeBindingMode` set to `WaitForFirstConsumer`. For more details, see the
+local [StorageClass](/docs/concepts/storage/storage-classes/#local) example.
+Delaying volume binding ensures that the PersistentVolumeClaim binding decision
+will also be evaluated with any other node constraints the Pod may have,
+such as node resource requirements, node selectors, Pod affinity, and Pod anti-affinity.
 
 An external static provisioner can be run separately for improved management of
 the local volume lifecycle. Note that this provisioner does not support dynamic
@@ -739,52 +703,84 @@ user if the external static provisioner is not used to manage the volume
 lifecycle.
 {{< /note >}}
 
-### nfs {#nfs}
+### nfs
 
 An `nfs` volume allows an existing NFS (Network File System) share to be
-mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is
+mounted into a Pod. Unlike `emptyDir`, which is erased when a Pod is
 removed, the contents of an `nfs` volume are preserved and the volume is merely
-unmounted.  This means that an NFS volume can be pre-populated with data, and
-that data can be "handed off" between Pods.  NFS can be mounted by multiple
+unmounted. This means that an NFS volume can be pre-populated with data, and
+that data can be shared between pods. NFS can be mounted by multiple
 writers simultaneously.
 
-{{< caution >}}
+{{< note >}}
 You must have your own NFS server running with the share exported before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details.
 
 ### persistentVolumeClaim {#persistentvolumeclaim}
 
 A `persistentVolumeClaim` volume is used to mount a
-[PersistentVolume](/docs/concepts/storage/persistent-volumes/) into a Pod.  PersistentVolumes are a
-way for users to "claim" durable storage (such as a GCE PersistentDisk or an
+[PersistentVolume](/docs/concepts/storage/persistent-volumes/) into a Pod. PersistentVolumeClaims
+are a way for users to "claim" durable storage (such as a GCE PersistentDisk or an
 iSCSI volume) without knowing the details of the particular cloud environment.
 
-See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more
+See the information about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) for more
 details.
 
-### projected {#projected}
+### portworxVolume {#portworxvolume}
+
+A `portworxVolume` is an elastic block storage layer that runs hyperconverged with
+Kubernetes. [Portworx](https://portworx.com/use-case/kubernetes-storage/) fingerprints storage
+in a server, tiers based on capabilities, and aggregates capacity across multiple servers.
+Portworx runs in-guest in virtual machines or on bare metal Linux nodes.
+
+A `portworxVolume` can be dynamically created through Kubernetes or it can also
+be pre-provisioned and referenced inside a Pod.
+Here is an example Pod referencing a pre-provisioned Portworx volume:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-portworx-volume-pod
+spec:
+  containers:
+  - image: k8s.gcr.io/test-webserver
+    name: test-container
+    volumeMounts:
+    - mountPath: /mnt
+      name: pxvol
+  volumes:
+  - name: pxvol
+    # This Portworx volume must already exist.
+    portworxVolume:
+      volumeID: "pxvol"
+      fsType: "<fs-type>"
+```
+
+{{< note >}}
+Make sure you have an existing PortworxVolume with name `pxvol`
+before using it in the Pod.
+{{< /note >}}
+
+For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) examples.
+
+### projected
 
 A `projected` volume maps several existing volume sources into the same directory.
 
 Currently, the following types of volume sources can be projected:
 
-- [`secret`](#secret)
-- [`downwardAPI`](#downwardapi)
-- [`configMap`](#configmap)
-- `serviceAccountToken`
+* [`secret`](#secret)
+* [`downwardAPI`](#downwardapi)
+* [`configMap`](#configmap)
+* `serviceAccountToken`
 
 All sources are required to be in the same namespace as the Pod. For more details,
 see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md).
 
-The projection of service account tokens is a feature introduced in Kubernetes
-1.11 and promoted to Beta in 1.12.
-To enable this feature on 1.11, you need to explicitly set the `TokenRequestProjection`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to
-True.
-
-#### Example Pod with a secret, a downward API, and a configmap.
+#### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
 
 ```yaml
 apiVersion: v1
@@ -824,7 +820,7 @@ spec:
               path: my-group/my-config
 ```
 
-#### Example Pod with multiple secrets with a non-default permission mode set.
+#### Example configuration: secrets with a non-default permission mode set {#example-configuration-secrets-nondefault-permission-mode}
 
 ```yaml
 apiVersion: v1
@@ -867,7 +863,7 @@ parameters are nearly the same with two exceptions:
 
 When the `TokenRequestProjection` feature is enabled, you can inject the token
 for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
-into a Pod at a specified path. Below is an example:
+into a Pod at a specified path. For example:
 
 ```yaml
 apiVersion: v1
@@ -893,8 +889,8 @@ spec:
 ```
 
 The example Pod has a projected volume containing the injected service account
-token. This token can be used by Pod containers to access the Kubernetes API
-server, for example. The `audience` field contains the intended audience of the
+token. This token can be used by a Pod's containers to access the Kubernetes API
+server. The `audience` field contains the intended audience of the
 token. A recipient of the token must identify itself with an identifier specified
 in the audience of the token, and otherwise should reject the token. This field
 is optional and it defaults to the identifier of the API server.
@@ -906,96 +902,61 @@ option for the API server. The `path` field specifies a relative path to the mou
 of the projected volume.
 
 {{< note >}}
-A Container using a projected volume source as a [subPath](#using-subpath) volume mount will not
+A container using a projected volume source as a [`subPath`](#using-subpath) volume mount will not
 receive updates for those volume sources.
 {{< /note >}}
 
-### portworxVolume {#portworxvolume}
-
-A `portworxVolume` is an elastic block storage layer that runs hyperconverged with
-Kubernetes. [Portworx](https://portworx.com/use-case/kubernetes-storage/) fingerprints storage in a server, tiers based on capabilities,
-and aggregates capacity across multiple servers. Portworx runs in-guest in virtual machines or on bare metal Linux nodes.
-
-A `portworxVolume` can be dynamically created through Kubernetes or it can also
-be pre-provisioned and referenced inside a Kubernetes Pod.
-Here is an example Pod referencing a pre-provisioned PortworxVolume:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: test-portworx-volume-pod
-spec:
-  containers:
-  - image: k8s.gcr.io/test-webserver
-    name: test-container
-    volumeMounts:
-    - mountPath: /mnt
-      name: pxvol
-  volumes:
-  - name: pxvol
-    # This Portworx volume must already exist.
-    portworxVolume:
-      volumeID: "pxvol"
-      fsType: "<fs-type>"
-```
-
-{{< caution >}}
-Make sure you have an existing PortworxVolume with name `pxvol`
-before using it in the Pod.
-{{< /caution >}}
-
-More details and examples can be found [here](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md).
-
-### quobyte {#quobyte}
+### quobyte
 
 A `quobyte` volume allows an existing [Quobyte](https://www.quobyte.com) volume to
 be mounted into your Pod.
 
-{{< caution >}}
-You must have your own Quobyte setup running with the volumes
+{{< note >}}
+You must have your own Quobyte setup and running with the volumes
 created before you can use it.
-{{< /caution >}}
+{{< /note >}}
 
 Quobyte supports the {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}.
 CSI is the recommended plugin to use Quobyte volumes inside Kubernetes. Quobyte's
 GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte-csi) for deploying Quobyte using CSI, along with examples.
 
-### rbd {#rbd}
+### rbd
 
 An `rbd` volume allows a
-[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your
-Pod.  Unlike `emptyDir`, which is erased when a Pod is removed, the contents of
-a `rbd` volume are preserved and the volume is merely unmounted.  This
+[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/) (RBD) volume to mount into your
+Pod. Unlike `emptyDir`, which is erased when a pod is removed, the contents of
+an `rbd` volume are preserved and the volume is unmounted. This
 means that a RBD volume can be pre-populated with data, and that data can
-be "handed off" between Pods.
+be shared between pods.
 
-{{< caution >}}
-You must have your own Ceph installation running before you can use RBD.
-{{< /caution >}}
+{{< note >}}
+You must have a Ceph installation running before you can use RBD.
+{{< /note >}}
 
 A feature of RBD is that it can be mounted as read-only by multiple consumers
-simultaneously.  This means that you can pre-populate a volume with your dataset
-and then serve it in parallel from as many Pods as you need.  Unfortunately,
-RBD volumes can only be mounted by a single consumer in read-write mode - no
-simultaneous writers allowed.
+simultaneously. This means that you can pre-populate a volume with your dataset
+and then serve it in parallel from as many pods as you need. Unfortunately,
+RBD volumes can only be mounted by a single consumer in read-write mode.
+Simultaneous writers are not allowed.
 
-See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) for more details.
+See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)
+for more details.
 
-### scaleIO {#scaleio}
+### scaleIO (deprecated) {#scaleio}
 
-ScaleIO is a software-based storage platform that can use existing hardware to
+ScaleIO is a software-based storage platform that uses existing hardware to
 create clusters of scalable shared block networked storage. The `scaleIO` volume
-plugin allows deployed Pods to access existing ScaleIO
-volumes (or it can dynamically provision new volumes for persistent volume claims, see
-[ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)).
+plugin allows deployed pods to access existing ScaleIO
+volumes. For information about dynamically provisioning new volumes for
+persistent volume claims, see
+[ScaleIO persistent volumes](/docs/concepts/storage/persistent-volumes/#scaleio).
 
-{{< caution >}}
+{{< note >}}
 You must have an existing ScaleIO cluster already setup and
 running with the volumes created before you can use them.
-{{< /caution >}}
+{{< /note >}}
 
-The following is an example of Pod configuration with ScaleIO:
+The following example is a Pod configuration with ScaleIO:
 
 ```yaml
 apiVersion: v1
@@ -1022,49 +983,51 @@ spec:
       fsType: xfs
 ```
 
-For further detail, please see the [ScaleIO examples](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio).
+For further details, see the [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) examples.
 
-### secret {#secret}
+### secret
 
 A `secret` volume is used to pass sensitive information, such as passwords, to
-Pods.  You can store secrets in the Kubernetes API and mount them as files for
-use by Pods without coupling to Kubernetes directly.  `secret` volumes are
+Pods. You can store secrets in the Kubernetes API and mount them as files for
+use by pods without coupling to Kubernetes directly. `secret` volumes are
 backed by tmpfs (a RAM-backed filesystem) so they are never written to
 non-volatile storage.
 
-{{< caution >}}
-You must create a secret in the Kubernetes API before you can use it.
-{{< /caution >}}
+{{< note >}}
+You must create a Secret in the Kubernetes API before you can use it.
+{{< /note >}}
 
 {{< note >}}
-A Container using a Secret as a [subPath](#using-subpath) volume mount will not
+A container using a Secret as a [`subPath`](#using-subpath) volume mount will not
 receive Secret updates.
 {{< /note >}}
 
-Secrets are described in more detail [here](/docs/concepts/configuration/secret/).
+For more details, see [Configuring Secrets](/docs/concepts/configuration/secret/).
 
 ### storageOS {#storageos}
 
 A `storageos` volume allows an existing [StorageOS](https://www.storageos.com)
-volume to be mounted into your Pod.
+volume to mount into your Pod.
 
-StorageOS runs as a Container within your Kubernetes environment, making local
+StorageOS runs as a container within your Kubernetes environment, making local
 or attached storage accessible from any node within the Kubernetes cluster.
 Data can be replicated to protect against node failure. Thin provisioning and
 compression can improve utilization and reduce cost.
 
-At its core, StorageOS provides block storage to Containers, accessible via a file system.
+At its core, StorageOS provides block storage to containers, accessible from a file system.
 
 The StorageOS Container requires 64-bit Linux and has no additional dependencies.
 A free developer license is available.
 
 {{< caution >}}
-You must run the StorageOS Container on each node that wants to
+You must run the StorageOS container on each node that wants to
 access StorageOS volumes or that will contribute storage capacity to the pool.
 For installation instructions, consult the
 [StorageOS documentation](https://docs.storageos.com).
 {{< /caution >}}
 
+The following example is a Pod configuration with StorageOS:
+
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -1093,24 +1056,24 @@ spec:
         fsType: ext4
 ```
 
-For more information including Dynamic Provisioning and Persistent Volume Claims, please see the
+For more information about StorageOS, dynamic provisioning, and PersistentVolumeClaims, see the
 [StorageOS examples](https://github.com/kubernetes/examples/blob/master/volumes/storageos).
 
 ### vsphereVolume {#vspherevolume}
 
 {{< note >}}
-Prerequisite: Kubernetes with vSphere Cloud Provider configured. For cloudprovider
-configuration please refer [vSphere getting started guide](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/).
+You must configure the Kubernetes vSphere Cloud Provider. For cloudprovider
+configuration, refer to the [vSphere Getting Started guide](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/).
 {{< /note >}}
 
-A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod.  The contents
+A `vsphereVolume` is used to mount a vSphere VMDK volume into your Pod.  The contents
 of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore.
 
-{{< caution >}}
-You must create VMDK using one of the following methods before using with Pod.
-{{< /caution >}}
+{{< note >}}
+You must create vSphere VMDK volume using one of the following methods before using with a Pod.
+{{< /note >}}
 
-#### Creating a VMDK volume
+#### Creating a VMDK volume {#creating-vmdk-volume}
 
 Choose one of the following methods to create a VMDK.
 
@@ -1121,6 +1084,7 @@ First ssh into ESX, then use the following command to create a VMDK:
 ```shell
 vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
 ```
+
 {{% /tab %}}
 {{% tab name="Create using vmware-vdiskmanager" %}}
 Use the following command to create a VMDK:
@@ -1128,12 +1092,12 @@ Use the following command to create a VMDK:
 ```shell
 vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
 ```
+
 {{% /tab %}}
 
 {{< /tabs >}}
 
-
-#### vSphere VMDK Example configuration
+#### vSphere VMDK configuration example {#vsphere-vmdk-configuration}
 
 ```yaml
 apiVersion: v1
@@ -1155,22 +1119,22 @@ spec:
       fsType: ext4
 ```
 
-More examples can be found [here](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere).
+For more information, see the [vSphere volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) examples.
 
-#### CSI migration
+#### vSphere CSI migration {#vsphere-csi-migration}
 
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-The CSI Migration feature for vsphereVolume, when enabled, shims all plugin operations
-from the existing in-tree plugin to the `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this feature, the [vSphere CSI
-Driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)
+The `CSIMigration` feature for `vsphereVolume`, when enabled, redirects all plugin operations
+from the existing in-tree plugin to the `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this feature, the
+[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere`
 [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled.
 
 This also requires minimum vSphere vCenter/ESXi Version to be 7.0u1 and minimum HW Version to be VM version 15.
 
 {{< note >}}
-The following StorageClass parameters from the built-in vsphereVolume plugin are not supported by the vSphere CSI driver:
+The following StorageClass parameters from the built-in `vsphereVolume` plugin are not supported by the vSphere CSI driver:
 
 * `diskformat`
 * `hostfailurestotolerate`
@@ -1180,22 +1144,28 @@ The following StorageClass parameters from the built-in vsphereVolume plugin are
 * `objectspacereservation`
 * `iopslimit`
 
-Existing volumes created using these parameters will be migrated to the vSphere CSI driver, but new volumes created by the vSphere CSI driver will not be honoring these parameters.
+Existing volumes created using these parameters will be migrated to the vSphere CSI driver,
+but new volumes created by the vSphere CSI driver will not be honoring these parameters.
 {{< /note >}}
 
-#### CSI Migration Complete
+#### vSphere CSI migration complete {#vsphere-csi-migration-complete}
+
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-To turn off the vsphereVolume plugin from being loaded by controller manager and kubelet, you need to set this feature flag to true. This requires `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver being installed on all worker nodes.
+To turn off the `vsphereVolume` plugin from being loaded by the controller manager and the kubelet, you need to set this feature flag to `true`. You must install a `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver on all worker nodes.
 
+## Using subPath {#using-subpath}
 
-## Using subPath
+Sometimes, it is useful to share one volume for multiple uses in a single pod.
+The `volumeMounts.subPath` property specifies a sub-path inside the referenced volume
+instead of its root.
 
-Sometimes, it is useful to share one volume for multiple uses in a single Pod. The `volumeMounts.subPath`
-property can be used to specify a sub-path inside the referenced volume instead of its root.
+The following example shows how to configure a Pod with a LAMP stack (Linux Apache MySQL PHP)
+using a single, shared volume. This sample `subPath` configuration is not recommended
+for production use.
 
-Here is an example of a Pod with a LAMP stack (Linux Apache Mysql PHP) using a single, shared volume.
-The HTML contents are mapped to its `html` folder, and the databases will be stored in its `mysql` folder:
+The PHP application's code and assets map to the volume's `html` folder and
+the MySQL database is stored in the volume's `mysql` folder. For example:
 
 ```yaml
 apiVersion: v1
@@ -1225,15 +1195,18 @@ spec:
         claimName: my-lamp-site-data
 ```
 
-### Using subPath with expanded environment variables
+### Using subPath with expanded environment variables {#using-subpath-expanded-environment}
 
 {{< feature-state for_k8s_version="v1.17" state="stable" >}}
 
-
-Use the `subPathExpr` field to construct `subPath` directory names from Downward API environment variables.
+Use the `subPathExpr` field to construct `subPath` directory names from
+downward API environment variables.
 The `subPath` and `subPathExpr` properties are mutually exclusive.
 
-In this example, a Pod uses `subPathExpr` to create a directory `pod1` within the hostPath volume `/var/log/pods`, using the pod name from the Downward API.  The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container.
+In this example, a `Pod` uses `subPathExpr` to create a directory `pod1` within
+the `hostPath` volume `/var/log/pods`.
+The `hostPath` volume takes the `Pod` name from the `downwardAPI`.
+The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container.
 
 ```yaml
 apiVersion: v1
@@ -1264,47 +1237,41 @@ spec:
 
 ## Resources
 
-The storage media (Disk, SSD, etc.) of an `emptyDir` volume is determined by the
+The storage media (such as Disk or SSD) of an `emptyDir` volume is determined by the
 medium of the filesystem holding the kubelet root dir (typically
-`/var/lib/kubelet`).  There is no limit on how much space an `emptyDir` or
-`hostPath` volume can consume, and no isolation between Containers or between
-Pods.
+`/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or
+`hostPath` volume can consume, and no isolation between containers or between
+pods.
 
-In the future, we expect that `emptyDir` and `hostPath` volumes will be able to
-request a certain amount of space using a [resource](/docs/concepts/configuration/manage-resources-containers/)
-specification, and to select the type of media to use, for clusters that have
-several media types.
+To learn about requesting space using a resource specification, see
+[how to manage resources](/docs/concepts/configuration/manage-resources-containers/).
 
-## Out-of-Tree Volume Plugins
+## Out-of-tree volume plugins
 
-The Out-of-tree volume plugins include the Container Storage Interface (CSI)
-and FlexVolume. They enable storage vendors to create custom storage plugins
-without adding them to the Kubernetes repository.
+The out-of-tree volume plugins include
+{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI)
+and FlexVolume. These plugins enable storage vendors to create custom storage plugins
+without adding their plugin source code to the Kubernetes repository.
 
-Before the introduction of CSI and FlexVolume, all volume plugins (like
-volume types listed above) were "in-tree" meaning they were built, linked,
-compiled, and shipped with the core Kubernetes binaries and extend the core
-Kubernetes API. This meant that adding a new storage system to Kubernetes (a
-volume plugin) required checking code into the core Kubernetes code repository.
+Previously, all volume plugins were "in-tree". The "in-tree" plugins were built, linked, compiled,
+and shipped with the core Kubernetes binaries. This meant that adding a new storage system to
+Kubernetes (a volume plugin) required checking code into the core Kubernetes code repository.
 
 Both CSI and FlexVolume allow volume plugins to be developed independent of
 the Kubernetes code base, and deployed (installed) on Kubernetes clusters as
 extensions.
 
 For storage vendors looking to create an out-of-tree volume plugin, please refer
-to [this FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md).
+to the [volume plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md).
 
-### CSI
+### csi
 
-[Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI)
-defines a standard interface for container orchestration systems (like
+[Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md)
+(CSI) defines a standard interface for container orchestration systems (like
 Kubernetes) to expose arbitrary storage systems to their container workloads.
 
 Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information.
 
-CSI support was introduced as alpha in Kubernetes v1.9, moved to beta in
-Kubernetes v1.10, and is GA in Kubernetes v1.13.
-
 {{< note >}}
 Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes
 v1.13 and will be removed in a future release.
@@ -1317,57 +1284,59 @@ deployments steps for each Kubernetes release and a compatibility matrix.
 {{< /note >}}
 
 Once a CSI compatible volume driver is deployed on a Kubernetes cluster, users
-may use the `csi` volume type to attach, mount, etc. the volumes exposed by the
+may use the `csi` volume type to attach or mount the volumes exposed by the
 CSI driver.
 
-A `csi` volume can be used in a pod in three different ways:
-- through a reference to a [`persistentVolumeClaim`](#persistentvolumeclaim)
-- with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) (alpha feature)
-- with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) if the driver
-  supports that (beta feature)
+A `csi` volume can be used in a Pod in three different ways:
+
+* through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim)
+* with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)
+(alpha feature)
+* with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)
+if the driver supports that (beta feature)
 
 The following fields are available to storage administrators to configure a CSI
 persistent volume:
 
-- `driver`: A string value that specifies the name of the volume driver to use.
+* `driver`: A string value that specifies the name of the volume driver to use.
   This value must correspond to the value returned in the `GetPluginInfoResponse`
   by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo).
   It is used by Kubernetes to identify which CSI driver to call out to, and by
   CSI driver components to identify which PV objects belong to the CSI driver.
-- `volumeHandle`: A string value that uniquely identifies the volume. This value
+* `volumeHandle`: A string value that uniquely identifies the volume. This value
   must correspond to the value returned in the `volume.id` field of the
   `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
   The value is passed as `volume_id` on all calls to the CSI volume driver when
   referencing the volume.
-- `readOnly`: An optional boolean value indicating whether the volume is to be
+* `readOnly`: An optional boolean value indicating whether the volume is to be
   "ControllerPublished" (attached) as read only. Default is false. This value is
   passed to the CSI driver via the `readonly` field in the
   `ControllerPublishVolumeRequest`.
-- `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used
+* `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used
   to specify the filesystem that should be used to mount the volume. If the
   volume has not been formatted and formatting is supported, this value will be
   used to format the volume.
   This value is passed to the CSI driver via the `VolumeCapability` field of
   `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
   `NodePublishVolumeRequest`.
-- `volumeAttributes`: A map of string to string that specifies static properties
+* `volumeAttributes`: A map of string to string that specifies static properties
   of a volume. This map must correspond to the map returned in the
   `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as
   defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume).
   The map is passed to the CSI driver via the `volume_context` field in the
   `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
   `NodePublishVolumeRequest`.
-- `controllerPublishSecretRef`: A reference to the secret object containing
+* `controllerPublishSecretRef`: A reference to the secret object containing
   sensitive information to pass to the CSI driver to complete the CSI
   `ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is
-  optional, and may be empty if no secret is required. If the secret object
+  optional, and may be empty if no secret is required. If the Secret
   contains more than one secret, all secrets are passed.
-- `nodeStageSecretRef`: A reference to the secret object containing
+* `nodeStageSecretRef`: A reference to the secret object containing
   sensitive information to pass to the CSI driver to complete the CSI
   `NodeStageVolume` call. This field is optional, and may be empty if no secret
-  is required. If the secret object contains more than one secret, all secrets
+  is required. If the Secret contains more than one secret, all secrets
   are passed.
-- `nodePublishSecretRef`: A reference to the secret object containing
+* `nodePublishSecretRef`: A reference to the secret object containing
   sensitive information to pass to the CSI driver to complete the CSI
   `NodePublishVolume` call. This field is optional, and may be empty if no
   secret is required. If the secret object contains more than one secret, all
@@ -1377,11 +1346,11 @@ persistent volume:
 
 {{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
-Vendors with external CSI drivers can implement raw block volumes support
+Vendors with external CSI drivers can implement raw block volume support
 in Kubernetes workloads.
 
-You can [setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
-as usual, without any CSI specific changes.
+You can set up your
+[PersistentVolume/PersistentVolumeClaim with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) as usual, without any CSI specific changes.
 
 #### CSI ephemeral volumes
 
@@ -1389,107 +1358,105 @@ as usual, without any CSI specific changes.
 
 You can directly configure CSI volumes within the Pod
 specification. Volumes specified in this way are ephemeral and do not
-persist across Pod restarts. See [Ephemeral
+persist across pod restarts. See [Ephemeral
 Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)
 for more information.
 
-#### {{% heading "whatsnext" %}}
-
-For more information on how to develop a CSI driver, refer to the [kubernetes-csi
-documentation](https://kubernetes-csi.github.io/docs/)
+For more information on how to develop a CSI driver, refer to the
+[kubernetes-csi documentation](https://kubernetes-csi.github.io/docs/)
 
 #### Migrating to CSI drivers from in-tree plugins
 
-{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
-The CSI Migration feature, when enabled, directs operations against existing in-tree
+The `CSIMigration` feature, when enabled, directs operations against existing in-tree
 plugins to corresponding CSI plugins (which are expected to be installed and configured).
-The feature implements the necessary translation logic and shims to re-route the
-operations in a seamless fashion. As a result, operators do not have to make any
-configuration changes to existing Storage Classes, PVs or PVCs (referring to
-in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin.
+As a result, operators do not have to make any
+configuration changes to existing Storage Classes, PersistentVolumes or PersistentVolumeClaims
+(referring to in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin.
 
-In the alpha state, the operations and features that are supported include
+The operations and features that are supported include:
 provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
 
-In-tree plugins that support CSI Migration and have a corresponding CSI driver implemented
-are listed in the "Types of Volumes" section above.
+In-tree plugins that support `CSIMigration` and have a corresponding CSI driver implemented
+are listed in [Types of Volumes](#volume-types).
 
-### FlexVolume {#flexVolume}
+### flexVolume
 
 FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes
 since version 1.2 (before CSI). It uses an exec-based model to interface with
-drivers. FlexVolume driver binaries must be installed in a pre-defined volume
-plugin path on each node (and in some cases master).
+drivers. The FlexVolume driver binaries must be installed in a pre-defined volume
+plugin path on each node and in some cases the control plane nodes as well.
 
-Pods interact with FlexVolume drivers through the `flexvolume` in-tree plugin.
-More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md).
+Pods interact with FlexVolume drivers through the `flexvolume` in-tree volume plugin.
+For more details, see the [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) examples.
 
 ## Mount propagation
 
-Mount propagation allows for sharing volumes mounted by a Container to
-other Containers in the same Pod, or even to other Pods on the same node.
+Mount propagation allows for sharing volumes mounted by a container to
+other containers in the same pod, or even to other pods on the same node.
 
-Mount propagation of a volume is controlled by `mountPropagation` field in Container.volumeMounts.
-Its values are:
+Mount propagation of a volume is controlled by the `mountPropagation` field
+in `Container.volumeMounts`. Its values are:
 
- * `None` - This volume mount will not receive any subsequent mounts
-   that are mounted to this volume or any of its subdirectories by the host.
-   In similar fashion, no mounts created by the Container will be visible on
-   the host. This is the default mode.
+* `None` - This volume mount will not receive any subsequent mounts
+  that are mounted to this volume or any of its subdirectories by the host.
+  In similar fashion, no mounts created by the container will be visible on
+  the host. This is the default mode.
 
-   This mode is equal to `private` mount propagation as described in the
-   [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+  This mode is equal to `private` mount propagation as described in the
+  [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
 
- * `HostToContainer` - This volume mount will receive all subsequent mounts
-   that are mounted to this volume or any of its subdirectories.
+* `HostToContainer` - This volume mount will receive all subsequent mounts
+  that are mounted to this volume or any of its subdirectories.
 
-   In other words, if the host mounts anything inside the volume mount, the
-   Container will see it mounted there.
+  In other words, if the host mounts anything inside the volume mount, the
+  container will see it mounted there.
 
-   Similarly, if any Pod with `Bidirectional` mount propagation to the same
-   volume mounts anything there, the Container with `HostToContainer` mount
-   propagation will see it.
+  Similarly, if any Pod with `Bidirectional` mount propagation to the same
+  volume mounts anything there, the container with `HostToContainer` mount
+  propagation will see it.
 
-   This mode is equal to `rslave` mount propagation as described in the
-   [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+  This mode is equal to `rslave` mount propagation as described in the
+  [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
 
- * `Bidirectional` - This volume mount behaves the same the `HostToContainer` mount.
-   In addition, all volume mounts created by the Container will be propagated
-   back to the host and to all Containers of all Pods that use the same volume.
+* `Bidirectional` - This volume mount behaves the same the `HostToContainer` mount.
+  In addition, all volume mounts created by the container will be propagated
+  back to the host and to all containers of all pods that use the same volume.
 
-   A typical use case for this mode is a Pod with a FlexVolume or CSI driver or
-   a Pod that needs to mount something on the host using a `hostPath` volume.
+  A typical use case for this mode is a Pod with a FlexVolume or CSI driver or
+  a Pod that needs to mount something on the host using a `hostPath` volume.
 
-   This mode is equal to `rshared` mount propagation as described in the
-   [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
+  This mode is equal to `rshared` mount propagation as described in the
+  [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
 
-{{< caution >}}
-`Bidirectional` mount propagation can be dangerous. It can damage
-the host operating system and therefore it is allowed only in privileged
-Containers. Familiarity with Linux kernel behavior is strongly recommended.
-In addition, any volume mounts created by Containers in Pods must be destroyed
-(unmounted) by the Containers on termination.
-{{< /caution >}}
+  {{< warning >}}
+  `Bidirectional` mount propagation can be dangerous. It can damage
+  the host operating system and therefore it is allowed only in privileged
+  containers. Familiarity with Linux kernel behavior is strongly recommended.
+  In addition, any volume mounts created by containers in pods must be destroyed
+  (unmounted) by the containers on termination.
+  {{< /warning >}}
 
 ### Configuration
+
 Before mount propagation can work properly on some deployments (CoreOS,
 RedHat/Centos, Ubuntu) mount share must be configured correctly in
 Docker as shown below.
 
-Edit your Docker's `systemd` service file.  Set `MountFlags` as follows:
+Edit your Docker's `systemd` service file. Set `MountFlags` as follows:
+
 ```shell
 MountFlags=shared
 ```
-Or, remove `MountFlags=slave` if present.  Then restart the Docker daemon:
+
+Or, remove `MountFlags=slave` if present. Then restart the Docker daemon:
+
 ```shell
 sudo systemctl daemon-reload
 sudo systemctl restart docker
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
-* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
-
+Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md
index 1aac095cb5..21e57aed03 100644
--- a/content/en/docs/concepts/workloads/_index.md
+++ b/content/en/docs/concepts/workloads/_index.md
@@ -3,5 +3,55 @@ title: "Workloads"
 weight: 50
 description: >
   Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
+no_list: true
 ---
 
+{{< glossary_definition term_id="workload" length="short" >}}
+Whether your workload is a single component or several that work together, on Kubernetes you run
+it inside a set of [Pods](/docs/concepts/workloads/pods).
+In Kubernetes, a Pod represents a set of running {{< glossary_tooltip text="containers" term_id="container" >}}
+on your cluster.
+
+A Pod has a defined lifecycle. For example, once a Pod is running in your cluster then
+a critical failure on the {{< glossary_tooltip text="node" term_id="node" >}} where that
+Pod is running means that all the Pods on that node fail. Kubernetes treats that level
+of failure as final: you would need to create a new Pod even if the node later recovers.
+
+However, to make life considerably easier, you don't need to manage each Pod directly.
+Instead, you can use _workload resources_ that manage a set of Pods on your behalf.
+These resources configure {{< glossary_tooltip term_id="controller" text="controllers" >}}
+that make sure the right number of the right kind of Pod are running, to match the state
+you specified.
+
+Those workload resources include:
+
+* [Deployment](/docs/concepts/workloads/controllers/deployment/) and [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
+  (replacing the legacy resource {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}});
+* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/);
+* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) for running Pods that provide
+  node-local facilities, such as a storage driver or network plugin;
+* [Job](/docs/concepts/workloads/controllers/job/) and
+  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/)
+  for tasks that run to completion.
+
+There are also two supporting concepts that you might find relevant:
+* [Garbage collection](/docs/concepts/workloads/controllers/garbage-collection/) tidies up objects
+  from your cluster after their _owning resource_ has been removed.
+* The [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/)
+  removes Jobs once a defined time has passed since they completed.
+
+## {{% heading "whatsnext" %}}
+
+As well as reading about each resource, you can learn about specific tasks that relate to them:
+
+* [Run a stateless application using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/)
+* Run a stateful application either as a [single instance](/docs/tasks/run-application/run-single-instance-stateful-application/)
+  or as a [replicated set](/docs/tasks/run-application/run-replicated-stateful-application/)
+* [Run Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)
+
+Once your application is running, you might want to make it available on the internet as
+a [Service](/docs/concepts/services-networking/service/) or, for web application only,
+using an [Ingress](/docs/concepts/services-networking/ingress).
+
+You can also visit [Configuration](/docs/concepts/configuration/) to learn about Kubernetes'
+mechanisms for separating code from configuration.
diff --git a/content/en/docs/concepts/workloads/controllers/_index.md b/content/en/docs/concepts/workloads/controllers/_index.md
index 6aaa7405b5..a18ad08a38 100755
--- a/content/en/docs/concepts/workloads/controllers/_index.md
+++ b/content/en/docs/concepts/workloads/controllers/_index.md
@@ -1,5 +1,5 @@
 ---
-title: "Controllers"
+title: "Workload Resources"
 weight: 20
 ---
 
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index b73f78712e..54448de92f 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -13,7 +13,7 @@ weight: 10
 
 <!-- overview -->
 
-A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}}
+A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} and
 {{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}.
 
 You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
@@ -102,7 +102,7 @@ Follow the steps given below to create the above Deployment:
    The output is similar to:
    ```
    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-   deployment.apps/nginx-deployment successfully rolled out
+   deployment "nginx-deployment" successfully rolled out
    ```
 
 4. Run the `kubectl get deployments` again a few seconds later.
@@ -205,7 +205,7 @@ Follow the steps given below to update your Deployment:
     ```
     or
     ```
-    deployment.apps/nginx-deployment successfully rolled out
+    deployment "nginx-deployment" successfully rolled out
     ```
 
 Get more details on your updated Deployment:
@@ -752,7 +752,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
     REVISION  CHANGE-CAUSE
     1   <none>
     ```
-* Get the rollout status to ensure that the Deployment is updates successfully:
+* Get the rollout status to ensure that the Deployment is updated successfully:
     ```shell
     kubectl get rs
     ```
@@ -857,7 +857,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 The output is similar to this:
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 ```
 and the exit status from `kubectl rollout` is 0 (success):
 ```shell
diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md
index bdded6d27e..ba0270b573 100644
--- a/content/en/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/en/docs/concepts/workloads/controllers/replicaset.md
@@ -233,7 +233,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
 
 ### Pod Template
 
-The `.spec.template` is a [pod template](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) which is also
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates) which is also
 required to have labels in place. In our `frontend.yaml` example we had one label: `tier: frontend`.
 Be careful not to overlap with the selectors of other controllers, lest they try to adopt this Pod.
 
@@ -351,7 +351,7 @@ Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods t
 
 ### Job
 
-Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicaSet for Pods that are expected to terminate on their own
+Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet for Pods that are expected to terminate on their own
 (that is, batch jobs).
 
 ### DaemonSet
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index 64cef43470..acdb681652 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -150,7 +150,7 @@ remembered and reused, even after the Pod is running, for at least a few seconds
 If you need to discover Pods promptly after they are created, you have a few options:
 
 - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
-- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
 
 
 As mentioned in the [limitations](#limitations) section, you are responsible for
diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md
index 90dd7b5618..9f3f7800e4 100644
--- a/content/en/docs/concepts/workloads/pods/_index.md
+++ b/content/en/docs/concepts/workloads/pods/_index.md
@@ -145,7 +145,7 @@ from a _pod template_ and manage those Pods on your behalf.
 
 PodTemplates are specifications for creating Pods, and are included in workload resources such as
 [Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[Jobs](/docs/concepts/workloads/controllers/job/), and
 [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
 
 Each controller for a workload resource uses the `PodTemplate` inside the workload
@@ -172,14 +172,18 @@ spec:
     # The pod template ends here
 ```
 
-Modifying the pod template or switching to a new pod template has no effect on the
-Pods that already exist. Pods do not receive template updates directly. Instead,
-a new Pod is created to match the revised pod template.
+Modifying the pod template or switching to a new pod template has no direct effect
+on the Pods that already exist. If you change the pod template for a workload
+resource, that resource needs to create replacement Pods that use the updated template.
 
-For example, the deployment controller ensures that the running Pods match the current
-pod template for each Deployment object. If the template is updated, the Deployment has
-to remove the existing Pods and create new Pods based on the updated template. Each workload
-resource implements its own rules for handling changes to the Pod template.
+For example, the StatefulSet controller ensures that the running Pods match the current
+pod template for each StatefulSet object. If you edit the StatefulSet to change its pod
+template, the StatefulSet starts to create new Pods based on the updated template.
+Eventually, all of the old Pods are replaced with new Pods, and the update is complete.
+
+Each workload resource implements its own rules for handling changes to the Pod template.
+If you want to read more about StatefulSet specifically, read
+[Update strategy](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) in the StatefulSet Basics tutorial.
 
 On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
 directly observe or manage any of the details around pod templates and updates; those
@@ -217,7 +221,7 @@ or POSIX shared memory.  Containers in different Pods have distinct IP addresses
 and can not communicate by IPC without
 [special configuration](/docs/concepts/policy/pod-security-policy/).
 Containers that want to interact with a container running in a different Pod can
-use IP networking to comunicate.
+use IP networking to communicate.
 
 Containers within the Pod see the system hostname as being the same as the configured
 `name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
@@ -254,7 +258,7 @@ but cannot be controlled from there.
 
 * Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
 * Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
-* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
+* Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
   configure different Pods with different container runtime configurations.
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
 * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
@@ -264,7 +268,7 @@ but cannot be controlled from there.
 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
 
 To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
-  * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+  * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
   * [Borg](https://research.google.com/pubs/pub43438.html)
   * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
   * [Omega](https://research.google/pubs/pub41684/)
diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md
index 6e67a9e0ca..5c92f07423 100644
--- a/content/en/docs/concepts/workloads/pods/init-containers.md
+++ b/content/en/docs/concepts/workloads/pods/init-containers.md
@@ -28,8 +28,8 @@ Init containers are exactly like regular containers, except:
 * Init containers always run to completion.
 * Each init container must complete successfully before the next one starts.
 
-If a Pod's init container fails, Kubernetes repeatedly restarts the Pod until the init container
-succeeds. However, if the Pod has a `restartPolicy` of Never, Kubernetes does not restart the Pod.
+If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds. 
+However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed.
 
 To specify an init container for a Pod, add the `initContainers` field into
 the Pod specification, as an array of objects of type
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 0daf25de1a..3dfa69c5bf 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -13,7 +13,8 @@ of its primary containers starts OK, and then through either the `Succeeded` or
 
 Whilst a Pod is running, the kubelet is able to restart containers to handle some
 kind of faults. Within a Pod, Kubernetes tracks different container
-[states](#container-states) and handles
+[states](#container-states) and determines what action to take to make the Pod
+healthy again.
 
 In the Kubernetes API, Pods have both a specification and an actual status. The
 status for a Pod object consists of a set of [Pod conditions](#pod-conditions).
@@ -32,7 +33,7 @@ Like individual application containers, Pods are considered to be relatively
 ephemeral (rather than durable) entities. Pods are created, assigned a unique
 ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled
 to nodes where they remain until termination (according to restart policy) or
-deletion.  
+deletion.
 If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node
 are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
 
@@ -45,7 +46,7 @@ higher-level abstraction, called a
 managing the relatively disposable Pod instances.
 
 A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
-that Pod can be replaced by a new, near-identical Pod, with even the same name i
+that Pod can be replaced by a new, near-identical Pod, with even the same name if
 desired, but with a different UID.
 
 When something is said to have the same lifetime as a Pod, such as a
@@ -76,13 +77,13 @@ have a given `phase` value.
 
 Here are the possible values for `phase`:
 
-Value | Description
-:-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
-`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
+Value       | Description
+:-----------|:-----------
+`Pending`   | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
+`Running`   | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
 `Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
-`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
-`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
+`Failed`    | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
+`Unknown`   | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
 
 If a node dies or is disconnected from the rest of the cluster, Kubernetes
 applies a policy for setting the `phase` of all Pods on the lost node to Failed.
@@ -99,7 +100,7 @@ assigns a Pod to a Node, the kubelet starts creating containers for that Pod
 using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
 There are three possible container states: `Waiting`, `Running`, and `Terminated`.
 
-To the check state of a Pod's containers, you can use
+To check the state of a Pod's containers, you can use
 `kubectl describe pod <name-of-pod>`. The output shows the state for each container
 within that Pod.
 
@@ -107,7 +108,7 @@ Each state has a specific meaning:
 
 ### `Waiting` {#container-state-waiting}
 
-If a container is not in either the `Running` or `Terminated` state, it `Waiting`.
+If a container is not in either the `Running` or `Terminated` state, it is `Waiting`.
 A container in the `Waiting` state is still running the operations it requires in
 order to complete start up: for example, pulling the container image from a container
 image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}}
@@ -118,7 +119,7 @@ a Reason field to summarize why the container is in that state.
 ### `Running` {#container-state-running}
 
 The `Running` status indicates that a container is executing without issues. If there
-was a `postStart` hook configured, it has already executed and executed. When you use
+was a `postStart` hook configured, it has already executed and finished. When you use
 `kubectl` to query a Pod with a container that is `Running`, you also see information
 about when the container entered the `Running` state.
 
@@ -140,9 +141,8 @@ and Never. The default value is Always.
 The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
 refers to restarts of the containers by the kubelet on the same node. After containers
 in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
-40s, …), that is capped at five minutes. Once a container has executed with no problems
-for 10 minutes without any problems, the kubelet resets the restart backoff timer for
-that container.
+40s, …), that is capped at five minutes. Once a container has executed for 10 minutes
+without any problems, the kubelet resets the restart backoff timer for that container.
 
 ## Pod conditions
 
@@ -228,7 +228,8 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 ## Container probes
 
 A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
+performed periodically by the
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
 on a Container. To perform a diagnostic,
 the kubelet calls a
 [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
@@ -314,7 +315,7 @@ to stop.
 
 ### When should you use a startup probe?
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 Startup probes are useful for Pods that have containers that take a long time to
 come into service. Rather than set a long liveness interval, you can configure
@@ -342,7 +343,9 @@ place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts gr
 shutdown.
 
 Typically, the container runtime sends a TERM signal to the main process in each
-container. Once the grace period has expired, the KILL signal is sent to any remaining
+container. Many container runtimes respect the `STOPSIGNAL` value defined in the container
+image and send this instead of TERM.
+Once the grace period has expired, the KILL signal is sent to any remaining
 processes, and the Pod is then deleted from the
 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
 container runtime's management service is restarted while waiting for processes to terminate, the
@@ -353,9 +356,9 @@ An example flow:
 1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
    (30 seconds).
 1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
-   along with the grace period.  
+   along with the grace period.
    If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
-   "Terminating".  
+   "Terminating".
    On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
    as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
    shutdown process.
@@ -386,7 +389,7 @@ An example flow:
    `SIGKILL` to any processes still running in any container in the Pod.
    The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
 1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
-   to 0 (immediate deletion).  
+   to 0 (immediate deletion).
 1. The API server deletes the Pod's API object, which is then no longer visible from any client.
 
 ### Forced Pod termination {#pod-termination-forced}
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 5cc52cdbe6..e3a30b3f8b 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -4,11 +4,21 @@ content_type: concept
 weight: 40
 ---
 
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
+<!-- leave this shortcode in place until the note about EvenPodsSpread is
+obsolete -->
+
 <!-- overview -->
 
 You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
 
-
+{{< note >}}
+In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on
+the [API server](/docs/concepts/overview/components/#kube-apiserver) and the
+[scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod
+topology spread constraints.
+{{< /note >}}
 
 <!-- body -->
 
@@ -30,13 +40,23 @@ node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
 
 Then the cluster is logically viewed as below:
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph TB
+    subgraph "zoneB"
+        n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        n1(Node1)
+        n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters.
 
@@ -80,17 +100,25 @@ You can read more about this field by running `kubectl explain Pod.spec.topology
 
 ### Example: One TopologySpreadConstraint
 
-Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
+Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively:
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as:
 
@@ -100,15 +128,46 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones,
 
 If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB":
 
-```
-+---------------+---------------+      +---------------+---------------+
-|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+OR
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n3
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 You can tweak the Pod spec to meet various kinds of requirements:
 
@@ -118,17 +177,26 @@ You can tweak the Pod spec to meet various kinds of requirements:
 
 ### Example: Multiple TopologySpreadConstraints
 
-This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
+This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively:
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node:
 
@@ -138,15 +206,24 @@ In this case, to match the first constraint, the incoming Pod can only be placed
 
 Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
 
-```
-+---------------+-------+
-|     zoneA     | zoneB |
-+-------+-------+-------+
-| node1 | node2 | node3 |
-+-------+-------+-------+
-|  P P  |   P   |  P P  |
-+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p4(Pod) --> n3(Node3)
+        p5(Pod) --> n3
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n1
+        p3(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing.
 
@@ -169,15 +246,37 @@ There are some implicit conventions worth noting here:
 
     Suppose you have a 5-node cluster ranging from zoneA to zoneC:
 
-    ```
-    +---------------+---------------+-------+
-    |     zoneA     |     zoneB     | zoneC |
-    +-------+-------+-------+-------+-------+
-    | node1 | node2 | node3 | node4 | node5 |
-    +-------+-------+-------+-------+-------+
-    |   P   |   P   |   P   |       |       |
-    +-------+-------+-------+-------+-------+
-    ```
+    {{<mermaid>}}
+    graph BT
+        subgraph "zoneB"
+            p3(Pod) --> n3(Node3)
+            n4(Node4)
+        end
+        subgraph "zoneA"
+            p1(Pod) --> n1(Node1)
+            p2(Pod) --> n2(Node2)
+        end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+    {{< /mermaid >}}
+
+    {{<mermaid>}}
+    graph BT
+        subgraph "zoneC"
+            n5(Node5)
+        end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n5 k8s;
+    class zoneC cluster;
+    {{< /mermaid >}}
 
     and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
 
@@ -185,8 +284,6 @@ There are some implicit conventions worth noting here:
 
 ### Cluster-level default constraints
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
 It is possible to set default topology spread constraints for a cluster. Default
 topology spread constraints are applied to a Pod if, and only if:
 
@@ -206,13 +303,13 @@ apiVersion: kubescheduler.config.k8s.io/v1beta1
 kind: KubeSchedulerConfiguration
 
 profiles:
-  pluginConfig:
-    - name: PodTopologySpread
-      args:
-        defaultConstraints:
-          - maxSkew: 1
-            topologyKey: topology.kubernetes.io/zone
-            whenUnsatisfiable: ScheduleAnyway
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints:
+            - maxSkew: 1
+              topologyKey: topology.kubernetes.io/zone
+              whenUnsatisfiable: ScheduleAnyway
 ```
 
 {{< note >}}
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index 8616f77afb..1db65ec56d 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -1,6 +1,6 @@
 ---
 content_type: concept
-title: Contribute to Kubernetes docs
+title: Contribute to K8s docs
 linktitle: Contribute
 main_menu: true
 no_list: true
@@ -8,11 +8,18 @@ weight: 80
 card:
   name: contribute
   weight: 10
-  title: Start contributing
+  title: Start contributing to K8s
 ---
 
 <!-- overview -->
 
+*Kubernetes welcomes improvements from all contributors, new and experienced!*
+
+{{< note >}}
+To learn more about contributing to Kubernetes in general, see the
+[contributor documentation](https://www.kubernetes.dev/docs/).
+{{< /note >}}
+
 This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
 
 Kubernetes documentation contributors:
@@ -22,8 +29,6 @@ Kubernetes documentation contributors:
 - Translate the documentation
 - Manage and publish the documentation parts of the Kubernetes release cycle
 
-Kubernetes documentation welcomes improvements from all contributors, new and experienced!
-
 <!-- body -->
 
 ## Getting started
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index 80552144dd..b216a0a5b7 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -230,11 +230,9 @@ Build the Kubernetes documentation in your local `<web-base>`.
 
 ```shell
 cd <web-base>
-make docker-serve
+git submodule update --init --recursive --depth 1 # if not already done
+make container-serve
 ```
-{{< note >}}
-The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
-{{< /note >}}
 
 View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/).
 
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index f2ec01d8e8..251dfe2efe 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -182,13 +182,10 @@ Verify the [local preview](http://localhost:1313/docs/reference/generated/kubern
 
 ```shell
 cd <web-base>
-make docker-serve
+git submodule update --init --recursive --depth 1 # if not already done
+make container-serve
 ```
 
-{{< note >}}
-The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
-{{< /note >}}
-
 ## Commit the changes
 
 In `<web-base>` run `git add` and `git commit` to commit the change.
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 74c4f8e091..48c48b6ed3 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -32,7 +32,7 @@ First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/p
 
 ### Fork and clone the repo
 
-First, [create your own fork](/docs/contribute/new-content/new-content/#fork-the-repo) of the [kubernetes/website](https://github.com/kubernetes/website) repository.
+First, [create your own fork](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the [kubernetes/website](https://github.com/kubernetes/website) repository.
 
 Then, clone your fork and `cd` into it:
 
@@ -73,7 +73,9 @@ For an example of adding a label, see the PR for adding the [Italian language la
 
 ### Find community
 
-Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). Other localization teams are happy to help you get started and answer any questions you have.
+Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). Other localization teams are happy to help you get started and answer any questions you have.
+
+Please also consider participating in the [SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs).  The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization teams to collaborate on defining and documenting the processes for creating localized contribution guides. In addition, the SIG Docs localization subgroup will look for opportunities for the creation and sharing of common tools across localization teams and also serve to identify new requirements to the SIG Docs Leadership team.  If you have questions about this meeting, please inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations).
 
 You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980).
 
diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md
index 2ec9f35ac0..6628925694 100644
--- a/content/en/docs/contribute/new-content/blogs-case-studies.md
+++ b/content/en/docs/contribute/new-content/blogs-case-studies.md
@@ -25,7 +25,7 @@ Anyone can write a blog post and submit it for review.
 ### Guidelines and expectations
 
 - Blog posts should not be vendor pitches. 
-  - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](https://kubernetes.io/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties. 
+  - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties. 
   - Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog.
   - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out. 
 - Blog posts are not published on specific dates.
@@ -56,7 +56,7 @@ The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/mast
 
 To submit a blog post follow these directions:
 
-- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
+- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
 
 - Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
 
diff --git a/content/en/docs/contribute/new-content/new-features.md b/content/en/docs/contribute/new-content/new-features.md
index 54db84da8f..4e70f6c9ec 100644
--- a/content/en/docs/contribute/new-content/new-features.md
+++ b/content/en/docs/contribute/new-content/new-features.md
@@ -98,7 +98,9 @@ deadlines.
 1. Open a pull request against the
 `dev-{{< skew nextMinorVersion >}}` branch in the `kubernetes/website` repository, with a small
 commit that you will amend later.
-2. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
+2. Edit the pull request description to include links to [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)
+PR(s) and [kubernetes/enhancements](https://github.com/kubernetes/enhancements) issue(s).
+3. Use the Prow command `/milestone {{< skew nextMinorVersion >}}` to
 assign the PR to the relevant milestone. This alerts the docs person managing
 this release that the feature docs are coming.
 
@@ -114,7 +116,9 @@ When ready, populate your placeholder PR with feature documentation.
 
 Do your best to describe your feature and how to use it. If you need help structuring your documentation, ask in the `#sig-docs` slack channel.
 
-When you complete your content, the documentation person assigned to your feature reviews it. Use their suggestions to get the content to a release ready state.
+When you complete your content, the documentation person assigned to your feature reviews it.
+To ensure technical accuracy, the content may also require a technical review from corresponding SIG(s).
+Use their suggestions to get the content to a release ready state.
 
 If your feature needs documentation and the first draft
 content is not received, the feature may be removed from the milestone.
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
index b1f7e4f20a..a7c6ab083e 100644
--- a/content/en/docs/contribute/new-content/overview.md
+++ b/content/en/docs/contribute/new-content/overview.md
@@ -43,7 +43,7 @@ When opening a pull request, you need to know in advance which branch to base yo
 Scenario | Branch
 :---------|:------------
 Existing or new English language content for the current release | `master`
-Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
+Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
 Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
 
 
diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md
index 00c2ebcdab..328de3b73c 100644
--- a/content/en/docs/contribute/participate/pr-wranglers.md
+++ b/content/en/docs/contribute/participate/pr-wranglers.md
@@ -6,7 +6,7 @@ weight: 20
 
 <!-- overview -->
 
-SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
 
 This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/).
 
diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md
index 82a05bdb86..5c781ec53f 100644
--- a/content/en/docs/contribute/review/for-approvers.md
+++ b/content/en/docs/contribute/review/for-approvers.md
@@ -190,7 +190,7 @@ close the issue without fixing.
 
 Some docs issues are actually issues with the underlying code, or requests for
 assistance when something, for example a tutorial, doesn't work.
-For issues unrelated to docs, close the issue with the `triage/support` label and a comment
+For issues unrelated to docs, close the issue with the `kind/support` label and a comment
 directing the requester to support venues (Slack, Stack Overflow) and, if
 relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
 is a great place to start).
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 9b99ba3abc..c0efac7959 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -42,12 +42,9 @@ The English-language documentation uses U.S. English spelling and grammar.
 
 ## Documentation formatting standards
 
-### Use camel case for API objects
+### Use upper camel case for API objects
 
-When you refer to an API object, use the same uppercase and lowercase letters
-that are used in the actual object name. Typically, the names of API
-objects use
-[camel case](https://en.wikipedia.org/wiki/Camel_case).
+When you refer specifically to interacting with an API object, use [UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case), also known as Pascal Case. When you are generally discussing an API object, use [sentence-style capitalization](https://docs.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization).
 
 Don't split the API object name into separate words. For example, use
 PodTemplateList, not Pod Template List.
@@ -58,9 +55,9 @@ leads to an awkward construction.
 {{< table caption = "Do and Don't - API objects" >}}
 Do | Don't
 :--| :-----
-The Pod has two containers. | The pod has two containers.
-The Deployment is responsible for ... | The Deployment object is responsible for ...
-A PodList is a list of Pods. | A Pod List is a list of pods.
+The pod has two containers. | The Pod has two containers.
+The HorizontalPodAutoscaler is responsible for ... | The HorizontalPodAutoscaler object is responsible for ...
+A PodList is a list of pods. | A Pod List is a list of pods.
 The two ContainerPorts ... | The two ContainerPort objects ...
 The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ...
 {{< /table >}}
@@ -71,7 +68,7 @@ The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds
 Use angle brackets for placeholders. Tell the reader what a placeholder
 represents.
 
-1. Display information about a Pod:
+1. Display information about a pod:
 
         kubectl describe pod <pod-name> -n <namespace>
 
@@ -116,7 +113,7 @@ The copy is called a "fork". | The copy is called a "fork."
 
 ## Inline code formatting
 
-### Use code style for inline code and commands
+### Use code style for inline code, commands, and API objects
 
 For inline code in an HTML document, use the `<code>` tag. In a Markdown
 document, use the backtick (`` ` ``).
@@ -124,7 +121,9 @@ document, use the backtick (`` ` ``).
 {{< table caption = "Do and Don't - Use code style for inline code and commands" >}}
 Do | Don't
 :--| :-----
-The `kubectl run`command creates a Pod. | The "kubectl run" command creates a Pod.
+The `kubectl run` command creates a `Pod`. | The "kubectl run" command creates a pod.
+The kubelet on each node acquires a `Lease`… | The kubelet on each node acquires a lease…
+A `PersistentVolume` represents durable storage… | A Persistent Volume represents durable storage…
 For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply".
 Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax.
 Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**.
@@ -201,7 +200,7 @@ kubectl get pods | $ kubectl get pods
 
 ### Separate commands from output
 
-Verify that the Pod is running on your chosen node:
+Verify that the pod is running on your chosen node:
 
     kubectl get pods --output=wide
 
@@ -513,7 +512,7 @@ Do | Don't
 :--| :-----
 To create a ReplicaSet, ... | In order to create a ReplicaSet, ...
 See the configuration file. | Please see the configuration file.
-View the Pods. | With this next command, we'll view the Pods.
+View the pods. | With this next command, we'll view the pods.
 {{< /table >}}
 
 ### Address the reader as "you"
@@ -552,7 +551,7 @@ Do | Don't
 :--| :-----
 Version 1.4 includes ... | In version 1.4, we have added ...
 Kubernetes provides a new feature for ... | We provide a new feature ...
-This page teaches you how to use Pods. | In this page, we are going to learn about Pods.
+This page teaches you how to use pods. | In this page, we are going to learn about pods.
 {{< /table >}}
 
 
diff --git a/content/en/docs/contribute/suggesting-improvements.md b/content/en/docs/contribute/suggesting-improvements.md
index e48c2915b9..dbf5bf1abb 100644
--- a/content/en/docs/contribute/suggesting-improvements.md
+++ b/content/en/docs/contribute/suggesting-improvements.md
@@ -24,7 +24,7 @@ of the Kubernetes community open a pull request with changes to resolve the issu
 
 If you want to suggest improvements to existing content, or notice an error, then open an issue.
 
-1. Go to the bottom of the page and click the **Create an Issue** button. This redirects you
+1. Click the **Create an issue** link on the right sidebar. This redirects you
  to a GitHub issue page pre-populated with some headers.
 2. Describe the issue or suggestion for improvement. Provide as many details as you can.
 3. Click **Submit new issue**.
diff --git a/content/en/docs/doc-contributor-tools/README.md b/content/en/docs/doc-contributor-tools/README.md
deleted file mode 100644
index b493e67bd3..0000000000
--- a/content/en/docs/doc-contributor-tools/README.md
+++ /dev/null
@@ -1,2 +0,0 @@
-Tools for Kubernetes docs contributors. View `README.md` files in
-subdirectories for more info.
\ No newline at end of file
diff --git a/content/en/docs/doc-contributor-tools/snippets/README.md b/content/en/docs/doc-contributor-tools/snippets/README.md
deleted file mode 100644
index 2b4c9c8d45..0000000000
--- a/content/en/docs/doc-contributor-tools/snippets/README.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Snippets for Atom
-
-Snippets are bits of text that get inserted into your editor, to save typing and
-reduce syntax errors. The snippets provided in `atom-snippets.cson` are scoped to
-only work on Markdown files within Atom.
-
-## Installation
-
-Copy the contents of the `atom-snippets.cson` file into your existing
-`~/.atom/snippets.cson`. **Do not replace your existing file.**
-
-You do not need to restart Atom.
-
-## Usage
-
-Have a look through `atom-snippets.cson` and note the titles and `prefix` values
-of the snippets.
-
-You can trigger a given snippet in one of two ways:
-
-- By typing the snippet's `prefix` and pressing the `<TAB>` key
-- By searching for the snippet's title in **Packages / Snippets / Available**
-
-For example, open a Markdown file and type `anote` and press `<TAB>`. A blank
-note is added, with the correct Hugo shortcodes.
-
-A snippet can insert a single line or multiple lines of text. Some snippets
-have placeholder values. To get to the next placeholder, press `<TAB>` again.
-
-Some of the snippets only insert partially-formed Markdown or Hugo syntax.
-For instance, `coverview` inserts the start of a concept overview tag, while
-`cclose` inserts a close-capture tag. This is because every type of capture
-needs a capture-close tab.
-
-## Creating new topics using snippets
-
-To create a new concept, task, or tutorial from a blank file, use one of the
-following:
-
-- `newconcept`
-- `newtask`
-- `newtutorial`
-
-Placeholder text is included.
-
-## Submitting new snippets
-
-1.  Develop the snippet locally and verify that it works as expected.
-2.  Copy the template's code into the `atom-snippets.cson` file on GitHub. Raise a
-    pull request, and ask for review from another Atom user in `#sig-docs` on
-    Kubernetes Slack.
\ No newline at end of file
diff --git a/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson b/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson
deleted file mode 100644
index 878ccc4ed7..0000000000
--- a/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson
+++ /dev/null
@@ -1,226 +0,0 @@
-# Your snippets
-#
-# Atom snippets allow you to enter a simple prefix in the editor and hit tab to
-# expand the prefix into a larger code block with templated values.
-#
-# You can create a new snippet in this file by typing "snip" and then hitting
-# tab.
-#
-# An example CoffeeScript snippet to expand log to console.log:
-#
-# '.source.coffee':
-#   'Console log':
-#     'prefix': 'log'
-#     'body': 'console.log $1'
-#
-# Each scope (e.g. '.source.coffee' above) can only be declared once.
-#
-# This file uses CoffeeScript Object Notation (CSON).
-# If you are unfamiliar with CSON, you can read more about it in the
-# Atom Flight Manual:
-# http://flight-manual.atom.io/using-atom/sections/basic-customization/#_cson
-
-'.source.gfm':
-
-  # Capture variables for concept template
-  # For full concept template see 'newconcept' below
-  'Insert concept template':
-    'prefix': 'ctemplate'
-    'body': 'content_template: templates/concept'
-  'Insert concept overview':
-    'prefix': 'coverview'
-    'body': '{{% capture overview %}}'
-  'Insert concept body':
-    'prefix': 'cbody'
-    'body': '{{% capture body %}}'
-  'Insert concept whatsnext':
-    'prefix': 'cnext'
-    'body': '{{% capture whatsnext %}}'
-
-
-  # Capture variables for task template
-  # For full task template see 'newtask' below
-  'Insert task template':
-    'prefix': 'ttemplate'
-    'body': 'content_template: templates/task'
-  'Insert task overview':
-    'prefix': 'toverview'
-    'body': '{{% capture overview %}}'
-  'Insert task prerequisites':
-    'prefix': 'tprereq'
-    'body': """
-      {{% capture prerequisites %}}
-
-      {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-      {{% /capture %}}
-    """
-  'Insert task steps':
-    'prefix': 'tsteps'
-    'body': '{{% capture steps %}}'
-  'Insert task discussion':
-    'prefix': 'tdiscuss'
-    'body': '{{% capture discussion %}}'
-
-
-  # Capture variables for tutorial template
-  # For full tutorial template see 'newtutorial' below
-  'Insert tutorial template':
-    'prefix': 'tutemplate'
-    'body': 'content_template: templates/tutorial'
-  'Insert tutorial overview':
-    'prefix': 'tuoverview'
-    'body': '{{% capture overview %}}'
-  'Insert tutorial prerequisites':
-    'prefix': 'tuprereq'
-    'body': '{{% capture prerequisites %}}'  
-  'Insert tutorial objectives':
-    'prefix': 'tuobjectives'
-    'body': '{{% capture objectives %}}'
-  'Insert tutorial lesson content':
-    'prefix': 'tulesson'
-    'body': '{{% capture lessoncontent %}}'
-  'Insert tutorial whatsnext':
-    'prefix': 'tunext'
-    'body': '{{% capture whatsnext %}}'
-  'Close capture':
-    'prefix': 'ccapture'
-    'body': '{{% /capture %}}'
-  'Insert note':
-    'prefix': 'anote'
-    'body': """
-      {{< note >}}
-      $1
-      {{< /note >}}
-    """
-  
-  # Admonitions
-  'Insert caution':
-    'prefix': 'acaution'
-    'body': """
-      {{< caution >}}
-      $1
-      {{< /caution >}}
-    """
-  'Insert warning':
-    'prefix': 'awarning'
-    'body': """
-      {{< warning >}}
-      $1
-      {{< /warning >}}
-    """
-  
-  # Misc one-liners
-  'Insert TOC':
-    'prefix': 'toc'
-    'body': '{{< toc >}}'
-  'Insert code from file':
-    'prefix': 'codefile'
-    'body': '{{< codenew file="$1" >}}'
-  'Insert feature state':
-    'prefix': 'fstate'
-    'body': '{{< feature-state for_k8s_version="$1" state="$2" >}}'
-  'Insert figure':
-    'prefix': 'fig'
-    'body': '{{< figure src="$1" title="$2" alt="$3" caption="$4" >}}'
-  'Insert Youtube link':
-    'prefix': 'yt'
-    'body': '{{< youtube $1 >}}'
-
-
-  # Full concept template
-  'Create new concept':
-    'prefix': 'newconcept'
-    'body': """
-      ---
-      reviewers:
-      - ${1:"github-id-or-group"}
-      title: ${2:"topic-title"}
-      content_template: templates/concept
-      ---
-      {{% capture overview %}}
-      ${3:"overview-content"}
-      {{% /capture %}}
-      
-      {{< toc >}}
-      
-      {{% capture body %}}
-      ${4:"h2-heading-per-subtopic"}
-      {{% /capture %}}
-      
-      {{% capture whatsnext %}}
-      ${5:"next-steps-or-delete"}
-      {{% /capture %}}
-    """
-
-
-  # Full task template
-  'Create new task':
-    'prefix': 'newtask'
-    'body': """
-      ---
-      reviewers:
-      - ${1:"github-id-or-group"}
-      title: ${2:"topic-title"}
-      content_template: templates/task
-      ---
-      {{% capture overview %}}
-      ${3:"overview-content"}
-      {{% /capture %}}
-      
-      {{< toc >}}
-      
-      {{% capture prerequisites %}}
-      
-      {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-      
-      ${4:"additional-prereqs-or-delete"}
-      
-      {{% /capture %}}
-      
-      {{% capture steps %}}
-      ${5:"h2-heading-per-step"}
-      {{% /capture %}}
-      
-      {{% capture discussion %}}
-      ${6:"task-discussion-or-delete"}
-      {{% /capture %}}
-    """
-
-  # Full tutorial template
-  'Create new tutorial':
-    'prefix': 'newtutorial'
-    'body': """
-      ---
-      reviewers:
-      - ${1:"github-id-or-group"}
-      title: ${2:"topic-title"}
-      content_template: templates/tutorial
-      ---
-      {{% capture overview %}}
-      ${3:"overview-content"}
-      {{% /capture %}}
-      
-      {{< toc >}}
-      
-      {{% capture prerequisites %}}
-      
-      {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-      
-      ${4:"additional-prereqs-or-delete"}
-      
-      {{% /capture %}}
-      
-      {{% capture objectives %}}
-      ${5:"tutorial-objectives"}
-      {{% /capture %}}
-      
-      {{% capture lessoncontent %}}
-      ${6:"lesson-content"}
-      {{% /capture %}}
-      
-      {{% capture whatsnext %}}
-      ${7:"next-steps-or-delete"}
-      {{% /capture %}}
-    """
-  
diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md
index 7ee48721f2..68f4bfd3c9 100644
--- a/content/en/docs/home/_index.md
+++ b/content/en/docs/home/_index.md
@@ -32,7 +32,7 @@ cards:
   button: "View Tutorials"
   button_path: "/docs/tutorials"
 - name: setup
-  title: "Set up a cluster"
+  title: "Set up a K8s cluster"
   description: "Get Kubernetes running based on your resources and needs."
   button: "Set up Kubernetes"
   button_path: "/docs/setup"
@@ -57,7 +57,7 @@ cards:
   button: Contribute to the docs
   button_path: /docs/contribute
 - name: release-notes
-  title: Release Notes
+  title: K8s Release Notes
   description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
   button: "Download Kubernetes"
   button_path: "/docs/setup/release/notes"
diff --git a/content/en/docs/home/supported-doc-versions.md b/content/en/docs/home/supported-doc-versions.md
index bd368b2b54..b955f95f56 100644
--- a/content/en/docs/home/supported-doc-versions.md
+++ b/content/en/docs/home/supported-doc-versions.md
@@ -1,30 +1,12 @@
 ---
-title: Supported Versions of the Kubernetes Documentation
-content_type: concept
+title: Available Documentation Versions
+content_type: custom
+layout: supported-versions
 card:
   name: about
   weight: 10
-  title: Supported Versions of the Documentation
+  title: Available Documentation Versions
 ---
 
-<!-- overview -->
-
 This website contains documentation for the current version of Kubernetes
 and the four previous versions of Kubernetes.
-
-
-
-<!-- body -->
-
-## Current version
-
-The current version is
-[{{< param "version" >}}](/).
-
-## Previous versions
-
-{{< versions-other >}}
-
-
-
-
diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md
index 06eeb347d8..bc95e7efeb 100644
--- a/content/en/docs/reference/_index.md
+++ b/content/en/docs/reference/_index.md
@@ -18,8 +18,8 @@ This section of the Kubernetes documentation contains references.
 
 ## API Reference
 
-* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
 * [Kubernetes API Reference {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+* [Using The Kubernetes API](/docs/reference/using-api/) - overview of the API for Kubernetes.
 
 ## API Client Libraries
 
@@ -36,7 +36,7 @@ client libraries:
 
 * [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
     * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](https://goessner.net/articles/JsonPath/) with kubectl.
-* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
+* [kubeadm](/docs/reference/setup-tools/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
 
 ## Components Reference
 
diff --git a/content/en/docs/reference/access-authn-authz/_index.md b/content/en/docs/reference/access-authn-authz/_index.md
index 4e1bff0818..d999e52bf5 100644
--- a/content/en/docs/reference/access-authn-authz/_index.md
+++ b/content/en/docs/reference/access-authn-authz/_index.md
@@ -1,4 +1,26 @@
 ---
-title: Accessing the API
+title: API Access Control
 weight: 20
----
\ No newline at end of file
+no_list: true
+---
+
+For an introduction to how Kubernetes implements and controls API access,
+read [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
+
+Reference documentation:
+
+- [Authenticating](/docs/reference/access-authn-authz/authentication/)
+   - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+   - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [Authorization](/docs/reference/access-authn-authz/authorization/)
+   - [Role Based Access Control](/docs/reference/access-authn-authz/rbac/)
+   - [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/)
+   - [Node Authorization](/docs/reference/access-authn-authz/node/)
+   - [Webhook Authorization](/docs/reference/access-authn-authz/webhook/)
+- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
+     and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
+- Service accounts
+  - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
+  - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index fda7119caf..9bd082dc10 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -91,7 +91,7 @@ To see which admission plugins are enabled:
 kube-apiserver -h | grep enable-admission-plugins
 ```
 
-In 1.18, they are:
+In the current version, the default ones are:
 
 ```shell
 NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota
@@ -163,10 +163,11 @@ storage classes and how to mark a storage class as default.
 ### DefaultTolerationSeconds {#defaulttolerationseconds}
 
 This admission controller sets the default forgiveness toleration for pods to tolerate
-the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes,
-if the pods don't already have toleration for taints
-`node.kubernetes.io/not-ready:NoExecute` or
-`node.alpha.kubernetes.io/unreachable:NoExecute`.
+the taints `notready:NoExecute` and `unreachable:NoExecute` based on the k8s-apiserver input parameters
+`default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` if the pods don't already 
+have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or
+`node.kubernetes.io/unreachable:NoExecute`.
+The default value for `default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` is 5 minutes.
 
 ### DenyExecOnPrivileged {#denyexeconprivileged}
 
@@ -202,8 +203,6 @@ is recommended instead.
 This admission controller mitigates the problem where the API server gets flooded by
 event requests. The cluster admin can specify event rate limits by:
 
- * Ensuring that `eventratelimit.admission.k8s.io/v1alpha1=true` is included in the
-   `--runtime-config` flag for the API server;
  * Enabling the `EventRateLimit` admission controller;
  * Referencing an `EventRateLimit` configuration file from the file provided to the API
    server's command line flag `--admission-control-config-file`:
@@ -535,8 +534,8 @@ and kubelets will not be allowed to modify labels with that prefix.
   * `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`
+  * `failure-domain.beta.kubernetes.io/region` (deprecated)
+  * `failure-domain.beta.kubernetes.io/zone` (deprecated)
   * `topology.kubernetes.io/region`
   * `topology.kubernetes.io/zone`
   * `kubelet.kubernetes.io/`-prefixed labels
@@ -731,7 +730,7 @@ See the [resourceQuota design doc](https://git.k8s.io/community/contributors/des
 For [RuntimeClass](/docs/concepts/containers/runtime-class/) definitions which describe an overhead associated with running a pod,
 this admission controller will set the pod.Spec.Overhead field accordingly.
 
-See also [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
+See also [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
 for more information.
 
 ### SecurityContextDeny {#securitycontextdeny}
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index d05ef76acd..05bd0c9b9e 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -29,7 +29,7 @@ It is assumed that a cluster-independent service manages normal users in the fol
 In this regard, _Kubernetes does not have objects which represent normal user
 accounts._ Normal users cannot be added to a cluster through an API call.
 
-Even though normal user cannot be added via an API call, but any user that
+Even though a normal user cannot be added via an API call, any user that
 presents a valid certificate signed by the cluster's certificate authority
 (CA) is considered authenticated. In this configuration, Kubernetes determines
 the username from the common name field in the 'subject' of the cert (e.g.,
@@ -282,7 +282,33 @@ from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_
 as a bearer token.  See [above](#putting-a-bearer-token-in-a-request) for how the token
 is included in a request.
 
-![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)
+{{< mermaid >}}
+sequenceDiagram
+    participant user as User
+    participant idp as Identity Provider
+    participant kube as Kubectl
+    participant api as API Server
+
+    user ->> idp: 1. Login to IdP
+    activate idp
+    idp -->> user: 2. Provide access_token,<br>id_token, and refresh_token
+    deactivate idp
+    activate user
+    user ->> kube: 3. Call Kubectl<br>with --token being the id_token<br>OR add tokens to .kube/config
+    deactivate user
+    activate kube
+    kube ->> api: 4. Authorization: Bearer...
+    deactivate kube
+    activate api
+    api ->> api: 5. Is JWT signature valid?
+    api ->> api: 6. Has the JWT expired?(iat+exp)
+    api ->> api: 7. user authorized?
+    api -->> kube: 8. Authorized: Perform<br>action and return result
+    deactivate api
+    activate kube
+    kube --x user: 9. Return result
+    deactivate kube
+{{< /mermaid >}}
 
 1.  Login to your identity provider
 2.  Your identity provider will provide you with an `access_token`, `id_token` and a `refresh_token`
@@ -328,7 +354,7 @@ tokens on behalf of another.
 Kubernetes does not provide an OpenID Connect Identity Provider.
 You can use an existing public OpenID Connect Identity Provider (such as Google, or
 [others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
-Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
+Or, you can run your own Identity Provider, such as [dex](https://dexidp.io/),
 [Keycloak](https://github.com/keycloak/keycloak),
 CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
 Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
@@ -339,13 +365,13 @@ For an identity provider to work with Kubernetes it must:
 2.  Run in TLS with non-obsolete ciphers
 3.  Have a CA signed certificate (even if the CA is not a commercial CA or is self signed)
 
-A note about requirement #3 above, requiring a CA signed certificate.  If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed.  This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation.  If you don't have a CA handy, you can use [this script](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) from the CoreOS team to create a simple CA and a signed certificate and key pair.
+A note about requirement #3 above, requiring a CA signed certificate.  If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed.  This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation.  If you don't have a CA handy, you can use [this script](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) from the Dex team to create a simple CA and a signed certificate and key pair.
 Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh) that generates SHA256 certs with a longer life and larger key size.
 
 Setup instructions for specific systems:
 
 - [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html)
-- [Dex](https://github.com/dexidp/dex/blob/master/Documentation/kubernetes.md)
+- [Dex](https://dexidp.io/docs/kubernetes/)
 - [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/)
 
 #### Using kubectl
@@ -414,6 +440,8 @@ Webhook authentication is a hook for verifying bearer tokens.
 
 * `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service.
 * `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
+* `--authentication-token-webhook-version` determines whether to use `authentication.k8s.io/v1beta1` or `authentication.k8s.io/v1` 
+  `TokenReview` objects to send/receive information from the webhook. Defaults to `v1beta1`.
 
 The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 file format. Within the file, `clusters` refers to the remote service and
@@ -443,76 +471,171 @@ current-context: webhook
 contexts:
 - context:
     cluster: name-of-remote-authn-service
-    user: name-of-api-sever
+    user: name-of-api-server
   name: webhook
 ```
 
-When a client attempts to authenticate with the API server using a bearer token
-as discussed [above](#putting-a-bearer-token-in-a-request),
-the authentication webhook POSTs a JSON-serialized `authentication.k8s.io/v1beta1` `TokenReview` object containing the token
-to the remote service. Kubernetes will not challenge a request that lacks such a header.
+When a client attempts to authenticate with the API server using a bearer token as discussed [above](#putting-a-bearer-token-in-a-request),
+the authentication webhook POSTs a JSON-serialized `TokenReview` object containing the token to the remote service.
 
-Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/)
-as other Kubernetes API objects. Implementers should be aware of looser
-compatibility promises for beta objects and check the "apiVersion" field of the
-request to ensure correct deserialization. Additionally, the API server must
-enable the `authentication.k8s.io/v1beta1` API extensions group (`--runtime-config=authentication.k8s.io/v1beta1=true`).
+Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/) as other Kubernetes API objects.
+Implementers should check the `apiVersion` field of the request to ensure correct deserialization,
+and **must** respond with a `TokenReview` object of the same version as the request.
 
-The POST body will be of the following format:
+{{< tabs name="TokenReview_request" >}}
+{{% tab name="authentication.k8s.io/v1" %}}
+{{< note >}}
+The Kubernetes API server defaults to sending `authentication.k8s.io/v1beta1` token reviews for backwards compatibility.
+To opt into receiving `authentication.k8s.io/v1` token reviews, the API server must be started with `--authentication-token-webhook-version=v1`.
+{{< /note >}}
 
-```json
+```yaml
+{
+  "apiVersion": "authentication.k8s.io/v1",
+  "kind": "TokenReview",
+  "spec": {
+    # Opaque bearer token sent to the API server
+    "token": "014fbff9a07c...",
+   
+    # Optional list of the audience identifiers for the server the token was presented to.
+    # Audience-aware token authenticators (for example, OIDC token authenticators) 
+    # should verify the token was intended for at least one of the audiences in this list,
+    # and return the intersection of this list and the valid audiences for the token in the response status.
+    # This ensures the token is valid to authenticate to the server it was presented to.
+    # If no audiences are provided, the token should be validated to authenticate to the Kubernetes API server.
+    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
+  }
+}
+```
+{{% /tab %}}
+{{% tab name="authentication.k8s.io/v1beta1" %}}
+```yaml
 {
   "apiVersion": "authentication.k8s.io/v1beta1",
   "kind": "TokenReview",
   "spec": {
-    "token": "(BEARERTOKEN)"
+    # Opaque bearer token sent to the API server
+    "token": "014fbff9a07c...",
+   
+    # Optional list of the audience identifiers for the server the token was presented to.
+    # Audience-aware token authenticators (for example, OIDC token authenticators) 
+    # should verify the token was intended for at least one of the audiences in this list,
+    # and return the intersection of this list and the valid audiences for the token in the response status.
+    # This ensures the token is valid to authenticate to the server it was presented to.
+    # If no audiences are provided, the token should be validated to authenticate to the Kubernetes API server.
+    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
   }
 }
 ```
+{{% /tab %}}
+{{< /tabs >}}
 
-The remote service is expected to fill the `status` field of
-the request to indicate the success of the login. The response body's `spec`
-field is ignored and may be omitted. A successful validation of the bearer
-token would return:
+The remote service is expected to fill the `status` field of the request to indicate the success of the login.
+The response body's `spec` field is ignored and may be omitted.
+The remote service must return a response using the same `TokenReview` API version that it received.
+A successful validation of the bearer token would return:
 
-```json
+{{< tabs name="TokenReview_response_success" >}}
+{{% tab name="authentication.k8s.io/v1" %}}
+```yaml
 {
-  "apiVersion": "authentication.k8s.io/v1beta1",
+  "apiVersion": "authentication.k8s.io/v1",
   "kind": "TokenReview",
   "status": {
     "authenticated": true,
     "user": {
+      # Required
       "username": "janedoe@example.com",
+      # Optional
       "uid": "42",
-      "groups": [
-        "developers",
-        "qa"
-      ],
+      # Optional group memberships
+      "groups": ["developers", "qa"],
+      # Optional additional information provided by the authenticator.
+      # This should not contain confidential data, as it can be recorded in logs
+      # or API objects, and is made available to admission webhooks.
       "extra": {
         "extrafield1": [
           "extravalue1",
           "extravalue2"
         ]
       }
-    }
+    },
+    # Optional list audience-aware token authenticators can return,
+    # containing the audiences from the `spec.audiences` list for which the provided token was valid.
+    # If this is omitted, the token is considered to be valid to authenticate to the Kubernetes API server.
+    "audiences": ["https://myserver.example.com"]
   }
 }
 ```
-
-An unsuccessful request would return:
-
-```json
+{{% /tab %}}
+{{% tab name="authentication.k8s.io/v1beta1" %}}
+```yaml
 {
   "apiVersion": "authentication.k8s.io/v1beta1",
   "kind": "TokenReview",
   "status": {
-    "authenticated": false
+    "authenticated": true,
+    "user": {
+      # Required
+      "username": "janedoe@example.com",
+      # Optional
+      "uid": "42",
+      # Optional group memberships
+      "groups": ["developers", "qa"],
+      # Optional additional information provided by the authenticator.
+      # This should not contain confidential data, as it can be recorded in logs
+      # or API objects, and is made available to admission webhooks.
+      "extra": {
+        "extrafield1": [
+          "extravalue1",
+          "extravalue2"
+        ]
+      }
+    },
+    # Optional list audience-aware token authenticators can return,
+    # containing the audiences from the `spec.audiences` list for which the provided token was valid.
+    # If this is omitted, the token is considered to be valid to authenticate to the Kubernetes API server.
+    "audiences": ["https://myserver.example.com"]
   }
 }
 ```
+{{% /tab %}}
+{{< /tabs >}}
 
-HTTP status codes can be used to supply additional error context.
+An unsuccessful request would return:
 
+{{< tabs name="TokenReview_response_error" >}}
+{{% tab name="authentication.k8s.io/v1" %}}
+```yaml
+{
+  "apiVersion": "authentication.k8s.io/v1",
+  "kind": "TokenReview",
+  "status": {
+    "authenticated": false,
+    # Optionally include details about why authentication failed.
+    # If no error is provided, the API will return a generic Unauthorized message.
+    # The error field is ignored when authenticated=true.
+    "error": "Credentials are expired"
+  }
+}
+```
+{{% /tab %}}
+{{% tab name="authentication.k8s.io/v1beta1" %}}
+```yaml
+{
+  "apiVersion": "authentication.k8s.io/v1beta1",
+  "kind": "TokenReview",
+  "status": {
+    "authenticated": false,
+    # Optionally include details about why authentication failed.
+    # If no error is provided, the API will return a generic Unauthorized message.
+    # The error field is ignored when authenticated=true.
+    "error": "Credentials are expired"
+  }
+}
+```
+{{% /tab %}}
+{{< /tabs >}}
 
 ### Authenticating Proxy
 
diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md
index db668f818a..a084a7e54e 100644
--- a/content/en/docs/reference/access-authn-authz/authorization.md
+++ b/content/en/docs/reference/access-authn-authz/authorization.md
@@ -17,7 +17,7 @@ policies using the supported authorization modules.
 <!-- body -->
 In Kubernetes, you must be authenticated (logged in) before your request can be
 authorized (granted permission to access). For information about authentication,
-see [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
+see [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
 
 Kubernetes expects attributes that are common to REST API requests. This means
 that Kubernetes authorization works with existing organization-wide or
@@ -52,7 +52,7 @@ Kubernetes reviews only the following API request attributes:
  * **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
  * **Subresource** - The subresource that is being accessed (for resource requests only).
  * **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
- * **API group** - The {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
+ * **API group** - The {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the _core_ [API group](/docs/reference/using-api/#api-groups).
 
 ## Determine the Request Verb
 
@@ -202,6 +202,6 @@ action the account could take. This applies regardless of authorization mode.
 
 ## {{% heading "whatsnext" %}}
 
-* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
+* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
 * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
 
diff --git a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
index 542b5267be..856669a5d8 100644
--- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
+++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
@@ -12,10 +12,10 @@ weight: 20
 
 Bootstrap tokens are a simple bearer token that is meant to be used when
 creating new clusters or joining new nodes to an existing cluster.  It was built
-to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be used in other contexts
+to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts
 for users that wish to start clusters without `kubeadm`. It is also built to
-work, via RBAC policy, with the [Kubelet TLS
-Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
+work, via RBAC policy, with the
+[Kubelet TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
 
 
 <!-- body -->
diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
index 4eb1705f4c..6d05d0436a 100644
--- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
+++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
@@ -21,16 +21,16 @@ A CertificateSigningRequest (CSR) resource is used to request that a certificate
 by a denoted signer, after which the request may be approved or denied before
 finally being signed.
 
-
-
 <!-- body -->
+
 ## Request signing process
 
-The _CertificateSigningRequest_ resource type allows a client to ask for an X.509 certificate
+The CertificateSigningRequest resource type allows a client to ask for an X.509 certificate
 be issued, based on a signing request.
 The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing request in
-the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the
+the `spec.request` field. The CertificateSigningRequest denotes the signer (the
 recipient that the request is being made to) using the `spec.signerName` field.
+Note that `spec.signerName` is a required key after API version `certificates.k8s.io/v1`.
 
 Once created, a CertificateSigningRequest must be approved before it can be signed.
 Depending on the signer selected, a CertificateSigningRequest may be automatically approved
@@ -67,54 +67,80 @@ This includes:
 1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested.
 1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
 1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR.
-1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR.
+1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc
+   and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR.
 1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it.
 
-Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be the certificate plus intermediates to be presented during TLS handshakes.
+Commonly, the `status.certificate` field contains a single PEM-encoded X.509
+certificate once the CSR is approved and the certificate is issued. Some
+signers store multiple certificates into the `status.certificate` field. In
+that case, the documentation for the signer should specify the meaning of
+additional certificates; for example, this might be the certificate plus
+intermediates to be presented during TLS handshakes.
+
+The PKCS#10 signing request format doesn't allow to specify a certificate
+expiration or lifetime. The expiration or lifetime therefore has to be set
+through e.g. an annotation on the CSR object. While it's theoretically
+possible for a signer to use that expiration date, there is currently no
+known implementation that does. (The built-in signers all use the same
+`ClusterSigningDuration` configuration option, which defaults to 1 year,
+and can be changed with the `--cluster-signing-duration` command-line
+flag of the kube-controller-manager.)
+
 
 ### Kubernetes signers
 
 Kubernetes provides built-in signers that each have a well-known `signerName`:
 
-1. `kubernetes.io/kube-apiserver-client`: signs certificates that will be honored as client-certs by the kube-apiserver.
-  Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-    1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle is not distributed by any other means.
-    1. Permitted subjects - no subject restrictions, but approvers and signers may choose not to approve or sign. Certain subjects like cluster-admin level users or groups vary between distributions and installations, but deserve additional scrutiny before approval and signing. The `CertificateSubjectRestriction` admission plugin is available and enabled by default to restrict `system:masters`, but it is often not the only cluster-admin subject in a cluster.
+1. `kubernetes.io/kube-apiserver-client`: signs certificates that will be honored as client certificates by the API server.
+   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+    1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle is not distributed by any other means.
+    1. Permitted subjects - no subject restrictions, but approvers and signers may choose not to approve or sign.
+       Certain subjects like cluster-admin level users or groups vary between distributions and installations,
+       but deserve additional scrutiny before approval and signing.
+       The `CertificateSubjectRestriction` admission plugin is enabled by default to restrict `system:masters`,
+       but it is often not the only cluster-admin subject in a cluster.
     1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
-    1. Permitted key usages - must include []string{"client auth"}. Must not include key usages beyond []string{"digital signature", "key encipherment", "client auth"}
-    1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
+    1. Permitted key usages - must include `["client auth"]`. Must not include key usages beyond `["digital signature", "key encipherment", "client auth"]`.
+    1. Expiration/certificate lifetime - set by the `--cluster-signing-duration` option for the
+       kube-controller-manager implementation of this signer.
     1. CA bit allowed/disallowed - not allowed.
 
-1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client-certs by the
-  kube-apiserver.
-  May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-    1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle
+1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client certificates by the
+   API server.
+   May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+    1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle
        is not distributed by any other means.
-    1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
+    1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
     1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
-    1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}`
-    1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
+    1. Permitted key usages - exactly `["key encipherment", "digital signature", "client auth"]`.
+    1. Expiration/certificate lifetime - set by the `--cluster-signing-duration` option for the
+       kube-controller-manager implementation of this signer.
     1. CA bit allowed/disallowed - not allowed.
 
 1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate
-  by the kube-apiserver, but has no other guarantees.
-  Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-    1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means.
-    1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
-    1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
-    1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}`
-    1. Expiration/certificate lifetime - minimum of CSR signer or request.
+   by the API server, but has no other guarantees.
+   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+    1. Trust distribution: signed certificates must be honored by the API server as valid to terminate connections to a kubelet.
+       The CA bundle is not distributed by any other means.
+    1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
+    1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and
+       URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
+    1. Permitted key usages - exactly `["key encipherment", "digital signature", "server auth"]`.
+    1. Expiration/certificate lifetime - set by the `--cluster-signing-duration` option for the
+       kube-controller-manager implementation of this signer.
     1. CA bit allowed/disallowed - not allowed.
 
-1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some distributions may honor these as client
-  certs, but that behavior is not standard Kubernetes behavior.
-  This signerName can only be requested in CertificateSigningRequests created via the `certificates.k8s.io/v1beta1` API version.
-  Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-    1. Trust distribution: None.  There is no standard trust or distribution for this signer in a Kubernetes cluster.
+1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some third-party distributions of Kubernetes
+   may honor client certificates signed by it. The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and later)
+   does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
+   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+    1. Trust distribution: None. There is no standard trust or distribution for this signer in a Kubernetes cluster.
     1. Permitted subjects - any
     1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
     1. Permitted key usages - any
-    1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
+    1. Expiration/certificate lifetime - set by the `--cluster-signing-duration` option for the
+       kube-controller-manager implementation of this signer.
     1. CA bit allowed/disallowed - not allowed.
 
 {{< note >}}
@@ -125,7 +151,7 @@ Distribution of trust happens out of band for these signers.  Any trust outside
 coincidental. For instance, some distributions may honor `kubernetes.io/legacy-unknown` as client certificates for the
 kube-apiserver, but this is not a standard.
 None of these usages are related to ServiceAccount token secrets `.data[ca.crt]` in any way.  That CA bundle is only
-guaranteed to verify a connection to the kube-apiserver using the default service (`kubernetes.default.svc`).
+guaranteed to verify a connection to the API server using the default service (`kubernetes.default.svc`).
 
 ## Authorization
 
@@ -135,22 +161,7 @@ To allow creating a CertificateSigningRequest and retrieving any CertificateSign
 
 For example:
 
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: csr-creator
-rules:
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - certificatesigningrequests
-  verbs:
-  - create
-  - get
-  - list
-  - watch
-```
+{{< codenew file="access/certificate-signing-request/clusterrole-create.yaml" >}}
 
 To allow approving a CertificateSigningRequest:
 
@@ -160,35 +171,7 @@ To allow approving a CertificateSigningRequest:
 
 For example:
 
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: csr-approver
-rules:
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - certificatesigningrequests
-  verbs:
-  - get
-  - list
-  - watch
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - certificatesigningrequests/approval
-  verbs:
-  - update
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - signers
-  resourceNames:
-  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
-  verbs:
-  - approve
-```
+{{< codenew file="access/certificate-signing-request/clusterrole-approve.yaml" >}}
 
 To allow signing a CertificateSigningRequest:
 
@@ -196,56 +179,34 @@ To allow signing a CertificateSigningRequest:
 * Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/status`
 * Verbs: `sign`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
 
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: csr-signer
-rules:
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - certificatesigningrequests
-  verbs:
-  - get
-  - list
-  - watch
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - certificatesigningrequests/status
-  verbs:
-  - update
-- apiGroups:
-  - certificates.k8s.io
-  resources:
-  - signers
-  resourceName:
-  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
-  verbs:
-  - sign
-```
+{{< codenew file="access/certificate-signing-request/clusterrole-sign.yaml" >}}
 
-## Normal User
+## Normal user
 
-There are a few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl.
+A few steps are required in order to get a normal user to be able to
+authenticate and invoke an API. First, this user must have certificate issued
+by the Kubernetes cluster, and then present that Certificate to the API call
+as the Certificate Header or through the kubectl.
 
-### Create Private Key
+### Create private key
 
-The following scripts show how to generate PKI private key and CSR. It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
+The following scripts show how to generate PKI private key and CSR. It is
+important to set CN and O attribute of the CSR. CN is the name of the user and
+O is the group that this user will belong to. You can refer to
+[RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
 
-```
+```shell
 openssl genrsa -out john.key 2048
 openssl req -new -key john.key -out john.csr
 ```
 
-### Create Certificate Request Kubernetes Object
+### Create CertificateSigningRequest
 
 Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
 
-```
+```shell
 cat <<EOF | kubectl apply -f -
-apiVersion: certificates.k8s.io/v1beta1
+apiVersion: certificates.k8s.io/v1
 kind: CertificateSigningRequest
 metadata:
   name: john
@@ -253,6 +214,7 @@ spec:
   groups:
   - system:authenticated
   request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
+  signerName: kubernetes.io/kube-apiserver-client
   usages:
   - client auth
 EOF
@@ -260,68 +222,78 @@ EOF
 
 Some points to note:
 
-- usage has to be 'client auth'
-- request is the base64 encoded value of the CSR file content. You can use this command to get that ```cat john.csr | base64 | tr -d "\n"```
+- `usages` has to be '`client auth`'
+- `request` is the base64 encoded value of the CSR file content.
+  You can get the content using this command: ```cat john.csr | base64 | tr -d "\n"```
 
-### Approve Certificate Request
+### Approve certificate signing request
 
-Use kubeadmin to create a CSR and approve it.
+Use kubectl to create a CSR and approve it.
 
-Get the list of CSRs
-```
+Get the list of CSRs:
+
+```shell
 kubectl get csr
 ```
 
-Approve the CSR
-```
+Approve the CSR:
+
+```shell
 kubectl certificate approve john
 ```
 
-### Get the Certificate
+### Get the certificate
 
-Retrieve the Certificate from the CSR.
+Retrieve the certificate from the CSR:
 
-```
+```shell
 kubectl get csr/john -o yaml
 ```
 
-The Certificate value is in Base64-encoded format under status.certificate.
+The certificate value is in Base64-encoded format under `status.certificate`.
 
-### Create Role and Role Binding
+### Create Role and RoleBinding
 
-You get the Certificate already. Now it is time to define the Role and Role Binding for this user to access Kubernetes Cluster resources.
+With the certificate created. it is time to define the Role and RoleBinding for
+this user to access Kubernetes cluster resources.
 
-This is a sample script to create role for this new user
-```
+This is a sample script to create a Role for this new user:
+
+```shell
 kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
 ```
 
-This is a sample script to create role binding for this new user
-```
+This is a sample command to create a RoleBinding for this new user:
+
+```shell
 kubectl create rolebinding developer-binding-john --role=developer --user=john
 ```
 
-### Add to KubeConfig
+### Add to kubeconfig
 
-The last step is to add this user into the KubeConfig. We assume the key and crt files are located here "/home/vagrant/work/".
+The last step is to add this user into the kubeconfig file.
+This example assumes the key and certificate files are located at "/home/vagrant/work/".
+
+First, you need to add new credentials:
 
-First, we need to add new credentials
 ```
 kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true
 
 ```
 
-Then, we need to add the context
+Then, you need to add the context:
+
 ```
 kubectl config set-context john --cluster=kubernetes --user=john
 ```
 
-To test it, change kubecontext to john
+To test it, change the context to `john`:
+
 ```
 kubectl config use-context john
 ```
 
-## Approval & rejection
+## Approval or rejection  {#approval-rejection}
 
 ### Control plane automated approval {#approval-rejection-control-plane}
 
@@ -331,7 +303,7 @@ permissions on CSRs for node credentials to authorization.
 The kube-controller-manager POSTs SubjectAccessReview resources to the API server
 in order to check authorization for certificate approval.
 
-### Approval & rejection using `kubectl` {#approval-rejection-kubectl}
+### Approval or rejection using `kubectl` {#approval-rejection-kubectl}
 
 A Kubernetes administrator (with appropriate permissions) can manually approve
 (or deny) CertificateSigningRequests by using the `kubectl certificate
@@ -339,17 +311,17 @@ approve` and `kubectl certificate deny` commands.
 
 To approve a CSR with kubectl:
 
-```bash
+```shell
 kubectl certificate approve <certificate-signing-request-name>
 ```
 
 Likewise, to deny a CSR:
 
-```bash
+```shell
 kubectl certificate deny <certificate-signing-request-name>
 ```
 
-### Approval & rejection using the Kubernetes API {#approval-rejection-api-client}
+### Approval or rejection using the Kubernetes API {#approval-rejection-api-client}
 
 Users of the REST API can approve CSRs by submitting an UPDATE request to the `approval`
 subresource of the CSR to be approved. For example, you could write an
@@ -398,7 +370,8 @@ you like. If you want to add a note just for human consumption, use the
 
 ### Control plane signer {#signer-control-plane}
 
-The Kubernetes control plane implements each of the [Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers),
+The Kubernetes control plane implements each of the
+[Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers),
 as part of the kube-controller-manager.
 
 {{< note >}}
@@ -458,13 +431,11 @@ status:
   certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
 * View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
 * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
+
diff --git a/content/en/docs/reference/access-authn-authz/node.md b/content/en/docs/reference/access-authn-authz/node.md
index 439d97ff84..141dc8bb61 100644
--- a/content/en/docs/reference/access-authn-authz/node.md
+++ b/content/en/docs/reference/access-authn-authz/node.md
@@ -46,7 +46,7 @@ This group and user name format match the identity created for each kubelet as p
 [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
 
 The value of `<nodeName>` **must** match precisely the name of the node as registered by the kubelet. By default, this is the host name as provided by `hostname`, or overridden via the [kubelet option](/docs/reference/command-line-tools-reference/kubelet/) `--hostname-override`. However, when using the `--cloud-provider` kubelet option, the specific hostname may be determined by the cloud provider, ignoring the local `hostname` and the `--hostname-override` option. 
-For specifics about how the kubelet determines the hostname, as well as cloud provider overrides, see the [kubelet options reference](/docs/reference/command-line-tools-reference/kubelet/) and the [cloud provider details](/docs/concepts/cluster-administration/cloud-providers/).
+For specifics about how the kubelet determines the hostname, see the [kubelet options reference](/docs/reference/command-line-tools-reference/kubelet/).
 
 To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
 
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 2be833826c..138403e37c 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -891,6 +891,7 @@ rules:
 - apiGroups: ["rbac.authorization.k8s.io"]
   resources: ["clusterroles"]
   verbs: ["bind"]
+  # omit resourceNames to allow binding any ClusterRole
   resourceNames: ["admin","edit","view"]
 ---
 apiVersion: rbac.authorization.k8s.io/v1
@@ -1095,37 +1096,37 @@ In order from most secure to least secure, the approaches are:
 
 2. Grant a role to the "default" service account in a namespace
 
-If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+    If an application does not specify a `serviceAccountName`, it uses the "default" service account.
 
-{{< note >}}
-Permissions given to the "default" service account are available to any pod
-in the namespace that does not specify a `serviceAccountName`.
-{{< /note >}}
+    {{< note >}}
+    Permissions given to the "default" service account are available to any pod
+    in the namespace that does not specify a `serviceAccountName`.
+    {{< /note >}}
 
-For example, grant read-only permission within "my-namespace" to the "default" service account:
+    For example, grant read-only permission within "my-namespace" to the "default" service account:
 
-```shell
-kubectl create rolebinding default-view \
-  --clusterrole=view \
-  --serviceaccount=my-namespace:default \
-  --namespace=my-namespace
-```
+    ```shell
+    kubectl create rolebinding default-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:default \
+      --namespace=my-namespace
+    ```
 
-Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
-"default" service account in the `kube-system` namespace.
-To allow those add-ons to run with super-user access, grant cluster-admin
-permissions to the "default" service account in the `kube-system` namespace.
+    Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+    "default" service account in the `kube-system` namespace.
+    To allow those add-ons to run with super-user access, grant cluster-admin
+    permissions to the "default" service account in the `kube-system` namespace.
 
-{{< caution >}}
-Enabling this means the `kube-system` namespace contains Secrets
-that grant super-user access to your cluster's API.
-{{< /caution >}}
+    {{< caution >}}
+    Enabling this means the `kube-system` namespace contains Secrets
+    that grant super-user access to your cluster's API.
+    {{< /caution >}}
 
-```shell
-kubectl create clusterrolebinding add-on-cluster-admin \
-  --clusterrole=cluster-admin \
-  --serviceaccount=kube-system:default
-```
+    ```shell
+    kubectl create clusterrolebinding add-on-cluster-admin \
+      --clusterrole=cluster-admin \
+      --serviceaccount=kube-system:default
+    ```
 
 3. Grant a role to all service accounts in a namespace
 
@@ -1192,7 +1193,7 @@ the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-fo
 ```
 
 To explain that first command line option in detail: if earlier authorizers, such as Node,
-deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC
+deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC
 also denies that API request, the ABAC authorizer is then run. This means that any request
 allowed by *either* the RBAC or ABAC policies is allowed.
 
diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
index df653a206f..8f094309e1 100644
--- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
@@ -23,96 +23,108 @@ incomplete features are referred to in order to better describe service accounts
 Kubernetes distinguishes between the concept of a user account and a service account
 for a number of reasons:
 
-  - User accounts are for humans. Service accounts are for processes, which
-    run in pods.
-  - User accounts are intended to be global. Names must be unique across all
-    namespaces of a cluster, future user resource will not be namespaced.
-    Service accounts are namespaced.
-  - Typically, a cluster's User accounts might be synced from a corporate
-    database, where new user account creation requires special privileges and
-    is tied to complex business processes. Service account creation is intended
-    to be more lightweight, allowing cluster users to create service accounts for
-    specific tasks (i.e. principle of least privilege).
-  - Auditing considerations for humans and service accounts may differ.
-  - A config bundle for a complex system may include definition of various service
-    accounts for components of that system.  Because service accounts can be created
-    ad-hoc and have namespaced names, such config is portable.
+- User accounts are for humans. Service accounts are for processes, which run
+  in pods.
+- User accounts are intended to be global. Names must be unique across all
+  namespaces of a cluster. Service accounts are namespaced.
+- Typically, a cluster's user accounts might be synced from a corporate
+  database, where new user account creation requires special privileges and is
+  tied to complex business processes. Service account creation is intended to be
+  more lightweight, allowing cluster users to create service accounts for
+  specific tasks by following the principle of least privilege.
+- Auditing considerations for humans and service accounts may differ.
+- A config bundle for a complex system may include definition of various service
+  accounts for components of that system. Because service accounts can be created
+  without many constraints and have namespaced names, such config is portable.
 
 ## Service account automation
 
 Three separate components cooperate to implement the automation around service accounts:
 
-  - A Service account admission controller
-  - A Token controller
-  - A Service account controller
+- A `ServiceAccount` admission controller
+- A Token controller
+- A `ServiceAccount` controller
 
-### Service Account Admission Controller
+### ServiceAccount Admission Controller
 
 The modification of pods is implemented via a plugin
-called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). It is part of the apiserver.
+called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/).
+It is part of the API server.
 It acts synchronously to modify pods as they are created or updated. When this plugin is active
 (and it is by default on most distributions), then it does the following when a pod is created or modified:
 
-  1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`.
-  1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
-  1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod.
-  1. It adds a `volume` to the pod which contains a token for API access.
-  1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`.
+1. If the pod does not have a `serviceAccountName` set, it sets the
+   `serviceAccountName` to `default`.
+1. It ensures that the `serviceAccountName` referenced by the pod exists, and
+   otherwise rejects it.
+1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets`
+   of the ServiceAccount referenced by `serviceAccountName` are added to the pod.
+1. It adds a `volume` to the pod which contains a token for API access
+   if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's
+   `automountServiceAccountToken` is set to `false`.
+1. It adds a `volumeSource` to each container of the pod mounted at
+   `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has
+   created a volume for ServiceAccount token.
 
-Starting from v1.13, you can migrate a service account volume to a projected volume when
+You can migrate a service account volume to a projected volume when
 the `BoundServiceAccountTokenVolume` feature gate is enabled.
-The service account token will expire after 1 hour or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
+The service account token will expire after 1 hour or the pod is deleted. See
+more details about
+[projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
 
 ### Token Controller
 
-TokenController runs as part of controller-manager. It acts asynchronously. It:
+TokenController runs as part of `kube-controller-manager`. It acts asynchronously. It:
 
-- observes serviceAccount creation and creates a corresponding Secret to allow API access.
-- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets.
-- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed.
-- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed.
+- watches ServiceAccount creation and creates a corresponding
+  ServiceAccount token Secret to allow API access.
+- watches ServiceAccount deletion and deletes all corresponding ServiceAccount
+  token Secrets.
+- watches ServiceAccount token Secret addition, and ensures the referenced
+  ServiceAccount exists, and adds a token to the Secret if needed.
+- watches Secret deletion and removes a reference from the corresponding
+  ServiceAccount if needed.
 
-You must pass a service account private key file to the token controller in the controller-manager by using
-the `--service-account-private-key-file` option. The private key will be used to sign generated service account tokens.
-Similarly, you must pass the corresponding public key to the kube-apiserver using the `--service-account-key-file`
-option. The public key will be used to verify the tokens during authentication.
+You must pass a service account private key file to the token controller in
+the `kube-controller-manager` using the `--service-account-private-key-file`
+flag. The private key is used to sign generated service account tokens.
+Similarly, you must pass the corresponding public key to the `kube-apiserver`
+using the `--service-account-key-file` flag. The public key will be used to
+verify the tokens during authentication.
 
 #### To create additional API tokens
 
-A controller loop ensures a secret with an API token exists for each service
-account. To create additional API tokens for a service account, create a secret
-of type `ServiceAccountToken` with an annotation referencing the service
-account, and the controller will update it with a generated token:
+A controller loop ensures a Secret with an API token exists for each
+ServiceAccount. To create additional API tokens for a ServiceAccount, create a
+Secret of type `kubernetes.io/service-account-token` with an annotation
+referencing the ServiceAccount, and the controller will update it with a
+generated token:
 
-secret.json:
+Below is a sample configuration for such a Secret:
 
-```json
-{
-    "kind": "Secret",
-    "apiVersion": "v1",
-    "metadata": {
-        "name": "mysecretname",
-        "annotations": {
-            "kubernetes.io/service-account.name": "myserviceaccount"
-        }
-    },
-    "type": "kubernetes.io/service-account-token"
-}
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecretname
+  annotations:
+    kubernetes.io/service-account.name: myserviceaccount
+type: kubernetes.io/service-account-token
 ```
 
 ```shell
-kubectl create -f ./secret.json
+kubectl create -f ./secret.yaml
 kubectl describe secret mysecretname
 ```
 
-#### To delete/invalidate a service account token
+#### To delete/invalidate a ServiceAccount token Secret
 
 ```shell
 kubectl delete secret mysecretname
 ```
 
-### Service Account Controller
+### ServiceAccount controller
 
-Service Account Controller manages ServiceAccount inside namespaces, and ensures
-a ServiceAccount named "default" exists in every active namespace.
+A ServiceAccount controller manages the ServiceAccounts inside namespaces, and
+ensures a ServiceAccount named "default" exists in every active namespace.
 
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
index 806d7a2021..40f5f0b8b2 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -83,8 +83,6 @@ different Kubernetes components.
 | `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | |
 | `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
-| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
-| `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
 | `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | |
 | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | Beta | 1.10 | |
@@ -138,12 +136,11 @@ different Kubernetes components.
 | `RuntimeClass` | `true` | Beta | 1.14 | |
 | `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
 | `SCTPSupport` | `true` | Beta | 1.19 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
 | `ServiceTopology` | `false` | Alpha | 1.17 | |
@@ -210,6 +207,9 @@ different Kubernetes components.
 | `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
 | `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
 | `CustomPodDNS` | `true` | GA | 1.14 | - |
+| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
+| `CustomResourceDefaulting` | `true` | Beta | 1.16 | 1.16 |
+| `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
 | `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
 | `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | 1.15 |
 | `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
@@ -423,11 +423,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `CustomResourceWebhookConversion`: Enable webhook-based conversion
   on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
   troubleshoot a running Pod.
-- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/monitoring.md).
+- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/system-metrics/).
 - `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
   based resource provisioning on nodes.
 - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
-  [default spreading](/docs/concepts/workloads/pods/pod/pod-topology-spread-constraints/#internal-default-constraints).
+  [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
 - `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests
   so that validation, merging, and mutation can be tested without committing.
 - `DynamicAuditing`(*deprecated*): Used to enable dynamic auditing before v1.19.
@@ -473,11 +473,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
    See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details.
 - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
-- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
-  [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for
-  [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor
-  [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
+- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
 - `MountContainers`: Enable using utility containers on host as the volume mounter.
 - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
   For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
@@ -487,7 +484,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
   Pod affinity has to be specified if requesting a `local` volume.
 - `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature.
-- `PodOverhead`: Enable the [PodOverhead](/docs/concepts/configuration/pod-overhead/) feature to account for pod overheads.
+- `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/) feature to account for pod overheads.
 - `PodPriority`: Enable the descheduling and preemption of Pods based on their [priorities](/docs/concepts/configuration/pod-priority-preemption/).
 - `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending
   Pod readiness evaluation.  See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
@@ -513,7 +510,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `RuntimeClass`: Enable the [RuntimeClass](/docs/concepts/containers/runtime-class/) feature for selecting container runtime configurations.
 - `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
 - `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service, Endpoints, EndpointSlice, and NetworkPolicy definitions.
-- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
+- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/server-side-apply/) path at the API Server.
 - `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details.
 - `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints.
 - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
index 0daa490276..f512dc991d 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
@@ -243,7 +243,7 @@ for example:
 The validity duration of signed certificates can be configured with flag:
 
 ```
---experimental-cluster-signing-duration
+--cluster-signing-duration
 ```
 
 ### Approval
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md
index 54dc1a84d9..4bf6f9f769 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md
@@ -42,21 +42,21 @@ kubelet [flags]
 <td colspan="2">--add-dir-header</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, adds the file directory to the header</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, adds the file directory to the header of the log messages</td>
 </tr>
     
 <tr>
-<td colspan="2">--address 0.0.0.0</td>
+<td colspan="2">--address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0 </td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 0.0.0.0) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the Kubelet to serve on (set to `0.0.0.0` for all IPv4 interfaces and `::` for all IPv6 interfaces)  (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
     
 <tr>
 <td colspan="2">--allowed-unsafe-sysctls strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in `*`). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
@@ -67,116 +67,108 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--anonymous-auth</td>
+<td colspan="2">--anonymous-auth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of `system:anonymous`, and a group name of `system:unauthenticated`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--application-metrics-count-limit int</td>
+<td colspan="2">--application-metrics-count-limit int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 100</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"> Max number of application metrics to store (per container) (default 100) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns,it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of application metrics to store (per container) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns,it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--authentication-token-webhook</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Use the TokenReview API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Use the `TokenReview` API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--authentication-token-webhook-cache-ttl duration</td>
+<td colspan="2">--authentication-token-webhook-cache-ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `2m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache responses from the webhook token authenticator. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's
---config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache responses from the webhook token authenticator. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--authorization-mode string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (default "AlwaysAllow" when --config flag is not provided; "Webhook" when --config flag presents.) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Authorization mode for Kubelet server. Valid options are `AlwaysAllow` or `Webhook`. `Webhook` mode uses the `SubjectAccessReview` API to determine authorization. (default "AlwaysAllow" when `--config` flag is not provided; "Webhook" when `--config` flag presents.) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--authorization-webhook-cache-authorized-ttl duration</td>
+<td colspan="2">--authorization-webhook-cache-authorized-ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `5m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'authorized' responses from the webhook authorizer. (default 5m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'authorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--authorization-webhook-cache-unauthorized-ttl duration</td>
+<td colspan="2">--authorization-webhook-cache-unauthorized-ttl duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `30s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'unauthorized' responses from the webhook authorizer. (default 30s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The duration to cache 'unauthorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--azure-container-registry-config string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file container Azure container registry configuration information.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td>
 </tr>
 
 <tr>
-<td colspan="2">--boot-id-file string</td>
+<td colspan="2">--boot-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/proc/sys/kernel/random/boot_id`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for boot-id. Use the first one that exists. (default "/proc/sys/kernel/random/boot_id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
-</tr>
-
-<tr>
-<td colspan="2">--bootstrap-checkpoint-path string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; Path to the directory where the checkpoints are stored</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for `boot-id`. Use the first one that exists. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--bootstrap-kubeconfig string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by --kubeconfig. The client certificate and key file will be stored in the directory pointed by --cert-dir.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by `--kubeconfig`. The client certificate and key file will be stored in the directory pointed by `--cert-dir`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--cert-dir string</td>
+<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/var/lib/kubelet/pki`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/lib/kubelet/pki")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The directory where the TLS certs are located. If `--tls-cert-file` and `--tls-private-key-file` are provided, this flag will be ignored.</td>
 </tr>
 
 <tr>
-<td colspan="2">--cgroup-driver string</td>
+<td colspan="2">--cgroup-driver string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `cgroupfs`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Driver that the kubelet uses to manipulate cgroups on the host.  Possible values: 'cgroupfs', 'systemd' (default "cgroupfs") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Driver that the kubelet uses to manipulate cgroups on the host.  Possible values: `cgroupfs`, `systemd`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td>
 </tr>
 
 <tr>
-<td colspan="2">--cgroup-root string</td>
+<td colspan="2">--cgroup-root string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `''`</td>
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Optional root cgroup to use for pods. This is handled by the container runtime on a best effort basis. Default: '', which means use the container runtime default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--cgroups-per-qos</td>
+<td colspan="2">--cgroups-per-qos&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--chaos-chance float</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If > 0.0, introduce random client errors and latency. Intended for testing.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If &gt; 0.0, introduce random client errors and latency. Intended for testing. (DEPRECATED: will be removed in a future version.)</td>
 </tr>
 
 <tr>
@@ -190,49 +182,49 @@ kubelet [flags]
 <td colspan="2">--cloud-config string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the cloud provider configuration file.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the cloud provider configuration file. Empty string for no configuration file. (DEPRECATED: will be removed in 1.23, in favor of removing cloud providers code from Kubelet.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--cloud-provider string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The provider for cloud services. Specify empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The provider for cloud services. Set to empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used). (DEPRECATED: will be removed in 1.23, in favor of removing cloud provider code from Kubelet.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--cluster-dns strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of DNS server IP address.  This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--cluster-domain string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Domain for this cluster.  If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--cni-bin-dir string</td>
+<td colspan="2">--cni-bin-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/opt/cni/bin`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to docker. (default "/opt/cni/bin")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--cni-cache-dir string</td>
+<td colspan="2">--cni-cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/var/lib/cni/cache`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to docker. (default "/var/lib/cni/cache")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--cni-conf-dir string</td>
+<td colspan="2">--cni-conf-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/etc/cni/net.d`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to docker. (default "/etc/cni/net.d")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
@@ -243,94 +235,94 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--container-hints string</td>
+<td colspan="2">--container-hints string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/etc/cadvisor/container_hints.json`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">location of the container hints file (default "/etc/cadvisor/container_hints.json") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">location of the container hints file. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--container-log-max-files int32</td>
+<td colspan="2">--container-log-max-files int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Beta feature&gt; Set the maximum number of container log files that can be present for a container. The number must be &ge; 2. This flag can only be used with --container-runtime=remote. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Beta feature&gt; Set the maximum number of container log files that can be present for a container. The number must be &ge; 2. This flag can only be used with `--container-runtime=remote`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--container-log-max-size string</td>
+<td colspan="2">--container-log-max-size string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `10Mi`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Beta feature&gt; Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with --container-runtime=remote. (default "10Mi") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Beta feature&gt; Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with `--container-runtime=remote`.  (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--container-runtime string</td>
+<td colspan="2">--container-runtime string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `docker`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The container runtime to use. Possible values: 'docker', 'remote', 'rkt(deprecated)'. (default "docker")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The container runtime to use. Possible values: `docker`, `remote`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--container-runtime-endpoint string</td>
+<td colspan="2">--container-runtime-endpoint string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `unix:///var/run/dockershim.sock`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows.  Examples:'unix:///var/run/dockershim.sock', 'npipe:////./pipe/dockershim' (default "unix:///var/run/dockershim.sock")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: `unix:///var/run/dockershim.sock`, `npipe:////./pipe/dockershim`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--containerd string</td>
+<td colspan="2">--containerd string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/run/containerd/containerd.sock`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">  containerd endpoint (default "/run/containerd/containerd.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The `containerd` endpoint. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
     
 <tr>
 <td colspan="2">--contention-profiling</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--cpu-cfs-quota</td>
+<td colspan="2">--cpu-cfs-quota&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable CPU CFS quota enforcement for containers that specify CPU limits (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable CPU CFS quota enforcement for containers that specify CPU limits (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--cpu-cfs-quota-period duration</td>
+<td colspan="2">--cpu-cfs-quota-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `100ms`</td>
    </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default (default 100ms) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Sets CPU CFS quota period value, `cpu.cfs_period_us`, defaults to Linux Kernel default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--cpu-manager-policy string</td>
+<td colspan="2">--cpu-manager-policy string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `none`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (default "none") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">CPU Manager policy to use. Possible values: `none`, `static`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--cpu-manager-reconcile-period NodeStatusUpdateFrequency</td>
+<td colspan="2">--cpu-manager-reconcile-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `10s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; CPU Manager reconciliation period. Examples: '10s', or '1m'. If not supplied, defaults to NodeStatusUpdateFrequency (default 10s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; CPU Manager reconciliation period. Examples: `10s`, or `1m`. If not supplied, defaults to node status update frequency. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--docker string</td>
+<td colspan="2">--docker string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `unix:///var/run/docker.sock`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">docker endpoint (default "unix:///var/run/docker.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The `docker` endpoint. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
     
 <tr>
-<td colspan="2">--docker-endpoint string</td>
+<td colspan="2">--docker-endpoint string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `unix:///var/run/docker.sock`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker. (default "unix:///var/run/docker.sock")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Use this for the `docker` endpoint to communicate with. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
@@ -348,10 +340,10 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--docker-root string</td>
+<td colspan="2">--docker-root string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/var/lib/docker`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker) (default "/var/lib/docker")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: docker root is read from docker info (this is a fallback).</td>
 </tr>
 
 <tr>
@@ -362,143 +354,143 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--docker-tls-ca string</td>
+<td colspan="2">--docker-tls-ca string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `ca.pem`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">path to trusted CA (default "ca.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">path to trusted CA. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--docker-tls-cert string</td>
+<td colspan="2">--docker-tls-cert string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `cert.pem`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">path to client certificate (default "cert.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">path to client certificate. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--docker-tls-key string</td>
+<td colspan="2">--docker-tls-key string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `key.pem`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">path to private key (default "key.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to private key. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--dynamic-config-dir string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The DynamicKubeletConfig feature gate must be enabled to pass this flag; this gate currently defaults to true because the feature is beta.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The `DynamicKubeletConfig` feature gate must be enabled to pass this flag; this gate currently defaults to `true` because the feature is beta.</td>
 </tr>
 
 <tr>
-<td colspan="2">--enable-cadvisor-json-endpoints</td>
+<td colspan="2">--enable-cadvisor-json-endpoints&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `false`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable cAdvisor json /spec and /stats/* endpoints. (default false) (DEPRECATED: will be removed in a future version)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable cAdvisor json `/spec` and `/stats/*` endpoints. (DEPRECATED: will be removed in a future version)</td>
 </tr>
 
 <tr>
-<td colspan="2">--enable-controller-attach-detach</td>
+<td colspan="2">--enable-controller-attach-detach&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations (default true)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations.</td>
 </tr>
 
 <tr>
-<td colspan="2">--enable-debugging-handlers</td>
+<td colspan="2">--enable-debugging-handlers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables server endpoints for log collection and local running of containers and commands (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables server endpoints for log collection and local running of containers and commands. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--enable-load-reader</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Whether to enable cpu load reader (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Whether to enable CPU load reader (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--enable-server</td>
+<td colspan="2">--enable-server&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable the Kubelet's server (default true)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enable the Kubelet's server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--enforce-node-allocatable stringSlice</td>
+<td colspan="2">--enforce-node-allocatable strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `pods`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'none', 'pods', 'system-reserved', and 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' and '--kube-reserved-cgroup' must also be set, respectively. If 'none' is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (default [pods]) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are `none`, `pods`, `system-reserved`, and `kube-reserved`. If the latter two options are specified, `--system-reserved-cgroup` and `--kube-reserved-cgroup` must also be set, respectively. If `none` is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--event-burst int32</td>
+<td colspan="2">--event-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding `--event-qps`. Only used if `--event-qps` &gt; 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--event-qps int32</td>
+<td colspan="2">--event-qps int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If &gt; 0, limit event creations per second to this value. If 0, unlimited. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If &gt; `0`, limit event creations per second to this value. If `0`, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--event-storage-age-limit string</td>
+<td colspan="2">--event-storage-age-limit string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `default=0`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: `creation`, `oom`) or `default` and the value is a duration. Default is applied to all non-specified event types. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--event-storage-event-limit string</td>
+<td colspan="2">--event-storage-event-limit string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `default=0`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: `creation`, `oom`) or `default` and the value is an integer. Default is applied to all non-specified event types. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--eviction-hard mapStringString</td>
+<td colspan="2">--eviction-hard mapStringString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction thresholds (e.g. memory.available&lt;1Gi) that if met would trigger a pod eviction. (default imagefs.available&lt;15%,memory.available&lt;100Mi,nodefs.available&lt;10%,nodefs.inodesFree&lt;5%) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction thresholds (e.g. `memory.available<1Gi`) that if met would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--eviction-max-pod-grace-period int32</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"> Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met.  If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"> Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--eviction-minimum-reclaim mapStringString</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of minimum reclaims (e.g. imagefs.available=2Gi) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of minimum reclaims (e.g. `imagefs.available=2Gi`) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--eviction-pressure-transition-period duration</td>
+<td colspan="2">--eviction-pressure-transition-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `5m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (default 5m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--eviction-soft mapStringString</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction thresholds (e.g. memory.available&lt;1.5Gi) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction thresholds (e.g. `memory.available>1.5Gi`) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--eviction-soft-grace-period mapStringString</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of eviction grace periods (e.g. `memory.available=1m30s`) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
@@ -509,88 +501,173 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--experimental-allocatable-ignore-eviction</td>
+<td colspan="2">--experimental-allocatable-ignore-eviction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `false`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. [default=false]</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to `true`, Hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.23)</td>
 </tr>
     
 <tr>
 <td colspan="2">--experimental-bootstrap-kubeconfig string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">(DEPRECATED: Use --bootstrap-kubeconfig)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: Use `--bootstrap-kubeconfig`</td>
 </tr>
 
 <tr>
 <td colspan="2">--experimental-check-node-capabilities-before-mount</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] if set to `true`, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount (DEPRECATED: will be removed in 1.23, in favor of using CSI.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--experimental-kernel-memcg-notification</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. This flag will be removed in 1.23. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--experimental-mounter-path string</td>
+<td colspan="2">--experimental-mounter-path string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `mount`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] Path of mounter binary. Leave empty to use the default mount.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] Path of mounter binary. Leave empty to use the default `mount`. (DEPRECATED: will be removed in 1.23, in favor of using CSI.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--fail-swap-on</td>
+<td colspan="2">--fail-swap-on&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Makes the Kubelet fail to start if swap is enabled on the node.  (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Makes the Kubelet fail to start if swap is enabled on the node. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--feature-gates mapStringBool</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)
-<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of `key=value` pairs that describe feature gates for alpha/experimental features. Options are:<br/>
+APIListChunking=true|false (BETA - default=true)<br/>
+APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>
+APIResponseCompression=true|false (BETA - default=true)<br/>
+AllAlpha=true|false (ALPHA - default=false)<br/>
+AllBeta=true|false (BETA - default=false)<br/>
+AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>
+AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>
+AppArmor=true|false (BETA - default=true)<br/>
+BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>
+BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>
+CPUManager=true|false (BETA - default=true)<br/>
+CRIContainerLogRotation=true|false (BETA - default=true)<br/>
+CSIInlineVolume=true|false (BETA - default=true)<br/>
+CSIMigration=true|false (BETA - default=true)<br/>
+CSIMigrationAWS=true|false (BETA - default=false)<br/>
+CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>
+CSIMigrationAzureDisk=true|false (BETA - default=false)<br/>
+CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>
+CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>
+CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>
+CSIMigrationGCE=true|false (BETA - default=false)<br/>
+CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>
+CSIMigrationOpenStack=true|false (BETA - default=false)<br/>
+CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>
+CSIMigrationvSphere=true|false (BETA - default=false)<br/>
+CSIMigrationvSphereComplete=true|false (BETA - default=false)<br/>
+CSIStorageCapacity=true|false (ALPHA - default=false)<br/>
+CSIVolumeFSGroupPolicy=true|false (ALPHA - default=false)<br/>
+ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>
+CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>
+DefaultPodTopologySpread=true|false (ALPHA - default=false)<br/>
+DevicePlugins=true|false (BETA - default=true)<br/>
+DisableAcceleratorUsageMetrics=true|false (ALPHA - default=false)<br/>
+DynamicKubeletConfig=true|false (BETA - default=true)<br/>
+EndpointSlice=true|false (BETA - default=true)<br/>
+EndpointSliceProxying=true|false (BETA - default=true)<br/>
+EphemeralContainers=true|false (ALPHA - default=false)<br/>
+ExpandCSIVolumes=true|false (BETA - default=true)<br/>
+ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>
+ExpandPersistentVolumes=true|false (BETA - default=true)<br/>
+ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>
+GenericEphemeralVolume=true|false (ALPHA - default=false)<br/>
+HPAScaleToZero=true|false (ALPHA - default=false)<br/>
+HugePageStorageMediumSize=true|false (BETA - default=true)<br/>
+HyperVContainer=true|false (ALPHA - default=false)<br/>
+IPv6DualStack=true|false (ALPHA - default=false)<br/>
+ImmutableEphemeralVolumes=true|false (BETA - default=true)<br/>
+KubeletPodResources=true|false (BETA - default=true)<br/>
+LegacyNodeRoleBehavior=true|false (BETA - default=true)<br/>
+LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>
+LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>
+NodeDisruptionExclusion=true|false (BETA - default=true)<br/>
+NonPreemptingPriority=true|false (BETA - default=true)<br/>
+PodDisruptionBudget=true|false (BETA - default=true)<br/>
+PodOverhead=true|false (BETA - default=true)<br/>
+ProcMountType=true|false (ALPHA - default=false)<br/>
+QOSReserved=true|false (ALPHA - default=false)<br/>
+RemainingItemCount=true|false (BETA - default=true)<br/>
+RemoveSelfLink=true|false (ALPHA - default=false)<br/>
+RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>
+RunAsGroup=true|false (BETA - default=true)<br/>
+RuntimeClass=true|false (BETA - default=true)<br/>
+SCTPSupport=true|false (BETA - default=true)<br/>
+SelectorIndex=true|false (BETA - default=true)<br/>
+ServerSideApply=true|false (BETA - default=true)<br/>
+ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>
+ServiceAppProtocol=true|false (BETA - default=true)<br/>
+ServiceNodeExclusion=true|false (BETA - default=true)<br/>
+ServiceTopology=true|false (ALPHA - default=false)<br/>
+SetHostnameAsFQDN=true|false (ALPHA - default=false)<br/>
+StartupProbe=true|false (BETA - default=true)<br/>
+StorageVersionHash=true|false (BETA - default=true)<br/>
+SupportNodePidsLimit=true|false (BETA - default=true)<br/>
+SupportPodPidsLimit=true|false (BETA - default=true)<br/>
+Sysctls=true|false (BETA - default=true)<br/>
+TTLAfterFinished=true|false (ALPHA - default=false)<br/>
+TokenRequest=true|false (BETA - default=true)<br/>
+TokenRequestProjection=true|false (BETA - default=true)<br/>
+TopologyManager=true|false (BETA - default=true)<br/>
+ValidateProxyRedirects=true|false (BETA - default=true)<br/>
+VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>
+WarningHeaders=true|false (BETA - default=true)<br/>
+WinDSR=true|false (ALPHA - default=false)<br/>
+WinOverlay=true|false (ALPHA - default=false)<br/>
+WindowsEndpointSliceProxying=true|false (ALPHA - default=false)<br/>
+(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--file-check-frequency duration</td>
+<td colspan="2">--file-check-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `20s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Duration between checking config files for new data (default 20s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Duration between checking config files for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--global-housekeeping-interval duration</td>
+<td colspan="2">--global-housekeeping-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `1m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between global housekeepings (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between global housekeepings. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
     
 <tr>
-<td colspan="2">--hairpin-mode string</td>
+<td colspan="2">--hairpin-mode string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `promiscuous-bridge`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">How should the kubelet setup hairpin NAT. This allows endpoints of a Service to loadbalance back to themselves if they should try to access their own Service. Valid values are "promiscuous-bridge", "hairpin-veth" and "none". (default "promiscuous-bridge") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">How should the kubelet setup hairpin NAT. This allows endpoints of a Service to load balance back to themselves if they should try to access their own Service. Valid values are `promiscuous-bridge`, `hairpin-veth` and `none`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--healthz-bind-address 0.0.0.0</td>
+<td colspan="2">--healthz-bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `127.0.0.1`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the healthz server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 127.0.0.1) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the healthz server to serve on (set to `0.0.0.0` for all IPv4 interfaces and `::` for all IPv6 interfaces). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--healthz-port int32</td>
+<td colspan="2">--healthz-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10248</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The port of the localhost healthz endpoint (set to 0 to disable) (default 10248) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The port of the localhost healthz endpoint (set to `0` to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
@@ -604,119 +681,126 @@ kubelet [flags]
 <td colspan="2">--hostname-override string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, will use this string as identification instead of the actual hostname. If --cloud-provider is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If non-empty, will use this string as identification instead of the actual hostname. If `--cloud-provider` is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).</td>
 </tr>
 
 <tr>
-<td colspan="2">--housekeeping-interval duration</td>
+<td colspan="2">--housekeeping-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `10s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between container housekeepings (default 10s)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between container housekeepings.</td>
 </tr>
 
 <tr>
-<td colspan="2">--http-check-frequency duration</td>
+<td colspan="2">--http-check-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `20s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Duration between checking http for new data (default 20s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Duration between checking HTTP for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--image-gc-high-threshold int32</td>
+<td colspan="2">--image-gc-high-threshold int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 85</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100.  (default 85) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100.   (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--image-gc-low-threshold int32</td>
+<td colspan="2">--image-gc-low-threshold int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 80</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of --image-gc-high-threshold. (default 80) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of `--image-gc-high-threshold`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--image-pull-progress-deadline duration</td>
+<td colspan="2">--image-pull-progress-deadline duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `1m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to docker. (default 1m0s)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
 <td colspan="2">--image-service-endpoint string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote image service. If not specified, it will be the same with container-runtime-endpoint by default. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows.  Examples:'unix:///var/run/dockershim.sock', 'npipe:////./pipe/dockershim'</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote image service. If not specified, it will be the same with `--container-runtime-endpoint` by default. Currently UNIX socket endpoint is supported on Linux, while npipe and TCP endpoints are supported on Windows.  Examples: `unix:///var/run/dockershim.sock`, `npipe:////./pipe/dockershim`</td>
 </tr>
     
 <tr>
-<td colspan="2">--iptables-drop-bit int32</td>
+<td colspan="2">--iptables-drop-bit int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 15</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The bit of the `fwmark` space to mark packets for dropping. Must be within the range [0, 31]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
     
 <tr>
-<td colspan="2">--iptables-masquerade-bit int32</td>
+<td colspan="2">--iptables-masquerade-bit int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 14</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (default 14) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The bit of the `fwmark` space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in `kube-proxy`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
     
 <tr>
 <td colspan="2">--keep-terminated-pod-volumes</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Keep terminated pod volumes mounted to the node after the pod terminates.  Can be useful for debugging volume related issues. (DEPRECATED: will be removed in a future version)</td>
-</tr>
-    
-<tr>
-<td colspan="2">--kube-api-burst int32</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"> Burst to use while talking with kubernetes apiserver (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Keep terminated pod volumes mounted to the node after the pod terminates. Can be useful for debugging volume related issues. (DEPRECATED: will be removed in a future version)</td>
 </tr>
 
 <tr>
-<td colspan="2">--kube-api-content-type string</td>
+<td colspan="2">--kernel-memcg-notification</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--kube-api-qps int32</td>
+<td colspan="2">--kube-api-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">QPS to use while talking with kubernetes apiserver (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"> Burst to use while talking with kubernetes API server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--kube-reserved mapStringString</td>
+<td colspan="2">--kube-api-content-type string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `application/vnd.kubernetes.protobuf`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral storage for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Content type of requests sent to apiserver. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--kube-reserved-cgroup string</td>
+<td colspan="2">--kube-api-qps int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via '--kube-reserved' flag. Ex. '/kube-reserved'. [default=''] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">QPS to use while talking with kubernetes API server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+</tr>
+
+<tr>
+<td colspan="2">--kube-reserved mapStringString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: &lt;None&gt;</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of `<resource name>=<resource quantity>` (e.g. `cpu=200m,memory=500Mi,ephemeral-storage=1Gi`) pairs that describe resources reserved for kubernetes system components. Currently `cpu`, `memory` and local `ephemeral-storage` for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+</tr>
+
+<tr>
+<td colspan="2">--kube-reserved-cgroup string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `''`</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via `--kube-reserved` flag. Ex. `/kube-reserved`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--kubeconfig string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeconfig file, specifying how to connect to the API server. Providing --kubeconfig enables API server mode, omitting --kubeconfig enables standalone mode. </td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeconfig file, specifying how to connect to the API server. Providing `--kubeconfig` enables API server mode, omitting `--kubeconfig` enables standalone mode. </td>
 </tr>
 
 <tr>
 <td colspan="2">--kubelet-cgroups string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
@@ -727,10 +811,10 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--log-backtrace-at traceLocation</td>
+<td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `:0`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">when logging hits line file:N, emit a stack trace (default :0)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">When logging hits line `<file>:<N>`, emit a stack trace.</td>
 </tr>
 
 <tr>
@@ -755,114 +839,121 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--log-file-max-size uint</td>
+<td colspan="2">--log-file-max-size uint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1800</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.</td>
 </tr>
 
 <tr>
-<td colspan="2">--log-flush-frequency duration</td>
+<td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `5s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes (default 5s)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of seconds between log flushes.</td>
 </tr>
 
 <tr>
-<td colspan="2">--logtostderr</td>
+<td colspan="2">--logging-format string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `text`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error instead of files (default true)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Sets the log format. Permitted formats: `text`, `json`.\nNon-default formats don't honor these flags: `--add-dir-header`, `--alsologtostderr`, `--log-backtrace-at`, `--log_dir`, `--log-file`, `--log-file-max-size`, `--logtostderr`, `--skip_headers`, `--skip_log_headers`, `--stderrthreshold`, `--log-flush-frequency`.\nNon-default choices are currently alpha and subject to change without warning. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--machine-id-file string</td>
+<td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for machine-id. Use the first one that exists. (default "/etc/machine-id,/var/lib/dbus/machine-id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error instead of files.</td>
 </tr>
 
 <tr>
-<td colspan="2">--make-iptables-util-chains</td>
+<td colspan="2">--machine-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/etc/machine-id,/var/lib/dbus/machine-id`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, kubelet will ensure iptables utility rules are present on host. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for `machine-id`. Use the first one that exists. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+</tr>
+
+<tr>
+<td colspan="2">--make-iptables-util-chains&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, kubelet will ensure `iptables` utility rules are present on host. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--manifest-url string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"> URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'</td>
+<td colspan="2">--manifest-url-header string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of HTTP headers to use when accessing the url provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of HTTP headers to use when accessing the URL provided to `--manifest-url`. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: `--manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'` (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 <tr>
-<td colspan="2">--master-service-namespace string</td>
+<td colspan="2">--master-service-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `default`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The namespace from which the kubernetes master services should be injected into pods (default "default") (DEPRECATED: This flag will be removed in a future version.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The namespace from which the kubernetes master services should be injected into pods. (DEPRECATED: This flag will be removed in a future version.)</td>
 </tr>
     
 <tr>
-<td colspan="2">--max-open-files int</td>
+<td colspan="2">--max-open-files int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1000000</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Number of files that can be opened by Kubelet process. (default 1000000) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Number of files that can be opened by Kubelet process. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--max-pods int32</td>
+<td colspan="2">--max-pods int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 110</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Number of Pods that can run on this Kubelet. (default 110) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Number of Pods that can run on this Kubelet. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--maximum-dead-containers int32</td>
+<td colspan="2">--maximum-dead-containers int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: -1</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of old instances of containers to retain globally.  Each container takes up some disk space. To disable, set to a negative number. (default -1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (DEPRECATED: Use `--eviction-hard` or `--eviction-soft` instead. Will be removed in a future version.)</td>
 </tr>
 
  <tr>
-<td colspan="2">--maximum-dead-containers-per-container int32</td>
+<td colspan="2">--maximum-dead-containers-per-container int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of old instances to retain per container.  Each container takes up some disk space. (default 1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum number of old instances to retain per container.  Each container takes up some disk space. (DEPRECATED: Use `--eviction-hard` or `--eviction-soft` instead. Will be removed in a future version.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--minimum-container-ttl-duration duration</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum age for a finished container before it is garbage collected.  Examples: '300ms', '10s' or '2h45m' (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum age for a finished container before it is garbage collected.  Examples: `300ms`, `10s` or `2h45m` (DEPRECATED: Use `--eviction-hard` or `--eviction-soft` instead. Will be removed in a future version.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--minimum-image-ttl-duration duration</td>
+<td colspan="2">--minimum-image-ttl-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `2m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum age for an unused image before it is garbage collected.  Examples: '300ms', '10s' or '2h45m'. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum age for an unused image before it is garbage collected.  Examples: `300ms`, `10s` or `2h45m`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--network-plugin string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to docker.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
 <td colspan="2">--network-plugin-mtu int32</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The MTU to be passed to the network plugin, to override the default. Set to 0 to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to docker.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The MTU to be passed to the network plugin, to override the default. Set to `0` to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
@@ -876,189 +967,196 @@ kubelet [flags]
 <td colspan="2">--node-labels mapStringString</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; Labels to add when registering the node in the cluster.  Labels must be key=value pairs separated by ','. Labels in the 'kubernetes.io' namespace must begin with an allowed prefix (kubelet.kubernetes.io, node.kubernetes.io) or be in the specifically allowed set (beta.kubernetes.io/arch, beta.kubernetes.io/instance-type, beta.kubernetes.io/os, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt;Labels to add when registering the node in the cluster. Labels must be `key=value pairs` separated by `,`. Labels in the `kubernetes.io` namespace must begin with an allowed prefix (`kubelet.kubernetes.io`, `node.kubernetes.io`) or be in the specifically allowed set (`beta.kubernetes.io/arch`, `beta.kubernetes.io/instance-type`, `beta.kubernetes.io/os`, `failure-domain.beta.kubernetes.io/region`, `failure-domain.beta.kubernetes.io/zone`, `kubernetes.io/arch`, `kubernetes.io/hostname`, `kubernetes.io/os`, `node.kubernetes.io/instance-type`, `topology.kubernetes.io/region`, `topology.kubernetes.io/zone`)</td>
 </tr>
 
 <tr>
-<td colspan="2">--node-status-max-images int32</td>
+<td colspan="2">--node-status-max-images int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 50</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The maximum number of images to report in Node.Status.Images. If -1 is specified, no cap will be applied. (default 50)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The maximum number of images to report in `node.status.images`. If `-1` is specified, no cap will be applied. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--node-status-update-frequency duration</td>
+<td colspan="2">--node-status-update-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `10s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller. (default 10s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in Node controller. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--non-masquerade-cidr string</td>
+<td colspan="2">--non-masquerade-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `10.0.0.0/8`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade. (default "10.0.0.0/8") (DEPRECATED: will be removed in a future version)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Traffic to IPs outside this range will use IP masquerade. Set to `0.0.0.0/0` to never masquerade. (DEPRECATED: will be removed in a future version)</td>
 </tr>
 
 <tr>
-<td colspan="2">--oom-score-adj int32</td>
+<td colspan="2">--oom-score-adj int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: -999</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000] (default -999) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--pod-cidr string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The CIDR to use for pod IP addresses, only used in standalone mode.  In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--pod-infra-container-image string</td>
+<td colspan="2">--pod-infra-container-image string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `k8s.gcr.io/pause:3.2`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The image whose network/ipc namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to docker. (default "k8s.gcr.io/pause:3.2")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The image whose network/IPC namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to `docker`.</td>
 </tr>
 
 <tr>
 <td colspan="2">--pod-manifest-path string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--pod-max-pids int</td>
+<td colspan="2">--pod-max-pids int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: -1</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Set the maximum number of processes per pod.  If -1, the kubelet defaults to the node allocatable pid capacity. (default -1) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Set the maximum number of processes per pod.  If `-1`, the kubelet defaults to the node allocatable PID capacity. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--pods-per-core int32</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Number of Pods per core that can run on this Kubelet. The total number of Pods on this Kubelet cannot exceed max-pods, so max-pods will be used if this calculation results in a larger number of Pods allowed on the Kubelet. A value of 0 disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Number of Pods per core that can run on this Kubelet. The total number of Pods on this Kubelet cannot exceed `--max-pods`, so `--max-pods` will be used if this calculation results in a larger number of Pods allowed on the Kubelet. A value of `0` disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--port int32</td>
+<td colspan="2">--port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10250</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The port for the Kubelet to serve on. (default 10250) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The port for the Kubelet to serve on. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--protect-kernel-defaults</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"> Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"> Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--provider-id string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Unique identifier for identifying the node in a machine database, i.e cloudprovider</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Unique identifier for identifying the node in a machine database, i.e cloud provider. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--qos-reserved mapStringString</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; A set of ResourceName=Percentage (e.g. memory=50%) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the QOSReserved feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; A set of `<resource name>=<percentage>` (e.g. `memory=50%`) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the `QOSReserved` feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--read-only-port int32</td>
+<td colspan="2">--read-only-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10255</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The read-only port for the Kubelet to serve on with no authentication/authorization (set to `0` to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--really-crash-for-testing</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, when panics occur crash. Intended for testing.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, when panics occur crash. Intended for testing. (DEPRECATED: will be removed in a future version.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--redirect-container-streaming</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables container streaming redirect. If false, kubelet will proxy container streaming data between apiserver and container runtime; if true, kubelet will return an http redirect to apiserver, and apiserver will access container runtime directly. The proxy approach is more secure, but introduces some overhead. The redirect approach is more performant, but less secure because the connection between apiserver and container runtime may not be authenticated.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Enables container streaming redirect. If false, kubelet will proxy container streaming data between the API server and container runtime; if `true`, kubelet will return an HTTP redirect to the API server, and the API server will access container runtime directly. The proxy approach is more secure, but introduces some overhead. The redirect approach is more performant, but less secure because the connection between apiserver and container runtime may not be authenticated. (DEPRECATED: Container streaming redirection will be removed from the kubelet in v1.20, and this flag will be removed in v1.22. For more details, see http://git.k8s.io/enhancements/keps/sig-node/20191205-container-streaming-requests.md)</td>
 </tr>
 
 <tr>
 <td colspan="2">--register-node</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Register the node with the apiserver. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an apiserver to register with. Default=true. (default true)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Register the node with the API server. If `--kubeconfig` is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with. Default to `true`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--register-schedulable</td>
+<td colspan="2">--register-schedulable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Register the node as schedulable. Won't have any effect if register-node is false. (default true) (DEPRECATED: will be removed in a future version)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Register the node as schedulable. Won't have any effect if `--register-node` is false. (DEPRECATED: will be removed in a future version)</td>
   </tr>
 
 <tr>
 <td colspan="2">--register-with-taints []api.Taint</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Register the node with the given list of taints (comma separated "<key>=<value>:<effect>"). No-op if register-node is false.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `--register-node` is `false`.</td>
 </tr>
 
 <tr>
-<td colspan="2">--registry-burst int32</td>
+<td colspan="2">--registry-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding `--registry-qps`. Only used if `--registry-qps > 0`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--registry-qps int32</td>
+<td colspan="2">--registry-qps int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If > 0, limit registry pull QPS to this value.  If 0, unlimited. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If &gt; 0, limit registry pull QPS to this value.  If `0`, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--resolv-conf string</td>
+<td colspan="2">--reserved-cpus string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Resolver configuration file used as the basis for the container DNS resolution configuration. (default "/etc/resolv.conf") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A comma-separated list of CPUs or CPU ranges that are reserved for system and kubernetes usage. This specific list will supersede cpu counts in `--system-reserved` and `--kube-reserved`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--root-dir string</td>
+<td colspan="2">--resolv-conf string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/etc/resolv.conf`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Directory path for managing kubelet files (volume mounts,etc). (default "/var/lib/kubelet")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Resolver configuration file used as the basis for the container DNS resolution configuration. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+</tr>
+
+<tr>
+<td colspan="2">--root-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/var/lib/kubelet`</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Directory path for managing kubelet files (volume mounts, etc).</td>
 </tr>
 
 <tr>
 <td colspan="2">--rotate-certificates</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Beta feature&gt; Auto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Beta feature&gt; Auto rotate the kubelet client certificates by requesting new certificates from the `kube-apiserver` when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--rotate-server-certificates</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Auto-request and rotate the kubelet serving certificates by requesting new certificates from the `kube-apiserver` when the certificate expiration approaches. Requires the `RotateKubeletServerCertificate` feature gate to be enabled, and approval of the submitted `CertificateSigningRequest` objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--runonce</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If `true`, exit after spawning pods from local manifests or remote urls. Exclusive with `--enable-server` (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
@@ -1069,172 +1167,176 @@ kubelet [flags]
 </tr>
 
 <tr>
-<td colspan="2">--runtime-request-timeout duration</td>
+<td colspan="2">--runtime-request-timeout duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `2m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Timeout of all runtime requests except long running request - pull, logs, exec and attach. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Timeout of all runtime requests except long running request - `pull`, `logs`, `exec` and `attach`. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--seccomp-profile-root string</td>
+<td colspan="2">--seccomp-profile-root string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/var/lib/kubelet/seccomp`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; Directory path for seccomp profiles. (default "/var/lib/kubelet/seccomp")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; Directory path for seccomp profiles. (DEPRECATED: will be removed in 1.23, in favor of using the `<root-dir>/seccomp` directory)
+</td>
 </tr>
 
 <tr>
-<td colspan="2">--serialize-image-pulls</td>
+<td colspan="2">--serialize-image-pulls&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `true`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an Aufs storage backend. Issue #10959 has more details. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version &lt; 1.9 or an `aufs` storage backend. Issue #10959 has more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--skip-headers</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, avoid header prefixes in the log messages</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If `true`, avoid header prefixes in the log messages</td>
 </tr>
 
 <tr>
 <td colspan="2">--skip-log-headers</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, avoid headers when opening log files</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If `true`, avoid headers when opening log files</td>
 </tr>
 
 <tr>
-<td colspan="2">--stderrthreshold severity</td>
+<td colspan="2">--stderrthreshold severity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 2</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">logs at or above this threshold go to stderr (default 2)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">logs at or above this threshold go to stderr.</td>
 </tr>
 
 <tr>
-<td colspan="2">--storage-driver-buffer-duration duration</td>
+<td colspan="2">--storage-driver-buffer-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `1m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--storage-driver-db string</td>
+<td colspan="2">--storage-driver-db string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `cadvisor`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">database name (default "cadvisor") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Database name. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--storage-driver-host string</td>
+<td colspan="2">--storage-driver-host string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `localhost:8086`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">database host:port (default "localhost:8086") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Database `host:port`. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--storage-driver-password string</td>
+<td colspan="2">--storage-driver-password string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `root`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">database password (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Database password. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--storage-driver-secure</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">use secure connection with database (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Use secure connection with database (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--storage-driver-table string</td>
+<td colspan="2">--storage-driver-table string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `stats`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">table name (default "stats") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Table name. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--storage-driver-user string</td>
+<td colspan="2">--storage-driver-user string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `root`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">database username (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Database username. (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--streaming-connection-idle-timeout duration</td>
+<td colspan="2">--streaming-connection-idle-timeout duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `4h0m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: '5m' (default 4h0m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Maximum time a streaming connection can be idle before the connection is automatically closed. `0` indicates no timeout. Example: `5m`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--sync-frequency duration</td>
+<td colspan="2">--sync-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `1m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Max period between synchronizing running containers and config (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Max period between synchronizing running containers and config. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--system-cgroups /</td>
+<td colspan="2">--system-cgroups string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under /. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under `/`. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--system-reserved mapStringString</td>
+<td colspan="2">--system-reserved mapStringString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: \<none\></td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of `<resource name>=<resource quantity>` (e.g. `cpu=200m,memory=500Mi,ephemeral-storage=1Gi`) pairs that describe resources reserved for non-kubernetes components. Currently only `cpu` and `memory` are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--system-reserved-cgroup string</td>
+<td colspan="2">--system-reserved-cgroup string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `''`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via '--system-reserved' flag. Ex. '/system-reserved'. [default=''] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via `--system-reserved` flag. Ex. `/system-reserved`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--tls-cert-file string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If `--tls-cert-file` and `--tls-private-key-file` are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to `--cert-dir`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--tls-cipher-suites stringSlice</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.<br/>
+Preferred values:
+TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.<br/> 
+Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
 </tr>
 
 <tr>
 <td colspan="2">--tls-min-version string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum TLS version supported. Possible values: `VersionTLS10`, `VersionTLS11`, `VersionTLS12`, `VersionTLS13` (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">--tls-private-key-file string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">File containing x509 private key matching --tls-cert-file. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">File containing x509 private key matching `--tls-cert-file`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 
 <tr>
-<td colspan="2">--topology-manager-policy string</td>
+<td colspan="2">--topology-manager-policy string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `none`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (default "none") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Topology Manager policy to use. Possible values: `none`, `best-effort`, `restricted`, `single-numa-node`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
 <td colspan="2">-v, --v Level</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">number for the log level verbosity</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Number for the log level verbosity</td>
 </tr>
 
 <tr>
@@ -1248,21 +1350,21 @@ kubelet [flags]
 <td colspan="2">--vmodule moduleSpec</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">comma-separated list of pattern=N settings for file-filtered logging</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of `pattern=N` settings for file-filtered logging</td>
 </tr>
 
 <tr>
-<td colspan="2">--volume-plugin-dir string</td>
+<td colspan="2">--volume-plugin-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The full path of the directory in which to search for additional third party volume plugins (default "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The full path of the directory in which to search for additional third party volume plugins. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 
 <tr>
-<td colspan="2">--volume-stats-agg-period duration</td>
+<td colspan="2">--volume-stats-agg-period duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: `1m0s`</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes.  To disable volume calculations, set to 0. (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to `0`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
 </tr>
 </tbody>
 </table>
diff --git a/content/en/docs/reference/glossary/cloud-provider.md b/content/en/docs/reference/glossary/cloud-provider.md
index 84b4d6fcac..c9f3f11fb5 100755
--- a/content/en/docs/reference/glossary/cloud-provider.md
+++ b/content/en/docs/reference/glossary/cloud-provider.md
@@ -2,7 +2,6 @@
 title: Cloud Provider
 id: cloud-provider
 date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
 short_description: >
   An organization that offers a cloud computing platform.
 
diff --git a/content/en/docs/reference/glossary/container.md b/content/en/docs/reference/glossary/container.md
index 762a4fdcd5..cbf1f80fba 100755
--- a/content/en/docs/reference/glossary/container.md
+++ b/content/en/docs/reference/glossary/container.md
@@ -2,7 +2,7 @@
 title: Container
 id: container
 date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /docs/concepts/containers/
 short_description: >
   A lightweight and portable executable image that contains software and all of its dependencies.
 
diff --git a/content/en/docs/reference/glossary/kubelet.md b/content/en/docs/reference/glossary/kubelet.md
index 92073a5347..e442fe29f0 100755
--- a/content/en/docs/reference/glossary/kubelet.md
+++ b/content/en/docs/reference/glossary/kubelet.md
@@ -9,7 +9,6 @@ short_description: >
 aka:
 tags:
 - fundamental
-- core-object
 ---
  An agent that runs on each {{< glossary_tooltip text="node" term_id="node" >}} in the cluster. It makes sure that {{< glossary_tooltip text="containers" term_id="container" >}} are running in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
 
diff --git a/content/en/docs/reference/glossary/object.md b/content/en/docs/reference/glossary/object.md
new file mode 100755
index 0000000000..1e3a6165fd
--- /dev/null
+++ b/content/en/docs/reference/glossary/object.md
@@ -0,0 +1,19 @@
+---
+title: Object
+id: object
+date: 2020-10-12
+full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
+short_description: >
+   A entity in the Kubernetes system, representing part of the state of your cluster.
+aka: 
+tags:
+- fundamental
+---
+An entity in the Kubernetes system. The Kubernetes API uses these entities to represent the state
+of your cluster.
+<!--more-->
+A Kubernetes object is typically a “record of intent”—once you create the object, the Kubernetes
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}} works constantly to ensure
+that the item it represents actually exists.
+By creating an object, you're effectively telling the Kubernetes system what you want that part of
+your cluster's workload to look like; this is your cluster's desired state.
diff --git a/content/en/docs/reference/glossary/platform-developer.md b/content/en/docs/reference/glossary/platform-developer.md
index ed961c27f2..8489aea94e 100755
--- a/content/en/docs/reference/glossary/platform-developer.md
+++ b/content/en/docs/reference/glossary/platform-developer.md
@@ -14,8 +14,8 @@ tags:
 
 <!--more--> 
 
-A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) or
-[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)
+A platform developer may, for example, use [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) or
+[Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
 to add functionality to their instance of Kubernetes, specifically for their application.
 Some Platform Developers are also {{< glossary_tooltip text="contributors" term_id="contributor" >}} and
 develop extensions which are contributed to the Kubernetes community.
diff --git a/content/en/docs/reference/glossary/rkt.md b/content/en/docs/reference/glossary/rkt.md
deleted file mode 100644
index 165bce5406..0000000000
--- a/content/en/docs/reference/glossary/rkt.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: rkt
-id: rkt
-date: 2019-01-24
-full_link: https://coreos.com/rkt/
-short_description: >
-  A security-minded, standards-based container engine.
-
-aka: 
-tags:
-- security
-- tool
----
- A security-minded, standards-based container engine.
-
-<!--more--> 
-
-rkt is an application {{< glossary_tooltip text="container" term_id="container" >}} engine featuring a {{< glossary_tooltip text="Pod" term_id="pod" >}}-native approach, a pluggable execution environment, and a well-defined surface area. rkt allows users to apply different configurations at both the Pod and application level. Each Pod executes directly in the classic Unix process model, in a self-contained, isolated environment.
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index e20826ca43..8ff32aa54e 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -90,6 +90,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # create from multiple files
 kubectl apply -f ./dir                         # create resource(s) in all manifest files in dir
 kubectl apply -f https://git.io/vPieo          # create resource(s) from url
 kubectl create deployment nginx --image=nginx  # start a single instance of nginx
+
+# create a Job which prints "Hello World"
+kubectl create job hello --image=busybox -- echo "Hello World" 
+
+# create a CronJob that prints "Hello World" every minute
+kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"    
+
 kubectl explain pods                           # get the documentation for pod manifests
 
 # Create multiple YAML objects from stdin
diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md
index 062847c485..9f0d2efe8b 100644
--- a/content/en/docs/reference/kubectl/conventions.md
+++ b/content/en/docs/reference/kubectl/conventions.md
@@ -29,14 +29,14 @@ For `kubectl run` to satisfy infrastructure as code:
 * Check in the script for an image that is heavily parameterized.
 * Switch to configuration files checked into source control for features that are needed, but not expressible via `kubectl run` flags.
 
-You can use the `--dry-run` flag to preview the object that would be sent to your cluster, without really submitting it.
+You can use the `--dry-run=client` flag to preview the object that would be sent to your cluster, without really submitting it.
 
 {{< note >}}
 All `kubectl` generators are deprecated. See the Kubernetes v1.17 documentation for a [list](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) of generators and how they were used.
 {{< /note >}}
 
 #### Generators
-You can generate the following resources with a kubectl command, `kubectl create --dry-run -o yaml`:
+You can generate the following resources with a kubectl command, `kubectl create --dry-run=client -o yaml`:
 ```
   clusterrole         Create a ClusterRole.
   clusterrolebinding  Create a ClusterRoleBinding for a particular ClusterRole.
diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
index af0ba73b90..5afdebd557 100644
--- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
+++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
@@ -42,6 +42,7 @@ kubectl create deployment --image=nginx nginx-app
 # add env to nginx-app
 kubectl set env deployment/nginx-app  DOMAIN=cluster
 ```
+```
 deployment.apps/nginx-app created
 ```
 
@@ -52,7 +53,6 @@ kubectl set env deployment/nginx-app  DOMAIN=cluster
 ```
 deployment.apps/nginx-app env updated
 ```
-deployment.apps/nginx-app env updated
 
 {{< note >}}
 `kubectl` commands print the type and name of the resource created or mutated, which can then be used in subsequent commands. You can expose a new Service after a Deployment is created.
diff --git a/content/en/docs/reference/kubectl/jsonpath.md b/content/en/docs/reference/kubectl/jsonpath.md
index 50c051c9f4..d26c110cee 100644
--- a/content/en/docs/reference/kubectl/jsonpath.md
+++ b/content/en/docs/reference/kubectl/jsonpath.md
@@ -98,4 +98,16 @@ kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.
 ```
 {{< /note >}}
 
+{{< note >}}
 
+JSONPath regular expressions are not supported. If you want to match using regular expressions, you can use a tool such as `jq`.
+
+```shell
+# kubectl does not support regular expressions for JSONpath output
+# The following command does not work
+kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'
+
+# The following command achieves the desired result
+kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
+```
+{{< /note >}}
diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md
index a9177da9f5..a9f1550659 100644
--- a/content/en/docs/reference/kubectl/overview.md
+++ b/content/en/docs/reference/kubectl/overview.md
@@ -61,7 +61,7 @@ for example `create`, `get`, `describe`, `delete`.
    * To specify resources with one or more files:  `-f file1 -f file2 -f file<#>`
 
       * [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-configuration-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
-     Example: `kubectl get pod -f ./pod.yaml`
+     Example: `kubectl get -f ./pod.yaml`
 
 * `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.<br/>
 
@@ -127,14 +127,15 @@ To learn more about command operations, see the [kubectl](/docs/reference/kubect
 
 The following table includes a list of all the supported resource types and their abbreviated aliases.
 
-(This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.13.3.)
+(This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.19.1.)
 
-| Resource Name | Short Names | API Group | Namespaced | Resource Kind |
+| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
 |---|---|---|---|---|
-| `bindings` | | | true | Binding|
+| `bindings` | | | true | Binding |
 | `componentstatuses` | `cs` | | false | ComponentStatus |
 | `configmaps` | `cm` | | true | ConfigMap |
 | `endpoints` | `ep` | | true | Endpoints |
+| `events` | `ev` | | true | Event |
 | `limitranges` | `limits` | | true | LimitRange |
 | `namespaces` | `ns` | | false | Namespace |
 | `nodes` | `no` | | false | Node |
@@ -142,14 +143,14 @@ The following table includes a list of all the supported resource types and thei
 | `persistentvolumes` | `pv` | | false | PersistentVolume |
 | `pods` | `po` | | true | Pod |
 | `podtemplates` | | | true | PodTemplate |
-| `replicationcontrollers` | `rc` | | true| ReplicationController |
+| `replicationcontrollers` | `rc` | | true | ReplicationController |
 | `resourcequotas` | `quota` | | true | ResourceQuota |
 | `secrets` | | | true | Secret |
 | `serviceaccounts` | `sa` | | true | ServiceAccount |
 | `services` | `svc` | | true | Service |
 | `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
 | `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
-| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
+| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
 | `apiservices` | | apiregistration.k8s.io | false | APIService |
 | `controllerrevisions` | | apps | true | ControllerRevision |
 | `daemonsets` | `ds` | apps | true | DaemonSet |
@@ -166,9 +167,15 @@ The following table includes a list of all the supported resource types and thei
 | `jobs` | | batch | true | Job |
 | `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
 | `leases` | | coordination.k8s.io | true | Lease |
+| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
 | `events` | `ev` | events.k8s.io | true | Event |
 | `ingresses` | `ing` | extensions | true | Ingress |
+| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
+| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
+| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
+| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
 | `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
+| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
 | `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
 | `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
 | `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
@@ -178,7 +185,7 @@ The following table includes a list of all the supported resource types and thei
 | `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
 | `csidrivers` | | storage.k8s.io | false | CSIDriver |
 | `csinodes` | | storage.k8s.io | false | CSINode |
-| `storageclasses` | `sc` | storage.k8s.io |  false | StorageClass |
+| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
 | `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
 
 ## Output options
diff --git a/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
index d1faa51a88..b0ef5d5a65 100644
--- a/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
+++ b/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md
@@ -38,7 +38,7 @@ This label has been deprecated. Please use `kubernetes.io/arch` instead.
 
 This label has been deprecated. Please use `kubernetes.io/os` instead.
 
-## kubernetes.io/hostname
+## kubernetes.io/hostname {#kubernetesiohostname}
 
 Example: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal`
 
@@ -46,6 +46,8 @@ Used on: Node
 
 The Kubelet populates this label with the hostname. Note that the hostname can be changed from the "actual" hostname by passing the `--hostname-override` flag to the `kubelet`.
 
+This label is also used as part of the topology hierarchy.  See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information.
+
 ## beta.kubernetes.io/instance-type (deprecated)
 
 {{< note >}} Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). {{< /note >}}
@@ -63,71 +65,52 @@ to rely on the Kubernetes scheduler to perform resource-based scheduling. You sh
 
 ## failure-domain.beta.kubernetes.io/region (deprecated) {#failure-domainbetakubernetesioregion}
 
-See [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone).
+See [topology.kubernetes.io/region](#topologykubernetesioregion).
 
 {{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/region](#topologykubernetesioregion). {{< /note >}}
 
 ## failure-domain.beta.kubernetes.io/zone (deprecated) {#failure-domainbetakubernetesiozone}
 
-Example:
-
-`failure-domain.beta.kubernetes.io/region=us-east-1`
-
-`failure-domain.beta.kubernetes.io/zone=us-east-1c`
-
-Used on: Node, PersistentVolume
-
-On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
-This will be set only if you are using a `cloudprovider`. However, you should consider setting this
-on the nodes if it makes sense in your topology.
-
-On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
-
-Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
-
-_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
-
-The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
-
-The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
-The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
-
-If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
-adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
+See [topology.kubernetes.io/zone](#topologykubernetesiozone).
 
 {{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< /note >}}
 
 ## topology.kubernetes.io/region {#topologykubernetesioregion}
 
+Example:
+
+`topology.kubernetes.io/region=us-east-1`
+
 See [topology.kubernetes.io/zone](#topologykubernetesiozone).
 
 ## topology.kubernetes.io/zone {#topologykubernetesiozone}
 
 Example:
 
-`topology.kubernetes.io/region=us-east-1`
-
 `topology.kubernetes.io/zone=us-east-1c`
 
 Used on: Node, PersistentVolume
 
-On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
-This will be set only if you are using a `cloudprovider`. However, you should consider setting this
-on the nodes if it makes sense in your topology.
+On Node: The `kubelet` or the external `cloud-controller-manager` populates this with the information as provided by the `cloudprovider`.  This will be set only if you are using a `cloudprovider`. However, you should consider setting this on nodes if it makes sense in your topology.
 
-On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
+On PersistentVolume: topology-aware volume provisioners will automatically set node affinity constraints on `PersistentVolumes`.
 
-Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
+A zone represents a logical failure domain.  It is common for Kubernetes clusters to span multiple zones for increased availability.  While the exact definition of a zone is left to infrastructure implementations, common properties of a zone include very low network latency within a zone, no-cost network traffic within a zone, and failure independence from other zones.  For example, nodes within a zone might share a network switch, but nodes in different zones should not.
+
+A region represents a larger domain, made up of one or more zones.  It is uncommon for Kubernetes clusters to span multiple regions,  While the exact definition of a zone or region is left to infrastructure implementations, common properties of a region include higher network latency between them than within them, non-zero cost for network traffic between them, and failure independence from other zones or regions.  For example, nodes within a region might share power infrastructure (e.g. a UPS or generator), but nodes in different regions typically would not.
+
+Kubernetes makes a few assumptions about the structure of zones and regions:
+1) regions and zones are hierarchical: zones are strict subsets of regions and no zone can be in 2 regions
+2) zone names are unique across regions; for example region "africa-east-1" might be comprised of zones "africa-east-1a" and "africa-east-1b"
+
+It should be safe to assume that topology labels do not change.  Even though labels are strictly mutable, consumers of them can assume that a given node is not going to be moved between zones without being destroyed and recreated.
+
+Kubernetes can use this information in various ways.  For example, the scheduler automatically tries to spread the Pods in a ReplicaSet across nodes in a single-zone cluster (to reduce the impact of node failures, see [kubernetes.io/hostname](#kubernetesiohostname)). With multiple-zone clusters, this spreading behavior also applies to zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
 
 _SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
 
 The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
 
-The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
-The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
-
 If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
 adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
 
-
-
diff --git a/content/en/docs/reference/scheduling/config.md b/content/en/docs/reference/scheduling/config.md
index 530e881cbd..0dca862fb9 100644
--- a/content/en/docs/reference/scheduling/config.md
+++ b/content/en/docs/reference/scheduling/config.md
@@ -20,10 +20,7 @@ by implementing one or more of these extension points.
 
 You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
 using the component config APIs
-([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
-or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)).
-The `v1alpha2` API allows you to configure kube-scheduler to run
-[multiple profiles](#multiple-profiles).
+([`v1beta1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.19.0/config/v1beta1?tab=doc#KubeSchedulerConfiguration)).
 
 A minimal configuration looks as follows:
 
diff --git a/content/en/docs/reference/scheduling/policies.md b/content/en/docs/reference/scheduling/policies.md
index 9601b22ec4..946150322d 100644
--- a/content/en/docs/reference/scheduling/policies.md
+++ b/content/en/docs/reference/scheduling/policies.md
@@ -32,7 +32,7 @@ The following *predicates* implement filtering:
 - `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory)
   to meet the requirement of the Pod.
 
-- `PodMatchNodeSelector`: Checks if a Pod's Node {{< glossary_tooltip term_id="selector" >}}
+- `MatchNodeSelector`: Checks if a Pod's Node {{< glossary_tooltip term_id="selector" >}}
    matches the Node's {{< glossary_tooltip text="label(s)" term_id="label" >}}.
 
 - `NoVolumeZoneConflict`: Evaluate if the {{< glossary_tooltip text="Volumes" term_id="volume" >}}
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
index 21a6e628a8..f84c62c01d 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
@@ -12,6 +12,14 @@ weight: 90
  from the community. Please try it out and give us feedback!
 {{< /caution >}}
 
+## kubeadm alpha certs {#cmd-certs}
+
+A collection of operations for operating Kubernetes certificates.
+
+{{< tabs name="tab-certs" >}}
+{{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}}
+{{< /tabs >}}
+
 ## kubeadm alpha certs renew {#cmd-certs-renew}
 
 You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.
@@ -42,6 +50,15 @@ to enable the automatic copy of certificates when joining additional control-pla
 {{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}}
 {{< /tabs >}}
 
+## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr}
+
+This command can be used to generate certificate signing requests (CSRs) which
+can be submitted to a certificate authority (CA) for signing.
+
+{{< tabs name="tab-certs-generate-csr" >}}
+{{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}}
+{{< /tabs >}}
+
 ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration}
 
 This command checks expiration for the certificates in the local PKI managed by kubeadm.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
index 655f9ec875..23dff658e9 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md
@@ -16,6 +16,10 @@ You can use `kubeadm config print` to print the default configuration and `kubea
 convert your old configuration files to a newer version. `kubeadm config images list` and
 `kubeadm config images pull` can be used to list and pull the images that kubeadm requires.
 
+For more information navigate to
+[Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)
+or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file).
+
 In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image
 the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
 has to be used.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
index 289767e1e1..21ab7a863d 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
@@ -119,6 +119,17 @@ Use the following phase to configure bootstrap tokens.
 {{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}}
 {{< /tabs >}}
 
+## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all}
+
+Use the following phase to update settings relevant to the kubelet after TLS
+bootstrap. You can use the `all` subcommand to run all `kubelet-finalize`
+phases.
+
+{{< tabs name="tab-kubelet-finalize" >}}
+{{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}}
+{{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}}
+{{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}}
+{{< /tabs >}}
 
 ## kubeadm init phase addon {#cmd-phase-addon}
 
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 997240399e..7a210ba5de 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -114,16 +114,18 @@ The config file is still considered beta and may change in future versions.
 
 It's possible to configure `kubeadm init` with a configuration file instead of command
 line flags, and some more advanced features may only be available as
-configuration file options. This file is passed with the `--config` option.
+configuration file options. This file is passed using the `--config` flag and it must
+contain a `ClusterConfiguration` structure and optionally more structures separated by `---\n`
+Mixing `--config` with others flags may not be allowed in some cases.
 
 The default configuration can be printed out using the
 [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
-It is **recommended** that you migrate your old `v1beta1` configuration to `v1beta2` using
+If your configuration is not using the latest version it is **recommended** that you migrate using
 the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
-For more details on each field in the `v1beta2` configuration you can navigate to our
-[API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2).
+For more information on the fields and usage of the configuration you can navigate to our API reference
+page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
 
 ### Adding kube-proxy parameters {#kube-proxy}
 
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index 28d489cfb6..0a39f70927 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -273,15 +273,17 @@ The config file is still considered beta and may change in future versions.
 It's possible to configure `kubeadm join` with a configuration file instead of command
 line flags, and some more advanced features may only be available as
 configuration file options. This file is passed using the `--config` flag and it must
-contain a `JoinConfiguration` structure.
+contain a `JoinConfiguration` structure. Mixing `--config` with others flags may not be
+allowed in some cases.
 
-To print the default values of `JoinConfiguration` run the following command:
+The default configuration can be printed out using the
+[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
-```shell
-kubeadm config print join-defaults
-```
+If your configuration is not using the latest version it is **recommended** that you migrate using
+the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
-For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration).
+For more information on the fields and usage of the configuration you can navigate to our API reference
+page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
index a7f4b6d1a6..1f712f912c 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
@@ -15,6 +15,7 @@ be called on a primary control-plane node.
 
 {{< tabs name="tab-phase" >}}
 {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}}
+{{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}}
 {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}}
 {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
 {{< /tabs >}}
diff --git a/content/en/docs/reference/tools.md b/content/en/docs/reference/tools.md
index ef210f2b07..ceeadbb279 100644
--- a/content/en/docs/reference/tools.md
+++ b/content/en/docs/reference/tools.md
@@ -20,7 +20,7 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes
 
 ## Minikube
 
-[`minikube`](/docs/tasks/tools/install-minikube/) is a tool that makes it
+[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that makes it
 easy to run a single-node Kubernetes cluster locally on your workstation for
 development and testing purposes.
 
@@ -44,7 +44,7 @@ Use Helm to:
 
 ## Kompose
 
-[`Kompose`](https://github.com/kubernetes-incubator/kompose) is a tool to help Docker Compose users move to Kubernetes.
+[`Kompose`](https://github.com/kubernetes/kompose) is a tool to help Docker Compose users move to Kubernetes.
 
 Use Kompose to:
 
diff --git a/content/en/docs/reference/using-api/_index.md b/content/en/docs/reference/using-api/_index.md
index 9d6b7c4e36..df9e00758e 100644
--- a/content/en/docs/reference/using-api/_index.md
+++ b/content/en/docs/reference/using-api/_index.md
@@ -1,4 +1,125 @@
 ---
-title: Using the Kubernetes API
+title: Kubernetes API Overview
+reviewers:
+- erictune
+- lavalamp
+- jbeda
+content_type: concept
 weight: 10
----
\ No newline at end of file
+card:
+  name: reference
+  weight: 50
+  title: Overview of API
+---
+
+<!-- overview -->
+
+This section provides reference information for the Kubernetes API.
+
+The REST API is the fundamental fabric of Kubernetes. All operations and
+communications between components, and external user commands are REST API
+calls that the API Server handles. Consequently, everything in the Kubernetes
+platform is treated as an API object and has a corresponding entry in the
+[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
+
+The [Kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+lists the API for Kubernetes version {{< param "version" >}}.
+
+For general background information, read
+[The Kubernetes API](/docs/concepts/overview/kubernetes-api/).
+[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/)
+describes how clients can authenticate to the Kubernetes API server, and how their
+requests are authorized.
+
+
+## API versioning
+
+The JSON and Protobuf serialization schemas follow the same guidelines for
+schema changes. The following descriptions cover both formats.
+
+The API versioning and software versioning are indirectly related.
+The [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
+describes the relationship between API versioning and software versioning.
+
+Different API versions indicate different levels of stability and support. You
+can find more information about the criteria for each level in the
+[API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).
+
+Here's a summary of each level:
+
+- Alpha:
+  - The version names contain `alpha` (for example, `v1alpha1`).
+  - The software may contain bugs. Enabling a feature may expose bugs. A
+    feature may be disabled by default.
+  - The support for a feature may be dropped at any time without notice.
+  - The API may change in incompatible ways in a later software release without notice.
+  - The software is recommended for use only in short-lived testing clusters,
+    due to increased risk of bugs and lack of long-term support.
+
+- Beta:
+  - The version names contain `beta` (for example, `v2beta3`).
+  - The software is well tested. Enabling a feature is considered safe.
+    Features are enabled by default.
+  - The support for a feature will not be dropped, though the details may change.
+
+  - The schema and/or semantics of objects may change in incompatible ways in
+    a subsequent beta or stable release. When this happens, migration
+    instructions are provided. Schema changes may require deleting, editing, and
+    re-creating API objects. The editing process may not be straightforward.
+    The migration may require downtime for applications that rely on the feature.
+  - The software is not recommended for production uses. Subsequent releases
+    may introduce incompatible changes. If you have multiple clusters which
+    can be upgraded independently, you may be able to relax this restriction.
+
+  {{< note >}}
+  Please try beta features and provide feedback. After the features exit beta, it
+  may not be practical to make more changes.
+  {{< /note >}}
+
+- Stable:
+  - The version name is `vX` where `X` is an integer.
+  - The stable versions of features appear in released software for many subsequent versions.
+
+## API groups
+
+[API groups](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)
+make it easier to extend the Kubernetes API.
+The API group is specified in a REST path and in the `apiVersion` field of a
+serialized object.
+
+There are several API groups in Kubernetes:
+
+*  The *core* (also called *legacy*) group is found at REST path `/api/v1`.
+   The core group is not specified as part of the `apiVersion` field, for
+   example, `apiVersion: v1`.
+*  The named groups are at REST path `/apis/$GROUP_NAME/$VERSION` and use
+   `apiVersion: $GROUP_NAME/$VERSION` (for example, `apiVersion: batch/v1`).
+   You can find the full list of supported API groups in
+   [Kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#-strong-api-groups-strong-).
+
+## Enabling or disabling API groups   {#enabling-or-disabling}
+
+Certain resources and API groups are enabled by default. You can enable or
+disable them by setting `--runtime-config` on the API server.  The
+`--runtime-config` flag accepts comma separated `<key>[=<value>]` pairs
+describing the runtime configuration of the API server. If the `=<value>`
+part is omitted, it is treated as if `=true` is specified. For example:
+
+ - to disable `batch/v1`, set `--runtime-config=batch/v1=false`
+ - to enable `batch/v2alpha1`, set `--runtime-config=batch/v2alpha1`
+
+{{< note >}}
+When you enable or disable groups or resources, you need to restart the API
+server and controller manager to pick up the `--runtime-config` changes.
+{{< /note >}}
+
+## Persistence
+
+Kubernetes stores its serialized state in terms of the API resources by writing them into
+{{< glossary_tooltip term_id="etcd" >}}.
+
+## {{% heading "whatsnext" %}}
+
+- Learn more about [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
+- Read the design documentation for
+  [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md
index a937d18598..5f8f8337d1 100644
--- a/content/en/docs/reference/using-api/api-concepts.md
+++ b/content/en/docs/reference/using-api/api-concepts.md
@@ -30,9 +30,12 @@ Kubernetes generally leverages standard RESTful terminology to describe the API
 All resource types are either scoped by the cluster (`/apis/GROUP/VERSION/*`) or to a namespace (`/apis/GROUP/VERSION/namespaces/NAMESPACE/*`). A namespace-scoped resource type will be deleted when its namespace is deleted and access to that resource type is controlled by authorization checks on the namespace scope. The following paths are used to retrieve collections and resources:
 
 * Cluster-scoped resources:
+
   * `GET /apis/GROUP/VERSION/RESOURCETYPE` - return the collection of resources of the resource type
   * `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME` - return the resource with NAME under the resource type
+
 * Namespace-scoped resources:
+
   * `GET /apis/GROUP/VERSION/RESOURCETYPE` - return the collection of all instances of the resource type across all namespaces
   * `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE` - return collection of all instances of the resource type in NAMESPACE
   * `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME` - return the instance of the resource type with NAME in NAMESPACE
@@ -57,33 +60,39 @@ For example:
 
 1. List all of the pods in a given namespace.
 
-        GET /api/v1/namespaces/test/pods
-        ---
-        200 OK
-        Content-Type: application/json
-        {
-          "kind": "PodList",
-          "apiVersion": "v1",
-          "metadata": {"resourceVersion":"10245"},
-          "items": [...]
-        }
+   ```console
+   GET /api/v1/namespaces/test/pods
+   ---
+   200 OK
+   Content-Type: application/json
+
+   {
+     "kind": "PodList",
+     "apiVersion": "v1",
+     "metadata": {"resourceVersion":"10245"},
+     "items": [...]
+   }
+   ```
 
 2. Starting from resource version 10245, receive notifications of any creates, deletes, or updates as individual JSON objects.
 
-        GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245
-        ---
-        200 OK
-        Transfer-Encoding: chunked
-        Content-Type: application/json
-        {
-          "type": "ADDED",
-          "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
-        }
-        {
-          "type": "MODIFIED",
-          "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...}
-        }
-        ...
+   ```
+   GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245
+   ---
+   200 OK
+   Transfer-Encoding: chunked
+   Content-Type: application/json
+
+   {
+     "type": "ADDED",
+     "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
+   }
+   {
+     "type": "MODIFIED",
+     "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...}
+   }
+   ...
+   ```
 
 A given Kubernetes server will only preserve a historical list of changes for a limited time. Clusters using etcd3 preserve changes in the last 5 minutes by default.  When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code `410 Gone`, clearing their local cache, performing a list operation, and starting the watch from the `resourceVersion` returned by that new list operation. Most client libraries offer some form of standard tool for this logic. (In Go this is called a `Reflector` and is located in the `k8s.io/client-go/cache` package.)
 
@@ -91,24 +100,28 @@ A given Kubernetes server will only preserve a historical list of changes for a
 
 To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to mark that all changes up to a given `resourceVersion` the client is requesting have already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.:
 
-        GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
-        ---
-        200 OK
-        Transfer-Encoding: chunked
-        Content-Type: application/json
-        {
-          "type": "ADDED",
-          "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
-        }
-        ...
-        {
-          "type": "BOOKMARK",
-          "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
-        }
+```console
+GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
+---
+200 OK
+Transfer-Encoding: chunked
+Content-Type: application/json
+
+{
+  "type": "ADDED",
+  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
+}
+...
+{
+  "type": "BOOKMARK",
+  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
+}
+```
 
 `Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event.
 
 ## Retrieving large results sets in chunks
+
 {{< feature-state for_k8s_version="v1.9" state="beta" >}}
 
 On large clusters, retrieving the collection of some resource types may result in very large responses that can impact the server and client. For instance, a cluster may have tens of thousands of pods, each of which is 1-2kb of encoded JSON. Retrieving all pods across all namespaces may result in a very large response (10-20MB) and consume a large amount of server resources. Starting in Kubernetes 1.9 the server supports the ability to break a single large collection request into many smaller chunks while preserving the consistency of the total request. Each chunk can be returned sequentially which reduces both the total size of the request and allows user-oriented clients to display results incrementally to improve responsiveness.
@@ -121,54 +134,63 @@ For example, if there are 1,253 pods on the cluster and the client wants to rece
 
 1. List all of the pods on a cluster, retrieving up to 500 pods each time.
 
-        GET /api/v1/pods?limit=500
-        ---
-        200 OK
-        Content-Type: application/json
-        {
-          "kind": "PodList",
-          "apiVersion": "v1",
-          "metadata": {
-            "resourceVersion":"10245",
-            "continue": "ENCODED_CONTINUE_TOKEN",
-            ...
-          },
-          "items": [...] // returns pods 1-500
-        }
+   ```console
+   GET /api/v1/pods?limit=500
+   ---
+   200 OK
+   Content-Type: application/json
+
+   {
+     "kind": "PodList",
+     "apiVersion": "v1",
+     "metadata": {
+       "resourceVersion":"10245",
+       "continue": "ENCODED_CONTINUE_TOKEN",
+       ...
+     },
+     "items": [...] // returns pods 1-500
+   }
+   ```
 
 2. Continue the previous call, retrieving the next set of 500 pods.
 
-        GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
-        ---
-        200 OK
-        Content-Type: application/json
-        {
-          "kind": "PodList",
-          "apiVersion": "v1",
-          "metadata": {
-            "resourceVersion":"10245",
-            "continue": "ENCODED_CONTINUE_TOKEN_2",
-            ...
-          },
-          "items": [...] // returns pods 501-1000
-        }
+   ```console
+   GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
+   ---
+   200 OK
+   Content-Type: application/json
+
+   {
+     "kind": "PodList",
+     "apiVersion": "v1",
+     "metadata": {
+       "resourceVersion":"10245",
+       "continue": "ENCODED_CONTINUE_TOKEN_2",
+       ...
+     },
+     "items": [...] // returns pods 501-1000
+   }
+   ```
 
 3. Continue the previous call, retrieving the last 253 pods.
 
-        GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN_2
-        ---
-        200 OK
-        Content-Type: application/json
-        {
-          "kind": "PodList",
-          "apiVersion": "v1",
-          "metadata": {
-            "resourceVersion":"10245",
-            "continue": "", // continue token is empty because we have reached the end of the list
-            ...
-          },
-          "items": [...] // returns pods 1001-1253
-        }
+   ```console
+   GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN_2
+   ---
+   200 OK
+   Content-Type: application/json
+
+   {
+     "kind": "PodList",
+     "apiVersion": "v1",
+     "metadata": {
+       "resourceVersion":"10245",
+       "continue": "", // continue token is empty because we have reached the end of the list
+       ...
+     },
+     "items": [...] // returns pods 1001-1253
+   }
+   ```
 
 Note that the `resourceVersion` of the list remains constant across each request, indicating the server is showing us a consistent snapshot of the pods. Pods that are created, updated, or deleted after version `10245` would not be shown unless the user makes a list request without the `continue` token.  This allows clients to break large requests into smaller chunks and then perform a watch operation on the full set without missing any updates.
 
@@ -180,52 +202,56 @@ A few limitations of that approach include non-trivial logic when dealing with c
 
 In order to avoid potential limitations as described above, clients may request the Table representation of objects, delegating specific details of printing to the server. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header containing a value of `application/json;as=Table;g=meta.k8s.io;v=v1beta1` with a `GET` call will request that the server return objects in the Table content type.
 
-For example:
+For example, list all of the pods on a cluster in the Table format.
 
-1. List all of the pods on a cluster in the Table format.
+```console
+GET /api/v1/pods
+Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1
+---
+200 OK
+Content-Type: application/json
 
-        GET /api/v1/pods
-        Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1
-        ---
-        200 OK
-        Content-Type: application/json
-        {
-            "kind": "Table",
-            "apiVersion": "meta.k8s.io/v1beta1",
-            ...
-            "columnDefinitions": [
-                ...
-            ]
-        }
+{
+    "kind": "Table",
+    "apiVersion": "meta.k8s.io/v1beta1",
+    ...
+    "columnDefinitions": [
+        ...
+    ]
+}
+```
 
 For API resource types that do not have a custom Table definition on the server, a default Table response is returned by the server, consisting of the resource's `name` and `creationTimestamp` fields.
 
-        GET /apis/crd.example.com/v1alpha1/namespaces/default/resources
-        ---
-        200 OK
-        Content-Type: application/json
-        ...
+```console
+GET /apis/crd.example.com/v1alpha1/namespaces/default/resources
+---
+200 OK
+Content-Type: application/json
+...
+
+{
+    "kind": "Table",
+    "apiVersion": "meta.k8s.io/v1beta1",
+    ...
+    "columnDefinitions": [
         {
-            "kind": "Table",
-            "apiVersion": "meta.k8s.io/v1beta1",
+            "name": "Name",
+            "type": "string",
+            ...
+        },
+        {
+            "name": "Created At",
+            "type": "date",
             ...
-            "columnDefinitions": [
-                {
-                    "name": "Name",
-                    "type": "string",
-                    ...
-                },
-                {
-                    "name": "Created At",
-                    "type": "date",
-                    ...
-                }
-            ]
         }
+    ]
+}
+```
 
 Table responses are available beginning in version 1.10 of the kube-apiserver. As such, not all API resource types will support a Table response, specifically when using a client against older clusters. Clients that must work against all resource types, or can potentially deal with older clusters, should specify multiple content types in their `Accept` header to support fallback to non-Tabular JSON:
 
-```
+```console
 Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1, application/json
 ```
 
@@ -240,42 +266,47 @@ For example:
 
 1. List all of the pods on a cluster in Protobuf format.
 
-        GET /api/v1/pods
-        Accept: application/vnd.kubernetes.protobuf
-        ---
-        200 OK
-        Content-Type: application/vnd.kubernetes.protobuf
-        ... binary encoded PodList object
+   ```console
+   GET /api/v1/pods
+   Accept: application/vnd.kubernetes.protobuf
+   ---
+   200 OK
+   Content-Type: application/vnd.kubernetes.protobuf
+
+   ... binary encoded PodList object
+   ```
 
 2. Create a pod by sending Protobuf encoded data to the server, but request a response in JSON.
 
-        POST /api/v1/namespaces/test/pods
-        Content-Type: application/vnd.kubernetes.protobuf
-        Accept: application/json
-        ... binary encoded Pod object
-        ---
-        200 OK
-        Content-Type: application/json
-        {
-          "kind": "Pod",
-          "apiVersion": "v1",
-          ...
-        }
+   ```console
+   POST /api/v1/namespaces/test/pods
+   Content-Type: application/vnd.kubernetes.protobuf
+   Accept: application/json
+   ... binary encoded Pod object
+   ---
+   200 OK
+   Content-Type: application/json
+
+   {
+     "kind": "Pod",
+     "apiVersion": "v1",
+     ...
+   }
+   ```
 
 Not all API resource types will support Protobuf, specifically those defined via Custom Resource Definitions or those that are API extensions. Clients that must work against all resource types should specify multiple content types in their `Accept` header to support fallback to JSON:
 
-```
+```console
 Accept: application/vnd.kubernetes.protobuf, application/json
 ```
 
-
 ### Protobuf encoding
 
 Kubernetes uses an envelope wrapper to encode Protobuf responses. That wrapper starts with a 4 byte magic number to help identify content in disk or in etcd as Protobuf (as opposed to JSON), and then is followed by a Protobuf encoded wrapper message, which describes the encoding and type of the underlying object and then contains the object.
 
 The wrapper format is:
 
-```
+```console
 A four byte magic number prefix:
   Bytes 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]
 
@@ -362,9 +393,11 @@ Dry-run is triggered by setting the `dryRun` query parameter. This parameter is
 
 For example:
 
-        POST /api/v1/namespaces/test/pods?dryRun=All
-        Content-Type: application/json
-        Accept: application/json
+```console
+POST /api/v1/namespaces/test/pods?dryRun=All
+Content-Type: application/json
+Accept: application/json
+```
 
 The response would look the same as for non-dry-run request, but the values of some generated fields may differ.
 
@@ -398,438 +431,14 @@ Some values of an object are typically generated before the object is persisted.
 
 ## Server Side Apply
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-
-{{< note >}}Starting from Kubernetes v1.18, if you have Server Side Apply enabled then the control plane tracks managed fields for all newly created objects.{{< /note >}}
-
-### Introduction
-
-Server Side Apply helps users and controllers manage their resources via
-declarative configurations. It allows them to create and/or modify their
-objects declaratively, simply by sending their fully specified intent.
-
-A fully specified intent is a partial object that only includes the fields and
-values for which the user has an opinion. That intent either creates a new
-object or is [combined](#merge-strategy), by the server, with the existing object.
-
-The system supports multiple appliers collaborating on a single object.
-
-Changes to an object's fields are tracked through a "[field management](#field-management)"
-mechanism. When a field's value changes, ownership moves from its current
-manager to the manager making the change. When trying to apply an object, fields
-that have a different value and are owned by another manager will result in a
-[conflict](#conflicts). This is done in order to signal that the operation might undo another
-collaborator's changes. Conflicts can be forced, in which case the value will be
-overridden, and the ownership will be transferred.
-
-If you remove a field from a configuration and apply the configuration, server side apply checks
-if there are any other field managers that also own the field.  If the field is
-not owned by any other field managers, it is either deleted from the live
-object or reset to its default value, if it has one. The same rule applies to associative list or
-map items.
-
-Server side apply is meant both as a replacement for the original `kubectl
-apply` and as a simpler mechanism for controllers to enact their changes.
-
-### Field Management
-
-Compared to the `last-applied` annotation managed by `kubectl`, Server Side
-Apply uses a more declarative approach, which tracks a user's field management,
-rather than a user's last applied state. This means that as a side effect of
-using Server Side Apply, information about which field manager manages each
-field in an object also becomes available.
-
-For a user to manage a field, in the Server Side Apply sense, means that the
-user relies on and expects the value of the field not to change. The user who
-last made an assertion about the value of a field will be recorded as the
-current field manager. This can be done either by changing the value with
-`POST`, `PUT`, or non-apply `PATCH`, or by including the field in a config sent
-to the Server Side Apply endpoint. When using Server-Side Apply, trying to
-change a field which is managed by someone else will result in a rejected
-request (if not forced, see [Conflicts](#conflicts)).
-
-When two or more appliers set a field to the same value, they share ownership of
-that field. Any subsequent attempt to change the value of the shared field, by any of
-the appliers, results in a conflict. Shared field owners may give up ownership
-of a field by removing it from their configuration.
-
-Field management is stored in a`managedFields` field that is part of an object's
-[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta).
-
-A simple example of an object created by Server Side Apply could look like this:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: test-cm
-  namespace: default
-  labels:
-    test-label: test
-  managedFields:
-  - manager: kubectl
-    operation: Apply
-    apiVersion: v1
-    time: "2010-10-10T0:00:00Z"
-    fieldsType: FieldsV1
-    fieldsV1:
-      f:metadata:
-        f:labels:
-          f:test-label: {}
-      f:data:
-        f:key: {}
-data:
-  key: some value
-```
-
-The above object contains a single manager in `metadata.managedFields`. The
-manager consists of basic information about the managing entity itself, like
-operation type, api version, and the fields managed by it.
-
-{{< note >}} This field is managed by the apiserver and should not be changed by
-the user. {{< /note >}}
-
-Nevertheless it is possible to change `metadata.managedFields` through an
-`Update` operation. Doing so is highly discouraged, but might be a reasonable
-option to try if, for example, the `managedFields` get into an inconsistent
-state (which clearly should not happen).
-
-The format of the `managedFields` is described in the [API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta).
-
-### Conflicts
-
-A conflict is a special status error that occurs when an `Apply` operation tries
-to change a field, which another user also claims to manage. This prevents an
-applier from unintentionally overwriting the value set by another user. When
-this occurs, the applier has 3 options to resolve the conflicts:
-
-* **Overwrite value, become sole manager:** If overwriting the value was
-  intentional (or if the applier is an automated process like a controller) the
-  applier should set the `force` query parameter to true and make the request
-  again. This forces the operation to succeed, changes the value of the field,
-  and removes the field from all other managers' entries in managedFields.
-* **Don't overwrite value, give up management claim:** If the applier doesn't
-  care about the value of the field anymore, they can remove it from their
-  config and make the request again. This leaves the value unchanged, and causes
-  the field to be removed from the applier's entry in managedFields.
-* **Don't overwrite value, become shared manager:** If the applier still cares
-  about the value of the field, but doesn't want to overwrite it, they can
-  change the value of the field in their config to match the value of the object
-  on the server, and make the request again. This leaves the value unchanged,
-  and causes the field's management to be shared by the applier and all other
-  field managers that already claimed to manage it.
-
-
-### Managers
-
-Managers identify distinct workflows that are modifying the object (especially
-useful on conflicts!), and can be specified through the `fieldManager` query
-parameter as part of a modifying request. It is required for the apply endpoint,
-though kubectl will default it to `kubectl`. For other updates, its default is
-computed from the user-agent.
-
-### Apply and Update
-
-The two operation types considered by this feature are `Apply` (`PATCH` with
-content type `application/apply-patch+yaml`) and `Update` (all other operations
-which modify the object). Both operations update the `managedFields`, but behave
-a little differently.
-
-{{< note >}}
-Whether you are submitting JSON data or YAML data, use `application/apply-patch+yaml` as the
-Content-Type header value.
-
-All JSON documents are valid YAML.
-{{< /note >}}
-
-For instance, only the apply operation fails on conflicts while update does
-not. Also, apply operations are required to identify themselves by providing a
-`fieldManager` query parameter, while the query parameter is optional for update
-operations. Finally, when using the apply operation you cannot have `managedFields` in the object that is being applied.
-
-An example object with multiple managers could look like this:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: test-cm
-  namespace: default
-  labels:
-    test-label: test
-  managedFields:
-  - manager: kubectl
-    operation: Apply
-    apiVersion: v1
-    fields:
-      f:metadata:
-        f:labels:
-          f:test-label: {}
-  - manager: kube-controller-manager
-    operation: Update
-    apiVersion: v1
-    time: '2019-03-30T16:00:00.000Z'
-    fields:
-      f:data:
-        f:key: {}
-data:
-  key: new value
-```
-
-In this example, a second operation was run as an `Update` by the manager called
-`kube-controller-manager`. The update changed a value in the data field which
-caused the field's management to change to the `kube-controller-manager`.
-
-{{< note >}}If this update would have been an `Apply` operation, the operation
-would have failed due to conflicting ownership.{{< /note >}}
-
-### Merge strategy
-
-The merging strategy, implemented with Server Side Apply, provides a generally
-more stable object lifecycle. Server Side Apply tries to merge fields based on
-the fact who manages them instead of overruling just based on values. This way
-it is intended to make it easier and more stable for multiple actors updating
-the same object by causing less unexpected interference.
-
-When a user sends a "fully-specified intent" object to the Server Side Apply
-endpoint, the server merges it with the live object favoring the value in the
-applied config if it is specified in both places. If the set of items present in
-the applied config is not a superset of the items applied by the same user last
-time, each missing item not managed by any other appliers is removed. For
-more information about how an object's schema is used to make decisions when
-merging, see
-[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff).
-
-A number of markers were added in Kubernetes 1.16 and 1.17, to allow API
-developers to describe the merge strategy supported by lists, maps, and
-structs. These markers can be applied to objects of the respective type,
-in Go files or in the [OpenAPI schema definition of the
-CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io):
-
-| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
-|---|---|---|---|---|
-| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16          |
-| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 |
-| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
-| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |
-
-### Custom Resources
-
-By default, Server Side Apply treats custom resources as unstructured data. All
-keys are treated the same as struct fields, and all lists are considered atomic.
-
-If the Custom Resource Definition defines a
-[schema](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)
-that contains annotations as defined in the previous "Merge Strategy"
-section, these annotations will be used when merging objects of this
-type.
-
-### Using Server-Side Apply in a controller
-
-As a developer of a controller, you can use server-side apply as a way to
-simplify the update logic of your controller. The main differences with a
-read-modify-write and/or patch are the following:
-
-* the applied object must contain all the fields that the controller cares about.
-* there are no way to remove fields that haven't been applied by the controller
-  before (controller can still send a PATCH/UPDATE for these use-cases).
-* the object doesn't have to be read beforehand, `resourceVersion` doesn't have
-  to be specified.
-
-It is strongly recommended for controllers to always "force" conflicts, since they
-might not be able to resolve or act on these conflicts.
-
-### Transferring Ownership
-
-In addition to the concurrency controls provided by [conflict
-resolution](#conflicts), Server Side Apply provides ways to perform coordinated
-field ownership transfers from users to controllers.
-
-This is best explained by example. Let's look at how to safely transfer
-ownership of the `replicas` field from a user to a controller while enabling
-automatic horizontal scaling for a Deployment, using the HorizontalPodAutoscaler
-resource and its accompanying controller.
-
-Say a user has defined deployment with `replicas` set to the desired value:
-
-{{< codenew file="application/ssa/nginx-deployment.yaml" >}}
-
-And the user has created the deployment using server side apply like so:
-
-```shell
-kubectl apply -f application/ssa/nginx-deployment.yaml --server-side
-```
-
-Then later, HPA is enabled for the deployment, e.g.:
-
-```
-kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10
-```
-
-Now, the user would like to remove `replicas` from their configuration, so they
-don't accidentally fight with the HPA controller. However, there is a race: it
-might take some time before HPA feels the need to adjust `replicas`, and if
-the user removes `replicas` before the HPA writes to the field and becomes
-its owner, then apiserver will set `replicas` to 1, its default value. This
-is not what the user wants to happen, even temporarily.
-
-There are two solutions:
-
-- (easy) Leave `replicas` in the configuration; when HPA eventually writes to that
-  field, the system gives the user a conflict over it. At that point, it is safe
-  to remove from the configuration.
-
-- (more advanced) If, however, the user doesn't want to wait, for example
-  because they want to keep the cluster legible to coworkers, then they can take
-  the following steps to make it safe to remove `replicas` from their
-  configuration:
-
-First, the user defines a new configuration containing only the `replicas` field:
-
-{{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}}
-
-The user applies that configuration using the field manager name `handover-to-hpa`:
-
-```shell
-kubectl apply -f application/ssa/nginx-deployment-replicas-only.yaml --server-side --field-manager=handover-to-hpa --validate=false
-```
-
-If the apply results in a conflict with the HPA controller, then do nothing. The
-conflict just indicates the controller has claimed the field earlier in the
-process than it sometimes does.
-
-At this point the user may remove the `replicas` field from their configuration.
-
-{{< codenew file="application/ssa/nginx-deployment-no-replicas.yaml" >}}
-
-Note that whenever the HPA controller sets the `replicas` field to a new value,
-the temporary field manager will no longer own any fields and will be
-automatically deleted. No clean up is required.
-
-### Transferring Ownership Between Users
-
-Users can transfer ownership of a field between each other by setting the field
-to the same value in both of their applied configs, causing them to share
-ownership of the field. Once the users share ownership of the field, one of them
-can remove the field from their applied configuration to give up ownership and
-complete the transfer to the other user.
-
-### Comparison with Client Side Apply
-
-A consequence of the conflict detection and resolution implemented by Server
-Side Apply is that an applier always has up to date field values in their local
-state. If they don't, they get a conflict the next time they apply. Any of the
-three options to resolve conflicts results in the applied configuration being an
-up to date subset of the object on the server's fields.
-
-This is different from Client Side Apply, where outdated values which have been
-overwritten by other users are left in an applier's local config. These values
-only become accurate when the user updates that specific field, if ever, and an
-applier has no way of knowing whether their next apply will overwrite other
-users' changes.
-
-Another difference is that an applier using Client Side Apply is unable to
-change the API version they are using, but Server Side Apply supports this use
-case.
-
-### Upgrading from client-side apply to server-side apply
-
-Client-side apply users who manage a resource with `kubectl apply` can start
-using server-side apply with the following flag.
-
-```
-kubectl apply --server-side [--dry-run=server]
-```
-
-By default, field management of the object transfers from client-side apply
-to kubectl server-side apply without encountering conflicts.
-
-{{< caution >}}
-Keep the `last-applied-configuration` annotation up to date. The annotation infers client-side apply's managed fields. Any fields not managed by client-side apply raise conflicts.
-
-For example, if you used `kubectl scale` to update the replicas field after client-side apply,
-then this field is not owned by client-side apply and creates conflicts on `kubectl apply --server-side`.
-{{< /caution >}}
-
-This behavior applies to server-side apply with the `kubectl` field manager. As
-an exception, you can opt-out of this behavior by specifying a different,
-non-default field manager, as seen in the following example. The default field manager for kubectl
-server-side apply is `kubectl`.
-
-```
-kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
-```
-
-### Downgrading from server-side apply to client-side apply
-
-If you manage a resource with `kubectl apply --server-side`,
-you can downgrade to client-side apply directly with `kubectl apply`.
-
-Downgrading works because kubectl server-side apply keeps the
-`last-applied-configuration` annotation up-to-date if you use
-`kubectl apply`.
-
-This behavior applies to server-side apply with the `kubectl` field manager. As
-an exception, you can opt-out of this behavior by specifying a different,
-non-default field manager, as seen in the following example. The default field manager for kubectl
-server-side apply is `kubectl`.
-
-```
-kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
-```
-
-### API Endpoint
-
-With the Server Side Apply feature enabled, the `PATCH` endpoint accepts the
-additional `application/apply-patch+yaml` content type. Users of Server Side
-Apply can send partially specified objects as YAML to this endpoint.
-When applying a configuration, one should always include all the fields
-that they have an opinion about.
-
-### Clearing ManagedFields
-
-It is possible to strip all managedFields from an object by overwriting them
-using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
-non-apply operation. This can be done by overwriting the managedFields field
-with an empty entry. Two examples are:
-
-```json
-PATCH /api/v1/namespaces/default/configmaps/example-cm
-Content-Type: application/merge-patch+json
-Accept: application/json
-Data: {"metadata":{"managedFields": [{}]}}
-```
-
-```json
-PATCH /api/v1/namespaces/default/configmaps/example-cm
-Content-Type: application/json-patch+json
-Accept: application/json
-Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
-```
-
-This will overwrite the managedFields with a list containing a single empty
-entry that then results in the managedFields being stripped entirely from the
-object. Note that just setting the managedFields to an empty list will not reset
-the field. This is on purpose, so managedFields never get stripped by clients
-not aware of the field.
-
-In cases where the reset operation is combined with changes to other fields than
-the managedFields, this will result in the managedFields being reset first and
-the other changes being processed afterwards. As a result the applier takes
-ownership of any fields updated in the same request.
-
-{{< caution >}} Server Side Apply does not correctly track ownership on
-sub-resources that don't receive the resource object type. If you are
-using Server Side Apply with such a sub-resource, the changed fields
-won't be tracked.  {{< /caution >}}
-
-### Disabling the feature
-
-Server Side Apply is a beta feature, so it is enabled by default. To turn this
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates) off,
-you need to include the `--feature-gates ServerSideApply=false` flag when
-starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all
-should have the same flag setting.
+Starting from Kubernetes v1.18, you can enable the
+[Server Side Apply](/docs/reference/using-api/server-side-apply/)
+feature so that the control plane tracks managed fields for all newly created objects.
+Server Side Apply provides a clear pattern for managing field conflicts,
+offers server-side `Apply` and `Update` operations, and replaces the
+client-side functionality of `kubectl apply`. For more details about this
+feature, see the section on
+[Server Side Apply](/docs/reference/using-api/server-side-apply/).
 
 ## Resource Versions
 
@@ -859,12 +468,13 @@ For get and list, the semantics of resource version are:
 
 **List:**
 
-v1.19+ API servers and newer support the `resourceVersionMatch` parameter, which
+v1.19+ API servers support the `resourceVersionMatch` parameter, which
 determines how resourceVersion is applied to list calls.  It is highly
 recommended that `resourceVersionMatch` be set for list calls where
 `resourceVersion` is set. If `resourceVersion` is unset, `resourceVersionMatch`
 is not allowed.  For backward compatibility, clients must tolerate the server
 ignoring `resourceVersionMatch`:
+
 - When using `resourceVersionMatch=NotOlderThan` and limit is set, clients must
   handle HTTP 410 "Gone" responses. For example, the client might retry with a
   newer `resourceVersion` or fall back to `resourceVersion=""`.
@@ -878,27 +488,29 @@ a known `resourceVersion` is preferable since it can achieve better performance
 of your cluster than leaving `resourceVersion` and `resourceVersionMatch` unset, which requires
 quorum read to be served.
 
+{{< table caption="resourceVersionMatch and paging parameters for list" >}}
+
 | resourceVersionMatch param            | paging params                 | resourceVersion unset | resourceVersion="0"                       | resourceVersion="{value other than 0}" |
 |---------------------------------------|-------------------------------|-----------------------|-------------------------------------------|----------------------------------------|
 | resourceVersionMatch unset            | limit unset                   | Most Recent           | Any                                       | Not older than                         |
-| resourceVersionMatch unset            | limit="n", continue unset     | Most Recent           | Any                                       | Exact                                  |
-| resourceVersionMatch unset            | limit="n", continue="<token>" | Continue Token, Exact | Invalid, treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request`        |
-| resourceVersionMatch=Exact[^1]        | limit unset                   | Invalid               | Invalid                                   | Exact                                  |
-| resourceVersionMatch=Exact[^1]        | limit="n", continue unset     | Invalid               | Invalid                                   | Exact                                  |
-| resourceVersionMatch=NotOlderThan[^1] | limit unset                   | Invalid               | Any                                       | Not older than                         |
-| resourceVersionMatch=NotOlderThan[^1] | limit="n", continue unset     | Invalid               | Any                                       | Not older than                         |
+| resourceVersionMatch unset            | limit=\<n\>, continue unset     | Most Recent           | Any                                       | Exact                                  |
+| resourceVersionMatch unset            | limit=\<n\>, continue=\<token\> | Continue Token, Exact | Invalid, treated as Continue Token, Exact | Invalid, HTTP `400 Bad Request`        |
+| resourceVersionMatch=Exact [1]        | limit unset                   | Invalid               | Invalid                                   | Exact                                  |
+| resourceVersionMatch=Exact [1]        | limit=\<n\>, continue unset     | Invalid               | Invalid                                   | Exact                                  |
+| resourceVersionMatch=NotOlderThan [1] | limit unset                   | Invalid               | Any                                       | Not older than                         |
+| resourceVersionMatch=NotOlderThan [1] | limit=\<n\>, continue unset     | Invalid               | Any                                       | Not older than                         |
 
-[^1]: If the server does not honor the `resourceVersionMatch` parameter, it is treated as if it is unset.
-| paging                          | resourceVersion unset | resourceVersion="0"                            | resourceVersion="{value other than 0}" |
-|---------------------------------|-----------------------|------------------------------------------------|----------------------------------------|
-| limit unset                     | Most Recent           | Any                                            | Not older than                         |
-| limit="n", continue unset       | Most Recent           | Any                                            | Exact                                  |
-| limit="n", continue="\<token\>" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact  | Invalid, HTTP `400 Bad Request`        |
+{{< /table >}}
+
+**Footnotes:**
+
+[1] If the server does not honor the `resourceVersionMatch` parameter, it is treated as if it is unset.
 
 The meaning of the get and list semantics are:
 
 - **Most Recent:** Return data at the most recent resource version. The returned data must be
   consistent (i.e. served from etcd via a quorum read).
+
 - **Any:** Return data at any resource version. The newest available resource version is preferred,
   but strong consistency is not required; data at any resource version may be served. It is possible
   for the request to return data at a much older resource version that the client has previously
@@ -911,6 +523,7 @@ The meaning of the get and list semantics are:
   but does not make any guarantee about the resourceVersion in the ObjectMeta of the list items
   since ObjectMeta.resourceVersion tracks when an object was last updated, not how up-to-date the
   object is when served.
+
 - **Exact:** Return data at the exact resource version provided. If the provided resourceVersion is
   unavailable, the server responds with HTTP 410 "Gone".  For list requests to servers that honor the
   resourceVersionMatch parameter, this guarantees that resourceVersion in the ListMeta is the same as
@@ -925,10 +538,14 @@ For watch, the semantics of resource version are:
 
 **Watch:**
 
+{{< table caption="resourceVersion for watch" >}}
+
 | resourceVersion unset               | resourceVersion="0"        | resourceVersion="{value other than 0}" |
 |-------------------------------------|----------------------------|----------------------------------------|
 | Get State and Start at Most Recent  | Get State and Start at Any | Start at Exact                         |
 
+{{< /table >}}
+
 The meaning of the watch semantics are:
 
 - **Get State and Start at Most Recent:** Start a watch at the most recent resource version, which must be consistent (i.e. served from etcd via a quorum read). To establish initial state, the watch begins with synthetic "Added" events of all resources instances that exist at the starting resource version. All following watch events are for all changes that occurred after the resource version the watch started at.
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
deleted file mode 100644
index 529c6fc799..0000000000
--- a/content/en/docs/reference/using-api/api-overview.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Kubernetes API Overview
-reviewers:
-- erictune
-- lavalamp
-- jbeda
-content_type: concept
-weight: 10
-card:
-  name: reference
-  weight: 50
-  title: Overview of API
----
-
-<!-- overview -->
-This page provides an overview of the Kubernetes API. 
-
-
-<!-- body -->
-The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes
-platform is treated as an API object and has a corresponding entry in the
-[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
-
-Most operations can be performed through the
-[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
-command-line tools, such as [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), which in turn use
-the API. However, you can also access the API directly using REST calls.
-
-Consider using one of the [client libraries](/docs/reference/using-api/client-libraries/)
-if you are writing an application using the Kubernetes API.
-
-## API versioning
-
-To eliminate fields or restructure resource representations, Kubernetes supports
-multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/rbac.authorization.k8s.io/v1alpha1`.
-
-The version is set at the API level rather than at the resource or field level to:
-
-- Ensure that the API presents a clear and consistent view of system resources and behavior.
-- Enable control access to end-of-life and/or experimental APIs.
-
-The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats.
-
-{{< note >}}
-The API versioning and software versioning are indirectly related.  The [API and release
-versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and software versioning.
-{{< /note >}}
-
-Different API versions indicate different levels of stability and support. You can find more information about the criteria for each level in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).
-
-Here's a summary of each level:
-
-- Alpha:
-  - The version names contain `alpha` (for example, `v1alpha1`).
-  - The software may contain bugs. Enabling a feature may expose bugs. A feature may be disabled by default.
-  - The support for a feature may be dropped at any time without notice.
-  - The API may change in incompatible ways in a later software release without notice.
-  - The software is recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of  long-term support.
-  
-- Beta:
-  - The version names contain `beta` (for example, `v2beta3`).
-  - The software is well tested. Enabling a feature is considered safe. Features are enabled by default.
-  - The support for a feature will not be dropped, though the details may change.
-  - The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, migration instructions are provided.  This may require deleting, editing, and re-creating
-    API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
-  - The software is recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters which can be upgraded independently, you may be able to relax this restriction.
-  
- {{< note >}}
-Try the beta features and provide feedback. After the features exit beta, it may not be practical to make more changes.
- {{< /note >}}
-  
-- Stable:
-  - The version name is `vX` where `X` is an integer.
-  - The stable versions of features appear in released software for many subsequent versions.
-
-## API groups
-
-[*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
-
-Currently, there are several API groups in use:
-
-*  The *core* (also called *legacy*) group, which is at REST path `/api/v1` and is not specified as part of the `apiVersion` field, for example, `apiVersion: v1`.
-*  The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
-   (for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).
-
-The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are:
-
- - [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
-   for basic CRUD needs.
- - [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) for a full set of Kubernetes API semantics to implement their own apiserver.
- 
-
-## Enabling or disabling API groups
-
-Certain resources and API groups are enabled by default. You can enable or disable them by setting `--runtime-config`
-on the apiserver. `--runtime-config` accepts comma separated values. For example:
-
- - to disable batch/v1, set `--runtime-config=batch/v1=false`
- - to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`
-
-The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
-
-{{< note >}}
-When you enable or disable groups or resources, you need to restart the apiserver and controller-manager
-to pick up the `--runtime-config` changes.
-{{< /note >}}
-
diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md
index c4d7e5ea24..c14f0fa9c7 100644
--- a/content/en/docs/reference/using-api/client-libraries.md
+++ b/content/en/docs/reference/using-api/client-libraries.md
@@ -12,7 +12,7 @@ API from various programming languages.
 
 
 <!-- body -->
-To write applications using the [Kubernetes REST API](/docs/reference/using-api/api-overview/),
+To write applications using the [Kubernetes REST API](/docs/reference/using-api/),
 you do not need to implement the API calls and request/response types yourself.
 You can use a client library for the programming language you are using.
 
@@ -40,6 +40,8 @@ The following client libraries are officially maintained by
 
 ## Community-maintained client libraries
 
+{{% thirdparty-content %}}
+
 The following Kubernetes API client libraries are provided and maintained by
 their authors, not the Kubernetes team.
 
@@ -60,6 +62,7 @@ their authors, not the Kubernetes team.
 | PHP                  | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
 | PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
 | PHP                  | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
+| PHP                  | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
 | Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
 | Python               | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md
index ba322d42b5..17840f195b 100644
--- a/content/en/docs/reference/using-api/deprecation-policy.md
+++ b/content/en/docs/reference/using-api/deprecation-policy.md
@@ -24,7 +24,7 @@ a deprecation policy for aspects of the system that are slated to be removed.
 Since Kubernetes is an API-driven system, the API has evolved over time to
 reflect the evolving understanding of the problem space. The Kubernetes API is
 actually a set of APIs, called "API groups", and each API group is
-independently versioned.  [API versions](/docs/reference/using-api/api-overview/#api-versioning) fall
+independently versioned.  [API versions](/docs/reference/using-api/#api-versioning) fall
 into 3 main tracks, each of which has different policies for deprecation:
 
 | Example  | Track                            |
@@ -303,12 +303,12 @@ Starting in Kubernetes v1.19, making an API request to a deprecated REST API end
 2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request.
 3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver` 
    process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined
-   to the `apiserver_request_total` metric, and a `removed_version` label that indicates the 
+   to the `apiserver_request_total` metric, and a `removed_release` label that indicates the
    Kubernetes release in which the API will no longer be served. The following Prometheus query
    returns information about requests made to deprecated APIs which will be removed in v1.22:
-   
+
    ```promql
-   apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total
+   apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total
    ```
 
 ### Fields of REST resources
diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md
index a7be3b267f..2c315505db 100644
--- a/content/en/docs/reference/using-api/health-checks.md
+++ b/content/en/docs/reference/using-api/health-checks.md
@@ -19,7 +19,7 @@ The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should us
 The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
 For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
 Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
-A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
 The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
 
 The following examples will show how you can interact with the health API endpoints.
@@ -27,15 +27,15 @@ The following examples will show how you can interact with the health API endpoi
 For all endpoints you can use the `verbose` parameter to print out the checks and their status.
 This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
 
-    ```shell
-    curl -k https://localhost:6443/livez?verbose
-    ```
+```shell
+curl -k https://localhost:6443/livez?verbose
+```
 
 or from a remote host with authentication:
 
-    ```shell
-    kubectl get --raw='/readyz?verbose'
-    ```
+```shell
+kubectl get --raw='/readyz?verbose'
+```
 
 The output will look like this:
 
@@ -62,9 +62,9 @@ The output will look like this:
 The Kubernetes API server also supports to exclude specific checks.
 The query parameters can also be combined like in this example:
 
-    ```shell
-    curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
-    ```
+```shell
+curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+```
 
 The output show that the `etcd` check is excluded:
 
@@ -94,10 +94,10 @@ The output show that the `etcd` check is excluded:
 {{< feature-state state="alpha" >}}
 
 Each individual health check exposes an http endpoint and could can be checked individually.
-The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server.
+The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server.
 The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
 These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
 
-    ```shell
-    curl -k https://localhost:6443/livez/etcd
-    ```
+```shell
+curl -k https://localhost:6443/livez/etcd
+```
diff --git a/content/en/docs/reference/using-api/server-side-apply.md b/content/en/docs/reference/using-api/server-side-apply.md
new file mode 100644
index 0000000000..c945765d76
--- /dev/null
+++ b/content/en/docs/reference/using-api/server-side-apply.md
@@ -0,0 +1,462 @@
+---
+title: Server-Side Apply
+reviewers:
+- smarterclayton
+- apelisse
+- lavalamp
+- liggitt
+content_type: concept
+weight: 25
+min-kubernetes-server-version: 1.16
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+## Introduction
+
+Server Side Apply helps users and controllers manage their resources via
+declarative configurations. It allows them to create and/or modify their
+[objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+declaratively, simply by sending their fully specified intent.
+
+A fully specified intent is a partial object that only includes the fields and
+values for which the user has an opinion. That intent either creates a new
+object or is [combined](#merge-strategy), by the server, with the existing object.
+
+The system supports multiple appliers collaborating on a single object.
+
+Changes to an object's fields are tracked through a "[field management](#field-management)"
+mechanism. When a field's value changes, ownership moves from its current
+manager to the manager making the change. When trying to apply an object,
+fields that have a different value and are owned by another manager will
+result in a [conflict](#conflicts). This is done in order to signal that the
+operation might undo another collaborator's changes. Conflicts can be forced,
+in which case the value will be overridden, and the ownership will be
+transferred.
+
+If you remove a field from a configuration and apply the configuration, server
+side apply checks if there are any other field managers that also own the
+field.  If the field is not owned by any other field managers, it is either
+deleted from the live object or reset to its default value, if it has one. The
+same rule applies to associative list or map items.
+
+Server side apply is meant both as a replacement for the original `kubectl
+apply` and as a simpler mechanism for controllers to enact their changes.
+
+If you have Server Side Apply enabled, the control plane tracks managed fields
+for all newlly created objects.
+
+## Field Management
+
+Compared to the `last-applied` annotation managed by `kubectl`, Server Side
+Apply uses a more declarative approach, which tracks a user's field management,
+rather than a user's last applied state. This means that as a side effect of
+using Server Side Apply, information about which field manager manages each
+field in an object also becomes available.
+
+For a user to manage a field, in the Server Side Apply sense, means that the
+user relies on and expects the value of the field not to change. The user who
+last made an assertion about the value of a field will be recorded as the
+current field manager. This can be done either by changing the value with
+`POST`, `PUT`, or non-apply `PATCH`, or by including the field in a config sent
+to the Server Side Apply endpoint. When using Server-Side Apply, trying to
+change a field which is managed by someone else will result in a rejected
+request (if not forced, see [Conflicts](#conflicts)).
+
+When two or more appliers set a field to the same value, they share ownership of
+that field. Any subsequent attempt to change the value of the shared field, by any of
+the appliers, results in a conflict. Shared field owners may give up ownership
+of a field by removing it from their configuration.
+
+Field management is stored in a`managedFields` field that is part of an object's
+[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta).
+
+A simple example of an object created by Server Side Apply could look like this:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: test-cm
+  namespace: default
+  labels:
+    test-label: test
+  managedFields:
+  - manager: kubectl
+    operation: Apply
+    apiVersion: v1
+    time: "2010-10-10T0:00:00Z"
+    fieldsType: FieldsV1
+    fieldsV1:
+      f:metadata:
+        f:labels:
+          f:test-label: {}
+      f:data:
+        f:key: {}
+data:
+  key: some value
+```
+
+The above object contains a single manager in `metadata.managedFields`. The
+manager consists of basic information about the managing entity itself, like
+operation type, API version, and the fields managed by it.
+
+{{< note >}}
+This field is managed by the  API server and should not be changed by
+the user.
+{{< /note >}}
+
+Nevertheless it is possible to change `metadata.managedFields` through an
+`Update` operation. Doing so is highly discouraged, but might be a reasonable
+option to try if, for example, the `managedFields` get into an inconsistent
+state (which clearly should not happen).
+
+The format of the `managedFields` is described in the
+[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta).
+
+## Conflicts
+
+A conflict is a special status error that occurs when an `Apply` operation tries
+to change a field, which another user also claims to manage. This prevents an
+applier from unintentionally overwriting the value set by another user. When
+this occurs, the applier has 3 options to resolve the conflicts:
+
+* **Overwrite value, become sole manager:** If overwriting the value was
+  intentional (or if the applier is an automated process like a controller) the
+  applier should set the `force` query parameter to true and make the request
+  again. This forces the operation to succeed, changes the value of the field,
+  and removes the field from all other managers' entries in managedFields.
+
+* **Don't overwrite value, give up management claim:** If the applier doesn't
+  care about the value of the field anymore, they can remove it from their
+  config and make the request again. This leaves the value unchanged, and causes
+  the field to be removed from the applier's entry in managedFields.
+
+* **Don't overwrite value, become shared manager:** If the applier still cares
+  about the value of the field, but doesn't want to overwrite it, they can
+  change the value of the field in their config to match the value of the object
+  on the server, and make the request again. This leaves the value unchanged,
+  and causes the field's management to be shared by the applier and all other
+  field managers that already claimed to manage it.
+
+## Managers
+
+Managers identify distinct workflows that are modifying the object (especially
+useful on conflicts!), and can be specified through the `fieldManager` query
+parameter as part of a modifying request. It is required for the apply endpoint,
+though kubectl will default it to `kubectl`. For other updates, its default is
+computed from the user-agent.
+
+## Apply and Update
+
+The two operation types considered by this feature are `Apply` (`PATCH` with
+content type `application/apply-patch+yaml`) and `Update` (all other operations
+which modify the object). Both operations update the `managedFields`, but behave
+a little differently.
+
+{{< note >}}
+Whether you are submitting JSON data or YAML data, use
+`application/apply-patch+yaml` as the `Content-Type` header value.
+
+All JSON documents are valid YAML.
+{{< /note >}}
+
+For instance, only the apply operation fails on conflicts while update does
+not. Also, apply operations are required to identify themselves by providing a
+`fieldManager` query parameter, while the query parameter is optional for update
+operations. Finally, when using the apply operation you cannot have
+`managedFields` in the object that is being applied.
+
+An example object with multiple managers could look like this:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: test-cm
+  namespace: default
+  labels:
+    test-label: test
+  managedFields:
+  - manager: kubectl
+    operation: Apply
+    apiVersion: v1
+    fields:
+      f:metadata:
+        f:labels:
+          f:test-label: {}
+  - manager: kube-controller-manager
+    operation: Update
+    apiVersion: v1
+    time: '2019-03-30T16:00:00.000Z'
+    fields:
+      f:data:
+        f:key: {}
+data:
+  key: new value
+```
+
+In this example, a second operation was run as an `Update` by the manager called
+`kube-controller-manager`. The update changed a value in the data field which
+caused the field's management to change to the `kube-controller-manager`.
+
+If this update would have been an `Apply` operation, the operation
+would have failed due to conflicting ownership.
+
+## Merge strategy
+
+The merging strategy, implemented with Server Side Apply, provides a generally
+more stable object lifecycle. Server Side Apply tries to merge fields based on
+the fact who manages them instead of overruling just based on values. This way
+it is intended to make it easier and more stable for multiple actors updating
+the same object by causing less unexpected interference.
+
+When a user sends a "fully-specified intent" object to the Server Side Apply
+endpoint, the server merges it with the live object favoring the value in the
+applied config if it is specified in both places. If the set of items present in
+the applied config is not a superset of the items applied by the same user last
+time, each missing item not managed by any other appliers is removed. For
+more information about how an object's schema is used to make decisions when
+merging, see
+[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff).
+
+A number of markers were added in Kubernetes 1.16 and 1.17, to allow API
+developers to describe the merge strategy supported by lists, maps, and
+structs. These markers can be applied to objects of the respective type,
+in Go files or in the OpenAPI schema definition of the 
+[CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io):
+
+| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
+|---|---|---|---|---|
+| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `set` or `map`, different managers can manage entries separately. | 1.16          |
+| `//+listMapKey` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. While there can be multiple keys, `listMapKey` is singular because keys need to be specified individually in the Go type. | 1.16 |
+| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
+| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |
+
+### Custom Resources
+
+By default, Server Side Apply treats custom resources as unstructured data. All
+keys are treated the same as struct fields, and all lists are considered atomic.
+
+If the Custom Resource Definition defines a
+[schema](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)
+that contains annotations as defined in the previous "Merge Strategy"
+section, these annotations will be used when merging objects of this
+type.
+
+### Using Server-Side Apply in a controller
+
+As a developer of a controller, you can use server-side apply as a way to
+simplify the update logic of your controller. The main differences with a
+read-modify-write and/or patch are the following:
+
+* the applied object must contain all the fields that the controller cares about.
+* there are no way to remove fields that haven't been applied by the controller
+  before (controller can still send a PATCH/UPDATE for these use-cases).
+* the object doesn't have to be read beforehand, `resourceVersion` doesn't have
+  to be specified.
+
+It is strongly recommended for controllers to always "force" conflicts, since they
+might not be able to resolve or act on these conflicts.
+
+### Transferring Ownership
+
+In addition to the concurrency controls provided by [conflict resolution](#conflicts),
+Server Side Apply provides ways to perform coordinated
+field ownership transfers from users to controllers.
+
+This is best explained by example. Let's look at how to safely transfer
+ownership of the `replicas` field from a user to a controller while enabling
+automatic horizontal scaling for a Deployment, using the HorizontalPodAutoscaler
+resource and its accompanying controller.
+
+Say a user has defined deployment with `replicas` set to the desired value:
+
+{{< codenew file="application/ssa/nginx-deployment.yaml" >}}
+
+And the user has created the deployment using server side apply like so:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment.yaml --server-side
+```
+
+Then later, HPA is enabled for the deployment, e.g.:
+
+```shell
+kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10
+```
+
+Now, the user would like to remove `replicas` from their configuration, so they
+don't accidentally fight with the HPA controller. However, there is a race: it
+might take some time before HPA feels the need to adjust `replicas`, and if
+the user removes `replicas` before the HPA writes to the field and becomes
+its owner, then apiserver will set `replicas` to 1, its default value. This
+is not what the user wants to happen, even temporarily.
+
+There are two solutions:
+
+- (easy) Leave `replicas` in the configuration; when HPA eventually writes to that
+  field, the system gives the user a conflict over it. At that point, it is safe
+  to remove from the configuration.
+
+- (more advanced) If, however, the user doesn't want to wait, for example
+  because they want to keep the cluster legible to coworkers, then they can take
+  the following steps to make it safe to remove `replicas` from their
+  configuration:
+
+First, the user defines a new configuration containing only the `replicas` field:
+
+{{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}}
+
+The user applies that configuration using the field manager name `handover-to-hpa`:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replicas-only.yaml \
+  --server-side --field-manager=handover-to-hpa \
+  --validate=false
+```
+
+If the apply results in a conflict with the HPA controller, then do nothing. The
+conflict just indicates the controller has claimed the field earlier in the
+process than it sometimes does.
+
+At this point the user may remove the `replicas` field from their configuration.
+
+{{< codenew file="application/ssa/nginx-deployment-no-replicas.yaml" >}}
+
+Note that whenever the HPA controller sets the `replicas` field to a new value,
+the temporary field manager will no longer own any fields and will be
+automatically deleted. No clean up is required.
+
+## Transferring Ownership Between Users
+
+Users can transfer ownership of a field between each other by setting the field
+to the same value in both of their applied configs, causing them to share
+ownership of the field. Once the users share ownership of the field, one of them
+can remove the field from their applied configuration to give up ownership and
+complete the transfer to the other user.
+
+## Comparison with Client Side Apply
+
+A consequence of the conflict detection and resolution implemented by Server
+Side Apply is that an applier always has up to date field values in their local
+state. If they don't, they get a conflict the next time they apply. Any of the
+three options to resolve conflicts results in the applied configuration being an
+up to date subset of the object on the server's fields.
+
+This is different from Client Side Apply, where outdated values which have been
+overwritten by other users are left in an applier's local config. These values
+only become accurate when the user updates that specific field, if ever, and an
+applier has no way of knowing whether their next apply will overwrite other
+users' changes.
+
+Another difference is that an applier using Client Side Apply is unable to
+change the API version they are using, but Server Side Apply supports this use
+case.
+
+## Upgrading from client-side apply to server-side apply
+
+Client-side apply users who manage a resource with `kubectl apply` can start
+using server-side apply with the following flag.
+
+```shell
+kubectl apply --server-side [--dry-run=server]
+```
+
+By default, field management of the object transfers from client-side apply to
+kubectl server-side apply without encountering conflicts.
+
+{{< caution >}}
+Keep the `last-applied-configuration` annotation up to date.
+The annotation infers client-side apply's managed fields.
+Any fields not managed by client-side apply raise conflicts.
+
+For example, if you used `kubectl scale` to update the replicas field after
+client-side apply, then this field is not owned by client-side apply and
+creates conflicts on `kubectl apply --server-side`.
+{{< /caution >}}
+
+This behavior applies to server-side apply with the `kubectl` field manager.
+As an exception, you can opt-out of this behavior by specifying a different,
+non-default field manager, as seen in the following example. The default field
+manager for kubectl server-side apply is `kubectl`.
+
+```shell
+kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
+```
+
+## Downgrading from server-side apply to client-side apply
+
+If you manage a resource with `kubectl apply --server-side`,
+you can downgrade to client-side apply directly with `kubectl apply`.
+
+Downgrading works because kubectl server-side apply keeps the
+`last-applied-configuration` annotation up-to-date if you use
+`kubectl apply`.
+
+This behavior applies to server-side apply with the `kubectl` field manager.
+As an exception, you can opt-out of this behavior by specifying a different,
+non-default field manager, as seen in the following example. The default field
+manager for kubectl server-side apply is `kubectl`.
+
+```shell
+kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
+```
+
+## API Endpoint
+
+With the Server Side Apply feature enabled, the `PATCH` endpoint accepts the
+additional `application/apply-patch+yaml` content type. Users of Server Side
+Apply can send partially specified objects as YAML to this endpoint.  When
+applying a configuration, one should always include all the fields that they
+have an opinion about.
+
+## Clearing ManagedFields
+
+It is possible to strip all managedFields from an object by overwriting them
+using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
+non-apply operation. This can be done by overwriting the managedFields field
+with an empty entry. Two examples are:
+
+```console
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/merge-patch+json
+Accept: application/json
+Data: {"metadata":{"managedFields": [{}]}}
+```
+
+```console
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/json-patch+json
+Accept: application/json
+Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
+```
+
+This will overwrite the managedFields with a list containing a single empty
+entry that then results in the managedFields being stripped entirely from the
+object. Note that just setting the managedFields to an empty list will not
+reset the field. This is on purpose, so managedFields never get stripped by
+clients not aware of the field.
+
+In cases where the reset operation is combined with changes to other fields
+than the managedFields, this will result in the managedFields being reset
+first and the other changes being processed afterwards. As a result the
+applier takes ownership of any fields updated in the same request.
+
+{{< caution >}}
+Server Side Apply does not correctly track ownership on
+sub-resources that don't receive the resource object type. If you are
+using Server Side Apply with such a sub-resource, the changed fields
+won't be tracked.
+{{< /caution >}}
+
+## Disabling the feature
+
+Server Side Apply is a beta feature, so it is enabled by default. To turn this
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates) off,
+you need to include the `--feature-gates ServerSideApply=false` flag when
+starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all
+should have the same flag setting.
+
diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md
index 9e27b40943..a065462baf 100644
--- a/content/en/docs/setup/best-practices/certificates.md
+++ b/content/en/docs/setup/best-practices/certificates.md
@@ -124,8 +124,8 @@ Same considerations apply for the service account key pair:
 
 | private key path             | public key path             | command                 | argument                             |
 |------------------------------|-----------------------------|-------------------------|--------------------------------------|
-|  sa.key                      |                             | kube-controller-manager | service-account-private              |
-|                              | sa.pub                      | kube-apiserver          | service-account-key                  |
+|  sa.key                      |                             | kube-controller-manager | --service-account-private-key-file   |
+|                              | sa.pub                      | kube-apiserver          | --service-account-key-file           |
 
 ## Configure certificates for user accounts
 
diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md
index 2b8f7b487f..ccb31fe108 100644
--- a/content/en/docs/setup/best-practices/cluster-large.md
+++ b/content/en/docs/setup/best-practices/cluster-large.md
@@ -2,126 +2,122 @@
 reviewers:
 - davidopp
 - lavalamp
-title: Building large clusters
+title: Considerations for large clusters
 weight: 20
 ---
 
-## Support
-
-At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria:
+A cluster is a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (physical
+or virtual machines) running Kubernetes agents, managed by the
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+Kubernetes {{< param "version" >}} supports clusters with up to 5000 nodes. More specifically,
+Kubernetes is designed to accommodate configurations that meet *all* of the following criteria:
 
+* No more than 100 pods per node
 * No more than 5000 nodes
 * No more than 150000 total pods
 * No more than 300000 total containers
-* No more than 100 pods per node
 
+You can scale your cluster by adding or removing nodes. The way you do this depends
+on how your cluster is deployed.
 
-## Setup
+## Cloud provider resource quotas {#quota-issues}
 
-A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
-
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
-
-Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
-
-When setting up a large Kubernetes cluster, the following issues must be considered.
-
-### Quota Issues
-
-To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider:
-
-* Increase the quota for things like CPU, IPs, etc.
-  * In [GCE, for example,](https://cloud.google.com/compute/docs/resource-quotas) you'll want to increase the quota for:
+To avoid running into cloud provider quota issues, when creating a cluster with many nodes,
+consider:
+* Request a quota increase for cloud resources such as:
+    * Computer instances
     * CPUs
-    * VM instances
-    * Total persistent disk reserved
+    * Storage volumes
     * In-use IP addresses
-    * Firewall Rules
-    * Forwarding rules
-    * Routes
-    * Target pools
-* Gating the setup script so that it brings up new node VMs in smaller batches with waits in between, because some cloud providers rate limit the creation of VMs.
+    * Packet filtering rule sets
+    * Number of load balancers
+    * Network subnets
+    * Log streams
+* Gate the cluster scaling actions to brings up new nodes in batches, with a pause
+  between batches, because some cloud providers rate limit the creation of new instances.
 
-### Etcd storage
+## Control plane components
 
-To improve performance of large clusters, we store events in a separate dedicated etcd instance.
+For a large cluster, you need a control plane with sufficient compute and other
+resources.
 
-When creating a cluster, existing salt scripts:
+Typically you would run one or two control plane instances per failure zone,
+scaling those instances vertically first and then scaling horizontally after reaching
+the point of falling returns to (vertical) scale.
+
+You should run at least one instance per failure zone to provide fault-tolerance. Kubernetes
+nodes do not automatically steer traffic towards control-plane endpoints that are in the
+same failure zone; however, your cloud provider might have its own mechanisms to do this.
+
+For example, using a managed load balancer, you configure the load balancer to send traffic
+that originates from the kubelet and Pods in failure zone _A_, and direct that traffic only
+to the control plane hosts that are also in zone _A_. If a single control-plane host or
+endpoint failure zone _A_ goes offline, that means that all the control-plane traffic for
+nodes in zone _A_ is now being sent between zones. Running multiple control plane hosts in
+each zone makes that outcome less likely.
+
+### etcd storage
+
+To improve performance of large clusters, you can store Event objects in a separate
+dedicated etcd instance.
+
+When creating a cluster, you can (using custom tooling):
 
 * start and configure additional etcd instance
-* configure api-server to use it for storing events
+* configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events
 
-### Size of master and master components
+## Addon resources
 
-On GCE/Google Kubernetes Engine, and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes
-in your cluster. On other providers, you will need to configure it manually. For reference, the sizes we use on GCE are
+Kubernetes [resource limits](/docs/concepts/configuration/manage-resources-containers/)
+help to minimise the impact of memory leaks and other ways that pods and containers can
+impact on other components. These resource limits can and should apply to
+{{< glossary_tooltip text="addon" term_id="addons" >}} just as they apply to application
+workloads.
 
-* 1-5 nodes: n1-standard-1
-* 6-10 nodes: n1-standard-2
-* 11-100 nodes: n1-standard-4
-* 101-250 nodes: n1-standard-8
-* 251-500 nodes: n1-standard-16
-* more than 500 nodes: n1-standard-32
-
-And the sizes we use on AWS are
-
-* 1-5 nodes: m3.medium
-* 6-10 nodes: m3.large
-* 11-100 nodes: m3.xlarge
-* 101-250 nodes: m3.2xlarge
-* 251-500 nodes: c4.4xlarge
-* more than 500 nodes: c4.8xlarge
-
-{{< note >}}
-On Google Kubernetes Engine, the size of the master node adjusts automatically based on the size of your cluster. For more information, see [this blog post](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html).
-
-On AWS, master node sizes are currently set at cluster startup time and do not change, even if you later scale your cluster up or down by manually removing or adding nodes or using a cluster autoscaler.
-{{< /note >}}
-
-### Addon Resources
-
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).
-
-For example:
+For example, you can set CPU and memory limits for a logging component:
 
 ```yaml
+  ...
   containers:
   - name: fluentd-cloud-logging
-    image: k8s.gcr.io/fluentd-gcp:1.16
+    image: fluent/fluentd-kubernetes-daemonset:v1
     resources:
       limits:
         cpu: 100m
         memory: 200Mi
 ```
 
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Addons' default limits are typically based on data collected from experience running
+each addon on small or medium Kubernetes clusters. When running on large
+clusters, addons often consume more of some resources than their default limits.
+If a large cluster is deployed without adjusting these values, the addon(s)
+may continuously get killed because they keep hitting the memory limit.
+Alternatively, the addon may run but with poor performance due to CPU time
+slice restrictions.
 
-To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
+To avoid running into cluster addon resource issues, when creating a cluster with
+many nodes, consider the following:
 
-* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
-  * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
-* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
-  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
-* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
-  * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+* Some addons scale vertically - there is one replica of the addon for the cluster
+  or serving a whole failure zone. For these addons, increase requests and limits
+  as you scale out your cluster.
+* Many addons scale horizontally - you add capacity by running more pods - but with
+  a very large cluster you may also need to raise CPU or memory limits slightly.
+  The VerticalPodAutoscaler can run in _recommender_ mode to provide suggested
+  figures for requests and limits.
+* Some addons run as one copy per node, controlled by a {{< glossary_tooltip text="DaemonSet"
+  term_id="daemonset" >}}: for example, a node-level log aggregator. Similar to
+  the case with horizontally-scaled addons, you may also need to raise CPU or memory
+  limits slightly.
 
-Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
-and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
-out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
+## {{% heading "whatsnext" %}}
 
-For directions on how to detect if addon containers are hitting resource limits, see the
-[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
-
-### Allowing minor node failure at startup
-
-For various reasons (see [#18969](https://github.com/kubernetes/kubernetes/issues/18969) for more details) running
-`kube-up.sh` with a very large `NUM_NODES` may fail due to a very small number of nodes not coming up properly.
-Currently you have two choices: restart the cluster (`kube-down.sh` and then `kube-up.sh` again), or before
-running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to whatever value you feel comfortable
-with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
-reason for the failure, those additional nodes may join later or the cluster may remain at a size of
-`NUM_NODES - ALLOWED_NOTREADY_NODES`.
+`VerticalPodAutoscaler` is a custom resource that you can deploy into your cluster
+to help you manage resource requests and limits for pods.  
+Visit [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)
+to learn more about `VerticalPodAutoscaler` and how you can use it to scale cluster
+components, including cluster-critical addons.
 
+The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
+integrates with a number of cloud providers to help you run the right number of
+nodes for the level of resource demand in your cluster.
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index 7c2622641b..501e954642 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -4,401 +4,141 @@ reviewers:
 - justinsb
 - quinton-hoole
 title: Running in multiple zones
-weight: 10
+weight: 20
 content_type: concept
 ---
 
 <!-- overview -->
 
-This page describes how to run a cluster in multiple zones.
-
-
+This page describes running Kubernetes across multiple zones.
 
 <!-- body -->
 
-## Introduction
+## Background
 
-Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
-(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
-This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
-nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
-Full Cluster Federation allows combining separate
-Kubernetes clusters running in different regions or cloud providers
-(or on-premises data centers).  However, many
-users simply want to run a more available Kubernetes cluster in multiple zones
-of their single cloud provider, and this is what the multizone support in 1.2 allows
-(this previously went by the nickname "Ubernetes Lite").
+Kubernetes is designed so that a single Kubernetes cluster can run
+across multiple failure zones, typically where these zones fit within
+a logical grouping called a _region_. Major cloud providers define a region
+as a set of failure zones (also called _availability zones_) that provide
+a consistent set of features: within a region, each zone offers the same
+APIs and services.
 
-Multizone support is deliberately limited: a single Kubernetes cluster can run
-in multiple zones, but only within the same region (and cloud provider).  Only
-GCE and AWS are currently supported automatically (though it is easy to
-add similar support for other clouds or even bare metal, by simply arranging
-for the appropriate labels to be added to nodes and volumes).
+Typical cloud architectures aim to minimize the chance that a failure in
+one zone also impairs services in another zone.
 
+## Control plane behavior
 
-## Functionality
+All [control plane components](/docs/concepts/overview/components/#control-plane-components)
+support running as a pool of interchangable resources, replicated per
+component.
 
-When nodes are started, the kubelet automatically adds labels to them with
-zone information.
-
-Kubernetes will automatically spread the pods in a replication controller
-or service across nodes in a single-zone cluster (to reduce the impact of
-failures.)  With multiple-zone clusters, this spreading behavior is
-extended across zones (to reduce the impact of zone failures.)  (This is
-achieved via `SelectorSpreadPriority`).  This is a best-effort
-placement, and so if the zones in your cluster are heterogeneous
-(e.g. different numbers of nodes, different types of nodes, or
-different pod resource requirements), this might prevent perfectly
-even spreading of your pods across zones. If desired, you can use
-homogeneous zones (same number and types of nodes) to reduce the
-probability of unequal spreading.
-
-When persistent volumes are created, the `PersistentVolumeLabel`
-admission controller automatically adds zone labels to them.  The scheduler (via the
-`VolumeZonePredicate` predicate) will then ensure that pods that claim a
-given volume are only placed into the same zone as that volume, as volumes
-cannot be attached across zones.
-
-## Limitations
-
-There are some important limitations of the multizone support:
-
-* We assume that the different zones are located close to each other in the
-network, so we don't perform any zone-aware routing.  In particular, traffic
-that goes via services might cross zones (even if some pods backing that service
-exist in the same zone as the client), and this may incur additional latency and cost.
-
-* Volume zone-affinity will only work with a `PersistentVolume`, and will not
-work if you directly specify an EBS volume in the pod spec (for example).
-
-* Clusters cannot span clouds or regions (this functionality will require full
-federation support).
-
-* Although your nodes are in multiple zones, kube-up currently builds
-a single master node by default.  While services are highly
-available and can tolerate the loss of a zone, the control plane is
-located in a single zone.  Users that want a highly available control
-plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
-
-### Volume limitations
-The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
-
-* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
-  pod affinity or anti-affinity policies.
-
-* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
-  may not provide a uniform distribution of storage across zones.
-
-* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
-  needs to be configured for a specific single zone, or the PVs need to be
-  statically provisioned in a specific zone. Another workaround is to use a
-  StatefulSet, which will ensure that all the volumes for a replica are
-  provisioned in the same zone.
-
-## Walkthrough
-
-We're now going to walk through setting up and using a multi-zone
-cluster on both GCE & AWS.  To do so, you bring up a full cluster
-(specifying `MULTIZONE=true`), and then you add nodes in additional zones
-by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
-
-### Bringing up your cluster
-
-Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
-
-GCE:
-
-```shell
-curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
-```
-
-AWS:
-
-```shell
-curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
-```
-
-This step brings up a cluster as normal, still running in a single zone
-(but `MULTIZONE=true` has enabled multi-zone capabilities).
-
-### Nodes are labeled
-
-View the nodes; you can see that they are labeled with zone information.
-They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far.  The
-labels are `failure-domain.beta.kubernetes.io/region` for the region,
-and `failure-domain.beta.kubernetes.io/zone` for the zone:
-
-```shell
-kubectl get nodes --show-labels
-```
-
-The output is similar to this:
-
-```shell
-NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-```
-
-### Add more nodes in a second zone
-
-Let's add another set of nodes to the existing cluster, reusing the
-existing master, running in a different zone (us-central1-b or us-west-2b).
-We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
-kube-up will not create a new master, but will reuse one that was previously
-created instead.
-
-GCE:
-
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
-```
-
-On AWS we also need to specify the network CIDR for the additional
-subnet, along with the master internal IP address:
-
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
-```
-
-
-View the nodes again; 3 more nodes should have launched and be tagged
-in us-central1-b:
-
-```shell
-kubectl get nodes --show-labels
-```
-
-The output is similar to this:
-
-```shell
-NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
-kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
-```
-
-### Volume affinity
-
-Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
-
-```bash
-kubectl apply -f - <<EOF
-{
-  "apiVersion": "v1",
-  "kind": "PersistentVolumeClaim",
-  "metadata": {
-    "name": "claim1",
-    "annotations": {
-        "volume.alpha.kubernetes.io/storage-class": "foo"
-    }
-  },
-  "spec": {
-    "accessModes": [
-      "ReadWriteOnce"
-    ],
-    "resources": {
-      "requests": {
-        "storage": "5Gi"
-      }
-    }
-  }
-}
-EOF
-```
+When you deploy a cluster control plane, place replicas of
+control plane components across multple failure zones. If availability is
+an important concern, select at least three failure zones and replicate
+each individual control plane component (API server, scheduler, etcd,
+cluster controller manager) across at least three failure zones.
+If you are running a cloud controller manager then you should
+also replicate this across all the failure zones you selected.
 
 {{< note >}}
-For version 1.3+ Kubernetes will distribute dynamic PV claims across
-the configured zones. For version 1.2, dynamic persistent volumes were
-always created in the zone of the cluster master
-(here us-central1-a / us-west-2a); that issue
-([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
-was addressed in 1.3+.
+Kubernetes does not provide cross-zone resilience for the API server
+endpoints. You can use various techniques to improve availability for
+the cluster API server, including DNS round-robin, SRV records, or
+a third-party load balancing solution with health checking.
 {{< /note >}}
 
-Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
+## Node behavior
 
-```shell
-kubectl get pv --show-labels
-```
+Kubernetes automatically spreads the Pods for
+workload resources (such as {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+or {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})
+across different nodes in a cluster. This spreading helps
+reduce the impact of failures.
 
-The output is similar to this:
+When nodes start up, the kubelet on each node automatically adds
+{{< glossary_tooltip text="labels" term_id="label" >}} to the Node object
+that represents that specific kubelet in the Kubernetes API.
+These labels can include
+[zone information](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone).
 
-```shell
-NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
-pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
-```
+If your cluster spans multiple zones or regions, you can use node labels
+in conjunction with
+[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+to control how Pods are spread across your cluster among fault domains:
+regions, zones, and even specific nodes.
+These hints enable the
+{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} to place
+Pods for better expected availability, reducing the risk that a correlated
+failure affects your whole workload.
 
-So now we will create a pod that uses the persistent volume claim.
-Because GCE PDs / AWS EBS volumes cannot be attached across zones,
-this means that this pod can only be created in the same zone as the volume:
+For example, you can set a constraint to make sure that the
+3 replicas of a StatefulSet are all running in different zones to each
+other, whenever that is feasible. You can define this declaratively
+without explicitly defining which availability zones are in use for
+each workload.
 
-```yaml
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-    - name: myfrontend
-      image: nginx
-      volumeMounts:
-      - mountPath: "/var/www/html"
-        name: mypd
-  volumes:
-    - name: mypd
-      persistentVolumeClaim:
-        claimName: claim1
-EOF
-```
+### Distributing nodes across zones
 
-Note that the pod was automatically created in the same zone as the volume, as
-cross-zone attachments are not generally permitted by cloud providers:
+Kubernetes' core does not create nodes for you; you need to do that yourself,
+or use a tool such as the [Cluster API](https://cluster-api.sigs.k8s.io/) to
+manage nodes on your behalf.
 
-```shell
-kubectl describe pod mypod | grep Node
-```
+Using tools such as the Cluster API you can define sets of machines to run as
+worker nodes for your cluster across multiple failure domains, and rules to
+automatically heal the cluster in case of whole-zone service disruption.
 
-```shell
-Node:        kubernetes-minion-9vlv/10.240.0.5
-```
+## Manual zone assignment for Pods
 
-And check node labels:
+You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
+to Pods that you create, as well as to Pod templates in workload resources
+such as Deployment, StatefulSet, or Job.
 
-```shell
-kubectl get node kubernetes-minion-9vlv --show-labels
-```
+## Storage access for zones
 
-```shell
-NAME                     STATUS    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-```
+When persistent volumes are created, the `PersistentVolumeLabel`
+[admission controller](/docs/reference/access-authn-authz/admission-controllers/)
+automatically adds zone labels to any PersistentVolumes that are linked to a specific
+zone. The {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} then ensures,
+through its `NoVolumeZoneConflict` predicate, that pods which claim a given PersistentVolume
+are only placed into the same zone as that volume.
 
-### Pods are spread across zones
+You can specify a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
+for PersistentVolumeClaims that specifies the failure domains (zones) that the
+storage in that class may use.
+To learn about configuring a StorageClass that is aware of failure domains or zones,
+see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies).
 
-Pods in a replication controller or service are automatically spread
-across zones.  First, let's launch more nodes in a third zone:
+## Networking
 
-GCE:
+By itself, Kubernetes does not include zone-aware networking. You can use a
+[network plugin](docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+to configure cluster networking, and that network solution might have zone-specific
+elements. For example, if your cloud provider supports Services with
+`type=LoadBalancer`, the load balancer might only send traffic to Pods running in the
+same zone as the load balancer element processing a given connection.
+Check your cloud provider's documentation for details.
 
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
-```
+For custom or on-premises deployments, similar considerations apply.
+{{< glossary_tooltip text="Service" term_id="service" >}} and
+{{< glossary_tooltip text="Ingress" term_id="ingress" >}} behavior, including handling
+of different failure zones, does vary depending on exactly how your cluster is set up.
 
-AWS:
+## Fault recovery
 
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
-```
+When you set up your cluster, you might also need to consider whether and how
+your setup can restore service if all of the failure zones in a region go
+off-line at the same time. For example, do you rely on there being at least
+one node able to run Pods in a zone?  
+Make sure that any cluster-critical repair work does not rely
+on there being at least one healthy node in your cluster. For example: if all nodes
+are unhealthy, you might need to run a repair Job with a special
+{{< glossary_tooltip text="toleration" term_id="toleration" >}} so that the repair
+can complete enough to bring at least one node into service.
 
-Verify that you now have nodes in 3 zones:
-
-```shell
-kubectl get nodes --show-labels
-```
-
-Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
-
-```shell
-find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
-```
-
-The pods should be spread across all 3 zones:
-
-```shell
-kubectl describe pod -l app=guestbook | grep Node
-```
-
-```shell
-Node:        kubernetes-minion-9vlv/10.240.0.5
-Node:        kubernetes-minion-281d/10.240.0.8
-Node:        kubernetes-minion-olsh/10.240.0.11
-```
-
-```shell
-kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
-```
-
-```shell
-NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
-```
-
-
-Load-balancers span all zones in a cluster; the guestbook-go example
-includes an example load-balanced service:
-
-```shell
-kubectl describe service guestbook | grep LoadBalancer.Ingress
-```
-
-The output is similar to this:
-
-```shell
-LoadBalancer Ingress:   130.211.126.21
-```
-
-Set the above IP:
-
-```shell
-export IP=130.211.126.21
-```
-
-Explore with curl via IP:
-
-```shell
-curl -s http://${IP}:3000/env | grep HOSTNAME
-```
-
-The output is similar to this:
-
-```shell
-  "HOSTNAME": "guestbook-44sep",
-```
-
-Again, explore multiple times:
-
-```shell
-(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
-```
-
-The output is similar to this:
-
-```shell
-  "HOSTNAME": "guestbook-44sep",
-  "HOSTNAME": "guestbook-hum5n",
-  "HOSTNAME": "guestbook-ppm40",
-```
-
-The load balancer correctly targets all the pods, even though they are in multiple zones.
-
-### Shutting down the cluster
-
-When you're done, clean up:
-
-GCE:
-
-```shell
-KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
-```
-
-AWS:
-
-```shell
-KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
-```
+Kubernetes doesn't come with an answer for this challenge; however, it's
+something to consider.
 
+## {{% heading "whatsnext" %}}
 
+To learn how the scheduler places Pods in a cluster, honoring the configured constraints,
+visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/).
diff --git a/content/en/docs/setup/best-practices/node-conformance.md b/content/en/docs/setup/best-practices/node-conformance.md
index 5e75959b18..6a3822ef70 100644
--- a/content/en/docs/setup/best-practices/node-conformance.md
+++ b/content/en/docs/setup/best-practices/node-conformance.md
@@ -13,12 +13,6 @@ verification and functionality test for a node. The test validates whether the
 node meets the minimum requirements for Kubernetes; a node that passes the test
 is qualified to join a Kubernetes cluster.
 
-## Limitations
-
-In Kubernetes version 1.5, node conformance test has the following limitations:
-
-* Node conformance test only supports Docker as the container runtime.
-
 ## Node Prerequisite
 
 To run node conformance test, a node must satisfy the same prerequisites as a
@@ -31,10 +25,11 @@ daemons installed:
 ## Running Node Conformance Test
 
 To run the node conformance test, perform the following steps:
-
-1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`,
-because the test framework starts a local master to test Kubelet. There are some
-other Kubelet flags you may care:
+1. Work out the value of the `--kubeconfig` option for the kubelet; for example:
+   `--kubeconfig=/var/lib/kubelet/config.yaml`.
+    Because the test framework starts a local control plane to test the kubelet,
+    use `http://localhost:8080` as the URL of the API server.
+    There are some other kubelet command line parameters you may want to use:
   * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR
     to Kubelet, for example `--pod-cidr=10.180.0.0/24`.
   * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
diff --git a/content/en/docs/setup/learning-environment/_index.md b/content/en/docs/setup/learning-environment/_index.md
index f17c7e2f9d..672bbd69ed 100644
--- a/content/en/docs/setup/learning-environment/_index.md
+++ b/content/en/docs/setup/learning-environment/_index.md
@@ -2,3 +2,32 @@
 title: Learning environment
 weight: 20
 ---
+
+<!--
+{{/* There is a Netlify redirect from this page to /docs/tasks/tools/ */}}
+{{/* This page content only exists to provide a navigation stub */}}
+{{/* and to protect in case that redirect is one day removed. */}}
+
+{{/* If you're localizing this page, you only need to copy the front matter */}}
+{{/* and add a redirect into "/static/_redirects", for YOUR localization. */}}
+-->
+
+## kind
+
+[`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local computer. This tool requires that you have
+[Docker](https://docs.docker.com/get-docker/) installed and configured.
+
+The kind [Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) page
+shows you what you need to do to get up and running with kind.
+
+## minikube
+
+Like `kind`, [`minikube`](https://minikube.sigs.k8s.io/) is a tool that lets you run Kubernetes
+locally. `minikube` runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out
+Kubernetes, or for daily development work.
+
+You can follow the official
+[Get Started!](https://minikube.sigs.k8s.io/docs/start/) guide if your focus is
+on getting the tool installed.
diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md
deleted file mode 100644
index d0b07b046a..0000000000
--- a/content/en/docs/setup/learning-environment/minikube.md
+++ /dev/null
@@ -1,519 +0,0 @@
----
-reviewers:
-- dlorenc
-- balopat
-- aaron-prindle
-title: Installing Kubernetes with Minikube
-weight: 30
-content_type: concept
----
-
-<!-- overview -->
-
-Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a Virtual Machine (VM) on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
-
-
-
-<!-- body -->
-
-## Minikube Features
-
-Minikube supports the following Kubernetes features:
-
-* DNS
-* NodePorts
-* ConfigMaps and Secrets
-* Dashboards
-* Container Runtime: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/), and [containerd](https://github.com/containerd/containerd)
-* Enabling CNI (Container Network Interface)
-* Ingress
-
-## Installation
-
-See [Installing Minikube](/docs/tasks/tools/install-minikube/).
-
-## Quickstart
-
-This brief demo guides you on how to start, use, and delete Minikube locally. Follow the steps given below to start and explore Minikube.
-
-1. Start Minikube and create a cluster:
-
-   ```shell
-    minikube start
-   ```
-
-   The output is similar to this:
-
-   ```
-   Starting local Kubernetes cluster...
-   Running pre-create checks...
-   Creating machine...
-   Starting local Kubernetes cluster...
-   ```
-
-   For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster).
-
-2. Now, you can interact with your cluster using kubectl. For more information, see [Interacting with Your Cluster](#interacting-with-your-cluster).
-
-   Let's create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`.
-
-   ```shell
-   kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
-   ```
-
-   The output is similar to this:
-
-   ```
-   deployment.apps/hello-minikube created
-   ```
-3. To access the `hello-minikube` Deployment, expose it as a Service:
-
-   ```shell
-   kubectl expose deployment hello-minikube --type=NodePort --port=8080
-   ```
-
-   The option `--type=NodePort` specifies the type of the Service.
-
-   The output is similar to this:
-
-   ```
-   service/hello-minikube exposed
-   ```
-
-4. The `hello-minikube` Pod is now launched but you have to wait until the Pod is up before accessing it via the exposed Service.
-
-   Check if the Pod is up and running:
-
-   ```shell
-   kubectl get pod
-   ```
-
-   If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created:
-
-   ```
-   NAME                              READY     STATUS              RESTARTS   AGE
-   hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
-   ```
-
-   If the output shows the `STATUS` as `Running`, the Pod is now up and running:
-
-   ```
-   NAME                              READY     STATUS    RESTARTS   AGE
-   hello-minikube-3383150820-vctvh   1/1       Running   0          13s
-   ```
-
-5. Get the URL of the exposed Service to view the Service details:
-
-   ```shell
-   minikube service hello-minikube --url
-   ```
-
-6. To view the details of your local cluster, copy and paste the URL you got as the output, on your browser.
-
-   The output is similar to this:
-
-   ```
-   Hostname: hello-minikube-7c77b68cff-8wdzq
-
-   Pod Information:
-    -no pod information available-
-
-   Server values:
-    server_version=nginx: 1.13.3 - lua: 10008
-
-   Request Information:
-    client_address=172.17.0.1
-    method=GET
-    real path=/
-    query=
-    request_version=1.1
-    request_scheme=http
-    request_uri=http://192.168.99.100:8080/
-
-   Request Headers:
-        accept=*/*
-        host=192.168.99.100:30674
-        user-agent=curl/7.47.0
-
-   Request Body:
-        -no body in request-
-   ```
-
-   If you no longer want the Service and cluster to run, you can delete them.
-
-7. Delete the `hello-minikube` Service:
-
-   ```shell
-   kubectl delete services hello-minikube
-   ```
-
-   The output is similar to this:
-
-   ```
-   service "hello-minikube" deleted
-   ```
-
-8. Delete the `hello-minikube` Deployment:
-
-   ```shell
-   kubectl delete deployment hello-minikube
-   ```
-
-   The output is similar to this:
-
-   ```
-   deployment.extensions "hello-minikube" deleted
-   ```
-
-9. Stop the local Minikube cluster:
-
-   ```shell
-   minikube stop
-   ```
-
-   The output is similar to this:
-
-   ```
-   Stopping "minikube"...
-   "minikube" stopped.
-   ```
-
-   For more information, see [Stopping a Cluster](#stopping-a-cluster).
-
-10. Delete the local Minikube cluster:
-
-    ```shell
-    minikube delete
-    ```
-    The output is similar to this:
-    ```
-    Deleting "minikube" ...
-    The "minikube" cluster has been deleted.
-    ```
-	For more information, see [Deleting a cluster](#deleting-a-cluster).
-
-## Managing your Cluster
-
-### Starting a Cluster
-
-The `minikube start` command can be used to start your cluster.
-This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
-This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster.
-
-{{< note >}}
-If you are behind a web proxy, you need to pass this information to the `minikube start` command:
-
-```shell
-https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
-```
-Unfortunately, setting the environment variables alone does not work.
-
-Minikube also creates a "minikube" context, and sets it to default in kubectl.
-To switch back to this context, run this command: `kubectl config use-context minikube`.
-{{< /note >}}
-
-#### Specifying the Kubernetes version
-
-You can specify the version of Kubernetes for Minikube to use by
-adding the `--kubernetes-version` string to the `minikube start` command. For
-example, to run version {{< param "fullversion" >}}, you would run the following:
-
-```
-minikube start --kubernetes-version {{< param "fullversion" >}}
-```
-#### Specifying the VM driver
-You can change the VM driver by adding the `--driver=<enter_driver_name>` flag to `minikube start`.
-For example the command would be.
-```shell
-minikube start --driver=<driver_name>
-```
-Minikube supports the following drivers:
-{{< note >}}
-See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install
-plugins.
-{{< /note >}}
-
-* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/))
-* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/))
-* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (EXPERIMENTAL)
-* vmwarefusion
-* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/))
-* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/))
-* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/))
-Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
-* vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver)
-* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/))
-* none (Runs the Kubernetes components on the host and not in a virtual machine. You need to be running Linux and to have {{< glossary_tooltip term_id="docker" >}} installed.)
-
-{{< caution >}}
-If you use the `none` driver, some Kubernetes components run as privileged containers that have side effects outside of the Minikube environment. Those side effects mean that the `none` driver is not recommended for personal workstations.
-{{< /caution >}}
-
-#### Starting a cluster on alternative container runtimes
-You can start Minikube on the following container runtimes.
-{{< tabs name="container_runtimes" >}}
-{{% tab name="containerd" %}}
-To use [containerd](https://github.com/containerd/containerd) as the container runtime, run:
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --container-runtime=containerd \
-    --bootstrapper=kubeadm
-```
-
-Or you can use the extended version:
-
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --extra-config=kubelet.container-runtime=remote \
-    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
-    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
-    --bootstrapper=kubeadm
-```
-{{% /tab %}}
-{{% tab name="CRI-O" %}}
-To use [CRI-O](https://cri-o.io/) as the container runtime, run:
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --container-runtime=cri-o \
-    --bootstrapper=kubeadm
-```
-Or you can use the extended version:
-
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --extra-config=kubelet.container-runtime=remote \
-    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
-    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
-    --bootstrapper=kubeadm
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-#### Use local images by re-using the Docker daemon
-
-When using a single VM for Kubernetes, it's useful to reuse Minikube's built-in Docker daemon. Reusing the built-in daemon means you don't have to build a Docker registry on your host machine and push the image into it. Instead, you can build inside the same Docker daemon as Minikube, which speeds up local experiments.
-
-{{< note >}}
-Be sure to tag your Docker image with something other than latest and use that tag to pull the image. Because `:latest` is the default value, with a corresponding default image pull policy of `Always`, an image pull error (`ErrImagePull`) eventually results if you do not have the Docker image in the default Docker registry (usually DockerHub).
-{{< /note >}}
-
-To work with the Docker daemon on your Mac/Linux host, run the last line from `minikube docker-env`.
-
-You can now use Docker at the command line of your host Mac/Linux machine to communicate with the Docker daemon inside the Minikube VM:
-
-```shell
-docker ps
-```
-
-{{< note >}}
-On Centos 7, Docker may report the following error:
-
-```
-Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
-```
-
-You can fix this by updating /etc/sysconfig/docker to ensure that Minikube's environment changes are respected:
-
-```shell
-< DOCKER_CERT_PATH=/etc/docker
----
-> if [ -z "${DOCKER_CERT_PATH}" ]; then
->   DOCKER_CERT_PATH=/etc/docker
-> fi
-```
-{{< /note >}}
-
-### Configuring Kubernetes
-
-Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values.
-To use this feature, you can use the `--extra-config` flag on the `minikube start` command.
-
-This flag is repeated, so you can pass it several times with several different values to set multiple options.
-
-This flag takes a string of the form `component.key=value`, where `component` is one of the strings from the below list, `key` is a value on the
-configuration struct and `value` is the value to set.
-
-Valid keys can be found by examining the documentation for the Kubernetes `componentconfigs` for each component.
-Here is the documentation for each supported configuration:
-
-* [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
-* [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions)
-* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration)
-* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration)
-* [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig)
-* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration)
-
-#### Examples
-
-To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-config=kubelet.MaxPods=5`.
-
-This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
-
-To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.authorization-mode=RBAC`.
-
-### Stopping a Cluster
-The `minikube stop` command can be used to stop your cluster.
-This command shuts down the Minikube Virtual Machine, but preserves all cluster state and data.
-Starting the cluster again will restore it to its previous state.
-
-### Deleting a Cluster
-The `minikube delete` command can be used to delete your cluster.
-This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.
-
-### Upgrading Minikube
-If you are using macOS and [Brew Package Manager](https://brew.sh/) is installed run:
-
-```shell
-brew update
-brew upgrade minikube
-```
-
-## Interacting with Your Cluster
-
-### Kubectl
-
-The `minikube start` command creates a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) called "minikube".
-This context contains the configuration to communicate with your Minikube cluster.
-
-Minikube sets this context to default automatically, but if you need to switch back to it in the future, run:
-
-`kubectl config use-context minikube`
-
-Or pass the context on each command like this:
-
-`kubectl get pods --context=minikube`
-
-### Dashboard
-
-To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting Minikube to get the address:
-
-```shell
-minikube dashboard
-```
-
-### Services
-
-To access a Service exposed via a node port, run this command in a shell after starting Minikube to get the address:
-
-```shell
-minikube service [-n NAMESPACE] [--url] NAME
-```
-
-## Networking
-
-The Minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command.
-Any services of type `NodePort` can be accessed over that IP address, on the NodePort.
-
-To determine the NodePort for your service, you can use a `kubectl` command like this:
-
-`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
-
-## Persistent Volumes
-Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`.
-These PersistentVolumes are mapped to a directory inside the Minikube VM.
-
-The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`).
-However, Minikube is configured to persist files stored under the following host directories:
-
-* `/data`
-* `/var/lib/minikube`
-* `/var/lib/docker`
-
-Here is an example PersistentVolume config to persist data in the `/data` directory:
-
-```yaml
-apiVersion: v1
-kind: PersistentVolume
-metadata:
-  name: pv0001
-spec:
-  accessModes:
-    - ReadWriteOnce
-  capacity:
-    storage: 5Gi
-  hostPath:
-    path: /data/pv0001/
-```
-
-## Mounted Host Folders
-Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host.  These are not configurable at the moment and different for the driver and OS you are using.
-
-{{< note >}}
-Host folder sharing is not implemented in the KVM driver yet.
-{{< /note >}}
-
-| Driver | OS | HostFolder | VM |
-| --- | --- | --- | --- |
-| VirtualBox | Linux | /home | /hosthome |
-| VirtualBox | macOS | /Users | /Users |
-| VirtualBox | Windows | C://Users | /c/Users |
-| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
-| Xhyve | macOS | /Users | /Users |
-
-## Private Container Registries
-
-To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/).
-
-We recommend you use `ImagePullSecrets`, but if you would like to configure access on the Minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory.
-
-## Add-ons
-
-In order to have Minikube properly start or restart custom addons,
-place the addons you wish to be launched with Minikube in the `~/.minikube/addons`
-directory. Addons in this folder will be moved to the Minikube VM and
-launched each time Minikube is started or restarted.
-
-## Using Minikube with an HTTP Proxy
-
-Minikube creates a Virtual Machine that includes Kubernetes and a Docker daemon.
-When Kubernetes attempts to schedule containers using Docker, the Docker daemon may require external network access to pull containers.
-
-If you are behind an HTTP proxy, you may need to supply Docker with the proxy settings.
-To do this, pass the required environment variables as flags during `minikube start`.
-
-For example:
-
-```shell
-minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
-                 --docker-env https_proxy=https://$YOURPROXY:PORT
-```
-
-If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent `kubectl` from directly reaching it.
-To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with:
-
-```shell
-export no_proxy=$no_proxy,$(minikube ip)
-```
-
-## Known Issues
-
-Features that require multiple nodes will not work in Minikube.
-
-## Design
-
-Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [kubeadm](https://github.com/kubernetes/kubeadm) to provision a Kubernetes cluster.
-
-For more information about Minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
-
-## Additional Links
-
-* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/).
-* **Development Guide**: See [Contributing](https://minikube.sigs.k8s.io/docs/contrib/) for an overview of how to send pull requests.
-* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://minikube.sigs.k8s.io/docs/contrib/building/).
-* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube, see the [adding dependencies guide](https://minikube.sigs.k8s.io/docs/contrib/drivers/).
-* **Adding a New Addon**: For instructions on how to add a new addon for Minikube, see the [adding an addon guide](https://minikube.sigs.k8s.io/docs/contrib/addons/).
-* **MicroK8s**: Linux users wishing to avoid running a virtual machine may consider [MicroK8s](https://microk8s.io/) as an alternative.
-
-## Community
-
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
-
-
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 87275861df..ecaf53c03f 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -4,371 +4,92 @@ reviewers:
 - bart0sh
 title: Container runtimes
 content_type: concept
-weight: 10
+weight: 20
 ---
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.6" state="stable" >}}
-To run containers in Pods, Kubernetes uses a container runtime. Here are
-the installation instructions for various runtimes.
-
 
+You need to install a
+{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
+into each node in the cluster so that Pods can run there. This page outlines
+what is involved and describes related tasks for setting up nodes.
 
 <!-- body -->
 
+This page lists details for using several common container runtimes with
+Kubernetes, on Linux:
 
-{{< caution >}}
-A flaw was found in the way runc handled system file descriptors when running containers.
-A malicious container could use this flaw to overwrite contents of the runc binary and
-consequently run arbitrary commands on the container host system.
-
-Please refer to [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) for more
-information about the issue.
-{{< /caution >}}
-
-### Applicability
+- [containerd](#containerd)
+- [CRI-O](#cri-o)
+- [Docker](#docker)
 
 {{< note >}}
-This document is written for users installing CRI onto Linux. For other operating
-systems, look for documentation specific to your platform.
+For other operating systems, look for documentation specific to your platform.
 {{< /note >}}
 
-You should execute all the commands in this guide as `root`. For example, prefix commands
-with `sudo `, or become `root` and run the commands as that user.
-
-### Cgroup drivers
-
-When systemd is chosen as the init system for a Linux distribution, the init process generates
-and consumes a root control group (`cgroup`) and acts as a cgroup manager. Systemd has a tight
-integration with cgroups and will allocate cgroups per process. It's possible to configure your
-container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside systemd means
-that there will be two different cgroup managers.
+## Cgroup drivers
 
 Control groups are used to constrain resources that are allocated to processes.
-A single cgroup manager will simplify the view of what resources are being allocated
-and will by default have a more consistent view of the available and in-use resources. When we have
-two managers we end up with two views of those resources. We have seen cases in the field
-where nodes that are configured to use `cgroupfs` for the kubelet and Docker, and `systemd`
-for the rest of the processes running on the node becomes unstable under resource pressure.
+
+When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init
+system for a Linux distribution, the init process generates and consumes a root control group
+(`cgroup`) and acts as a cgroup manager.
+Systemd has a tight integration with cgroups and allocates a cgroup per systemd unit. It's possible
+to configure your container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside
+systemd means that there will be two different cgroup managers.
+
+A single cgroup manager simplifies the view of what resources are being allocated
+and will by default have a more consistent view of the available and in-use resources.
+When there are two cgroup managers on a system, you end up with two views of those resources.
+In the field, people have reported cases where nodes that are configured to use `cgroupfs`
+for the kubelet and Docker, but `systemd` for the rest of the processes, become unstable under
+resource pressure.
 
 Changing the settings such that your container runtime and kubelet use `systemd` as the cgroup driver
-stabilized the system. Please note the `native.cgroupdriver=systemd` option in the Docker setup below.
+stabilized the system. To configure this for Docker, set `native.cgroupdriver=systemd`.
 
 {{< caution >}}
-Changing the cgroup driver of a Node that has joined a cluster is highly unrecommended.
+Changing the cgroup driver of a Node that has joined a cluster is strongly *not* recommended.  
 If the kubelet has created Pods using the semantics of one cgroup driver, changing the container
-runtime to another cgroup driver can cause errors when trying to re-create the PodSandbox
-for such existing Pods. Restarting the kubelet may not solve such errors. The recommendation
-is to drain the Node from its workloads, remove it from the cluster and re-join it.
+runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox
+for such existing Pods. Restarting the kubelet may not solve such errors.
+
+If you have automation that makes it feasible, replace the node with another using the updated
+configuration, or reinstall it using automation.
 {{< /caution >}}
 
-## Docker
+## Container runtimes
 
-On each of your machines, install Docker.
-Version 19.03.11 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well.
-Keep track of the latest verified Docker version in the Kubernetes release notes.
+{{% thirdparty-content %}}
 
-Use the following commands to install Docker on your system:
-
-{{< tabs name="tab-cri-docker-installation" >}}
-{{% tab name="Ubuntu 16.04+" %}}
-
-```shell
-# (Install Docker CE)
-## Set up the repository:
-### Install packages to allow apt to use a repository over HTTPS
-apt-get update && apt-get install -y \
-  apt-transport-https ca-certificates curl software-properties-common gnupg2
-```
-
-```shell
-# Add Docker's official GPG key:
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-```
-
-```shell
-# Add the Docker apt repository:
-add-apt-repository \
-  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-  $(lsb_release -cs) \
-  stable"
-```
-
-```shell
-# Install Docker CE
-apt-get update && apt-get install -y \
-  containerd.io=1.2.13-2 \
-  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
-```
-
-```shell
-# Set up the Docker daemon
-cat > /etc/docker/daemon.json <<EOF
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2"
-}
-EOF
-```
-
-```shell
-mkdir -p /etc/systemd/system/docker.service.d
-```
-
-```shell
-# Restart Docker
-systemctl daemon-reload
-systemctl restart docker
-```
-{{% /tab %}}
-{{% tab name="CentOS/RHEL 7.4+" %}}
-
-```shell
-# (Install Docker CE)
-## Set up the repository
-### Install required packages
-yum install -y yum-utils device-mapper-persistent-data lvm2
-```
-
-```shell
-## Add the Docker repository
-yum-config-manager --add-repo \
-  https://download.docker.com/linux/centos/docker-ce.repo
-```
-
-```shell
-# Install Docker CE
-yum update -y && yum install -y \
-  containerd.io-1.2.13 \
-  docker-ce-19.03.11 \
-  docker-ce-cli-19.03.11
-```
-
-```shell
-## Create /etc/docker
-mkdir /etc/docker
-```
-
-```shell
-# Set up the Docker daemon
-cat > /etc/docker/daemon.json <<EOF
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2",
-  "storage-opts": [
-    "overlay2.override_kernel_check=true"
-  ]
-}
-EOF
-```
-
-```shell
-mkdir -p /etc/systemd/system/docker.service.d
-```
-
-```shell
-# Restart Docker
-systemctl daemon-reload
-systemctl restart docker
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-If you want the docker service to start on boot, run the following command:
-
-```shell
-sudo systemctl enable docker
-```
-
-Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
-for more information.
-
-## CRI-O
-
-This section contains the necessary steps to install `CRI-O` as CRI runtime.
-
-Use the following commands to install CRI-O on your system:
-
-{{< note >}}
-The CRI-O major and minor versions must match the Kubernetes major and minor versions.
-For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o).
-{{< /note >}}
-
-### Prerequisites
-
-```shell
-modprobe overlay
-modprobe br_netfilter
-
-# Set up required sysctl params, these persist across reboots.
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
-net.bridge.bridge-nf-call-iptables  = 1
-net.ipv4.ip_forward                 = 1
-net.bridge.bridge-nf-call-ip6tables = 1
-EOF
-
-sysctl --system
-```
-
-{{< tabs name="tab-cri-cri-o-installation" >}}
-{{% tab name="Debian" %}}
-
-To install CRI-O on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
-
-| Operating system | $OS               |
-| ---------------- | ----------------- |
-| Debian Unstable  | `Debian_Unstable` |
-| Debian Testing   | `Debian_Testing`  |
-
-<br />
-Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
-You can pin your installation to a specific release.
-To install version 1.18.3, set `VERSION=1.18:1.18.3`.
-<br />
-
-Then run
-```shell
-echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
-
-curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
-curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
-
-apt-get update
-apt-get install cri-o cri-o-runc
-```
-
-{{% /tab %}}
-
-{{% tab name="Ubuntu" %}}
-
-To install on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
-
-| Operating system | $OS               |
-| ---------------- | ----------------- |
-| Ubuntu 20.04     | `xUbuntu_20.04`   |
-| Ubuntu 19.10     | `xUbuntu_19.10`   |
-| Ubuntu 19.04     | `xUbuntu_19.04`   |
-| Ubuntu 18.04     | `xUbuntu_18.04`   |
-
-<br />
-Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
-You can pin your installation to a specific release.
-To install version 1.18.3, set `VERSION=1.18:1.18.3`.
-<br />
-
-Then run
-```shell
-echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
-
-curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
-curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
-
-apt-get update
-apt-get install cri-o cri-o-runc
-```
-{{% /tab %}}
-
-{{% tab name="CentOS" %}}
-
-To install on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
-
-| Operating system | $OS               |
-| ---------------- | ----------------- |
-| Centos 8         | `CentOS_8`        |
-| Centos 8 Stream  | `CentOS_8_Stream` |
-| Centos 7         | `CentOS_7`        |
-
-<br />
-Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
-You can pin your installation to a specific release.
-To install version 1.18.3, set `VERSION=1.18:1.18.3`.
-<br />
-
-Then run
-```shell
-curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
-curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
-yum install cri-o
-```
-
-{{% /tab %}}
-
-{{% tab name="openSUSE Tumbleweed" %}}
-
-```shell
-sudo zypper install cri-o
-```
-{{% /tab %}}
-{{% tab name="Fedora" %}}
-
-Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.18, `VERSION=1.18`                                                                                                                                                                               
-You can find available versions with:
-```shell
-dnf module list cri-o
-```
-CRI-O does not support pinning to specific releases on Fedora.
-
-Then run
-```shell
-dnf module enable cri-o:$VERSION
-dnf install cri-o
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Start CRI-O
-
-```shell
-systemctl daemon-reload
-systemctl start crio
-```
-
-Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started)
-for more information.
-
-## Containerd
+### containerd
 
 This section contains the necessary steps to use `containerd` as CRI runtime.
 
 Use the following commands to install Containerd on your system:
 
-### Prerequisites
+Install and configure prerequisites:
 
 ```shell
-cat > /etc/modules-load.d/containerd.conf <<EOF
+cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
 overlay
 br_netfilter
 EOF
 
-modprobe overlay
-modprobe br_netfilter
+sudo modprobe overlay
+sudo modprobe br_netfilter
 
 # Setup required sysctl params, these persist across reboots.
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
 net.bridge.bridge-nf-call-iptables  = 1
 net.ipv4.ip_forward                 = 1
 net.bridge.bridge-nf-call-ip6tables = 1
 EOF
 
-sysctl --system
+# Apply sysctl params without reboot
+sudo sysctl --system
 ```
 
-### Install containerd
+Install containerd:
 
 {{< tabs name="tab-cri-containerd-installation" >}}
 {{% tab name="Ubuntu 16.04" %}}
@@ -377,17 +98,17 @@ sysctl --system
 # (Install containerd)
 ## Set up the repository
 ### Install packages to allow apt to use a repository over HTTPS
-apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
 ```
 
 ```shell
 ## Add Docker's official GPG key
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
 ```
 
 ```shell
 ## Add Docker apt repository.
-add-apt-repository \
+sudo add-apt-repository \
     "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
     $(lsb_release -cs) \
     stable"
@@ -395,18 +116,18 @@ add-apt-repository \
 
 ```shell
 ## Install containerd
-apt-get update && apt-get install -y containerd.io
+sudo apt-get update && sudo apt-get install -y containerd.io
 ```
 
 ```shell
 # Configure containerd
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
 ```
 
 ```shell
 # Restart containerd
-systemctl restart containerd
+sudo systemctl restart containerd
 ```
 {{% /tab %}}
 {{% tab name="CentOS/RHEL 7.4+" %}}
@@ -415,30 +136,30 @@ systemctl restart containerd
 # (Install containerd)
 ## Set up the repository
 ### Install required packages
-yum install -y yum-utils device-mapper-persistent-data lvm2
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
 ```
 
 ```shell
 ## Add docker repository
-yum-config-manager \
+sudo yum-config-manager \
     --add-repo \
     https://download.docker.com/linux/centos/docker-ce.repo
 ```
 
 ```shell
 ## Install containerd
-yum update -y && yum install -y containerd.io
+sudo yum update -y && sudo yum install -y containerd.io
 ```
 
 ```shell
 ## Configure containerd
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
 ```
 
 ```shell
 # Restart containerd
-systemctl restart containerd
+sudo systemctl restart containerd
 ```
 {{% /tab %}}
 {{% tab name="Windows (PowerShell)" %}}
@@ -469,14 +190,312 @@ Start-Service containerd
 {{% /tab %}}
 {{< /tabs >}}
 
-### systemd
+#### systemd {#containerd-systemd}
+
+To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
+
+```
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
+  ...
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
+    SystemdCgroup = true
+```
 
-To use the `systemd` cgroup driver, set `plugins.cri.systemd_cgroup = true` in `/etc/containerd/config.toml`.
 When using kubeadm, manually configure the
-[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)
+[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
 
-## Other CRI runtimes: frakti
+### CRI-O
 
-Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information.
+This section contains the necessary steps to install CRI-O as a container runtime.
+
+Use the following commands to install CRI-O on your system:
+
+{{< note >}}
+The CRI-O major and minor versions must match the Kubernetes major and minor versions.
+For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o).
+{{< /note >}}
+
+Install and configure prerequisites:
+
+```shell
+sudo modprobe overlay
+sudo modprobe br_netfilter
+
+# Set up required sysctl params, these persist across reboots.
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
+net.bridge.bridge-nf-call-iptables  = 1
+net.ipv4.ip_forward                 = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+EOF
+
+sudo sysctl --system
+```
+
+{{< tabs name="tab-cri-cri-o-installation" >}}
+{{% tab name="Debian" %}}
+
+To install CRI-O on the following operating systems, set the environment variable `OS`
+to the appropriate value from the following table:
+
+| Operating system | `$OS`             |
+| ---------------- | ----------------- |
+| Debian Unstable  | `Debian_Unstable` |
+| Debian Testing   | `Debian_Testing`  |
+
+<br />
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+<br />
+
+Then run
+```shell
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
+EOF
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
+EOF
+
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
+
+sudo apt-get update
+sudo apt-get install cri-o cri-o-runc
+```
+
+{{% /tab %}}
+
+{{% tab name="Ubuntu" %}}
+
+To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table:
+
+| Operating system | `$OS`             |
+| ---------------- | ----------------- |
+| Ubuntu 20.04     | `xUbuntu_20.04`   |
+| Ubuntu 19.10     | `xUbuntu_19.10`   |
+| Ubuntu 19.04     | `xUbuntu_19.04`   |
+| Ubuntu 18.04     | `xUbuntu_18.04`   |
+
+<br />
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+<br />
+
+Then run
+```shell
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
+EOF
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
+EOF
+
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
+
+sudo apt-get update
+sudo apt-get install cri-o cri-o-runc
+```
+{{% /tab %}}
+
+{{% tab name="CentOS" %}}
+
+To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table:
+
+| Operating system | `$OS`             |
+| ---------------- | ----------------- |
+| Centos 8         | `CentOS_8`        |
+| Centos 8 Stream  | `CentOS_8_Stream` |
+| Centos 7         | `CentOS_7`        |
+
+<br />
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+<br />
+
+Then run
+```shell
+sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
+sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
+sudo yum install cri-o
+```
+
+{{% /tab %}}
+
+{{% tab name="openSUSE Tumbleweed" %}}
+
+```shell
+sudo zypper install cri-o
+```
+{{% /tab %}}
+{{% tab name="Fedora" %}}
+
+Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, `VERSION=1.18`.
+
+You can find available versions with:
+```shell
+sudo dnf module list cri-o
+```
+CRI-O does not support pinning to specific releases on Fedora.
+
+Then run
+```shell
+sudo dnf module enable cri-o:$VERSION
+sudo dnf install cri-o
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+Start CRI-O:
+
+```shell
+sudo systemctl daemon-reload
+sudo systemctl start crio
+```
+
+Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started)
+for more information.
 
 
+
+### Docker
+
+On each of your nodes, install Docker CE.
+
+The Kubernetes release notes list which versions of Docker are compatible
+with that version of Kubernetes.
+
+Use the following commands to install Docker on your system:
+
+{{< tabs name="tab-cri-docker-installation" >}}
+{{% tab name="Ubuntu 16.04+" %}}
+
+```shell
+# (Install Docker CE)
+## Set up the repository:
+### Install packages to allow apt to use a repository over HTTPS
+sudo apt-get update && sudo apt-get install -y \
+  apt-transport-https ca-certificates curl software-properties-common gnupg2
+```
+
+```shell
+# Add Docker's official GPG key:
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
+```
+
+```shell
+# Add the Docker apt repository:
+sudo add-apt-repository \
+  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+  $(lsb_release -cs) \
+  stable"
+```
+
+```shell
+# Install Docker CE
+sudo apt-get update && sudo apt-get install -y \
+  containerd.io=1.2.13-2 \
+  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+```
+
+```shell
+# Set up the Docker daemon
+cat <<EOF | sudo tee /etc/docker/daemon.json
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2"
+}
+EOF
+```
+
+```shell
+# Create /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
+```
+
+```shell
+# Restart Docker
+sudo systemctl daemon-reload
+sudo systemctl restart docker
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
+
+```shell
+# (Install Docker CE)
+## Set up the repository
+### Install required packages
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
+```
+
+```shell
+## Add the Docker repository
+sudo yum-config-manager --add-repo \
+  https://download.docker.com/linux/centos/docker-ce.repo
+```
+
+```shell
+# Install Docker CE
+sudo yum update -y && sudo yum install -y \
+  containerd.io-1.2.13 \
+  docker-ce-19.03.11 \
+  docker-ce-cli-19.03.11
+```
+
+```shell
+## Create /etc/docker
+sudo mkdir /etc/docker
+```
+
+```shell
+# Set up the Docker daemon
+cat <<EOF | sudo tee /etc/docker/daemon.json
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2",
+  "storage-opts": [
+    "overlay2.override_kernel_check=true"
+  ]
+}
+EOF
+```
+
+```shell
+# Create /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
+```
+
+```shell
+# Restart Docker
+sudo systemctl daemon-reload
+sudo systemctl restart docker
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+If you want the `docker` service to start on boot, run the following command:
+
+```shell
+sudo systemctl enable docker
+```
+
+Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
+for more information.
+
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/_index.md b/content/en/docs/setup/production-environment/on-premises-vm/_index.md
deleted file mode 100644
index 42c4ec3899..0000000000
--- a/content/en/docs/setup/production-environment/on-premises-vm/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: On-Premises VMs
-weight: 40
----
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
deleted file mode 100644
index c440f14b31..0000000000
--- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-reviewers:
-- thockin
-title: Cloudstack
-content_type: concept
----
-
-<!-- overview -->
-
-[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
-
-[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
-
-This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
-
-<!-- body -->
-
-## Prerequisites
-
-```shell
-sudo apt-get install -y python-pip libssl-dev
-sudo pip install cs
-sudo pip install sshpubkeys
-sudo apt-get install software-properties-common
-sudo apt-add-repository ppa:ansible/ansible
-sudo apt-get update
-sudo apt-get install ansible
-```
-
-On CloudStack server you also have to install libselinux-python :
-
-```shell
-yum install libselinux-python
-```
-
-[_cs_](https://github.com/exoscale/cs) is a python module for the CloudStack API.
-
-Set your CloudStack endpoint, API keys and HTTP method used.
-
-You can define them as environment variables: `CLOUDSTACK_ENDPOINT`, `CLOUDSTACK_KEY`, `CLOUDSTACK_SECRET` and `CLOUDSTACK_METHOD`.
-
-Or create a `~/.cloudstack.ini` file:
-
-```none
-[cloudstack]
-endpoint = <your cloudstack api endpoint>
-key = <your api access key>
-secret = <your api secret key>
-method = post
-```
-
-We need to use the http POST method to pass the _large_ userdata to the coreOS instances.
-
-### Clone the playbook
-
-```shell
-git clone https://github.com/apachecloudstack/k8s
-cd kubernetes-cloudstack
-```
-
-### Create a Kubernetes cluster
-
-You simply need to run the playbook.
-
-```shell
-ansible-playbook k8s.yml
-```
-
-Some variables can be edited in the `k8s.yml` file.
-
-```none
-vars:
-  ssh_key: k8s
-  k8s_num_nodes: 2
-  k8s_security_group_name: k8s
-  k8s_node_prefix: k8s2
-  k8s_template: <templatename>
-  k8s_instance_type: <serviceofferingname>
-```
-
-This will start a Kubernetes master node and a number of compute nodes (by default 2).
-The `instance_type` and `template` are specific, edit them to specify your CloudStack cloud specific template and instance type (i.e. service offering).
-
-Check the tasks and templates in `roles/k8s` if you want to modify anything.
-
-Once the playbook as finished, it will print out the IP of the Kubernetes master:
-
-```none
-TASK: [k8s | debug msg='k8s master IP is {{ k8s_master.default_ip }}'] ********
-```
-
-SSH to it using the key that was created and using the _core_ user.
-
-```shell
-ssh -i ~/.ssh/id_rsa_k8s core@<master IP>
-```
-
-And you can list the machines in your cluster:
-
-```shell
-fleetctl list-machines
-```
-
-```none
-MACHINE        IP             METADATA
-a017c422...    <node #1 IP>   role=node
-ad13bf84...    <master IP>    role=master
-e9af8293...    <node #2 IP>   role=node
-```
-
-## Support Level
-
-IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
--------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
-CloudStack           | Ansible      | CoreOS | flannel     | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/)                             |          | Community ([@Guiques](https://github.com/ltupin/))
-
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/dcos.md b/content/en/docs/setup/production-environment/on-premises-vm/dcos.md
deleted file mode 100644
index e4b310902c..0000000000
--- a/content/en/docs/setup/production-environment/on-premises-vm/dcos.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-reviewers:
-- smugcloud
-title: Kubernetes on DC/OS
-content_type: concept
----
-
-<!-- overview -->
-
-Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https://mesosphere.com/product/), offering:
-
-* Pure upstream Kubernetes
-* Single-click cluster provisioning
-* Highly available and secure by default
-* Kubernetes running alongside fast-data platforms (e.g. Akka, Cassandra, Kafka, Spark)
-
-
-
-<!-- body -->
-
-## Official Mesosphere Guide
-
-The canonical source of getting started on DC/OS is located in the [quickstart repo](https://github.com/mesosphere/dcos-kubernetes-quickstart).
-
-
diff --git a/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md b/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md
deleted file mode 100644
index 1d57b6f7eb..0000000000
--- a/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-reviewers:
-- caesarxuchao
-- erictune
-title: oVirt
-content_type: concept
----
-
-<!-- overview -->
-
-oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
-
-
-
-<!-- body -->
-
-## oVirt Cloud Provider Deployment
-
-The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your Kubernetes cluster.
-At the moment there are no community-supported or pre-loaded VM images including Kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes Kubernetes may work as well.
-
-It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to Kubernetes.
-
-Once the Kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider.
-
-[import]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
-[install]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
-[generate a template]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
-[install the ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
-
-## Using the oVirt Cloud Provider
-
-The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file:
-
-```none
-[connection]
-uri = https://localhost:8443/ovirt-engine/api
-username = admin@internal
-password = admin
-```
-
-In the same file it is possible to specify (using the `filters` section) what search query to use to identify the VMs to be reported to Kubernetes:
-
-```none
-[filters]
-# Search query used to find nodes
-vms = tag=kubernetes
-```
-
-In the above example all the VMs tagged with the `kubernetes` label will be reported as nodes to Kubernetes.
-
-The `ovirt-cloud.conf` file then must be specified in kube-controller-manager:
-
-```shell
-kube-controller-manager ... --cloud-provider=ovirt --cloud-config=/path/to/ovirt-cloud.conf ...
-```
-
-## oVirt Cloud Provider Screencast
-
-This short screencast demonstrates how the oVirt Cloud Provider can be used to dynamically add VMs to your Kubernetes cluster.
-
-[![Screencast](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](https://www.youtube.com/watch?v=JyyST4ZKne8)
-
-## Support Level
-
-
-IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
--------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
-oVirt                |              |        |             | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/)                                  |          | Community ([@simon3z](https://github.com/simon3z))
-
-
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index f82e4637c2..daf4aaec1a 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -139,7 +139,7 @@ is not supported by kubeadm.
 
 For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
 
-For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
+To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
 
 To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
 
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index e91e9f7a60..b8c3236b73 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -36,7 +36,7 @@ LoadBalancer, or with dynamic PersistentVolumes.
 For both methods you need this infrastructure:
 
 - Three machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for
-  the masters
+  the control-plane nodes
 - Three machines that meet [kubeadm's minimum
   requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers
 - Full network connectivity between all machines in the cluster (public or
@@ -224,7 +224,7 @@ in the kubeadm config file.
     scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
     ```
 
-    - Replace the value of `CONTROL_PLANE` with the `user@host` of the first control plane machine.
+    - Replace the value of `CONTROL_PLANE` with the `user@host` of the first control-plane node.
 
 ### Set up the first control plane node
 
@@ -372,4 +372,3 @@ SSH is required if you want to control all nodes from a single machine.
     # Quote this line if you are using external etcd
     mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
     ```
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index 42ab59f4db..92a73bf4a1 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -25,7 +25,7 @@ For information how to create a cluster with kubeadm once you have performed thi
   - Red Hat Enterprise Linux (RHEL) 7
   - Fedora 25+
   - HypriotOS v1.0.1+
-  - Container Linux (tested with 1800.6.0)
+  - Flatcar Container Linux (tested with 2512.3.0)
 * 2 GB or more of RAM per machine (any less will leave little room for your apps)
 * 2 CPUs or more
 * Full network connectivity between all machines in the cluster (public or private network is fine)
@@ -220,7 +220,7 @@ sudo systemctl enable --now kubelet
   - You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
 
 {{% /tab %}}
-{{% tab name="Fedora CoreOS" %}}
+{{% tab name="Fedora CoreOS or Flatcar Container Linux" %}}
 Install CNI plugins (required for most pod network):
 
 ```bash
@@ -231,6 +231,11 @@ curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_
 
 Define the directory to download command files  
 
+{{< note >}}
+The DOWNLOAD_DIR variable must be set to a writable directory.
+If you are running Flatcar Container Linux, set DOWNLOAD_DIR=/opt/bin.
+{{< /note >}}
+
 ```bash
 DOWNLOAD_DIR=/usr/local/bin
 sudo mkdir -p $DOWNLOAD_DIR
@@ -251,7 +256,7 @@ cd $DOWNLOAD_DIR
 sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
 sudo chmod +x {kubeadm,kubelet,kubectl}
 
-RELEASE_VERSION="v0.2.7"
+RELEASE_VERSION="v0.4.0"
 curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
 sudo mkdir -p /etc/systemd/system/kubelet.service.d
 curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
@@ -262,6 +267,12 @@ Enable and start `kubelet`:
 ```bash
 systemctl enable --now kubelet
 ```
+
+{{< note >}}
+The Flatcar Container Linux distribution mounts the `/usr` directory as a read-only filesystem.
+Before bootstrapping your cluster, you need to take additional steps to configure a writable directory.
+See the [Kubeadm Troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only/) to learn how to set up a writable directory.
+{{< /note >}}
 {{% /tab %}}
 {{< /tabs >}}
 
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index af4eb4a101..f68b026ccb 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -200,6 +200,6 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
 | `kubeadm`    | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
 | `kubelet`    | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
 | `kubectl`    | Installs the `/usr/bin/kubectl` binary. |
-| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
+| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-sigs/cri-tools). |
 
 
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index b707828cc9..6f62a051ad 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -51,6 +51,7 @@ this example.
 
 1. Configure the kubelet to be a service manager for etcd.
 
+   {{< note >}}You must do this on every host where etcd should be running.{{< /note >}}
     Since etcd was created first, you must override the service priority by creating a new unit file
     that has higher precedence than the kubeadm-provided kubelet unit file.
 
@@ -67,6 +68,12 @@ this example.
     systemctl restart kubelet
     ```
 
+    Check the kubelet status to ensure it is running.
+
+    ```sh
+    systemctl status kubelet
+    ```
+
 1. Create configuration files for kubeadm.
 
     Generate one kubeadm configuration file for each host that will have an etcd
@@ -270,4 +277,3 @@ Once you have a working 3 member etcd cluster, you can continue setting up a
 highly available control plane using the [external etcd method with
 kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/).
 
-
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index 82ceef4696..2e347b0ef6 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -407,4 +407,12 @@ be advised that this is modifying a design principle of the Linux distribution.
 
 This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`. 
 
-This issue is fixed as of version 1.19. 
\ No newline at end of file
+This issue is fixed as of version 1.19.
+
+## `kubeadm reset` unmounts `/var/lib/kubelet`
+
+If `/var/lib/kubelet` is being mounted, performing a `kubeadm reset` will effectively unmount it.
+
+To workaround the issue, re-mount the `/var/lib/kubelet` directory after performing the `kubeadm reset` operation.
+
+This is a regression introduced in kubeadm 1.15. The issue is fixed in 1.20.
diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md
index 02d99d926a..ac635101a0 100644
--- a/content/en/docs/setup/production-environment/tools/kubespray.md
+++ b/content/en/docs/setup/production-environment/tools/kubespray.md
@@ -13,12 +13,13 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
 * a highly available cluster
 * composable attributes
 * support for most popular Linux distributions
-  * Container Linux by CoreOS
+  * Ubuntu 16.04, 18.04, 20.04
+  * CentOS/RHEL/Oracle Linux 7, 8
   * Debian Buster, Jessie, Stretch, Wheezy
-  * Ubuntu 16.04, 18.04
-  * CentOS/RHEL/Oracle Linux 7
-  * Fedora 28
+  * Fedora 31, 32
+  * Fedora CoreOS
   * openSUSE Leap 15
+  * Flatcar Container Linux by Kinvolk
 * continuous integration tests
 
 To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
@@ -32,8 +33,8 @@ To choose a tool which best fits your use case, read [this comparison](https://g
 
 Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
 
-* **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands**
-* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
+* **Ansible v2.9 and python-netaddr is installed on the machine that will run Ansible commands**
+* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
 * The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
 * The target servers are configured to allow **IPv4 forwarding**
 * **Your ssh key must be copied** to all the servers part of your inventory
diff --git a/content/en/docs/setup/production-environment/turnkey-solutions.md b/content/en/docs/setup/production-environment/turnkey-solutions.md
new file mode 100644
index 0000000000..c62b41932a
--- /dev/null
+++ b/content/en/docs/setup/production-environment/turnkey-solutions.md
@@ -0,0 +1,14 @@
+---
+title: Turnkey Cloud Solutions
+content_type: concept
+weight: 30
+---
+<!-- overview -->
+
+This page provides a list of Kubernetes certified solution providers. From each
+provider page, you can learn how to install and setup production
+ready clusters.
+
+<!-- body -->
+
+{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}}
diff --git a/content/en/docs/setup/production-environment/turnkey/_index.md b/content/en/docs/setup/production-environment/turnkey/_index.md
deleted file mode 100644
index 1941966bb0..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Turnkey Cloud Solutions
-weight: 30
----
diff --git a/content/en/docs/setup/production-environment/turnkey/alibaba-cloud.md b/content/en/docs/setup/production-environment/turnkey/alibaba-cloud.md
deleted file mode 100644
index d83ecf18ac..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/alibaba-cloud.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-reviewers:
-- colemickens
-- brendandburns
-title: Running Kubernetes on Alibaba Cloud
----
-
-## Alibaba Cloud Container Service
-
-The [Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service) lets you run and manage Docker applications on a cluster of either Alibaba Cloud ECS instances or in a Serverless fashion. It supports the popular open source container orchestrators: Docker Swarm and Kubernetes.
-
-To simplify cluster deployment and management, use [Kubernetes Support for Alibaba Cloud Container Service](https://www.alibabacloud.com/product/kubernetes). You can get started quickly by following the [Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm), and there are some [tutorials for Kubernetes Support on Alibaba Cloud](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1) in Chinese.
-
-To use custom binaries or open source Kubernetes, follow the instructions below.
-
-## Custom Deployments
-
-The source code for [Kubernetes with Alibaba Cloud provider implementation](https://github.com/AliyunContainerService/kubernetes) is open source and available on GitHub.
-
-For more information, see "[Quick deployment of Kubernetes - VPC environment on Alibaba Cloud](https://www.alibabacloud.com/forum/read-830)" in English.
diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md
deleted file mode 100644
index be75623158..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/aws.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-reviewers:
-- justinsb
-- clove
-title: Running Kubernetes on AWS EC2
-content_type: task
----
-
-<!-- overview -->
-
-This page describes how to install a Kubernetes cluster on AWS.
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
-
-### Supported Production Grade Tools
-
-* [conjure-up](https://docs.conjure-up.io/stable/en/cni/k8s-and-aws) is an open-source installer for Kubernetes that creates Kubernetes clusters with native AWS integrations on Ubuntu.
-
-* [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS.
-
-* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
-
-* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
-
-
-
-<!-- steps -->
-
-## Getting started with your cluster
-
-### Command line administration tool: kubectl
-
-The cluster startup script will leave you with a `kubernetes` directory on your workstation.
-Alternately, you can download the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases).
-
-Next, add the appropriate binary folder to your `PATH` to access kubectl:
-
-```shell
-# macOS
-export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
-
-# Linux
-export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
-```
-
-An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/)
-
-By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
-For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
-
-### Examples
-
-See [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
-
-The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
-
-For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)
-
-## Scaling the cluster
-
-Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the
-[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
-
-## Tearing down the cluster
-
-Make sure the environment variables you used to provision your cluster are still exported, then call the following script inside the
-`kubernetes` directory:
-
-```shell
-cluster/kube-down.sh
-```
-
-## Support Level
-
-
-IaaS Provider        | Config. Mgmt | OS            | Networking  | Docs                                          | Conforms | Support Level
--------------------- | ------------ | ------------- | ----------  | --------------------------------------------- | ---------| ----------------------------
-AWS                  | kops         | Debian        | k8s (VPC)   | [docs](https://github.com/kubernetes/kops)    |          | Community ([@justinsb](https://github.com/justinsb))
-AWS                  | CoreOS       | CoreOS        | flannel     | -  |          | Community
-AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | - | 100%     | Commercial, Community
-AWS                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community
-
-
diff --git a/content/en/docs/setup/production-environment/turnkey/azure.md b/content/en/docs/setup/production-environment/turnkey/azure.md
deleted file mode 100644
index eccbbca75b..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/azure.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-reviewers:
-- colemickens
-- brendandburns
-title: Running Kubernetes on Azure
----
-
-## Azure Kubernetes Service (AKS)
-
-The [Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/) offers simple
-deployments for Kubernetes clusters.
-
-For an example of deploying a Kubernetes cluster onto Azure via the Azure Kubernetes Service:
-
-**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)**
-
-## Custom Deployments: AKS-Engine
-
-The core of the Azure Kubernetes Service is **open source** and available on GitHub for the community
-to use and contribute to: **[AKS-Engine](https://github.com/Azure/aks-engine)**. The legacy [ACS-Engine](https://github.com/Azure/acs-engine) codebase has been deprecated in favor of AKS-engine.
-
-AKS-Engine is a good choice if you need to make customizations to the deployment beyond what the Azure Kubernetes
-Service officially supports. These customizations include deploying into existing virtual networks, utilizing multiple
-agent pools, and more. Some community contributions to AKS-Engine may even become features of the Azure Kubernetes Service.
-
-The input to AKS-Engine is an apimodel JSON file describing the Kubernetes cluster. It is similar to the Azure Resource Manager (ARM) template syntax used to deploy a cluster directly with the Azure Kubernetes Service. The resulting output is an ARM template that can be checked into source control and used to deploy Kubernetes clusters to Azure.
-
-You can get started by following the **[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**.
-
-## CoreOS Tectonic for Azure
-
-The CoreOS Tectonic Installer for Azure is **open source** and available on GitHub for the community to use and contribute to: **[Tectonic Installer](https://github.com/coreos/tectonic-installer)**.
-
-Tectonic Installer is a good choice when you need to make cluster customizations as it is built on [Hashicorp's Terraform](https://www.terraform.io/docs/providers/azurerm/) Azure Resource Manager (ARM) provider. This enables users to customize or integrate using familiar Terraform tooling.
-
-You can get started using the [Tectonic Installer for Azure Guide](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html).
diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md
deleted file mode 100644
index 78386161a6..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/gce.md
+++ /dev/null
@@ -1,223 +0,0 @@
----
-reviewers:
-- brendandburns
-- jbeda
-- mikedanese
-- thockin
-title: Running Kubernetes on Google Compute Engine
-content_type: task
----
-
-<!-- overview -->
-
-The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
-
-For an easy way to experiment with the Kubernetes development environment, click the button below
-to open a Google Cloud Shell with an auto-cloned copy of the Kubernetes source repo.
-
-[![Open in Cloud Shell](https://gstatic.com/cloudssh/images/open-btn.png)](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md)
-
-If you want to use custom binaries or pure open source Kubernetes, please continue with the instructions below.
-
-### Prerequisites
-
-1. You need a Google Cloud Platform account with billing enabled. Visit the [Google Developers Console](https://console.cloud.google.com) for more details.
-1. Install `gcloud` as necessary. `gcloud` can be installed as a part of the [Google Cloud SDK](https://cloud.google.com/sdk/).
-1. Enable the [Compute Engine Instance Group Manager API](https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview) in the [Google Cloud developers console](https://console.developers.google.com/apis/library).
-1. Make sure that gcloud is set to use the Google Cloud Platform project you want. You can check the current project using `gcloud config list project` and change it via `gcloud config set project <project-id>`.
-1. Make sure you have credentials for GCloud by running `gcloud auth login`.
-1. (Optional)  In order to make API calls against GCE, you must also run `gcloud auth application-default login`.
-1. Make sure you can start up a GCE VM from the command line.  At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
-1. Make sure you can SSH into the VM without interactive prompts.  See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
-
-
-
-<!-- steps -->
-
-## Starting a cluster
-
-You can install a client and start a cluster with either one of these commands (we list both in case only one is installed on your machine):
-
-
-```shell
-curl -sS https://get.k8s.io | bash
-```
-
-or
-
-```shell
-wget -q -O - https://get.k8s.io | bash
-```
-
-Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.
-
-By default, some containers will already be running on your cluster. Containers like `fluentd` provide [logging](/docs/concepts/cluster-administration/logging/), while `heapster` provides [monitoring](https://releases.k8s.io/master/cluster/addons/cluster-monitoring/README.md) services.
-
-The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once.
-
-Alternately, you can download and install the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases), then run the `<kubernetes>/cluster/kube-up.sh` script to start the cluster:
-
-```shell
-cd kubernetes
-cluster/kube-up.sh
-```
-
-If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
-
-If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.
-
-The next few steps will show you:
-
-1. How to set up the command line client on your workstation to manage the cluster
-1. Examples of how to use the cluster
-1. How to delete the cluster
-1. How to start clusters with non-default options (like larger clusters)
-
-## Installing the Kubernetes command line tools on your workstation
-
-The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
-
-The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
-manager.  It lets you inspect your cluster resources, create, delete, and update
-components, and much more. You will use it to look at your new cluster and bring
-up example apps.
-
-You can use `gcloud` to install the `kubectl` command-line tool on your workstation:
-
-```shell
-gcloud components install kubectl
-```
-
-{{< note >}}
-The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/)
-document to see how you can set up the latest `kubectl` on your workstation.
-{{< /note >}}
-
-## Getting started with your cluster
-
-### Inspect your cluster
-
-Once `kubectl` is in your path, you can use it to look at your cluster. E.g., running:
-
-```shell
-kubectl get --all-namespaces services
-```
-
-should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:
-
-```shell
-NAMESPACE     NAME          TYPE             CLUSTER_IP       EXTERNAL_IP       PORT(S)        AGE
-default       kubernetes    ClusterIP        10.0.0.1         <none>            443/TCP        1d
-kube-system   kube-dns      ClusterIP        10.0.0.2         <none>            53/TCP,53/UDP  1d
-kube-system   kube-ui       ClusterIP        10.0.0.3         <none>            80/TCP         1d
-...
-```
-
-Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/) that were created during cluster startup.
-You can do this via the
-
-```shell
-kubectl get --all-namespaces pods
-```
-
-command.
-
-You'll see a list of pods that looks something like this (the name specifics will be different):
-
-```shell
-NAMESPACE     NAME                                           READY     STATUS    RESTARTS   AGE
-kube-system   coredns-5f4fbb68df-mc8z8                       1/1       Running   0          15m
-kube-system   fluentd-cloud-logging-kubernetes-minion-63uo   1/1       Running   0          14m
-kube-system   fluentd-cloud-logging-kubernetes-minion-c1n9   1/1       Running   0          14m
-kube-system   fluentd-cloud-logging-kubernetes-minion-c4og   1/1       Running   0          14m
-kube-system   fluentd-cloud-logging-kubernetes-minion-ngua   1/1       Running   0          14m
-kube-system   kube-ui-v1-curt1                               1/1       Running   0          15m
-kube-system   monitoring-heapster-v5-ex4u3                   1/1       Running   1          15m
-kube-system   monitoring-influx-grafana-v1-piled             2/2       Running   0          15m
-```
-
-Some of the pods may take a few seconds to start up (during this time they'll show `Pending`), but check that they all show as `Running` after a short period.
-
-### Run some examples
-
-Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
-
-For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/).  The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
-
-## Tearing down the cluster
-
-To remove/delete/teardown the cluster, use the `kube-down.sh` script.
-
-```shell
-cd kubernetes
-cluster/kube-down.sh
-```
-
-Likewise, the `kube-up.sh` in the same directory will bring it back up. You do not need to rerun the `curl` or `wget` command: everything needed to setup the Kubernetes cluster is now on your workstation.
-
-## Customizing
-
-The script above relies on Google Storage to stage the Kubernetes release. It
-then will start (by default) a single master VM along with 3 worker VMs.  You
-can tweak some of these parameters by editing `kubernetes/cluster/gce/config-default.sh`
-You can view a transcript of a successful cluster creation
-[here](https://gist.github.com/satnam6502/fc689d1b46db9772adea).
-
-## Troubleshooting
-
-### Project settings
-
-You need to have the Google Cloud Storage API, and the Google Cloud Storage
-JSON API enabled. It is activated by default for new projects. Otherwise, it
-can be done in the Google Cloud Console.  See the [Google Cloud Storage JSON
-API Overview](https://cloud.google.com/storage/docs/json_api/) for more
-details.
-
-Also ensure that-- as listed in the [Prerequisites section](#prerequisites)-- you've enabled the `Compute Engine Instance Group Manager API`, and can start up a GCE VM from the command line as in the [GCE Quickstart](https://cloud.google.com/compute/docs/quickstart) instructions.
-
-### Cluster initialization hang
-
-If the Kubernetes startup script hangs waiting for the API to be reachable, you can troubleshoot by SSHing into the master and node VMs and looking at logs such as `/var/log/startupscript.log`.
-
-**Once you fix the issue, you should run `kube-down.sh` to cleanup** after the partial cluster creation, before running `kube-up.sh` to try again.
-
-### SSH
-
-If you're having trouble SSHing into your instances, ensure the GCE firewall
-isn't blocking port 22 to your VMs.  By default, this should work but if you
-have edited firewall rules or created a new non-default network, you'll need to
-expose it: `gcloud compute firewall-rules create default-ssh --network=<network-name>
---description "SSH allowed from anywhere" --allow tcp:22`
-
-Additionally, your GCE SSH key must either have no passcode or you need to be
-using `ssh-agent`.
-
-### Networking
-
-The instances must be able to connect to each other using their private IP. The
-script uses the "default" network which should have a firewall rule called
-"default-allow-internal" which allows traffic on any port on the private IPs.
-If this rule is missing from the default network or if you change the network
-being used in `cluster/config-default.sh` create a new rule with the following
-field values:
-
-* Source Ranges: `10.0.0.0/8`
-* Allowed Protocols and Port: `tcp:1-65535;udp:1-65535;icmp`
-
-## Support Level
-
-
-IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
--------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
-GCE                  | Saltstack    | Debian | GCE         | [docs](/docs/setup/production-environment/turnkey/gce/)                                    |   | Project
-
-
diff --git a/content/en/docs/setup/production-environment/turnkey/icp.md b/content/en/docs/setup/production-environment/turnkey/icp.md
deleted file mode 100644
index 1ebb7a9267..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/icp.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-reviewers:
-- bradtopol
-title: Running Kubernetes on Multiple Clouds with IBM Cloud Private
----
-
-IBM® Cloud Private is a turnkey cloud solution and an on-premises turnkey cloud solution. IBM Cloud Private delivers pure upstream Kubernetes with the typical management components that are required to run real enterprise workloads. These workloads include health management, log management, audit trails, and metering for tracking usage of workloads on the platform.
-
-IBM Cloud Private is available in a community edition and a fully supported enterprise edition. The community edition is available at no charge from [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/). The enterprise edition supports high availability topologies and includes commercial support from IBM for Kubernetes and the IBM Cloud Private management platform. If you want to try IBM Cloud Private, you can use either the hosted trial, the tutorial, or the self-guided demo. You can also try the free community edition. For details, see [Get started with IBM Cloud Private](https://www.ibm.com/cloud/private/get-started).
-
-For more information, explore the following resources:
-
-* [IBM Cloud Private](https://www.ibm.com/cloud/private)
-* [Reference architecture for IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
-* [IBM Cloud Private documentation](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
-
-## IBM Cloud Private and Terraform
-
-The following modules are available where you can deploy IBM Cloud Private by using Terraform:
-
-* AWS: [Deploy IBM Cloud Private to AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
-* Azure: [Deploy IBM Cloud Private to Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
-* IBM Cloud: [Deploy IBM Cloud Private cluster to IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
-* OpenStack: [Deploy IBM Cloud Private to OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
-* Terraform module: [Deploy IBM Cloud Private on any supported infrastructure vendor](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
-* VMware: [Deploy IBM Cloud Private to VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
-
-## IBM Cloud Private on AWS
-
-You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform.
-
-IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws).
-
-## IBM Cloud Private on Azure
-
-You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html).
-
-## IBM Cloud Private with Red Hat OpenShift
-
-You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.
-
-Integration capabilities:
-
-* Supports Linux® 64-bit platform in offline-only installation mode
-* Single-master configuration
-* Integrated IBM Cloud Private cluster management console and catalog
-* Integrated core platform services, such as monitoring, metering, and logging
-* IBM Cloud Private uses the OpenShift image registry
-
-For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html).
-
-## IBM Cloud Private on VirtualBox
-
-To install IBM Cloud Private to a VirtualBox environment, see [Installing IBM Cloud Private on VirtualBox](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox).
-
-## IBM Cloud Private on VMware
-
-You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. For details, see the following projects:
-
-* [Installing IBM Cloud Private with Ubuntu](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
-* [Installing IBM Cloud Private with Red Hat Enterprise](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
-
-The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.
-
-For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview).
diff --git a/content/en/docs/setup/production-environment/turnkey/tencent.md b/content/en/docs/setup/production-environment/turnkey/tencent.md
deleted file mode 100644
index fadef5d3dd..0000000000
--- a/content/en/docs/setup/production-environment/turnkey/tencent.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Running Kubernetes on Tencent Kubernetes Engine
----
-
-## Tencent Kubernetes Engine
-
- [Tencent Cloud Tencent Kubernetes Engine (TKE)](https://intl.cloud.tencent.com/product/tke) provides native Kubernetes container management services. You can deploy and manage a Kubernetes cluster with TKE in just a few steps. For detailed directions, see [Deploy Tencent Kubernetes Engine](https://intl.cloud.tencent.com/document/product/457/11741).
-
- TKE is a [Certified Kubernetes product](https://www.cncf.io/certification/software-conformance/).It is fully compatible with the native Kubernetes API.
-
-## Custom Deployment
-
- The core of Tencent Kubernetes Engine is open source and available [on GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/).
-
- When using TKE to create a Kubernetes cluster, you can choose managed mode or independent deployment mode. In addition, you can customize the deployment as needed; for example, you can choose an existing Cloud Virtual Machine instance for cluster creation or enable Kube-proxy in IPVS mode.
-
-## What's Next
-
- To learn more, see the [TKE documentation](https://intl.cloud.tencent.com/document/product/457).
\ No newline at end of file
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index 812d86faf7..07d5bfb6bd 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -125,7 +125,7 @@ There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa
 
 {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0-beta.2+ can also be used as the container runtime for Windows Kubernetes nodes.
 
-Initial support for ContainerD on Windows was added in Kubernetes v1.18. Progress for ContainerD on Windows can be tracked at [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001). 
+Initial support for ContainerD on Windows was added in Kubernetes v1.18. Progress for ContainerD on Windows can be tracked at [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001).
 
 Learn how to [install ContainerD on a Windows](/docs/setup/production-environment/container-runtimes/#install-containerd).
 
@@ -573,7 +573,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
     Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
     ```
 
-    Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
+    Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
 
 1. My Pods are stuck at "Container Creating" or restarting over and over
 
@@ -603,7 +603,7 @@ Your main source of help for troubleshooting your Kubernetes cluster should star
 
     In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accommodate worker containers crashing or restarting without losing any of the networking configuration.
 
-    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat).
+    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile).
 
 ### Further investigation
 
diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md
index 8bc87867bc..45791de15b 100644
--- a/content/en/docs/setup/release/notes.md
+++ b/content/en/docs/setup/release/notes.md
@@ -1,5 +1,5 @@
 ---
-title: v1.18 Release Notes
+title: v1.19 Release Notes
 weight: 10
 card:
   name: release-notes
@@ -13,788 +13,2403 @@ card:
 
 <!-- NEW RELEASE NOTES ENTRY -->
 
-# v1.18.0
+# v1.19.0
 
 [Documentation](https://docs.k8s.io)
 
-## Downloads for v1.18.0
+## Downloads for v1.19.0
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes.tar.gz) | `cd5b86a3947a4f2cea6d857743ab2009be127d782b6f2eb4d37d88918a5e433ad2c7ba34221c34089ba5ba13701f58b657f0711401e51c86f4007cb78744dee7`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-src.tar.gz) | `fb42cf133355ef18f67c8c4bb555aa1f284906c06e21fa41646e086d34ece774e9d547773f201799c0c703ce48d4d0e62c6ba5b2a4d081e12a339a423e111e52`
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes.tar.gz) | `448b941e973a519a500eb24786f6deb7eebd0e1ecb034941e382790ff69dfc2838715a222cfc53bea7b75f2c6aedc7425eded4aad69bf88773393155c737f9c0`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-src.tar.gz) | `47d253e6eb1f6da730f4f3885e205e6bfde88ffe66d92915465108c9eaf8e3c5d1ef515f8bf804a726db057433ecd25008ecdef624ee68ad9c103d1c7a615aad`
 
 ### Client Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-386.tar.gz) | `26df342ef65745df12fa52931358e7f744111b6fe1e0bddb8c3c6598faf73af997c00c8f9c509efcd7cd7e82a0341a718c08fbd96044bfb58e80d997a6ebd3c2`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-amd64.tar.gz) | `803a0fed122ef6b85f7a120b5485723eaade765b7bc8306d0c0da03bd3df15d800699d15ea2270bb7797fa9ce6a81da90e730dc793ea4ed8c0149b63d26eca30`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-386.tar.gz) | `110844511b70f9f3ebb92c15105e6680a05a562cd83f79ce2d2e25c2dd70f0dbd91cae34433f61364ae1ce4bd573b635f2f632d52de8f72b54acdbc95a15e3f0`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-amd64.tar.gz) | `594ca3eadc7974ec4d9e4168453e36ca434812167ef8359086cd64d048df525b7bd46424e7cc9c41e65c72bda3117326ba1662d1c9d739567f10f5684fd85bee`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm.tar.gz) | `d3627b763606557a6c9a5766c34198ec00b3a3cd72a55bc2cb47731060d31c4af93543fb53f53791062bb5ace2f15cbaa8592ac29009641e41bd656b0983a079`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm64.tar.gz) | `ba9056eff1452cbdaef699efbf88f74f5309b3f7808d372ebf6918442d0c9fea1653c00b9db3b7626399a460eef9b1fa9e29b827b7784f34561cbc380554e2ea`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-ppc64le.tar.gz) | `f80fb3769358cb20820ff1a1ce9994de5ed194aabe6c73fb8b8048bffc394d1b926de82c204f0e565d53ffe7562faa87778e97a3ccaaaf770034a992015e3a86`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-s390x.tar.gz) | `a9b658108b6803d60fa3cd4e76d9e58bf75201017164fe54054b7ccadbb68c4ad7ba7800746940bc518d90475e6c0a96965a26fa50882f4f0e56df404f4ae586`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-386.tar.gz) | `18adffab5d1be146906fd8531f4eae7153576aac235150ce2da05aee5ae161f6bd527e8dec34ae6131396cd4b3771e0d54ce770c065244ad3175a1afa63c89e1`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-amd64.tar.gz) | `162396256429cef07154f817de2a6b67635c770311f414e38b1e2db25961443f05d7b8eb1f8da46dec8e31c5d1d2cd45f0c95dad1bc0e12a0a7278a62a0b9a6b`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-darwin-amd64.tar.gz) | `7093a34298297e46bcd1ccb77a9c83ca93b8ccb63ce2099d3d8cd8911ccc384470ac202644843406f031c505a8960d247350a740d683d8910ca70a0b58791a1b`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-386.tar.gz) | `891569cff7906732a42b20b86d1bf20a9fe873f87b106e717a5c0f80728b5823c2a00c7ccea7ec368382509f095735089ddd582190bc51dcbbcef6b8ebdbd5cc`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-amd64.tar.gz) | `1590d4357136a71a70172e32820c4a68430d1b94cf0ac941ea17695fbe0c5440d13e26e24a2e9ebdd360c231d4cd16ffffbbe5b577c898c78f7ebdc1d8d00fa3`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-arm.tar.gz) | `bc0fb19fb6af47f591adc64b5a36d3dffcadc35fdfd77a4a222e037dbd2ee53fafb84f13c4e307910cfa36b3a46704063b42a14ceaad902755ec14c492ccd51d`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-arm64.tar.gz) | `6ff47f4fdfb3b5f2bfe18fd792fe9bfc747f06bf52de062ee803cda87ac4a98868d8e1211742e32dd443a4bdb770018bbdde704dae6abfc6d80c02bdfb4e0311`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-ppc64le.tar.gz) | `d8816518adc3a7fc00f996f23ff84e6782a3ebbba7ef37ba44def47b0e6506fefeeaf37d0e197cecf0deb5bd1a8f9dd1ba82af6c29a6b9d21b8e62af965b6b81`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-s390x.tar.gz) | `662fd4618f2b747d2b0951454b9148399f6cd25d3ca7c40457b6e02cb20df979138cad8cccd18fc8b265d9426c90828d3f0b2a6b40d9cd1a1bdc17219e35ed33`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-windows-386.tar.gz) | `d90cb92eb33ecbfab7a0e3a2da60ab10fc59132e4bc9abe0a1461a13222b5016704a7cfe0bf9bcf5d4ec55f505ffbbf53162dfe570e8f210e3f68b0d3a6bf7e3`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-windows-amd64.tar.gz) | `6ec32a8a62b69363a524c4f8db765ff4bd16ea7e5b0eb04aa5a667f8653eda18c357a97513d9e12f0ba1612516acb150deffb6e3608633c62b97a15b6efa7cc0`
 
 ### Server Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-amd64.tar.gz) | `a92f8d201973d5dfa44a398e95fcf6a7b4feeb1ef879ab3fee1c54370e21f59f725f27a9c09ace8c42c96ac202e297fd458e486c489e05f127a5cade53b8d7c4`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm.tar.gz) | `62fbff3256bc0a83f70244b09149a8d7870d19c2c4b6dee8ca2714fc7388da340876a0f540d2ae9bbd8b81fdedaf4b692c72d2840674db632ba2431d1df1a37d`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm64.tar.gz) | `842910a7013f61a60d670079716b207705750d55a9e4f1f93696d19d39e191644488170ac94d8740f8e3aa3f7f28f61a4347f69d7e93d149c69ac0efcf3688fe`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-ppc64le.tar.gz) | `95c5b952ac1c4127a5c3b519b664972ee1fb5e8e902551ce71c04e26ad44b39da727909e025614ac1158c258dc60f504b9a354c5ab7583c2ad769717b30b3836`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-s390x.tar.gz) | `a46522d2119a0fd58074564c1fa95dd8a929a79006b82ba3c4245611da8d2db9fd785c482e1b61a9aa361c5c9a6d73387b0e15e6a7a3d84fffb3f65db3b9deeb`
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-amd64.tar.gz) | `7c268bd58e67d3c5016f3fcc9f4b6d2da7558af5a2c708ff3baf767b39e847e3d35d4fd2fa0f640bedbfb09a445036cafbe2f04357a88dada405cfc2ded76972`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-arm.tar.gz) | `fcbf8d9004f1cd244a82b685abaf81f9638c3cc1373d78e705050042cfa6a004f8eed92f4721539dcd169c55b662d10416af19cff7537a8dfef802dc41b4088b`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-arm64.tar.gz) | `e21f54a35ff29e919e98fe81758f654ea735983d5a9d08dab9484598b116843830a86ceb5cf0a23d27b7f9aba77e5f0aa107c171a0837ba781d508ebbea76f55`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-ppc64le.tar.gz) | `c7014c782683f8f612c7805654b632aab4c5dce895ee8f9ef24360616e24240ce59ddf3cf27c3170df5450d8fe14fbca3fb7cddfc9b74ae37943081f0fa4b6b3`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-s390x.tar.gz) | `3ac2d6b273e5b650f63260aae164fc6781ad5760f63cca911f5db9652c4bf32e7e7b25728987befc6dfda89c5c56969681b75f12b17141527d4e1d12f3d41f3c`
 
 ### Node Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-amd64.tar.gz) | `f714f80feecb0756410f27efb4cf4a1b5232be0444fbecec9f25cb85a7ccccdcb5be588cddee935294f460046c0726b90f7acc52b20eeb0c46a7200cf10e351a`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm.tar.gz) | `806000b5f6d723e24e2f12d19d1b9b3d16c74b855f51c7063284adf1fcc57a96554a3384f8c05a952c6f6b929a05ed12b69151b1e620c958f74c9600f3db0fcb`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm64.tar.gz) | `c207e9ab60587d135897b5366af79efe9d2833f33401e469b2a4e0d74ecd2cf6bb7d1e5bc18d80737acbe37555707f63dd581ccc6304091c1d98dafdd30130b7`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-ppc64le.tar.gz) | `a542ed5ed02722af44ef12d1602f363fcd4e93cf704da2ea5d99446382485679626835a40ae2ba47a4a26dce87089516faa54479a1cfdee2229e8e35aa1c17d7`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-s390x.tar.gz) | `651e0db73ee67869b2ae93cb0574168e4bd7918290fc5662a6b12b708fa628282e3f64be2b816690f5a2d0f4ff8078570f8187e65dee499a876580a7a63d1d19`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-windows-amd64.tar.gz) | `d726ed904f9f7fe7e8831df621dc9094b87e767410a129aa675ee08417b662ddec314e165f29ecb777110fbfec0dc2893962b6c71950897ba72baaa7eb6371ed`
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-amd64.tar.gz) | `d5e21432a4ab019f00cd1a52bbbdb00feb3db2ce96b41a58b1ee27d8847c485f5d0efe13036fd1155469d6d15f5873a5a892ecc0198f1bae1bf5b586a0129e75`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-arm.tar.gz) | `bd57adf060813b06be2b33439d6f60d13630c0251ef96ba473274073200ea118f5622ec31ed714cc57bd9da410655e958a7700a5742ae7e4b6406ab12fbf21f3`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-arm64.tar.gz) | `3ee70abc0a5cbf1ef5dde0d27055f4d17084585c36a2cf41e3fd925d206df0b583f50dc1c118472f198788b65b2c447aa40ad41646b88791659d2dfb69b3890b`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-ppc64le.tar.gz) | `0f4368f229c082b2a75e7089a259e487d60b20bc8edf650dd7ca0fe23c51632397c2ef24c9c6cef078c95fce70d9229a5b4ff682c34f65a44bc4be3329c8ccde`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-s390x.tar.gz) | `8f0b6839fc0ad51300221fa7f32134f8c687073715cc0839f7aacb21a075c66dab113369707d03e9e0e53be62ca2e1bdf04d4b26cff805ae9c7a5a4b864e3eae`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-windows-amd64.tar.gz) | `587651158c9999e64e06186ef2e65fe14d46ffdae28c5d8ee6261193bfe4967717f997ebe13857fa1893bbf492e1cc1f816bce86a94c6df9b7a0264848391397`
 
-## Changelog since v1.17.0
-
-A complete changelog for the release notes is now hosted in a customizable
-format at [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0). Check it out and please give us your
-feedback!
+## Changelog since v1.18.0
 
 ## What’s New (Major Themes)
 
-### Kubernetes Topology Manager Moves to Beta - Align Up!
+### Deprecation warnings
 
-A beta feature of Kubernetes in release 1.18, the [Topology Manager feature](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) enables NUMA alignment of CPU and devices (such as SR-IOV VFs) that will allow your workload to run in an environment optimized for low-latency. Prior to the introduction of the Topology Manager, the CPU and Device Manager would make resource allocation decisions independent of each other. This could result in undesirable allocations on multi-socket systems, causing degraded performance on latency critical applications.
+SIG API Machinery implemented [warnings when using deprecated APIs](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#rest-resources-aka-api-objects)
+that are visible to `kubectl` users and API consumers, and metrics visible to cluster administrators.
+Requests to a deprecated API are returned with a warning containing a target removal release and any replacement API.
+Warnings can also be returned by [admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admissionreview-response-warning),
+and specified for [deprecated versions of custom resources](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#version-deprecation).
 
-### Serverside Apply - Beta 2
+### Avoiding permanent beta
 
-Server-side Apply was promoted to Beta in 1.16, but is now introducing a second Beta in 1.18. This new version will track and manage changes to fields of all new Kubernetes objects, allowing you to know what changed your resources and when.
+From Kubernetes 1.20 onwards, SIG Architecture will implement a new policy to transition all REST APIs out of beta within nine months. The idea behind the new policy is to avoid features staying in beta for a long time. Once a new API enters beta, it will have nine months to either:
 
-### Extending Ingress with and replacing a deprecated annotation with IngressClass
+ - reach GA, and deprecate the beta, or
+ - have a new beta version _(and deprecate the previous beta)_.
 
-In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types.
+If a REST API reaches the end of that nine-month countdown, then the next Kubernetes release will deprecate that API version. More information can be found on [the Kubernetes Blog](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/).
 
-The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation.
+### Expanded CLI support for debugging workloads and nodes
 
-### SIG CLI introduces kubectl debug
+SIG CLI expanded on debugging with `kubectl` to support two new debugging workflows: debugging workloads by creating a copy, and debugging nodes by creating a container in host namespaces. These can be convenient to:
+ - Insert a debug container in clusters that don’t have ephemeral containers enabled 
+ - Modify a crashing container for easier debugging by changing its image, for example to busybox, or its command, for example, to `sleep 1d` so you have time to `kubectl exec`.
+ - Inspect configuration files on a node's host filesystem
 
-SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable.  This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
+Since these new workflows don’t require any new cluster features, they’re available for experimentation with your existing clusters via `kubectl alpha debug`. We’d love to hear your feedback on debugging with `kubectl`. Reach us by opening an issue, visiting [#sig-cli](https://kubernetes.slack.com/messages/sig-cli) or commenting on enhancement [#1441](https://features.k8s.io/1441).
 
-### Introducing Windows CSI support alpha for Kubernetes
+### Structured logging
 
-With the release of Kubernetes 1.18, an alpha version of CSI Proxy for Windows is getting released. CSI proxy enables non-privileged (pre-approved) containers to perform privileged storage operations on Windows. CSI drivers can now be supported in Windows by leveraging CSI proxy.
-SIG Storage made a lot of progress in the 1.18 release.
-In particular, the following storage features are moving to GA in Kubernetes 1.18:
-- Raw Block Support: Allow volumes to be surfaced as block devices inside containers instead of just mounted filesystems.
-- Volume Cloning: Duplicate a PersistentVolumeClaim and underlying storage volume using the Kubernetes API via CSI.
-- CSIDriver Kubernetes API Object: Simplifies CSI driver discovery and allows CSI Drivers to customize Kubernetes behavior.
+SIG Instrumentation standardized the structure of log messages and references to Kubernetes objects. Structured logging makes parsing, processing, storing, querying and analyzing logs easier. New methods in the klog library enforce log message structure.
 
-SIG Storage is also introducing the following new storage features as alpha in Kubernetes 1.18:
-- Windows CSI Support: Enabling containerized CSI node plugins in Windows via new [CSIProxy](https://github.com/kubernetes-csi/csi-proxy)
-- Recursive Volume Ownership OnRootMismatch Option: Add a new “OnRootMismatch” policy that can help shorten the mount time for volumes that require ownership change and have many directories and files.
+### EndpointSlices are now enabled by default
 
-### Other notable announcements
+EndpointSlices are an exciting new API that provides a scalable and extensible alternative to the Endpoints API. EndpointSlices track IP addresses, ports, readiness, and topology information for Pods backing a Service.
 
-SIG Network is moving IPv6 to Beta in Kubernetes 1.18, after incrementing significantly the test coverage with new CI jobs.
+In Kubernetes 1.19 this feature will be enabled by default with kube-proxy reading from EndpointSlices instead of Endpoints. Although this will mostly be an invisible change, it should result in noticeable scalability improvements in large clusters. It will also enable significant new features in future Kubernetes releases like Topology Aware Routing.
 
-NodeLocal DNSCache is an add-on that runs a dnsCache pod as a daemonset to improve clusterDNS performance and reliability. The feature has been in Alpha since 1.13 release. The SIG Network is announcing the GA graduation of Node Local DNSCache [#1351](https://github.com/kubernetes/enhancements/pull/1351)
+### Ingress graduates to General Availability
+
+SIG Network has graduated the widely used [Ingress API](https://kubernetes.io/docs/concepts/services-networking/ingress/) to general availability in Kubernetes 1.19. This change recognises years of hard work by Kubernetes contributors, and paves the way for further work on future networking APIs in Kubernetes.
+
+### seccomp graduates to General Availability
+
+The seccomp (secure computing mode) support for Kubernetes has graduated to General Availability (GA). This feature can be used to increase the workload security by restricting the system calls for a Pod (applies to all containers) or single containers.
+
+Technically this means that a first class `seccompProfile` field has been added to the Pod and Container `securityContext` objects:
+
+```yaml
+securityContext:
+  seccompProfile:
+    type: RuntimeDefault|Localhost|Unconfined # choose one of the three
+    localhostProfile: my-profiles/profile-allow.json # only necessary if type == Localhost
+```
+
+The support for `seccomp.security.alpha.kubernetes.io/pod` and `container.seccomp.security.alpha.kubernetes.io/...` annotations are now deprecated, and will be removed in Kubernetes v1.22.0. Right now, an automatic version skew handling will convert the new field into the annotations and vice versa. This means there is no action required for converting existing workloads in a cluster.
+
+You can find more information about how to restrict container system calls with seccomp in the new [documentation page on Kubernetes.io][seccomp-docs]
+
+[seccomp-docs]: https://kubernetes.io/docs/tutorials/clusters/seccomp/
+
+
+### Production images moved to community control
+
+As of Kuberenetes v1.19, Kubernetes container images are stored on a community-controlled storage bucket, 
+located at `{asia,eu,us}.gcr.io/k8s-artifacts-prod`. The `k8s.gcr.io` vanity domain has been updated 
+to this new bucket. This brings production artifacts under community control.
+
+### KubeSchedulerConfiguration graduates to Beta
+
+SIG Scheduling graduates `KubeSchedulerConfiguration` to Beta. The [KubeSchedulerConfiguration](https://kubernetes.io/docs/reference/scheduling/config) feature allows you to tune the algorithms and other settings of the kube-scheduler. You can easily enable or disable specific functionality (contained in plugins) in selected scheduling phases without having to rewrite the rest of the configuration. Furthermore, a single kube-scheduler instance can serve different configurations, called profiles. Pods can select the profile they want to be scheduled under via the `.spec.schedulerName` field.
+
+### CSI Migration - AzureDisk and vSphere (beta)
+ 
+In-tree volume plugins and all cloud provider dependencies are being moved out of the Kubernetes core. The CSI migration feature allows existing volumes using the legacy APIs to continue to function even when the code has been removed, by routing all the volume operations to the respective CSI driver. The AzureDisk and vSphere implementations of this feature have been promoted to beta.
+
+### Storage capacity tracking
+
+Traditionally, the Kubernetes scheduler was based on the assumption that additional persistent storage is available everywhere in the cluster and has infinite capacity. Topology constraints addressed the first point, but up to now pod scheduling was still done without considering that the remaining storage capacity may not be enough to start a new pod. [Storage capacity tracking](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking), a new alpha feature, addresses that by adding an API for a CSI driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod. This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained.
+
+### CSI Volume health monitoring
+ 
+The alpha version of CSI health monitoring is being released with Kubernetes 1.19. This feature enables CSI Drivers to share abnormal volume conditions from the underlying storage systems with Kubernetes so that they can be reported as events on PVCs or Pods. This feature serves as a stepping stone towards programmatic detection and resolution of individual volume health issues by Kubernetes.
+
+### General ephemeral volumes
+
+Kubernetes provides volume plugins whose lifecycle is tied to a pod and can be used as scratch space (e.g. the builtin “empty dir” volume type) or to load some data in to a pod (e.g. the builtin ConfigMap and Secret volume types or “CSI inline volumes”). The new [generic ephemeral volumes](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1698-generic-ephemeral-volumes) alpha feature allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume with the volume’s lifecycle bound to the Pod.
+ - It can be used to provide scratch storage that is different from the root disk, for example persistent memory, or a separate local disk on that node.
+ - All StorageClass parameters for volume provisioning are supported.
+ - All features supported with PersistentVolumeClaims are supported, such as storage capacity tracking, snapshots and restore, and volume resizing.
+
+### Immutable Secrets and ConfigMaps (beta)
+
+Secret and ConfigMap volumes can be marked as immutable, which significantly reduces load on the API server if there are many Secret and ConfigMap volumes in the cluster.
+See [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) and [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) for more information.
+
+### CSI Proxy for Windows
+
+The CSI Proxy for Windows is being promoted to beta along with the 1.19 release. This CSI Proxy enables CSI Drivers to run on Windows by allowing containers in Windows to perform privileged storage operations. At beta, the CSI Proxy for Windows supports storage drivers using direct attached disks and SMB.
+
+### Dashboard v2
+
+SIG UI has released v2 of the Kubernetes Dashboard add-on. You can find the most recent release in the [kubernetes/dashboard](https://github.com/kubernetes/dashboard/releases) repository. Kubernetes Dashboard now includes CRD support, new translations, and an updated version of AngularJS.
+
+### Windows containerd support graduates to beta
+
+Initially introduced in Kubernetes 1.18, Windows containerd support goes to Beta on this release. This includes the added support for Windows Server version 2004 (complete version compatibility can be found in the [documentation for Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd)).
+
+SIG Windows is also including several addition to this release:
+ - Direct Server Return (DSR) mode support, allowing large numbers of services to scale up efficiently
+ - Windows containers  now honor CPU limits
+ - Performance improvements for collections of metrics and summary
+
+### Increase the Kubernetes support window to one year
+
+As of Kubernetes 1.19, bugfix support via patch releases for a Kubernetes minor release has increased from 9 months to 1 year.
+
+A survey conducted in early 2019 by the working group (WG) Long Term Support (LTS) showed that a significant subset of Kubernetes end-users fail to upgrade within the previous 9-month support period. 
+A yearly support period provides the cushion end-users appear to desire, and is more in harmony with familiar annual planning cycles.
 
 ## Known Issues
 
-No Known Issues Reported
+The new storage capacity tracking alpha feature is known to be affected by a limitation of the WaitForFirstConsumer volume binding mode: [#94217](https://github.com/kubernetes/kubernetes/issues/94217)
 
-## Urgent Upgrade Notes
+## Urgent Upgrade Notes 
 
 ### (No, really, you MUST read this before you upgrade)
 
-#### kube-apiserver:
-- in an `--encryption-provider-config` config file, an explicit `cacheSize: 0` parameter previously silently defaulted to caching 1000 keys. In Kubernetes 1.18, this now returns a config validation error. To disable caching, you can specify a negative cacheSize value in Kubernetes 1.18+.
-- consumers of the 'certificatesigningrequests/approval' API must now have permission to 'approve' CSRs for the specific signer requested by the CSR. More information on the new signerName field and the required authorization can be found at https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests#authorization ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, Apps, Auth, CLI, Node and Testing]
-- The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) [SIG Apps and Scheduling]
-
-#### kubelet:
-- `--enable-cadvisor-endpoints` is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, Node and Testing]
-- Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver. The in-tree AWS OpenStack Cinder driver "kubernetes.io/cinder" was deprecated in 1.16 and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time. Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider]
-
-#### kubectl:
-- `kubectl` and k8s.io/client-go no longer default to a server address of `http://localhost:8080`. If you own one of these legacy clusters, you are *strongly* encouraged to secure your server. If you cannot secure your server, you can set the `$KUBERNETES_MASTER` environment variable to `http://localhost:8080` to continue defaulting the server address. `kubectl` users can also set the server address using the `--server` flag, or in a kubeconfig file specified via `--kubeconfig` or `$KUBECONFIG`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
-- `kubectl run` has removed the previously deprecated generators, along with flags unrelated to creating pods. `kubectl run` now only creates pods. See specific `kubectl create` subcommands to create objects other than pods.
-([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI and Testing]
-- The deprecated command `kubectl rolling-update` has been removed ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing]
-
-#### client-go:
-- Signatures on methods in generated clientsets, dynamic, metadata, and scale clients have been modified to accept `context.Context` as a first argument. Signatures of Create, Update, and Patch methods have been updated to accept CreateOptions, UpdateOptions and PatchOptions respectively. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. Generated clientsets with the previous interface have been added in new "deprecated" packages to allow incremental migration to the new APIs. The deprecated packages will be removed in the 1.21 release. A tool is available at http://sigs.k8s.io/clientgofix to rewrite method invocations to the new signatures.
-
-- The following deprecated metrics are removed, please convert to the corresponding metrics:
-  - The following replacement metrics are available from v1.14.0:
-      - `rest_client_request_latency_seconds` -> `rest_client_request_duration_seconds`
-      - `scheduler_scheduling_latency_seconds` -> `scheduler_scheduling_duration_seconds `
-      - `docker_operations` -> `docker_operations_total`
-      - `docker_operations_latency_microseconds` -> `docker_operations_duration_seconds`
-      - `docker_operations_errors` -> `docker_operations_errors_total`
-      - `docker_operations_timeout` -> `docker_operations_timeout_total`
-      - `network_plugin_operations_latency_microseconds` -> `network_plugin_operations_duration_seconds`
-      - `kubelet_pod_worker_latency_microseconds` -> `kubelet_pod_worker_duration_seconds`
-      - `kubelet_pod_start_latency_microseconds` -> `kubelet_pod_start_duration_seconds`
-      - `kubelet_cgroup_manager_latency_microseconds` -> `kubelet_cgroup_manager_duration_seconds`
-      - `kubelet_pod_worker_start_latency_microseconds` -> `kubelet_pod_worker_start_duration_seconds`
-      - `kubelet_pleg_relist_latency_microseconds` -> `kubelet_pleg_relist_duration_seconds`
-      - `kubelet_pleg_relist_interval_microseconds` -> `kubelet_pleg_relist_interval_seconds`
-      - `kubelet_eviction_stats_age_microseconds` -> `kubelet_eviction_stats_age_seconds`
-      - `kubelet_runtime_operations` -> `kubelet_runtime_operations_total`
-      - `kubelet_runtime_operations_latency_microseconds` -> `kubelet_runtime_operations_duration_seconds`
-      - `kubelet_runtime_operations_errors` -> `kubelet_runtime_operations_errors_total`
-      - `kubelet_device_plugin_registration_count` -> `kubelet_device_plugin_registration_total`
-      - `kubelet_device_plugin_alloc_latency_microseconds` -> `kubelet_device_plugin_alloc_duration_seconds`
-      - `scheduler_e2e_scheduling_latency_microseconds` -> `scheduler_e2e_scheduling_duration_seconds`
-      - `scheduler_scheduling_algorithm_latency_microseconds` -> `scheduler_scheduling_algorithm_duration_seconds`
-      - `scheduler_scheduling_algorithm_predicate_evaluation` -> `scheduler_scheduling_algorithm_predicate_evaluation_seconds`
-      - `scheduler_scheduling_algorithm_priority_evaluation` -> `scheduler_scheduling_algorithm_priority_evaluation_seconds`
-      - `scheduler_scheduling_algorithm_preemption_evaluation` -> `scheduler_scheduling_algorithm_preemption_evaluation_seconds`
-      - `scheduler_binding_latency_microseconds` -> `scheduler_binding_duration_seconds`
-      - `kubeproxy_sync_proxy_rules_latency_microseconds` -> `kubeproxy_sync_proxy_rules_duration_seconds`
-      - `apiserver_request_latencies` -> `apiserver_request_duration_seconds`
-      - `apiserver_dropped_requests` -> `apiserver_dropped_requests_total`
-      - `etcd_request_latencies_summary` -> `etcd_request_duration_seconds`
-      - `apiserver_storage_transformation_latencies_microseconds ` -> `apiserver_storage_transformation_duration_seconds`
-      - `apiserver_storage_data_key_generation_latencies_microseconds` -> `apiserver_storage_data_key_generation_duration_seconds`
-      - `apiserver_request_count` -> `apiserver_request_total`
-      - `apiserver_request_latencies_summary`
-  - The following replacement metrics are available from v1.15.0:
-      - `apiserver_storage_transformation_failures_total` -> `apiserver_storage_transformation_operations_total` ([#76496](https://github.com/kubernetes/kubernetes/pull/76496), [@danielqsj](https://github.com/danielqsj)) [SIG API Machinery, Cluster Lifecycle, Instrumentation, Network, Node and Scheduling]
-
+- ACTION REQUIRED: Switch core master base images (kube-controller-manager) from debian to distroless. If you need Flex Volumes support using scripts, please build your own image with required packages (like bash) ([#91329](https://github.com/kubernetes/kubernetes/pull/91329), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release, Storage and Testing]
+- ACTION REQUIRED: Support for basic authentication via the --basic-auth-file flag has been removed.  Users should migrate to --token-auth-file for similar functionality. ([#89069](https://github.com/kubernetes/kubernetes/pull/89069), [@enj](https://github.com/enj)) [SIG API Machinery]
+ - Azure blob disk feature(`kind`: `Shared`, `Dedicated`) has been deprecated, you should use `kind`: `Managed` in `kubernetes.io/azure-disk` storage class. ([#92905](https://github.com/kubernetes/kubernetes/pull/92905), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+ - CVE-2020-8559 (Medium): Privilege escalation from compromised node to cluster. See https://github.com/kubernetes/kubernetes/issues/92914 for more details.
+  The API Server will no longer proxy non-101 responses for upgrade requests. This could break proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code. ([#92941](https://github.com/kubernetes/kubernetes/pull/92941), [@tallclair](https://github.com/tallclair)) [SIG API Machinery]
+ - Kubeadm does not set the deprecated '--cgroup-driver' flag in /var/lib/kubelet/kubeadm-flags.env, it will be set in the kubelet config.yaml. If you have this flag in /var/lib/kubelet/kubeadm-flags.env or /etc/default/kubelet (/etc/sysconfig/kubelet for RPMs) please remove it and set the value using KubeletConfiguration ([#90513](https://github.com/kubernetes/kubernetes/pull/90513), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+ - Kubeadm now respects user specified etcd versions in the ClusterConfiguration and properly uses them. If users do not want to stick to the version specified in the ClusterConfiguration, they should edit the kubeadm-config config map and delete it. ([#89588](https://github.com/kubernetes/kubernetes/pull/89588), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+ - Kubeadm respects resolvConf value set by user even if systemd-resolved service is active. kubeadm no longer sets the flag in '--resolv-conf' in /var/lib/kubelet/kubeadm-flags.env. If you have this flag in /var/lib/kubelet/kubeadm-flags.env or /etc/default/kubelet (/etc/sysconfig/kubelet for RPMs) please remove it and set the value using KubeletConfiguration ([#90394](https://github.com/kubernetes/kubernetes/pull/90394), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+ - Kubeadm: Move the "kubeadm init" phase "kubelet-start" later in the init workflow, after the "kubeconfig" phase. This makes kubeadm start the kubelet only after the KubeletConfiguration component config file (/var/lib/kubelet/config.yaml) is generated and solves a problem where init systems like OpenRC cannot crashloop the kubelet service. ([#90892](https://github.com/kubernetes/kubernetes/pull/90892), [@xphoniex](https://github.com/xphoniex)) [SIG Cluster Lifecycle]
+ - The 'kubeadm config upload' command is finally removed after a full GA deprecation cycle. If you still use it, please, use 'kubeadm init phase upload-config' instead ([#92610](https://github.com/kubernetes/kubernetes/pull/92610), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+ - Upgrade kubescheduler.config.k8s.io/v1alpha2 to kubescheduler.config.k8s.io/v1beta1
+  
+   - `.bindTimeoutSeconds` was moved as part of plugin args for `VolumeBinding`,
+     which can be configured separately per [profile](&#35;profiles).
+   - `.extenders` are updated to satisfy API standards. In particular:
+     - `.extenders` decoding is case sensitive. All fields are affected.
+     - `.extenders[*].httpTimeout` is of type `metav1.Duration`.
+     - `.extenders[*].enableHttps` is renamed to `.extenders[*].enableHTTPS`.
+   - `RequestedToCapacityRatio` args decoding is case sensitive. All fields are affected.
+   - `DefaultPodTopologySpread` [plugin](&#35;scheduling-plugins) is renamed to `SelectorSpread`.
+   - `Unreserve` extension point is removed from Profile definition. All `Reserve`
+     plugins implement an `Unreserve` call.
+   - `.disablePreemption` was removed. Users can disable preemption by disabling the
+     "DefaultPreemption" PostFilter plugin. ([#91420](https://github.com/kubernetes/kubernetes/pull/91420), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
+ 
 ## Changes by Kind
 
 ### Deprecation
 
-#### kube-apiserver:
-- the following deprecated APIs can no longer be served:
-  - All resources under `apps/v1beta1` and `apps/v1beta2` - use `apps/v1` instead
-  - `daemonsets`, `deployments`, `replicasets` resources under `extensions/v1beta1` - use `apps/v1` instead
-  - `networkpolicies` resources under `extensions/v1beta1` - use `networking.k8s.io/v1` instead
-  - `podsecuritypolicies` resources under `extensions/v1beta1` - use `policy/v1beta1` instead ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, Cluster Lifecycle, Instrumentation and Testing]
+- Added support for vSphere in-tree volumes migration to vSphere CSI driver. The in-tree vSphere Volume plugin will be deprecated and removed in a future release.
+  
+  Users that self-deploy Kubernetes on vSphere should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to avoid disruption to existing Pod and PVC objects at that time. Users should start using the vSphere CSI driver directly for any new volumes.
+  
+  The CSI Migration feature for vSphere Volume also requires minimum vSphere vCenter/ESXi Version to be 7.0u1 and minimum HW Version to be VM version 15.
+  
+  vSAN raw policy parameter is deprecated for the in-tree vSphere Volume plugin and will be removed in a future release. ([#90911](https://github.com/kubernetes/kubernetes/pull/90911), [@divyenpatel](https://github.com/divyenpatel)) [SIG API Machinery, Node and Storage]
+- Apiextensions.k8s.io/v1beta1 is deprecated in favor of apiextensions.k8s.io/v1 ([#90673](https://github.com/kubernetes/kubernetes/pull/90673), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Apiregistration.k8s.io/v1beta1 is deprecated in favor of apiregistration.k8s.io/v1 ([#90672](https://github.com/kubernetes/kubernetes/pull/90672), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Authentication.k8s.io/v1beta1 and authorization.k8s.io/v1beta1 are deprecated in 1.19 in favor of v1 levels and will be removed in 1.22 ([#90458](https://github.com/kubernetes/kubernetes/pull/90458), [@deads2k](https://github.com/deads2k)) [SIG API Machinery and Auth]
+- Autoscaling/v2beta1 is deprecated in favor of autoscaling/v2beta2 ([#90463](https://github.com/kubernetes/kubernetes/pull/90463), [@deads2k](https://github.com/deads2k)) [SIG Autoscaling]
+- Coordination.k8s.io/v1beta1 is deprecated in 1.19, targeted for removal in 1.22, use v1 instead. ([#90559](https://github.com/kubernetes/kubernetes/pull/90559), [@deads2k](https://github.com/deads2k)) [SIG Scalability]
+- Ensure that volume capability and staging target fields are present in nodeExpansion CSI calls
 
-#### kube-controller-manager:
-- Azure service annotation service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset has been deprecated. Its support would be removed in a future release. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-
-#### kubelet:
-- The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option. If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node]
-- resource metrics endpoint `/metrics/resource/v1alpha1` as well as all metrics under this endpoint have been deprecated. Please convert to the following metrics emitted by endpoint `/metrics/resource`:
-      - scrape_error --> scrape_error
-      - node_cpu_usage_seconds_total --> node_cpu_usage_seconds
-      - node_memory_working_set_bytes --> node_memory_working_set_bytes
-      - container_cpu_usage_seconds_total --> container_cpu_usage_seconds
-      - container_memory_working_set_bytes --> container_memory_working_set_bytes
-      - scrape_error --> scrape_error
-      ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG Node]
-- In a future release, kubelet will no longer create the CSI NodePublishVolume target directory, in accordance with the CSI specification. CSI drivers may need to be updated accordingly to properly create and process the target path. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG Storage]
-
-#### kube-proxy:
-- `--healthz-port` and `--metrics-port` flags are deprecated, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
-- a new `EndpointSliceProxying` feature gate has been added to control the use of EndpointSlices in kube-proxy. The EndpointSlice feature gate that used to control this behavior no longer affects kube-proxy. This feature has been disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
-
-#### kubeadm:
-- command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- kube-dns is deprecated and will not be supported in a future version ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- the `ClusterStatus` struct present in the kubeadm-config ConfigMap is deprecated and will be removed in a future version. It is going to be maintained by kubeadm until it gets removed. The same information can be found on `etcd` and `kube-apiserver` pod annotations, `kubeadm.kubernetes.io/etcd.advertise-client-urls` and `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint` respectively. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle]
-
-#### kubectl:
-- the boolean and unset values for the --dry-run flag are deprecated and a value --dry-run=server|client|none will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-- `kubectl apply --server-dry-run` is deprecated and replaced with --dry-run=server ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-
-#### add-ons:
-- Remove cluster-monitoring addon ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius)) [SIG Cluster Lifecycle, Instrumentation, Scalability and Testing]
-
-#### kube-scheduler:
-- The `scheduling_duration_seconds` summary metric is deprecated ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG Scheduling]
-- The `scheduling_algorithm_predicate_evaluation_seconds` and
-  `scheduling_algorithm_priority_evaluation_seconds` metrics are deprecated, replaced by `framework_extension_point_duration_seconds[extension_point="Filter"]` and `framework_extension_point_duration_seconds[extension_point="Score"]`. ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG Scheduling]
-- `AlwaysCheckAllPredicates` is deprecated in scheduler Policy API. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
-
-#### Other deprecations:
-- The k8s.io/node-api component is no longer updated. Instead, use the RuntimeClass types located within k8s.io/api, and the generated clients located within k8s.io/client-go ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG Node and Release]
-- Removed the 'client' label from apiserver_request_total. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery and Instrumentation]
+  Behaviour of NodeExpandVolume being called between NodeStage and NodePublish is deprecated for CSI volumes. CSI drivers should support calling NodeExpandVolume after NodePublish if they have node EXPAND_VOLUME capability ([#86968](https://github.com/kubernetes/kubernetes/pull/86968), [@gnufied](https://github.com/gnufied)) [SIG Storage]
+- Feat: azure disk migration go beta in 1.19. Feature gates CSIMigration to Beta (on by default) and CSIMigrationAzureDisk to Beta (off by default since it requires installation of the AzureDisk CSI Driver)
+  The in-tree AzureDisk plugin "kubernetes.io/azure-disk" is now deprecated and will be removed in 1.23. Users should enable CSIMigration + CSIMigrationAzureDisk features and install the AzureDisk CSI Driver (https://github.com/kubernetes-sigs/azuredisk-csi-driver) to avoid disruption to existing Pod and PVC objects at that time.
+  Users should start using the AzureDisk CSI Driver directly for any new volumes. ([#90896](https://github.com/kubernetes/kubernetes/pull/90896), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Cluster Lifecycle]
+- Kubeadm: `kubeadm config view` command has been deprecated and will be removed in a feature release, please use `kubectl get cm -o yaml -n kube-system kubeadm-config` to get the kubeadm config directly ([#92740](https://github.com/kubernetes/kubernetes/pull/92740), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: deprecate the "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. ([#92881](https://github.com/kubernetes/kubernetes/pull/92881), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: deprecate the feature `--experimental-kustomize` in favor of `--experimental-patches`. The supported patch formats are the same as "kubectl patch". They are read as files from a directory and can be applied to kubeadm components during init/join/upgrade. Only patching of static Pods is supported for the time being. ([#92017](https://github.com/kubernetes/kubernetes/pull/92017), [@neolit123](https://github.com/neolit123))
+- Kubeadm: remove the deprecated "--use-api" flag for "kubeadm alpha certs renew" ([#90143](https://github.com/kubernetes/kubernetes/pull/90143), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubernetes no longer supports building hyperkube images ([#88676](https://github.com/kubernetes/kubernetes/pull/88676), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle and Release]
+- Remove --export flag from kubectl get command. ([#88649](https://github.com/kubernetes/kubernetes/pull/88649), [@oke-py](https://github.com/oke-py)) [SIG CLI and Testing]
+- Scheduler's alpha feature 'ResourceLimitsPriorityFunction' is completely removed due to lack of usage ([#91883](https://github.com/kubernetes/kubernetes/pull/91883), [@SataQiu](https://github.com/SataQiu)) [SIG Scheduling and Testing]
+- Storage.k8s.io/v1beta1 is deprecated in favor of storage.k8s.io/v1 ([#90671](https://github.com/kubernetes/kubernetes/pull/90671), [@deads2k](https://github.com/deads2k)) [SIG Storage]
 
 ### API Change
 
-#### New API types/versions:
-- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing]
-- The CSIDriver API has graduated to storage.k8s.io/v1, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
-
-#### New API fields:
-- autoscaling/v2beta2 HorizontalPodAutoscaler added a `spec.behavior` field that allows scale behavior to be configured. Behaviors are specified separately for scaling up and down. In each direction a stabilization window can be specified as well as a list of policies and how to select amongst them. Policies can limit the absolute number of pods added or removed, or the percentage of pods added or removed. ([#74525](https://github.com/kubernetes/kubernetes/pull/74525), [@gliush](https://github.com/gliush)) [SIG API Machinery, Apps, Autoscaling and CLI]
-- Ingress:
-  - `spec.ingressClassName` replaces the deprecated `kubernetes.io/ingress.class` annotation, and allows associating an Ingress object with a particular controller.
-  - path definitions added a `pathType` field to allow indicating how the specified path should be matched against incoming requests. Valid values are `Exact`, `Prefix`, and `ImplementationSpecific` ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network]
-- The alpha feature `AnyVolumeDataSource` enables PersistentVolumeClaim objects to use the spec.dataSource field to reference a custom type as a data source ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage]
-- The alpha feature `ConfigurableFSGroupPolicy` enables v1 Pods to specify a spec.securityContext.fsGroupChangePolicy policy to control how file permissions are applied to volumes mounted into the pod. ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG  Storage]
-- The alpha feature `ServiceAppProtocol` enables setting an `appProtocol` field in ServicePort and EndpointPort definitions. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
-- The alpha feature `ImmutableEphemeralVolumes` enables an `immutable` field in both Secret and ConfigMap objects to mark their contents as immutable. ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, CLI and Testing]
-
-#### Other API changes:
-- The beta feature `ServerSideApply` enables tracking and managing changed fields for all new objects, which means there will be `managedFields` in `metadata` with the list of managers and their owned fields.
-- The alpha feature `ServiceAccountIssuerDiscovery` enables publishing OIDC discovery information and service account token verification keys at `/.well-known/openid-configuration` and `/openid/v1/jwks` endpoints by API servers configured to issue service account tokens. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, Auth, Cluster Lifecycle and Testing]
-- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
-- CustomResourceDefinition schemas that use `x-kubernetes-list-type: map` or `x-kubernetes-list-type: set` now enable validation that the list items in the corresponding custom resources are unique. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-
-#### Configuration file changes:
-
-#### kube-apiserver:
-- The `--egress-selector-config-file` configuration file now accepts an apiserver.k8s.io/v1beta1  EgressSelectorConfiguration configuration object, and has been updated to allow specifying HTTP or GRPC connections to the network proxy ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Cloud Provider and Cluster Lifecycle]
-
-#### kube-scheduler:
-- A kubescheduler.config.k8s.io/v1alpha2 configuration file version is now accepted, with support for multiple scheduling profiles ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-  - HardPodAffinityWeight moved from a top level ComponentConfig parameter to a PluginConfig parameter of InterPodAffinity Plugin in `kubescheduler.config.k8s.io/v1alpha2` ([#88002](https://github.com/kubernetes/kubernetes/pull/88002), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing]
-  - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.schedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
-  - Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
-  - The PostFilter of scheduler framework is renamed to PreScore in kubescheduler.config.k8s.io/v1alpha2. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing]
-
-#### kube-proxy:
-- Added kube-proxy flags `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout` to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cluster Lifecycle and Network]
-- Added optional `--detect-local-mode` flag to kube-proxy. Valid values are "ClusterCIDR" (default matching previous behavior) and "NodeCIDR" ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
-- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver.  Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling]
-- Kubelet pod resources API now provides the information about active pods only. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG Node]
-- New flag `--endpointslice-updates-batch-period` in kube-controller-manager can be used to reduce the number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network]
-- New flag `--show-hidden-metrics-for-version` in kube-proxy, kubelet, kube-controller-manager, and kube-scheduler can be used to show all hidden metrics that are deprecated in the previous minor release. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango)) [SIG Cluster Lifecycle and Network]
-
-#### Features graduated to beta:
-  - StartupProbe ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx)) [SIG Node, Scalability and Testing]
-
-#### Features graduated to GA:
-  - VolumePVCDataSource ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Storage]
-  - TaintBasedEvictions ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing]
-  - BlockVolume and CSIBlockVolume ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
-  - Windows RunAsUserName ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows]
-- The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- A new alpha-level field, `SupportsFsGroup`, has been introduced for CSIDrivers to allow them to specify whether they support volume ownership and permission modifications. The `CSIVolumeSupportFSGroup` feature gate must be enabled to allow this field to be used. ([#92001](https://github.com/kubernetes/kubernetes/pull/92001), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, CLI and Storage]
+- Added pod version skew strategy for seccomp profile to synchronize the deprecated annotations with the new API Server fields. Please see the corresponding section [in the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md&#35;version-skew-strategy) for more detailed explanations. ([#91408](https://github.com/kubernetes/kubernetes/pull/91408), [@saschagrunert](https://github.com/saschagrunert)) [SIG Apps, Auth, CLI and Node]
+- Adds the ability to disable Accelerator/GPU metrics collected by Kubelet ([#91930](https://github.com/kubernetes/kubernetes/pull/91930), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node]
+- Admission webhooks can now return warning messages that are surfaced to API clients, using the `.response.warnings` field in the admission review response. ([#92667](https://github.com/kubernetes/kubernetes/pull/92667), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- CertificateSigningRequest API conditions were updated:
+  - a `status` field was added; this field defaults to `True`, and may only be set to `True` for `Approved`, `Denied`, and `Failed` conditions
+  - a `lastTransitionTime` field was added
+  - a `Failed` condition type was added to allow signers to indicate permanent failure; this condition can be added via the `certificatesigningrequests/status` subresource.
+  - `Approved` and `Denied` conditions are mutually exclusive
+  - `Approved`, `Denied`, and `Failed` conditions can no longer be removed from a CSR ([#90191](https://github.com/kubernetes/kubernetes/pull/90191), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, Auth, CLI and Node]
+- Cluster admins can now turn off /logs endpoint in kubelet by setting enableSystemLogHandler to false in their kubelet configuration file. enableSystemLogHandler can be set to true only when enableDebuggingHandlers is also set to true. ([#87273](https://github.com/kubernetes/kubernetes/pull/87273), [@SaranBalaji90](https://github.com/SaranBalaji90)) [SIG Node]
+- Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. ([#91637](https://github.com/kubernetes/kubernetes/pull/91637), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing]
+- CustomResourceDefinitions added support for marking versions as deprecated by setting `spec.versions[*].deprecated` to `true`, and for optionally overriding the default deprecation warning with a `spec.versions[*].deprecationWarning` field. ([#92329](https://github.com/kubernetes/kubernetes/pull/92329), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- EnvVarSource api doc bug fixes ([#91194](https://github.com/kubernetes/kubernetes/pull/91194), [@wawa0210](https://github.com/wawa0210)) [SIG Apps]
+- Fix bug in reflector that couldn't recover from "Too large resource version" errors ([#92537](https://github.com/kubernetes/kubernetes/pull/92537), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- Fixed: log timestamps now include trailing zeros to maintain a fixed width ([#91207](https://github.com/kubernetes/kubernetes/pull/91207), [@iamchuckss](https://github.com/iamchuckss)) [SIG Apps and Node]
+- Generic ephemeral volumes, a new alpha feature under the `GenericEphemeralVolume` feature gate, provide a more flexible alternative to `EmptyDir` volumes: as with `EmptyDir`, volumes are created and deleted for each pod automatically by Kubernetes. But because the normal provisioning process is used (`PersistentVolumeClaim`), storage can be provided by third-party storage vendors and all of the usual volume features work. Volumes don't need to be empt; for example, restoring from snapshot is supported. ([#92784](https://github.com/kubernetes/kubernetes/pull/92784), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing]
+- Go1.14.4 is now the minimum version required for building Kubernetes ([#92438](https://github.com/kubernetes/kubernetes/pull/92438), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Storage and Testing]
+- Hide managedFields from kubectl edit command ([#91946](https://github.com/kubernetes/kubernetes/pull/91946), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- K8s.io/apimachinery - scheme.Convert() now uses only explicitly registered conversions - default reflection based conversion is no longer available. `+k8s:conversion-gen` tags can be used with the `k8s.io/code-generator` component to generate conversions. ([#90018](https://github.com/kubernetes/kubernetes/pull/90018), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps and Testing]
+- Kube-proxy: add `--bind-address-hard-fail` flag to treat failure to bind to a port as fatal ([#89350](https://github.com/kubernetes/kubernetes/pull/89350), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Network]
+- Kubebuilder validation tags are set on metav1.Condition for CRD generation ([#92660](https://github.com/kubernetes/kubernetes/pull/92660), [@damemi](https://github.com/damemi)) [SIG API Machinery]
+- Kubelet's --runonce option is now also available in Kubelet's config file as `runOnce`. ([#89128](https://github.com/kubernetes/kubernetes/pull/89128), [@vincent178](https://github.com/vincent178)) [SIG Node]
+- Kubelet: add '--logging-format' flag to support structured logging ([#91532](https://github.com/kubernetes/kubernetes/pull/91532), [@afrouzMashaykhi](https://github.com/afrouzMashaykhi)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Node]
+- Kubernetes is now built with golang 1.15.0-rc.1.
+  - The deprecated, legacy behavior of treating the CommonName field on X.509 serving certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable. ([#93264](https://github.com/kubernetes/kubernetes/pull/93264), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage and Testing]
+- Promote Immutable Secrets/ConfigMaps feature to Beta and enable the feature by default.
+  This allows to set `Immutable` field in Secrets or ConfigMap object to mark their contents as immutable. ([#89594](https://github.com/kubernetes/kubernetes/pull/89594), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps and Testing]
+- Remove `BindTimeoutSeconds` from schedule configuration `KubeSchedulerConfiguration` ([#91580](https://github.com/kubernetes/kubernetes/pull/91580), [@cofyc](https://github.com/cofyc)) [SIG Scheduling and Testing]
+- Remove kubescheduler.config.k8s.io/v1alpha1 ([#89298](https://github.com/kubernetes/kubernetes/pull/89298), [@gavinfish](https://github.com/gavinfish)) [SIG Scheduling]
+- Reserve plugins that fail to reserve will trigger the unreserve extension point ([#92391](https://github.com/kubernetes/kubernetes/pull/92391), [@adtac](https://github.com/adtac)) [SIG Scheduling and Testing]
+- Resolve regression in `metadata.managedFields` handling in update/patch requests submitted by older API clients ([#91748](https://github.com/kubernetes/kubernetes/pull/91748), [@apelisse](https://github.com/apelisse))
+- Scheduler: optionally check for available storage capacity before scheduling pods which have unbound volumes (alpha feature with the new `CSIStorageCapacity` feature gate, only works for CSI drivers and depends on support for the feature in a CSI driver deployment) ([#92387](https://github.com/kubernetes/kubernetes/pull/92387), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, Scheduling, Storage and Testing]
+- Seccomp support has graduated to GA. A new `seccompProfile` field is added to pod and container securityContext objects. Support for `seccomp.security.alpha.kubernetes.io/pod` and `container.seccomp.security.alpha.kubernetes.io/...` annotations is deprecated, and will be removed in v1.22. ([#91381](https://github.com/kubernetes/kubernetes/pull/91381), [@pjbgf](https://github.com/pjbgf)) [SIG Apps, Auth, Node, Release, Scheduling and Testing]
+- ServiceAppProtocol feature gate is now beta and enabled by default, adding new AppProtocol field to Services and Endpoints. ([#90023](https://github.com/kubernetes/kubernetes/pull/90023), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- SetHostnameAsFQDN is a new field in PodSpec. When set to true, the fully 
+  qualified domain name (FQDN) of a Pod is set as hostname of its containers. 
+  In Linux containers, this means setting the FQDN in the hostname field of the 
+  kernel (the nodename field of struct utsname).  In Windows containers, this
+  means setting the this means setting the registry value of hostname for the registry key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters to FQDN. 
+  If a pod does not have FQDN, this has no effect. ([#91699](https://github.com/kubernetes/kubernetes/pull/91699), [@javidiaz](https://github.com/javidiaz)) [SIG Apps, Network, Node and Testing]
+- The CertificateSigningRequest API is promoted to certificates.k8s.io/v1 with the following changes:
+  - `spec.signerName` is now required, and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
+  - `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
+  - `status.conditions` may not contain duplicate types
+  - `status.conditions[*].status` is now required
+  - `status.certificate` must be PEM-encoded, and contain only CERTIFICATE blocks ([#91685](https://github.com/kubernetes/kubernetes/pull/91685), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, Auth, CLI and Testing]
+- The HugePageStorageMediumSize feature gate is now on by default allowing usage of multiple sizes huge page resources on a container level. ([#90592](https://github.com/kubernetes/kubernetes/pull/90592), [@bart0sh](https://github.com/bart0sh)) [SIG Node]
+- The Kubelet's --node-status-max-images option is now available via the Kubelet config file field nodeStatusMaxImage ([#91275](https://github.com/kubernetes/kubernetes/pull/91275), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's --seccomp-profile-root option is now marked as deprecated. ([#91182](https://github.com/kubernetes/kubernetes/pull/91182), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--bootstrap-checkpoint-path` option is now removed. ([#91577](https://github.com/kubernetes/kubernetes/pull/91577), [@knabben](https://github.com/knabben)) [SIG Apps and Node]
+- The Kubelet's `--cloud-provider` and `--cloud-config` options are now marked as deprecated. ([#90408](https://github.com/kubernetes/kubernetes/pull/90408), [@knabben](https://github.com/knabben)) [SIG Cloud Provider and Node]
+- The Kubelet's `--enable-server` and `--provider-id` option is now available via the Kubelet config file field `enableServer` and `providerID` respectively. ([#90494](https://github.com/kubernetes/kubernetes/pull/90494), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--kernel-memcg-notification` option is now available via the Kubelet config file field kernelMemcgNotification ([#91863](https://github.com/kubernetes/kubernetes/pull/91863), [@knabben](https://github.com/knabben)) [SIG Cloud Provider, Node and Testing]
+- The Kubelet's `--really-crash-for-testing` and  `--chaos-chance` options are now marked as deprecated. ([#90499](https://github.com/kubernetes/kubernetes/pull/90499), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--volume-plugin-dir` option is now available via the Kubelet config file field `VolumePluginDir`. ([#88480](https://github.com/kubernetes/kubernetes/pull/88480), [@savitharaghunathan](https://github.com/savitharaghunathan)) [SIG Node]
+- The `DefaultIngressClass` feature is now GA. The `--feature-gate` parameter will be removed in 1.20. ([#91957](https://github.com/kubernetes/kubernetes/pull/91957), [@cmluciano](https://github.com/cmluciano)) [SIG API Machinery, Apps, Network and Testing]
+- The alpha `DynamicAuditing` feature gate and `auditregistration.k8s.io/v1alpha1` API have been removed and are no longer supported. ([#91502](https://github.com/kubernetes/kubernetes/pull/91502), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and Testing]
+- The kube-controller-manager managed signers can now have distinct signing certificates and keys.  See the help about `--cluster-signing-[signer-name]-{cert,key}-file`.  `--cluster-signing-{cert,key}-file` is still the default. ([#90822](https://github.com/kubernetes/kubernetes/pull/90822), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth]
+- The unused `series.state` field, deprecated since v1.14, is removed from the `events.k8s.io/v1beta1` and `v1` Event types. ([#90449](https://github.com/kubernetes/kubernetes/pull/90449), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps]
+- Unreserve extension point for scheduler plugins is merged into Reserve extension point ([#92200](https://github.com/kubernetes/kubernetes/pull/92200), [@adtac](https://github.com/adtac)) [SIG Scheduling and Testing]
+- Update Golang to v1.14.4 ([#88638](https://github.com/kubernetes/kubernetes/pull/88638), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Cloud Provider, Release and Testing]
+- Updated the API documentation for Service.Spec.IPFamily to warn that its exact
+  semantics will probably change before the dual-stack feature goes GA, and users
+  should look at ClusterIP or Endpoints, not IPFamily, to figure out if an existing
+  Service is IPv4, IPv6, or dual-stack. ([#91527](https://github.com/kubernetes/kubernetes/pull/91527), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+- Users can configure a resource prefix to ignore a group of resources. ([#88842](https://github.com/kubernetes/kubernetes/pull/88842), [@angao](https://github.com/angao)) [SIG Node and Scheduling]
+- `Ingress` and `IngressClass` resources have graduated to `networking.k8s.io/v1`. Ingress and IngressClass types in the `extensions/v1beta1` and `networking.k8s.io/v1beta1` API versions are deprecated and will no longer be served in 1.22+. Persisted objects can be accessed via the `networking.k8s.io/v1` API. Notable changes in v1 Ingress objects (v1beta1 field names are unchanged):
+  - `spec.backend` -> `spec.defaultBackend`
+  - `serviceName` -> `service.name`
+  - `servicePort` -> `service.port.name` (for string values)
+  - `servicePort` -> `service.port.number` (for numeric values)
+  - `pathType` no longer has a default value in v1; "Exact", "Prefix", or "ImplementationSpecific" must be specified
+  Other Ingress API updates:
+  - backends can now be resource or service backends
+  - `path` is no longer required to be a valid regular expression ([#89778](https://github.com/kubernetes/kubernetes/pull/89778), [@cmluciano](https://github.com/cmluciano)) [SIG API Machinery, Apps, CLI, Network and Testing]
+- `NodeResourcesLeastAllocated` and `NodeResourcesMostAllocated` plugins now support customized weight on the CPU and memory. ([#90544](https://github.com/kubernetes/kubernetes/pull/90544), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+- `PostFilter` type is added to scheduler component config API on version v1beta1. ([#91547](https://github.com/kubernetes/kubernetes/pull/91547), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- `RequestedToCapacityRatioArgs` encoding is now strict ([#91603](https://github.com/kubernetes/kubernetes/pull/91603), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
+- `v1beta1` Scheduler `Extender` encoding is case-sensitive (`v1alpha1`/`v1alpha2` was case-insensitive), its `httpTimeout` field uses duration encoding (for example, one second is specified as `"1s"`), and the `enableHttps` field in `v1alpha1`/`v1alpha2` was renamed to `enableHTTPS`. ([#91625](https://github.com/kubernetes/kubernetes/pull/91625), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
 
 ### Feature
 
-- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2.  The messages are of the form:`Throttling request took 1.50705208s, request: GET:<URL>` The presence of these messages may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery]
-- Add support for mount options to the FC volume plugin ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG Storage]
-- Added a config-mode flag in azure auth module to enable getting AAD token without spn: prefix in audience claim. When it's not specified, the default behavior doesn't change. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth, CLI and Cloud Provider]
-- Allow for configuration of CoreDNS replica count ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick)) [SIG Cluster Lifecycle]
-- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
-- Apiserver added a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
-- Azure Cloud Provider now supports using Azure network resources (Virtual Network, Load Balancer, Public IP, Route Table, Network Security Group, etc.) in different AAD Tenant and Subscription than those for the Kubernetes cluster. To use the feature, please reference https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md&#35;host-network-resources-in-different-aad-tenant-and-subscription. ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
-- Azure VMSS/VMSSVM clients now suppress requests on throttling ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Azure cloud provider cache TTL is configurable, list of the azure cloud provider is as following:
-  - "availabilitySetNodesCacheTTLInSeconds"
-  - "vmssCacheTTLInSeconds"
-  - "vmssVirtualMachinesCacheTTLInSeconds"
-  - "vmCacheTTLInSeconds"
-  - "loadBalancerCacheTTLInSeconds"
-  - "nsgCacheTTLInSeconds"
-  - "routeTableCacheTTLInSeconds"
-  ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1)) [SIG Cloud Provider]
-- Azure global rate limit is switched to per-client. A set of new rate limit configure options are introduced, including routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit and VirtualMachineSizeRateLimit. The original rate limit options would be default values for those new client's rate limiter. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Azure network and VM clients now suppress requests on throttling ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Azure storage clients now suppress requests on throttling ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
-- DefaultConstraints can be specified for PodTopologySpread Plugin in the scheduler’s ComponentConfig ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- DisableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including control plane nodes) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Elasticsearch supports automatically setting the advertise address ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Instrumentation]
-- EndpointSlices will now be enabled by default. A new `EndpointSliceProxying` feature gate determines if kube-proxy will use EndpointSlices, this is disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) [SIG Network]
-- Kube-proxy: Added dual-stack IPv4/IPv6 support to the iptables proxier. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG Network]
-- Kubeadm now supports automatic calculations of dual-stack node cidr masks to kube-controller-manager. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG Cluster Lifecycle]
-- Kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: add the experimental feature gate PublicKeysECDSA that can be used to create a
-  cluster with ECDSA certificates from "kubeadm init". Renewal of existing ECDSA certificates is also supported using "kubeadm alpha certs renew", but not switching between the RSA and ECDSA algorithms on the fly or during upgrades. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth and Cluster Lifecycle]
-- Kubeadm: implemented structured output of 'kubeadm config images list' command in JSON, YAML, Go template and JsonPath formats ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG Cluster Lifecycle]
-- Kubeadm: on kubeconfig certificate renewal, keep the embedded CA in sync with the one on disk ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows]
-- Kubeadm: support automatic retry after failing to pull image ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm: upgrade supports fallback to the nearest known etcd version if an unknown k8s version is passed ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubectl/drain: add disable-eviction option.Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, and should be used with caution. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI]
-- Kubectl/drain: add skip-wait-for-delete-timeout option. If a pod’s  `DeletionTimestamp` is older than N seconds, skip waiting for the pod.  Seconds must be greater than 0 to skip. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI]
-- Option `preConfiguredBackendPoolLoadBalancerTypes` is added to azure cloud provider for the pre-configured load balancers, possible values: `""`, `"internal"`, `"external"`,`"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion)) [SIG Cloud Provider]
-- PodTopologySpread plugin now excludes terminatingPods when making scheduling decisions. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
-- Provider/azure: Network security groups can now be in a separate resource group. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon)) [SIG Cloud Provider]
-- SafeSysctlWhitelist: add net.ipv4.ping_group_range ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda)) [SIG Auth]
-- Scheduler framework permit plugins now run at the end of the scheduling cycle, after reserve plugins. Waiting on permit will remain in the beginning of the binding cycle. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG Scheduling]
-- Scheduler: Add DefaultBinder plugin ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing]
-- Skip default spreading scoring plugin for pods that define TopologySpreadConstraints ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling]
-- The kubectl --dry-run flag now accepts the values 'client', 'server', and 'none', to support client-side and server-side dry-run strategies. The boolean and unset values for the --dry-run flag are deprecated and a value will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-- Support server-side dry-run in kubectl with --dry-run=server for commands including apply, patch, create, run, annotate, label, set, autoscale, drain, rollout undo, and expose. ([#87714](https://github.com/kubernetes/kubernetes/pull/87714), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, CLI and Testing]
-- Add --dry-run=server|client to kubectl delete, taint, replace ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
-- The feature PodTopologySpread (feature gate `EvenPodsSpread`) has been enabled by default in 1.18. ([#88105](https://github.com/kubernetes/kubernetes/pull/88105), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
-- The kubelet and the default docker runtime now support running ephemeral containers in the Linux process namespace of a target container. Other container runtimes must implement support for this feature before it will be available for that runtime. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG Node]
-- The underlying format of the `CPUManager` state file has changed. Upgrades should be seamless, but any third-party tools that rely on reading the previous format need to be updated. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska)) [SIG Node and Testing]
-- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Cluster Lifecycle, Network, Release and Testing]
-- Webhooks have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing]
-- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing]
-- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- Windows nodes on GCE can use virtual TPM-based authentication to the control plane. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh)) [SIG Cluster Lifecycle]
-- You can now pass "--node-ip ::" to kubelet to indicate that it should autodetect an IPv6 address to use as the node's primary address. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship)) [SIG Cloud Provider, Network and Node]
-- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI]
-- TLS Server Name overrides can now be specified in a kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
-
-#### Metrics:
-- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
-- Added two client certificate metrics for exec auth:
-    - `rest_client_certificate_expiration_seconds` a gauge reporting the lifetime of the current client certificate. Reports the time of expiry in seconds since January 1, 1970 UTC.
-    - `rest_client_certificate_rotation_age` a histogram reporting the age of a just rotated client certificate in seconds. ([#84382](https://github.com/kubernetes/kubernetes/pull/84382), [@sambdavidson](https://github.com/sambdavidson)) [SIG API Machinery, Auth, Cluster Lifecycle and Instrumentation]
-- Controller manager serve workqueue metrics ([#87967](https://github.com/kubernetes/kubernetes/pull/87967), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
-- Following metrics have been turned off:
-  - kubelet_pod_worker_latency_microseconds
-  - kubelet_pod_start_latency_microseconds
-  - kubelet_cgroup_manager_latency_microseconds
-  - kubelet_pod_worker_start_latency_microseconds
-  - kubelet_pleg_relist_latency_microseconds
-  - kubelet_pleg_relist_interval_microseconds
-  - kubelet_eviction_stats_age_microseconds
-  - kubelet_runtime_operations
-  - kubelet_runtime_operations_latency_microseconds
-  - kubelet_runtime_operations_errors
-  - kubelet_device_plugin_registration_count
-  - kubelet_device_plugin_alloc_latency_microseconds
-  - kubelet_docker_operations
-  - kubelet_docker_operations_latency_microseconds
-  - kubelet_docker_operations_errors
-  - kubelet_docker_operations_timeout
-  - network_plugin_operations_latency_microseconds ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango)) [SIG Network and Node]
-- Kube-apiserver metrics will now include request counts, latencies, and response sizes for /healthz, /livez, and /readyz requests. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery]
-- Kubelet now exports a `server_expiration_renew_failure` and `client_expiration_renew_failure` metric counter if the certificate rotations cannot be performed. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node and Release]
-- Kubelet: the metric process_start_time_seconds be marked as with the ALPHA stability level. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Node]
-- New metric `kubelet_pleg_last_seen_seconds` to aid diagnosis of PLEG not healthy issues. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham)) [SIG Node]
-
-### Other (Bug, Cleanup or Flake)
-
-- Fixed a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network]
-- Fixed "kubectl describe statefulsets.apps" printing garbage for rolling update partition ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI]
-- Add a event to PV when filesystem on PV does not match actual filesystem on disk ([#86982](https://github.com/kubernetes/kubernetes/pull/86982), [@gnufied](https://github.com/gnufied)) [SIG Storage]
-- Add azure disk WriteAccelerator support ([#87945](https://github.com/kubernetes/kubernetes/pull/87945), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Add delays between goroutines for vm instance update ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
-- Add init containers log to cluster dump info. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Addons: elasticsearch discovery supports IPv6 ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Instrumentation]
-- Adds "volume.beta.kubernetes.io/migrated-to" annotation to PV's and PVC's when they are migrated to signal external provisioners to pick up those objects for Provisioning and Deleting. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG  Storage]
-- All api-server log request lines in a more greppable format. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp)) [SIG API Machinery]
-- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with sequential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Azure cloud provider now obtains AAD token who audience claim will not have spn: prefix ([#87590](https://github.com/kubernetes/kubernetes/pull/87590), [@weinong](https://github.com/weinong)) [SIG Cloud Provider]
-- AzureFile and CephFS use the new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG Storage]
-- Bind dns-horizontal containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle and Windows]
-- Bind kube-dns containers to linux nodes to avoid Windows scheduling ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle and Windows]
-- Bind metadata-agent containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle, Instrumentation and Windows]
-- Bind metrics-server containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210)) [SIG Cluster Lifecycle, Instrumentation and Windows]
-- Bug fixes: Make sure we include latest packages node &#35;351 (@caseydavenport) ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera)) [SIG Cluster Lifecycle]
-- CPU limits are now respected for Windows containers. If a node is over-provisioned, no weighting is used, only limits are respected. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG Node, Testing and Windows]
-- Changed core_pattern on COS nodes to be an absolute path. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml)) [SIG Cluster Lifecycle and Node]
-- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth]
-- Cloud provider config CloudProviderBackoffMode has been removed since it won't be used anymore. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing]
-- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI]
-- During initialization phase (preflight), kubeadm now verifies the presence of the conntrack executable ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni)) [SIG Cluster Lifecycle]
-- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
-- Evictions due to pods breaching their ephemeral storage limits are now recorded by the `kubelet_evictions` metric and can be alerted on. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node]
-- Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]
-- Fix API Server potential memory leak issue in processing watch request. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
-- Fix EndpointSlice controller race condition and ensure that it handles external changes to EndpointSlices. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
-- Fix IPv6 addresses lost issue in pure ipv6 vsphere environment ([#86001](https://github.com/kubernetes/kubernetes/pull/86001), [@hubv](https://github.com/hubv)) [SIG Cloud Provider]
-- Fix LoadBalancer rule checking so that no unexpected LoadBalancer updates are made ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fix a bug in kube-proxy that caused it to crash when using load balancers with a different IP family ([#87117](https://github.com/kubernetes/kubernetes/pull/87117), [@aojea](https://github.com/aojea)) [SIG Network]
-- Fix a bug in port-forward: named port not working with service ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py)) [SIG CLI]
-- Fix a bug in the dual-stack IPVS proxier where stale IPv6 endpoints were not being cleaned up ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
-- Fix a bug that orphan revision cannot be adopted and statefulset cannot be synced ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli)) [SIG Apps]
-- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network]
-- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
-- Fix a regression in kubenet that prevent pods to obtain ip addresses ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs)) [SIG Network and Node]
-- Fix azure file AuthorizationFailure ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix bug where EndpointSlice controller would attempt to modify shared objects. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps and Network]
-- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider]
-- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
-- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fix issue #85805 about a resource not found in azure cloud provider when LoadBalancer specified in another resource group. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm)) [SIG Cloud Provider]
-- Fix kubectl annotate error when local=true is set ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix `kubectl drain ignore` daemonsets and others. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node]
-- Fix nil pointer dereference in azure cloud provider ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx)) [SIG Cloud Provider]
-- Fix regression in statefulset conversion which prevents applying a statefulset multiple times. ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG Apps and Testing]
-- Fix route conflicted operations when updating multiple routes together ([#88209](https://github.com/kubernetes/kubernetes/pull/88209), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage]
-- Fix the bug PIP's DNS is deleted if no DNS label service annotation isn't set. ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
-- Fix control plane hosts rolling upgrade causing thundering herd of LISTs on etcd leading to control plane unavailability. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Node and Testing]
-- Fix: add azure disk migration support for CSINode ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: add non-retriable errors in azure clients ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fix: add remediation in azure disk attach/detach ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fix: azure data disk should use same key as os disk by default ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fix: azure disk could not mounted on Standard_DC4s/DC2s instances ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: check disk status before disk azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage]
-- Fix: get azure disk lun timeout issue ([#88158](https://github.com/kubernetes/kubernetes/pull/88158), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: update azure disk max count ([#88201](https://github.com/kubernetes/kubernetes/pull/88201), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fixed "requested device X but found Y" attach error on AWS. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane)) [SIG Cloud Provider and Storage]
-- Fixed NetworkPolicy validation that `Except` values are accepted when they are outside the CIDR range. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG Network]
-- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node]
-- Fixed a bug which could prevent a provider ID from ever being set for node if an error occurred determining the provider ID when the node was added. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs)) [SIG Apps and Cloud Provider]
-- Fixed a data race in the kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node]
-- Fixed a panic in the kubelet cleaning up pod volumes ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu)) [SIG Storage]
-- Fixed a regression where the kubelet would fail to update the ready status of pods. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu)) [SIG Node]
-- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node]
-- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
-- Fixed cleaning of CSI raw block volumes. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
-- Fixed AWS Cloud Provider attempting to delete LoadBalancer security group it didn’t provision, and fixed AWS Cloud Provider creating a default LoadBalancer security group even if annotation `service.beta.kubernetes.io/aws-load-balancer-security-groups` is present because the intended behavior of aws-load-balancer-security-groups is to replace all security groups assigned to the load balancer. ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919)) [SIG Cloud Provider]
-- Fixed two scheduler metrics (pending_pods and schedule_attempts_total) not being recorded ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG Scheduling]
-- Fixes an issue with kubelet-reported pod status on deleted/recreated pods. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt)) [SIG Node]
-- Fixes conversion error in multi-version custom resources that could cause metadata.generation to increment on no-op patches or updates of a custom resource. ([#88995](https://github.com/kubernetes/kubernetes/pull/88995), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
-- Fixes issue where AAD token obtained by kubectl is incompatible with on-behalf-of flow and oidc. The audience claim before this fix has "spn:" prefix. After this fix, "spn:" prefix is omitted. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth and Cloud Provider]
-- Fixes an issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage]
-- Fixes kube-proxy when EndpointSlice feature gate is enabled on Windows. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott)) [SIG Auth and Network]
-- Fixes kubelet crash in client certificate rotation cases ([#88079](https://github.com/kubernetes/kubernetes/pull/88079), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Auth and Node]
-- Fixes service account token admission error in clusters that do not run the service account token controller ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- Fixes v1.17.0 regression in --service-cluster-ip-range handling with IPv4 ranges larger than 65536 IP addresses ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt)) [SIG Network]
-- Fixes wrong validation result of NetworkPolicy PolicyTypes ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn)) [SIG Network]
-- For subprotocol negotiation, both client and server protocol is required now. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu)) [SIG API Machinery and Node]
-- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Storage]
-- Garbage collector now can correctly orphan ControllerRevisions when StatefulSets are deleted with orphan propagation policy. ([#84984](https://github.com/kubernetes/kubernetes/pull/84984), [@cofyc](https://github.com/cofyc)) [SIG Apps]
-- `Get-kube.sh` uses the gcloud's current local GCP service account for auth when the provider is GCE or GKE instead of the metadata server default ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG Cluster Lifecycle]
-- Golang/x/net has been updated to bring in fixes for CVE-2020-9283 ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
-- If a serving certificate’s param specifies a name that is an IP for an SNI certificate, it will have priority for replying to server connections. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
-- Improved yaml parsing performance ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
-- Improves performance of the node authorizer ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider]
-- Includes FSType when describing CSI persistent volumes. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca)) [SIG CLI and Storage]
-- Iptables/userspace proxy: improve performance by getting local addresses only once per sync loop, instead of for every external IP ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Network]
-- Kube-aggregator: always sets unavailableGauge metric to reflect the current state of a service. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
-- Kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery]
-- Kube-proxy no longer modifies shared EndpointSlices. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott)) [SIG Network]
-- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network]
-- Kubeadm allows to configure single-stack clusters if dual-stack is enabled ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, Cluster Lifecycle and Network]
-- Kubeadm now includes CoreDNS version 1.6.7 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle]
-- Kubeadm upgrades always persist the etcd backup for stacked ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm:  'kubeadm alpha kubelet config download' has been removed, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm: Forward cluster name to the controller-manager arguments ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle]
-- Kubeadm: add support for the "ci/k8s-master" version label as a replacement for "ci-cross/*", which no longer exists. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu)) [SIG Cluster Lifecycle]
-- Kubeadm: apply further improvements to the tentative support for concurrent etcd member join. Fixes a bug where multiple members can receive the same hostname. Increase the etcd client dial timeout and retry timeout for add/remove/... operations. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: don't write the kubelet environment file on "upgrade apply" ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa)) [SIG Cluster Lifecycle]
-- Kubeadm: fix potential panic when executing "kubeadm reset" with a corrupted kubelet.conf file ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: fix the bug that 'kubeadm upgrade' hangs in single node cluster ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) [SIG Cluster Lifecycle]
-- Kubeadm: remove 'kubeadm upgrade node config' command since it was deprecated in v1.15, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm: remove the deprecated CoreDNS feature-gate. It was set to "true" since v1.11 when the feature went GA. In v1.13 it was marked as deprecated and hidden from the CLI. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: retry `kubeadm-config` ConfigMap creation or mutation if the apiserver is not responding. This will improve resiliency when joining new control plane nodes. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle]
-- Kubeadm: tolerate whitespace when validating certificate authority PEM data in kubeconfig files ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Kubeadm: use bind-address option to configure the kube-controller-manager and kube-scheduler http probes ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle]
-- Kubeadm: uses the api-server AdvertiseAddress IP family to choose the etcd endpoint IP family for non external etcd clusters ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle]
-- Kubectl cluster-info dump --output-directory=xxx now generates files with an extension depending on the output format. ([#82070](https://github.com/kubernetes/kubernetes/pull/82070), [@olivierlemasle](https://github.com/olivierlemasle)) [SIG CLI]
-- `Kubectl describe <type>` and `kubectl top pod` will return a message saying `"No resources found"` or `"No resources found in <namespace> namespace"` if there are no results to display. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- `Kubectl drain node --dry-run` will list pods that would be evicted or deleted ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom)) [SIG CLI]
-- `Kubectl set resources` will no longer return an error if passed an empty change for a resource. `kubectl set subject` will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) [SIG CLI]
-- Kubelet metrics gathered through metrics-server or prometheus should no longer timeout for Windows nodes running more than 3 pods. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG Node, Testing and Windows]
-- Kubelet metrics have been changed to buckets. For example the `exec/{podNamespace}/{podID}/{containerName}` is now just exec. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG Node]
-- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
-- Kubernetes will try to acquire the iptables lock every 100 msec during 5 seconds instead of every second. This is especially useful for environments using kube-proxy in iptables mode with a high churn rate of services. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea)) [SIG Network]
-- Limit number of instances in a single update to GCE target pool to 1000. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability]
-- Make Azure clients only retry on specified HTTP status codes ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Make error message and service event message more clear ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Minimize AWS NLB health check timeout when externalTrafficPolicy set to Local ([#73363](https://github.com/kubernetes/kubernetes/pull/73363), [@kellycampbell](https://github.com/kellycampbell)) [SIG Cloud Provider]
-- Pause image contains "Architecture" in non-amd64 images ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG Release]
-- Pause image upgraded to 3.2 in kubelet and kubeadm. ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder)) [SIG CLI, Cluster Lifecycle, Node and Testing]
-- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Remove `FilteredNodesStatuses` argument from `PreScore`'s interface. ([#88189](https://github.com/kubernetes/kubernetes/pull/88189), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling and Testing]
-- Resolved a performance issue in the node authorizer index maintenance. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- Resolved regression in admission, authentication, and authorization webhook performance in v1.17.0-rc.1 ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
-- Resolves performance regression in `kubectl get all` and in client-go discovery clients constructed using `NewDiscoveryClientForConfig` or `NewDiscoveryClientForConfigOrDie`. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
-- Reverted a kubectl azure auth module change where oidc claim spn: prefix was omitted resulting a breaking behavior with existing Azure AD OIDC enabled api-server ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth and Cloud Provider]
-- Shared informers are now more reliable in the face of network disruption. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery]
-- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
-  Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
-- The CSR signing cert/key pairs will be reloaded from disk like the kube-apiserver cert/key pairs ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth]
-- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery]
-- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth]
-- The sample-apiserver aggregated conformance test has updated to use the Kubernetes v1.17.0 sample apiserver ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, CLI and Testing]
-- To reduce chances of throttling, VM cache is set to nil when Azure node provisioning state is deleting ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- VMSS cache is added so that less chances of VMSS GET throttling ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
-- Wait for kubelet & kube-proxy to be ready on Windows node within 10s ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031)) [SIG Cluster Lifecycle]
-- `kubectl apply  -f <file> --prune -n <namespace>` should prune all resources not defined in the file in the cli specified namespace. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu)) [SIG CLI]
-- `kubectl create clusterrolebinding` creates rbac.authorization.k8s.io/v1 object ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI]
-- `kubectl diff` now returns 1 only on diff finding changes, and >1 on kubectl errors. The "exit status code 1" message has also been muted. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI and Testing]
-
-## Dependencies
-
-- Update Calico to v3.8.4 ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera))[SIG Cluster Lifecycle]
-- Update aws-sdk-go dependency to v1.28.2 ([#87253](https://github.com/kubernetes/kubernetes/pull/87253), [@SaranBalaji90](https://github.com/SaranBalaji90))[SIG API Machinery and Cloud Provider]
-- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus))[SIG Release, Testing, Network, Cluster Lifecycle and API Machinery]
-- Update cri-tools to v1.17.0 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert))[SIG Release and Cluster Lifecycle]
-- Pause image upgraded to 3.2 in kubelet and kubeadm ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, Node, Testing and Cluster Lifecycle]
-- Update CoreDNS version to 1.6.7 in kubeadm ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep))[SIG Cluster Lifecycle]
-- Update golang.org/x/crypto to fix CVE-2020-9283 ([#8838](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, Instrumentation, API Machinery, CLuster Lifecycle and Cloud Provider]
-- Update Go to 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov))[SIG Release and Testing]
-- Update Cluster-Autoscaler to 1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk))[SIG Autoscaling and Cluster Lifecycle]
-
-
-
-# v1.18.0-rc.1
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-rc.1
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes.tar.gz) | `c17231d5de2e0677e8af8259baa11a388625821c79b86362049f2edb366404d6f4b4587b8f13ccbceeb2f32c6a9fe98607f779c0f3e1caec438f002e3a2c8c21`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-src.tar.gz) | `e84ffad57c301f5d6e90f916b996d5abb0c987928c3ca6b1565f7b042588f839b994ca12c43fc36f0ffb63f9fabc15110eb08be253b8939f49cd951e956da618`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-386.tar.gz) | `1aea99923d492436b3eb91aaecffac94e5d0aa2b38a0930d266fda85c665bbc4569745c409aa302247df3b578ce60324e7a489eb26240e97d4e65a67428ea3d1`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-amd64.tar.gz) | `07fa7340a959740bd52b83ff44438bbd988e235277dad1e43f125f08ac85230a24a3b755f4e4c8645743444fa2b66a3602fc445d7da6d2fc3770e8c21ba24b33`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-386.tar.gz) | `48cebd26448fdd47aa36257baa4c716a98fda055bbf6a05230f2a3fe3c1b99b4e483668661415392190f3eebb9cb6e15c784626b48bb2541d93a37902f0e3974`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-amd64.tar.gz) | `c3a5fedf263f07a07f59c01fea6c63c1e0b76ee8dc67c45b6c134255c28ed69171ccc2f91b6a45d6a8ec5570a0a7562e24c33b9d7b0d1a864f4dc04b178b3c04`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm.tar.gz) | `a6b11a55bd38583bbaac14931a6862f8ce6493afe30947ba29e5556654a571593358278df59412bbeb6888fa127e9ae4c0047a9d46cb59394995010796df6b14`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm64.tar.gz) | `9e15331ac8010154a9b64f5488969fc8ee2f21059639896cb84c5cf4f05f4c9d1d8970cb6f9831de6b34013848227c1972c12a698d07aac1ecc056e972fe6f79`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-ppc64le.tar.gz) | `f828fe6252678de9d4822e482f5873309ae9139b2db87298ab3273ce45d38aa07b6b9b42b76c140705f27ba71e101d58b43e59ac7259d7c08dc647ea809e207c`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-s390x.tar.gz) | `19da4b45f0666c063934af616f3e7ed3caa99d4ee1e46d53efadc7a8a4d38e43a36ced7249acd7ad3dcc4b4f60d8451b4f7ec7727e478ee2fadd14d353228bce`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-386.tar.gz) | `775c9afb6cb3e7c4ba53e9f48a5df2cf207234a33059bd74448bc9f177dd120fb3f9c58ab45048a566326acc43bc8a67e886e10ef99f20780c8f63bb17426ebd`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-amd64.tar.gz) | `208d2595a5b57ac97aac75b4a2a6130f0c937f781a030bde1a432daf4bc51f2fa523fca2eb84c38798489c4b536ee90aad22f7be8477985d9691d51ad8e1c4dc`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-amd64.tar.gz) | `dcf832eae04f9f52ff473754ef5cfe697b35f4dc1a282622c94fa10943c8c35f4a8777a0c58c7de871c3c428c8973bf72d6bcd8751416d4c682125268b8fcefe`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm.tar.gz) | `a04e34bea28eb1c8b492e8b1dd3c0dd87ebee71a7dbbef72be10a335e553361af7e48296e504f9844496b04e66350871114d20cfac3f3b49550d8be60f324ba3`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm64.tar.gz) | `a6af086b07a8c2e498f32b43e6511bf6a5e6baf358c572c6910c8df17cd6cae94f562f459714fcead1595767cb14c7f639c5735f1411173bbd38d5604c082a77`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-ppc64le.tar.gz) | `5a960ef5ba0c255f587f2ac0b028cd03136dc91e4efc5d1becab46417852e5524d18572b6f66259531ec6fea997da3c4d162ac153a9439672154375053fec6c7`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-s390x.tar.gz) | `0f32c7d9b14bc238b9a5764d8f00edc4d3bf36bcf06b340b81061424e6070768962425194a8c2025c3a7ffb97b1de551d3ad23d1591ae34dd4e3ba25ab364c33`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-amd64.tar.gz) | `27d8955d535d14f3f4dca501fd27e4f06fad84c6da878ea5332a5c83b6955667f6f731bfacaf5a3a23c09f14caa400f9bee927a0f269f5374de7f79cd1919b3b`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm.tar.gz) | `0d56eccad63ba608335988e90b377fe8ae978b177dc836cdb803a5c99d99e8f3399a666d9477ca9cfe5964944993e85c416aec10a99323e3246141efc0b1cc9e`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm64.tar.gz) | `79bb9be66f9e892d866b28e5cc838245818edb9706981fab6ccbff493181b341c1fcf6fe5d2342120a112eb93af413f5ba191cfba1ab4c4a8b0546a5ad8ec220`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-ppc64le.tar.gz) | `3e9e2c6f9a2747d828069511dce8b4034c773c2d122f005f4508e22518055c1e055268d9d86773bbd26fbd2d887d783f408142c6c2f56ab2f2365236fd4d2635`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-s390x.tar.gz) | `4f96e018c336fa13bb6df6f7217fe46a2b5c47f806f786499c429604ccba2ebe558503ab2c72f63250aa25b61dae2d166e4b80ae10f6ab37d714f87c1dcf6691`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-windows-amd64.tar.gz) | `ab110d76d506746af345e5897ef4f6993d5f53ac818ba69a334f3641047351aa63bfb3582841a9afca51dd0baff8b9010077d9c8ec85d2d69e4172b8d4b338b0`
-
-## Changelog since v1.18.0-beta.2
-
-## Changes by Kind
-
-### API Change
-
-- Removes ConfigMap as suggestion for IngressClass parameters ([#89093](https://github.com/kubernetes/kubernetes/pull/89093), [@robscott](https://github.com/robscott)) [SIG Network]
-
-### Other (Bug, Cleanup or Flake)
-
-- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
-- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network]
-- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
-- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fixed a data race in kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node]
-- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node]
-- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network]
-- Update Cluster Autoscaler to 1.18.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk)) [SIG Autoscaling and Cluster Lifecycle]
-
-
-# v1.18.0-beta.2
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-beta.2
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes.tar.gz) | `3017430ca17f8a3523669b4a02c39cedfc6c48b07281bc0a67a9fbe9d76547b76f09529172cc01984765353a6134a43733b7315e0dff370bba2635dd2a6289af`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-src.tar.gz) | `c5fd60601380a99efff4458b1c9cf4dc02195f6f756b36e590e54dff68f7064daf32cf63980dddee13ef9dec7a60ad4eeb47a288083fdbbeeef4bc038384e9ea`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-386.tar.gz) | `7e49ede167b9271d4171e477fa21d267b2fb35f80869337d5b323198dc12f71b61441975bf925ad6e6cd7b61cbf6372d386417dc1e5c9b3c87ae651021c37237`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | `3f5cdf0e85eee7d0773e0ae2df1c61329dea90e0da92b02dae1ffd101008dc4bade1c4951fc09f0cad306f0bcb7d16da8654334ddee43d5015913cc4ac8f3eda`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-386.tar.gz) | `b67b41c11bfecb88017c33feee21735c56f24cf6f7851b63c752495fc0fb563cd417a67a81f46bca091f74dc00fca1f296e483d2e3dfe2004ea4b42e252d30b9`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | `1fef2197cb80003e3a5c26f05e889af9d85fbbc23e27747944d2997ace4bfa28f3670b13c08f5e26b7e274176b4e2df89c1162aebd8b9506e63b39b311b2d405`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm.tar.gz) | `84e5f4d9776490219ee94a84adccd5dfc7c0362eb330709771afcde95ec83f03d96fe7399eec218e47af0a1e6445e24d95e6f9c66c0882ef8233a09ff2022420`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | `ba613b114e0cca32fa21a3d10f845aa2f215d3af54e775f917ff93919f7dd7075efe254e4047a85a1f4b817fc2bd78006c2e8873885f1208cbc02db99e2e2e25`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | `502a6938d8c4bbe04abbd19b59919d86765058ff72334848be4012cec493e0e7027c6cd950cf501367ac2026eea9f518110cb72d1c792322b396fc2f73d23217`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | `c24700e0ed2ef5c1d2dd282d638c88d90392ae90ea420837b39fd8e1cfc19525017325ccda71d8472fdaea174762208c09e1bba9bbc77c89deef6fac5e847ba2`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-386.tar.gz) | `0d4c5a741b052f790c8b0923c9586ee9906225e51cf4dc8a56fc303d4d61bb5bf77fba9e65151dec7be854ff31da8fc2dcd3214563e1b4b9951e6af4aa643da4`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | `841ef2e306c0c9593f04d9528ee019bf3b667761227d9afc1d6ca8bf1aa5631dc25f5fe13ff329c4bf0c816b971fd0dec808f879721e0f3bf51ce49772b38010`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | `b373df2e6ef55215e712315a5508e85a39126bd81b7b93c6b6305238919a88c740077828a6f19bcd97141951048ef7a19806ef6b1c3e1772dbc45715c5fcb3af`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm.tar.gz) | `b8103cb743c23076ce8dd7c2da01c8dd5a542fbac8480e82dc673139c8ee5ec4495ca33695e7a18dd36412cf1e18ed84c8de05042525ddd8e869fbdfa2766569`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | `8f8f05cf64fb9c8d80cdcb4935b2d3e3edc48bdd303231ae12f93e3f4d979237490744a11e24ba7f52dbb017ca321a8e31624dcffa391b8afda3d02078767fa0`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | `b313b911c46f2ec129537407af3f165f238e48caeb4b9e530783ffa3659304a544ed02bef8ece715c279373b9fb2c781bd4475560e02c4b98a6d79837bc81938`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | `a1b6b06571141f507b12e5ef98efb88f4b6b9aba924722b2a74f11278d29a2972ab8290608360151d124608e6e24da0eb3516d484cb5fa12ff2987562f15964a`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | `20e02ca327543cddb2568ead3d5de164cbfb2914ab6416106d906bf12fcfbc4e55b13bea4d6a515e8feab038e2c929d72c4d6909dfd7881ba69fd1e8c772ab99`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm.tar.gz) | `ecd817ef05d6284f9c6592b84b0a48ea31cf4487030c9fb36518474b2a33dad11b9c852774682e60e4e8b074e6bea7016584ca281dddbe2994da5eaf909025c0`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | `0020d32b7908ffd5055c8b26a8b3033e4702f89efcfffe3f6fcdb8a9921fa8eaaed4193c85597c24afd8c523662454f233521bb7055841a54c182521217ccc9d`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | `e065411d66d486e7793449c1b2f5a412510b913bf7f4e728c0a20e275642b7668957050dc266952cdff09acc391369ae6ac5230184db89af6823ba400745f2fc`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | `082ee90413beaaea41d6cbe9a18f7d783a95852607f3b94190e0ca12aacdd97d87e233b87117871bfb7d0a4b6302fbc7688549492a9bc50a2f43a5452504d3ce`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | `fb5aca0cc36be703f9d4033eababd581bac5de8399c50594db087a99ed4cb56e4920e960eb81d0132d696d094729254eeda2a5c0cb6e65e3abca6c8d61da579e`
-
-## Changelog since v1.18.0-beta.1
-
-## Urgent Upgrade Notes
-
-### (No, really, you MUST read this before you upgrade)
-
-- `kubectl` no longer defaults to `http://localhost:8080`.  If you own one of these legacy clusters, you are *strongly- encouraged to secure your server.   If you cannot secure your server, you can set `KUBERNETES_MASTER` if you were relying on that behavior and you're a client-go user. Set `--server`, `--kubeconfig` or `KUBECONFIG` to make it work in `kubectl`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
-
-## Changes by Kind
-
-### Deprecation
-
-- AlgorithmSource is removed from v1alpha2 Scheduler ComponentConfig ([#87999](https://github.com/kubernetes/kubernetes/pull/87999), [@damemi](https://github.com/damemi)) [SIG Scheduling]
-- Kube-proxy: deprecate `--healthz-port` and `--metrics-port` flag, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
-- Kubeadm: deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-
-### API Change
-
-- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing]
-- Added GenericPVCDataSource feature gate to enable using arbitrary custom resources as the data source for a PVC. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage]
-- Allow user to specify fsgroup permission change policy for pods ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage]
-- BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage]
-- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
-- Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network]
-- Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network]
-- Ingress: Add alternate backends via TypedLocalObjectReference ([#88775](https://github.com/kubernetes/kubernetes/pull/88775), [@cmluciano](https://github.com/cmluciano)) [SIG Apps and Network]
-- Ingress: allow wildcard hosts in IngressRule ([#88858](https://github.com/kubernetes/kubernetes/pull/88858), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
-- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver.  Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling]
-- Move TaintBasedEvictions feature gates to GA ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing]
-- New flag --endpointslice-updates-batch-period in kube-controller-manager can be used to reduce number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network]
-- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
-- The apiserver/v1alph1&#35;EgressSelectorConfiguration API is now beta. ([#88502](https://github.com/kubernetes/kubernetes/pull/88502), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery]
-- The storage.k8s.io/CSIDriver has moved to GA, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, Apps, Auth, Node, Scheduling, Storage and Testing]
-- VolumePVCDataSource moves to GA in 1.18 release ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Apps, CLI and Cluster Lifecycle]
-
-### Feature
-
-- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
-- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
-- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver.
-  After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect.
-  The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
-  Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
-- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
-- DefaultConstraints can be specified for the PodTopologySpread plugin in the component config ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows]
-- Kubectl cluster-info dump changed to only display a message telling you the location where the output was written when the output is not standard output. ([#88765](https://github.com/kubernetes/kubernetes/pull/88765), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- Print NotReady when pod is not ready based on its conditions. ([#88240](https://github.com/kubernetes/kubernetes/pull/88240), [@soltysh](https://github.com/soltysh)) [SIG CLI]
-- Scheduler Extender API is now located under k8s.io/kube-scheduler/extender ([#88540](https://github.com/kubernetes/kubernetes/pull/88540), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
-- Signatures on scale client methods have been modified to accept `context.Context` as a first argument. Signatures of Get, Update, and Patch methods have been updated to accept GetOptions, UpdateOptions and PatchOptions respectively. ([#88599](https://github.com/kubernetes/kubernetes/pull/88599), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, Apps, Autoscaling and CLI]
-- Signatures on the dynamic client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88906](https://github.com/kubernetes/kubernetes/pull/88906), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, CLI, Cluster Lifecycle, Storage and Testing]
-- Signatures on the metadata client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88910](https://github.com/kubernetes/kubernetes/pull/88910), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing]
-- Webhooks will have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing]
-- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing]
-- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI]
+- A defaultpreemption plugin is registered and enabled in scheduler which replaces the legacy hard-coded Pod preemption logic. ([#92049](https://github.com/kubernetes/kubernetes/pull/92049), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- A new extension point `PostFilter` is introduced to scheduler framework which runs after Filter phase to resolve scheduling filter failures. A typical implementation is running preemption logic. ([#91314](https://github.com/kubernetes/kubernetes/pull/91314), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- ACTION REQUIRED : In CoreDNS v1.7.0, [metrics names have been changed](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md&#35;metric-changes) which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading. 
+  
+  Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include:
+  -  Fixed a bug that could cause CoreDNS to stop updating service records.
+  -  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
+  -  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
+  -  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
+  -  The federation plugin (allows for v1 Kubernetes federation) has been removed.
+  More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92651](https://github.com/kubernetes/kubernetes/pull/92651), [@rajansandeep](https://github.com/rajansandeep)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- API requests to deprecated versions now receive a warning header in the API response, and cause a metric indicating use of a deprecated API to be published:
+  - `kubectl` outputs warnings to stderr, and accepts a `--warnings-as-errors` option to treat warnings as fatal errors
+  - `k8s.io/client-go` outputs warnings to stderr by default; override this per-client by setting `config.WarningHandler`, or per-process with `rest.SetDefaultWarningHandler()`
+  - `kube-apiserver` publishes `apiserver_requested_deprecated_apis` gauge metrics set to `1` for deprecated APIs which have been requested, with `group`, `version`, `resource`, `subresource`, and `removed_release` labels ([#73032](https://github.com/kubernetes/kubernetes/pull/73032), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, CLI, Instrumentation and Testing]
+- Add --logging-format flag for component-base. Defaults to "text" using unchanged klog. ([#89683](https://github.com/kubernetes/kubernetes/pull/89683), [@yuzhiquan](https://github.com/yuzhiquan)) [SIG Instrumentation]
+- Add --port flag to kubectl create deployment ([#91113](https://github.com/kubernetes/kubernetes/pull/91113), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
+- Add .import-restrictions file to cmd/cloud-controller-manager. ([#90630](https://github.com/kubernetes/kubernetes/pull/90630), [@nilo19](https://github.com/nilo19)) [SIG API Machinery and Cloud Provider]
+- Add Annotations to CRI-API ImageSpec objects. ([#90061](https://github.com/kubernetes/kubernetes/pull/90061), [@marosset](https://github.com/marosset)) [SIG Node and Windows]
+- Add attempts label to scheduler's PodSchedulingDuration metric. ([#92650](https://github.com/kubernetes/kubernetes/pull/92650), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
+- Add client-side and server-side dry-run support to kubectl scale ([#89666](https://github.com/kubernetes/kubernetes/pull/89666), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Add selectors to kubectl diff ([#90857](https://github.com/kubernetes/kubernetes/pull/90857), [@sethpollack](https://github.com/sethpollack)) [SIG CLI]
+- Add support for cgroups v2 node validation ([#89901](https://github.com/kubernetes/kubernetes/pull/89901), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle and Node]
+- Add support for pre allocated huge pages with different sizes, on node level ([#89252](https://github.com/kubernetes/kubernetes/pull/89252), [@odinuge](https://github.com/odinuge)) [SIG Apps and Node]
+- Add tags support for Azure File Driver ([#92825](https://github.com/kubernetes/kubernetes/pull/92825), [@ZeroMagic](https://github.com/ZeroMagic)) [SIG Cloud Provider and Storage]
+- Add tags support for azure disk driver ([#92356](https://github.com/kubernetes/kubernetes/pull/92356), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Added --privileged flag to kubectl run ([#90569](https://github.com/kubernetes/kubernetes/pull/90569), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- Added a new `GetPreferredAllocation()` call to the `v1beta1` device plugin API. ([#92665](https://github.com/kubernetes/kubernetes/pull/92665), [@klueska](https://github.com/klueska)) [SIG Node and Testing]
+- Added feature support to Windows for configuring session affinity of Kubernetes services.
+  required: [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) (or higher) ([#91701](https://github.com/kubernetes/kubernetes/pull/91701), [@elweb9858](https://github.com/elweb9858)) [SIG Network and Windows]
+- Added kube-apiserver metrics: apiserver_current_inflight_request_measures and, when API Priority and Fairness is enable, windowed_request_stats. ([#91177](https://github.com/kubernetes/kubernetes/pull/91177), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery, Instrumentation and Testing]
+- Added service.beta.kubernetes.io/aws-load-balancer-target-node-labels annotation to target nodes in AWS LoadBalancer Services ([#90943](https://github.com/kubernetes/kubernetes/pull/90943), [@foobarfran](https://github.com/foobarfran)) [SIG Cloud Provider]
+- Adding a set of debugging endpoints under prefix "/debug/flowcontrol/*" for dumping internal states of flow-control system with different granularity. ([#90967](https://github.com/kubernetes/kubernetes/pull/90967), [@yue9944882](https://github.com/yue9944882)) [SIG API Machinery]
+- Adds profile label to kube-scheduler metric framework_extension_point_duration_seconds ([#92268](https://github.com/kubernetes/kubernetes/pull/92268), [@alculquicondor](https://github.com/alculquicondor)) [SIG Instrumentation and Scheduling]
+- Adds profile label to kube-scheduler metric schedule_attempts_total
+  - Adds result and profile label to e2e_scheduling_duration_seconds. Times for unschedulable and error attempts are now recorded. ([#92202](https://github.com/kubernetes/kubernetes/pull/92202), [@alculquicondor](https://github.com/alculquicondor)) [SIG Instrumentation and Scheduling]
+- Audit events for API requests to deprecated API versions now include a `"k8s.io/deprecated": "true"` audit annotation. If a target removal release is identified, the audit event includes a `"k8s.io/removal-release": "<majorVersion>.<minorVersion>"` audit annotation as well. ([#92842](https://github.com/kubernetes/kubernetes/pull/92842), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Instrumentation]
+- Bump Dashboard to v2.0.1 ([#91526](https://github.com/kubernetes/kubernetes/pull/91526), [@maciaszczykm](https://github.com/maciaszczykm)) [SIG Cloud Provider]
+- Cloud node-controller use InstancesV2 ([#91319](https://github.com/kubernetes/kubernetes/pull/91319), [@gongguan](https://github.com/gongguan)) [SIG Apps, Cloud Provider, Scalability and Storage]
+- Deps: Update to Golang 1.13.9
+  - build: Remove kube-cross image building ([#89275](https://github.com/kubernetes/kubernetes/pull/89275), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Detailed scheduler scoring result can be printed at verbose level 10. ([#89384](https://github.com/kubernetes/kubernetes/pull/89384), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- E2e.test can print the list of conformance tests that need to pass for the cluster to be conformant. ([#88924](https://github.com/kubernetes/kubernetes/pull/88924), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+- Enable feature Gate DefaultPodTopologySpread to use PodTopologySpread plugin to do defaultspreading. In doing so, legacy DefaultPodTopologySpread plugin is disabled. ([#91793](https://github.com/kubernetes/kubernetes/pull/91793), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- EndpointSlice controller waits longer to retry failed sync. ([#89438](https://github.com/kubernetes/kubernetes/pull/89438), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- Extend AWS azToRegion method to support Local Zones ([#90874](https://github.com/kubernetes/kubernetes/pull/90874), [@Jeffwan](https://github.com/Jeffwan)) [SIG Cloud Provider]
+- Feat: add azure shared disk support ([#89511](https://github.com/kubernetes/kubernetes/pull/89511), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Feat: change azure disk api-version ([#89250](https://github.com/kubernetes/kubernetes/pull/89250), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Feat: support [Azure shared disk](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-shared-enable), added a new field(`maxShares`) in azure disk storage class:
+  
+  kind: StorageClass
+  apiVersion: storage.k8s.io/v1
+  metadata:
+    name: shared-disk
+  provisioner: kubernetes.io/azure-disk
+  parameters:
+    skuname: Premium_LRS  &#35; Currently only available with premium SSDs.
+    cachingMode: None  &#35; ReadOnly host caching is not available for premium SSDs with maxShares>1
+    maxShares: 2 ([#89328](https://github.com/kubernetes/kubernetes/pull/89328), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Improves IPVS proxy performance by only running `EnsureDummyInterface` if the virtual server address is not binded already. ([#92609](https://github.com/kubernetes/kubernetes/pull/92609), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
+- Kube-Proxy now supports EndpointSlices on Windows with the EndpointSliceProxying feature gate. ([#90909](https://github.com/kubernetes/kubernetes/pull/90909), [@kumarvin123](https://github.com/kumarvin123)) [SIG Network and Windows]
+- Kube-Proxy now supports IPv6DualStack on Windows with the IPv6DualStack feature gate. ([#90853](https://github.com/kubernetes/kubernetes/pull/90853), [@kumarvin123](https://github.com/kumarvin123)) [SIG Network, Node and Windows]
+- Kube-addon-manager has been updated to v9.1.1 to allow overriding the default list of whitelisted resources (https://github.com/kubernetes/kubernetes/pull/91018) ([#91240](https://github.com/kubernetes/kubernetes/pull/91240), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing]
+- Kube-apiserver backed by etcd3 exports metric showing the database file size. ([#89151](https://github.com/kubernetes/kubernetes/pull/89151), [@jingyih](https://github.com/jingyih)) [SIG API Machinery]
+- Kube-apiserver, kube-scheduler and kube-controller manager now use SO_REUSEPORT socket option when listening on address defined by --bind-address and --secure-port flags, when running on Unix systems (Windows is NOT supported). This allows to run multiple instances of those processes on a single host with the same configuration, which allows to update/restart them in a graceful way, without causing downtime. ([#88893](https://github.com/kubernetes/kubernetes/pull/88893), [@invidian](https://github.com/invidian)) [SIG API Machinery, Scheduling and Testing]
+- Kube-apiserver: The NodeRestriction admission plugin now restricts Node labels kubelets are permitted to set when creating a new Node to the `--node-labels` parameters accepted by kubelets in 1.16+. ([#90307](https://github.com/kubernetes/kubernetes/pull/90307), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Kube-controller-manager: add '--logging-format' flag to support structured logging ([#91521](https://github.com/kubernetes/kubernetes/pull/91521), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery and Instrumentation]
+- Kube-controller-manager: the `--experimental-cluster-signing-duration` flag is marked as deprecated for removal in v1.22, and is replaced with `--cluster-signing-duration`. ([#91154](https://github.com/kubernetes/kubernetes/pull/91154), [@liggitt](https://github.com/liggitt)) [SIG Auth and Cloud Provider]
+- Kube-proxy now consumes EndpointSlices instead of Endpoints by default on Linux. A new alpha `WindowsEndpointSliceProxying` feature gate allows the feature to be enabled on Windows. ([#92736](https://github.com/kubernetes/kubernetes/pull/92736), [@robscott](https://github.com/robscott)) [SIG Network]
+- Kube-scheduler: add '--logging-format' flag to support structured logging ([#91522](https://github.com/kubernetes/kubernetes/pull/91522), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Scheduling]
+- Kubeadm now distinguishes between generated and user supplied component configs, regenerating the former ones if a config upgrade is required ([#86070](https://github.com/kubernetes/kubernetes/pull/86070), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: Allow manually upgraded component configs to be supplied in a YAML file via the --config option during upgrade plan & apply. The old behavior of --config in which kubeadm configuration and component configs that overwrite everything cluster stored is preserved too. The behavior to use with --config is now determined based on whether kubeadm config API objects (API group "kubeadm.kubernetes.io") were supplied in the file or not. ([#91980](https://github.com/kubernetes/kubernetes/pull/91980), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: add startup probes for static Pods to protect slow starting containers ([#91179](https://github.com/kubernetes/kubernetes/pull/91179), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: deprecate the "--csr-only" and "--csr-dir" flags of the "kubeadm init phase certs" subcommands. Please use "kubeadm alpha certs generate-csr" instead. This new command allows you to generate new private keys and certificate signing requests for all the control-plane components, so that the certificates can be signed by an external CA. ([#92183](https://github.com/kubernetes/kubernetes/pull/92183), [@wallrj](https://github.com/wallrj)) [SIG Cluster Lifecycle]
+- Kubeadm: during 'upgrade apply', if the kube-proxy ConfigMap is missing, assume that kube-proxy should not be upgraded. Same applies to a missing kube-dns/coredns ConfigMap for the DNS server addon. Note that this is a temporary workaround until 'upgrade apply' supports phases. Once phases are supported the kube-proxy/dns upgrade should be skipped manually. ([#89593](https://github.com/kubernetes/kubernetes/pull/89593), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: switch control-plane static Pods to the "system-node-critical" priority class ([#90063](https://github.com/kubernetes/kubernetes/pull/90063), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: upgrade plan now prints a table indicating the state of known component configs prior to upgrade ([#88124](https://github.com/kubernetes/kubernetes/pull/88124), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubectl supports taint no without specifying(without having to type the full resource name) ([#88723](https://github.com/kubernetes/kubernetes/pull/88723), [@wawa0210](https://github.com/wawa0210)) [SIG CLI]
+- Kubelet: following metrics have been renamed:
+  kubelet_running_container_count --> kubelet_running_containers
+  kubelet_running_pod_count --> kubelet_running_pods ([#92407](https://github.com/kubernetes/kubernetes/pull/92407), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Node]
+- Kubelets configured to rotate client certificates now publish a `certificate_manager_server_ttl_seconds` gauge metric indicating the remaining seconds until certificate expiration. ([#91148](https://github.com/kubernetes/kubernetes/pull/91148), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- New scoring for PodTopologySpreading that yields better spreading ([#90475](https://github.com/kubernetes/kubernetes/pull/90475), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- No actions required. This is a small enhancement to a utility library. ([#92440](https://github.com/kubernetes/kubernetes/pull/92440), [@luigibk](https://github.com/luigibk)) [SIG Network]
+- PodTolerationRestriction: Mention Whitelist Scope in Error ([#87582](https://github.com/kubernetes/kubernetes/pull/87582), [@mrueg](https://github.com/mrueg)) [SIG Scheduling]
+- Provider-specific Notes: vsphere: vsphere.conf - new option to disable credentials secret management for performance concerns ([#90836](https://github.com/kubernetes/kubernetes/pull/90836), [@Danil-Grigorev](https://github.com/Danil-Grigorev)) [SIG Cloud Provider]
+- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
+- Rest.Config now supports a flag to override proxy configuration that was previously only configurable through environment variables. ([#81443](https://github.com/kubernetes/kubernetes/pull/81443), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery and Node]
+- Scores from PodTopologySpreading have reduced differentiation as maxSkew increases. ([#90820](https://github.com/kubernetes/kubernetes/pull/90820), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
+- Service controller: only sync LB node pools when relevant fields in Node changes ([#90769](https://github.com/kubernetes/kubernetes/pull/90769), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+- Set CSIMigrationvSphere feature gates to beta.
+  Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
+  
+  Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15 ([#92816](https://github.com/kubernetes/kubernetes/pull/92816), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider and Storage]
+- Support `kubectl create deployment` with replicas ([#91562](https://github.com/kubernetes/kubernetes/pull/91562), [@zhouya0](https://github.com/zhouya0))
+- Support a smooth upgrade from client-side apply to server-side apply without conflicts, as well as support the corresponding downgrade. ([#90187](https://github.com/kubernetes/kubernetes/pull/90187), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery and Testing]
+- Support create or update VMSS asynchronously. ([#89248](https://github.com/kubernetes/kubernetes/pull/89248), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
+- Support for running on a host that uses cgroups v2 unified mode ([#85218](https://github.com/kubernetes/kubernetes/pull/85218), [@giuseppe](https://github.com/giuseppe)) [SIG Node]
+- Switch core master base images (kube-apiserver, kube-scheduler) from debian to distroless ([#90674](https://github.com/kubernetes/kubernetes/pull/90674), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release and Scalability]
+- Switch etcd image (with migration scripts) from debian to distroless ([#91171](https://github.com/kubernetes/kubernetes/pull/91171), [@dims](https://github.com/dims)) [SIG API Machinery and Cloud Provider]
+- The RotateKubeletClientCertificate feature gate has been promoted to GA, and the kubelet --feature-gate RotateKubeletClientCertificate parameter will be removed in 1.20. ([#91780](https://github.com/kubernetes/kubernetes/pull/91780), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- The SCTPSupport feature is now active by default. ([#88932](https://github.com/kubernetes/kubernetes/pull/88932), [@janosi](https://github.com/janosi)) [SIG Network]
+- The `certificatesigningrequests/approval` subresource now supports patch API requests ([#91558](https://github.com/kubernetes/kubernetes/pull/91558), [@liggitt](https://github.com/liggitt)) [SIG Auth and Testing]
+- The metric label name of `kubernetes_build_info` has been updated from `camel case` to `snake case`:
+  - gitVersion --> git_version
+  - gitCommit --> git_commit
+  - gitTreeState --> git_tree_state
+  - buildDate --> build_date
+  - goVersion --> go_version
+  
+  This change happens in `kube-apiserver`、`kube-scheduler`、`kube-proxy` and `kube-controller-manager`. ([#91805](https://github.com/kubernetes/kubernetes/pull/91805), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
+- Trace output in apiserver logs is more organized and comprehensive. Traces are nested, and for all non-long running request endpoints, the entire filter chain is instrumented (e.g. authentication check is included). ([#88936](https://github.com/kubernetes/kubernetes/pull/88936), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Scheduling]
+- Try to send watch bookmarks (if requested) periodically in addition to sending them right before timeout ([#90560](https://github.com/kubernetes/kubernetes/pull/90560), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- Update cri-tools to v1.18.0 ([#89720](https://github.com/kubernetes/kubernetes/pull/89720), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cloud Provider, Cluster Lifecycle, Release and Scalability]
+- Update etcd client side to v3.4.4 ([#89169](https://github.com/kubernetes/kubernetes/pull/89169), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider]
+- Update etcd client side to v3.4.7 ([#89822](https://github.com/kubernetes/kubernetes/pull/89822), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider]
+- Update etcd client side to v3.4.9 ([#92075](https://github.com/kubernetes/kubernetes/pull/92075), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider and Instrumentation]
+- Upgrade to azure-sdk v40.2.0 ([#89105](https://github.com/kubernetes/kubernetes/pull/89105), [@andyzhangx](https://github.com/andyzhangx)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Storage and Testing]
+- Warn users that `kubectl port-forward` does not support UDP now ([#91616](https://github.com/kubernetes/kubernetes/pull/91616), [@knight42](https://github.com/knight42)) [SIG CLI]
+- Weight of PodTopologySpread scheduling Score is doubled. ([#91258](https://github.com/kubernetes/kubernetes/pull/91258), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- `EventRecorder()` is exposed to `FrameworkHandle` interface so that scheduler plugin developers can choose to log cluster-level events. ([#92010](https://github.com/kubernetes/kubernetes/pull/92010), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- `kubectl alpha debug` command now supports debugging pods by copy the original one. ([#90094](https://github.com/kubernetes/kubernetes/pull/90094), [@aylei](https://github.com/aylei)) [SIG CLI]
+- `kubectl alpha debug` now supports debugging nodes by creating a debugging container running in the node's host namespaces. ([#92310](https://github.com/kubernetes/kubernetes/pull/92310), [@verb](https://github.com/verb)) [SIG CLI]
+- `local-up-cluster.sh` installs CSI snapshotter by default now, can be disabled with `ENABLE_CSI_SNAPSHOTTER=false`. ([#91504](https://github.com/kubernetes/kubernetes/pull/91504), [@pohly](https://github.com/pohly))
+- `maxThreshold` of `ImageLocality` plugin is now scaled by the number of images in the pod, which helps to distinguish the node priorities for pod with several images. ([#91138](https://github.com/kubernetes/kubernetes/pull/91138), [@chendave](https://github.com/chendave)) [SIG Scheduling]
 
 ### Documentation
 
-- Update Japanese translation for kubectl help ([#86837](https://github.com/kubernetes/kubernetes/pull/86837), [@inductor](https://github.com/inductor)) [SIG CLI and Docs]
-- `kubectl plugin` now prints a note how to install krew ([#88577](https://github.com/kubernetes/kubernetes/pull/88577), [@corneliusweig](https://github.com/corneliusweig)) [SIG CLI]
+- Updated the instructions for deploying the sample app. ([#82785](https://github.com/kubernetes/kubernetes/pull/82785), [@ashish-billore](https://github.com/ashish-billore)) [SIG API Machinery]
 
-### Other (Bug, Cleanup or Flake)
+### Failing Test
 
-- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with squential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- AzureFile and CephFS use new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
-- Build: Enable kube-cross image-building on K8s Infra ([#88562](https://github.com/kubernetes/kubernetes/pull/88562), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
-- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth]
-- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing]
-- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI]
-- FIX: prevent apiserver from panicking when failing to load audit webhook config file ([#88879](https://github.com/kubernetes/kubernetes/pull/88879), [@JoshVanL](https://github.com/JoshVanL)) [SIG API Machinery and Auth]
-- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]
-- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
-- Fix describe ingress annotations not sorted. ([#88394](https://github.com/kubernetes/kubernetes/pull/88394), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider]
-- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node]
-- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage]
-- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage]
-- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node]
-- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Node and Storage]
-- Fixes issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage]
-- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Apps, Node and Storage]
-- Hide kubectl.kubernetes.io/last-applied-configuration in describe command ([#88758](https://github.com/kubernetes/kubernetes/pull/88758), [@soltysh](https://github.com/soltysh)) [SIG Auth and CLI]
-- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider]
-- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
-- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
+- Kube-proxy iptables min-sync-period defaults to 1 sec. Previously, it was 0. ([#92836](https://github.com/kubernetes/kubernetes/pull/92836), [@aojea](https://github.com/aojea)) [SIG Network]
 
-  Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
-- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
-- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery]
-- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth]
-- Update to use golang 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Release and Testing]
-- Validate kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout ([#88657](https://github.com/kubernetes/kubernetes/pull/88657), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
+### Bug or Regression
+
+- A PV set from in-tree source will have ordered requirement values in NodeAffinity when converted to CSIPersistentVolumeSource ([#88987](https://github.com/kubernetes/kubernetes/pull/88987), [@jiahuif](https://github.com/jiahuif)) [SIG Storage]
+- A panic in the apiserver caused by the `informer-sync` health checker is now fixed. ([#93600](https://github.com/kubernetes/kubernetes/pull/93600), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery]
+- An issue preventing GCP cloud-controller-manager running out-of-cluster to initialize new Nodes is now fixed. ([#90057](https://github.com/kubernetes/kubernetes/pull/90057), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Apps and Cloud Provider]
+- Avoid GCE API calls when initializing GCE CloudProvider for Kubelets. ([#90218](https://github.com/kubernetes/kubernetes/pull/90218), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider and Scalability]
+- Avoid unnecessary GCE API calls when adding IP alises or reflecting them in Node object in GCE cloud provider. ([#90242](https://github.com/kubernetes/kubernetes/pull/90242), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, Cloud Provider and Network]
+- Avoid unnecessary scheduling churn when annotations are updated while Pods are being scheduled. ([#90373](https://github.com/kubernetes/kubernetes/pull/90373), [@fabiokung](https://github.com/fabiokung)) [SIG Scheduling]
+- Azure auth module for kubectl now requests login after refresh token expires. ([#86481](https://github.com/kubernetes/kubernetes/pull/86481), [@tdihp](https://github.com/tdihp)) [SIG API Machinery and Auth]
+- Azure: fix concurreny issue in lb creation ([#89604](https://github.com/kubernetes/kubernetes/pull/89604), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Azure: set dest prefix and port for IPv6 inbound security rule ([#91831](https://github.com/kubernetes/kubernetes/pull/91831), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Base-images: Update to kube-cross:v1.13.9-5 ([#90963](https://github.com/kubernetes/kubernetes/pull/90963), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Bug fix for AWS NLB service when nodePort for existing servicePort changed manually. ([#89562](https://github.com/kubernetes/kubernetes/pull/89562), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- CSINode initialization does not crash kubelet on startup when APIServer is not reachable or kubelet has not the right credentials yet. ([#89589](https://github.com/kubernetes/kubernetes/pull/89589), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- CVE-2020-8557 (Medium): Node-local denial of service via container /etc/hosts file. See https://github.com/kubernetes/kubernetes/issues/93032 for more details. ([#92916](https://github.com/kubernetes/kubernetes/pull/92916), [@joelsmith](https://github.com/joelsmith)) [SIG Node]
+- Client-go: resolves an issue with informers falling back to full list requests when timeouts are encountered, rather than re-establishing a watch. ([#89652](https://github.com/kubernetes/kubernetes/pull/89652), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- CloudNodeLifecycleController will check node existence status before shutdown status when monitoring nodes. ([#90737](https://github.com/kubernetes/kubernetes/pull/90737), [@jiahuif](https://github.com/jiahuif)) [SIG Apps and Cloud Provider]
+- Containers which specify a `startupProbe` but not a `readinessProbe` were previously considered "ready" before the `startupProbe` completed, but are now considered "not-ready". ([#92196](https://github.com/kubernetes/kubernetes/pull/92196), [@thockin](https://github.com/thockin)) [SIG Node]
+- Cordoned nodes are now deregistered from AWS target groups. ([#85920](https://github.com/kubernetes/kubernetes/pull/85920), [@hoelzro](https://github.com/hoelzro)) [SIG Cloud Provider]
+- Do not add nodes labeled with kubernetes.azure.com/managed=false to backend pool of load balancer. ([#93034](https://github.com/kubernetes/kubernetes/pull/93034), [@matthias50](https://github.com/matthias50)) [SIG Cloud Provider]
+- Do not retry volume expansion if CSI driver returns FailedPrecondition error ([#92986](https://github.com/kubernetes/kubernetes/pull/92986), [@gnufied](https://github.com/gnufied)) [SIG Node and Storage]
+- Dockershim security: pod sandbox now always run with `no-new-privileges` and `runtime/default` seccomp profile
+  dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90948](https://github.com/kubernetes/kubernetes/pull/90948), [@pjbgf](https://github.com/pjbgf)) [SIG Node]
+- Dual-stack: fix the bug that Service clusterIP does not respect specified ipFamily ([#89612](https://github.com/kubernetes/kubernetes/pull/89612), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
+- EndpointSliceMirroring controller now copies labels from Endpoints to EndpointSlices. ([#93442](https://github.com/kubernetes/kubernetes/pull/93442), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- Ensure Azure availability zone is always in lower cases. ([#89722](https://github.com/kubernetes/kubernetes/pull/89722), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Eviction requests for pods that have a non-zero DeletionTimestamp will always succeed ([#91342](https://github.com/kubernetes/kubernetes/pull/91342), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps]
+- Explain CRDs whose resource name are the same as builtin objects ([#89505](https://github.com/kubernetes/kubernetes/pull/89505), [@knight42](https://github.com/knight42)) [SIG API Machinery, CLI and Testing]
+- Extend kube-apiserver /readyz with new "informer-sync" check ensuring that internal informers are synced. ([#92644](https://github.com/kubernetes/kubernetes/pull/92644), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing]
+- Extended DSR loadbalancer feature in winkernel kube-proxy to HNS versions 9.3-9.max, 10.2+ ([#93080](https://github.com/kubernetes/kubernetes/pull/93080), [@elweb9858](https://github.com/elweb9858)) [SIG Network]
+- First pod with required affinity terms can schedule only on nodes with matching topology keys. ([#91168](https://github.com/kubernetes/kubernetes/pull/91168), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- Fix AWS Loadbalancer VPC CIDR calculation when CIDR in disassociated state exists. ([#92227](https://github.com/kubernetes/kubernetes/pull/92227), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- Fix InstanceMetadataByProviderID for unmanaged nodes ([#92572](https://github.com/kubernetes/kubernetes/pull/92572), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix `VirtualMachineScaleSets.virtualMachines.GET` not allowed issues when customers have set VMSS orchestrationMode. ([#91097](https://github.com/kubernetes/kubernetes/pull/91097), [@feiskyer](https://github.com/feiskyer))
+- Fix a bug that didn't allow to use IPv6 addresses with leading zeros ([#89341](https://github.com/kubernetes/kubernetes/pull/89341), [@aojea](https://github.com/aojea)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#90537](https://github.com/kubernetes/kubernetes/pull/90537), [@freehan](https://github.com/freehan)) [SIG Network]
+- Fix a condition when expiring nil VM entry in VMSS cache ([#92681](https://github.com/kubernetes/kubernetes/pull/92681), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
+- Fix a racing issue where the scheduler may perform unnecessary scheduling attempts. ([#90660](https://github.com/kubernetes/kubernetes/pull/90660), [@Huang-Wei](https://github.com/Huang-Wei))
+- Fix an issue with container restarts using a modified configmap or secret subpath volume mount. ([#89629](https://github.com/kubernetes/kubernetes/pull/89629), [@fatedier](https://github.com/fatedier)) [SIG Architecture, Storage and Testing]
+- Fix bug in the port allocation logic that caused that the NodePort creation with statically assigned portNumber collide in multi-master HA cluster ([#89937](https://github.com/kubernetes/kubernetes/pull/89937), [@aojea](https://github.com/aojea)) [SIG Network and Testing]
+- Fix bug with xfs_repair from stopping xfs mount ([#89444](https://github.com/kubernetes/kubernetes/pull/89444), [@gnufied](https://github.com/gnufied)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Fix clusterdump info namespaces flag not working ([#91890](https://github.com/kubernetes/kubernetes/pull/91890), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix detection of SystemOOMs in which the victim is a container. ([#88871](https://github.com/kubernetes/kubernetes/pull/88871), [@dashpole](https://github.com/dashpole)) [SIG Node]
+- Fix detection of image filesystem, disk metrics for devicemapper, detection of OOM Kills on 5.0+ linux kernels. ([#92919](https://github.com/kubernetes/kubernetes/pull/92919), [@dashpole](https://github.com/dashpole)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
+- Fix etcd version migration script in etcd image. ([#91925](https://github.com/kubernetes/kubernetes/pull/91925), [@wenjiaswe](https://github.com/wenjiaswe)) [SIG API Machinery]
+- Fix flaws in Azure File CSI translation ([#90162](https://github.com/kubernetes/kubernetes/pull/90162), [@rfranzke](https://github.com/rfranzke)) [SIG Release and Storage]
+- Fix instance not found issues when an Azure Node is recreated in a short time ([#93316](https://github.com/kubernetes/kubernetes/pull/93316), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix issues when supported huge page sizes changes ([#80831](https://github.com/kubernetes/kubernetes/pull/80831), [@odinuge](https://github.com/odinuge)) [SIG Node and Testing]
+- Fix kube-apiserver startup to wait for APIServices to be installed into the HTTP handler before reporting readiness. ([#89147](https://github.com/kubernetes/kubernetes/pull/89147), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- Fix kubectl create --dryrun client ignores namespace ([#90502](https://github.com/kubernetes/kubernetes/pull/90502), [@zhouya0](https://github.com/zhouya0))
+- Fix kubectl create secret docker-registry --from-file not usable ([#90960](https://github.com/kubernetes/kubernetes/pull/90960), [@zhouya0](https://github.com/zhouya0)) [SIG CLI and Testing]
+- Fix kubectl describe CSINode nil pointer error ([#89646](https://github.com/kubernetes/kubernetes/pull/89646), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix kubectl describe node for users not having access to lease information. ([#90469](https://github.com/kubernetes/kubernetes/pull/90469), [@uthark](https://github.com/uthark)) [SIG CLI]
+- Fix kubectl describe output format for empty annotations. ([#91405](https://github.com/kubernetes/kubernetes/pull/91405), [@iyashu](https://github.com/iyashu)) [SIG CLI]
+- Fix kubectl diff so it doesn't actually persist patches ([#89795](https://github.com/kubernetes/kubernetes/pull/89795), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Fix kubectl run  --dry-run client  ignore namespace ([#90785](https://github.com/kubernetes/kubernetes/pull/90785), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix kubectl version should print version info without config file ([#89913](https://github.com/kubernetes/kubernetes/pull/89913), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery and CLI]
+- Fix missing `-c` shorthand for `--container` flag of `kubectl alpha debug` ([#89674](https://github.com/kubernetes/kubernetes/pull/89674), [@superbrothers](https://github.com/superbrothers)) [SIG CLI]
+- Fix printers ignoring object average value ([#89142](https://github.com/kubernetes/kubernetes/pull/89142), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery]
+- Fix public IP not shown issues after assigning public IP to Azure VMs ([#90886](https://github.com/kubernetes/kubernetes/pull/90886), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix scheduler crash when removing node before its pods ([#89908](https://github.com/kubernetes/kubernetes/pull/89908), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Fix the VMSS name and resource group name when updating Azure VMSS for LoadBalancer backendPools ([#89337](https://github.com/kubernetes/kubernetes/pull/89337), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix throttling issues when Azure VM computer name prefix is different from VMSS name ([#92793](https://github.com/kubernetes/kubernetes/pull/92793), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix: Azure deallocating node should be regarded as shut down ([#92257](https://github.com/kubernetes/kubernetes/pull/92257), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: GetLabelsForVolume panic issue for azure disk PV ([#92166](https://github.com/kubernetes/kubernetes/pull/92166), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: add azure file migration support on annotation support ([#91093](https://github.com/kubernetes/kubernetes/pull/91093), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Node]
+- Fix: azure disk dangling attach issue which would cause API throttling ([#90749](https://github.com/kubernetes/kubernetes/pull/90749), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: determine the correct ip config based on ip family ([#93043](https://github.com/kubernetes/kubernetes/pull/93043), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Fix: don't use docker config cache if it's empty ([#92330](https://github.com/kubernetes/kubernetes/pull/92330), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: fix topology issue in azure disk storage class migration ([#91196](https://github.com/kubernetes/kubernetes/pull/91196), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: get attach disk error due to missing item in max count table ([#89768](https://github.com/kubernetes/kubernetes/pull/89768), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fix: incorrect max azure disk max count ([#92331](https://github.com/kubernetes/kubernetes/pull/92331), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fix: initial delay in mounting azure disk & file ([#93052](https://github.com/kubernetes/kubernetes/pull/93052), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fix: support removal of nodes backed by deleted non VMSS instances on Azure ([#91184](https://github.com/kubernetes/kubernetes/pull/91184), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Fix: use force detach for azure disk ([#91948](https://github.com/kubernetes/kubernetes/pull/91948), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fixed a 1.18 regression in wait.Forever that skips the backoff period on the first repeat ([#90476](https://github.com/kubernetes/kubernetes/pull/90476), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
+- Fixed a bug that mistake use newObj as oldObj in endpoint slice update. ([#92339](https://github.com/kubernetes/kubernetes/pull/92339), [@fatkun](https://github.com/fatkun)) [SIG Apps and Network]
+- Fixed a bug where executing a kubectl command with a jsonpath output expression that has a nested range would ignore expressions following the nested range. ([#88464](https://github.com/kubernetes/kubernetes/pull/88464), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery]
+- Fixed a bug whereby the allocation of reusable CPUs and devices was not being honored when the TopologyManager was enabled ([#93189](https://github.com/kubernetes/kubernetes/pull/93189), [@klueska](https://github.com/klueska)) [SIG Node]
+- Fixed a performance issue applying json patches to deeply nested objects ([#92069](https://github.com/kubernetes/kubernetes/pull/92069), [@tapih](https://github.com/tapih)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fixed a regression preventing garbage collection of RBAC role and binding objects ([#90534](https://github.com/kubernetes/kubernetes/pull/90534), [@apelisse](https://github.com/apelisse)) [SIG Auth]
+- Fixed a regression running kubectl commands with  --local or --dry-run flags when no kubeconfig file is present ([#90243](https://github.com/kubernetes/kubernetes/pull/90243), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
+- Fixed ambiguous behavior when bearer token (kubectl --token=..) and an exec credential plugin was configured in the same context - the bearer token now takes precedence. ([#91745](https://github.com/kubernetes/kubernetes/pull/91745), [@anderseknert](https://github.com/anderseknert)) [SIG API Machinery, Auth and Testing]
+- Fixed an issue mounting credentials for service accounts whose name contains `.` characters ([#89696](https://github.com/kubernetes/kubernetes/pull/89696), [@nabokihms](https://github.com/nabokihms)) [SIG Auth]
+- Fixed an issue that a Pod's nominatedNodeName cannot be cleared upon node deletion. ([#91750](https://github.com/kubernetes/kubernetes/pull/91750), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Fixed bug where a nonzero exit code was returned when initializing zsh completion even though zsh completion was successfully initialized ([#88165](https://github.com/kubernetes/kubernetes/pull/88165), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- Fixed memory leak in endpointSliceTracker ([#92838](https://github.com/kubernetes/kubernetes/pull/92838), [@tnqn](https://github.com/tnqn)) [SIG Apps and Network]
+- Fixed mountOptions in iSCSI and FibreChannel volume plugins. ([#89172](https://github.com/kubernetes/kubernetes/pull/89172), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Fixed node data lost in kube-scheduler for clusters with imbalance on number of nodes across zones ([#93355](https://github.com/kubernetes/kubernetes/pull/93355), [@maelk](https://github.com/maelk))
+- Fixed several bugs involving the IPFamily field when creating or updating services
+  in clusters with the IPv6DualStack feature gate enabled.
+  
+  Beware that the behavior of the IPFamily field is strange and inconsistent and will
+  likely be changed before the dual-stack feature goes GA. Users should treat the
+  field as "write-only" for now and should not make any assumptions about a service
+  based on its current IPFamily value. ([#91400](https://github.com/kubernetes/kubernetes/pull/91400), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+- Fixed the EndpointSlice controller to run without error on a cluster with the OwnerReferencesPermissionEnforcement validating admission plugin enabled. ([#89741](https://github.com/kubernetes/kubernetes/pull/89741), [@marun](https://github.com/marun)) [SIG Auth and Network]
+- Fixed the EndpointSliceController to correctly create endpoints for IPv6-only pods.
+  
+  Fixed the EndpointController to allow IPv6 headless services, if the IPv6DualStack
+  feature gate is enabled, by specifying `ipFamily: IPv6` on the service. (This already
+  worked with the EndpointSliceController.) ([#91399](https://github.com/kubernetes/kubernetes/pull/91399), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+- Fixed using of a read-only iSCSI volume in multiple pods. ([#91738](https://github.com/kubernetes/kubernetes/pull/91738), [@jsafrane](https://github.com/jsafrane)) [SIG Storage and Testing]
+- Fixes CSI volume attachment scaling issue by using informers. ([#91307](https://github.com/kubernetes/kubernetes/pull/91307), [@yuga711](https://github.com/yuga711)) [SIG API Machinery, Apps, Node, Storage and Testing]
+- Fixes a bug defining a default value for a replicas field in a custom resource definition that has the scale subresource enabled ([#89833](https://github.com/kubernetes/kubernetes/pull/89833), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fixes a bug that non directory hostpath type can be recognized as HostPathFile and adds e2e tests for HostPathType ([#64829](https://github.com/kubernetes/kubernetes/pull/64829), [@dixudx](https://github.com/dixudx)) [SIG Apps, Storage and Testing]
+- Fixes a problem with 63-second or 1-second connection delays with some VXLAN-based
+  network plugins which was first widely noticed in 1.16 (though some users saw it
+  earlier than that, possibly only with specific network plugins). If you were previously
+  using ethtool to disable checksum offload on your primary network interface, you should
+  now be able to stop doing that. ([#92035](https://github.com/kubernetes/kubernetes/pull/92035), [@danwinship](https://github.com/danwinship)) [SIG Network and Node]
+- Fixes a regression in 1.17 that dropped cache-control headers on API requests ([#90468](https://github.com/kubernetes/kubernetes/pull/90468), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- Fixes conversion error for HorizontalPodAutoscaler objects with invalid annotations ([#89963](https://github.com/kubernetes/kubernetes/pull/89963), [@liggitt](https://github.com/liggitt)) [SIG Autoscaling]
+- Fixes kubectl to apply all validly built objects, instead of stopping on error. ([#89848](https://github.com/kubernetes/kubernetes/pull/89848), [@seans3](https://github.com/seans3)) [SIG CLI and Testing]
+- Fixes regression in CPUManager that caused freeing of exclusive CPUs at incorrect times ([#90377](https://github.com/kubernetes/kubernetes/pull/90377), [@cbf123](https://github.com/cbf123)) [SIG Cloud Provider and Node]
+- Fixes regression in CPUManager that had the (rare) possibility to release exclusive CPUs in app containers inherited from init containers. ([#90419](https://github.com/kubernetes/kubernetes/pull/90419), [@klueska](https://github.com/klueska)) [SIG Node]
+- Fixes v1.18.0-rc.1 regression in `kubectl port-forward` when specifying a local and remote port ([#89401](https://github.com/kubernetes/kubernetes/pull/89401), [@liggitt](https://github.com/liggitt))
+- Fixing race condition with EndpointSlice controller garbage collection. ([#91311](https://github.com/kubernetes/kubernetes/pull/91311), [@robscott](https://github.com/robscott)) [SIG Apps, Network and Testing]
+- For GCE cluster provider, fix bug of not being able to create internal type load balancer for clusters with more than 1000 nodes in a single zone. ([#89902](https://github.com/kubernetes/kubernetes/pull/89902), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability]
+- For external storage e2e test suite, update external driver, to pick snapshot provisioner from VolumeSnapshotClass, when a VolumeSnapshotClass is explicitly provided as an input. ([#90878](https://github.com/kubernetes/kubernetes/pull/90878), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing]
+- Get-kube.sh: fix order to get the binaries from the right bucket ([#91635](https://github.com/kubernetes/kubernetes/pull/91635), [@cpanato](https://github.com/cpanato)) [SIG Release]
+- If firstTimestamp is not set use eventTime when printing event ([#89999](https://github.com/kubernetes/kubernetes/pull/89999), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- If we set parameter cgroupPerQos=false and cgroupRoot=/docker，this function will retrun  nodeAllocatableRoot=/docker/kubepods, it is not right, the correct return should be /docker.
+  cm.NodeAllocatableRoot(s.CgroupRoot, s.CgroupDriver)
+  
+  kubeDeps.CAdvisorInterface, err = cadvisor.New(imageFsInfoProvider, s.RootDirectory, cgroupRoots, cadvisor.UsingLegacyCadvisorStats(s.ContainerRuntime, s.RemoteRuntimeEndpoint))
+  the above funtion，as we use cgroupRoots to create cadvisor interface，the wrong parameter cgroupRoots will lead eviction manager not  to collect metric from /docker, then kubelet frequently print those error：
+  E0303 17:25:03.436781 63839 summary_sys_containers.go:47] Failed to get system container stats for "/docker": failed to get cgroup stats for "/docker": failed to get container info for "/docker": unknown container "/docker"
+  E0303 17:25:03.436809 63839 helpers.go:680] eviction manager: failed to construct signal: "allocatableMemory.available" error: system container "pods" not found in metrics ([#88970](https://github.com/kubernetes/kubernetes/pull/88970), [@mysunshine92](https://github.com/mysunshine92)) [SIG Node]
+- In a HA env, during the period a standby scheduler lost connection to API server, if a Pod is deleted and recreated, and the standby scheduler becomes master afterwards, there could be a scheduler cache corruption. This PR fixes this issue. ([#91126](https://github.com/kubernetes/kubernetes/pull/91126), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- In the kubelet resource metrics endpoint at /metrics/resource, change the names of the following metrics:
+  - node_cpu_usage_seconds --> node_cpu_usage_seconds_total
+  - container_cpu_usage_seconds --> container_cpu_usage_seconds_total
+  This is a partial revert of &#35;86282, which was added in 1.18.0, and initially removed the _total suffix ([#89540](https://github.com/kubernetes/kubernetes/pull/89540), [@dashpole](https://github.com/dashpole)) [SIG Instrumentation and Node]
+- Ipvs: only attempt setting of sysctlconnreuse on supported kernels ([#88541](https://github.com/kubernetes/kubernetes/pull/88541), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
+- Jsonpath support in kubectl / client-go serializes complex types (maps / slices / structs) as json instead of Go-syntax. ([#89660](https://github.com/kubernetes/kubernetes/pull/89660), [@pjferrell](https://github.com/pjferrell)) [SIG API Machinery, CLI and Cluster Lifecycle]
+- Kube-aggregator certificates are dynamically loaded on change from disk ([#92791](https://github.com/kubernetes/kubernetes/pull/92791), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
+- Kube-apiserver: fixes scale subresource patch handling to avoid returning unnecessary 409 Conflict error to clients ([#90342](https://github.com/kubernetes/kubernetes/pull/90342), [@liggitt](https://github.com/liggitt)) [SIG Apps, Autoscaling and Testing]
+- Kube-apiserver: jsonpath expressions with consecutive recursive descent operators are no longer evaluated for custom resource printer columns ([#93408](https://github.com/kubernetes/kubernetes/pull/93408), [@joelsmith](https://github.com/joelsmith)) [SIG API Machinery]
+- Kube-apiserver: multiple comma-separated protocols in a single X-Stream-Protocol-Version header are now recognized, in addition to multiple headers, complying with RFC2616 ([#89857](https://github.com/kubernetes/kubernetes/pull/89857), [@tedyu](https://github.com/tedyu)) [SIG API Machinery]
+- Kube-proxy IP family will be determined by the nodeIP used by the proxier. The order of precedence is:
+  1. the configured --bind-address if the bind address is not 0.0.0.0 or ::
+  2. the primary IP from the Node object, if set.
+  3. if no IP is found, NodeIP defaults to 127.0.0.1 and the IP family to IPv4 ([#91725](https://github.com/kubernetes/kubernetes/pull/91725), [@aojea](https://github.com/aojea)) [SIG Network]
+- Kube-proxy, in dual-stack mode, infers the service IP family from the ClusterIP instead of using the `Service.Spec.IPFamily` field ([#91357](https://github.com/kubernetes/kubernetes/pull/91357), [@aojea](https://github.com/aojea))
+- Kube-up now includes CoreDNS version v1.7.0. Some of the major changes include:
+  -  Fixed a bug that could cause CoreDNS to stop updating service records.
+  -  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
+  -  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
+  -  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
+  -  The federation plugin (allows for v1 Kubernetes federation) has been removed.
+  More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92718](https://github.com/kubernetes/kubernetes/pull/92718), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cloud Provider]
+- Kube-up: fixes setup of validating admission webhook credential configuration ([#91995](https://github.com/kubernetes/kubernetes/pull/91995), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Cluster Lifecycle]
+- Kubeadm increased to 5 minutes its timeout for the TLS bootstrapping process to complete upon join ([#89735](https://github.com/kubernetes/kubernetes/pull/89735), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: Add retries for kubeadm join / UpdateStatus to make update status more resilient by adding a retry loop to this operation ([#91952](https://github.com/kubernetes/kubernetes/pull/91952), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- Kubeadm: add the deprecated flag --port=0 to kube-controller-manager and kube-scheduler manifests to disable insecure serving. Without this flag the components by default serve (e.g. /metrics) insecurely on the default node interface (controlled by --address). Users that wish to override this behavior and enable insecure serving can pass a custom --port=X via kubeadm's "extraArgs" mechanic for these components. ([#92720](https://github.com/kubernetes/kubernetes/pull/92720), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: during "join", don't re-add an etcd member if it already exists in the cluster. ([#92118](https://github.com/kubernetes/kubernetes/pull/92118), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: during "reset" do not remove the only remaining stacked etcd member from the cluster and just proceed with the cleanup of the local etcd storage. ([#91145](https://github.com/kubernetes/kubernetes/pull/91145), [@tnqn](https://github.com/tnqn)) [SIG Cluster Lifecycle]
+- Kubeadm: during join when a check is performed that a Node with the same name already exists in the cluster, make sure the NodeReady condition is properly validated ([#89602](https://github.com/kubernetes/kubernetes/pull/89602), [@kvaps](https://github.com/kvaps)) [SIG Cluster Lifecycle]
+- Kubeadm: ensure `image-pull-timeout` flag is respected during upgrade phase ([#90328](https://github.com/kubernetes/kubernetes/pull/90328), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: fix a bug where post upgrade to 1.18.x, nodes cannot join the cluster due to missing RBAC ([#89537](https://github.com/kubernetes/kubernetes/pull/89537), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: fix misleading warning about passing control-plane related flags on 'kubeadm join' ([#89596](https://github.com/kubernetes/kubernetes/pull/89596), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: increase robustness for "kubeadm join" when adding etcd members on slower setups ([#90645](https://github.com/kubernetes/kubernetes/pull/90645), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: remove duplicate DNS names and IP addresses from generated certificates ([#92753](https://github.com/kubernetes/kubernetes/pull/92753), [@QianChenglong](https://github.com/QianChenglong)) [SIG Cluster Lifecycle]
+- Kubectl azure authentication: fixed a regression in 1.18.0 where "spn:" prefix was unexpectedly added to the `apiserver-id` configuration in the kubeconfig file ([#89706](https://github.com/kubernetes/kubernetes/pull/89706), [@weinong](https://github.com/weinong)) [SIG API Machinery and Auth]
+- Kubectl: fix the bug that kubectl autoscale does not honor '--name' flag ([#91855](https://github.com/kubernetes/kubernetes/pull/91855), [@SataQiu](https://github.com/SataQiu)) [SIG CLI]
+- Kubectl: fix the bug that kubectl scale does not honor '--timeout' flag ([#91858](https://github.com/kubernetes/kubernetes/pull/91858), [@SataQiu](https://github.com/SataQiu)) [SIG CLI]
+- Kubelet: fix the bug that kubelet help information can not show the right type of flags ([#88515](https://github.com/kubernetes/kubernetes/pull/88515), [@SataQiu](https://github.com/SataQiu)) [SIG Docs and Node]
+- Kuberuntime security: pod sandbox now always runs with `runtime/default` seccomp profile
+  kuberuntime seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90949](https://github.com/kubernetes/kubernetes/pull/90949), [@pjbgf](https://github.com/pjbgf)) [SIG Node]
+- Make Kubelet bootstrap certificate signal aware ([#92786](https://github.com/kubernetes/kubernetes/pull/92786), [@answer1991](https://github.com/answer1991)) [SIG API Machinery, Auth and Node]
+- Node ([#89677](https://github.com/kubernetes/kubernetes/pull/89677), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- On AWS nodes with multiple network interfaces, kubelet should now more reliably report addresses from secondary interfaces. ([#91889](https://github.com/kubernetes/kubernetes/pull/91889), [@anguslees](https://github.com/anguslees)) [SIG Cloud Provider]
+- Pod Conditions updates are skipped for re-scheduling attempts ([#91252](https://github.com/kubernetes/kubernetes/pull/91252), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Pods can now be considered for preemption after a previously nominated node has become unschedulable and unresolvable. ([#92604](https://github.com/kubernetes/kubernetes/pull/92604), [@soulxu](https://github.com/soulxu))
+- Prevent PVC requested size overflow when expanding or creating a volume ([#90907](https://github.com/kubernetes/kubernetes/pull/90907), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage]
+- Provides a fix to allow a cluster in a private Azure cloud to authenticate to ACR in the same cloud. ([#90425](https://github.com/kubernetes/kubernetes/pull/90425), [@DavidParks8](https://github.com/DavidParks8)) [SIG Cloud Provider]
+- Refine aws loadbalancer worker node SG rule logic to be deterministic ([#92224](https://github.com/kubernetes/kubernetes/pull/92224), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- Resolve regression in metadata.managedFields handling in create/update/patch requests not using server-side apply ([#91690](https://github.com/kubernetes/kubernetes/pull/91690), [@apelisse](https://github.com/apelisse)) [SIG API Machinery and Testing]
+- Resolved a regression in v1.18.0-rc.1 mounting windows volumes ([#89319](https://github.com/kubernetes/kubernetes/pull/89319), [@mboersma](https://github.com/mboersma)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Resolves an issue using `kubectl certificate approve/deny` against a server serving the v1 CSR API ([#91691](https://github.com/kubernetes/kubernetes/pull/91691), [@liggitt](https://github.com/liggitt)) [SIG Auth and CLI]
+- Restore the ability to `kubectl apply --prune` without --namespace flag.  Since 1.17, `kubectl apply --prune` only prunes resources in the default namespace (or from kubeconfig) or explicitly specified in command line flag.  But this is s breaking change from kubectl 1.16, which can prune resources in all namespace in config file.  This patch restores the kubectl 1.16 behaviour. ([#89551](https://github.com/kubernetes/kubernetes/pull/89551), [@tatsuhiro-t](https://github.com/tatsuhiro-t)) [SIG CLI and Testing]
+- Restores priority of static control plane pods in the cluster/gce/manifests control-plane manifests ([#89970](https://github.com/kubernetes/kubernetes/pull/89970), [@liggitt](https://github.com/liggitt)) [SIG Cluster Lifecycle and Node]
+- Reverted devicemanager for Windows node added in 1.19rc1. ([#93263](https://github.com/kubernetes/kubernetes/pull/93263), [@liggitt](https://github.com/liggitt)) [SIG Node and Windows]
+- Scheduler v1 Policy config or algorithm-provider settings can now be passed alongside v1beta1 ComponentConfig to aid transition from Policy to CC ([#92531](https://github.com/kubernetes/kubernetes/pull/92531), [@damemi](https://github.com/damemi)) [SIG Scheduling]
+- Scheduling failures due to no nodes available are now reported as unschedulable under ```schedule_attempts_total``` metric. ([#90989](https://github.com/kubernetes/kubernetes/pull/90989), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- Service account tokens bound to pods can now be used during the pod deletion grace period. ([#89583](https://github.com/kubernetes/kubernetes/pull/89583), [@liggitt](https://github.com/liggitt)) [SIG Auth]
+- Service load balancers no longer exclude nodes marked unschedulable from the candidate nodes. The service load balancer exclusion label should be used instead.
+  
+  Users upgrading from 1.18 who have cordoned nodes should set the `node.kubernetes.io/exclude-from-external-load-balancers` label on the impacted nodes before upgrading if they wish those nodes to remain excluded from service load balancers. ([#90823](https://github.com/kubernetes/kubernetes/pull/90823), [@smarterclayton](https://github.com/smarterclayton)) [SIG Apps, Cloud Provider and Network]
+- Support kubectl annotate --list option ([#92576](https://github.com/kubernetes/kubernetes/pull/92576), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Sync LB backend nodes for Service `Type=LoadBalancer` on Add/Delete node events. ([#81185](https://github.com/kubernetes/kubernetes/pull/81185), [@andrewsykim](https://github.com/andrewsykim))
+- The following components that do not expect non-empty, non-flag arguments will now print an error message and exit if an argument is specified: cloud-controller-manager, kube-apiserver, kube-controller-manager, kube-proxy, kubeadm {alpha|config|token|version}, kubemark. Flags should be prefixed with a single dash "-" (0x45) for short form or double dash "--" for long form. Before this change, malformed flags (for example, starting with a non-ascii dash character such as 0x8211: "–") would have been silently treated as positional arguments and ignored. ([#91349](https://github.com/kubernetes/kubernetes/pull/91349), [@neolit123](https://github.com/neolit123)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle, Network and Scheduling]
+- The terminationGracePeriodSeconds from pod spec is respected for the mirror pod. ([#92442](https://github.com/kubernetes/kubernetes/pull/92442), [@tedyu](https://github.com/tedyu)) [SIG Node and Testing]
+- Update github.com/moby/ipvs to v1.0.1 to fix IPVS compatibility issue with older kernels ([#90555](https://github.com/kubernetes/kubernetes/pull/90555), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
+- Updates to pod status via the status subresource now validate that `status.podIP` and `status.podIPs` fields are well-formed. ([#90628](https://github.com/kubernetes/kubernetes/pull/90628), [@liggitt](https://github.com/liggitt)) [SIG Apps and Node]
+- Wait for all CRDs to show up in discovery endpoint before reporting readiness. ([#89145](https://github.com/kubernetes/kubernetes/pull/89145), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- When evicting, Pods in Pending state are removed without checking PDBs. ([#83906](https://github.com/kubernetes/kubernetes/pull/83906), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery, Apps, Node and Scheduling]
+- [security] Vulnerability in golang.org/x/text/encoding/unicode ([#92219](https://github.com/kubernetes/kubernetes/pull/92219), [@voor](https://github.com/voor)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
+
+### Other (Cleanup or Flake)
+
+- --cache-dir sets cache directory for both http and discovery, defaults to $HOME/.kube/cache ([#92910](https://github.com/kubernetes/kubernetes/pull/92910), [@soltysh](https://github.com/soltysh)) [SIG API Machinery and CLI]
+- Add `pod.Namespace` to the image log ([#91945](https://github.com/kubernetes/kubernetes/pull/91945), [@zhipengzuo](https://github.com/zhipengzuo))
+- Add the ability to disable kubeconfig file lock through DISABLE_KUBECONFIG_LOCK env var ([#92513](https://github.com/kubernetes/kubernetes/pull/92513), [@soltysh](https://github.com/soltysh)) [SIG API Machinery and CLI]
+- Adds additional testing to ensure that udp pods conntrack are cleaned up ([#90180](https://github.com/kubernetes/kubernetes/pull/90180), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Architecture, Network and Testing]
+- Adjusts the fsType for cinder values to be `ext4` if no fsType is specified. ([#90608](https://github.com/kubernetes/kubernetes/pull/90608), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
+- Base-images: Use debian-base:v2.1.0 ([#90697](https://github.com/kubernetes/kubernetes/pull/90697), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery and Release]
+- Base-images: Use debian-iptables:v12.1.0 ([#90782](https://github.com/kubernetes/kubernetes/pull/90782), [@justaugustus](https://github.com/justaugustus)) [SIG Release]
+- Beta.kubernetes.io/arch is already deprecated since v1.14, are targeted for removal in v1.18 ([#89462](https://github.com/kubernetes/kubernetes/pull/89462), [@wawa0210](https://github.com/wawa0210)) [SIG Testing]
+- Build: Update to debian-base@v2.1.2 and debian-iptables@v12.1.1 ([#93667](https://github.com/kubernetes/kubernetes/pull/93667), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing]
+- Change beta.kubernetes.io/os  to kubernetes.io/os ([#89460](https://github.com/kubernetes/kubernetes/pull/89460), [@wawa0210](https://github.com/wawa0210)) [SIG Testing and Windows]
+- Change beta.kubernetes.io/os to kubernetes.io/os ([#89461](https://github.com/kubernetes/kubernetes/pull/89461), [@wawa0210](https://github.com/wawa0210)) [SIG Cloud Provider and Cluster Lifecycle]
+- Changes not found message when using `kubectl get` to retrieve not namespaced resources ([#89861](https://github.com/kubernetes/kubernetes/pull/89861), [@rccrdpccl](https://github.com/rccrdpccl)) [SIG CLI]
+- CoreDNS will no longer be supporting Federation data translation for kube-dns ConfigMap ([#92716](https://github.com/kubernetes/kubernetes/pull/92716), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle]
+- Deprecate kubectl top flags related to heapster
+  Drop support of heapster in kubectl top ([#87498](https://github.com/kubernetes/kubernetes/pull/87498), [@serathius](https://github.com/serathius)) [SIG CLI]
+- Deprecate the `--target-ram-md` flags that is no longer used for anything. ([#91818](https://github.com/kubernetes/kubernetes/pull/91818), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- Drop some conformance tests that rely on Kubelet API directly ([#90615](https://github.com/kubernetes/kubernetes/pull/90615), [@dims](https://github.com/dims)) [SIG Architecture, Network, Release and Testing]
+- Emit `WaitingForPodScheduled` event if the unbound PVC is in delay binding mode but used by a pod ([#91455](https://github.com/kubernetes/kubernetes/pull/91455), [@cofyc](https://github.com/cofyc)) [SIG Storage]
+- Fix: license issue in blob disk feature ([#92824](https://github.com/kubernetes/kubernetes/pull/92824), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Improve server-side apply conflict errors by setting dedicated kubectl subcommand field managers ([#88885](https://github.com/kubernetes/kubernetes/pull/88885), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- IsFullyQualifiedDomainName() validates each label based on IsDNS1123Label. ([#90172](https://github.com/kubernetes/kubernetes/pull/90172), [@nak3](https://github.com/nak3)) [SIG API Machinery and Network]
+- It is now possible to use the service annotation `cloud.google.com/network-tier: Standard` to configure the Network Tier of the GCE Loadbalancer ([#88532](https://github.com/kubernetes/kubernetes/pull/88532), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider, Network and Testing]
+- Kube-aggregator: renames aggregator_unavailable_apiservice_count metric to aggregator_unavailable_apiservice_total ([#88156](https://github.com/kubernetes/kubernetes/pull/88156), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
+- Kube-apiserver: openapi schemas published for custom resources now reference standard ListMeta schema definitions ([#92546](https://github.com/kubernetes/kubernetes/pull/92546), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- Kube-proxy exposes a new metric, `kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds`, that indicates the last time a change for kube-proxy was queued to be applied. ([#90175](https://github.com/kubernetes/kubernetes/pull/90175), [@squeed](https://github.com/squeed)) [SIG Instrumentation and Network]
+- Kube-scheduler: The metric name `scheduler_total_preemption_attempts` has been renamed to `scheduler_preemption_attempts_total`. ([#91448](https://github.com/kubernetes/kubernetes/pull/91448), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Scheduling]
+- Kube-up: defaults to limiting critical pods to the kube-system namespace to match behavior prior to 1.17 ([#93121](https://github.com/kubernetes/kubernetes/pull/93121), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Scheduling]
+- Kubeadm now forwards the IPv6DualStack feature gate using the kubelet component config, instead of the kubelet command line ([#90840](https://github.com/kubernetes/kubernetes/pull/90840), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: do not use a DaemonSet for the pre-pull of control-plane images during "kubeadm upgrade apply". Individual node upgrades now pull the required images using a preflight check. The flag "--image-pull-timeout" for "kubeadm upgrade apply" is now deprecated and will be removed in a future release following a GA deprecation policy. ([#90788](https://github.com/kubernetes/kubernetes/pull/90788), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- Kubeadm: use two separate checks on /livez and /readyz for the kube-apiserver static Pod instead of using /healthz ([#90970](https://github.com/kubernetes/kubernetes/pull/90970), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+- NONE ([#91597](https://github.com/kubernetes/kubernetes/pull/91597), [@elmiko](https://github.com/elmiko)) [SIG Autoscaling and Testing]
+- Openapi-controller: remove the trailing `1` character literal from the rate limiting metric `APIServiceOpenAPIAggregationControllerQueue1` and rename it to `open_api_aggregation_controller` to adhere to Prometheus best practices. ([#77979](https://github.com/kubernetes/kubernetes/pull/77979), [@s-urbaniak](https://github.com/s-urbaniak)) [SIG API Machinery]
+- Reduce event spam during a volume operation error. ([#89794](https://github.com/kubernetes/kubernetes/pull/89794), [@msau42](https://github.com/msau42)) [SIG Storage]
+- Refactor the local nodeipam range allocator and instrument the cidrset used to store the allocated CIDRs with the following metrics:
+  "cidrset_cidrs_allocations_total",
+  "cidrset_cidrs_releases_total",
+  "cidrset_usage_cidrs",
+  "cidrset_allocation_tries_per_request", ([#90288](https://github.com/kubernetes/kubernetes/pull/90288), [@aojea](https://github.com/aojea)) [SIG Apps, Instrumentation, Network and Scalability]
+- Remove deprecated --server-dry-run flag from kubectl apply ([#91308](https://github.com/kubernetes/kubernetes/pull/91308), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Renamed DefaultPodTopologySpread plugin to SelectorSpread plugin to avoid naming conflicts with feature Gate DefaultPodTopologySpread ([#92501](https://github.com/kubernetes/kubernetes/pull/92501), [@rakeshreddybandi](https://github.com/rakeshreddybandi)) [SIG Release, Scheduling and Testing]
+- Replace framework.Failf with ExpectNoError ([#91811](https://github.com/kubernetes/kubernetes/pull/91811), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG Instrumentation, Storage and Testing]
+- Scheduler PreScore plugins are not executed if there is one filtered node or less. ([#89370](https://github.com/kubernetes/kubernetes/pull/89370), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- The "HostPath should give a volume the correct mode" is no longer a conformance test ([#90861](https://github.com/kubernetes/kubernetes/pull/90861), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+- The Kubelet's `--experimental-allocatable-ignore-eviction` option is now marked as deprecated. ([#91578](https://github.com/kubernetes/kubernetes/pull/91578), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--experimental-mounter-path` and `--experimental-check-node-capabilities-before-mount` options are now marked as deprecated. ([#91373](https://github.com/kubernetes/kubernetes/pull/91373), [@knabben](https://github.com/knabben))
+- The PR adds functionality to generate events when a PV or PVC processing encounters certain failures. The events help users to know the reason for the failure so they can take necessary recovery actions. ([#89845](https://github.com/kubernetes/kubernetes/pull/89845), [@yuga711](https://github.com/yuga711)) [SIG Apps]
+- The PodShareProcessNamespace feature gate has been removed, and the PodShareProcessNamespace is unconditionally enabled. ([#90099](https://github.com/kubernetes/kubernetes/pull/90099), [@tanjunchen](https://github.com/tanjunchen)) [SIG Node]
+- The kube-apiserver `--kubelet-https` flag is deprecated. kube-apiserver connections to kubelets now unconditionally use `https` (kubelets have unconditionally used `https` to serve the endpoints the apiserver communicates with since before v1.0). ([#91630](https://github.com/kubernetes/kubernetes/pull/91630), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Node]
+- Update CNI to v0.8.6 ([#91370](https://github.com/kubernetes/kubernetes/pull/91370), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Release and Testing]
+- Update Golang to v1.14.5
+  - Update repo-infra to 0.0.7 (to support go1.14.5 and go1.13.13)
+    - Includes:
+      - bazelbuild/bazel-toolchains@3.3.2
+      - bazelbuild/rules_go@v0.22.7 ([#93088](https://github.com/kubernetes/kubernetes/pull/93088), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Update Golang to v1.14.6
+  - Update repo-infra to 0.0.8 (to support go1.14.6 and go1.13.14)
+    - Includes:
+      - bazelbuild/bazel-toolchains@3.4.0
+      - bazelbuild/rules_go@v0.22.8 ([#93198](https://github.com/kubernetes/kubernetes/pull/93198), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Update corefile-migration library to 1.0.8 ([#91856](https://github.com/kubernetes/kubernetes/pull/91856), [@wawa0210](https://github.com/wawa0210)) [SIG Node]
+- Update default etcd server version to 3.4.4 ([#89214](https://github.com/kubernetes/kubernetes/pull/89214), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle and Testing]
+- Update default etcd server version to 3.4.7 ([#89895](https://github.com/kubernetes/kubernetes/pull/89895), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle and Testing]
+- Update default etcd server version to 3.4.9 ([#92349](https://github.com/kubernetes/kubernetes/pull/92349), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing]
+- Update go.etcd.io/bbolt to v1.3.5 ([#92350](https://github.com/kubernetes/kubernetes/pull/92350), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery and Cloud Provider]
+- Update opencontainers/runtime-spec dependency to v1.0.2 ([#89644](https://github.com/kubernetes/kubernetes/pull/89644), [@saschagrunert](https://github.com/saschagrunert)) [SIG Node]
+- `beta.kubernetes.io/os` and `beta.kubernetes.io/arch` node labels are deprecated. Update node selectors to use `kubernetes.io/os` and `kubernetes.io/arch`. ([#91046](https://github.com/kubernetes/kubernetes/pull/91046), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and Node]
+- `kubectl config view` now redacts bearer tokens by default, similar to client certificates. The `--raw` flag can still be used to output full content. ([#88985](https://github.com/kubernetes/kubernetes/pull/88985), [@puerco](https://github.com/puerco))
+
+## Dependencies
+
+### Added
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/checkpoint-restore/go-criu/v4: [v4.0.2](https://github.com/checkpoint-restore/go-criu/v4/tree/v4.0.2)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/containerd/cgroups: [0dbf7f0](https://github.com/containerd/cgroups/tree/0dbf7f0)
+- github.com/containerd/continuity: [aaeac12](https://github.com/containerd/continuity/tree/aaeac12)
+- github.com/containerd/fifo: [a9fb20d](https://github.com/containerd/fifo/tree/a9fb20d)
+- github.com/containerd/go-runc: [5a6d9f3](https://github.com/containerd/go-runc/tree/5a6d9f3)
+- github.com/containerd/ttrpc: [v1.0.0](https://github.com/containerd/ttrpc/tree/v1.0.0)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/coreos/go-systemd/v22: [v22.1.0](https://github.com/coreos/go-systemd/v22/tree/v22.1.0)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/docopt/docopt-go: [ee0de3b](https://github.com/docopt/docopt-go/tree/ee0de3b)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0)
+- github.com/godbus/dbus/v5: [v5.0.3](https://github.com/godbus/dbus/v5/tree/v5.0.3)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/ishidawataru/sctp: [7c296d4](https://github.com/ishidawataru/sctp/tree/7c296d4)
+- github.com/moby/ipvs: [v1.0.1](https://github.com/moby/ipvs/tree/v1.0.1)
+- github.com/moby/sys/mountinfo: [v0.1.3](https://github.com/moby/sys/mountinfo/tree/v0.1.3)
+- github.com/moby/term: [672ec06](https://github.com/moby/term/tree/672ec06)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27)
+- google.golang.org/protobuf: v1.24.0
+- gotest.tools/v3: v3.0.2
+- k8s.io/klog/v2: v2.2.0
+
+### Changed
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/Azure/azure-sdk-for-go: [v35.0.0+incompatible → v43.0.0+incompatible](https://github.com/Azure/azure-sdk-for-go/compare/v35.0.0...v43.0.0)
+- github.com/Azure/go-autorest/autorest/adal: [v0.5.0 → v0.8.2](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.5.0...v0.8.2)
+- github.com/Azure/go-autorest/autorest/date: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.1.0...v0.2.0)
+- github.com/Azure/go-autorest/autorest/mocks: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.2.0...v0.3.0)
+- github.com/Azure/go-autorest/autorest: [v0.9.0 → v0.9.6](https://github.com/Azure/go-autorest/autorest/compare/v0.9.0...v0.9.6)
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/Microsoft/go-winio: [v0.4.14 → fc70bd9](https://github.com/Microsoft/go-winio/compare/v0.4.14...fc70bd9)
+- github.com/Microsoft/hcsshim: [672e52e → 5eafd15](https://github.com/Microsoft/hcsshim/compare/672e52e...5eafd15)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/cilium/ebpf: [95b36a5 → 1c8d4c9](https://github.com/cilium/ebpf/compare/95b36a5...1c8d4c9)
+- github.com/containerd/console: [84eeaae → v1.0.0](https://github.com/containerd/console/compare/84eeaae...v1.0.0)
+- github.com/containerd/containerd: [v1.0.2 → v1.3.3](https://github.com/containerd/containerd/compare/v1.0.2...v1.3.3)
+- github.com/containerd/typeurl: [2a93cfd → v1.0.0](https://github.com/containerd/typeurl/compare/2a93cfd...v1.0.0)
+- github.com/containernetworking/cni: [v0.7.1 → v0.8.0](https://github.com/containernetworking/cni/compare/v0.7.1...v0.8.0)
+- github.com/coredns/corefile-migration: [v1.0.6 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.6...v1.0.10)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/docker/docker: [be7ac8b → aa6a989](https://github.com/docker/docker/compare/be7ac8b...aa6a989)
+- github.com/docker/go-connections: [v0.3.0 → v0.4.0](https://github.com/docker/go-connections/compare/v0.3.0...v0.4.0)
+- github.com/evanphx/json-patch: [v4.2.0+incompatible → e83c0a1](https://github.com/evanphx/json-patch/compare/v4.2.0...e83c0a1)
+- github.com/fsnotify/fsnotify: [v1.4.7 → v1.4.9](https://github.com/fsnotify/fsnotify/compare/v1.4.7...v1.4.9)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/go-logr/logr: [v0.1.0 → v0.2.0](https://github.com/go-logr/logr/compare/v0.1.0...v0.2.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.2 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.2...v1.4.2)
+- github.com/google/cadvisor: [v0.35.0 → v0.37.0](https://github.com/google/cadvisor/compare/v0.35.0...v0.37.0)
+- github.com/google/go-cmp: [v0.3.0 → v0.4.0](https://github.com/google/go-cmp/compare/v0.3.0...v0.4.0)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/googleapis/gnostic: [v0.1.0 → v0.4.1](https://github.com/googleapis/gnostic/compare/v0.1.0...v0.4.1)
+- github.com/gorilla/mux: [v1.7.0 → v1.7.3](https://github.com/gorilla/mux/compare/v1.7.0...v1.7.3)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.10)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/konsorten/go-windows-terminal-sequences: [v1.0.1 → v1.0.3](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.1...v1.0.3)
+- github.com/kr/pretty: [v0.1.0 → v0.2.0](https://github.com/kr/pretty/compare/v0.1.0...v0.2.0)
+- github.com/mattn/go-isatty: [v0.0.9 → v0.0.4](https://github.com/mattn/go-isatty/compare/v0.0.9...v0.0.4)
+- github.com/matttproud/golang_protobuf_extensions: [v1.0.1 → c182aff](https://github.com/matttproud/golang_protobuf_extensions/compare/v1.0.1...c182aff)
+- github.com/mistifyio/go-zfs: [v2.1.1+incompatible → f784269](https://github.com/mistifyio/go-zfs/compare/v2.1.1...f784269)
+- github.com/mrunalp/fileutils: [7d4729f → abd8a0e](https://github.com/mrunalp/fileutils/compare/7d4729f...abd8a0e)
+- github.com/opencontainers/runc: [v1.0.0-rc10 → 819fcc6](https://github.com/opencontainers/runc/compare/v1.0.0-rc10...819fcc6)
+- github.com/opencontainers/runtime-spec: [v1.0.0 → 237cc4f](https://github.com/opencontainers/runtime-spec/compare/v1.0.0...237cc4f)
+- github.com/opencontainers/selinux: [5215b18 → v1.5.2](https://github.com/opencontainers/selinux/compare/5215b18...v1.5.2)
+- github.com/pkg/errors: [v0.8.1 → v0.9.1](https://github.com/pkg/errors/compare/v0.8.1...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.7.1)
+- github.com/prometheus/common: [v0.4.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.4.1...v0.10.0)
+- github.com/prometheus/procfs: [v0.0.2 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.2...v0.1.3)
+- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102)
+- github.com/sirupsen/logrus: [v1.4.2 → v1.6.0](https://github.com/sirupsen/logrus/compare/v1.4.2...v1.6.0)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- github.com/urfave/cli: [v1.20.0 → v1.22.2](https://github.com/urfave/cli/compare/v1.20.0...v1.22.2)
+- github.com/vishvananda/netlink: [v1.0.0 → v1.1.0](https://github.com/vishvananda/netlink/compare/v1.0.0...v1.1.0)
+- github.com/vishvananda/netns: [be1fbed → 52d707b](https://github.com/vishvananda/netns/compare/be1fbed...52d707b)
+- go.etcd.io/bbolt: v1.3.3 → v1.3.5
+- go.etcd.io/etcd: 3cf2f69 → 18dfb9c
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/crypto: bac4c82 → 75b2880
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/mod: 4bf6d31 → v0.3.0
+- golang.org/x/net: 13f9640 → ab34263
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- golang.org/x/sys: fde4db3 → ed371f2
+- golang.org/x/text: v0.3.2 → v0.3.3
+- golang.org/x/time: 9d24e82 → 555d28b
+- golang.org/x/tools: 65e3620 → c1934b7
+- golang.org/x/xerrors: a985d34 → 9bdfabe
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: 24fa4b2 → cb27e3a
+- google.golang.org/grpc: v1.26.0 → v1.27.0
+- gopkg.in/check.v1: 788fd78 → 41f04d3
+- honnef.co/go/tools: v0.0.1-2019.2.2 → v0.0.1-2019.2.3
+- k8s.io/gengo: 36b2048 → 8167cfd
+- k8s.io/kube-openapi: bf4fb3b → 656914f
+- k8s.io/system-validators: v1.0.4 → v1.1.2
+- k8s.io/utils: 0a110f9 → d5654de
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → v0.0.9
+- sigs.k8s.io/structured-merge-diff/v3: v3.0.0 → 43c19bb
+
+### Removed
+- github.com/OpenPeeDeeP/depguard: [v1.0.1](https://github.com/OpenPeeDeeP/depguard/tree/v1.0.1)
+- github.com/Rican7/retry: [v0.1.0](https://github.com/Rican7/retry/tree/v0.1.0)
+- github.com/StackExchange/wmi: [5d04971](https://github.com/StackExchange/wmi/tree/5d04971)
+- github.com/anmitsu/go-shlex: [648efa6](https://github.com/anmitsu/go-shlex/tree/648efa6)
+- github.com/bazelbuild/bazel-gazelle: [70208cb](https://github.com/bazelbuild/bazel-gazelle/tree/70208cb)
+- github.com/bazelbuild/buildtools: [69366ca](https://github.com/bazelbuild/buildtools/tree/69366ca)
+- github.com/bazelbuild/rules_go: [6dae44d](https://github.com/bazelbuild/rules_go/tree/6dae44d)
+- github.com/bradfitz/go-smtpd: [deb6d62](https://github.com/bradfitz/go-smtpd/tree/deb6d62)
+- github.com/cespare/prettybench: [03b8cfe](https://github.com/cespare/prettybench/tree/03b8cfe)
+- github.com/checkpoint-restore/go-criu: [17b0214](https://github.com/checkpoint-restore/go-criu/tree/17b0214)
+- github.com/client9/misspell: [v0.3.4](https://github.com/client9/misspell/tree/v0.3.4)
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/cpuguy83/go-md2man: [v1.0.10](https://github.com/cpuguy83/go-md2man/tree/v1.0.10)
+- github.com/docker/libnetwork: [c8a5fca](https://github.com/docker/libnetwork/tree/c8a5fca)
+- github.com/gliderlabs/ssh: [v0.1.1](https://github.com/gliderlabs/ssh/tree/v0.1.1)
+- github.com/go-critic/go-critic: [1df3008](https://github.com/go-critic/go-critic/tree/1df3008)
+- github.com/go-lintpack/lintpack: [v0.5.2](https://github.com/go-lintpack/lintpack/tree/v0.5.2)
+- github.com/go-ole/go-ole: [v1.2.1](https://github.com/go-ole/go-ole/tree/v1.2.1)
+- github.com/go-toolsmith/astcast: [v1.0.0](https://github.com/go-toolsmith/astcast/tree/v1.0.0)
+- github.com/go-toolsmith/astcopy: [v1.0.0](https://github.com/go-toolsmith/astcopy/tree/v1.0.0)
+- github.com/go-toolsmith/astequal: [v1.0.0](https://github.com/go-toolsmith/astequal/tree/v1.0.0)
+- github.com/go-toolsmith/astfmt: [v1.0.0](https://github.com/go-toolsmith/astfmt/tree/v1.0.0)
+- github.com/go-toolsmith/astinfo: [9809ff7](https://github.com/go-toolsmith/astinfo/tree/9809ff7)
+- github.com/go-toolsmith/astp: [v1.0.0](https://github.com/go-toolsmith/astp/tree/v1.0.0)
+- github.com/go-toolsmith/pkgload: [v1.0.0](https://github.com/go-toolsmith/pkgload/tree/v1.0.0)
+- github.com/go-toolsmith/strparse: [v1.0.0](https://github.com/go-toolsmith/strparse/tree/v1.0.0)
+- github.com/go-toolsmith/typep: [v1.0.0](https://github.com/go-toolsmith/typep/tree/v1.0.0)
+- github.com/gobwas/glob: [v0.2.3](https://github.com/gobwas/glob/tree/v0.2.3)
+- github.com/godbus/dbus: [2ff6f7f](https://github.com/godbus/dbus/tree/2ff6f7f)
+- github.com/golangci/check: [cfe4005](https://github.com/golangci/check/tree/cfe4005)
+- github.com/golangci/dupl: [3e9179a](https://github.com/golangci/dupl/tree/3e9179a)
+- github.com/golangci/errcheck: [ef45e06](https://github.com/golangci/errcheck/tree/ef45e06)
+- github.com/golangci/go-misc: [927a3d8](https://github.com/golangci/go-misc/tree/927a3d8)
+- github.com/golangci/go-tools: [e32c541](https://github.com/golangci/go-tools/tree/e32c541)
+- github.com/golangci/goconst: [041c5f2](https://github.com/golangci/goconst/tree/041c5f2)
+- github.com/golangci/gocyclo: [2becd97](https://github.com/golangci/gocyclo/tree/2becd97)
+- github.com/golangci/gofmt: [0b8337e](https://github.com/golangci/gofmt/tree/0b8337e)
+- github.com/golangci/golangci-lint: [v1.18.0](https://github.com/golangci/golangci-lint/tree/v1.18.0)
+- github.com/golangci/gosec: [66fb7fc](https://github.com/golangci/gosec/tree/66fb7fc)
+- github.com/golangci/ineffassign: [42439a7](https://github.com/golangci/ineffassign/tree/42439a7)
+- github.com/golangci/lint-1: [ee948d0](https://github.com/golangci/lint-1/tree/ee948d0)
+- github.com/golangci/maligned: [b1d8939](https://github.com/golangci/maligned/tree/b1d8939)
+- github.com/golangci/misspell: [950f5d1](https://github.com/golangci/misspell/tree/950f5d1)
+- github.com/golangci/prealloc: [215b22d](https://github.com/golangci/prealloc/tree/215b22d)
+- github.com/golangci/revgrep: [d9c87f5](https://github.com/golangci/revgrep/tree/d9c87f5)
+- github.com/golangci/unconvert: [28b1c44](https://github.com/golangci/unconvert/tree/28b1c44)
+- github.com/google/go-github: [v17.0.0+incompatible](https://github.com/google/go-github/tree/v17.0.0)
+- github.com/google/go-querystring: [v1.0.0](https://github.com/google/go-querystring/tree/v1.0.0)
+- github.com/gostaticanalysis/analysisutil: [v0.0.3](https://github.com/gostaticanalysis/analysisutil/tree/v0.0.3)
+- github.com/jellevandenhooff/dkim: [f50fe3d](https://github.com/jellevandenhooff/dkim/tree/f50fe3d)
+- github.com/klauspost/compress: [v1.4.1](https://github.com/klauspost/compress/tree/v1.4.1)
+- github.com/logrusorgru/aurora: [a7b3b31](https://github.com/logrusorgru/aurora/tree/a7b3b31)
+- github.com/mattn/go-shellwords: [v1.0.5](https://github.com/mattn/go-shellwords/tree/v1.0.5)
+- github.com/mattn/goveralls: [v0.0.2](https://github.com/mattn/goveralls/tree/v0.0.2)
+- github.com/mesos/mesos-go: [v0.0.9](https://github.com/mesos/mesos-go/tree/v0.0.9)
+- github.com/mitchellh/go-ps: [4fdf99a](https://github.com/mitchellh/go-ps/tree/4fdf99a)
+- github.com/mozilla/tls-observatory: [8791a20](https://github.com/mozilla/tls-observatory/tree/8791a20)
+- github.com/nbutton23/zxcvbn-go: [eafdab6](https://github.com/nbutton23/zxcvbn-go/tree/eafdab6)
+- github.com/pquerna/ffjson: [af8b230](https://github.com/pquerna/ffjson/tree/af8b230)
+- github.com/quasilyte/go-consistent: [c6f3937](https://github.com/quasilyte/go-consistent/tree/c6f3937)
+- github.com/ryanuber/go-glob: [256dc44](https://github.com/ryanuber/go-glob/tree/256dc44)
+- github.com/shirou/gopsutil: [c95755e](https://github.com/shirou/gopsutil/tree/c95755e)
+- github.com/shirou/w32: [bb4de01](https://github.com/shirou/w32/tree/bb4de01)
+- github.com/shurcooL/go-goon: [37c2f52](https://github.com/shurcooL/go-goon/tree/37c2f52)
+- github.com/shurcooL/go: [9e1955d](https://github.com/shurcooL/go/tree/9e1955d)
+- github.com/sourcegraph/go-diff: [v0.5.1](https://github.com/sourcegraph/go-diff/tree/v0.5.1)
+- github.com/tarm/serial: [98f6abe](https://github.com/tarm/serial/tree/98f6abe)
+- github.com/timakin/bodyclose: [87058b9](https://github.com/timakin/bodyclose/tree/87058b9)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- github.com/ultraware/funlen: [v0.0.2](https://github.com/ultraware/funlen/tree/v0.0.2)
+- github.com/valyala/bytebufferpool: [v1.0.0](https://github.com/valyala/bytebufferpool/tree/v1.0.0)
+- github.com/valyala/fasthttp: [v1.2.0](https://github.com/valyala/fasthttp/tree/v1.2.0)
+- github.com/valyala/quicktemplate: [v1.1.1](https://github.com/valyala/quicktemplate/tree/v1.1.1)
+- github.com/valyala/tcplisten: [ceec8f9](https://github.com/valyala/tcplisten/tree/ceec8f9)
+- go4.org: 417644f
+- golang.org/x/build: 2835ba2
+- golang.org/x/perf: 6e6d33e
+- gopkg.in/airbrake/gobrake.v2: v2.0.9
+- gopkg.in/gemnasium/logrus-airbrake-hook.v2: v2.1.2
+- gotest.tools/gotestsum: v0.3.5
+- grpc.go4.org: 11d0a25
+- k8s.io/klog: v1.0.0
+- k8s.io/repo-infra: v0.0.1-alpha.1
+- mvdan.cc/interfacer: c200402
+- mvdan.cc/lint: adc824a
+- mvdan.cc/unparam: fbb5962
+- sourcegraph.com/sqs/pbtypes: d3ebe8f
 
 
-# v1.18.0-beta.1
+## Dependencies
 
-[Documentation](https://docs.k8s.io)
+### Added
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/checkpoint-restore/go-criu/v4: [v4.0.2](https://github.com/checkpoint-restore/go-criu/v4/tree/v4.0.2)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/containerd/cgroups: [0dbf7f0](https://github.com/containerd/cgroups/tree/0dbf7f0)
+- github.com/containerd/continuity: [aaeac12](https://github.com/containerd/continuity/tree/aaeac12)
+- github.com/containerd/fifo: [a9fb20d](https://github.com/containerd/fifo/tree/a9fb20d)
+- github.com/containerd/go-runc: [5a6d9f3](https://github.com/containerd/go-runc/tree/5a6d9f3)
+- github.com/containerd/ttrpc: [v1.0.0](https://github.com/containerd/ttrpc/tree/v1.0.0)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/coreos/go-systemd/v22: [v22.1.0](https://github.com/coreos/go-systemd/v22/tree/v22.1.0)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/docopt/docopt-go: [ee0de3b](https://github.com/docopt/docopt-go/tree/ee0de3b)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0)
+- github.com/godbus/dbus/v5: [v5.0.3](https://github.com/godbus/dbus/v5/tree/v5.0.3)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/ishidawataru/sctp: [7c296d4](https://github.com/ishidawataru/sctp/tree/7c296d4)
+- github.com/moby/ipvs: [v1.0.1](https://github.com/moby/ipvs/tree/v1.0.1)
+- github.com/moby/sys/mountinfo: [v0.1.3](https://github.com/moby/sys/mountinfo/tree/v0.1.3)
+- github.com/moby/term: [672ec06](https://github.com/moby/term/tree/672ec06)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27)
+- google.golang.org/protobuf: v1.24.0
+- gotest.tools/v3: v3.0.2
+- k8s.io/klog/v2: v2.2.0
+- sigs.k8s.io/structured-merge-diff/v4: v4.0.1
 
-## Downloads for v1.18.0-beta.1
+### Changed
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/Azure/azure-sdk-for-go: [v35.0.0+incompatible → v43.0.0+incompatible](https://github.com/Azure/azure-sdk-for-go/compare/v35.0.0...v43.0.0)
+- github.com/Azure/go-autorest/autorest/adal: [v0.5.0 → v0.8.2](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.5.0...v0.8.2)
+- github.com/Azure/go-autorest/autorest/date: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.1.0...v0.2.0)
+- github.com/Azure/go-autorest/autorest/mocks: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.2.0...v0.3.0)
+- github.com/Azure/go-autorest/autorest: [v0.9.0 → v0.9.6](https://github.com/Azure/go-autorest/autorest/compare/v0.9.0...v0.9.6)
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/Microsoft/go-winio: [v0.4.14 → fc70bd9](https://github.com/Microsoft/go-winio/compare/v0.4.14...fc70bd9)
+- github.com/Microsoft/hcsshim: [672e52e → 5eafd15](https://github.com/Microsoft/hcsshim/compare/672e52e...5eafd15)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/cilium/ebpf: [95b36a5 → 1c8d4c9](https://github.com/cilium/ebpf/compare/95b36a5...1c8d4c9)
+- github.com/containerd/console: [84eeaae → v1.0.0](https://github.com/containerd/console/compare/84eeaae...v1.0.0)
+- github.com/containerd/containerd: [v1.0.2 → v1.3.3](https://github.com/containerd/containerd/compare/v1.0.2...v1.3.3)
+- github.com/containerd/typeurl: [2a93cfd → v1.0.0](https://github.com/containerd/typeurl/compare/2a93cfd...v1.0.0)
+- github.com/containernetworking/cni: [v0.7.1 → v0.8.0](https://github.com/containernetworking/cni/compare/v0.7.1...v0.8.0)
+- github.com/coredns/corefile-migration: [v1.0.6 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.6...v1.0.10)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/docker/docker: [be7ac8b → aa6a989](https://github.com/docker/docker/compare/be7ac8b...aa6a989)
+- github.com/docker/go-connections: [v0.3.0 → v0.4.0](https://github.com/docker/go-connections/compare/v0.3.0...v0.4.0)
+- github.com/evanphx/json-patch: [v4.2.0+incompatible → v4.9.0+incompatible](https://github.com/evanphx/json-patch/compare/v4.2.0...v4.9.0)
+- github.com/fsnotify/fsnotify: [v1.4.7 → v1.4.9](https://github.com/fsnotify/fsnotify/compare/v1.4.7...v1.4.9)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/go-logr/logr: [v0.1.0 → v0.2.0](https://github.com/go-logr/logr/compare/v0.1.0...v0.2.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.2 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.2...v1.4.2)
+- github.com/google/cadvisor: [v0.35.0 → v0.37.0](https://github.com/google/cadvisor/compare/v0.35.0...v0.37.0)
+- github.com/google/go-cmp: [v0.3.0 → v0.4.0](https://github.com/google/go-cmp/compare/v0.3.0...v0.4.0)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/googleapis/gnostic: [v0.1.0 → v0.4.1](https://github.com/googleapis/gnostic/compare/v0.1.0...v0.4.1)
+- github.com/gorilla/mux: [v1.7.0 → v1.7.3](https://github.com/gorilla/mux/compare/v1.7.0...v1.7.3)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.10)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/konsorten/go-windows-terminal-sequences: [v1.0.1 → v1.0.3](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.1...v1.0.3)
+- github.com/kr/pretty: [v0.1.0 → v0.2.0](https://github.com/kr/pretty/compare/v0.1.0...v0.2.0)
+- github.com/mattn/go-isatty: [v0.0.9 → v0.0.4](https://github.com/mattn/go-isatty/compare/v0.0.9...v0.0.4)
+- github.com/matttproud/golang_protobuf_extensions: [v1.0.1 → c182aff](https://github.com/matttproud/golang_protobuf_extensions/compare/v1.0.1...c182aff)
+- github.com/mistifyio/go-zfs: [v2.1.1+incompatible → f784269](https://github.com/mistifyio/go-zfs/compare/v2.1.1...f784269)
+- github.com/mrunalp/fileutils: [7d4729f → abd8a0e](https://github.com/mrunalp/fileutils/compare/7d4729f...abd8a0e)
+- github.com/opencontainers/runc: [v1.0.0-rc10 → 819fcc6](https://github.com/opencontainers/runc/compare/v1.0.0-rc10...819fcc6)
+- github.com/opencontainers/runtime-spec: [v1.0.0 → 237cc4f](https://github.com/opencontainers/runtime-spec/compare/v1.0.0...237cc4f)
+- github.com/opencontainers/selinux: [5215b18 → v1.5.2](https://github.com/opencontainers/selinux/compare/5215b18...v1.5.2)
+- github.com/pkg/errors: [v0.8.1 → v0.9.1](https://github.com/pkg/errors/compare/v0.8.1...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.7.1)
+- github.com/prometheus/common: [v0.4.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.4.1...v0.10.0)
+- github.com/prometheus/procfs: [v0.0.2 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.2...v0.1.3)
+- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102)
+- github.com/sirupsen/logrus: [v1.4.2 → v1.6.0](https://github.com/sirupsen/logrus/compare/v1.4.2...v1.6.0)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- github.com/urfave/cli: [v1.20.0 → v1.22.2](https://github.com/urfave/cli/compare/v1.20.0...v1.22.2)
+- github.com/vishvananda/netlink: [v1.0.0 → v1.1.0](https://github.com/vishvananda/netlink/compare/v1.0.0...v1.1.0)
+- github.com/vishvananda/netns: [be1fbed → 52d707b](https://github.com/vishvananda/netns/compare/be1fbed...52d707b)
+- go.etcd.io/bbolt: v1.3.3 → v1.3.5
+- go.etcd.io/etcd: 3cf2f69 → 17cef6e
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/crypto: bac4c82 → 75b2880
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/mod: 4bf6d31 → v0.3.0
+- golang.org/x/net: 13f9640 → ab34263
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- golang.org/x/sys: fde4db3 → ed371f2
+- golang.org/x/text: v0.3.2 → v0.3.3
+- golang.org/x/time: 9d24e82 → 555d28b
+- golang.org/x/tools: 65e3620 → c1934b7
+- golang.org/x/xerrors: a985d34 → 9bdfabe
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: 24fa4b2 → cb27e3a
+- google.golang.org/grpc: v1.26.0 → v1.27.0
+- gopkg.in/check.v1: 788fd78 → 41f04d3
+- honnef.co/go/tools: v0.0.1-2019.2.2 → v0.0.1-2019.2.3
+- k8s.io/gengo: 36b2048 → 8167cfd
+- k8s.io/kube-openapi: bf4fb3b → 6aeccd4
+- k8s.io/system-validators: v1.0.4 → v1.1.2
+- k8s.io/utils: a9aa75a → d5654de
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → v0.0.9
+
+### Removed
+- github.com/OpenPeeDeeP/depguard: [v1.0.1](https://github.com/OpenPeeDeeP/depguard/tree/v1.0.1)
+- github.com/Rican7/retry: [v0.1.0](https://github.com/Rican7/retry/tree/v0.1.0)
+- github.com/StackExchange/wmi: [5d04971](https://github.com/StackExchange/wmi/tree/5d04971)
+- github.com/anmitsu/go-shlex: [648efa6](https://github.com/anmitsu/go-shlex/tree/648efa6)
+- github.com/bazelbuild/bazel-gazelle: [70208cb](https://github.com/bazelbuild/bazel-gazelle/tree/70208cb)
+- github.com/bazelbuild/buildtools: [69366ca](https://github.com/bazelbuild/buildtools/tree/69366ca)
+- github.com/bazelbuild/rules_go: [6dae44d](https://github.com/bazelbuild/rules_go/tree/6dae44d)
+- github.com/bradfitz/go-smtpd: [deb6d62](https://github.com/bradfitz/go-smtpd/tree/deb6d62)
+- github.com/cespare/prettybench: [03b8cfe](https://github.com/cespare/prettybench/tree/03b8cfe)
+- github.com/checkpoint-restore/go-criu: [17b0214](https://github.com/checkpoint-restore/go-criu/tree/17b0214)
+- github.com/client9/misspell: [v0.3.4](https://github.com/client9/misspell/tree/v0.3.4)
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/cpuguy83/go-md2man: [v1.0.10](https://github.com/cpuguy83/go-md2man/tree/v1.0.10)
+- github.com/docker/libnetwork: [c8a5fca](https://github.com/docker/libnetwork/tree/c8a5fca)
+- github.com/gliderlabs/ssh: [v0.1.1](https://github.com/gliderlabs/ssh/tree/v0.1.1)
+- github.com/go-critic/go-critic: [1df3008](https://github.com/go-critic/go-critic/tree/1df3008)
+- github.com/go-lintpack/lintpack: [v0.5.2](https://github.com/go-lintpack/lintpack/tree/v0.5.2)
+- github.com/go-ole/go-ole: [v1.2.1](https://github.com/go-ole/go-ole/tree/v1.2.1)
+- github.com/go-toolsmith/astcast: [v1.0.0](https://github.com/go-toolsmith/astcast/tree/v1.0.0)
+- github.com/go-toolsmith/astcopy: [v1.0.0](https://github.com/go-toolsmith/astcopy/tree/v1.0.0)
+- github.com/go-toolsmith/astequal: [v1.0.0](https://github.com/go-toolsmith/astequal/tree/v1.0.0)
+- github.com/go-toolsmith/astfmt: [v1.0.0](https://github.com/go-toolsmith/astfmt/tree/v1.0.0)
+- github.com/go-toolsmith/astinfo: [9809ff7](https://github.com/go-toolsmith/astinfo/tree/9809ff7)
+- github.com/go-toolsmith/astp: [v1.0.0](https://github.com/go-toolsmith/astp/tree/v1.0.0)
+- github.com/go-toolsmith/pkgload: [v1.0.0](https://github.com/go-toolsmith/pkgload/tree/v1.0.0)
+- github.com/go-toolsmith/strparse: [v1.0.0](https://github.com/go-toolsmith/strparse/tree/v1.0.0)
+- github.com/go-toolsmith/typep: [v1.0.0](https://github.com/go-toolsmith/typep/tree/v1.0.0)
+- github.com/gobwas/glob: [v0.2.3](https://github.com/gobwas/glob/tree/v0.2.3)
+- github.com/godbus/dbus: [2ff6f7f](https://github.com/godbus/dbus/tree/2ff6f7f)
+- github.com/golangci/check: [cfe4005](https://github.com/golangci/check/tree/cfe4005)
+- github.com/golangci/dupl: [3e9179a](https://github.com/golangci/dupl/tree/3e9179a)
+- github.com/golangci/errcheck: [ef45e06](https://github.com/golangci/errcheck/tree/ef45e06)
+- github.com/golangci/go-misc: [927a3d8](https://github.com/golangci/go-misc/tree/927a3d8)
+- github.com/golangci/go-tools: [e32c541](https://github.com/golangci/go-tools/tree/e32c541)
+- github.com/golangci/goconst: [041c5f2](https://github.com/golangci/goconst/tree/041c5f2)
+- github.com/golangci/gocyclo: [2becd97](https://github.com/golangci/gocyclo/tree/2becd97)
+- github.com/golangci/gofmt: [0b8337e](https://github.com/golangci/gofmt/tree/0b8337e)
+- github.com/golangci/golangci-lint: [v1.18.0](https://github.com/golangci/golangci-lint/tree/v1.18.0)
+- github.com/golangci/gosec: [66fb7fc](https://github.com/golangci/gosec/tree/66fb7fc)
+- github.com/golangci/ineffassign: [42439a7](https://github.com/golangci/ineffassign/tree/42439a7)
+- github.com/golangci/lint-1: [ee948d0](https://github.com/golangci/lint-1/tree/ee948d0)
+- github.com/golangci/maligned: [b1d8939](https://github.com/golangci/maligned/tree/b1d8939)
+- github.com/golangci/misspell: [950f5d1](https://github.com/golangci/misspell/tree/950f5d1)
+- github.com/golangci/prealloc: [215b22d](https://github.com/golangci/prealloc/tree/215b22d)
+- github.com/golangci/revgrep: [d9c87f5](https://github.com/golangci/revgrep/tree/d9c87f5)
+- github.com/golangci/unconvert: [28b1c44](https://github.com/golangci/unconvert/tree/28b1c44)
+- github.com/google/go-github: [v17.0.0+incompatible](https://github.com/google/go-github/tree/v17.0.0)
+- github.com/google/go-querystring: [v1.0.0](https://github.com/google/go-querystring/tree/v1.0.0)
+- github.com/gostaticanalysis/analysisutil: [v0.0.3](https://github.com/gostaticanalysis/analysisutil/tree/v0.0.3)
+- github.com/jellevandenhooff/dkim: [f50fe3d](https://github.com/jellevandenhooff/dkim/tree/f50fe3d)
+- github.com/klauspost/compress: [v1.4.1](https://github.com/klauspost/compress/tree/v1.4.1)
+- github.com/logrusorgru/aurora: [a7b3b31](https://github.com/logrusorgru/aurora/tree/a7b3b31)
+- github.com/mattn/go-shellwords: [v1.0.5](https://github.com/mattn/go-shellwords/tree/v1.0.5)
+- github.com/mattn/goveralls: [v0.0.2](https://github.com/mattn/goveralls/tree/v0.0.2)
+- github.com/mesos/mesos-go: [v0.0.9](https://github.com/mesos/mesos-go/tree/v0.0.9)
+- github.com/mitchellh/go-ps: [4fdf99a](https://github.com/mitchellh/go-ps/tree/4fdf99a)
+- github.com/mozilla/tls-observatory: [8791a20](https://github.com/mozilla/tls-observatory/tree/8791a20)
+- github.com/nbutton23/zxcvbn-go: [eafdab6](https://github.com/nbutton23/zxcvbn-go/tree/eafdab6)
+- github.com/pquerna/ffjson: [af8b230](https://github.com/pquerna/ffjson/tree/af8b230)
+- github.com/quasilyte/go-consistent: [c6f3937](https://github.com/quasilyte/go-consistent/tree/c6f3937)
+- github.com/ryanuber/go-glob: [256dc44](https://github.com/ryanuber/go-glob/tree/256dc44)
+- github.com/shirou/gopsutil: [c95755e](https://github.com/shirou/gopsutil/tree/c95755e)
+- github.com/shirou/w32: [bb4de01](https://github.com/shirou/w32/tree/bb4de01)
+- github.com/shurcooL/go-goon: [37c2f52](https://github.com/shurcooL/go-goon/tree/37c2f52)
+- github.com/shurcooL/go: [9e1955d](https://github.com/shurcooL/go/tree/9e1955d)
+- github.com/sourcegraph/go-diff: [v0.5.1](https://github.com/sourcegraph/go-diff/tree/v0.5.1)
+- github.com/tarm/serial: [98f6abe](https://github.com/tarm/serial/tree/98f6abe)
+- github.com/timakin/bodyclose: [87058b9](https://github.com/timakin/bodyclose/tree/87058b9)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- github.com/ultraware/funlen: [v0.0.2](https://github.com/ultraware/funlen/tree/v0.0.2)
+- github.com/valyala/bytebufferpool: [v1.0.0](https://github.com/valyala/bytebufferpool/tree/v1.0.0)
+- github.com/valyala/fasthttp: [v1.2.0](https://github.com/valyala/fasthttp/tree/v1.2.0)
+- github.com/valyala/quicktemplate: [v1.1.1](https://github.com/valyala/quicktemplate/tree/v1.1.1)
+- github.com/valyala/tcplisten: [ceec8f9](https://github.com/valyala/tcplisten/tree/ceec8f9)
+- go4.org: 417644f
+- golang.org/x/build: 2835ba2
+- golang.org/x/perf: 6e6d33e
+- gopkg.in/airbrake/gobrake.v2: v2.0.9
+- gopkg.in/gemnasium/logrus-airbrake-hook.v2: v2.1.2
+- gotest.tools/gotestsum: v0.3.5
+- grpc.go4.org: 11d0a25
+- k8s.io/klog: v1.0.0
+- k8s.io/repo-infra: v0.0.1-alpha.1
+- mvdan.cc/interfacer: c200402
+- mvdan.cc/lint: adc824a
+- mvdan.cc/unparam: fbb5962
+- sigs.k8s.io/structured-merge-diff/v3: v3.0.0
+- sourcegraph.com/sqs/pbtypes: d3ebe8f
+
+
+
+# v1.19.0-rc.4
+
+
+## Downloads for v1.19.0-rc.4
+
+### Source Code
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes.tar.gz) | `7c182ca905b3a31871c01ab5fdaf46f074547536c7975e069ff230af0d402dfc0346958b1d084bd2c108582ffc407484e6a15a1cd93e9affbe34b6e99409ef1f`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-src.tar.gz) | `d104b8c792b1517bd730787678c71c8ee3b259de81449192a49a1c6e37a6576d28f69b05c2019cc4a4c40ddeb4d60b80138323df3f85db8682caabf28e67c2de`
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes.tar.gz) | 98bb6e2ac98a3176a9592982fec04b037d189de73cb7175d51596075bfd008c7ec0a2301b9511375626581f864ea74b5731e2ef2b4c70363f1860d11eb827de1
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-src.tar.gz) | d4686f8d07fe6f324f46880a4dc5af9afa314a6b7dca82d0edb50290b769d25d18babcc5257a96a51a046052c7747e324b025a90a36ca5e62f67642bb03c44f6
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-darwin-amd64.tar.gz) | e9184ceb37491764c1ea2ef0b1eca55f27109bb973c7ff7c78e83c5945840baf28fdead21ef861b0c5cb81f4dc39d0af86ed7b17ed6f087f211084d0033dad11
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-386.tar.gz) | c9f1ec4e8d9c6245f955b2132c0fae6d851a6a49a5b7a2333c01ba9fafa3c4e8a07c6462e525179c25e308520502544ab4dc570e1b9d0090d58b6d18bcfcba47
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-amd64.tar.gz) | d23858b03c3554ad12517ce5f7855ceccaa9425c2d19fbc9cf902c0e796a8182f8b0e8eeeeefff0f46e960dfee96b2a2033a04a3194ac34dfd2a32003775d060
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-arm.tar.gz) | a745b3a06fe992713e4d7f921e2f36c5b39222d7b1a3e13299d15925743dd99965c2bdf05b4deda30a6f6232a40588e154fdd83f40d9d260d7ac8f70b18cad48
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-arm64.tar.gz) | 719b1f30e4bbb05d638ee78cf0145003a1e783bbd0c2f0952fcb30702dd27dfd44c3bc85baaf9a776e490ed53c638327ed1c0e5a882dc93c24d7cac20e4f1dd0
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-ppc64le.tar.gz) | fba0794e9dc0f231da5a4e85e37c2d8260e5205574e0421f5122a7d60a05ca6546912519a28e8d6c241904617234e1b0b5c94f890853ad5ae4e329ef8085a092
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-s390x.tar.gz) | edce96e37e37fd2b60e34fe56240461094e5784985790453becdfe09011305fcbd8a50ee5bf6d82a70d208d660796d0ddf160bed0292271b6617049db800962f
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-windows-386.tar.gz) | 06c849b35d886bebedfd8d906ac37ccda10e05b06542fefe6440268c5e937f235915e53daafe35076b68e0af0d4ddeab4240da55b09ee52fa26928945f1a2ecd
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-windows-amd64.tar.gz) | a13e6ec70f76d6056d5668b678ba6f223e35756cded6c84dfb58e28b3741fecfa7cb5e6ae2239392d770028d1b55ca8eb520c0b24e13fc3bd38720134b472d53
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-amd64.tar.gz) | ff7fbf211c29b94c19466337e6c142e733c8c0bac815a97906168e57d21ad1b2965e4b0033b525de8fed9a91ab943e3eb6d330f8095660e32be2791f8161a6a2
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-arm.tar.gz) | 218a35466ebcc0bc0e8eff9bbb2e58f0ac3bec6a75f45a7c1487aa4fc3e2bddb90b74e91a2b81bbbbb1eb1de2df310adab4c07c2a2c38a9973580b4f85734a1f
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-arm64.tar.gz) | 8a81d727e63875d18336fda8bb6f570084553fc346b7e7df2fc3e1c04a8ef766f61d96d445537e4660ce2f46b170a04218a4d8a270b3ad373caa3f815c0fec93
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-ppc64le.tar.gz) | 9b5afa44ac2e1232cd0c54b3602a2027bc8a08b30809b3ef973f75793b35a596491e6056d7995e493a1e4f48d83389240ac2e609b9f76d2715b8e115e6648716
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-s390x.tar.gz) | f3034b2e88b5c1d362d84f78dfd1761d0fc21ada1cd6b1a6132a709c663a1206651df96c948534b3661f6b70b651e33021aced3a7574a0e5fc88ace73fff2a6f
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-amd64.tar.gz) | 2061a8f5bc2060b071564c92b693950eda7768a9ceb874982f0e91aa78284fb477becb55ecf099acae73c447271240caecefc19b3b29024e9b818e0639c2fc70
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-arm.tar.gz) | c06b817b191ff9a4b05bf70fc14edcf01d4ded204e489966b1761dd68d45d054028870301e45ebba648c0be097c7c42120867c8b28fdd625c8eb5a5bc3ace71d
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-arm64.tar.gz) | 21efb3bf23628546de97210074f48e928fec211b81215eff8b10c3f5f7e79bb5911c1393a66a8363a0183fe299bf98b316c0c2d77a13c8c5b798255c056bd806
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-ppc64le.tar.gz) | ce31dd65b9cbfaabdc3c93e8afee0ea5606c64e6bf4452078bee73b1d328d23ebdbc871a00edd16fa4e676406a707cf9113fdaec76489681c379c35c3fd6aeb0
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-s390x.tar.gz) | 523a8e1d6e0eff70810e846c171b7f74a4aaecb25237addf541a9f8adb3797402b6e57abf9030f62d5bb333d5f5e8960199a44fe48696a4da98f7ed7d993cde1
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-windows-amd64.tar.gz) | a7fbcd11ea8b6427e7846e39b2fdeae41d484320faa8f3e9b6a777d87ba62e7399ad0ec6a33d9a4675001898881e444f336eebd5c97b3903dee803834a646f3d
+
+## Changelog since v1.19.0-rc.3
+
+## Changes by Kind
+
+### Deprecation
+
+- Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Cluster Lifecycle]
+
+### Bug or Regression
+
+- A panic in the apiserver caused by the `informer-sync` health checker is now fixed. ([#93600](https://github.com/kubernetes/kubernetes/pull/93600), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery]
+- EndpointSliceMirroring controller now copies labels from Endpoints to EndpointSlices. ([#93442](https://github.com/kubernetes/kubernetes/pull/93442), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- Kube-apiserver: jsonpath expressions with consecutive recursive descent operators are no longer evaluated for custom resource printer columns ([#93408](https://github.com/kubernetes/kubernetes/pull/93408), [@joelsmith](https://github.com/joelsmith)) [SIG API Machinery]
+
+### Other (Cleanup or Flake)
+
+- Build: Update to debian-base@v2.1.0 and debian-iptables@v12.1.1 ([#93667](https://github.com/kubernetes/kubernetes/pull/93667), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- k8s.io/utils: 0bdb4ca → d5654de
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-rc.3
+
+
+## Downloads for v1.19.0-rc.3
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes.tar.gz) | 31f98fb8d51c6dfa60e2cf710a35af14bc17a6b3833b3802cebc92586b01996c091943087dc818541fc13ad75f051d20c176d9506fc0c86ab582a9295fb7ed59
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-src.tar.gz) | 4886180edf6287adf9db1cdab1e8439c41296c6b5b40af9c4642bb6cfd1fb894313c6d1210c2b882f1bc40dbfd17ed20c5159ea3a8c79ad2ef7a7630016e99de
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-darwin-amd64.tar.gz) | 19b0f9fe95e135329ce2cb9dd3e95551f3552be035ce7235e055c9d775dfa747c773b0806b5c2eef1e69863368be13adcb4c5ef78ae05af65483434686e9a773
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-386.tar.gz) | 219a15b54ba616938960ac38869c87be573e3cd7897e4790c31cdeb819415fcefb4f293fc49d63901b42f70e66555c72a8a774cced7ec15a93592dffef3b1336
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-amd64.tar.gz) | 7c5a2163e0e163d3b1819acc7c4475d35b853318dd5a6084ea0785744a92063edf65254b0f0eae0f69f4598561c182033a9722c1b8a61894959333f1357cb1f9
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-arm.tar.gz) | 5d48f78da6a54b63d8ea68e983d780c672b546b4a5d1fb2c15033377dd3098f0011516b55cc47db316dacabdbbd3660108014d12899ef1f4a6a03158ef503101
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-arm64.tar.gz) | c2db09db465f8ea2bd7b82971a59a2be394b2f9a8c15ff78ab06c3a41d9f1292175de19fdc7450cc28746027d59dc3162cb47b64555e91d324d33d699d89f408
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-ppc64le.tar.gz) | f28c9c672bc2c5e780f6fdcf019a5dad7172537e38e2ab7d52a1ea55babb41d296cef97b482133c7fce0634b1aed1b5322d1e0061d30c3848e4c912a7e1ca248
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-s390x.tar.gz) | 22844af3c97eb9f36a038c552e9818b8670cd02acc98defe5c131c7f88621014cd51c343c1e0921b88ebbfd9850a5c277f50df78350f7565db4e356521d415d4
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-windows-386.tar.gz) | edabe78a1337f73caa81c885d722544fec443f875297291e57608d4f486c897af6c602656048a4325fcc957ce1d7acb1c1cf06cab0bd2e36acee1d6be206d3c6
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-windows-amd64.tar.gz) | f1a370b9ec298838e302909dd826760b50b593ee2d2247416d345ff00331973e7b6b29cef69f07d6c1477ab534d6ec9d1bbf5d3c2d1bb9b5b2933e088c8de3f1
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-amd64.tar.gz) | 193c023306d7478c2e43c4039642649c77598c05b07dbc466611e166f0233a7ea2a7f2ff61763b2630988c151a591f44428942d8ee06ce6766641e1dcfaac588
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-arm.tar.gz) | c1aa489779fb74855385f24120691771a05b57069064c99471b238e5d541d94d4356e7d2cd5b66c284c46bde1fc3eff2a1cebfcd9e72a78377b76e32a1dbf57a
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-arm64.tar.gz) | 73400003571f9f0308051ca448b1f96d83e9d211876a57b572ffb787ad0c3bb5f1e20547d959f0fac51a916cf7f26f8839ddddd55d4a38e59c8270d5eb48a970
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-ppc64le.tar.gz) | bebf75d884d024ffebfda40abaa0bfec99a6d4cd3cc0fac904a1c4c190e6eb8fc9412c7790b2f8a2b3cc8ccdf8556d9a93eec37e5c298f8abd62ee41de641a42
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-s390x.tar.gz) | 8374dfb689abae31480814d6849aaa51e30666b7203cdcf204d49c9a0344391232f40d135671ec8316e26d1685e1cbbea4b829ff3b9f83c08c2d1ba50cd5aeb2
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-amd64.tar.gz) | 194ee29b012463e6d90c346f76d53f94778f75cc916b0e10a5ee174983fac6e848438e0d9e36a475c5d7ba7b0f3ad5debc039ec8f95fdfb6229843f04dfacb53
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-arm.tar.gz) | f0d075eaa84dae7ce2101dfa421021b0bfea235fe606d693e881775cd37ff0b82ca6a419dfe48becd2eddc5f882e97ba838164e6ac5991445225c31f147b4f97
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-arm64.tar.gz) | 3dc69981f31b01a2d8c439f7047f73e5699a121501c516ed17b3e91ed358ee97e43fa955eb9e1434cbf7864e51097e76c216075d34f4b455930a44af6c64be5c
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-ppc64le.tar.gz) | 4a77720373960a0cc20bbcfcdfe17f8d5ddaaf2e38bad607cfe05831029e8e14559e78cd0b5b80ab9c9268a04a8b6bd54ad7232c29301a1f6a6392fcd38ecedf
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-s390x.tar.gz) | 319e684340aab739e3da46c6407851ff1c42463ba176bf190e58faa48d143975f02df3443ac287cdfcf652b5d6b6e6721d9e4f35995c4e705297a97dd777fe7e
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-windows-amd64.tar.gz) | 1ff22497a3f0844ffa8593a2a444a8fcb45d0123da49fd58e17cfc1477d22be7f6809d923898b6aa7a9ce519b0a6e0825f575f6cf71da5c8a0fa5f6b4d0905b6
+
+## Changelog since v1.19.0-rc.2
+
+## Changes by Kind
+
+### API Change
+
+- Adds the ability to disable Accelerator/GPU metrics collected by Kubelet ([#91930](https://github.com/kubernetes/kubernetes/pull/91930), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node]
+- Kubernetes is now built with golang 1.15.0-rc.1.
+  - The deprecated, legacy behavior of treating the CommonName field on X.509 serving certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable. ([#93264](https://github.com/kubernetes/kubernetes/pull/93264), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage and Testing]
+
+### Bug or Regression
+
+- Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Extended DSR loadbalancer feature in winkernel kube-proxy to HNS versions 9.3-9.max, 10.2+ ([#93080](https://github.com/kubernetes/kubernetes/pull/93080), [@elweb9858](https://github.com/elweb9858)) [SIG Network]
+- Fix instance not found issues when an Azure Node is recreated in a short time ([#93316](https://github.com/kubernetes/kubernetes/pull/93316), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+
+## Dependencies
+
+### Added
+- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27)
+
+### Changed
+- github.com/Microsoft/hcsshim: [v0.8.9 → 5eafd15](https://github.com/Microsoft/hcsshim/compare/v0.8.9...5eafd15)
+- github.com/containerd/cgroups: [bf292b2 → 0dbf7f0](https://github.com/containerd/cgroups/compare/bf292b2...0dbf7f0)
+- github.com/urfave/cli: [v1.22.1 → v1.22.2](https://github.com/urfave/cli/compare/v1.22.1...v1.22.2)
+- golang.org/x/crypto: bac4c82 → 75b2880
+- golang.org/x/mod: v0.1.0 → v0.3.0
+- golang.org/x/net: d3edc99 → ab34263
+- golang.org/x/tools: c00d67e → c1934b7
+
+### Removed
+- github.com/godbus/dbus: [ade71ed](https://github.com/godbus/dbus/tree/ade71ed)
+
+
+
+# v1.19.0-rc.2
+
+
+## Downloads for v1.19.0-rc.2
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes.tar.gz) | 7a9fa6af3772be18f8c427d8b96836bd77e271a08fffeba92d01b3fac4bd69d2be1bbc404cdd4fc259dda42b16790a7943eddb7c889b918d7631857e127a724c
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-src.tar.gz) | 60184627a181ac99cd914acb0ba61c22f31b315ef13be5504f3cb43dea1fa84abb2142c8a1ba9e98e037e0d9d2765e8d85bd12903b03a86538d7638ceb6ac5c9
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-darwin-386.tar.gz) | 03332cd70ce6a9c8e533d93d694da32b549bef486cf73c649bcb1c85fc314b0ac0f95e035de7b54c81112c1ac39029abeb8f246d359384bde2119ea5ea3ebe66
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-darwin-amd64.tar.gz) | e82c2908366cc27cbc1d72f89fdc13414b484dfdf26c39c6180bf2e5734169cc97d77a2d1ac051cdb153582a38f4805e5c5b5b8eb88022c914ffb4ef2a8202d3
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-386.tar.gz) | 948be72e8162ee109c670a88c443ba0907acfd0ffb64df62afe41762717bc2fb9308cbc4eb2012a14e0203197e8576e3700ad9f105379841d46acafad2a4c6dc
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-amd64.tar.gz) | 54e1980b6967dab1e70be2b4df0cd0171f04c92f12dcdf80908b087facb9d5cc1399a7d9455a4a799daa8e9d48b6ad86cb3666a131e5adfcd36b008d25138fa3
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-arm.tar.gz) | 4edcd2e1a866a16b8b0f6228f93b4a61cdd43dca36dcb53a5dbd865cc5a143ef6fd3b8575925acc8af17cff21dee993df9b88db5724320e7b420ca9d0427677f
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-arm64.tar.gz) | 138b215e35cfb5d05bda766763e92352171e018a090d516dbf0c280588c5e6f36228163a75a8147c7bac46e773ad0353daaf550d8fa0e91b1e05c5bc0242531c
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-ppc64le.tar.gz) | 3b8e7f5f1f2e34df5dbb06c12f07f660a2a732846c56d0f4b0a939b8121361d381325565bdda3182ef8951f4c2513a2c255940f97011034063ffb506d5aedeab
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-s390x.tar.gz) | b695cc0695bd324c51084e64bea113aaad3c0b5ba44b5d122db9da6e359a4108008a80944cbe96c405bd2cf57f5f31b3eaf50f33c23d980bdb9f272937c88d1c
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-windows-386.tar.gz) | 8e370a66545cdebe0ae0816afe361c7579c7c6e8ee5652e4e01c6fcc3d6d2a6557101be39be24ceb14302fb30855730894a17f6ae11586759257f12406c653e2
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-windows-amd64.tar.gz) | 89e0fe5aac33c991891b08e5a3891ecbda3e038f0ee6a5cdd771ea294ec84292bd5f65f1a895f23e6892ec28f001f66d0166d204bf135cb1aa467ae56ccc1260
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-amd64.tar.gz) | 2b0a1b107bf31913d9deec57eab9d3db2ea512c995ce3b4fe247f91c36fdebcc4484a2f8ff53d40a5bc6a04c7144827b85b40ac90c46a9b0cec8a680700f1b1c
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-arm.tar.gz) | 2f1ab3bcacd82a9b6d92e09b7cdd63f57fc44623cdfb517512b634264fed87999d78b8571c7930839381b1ed4793b68343e85956d7a8c5bae77ba8f8ade06afa
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-arm64.tar.gz) | ea67613c8356f650891a096881546afb27f00e86a9c777617817583628d38b4725f0f65da3b0732414cbc8f97316b3029a355177342a4b1d94cf02d79542e4cd
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-ppc64le.tar.gz) | d1b151f3f47c28ead2304d2477fa25f24d12e3fd80e9d1b3b593db99b9a1c5821db4d089f4f1dd041796ea3fd814000c225a7e75aac1e5891a4e16517bcaceee
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-s390x.tar.gz) | 69bf215fdc3ad53834eaa9a918452feb0803dffe381b6e03b73141364a697a576e5ed0242d448616707cb386190c21564fe89f8cf3409a7c621a86d86b2c7680
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-amd64.tar.gz) | 88ae137316bab3bb1dcb6c78a4d725face618d41714400505b97ce9d3fa37a6caa036b9e8508ade6dd679e3a8c483a32aef9e400ab08d86b6bf39bc13f34e435
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-arm.tar.gz) | 7eaaf2a2a4ee5181cb4c1567e99b8bf82a3da342799f5d2b34dd7f133313c3e3d2ac5a778110e178161788cb226bd64836fba35fbec21c8384e7725cae9b756c
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-arm64.tar.gz) | 4f0ef95abc52da0e5d0c40434f8c324ddfb218a577114c4ead00f2ac1c01439922aee6fe347f702927a73b0166cd8b9f4c491d3a18a1a951d24c9ea7259d2655
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-ppc64le.tar.gz) | 0424896e2fedae3a566a5aa2e4af26977a578066d49e3ad66307839c2d2dd1c53d1afcf16b2f6cebf0c74d2d60dbc118e6446d9c02aaab27e95b3a6d26889f51
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-s390x.tar.gz) | 294788687a6e6d1ca2e4d56435b1174e4330abe64cc58b1372c3b9caaab4455586da4e3bfc62616b52ea7d678561fb77ce1f8d0023fd7d1e75e1db348c69939c
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-windows-amd64.tar.gz) | 61389f8c05c682102e3432a2f05f41b11d531124f61443429627f94ef6e970d44240d44d32aa467b814de0b54a17208b2d2696602ba5dd6d30f64db964900230
+
+## Changelog since v1.19.0-rc.1
+
+## Changes by Kind
+
+### API Change
+
+- A new alpha-level field, `SupportsFsGroup`, has been introduced for CSIDrivers to allow them to specify whether they support volume ownership and permission modifications. The `CSIVolumeSupportFSGroup` feature gate must be enabled to allow this field to be used. ([#92001](https://github.com/kubernetes/kubernetes/pull/92001), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, CLI and Storage]
+- The kube-controller-manager managed signers can now have distinct signing certificates and keys.  See the help about `--cluster-signing-[signer-name]-{cert,key}-file`.  `--cluster-signing-{cert,key}-file` is still the default. ([#90822](https://github.com/kubernetes/kubernetes/pull/90822), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth]
+
+### Feature
+
+- Added kube-apiserver metrics: apiserver_current_inflight_request_measures and, when API Priority and Fairness is enable, windowed_request_stats. ([#91177](https://github.com/kubernetes/kubernetes/pull/91177), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery, Instrumentation and Testing]
+- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
+
+### Bug or Regression
+
+- Do not add nodes labeled with kubernetes.azure.com/managed=false to backend pool of load balancer. ([#93034](https://github.com/kubernetes/kubernetes/pull/93034), [@matthias50](https://github.com/matthias50)) [SIG Cloud Provider]
+- Do not retry volume expansion if CSI driver returns FailedPrecondition error ([#92986](https://github.com/kubernetes/kubernetes/pull/92986), [@gnufied](https://github.com/gnufied)) [SIG Node and Storage]
+- Fix: determine the correct ip config based on ip family ([#93043](https://github.com/kubernetes/kubernetes/pull/93043), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Fix: initial delay in mounting azure disk & file ([#93052](https://github.com/kubernetes/kubernetes/pull/93052), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fixed the EndpointSliceController to correctly create endpoints for IPv6-only pods.
+  
+  Fixed the EndpointController to allow IPv6 headless services, if the IPv6DualStack
+  feature gate is enabled, by specifying `ipFamily: IPv6` on the service. (This already
+  worked with the EndpointSliceController.) ([#91399](https://github.com/kubernetes/kubernetes/pull/91399), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+
+### Other (Cleanup or Flake)
+
+- Kube-up: defaults to limiting critical pods to the kube-system namespace to match behavior prior to 1.17 ([#93121](https://github.com/kubernetes/kubernetes/pull/93121), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Scheduling]
+- Update Golang to v1.14.5
+  - Update repo-infra to 0.0.7 (to support go1.14.5 and go1.13.13)
+    - Includes:
+      - bazelbuild/bazel-toolchains@3.3.2
+      - bazelbuild/rules_go@v0.22.7 ([#93088](https://github.com/kubernetes/kubernetes/pull/93088), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Update Golang to v1.14.6
+  - Update repo-infra to 0.0.8 (to support go1.14.6 and go1.13.14)
+    - Includes:
+      - bazelbuild/bazel-toolchains@3.4.0
+      - bazelbuild/rules_go@v0.22.8 ([#93198](https://github.com/kubernetes/kubernetes/pull/93198), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Update default etcd server version to 3.4.9 ([#92349](https://github.com/kubernetes/kubernetes/pull/92349), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- go.etcd.io/etcd: 54ba958 → 18dfb9c
+- k8s.io/utils: 6e3d28b → 0bdb4ca
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-rc.1
+
+
+## Downloads for v1.19.0-rc.1
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes.tar.gz) | d4bc1d86ff77a1a8695091207b8181a246c8964ae1dd8967392aae95197c0339c7915a016c017ecab0b9d203b3205221ca766ce568d7ee52947e7f50f057af4f
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-src.tar.gz) | 79af4e01b0d5432f92b026730a0c60523069d312858c30fdcaeaf6ee159c71f3413a5075d82c0acd9b135b7a06d5ecb0c0d38b8a8d0f301a9d9bffb35d22f029
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-darwin-386.tar.gz) | 7d21bf9733810659576e67986d129208894adea3c571de662dbf80fb822e18abfc1644ea60a4e5fbe244a23b56aa973b76dafe789ead1bf7539f41bdd9bca886
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-darwin-amd64.tar.gz) | b4622e06c09bb08a0dc0115bfcd991c50459c7b772889820648ed1c05a425605d10b71b92c58c119b77baa3bca209f9c75827d2cde69d128a5cfcada5f37be39
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-386.tar.gz) | f51032ad605543f68a2a4da3bede1f3e7be0dd63b03b751fef5f133e8d64bec02bfe7433b75e3d0c4ae122d4e0cf009095800c638d2cc81f6fb81b488f5a6dab
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-amd64.tar.gz) | 48489d22969f69a5015988e596d597c64ea18675649afe55ad119dbbe98ba9a4104d5e323704cf1f3cbdfca3feac629d3813e260a330a72da12f1a794d054f76
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-arm.tar.gz) | d9f8a6f6f3d09be9c08588c2b5153a4d8cc9db496bde3da2f3af472c260566d1391cd8811f2c05d4f302db849a38432f25228d9bbb59aaaf0dfba64b33f8ee8e
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-arm64.tar.gz) | 1c3590750a3f02e0e5845e1135cc3ab990309bdecfe64c089842a134eae57b573488531696796185ed12dde2d6f95d2e3656dd9893d04cd0adbe025513ffff30
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-ppc64le.tar.gz) | 158a562d5dbbe90cd56b5d757823adda1919e9b5db8005fb6e2523358e5a20628d55ec1903c0e317a0d8ac9b9a649eea23d9ea746db22b73d6d580ae8c067077
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-s390x.tar.gz) | 47c140567dc593caf065f295ed6006efcde010a526a96c8d3ef5f3d9a9dc6b413bc197dc822648067fe16299908ada7046c2a8a3213d4296b04b51a264ad40e9
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-windows-386.tar.gz) | e25d7d4ad3e6f6e6cfba181c5871e56de2751f88b640502745f6693ddd86ccd7eef8aebaa30955afdbbd0320a5b51d4e9e17f71baab37a470aac284178a0e21c
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-windows-amd64.tar.gz) | fd8463b04b5d7f115104245fa1dd53de6656b349dad4cfd55f239012d4f2c1a8e35aa3f3554138df9ddfea9d7702b51a249f6db698c0cea7c36e5bc98a017fe7
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-amd64.tar.gz) | 96acce78bba3779bef616de28da5d75bc4dc0b52fe0bf03b169c469ade9a8cd38b19c4620d222d67bff9ceeb0c5ebf893f55c1de02356bcebe5689890d0478f7
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-arm.tar.gz) | 1e561f3edbc66d2ab7f6f1ffe8dc1c01cec13ee3ba700458bd5d87202723cc832f3305a864a3b569463c96d60c9f60c03b77f210663cc40589e40515b3a32e75
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-arm64.tar.gz) | ba8fc011ac0e54cb1a0e0e3ee5f1cff4d877f4fdd75e15bf25b1cf817b3cf2bc85f9809d3cc76e9145f07a837960843ca68bdf02fe970c0043fc9ff7b53da021
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-ppc64le.tar.gz) | 1f506676284ab2f6bd3fc8a29a062f4fddf5346ef30be9363f640467c64011144381180c5bf74ec885d2f54524e82e21c745c5d2f1b191948bc40db2a09a2900
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-s390x.tar.gz) | 5a7101288d51297c3346d028176b4b997afd8652d6481cec82f8863a91209fec6e8a9286a9bd7543b428e6ef82c1c68a7ce0782191c4682634015a032f749554
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-amd64.tar.gz) | 6852edc9818cb51a7e738e44a8bca2290777320e62518c024962fddd05f7ef390fb5696537068fd75e340bae909602f0bbc2aa5ebf6c487c7b1e990250f16810
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-arm.tar.gz) | f13edad4684d0de61e4cd7e524f891c75e0efe1050911d9bf0ee3a77cac28f57dca68fb990df6b5d9646e9b389527cbb861de10e12a84e57788f339db05936cb
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-arm64.tar.gz) | 69480150325525459aed212b8c96cb1865598cb5ecbeb57741134142d65e8a96258ec298b86d533ce88d2c499c4ad17e66dd3f0f7b5e9c34882889e9cb384805
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-ppc64le.tar.gz) | 774cfa9a4319ede166674d3e8c46900c9319d98ffba5b46684244e4bb15d94d31df8a6681e4711bc744d7e92fd23f207505eda98f43c8e2383107badbd43f289
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-s390x.tar.gz) | 7e696988febb1e913129353134191b23c6aa5b0bea7c9c9168116596b827c091a88049ca8b8847dda25ecd4467cca4cc48cae8699635b5e78b83aab482c109f5
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-windows-amd64.tar.gz) | 067182292d9e17f0d4974051681bedcf5ed6017dc80485541f89ea1f211085714165941a5262a4997b7bfc2bd190f2255df4c1b39f86a3278487248111d83cd4
+
+## Changelog since v1.19.0-rc.0
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+ - Azure blob disk feature(`kind`: `Shared`, `Dedicated`) has been deprecated, you should use `kind`: `Managed` in `kubernetes.io/azure-disk` storage class. ([#92905](https://github.com/kubernetes/kubernetes/pull/92905), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+ 
+## Changes by Kind
+
+### Deprecation
+
+- Kubeadm: deprecate the "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. ([#92881](https://github.com/kubernetes/kubernetes/pull/92881), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+
+### API Change
+
+- Added pod version skew strategy for seccomp profile to synchronize the deprecated annotations with the new API Server fields. Please see the corresponding section [in the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.mdversion-skew-strategy) for more detailed explanations. ([#91408](https://github.com/kubernetes/kubernetes/pull/91408), [@saschagrunert](https://github.com/saschagrunert)) [SIG Apps, Auth, CLI and Node]
+- Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. ([#91637](https://github.com/kubernetes/kubernetes/pull/91637), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing]
+- Generic ephemeral volumes, a new alpha feature under the `GenericEphemeralVolume` feature gate, provide a more flexible alternative to `EmptyDir` volumes: as with `EmptyDir`, volumes are created and deleted for each pod automatically by Kubernetes. But because the normal provisioning process is used (`PersistentVolumeClaim`), storage can be provided by third-party storage vendors and all of the usual volume features work. Volumes don't need to be empt; for example, restoring from snapshot is supported. ([#92784](https://github.com/kubernetes/kubernetes/pull/92784), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing]
+
+### Feature
+
+- ACTION REQUIRED : In CoreDNS v1.7.0, [metrics names have been changed](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md&#35;metric-changes) which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading. 
+  
+  Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include:
+  -  Fixed a bug that could cause CoreDNS to stop updating service records.
+  -  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
+  -  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
+  -  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
+  -  The federation plugin (allows for v1 Kubernetes federation) has been removed.
+  More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92651](https://github.com/kubernetes/kubernetes/pull/92651), [@rajansandeep](https://github.com/rajansandeep)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Add tags support for Azure File Driver ([#92825](https://github.com/kubernetes/kubernetes/pull/92825), [@ZeroMagic](https://github.com/ZeroMagic)) [SIG Cloud Provider and Storage]
+- Audit events for API requests to deprecated API versions now include a `"k8s.io/deprecated": "true"` audit annotation. If a target removal release is identified, the audit event includes a `"k8s.io/removal-release": "<majorVersion>.<minorVersion>"` audit annotation as well. ([#92842](https://github.com/kubernetes/kubernetes/pull/92842), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Instrumentation]
+- Cloud node-controller use InstancesV2 ([#91319](https://github.com/kubernetes/kubernetes/pull/91319), [@gongguan](https://github.com/gongguan)) [SIG Apps, Cloud Provider, Scalability and Storage]
+- Kubeadm: deprecate the "--csr-only" and "--csr-dir" flags of the "kubeadm init phase certs" subcommands. Please use "kubeadm alpha certs generate-csr" instead. This new command allows you to generate new private keys and certificate signing requests for all the control-plane components, so that the certificates can be signed by an external CA. ([#92183](https://github.com/kubernetes/kubernetes/pull/92183), [@wallrj](https://github.com/wallrj)) [SIG Cluster Lifecycle]
+- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
+- Set CSIMigrationvSphere feature gates to beta.
+  Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
+  
+  Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15 ([#92816](https://github.com/kubernetes/kubernetes/pull/92816), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider and Storage]
+- Support a smooth upgrade from client-side apply to server-side apply without conflicts, as well as support the corresponding downgrade. ([#90187](https://github.com/kubernetes/kubernetes/pull/90187), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery and Testing]
+- Trace output in apiserver logs is more organized and comprehensive. Traces are nested, and for all non-long running request endpoints, the entire filter chain is instrumented (e.g. authentication check is included). ([#88936](https://github.com/kubernetes/kubernetes/pull/88936), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Scheduling]
+- `kubectl alpha debug` now supports debugging nodes by creating a debugging container running in the node's host namespaces. ([#92310](https://github.com/kubernetes/kubernetes/pull/92310), [@verb](https://github.com/verb)) [SIG CLI]
+
+### Failing Test
+
+- Kube-proxy iptables min-sync-period defaults to 1 sec. Previously, it was 0. ([#92836](https://github.com/kubernetes/kubernetes/pull/92836), [@aojea](https://github.com/aojea)) [SIG Network]
+
+### Bug or Regression
+
+- Dockershim security: pod sandbox now always run with `no-new-privileges` and `runtime/default` seccomp profile
+  dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90948](https://github.com/kubernetes/kubernetes/pull/90948), [@pjbgf](https://github.com/pjbgf)) [SIG Node]
+- Eviction requests for pods that have a non-zero DeletionTimestamp will always succeed ([#91342](https://github.com/kubernetes/kubernetes/pull/91342), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps]
+- Fix detection of image filesystem, disk metrics for devicemapper, detection of OOM Kills on 5.0+ linux kernels. ([#92919](https://github.com/kubernetes/kubernetes/pull/92919), [@dashpole](https://github.com/dashpole)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
+- Fixed memory leak in endpointSliceTracker ([#92838](https://github.com/kubernetes/kubernetes/pull/92838), [@tnqn](https://github.com/tnqn)) [SIG Apps and Network]
+- Kube-aggregator certificates are dynamically loaded on change from disk ([#92791](https://github.com/kubernetes/kubernetes/pull/92791), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
+- Kube-up now includes CoreDNS version v1.7.0. Some of the major changes include:
+  -  Fixed a bug that could cause CoreDNS to stop updating service records.
+  -  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
+  -  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
+  -  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
+  -  The federation plugin (allows for v1 Kubernetes federation) has been removed.
+  More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92718](https://github.com/kubernetes/kubernetes/pull/92718), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cloud Provider]
+- The apiserver will no longer proxy non-101 responses for upgrade requests. This could break proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code. ([#92941](https://github.com/kubernetes/kubernetes/pull/92941), [@tallclair](https://github.com/tallclair)) [SIG API Machinery]
+- The terminationGracePeriodSeconds from pod spec is respected for the mirror pod. ([#92442](https://github.com/kubernetes/kubernetes/pull/92442), [@tedyu](https://github.com/tedyu)) [SIG Node and Testing]
+
+### Other (Cleanup or Flake)
+
+- --cache-dir sets cache directory for both http and discovery, defaults to $HOME/.kube/cache ([#92910](https://github.com/kubernetes/kubernetes/pull/92910), [@soltysh](https://github.com/soltysh)) [SIG API Machinery and CLI]
+- Fix: license issue in blob disk feature ([#92824](https://github.com/kubernetes/kubernetes/pull/92824), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- github.com/cilium/ebpf: [9f1617e → 1c8d4c9](https://github.com/cilium/ebpf/compare/9f1617e...1c8d4c9)
+- github.com/coredns/corefile-migration: [v1.0.8 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.8...v1.0.10)
+- github.com/google/cadvisor: [8450c56 → v0.37.0](https://github.com/google/cadvisor/compare/8450c56...v0.37.0)
+- github.com/json-iterator/go: [v1.1.9 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.9...v1.1.10)
+- github.com/opencontainers/runc: [1b94395 → 819fcc6](https://github.com/opencontainers/runc/compare/1b94395...819fcc6)
+- github.com/prometheus/client_golang: [v1.6.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.6.0...v1.7.1)
+- github.com/prometheus/common: [v0.9.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.9.1...v0.10.0)
+- github.com/prometheus/procfs: [v0.0.11 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.11...v0.1.3)
+- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102)
+- sigs.k8s.io/structured-merge-diff/v3: v3.0.0 → 43c19bb
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-beta.2
+
+
+## Downloads for v1.19.0-beta.2
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes.tar.gz) | 806c1734a57dfc1800730fcb25aeb60d50d19d248c0e2a92ede4b6c4565745b4f370d4fd925bef302a96fba89102b7560b8f067240e0f35f6ec6caa29971dea4
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-src.tar.gz) | 507372c6d7ea380ec68ea237141a2b62953a2e1d1d16288f37820b605e33778c5f43ac5a3dedf39f7907d501749916221a8fa4d50be1e5a90b3ce23d36eaa075
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-darwin-386.tar.gz) | 6d20ca8d37b01213dcb98a1e49d44d414043ce485ae7df9565dfb7914acb1ec42b7aeb0c503b8febc122a8b444c6ed13eec0ff3c88033c6db767e7af5dbbc65d
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | e9caa5463a662869cfc8b9254302641aee9b53fa2119244bd65ef2c66e8c617f7db9b194a672ff80d7bc42256e6560db9fe8a00b2214c0ef023e2d6feed58a3a
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-386.tar.gz) | 48296417fcd2c2f6d01c30dcf66956401ea46455c52a2bbd76feb9b117502ceaa2fb10dae944e087e7038b9fdae5b835497213894760ca01698eb892087490d2
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | e2cc7819974316419a8973f0d77050b3262c4e8d078946ff9f6f013d052ec1dd82893313feff6e4493ae0fd3fb62310e6ce4de49ba6e80f8b9979650debf53f2
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-arm.tar.gz) | 484aac48a7a736970ea0766547453b7d37b25ed29fdee771734973e3e080b33f6731eecc458647db962290b512d32546e675e4658287ced3214e87292b98a643
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | f793078dc2333825a6679126b279cb0a3415ded8c650478e73c37735c6aa9576b68b2a4165bb77ef475884d50563ea236d8db4c72b2e5552b5418ea06268daae
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | 4c204b8d3b2717470ee460230b6bdc63725402ad3d24789397934bfe077b94d68041a376864b618e01f541b5bd00d0e63d75aa531a327ab0082c01eb4b9aa5ee
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | d0f6e4ddbf122ebcb4c5a980d5f8e33a23213cb438983341870f288afd17e73ec42f0ded55a3a9622c57700e68999228508d449ca206aca85f3254f7622375db
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-windows-386.tar.gz) | a615a7821bba1f8e4115b7981347ed94a79947c78d32c692cd600e21e0de29fedfc4a39dc08ca516f2f35261cf4a6d6ce557008f034e0e1d311fa9e75478ec0c
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | 34046130c5ebb3afe17e6e3cf88229b8d3281a9ac9c28dece1fd2d49a11b7be011700b74d9b8111dee7d0943e5ebfa208185bae095c2571aa54e0f9201e2cddd
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | c922058ce9c665e329d3d4647aac5d2dd22d9a8af63a21e6af98943dfd14f2b90268c53876f42a64093b96499ee1109803868c9aead4c15fd8db4b1bbec58fd9
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-arm.tar.gz) | 4f17489b946dc04570bfab87015f2c2401b139b9ee745ed659bc94ccd116f3f23e249f83e19aaa418aa980874fffb478b1ec7340aa25292af758c9eabd4c2022
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | 69e44a63d15962de95a484e311130d415ebfec16a9da54989afc53a835c5b67de20911d71485950d07259a0f8286a299f4d74f90c73530e905da8dc60e391597
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | 66b30ebad7a8226304150aa42a1bd660a0b3975fecbfd8dbbea3092936454d9f81c8083841cc67c6645ab771383b66c7f980dd65319803078c91436c55d5217a
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | 0e197280f99654ec9e18ea01a9fc848449213ce28521943bc5d593dd2cac65310b6a918f611ea283b3a0377347eb718e99dd59224b8fad8adb223d483fa9fecb
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | f40afee38155c5163ba92e3fa3973263ca975f3b72ac18535799fb29180413542ef86f09c87681161affeef94eb0bd38e7cf571a73ab0f51a88420f1aedeaeec
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-arm.tar.gz) | 6088b11767b77f0ec932a9f1aee9f0c7795c3627529f259edf4d8b1be2e1a324a75c89caed65c6aa277c2fd6ee23b3ebeb05901f351cd2dde0a833bbbd6d6d07
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | e790c491d057721b94d0d2ad22dd5c75400e8602e95276471f20cd2181f52c5be38e66b445d8360e1fb671627217eb0b7735b485715844d0e9908cf3de249464
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | 04f696cfab66f92b4b22c23807a49c344d6a157a9ac3284a267613369b7f9f5887f67902cb8a2949caa204f89fdc65fe442a03c2c454013523f81b56476d39a0
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | c671e20f69f70ec567fb16bbed2fecac3099998a3365def1e0755e41509531fd65768f7a04015b27b17e6a5884e65cddb82ff30a8374ed011c5e2008817259db
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | 23d712fb2d455b5095d31b9c280d92442f7871786808528a1b39b9babf169dc7ae467f1ee2b2820089d69aa2342441d0290edf4f710808c78277e612f870321d
+
+## Changelog since v1.19.0-beta.1
+
+## Changes by Kind
+
+### Deprecation
+
+- Kubeadm: remove the deprecated "--use-api" flag for "kubeadm alpha certs renew" ([#90143](https://github.com/kubernetes/kubernetes/pull/90143), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Scheduler's alpha feature 'ResourceLimitsPriorityFunction' is completely removed due to lack of usage ([#91883](https://github.com/kubernetes/kubernetes/pull/91883), [@SataQiu](https://github.com/SataQiu)) [SIG Scheduling and Testing]
+
+### API Change
+
+- Remove `BindTimeoutSeconds` from schedule configuration `KubeSchedulerConfiguration` ([#91580](https://github.com/kubernetes/kubernetes/pull/91580), [@cofyc](https://github.com/cofyc)) [SIG Scheduling and Testing]
+- Resolve regression in metadata.managedFields handling in update/patch requests submitted by older API clients ([#91748](https://github.com/kubernetes/kubernetes/pull/91748), [@apelisse](https://github.com/apelisse)) [SIG API Machinery and Testing]
+- The CertificateSigningRequest API is promoted to certificates.k8s.io/v1 with the following changes:
+  - `spec.signerName` is now required, and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
+  - `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
+  - `status.conditions` may not contain duplicate types
+  - `status.conditions[*].status` is now required
+  - `status.certificate` must be PEM-encoded, and contain only CERTIFICATE blocks ([#91685](https://github.com/kubernetes/kubernetes/pull/91685), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, Auth, CLI and Testing]
+- The Kubelet's `--cloud-provider` and `--cloud-config` options are now marked as deprecated. ([#90408](https://github.com/kubernetes/kubernetes/pull/90408), [@knabben](https://github.com/knabben)) [SIG Cloud Provider and Node]
+
+### Feature
+
+- A new extension point `PostFilter` is introduced to scheduler framework which runs after Filter phase to resolve scheduling filter failures. A typical implementation is running preemption logic. ([#91314](https://github.com/kubernetes/kubernetes/pull/91314), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Added --privileged flag to kubectl run ([#90569](https://github.com/kubernetes/kubernetes/pull/90569), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- Enable feature Gate DefaultPodTopologySpread to use PodTopologySpread plugin to do defaultspreading. In doing so, legacy DefaultPodTopologySpread plugin is disabled. ([#91793](https://github.com/kubernetes/kubernetes/pull/91793), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Extend AWS azToRegion method to support Local Zones ([#90874](https://github.com/kubernetes/kubernetes/pull/90874), [@Jeffwan](https://github.com/Jeffwan)) [SIG Cloud Provider]
+- Kube-Proxy now supports IPv6DualStack on Windows with the IPv6DualStack feature gate. ([#90853](https://github.com/kubernetes/kubernetes/pull/90853), [@kumarvin123](https://github.com/kumarvin123)) [SIG Network, Node and Windows]
+- Kube-controller-manager: the `--experimental-cluster-signing-duration` flag is marked as deprecated for removal in v1.22, and is replaced with `--cluster-signing-duration`. ([#91154](https://github.com/kubernetes/kubernetes/pull/91154), [@liggitt](https://github.com/liggitt)) [SIG Auth and Cloud Provider]
+- Support kubectl create deployment with replicas ([#91562](https://github.com/kubernetes/kubernetes/pull/91562), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- The RotateKubeletClientCertificate feature gate has been promoted to GA, and the kubelet --feature-gate RotateKubeletClientCertificate parameter will be removed in 1.20. ([#91780](https://github.com/kubernetes/kubernetes/pull/91780), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- The metric label name of `kubernetes_build_info` has been updated from `camel case` to `snake case`:
+  - gitVersion --> git_version
+  - gitCommit --> git_commit
+  - gitTreeState --> git_tree_state
+  - buildDate --> build_date
+  - goVersion --> go_version
+  
+  This change happens in `kube-apiserver`、`kube-scheduler`、`kube-proxy` and `kube-controller-manager`. ([#91805](https://github.com/kubernetes/kubernetes/pull/91805), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
+- `EventRecorder()` is exposed to `FrameworkHandle` interface so that scheduler plugin developers can choose to log cluster-level events. ([#92010](https://github.com/kubernetes/kubernetes/pull/92010), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+
+### Bug or Regression
+
+- Azure: set dest prefix and port for IPv6 inbound security rule ([#91831](https://github.com/kubernetes/kubernetes/pull/91831), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Fix etcd version migration script in etcd image. ([#91925](https://github.com/kubernetes/kubernetes/pull/91925), [@wenjiaswe](https://github.com/wenjiaswe)) [SIG API Machinery]
+- Fix issues when supported huge page sizes changes ([#80831](https://github.com/kubernetes/kubernetes/pull/80831), [@odinuge](https://github.com/odinuge)) [SIG Node and Testing]
+- Fix kubectl describe output format for empty annotations. ([#91405](https://github.com/kubernetes/kubernetes/pull/91405), [@iyashu](https://github.com/iyashu)) [SIG CLI]
+- Fixed an issue that a Pod's nominatedNodeName cannot be cleared upon node deletion. ([#91750](https://github.com/kubernetes/kubernetes/pull/91750), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Fixed several bugs involving the IPFamily field when creating or updating services
+  in clusters with the IPv6DualStack feature gate enabled.
+  
+  Beware that the behavior of the IPFamily field is strange and inconsistent and will
+  likely be changed before the dual-stack feature goes GA. Users should treat the
+  field as "write-only" for now and should not make any assumptions about a service
+  based on its current IPFamily value. ([#91400](https://github.com/kubernetes/kubernetes/pull/91400), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+- Kube-apiserver: fixes scale subresource patch handling to avoid returning unnecessary 409 Conflict error to clients ([#90342](https://github.com/kubernetes/kubernetes/pull/90342), [@liggitt](https://github.com/liggitt)) [SIG Apps, Autoscaling and Testing]
+- Kube-up: fixes setup of validating admission webhook credential configuration ([#91995](https://github.com/kubernetes/kubernetes/pull/91995), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Cluster Lifecycle]
+- Kubeadm: Add retries for kubeadm join / UpdateStatus to make update status more resilient by adding a retry loop to this operation ([#91952](https://github.com/kubernetes/kubernetes/pull/91952), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- On AWS nodes with multiple network interfaces, kubelet should now more reliably report addresses from secondary interfaces. ([#91889](https://github.com/kubernetes/kubernetes/pull/91889), [@anguslees](https://github.com/anguslees)) [SIG Cloud Provider]
+- Resolve regression in metadata.managedFields handling in create/update/patch requests not using server-side apply ([#91690](https://github.com/kubernetes/kubernetes/pull/91690), [@apelisse](https://github.com/apelisse)) [SIG API Machinery and Testing]
+
+### Other (Cleanup or Flake)
+
+- Deprecate the `--target-ram-md` flags that is no longer used for anything. ([#91818](https://github.com/kubernetes/kubernetes/pull/91818), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- Replace framework.Failf with ExpectNoError ([#91811](https://github.com/kubernetes/kubernetes/pull/91811), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG Instrumentation, Storage and Testing]
+- The Kubelet's `--experimental-allocatable-ignore-eviction` option is now marked as deprecated. ([#91578](https://github.com/kubernetes/kubernetes/pull/91578), [@knabben](https://github.com/knabben)) [SIG Node]
+- Update corefile-migration library to 1.0.8 ([#91856](https://github.com/kubernetes/kubernetes/pull/91856), [@wawa0210](https://github.com/wawa0210)) [SIG Node]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- github.com/Azure/azure-sdk-for-go: [v40.2.0+incompatible → v43.0.0+incompatible](https://github.com/Azure/azure-sdk-for-go/compare/v40.2.0...v43.0.0)
+- github.com/coredns/corefile-migration: [v1.0.6 → v1.0.8](https://github.com/coredns/corefile-migration/compare/v1.0.6...v1.0.8)
+- k8s.io/klog/v2: v2.0.0 → v2.1.0
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-beta.1
+
+
+## Downloads for v1.19.0-beta.1
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes.tar.gz) | c4ab79e987790fbda842310525abecee60861e44374c414159e60d74e85b4dd36d9d49253b8e7f08aec36a031726f9517d0a401fb748e41835ae2dc86aee069d
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-src.tar.gz) | 08d1aadb8a31b35f3bc39f44d8f97b7e98951f833bb87f485f318c6acfdb53539851fbb2d4565036e00b6f620c5b1882c6f9620759c3b36833da1d6b2b0610f2
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-darwin-386.tar.gz) | 55eb230fdb4e60ded6c456ec6e03363c6d55e145a956aa5eff0c2b38d8ecfe848b4a404169def45d392e747e4d04ee71fe3182ab1e6426110901ccfb2e1bc17f
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | ddc03644081928bd352c40077f2a075961c90a7159964be072b3e05ec170a17d6d78182d90210c18d24d61e75b45eae3d1b1486626db9e28f692dfb33196615c
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-386.tar.gz) | 6e1e00a53289bd9a4d74a61fce4665786051aafe8fef8d1d42de88ba987911bfb7fd5f4a2c3771ae830819546cf9f4badd94fd90c50ca74367c1ace748e8eafd
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | 2c4db87c61bc4a528eb2af9246648fc7a015741fe52f551951fda786c252eca1dc48a4325be70e6f80f1560f773b763242334ad4fe06657af290e610f10bc231
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-arm.tar.gz) | 8a2bebf67cbd8f91ba38edc36a239aa50d3e58187827763eb5778a5ca0d9d35be97e193b794bff415e8f5de071e47659033dc0420e038d78cc32e841a417a62a
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | f2d0029efc03bf17554c01c11e77b161b8956d9da4b17962ca878378169cbdee04722bbda87279f4b7431c91db0e92bfede45dcc6d971f34d3fe891339b7c47b
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | 45eb3fe40951ba152f05aa0fe41b7c17ffb91ee3cecb12ec19d2d9cdb467267c1eb5696660687852da314eb8a14a9ebf5f5da21eca252e1c2e3b18dca151ad0d
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | 2097ac5d593dd0951a34df9bdf7883b5c228da262042904ee3a2ccfd1f9c955ff6a3a59961850053e41646bce8fc70a023efe9e9fe49f14f9a6276c8da22f907
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-windows-386.tar.gz) | c38b034e8ac3a5972a01f36b184fe1a195f6a422a3c6564f1f3faff858b1220173b6ab934e7b7ec200931fd7d9456e947572620d82d02e7b05fc61a7fb67ec70
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | 0501694734381914882836e067dc177e8bccd48a4826e286017dc5f858f27cdef348edbb664dda59162f6cd3ac14a9e491e314a3ea032dec43bc77610ce8c8bc
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | 0dd2058889eabbf0b05b6fafd593997ff9911467f0fc567c142583adf0474f4d0e2f4024b4906ff9ee4264d1cbbfde66596ccb8c73b3d5bb79f67e5eb4b3258a
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-arm.tar.gz) | 9c3a33d7c198116386178a4f8ee7d4df82e810d6f26833f19f93eff112c29f9f89e5ee790013ad1d497856ecb2662ee95a49fc6a41f0d33cc67e431d06135b88
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | 11f83132f729bec4a4d84fc1983dbd5ddd1643d000dc74c6e05f35637de21533834a572692fc1281c7b0bd29ee93e721fb00e276983e36c327a1950266b17f6d
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | 949334065d968f10207089db6175dcc4bf9432b3b48b120f689cd39c56562a0f4f60d774c95a20a5391d0467140a4c3cb6b2a2dfedccfda6c20f333a63ebcf81
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | 29e8f6a22969d8ab99bf6d272215f53d8f7a125d0c5c20981dcfe960ed440369f831c71a94bb61974b486421e4e9ed936a9421a1be6f02a40e456daab4995663
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | 3d9767e97a40b501f29bbfc652c8fd841eae1dee22a97fdc20115e670081de7fa8e84f6e1be7bbf2376b59c5eef15fb5291415ae2e24ce4c9c5e141faa38c47c
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-arm.tar.gz) | 8ccf401e0bd0c59403af49046b49cf556ff164fca12c5233169a80e18cc4367f404fd7edd236bb862bff9fd25b687d48a8d57d5567809b89fd2727549d0dc48f
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | 3e1fa2bde05a4baec6ddd43cd1994d155a143b9c825ab5dafe766efc305cb1aad92d6026c41c05e9da114a04226361fb6b0510b98e3b05c3ed510da23db403b3
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | 01df4be687f5634afa0ab5ef06f8cee17079264aa452f00a45eccb8ace654c9acc6582f4c74e8242e6ca7715bc48bf2a7d2c4d3d1eef69106f99c8208bc245c4
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | 5523b0b53c30b478b1a9e1df991607886acdcde8605e1b44ef91c94993ca2256c74f6e38fbdd24918d7dbf7afd5cd73d24a3f7ff911e9762819776cc19935363
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | 8e7ebf000bc8dec1079a775576807c0a11764d20a59e16f89d93c948532ba5e6864efd3e08c3e8cc5bd7e7f97bb65baefbf2f01cb226897abd5e01997a4c4f75
+
+## Changelog since v1.19.0-alpha.3
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+ - ACTION REQUIRED : Switch core master base images (kube-controller-manager) from debian to distroless. If you need Flex Volumes support using scripts, please build your own image with required packages (like bash) ([#91329](https://github.com/kubernetes/kubernetes/pull/91329), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release, Storage and Testing]
+  - Kubeadm: Move the "kubeadm init" phase "kubelet-start" later in the init workflow, after the "kubeconfig" phase. This makes kubeadm start the kubelet only after the KubeletConfiguration component config file (/var/lib/kubelet/config.yaml) is generated and solves a problem where init systems like OpenRC cannot crashloop the kubelet service. ([#90892](https://github.com/kubernetes/kubernetes/pull/90892), [@xphoniex](https://github.com/xphoniex)) [SIG Cluster Lifecycle]
+ 
+## Changes by Kind
+
+### API Change
+
+- CertificateSigningRequest API conditions were updated:
+  - a `status` field was added; this field defaults to `True`, and may only be set to `True` for `Approved`, `Denied`, and `Failed` conditions
+  - a `lastTransitionTime` field was added
+  - a `Failed` condition type was added to allow signers to indicate permanent failure; this condition can be added via the `certificatesigningrequests/status` subresource.
+  - `Approved` and `Denied` conditions are mutually exclusive
+  - `Approved`, `Denied`, and `Failed` conditions can no longer be removed from a CSR ([#90191](https://github.com/kubernetes/kubernetes/pull/90191), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, Auth, CLI and Node]
+- EnvVarSource api doc bug fixes ([#91194](https://github.com/kubernetes/kubernetes/pull/91194), [@wawa0210](https://github.com/wawa0210)) [SIG Apps]
+- Fixed: log timestamps now include trailing zeros to maintain a fixed width ([#91207](https://github.com/kubernetes/kubernetes/pull/91207), [@iamchuckss](https://github.com/iamchuckss)) [SIG Apps and Node]
+- The Kubelet's --node-status-max-images option is now available via the Kubelet config file field nodeStatusMaxImage ([#91275](https://github.com/kubernetes/kubernetes/pull/91275), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's --seccomp-profile-root option is now available via the Kubelet config file field seccompProfileRoot. ([#91182](https://github.com/kubernetes/kubernetes/pull/91182), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--enable-server` and `--provider-id` option is now available via the Kubelet config file field `enableServer` and `providerID` respectively. ([#90494](https://github.com/kubernetes/kubernetes/pull/90494), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--really-crash-for-testing` and  `--chaos-chance` options are now marked as deprecated. ([#90499](https://github.com/kubernetes/kubernetes/pull/90499), [@knabben](https://github.com/knabben)) [SIG Node]
+- The alpha `DynamicAuditing` feature gate and `auditregistration.k8s.io/v1alpha1` API have been removed and are no longer supported. ([#91502](https://github.com/kubernetes/kubernetes/pull/91502), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and Testing]
+- `NodeResourcesLeastAllocated` and `NodeResourcesMostAllocated` plugins now support customized weight on the CPU and memory. ([#90544](https://github.com/kubernetes/kubernetes/pull/90544), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+- `PostFilter` type is added to scheduler component config API on version v1beta1. ([#91547](https://github.com/kubernetes/kubernetes/pull/91547), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- `kubescheduler.config.k8s.io` is now beta ([#91420](https://github.com/kubernetes/kubernetes/pull/91420), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
+
+### Feature
+
+- Add --logging-format flag for component-base. Defaults to "text" using unchanged klog. ([#89683](https://github.com/kubernetes/kubernetes/pull/89683), [@yuzhiquan](https://github.com/yuzhiquan)) [SIG Instrumentation]
+- Add --port flag to kubectl create deployment ([#91113](https://github.com/kubernetes/kubernetes/pull/91113), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
+- Add .import-restrictions file to cmd/cloud-controller-manager. ([#90630](https://github.com/kubernetes/kubernetes/pull/90630), [@nilo19](https://github.com/nilo19)) [SIG API Machinery and Cloud Provider]
+- Add Annotations to CRI-API ImageSpec objects. ([#90061](https://github.com/kubernetes/kubernetes/pull/90061), [@marosset](https://github.com/marosset)) [SIG Node and Windows]
+- Added feature support to Windows for configuring session affinity of Kubernetes services.
+  required: [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) (or higher) ([#91701](https://github.com/kubernetes/kubernetes/pull/91701), [@elweb9858](https://github.com/elweb9858)) [SIG Network and Windows]
+- Added service.beta.kubernetes.io/aws-load-balancer-target-node-labels annotation to target nodes in AWS LoadBalancer Services ([#90943](https://github.com/kubernetes/kubernetes/pull/90943), [@foobarfran](https://github.com/foobarfran)) [SIG Cloud Provider]
+- Feat: azure disk migration go beta in 1.19 ([#90896](https://github.com/kubernetes/kubernetes/pull/90896), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-addon-manager has been updated to v9.1.1 to allow overriding the default list of whitelisted resources (https://github.com/kubernetes/kubernetes/pull/91018) ([#91240](https://github.com/kubernetes/kubernetes/pull/91240), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing]
+- Kubeadm now distinguishes between generated and user supplied component configs, regenerating the former ones if a config upgrade is required ([#86070](https://github.com/kubernetes/kubernetes/pull/86070), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: add startup probes for static Pods to protect slow starting containers ([#91179](https://github.com/kubernetes/kubernetes/pull/91179), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubelets configured to rotate client certificates now publish a `certificate_manager_server_ttl_seconds` gauge metric indicating the remaining seconds until certificate expiration. ([#91148](https://github.com/kubernetes/kubernetes/pull/91148), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Local-up-cluster.sh installs CSI snapshotter by default now, can be disabled with ENABLE_CSI_SNAPSHOTTER=false. ([#91504](https://github.com/kubernetes/kubernetes/pull/91504), [@pohly](https://github.com/pohly)) [SIG Storage]
+- Rest.Config now supports a flag to override proxy configuration that was previously only configurable through environment variables. ([#81443](https://github.com/kubernetes/kubernetes/pull/81443), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery and Node]
+- Scores from PodTopologySpreading have reduced differentiation as maxSkew increases. ([#90820](https://github.com/kubernetes/kubernetes/pull/90820), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Service controller: only sync LB node pools when relevant fields in Node changes ([#90769](https://github.com/kubernetes/kubernetes/pull/90769), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+- Switch core master base images (kube-apiserver, kube-scheduler) from debian to distroless ([#90674](https://github.com/kubernetes/kubernetes/pull/90674), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release and Scalability]
+- Switch etcd image (with migration scripts) from debian to distroless ([#91171](https://github.com/kubernetes/kubernetes/pull/91171), [@dims](https://github.com/dims)) [SIG API Machinery and Cloud Provider]
+- The `certificatesigningrequests/approval` subresource now supports patch API requests ([#91558](https://github.com/kubernetes/kubernetes/pull/91558), [@liggitt](https://github.com/liggitt)) [SIG Auth and Testing]
+- Update cri-tools to v1.18.0 ([#89720](https://github.com/kubernetes/kubernetes/pull/89720), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cloud Provider, Cluster Lifecycle, Release and Scalability]
+- Weight of PodTopologySpread scheduling Score is doubled. ([#91258](https://github.com/kubernetes/kubernetes/pull/91258), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- `maxThreshold` of `ImageLocality` plugin is now scaled by the number of images in the pod, which helps to distinguish the node priorities for pod with several images. ([#91138](https://github.com/kubernetes/kubernetes/pull/91138), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+
+### Bug or Regression
+
+- Add support for TLS 1.3 ciphers: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 and TLS_AES_256_GCM_SHA384. ([#90843](https://github.com/kubernetes/kubernetes/pull/90843), [@pjbgf](https://github.com/pjbgf)) [SIG API Machinery, Auth and Cluster Lifecycle]
+- Base-images: Update to kube-cross:v1.13.9-5 ([#90963](https://github.com/kubernetes/kubernetes/pull/90963), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- CloudNodeLifecycleController will check node existence status before shutdown status when monitoring nodes. ([#90737](https://github.com/kubernetes/kubernetes/pull/90737), [@jiahuif](https://github.com/jiahuif)) [SIG Apps and Cloud Provider]
+- First pod with required affinity terms can schedule only on nodes with matching topology keys. ([#91168](https://github.com/kubernetes/kubernetes/pull/91168), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- Fix VirtualMachineScaleSets.virtualMachines.GET not allowed issues when customers have set VMSS orchestrationMode. ([#91097](https://github.com/kubernetes/kubernetes/pull/91097), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix a racing issue that scheduler may perform unnecessary scheduling attempt. ([#90660](https://github.com/kubernetes/kubernetes/pull/90660), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Fix kubectl create --dryrun client ignore namespace ([#90502](https://github.com/kubernetes/kubernetes/pull/90502), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix kubectl create secret docker-registry --from-file not usable ([#90960](https://github.com/kubernetes/kubernetes/pull/90960), [@zhouya0](https://github.com/zhouya0)) [SIG CLI and Testing]
+- Fix kubectl describe node for users not having access to lease information. ([#90469](https://github.com/kubernetes/kubernetes/pull/90469), [@uthark](https://github.com/uthark)) [SIG CLI]
+- Fix kubectl run  --dry-run client  ignore namespace ([#90785](https://github.com/kubernetes/kubernetes/pull/90785), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix public IP not shown issues after assigning public IP to Azure VMs ([#90886](https://github.com/kubernetes/kubernetes/pull/90886), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix: add azure file migration support on annotation support ([#91093](https://github.com/kubernetes/kubernetes/pull/91093), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Node]
+- Fix: azure disk dangling attach issue which would cause API throttling ([#90749](https://github.com/kubernetes/kubernetes/pull/90749), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: fix topology issue in azure disk storage class migration ([#91196](https://github.com/kubernetes/kubernetes/pull/91196), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: support removal of nodes backed by deleted non VMSS instances on Azure ([#91184](https://github.com/kubernetes/kubernetes/pull/91184), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Fixed a regression preventing garbage collection of RBAC role and binding objects ([#90534](https://github.com/kubernetes/kubernetes/pull/90534), [@apelisse](https://github.com/apelisse)) [SIG Auth]
+- For external storage e2e test suite, update external driver, to pick snapshot provisioner from VolumeSnapshotClass, when a VolumeSnapshotClass is explicitly provided as an input. ([#90878](https://github.com/kubernetes/kubernetes/pull/90878), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing]
+- Get-kube.sh: fix order to get the binaries from the right bucket ([#91635](https://github.com/kubernetes/kubernetes/pull/91635), [@cpanato](https://github.com/cpanato)) [SIG Release]
+- In a HA env, during the period a standby scheduler lost connection to API server, if a Pod is deleted and recreated, and the standby scheduler becomes master afterwards, there could be a scheduler cache corruption. This PR fixes this issue. ([#91126](https://github.com/kubernetes/kubernetes/pull/91126), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- Kubeadm: during "reset" do not remove the only remaining stacked etcd member from the cluster and just proceed with the cleanup of the local etcd storage. ([#91145](https://github.com/kubernetes/kubernetes/pull/91145), [@tnqn](https://github.com/tnqn)) [SIG Cluster Lifecycle]
+- Kubeadm: increase robustness for "kubeadm join" when adding etcd members on slower setups ([#90645](https://github.com/kubernetes/kubernetes/pull/90645), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Pod Conditions updates are skipped for re-scheduling attempts ([#91252](https://github.com/kubernetes/kubernetes/pull/91252), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Prevent PVC requested size overflow when expanding or creating a volume ([#90907](https://github.com/kubernetes/kubernetes/pull/90907), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage]
+- Resolves an issue using `kubectl certificate approve/deny` against a server serving the v1 CSR API ([#91691](https://github.com/kubernetes/kubernetes/pull/91691), [@liggitt](https://github.com/liggitt)) [SIG Auth and CLI]
+- Scheduling failures due to no nodes available are now reported as unschedulable under ```schedule_attempts_total``` metric. ([#90989](https://github.com/kubernetes/kubernetes/pull/90989), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- The following components that do not expect non-empty, non-flag arguments will now print an error message and exit if an argument is specified: cloud-controller-manager, kube-apiserver, kube-controller-manager, kube-proxy, kubeadm {alpha|config|token|version}, kubemark. Flags should be prefixed with a single dash "-" (0x45) for short form or double dash "--" for long form. Before this change, malformed flags (for example, starting with a non-ascii dash character such as 0x8211: "–") would have been silently treated as positional arguments and ignored. ([#91349](https://github.com/kubernetes/kubernetes/pull/91349), [@neolit123](https://github.com/neolit123)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle, Network and Scheduling]
+- When evicting, Pods in Pending state are removed without checking PDBs. ([#83906](https://github.com/kubernetes/kubernetes/pull/83906), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery, Apps, Node and Scheduling]
+
+### Other (Cleanup or Flake)
+
+- Adds additional testing to ensure that udp pods conntrack are cleaned up ([#90180](https://github.com/kubernetes/kubernetes/pull/90180), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Architecture, Network and Testing]
+- Adjusts the fsType for cinder values to be `ext4` if no fsType is specified. ([#90608](https://github.com/kubernetes/kubernetes/pull/90608), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
+- Change beta.kubernetes.io/os to kubernetes.io/os ([#89461](https://github.com/kubernetes/kubernetes/pull/89461), [@wawa0210](https://github.com/wawa0210)) [SIG Cloud Provider and Cluster Lifecycle]
+- Content-type and verb for request metrics are now bounded to a known set. ([#89451](https://github.com/kubernetes/kubernetes/pull/89451), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery and Instrumentation]
+- Emit `WaitingForPodScheduled` event if the unbound PVC is in delay binding mode but used by a pod ([#91455](https://github.com/kubernetes/kubernetes/pull/91455), [@cofyc](https://github.com/cofyc)) [SIG Storage]
+- Improve server-side apply conflict errors by setting dedicated kubectl subcommand field managers ([#88885](https://github.com/kubernetes/kubernetes/pull/88885), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- It is now possible to use the service annotation `cloud.google.com/network-tier: Standard` to configure the Network Tier of the GCE Loadbalancer ([#88532](https://github.com/kubernetes/kubernetes/pull/88532), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider, Network and Testing]
+- Kube-scheduler: The metric name `scheduler_total_preemption_attempts` has been renamed to `scheduler_preemption_attempts_total`. ([#91448](https://github.com/kubernetes/kubernetes/pull/91448), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Scheduling]
+- Kubeadm now forwards the IPv6DualStack feature gate using the kubelet component config, instead of the kubelet command line ([#90840](https://github.com/kubernetes/kubernetes/pull/90840), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: do not use a DaemonSet for the pre-pull of control-plane images during "kubeadm upgrade apply". Individual node upgrades now pull the required images using a preflight check. The flag "--image-pull-timeout" for "kubeadm upgrade apply" is now deprecated and will be removed in a future release following a GA deprecation policy. ([#90788](https://github.com/kubernetes/kubernetes/pull/90788), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- Kubeadm: use two separate checks on /livez and /readyz for the kube-apiserver static Pod instead of using /healthz ([#90970](https://github.com/kubernetes/kubernetes/pull/90970), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+- NONE ([#91597](https://github.com/kubernetes/kubernetes/pull/91597), [@elmiko](https://github.com/elmiko)) [SIG Autoscaling and Testing]
+- Remove deprecated --server-dry-run flag from kubectl apply ([#91308](https://github.com/kubernetes/kubernetes/pull/91308), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- The "HostPath should give a volume the correct mode" is no longer a conformance test ([#90861](https://github.com/kubernetes/kubernetes/pull/90861), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+- The Kubelet's --experimental-mounter-path and --experimental-check-node-capabilities-before-mount options are now marked as deprecated. ([#91373](https://github.com/kubernetes/kubernetes/pull/91373), [@knabben](https://github.com/knabben)) [SIG Node]
+- The kube-apiserver `--kubelet-https` flag is deprecated. kube-apiserver connections to kubelets now unconditionally use `https` (kubelets have unconditionally used `https` to serve the endpoints the apiserver communicates with since before v1.0). ([#91630](https://github.com/kubernetes/kubernetes/pull/91630), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Node]
+- Update CNI to v0.8.6 ([#91370](https://github.com/kubernetes/kubernetes/pull/91370), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Release and Testing]
+- `beta.kubernetes.io/os` and `beta.kubernetes.io/arch` node labels are deprecated. Update node selectors to use `kubernetes.io/os` and `kubernetes.io/arch`. ([#91046](https://github.com/kubernetes/kubernetes/pull/91046), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and Node]
+- base-images: Use debian-base:v2.1.0 ([#90697](https://github.com/kubernetes/kubernetes/pull/90697), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery and Release]
+- base-images: Use debian-iptables:v12.1.0 ([#90782](https://github.com/kubernetes/kubernetes/pull/90782), [@justaugustus](https://github.com/justaugustus)) [SIG Release]
+
+## Dependencies
+
+### Added
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/containerd/cgroups: [bf292b2](https://github.com/containerd/cgroups/tree/bf292b2)
+- github.com/containerd/continuity: [aaeac12](https://github.com/containerd/continuity/tree/aaeac12)
+- github.com/containerd/fifo: [a9fb20d](https://github.com/containerd/fifo/tree/a9fb20d)
+- github.com/containerd/go-runc: [5a6d9f3](https://github.com/containerd/go-runc/tree/5a6d9f3)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/google/renameio: [v0.1.0](https://github.com/google/renameio/tree/v0.1.0)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/rogpeppe/go-internal: [v1.3.0](https://github.com/rogpeppe/go-internal/tree/v1.3.0)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- golang.org/x/mod: v0.1.0
+- google.golang.org/protobuf: v1.23.0
+- gopkg.in/errgo.v2: v2.1.0
+- k8s.io/klog/v2: v2.0.0
+
+### Changed
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/Microsoft/hcsshim: [672e52e → v0.8.9](https://github.com/Microsoft/hcsshim/compare/672e52e...v0.8.9)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.3 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.3...v1.4.2)
+- github.com/google/cadvisor: [8af10c6 → 6a8d614](https://github.com/google/cadvisor/compare/8af10c6...6a8d614)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.9](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.9)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.6.0](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.6.0)
+- github.com/prometheus/common: [v0.4.1 → v0.9.1](https://github.com/prometheus/common/compare/v0.4.1...v0.9.1)
+- github.com/prometheus/procfs: [v0.0.5 → v0.0.11](https://github.com/prometheus/procfs/compare/v0.0.5...v0.0.11)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: f3c370f → ca5a221
+- honnef.co/go/tools: e561f67 → v0.0.1-2019.2.3
+- k8s.io/gengo: e0e292d → 8167cfd
+- k8s.io/kube-openapi: e1beb1b → 656914f
+- k8s.io/utils: a9aa75a → 2df71eb
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → 33b9978
+
+### Removed
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- k8s.io/klog: v1.0.0
+
+
+
+# v1.19.0-beta.0
+
+
+## Downloads for v1.19.0-beta.0
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes.tar.gz) | 8c7e820b8bd7a8f742b7560cafe6ae1acc4c9836ae23d1b10d987b4de6a690826be75c68b8f76ec027097e8dfd861afb1d229b3687f0b82afcfe7b4d6481242e
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-src.tar.gz) | 543e9d36fd8b2de3e19631d3295d3a7706e6e88bbd3adb2d558b27b3179a3961455f4f04f0d4a5adcff1466779e1b08023fe64dc2ab39813b37adfbbc779dec7
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-darwin-386.tar.gz) | 3ef37ef367a8d9803f023f6994d73ff217865654a69778c1ea3f58c88afbf25ff5d8d6bec9c608ac647c2654978228c4e63f30eec2a89d16d60f4a1c5f333b22
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-darwin-amd64.tar.gz) | edb02b0b8d6a1c2167fbce4a85d84fb413566d3a76839fd366801414ca8ad2d55a5417b39b4cac6b65fddf13c1b3259791a607703773241ca22a67945ecb0014
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-386.tar.gz) | dafe93489df7328ae23f4bdf0a9d2e234e18effe7e042b217fe2dd1355e527a54bab3fb664696ed606a8ebedce57da4ee12647ec1befa2755bd4c43d9d016063
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-amd64.tar.gz) | d8e2bf8c9dd665410c2e7ceaa98bc4fc4f966753b7ade91dcef3b5eff45e0dda63bd634610c8761392a7804deb96c6b030c292280bf236b8b29f63b7f1af3737
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-arm.tar.gz) | d590d3d07d0ebbb562bce480c7cbe4e60b99feba24376c216fe73d8b99a246e2cd2acb72abe1427bde3e541d94d55b7688daf9e6961e4cbc6b875ac4eeea6e62
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-arm64.tar.gz) | f9647a99a566c9febd348c1c4a8e5c05326058eab076292a8bb5d3a2b882ee49287903f8e0e036b40af294aa3571edd23e65f3de91330ac9af0c10350b02583d
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-ppc64le.tar.gz) | 662f009bc393734a89203d7956942d849bad29e28448e7baa017d1ac2ec2d26d7290da4a44bccb99ed960b2e336d9d98908c98f8a3d9fe1c54df2d134c799cad
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-s390x.tar.gz) | 61fdf4aff78dcdb721b82a3602bf5bc94d44d51ab6607b255a9c2218bb3e4b57f6e656c2ee0dd68586fb53acbeff800d6fd03e4642dded49735a93356e7c5703
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-windows-386.tar.gz) | 20d1e803b10b3bee09a7a206473ba320cc5f1120278d8f6e0136c388b2720da7264b917cd4738488b1d0a9aa922eb581c1f540715a6c2042c4dd7b217b6a9a0a
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-windows-amd64.tar.gz) | b85d729ec269f6aad0b6d2f95f3648fbea84330d2fbfde2267a519bc08c42d70d7b658b0e41c3b0d5f665702a8f1bbb37652753de34708ae3a03e45175c8b92c
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-amd64.tar.gz) | c3641bdb0a8d8eff5086d24b71c6547131092b21f976b080dc48129f91de3da560fed6edf880eab1d205017ad74be716a5b970e4bbc00d753c005e5932b3d319
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-arm.tar.gz) | 7c29b8e33ade23a787330d28da22bf056610dae4d3e15574c56c46340afe5e0fdb00126ae3fd64fd70a26d1a87019f47e401682b88fa1167368c7edbecc72ccf
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-arm64.tar.gz) | 27cd6042425eb94bb468431599782467ed818bcc51d75e8cb251c287a806b60a5cce50d4ae7525348c5446eaa45f849bc3fe3e6ac7248b54f3ebae8bf6553c3f
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-ppc64le.tar.gz) | ede896424eb12ec07dd3756cbe808ca3915f51227e7b927795402943d81a99bb61654fd8f485a838c2faf199d4a55071af5bd8e69e85669a7f4a0b0e84a093cc
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-s390x.tar.gz) | 4e48d4f5afd22f0ae6ade7da4877238fd2a5c10ae3dea2ae721c39ac454b0b295e1d7501e26bddee4bc0289e79e33dadca255a52a645bee98cf81acf937db0ef
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-amd64.tar.gz) | 8025bd8deb9586487fcf268bdaf99e8fd9f9433d9e7221c29363d1d66c4cbd55a2c44e6c89bc8133828c6a1aa0c42c2359b74846dfb71765c9ae8f21b8170625
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-arm.tar.gz) | 25787d47c8cc1e9445218d3a947b443d261266033187f8b7bc6141ae353a6806503fe72e3626f058236d4cd7f284348d2cc8ccb7a0219b9ddd7c6a336dae360b
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-arm64.tar.gz) | ff737a7310057bdfd603f2853b15f79dc2b54a3cbbbd7a8ffd4d9756720fa5a02637ffc10a381eeee58bef61024ff348a49f3044a6dfa0ba99645fda8d08e2da
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-ppc64le.tar.gz) | 2b1144c9ae116306a2c3214b02361083a60a349afc804909f95ea85db3660de5025de69a1860e8fc9e7e92ded335c93b74ecbbb20e1f6266078842d4adaf4161
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-s390x.tar.gz) | 822ec64aef3d65faa668a91177aa7f5d0c78a83cc1284c5e30629eda448ee4b2874cf4cfa6f3d68ad8eb8029dd035bf9fe15f68cc5aa4b644513f054ed7910ae
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-windows-amd64.tar.gz) | 3957cae43211df050c5a9991a48e23ac27d20aec117c580c53fc7edf47caf79ed1e2effa969b5b972968a83e9bdba0b20c46705caca0c35571713041481c1966
+
+## Changelog since v1.19.0-alpha.3
+
+## Changes by Kind
+
+### API Change
+ - EnvVarSource api doc bug fixes ([#91194](https://github.com/kubernetes/kubernetes/pull/91194), [@wawa0210](https://github.com/wawa0210)) [SIG Apps]
+ - The Kubelet's `--really-crash-for-testing` and  `--chaos-chance` options are now marked as deprecated. ([#90499](https://github.com/kubernetes/kubernetes/pull/90499), [@knabben](https://github.com/knabben)) [SIG Node]
+ - `NodeResourcesLeastAllocated` and `NodeResourcesMostAllocated` plugins now support customized weight on the CPU and memory. ([#90544](https://github.com/kubernetes/kubernetes/pull/90544), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+
+### Feature
+ - Add .import-restrictions file to cmd/cloud-controller-manager. ([#90630](https://github.com/kubernetes/kubernetes/pull/90630), [@nilo19](https://github.com/nilo19)) [SIG API Machinery and Cloud Provider]
+ - Add Annotations to CRI-API ImageSpec objects. ([#90061](https://github.com/kubernetes/kubernetes/pull/90061), [@marosset](https://github.com/marosset)) [SIG Node and Windows]
+ - Kubelets configured to rotate client certificates now publish a `certificate_manager_server_ttl_seconds` gauge metric indicating the remaining seconds until certificate expiration. ([#91148](https://github.com/kubernetes/kubernetes/pull/91148), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+ - Rest.Config now supports a flag to override proxy configuration that was previously only configurable through environment variables. ([#81443](https://github.com/kubernetes/kubernetes/pull/81443), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery and Node]
+ - Scores from PodTopologySpreading have reduced differentiation as maxSkew increases. ([#90820](https://github.com/kubernetes/kubernetes/pull/90820), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+ - Service controller: only sync LB node pools when relevant fields in Node changes ([#90769](https://github.com/kubernetes/kubernetes/pull/90769), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+ - Switch core master base images (kube-apiserver, kube-scheduler) from debian to distroless ([#90674](https://github.com/kubernetes/kubernetes/pull/90674), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release and Scalability]
+ - Update cri-tools to v1.18.0 ([#89720](https://github.com/kubernetes/kubernetes/pull/89720), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cloud Provider, Cluster Lifecycle, Release and Scalability]
+
+### Bug or Regression
+ - Add support for TLS 1.3 ciphers: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 and TLS_AES_256_GCM_SHA384. ([#90843](https://github.com/kubernetes/kubernetes/pull/90843), [@pjbgf](https://github.com/pjbgf)) [SIG API Machinery, Auth and Cluster Lifecycle]
+ - Base-images: Update to kube-cross:v1.13.9-5 ([#90963](https://github.com/kubernetes/kubernetes/pull/90963), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+ - CloudNodeLifecycleController will check node existence status before shutdown status when monitoring nodes. ([#90737](https://github.com/kubernetes/kubernetes/pull/90737), [@jiahuif](https://github.com/jiahuif)) [SIG Apps and Cloud Provider]
+ - First pod with required affinity terms can schedule only on nodes with matching topology keys. ([#91168](https://github.com/kubernetes/kubernetes/pull/91168), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+ - Fix VirtualMachineScaleSets.virtualMachines.GET not allowed issues when customers have set VMSS orchestrationMode. ([#91097](https://github.com/kubernetes/kubernetes/pull/91097), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+ - Fix a racing issue that scheduler may perform unnecessary scheduling attempt. ([#90660](https://github.com/kubernetes/kubernetes/pull/90660), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+ - Fix kubectl run  --dry-run client  ignore namespace ([#90785](https://github.com/kubernetes/kubernetes/pull/90785), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+ - Fix public IP not shown issues after assigning public IP to Azure VMs ([#90886](https://github.com/kubernetes/kubernetes/pull/90886), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+ - Fix: azure disk dangling attach issue which would cause API throttling ([#90749](https://github.com/kubernetes/kubernetes/pull/90749), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+ - Fix: support removal of nodes backed by deleted non VMSS instances on Azure ([#91184](https://github.com/kubernetes/kubernetes/pull/91184), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+ - Fixed a regression preventing garbage collection of RBAC role and binding objects ([#90534](https://github.com/kubernetes/kubernetes/pull/90534), [@apelisse](https://github.com/apelisse)) [SIG Auth]
+ - For external storage e2e test suite, update external driver, to pick snapshot provisioner from VolumeSnapshotClass, when a VolumeSnapshotClass is explicitly provided as an input. ([#90878](https://github.com/kubernetes/kubernetes/pull/90878), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing]
+ - In a HA env, during the period a standby scheduler lost connection to API server, if a Pod is deleted and recreated, and the standby scheduler becomes master afterwards, there could be a scheduler cache corruption. This PR fixes this issue. ([#91126](https://github.com/kubernetes/kubernetes/pull/91126), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+ - Kubeadm: increase robustness for "kubeadm join" when adding etcd members on slower setups ([#90645](https://github.com/kubernetes/kubernetes/pull/90645), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+ - Prevent PVC requested size overflow when expanding or creating a volume ([#90907](https://github.com/kubernetes/kubernetes/pull/90907), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage]
+ - Scheduling failures due to no nodes available are now reported as unschedulable under ```schedule_attempts_total``` metric. ([#90989](https://github.com/kubernetes/kubernetes/pull/90989), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+
+### Other (Cleanup or Flake)
+ - Adds additional testing to ensure that udp pods conntrack are cleaned up ([#90180](https://github.com/kubernetes/kubernetes/pull/90180), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Architecture, Network and Testing]
+ - Adjusts the fsType for cinder values to be `ext4` if no fsType is specified. ([#90608](https://github.com/kubernetes/kubernetes/pull/90608), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
+ - Change beta.kubernetes.io/os to kubernetes.io/os ([#89461](https://github.com/kubernetes/kubernetes/pull/89461), [@wawa0210](https://github.com/wawa0210)) [SIG Cloud Provider and Cluster Lifecycle]
+ - Improve server-side apply conflict errors by setting dedicated kubectl subcommand field managers ([#88885](https://github.com/kubernetes/kubernetes/pull/88885), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+ - It is now possible to use the service annotation `cloud.google.com/network-tier: Standard` to configure the Network Tier of the GCE Loadbalancer ([#88532](https://github.com/kubernetes/kubernetes/pull/88532), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider, Network and Testing]
+ - Kubeadm now forwards the IPv6DualStack feature gate using the kubelet component config, instead of the kubelet command line ([#90840](https://github.com/kubernetes/kubernetes/pull/90840), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+ - Kubeadm: do not use a DaemonSet for the pre-pull of control-plane images during "kubeadm upgrade apply". Individual node upgrades now pull the required images using a preflight check. The flag "--image-pull-timeout" for "kubeadm upgrade apply" is now deprecated and will be removed in a future release following a GA deprecation policy. ([#90788](https://github.com/kubernetes/kubernetes/pull/90788), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+ - Kubeadm: use two separate checks on /livez and /readyz for the kube-apiserver static Pod instead of using /healthz ([#90970](https://github.com/kubernetes/kubernetes/pull/90970), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+ - The "HostPath should give a volume the correct mode" is no longer a conformance test ([#90861](https://github.com/kubernetes/kubernetes/pull/90861), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+ - `beta.kubernetes.io/os` and `beta.kubernetes.io/arch` node labels are deprecated. Update node selectors to use `kubernetes.io/os` and `kubernetes.io/arch`. ([#91046](https://github.com/kubernetes/kubernetes/pull/91046), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and Node]
+ - base-images: Use debian-base:v2.1.0 ([#90697](https://github.com/kubernetes/kubernetes/pull/90697), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery and Release]
+ - base-images: Use debian-iptables:v12.1.0 ([#90782](https://github.com/kubernetes/kubernetes/pull/90782), [@justaugustus](https://github.com/justaugustus)) [SIG Release]
+
+## Dependencies
+
+### Added
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/google/renameio: [v0.1.0](https://github.com/google/renameio/tree/v0.1.0)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/rogpeppe/go-internal: [v1.3.0](https://github.com/rogpeppe/go-internal/tree/v1.3.0)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- golang.org/x/mod: v0.1.0
+- google.golang.org/protobuf: v1.23.0
+- gopkg.in/errgo.v2: v2.1.0
+- k8s.io/klog/v2: v2.0.0
+
+### Changed
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.3 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.3...v1.4.2)
+- github.com/google/cadvisor: [8af10c6 → 6a8d614](https://github.com/google/cadvisor/compare/8af10c6...6a8d614)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.9](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.9)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.6.0](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.6.0)
+- github.com/prometheus/common: [v0.4.1 → v0.9.1](https://github.com/prometheus/common/compare/v0.4.1...v0.9.1)
+- github.com/prometheus/procfs: [v0.0.5 → v0.0.11](https://github.com/prometheus/procfs/compare/v0.0.5...v0.0.11)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: f3c370f → ca5a221
+- honnef.co/go/tools: e561f67 → v0.0.1-2019.2.3
+- k8s.io/gengo: e0e292d → 8167cfd
+- k8s.io/kube-openapi: e1beb1b → 656914f
+- k8s.io/utils: a9aa75a → 2df71eb
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → 33b9978
+
+### Removed
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- k8s.io/klog: v1.0.0
+
+
+
+# v1.19.0-alpha.3
+
+[Documentation](https://docs.k8s.io)
+
+## Downloads for v1.19.0-alpha.3
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes.tar.gz) | `49df3a77453b759d3262be6883dd9018426666b4261313725017eed42da1bc8dd1af037ec6c11357a6360c0c32c2486490036e9e132c9026f491325ce353c84b`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-src.tar.gz) | `ddbb0baaf77516dc885c41017f4a8d91d0ff33eeab14009168a1e4d975939ccc6a053a682c2af14346c67fe7b142aa2c1ba32e86a30f2433cefa423764c5332d`
 
 ### Client Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-386.tar.gz) | `bc337bb8f200a789be4b97ce99b9d7be78d35ebd64746307c28339dc4628f56d9903e0818c0888aaa9364357a528d1ac6fd34f74377000f292ec502fbea3837e`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | `38dfa5e0b0cfff39942c913a6bcb2ad8868ec43457d35cffba08217bb6e7531720e0731f8588505f4c81193ce5ec0e5fe6870031cf1403fbbde193acf7e53540`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-386.tar.gz) | `8e63ec7ce29c69241120c037372c6c779e3f16253eabd612c7cbe6aa89326f5160eb5798004d723c5cd72d458811e98dac3574842eb6a57b2798ecd2bbe5bcf9`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | `c1be9f184a7c3f896a785c41cd6ece9d90d8cb9b1f6088bdfb5557d8856c55e455f6688f5f54c2114396d5ae7adc0361e34ebf8e9c498d0187bd785646ccc1d0`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm.tar.gz) | `8eab02453cfd9e847632a774a0e0cf3a33c7619fb4ced7f1840e1f71444e8719b1c8e8cbfdd1f20bb909f3abe39cdcac74f14cb9c878c656d35871b7c37c7cbe`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | `f7df0ec02d2e7e63278d5386e8153cfe2b691b864f17b6452cc824a5f328d688976c975b076e60f1c6b3c859e93e477134fbccc53bb49d9e846fb038b34eee48`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | `36dd5b10addca678a518e6d052c9d6edf473e3f87388a2f03f714c93c5fbfe99ace16cf3b382a531be20a8fe6f4160f8d891800dd2cff5f23c9ca12c2f4a151b`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | `5bdbb44b996ab4ccf3a383780270f5cfdbf174982c300723c8bddf0a48ae5e459476031c1d51b9d30ffd621d0a126c18a5de132ef1d92fca2f3e477665ea10cc`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-386.tar.gz) | `5dea3d4c4e91ef889850143b361974250e99a3c526f5efee23ff9ccdcd2ceca4a2247e7c4f236bdfa77d2150157da5d676ac9c3ba26cf3a2f1e06d8827556f77`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | `db298e698391368703e6aea7f4345aec5a4b8c69f9d8ff6c99fb5804a6cea16d295fb01e70fe943ade3d4ce9200a081ad40da21bd331317ec9213f69b4d6c48f`
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-darwin-386.tar.gz) | `c0fb1afb5b22f6e29cf3e5121299d3a5244a33b7663e041209bcc674a0009842b35b9ebdafa5bd6b91a1e1b67fa891e768627b97ea5258390d95250f07c2defc`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | `f32596863fed32bc8e3f032ef1e4f9f232898ed506624cb1b4877ce2ced2a0821d70b15599258422aa13181ab0e54f38837399ca611ab86cbf3feec03ede8b95`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-386.tar.gz) | `37290244cee54ff05662c2b14b69445eee674d385e6b05ca0b8c8b410ba047cf054033229c78af91670ca1370807753103c25dbb711507edc1c6beca87bd0988`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | `3753eb28b9d68a47ef91fff3e91215015c28bce12828f81c0bbddbde118fd2cf4d580e474e54b1e8176fa547829e2ed08a4df36bbf83b912c831a459821bd581`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | `86b1cdb59a6b4e9de4496e5aa817b1ae7687ac6a93f8b8259cdeb356020773711d360a2ea35f7a8dc1bdd6d31c95e6491abf976afaff3392eb7d2df1008e192c`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | `fbf324e92b93cd8048073b2a627ddc8866020bc4f086604d82bf4733d463411a534d8c8f72565976eb1b32be64aecae8858cd140ef8b7a3c96fcbbf92ca54689`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | `7a6551eca17d29efb5d818e360b53ab2f0284e1091cc537e0a7ce39843d0b77579f26eb14bdeca9aa9e0aa0ef92ce1ccde34bdce84b4a5c1e090206979afb0ea`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | `46352be54882cf3edb949b355e71daea839c9b1955ccfe1085590b81326665d81cabde192327d82e56d6a157e224caefdcfbec3364b9f8b18b5da0cfcb97fc0c`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-windows-386.tar.gz) | `d049bf5f27e5e646ea4aa657aa0a694de57394b0dc60eadf1f7516d1ca6a6db39fc89d34bb6bba0a82f0c140113c2a91c41ad409e0ab41118a104f47eddcb9d2`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | `2e585f6f97b86443a6e3a847c8dfaa29c6323f8d5bbfdb86dc7bf5465ba54f64b35ee55a6d38e9be105a67fff39057ad16db3f3b1c3b9c909578517f4da7e51e`
 
 ### Server Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | `c6284929dd5940e750b48db72ffbc09f73c5ec31ab3db283babb8e4e07cd8cbb27642f592009caae4717981c0db82c16312849ef4cbafe76acc4264c7d5864ac`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm.tar.gz) | `6fc9552cf082c54cc0833b19876117c87ba7feb5a12c7e57f71b52208daf03eaef3ca56bd22b7bce2d6e81b5a23537cf6f5497a6eaa356c0aab1d3de26c309f9`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | `b794b9c399e548949b5bfb2fe71123e86c2034847b2c99aca34b6de718a35355bbecdae9dc2a81c49e3c82fb4b5862526a3f63c2862b438895e12c5ea884f22e`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | `fddaed7a54f97046a91c29534645811c6346e973e22950b2607b8c119c2377e9ec2d32144f81626078cdaeca673129cc4016c1a3dbd3d43674aa777089fb56ac`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | `65951a534bb55069c7419f41cbcdfe2fae31541d8a3f9eca11fc2489addf281c5ad2d13719212657da0be5b898f22b57ac39446d99072872fbacb0a7d59a4f74`
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | `8c41c6abf32ba7040c2cc654765d443e615d96891eacf6bcec24146a8aaf79b9206d13358518958e5ec04eb911ade108d4522ebd8603b88b3e3d95e7d5b24e60`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | `7e54c60bf724e2e3e2cff1197512ead0f73030788877f2f92a7e0deeeabd86e75ce8120eb815bf63909f8a110e647a5fcfddd510efffbd9c339bd0f90caa6706`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | `7c57fd80b18be6dd6b6e17558d12ec0c07c06ce248e99837737fdd39b7f5d752597679748dc6294563f30def986ed712a8f469f3ea1c3a4cbe5d63c44f1d41dc`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | `d22b1d4d8ccf9e9df8f90d35b8d2a1e7916f8d809806743cddc00b15d8ace095c54c61d7c9affd6609a316ee14ba43bf760bfec4276aee8273203aab3e7ac3c1`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | `3177c9a2d6bd116d614fa69ff9cb16b822bee4e36e38f93ece6aeb5d118ae67dbe61546c7f628258ad719e763c127ca32437ded70279ea869cfe4869e06cbdde`
 
 ### Node Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | `992059efb5cae7ed0ef55820368d854bad1c6d13a70366162cd3b5111ce24c371c7c87ded2012f055e08b2ff1b4ef506e1f4e065daa3ac474fef50b5efa4fb07`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm.tar.gz) | `c63ae0f8add5821ad267774314b8c8c1ffe3b785872bf278e721fd5dfdad1a5db1d4db3720bea0a36bf10d9c6dd93e247560162c0eac6e1b743246f587d3b27a`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | `47adb9ddf6eaf8f475b89f59ee16fbd5df183149a11ad1574eaa645b47a6d58aec2ca70ba857ce9f1a5793d44cf7a61ebc6874793bb685edaf19410f4f76fd13`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | `a3bc4a165567c7b76a3e45ab7b102d6eb3ecf373eb048173f921a4964cf9be8891d0d5b8dafbd88c3af7b0e21ef3d41c1e540c3347ddd84b929b3a3d02ceb7b2`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | `109ddf37c748f69584c829db57107c3518defe005c11fcd2a1471845c15aae0a3c89aafdd734229f4069ed18856cc650c80436684e1bdc43cfee3149b0324746`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | `a3a75d2696ad3136476ad7d811e8eabaff5111b90e592695e651d6111f819ebf0165b8b7f5adc05afb5f7f01d1e5fb64876cb696e492feb20a477a5800382b7a`
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | `543248e35c57454bfc4b6f3cf313402d7cf81606b9821a5dd95c6758d55d5b9a42e283a7fb0d45322ad1014e3382aafaee69879111c0799dac31d5c4ad1b8041`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | `c94bed3861376d3fd41cb7bc93b5a849612bc7346ed918f6b5b634449cd3acef69ff63ca0b6da29f45df68402f64f3d290d7688bc50f46dac07e889219dac30c`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | `3649dbca59d08c3922830b7acd8176e8d2f622fbf6379288f3a70045763d5d72c944d241f8a2c57306f23e6e44f7cc3b912554442f77e0f90e9f876f240114a8`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | `5655d1d48a1ae97352af2d703954c7a28c2d1c644319c4eb24fe19ccc5fb546c30b34cc86d8910f26c88feee88d7583bc085ebfe58916054f73dcf372a824fd9`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | `55190804357a687c37d1abb489d5aef7cea209d1c03778548f0aa4dab57a0b98b710fda09ff5c46d0963f2bb674726301d544b359f673df8f57226cafa831ce3`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | `d8ffbe8dc9a0b0b55db357afa6ef94e6145f9142b1bc505897cac9ee7c950ef527a189397a8e61296e66ce76b020eccb276668256927d2273d6079b9ffebef24`
 
-## Changelog since v1.18.0-beta.0
+## Changelog since v1.19.0-alpha.2
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+- Kubeadm does not set the deprecated '--cgroup-driver' flag in /var/lib/kubelet/kubeadm-flags.env, it will be set in the kubelet config.yaml. If you have this flag in /var/lib/kubelet/kubeadm-flags.env or /etc/default/kubelet (/etc/sysconfig/kubelet for RPMs) please remove it and set the value using KubeletConfiguration ([#90513](https://github.com/kubernetes/kubernetes/pull/90513), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+
+- Kubeadm respects resolvConf value set by user even if systemd-resolved service is active. kubeadm no longer sets the flag in '--resolv-conf' in /var/lib/kubelet/kubeadm-flags.env. If you have this flag in /var/lib/kubelet/kubeadm-flags.env or /etc/default/kubelet (/etc/sysconfig/kubelet for RPMs) please remove it and set the value using KubeletConfiguration ([#90394](https://github.com/kubernetes/kubernetes/pull/90394), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+
+## Changes by Kind
+
+### Deprecation
+
+- Apiextensions.k8s.io/v1beta1 is deprecated in favor of apiextensions.k8s.io/v1 ([#90673](https://github.com/kubernetes/kubernetes/pull/90673), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Apiregistration.k8s.io/v1beta1 is deprecated in favor of apiregistration.k8s.io/v1 ([#90672](https://github.com/kubernetes/kubernetes/pull/90672), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Authentication.k8s.io/v1beta1 and authorization.k8s.io/v1beta1 are deprecated in 1.19 in favor of v1 levels and will be removed in 1.22 ([#90458](https://github.com/kubernetes/kubernetes/pull/90458), [@deads2k](https://github.com/deads2k)) [SIG API Machinery and Auth]
+- Autoscaling/v2beta1 is deprecated in favor of autoscaling/v2beta2 ([#90463](https://github.com/kubernetes/kubernetes/pull/90463), [@deads2k](https://github.com/deads2k)) [SIG Autoscaling]
+- Coordination.k8s.io/v1beta1 is deprecated in 1.19, targeted for removal in 1.22, use v1 instead. ([#90559](https://github.com/kubernetes/kubernetes/pull/90559), [@deads2k](https://github.com/deads2k)) [SIG Scalability]
+- Storage.k8s.io/v1beta1 is deprecated in favor of storage.k8s.io/v1 ([#90671](https://github.com/kubernetes/kubernetes/pull/90671), [@deads2k](https://github.com/deads2k)) [SIG Storage]
+
+### API Change
+
+- K8s.io/apimachinery - scheme.Convert() now uses only explicitly registered conversions - default reflection based conversion is no longer available. `+k8s:conversion-gen` tags can be used with the `k8s.io/code-generator` component to generate conversions. ([#90018](https://github.com/kubernetes/kubernetes/pull/90018), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps and Testing]
+- Kubelet's --runonce option is now also available in Kubelet's config file as `runOnce`. ([#89128](https://github.com/kubernetes/kubernetes/pull/89128), [@vincent178](https://github.com/vincent178)) [SIG Node]
+- Promote Immutable Secrets/ConfigMaps feature to Beta and enable the feature by default.
+  This allows to set `Immutable` field in Secrets or ConfigMap object to mark their contents as immutable. ([#89594](https://github.com/kubernetes/kubernetes/pull/89594), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps and Testing]
+- The unused `series.state` field, deprecated since v1.14, is removed from the `events.k8s.io/v1beta1` and `v1` Event types. ([#90449](https://github.com/kubernetes/kubernetes/pull/90449), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps]
+
+### Feature
+
+- Kube-apiserver: The NodeRestriction admission plugin now restricts Node labels kubelets are permitted to set when creating a new Node to the `--node-labels` parameters accepted by kubelets in 1.16+. ([#90307](https://github.com/kubernetes/kubernetes/pull/90307), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Kubectl supports taint no without specifying(without having to type the full resource name) ([#88723](https://github.com/kubernetes/kubernetes/pull/88723), [@wawa0210](https://github.com/wawa0210)) [SIG CLI]
+- New scoring for PodTopologySpreading that yields better spreading ([#90475](https://github.com/kubernetes/kubernetes/pull/90475), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- No ([#89549](https://github.com/kubernetes/kubernetes/pull/89549), [@happinesstaker](https://github.com/happinesstaker)) [SIG API Machinery, Auth, Instrumentation and Testing]
+- Try to send watch bookmarks (if requested) periodically in addition to sending them right before timeout ([#90560](https://github.com/kubernetes/kubernetes/pull/90560), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+
+### Bug or Regression
+
+- Avoid GCE API calls when initializing GCE CloudProvider for Kubelets. ([#90218](https://github.com/kubernetes/kubernetes/pull/90218), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider and Scalability]
+- Avoid unnecessary scheduling churn when annotations are updated while Pods are being scheduled. ([#90373](https://github.com/kubernetes/kubernetes/pull/90373), [@fabiokung](https://github.com/fabiokung)) [SIG Scheduling]
+- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#90537](https://github.com/kubernetes/kubernetes/pull/90537), [@freehan](https://github.com/freehan)) [SIG Network]
+- Fixed a regression in wait.Forever that skips the backoff period on the first repeat ([#90476](https://github.com/kubernetes/kubernetes/pull/90476), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
+- Fixes a bug that non directory hostpath type can be recognized as HostPathFile and adds e2e tests for HostPathType ([#64829](https://github.com/kubernetes/kubernetes/pull/64829), [@dixudx](https://github.com/dixudx)) [SIG Apps, Storage and Testing]
+- Fixes a regression in 1.17 that dropped cache-control headers on API requests ([#90468](https://github.com/kubernetes/kubernetes/pull/90468), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- Fixes regression in CPUManager that caused freeing of exclusive CPUs at incorrect times ([#90377](https://github.com/kubernetes/kubernetes/pull/90377), [@cbf123](https://github.com/cbf123)) [SIG Cloud Provider and Node]
+- Fixes regression in CPUManager that had the (rare) possibility to release exclusive CPUs in app containers inherited from init containers. ([#90419](https://github.com/kubernetes/kubernetes/pull/90419), [@klueska](https://github.com/klueska)) [SIG Node]
+- Jsonpath support in kubectl / client-go serializes complex types (maps / slices / structs) as json instead of Go-syntax. ([#89660](https://github.com/kubernetes/kubernetes/pull/89660), [@pjferrell](https://github.com/pjferrell)) [SIG API Machinery, CLI and Cluster Lifecycle]
+- Kubeadm: ensure `image-pull-timeout` flag is respected during upgrade phase ([#90328](https://github.com/kubernetes/kubernetes/pull/90328), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: fix misleading warning for the kube-apiserver authz modes during "kubeadm init" ([#90064](https://github.com/kubernetes/kubernetes/pull/90064), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Provides a fix to allow a cluster in a private Azure cloud to authenticate to ACR in the same cloud. ([#90425](https://github.com/kubernetes/kubernetes/pull/90425), [@DavidParks8](https://github.com/DavidParks8)) [SIG Cloud Provider]
+- Update github.com/moby/ipvs to v1.0.1 to fix IPVS compatiblity issue with older kernels ([#90555](https://github.com/kubernetes/kubernetes/pull/90555), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
+- Updates to pod status via the status subresource now validate that `status.podIP` and `status.podIPs` fields are well-formed. ([#90628](https://github.com/kubernetes/kubernetes/pull/90628), [@liggitt](https://github.com/liggitt)) [SIG Apps and Node]
+
+### Other (Cleanup or Flake)
+
+- Drop some conformance tests that rely on Kubelet API directly ([#90615](https://github.com/kubernetes/kubernetes/pull/90615), [@dims](https://github.com/dims)) [SIG Architecture, Network, Release and Testing]
+- Kube-proxy exposes a new metric, `kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds`, that indicates the last time a change for kube-proxy was queued to be applied. ([#90175](https://github.com/kubernetes/kubernetes/pull/90175), [@squeed](https://github.com/squeed)) [SIG Instrumentation and Network]
+- Kubeadm: fix badly formatted error message for small service CIDRs ([#90411](https://github.com/kubernetes/kubernetes/pull/90411), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+- None. ([#90484](https://github.com/kubernetes/kubernetes/pull/90484), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
+- Remove the repeated calculation of nodeName and hostname during kubelet startup, these parameters are all calculated in the `RunKubelet` method ([#90284](https://github.com/kubernetes/kubernetes/pull/90284), [@wawa0210](https://github.com/wawa0210)) [SIG Node]
+- UI change ([#87743](https://github.com/kubernetes/kubernetes/pull/87743), [@u2takey](https://github.com/u2takey)) [SIG Apps and Node]
+- Update opencontainers/runtime-spec dependency to v1.0.2 ([#89644](https://github.com/kubernetes/kubernetes/pull/89644), [@saschagrunert](https://github.com/saschagrunert)) [SIG Node]
+
+
+# v1.19.0-alpha.2
+
+[Documentation](https://docs.k8s.io)
+
+## Downloads for v1.19.0-alpha.2
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes.tar.gz) | `a1106309d18a5d73882650f8a5cbd1f287436a0dc527136808e5e882f5e98d6b0d80029ff53abc0c06ac240f6b879167437f15906e5309248d536ec1675ed909`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-src.tar.gz) | `c24c0b2a99ad0d834e0f017d7436fa84c6de8f30e8768ee59b1a418eb66a9b34ed4bcc25e03c04b19ea17366564f4ee6fe55a520fa4d0837e86c0a72fc7328c1`
+
+### Client Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-darwin-386.tar.gz) | `51ede026b0f8338f7fd293fb096772a67f88f23411c3280dff2f9efdd3ad7be7917d5c32ba764162c1a82b14218a90f624271c3cd8f386c8e41e4a9eac28751f`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | `4ed4358cabbecf724d974207746303638c7f23d422ece9c322104128c245c8485e37d6ffdd9d17e13bb1d8110e870c0fe17dcc1c9e556b69a4df7d34b6ff66d5`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-386.tar.gz) | `a57b10f146083828f18d809dbe07938b72216fa21083e7dbb9acce7dbcc3e8c51b8287d3bf89e81c8e1af4dd139075c675cc0f6ae7866ef69a3813db09309b97`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | `099247419dd34dc78131f24f1890cc5c6a739e887c88fae96419d980c529456bfd45c4e451ba5b6425320ddc764245a2eab1bd5e2b5121d9a2774bdb5df9438b`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | `d12704bc6c821d3afcd206234fbd32e57cefcb5a5d15a40434b6b0ef4781d7fa77080e490678005225f24b116540ff51e436274debf66a6eb2247cd1dc833e6c`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | `da0d110751fa9adac69ed2166eb82b8634989a32b65981eff014c84449047abfb94fe015e2d2e22665d57ff19f673e2c9f6549c578ad1b1e2f18b39871b50b81`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | `7ac2b85bba9485dd38aed21895d627d34beb9e3b238e0684a9864f4ce2cfa67d7b3b7c04babc2ede7144d05beacdbe11c28c7d53a5b0041004700b2854b68042`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | `ac447eabc5002a059e614b481d25e668735a7858134f8ad49feb388bb9f9191ff03b65da57bb49811119983e8744c8fdc7d19c184d9232bd6d038fae9eeec7c6`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-windows-386.tar.gz) | `7c7dac7af329e4515302e7c35d3a19035352b4211942f254a4bb94c582a89d740b214d236ba6e35b9e78945a06b7e6fe8d70da669ecc19a40b7a9e8eaa2c0a28`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | `0c89b70a25551123ffdd7c5d3cc499832454745508c5f539f13b4ea0bf6eea1afd16e316560da9cf68e5178ae69d91ccfe6c02d7054588db3fac15c30ed96f4b`
+
+### Server Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | `3396e6e0516a09999ec26631e305cf0fb1eb0109ca1490837550b7635eb051dd92443de8f4321971fc2b4030ea2d8da4bfe8b85887505dec96e2a136b6a46617`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | `cdea122a2d8d602ec0c89c1135ecfc27c47662982afc5b94edf4a6db7d759f27d6fe8d8b727bddf798bfec214a50e8d8a6d8eb0bca2ad5b1f72eb3768afd37f1`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | `6543186a3f4437fb475fbc6a5f537640ab00afb2a22678c468c3699b3f7493f8b35fb6ca14694406ffc90ff8faad17a1d9d9d45732baa976cb69f4b27281295a`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | `fde8dfeb9a0b243c8bef5127a9c63bf685429e2ff7e486ac8bae373882b87a4bd1b28a12955e3cce1c04eb0e6a67aabba43567952f9deef943a75fcb157a949c`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | `399d004ee4db5d367f37a1fa9ace63b5db4522bd25eeb32225019f3df9b70c715d2159f6556015ddffe8f49aa0f72a1f095f742244637105ddbed3fb09570d0d`
+
+### Node Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | `fd865c2fcc71796d73c90982f90c789a44a921cf1d56aee692bd00efaa122dcc903b0448f285a06b0a903e809f8310546764b742823fb8d10690d36ec9e27cbd`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | `63aeb35222241e2a9285aeee4190b4b49c49995666db5cdb142016ca87872e7fdafc9723bc5de1797a45cc7e950230ed27be93ac165b8cda23ca2a9f9233c27a`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | `3532574d9babfc064ce90099b514eadfc2a4ce69091f92d9c1a554ead91444373416d1506a35ef557438606a96cf0e5168a83ddd56c92593ea4adaa15b0b56a8`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | `de59d91e5b0e4549e9a97f3a0243236e97babaed08c70f1a17273abf1966e6127db7546e1f91c3d66e933ce6eeb70bc65632ab473aa2c1be2a853da026c9d725`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | `0cb8cf6f8dffd63122376a2f3e8986a2db155494a45430beea7cb5d1180417072428dabebd1af566ea13a4f079d46368c8b549be4b8a6c0f62a974290fd2fdb0`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | `f1faf695f9f6fded681653f958b48779a2fecf50803af49787acba192441790c38b2b611ec8e238971508c56e67bb078fb423e8f6d9bddb392c199b5ee47937c`
+
+## Changelog since v1.19.0-alpha.1
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+- Kubeadm now respects user specified etcd versions in the ClusterConfiguration and properly uses them. If users do not want to stick to the version specified in the ClusterConfiguration, they should edit the kubeadm-config config map and delete it. ([#89588](https://github.com/kubernetes/kubernetes/pull/89588), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+
+## Changes by Kind
+
+### API Change
+
+- Kube-proxy: add `--bind-address-hard-fail` flag to treat failure to bind to a port as fatal ([#89350](https://github.com/kubernetes/kubernetes/pull/89350), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Network]
+- Remove kubescheduler.config.k8s.io/v1alpha1 ([#89298](https://github.com/kubernetes/kubernetes/pull/89298), [@gavinfish](https://github.com/gavinfish)) [SIG Scheduling]
+- ServiceAppProtocol feature gate is now beta and enabled by default, adding new AppProtocol field to Services and Endpoints. ([#90023](https://github.com/kubernetes/kubernetes/pull/90023), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- The Kubelet's `--volume-plugin-dir` option is now available via the Kubelet config file field `VolumePluginDir`. ([#88480](https://github.com/kubernetes/kubernetes/pull/88480), [@savitharaghunathan](https://github.com/savitharaghunathan)) [SIG Node]
+
+### Feature
+
+- Add client-side and server-side dry-run support to kubectl scale ([#89666](https://github.com/kubernetes/kubernetes/pull/89666), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Add support for cgroups v2 node validation ([#89901](https://github.com/kubernetes/kubernetes/pull/89901), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle and Node]
+- Detailed scheduler scoring result can be printed at verbose level 10. ([#89384](https://github.com/kubernetes/kubernetes/pull/89384), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- E2e.test can print the list of conformance tests that need to pass for the cluster to be conformant. ([#88924](https://github.com/kubernetes/kubernetes/pull/88924), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+- Feat: add azure shared disk support ([#89511](https://github.com/kubernetes/kubernetes/pull/89511), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-apiserver backed by etcd3 exports metric showing the database file size. ([#89151](https://github.com/kubernetes/kubernetes/pull/89151), [@jingyih](https://github.com/jingyih)) [SIG API Machinery]
+- Kube-apiserver: The NodeRestriction admission plugin now restricts Node labels kubelets are permitted to set when creating a new Node to the `--node-labels` parameters accepted by kubelets in 1.16+. ([#90307](https://github.com/kubernetes/kubernetes/pull/90307), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Kubeadm: during 'upgrade apply', if the kube-proxy ConfigMap is missing, assume that kube-proxy should not be upgraded. Same applies to a missing kube-dns/coredns ConfigMap for the DNS server addon. Note that this is a temporary workaround until 'upgrade apply' supports phases. Once phases are supported the kube-proxy/dns upgrade should be skipped manually. ([#89593](https://github.com/kubernetes/kubernetes/pull/89593), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: switch control-plane static Pods to the "system-node-critical" priority class ([#90063](https://github.com/kubernetes/kubernetes/pull/90063), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Support for running on a host that uses cgroups v2 unified mode ([#85218](https://github.com/kubernetes/kubernetes/pull/85218), [@giuseppe](https://github.com/giuseppe)) [SIG Node]
+- Update etcd client side to v3.4.7 ([#89822](https://github.com/kubernetes/kubernetes/pull/89822), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider]
+
+### Bug or Regression
+
+- An issue preventing GCP cloud-controller-manager running out-of-cluster to initialize new Nodes is now fixed. ([#90057](https://github.com/kubernetes/kubernetes/pull/90057), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Apps and Cloud Provider]
+- Avoid unnecessary GCE API calls when adding IP alises or reflecting them in Node object in GCE cloud provider. ([#90242](https://github.com/kubernetes/kubernetes/pull/90242), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, Cloud Provider and Network]
+- Azure: fix concurreny issue in lb creation ([#89604](https://github.com/kubernetes/kubernetes/pull/89604), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Bug fix for AWS NLB service when nodePort for existing servicePort changed manually. ([#89562](https://github.com/kubernetes/kubernetes/pull/89562), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- CSINode initialization does not crash kubelet on startup when APIServer is not reachable or kubelet has not the right credentials yet. ([#89589](https://github.com/kubernetes/kubernetes/pull/89589), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Client-go: resolves an issue with informers falling back to full list requests when timeouts are encountered, rather than re-establishing a watch. ([#89652](https://github.com/kubernetes/kubernetes/pull/89652), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- Dual-stack: fix the bug that Service clusterIP does not respect specified ipFamily ([#89612](https://github.com/kubernetes/kubernetes/pull/89612), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
+- Ensure Azure availability zone is always in lower cases. ([#89722](https://github.com/kubernetes/kubernetes/pull/89722), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Explain CRDs whose resource name are the same as builtin objects ([#89505](https://github.com/kubernetes/kubernetes/pull/89505), [@knight42](https://github.com/knight42)) [SIG API Machinery, CLI and Testing]
+- Fix flaws in Azure File CSI translation ([#90162](https://github.com/kubernetes/kubernetes/pull/90162), [@rfranzke](https://github.com/rfranzke)) [SIG Release and Storage]
+- Fix kubectl describe CSINode nil pointer error ([#89646](https://github.com/kubernetes/kubernetes/pull/89646), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix kubectl diff so it doesn't actually persist patches ([#89795](https://github.com/kubernetes/kubernetes/pull/89795), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Fix kubectl version should print version info without config file ([#89913](https://github.com/kubernetes/kubernetes/pull/89913), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery and CLI]
+- Fix missing `-c` shorthand for `--container` flag of `kubectl alpha debug` ([#89674](https://github.com/kubernetes/kubernetes/pull/89674), [@superbrothers](https://github.com/superbrothers)) [SIG CLI]
+- Fix printers ignoring object average value ([#89142](https://github.com/kubernetes/kubernetes/pull/89142), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery]
+- Fix scheduler crash when removing node before its pods ([#89908](https://github.com/kubernetes/kubernetes/pull/89908), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Fix: get attach disk error due to missing item in max count table ([#89768](https://github.com/kubernetes/kubernetes/pull/89768), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fixed a bug where executing a kubectl command with a jsonpath output expression that has a nested range would ignore expressions following the nested range. ([#88464](https://github.com/kubernetes/kubernetes/pull/88464), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery]
+- Fixed a regression running kubectl commands with  --local or --dry-run flags when no kubeconfig file is present ([#90243](https://github.com/kubernetes/kubernetes/pull/90243), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
+- Fixed an issue mounting credentials for service accounts whose name contains `.` characters ([#89696](https://github.com/kubernetes/kubernetes/pull/89696), [@nabokihms](https://github.com/nabokihms)) [SIG Auth]
+- Fixed mountOptions in iSCSI and FibreChannel volume plugins. ([#89172](https://github.com/kubernetes/kubernetes/pull/89172), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Fixed the EndpointSlice controller to run without error on a cluster with the OwnerReferencesPermissionEnforcement validating admission plugin enabled. ([#89741](https://github.com/kubernetes/kubernetes/pull/89741), [@marun](https://github.com/marun)) [SIG Auth and Network]
+- Fixes a bug defining a default value for a replicas field in a custom resource definition that has the scale subresource enabled ([#89833](https://github.com/kubernetes/kubernetes/pull/89833), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fixes conversion error for HorizontalPodAutoscaler objects with invalid annotations ([#89963](https://github.com/kubernetes/kubernetes/pull/89963), [@liggitt](https://github.com/liggitt)) [SIG Autoscaling]
+- Fixes kubectl to apply all validly built objects, instead of stopping on error. ([#89848](https://github.com/kubernetes/kubernetes/pull/89848), [@seans3](https://github.com/seans3)) [SIG CLI and Testing]
+- For GCE cluster provider, fix bug of not being able to create internal type load balancer for clusters with more than 1000 nodes in a single zone. ([#89902](https://github.com/kubernetes/kubernetes/pull/89902), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability]
+- If firstTimestamp is not set use eventTime when printing event ([#89999](https://github.com/kubernetes/kubernetes/pull/89999), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- If we set parameter cgroupPerQos=false and cgroupRoot=/docker，this function will retrun  nodeAllocatableRoot=/docker/kubepods, it is not right, the correct return should be /docker.
+  cm.NodeAllocatableRoot(s.CgroupRoot, s.CgroupDriver)
+  
+  kubeDeps.CAdvisorInterface, err = cadvisor.New(imageFsInfoProvider, s.RootDirectory, cgroupRoots, cadvisor.UsingLegacyCadvisorStats(s.ContainerRuntime, s.RemoteRuntimeEndpoint))
+  the above funtion，as we use cgroupRoots to create cadvisor interface，the wrong parameter cgroupRoots will lead eviction manager not  to collect metric from /docker, then kubelet frequently print those error：
+  E0303 17:25:03.436781 63839 summary_sys_containers.go:47] Failed to get system container stats for "/docker": failed to get cgroup stats for "/docker": failed to get container info for "/docker": unknown container "/docker"
+  E0303 17:25:03.436809 63839 helpers.go:680] eviction manager: failed to construct signal: "allocatableMemory.available" error: system container "pods" not found in metrics ([#88970](https://github.com/kubernetes/kubernetes/pull/88970), [@mysunshine92](https://github.com/mysunshine92)) [SIG Node]
+- In the kubelet resource metrics endpoint at /metrics/resource, change the names of the following metrics:
+  - node_cpu_usage_seconds --> node_cpu_usage_seconds_total
+  - container_cpu_usage_seconds --> container_cpu_usage_seconds_total
+  This is a partial revert of &#35;86282, which was added in 1.18.0, and initially removed the _total suffix ([#89540](https://github.com/kubernetes/kubernetes/pull/89540), [@dashpole](https://github.com/dashpole)) [SIG Instrumentation and Node]
+- Kube-apiserver: multiple comma-separated protocols in a single X-Stream-Protocol-Version header are now recognized, in addition to multiple headers, complying with RFC2616 ([#89857](https://github.com/kubernetes/kubernetes/pull/89857), [@tedyu](https://github.com/tedyu)) [SIG API Machinery]
+- Kubeadm increased to 5 minutes its timeout for the TLS bootstrapping process to complete upon join ([#89735](https://github.com/kubernetes/kubernetes/pull/89735), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: during join when a check is performed that a Node with the same name already exists in the cluster, make sure the NodeReady condition is properly validated ([#89602](https://github.com/kubernetes/kubernetes/pull/89602), [@kvaps](https://github.com/kvaps)) [SIG Cluster Lifecycle]
+- Kubeadm: fix a bug where post upgrade to 1.18.x, nodes cannot join the cluster due to missing RBAC ([#89537](https://github.com/kubernetes/kubernetes/pull/89537), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: fix misleading warning about passing control-plane related flags on 'kubeadm join' ([#89596](https://github.com/kubernetes/kubernetes/pull/89596), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubectl azure authentication: fixed a regression in 1.18.0 where "spn:" prefix was unexpectedly added to the `apiserver-id` configuration in the kubeconfig file ([#89706](https://github.com/kubernetes/kubernetes/pull/89706), [@weinong](https://github.com/weinong)) [SIG API Machinery and Auth]
+- Restore the ability to `kubectl apply --prune` without --namespace flag.  Since 1.17, `kubectl apply --prune` only prunes resources in the default namespace (or from kubeconfig) or explicitly specified in command line flag.  But this is s breaking change from kubectl 1.16, which can prune resources in all namespace in config file.  This patch restores the kubectl 1.16 behaviour. ([#89551](https://github.com/kubernetes/kubernetes/pull/89551), [@tatsuhiro-t](https://github.com/tatsuhiro-t)) [SIG CLI and Testing]
+- Restores priority of static control plane pods in the cluster/gce/manifests control-plane manifests ([#89970](https://github.com/kubernetes/kubernetes/pull/89970), [@liggitt](https://github.com/liggitt)) [SIG Cluster Lifecycle and Node]
+- Service account tokens bound to pods can now be used during the pod deletion grace period. ([#89583](https://github.com/kubernetes/kubernetes/pull/89583), [@liggitt](https://github.com/liggitt)) [SIG Auth]
+- Sync LB backend nodes for Service Type=LoadBalancer on Add/Delete node events. ([#81185](https://github.com/kubernetes/kubernetes/pull/81185), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+
+### Other (Cleanup or Flake)
+
+- Change beta.kubernetes.io/os  to kubernetes.io/os ([#89460](https://github.com/kubernetes/kubernetes/pull/89460), [@wawa0210](https://github.com/wawa0210)) [SIG Testing and Windows]
+- Changes not found message when using `kubectl get` to retrieve not namespaced resources ([#89861](https://github.com/kubernetes/kubernetes/pull/89861), [@rccrdpccl](https://github.com/rccrdpccl)) [SIG CLI]
+- Node ([#76443](https://github.com/kubernetes/kubernetes/pull/76443), [@mgdevstack](https://github.com/mgdevstack)) [SIG Architecture, Network, Node, Testing and Windows]
+- None. ([#90273](https://github.com/kubernetes/kubernetes/pull/90273), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
+- Reduce event spam during a volume operation error. ([#89794](https://github.com/kubernetes/kubernetes/pull/89794), [@msau42](https://github.com/msau42)) [SIG Storage]
+- The PR adds functionality to generate events when a PV or PVC processing encounters certain failures. The events help users to know the reason for the failure so they can take necessary recovery actions. ([#89845](https://github.com/kubernetes/kubernetes/pull/89845), [@yuga711](https://github.com/yuga711)) [SIG Apps]
+- The PodShareProcessNamespace feature gate has been removed, and the PodShareProcessNamespace is unconditionally enabled. ([#90099](https://github.com/kubernetes/kubernetes/pull/90099), [@tanjunchen](https://github.com/tanjunchen)) [SIG Node]
+- Update default etcd server version to 3.4.4 ([#89214](https://github.com/kubernetes/kubernetes/pull/89214), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle and Testing]
+- Update default etcd server version to 3.4.7 ([#89895](https://github.com/kubernetes/kubernetes/pull/89895), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle and Testing]
+
+
+# v1.19.0-alpha.1
+
+[Documentation](https://docs.k8s.io)
+
+## Downloads for v1.19.0-alpha.1
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes.tar.gz) | `d5930e62f98948e3ae2bc0a91b2cb93c2009202657b9e798e43fcbf92149f50d991af34a49049b2640db729efc635d643d008f4b3dd6c093cac4426ee3d5d147`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-src.tar.gz) | `5d92125ec3ca26b6b0af95c6bb3289bb7cf60a4bad4e120ccdad06ffa523c239ca8e608015b7b5a1eb789bfdfcedbe0281518793da82a7959081fb04cf53c174`
+
+### Client Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-darwin-386.tar.gz) | `08d307dafdd8e1aa27721f97f038210b33261d1777ea173cc9ed4b373c451801988a7109566425fce32d38df70bdf0be6b8cfff69da768fbd3c303abd6dc13a5`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | `08c3b722a62577d051e300ebc3c413ead1bd3e79555598a207c704064116087323215fb402bae7584b9ffd08590f36fa8a35f13f8fea1ce92e8f144e3eae3384`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-386.tar.gz) | `0735978b4d4cb0601171eae3cc5603393c00f032998f51d79d3b11e4020f4decc9559905e9b02ddcb0b6c3f4caf78f779940ebc97996e3b96b98ba378fbe189d`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | `ca55fc431d59c1a0bf1f1c248da7eab65215e438fcac223d4fc3a57fae0205869e1727b2475dfe9b165921417d68ac380a6e42bf7ea6732a34937ba2590931ce`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | `4e1aa9e640d7cf0ccaad19377e4c3ca9a60203daa2ce0437d1d40fdea0e43759ef38797e948cdc3c676836b01e83f1bfde51effc0579bf832f6f062518f03f06`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | `fca5df8c2919a9b3d99248120af627d9a1b5ddf177d9a10f04eb4e486c14d4e3ddb72e3abc4733b5078e0d27204a51e2f714424923fb92a5351137f82d87d6ea`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | `6a98a4f99aa8b72ec815397c5062b90d5c023092da28fa7bca1cdadf406e2d86e2fd3a0eeab28574064959c6926007423c413d9781461e433705452087430d57`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | `94724c17985ae2dbd3888e6896f300f95fec8dc2bf08e768849e98b05affc4381b322d802f41792b8e6da4708ce1ead2edcb8f4d5299be6267f6559b0d49e484`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-windows-386.tar.gz) | `5a076bf3a5926939c170a501f8292a38003552848c45c1f148a97605b7ac9843fb660ef81a46abe6d139f4c5eaa342d4b834a799ee7055d5a548d189b31d7124`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | `4b395894bfd9cfa0976512d1d58c0056a80bacefc798de294db6d3f363bd5581fd3ce2e4bdc1b902d46c8ce2ac87a98ced56b6b29544c86e8444fb8e9465faea`
+
+### Server Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | `6720d1b826dc20e56b0314e580403cd967430ff25bdbe08e8bf453fed339557d2a4ace114c2f524e6b6814ec9341ccdea870f784ebb53a52056ca3ab22e5cc36`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | `f09b295f5a95cc72494eb1c0e9706b237a8523eacda182778e9afdb469704c7eacd29614aff6d3d7aff3bc1783fb277d52ad56a1417f1bd973eeb9bdc8086695`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | `24787767abd1d67a4d0234433e1693ea3e1e906364265ee03e58ba203b66583b75d4ce0c4185756fc529997eb9a842d65841962cd228df9c182a469dbd72493d`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | `a117e609729263d7bd58aac156efa33941f0f9aa651892d1abf32cfa0a984aa495fccd3be8385cae083415bfa8f81942648d5978f72e950103e42184fd0d7527`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | `19280a6dc20f019d23344934f8f1ec6aa17c3374b9c569d4c173535a8cd9e298b8afcabe06d232a146c9c7cb4bfe7d1d0e10aa2ab9184ace0b7987e36973aaef`
+
+### Node Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | `c4b23f113ed13edb91b59a498d15de8b62ff1005243f2d6654a11468511c9d0ebaebb6dc02d2fa505f18df446c9221e77d7fc3147fa6704cde9bec5d6d80b5a3`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | `8dcf5531a5809576049c455d3c5194f09ddf3b87995df1e8ca4543deff3ffd90a572539daff9aa887e22efafedfcada2e28035da8573e3733c21778e4440677a`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | `4b3f4dfee2034ce7d01fef57b8766851fe141fc72da0f9edeb39aca4c7a937e2dccd2c198a83fbb92db7911d81e50a98bd0a17b909645adbeb26e420197db2cd`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | `df0e87f5e42056db2bbc7ef5f08ecda95d66afc3f4d0bc57f6efcc05834118c39ab53d68595d8f2bb278829e33b9204c5cce718d8bf841ce6cccbb86d0d20730`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | `3a6499b008a68da52f8ae12eb694885d9e10a8f805d98f28fc5f7beafea72a8e180df48b5ca31097b2d4779c61ff67216e516c14c2c812163e678518d95f22d6`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | `c311373506cbfa0244ac92a709fbb9bddb46cbeb130733bdb689641ecee6b21a7a7f020eae4856a3f04a3845839dc5e0914cddc3478d55cd3d5af3d7804aa5ba`
+
+## Changelog since v1.19.0-alpha.0
 
 ## Urgent Upgrade Notes
 
@@ -803,568 +2418,187 @@ filename | sha512 hash
 - The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option.
   If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node]
 
-- Yes.
-
-  Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster.
-
-  Changes in Pull Request:
-
-    1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources.
-    2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature.
-    3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature.
-    4. Related unit tests.
-
-  None.
-
-  User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
+- `kubectl` no longer defaults to `http://localhost:8080`.  If you own one of these legacy clusters, you are *strongly- encouraged to secure your server.   If you cannot secure your server, you can set `KUBERNETES_MASTER` if you were relying on that behavior and you're client-go user. Set `--server`, `--kubeconfig` or `KUBECONFIG` to make it work in `kubectl`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
 
 ## Changes by Kind
 
 ### Deprecation
 
+- AlgorithmSource is removed from v1alpha2 Scheduler ComponentConfig ([#87999](https://github.com/kubernetes/kubernetes/pull/87999), [@damemi](https://github.com/damemi)) [SIG Scheduling]
 - Azure service annotation service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset has been deprecated. Its support would be removed in a future release. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Kube-proxy: deprecate `--healthz-port` and `--metrics-port` flag, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
+- Kubeadm: deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubernetes no longer supports building hyperkube images ([#88676](https://github.com/kubernetes/kubernetes/pull/88676), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle and Release]
 
 ### API Change
 
+- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing]
 - API additions to apiserver types ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Cloud Provider and Cluster Lifecycle]
 - Add Scheduling Profiles to kubescheduler.config.k8s.io/v1alpha2 ([#88087](https://github.com/kubernetes/kubernetes/pull/88087), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing]
+- Added GenericPVCDataSource feature gate to enable using arbitrary custom resources as the data source for a PVC. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage]
 - Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage]
+- Allow user to specify fsgroup permission change policy for pods ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage]
 - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage]
+- Consumers of the 'certificatesigningrequests/approval' API must now grant permission to 'approve' CSRs for the 'signerName' specified on the CSR. More information on the new signerName field can be found at https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190607-certificates-api.md&#35;signers ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, Apps, Auth, CLI, Node and Testing]
+- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
 - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-- Introduces optional --detect-local flag to kube-proxy.
-  Currently the only supported value is "cluster-cidr",
+- Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network]
+- Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network]
+- Ingress: Add alternate backends via TypedLocalObjectReference ([#88775](https://github.com/kubernetes/kubernetes/pull/88775), [@cmluciano](https://github.com/cmluciano)) [SIG Apps and Network]
+- Ingress: allow wildcard hosts in IngressRule ([#88858](https://github.com/kubernetes/kubernetes/pull/88858), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
+- Introduces optional --detect-local flag to kube-proxy. 
+  Currently the only supported value is "cluster-cidr", 
   which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
+- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver.  Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling]
 - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
+- Move TaintBasedEvictions feature gates to GA ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing]
 - Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows]
+- New flag --endpointslice-updates-batch-period in kube-controller-manager can be used to reduce number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network]
+- New flag `--show-hidden-metrics-for-version` in kubelet can be used to show all hidden metrics that deprecated in the previous minor release. ([#85282](https://github.com/kubernetes/kubernetes/pull/85282), [@serathius](https://github.com/serathius)) [SIG Node]
+- Removes ConfigMap as suggestion for IngressClass parameters ([#89093](https://github.com/kubernetes/kubernetes/pull/89093), [@robscott](https://github.com/robscott)) [SIG Network]
+- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
+- The apiserver/v1alph1&#35;EgressSelectorConfiguration API is now beta. ([#88502](https://github.com/kubernetes/kubernetes/pull/88502), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery]
+- The storage.k8s.io/CSIDriver has moved to GA, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, Apps, Auth, Node, Scheduling, Storage and Testing]
+- VolumePVCDataSource moves to GA in 1.18 release ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Apps, CLI and Cluster Lifecycle]
 
 ### Feature
 
+- deps: Update to Golang 1.13.9
+  - build: Remove kube-cross image building ([#89275](https://github.com/kubernetes/kubernetes/pull/89275), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
 - Add --dry-run to kubectl delete, taint, replace ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
 - Add huge page stats to Allocated resources in "kubectl describe node" ([#80605](https://github.com/kubernetes/kubernetes/pull/80605), [@odinuge](https://github.com/odinuge)) [SIG CLI]
+- Add support for pre allocated huge pages with different sizes, on node level ([#89252](https://github.com/kubernetes/kubernetes/pull/89252), [@odinuge](https://github.com/odinuge)) [SIG Apps and Node]
+- Adds support for NodeCIDR as an argument to --detect-local-mode ([#88935](https://github.com/kubernetes/kubernetes/pull/88935), [@satyasm](https://github.com/satyasm)) [SIG Network]
+- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
+- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. 
+  After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. 
+  The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
+  Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
+- Azure Cloud Provider now supports using Azure network resources (Virtual Network, Load Balancer, Public IP, Route Table, Network Security Group, etc.) in different AAD Tenant and Subscription than those for the Kubernetes cluster. To use the feature, please reference https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md&#35;host-network-resources-in-different-aad-tenant-and-subscription. ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
+- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- DefaultConstraints can be specified for the PodTopologySpread plugin in the component config ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- EndpointSlice controller waits longer to retry failed sync. ([#89438](https://github.com/kubernetes/kubernetes/pull/89438), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- Feat: change azure disk api-version ([#89250](https://github.com/kubernetes/kubernetes/pull/89250), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Feat: support [Azure shared disk](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-shared-enable), added a new field(`maxShares`) in azure disk storage class:
+  
+  kind: StorageClass
+  apiVersion: storage.k8s.io/v1
+  metadata:
+    name: shared-disk
+  provisioner: kubernetes.io/azure-disk
+  parameters:
+    skuname: Premium_LRS  &#35; Currently only available with premium SSDs.
+    cachingMode: None  &#35; ReadOnly host caching is not available for premium SSDs with maxShares>1
+    maxShares: 2 ([#89328](https://github.com/kubernetes/kubernetes/pull/89328), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-apiserver, kube-scheduler and kube-controller manager now use SO_REUSEPORT socket option when listening on address defined by --bind-address and --secure-port flags, when running on Unix systems (Windows is NOT supported). This allows to run multiple instances of those processes on a single host with the same configuration, which allows to update/restart them in a graceful way, without causing downtime. ([#88893](https://github.com/kubernetes/kubernetes/pull/88893), [@invidian](https://github.com/invidian)) [SIG API Machinery, Scheduling and Testing]
 - Kubeadm: The ClusterStatus struct present in the kubeadm-config ConfigMap is deprecated and will be removed on a future version. It is going to be maintained by kubeadm until it gets removed. The same information can be found on `etcd` and `kube-apiserver` pod annotations, `kubeadm.kubernetes.io/etcd.advertise-client-urls` and `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint` respectively. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle]
 - Kubeadm: add the experimental feature gate PublicKeysECDSA that can be used to create a
   cluster with ECDSA certificates from "kubeadm init". Renewal of existing ECDSA certificates is
   also supported using "kubeadm alpha certs renew", but not switching between the RSA and
   ECDSA algorithms on the fly or during upgrades. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth and Cluster Lifecycle]
 - Kubeadm: on kubeconfig certificate renewal, keep the embedded CA in sync with the one on disk ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows]
 - Kubeadm: upgrade supports fallback to the nearest known etcd version if an unknown k8s version is passed ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubectl cluster-info dump changed to only display a message telling you the location where the output was written when the output is not standard output. ([#88765](https://github.com/kubernetes/kubernetes/pull/88765), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
 - New flag `--show-hidden-metrics-for-version` in kube-scheduler can be used to show all hidden metrics that deprecated in the previous minor release. ([#84913](https://github.com/kubernetes/kubernetes/pull/84913), [@serathius](https://github.com/serathius)) [SIG Instrumentation and Scheduling]
+- Print NotReady when pod is not ready based on its conditions. ([#88240](https://github.com/kubernetes/kubernetes/pull/88240), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- Scheduler Extender API is now located under k8s.io/kube-scheduler/extender ([#88540](https://github.com/kubernetes/kubernetes/pull/88540), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
 - Scheduler framework permit plugins now run at the end of the scheduling cycle, after reserve plugins. Waiting on permit will remain in the beginning of the binding cycle. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG Scheduling]
+- Signatures on scale client methods have been modified to accept `context.Context` as a first argument. Signatures of Get, Update, and Patch methods have been updated to accept GetOptions, UpdateOptions and PatchOptions respectively. ([#88599](https://github.com/kubernetes/kubernetes/pull/88599), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, Apps, Autoscaling and CLI]
+- Signatures on the dynamic client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88906](https://github.com/kubernetes/kubernetes/pull/88906), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, CLI, Cluster Lifecycle, Storage and Testing]
+- Signatures on the metadata client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88910](https://github.com/kubernetes/kubernetes/pull/88910), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing]
+- Support create or update VMSS asynchronously. ([#89248](https://github.com/kubernetes/kubernetes/pull/89248), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
 - The kubelet and the default docker runtime now support running ephemeral containers in the Linux process namespace of a target container. Other container runtimes must implement this feature before it will be available in that runtime. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG Node]
+- Update etcd client side to v3.4.4 ([#89169](https://github.com/kubernetes/kubernetes/pull/89169), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider]
+- Upgrade to azure-sdk v40.2.0 ([#89105](https://github.com/kubernetes/kubernetes/pull/89105), [@andyzhangx](https://github.com/andyzhangx)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Storage and Testing]
+- Webhooks will have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing]
+- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing]
+- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI]
+
+### Documentation
+
+- Improved error message for incorrect auth field. ([#82829](https://github.com/kubernetes/kubernetes/pull/82829), [@martin-schibsted](https://github.com/martin-schibsted)) [SIG Auth]
+- Update Japanese translation for kubectl help ([#86837](https://github.com/kubernetes/kubernetes/pull/86837), [@inductor](https://github.com/inductor)) [SIG CLI and Docs]
+- Updated the instructions for deploying the sample app. ([#82785](https://github.com/kubernetes/kubernetes/pull/82785), [@ashish-billore](https://github.com/ashish-billore)) [SIG API Machinery]
+- `kubectl plugin` now prints a note how to install krew ([#88577](https://github.com/kubernetes/kubernetes/pull/88577), [@corneliusweig](https://github.com/corneliusweig)) [SIG CLI]
 
 ### Other (Bug, Cleanup or Flake)
 
+- A PV set from in-tree source will have ordered requirement values in NodeAffinity when converted to CSIPersistentVolumeSource ([#88987](https://github.com/kubernetes/kubernetes/pull/88987), [@jiahuif](https://github.com/jiahuif)) [SIG Storage]
 - Add delays between goroutines for vm instance update ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
 - Add init containers log to cluster dump info. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with squential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Azure auth module for kubectl now requests login after refresh token expires. ([#86481](https://github.com/kubernetes/kubernetes/pull/86481), [@tdihp](https://github.com/tdihp)) [SIG API Machinery and Auth]
+- AzureFile and CephFS use new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Beta.kubernetes.io/arch is already deprecated since v1.14, are targeted for removal in v1.18 ([#89462](https://github.com/kubernetes/kubernetes/pull/89462), [@wawa0210](https://github.com/wawa0210)) [SIG Testing]
+- Build: Enable kube-cross image-building on K8s Infra ([#88562](https://github.com/kubernetes/kubernetes/pull/88562), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
 - CPU limits are now respected for Windows containers. If a node is over-provisioned, no weighting is used - only limits are respected. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG Node, Testing and Windows]
+- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth]
 - Cloud provider config CloudProviderBackoffMode has been removed since it won't be used anymore. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing]
+- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- Deprecate kubectl top flags related to heapster
+  Drop support of heapster in kubectl top ([#87498](https://github.com/kubernetes/kubernetes/pull/87498), [@serathius](https://github.com/serathius)) [SIG CLI]
+- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
 - Evictions due to pods breaching their ephemeral storage limits are now recorded by the `kubelet_evictions` metric and can be alerted on. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node]
+- FIX: prevent apiserver from panicking when failing to load audit webhook config file ([#88879](https://github.com/kubernetes/kubernetes/pull/88879), [@JoshVanL](https://github.com/JoshVanL)) [SIG API Machinery and Auth]
+- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]
+- Fix a bug that didn't allow to use IPv6 addresses with leading zeros ([#89341](https://github.com/kubernetes/kubernetes/pull/89341), [@aojea](https://github.com/aojea)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network]
+- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
+- Fix bug with xfs_repair from stopping xfs mount ([#89444](https://github.com/kubernetes/kubernetes/pull/89444), [@gnufied](https://github.com/gnufied)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Fix describe ingress annotations not sorted. ([#88394](https://github.com/kubernetes/kubernetes/pull/88394), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix detection of SystemOOMs in which the victim is a container. ([#88871](https://github.com/kubernetes/kubernetes/pull/88871), [@dashpole](https://github.com/dashpole)) [SIG Node]
+- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider]
+- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
+- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix kube-apiserver startup to wait for APIServices to be installed into the HTTP handler before reporting readiness. ([#89147](https://github.com/kubernetes/kubernetes/pull/89147), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node]
+- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage]
+- Fix the VMSS name and resource group name when updating Azure VMSS for LoadBalancer backendPools ([#89337](https://github.com/kubernetes/kubernetes/pull/89337), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
 - Fix: add remediation in azure disk attach/detach ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fix: check disk status before disk azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fix: check disk status before delete azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage]
+- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node]
+- Fixed a data race in kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node]
+- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node]
+- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Node and Storage]
+- Fixed bug where a nonzero exit code was returned when initializing zsh completion even though zsh completion was successfully initialized ([#88165](https://github.com/kubernetes/kubernetes/pull/88165), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
 - Fixed cleaning of CSI raw block volumes. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Fixes conversion error in multi-version custom resources that could cause metadata.generation to increment on no-op patches or updates of a custom resource. ([#88995](https://github.com/kubernetes/kubernetes/pull/88995), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- Fixes issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage]
+- Fixes v1.18.0-rc.1 regression in `kubectl port-forward` when specifying a local and remote port ([#89401](https://github.com/kubernetes/kubernetes/pull/89401), [@liggitt](https://github.com/liggitt)) [SIG CLI]
+- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Apps, Node and Storage]
 - Get-kube.sh uses the gcloud's current local GCP service account for auth when the provider is GCE or GKE instead of the metadata server default ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG Cluster Lifecycle]
 - Golang/x/net has been updated to bring in fixes for CVE-2020-9283 ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Hide kubectl.kubernetes.io/last-applied-configuration in describe command ([#88758](https://github.com/kubernetes/kubernetes/pull/88758), [@soltysh](https://github.com/soltysh)) [SIG Auth and CLI]
+- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider]
+- Ipvs: only attempt setting of sysctlconnreuse on supported kernels ([#88541](https://github.com/kubernetes/kubernetes/pull/88541), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
+- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network]
 - Kubeadm now includes CoreDNS version 1.6.7 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle]
 - Kubeadm: fix the bug that 'kubeadm upgrade' hangs in single node cluster ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubelet: fix the bug that kubelet help information can not show the right type of flags ([#88515](https://github.com/kubernetes/kubernetes/pull/88515), [@SataQiu](https://github.com/SataQiu)) [SIG Docs and Node]
+- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
 - Optimize kubectl version help info ([#88313](https://github.com/kubernetes/kubernetes/pull/88313), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
 - Removes the deprecated command `kubectl rolling-update` ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing]
+- Resolved a regression in v1.18.0-rc.1 mounting windows volumes ([#89319](https://github.com/kubernetes/kubernetes/pull/89319), [@mboersma](https://github.com/mboersma)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Scheduler PreScore plugins are not executed if there is one filtered node or less. ([#89370](https://github.com/kubernetes/kubernetes/pull/89370), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
+  
+  Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
+- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
+- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery]
+- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth]
+- Update Cluster Autoscaler to 1.18.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk)) [SIG Autoscaling and Cluster Lifecycle]
+- Update to use golang 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Release and Testing]
+- Validate kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout ([#88657](https://github.com/kubernetes/kubernetes/pull/88657), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
+- Wait for all CRDs to show up in discovery endpoint before reporting readiness. ([#89145](https://github.com/kubernetes/kubernetes/pull/89145), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- `kubectl config view` now redacts bearer tokens by default, similar to client certificates. The `--raw` flag can still be used to output full content. ([#88985](https://github.com/kubernetes/kubernetes/pull/88985), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery and CLI]
 
-
-# v1.18.0-alpha.5
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.5
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes.tar.gz) | `6452cac2b80721e9f577cb117c29b9ac6858812b4275c2becbf74312566f7d016e8b34019bd1bf7615131b191613bf9b973e40ad9ac8f6de9007d41ef2d7fd70`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-src.tar.gz) | `e41d9d4dd6910a42990051fcdca4bf5d3999df46375abd27ffc56aae9b455ae984872302d590da6aa85bba6079334fb5fe511596b415ee79843dee1c61c137da`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-386.tar.gz) | `5c95935863492b31d4aaa6be93260088dafea27663eb91edca980ca3a8485310e60441bc9050d4d577e9c3f7ffd96db516db8d64321124cec1b712e957c9fe1c`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-amd64.tar.gz) | `868faa578b3738604d8be62fae599ccc556799f1ce54807f1fe72599f20f8a1f98ad8152fac14a08a463322530b696d375253ba3653325e74b587df6e0510da3`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-386.tar.gz) | `76a89d1d30b476b47f8fb808e342f89608e5c1c1787c4c06f2d7e763f9482e2ae8b31e6ad26541972e2b9a3a7c28327e3150cdd355e8b8d8b050a801bbf08d49`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-amd64.tar.gz) | `07ad96a09b44d1c707d7c68312c5d69b101a3424bf1e6e9400b2e7a3fba78df04302985d473ddd640d8f3f0257be34110dbe1304b9565dd9d7a4639b7b7b85fd`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm.tar.gz) | `c04fed9fa370a75c1b8e18b2be0821943bb9befcc784d14762ea3278e73600332a9b324d5eeaa1801d20ad6be07a553c41dcf4fa7ab3eadd0730ab043d687c8c`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm64.tar.gz) | `4199147dea9954333df26d34248a1cb7b02ebbd6380ffcd42d9f9ed5fdabae45a59215474dab3c11436c82e60bd27cbd03b3dde288bf611cd3e78b87c783c6a9`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-ppc64le.tar.gz) | `4f6d4d61d1c52d3253ca19031ebcd4bad06d19b68bbaaab5c8e8c590774faea4a5ceab1f05f2706b61780927e1467815b3479342c84d45df965aba78414727c4`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-s390x.tar.gz) | `e2a454151ae5dd891230fb516a3f73f73ab97832db66fd3d12e7f1657a569f58a9fe2654d50ddd7d8ec88a5ff5094199323a4c6d7d44dcf7edb06cca11dd4de1`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-386.tar.gz) | `14b262ba3b71c41f545db2a017cf1746075ada5745a858d2a62bc9df7c5dc10607220375db85e2c4cb85307b09709e58bc66a407488e0961191e3249dc7742b0`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-amd64.tar.gz) | `26353c294755a917216664364b524982b7f5fc6aa832ce90134bb178df8a78604963c68873f121ea5f2626ff615bdbf2ffe54e00578739cde6df42ffae034732`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-amd64.tar.gz) | `ba77e0e7c610f59647c1b2601f82752964a0f54b7ad609a89b00fcfd553d0f0249f6662becbabaa755bb769b36a2000779f08022c40fb8cc61440337481317a1`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm.tar.gz) | `45e87b3e844ea26958b0b489e8c9b90900a3253000850f5ff9e87ffdcafba72ab8fd17b5ba092051a58a4bc277912c047a85940ec7f093dff6f9e8bf6fed3b42`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm64.tar.gz) | `155e136e3124ead69c594eead3398d6cfdbb8f823c324880e8a7bbd1b570b05d13a77a69abd0a6758cfcc7923971cc6da4d3e0c1680fd519b632803ece00d5ce`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-ppc64le.tar.gz) | `3fa0fb8221da19ad9d03278961172b7fa29a618b30abfa55e7243bb937dede8df56658acf02e6b61e7274fbc9395e237f49c62f2a83017eca2a69f67af31c01c`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-s390x.tar.gz) | `db3199c3d7ba0b326d71dc8b80f50b195e79e662f71386a3b2976d47d13d7b0136887cc21df6f53e70a3d733da6eac7bbbf3bab2df8a1909a3cee4b44c32dd0b`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-amd64.tar.gz) | `addcdfbad7f12647e6babb8eadf853a374605c8f18bf63f416fa4d3bf1b903aa206679d840433206423a984bb925e7983366edcdf777cf5daef6ef88e53d6dfa`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm.tar.gz) | `b2ac54e0396e153523d116a2aaa32c919d6243931e0104cd47a23f546d710e7abdaa9eae92d978ce63c92041e63a9b56f5dd8fd06c812a7018a10ecac440f768`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm64.tar.gz) | `7aab36f2735cba805e4fd109831a1af0f586a88db3f07581b6dc2a2aab90076b22c96b490b4f6461a8fb690bf78948b6d514274f0d6fb0664081de2d44dc48e1`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-ppc64le.tar.gz) | `a579936f07ebf86f69f297ac50ba4c34caf2c0b903f73190eb581c78382b05ef36d41ade5bfd25d7b1b658cfcbee3d7125702a18e7480f9b09a62733a512a18a`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-s390x.tar.gz) | `58fa0359ddd48835192fab1136a2b9b45d1927b04411502c269cda07cb8a8106536973fb4c7fedf1d41893a524c9fe2e21078fdf27bfbeed778273d024f14449`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-windows-amd64.tar.gz) | `9086c03cd92b440686cea6d8c4e48045cc46a43ab92ae0e70350b3f51804b9e2aaae7178142306768bae00d9ef6dd938167972bfa90b12223540093f735a45db`
-
-## Changelog since v1.18.0-alpha.3
-
-### Deprecation
-
-- Kubeadm: command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-
-### API Change
-
-- Kubelet podresources API now provides the information about active pods only. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG Node]
-- Remove deprecated fields from .leaderElection in kubescheduler.config.k8s.io/v1alpha2 ([#87904](https://github.com/kubernetes/kubernetes/pull/87904), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Signatures on generated clientset methods have been modified to accept `context.Context` as a first argument. Signatures of generated Create, Update, and Patch methods have been updated to accept CreateOptions, UpdateOptions and PatchOptions respectively. Clientsets that with the previous interface have been added in new "deprecated" packages to allow incremental migration to the new APIs. The deprecated packages will be removed in the 1.21 release. ([#87299](https://github.com/kubernetes/kubernetes/pull/87299), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, Apps, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Scheduling, Storage, Testing and Windows]
-- The k8s.io/node-api component is no longer updated. Instead, use the RuntimeClass types located within k8s.io/api, and the generated clients located within k8s.io/client-go ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG Node and Release]
-
-### Feature
-
-- Add indexer for storage cacher ([#85445](https://github.com/kubernetes/kubernetes/pull/85445), [@shaloulcy](https://github.com/shaloulcy)) [SIG API Machinery]
-- Add support for mount options to the FC volume plugin ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG Storage]
-- Added a config-mode flag in azure auth module to enable getting AAD token without spn: prefix in audience claim. When it's not specified, the default behavior doesn't change. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth, CLI and Cloud Provider]
-- Introduced BackoffManager interface for backoff management ([#87829](https://github.com/kubernetes/kubernetes/pull/87829), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
-- PodTopologySpread plugin now excludes terminatingPods when making scheduling decisions. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
-- Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver)
-  The in-tree AWS OpenStack Cinder "kubernetes.io/cinder" was already deprecated a while ago and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time.
-  Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider]
-
-### Design
-
-- The scheduler Permit extension point doesn't return a boolean value in its Allow() and Reject() functions. ([#87936](https://github.com/kubernetes/kubernetes/pull/87936), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
-
-### Other (Bug, Cleanup or Flake)
-
-- Adds "volume.beta.kubernetes.io/migrated-to" annotation to PV's and PVC's when they are migrated to signal external provisioners to pick up those objects for Provisioning and Deleting. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG Apps and Storage]
-- Fix a bug in the dual-stack IPVS proxier where stale IPv6 endpoints were not being cleaned up ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
-- Fix kubectl drain ignore daemonsets and others. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix: add azure disk migration support for CSINode ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: add non-retriable errors in azure clients ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fixed NetworkPolicy validation that Except values are accepted when they are outside the CIDR range. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG Network]
-- Improves performance of the node authorizer ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- Iptables/userspace proxy: improve performance by getting local addresses only once per sync loop, instead of for every external IP ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Network]
-- Kube-aggregator: always sets unavailableGauge metric to reflect the current state of a service. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
-- Kubeadm allows to configure single-stack clusters if dual-stack is enabled ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, Cluster Lifecycle and Network]
-- Kubeadm:  'kubeadm alpha kubelet config download' has been removed, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm: remove 'kubeadm upgrade node config' command since it was deprecated in v1.15, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubectl describe <type> and kubectl top pod will return a message saying "No resources found" or "No resources found in <namespace> namespace" if there are no results to display. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- Kubelet metrics gathered through metrics-server or prometheus should no longer timeout for Windows nodes running more than 3 pods. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG Node, Testing and Windows]
-- Kubelet metrics have been changed to buckets.
-  For example the exec/{podNamespace}/{podID}/{containerName} is now just exec. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG Node]
-- Limit number of instances in a single update to GCE target pool to 1000. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability]
-- Make Azure clients only retry on specified HTTP status codes ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Pause image contains "Architecture" in non-amd64 images ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG Release]
-- Pods that are considered for preemption and haven't started don't produce an error log. ([#87900](https://github.com/kubernetes/kubernetes/pull/87900), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Prevent error message from being displayed when running kubectl plugin list and your path includes an empty string ([#87633](https://github.com/kubernetes/kubernetes/pull/87633), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- `kubectl create clusterrolebinding` creates rbac.authorization.k8s.io/v1 object ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI]
-
-# v1.18.0-alpha.4
-
-[Documentation](https://docs.k8s.io)
-
-## Important note about manual tag
-
-Due to a [tagging bug in our Release Engineering tooling](https://github.com/kubernetes/release/issues/1080) during `v1.18.0-alpha.3`, we needed to push a manual tag (`v1.18.0-alpha.4`).
-
-**No binaries have been produced or will be provided for `v1.18.0-alpha.4`.**
-
-The changelog for `v1.18.0-alpha.4` is included as part of the [changelog since v1.18.0-alpha.3][#changelog-since-v1180-alpha3] section.
-
-# v1.18.0-alpha.3
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.3
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes.tar.gz) | `60bf3bfc23b428f53fd853bac18a4a905b980fcc0bacd35ccd6357a89cfc26e47de60975ea6b712e65980e6b9df82a22331152d9f08ed4dba44558ba23a422d4`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-src.tar.gz) | `8adf1016565a7c93713ab6fa4293c2d13b4f6e4e1ec4dcba60bd71e218b4dbe9ef5eb7dbb469006743f498fc7ddeb21865cd12bec041af60b1c0edce8b7aecd5`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-386.tar.gz) | `abb32e894e8280c772e96227b574da81cd1eac374b8d29158b7f222ed550087c65482eef4a9817dfb5f2baf0d9b85fcdfa8feced0fbc1aacced7296853b57e1f`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | `5e4b1a993264e256ec1656305de7c306094cae9781af8f1382df4ce4eed48ce030827fde1a5e757d4ad57233d52075c9e4e93a69efbdc1102e4ba810705ccddc`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-386.tar.gz) | `68da39c2ae101d2b38f6137ceda07eb0c2124794982a62ef483245dbffb0611c1441ca085fa3127e7a9977f45646788832a783544ff06954114548ea0e526e46`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | `dc236ffa8ad426620e50181419e9bebe3c161e953dbfb8a019f61b11286e1eb950b40d7cc03423bdf3e6974973bcded51300f98b55570c29732fa492dcde761d`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | `ab0a8bd6dc31ea160b731593cdc490b3cc03668b1141cf95310bd7060dcaf55c7ee9842e0acae81063fdacb043c3552ccdd12a94afd71d5310b3ce056fdaa06c`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | `159ea083c601710d0d6aea423eeb346c99ffaf2abd137d35a53e87a07f5caf12fca8790925f3196f67b768fa92a024f83b50325dbca9ccd4dde6c59acdce3509`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | `16b0459adfa26575d13be49ab53ac7f0ffd05e184e4e13d2dfbfe725d46bb8ac891e1fd8aebe36ecd419781d4cc5cf3bd2aaaf5263cf283724618c4012408f40`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | `d5aa1f5d89168995d2797eb839a04ce32560f405b38c1c0baaa0e313e4771ae7bb3b28e22433ad5897d36aadf95f73eb69d8d411d31c4115b6b0adf5fe041f85`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-386.tar.gz) | `374e16a1e52009be88c94786f80174d82dff66399bf294c9bee18a2159c42251c5debef1109a92570799148b08024960c6c50b8299a93fd66ebef94f198f34e9`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | `5a94c1068c19271f810b994adad8e62fae03b3d4473c7c9e6d056995ff7757ea61dd8d140c9267dd41e48808876673ce117826d35a3c1bb5652752f11a044d57`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | `a677bec81f0eba75114b92ff955bac74512b47e53959d56a685dae5edd527283d91485b1e86ad74ef389c5405863badf7eb22e2f0c9a568a4d0cb495c6a5c32f`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | `2fb696f86ff13ebeb5f3cf2b254bf41303644c5ea84a292782eac6123550702655284d957676d382698c091358e5c7fe73f32803699c19be7138d6530fe413b6`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | `738e95da9cfb8f1309479078098de1c38cef5e1dd5ee1129b77651a936a412b7cd0cf15e652afc7421219646a98846ab31694970432e48dea9c9cafa03aa59cf`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | `7a85bfcbb2aa636df60c41879e96e788742ecd72040cb0db2a93418439c125218c58a4cfa96d01b0296c295793e94c544e87c2d98d50b49bc4cb06b41f874376`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | `1f1cdb2efa3e7cac857203d8845df2fdaa5cf1f20df764efffff29371945ec58f6deeba06f8fbf70b96faf81b0c955bf4cb84e30f9516cb2cc1ed27c2d2185a6`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | `4ccfced3f5ba4adfa58f4a9d1b2c5bdb3e89f9203ab0e27d11eb1c325ac323ebe63c015d2c9d070b233f5d1da76cab5349da3528511c1cd243e66edc9af381c4`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | `d695a69d18449062e4c129e54ec8384c573955f8108f4b78adc2ec929719f2196b995469c728dd6656c63c44cda24315543939f85131ebc773cfe0de689df55b`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | `21df1da88c89000abc22f97e482c3aaa5ce53ec9628d83dda2e04a1d86c4d53be46c03ed6f1f211df3ee5071bce39d944ff7716b5b6ada3b9c4821d368b0a898`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | `ff77e3aacb6ed9d89baed92ef542c8b5cec83151b6421948583cf608bca3b779dce41fc6852961e00225d5e1502f6a634bfa61a36efa90e1aee90dedb787c2d2`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | `57d75b7977ec1a0f6e7ed96a304dbb3b8664910f42ca19aab319a9ec33535ff5901dfca4abcb33bf5741cde6d152acd89a5f8178f0efe1dc24430e0c1af5b98f`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | `63fdbb71773cfd73a914c498e69bb9eea3fc314366c99ffb8bd42ec5b4dae807682c83c1eb5cfb1e2feb4d11d9e49cc85ba644e954241320a835798be7653d61`
-
-## Changelog since v1.18.0-alpha.2
-
-### Deprecation
-
-- Remove all the generators from kubectl run. It will now only create pods. Additionally, deprecates all the flags that are not relevant anymore. ([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, SIG CLI, and SIG Testing]
-- kubeadm: kube-dns is deprecated and will not be supported in a future version ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-
-### API Change
-
-- Add kubescheduler.config.k8s.io/v1alpha2 ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- --enable-cadvisor-endpoints is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, SIG Node, and SIG Testing]
-- The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
-
-### Feature
-
-- aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery]
-- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2.  The messages are of the form
-
-  Throttling request took 1.50705208s, request: GET:<URL>
-
-  The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery]
-- kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- The kubectl --dry-run flag now accepts the values 'client', 'server', and 'none', to support client-side and server-side dry-run strategies. The boolean and unset values for the --dry-run flag are deprecated and a value will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-- Add support for pre-allocated hugepages for more than one page size ([#82820](https://github.com/kubernetes/kubernetes/pull/82820), [@odinuge](https://github.com/odinuge)) [SIG Apps]
-- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, SIG Cluster Lifecycle, SIG Network, SIG Release, and SIG Testing]
-- Skip default spreading scoring plugin for pods that define TopologySpreadConstraints ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling]
-- Added more details to taint toleration errors ([#87250](https://github.com/kubernetes/kubernetes/pull/87250), [@starizard](https://github.com/starizard)) [SIG Apps, and SIG Scheduling]
-- Scheduler: Add DefaultBinder plugin ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling, and SIG Testing]
-- Kube-apiserver metrics will now include request counts, latencies, and response sizes for /healthz, /livez, and /readyz requests. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery]
-
-### Other (Bug, Cleanup or Flake)
-
-- Fix the masters rolling upgrade causing thundering herd of LISTs on etcd leading to control plane unavailability. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, SIG Node, and SIG Testing]
-- `kubectl diff` now returns 1 only on diff finding changes, and >1 on kubectl errors. The "exit status code 1" message as also been muted. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI, and SIG Testing]
-- To reduce chances of throttling, VM cache is set to nil when Azure node provisioning state is deleting ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fix regression in statefulset conversion which prevented applying a statefulset multiple times. ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG Apps, and SIG Testing]
-- fixed two scheduler metrics (pending_pods and schedule_attempts_total) not being recorded ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG Scheduling]
-- Resolved a performance issue in the node authorizer index maintenance. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- Removed the 'client' label from apiserver_request_total. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, and SIG Instrumentation]
-- `(*"k8s.io/client-go/rest".Request).{Do,DoRaw,Stream,Watch}` now require callers to pass a `context.Context` as an argument. The context is used for timeout and cancellation signaling and to pass supplementary information to round trippers in the wrapped transport chain. If you don't need any of this functionality, it is sufficient to pass a context created with `context.Background()` to these functions. The `(*"k8s.io/client-go/rest".Request).Context` method is removed now that all methods that execute a request accept a context directly. ([#87597](https://github.com/kubernetes/kubernetes/pull/87597), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, SIG Apps, SIG Auth, SIG Autoscaling, SIG CLI, SIG Cloud Provider, SIG Cluster Lifecycle, SIG Instrumentation, SIG Network, SIG Node, SIG Scheduling, SIG Storage, and SIG Testing]
-- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#87258](https://github.com/kubernetes/kubernetes/pull/87258), [@verult](https://github.com/verult)) [SIG Apps, SIG Node, and SIG Storage]
-- kubeadm: apply further improvements to the tentative support for concurrent etcd member join. Fixes a bug where multiple members can receive the same hostname. Increase the etcd client dial timeout and retry timeout for add/remove/... operations. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Reverted a kubectl azure auth module change where oidc claim spn: prefix was omitted resulting a breaking behavior with existing Azure AD OIDC enabled api-server ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, SIG Auth, and SIG Cloud Provider]
-- Update cri-tools to v1.17.0 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cluster Lifecycle, and SIG Release]
-- kubeadm: remove the deprecated CoreDNS feature-gate. It was set to "true" since v1.11 when the feature went GA. In v1.13 it was marked as deprecated and hidden from the CLI. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Shared informers are now more reliable in the face of network disruption. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery]
-- the CSR signing cert/key pairs will be reloaded from disk like the kube-apiserver cert/key pairs ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, SIG Apps, and SIG Auth]
-- "kubectl describe statefulsets.apps" prints garbage for rolling update partition ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI]
-
-
-<!-- NEW RELEASE NOTES ENTRY -->
-
-
-# v1.18.0-alpha.2
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.2
-
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes.tar.gz) | `7af83386b4b35353f0aa1bdaf73599eb08b1d1ca11ecc2c606854aff754db69f3cd3dc761b6d7fc86f01052f615ca53185f33dbf9e53b2f926b0f02fc103fbd3`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-src.tar.gz) | `a14b02a0a0bde97795a836a8f5897b0ee6b43e010e13e43dd4cca80a5b962a1ef3704eedc7916fed1c38ec663a71db48c228c91e5daacba7d9370df98c7ddfb6`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-386.tar.gz) | `427f214d47ded44519007de2ae87160c56c2920358130e474b768299751a9affcbc1b1f0f936c39c6138837bca2a97792a6700896976e98c4beee8a1944cfde1`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | `861fd81ac3bd45765575bedf5e002a2294aba48ef9e15980fc7d6783985f7d7fcde990ea0aef34690977a88df758722ec0a2e170d5dcc3eb01372e64e5439192`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-386.tar.gz) | `7d59b05d6247e2606a8321c72cd239713373d876dbb43b0fb7f1cb857fa6c998038b41eeed78d9eb67ce77b0b71776ceed428cce0f8d2203c5181b473e0bd86c`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | `7cdefb4e32bad9d2df5bb8e7e0a6f4dab2ae6b7afef5d801ac5c342d4effdeacd799081fa2dec699ecf549200786c7623c3176252010f12494a95240dd63311d`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | `6212bbf0fa1d01ced77dcca2c4b76b73956cd3c6b70e0701c1fe0df5ff37160835f6b84fa2481e0e6979516551b14d8232d1c72764a559a3652bfe2a1e7488ff`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | `1f0d9990700510165ee471acb2f88222f1b80e8f6deb351ce14cf50a70a9840fb99606781e416a13231c74b2bd7576981b5348171aa33b628d2666e366cd4629`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | `77e00ba12a32db81e96f8de84609de93f32c61bb3f53875a57496d213aa6d1b92c09ad5a6de240a78e1a5bf77fac587ff92874f34a10f8909ae08ca32fda45d2`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | `a39ec2044bed5a4570e9c83068e0fc0ce923ccffa44380f8bbc3247426beaff79c8a84613bcb58b05f0eb3afbc34c79fe3309aa2e0b81abcfd0aa04770e62e05`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-386.tar.gz) | `1a0ab88f9b7e34b60ab31d5538e97202a256ad8b7b7ed5070cae5f2f12d5d4edeae615db7a34ebbe254004b6393c6b2480100b09e30e59c9139492a3019a596a`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | `1966eb5dfb78c1bc33aaa6389f32512e3aa92584250a0164182f3566c81d901b59ec78ee4e25df658bc1dd221b5a9527d6ce3b6c487ca3e3c0b319a077caa735`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | `f814d6a3872e4572aa4da297c29def4c1fad8eba0903946780b6bf9788c72b99d71085c5aef9e12c01133b26fa4563c1766ba724ad2a8af2670a24397951a94d`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | `56aa08225e546c92c2ff88ac57d3db7dd5e63640772ea72a429f080f7069827138cbc206f6f5fe3a0c01bfca043a9eda305ecdc1dcb864649114893e46b6dc84`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | `fb87128d905211ba097aa860244a376575ae2edbaca6e51402a24bc2964854b9b273e09df3d31a2bcffc91509f7eecb2118b183fb0e0eb544f33403fa235c274`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | `6d21fbf39b9d3a0df9642407d6f698fabdc809aca83af197bceb58a81b25846072f407f8fb7caae2e02dc90912e3e0f5894f062f91bcb69f8c2329625d3dfeb7`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | `ddcda4dc360ca97705f71bf2a18ddacd7b7ddf77535b62e699e97a1b2dd24843751313351d0112e238afe69558e8271eba4d27ab77bb67b4b9e3fbde6eec85c9`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | `78915a9bde35c70c67014f0cea8754849db4f6a84491a3ad9678fd3bc0203e43af5a63cfafe104ae1d56b05ce74893a87a6dcd008d7859e1af6b3bce65425b5d`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | `3218e811abcb0cb09d80742def339be3916db5e9bbc62c0dc8e6d87085f7e3d9eeed79dea081906f1de78ddd07b7e3acdbd7765fdb838d262bb35602fd1df106`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | `fa22de9c4440b8fb27f4e77a5a63c5e1c8aa8aa30bb79eda843b0f40498c21b8c0ad79fff1d841bb9fef53fe20da272506de9a86f81a0b36d028dbeab2e482ce`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | `bbda9b5cc66e8f13d235703b2a85e2c4f02fa16af047be4d27a3e198e11eb11706e4a0fbb6c20978c770b069cd4cd9894b661f09937df9d507411548c36576e0`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | `b2ed1eda013069adce2aac00b86d75b84e006cfce9bafac0b5a2bafcb60f8f2cb346b5ea44eafa72d777871abef1ea890eb3a2a05de28968f9316fa88886a8ed`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | `bd8eb23dba711f31b5148257076b1bbe9629f2a75de213b2c779bd5b29279e9bf22f8bde32f4bc814f4c0cc49e19671eb8b24f4105f0fe2c1490c4b78ec3c704`
-
-## Changelog since v1.18.0-alpha.1
-
-### Other notable changes
-
-* Bump golang/mock version to v1.3.1 ([#87326](https://github.com/kubernetes/kubernetes/pull/87326), [@wawa0210](https://github.com/wawa0210))
-* fix a bug that orphan revision cannot be adopted and statefulset cannot be synced ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli))
-* Azure storage clients now suppress requests on throttling ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer))
-* Introduce Alpha field `Immutable` in both Secret and ConfigMap objects to mark their contents as immutable. The implementation is hidden behind feature gate `ImmutableEphemeralVolumes` (currently in Alpha stage). ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t))
-* EndpointSlices will now be enabled by default. A new `EndpointSliceProxying` feature gate determines if kube-proxy will use EndpointSlices, this is disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
-* kubeadm upgrades always persist the etcd backup for stacked ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu))
-* Fix the bug PIP's DNS is deleted if no DNS label service annotation isn't set. ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19))
-* New flag `--show-hidden-metrics-for-version` in kube-controller-manager can be used to show all hidden metrics that deprecated in the previous minor release. ([#85281](https://github.com/kubernetes/kubernetes/pull/85281), [@RainbowMango](https://github.com/RainbowMango))
-* Azure network and VM clients now suppress requests on throttling ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer))
-* `kubectl apply  -f <file> --prune -n <namespace>` should prune all resources not defined in the file in the cli specified namespace. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu))
-* Fixes service account token admission error in clusters that do not run the service account token controller ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt))
-* CustomResourceDefinition status fields are no longer required for client validation when submitting manifests.  ([#87213](https://github.com/kubernetes/kubernetes/pull/87213), [@hasheddan](https://github.com/hasheddan))
-* All apiservers log request lines in a more greppable format. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp))
-* provider/azure: Network security groups can now be in a separate resource group. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon))
-* Cleaned up the output from `kubectl describe CSINode <name>`. ([#85283](https://github.com/kubernetes/kubernetes/pull/85283), [@huffmanca](https://github.com/huffmanca))
-* Fixed the following  ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919))
-    * -  AWS Cloud Provider attempts to delete LoadBalancer security group it didn’t provision
-    * -  AWS Cloud Provider creates default LoadBalancer security group even if annotation [service.beta.kubernetes.io/aws-load-balancer-security-groups] is present
-* kubelet: resource metrics endpoint `/metrics/resource/v1alpha1` as well as all metrics under this endpoint have been deprecated. ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango))
-    * Please convert to the following metrics emitted by endpoint `/metrics/resource`:
-    * - scrape_error --> scrape_error
-    * - node_cpu_usage_seconds_total --> node_cpu_usage_seconds
-    * - node_memory_working_set_bytes --> node_memory_working_set_bytes
-    * - container_cpu_usage_seconds_total --> container_cpu_usage_seconds
-    * - container_memory_working_set_bytes --> container_memory_working_set_bytes
-    * - scrape_error --> scrape_error
-* You can now pass "--node-ip ::" to kubelet to indicate that it should autodetect an IPv6 address to use as the node's primary address. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship))
-* kubeadm: support automatic retry after failing to pull image ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu))
-* TODO ([#87044](https://github.com/kubernetes/kubernetes/pull/87044), [@jennybuckley](https://github.com/jennybuckley))
-* Improved yaml parsing performance ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen))
-* Fixed a bug which could prevent a provider ID from ever being set for node if an error occurred determining the provider ID when the node was added. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs))
-* fix a regression in kubenet that prevent pods to obtain ip addresses ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs))
-* Bind kube-dns containers to linux nodes to avoid Windows scheduling ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210))
-* The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness))
-* Bind dns-horizontal containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210))
-* fix kubectl annotate error when local=true is set ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0))
-* Bug fixes: ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera))
-    * Make sure we include latest packages node #351 ([@caseydavenport](https://github.com/caseydavenport))
-* fix kuebctl apply set-last-applied namespaces error   ([#86474](https://github.com/kubernetes/kubernetes/pull/86474), [@zhouya0](https://github.com/zhouya0))
-* Add VolumeBinder method to FrameworkHandle interface, which allows user to get the volume binder when implementing scheduler framework plugins. ([#86940](https://github.com/kubernetes/kubernetes/pull/86940), [@skilxn-go](https://github.com/skilxn-go))
-* elasticsearch supports automatically setting the advertise address ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu))
-* If a serving certificates param specifies a name that is an IP for an SNI certificate, it will have priority for replying to server connections. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k))
-* kube-proxy: Added dual-stack IPv4/IPv6 support to the iptables proxier. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry))
-* Azure VMSS/VMSSVM clients now suppress requests on throttling ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer))
-* New metric kubelet_pleg_last_seen_seconds to aid diagnosis of PLEG not healthy issues. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham))
-* For subprotocol negotiation, both client and server protocol is required now. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu))
-* kubeadm: use bind-address option to configure the kube-controller-manager and kube-scheduler http probes ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea))
-* Marked scheduler's metrics scheduling_algorithm_predicate_evaluation_seconds and ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei))
-    * scheduling_algorithm_priority_evaluation_seconds as deprecated. Those are replaced by framework_extension_point_duration_seconds[extenstion_point="Filter"] and framework_extension_point_duration_seconds[extenstion_point="Score"] respectively.
-* Marked scheduler's scheduling_duration_seconds Summary metric as deprecated ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei))
-* Add instructions about how to bring up e2e test cluster ([#85836](https://github.com/kubernetes/kubernetes/pull/85836), [@YangLu1031](https://github.com/YangLu1031))
-* If a required flag is not provided to a command, the user will only see the required flag error message, instead of the entire usage menu. ([#86693](https://github.com/kubernetes/kubernetes/pull/86693), [@sallyom](https://github.com/sallyom))
-* kubeadm: tolerate whitespace when validating certificate authority PEM data in kubeconfig files ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123))
-* kubeadm: add support for the "ci/k8s-master" version label as a replacement for "ci-cross/*", which no longer exists. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu))
-* Fix EndpointSlice controller race condition and ensure that it handles external changes to EndpointSlices. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott))
-* Fix nil pointer dereference in azure cloud provider ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx))
-* fix: azure disk could not mounted on Standard_DC4s/DC2s instances ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx))
-* Fixes v1.17.0 regression in --service-cluster-ip-range handling with IPv4 ranges larger than 65536 IP addresses ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt))
-* Adds back support for AlwaysCheckAllPredicates flag. ([#86496](https://github.com/kubernetes/kubernetes/pull/86496), [@ahg-g](https://github.com/ahg-g))
-* Azure global rate limit is switched to per-client. A set of new rate limit configure options are introduced, including routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit and VirtualMachineSizeRateLimit. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer))
-    * The original rate limit options would be default values for those new client's rate limiter.
-* Fix issue [#85805](https://github.com/kubernetes/kubernetes/pull/85805) about resource not found in azure cloud provider when lb specified in other resource group. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm))
-* `AlwaysCheckAllPredicates` is deprecated in scheduler Policy API. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei))
-* Kubernetes KMS provider for data encryption now supports disabling the in-memory data encryption key (DEK) cache by setting cachesize to a negative value. ([#86294](https://github.com/kubernetes/kubernetes/pull/86294), [@enj](https://github.com/enj))
-* option `preConfiguredBackendPoolLoadBalancerTypes` is added to azure cloud provider for the pre-configured load balancers, possible values: `""`, `"internal"`, "external"`, `"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion))
-* Promote StartupProbe to beta for 1.18 release ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx))
-* Fixes issue where AAD token obtained by kubectl is incompatible with on-behalf-of flow and oidc. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong))
-    * The audience claim before this fix has "spn:" prefix. After this fix, "spn:" prefix is omitted.
-* change CounterVec to Counter about  PLEGDiscardEvent ([#86167](https://github.com/kubernetes/kubernetes/pull/86167), [@yiyang5055](https://github.com/yiyang5055))
-* hollow-node do not use remote CRI anymore ([#86425](https://github.com/kubernetes/kubernetes/pull/86425), [@jkaniuk](https://github.com/jkaniuk))
-* hollow-node use fake CRI ([#85879](https://github.com/kubernetes/kubernetes/pull/85879), [@gongguan](https://github.com/gongguan))
-
-
-
-# v1.18.0-alpha.1
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.1
-
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes.tar.gz) | `0c4904efc7f4f1436119c91dc1b6c93b3bd9c7490362a394bff10099c18e1e7600c4f6e2fcbaeb2d342a36c4b20692715cf7aa8ada6dfac369f44cc9292529d7`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-src.tar.gz) | `0a50fc6816c730ca5ae4c4f26d5ad7b049607d29f6a782a4e5b4b05ac50e016486e269dafcc6a163bd15e1a192780a9a987f1bb959696993641c603ed1e841c8`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-386.tar.gz) | `c6d75f7f3f20bef17fc7564a619b54e6f4a673d041b7c9ec93663763a1cc8dd16aecd7a2af70e8d54825a0eecb9762cf2edfdade840604c9a32ecd9cc2d5ac3c`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | `ca1f19db289933beace6daee6fc30af19b0e260634ef6e89f773464a05e24551c791be58b67da7a7e2a863e28b7cbcc7b24b6b9bf467113c26da76ac8f54fdb6`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-386.tar.gz) | `af2e673653eb39c3f24a54efc68e1055f9258bdf6cf8fea42faf42c05abefc2da853f42faac3b166c37e2a7533020b8993b98c0d6d80a5b66f39e91d8ae0a3fb`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | `9009032c3f94ac8a78c1322a28e16644ce3b20989eb762685a1819148aed6e883ca8e1200e5ec37ec0853f115c67e09b5d697d6cf5d4c45f653788a2d3a2f84f`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | `afba9595b37a3f2eead6e3418573f7ce093b55467dce4da0b8de860028576b96b837a2fd942f9c276e965da694e31fbd523eeb39aefb902d7e7a2f169344d271`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | `04fc3b2fe3f271807f0bc6c61be52456f26a1af904964400be819b7914519edc72cbab9afab2bb2e2ba1a108963079367cedfb253c9364c0175d1fcc64d52f5c`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | `04c7edab874b33175ff7bebfff5b3a032bc6eb088fcd7387ffcd5b3fa71395ca8c5f9427b7ddb496e92087dfdb09eaf14a46e9513071d3bd73df76c182922d38`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | `499287dbbc33399a37b9f3b35e0124ff20b17b6619f25a207ee9c606ef261af61fa0c328dde18c7ce2d3dfb2eea2376623bc3425d16bc8515932a68b44f8bede`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-386.tar.gz) | `cf84aeddf00f126fb13c0436b116dd0464a625659e44c84bf863517db0406afb4eefd86807e7543c4f96006d275772fbf66214ae7d582db5865c84ac3545b3e6`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | `69f20558ccd5cd6dbaccf29307210db4e687af21f6d71f68c69d3a39766862686ac1333ab8a5012010ca5c5e3c11676b45e498e3d4c38773da7d24bcefc46d95`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | `3f29df2ce904a0f10db4c1d7a425a36f420867b595da3fa158ae430bfead90def2f2139f51425b349faa8a9303dcf20ea01657cb6ea28eb6ad64f5bb32ce2ed1`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | `4a21073b2273d721fbf062c254840be5c8471a010bcc0c731b101729e36e61f637cb7fcb521a22e8d24808510242f4fff8a6ca40f10e9acd849c2a47bf135f27`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | `7f1cb6d721bedc90e28b16f99bea7e59f5ad6267c31ef39c14d34db6ad6aad87ee51d2acdd01b6903307c1c00b58ff6b785a03d5a491cc3f8a4df9a1d76d406c`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | `8f2b552030b5274b1c2c7c166eacd5a14b0c6ca0f23042f4c52efe87e22a167ba4460dcd66615a5ecd26d9e88336be1fb555548392e70efe59070dd2c314da98`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | `8d9f2c96f66edafb7c8b3aa90960d29b41471743842aede6b47b3b2e61f4306fb6fc60b9ebc18820c547ee200bfedfe254c1cde962d447c791097dd30e79abdb`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | `84194cb081d1502f8ca68143569f9707d96f1a28fcf0c574ebd203321463a8b605f67bb2a365eaffb14fbeb8d55c8d3fa17431780b242fb9cba3a14426a0cd4a`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | `0091e108ab94fd8683b89c597c4fdc2fbf4920b007cfcd5297072c44bc3a230dfe5ceed16473e15c3e6cf5edab866d7004b53edab95be0400cc60e009eee0d9d`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | `b7e85682cc2848a35d52fd6f01c247f039ee1b5dd03345713821ea10a7fa9939b944f91087baae95eaa0665d11857c1b81c454f720add077287b091f9f19e5d3`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | `cd1f0849e9c62b5d2c93ff0cebf58843e178d8a88317f45f76de0db5ae020b8027e9503a5fccc96445184e0d77ecdf6f57787176ac31dbcbd01323cd0a190cbb`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | `e1e697a34424c75d75415b613b81c8af5f64384226c5152d869f12fd7db1a3e25724975b73fa3d89e56e4bf78d5fd07e68a709ba8566f53691ba6a88addc79ea`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | `c725a19a4013c74e22383ad3fb4cb799b3e161c4318fdad066daf806730a89bc3be3ff0f75678d02b3cbe52b2ef0c411c0639968e200b9df470be40bb2c015cc`
-
-## Changelog since v1.17.0
-
-### Action Required
-
-* action required ([#85363](https://github.com/kubernetes/kubernetes/pull/85363), [@immutableT](https://github.com/immutableT))
-    * 1. Currently, if users were to explicitly specify CacheSize of 0 for KMS provider, they would end-up with a provider that caches up to 1000 keys. This PR changes this behavior.
-    * Post this PR, when users supply 0 for CacheSize this will result in a validation error.
-    * 2. CacheSize type was changed from int32 to *int32. This allows defaulting logic to differentiate between cases where users explicitly supplied 0 vs. not supplied any value.
-    * 3. KMS Provider's endpoint (path to Unix socket) is now validated when the EncryptionConfiguration files is loaded. This used to be handled by the GRPCService.
-
-### Other notable changes
-
-* fix: azure data disk should use same key as os disk by default ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx))
-* New flag `--show-hidden-metrics-for-version` in kube-proxy can be used to show all hidden metrics that deprecated in the previous minor release. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango))
-* Remove cluster-monitoring addon ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius))
-* Changed core_pattern on COS nodes to be an absolute path. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml))
-* Track mount operations as uncertain if operation fails with non-final error ([#82492](https://github.com/kubernetes/kubernetes/pull/82492), [@gnufied](https://github.com/gnufied))
-* add kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim))
-* The sample-apiserver aggregated conformance test has updated to use the Kubernetes v1.17.0 sample apiserver ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt))
-* The underlying format of the `CPUManager` state file has changed. Upgrades should be seamless, but any third-party tools that rely on reading the previous format need to be updated. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska))
-* kubernetes will try to acquire the iptables lock every 100 msec during 5 seconds instead of every second. This specially useful for environments using kube-proxy in iptables mode with a high churn rate of services. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea))
-* Fixed a panic in the kubelet cleaning up pod volumes ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu))
-* azure cloud provider cache TTL is configurable, list of the azure cloud provider is as following: ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1))
-    * - "availabilitySetNodesCacheTTLInSeconds"
-    * - "vmssCacheTTLInSeconds"
-    * - "vmssVirtualMachinesCacheTTLInSeconds"
-    * - "vmCacheTTLInSeconds"
-    * - "loadBalancerCacheTTLInSeconds"
-    * - "nsgCacheTTLInSeconds"
-    * - "routeTableCacheTTLInSeconds"
-* Fixes kube-proxy when EndpointSlice feature gate is enabled on Windows. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott))
-* Fixes wrong validation result of NetworkPolicy PolicyTypes ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn))
-* Fixes an issue with kubelet-reported pod status on deleted/recreated pods. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt))
-* kube-apiserver no longer serves the following deprecated APIs: ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt))
-        * All resources under `apps/v1beta1` and `apps/v1beta2` - use `apps/v1` instead
-        * `daemonsets`, `deployments`, `replicasets` resources under `extensions/v1beta1` - use `apps/v1` instead
-        * `networkpolicies` resources under `extensions/v1beta1` - use `networking.k8s.io/v1` instead
-        * `podsecuritypolicies` resources under `extensions/v1beta1` - use `policy/v1beta1` instead
-* kubeadm: fix potential panic when executing "kubeadm reset" with a corrupted kubelet.conf file ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123))
-* Fix a bug in port-forward: named port not working with service ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py))
-* kube-proxy no longer modifies shared EndpointSlices. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott))
-* allow for configuration of CoreDNS replica count ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick))
-* Fixed a regression where the kubelet would fail to update the ready status of pods. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu))
-* Resolves performance regression in client-go discovery clients constructed using `NewDiscoveryClientForConfig` or `NewDiscoveryClientForConfigOrDie`. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt))
-* Make error message and service event message more clear ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer))
-* e2e-test-framework: add e2e test namespace dump if all tests succeed but the cleanup fails. ([#85542](https://github.com/kubernetes/kubernetes/pull/85542), [@schrodit](https://github.com/schrodit))
-* SafeSysctlWhitelist: add net.ipv4.ping_group_range ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda))
-* kubelet: the metric process_start_time_seconds be marked as with the ALPHA stability level. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango))
-* API request throttling (due to a high rate of requests) is now reported in the kubelet (and other component) logs by default.  The messages are of the form ([#80649](https://github.com/kubernetes/kubernetes/pull/80649), [@RobertKrawitz](https://github.com/RobertKrawitz))
-    * Throttling request took 1.50705208s, request: GET:<URL>
-    * The presence of large numbers of these messages, particularly with long delay times, may indicate to the administrator the need to tune the cluster accordingly.
-* Fix API Server potential memory leak issue in processing watch request. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991))
-* Verify kubelet & kube-proxy can recover after being killed on Windows nodes ([#84886](https://github.com/kubernetes/kubernetes/pull/84886), [@YangLu1031](https://github.com/YangLu1031))
-* Fixed an issue that the scheduler only returns the first failure reason. ([#86022](https://github.com/kubernetes/kubernetes/pull/86022), [@Huang-Wei](https://github.com/Huang-Wei))
-* kubectl/drain: add skip-wait-for-delete-timeout option. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino))
-    * If pod DeletionTimestamp older than N seconds, skip waiting for the pod.  Seconds must be greater than 0 to skip.
-* Following metrics have been turned off: ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango))
-    * - kubelet_pod_worker_latency_microseconds
-    * - kubelet_pod_start_latency_microseconds
-    * - kubelet_cgroup_manager_latency_microseconds
-    * - kubelet_pod_worker_start_latency_microseconds
-    * - kubelet_pleg_relist_latency_microseconds
-    * - kubelet_pleg_relist_interval_microseconds
-    * - kubelet_eviction_stats_age_microseconds
-    * - kubelet_runtime_operations
-    * - kubelet_runtime_operations_latency_microseconds
-    * - kubelet_runtime_operations_errors
-    * - kubelet_device_plugin_registration_count
-    * - kubelet_device_plugin_alloc_latency_microseconds
-    * - kubelet_docker_operations
-    * - kubelet_docker_operations_latency_microseconds
-    * - kubelet_docker_operations_errors
-    * - kubelet_docker_operations_timeout
-    * - network_plugin_operations_latency_microseconds
-* - Renamed Kubelet metric certificate_manager_server_expiration_seconds to certificate_manager_server_ttl_seconds and changed to report the second until expiration at read time rather than absolute time of expiry. ([#85874](https://github.com/kubernetes/kubernetes/pull/85874), [@sambdavidson](https://github.com/sambdavidson))
-    * - Improved accuracy of Kubelet metric rest_client_exec_plugin_ttl_seconds.
-* Bind metadata-agent containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210))
-* Bind metrics-server containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210))
-* During initialization phase (preflight), kubeadm now verifies the presence of the conntrack executable ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni))
-* VMSS cache is added so that less chances of VMSS GET throttling ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19))
-* Update go-winio module version from 0.4.11 to 0.4.14 ([#85739](https://github.com/kubernetes/kubernetes/pull/85739), [@wawa0210](https://github.com/wawa0210))
-* Fix LoadBalancer rule checking so that no unexpected LoadBalancer updates are made ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer))
-* kubectl drain node --dry-run will list pods that would be evicted or deleted ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom))
-* Windows nodes on GCE can use TPM-based authentication to the master. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh))
-* kubectl/drain: add disable-eviction option. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino))
-    * Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, and should be used with caution.
-* kubeadm now errors out whenever a not supported component config version is supplied for the kubelet and kube-proxy ([#85639](https://github.com/kubernetes/kubernetes/pull/85639), [@rosti](https://github.com/rosti))
-* Fixed issue with addon-resizer using deprecated extensions APIs ([#85793](https://github.com/kubernetes/kubernetes/pull/85793), [@bskiba](https://github.com/bskiba))
-* Includes FSType when describing CSI persistent volumes. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca))
-* kubelet now exports a "server_expiration_renew_failure" and "client_expiration_renew_failure" metric counter if the certificate rotations cannot be performed. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips))
-* kubeadm: don't write the kubelet environment file on "upgrade apply" ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa))
-* fix azure file AuthorizationFailure ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx))
-* Resolved regression in admission, authentication, and authorization webhook performance in v1.17.0-rc.1 ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt))
-* kubeadm: uses the apiserver AdvertiseAddress IP family to choose the etcd endpoint IP family for non external etcd clusters ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea))
-* kubeadm: Forward cluster name to the controller-manager arguments ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre))
-* Fixed "requested device X but found Y" attach error on AWS. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane))
-* addons: elasticsearch discovery supports IPv6 ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu))
-* kubeadm: retry `kubeadm-config` ConfigMap creation or mutation if the apiserver is not responding. This will improve resiliency when joining new control plane nodes. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre))
-* Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk))
-* Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts))
-* kubectl set resources will no longer return an error if passed an empty change for a resource.  ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom))
-    * kubectl set subject will no longer return an error if passed an empty change for a resource.  
-* kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino))
-* kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123))
-* kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh))
-* kube-apiserver: Fixes a bug that hidden metrics can not be enabled by the command-line option `--show-hidden-metrics-for-version`. ([#85444](https://github.com/kubernetes/kubernetes/pull/85444), [@RainbowMango](https://github.com/RainbowMango))
-* kubeadm now supports automatic calculations of dual-stack node cidr masks to kube-controller-manager.  ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal))
-* Fix bug where EndpointSlice controller would attempt to modify shared objects. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott))
-* Use context to check client closed instead of http.CloseNotifier in processing watch request which will reduce 1 goroutine for each request if proto is HTTP/2.x . ([#85408](https://github.com/kubernetes/kubernetes/pull/85408), [@answer1991](https://github.com/answer1991))
-* kubeadm: reset raises warnings if it cannot delete folders ([#85265](https://github.com/kubernetes/kubernetes/pull/85265), [@SataQiu](https://github.com/SataQiu))
-* Wait for kubelet & kube-proxy to be ready on Windows node within 10s ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031))
diff --git a/content/en/docs/sitemap.md b/content/en/docs/sitemap.md
deleted file mode 100644
index 133f426a6b..0000000000
--- a/content/en/docs/sitemap.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
----
-<script language="JavaScript">
-var dropDownsPopulated = false;
-$( document ).ready(function() {
-  // When the document loads, get the metadata JSON, and kick off tbl render
-  $.get("/metadata.txt", function(data, status) {
-    metadata = $.parseJSON(data);
-    metadata.pages.sort(dynamicSort("t"));
-    mainLogic()
-    $(window).bind( 'hashchange', function(e) {
-      mainLogic();
-    });
-  });
-});
-function mainLogic()
-{
-  // If there's a tag filter, change the table/drop down output
-  if (!dropDownsPopulated) populateDropdowns();
-  var tag=window.location.hash.replace("#","");
-  if(tag) {
-    tag = $.trim(tag);
-    for (i=0;i<tagName.length;i++) {
-      querystringTag = tagName[i] + "=";
-      if (tag.indexOf(querystringTag) > -1)
-      {
-        console.log("in mainLog: querystringTag of " + querystringTag + " matches tag of " + tag);
-        tag = tag.replace(querystringTag,"");
-        selectDropDown(tagName[i],tag);
-        topicsFilter(tagName[i],tag,"output");
-      }
-    }
-  } else {
-    currentTopics = metadata.pages;
-  }
-  renderTable(currentTopics,"output");
-
-}
-function populateDropdowns()
-{
-  // Keeping mainLogic() brief by functionalizing the initialization of the
-  // drop-down filter boxes
-
-  for(i=0;i<metadata.pages.length;i++)
-  {
-    var metadataArrays = [metadata.pages[i].cr,metadata.pages[i].or,metadata.pages[i].mr];
-    for(j=0;j<metadataArrays.length;j++)
-    {
-      if (metadataArrays[j]) {
-        for (k=0;k<metadataArrays[j].length;k++) {
-          if (typeof storedTagsArrays[j] == 'undefined') storedTagsArrays[j] = new Array();
-          storedTagsArrays[j][metadataArrays[j][k][tagName[j]]] = true;
-          // ^ conceptList[metadata.pages[i].cr[k].concept] = true; (if rolling through concepts)
-          // ^ conceptList['container'] = true; (ultimate result)
-          // ^ objectList[metadata.pages[i].or[k].object] = true; (if rolling through objects)
-          // ^ objectList['restartPolicy'] = true; (ultimate result)
-        }
-      }
-    }
-  }
-  var output = new Array();
-  for(i=0;i<tagName.length;i++)
-  {
-    // Phew! All tags in conceptList, objectList, and commandList!
-    // Loop through them and populate those drop-downs through html() injection
-    output = [];
-    output.push("<select id='" + tagName[i] + "' onchange='dropFilter(this)'>");
-    output.push("<option>---</option>");
-    Object.keys(storedTagsArrays[i]).sort().forEach(function (key) {
-      output.push("<option>" + key + "</option>");
-    });
-    output.push("</select>")
-    $(dropDowns[i]).html(output.join(""));
-  }
-  dropDownsPopulated = true;
-}
-function dropFilter(srcobj)
-{
-  // process the change of a drop-down value
-  // the ID of the drop down is either command, object, or concept
-  // these exact values are what topicsFilter() expects, plus a filter val
-  // which we get from .text() of :selected
-  console.log("dropFilter:" + $(srcobj).attr('id') + ":" + $(srcobj).find(":selected").text());
-  topicsFilter($(srcobj).attr('id').replace("#",""),$(srcobj).find(":selected").text(),"output");
-  for(i=0;i<tagName.length;i++)
-  {
-    if($(srcobj).attr('id')!=tagName[i]) selectDropDown(tagName[i],"---");
-  }
-}
-function selectDropDown(type,tag)
-{
-  // change drop-down selection w/o filtering
-  $("#" + type).val(tag);
-}
-</script>
-<style>
-#filters select{
-  font-size: 14px;
-  border: 1px #000 solid;
-}
-#filters {
-  padding-top: 20px;
-}
-</style>
-
-Click tags or use the drop downs to filter. Click table headers to sort or reverse sort.
-
-<p id="filters">
-Filter by Concept: <span id="conceptFilter" /><br/>
-Filter by Object: <span id="objectFilter" /><br/>
-Filter by Command: <span id="commandFilter" />
-</p>
-
-<div id="output" />
diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md
index d05de37f34..7f74320118 100644
--- a/content/en/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md
@@ -149,9 +149,8 @@ certificate.
 
 On some clusters, the apiserver does not require authentication; it may serve
 on localhost, or be protected by a firewall.  There is not a standard
-for this.  [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
-describes how a cluster admin can configure this.  Such approaches may conflict
-with future high-availability support.
+for this.  [Controlling Access to the API](/docs/concepts/security/controlling-access)
+describes how a cluster admin can configure this.
 
 ## Programmatic access to the API
 
diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index 3f3100395c..7d1db15451 100644
--- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -156,7 +156,7 @@ users:
 ```
 
 The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders
-for the pathnames of the certificate files. You need change these to the actual pathnames
+for the pathnames of the certificate files. You need to change these to the actual pathnames
 of certificate files in your environment.
 
 Sometimes you may want to use Base64-encoded data embedded here instead of separate
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 6310d15851..5b3fd114b0 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -132,28 +132,12 @@ The following file is an Ingress resource that sends traffic to your Service via
 
 1. Create `example-ingress.yaml` from the following file:
 
-    ```yaml
-    apiVersion: networking.k8s.io/v1beta1
-    kind: Ingress
-    metadata:
-      name: example-ingress
-      annotations:
-        nginx.ingress.kubernetes.io/rewrite-target: /$1
-    spec:
-      rules:
-      - host: hello-world.info
-        http:
-          paths:
-          - path: /
-            backend:
-              serviceName: web
-              servicePort: 8080
-    ```
+  {{< codenew file="service/networking/example-ingress.yaml" >}}
 
 1. Create the Ingress resource by running the following command:
 
     ```shell
-    kubectl apply -f example-ingress.yaml
+    kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
     ```
 
     Output:
@@ -171,8 +155,8 @@ The following file is an Ingress resource that sends traffic to your Service via
     {{< note >}}This can take a couple of minutes.{{< /note >}}
 
     ```shell
-    NAME              HOSTS              ADDRESS       PORTS     AGE
-    example-ingress   hello-world.info   172.17.0.15   80        38s
+    NAME              CLASS    HOSTS              ADDRESS        PORTS   AGE
+    example-ingress   <none>   hello-world.info   172.17.0.15    80      38s
     ```
 
 1. Add the following line to the bottom of the `/etc/hosts` file.
@@ -232,9 +216,12 @@ The following file is an Ingress resource that sends traffic to your Service via
 
     ```yaml
           - path: /v2
+            pathType: Prefix
             backend:
-              serviceName: web2
-              servicePort: 8080
+              service:
+                name: web2
+                port:
+                  number: 8080
     ```
 
 1. Apply the changes:
diff --git a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index a6c2e217a5..3eceb4f6d2 100644
--- a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -152,7 +152,7 @@ for database debugging.
     or
 
     ```shell
-    kubectl port-forward service/redis-master 7000:6379
+    kubectl port-forward service/redis-master 7000:redis
     ```
 
     Any of the above commands works. The output is similar to this:
diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 7bfcf03ebd..47cec90f26 100644
--- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -55,7 +55,7 @@ You can access Dashboard using the kubectl command-line tool by running the foll
 kubectl proxy
 ```
 
-Kubectl will make Dashboard available at http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.
+Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/).
 
 The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.
 
diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-api.md b/content/en/docs/tasks/administer-cluster/access-cluster-api.md
index 5c94dceffc..ffe200b118 100644
--- a/content/en/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/en/docs/tasks/administer-cluster/access-cluster-api.md
@@ -148,9 +148,8 @@ certificate.
 
 On some clusters, the API server does not require authentication; it may serve
 on localhost, or be protected by a firewall. There is not a standard
-for this. [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
-describes how a cluster admin can configure this. Such approaches may conflict
-with future high-availability support.
+for this. [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
+describes how you can configure this as a cluster administrator.
 
 ### Programmatic access to the API
 
@@ -171,7 +170,10 @@ The Go client can use the same [kubeconfig file](/docs/concepts/configuration/or
 as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go):
 
 ```golang
+package main
+
 import (
+  "context"
   "fmt"
   "k8s.io/apimachinery/pkg/apis/meta/v1"
   "k8s.io/client-go/kubernetes"
@@ -185,7 +187,7 @@ func main() {
   // creates the clientset
   clientset, _ := kubernetes.NewForConfig(config)
   // access the API to list pods
-  pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
+  pods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{})
   fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
 }
 ```
diff --git a/content/en/docs/tasks/administer-cluster/cluster-management.md b/content/en/docs/tasks/administer-cluster/cluster-management.md
deleted file mode 100644
index 3120f4c640..0000000000
--- a/content/en/docs/tasks/administer-cluster/cluster-management.md
+++ /dev/null
@@ -1,223 +0,0 @@
----
-reviewers:
-- lavalamp
-- thockin
-title: Cluster Management
-content_type: concept
----
-
-<!-- overview -->
-
-This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
-upgrading your cluster's
-master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
-running cluster.
-
-<!-- body -->
-
-## Creating and configuring a Cluster
-
-To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/setup/) depending on your environment.
-
-## Upgrading a cluster
-
-The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG/README.md), as well as the version specific upgrade notes prior to upgrading their clusters.
-
-### Upgrading an Azure Kubernetes Service (AKS) cluster
-
-Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
-currently user-initiated and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
-
-### Upgrading Google Compute Engine clusters
-
-Google Compute Engine Open Source (GCE-OSS) support master upgrades by deleting and
-recreating the master, while maintaining the same Persistent Disk (PD) to ensure that data is retained across the
-upgrade.
-
-Node upgrades for GCE use a [Managed Instance Group](https://cloud.google.com/compute/docs/instance-groups/), each node
-is sequentially destroyed and then recreated with new software.  Any Pods that are running on that node need to be
-controlled by a Replication Controller, or manually re-created after the roll out.
-
-Upgrades on open source Google Compute Engine (GCE) clusters are controlled by the `cluster/gce/upgrade.sh` script.
-
-Get its usage by running `cluster/gce/upgrade.sh -h`.
-
-For example, to upgrade just your master to a specific version (v1.0.2):
-
-```shell
-cluster/gce/upgrade.sh -M v1.0.2
-```
-
-Alternatively, to upgrade your entire cluster to the latest stable release:
-
-```shell
-cluster/gce/upgrade.sh release/stable
-```
-
-### Upgrading Google Kubernetes Engine clusters
-
-Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.
-
-The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).
-
-### Upgrading an Amazon EKS Cluster
-
-Amazon EKS cluster's master components can be upgraded by using eksctl, AWS Management Console, or AWS CLI. The process is user-initiated and is described in the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
-
-### Upgrading an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster
-
-Oracle creates and manages a set of master nodes in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these master nodes to new versions of Kubernetes with zero downtime. These actions are described in the [OKE documentation](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm). 
-
-### Upgrading clusters on other platforms
-
-Different providers, and tools, will manage upgrades differently.  It is recommended that you consult their main documentation regarding upgrades.
-
-* [kops](https://github.com/kubernetes/kops)
-* [kubespray](https://github.com/kubernetes-incubator/kubespray)
-* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
-* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
-* ...
-
-To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the
-[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
-
-## Resizing a cluster
-
-If your cluster runs short on resources you can easily add more machines to it if your cluster
-is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
-If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes.
-It can be accomplished by modifying number of instances on
-`Compute > Compute Engine > Instance groups > your group > Edit group`
-[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
-
-```shell
-gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
-```
-
-The Instance Group will take care of putting appropriate image on new machines and starting them,
-while the Kubelet will register its Node with the API server to make it available for scheduling.
-If you scale the instance group down, system will randomly choose Nodes to kill.
-
-In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.
-
-### Resizing an Azure Kubernetes Service (AKS) cluster
-
-Azure Kubernetes Service enables user-initiated resizing of the cluster from either the CLI or
-the Azure Portal and is described in the
-[Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).
-
-
-### Cluster autoscaling
-
-If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
-pod needs.
-
-As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/),
-users can reserve how much CPU and memory is allocated to pods.
-This information is used by the Kubernetes scheduler to find a place to run the pod. If there is
-no node that has enough free capacity (or doesn't match other pod requirements) then the pod has
-to wait until some pods are terminated or a new node is added.
-
-Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar
-to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods.
-
-Cluster autoscaler also scales down the cluster if it notices that one or more nodes are not needed anymore for
-an extended period of time (10min but it may change in the future).
-
-Cluster autoscaler is configured per instance group (GCE) or node pool (Google Kubernetes Engine).
-
-If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
-To configure cluster autoscaler you have to set three environment variables:
-
-* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true.
-* `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster.
-* `KUBE_AUTOSCALER_MAX_NODES` - maximum number of nodes in the cluster.
-
-Example:
-
-```shell
-KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
-```
-
-On Google Kubernetes Engine you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
-(which you want to be autoscaled) by passing flags `--enable-autoscaling` `--min-nodes` and `--max-nodes`
-to the corresponding `gcloud` commands.
-
-Examples:
-
-```shell
-gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
-```
-
-```shell
-gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
-```
-
-**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
-
-For more details about how the cluster autoscaler decides whether, when and how
-to scale a cluster, please refer to the [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
-documentation from the autoscaler project.
-
-## Maintenance on a Node
-
-If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is
-brief, then when the Kubelet restarts, it will attempt to restart the pods scheduled to it.  If the reboot takes longer
-(the default time is 5 minutes, controlled by `--pod-eviction-timeout` on the controller-manager),
-then the node controller will terminate the pods that are bound to the unavailable node.  If there is a corresponding
-replica set (or replication controller), then a new copy of the pod will be started on a different node.  So, in the case where all
-pods are replicated, upgrades can be done without special coordination, assuming that not all nodes will go down at the same time.
-
-If you want more control over the upgrading process, you may use the following workflow:
-
-Use `kubectl drain` to gracefully terminate all pods on the node while marking the node as unschedulable:
-
-```shell
-kubectl drain $NODENAME
-```
-
-This keeps new pods from landing on the node while you are trying to get them off.
-
-For pods with a replica set, the pod will be replaced by a new pod which will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
-
-For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
-
-Perform maintenance work on the node.
-
-Make the node schedulable again:
-
-```shell
-kubectl uncordon $NODENAME
-```
-
-If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
-be created automatically (if you're using a cloud provider that supports
-node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
-See [Node](/docs/concepts/architecture/nodes/) for more details.
-
-## Advanced Topics
-
-### Turn on or off an API version for your cluster
-
-Specific API versions can be turned on or off by passing `--runtime-config=api/<version>` flag while bringing up the API server. For example: to turn off v1 API, pass `--runtime-config=api/v1=false`.
-runtime-config also supports 2 special keys: api/all and api/legacy to control all and legacy APIs respectively.
-For example, for turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`.
-For the purposes of these flags, _legacy_ APIs are those APIs which have been explicitly deprecated (e.g. `v1beta3`).
-
-### Switching your cluster's storage API version
-
-The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
-When the supported API changes, these objects may need to be rewritten in the newer API.  Failure to do this will eventually result in resources that are no longer decodable or usable
-by the Kubernetes API server.
-
-### Switching your config files to a new API version
-
-You can use `kubectl convert` command to convert config files between different API versions.
-
-```shell
-kubectl convert -f pod.yaml --output-version v1
-```
-
-For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
-
-
diff --git a/content/en/docs/tasks/administer-cluster/cluster-upgrade.md b/content/en/docs/tasks/administer-cluster/cluster-upgrade.md
new file mode 100644
index 0000000000..1e2cc422e4
--- /dev/null
+++ b/content/en/docs/tasks/administer-cluster/cluster-upgrade.md
@@ -0,0 +1,93 @@
+---
+title: Upgrade A Cluster
+content_type: task
+---
+
+<!-- overview -->
+This page provides an overview of the steps you should follow to upgrade a
+Kubernetes cluster.
+
+The way that you upgrade a cluster depends on how you initially deployed it
+and on any subsequent changes.
+
+At a high level, the steps you perform are:
+
+- Upgrade the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+- Upgrade the nodes in your cluster
+- Upgrade clients such as {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
+- Adjust manifests and other resources based on the API changes that accompany the
+  new Kubernetes version
+
+## {{% heading "prerequisites" %}}
+
+You must have an existing cluster. This page is about upgrading from Kubernetes
+{{< skew prevMinorVersion >}} to Kubernetes {{< skew latestVersion >}}. If your cluster
+is not currently running Kubernetes {{< skew prevMinorVersion >}} then please check
+the documentation for the version of Kubernetes that you plan to upgrade to.
+
+## Upgrade approaches
+
+### kubeadm {#upgrade-kubeadm}
+
+If your cluster was deployed using the `kubeadm` tool, refer to 
+[Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+for detailed information on how to upgrade the cluster.
+
+Once you have upgraded the cluster, remember to
+[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
+
+### Manual deployments
+
+{{< caution >}}
+These steps do not account for third-party extensions such as network and storage
+plugins.
+{{< /caution >}}
+
+You should manually update the control plane following this sequence:
+
+- etcd (all instances)
+- kube-apiserver (all control plane hosts)
+- kube-controller-manager
+- kube-scheduler
+- cloud controller manager, if you use one
+
+At this point you should
+[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
+
+For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/)
+that node and then either replace it with a new node that uses the {{< skew latestVersion >}}
+kubelet, or upgrade the kubelet on that node and bring the node back into service.
+
+### Other deployments {#upgrade-other}
+
+Refer to the documentation for your cluster deployment tool to learn the recommended set
+up steps for maintenance.
+
+## Post-upgrade tasks
+
+### Switch your cluster's storage API version
+
+The objects that are serialized into etcd for a cluster's internal
+representation of the Kubernetes resources active in the cluster are
+written using a particular version of the API.
+
+When the supported API changes, these objects may need to be rewritten
+in the newer API. Failure to do this will eventually result in resources
+that are no longer decodable or usable by the Kubernetes API server.
+
+For each affected object, fetch it using the latest supported API and then
+write it back also using the latest supported API.
+
+### Update manifests
+
+Upgrading to a new Kubernetes version can provide new APIs.
+
+You can use `kubectl convert` command to convert manifests between different API versions.
+For example:
+
+```shell
+kubectl convert -f pod.yaml --output-version v1
+```
+
+The `kubectl` tool replaces the contents of `pod.yaml` with a manifest that sets `kind` to
+Pod (unchanged), but with a revised `apiVersion`.
diff --git a/content/en/docs/tasks/administer-cluster/declare-network-policy.md b/content/en/docs/tasks/administer-cluster/declare-network-policy.md
index 61add5312a..fed4a77f9d 100644
--- a/content/en/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/declare-network-policy.md
@@ -9,6 +9,7 @@ content_type: task
 <!-- overview -->
 This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
 
+{{% thirdparty-content %}}
 
 ## {{% heading "prerequisites" %}}
 
@@ -23,11 +24,6 @@ Make sure you've configured a network provider with network policy support. Ther
 * [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
 * [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
 
-{{< note >}}
-The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
-{{< /note >}}
-
-
 <!-- steps -->
 
 ## Create an `nginx` deployment and expose it via a service
diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
index e762258c88..8680abad43 100644
--- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
+++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -222,7 +222,7 @@ data:
           fallthrough in-addr.arpa ip6.arpa
         }
         prometheus :9153
-        proxy . /etc/resolv.conf
+        forward . /etc/resolv.conf
         cache 30
         loop
         reload
diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index f333b215a2..bdcb35ada2 100644
--- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -143,7 +143,7 @@ The idea is that when a cluster is using nodes that have many cores,
 cores, `nodesPerReplica` dominates.
 
 There are other supported scaling patterns. For details, see
-[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
+[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
 
 ## Disable DNS horizontal autoscaling
 
@@ -233,5 +233,5 @@ patterns: *linear* and *ladder*.
 
 * Read about [Guaranteed Scheduling For Critical Add-On Pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
 * Learn more about the
-[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
+[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
 
diff --git a/content/en/docs/tasks/administer-cluster/enable-disable-api.md b/content/en/docs/tasks/administer-cluster/enable-disable-api.md
new file mode 100644
index 0000000000..a10de2c3b4
--- /dev/null
+++ b/content/en/docs/tasks/administer-cluster/enable-disable-api.md
@@ -0,0 +1,29 @@
+---
+title: Enable Or Disable A Kubernetes API
+content_type: task
+---
+
+<!-- overview -->
+This page shows how to enable or disable an API version from your cluster's
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+
+<!-- steps -->
+
+
+Specific API versions can be turned on or off by passing `--runtime-config=api/<version>` as a
+command line argument to the API server. The values for this argument are a comma-separated
+list of API versions. Later values override earlier values.
+
+The `runtime-config` command line argument also supports 2 special keys:
+
+- `api/all`, representing all known APIs
+- `api/legacy`, representing only legacy APIs. Legacy APIs are any APIs that have been
+   explicitly [deprecated](/docs/reference/using-api/deprecation-policy/).
+
+For example, to turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`
+to the `kube-apiserver`.
+
+## {{% heading "whatsnext" %}}
+
+Read the [full documentation](/docs/reference/command-line-tools-reference/kube-apiserver/)
+for the `kube-apiserver` component.
diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
index 9c2e1d3d5d..2997508a15 100644
--- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
+++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
@@ -62,7 +62,7 @@ By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7
 To create an ip-masq-agent, run the following kubectl command:
 
 `
-kubectl apply -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/ip-masq-agent/master/ip-masq-agent.yaml
 `
 
 You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
@@ -71,7 +71,7 @@ You must also apply the appropriate node label to any nodes in your cluster that
 kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
 `
 
-More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)
+More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-sigs/ip-masq-agent)
 
 In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to customize the IP ranges that are affected.  For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) in a file called "config".
 
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index c3498fce61..ed498b1319 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
 ### Joining a Windows worker node
 {{< note >}}
 You must install the `Containers` feature and install Docker. Instructions
-to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows).
 {{< /note >}}
 
 {{< note >}}
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
index 02687a85f2..abd072b5a3 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@@ -10,7 +10,7 @@ weight: 10
 
 {{< feature-state for_k8s_version="v1.15" state="stable" >}}
 
-Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
+Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
 
 ## {{% heading "prerequisites" %}}
 
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index 83989b1f58..948893d3ea 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -72,7 +72,7 @@ policies using an example application.
 ## Deploying Cilium for Production Use
 
 For detailed instructions around deploying Cilium for production, see:
-[Cilium Kubernetes Installation Guide](https://docs.cilium.io/en/stable/kubernetes/intro/)
+[Cilium Kubernetes Installation Guide](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)
 This documentation includes detailed requirements, instructions and example
 production DaemonSet files.
 
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
index 93312e199e..6a57d8cc0b 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -12,7 +12,7 @@ This page shows how to use Romana for NetworkPolicy.
 
 ## {{% heading "prerequisites" %}}
 
-Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
+Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/).
 
 <!-- steps -->
 
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
index b6b562620a..fcbc9c4045 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -13,16 +13,16 @@ This page shows how to use Weave Net for NetworkPolicy.
 ## {{% heading "prerequisites" %}}
 
 You need to have a Kubernetes cluster. Follow the
-[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/kubeadm/) to bootstrap one.
+[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/) to bootstrap one.
 
 <!-- steps -->
 
 ## Install the Weave Net addon
 
-Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.
+Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) guide.
 
 The Weave Net addon for Kubernetes comes with a
-[Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc)
+[Network Policy Controller](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)
 that automatically monitors Kubernetes for any NetworkPolicy annotations on all
 namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
 
diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md
index 10ef986b8c..908d7155d5 100644
--- a/content/en/docs/tasks/administer-cluster/out-of-resource.md
+++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md
@@ -18,28 +18,19 @@ nodes become unstable.
 
 <!-- body -->
 
-## Eviction Policy
-
-The `kubelet` can proactively monitor for and prevent total starvation of a
-compute resource. In those cases, the `kubelet` can reclaim the starved
-resource by proactively failing one or more Pods. When the `kubelet` fails
-a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
-If the evicted Pod is managed by a Deployment, the Deployment will create another Pod 
-to be scheduled by Kubernetes.
-
 ### Eviction Signals
 
 The `kubelet` supports eviction decisions based on the signals described in the following
 table. The value of each signal is described in the Description column, which is based on
 the `kubelet` summary API.
 
-| Eviction Signal  | Description                                                                     |
-|----------------------------|-----------------------------------------------------------------------|
-| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
-| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
-| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
-| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
-| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
+| Eviction Signal      | Description                                                                           |
+|----------------------|---------------------------------------------------------------------------------------|
+| `memory.available`   | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
+| `nodefs.available`   | `nodefs.available` := `node.stats.fs.available`                                       |
+| `nodefs.inodesFree`  | `nodefs.inodesFree` := `node.stats.fs.inodesFree`                                     |
+| `imagefs.available`  | `imagefs.available` := `node.stats.runtime.imagefs.available`                         |
+| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree`                       |
 
 Each of the above signals supports either a literal or percentage based value.
 The percentage based value is calculated relative to the total capacity
@@ -50,7 +41,7 @@ like `free -m`. This is important because `free -m` does not work in a
 container, and if users use the [node
 allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
 are made local to the end user Pod part of the cgroup hierarchy as well as the
-root node. This [script](/docs/tasks/administer-cluster/memory-available.sh)
+root node. This [script](/examples/admin/resource/memory-available.sh)
 reproduces the same set of steps that the `kubelet` performs to calculate
 `memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
 file-backed memory on inactive LRU list) from its calculation as it assumes that
@@ -65,7 +56,7 @@ memory is reclaimable under pressure.
 `imagefs` is optional. `kubelet` auto-discovers these filesystems using
 cAdvisor. `kubelet` does not care about any other filesystems. Any other types
 of configurations are not currently supported by the kubelet. For example, it is
-*not OK* to store volumes and logs in a dedicated `filesystem`.
+_not OK_ to store volumes and logs in a dedicated `filesystem`.
 
 In future releases, the `kubelet` will deprecate the existing [garbage
 collection](/docs/concepts/cluster-administration/kubelet-garbage-collection/)
@@ -83,9 +74,7 @@ where:
 
 * `eviction-signal` is an eviction signal token as defined in the previous table.
 * `operator` is the desired relational operator, such as `<` (less than).
-* `quantity` is the eviction threshold quantity, such as `1Gi`. These tokens must
-match the quantity representation used by Kubernetes. An eviction threshold can also
-be expressed as a percentage using the `%` token.
+* `quantity` is the eviction threshold quantity, such as `1Gi`. These tokens must match the quantity representation used by Kubernetes. An eviction threshold can also be expressed as a percentage using the `%` token.
 
 For example, if a node has `10Gi` of total memory and you want trigger eviction if
 the available memory falls below `1Gi`, you can define the eviction threshold as
@@ -108,12 +97,9 @@ termination.
 
 To configure soft eviction thresholds, the following flags are supported:
 
-* `eviction-soft` describes a set of eviction thresholds (e.g. `memory.available<1.5Gi`) that if met over a
-corresponding grace period would trigger a Pod eviction.
-* `eviction-soft-grace-period` describes a set of eviction grace periods (e.g. `memory.available=1m30s`) that
-correspond to how long a soft eviction threshold must hold before triggering a Pod eviction.
-* `eviction-max-pod-grace-period` describes the maximum allowed grace period (in seconds) to use when terminating
-pods in response to a soft eviction threshold being met.
+* `eviction-soft` describes a set of eviction thresholds (e.g. `memory.available<1.5Gi`) that if met over a corresponding grace period would trigger a Pod eviction.
+* `eviction-soft-grace-period` describes a set of eviction grace periods (e.g. `memory.available=1m30s`) that correspond to how long a soft eviction threshold must hold before triggering a Pod eviction.
+* `eviction-max-pod-grace-period` describes the maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met.
 
 #### Hard Eviction Thresholds
 
@@ -124,8 +110,7 @@ with no graceful termination.
 
 To configure hard eviction thresholds, the following flag is supported:
 
-* `eviction-hard` describes a set of eviction thresholds (e.g. `memory.available<1Gi`) that if met
-would trigger a Pod eviction.
+* `eviction-hard` describes a set of eviction thresholds (e.g. `memory.available<1Gi`) that if met would trigger a Pod eviction.
 
 The `kubelet` has the following default hard eviction threshold:
 
@@ -150,10 +135,10 @@ reflects the node is under pressure.
 
 The following node conditions are defined that correspond to the specified eviction signal.
 
-| Node Condition | Eviction Signal  | Description                                                      |
-|-------------------------|-------------------------------|--------------------------------------------|
-| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold |
-| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold |
+| Node Condition    | Eviction Signal                                                                       | Description                                                                                                                  |
+|-------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|
+| `MemoryPressure`  | `memory.available`                                                                    | Available memory on the node has satisfied an eviction threshold                                                             |
+| `DiskPressure`    | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold |
 
 The `kubelet` continues to report node status updates at the frequency specified by
 `--node-status-update-frequency` which defaults to `10s`.
@@ -168,8 +153,7 @@ as a consequence.
 To protect against this oscillation, the following flag is defined to control how
 long the `kubelet` must wait before transitioning out of a pressure condition.
 
-* `eviction-pressure-transition-period` is the duration for which the `kubelet` has
-to wait before transitioning out of an eviction pressure condition.
+* `eviction-pressure-transition-period` is the duration for which the `kubelet` has to wait before transitioning out of an eviction pressure condition.
 
 The `kubelet` would ensure that it has not observed an eviction threshold being met
 for the specified pressure condition for the period specified before toggling the
@@ -207,17 +191,8 @@ then by [Priority](/docs/concepts/configuration/pod-priority-preemption/), and t
 
 As a result, `kubelet` ranks and evicts Pods in the following order:
 
-* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
-Such pods are ranked by Priority, and then usage above request.
-* `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last.
-`Guaranteed` Pods are guaranteed only when requests and limits are specified for all
-the containers and they are equal. Such pods are guaranteed to never be evicted because
-of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`,
-and `journald`) is consuming more resources than were reserved via `system-reserved` or
-`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using
-less than requests remaining, then the node must choose to evict such a Pod in order to
-preserve node stability and to limit the impact of the unexpected consumption to other Pods.
-In this case, it will choose to evict pods of Lowest Priority first.
+* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request. Such pods are ranked by Priority, and then usage above request.
+* `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last. `Guaranteed` Pods are guaranteed only when requests and limits are specified for all the containers and they are equal. Such pods are guaranteed to never be evicted because of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`, and `journald`) is consuming more resources than were reserved via `system-reserved` or `kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using less than requests remaining, then the node must choose to evict such a Pod in order to preserve node stability and to limit the impact of the unexpected consumption to other Pods. In this case, it will choose to evict pods of Lowest Priority first.
 
 If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
 is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
@@ -228,6 +203,7 @@ that consumes the largest amount of disk and kills those first.
 #### With `imagefs`
 
 If `nodefs` is triggering evictions, `kubelet` sorts Pods based on the usage on `nodefs`
+
 - local volumes + logs of all its containers.
 
 If `imagefs` is triggering evictions, `kubelet` sorts Pods based on the writable layer usage of all its containers.
@@ -235,13 +211,13 @@ If `imagefs` is triggering evictions, `kubelet` sorts Pods based on the writable
 #### Without `imagefs`
 
 If `nodefs` is triggering evictions, `kubelet` sorts Pods based on their total disk usage
+
 - local volumes + logs & writable layer of all its containers.
 
 ### Minimum eviction reclaim
 
 In certain scenarios, eviction of Pods could result in reclamation of small amount of resources. This can result in
-`kubelet` hitting eviction thresholds in repeated successions. In addition to that, eviction of resources like `disk`,
- is time consuming.
+`kubelet` hitting eviction thresholds in repeated successions. In addition to that, eviction of resources like `disk`, is time consuming.
 
 To mitigate these issues, `kubelet` can have a per-resource `minimum-reclaim`. Whenever `kubelet` observes
 resource pressure, `kubelet` attempts to reclaim at least `minimum-reclaim` amount of resource below
@@ -268,10 +244,10 @@ The node reports a condition when a compute resource is under pressure. The
 scheduler views that condition as a signal to dissuade placing additional
 pods on the node.
 
-| Node Condition    | Scheduler Behavior                               |
-| ---------------- | ------------------------------------------------ |
-| `MemoryPressure` | No new `BestEffort` Pods are scheduled to the node. |
-| `DiskPressure` | No new Pods are scheduled to the node. |
+| Node Condition    | Scheduler Behavior                                  |
+| ------------------| ----------------------------------------------------|
+| `MemoryPressure`  | No new `BestEffort` Pods are scheduled to the node. |
+| `DiskPressure`    | No new Pods are scheduled to the node.              |
 
 ## Node OOM Behavior
 
@@ -280,11 +256,11 @@ the node depends on the [oom_killer](https://lwn.net/Articles/391222/) to respon
 
 The `kubelet` sets a `oom_score_adj` value for each container based on the quality of service for the Pod.
 
-| Quality of Service | oom_score_adj |
-|----------------------------|-----------------------------------------------------------------------|
-| `Guaranteed` | -998 |
-| `BestEffort` | 1000 |
-| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
+| Quality of Service | oom_score_adj                                                                     |
+|--------------------|-----------------------------------------------------------------------------------|
+| `Guaranteed`       | -998                                                                              |
+| `BestEffort`       | 1000                                                                              |
+| `Burstable`        | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
 
 If the `kubelet` is unable to reclaim memory prior to a node experiencing system OOM, the `oom_killer` calculates
 an `oom_score` based on the percentage of memory it's using on the node, and then add the `oom_score_adj` to get an
@@ -325,10 +301,7 @@ and trigger eviction assuming those Pods use less than their configured request.
 
 ### DaemonSet
 
-As `Priority` is a key factor in the eviction strategy, if you do not want 
-pods belonging to a `DaemonSet` to be evicted, specify a sufficiently high priorityClass 
-in the pod spec template. If you want pods belonging to a `DaemonSet` to run only if 
-there are sufficient resources, specify a lower or default priorityClass.
+As `Priority` is a key factor in the eviction strategy, if you do not want pods belonging to a `DaemonSet` to be evicted, specify a sufficiently high priorityClass in the pod spec template. If you want pods belonging to a `DaemonSet` to run only if there are sufficient resources, specify a lower or default priorityClass.
 
 
 ## Deprecation of existing feature flags to reclaim disk
@@ -338,15 +311,15 @@ there are sufficient resources, specify a lower or default priorityClass.
 As disk based eviction matures, the following `kubelet` flags are marked for deprecation
 in favor of the simpler configuration supported around eviction.
 
-| Existing Flag | New Flag |
-| ------------- | -------- |
-| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` |
-| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` |
-| `--maximum-dead-containers` | deprecated |
-| `--maximum-dead-containers-per-container` | deprecated |
-| `--minimum-container-ttl-duration` | deprecated |
-| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` |
-| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` |
+| Existing Flag                              | New Flag                                |
+| ------------------------------------------ | ----------------------------------------|
+| `--image-gc-high-threshold`                | `--eviction-hard` or `eviction-soft`    |
+| `--image-gc-low-threshold`                 | `--eviction-minimum-reclaim`            |
+| `--maximum-dead-containers`                | deprecated                              |
+| `--maximum-dead-containers-per-container`  | deprecated                              |
+| `--minimum-container-ttl-duration`         | deprecated                              |
+| `--low-diskspace-threshold-mb`             | `--eviction-hard` or `eviction-soft`    |
+| `--outofdisk-transition-frequency`         | `--eviction-pressure-transition-period` |
 
 ## Known issues
 
@@ -368,4 +341,11 @@ to prevent system OOMs, and promote eviction of workloads so cluster state can r
 The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding
 the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future.
 
+### active_file memory is not considered as available memory
+
+On Linux, the kernel tracks the number of bytes of file-backed memory on active LRU list as the `active_file` statistic. The kubelet treats `active_file` memory areas as not reclaimable. For workloads that make intensive use of block-backed local storage, including ephemeral local storage, kernel-level caches of file and block data means that many recently accessed cache pages are likely to be counted as `active_file`. If enough of these kernel block buffers are on the active LRU list, the kubelet is liable to observe this as high resource use and taint the node as experiencing memory pressure - triggering Pod eviction.
+
+For more more details, see [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)
+
+You can work around that behavior by setting the memory limit and memory request the same for containers likely to perform intensive I/O activity. You will need to estimate or measure an optimal memory limit value for that container.
 
diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
index 4f00675c37..b6249f50ef 100644
--- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -39,22 +39,7 @@ the kubelet command line option `--reserved-cpus` to set an
 
 ## Node Allocatable
 
-```text
-      Node Capacity
----------------------------
-|     kube-reserved       |
-|-------------------------|
-|     system-reserved     |
-|-------------------------|
-|    eviction-threshold   |
-|-------------------------|
-|                         |
-|      allocatable        |
-|   (available for pods)  |
-|                         |
-|                         |
----------------------------
-```
+![node capacity](/images/docs/node-capacity.svg)
 
 `Allocatable` on a Kubernetes node is defined as the amount of compute resources
 that are available for pods. The scheduler does not over-subscribe
diff --git a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
index aa01c902e4..b1a7e56548 100644
--- a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -11,7 +11,7 @@ content_type: concept
 
 {{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
-Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the {{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}} binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}` binary allows cloud vendors to evolve independently from the core Kubernetes code.
 
 The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.
 
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index ed1b9657c8..db31cceb8b 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -4,41 +4,48 @@ reviewers:
 - mml
 - foxish
 - kow3ns
-title: Safely Drain a Node while Respecting the PodDisruptionBudget
+title: Safely Drain a Node
 content_type: task
+min-kubernetes-server-version: 1.5
 ---
 
 <!-- overview -->
-This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined.
-
+This page shows how to safely drain a {{< glossary_tooltip text="node" term_id="node" >}},
+optionally respecting the PodDisruptionBudget you have defined.
 
 ## {{% heading "prerequisites" %}}
 
-
-This task assumes that you have met the following prerequisites:
-
-* You are using Kubernetes release >= 1.5.
-* Either:
+{{% version-check %}}
+This task also assumes that you have met the following prerequisites:
   1. You do not require your applications to be highly available during the
      node drain, or
-  1. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/)
-     and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
+  1. You have read about the [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) concept,
+     and have [configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
      applications that need them.
 
 
 
 <!-- steps -->
 
+## (Optional) Configure a disruption budget {#configure-poddisruptionbudget}
+
+To endure that your workloads remain available during maintenance, you can
+configure a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/).
+
+If availability is important for any applications that run or could run on the node(s)
+that you are draining, [configure a PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
+first and the continue following this guide.
+
 ## Use `kubectl drain` to remove a node from service
 
 You can use `kubectl drain` to safely evict all of your pods from a
 node before you perform maintenance on the node (e.g. kernel upgrade,
 hardware maintenance, etc.). Safe evictions allow the pod's containers
 to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
-and will respect the `PodDisruptionBudgets` you have specified.
+and will respect the PodDisruptionBudgets you have specified.
 
 {{< note >}}
-By default `kubectl drain` will ignore certain system pods on the node
+By default `kubectl drain` ignores certain system pods on the node
 that cannot be killed; see
 the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
 documentation for more details.
@@ -78,29 +85,29 @@ The `kubectl drain` command should only be issued to a single node at a
 time. However, you can run multiple `kubectl drain` commands for
 different nodes in parallel, in different terminals or in the
 background. Multiple drain commands running concurrently will still
-respect the `PodDisruptionBudget` you specify.
+respect the PodDisruptionBudget you specify.
 
 For example, if you have a StatefulSet with three replicas and have
-set a `PodDisruptionBudget` for that set specifying `minAvailable:
-2`. `kubectl drain` will only evict a pod from the StatefulSet if all
-three pods are ready, and if you issue multiple drain commands in
-parallel, Kubernetes will respect the PodDisruptionBudget and ensure
-that only one pod is unavailable at any given time. Any drains that
-would cause the number of ready replicas to fall below the specified
-budget are blocked.
+set a PodDisruptionBudget for that set specifying `minAvailable: 2`,
+`kubectl drain` only evicts a pod from the StatefulSet if all three
+replicas pods are ready; if then you issue multiple drain commands in
+parallel, Kubernetes respects the PodDisruptionBudget and ensure
+that only 1 (calculated as `replicas - minAvailable`) Pod is unavailable
+at any given time. Any drains that would cause the number of ready
+replicas to fall below the specified budget are blocked.
 
-## The Eviction API
+## The Eviction API {#eviction-api}
 
 If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as
 to avoid calling to an external command, or to get finer control over the pod
 eviction process), you can also programmatically cause evictions using the eviction API.
 
-You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api).
+You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) to access the API.
 
 The eviction subresource of a
-pod can be thought of as a kind of policy-controlled DELETE operation on the pod
-itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
-*create* an eviction), you POST an attempted operation. Here's an example:
+Pod can be thought of as a kind of policy-controlled DELETE operation on the Pod
+itself. To attempt an eviction (more precisely: to attempt to
+*create* an Eviction), you POST an attempted operation. Here's an example:
 
 ```json
 {
@@ -116,21 +123,19 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
 You can attempt an eviction using `curl`:
 
 ```bash
-curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
+curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
 ```
 
 The API can respond in one of three ways:
 
-- If the eviction is granted, then the pod is deleted just as if you had sent
-  a `DELETE` request to the pod's URL and you get back `200 OK`.
+- If the eviction is granted, then the Pod is deleted just as if you had sent
+  a `DELETE` request to the Pod's URL and you get back `200 OK`.
 - If the current state of affairs wouldn't allow an eviction by the rules set
   forth in the budget, you get back `429 Too Many Requests`. This is
   typically used for generic rate limiting of *any* requests, but here we mean
   that this request isn't allowed *right now* but it may be allowed later.
-  Currently, callers do not get any `Retry-After` advice, but they may in
-  future versions.
-- If there is some kind of misconfiguration, like multiple budgets pointing at
-  the same pod, you will get `500 Internal Server Error`.
+- If there is some kind of misconfiguration; for example multiple PodDisruptionBudgets
+  that refer the same Pod, you get a `500 Internal Server Error` response.
 
 For a given eviction request, there are two cases:
 
@@ -139,27 +144,27 @@ For a given eviction request, there are two cases:
 - There is at least one budget. In this case, any of the three above responses may
  apply.
 
-In some cases, an application may reach a broken state where it will never return anything
-other than 429 or 500. This can happen, for example, if the replacement pod created by the
-application's controller does not become ready, or if the last pod evicted has a very long
-termination grace period.
+## Stuck evictions
+
+In some cases, an application may reach a broken state, one where unless you intervene the
+eviction API will never return anything other than 429 or 500.
+
+For example: this can happen if ReplicaSet is creating Pods for your application but
+the replacement Pods do not become `Ready`. You can also see similar symptoms if the
+last Pod evicted has a very long termination grace period.
 
 In this case, there are two potential solutions:
 
-- Abort or pause the automated operation. Investigate the reason for the stuck application, and restart the automation.
-- After a suitably long wait, `DELETE` the pod instead of using the eviction API.
+- Abort or pause the automated operation. Investigate the reason for the stuck application,
+  and restart the automation.
+- After a suitably long wait, `DELETE` the Pod from your cluster's control plane, instead
+  of using the eviction API.
 
 Kubernetes does not specify what the behavior should be in this case; it is up to the
 application owners and cluster owners to establish an agreement on behavior in these cases.
 
-
-
 ## {{% heading "whatsnext" %}}
 
 
 * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
-* Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
-
-
-
 
diff --git a/content/en/docs/tasks/configmap-secret/_index.md b/content/en/docs/tasks/configmap-secret/_index.md
new file mode 100755
index 0000000000..d80692c967
--- /dev/null
+++ b/content/en/docs/tasks/configmap-secret/_index.md
@@ -0,0 +1,6 @@
+---
+title: "Managing Secrets"
+weight: 28
+description: Managing confidential settings data using Secrets.
+---
+
diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
new file mode 100644
index 0000000000..8ed9730415
--- /dev/null
+++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
@@ -0,0 +1,198 @@
+---
+title: Managing Secret using Configuration File
+content_type: task
+weight: 20
+description: Creating Secret objects using resource configuration file.
+---
+
+<!-- overview -->
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+## Create the Config file
+
+You can create a Secret in a file first, in JSON or YAML format, and then
+create that object.  The
+[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+resource contains two maps: `data` and `stringData`.
+The `data` field is used to store arbitrary data, encoded using base64. The
+`stringData` field is provided for convenience, and it allows you to provide
+Secret data as unencoded strings.
+The keys of `data` and `stringData` must consist of alphanumeric characters,
+`-`, `_` or `.`.
+
+For example, to store two strings in a Secret using the `data` field, convert
+the strings to base64 as follows:
+
+```shell
+echo -n 'admin' | base64
+```
+
+The output is similar to:
+
+```
+YWRtaW4=
+```
+
+```shell
+echo -n '1f2d1e2e67df' | base64
+```
+
+The output is similar to:
+
+```
+MWYyZDFlMmU2N2Rm
+```
+
+Write a Secret config file that looks like this:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret
+type: Opaque
+data:
+  username: YWRtaW4=
+  password: MWYyZDFlMmU2N2Rm
+```
+
+Note that the name of a Secret object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+{{< note >}}
+The serialized JSON and YAML values of Secret data are encoded as base64
+strings. Newlines are not valid within these strings and must be omitted. When
+using the `base64` utility on Darwin/macOS, users should avoid using the `-b`
+option to split long lines. Conversely, Linux users *should* add the option
+`-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if the `-w`
+option is not available.
+{{< /note >}}
+
+For certain scenarios, you may wish to use the `stringData` field instead. This
+field allows you to put a non-base64 encoded string directly into the Secret,
+and the string will be encoded for you when the Secret is created or updated.
+
+A practical example of this might be where you are deploying an application
+that uses a Secret to store a configuration file, and you want to populate
+parts of that configuration file during your deployment process.
+
+For example, if your application uses the following configuration file:
+
+```yaml
+apiUrl: "https://my.api.com/api/v1"
+username: "<user>"
+password: "<password>"
+```
+
+You could store this in a Secret using the following definition:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret
+type: Opaque
+stringData:
+  config.yaml: |
+    apiUrl: "https://my.api.com/api/v1"
+    username: <user>
+    password: <password>
+```
+
+## Create the Secret object
+
+Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply):
+
+```shell
+kubectl apply -f ./secret.yaml
+```
+
+The output is similar to:
+
+```
+secret/mysecret created
+```
+
+## Check the Secret
+
+The `stringData` field is a write-only convenience field. It is never output when
+retrieving Secrets. For example, if you run the following command:
+
+```shell
+kubectl get secret mysecret -o yaml
+```
+
+The output is similar to:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  creationTimestamp: 2018-11-15T20:40:59Z
+  name: mysecret
+  namespace: default
+  resourceVersion: "7225"
+  uid: c280ad2e-e916-11e8-98f2-025000000001
+type: Opaque
+data:
+  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
+```
+
+The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
+default. This is to protect the `Secret` from being exposed accidentally to an onlooker,
+or from being stored in a terminal log.
+To check the actual content of the encoded data, please refer to
+[decoding secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret).
+
+If a field, such as `username`, is specified in both `data` and `stringData`,
+the value from `stringData` is used. For example, the following Secret definition:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret
+type: Opaque
+data:
+  username: YWRtaW4=
+stringData:
+  username: administrator
+```
+
+Results in the following Secret:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  creationTimestamp: 2018-11-15T20:46:46Z
+  name: mysecret
+  namespace: default
+  resourceVersion: "7579"
+  uid: 91460ecb-e917-11e8-98f2-025000000001
+type: Opaque
+data:
+  username: YWRtaW5pc3RyYXRvcg==
+```
+
+Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
+
+## Clean Up
+
+To delete the Secret you have just created:
+
+```shell
+kubectl delete secret db-user-pass
+```
+
+## {{% heading "whatsnext" %}}
+
+- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
+- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+
diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
new file mode 100644
index 0000000000..f370e24281
--- /dev/null
+++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
@@ -0,0 +1,157 @@
+---
+title: Managing Secret using kubectl
+content_type: task
+weight: 10
+description: Creating Secret objects using kubectl command line.
+---
+
+<!-- overview -->
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+## Create a Secret
+
+A `Secret` can contain user credentials required by Pods to access a database.
+For example, a database connection string consists of a username and password.
+You can store the username in a file `./username.txt` and the password in a
+file `./password.txt` on your local machine.
+
+```shell
+echo -n 'admin' > ./username.txt
+echo -n '1f2d1e2e67df' > ./password.txt
+```
+
+The `-n` flag in the above two commands ensures that the generated files will
+not contain an extra newline character at the end of the text. This is
+important because when `kubectl` reads a file and encode the content into
+base64 string, the extra newline character gets encoded too.
+
+The `kubectl create secret` command packages these files into a Secret and creates
+the object on the API server.
+
+```shell
+kubectl create secret generic db-user-pass \
+  --from-file=./username.txt \
+  --from-file=./password.txt
+```
+
+The output is similar to:
+
+```
+secret/db-user-pass created
+```
+
+Default key name is the filename. You may optionally set the key name using
+`--from-file=[key=]source`. For example:
+
+```shell
+kubectl create secret generic db-user-pass \
+  --from-file=username=./username.txt \
+  --from-file=password=./password.txt
+```
+
+You do not need to escape special characters in passwords from files
+(`--from-file`).
+
+You can also provide Secret data using the `--from-literal=<key>=<value>` tag.
+This tag can be specified more than once to provide multiple key-value pairs.
+Note that special characters such as `$`, `\`, `*`, `=`, and `!` will be
+interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing))
+and require escaping.
+In most shells, the easiest way to escape the password is to surround it with
+single quotes (`'`).  For example, if your actual password is `S!B\*d$zDsb=`,
+you should execute the command this way:
+
+```shell
+kubectl create secret generic dev-db-secret \
+  --from-literal=username=devuser \
+  --from-literal=password='S!B\*d$zDsb='
+```
+
+## Verify the Secret
+
+You can check that the secret was created:
+
+```shell
+kubectl get secrets
+```
+
+The output is similar to:
+
+```
+NAME                  TYPE                                  DATA      AGE
+db-user-pass          Opaque                                2         51s
+```
+
+You can view a description of the `Secret`:
+
+```shell
+kubectl describe secrets/db-user-pass
+```
+
+The output is similar to:
+
+```
+Name:            db-user-pass
+Namespace:       default
+Labels:          <none>
+Annotations:     <none>
+
+Type:            Opaque
+
+Data
+====
+password.txt:    12 bytes
+username.txt:    5 bytes
+```
+
+The commands `kubectl get` and `kubectl describe` avoid showing the contents
+of a `Secret` by default. This is to protect the `Secret` from being exposed
+accidentally to an onlooker, or from being stored in a terminal log.
+
+## Decoding the Secret  {#decoding-secret}
+
+To view the contents of the Secret we just created, you can run the following
+command:
+
+```shell
+kubectl get secret db-user-pass -o jsonpath='{.data}'
+```
+
+The output is similar to:
+
+```json
+{"password.txt":"MWYyZDFlMmU2N2Rm","username.txt":"YWRtaW4="}
+```
+
+Now you can decode the `password.txt` data:
+
+```shell
+echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
+```
+
+The output is similar to:
+
+```
+1f2d1e2e67df
+```
+
+## Clean Up
+
+To delete the Secret you have just created:
+
+```shell
+kubectl delete secret db-user-pass
+```
+
+<!-- discussion -->
+
+## {{% heading "whatsnext" %}}
+
+- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
+- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md
new file mode 100644
index 0000000000..d7b1f48a4a
--- /dev/null
+++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md
@@ -0,0 +1,128 @@
+---
+title: Managing Secret using Kustomize
+content_type: task
+weight: 30
+description: Creating Secret objects using kustomization.yaml file.
+---
+
+<!-- overview -->
+
+Since Kubernetes v1.14, `kubectl` supports
+[managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/).
+Kustomize provides resource Generators to create Secrets and ConfigMaps. The
+Kustomize generators should be specified in a `kustomization.yaml` file inside
+a directory. After generating the Secret, you can create the Secret on the API
+server with `kubectl apply`.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+## Create the Kustomization file
+
+You can generate a Secret by defining a `secretGenerator` in a
+`kustomization.yaml` file that references other existing files.
+For example, the following kustomization file references the
+`./username.txt` and the `./password.txt` files:
+
+```yaml
+secretGenerator:
+- name: db-user-pass
+  files:
+  - username.txt
+  - password.txt
+```
+
+You can also define the `secretGenerator` in the `kustomization.yaml`
+file by providing some literals.
+For example, the following `kustomization.yaml` file contains two literals
+for `username` and `password` respectively:
+
+```yaml
+secretGenerator:
+- name: db-user-pass
+  literals:
+  - username=admin
+  - password=1f2d1e2e67df
+```
+
+Note that in both cases, you don't need to base64 encode the values.
+
+## Create the Secret
+
+Apply the directory containing the `kustomization.yaml` to create the Secret.
+
+```shell
+kubectl apply -k .
+```
+
+The output is similar to:
+
+```
+secret/db-user-pass-96mffmfh4k created
+```
+
+Note that when a Secret is generated, the Secret name is created by hashing
+the Secret data and appending the hash value to the name. This ensures that
+a new Secret is generated each time the data is modified.
+
+## Check the Secret created
+
+You can check that the secret was created:
+
+```shell
+kubectl get secrets
+```
+
+The output is similar to:
+
+```
+NAME                             TYPE                                  DATA      AGE
+db-user-pass-96mffmfh4k          Opaque                                2         51s
+```
+
+You can view a description of the secret:
+
+```shell
+kubectl describe secrets/db-user-pass-96mffmfh4k
+```
+
+The output is similar to:
+
+```
+Name:            db-user-pass
+Namespace:       default
+Labels:          <none>
+Annotations:     <none>
+
+Type:            Opaque
+
+Data
+====
+password.txt:    12 bytes
+username.txt:    5 bytes
+```
+
+The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
+default. This is to protect the `Secret` from being exposed accidentally to an onlooker,
+or from being stored in a terminal log.
+To check the actual content of the encoded data, please refer to
+[decoding secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret).
+
+## Clean Up
+
+To delete the Secret you have just created:
+
+```shell
+kubectl delete secret db-user-pass-96mffmfh4k
+```
+
+<!-- Optional section; add links to information related to this topic. -->
+## {{% heading "whatsnext" %}}
+
+- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
+- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+
diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 3afda46609..243072eff2 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -22,7 +22,7 @@ allocated as much CPU as it requests.
 Your cluster must have at least 1 CPU available for use to run the task examples.
 
 A few of the steps on this page require you to run the
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
 service in your cluster. If you have the metrics-server
 running, you can skip those steps.
 
@@ -222,6 +222,13 @@ Container is automatically assigned the default limit. Cluster administrators ca
 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
 to specify a default value for the CPU limit.
 
+## If you specify a CPU limit but do not specify a CPU request
+
+If you specify a CPU limit for a Container but do not specify a CPU request, Kubernetes automatically
+assigns a CPU request that matches the limit. Similarly, if a Container specifies its own memory limit,
+but does not specify a memory request, Kubernetes automatically assigns a memory request that matches
+the limit.
+
 ## Motivation for CPU requests and limits
 
 By configuring the CPU requests and limits of the Containers that run in your
diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
index 79bc2b86b6..7afb3cb249 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -21,7 +21,7 @@ but is not allowed to use more memory than its limit.
 Each node in your cluster must have at least 300 MiB of memory.
 
 A few of the steps on this page require you to run the
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
 service in your cluster. If you have the metrics-server
 running, you can skip those steps.
 
diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index e72c86255a..75d6b1e3cf 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -330,8 +330,8 @@ seconds. Minimum value is 1.
 * `timeoutSeconds`: Number of seconds after which the probe times out. Defaults
 to 1 second. Minimum value is 1.
 * `successThreshold`: Minimum consecutive successes for the probe to be
-considered successful after having failed. Defaults to 1. Must be 1 for
-liveness. Minimum value is 1.
+considered successful after having failed. Defaults to 1. Must be 1 for liveness
+and startup Probes. Minimum value is 1.
 * `failureThreshold`: When a probe fails, Kubernetes will
 try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
 Defaults to 3. Minimum value is 1.
diff --git a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
index 2644dfd3cb..a53d278223 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
@@ -29,7 +29,7 @@ PersistentVolume.
 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
 command-line tool must be configured to communicate with your cluster. If you
 do not already have a single-node cluster, you can create one by using
-[Minikube](/docs/setup/learning-environment/minikube/).
+[Minikube](https://minikube.sigs.k8s.io/docs/).
 
 * Familiarize yourself with the material in
 [Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
index 42eff59db0..2824cce642 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
@@ -532,7 +532,7 @@ This functionality is available in Kubernetes v1.6 and later.
 
 ## Use ConfigMap-defined environment variables in Pod commands
 
-You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax.
+You can use ConfigMap-defined environment variables in the `command` and `args` of a container using the `$(VAR_NAME)` Kubernetes substitution syntax.
 
 For example, the following Pod specification
 
diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
index 9a8a33f655..cca96f2b79 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md
@@ -37,7 +37,7 @@ shared Volume at `/work-dir`, and the application container mounts the shared
 Volume at `/usr/share/nginx/html`. The init container runs the following command
 and then terminates:
 
-    wget -O /work-dir/index.html http://kubernetes.io
+    wget -O /work-dir/index.html http://info.cern.ch
 
 Notice that the init container writes the `index.html` file in the root directory
 of the nginx server.
@@ -67,16 +67,13 @@ In your shell, send a GET request to the nginx server:
 
 The output shows that nginx is serving the web page that was written by the init container:
 
-    <!Doctype html>
-    <html id="home">
+    <html><head></head><body><header>
+    <title>http://info.cern.ch</title>
+    </header>
 
-    <head>
-    ...
-    "url": "http://kubernetes.io/"}</script>
-    </head>
-    <body>
+    <h1>http://info.cern.ch - home of the first website</h1>
       ...
-      <p>Kubernetes is open source giving you the freedom to take advantage ...</p>
+      <li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
       ...
 
 
diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
index ce39aa01a5..0e6a02af37 100644
--- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -45,8 +45,8 @@ kubectl create namespace qos-example
 
 For a Pod to be given a QoS class of Guaranteed:
 
-* Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
-* Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.
 
 Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
 memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index c4b0c72805..ab4c0c75f7 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -9,10 +9,11 @@ title: Auditing
 
 <!-- overview -->
 
-Kubernetes auditing provides a security-relevant chronological set of records documenting
-the sequence of activities that have affected system by individual users, administrators
-or other components of the system. It allows cluster administrator to
-answer the following questions:
+Kubernetes _auditing_ provides a security-relevant, chronological set of records documenting
+the sequence of actions in a cluster. The cluster audits the activities generated by users,
+by applications that use the Kubernetes API, and by the control plane itself.
+
+Auditing allows cluster administrators to answer the following questions:
 
  - what happened?
  - when did it happen?
@@ -32,7 +33,7 @@ a certain policy and written to a backend. The policy determines what's recorded
 and the backends persist the records. The current backend implementations
 include logs files and webhooks.
 
-Each request can be recorded with an associated "stage". The known stages are:
+Each request can be recorded with an associated _stage_. The defined stages are:
 
 - `RequestReceived` - The stage for events generated as soon as the audit
   handler receives the request, and before it is delegated down the handler
@@ -45,19 +46,23 @@ Each request can be recorded with an associated "stage". The known stages are:
 - `Panic` - Events generated when a panic occurred.
 
 {{< note >}}
-The audit logging feature increases the memory consumption of the API server
-because some context required for auditing is stored for each request.
-Additionally, memory consumption depends on the audit logging configuration.
+Audit events are different from the
+[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+API object.
 {{< /note >}}
 
-## Audit Policy
+The audit logging feature increases the memory consumption of the API server
+because some context required for auditing is stored for each request.
+Memory consumption depends on the audit logging configuration.
+
+## Audit policy
 
 Audit policy defines rules about what events should be recorded and what data
 they should include. The audit policy object structure is defined in the
 [`audit.k8s.io` API group](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
 When an event is processed, it's
 compared against the list of rules in order. The first matching rule sets the
-"audit level" of the event. The known audit levels are:
+_audit level_ of the event. The defined audit levels are:
 
 - `None` - don't log events that match this rule.
 - `Metadata` - log request metadata (requesting user, timestamp, resource,
@@ -86,26 +91,27 @@ rules:
 - level: Metadata
 ```
 
-The audit profile used by GCE should be used as reference by admins constructing their own audit profiles. You can check the
+If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the
 [configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
-script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
+script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script.
 
 ## Audit backends
 
 Audit backends persist audit events to an external storage.
 Out of the box, the kube-apiserver provides two backends:
 
-- Log backend, which writes events to a disk
-- Webhook backend, which sends events to an external API
+- Log backend, which writes events into the filesystem
+- Webhook backend, which sends events to an external HTTP API
 
-In all cases, audit events structure is defined by the API in the
-`audit.k8s.io` API group. The current version of the API is
+In all cases, audit events follow a structure defined by the Kubernetes API in the
+`audit.k8s.io` API group. For Kubernetes {{< param "fullversion" >}}, that
+API is at version
 [`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
 
 {{< note >}}
 In case of patches, request body is a JSON array with patch operations, not a JSON object
 with an appropriate Kubernetes API object. For example, the following request body is a valid patch
-request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
+request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`:
 
 ```json
 [
@@ -125,8 +131,8 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
 
 ### Log backend
 
-Log backend writes audit events to a file in JSON format. You can configure
-log audit backend using the following `kube-apiserver` flags:
+The log backend writes audit events to a file in [JSONlines](https://jsonlines.org/) format.
+You can configure the log audit backend using the following `kube-apiserver` flags:
 
 - `--audit-log-path` specifies the log file path that log backend uses to write
   audit events. Not specifying this flag disables log backend. `-` means standard out
@@ -134,15 +140,16 @@ log audit backend using the following `kube-apiserver` flags:
 - `--audit-log-maxbackup` defines the maximum number of audit log files to retain
 - `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
 
-In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example, 
-`
---audit-policy-file=/etc/kubernetes/audit-policy.yaml
---audit-log-path=/var/log/audit.log
-`
+If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the `hostPath`
+to the location of the policy file and log file, so that audit records are persisted. For example:
+```shell
+    --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
+    --audit-log-path=/var/log/audit.log
+```
 then mount the volumes:
 
-
-```
+```yaml
+...
 volumeMounts:
   - mountPath: /etc/kubernetes/audit-policy.yaml
     name: audit
@@ -151,9 +158,10 @@ volumeMounts:
     name: audit-log
     readOnly: false
 ```
-finally the hostPath:
+and finally configure the `hostPath`:
 
-```
+```yaml
+...
 - name: audit
   hostPath:
     path: /etc/kubernetes/audit-policy.yaml
@@ -163,19 +171,19 @@ finally the hostPath:
   hostPath:
     path: /var/log/audit.log
     type: FileOrCreate
-    
+
 ```
 
 
 
 ### Webhook backend
 
-Webhook backend sends audit events to a remote API, which is assumed to be the
-same API as `kube-apiserver` exposes. You can configure webhook
-audit backend using the following kube-apiserver flags:
+The webhook audit backend sends audit events to a remote web API, which is assumed to
+be a form of the Kubernetes API, including means of authentication. You can configure
+a webhook audit backend using the following kube-apiserver flags:
 
 - `--audit-webhook-config-file` specifies the path to a file with a webhook
-  configuration. Webhook configuration is effectively a
+  configuration. The webhook configuration is effectively a specialized
   [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
 - `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed
   request before retrying. Subsequent requests are retried with exponential backoff.
@@ -183,7 +191,7 @@ audit backend using the following kube-apiserver flags:
 The webhook config file uses the kubeconfig format to specify the remote address of
 the service and credentials used to connect to it.
 
-### Batching
+## Event batching {#batching}
 
 Both log and webhook backends support batching. Using webhook as an example, here's the list of
 available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag
@@ -193,9 +201,10 @@ throttling is enabled in `webhook` and disabled in `log`.
 - `--audit-webhook-mode` defines the buffering strategy. One of the following:
   - `batch` - buffer events and asynchronously process them in batches. This is the default.
   - `blocking` - block API server responses on processing each individual event.
-  - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at RequestReceived stage, the whole request to apiserver will fail.
+  - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at the
+     RequestReceived stage, the whole request to the kube-apiserver fails.
 
-The following flags are used only in the `batch` mode.
+The following flags are used only in the `batch` mode:
 
 - `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching.
   If the rate of incoming events overflows the buffer, events are dropped.
@@ -207,16 +216,16 @@ The following flags are used only in the `batch` mode.
 - `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same
   moment if the allowed QPS was underutilized previously.
 
-#### Parameter tuning
+## Parameter tuning
 
-Parameters should be set to accommodate the load on the apiserver.
+Parameters should be set to accommodate the load on the API server.
 
 For example, if kube-apiserver receives 100 requests each second, and each request is audited only
-on `ResponseStarted` and `ResponseComplete` stages, you should account for ~200 audit
+on `ResponseStarted` and `ResponseComplete` stages, you should account for ≅200 audit
 events being generated each second. Assuming that there are up to 100 events in a batch,
-you should set throttling level at least 2 QPS. Assuming that the backend can take up to
-5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events, i.e.
-10 batches, i.e. 1000 events.
+you should set throttling level at least 2 queries per second. Assuming that the backend can take up to
+5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events;
+that is: 10 batches, or 1000 events.
 
 In most cases however, the default parameters should be sufficient and you don't have to worry about
 setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver
@@ -226,192 +235,18 @@ and in the logs to monitor the state of the auditing subsystem.
 - `apiserver_audit_error_total` metric contains the total number of events dropped due to an error
   during exporting.
 
-### Truncate
+### Log entry truncation {#truncate}
 
-Both log and webhook backends support truncating. As an example, the following is the list of flags
-available for the log backend:
+Both log and webhook backends support limiting the size of events that are logged.
+As an example, the following is the list of flags available for the log backend:
 
- - `audit-log-truncate-enabled` whether event and batch truncating is enabled.
- - `audit-log-truncate-max-batch-size` maximum size in bytes of the batch sent to the underlying backend.
- - `audit-log-truncate-max-event-size` maximum size in bytes of the audit event sent to the underlying backend.
-
-By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set `audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature.
-
-## Setup for multiple API servers
-
-If you're extending the Kubernetes API with the [aggregation
-layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/),
-you can also set up audit logging for the aggregated apiserver. To do this,
-pass the configuration options in the same format as described above to the
-aggregated apiserver and set up the log ingesting pipeline to pick up audit
-logs. Different apiservers can have different audit configurations and
-different audit policies.
-
-## Log Collector Examples
-
-### Use fluentd to collect and distribute audit events from log file
-
-[Fluentd](https://www.fluentd.org/) is an open source data collector for unified logging layer.
-In this example, we will use fluentd to split audit events by different namespaces.
-
-{{< note >}}
-The `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` are plugins for fluentd.
-You can get details about plugin installation from
-[fluentd plugin-management](https://docs.fluentd.org/v1.0/articles/plugin-management).
-{{< /note >}}
-
-1. Install [`fluentd`](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd),
-   `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` in the kube-apiserver node
-
-1. Create a config file for fluentd
-
-    ```
-    cat <<'EOF' > /etc/fluentd/config
-    # fluentd conf runs in the same host with kube-apiserver
-    <source>
-        @type tail
-        # audit log path of kube-apiserver
-        path /var/log/kube-audit
-        pos_file /var/log/audit.pos
-        format json
-        time_key time
-        time_format %Y-%m-%dT%H:%M:%S.%N%z
-        tag audit
-    </source>
-
-    <filter audit>
-        #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
-        @type record_transformer
-        enable_ruby
-        <record>
-         namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])}
-        </record>
-    </filter>
-
-    <match audit>
-        # route audit according to namespace element in context
-        @type rewrite_tag_filter
-        <rule>
-            key namespace
-            pattern /^(.+)/
-            tag ${tag}.$1
-        </rule>
-    </match>
-
-    <filter audit.**>
-       @type record_transformer
-       remove_keys namespace
-    </filter>
-
-    <match audit.**>
-        @type forest
-        subtype file
-        remove_prefix audit
-        <template>
-            time_slice_format %Y%m%d%H
-            compress gz
-            path /var/log/audit-${tag}.*.log
-            format json
-            include_time_key true
-        </template>
-    </match>
-    EOF
-    ```
-
-1. Start fluentd
-
-    ```shell
-    fluentd -c /etc/fluentd/config  -vv
-    ```
-
-1. Start kube-apiserver with the following options:
-
-    ```shell
-    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
-    ```
-
-1. Check audits for different namespaces in `/var/log/audit-*.log`
-
-### Use logstash to collect and distribute audit events from webhook backend
-
-[Logstash](https://www.elastic.co/products/logstash)
-is an open source, server-side data processing tool. In this example,
-we will use logstash to collect audit events from webhook backend, and save events of
-different users into different files.
-
-1. install [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html)
-
-1. create config file for logstash
-
-    ```
-    cat <<EOF > /etc/logstash/config
-    input{
-        http{
-            #TODO, figure out a way to use kubeconfig file to authenticate to logstash
-            #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
-            port=>8888
-        }
-    }
-    filter{
-        split{
-            # Webhook audit backend sends several events together with EventList
-            # split each event here.
-            field=>[items]
-            # We only need event subelement, remove others.
-            remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
-        }
-        mutate{
-            rename => {items=>event}
-        }
-    }
-    output{
-        file{
-            # Audit events from different users will be saved into different files.
-            path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
-        }
-    }
-    EOF
-    ```
-
-1. start logstash
-
-    ```shell
-    bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
-    ```
-
-1. create a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) for kube-apiserver webhook audit backend
-
-        cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
-        apiVersion: v1
-        kind: Config
-        clusters:
-        - cluster:
-            server: http://<ip_of_logstash>:8888
-          name: logstash
-        contexts:
-        - context:
-            cluster: logstash
-            user: ""
-          name: default-context
-        current-context: default-context
-        preferences: {}
-        users: []
-        EOF
-
-1. start kube-apiserver with the following options:
-
-    ```shell
-    --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
-    ```
-
-1. check audits in logstash node's directories `/var/log/kube-audit-*/audit`
-
-Note that in addition to file output plugin, logstash has a variety of outputs that
-let users route data where they want. For example, users can emit audit events to elasticsearch
-plugin which supports full-text search and analytics.
+- `audit-log-truncate-enabled` whether event and batch truncating is enabled.
+- `audit-log-truncate-max-batch-size` maximum size in bytes of the batch sent to the underlying backend.
+- `audit-log-truncate-max-event-size` maximum size in bytes of the audit event sent to the underlying backend.
 
+By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set
+`audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature.
 
 ## {{% heading "whatsnext" %}}
 
-Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
-
+* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md
index a047f194e9..ef80817082 100644
--- a/content/en/docs/tasks/debug-application-cluster/crictl.md
+++ b/content/en/docs/tasks/debug-application-cluster/crictl.md
@@ -15,7 +15,7 @@ content_type: task
 `crictl` is a command-line interface for CRI-compatible container runtimes.
 You can use it to inspect and debug container runtimes and applications on a
 Kubernetes node. `crictl` and its source are hosted in the
-[cri-tools](https://github.com/kubernetes-incubator/cri-tools) repository.
+[cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository.
 
 
 
@@ -31,7 +31,7 @@ Kubernetes node. `crictl` and its source are hosted in the
 ## Installing crictl
 
 You can download a compressed archive `crictl` from the cri-tools [release
-page](https://github.com/kubernetes-incubator/cri-tools/releases), for several
+page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
 different architectures. Download the version that corresponds to your version
 of Kubernetes. Extract it and move it to a location on your system path, such as
 `/usr/local/bin/`.
@@ -353,7 +353,7 @@ CONTAINER ID        IMAGE               CREATED              STATE
 
 <!-- discussion -->
 
-See [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)
+See [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)
 for more information.
 
 
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 65dfb63322..8f7c97c4e8 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -47,7 +47,7 @@ can not schedule your pod. Reasons include:
 You may have exhausted the supply of CPU or Memory in your cluster. In this
 case you can try several things:
 
-* [Add more nodes](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster) to the cluster.
+* Add more nodes to the cluster.
 
 * [Terminate unneeded pods](/docs/concepts/workloads/pods/#pod-termination)
   to make room for pending pods.
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index 00c5eb8944..a8c24693dc 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -9,29 +9,29 @@ content_type: concept
 <!-- overview -->
 
 Resource usage metrics, such as container CPU and memory usage,
-are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
-by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
+are available in Kubernetes through the Metrics API. These metrics can be accessed either directly
+by the user with the `kubectl top` command, or by a controller in the cluster, for example
 Horizontal Pod Autoscaler, to make decisions.
 
 <!-- body -->
 
 ## The Metrics API
 
-Through the Metrics API you can get the amount of resource currently used
+Through the Metrics API, you can get the amount of resource currently used
 by a given node or a given pod. This API doesn't store the metric values,
-so it's not possible for example to get the amount of resources used by a
+so it's not possible, for example, to get the amount of resources used by a
 given node 10 minutes ago.
 
 The API is no different from any other API:
 
-- it is discoverable through the same endpoint as the other Kubernetes APIs under `/apis/metrics.k8s.io/` path
-- it offers the same security, scalability and reliability guarantees
+- it is discoverable through the same endpoint as the other Kubernetes APIs under the path: `/apis/metrics.k8s.io/`
+- it offers the same security, scalability, and reliability guarantees
 
 The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
 repository. You can find more information about the API there.
 
 {{< note >}}
-The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
+The API requires the metrics server to be deployed in the cluster. Otherwise it will be not available.
 {{< /note >}}
 
 ## Measuring Resource Usage
@@ -49,22 +49,19 @@ The kubelet chooses the window for the rate calculation.
 Memory is reported as the working set, in bytes, at the instant the metric was collected.
 In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
 However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
-It includes all anonymous (non-file-backed) memory since kubernetes does not support swap.
+It includes all anonymous (non-file-backed) memory since Kubernetes does not support swap.
 The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
 
 ## Metrics Server
 
-[Metrics Server](https://github.com/kubernetes-incubator/metrics-server) is a cluster-wide aggregator of resource usage data.
-It is deployed by default in clusters created by `kube-up.sh` script
-as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
+[Metrics Server](https://github.com/kubernetes-sigs/metrics-server) is a cluster-wide aggregator of resource usage data.
+By default, it is deployed in clusters created by `kube-up.sh` script
+as a Deployment object. If you use a different Kubernetes setup mechanism, you can deploy it using the provided
 [deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
 
-Metric server collects metrics from the Summary API, exposed by
-[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node.
-
-Metrics Server is registered with the main API server through
+Metrics Server collects metrics from the Summary API, exposed by
+[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node, and is registered with the main API server via
 [Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 
 Learn more about the metrics server in
 [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
-
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index 8255d06afe..957ee62192 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -30,7 +30,7 @@ cluster components such as the
 [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
 controller, as well as the `kubectl top` utility.
 These  metrics are collected by the lightweight, short-term, in-memory 
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server) and
  are exposed via the `metrics.k8s.io` API. 
 
 metrics-server discovers all nodes on the cluster and 
diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
index 216145a744..bec423043d 100644
--- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -32,7 +32,7 @@ using [Krew](https://krew.dev/). Krew is a plugin manager maintained by
 the Kubernetes SIG CLI community.
 
 {{< caution >}}
-Kubectl plugins available via the Krew [plugin index](https://index.krew.dev/)
+Kubectl plugins available via the Krew [plugin index](https://krew.sigs.k8s.io/plugins/)
 are not audited for security. You should install and run third-party plugins at your
 own risk, since they are arbitrary programs running on your machine.
 {{< /caution >}}
@@ -46,7 +46,7 @@ A warning will also be included for any valid plugin files that overlap each oth
 
 You can use [Krew](https://krew.dev/) to discover and install `kubectl`
 plugins from a community-curated
-[plugin index](https://index.krew.dev/).
+[plugin index](https://krew.sigs.k8s.io/plugins/).
 
 #### Limitations
 
@@ -153,7 +153,7 @@ An older kubectl plugin mechanism provided environment variables such as `KUBECT
 kubectl plugins must parse and validate all of the arguments passed to them.
 See [using the command line runtime package](#using-the-command-line-runtime-package) for details of a Go library aimed at plugin authors.
 
-Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.
 
 If you run `kubectl foo bar baz arg1 --flag=value arg2`, kubectl's plugin mechanism will first try to find the plugin with the longest possible name, which in this case
 would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, kubectl then treats the last dash-separated value as an argument (`arg1` in this case), and attempts to find the next longest possible name, `kubectl-foo-bar-baz`.
@@ -354,7 +354,7 @@ package it, distribute it and deliver updates to your users.
 distribute your plugins. This way, you use a single packaging format for all
 target platforms (Linux, Windows, macOS etc) and deliver updates to your users.
 Krew also maintains a [plugin
-index](https://index.krew.dev/) so that other people can
+index](https://krew.sigs.k8s.io/plugins/) so that other people can
 discover your plugin and install it.
 
 
diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
index f9333b01c5..386bc7a08b 100644
--- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
+++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
@@ -150,7 +150,7 @@ kubectl get ct -o yaml
 ```
 
 You should see that it contains the custom `cronSpec` and `image` fields
-from the yaml you used to create it:
+from the YAML you used to create it:
 
 ```yaml
 apiVersion: v1
@@ -174,7 +174,7 @@ metadata:
 
 ## Delete a CustomResourceDefinition
 
-When you delete a CustomResourceDefinition, the server will uninstall the RESTful API  endpoint
+When you delete a CustomResourceDefinition, the server will uninstall the RESTful API endpoint
 and delete all custom objects stored in it.
 
 ```shell
@@ -190,11 +190,17 @@ If you later recreate the same CustomResourceDefinition, it will start out empty
 
 ## Specifying a structural schema
 
-CustomResources store structured data in custom fiels (alongside the built-in fields `apiVersion`, `kind` and `metadata`, which the API server validates implicitly). With [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
+CustomResources store structured data in custom fields (alongside the built-in
+fields `apiVersion`, `kind` and `metadata`, which the API server validates
+implicitly). With [OpenAPI v3.0 validation](#validation) a schema can be
+specified, which is validated during creation and updates, compare below for
+details and limits of such a schema.
 
-With `apiextensions.k8s.io/v1` the definition of a structural schema is mandatory for CustomResourceDefinitions (in the beta version of CustomResourceDefinition, structural schemas were optional).
+With `apiextensions.k8s.io/v1` the definition of a structural schema is
+mandatory for CustomResourceDefinitions. In the beta version of
+CustomResourceDefinition, the structural schema was optional.
 
-A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) which:
+A structural schema is an [OpenAPI v3.0 validation schema](#validation) which:
 
 1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of:
    * a node with `x-kubernetes-int-or-string: true`
@@ -274,7 +280,7 @@ is not a structural schema because of the following violations:
 * `bar` inside of `anyOf` is not specified outside (rule 2).
 * `bar`'s `type` is within `anyOf` (rule 3).
 * the description is set within `anyOf` (rule 3).
-* `metadata.finalizer` might not be restricted (rule 4).
+* `metadata.finalizers` might not be restricted (rule 4).
 
 In contrast, the following, corresponding schema is structural:
 ```yaml
@@ -308,7 +314,7 @@ CustomResourceDefinitions store validated resource data in the cluster's persist
 {{< note >}}
 CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`.
 
-For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update customer resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` true for the CustomResourceDefinition itself.
+For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` to true for the CustomResourceDefinition itself.
 {{< /note >}}
 
 If you save the following YAML to `my-crontab.yaml`:
@@ -350,12 +356,12 @@ spec:
 Notice that the field `someRandomField` was pruned.
 
 This example turned off client-side validation to demonstrate the API server's behavior, by adding the `--validate=false` command line option.
-Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
+Because the [OpenAPI validation schemas are also published](#publish-validation-schema-in-openapi-v2)
 to clients, `kubectl` also checks for unknown fields and rejects those objects well before they would be sent to the API server.
 
 #### Controlling pruning
 
-By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to opt-out of that for specifc sub-trees fof fields by adding `x-kubernetes-preserve-unknown-fields: true` in the [structural OpenAPI v3 validation schema](#specifying-a-structural-schema).  
+By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to opt-out of that for specifc sub-trees of fields by adding `x-kubernetes-preserve-unknown-fields: true` in the [structural OpenAPI v3 validation schema](#specifying-a-structural-schema).  
 For example:
 
 ```yaml
@@ -458,7 +464,7 @@ allOf:
 
 With one of those specification, both an integer and a string validate.
 
-In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2),
+In [Validation Schema Publishing](#publish-validation-schema-in-openapi-v2),
 `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
 
 ### RawExtension
@@ -512,32 +518,32 @@ apiVersion: "stable.example.com/v1"
 kind: CronTab
 metadata:
   finalizers:
-  - finalizer.stable.example.com
+  - stable.example.com/finalizer
 ```
 
-Finalizers are arbitrary string values, that when present ensure that a hard delete
-of a resource is not possible while they exist.
+Identifiers of custom finalizers consist of a domain name, a forward slash and the name of
+the finalizer. Any controller can add a finalizer to any object's list of finalizers.
 
 The first delete request on an object with finalizers sets a value for the
 `metadata.deletionTimestamp` field but does not delete it. Once this value is set,
-entries in the `finalizer` list can only be removed.
+entries in the `finalizers` list can only be removed. While any finalizers remain it is also
+impossible to force the deletion of an object.
 
-When the `metadata.deletionTimestamp` field is set, controllers watching the object
-execute any finalizers they handle, by polling update requests for that
-object. When all finalizers have been executed, the resource is deleted.
+When the `metadata.deletionTimestamp` field is set, controllers watching the object execute any
+finalizers they handle and remove the finalizer from the list after they are done. It is the
+responsibility of each controller to remove its finalizer from the list.
 
-The value of `metadata.deletionGracePeriodSeconds` controls the interval between
-polling updates.
+The value of `metadata.deletionGracePeriodSeconds` controls the interval between polling updates.
 
-It is the responsibility of each controller to remove its finalizer from the list.
-
-Kubernetes only finally deletes the object if the list of finalizers is empty,
-meaning all finalizers have been executed.
+Once the list of finalizers is empty, meaning all finalizers have been executed, the resource is
+deleted by Kubernetes.
 
 ### Validation
 
 Custom resources are validated via
-[OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) and you can add additional validation using [admission webhooks](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook).
+[OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject)
+and you can add additional validation using
+[admission webhooks](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook).
 
 Additionally, the following restrictions are applied to the schema:
 
@@ -552,17 +558,18 @@ Additionally, the following restrictions are applied to the schema:
   - `writeOnly`,
   - `xml`,
   - `$ref`.
-- The field `uniqueItems` cannot be set to _true_.
-- The field `additionalProperties` cannot be set to _false_.
+- The field `uniqueItems` cannot be set to `true`.
+- The field `additionalProperties` cannot be set to `false`.
 - The field `additionalProperties` is mutually exclusive with `properties`.
 
-These fields can only be set with specific features enabled:
+The `default` field can be set when the [Defaulting feature](#defaulting) is enabled,
+which is the case with `apiextensions.k8s.io/v1` CustomResourceDefinitions. 
+Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+enabled, which is the case automatically for many clusters for beta features).
 
-You can also use [Validation Schema Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) to apply default values.
-
-{{< note >}}
-Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features.
-{{< /note >}}
+Refer to the [structural schemas](#specifying-a-structural-schema) section for other
+restrictions and CustomResourceDefinition features.
 
 The schema is defined in the CustomResourceDefinition. In the following example, the
 CustomResourceDefinition applies the following validations on the custom object:
@@ -756,7 +763,7 @@ Default values for `metadata` fields of `x-kubernetes-embedded-resources: true`
 
 ### Publish Validation Schema in OpenAPI v2
 
-CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#preserving-unknown-fields) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server.
+CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server.
 
 The [kubectl](/docs/reference/kubectl/overview) command-line tool consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation.
 
@@ -853,7 +860,7 @@ The `NAME` column is implicit and does not need to be defined in the CustomResou
 
 #### Priority
 
-Each column includes a `priority` field for each column. Currently, the priority
+Each column includes a `priority` field. Currently, the priority
 differentiates between columns shown in standard view or wide view (using the `-o wide` flag).
 
 - Columns with priority `0` are shown in standard view.
@@ -866,7 +873,7 @@ A column's `type` field can be any of the following (compare [OpenAPI v3 data ty
 - `integer` – non-floating-point numbers
 - `number` – floating point numbers
 - `string` – strings
-- `boolean` – true or false
+- `boolean` – `true` or `false`
 - `date` – rendered differentially as time since this timestamp.
 
 If the value inside a CustomResource does not match the type specified for the column,
@@ -906,54 +913,54 @@ When the status subresource is enabled, the `/status` subresource for the custom
 - The `.metadata.generation` value is incremented for all changes, except for changes to `.metadata` or `.status`.
 - Only the following constructs are allowed at the root of the CRD OpenAPI validation schema:
 
-  - Description
-  - Example
-  - ExclusiveMaximum
-  - ExclusiveMinimum
-  - ExternalDocs
-  - Format
-  - Items
-  - Maximum
-  - MaxItems
-  - MaxLength
-  - Minimum
-  - MinItems
-  - MinLength
-  - MultipleOf
-  - Pattern
-  - Properties
-  - Required
-  - Title
-  - Type
-  - UniqueItems
+  - `description`
+  - `example`
+  - `exclusiveMaximum`
+  - `exclusiveMinimum`
+  - `externalDocs`
+  - `format`
+  - `items`
+  - `maximum`
+  - `maxItems`
+  - `maxLength`
+  - `minimum`
+  - `minItems`
+  - `minLength`
+  - `multipleOf`
+  - `pattern`
+  - `properties`
+  - `required`
+  - `title`
+  - `type`
+  - `uniqueItems`
 
 #### Scale subresource
 
 When the scale subresource is enabled, the `/scale` subresource for the custom resource is exposed.
 The `autoscaling/v1.Scale` object is sent as the payload for `/scale`.
 
-To enable the scale subresource, the following values are defined in the CustomResourceDefinition.
+To enable the scale subresource, the following fields are defined in the CustomResourceDefinition.
 
-- `SpecReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Spec.Replicas`.
+- `specReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `scale.spec.replicas`.
 
   - It is a required value.
   - Only JSONPaths under `.spec` and with the dot notation are allowed.
-  - If there is no value under the `SpecReplicasPath` in the custom resource,
+  - If there is no value under the `specReplicasPath` in the custom resource,
 the `/scale` subresource will return an error on GET.
 
-- `StatusReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Status.Replicas`.
+- `statusReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `scale.status.replicas`.
 
   - It is a required value.
   - Only JSONPaths under `.status` and with the dot notation are allowed.
-  - If there is no value under the `StatusReplicasPath` in the custom resource,
+  - If there is no value under the `statusReplicasPath` in the custom resource,
 the status replica value in the `/scale` subresource will default to 0.
 
-- `LabelSelectorPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Status.Selector`.
+- `labelSelectorPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Status.Selector`.
 
   - It is an optional value.
   - It must be set to work with HPA.
   - Only JSONPaths under `.status` or `.spec` and with the dot notation are allowed.
-  - If there is no value under the `LabelSelectorPath` in the custom resource,
+  - If there is no value under the `labelSelectorPath` in the custom resource,
 the status selector value in the `/scale` subresource will default to the empty string.
   - The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form.
 
@@ -1141,7 +1148,7 @@ and create it:
 kubectl apply -f my-crontab.yaml
 ```
 
-You can specify the category using `kubectl get`:
+You can specify the category when using `kubectl get`:
 
 ```
 kubectl get all
diff --git a/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md
index da9dabb135..82eecc9c38 100644
--- a/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md
+++ b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md
@@ -24,10 +24,35 @@ The following steps require an egress configuration, for example:
 You need to configure the API Server to use the Konnectivity service
 and direct the network traffic to the cluster nodes:
 
+1. Make sure that
+the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is enabled. You can enable
+[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
+by providing the following flags to the kube-apiserver:
+   ```
+   --service-account-issuer=api
+   --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
+   --api-audiences=system:konnectivity-server
+   ```
 1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
 1. Set the `--egress-selector-config-file` flag of the API Server to the path of
 your API Server egress configuration file.
 
+Generate or obtain a certificate and kubeconfig for konnectivity-server.  
+For example, you can use the OpenSSL command line tool to issue a X.509 certificate,
+using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-plane host.
+
+```bash
+openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr
+openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
+SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
+rm -f konnectivity.crt konnectivity.key konnectivity.csr
+```
+
 Next, you need to deploy the Konnectivity server and agents.
 [kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
 is a reference implementation.
diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
index cbc3c45260..9cefdca03d 100644
--- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -47,17 +47,10 @@ Pod:
     envar-demo      1/1       Running   0          9s
     ```
 
-1. Get a shell to the container running in your Pod:
+1. List the Pod's container environment variables:
 
     ```shell
-    kubectl exec -it envar-demo -- /bin/bash
-    ```
-
-1. In your shell, run the `printenv` command to list the environment variables.
-
-    ```shell
-    # Run this in the shell inside the container
-    printenv
+    kubectl exec envar-demo -- printenv
     ```
 
     The output is similar to this:
@@ -71,8 +64,6 @@ Pod:
     DEMO_FAREWELL=Such a sweet sorrow
     ```
 
-1. To exit the shell, enter `exit`.
-
 {{< note >}}
 The environment variables set using the `env` or `envFrom` field
 override any environment variables specified in the container image.
@@ -122,4 +113,3 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
 * Learn about [using secrets as environment variables](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables).
 * See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
 
-
diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md
index 9eea082321..91c3c7beb6 100644
--- a/content/en/docs/tasks/inject-data-application/podpreset.md
+++ b/content/en/docs/tasks/inject-data-application/podpreset.md
@@ -18,7 +18,7 @@ This page shows how to use PodPreset objects to inject information like {{< glos
 ## {{% heading "prerequisites" %}}
 
 
-You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](/docs/setup/learning-environment/minikube/).
+You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/).
 Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
 
 
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
index f8403dec17..a51b5664ba 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -37,7 +37,7 @@ The `kubectl` tool supports verb-driven commands for creating some of the most c
 object types. The commands are named to be recognizable to users unfamiliar with
 the Kubernetes object types.
 
-- `run`: Create a new Deployment object to run Containers in one or more Pods.
+- `run`: Create a new Pod to run a Container.
 - `expose`: Create a new Service object to load balance traffic across Pods.
 - `autoscale`: Create a new Autoscaler object to automatically horizontally scale a controller, such as a Deployment.
 
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
index a8faefd63e..2b97ed271c 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -64,6 +64,18 @@ configuration file.
 
 * `kubectl delete -f <filename|url>`
 
+{{< note >}}
+If configuration file has specified the `generateName` field in the `metadata`
+section instead of the `name` field, you cannot delete the object using
+`kubectl delete -f <filename|url>`.
+You will have to use other flags for deleting the object. For example:
+
+```shell
+kubectl delete <type> <name>
+kubectl delete <type> -l <label>
+```
+{{< /note >}}
+
 ## How to view an object
 
 You can use `kubectl get -f` to view information about an object that is
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
index 01b03233c8..f5e20a94c0 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -8,7 +8,7 @@ weight: 20
 
 [Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool
 to customize Kubernetes objects
-through a [kustomization file](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization).
+through a [kustomization file](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization).
 
 Since 1.14, Kubectl also
 supports the management of Kubernetes objects using a kustomization file.
diff --git a/content/en/docs/tasks/network/validate-dual-stack.md b/content/en/docs/tasks/network/validate-dual-stack.md
index 1e21af226d..305f78db28 100644
--- a/content/en/docs/tasks/network/validate-dual-stack.md
+++ b/content/en/docs/tasks/network/validate-dual-stack.md
@@ -16,7 +16,6 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
 
 * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
 * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico)
-* Kube-proxy running in mode IPVS
 * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster
 
 {{< version-check >}}
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 2c00e4aa7b..49009e1268 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -11,39 +11,37 @@ weight: 100
 
 <!-- overview -->
 
-Horizontal Pod Autoscaler automatically scales the number of pods
+Horizontal Pod Autoscaler automatically scales the number of Pods
 in a replication controller, deployment, replica set or stateful set based on observed CPU utilization
 (or, with beta support, on some other, application-provided metrics).
 
 This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.
-For more information on how Horizontal Pod Autoscaler behaves, see the 
+For more information on how Horizontal Pod Autoscaler behaves, see the
 [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
 
 ## {{% heading "prerequisites" %}}
 
-
 This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
-to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
-metrics-server monitoring will be turned-on by default.
+[Metrics server](https://github.com/kubernetes-sigs/metrics-server) monitoring needs to be deployed
+in the cluster to provide metrics through the [Metrics API](https://github.com/kubernetes/metrics).
+Horizontal Pod Autoscaler uses this API to collect metrics. To learn how to deploy the metrics-server,
+see the [metrics-server documentation](https://github.com/kubernetes-sigs/metrics-server#deployment).
 
-To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
-and kubectl at version 1.6 or later.  Furthermore, in order to make use of custom metrics, your cluster
-must be able to communicate with the API server providing the custom metrics API. Finally, to use metrics
-not related to any Kubernetes object you must have a Kubernetes cluster at version 1.10 or later, and
-you must be able to communicate with the API server that provides the external metrics API.
+To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a
+Kubernetes cluster and kubectl at version 1.6 or later. To make use of custom metrics, your cluster
+must be able to communicate with the API server providing the custom Metrics API.
+Finally, to use metrics not related to any Kubernetes object you must have a
+Kubernetes cluster at version 1.10 or later, and you must be able to communicate
+with the API server that provides the external Metrics API.
 See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
 
-
-
 <!-- steps -->
 
-## Run & expose php-apache server
+## Run and expose php-apache server
 
-To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
-The Dockerfile has the following content:
+To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image. The Dockerfile has the following content:
 
-```
+```dockerfile
 FROM php:5-apache
 COPY index.php /var/www/html/index.php
 RUN chmod a+rx index.php
@@ -51,7 +49,7 @@ RUN chmod a+rx index.php
 
 It defines an index.php page which performs some CPU intensive computations:
 
-```
+```php
 <?php
   $x = 0.0001;
   for ($i = 0; $i <= 1000000; $i++) {
@@ -66,11 +64,12 @@ using the following configuration:
 
 {{< codenew file="application/php-apache.yaml" >}}
 
-
 Run the following command:
+
 ```shell
 kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
 ```
+
 ```
 deployment.apps/php-apache created
 service/php-apache created
@@ -90,6 +89,7 @@ See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-detai
 ```shell
 kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
 ```
+
 ```
 horizontalpodautoscaler.autoscaling/php-apache autoscaled
 ```
@@ -99,10 +99,10 @@ We may check the current status of autoscaler by running:
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET    MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1          18s
-
 ```
 
 Please note that the current CPU consumption is 0% as we are not sending any requests to the server
@@ -114,11 +114,7 @@ Now, we will see how the autoscaler reacts to increased load.
 We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
 
 ```shell
-kubectl run -it --rm load-generator --image=busybox /bin/sh
-
-Hit enter for command prompt
-
-while true; do wget -q -O- http://php-apache; done
+kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
 ```
 
 Within a minute or so, we should see the higher CPU load by executing:
@@ -126,10 +122,10 @@ Within a minute or so, we should see the higher CPU load by executing:
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   305% / 50%  1         10        1          3m
-
 ```
 
 Here, CPU consumption has increased to 305% of the request.
@@ -138,6 +134,7 @@ As a result, the deployment was resized to 7 replicas:
 ```shell
 kubectl get deployment php-apache
 ```
+
 ```
 NAME         READY   UP-TO-DATE   AVAILABLE   AGE
 php-apache   7/7      7           7           19m
@@ -161,6 +158,7 @@ Then we will verify the result state (after a minute or so):
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m
@@ -169,6 +167,7 @@ php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1
 ```shell
 kubectl get deployment php-apache
 ```
+
 ```
 NAME         READY   UP-TO-DATE   AVAILABLE   AGE
 php-apache   1/1     1            1           27m
@@ -180,8 +179,6 @@ Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas
 Autoscaling the replicas may take a few minutes.
 {{< /note >}}
 
-
-
 <!-- discussion -->
 
 ## Autoscaling on multiple metrics and custom metrics
@@ -244,8 +241,8 @@ There are two other types of metrics, both of which are considered *custom metri
 object metrics.  These metrics may have names which are cluster specific, and require a more
 advanced cluster monitoring setup.
 
-The first of these alternative metric types is *pod metrics*.  These metrics describe pods, and
-are averaged together across pods and compared with a target value to determine the replica count.
+The first of these alternative metric types is *pod metrics*.  These metrics describe Pods, and
+are averaged together across Pods and compared with a target value to determine the replica count.
 They work much like resource metrics, except that they *only* support a `target` type of `AverageValue`.
 
 Pod metrics are specified using a metric block like this:
@@ -261,11 +258,11 @@ pods:
 ```
 
 The second alternative metric type is *object metrics*. These metrics describe a different
-object in the same namespace, instead of describing pods. The metrics are not necessarily
+object in the same namespace, instead of describing Pods. The metrics are not necessarily
 fetched from the object; they only describe it. Object metrics support `target` types of
 both `Value` and `AverageValue`.  With `Value`, the target is compared directly to the returned
 metric from the API. With `AverageValue`, the value returned from the custom metrics API is divided
-by the number of pods before being compared to the target. The following example is the YAML
+by the number of Pods before being compared to the target. The following example is the YAML
 representation of the `requests-per-second` metric.
 
 ```yaml
@@ -423,7 +420,8 @@ we can use `kubectl describe hpa`:
 ```shell
 kubectl describe hpa cm-test
 ```
-```shell
+
+```
 Name:                           cm-test
 Namespace:                      prom
 Labels:                         <none>
@@ -478,8 +476,7 @@ We will create the autoscaler by executing the following command:
 ```shell
 kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
 ```
+
 ```
 horizontalpodautoscaler.autoscaling/php-apache created
 ```
-
-
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
index f84744cdd7..ff16a13e74 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -15,7 +15,7 @@ weight: 90
 
 <!-- overview -->
 
-The Horizontal Pod Autoscaler automatically scales the number of pods
+The Horizontal Pod Autoscaler automatically scales the number of Pods
 in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with
 [custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
 support, on some other application-provided metrics). Note that Horizontal
@@ -45,16 +45,16 @@ obtains the metrics from either the resource metrics API (for per-pod resource m
 or the custom metrics API (for all other metrics).
 
 * For per-pod resource metrics (like CPU), the controller fetches the metrics
-  from the resource metrics API for each pod targeted by the HorizontalPodAutoscaler.
+  from the resource metrics API for each Pod targeted by the HorizontalPodAutoscaler.
   Then, if a target utilization value is set, the controller calculates the utilization
   value as a percentage of the equivalent resource request on the containers in
-  each pod.  If a target raw value is set, the raw metric values are used directly.
+  each Pod.  If a target raw value is set, the raw metric values are used directly.
   The controller then takes the mean of the utilization or the raw value (depending on the type
-  of target specified) across all targeted pods, and produces a ratio used to scale
+  of target specified) across all targeted Pods, and produces a ratio used to scale
   the number of desired replicas.
 
-  Please note that if some of the pod's containers do not have the relevant resource request set,
-  CPU utilization for the pod will not be defined and the autoscaler will
+  Please note that if some of the Pod's containers do not have the relevant resource request set,
+  CPU utilization for the Pod will not be defined and the autoscaler will
   not take any action for that metric. See the [algorithm
   details](#algorithm-details) section below for more information about
   how the autoscaling algorithm works.
@@ -65,7 +65,7 @@ or the custom metrics API (for all other metrics).
 * For object metrics and external metrics, a single metric is fetched, which describes
   the object in question. This metric is compared to the target
   value, to produce a ratio as above. In the `autoscaling/v2beta2` API
-  version, this value can optionally be divided by the number of pods before the
+  version, this value can optionally be divided by the number of Pods before the
   comparison is made.
 
 The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
@@ -265,12 +265,12 @@ APIs, cluster administrators must ensure that:
 
 * The corresponding APIs are registered:
 
-   * For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-incubator/metrics-server).
+   * For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server).
      It can be launched as a cluster addon.
 
    * For custom metrics, this is the `custom.metrics.k8s.io` API.  It's provided by "adapter" API servers provided by metrics solution vendors.
      Check with your metrics pipeline, or the [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
-     If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) to get started.
+     If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started.
 
    * For external metrics, this is the `external.metrics.k8s.io` API.  It may be provided by the custom metrics adapters provided above.
 
@@ -319,7 +319,7 @@ For instance if there are 80 replicas and the target has to be scaled down to 10
 then during the first step 8 replicas will be reduced. In the next iteration when the number
 of replicas is 72, 10% of the pods is 7.2 but the number is rounded up to 8. On each loop of
 the autoscaler controller the number of pods to be change is re-calculated based on the number
-of current replicas. When the number of replicas falls below 40 the first policy_(Pods)_ is applied
+of current replicas. When the number of replicas falls below 40 the first policy _(Pods)_ is applied
 and 4 replicas will be reduced at a time.
 
 `periodSeconds` indicates the length of time in the past for which the policy must hold true.
@@ -328,7 +328,7 @@ allows at most 10% of the current replicas to be scaled down in one minute.
 
 The policy selection can be changed by specifying the `selectPolicy` field for a scaling
 direction. By setting the value to `Min` which would select the policy which allows the
-smallest change in the replica count. Setting the value to `Disabled` completely disabled
+smallest change in the replica count. Setting the value to `Disabled` completely disables
 scaling in that direction.
 
 ### Stabilization Window
@@ -405,8 +405,9 @@ behavior:
       periodSeconds: 60
 ```
 
-To allow a final drop of 5 pods, another policy can be added and a selection
-strategy of minimum:
+To ensure that no more than 5 Pods are removed per minute, you can add a second scale-down
+policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means
+that the autoscaler chooses the policy that affects the smallest number of Pods:
 
 ```yaml
 behavior:
@@ -418,7 +419,7 @@ behavior:
     - type: Pods
       value: 5
       periodSeconds: 60
-    selectPolicy: Max
+    selectPolicy: Min
 ```
 
 ### Example: disable scale down
@@ -432,7 +433,14 @@ behavior:
     selectPolicy: Disabled
 ```
 
+## Implicit maintenance-mode deactivation
 
+You can implicitly deactivate the HPA for a target without the
+need to change the HPA configuration itself. If the target's desired replica count
+is set to 0, and the HPA's minimum replica count is greater than 0, the HPA 
+stops adjusting the target (and sets the `ScalingActive` Condition on itself
+to `false`) until you reactivate it by manually adjusting the target's desired
+replica count or HPA's minimum replica count.
 
 ## {{% heading "whatsnext" %}}
 
@@ -440,5 +448,3 @@ behavior:
 * Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
 * kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
 * Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
-
-
diff --git a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
index 9e6ed4a25e..df604facf8 100644
--- a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
+++ b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
@@ -80,7 +80,7 @@ a Deployment that runs the nginx:1.14.2 Docker image:
         NewReplicaSet:    nginx-deployment-1771418926 (2/2 replicas created)
         No events.
 
-1. List the pods created by the deployment:
+1. List the Pods created by the deployment:
 
         kubectl get pods -l app=nginx
 
@@ -113,9 +113,9 @@ specifies that the deployment should be updated to use nginx 1.16.1.
 
 ## Scaling the application by increasing the replica count
 
-You can increase the number of pods in your Deployment by applying a new YAML
+You can increase the number of Pods in your Deployment by applying a new YAML
 file. This YAML file sets `replicas` to 4, which specifies that the Deployment
-should have four pods:
+should have four Pods:
 
 {{< codenew file="application/deployment-scale.yaml" >}}
 
@@ -123,7 +123,7 @@ should have four pods:
 
         kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
 
-1. Verify that the Deployment has four pods:
+1. Verify that the Deployment has four Pods:
 
         kubectl get pods -l app=nginx
 
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 95213176bf..d558a271ad 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -39,7 +39,7 @@ helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
 Check to make sure that it installed successfully by executing the following command:
 
 ```shell
-helm search service-catalog
+helm search repo service-catalog
 ```
 
 If the installation was successful, the command should output the following:
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
index 937f1170a7..52a55457a2 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -78,6 +78,6 @@ sc uninstall
 ## {{% heading "whatsnext" %}}
 
 * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
+* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
 
 
diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
index e35fddcd46..62e5cfc9cf 100644
--- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
@@ -76,11 +76,16 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
     "192.0.2.24",
     "10.0.34.2"
   ],
-  "CN": "my-pod.my-namespace.pod.cluster.local",
+  "CN": "system:node:my-pod.my-namespace.pod.cluster.local",
   "key": {
     "algo": "ecdsa",
     "size": 256
-  }
+  },
+  "names": [
+    {
+      "O": "system:nodes"
+    }
+  ]
 }
 EOF
 ```
diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
index 9d7516aeef..3147ac3a18 100644
--- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
+++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
@@ -33,14 +33,17 @@ Configurations with a single API server will experience unavailability while the
    (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`)
    to all your control plane nodes in the Kubernetes certificates directory.
 
-1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager.
+1. Update {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}'s `--root-ca-file` to
+   include both old and new CA. Then restart the component.
 
    Any service account created after this point will get secrets that include both old and new CAs.
 
    {{< note >}}
-   Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration.
-   You can also replace the existing client CA file or change this configuration item to reference a new, updated CA.
-   [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
+   The files specified by the kube-controller-manager flags `--client-ca-file` and `--cluster-signing-cert-file`
+   cannot be CA bundles. If these flags and `--root-ca-file` point to the same `ca.crt` file which is now a
+   bundle (includes both old and new CA) you will face an error. To workaround this problem you can copy the new CA to a separate
+   file and make the flags `--client-ca-file` and `--cluster-signing-cert-file` point to the copy. Once `ca.crt` is no longer
+   a bundle you can restore the problem flags to point to `ca.crt` and delete the copy.
    {{< /note >}}
 
 1. Update all service account tokens to include both old and new CA certificates.
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index a942f3ea87..7bbb2161ec 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -8,34 +8,51 @@ no_list: true
 ## kubectl
 
 The Kubernetes command-line tool, `kubectl`, allows you to run commands against
-Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage
-cluster resources, and view logs.
+Kubernetes clusters. You can use `kubectl` to deploy applications, inspect and
+manage cluster resources, and view logs.
 
-See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to
-download and install `kubectl` and set it up for accessing your cluster.
+See [Install and Set Up `kubectl`](/docs/tasks/tools/install-kubectl/) for
+information about how to download and install `kubectl` and set it up for
+accessing your cluster.
 
-You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/).
+<a class="btn btn-primary" href="/docs/tasks/tools/install-kubectl/" role="button" aria-label="View kubectl Install and Set Up Guide">View kubectl Install and Set Up Guide</a>
 
-## Minikube
-
-[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run
-Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal
-computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes,
-or for daily development work.
-
-You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/)
-guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus
-is on getting the tool installed.
-
-Once you have Minikube working, you can use it to
-[run a sample application](/docs/tutorials/hello-minikube/).
+You can also read the
+[`kubectl` reference documentation](/docs/reference/kubectl/).
 
 ## kind
 
-Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
-your local computer. Unlike Minikube, kind only works with a single container runtime:
-it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
-and configured.
+[`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local computer. This tool requires that you have
+[Docker](https://docs.docker.com/get-docker/) installed and configured.
 
-[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you
-need to do to get up and running with kind.
+The kind [Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) page
+shows you what you need to do to get up and running with kind.
+
+<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/" role="button" aria-label="View kind Quick Start Guide">View kind Quick Start Guide</a>
+
+## minikube
+
+Like `kind`, [`minikube`](https://minikube.sigs.k8s.io/) is a tool that lets you run Kubernetes
+locally. `minikube` runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out
+Kubernetes, or for daily development work.
+
+You can follow the official
+[Get Started!](https://minikube.sigs.k8s.io/docs/start/) guide if your focus is
+on getting the tool installed.
+
+<a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/" role="button" aria-label="View minikube Get Started! Guide">View minikube Get Started! Guide</a>
+
+Once you have `minikube` working, you can use it to
+[run a sample application](/docs/tutorials/hello-minikube/).
+
+## kubeadm
+
+You can use the {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} tool to create and manage Kubernetes clusters.
+It performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way.
+
+[Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) shows you how to install kubeadm.
+Once installed, you can use it to [create a cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
+
+<a class="btn btn-primary" href="/docs/setup/production-environment/tools/kubeadm/install-kubeadm/" role="button" aria-label="View kubeadm Install Guide">View kubeadm Install Guide</a>
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 2d9c8f1adb..5bfebd226b 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -65,7 +65,7 @@ Using the latest version of kubectl helps avoid unforeseen issues.
 
 {{< tabs name="kubectl_install" >}}
 {{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
+sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
 echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
 sudo apt-get update
@@ -525,7 +525,7 @@ compinit
 
 ## {{% heading "whatsnext" %}}
 
-* [Install Minikube](/docs/tasks/tools/install-minikube/)
+* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/)
 * See the [getting started guides](/docs/setup/) for more about creating clusters.
 * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
 * If you need access to a cluster you didn't create, see the
diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md
deleted file mode 100644
index d8b5b101c4..0000000000
--- a/content/en/docs/tasks/tools/install-minikube.md
+++ /dev/null
@@ -1,262 +0,0 @@
----
-title: Install Minikube
-content_type: task
-weight: 20
-card:
-  name: tasks
-  weight: 10
----
-
-<!-- overview -->
-
-This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-{{< tabs name="minikube_before_you_begin" >}}
-{{% tab name="Linux" %}}
-To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
-```
-grep -E --color 'vmx|svm' /proc/cpuinfo
-```
-{{% /tab %}}
-
-{{% tab name="macOS" %}}
-To check if virtualization is supported on macOS, run the following command on your terminal.
-```
-sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
-```
-If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
-{{% /tab %}}
-
-{{% tab name="Windows" %}}
-To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
-```
-systeminfo
-```
-If you see the following output, virtualization is supported on Windows.
-```
-Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
-                          Virtualization Enabled In Firmware: Yes
-                          Second Level Address Translation: Yes
-                          Data Execution Prevention Available: Yes
-```
-
-If you see the following output, your system already has a Hypervisor installed and you can skip the next step.
-```
-Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.
-```
-
-
-{{% /tab %}}
-{{< /tabs >}}
-
-
-
-<!-- steps -->
-
-## Installing minikube
-
-{{< tabs name="tab_with_md" >}}
-{{% tab name="Linux" %}}
-
-### Install kubectl
-
-Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
-
-### Install a Hypervisor
-
-If you do not already have a hypervisor installed, install one of these now:
-
-• [KVM](https://www.linux-kvm.org/), which also uses QEMU
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-Minikube also supports a `--driver=none` option that runs the Kubernetes components on the host and not in a VM.
-Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
-
-If you're using the `none` driver in Debian or a derivative, use the `.deb` packages for
-Docker rather than the snap package, which does not work with Minikube.
-You can download `.deb` packages from [Docker](https://www.docker.com/products/docker-desktop).
-
-{{< caution >}}
-The `none` VM driver can result in security and data loss issues.
-Before using `--driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
-{{< /caution >}}
-
-Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
-
-{{< caution >}}
-The `podman` driver requires running the containers as root because regular user accounts don't have full access to all operating system features that their containers might need to run.
-{{< /caution >}}
-
-### Install Minikube using a package
-
-There are *experimental* packages for Minikube available; you can find Linux (AMD64) packages
-from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page on GitHub.
-
-Use your Linux's distribution's package tool to install a suitable package.
-
-### Install Minikube via direct download
-
-If you're not installing via a package, you can download a stand-alone
-binary and use that.
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
-  && chmod +x minikube
-```
-
-Here's an easy way to add the Minikube executable to your path:
-
-```shell
-sudo mkdir -p /usr/local/bin/
-sudo install minikube /usr/local/bin/
-```
-
-### Install Minikube using Homebrew
-
-As yet another alternative, you can install Minikube using Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux):
-
-```shell
-brew install minikube
-```
-
-{{% /tab %}}
-{{% tab name="macOS" %}}
-### Install kubectl
-
-Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
-
-### Install a Hypervisor
-
-If you do not already have a hypervisor installed, install one of these now:
-
-• [HyperKit](https://github.com/moby/hyperkit)
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-• [VMware Fusion](https://www.vmware.com/products/fusion)
-
-### Install Minikube
-The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh):
-
-```shell
-brew install minikube
-```
-
-You can also install it on macOS by downloading a stand-alone binary:
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
-  && chmod +x minikube
-```
-
-Here's an easy way to add the Minikube executable to your path:
-
-```shell
-sudo mv minikube /usr/local/bin
-```
-
-{{% /tab %}}
-{{% tab name="Windows" %}}
-### Install kubectl
-
-Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
-
-### Install a Hypervisor
-
-If you do not already have a hypervisor installed, install one of these now:
-
-• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-{{< note >}}
-Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
-{{< /note >}}
-
-### Install Minikube using Chocolatey
-
-The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
-
-```shell
-choco install minikube
-```
-
-After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
-
-### Install Minikube using an installer executable
-
-To install Minikube manually on Windows using [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), download [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) and execute the installer.
-
-### Install Minikube via direct download
-
-To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Confirm Installation
-
-To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster:
-
-{{< note >}}
-
-For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
-
-{{< /note >}}
-
-{{< caution >}}
-When using KVM, note that libvirt's default QEMU URI under Debian and some other systems is `qemu:///session` whereas Minikube's default QEMU URI is `qemu:///system`. If this is the case for your system, you will need to pass `--kvm-qemu-uri qemu:///session` to `minikube start`.
-{{< /caution >}}
-
-```shell
-minikube start --driver=<driver_name>
-```
-
-Once `minikube start` finishes, run the command below to check the status of the cluster:
-
-```shell
-minikube status
-```
-
-If your cluster is running, the output from `minikube status` should be similar to:
-
-```
-host: Running
-kubelet: Running
-apiserver: Running
-kubeconfig: Configured
-```
-
-After you have confirmed whether Minikube is working with your chosen hypervisor, you can continue to use Minikube or you can stop your cluster. To stop your cluster, run:
-
-```shell
-minikube stop
-```
-
-## Clean up local state {#cleanup-local-state}
-
-If you have previously installed Minikube, and run:
-```shell
-minikube start
-```
-
-and `minikube start` returned an error:
-```
-machine does not exist
-```
-
-then you need to clear minikube's local state:
-```shell
-minikube delete
-```
-
-## {{% heading "whatsnext" %}}
-
-
-* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
diff --git a/content/en/docs/test.md b/content/en/docs/test.md
index 071a873b37..c052cb5f9c 100644
--- a/content/en/docs/test.md
+++ b/content/en/docs/test.md
@@ -61,9 +61,7 @@ Markdown doesn't have strict rules about how to process lists. When we moved
 from Jekyll to Hugo, we broke some lists. To fix them, keep the following in
 mind:
 
-- Make sure you indent sub-list items **4 spaces** rather than the 2 that you
-  may be used to. Counter-intuitively, you need to indent block-level content
-  within a list item an extra 4 spaces too.
+- Make sure you indent sub-list items **2 spaces**. 
 
 - To end a list and start another, you need a HTML comment block on a new line
   between the lists, flush with the left-hand border. The first list won't end
@@ -74,10 +72,9 @@ mind:
 - This is a list item
 * This is another list item in the same list
 - You can mix `-` and `*`
-    - To make a sub-item, indent two tabstops (4 spaces). **This is different
-      from Jekyll and Kramdown.**
-        - This is a sub-sub-item. Indent two more tabstops (4 more spaces).
-    - Another sub-item.
+  - To make a sub-item, indent two spaces.
+    - This is a sub-sub-item. Indent two more spaces.
+  - Another sub-item.
 
 <!-- separate lists -->
 
@@ -85,15 +82,15 @@ mind:
   consecutive lists. **The HTML comment needs to be at the left margin.**
 - Bullet lists can have paragraphs or block elements within them.
 
-      Indent the content to be one tab stop beyond the text of the bullet
-      point. **This paragraph and the code block line up with the second `l` in
-      `Bullet` above.**
+  Indent the content to be the same as the first line of the bullet point.
+  **This paragraph and the code block line up with the first `B` in `Bullet`
+  above.**
 
-      ```bash
-      ls -l
-      ```
+  ```bash
+  ls -l
+  ```
 
-      - And a sub-list after some block-level content
+  - And a sub-list after some block-level content
 
 - A bullet list item can contain a numbered list.
     1.  Numbered sub-list item 1
@@ -116,13 +113,13 @@ mind:
     two consecutive lists. **The HTML comment needs to be at the left margin.**
 2.  Numbered lists can have paragraphs or block elements within them.
 
-      Just indent the content to be one tab stop beyond the text of the bullet
-      point. **This paragraph and the code block line up with the `m` in
-      `Numbered` above.**
+    Just indent the content to be the same as the first line of the bullet
+    point. **This paragraph and the code block line up with the `N` in
+    `Numbered` above.**
 
-      ```bash
-      ls -l
-      ```
+    ```bash
+    ls -l
+    ```
 
     - And a sub-list after some block-level content. This is at the same
       "level" as the paragraph and code block above, despite being indented
@@ -178,13 +175,6 @@ back-ticks (code fences) for code blocks.** This allows you to specify the
 language of the enclosed code, which enables syntax highlighting. It is also more
 predictable than using indentation.
 
-{{< warning >}}
-There is one situation where you need to use indentation for code blocks: when
-the contents of the code block contain lines starting with `-` or `*` characters.
-This is due to
-[blackfriday issue #239](https://github.com/russross/blackfriday/issues/239).
-{{< /warning >}}
-
 ```
 this is a code block created by back-ticks
 ```
@@ -241,7 +231,7 @@ character. The square brackets contain the image's alt text. Try to always use
 alt text so that people using screen readers can get some benefit from the
 image.
 
-![pencil icon](/static/images/pencil.png)
+![pencil icon](/images/pencil.png)
 
 To specify extended attributes, such as width, title, caption, etc, use the
 <a href="https://gohugo.io/content-management/shortcodes/#figure">figure shortcode</a>,
@@ -249,17 +239,17 @@ which is preferred to using a HTML `<img>` tag. Also, if you need the image to
 also be a hyperlink, use the `link` attribute, rather than wrapping the whole
 figure in Markdown link syntax as shown below.
 
-{{< figure src="/static/images/pencil.png" title="Pencil icon" caption="Image used to illustrate the figure shortcode" width="200px" >}}
+{{< figure src="/images/pencil.png" title="Pencil icon" caption="Image used to illustrate the figure shortcode" width="200px" >}}
 
 Even if you choose not to use the figure shortcode, an image can also be a link. This
 time the pencil icon links to the Kubernetes website. Outer square brackets enclose
 the entire image tag, and the link target is in the parentheses at the end.
 
-[![pencil icon](/static/images/pencil.png)](https://kubernetes.io)
+[![pencil icon](/images/pencil.png)](https://kubernetes.io)
 
 You can also use HTML for images, but it is not preferred.
 
-<img src="/static/images/pencil.png" alt="pencil icon" />
+<img src="/images/pencil.png" alt="pencil icon" />
 
 
 ## Tables
diff --git a/content/en/docs/tutorials/clusters/seccomp.md b/content/en/docs/tutorials/clusters/seccomp.md
index 41c0937420..adb3d9c500 100644
--- a/content/en/docs/tutorials/clusters/seccomp.md
+++ b/content/en/docs/tutorials/clusters/seccomp.md
@@ -37,7 +37,7 @@ profiles that give only the necessary privileges to your container processes.
 
 In order to complete all steps in this tutorial, you must install
 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and
-[kubectl](/doc/tasks/tools/install-kubectl/). This tutorial will show examples
+[kubectl](/docs/tasks/tools/install-kubectl/). This tutorial will show examples
 with both alpha (pre-v1.19) and generally available seccomp functionality, so
 make sure that your cluster is [configured
 correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
@@ -365,4 +365,4 @@ The default seccomp profile should provide adequate access for most workloads.
 Additional resources:
 
 * [A Seccomp Overview](https://lwn.net/Articles/656307/)
-* [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/)
\ No newline at end of file
+* [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/)
diff --git a/content/en/docs/tutorials/configuration/configure-java-microservice/_index.md b/content/en/docs/tutorials/configuration/configure-java-microservice/_index.md
new file mode 100755
index 0000000000..8a5bc5d604
--- /dev/null
+++ b/content/en/docs/tutorials/configuration/configure-java-microservice/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Example: Configuring a Java Microservice"
+weight: 10
+---
+
diff --git a/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html b/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
new file mode 100644
index 0000000000..bb926a1d19
--- /dev/null
+++ b/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
@@ -0,0 +1,30 @@
+---
+title: "Interactive Tutorial - Configuring a Java Microservice"
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/9" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+        </div>
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md b/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
new file mode 100644
index 0000000000..dccf214c47
--- /dev/null
+++ b/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
@@ -0,0 +1,39 @@
+---
+title: "Externalizing config using MicroProfile, ConfigMaps and Secrets"
+content_type: tutorial
+weight: 10
+---
+
+<!-- overview -->
+
+In this tutorial you will learn how and why to externalize your microservice’s configuration.  Specifically, you will learn how to use Kubernetes ConfigMaps and Secrets to set environment variables and then consume them using MicroProfile Config.
+
+
+## {{% heading "prerequisites" %}}
+
+### Creating Kubernetes ConfigMaps & Secrets
+There are several ways to set environment variables for a Docker container in Kubernetes, including: Dockerfile, kubernetes.yml, Kubernetes ConfigMaps, and Kubernetes Secrets.  In the tutorial, you will learn how to use the latter two for setting your environment variables whose values will be injected into your microservices.  One of the benefits for using ConfigMaps and Secrets is that they can be re-used across multiple containers, including being assigned to different environment variables for the different containers.
+
+ConfigMaps are API Objects that store non-confidential key-value pairs.  In the Interactive Tutorial you will learn how to use a ConfigMap to store the application's name.  For more information regarding ConfigMaps, you can find the documentation [here](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+
+Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that they're intended for confidential/sensitive information and are stored using Base64 encoding.  This makes secrets the appropriate choice for storing such things as credentials, keys, and tokens, the former of which you'll do in the Interactive Tutorial.  For more information on Secrets, you can find the documentation [here](/docs/concepts/configuration/secret/).
+
+
+### Externalizing Config from Code
+Externalized application configuration is useful because configuration usually changes depending on your environment.  In order to accomplish this, we'll use Java's Contexts and Dependency Injection (CDI) and MicroProfile Config. MicroProfile Config is a feature of MicroProfile, a set of open Java technologies for developing and deploying cloud-native microservices.
+
+CDI provides a standard dependency injection capability enabling an application to be assembled from collaborating, loosely-coupled beans.  MicroProfile Config provides apps and microservices a standard way to obtain config properties from various sources, including the application, runtime, and environment.  Based on the source's defined priority, the properties are automatically combined into a single set of properties that the application can access via an API.  Together, CDI & MicroProfile will be used in the Interactive Tutorial to retrieve the externally provided properties from the Kubernetes ConfigMaps and Secrets and get injected into your application code.
+
+Many open source frameworks and runtimes implement and support MicroProfile Config.  Throughout the interactive tutorial, you'll be using Open Liberty, a flexible open-source Java runtime for building and running cloud-native apps and microservices.  However, any MicroProfile compatible runtime could be used instead. 
+
+
+## {{% heading "objectives" %}}
+
+* Create a Kubernetes ConfigMap and Secret
+* Inject microservice configuration using MicroProfile Config
+
+  
+<!-- lessoncontent -->
+
+## Example: Externalizing config using MicroProfile, ConfigMaps and Secrets
+### [Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) 
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index 901e0063cf..ba115b601c 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -16,24 +16,20 @@ card:
 <!-- overview -->
 
 This tutorial shows you how to run a sample app
-on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda.
+on Kubernetes using minikube and Katacoda.
 Katacoda provides a free, in-browser Kubernetes environment.
 
 {{< note >}}
-You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/).
+You can also follow this tutorial if you've installed minikube locally.
+See [minikube start](https://minikube.sigs.k8s.io/docs/start/) for installation instructions.
 {{< /note >}}
 
-
-
 ## {{% heading "objectives" %}}
 
-
-* Deploy a sample application to Minikube.
+* Deploy a sample application to minikube.
 * Run the app.
 * View application logs.
 
-
-
 ## {{% heading "prerequisites" %}}
 
 
@@ -43,14 +39,14 @@ This tutorial provides a container image that uses NGINX to echo back all the re
 
 <!-- lessoncontent -->
 
-## Create a Minikube cluster
+## Create a minikube cluster
 
 1. Click **Launch Terminal**
 
     {{< kat-button >}}
 
 {{< note >}}
-    If you installed Minikube locally, run `minikube start`.
+If you installed minikube locally, run `minikube start`.
 {{< /note >}}
 
 2. Open the Kubernetes dashboard in a browser:
@@ -136,6 +132,9 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
 
     The `--type=LoadBalancer` flag indicates that you want to expose your Service
     outside of the cluster.
+    
+    The application code inside the image `k8s.gcr.io/echoserver` only listens on TCP port 8080. If you used
+    `kubectl expose` to expose a different port, clients could not connect to that other port.
 
 2. View the Service you just created:
 
@@ -152,7 +151,7 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
     ```
 
     On cloud providers that support load balancers,
-    an external IP address would be provisioned to access the Service. On Minikube,
+    an external IP address would be provisioned to access the Service. On minikube,
     the `LoadBalancer` type makes the Service accessible through the `minikube service`
     command.
 
@@ -170,7 +169,7 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
 
 ## Enable addons
 
-Minikube has a set of built-in {{< glossary_tooltip text="addons" term_id="addons" >}} that can be enabled, disabled and opened in the local Kubernetes environment.
+The minikube tool includes a set of built-in {{< glossary_tooltip text="addons" term_id="addons" >}} that can be enabled, disabled and opened in the local Kubernetes environment.
 
 1. List the currently supported addons:
 
@@ -283,4 +282,3 @@ minikube delete
 * Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/).
 * Learn more about [Service objects](/docs/concepts/services-networking/service/).
 
-
diff --git a/content/en/docs/tutorials/kubernetes-basics/_index.html b/content/en/docs/tutorials/kubernetes-basics/_index.html
index 39204e19de..fe4b7cb9de 100644
--- a/content/en/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/en/docs/tutorials/kubernetes-basics/_index.html
@@ -1,6 +1,7 @@
 ---
 title: Learn Kubernetes Basics
 linkTitle: Learn Kubernetes Basics
+no_list: true
 weight: 10
 card:
   name: tutorials
diff --git a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index 1816442416..ad7b856223 100644
--- a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 The screen is too narrow to interact with the Terminal, please use a desktop/tablet.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
index 13d3d99758..5ac682d7af 100644
--- a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
@@ -72,7 +72,7 @@ weight: 10
         <div class="row">
             <div class="col-md-8">
                 <p><b>The Master is responsible for managing the cluster.</b> The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.</p>
-                <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p>
+                <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p>
 
             </div>
             <div class="col-md-4">
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index fb782458de..ab008c38af 100644
--- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -31,7 +31,7 @@ weight: 20
                 To interact with the Terminal, please use the desktop/tablet version
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index ac23bbf61b..8c87cfab18 100644
--- a/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 To interact with the Terminal, please use the desktop/tablet version
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 9e1605c518..e89414b917 100644
--- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 To interact with the Terminal, please use the desktop/tablet version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css b/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css
index 8c743991d9..a9e2a62009 100644
--- a/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css
+++ b/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css
@@ -8392,46 +8392,6 @@ button.close
     src: url('../fonts/Inconsolata-Bold.eot?#iefix') format('embedded-opentype'), url('../fonts/Inconsolata-Bold.woff2') format('woff2'), url('../fonts/Inconsolata-Bold.woff') format('woff'), url('../fonts/Inconsolata-Bold.ttf') format('truetype'), url('../fonts/Inconsolata-Bold.svg#Inconsolata-Bold') format('svg');
 }
 
-@font-face
-{
-    font-family: 'Roboto Slab';
-    font-weight: normal;
-    font-style: normal;
-
-    src: url('../fonts/RobotoSlab-Regular.eot');
-    src: url('../fonts/RobotoSlab-Regular.eot?#iefix') format('embedded-opentype'), url('../fonts/RobotoSlab-Regular.woff2') format('woff2'), url('../fonts/RobotoSlab-Regular.woff') format('woff'), url('../fonts/RobotoSlab-Regular.ttf') format('truetype'), url('../fonts/RobotoSlab-Regular.svg#RobotoSlab-Regular') format('svg');
-}
-
-@font-face
-{
-    font-family: 'Roboto Slab';
-    font-weight: 100;
-    font-style: normal;
-
-    src: url('../fonts/RobotoSlab-Thin.eot');
-    src: url('../fonts/RobotoSlab-Thin.eot?#iefix') format('embedded-opentype'), url('../fonts/RobotoSlab-Thin.woff2') format('woff2'), url('../fonts/RobotoSlab-Thin.woff') format('woff'), url('../fonts/RobotoSlab-Thin.ttf') format('truetype'), url('../fonts/RobotoSlab-Thin.svg#RobotoSlab-Thin') format('svg');
-}
-
-@font-face
-{
-    font-family: 'Roboto Slab';
-    font-weight: 300;
-    font-style: normal;
-
-    src: url('../fonts/RobotoSlab-Light.eot');
-    src: url('../fonts/RobotoSlab-Light.eot?#iefix') format('embedded-opentype'), url('../fonts/RobotoSlab-Light.woff2') format('woff2'), url('../fonts/RobotoSlab-Light.woff') format('woff'), url('../fonts/RobotoSlab-Light.ttf') format('truetype'), url('../fonts/RobotoSlab-Light.svg#RobotoSlab-Light') format('svg');
-}
-
-@font-face
-{
-    font-family: 'Roboto Slab';
-    font-weight: bold;
-    font-style: normal;
-
-    src: url('../fonts/RobotoSlab-Bold.eot');
-    src: url('../fonts/RobotoSlab-Bold.eot?#iefix') format('embedded-opentype'), url('../fonts/RobotoSlab-Bold.woff2') format('woff2'), url('../fonts/RobotoSlab-Bold.woff') format('woff'), url('../fonts/RobotoSlab-Bold.ttf') format('truetype'), url('../fonts/RobotoSlab-Bold.svg#RobotoSlab-Bold') format('svg');
-}
-
 .layout
 {
     display: -webkit-box;
@@ -8574,7 +8534,7 @@ button.close
 
 .nav
 {
-    font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
+    font-family: 'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
     font-size: 14px;
 
     min-height: 600px;
@@ -9035,7 +8995,7 @@ button.close
 }
 .content__modules .caption h5
 {
-    font-family: Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
+    font-family: 'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
     font-size: 16px;
 }
 
@@ -9075,641 +9035,6 @@ button.close
     max-width: 300px;
 }
 
-/*
-.header
-{
-    padding: 20px 20px;
-
-    background: #fff;
-}
-@media screen and (max-width: 480px)
-{
-    .header
-    {
-        position: relative;
-
-        padding: 10px 20px;
-
-        background: none;
-    }
-}
-
-.header__site
-{
-    font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
-    font-size: 32px;
-    font-weight: bold;
-    line-height: 60px;
-
-    text-decoration: none !important;
-
-    color: #231f20 !important;
-}
-@media screen and (max-width: 480px)
-{
-    .header__site
-    {
-        display: block;
-        overflow: hidden;
-
-        width: 42px;
-    }
-}
-
-.header__logo
-{
-    height: 60px;
-    margin: 0 10px 0 0;
-
-    vertical-align: top;
-}
-@media screen and (max-width: 480px)
-{
-    .header__logo
-    {
-        display: none;
-    }
-}
-
-.header__logo-mobile
-{
-    display: none;
-}
-@media screen and (max-width: 480px)
-{
-    .header__logo-mobile
-    {
-        display: block;
-
-        height: 40px;
-    }
-}
-
-@media screen and (max-width: 480px)
-{
-    .header__name
-    {
-        display: none;
-    }
-}
-
-.header__sider
-{
-    position: absolute;
-    z-index: 1010;
-    top: 15px;
-    right: 20px;
-
-    display: none;
-
-    box-sizing: border-box;
-    width: 30px;
-    height: 30px;
-
-    cursor: pointer;
-
-    -webkit-tap-highlight-color: transparent;
-}
-@media screen and (max-width: 480px)
-{
-    .header__sider
-    {
-        display: block;
-    }
-}
-
-.header__burger
-{
-    position: absolute;
-    top: 50%;
-    left: 0;
-
-    width: 30px;
-    height: 3px;
-    margin: -1px 0 0 0;
-
-    border-radius: 3px;
-    background: #fff;
-}
-.header__burger:before,
-.header__burger:after
-{
-    position: absolute;
-    top: -9px;
-    left: 0;
-
-    width: 100%;
-    height: 3px;
-    margin: -1px 0 0 0;
-
-    content: '';
-    -webkit-transition: .12s linear;
-            transition: .12s linear;
-
-    border-radius: 3px;
-    background: inherit;
-}
-.header__burger:after
-{
-    top: auto;
-    bottom: -10px;
-}
-.page_open .header__burger
-{
-    background: transparent;
-}
-.page_open .header__burger:before
-{
-    top: 0;
-
-    -webkit-transform: rotate(45deg);
-        -ms-transform: rotate(45deg);
-            transform: rotate(45deg);
-
-    background: #326de6;
-}
-.page_open .header__burger:after
-{
-    bottom: 0;
-
-    -webkit-transform: rotate(-45deg);
-        -ms-transform: rotate(-45deg);
-            transform: rotate(-45deg);
-
-    background: #326de6;
-}
-
-.footer
-{
-    font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
-
-    margin: 20px 0 0;
-
-    text-align: left;
-}
-.layout > .footer
-{
-    display: none;
-}
-@media screen and (max-width: 480px)
-{
-    .footer
-    {
-        display: none;
-    }
-    .layout > .footer
-    {
-        display: block;
-
-        padding: 0 0 20px;
-
-        text-align: center;
-
-        background: #326de6;
-    }
-    .footer:before
-    {
-        position: relative;
-
-        display: block;
-
-        height: 15px;
-        margin: 0 0 40px;
-
-        content: '';
-
-        background: -webkit-linear-gradient(45deg, #326de6 0%, #4cffd4 100%);
-        background:         linear-gradient(45deg, #326de6 0%, #4cffd4 100%);
-    }
-}
-
-.footer__content
-{
-    padding: 0 20px;
-}
-
-.footer__social
-{
-    font-size: 32px;
-    line-height: 1;
-
-    width: 60px;
-    margin: 0;
-    padding: 10px 0;
-
-    list-style: none;
-
-    text-align: left;
-
-    border-top: 1px solid rgba(255, 255, 255, .3);
-    border-bottom: 1px solid rgba(255, 255, 255, .3);
-}
-.page_open .footer__social
-{
-    width: auto;
-    padding: 0;
-
-    border: none;
-}
-@media screen and (min-width: 999px)
-{
-    .footer__social
-    {
-        width: auto;
-        padding: 0;
-
-        border: none;
-    }
-}
-@media screen and (max-width: 480px)
-{
-    .footer__social
-    {
-        width: auto;
-        padding: 0;
-
-        text-align: center;
-
-        border: none;
-    }
-}
-@media screen and (min-width: 1000px)
-{
-    .page_desktop_hide .footer__social
-    {
-        width: 60px;
-        padding: 10px 0;
-
-        border-top: 1px solid rgba(255, 255, 255, .3);
-        border-bottom: 1px solid rgba(255, 255, 255, .3);
-    }
-}
-
-.footer__social-item
-{
-    width: 60px;
-    margin: 10px 0;
-
-    text-align: center;
-}
-.page_open .footer__social-item
-{
-    display: inline-block;
-
-    width: auto;
-    margin: 0 20px 0 0;
-
-    text-align: left;
-}
-@media screen and (min-width: 999px)
-{
-    .footer__social-item
-    {
-        display: inline-block;
-
-        width: auto;
-        margin: 0 20px 0 0;
-
-        text-align: left;
-    }
-}
-@media screen and (max-width: 480px)
-{
-    .footer__social-item
-    {
-        display: inline-block;
-
-        width: auto;
-        margin: 0 10px;
-
-        text-align: center;
-    }
-}
-@media screen and (min-width: 1000px)
-{
-    .page_desktop_hide .footer__social-item
-    {
-        width: 60px;
-        margin: 10px 0;
-
-        text-align: center;
-    }
-}
-
-.footer__network
-{
-    display: inline-block;
-
-    text-decoration: none;
-
-    opacity: .7;
-    color: #fff;
-}
-.page_open .footer__network
-{
-    opacity: 1;
-    color: #326de6;
-}
-@media screen and (min-width: 999px)
-{
-    .footer__network
-    {
-        opacity: 1;
-        color: #326de6;
-    }
-}
-@media screen and (max-width: 480px)
-{
-    .footer__network
-    {
-        display: inline-block;
-
-        width: auto;
-        margin: 0 20px 0 0;
-    }
-    .footer__network:hover
-    {
-        opacity: 1;
-        color: #fff;
-    }
-}
-@media screen and (min-width: 1000px)
-{
-    .page_desktop_hide .footer__network
-    {
-        display: inline-block;
-
-        text-decoration: none;
-
-        opacity: .7;
-        color: #fff;
-    }
-}
-
-.footer__menu
-{
-    display: none;
-
-    margin: 20px 0;
-    padding: 10px 0;
-
-    list-style: none;
-
-    border-top: 1px solid rgba(255, 255, 255, .3);
-    border-bottom: 1px solid rgba(255, 255, 255, .3);
-}
-.page_open .footer__menu
-{
-    display: block;
-}
-@media screen and (min-width: 999px)
-{
-    .footer__menu
-    {
-        display: block;
-    }
-}
-@media screen and (max-width: 480px)
-{
-    .footer__menu
-    {
-        display: block;
-
-        padding-bottom: 40px;
-
-        text-align: left;
-
-        border-top: none;
-        border-bottom: 2px solid rgba(255, 255, 255, .3);
-    }
-}
-@media screen and (min-width: 1000px)
-{
-    .page_desktop_hide .footer__menu
-    {
-        display: none;
-    }
-}
-
-.footer__item
-{
-    margin: 10px 0;
-}
-@media screen and (max-width: 480px)
-{
-    .footer__item:before
-    {
-        display: inline;
-
-        margin: 0 5px 0 0;
-
-        content: '›';
-
-        opacity: .7;
-        color: #fff;
-    }
-}
-
-.footer__link
-{
-    color: #273d6d;
-}
-@media screen and (max-width: 480px)
-{
-    .footer__link
-    {
-        opacity: .7;
-        color: #fff;
-    }
-    .footer__link:hover
-    {
-        opacity: 1;
-        color: #fff;
-    }
-}
-
-.footer__copyright
-{
-    font-size: 12px;
-    padding-top: 20px;
-}
-.page_open .footer__copyright
-{
-    display: block;
-}
-@media screen and (min-width: 999px)
-{
-    .footer__copyright
-    {
-        display: block;
-    }
-}
-@media screen and (max-width: 480px)
-{
-    .footer__copyright
-    {
-        display: block;
-
-        color: #fff;
-    }
-    .footer__copyright b
-    {
-        font-size: 16px;
-
-        display: block;
-    }
-}
-@media screen and (min-width: 1000px)
-{
-    .page_desktop_hide .footer__copyright
-    {
-        display: none;
-    }
-}
-*/
-
-/*
-.scrolltop
-{
-    position: fixed;
-    z-index: 300;
-    bottom: -100px;
-    left: 20px;
-
-    display: none;
-
-    width: 56px;
-    height: 56px;
-
-    -webkit-transition: .36s ease-out;
-            transition: .36s ease-out;
-
-    opacity: 0;
-    border: 2px solid #fff;
-    border-radius: 50%;
-    outline: none;
-}
-.scrolltop:before,
-.scrolltop:after
-{
-    position: absolute;
-    top: 23px;
-    left: 4px;
-
-    width: 26px;
-    height: 2px;
-
-    content: '';
-    -webkit-transform: rotate(-45deg);
-        -ms-transform: rotate(-45deg);
-            transform: rotate(-45deg);
-
-    background: #fff;
-}
-.scrolltop:after
-{
-    right: 4px;
-    left: auto;
-
-    -webkit-transform: rotate(45deg);
-        -ms-transform: rotate(45deg);
-            transform: rotate(45deg);
-
-    background: #fff;
-}
-@media screen and (max-width: 992px)
-{
-    .scrolltop
-    {
-        display: block;
-    }
-}
-@media screen and (max-width: 480px)
-{
-    .scrolltop
-    {
-        background: #326de6;
-        background: rgba(50, 109, 230, .5);
-        box-shadow: 0 0 0 1px #326de6;
-    }
-}
-.scrolltop_active
-{
-    bottom: 20px;
-
-    opacity: 1;
-}
-*/
-
-
-/*
-body
-{
-    font-family: Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
-    font-size: 15px;
-    line-height: 1.5;
-
-    min-height: 100vh;
-
-    background: #eee;
-}
-body.page_open
-{
-    overflow: hidden;
-}
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6
-{
-    font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
-}
-
-h1
-{
-    font-size: 36px;
-    font-weight: bold;
-
-    margin-bottom: 20px;
-}
-
-h2,
-h3
-{
-    padding-bottom: 10px;
-
-    border-bottom: 1px solid #ebebec;
-}
-
-h2
-{
-    font-size: 28px;
-}
-
-.title-light
-{
-    border: none;
-}
-
-a
-{
-    color: #326de6;
-}
-
-p a
-{
-    text-decoration: underline;
-}
-p a:hover
-{
-    text-decoration: none;
-}
-*/
-
-
 .breadcrumb
 {
     font-weight: 100;
@@ -9735,12 +9060,6 @@ p a:hover
     content: '|';
 }
 
-/* .btn
-{
-    font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
-
-    border-radius: 0;
-} */
 .btn.btn-success
 {
     color: #273d6d;
@@ -9945,7 +9264,7 @@ p a:hover
 
 .katacoda__alert
 {
-    font-family: Inconsolata, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
+    font-family: Inconsolata, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif;
 
     display: none;
 
diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index 8c6da7c579..77e707c429 100644
--- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 To interact with the Terminal, please use the desktop/tablet version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 37f7cc0fbe..42663ecdaa 100644
--- a/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 To interact with the Terminal, please use the desktop/tablet version
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md
index 9c6edf784f..64073549ef 100644
--- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -1039,7 +1039,7 @@ Even though you completely deleted the StatefulSet, and all of its Pods, the
 Pods are recreated with their PersistentVolumes mounted, and `web-0` and
 `web-1` continue to serve their hostnames.
 
-Finally, delete the `web` StatefulSet...
+Finally, delete the `nginx` Service...
 
 ```shell
 kubectl delete service nginx
@@ -1047,7 +1047,7 @@ kubectl delete service nginx
 ```
 service "nginx" deleted
 ```
-...and the `nginx` Service:
+...and the `web` StatefulSet:
 ```shell
 kubectl delete statefulset web
 ```
diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md
index 6eb5e15dae..5b453f6594 100644
--- a/content/en/docs/tutorials/stateful-application/cassandra.md
+++ b/content/en/docs/tutorials/stateful-application/cassandra.md
@@ -50,7 +50,7 @@ To complete this tutorial, you should already have a basic familiarity with
 ### Additional Minikube setup instructions
 
 {{< caution >}}
-[Minikube](/docs/setup/learning-environment/minikube/) defaults to 1024MiB of memory and 1 CPU.
+[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 1024MiB of memory and 1 CPU.
 Running Minikube with the default resource configuration results in insufficient resource
 errors during this tutorial. To avoid these errors, start Minikube with the following settings:
 
diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md
index eaba068b6f..c044532e5f 100644
--- a/content/en/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/en/docs/tutorials/stateful-application/zookeeper.md
@@ -26,7 +26,7 @@ Kubernetes concepts.
 -   [Pods](/docs/concepts/workloads/pods/)
 -   [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
 -   [Headless Services](/docs/concepts/services-networking/service/#headless-services)
--   [PersistentVolumes](/docs/concepts/storage/volumes/)
+-   [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
 -   [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 -   [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
 -   [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
@@ -46,7 +46,7 @@ tutorial.
 After this tutorial, you will know the following.
 
 -   How to deploy a ZooKeeper ensemble using StatefulSet.
--   How to consistently configure the ensemble using ConfigMaps.
+-   How to consistently configure the ensemble.
 -   How to spread the deployment of ZooKeeper servers in the ensemble.
 -   How to use PodDisruptionBudgets to ensure service availability during planned maintenance.
 
@@ -522,7 +522,7 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
 log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
 ```
 
-This is the simplest possible way to safely log inside the container. 
+This is the simplest possible way to safely log inside the container.
 Because the applications write logs to standard out, Kubernetes will handle log rotation for you.
 Kubernetes also implements a sane retention policy that ensures application logs written to
 standard out and standard error do not exhaust local storage media.
@@ -770,7 +770,7 @@ In one terminal window, use the following command to watch the Pods in the `zk`
 kubectl get pod -w -l app=zk
 ```
 
-In another window, using the following command to delete the `zkOk.sh` script from the file system of Pod `zk-0`.
+In another window, using the following command to delete the `zookeeper-ready` script from the file system of Pod `zk-0`.
 
 ```shell
 kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
diff --git a/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
index 0c4964a17f..d3a38c4df5 100644
--- a/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
+++ b/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
@@ -19,17 +19,14 @@ This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/statele
 * Metricbeat
 * Packetbeat
 
-
-
 ## {{% heading "objectives" %}}
 
 * Start up the PHP Guestbook with Redis.
 * Install kube-state-metrics.
-* Create a Kubernetes secret.
+* Create a Kubernetes Secret.
 * Deploy the Beats.
 * View dashboards of your logs and metrics.
 
-
 ## {{% heading "prerequisites" %}}
 
 
@@ -40,16 +37,18 @@ Additionally you need:
 
 * A running deployment of the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.
 
-* A running Elasticsearch and Kibana deployment.  You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co), run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
-
-
+* A running Elasticsearch and Kibana deployment. You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co),
+  run the [downloaded files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)
+  on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
 
 <!-- lessoncontent -->
 
 ## Start up the  PHP Guestbook with Redis
+
 This tutorial builds on the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.  If you have the guestbook application running, then you can monitor that.  If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps.  Come back to this page when you have the guestbook running.
 
 ## Add a Cluster role binding
+
 Create a [cluster level role binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) so that you can deploy kube-state-metrics and the Beats at the cluster level (in kube-system).
 
 ```shell
@@ -61,38 +60,38 @@ kubectl create clusterrolebinding cluster-admin-binding \
 
 Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics) is a simple service that listens to the Kubernetes API server and generates metrics about the state of the objects.  Metricbeat reports these metrics.  Add kube-state-metrics to the Kubernetes cluster that the guestbook is running in.
 
-### Check to see if kube-state-metrics is running
-```shell
-kubectl get pods --namespace=kube-system | grep kube-state
-```
-### Install kube-state-metrics if needed
-
 ```shell
 git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
 kubectl apply -f kube-state-metrics/examples/standard
-kubectl get pods --namespace=kube-system | grep kube-state-metrics
 ```
-Verify that kube-state-metrics is running and ready
+
+### Check to see if kube-state-metrics is running
+
 ```shell
-kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics
+kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
 ```
 
 Output:
-```shell
+
+```
 NAME                                 READY   STATUS    RESTARTS   AGE
 kube-state-metrics-89d656bf8-vdthm   1/1     Running     0          21s
 ```
+
 ## Clone the Elastic examples GitHub repo
+
 ```shell
 git clone https://github.com/elastic/examples.git
 ```
 
 The rest of the commands will reference files in the `examples/beats-k8s-send-anywhere` directory, so change dir there:
+
 ```shell
 cd examples/beats-k8s-send-anywhere
 ```
 
 ## Create a Kubernetes Secret
+
 A Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}} is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image; putting it in a Secret object allows for more control over how it is used, and reduces the risk of accidental exposure.
 
 {{< note >}}
@@ -103,55 +102,70 @@ There are two sets of steps here, one for *self managed* Elasticsearch and Kiban
 {{% tab name="Self Managed" %}}
 
 ### Self managed
+
 Switch to the **Managed service** tab if you are connecting to Elasticsearch Service in Elastic Cloud.
 
 ### Set the credentials
+
 There are four files to edit to create a k8s secret when you are connecting to self managed Elasticsearch and Kibana (self managed is effectively anything other than the managed Elasticsearch Service in Elastic Cloud).  The files are:
 
-1. ELASTICSEARCH_HOSTS
-1. ELASTICSEARCH_PASSWORD
-1. ELASTICSEARCH_USERNAME
-1. KIBANA_HOST
+1. `ELASTICSEARCH_HOSTS`
+1. `ELASTICSEARCH_PASSWORD`
+1. `ELASTICSEARCH_USERNAME`
+1. `KIBANA_HOST`
 
 Set these with the information for your Elasticsearch cluster and your Kibana host.  Here are some examples (also see [*this configuration*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897))
 
 #### `ELASTICSEARCH_HOSTS`
+
 1. A nodeGroup from the Elastic Elasticsearch Helm Chart:
 
-    ```shell
-    ["http://elasticsearch-master.default.svc.cluster.local:9200"]
-    ```
+   ```
+   ["http://elasticsearch-master.default.svc.cluster.local:9200"]
+   ```
+
 1. A single Elasticsearch node running on a Mac where your Beats are running in Docker for Mac:
 
-    ```shell
-    ["http://host.docker.internal:9200"]
-    ```
+   ```
+   ["http://host.docker.internal:9200"]
+   ```
+
 1. Two Elasticsearch nodes running in VMs or on physical hardware:
 
-    ```shell
-    ["http://host1.example.com:9200", "http://host2.example.com:9200"]
-    ```
-Edit `ELASTICSEARCH_HOSTS`
+   ```
+   ["http://host1.example.com:9200", "http://host2.example.com:9200"]
+   ```
+
+Edit `ELASTICSEARCH_HOSTS`:
+
 ```shell
 vi ELASTICSEARCH_HOSTS
 ```
 
 #### `ELASTICSEARCH_PASSWORD`
-Just the password; no whitespace, quotes, or <>:
 
-    <yoursecretpassword>
+Just the password; no whitespace, quotes, `<` or `>`:
+
+```
+<yoursecretpassword>
+```
+
+Edit `ELASTICSEARCH_PASSWORD`:
 
-Edit `ELASTICSEARCH_PASSWORD`
 ```shell
 vi ELASTICSEARCH_PASSWORD
 ```
 
 #### `ELASTICSEARCH_USERNAME`
-Just the username; no whitespace, quotes, or <>:
 
-    <your ingest username for Elasticsearch>
+Just the username; no whitespace, quotes, `<` or `>`:
+
+```
+<your ingest username for Elasticsearch>
+```
+
+Edit `ELASTICSEARCH_USERNAME`:
 
-Edit `ELASTICSEARCH_USERNAME`
 ```shell
 vi ELASTICSEARCH_USERNAME
 ```
@@ -160,78 +174,98 @@ vi ELASTICSEARCH_USERNAME
 
 1. The Kibana instance from the Elastic Kibana Helm Chart.  The subdomain `default` refers to the default namespace.  If you have deployed the Helm Chart using a different namespace, then your subdomain will be different:
 
-    ```shell
-    "kibana-kibana.default.svc.cluster.local:5601"
-    ```
+   ```
+   "kibana-kibana.default.svc.cluster.local:5601"
+   ```
+
 1. A Kibana instance running on a Mac where your Beats are running in Docker for Mac:
 
-    ```shell
-    "host.docker.internal:5601"
-    ```
+   ```
+   "host.docker.internal:5601"
+   ```
 1. Two Elasticsearch nodes running in VMs or on physical hardware:
 
-    ```shell
-    "host1.example.com:5601"
-    ```
-Edit `KIBANA_HOST`
+   ```
+   "host1.example.com:5601"
+   ```
+
+Edit `KIBANA_HOST`:
+
 ```shell
 vi KIBANA_HOST
 ```
 
-### Create a Kubernetes secret
-This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
+### Create a Kubernetes Secret
 
-    kubectl create secret generic dynamic-logging \
-      --from-file=./ELASTICSEARCH_HOSTS \
-      --from-file=./ELASTICSEARCH_PASSWORD \
-      --from-file=./ELASTICSEARCH_USERNAME \
-      --from-file=./KIBANA_HOST \
-      --namespace=kube-system
+This command creates a Secret in the Kubernetes system level namespace (`kube-system`) based on the files you just edited:
+
+```shell
+kubectl create secret generic dynamic-logging \
+  --from-file=./ELASTICSEARCH_HOSTS \
+  --from-file=./ELASTICSEARCH_PASSWORD \
+  --from-file=./ELASTICSEARCH_USERNAME \
+  --from-file=./KIBANA_HOST \
+  --namespace=kube-system
+```
 
 {{% /tab %}}
 {{% tab name="Managed service" %}}
 
 ## Managed service
-This tab is for Elasticsearch Service in Elastic Cloud only, if you have already created a secret for a self managed Elasticsearch and Kibana deployment, then continue with [Deploy the Beats](#deploy-the-beats).
-### Set the credentials
-There are two files to edit to create a k8s secret when you are connecting to the managed Elasticsearch Service in Elastic Cloud.  The files are:
 
-1. ELASTIC_CLOUD_AUTH
-1. ELASTIC_CLOUD_ID
+This tab is for Elasticsearch Service in Elastic Cloud only, if you have already created a secret for a self managed Elasticsearch and Kibana deployment, then continue with [Deploy the Beats](#deploy-the-beats).
+
+### Set the credentials
+
+There are two files to edit to create a Kubernetes Secret when you are connecting to the managed Elasticsearch Service in Elastic Cloud.  The files are:
+
+1. `ELASTIC_CLOUD_AUTH`
+1. `ELASTIC_CLOUD_ID`
 
 Set these with the information provided to you from the Elasticsearch Service console when you created the deployment.  Here are some examples:
 
-#### ELASTIC_CLOUD_ID
-```shell
+#### `ELASTIC_CLOUD_ID`
+
+```
 devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
 ```
 
-#### ELASTIC_CLOUD_AUTH
+#### `ELASTIC_CLOUD_AUTH`
+
 Just the username, a colon (`:`), and the password, no whitespace or quotes:
-```shell
+
+```
 elastic:VFxJJf9Tjwer90wnfTghsn8w
 ```
 
 ### Edit the required files:
+
 ```shell
 vi ELASTIC_CLOUD_ID
 vi ELASTIC_CLOUD_AUTH
 ```
-### Create a Kubernetes secret
-This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
 
-    kubectl create secret generic dynamic-logging \
-      --from-file=./ELASTIC_CLOUD_ID \
-      --from-file=./ELASTIC_CLOUD_AUTH \
-      --namespace=kube-system
+### Create a Kubernetes Secret
+
+This command creates a Secret in the Kubernetes system level namespace (`kube-system`) based on the files you just edited:
+
+```shell
+kubectl create secret generic dynamic-logging \
+  --from-file=./ELASTIC_CLOUD_ID \
+  --from-file=./ELASTIC_CLOUD_AUTH \
+  --namespace=kube-system
+```
+
+{{% /tab %}}
 
-  {{% /tab %}}
 {{< /tabs >}}
 
 ## Deploy the Beats
+
 Manifest files are provided for each Beat.  These manifest files use the secret created earlier to configure the Beats to connect to your Elasticsearch and Kibana servers.
 
 ### About Filebeat
+
 Filebeat will collect logs from the Kubernetes nodes and the containers running in each pod running on those nodes.  Filebeat is deployed as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.  Filebeat can autodiscover applications running in your Kubernetes cluster. At startup Filebeat scans existing containers and launches the proper configurations for them, then it will watch for new start/stop events.
 
 Here is the autodiscover configuration that enables Filebeat to locate and parse Redis logs from the Redis containers deployed with the guestbook application.  This configuration is in the file `filebeat-kubernetes.yaml`:
@@ -250,20 +284,25 @@ Here is the autodiscover configuration that enables Filebeat to locate and parse
         enabled: true
         var.hosts: ["${data.host}:${data.port}"]
 ```
+
 This configures Filebeat to apply the Filebeat module `redis` when a container is detected with a label `app` containing the string `redis`.  The redis module has the ability to collect the `log` stream from the container by using the docker input type (reading the file on the Kubernetes node associated with the STDOUT stream from this Redis container).  Additionally, the module has the ability to collect Redis `slowlog` entries by connecting to the proper pod host and port, which is provided in the container metadata.
 
 ### Deploy Filebeat:
+
 ```shell
 kubectl create -f filebeat-kubernetes.yaml
 ```
 
 #### Verify
+
 ```shell
 kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
 ```
 
 ### About Metricbeat
+
 Metricbeat autodiscover is configured in the same way as Filebeat.  Here is the Metricbeat autodiscover configuration for the Redis containers.  This configuration is in the file `metricbeat-kubernetes.yaml`:
+
 ```yaml
 - condition.equals:
     kubernetes.labels.tier: backend
@@ -275,22 +314,27 @@ Metricbeat autodiscover is configured in the same way as Filebeat.  Here is the
       # Redis hosts
       hosts: ["${data.host}:${data.port}"]
 ```
+
 This configures Metricbeat to apply the Metricbeat module `redis` when a container is detected with a label `tier` equal to the string `backend`.  The `redis` module has the ability to collect the `info` and `keyspace` metrics from the container by connecting to the proper pod host and port, which is provided in the container metadata.
 
 ### Deploy Metricbeat
+
 ```shell
 kubectl create -f metricbeat-kubernetes.yaml
 ```
+
 #### Verify
+
 ```shell
 kubectl get pods -n kube-system -l k8s-app=metricbeat
 ```
 
 ### About Packetbeat
+
 Packetbeat configuration is different than Filebeat and Metricbeat.  Rather than specify patterns to match against container labels the configuration is based on the protocols and port numbers involved.  Shown below is a subset of the port numbers.
 
 {{< note >}}
-If you are running a service on a non-standard port add that port number to the appropriate type in `filebeat.yaml` and delete / create the Packetbeat DaemonSet.
+If you are running a service on a non-standard port add that port number to the appropriate type in `filebeat.yaml` and delete/create the Packetbeat DaemonSet.
 {{< /note >}}
 
 ```yaml
@@ -317,11 +361,13 @@ packetbeat.flows:
 ```
 
 #### Deploy Packetbeat
+
 ```shell
 kubectl create -f packetbeat-kubernetes.yaml
 ```
 
 #### Verify
+
 ```shell
 kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
 ```
@@ -336,15 +382,17 @@ Similarly, view dashboards for Apache and Redis.  You will see dashboards for lo
 
 To enable Metricbeat to retrieve the Apache metrics, enable server-status by adding a ConfigMap including a mod-status configuration file and re-deploy the guestbook.
 
+## Scale your Deployments and see new pods being monitored
+
+List the existing Deployments:
 
-## Scale your deployments and see new pods being monitored
-List the existing deployments:
 ```shell
 kubectl get deployments
 ```
 
 The output:
-```shell
+
+```
 NAME            READY   UP-TO-DATE   AVAILABLE   AGE
 frontend        3/3     3            3           3h27m
 redis-master    1/1     1            1           3h27m
@@ -352,54 +400,56 @@ redis-slave     2/2     2            2           3h27m
 ```
 
 Scale the frontend down to two pods:
+
 ```shell
 kubectl scale --replicas=2 deployment/frontend
 ```
+
 The output:
-```shell
+
+```
 deployment.extensions/frontend scaled
 ```
+
 Scale the frontend back up to three pods:
+
 ```shell
 kubectl scale --replicas=3 deployment/frontend
 ```
 
 ## View the changes in Kibana
+
 See the screenshot, add the indicated filters and then add the columns to the view.  You can see the ScalingReplicaSet entry that is marked, following from there to the top of the list of events shows the image being pulled, the volumes mounted, the pod starting, etc.
 ![Kibana Discover](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png)
 
-
-
 ## {{% heading "cleanup" %}}
 
 Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command.
 
 1. Run the following commands to delete all Pods, Deployments, and Services.
 
-      ```shell
-      kubectl delete deployment -l app=redis
-      kubectl delete service -l app=redis
-      kubectl delete deployment -l app=guestbook
-      kubectl delete service -l app=guestbook
-      kubectl delete -f filebeat-kubernetes.yaml
-      kubectl delete -f metricbeat-kubernetes.yaml
-      kubectl delete -f packetbeat-kubernetes.yaml
-      kubectl delete secret dynamic-logging -n kube-system
-      ```
+   ```shell
+   kubectl delete deployment -l app=redis
+   kubectl delete service -l app=redis
+   kubectl delete deployment -l app=guestbook
+   kubectl delete service -l app=guestbook
+   kubectl delete -f filebeat-kubernetes.yaml
+   kubectl delete -f metricbeat-kubernetes.yaml
+   kubectl delete -f packetbeat-kubernetes.yaml
+   kubectl delete secret dynamic-logging -n kube-system
+   ```
 
 1. Query the list of Pods to verify that no Pods are running:
 
-      ```shell
-      kubectl get pods
-      ```
-
-      The response should be this:
-
-      ```
-      No resources found.
-      ```
+   ```shell
+   kubectl get pods
+   ```
 
+   The response should be this:
 
+   ```
+   No resources found.
+   ```
 
 ## {{% heading "whatsnext" %}}
 
@@ -407,3 +457,4 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
 * Read more about [logging architecture](/docs/concepts/cluster-administration/logging/)
 * Read more about [application introspection and debugging](/docs/tasks/debug-application-cluster/)
 * Read more about [troubleshoot applications](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+
diff --git a/content/en/examples/access/certificate-signing-request/clusterrole-approve.yaml b/content/en/examples/access/certificate-signing-request/clusterrole-approve.yaml
new file mode 100644
index 0000000000..e5bcfdc44e
--- /dev/null
+++ b/content/en/examples/access/certificate-signing-request/clusterrole-approve.yaml
@@ -0,0 +1,28 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: csr-approver
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests/approval
+  verbs:
+  - update
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - signers
+  resourceNames:
+  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
+  verbs:
+  - approve
+
diff --git a/content/en/examples/access/certificate-signing-request/clusterrole-create.yaml b/content/en/examples/access/certificate-signing-request/clusterrole-create.yaml
new file mode 100644
index 0000000000..def1b879d8
--- /dev/null
+++ b/content/en/examples/access/certificate-signing-request/clusterrole-create.yaml
@@ -0,0 +1,14 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: csr-creator
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests
+  verbs:
+  - create
+  - get
+  - list
+  - watch
diff --git a/content/en/examples/access/certificate-signing-request/clusterrole-sign.yaml b/content/en/examples/access/certificate-signing-request/clusterrole-sign.yaml
new file mode 100644
index 0000000000..29bbc6a9cd
--- /dev/null
+++ b/content/en/examples/access/certificate-signing-request/clusterrole-sign.yaml
@@ -0,0 +1,27 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: csr-signer
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests/status
+  verbs:
+  - update
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - signers
+  resourceName:
+  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
+  verbs:
+  - sign
diff --git a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml
index 6659ff3fbb..c85f25ea51 100644
--- a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml
+++ b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml
@@ -18,4 +18,4 @@ egressSelections:
       # The other supported transport is "tcp". You will need to set up TLS 
       # config to secure the TCP transport.
       uds:
-        udsName: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket
+        udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket
diff --git a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml
index c3dc71040b..3c71999427 100644
--- a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml
+++ b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml
@@ -22,7 +22,7 @@ spec:
         - key: "CriticalAddonsOnly"
           operator: "Exists"
       containers:
-        - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.8
+        - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.12
           name: konnectivity-agent
           command: ["/proxy-agent"]
           args: [
@@ -32,6 +32,8 @@ spec:
                   # this is the IP address of the master machine.
                   "--proxy-server-host=35.225.206.7",
                   "--proxy-server-port=8132",
+                  "--admin-server-port=8133",
+                  "--health-server-port=8134",
                   "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
                   ]
           volumeMounts:
@@ -39,7 +41,7 @@ spec:
               name: konnectivity-agent-token
           livenessProbe:
             httpGet:
-              port: 8093
+              port: 8134
               path: /healthz
             initialDelaySeconds: 15
             timeoutSeconds: 15
diff --git a/content/en/examples/admin/konnectivity/konnectivity-server.yaml b/content/en/examples/admin/konnectivity/konnectivity-server.yaml
index 730c26c66a..a0f45af5ff 100644
--- a/content/en/examples/admin/konnectivity/konnectivity-server.yaml
+++ b/content/en/examples/admin/konnectivity/konnectivity-server.yaml
@@ -8,34 +8,33 @@ spec:
   hostNetwork: true
   containers:
   - name: konnectivity-server-container
-    image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.8
+    image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.12
     command: ["/proxy-server"]
     args: [
-            "--log-file=/var/log/konnectivity-server.log",
-            "--logtostderr=false",
-            "--log-file-max-size=0",
+            "--logtostderr=true",
             # This needs to be consistent with the value set in egressSelectorConfiguration.
-            "--uds-name=/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket",
+            "--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
             # The following two lines assume the Konnectivity server is
             # deployed on the same machine as the apiserver, and the certs and
             # key of the API Server are at the specified location.
-            "--cluster-cert=/etc/srv/kubernetes/pki/apiserver.crt",
-            "--cluster-key=/etc/srv/kubernetes/pki/apiserver.key",
+            "--cluster-cert=/etc/kubernetes/pki/apiserver.crt",
+            "--cluster-key=/etc/kubernetes/pki/apiserver.key",
             # This needs to be consistent with the value set in egressSelectorConfiguration.
             "--mode=grpc",
             "--server-port=0",
             "--agent-port=8132",
             "--admin-port=8133",
+            "--health-port=8134",
             "--agent-namespace=kube-system",
             "--agent-service-account=konnectivity-agent",
-            "--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig",
+            "--kubeconfig=/etc/kubernetes/konnectivity-server.conf",
             "--authentication-audience=system:konnectivity-server"
             ]
     livenessProbe:
       httpGet:
         scheme: HTTP
         host: 127.0.0.1
-        port: 8133
+        port: 8134
         path: /healthz
       initialDelaySeconds: 30
       timeoutSeconds: 60
@@ -46,25 +45,28 @@ spec:
     - name: adminport
       containerPort: 8133
       hostPort: 8133
+    - name: healthport
+      containerPort: 8134
+      hostPort: 8134
     volumeMounts:
-    - name: varlogkonnectivityserver
-      mountPath: /var/log/konnectivity-server.log
-      readOnly: false
-    - name: pki
-      mountPath: /etc/srv/kubernetes/pki
+    - name: k8s-certs
+      mountPath: /etc/kubernetes/pki
+      readOnly: true
+    - name: kubeconfig
+      mountPath: /etc/kubernetes/konnectivity-server.conf
       readOnly: true
     - name: konnectivity-uds
-      mountPath: /etc/srv/kubernetes/konnectivity-server
+      mountPath: /etc/kubernetes/konnectivity-server
       readOnly: false
   volumes:
-  - name: varlogkonnectivityserver
+  - name: k8s-certs
     hostPath:
-      path: /var/log/konnectivity-server.log
+      path: /etc/kubernetes/pki
+  - name: kubeconfig
+    hostPath:
+      path: /etc/kubernetes/konnectivity-server.conf
       type: FileOrCreate
-  - name: pki
-    hostPath:
-      path: /etc/srv/kubernetes/pki
   - name: konnectivity-uds
     hostPath:
-      path: /etc/srv/kubernetes/konnectivity-server
+      path: /etc/kubernetes/konnectivity-server
       type: DirectoryOrCreate
diff --git a/content/en/docs/tasks/administer-cluster/memory-available.sh b/content/en/examples/admin/resource/memory-available.sh
similarity index 100%
rename from content/en/docs/tasks/administer-cluster/memory-available.sh
rename to content/en/examples/admin/resource/memory-available.sh
diff --git a/content/en/examples/application/guestbook/redis-master-service.yaml b/content/en/examples/application/guestbook/redis-master-service.yaml
index a484014f1f..65cef2191c 100644
--- a/content/en/examples/application/guestbook/redis-master-service.yaml
+++ b/content/en/examples/application/guestbook/redis-master-service.yaml
@@ -8,7 +8,8 @@ metadata:
     tier: backend
 spec:
   ports:
-  - port: 6379
+  - name: redis
+    port: 6379
     targetPort: 6379
   selector:
     app: redis
diff --git a/content/en/examples/pods/init-containers.yaml b/content/en/examples/pods/init-containers.yaml
index 35c393d7c7..667b03eccd 100644
--- a/content/en/examples/pods/init-containers.yaml
+++ b/content/en/examples/pods/init-containers.yaml
@@ -19,7 +19,7 @@ spec:
     - wget
     - "-O"
     - "/work-dir/index.html"
-    - http://kubernetes.io
+    - http://info.cern.ch
     volumeMounts:
     - name: workdir
       mountPath: "/work-dir"
diff --git a/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml b/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml
index a72b4335ce..00827ec98a 100644
--- a/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml
+++ b/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml
@@ -6,7 +6,7 @@ spec:
   containers:
     - name: test-container
       image: k8s.gcr.io/busybox
-      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
+      command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
       env:
         - name: SPECIAL_LEVEL_KEY
           valueFrom:
diff --git a/content/en/examples/pods/pod-with-pod-affinity.yaml b/content/en/examples/pods/pod-with-pod-affinity.yaml
index 35e645ef1f..6d075e0860 100644
--- a/content/en/examples/pods/pod-with-pod-affinity.yaml
+++ b/content/en/examples/pods/pod-with-pod-affinity.yaml
@@ -12,7 +12,7 @@ spec:
             operator: In
             values:
             - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
     podAntiAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 100
@@ -23,7 +23,7 @@ spec:
               operator: In
               values:
               - S2
-          topologyKey: failure-domain.beta.kubernetes.io/zone
+          topologyKey: topology.kubernetes.io/zone
   containers:
   - name: with-pod-affinity
     image: k8s.gcr.io/pause:2.0
diff --git a/content/en/examples/service/networking/example-ingress.yaml b/content/en/examples/service/networking/example-ingress.yaml
new file mode 100644
index 0000000000..b309d13275
--- /dev/null
+++ b/content/en/examples/service/networking/example-ingress.yaml
@@ -0,0 +1,18 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: example-ingress
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /$1
+spec:
+  rules:
+    - host: hello-world.info
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: web
+                port:
+                  number: 8080
\ No newline at end of file
diff --git a/content/en/includes/partner-style.css b/content/en/includes/partner-style.css
index 7aeb255dd5..dc120872e0 100644
--- a/content/en/includes/partner-style.css
+++ b/content/en/includes/partner-style.css
@@ -82,7 +82,6 @@
 .button{
   max-width: 100%;
 	box-sizing: border-box;
-	font-family: "Roboto", sans-serif;
 	margin: 0;
 	display: inline-block;
 	border-radius: 6px;
diff --git a/content/en/includes/task-tutorial-prereqs.md b/content/en/includes/task-tutorial-prereqs.md
index d4546bdf62..93195d8b9c 100644
--- a/content/en/includes/task-tutorial-prereqs.md
+++ b/content/en/includes/task-tutorial-prereqs.md
@@ -1,7 +1,7 @@
 You need to have a Kubernetes cluster, and the kubectl command-line tool must
 be configured to communicate with your cluster. If you do not already have a
 cluster, you can create one by using
-[Minikube](/docs/setup/learning-environment/minikube/),
+[minikube](/docs/tasks/tools/#minikube)
 or you can use one of these Kubernetes playgrounds:
 
 * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
diff --git a/content/en/partners/_index.html b/content/en/partners/_index.html
index 7925e03188..80078ae76b 100644
--- a/content/en/partners/_index.html
+++ b/content/en/partners/_index.html
@@ -7,7 +7,6 @@ cid: partners
 ---
 
 <section id="users">
-  <main class="main-section">
     <h5>Kubernetes works with partners to create a strong, vibrant codebase that supports a spectrum of complementary platforms.</h5>
     <div class="col-container">
       <div class="col-nav">
@@ -17,7 +16,7 @@ cid: partners
           </h5>
           <br>Vetted service providers with deep experience helping enterprises successfully adopt Kubernetes.
           <br><br><br>
-          <button class="button" id="kcsp" onclick="updateSrc(this.id)">See KCSP Partners</button>
+          <button class="button landscape-trigger landscape-default" data-landscape-types="kubernetes-certified-service-provider" id="kcsp">See KCSP Partners</button>
           <br><br>Interested in becoming a
           <a href="https://www.cncf.io/certification/kcsp/">KCSP</a>?
         </center>
@@ -28,7 +27,7 @@ cid: partners
             <b>Certified Kubernetes Distributions, Hosted Platforms, and Installers</b>
           </h5>Software conformance ensures that every vendor’s version of Kubernetes supports the required APIs.
           <br><br><br>
-          <button class="button" id="conformance" onclick="updateSrc(this.id)">See Conformance Partners</button>
+          <button class="button landscape-trigger" data-landscape-types="certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer" id="conformance">See Conformance Partners</button>
           <br><br>Interested in becoming
           <a href="https://www.cncf.io/certification/software-conformance/">Kubernetes Certified</a>?
         </center>
@@ -40,57 +39,13 @@ cid: partners
           </h5>
           <br>Vetted training providers who have deep experience in cloud native technology training.
           <br><br><br>
-          <button class="button" id="ktp" onclick="updateSrc(this.id)">See KTP Partners</button>
+          <button class="button landscape-trigger" data-landscape-types="kubernetes-training-partner" id="ktp">See KTP Partners</button>
           <br><br>Interested in becoming a
           <a href="https://www.cncf.io/certification/training/">KTP</a>?
         </center>
       </div>
     </div>
-    <script crossorigin="anonymous" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
-    <script type="text/javascript">
-
-      var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes";
-      var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes";
-      var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes";
-
-      function updateSrc(buttonId) {
-        if (buttonId == "kcsp") {
-          $("#landscape").attr("src", defaultLink);
-          window.location.hash = "#kcsp";
-        }
-        if (buttonId == "conformance") {
-          $("#landscape").attr("src", firstLink);
-          window.location.hash = "#conformance";
-        }
-        if (buttonId == "ktp") {
-          $("#landscape").attr("src", secondLink);
-          window.location.hash = "#ktp";
-        }
-      }
-
-      // Automatically load the correct iframe based on the URL fragment
-      document.addEventListener("DOMContentLoaded", function () {
-        var showContent = "kcsp";
-        if (window.location.hash) {
-          console.log("hash is:", window
-            .location
-            .hash
-            .substring(1));
-          showContent = window
-            .location
-            .hash
-            .substring(1);
-        }
-        updateSrc(showContent);
-      });
-    </script>
-    <body>
-      <div id="frameHolder">
-        <iframe frameborder="0" id="landscape" scrolling="no" src="" style="width: 1px; min-width: 100%" title="CNCF Landscape"></iframe>
-        <script src="https://landscape.cncf.io/iframeResizer.js"></script>
-      </div>
-    </body>
-  </main>
+    {{< cncf-landscape helpers=true >}}
 </section>
 
 <style>
diff --git a/content/en/docs/search.md b/content/en/search.md
similarity index 100%
rename from content/en/docs/search.md
rename to content/en/search.md
diff --git a/content/en/training/_index.html b/content/en/training/_index.html
index 6dc509ff5b..5b94d73bac 100644
--- a/content/en/training/_index.html
+++ b/content/en/training/_index.html
@@ -10,16 +10,19 @@ class: training
 <section class="call-to-action">
   <div class="main-section">
     <div class="call-to-action" id="cta-certification">
-      <div class="logo-certification cta-image cta-image-before" id="logo-cka">
-        <img src="/images/training/kubernetes-cka-white.svg"/>
-      </div>
-      <div class="logo-certification cta-image cta-image-after" id="logo-ckad">
-        <img src="/images/training/kubernetes-ckad-white.svg"/>
-      </div>
       <div class="cta-text">
         <h2>Build your cloud native career</h2>
         <p>Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.</p>
       </div>
+      <div class="logo-certification cta-image" id="logo-cka">
+        <img src="/images/training/kubernetes-cka-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image" id="logo-ckad">
+        <img src="/images/training/kubernetes-ckad-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image" id="logo-cks">
+        <img src="/images/training/kubernetes-cks-white.svg"/>
+      </div>
     </div>
   </div>
 </section>
@@ -74,31 +77,36 @@ class: training
   </div>
 </div>
 
-<section>
+<section id="get-certified">
   <div class="main-section padded">
-    <center>
-        <h2>Get Kubernetes Certified</h2>
-    </center>
+    <h2>Get Kubernetes Certified</h2>
     <div class="col-container">
       <div class="col-nav">
-        <center>
           <h5>
             <b>Certified Kubernetes Application Developer (CKAD)</b>
           </h5>
           <p>The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.</p>
+          <p>A CKAD can define application resources and use core primitives to build, monitor, and troubleshoot scalable applications and tools in Kubernetes.</p>
           <br>
           <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Go to Certification</a>
-        </center>
       </div>
       <div class="col-nav">
-        <center>
           <h5>
             <b>Certified Kubernetes Administrator (CKA)</b>
           </h5>
           <p>The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.</p>
+          <p>A certified Kubernetes administrator has demonstrated the ability to do basic installation as well as configuring and managing production-grade Kubernetes clusters.</p>
           <br>
           <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Go to Certification</a>
-        </center>
+      </div>
+      <div class="col-nav">
+          <h5>
+            <b>Certified Kubernetes Security Specialist (CKS)</b>
+          </h5>
+          <p>The Certified Kubernetes Security Specialist program provides assurance that the holder is comfortable and competent with a broad range of best practices. CKS certification covers skills for securing container-based applications and Kubernetes platforms during build, deployment and runtime.</p>
+          <p><em>Candidates for CKS must hold a current Certified Kubernetes Administrator (CKA) certification to demonstrate they possess sufficient Kubernetes expertise before sitting for the CKS.</em></p>
+          <br>
+          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">Go to Certification</a>
       </div>
     </div>
   </div>
@@ -112,7 +120,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
   </div>
 </div>
diff --git a/content/es/_index.html b/content/es/_index.html
index 8aecd07aaf..af07c0764b 100644
--- a/content/es/_index.html
+++ b/content/es/_index.html
@@ -41,7 +41,6 @@ Kubernetes es código abierto lo que le brinda la libertad de aprovechar su infr
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Ver vídeo</button>
         <br>
         <br>
-        <br>
         <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Asista a la KubeCon en San Diego del 18 al 21 de Nov. 2019</a>
         <br>
         <br>
diff --git a/content/es/docs/concepts/overview/kubernetes-api.md b/content/es/docs/concepts/overview/kubernetes-api.md
new file mode 100644
index 0000000000..25cfe18049
--- /dev/null
+++ b/content/es/docs/concepts/overview/kubernetes-api.md
@@ -0,0 +1,124 @@
+---
+reviewers:
+- raelga
+title: API de Kubernetes
+content_type: concept
+weight: 30
+card:
+  name: concepts
+  weight: 30
+---
+
+<!-- overview -->
+
+Las convenciones globales de la API se describen en el [documento de convenciones de la API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+
+Los endpoints, tipos de recursos y ejemplos se describen en la [Referencia](/es/docs/reference) de la API.
+
+El acceso remoto a la API se discute en el documento [Controlando el acceso a la API](/docs/reference/access-authn-authz/controlling-access/).
+
+La API de Kubernetes sirve como base para el esquema de configuración declarativa del sistema. La herramienta de
+línea de comandos [kubectl](/docs/reference/kubectl/overview/) puede ser usada para crear, actualizar, eliminar y consultar objetos a través de la API.
+
+Kubernetes también almacena el estado de los recursos de la API en forma serializada. Actualmente esto se hace en [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/).
+
+Kubernetes está compuesto, en si mismo, por varios componentes que interactúan a través de su API.
+
+<!-- body -->
+
+## Cambios a la API
+
+En nuestra experiencia, cualquier sistema exitoso necesita crecer y evolucionar al cambiar o emerger nuevos casos de uso. Por lo tanto, esperamos que la API de Kubernetes cambie y crezca continuamente. Dicho esto, nuestro objetivo es no romper la compatibilidad con los clientes ya existentes, por un período de tiempo razonable. En general, podemos esperar que se agreguen nuevos recursos y propiedades con cierta frecuencia. Para eliminar un recurso o propiedad, se requiere seguir la [política de obsolescencia de la API](/docs/reference/using-api/deprecation-policy/).
+
+En el documento de [cambios a la API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md) describimos como cambiar la API y definimos lo que es considerado como un cambio compatible.
+
+## Definiciones OpenAPI y Swagger
+
+Los detalles completos de la API se documentan usando [OpenAPI](https://www.openapis.org/).
+
+A partir de Kubernetes 1.10, el servidor de API de Kubernetes provee una especificación OpenAPI en el endpoint  `/openapi/v2`.
+
+Se puede solicitar un formato en particular utilizando las siguientes cabeceras HTTP:
+
+| Cabecera        | Valores admitidos                                                                                                                                                                  |
+| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Accept          | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (el content-type predeterminado es `application/json` si esta cabecera contiene `*/*` o se omite) |
+| Accept-Encoding | `gzip` (esta cabecera es opcional)                                                                                                                                                 |
+
+Antes de 1.14, los endpoints separados por formato (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)
+servían la especificación OpenAPI en distintos formatos. Estos endpoints se consideran obsoletos y serán removidos en Kubernetes 1.14.
+
+**Ejemplos**:
+
+| Antes de 1.10               | A partir de 1.10                                                                                                 |
+| --------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| GET /swagger.json           | GET /openapi/v2 **Accept**: application/json                                                                     |
+| GET /swagger-2.0.0.pb-v1    | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf                           |
+| GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip |
+
+Kubernetes implementa un formato alternativo de serialización basado en [Protocol Buffer (_Protobuf_)](https://developers.google.com/protocol-buffers/) diseñado principalmente para las comunicaciones dentro del clúster. Este formato está documentado en su [propuesta de diseño](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) y los archivos IDL de cada esquema se encuentran en los paquetes de Go que definen los objetos de la API.
+
+Antes de 1.14, el `apiserver` de Kubernetes ofrecía una API para obtener la especificación [Swagger v1.2](http://swagger.io/) de la API de Kubernetes en `/swaggerapi`. Este endpoint se considera obsoleto y será removido en Kubernetes 1.14.
+
+## Versionado de la API
+
+Para facilitar la eliminación de propiedades o reestructurar la representación de un recurso, Kubernetes soporta múltiples versiones de la API en distintas rutas como `/api/v1` or `/apis/extensions/v1beta1`.
+
+Se versiona a nivel de la API en vez de a nivel de los recursos o propiedades para asegurarnos de que la API presenta una visión clara y consistente de los recursos y el comportamiento del sistema, y para controlar el acceso a las APIs experimentales o que estén terminando su ciclo de vida. Los esquemas de serialización JSON y Protobuf siguen los mismos lineamientos para los cambios, es decir, estas descripciones cubren ambos formatos.
+
+Se ha de tener en cuenta que hay una relación indirecta entre el versionado de la API y el versionado del resto del software. La propuesta de [versionado de la API y releases](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describe esta relación.
+
+Las distintas versiones de la API implican distintos niveles de estabilidad y soporte. El criterio para cada nivel se describe en detalle en la documentación de [Cambios a la API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). A continuación se ofrece un resumen:
+
+- Nivel "alpha":
+  - El nombre de la versión contiene `alpha` (p. ej., `v1alpha1`).
+  - Puede tener muchos errores. Activar esta característica podría exponer errores. Desactivada por defecto.
+  - El soporte para esta característica podría ser eliminado sin previo aviso.
+  - La API podría volverse incompatible en el futuro y sin previo aviso.
+  - Se recomienda su uso solo en clústers efímeros y de prueba ya que hay mayor riesgo de errores y carece de soporte a largo plazo
+- Nivel "beta":
+  - El nombre de la versión contiene `beta` (p. ej., `v2beta3`).
+  - El código ha sido probado. Activar esta característica es seguro. Activada por defecto.
+  - Los detalles de esta característica podrían cambiar, pero se mantendrá el soporte.
+  - El esquema y/o la semántica de un objeto podría volverse incompatible en el futuro. Si esto pasa, se ofrecerán instrucciones para migrar a una nueva versión. Esto podría requerir eliminar, editar o volver a crear objetos. El proceso de edición podría requerir planificación, incluyendo tiempo de inactividad para aplicaciones que usaban esta característica.
+  - No se recomienda para aplicaciones críticas de negocio ya que podría volverse incompatible en futuras versiones. Si tiene múltiples clústeres que pueden actualizarse de forma independiente se podría decidir correr este riesgo.
+  - **Por favor, ¡pruebe las características en fase beta y comparta sus comentarios! Una vez que salgan de la fase beta, sería más difícil hacer cambios.**
+- Nivel estable:
+  - El nombre de la versión es `vX` donde `X` es un entero.
+  - Las versiones estables de las características aparecerán en los siguientes releases.
+
+## Grupos de API
+
+Para que sea más fácil extender la API de Kubernetes, se han creado los [*grupos de API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
+Estos grupos se especifican en una ruta REST y en la propiedad `apiVersion` de un objeto serializado.
+
+Actualmente hay varios grupos de API en uso:
+
+1. El grupo *core* (o *group*) en la ruta REST `/api/v1` y usa `apiVersion: v1`.
+
+2. Los grupos con entidad propia están en la ruta REST `/apis/$NOMBRE_GRUPO/$VERSION` y usan `apiVersion: $NOMBRE_GRUPO/$VERSION`.
+   (p. ej., `apiVersion: batch/v1`).  La lista completa de los grupos soportados está disponible en la [Referencia de la API](/es/docs/reference/).
+
+
+Hay dos rutas soportadas para extender la API con [recursos personalizados](/docs/concepts/api-extension/custom-resources/):
+
+1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
+   es para los usuarios que tengan necesidades CRUD muy básicas.
+2. Los usuarios que necesiten la semántica completa de la API pueden implementar su propio `apiserver`
+   usando el [agregador](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) para hacerlo
+   transparente para los clientes.
+
+## Activar los grupos de API
+
+Ciertos recursos y grupos de API están activados por defecto. Pueden activarse o desactivarse con la opción `--runtime-config` en `apiserver`. `--runtime-config` acepta valores separados por coma. Por ejemplo, para desactivar `batch/v1`, use la opción
+`--runtime-config=batch/v1=false`. Para activar `batch/v2alpha1`, pase la opción `--runtime-config=batch/v2alpha1`.
+Esta opción acepta pares de `clave=valor` separados por coma que describen la configuración operativa del `apiserver`.
+
+**IMPORTANTE:** Activar o desactivar grupos o recursos requiere reiniciar el `apiserver` y el controller-manager para que estos reconozcan los cambios a `--runtime-config`.
+
+## Activar recursos en los grupos
+
+Los `DaemonSets`, `Deployments`, `HorizontalPodAutoscalers`, `Ingresses`, `Jobs` y `ReplicaSets` están activados por defecto.
+
+Se pueden activar otros recursos con la opción `--runtime-config` del `apiserver`. Por ejemplo, como `--runtime-config` acepta valores separados por coma, puede desactivar los Deployments y los Ingress con la opción
+`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`
diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md
index 89563b3b72..17a42882a0 100644
--- a/content/es/docs/concepts/workloads/controllers/deployment.md
+++ b/content/es/docs/concepts/workloads/controllers/deployment.md
@@ -109,7 +109,7 @@ Para ver el estado del Deployment, ejecuta el comando `kubectl rollout status de
 
 ```shell
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 ```
 
 Ejecuta de nuevo el comando `kubectl get deployments` unos segundos más tarde:
@@ -195,7 +195,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 ```
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 ```
 
 Cuando el despliegue funciona, puede que quieras `obtener` el Deployment:
@@ -803,7 +803,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 $ echo $?
 0
 ```
diff --git a/content/es/docs/concepts/workloads/controllers/replicaset.md b/content/es/docs/concepts/workloads/controllers/replicaset.md
index 38bbf847c6..70ba5ac832 100644
--- a/content/es/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/es/docs/concepts/workloads/controllers/replicaset.md
@@ -34,7 +34,7 @@ este será inmediatamente adquirido por dicho ReplicaSet.
 
 ## Cuándo usar un ReplicaSet
 
-Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejeuctando en todo momento. 
+Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejecutando en todo momento. 
 Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y
 proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles.
 Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser
diff --git a/content/es/docs/concepts/workloads/pods/podpreset.md b/content/es/docs/concepts/workloads/pods/podpreset.md
index 87cd6bb83f..d4406f56ea 100644
--- a/content/es/docs/concepts/workloads/pods/podpreset.md
+++ b/content/es/docs/concepts/workloads/pods/podpreset.md
@@ -7,7 +7,9 @@ weight: 50
 ---
 
 <!-- overview -->
-Esta página provee una descripción general de los Pod Presets, los cuales son
+{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
+
+Esta página provee una descripción general de los PodPresets, los cuales son
 los objetos que se utilizan para inyectar cierta información en los Pods en
 el momento de la creación. Esta información puede incluir secretos, volúmenes,
 montajes de volúmenes y variables de entorno.
@@ -17,16 +19,35 @@ montajes de volúmenes y variables de entorno.
 <!-- body -->
 ## Entendiendo los Pod Presets
 
-Un `Pod Preset` es un recurso de la API utilizado para poder inyectar requerimientos
+Un PodPreset es un recurso de la API utilizado para poder inyectar requerimientos
 adicionales de tiempo de ejecución en un Pod en el momento de la creación.
 Se utilizan los [selectores de etiquetas](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
-para especificar los Pods a los que se aplica un Pod Preset determinado.
+para especificar los Pods a los que se aplica un PodPreset determinado.
 
-El uso de un Pod Preset permite a los autores de plantillas de Pods no tener que proporcionar
+El uso de un PodPreset permite a los autores de plantillas de Pods no tener que proporcionar
 explícitamente toda la información de cada Pod. De esta manera, los autores de plantillas de
 Pods que consuman un determinado servicio no tendrán que conocer todos los detalles de ese servicio.
 
-Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
+
+## Habilitando un PodPreset en su clúster
+
+Con el fin de utilizar los Pod Presets en un clúster debe asegurarse de lo siguiente:
+
+1.  Que se ha configurado el tipo de API `settings.k8s.io/v1alpha1/podpreset`. Esto se puede hacer,
+    por ejemplo, incluyendo `settings.k8s.io/v1alpha1=true` como valor de la opción `--runtime-config`
+    en el servidor API. En minikube se debe añadir el flag
+    `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` cuando el clúster
+    se está iniciando.
+2.  Que se ha habilitado el controlador de admisión `PodPreset`. Una forma de hacer esto es incluir
+    `PodPreset` como valor de la opción `--enable-admission-plugins` especificada
+    para el servidor API. En minikube se debe añadir el flag
+
+    ```shell
+    --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+    ```
+
+    cuando el clúster se está iniciando.
+
 
 ## Cómo funciona
 
@@ -46,51 +67,29 @@ Cuando se realiza una solicitud de creación de Pods, el sistema hace lo siguien
    indicar que ha sido modificada por un `PodPreset`. La nota descriptiva presenta la forma
    `podpreset.admission.kubernetes.io/podpreset-<pod-preset name>: "<resource version>"`.
 
-Cada Pod puede ser correspondido por cero o más Pod Presets; y cada `Pod Preset` puede ser
-aplicado a cero o más Pods. Cuando se aplica un `Pod Preset` a una o más Pods, Kubernetes
-modifica la especificación del Pod. Para los cambios a `Env`, `EnvFrom`, y `VolumeMounts`,
+Cada Pod puede ser correspondido por cero o más Pod Presets; y cada `PodPreset` puede ser
+aplicado a cero o más Pods. Cuando se aplica un `PodPreset` a una o más Pods, Kubernetes
+modifica la especificación del Pod. Para los cambios a `env`, `envFrom`, y `volumeMounts`,
 Kubernetes modifica la especificación del Container para todos los Containers en el Pod;
-para los cambios a `Volume`, Kubernetes modifica la especificación del Pod.
+para los cambios a `volumes`, Kubernetes modifica la especificación del Pod.
 
 {{< note >}}
 Un Pod Preset es capaz de modificar los siguientes campos en las especificaciones de un Pod
 en caso de ser necesario:
 - El campo `.spec.containers`.
-- El campo `initContainers` (requiere Kubernetes versión 1.14.0 o posterior).
+- El campo `.spec.initContainers`
 {{< /note >}}
 
 ### Deshabilitar un Pod Preset para un Pod específico
 
 Puede haber casos en los que se desee que un Pod no se vea alterado por ninguna posible
 modificación del Pod Preset. En estos casos, se puede añadir una observación en el Pod
-Spec de la siguiente forma: `podpreset.admission.kubernetes.io/exclude: "true"`.
-
-## Habilitando un Pod Preset
-
-Con el fin de utilizar los Pod Presets en un clúster debe asegurarse de lo siguiente:
-
-1.  Que se ha configurado el tipo de API `settings.k8s.io/v1alpha1/podpreset`. Esto se puede hacer,
-    por ejemplo, incluyendo `settings.k8s.io/v1alpha1=true` como valor de la opción `--runtime-config`
-    en el servidor API. En minikube se debe añadir el flag
-    `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` cuando el clúster
-    se está iniciando.
-2.  Que se ha habilitado el controlador de admisión `PodPreset`. Una forma de hacer esto es incluir
-    `PodPreset` como valor de la opción `--enable-admission-plugins` especificada
-    para el servidor API. En minikube se debe añadir el flag
-
-    ```shell
-    --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
-    ```
-
-    cuando el clúster se está iniciando.
-3.  Que se han definido los Pod Presets mediante la creación de objetos `PodPreset` en el
-    namespace que se utilizará.
-
+`.spec` de la siguiente forma: `podpreset.admission.kubernetes.io/exclude: "true"`.
 
 
 ## {{% heading "whatsnext" %}}
 
 
-* [Inyectando datos en un Pod usando PodPreset](/docs/tasks/inject-data-application/podpreset/)
-
+Ver [Inyectando datos en un Pod usando PodPreset](/docs/tasks/inject-data-application/podpreset/)
 
+Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). 
diff --git a/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index b2f5b453de..a91e00f679 100644
--- a/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Para interactuar con la Terminal, use la versión de escritorio / tableta
             </div>
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="es" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="es" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 269fa5c387..28a2f35a0e 100644
--- a/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -23,7 +23,7 @@ weight: 20
                 Para interactuar con la Terminal, use la versión de escritorio / tableta
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="es" data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="es" data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/fr/docs/concepts/architecture/master-node-communication.md b/content/fr/docs/concepts/architecture/master-node-communication.md
index 23dd1a4b58..c1d1c6e981 100644
--- a/content/fr/docs/concepts/architecture/master-node-communication.md
+++ b/content/fr/docs/concepts/architecture/master-node-communication.md
@@ -16,16 +16,16 @@ L'objectif est de permettre aux utilisateurs de personnaliser leur installation
 
 ## Communication du Cluster vers le Master
 
-Tous les canaux de communication du cluster au master se terminent au apiserver (aucun des autres composants principaux n'est conçu pour exposer des services distants).
+Tous les canaux de communication du cluster au master se terminent à l'apiserver (aucun des autres composants principaux n'est conçu pour exposer des services distants).
 Dans un déploiement typique, l'apiserver est configuré pour écouter les connexions distantes sur un port HTTPS sécurisé (443) avec un ou plusieurs types d'[authentification](/docs/reference/access-authn-authz/authentication/) client.
-Une ou plusieurs formes d'[autorisation](/docs/reference/access-authn-authz/authorization/) devraient être activée, notamment si les [requêtes anonymes](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ou [jeton de compte de service](/docs/reference/access-authn-authz/authentication/#service-account-tokens) sont autorisés.
+Une ou plusieurs formes d'[autorisation](/docs/reference/access-authn-authz/authorization/) devraient être activées, notamment si les [requêtes anonymes](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ou [jeton de compte de service](/docs/reference/access-authn-authz/authentication/#service-account-tokens) sont autorisés.
 
 Le certificat racine public du cluster doit être configuré pour que les nœuds puissent se connecter en toute sécurité à l'apiserver avec des informations d'identification client valides.
 Par exemple, dans un déploiement GKE par défaut, les informations d'identification client fournies au kubelet sont sous la forme d'un certificat client.
 Consultez [amorçage TLS de kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) pour le provisioning automatisé des certificats de client Kubelet.
 
 Les pods qui souhaitent se connecter à l'apiserver peuvent le faire de manière sécurisée en utilisant un compte de service afin que Kubernetes injecte automatiquement le certificat racine public et un jeton de support valide dans le pod lorsqu'il est instancié.
-Le service `kubernetes` (dans tous les namespaces) est configuré avec une adresse IP virtuelle redirigée (via kube-proxy) vers le point de terminaison HTTPS sur le apiserver.
+Le service `kubernetes` (dans tous les namespaces) est configuré avec une adresse IP virtuelle redirigée (via kube-proxy) vers le point de terminaison HTTPS sur l'apiserver.
 
 Les composants du master communiquent également avec l'apiserver du cluster via le port sécurisé.
 
@@ -48,11 +48,11 @@ Les connexions de l'apiserver au kubelet sont utilisées pour:
 Ces connexions se terminent au point de terminaison HTTPS du kubelet.
 Par défaut, l'apiserver ne vérifie pas le certificat du kubelet, ce qui rend la connexion sujette aux attaques de type "man-in-the-middle", et **non sûre** sur des réseaux non approuvés et/ou publics.
 
-Pour vérifier cette connexion, utilisez l'argument `--kubelet-certificate-authority` pour fournir à apiserver un ensemble de certificats racine à utiliser pour vérifier le certificat du kubelet.
+Pour vérifier cette connexion, utilisez l'argument `--kubelet-certificate-authority` pour fournir à l'apiserver un ensemble de certificats racine à utiliser pour vérifier le certificat du kubelet.
 
 Si ce n'est pas possible, utilisez [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) entre l'apiserver et le kubelet si nécessaire pour éviter la connexion sur un réseau non sécurisé ou public.
 
-Finalement, l'[authentification et/ou autorisation du Kubelet](/docs/admin/kubelet-authentication-authorization/) devrait être activé pour sécuriser l'API kubelet.
+Finalement, l'[authentification et/ou autorisation du Kubelet](/docs/admin/kubelet-authentication-authorization/) devrait être activée pour sécuriser l'API kubelet.
 
 ### apiserver vers nodes, pods et services
 
diff --git a/content/fr/docs/concepts/cluster-administration/logging.md b/content/fr/docs/concepts/cluster-administration/logging.md
index b6384efe47..465ec742b1 100644
--- a/content/fr/docs/concepts/cluster-administration/logging.md
+++ b/content/fr/docs/concepts/cluster-administration/logging.md
@@ -12,18 +12,18 @@ weight: 60
 La journalisation des évènements systèmes et d'applications peut aider à
 comprendre ce qui se passe dans un cluster. Les journaux sont particulièrement
 utiles pour débogguer les problèmes et surveiller l'activité du cluster. La
-plupart des application modernes ont un mécanisme de journalisation
+plupart des applications modernes ont un mécanisme de journalisation
 d'évènements, et la plupart des environnements d'exécution de conteneurs ont été
 conçus pour supporter la journalisation des évènements. La méthode de
 journalisation la plus facile et la plus répandue pour des applications
 conteneurisées est d'écrire dans les flux de sortie standard et d'erreur
-standard (`stdout` et `stderr`).
+(`stdout` et `stderr`).
 
 Malgré cela, la fonctionnalité de journalisation fournie nativement par
 l'environnement d'exécution de conteneurs n'est pas suffisante comme solution
-complète de journalisation. Quand un conteneur crash, quand un Pod est expulsé
+complète de journalisation. Quand un conteneur crashe, quand un Pod est expulsé
 ou quand un nœud disparaît, il est utile de pouvoir accéder au journal
-d'événement de l'application. C'est pourquoi les journaux doivent avoir leur
+d'événements de l'application. C'est pourquoi les journaux doivent avoir leur
 propre espace de stockage et un cycle de vie indépendamment des nœuds, Pods ou
 conteneurs. Ce concept est appelé _journalisation des évènements au niveau du
 cluster_ (cluster-level-logging). Un backend dédié pour stocker, analyser et
@@ -92,15 +92,15 @@ logs`] (/docs/reference/generated/kubectl/kubectl-commands#logs)
 nœud](/images/docs/user-guide/logging/logging-node-level.png)
 
 Tout ce qu'une application conteneurisée écrit sur `stdout` ou `stderr` est pris
-en compte et redirigé par l'environment d'exécution des conteneurs. Par exemple,
-Docker redirige ces deux flux à un [driver de journalisation
+en compte et redirigé par l'environnement d'exécution des conteneurs. Par exemple,
+Docker redirige ces deux flux vers un [driver de journalisation
 (EN)](https://docs.docker.com/config/containers/logging/configure/) qui est
 configuré dans Kubernetes pour écrire dans un fichier au format json.
 
 {{< note >}} Le driver json de Docker traite chaque ligne comme un message
 différent. Avec ce driver il n'y a pas de support direct pour des messages
 multi-lignes. Il faut donc traiter les messages multi-lignes au niveau de
-l'agent de journalisation ou plus haut. {{< /note >}}
+l'agent de journalisation ou plus en amont encore. {{< /note >}}
 
 Par défaut quand un conteneur redémarre, le kubelet ne conserve le journal que
 du dernier conteneur terminé. Quand un Pod est expulsé d'un nœud, tous ses
@@ -119,11 +119,11 @@ l'environnement d'exécution des conteneurs pour que la rotation des journaux
 s'exécute automatiquement, e.g. en utilisant le paramètre `log-opt` de Docker.
 Dans le script `kube-up.sh`, c'est cette méthode qui est utilisée pour des
 images COS sur GCP et sinon c'est la première méthode dans tous les autres cas.
-Quel que soit la méthode choisie par `kube-up.sh` la rotation est configurée par
-defaut quand la taille d'un journal atteint 10 Mo.
+Quelle que soit la méthode choisie par `kube-up.sh` la rotation est configurée par
+défaut quand la taille d'un journal atteint 10 Mo.
 
 Ce [script][cosConfigureHelper] montre de manière détaillée comment `kube-up.sh`
-met en place la journalisation d'évènement pour des images COS sur GCP.
+met en place la journalisation d'évènements pour des images COS sur GCP.
 
 Quand [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)
 s'exécute comme dans le premier exemple de journalisation simple le kubelet du
@@ -147,10 +147,10 @@ conteneur ou pas.
 Par exemple :
 
 * Le scheduler Kubernetes et kube-proxy s'exécutent dans un conteneur.
-* Kubelet et l'environment d'exécution de conteneurs, comme par exemple
+* Kubelet et l'environnement d'exécution de conteneurs, comme par exemple
 Docker, ne s'exécutent pas dans un conteneur.
 
-Sur les systèmes avec systemd, kubelet et l'environment d'exécution de
+Sur les systèmes avec systemd, kubelet et l'environnement d'exécution de
 conteneurs écrivent dans journald. Si systemd n'est pas présent, ils écrivent
 dans un fichier `.log` dans le répertoire `/var/log`.
 
@@ -198,7 +198,7 @@ le nœud. Ces deux dernières options sont obsolètes et fortement découragées
 Utiliser un agent de journalisation au niveau du nœud est l'approche la plus
 commune et recommandée pour un cluster Kubernetes parce qu'un seul agent par
 nœud est créé et qu'aucune modification dans l'application n'est nécessaire.
-Mais cette approche _ne fonctionne correctement que pour les flux standard de
+Mais cette approche _ne fonctionne correctement que pour les flux standards de
 sortie et d'erreurs des applications_.
 
 Kubernetes ne définit pas d'agent de journalisation, mais deux agents de
@@ -288,13 +288,13 @@ Notez que bien que la consommation en CPU et mémoire soit faible ( de l'ordre d
 quelques milicores pour la CPU et quelques mégaoctets pour la mémoire),  ecrire
 les évènements dans un fichier et les envoyer ensuite dans `stdout` peut doubler
 l'espace disque utilisé. Quand une application écrit dans un seul fichier de
-journal il est préférable de configurer `/dev/stdout` comme destination plutôt
+journal, il est préférable de configurer `/dev/stdout` comme destination plutôt
 que d'implémenter un conteneur side-car diffusant.
 
 Les conteneurs side-car peuvent être utilisés pour faire la rotation des
-journaux quand l'application n'en est pas capable elle même. Un exemple serait
+journaux quand l'application n'en est pas capable elle-même. Un exemple serait
 un petit conteneur side-car qui effectuerait cette rotation périodiquement.
-Toutefois il est recommandé d'utiliser `stdout` et `stderr` directement et de
+Toutefois, il est recommandé d'utiliser `stdout` et `stderr` directement et de
 laisser la rotation et les politiques de rétentions au kubelet.
 
 ### Conteneur side-car avec un agent de journalisation
@@ -303,13 +303,13 @@ laisser la rotation et les politiques de rétentions au kubelet.
 journalisation](/images/docs/user-guide/logging/logging-with-sidecar-agent.png)
 
 Quand un agent de journalisation au niveau du nœud n'est pas assez flexible pour
-votre utilisation vous pouvez créer un conteneur side-car avec un agent de
+votre utilisation, vous pouvez créer un conteneur side-car avec un agent de
 journalisation séparé que vous avez configuré spécialement pour qu'il s'exécute
 avec votre application.
 
 {{< note >}}
 Utiliser un agent de journalisation dans un conteneur side-car peut entraîner
-une consommation de ressource significative. De plus vous n'avez plus accès aux
+une consommation de ressources significative. De plus vous n'avez plus accès aux
 journaux avec la commande `kubectl` parce qu'ils ne sont plus gérés par
 kubelet.
 {{< /note >}}
@@ -355,4 +355,3 @@ Toutefois l'implémentation de ce mécanisme de journalisation est hors du cadre
 de Kubernetes.
 
 
-
diff --git a/content/fr/docs/concepts/configuration/secret.md b/content/fr/docs/concepts/configuration/secret.md
index 79b9e2e533..1b7cd5314b 100644
--- a/content/fr/docs/concepts/configuration/secret.md
+++ b/content/fr/docs/concepts/configuration/secret.md
@@ -217,7 +217,7 @@ type: Opaque
 data:
   username: YWRtaW4=
 stringData:
-  username: administrator
+  username: administrateur
 ```
 
 Donnera le secret suivant:
@@ -233,10 +233,10 @@ metadata:
   uid: 91460ecb-e917-11e8-98f2-025000000001
 type: Opaque
 data:
-  username: YWRtaW5pc3RyYXRvcg==
+  username: YWRtaW5pc3RyYXRldXI=
 ```
 
-Où `YWRtaW5pc3RyYXRvcg ==` décode en `administrateur`.
+Où `YWRtaW5pc3RyYXRldXI=` décode en `administrateur`.
 
 Les clés de `data` et `stringData` doivent être composées de caractères alphanumériques, '-', '_' ou '.'.
 
diff --git a/content/fr/docs/concepts/overview/what-is-kubernetes.md b/content/fr/docs/concepts/overview/what-is-kubernetes.md
index e71283aadf..07a6c738d8 100644
--- a/content/fr/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/fr/docs/concepts/overview/what-is-kubernetes.md
@@ -13,19 +13,19 @@ Cette page est une vue d'ensemble de Kubernetes.
 
 
 <!-- body -->
-Kubernetes est une plate-forme open-source extensible et portable pour la gestion de charges de travail (workloads) et des services conteneurisés.
+Kubernetes est une plate-forme open-source extensible et portable pour la gestion de charges de travail (workloads) et de services conteneurisés.
 Elle favorise à la fois l'écriture de configuration déclarative (declarative configuration) et l'automatisation.
 C'est un large écosystème en rapide expansion.
 Les services, le support et les outils Kubernetes sont largement disponibles.
 
 Google a rendu open-source le projet Kubernetes en 2014.
-Le développement de Kubernetes est basé sur une [décennie et demie d’expérience de Google avec la gestion de la charge et de la mise à l'échelle (scale) en production](https://research.google.com/pubs/pub43438.html), associé aux meilleures idées et pratiques de la communauté.
+Le développement de Kubernetes est basé sur une [décennie et demie d’expérience de Google avec la gestion de la charge et de la mise à l'échelle (scale) en production](https://research.google.com/pubs/pub43438.html), associée aux meilleures idées et pratiques de la communauté.
 
 ## Pourquoi ai-je besoin de Kubernetes et que peut-il faire ?
 
 Kubernetes a un certain nombre de fonctionnalités. Il peut être considéré comme:
 
-- une plate-forme de conteneur
+- une plate-forme de conteneurs
 - une plate-forme de microservices
 - une plate-forme cloud portable
 et beaucoup plus.
@@ -46,7 +46,7 @@ C'est pourquoi Kubernetes a également été conçu pour servir de plate-forme e
 
 De plus, le [plan de contrôle Kubernetes (control
 plane)](/docs/concepts/overview/components/) est construit sur les mêmes [APIs](/docs/reference/using-api/api-overview/) que celles accessibles aux développeurs et utilisateurs.
-Les utilisateurs peuvent écrire leurs propres controlleurs (controllers), tels que les [ordonnanceurs (schedulers)](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md),
+Les utilisateurs peuvent écrire leurs propres contrôleurs (controllers), tels que les [ordonnanceurs (schedulers)](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md),
 avec [leurs propres APIs](/docs/concepts/api-extension/custom-resources/) qui peuvent être utilisés par un [outil en ligne de commande](/docs/user-guide/kubectl-overview/).
 
 Ce choix de [conception](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) a permis de construire un ensemble d'autres systèmes par dessus Kubernetes.
@@ -60,8 +60,8 @@ Ces implémentations par défaut sont optionnelles et interchangeables. Kubernet
 
 Kubernetes:
 
-- Ne limite pas les types d'applications supportées. Kubernetes prend en charge des workloads extrêmement divers, dont des applications stateless, stateful ou orientées traitement de données (data-processing).
-Si l'application peut fonctionner dans un conteneur, elle devrait bien fonctionner sur Kubernetes.
+- Ne limite pas les types d'applications supportées. Kubernetes prend en charge des workloads extrêmement diverses, dont des applications stateless, stateful ou orientées traitement de données (data-processing).
+Si l'application peut fonctionner dans un conteneur, elle devrait fonctionner correctement sur Kubernetes.
 - Ne déploie pas de code source et ne build pas d'application non plus. Les workflows d'Intégration Continue, de Livraison Continue et de Déploiement Continu (CI/CD) sont réalisés en fonction de la culture d'entreprise, des préférences ou des pré-requis techniques.
 - Ne fournit pas nativement de services au niveau applicatif tels que des middlewares (e.g., message buses), des frameworks de traitement de données (par exemple, Spark), des bases de données (e.g., mysql), caches, ou systèmes de stockage clusterisés (e.g., Ceph).
 Ces composants peuvent être lancés dans Kubernetes et/ou être accessibles à des applications tournant dans Kubernetes via des mécaniques d'intermédiation tel que Open Service Broker.
@@ -72,11 +72,11 @@ Il fournit une API déclarative qui peut être ciblée par n'importe quelle form
 - Ne fournit ou n'adopte aucune mécanique de configuration des machines, de maintenance, de gestion ou de contrôle de la santé des systèmes.
 
 De plus, Kubernetes n'est pas vraiment un _système d'orchestration_. En réalité, il élimine le besoin d'orchestration.
-Techniquement, l'_orchestration_ se définie par l'exécution d'un workflow défini : premièrement faire A, puis B, puis C.
-Kubernetes quant à lui est composé d'un ensemble de processus de contrôle qui pilote l'état courant vers l'état désiré.
+Techniquement, l'_orchestration_ se définit par l'exécution d'un workflow spécifié : premièrement faire A, puis B, puis C.
+Kubernetes quant à lui est composé d'un ensemble de processus de contrôle qui pilotent l'état courant vers l'état désiré.
 Peu importe comment on arrive du point A au point C.
 Un contrôle centralisé n'est pas non plus requis.
-Cela abouti à un système plus simple à utiliser et plus puissant, robuste, résiliant et extensible.
+Cela aboutit à un système plus simple à utiliser et plus puissant, robuste, résiliant et extensible.
 
 ## Pourquoi les conteneurs ?
 
@@ -91,23 +91,23 @@ Il est bien entendu possible de construire une image de machine virtuelle (VM) i
 La _nouvelle façon (new way)_ consiste à déployer des conteneurs basés sur une virtualisation au niveau du système d'opération (operation-system-level) plutôt que de la virtualisation hardware.
 Ces conteneurs sont isolés les uns des autres et de l'hôte :
 ils ont leurs propres systèmes de fichiers, ne peuvent voir que leurs propres processus et leur usage des ressources peut être contraint.
-Ils sont aussi plus facile à construire que des VMs, et vu qu'ils sont décorrélés de l'infrastructure sous-jacente et du système de fichiers de l'hôte, ils sont aussi portables entre les différents fournisseurs de Cloud et les OS.
+Ils sont aussi plus faciles à construire que des VMs, et vu qu'ils sont décorrélés de l'infrastructure sous-jacente et du système de fichiers de l'hôte, ils sont aussi portables entre les différents fournisseurs de Cloud et les OS.
 
-Étant donné que les conteneurs sont petits et rapides, une application peut être packagées dans chaque image de conteneurs.
-Cette relation application-image tout-en-un permet de bénéficier de tous les bénéfices des conteneurs. Avec les conteneurs, des images immuables de conteneur peuvent être créées au moment du build/release plutôt qu'au déploiement, vu que chaque application ne dépend pas du reste de la stack applicative et n'est pas liée à l'environnement de production.
+Étant donné que les conteneurs sont petits et rapides, une application peut être packagée dans chaque image de conteneurs.
+Cette relation application-image tout-en-un permet de bénéficier de tous les bénéfices des conteneurs. Avec les conteneurs, des images immuables de conteneurs peuvent être créées au moment du build/release plutôt qu'au déploiement, vu que chaque application ne dépend pas du reste de la stack applicative et n'est pas liée à l'environnement de production.
 La génération d'images de conteneurs au moment du build permet d'obtenir un environnement constant qui peut être déployé tant en développement qu'en production. De la même manière, les conteneurs sont bien plus transparents que les VMs, ce qui facilite le monitoring et le management.
 Cela est particulièrement vrai lorsque le cycle de vie des conteneurs est géré par l'infrastructure plutôt que caché par un gestionnaire de processus à l'intérieur du conteneur. Avec une application par conteneur, gérer ces conteneurs équivaut à gérer le déploiement de son application.
 
 Résumé des bénéfices des conteneurs :
 
-- **Création et déploiement agile d'application** :
-  Augmente la simplicité et l'efficacité de la création d'images par rapport à l'utilisation d'image de VM.
+- **Création et déploiement agile d'applications** :
+  Augmente la simplicité et l'efficacité de la création d'images par rapport à l'utilisation d'images de VM.
 - **Développement, intégration et déploiement Continus**:
-  Fournit un processus pour constuire et déployer fréquemment et de façon fiable avec la capacité de faire des rollbacks rapide et simple (grâce à l'immuabilité de l'image).
+  Fournit un processus pour constuire et déployer fréquemment et de façon fiable avec la capacité de faire des rollbacks rapides et simples (grâce à l'immuabilité de l'image).
 - **Séparation des besoins entre Dev et Ops**:
   Création d'images applicatives au moment du build plutôt qu'au déploiement, tout en séparant l'application de l'infrastructure.
 - **Observabilité**
-  Pas seulement des informations venant du système d'exploitation sous-jacent mais aussi des signaux propres de l'application.
+  Informations venant non seulement du système d'exploitation sous-jacent mais aussi des signaux propres de l'application.
 - **Consistance entre les environnements de développement, tests et production**:
   Fonctionne de la même manière que ce soit sur un poste local que chez un fournisseur d'hébergement / dans le Cloud.
 - **Portabilité entre Cloud et distribution système**:
@@ -115,15 +115,15 @@ Résumé des bénéfices des conteneurs :
 - **Gestion centrée Application**:
   Bascule le niveau d'abstraction d'une virtualisation hardware liée à l'OS à une logique de ressources orientée application.
 - **[Micro-services](https://martinfowler.com/articles/microservices.html) faiblement couplés, distribués, élastiques**:
-  Les applications sont séparées en petits morceaux indépendants et peuvent être déployés et gérés dynamiquement -- pas une stack monolithique dans une seule machine à tout faire.
+  Les applications sont séparées en petits morceaux indépendants et peuvent être déployées et gérées dynamiquement -- pas une stack monolithique dans une seule machine à tout faire.
 - **Isolation des ressources**:
-  Performances de l'application prédictible.
+  Performances de l'application prédictibles.
 - **Utilisation des ressources**:
   Haute efficacité et densité.
 
 ## Qu'est-ce-que Kubernetes signifie ? K8s ?
 
-Le nom **Kubernetes** tire son origine du grec ancien, signifiant _capitaine_ ou _pilôte_ et est la racine de _gouverneur_ et [cybernetic](http://www.etymonline.com/index.php?term=cybernetics). _K8s_ est l'abréviation dérivée par le remplacement des 8 lettres "ubernete" par "8".
+Le nom **Kubernetes** tire son origine du grec ancien, signifiant _capitaine_ ou _pilote_ et est la racine de _gouverneur_ et [cybernetic](http://www.etymonline.com/index.php?term=cybernetics). _K8s_ est l'abbréviation dérivée par le remplacement des 8 lettres "ubernete" par "8".
 
 
 
diff --git a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md
index 90229676b0..87aae45e7a 100644
--- a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md
@@ -6,8 +6,8 @@ weight: 30
 
 <!-- overview -->
 
-Kubernetes prend en charge plusieurs clusters virtuels presents sur le même cluster physique.
-Ces clusters virtuels sont appelés namespaces (espaces de noms en français).
+Kubernetes prend en charge plusieurs clusters virtuels présents sur le même cluster physique.
+Ces clusters virtuels sont appelés namespaces (espaces de nommage en français).
 
 <!-- body -->
 
@@ -38,7 +38,7 @@ La création et la suppression des namespaces sont décrites dans la [Documentat
 
 ### Affichage des namespaces
 
-Dans un cluster vous pouvez lister les namespaces actuels à l'aide de:
+Dans un cluster vous pouvez lister les namespaces actuels à l'aide de :
 
 ```shell
 kubectl get namespace
@@ -54,7 +54,7 @@ kube-system       Active   1d
 
 Kubernetes démarre avec quatre namespaces initiaux:
 
-- `default` Le namespace par défaut pour les objets sans autre namespace
+- `default` Le namespace par défaut pour les objets sans mention d'autre namespace
 - `kube-system` Le namespace pour les objets créés par Kubernetes lui-même
 - `kube-public` Ce namespace est créé automatiquement et est visible par tous les utilisateurs (y compris ceux qui ne sont pas authentifiés). Ce namespace est principalement réservé à l'utilisation du cluster, au cas où certaines ressources devraient être disponibles publiquement dans l'ensemble du cluster. L'aspect public de ce namespace n'est qu'une convention, pas une exigence.
 - `kube-node-lease` Ce namespace contient les objets de bail associés à chaque nœud, ce qui améliore les performances des pulsations du nœud à mesure que le cluster évolue.
@@ -85,15 +85,15 @@ kubectl config view --minify | grep namespace:
 Lorsque vous créez un [Service](/fr/docs/concepts/services-networking/service/), il crée une [entrée DNS](/fr/docs/concepts/services-networking/dns-pod-service/) correspondante.
 Cette entrée est de la forme `<nom-service>.<nom-namespace>.svc.cluster.local`, ce qui signifie
 que si un conteneur utilise simplement `<nom-service>`, il résoudra le service qui
-est local à un namespace. Ceci est utile pour utiliser la même configuration pour
+est local à son namespace. Ceci est utile pour utiliser la même configuration pour
 plusieurs namespaces tels que le Développement, la Qualification et la Production. Si vous voulez naviguer
-entre plusieurs namespaces, vous devez utiliser le nom de domaine complet (FQDN ou nom de domaine complet en français).
+entre plusieurs namespaces, vous devez utiliser le nom de domaine complet (FQDN ou nom de domaine complètement qualifié en français).
 
 ## Tous les objets ne se trouvent pas dans un namespace
 
 La plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication et autres) sont
 dans des namespaces. Cependant, les ressources de type namespace ne sont pas elles-mêmes dans un namespace.
-Et les ressources de bas niveau, telles que les [noeuds](/docs/admin/node) et les volumes persistants, ne se trouvent dans aucun namespace.
+Et les ressources de bas niveau, telles que les [nœuds](/docs/admin/node) et les volumes persistants, ne se trouvent dans aucun namespace.
 
 Pour voir quelles ressources Kubernetes sont et ne sont pas dans un namespace:
 
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index f019b1f0fe..f5b157bc01 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -25,7 +25,7 @@ _EndpointSlices_ offrent une méthode simple pour suivre les Endpoints d'un rés
 
 Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de Endpoints. 
 Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié. 
-Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspond aux selecteur de Service. 
+Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspondent aux selecteurs de Service. 
 EndpointSlices groupent ensemble les Endpoints d'un réseau par combinaisons uniques de Services et de Ports.
 
 Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
@@ -53,8 +53,8 @@ endpoints:
       topology.kubernetes.io/zone: us-west2-a
 ```
 
-Les EndpointSlices géré par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun. 
-En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire.
+Les EndpointSlices gérés par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun. 
+En dessous de cette échelle, EndpointSlices devraient mapper 1:1 les Endpoints et les Services et devraientt avoir une performance similaire.
 
 EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand il s'agit du routage d'un trafic interne. 
 Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'Endpoints.
@@ -65,51 +65,51 @@ Les EndpointSlices supportent 3 types d'addresses:
 
 * IPv4
 * IPv6
-* FQDN (Fully Qualified Domain Name) - [serveur entièrement nommé]
+* FQDN (Fully Qualified Domain Name) - [nom de domaine entièrement qualifié]
 
 ### Topologie
 
 Chaque Endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes. 
-Ceci est utilisé pour indiqué où se trouve un Endpoint, qui contient les informations sur le Node, zone et region correspondante. Lorsque les valeurs sont disponibles, les labels de Topologies suivantes seront définies par le contrôleur EndpointSlice:
+Ceci est utilisé pour indiquer où se trouve un Endpoint, qui contient les informations sur le Node, zone et région correspondantes. Lorsque les valeurs sont disponibles, les labels de Topologies suivants seront définis par le contrôleur EndpointSlice:
 
 * `kubernetes.io/hostname` - Nom du Node sur lequel l'Endpoint se situe.
 * `topology.kubernetes.io/zone` - Zone dans laquelle l'Endpoint se situe.
-* `topology.kubernetes.io/region` - Region dans laquelle l'Endpoint se situe.
+* `topology.kubernetes.io/region` - Région dans laquelle l'Endpoint se situe.
 
 Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que leurs correspondances avec les EndpointSlices sont à jour. 
-Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélecteur - [référence: {{< glossary_tooltip text="sélecteur" term_id="selector" >}}] - specifié. Celles-ci représenteront les IPs des Pods qui correspond au sélecteur.
+Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélecteur - [référence: {{< glossary_tooltip text="sélecteur" term_id="selector" >}}] - specifié. Celles-ci représenteront les IPs des Pods qui correspondent au sélecteur.
 
 ### Capacité d'EndpointSlices
 
-Les EndpointSlices sont limités a une capacité de 100 Endpoints chacun, par défaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
+Les EndpointSlices sont limités à une capacité de 100 Endpoints chacun, par défaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
 
 ### Distribution d'EndpointSlices
 
 Chaque EndpointSlice a un ensemble de ports qui s'applique à tous les Endpoints dans la resource. 
-Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices. 
+Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents ports cibles pour le même port nommé, nécessitant différents EndpointSlices. 
 
-Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
+Le contrôleur essaie de remplir les EndpointSlices aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
 
-1. Itérer à travers les EnpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changés.
+1. Itérer à travers les EnpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changé.
 2. Itérer à travers les EndpointSlices qui ont été modifiés dans la première étape et les remplir avec n'importe quel Endpoint nécéssaire.
-3. S'il reste encore des Endpoints neufs à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouveaux.
+3. S'il reste encore des Endpoints nouveaux à ajouter, essayez de les mettre dans une slice qui n'a pas été changée et/ou en créer une nouvelle.
 
-Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants. 
-C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
+Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, s'il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants. 
+C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlices.
 
 Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement d'un EndpointSlice devient relativement coûteux puisqu'ils seront transmis à chaque Node du cluster. 
 Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut causer plusieurs EndpointSlices non remplis.
 
-En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petite pour tenir dans un EndpointSlice existant, et sinon, un nouveau EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également une compaction naturelle des EndpointSlices avec tous leurs pods et les Endpoints correspondants qui se feront remplacer.
+En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice seront suffisamment petits pour tenir dans un EndpointSlice existant, et sinon, un nouveau EndpointSlice aurait probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également une compaction naturelle des EndpointSlices avec tous leurs pods et les Endpoints correspondants qui se feront remplacer.
 
 ## Motivation
 
 L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints dans Kubernetes. 
-Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles. 
-Plus particulièrement, ceux-ci comprenaient des limitations liés au dimensionnement vers un plus grand nombre d'Endpoint d'un réseau.
+Malheureusement, comme les clusters Kubernetes et Services sont devenus plus grands, les limitations de cette API sont devenues plus visibles. 
+Plus particulièrement, celles-ci comprennent des limitations liées au dimensionnement vers un plus grand nombre d'Endpoints d'un réseau.
 
 Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. 
-Cela a affecté les performances des composants Kubernetes (notamment le plan de contrôle) et a causé une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent. 
+Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et cause une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent. 
 Les EndpointSlices aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique. 
 
 
diff --git a/content/fr/docs/concepts/services-networking/ingress.md b/content/fr/docs/concepts/services-networking/ingress.md
index 8be9ea32bf..81018b3ede 100644
--- a/content/fr/docs/concepts/services-networking/ingress.md
+++ b/content/fr/docs/concepts/services-networking/ingress.md
@@ -22,12 +22,12 @@ Un Ingress peut fournir un équilibrage de charge, une terminaison TLS et un hé
 Par souci de clarté, ce guide définit les termes suivants :
 
 * Nœud (Node) : une seule machine virtuelle ou physique dans un cluster Kubernetes.
-* Cluster : groupe de nœuds protégés par un pare-feu provenant d'Internet et constituant les principales ressources de calcul gérées par Kubernetes.
+* Cluster : groupe de nœuds protégés par un pare-feu du trafic provenant d'Internet et constituant les principales ressources de calcul gérées par Kubernetes.
 * Routeur Edge : routeur appliquant la stratégie de pare-feu pour votre cluster. Il peut s’agir d’une passerelle gérée par un fournisseur de cloud ou d’un matériel physique.
 * Réseau de cluster : ensemble de liens, logiques ou physiques, facilitant la communication au sein d'un cluster selon le [modèle de réseau Kubernetes](/docs/concepts/cluster-administration/networking/).
 * Service : un Kubernetes [Service](/docs/concepts/services-networking/service/) identifiant un ensemble de pods à l'aide de sélecteurs d'étiquettes. Sauf indication contraire, les services sont supposés avoir des adresses IP virtuelles routables uniquement dans le réseau du cluster.
 
-## Qu'est-ce qu'un ingress ?
+## Qu'est-ce qu'un Ingress ?
 
 Ingress (ou une entrée réseau), ajouté à Kubernetes v1.1, expose les routes HTTP et HTTPS de l'extérieur du cluster à des
 {{<link text = "services" url = "/docs/concepts/services-networking/service/">}} au sein du cluster.
@@ -41,7 +41,7 @@ Le routage du trafic est contrôlé par des règles définies sur la ressource I
    [ Services ]
 ```
 
-Un Ingress peut être configuré pour donner aux services des URLs accessibles de l'extérieur, du trafic de charge équilibrée, la terminaison SSL/TLS et un hébergement virtuel basé sur le nom. Un [contrôleur d'Ingress](/docs/concepts/services-networking/ingress-controllers) est responsable de l'exécution de l'Ingress, généralement avec un load-balancer (équilibreur de charge), bien qu'il puisse également configurer votre routeur périphérique ou des interfaces supplémentaires pour aider à gérer le trafic.
+Un Ingress peut être configuré pour donner aux services des URLs accessibles de l'extérieur, un équilibrage du trafic de charge externe, la terminaison SSL/TLS et un hébergement virtuel basé sur le nom. Un [contrôleur d'Ingress](/docs/concepts/services-networking/ingress-controllers) est responsable de l'exécution de l'Ingress, généralement avec un load-balancer (équilibreur de charge), bien qu'il puisse également configurer votre routeur périphérique ou des interfaces supplémentaires pour aider à gérer le trafic.
 
 Un Ingress n'expose pas de ports ni de protocoles arbitraires. Exposer des services autres que HTTP et HTTPS à Internet généralement utilise un service de type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) ou [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
 
@@ -52,7 +52,7 @@ Un Ingress n'expose pas de ports ni de protocoles arbitraires. Exposer des servi
 Avant de commencer à utiliser un Ingress, vous devez comprendre certaines choses. Un Ingress est une ressource en "version Beta".
 
 {{< note >}}
-Vous devez avoir un [contrôleur d'Ingress](/docs/concepts/services-networking/ingress-controllers) pour lancer un Ingress. Seule la création d'une ressource Ingress n'a aucun effet.
+Vous devez avoir un [contrôleur d'Ingress](/docs/concepts/services-networking/ingress-controllers) pour lancer un Ingress. Seule, la création d'une ressource Ingress n'a aucun effet.
 {{< /note >}}
 
 GCE/GKE (Google Cloud Engine / Google Kubernetes Engine) déploie un contrôleur d’Ingress sur le master (le maître de kubernetes). Revoir les [limitations beta](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations) de ce contrôleur si vous utilisez GCE/GKE.
@@ -64,7 +64,7 @@ Dans les environnements autres que GCE/GKE, vous devrez peut-être [déployer un
 Dans l’idéal, tous les contrôleurs d’Ingress devraient correspondre à cette spécification. Cependant le fonctionnement est légèrement différent d'un contrôleur à un autre (en fonction de son implémentation).
 
 {{< note >}}
-Assurez-vous de consulter la documentation de votre contrôleur d’Ingress pour bien comprendre les mises en garde qu’il ya à faire pour le choisir.
+Assurez-vous de consulter la documentation de votre contrôleur d’Ingress pour bien comprendre les mises en garde à prendre en compte au moment de le choisir.
 {{< /note >}}
 
 ## La ressource Ingress
@@ -72,7 +72,7 @@ Assurez-vous de consulter la documentation de votre contrôleur d’Ingress pour
 Exemple de ressource Ingress minimale :
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: test-ingress
@@ -83,19 +83,22 @@ spec:
   - http:
       paths:
       - path: /testpath
+        pathType: Prefix
         backend:
-          serviceName: test
-          servicePort: 80
+          service:
+            name: test
+            port:
+              number: 80
 ```
 
-Comme pour toutes les autres ressources Kubernetes, un ingress (une entrée) a besoin des champs `apiVersion`,` kind` et `metadata`.
+Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`,` kind` et `metadata`.
  Pour des informations générales sur l'utilisation des fichiers de configuration, voir [déployer des applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configurer des conteneurs](/docs/tasks/configure-pod-container/configure-pod-configmap/), [gestion des ressources](/docs/concepts/cluster-administration/manage-deployment/).
  Ingress utilise fréquemment des annotations pour configurer certaines options en fonction du contrôleur Ingress, dont un exemple
  est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
- Différents [Ingress controller](/docs/concepts/services-networking/ingress-controllers) prennent en charge différentes annotations. Consultez la documentation de votre choix de contrôleur Ingress pour savoir quelles annotations sont prises en charge.
+ Différents [Ingress controller](/docs/concepts/services-networking/ingress-controllers) prennent en charge différentes annotations. Consultez la documentation du contrôleur Ingress de votre choix pour savoir quelles annotations sont prises en charge.
 
 La [spécification de la ressource Ingress](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il
-contient une liste de règles appariées à toutes les demandes entrantes. La ressource ingress ne supporte que les règles pour diriger le trafic HTTP.
+contient une liste de règles d'appariement de toutes les demandes entrantes. La ressource Ingress ne supporte que les règles pour diriger le trafic HTTP.
 
 
 ### Ingress rules
@@ -105,11 +108,11 @@ Chaque règle http contient les informations suivantes :
 * Un hôte optionnel. Dans cet exemple, aucun hôte n'est spécifié. La règle s'applique donc à tous les appels entrants.
   Le trafic HTTP via l'adresse IP est spécifié. Si un hôte est fourni (par exemple,
   foo.bar.com), les règles s’appliquent à cet hôte.
-* une liste de chemins (par exemple, /testpath), chacun étant associé à un backend associé défini par un `serviceName` et `servicePort`. L’hôte et le chemin doivent correspondre au contenu d’une demande entrante avant que le load-balancer dirige le trafic vers le service référencé.
+* une liste de chemins (par exemple, /testpath), chacun étant associé à un backend associé défini par un `serviceName` et `servicePort`. L’hôte et le chemin doivent correspondre au contenu d’une demande entrante avant que le load-balancer ne dirige le trafic vers le service référencé.
 * Un backend est une combinaison de noms de services et de ports, comme décrit dans
-  [services doc](/docs/concepts/services-networking/service/). Les requêtes HTTP (et HTTPS) envoyées à l'Ingress correspondant aux hôtes et au chemin de la règle seront envoyées au backend indiqué.
+  [services doc](/docs/concepts/services-networking/service/). Les requêtes HTTP (et HTTPS) envoyées à l'Ingress correspondant à l'hôte et au chemin de la règle seront envoyées au backend indiqué.
 
-Un backend par défaut est souvent configuré dans un contrôleur d’Ingress qui traite toutes les demandes qui ne corresponds à aucun chemin dans la spécification.
+Un backend par défaut est souvent configuré dans un contrôleur d’Ingress qui traite toutes les demandes qui ne correspondent à aucun chemin dans la spécification.
 
 ### Backend par défaut
 
@@ -122,18 +125,20 @@ Si aucun des hôtes ou chemins ne correspond à la demande HTTP dans les objets
 ### Ingress pour service unique
 
 Il existe des concepts Kubernetes qui vous permettent d’exposer un seul service.
-(voir [alternatives](#alternatives)). Vous pouvez également le faire avec un ingress en spécifiant un *backend par défaut* sans règles.
+(voir [alternatives](#alternatives)). Vous pouvez également le faire avec un Ingress en spécifiant un *backend par défaut* sans règles.
 
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: test-ingress
 spec:
-  backend:
-    serviceName: testsvc
-    servicePort: 80
+  defaultBackend:
+    service:
+      name: testsvc
+      port:
+        number: 80
 ```
 
 Si vous le créez en utilisant `kubectl create -f`, vous devriez voir :
@@ -156,7 +161,7 @@ Jusque-là, vous verrez souvent l’adresse listée sous la forme `<pending>` (e
 
 ### Fanout simple
 
-Une configuration d'un fanout achemine le trafic d'une adresse IP unique vers plusieurs services, en se basant sur l'URI HTTP demandé. Une entrée vous permet de garder le nombre de loadbalancers au minimum. Par exemple, une configuration comme :
+Une configuration de type fanout achemine le trafic d'une adresse IP unique vers plusieurs services, en se basant sur l'URI HTTP demandée. Une entrée vous permet de garder le nombre de loadbalancers au minimum. Par exemple, une configuration comme :
 
 ```shell
 foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
@@ -166,7 +171,7 @@ foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
 ceci nécessitera un Ingress défini comme suit :
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: simple-fanout-example
@@ -178,13 +183,19 @@ spec:
     http:
       paths:
       - path: /foo
+        pathType: Prefix
         backend:
-          serviceName: service1
-          servicePort: 4200
+          service:
+            name: service1
+            port:
+              number: 4200
       - path: /bar
+        pathType: Prefix
         backend:
-          serviceName: service2
-          servicePort: 8080
+          service:
+            name: service2
+            port:
+              number: 8080
 ```
 
 Lorsque vous créez l'ingress avec `kubectl create -f`:
@@ -212,17 +223,17 @@ Events:
   Normal   ADD     22s                loadbalancer-controller  default/test
 ```
 
-Le contrôleur d’ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`,` s2`) existent.
+Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`,` s2`) existent.
 Lorsque cela est fait, vous pouvez voir l’adresse du load-balancer sur le champ d'adresse.
 
 {{< note >}}
-En fonction du [Contrôleur d'ingress](/docs/concepts/services-networking/ingress-controllers) vous utilisez, vous devrez peut-être
+En fonction du [Contrôleur d'ingress](/docs/concepts/services-networking/ingress-controllers) que vous utilisez, vous devrez peut-être
 créer un backend http par défaut [Service](/docs/concepts/services-networking/service/).
 {{< /note >}}
 
 ### Hébergement virtuel basé sur le nom
 
-Les hôtes virtuels basés sur des noms prennent en charge le routage du trafic HTTP vers plusieurs noms d'hôte à la même adresse IP.
+Les hôtes virtuels basés sur des noms prennent en charge le routage du trafic HTTP vers plusieurs noms d'hôte basés sur la même adresse IP.
 
 ```none
 foo.bar.com --|                 |-> foo.bar.com s1:80
@@ -230,10 +241,10 @@ foo.bar.com --|                 |-> foo.bar.com s1:80
 bar.foo.com --|                 |-> bar.foo.com s2:80
 ```
 
-L’ingress suivant indique au load-balancer de router les requêtes en fonction de [En-tête du hôte](https://tools.ietf.org/html/rfc7230#section-5.4).
+L’Ingress suivant indique au load-balancer de router les requêtes en fonction de [En-tête du hôte](https://tools.ietf.org/html/rfc7230#section-5.4).
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: name-virtual-host-ingress
@@ -242,21 +253,29 @@ spec:
   - host: foo.bar.com
     http:
       paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
   - host: bar.foo.com
     http:
       paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
 ```
 
 Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1` `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: name-virtual-host-ingress
@@ -265,25 +284,37 @@ spec:
   - host: first.bar.com
     http:
       paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
   - host: second.foo.com
     http:
       paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
   - http:
       paths:
-      - backend:
-          serviceName: service3
-          servicePort: 80
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service3
+            port:
+              number: 80
 ```
 
 ### TLS
 
-Vous pouvez sécuriser un ingress en définissant un [secret](/docs/concepts/configuration/secret) qui contient une clé privée et un certificat TLS. Actuellement, l'ingress prend seulement en charge un seul port TLS, 443, et suppose une terminaison TLS. Si la section de configuration TLS dans un ingress spécifie différents hôtes, ils seront multiplexés sur le même port en fonction du nom d’hôte spécifié via l'extension SNI TLS (à condition que le contrôleur d’Ingress prenne en charge SNI). Le secret de TLS doit contenir les clés `tls.crt` et `tls.key` contenant le certificat et clé privée à utiliser pour TLS, par exemple :
+Vous pouvez sécuriser un Ingress en définissant un [secret](/docs/concepts/configuration/secret) qui contient une clé privée et un certificat TLS. Actuellement, l'Ingress prend seulement en charge l'unique port TLS, 443, et suppose une terminaison TLS. Si la section de configuration TLS dans un Ingress spécifie différents hôtes, ils seront multiplexés sur le même port en fonction du nom d’hôte spécifié via l'extension SNI TLS (à condition que le contrôleur d’Ingress prenne en charge SNI). Le secret de TLS doit contenir les clés `tls.crt` et `tls.key` contenant le certificat et clé privée à utiliser pour TLS, par exemple :
 
 ```yaml
 apiVersion: v1
@@ -297,10 +328,10 @@ metadata:
 type: kubernetes.io/tls
 ```
 
-Référencer ce secret dans un ingress indiquera au contrôleur d'ingress de sécuriser le canal du client au load-balancer à l'aide de TLS. Vous devez vous assurer que le secret TLS que vous avez créé provenait d'un certificat contenant un CN pour `sslexample.foo.com`.
+Référencer ce secret dans un Ingress indiquera au contrôleur d'ingress de sécuriser le canal du client au load-balancer à l'aide de TLS. Vous devez vous assurer que le secret TLS que vous avez créé provenait d'un certificat contenant un CN pour `sslexample.foo.com`.
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: tls-example-ingress
@@ -314,9 +345,12 @@ spec:
       http:
         paths:
         - path: /
+          pathType: Prefix
           backend:
-            serviceName: service1
-            servicePort: 80
+            service:
+              name: service1
+              port:
+                number: 80
 ```
 
 {{< note >}}
@@ -329,14 +363,14 @@ ou tout autre contrôleur d’Ingress spécifique à la plate-forme pour compren
 ### L'équilibrage de charge
 
 Un contrôleur d’Ingress est démarré avec certains paramètres de politique d’équilibrage de charge
-qui s'applique à toutes les entrées, telles que l'algorithme d'équilibrage de la charge, régime de pondérations des backends, et d'autres.
-Les concepts un peu plus avancés d'équilibrage de charge  (p. ex. sessions persistantes, pondérations dynamiques) ne sont pas encore exposés pour l'ingress. Vous pouvez toujours obtenir ces fonctionnalités via le [service loadbalancer](https://github.com/kubernetes/ingress-nginx).
+qui s'appliquent à toutes les entrées, tels que l'algorithme d'équilibrage de la charge, le régime de pondérations des backends, et d'autres.
+Les concepts un peu plus avancés d'équilibrage de charge  (p. ex. sessions persistantes, pondérations dynamiques) ne sont pas encore exposés pour l'Ingress. Vous pouvez toujours obtenir ces fonctionnalités via le [service loadbalancer](https://github.com/kubernetes/ingress-nginx).
 
-Il est également intéressant de noter que même si les health checks (contrôles de santé) ne sont pas exposés directement via l'Ingress, il existe des concepts parallèles dans Kubernetes, tels que [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) qui vous permettent d'obtenir le même résultat final. Veuillez consulter les documents spécifiques au contrôleur pour voir comment ils gèrent les health checks. ([nginx](https://git.k8s.io/ingress-nginx/README.md),[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
+Il est également intéressant de noter que même si les health checks (contrôles de santé) ne sont pas exposés directement via l'Ingress, il existe des concepts parallèles dans Kubernetes, tels que [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) qui vous permettent d'obtenir le même résultat final. Veuillez consulter les documents spécifiques au contrôleur pour voir comment il gère les health checks. ([nginx](https://git.k8s.io/ingress-nginx/README.md),[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
 
-## Mise à jour d'un ingress
+## Mise à jour d'un Ingress
 
-Pour mettre à jour un ingress existant afin d'ajouter un nouvel hôte, vous pouvez le mettre à jour en modifiant la ressource :
+Pour mettre à jour un Ingress existant afin d'ajouter un nouvel hôte, vous pouvez le mettre à jour en modifiant la ressource :
 
 ```shell
 kubectl describe ingress test
@@ -373,20 +407,26 @@ spec:
     http:
       paths:
       - backend:
-          serviceName: s1
-          servicePort: 80
+          service:
+            name: s1
+            port:
+              number: 80
         path: /foo
+        pathType: Prefix
   - host: bar.baz.com
     http:
       paths:
       - backend:
-          serviceName: s2
-          servicePort: 80
+          service:
+            name: s2
+            port:
+              number: 80
         path: /foo
+        pathType: Prefix
 ..
 ```
 
-L'enregistrement du yaml mettra à jour la ressource dans le serveur d'API, ce qui devrait indiquer au contrôleur d'ingress de reconfigurer le load-balancer.
+L'enregistrement du yaml mettra à jour la ressource dans le serveur d'API, ce qui devrait indiquer au contrôleur d'Ingress de reconfigurer le load-balancer.
 
 ```shell
 kubectl describe ingress test
@@ -416,12 +456,12 @@ Vous pouvez obtenir le même résultat en appelant `kubectl replace -f` sur un f
 
 ## Échec dans les zones de disponibilité
 
-Les techniques permettant de répartir le trafic sur plusieurs domaines de défaillance qui diffère d'un fournisseur de cloud à l'autre.
+Les techniques permettant de répartir le trafic sur plusieurs domaines de défaillance diffèrent d'un fournisseur de cloud à l'autre.
 Veuillez consulter la documentation du [Contrôleur d'ingress](/docs/concepts/services-networking/ingress-controllers) pour plus de détails. Vous pouvez également vous référer à la [documentation de la fédération](/docs/concepts/cluster-administration/federation/) pour plus d'informations sur le déploiement d'Ingress dans un cluster fédéré.
 
 ## Travail futur
 
-Suivez [SIG network](https://github.com/kubernetes/community/tree/master/sig-network) (groupe d'intérêt spécial Réseau) pour plus de détails sur l'évolution de l'entrée et des ressources associées. Vous pouvez également suivre le [Dépôt Ingress](https://github.com/kubernetes/ingress/tree/master) pour plus de détails sur l'évolution des différents contrôleurs d’ingress.
+Suivez [SIG network](https://github.com/kubernetes/community/tree/master/sig-network) (groupe d'intérêt spécial Réseau) pour plus de détails sur l'évolution de l'Ingress et des ressources associées. Vous pouvez également suivre le [Dépôt Ingress](https://github.com/kubernetes/ingress/tree/master) pour plus de détails sur l'évolution des différents contrôleurs d’Ingress.
 
 ## Alternatives
 
diff --git a/content/fr/docs/concepts/storage/persistent-volumes.md b/content/fr/docs/concepts/storage/persistent-volumes.md
index e1a1701fcb..1f149bb6e5 100644
--- a/content/fr/docs/concepts/storage/persistent-volumes.md
+++ b/content/fr/docs/concepts/storage/persistent-volumes.md
@@ -411,7 +411,7 @@ Un PV sans `storageClassName` n'a pas de classe et ne peut être lié qu'à des
 Dans le passé, l'annotation `volume.beta.kubernetes.io/storage-class` a été utilisé à la place de l'attribut `storageClassName`.
 Cette annotation fonctionne toujours; cependant, il deviendra complètement obsolète dans une future version de Kubernetes.
 
-### Politique de récupration
+### Politique de récupération
 
 Les politiques de récupération actuelles sont:
 
diff --git a/content/fr/docs/concepts/workloads/controllers/deployment.md b/content/fr/docs/concepts/workloads/controllers/deployment.md
index e8034cc9ad..e12c3ffbab 100644
--- a/content/fr/docs/concepts/workloads/controllers/deployment.md
+++ b/content/fr/docs/concepts/workloads/controllers/deployment.md
@@ -116,7 +116,7 @@ Avant de commencer, assurez-vous que votre cluster Kubernetes est opérationnel.
 
    ```shell
    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-   deployment.apps/nginx-deployment successfully rolled out
+   deployment "nginx-deployment" successfully rolled out
    ```
 
 1. Exécutez à nouveau `kubectl get deployments` quelques secondes plus tard.
@@ -223,7 +223,7 @@ Suivez les étapes ci-dessous pour mettre à jour votre déploiement:
     ou
 
     ```text
-    deployment.apps/nginx-deployment successfully rolled out
+    deployment "nginx-deployment" successfully rolled out
     ```
 
 Obtenez plus de détails sur votre déploiement mis à jour:
@@ -932,7 +932,7 @@ La sortie est similaire à ceci:
 
 ```text
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 $ echo $?
 0
 ```
diff --git a/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
new file mode 100644
index 0000000000..d1cd1f41e1
--- /dev/null
+++ b/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -0,0 +1,240 @@
+---
+title: Contraintes de propagation de topologie pour les Pods
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+Vous pouvez utiliser des  _contraintes de propagation de topologie_ pour contrôler comment les {{< glossary_tooltip text="Pods" term_id="Pod" >}} sont propagés à travers votre cluster parmi les domaines de défaillance comme les régions, zones, noeuds et autres domaines de topologie définis par l'utilisateur. Ceci peut aider à mettre en place de la haute disponibilité et à utiliser efficacement les ressources.
+
+
+
+<!-- body -->
+
+## Conditions préalables
+
+### Autoriser la Feature Gate
+
+La [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `EvenPodsSpread`  doit être autorisée pour
+{{< glossary_tooltip text="l'API Server" term_id="kube-apiserver" >}} **et** le
+{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}.
+
+### Labels de noeuds
+
+Les contraintes de propagation de topologie reposent sur les labels de noeuds pour identifier le ou les domaines de topologie dans lesquels se trouve  chacun des noeuds. Par exemple, un noeud pourrait avoir les labels: `node=node1,zone=us-east-1a,region=us-east-1`
+
+Supposons que vous ayez un cluster de 4 noeuds ayant les labels suivants:
+
+```
+NAME    STATUS   ROLES    AGE     VERSION   LABELS
+node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
+node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
+node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
+node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
+```
+
+Une vue logique du cluster est celle-ci :
+
+```
++---------------+---------------+
+|     zoneA     |     zoneB     |
++-------+-------+-------+-------+
+| node1 | node2 | node3 | node4 |
++-------+-------+-------+-------+
+```
+
+Plutôt que d'appliquer des labels manuellement, vous pouvez aussi réutiliser les [labels réputés](/docs/reference/kubernetes-api/labels-annotations-taints/) qui sont créés et renseignés automatiquement dans la plupart des clusters.
+
+## Contraintes de propagation pour les Pods
+
+### API
+
+Le champ `pod.spec.topologySpreadConstraints` est introduit dans 1.16 comme suit :
+
+```
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  topologySpreadConstraints:
+    - maxSkew: <integer>
+      topologyKey: <string>
+      whenUnsatisfiable: <string>
+      labelSelector: <object>
+```
+
+Vous pouvez définir une ou plusieurs `topologySpreadConstraint` pour indiquer au kube-scheduler comment placer chaque nouveau Pod par rapport aux Pods déjà existants dans votre cluster. Les champs sont :
+
+- **maxSkew** décrit le degré avec lequel les Pods peuvent être inégalement distribués. C'est la différence maximale permise entre le nombre de Pods correspondants entre deux quelconques domaines de topologie d'un type donné. Il doit être supérieur à zéro.
+- **topologyKey** est la clé des labels de noeuds. Si deux noeuds sont étiquettés avec cette clé et ont des valeurs égales pour ce label, le scheduler considère les deux noeuds dans la même topologie. Le scheduler essaie de placer un nombre équilibré de Pods dans chaque domaine de topologie.
+- **whenUnsatisfiable** indique comment traiter un Pod qui ne satisfait pas les contraintes de propagation :
+  - `DoNotSchedule` (défaut) indique au scheduler de ne pas le programmer.
+  - `ScheduleAnyway` indique au scheduler de le programmer, tout en priorisant les noeuds minimisant le biais (*skew*).
+- **labelSelector** est utilisé pour touver les Pods correspondants. Les Pods correspondants à ce sélecteur de labels sont comptés pour déterminer le nombre de Pods dans leurs domaines de topologie correspodants. Voir [Sélecteurs de labels](/docs/concepts/overview/working-with-objects/labels/#label-selectors) pour plus de détails.
+
+Vous pouvez en savoir plus sur ces champ en exécutant `kubectl explain Pod.spec.topologySpreadConstraints`.
+
+### Exemple : Une TopologySpreadConstraint
+
+Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquettés `foo:bar` sont placés sur node1, node2 et node3 respectivement (`P` représente un Pod) :
+
+```
++---------------+---------------+
+|     zoneA     |     zoneB     |
++-------+-------+-------+-------+
+| node1 | node2 | node3 | node4 |
++-------+-------+-------+-------+
+|   P   |   P   |   P   |       |
++-------+-------+-------+-------+
+```
+
+Si nous voulons qu'un nouveau Pod soit uniformément réparti avec les Pods existants à travers les zones, la spec peut être :
+
+{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
+
+`topologyKey: zone` implique que la distribution uniforme sera uniquement appliquée pour les noeuds ayant le label "zone:&lt;any value&gt;" présent. `whenUnsatisfiable: DoNotSchedule` indique au scheduler de laisser le Pod dans l'état Pending si le Pod entrant ne peut pas satisfaire la contrainte.
+
+Si le scheduler plaçait ce Pod entrant dans "zoneA", la distribution des Pods deviendrait [3, 1], et le biais serait de 2 (3 - 1) - ce qui va à l'encontre de `maxSkew: 1`. Dans cet exemple, le Pod entrant peut uniquement être placé dans "zoneB":
+
+```
++---------------+---------------+      +---------------+---------------+
+|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
++-------+-------+-------+-------+      +-------+-------+-------+-------+
+| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
++-------+-------+-------+-------+      +-------+-------+-------+-------+
+|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
++-------+-------+-------+-------+      +-------+-------+-------+-------+
+```
+
+Vous pouvez ajuster la spec du Pod pour pour répondre à divers types d'exigences :
+
+- Changez `maxSkew` pour une valeur plus grande comme "2" pour que le Pod entrant puisse aussi être placé dans la "zoneA".
+- Changez `topologyKey` pour "node" pour distribuer les Pods uniformément à travers les noeuds et non plus les zones. Dans l'exemple ci-dessus, si `maxSkew` reste à "1", le Pod entrant peut être uniquement placé dans "node4".
+- Changez `whenUnsatisfiable: DoNotSchedule` en `whenUnsatisfiable: ScheduleAnyway` pour s'assurer que le Pod est toujours programmable (en supposant que les autres APIs de scheduling soient satisfaites). Cependant, il sera de préférence placé dans la topologie de domaine ayant le moins de Pods correspondants. (Prenez note que cette préférence est normalisée conjointement avec d'autres priorités de scheduling interne comme le ratio d'usage de ressources, etc.)
+
+### Example: Plusieurs TopologySpreadConstraints
+
+Cela s'appuie sur l'exemple précédent. Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquetés `foo:bar` sont placés sur node1, node2 et node3 respectivement (`P` représente un Pod):
+
+```
++---------------+---------------+
+|     zoneA     |     zoneB     |
++-------+-------+-------+-------+
+| node1 | node2 | node3 | node4 |
++-------+-------+-------+-------+
+|   P   |   P   |   P   |       |
++-------+-------+-------+-------+
+```
+
+Vous pouvez utiliser 2 TopologySpreadConstraints pour contrôler la répartition des Pods aussi bien dans les zones que dans les noeuds :
+
+{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
+
+Dans ce cas, pour satisfaire la première contrainte, le Pod entrant peut uniquement être placé dans "zoneB" ; alors que pour satisfaire la seconde contrainte, le Pod entrant peut uniquement être placé dans "node4". Le résultat étant l'intersection des résultats des 2 contraintes, l'unique option possible est de placer le Pod entrant dans "node4".
+
+Plusieurs contraintes peuvent entraîner des conflits. Supposons que vous ayez un cluster de 3 noeuds couvrant 2 zones :
+
+```
++---------------+-------+
+|     zoneA     | zoneB |
++-------+-------+-------+
+| node1 | node2 | node3 |
++-------+-------+-------+
+|  P P  |   P   |  P P  |
++-------+-------+-------+
+```
+
+Si vous appliquez "two-constraints.yaml" à ce cluster, vous noterez que "mypod" reste dans l'état `Pending`. Cela parce que : pour satisfaire la première contrainte, "mypod" peut uniquement être placé dans "zoneB"; alors que pour satisfaire la seconde contrainte, "mypod" peut uniquement être placé sur "node2". Ainsi, le résultat de l'intersection entre "zoneB" et "node2" ne retourne rien.
+
+Pour surmonter cette situation, vous pouvez soit augmenter `maxSkew`, soit modifier une des contraintes pour qu'elle utilise `whenUnsatisfiable: ScheduleAnyway`.
+
+### Conventions
+
+Il existe quelques conventions implicites qu'il est intéressant de noter ici :
+
+- Seuls le Pods du même espace de noms que le Pod entrant peuvent être des candidats pour la correspondance.
+
+- Les noeuds sans label  `topologySpreadConstraints[*].topologyKey` seront ignorés. Cela induit que :
+
+  1. les Pods localisés sur ces noeuds n'impactent pas le calcul de `maxSkew` - dans l'exemple ci-dessus, supposons que "node1" n'a pas de label "zone", alors les 2 Pods ne seront pas comptés, et le Pod entrant sera placé dans "zoneA".
+  2. le Pod entrant n'a aucune chance d'être programmé sur ce type de noeuds - dans l'exemple ci-dessus, supposons qu'un "node5" portant un label `{zone-typo: zoneC}` joigne le cluster ; il sera ignoré, en raison de l'absence de label "zone".
+
+- Faites attention à ce qui arrive lorsque le `topologySpreadConstraints[*].labelSelector`  du Pod entrant ne correspond pas à ses propres labels. Dans l'exemple ci-dessus, si nous supprimons les labels du Pod entrant, il sera toujours placé dans "zoneB" car les contraintes sont toujours satisfaites. Cependant, après le placement, le degré de déséquilibre du cluster reste inchangé - zoneA contient toujours 2 Pods ayant le label {foo:bar}, et zoneB contient 1 Pod cayant le label {foo:bar}. Si ce n'est pas ce que vous attendez, nous recommandons que `topologySpreadConstraints[*].labelSelector` du workload corresponde à ses propres labels.
+
+- Si le Pod entrant a défini `spec.nodeSelector` ou `spec.affinity.nodeAffinity`, les noeuds non correspondants seront ignorés.
+
+    Supposons que vous ayez un cluster de 5 noeuds allant de zoneA à zoneC :
+
+    ```
+    +---------------+---------------+-------+
+    |     zoneA     |     zoneB     | zoneC |
+    +-------+-------+-------+-------+-------+
+    | node1 | node2 | node3 | node4 | node5 |
+    +-------+-------+-------+-------+-------+
+    |   P   |   P   |   P   |       |       |
+    +-------+-------+-------+-------+-------+
+    ```
+
+    et vous savez que "zoneC" doit être exclue. Dans ce cas, vous pouvez écrire le yaml ci-dessous, pour que "mypod" soit placé dans "zoneB" plutôt que dans "zoneC". `spec.nodeSelector` est pris en compte de la même manière.
+
+    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+
+### Contraintes par défaut au niveau du cluster
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+Il est possible de définir des contraintes de propagation de topologie par défaut pour un cluster. Les contraintes de propagation de topologie sont appliquées à un Pod si et seulement si :
+
+- Il ne définit aucune contrainte dans son `.spec.topologySpreadConstraints`.
+- Il appartient à un service, replication controller, replica set ou stateful set.
+
+Les contraintes par défaut peuvent être définies comme arguments du plugin `PodTopologySpread`
+dans un [profil de scheduling](/docs/reference/scheduling/profiles).
+Les contraintes sont spécifiées avec la même [API ci-dessus](#api), à l'exception que
+`labelSelector` doit être vide. Les sélecteurs sont calculés à partir des services,
+replication controllers, replica sets ou stateful sets auxquels le Pod appartient.
+
+Un exemple de configuration pourrait ressembler à :
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1alpha2
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints:
+            - maxSkew: 1
+              topologyKey: topology.kubernetes.io/zone
+              whenUnsatisfiable: ScheduleAnyway
+```
+
+{{< note >}}
+Le score produit par les contraintes de scheduling par défaut peuvent rentrer en conflit avec le score
+produit par le [plugin `DefaultPodTopologySpread`](/docs/reference/scheduling/profiles/#scheduling-plugins).
+Il est recommandé de désactiver ce plugin dans le profil de scheduling lorsque vous utilisez des contraintes
+par défaut pour `PodTopologySpread`.
+{{< /note >}}
+
+## Comparaison avec PodAffinity/PodAntiAffinity
+
+Dans Kubernetes, les directives relatives aux "Affinités" contrôlent comment les Pods sont
+programmés - plus regroupés ou plus dispersés.
+
+- Pour `PodAffinity`, vous pouvez essayer de regrouper un certain nombre de Pods dans des domaines de topologie qualifiés,
+- Pour `PodAntiAffinity`, seulement un Pod peut être programmé dans un domaine de topologie unique.
+
+La fonctionnalité "EvenPodsSpread" fournit des options flexibles pour distribuer des Pods uniformément sur différents domaines de topologie - pour mettre en place de la haute disponibilité ou réduire les coûts. Cela peut aussi aider
+au rolling update des charges de travail et à la mise à l'échelle de réplicas. Voir [Motivations](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation) pour plus de détails.
+
+## Limitations connues
+
+En version 1.18, pour laquelle cette fonctionnalité est en Beta, il y a quelques limitations connues :
+
+- Réduire un Déploiement peut résulter en une distrubution désiquilibrée des Pods.
+- Les Pods correspondants sur des noeuds taintés sont respectés. Voir [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
diff --git a/content/fr/docs/contribute/participating.md b/content/fr/docs/contribute/participating.md
index 34015b19b4..0658be231f 100644
--- a/content/fr/docs/contribute/participating.md
+++ b/content/fr/docs/contribute/participating.md
@@ -27,7 +27,7 @@ Le reste de ce document décrit certaines fonctions uniques de ces rôles au sei
 
 Lorsqu'une pull request est mergée à la branche utilisée pour publier le contenu (actuellement `master`), ce contenu est publié et disponible dans le monde entier.
 Pour nous assurer que la qualité de notre contenu publié est élevée, nous limitons aux approbateurs SIG Docs le droit de merger des pull requests.
-Voici comment ça fonctionne.
+Voici comment ce processus fonctionne.
 
 - Lorsqu'une pull request a les deux labels `lgtm` et `approve` et n'a pas de label `hold`, la pull request est mergée automatiquement.
 - Les membres de l'organisation Kubernetes et les approbateurs SIG Docs peuvent ajouter des commentaires à une pull request ou empêcher le merge automatique d'une pull request donnée (en ajoutant un commentaire `/hold` ou en retirant un commentaire `/lgtm`).
@@ -35,7 +35,7 @@ Voici comment ça fonctionne.
 - Seul un approbateur membre de SIG Docs peut causer le merge d'une pull request en ajoutant un commentaire `/approve`.
   Certains approbateurs remplissent également des rôles spécifiques supplémentaires, tels que [PR Wrangler](#pr-wrangler) or [président(e) du SIG Docs](#sig-docs-chairperson).
 
-Pour plus d'informations sur les attentes et les différences entre les rôles de membre d'organisation Kubernetes et d'approbateurs SIG Docs, voir [Types de contributeur](/docs/contribute#types-of-contributor).
+Pour plus d'informations sur les attentes et les différences entre les rôles de membre de l'organisation Kubernetes et d'approbateurs SIG Docs, voir [Types de contributeur](/docs/contribute#types-of-contributor).
 Les sections suivantes couvrent plus de détails sur ces rôles et leur fonctionnement dans SIG-Docs.
 
 ### N'importe qui
@@ -47,7 +47,7 @@ Si vous ne pouvez pas signer le CLA, le projet Kubernetes ne peut pas accepter v
 
 ### Membres
 
-Tout membre de l'[organisation Kubernetes](https://github.com/kubernetes) peut faire une revue d'une pull request, et SIG Docs les membres de l’équipe demandent fréquemment aux membres d’autres SIG d’être révisés pour des raisons de précision technique.
+Tout membre de l'[organisation Kubernetes](https://github.com/kubernetes) peut faire une revue d'une pull request, et les membres de l’équipe SIG Docs demandent fréquemment aux membres d’autres SIG d'effectuer des révisions de documents pour des raisons de précision technique.
 SIG Docs accueille également des critiques et des commentaires indépendamment du statut de membre d'une personne dans l'organisation Kubernetes.
 Vous pouvez indiquer votre approbation en ajoutant un commentaire de `/lgtm` à une pull request.
 Si vous n'êtes pas membre de l'organisation Kubernetes, votre `/lgtm` n'a aucun effet sur les systèmes automatisés.
@@ -85,7 +85,7 @@ Voir [Equipes et groupes au sein de SIG Docs](#teams-and-groups-within-sig-docs)
 
 Les relecteurs examinent les Pull Request de documentation et font des commentaires sur les changements proposés.
 
-L'automatisation assigne des relecteurs aux pull requets, et les contributeurs peuvent demander une revue d'un relecteur spécifique en laissant un commentaire tel que: `/assign [@_github_handle]`.
+L'automatisation assigne des relecteurs aux pull requests, et les contributeurs peuvent demander une revue d'un relecteur spécifique en laissant un commentaire tel que: `/assign [@_github_handle]`.
 Pour indiquer qu'une pull request est techniquement exacte et ne nécessite aucune modification supplémentaire, un examinateur ajoute un commentaire `/lgtm` à la Pull Request.
 
 Si le relecteur affecté n'a pas encore revu le contenu, un autre relecteur peut intervenir.
@@ -105,7 +105,7 @@ Les relecteurs d'autres SIG doivent demander séparément le statut de relecteur
 Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépôt `kubernetes/website`.
 Affectez la PR à un ou plusieurs approbateurs SIG Docs.
 
-Si votre pull request est approuvé, vous êtes maintenant un relecteur SIG Docs.
+Si votre pull request est approuvée, vous êtes maintenant un relecteur SIG Docs.
 [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) vous assignera et vous suggérera en tant que relecteur pour les nouvelles Pull Requests.
 
 Si vous êtes approuvé, demandez qu’un approbateur SIG Docs en cours vous ajoute au groupe Github [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews).
@@ -141,7 +141,7 @@ Seuls les membres du groupe Github `kubernetes-website-admins` peuvent ajouter d
 
 #### Devenir un administrateur de site Web
 
-Les membres du groupe GitHub `kubernetes-website-admins` peut gérer l’appartenance au groupe Github et disposer de tous les droits administratifs sur les paramètres du dépôt, y compris la possibilité d'ajouter, de supprimer et de debugger des Webhooks.
+Les membres du groupe GitHub `kubernetes-website-admins` peuvent gérer l’appartenance au groupe Github et disposer de tous les droits administratifs sur les paramètres du dépôt, y compris la possibilité d'ajouter, de supprimer et de debugger des Webhooks.
 Tous les approbateurs SIG Docs n'ont pas besoin de ce niveau d'accès.
 
 Si vous pensez avoir besoin de ce niveau d’accès, adressez-vous à un administrateur de site Web existant ou posez la question dans le canal Slack [#sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/).
@@ -187,12 +187,12 @@ Le [dépôt du site web Kubernetes](https://github.com/kubernetes/website) utili
 Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne.
 
 Un fichier [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs.
-Les fichiers OWNERS existent aussi dans les sous-dossiers, et peut ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants.
+Les fichiers OWNERS existent aussi dans les sous-dossiers, et peuvent ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants.
 Pour plus d'informations sur les fichiers OWNERS en général, voir [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
 
 En outre, un fichier Markdown individuel peut répertorier les relecteurs et les approbateurs dans l'entête, soit en répertoriant les noms d’utilisateur ou les groupes de Github.
 
-La combinaison des fichiers `OWNERS` et des entêtes dans les fichiers Markdown determinent les suggestions automatiques de relecteurs dans la PullRequest.
+La combinaison des fichiers `OWNERS` et des entêtes dans les fichiers Markdown déterminent les suggestions automatiques de relecteurs dans la PullRequest.
 
 
 
diff --git a/content/fr/docs/reference/kubectl/kubectl.md b/content/fr/docs/reference/kubectl/kubectl.md
index 23d788c0c3..40424cbfd8 100755
--- a/content/fr/docs/reference/kubectl/kubectl.md
+++ b/content/fr/docs/reference/kubectl/kubectl.md
@@ -21,489 +21,489 @@ kubectl [flags]
 
 
 <table style="width: 100%; table-layout: fixed;">
-  <colgroup>
-    <col span="1" style="width: 10px;" />
-    <col span="1" />
-  </colgroup>
-  <tbody>
-
-    <tr>
-      <td colspan="2">--add-dir-header</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, ajoute le répertoire du fichier à l'entête</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--alsologtostderr</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">log sur l'erreur standard en plus d'un fichier</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--application-metrics-count-limit int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 100</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nombre max de métriques d'applications à stocker (par conteneur)</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--as chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nom d'utilisateur à utiliser pour l'opération</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--as-group tableauDeChaînes</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Groupe à utiliser pour l'opération, ce flag peut être répété pour spécifier plusieurs groupes</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--azure-container-registry-config chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin du fichier contenant les informations de configuration du registre de conteneurs Azure</td>
-    </tr>
-
-     <tr>
-      <td colspan="2">--boot-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/proc/sys/kernel/random/boot_id"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Liste séparée par des virgules de fichiers dans lesquels rechercher le boot-id. Utilise le premier trouvé.</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--cache-dir chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "/home/karen/.kube/http-cache"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Répertoire de cache HTTP par défaut</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--certificate-authority chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin vers un fichier cert pour l'autorité de certification</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--client-certificate chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin vers un fichier de certificat client pour TLS</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--client-key chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin vers un fichier de clé client pour TLS</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">CIDRs ouverts dans le firewall GCE pour le proxy de trafic LB & health checks</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--cluster chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Le nom du cluster kubeconfig à utiliser</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--container-hints chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/etc/cadvisor/container_hints.json"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">location du fichier hints du conteneur</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--containerd chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/run/containerd/containerd.sock"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Point de terminaison de containerd</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--containerd-namespace chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "k8s.io"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">namespace de containerd</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--context chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Le nom du contexte kubeconfig à utiliser</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 300</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Indique les tolerationSeconds de la tolérance pour notReady:NoExecute qui sont ajoutées par défaut à tous les pods qui n'ont pas défini une telle tolérance</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 300</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Indique les tolerationSeconds de la tolérance pour unreachable:NoExecute qui sont ajoutées par défaut à tous les pods qui n'ont pas défini une telle tolérance</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--disable-root-cgroup-stats</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Désactive la collecte des stats du Cgroup racine</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "unix:///var/run/docker.sock"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Point de terminaison docker</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-env-metadata-whitelist chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">une liste séparée par des virgules de variables d'environnement qui doivent être collectées pour les conteneurs docker</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-only</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Remonte uniquement les stats Docker en plus des stats racine</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-root chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/var/lib/docker"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">DÉPRÉCIÉ : la racine de docker est lue depuis docker info (ceci est une solution de secours, défaut : /var/lib/docker)</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-tls</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">utiliser TLS pour se connecter à docker</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-tls-ca chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "ca.pem"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">chemin vers CA de confiance</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-tls-cert chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "cert.pem"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">chemin vers le certificat client</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--docker-tls-key chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "key.pem"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">chemin vers la clef privée</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--enable-load-reader</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Activer le lecteur de la charge CPU</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--event-storage-age-limit chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "default=0"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Durée maximale pendant laquelle stocker les événements  (par type). La valeur est une liste séparée par des virgules de clefs/valeurs, où les clefs sont des types d'événements (par ex: creation, oom) ou "default" et la valeur est la durée. La valeur par défaut est appliquée à tous les types d'événements non spécifiés</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--event-storage-event-limit chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "default=0"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nombre max d'événements à stocker (par type). La valeur est une liste séparée par des virgules de clefs/valeurs, où les clefs sont les types d'événements (par ex: creation, oom) ou "default" et la valeur est un entier. La valeur par défaut est appliquée à tous les types d'événements non spécifiés</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--global-housekeeping-interval durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 1m0s</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Intevalle entre ménages globaux</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">-h, --help</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">aide pour kubectl</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--housekeeping-interval durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 10s</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Intervalle entre ménages des conteneurs</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--insecure-skip-tls-verify</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, la validité du certificat du serveur ne sera pas vérifiée. Ceci rend vos connexions HTTPS non sécurisées</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--kubeconfig chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin du fichier kubeconfig à utiliser pour les requêtes du CLI</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: :0</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">lorsque les logs arrivent à la ligne fichier:N, émet une stack trace</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--log-cadvisor-usage</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Activer les logs d'usage du conteneur cAdvisor</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--log-dir chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si non vide, écrit les fichiers de log dans ce répertoire</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--log-file chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si non vide, utilise ce fichier de log</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--log-file-max-size uint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 1800</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Définit la taille maximale d'un fichier de log. L'unité est le mega-octet. Si la valeur est 0, la taille de fichier maximale est illimitée.</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--log-flush-frequency durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 5s</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nombre de secondes maximum entre flushs des logs</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: true</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">log sur l'erreur standard plutôt que dans un fichier</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--machine-id-file chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/etc/machine-id,/var/lib/dbus/machine-id"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">liste séparée par des virgules de fichiers dans lesquels rechercher le machine-id. Utiliser le premier trouvé.</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--match-server-version</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">La version du serveur doit correspondre à la version du client</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">-n, --namespace chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si présent, la portée de namespace pour la requête du CLI</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--password chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Mot de passe pour l'authentification de base au serveur d'API</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--profile chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "none"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nom du profil à capturer. Parmi (none|cpu|heap|goroutine|threadcreate|block|mutex)</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--profile-output chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "profile.pprof"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nom du fichier dans lequel écrire le profil</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--request-timeout chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "0"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">La durée à attendre avant d'abandonner une requête au serveur. Les valeurs non égales à zéro doivent contenir une unité de temps correspondante (ex 1s, 2m, 3h). Une valeur à zéro indique de ne pas abandonner les requêtes</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">-s, --server chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">L'adresse et le port de l'API server Kubernetes</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--skip-headers</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, n'affiche pas les entêtes dans les messages de log</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--skip-log-headers</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, évite les entêtes lors de l'ouverture des fichiers de log</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--stderrthreshold sévérité&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 2</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">logs à cette sévérité et au dessus de ce seuil vont dans stderr</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-buffer-duration durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 1m0s</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Les écritures dans le driver de stockage seront bufferisés pour cette durée, et seront envoyés aux backends non-mémoire en une seule transaction</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-db chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "cadvisor"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">nom de la base de données</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-host chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "localhost:8086"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">hôte:port de la base de données</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-password chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "root"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Mot de passe de la base de données</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-secure</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">utiliser une connexion sécurisée avec la base de données</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-table chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "stats"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nom de la table dans la base de données</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--storage-driver-user chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "root"</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">nom d'utilisateur de la base de données</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--token chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Bearer token pour l'authentification auprès de l'API server</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--update-machine-info-interval durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 5m0s</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Intevalle entre mises à jour des infos machine.</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--user chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Le nom de l'utilisateur kubeconfig à utiliser</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--username chaîne</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Nom d'utilisateur pour l'authentification de base au serveur  d'API</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">-v, --v Niveau</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Niveau de verbosité des logs</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--version version[=true]</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Affiche les informations de version et quitte</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--vmodule moduleSpec</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Liste de settings pattern=N séparés par des virgules pour le logging filtré par fichiers</td>
-    </tr>
-
-  </tbody>
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--add-dir-header</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, ajoute le répertoire du fichier à l'entête</td>
+</tr>
+
+<tr>
+<td colspan="2">--alsologtostderr</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">log sur l'erreur standard en plus d'un fichier</td>
+</tr>
+
+<tr>
+<td colspan="2">--application-metrics-count-limit int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 100</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nombre max de métriques d'applications à stocker (par conteneur)</td>
+</tr>
+
+<tr>
+<td colspan="2">--as chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nom d'utilisateur à utiliser pour l'opération</td>
+</tr>
+
+<tr>
+<td colspan="2">--as-group tableauDeChaînes</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Groupe à utiliser pour l'opération, ce flag peut être répété pour spécifier plusieurs groupes</td>
+</tr>
+
+<tr>
+<td colspan="2">--azure-container-registry-config chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin du fichier contenant les informations de configuration du registre de conteneurs Azure</td>
+</tr>
+
+<tr>
+<td colspan="2">--boot-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/proc/sys/kernel/random/boot_id"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Liste séparée par des virgules de fichiers dans lesquels rechercher le boot-id. Utilise le premier trouvé.</td>
+</tr>
+
+<tr>
+<td colspan="2">--cache-dir chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "/home/karen/.kube/http-cache"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Répertoire de cache HTTP par défaut</td>
+</tr>
+
+<tr>
+<td colspan="2">--certificate-authority chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin vers un fichier cert pour l'autorité de certification</td>
+</tr>
+
+<tr>
+<td colspan="2">--client-certificate chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin vers un fichier de certificat client pour TLS</td>
+</tr>
+
+<tr>
+<td colspan="2">--client-key chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin vers un fichier de clé client pour TLS</td>
+</tr>
+
+<tr>
+<td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">CIDRs ouverts dans le firewall GCE pour le proxy de trafic LB & health checks</td>
+</tr>
+
+<tr>
+<td colspan="2">--cluster chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Le nom du cluster kubeconfig à utiliser</td>
+</tr>
+
+<tr>
+<td colspan="2">--container-hints chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/etc/cadvisor/container_hints.json"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">location du fichier hints du conteneur</td>
+</tr>
+
+<tr>
+<td colspan="2">--containerd chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/run/containerd/containerd.sock"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Point de terminaison de containerd</td>
+</tr>
+
+<tr>
+<td colspan="2">--containerd-namespace chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "k8s.io"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">namespace de containerd</td>
+</tr>
+
+<tr>
+<td colspan="2">--context chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Le nom du contexte kubeconfig à utiliser</td>
+</tr>
+
+<tr>
+<td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 300</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Indique les tolerationSeconds de la tolérance pour notReady:NoExecute qui sont ajoutées par défaut à tous les pods qui n'ont pas défini une telle tolérance</td>
+</tr>
+
+<tr>
+<td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 300</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Indique les tolerationSeconds de la tolérance pour unreachable:NoExecute qui sont ajoutées par défaut à tous les pods qui n'ont pas défini une telle tolérance</td>
+</tr>
+
+<tr>
+<td colspan="2">--disable-root-cgroup-stats</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Désactive la collecte des stats du Cgroup racine</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "unix:///var/run/docker.sock"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Point de terminaison docker</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-env-metadata-whitelist chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">une liste séparée par des virgules de variables d'environnement qui doivent être collectées pour les conteneurs docker</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-only</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Remonte uniquement les stats Docker en plus des stats racine</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-root chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/var/lib/docker"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">DÉPRÉCIÉ : la racine de docker est lue depuis docker info (ceci est une solution de secours, défaut : /var/lib/docker)</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-tls</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">utiliser TLS pour se connecter à docker</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-tls-ca chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "ca.pem"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">chemin vers CA de confiance</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-tls-cert chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "cert.pem"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">chemin vers le certificat client</td>
+</tr>
+
+<tr>
+<td colspan="2">--docker-tls-key chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "key.pem"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">chemin vers la clef privée</td>
+</tr>
+
+<tr>
+<td colspan="2">--enable-load-reader</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Activer le lecteur de la charge CPU</td>
+</tr>
+
+<tr>
+<td colspan="2">--event-storage-age-limit chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "default=0"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Durée maximale pendant laquelle stocker les événements  (par type). La valeur est une liste séparée par des virgules de clefs/valeurs, où les clefs sont des types d'événements (par ex: creation, oom) ou "default" et la valeur est la durée. La valeur par défaut est appliquée à tous les types d'événements non spécifiés</td>
+</tr>
+
+<tr>
+<td colspan="2">--event-storage-event-limit chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "default=0"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nombre max d'événements à stocker (par type). La valeur est une liste séparée par des virgules de clefs/valeurs, où les clefs sont les types d'événements (par ex: creation, oom) ou "default" et la valeur est un entier. La valeur par défaut est appliquée à tous les types d'événements non spécifiés</td>
+</tr>
+
+<tr>
+<td colspan="2">--global-housekeeping-interval durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 1m0s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Intevalle entre ménages globaux</td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">aide pour kubectl</td>
+</tr>
+
+<tr>
+<td colspan="2">--housekeeping-interval durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 10s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Intervalle entre ménages des conteneurs</td>
+</tr>
+
+<tr>
+<td colspan="2">--insecure-skip-tls-verify</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, la validité du certificat du serveur ne sera pas vérifiée. Ceci rend vos connexions HTTPS non sécurisées</td>
+</tr>
+
+<tr>
+<td colspan="2">--kubeconfig chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Chemin du fichier kubeconfig à utiliser pour les requêtes du CLI</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: :0</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">lorsque les logs arrivent à la ligne fichier:N, émet une stack trace</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-cadvisor-usage</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Activer les logs d'usage du conteneur cAdvisor</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-dir chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si non vide, écrit les fichiers de log dans ce répertoire</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-file chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si non vide, utilise ce fichier de log</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-file-max-size uint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 1800</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Définit la taille maximale d'un fichier de log. L'unité est le mega-octet. Si la valeur est 0, la taille de fichier maximale est illimitée.</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-flush-frequency durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 5s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nombre de secondes maximum entre flushs des logs</td>
+</tr>
+
+<tr>
+<td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: true</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">log sur l'erreur standard plutôt que dans un fichier</td>
+</tr>
+
+<tr>
+<td colspan="2">--machine-id-file chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "/etc/machine-id,/var/lib/dbus/machine-id"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">liste séparée par des virgules de fichiers dans lesquels rechercher le machine-id. Utiliser le premier trouvé.</td>
+</tr>
+
+<tr>
+<td colspan="2">--match-server-version</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">La version du serveur doit correspondre à la version du client</td>
+</tr>
+
+<tr>
+<td colspan="2">-n, --namespace chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si présent, la portée de namespace pour la requête du CLI</td>
+</tr>
+
+<tr>
+<td colspan="2">--password chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Mot de passe pour l'authentification de base au serveur d'API</td>
+</tr>
+
+<tr>
+<td colspan="2">--profile chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "none"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nom du profil à capturer. Parmi (none|cpu|heap|goroutine|threadcreate|block|mutex)</td>
+</tr>
+
+<tr>
+<td colspan="2">--profile-output chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "profile.pprof"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nom du fichier dans lequel écrire le profil</td>
+</tr>
+
+<tr>
+<td colspan="2">--request-timeout chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: "0"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">La durée à attendre avant d'abandonner une requête au serveur. Les valeurs non égales à zéro doivent contenir une unité de temps correspondante (ex 1s, 2m, 3h). Une valeur à zéro indique de ne pas abandonner les requêtes</td>
+</tr>
+
+<tr>
+<td colspan="2">-s, --server chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">L'adresse et le port de l'API server Kubernetes</td>
+</tr>
+
+<tr>
+<td colspan="2">--skip-headers</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, n'affiche pas les entêtes dans les messages de log</td>
+</tr>
+
+<tr>
+<td colspan="2">--skip-log-headers</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Si vrai, évite les entêtes lors de l'ouverture des fichiers de log</td>
+</tr>
+
+<tr>
+<td colspan="2">--stderrthreshold sévérité&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut: 2</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">logs à cette sévérité et au dessus de ce seuil vont dans stderr</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-buffer-duration durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 1m0s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Les écritures dans le driver de stockage seront bufferisés pour cette durée, et seront envoyés aux backends non-mémoire en une seule transaction</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-db chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "cadvisor"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">nom de la base de données</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-host chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "localhost:8086"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">hôte:port de la base de données</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-password chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "root"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Mot de passe de la base de données</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-secure</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">utiliser une connexion sécurisée avec la base de données</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-table chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "stats"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nom de la table dans la base de données</td>
+</tr>
+
+<tr>
+<td colspan="2">--storage-driver-user chaîne&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : "root"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">nom d'utilisateur de la base de données</td>
+</tr>
+
+<tr>
+<td colspan="2">--token chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Bearer token pour l'authentification auprès de l'API server</td>
+</tr>
+
+<tr>
+<td colspan="2">--update-machine-info-interval durée&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Défaut : 5m0s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Intevalle entre mises à jour des infos machine.</td>
+</tr>
+
+<tr>
+<td colspan="2">--user chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Le nom de l'utilisateur kubeconfig à utiliser</td>
+</tr>
+
+<tr>
+<td colspan="2">--username chaîne</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Nom d'utilisateur pour l'authentification de base au serveur  d'API</td>
+</tr>
+
+<tr>
+<td colspan="2">-v, --v Niveau</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Niveau de verbosité des logs</td>
+</tr>
+
+<tr>
+<td colspan="2">--version version[=true]</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Affiche les informations de version et quitte</td>
+</tr>
+
+<tr>
+<td colspan="2">--vmodule moduleSpec</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Liste de settings pattern=N séparés par des virgules pour le logging filtré par fichiers</td>
+</tr>
+
+</tbody>
 </table>
 
 
diff --git a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index dcd43b3634..edf5c7e4c9 100644
--- a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -170,7 +170,7 @@ Vous remarquerez que la commande CLI `kubeadm` ne modifiera jamais ce fichier.
 Ce fichier ad-hoc appartient au paquet deb/rpm de kubeadm.
 
 Pour en savoir plus sur comment kubeadm gère kubelet, vous pouvez consulter
-[cette page](/docs/setup/independent/kubelet-integration).
+[cette page](/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration).
 
 ### Utilisation de kubeadm avec des runtimes CRI
 
diff --git a/content/fr/docs/setup/independent/_index.md b/content/fr/docs/setup/independent/_index.md
deleted file mode 100755
index 0025e6d6ec..0000000000
--- a/content/fr/docs/setup/independent/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Déployer des clusters avec kubeadm
-description: Déploiement cluster Kubernetes kubeadm
-weight: 30
----
diff --git a/content/fr/docs/setup/pick-right-solution.md b/content/fr/docs/setup/pick-right-solution.md
index 929e7ffbfb..a730ce8eb1 100644
--- a/content/fr/docs/setup/pick-right-solution.md
+++ b/content/fr/docs/setup/pick-right-solution.md
@@ -15,13 +15,13 @@ de votre propre cluster personnalisé. Utilisez ce guide pour choisir la solutio
 
 Si vous voulez simplement jeter un coup d'oeil rapide, utilisez alors de préférence les [solutions locales basées sur Docker](#solutions-locales).
 
-Lorsque vous êtes prêts à augmenter le nombre de machines et souhaitez bénéficier de la haute disponibilité, une 
+Lorsque vous êtes prêts à augmenter le nombre de machines et souhaitez bénéficier de la haute disponibilité, une
 [solution hébergée](#solutions-hebergées) est la plus simple à déployer et à maintenir.
 
-[Les solutions cloud clés en main](#solutions-clés-en-main) ne demandent que peu de commande pour déployer et couvrent un large panel de 
+[Les solutions cloud clés en main](#solutions-clés-en-main) ne demandent que peu de commande pour déployer et couvrent un large panel de
  fournisseurs de cloud. [Les solutions clés en main pour cloud privé](#solutions-on-premises-clés-en-main) possèdent la simplicité des solutions cloud clés en main combinées avec la sécurité de votre propre réseau privé.
 
-Si vous avez déjà un moyen de configurer vos resources, utilisez [kubeadm](/fr/docs/setup/independent/create-cluster-kubeadm/) pour facilement
+Si vous avez déjà un moyen de configurer vos resources, utilisez [kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) pour facilement
 déployer un cluster grâce à une seule ligne de commande par machine.
 
 [Les solutions personnalisées](#solutions-personnalisées) varient d'instructions pas à pas, à des conseils relativement généraux pour déployer un
@@ -168,7 +168,7 @@ essayez le guide [Getting Started from Scratch](/docs/setup/release/building-fro
 ### Universel
 
 Si vous avez déjà un moyen de configurer les ressources d'hébergement, utilisez
-[kubeadm](/docs/setup/independent/create-cluster-kubeadm/) pour déployer facilement un cluster
+[kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) pour déployer facilement un cluster
 avec une seule commande par machine.
 
 ### Cloud
@@ -220,7 +220,7 @@ Ci-dessous vous trouverez un tableau récapitulatif de toutes les solutions list
 
 | Fournisseur de IaaS                            | Config. Mgmt.                                                                | OS                                                                       | Réseau                                                                                                           | Docs                                                                                          | Niveau de support                                                                                                                                                                                                                              |
 |------------------------------------------------|------------------------------------------------------------------------------|--------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| tous                                           | tous                                                                         | multi-support                                                            | tout les CNI                                                                                                     | [docs](/docs/setup/independent/create-cluster-kubeadm/)                                       | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))                                                                                                                                                          |
+| tous                                           | tous                                                                         | multi-support                                                            | tout les CNI                                                                                                     | [docs](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)                                       | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))                                                                                                                                                          |
 | Google Kubernetes Engine                       |                                                                              |                                                                          | GCE                                                                                                              | [docs](https://cloud.google.com/kubernetes-engine/docs/)                                      | Commercial                                                                                                                                                                                                                                     |
 | Docker Enterprise                              | personnalisé                                                                 | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/)                                   | [docs](https://docs.docker.com/ee/)                                                           | Commercial                                                                                                                                                                                                                                     |
 | IBM Cloud Private                              | Ansible                                                                      | multi-support                                                            | multi-support                                                                                                    | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) |
diff --git a/content/fr/docs/setup/production-environment/_index.md b/content/fr/docs/setup/production-environment/_index.md
new file mode 100644
index 0000000000..232922eccd
--- /dev/null
+++ b/content/fr/docs/setup/production-environment/_index.md
@@ -0,0 +1,4 @@
+---
+title: Environnement de production
+weight: 30
+---
diff --git a/content/fr/docs/setup/on-premises-vm/_index.md b/content/fr/docs/setup/production-environment/on-premises-vm/_index.md
similarity index 100%
rename from content/fr/docs/setup/on-premises-vm/_index.md
rename to content/fr/docs/setup/production-environment/on-premises-vm/_index.md
diff --git a/content/fr/docs/setup/production-environment/tools/_index.md b/content/fr/docs/setup/production-environment/tools/_index.md
new file mode 100644
index 0000000000..f12147d4ed
--- /dev/null
+++ b/content/fr/docs/setup/production-environment/tools/_index.md
@@ -0,0 +1,4 @@
+---
+title: Installer Kubernetes avec les outils de déploiement
+weight: 30
+---
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/_index.md b/content/fr/docs/setup/production-environment/tools/kubeadm/_index.md
new file mode 100644
index 0000000000..7ab8b1b5bb
--- /dev/null
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Déploiement d'un cluster avec kubeadm"
+weight: 10
+---
diff --git a/content/fr/docs/setup/independent/control-plane-flags.md b/content/fr/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
similarity index 100%
rename from content/fr/docs/setup/independent/control-plane-flags.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
diff --git a/content/fr/docs/setup/independent/create-cluster-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
similarity index 98%
rename from content/fr/docs/setup/independent/create-cluster-kubeadm.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index a2ac112b3a..f25ac905be 100644
--- a/content/fr/docs/setup/independent/create-cluster-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -95,14 +95,14 @@ problème de sécurité est trouvé. Voici les dernières versions de Kubernetes
 ## Objectifs
 
 * Installer un cluster Kubernetes à master unique ou un
-[cluster à haute disponibilité](/docs/setup/independent/high-availability/)
+[cluster à haute disponibilité](/fr/docs/setup/production-environment/tools/kubeadm/high-availability/)
 * Installez un réseau de pods sur le cluster afin que vos pods puissent se parler
 
 ## Instructions
 
 ### Installer kubeadm sur vos hôtes
 
-Voir ["Installation de kubeadm"](/docs/setup/independent/install-kubeadm/).
+Voir ["Installation de kubeadm"](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
 
 {{< note >}}
 Si vous avez déjà installé kubeadm, lancez `apt-get update &&
@@ -436,7 +436,7 @@ vérifiant que le pod CoreDNS est en cours d’exécution dans l'output de `kube
 Et une fois que le pod CoreDNS est opérationnel, vous pouvez continuer en joignant vos nœuds.
 
 Si votre réseau ne fonctionne pas ou si CoreDNS n'est pas en cours d'exécution, vérifiez
-notre [documentation de dépannage](/docs/setup/independent/troubleshooting-kubeadm/).
+notre [documentation de dépannage](/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
 
 ### Isolation des nœuds du control plane
 
@@ -653,7 +653,7 @@ Ces ressources fournissent plus d'informations sur le saut de version pris en
 charge entre les kubelets et le control plane, ainsi que sur d'autres composants Kubernetes:
 
 * [politique de compatibilité de versions](/docs/setup/version-skew-policy/) de Kubernetes
-* [Guide d'installation](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
+* [Guide d'installation](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
 spécifique à Kubeadm
 
 ## kubeadm fonctionne sur plusieurs plates-formes {#multi-platform}
@@ -682,4 +682,4 @@ le répertoire des données etcd configuré par kubeadm se trouve dans `/var/lib
 ## Diagnostic {#troubleshooting}
 
 Si vous rencontrez des difficultés avec kubeadm, veuillez consulter nos
- [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).
+ [troubleshooting docs](/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
diff --git a/content/fr/docs/setup/independent/ha-topology.md b/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
similarity index 91%
rename from content/fr/docs/setup/independent/ha-topology.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
index cd0b6aec36..fbc9d14c0c 100644
--- a/content/fr/docs/setup/independent/ha-topology.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
@@ -55,7 +55,7 @@ Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stac
 
 Un cluster haute disponibilité avec un etcd externe est une
 [topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) où le cluster de stockage de données
-distribué fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
+distribuées fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
 du control plane.
 
 Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
@@ -63,7 +63,7 @@ une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`.
 est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
 des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane.
 
-Cette topologie dissocie le control plane et le membre etcd. Il fournit donc une configuration HA où
+Cette topologie dissocie le control plane et le membre etcd. Elle fournit donc une configuration HA où
 perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du
 cluster autant que la topologie HA empilée.
 
@@ -78,5 +78,5 @@ Schéma de la [Topologie externe etcd](/images/kubeadm/kubeadm-ha-topology-exter
 ## {{% heading "whatsnext" %}}
 
 
-- [Configurer un cluster hautement disponible avec kubeadm](/docs/setup/independent/high-availability/)
+- [Configurer un cluster hautement disponible avec kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/high-availability/)
 
diff --git a/content/fr/docs/setup/independent/high-availability.md b/content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md
similarity index 94%
rename from content/fr/docs/setup/independent/high-availability.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 210ba7e30c..88d2ea5da0 100644
--- a/content/fr/docs/setup/independent/high-availability.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -16,7 +16,7 @@ Les membres etcd et les nœuds du control plane sont co-localisés.
 Les nœuds du control plane et les membres etcd sont séparés.
 
 Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux
-aux besoins de vos applications et de l'environnement. [Cette comparaison](/docs/setup/independent/ha-topology/)
+aux besoins de vos applications et de l'environnement. [Cette comparaison](/fr/docs/setup/production-environment/tools/kubeadm/ha-topology/)
 décrit les avantages et les inconvénients de chacune.
 
 Vos clusters doivent exécuter Kubernetes version 1.12 ou ultérieure. Vous devriez aussi savoir que
@@ -31,7 +31,7 @@ Voir aussi [La documentation de mise à niveau HA](/docs/tasks/administer-cluste
 
 {{< caution >}}
 Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un
-environnement Cloud, les approches documentées ici ne fonctionne ni avec des objets de type
+environnement Cloud, les approches documentées ici ne fonctionnent ni avec des objets de type
 load balancer, ni avec des volumes persistants dynamiques.
 {{< /caution >}}
 
@@ -42,8 +42,8 @@ load balancer, ni avec des volumes persistants dynamiques.
 
 Pour les deux méthodes, vous avez besoin de cette infrastructure:
 
-- Trois machines qui répondent aux pré-requis des [exigences de kubeadm](/docs/setup/independent/install-kubeadm/#before-you-begin) pour les maîtres (masters)
-- Trois machines qui répondent aux pré-requis des [exigences de kubeadm](/docs/setup/independent/install-kubeadm/#before-you-begin) pour les workers
+- Trois machines qui répondent aux pré-requis des [exigences de kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) pour les maîtres (masters)
+- Trois machines qui répondent aux pré-requis des [exigences de kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) pour les workers
 - Connectivité réseau complète entre toutes les machines du cluster (public ou réseau privé)
 - Privilèges sudo sur toutes les machines
 - Accès SSH d'une machine à tous les nœuds du cluster
@@ -71,14 +71,14 @@ Toutes les commandes d'un control plane ou d'un noeud etcd doivent être
 
 - Certains plugins réseau CNI tels que Calico nécessitent un CIDR tel que `192.168.0.0 / 16` et 
 certains comme Weave n'en ont pas besoin. Voir la
-[Documentation du CNI réseau](/docs/setup/independent/create-cluster-kubeadm/#pod-network).
+[Documentation du CNI réseau](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
   Pour ajouter un CIDR de pod, définissez le champ `podSubnet: 192.168.0.0 / 16` sous
   l'objet `networking` de` ClusterConfiguration`.
 
 ### Créez un load balancer pour kube-apiserver
 
 {{< note >}}
-Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer).
+Il existe de nombreuses configurations pour les équilibreurs de charge (load balancers).
 L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent nécessiter une configuration différente.
 {{< /note >}}
 
@@ -260,7 +260,7 @@ donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelqu
 
 ### Configurer le cluster etcd
 
-- Suivez ces [instructions](/docs/setup/independent/setup-ha-etcd-with-kubeadm/)
+- Suivez ces [instructions](/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
   pour configurer le cluster etcd.
 
 ### Configurer le premier nœud du control plane
@@ -335,7 +335,7 @@ Pour résumer:
 
 ### Installer un réseau de pod
 
-[Suivez ces instructions](/docs/setup/independent/create-cluster-kubeadm/#pod-network) afin
+[Suivez ces instructions](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) afin
  d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni
  dans le fichier de configuration principal.
 
diff --git a/content/fr/docs/setup/independent/install-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
similarity index 95%
rename from content/fr/docs/setup/independent/install-kubeadm.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index a32225872f..cc33bbbdeb 100644
--- a/content/fr/docs/setup/independent/install-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -10,7 +10,7 @@ weight: 20
 <img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">Cette page vous
 apprend comment installer la boîte à outils `kubeadm`.
 Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez
-effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour créer un cluster](/docs/setup/independent/create-cluster-kubeadm/).
+effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour créer un cluster](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
 
 
 
@@ -126,7 +126,7 @@ C’est parce que kubeadm et Kubernetes ont besoin d'une
 Pour plus d'informations sur les compatibilités de version, voir:
 
 * Kubernetes [version et politique de compatibilité de version](/docs/setup/version-skew-policy/)
-* Kubeadm-specific [politique de compatibilité de version](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)
+* Kubeadm-specific [politique de compatibilité de version](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
 
 {{< tabs name="k8s_install" >}}
 {{% tab name="Ubuntu, Debian or HypriotOS" %}}
@@ -252,11 +252,11 @@ systemctl restart kubelet
 
 ## Dépannage
 
-Si vous rencontrez des difficultés avec kubeadm, veuillez consulter notre [documentation de dépannage](/docs/setup/independent/troubleshooting-kubeadm/).
+Si vous rencontrez des difficultés avec kubeadm, veuillez consulter notre [documentation de dépannage](/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
 
 ## {{% heading "whatsnext" %}}
 
 
-* [Utiliser kubeadm pour créer un cluster](/docs/setup/independent/create-cluster-kubeadm/)
+* [Utiliser kubeadm pour créer un cluster](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
 
 
diff --git a/content/fr/docs/setup/independent/kubelet-integration.md b/content/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
similarity index 100%
rename from content/fr/docs/setup/independent/kubelet-integration.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
diff --git a/content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
similarity index 97%
rename from content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index 446548d0f1..c8966b56fa 100644
--- a/content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -23,7 +23,7 @@ le fichier de configuration kubeadm.
 * Chaque hôte doit avoir [docker, kubelet et kubeadm installés][toolbox].
 * Certains paquets pour copier des fichiers entre les hôtes. Par exemple, `ssh` et` scp`.
 
-[toolbox]: /docs/setup/independent/install-kubeadm/
+[toolbox]: /fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
 
 
 
@@ -118,7 +118,7 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
     - `/etc/kubernetes/pki/etcd/ca.crt`
     - `/etc/kubernetes/pki/etcd/ca.key`
 
-1. Créer des certificats pour chaque membres
+1. Créer des certificats pour chaque membre
 
     ```sh
     kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
@@ -257,7 +257,7 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
 
 Une fois que vous avez un cluster de 3 membres etcd qui fonctionne, vous pouvez continuer à
  configurer un control plane hautement disponible utilisant la
-[méthode etcd externe avec kubeadm](/docs/setup/independent/high-availability/).
+[méthode etcd externe avec kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/high-availability/).
 
 
 
diff --git a/content/fr/docs/setup/independent/troubleshooting-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
similarity index 97%
rename from content/fr/docs/setup/independent/troubleshooting-kubeadm.md
rename to content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index 497c7ae7d7..bf9b0d69cb 100644
--- a/content/fr/docs/setup/independent/troubleshooting-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -68,9 +68,9 @@ de `journalctl -u kubelet`. Si vous voyez quelque chose comme ce qui suit:
   Il existe deux méthodes courantes pour résoudre le problème du driver cgroup:
 
  1. Installez à nouveau Docker en suivant les instructions
-  [ici](/docs/setup/independent/install-kubeadm/#installing-docker).
+  [ici](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-docker).
  1. Changez manuellement la configuration de la kubelet pour correspondre au driver Docker cgroup, vous pouvez vous référer à
-    [Configurez le driver de cgroupe utilisé par la kubelet sur le Nœud Master](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+    [Configurez le driver de cgroupe utilisé par la kubelet sur le Nœud Master](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
     pour des instruction détaillées.
 
 - Les conteneurs Docker du control plane sont en crashloop ou suspendus. Vous pouvez le vérifier en lançant `docker ps` et étudier chaque conteneur en exécutant `docker logs`.
@@ -238,7 +238,7 @@ dernière comme` InternalIP` du noeud au lieu du public.
 Si vous avez des nœuds qui exécutent SELinux avec une version plus ancienne de Docker, vous risquez
 de rencontrer un problème ou les pods de `coredns` ne démarrent pas. Pour résoudre ce problème, vous pouvez essayer l'une des options suivantes:
 
-- Mise à niveau vers une [nouvelle version de Docker](/docs/setup/independent/install-kubeadm/#installing-docker).
+- Mise à niveau vers une [nouvelle version de Docker](/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-docker).
 - [Désactiver SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
 - Modifiez le déploiement de `coredns` pour définir` allowPrivilegeEscalation` à `true`:
 
diff --git a/content/fr/docs/setup/turnkey/_index.md b/content/fr/docs/setup/production-environment/turnkey/_index.md
similarity index 100%
rename from content/fr/docs/setup/turnkey/_index.md
rename to content/fr/docs/setup/production-environment/turnkey/_index.md
diff --git a/content/fr/docs/setup/windows/_index.md b/content/fr/docs/setup/production-environment/windows/_index.md
similarity index 100%
rename from content/fr/docs/setup/windows/_index.md
rename to content/fr/docs/setup/production-environment/windows/_index.md
diff --git a/content/fr/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/fr/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
new file mode 100644
index 0000000000..ba11fb3a06
--- /dev/null
+++ b/content/fr/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -0,0 +1,374 @@
+---
+title: Configurer l'accès à plusieurs clusters
+content_type: task
+weight: 30
+card:
+  name: tasks
+  weight: 40
+---
+
+
+<!-- overview -->
+
+Cette page montre comment configurer l'accès à plusieurs clusters à l'aide de fichiers de configuration.
+Une fois vos clusters, utilisateurs et contextes définis dans un ou plusieurs fichiers de configuration, vous pouvez basculer rapidement entre les clusters en utilisant la commande `kubectl config use-context`.
+
+{{< note >}}
+Un fichier utilisé pour configurer l'accès à un cluster est parfois appelé *fichier kubeconfig*.
+C'est une manière générique de se référer aux fichiers de configuration.
+Cela ne signifie pas qu'il existe un fichier nommé `kubeconfig`.
+{{< /note >}}
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+Pour vérifier que {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} est installé, executez `kubectl version --client`.
+La version kubectl doit être [dans une version mineure](/docs/setup/release/version-skew-policy/#kubectl) de votre
+serveur API du cluster.
+
+<!-- steps -->
+
+## Définir des clusters, des utilisateurs et des contextes
+
+Supposons que vous ayez deux clusters, un pour le développement et un pour le travail `scratch`.
+Dans le cluster `development`, vos développeurs frontend travaillent dans un espace de noms appelé `frontend`, et vos développeurs de stockage travaillent dans un espace de noms appelé `storage`.
+Dans votre cluster `scratch`, les développeurs travaillent dans le namespace par défaut ou créent des namespaces auxiliaires comme bon leur semble.
+L'accès au cluster `development` nécessite une authentification par certificat.
+L'accès au cluster `scratch` nécessite une authentification par nom d'utilisateur et mot de passe.
+
+Créez un répertoire nommé `config-exercice`.
+Dans votre répertoire `config-exercice`, créez un fichier nommé `config-demo` avec ce contenu:
+
+```shell
+apiVersion: v1
+kind: Config
+preferences: {}
+
+clusters:
+- cluster:
+  name: development
+- cluster:
+  name: scratch
+
+users:
+- name: developer
+- name: experimenter
+
+contexts:
+- context:
+  name: dev-frontend
+- context:
+  name: dev-storage
+- context:
+  name: exp-scratch
+```
+
+Un fichier de configuration décrit les clusters, les utilisateurs et les contextes.
+Votre fichier `config-demo` a le cadre pour décrire deux clusters, deux utilisateurs et trois contextes.
+
+Allez dans votre répertoire `config-exercice`.
+Entrez ces commandes pour ajouter les détails du cluster à votre fichier de configuration:
+
+```shell
+kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
+kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
+```
+
+Ajoutez les détails de l'utilisateur à votre fichier de configuration:
+
+```shell
+kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
+kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
+```
+
+{{< note >}}
+
+- Pour supprimer un utilisateur, vous pouvez exécuter `kubectl --kubeconfig=config-demo config unset users.<name>`
+- Pour supprimer un cluster, vous pouvez exécuter `kubectl --kubeconfig=config-demo config unset clusters.<name>`
+- Pour supprimer un contexte, vous pouvez exécuter `kubectl --kubeconfig=config-demo config unset contexts.<name>`
+{{< /note >}}
+
+Ajoutez des détails de contexte à votre fichier de configuration:
+
+```shell
+kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
+kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
+kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
+```
+
+Ouvrez votre fichier `config-demo` pour voir les détails ajoutés.
+Au lieu d'ouvrir le fichier `config-demo`, vous pouvez utiliser la commande `kubectl config view`.
+
+```shell
+kubectl config --kubeconfig=config-demo view
+```
+
+La sortie montre les deux clusters, deux utilisateurs et trois contextes:
+
+```shell
+apiVersion: v1
+clusters:
+- cluster:
+    certificate-authority: fake-ca-file
+    server: https://1.2.3.4
+  name: development
+- cluster:
+    insecure-skip-tls-verify: true
+    server: https://5.6.7.8
+  name: scratch
+contexts:
+- context:
+    cluster: development
+    namespace: frontend
+    user: developer
+  name: dev-frontend
+- context:
+    cluster: development
+    namespace: storage
+    user: developer
+  name: dev-storage
+- context:
+    cluster: scratch
+    namespace: default
+    user: experimenter
+  name: exp-scratch
+current-context: ""
+kind: Config
+preferences: {}
+users:
+- name: developer
+  user:
+    client-certificate: fake-cert-file
+    client-key: fake-key-file
+- name: experimenter
+  user:
+    password: some-password
+    username: exp
+```
+
+Le `fake-ca-file`, `fake-cert-file` et `fake-key-file` ci-dessus sont les espaces réservés pour les noms de chemin des fichiers de certificat.
+Vous devez les remplacer par les noms de chemin réels des fichiers de certificat dans votre environnement.
+
+Parfois, vous souhaiterez peut-être utiliser des données encodées en Base64 incorporées ici au lieu de fichiers de certificat séparés; dans ce cas, vous devez ajouter le suffixe `-data` aux clés, par exemple, `certificate-Authority-data`, `client-certificate-data`, `client-key-data`.
+
+Chaque contexte est un triplet (cluster, utilisateur, namespace).
+Par exemple, le contexte `dev-frontend` dit, "Utilisez les informations d'identification de l'utilisateur `developer` pour accéder au namespace `frontend` du cluster `development`".
+
+Définissez le contexte actuel:
+
+```shell
+kubectl config --kubeconfig=config-demo use-context dev-frontend
+```
+
+Maintenant, chaque fois que vous entrez une commande `kubectl`, l'action s'appliquera au cluster et au namespace répertorié dans le contexte `dev-frontend`.
+Et la commande utilisera les informations d'identification de l'utilisateur répertoriées dans le contexte `dev-frontend`.
+
+Pour voir uniquement les informations de configuration associées au contexte actuel, utilisez l'indicateur `--minify`.
+
+```shell
+kubectl config --kubeconfig=config-demo view --minify
+```
+
+La sortie affiche les informations de configuration associées au contexte `dev-frontend`:
+
+```shell
+apiVersion: v1
+clusters:
+- cluster:
+    certificate-authority: fake-ca-file
+    server: https://1.2.3.4
+  name: development
+contexts:
+- context:
+    cluster: development
+    namespace: frontend
+    user: developer
+  name: dev-frontend
+current-context: dev-frontend
+kind: Config
+preferences: {}
+users:
+- name: developer
+  user:
+    client-certificate: fake-cert-file
+    client-key: fake-key-file
+```
+
+Supposons maintenant que vous souhaitiez travailler pendant un certain temps dans le cluster scratch.
+
+Changez le contexte actuel en `exp-scratch`:
+
+```shell
+kubectl config --kubeconfig=config-demo use-context exp-scratch
+```
+
+Maintenant, toute commande `kubectl` que vous donnez s'appliquera au namespace par défaut du cluster `scratch`.
+Et la commande utilisera les informations d'identification de l'utilisateur répertoriées dans le contexte `exp-scratch`.
+
+Afficher la configuration associée au nouveau contexte actuel, `exp-scratch`.
+
+```shell
+kubectl config --kubeconfig=config-demo view --minify
+```
+
+Enfin, supposons que vous vouliez travailler pendant un certain temps dans le namespace `storage` du cluster `development`.
+
+Changez le contexte actuel en `dev-storage`:
+
+```shell
+kubectl config --kubeconfig=config-demo use-context dev-storage
+```
+
+Afficher la configuration associée au nouveau contexte actuel, `dev-storage`.
+
+```shell
+kubectl config --kubeconfig=config-demo view --minify
+```
+
+## Créer un deuxième fichier de configuration
+
+Dans votre répertoire `config-exercice`, créez un fichier nommé `config-demo-2` avec ce contenu:
+
+```shell
+apiVersion: v1
+kind: Config
+preferences: {}
+
+contexts:
+- context:
+    cluster: development
+    namespace: ramp
+    user: developer
+  name: dev-ramp-up
+```
+
+Le fichier de configuration précédent définit un nouveau contexte nommé `dev-ramp-up`.
+
+## Définissez la variable d'environnement KUBECONFIG
+
+Vérifiez si vous avez une variable d'environnement nommée `KUBECONFIG`.
+Si tel est le cas, enregistrez la valeur actuelle de votre variable d'environnement `KUBECONFIG`, afin de pouvoir la restaurer ultérieurement.
+Par exemple:
+
+### Linux
+
+```shell
+export KUBECONFIG_SAVED=$KUBECONFIG
+```
+
+### Windows PowerShell
+
+```shell
+$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
+```
+
+La variable d'environnement `KUBECONFIG` est une liste de chemins vers les fichiers de configuration.
+La liste est délimitée par deux-points pour Linux et Mac et par des points-virgules pour Windows.
+Si vous avez une variable d'environnement `KUBECONFIG`, familiarisez-vous avec les fichiers de configuration de la liste.
+
+Ajoutez temporairement deux chemins à votre variable d'environnement `KUBECONFIG`.
+Par exemple:
+
+### Linux
+
+```shell
+export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
+```
+
+### Windows PowerShell
+
+```shell
+$Env:KUBECONFIG=("config-demo;config-demo-2")
+```
+
+Dans votre répertoire `config-exercice`, entrez cette commande:
+
+```shell
+kubectl config view
+```
+
+La sortie affiche les informations fusionnées de tous les fichiers répertoriés dans votre variable d'environnement `KUBECONFIG`.
+En particulier, notez que les informations fusionnées ont le contexte `dev-ramp-up` du fichier `config-demo-2` et les trois contextes du fichier `config-demo`:
+
+```shell
+contexts:
+- context:
+    cluster: development
+    namespace: frontend
+    user: developer
+  name: dev-frontend
+- context:
+    cluster: development
+    namespace: ramp
+    user: developer
+  name: dev-ramp-up
+- context:
+    cluster: development
+    namespace: storage
+    user: developer
+  name: dev-storage
+- context:
+    cluster: scratch
+    namespace: default
+    user: experimenter
+  name: exp-scratch
+```
+
+Pour plus d'informations sur la manière dont les fichiers kubeconfig sont fusionnés, consultez [Organisation de l'accès au cluster à l'aide des fichiers kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+
+## Explorez le répertoire $HOME/.kube
+
+Si vous avez déjà un cluster, et vous pouvez utiliser `kubectl` pour interagir avec le cluster, alors vous avez probablement un fichier nommé `config` dans le repertoire `$HOME/.kube`.
+
+Allez dans `$ HOME/.kube`, et voyez quels fichiers sont là.
+En règle générale, il existe un fichier nommé `config`.
+Il peut également y avoir d'autres fichiers de configuration dans ce répertoire.
+Familiarisez-vous brièvement avec le contenu de ces fichiers.
+
+## Ajoutez $HOME/.kube/config à votre variable d'environnement KUBECONFIG
+
+Si vous avez un fichier `$ HOME/.kube/config`, et qu'il n'est pas déjà répertorié dans votre variable d'environnement `KUBECONFIG`, ajoutez-le maintenant à votre variable d'environnement `KUBECONFIG`.
+Par exemple:
+
+### Linux
+
+```shell
+export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
+```
+
+### Windows Powershell
+
+```shell
+$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
+```
+
+Affichez les informations de configuration fusionnées à partir de tous les fichiers qui sont maintenant répertoriés dans votre variable d'environnement `KUBECONFIG`.
+Dans votre répertoire config-exercice, entrez:
+
+```shell
+kubectl config view
+```
+
+## Nettoyage
+
+Remettez votre variable d'environnement `KUBECONFIG` à sa valeur d'origine.
+
+Par exemple:
+
+### Linux
+
+```shell
+export KUBECONFIG=$KUBECONFIG_SAVED
+```
+
+### Windows PowerShell
+
+```shell
+$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
+```
+
+## {{% heading "whatsnext" %}}
+
+- [Organisation de l'accès au cluster à l'aide des fichiers kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+- [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
diff --git a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md
new file mode 100644
index 0000000000..eea6e5cd3d
--- /dev/null
+++ b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -0,0 +1,97 @@
+---
+title: Lister toutes les images de conteneur exécutées dans un cluster
+content_type: task
+weight: 100
+---
+
+<!-- overview -->
+
+Cette page montre comment utiliser kubectl pour répertorier toutes les images de conteneur pour les pods s'exécutant dans un cluster.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods exécutés dans un cluster et formater la sortie pour extraire la liste des conteneurs pour chacun.
+
+## Répertorier toutes les images de conteneurs dans tous les namespaces
+
+- Récupérez tous les pods dans tous les namespace à l'aide de `kubectl get pods --all-namespaces`
+- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={..image}`.
+  Cela analysera récursivement le champ `image` du json retourné.
+  - Voir la [reference jsonpath](/docs/reference/kubectl/jsonpath/) pour plus d'informations sur l'utilisation de jsonpath.
+- Formatez la sortie à l'aide des outils standard: `tr`, `sort`, `uniq`
+  - Utilisez `tr` pour remplacer les espaces par des nouvelles lignes
+  - Utilisez `sort` pour trier les résultats
+  - Utilisez `uniq` pour agréger le nombre d'images
+
+```shell
+kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+tr -s '[[:space:]]' '\n' |\
+sort |\
+uniq -c
+```
+
+La commande ci-dessus renverra récursivement tous les champs nommés `image` pour tous les éléments retournés.
+
+Comme alternative, il est possible d'utiliser le chemin absolu vers le champ d'image dans le Pod.
+Cela garantit que le champ correct est récupéré même lorsque le nom du champ est répété, par ex. de nombreux champs sont appelés `name` dans un élément donné:
+
+```shell
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
+```
+
+Le jsonpath est interprété comme suit:
+
+- `.items[*]`: pour chaque valeur renvoyée
+- `.spec`: obtenir les spécifications
+- `.containers[*]`: pour chaque conteneur
+- `.image`: obtenir l'image
+
+{{< note >}}
+Lors de la récupération d'un seul pod par son nom, par exemple `kubectl get pod nginx`, la portion `.items[*]` du chemin doit être omis car un seul pod est renvoyé au lieu d'une liste d'éléments.
+{{< /note >}}
+
+## Liste des images de conteneurs par pod
+
+Le formatage peut être contrôlé davantage en utilisant l'opération `range` pour parcourir les éléments individuellement.
+
+```shell
+kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
+sort
+```
+
+## Filtrage des images de conteneur de liste par label de pod
+
+Pour cibler uniquement les pods correspondant à un label spécifique, utilisez l'indicateur -l.
+Les éléments suivants correspondent uniquement aux pods avec les labels `app=nginx`.
+
+```shell
+kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+```
+
+## Filtrage des images de conteneur de liste par namespace de pod
+
+Pour cibler uniquement les pods dans un namespace spécifique, utilisez l'indicateur de namespace.
+Ce qui suit correspond uniquement aux pods du namespace `kube-system`.
+
+```shell
+kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+```
+
+## Répertorier les images de conteneurs en utilisant un go-template au lieu de jsonpath
+
+Comme alternative à jsonpath, Kubectl peut aussi utiliser les [go-templates](https://golang.org/pkg/text/template/) pour formater la sortie:
+
+```shell
+kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
+```
+
+## {{% heading "whatsnext" %}}
+
+### Reference
+
+- Guide de référence pour [Jsonpath](/docs/reference/kubectl/jsonpath/)
+- Guide de référence pour les [Go template](https://golang.org/pkg/text/template/)
diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
new file mode 100644
index 0000000000..1c45b2b071
--- /dev/null
+++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -0,0 +1,291 @@
+---
+title: Configurer les Liveness, Readiness et Startup Probes
+content_type: task
+weight: 110
+---
+
+<!-- overview -->
+
+Cette page montre comment configurer les liveness, readiness et startup probes pour les conteneurs.
+
+Le [Kubelet](/docs/admin/kubelet/) utilise les liveness probes pour détecter quand redémarrer un conteneur. Par exemple, les Liveness probes pourraient attraper un deadlock dans le cas où une application est en cours d'exécution, mais qui est incapable de traiter les requêtes. Le redémarrage d'un conteneur dans un tel état rend l'application plus disponible malgré les bugs.
+
+Le Kubelet utilise readiness probes pour savoir quand un conteneur est prêt à accepter le trafic. Un Pod est considéré comme prêt lorsque tous ses conteneurs sont prêts.
+Ce signal sert notamment à contrôler les pods qui sont utilisés comme backends pour les Services. Lorsqu'un Pod n'est pas prêt, il est retiré des équilibreurs de charge des Services.
+
+Le Kubelet utilise startup probes pour savoir quand une application d'un conteneur a démarré.
+Si une telle probe est configurée, elle désactive les contrôles de liveness et readiness jusqu'à cela réussit, en s'assurant que ces probes n'interfèrent pas avec le démarrage de l'application.
+Cela peut être utilisé dans le cas des liveness checks sur les conteneurs à démarrage lent, en les évitant de se faire tuer par le Kubelet avant qu'ils ne soient opérationnels.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+## Définir une commande de liveness
+
+De nombreuses applications fonctionnant pour des longues périodes finissent par passer à des états de rupture et ne peuvent pas se rétablir, sauf en étant redémarrées. Kubernetes fournit des liveness probes pour détecter et remédier à ces situations.
+
+Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image  `k8s.gcr.io/busybox`. Voici le fichier de configuration pour le Pod :
+
+{{< codenew file="pods/probe/exec-liveness.yaml" >}}
+
+Dans le fichier de configuration, vous constatez que le Pod a un seul conteneur.
+Le champ `periodSeconds` spécifie que le Kubelet doit effectuer un check de liveness toutes les 5 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 5 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet exécute la commande `cat /tmp/healthy` dans le conteneur. Si la commande réussit, elle renvoie 0, et le Kubelet considère que le conteneur est vivant et en bonne santé. Si la commande renvoie une valeur non nulle, le Kubelet tue le conteneur et le redémarre.
+
+Au démarrage, le conteneur exécute cette commande :
+
+```shell
+/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
+```
+
+Pour les 30 premières secondes de la vie du conteneur, il y a un fichier `/tmp/healthy`.
+Donc pendant les 30 premières secondes, la commande `cat /tmp/healthy` renvoie un code de succès. Après 30 secondes, `cat /tmp/healthy` renvoie un code d'échec.
+
+Créez le Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
+```
+
+Dans les 30 secondes, visualisez les événements du Pod :
+
+```shell
+kubectl describe pod liveness-exec
+```
+
+La sortie indique qu'aucune liveness probe n'a encore échoué :
+
+```shell
+FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message
+--------- --------    -----   ----            -------------           --------    ------      -------
+24s       24s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
+23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
+```
+
+Après 35 secondes, visualisez à nouveau les événements du Pod :
+
+```shell
+kubectl describe pod liveness-exec
+```
+
+Au bas de la sortie, il y a des messages indiquant que les liveness probes ont échoué, et que les conteneurs ont été tués et recréés.
+
+```shell
+FirstSeen LastSeen    Count   From            SubobjectPath           Type        Reason      Message
+--------- --------    -----   ----            -------------           --------    ------      -------
+37s       37s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
+36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
+2s        2s      1   {kubelet worker0}   spec.containers{liveness}   Warning     Unhealthy   Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
+```
+
+Attendez encore 30 secondes et vérifiez que le conteneur a été redémarré :
+
+```shell
+kubectl get pod liveness-exec
+```
+
+La sortie montre que `RESTARTS` a été incrémenté :
+
+```shell
+NAME            READY     STATUS    RESTARTS   AGE
+liveness-exec   1/1       Running   1          1m
+```
+
+## Définir une requête HTTP de liveness
+
+Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration
+d'un Pod qui fait fonctionner un conteneur basé sur l'image `k8s.gcr.io/liveness`.
+
+{{< codenew file="pods/probe/http-liveness.yaml" >}}
+
+Dans le fichier de configuration, vous pouvez voir que le Pod a un seul conteneur.
+Le champ `periodSeconds` spécifie que le Kubelet doit effectuer une liveness probe toutes les 3 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 3 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet envoie une requête HTTP GET au serveur qui s'exécute dans le conteneur et écoute sur le port 8080. Si le handler du chemin `/healthz` du serveur renvoie un code de succès, le Kubelet considère que le conteneur est vivant et en bonne santé. Si le handler renvoie un code d'erreur, le Kubelet tue le conteneur et le redémarre.
+
+Tout code supérieur ou égal à 200 et inférieur à 400 indique un succès. Tout autre code indique un échec.
+
+Vous pouvez voir le code source du serveur dans
+[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
+
+Pendant les 10 premières secondes où le conteneur est en vie, le handler `/healthz` renvoie un statut de 200. Après cela, le handler renvoie un statut de 500.
+
+```go
+http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
+    duration := time.Now().Sub(started)
+    if duration.Seconds() > 10 {
+        w.WriteHeader(500)
+        w.Write([]byte(fmt.Sprintf("erreur: %v", duration.Seconds())))
+    } else {
+        w.WriteHeader(200)
+        w.Write([]byte("ok"))
+    }
+})
+```
+
+Le Kubelet commence à effectuer des contrôles de santé 3 secondes après le démarrage du conteneur.
+Ainsi, les premiers contrôles de santé seront réussis. Mais après 10 secondes, les contrôles de santé échoueront, et le Kubelet tuera et redémarrera le conteneur.
+
+Pour essayer le HTTP liveness check, créez un Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
+```
+
+Après 10 secondes, visualisez les événements du Pod pour vérifier que les liveness probes ont échoué et le conteneur a été redémarré :
+
+```shell
+kubectl describe pod liveness-http
+```
+
+Dans les versions antérieures à la v1.13 (y compris la v1.13), au cas où la variable d'environnement `http_proxy` (ou `HTTP_PROXY`) est définie sur le noeud où tourne un Pod, le HTTP liveness probe utilise ce proxy.
+Dans les versions postérieures à la v1.13, les paramètres de la variable d'environnement du HTTP proxy local n'affectent pas le HTTP liveness probe.
+
+## Définir une TCP liveness probe
+
+Un troisième type de liveness probe utilise un TCP Socket. Avec cette configuration, le Kubelet tentera d'ouvrir un socket vers votre conteneur sur le port spécifié.
+S'il arrive à établir une connexion, le conteneur est considéré comme étant en bonne santé, s'il n'y arrive pas, c'est un échec.
+
+{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
+
+Comme vous le voyez, la configuration pour un check TCP est assez similaire à un check HTTP.
+Cet exemple utilise à la fois des readiness et liveness probes. Le Kubelet transmettra la première readiness probe 5 secondes après le démarrage du conteneur. Il tentera de se connecter au conteneur `goproxy` sur le port 8080. Si la probe réussit, le conteneur sera marqué comme prêt. Kubelet continuera à effectuer ce check tous les 10 secondes.
+
+En plus de la readiness probe, cette configuration comprend une liveness probe.
+Le Kubelet effectuera la première liveness probe 15 secondes après que le conteneur démarre. Tout comme la readiness probe, celle-ci tentera de se connecter au conteneur de `goproxy` sur le port 8080. Si la liveness probe échoue, le conteneur sera redémarré.
+
+Pour essayer la TCP liveness check, créez un Pod :
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
+```
+
+Après 15 secondes, visualisez les événements de Pod pour vérifier les liveness probes :
+
+```shell
+kubectl describe pod goproxy
+```
+
+## Utilisation d'un port nommé
+
+Vous pouvez utiliser un [ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core) nommé pour les HTTP or TCP liveness probes : 
+
+```yaml
+ports:
+- name: liveness-port
+  containerPort: 8080
+  hostPort: 8080
+
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+```
+
+## Protéger les conteneurs à démarrage lent avec des startup probes {#define-startup-probes}
+
+Parfois, vous devez faire face à des applications legacy qui peuvent nécessiter un temps de démarrage supplémentaire lors de leur première initialisation.
+Dans de telles situations, il peut être compliqué de régler les paramètres de la liveness probe sans compromettant la réponse rapide aux blocages qui ont motivé une telle probe.
+L'astuce est de configurer une startup probe avec la même commande, HTTP ou TCP check avec un `failureThreshold * periodSeconds` assez long pour couvrir le pire des scénarios des temps de démarrage.
+
+Ainsi, l'exemple précédent deviendrait :
+
+```yaml
+ports:
+- name: liveness-port
+  containerPort: 8080
+  hostPort: 8080
+
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+  failureThreshold: 1
+  periodSeconds: 10
+
+startupProbe:
+  httpGet:
+    path: /healthz
+    port: liveness-port
+  failureThreshold: 30
+  periodSeconds: 10
+```
+
+Grâce à la startup probe, l'application aura un maximum de 5 minutes (30 * 10 = 300s) pour terminer son démarrage.
+Une fois que la startup probe a réussi, la liveness probe prend le relais pour fournir une réponse rapide aux blocages de conteneurs.
+Si la startup probe ne réussit jamais, le conteneur est tué après 300s puis soumis à la `restartPolicy` (politique de redémarrage) du Pod.
+
+## Définir les readiness probes
+
+Parfois, les applications sont temporairement incapables de servir le trafic.
+Par exemple, une application peut avoir besoin de charger des larges données ou des fichiers de configuration pendant le démarrage, ou elle peut dépendre de services externes après le démarrage.
+Dans ces cas, vous ne voulez pas tuer l'application, mais tu ne veux pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes.
+
+{{< note >}}
+Readiness probes fonctionnent sur le conteneur pendant tout son cycle de vie.
+{{< /note >}}
+
+Readiness probes sont configurées de la même façon que les liveness probes. La seule différence est que vous utilisez le champ `readinessProbe` au lieu du champ `livenessProbe`.
+
+```yaml
+readinessProbe:
+  exec:
+    command:
+    - cat
+    - /tmp/healthy
+  initialDelaySeconds: 5
+  periodSeconds: 5
+```
+
+La configuration des readiness probes HTTP et TCP reste également identique à celle des liveness probes.
+
+Les readiness et liveness probes peuvent être utilisées en parallèle pour le même conteneur.
+L'utilisation des deux peut garantir que le trafic n'atteigne pas un conteneur qui n'est pas prêt et que les conteneurs soient redémarrés en cas de défaillance.
+
+## Configurer les Probes
+
+{{< comment >}}
+Éventuellement, une partie de cette section pourrait être déplacée vers un sujet conceptuel.
+{{< /comment >}}
+
+[Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) ont un certain nombre de champs qui vous pouvez utiliser pour contrôler plus précisément le comportement de la vivacité et de la disponibilité des probes :
+
+* `initialDelaySeconds`: Nombre de secondes après le démarrage du conteneur avant que les liveness et readiness probes ne soient lancées. La valeur par défaut est de 0 seconde. La valeur minimale est 0.
+* `periodSeconds`: La fréquence (en secondes) à laquelle la probe doit être effectuée. La valeur par défaut est de 10 secondes. La valeur minimale est de 1.
+* `timeoutSeconds`: Nombre de secondes après lequel la probe time out. Valeur par défaut à 1 seconde. La valeur minimale est de 1.
+* `successThreshold`: Le minimum de succès consécutifs pour que la probe soit considérée comme réussie après avoir échoué. La valeur par défaut est 1. Doit être 1 pour la liveness probe. La valeur minimale est de 1.
+* `failureThreshold`: Quand un Pod démarre et que la probe échoue, Kubernetes va tenter pour un temps de `failureThreshold` avant d'abandonner. Abandonner en cas de liveness probe signifie le redémarrage du conteneur. En cas de readiness probe, le Pod sera marqué Unready.
+La valeur par défaut est 3, la valeur minimum est 1.
+
+[HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
+ont des champs supplémentaires qui peuvent être définis sur `httpGet` :
+
+* `host`: Nom de l'hôte auquel se connecter, par défaut l'IP du pod. Vous voulez peut être mettre "Host" en httpHeaders à la place.
+* `scheme`: Schéma à utiliser pour se connecter à l'hôte (HTTP ou HTTPS). La valeur par défaut est HTTP.
+* `path`: Chemin d'accès sur le serveur HTTP.
+* `httpHeaders`: En-têtes personnalisés à définir dans la requête. HTTP permet des en-têtes répétés.
+* `port`: Nom ou numéro du port à accéder sur le conteneur. Le numéro doit être dans un intervalle de 1 à 65535.
+
+Pour une probe HTTP, le Kubelet envoie une requête HTTP au chemin et au port spécifiés pour effectuer la vérification. Le Kubelet envoie la probe à l'adresse IP du Pod, à moins que l'adresse ne soit surchargée par le champ optionnel `host` dans `httpGet`. Si Le champ `scheme` est mis à `HTTPS`, le Kubelet envoie une requête HTTPS en ignorant la vérification du certificat. Dans la plupart des scénarios, vous ne voulez pas définir le champ `host`.
+Voici un scénario où vous le mettriez en place. Supposons que le conteneur écoute sur 127.0.0.1 et que le champ `hostNetwork` du Pod a la valeur true. Alors `host`, sous `httpGet`, devrait être défini à 127.0.0.1. Si votre Pod repose sur des hôtes virtuels, ce qui est probablement plus courant, vous ne devriez pas utiliser `host`, mais plutôt mettre l'en-tête `Host` dans `httpHeaders`.
+
+Le Kubelet fait la connexion de la probe au noeud, pas dans le Pod, ce qui signifie que vous ne pouvez pas utiliser un nom de service dans le paramètre `host` puisque le Kubelet est incapable pour le résoudre.
+
+## {{% heading whatsnext %}}
+
+* Pour en savoir plus sur
+[Probes des Conteneurs](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
+
+### Référence
+
+* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
+
+
diff --git a/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md b/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md
new file mode 100644
index 0000000000..cb5a99cbe3
--- /dev/null
+++ b/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md
@@ -0,0 +1,91 @@
+---
+title: Partager l'espace de nommage des processus entre les conteneurs d'un Pod
+min-kubernetes-server-version: v1.10
+content_type: task
+weight: 160
+---
+
+<!-- overview -->
+
+{{< feature-state state="stable" for_k8s_version="v1.17" >}}
+
+Cette page montre comment configurer le partage de l'espace de noms d'un processus pour un pod. Lorsque le partage de l'espace de noms des processus est activé, les processus d'un conteneur sont visibles pour tous les autres conteneurs de ce pod.
+
+Vous pouvez utiliser cette fonctionnalité pour configurer les conteneurs coopérants, comme un conteneur de sidecar de gestionnaire de journaux, ou pour dépanner les images de conteneurs qui n'incluent pas d'utilitaires de débogage comme un shell.
+
+## {{% heading prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+## Configurer un Pod
+
+Le partage de l'espace de nommage du processus est activé en utilisant le champ `shareProcessNamespace` de `v1.PodSpec`. Par exemple:
+
+{{< codenew file="pods/share-process-namespace.yaml" >}}
+
+1. Créez le pod `nginx` sur votre cluster :
+
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
+    ```
+
+1. Attachez-le au conteneur `shell` et lancez `ps` :
+
+    ```shell
+    kubectl attach -it nginx -c shell
+    ```
+
+    Si vous ne verrez pas d'invite de commande, appuyez sur la touche Entrée.
+
+    ```
+    / # ps ax
+    PID   USER     TIME  COMMAND
+        1 root      0:00 /pause
+        8 root      0:00 nginx: master process nginx -g daemon off;
+       14 101       0:00 nginx: worker process
+       15 root      0:00 sh
+       21 root      0:00 ps ax
+    ```
+
+Vous pouvez signaler les processus dans d'autres conteneurs. Par exemple, envoyez `SIGHUP` à
+nginx pour relancer le processus de worker. Cela nécessite la fonctionnalité `SYS_PTRACE`.
+
+```
+/ # kill -HUP 8
+/ # ps ax
+PID   USER     TIME  COMMAND
+    1 root      0:00 /pause
+    8 root      0:00 nginx: master process nginx -g daemon off;
+   15 root      0:00 sh
+   22 101       0:00 nginx: worker process
+   23 root      0:00 ps ax
+```
+
+Il est même possible d'accéder aux autres conteneurs en utilisant le lien `/proc/$pid/root`.
+
+```
+/ # head /proc/8/root/etc/nginx/nginx.conf
+
+user  nginx;
+worker_processes  1;
+
+error_log  /var/log/nginx/error.log warn;
+pid        /var/run/nginx.pid;
+
+
+events {
+    worker_connections  1024;
+```
+
+## Comprendre le processus de partage de l'espace de nommage
+
+Les pods partagent de nombreuses ressources, il est donc logique qu'elles partagent également un espace de noms des processus. Pour certaines images de conteneur, on peut envisager de les isoler les uns des autres. Il est donc important de comprendre ces différences :
+
+1. **Le processus de conteneur n'a plus de PID 1.** Certaines images de conteneurs refusent de démarrer sans PID 1 (par exemple, les conteneurs utilisant `systemd`) ou exécuter des commandes comme `kill -HUP 1` pour signaler le processus du conteneur. Dans les pods avec un espace de noms partagé du processus, `kill -HUP 1` signalera la sandbox du pod.  (`/pause` dans l'exemple ci-dessus.)
+
+1. **Les processus sont visibles par les autres conteneurs du pod.**  Cela inclut tout les informations visibles dans `/proc`, comme les mots de passe passés en argument ou les variables d'environnement. Celles-ci ne sont protégées que par des permissions Unix régulières.
+
+1. **Les systèmes de fichiers des conteneurs sont visibles par les autres conteneurs du pod à travers le lien `/proc/$pid/root`.** Cela rend le débogage plus facile, mais cela signifie aussi que les secrets du système de fichiers ne sont protégés que par les permissions du système de fichiers.
+
diff --git a/content/fr/docs/tasks/tools/install-minikube.md b/content/fr/docs/tasks/tools/install-minikube.md
index c3fcb56f34..b079eba6ec 100644
--- a/content/fr/docs/tasks/tools/install-minikube.md
+++ b/content/fr/docs/tasks/tools/install-minikube.md
@@ -75,7 +75,7 @@ Si vous n'avez pas déjà un hyperviseur installé, installez-le maintenant pour
 
 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
 
-Minikube supporte également une option `--vm-driver=none` qui exécute les composants Kubernetes sur la machine hôte et dans pas dans une VM.
+Minikube supporte également une option `--vm-driver=none` qui exécute les composants Kubernetes sur la machine hôte et pas dans une VM.
 L'utilisation de ce pilote nécessite [Docker](https://www.docker.com/products/docker-desktop) et un environnement Linux mais pas un hyperviseur.
 
 Si vous utilisez le pilote `none` dans Debian ou un dérivé, utilisez les paquets` .deb` pour
diff --git a/content/fr/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/fr/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index 564745c86d..c8137aa987 100644
--- a/content/fr/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/fr/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Pour interagir avec le terminal, veuillez utiliser la version bureau / tablette.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/fr/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/fr/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 99bab76a41..de064cd22e 100644
--- a/content/fr/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/fr/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -23,7 +23,7 @@ weight: 20
                 Pour interagir avec le terminal, veuillez utiliser la version bureau / tablette.
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/fr/examples/pods/probe/exec-liveness.yaml b/content/fr/examples/pods/probe/exec-liveness.yaml
new file mode 100644
index 0000000000..07bf75f85c
--- /dev/null
+++ b/content/fr/examples/pods/probe/exec-liveness.yaml
@@ -0,0 +1,21 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  labels:
+    test: liveness
+  name: liveness-exec
+spec:
+  containers:
+  - name: liveness
+    image: k8s.gcr.io/busybox
+    args:
+    - /bin/sh
+    - -c
+    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
+    livenessProbe:
+      exec:
+        command:
+        - cat
+        - /tmp/healthy
+      initialDelaySeconds: 5
+      periodSeconds: 5
diff --git a/content/fr/examples/pods/probe/http-liveness.yaml b/content/fr/examples/pods/probe/http-liveness.yaml
new file mode 100644
index 0000000000..670af18399
--- /dev/null
+++ b/content/fr/examples/pods/probe/http-liveness.yaml
@@ -0,0 +1,21 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  labels:
+    test: liveness
+  name: liveness-http
+spec:
+  containers:
+  - name: liveness
+    image: k8s.gcr.io/liveness
+    args:
+    - /server
+    livenessProbe:
+      httpGet:
+        path: /healthz
+        port: 8080
+        httpHeaders:
+        - name: Custom-Header
+          value: Awesome
+      initialDelaySeconds: 3
+      periodSeconds: 3
diff --git a/content/fr/examples/pods/probe/tcp-liveness-readiness.yaml b/content/fr/examples/pods/probe/tcp-liveness-readiness.yaml
new file mode 100644
index 0000000000..08fb77ff0f
--- /dev/null
+++ b/content/fr/examples/pods/probe/tcp-liveness-readiness.yaml
@@ -0,0 +1,22 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: goproxy
+  labels:
+    app: goproxy
+spec:
+  containers:
+  - name: goproxy
+    image: k8s.gcr.io/goproxy:0.1
+    ports:
+    - containerPort: 8080
+    readinessProbe:
+      tcpSocket:
+        port: 8080
+      initialDelaySeconds: 5
+      periodSeconds: 10
+    livenessProbe:
+      tcpSocket:
+        port: 8080
+      initialDelaySeconds: 15
+      periodSeconds: 20
diff --git a/content/fr/examples/pods/share-process-namespace.yaml b/content/fr/examples/pods/share-process-namespace.yaml
new file mode 100644
index 0000000000..af812732a2
--- /dev/null
+++ b/content/fr/examples/pods/share-process-namespace.yaml
@@ -0,0 +1,17 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  shareProcessNamespace: true
+  containers:
+  - name: nginx
+    image: nginx
+  - name: shell
+    image: busybox
+    securityContext:
+      capabilities:
+        add:
+        - SYS_PTRACE
+    stdin: true
+    tty: true
diff --git a/content/fr/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml b/content/fr/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml
new file mode 100644
index 0000000000..858ecd1b9b
--- /dev/null
+++ b/content/fr/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml
@@ -0,0 +1,26 @@
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod
+  labels:
+    foo: bar
+spec:
+  topologySpreadConstraints:
+  - maxSkew: 1
+    topologyKey: zone
+    whenUnsatisfiable: DoNotSchedule
+    labelSelector:
+      matchLabels:
+        foo: bar
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+        - matchExpressions:
+          - key: zone
+            operator: NotIn
+            values:
+            - zoneC
+  containers:
+  - name: pause
+    image: k8s.gcr.io/pause:3.1
diff --git a/content/fr/examples/pods/topology-spread-constraints/one-constraint.yaml b/content/fr/examples/pods/topology-spread-constraints/one-constraint.yaml
new file mode 100644
index 0000000000..1062e8a489
--- /dev/null
+++ b/content/fr/examples/pods/topology-spread-constraints/one-constraint.yaml
@@ -0,0 +1,17 @@
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod
+  labels:
+    foo: bar
+spec:
+  topologySpreadConstraints:
+  - maxSkew: 1
+    topologyKey: zone
+    whenUnsatisfiable: DoNotSchedule
+    labelSelector:
+      matchLabels:
+        foo: bar
+  containers:
+  - name: pause
+    image: k8s.gcr.io/pause:3.1
diff --git a/content/fr/examples/pods/topology-spread-constraints/two-constraints.yaml b/content/fr/examples/pods/topology-spread-constraints/two-constraints.yaml
new file mode 100644
index 0000000000..6c0ab0009b
--- /dev/null
+++ b/content/fr/examples/pods/topology-spread-constraints/two-constraints.yaml
@@ -0,0 +1,23 @@
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod
+  labels:
+    foo: bar
+spec:
+  topologySpreadConstraints:
+  - maxSkew: 1
+    topologyKey: zone
+    whenUnsatisfiable: DoNotSchedule
+    labelSelector:
+      matchLabels:
+        foo: bar
+  - maxSkew: 1
+    topologyKey: node
+    whenUnsatisfiable: DoNotSchedule
+    labelSelector:
+      matchLabels:
+        foo: bar
+  containers:
+  - name: pause
+    image: k8s.gcr.io/pause:3.1
diff --git a/content/fr/includes/partner-style.css b/content/fr/includes/partner-style.css
index 7aeb255dd5..dc120872e0 100644
--- a/content/fr/includes/partner-style.css
+++ b/content/fr/includes/partner-style.css
@@ -82,7 +82,6 @@
 .button{
   max-width: 100%;
 	box-sizing: border-box;
-	font-family: "Roboto", sans-serif;
 	margin: 0;
 	display: inline-block;
 	border-radius: 6px;
diff --git a/content/id/_index.html b/content/id/_index.html
index e95d661b76..10c0775866 100644
--- a/content/id/_index.html
+++ b/content/id/_index.html
@@ -43,7 +43,6 @@ Kubernetes sebagai <i>open source</i> memberikan kamu kebebasan untuk menggunaka
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
-        <br>
         <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">Hadiri KubeCon di Barcelona tanggal 20-23 Mei 2019</a>
         <br>
         <br>
diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md
index 75f3b97189..e00745d1d9 100644
--- a/content/id/docs/concepts/cluster-administration/logging.md
+++ b/content/id/docs/concepts/cluster-administration/logging.md
@@ -52,7 +52,7 @@ Kamu dapat menambahkan parameter `--previous` pada perintah `kubectl logs` untuk
 
 ![Node-level _logging_](/images/docs/user-guide/logging/logging-node-level.png)
 
-Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam file dalam format json.
+Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam berkas dalam format json.
 
 {{< note >}}
 _Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang terpisah. Saat menggunakan _logging driver_ Docker, tidak ada dukungan untuk menangani pesan _multi-line_. Kamu harus menangani pesan _multi-line_ pada level agen log atau yang lebih tinggi.
diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md
index 7350470fa3..c5b6a8912f 100644
--- a/content/id/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md
@@ -203,7 +203,7 @@ Misalnya sebuah Node N sedang dipertimbangkan untuk pemindahan Pod sehingga sebu
 *   Pod P dipertimbangkan untuk Node N.
 *   Pod Q sedang berjalan pada Node lain pada Zona yang sama dengan Node N.
 *   Pod P memiliki anti-afinitas yang berlaku pada seluruh Zona terhadap Pod Q (`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`).
+    topology.kubernetes.io/zone`).
 *   Tidak ada kasus anti-afinitas lain antara Pod P dengan Pod-pod lainnya pada Zona tersebut.
 *   Untuk dapat menjadwalkan Pod P pada Node N, Pod Q dapat dipindahkan, tetapi
     Scheduler tidak melakukan pemindahan Pod antar Node. Jadi, Pod P akan
diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md
index 40875648ff..c0a1e750bf 100644
--- a/content/id/docs/concepts/configuration/secret.md
+++ b/content/id/docs/concepts/configuration/secret.md
@@ -61,7 +61,7 @@ dan _password_ yang harus digunakan oleh Pod-Pod tersebut berada pada mesin loka
 dalam bentuk _file-file_ `./username.txt` dan `./password.txt`.
 
 ```shell
-# Buatlah file yang selanjutnya akan digunakan pada contoh-contoh selanjutnya
+# Buatlah berkas yang selanjutnya akan digunakan pada contoh-contoh selanjutnya
 echo -n 'admin' > ./username.txt
 echo -n '1f2d1e2e67df' > ./password.txt
 ```
@@ -271,7 +271,7 @@ dispesifikasikan di dalam sebuah _file_ `kustomization.yaml` di dalam sebuah dir
 
 Sebagai contoh, untuk menghasilan sebuah Secret dari _file-file_ `./username.txt` dan `./password.txt`
 ```shell
-# Membuat sebuah file kustomization.yaml dengan SecretGenerator
+# Membuat sebuah berkas kustomization.yaml dengan SecretGenerator
 cat <<EOF >./kustomization.yaml
 secretGenerator:
 - name: db-user-pass
@@ -310,7 +310,7 @@ username.txt:    5 bytes
 Sebagai contoh, untuk membuat sebuah Secret dari literal `username=admin` dan `password=secret`,
 kamu dapat menspesifikasikan _generator_ Secret pada _file_ `kustomization.yaml` sebagai
 ```shell
-# Membuat sebuah file kustomization.yaml dengan menggunakan SecretGenerator
+# Membuat sebuah berkas kustomization.yaml dengan menggunakan SecretGenerator
 $ cat <<EOF >./kustomization.yaml
 secretGenerator:
 - name: db-user-pass
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md
index aa2ee52152..43bba4d783 100644
--- a/content/id/docs/concepts/overview/components.md
+++ b/content/id/docs/concepts/overview/components.md
@@ -2,6 +2,9 @@
 title: Komponen-Komponen Kubernetes
 content_type: concept
 weight: 20
+description: >
+  Sebuah klaster Kubernetes terdiri dari komponen yang merepresentasikan 
+  bidang kontrol dan sepasang mesin yaitu _nodes_.
 card:
   name: concepts
   weight: 20
diff --git a/content/id/docs/concepts/overview/kubernetes-api.md b/content/id/docs/concepts/overview/kubernetes-api.md
index 35bf3f67dc..336c48f60f 100644
--- a/content/id/docs/concepts/overview/kubernetes-api.md
+++ b/content/id/docs/concepts/overview/kubernetes-api.md
@@ -2,6 +2,9 @@
 title: API Kubernetes
 content_type: concept
 weight: 30
+description: >
+  API Kubernetes membuatmu dapat melakukan _query_ dan memanipulasi keadaan objek dalam Kubernetes.
+  Inti dari bidang kontrol Kubernetes adalah  _server_ API dan HTTP API yang diekspos. Pengguna, berbagai bagian klastermu, dan komponen eksternal semuanya berkomunikasi satu sama lain melalui server API.
 card:
   name: concepts
   weight: 30
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/_index.md b/content/id/docs/concepts/overview/object-management-kubectl/_index.md
deleted file mode 100644
index 909abd79ce..0000000000
--- a/content/id/docs/concepts/overview/object-management-kubectl/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Pengelolaan Objek dengan kubectl"
-weight: 50
----
-
diff --git a/content/id/docs/concepts/overview/what-is-kubernetes.md b/content/id/docs/concepts/overview/what-is-kubernetes.md
index de35f65b29..a0e0982633 100644
--- a/content/id/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/id/docs/concepts/overview/what-is-kubernetes.md
@@ -2,6 +2,16 @@
 title: Apa itu Kubernetes?
 content_type: concept
 weight: 10
+description: >
+  Kubernetes merupakan _platform open-source_ yang digunakan untuk melakukan
+  manajemen _workloads_ aplikasi yang dikontainerisasi, serta menyediakan
+  konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem
+  yang besar dan berkembang cepat. _Service_, _support_, dan perkakas
+  Kubernetes tersedia secara meluas. Kubernetes merupakan _platform open-source_ 
+  yang digunakan untuk melakukan manajemen _workloads_ aplikasi yang dikontainerisasi, 
+  serta menyediakan konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada 
+  di dalam ekosistem yang besar dan berkembang cepat. _Service_, _support_, 
+  dan perkakas Kubernetes tersedia secara meluas.
 card:
   name: concepts
   weight: 10
diff --git a/content/id/docs/concepts/overview/working-with-objects/_index.md b/content/id/docs/concepts/overview/working-with-objects/_index.md
index 53a2d7c9b3..6849cbe870 100644
--- a/content/id/docs/concepts/overview/working-with-objects/_index.md
+++ b/content/id/docs/concepts/overview/working-with-objects/_index.md
@@ -1,5 +1,9 @@
 ---
 title: "Menggunakan Objek-Objek Kubernetes"
 weight: 40
+description: >
+  Objek-objek Kubernetes adalah entitas yang tetap dalam sistem Kubernetes. 
+  Kubernetes menggunakan entitas tersebut untuk merepresentasikan keadaan dari klastermu.
+  Pelajari tentang objek model Kubernetes dan bagaimana menggunakan objek tersebut.
 ---
 
diff --git a/content/id/docs/concepts/scheduling/scheduling-framework.md b/content/id/docs/concepts/scheduling/scheduling-framework.md
index f08f9f40c7..b3580eb7ac 100644
--- a/content/id/docs/concepts/scheduling/scheduling-framework.md
+++ b/content/id/docs/concepts/scheduling/scheduling-framework.md
@@ -76,6 +76,14 @@ mereka dikonfigurasi. Jika ada _plugin_ Filter menandai Node menjadi _infeasible
 maka _plugin_ yang lainnya tidak akan dipanggil untuk Node itu. Node-Node dapat dievaluasi 
 secara bersamaan.
 
+### PostFilter {#post-filter}
+
+Plugin ini disebut setelah fase Filter, tetapi hanya ketika tidak ada node yang layak
+ditemukan untuk pod. Plugin dipanggil dalam urutan yang dikonfigurasi. Jika
+plugin postFilter menandai node sebagai 'Schedulable', plugin yang tersisa
+tidak akan dipanggil. Implementasi PostFilter yang khas adalah preemption, yang
+mencoba membuat pod dapat di menjadwalkan dengan mendahului Pod lain.
+
 ### PreScore {#pre-score}
 
 _Plugin_ ini digunakan untuk melakukan pekerjaan "pra-penilaian", yang 
diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md
index fe510b846d..cba7ff9337 100644
--- a/content/id/docs/concepts/services-networking/network-policies.md
+++ b/content/id/docs/concepts/services-networking/network-policies.md
@@ -81,7 +81,7 @@ kecuali penyedia jaringan mendukung network policy.
 membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`.  Informasi generik mengenai
 bagaimana bekerja dengan _file_ `config`, dapat dilihat di
 [Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/),
-serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/).
+serta [Manajemen Objek](/id/docs/tasks/manage-kubernetes-objects/).
 
 **spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu.
 
diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md
index 00bf4e6241..5136a00415 100644
--- a/content/id/docs/concepts/services-networking/service.md
+++ b/content/id/docs/concepts/services-networking/service.md
@@ -15,7 +15,7 @@ weight: 10
 [`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*.
 Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut
 tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara
-khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*).
+khusus bertugas membuat dan menghapus `Pod` secara dinamis (misalnya, pada proses *scaling out* atau *scaling in*).
 Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP
 yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil.
 Hal ini kemudian menimbulkan pertanyaan baru: apabila sebuah sekumpulan `Pod` (yang selanjutnya kita sebut _backend_)
diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md
index 5ddfc2aaa6..96461e16a3 100644
--- a/content/id/docs/concepts/storage/volume-snapshots.md
+++ b/content/id/docs/concepts/storage/volume-snapshots.md
@@ -43,7 +43,7 @@ VolumeSnapshotContent merupakan bagian dari sumber daya klaster. VolumeSnapshot
 Ada dua cara untuk menyediakan _snapshot_: secara statis maupun dinamis.
 
 #### Statis
-Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes.
+Seorang administrator klaster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes.
 
 #### Dinamis
 Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja
diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md
index 8d593f1eba..fca45bbd74 100644
--- a/content/id/docs/concepts/storage/volumes.md
+++ b/content/id/docs/concepts/storage/volumes.md
@@ -16,7 +16,7 @@ Pengetahuan tentang [Pod](/docs/user-guide/pods) disarankan.
 
 ## Latar Belakang
 
-Docker juga memiliki konsep _[volume]_(https://docs.docker.com/storage/), walaupun konsepnya Docker agak lebih fleksibel dan kurang dikelola. Pada Docker, sebuah volume adalah sesederhana sebuah direktori pada _disk_ atau  di dalam Container lainnya. _Lifetime_ tidak dikelola dan hingga baru-baru ini hanya ada volume yang didukung _disk_ lokal. Docker sekarang menyediakan _driver_ untuk volume, namun fungsionalitasnya masih sangat terbatas (misalnya hingga Docker 1.7 hanya ada satu _driver_ volume yang diizinkan untuk setiap Container, dan tidak ada cara untuk menyampaikan parameter kepada volume).
+Docker juga memiliki konsep _[volume](https://docs.docker.com/storage/)_, walaupun konsepnya Docker agak lebih fleksibel dan kurang dikelola. Pada Docker, sebuah volume adalah sesederhana sebuah direktori pada _disk_ atau  di dalam Container lainnya. _Lifetime_ tidak dikelola dan hingga baru-baru ini hanya ada volume yang didukung _disk_ lokal. Docker sekarang menyediakan _driver_ untuk volume, namun fungsionalitasnya masih sangat terbatas (misalnya hingga Docker 1.7 hanya ada satu _driver_ volume yang diizinkan untuk setiap Container, dan tidak ada cara untuk menyampaikan parameter kepada volume).
 
 Sebaliknya, sebuah Volume Kubernetes memiliki _lifetime_ yang gamblang - sama dengan _lifetime_ Pod yang berisi Volume tersebut. Oleh karena itu, sebuah Volume bertahan lebih lama dari Container-container yang berjalan di dalam Pod tersebut, dan data di Volum tersebut juga dipertahankan melewati diulangnya Container. Tentu saja, saat sebuah Pod berakhir, Volume tersebut juga akan berakhir/terhapus. Dan mungkin lebih penting lagi, Kubernetes mendukung banyak jenis Volume, dan sebuah Pod dapat menggunakan sebanyak apapun Volume secara bersamaan.
 
diff --git a/content/id/docs/concepts/workloads/controllers/deployment.md b/content/id/docs/concepts/workloads/controllers/deployment.md
index 8eae6c579f..b4e728cd92 100644
--- a/content/id/docs/concepts/workloads/controllers/deployment.md
+++ b/content/id/docs/concepts/workloads/controllers/deployment.md
@@ -96,7 +96,7 @@ Dalam contoh ini:
   3. Untuk melihat status rilis Deployment, jalankan `kubectl rollout status deployment.v1.apps/nginx-deployment`. Keluaran akan tampil seperti berikut:
     ```shell
     Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-    deployment.apps/nginx-deployment successfully rolled out
+    deployment "nginx-deployment" successfully rolled out
     ```
 
   4. Jalankan `kubectl get deployments` lagi beberapa saat kemudian. Keluaran akan tampil seperti berikut:
@@ -179,7 +179,7 @@ Ikuti langkah-langkah berikut untuk membarui Deployment:
     ```
     atau
     ```
-    deployment.apps/nginx-deployment successfully rolled out
+    deployment "nginx-deployment" successfully rolled out
     ```
 
 Untuk menampilkan detail lain dari Deployment yang terbaru:
@@ -826,7 +826,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 Keluaran akan tampil seperti berikut:
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 $ echo $?
 0
 ```
diff --git a/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index f1d970a473..8c5bb1a227 100644
--- a/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -249,13 +249,13 @@ apiVersion: kubescheduler.config.k8s.io/v1alpha2
 kind: KubeSchedulerConfiguration
 
 profiles:
-  pluginConfig:
-  - name: PodTopologySpread
-    args:
-      defaultConstraints:
-      - maxSkew: 1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
-        whenUnsatisfiable: ScheduleAnyway
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints:
+            - maxSkew: 1
+              topologyKey: topology.kubernetes.io/zone
+              whenUnsatisfiable: ScheduleAnyway
 ```
 
 {{< note >}}
diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md
index e25a3a9104..63ee548459 100644
--- a/content/id/docs/concepts/workloads/pods/pod.md
+++ b/content/id/docs/concepts/workloads/pods/pod.md
@@ -109,7 +109,7 @@ Pod dapat digunakan untuk menjalankan beberapa aplikasi yang terintegrasi
 secara vertikal (misalnya LAMP), namun motivasi utamanya adalah untuk mendukung
 berlokasi bersama, mengelola program pembantu, diantaranya adalah:
 
-* sistem pengelolaan konten, pemuat file dan data, manajer _cache_ lokal, dll.
+* sistem pengelolaan konten, pemuat berkas dan data, manajer _cache_ lokal, dll.
 * catatan dan _checkpoint_ cadangan, kompresi, rotasi, dll.
 * pengamat perubahan data, pengintip catatan, adapter pencatatan dan pemantauan,
 penerbit peristiwa, dll.
diff --git a/content/id/docs/reference/_index.md b/content/id/docs/reference/_index.md
new file mode 100644
index 0000000000..2191ab6df8
--- /dev/null
+++ b/content/id/docs/reference/_index.md
@@ -0,0 +1,13 @@
+---
+title: Referensi
+linkTitle: "Referensi"
+main_menu: true
+weight: 70
+content_type: concept
+---
+
+<!-- overview -->
+
+Bagian dari dokumentasi Kubernetes ini berisi referensi-referensi.
+
+<!-- TODO: translate the rest -->
\ No newline at end of file
diff --git a/content/id/docs/reference/access-authn-authz/_index.md b/content/id/docs/reference/access-authn-authz/_index.md
new file mode 100644
index 0000000000..5571044289
--- /dev/null
+++ b/content/id/docs/reference/access-authn-authz/_index.md
@@ -0,0 +1,4 @@
+---
+title: Mengakses API
+weight: 20
+---
diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md
index 49aa20ed6e..03e7d2e076 100644
--- a/content/id/docs/reference/access-authn-authz/rbac.md
+++ b/content/id/docs/reference/access-authn-authz/rbac.md
@@ -6,39 +6,40 @@ weight: 70
 ---
 
 <!-- overview -->
-Kontrol akses berbasis peran (RBAC) adalah metode pengaturan akses ke sumber daya komputer 
-atau jaringan berdasarkan peran pengguna individu dalam organisasi kamu.
+_Role-based access control_ (RBAC) atau kontrol akses berbasis rol adalah metode pengaturan akses ke sumber daya komputer 
+atau jaringan berdasarkan rol pengguna individu dalam organisasimu.
 
 
 <!-- body -->
-Otorisasi RBAC menggunakan `rbac.authorization.k8s.io` kelompok API untuk mengendalikan keputusan
-otorisasi, memungkinkan kamu untuk mengkonfigurasi kebijakan secara dinamis melalui API Kubernetes.
+Otorisasi RBAC menggunakan {{< glossary_tooltip text="grup API" term_id="api-group" >}} `rbac.authorization.k8s.io` untuk mengendalikan keputusan
+otorisasi. Hal ini memungkinkanmu untuk mengonfigurasi kebijakan secara dinamis melalui
+API Kubernetes.
 
-Untuk mengaktifkan RBAC, jalankan Kubernetes dengan _flag_ `--authorization-mode` atur 
-dengan daftar yang dipisahkan koma dengan menyertakan `RBAC`;
+Untuk mengaktifkan RBAC, jalankan {{< glossary_tooltip text="server API" term_id="kube-apiserver" >}} dengan _flag_ `--authorization-mode` diatur 
+dengan daftar yang dipisahkan koma yang menyertakan `RBAC`;
 sebagai contoh:
 ```shell
 kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
 ```
 
-## Objek API  {#api-overview}
+## Objek API {#api-overview}
 
 API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole,
-RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
+RoleBinding dan ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain.
 
 {{< caution >}}
 Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan
 ke klaster saat kamu belajar, lihat
-[pencegahan eskalasi hak istimewa dan _bootstrap_](#privilege-eskalasi-pencegahan-dan-bootstrap)
+[pencegahan eskalasi privilese dan _bootstrapping_](#pencegahan-eskalasi-privilese-dan-bootstrapping)
 untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beberapa perubahan.
 {{< /caution >}}
 
 ### Role dan ClusterRole
 
-Sebuah RBAC Role atau ClusterRole berisi aturan yang mewakili sekumpulan izin.
+Sebuah Role RBAC atau ClusterRole memuat aturan yang mewakili sekumpulan izin.
 Izin bersifat aditif (tidak ada aturan "tolak").
 
-Sebuah Role selalu mengatur izin dalam Namespace tertentu;
+Sebuah Role selalu mengatur izin dalam {{< glossary_tooltip text="Namespace" term_id="namespace" >}} tertentu;
 ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada.
 
 ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role
@@ -48,16 +49,16 @@ tidak mungkin keduanya.
 ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk:
 
 1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih
-1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace
-1. mendefinisikan izin pada sumber daya yang dicakup klaster
+2. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace
+3. mendefinisikan izin pada sumber daya dalam lingkup klaster
 
-Jika kamu ingin mendefinisikan sebuah peran dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan
-peran di level klaster, gunakan ClusterRole.
+Jika kamu ingin mendefinisikan sebuah rol dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan
+rol di level klaster, gunakan ClusterRole.
  
 #### Contoh Role 
 
 Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan 
-untuk memberikan akses baca pada Pod:
+untuk memberikan akses baca pada {{< glossary_tooltip text="Pod" term_id="pod" >}}:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -66,7 +67,7 @@ metadata:
   Namespace: default
   name: pod-reader
 rules:
-- apiGroups: [""] # "" mengindikasikan core API group
+- apiGroups: [""] # "" mengindikasikan grup API inti
   resources: ["pods"]
   verbs: ["get", "watch", "list"]
 ```
@@ -74,16 +75,16 @@ rules:
 #### Contoh ClusterRole
 
 ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role.
-Karena ClusterRole memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke:
+Karena ClusterRole memiliki lingkup klaster, kamu juga dapat menggunakannya untuk memberikan akses ke:
 
-* sumber daya lingkup-klaster (seperti Nodes)
+* sumber daya lingkup klaster (seperti {{< glossary_tooltip text="Node" term_id="node" >}})
 * berbagai _endpoint_ non-sumber daya (seperti `/healthz`)
 * sumber daya Namespace (seperti Pod), di semua Namespace
  Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan 
 `kubectl get pods --all-namespaces`.
 
 Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada
-Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana itu [terikat](#rolebinding-dan-clusterrolebinding)):
+{{< glossary_tooltip text="Secret" term_id="secret" >}} di Namespace tertentu, atau di semua Namespace (tergantung bagaimana [keterikatannya](#rolebinding-dan-clusterrolebinding)):
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -112,7 +113,7 @@ memberikan akses tersebut pada lingkup klaster.
 
 RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding
 dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding.
-Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu dapat menggunakan 
+Jika kamu ingin memasangkan ClusterRole ke semua Namespace di dalam klastermu, kamu dapat menggunakan 
 ClusterRoleBinding.
 
 Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan
@@ -121,12 +122,12 @@ Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan
 #### Contoh RoleBinding
 
 Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane"
-pada Namespace bawaan.
-Ini memungkinkan "jane" untuk membaca Pod di Namespace bawaan.
+pada Namespace "default".
+Ini memungkinkan "jane" untuk membaca Pod di Namespace "default".
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# Role binding memungkinkan "jane" untuk membaca Pod di Namespace bawaan
+# RoleBinding memungkinkan "jane" untuk membaca Pod di Namespace "default"
 # Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut.
 kind: RoleBinding
 metadata:
@@ -138,7 +139,7 @@ subjects:
   name: jane # "name" peka huruf besar-kecil
   apiGroup: rbac.authorization.k8s.io
 roleRef:
-  # "roleRef" menentukan pengikatan ke Role / ClusterRole
+  # "roleRef" menentukan pengikatan (binding) ke Role / ClusterRole
   kind: Role # ini harus Role atau ClusterRole
   name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan
   apiGroup: rbac.authorization.k8s.io
@@ -146,22 +147,22 @@ roleRef:
 
 RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam
 ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini
-memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam
+memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klastermu, lalu menggunakannya kembali di dalam
 beberapa Namespace.
 
 Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole,
-"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secret di dalam Namespace "development", 
-karena Namespace RoleBinding (di dalam metadata-nya) adalah "development".
+"dave" (subjek, peka kapital) hanya akan dapat membaca Secret di dalam Namespace "development", 
+karena Namespace RoleBinding (di dalam metadatanya) adalah "development".
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# role binding memungkinkan "dave" untuk membaca Secret di Namespace "development".
+# RoleBinding memungkinkan "dave" untuk membaca Secret di Namespace "development".
 # Kamu sudah harus memiliki ClusterRole bernama "secret-reader".
 kind: RoleBinding
 metadata:
   name: read-secrets
   #
-  # Namespace dari RoleBinding menentukan dimana izin akan diberikan.  
+  # Namespace dari RoleBinding menentukan di mana izin akan diberikan.  
   # Ini hanya memberikan izin di dalam Namespace "development".
   namespace: development
 subjects:
@@ -182,37 +183,37 @@ membaca Secret di berbagai Namespace.
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace.
+# ClusterRoleBinding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace.
 kind: ClusterRoleBinding
 metadata:
   name: read-secrets-global
 subjects:
 - kind: Group
-  name: manager # Nama peka huruf besar-kecil
+  name: manager # Nama peka kapital
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: ClusterRole
   name: secret-reader
   apiGroup: rbac.authorization.k8s.io
 ```
-Setelah kamu membuat sebuat ikatan, kamu tidak dapat mengganti Role atau ClusterRole dirujuk.
-Jika kamu mencoba mengganti sebuah ikatan `roleRef`, kamu mendapatkan kesalahan validasi. Jika kamu
-tidak ingin mengganti `roleRef` untuk sebuah ikatan, kamu harus menghapus objek ikatan tersebut dan membuat
+Setelah kamu membuat ClusterRoleBinding, kamu tidak dapat mengganti Role atau ClusterRole yang dirujuk.
+Jika kamu mencoba mengganti `roleRef` dari sebuah ClusterRoleBinding, kamu akan mendapatkan galat validasi. Jika kamu
+tidak ingin mengganti `roleRef` untuk sebuah ClusterRoleBinding, kamu harus menghapus objek ClusterRoleBinding tersebut dan membuat
 sebuah pengganti.
 
 Ada dua alasan untuk pembatasan tersebut:
 
-1. Membuat `roleRef` tidak dapat diubah memungkinkan seseorang untuk melakukan `update` pada objek ikatan yang ada, 
-sehingga mereka dapat mengelola daftar subyek, tanpa bisa berubah
-Role yang diberikan kepada subyek tersebut.
+1. Membuat `roleRef` menjadi tidak dapat diubah (_immutable_) memungkinkan pemberian izin `update` kepada seseorang pada objek ClusterRoleBinding yang ada, 
+sehingga mereka dapat mengelola daftar subjek, tanpa bisa berubah
+Role yang diberikan kepada subjek tersebut.
 
-1. Ikatan pada Role yang berbeda adalah ikatan yang berbeda secara fundamental.
-Mengharuskan sebuah ikatan untuk dihapus/diciptakan kembali untuk dalam upaya mengubah `roleRef` akan
-memastikan daftar lengkap subyek dalam ikatan akan diberikan diberikan
-Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef
-tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada Role baru).
+2. ClusterRoleBinding dengan Role yang berbeda adalah ClusterRoleBinding yang berbeda secara fundamental.
+Mengharuskan sebuah ClusterRoleBinding untuk dihapus/diciptakan kembali untuk mengubah `roleRef` akan
+memastikan daftar lengkap subjek dalam ClusterRoleBinding akan diberikan
+Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada `roleRef`
+tanpa memastikan semua subjek yang seharusnya diberikan izin pada Role baru).
 
-Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbaharui berkas manifes yang mengandung objek RBAC,
+Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbarui berkas manifes yang mengandung objek RBAC,
 dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk.
 Lihat [penggunaan perintah dan contoh](#kubectl-auth-reconcile) untuk informasi tambahan.
 
@@ -222,7 +223,7 @@ Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan
 nama objek, seperti `pods` untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama
 dengan yang muncul di URL untuk berbagai _endpoint_ API yang relevan.
 Beberapa Kubernetes APIs melibatkan 
-_subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat seperti:
+_subresource_, seperti log untuk Pod. Permintaan untuk log Pod terlihat seperti:
 
 ```http
 GET /api/v1/namespaces/{namespace}/pods/{name}/log
@@ -248,7 +249,7 @@ rules:
 Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`.
 Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya.
 Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah
-ConfigMap bernama `my-configmap`:
+{{< glossary_tooltip term_id="ConfigMap" >}} bernama `my-configmap`:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -268,18 +269,18 @@ rules:
 
 {{< note >}}
 Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`, 
-Keterbatasan ini dikarenakan nama objek yang tidak dikenal pada waktu otorisasi.
+keterbatasan ini dikarenakan nama objek tidak diketahui pada waktu otorisasi.
 {{< /note >}}
 
-### Agregat ClusterRole
+### ClusterRole gabungan
 
 Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan.
-_Controller_, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole
-dengan `aggregationRule`. `AggregationRule` mendefinisikan label
-Selector yang digunakan oleh _Controller_ untuk mencocokkan objek ClusterRole lain 
+Pengontrol, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole
+dengan `aggregationRule`. `AggregationRule` mendefinisikan
+{{< glossary_tooltip text="Selector" term_id="selector" >}} label yang digunakan oleh pengontrol untuk mencocokkan objek ClusterRole lain 
 yang harus digabungkan ke dalam `rules`.
 
-Berikut adalah contoh ClusterRole agregat:
+Berikut adalah contoh ClusterRole gabungan:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -290,12 +291,12 @@ aggregationRule:
   clusterRoleSelectors:
   - matchLabels:
       rbac.example.com/aggregate-to-monitoring: "true"
-rules: [] # _Control plane_ secara otomatis mengisi rules
+rules: [] # Control plane secara otomatis mengisi rules
 ```
 
-Jika kamu membuat ClusterRole baru yang cocok dengan _selector_ label dari ClusterRole agregat yang ada,
-perubahan itu memicu penambahan aturan baru ke dalam ClusterRole agregat.
-Berikut adalah contoh yang menambahkan aturan ke "monitoring" ClusterRole, dengan membuat sebuah
+Jika kamu membuat ClusterRole baru yang cocok dengan label Selector dari ClusterRole gabungan yang ada,
+maka perubahan itu akan memicu penambahan aturan baru ke dalam ClusterRole gabungan.
+Berikut adalah contoh yang menambahkan aturan ke ClusterRole "monitoring", dengan membuat sebuah
 ClusterRole lain berlabel `rbac.example.com/aggregate-to-monitoring: true`.
 
 ```yaml
@@ -313,12 +314,12 @@ rules:
   verbs: ["get", "list", "watch"]
 ```
 
-[Role bawaan pengguna](#role-dan-role-binding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu,
-sebagai administrator klaster, menambahkan aturan untuk sumber daya kustom, seperti yang dilayani oleh CustomResourceDefinition
-atau _aggregated_ server API, untuk memperluas Role bawaan.
+[Role bawaan pengguna](#role-dan-rolebinding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu,
+sebagai administrator klaster, menambahkan aturan untuk sumber daya ubah suai, seperti yang dilayani oleh {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}}
+atau server API gabungan, untuk memperluas Role bawaan.
 
-Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya kustom
-bernama CronTab, sedangkan Role "view" hanya dapat melakukan tindakan membaca sumber daya CronTab.
+Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya ubah suai
+bernama CronTab, sedangkan Role "view" hanya dapat membaca sumber daya CronTab.
 Kamu dapat mengasumsikan bahwa objek CronTab dinamai `"crontab"` dalam URL yang terlihat oleh server API.
 
 ```yaml
@@ -350,10 +351,10 @@ rules:
 
 #### Contoh Role
 
-Contoh berikut adalah potongan dari objek Role atau ClusterRole, yang hanya menampilkan
+Contoh berikut adalah potongan dari objek Role atau ClusterRole yang hanya menampilkan
 bagian `rules`.
 
-Mengizinkan pembacaan sumber daya `"pods`` pada kumpulan API inti:
+Mengizinkan pembacaan sumber daya `"pods"` pada {{< glossary_tooltip text="grup API" term_id="api-group" >}} inti:
 
 ```yaml
 rules:
@@ -366,7 +367,7 @@ rules:
 ```
 
 Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan `"deployments"` 
-di bagian sumber daya dari URL) pada masing-masing kumpulan API `"extensions"` dan `"apps"`:
+di bagian sumber daya dari URL) pada masing-masing grup API `"extensions"` dan `"apps"`:
 
 ```yaml
 rules:
@@ -378,8 +379,8 @@ rules:
   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
 ```
 
-Mengizinkan pembacaan pada Pods pada kumpulan API inti, dan juga serta pembacaan atau penulisan Job
-di kumpulan API `"batch"` atau `"extensions"`:
+Mengizinkan pembacaan pada Pods pada grup API inti, dan juga serta pembacaan atau penulisan Job
+di grup API `"batch"` atau `"extensions"`:
 
 ```yaml
 rules:
@@ -397,8 +398,8 @@ rules:
   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
 ```
 
-Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan
-RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah Namespace):
+Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan suatu
+RoleBinding untuk membatasi ke satu ConfigMap di satu Namespace):
 
 ```yaml
 rules:
@@ -411,7 +412,7 @@ rules:
   verbs: ["get"]
 ```
 
-Mengizinkan pembacaan sumber daya `"nodes"` pada kumpulan API inti (karena sebuah node
+Mengizinkan pembacaan sumber daya `"nodes"` pada grup API inti (karena sebuah node
 ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding
 agar efektif):
 
@@ -434,33 +435,33 @@ rules:
   verbs: ["get", "post"]
 ```
 
-### Mengacu Pada Subjek
+### Mengacu pada subjek
 
 RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek.
-Subjek dapat berupa kelompok, pengguna atau ServiceAccount.
+Subjek dapat berupa kelompok, pengguna atau {{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}.
 
-Kubernetes merepresentasikan _username_ sebagai string.
+Kubernetes merepresentasikan _username_ sebagai _string_.
 Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com";
-atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster
-untuk mengkonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/)
+atau ID pengguna numerik yang direpresentasikan sebagai _string_. Terserah kamu sebagai administrator klaster
+untuk mengonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/)
 sehingga otentikasi menghasilkan _username_ dalam format yang kamu inginkan.
 
 {{< caution >}}
 Awalan `system:` direservasi untuk sistem Kubernetes, jadi kamu harus memastikan
 bahwa kamu tidak memiliki pengguna atau grup dengan nama yang dimulai dengan `system:` secara tidak sengaja.
-Selain awalan khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun
+Selain prefiks khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun
 untuk nama pengguna.
 {{< /caution >}}
 
 Di Kubernetes, modul otentikasi menyediakan informasi grup.
 Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu,
-selain awalan `system:` yang sudah direservasi.
+selain prefiks `system:` yang sudah direservasi.
 
 [ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`.
 
 {{< note >}}
-- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_.
-- `system:serviceaccounts:` (jamak) adalah awalan untuk ServiceAccount grup.
+- `system:serviceaccount:` (tunggal) adalah prefiks untuk _username_ ServiceAccount.
+- `system:serviceaccounts:` (jamak) adalah prefiks untuk grup ServiceAccount.
 {{< /note >}}
 
 #### Contoh RoleBinding {#role-binding-examples}
@@ -543,33 +544,33 @@ subjects:
   apiGroup: rbac.authorization.k8s.io
 ```
 
-## Role dan RoleBinding Bawaan
+## Role dan RoleBinding bawaan
 
 API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. 
-Sebagian besar dari objek berawalan `system:`, menunjukkan bahwa sumber daya tersebut
-secara langsung dikelolah oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan
+Sebagian besar dari objek dengan prefiks `system:` menunjukkan bahwa sumber daya tersebut
+secara langsung dikelola oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan
 `kubernetes.io/bootstrapping=rbac-defaults`.
 
 {{< caution >}}
 Berhati-hatilah saat memodifikasi CLusterRole dan ClusterRoleBinding dengan nama yang
-memiliki awalan `system:`.
-Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi.
+memiliki prefiks `system:`.
+Modifikasi sumber daya ini dapat mengakibatkan malfungsi klaster.
 {{< /caution >}}
 
-### Rekonsiliasi Otomatis
+### Rekonsiliasi otomatis
 
-Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, 
-dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang.
+Pada setiap penyalaan (_start-up_), server API memperbarui ClusterRole bawaan dengan berbagai izin yang hilang, 
+dan memperbarui ClusterRoleBinding bawaan dengan subjek yang hilang.
 Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role 
 dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes.
 
-Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate`
+Untuk menonaktifkan rekonsiliasi ini, atur anotasi `rbac.authorization.kubernetes.io/autoupdate`
 pada ClusterRole bawaan atau RoleBinding bawaan menjadi `false`.
-Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak berfungsi.
+Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan malfungsi klaster.
 
-Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif.
+Rekonsiliasi otomatis diaktifkan secara bawaan jika pemberi otorisasi RBAC aktif.
 
-### Role API discovery {#discovery-roles}
+### Role diskoveri API {#discovery-roles}
 
 RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman
 untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API.
@@ -581,13 +582,13 @@ kubectl get clusterroles system:discovery -o yaml
 ```
 
 {{< note >}}
-Jika kamu mengubah ClusterRole tersebut, perubahan kamu akan ditimpa pada penyalaan ulang server API melalui 
+Jika kamu mengubah ClusterRole tersebut, maka perubahanmu akan ditimpa pada penyalaan ulang server API melalui 
 [rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah Role secara manual, 
 atau nonaktifkan rekonsiliasi otomatis
 {{< /note >}}
 
 <table>
-<caption>Kubernetes RBAC API discovery roles</caption>
+<caption>Role diskoveri API Kubernetes RBAC</caption>
 <colgroup><col width="25%" /><col width="25%" /><col /></colgroup>
 <tr>
 <th>ClusterRole Bawaan</th>
@@ -596,29 +597,29 @@ atau nonaktifkan rekonsiliasi otomatis
 </tr>
 <tr>
 <td><b>system:basic-user</b></td>
-<td><b>system:authenticated</b> group</td>
-<td>Mengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum  v1.14, Role ini juga terikat pada <tt>system:unauthenticated</tt> secara bawaan.</td>
+<td>Grup <b>system:authenticated</b></td>
+<td>Mengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, Role ini juga terikat pada <tt>system:unauthenticated</tt> secara bawaan.</td>
 </tr>
 <tr>
 <td><b>system:discovery</b></td>
-<td><b>system:authenticated</b> group</td>
-<td>Mengizinkan akses baca pada berbagai _API discovery endpoint_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada <tt>system:unauthenticated</tt> secara bawaan.</td>
+<td>Grup <b>system:authenticated</b></td>
+<td>Mengizinkan akses baca pada berbagai <i>endpoint</i> diskoveri API yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada <tt>system:unauthenticated</tt> secara bawaan.</td>
 </tr>
 <tr>
 <td><b>system:public-info-viewer</b></td>
-<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
+<td>Grup <b>system:authenticated</b> dan <b>system:unauthenticated</b></td>
 <td>Mengizinkan akses baca pada informasi yang tidak sensitif tentang klaster. Diperkenalkan pada Kubernetes v1.14.</td>
 </tr>
 </table>
 
-### Role Pengguna
+### Role pengguna
 
 Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk Role pengguna.
-Ini termasuk Role super-user (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan
+Ini termasuk Role _super-user_ (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan
 menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu 
 dengan menggunakan RoleBinding (`admin`, `edit`, `view`).
 
-ClusterRole menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buat sebuah CLusterRole
+ClusterRole menggunakan [ClusterRole gabungan](#clusterrole-gabungan) untuk mengizinkan administrator untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buatlah sebuah CLusterRole
 dengan satu atau lebih label berikut:
 
 ```yaml
@@ -638,149 +639,156 @@ metadata:
 </tr>
 <tr>
 <td><b>cluster-admin</b></td>
-<td><b>system:masters</b> group</td>
-<td>Mengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. 
-Ketika digunakan pada <b>ClusterRoleBinding</b>, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh Namespace. 
-Ketika digunakan pada <b>RoleBinding</b>, ini memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri.</td>
+<td>Grup <b>system:masters</b></td>
+<td>Mengizinkan akses <i>super-user</i> untuk melakukan berbagai aksi pada berbagai sumber daya. 
+Ketika digunakan pada <b>ClusterRoleBinding</b>, Role ini akan memberikan kendali penuh terhadap semua sumber daya pada klaster dan seluruh Namespace. 
+Ketika digunakan pada <b>RoleBinding</b>, Role ini akan memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri.</td>
 </tr>
 <tr>
 <td><b>admin</b></td>
-<td>None</td>
-<td>mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan <b>RoleBinding</b>.
+<td>Tidak ada</td>
+<td>mengizinkan akses administrator, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan <b>RoleBinding</b>.
 Jika digunakan dalam <b>RoleBinding</b>, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah Namespace,
 termasuk kemampuan untuk membuat Role dan RoleBinding dalam Namespace. 
 Role ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke Namespace itu sendiri.</td>
 </tr>
 <tr>
 <td><b>edit</b></td>
-<td>None</td>
+<td>Tidak ada</td>
 <td>Mengizinkan akses baca/tulis pada seluruh objek dalam Namespace.
 
-Role ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding.
+Role ini tidak memungkinkan untuk melihat dan mengubah Role dan RoleBinding.
 Namun, Role ini memungkinkan untuk mengakses Secret dan menjalankan Pod seperti ServiceAccount dalam Namespace, 
 sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di Namespace. 
 </td>
 </tr>
 <tr>
 <td><b>view</b></td>
-<td>None</td>
+<td>Tidak ada</td>
 <td>Mengizinkan akses baca untuk melihat hampir seluruh objek dalam Namespace.
 
 Ini tidak memungkinkan untuk melihat Role dan RoleBinding.
 
 Role ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan
 akses ke kredensial ServiceAccount dalam Namespace, yang akan memungkinkan akses API sebagai
-ServiceAccount apapun di Namespace (bentuk eskalasi hak istimewa).
+ServiceAccount apapun di Namespace (bentuk eskalasi privilese).
 </td>
 </tr>
 </table>
 
-### Core component roles
+### Role komponen inti
 
 <table>
-<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup>
+<thead>
 <tr>
-<th>Default ClusterRole</th>
-<th>Default ClusterRoleBinding</th>
-<th>Description</th>
+<th>ClusterRole Bawaan</th>
+<th>ClusterRoleBinding Bawaan</th>
+<th>Deskripsi</th>
 </tr>
+</thead>
+<tbody>
 <tr>
 <td><b>system:kube-scheduler</b></td>
-<td><b>system:kube-scheduler</b> user</td>
-<td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.</td>
+<td>Pengguna <b>system:kube-scheduler</b></td>
+<td>Mengizinkan akses ke sumber daya yang dibutuhkan oleh komponen {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}.</td>
 </tr>
 <tr>
 <td><b>system:volume-scheduler</b></td>
-<td><b>system:kube-scheduler</b> user</td>
-<td>Allows access to the volume resources required by the kube-scheduler component.</td>
+<td>Pengguna <b>system:kube-scheduler</b></td>
+<td>Mengizinkan akses ke sumber daya volume yang dibutuhkan oleh komponen kube-scheduler.</td>
 </tr>
 <tr>
 <td><b>system:kube-controller-manager</b></td>
-<td><b>system:kube-controller-manager</b> user</td>
-<td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component.
-The permissions required by individual controllers are detailed in the <a href="#controller-roles">controller roles</a>.</td>
+<td>Pengguna <b>system:kube-controller-manager</b></td>
+<td>Mengizinkan akses ke sumber daya yang dibutuhkan oleh komponen {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
+Izin yang diperlukan oleh masing-masing pengontrol dirincikan di <a href="#controller-roles">Role pengontrol</a>.</td>
 </tr>
 <tr>
 <td><b>system:node</b></td>
-<td>None</td>
-<td>Allows access to resources required by the kubelet, <b>including read access to all secrets, and write access to all pod status objects</b>.
+<td>Tidak ada</td>
+<td>Mengizinkan akses ke sumber daya yang dibutuhkan oleh kubelet, <b>termasuk akses baca ke semua Secret, dan akses rulis ke semua objek status Pod</b>.
 
-You should use the <a href="/docs/reference/access-authn-authz/node/">Node authorizer</a> and <a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction admission plugin</a> instead of the <tt>system:node</tt> role, and allow granting API access to kubelets based on the Pods scheduled to run on them.
+Kamu dapat menggunakan <a href="/docs/reference/access-authn-authz/node/">pemberi otorisasi Node</a> dan <a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">pugasan admisi NodeRestriction</a> daripada Role <tt>system:node</tt>, dan mengizinkan pemberian akses API ke kubelet berdasarkan Pod yang dijadwalkan untuk berjalan di atasnya.
 
-The <tt>system:node</tt> role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8.
+Role <tt>system:node</tt> hanya ada untuk kompatibilitas dengan klaster Kubernetes yang ditingkatkan dari versi sebelum v1.8.
 </td>
 </tr>
 <tr>
 <td><b>system:node-proxier</b></td>
-<td><b>system:kube-proxy</b> user</td>
-<td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.</td>
+<td>Pengguna <b>system:kube-proxy</b></td>
+<td>Mengizinkan akses ke sumber daya yang dibutuhkan oleh komponen {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}.</td>
 </tr>
+</tbody>
 </table>
 
-### Other component roles
+### Role komponen lainnya
 
 <table>
-<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup>
+<thead>
 <tr>
-<th>Default ClusterRole</th>
-<th>Default ClusterRoleBinding</th>
-<th>Description</th>
+<th>ClusterRole Bawaan</th>
+<th>ClusterRoleBinding Bawaan</th>
+<th>Deskripsi</th>
 </tr>
+</thead>
+<tbody>
 <tr>
 <td><b>system:auth-delegator</b></td>
-<td>None</td>
-<td>Allows delegated authentication and authorization checks.
-This is commonly used by add-on API servers for unified authentication and authorization.</td>
+<td>Tidak ada</td>
+<td>Mengizinkan pemeriksaan otentikasi dan otorisasi yang didelegasikan.
+Hal ini umumnya digunakan oleh pugasan server API untuk otentikasi dan otorisasi terpadu.</td>
 </tr>
 <tr>
 <td><b>system:heapster</b></td>
-<td>None</td>
-<td>Role for the <a href="https://github.com/kubernetes/heapster">Heapster</a> component (deprecated).</td>
+<td>Tidak ada</td>
+<td>Role untuk komponen <a href="https://github.com/kubernetes/heapster">Heapster</a> (usang).</td>
 </tr>
 <tr>
 <td><b>system:kube-aggregator</b></td>
-<td>None</td>
-<td>Role for the <a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a> component.</td>
+<td>Tidak ada</td>
+<td>Role untuk komponen <a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a>.</td>
 </tr>
 <tr>
 <td><b>system:kube-dns</b></td>
-<td><b>kube-dns</b> service account in the <b>kube-system</b> namespace</td>
-<td>Role for the <a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a> component.</td>
+<td>ServiceAccount <b>kube-dns</b> dalam Namespace <b>kube-system</b></td>
+<td>Role untuk komponen <a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a>.</td>
 </tr>
 <tr>
 <td><b>system:kubelet-api-admin</b></td>
-<td>None</td>
-<td>Allows full access to the kubelet API.</td>
+<td>Tidak ada</td>
+<td>Mengizinkan akses penuh ke API kubelet.</td>
 </tr>
 <tr>
 <td><b>system:node-bootstrapper</b></td>
-<td>None</td>
-<td>Allows access to the resources required to perform
-<a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">kubelet TLS bootstrapping</a>.</td>
+<td>Tidak ada</td>
+<td>Mengizinkan akses ke sumber daya yang dibutuhkan untuk melakukan <a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/"><i>bootstrapping</i> TLS kubelet</a>.</td>
 </tr>
 <tr>
 <td><b>system:node-problem-detector</b></td>
-<td>None</td>
-<td>Role for the <a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> component.</td>
+<td>Tidak ada</td>
+<td>Role untuk komponen <a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a>.</td>
 </tr>
 <tr>
 <td><b>system:persistent-volume-provisioner</b></td>
-<td>None</td>
-<td>Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td>
+<td>Tidak ada</td>
+<td>Mengizinkan akses ke sumber daya yang dibutuhkan oleh kebanyakan <a href="/docs/concepts/storage/persistent-volumes/#provisioner">penyedia volume dinamis</a>.</td>
 </tr>
+<tbody>
 </table>
 
-### Roles for built-in controllers {#controller-roles}
+### Role untuk pengontrol bawaan {#controller-roles}
 
-The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs
-{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes
-control plane.
-When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller
-using a separate service account.
-Corresponding roles exist for each built-in controller, prefixed with `system:controller:`.
-If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops
-using its own credential, which must be granted all the relevant roles.
-These roles include:
+{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+pada Kubernetes menjalankan {{< glossary_tooltip term_id="controller" text="pengontrol" >}}
+yang merupakan bawaan dari _control plane_ Kubernetes. Ketika dijalankan dengan
+`--use-service-account-credentials`, kube-controller-manager memulai setiap pengontrol
+menggunakan ServiceAccount yang terpisah. Role yang sesuai tersedia untuk setiap
+pengontrol bawaan, dengan prefiks `system:controller:`. Jika manajer pengontrol tidak
+dimulai dengan `--use-service-account-credentials`, maka manajer pengontrol akan menjalankan
+semua kontrol tertutup (_control loop_) menggunakan kredensialnya sendiri, yang harus
+diberikan semua Role yang relevan. Role yang dimaksud termasuk:
 
 * `system:controller:attachdetach-controller`
 * `system:controller:certificate-controller`
@@ -810,40 +818,48 @@ These roles include:
 * `system:controller:statefulset-controller`
 * `system:controller:ttl-controller`
 
-## Privilege escalation prevention and bootstrapping
+## Pencegahan eskalasi privilese dan _bootstrapping_
 
-The RBAC API prevents users from escalating privileges by editing roles or role bindings.
-Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use.
+API RBAC mencegah pengguna dari mengeskalasikan privilese dengan mengubah Role atau RoleBinding.
+Karena hal ini diberlakukan pada level API, maka hal ini berlaku bahkan ketika pemberi otorisasi
+RBAC tidak digunakan.
 
-### Restrictions on role creation or update
+### Pembatasan pada pembuatan dan pembaruan Role
 
-You can only create/update a role if at least one of the following things is true:
+Kamu hanya bisa membuat/memperbaru suatu Role jika setidaknya satu dari beberapa
+hal di bawah ini terpenuhi:
 
-1. You already have all the permissions contained in the role, at the same scope as the object being modified
-(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
-2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
+1. Kamu telah mempunyai semua izin yang termuat dalam Role tersebut, pada lingkup yang sama
+dengan objek yang diubah
+(di seluruh klaster untuk sebuah ClusterRole, di dalam Namespace yang sama atau keseluruhan
+klaster untuk sebuah Role).
+2. Kamu diberikan izin eksplisit untuk melakukan `escalate` pada sumber daya `roles` atau
+`clusterroles` di dalam grup API `rbac.authorization.k8s.io`.
 
-For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole
-containing that permission. To allow a user to create/update roles:
+Sebagai contoh, jika `user-1` tidak memiliki kemampuan untuk mendaftar Secret di seluruh klaster,
+maka `user-1` tidak akan bisa membuat suatu ClusterRole yang memuat izin tersebut. Agar pengguna
+bisa membuat/memperbaru Role:
 
-1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired.
-2. Grant them permission to include specific permissions in the roles they create/update:
-    * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
-    * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group
+1. Berikan sebuah Role yang memungkinkan mereka untuk membuat/memperbarui objek Role atau CLusterRole, sesuai keinginan.
+2. Berikan mereka izin untuk menyertakan izin tertentu dalam Role yang mereka buat/perbarui:
+    * secara implisit, dengan memberikan mereka izin tersebut (jika mereka mencoba untuk membuat atau mengubah sebuah Role atau ClusterRole dengan izin yang tidak mereka miliki, permintaan API akan dilarang)
+    * atau secara eksplisit mengizinkan penentuan izin apa pun dalam sebuah `Role` atau `ClusterRole` dengan memberikan mereka izin untuk melakukan `escalate` pada sumber daya `roles` atau `clusterroles` di dalam grup API `rbac.authorization.k8s.io`
 
-### Restrictions on role binding creation or update
+### Pembatasan pada pembuatan dan pembaruan RoleBinding
 
-You can only create/update a role binding if you already have all the permissions contained in the referenced role
-(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role.
-For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding
-to a role that grants that permission. To allow a user to create/update role bindings:
+Kamu hanya bisa membuat/memperbarui suatu RoleBinding jika kamu telah mempunyai semua izin yang
+terdapat pada Role yang diacu (di dalam lingkup yang sama dengan RoleBinding) *atau* jika
+kamu telah terotorisasi untuk melakukan `bind` pada role yang diacu.
+Sebagai contoh, jika `user-1` tidak mempunyai kemampuan untuk mendaftar Secret di seluruh klaster,
+maka `user-1` tidak akan bisa membuat sebuah ClusterRoleBinding dengan Role yang memberikan
+izin tersebut. Agar pengguna bisa membuat/memperbarui RoleBinding:
 
-1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired.
-2. Grant them permissions needed to bind a particular role:
-    * implicitly, by giving them the permissions contained in the role.
-    * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole).
+1. Berikan sebuah Role yang mengizinkan mereka untuk membuat/memperbarui objek RoleBinding atau ClusterRoleBinding, sesuai keinginan.
+2. Berikan mereka izin yang dibutuhkan untuk RoleBinding tertentu:
+    * secara implisit, dengan memberikan mereka izin yang yang termuat pada Role yang dimaksud
+    * secara eksplisit, dengan memberikan mereka izin untuk melakukan `bind` pada Role (atau ClusterRole) tertentu
 
-For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`:
+Sebagai contoh, ClusterRole dan RoleBinding berikut akan memungkinkan `user-1` untuk memberikan Role `admin`, `edit`, dan `view` kepada pengguna lain di dalam Namespace `user-1-namespace`:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -874,43 +890,44 @@ subjects:
   name: user-1
 ```
 
-When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have.
-To bootstrap initial roles and role bindings:
+Ketika melakukan _bootstrapping_ Role dan RoleBinding yang pertama, pengguna awal perlu memberikan
+izin yang belum mereka miliki.
+Untuk melakukan _bootstrapping_ Role dan RoleBinding awal:
 
-* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings.
-* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization.
+* Gunakan kredensial dengan grup "system:masters" yang terikat ke Role _super-user_ "cluster-admin" oleh RoleBinding bawaan.
+* Jika server API dijalankan dengan porta tidak aman diaktifkan (`--insecure-port`), kamu juga bisa membuat panggilan API via porta tersebut, yang tidak memberlakukan otentikasi atau otorisasi.
 
-## Command-line utilities
+## Utilitas baris perintah
 
 ### `kubectl create role`
 
-Creates a Role object defining permissions within a single namespace. Examples:
+Membuat sebuah objek Role yang mendefinisikan izin di dalam sebuah Namespace. Contoh:
 
-* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods:
+* Membuat sebuah Role bernama "pod-reader" yang memungkinkan pengguna untuk melakukan `get`, `watch` dan `list` pada Pod:
 
     ```shell
     kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
     ```
 
-* Create a Role named "pod-reader" with resourceNames specified:
+* Membuat sebuah Role bernama "pod-reader" dengan resourceNames yang ditentukan:
 
     ```shell
     kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
     ```
 
-* Create a Role named "foo" with apiGroups specified:
+* Membuat sebuah Role bernama "foo" dengan apiGroups yang ditentukan:
 
     ```shell
     kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
     ```
 
-* Create a Role named "foo" with subresource permissions:
+* Membuat sebuah Role bernama "foo" dengan izin sub-sumber daya:
 
     ```shell
     kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
     ```
 
-* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name:
+* Membuat sebuah Role bernama "my-component-lease-holder" dengan izin untuk mendapatkan/memperbarui suatu sumber daya dengan nama tertentu:
 
     ```shell
     kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
@@ -918,39 +935,39 @@ Creates a Role object defining permissions within a single namespace. Examples:
 
 ### `kubectl create clusterrole`
 
-Creates a ClusterRole. Examples:
+Membuat sebuah ClusterRole. Contoh:
 
-* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods:
+* Membuat sebuah ClusterRole bernama "pod-reader" yang memungkinkan pengguna untuk merlakukan `get`, `watch` dan `list` pada Pod:
 
     ```shell
     kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
     ```
 
-* Create a ClusterRole named "pod-reader" with resourceNames specified:
+* Membuat sebuah ClusterRole bernama "pod-reader" dengan recourceNames yang ditentukan:
 
     ```shell
     kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
     ```
 
-* Create a ClusterRole named "foo" with apiGroups specified:
+* Membuat sebuah ClusterRole bernama "foo" dengan apiGroups yang ditentukan:
 
     ```shell
     kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
     ```
 
-* Create a ClusterRole named "foo" with subresource permissions:
+* Membuat sebuah ClusterRole bernama "foo" dengan izin sub-sumber daya:
 
     ```shell
     kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
     ```
 
-* Create a ClusterRole named "foo" with nonResourceURL specified:
+* Membuat sebuah ClusterRole bernama "foo" dengan nonResourceURL yang ditentukan:
 
     ```shell
     kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
     ```
 
-* Create a ClusterRole named "monitoring" with an aggregationRule specified:
+* Membuat sebuah ClusterRole bernama "monitoring" dengan aggregationRule yang ditentukan:
 
     ```shell
     kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
@@ -958,21 +975,21 @@ Creates a ClusterRole. Examples:
 
 ### `kubectl create rolebinding`
 
-Grants a Role or ClusterRole within a specific namespace. Examples:
+Memberikan sebuah Role atau ClusterRole di dalam Namespace tertentu. Contoh:
 
-* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob":
+* Di dalam Namespace "acme", memberikan izin dalam ClusterRole "admin" kepada pengguna bernama "bob":
 
     ```shell
     kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
     ```
 
-* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp":
+* Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "acme" yang bernama "myapp":
 
     ```shell
     kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
     ```
 
-* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp":
+* Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "myappnamespace" yang bernama "myapp":
 
     ```shell
     kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
@@ -980,21 +997,21 @@ Grants a Role or ClusterRole within a specific namespace. Examples:
 
 ### `kubectl create clusterrolebinding`
 
-Grants a ClusterRole across the entire cluster (all namespaces). Examples:
+Memberikan sebuah ClusterRole di seluruh klaster (semua Namespace). Contoh:
 
-* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root":
+* Di seluruh klaster, memberikan izin dalam ClusterRole "cluster-admin" kepada pengguna bernama "root":
 
     ```shell
     kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
     ```
 
-* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy":
+* Di seluruh klaster, memberikan izin dalam ClusterRole "system:node-proxier" kepada user bernama "system:kube-proxy":
 
     ```shell
     kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
     ```
 
-* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme":
+* Di seluruh klaster, memberikan izin dalam ClusterRole "view" ke ServiceAccount bernama "myapp" di dalam Namespace "acme":
 
     ```shell
     kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
@@ -1002,55 +1019,58 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples:
 
 ### `kubectl auth reconcile` {#kubectl-auth-reconcile}
 
-Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file.
+Membuat atau memperbarui objek API `rbac.authorization.k8s.io/v1` dari suatu berkas manifes.
 
-Missing objects are created, and the containing namespace is created for namespaced objects, if required.
+Objek yang hilang dibuat, dan Namespace dibuat untuk objek dengan Namespace jika diperlukan.
 
-Existing roles are updated to include the permissions in the input objects,
-and remove extra permissions if `--remove-extra-permissions` is specified.
+Role yang sudah ada diperbarui untuk menyertakan izin pada objek masukan,
+dan menghilangkan izin tambahan jika `--remove-extra-permissions` ditetapkan.
 
-Existing bindings are updated to include the subjects in the input objects,
-and remove extra subjects if `--remove-extra-subjects` is specified.
+RoleBinding yang sudah ada diperbarui untuk menyertakan subjek pada objek masukan,
+dan menghapus subjek tambahan jika `--remove-extra-subjects` ditetapkan.
 
-Examples:
+Contoh:
 
-* Test applying a manifest file of RBAC objects, displaying changes that would be made:
+* Mencoba menerapkan sebuah berkas manifes dari objek RBAC, menampilkan perubahan yang akan dibuat:
 
     ```
     kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
     ```
 
-* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings):
+* Menerapkan sebuah berkas manifes dari objek RBAC, mempertahankan izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding):
 
     ```shell
     kubectl auth reconcile -f my-rbac-rules.yaml
     ```
 
-* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings):
+* Menerapkan sebuah berkas manifes dari objek RBAC, menghapus izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding):
 
     ```shell
     kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
     ```
 
-## ServiceAccount permissions {#service-account-permissions}
+## Izin ServiceAccount {#service-account-permissions}
 
-Default RBAC policies grant scoped permissions to control-plane components, nodes,
-and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
-(beyond discovery permissions given to all authenticated users).
+Kebijakan RBAC bawaan memberikan izin terbatas ke komponen _control plane_, Node, dan pengontrol,
+akan tetapi *tidak memberikan izin* ke ServiceAccount di luar Namespace `kube-system`
+(di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi).
 
-This allows you to grant particular roles to particular ServiceAccounts as needed.
-Fine-grained role bindings provide greater security, but require more effort to administrate.
-Broader grants can give unnecessary (and potentially escalating) API access to
-ServiceAccounts, but are easier to administrate.
+Hal ini memungkinkan kamu untuk memberika Role tertentu ke ServiceAccount tertentu sesuai
+kebutuhan. RoleBinding yang sangat detail memberikan keamanan yang lebih baik,
+akan tetapi membutuhkan lebih banyak usaha untuk pengaturannya. Pemberian izin
+yang lebih luas dapat memberikan akses API yang tidak perlu (dan berpotensi tereskalasi)
+ke ServiceAccount, akan tetapi pengaturannya lebih mudah.
 
-In order from most secure to least secure, the approaches are:
+Dalam urutan dari yang paling aman ke yang paling tidak aman, pendekatannya adalah:
 
-1. Grant a role to an application-specific service account (best practice)
+1. Memberikan sebuah Role ke ServiceAccount aplikasi tertentu (praktik terbaik)
 
-    This requires the application to specify a `serviceAccountName` in its pod spec,
-    and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
+    Hal ini membutuhkan aplikasi untuk menentukan sebuah `serviceAccountName`
+    di dalam spesifikasi Pod-nya, dan untuk ServiceAccount yang akan dibuat (via
+    API, manifes aplikasi, `kubectl create serviceaccount`, dan lain-lain).
 
-    For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
+    Sebagai contoh, untuk memberikan izin hanya baca (_read-only_) di dalam "my-namespace"
+    ke ServiceAccount "my-sa":
 
     ```shell
     kubectl create rolebinding my-sa-view \
@@ -1059,16 +1079,18 @@ In order from most secure to least secure, the approaches are:
       --namespace=my-namespace
     ```
 
-2. Grant a role to the "default" service account in a namespace
+2. Memberikan sebuah Role ke ServiceAccount "default" di dalam suatu Namespace
 
-    If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+    Jika sebuah aplikasi tidak menetapkan `serviceAccountName`, aplikasi
+    tersebut akan menggunakan ServiceAccount "default".
 
     {{< note >}}
-    Permissions given to the "default" service account are available to any pod
-    in the namespace that does not specify a `serviceAccountName`.
+    Izin yang diberikan ke ServiceAccount "default" tersedia ke Pod apa pun di dalam
+    Namespace yang tidak menetapkan `serviceAccountName`.
     {{< /note >}}
 
-    For example, grant read-only permission within "my-namespace" to the "default" service account:
+    Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke ServiceAccount
+    "default":
 
     ```shell
     kubectl create rolebinding default-view \
@@ -1077,14 +1099,14 @@ In order from most secure to least secure, the approaches are:
       --namespace=my-namespace
     ```
 
-    Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the
-    "default" service account in the `kube-system` namespace.
-    To allow those add-ons to run with super-user access, grant cluster-admin
-    permissions to the "default" service account in the `kube-system` namespace.
+    Banyak [pugasan](/id/docs/concepts/cluster-administration/addons/) berjalan sebagai
+    ServiceAccount "default" di dalam Namespace `kube-system`. Untuk mengizinkan pugasan
+    tersebut berjalan dengan akses _super-user_, berikan izin `cluster-admin` kepada
+    ServiceAccount "default" di dalam Namespace `kube-system`.
 
     {{< caution >}}
-    Enabling this means the `kube-system` namespace contains Secrets
-    that grant super-user access to your cluster's API.
+    Mengaktifkan ini berarti Namespace `kube-system` memuat Secret yang
+    memberikan akses _super-user_ ke API klastermu.
     {{< /caution >}}
 
     ```shell
@@ -1093,12 +1115,14 @@ In order from most secure to least secure, the approaches are:
       --serviceaccount=kube-system:default
     ```
 
-3. Grant a role to all service accounts in a namespace
+3. Memberikan Role ke semua ServiceAccount dalam suatu Namespace
 
-    If you want all applications in a namespace to have a role, no matter what service account they use,
-    you can grant a role to the service account group for that namespace.
+    Jika kamu ingin semua aplikasi di dalam satu Namespace untuk memiliki Role, apa pun
+    ServiceAccount yang digunakan, maka kamu dapat memberikan Role ke grup ServiceAccount
+    untuk Namespace tersebut.
 
-    For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
+    Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke semua
+    ServiceAccount di dalam Namespace tersebut:
 
     ```shell
     kubectl create rolebinding serviceaccounts-view \
@@ -1107,11 +1131,13 @@ In order from most secure to least secure, the approaches are:
       --namespace=my-namespace
     ```
 
-4. Grant a limited role to all service accounts cluster-wide (discouraged)
+4. Memberikan Role terbatas ke semua ServiceAccount di seluruh klaster (tidak disarankan)
+    
+    Jika kamu tidak ingin untuk mengelola izin per Namespace, kamu bisa memberikan
+    Role yang berlaku di seluruh klaster kepada semua ServiceAccount.
 
-    If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
-
-    For example, grant read-only permission across all namespaces to all service accounts in the cluster:
+    Sebagai contoh, untuk memberikan akses hanya baca di semua Namespace untuk
+    semua ServiceAccount yang ada di klaster:
 
     ```shell
     kubectl create clusterrolebinding serviceaccounts-view \
@@ -1119,14 +1145,15 @@ In order from most secure to least secure, the approaches are:
      --group=system:serviceaccounts
     ```
 
-5. Grant super-user access to all service accounts cluster-wide (strongly discouraged)
-
-    If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
+5. Memberikan akses _super-user_ ke semua ServiceAccount di seluruh klaster (sangat tidak disarankan)
+    
+    Jika kamu tidak peduli untuk melakukan partisi terhadap izin sama sekali, maka kamu bisa
+    memberikan akses _super-user_ ke semua ServiceAccount.
 
     {{< warning >}}
-    This allows any application full access to your cluster, and also grants
-    any user with read access to Secrets (or the ability to create any pod)
-    full access to your cluster.
+    Hal ini akan memberikan akses penuh untuk aplikasi apapun ke klastermu, dan juga
+    memberikan pengguna manapun dengan akses baca ke Secret (atau kemampuan untuk membuat
+    Pod apa pun) akses penuh ke klastermu.
     {{< /warning >}}
 
     ```shell
@@ -1135,50 +1162,55 @@ In order from most secure to least secure, the approaches are:
       --group=system:serviceaccounts
     ```
 
-## Upgrading from ABAC
+## Melakukan peningkatan dari ABAC
 
-Clusters that originally ran older Kubernetes versions often used
-permissive ABAC policies, including granting full API access to all
-service accounts.
+Klaster yang awalnya menjalankan versi Kubernetes lawas sering kali menggunakan
+kebijakan ABAC yang permisif, termasuk memberikan akses API penuh ke semua
+ServiceAccount.
 
-Default RBAC policies grant scoped permissions to control-plane components, nodes,
-and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
-(beyond discovery permissions given to all authenticated users).
+Kebijakan RBAC bawaan memberikan izin yang terbatas ke komponen _control plane_, Node,
+dan pengontrol, akan tetapi *tidak memberikan izin* ke ServiceAccount di luar Namespace
+`kube-system` (di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi).
 
-While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions.
-Here are two approaches for managing this transition:
+Meskipun jauh lebih aman, hal ini dapat mengganggu beban kerja yang sudah ada yang
+mengharapkan untuk menerima izin API secara otomatis.
+Berikut adalah dua pendekatan untuk mengelola transisi ini:
 
-### Parallel authorizers
+### Pemberi otorisasi paralel
 
-Run both the RBAC and ABAC authorizers, and specify a policy file that contains
-the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format):
+Jalankan pemberi otorisasi RBAC dan ABAC bersamaan, dan tentukan berkas kebijakan yang
+memuat [kebijakan ABAC lama](/docs/reference/access-authn-authz/abac/#policy-file-format):
 
 ```
 --authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json
 ```
 
-To explain that first command line option in detail: if earlier authorizers, such as Node,
-deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC
-also denies that API request, the ABAC authorizer is then run. This means that any request
-allowed by *either* the RBAC or ABAC policies is allowed.
+Untuk menjelaskan opsi baris perintah yang pertama secara detail: jika pemberi otorisasi
+sebelumnya, seperti Node, menolak permintaan, maka pemberi otorisasi RBAC mencoba untuk
+mengotorisasi permintaan API tersebut. Jika RBAC juga menolak permintaan API tersebut,
+maka pemberi otorisasi ABAC akan dijalankan. Hal ini berarti permintaan apa pun yang
+diizinkan oleh *salah satu* kebijakan RBAC atau ABAC akan diizinkan.
 
-When the kube-apiserver is run with a log level of 5 or higher for the RBAC component
-(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log
-(prefixed with `RBAC`).
-You can use that information to determine which roles need to be granted to which users, groups, or service accounts.
+Ketika kube-apiserver dijalankan dengan level log 5 atau lebih tinggi untuk komponen
+RBAC (`--vmodule=rbac*=5` atau `--v=5`), kamu dapat melihat penolakan RBAC di log
+server API (dengan prefiks `RBAC`). Kamu dapat menggunakan informasi tersebut untuk
+menentukan Role mana yang perlu diberikan ke pengguna, grup, atau ServiceAccount yang mana.
 
-Once you have [granted roles to service accounts](#service-account-permissions) and workloads
-are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer.
+Jika kamu telah [memberikan Role ke ServiceAccount](#service-account-permissions) dan
+beban kerja sedang berjalan tanpa pesan penolakan RBAC dalam log server, maka kamu
+dapat menghapus pemberi otorisasi ABAC.
 
-### Permissive RBAC permissions
+### Izin RBAC permisif
 
-You can replicate a permissive ABAC policy using RBAC role bindings.
+Kamu dapat mereplikasi kebijakan ABAC yang permisif dengan menggunakan RoleBinding
+RBAC.
 
 {{< warning >}}
-The following policy allows **ALL** service accounts to act as cluster administrators.
-Any application running in a container receives service account credentials automatically,
-and could perform any action against the API, including viewing secrets and modifying permissions.
-This is not a recommended policy.
+Kebijakan berikut mengizinkan **SEMUA** ServiceAccount bentindak sebagai administrator
+klaster. Aplikasi apa pun yang berjalan di dalam Container akan menerima kredensial
+ServiceAccount secara otomatis, dan dapat melakukan tindakan apa pun terhadap API,
+termasuk menampilkan Secret dan mengubah izin. Hal ini bukan kebijakan
+yang direkomendasikan.
 
 ```shell
 kubectl create clusterrolebinding permissive-binding \
@@ -1189,7 +1221,6 @@ kubectl create clusterrolebinding permissive-binding \
 ```
 {{< /warning >}}
 
-After you have transitioned to use RBAC, you should adjust the access controls
-for your cluster to ensure that these meet your information security needs.
-
-
+Setelah kamu beralih menggunakan RBAC, kamu harus menyesuaikan kontrol akses untuk
+klastermu untuk memastikan bahwa kesemuanya memenuhi kebutuhanmu terkait keamanan
+informasi.
diff --git a/content/id/docs/reference/glossary/annotation.md b/content/id/docs/reference/glossary/annotation.md
new file mode 100644
index 0000000000..2ae2c729a0
--- /dev/null
+++ b/content/id/docs/reference/glossary/annotation.md
@@ -0,0 +1,16 @@
+---
+title: Anotasi
+id: annotation
+date: 2018-04-12
+full_link: /id/docs/concepts/overview/working-with-objects/annotations
+short_description: >
+  Suatu pasangan kunci-nilai (_key-value_) yang digunakan untuk melampirkan metadata nonidentifikasi arbitrer ke objek.
+aka:
+tags:
+- fundamental
+---
+Suatu pasangan kunci-nilai (_key-value_) yang digunakan untuk melampirkan metadata nonidentifikasi arbitrer ke objek.
+
+<!--more-->
+
+Metadata dalam anotasi bisa berukuran kecil atau besar, terstruktur atau tidak terstruktur, dan dapat menyertakan karakter yang tidak dibolehkan pada {{< glossary_tooltip text="label" term_id="label" >}}. Klien seperti utilitas dan pustaka dapat mengambil metadata ini.
diff --git a/content/id/docs/reference/glossary/api-group.md b/content/id/docs/reference/glossary/api-group.md
new file mode 100644
index 0000000000..4701d13c60
--- /dev/null
+++ b/content/id/docs/reference/glossary/api-group.md
@@ -0,0 +1,19 @@
+---
+title: Grup API
+id: api-group
+date: 2019-09-02
+full_link: /id/docs/concepts/overview/kubernetes-api/#api-groups
+short_description: >
+  Sekumpulan _path_ terkait pada API Kubernetes.
+aka:
+tags:
+- fundamental
+- architecture
+---
+Sekumpulan _path_ terkait pada API Kubernetes.
+
+<!--more-->
+
+Kamu dapat mengaktifkan atau menonaktifkan setiap grup API dengan mengubah konfigurasi server API-mu. Kamu juga dapat menonaktifkan atau mengaktifkan _path_ untuk sumber daya tertentu. Grup API memudahkan penambahan ekstensi dari API Kubernetes. Grup API ditentukan di dalam _path_ REST dan _field_ `apiVersion` dari objek terserialisasi.
+
+* Baca [Grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups) untuk informasi lebih lanjut.
diff --git a/content/id/docs/reference/glossary/applications.md b/content/id/docs/reference/glossary/applications.md
new file mode 100644
index 0000000000..643b3c9b27
--- /dev/null
+++ b/content/id/docs/reference/glossary/applications.md
@@ -0,0 +1,12 @@
+---
+title: Aplikasi
+id: applications
+date: 2019-05-12
+full_link:
+short_description: >
+  Lapisan (_layer_) tempat menjalankan berbagai aplikasi dalam Container.
+aka:
+tags:
+- fundamental
+---
+Lapisan (_layer_) tempat menjalankan berbagai aplikasi dalam Container.
diff --git a/content/id/docs/reference/glossary/cgroup.md b/content/id/docs/reference/glossary/cgroup.md
new file mode 100644
index 0000000000..ef418f00b3
--- /dev/null
+++ b/content/id/docs/reference/glossary/cgroup.md
@@ -0,0 +1,17 @@
+---
+title: cgroup (control group)
+id: cgroup
+date: 2019-06-25
+full_link:
+short_description: >
+  Suatu grup proses Linux dengan isolasi, penghitungan, dan pembatasan sumber daya opsional.
+aka:
+- grup kontrol
+tags:
+- fundamental
+---
+Suatu grup proses Linux dengan isolasi, penghitungan, dan pembatasan sumber daya opsional.
+
+<!--more--> 
+
+cgroup merupakan fitur kernel Linux yang membatasi, menghitung, dan mengisolasi penggunaan sumber daya (CPU, memori, I/O diska, jaringan) untuk sekumpulan proses.
diff --git a/content/id/docs/reference/glossary/cluster-operator.md b/content/id/docs/reference/glossary/cluster-operator.md
index e1d09dbc7d..893aaeae5e 100644
--- a/content/id/docs/reference/glossary/cluster-operator.md
+++ b/content/id/docs/reference/glossary/cluster-operator.md
@@ -1,23 +1,21 @@
 ---
-title: Cluster Operator
+title: Operator Klaster
 id: cluster-operator
 date: 2018-04-12
 full_link: 
 short_description: >
-  Seseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster.
+  Seseorang yang mengonfigurasi, mengontrol, dan memonitor klaster.
 
-aka: 
+aka:
 tags:
 - user-type
 ---
-  Seseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster.
+Seseorang yang mengonfigurasi, mengontrol, dan memonitor klaster.
 
-<!--more--> 
+<!--more-->
 
-
-Tanggung jawab utama mereka adalah menjaga dan menjalankan cluster, yang mungkin melibatkan kegiatan pemeliharaan berkala atau peningkatan. <br>
+Tanggung jawab utama operator klaster adalah menjaga dan menjalankan klaster, yang mungkin melibatkan kegiatan pemeliharaan berkala atau peningkatan.
 
 {{< note >}}
-Operator cluster berbeda dari [Pola operator] (https://coreos.com/operators) yang memperluas API Kubernetes.
+Operator klaster berbeda dari [pola Operator](https://coreos.com/operators) yang memperluas API Kubernetes.
 {{< /note >}}
-
diff --git a/content/id/docs/reference/glossary/cluster.md b/content/id/docs/reference/glossary/cluster.md
new file mode 100644
index 0000000000..a6722eef1e
--- /dev/null
+++ b/content/id/docs/reference/glossary/cluster.md
@@ -0,0 +1,17 @@
+---
+title: Klaster
+id: cluster
+date: 2019-06-15
+full_link: 
+short_description: >
+  Sekumpulan mesin pekerja, yang dikenal sebagai Node, yang menjalankan aplikasi dalam Container. Setiap klaster setidaknya mempunyai satu Node pekerja.
+aka:
+tags:
+- fundamental
+- operation
+---
+Sekumpulan mesin pekerja, yang dikenal sebagai {{< glossary_tooltip term_id="node" >}}, yang menjalankan aplikasi dalam Container. Setiap klaster setidaknya mempunyai satu Node pekerja.
+
+<!--more-->
+
+Node pekerja menjalankan {{< glossary_tooltip term_id="pod" >}} yang merupakan komponen dari beban kerja aplikasi. {{< glossary_tooltip term_id="control-plane" >}} mengelola Node pekerja dan Pod di dalam klaster. Pada lingkungan produksi, _control plane_ biasanya berjalan di beberapa komputer dan suatu klaster pada umumnya menjalankan beberapa Node, hal ini akan memberikan toleransi kesalahan (_fault-tolerance_) dan ketersediaan tinggi (_high availability_).
diff --git a/content/id/docs/reference/glossary/configmap.md b/content/id/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..a5efb02328
--- /dev/null
+++ b/content/id/docs/reference/glossary/configmap.md
@@ -0,0 +1,17 @@
+---
+title: ConfigMap
+id: configmap
+date: 2018-04-12
+full_link: /docs/concepts/configuration/configmap/
+short_description: >
+  Sebuah objek API yang digunakan untuk menyimpan data nonkonfidensial sebagai pasangan kunci-nilai (_key-value_). Pod dapat menggunakan ConfigMap sebagai variabel lingkungan, argumen baris perintah (_command-line_), atau berkas konfigurasi dalam sebuah _volume_.
+
+aka:
+tags:
+- core-object
+---
+Sebuah objek API yang digunakan untuk menyimpan data nonkonfidensial sebagai pasangan kunci-nilai (_key-value_). {{< glossary_tooltip term_id="pod" >}} dapat menggunakan ConfigMap sebagai variabel lingkungan, argumen baris perintah (_command-line_), atau berkas konfigurasi dalam sebuah {{< glossary_tooltip text="volume" term_id="volume" >}}.
+
+<!--more-->
+
+Sebuah ConfigMap memungkinkanmu untuk memisahkan konfigurasi lingkungan tertentu dari {{< glossary_tooltip text="image Container" term_id="image" >}}, sehingga aplikasimu menjadi lebih portabel.
diff --git a/content/id/docs/reference/glossary/container-env-variables.md b/content/id/docs/reference/glossary/container-env-variables.md
index 996475cc2f..cbc39d1e57 100644
--- a/content/id/docs/reference/glossary/container-env-variables.md
+++ b/content/id/docs/reference/glossary/container-env-variables.md
@@ -1,17 +1,18 @@
 ---
-title: Container Environment Variables
+title: Variabel Lingkungan Container
 id: container-env-variables
 date: 2019-06-24
 full_link: /docs/concepts/containers/container-environment-variables/
 short_description: >
-  Variabel environment kontainer merupakan pasangan name=value yang dapat digunakan untuk menyediakan informasi penting bagi kontainer yang dijalankan pada pod.
+  Variabel lingkungan Container merupakan pasangan nama=nilai yang dapat digunakan untuk menyediakan informasi penting bagi Container yang dijalankan pada Pod.
 
-aka: 
+aka:
+- Container Environment Variables
 tags:
 - fundamental
 ---
- Container environment variables are name=value pairs that provide useful information into containers running in a Pod.
+Variabel lingkungan Container merupakan pasangan nama=nilai yang dapat digunakan untuk menyediakan informasi penting bagi Container yang dijalankan pada Pod.
 
 <!--more-->
 
-Variabel environment kontainer merupakan pasangan name=value yang dapat digunakan untuk menyediakan informasi penting bagi {{< glossary_tooltip text="kontainer" term_id="container" >}} yang dijalankan pada pod. Contohnya, detail mengenai file systems, informasi mengenai kontainer itu sendiri, dan komponen kluster lainnya seperti endpoint kluster.
+Variabel lingkungan Container menyediakan informasi yang dibutuhkan oleh aplikasi yang berjalan di dalam Container bersama dengan informasi mengenai sumber daya penting yang dibutuhkan oleh {{< glossary_tooltip term_id="container" >}}. Sebagai contoh, detail sistem berkas (_file system_), informasi mengenai Container itu sendiri, dan sumber daya klaster lainnya seperti _endpoint_ Service.
diff --git a/content/id/docs/reference/glossary/container-runtime.md b/content/id/docs/reference/glossary/container-runtime.md
new file mode 100644
index 0000000000..64416edd86
--- /dev/null
+++ b/content/id/docs/reference/glossary/container-runtime.md
@@ -0,0 +1,17 @@
+---
+title: Runtime Container
+id: container-runtime
+date: 2019-06-05
+full_link: /id/docs/setup/production-environment/container-runtimes
+short_description: >
+ _Runtime_ Container adalah perangkat lunak yang bertanggung jawab untuk menjalankan Container.
+aka:
+tags:
+- fundamental
+- workload
+---
+_Runtime_ Container adalah perangkat lunak yang bertanggung jawab untuk menjalankan Container.
+
+<!--more-->
+
+Kubernetes mendukung beberapa _runtime_ Container: {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, dan implementasi apapun dari [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
diff --git a/content/id/docs/reference/glossary/container.md b/content/id/docs/reference/glossary/container.md
index df94eca126..93a85b567e 100644
--- a/content/id/docs/reference/glossary/container.md
+++ b/content/id/docs/reference/glossary/container.md
@@ -2,16 +2,17 @@
 title: Container
 id: container
 date: 2019-06-24
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /id/docs/concepts/overview/what-is-kubernetes/#mengapa-kontainer
 short_description: >
-  Sebuah image yang ringan dan *executable* yang mengandung perangkat lunak and segala *dependency* yang dibutuhkan.
+  Sebuah _image_ yang ringan dan dapat dijalankan yang mengandung perangkat lunak and segala dependensi yang dibutuhkan.
 
-aka: 
+aka:
 tags:
 - fundamental
 - workload
 ---
-Sebuah image yang ringan dan *executable* yang mengandung perangkat lunak and segala *dependency* yang dibutuhkan.
+Sebuah _image_ yang ringan dan dapat dijalankan yang mengandung perangkat lunak and segala dependensi yang dibutuhkan.
 
-<!--more--> 
-Kontainer memisahkan aplikasi dan segala infrastruktur yang digunakan untuk membuat sebuah deployment menjadi lebih mudah pada berbagai environment *cloud provider* yang ada. 
\ No newline at end of file
+<!--more-->
+
+Container memisahkan aplikasi dari infrastruktur hos yang digunakan untuk mempermudah penggelaran pada berbagai lingkungan _cloud_ atau OS, dan juga untuk mempermudah penyekalaan.
diff --git a/content/id/docs/reference/glossary/control-plane.md b/content/id/docs/reference/glossary/control-plane.md
new file mode 100644
index 0000000000..a309e4fcc0
--- /dev/null
+++ b/content/id/docs/reference/glossary/control-plane.md
@@ -0,0 +1,25 @@
+---
+title: Control Plane
+id: control-plane
+date: 2019-05-12
+full_link:
+short_description: >
+  Merupakan lapisan orkestrasi Container yang mengekspos API dan antarmuka untuk mendefinisikan, menggelar, dan mengelola siklus hidup suatu Container.
+
+aka:
+tags:
+- fundamental
+---
+Merupakan lapisan orkestrasi Container yang mengekspos API dan antarmuka untuk mendefinisikan, menggelar, dan mengelola siklus hidup suatu Container.
+
+<!--more--> 
+
+Lapisan ini terdiri dari beragam komponen, seperti (tapi tidak terbatas pada):
+
+* {{< glossary_tooltip text="etcd" term_id="etcd" >}}
+* {{< glossary_tooltip text="Server API" term_id="kube-apiserver" >}}
+* {{< glossary_tooltip text="Penjadwal" term_id="kube-scheduler" >}}
+* {{< glossary_tooltip text="Manajer Pengontrol" term_id="kube-controller-manager" >}}
+* {{< glossary_tooltip text="Manajer Pengontrol Cloud" term_id="cloud-controller-manager" >}}
+
+Komponen-komponen tersebut dapat dijalankan sebagai layanan sistem operasi tradisional (_daemon_) atau sebagai Container. Hos yang menjalankan komponen-komponen tersebut secara historis dikenal sebagai {{< glossary_tooltip text="master" term_id="master" >}}.
diff --git a/content/id/docs/reference/glossary/controller.md b/content/id/docs/reference/glossary/controller.md
index c88dfccb14..bad87c4a6b 100755
--- a/content/id/docs/reference/glossary/controller.md
+++ b/content/id/docs/reference/glossary/controller.md
@@ -1,30 +1,21 @@
 ---
-title: Controller
+title: Pengontrol
 id: controller
 date: 2018-04-12
-full_link: /docs/concepts/architecture/controller/
+full_link: /id/docs/concepts/architecture/controller/
 short_description: >
   Kontrol tertutup yang mengawasi kondisi bersama dari klaster melalui apiserver dan membuat perubahan yang mencoba untuk membawa kondisi saat ini ke kondisi yang diinginkan.
 
-aka: 
+aka:
+- Controller
 tags:
 - architecture
 - fundamental
 ---
-Di Kubernetes, _controller_ adalah kontrol tertutup yang mengawasi kondisi
-{{< glossary_tooltip term_id="cluster" text="klaster">}} anda, lalu membuat atau 
-meminta perubahan jika diperlukan.
-Setiap _controller_ mencoba untuk memindahkan status klaster saat ini lebih 
-dekat ke kondisi yang diinginkan.
+Di Kubernetes, pengontrol adalah kontrol tertutup yang mengawasi kondisi {{< glossary_tooltip term_id="cluster" text="klaster">}}, lalu membuat atau meminta perubahan jika diperlukan. Setiap pengontrol mencoba untuk memindahkan status klaster saat ini lebih dekat ke kondisi yang diinginkan.
 
 <!--more-->
 
-_Controller_ mengawasi keadaan bersama dari klaster kamu melalui
-{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (bagian dari
-{{< glossary_tooltip term_id="control-plane" >}}).
+Pengontrol mengawasi keadaan bersama (_shared state_) dari klastermu melalui {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (bagian dari {{< glossary_tooltip term_id="control-plane" >}}).
 
-Beberapa _controller_ juga berjalan di dalam _control plane_, menyediakan 
-kontrol tertutup yang merupakan inti dari operasi Kubernetes. Sebagai contoh: 
-_controller Deployment_, _controller daemonset_, _controller namespace_, dan 
-_controller volume persisten_ (dan lainnya) semua berjalan di dalam
-{{< glossary_tooltip term_id="kube-controller-manager" >}}.
+Beberapa pengontrol juga berjalan di dalam _control plane_, menyediakan kontrol tertutup yang merupakan inti dari operasi Kubernetes. Sebagai contoh: pengontrol Deployment, pengontrol DaemonSet, pengontrol Namespace, dan pengontrol PersistentVolume (dan lainnya) semuanya berjalan di dalam {{< glossary_tooltip term_id="kube-controller-manager" >}}.
diff --git a/content/id/docs/reference/glossary/cri.md b/content/id/docs/reference/glossary/cri.md
new file mode 100644
index 0000000000..8226ee6f93
--- /dev/null
+++ b/content/id/docs/reference/glossary/cri.md
@@ -0,0 +1,18 @@
+---
+title: Antarmuka Runtime Container
+id: cri
+date: 2019-03-07
+full_link: /id/docs/concepts/overview/components/#container-runtime
+short_description: >
+  Sebuah API untuk mengintegrasikan _runtime_ Container dengan kubelet.
+
+aka:
+- Container Runtime Interface (CRI)
+tags:
+- fundamental
+---
+Sebuah API untuk mengintegrasikan _runtime_ Container dengan kubelet.
+
+<!--more-->
+
+Untuk informasi lebih lanjut, lihat API dan spesifikasi [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
diff --git a/content/id/docs/reference/glossary/customresourcedefinition.md b/content/id/docs/reference/glossary/customresourcedefinition.md
new file mode 100644
index 0000000000..4e2676c5ff
--- /dev/null
+++ b/content/id/docs/reference/glossary/customresourcedefinition.md
@@ -0,0 +1,19 @@
+---
+title: CustomResourceDefinition (CRD)
+id: CustomResourceDefinition
+date: 2018-04-12
+full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
+short_description: >
+  Kode khusus yang mendefinisikan sebuah sumber daya untuk ditambahkan ke server API Kubernetes-mu tanpa membangun server khusus tersendiri.
+
+aka:
+tags:
+- fundamental
+- operation
+- extension
+---
+Kode khusus yang mendefinisikan sebuah sumber daya untuk ditambahkan ke server API Kubernetes-mu tanpa membangun server khusus tersendiri.
+
+<!--more-->
+
+CRD memungkinkanmu untuk memperluas API Kubernetes untuk lingkunganmu jika sumber daya API yang didukung secara publik tidak dapat memenuhi kebutuhanmu.
diff --git a/content/id/docs/reference/glossary/daemonset.md b/content/id/docs/reference/glossary/daemonset.md
new file mode 100644
index 0000000000..7f8fdd5f61
--- /dev/null
+++ b/content/id/docs/reference/glossary/daemonset.md
@@ -0,0 +1,19 @@
+---
+title: DaemonSet
+id: daemonset
+date: 2018-04-12
+full_link: /id/docs/concepts/workloads/controllers/daemonset
+short_description: >
+  Memastikan salinan Pod dijalankan pada sekumpulan Node dalam satu klaster.
+
+aka:
+tags:
+- fundamental
+- core-object
+- workload
+---
+Memastikan salinan {{< glossary_tooltip term_id="pod" >}} dijalankan pada sekumpulan Node dalam satu {{< glossary_tooltip text="klaster" term_id="cluster" >}}.
+
+<!--more-->
+
+Digunakan untuk menggelar _daemon_ sistem sebagai kolektor log dan memonitor agen yang biasanya harus dijalankan di setiap {{< glossary_tooltip term_id="node" >}}.
diff --git a/content/id/docs/reference/glossary/data-plane.md b/content/id/docs/reference/glossary/data-plane.md
new file mode 100644
index 0000000000..bdfcd6758d
--- /dev/null
+++ b/content/id/docs/reference/glossary/data-plane.md
@@ -0,0 +1,13 @@
+---
+title: Data Plane
+id: data-plane
+date: 2019-05-12
+full_link:
+short_description: >
+  Lapisan yang menyediakan kapasitas seperti CPU, memori, jaringan, dan penyimpanan sehingga Container dapat dijalankan dan terhubung ke suatu jaringan.
+
+aka:
+tags:
+- fundamental
+---
+Lapisan yang menyediakan kapasitas seperti CPU, memori, jaringan, dan penyimpanan sehingga Container dapat dijalankan dan terhubung ke suatu jaringan.
diff --git a/content/id/docs/reference/glossary/deployment.md b/content/id/docs/reference/glossary/deployment.md
new file mode 100644
index 0000000000..6d21100fbb
--- /dev/null
+++ b/content/id/docs/reference/glossary/deployment.md
@@ -0,0 +1,18 @@
+---
+title: Deployment
+id: deployment
+date: 2018-04-12
+full_link: /id/docs/concepts/workloads/controllers/deployment/
+short_description: >
+  Mengelola aplikasi yang direplikasi di dalam klastermu.
+aka: 
+tags:
+- fundamental
+- core-object
+- workload
+---
+Sebuah objek API yang mengelola aplikasi yang direplikasi, biasanya dengan menjalankan Pod tanpa keadaan (_state_) lokal.
+
+<!--more--> 
+
+Setiap replika direpresentasikan oleh sebuah {{< glossary_tooltip term_id="pod" >}}, dan Pod tersebut didistribusikan di antara {{< glossary_tooltip term_id="node" >}} dari suatu klaster. Untuk beban kerja yang membutuhkan keadaan lokal, pertimbangkan untuk menggunakan {{< glossary_tooltip term_id="StatefulSet" >}}.
diff --git a/content/id/docs/reference/glossary/device-plugin.md b/content/id/docs/reference/glossary/device-plugin.md
new file mode 100644
index 0000000000..1318f44812
--- /dev/null
+++ b/content/id/docs/reference/glossary/device-plugin.md
@@ -0,0 +1,20 @@
+---
+title: Pugasan Peranti
+id: device-plugin
+date: 2019-02-02
+full_link: /id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
+short_description: >
+  Ekstensi perangkat lunak untuk memungkinkan Pod mengakses peranti yang membutuhkan inisialisasi atau penyiapan khusus.
+aka:
+- Device Plugin
+tags:
+- fundamental
+- extension
+---
+Pugasan peranti berjalan pada {{< glossary_tooltip term_id="node" >}} pekerja dan menyediakan akses ke sumber daya untuk {{< glossary_tooltip term_id="pod" >}}, seperti perangkat keras lokal, yang membutuhkan langkah inisialisasi atau penyiapan khusus.
+
+<!--more-->
+
+Pugasan peranti menawarkan sumber daya ke {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}, sehingga beban kerja Pod dapat mengakses fitur perangkat keras yang berhubungan dengan Node di mana Pod tersebut berjalan. Kamu dapat menggelar sebuah pugasan peranti sebagai sebuah {{< glossary_tooltip term_id="daemonset" >}}, atau menginstal perangkat lunak pugasan peranti secara langsung pada setiap Node target.
+
+Lihat [Pugasan Peranti](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk informasi lebih lanjut.
diff --git a/content/id/docs/reference/glossary/disruption.md b/content/id/docs/reference/glossary/disruption.md
new file mode 100644
index 0000000000..fb4898f397
--- /dev/null
+++ b/content/id/docs/reference/glossary/disruption.md
@@ -0,0 +1,18 @@
+---
+title: Disrupsi
+id: disruption
+date: 2019-09-10
+full_link: /id/docs/concepts/workloads/pods/disruptions/
+short_description: >
+  Peristiwa yang menyebabkan hilangnya Pod
+aka:
+tags:
+- fundamental
+---
+Disrupsi merupakan kejadian yang menyebabkan hilangnya satu atau beberapa {{< glossary_tooltip term_id="pod" >}}. Suatu disrupsi memiliki konsekuensi terhadap sumber daya beban kerja, seperti {{< glossary_tooltip term_id="deployment" >}}, yang bergantung pada Pod yang terpengaruh.
+
+<!--more-->
+
+Jika kamu, sebagai operator klaster, menghancurkan sebuah Pod milik suatu aplikasi, maka hal ini dalam Kubernetes dikenal sebagai disrupsi disengaja (_voluntary disruption_). Jika sebuah Pod menghilang karena kegagalan Node, atau pemadaman yang mempengaruhi zona kegagalan yang lebih luas, maka dalam Kubernetes dikenal dengan istilah disrupsi tidak disengaja (_involuntary disruption_).
+
+Lihat [Disrupsi](/id/docs/concepts/workloads/pods/disruptions/) untuk informasi lebih lanjut.
diff --git a/content/id/docs/reference/glossary/docker.md b/content/id/docs/reference/glossary/docker.md
new file mode 100644
index 0000000000..12e40468b6
--- /dev/null
+++ b/content/id/docs/reference/glossary/docker.md
@@ -0,0 +1,16 @@
+---
+title: Docker
+id: docker
+date: 2018-04-12
+full_link: https://docs.docker.com/engine/
+short_description: >
+  Docker merupakan suatu teknologi perangkat lunak yang menyediakan virtualisasi pada level sistem operasi yang juga dikenal sebagai Container.
+aka:
+tags:
+- fundamental
+---
+Docker (secara spesifik, Docker Engine) merupakan suatu teknologi perangkat lunak yang menyediakan virtualisasi pada level sistem operasi yang juga dikenal sebagai {{< glossary_tooltip term_id="container" >}}.
+
+<!--more-->
+
+Docker menggunakan fitur isolasi sumber daya pada kernel Linux seperti cgroup dan _namespace_, dan [UnionFS](https://docs.docker.com/get-started/overview/#union-file-systems) seperti OverlayFS dan lainnya untuk memungkinkan masing-masing Container dijalankan pada satu instans Linux, menghindari beban tambahan (_overhead_) saat memulai dan menjalankan VM.
diff --git a/content/id/docs/reference/glossary/ephemeral-container.md b/content/id/docs/reference/glossary/ephemeral-container.md
new file mode 100644
index 0000000000..bed0991807
--- /dev/null
+++ b/content/id/docs/reference/glossary/ephemeral-container.md
@@ -0,0 +1,17 @@
+---
+title: Container Sementara
+id: ephemeral-container
+date: 2019-08-26
+full_link: /id/docs/concepts/workloads/pods/ephemeral-containers/
+short_description: >
+  Jenis tipe Container yang dapat kamu jalankan sementara di dalam sebuah Pod.
+aka:
+- Ephemeral Container
+tags:
+- fundamental
+---
+Jenis tipe {{< glossary_tooltip term_id="container" >}} yang dapat kamu jalankan sementara di dalam sebuah {{< glossary_tooltip term_id="pod" >}}.
+
+<!--more-->
+
+Jika kamu ingin menyelidiki sebuah Pod yang bermasalah, kamu dapat menambahkan Container sementara ke Pod tersebut dan menjalankan diagnosis. Container sementara tidak memiliki jaminan sumber daya atau penjadwalan, dan kamu tidak boleh menggunakannya untuk menjalankan bagian mana pun dari beban kerja.
diff --git a/content/id/docs/reference/glossary/extensions.md b/content/id/docs/reference/glossary/extensions.md
new file mode 100644
index 0000000000..2e8e73d553
--- /dev/null
+++ b/content/id/docs/reference/glossary/extensions.md
@@ -0,0 +1,17 @@
+---
+title: Ekstensi
+id: Extensions
+date: 2019-02-01
+full_link: /id/docs/concepts/extend-kubernetes/extend-cluster/#perluasan
+short_description: >
+  Ekstensi adalah komponen perangkat lunak yang memperluas dan terintegrasi secara mendalam dengan Kubernetes untuk mendukung perangkat keras baru.
+aka:
+tags:
+- fundamental
+- extension
+---
+Ekstensi adalah komponen perangkat lunak yang memperluas dan terintegrasi secara mendalam dengan Kubernetes untuk mendukung perangkat keras baru.
+
+<!--more-->
+
+Sebagian besar admin klaster akan menggunakan instans Kubernetes yang dihoskan (_hosted_) atau didistribusikan. Akibatnya, hampir semua pengguna Kubernetes perlu menginstal [ekstensi](/id/docs/concepts/extend-kubernetes/extend-cluster/#perluasan) dan sedikit pengguna yang perlu membuat ekstensi baru.
diff --git a/content/id/docs/reference/glossary/image.md b/content/id/docs/reference/glossary/image.md
index bc26114e60..d0c09fc978 100644
--- a/content/id/docs/reference/glossary/image.md
+++ b/content/id/docs/reference/glossary/image.md
@@ -4,15 +4,14 @@ id: image
 date: 2019-04-24
 full_link: 
 short_description: >
-  Instans yang disimpan dari sebuah kontainer yang mengandung seperangkat perangkat lunak yang dibutuhkan untuk menjalankan sebuah aplikasi.
+  Instans yang disimpan dari sebuah Container yang memuat seperangkat perangkat lunak yang dibutuhkan untuk menjalankan sebuah aplikasi.
 
-aka: 
+aka:
 tags:
 - fundamental
 ---
- Instans yang disimpan dari sebuah kontainer yang mengandung seperangkat perangkat lunak yang dibutuhkan untuk menjalankan sebuah aplikasi.
+Instans yang disimpan dari sebuah Container yang memuat seperangkat perangkat lunak yang dibutuhkan untuk menjalankan sebuah aplikasi.
 
-<!--more--> 
-
-Sebuah mekanisme untuk mengemas perangkat lunak yang mengizinkan perangkat lunak tersebut untuk disimpan di dalam registri kontainer, di-_pull_ kedalam filesystem lokal, dan dijalankan sebagai suatu aplikasi. Meta data yang dimasukkan mengindikasikan _executable_ apa sajakah yang perlu dijalanmkan, siapa yang membuat _executable_ tersebut, dan informasi lainnya.
+<!--more-->
 
+Sebuah mekanisme untuk mengemas perangkat lunak yang memungkinkan perangkat lunak tersebut untuk disimpan di dalam register Container, ditarik ke dalam sistem lokal, dan dijalankan sebagai suatu aplikasi. Metadata disertakan di dalam _image_ yang mengindikasikan _executable_ apa saja yang perlu dijalankan, siapa yang membuatnya, dan informasi lainnya.
diff --git a/content/id/docs/reference/glossary/index.md b/content/id/docs/reference/glossary/index.md
new file mode 100644
index 0000000000..84ed9899da
--- /dev/null
+++ b/content/id/docs/reference/glossary/index.md
@@ -0,0 +1,11 @@
+---
+title: Glosarium
+layout: glossary
+noedit: true
+default_active_tag: fundamental
+weight: 5
+card:
+  name: reference
+  weight: 10
+  title: Glosarium
+---
diff --git a/content/id/docs/reference/glossary/init-container.md b/content/id/docs/reference/glossary/init-container.md
new file mode 100644
index 0000000000..3300504d9e
--- /dev/null
+++ b/content/id/docs/reference/glossary/init-container.md
@@ -0,0 +1,17 @@
+---
+title: Container Inisialisasi
+id: init-container
+date: 2018-04-12
+full_link: 
+short_description: >
+  Satu atau beberapa Container inisialisasi yang harus berjalan hingga selesai sebelum Container aplikasi apapun dijalankan.
+aka:
+- Init Container
+tags:
+- fundamental
+---
+Satu atau beberapa {{< glossary_tooltip term_id="container" >}} inisialisasi yang harus berjalan hingga selesai sebelum Container aplikasi apapun dijalankan.
+
+<!--more--> 
+
+Container inisialisasi mirip seperti Container aplikasi biasa, dengan satu perbedaan: Container inisialisasi harus berjalan sampai selesai sebelum Container aplikasi lainnya dijalankan. Container inisialisasi dijalankan secara seri: setiap Container inisialisasi harus berjalan sampai selesai sebelum Container inisialisasi berikutnya dijalankan.
diff --git a/content/id/docs/reference/glossary/job.md b/content/id/docs/reference/glossary/job.md
new file mode 100644
index 0000000000..2cc72f4073
--- /dev/null
+++ b/content/id/docs/reference/glossary/job.md
@@ -0,0 +1,18 @@
+---
+title: Job
+id: job
+date: 2018-04-12
+full_link: /docs/concepts/workloads/controllers/job/
+short_description: >
+  Tugas terbatas atau bertumpuk (_batch_) yang berjalan sampai selesai.
+aka:
+tags:
+- fundamental
+- core-object
+- workload
+---
+Tugas terbatas atau bertumpuk (_batch_) yang berjalan sampai selesai.
+
+<!--more--> 
+
+Membuat satu atau beberapa objek {{< glossary_tooltip term_id="pod" >}} dan memastikan bahwa sejumlah objek tersebut berhasil dihentikan. Saat Pod berhasil diselesaikan (_complete_), maka Job melacak keberhasilan penyelesaian tersebut.
diff --git a/content/id/docs/reference/glossary/kuantitas.md b/content/id/docs/reference/glossary/kuantitas.md
new file mode 100644
index 0000000000..ddac5a5ded
--- /dev/null
+++ b/content/id/docs/reference/glossary/kuantitas.md
@@ -0,0 +1,28 @@
+---
+title: Kuantitas
+id: kuantitas
+date: 2018-08-07
+full_link:
+short_description: >
+  Representasi bilangan bulat dari bilangan kecil atau bilangan besar menggunakan sufiks SI.
+
+aka: 
+tags:
+- core-object
+---
+ Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI.
+
+<!--lebih lanjut-->
+
+Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi 
+bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, 
+sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga.
+
+Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai` 1k`, dan `1000000` sebagai` 1M`.  Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat 
+ditulis sebagai `2Ki`.
+
+Satuan desimal yang diterima (pangkat 10) adalah `m` (mili),` k` (kilo,
+sengaja huruf kecil), `M` (mega),` G` (giga), `T` (tera),` P` (peta),
+`E` (exa).
+
+Unit biner (pangkat-2) yang diterima adalah `Ki` (kibi),` Mi` (mebi), `Gi` (gibi),` Ti` (tebi), `Pi` (pebi),` Ei` (exbi).
diff --git a/content/id/docs/reference/glossary/kube-apiserver.md b/content/id/docs/reference/glossary/kube-apiserver.md
index fda5ec39d5..a1b04754bd 100644
--- a/content/id/docs/reference/glossary/kube-apiserver.md
+++ b/content/id/docs/reference/glossary/kube-apiserver.md
@@ -4,16 +4,15 @@ id: kube-apiserver
 date: 2019-04-21
 full_link: /docs/reference/generated/kube-apiserver/
 short_description: >
-  Komponen di master yang mengekspos API Kubernetes. Merupakan <i> front-end </i> dari <i> kontrol plane </i> Kubernetes.
+  Komponen _control plane_ yang mengekspos API Kubernetes. Merupakan _front-end_ dari _control plane_ Kubernetes.
 
 aka:
 tags:
 - architecture
 - fundamental
 ---
- Komponen di master yang mengekspos API Kubernetes. Merupakan <i> front-end </i> dari <i> kontrol plane </i> Kubernetes.
+Komponen _control plane_ yang mengekspos API Kubernetes. Merupakan _front-end_ dari _control plane_ Kubernetes.
 
 <!--more-->
 
-Komponen ini didesain agar dapat di-<i>scale</i> secara horizontal. Lihat [Membangun Klaster HA](/docs/admin/high-availability/).
-
+Komponen ini didesain agar dapat diskalakan secara horizontal. Lihat [Membangun Klaster HA](/docs/admin/high-availability/).
diff --git a/content/id/docs/reference/glossary/kubectl.md b/content/id/docs/reference/glossary/kubectl.md
new file mode 100644
index 0000000000..579a4003c2
--- /dev/null
+++ b/content/id/docs/reference/glossary/kubectl.md
@@ -0,0 +1,18 @@
+---
+title: Kubectl
+id: kubectl
+date: 2018-04-12
+full_link: /docs/user-guide/kubectl-overview/
+short_description: >
+  Sebuah utilitas baris perintah untuk berkomunikasi dengan suatu server API Kubernetes.
+
+aka:
+tags:
+- tool
+- fundamental
+---
+Sebuah utilitas baris perintah untuk berkomunikasi dengan suatu server {{< glossary_tooltip text="API Kubernetes" term_id="kubernetes-api" >}}.
+
+<!--more-->
+
+Kamu dapat menggunakan kubectl untuk membuat, memeriksa, memperbarui, dan menghapus objek Kubernetes.
diff --git a/content/id/docs/reference/glossary/namespace.md b/content/id/docs/reference/glossary/namespace.md
new file mode 100644
index 0000000000..58678e689c
--- /dev/null
+++ b/content/id/docs/reference/glossary/namespace.md
@@ -0,0 +1,17 @@
+---
+title: Namespace
+id: namespace
+date: 2018-04-12
+full_link: /id/docs/concepts/overview/working-with-objects/namespaces
+short_description: >
+  Sebuah abstraksi yang digunakan oleh Kubernetes untuk mendukung multipel klaster virtual pada klaster fisik yang sama.
+
+aka:
+tags:
+- fundamental
+---
+Sebuah abstraksi yang digunakan oleh Kubernetes untuk mendukung multipel klaster virtual pada {{< glossary_tooltip text="klaster" term_id="cluster" >}} fisik yang sama.
+
+<!--more-->
+
+Namespace digunakan untuk mengatur objek-objek di dalam suatu klaster dan menyediakan cara untuk membagi sumber daya klaster. Nama sumber daya yang berada di dalam satu Namespace yang sama harus unik, akan tetapi tidak diharuskan dalam hal lintas Namespace.
diff --git a/content/id/docs/reference/glossary/persistent-volume-claim.md b/content/id/docs/reference/glossary/persistent-volume-claim.md
new file mode 100644
index 0000000000..b40fb29e05
--- /dev/null
+++ b/content/id/docs/reference/glossary/persistent-volume-claim.md
@@ -0,0 +1,18 @@
+---
+title: Persistent Volume Claim
+id: persistent-volume-claim
+date: 2018-04-12
+full_link: /id/docs/concepts/storage/persistent-volumes/
+short_description: >
+  Mengklaim sumber daya penyimpanan yang didefinisikan di dalam suatu PersistentVolume, sehingga PersistentVolume tersebut dapat dipasang (_mounted_) sebagai sebuah _volume_ pada suatu Container.
+
+aka:
+tags:
+- core-object
+- storage
+---
+Mengklaim sumber daya penyimpanan yang didefinisikan di dalam suatu {{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}, sehingga PersistentVolume tersebut dapat dipasang (_mounted_) sebagai sebuah _volume_ pada suatu {{< glossary_tooltip text="Container" term_id="container" >}}.
+
+<!--more-->
+
+Menentukan jumlah penyimpanan, bagaimana penyimpanan akan diakses (hanya baca (_read-only_), baca tulis (_read-write_), dan/atau eksklusif) dan bagaimana penyimpanan tersebut dapat diklaim kembali (dipertahankan, didaur ulang (_recycled_) atau dihapus). Detail dari penyimpanan itu sendiri dideskripsikan pada objek PersistentVolume.
diff --git a/content/id/docs/reference/glossary/persistent-volume.md b/content/id/docs/reference/glossary/persistent-volume.md
new file mode 100644
index 0000000000..4d9537b012
--- /dev/null
+++ b/content/id/docs/reference/glossary/persistent-volume.md
@@ -0,0 +1,20 @@
+---
+title: Persistent Volume
+id: persistent-volume
+date: 2018-04-12
+full_link: /docs/concepts/storage/persistent-volumes/
+short_description: >
+  Sebuat objek API yang merepresentasikan bagian penyimpanan pada klaster. Tersedia sebagai sumber daya umum yang dapat dipasang (_pluggable_) yang tetap bertahan bahkan di luar siklus hidup suatu Pod.
+
+aka:
+tags:
+- core-object
+- storage
+---
+Sebuat objek API yang merepresentasikan bagian penyimpanan pada klaster. Tersedia sebagai sumber daya umum yang dapat dipasang (_pluggable_) yang tetap bertahan bahkan di luar siklus hidup suatu {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+
+<!--more-->
+
+PersistentVolume (PV) menyediakan suatu API yang mengabstraksi detail tentang bagaimana penyimpanan disediakan dari cara penggunaannya.
+PV digunakan secara langsung pada skenario di mana penyimpanan dapat dibuat terlebih dahulu (penyediaan statis).
+Untuk skenario yang membutuhkan penyimpanan sesuai permintaan (penyediaan dinamis), maka yang dapat digunakan sebagai penggantinya adalah PersistentVolumeClaim (PV).
diff --git a/content/id/docs/reference/glossary/rbac.md b/content/id/docs/reference/glossary/rbac.md
new file mode 100644
index 0000000000..c856b77f3b
--- /dev/null
+++ b/content/id/docs/reference/glossary/rbac.md
@@ -0,0 +1,19 @@
+---
+title: Kontrol Akses Berbasis Rol
+id: rbac
+date: 2018-04-12
+full_link: /id/docs/reference/access-authn-authz/rbac/
+short_description: >
+  Mengelola keputusan otorisasi, memungkinkan admin untuk mengonfigurasi kebijakan akses secara dinamis melalui API Kubernetes.
+
+aka:
+- Role-Based Access Control (RBAC)
+tags:
+- security
+- fundamental
+---
+Mengelola keputusan otorisasi, memungkinkan admin untuk mengonfigurasi kebijakan akses secara dinamis melalui {{< glossary_tooltip text="API Kubernetes" term_id="kubernetes-api" >}}.
+
+<!--more-->
+
+RBAC menggunakan Role yang memuat aturan perizinan, dan RoleBinding yang memberikan izin sebagaimana telah ditentukan di dalam Role untuk sekumpulan pengguna.
diff --git a/content/id/docs/setup/_index.md b/content/id/docs/setup/_index.md
index 80677a97e4..2dfa4da74f 100644
--- a/content/id/docs/setup/_index.md
+++ b/content/id/docs/setup/_index.md
@@ -4,79 +4,31 @@ title: Persiapan
 main_menu: true
 weight: 30
 content_type: concept
+card:
+  name: persiapan
+  weight: 20
+  anchors:
+  - anchor: "#learning-environment"
+    title: Lingkungan Pembelajaran
+  - anchor: "#production-environment"
+    title: Lingkungan Produksi 
 ---
 
 <!-- overview -->
 
-Gunakan halaman ini untuk mencari solusi yang paling sesuai dengan kebutuhan kamu.
-
-Menentukan dimana sebaiknya Kubernetes dijalankan sangat tergantung pada kapasitas yang kamu punya dan seberapa fleksibel klaster yang kamu inginkan.
-Kamu dapat menjalankan Kubernetes hampir dimana saja, mulai dari laptop, VM di penyedia cloud, sampai pada rak-rak berisi server <i>baremetal</i>.
-Kamu juga bisa menyiapkan klaster yang diatur sepenuhnya (<i>fully-managed</i>), dengan hanya menjalankan satu perintah, ataupun membuat klaster dengan solusi <i>custom</i> kamu sendiri pada server <i>baremetal</i>.
-
+Bagian ini mencantumkan berbagai cara untuk menyiapkan dan menjalankan Kubernetes. Ketika kamu menginstal Kubernetes, pilih tipe instalasi berdasarkan: kemudahan perawatan, keamanan, sumber daya yang tersedia, dan keahlian yang dibutuhkan untuk mengoperasikan dan mengelola klaster.
 
+Kamu dapat menggelar klaster Kubernetes di mesin lokal, cloud, _datacenter_ di tempat, atau pilih klaster Kubernetes yang dikelola. Ada juga solusi khusus di berbagai penyedia cloud, atau lingkungan _baremetal_.
 
 <!-- body -->
 
-## Solusi pada Mesin Lokal
+## Lingkungan Pembelajaran
 
-Memulai Kubernetes bisa dilakukan dengan mudah melalui solusi pada mesin lokal.
-Kamu bisa membuat dan mengevaluasi klaster Kubernetes tanpa perlu takut menghabiskan <i>resource</i> dan kuota penyedia cloud.
+Jika kamu sedang belajar Kubernetes, gunakan alat yang didukung oleh komunitas Kubernetes, atau alat di ekosistem untuk menyiapkan klaster Kubernetes di mesin lokal.
 
-Sebaiknya kamu memilih solusi lokal jika kamu ingin:
+## Lingkungan Produksi
 
-* Mulai belajar atau mencoba Kubernetes
-* Mengembangkan dan melakukan evaluasi klaster secara lokal
+Pada saat mengevaluasi sebuah solusi untuk lingkungan produksi, pertimbangkan aspek dari pengoperasian klaster Kubernetes (atau _abstractions_) yang ingin kamu kelola atau membiarkan penyedia.
 
-Pilih [solusi lokal](/docs/setup/pick-right-solution/#local-machine-solutions).
-
-## Solusi Tersediakan (<i>Hosted Solution</i>)
-
-Solusi tersediakan adalah cara yang nyaman untuk membuat dan memelihara klaster Kubernetes. Kamu tidak perlu repot, karena para penyedia solusi mengatur dan mengoperasikan klaster milikmu.
-
-Sebaiknya kamu memilih solusi tersediakan ini jika kamu:
-
-* Ingin punya solusi yang diatur sepenuhnya
-* Fokus pada pengembangan aplikasi atau servis saja
-* Tidak mau punya tim SRE (<i>Site Reliability Engineering</i>) yang mendedikasikan waktunya untukmu, tapi ingin HA (<i>High Availability</i>)
-* Tidak punya <i>resource</i> untuk menjalankan dan memonitor klaster.
-
-Pilih [solusi tersediakan](/docs/setup/pick-right-solution/#hosted-solutions).
-
-## Turnkey – Solusi Cloud
-
-Solusi-solusi ini memudahkan kamu untuk mempunyai klaster Kubernetes hanya dengan beberapa perintah. Lalu, solusi-solusi ini juga masih terus berkembang dan memiliki pendukung komunitas yang aktif.
-Mereka juga bisa berjalan pada berbagai macam penyedia Cloud IaaS, tapi mereka menawarkan kebebasan dan fleksibilitas sebagai pengganti dari usaha.
-
-Sebaiknya kamu memilih solusi cloud <i>turnkey</i>, jika kamu:
-
-* Ingin punya kontrol yang lebih daripada yang ditawarkan oleh solusi tersediakan (<i>hosted solution</i>)
-* Ingin memiliki porsi dalam mengoperasikan klaster
-
-Pilih [solusi cloud turnkey](/docs/setup/pick-right-solution/#turnkey-cloud-solutions)
-
-## Turnkey – Solusi On-Premise
-
-Solusi-solusi ini menyediakan cara untuk membuat klaster Kubernetes di dalam jaringan cloud internal kamu yang aman, hanya dengan beberapa perintah.
-
-Sebaiknya kamu memilih solusi cloud on-premise turnkey, jika kamu:
-
-* Ingin membuat klaster di jaringan cloud yang privat (<i>private cloud network</i>)
-* Punya tim SRE yang mendedikasikan waktunya
-* Punya <i>resource</i> untuk menjalankan dan memonitor klaster
-
-Pilih [solusi cloud on-prem turnkey](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions).
-
-## Solusi <i>Custom</i>
-
-Solusi <i>custom</i> adalah solusi yang paling memberikan kebebasan dalam menjalankan klaster kamu, tapi perlu keahlian.
-Solusi-solusi ini cukup beragam, mulai dari bare-metal sampai ke penyedia cloud, berjalan pada sistem operasi yang berbeda-beda.
-
-Pilih [solusi <i>custom</i>](/docs/setup/pick-right-solution/#custom-solutions).
-
-
-
-## {{% heading "whatsnext" %}}
-
-Lihat [Memilih Solusi Terbaik](/docs/setup/pick-right-solution/) untuk daftar solusi yang lengkap.
+[Kubernetes Partners](https://kubernetes.io/partners/#conformance) termasuk dari daftar dari penyedia [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes).
 
diff --git a/content/id/docs/setup/learning-environment/_index.md b/content/id/docs/setup/learning-environment/_index.md
new file mode 100644
index 0000000000..4c116a9bc0
--- /dev/null
+++ b/content/id/docs/setup/learning-environment/_index.md
@@ -0,0 +1,4 @@
+---
+title: Lingkungan Pembelajaran
+weight: 20
+---
diff --git a/content/id/docs/setup/learning-environment/minikube.md b/content/id/docs/setup/learning-environment/minikube.md
new file mode 100644
index 0000000000..8729968738
--- /dev/null
+++ b/content/id/docs/setup/learning-environment/minikube.md
@@ -0,0 +1,514 @@
+---
+title: Instalasi Kubernetes dengan Minikube
+weight: 30
+content_type: concept
+---
+
+<!-- overview -->
+
+Minikube adalah alat yang memudahkan untuk menjalankan Kubernetes pada komputer lokal. Minikube menjalankan satu Node klaster Kubernetes di dalam _Virtual Machine_ (VM) pada laptop kamu untuk pengguna yang ingin mencoba Kubernetes atau mengembangkannya.
+
+
+<!-- body -->
+
+## Fitur Minikube
+
+Minikube mendukung fitur Kubernetes berikut:
+
+* DNS
+* NodePort
+* {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} dan {< glossary_tooltip text="Secret" term_id="secret" >}}
+* _Dashboard_
+* _Container runtime_: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/), dan [containerd](https://github.com/containerd/containerd)
+* {{< glossary_tooltip text="CNI" term_id="cni" >}}
+* Ingress
+
+## Instalasi
+
+Lihat [Instalasi Minikube](/id/docs/tasks/tools/install-minikube/).
+
+## Memulai Cepat
+
+Demonstrasi singkat ini memandu kamu tentang bagaimana memulai, menggunakan dan menghapus Minikube secara lokal. Ikuti langkah berikut untuk memulai dan menjelajahi Minikube.
+
+1. Mulailah Minikube dan buatlah sebuah klaster:
+
+   ```shell
+    minikube start
+   ```
+
+   Keluaran menyerupai:
+
+   ```
+   Starting local Kubernetes cluster...
+   Running pre-create checks...
+   Creating machine...
+   Starting local Kubernetes cluster...
+   ```
+   Untuk informasi lebih lanjut mengenai bagaimana memulai klaster pada versi Kubernetes tertentu, VM atau Container _runtime_, lihatlah [Memulai klaster](#memulai-klaster).
+
+2. Kini kamu bisa berinteraksi dengan klaster kamu dengan kubectl. Untuk informasi lebih lanjut, lihatlah [Interaksi dengan klaster kamu](#interaksi-dengan-klaster-kamu).
+
+   Mari kita buat Kubernetes Deployment menggunakan _image_ bernama `echoserver`, yaitu sebuah server HTTP sederhana dan buka layanan pada porta 8080 dengan menggunakan opsi `--port`.
+
+   ```shell
+   kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
+   ```
+
+   Keluaran menyerupai:
+
+   ```
+   deployment.apps/hello-minikube created
+   ```
+3. Untuk mengakses Deployment `hello-minikube`, bukalah dia sebagai sebuah Service: 
+
+   ```shell
+   kubectl expose deployment hello-minikube --type=NodePort --port=8080
+   ```
+
+   Opsi `--type=NodePort` menentukan tipe Service.
+
+   Keluarannya menyerupai:
+
+   ```
+   service/hello-minikube exposed
+   ```
+
+4. Pod `hello-minikube` saat ini telah dibuat namun kamu harus menunggu hingga Pod selesai dijalankan sebelum dapat mengaksesnya melalui Service yang telah dibuka.
+
+   Cek apakah Pod sudah berjalan dan beroperasi:
+
+   ```shell
+   kubectl get pod
+   ```
+
+   Jika keluaran menampilkan `STATUS` sebagai `ContainerCreating`, maka Pod sedang dalam proses pembuatan:
+
+   ```
+   NAME                              READY     STATUS              RESTARTS   AGE
+   hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
+   ```
+
+   Jika keluaran menampilkan `STATUS` sebagai `Running`, maka Pod sudah berjalan dan beroperasi:
+
+   ```
+   NAME                              READY     STATUS    RESTARTS   AGE
+   hello-minikube-3383150820-vctvh   1/1       Running   0          13s
+   ```
+
+5. Ambil URL Service yang telah dibuka untuk melihat Service secara detail:
+
+   ```shell
+   minikube service hello-minikube --url
+   ```
+
+6. Untuk melihat detail dari klaster lokal kamu, salin dan tempel URL yang kamu dapatkan dari keluaran pada peramban kamu.
+
+   Keluarannya menyerupai:
+
+   ```
+   Hostname: hello-minikube-7c77b68cff-8wdzq
+
+   Pod Information:
+    -no pod information available-
+
+   Server values:
+    server_version=nginx: 1.13.3 - lua: 10008
+
+   Request Information:
+    client_address=172.17.0.1
+    method=GET
+    real path=/
+    query=
+    request_version=1.1
+    request_scheme=http
+    request_uri=http://192.168.99.100:8080/
+
+   Request Headers:
+        accept=*/*
+        host=192.168.99.100:30674
+        user-agent=curl/7.47.0
+
+   Request Body:
+        -no body in request-
+   ```
+
+   Jika kamu tidak lagi membutuhkan Service dan klaster, maka kamu bisa menghapusnya.
+
+7. Hapuslah Service `hello-minikube`:
+
+   ```shell
+   kubectl delete services hello-minikube
+   ```
+
+   Keluarannya menyerupai:
+
+   ```
+   service "hello-minikube" deleted
+   ```
+
+8. Hapuslah Deployment `hello-minikube`:
+
+   ```shell
+   kubectl delete deployment hello-minikube
+   ```
+
+   Keluarannya menyerupai:
+
+   ```
+   deployment.extensions "hello-minikube" deleted
+   ```
+
+9. Hentikanlah klaster Minikube lokal:
+
+   ```shell
+   minikube stop
+   ```
+
+   Keluarannya menyerupai:
+
+   ```
+   Stopping "minikube"...
+   "minikube" stopped.
+   ```
+
+   Untuk informasi lebih lanjut, lihatlah [Menghentikan Klaster](#menghentikan-klaster).
+
+10. Hapuslah klaster Minikube lokal
+
+    ```shell
+    minikube delete
+    ```
+    Keluarannya menyerupai:
+    ```
+    Deleting "minikube" ...
+    The "minikube" cluster has been deleted.
+    ```
+	Untuk informasi lebih lanjut, lihat [Menghapus Klaster](#menghapus-klaster).
+
+## Mengelola Klaster
+
+### Memulai Klaster
+
+Perintah `minikube start` bisa digunakan untuk memulai klaster kamu.
+Perintah ini membuat dan mengonfigurasi sebuah mesin virtual yang menjalankan klaster Kubernetes dengan satu Node.
+Perintah ini juga mengonfigurasi instalasi [kubectl](/id/docs/user-guide/kubectl-overview/) untuk berkomunikasi dengan klaster ini.
+
+{{< note >}}
+Jika kamu menggunakan proksi web, maka kamu harus meneruskan informasi berikut ini ke perintah `minikube start`:
+
+```shell
+https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
+```
+Sayangnya, pengaturan dengan _environment variable_ saja tidak berguna.
+
+Minikube juga membuat konteks "minikube", dan menetapkannya sebagai bawaan di kubectl.
+Untuk kembali menggunakan konteks ini, jalankan perintah: `kubectl config use-context minikube`.
+{{< /note >}}
+
+#### Menentukan Versi Kubernetes
+
+Kamu bisa menentukan versi Kubernetes yang digunakan oleh Minikube dengan
+menambahkan `--kubernetes-version` ke perintah `minikube start`. Sebagai 
+contoh, untuk menjalankan versi {{<param "fullversion">}}, kamu akan menjalankan perintah berikut:
+
+```
+minikube start --kubernetes-version {{< param "fullversion" >}}
+```
+#### Menentukan _driver_ VM
+
+Kamu bisa mengubah _driver_ VM dengan menambahkan tanda `--driver=<masukan_nama_driver>` pada `minikube start`.
+Sebagai contoh:
+```shell
+minikube start --driver=<nama_driver>
+```
+
+Minikube mendukung _driver_ berikut ini:
+{{< note >}}
+Lihat [_DRIVER_](https://minikube.sigs.k8s.io/docs/reference/drivers/) untuk detail tentang _driver_ yang didukung dan proses instalasi _plugin_.
+{{< /note >}}
+
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/docker/)) docker
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) virtualbox 
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/podman/)) podman (TAHAP EXPERIMEN)
+* vmwarefusion
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) kvm2
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) hyperkit
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) hyperv
+Perlu diingat bahwa IP dibawah adalah dinamik dan bisa berubah. IP ini bisa diambil dengan `minikube ip`.
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) vmware (_driver_ VMware terpadu)
+* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) parallels
+* none (menjalankan komponen Kubernetes pada hos dan bukan pada mesin virtual. Kamu harus menjalankan Linux dan harus menginstal {{<glossary_tooltip term_id = "docker">}}.)
+
+{{< caution >}}
+Jika kamu menggunakan _driver_ `none`, beberapa komponen Kubernetes dijalankan sebagai Container istimewa yang memiliki efek samping di luar lingkungan Minikube. Efek samping tersebut berarti bahwa _driver_ `none` tidak direkomendasikan untuk komputer pribadi.
+{{< /caution >}}
+
+#### Memulai klaster pada _runtime_ kontainer alternatif
+Kamu bisa memulai Minikube pada _runtime_ kontainer berikut.
+{{< tabs name="container_runtimes" >}}
+{{% tab name="containerd" %}}
+Untuk menggunakan [containerd](https://github.com/containerd/containerd) sebagai _runtime_ kontainer, jalankan:
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-cni \
+    --container-runtime=containerd \
+    --bootstrapper=kubeadm
+```
+
+Atau kamu bisa menggunakan versi yang diperpanjang:
+
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-cni \
+    --extra-config=kubelet.container-runtime=remote \
+    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
+    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
+    --bootstrapper=kubeadm
+```
+{{% /tab %}}
+{{% tab name="CRI-O" %}}
+Untuk menggunakan [CRI-O](https://cri-o.io/) sebagain _runtime_ kontainer, jalankan:
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-cni \
+    --container-runtime=cri-o \
+    --bootstrapper=kubeadm
+```
+Atau kamu bisa menggunakan versi yang diperpanjang:
+
+```bash
+minikube start \
+    --network-plugin=cni \
+    --enable-default-cni \
+    --extra-config=kubelet.container-runtime=remote \
+    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
+    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
+    --bootstrapper=kubeadm
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+#### Menggunakan _image_ lokal degan menggunakan kembali _daemon_ Docker
+
+Saat menggunakan sebuah VM untuk Kubernetes, akan lebih baik jika _daemon_ Docker bawaan Minikube digunakan kembali. Menggunakan kembali _daemon_ bawaan membuat kamu tidak perlu membangun registri Docker pada mesin hos kamu dan mengunggah _image_ ke dalamnya. Namun, kamu dapat membangun di dalam _daemon_ Docker yang sama dengan Minikube, yang tentunya dapat mempercepat percobaan lokal.
+
+{{< note >}}
+Pastikan untuk memberi _tag_ pada Docker _image_ kamu dengan sesuatu selain `latest` dan gunakan _tag_ tersebut untuk menarik _image_. Karena `:latest` adalah bawaan, dengan kebijakan penarikan _image_ bawaan, yaitu `Always`, kesalahan penarikan _image_ (`ErrImagePull`) akhirnya dapat terjadi jika kamu tidak memiliki _image_ Docker di register Docker bawaan (biasanya DockerHub).
+{{< /note >}}
+
+Untuk bekerja dengan _daemon_ Docker pada mesin Mac/Linux, jalankan baris terakhir dari `minikube docker-env`.
+
+Kamu sekarang dapat menggunakan Docker di terminal mesin Mac/Linux kamu untuk berkomunikasi dengan _daemon_ Docker di dalam VM Minikube:
+
+```shell
+docker ps
+```
+
+{{< note >}}
+Pada Centos 7, Docker bisa memberikan kesalahan berikut:
+
+```
+Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
+```
+
+Kamu bisa memperbaikinya dengan memperbaharui /etc/sysconfig/docker untuk memastikan bahwa lingkungan Minikube dikenali:
+
+```shell
+< DOCKER_CERT_PATH=/etc/docker
+---
+> if [ -z "${DOCKER_CERT_PATH}" ]; then
+>   DOCKER_CERT_PATH=/etc/docker
+> fi
+```
+{{< /note >}}
+
+### Mengonfigurasi Kubernetes
+
+Minikube memiliki sebuah fitur "pengonfigurasi" yang memperbolehkan pengguna untuk mengkonfigurasi komponen Kubernetes dengan sembarang nilai.
+Untuk menggunakan fitur ini, kamu bisa menggunakan _flag_ `--extra-config` pada perintah `minikube start`.
+
+_Flag_ ini berulang, jadi kamu bisa menggunakannya beberapa kali dengan beberapa nilai yang berbeda untuk mengatur beberapa opsi.
+
+_Flag_ ini menerima sebuah _string_ dalam format `component.key=value`, di mana `component` adalah salah satu _string_ dari list di bawah, `key` adalah nilai dari _struct_ configurasi dan `value` adalah nilai yang digunakan.
+
+Kunci yang valid bisa ditemukan dengan memeriksa dokumentasi `componentconfigs` Kubernetes untuk setiap komponen.
+Berikut adalah dokumentasi untuk setiap konfigurasi yang didukung:
+
+* [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
+* [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions)
+* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration)
+* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration)
+* [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig)
+* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration)
+
+#### Contoh
+
+Untuk mengubah pengaturan `MaxPods` menjadi 5 pada Kubelet, gunakan _flag_ ini: `--extra-config=kubelet.MaxPods=5`.
+
+Fitur ini juga mendukung _struct_ yang berulang. Untuk mengubah pengaturan `LeaderElection.LeaderElect` menjadi `true` pada penjadwal, gunakan _flag_: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
+
+Untuk mengatur `AuthorizationMode` pada `apiserver` menjadi `RBAC`, kamu bisa menggunakan: `--extra-config=apiserver.authorization-mode=RBAC`.
+
+### Menghentikan klaster
+Perintah `minikube stop` bisa digunakan untuk menghentikan klaster kamu.
+Perintah ini menghentikan mesin virtual Minikube, tapi mempertahankan semua status dan data klaster.
+Memulai klaster lagi akan mengembalikannya ke keadaan sebelumnya.
+
+### Menghapus klaster
+Perintah `minikube delete` bisa digunakan untuk menghapus klaster kamu.
+Perintah ini menghentikan dan menghapus mesin virtual Minikube. Tidak ada data atau _state_ yang dipertahankan.
+
+### Memperbaharui Minikube
+Jika kamu menggunakan MacOS dan [Brew Package Manager](https://brew.sh/) sudah terpasang, jalankan:
+
+```shell
+brew update
+brew upgrade minikube
+```
+
+## Interaksi dengan Klaster Kamu
+
+### Kubectl
+
+Perintah `minikube start` membuat sebuah [konteks kubectl](/id/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) yang disebut "minikube".
+Konteks ini menyimpan pengaturan untuk berkomunikasi dengan klaster Minikube kamu.
+
+Minikube menetapkan konteks ini sebagai bawaan secara otomatis, tetapi jika kamu ingin mengubah kembali ke konteks tersebut di kemudian hari, gunakan:
+
+`kubectl config use-context minikube`
+
+Atau berikan konteks untuk setiap perintah seperti ini:
+
+`kubectl get pods --context=minikube`
+
+### Dashboard
+
+Untuk mengakses [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), gunakan perintah ini pada terminal setelah memulai Minikube untuk mendapatkan alamatnya:
+
+```shell
+minikube dashboard
+```
+
+### Service
+
+Untuk mengakses Service yang dibuka via NodePort, jalankan perintah ini pada terminal setelah memulai Minikube untuk mendapatkan alamat:
+
+```shell
+minikube service [-n NAMESPACE] [--url] NAME
+```
+
+## Jaringan
+
+Mesin virtual Minikube dibuka ke sistem hos melalui alamat IP _host-only_ , yang bisa didapatkan dengan perintah `minikube ip`.
+Seluruh Service dengan jenis `NodePort` bisa diakses melalui alamat IP pada NodePort.
+
+Untuk mementukan NodePort pada Service kamu, kamu bisa menggunakan perintah `kubectl` sebagai berikut:
+
+`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
+
+## PersistentVolume
+
+Minikube mendukung [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) dengan jenis `hostPath`.
+PersistenVolume ini dipetakan ke direktori di dalam mesin virtual Minikube.
+
+Mesin virtual Minikube melakukan _booting_ ke tmpfs, sehingga sebagian besar direktori tidak akan bertahan setelah di _reboot_ (`minikube stop`).
+
+Namun, Minikube diatur untuk mempertahankan berkas yang tersimpan didalam direktori hos berikut:
+
+* `/data`
+* `/var/lib/minikube`
+* `/var/lib/docker`
+
+Ini adalah contoh pengaturan PersistentVolume untuk mempertahankan data di dalam direktori `/data`:
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv0001
+spec:
+  accessModes:
+    - ReadWriteOnce
+  capacity:
+    storage: 5Gi
+  hostPath:
+    path: /data/pv0001/
+```
+
+## Folder hos yang di _mount_
+Beberapa _driver_ akan memasang folder _hos_ dalam VM sehingga kamu dapat dengan mudah berbagi berkas antara VM dan hos. Saat ini, hal tersebut tidak dapat dikonfigurasi dan berbeda untuk setiap _driver_ dan sistem operasi yang kamu gunakan.
+
+{{< note >}}
+Berbagi folder hos belum diimplementasikan pada _driver_ KVM.
+{{< /note >}}
+
+| Driver | OS | HostFolder | VM |
+| --- | --- | --- | --- |
+| VirtualBox | Linux | /home | /hosthome |
+| VirtualBox | macOS | /Users | /Users |
+| VirtualBox | Windows | C://Users | /c/Users |
+| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
+| Xhyve | macOS | /Users | /Users |
+
+## Registri Container Pribadi
+
+Untuk mengakses registri Container pribadi, ikuti langkah berikut pada [halaman ini](/id/docs/concepts/containers/images/).
+
+Kami merekomendasi penggunaan `ImagePullSecrets`, tetapi jika kamu ingin mengonfigurasi akses pada virtual mesin Minikube, kamu bisa menempatkan `.dockercfg` pada direktori `/home/docker` atau `config.json` dalam direktori `/home/docker/.docker`.
+
+## Tambahan (_Add-on_)
+
+Supaya Minikube memulai atau memulai kembali kustom tambahan dengan benar, 
+tempatkan tambahan yang ingin kamu jalankan di dalam direktori `~/.minikube/addons`.
+Tambahan dalam folder akan dipindahkan ke virtual mesin Minikube dan dijalankan setiap kali Minikube
+dimulai atau dimulai ulang.
+
+## Menggunakan Minikube dengan Proksi HTTP
+
+Minikube membuat sebuah mesin virtual yang memasukkan Kubernetes dan _daemon_ Docker.
+Ketika Kubernetes berusaha untuk menjadwalkan Container dengan Docker, _daemon_ Docker mungkin membutuhkan
+akses jaringan eksternal untuk menarik Container.
+
+Jika kamu berada di belakang _proxy_ HTTP, kamu mungkin perlu menyediakan Docker dengan pengaturan proksi. 
+Untuk melakukan ini, berikan _environment variable_ yang dibutuhkan sebagai _flag_ pada saat `minikube start`.
+
+Contoh:
+
+```shell
+minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
+                 --docker-env https_proxy=https://$YOURPROXY:PORT
+```
+
+Jika alamat mesin virtual kamu adalah 192.168.99.100, maka ada kemungkinan pengaturan proksi kamu akan mencegah `kubectl` untuk mencapainya. 
+Untuk melewatkan konfigurasi _proxy_ untuk alamat IP ini, kamu harus memodifikasi pengaturan _no_proxy` kamu. Kamu bisa melakukannya dengan:
+
+```shell
+export no_proxy=$no_proxy,$(minikube ip)
+```
+
+## Masalah yang Diketahui
+
+Fitur yang memerlukan banyak Node tidak akan berfungsi dalam Minikube.
+
+## Desain
+
+Minikube menggunakan [libmachine](https://github.com/docker/machine/tree/master/libmachine) untuk menyediakan mesin virtual, dan [kubeadm](https://github.com/kubernetes/kubeadm) untuk menyediakan klaster Kubernetes.
+
+Untuk info lebih lanjut tentang Minikube, lihat [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
+
+## Tautan Tambahan
+
+* **Tujuan and Non-Tujuan**: Untuk tujuan dan non-tujuan dari projek Minikube, lihat [roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/).
+* **Petunjuk Pengembangan**: Lihat [Berkontribusi](https://minikube.sigs.k8s.io/docs/contrib/) untuk ikhtisar bagaimana cara mengirimkan _pull request_.
+* **Membangun Minikube**: Untuk instruksi bagaimana membangun atau mengetes Minikube dari sumber kode, lihat [petunjuk membangun](https://minikube.sigs.k8s.io/docs/contrib/building/).
+* **Menambahkan Dependensi Baru**: Untuk instruksi bagaimana menambahkan dependensi baru ke Minikube, lihat [petunjuk penambahan dependensi](https://minikube.sigs.k8s.io/docs/contrib/drivers/).
+* **Menambahkan Addon Baru**: Untuk instruksi bagaimana menambahkan tambahan baru untuk Minikube, lihat [petunjuk menambahkan addon baru](https://minikube.sigs.k8s.io/docs/contrib/addons/).
+* **MicroK8s**: Pengguna Linux yang ingin menghindari penggunaan mesin virtual, bisa mempertimbangkan [MicroK8s](https://microk8s.io/) sebagai alternatif.
+
+## Komunitas
+
+Kontribusi, pertanyaan, dan komentar sangat diharapkan! Pengembang Minikube berkumpul dalam [Slack](https://kubernetes.slack.com) di _channel_ #minikube (dapatkan undangan [di sini](http://slack.kubernetes.io/)). Kami juga memiliki [milis kubernetes-dev Google Groups](https://groups.google.com/forum/#!forum/kubernetes-dev). Jika kamu memposting sesuatu, awali subjek kamu dengan "minikube: ".
diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 99d23c823d..c8023c79d4 100644
--- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -94,11 +94,11 @@ Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu da
   Contoh:
 
   ```conf
-release=1.0
-tier=frontend
-environment=pod
-track=stable
-```
+  release=1.0
+  tier=frontend
+  environment=pod
+  track=stable
+  ```
 
 - **_Namespace_**: Kubernetes mendukung beberapa klaster virtual yang berjalan di atas klaster fisik yang sama. Klaster virtual ini disebut [Namespace](/docs/tasks/administer-cluster/namespaces/). Mereka mengizinkan kamu untuk mempartisi sumber daya ke beberapa grup yang diberi nama secara logis.
 
diff --git a/content/id/docs/tasks/administer-cluster/_index.md b/content/id/docs/tasks/administer-cluster/_index.md
new file mode 100755
index 0000000000..4855515ce2
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/_index.md
@@ -0,0 +1,6 @@
+---
+title: "Mengelola Sebuah Klaster"
+description: Pelajari tugas-tugas umum dalam pengelolaan sebuah klaster.
+weight: 20
+---
+
diff --git a/content/id/docs/tasks/administer-cluster/cluster-management.md b/content/id/docs/tasks/administer-cluster/cluster-management.md
new file mode 100644
index 0000000000..0473dde9f3
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/cluster-management.md
@@ -0,0 +1,221 @@
+---
+title: Manajemen Klaster
+content_type: concept
+---
+
+<!-- overview -->
+
+Dokumen ini menjelaskan beberapa topik yang terkait dengan siklus hidup sebuah klaster: membuat klaster baru,
+memperbarui Node _control plane_ dan Node pekerja dari klaster kamu,
+melakukan pemeliharaan Node (misalnya pembaruan kernel), dan meningkatkan versi API Kubernetes dari
+klaster yang berjalan.
+
+<!-- body -->
+
+
+## Membuat dan mengonfigurasi klaster
+
+Untuk menginstal Kubernetes dalam sekumpulan mesin, konsultasikan dengan salah satu [Panduan Memulai](/id/docs/setup) tergantung dengan lingkungan kamu.
+
+## Memperbarui klaster
+
+Status saat ini pembaruan klaster bergantung pada penyedia, dan beberapa rilis yang mungkin memerlukan perhatian khusus saat memperbaruinya. Direkomendasikan agar admin membaca [Catatan Rilis](https://git.k8s.io/kubernetes/CHANGELOG/README.md), serta catatan khusus pembaruan versi sebelum memperbarui klaster mereka.
+
+### Memperbarui klaster Azure Kubernetes Service (AKS)
+
+Azure Kubernetes Service memungkinkan pembaruan layanan mandiri yang mudah dari _control plane_ dan Node pada klaster kamu. Prosesnya adalah
+saat ini dimulai oleh pengguna dan dijelaskan dalam [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
+
+### Memperbarui klaster Google Compute Engine
+
+Google Compute Engine Open Source (GCE-OSS) mendukung pembaruan _control plane_ dengan menghapus dan
+membuat ulang _control plane_, sambil mempertahankan _Persistent Disk_ (PD) yang sama untuk memastikan bahwa data disimpan pada berkas
+untuk setiap kali pembaruan.
+
+Pembaruan Node untuk GCE menggunakan [grup _instance_ yang di-_manage_](https://cloud.google.com/compute/docs/instance-groups/), dimana setiap Node
+dihancurkan secara berurutan dan kemudian dibuat ulang dengan perangkat lunak baru. Semua Pod yang berjalan di Node tersebut harus
+dikontrol oleh pengontrol replikasi (_Replication Controller_), atau dibuat ulang secara manual setelah peluncuran.
+
+Pembaruan versi pada klaster open source Google Compute Engine (GCE) yang dikontrol oleh skrip `cluster/gce/upgrade.sh`.
+
+Dapatkan penggunaan dengan menjalankan `cluster/gce/upgrade.sh -h`.
+
+Misalnya, untuk meningkatkan hanya _control plane_ kamu ke versi tertentu (v1.0.2):
+
+```shell
+cluster/gce/upgrade.sh -M v1.0.2
+```
+
+Sebagai alternatif, untuk meningkatkan seluruh klaster kamu ke rilis yang stabil terbaru gunakan:
+
+```shell
+cluster/gce/upgrade.sh release/stable
+```
+
+### Memperbarui klaster Google Kubernetes Engine
+
+Google Kubernetes Engine secara otomatis memperbarui komponen _control plane_ (misalnya, `kube-apiserver`, ` kube-scheduler`) ke versi yang terbaru. Ini juga menangani pembaruan sistem operasi dan komponen lain yang dijalankan oleh _control plane_.
+
+Proses pembaruan Node dimulai oleh pengguna dan dijelaskan dalam [Dokumentasi Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).
+
+### Memperbarui klaster Amazon EKS
+
+Komponen _control plane_ klaster pada Amazon EKS dapat diperbarui dengan menggunakan eksctl, AWS Management Console, atau AWS CLI. Prosesnya dimulai oleh pengguna dan dijelaskan di [Dokumentasi Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
+
+### Memperbarui klaster Oracle Cloud Infrastructure Container Engine untuk Kubernetes (OKE)
+
+Oracle membuat dan mengelola sekumpulan Node _control plane_ pada _control plane_ Oracle atas nama kamu (dan infrastruktur Kubernetes terkait seperti Node etcd) untuk memastikan kamu memiliki Kubernetes _control plane_ yang terkelola dengan ketersedian tinggi. Kamu juga dapat memperbarui Node _control plane_ ini dengan mulus ke versi Kubernetes baru tanpa berhenti. Tindakan ini dijelaskan dalam [Dokumentasi OKE](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm).
+
+### Memperbarui klaster pada platform yang lain
+
+Penyedia dan alat yang berbeda akan mengelola pembaruan secara berbeda. Kamu disarankan untuk membaca dokumentasi utama mereka terkait pembaruan.
+
+* [kops](https://github.com/kubernetes/kops)
+* [kubespray](https://github.com/kubernetes-incubator/kubespray)
+* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
+* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
+* ...
+
+Untuk memperbarukan sebuah klaster pada platform yang tidak disebutkan dalam daftar di atas, periksa urutan pembaruan komponen pada
+halaman [Versi Skewed](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order).
+
+## Merubah ukuran klaster
+
+Jika klaster kamu kekurangan sumber daya, kamu dapat dengan mudah menambahkan lebih banyak mesin ke klaster tersebut jika klaster kamu
+menjalankan [Mode Node Registrasi Sendiri](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
+Jika kamu menggunakan GCE atau Google Kubernetes Engine, itu dilakukan dengan mengubah ukuran grup _instance_ yang mengelola Node kamu.
+Ini dapat dilakukan dengan mengubah jumlah _instance_ pada
+`Compute > Compute Engine > Instance groups > your group > Edit group`
+[Laman Google Cloud Console](https://console.developers.google.com) atau dengan baris perintah gcloud:
+
+```shell
+gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
+```
+
+Grup _instance_ akan menangani penempatan _image_ yang sesuai pada mesin baru dan memulainya,
+sedangkan Kubelet akan mendaftarkan Node-nya ke server API agar tersedia untuk penjadwalan.
+Jika kamu menurunkan skala grup _instance_, sistem akan secara acak memilih Node untuk dimatikan.
+
+Di lingkungan lain kamu mungkin perlu mengonfigurasi mesin sendiri dan memberi tahu Kubelet di mana server API mesin itu berjalan.
+
+### Merubah ukuran klaster Azure Kubernetes Service (AKS)
+
+Azure Kubernetes Service memungkinkan perubahan ukuran klaster yang dimulai oleh pengguna dari CLI atau
+portal Azure dan dijelaskan dalam [Dokumentasi Azure AKS](https://docs.microsoft.com/en-us/azure/aks/scale-cluster).
+
+
+### Penyekalaan otomatis klaster
+
+Jika kamu menggunakan GCE atau Google Kubernetes Engine, kamu dapat mengonfigurasi klaster kamu sehingga secara otomatis diskalakan berdasarkan
+kebutuhan Pod.
+
+Seperti yang dideskripsikan dalam [Sumber daya komputasi](/id/docs/concepts/configuration/manage-resources-containers/),
+pengguna dapat memesan berapa banyak CPU dan memori yang dialokasikan ke Pod.
+Informasi ini digunakan oleh penjadwal Kubernetes untuk menemukan tempat menjalankan Pod. Jika
+tidak ada Node yang memiliki kapasitas kosong yang cukup (atau tidak sesuai dengan persyaratan Pod yang lainnya) maka Pod
+menunggu sampai beberapa Pod dihentikan atau Node baru ditambahkan.
+
+Penyekala otomatis klaster mencari Pod yang tidak dapat dijadwalkan dan memeriksa apakah perlu menambahkan Node baru, yang serupa
+dengan Node yang lain dalam klaster untuk membantu. Jika ya, maka itu mengubah ukuran klaster agar dapat mengakomodasi Pod yang menunggu.
+
+Penyekala otomatis klaster juga menurunkan skala klaster jika mengetahui bahwa satu atau beberapa Node tidak diperlukan lagi untuk
+periode waktu tambahan (selama 10 menit tetapi dapat berubah di masa mendatang).
+
+Penyekala otomatis klaster dikonfigurasikan untuk per grup _instance_ (GCE) atau kumpulan Node (Google Kubernetes Engine).
+
+Jika kamu menggunakan GCE, kamu dapat mengaktifkannya sambil membuat klaster dengan skrip kube-up.sh.
+Untuk mengonfigurasi penyekala otomatis klaster, kamu harus menyetel tiga variabel lingkungan:
+
+* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - mengaktifkan penyekala otomatis klaster kalau di setel menjadi _true_.
+* `KUBE_AUTOSCALER_MIN_NODES` - minimal jumlah Node dalam klaster.
+* `KUBE_AUTOSCALER_MAX_NODES` - maksimal jumlah Node dalam klaster.
+
+Contoh:
+
+```shell
+KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
+```
+
+Pada Google Kubernetes Engine, kamu mengonfigurasi penyekala otomatis klaster baik saat pembuatan atau pembaruan klaster atau saat membuat kumpulan Node tertentu
+(yang ingin kamu skalakan secara otomatis) dengan meneruskan _flag_ `--enable-autoscaling`, `--min-nodes` dan `--max-nodes`
+yang sesuai dengan perintah `gcloud`.
+
+Contoh:
+
+```shell
+gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
+```
+
+```shell
+gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
+```
+
+**Penyekala otomatis klaster mengharapkan bahwa Node belum dimodifikasi secara manual (misalnya dengan menambahkan label melalui kubectl) karena properti tersebut tidak akan disebarkan ke Node baru dalam grup _instance_ yang sama.**
+
+Untuk detail selengkapnya tentang cara penyekala otomatis klaster memutuskan apakah, kapan dan bagaimana
+melakukan penyekalaan sebuah klaster, silahkan lihat dokumentasi [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
+dari proyek penyekala otomatis klaster.
+
+## Memelihara dalam Node
+
+Jika kamu perlu memulai ulang Node (seperti untuk pembaruan kernel, pembaruan libc, pembaruan perangkat keras, dll.) dan waktu kegagalan (_downtime_) yang
+singkat, lalu ketika Kubelet memulai ulang, maka ia akan mencoba untuk memulai ulang Pod yang dijadwalkan. Jika mulai ulang membutuhkan waktu yang lebih lama
+(waktu bawaan adalah 5 menit, yang dikontrol oleh `--pod-eviction-timeout` pada _controller-manager_),
+maka pengontrol Node akan menghentikan Pod yang terikat ke Node yang tidak tersedia. Jika ada yang sesuai dengan
+kumpulan replika (atau pengontrol replikasi), maka salinan baru dari Pod akan dimulai pada Node yang berbeda. Jadi, dalam kasus di mana semua
+Pod direplikasi, pembaruan dapat dilakukan tanpa koordinasi khusus, dengan asumsi bahwa tidak semua Node akan mati pada saat yang bersamaan.
+
+Jika kamu ingin lebih mengontrol proses pembaruan, kamu dapat menggunakan alur kerja berikut ini:
+
+Gunakan `kubectl drain` untuk meghentikan perlahan-lahan semua Pod dalam Node ketika menandai Node sebagai _unschedulable_:
+
+```shell
+kubectl drain $NODENAME
+```
+
+Ini mencegah Pod baru mendarat pada Node saat kamu mencoba melepaskannya.
+
+Untuk Pod dengan sebuah kumpulan replika, Pod tersebut akan diganti dengan Pod baru yang akan dijadwalkan ke Node baru. Selain itu, jika Pod adalah bagian dari layanan, maka klien akan secara otomatis dialihkan ke Pod baru.
+
+Untuk Pod yang tidak memiliki replika, kamu perlu memunculkan salinan baru dari Pod tersebut, dan menganggapnya bukan bagian dari layanan, alihkan klien ke Pod tersebut.
+
+Lakukan pekerjaan pemeliharaan pada Node.
+
+Buat Node dapat dijadwal lagi:
+
+
+```shell
+kubectl uncordon $NODENAME
+```
+
+Jika kamu menghapus Node dari _instance_ VM dan membuat yang baru, maka sumber daya Node baru yang dapat dijadwalkan akan
+dibuat secara otomatis (jika kamu menggunakan penyedia cloud yang mendukung
+pencarian Node; saat ini hanya Google Compute Engine, tidak termasuk CoreOS di Google Compute Engine menggunakan kube-register).
+Lihatlah [Node](/docs/concepts/architecture/nodes/) untuk lebih detail.
+
+## Topik lebih lanjut
+
+### Mengaktifkan atau menonaktifkan versi API untuk klaster kamu
+
+Versi API spesifik dapat dinyalakan dan dimatikan dengan meneruskan _flag_ `--runtime-config=api/<version>` ketika menjalankan server API. Sebagai contoh: untuk menyalakan APIv1, teruskan `--runtime-config=api/v1=false`.
+_runtime-config_ juga mendukung 2 kunci khusus: api/all dan api/legacy yang masing-masing untuk mengontrol semua dan API lama.
+Sebagai contoh, untuk mematikan versi API semua kecuali v1, teruskan `--runtime-config=api/all=false,api/v1=true`.
+Untuk tujuan _flag_ ini, API lama adalah API yang sudah tidak digunakan lagi secara eksplisit (misalnya, `v1beta3`).
+
+### Mengalihkan versi API penyimpanan dari klaster kamu
+
+Objek yang disimpan ke diska untuk representasi internal klaster dari sumber daya Kubernetes yang aktif dalam klaster ditulis menggunakan versi API tertentu.
+Saat API yang didukung berubah, objek ini mungkin perlu ditulis ulang dalam API yang lebih baru. Kegagalan melakukan ini pada akhirnya akan menghasilkan sumber daya yang tidak lagi dapat didekodekan atau digunakan
+oleh server API Kubernetes.
+
+### Mengalihkan berkas konfigurasi kamu ke versi API baru
+
+Kamu dapat menggunakan perintah `kubectl convert` untuk mengubah berkas konfigurasi di antara versi API berbeda.
+
+```shell
+kubectl convert -f pod.yaml --output-version v1
+```
+
+Untuk opsi yang lainnya, silakan merujuk pada penggunaan dari perintah [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert).
+
+
diff --git a/content/id/docs/tasks/administer-cluster/manage-resources/_index.md b/content/id/docs/tasks/administer-cluster/manage-resources/_index.md
new file mode 100644
index 0000000000..b3094dde73
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/manage-resources/_index.md
@@ -0,0 +1,4 @@
+---
+title: Mengelola Memori, CPU, dan Sumber Daya API
+weight: 20
+---
diff --git a/content/id/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/id/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
new file mode 100644
index 0000000000..1aae3e38f0
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
@@ -0,0 +1,272 @@
+---
+title: Mengatur Batas Minimum dan Maksimum Memori pada sebuah Namespace
+content_type: task
+weight: 30
+---
+
+
+<!-- overview -->
+
+Laman ini menunjukkan cara untuk mengatur nilai minimum dan maksimum memori yang digunakan oleh Container
+yang berjalan pada sebuah Namespace. Kamu dapat menentukan nilai minimum dan maksimum memori pada objek
+[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core). Jika sebuah Pod tidak memenuhi batasan yang ditentukan oleh LimitRange,
+maka Pod tersebut tidak dapat dibuat pada Namespace tersebut.
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+Tiap Node dalam klastermu harus memiliki setidaknya 1 GiB memori.
+
+
+
+
+<!-- steps -->
+
+## Membuat sebuah Namespace
+
+Buat sebuah Namespace sehingga sumber daya yang kamu buat pada latihan ini
+terisolasi dari komponen lain pada klastermu.
+
+```shell
+kubectl create namespace constraints-mem-example
+```
+
+## Membuat LimitRange dan Pod
+
+Berikut berkas konfigurasi untuk sebuah LimitRange:
+
+{{< codenew file="admin/resource/memory-constraints.yaml" >}}
+
+Membuat LimitRange:
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
+```
+
+Melihat informasi mendetail mengenai LimitRange:
+
+```shell
+kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml
+```
+
+Keluaran yang dihasilkan menunjukkan batasan minimum dan maksimum dari memori seperti yang diharapkan. Tetapi
+perhatikan hal berikut, meskipun kamu tidak menentukan nilai bawaan pada berkas konfigurasi untuk 
+LimitRange, namun nilai tersebut akan dibuat secara otomatis.
+
+```
+  limits:
+  - default:
+      memory: 1Gi
+    defaultRequest:
+      memory: 1Gi
+    max:
+      memory: 1Gi
+    min:
+      memory: 500Mi
+    type: Container
+```
+
+Mulai sekarang setiap Container yang dibuat pada Namespace constraints-mem-example, Kubernetes
+akan menjalankan langkah-langkah berikut:
+
+* Jika Container tersebut tidak menentukan permintaan dan limit memori, maka diberikan nilai permintaan 
+dan limit memori bawaan pada Container.
+
+* Memastikan Container memiliki permintaan memori yang lebih besar atau sama dengan 500 MiB.
+
+* Memastikan Container memiliki limit memori yang lebih kecil atau kurang dari 1 GiB.
+
+Berikut berkas konfigurasi Pod yang memiliki satu Container. Manifes Container
+menentukan permintaan memori 600 MiB dan limit memori 800 MiB. Nilai tersebut memenuhi
+batasan minimum dan maksimum memori yang ditentukan oleh LimitRange.
+
+{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
+
+Membuat Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
+```
+
+Memastikan Container pada Pod sudah berjalan:
+
+```shell
+kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
+```
+
+Melihat informasi mendetail tentang Pod:
+
+```shell
+kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example
+```
+
+Keluaran yang dihasilkan menunjukkan Container memiliki permintaan memori 600 MiB dan limit memori
+800 MiB. Nilai tersebut memenuhi batasan yang ditentukan oleh LimitRange.
+
+```yaml
+resources:
+  limits:
+     memory: 800Mi
+  requests:
+    memory: 600Mi
+```
+
+Menghapus Podmu:
+
+```shell
+kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
+```
+
+## Mencoba membuat Pod yang melebihi batasan maksimum memori
+
+Berikut berkas konfigurasi untuk sebuah Pod yang memiliki satu Container. Container tersebut menentukan
+permintaan memori 800 MiB dan batas memori 1.5 GiB.
+
+{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
+
+Mencoba membuat Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
+```
+
+Keluaran yang dihasilkan menunjukkan Pod tidak dibuat, karena Container menentukan limit memori yang
+terlalu besar:
+
+```
+Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
+pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi.
+```
+
+## Mencoba membuat Pod yang tidak memenuhi permintaan memori
+
+Berikut berkas konfigurasi untuk sebuah Pod yang memiliki satu Container. Container tersebut menentukan
+permintaan memori 100 MiB dan limit memori 800 MiB.
+
+{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
+
+Mencoba membuat Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
+```
+
+Keluaran yang dihasilkan menunjukkan Pod tidak dibuat, karena Container menentukan permintaan memori yang
+terlalu kecil:
+
+```
+Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
+pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.
+```
+
+## Membuat Pod yang tidak menentukan permintaan ataupun limit memori
+
+
+
+Berikut berkas konfigurasi untuk sebuah Pod yang memiliki satu Container. Container tersebut tidak menentukan
+permintaan memori dan juga limit memori.
+
+{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
+
+Mencoba membuat Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
+```
+
+Melihat informasi mendetail tentang Pod:
+
+```
+kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml
+```
+
+Keluaran yang dihasilkan menunjukkan Container pada Pod memiliki permintaan memori 1 GiB dan limit memori 1 GiB.
+Bagaimana Container mendapatkan nilai tersebut?
+
+```
+resources:
+  limits:
+    memory: 1Gi
+  requests:
+    memory: 1Gi
+```
+
+Karena Containermu tidak menentukan permintaan dan limit memori, Container tersebut diberikan
+[permintaan dan limit memori bawaan](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+dari LimitRange.
+
+Pada tahap ini, Containermu mungkin saja berjalan ataupun mungkin juga tidak berjalan. Ingat bahwa prasyarat
+untuk tugas ini adalah Node harus memiliki setidaknya 1 GiB memori. Jika tiap Node hanya memiliki
+1 GiB memori, maka tidak akan ada cukup memori untuk dialokasikan pada setiap Node untuk memenuhi permintaan 1 Gib memori. Jika ternyata kamu menggunakan Node dengan 2 GiB memori, maka kamu mungkin memiliki cukup ruang untuk memenuhi permintaan 1 GiB tersebut.
+
+Menghapus Pod:
+
+```
+kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
+```
+
+## Pelaksanaan batasan minimum dan maksimum memori
+
+Batasan maksimum dan minimum memori yang yang ditetapkan pada sebuah Namespace oleh LimitRange dilaksanakan
+hanya ketika Pod dibuat atau diperbarui. Jika kamu mengubah LimitRange, hal tersebut tidak akan memengaruhi
+Pods yang telah dibuat sebelumnya.
+
+## Motivasi untuk batasan minimum dan maksimum memori
+
+Sebagai seorang administrator klaster, kamu mungkin ingin menetapkan pembatasan jumlah memori yang dapat digunakan oleh Pod.
+Sebagai contoh:
+
+* Tiap Node dalam sebuah klaster memiliki 2 GB memori. Kamu tidak ingin menerima Pod yang meminta
+lebih dari 2 GB memori, karena tidak ada Node pada klater yang dapat memenuhi permintaan tersebut.
+
+* Sebuah klaster digunakan bersama pada departemen produksi dan pengembangan.
+Kamu ingin mengizinkan beban kerja (_workload_) pada produksi untuk menggunakan hingga 8 GB memori, tapi
+kamu ingin beban kerja pada pengembangan cukup terbatas sampai dengan 512 MB saja. Kamu membuat Namespace terpisah
+untuk produksi dan pengembangan, dan kamu menerapkan batasan memori pada tiap Namespace.
+
+## Bersih-bersih
+
+Menghapus Namespace:
+
+```shell
+kubectl delete namespace constraints-mem-example
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### Untuk administrator klaster
+
+* [Mengatur Permintaan dan Limit Memori Bawaan untuk Sebuah Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+
+* [Mengatur Permintaan dan Limit CPU Bawaan untuk Sebuah Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+
+* [Mengatur Batas Minimum dan Maksimum CPU untuk Sebuah Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+
+* [Mengatur Kuota Memori dan CPU untuk Sebuah Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+
+* [Mengatur Kuota Pod untuk Sebuah Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+
+* [Mengatur Kuota untuk Objek API](/docs/tasks/administer-cluster/quota-api-object/)
+
+### Untuk pengembang aplikasi
+
+* [Memberikan Sumber Daya Memori pada Container dan Pod](/docs/tasks/configure-pod-container/assign-memory-resource/)
+
+* [Memberikan Sumber Daya CPU pada Container dan Pod](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+
+* [Mengatur Kualitas Layanan Pod](/docs/tasks/configure-pod-container/quality-service-pod/)
+
+
+
+
+
+
+
diff --git a/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md
new file mode 100644
index 0000000000..e1ac7b035e
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -0,0 +1,231 @@
+---
+title: Melakukan Reservasi Sumber Daya Komputasi untuk Daemon Sistem
+content_type: task
+min-kubernetes-server-version: 1.8
+---
+
+<!-- overview -->
+
+Node Kubernetes dapat dijadwalkan sesuai dengan kapasitas. Secara bawaan, Pod dapat menggunakan
+semua kapasitas yang tersedia pada sebuah Node. Ini merupakan masalah karena Node
+sebenarnya menjalankan beberapa _daemon_ sistem yang diperlukan oleh OS dan Kubernetes itu sendiri.
+Jika sumber daya pada Node tidak direservasi untuk _daemon-daemon_ tersebut, maka
+Pod dan _daemon_ akan berlomba-lomba menggunakan sumber daya yang tersedia, sehingga
+menyebabkan _starvation_ sumber daya pada Node.
+
+Fitur bernama `Allocatable` pada Node diekspos oleh kubelet yang berfungsi untuk melakukan
+reservasi sumber daya komputasi untuk _daemon_ sistem. Kubernetes merekomendasikan admin
+klaster untuk mengatur `Allocatable` pada Node berdasarkan tingkat kepadatan (_density_) beban kerja setiap Node.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+Kamu harus menjalankan Kubernetes server dengan versi 1.17 atau yang lebih baru
+untuk menggunakan perintah baris kubelet dengan opsi `--reserved-cpus` untuk
+menyetel [daftar reservasi CPU secara eksplisit](#melakukan-reservasi-daftar-cpu-secara-eksplisit).
+
+
+
+<!-- steps -->
+
+## _Allocatable_ pada Node
+
+```text
+       Kapasitas Node
+------------------------------
+|       kube-reserved        |
+|----------------------------|
+|      system-reserved       |
+|----------------------------|
+|     eviction-threshold     |
+|     (batas pengusiran)     |
+|----------------------------|
+|                            |
+|        allocatable         |
+| (dapat digunakan oleh Pod) |
+|                            |
+|                            |
+------------------------------
+```
+
+`Allocatable` atau sumber daya yang dialokasikan pada sebuah Node Kubernetes merupakan
+jumlah sumber daya komputasi yang dapat digunakan oleh Pod. Penjadwal tidak
+dapat melakukan penjadwalan melebihi `Allocatable`. Saat ini dukungan terhadap
+`CPU`, `memory` dan `ephemeral-storage` tersedia.
+
+`Allocatable` pada Node diekspos oleh objek API `v1.Node` dan merupakan
+bagian dari baris perintah `kubectl describe node`.
+
+Sumber daya dapat direservasi untuk dua kategori _daemon_ sistem melalui kubelet.
+
+### Mengaktifkan QoS dan tingkatan cgroup dari Pod
+
+Untuk menerapkan batasan `Allocatable` pada Node, kamu harus mengaktifkan
+hierarki cgroup yang baru melalui _flag_ `--cgroups-per-qos`. Secara bawaan, _flag_ ini
+telah aktif. Saat aktif, kubelet akan memasukkan semua Pod pengguna di bawah
+sebuah hierarki cgroup yang dikelola oleh kubelet.
+
+### Mengonfigurasi _driver_ cgroup
+
+Manipulasi terhadap hierarki cgroup pada hos melalui _driver_ cgroup didukung oleh kubelet.
+_Driver_ dikonfigurasi melalui _flag_ `--cgroup-driver`.
+
+Nilai yang didukung adalah sebagai berikut:
+
+* `cgroupfs` merupakan _driver_ bawaan yang melakukan manipulasi secara langsung
+terhadap _filesystem_ cgroup pada hos untuk mengelola _sandbox_ cgroup.
+* `systemd` merupakan _driver_ alternatif yang mengelola _sandbox_ cgroup menggunakan
+bagian dari sumber daya yang didukung oleh sistem _init_ yang digunakan.
+
+Tergantung dari konfigurasi _runtime_ Container yang digunakan,
+operator dapat memilih _driver_ cgroup tertentu untuk memastikan perilaku sistem yang tepat.
+Misalnya, jika operator menggunakan _driver_ cgroup `systemd` yang disediakan oleh
+_runtime_ docker, maka kubelet harus diatur untuk menggunakan _driver_ cgroup `systemd`.
+
+### Kube Reserved
+
+- **_Flag_ Kubelet**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
+- **_Flag_ Kubelet**: `--kube-reserved-cgroup=`
+
+`kube-reserved` berfungsi untuk mengambil informasi sumber daya reservasi
+untuk _daemon_ sistem Kubernetes, seperti kubelet, _runtime_ Container, detektor masalah pada Node, dsb.
+`kube-reserved` tidak berfungsi untuk mereservasi sumber daya untuk _daemon_ sistem yang berjalan
+sebagai Pod. `kube-reserved`  merupakan fungsi dari kepadatan Pod pada Node.
+
+Selain dari `cpu`, `memory`, dan `ephemeral-storage`,`pid` juga dapat
+diatur untuk mereservasi jumlah ID proses untuk _daemon_ sistem Kubernetes.
+
+Secara opsional, kamu dapat memaksa _daemon_ sistem melalui setelan `kube-reserved`.
+Ini dilakukan dengan menspesifikasikan _parent_ cgroup sebagai nilai dari _flag_ `--kube-reserved-cgroup` pada kubelet.
+
+Kami merekomendasikan _daemon_ sistem Kubernetes untuk ditempatkan pada
+tingkatan cgroup yang tertinggi (contohnya, `runtime.slice` pada mesin systemd).
+Secara ideal, setiap _daemon_ sistem sebaiknya dijalankan pada _child_ cgroup
+di bawah _parent_ ini. Lihat [dokumentasi](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
+untuk mengetahui rekomendasi hierarki cgroup secara detail.
+
+Catatan: kubelet **tidak membuat** `--kube-reserved-cgroup` jika cgroup
+yang diberikan tidak ada pada sistem. Jika cgroup yang tidak valid diberikan,
+maka kubelet akan mengalami kegagalan.
+
+### System Reserved
+
+- **_Flag_ Kubelet**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
+- **_Flag_ Kubelet**: `--system-reserved-cgroup=`
+
+
+`system-reserved` berfungsi untuk mengetahui reservasi sumber daya untuk
+_daemon_ sistem pada OS, seperti `sshd`, `udev`, dan lainnya. `system-reserved` sebaiknya
+mereservasi memori untuk kernel juga, karena memori kernel tidak termasuk dalam
+hitungan kalkulasi Pod pada Kubernetes. Kami juga merekomendasikan reservasi sumber daya
+untuk sesi (_session_) login pengguna (contohnya, `user.slice` di dalam dunia systemd).
+
+### Melakukan Reservasi Daftar CPU secara Eksplisit
+{{< feature-state for_k8s_version="v1.17" state="stable" >}}
+
+- **_Flag_ Kubelet**: `--reserved-cpus=0-3`
+
+`reserved-cpus` berfungsi untuk mendefinisikan [cpuset](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) secara eksplisit untuk
+_daemon_ sistem OS dan _daemon_ sistem Kubernetes. `reserved-cpus` dimaksudkan untuk
+sistem-sistem yang tidak mendefinisikan tingkatan cgroup tertinggi secara terpisah untuk
+_daemon_ sistem OS dan _daemon_ sistem Kubernetes yang berkaitan dengan sumber daya cpuset.
+
+Jika kubelet **tidak memiliki** `--system-reserved-cgroup` dan `--kube-reserved-cgroup`,
+cpuset akan diberikan secara eksplisit oleh `reserved-cpus`, yang akan menimpa definisi
+yang diberikan oleh opsi `--kube-reserved` dan `--system-reserved`.
+
+Opsi ini dirancang secara spesifik untuk kasus-kasus Telco/NFV, di mana _interrupt_ atau _timer_
+yang tidak terkontrol bisa memengaruhi performa dari beban kerja. Kamu dapat menggunakan
+opsi untuk untuk mendefinisikan cpuset secara eksplisit untuk _daemon_ sistem/Kubernetes dan
+_interrupt_/_timer_, sehingga CPU sisanya dalam sistem akan digunakan untuk beban kerja saja,
+dengan dampak yang sedikit terhadap _interrupt_/_timer_ yang tidak terkontrol. Untuk
+memindahkan _daemon_ sistem, _daemon_ Kubernetes serta _interrrupt_/_timer_ Kubernetes supaya
+menggunakan cpuset yang eksplisit didefinisikan oleh opsi ini, sebaiknya digunakan mekanisme lain di luar Kubernetes. Contohnya: pada Centos, kamu dapat melakukan ini dengan menggunakan
+toolset yang sudah disetel.
+
+### Batas Pengusiran (_Eviction Threshold_)
+
+- **_Flag_ Kubelet**: `--eviction-hard=[memory.available<500Mi]`
+
+Tekanan memori pada tingkatan Node menyebabkan sistem OOM (_Out Of Memory_) yang
+berdampak pada Node secara keseluruhan dan semua Pod yang dijalankan di dalamnya. 
+Node dapat berubah menjadi _offline_ sementara sampai memori berhasil diklaim kembali.
+Untuk menghindari sistem OOM, atau mengurangi kemungkinan terjadinya OOM, kubelet
+menyediakan fungsi untuk pengelolaan saat [Kehabisan Sumber Daya (_Out of Resource_)](/docs/tasks/administer-cluster/out-of-resource/).
+Pengusiran dapat dilakukan hanya untuk kasus kehabisan `memory` dan `ephemeral-storage`. Dengan mereservasi
+sebagian memori melalui _flag_ `--eviction-hard`, kubelet akan berusaha untuk "mengusir" (_evict_)
+Pod ketika ketersediaan memori pada Node jatuh di bawah nilai yang telah direservasi.
+Dalam bahasa sederhana, jika _daemon_ sistem tidak ada pada Node, maka Pod tidak dapat menggunakan
+memori melebihi nilai yang ditentukan oleh _flag_ `--eviction-hard`. Karena alasan ini,
+sumber daya yang direservasi untuk pengusiran tidak tersedia untuk Pod.
+
+### Memaksakan _Allocatable_ pada Node
+
+- **_Flag_ Kubelet**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
+
+Penjadwal menganggap `Allocatable` sebagai kapasitas yang tersedia untuk digunakan oleh Pod.
+
+Secara bawaan, kubelet memaksakan `Allocatable` untuk semua Pod. Pemaksaan dilakukan
+dengan cara "mengusir" Pod-Pod ketika penggunaan sumber daya Pod secara keseluruhan telah
+melewati nilai `Allocatable`. Lihat [bagian ini](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)
+untuk mengetahui kebijakan pengusiran secara detail. Pemaksaan ini dikendalikan dengan
+cara memberikan nilai Pod melalui _flag_ `--enforce-node-allocatable` pada kubelet.
+
+Secara opsional, kubelet dapat diatur untuk memaksakan `kube-reserved` dan
+`system-reserved` dengan memberikan nilai melalui _flag_ tersebut. Sebagai catatan,
+jika kamu mengatur `kube-reserved`, maka kamu juga harus mengatur `--kube-reserved-cgroup`. Begitu pula
+jika kamu mengatur `system-reserved`, maka kamu juga harus mengatur `--system-reserved-cgroup`.
+
+## Panduan Umum
+
+_Daemon_ sistem dilayani mirip seperti Pod `Guaranteed` yang terjamin sumber dayanya.
+_Daemon_ sistem dapat melakukan _burst_ di dalam jangkauan cgroup. Perilaku ini
+dikelola sebagai bagian dari penggelaran (_deployment_) Kubernetes. Sebagai contoh,
+kubelet harus memiliki cgroup sendiri dan membagikan sumber daya `kube-reserved` dengan
+_runtime_ Container. Namun begitu, kubelet tidak dapat melakukan _burst_ dan menggunakan
+semua sumber daya yang tersedia pada Node jika `kube-reserved` telah dipaksakan pada sistem.
+
+Kamu harus berhati-hati ekstra ketika memaksakan reservasi `system-reserved` karena dapat
+menyebabkan layanan sistem yang terpenting mengalami CPU _starvation_, OOM _killed_, atau tidak
+dapat melakukan _fork_ pada Node. Kami menyarankan untuk memaksakan `system-reserved` hanya
+jika pengguna telah melakukan _profiling_ sebaik mungkin pada Node mereka untuk
+mendapatkan estimasi yang akurat dan percaya diri terhadap kemampuan mereka untuk
+memulihkan sistem ketika ada grup yang terkena OOM _killed_.
+
+* Untuk memulai, paksakan `Allocatable` pada Pod.
+* Ketika _monitoring_ dan _alerting_ telah cukup dilakukan untuk memonitor _daemon_
+dari sistem Kubernetes, usahakan untuk memaksakan `kube-reserved` berdasarkan penggunakan heuristik.
+* Jika benar-benar diperlukan, paksakan `system-reserved` secara bertahap.
+
+Sumber daya yang diperlukan oleh _daemon_ sistem Kubernetes dapat tumbuh seiring waktu dengan
+adanya penambahan fitur-fitur baru. Proyek Kubernetes akan berusaha untuk menurunkan penggunaan sumber daya
+dari _daemon_ sistem Node, tetapi belum menjadi prioritas untuk saat ini.
+Kamu dapat berekspektasi bahwa fitur kapasitas `Allocatable` ini akan dihapus pada versi yang akan datang.
+
+
+
+<!-- discussion -->
+
+## Contoh Skenario
+
+Berikut ini merupakan contoh yang menggambarkan komputasi `Allocatable` pada Node:
+
+* Node memiliki 16 CPU, memori sebesar 32Gi, dan penyimpanan sebesar 100Gi.
+* `--kube-reserved` diatur menjadi `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
+* `--system-reserved` diatur menjadi `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
+* `--eviction-hard` diatur menjadi `memory.available<500Mi,nodefs.available<10%`
+
+Dalam skenario ini, `Allocatable` akan menjadi 14.5 CPU, memori 28.5Gi, dan penyimpanan
+lokal 88Gi.
+Penjadwal memastikan bahwa semua Pod yang berjalan pada Node ini secara total tidak meminta memori melebihi
+28.5Gi dan tidak menggunakan penyimpanan lokal melebihi 88Gi.
+Pengusiran Pod akan dilakukan kubelet ketika penggunaan memori keseluruhan oleh Pod telah melebihi 28.5Gi,
+atau jika penggunaan penyimpanan keseluruhan telah melebihi 88Gi. Jika semua proses pada Node mengonsumsi
+CPU sebanyak-banyaknya, Pod-Pod tidak dapat mengonsumsi lebih dari 14.5 CPU.
+
+Jika `kube-reserved` dan/atau `system-reserved` tidak dipaksakan dan _daemon_ sistem
+melebihi reservasi mereka, maka kubelet akan mengusir Pod ketika penggunaan memori pada Node
+melebihi 31.5Gi atau penggunaan penyimpanan melebihi 90Gi.
diff --git a/content/id/docs/tasks/administer-cluster/sysctl-cluster.md b/content/id/docs/tasks/administer-cluster/sysctl-cluster.md
new file mode 100644
index 0000000000..9adbb50a9f
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/sysctl-cluster.md
@@ -0,0 +1,210 @@
+---
+title: Menggunakan sysctl dalam Sebuah Klaster Kubernetes
+content_type: task
+---
+
+<!-- overview -->
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
+
+Dokumen ini menjelaskan tentang cara mengonfigurasi dan menggunakan parameter kernel dalam sebuah
+klaster Kubernetes dengan menggunakan antarmuka {{< glossary_tooltip term_id="sysctl" >}}.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+## Melihat Daftar Semua Parameter Sysctl
+
+Dalam Linux, antarmuka sysctl memungkinkan administrator untuk memodifikasi kernel
+parameter pada _runtime_. Parameter tersedia melalui sistem file virtual dari proses `/proc/sys/`.
+Parameter mencakup berbagai subsistem seperti:
+
+- kernel (dengan prefiks umum: `kernel.`)
+- networking (dengan prefiks umum: `net.`)
+- virtual memory (dengan prefiks umum: `vm.`)
+- MDADM (dengan prefiks umum: `dev.`)
+- subsistem yang lainnya dideskripsikan pada [dokumentasi Kernel](https://www.kernel.org/doc/Documentation/sysctl/README).
+
+Untuk mendapatkan daftar semua parameter, kamu bisa menjalankan perintah:
+
+```shell
+sudo sysctl -a
+```
+
+## Mengaktifkan Sysctl _Unsafe_
+
+Sysctl dikelompokkan menjadi sysctl _safe_ dan sysctl _unsafe_. Sebagai tambahan untuk
+pengaturan _Namespace_ yang benar, sebuah sysctl _safe_ harus diisolasikan dengan benar diantara Pod dalam Node yang sama.
+Hal ini berarti mengatur sysctl _safe_ dalam satu Pod:
+
+- tidak boleh mempengaruhi Pod lain dalam Node
+- tidak boleh membahayakan kesehatan dari Node
+- tidak mengizinkan untuk mendapatkan sumber daya CPU atau memori di luar batas sumber daya dari sebuah Pod.
+
+
+Sejauh ini, sebagian besar sysctl yang diatur sebagai Namespace belum tentu dianggap sysctl _safe_.
+Sysctl berikut ini didukung dalam kelompok _safe_:
+
+- `kernel.shm_rmid_forced`,
+- `net.ipv4.ip_local_port_range`,
+- `net.ipv4.tcp_syncookies`,
+- `net.ipv4.ping_group_range` (sejak Kubernetes 1.18).
+
+{{< note >}}
+Contoh `net.ipv4.tcp_syncookies` bukan merupakan Namespace pada kernel Linux versi 4.4 atau lebih rendah.
+
+Daftar ini akan terus dikembangkan dalam versi Kubernetes berikutnya ketika kubelet
+mendukung mekanisme isolasi yang lebih baik.
+
+Semua sysctl _safe_ diaktifkan secara bawaan.
+
+Semua sysctl _unsafe_ dinon-aktifkan secara bawaan dan harus diizinkan secara manual oleh
+administrator klaster untuk setiap Node. Pod dengan sysctl _unsafe_ yang dinon-aktifkan akan dijadwalkan, 
+tetapi akan gagal untuk dijalankan.
+
+Dengan mengingat peringatan di atas, administrator klaster dapat mengizinkan sysctl _unsafe_ tertentu
+untuk situasi yang sangat spesial seperti pada saat kinerja tinggi atau
+penyetelan aplikasi secara _real-time_. _Unsafe_ syctl diaktifkan Node demi Node melalui
+_flag_ pada kubelet; sebagai contoh:
+
+```shell
+kubelet --allowed-unsafe-sysctls \
+  'kernel.msg*,net.core.somaxconn' ...
+```
+
+Untuk {{< glossary_tooltip term_id="minikube" >}}, ini dapat dilakukan melalui _flag_ `extra-config`:
+
+```shell
+minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...
+```
+
+Hanya sysctl yang diatur sebagai Namespace dapat diaktifkan dengan cara ini.
+
+## Mnegatur Sysctl untuk Pod
+
+Sejumlah sysctl adalah diatur sebagai Namespace dalam Kernel Linux hari ini. Ini berarti
+mereka dapat diatur secara independen untuk setiap Pod dalam sebuah Node. Hanya sysctl dengan Namespace
+yang dapat dikonfigurasi melalui Pod securityContext dalam Kubernetes.
+
+Sysctl berikut dikenal sebagai Namespace. Daftar ini dapat berubah
+pada versi kernel Linux yang akan datang.
+
+- `kernel.shm*`,
+- `kernel.msg*`,
+- `kernel.sem`,
+- `fs.mqueue.*`,
+- Parameter dibawah `net.*` dapat diatur sebagai Namespace dari _container networking_
+  Namun, ada beberapa perkecualian (seperti
+  `net.netfilter.nf_conntrack_max` dan `net.netfilter.nf_conntrack_expect_max`
+  yang dapat diatur dalam Namespace _container networking_ padahal bukan merupakan Namespace).
+
+Sysctl tanpa Namespace disebut dengan sysctl _node-level_. Jika kamu perlu mengatur
+mereka, kamu harus secara manual mengonfigurasi mereka pada sistem operasi setiap Node, atau dengan
+menggunakan DaemonSet melalui Container yang berwenang.
+
+Gunakan securityContext dari Pod untuk mengonfigurasi sysctl Namespace. securityContext
+berlaku untuk semua Container dalam Pod yang sama.
+
+
+Contoh ini menggunakan securityContext dari Pod untuk mengatur sebuah sysctl _safe_
+`kernel.shm_rmid_forced`, dan dua buah sysctl _unsafe_ `net.core.somaxconn` dan
+`kernel.msgmax`. Tidak ada perbedaan antara sysctl _safe_ dan sysctl _unsafe_ dalam
+spesifikasi tersebut.
+
+{{< warning >}}
+Hanya modifikasi parameter sysctl setelah kamu memahami efeknya, untuk menghindari
+gangguan pada kestabilan sistem operasi kamu.
+{{< /warning >}}
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: sysctl-example
+spec:
+  securityContext:
+    sysctls:
+    - name: kernel.shm_rmid_forced
+      value: "0"
+    - name: net.core.somaxconn
+      value: "1024"
+    - name: kernel.msgmax
+      value: "65536"
+  ...
+```
+
+
+<!-- discussion -->
+
+{{< warning >}}
+Karena sifat alami dari sysctl _unsafe_, penggunaan sysctl _unsafe_
+merupakan resiko kamu sendiri dan dapat menyebabkan masalah parah seperti perilaku yang salah
+pada Container, kekurangan sumber daya, atau kerusakan total dari Node.
+{{< /warning >}}
+
+Merupakan sebuah praktik yang baik untuk mempertimbangkan Node dengan pengaturan sysctl khusus sebagai
+Node yang tercemar (_tainted_) dalam sebuah cluster, dan hanya menjadwalkan Pod yang membutuhkan pengaturan sysctl.
+Sangat disarankan untuk menggunakan Kubernetes [fitur _taints and toleration_](/docs/reference/generated/kubectl/kubectl-commands/#taint) untuk mengimplementasikannya.
+
+Pod dengan sysctl _unsafe_ akan gagal diluncurkan pada sembarang Node yang belum
+mengaktifkan kedua sysctl _unsafe_ secara eksplisit. Seperti halnya sysctl _node-level_ sangat
+disarankan untuk menggunakan [fitur _taints and toleration_](/docs/reference/generated/kubectl/kubectl-commands/#taint) atau
+[pencemaran dalam Node](/docs/concepts/scheduling-eviction/taint-and-toleration/)
+untuk Pod dalam Node yang tepat.
+
+## PodSecurityPolicy
+
+Kamu selanjutnya dapat mengontrol sysctl mana saja yang dapat diatur dalam Pod dengan menentukan daftar
+sysctl atau pola (_pattern_) sysctl dalam `forbiddenSysctls` dan/atau _field_
+`allowedUnsafeSysctls` dari PodSecurityPolicy. Pola sysctl diakhiri
+dengan karakter `*`, seperti `kernel.*`. Karakter `*` saja akan mencakup
+semua sysctl.
+
+Secara bawaan, semua sysctl _safe_ diizinkan.
+
+Kedua `forbiddenSysctls` dan `allowedUnsafeSysctls` merupakan daftar dari nama sysctl
+atau pola sysctl yang polos (yang diakhiri dengan karakter `*`). Karakter `*` saja berarti sesuai dengan semua sysctl.
+
+_Field_ `forbiddenSysctls` tidak memasukkan sysctl tertentu. Kamu dapat melarang 
+kombinasi sysctl _safe_ dan sysctl _unsafe_ dalam daftar tersebut. Untuk melarang pengaturan
+sysctl, hanya gunakan `*` saja.
+
+Jika kamu menyebutkan sysctl _unsafe_ pada _field_ `allowedUnsafeSysctls` dan 
+tidak ada pada _field_ `forbiddenSysctls`, maka sysctl dapat digunakan pada Pod
+dengan menggunakan PodSecurityPolicy ini. Untuk mengizinkan semua sysctl _unsafe_ diatur dalam
+PodSecurityPolicy, gunakan karakter `*` saja.
+
+Jangan mengonfigurasi kedua _field_ ini sampai tumpang tindih, dimana
+sysctl yang diberikan akan diperbolehkan dan dilarang sekaligus.
+
+{{< warning >}}
+Jika kamu mengizinkan sysctl _unsafe_ melalui _field_ `allowUnsafeSysctls`
+pada PodSecurityPolicy, Pod apa pun yang menggunakan sysctl seperti itu akan gagal dimulai
+jika sysctl _unsafe_ tidak diperbolehkan dalam _flag_ kubelet `--allowed-unsafe-sysctls`
+pada Node tersebut.
+{{< /warning >}}
+
+Ini merupakan contoh sysctl _unsafe_ yang diawali dengan `kernel.msg` yang diperbolehkan dan
+sysctl `kernel.shm_rmid_forced` yang dilarang.
+
+```yaml
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: sysctl-psp
+spec:
+  allowedUnsafeSysctls:
+  - kernel.msg*
+  forbiddenSysctls:
+  - kernel.shm_rmid_forced
+ ...
+```
+
+
diff --git a/content/id/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/id/docs/tasks/configure-pod-container/assign-memory-resource.md
new file mode 100644
index 0000000000..bb092e86a5
--- /dev/null
+++ b/content/id/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -0,0 +1,367 @@
+---
+title: Menetapkan Sumber Daya Memori untuk Container dan Pod
+content_type: task
+weight: 10
+---
+
+<!-- overview -->
+
+Laman ini menunjukkan bagaimana menetapkan permintaan dan batasan memori untuk Container.
+Container dijamin memiliki memori sebanyak yang diminta,
+tetapi tidak diperbolehkan untuk menggunakan memori melebihi batas.
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+Setiap Node pada klaster kamu harus memiliki memori setidaknya 300 MiB.
+
+Beberapa langkah pada laman ini mengharuskan kamu menjalankan Service
+[_metrics-server_](https://github.com/kubernetes-incubator/metrics-server)
+pada klaster kamu. Jika kamu memiliki _metrics-server_
+yang sudah berjalan, kamu dapat melewati langkah-langkah berikut ini.
+
+Jika kamu menjalankan Minikube, jalankan perintah berikut untuk mengaktifkan
+_metrics-server_:
+
+```shell
+minikube addons enable metrics-server
+```
+
+Untuk melihat apakah _metrics-server_ sudah berjalan, atau penyedia lain dari API metrik sumber daya
+(`metrics.k8s.io`), jalankan perintah berikut ini:
+
+```shell
+kubectl get apiservices
+```
+
+Jika API metrik sumber daya telah tersedia, keluarannya meliputi seperti
+acuan pada `metrics.k8s.io`.
+
+```shell
+NAME
+v1beta1.metrics.k8s.io
+```
+
+
+
+<!-- steps -->
+
+## Membuat Namespace
+
+Buat Namespace sehingga sumber daya yang kamu buat dalam latihan ini 
+terisolasi dari klaster kamu yang lain.
+
+```shell
+kubectl create namespace mem-example
+```
+
+## Menentukan permintaan memori dan batasan memori
+
+Untuk menentukan permintaan memori untuk Container, sertakan _field_ `resources:requests`
+pada manifes sumber daya dari Container. Untuk menentukan batasan memori, sertakan `resources:limits`.
+
+Dalam latihan ini, kamu akan membuat Pod yang memiliki satu Container. Container memiliki permintaan memori
+sebesar 100 MiB dan batasan memori sebesar 200 MiB. Berikut berkas konfigurasi
+untuk Pod:
+
+{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
+
+Bagian `args` dalam berkas konfigurasi memberikan argumen untuk Container pada saat dimulai.
+Argumen`"--vm-bytes", "150M"` memberi tahu Container agar mencoba mengalokasikan memori sebesar 150 MiB.
+
+Buatlah Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
+```
+
+Verifikasi apakah Container dalam Pod sudah berjalan:
+
+```shell
+kubectl get pod memory-demo --namespace=mem-example
+```
+
+Lihat informasi mendetil tentang Pod:
+
+```shell
+kubectl get pod memory-demo --output=yaml --namespace=mem-example
+```
+
+Keluarannya menunjukkan bahwa satu Container dalam Pod memiliki permintaan memori sebesar 100 MiB
+dan batasan memori sebesar 200 MiB.
+
+```yaml
+...
+resources:
+  limits:
+    memory: 200Mi
+  requests:
+    memory: 100Mi
+...
+```
+
+Jalankan `kubectl top` untuk mengambil metrik dari Pod:
+
+```shell
+kubectl top pod memory-demo --namespace=mem-example
+```
+
+Keluarannya menunjukkan bahwa Pod menggunakan memori sekitar 162.900.000 byte, dimana
+sekitar 150 MiB. Ini lebih besar dari permintaannya sebesar 100 MiB Pod, tetapi masih di dalam
+batasan Pod sebesar 200 MiB.
+
+
+```
+NAME                        CPU(cores)   MEMORY(bytes)
+memory-demo                 <something>  162856960
+```
+
+Hapuslah Pod:
+
+```shell
+kubectl delete pod memory-demo --namespace=mem-example
+```
+
+## Melebihi batasan memori dari Container
+
+Container dapat melebihi permintaan memorinya jika Node memiliki memori yang tersedia. Tapi sebuah Container
+tidak diperbolehkan untuk menggunakan lebih dari batasan memorinya. Jika Container mengalokasikan lebih banyak memori daripada
+batasannya, Container menjadi kandidat untuk dihentikan. Jika Container terus berlanjut
+mengkonsumsi memori melebihi batasnya, maka Container akan diakhiri. Jika Container dihentikan dan bisa
+di mulai ulang, kubelet akan memulai ulang, sama seperti jenis kegagalan _runtime_ yang lainnya.
+
+Dalam latihan ini, kamu membuat Pod yang mencoba mengalokasikan lebih banyak memori dari batasannya.
+Berikut adalah berkas konfigurasi untuk Pod yang memiliki satu Container dengan berkas
+permintaan memori sebesar 50 MiB dan batasan memori sebesar 100 MiB:
+
+{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
+
+Dalam bagian `args` dari berkas konfigurasi, kamu dapat melihat bahwa Container tersebut
+akan mencoba mengalokasikan memori sebesar 250 MiB, yang jauh di atas batas yaitu 100 MiB.
+
+Buatlah Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
+```
+
+Lihat informasi mendetail tentang Pod:
+
+```shell
+kubectl get pod memory-demo-2 --namespace=mem-example
+```
+
+Sampai sini, Container mungkin sedang berjalan atau dimatikan. Ulangi perintah sebelumnya hingga Container dimatikan:
+
+```shell
+NAME            READY     STATUS      RESTARTS   AGE
+memory-demo-2   0/1       OOMKilled   1          24s
+```
+
+Dapatkan tampilan yang lebih mendetail tentang status Container:
+
+```shell
+kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
+```
+
+Keluarannya menunjukkan bahwa Container dimatikan karena kehabisan memori (OOM):
+
+```shell
+lastState:
+   terminated:
+     containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
+     exitCode: 137
+     finishedAt: 2017-06-20T20:52:19Z
+     reason: OOMKilled
+     startedAt: null
+```
+
+Container dalam latihan ini dapat dimulai ulang, sehingga kubelet akan memulai ulangnya. Ulangi
+perintah ini beberapa kali untuk melihat bahwa Container berulang kali dimatikan dan dimulai ulang:
+
+```shell
+kubectl get pod memory-demo-2 --namespace=mem-example
+```
+
+Keluarannya menunjukkan bahwa Container dimatikan, dimulai ulang, dimatikan lagi, dimulai ulang lagi, dan seterusnya:
+
+```
+kubectl get pod memory-demo-2 --namespace=mem-example
+NAME            READY     STATUS      RESTARTS   AGE
+memory-demo-2   0/1       OOMKilled   1          37s
+```
+```
+
+kubectl get pod memory-demo-2 --namespace=mem-example
+NAME            READY     STATUS    RESTARTS   AGE
+memory-demo-2   1/1       Running   2          40s
+```
+
+Lihat informasi mendetail tentang riwayat Pod:
+
+```
+kubectl describe pod memory-demo-2 --namespace=mem-example
+```
+
+
+Keluarannya menunjukkan bahwa Container dimulai dan gagal berulang kali:
+
+```
+... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
+... Warning BackOff   Back-off restarting failed container
+```
+
+Lihat informasi mendetail tentang Node klaster Anda:
+
+```
+kubectl describe nodes
+```
+
+Keluarannya mencakup rekaman Container yang dimatikan karena kondisi kehabisan memori:
+
+
+```
+Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
+```
+
+Hapus Pod kamu:
+
+```shell
+kubectl delete pod memory-demo-2 --namespace=mem-example
+```
+
+## Menentukan permintaan memori yang terlalu besar untuk Node kamu
+
+Permintaan dan batasan memori yang dikaitkan dengan Container, berguna untuk berpikir
+apakah sebuah Pod yang memiliki permintaan dan batasan memori. Permintaan memori untuk Pod tersebut adalah
+jumlah permintaan memori untuk semua Container dalam Pod. Begitu juga dengan batasan memori
+untuk Pod adalah jumlah batasan memori dari semua Container di dalam Pod.
+
+Penjadwalan Pod didasarkan pada permintaan. Sebuah Pod dijadwalkan untuk berjalan di sebuah Node hanya jika sebuah Node
+memiliki cukup memori yang tersedia untuk memenuhi permintaan memori dari Pod tersebut.
+
+Dalam latihan ini, kamu membuat Pod yang memiliki permintaan memori yang sangat besar sehingga melebihi
+kapasitas dari Node mana pun dalam klaster kamu. Berikut adalah berkas konfigurasi untuk Pod yang memiliki
+Container dengan permintaan memori 1000 GiB, yang kemungkinan besar melebihi kapasitas
+dari setiap Node dalam klaster kamu.
+
+{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
+
+Buatlah Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
+```
+
+Lihat status Pod:
+
+```shell
+kubectl get pod memory-demo-3 --namespace=mem-example
+```
+
+Keluarannya menunjukkan bahwa status Pod adalah PENDING. Artinya, Pod tidak dijadwalkan untuk berjalan di Node mana pun, dan Pod akan tetap dalam status PENDING tanpa batas waktu:
+
+```
+kubectl get pod memory-demo-3 --namespace=mem-example
+NAME            READY     STATUS    RESTARTS   AGE
+memory-demo-3   0/1       Pending   0          25s
+```
+
+Lihat informasi mendetail tentang Pod, termasuk _event_:
+
+```shell
+kubectl describe pod memory-demo-3 --namespace=mem-example
+```
+
+Keluarannya menunjukkan bahwa Container tidak dapat dijadwalkan karena memori yang tidak cukup pada Node:
+
+```shell
+Events:
+  ...  Reason            Message
+       ------            -------
+  ...  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient memory (3).
+```
+
+## Satuan Memori
+
+Sumber daya memori diukur dalam satuan _byte_. Kamu dapat mengekspresikan memori sebagai bilangan bulat biasa atau
+bilangan bulan _fixed-point_ dengan salah satu akhiran ini: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki.
+Contoh berikut ini mewakili nilai yang kira-kira sama:
+
+```shell
+128974848, 129e6, 129M , 123Mi
+```
+
+Hapuslah Pod kamu:
+
+```shell
+kubectl delete pod memory-demo-3 --namespace=mem-example
+```
+
+## Jika kamu tidak menentukan batasan memori
+
+Jika kamu tidak menentukan batasan memori untuk sebuah Container, salah satu dari situasi berikut ini berlaku:
+
+* Container tidak memiliki batasan maksimum jumlah memori yang digunakannya. Container
+dapat menggunakan semua memori yang tersedia dalam Node dimana Container itu berjalan yang pada gilirannya dapat memanggil penyetop OOM (_out-of-memory_).
+Lebih lanjut, dalam kasus menghentikan OOM, Container tanpa batas sumber daya akan memiliki peluang lebih besar untuk dihentikan.
+
+* Container berjalan pada Namespace yang memiliki batasan bawaan memori, dan
+Container secara otomatis menetapkan batasan bawaan. Administrator klaster dapat menggunakan
+[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
+untuk menentukan batasan memori secara bawaan.
+
+## Motivasi untuk permintaan dan batasan memori
+
+Dengan mengonfigurasi permintaan dan batasan memori untuk Container yang berjalan pada berkas
+klaster, kamu dapat menggunakan sumber daya memori yang tersedia pada Node klaster kamu secara efisien.
+Dengan menjaga permintaan memori pada Pod tetap rendah, kamu memberikan kesempatan yang baik untuk Pod tersebut
+dijadwalkan. Dengan memiliki batas memori yang lebih besar dari permintaan memori, Anda mencapai dua hal:
+
+* Pod dapat memiliki aktivitas yang bersifat _burst_ dengan memanfaatkan memori yang kebetulan tersedia.
+* Jumlah memori yang dapat digunakan Pod selama keadaan _burst_ dibatasi pada jumlah yang wajar.
+
+## Membersihkan
+
+Hapus Namespace kamu. Ini akan menghapus semua Pod yang kamu buat untuk tugas ini:
+
+```shell
+kubectl delete namespace mem-example
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### Untuk pengembang aplikasi
+
+* [Menetapkan sumber daya CPU ke Container dan Pod](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+
+* [Mengonfigurasi _Quality of Service_ untuk Pod](/docs/tasks/configure-pod-container/quality-service-pod/)
+
+### Untuk administrator klaster
+
+* [Mengonfigurasi permintaan dan batasan bawaan memori untuk Namespace](/id/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+
+* [Mengonfigurasi permintaan dan batasan bawaan CPU untuk Namespace](/id/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+
+* [Mengonfigurasi batasan memori minimum dan maksimum untuk Namespace](/id/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+
+* [Mengonfigurasi batasan CPU minimum dan maksimum untuk Namespace](/id/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+
+* [Mengonfigurasi kuota CPU dan memori untuk Namespace](/id/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+
+* [Mengonfigurasi kuota Pod untuk Namespace](/id/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+
+* [Mengonfigurasi kuota untuk objek API](/id/docs/tasks/administer-cluster/quota-api-object/)
+
+
+
+
+
diff --git a/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md
new file mode 100644
index 0000000000..2da9cebcda
--- /dev/null
+++ b/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -0,0 +1,135 @@
+---
+title: Mengatur Pod untuk Menggunakan Volume sebagai Tempat Penyimpanan
+content_type: task
+weight: 50
+---
+
+<!-- overview -->
+
+Laman ini menjelaskan bagaimana cara mengatur sebuah Pod untuk menggunakan Volume sebagai tempat penyimpanan.
+
+_Filesystem_ dari sebuah Container hanya hidup selama Container itu juga hidup. Saat Container berakhir dan dimulai ulang, perubahan pada _filesystem_ akan hilang. Untuk penyimpanan konsisten yang independen dari Container, kamu dapat menggunakan [Volume](/id/docs/concepts/storage/volumes/). Hal ini penting terutama untuk aplikasi _stateful_, seperti _key-value stores_ (contohnya Redis) dan database.
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+## Mengatur volume untuk Pod
+
+Pada latihan ini, kamu membuat sebuah Pod yang menjalankan sebuah Container. Pod ini memiliki sebuah Volume dengan tipe [emptyDir](/id/docs/concepts/storage/volumes/#emptydir)
+yang tetap bertahan, meski Container berakhir dan dimulai ulang. Berikut berkas konfigurasi untuk Pod:
+
+{{< codenew file="pods/storage/redis.yaml" >}}
+
+1. Membuat Pod:
+
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
+    ```
+
+2. Verifikasi apakah Container dari Pod berjalan sukses, lalu mengamati perubahan terhadap Pod:
+
+    ```shell
+    kubectl get pod redis --watch
+    ```
+    
+    Hasil keluaran seperti ini:
+
+    ```shell
+    NAME      READY     STATUS    RESTARTS   AGE
+    redis     1/1       Running   0          13s
+    ```
+
+1. Pada terminal lain, buka _shell_ untuk masuk ke Container yang sedang berjalan:
+
+    ```shell
+    kubectl exec -it redis -- /bin/bash
+    ```
+
+1. Di dalam _shell_, pergi ke `/data/redis`, kemudian buat sebuah berkas:
+
+    ```shell
+    root@redis:/data# cd /data/redis/
+    root@redis:/data/redis# echo Hello > test-file
+    ```
+
+1. Di dalam _shell_, munculkan daftar proses-proses yang sedang berjalan:
+
+    ```shell
+    root@redis:/data/redis# apt-get update
+    root@redis:/data/redis# apt-get install procps
+    root@redis:/data/redis# ps aux
+    ```
+
+    Keluarannya mirip seperti ini:
+
+    ```shell
+    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
+    redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
+    root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
+    root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
+    ```
+
+1. Di dalam _shell_, matikan proses Redis:
+
+    ```shell
+    root@redis:/data/redis# kill <pid>
+    ```
+
+    dengan `<pid>` adalah ID proses Redis (PID).
+
+2. Di dalam terminal awal, amati perubahan terhadap Pod Redis. Sampai akhirnya kamu akan melihat hal seperti ini:
+
+    ```shell
+    NAME      READY     STATUS     RESTARTS   AGE
+    redis     1/1       Running    0          13s
+    redis     0/1       Completed  0         6m
+    redis     1/1       Running    1         6m
+    ```
+
+Sampai di sini, Container telah berakhir dan dimuat ulang. Hal ini karena Pod Redis memiliki
+[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+dengan nilai `Always`.
+
+1. Gunakan _shell_ untuk masuk ke dalam Container yang telah dimuat ulang:
+
+    ```shell
+    kubectl exec -it redis -- /bin/bash
+    ```
+
+2. Di dalam _shell_, pergi ke `/data/redis`, dan verifikasi apakah `test-file` masih ada.
+    ```shell
+    root@redis:/data/redis# cd /data/redis/
+    root@redis:/data/redis# ls
+    test-file
+    ```
+
+3. Hapus Pod yang kamu buat untuk latihan ini:
+
+    ```shell
+    kubectl delete pod redis
+    ```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Lihat [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
+
+* Lihat [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
+
+* Selain penyimpanan pada disk lokal yang di sediakan oleh `emptyDir`, Kubernetes
+juga mendukung solusi penyimpanan _network-attached_, termasuk PD pada
+GCE dan EBS dari EC2, yang cenderung lebih disukai untuk data sangat penting dan akan menangani urusan detil seperti _mounting_ dan _unmounting_ perangkat pada Node. Lihat
+[Volume](/id/docs/concepts/storage/volumes/) untuk informasi detil.
+
+
+
+
diff --git a/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md
new file mode 100644
index 0000000000..96b7a05e07
--- /dev/null
+++ b/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md
@@ -0,0 +1,401 @@
+---
+content_type: concept
+title: Introspeksi dan _Debugging_ Aplikasi
+---
+
+<!-- overview -->
+
+Setelah aplikasi kamu berjalan, kamu pasti perlu untuk men-_debug_ masalah yang ada di dalamnya.
+Sebelumnya telah dijelaskan bagaimana kamu dapat menggunakan `kubectl get pods` untuk mengambil informasi status sederhana tentang
+Pod kamu. Namun ada sejumlah cara untuk mendapatkan lebih banyak informasi tentang aplikasi kamu.
+
+
+
+
+<!-- body -->
+
+## Menggunakan `kubectl describe pod` untuk mengambil detil informasi Pod
+
+Dalam contoh ini, kamu menggunakan Deployment untuk membuat dua buah Pod, yang hampir sama dengan contoh sebelumnya.
+
+{{< codenew file="application/nginx-with-request.yaml" >}}
+
+Buat Deployment dengan menjalankan perintah ini:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml
+```
+
+```none
+deployment.apps/nginx-deployment created
+```
+
+Cek status dari Pod dengan menggunakan perintah:
+
+```shell
+kubectl get pods
+```
+
+```none
+NAME                                READY     STATUS    RESTARTS   AGE
+nginx-deployment-1006230814-6winp   1/1       Running   0          11s
+nginx-deployment-1006230814-fmgu3   1/1       Running   0          11s
+```
+
+Kamu dapat memperoleh lebih banyak informasi tentang masing-masing Pod ini dengan menggunakan perintah `kubectl describe pod`. Sebagai contoh:
+
+```shell
+kubectl describe pod nginx-deployment-1006230814-6winp
+```
+
+```none
+Name:		nginx-deployment-1006230814-6winp
+Namespace:	default
+Node:		kubernetes-node-wul5/10.240.0.9
+Start Time:	Thu, 24 Mar 2016 01:39:49 +0000
+Labels:		app=nginx,pod-template-hash=1006230814
+Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1956810328","uid":"14e607e7-8ba1-11e7-b5cb-fa16" ...
+Status:		Running
+IP:		10.244.0.6
+Controllers:	ReplicaSet/nginx-deployment-1006230814
+Containers:
+  nginx:
+    Container ID:	docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149
+    Image:		nginx
+    Image ID:		docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707
+    Port:		80/TCP
+    QoS Tier:
+      cpu:	Guaranteed
+      memory:	Guaranteed
+    Limits:
+      cpu:	500m
+      memory:	128Mi
+    Requests:
+      memory:		128Mi
+      cpu:		500m
+    State:		Running
+      Started:		Thu, 24 Mar 2016 01:39:51 +0000
+    Ready:		True
+    Restart Count:	0
+    Environment:        <none>
+    Mounts:
+      /var/run/secrets/kubernetes.io/serviceaccount from default-token-5kdvl (ro)
+Conditions:
+  Type          Status
+  Initialized   True
+  Ready         True
+  PodScheduled  True
+Volumes:
+  default-token-4bcbi:
+    Type:	Secret (a volume populated by a Secret)
+    SecretName:	default-token-4bcbi
+    Optional:   false
+QoS Class:      Guaranteed
+Node-Selectors: <none>
+Tolerations:    <none>
+Events:
+  FirstSeen	LastSeen	Count	From					SubobjectPath		Type		Reason		Message
+  ---------	--------	-----	----					-------------		--------	------		-------
+  54s		54s		1	{default-scheduler }						Normal		Scheduled	Successfully assigned nginx-deployment-1006230814-6winp to kubernetes-node-wul5
+  54s		54s		1	{kubelet kubernetes-node-wul5}	spec.containers{nginx}	Normal		Pulling		pulling image "nginx"
+  53s		53s		1	{kubelet kubernetes-node-wul5}	spec.containers{nginx}	Normal		Pulled		Successfully pulled image "nginx"
+  53s		53s		1	{kubelet kubernetes-node-wul5}	spec.containers{nginx}	Normal		Created		Created container with docker id 90315cc9f513
+  53s		53s		1	{kubelet kubernetes-node-wul5}	spec.containers{nginx}	Normal		Started		Started container with docker id 90315cc9f513
+```
+
+Di sini kamu dapat melihat informasi konfigurasi tentang Container dan Pod (label, kebutuhan resource, dll.), serta informasi status tentang Container dan Pod (status, kesiapan, berapa kali _restart_, _event_, dll.) .
+
+Keadaan (_state_) Container merupakan salah satu dari keadaan _Waiting, Running,_ atau _Terminated_. Tergantung dari keadaannya, informasi tambahan akan diberikan - di sini kamu dapat melihat bahwa untuk Container dalam keadaan _running_, sistem memberi tahu kamu kapan Container tersebut mulai dijalankan.
+
+_Ready_ memberi tahu kepada kamu apakah Container berhasil melewati pemeriksaan kesiapan terakhir. (Dalam kasus ini, Container tidak memiliki pemeriksaan kesiapan yang dikonfigurasi; Container dianggap selalu siap jika tidak ada pemeriksaan kesiapan yang dikonfigurasi.)
+
+Jumlah _restart_ memberi tahu kamu berapa kali Container telah dimulai ulang; informasi ini dapat berguna untuk mendeteksi kemacetan tertutup (_crash loop_) dalam Container yang dikonfigurasi dengan nilai _restart policy_ 'always.'.
+
+Saat ini, satu-satunya kondisi yang terkait dengan Pod adalah kondisi _Binary Ready_, yang menunjukkan bahwa Pod tersebut dapat melayani permintaan dan harus ditambahkan ke kumpulan penyeimbang beban (_load balancing_) dari semua Service yang sesuai.
+
+Terakhir, kamu melihat catatan (_log_) peristiwa terbaru yang terkait dengan Pod kamu. Sistem mengompresi beberapa peristiwa yang identik dengan menunjukkan kapan pertama dan terakhir kali peristiwa itu dilihat dan berapa kali peristiwa itu dilihat. "From" menunjukkan komponen yang mencatat peristiwa, "SubobjectPath" memberi tahu kamu objek mana (mis. Container dalam pod) yang dimaksud, dan "Reason" dan "Message" memberi tahu kamu apa yang sudah terjadi.
+
+## Contoh: Men-_debug_ Pod yang _Pending_
+
+Skenario umum yang bisa kamu deteksi menggunakan peristiwa (_event_) adalah saat kamu telah membuat Pod yang tidak muat di Node mana pun. Misalnya, karena Pod mungkin meminta lebih banyak sumber daya yang tersedia dalam Node mana pun, atau mungkin Pod menentukan _label selector_ yang tidak sesuai dengan Node mana pun. Katakanlah kamu sebelumnya membuat Deployment dengan 5 replika (bukan 2) dan meminta 600 millicore, bukan 500, pada klaster dengan empat Node di mana setiap mesin (virtual) memiliki 1 CPU. Sehingga salah satu Pod tidak akan bisa dijadwalkan. (Perhatikan bahwa Pod _addon_ seperti fluentd, skydns, dll., yang berjalan di setiap Node pada klaster, tidak bisa dijadwalkan jika kamu meminta sebanyak 1000 millicore.)
+
+```shell
+kubectl get pods
+```
+
+```none
+NAME                                READY     STATUS    RESTARTS   AGE
+nginx-deployment-1006230814-6winp   1/1       Running   0          7m
+nginx-deployment-1006230814-fmgu3   1/1       Running   0          7m
+nginx-deployment-1370807587-6ekbw   1/1       Running   0          1m
+nginx-deployment-1370807587-fg172   0/1       Pending   0          1m
+nginx-deployment-1370807587-fz9sd   0/1       Pending   0          1m
+```
+
+Untuk mencari sebab kenapa Pod nginx-deployment-1370807587-fz9sd tidak berjalan, kamu dapat menggunakan `kubectl describe pod` pada Pod yang _pending_ dan melihat setiap peristiwa yang terjadi di dalamnya:
+
+```shell
+kubectl describe pod nginx-deployment-1370807587-fz9sd
+```
+
+```none
+  Name:		nginx-deployment-1370807587-fz9sd
+  Namespace:	default
+  Node:		/
+  Labels:		app=nginx,pod-template-hash=1370807587
+  Status:		Pending
+  IP:
+  Controllers:	ReplicaSet/nginx-deployment-1370807587
+  Containers:
+    nginx:
+      Image:	nginx
+      Port:	80/TCP
+      QoS Tier:
+        memory:	Guaranteed
+        cpu:	Guaranteed
+      Limits:
+        cpu:	1
+        memory:	128Mi
+      Requests:
+        cpu:	1
+        memory:	128Mi
+      Environment Variables:
+  Volumes:
+    default-token-4bcbi:
+      Type:	Secret (a volume populated by a Secret)
+      SecretName:	default-token-4bcbi
+  Events:
+    FirstSeen	LastSeen	Count	From			        SubobjectPath	Type		Reason			    Message
+    ---------	--------	-----	----			        -------------	--------	------			    -------
+    1m		    48s		    7	    {default-scheduler }			        Warning		FailedScheduling	pod (nginx-deployment-1370807587-fz9sd) failed to fit in any node
+  fit failure on node (kubernetes-node-6ta5): Node didn't have enough resource: CPU, requested: 1000, used: 1420, capacity: 2000
+  fit failure on node (kubernetes-node-wul5): Node didn't have enough resource: CPU, requested: 1000, used: 1100, capacity: 2000
+```
+
+Di sini kamu dapat melihat peristiwa yang dibuat oleh penjadwal yang mengatakan bahwa Pod gagal dijadwalkan karena alasan `FailedScheduling` (dan mungkin karena sebab yang lainnya). Pesan tersebut memberi tahu kamu bahwa tidak ada cukup sumber daya untuk Pod pada salah satu Node.
+
+Untuk memperbaiki situasi ini, kamu dapat menggunakan `kubectl scale` untuk memperbarui Deployment kamu untuk menentukan empat replika atau yang lebih kecil. (Atau kamu bisa membiarkan satu Pod tertunda, dimana hal ini tidak berbahaya.)
+
+Peristiwa seperti yang kamu lihat di bagian akhir keluaran dari perintah `kubectl description pod` akan tetap ada dalam etcd dan memberikan informasi tingkat tinggi tentang apa yang terjadi pada klaster. Untuk melihat daftar semua peristiwa kamu dapat menggunakan perintah
+
+```shell
+kubectl get events
+```
+
+tetapi kamu harus ingat bahwa peristiwa bersifat Namespace. Artinya, jika kamu tertarik dengan peristiwa untuk beberapa objek dalam Namespace (misalnya, apa yang terjadi dengan Pod pada Namespace `my-namespace`), kamu perlu secara eksplisit menyebutkan Namespace tersebut pada perintah:
+
+
+```shell
+kubectl get events --namespace=my-namespace
+```
+Untuk melihat peristiwa dari semua Namespace, kamu dapat menggunakan argumen `--all-namespaces`.
+
+Sebagai tambahan dari perintah `kubectl describe pod`, cara lain untuk mendapatkan informasi tambahan tentang sebuah Pod (selain yang disediakan oleh `kubectl get pod`) adalah dengan meneruskan _flag_ format keluaran `-o yaml` ke perintah `kubectl get pod`. Ini akan memberikan kamu lebih banyak informasi dalam format YAML daripada `kubectl describe pod`--semua informasi dasar yang dimiliki sistem tentang Pod. Di sini kamu akan melihat hal-hal seperti anotasi (yang merupakan metadata nilai kunci tanpa batasan label, yang digunakan secara internal oleh komponen sistem Kubernetes), kebijakan mulai ulang, porta, dan volume.
+
+```shell
+kubectl get pod nginx-deployment-1006230814-6winp -o yaml
+```
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  annotations:
+    kubernetes.io/created-by: |
+      {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1006230814","uid":"4c84c175-f161-11e5-9a78-42010af00005","apiVersion":"extensions","resourceVersion":"133434"}}
+  creationTimestamp: 2016-03-24T01:39:50Z
+  generateName: nginx-deployment-1006230814-
+  labels:
+    app: nginx
+    pod-template-hash: "1006230814"
+  name: nginx-deployment-1006230814-6winp
+  namespace: default
+  resourceVersion: "133447"
+  uid: 4c879808-f161-11e5-9a78-42010af00005
+spec:
+  containers:
+  - image: nginx
+    imagePullPolicy: Always
+    name: nginx
+    ports:
+    - containerPort: 80
+      protocol: TCP
+    resources:
+      limits:
+        cpu: 500m
+        memory: 128Mi
+      requests:
+        cpu: 500m
+        memory: 128Mi
+    terminationMessagePath: /dev/termination-log
+    volumeMounts:
+    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+      name: default-token-4bcbi
+      readOnly: true
+  dnsPolicy: ClusterFirst
+  nodeName: kubernetes-node-wul5
+  restartPolicy: Always
+  securityContext: {}
+  serviceAccount: default
+  serviceAccountName: default
+  terminationGracePeriodSeconds: 30
+  volumes:
+  - name: default-token-4bcbi
+    secret:
+      secretName: default-token-4bcbi
+status:
+  conditions:
+  - lastProbeTime: null
+    lastTransitionTime: 2016-03-24T01:39:51Z
+    status: "True"
+    type: Ready
+  containerStatuses:
+  - containerID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149
+    image: nginx
+    imageID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707
+    lastState: {}
+    name: nginx
+    ready: true
+    restartCount: 0
+    state:
+      running:
+        startedAt: 2016-03-24T01:39:51Z
+  hostIP: 10.240.0.9
+  phase: Running
+  podIP: 10.244.0.6
+  startTime: 2016-03-24T01:39:49Z
+```
+
+## Contoh: Men-_debug_ Node yang mati/tidak terjangkau (_down/unreachable_)
+
+Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan` kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
+
+```shell
+kubectl get nodes
+```
+
+```none
+NAME                     STATUS       ROLES     AGE     VERSION
+kubernetes-node-861h     NotReady     <none>    1h      v1.13.0
+kubernetes-node-bols     Ready        <none>    1h      v1.13.0
+kubernetes-node-st6x     Ready        <none>    1h      v1.13.0
+kubernetes-node-unaj     Ready        <none>    1h      v1.13.0
+```
+
+```shell
+kubectl describe node kubernetes-node-861h
+```
+
+```none
+Name:			kubernetes-node-861h
+Role
+Labels:		 kubernetes.io/arch=amd64
+           kubernetes.io/os=linux
+           kubernetes.io/hostname=kubernetes-node-861h
+Annotations:        node.alpha.kubernetes.io/ttl=0
+                    volumes.kubernetes.io/controller-managed-attach-detach=true
+Taints:             <none>
+CreationTimestamp:	Mon, 04 Sep 2017 17:13:23 +0800
+Phase:
+Conditions:
+  Type		Status		LastHeartbeatTime			LastTransitionTime			Reason					Message
+  ----    ------    -----------------     ------------------      ------          -------
+  OutOfDisk             Unknown         Fri, 08 Sep 2017 16:04:28 +0800         Fri, 08 Sep 2017 16:20:58 +0800         NodeStatusUnknown       Kubelet stopped posting node status.
+  MemoryPressure        Unknown         Fri, 08 Sep 2017 16:04:28 +0800         Fri, 08 Sep 2017 16:20:58 +0800         NodeStatusUnknown       Kubelet stopped posting node status.
+  DiskPressure          Unknown         Fri, 08 Sep 2017 16:04:28 +0800         Fri, 08 Sep 2017 16:20:58 +0800         NodeStatusUnknown       Kubelet stopped posting node status.
+  Ready                 Unknown         Fri, 08 Sep 2017 16:04:28 +0800         Fri, 08 Sep 2017 16:20:58 +0800         NodeStatusUnknown       Kubelet stopped posting node status.
+Addresses:	10.240.115.55,104.197.0.26
+Capacity:
+ cpu:           2
+ hugePages:     0
+ memory:        4046788Ki
+ pods:          110
+Allocatable:
+ cpu:           1500m
+ hugePages:     0
+ memory:        1479263Ki
+ pods:          110
+System Info:
+ Machine ID:                    8e025a21a4254e11b028584d9d8b12c4
+ System UUID:                   349075D1-D169-4F25-9F2A-E886850C47E3
+ Boot ID:                       5cd18b37-c5bd-4658-94e0-e436d3f110e0
+ Kernel Version:                4.4.0-31-generic
+ OS Image:                      Debian GNU/Linux 8 (jessie)
+ Operating System:              linux
+ Architecture:                  amd64
+ Container Runtime Version:     docker://1.12.5
+ Kubelet Version:               v1.6.9+a3d1dfa6f4335
+ Kube-Proxy Version:            v1.6.9+a3d1dfa6f4335
+ExternalID:                     15233045891481496305
+Non-terminated Pods:            (9 in total)
+  Namespace                     Name                                            CPU Requests    CPU Limits      Memory Requests Memory Limits
+  ---------                     ----                                            ------------    ----------      --------------- -------------
+......
+Allocated resources:
+  (Total limits may be over 100 percent, i.e., overcommitted.)
+  CPU Requests  CPU Limits      Memory Requests         Memory Limits
+  ------------  ----------      ---------------         -------------
+  900m (60%)    2200m (146%)    1009286400 (66%)        5681286400 (375%)
+Events:         <none>
+```
+
+```shell
+kubectl get node kubernetes-node-861h -o yaml
+```
+
+```yaml
+apiVersion: v1
+kind: Node
+metadata:
+  creationTimestamp: 2015-07-10T21:32:29Z
+  labels:
+    kubernetes.io/hostname: kubernetes-node-861h
+  name: kubernetes-node-861h
+  resourceVersion: "757"
+  uid: 2a69374e-274b-11e5-a234-42010af0d969
+spec:
+  externalID: "15233045891481496305"
+  podCIDR: 10.244.0.0/24
+  providerID: gce://striped-torus-760/us-central1-b/kubernetes-node-861h
+status:
+  addresses:
+  - address: 10.240.115.55
+    type: InternalIP
+  - address: 104.197.0.26
+    type: ExternalIP
+  capacity:
+    cpu: "1"
+    memory: 3800808Ki
+    pods: "100"
+  conditions:
+  - lastHeartbeatTime: 2015-07-10T21:34:32Z
+    lastTransitionTime: 2015-07-10T21:35:15Z
+    reason: Kubelet stopped posting node status.
+    status: Unknown
+    type: Ready
+  nodeInfo:
+    bootID: 4e316776-b40d-4f78-a4ea-ab0d73390897
+    containerRuntimeVersion: docker://Unknown
+    kernelVersion: 3.16.0-0.bpo.4-amd64
+    kubeProxyVersion: v0.21.1-185-gffc5a86098dc01
+    kubeletVersion: v0.21.1-185-gffc5a86098dc01
+    machineID: ""
+    osImage: Debian GNU/Linux 7 (wheezy)
+    systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+Pelajari tentang alat _debugging_ tambahan, termasuk:
+
+* [Pencatatan (_logging_)](/id/docs/concepts/cluster-administration/logging/)
+* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+* [Masuk ke Container melalui `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/)
+* [Masuk ke Container melalui _proxy_](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
+* [Masuk ke Container melalui _port forwarding_](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
+* [Inspeksi Node Kubernetes dengan menggunakan crictl](/docs/tasks/debug-application-cluster/crictl/)
+
+
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/tasks/manage-kubernetes-objects/declarative-config.md
similarity index 95%
rename from content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
rename to content/id/docs/tasks/manage-kubernetes-objects/declarative-config.md
index 46066769d4..88eeaf38d3 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md
+++ b/content/id/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -1,7 +1,7 @@
 ---
-title: Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi
+title: Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan Berkas Konfigurasi
 content_type: concept
-weight: 40
+weight: 10
 ---
 
 <!-- overview -->
@@ -18,20 +18,20 @@ Perintah `kubectl` memungkinkan tiga cara untuk mengelola objek:
 * Konfigurasi objek imperatif
 * Konfigurasi objek deklaratif
 
-Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-kubectl/overview/) untuk menyimak diskusi mengenai kelebihan dan kekurangan dari tiap cara pengelolaan objek.
+Lihat [Pengelolaan Objek Kubernetes](/id/docs/concepts/overview/working-with-objects/object-management/) untuk menyimak diskusi mengenai kelebihan dan kekurangan dari tiap cara pengelolaan objek.
 
 ## Sebelum kamu mulai
 
 Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik
 tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut:
 
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [Pengelolaan Objek Kubernetes Menggunakan Berkas Konfigurasi Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
 
 Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan
 dalam dokumen ini:
 
-- *objek file konfigurasi / file konfigurasi*: Sebuah *file* yang
+- *objek berkas konfigurasi / berkas konfigurasi*: Sebuah *file* yang
 mendefinisikan konfigurasi untuk sebuah objek Kubernetes. Dokumen ini akan memperlihatkan cara menggunakan *file* konfigurasi dengan perintah `kubectl apply`. *File-file* konfigurasi biasanya disimpan di sebuah *source control* seperti Git.
 - *konfigurasi objek live / konfigurasi live*: nilai konfigurasi *live* dari sebuah objek, sebagaimana yang tersimpan di klaster Kubernetes. Nilai-nilai ini disimpan di *storage* klaster Kubernetes, biasanya etcd.
 - *writer konfigurasi deklaratif / writer deklaratif*: Seseorang atau sebuah komponen perangkat lunak yang membuat pembaruan ke objek *live*. *Live writer* yang disebut pada dokumen ini adalah *writer* yang membuat perubahan terhadap *file* konfigurasi objek dan menjalankan perintah `kubectl apply` untuk menulis perubahan-perubahan tersebut.
@@ -340,7 +340,7 @@ Perintah `kubectl apply --prune` masih dalam versi alpha dan perubahan-perubahan
 Kamu harus berhati-hati ketika menggunakan perintah ini agar kamu tidak menghapus objek-objek lain secara tak sengaja.
 {{< /warning >}}
 
-Sebagai alternatif dari `kubectl delete`, kamu bisa menggunakan `kubectl apply` untuk mengidentifikasi objek-objek yang hendak dihapus setelah file konfigurasi objek-objek tersebut dihapus dari direktori. Ketika dijalankan dengan argumen `--prune`, perintah `kubectl apply` akan melakukan *query* ke *API server* untuk mencari semua objek yang sesuai dengan himpunan label-label tertentu, dan berusaha untuk mencocokkan kofigurasi objek *live* yg diperoleh terhadap *file* konfigurasi objek. Jika sebuah objek cocok dengan *query* yang dilakukan, dan objek tersebut tidak memiliki *file* konfigurasi di direktori serta tidak memiliki anotasi `last-applied-configuration`, objek tersebut akan dihapus.
+Sebagai alternatif dari `kubectl delete`, kamu bisa menggunakan `kubectl apply` untuk mengidentifikasi objek-objek yang hendak dihapus setelah berkas konfigurasi objek-objek tersebut dihapus dari direktori. Ketika dijalankan dengan argumen `--prune`, perintah `kubectl apply` akan melakukan *query* ke *API server* untuk mencari semua objek yang sesuai dengan himpunan label-label tertentu, dan berusaha untuk mencocokkan kofigurasi objek *live* yg diperoleh terhadap *file* konfigurasi objek. Jika sebuah objek cocok dengan *query* yang dilakukan, dan objek tersebut tidak memiliki *file* konfigurasi di direktori serta tidak memiliki anotasi `last-applied-configuration`, objek tersebut akan dihapus.
 
 {{< comment >}}
 TODO(pwittrock): Kita perlu mengubah cara kerja perintah ini untuk mencegah pengguna menjalankan apply ke sub direktori secara tidak disengaja.
@@ -372,7 +372,7 @@ Ketika memperbarui konfigurasi *live* dari sebuah objek, `kubectl apply` melakuk
 
 ### Perhitungan penggabungan *patch*
 
-Perintah `kubectl apply` menulis konten dari file konfigurasi ke anotasi `kubectl.kubernetes.io/last-applied-configuration`. Ini digunakan untuk mengidentifikasi *field* apa saja yang telah dihapus dari *file* konfigurasi dan perlu dihapus dari konfigurasi *live*. Berikut adalah langkah-langkah yang digunakan untuk menghitung *field* apa saja yang harus dihapus atau diubah:
+Perintah `kubectl apply` menulis konten dari berkas konfigurasi ke anotasi `kubectl.kubernetes.io/last-applied-configuration`. Ini digunakan untuk mengidentifikasi *field* apa saja yang telah dihapus dari *file* konfigurasi dan perlu dihapus dari konfigurasi *live*. Berikut adalah langkah-langkah yang digunakan untuk menghitung *field* apa saja yang harus dihapus atau diubah:
 
 1. Hitung *field-field* yang perlu dihapus. Ini mencakup *field-field* yang ada di `last-applied-configuration` tapi tidak ada di *file* konfigurasi.
 2. Hitung *field-field* yang perlu ditambah atau diubah. Ini mencakup *field-field* yang ada di *file* konfigurasi yang nilainya tidak sama dengan konfigurasi *live*.
@@ -533,7 +533,7 @@ Perlakukan *list* sama dengan *field* primitif. Ganti atau hapus keseluruhan lis
 # nilai last-applied-configuration*
     args: ["a", "b"]
 
-# nilai file konfigurasi
+# nilai berkas konfigurasi
     args: ["a", "c"]
 
 # nilai konfigurasi live
@@ -563,7 +563,7 @@ Strategi penggabungan ini menggunakan *tag* khusus `patchMergeKey` pada tiap *fi
     - name: nginx-helper-b # key: nginx-helper-b; akan dipertahankan pada hasil akhir
       image: helper:1.3
 
-# nilai file konfigurasi
+# nilai berkas konfigurasi
     containers:
     - name: nginx
       image: nginx:1.10
@@ -625,7 +625,7 @@ TODO(pwittrock): *Uncomment* ini untuk versi 1.6
 
 *API server* mengisi *field* tertentu dengan nilai *default* pada konfigurasi *live* jika nilai *field-field* tersebut tidak dispesifikasikan ketika objek dibuat.
 
-Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. File berikut tidak menspesifikasikan `strategy`:
+Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. Berkas berikut tidak menspesifikasikan `strategy`:
 
 {{< codenew file="application/simple_deployment.yaml" >}}
 
@@ -700,7 +700,7 @@ spec:
         ports:
         - containerPort: 80
 
-# file konfigurasi
+# berkas konfigurasi
 spec:
   strategy:
     type: Recreate # nilai yang diperbarui
@@ -862,8 +862,8 @@ template:
 
 ## {{% heading "whatsnext" %}}
 
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
-- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan Berkas Konfigurasi](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/tasks/manage-kubernetes-objects/imperative-command.md
similarity index 94%
rename from content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
rename to content/id/docs/tasks/manage-kubernetes-objects/imperative-command.md
index 23489efb59..2cfa48c431 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md
+++ b/content/id/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -1,7 +1,7 @@
 ---
 title: Pengelolaan Objek Kubernetes dengan Perintah Imperatif
 content_type: concept
-weight: 20
+weight: 30
 ---
 
 <!-- overview -->
@@ -18,7 +18,7 @@ Perintah `kubectl` mendukung tiga cara pengelolaan objek:
 * Konfigurasi objek imperatif
 * Konfigurasi objek deklaratif
 
-Lihat [Pengelolaan Objek Kubernetes](/id/docs/concepts/overview/object-management-kubectl/overview/) untuk mengenali lebih lanjut kelebihan dan kekurangan dari tiap pengelolaan objek.
+Lihat [Pengelolaan Objek Kubernetes](/id/docs/concepts/overview/working-with-objects/object-management/) untuk mengenali lebih lanjut kelebihan dan kekurangan dari tiap pengelolaan objek.
 
 ## Cara membuat objek
 
@@ -120,14 +120,14 @@ kubectl create --edit -f /tmp/srv.yaml
 ```
 
 1. Perintah `kubectl create service` membuat konfigurasi untuk objek Service dan menyimpannya di `/tmp/srv.yaml`.
-1. Perintah `kubectl create --edit` membuka file konfigurasi untuk diedit sebelum objek dibuat.
+1. Perintah `kubectl create --edit` membuka berkas konfigurasi untuk disunting sebelum objek dibuat.
 
 
 
 ## {{% heading "whatsnext" %}}
 
-- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
-- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
+- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan Konfigurasi Objek](/id//docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/tasks/manage-kubernetes-objects/imperative-config.md
similarity index 91%
rename from content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
rename to content/id/docs/tasks/manage-kubernetes-objects/imperative-config.md
index 94f1082e35..e9f0cfe639 100644
--- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md
+++ b/content/id/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -1,7 +1,7 @@
 ---
-title: Penglolaan Objek Kubernetes Secara Imperatif dengan Menggunakan File Konfigurasi
+title: Pengelolaan Objek Kubernetes Secara Imperatif dengan Menggunakan File Konfigurasi
 content_type: concept
-weight: 30
+weight: 40
 ---
 
 <!-- overview -->
@@ -18,7 +18,7 @@ Perintah `kubectl` mendukung tiga cara pengelolaan objek:
 * Konfigurasi objek imperatif
 * Konfigurasi objek deklaratif
 
-Lihat [Pengelolaan Objek Kubernetes](/id/docs/concepts/overview/object-management-kubectl/overview/) untuk mengenali lebih lanjut kelebihan dan kekurangan dari tiap cara pengelolaan objek.
+Lihat [Pengelolaan Objek Kubernetes](/id/docs/tasks/manage-kubernetes-objects/) untuk mengenali lebih lanjut kelebihan dan kekurangan dari tiap cara pengelolaan objek.
 
 ## Cara membuat objek
 
@@ -108,9 +108,9 @@ template:
 
 ## {{% heading "whatsnext" %}}
 
-- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/)
-- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/)
+- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
 
diff --git a/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md
index 680b20d371..2ca6535d90 100644
--- a/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md
+++ b/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -835,7 +835,7 @@ deployment.apps "dev-my-nginx" deleted
 
 * [Kustomize](https://github.com/kubernetes-sigs/kustomize)
 * [Buku Kubectl](https://kubectl.docs.kubernetes.io)
-* [Rujukan Perintah Kubectl](/id/docs/reference/generated/kubectl/kubectl/)
-* [Rujukan API Kubernetes](/id/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+* [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
 
diff --git a/content/id/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/id/docs/tasks/run-application/force-delete-stateful-set-pod.md
new file mode 100644
index 0000000000..a6ca6687c3
--- /dev/null
+++ b/content/id/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -0,0 +1,81 @@
+---
+reviewers:
+title: Menghapus Paksa Pod StatefulSet
+content_type: task
+weight: 70
+---
+
+<!-- overview -->
+Laman ini menjelaskan bagaimana cara menghapus Pod yang menjadi bagian dari sebuah {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, dan menjelaskan pertimbangan yang harus diperhatikan saat melakukannya.
+
+
+## {{% heading "prerequisites" %}}
+
+
+* Ini merupakan tugas yang cukup rumit dan memiliki potensi melanggar beberapa properti yang melekat dari StatefulSet.
+* Sebelum melanjutkan, pastikan kamu paham dengan pertimbangan yang disebutkan di bawah ini.
+
+
+
+<!-- steps -->
+
+## Pertimbangan StatefulSet
+
+Pada operasi normal dari StatefulSet, **tidak pernah** ada kebutuhan untuk menghapus paksa sebuah Pod StatefulSet. [_Controller_ StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) bertanggung jawab terhadap pembuatan, penyekalaan dan penghapusan terhadap anggota dari StatefulSet. _Controller_ akan berusaha menjaga agar jumlah Pod yang ditentukan dari 0 hingga N-1 hidup dan siap sedia. StatefulSet memastikan bahwa, pada waktu kapanpun, akan ada minimal satu Pod dengan identitas yang telah ditetapkan berjalan pada klaster. Hal ini direferensikan sebagai semantik *at most one* yang disediakan StatefulSet.
+
+Penghapusan paksa secara manual harus dilakukan dengan hati-hati, karena hal tersebut berpotensi melanggar semantik _at most one_ yang melekat pada StatefulSet. StatefulSet dapat digunakan untuk menjalankan aplikasi terklaster dan terdistribusi yang membutuhkan identitas jaringan dan penyimpanan yang stabil dan tetap. Aplikasi-aplikasi ini biasanya memiliki konfigurasi yang tergantung dengan sejumlah anggota dengan identitas yang tetap. Memiliki banyak anggota dengan identitas yang sama berpotensi menimbulkan kerusakan dan kehilangan data (contohnya skenario  _split brain_ pada sistem berbasis kuorum).
+
+## Menghapus Pod
+
+Kamu dapat melakukan penghapusan Pod secara _graceful_ dengan perintah berikut:
+
+```shell
+kubectl delete pods <pod>
+```
+
+Agar perintah di atas mengarah ke terminasi secara _graceful_, Pod **tidak boleh** menspesifikasikan `pod.Spec.TerminationGracePeriodSeconds` dengan nilai 0. Praktik untuk mengatur nilai `pod.Spec.TerminationGracePeriodSeconds` menjadi 0 detik merupakan hal yang tidak aman dan sangat tidak disarankan untuk Pod StatefulSet. Penghapusan secara _graceful_  itu aman dan akan memastikan bahwa Pod [akan mati secara _gracefully_](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) sebelum kubelet menghapus nama dari apiserver.
+
+Kubernetes (versi 1.5 atau lebih baru) tidak akan menghapus Pod hanya karena Node tidak dapat dijangkau. Pod yang berjalan pada Node yang tidak dapat dijangkau akan memasuki keadaan 'Terminating' atau 'Unknown' setelah [waktu habis](/id/docs/admin/node/#node-condition). Pod juga dapat memasuki keadaan ini saat pengguna berusaha melakukan penghapusan secara _graceful_ terhadap Pod pada Node yang tidak dapat dijangkau. Cara yang hanya dapat dilakukan untuk menghapus Pod pada keadaan tersebut dari apiserver adalah:
+
+   * Objek Node telah dihapus (baik oleh kamu, atau oleh [_Controller_ Node](/id/docs/admin/node)).<br/>
+   * Kubelet pada Node yang tidak responsif akan menanggapi, lalu mematikan Pod dan menghapusnya dari apiserver.<br/>
+   * Penghapusan paksa Pod oleh pengguna.
+
+Praktik terbaik yang direkomendasikan adalah menggunakan pendekatan pertama atau kedua. Jika sebuah Node telah terkonfirmasi mati (contohnya terputus dari jaringan secara permanen, dimatikan, dll), maka objek Node dihapus. Jika Node mengalami partisi jaringan, maka coba selesaikan masalah ini atau menunggu masalah itu terselesaikan. Saat partisi terselesaikan, kubelet akan menyelesaikan penghapusan Pod serta membebaskan namanya dari apiserver.
+
+Normalnya, sistem akan menyelesaikan penghapusan saat Pod tidak lagi berjalan pada Node, atau Node telah dihapus oleh administrator. Kamu dapat mengabaikan hal ini dengan menghapus paksa Pod.
+
+### Penghapusan Paksa
+
+Penghapusan paksa **tidak** menunggu konfirmasi dari kubelet bahwa Pod telah diterminasi. Terlepas dari apakah penghapusan paksa sukses mematikan sebuah Pod, namanya akan segera dibebaskan dari apiserver. Hal ini berakibat _controller_ StatefulSet akan membuat Pod pengganti dengan identitas yang sama; ini dapat menimbulkan duplikasi terhadap Pod apabila ternyata Pod tersebut masih berjalan, dan jika Pod tersebut masih dapat berkomunikasi dengan anggota Statefulset lainnya, hal ini berakibat terjadi pelanggaran semantik _at most one_ dari StatefulSet yang telah dijamin.
+
+Saat kamu menghapus paksa sebuah Pod StatefulSet, berarti kamu menjamin bahwa Pod tersebut tidak akan pernah lagi berkomunikasi dengan Pod lain pada StatefulSet dan namanya dapat dibebaskan secara aman untuk pembuatan penggantinya.
+
+Jika kamu ingin menghapus paksa Pod dengan menggunakan kubectl versi >= 1.5, lakukan perintah berikut:
+
+```shell
+kubectl delete pods <pod> --grace-period=0 --force
+```
+
+Jika kamu menggunakan kubectl <= 1.4, kamu harus menghilangkan pilihan `--force` dan gunakan:
+
+```shell
+kubectl delete pods <pod> --grace-period=0
+```
+
+Jika setelah perintah ini dijalankan dan Pod tetap berada pada kondisi `Unknown`, gunakan perintah berikut untuk menghapus Pod dari klaster:
+
+```shell
+kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
+```
+
+Selalu jalankan penghapusan paksa Pod StatefulSet dengan hati-hati dan penuh pemahaman terhadap risiko yang dapat timbul.
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+Pelajari lebih lanjut [_debugging_ StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
+
+
diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
new file mode 100644
index 0000000000..da873c4373
--- /dev/null
+++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -0,0 +1,448 @@
+---
+title: Panduan HorizontalPodAutoscaler
+content_type: task
+weight: 100
+---
+
+<!-- overview -->
+
+HorizontalPodAutoscaler secara otomatis akan memperbanyak jumlah Pod di dalam ReplicationController, Deployment, 
+ReplicaSet ataupun StatefulSet berdasarkan hasil observasi penggunaan CPU (atau, dengan 
+[metrik khusus](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), pada beberapa aplikasi yang menyediakan metrik).
+
+Laman ini memandu kamu dengan contoh pengaktifan HorizontalPodAutoscaler untuk server php-apache.  Untuk informasi lebih lanjut tentang perilaku HorizontalPodAutoscaler, lihat [Petunjuk pengguna HorizontalPodAutoscaler](/id/docs/tasks/run-application/horizontal-pod-autoscaler/).
+
+
+
+
+## {{% heading "prasyarat" %}}
+
+
+Contoh dibawah ini membutuhkan klaster Kubernetes dan kubectl di versi 1.2 atau yang lebih baru yang sedang berjalan. 
+[Server metrik](https://github.com/kubernetes-incubator/metrics-server/) sebagai pemantauan perlu diluncurkan di dalam sebuah klaster 
+untuk menyediakan metrik melalui metrik API sumber daya, karena HorizontalPodAutoscaler menggunakan API ini untuk mengumpulkan metrik. Petunjuk untuk menerapkan server metrik ada di repositori GitHub dari [server metrik](https://github.com/kubernetes-incubator/metrics-server/), jika kamu mengikuti petunjuk [memulai panduan GCE](/docs/setup/production-environment/turnkey/gce/),
+metrik-pemantauan server akan diaktifkan secara default
+
+Untuk menentukan beberapa metrik sumber daya untuk HorizontalPodAutoscaler, kamu harus memiliki klaster Kubernetes
+dan kubectl di versi 1.6 atau yang lebih baru. Selanjutnya, untuk menggunakan metrik khusus, klaster kamu
+harus dapat berkomunikasi dengan server API yang menyediakan API metrik khusus. Terakhir, untuk menggunakan metrik yang tidak terkait dengan objek Kubernetes apa pun, kamu harus memiliki klaster Kubernetes pada versi 1.10 atau yang lebih baru, dan kamu harus dapat berkomunikasi dengan server API yang menyediakan API metrik eksternal.
+Lihat [Panduan pengguna HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) untuk detail lebih lanjut.
+
+
+<!-- langkah - langkah -->
+
+## Menjalankan & mengekspos server php-apache
+
+Untuk mendemonstrasikan HorizontalPodAutoscaler kita akan menggunakan _image_ Docker khusus berdasarkan _image_ php-apache.
+Dockerfile memiliki konten berikut:
+
+```
+FROM php:5-apache
+ADD index.php /var/www/html/index.php
+RUN chmod a+rx index.php
+```
+
+Bagian ini mendefinisikan laman index.php yang melakukan beberapa komputasi intensif CPU:
+
+```
+<?php
+  $x = 0.0001;
+  for ($i = 0; $i <= 1000000; $i++) {
+    $x += sqrt($x);
+  }
+  echo "OK!";
+?>
+```
+
+Pertama, kita akan memulai Deployment yang menjalankan _image_ dan mengeksposnya sebagai Service
+menggunakan konfigurasi berikut:
+
+{{< codenew file="application/php-apache.yaml" >}}
+
+
+Jalankan perintah berikut:
+```shell
+kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
+```
+```
+deployment.apps/php-apache created
+service/php-apache created
+```
+
+## Membuat HorizontalPodAutoscaler
+
+Sekarang server sudah berjalan, selanjutnya kita akan membuat _autoscaler_ menggunakan
+[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale).
+Perintah berikut akan membuat HorizontalPodAutoscaler yang mengelola antara 1 dan 10 replika Pod yang dikontrol oleh Deployment php-apache yang kita buat pada langkah pertama instruksi ini.
+Secara kasar, HPA akan menambah dan mengurangi jumlah replika
+(melalui Deployment) untuk mempertahankan pemakaian CPU rata-rata di semua Pod sebesar 50%
+(karena setiap Pod meminta 200 mili-core menurut `kubectl run`), ini berarti penggunaan CPU rata-rata adalah 100 mili-core).
+Lihat [ini](/id/docs/tasks/run-application/horizontal-pod-autoscaler/#detail-algoritma) untuk detail lebih lanjut tentang algoritmanya.
+
+```shell
+kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
+```
+```
+horizontalpodautoscaler.autoscaling/php-apache autoscaled
+```
+
+Kita dapat memeriksa status _autoscaler_ saat ini dengan menjalankan:
+
+```shell
+kubectl get hpa
+```
+```
+NAME         REFERENCE                     TARGET    MINPODS   MAXPODS   REPLICAS   AGE
+php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1          18s
+
+```
+
+Harap dicatat bahwa konsumsi CPU saat ini adalah 0% karena kita tidak mengirimkan permintaan apa pun ke server
+(kolom ``TARGET`` menunjukkan nilai rata-rata di semua Pod yang dikontrol oleh Deployment yang sesuai).
+
+## Menambahkan beban
+
+Sekarang, kita akan melihat bagaimana _autoscaler_ bereaksi terhadap peningkatan beban.
+Kita akan memulai sebuah Container, dan mengirimkan perulangan kueri tak terbatas ke Service php-apache (jalankan di terminal yang berbeda):
+
+```shell
+kubectl run -it --rm load-generator --image=busybox /bin/sh
+
+Hit enter for command prompt
+
+while true; do wget -q -O- http://php-apache; done
+```
+
+Dalam satu menit atau lebih, kita akan melihat beban CPU yang lebih tinggi dengan menjalankan:
+
+```shell
+kubectl get hpa
+```
+```
+NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
+php-apache   Deployment/php-apache/scale   305% / 50%  1         10        1          3m
+
+```
+
+Di sini, konsumsi CPU meningkat hingga 305% dari permintaan.
+Hasilnya, Deployment mengubah ukurannya menjadi 7 replika:
+
+```shell
+kubectl get deployment php-apache
+```
+```
+NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+php-apache   7/7      7           7           19m
+```
+
+{{< note >}}
+Mungkin perlu beberapa menit untuk menstabilkan jumlah replika. Karena jumlah 
+bebannya tidak dikendalikan dengan cara apa pun, yang mungkin terjadi adalah jumlah replika akhir
+akan berbeda dari contoh.
+{{< /note >}}
+
+## Menghentikan beban
+
+Kita akan menyudahi contoh dengan menghentikan beban pengguna.
+
+Di terminal tempat kita membuat Container dengan _image_ `busybox`, hentikan
+pembangkitan beban dengan mengetik `<Ctrl> + C`.
+
+Kemudian kita akan memverifikasi status hasil (setelah satu menit atau lebih):
+
+```shell
+kubectl get hpa
+```
+```
+NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
+php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m
+```
+
+```shell
+kubectl get deployment php-apache
+```
+```
+NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+php-apache   1/1     1            1           27m
+```
+
+Di sini penggunaan CPU turun menjadi 0, sehingga HPA secara otomatis melakukan penyekalaan jumlah replika kembali menjadi 1.
+
+{{< note >}}
+Penyekalaan otomatis replika mungkin memerlukan waktu beberapa menit.
+{{< /note >}}
+
+
+
+<!-- diskusi -->
+
+## Penyekalaan otomatis pada metrik multipel dan metrik kustom
+
+Kamu dapat memperkenalkan metrik tambahan untuk digunakan saat melakukan penyekalaan otomatis pada Deployment `php-apache` dengan menggunakan versi API `autoscaling / v2beta2`.
+
+Pertama, dapatkan YAML HorizontalPodAutoscaler kamu dalam bentuk `autoscaling / v2beta2`:
+
+```shell
+kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
+```
+
+Buka berkas `/tmp/hpa-v2.yaml` di editor, dan kamu akan melihat YAML yang terlihat seperti ini:
+
+```yaml
+apiVersion: autoscaling/v2beta2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: php-apache
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: php-apache
+  minReplicas: 1
+  maxReplicas: 10
+  metrics:
+  - type: Resource
+    resource:
+      name: cpu
+      target:
+        type: Utilization
+        averageUtilization: 50
+status:
+  observedGeneration: 1
+  lastScaleTime: <some-time>
+  currentReplicas: 1
+  desiredReplicas: 1
+  currentMetrics:
+  - type: Resource
+    resource:
+      name: cpu
+      current:
+        averageUtilization: 0
+        averageValue: 0
+```
+
+Perhatikan bahwa kolom `targetCPUUtilizationPercentage` telah diganti dengan himpunan yang disebut `metrics`.
+Metrik penggunaan CPU adalah *resource metric*, merepresentasikan sebagai persentase sumber daya
+ditentukan pada Container Pod. Perhatikan bahwa kamu dapat menentukan metrik sumber daya selain CPU. Secara bawaan,
+satu-satunya metrik sumber daya lain yang didukung adalah memori. Sumber daya ini tidak mengubah nama dari klaster
+ke klaster, dan harus selalu tersedia, selama API `metrics.k8s.io` tersedia.
+
+Kamu juga dapat menentukan metrik sumber daya dalam nilai secara langsung, bukan sebagai persentase dari
+nilai yang diminta, dengan menggunakan `target.type` dari `AverageValue` sebagai ganti `Utilization`, dan
+menyetel _field_ `target.averageValue` yang sesuai, bukan `target.averageUtilization`.
+
+Ada dua jenis metrik lainnya, keduanya dianggap sebagai *metrik khusus*: metrik Pod dan
+metrik objek. Metrik ini memungkinkan untuk memiliki nama yang spesifik untuk klaster, dan membutuhkan lebih banyak
+pengaturan pemantauan klaster lanjutan.
+
+Jenis metrik alternatif yang pertama adalah *metrik Pod*. Metrik ini mendeskripsikan Pod, dan
+dirata-ratakan bersama di seluruh Pod dan dibandingkan dengan nilai target untuk menentukan jumlah replika.
+Mereka bekerja seperti metrik sumber daya, kecuali bahwa mereka *hanya* mendukung jenis `target` dari `AverageValue`.
+
+Metrik Pod ditentukan menggunakan blok metrik seperti ini:
+
+```yaml
+type: Pods
+pods:
+  metric:
+    name: packets-per-second
+  target:
+    type: AverageValue
+    averageValue: 1k
+```
+
+Jenis metrik alternatif kedua adalah *metrik objek*. Metrik ini mendeskripsikan perbedaan
+objek di Namespace yang sama, bukan mendeskripsikan Pod. Metriknya belum tentu
+diambil dari objek; mereka hanya mendeskripsikannya. Metrik objek mendukung jenis `target`
+baik `Value` dan `AverageValue`. Dengan `Value`, target dibandingkan langsung dengan yang dikembalikan
+metrik dari API. Dengan `AverageValue`, nilai yang dikembalikan dari API metrik khusus dibagi
+dengan jumlah Pod sebelum dibandingkan dengan target. Contoh berikut adalah YAML
+representasi dari metrik `requests-per-second`.
+
+```yaml
+type: Object
+object:
+  metric:
+    name: requests-per-second
+  describedObject:
+    apiVersion: networking.k8s.io/v1beta1
+    kind: Ingress
+    name: main-route
+  target:
+    type: Value
+    value: 2k
+```
+
+Jika kamu memberikan beberapa blok metrik seperti itu, HorizontalPodAutoscaler akan mempertimbangkan setiap metrik secara bergantian.
+HorizontalPodAutoscaler akan menghitung jumlah replika yang diusulkan untuk setiap metrik, lalu memilih
+satu dengan jumlah replika tertinggi.
+
+Misalnya, jika sistem pemantauan kamu mengumpulkan metrik tentang lalu lintas jaringan,
+kamu dapat memperbarui definisi di atas menggunakan `kubectl edit` agar terlihat seperti ini:
+
+```yaml
+apiVersion: autoscaling/v2beta2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: php-apache
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: php-apache
+  minReplicas: 1
+  maxReplicas: 10
+  metrics:
+  - type: Resource
+    resource:
+      name: cpu
+      target:
+        type: Utilization
+        averageUtilization: 50
+  - type: Pods
+    pods:
+      metric:
+        name: packets-per-second
+      target:
+        type: AverageValue
+        averageValue: 1k
+  - type: Object
+    object:
+      metric:
+        name: requests-per-second
+      describedObject:
+        apiVersion: networking.k8s.io/v1beta1
+        kind: Ingress
+        name: main-route
+      target:
+        type: Value
+        value: 10k
+status:
+  observedGeneration: 1
+  lastScaleTime: <some-time>
+  currentReplicas: 1
+  desiredReplicas: 1
+  currentMetrics:
+  - type: Resource
+    resource:
+      name: cpu
+    current:
+      averageUtilization: 0
+      averageValue: 0
+  - type: Object
+    object:
+      metric:
+        name: requests-per-second
+      describedObject:
+        apiVersion: networking.k8s.io/v1beta1
+        kind: Ingress
+        name: main-route
+      current:
+        value: 10k
+```
+
+Kemudian, HorizontalPodAutoscaler kamu akan mencoba memastikan bahwa setiap Pod mengonsumsi kira-kira
+50% dari CPU yang diminta, melayani 1000 paket per detik, dan semua Pod berada di belakang Ingress 
+rute utama melayani total 10.000 permintaan per detik.
+
+### Penyekalaan otomatis pada metrik yang lebih spesifik
+
+Banyak _pipeline_ metrik memungkinkan kamu mendeskripsikan metrik baik berdasarkan nama atau kumpulan tambahan
+deskriptor yang disebut _labels_. Untuk semua jenis metrik non-sumber daya (Pod, objek, dan eksternal,
+dijelaskan seperti dibawah), kamu dapat menentukan pemilih label tambahan yang diteruskan ke pipa metrik kamu. Misalnya, jika kamu mengumpulkan metrik `http_requests` dengan label `verb`
+, kamu dapat menentukan blok metrik berikut untuk diskalakan hanya pada permintaan GET:
+
+```yaml
+type: Object
+object:
+  metric:
+    name: http_requests
+    selector: {matchLabels: {verb: GET}}
+```
+
+_Selector_ ini menggunakan sintaksis yang sama dengan _selector_ lengkap label Kubernetes. Pipa pemantauan
+menentukan cara mengecilkan beberapa seri menjadi satu nilai, jika nama dan pemilih cocok dengan 
+beberapa seri. Selektor bersifat aditif, dan tidak dapat memilih metrik yang mendeskripsikan objek 
+yang **bukan** objek target (target pod dalam kasus tipe `Pod`, dan objek yang dijelaskan dalam kasus tipe `Objek`).
+
+### Penyekalaan otomatis pada metrik yang tidak terkait dengan objek Kubernetes
+
+Aplikasi yang berjalan di Kubernetes mungkin perlu melakukan penyekalaan otomatis berdasarkan metrik yang tidak
+memiliki hubungan yang jelas dengan objek apa pun di klaster Kubernetes, seperti metrik yang mendeskripsikan
+layanan yang dihosting tanpa korelasi langsung dengan namespace Kubernetes. Di Kubernetes 1.10 dan yang lebih baru, kamu dapat menangani kasus penggunaan ini dengan *metrik eksternal*.
+
+Menggunakan metrik eksternal membutuhkan pengetahuan tentang sistem pemantauanmu; penyiapannya mirip dengan yang diperlukan saat menggunakan metrik khusus. Metrik eksternal memungkinkan kamu menskalakan klaster kamu secara otomatis berdasarkan metrik apa pun yang tersedia di sistem pemantauanmu. Cukup berikan blok `metric` dengan `name` dan `selector` (pemilih), seperti di atas, dan gunakan jenis metrik `External`, bukan `Object`.
+Jika beberapa _series_ cocok dengan `metricSelector`, jumlah dari nilai mereka akan digunakan oleh HorizontalPodAutoscaler.
+Metrik eksternal mendukung jenis target `Value` dan `AverageValue`, yang berfungsi persis sama seperti saat kamu menggunakan tipe `Object`.
+
+Misalnya, jika aplikasi kamu memproses tugas dari layanan antrian yang dihosting, kamu dapat menambahkan bagian berikut ke manifes HorizontalPodAutoscaler untuk menentukan bahwa kamu memerlukan satu pekerja per 30 tugas yang belum diselesaikan.
+
+```yaml
+- type: External
+  external:
+    metric:
+      name: queue_messages_ready
+      selector: "queue=worker_tasks"
+    target:
+      type: AverageValue
+      averageValue: 30
+```
+
+Jika memungkinkan, lebih baik menggunakan target metrik khusus daripada metrik eksternal, karena lebih mudah bagi administrator klaster untuk mengamankan API metrik khusus. API metrik eksternal berpotensi memungkinkan akses ke metrik apa pun, jadi administrator klaster harus berhati-hati saat mengeksposnya.
+
+## Lampiran: Kondisi Status Horizontal Pod Autoscaler
+
+Saat menggunakan bentuk `autoscaling/v2beta2` dari HorizontalPodAutoscaler, kamu akan dapat melihat
+*status condition* yang ditetapkan oleh Kubernetes pada HorizontalPodAutoscaler. _Status condition_ ini menunjukkan apakah HorizontalPodAutoscaler dapat melakukan penyekalaan atau tidak, dan apakah saat ini dibatasi atau tidak.
+
+Kondisi muncul pada _field_ `status.conditions`. Untuk melihat kondisi yang memengaruhi HorizontalPodAutoscaler, kita bisa menggunakan `kubectl description hpa`:
+
+```shell
+kubectl describe hpa cm-test
+```
+```shell
+Name:                           cm-test
+Namespace:                      prom
+Labels:                         <none>
+Annotations:                    <none>
+CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
+Reference:                      ReplicationController/cm-test
+Metrics:                        ( current / target )
+  "http_requests" on pods:      66m / 500m
+Min replicas:                   1
+Max replicas:                   4
+ReplicationController pods:     1 current / 1 desired
+Conditions:
+  Type                  Status  Reason                  Message
+  ----                  ------  ------                  -------
+  AbleToScale           True    ReadyForNewScale        the last scale time was sufficiently old as to warrant a new scale
+  ScalingActive         True    ValidMetricFound        the HPA was able to successfully calculate a replica count from pods metric http_requests
+  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
+Events:
+```
+
+Untuk HorizontalPodAutoscaler ini, kita dapat melihat beberapa kondisi yang menandakan dalam keadaan sehat. Yang pertama, `AbleToScale`, menunjukkan apakah HPA dapat mengambil dan memperbarui skala atau tidak, serta apakah kondisi terkait _backoff_ akan mencegah penyekalaan atau tidak. Yang kedua, `ScalingActive`, menunjukkan apakah HPA diaktifkan atau tidak (yaitu jumlah replika target bukan nol) dan mampu menghitung skala yang diinginkan. Jika `False`, biasanya menunjukkan masalah dengan
+pengambilan metrik. Terakhir, kondisi terakhir, `ScalingLimited`, menunjukkan bahwa skala yang diinginkan telah dibatasi oleh maksimum atau minimum HorizontalPodAutoscaler.  Ini adalah indikasi bahwa kamu mungkin ingin menaikkan atau menurunkan batasan jumlah replika minimum atau maksimum pada HorizontalPodAutoscaler kamu.
+
+## Lampiran: Kuantitas
+
+Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="kuantitas" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili.  Ini berarti Anda mungkin melihat nilai metrik Anda berfluktuasi antara `1` dan` 1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal.
+
+## Lampiran: Skenario lain yang memungkinkan
+
+### Membuat autoscaler secara deklaratif
+
+Daripada menggunakan perintah `kubectl autoscale` untuk membuat HorizontalPodAutoscaler secara imperatif, kita dapat menggunakan berkas berikut untuk membuatnya secara deklaratif:
+
+{{< codenew file="application/hpa/php-apache.yaml" >}}
+
+Kita akan membuat _autoscaler_ dengan menjalankan perintah berikut:
+
+```shell
+kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
+```
+```
+horizontalpodautoscaler.autoscaling/php-apache created
+```
+
+
diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscale.md
similarity index 98%
rename from content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md
rename to content/id/docs/tasks/run-application/horizontal-pod-autoscale.md
index c4ed16413f..1ae40d2090 100644
--- a/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md
+++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -251,16 +251,8 @@ digunakan oleh HorizontalPodAutoscaler dan anotasi sebelumnya untuk menentukan m
 
 Kubernetes versi 1.6 menambah dukungan untuk menggunakan metrik khusus pada HorizontalPodAutoscaler.
 Kamu dapat menambahkan metrik khusus untuk HorizontalPodAutoscaler pada API versi `autoscaling/v2beta2`.
-Kubernetes kemudian memanggil API metrik khusu untuk mengambil nilai dari metrik khusus. 
-	
-@girikuncoro
-girikuncoro 4 days ago Contributor
-
-typo
-Suggested change
-Kubernetes kemudian memanggil API metrik khusu untuk mengambil nilai dari metrik khusus. 
 Kubernetes kemudian memanggil API metrik khusus untuk mengambil nilai dari metrik khusus. 
-@ecojuntak
+
 
 Lihat [Dukungan untuk API metrik](#dukungan-untuk-api-metrik) untuk kubutuhannya.
 
diff --git a/content/id/docs/tasks/tools/install-minikube.md b/content/id/docs/tasks/tools/install-minikube.md
index d3e10f4fd6..b674c52b6d 100644
--- a/content/id/docs/tasks/tools/install-minikube.md
+++ b/content/id/docs/tasks/tools/install-minikube.md
@@ -63,9 +63,9 @@ Hyper-V Requirements:     A hypervisor has been detected. Features required for
 {{< tabs name="tab_with_md" >}}
 {{% tab name="Linux" %}}
 
-### Menginstal kubectl
+### Instalasi kubectl
 
-Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
+Pastikan kamu sudah menginstal kubectl. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#menginstal-kubectl-pada-linux).
 
 ### Menginstal sebuah Hypervisor
 
@@ -125,7 +125,7 @@ brew install minikube
 {{% tab name="macOS" %}}
 ### Instalasi kubectl
 
-Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada laman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
+Pastikan kamu sudah menginstal kubectl. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#menginstal-kubectl-pada-macos).
 
 ### Instalasi sebuah Hypervisor
 
@@ -161,7 +161,7 @@ sudo mv minikube /usr/local/bin
 {{% tab name="Windows" %}}
 ### Instalasi kubectl
 
-Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
+Pastikan kamu sudah menginstal kubectl. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#menginstal-kubectl-pada-windows).
 
 ### Menginstal sebuah Hypervisor
 
diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md
index d2c8c3e8b4..9f3ec5afb3 100644
--- a/content/id/docs/tutorials/_index.md
+++ b/content/id/docs/tutorials/_index.md
@@ -18,7 +18,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus
 
 ## Prinsip Dasar
 
-* [Prinsip Dasar Kubernetes](/docs/tutorials/kubernetes-basics/) merupakan tutorial yang sangat interaktif, membantu kamu mengerti apa itu sistem Kubernetes dan beberapa fitur Kubernetes yang umum digunakan.
+* [Prinsip Dasar Kubernetes](/id/docs/tutorials/kubernetes-basics/) merupakan tutorial yang sangat interaktif, membantu kamu mengerti apa itu sistem Kubernetes dan beberapa fitur Kubernetes yang umum digunakan.
 
 * [Mikroservis yang Scalable dengan Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
 
diff --git a/content/id/docs/tutorials/kubernetes-basics/_index.html b/content/id/docs/tutorials/kubernetes-basics/_index.html
index 7abc15c771..bac7b2b6da 100644
--- a/content/id/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/id/docs/tutorials/kubernetes-basics/_index.html
@@ -23,13 +23,13 @@ card:
     <div class="row">
       <div class="col-md-9">
         <h2>Panduan Dasar Kubernetes</h2>
-        <p>Tutorial ini menyediakan panduan dasar mekanisme orkestrasi klaster Kubernetes. Setiap modul memliki beberapa informasi mengenai latar belakang bagi konsep mendasar dan <i>feature</i> Kubernetes, termasuk mode interaktif yang dapat digunakan sebagai metode pembelajaran <i>online</i>. Mode tutorial interaktif ini memberikan kesempatan pengguna untuk melakukan manajemen klaster sederhana beserta aplikasi dalam kontainer yang kamu miliki.</p>
+        <p>Tutorial ini menyediakan panduan dasar mekanisme orkestrasi klaster Kubernetes. Setiap modul memliki beberapa informasi mengenai latar belakang bagi konsep mendasar dan <i>feature</i> Kubernetes, termasuk mode interaktif yang dapat digunakan sebagai metode pembelajaran <i>online</i>. Mode tutorial interaktif ini memberikan kesempatan pengguna untuk melakukan manajemen klaster sederhana beserta aplikasi terkontainerisasi yang kamu miliki.</p>
         <p>Dengan menggunakan mode tutorial interaktif ini, pengguna diharapkan dapat memahami:</p>
         <ul>
-        <li><i>Deploy</i>i> sebuah aplikasi yang sudah dikontainerisasi pada klaster</li>
+        <li><i>Deploy</i> sebuah aplikasi yang sudah dikontainerisasi pada klaster</li>
         <li>Melakukan <i>scale</i> <i>deployment</i></li>
-        <li>Meng-update aplikasi yang sudah dikontainerisasi dengan menggunakan versi aplikasi terbaru</li>
-        <li>Men-debug aplikasi yang sudah dikontainerisasi</li>
+        <li>Memperbarui aplikasi yang sudah dikontainerisasi dengan menggunakan versi aplikasi terbaru</li>
+        <li>Men-<i>debug</i> aplikasi yang sudah dikontainerisasi</li>
         </ul>
         <p>Tutorial ini menggunakan Katakoda untuk menjalankan terminal virtual diatas Minikube pada <i>web browser</i> kamu. Dengan demikian, kamu tidak perlu melakukan instalasi perangkat lunak apa pun, segala modul yang ada dijalankan secara langsung melalui <i>web browser</i> yang kamu miliki.</p>
       </div>
@@ -44,32 +44,34 @@ card:
       </div>
     </div>
 
+    <br>
+    
     <div id="basics-modules" class="content__modules">
-      <h2>Kubernetes Basics Modules</h2>
+      <h2>Modul Dasar Kubernetes</h2>
       <div class="row">
         <div class="col-md-12">
           <div class="row">
             <div class="col-md-4">
               <div class="thumbnail">
-                <a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347" alt=""></a>
+                <a href="/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347" alt=""></a>
                 <div class="caption">
-                  <a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><h5>1. Create a Kubernetes cluster</h5></a>
+                  <a href="/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><h5>1. Membuat klaster Kubernetes</h5></a>
                 </div>
               </div>
             </div>
             <div class="col-md-4">
               <div class="thumbnail">
-                <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347" alt=""></a>
+                <a href="/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347" alt=""></a>
                 <div class="caption">
-                  <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><h5>2. Deploy an app</h5></a>
+                  <a href="/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><h5>2. Menyebarkan (Deploy) Aplikasi</h5></a>
                 </div>
               </div>
             </div>
             <div class="col-md-4">
               <div class="thumbnail">
-                <a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347" alt=""></a>
+                <a href="/id/docs/tutorials/kubernetes-basics/explore/explore-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347" alt=""></a>
                 <div class="caption">
-                  <a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><h5>3. Explore your app</h5></a>
+                  <a href="/id/docs/tutorials/kubernetes-basics/explore/explore-intro/"><h5>3. Menjelajahi aplikasimu</h5></a>
                 </div>
               </div>
             </div>
@@ -79,13 +81,33 @@ card:
           <div class="row">
             <div class="col-md-4">
               <div class="thumbnail">
-                <a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347" alt=""></a>
+                <a href="/id/docs/tutorials/kubernetes-basics/expose/expose-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/id/docs/tutorials/kubernetes-basics/expose/expose-intro/"><h5>4. Mengekspos aplikasimu secara publik</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/id/docs/tutorials/kubernetes-basics/scale/scale-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_05.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/id/docs/tutorials/kubernetes-basics/scale/scale-intro/"><h5>5. Penyekalaan naik aplikasimu</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/id/docs/tutorials/kubernetes-basics/update/update-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_06.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/id/docs/tutorials/kubernetes-basics/update/update-intro/"><h5>6. Memperbarui aplikasimu</h5></a>
+                </div>
               </div>
             </div>
           </div>
         </div>
       </div>
     </div>
+
   </main>
 
 </div>
diff --git a/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index aeae9f469d..5641d5991e 100644
--- a/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/id/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,11 +21,11 @@ weight: 20
             <div class="katacoda__alert">
                 Layar terlalu kecil untuk berinteraksi dengan Terminal, silahkan gunakan desktop/tablet.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
-                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Lanjut ke Modul 2<span class="btn__next">›</span></a>
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Lanjut ke Modul 2<span class="btn__next">›</span></a>
             </div>
         </div>
 
diff --git a/content/id/docs/tutorials/kubernetes-basics/deploy-app/_index.md b/content/id/docs/tutorials/kubernetes-basics/deploy-app/_index.md
new file mode 100644
index 0000000000..e49c3847f1
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/deploy-app/_index.md
@@ -0,0 +1,4 @@
+---
+title: Menyebarkan (Deploy) Aplikasi
+weight: 20
+---
diff --git a/content/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
new file mode 100644
index 0000000000..5dc8d1a0e8
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -0,0 +1,49 @@
+---
+title: Tutorial Interaktif - Menyebarkan (Deploy) Aplikasi
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="row">
+            <div class="col-md-12">
+                <p>
+                Pod merupakan unit eksekusi utama pada aplikasi Kubernetes. Setiap Pod mewakili sebagian dari beban kerja (<i>workload</i>) yang berjalan pada klaster kamu. <a href="/id/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Learn more about Pods</a>.
+                </p>
+            </div>
+        </div>
+
+        <br>
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                Untuk berinteraksi dengan Terminal, silahkan gunakan desktop/tablet.
+            </div>
+
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Lanjut ke Modul 3<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
new file mode 100644
index 0000000000..9c06db5b46
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
@@ -0,0 +1,109 @@
+---
+title: Menggunakan kubectl untuk membuat Deployment
+weight: 10
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+    <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+    <main class="content">
+
+        <div class="row">
+
+         <div class="col-md-8">
+          <h3>Tujuan</h3>
+                <ul>
+                    <li>Belajar tentang menyebarkan (<i>deploy</i>) aplikasi.</li>
+                    <li>Menyebarkan aplikasi pertama kamu di Kubernetes dengan kubectl.</li>
+                </ul>
+            </div>
+
+            <div class="col-md-8">
+                <h3><i>Deployment</i> Kubernetes</h3>
+                <p>
+                Ketika klaster Kubernetes kamu sudah berjalan, kamu dapat menyebarkan aplikasi terkontainerisasi di atasnya.
+                Untuk melakukannya, kamu perlu membuat konfigurasi <b>Deployment</b>. Deployment menginstruksikan Kubernetes
+                tentang bagaimana cara membuat dan memperbarui <i>instance</i> aplikasi kamu. Ketika kamu selesai membuat Deployment, Kubernetes <i>control plane</i>
+                melakukan penjadwalan <i>instance</i> aplikasi yang terlibat dalam Deployment untuk berjalan di Node individu pada klaster.
+                </p>
+
+                <p>Setelah <i>instance</i> aplikasi telah dibuat, Kubernetes Deployment Controller akan melakukan monitoring <i>instance</i> tersebut secara kontinu. Jika <i>instance</i> pada hos Node mati atau terhapus, Deployment Controller akan mengganti <i>instance</i> tersebut dengan <i>instance</i> Node lain dalam klaster. <b>Ia menyediakan mekanisme penyembuhan diri (<i>self-healing</i>) untuk mengatasi kegagalan mesin atau pemeliharaan (<i>maintenance</i>)</b></p>
+
+                <p>Pada masa pra-orkestrasi, instalasi <i>script</i> sering digunakan untuk memulai aplikasi, namun cara ini tidak memberikan mekanisme pemulihan ketika terjadi kegagalan mesin. Dengan kemampuan membuat <i>instance</i> aplikasi dan menjaganya tetap berjalan pada Node, Deployment Kubernetes menyediakan manajemen aplikasi dengan pendekatan fundamental yang berbeda. </p>
+
+            </div>
+
+            <div class="col-md-4">
+                <div class="content__box content__box_lined">
+                    <h3>Ringkasan:</h3>
+                    <ul>
+                        <li>Deployment</li>
+                        <li>Kubectl</li>
+                    </ul>
+                </div>
+                <div class="content__box content__box_fill">
+                    <p><i>
+                        Sebuah Deployment bertanggung jawab untuk membuat dan memperbarui instance dari aplikasi kamu
+                    </i></p>
+                </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2 style="color: #3771e3;">Menyebarkan aplikasi pertama kamu dalam Kubernetes</h2>
+            </div>
+        </div>
+
+        <div class="row">
+            <div class="col-md-8">
+                <p><img src="/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg"></p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+
+                <p>Kamu dapat membuat dan mengatur Deployment dengan menggunakan antar muka baris perintah (CLI) Kubernetes, <b>Kubectl</b>. Kubectl menggunakan Kubernetes API untuk berinteraksi dengan klaster. Pada modul ini, kamu akan belajar perintah-perintah yang sering digunakan Kubectl untuk membuat Deployment untuk menjalankan aplikasi kamu pada klaster Kubernetes.</p>
+
+                <p>Ketika kamu membuat Deployment, kamu perlu mendefinisikan Container <i>image</i> untuk aplikasi kamu dan jumlah replika yang kamu inginkan. Kamu dapat mengganti informasi tersebut nanti dengan melakukan pembaharuan Deployment kamu; Modul <a href="docs/tutorials/kubernetes-basics/scale/scale-intro/">5</a> dan <a href="/docs/tutorials/kubernetes-basics/update/update-intro/">6</a> pada <i>bootcamp</i> ini mendiskusikan bagaimana cara melakukan perluasan (<i>scale</i>) dan pembaruan Deployment kamu.</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_fill">
+                    <p><i> Aplikasi perlu dikemas menjadi satu dengan format Container yang didukung supaya tersebar pada Kubernetes</i></p>
+                </div>
+            </div>
+        </div>
+
+        <div class="row">
+            <div class="col-md-8">
+                <p>
+                Pada Deployment pertama kamu, kamu akan menggunakan aplikasi Node.js yang terkemas dalam Container Docker. (Jika kamu belum pernah mencoba membuat aplikasi Node.js dan menyebarkannya dengan Container, kamu dapat melakukannya dengan mengikuti instruksi pada <a href="/id/docs/tutorials/hello-minikube/">tutorial Hello Minikube</a>).
+                </p>
+                <p>Sekarang kamu tahu apa itu Deployment, mari kita ke tutorial <i>online</i> dan menyebarkan aplikasi pertama kita!</p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/" role="button">Mulai Tutorial Interaktif <span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/explore/_index.md b/content/id/docs/tutorials/kubernetes-basics/explore/_index.md
new file mode 100644
index 0000000000..89eba57482
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/explore/_index.md
@@ -0,0 +1,4 @@
+---
+title: Menjelajahi Aplikasimu
+weight: 30
+---
diff --git a/content/id/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/id/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
new file mode 100644
index 0000000000..0c96613419
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -0,0 +1,41 @@
+---
+title: Tutorial Interaktif - Menjelajahi Aplikasimu
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <br>
+        <div class="katacoda">
+
+            <div class="katacoda__alert">
+                Untuk berinteraksi dengan Terminal, tolong gunakan dalam desktop/tablet
+            </div>
+
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Lanjut ke Modul 4<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html
new file mode 100644
index 0000000000..a6381b3275
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html
@@ -0,0 +1,143 @@
+---
+title: Melihat Pod dan Node
+weight: 10
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+
+<div class="layout" id="top">
+
+    <main class="content">
+
+        <div class="row">
+
+     <div class="col-md-8">
+          <h3>Tujuan</h3>
+                <ul>
+                    <li>Belajar tentang Pod Kubernetes.</li>
+                    <li>Belajar tentang Node Kubernetes.</li>
+                    <li>Mengatasi masalah pada aplikasi-aplikasi yang digelar.</li>
+                </ul>
+            </div>
+
+            <div class="col-md-8">
+                <h2>Pod Kubernetes</h2>
+                <p>Ketika kamu membuat sebuah Deployment pada Modul <a href="/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>, Kubernetes membuatkan sebuah <b>Pod</b> untuk menempatkan instans aplikasimu. Pod merupakan sebuah abstraksi Kubernetes yang merepresentasikan sebuah grup yang terdiri dari satu atau lebih kontainer (seperti Docker), dan beberapa sumber daya bersama untuk kontainer-kontainer itu. Sumber daya tersebut termasuk:</p>
+                <ul>
+                    <li>Penyimpanan bersama, disebut Volume</li>
+                    <li>Jaringan, sebagai satu alamat IP klaster unik</li>
+                    <li>Informasi tentang bagaimana mejalankan tiap kontainer, seperti versi <i>image</i> atau porta spesifik yang digunakan oleh kontainer</li>
+                </ul>
+                <p>Pod memodelkan sebuah "logical host" spesifik aplikasi dan dapat berisi beberapa kontainer aplikasi berbeda yang relatif terkait erat. Contohnya, sebuah Pod mungkin terdiri atas kontainer aplikasi Node.js dan juga kontainer berbeda yang bertugas menyediakan data untuk dipublikasikan ke server web Node.js. Kontainer-kontainer dalam sebuah Pod berbagi satu alamat IP dan ruang porta, selalu terletak bersama dan terjadwal bersama, dan berjalankan dalam satu konteks bersama (<i>shared context</i>) pada Node yang sama.</p>
+
+            <p>Pod merupakan unit terkecil dalam platform Kubernetes. Ketika kita membuat sebuat Deployment, Deployment tersebut membuat Pod dengan kontainer-kontainer di dalamnya (bukannya dengan membuat kontainer secara langsung). Tiap Pod terikat langsung dengan Node di mana dia dijadwalkan dan tetap di sana sampai diterminasi (berdasarkan <i>restart policy</i>) atau penghapusan. Jika terjadi kegagalan pada sebuah Node, Pod indentik akan dijadwalkan di Node lain dalam klaster.</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_lined">
+                    <h3>Ringkasan:</h3>
+                    <ul>
+                        <li>Pod</li>
+                        <li>Node</li>
+                        <li>Perintah utama kubectl</li>
+                    </ul>
+                </div>
+                <div class="content__box content__box_fill">
+                        <p><i>
+                            Pod merupakan sebuah grup yang terdiri dari satu atau lebih kontainer aplikasi (seperti Docker) dan berisi penyimpanan bersama (<i>volume</i>), alamat IP dan informasi tentang bagaimana menjalankan mereka.
+                        </i></p>
+                </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2 style="color: #3771e3;">Ikhtisar Pod</h2>
+            </div>
+        </div>
+
+        <div class="row">
+            <div class="col-md-8">
+                <p><img src="/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg"></p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2>Node</h2>
+                <p>Sebuah Pod selalu berjalan dalam sebuah <b>Node</b>. Node merupakan sebuah mesin pekerja (<i>worker</i>) di Kubernetes dan mungkin merupakan mesin virtual ataupun fisik, tergantung dari klaster. Tiap Node dikelola oleh control plane. Satu Node dapat memiliki beberapa Pod, dan control plane Kubernetes yang otomatis menangani penjadwalan pod seluruh Node-Node dalam klaster. Penjadwalan otomatis oleh control plane memperhitungkan tersedianya sumber daya tiap Node.</p>
+
+                <p>Tiap Node Kuberbetes menjalankan setidaknya:</p>
+                <ul>
+                    <li>Kubelet, satu proses yang bertanggung jawab untuk berkomunikasi antara control plane Kuberneter dan Node; ini juga mengelola Pod-Pod dan kontainer-kontainer yang berjalan di sebuah mesin.</li>
+                    <li>Satu <i>container runtime</i>, seperti Docker, bertanggung jawab untuk menarik <i>image</i> kontainer dari register, membuka kontainer, dan menjalankan aplikasi.</li>
+                </ul>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_fill">
+                    <p><i> Kontainer seharusnya hanya dijadwalkan bersama di satu Pod jika terkait erat dan membutuhkan sumber daya bersama seperti diska. </i></p>
+                </div>
+            </div>
+        </div>
+
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2 style="color: #3771e3;">Ikhtisar Node</h2>
+            </div>
+        </div>
+
+        <div class="row">
+            <div class="col-md-8">
+                <p><img src="/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg"></p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2>Mengatasi masalah dengan kubectl</h2>
+                <p>Dalam Modul <a href="/id/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>, kamu menggunakan antarmuka baris perintah kubectl. Kamu akan lanjut menggunakannya pada modul 3 untuk mendapatkan informasi tentang aplikasi-aplikasi yang digelar dan lingkungannya. Operasi yang paling umum dapat dilakukan dengan perintah kubectl berikut:</p>
+                <ul>
+                    <li><b>kubectl get</b> - melihat daftar sumber daya</li>
+                    <li><b>kubectl describe</b> - menampilkan detil informasi tentang suatu sumber daya</li>
+                    <li><b>kubectl logs</b> - mencetak log-log dari satu kontainer dalam sebuah Pod</li>
+                    <li><b>kubectl exec</b> - eksekusi sebuah perintah pada satu kontainer dalam sebuah Pod</li>
+                </ul>
+
+                <p>Kamu dapat menggunakan perintah ini kapan aplikasi-aplikasi digelar, apa status mereka saat ini, di mana mereka berjalan, dan apa konfigurasi mereka.</p>
+
+                <p>Sekarang karena kita lebih mengetahui tentang klaster kita dan baris perintahnya, mari kita menjelajah aplikasi kita.</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_fill">
+                    <p><i> Node merupakan mesin pekerja di Kubernetes dan bisa berupa VM ataupun mesin fisik, tergantung pada klaster. Beberapa Pod dapat berjalan dalam satu Node. </i></p>
+                </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/explore/explore-interactive/" role="button">Mulai Tutorial Interaktif <span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/expose/_index.md b/content/id/docs/tutorials/kubernetes-basics/expose/_index.md
new file mode 100644
index 0000000000..a00eab636c
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/expose/_index.md
@@ -0,0 +1,4 @@
+---
+title: Mengekspos Aplikasimu Secara Publik
+weight: 40
+---
diff --git a/content/id/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/id/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
new file mode 100644
index 0000000000..c10f9d057d
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -0,0 +1,38 @@
+---
+title: Tutorial Interaktif - Mengekspos Aplikasimu
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                Untuk berinteraksi dengan Terminal, harap gunakan desktop/tablet
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Lanjutkan ke Modul 5<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/id/docs/tutorials/kubernetes-basics/expose/expose-intro.html
new file mode 100644
index 0000000000..a395834016
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -0,0 +1,109 @@
+---
+title: Menggunakan Service untuk Mengekspos Aplikasimu
+weight: 10
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+			<div class="col-md-8">
+    		<h3>Tujuan</h3>
+				<ul>
+					<li>Belajar tentang Service di Kubernetes</li>
+					<li>Memahami bagaimana label dan objek LabelSelector berhubungan dengan sebuah Service</li>
+					<li>Mengekspos sebuah aplikasi keluar klaster Kubernetes menggunakan sebuah Service</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+			<h3>Ikhtisar Service Kubernetes</h3>
+
+			<p><a href="/id/docs/concepts/workloads/pods/">Pod-Pod</a> Kubernetes itu fana. Pod pada kenyataannya punya <a href="/id/docs/concepts/workloads/pods/pod-lifecycle/">siklus hidup</a>. Ketika sebuah Node pekerja mati, Pod yang berjalan dalam Node itu juga hilang. <a href="/id/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> mungkin kemudian secara dinamis mendorong klaster kembali ke keadaan yang diinginkan melalui penciptaan Pod baru untuk memastikan aplikasimu berjalan. Contoh lainnya, katakanlah ada <i>backend</i> pengolahan citra dengan 3 replika. Replika tersebut dapat ditukar; sistem <i>front-end</i> seharusnya tidak peduli tentang replika <i>backend</i> atau bahkan jika Pod hilang dan dibuat ulang.  Walaupun demikian, tiap Pod dalam sebuah klaster Kubernetes memiliki alamat IP unik, meskipun Pod-Pod itu berada dalam satu Node yang sama, sehingga seharusnya ada jalan untuk mencocokan perubahan antara Pod-Pod itu sehingga aplikasimu tetap berfungsi.</p>
+
+			<p>Service di Kubernetes merupakan abstraksi yang mendefinisikan satu set Pod secara logis dan aturan untuk mengakses mereka. Service memungkinkan keterkaitan renggang antara Pod-Pod. Sebuah Service didefinisikan menggunakan YAML <a href="/id/docs/concepts/configuration/overview/#tip-konfigurasi-secara-umum">(lebih disukai)</a> atau JSON, sebagaimana semua objek Kubernetes. Kumpulan Pod yang ditargetkan oleh Service biasanya ditentukan oleh <i>LabelSelector</i> (lihat di bawah mengapa kamu mungkin ingin Service tanpa <code>selector</code> dalam <i>spec</i>).</p>
+
+			<p>Meskipun tiap Pod memiliki alamat IP unik, IP tersebut tidak diekpos ke luar klaster tanpa sebuah Service. Service memperbolehkan aplikasimu untuk menerima kunjungan. Service dapat diekspos dengan cara yang berbeda menggunakan <code>type</code> di ServiceSpec:
+			<ul>
+				<li><i>ClusterIP</i> (bawaan) - Mengekspos Service dengan internal IP dalam klaster. <i>Type</i> ini membuat Service hanya bisa diakses dalam klaster.</li>
+				<li><i>NodePort</i> - Mengekspos Service dengan porta yang sama untuk tiap Node dalam klaster menggunakan NAT. Ini membuat Service dapat diakses dari luar dengan <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>. <i>Superset</i> dari ClusterIP.</li>
+				<li><i>LoadBalancer</i> - Membuat <i>load balancer</i> eksternal di <i>cloud</i> saat ini (jika didukung) dan memberikan IP eksternal tetap kepada Service. <i>Superset</i> dari NodePort.</li>
+				<li><i>ExternalName</i> - Mengekpos Service menggunakan nama sesuai keinginan (ditentukan oleh <code>externalName</code> dalam <i>spec</i>) dengan mengembalikan catatan CNAME dengan nama tersebut. Tidak menggunakan proksi. <i>Type</i> ini membutuhkan <code>kube-dns</code> versi v1.7 atau lebih tinggi.</li>
+			</ul>
+			<p>Informasi lebih tentang <i>type</i> Service berbeda dapat ditemukan di tutorial <a href="/docs/tutorials/services/source-ip/">Menggunakan IP pengirim</a>. Lihat juga <a href="/id/docs/concepts/services-networking/connect-applications-service">Menghubungkan aplikasi dengan Service</a>.</p>
+			<p>Selain itu, catat bahwa ada kasus penggunaan Service yang tidak mendefinisikan <code>selector</code> di <i>spec</i>. Sebuah Service yang dibuat tanpa <code>selector</code> juga tidak akan membuat objek Endpoint yang sesuai. Ini mengizinkan pengguna untuk memetakan Service secara manual ke <i>endpoint</i> spesifik. Kemungkinan lain kenapa dimungkinan tanpa <i>selector</i> adalah kamu dengan tegas menggunakan <code>type: ExternalName</code>.</p>
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>Ringkasan</h3>
+					<ul>
+						<li>Mengekspos Pod ke kunjungan eksternal</li>
+						<li><i>Load balancing</i> kunjungan melintasi beberapa Pod</li>
+						<li>Menggunakan label</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+						<p><i>Service Kubernetes adalah lapisan abstraksi yang mendefinisikan kumpulan Pod secara logis dan mengijinkan paparan kunjungan eksternal, <i>load balancing</i>, dan <i>service discovery</i> untuk Pod-Pod tersebut.</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h3>Service dan Label</h3>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg" width="150%" height="150%"></p>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p>Service mengarahkan kunjungan melintasi sekumpulan Pod. Service merupakan abstraksi yang mengizinkan Pod-Pod untuk mati dan replikasi dalam Kubernetes tanpa memengaruhi aplikasimu. Menemukan dan <i>routing</i> antara Pod dependen (seperti komponen <i>frontend</i> dan <i>backend</i>) yang ditangani oleh Service Kubernetes.</p>
+				<p>Service mencocokan satu set Pod menggunakan <a href="/id/docs/concepts/overview/working-with-objects/labels/">label dan selektor</a>, mengelompokan primitif yang mengizinkan operasi logika pada objek-objek dalam Kubernetes. Label adalah pasangan <i>key/value</i> yang melekat pada objek-objek dan dapat digunakan untuk beberapa tujuan:</p>
+				<ul>
+					<li>Menandai objek-objek untuk lingkungan <i>development</i>, <i>test</i>, dan <i>production</i></li>
+					<li>Melekatkan label versi</li>
+					<li>Klasifikasi sebuah objek dengan label-label</li>
+				</ul>
+			</div>
+			
+		</div>
+
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg"></p>
+			</div>
+		</div>
+		<br>
+		<div class="row">
+			<div class="col-md-8">
+				<p>Label-label dapat dilekatkan pada objek-objek pada waktu pembuatan ataupun setelahnya. Mereka dapat diubah kapanpun. Mari kita ekspos aplikasi kita sekarang dengan sebuah Service dan menerapkan beberapa label.</p>
+			</div>
+		</div>
+		<br>
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Mulai Tutorial Interaktif<span class="btn__next">›</span></a>
+			</div>
+		</div>
+	</main>
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/scale/_index.md b/content/id/docs/tutorials/kubernetes-basics/scale/_index.md
new file mode 100644
index 0000000000..6a3cb3ff36
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/scale/_index.md
@@ -0,0 +1,4 @@
+---
+title: Penyekalaan Aplikasimu
+weight: 50
+---
diff --git a/content/id/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/id/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
new file mode 100644
index 0000000000..99b83c98f9
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -0,0 +1,40 @@
+---
+title: Tutorial Interaktif - Penyekalaan Aplikasimu
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                Untuk berinteraksi dengan Terminal, harap gunakan desktop/tablet
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">Lanjutkan ke Modul 6<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+<a class="scrolltop" href="#top"></a>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/id/docs/tutorials/kubernetes-basics/scale/scale-intro.html
new file mode 100644
index 0000000000..e5fb73f9f7
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/scale/scale-intro.html
@@ -0,0 +1,121 @@
+---
+title: Menjalankan Multipel Instans dari Aplikasimu
+weight: 10
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+    <main class="content">
+
+        <div class="row">
+
+     <div class="col-md-8">
+          <h3>Tujuan</h3>
+                <ul>
+                    <li>Penyekalaan aplikasi menggunakan kubectl.</li>
+                </ul>
+            </div>
+
+            <div class="col-md-8">
+       <h3>Penyekalaan sebuah Aplikasi</h3>
+
+            <p>Di modul-modul sebelumnya kita telah membuat <a href="/id/docs/concepts/workloads/controllers/deployment/">Deployment</a>, dan mengeksposnya secara publik via <a href="/id/docs/concepts/services-networking/service/">Service</a>. Deployment tersebut hanya membuat satu Pod untuk menjalankan aplikasi kita. Ketika kunjungan meningkat, kita perlu  melakukan penyekalaan (<i>scale</i>) aplikasi kita untuk mengikuti tingkat permintaan pengguna.</p>
+
+            <p><b>Penyekalaan</b> dapat dicapai dengan mengubah nilai replicas dalam Deployment</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_lined">
+                    <h3>Ringkasan:</h3>
+                    <ul>
+                        <li>Penyekalaan sebuah Deployment</li>
+                    </ul>
+                </div>
+                <div class="content__box content__box_fill">
+                    <p><i> Kamu dapat membuat Deployment dengan beberapa instans sekaligus dari awal dengan menggunakan parameter --replicas pada perintah kubectl create deployment</i></p>
+                </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2 style="color: #3771e3;">Ikhtisar Penyekalaan</h2>
+            </div>
+        </div>
+
+        <div class="row">
+            <div class="col-md-1"></div>
+            <div class="col-md-8">
+                <div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
+                    <ol class="carousel-indicators">
+                        <li data-target="#myCarousel" data-slide-to="0" class="active"></li>
+                        <li data-target="#myCarousel" data-slide-to="1"></li>
+                    </ol>
+                      <div class="carousel-inner" role="listbox">
+                        <div class="item carousel-item active">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg">
+                        </div>
+
+                        <div class="item carousel-item">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg">
+                        </div>
+                      </div>
+
+                      <a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
+                        <span class="sr-only ">Sebelumnya</span>
+                      </a>
+                      <a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
+                        <span class="sr-only">Selanjutnya</span>
+                      </a>
+
+                    </div>
+            </div>
+        </div>
+
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+
+                <p>Perluasan skala Deployment akan memastikan Pod baru dibuat dan dijadwalkan ke Node-Node dengan sumber daya yang tersedia. Penyekalaan akan meningkatkan jumlah Pod ke keadaan yang diinginkan. Kubernetes juga mendukung <a href="/id/docs/tasks/run-application/horizontal-pod-autoscale/"><i>autoscaling</i></a> Pod, tetapi itu di luar cakupan tutorial ini. Penyekalaan ke nol juga dimungkinkan, dan tindakan ini akan mengakhiri semua Pod pada Deployment tersebut.</p>
+
+                <p>Menjalankan beberapa instans dari aplikasi akan membutuhkan cara untuk mendistribusikan trafik ke semuanya. Service memiliki penyeimbang beban terintegrasi yang akan mendistribusikan trafik jaringan ke semua Pod dari sebuah Deployment yang diekspos. Service akan terus memonitor Pod-Pod yang berjalan menggunakan Endpoints, untuk memastikan trafik hanya dikirim ke Pod yang tersedia.</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_fill">
+                    <p><i>Penyekalaan dapat dicapai dengan mengubah jumlah replicas pada sebuah Deployment.</i></p>
+                </div>
+            </div>
+        </div>
+
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <p>Sewaktu kamu memiliki multipel instans dari aplikasi yang berjalan, kamu akan bisa melakukan pembaruan bertahap tanpa henti. Kita akan akan membahas hal tersebut pada modul selanjutnya. Sekarang, mari kita pergi ke terminal daring dan melakukan penyekalaan terhadap aplikasi kita.</p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button"> Mulai Tutorial Interaktif <span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/update/_index.md b/content/id/docs/tutorials/kubernetes-basics/update/_index.md
new file mode 100644
index 0000000000..860011dfd7
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/update/_index.md
@@ -0,0 +1,4 @@
+---
+title: Memperbarui Aplikasimu
+weight: 60
+---
diff --git a/content/id/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/id/docs/tutorials/kubernetes-basics/update/update-interactive.html
new file mode 100644
index 0000000000..6e11d5c6a7
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -0,0 +1,37 @@
+---
+title: Tutorial Interaktif - Memperbarui Aplikasimu
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                Untuk berinteraksi dengan Terminal, silahkan gunakan versi desktop/tablet
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="id" data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Kembali Mempelajari Panduan Dasar Kubernetes<span class="btn__next">›</span></a>
+            </div>
+        </div>
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/id/docs/tutorials/kubernetes-basics/update/update-intro.html
new file mode 100644
index 0000000000..5fa536f76a
--- /dev/null
+++ b/content/id/docs/tutorials/kubernetes-basics/update/update-intro.html
@@ -0,0 +1,135 @@
+---
+title: Melakukan Pembaruan Bertahap
+weight: 10
+---
+
+<!DOCTYPE html>
+
+<html lang="id">
+
+<body>
+
+    <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+
+<div class="layout" id="top">
+
+    <main class="content">
+
+        <div class="row">
+
+     <div class="col-md-8">
+          <h3>Tujuan</h3>
+                <ul>
+                    <li>Melakukan pembaruan bertahap (<i>rolling update</i>) menggunakan kubectl.</li>
+                </ul>
+            </div>
+
+            <div class="col-md-8">
+            <h3>Memperbarui suatu aplikasi</h3>
+
+            <p>Pengguna mengharapkan aplikasi tersedia sepanjang waktu dan pengembang bisa jadi diharapkan untuk men-<i>deploy</i> versi terbaru dari aplikasi tersebut beberapa kali dalam suatu waktu. Di Kubernetes hal ini dilakukan melalui pembaruan bertahap. <b>Pembaruan bertahap</b> memungkinkan pembaruan Deployment terjadi tanpa berhenti dengan memperbarui instans Pod secara bertahap dengan versi yang baru. Pod yang baru akan dijadwalkan pada Node dengan sumber daya yang tersedia.</p>
+
+            <p>Dalam modul sebelumnya kita telah melakukan penyekalaan aplikasi kita untuk menjalankan beberapa instans. Hal ini dibutuhkan untuk menjalankan pembaruan tanpa mempengaruhi ketersediaan aplikasi. Secara bawaan, jumlah maksimum dari Pod lama yang akan digantikan (menjadi tidak tersedia) selama pembaruan dan jumlah maksimum Pod baru yang dapat dibuat adalah satu. Kedua opsi ini dapat dikonfigurasi dengan angka atau persentase (dari Pod). Di Kubernetes, setiap pembaruan diberi versi masing-masing dan suatu pembaruan Deployment dapat dikembalikan ke versi sebelumnya (yang stabil).</p>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_lined">
+                    <h3>Ringkasan:</h3>
+                    <ul>
+                        <li>Memperbarui aplikasi</li>
+                    </ul>
+                </div>
+                <div class="content__box content__box_fill">
+                    <p><i>Pembaruan bertahap memungkinkan pembaruan Deployment terjadi tanpa berhenti dengan memperbarui instans Pod secara bertahap dengan versi yang baru.</i></p>
+                </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <h2 style="color: #3771e3;">Gambaran pembaruan bertahap</h2>
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-1"></div>
+            <div class="col-md-8">
+                <div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
+                    <ol class="carousel-indicators">
+                        <li data-target="#myCarousel" data-slide-to="0" class="active"></li>
+                        <li data-target="#myCarousel" data-slide-to="1"></li>
+                        <li data-target="#myCarousel" data-slide-to="2"></li>
+                        <li data-target="#myCarousel" data-slide-to="3"></li>
+                    </ol>
+                      <div class="carousel-inner" role="listbox">
+                        <div class="item carousel-item active">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg" >
+                        </div>
+
+                        <div class="item carousel-item">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg">
+                        </div>
+
+                        <div class="item carousel-item">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg">
+                        </div>
+
+                        <div class="item carousel-item">
+                          <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg">
+                        </div>
+                      </div>
+
+                      <a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
+                        <span class="sr-only ">Sebelumnya</span>
+                      </a>
+                      <a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
+                        <span class="sr-only">Selanjutnya</span>
+                      </a>
+
+                    </div>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+
+                <p>Seperti penyekalaan aplikasi, jika suatu Deployment terekspos secara publik, maka Service akan menyeimbangkan beban trafik hanya ke Pod yang tersedia saat pembaruan berlangsung. Pod yang tersedia adalah instans yang dapat diakses oleh pengguna aplikasi.</p>
+
+                <p>Pembaruan bertahap memungkinan dilakukannya aktivitas-aktivitas berikut:</p>
+                <ul>
+                    <li>Mempromosikan suatu aplikasi dari satu <i>environment</i> yang ke <i>environment</i> yang lain (via pembaruan kontainer <i>image</i>)</li>
+                    <li>Kembali (<i>rollback</i>) ke versi-versi sebelumnya</li>
+                    <li>Continuous Integration dan Continuous Delivery (CI/CD) dari aplikasi tanpa henti</li>
+                </ul>
+
+            </div>
+            <div class="col-md-4">
+                <div class="content__box content__box_fill">
+                    <p><i>Jika suatu Deployment terekspos secara publik, maka Service akan menyeimbangkan beban trafik hanya ke Pod yang tersedia saat pembaruan berlangsung.</i></p>
+                </div>
+            </div>
+        </div>
+
+        <br>
+
+        <div class="row">
+            <div class="col-md-8">
+                <p>Pada tutorial interaktif berikut ini, kita akan mencoba untuk memperbarui aplikasi kita ke versi terbaru dan kemudian melakukan <i>rollback</i>.</p>
+            </div>
+        </div>
+        <br>
+
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/id/docs/tutorials/kubernetes-basics/update/update-interactive/" role="button">Mulai Tutorial Interaktif <span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/id/docs/tutorials/stateful-application/_index.md b/content/id/docs/tutorials/stateful-application/_index.md
new file mode 100755
index 0000000000..22642348c7
--- /dev/null
+++ b/content/id/docs/tutorials/stateful-application/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Aplikasi Stateful"
+weight: 50
+---
diff --git a/content/id/docs/tutorials/stateful-application/basic-stateful-set.md b/content/id/docs/tutorials/stateful-application/basic-stateful-set.md
new file mode 100644
index 0000000000..35c27666b4
--- /dev/null
+++ b/content/id/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -0,0 +1,1202 @@
+---
+title: Dasar-dasar StatefulSet
+content_type: tutorial
+weight: 10
+---
+
+<!-- overview -->
+Tutorial ini memberikan pengantar untuk manajemen aplikasi dengan
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}.
+Di sini dicontohkan bagaimana cara untuk membuat, menghapus, melakukan penyekalaan, 
+dan memperbarui Pod dari StatefulSet.
+
+
+## {{% heading "prerequisites" %}}
+
+Sebelum memulai tutorial ini, kamu harus mengakrabkan dirimu dengan
+konsep-konsep Kubernetes sebagai berikut:
+
+* [Pod](/id/docs/concepts/workloads/pods/)
+* [DNS klaster](/id/docs/concepts/services-networking/dns-pod-service/)
+* [Service _headless_](/id/docs/concepts/services-networking/service/#service-headless)
+* [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/)
+* [Penyediaan PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/)
+* Alat baris perintah (_command line tool_) [kubectl](/docs/reference/kubectl/kubectl/)
+
+{{< note >}}
+Tutorial ini mengasumsikan bahwa klastermu telah dikonfigurasikan untuk 
+melakukan penyediaan PersistentVolume secara dinamis. Jika klastermu belum 
+dikonfigurasikan seperti itu, kamu harus menyediakan dua volume masing-masing dengan 
+ukuran 1 GiB sebelum memulai tutorial.
+{{< /note >}}
+
+## {{% heading "objectives" %}}
+
+StatefulSet ditujukan untuk digunakan dengan aplikasi-aplikasi _stateful_ 
+dan sistem terdistribusi. Akan tetapi, tata kelola aplikasi-aplikasi _stateful_ 
+dan sistem terdistribusi pada Kubernetes merupakan topik yang luas dan kompleks. 
+Untuk menunjukkan fitur-fitur dasar dari StatefulSet dan tidak mencampuradukkan 
+topik sebelum dan terakhir, kamu akan menggelar sebuah aplikasi web sederhana 
+menggunakan StatefulSet. 
+
+Setelah tutorial ini, kamu akan akrab hal-hal berikut:
+
+* Bagaimana cara membuat sebuah StatefulSet
+* Bagaimana suatu StatefulSet mengelola Pod
+* Bagaimana cara menghapus StatefulSet
+* Bagaimana cara melakukan penyekalaan terhadap suatu StatefulSet
+* Bagaimana cara memperbarui Pod dari StatefulSet
+
+<!-- lessoncontent -->
+
+## Membuat Sebuah StatefulSet
+
+Mulailah dengan membuat sebuah Statefulset dengan menggunakan contoh di bawah ini.
+Hal ini mirip dengan contoh yang ditunjukkan di dalam konsep 
+[StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/).
+Contoh ini menciptakan sebuah 
+[Service _headless_](/id/docs/concepts/services-networking/service/#service-headless), 
+`nginx`, untuk mempublikasikan alamat IP Pod di dalam StatefulSet, `web`.
+
+{{< codenew file="application/web/web.yaml" >}}
+
+Unduh contoh di atas, dan simpan ke dalam berkas dengan nama `web.yaml`.
+
+Kamu perlu menggunakan dua jendela terminal. Pada terminal yang pertama, gunakan perintah
+[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) untuk mengamati
+pembuatan Pod dari StatefulSet.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+Pada terminal yang kedua, gunakan
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) untuk membuat
+Service _headless_ dan StatefulSet yang didefinisikan di dalam `web.yaml`.
+
+```shell
+kubectl apply -f web.yaml
+```
+```
+service/nginx created
+statefulset.apps/web created
+```
+
+Perintah di atas menciptakan dua Pod, masing-masing menjalankan server web
+[NGINX](https://www.nginx.com). Dapatkan Service `nginx`...
+```shell
+kubectl get service nginx
+```
+```
+NAME      TYPE         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
+nginx     ClusterIP    None         <none>        80/TCP    12s
+```
+...kemudian dapatkan StatefulSet `web`, untuk memastikan keduanya berhasil dibuat:
+```shell
+kubectl get statefulset web
+```
+```
+NAME      DESIRED   CURRENT   AGE
+web       2         1         20s
+```
+
+### Pembuatan Pod Berurutan
+
+Untuk StatefulSet dengan _n_ replika, ketika Pod sedang digelar, kesemuanya
+akan dibuat secara berurutan, terurut dari _{0..n-1}_. Periksa keluaran dari
+perintah `kubectl get` pada terminal pertama. Pada akhirnya, keluaran yang dihasilkan
+akan seperti contoh di bawah ini.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     0/1       Pending   0          0s
+web-0     0/1       Pending   0         0s
+web-0     0/1       ContainerCreating   0         0s
+web-0     1/1       Running   0         19s
+web-1     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-1     0/1       ContainerCreating   0         0s
+web-1     1/1       Running   0         18s
+```
+Perhatikan Pod `web-1` tidak dijalankan hingga `web-0` berganti status menjadi _Running_
+(lihat [Fase Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#fase-pod)) dan _Ready_
+(lihat `type` di [Kondisi Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#kondisi-pod)).
+
+## Pod pada StatefulSet
+
+Pod pada StatefulSet memiliki satu indeks urutan unik dan satu identitas jaringan yang tetap.
+
+### Memeriksa Indeks Urutan Pod
+
+Dapatkan Pod dari StatefulSet:
+
+```shell
+kubectl get pods -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          1m
+web-1     1/1       Running   0          1m
+```
+
+Sebagaimana telah disebutkan di dalam konsep 
+[StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/),
+Pod pada StatefulSet memiliki suatu identitas yang melekat (_sticky_) dan unik.
+Identitas ini didasarkan pada sebuah indeks urutan yang unik yang di tetapkan 
+ke masing-masing Pod oleh {{< glossary_tooltip term_id="controller" text="pengontrol">}} StatefulSet.
+Nama Pod memiliki format `<nama statefulset>-<indeks urutan>`.
+Karena StatefulSet `web` memiliki dua replika, maka ada dua Pod yang tercipta, `web-0` dan `web-1`.
+
+### Menggunakan Identitas Jaringan yang Tetap
+
+Setiap Pod memiliki nama hos yang tetep berdasarkan indeks urutannya. Gunakan perintah
+[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) untuk menjalankan
+perintah `hostname` di tiap Pod:
+
+```shell
+for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done
+```
+```
+web-0
+web-1
+```
+
+Gunakan perintah [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) untuk
+menjalankan sebuah Container yang menyediakan perintah `nslookup` dari paket `dnsutils`.
+Dengan menjalankan perintah `nslookup` dengan nama hos dari Pod, kamu dapat memeriksa alamat
+DNS mereka di dalam klaster:
+
+```shell
+kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
+```
+perintah itu akan memulai sebuah _shell_ baru. Pada _shell_ tersebut, jalankan:
+```shell
+# Jalankan ini di dalam shell Container dns-test
+nslookup web-0.nginx
+```
+Keluarannya akan seperti:
+```
+Server:    10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name:      web-0.nginx
+Address 1: 10.244.1.6
+
+nslookup web-1.nginx
+Server:    10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name:      web-1.nginx
+Address 1: 10.244.2.6
+```
+
+(dan selanjutnya keluarlah dari _shell_ Container dengan menjalankan: `exit`)
+
+CNAME dari _headless service_ mengarah ke SRV _record_ (satu untuk tiap Pod yang
+Running dan Ready). SRC _record_ mengarah ke entri A _record_ yang memuat
+alamat IP Pod.
+
+Pada salah satu terminal, amati Pod dari StatefulSet:
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+Pada terminal yang lain, gunakan perintah
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) untuk menghapus
+semua Pod pada StatefulSet:
+
+```shell
+kubectl delete pod -l app=nginx
+```
+```
+pod "web-0" deleted
+pod "web-1" deleted
+```
+
+Tunggu sampai StatefulSet menjalankan mereka kembali, dan untuk keduanya menjadi
+Running dan Ready:
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+```
+NAME      READY     STATUS              RESTARTS   AGE
+web-0     0/1       ContainerCreating   0          0s
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          2s
+web-1     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-1     0/1       ContainerCreating   0         0s
+web-1     1/1       Running   0         34s
+```
+
+Gunakan perintah `kubectl exec` dan `kubectl run` untuk menampilkan nama hos Pod
+dan entri DNS mereka dalam klaster. Pertama-tama, tampilkan nama hos Pod:
+
+```shell
+for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
+```
+```
+web-0
+web-1
+```
+selanjutnya, jalankan:
+```
+kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
+```
+perintah itu akan menjalankan _shell_ baru.
+Di dalam _shell_ yang baru jalankan:
+```shell
+# Jalankan ini di dalam shell Container dns-test
+nslookup web-0.nginx
+```
+Keluarannya akan seperti:
+```
+Server:    10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name:      web-0.nginx
+Address 1: 10.244.1.7
+
+nslookup web-1.nginx
+Server:    10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+Name:      web-1.nginx
+Address 1: 10.244.2.8
+```
+
+(dan selanjutnya keluarlah dari _shell_ Container dengan menjalankan: `exit`)
+
+Urutan, nama hos, SRV _record_, dan nama A _record_ dari Pod tidak berubah,
+akan tetapi alamat IP yang terkait dengan Pod bisa jadi mengalami perubahan. Pada klaster
+yang digunakan dalam tutorial ini terjadi perubahan. Karena itulah mengapa sangat penting
+untuk menghindari pengaturan terhadap aplikasi lain yang terhubung ke Pod di dalam
+StatefulSet menggunakan alamat IP.
+
+Jika kamu ingin mencari dan terhubung dengan anggota aktif dari StatefulSet, kamu
+perlu melakukan kueri CNAME dari Service _headless_ (`nginx.default.svc.cluster.local`).
+SRV _record_ yang terkait dengan CNAME hanya akan memuat Pod dari StatefulSet yang
+Running dan Ready.
+
+Jika aplikasimu telah menerapkan logika koneksi yang menguji keaktifan
+(_liveness_) dan kesiapan (_readiness_), kamu dapat menggunakan SRV _record_ dari Pod (
+`web-0.nginx.default.svc.cluster.local`,
+`web-1.nginx.default.svc.cluster.local`), karena mereka tidak akan berubah, dan
+aplikasimu akan bisa menemukan alamat-alamat Pod ketika mereka mengalami peralihan
+ke Running dan Ready.
+
+### Menulis ke Penyimpanan Tetap
+
+Dapatkan PersistentVolumeClaim untuk `web-0` dan `web-1`:
+
+```shell
+kubectl get pvc -l app=nginx
+```
+Keluarannya akan seperti:
+```
+NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
+www-web-0   Bound     pvc-15c268c7-b507-11e6-932f-42010a800002   1Gi        RWO           48s
+www-web-1   Bound     pvc-15c79307-b507-11e6-932f-42010a800002   1Gi        RWO           48s
+```
+
+Pengontrol StatefulSet membuat dua
+{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
+yang terikat ke dua
+{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}.
+
+Karena klaster yang digunakan dalam tutorial ini dikonfigurasi untuk melakukan penyediaan
+PersistentVolume secara dinamis, maka PersistentVolume dibuat dan terikat secara otomatis.
+
+Server web NGINX, secara bawaan, menyajikan berkas indeks dari
+`/usr/share/nginx/html/index.html`. _Field_ `volumeMounts` pada `spec` StatefulSet
+memastikan direktori `/usr/share/nginx/html` didukung oleh sebuah PersistentVolume.
+
+Tulis nama hos Pod ke dalam berkas `index.html` mereka masing-masing dan periksa
+apakah server web NGINX menyajikan nama hos tersebut:
+
+```shell
+for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done
+
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+{{< note >}}
+Jika kamu melihat respon **403 Forbidden** untuk perintah curl di atas,
+kamu perlu untuk memperbaiki izin (_permission_) dari direktori yang dipasang
+oleh `volumeMounts` (disebabkan oleh sebuah
+[_bug_ ketika menggunakan volume hostPath](https://github.com/kubernetes/kubernetes/issues/2630)),
+dengan menjalankan:
+
+`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done`
+
+sebelum mencoba kembali perintah `curl` di atas.
+{{< /note >}}
+
+Di salah satu terminal, amati Pod dari StatefulSet:
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+
+Di terminal yang lain, hapus semua Pod dari StatefulSet:
+
+```shell
+kubectl delete pod -l app=nginx
+```
+```
+pod "web-0" deleted
+pod "web-1" deleted
+```
+Periksa keluaran dari perintah `kubectl get` pada terminal yang pertama dan tunggu
+semua Pod berubah menjadi Running dan Ready.
+
+```shell
+kubectl get pod -w -l app=nginx
+```
+```
+NAME      READY     STATUS              RESTARTS   AGE
+web-0     0/1       ContainerCreating   0          0s
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          2s
+web-1     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-1     0/1       ContainerCreating   0         0s
+web-1     1/1       Running   0         34s
+```
+
+Periksa apakah server web masih terus menyajikan nama hosnya:
+
+```
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+Walaupun `web-0` dan `web-1` telah dijadwalkan ulang, mereka masih menyajikan
+nama hos masing-masing karena PersistentVolume yang terkait dengan 
+PersistentVolumeClaim-nya dipasang kembali (_remounted_) ke setiap `volumeMounts`.
+Di Node manapun `web-0` dan `web-1` dijadwalkan, PersistentVolume-nya akan
+dipasangkan ke titik pasang (_mount point_) yang sesuai.
+
+## Penyekalaan StatefulSet
+
+Melakukan penyekalaan pada StatefulSet berarti meningkatkan atau mengurangi jumlah
+replika. Hal ini dicapai dengan memperbarui _field_ `replicas`. Kamu dapat menggunakan
+[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) atau
+[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) untuk
+melakukan penyekalaan terhadap StatefulSet.
+
+### Penyekalaan Naik
+
+Pada salah satu jendela terminal, amati Pod pada StatefulSet:
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+Di jendela terminal yang lain gunakan perintah `kubectl scale` untuk melakukan
+penyekalaan jumlah replika menjadi 5:
+
+```shell
+kubectl scale sts web --replicas=5
+```
+```
+statefulset.apps/web scaled
+```
+
+Periksa keluaran dari perintah `kubectl get` pada terminal pertama dan tunggu
+tambahan tiga Pod yang baru berubah menjadi Running dan Ready.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          2h
+web-1     1/1       Running   0          2h
+NAME      READY     STATUS    RESTARTS   AGE
+web-2     0/1       Pending   0          0s
+web-2     0/1       Pending   0         0s
+web-2     0/1       ContainerCreating   0         0s
+web-2     1/1       Running   0         19s
+web-3     0/1       Pending   0         0s
+web-3     0/1       Pending   0         0s
+web-3     0/1       ContainerCreating   0         0s
+web-3     1/1       Running   0         18s
+web-4     0/1       Pending   0         0s
+web-4     0/1       Pending   0         0s
+web-4     0/1       ContainerCreating   0         0s
+web-4     1/1       Running   0         19s
+```
+
+Pengontrol StatefulSet telah melakukan penyekalaan terhadap jumlah replika.
+Sama seperti [pembuatan StatefulSet](#pembuatan-pod-dengan-urutan), pengontrol
+StatefulSet membuat tiap Pod berurutan sesuai dengan indeks urutan masing-masing
+dan menunggu setiap Pod yang dibuat sebelumnya menjadi Running dan Ready sebelum
+menjalankan Pod berikutnya.
+
+### Penyekalaan Turun
+
+Di salah satu terminal, amati Pod pada StatefulSet:
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+Di terminal yang lain, gunakan perintah `kubectl patch` untuk melakukan penyekalaan
+StatefulSet turun menjadi tiga replika:
+
+```shell
+kubectl patch sts web -p '{"spec":{"replicas":3}}'
+```
+```
+statefulset.apps/web patched
+```
+
+Tunggu hingga `web-4` dan `web-3` berubah menjadi Terminating.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME      READY     STATUS              RESTARTS   AGE
+web-0     1/1       Running             0          3h
+web-1     1/1       Running             0          3h
+web-2     1/1       Running             0          55s
+web-3     1/1       Running             0          36s
+web-4     0/1       ContainerCreating   0          18s
+NAME      READY     STATUS    RESTARTS   AGE
+web-4     1/1       Running   0          19s
+web-4     1/1       Terminating   0         24s
+web-4     1/1       Terminating   0         24s
+web-3     1/1       Terminating   0         42s
+web-3     1/1       Terminating   0         42s
+```
+
+### Penghentian Pod Berurutan
+
+Pengontrol menghapus satu Pod dalam satu waktu, dengan urutan terbalik dari indeks
+urutannya, dan setiap Pod akan ditunggu sampai benar-benar mati terlebih dahulu
+sebelum menghapus Pod berikutnya.
+
+Dapatkan PersistentVolumeClaim dari StatefulSet:
+
+```shell
+kubectl get pvc -l app=nginx
+```
+```
+NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
+www-web-0   Bound     pvc-15c268c7-b507-11e6-932f-42010a800002   1Gi        RWO           13h
+www-web-1   Bound     pvc-15c79307-b507-11e6-932f-42010a800002   1Gi        RWO           13h
+www-web-2   Bound     pvc-e1125b27-b508-11e6-932f-42010a800002   1Gi        RWO           13h
+www-web-3   Bound     pvc-e1176df6-b508-11e6-932f-42010a800002   1Gi        RWO           13h
+www-web-4   Bound     pvc-e11bb5f8-b508-11e6-932f-42010a800002   1Gi        RWO           13h
+
+```
+
+Di sana masih ada lima PersistentVolumeClaim dan lima PersistentVolume.
+Ketika mengeksplorasi [penyimpanan tetap](#menulis-ke-penyimpanan-tetap) pada Pod,
+kita dapat melihat bahwa PersistentVolume yang terpasang pada Pod dari suatu StatefulSet 
+tidak terhapus ketika Pod-nya dihapus. Hal ini tetap berlaku ketika penghapusan Pod
+terjadi karena penyekalaan turun pada suatu StatefulSet.
+
+## Memperbarui StatefulSet
+
+Di Kubernetes 1.7 dan yang lebih baru, pengontrol StatefulSet mendukung
+pembaruan otomatis. Strategi yang digunakan ditentukan oleh _field_ 
+`spec.updateStrategy` dari objek API StatefulSet. Fitur ini dapat digunakan untuk
+memperbarui _image_ Container, permintaan sumber daya dan/atau pembatasan, label,
+dan anotasi Pod dalam suatu StatefulSet. Ada dua strategi pembaruan yang berlaku,
+`RollingUpdate` dan `OnDelete`.
+
+Pembaruan dengan `RollingUpdate` adalah strategi bawaan untuk StatefulSet.
+
+### Pembaruan Bertahap (RollingUpdate)
+
+Pembaruan dengan strategi `RollingUpdate` akan memperbarui semua Pod di dalam
+StatefulSet dalam urutan indeks terbalik, dengan tetap memperhatikan 
+jaminan dari StatefulSet.
+
+Lakukan _patch_ pada StatefulSet `web` dengan menerapkan `RollingUpdate`:
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+Pada salah satu jendela terminal, _patch_ StatefulSet `web` untuk mengubah 
+_image_ Container lagi:
+
+```shell
+kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
+```
+```
+statefulset.apps/web patched
+```
+
+Pada terminal yang lain, amati Pod pada StatefulSet:
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+Keluarannya akan seperti:
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          7m
+web-1     1/1       Running   0          7m
+web-2     1/1       Running   0          8m
+web-2     1/1       Terminating   0         8m
+web-2     1/1       Terminating   0         8m
+web-2     0/1       Terminating   0         8m
+web-2     0/1       Terminating   0         8m
+web-2     0/1       Terminating   0         8m
+web-2     0/1       Terminating   0         8m
+web-2     0/1       Pending   0         0s
+web-2     0/1       Pending   0         0s
+web-2     0/1       ContainerCreating   0         0s
+web-2     1/1       Running   0         19s
+web-1     1/1       Terminating   0         8m
+web-1     0/1       Terminating   0         8m
+web-1     0/1       Terminating   0         8m
+web-1     0/1       Terminating   0         8m
+web-1     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-1     0/1       ContainerCreating   0         0s
+web-1     1/1       Running   0         6s
+web-0     1/1       Terminating   0         7m
+web-0     1/1       Terminating   0         7m
+web-0     0/1       Terminating   0         7m
+web-0     0/1       Terminating   0         7m
+web-0     0/1       Terminating   0         7m
+web-0     0/1       Terminating   0         7m
+web-0     0/1       Pending   0         0s
+web-0     0/1       Pending   0         0s
+web-0     0/1       ContainerCreating   0         0s
+web-0     1/1       Running   0         10s
+```
+
+Pod dalam StatefulSet diperbarui dengan urutan indeks terbalik. Pengontrol
+StatefulSet mengakhiri setiap Pod, dan menunggunya beralih menjadi Running dan Ready
+sebelum melakukan pembaruan ke Pod berikutnya. Sebagai catatan, walaupun pengontrol
+StatefulSet tidak akan melanjutkan pembaruan terhadap Pod berikutnya hingga penggantinya
+Running dan Ready, pengontrol akan memulihkan Pod apa pun yang mengalami kegagalan selama
+proses pembaruan berlangsung.
+
+Pod yang telah menerima pembaruan akan dipulihkan ke versi yang diperbarui, sedangkan
+Pod yang belum menerima pembaruan akan dipulihkan ke versi sebelumnya. Dengan cara inilah
+pengontrol mencoba untuk terus mempertahankan kesehatan aplikasi dan
+pembaruan tetap konsisten ditengah adanya kemungkinan kegagalan intermiten.
+
+Dapatkan Pod untuk melihat _image_ Container-nya:
+
+```shell
+for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
+```
+```
+k8s.gcr.io/nginx-slim:0.8
+k8s.gcr.io/nginx-slim:0.8
+k8s.gcr.io/nginx-slim:0.8
+
+```
+
+Semua Pod pada StatefulSet saat ini sedang menjalankan _image_ Container sebelumnya.
+
+{{< note >}}
+Kamu juga bisa menggunakan perintah `kubectl rollout status sts/<name>`
+untuk menampilkan status pembaruan bertahap terhadap sebuah StatefulSet
+{{< /note >}}
+
+#### Pembaruan dengan _Staging_
+
+Kamu dapat melakukan _staging_ terhadap suatu pembaruan StatefulSet dengan
+menggunakan parameter `partition` dari strategi pembaruan `RollingUpdate`. Suatu
+pembaruan yang di-_staging_ akan akan mempertahankan semua Pod dalam StatefulSet
+tersebut pada versi yang digunakan saat ini sembari mengizinkan terjadinya
+perubahan pada `.spec.template` dari StatefulSet.
+
+Lakukan _patch_ terhadap StatefulSet `web` untuk menambahkan partisi pada
+_field_ `updateStrategy`:
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+Lakukan _patch_ terhadap StatefulSet lagi, untuk mengubah _image_ Container:
+
+```shell
+kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
+```
+```
+statefulset.apps/web patched
+```
+
+Hapus sebuah Pod dari StatefulSet:
+
+```shell
+kubectl delete pod web-2
+```
+```
+pod "web-2" deleted
+```
+
+Tunggu hingga Pod menjadi Running dan Ready.
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+NAME      READY     STATUS              RESTARTS   AGE
+web-0     1/1       Running             0          4m
+web-1     1/1       Running             0          4m
+web-2     0/1       ContainerCreating   0          11s
+web-2     1/1       Running   0         18s
+```
+
+Dapatkan _image_ Container Pod:
+
+```shell
+kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
+```
+```
+k8s.gcr.io/nginx-slim:0.8
+```
+
+Perhatikan, walaupun strategi pembaruan yang digunakan adalah `RollingUpdate`,
+StatefulSet mengembalikan Pod dengan Container-nya yang semula. Hal ini karena
+urutan Pod kurang dari nilai `partition` yang ditetapkan pada `updateStrategy`.
+
+#### Meluncurkan _Canary_
+
+Kamu dapat meluncurkan _canary_ untuk mencoba suatu perubahan dengan mengurangi
+`partition` yang kamu tentukan sebelumnya di [atas](#pembaruan-dengan-staging).
+
+Lakukan _patch_ terhadap StatefulSet untuk mengurangi jumlah partisi:
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+Tunggu hingga `web-2` menjadi Running dan Ready.
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+NAME      READY     STATUS              RESTARTS   AGE
+web-0     1/1       Running             0          4m
+web-1     1/1       Running             0          4m
+web-2     0/1       ContainerCreating   0          11s
+web-2     1/1       Running   0         18s
+```
+
+Dapatkan _image_ Container Pod:
+
+```shell
+kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
+```
+```
+k8s.gcr.io/nginx-slim:0.7
+
+```
+
+Ketika kamu mengubah `partition`, pengontrol StatefulSet secara otomatis memperbarui Pod
+`web-2` karena urutan dari Pod tersebut lebih besar dari atau sama dengan
+nilai `partition`.
+
+Hapus Pod `web-1`:
+
+```shell
+kubectl delete pod web-1
+```
+```
+pod "web-1" deleted
+```
+
+Tunggu sampai Pod `web-1` menjadi Running dan Ready.
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+Keluarannya akan seperti:
+```
+NAME      READY     STATUS        RESTARTS   AGE
+web-0     1/1       Running       0          6m
+web-1     0/1       Terminating   0          6m
+web-2     1/1       Running       0          2m
+web-1     0/1       Terminating   0         6m
+web-1     0/1       Terminating   0         6m
+web-1     0/1       Terminating   0         6m
+web-1     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-1     0/1       ContainerCreating   0         0s
+web-1     1/1       Running   0         18s
+```
+
+Dapatkan _image_ Container dari Pod `web-1`:
+
+```shell
+kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
+```
+```
+k8s.gcr.io/nginx-slim:0.8
+```
+
+`web-1` dikembalikan ke konfigurasinya yang semula karena urutan Pod lebih kecil
+dari partisi. Ketika partisi ditentukan, semua Pod dengan urutan yang lebih besar
+dari atau sama dengan jumlah partisi akan diperbarui ketika `.spec.template` dari
+StatefulSet diubah. Jika suatu Pod yang memiliki urutan lebih kecil dari partisi
+dihapus atau diakhiri, Pod tersebut akan dikembalikan ke konfigurasinya yang semula.
+
+#### Peluncuran Bertahap
+
+Kamu dapat melakukan peluncuran bertahap (misalkan peluncuran: linier, geometris, atau eksponensial)
+dengan menggunakan pembaruan bertahap yang terpartisi dengan cara yang serupa
+ketika kamu meluncurkan [_canary_](#meluncurkan-canary). Untuk melakukan peluncuran bertahap,
+atur `partition` ke urutan di mana kamu menginginkan pengontrol untuk melakukan 
+pause terhadap pembaruan.
+
+Saat ini partisi sedang di atur menjadi `2`. Ganti partisi menjadi `0`:
+
+```shell
+kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}'
+```
+```
+statefulset.apps/web patched
+```
+
+Tunggu semua Pod pada StatefulSet menjadi Running dan Ready.
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+Keluarannya akan seperti:
+```
+NAME      READY     STATUS              RESTARTS   AGE
+web-0     1/1       Running             0          3m
+web-1     0/1       ContainerCreating   0          11s
+web-2     1/1       Running             0          2m
+web-1     1/1       Running   0         18s
+web-0     1/1       Terminating   0         3m
+web-0     1/1       Terminating   0         3m
+web-0     0/1       Terminating   0         3m
+web-0     0/1       Terminating   0         3m
+web-0     0/1       Terminating   0         3m
+web-0     0/1       Terminating   0         3m
+web-0     0/1       Pending   0         0s
+web-0     0/1       Pending   0         0s
+web-0     0/1       ContainerCreating   0         0s
+web-0     1/1       Running   0         3s
+```
+
+Dapatkan detail _image_ Container dari Pod pada StatefulSet:
+
+```shell
+for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
+```
+```
+k8s.gcr.io/nginx-slim:0.7
+k8s.gcr.io/nginx-slim:0.7
+k8s.gcr.io/nginx-slim:0.7
+```
+
+Dengan mengubah nilai `partition` menjadi `0`, kamu mengizinkan StatefulSet
+untuk melanjutkan proses pembaruan.
+
+### Pembaruan OnDelete
+
+Strategi pembaruan `OnDelete` menerapkan mekanisme lama (versi 1.6 dan sebelumnya).
+Ketika kamu memilih strategi pembaruan ini, pengontrol StatefulSet tidak akan secara
+otomatis melakukan pembaruan terhadap Pod ketika suatu perubahan terjadi pada _field_
+`.spec.template` pada StatefulSet. Strategi ini dapat dipilih dengan mengatur
+`.spec.template.updateStrategy.type` menjadi `OnDelete`.
+
+## Menghapus StatefulSet
+
+StatefulSet mendukung penghapusan tidak berjenjang (_non-cascading_) dan berjenjang (_cascading_).
+Dalam penghapusan tidak berjenjang (_non-cascading delete_), Pod pada StatefulSet 
+tidak dihapus ketika StatefulSet terhapus. Pada penghapusan berjenjang (Cascading Delete),
+StatefulSet bersama Pod-nya dihapus semua.
+
+### Penghapusan Tidak Berjenjang (_Non-Cascading_)
+
+Pada salah satu jendela terminal, amati Pod pada StatefulSet.
+
+```
+kubectl get pods -w -l app=nginx
+```
+
+Gunakan perintah [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)
+untuk menghapus StatefulSet. Pastikan kamu menambahkan parameter `--cascade=false` ke
+perintah tersebut. Parameter ini memberitahukan Kubernetes untuk hanya menghapus StatefulSet
+dan agar tidak menghapus Pod yang ada padanya.
+
+```shell
+kubectl delete statefulset web --cascade=false
+```
+```
+statefulset.apps "web" deleted
+```
+
+Dapatkan Pod untuk melihat statusnya masing-masing:
+
+```shell
+kubectl get pods -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          6m
+web-1     1/1       Running   0          7m
+web-2     1/1       Running   0          5m
+```
+
+Walaupun `web` telah dihapus, semua Pod masih Running dan Ready.
+Hapus `web-0`:
+
+```shell
+kubectl delete pod web-0
+```
+```
+pod "web-0" deleted
+```
+
+Dapatkan Pod dari StatefulSet:
+
+```shell
+kubectl get pods -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-1     1/1       Running   0          10m
+web-2     1/1       Running   0          7m
+```
+
+Karena StatefulSet `web` telah dihapus, maka `web-0` tidak dijalankan lagi.
+
+Di salah satu terminal, amati Pod pada StatefulSet.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+Pada terminal yang lain, buat kembali StatefulSet. Perhatikan, terkecuali
+jika kamu telah menghapus Service `ngingx` (yang seharusnya belum kamu lakukan), 
+kamu akan melihat sebuah galat yang mengindikasikan bahwa Service tersebut sudah ada.
+
+```shell
+kubectl apply -f web.yaml
+```
+```
+statefulset.apps/web created
+service/nginx unchanged
+```
+
+Abaikan galat yang terjadi. Hal itu hanya menunjukkan bahwa suatu upaya telah dilakukan
+untuk membuat Service _headless_ `nginx` walaupun Service tersebut sebenarnya sudah ada.
+
+Perhatikan keluaran dari perintah `kubectl get` yang dijalankan pada terminal
+yang pertama.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-1     1/1       Running   0          16m
+web-2     1/1       Running   0          2m
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     0/1       Pending   0          0s
+web-0     0/1       Pending   0         0s
+web-0     0/1       ContainerCreating   0         0s
+web-0     1/1       Running   0         18s
+web-2     1/1       Terminating   0         3m
+web-2     0/1       Terminating   0         3m
+web-2     0/1       Terminating   0         3m
+web-2     0/1       Terminating   0         3m
+```
+
+Ketika StatefulSet `web` dibuat ulang, yang dijalankan pertama kali adalah `web-0`.
+Karena `web-1` telah menjadi Running dan Ready, ketika `web-0` berubah menjadi
+Running dan Ready, `web-0` mengadopsi Pod tersebut. Karena kamu membuat ulang
+StatefulSet dengan `replicas` sama dengan 2, ketika `web-0` selesai dibuat ulang, dan
+ketika `web-1` telah ditetapkan menjadi Running dan Ready, maka `web-2` diakhiri.
+
+Mari kita lihat kembali konten dari berkas `index.html` yang disajikan oleh server
+web Pod:
+
+```shell
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+Walaupun kamu sebelumnya pernah menghapus StatefulSet dan Pod `web-0`, server web
+masih terus menyajikan nama hos sebelumnya yang dimasukkan ke dalam berkas
+`index.html`. Hal ini terjadi karena StatefulSet tidak menghapus PersistentVolume
+yang terkait dengan Pod. Ketika kamu membuat ulang StatefulSet dan menjalankan
+kembali `web-0`, PersistentVolume yang digunakan sebelumnya akan dipasang kembali.
+
+### Penghapusan Berjenjang (Cascading)
+
+Pada salah satu jendela terminal, amati Pod pada StatefulSet.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+
+Pada terminal yang lain, hapus StatefulSet lagi. Kali ini, hilangkan parameter
+`--cascade=false`.
+
+```shell
+kubectl delete statefulset web
+```
+```
+statefulset.apps "web" deleted
+```
+Perhatikan keluaran dari perintah `kubectl get` yang dijalankan di terminal
+yang pertama, dan tunggu semua status Pod berubah menjadi Terminating.
+
+```shell
+kubectl get pods -w -l app=nginx
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     1/1       Running   0          11m
+web-1     1/1       Running   0          27m
+NAME      READY     STATUS        RESTARTS   AGE
+web-0     1/1       Terminating   0          12m
+web-1     1/1       Terminating   0         29m
+web-0     0/1       Terminating   0         12m
+web-0     0/1       Terminating   0         12m
+web-0     0/1       Terminating   0         12m
+web-1     0/1       Terminating   0         29m
+web-1     0/1       Terminating   0         29m
+web-1     0/1       Terminating   0         29m
+
+```
+
+Seperti yang telah kamu saksikan pada bagian [Penyekalaan Turun](#penyekalaan-turun),
+Pod diakhiri satu demi satu dengan urutan terbalik dari indeks urutan mereka. Sebelum
+mengakhiri suatu Pod, pengontrol StatefulSet menunggu Pod pengganti hingga benar-benar
+berakhir.
+
+{{< note >}}
+Walaupun penghapusan berjenjang menghapus suatu StatefulSet bersama Pod yang ada,
+penghapusan ini tidak menghapus Service _headless_ yang terkait dengan StatefulSet.
+Kamu hapus menghapus Service `nginx` secara manual.
+{{< /note >}}
+
+
+```shell
+kubectl delete service nginx
+```
+```
+service "nginx" deleted
+```
+
+Buat ulang StatefulSet dan Service _headless_ sekali lagi:
+
+```shell
+kubectl apply -f web.yaml
+```
+```
+service/nginx created
+statefulset.apps/web created
+```
+
+Saat semua Pod StatefulSet mengalami transisi ke Running dan Ready, dapatkan
+konten dari berkas `index.html` masing-masing:
+
+```shell
+for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
+```
+```
+web-0
+web-1
+```
+
+Walaupun kamu telah menghapus StatefulSet dan semua Pod di dalamnya, Pod dibuat
+lagi dengan PersistentVolume yang sama terpasang, dan `web-0` dan `web-1` masih
+menyajikan nama hos masing-masing.
+
+Akhirnya, hapus Service `nginx`...
+
+```shell
+kubectl delete service nginx
+```
+```
+service "nginx" deleted
+```
+...dan StatefulSet `web`:
+```shell
+kubectl delete statefulset web
+```
+```
+statefulset "web" deleted
+```
+
+## Kebijakan Manajemen Pod
+
+Untuk beberapa sistem terdistribusi, jaminan pengurutan StatefulSet tidak
+penting dan/atau tidak diharapkan. Sistem-sistem tersebut hanya membutuhkan
+keunikan dan identitas. Untuk mengatasi ini, pada Kubernetes 1.7, kami
+memperkenalkan `.spec.podManagementPolicy` pada objek API StatefulSet.
+
+### Manajemen Pod OrderedReady
+
+Manajemen Pod `OrderedReady` adalah bawaan dari StatefulSet. Manajemen
+dengan cara ini memberitahukan pengontrol StatefulSet untuk menghormati
+jaminan pengurutan yang sudah ditunjukkan sebelumnya.
+
+### Manajemen Pod Parallel
+
+Manajemen Pod `Parallel` memberitahukan pengontrol StatefulSet untuk
+menjalankan atau mengakhiri semua Pod secara bersamaan (paralel), dan tidak menunggu
+suatu Pod menjadi Running dan Ready atau benar-benar berakhir sebelum menjalankan atau 
+mengakhiri Pod yang lain.
+
+{{< codenew file="application/web/web-parallel.yaml" >}}
+
+Unduh contoh di atas, dan simpan ke sebuah berkas dengan nama `web-parallel.yaml`.
+
+Manifes ini serupa dengan yang telah kamu unduh sebelumnya kecuali `.spec.podManagementPolicy`
+dari StatefulSet `web` diatur ke `Parallel`.
+
+Di salah satu terminal, amati Pod pada StatefulSet.
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+
+Pada terminal yang lain, buat StatefulSet dan Service dari manifes tadi:
+
+```shell
+kubectl apply -f web-parallel.yaml
+```
+```
+service/nginx created
+statefulset.apps/web created
+```
+
+Perhatikan keluaran dari perintah `kubectl get` yang kamu jalankan pada
+terminal yang pertama.
+
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+NAME      READY     STATUS    RESTARTS   AGE
+web-0     0/1       Pending   0          0s
+web-0     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-1     0/1       Pending   0         0s
+web-0     0/1       ContainerCreating   0         0s
+web-1     0/1       ContainerCreating   0         0s
+web-0     1/1       Running   0         10s
+web-1     1/1       Running   0         10s
+```
+
+Pengontrol StatefulSet menjalankan `web-0` dan `web-` berbarengan.
+
+Biarkan terminal kedua tetap terbuka, kemudian, di jendela terminal
+yang lain lakukan penyekalaan terhadap StatefulSet:
+
+```shell
+kubectl scale statefulset/web --replicas=4
+```
+```
+statefulset.apps/web scaled
+```
+
+Perhatikan keluaran terminal di mana perintah `kubectl get` dijalankan.
+
+```
+web-3     0/1       Pending   0         0s
+web-3     0/1       Pending   0         0s
+web-3     0/1       Pending   0         7s
+web-3     0/1       ContainerCreating   0         7s
+web-2     1/1       Running   0         10s
+web-3     1/1       Running   0         26s
+```
+
+StatefulSet menjalankan dua Pod baru dan tidak menunggu Pod pertama
+menjadi Running dan Ready terlebih dahulu sebelum menjalankan Pod
+yang kedua.
+
+## {{% heading "cleanup" %}}
+
+Kamu harus membuka dua terminal yang siap untuk menjalankan perintah `kubectl`
+sebagai bagian dari pembersihan.
+
+```shell
+kubectl delete sts web
+# sts adalah singkatan dari statefulset
+```
+
+Kamu dapat mengamati `kubectl get` untuk melihat semua Pod yang sedang dihapus.
+```shell
+kubectl get pod -l app=nginx -w
+```
+```
+web-3     1/1       Terminating   0         9m
+web-2     1/1       Terminating   0         9m
+web-3     1/1       Terminating   0         9m
+web-2     1/1       Terminating   0         9m
+web-1     1/1       Terminating   0         44m
+web-0     1/1       Terminating   0         44m
+web-0     0/1       Terminating   0         44m
+web-3     0/1       Terminating   0         9m
+web-2     0/1       Terminating   0         9m
+web-1     0/1       Terminating   0         44m
+web-0     0/1       Terminating   0         44m
+web-2     0/1       Terminating   0         9m
+web-2     0/1       Terminating   0         9m
+web-2     0/1       Terminating   0         9m
+web-1     0/1       Terminating   0         44m
+web-1     0/1       Terminating   0         44m
+web-1     0/1       Terminating   0         44m
+web-0     0/1       Terminating   0         44m
+web-0     0/1       Terminating   0         44m
+web-0     0/1       Terminating   0         44m
+web-3     0/1       Terminating   0         9m
+web-3     0/1       Terminating   0         9m
+web-3     0/1       Terminating   0         9m
+```
+
+Selama penghapusan, StatefulSet menghapus semua Pod secara serentak; tidak menghentikan
+Pod berdasarkan urutan indeksnya terlebih dahulu sebelum menghapus Pod tersebut.
+
+Tutup terminal di mana perintah `kubectl get` dijalankan dan hapus Service `nginx`:
+
+```shell
+kubectl delete svc nginx
+```
+
+{{< note >}}
+Kamu juga perlu menghapus media penyimpanan persisten untuk PersistentVolume
+yang digunakan dalam tutorial ini.
+
+Ikuti langkah-langkah yang dibutuhkan, berdasarkan lingkungan yang kamu gunakan,
+konfigurasi penyimpanan, dan metode penyediaannya, untuk memastikan semua
+penyimpanan dapat dimanfaatkan lagi.
+{{< /note >}}
diff --git a/content/id/examples/admin/resource/memory-constraints-pod-2.yaml b/content/id/examples/admin/resource/memory-constraints-pod-2.yaml
new file mode 100644
index 0000000000..0b1ae569c4
--- /dev/null
+++ b/content/id/examples/admin/resource/memory-constraints-pod-2.yaml
@@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: constraints-mem-demo-2
+spec:
+  containers:
+  - name: constraints-mem-demo-2-ctr
+    image: nginx
+    resources:
+      limits:
+        memory: "1.5Gi"
+      requests:
+        memory: "800Mi"
diff --git a/content/id/examples/admin/resource/memory-constraints-pod-3.yaml b/content/id/examples/admin/resource/memory-constraints-pod-3.yaml
new file mode 100644
index 0000000000..f97cd4a8ac
--- /dev/null
+++ b/content/id/examples/admin/resource/memory-constraints-pod-3.yaml
@@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: constraints-mem-demo-3
+spec:
+  containers:
+  - name: constraints-mem-demo-3-ctr
+    image: nginx
+    resources:
+      limits:
+        memory: "800Mi"
+      requests:
+        memory: "100Mi"
diff --git a/content/id/examples/admin/resource/memory-constraints-pod-4.yaml b/content/id/examples/admin/resource/memory-constraints-pod-4.yaml
new file mode 100644
index 0000000000..657530c41e
--- /dev/null
+++ b/content/id/examples/admin/resource/memory-constraints-pod-4.yaml
@@ -0,0 +1,9 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: constraints-mem-demo-4
+spec:
+  containers:
+  - name: constraints-mem-demo-4-ctr
+    image: nginx
+
diff --git a/content/id/examples/admin/resource/memory-constraints-pod.yaml b/content/id/examples/admin/resource/memory-constraints-pod.yaml
new file mode 100644
index 0000000000..06954d10d6
--- /dev/null
+++ b/content/id/examples/admin/resource/memory-constraints-pod.yaml
@@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: constraints-mem-demo
+spec:
+  containers:
+  - name: constraints-mem-demo-ctr
+    image: nginx
+    resources:
+      limits:
+        memory: "800Mi"
+      requests:
+        memory: "600Mi"
diff --git a/content/id/examples/admin/resource/memory-constraints.yaml b/content/id/examples/admin/resource/memory-constraints.yaml
new file mode 100644
index 0000000000..3a2924c032
--- /dev/null
+++ b/content/id/examples/admin/resource/memory-constraints.yaml
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: LimitRange
+metadata:
+  name: mem-min-max-demo-lr
+spec:
+  limits:
+  - max:
+      memory: 1Gi
+    min:
+      memory: 500Mi
+    type: Container
diff --git a/content/id/examples/application/hpa/php-apache.yaml b/content/id/examples/application/hpa/php-apache.yaml
new file mode 100644
index 0000000000..f3f1ef5d4f
--- /dev/null
+++ b/content/id/examples/application/hpa/php-apache.yaml
@@ -0,0 +1,12 @@
+apiVersion: autoscaling/v1
+kind: HorizontalPodAutoscaler
+metadata:
+  name: php-apache
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: php-apache
+  minReplicas: 1
+  maxReplicas: 10
+  targetCPUUtilizationPercentage: 50
diff --git a/content/id/examples/application/nginx-with-request.yaml b/content/id/examples/application/nginx-with-request.yaml
new file mode 100644
index 0000000000..dd9d002a60
--- /dev/null
+++ b/content/id/examples/application/nginx-with-request.yaml
@@ -0,0 +1,23 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+        resources:
+          limits:
+            memory: "128Mi"
+            cpu: "500m"
+        ports:
+        - containerPort: 80
diff --git a/content/id/examples/application/php-apache.yaml b/content/id/examples/application/php-apache.yaml
new file mode 100644
index 0000000000..e8e1b5aeb4
--- /dev/null
+++ b/content/id/examples/application/php-apache.yaml
@@ -0,0 +1,36 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: php-apache
+spec:
+  selector:
+    matchLabels:
+      run: php-apache
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        run: php-apache
+    spec:
+      containers:
+      - name: php-apache
+        image: k8s.gcr.io/hpa-example
+        ports:
+        - containerPort: 80
+        resources:
+          limits:
+            cpu: 500m
+          requests:
+            cpu: 200m
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: php-apache
+  labels:
+    run: php-apache
+spec:
+  ports:
+  - port: 80
+  selector:
+    run: php-apache
diff --git a/content/id/examples/application/web/web-parallel.yaml b/content/id/examples/application/web/web-parallel.yaml
new file mode 100644
index 0000000000..4eab2dc206
--- /dev/null
+++ b/content/id/examples/application/web/web-parallel.yaml
@@ -0,0 +1,47 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  labels:
+    app: nginx
+spec:
+  ports:
+  - port: 80
+    name: web
+  clusterIP: None
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+spec:
+  serviceName: "nginx"
+  podManagementPolicy: "Parallel"
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: k8s.gcr.io/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:
+  - metadata:
+      name: www
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      resources:
+        requests:
+          storage: 1Gi
diff --git a/content/id/examples/application/web/web.yaml b/content/id/examples/application/web/web.yaml
new file mode 100644
index 0000000000..c1950aecbf
--- /dev/null
+++ b/content/id/examples/application/web/web.yaml
@@ -0,0 +1,46 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  labels:
+    app: nginx
+spec:
+  ports:
+  - port: 80
+    name: web
+  clusterIP: None
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+spec:
+  serviceName: "nginx"
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: k8s.gcr.io/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:
+  - metadata:
+      name: www
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      resources:
+        requests:
+          storage: 1Gi
diff --git a/content/id/examples/pods/resource/memory-request-limit-2.yaml b/content/id/examples/pods/resource/memory-request-limit-2.yaml
new file mode 100644
index 0000000000..99032c4fc2
--- /dev/null
+++ b/content/id/examples/pods/resource/memory-request-limit-2.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: memory-demo-2
+  namespace: mem-example
+spec:
+  containers:
+  - name: memory-demo-2-ctr
+    image: polinux/stress
+    resources:
+      requests:
+        memory: "50Mi"
+      limits:
+        memory: "100Mi"
+    command: ["stress"]
+    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]
diff --git a/content/id/examples/pods/resource/memory-request-limit-3.yaml b/content/id/examples/pods/resource/memory-request-limit-3.yaml
new file mode 100644
index 0000000000..9f089c4a7a
--- /dev/null
+++ b/content/id/examples/pods/resource/memory-request-limit-3.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: memory-demo-3
+  namespace: mem-example
+spec:
+  containers:
+  - name: memory-demo-3-ctr
+    image: polinux/stress
+    resources:
+      limits:
+        memory: "1000Gi"
+      requests:
+        memory: "1000Gi"
+    command: ["stress"]
+    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
diff --git a/content/id/examples/pods/resource/memory-request-limit.yaml b/content/id/examples/pods/resource/memory-request-limit.yaml
new file mode 100644
index 0000000000..985b1308d9
--- /dev/null
+++ b/content/id/examples/pods/resource/memory-request-limit.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: memory-demo
+  namespace: mem-example
+spec:
+  containers:
+  - name: memory-demo-ctr
+    image: polinux/stress
+    resources:
+      limits:
+        memory: "200Mi"
+      requests:
+        memory: "100Mi"
+    command: ["stress"]
+    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
diff --git a/content/id/examples/pods/storage/redis.yaml b/content/id/examples/pods/storage/redis.yaml
new file mode 100644
index 0000000000..cb06456d4b
--- /dev/null
+++ b/content/id/examples/pods/storage/redis.yaml
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: redis
+spec:
+  containers:
+  - name: redis
+    image: redis
+    volumeMounts:
+    - name: redis-storage
+      mountPath: /data/redis
+  volumes:
+  - name: redis-storage
+    emptyDir: {}
diff --git a/content/it/_index.html b/content/it/_index.html
index a5347fa45a..1e5191a982 100644
--- a/content/it/_index.html
+++ b/content/it/_index.html
@@ -41,7 +41,6 @@ Kubernetes è open source, e ti offre la libertà di spostare i tuoi carichi di
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Guarda il Video</button>
         <br>
         <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Partecipa alla KubeCon ad Amsterdam (13-16 Agosto 2020)</a>
         <br>
         <br>
diff --git a/content/it/docs/concepts/architecture/control-plane-node-communication.md b/content/it/docs/concepts/architecture/control-plane-node-communication.md
new file mode 100644
index 0000000000..95fa8cba24
--- /dev/null
+++ b/content/it/docs/concepts/architecture/control-plane-node-communication.md
@@ -0,0 +1,67 @@
+---
+title: Comunicazione Control Plane - Nodo
+content_type: concept
+weight: 20
+aliases:
+- master-node-communication
+---
+
+<!-- overview -->
+
+Questo documento cataloga le connessioni tra il piano di controllo (_control-plane_), in realtà l'apiserver, e il cluster Kubernetes. L'intento è di consentire agli utenti di personalizzare la loro installazione per rafforzare la configurazione di rete affinché il cluster possa essere eseguito su una rete pubblica (o su IP completamente pubblici resi disponibili da un fornitore di servizi cloud).
+
+
+<!-- body -->
+
+## Dal Nodo al control-plane{#dal-nodo-al-control-plane}
+Kubernetes adotta un pattern per le API di tipo _"hub-and-spoke"_. Tutte le chiamate delle API eseguite sui vari nodi sono effettuate verso l'apiserver (nessuno degli altri componenti principali è progettato per esporre servizi remoti). L'apiserver è configurato per l'ascolto di connessioni remote su una porta HTTPS protetta (443) con una o più forme di [autenticazioni client](/docs/reference/access-authn-authz/authentication/) abilitate. Si dovrebbero abilitare una o più forme di [autorizzazioni](/docs/reference/access-authn-authz/authorization/), in particolare nel caso in cui siano ammesse [richieste anonime](/docs/reference/access-authn-authz/authentication/#anonymous-requests) o [_token_ legati ad un account di servizio (_service account_)](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
+
+Il certificato pubblico (_public root certificate_) relativo al cluster corrente deve essere fornito ai vari nodi di modo che questi possano connettersi in modo sicuro all'apiserver insieme alle credenziali valide per uno specifico _client_. Ad esempio, nella configurazione predefinita di un cluster [GKE](https://cloud.google.com/kubernetes-engine?hl=it), le credenziali del client fornite al kubelet hanno la forma di un certificato client. Si veda
+[inizializzazione TLS del kubelet TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) per la fornitura automatica dei certificati client al _kubelet_.
+
+I Pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando un account di servizio in modo che Kubernetes inserisca automaticamente il certificato pubblico di radice e un token valido al portatore (_bearer token_) all'interno Pod quando questo viene istanziato.
+In tutti i namespace è configurato un _Service_ con nome `kubernetes` con un indirizzo IP virtuale che viene reindirizzato (tramite _kube-proxy_) all'endpoint HTTPS dell'apiserver.
+
+Anche i componenti del piano d controllo comunicano con l'apiserver del cluster su di una porta sicura esposta da quest'ultimo.
+
+Di conseguenza, la modalità operativa predefinita per le connessioni dai nodi e dai Pod in esecuzione sui nodi verso il _control-plane_ è protetta da un'impostazione predefinita
+e può essere eseguita su reti non sicure e/o pubbliche.
+
+## Dal control-plane al nodo{#dal-control-plane-al-nodo}
+
+Esistono due percorsi di comunicazione principali dal _control-plane_ (apiserver) verso i nodi. Il primo è dall'apiserver verso il processo _kubelet_ in esecuzione su ogni nodo nel cluster. Il secondo è dall'apiserver a ciascun nodo, Pod, o servizio attraverso la funzionalità proxy dell'apiserver.
+
+### Dall'apiserver al _kubelet_
+
+Le connessioni dall'apiserver al _kubelet_ vengono utilizzate per:
+
+  * Prendere i log relativi ai vari Pod.
+  * Collegarsi (attraverso kubectl) ai Pod in esecuzione.
+  * Fornire la funzionalità di _port-forwarding_ per i _kubelet_.
+
+Queste connessioni terminano all'endpoint HTTPS del _kubelet_. Di default, l'apiserver non verifica il certificato servito dal _kubelet_, il che rende la connessione soggetta ad attacchi _man-in-the-middle_, e tale  da essere considerato **non sicuro (unsafe)** se eseguito su reti non protette e/o pubbliche.
+
+Per verificare questa connessione, si utilizzi il parametro `--kubelet-certificate-authority` al fine di fornire all'apiserver un insieme di certificati radice da utilizzare per verificare il
+il certificato servito dal _kubelet_.
+
+Se questo non è possibile, si usi un [tunnel SSH](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) tra l'apiserver e il _kubelet_, se richiesto, per evitare il collegamento su una rete non protetta o pubblica.
+
+In fine, l'[autenticazione e/o l'autorizzazione del kubelet](/docs/admin/kubelet-authentication-authorization/) dovrebbe essere abilitate per proteggere le API esposte dal _kubelet_.
+
+### Dall'apiserver ai nodi, Pod, e servizi{#dal-apiserver-ai-nodi-pod-servizi}
+
+Le connessioni dall'apiserver verso un nodo, Pod o servizio avvengono in modalità predefinita su semplice connessione HTTP e quindi non sono né autenticate né criptata. Queste connessioni possono essere eseguite su una connessione HTTPS sicura mediante il prefisso `https:` al nodo, Pod o nome del servizio nell'URL dell'API, ma non valideranno il certificato fornito dall'endpoint HTTPS né forniranno le credenziali del client così anche se la connessione verrà criptata, non fornirà alcuna garanzia di integrità. **Non è attualmente sicuro** eseguire queste connessioni  su reti non protette e/o pubbliche.
+
+### I tunnel SSH
+
+Kubernetes supporta i _tunnel_ SSH per proteggere la comunicazione tra il _control-plane_ e i nodi. In questa configurazione, l'apiserver inizializza un tunnel SSH con ciascun nodo del cluster (collegandosi al server SSH in ascolto sulla porta 22) e fa passare tutto il traffico verso il _kubelet_, il nodo, il Pod, o il servizio attraverso questo tunnel. Questo tunnel assicura che il traffico non sia esposto al di fuori della rete su cui sono in esecuzioni i vari nodi.
+
+I tunnel SSH sono al momento deprecati ovvero non dovrebbero essere utilizzati a meno che ci siano delle esigenze particolari. Il servizio `Konnectivity` è pensato per rimpiazzare questo canale di comunicazione.
+
+### Il servizio _Konnectivity_
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+Come rimpiazzo dei tunnel SSH, il servizio _Konnectivity_ fornisce un proxy a livello TCP per la comunicazione tra il _control-plane_ e il cluster. Il servizio _Konnectivity_ consiste in due parti: il _Konnectivity_ server e gli agenti _Konnectivity_, in esecuzione rispettivamente sul _control-plane_ e sui vari nodi.  Gli agenti _Konnectivity_ inizializzano le connessioni verso il server _Konnectivity_ e mantengono le connessioni di rete. Una volta abilitato il servizio _Konnectivity_, tutto il traffico tra il _control-plane_ e i nodi passa attraverso queste connessioni.
+
+Si può fare riferimento al [tutorial per il servizio _Konnectivity_](/docs/tasks/extend-kubernetes/setup-konnectivity/) per configurare il servizio _Konnectivity_ all'interno del cluster
\ No newline at end of file
diff --git a/content/it/docs/concepts/architecture/master-node-communication.md b/content/it/docs/concepts/architecture/master-node-communication.md
deleted file mode 100644
index 375c244a6c..0000000000
--- a/content/it/docs/concepts/architecture/master-node-communication.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-draft: True
-title: Comunicazione Master-Node
-content_type: concept
-weight: 20
----
-
-<!-- overview -->
-
-Questo documento cataloga i percorsi di comunicazione tra il master (in realtà il
-apiserver) e il cluster Kubernetes. L'intento è di consentire agli utenti di
-personalizzare la loro installazione per rafforzare la configurazione di rete in questo modo
-il cluster può essere eseguito su una rete non affidabile (o su IP completamente pubblici su a
-fornitore di servizi cloud).
-
-
-
-
-<!-- body -->
-
-## Cluster to Master
-
-Tutti i percorsi di comunicazione dal cluster al master terminano in
-apiserver (nessuno degli altri componenti principali è progettato per esporre il telecomando
-Servizi). In una distribuzione tipica, l'apiserver è configurato per l'ascolto
-connessioni remote su una porta HTTPS protetta (443) con una o più forme di
-client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
-One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/)
-dovrebbe essere abilitato, specialmente se [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
-o [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
-sono ammessi.
-
-I nodi devono essere forniti con il certificato di root pubblico per il cluster
-in modo tale che possano connettersi in modo sicuro all'apiserver insieme al client valido
-credenziali. Ad esempio, in una distribuzione GKE predefinita, le credenziali del client
-fornito al kubelet hanno la forma di un certificato client. Vedere
-[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
-per il provisioning automatico dei certificati client kubelet.
-
-I pod che desiderano connettersi all'apiserver possono farlo in modo sicuro sfruttando a
-account di servizio in modo che Kubernetes inserisca automaticamente la radice pubblica
-certificato e un token al portatore valido nel pod quando viene istanziato.
-Il servizio `kubernetes` (in tutti gli spazi dei nomi) è configurato con un IP virtuale
-indirizzo che viene reindirizzato (tramite kube-proxy) all'endpoint HTTPS sul
-apiserver.
-
-I componenti master comunicano anche con l'apiserver del cluster sulla porta sicura.
-
-Di conseguenza, la modalità operativa predefinita per le connessioni dal cluster
-(nodi e pod in esecuzione sui nodi) sul master è protetto per impostazione predefinita
-e può funzionare su reti non sicure e / o pubbliche.
-
-## Master to Cluster
-
-Esistono due percorsi di comunicazione principali dal master (apiserver) al
-grappolo. Il primo è dal processo apiserver al processo kubelet su cui gira
-ogni nodo nel cluster. Il secondo è dall'Apiserver a qualsiasi nodo, pod,
-o servizio attraverso la funzionalità proxy dell'apiserver.
-
-### apiserver to kubelet
-
-Le connessioni dall'apiserver al kubelet vengono utilizzate per:
-
-  * Recupero dei log per i pod.
-  * Allegare (tramite kubectl) ai pod in esecuzione.
-  * Fornire la funzionalità di port forwarding di kubelet.
-
-Queste connessioni terminano all'endpoint HTTPS di kubelet. Di default,
-l'apiserver non verifica il certificato di servizio di Kubelet,
-che rende la connessione soggetta ad attacchi man-in-the-middle, e
-** non sicuro ** da eseguire su reti non sicure e / o pubbliche.
-
-Per verificare questa connessione, utilizzare il flag `--kubelet-certificate-authority` su
-fornire all'apiserver un pacchetto di certificati radice da utilizzare per verificare il
-il certificato di servizio di kubelet.
-
-Se questo non è possibile, usa [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
-btra l'apiserver e il kubelet se richiesto per evitare il collegamento su un
-rete non attendibile o pubblica.
-
-Finalmente, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/)
-dovrebbe essere abilitato per proteggere l'API kubelet.
-
-### apiserver to nodes, pods, and services
-
-Le connessioni dall'apiserver a un nodo, pod o servizio predefinito su semplice
-Connessioni HTTP e quindi non sono né autenticate né crittografate. Essi
-può essere eseguito su una connessione HTTPS sicura mediante il prefisso `https:` al nodo,
-pod o nome del servizio nell'URL dell'API, ma non convalideranno il certificato
-fornito dall'endpoint HTTPS né fornire le credenziali del client così mentre il file
-la connessione verrà crittografata, non fornirà alcuna garanzia di integrità.
-Queste connessioni ** non sono attualmente al sicuro ** da eseguire su non attendibili e / o
-reti pubbliche.
-
-
diff --git a/content/it/training/_index.html b/content/it/training/_index.html
index 9a2cd6f969..a8eee4e468 100644
--- a/content/it/training/_index.html
+++ b/content/it/training/_index.html
@@ -112,7 +112,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
   </div>
 </div>
diff --git a/content/ja/_index.html b/content/ja/_index.html
index a42c9484f9..b0a1005072 100644
--- a/content/ja/_index.html
+++ b/content/ja/_index.html
@@ -41,12 +41,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">2020年8月17日-20日のKubeCon EUバーチャルに参加する</a>
-        <br>
-        <br>
-        <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">2020年11月17日-20日のKubeCon NAバーチャルに参加する</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">2021年5月4日-7日のKubeCon EUバーチャルに参加する</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
diff --git a/content/ja/case-studies/appdirect/index.html b/content/ja/case-studies/appdirect/index.html
index e2b8948bf6..a5ef3a354b 100644
--- a/content/ja/case-studies/appdirect/index.html
+++ b/content/ja/case-studies/appdirect/index.html
@@ -1,70 +1,84 @@
 ---
 title: AppDirect ケーススタディ
-
 linkTitle: AppDirect
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: appdirect_featured_logo.png
 featured: true
 weight: 4
 quote: >
    私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。
+
+new_case_study_styles: true
+heading_background: /images/case-studies/appdirect/banner1.jpg
+heading_title_logo: /images/appdirect_logo.png
+title_prefix: "ケーススタディ："
+subheading: >
+  AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか
+case_study_details:
+  - 企業名: AppDirect
+  - 所在地: カリフォルニア州サンフランシスコ
+  - 業界: ソフトウェア
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_appdirect_banner1.jpg')">
-<h1>ケーススタディ：<img src="/images/appdirect_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;font-size:0.5em">AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか<br>
+<h2>課題</h2>
 
-</div></h1>
+<p><a href="https://www.appdirect.com/">AppDirect</a> はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。そのため、提供までのパイプラインにボトルネックがあったのです。」これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。</p>
 
-</div>
+<h2>ソリューション</h2>
 
-<div class="details">企業名 &nbsp;<b>AppDirect</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地&nbsp; <b>カリフォルニア州サンフランシスコ</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界&nbsp;<b>ソフトウェア</b>
-</div>
+<p>Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」彼らは、2016年初め<a href="https://kubernetes.io/">Kubernetes</a> の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のために<a href="https://prometheus.io/">Prometheus</a> モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターを<a href="https://aws.amazon.com/">AWS</a> 上や世界中のオンプレミス環境で展開しています。</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%">
-    <h2>課題</h2><a href="https://www.appdirect.com/">AppDirect</a> はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。
-そのため、提供までのパイプラインにボトルネックがあったのです。」
-これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。
-<br><br><h2>ソリューション</h2>Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」
-彼らは、2016年初め<a href="https://kubernetes.io/">Kubernetes</a> の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のために<a href="https://prometheus.io/">Prometheus</a>
-モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターを<a href="https://aws.amazon.com/">AWS</a> 上や世界中のオンプレミス環境で展開しています。 <br><br><h2>インパクト</h2>Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。
-彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。
-新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。
-こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに<a href="https://www.atlassian.com/software/jira">Jira</a> のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。
-以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。
-また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte</span></div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2><a href="https://www.appdirect.com/">AppDirect</a> は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。</h2><br> 2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」<br><br> これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、<a href="https://nodejs.org/">Node.js</a> に <a href="http://spring.io/projects/spring-boot">Spring Boot Java</a>といった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_appdirect_banner3.jpg')">
-  <div class="banner3text">「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  AppDirect ソフトウェア開発者　Alexandre Gervais </span></div>
-</div>
-<section class="section3">
-<div class="fullcol">Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。<br><br>Lacerteのグループは運用チームと連携することで同社の <a href="https://aws.amazon.com/">AWSのインフラ</a>により多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で <a href="https://www.chef.io/">Chef</a> や<a href="https://www.terraform.io/">Terraform</a> によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分で<a href="https://github.com/kubernetes/kops">Kops</a>を使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。<br><br> 今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。<br><br> Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 <a href="https://www.atlassian.com/software/jira">Jira</a>のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_appdirect_banner4.jpg');width:100%;">
-  <div class="banner4text">「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte</span></div>
-</div>
+<h2>インパクト</h2>
+
+<p>Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに<a href="https://www.atlassian.com/software/jira">Jira</a> のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。</p>
+
+{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}}
+「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+<a href="https://www.appdirect.com/">AppDirect</a> は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。
+{{< /case-studies/lead >}}
+
+<p>2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」</p>
+
+<p>これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、<a href="https://nodejs.org/">Node.js</a> に <a href="http://spring.io/projects/spring-boot">Spring Boot Java</a>といった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/appdirect/banner3.jpg"
+  author="AppDirect ソフトウェア開発者　Alexandre Gervais"
+>}}
+「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」
+{{< /case-studies/quote >}}
+
+<p>Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。</p>
+
+<p>Lacerteのグループは運用チームと連携することで同社の <a href="https://aws.amazon.com/">AWSのインフラ</a>により多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で <a href="https://www.chef.io/">Chef</a> や<a href="https://www.terraform.io/">Terraform</a> によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分で<a href="https://github.com/kubernetes/kops">Kops</a>を使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。</p>
+
+<p>今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。</p>
+
+<p>Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 <a href="https://www.atlassian.com/software/jira">Jira</a>のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/appdirect/banner4.jpg"
+  author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte"
+>}}
+「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」
+{{< /case-studies/quote >}}
 
 <section class="section5" style="padding:0px !important">
 
-<div class="fullcol">さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました<br><br>AppDirectのクラウドネイティブなスタックには<a href="https://grpc.io/">gRPC</a>、<a href="https://www.fluentd.org/">Fluentd</a>も含まれていて、そして今このチームは<a href="https://opencensus.io/">OpenCensus</a>の立ち上げに取り組んでいるところです。このプラットフォームはすでに<a href="https://prometheus.io/">Prometheus</a> で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境では<a href="https://slack.com/">Slack</a> メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」</div>
+<p>さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました</p>
 
-<div class="banner5" >
-  <div class="banner5text">「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte</span></div>
-</div>
+<p>AppDirectのクラウドネイティブなスタックには<a href="https://grpc.io/">gRPC</a>、<a href="https://www.fluentd.org/">Fluentd</a>も含まれていて、そして今このチームは<a href="https://opencensus.io/">OpenCensus</a>の立ち上げに取り組んでいるところです。このプラットフォームはすでに<a href="https://prometheus.io/">Prometheus</a> で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境では<a href="https://slack.com/">Slack</a> メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」</p>
 
-<div class="fullcol">もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 <br><br> エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」<br><br>Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」</div>
-</section>
+{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}}
+「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」
+{{< /case-studies/quote >}}
+
+<p>もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」</p>
+
+<p>エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」</p>
+
+<p>Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」</p>
diff --git a/content/ja/case-studies/chinaunicom/index.html b/content/ja/case-studies/chinaunicom/index.html
index 4c288aa97a..1f3fff3cee 100644
--- a/content/ja/case-studies/chinaunicom/index.html
+++ b/content/ja/case-studies/chinaunicom/index.html
@@ -1,104 +1,78 @@
 ---
-title: China Unicom Case Study
-
+title: China Unicom ケーススタディ
 linkTitle: chinaunicom
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
-logo: chinaunicom_featured_logo.png
-featured: true
-weight: 1
-quote: >
-   Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。
+featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/chinaunicom/banner1.jpg
+heading_title_logo: /images/chinaunicom_logo.png
+title_prefix: "ケーススタディ："
+subheading: >
+  Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。
+case_study_details:
+  - 企業名: China Unicom
+  - 所在地: 中国、北京
+  - 業界: テレコム
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_chinaunicom_banner1.jpg')">
-<h1>ケーススタディ：<img src="/images/chinaunicom_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;line-height:1.4em">China Unicom社：KubernetesによるITコスト削減と効率性向上をいかにして実現したか<br>
+<h2>課題</h2>
 
-</div></h1>
+<p>China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 <a href="https://www.vmware.com/">VMWare</a>、<a href="https://www.openstack.org/">OpenStack</a>のインフラや<a href="https://rancher.com/">Docker</a>によるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。</p>
 
-</div>
+<h2>ソリューション</h2>
 
-<div class="details">
-        企業名 &nbsp;<b>China Unicom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 <b>中国、北京</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界<b>&nbsp;テレコム</b>
-</div>
+<p>急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、<a href="https://istio.io/">Istio</a>、 <a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://coredns.io/">CoreDNS</a>、そして<a href="https://www.fluentd.org/">Fluentd</a>も活用しています。</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>課題</h2>
-    China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 <a href="https://www.vmware.com/">VMWare</a>、<a href="https://www.openstack.org/">OpenStack</a>のインフラや<a href="https://rancher.com/">Docker</a>によるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&amp;D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。
-<br><br>
-
-    <h2>ソリューション</h2>
-    急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、<a href="https://istio.io/">Istio</a>、 <a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://coredns.io/">CoreDNS</a>、そして<a href="https://www.fluentd.org/">Fluentd</a>も活用しています。
-<br><br>
 <h2>インパクト</h2>
-    KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。
-リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。
 
-</div>
+<p>KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-        「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」
-<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang、 China Unicom プラットフォーム技術R&amp;D グループリーダー</span></span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。 </h2>
+{{< case-studies/quote author="Chengyu Zhang、China Unicom プラットフォーム技術R&D グループリーダー" >}}
+「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」
+{{< /case-studies/quote >}}
 
-    その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&amp;D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」
- <br><br>
-  そこで新しい技術、研究開発(R&amp;D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_chinaunicom_banner3.jpg');width:100%;padding-left:0;">
-  <div class="banner3text">
-        「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang、 China Unicom プラットフォーム技術R&amp;D グループリーダー</span></span>
+{{< case-studies/lead >}}
+China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-      China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。<br><br>
+<p>その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」</p>
 
-  同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。<br><br>
+<p>そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。</p>
 
-  「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」
+{{< case-studies/quote
+  image="/images/case-studies/chinaunicom/banner3.jpg"
+  author="Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー"
+>}}
+「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_chinaunicom_banner4.jpg');width:100%">
-  <div class="banner4text">
-    「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Jie Jia、China Unicom プラットフォーム技術 R&amp;D</span>
-  </div>
-</div>
+<p>China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-    事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」<br><br>
-  China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。
-</div>
+<p>同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Jie Jia、China Unicom プラットフォーム技術 R&amp;D</span></div>
-</div>
+<p>「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」</p>
 
-<div class="fullcol">
-    プラットフォーム技術 R&amp;D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。<br><br>
-  「企業は  <a href="https://rancher.com/">Rancher</a>  のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」 <br><br>
+{{< case-studies/quote 
+  image="/images/case-studies/chinaunicom/banner4.jpg"
+  author="Jie Jia、China Unicom プラットフォーム技術 R&D"
+>}}
+「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」
+{{< /case-studies/quote >}}
 
-  今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの<a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)</a>に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。<br><br>
+<p>事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」</p>
 
-  それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
+<p>China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。</p>
 
-</div>
-</section>
-</body>
-</html>
+{{< case-studies/quote author="Jie Jia、China Unicom プラットフォーム技術 R&D" >}}
+「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」
+{{< /case-studies/quote >}}
+
+<p>プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。</p>
+
+<p>「企業は  <a href="https://rancher.com/">Rancher</a>  のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」</p>
+
+<p>今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの<a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)</a>に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。</p>
+
+<p>それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」</p>
diff --git a/content/ja/case-studies/nav/index.html b/content/ja/case-studies/nav/index.html
index c9ad5ab65b..1c1f34c78e 100644
--- a/content/ja/case-studies/nav/index.html
+++ b/content/ja/case-studies/nav/index.html
@@ -1,93 +1,82 @@
 ---
-title: Navケーススタディ
+title: Nav ケーススタディ
 linkTitle: Nav
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
-logo: nav_featured_logo.png
-featured: true
-weight: 3
+featured: false
 quote: > 
-   コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。
+  コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nav/banner1.jpg
+heading_title_logo: /images/nav_logo.png
+title_prefix: "ケーススタディ："
+subheading: >
+  スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか
+case_study_details:
+  - 企業名: Nav
+  - 所在地: ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ
+  - 業界: 事業者向け金融サービス
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_nav_banner1.jpg')">
-  <h1>ケーススタディ：<img src="/images/nav_logo.png" class="header_logo" style="width:15%"><br><div class="subhead" style="margin-top:1%">スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか</div></h1>
+<h2>課題</h2>
 
-</div>
+<p>2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」</p>
 
-<div class="details">
-	企業名 &nbsp;<b>Nav</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>事業者向け金融サービス</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%;margin-left:-1.5%">
-<br><br>
- <h2>課題</h2>
-2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」
-  <br><br>
 <h2>ソリューション</h2> 
-数多くのオーケストレーション ソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>上で稼働する <a href="https://kubernetes.io/">Kubernetes</a>を採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」
+
+<p>数多くのオーケストレーション ソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>上で稼働する <a href="https://kubernetes.io/">Kubernetes</a>を採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」</p>
 
 <h2>インパクト</h2>
-4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。
 
-</div>
-</div>
-</section>
+<p>4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。</p>
 
-<div class="banner2">
-  <div class="banner2text"><iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> 
-
-<br><br> 
+{{< case-studies/quote author="Travis Jeppson、Nav  エンジニアリング ディレクター" >}}
+<iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<br>
 「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」
- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Travis Jeppson、Nav  エンジニアリング ディレクター</span></div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。 </h2>
-数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」
-<br><br>
- こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_nav_banner3.jpg')">
-  <div class="banner3text"> 「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson、Nav エンジニアリングディレクター</span></div>
+{{< case-studies/lead >}}
+2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。
+{{< /case-studies/lead >}}
 
+<p>数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」</p>
 
-</div>
-<section class="section3">
-<div class="fullcol">Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。<br><br>
- 数多くのオーケストレーションソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>での<a href="https://kubernetes.io/">Kubernetes</a> 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」<br><br>
- Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために <a href="http://kubespray.io/">Kubespray</a> を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_nav_banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Travis Jeppson、Nav エンジニアリングディレクター</span>
- </div>
-</div>
+<p>こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」</p>
 
-<section class="section5" style="padding:0px !important">
+{{< case-studies/quote
+  image="/images/case-studies/nav/banner3.jpg"
+  author="Travis Jeppson、Nav エンジニアリングディレクター"
+>}}
+「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。
-そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために <a href="https://gitlab.com/">GitLab</a>にリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>を用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」<br><br>
- マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。<br><br>
- また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、<a href="https://www.twistlock.com/">Twistlock</a>ツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。
-</div>
+<p>Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。</p>
 
-<div class="banner5" >
-  <div class="banner5text">「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Travis Jeppson、Nav  エンジニアリング ディレクター</span></div>
-</div>
+<p>数多くのオーケストレーションソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>での<a href="https://kubernetes.io/">Kubernetes</a> 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」</p>
 
-<div class="fullcol">
- Kubernetesが導入された中、Navチームは <a href="https://prometheus.io/">Prometheus</a>を採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」<br><br>
- これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らは<a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://opentracing.io/">OpenTracing</a>、そして <a href="https://www.jaegertracing.io/">Jaeger</a>を検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」<br><br>
- もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」
+<p>Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために <a href="http://kubespray.io/">Kubespray</a> を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」</p>
 
-</div>
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/nav/banner4.jpg"
+  author="Travis Jeppson、Nav エンジニアリングディレクター"
+>}}
+「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」
+{{< /case-studies/quote >}}
+
+<p>この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために <a href="https://gitlab.com/">GitLab</a>にリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>を用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」</p>
+
+<p>マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。</p>
+
+<p>また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、<a href="https://www.twistlock.com/">Twistlock</a>ツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。</p>
+
+{{< case-studies/quote author="Travis Jeppson、Nav  エンジニアリング ディレクター" >}}
+「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」
+{{< /case-studies/quote >}}
+
+<p>Kubernetesが導入された中、Navチームは <a href="https://prometheus.io/">Prometheus</a>を採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」</p>
+
+<p>これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らは<a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://opentracing.io/">OpenTracing</a>、そして <a href="https://www.jaegertracing.io/">Jaeger</a>を検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」</p>
+
+<p>もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」</p>
diff --git a/content/ja/case-studies/nordstrom/index.html b/content/ja/case-studies/nordstrom/index.html
index e867f49d7c..ec757ca23c 100644
--- a/content/ja/case-studies/nordstrom/index.html
+++ b/content/ja/case-studies/nordstrom/index.html
@@ -2,105 +2,76 @@
 title: Nordstrom ケーススタディ
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nordstrom/banner1.jpg
+heading_title_logo: /images/nordstrom_logo.png
+title_prefix: "ケーススタディ："
+subheading: >
+  厳しい小売環境下で数百万ドルのコスト削減を実現
+case_study_details:
+  - 企業名: Nordstrom
+  - 所在地: シアトル、ワシントン
+  - 業界: 小売り
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_nordstrom_banner1.jpg')">
-  <h1> ケーススタディ:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">厳しい小売環境下で数百万ドルのコスト削減を実現
+<h2>課題</h2>
+
+<p>NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。</p>
+
+<h2>解決策</h2>
+
+<p>4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、<a href="http://kubernetes.io/">Kubernetes</a>でオーケストレーションされたDockerコンテナを採用しました。</p>
+
+<h2>影響</h2>
+
+<p>Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」</p>
+
+{{< case-studies/quote author="Nordstrom社シニアエンジニア Dhawal Patel" >}}
+私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
+{{< /case-studies/quote >}}
+
+<p>5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者として<a href="http://shop.nordstrom.com/">Nordstrom</a>に入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。</p>
+
+<p>DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」</p>
+
+<p>同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。</p>
+
+<p>開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームは<a href="https://www.chef.io/chef/">Chef</a>を選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」</p>
+
+<p>しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。</p>
+
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
+「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」
+{{< /case-studies/quote >}}
+
+<p>「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」</p>
+
+<p>Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。</p>
+
+<p>Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」</p>
+
+<p>参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」</p>
+
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
+「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
+{{< /case-studies/quote >}}
 
 
-</div></h1>
+<p>これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のための<a href="https://prometheus.io/">Prometheus</a>と<a href="https://grafana.com/">Grafana</a>フロントエンドを組み合わせました。また、<a href="http://www.fluentd.org/">Fluentd</a>を使用してログを<a href="https://www.elastic.co/">Elasticsearch</a>にプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。</p>
 
-</div>
+<p>現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」</p>
 
-<div class="details">
-    企業名 &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>シアトル、ワシントン</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>小売り</b>
-</div>
+<p>Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>課題</h2>
- NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。
-<br>
-    <h2>解決策</h2>
- 4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、<a href="http://kubernetes.io/">Kubernetes</a>でオーケストレーションされたDockerコンテナを採用しました。
-  <br>
+{{< case-studies/quote >}}
+「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
+{{< /case-studies/quote >}}
 
+<p>スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」</p>
 
-      </div>
+<p>Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」</p>
 
-<div class="col2">
+<p>そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」</p>
 
-  <h2>影響</h2>
-  Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-Nordstrom社シニアエンジニア Dhawal Patel</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者として<a href="http://shop.nordstrom.com/">Nordstrom</a>に入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。
-<br><br>
-    DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」
-<br><br>
-    同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。
-<br><br>
-    開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームは<a href="https://www.chef.io/chef/">Chef</a>を選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」
-    <br><br>しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。
-
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_nordstrom_banner3.jpg')">
-  <div class="banner3text">
-    「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-
-「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」
-<br><br>
-Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。
-Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」
-<br><br>
-参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_nordstrom_banner4.jpg')">
-  <div class="banner4text">
- 「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
-  </div>
-</div>
-
-<section class="section5">
-<div class="fullcol">
-  これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のための<a href="https://prometheus.io/">Prometheus</a>と<a href="https://grafana.com/">Grafana</a>フロントエンドを組み合わせました。また、<a href="http://www.fluentd.org/">Fluentd</a>を使用してログを<a href="https://www.elastic.co/">Elasticsearch</a>にプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。
- <br><br>
-現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」
- <br><br>
-Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。
-</div>
-
-<div class="banner5">
-  <div class="banner5text">
- 「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
-  </div>
-</div>
-
-<div class="fullcol">
-  スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
-<br><br>
-  Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」
-  そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」
-<br><br>
-  この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」
-
-</div>
-</section>
+<p>この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」</p>
diff --git a/content/ja/case-studies/sos/index.html b/content/ja/case-studies/sos/index.html
index 814e9cb119..c63fa4ab51 100644
--- a/content/ja/case-studies/sos/index.html
+++ b/content/ja/case-studies/sos/index.html
@@ -3,108 +3,82 @@ title: SOS International ケーススタディ
 linkTitle: SOS International
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: sos_featured_logo.png
+
+new_case_study_styles: true
+heading_background: /images/case-studies/sos/banner1.jpg
+heading_title_logo: /images/sos_logo.png
+title_prefix: "ケーススタディ："
+subheading: >
+  SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供
+case_study_details:
+  - 企業名: SOS International
+  - 所在地: フレゼレクスベア、デンマーク
+  - 業界: 医療および旅行支援
 ---
 
+<h2>課題</h2>
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_sos_banner1.jpg')">
-  <h1>ケーススタディ:<img src="/images/sos_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供
+<p>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」</p>
 
-</div></h1>
+<h2>ソリューション</h2>
 
-</div>
+<p>標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。</p>
 
-<div class="details">
-    企業名 &nbsp;<b>SOS International</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>フレゼレクスベア、デンマーク
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>医療および旅行支援</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>課題</h2>
- SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては
-3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
-
-
-<br><br>
-    <h2>ソリューション</h2>
- 標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
-<br><br>
 <h2>影響</h2>
- Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
- 「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。</h2>
- SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。<br><br>
- ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
-<br><br>
- Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」
+<p>Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」</p>
 
+{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}}
+「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。」
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_sos_banner3.jpg')">
-  <div class="banner3text">
- 「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
+{{< case-studies/lead >}}
+SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。
+{{< /case-studies/lead >}}
 
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
+<p>SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
- Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。<br><br>
+<p>ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」</p>
 
- 技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」<br><br>
+<p>Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」</p>
 
-プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_sos_banner4.jpg');width:100%">
-  <div class="banner4text">
- 「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/sos/banner3.jpg"
+  author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen"
+>}}
+「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
- プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。<br><br>
+<p>Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。</p>
 
- SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」<br><br>
+<p>技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」</p>
 
- しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。<br><br>
+<p>プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。</p>
 
- さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
+{{< case-studies/quote
+  image="/images/case-studies/sos/banner4.jpg"
+  author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen"
+>}}
+「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
+{{< /case-studies/quote >}}
 
-</div>
+<p>プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。</p>
 
-<div class="banner5" >
-  <div class="banner5text">
- 「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span></div>
-</div>
+<p>SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」</p>
 
-<div class="fullcol">
- SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」<br><br>
+<p>しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。</p>
 
- SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」<br><br>
+<p>さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」</p>
 
- 代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」<br><br>
+{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}}
+「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」
+{{< /case-studies/quote >}}
 
- Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」
-</div>
-</section>
+<p>SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」</p>
+
+<p>SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」</p>
+
+<p>代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」</p>
+
+<p>Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」</p>
diff --git a/content/ja/case-studies/spotify/index.html b/content/ja/case-studies/spotify/index.html
index 0725723b68..09a82b5fdb 100644
--- a/content/ja/case-studies/spotify/index.html
+++ b/content/ja/case-studies/spotify/index.html
@@ -1,120 +1,82 @@
 ---
-title: Spotifyケーススタディ
-linkTitle: Spotify 
+title: Spotify ケーススタディ
+linkTitle: Spotify
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
-logo: spotify_featured_logo.png 
-featured: true
-weight: 2
+featured: false
 quote: >
-   Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。
+  Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。
+
+new_case_study_styles: true
+heading_background: /images/case-studies/spotify/banner1.jpg
+heading_title_text: Spotify
+title_prefix: "ケーススタディ："
+subheading: >
+  Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています
+case_study_details:
+  - 企業名: Spotify
+  - 所在地: グローバル
+  - 業界: エンターテイメント
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_spotify_banner1.jpg')">
-  <h1> ケーススタディ：Spotify<br> <div class="subhead" style="margin-top:1%">Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています
+<h2>課題</h2>
 
-</div></h1>
+<p>2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、<a href="https://github.com/spotify/helios">Helios</a>という自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。</p>
 
-</div>
+<h2>ソリューション</h2>
 
-<div class="details">
-    企業名 &nbsp;<b>Spotify</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>グローバル</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>エンターテイメント</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%">
-    <h2>課題</h2>
-    2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、<a href="https://github.com/spotify/helios">Helios</a>という自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。
-
-<br><br>
-    <h2>ソリューション</h2>
-    「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。
+<p>「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。</p>
 
 <h2>インパクト</h2>
-    2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。
-    
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。 
-2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。</h2>
 
-<br><br>
-  マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」<br><br>しかし、2017年の終わりまでには、「小さなチームが<a href="https://github.com/spotify/helios">Helios</a>の機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。
+<p>2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。</p>
 
+{{< case-studies/quote author="Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti" >}}
+「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_spotify_banner3.jpg')">
-  <div class="banner3text">
-    「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky</span>
+{{< case-studies/lead >}}
+「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」
-    
-<br><br>
+<p>マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」</p>
 
-チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。
+<p>しかし、2017年の終わりまでには、「小さなチームが<a href="https://github.com/spotify/helios">Helios</a>の機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。</p>
 
-<br><br>
-マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」
-<br><br>
-今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。
+{{< case-studies/quote
+  image="/images/case-studies/spotify/banner3.jpg"
+  author="Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky"
+>}}
+「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」
+{{< /case-studies/quote >}}
 
-「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。
+<p>もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」</p>
 
-Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。
+<p>チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。</p>
 
+<p>マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_spotify_banner4.jpg')">
-  <div class="banner4text">
-  「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Spotify、Spotifyエンジニア、James Wen</span>
-  </div>
-</div>
+<p>今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。
-<br><br>
-Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」
-<br><br>
-またSpotifyは<a href="https://grpc.io/">gRPC</a>と<a href="https://www.envoyproxy.io/">envoy</a>を使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」
+{{< case-studies/quote
+  image="/images/case-studies/spotify/banner4.jpg"
+  author="Spotify、Spotifyエンジニア、James Wen"
+>}}
+「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」
+{{< /case-studies/quote >}}
 
+<p>Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。</p>
 
-</div>
+<p>Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」</p>
 
-<div class="banner5" >
-  <div class="banner5text">
-    「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Spotify、サイト・リライアビリティ・エンジニア、James Wen</span></div>
-</div>
+<p>またSpotifyは<a href="https://grpc.io/">gRPC</a>と<a href="https://www.envoyproxy.io/">envoy</a>を使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」</p>
 
+{{< case-studies/quote author="Spotify、サイト・リライアビリティ・エンジニア、James Wen" >}}
+「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」
+<p>どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」</p>
 
-<br><br>
-チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです -  CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。
+<p>チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです -  CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。</p>
 
-<br><br>
-SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」
-
-
-</div>
-</section>
-</body>
-</html>
+<p>SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」</p>
diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md
index 8cf85db09b..cf86ec011b 100644
--- a/content/ja/docs/concepts/architecture/cloud-controller.md
+++ b/content/ja/docs/concepts/architecture/cloud-controller.md
@@ -1,21 +1,18 @@
 ---
-title: クラウドコントローラーマネージャーとそのコンセプト
+title: クラウドコントローラーマネージャー
 content_type: concept
 weight: 40
 ---
 
 <!-- overview -->
 
-クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
+{{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
-クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
+クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーを信条としています。
 
-このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
-
-これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。
-
-![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
+{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}}
 
+cloud-controller-managerは、プラグイン機構を用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。
 
 
 
@@ -23,91 +20,49 @@ weight: 40
 
 ## 設計
 
-上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します:
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
 
-* Kubelet
-* Kubernetesコントローラーマネージャー
-* Kubernetes APIサーバー
+クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。
 
-CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります:
-
-![CCM Kube Arch](/images/docs/post-ccm-arch.png)
-
-## CCMのコンポーネント
-
-CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています:
-
- * ノードコントローラー
- * ボリュームコントローラー
- * ルートコントローラー
- * サービスコントローラー
-
-バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします:
-
-* ノードコントローラー
-* ルートコントローラー
-* サービスコントローラー
 
 {{< note >}}
-ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。
+コントロールプレーンの一部ではなく、Kubernetesの{{< glossary_tooltip text="addon" term_id="addons" >}}としてクラウドコントローラーマネージャーを実行することもできます。
 {{< /note >}}
 
-CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。
+## クラウドコントローラーマネージャーの機能 {#functions-of-the-ccm}
 
-これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。
-
-## CCMの機能群
-
-CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。
-
-### 1. Kubernetesコントローラーマネージャー
-
-CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします:
-
-* ノードコントローラー
-* ルートコントローラー
-* サービスコントローラー
+クラウドコントローラーマネージャーのコントローラーは以下を含んでいます。
 
 #### ノードコントローラー
 
-ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します:
+ノードコントローラーは、クラウドインフラストラクチャーで新しいサーバーが作成された際に、{{< glossary_tooltip text="Node" term_id="node" >}}オブジェクトを作成する責務を持ちます。ノードコントローラーは、クラウドプロバイダーのテナント内で動作しているホストの情報を取得します。ノードコントローラーは下記に示す機能を実行します:
 
-1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する
-2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する
-3. ノードのネットワークアドレスとホスト名を取得する
-4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する
+1. Nodeオブジェクトを、コントローラーがクラウドプロバイダーAPIを通じて見つけた各サーバーで初期化する
+2. Nodeオブジェクトに、ノードがデプロイされているリージョンや利用可能なリソース（CPU、メモリなど）のようなクラウド特有な情報を注釈付けやラベル付けをする
+3. ノードのホスト名とネットワークアドレスを取得する
+4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する
+
+いくつかのクラウドプロバイダーは、これをノードコントローラーと個別のノードライフサイクルコントローラーに分けて実装しています。
 
 #### ルートコントローラー
 
-ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
+ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
+
+クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。
 
 #### サービスコントローラー
 
-サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
-
-### 2. Kubelet
-
-ノードコントローラーは、kubeletのクラウドに依存した機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責務を持っていました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。
-
-この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。
-
-## プラグインメカニズム
-
-クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
-
-上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。
-
-プラグインを開発するためのさらなる情報は、[クラウドコントローラーマネージャーを開発する](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。
+{{< glossary_tooltip text="Services" term_id="service" >}}は、マネージドロードバランサー、IPアドレスネットワークパケットフィルタや対象のヘルスチェックのようなクラウドインフラストラクチャーコンポーネントのインテグレーションを行います。サービスコントローラーは、ロードバランサーや他のインフラストラクチャーコンポーネントを必要とするServiceリソースを宣言する際にそれらのコンポーネントを設定するため、クラウドプロバイダーのAPIと対話します。
 
 ## 認可
 
-このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。
+このセクションでは、クラウドコントローラーマネージャーが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。
 
-### ノードコントローラー
+### ノードコントローラー {#authorization-node-controller}
 
-ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。
+ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、readとmodifyの全権限が必要です。
 
-v1/Node:
+`v1/Node`:
 
 - Get
 - List
@@ -117,23 +72,23 @@ v1/Node:
 - Watch
 - Delete
 
-### ルートコントローラー
+### ルートコントローラー  {#authorization-route-controller}
 
 ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。
 
-v1/Node:
+`v1/Node`:
 
 - Get
 
-### サービスコントローラー
+### サービスコントローラー {#authorization-service-controller}
 
-サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。
+サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのEndpointを適切に設定します。
 
 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。
 
-サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。
+サービスのEndpointリソースを設定するため、create、list、get、watchそしてupdateの権限が必要です。
 
-v1/Service:
+`v1/Service`:
 
 - List
 - Get
@@ -141,21 +96,21 @@ v1/Service:
 - Patch
 - Update
 
-### その他
+### その他 {#authorization-miscellaneous}
 
-CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。
+クラウドコントローラーマネージャーのコア機能の実装は、Eventオブジェクトのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。
 
-v1/Event:
+`v1/Event`:
 
 - Create
 - Patch
 - Update
 
-v1/ServiceAccount:
+`v1/ServiceAccount`:
 
 - Create
 
-CCMのRBAC ClusterRoleはこのようになります:
+クラウドコントローラーマネージャーの{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRoleはこのようになります:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -219,25 +174,16 @@ rules:
   - update
 ```
 
-## ベンダー実装
 
-下記のクラウドプロバイダーがCCMを実装しています:
+## {{% heading "whatsnext" %}}
 
-* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
-* [AWS](https://github.com/kubernetes/cloud-provider-aws)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [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)
-* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)
+[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+はクラウドコントラーマネージャーの実行と管理を説明しています。
 
+どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？
 
-## クラスター管理
-
-CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。
+クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。
 
+本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。
 
+プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md
index 0a13635fe8..c2f71c9029 100644
--- a/content/ja/docs/concepts/architecture/controller.md
+++ b/content/ja/docs/concepts/architecture/controller.md
@@ -62,12 +62,10 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす
 
 ## 設計
 
-設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。
+設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。
 
 相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。
 
-たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。
-
 {{< note >}}
 同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。
 
@@ -88,3 +86,4 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作
 * 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ
 * [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ
 * 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。
+
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index 1c3d47c019..05793ebde8 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -6,27 +6,107 @@ weight: 10
 
 <!-- overview -->
 
-ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/ja/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
-
-
+Kubernetesはコンテナを_Node_上で実行されるPodに配置することで、ワークロードを実行します。
+ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。
+各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。
 
+通常、1つのクラスターで複数のノードを持ちます。学習用途やリソースの制限がある環境では、1ノードかもしれません。
+1つのノード上の[コンポーネント](/ja/docs/concepts/overview/components/#node-components)には、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}が含まれます。
 
 <!-- body -->
 
+## 管理 {#management}
+
+ノードを{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に加えるには2つの方法があります:
+
+1. ノード上のkubeletが、コントロールプレーンに自己登録する。
+2. あなた、もしくは他のユーザーが手動でNodeオブジェクトを追加する。
+
+Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう。
+
+```json
+{
+  "kind": "Node",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "10.240.79.157",
+    "labels": {
+      "name": "my-first-k8s-node"
+    }
+  }
+}
+```
+
+Kubernetesは内部的にNodeオブジェクトを作成します。 APIサーバーに登録したkubeletがノードの`metadata.name`フィールドが一致しているか検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
+
+{{< note >}}
+Kubernetesは無効なNodeのオブジェクトを保持し、それが有効になるまで検証を続けます。
+
+ヘルスチェックを止めるためには、あなた、もしくは{{< glossary_tooltip term_id="controller" text="コントローラー">}}が明示的にNodeを削除する必要があります。
+{{< /note >}}
+
+Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
+### ノードの自己登録 {#self-registration-of-nodes}
+
+kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。
+
+自己登録については、kubeletは以下のオプションを伴って起動されます:
+
+  - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス
+  - `--cloud-provider` - 自身に関するメタデータを読むために{{< glossary_tooltip text="クラウドプロバイダー" term_id="cloud-provider" >}}と会話する方法
+  - `--register-node` - 自身をAPIサーバーに自動的に登録
+  - `--register-with-taints` - 与えられた{{< glossary_tooltip text="taint" term_id="taint" >}}のリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`)。 
+  
+  `register-node`がfalseの場合、このオプションは機能しません
+  - `--node-ip` - ノードのIPアドレス
+  - `--node-labels` - ノードをクラスターに登録するときに追加する{{< glossary_tooltip text="Label" term_id="label" >}}（[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照）
+  - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定
+
+[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。
+
+### 手動によるノード管理 {#manual-node-administration}
+
+クラスター管理者は{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}を使用してNodeオブジェクトを作成および変更できます。
+
+管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。
+
+管理者は`--register-node`の設定に関係なくNodeオブジェクトを変更することができます。
+変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
+
+ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。
+例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。
+
+ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
+これは、ノードの再起動などの前の準備ステップとして役立ちます。
+
+ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します:
+
+```shell
+kubectl cordon $ノード名
+```
+
+{{< note >}}
+{{< glossary_tooltip term_id="daemonset" >}}によって作成されたPodはノード上のunschedulable属性を考慮しません。
+これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、DaemonSetがマシンに属していることを前提としているためです。
+{{< /note >}}
+
 ## ノードのステータス
 
-ノードのステータスには以下のような情報が含まれます:
+ノードのステータスは以下の情報を含みます:
 
 * [Addresses](#addresses)
 * [Conditions](#condition)
 * [CapacityとAllocatable](#capacity)
 * [Info](#info)
 
-ノードのステータスや、ノードに関するその他の詳細は、下記のコマンドを使うことで表示できます:
+`kubectl`を使用し、ノードのステータスや詳細を確認できます:
+
 ```shell
-kubectl describe node <ノード名>
+kubectl describe node <ノード名をここに挿入>
 ```
-各セクションについては、下記で説明します。
+
+出力情報の各箇所について、以下で説明します。
 
 ### Addresses
 
@@ -41,15 +121,22 @@ kubectl describe node <ノード名>
 
 `conditions`フィールドは全ての`Running`なノードのステータスを表します。例として、以下のような状態を含みます:
 
-| ノードのCondition | 概要 |
-|----------------|-------------|
-| `Ready`        | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
-| `MemoryPressure`    | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
-| `PIDPressure`    | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
-| `DiskPressure`    | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
-| `NetworkUnavailable`    | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 |
+{{< table caption = "ノードのConditionと、各condition適用時の概要" >}}
+| ノードのCondition       | 概要 |
+|----------------------|-------------|
+| `Ready`              | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
+| `DiskPressure`       | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `MemoryPressure`     | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `PIDPressure`        | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
+| `NetworkUnavailable` | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 |
+{{< /table >}}
 
-ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のようなレスポンスが表示されます。
+{{< note >}}
+コマンドラインを使用してcordonされたNodeを表示する場合、Conditionは`SchedulingDisabled`を含みます。
+`SchedulingDisabled`はKubernetesのAPIにおけるConditionではありません;その代わり、cordonされたノードはUnschedulableとしてマークされます。
+{{< /note >}}
+
+ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のような構造体が表示されます。
 
 ```json
 "conditions": [
@@ -64,14 +151,15 @@ kubectl describe node <ノード名>
 ]
 ```
 
-Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`Unknown`や`False`のままになっている場合、[kube-controller-manager](/docs/admin/kube-controller-manager/)に引数が渡され、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodたちは切り離されたノードの上で稼働を続けることになります。
+Ready conditionが`pod-eviction-timeout`({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に渡された引数)に設定された時間を超えても`Unknown`や`False`のままになっている場合、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodは切り離されたノードの上で稼働を続けることになります。
 
-バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
-
-ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。
+ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
 
+ノードのライフサイクルコントローラーがconditionを表した[taint](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を自動的に生成します。
 スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。
 
+詳細は[条件によるtaintの付与](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)を参照してください。
+
 ### CapacityとAllocatable {#capacity}
 
 ノードで利用可能なリソース（CPU、メモリ、およびノードでスケジュールできる最大Pod数）について説明します。
@@ -115,7 +203,7 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
 
 ### ノードコントローラー
 
-ノードコントローラーは、ノードのさまざまな側面を管理するKubernetesのマスターコンポーネントです。
+ノード{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、ノードのさまざまな側面を管理するKubernetesのコントロールプレーンコンポーネントです。
 
 ノードコントローラーは、ノードの存続期間中に複数の役割を果たします。1つ目は、ノードが登録されたときにCIDRブロックをノードに割り当てることです（CIDR割り当てがオンになっている場合）。
 
@@ -140,10 +228,6 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担
 
 #### 信頼性
 
-
-Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため）
-バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。
-
 ほとんどの場合、排除の速度は1秒あたり`--node-eviction-rate`に設定された数値（デフォルトは秒間0.1）です。つまり、10秒間に1つ以上のPodをノードから追い出すことはありません。
 
 特定のアベイラビリティーゾーン内のノードのステータスが異常になると、ノード排除の挙動が変わります。ノードコントローラーは、ゾーン内のノードの何%が異常（NodeReady条件がConditionUnknownまたはConditionFalseである）であるかを同時に確認します。
@@ -156,51 +240,8 @@ Kubernetes 1.4では、マスターに問題が発生した場合の対処方法
 コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。
 このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。
 
-Kubernetes 1.6以降では、ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
-さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応するtaintを追加する責務があります。
-`NoExecute`のtaint及び上述のアルファ機能に関する詳細は、[こちらのドキュメント](/docs/concepts/configuration/taint-and-toleration/)をご覧ください。
-
-バージョン1.8以降、ノードコントローラーに対してノードの状態を表すtaintを作成する責務を持たせることができます。これはバージョン1.8のアルファ機能です。
-
-### ノードの自己登録
-
-kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。
-
-自己登録については、kubeletは以下のオプションを伴って起動されます:
-
-  - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス
-  - `--cloud-provider` - 自身に関するメタデータを読むためにクラウドプロバイダーと会話する方法
-  - `--register-node` - 自身をAPIサーバーに自動的に登録
-  - `--register-with-taints` - 与えられたtaintのリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`). `register-node`がfalseの場合、このオプションは機能しません
-  - `--node-ip` - ノードのIPアドレス
-  - `--node-labels` - ノードをクラスターに登録するときに追加するラベル（1.13以降の[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照）
-  - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定
-
-[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。
-
-#### 手動によるノード管理 {#manual-node-administration}
-
-クラスター管理者はNodeオブジェクトを作成および変更できます。
-
-管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。
-
-管理者は`--register-node`の設定に関係なくNodeリソースを変更することができます。
-変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
-
-ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。
-例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。
-
-ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
-これは、ノードの再起動などの前の準備ステップとして役立ちます。たとえば、ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します:
-
-```shell
-kubectl cordon $ノード名
-```
-
-{{< note >}}
-DaemonSetコントローラーによって作成されたPodはKubernetesスケジューラーをバイパスし、ノード上のunschedulable属性を考慮しません。
-これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。
-{{< /note >}}
+ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
+さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。
 
 {{< caution >}}
 `kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
@@ -209,29 +250,29 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ
 
 ### ノードのキャパシティ
 
-ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
-通常、ノードは自分自身を登録し、Nodeオブジェクトを作成するときにキャパシティを報告します。
+Nodeオブジェクトはノードのリソースキャパシティ（CPUの数とメモリの量）を監視します。
+[自己登録](#self-registration-of-nodes)したノードは、Nodeオブジェクトを作成するときにキャパシティを報告します。
 [手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。
 
-Kubernetesスケジューラーは、ノード上のすべてのPodに十分なリソースがあることを確認します。
+Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。
 ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
-これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。
+これは、kubeletによって管理されたすべてのコンテナを含みますが、コンテナランタイムによって直接開始されたコンテナやkubeletの制御外で実行されているプロセスは含みません。
 
-Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。
+{{< note >}}
+Pod以外のプロセス用にリソースを明示的に予約したい場合は、[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)を参照してください。
+{{< /note >}}
 
 ## ノードのトポロジー
 
-{{< feature-state state="alpha" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
 `TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
-
-## APIオブジェクト
-
-NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます:
-[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
-
+詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
 
 ## {{% heading "whatsnext" %}}
 
-* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
-* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
+* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。
+* [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。
+* アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。
+* [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。
+* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。
diff --git a/content/ja/docs/concepts/cluster-administration/cloud-providers.md b/content/ja/docs/concepts/cluster-administration/cloud-providers.md
new file mode 100644
index 0000000000..f5fc0fe845
--- /dev/null
+++ b/content/ja/docs/concepts/cluster-administration/cloud-providers.md
@@ -0,0 +1,327 @@
+---
+title: クラウドプロバイダー
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。
+
+<!-- body -->
+### kubeadm
+[kubeadm](/ja/docs/reference/setup-tools/kubeadm/kubeadm/)は、Kubernetesクラスターを作成する選択肢として人気があります。
+kubeadmには、クラウドプロバイダーの設定情報を指定する設定オプションがあります。
+例えば、典型的なインツリークラウドプロバイダーは、以下のようにkubeadmを使用して設定することができます。
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: InitConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+---
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+kubernetesVersion: v1.13.0
+apiServer:
+  extraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+  extraVolumes:
+  - name: cloud
+    hostPath: "/etc/kubernetes/cloud.conf"
+    mountPath: "/etc/kubernetes/cloud.conf"
+controllerManager:
+  extraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+  extraVolumes:
+  - name: cloud
+    hostPath: "/etc/kubernetes/cloud.conf"
+    mountPath: "/etc/kubernetes/cloud.conf"
+```
+
+典型的なインツリークラウドプロバイダーは、通常、[kube-apiserver](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)および[kube-controller-manager](ja//docs/reference/command-line-tools-reference/kube-controller-manager/)、[kubelet](/ja/docs/reference/command-line-tools-reference/kubelet/)のコマンドラインで指定される`--cloud-provider`と`--cloud-config`の両方が必要です。
+プロバイダーごとに`--cloud-config`で指定されるファイルの内容についても、以下に記載します。
+
+すべての外部クラウドプロバイダーについては、以下の見出しに列挙されている個々のリポジトリーの案内に従ってください。または[すべてのリポジトリーのリスト](https://github.com/kubernetes?q=cloud-provider-&type=&language=)もご覧ください。
+
+## AWS
+ここでは、Amazon Web ServicesでKubernetesを実行する際に使用できるすべての設定について説明します。
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)リポジトリーを参照してください。
+
+### ノード名
+
+AWSクラウドプロバイダーは、AWSインスタンスのプライベートDNS名をKubernetesのNodeオブジェクトの名前として使用します。
+
+### ロードバランサー
+以下のようにアノテーションを設定することで、[外部ロードバランサー](/ja/docs/tasks/access-application-cluster/create-external-load-balancer/)をAWS上で特定の機能を利用するように構成できます。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: example
+  namespace: kube-system
+  labels:
+    run: example
+  annotations:
+     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
+     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
+spec:
+  type: LoadBalancer
+  ports:
+  - port: 443
+    targetPort: 5556
+    protocol: TCP
+  selector:
+    app: example
+```
+AWSのロードバランサーサービスには、_アノテーション_ を使ってさまざまな設定を適用することができます。以下では、AWS ELBでサポートされているアノテーションについて説明します。
+
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: アクセスログの送信間隔を指定するために使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: アクセスログを有効または無効にするためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: アクセスログ用のs3バケット名を指定するために使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: アクセスログ用のs3バケットのプレフィックスを指定するために使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: ELBに追加タグとして記録されるキーとバリューのペアのコンマ区切りリストとして指定するためにサービスで使用します。例えば、`"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`のように指定できます。
+* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: リスナーの背後にあるバックエンド(Pod)が使用するプロトコルを指定するためにサービスで使用します。`http`(デフォルト)または`https`を指定すると、接続を終端してヘッダーを解析するHTTPSリスナーが生成されます。`ssl`または`tcp`を指定すると、「生の」SSLリスナーが使われます。`http`を指定して`aws-load-balancer-ssl-cert`を使わない場合は、HTTPリスナーが使われます。
+* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: セキュアなリスナーを要求するためにサービスで使用します。値は有効な証明書のARNです。詳細は、[ELBリスナーの設定](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)を参照してください。CertARNは、IAMまたはCM証明書のARNで、例えば`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`のようになります。
+* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 接続ドレインを有効または無効にするためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 接続ドレインのタイムアウトを指定するためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: アイドル接続タイムアウトを指定するためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: クロスゾーン負荷分散を有効または無効にするためにサービスで使用されます。
+* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 作成されたELBに追加するセキュリティーグループを指定するために使用します。これは、以前にELBに割り当てられた他のすべてのセキュリティーグループを置き換えます。ここで定義されたセキュリティーグループは、サービス間で共有してはいけません。
+* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 作成されたELBに加える追加のセキュリティーグループを指定するためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-internal`: 内部ELBが必要であることを示すためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: ELB上でプロキシープロトコルを有効にするためにサービスで使用します。現在は、すべてのELBバックエンドでプロキシープロトコルを有効にすることを意味する`*`という値しか受け付けません。将来的には、特定のバックエンドでのみプロキシープロトコルを設定できるように調整できます。
+* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPSリスナーを使用するポートのコンマ区切りリストを指定するためにサービスで使用します。デフォルトは`*`(すべて)です。
+
+AWSのアノテーションの情報は、[aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)のコメントから引用しています。
+
+## Azure
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)リポジトリーを参照してください。
+
+### ノード名
+
+Azureクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名は、Azure VM名と一致しなければならないことに注意してください。
+
+## CloudStack
+
+この外部クラウドプロバイダーを利用したい場合、[apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)リポジトリーを参照してください。
+
+### ノード名
+
+CloudStackクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。
+
+## GCE
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)リポジトリーを参照してください。
+
+### ノード名
+
+GCEクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名の最初のセグメントは、GCEインスタンス名と一致しなければならないことに注意してください。例えば、`kubernetes-node-2.c.my-proj.internal`という名前のノードは、`kubernetes-node-2`という名前のインスタンスに対応していなければなりません。
+
+## HUAWEI CLOUD
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)リポジトリーを参照してください。
+
+### ノード名
+
+HUAWEI CLOUDプロバイダーは、ノードのプライベートIPアドレスをKubernetesノード名として使用します。
+ノードでkubeletを開始するときは、必ず`--hostname-override=<node private IP>`を指定してください。
+
+## OpenStack
+ここでは、OpenStackでKubernetesを実行する際に使用できるすべての設定について説明します。
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)リポジトリーを参照してください。
+
+### ノード名
+
+OpenStackクラウドプロバイダーは、インスタンス名(OpenStackのメタデータで決定されたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+インスタンス名は必ず、Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。
+kubeletがNodeオブジェクトを正常に登録できるように、インスタンス名は有効なKubernetesノード名である必要があります。
+
+### サービス
+
+KubernetesのOpenStackクラウドプロバイダーの実装では、利用可能な場合、基盤となるクラウドからこれらのOpenStackのサービスの使用をサポートします。
+
+| サービス名                 | APIバージョン    | 必須か    |
+|--------------------------|----------------|----------|
+| Block Storage (Cinder)   | V1†, V2, V3    | No       |
+| Compute (Nova)           | V2             | No       |
+| Identity (Keystone)      | V2‡,  V3       | Yes      |
+| Load Balancing (Neutron) | V1§, V2        | No       |
+| Load Balancing (Octavia) | V2             | No       |
+
+† Block Storage V1 APIのサポートは非推奨ですが、Kubernetes 1.9ではBlock Storage V3 APIのサポートが追加されました。
+
+‡ Identity V2 APIのサポートは非推奨となり、将来のリリースでプロバイダーから削除される予定です。「Queens」のリリース時点で、OpenStackはIdentity V2 APIを公開しません。
+
+§ Load Balancing V1 APIのサポートは、Kubernetes 1.9で削除されました。
+
+サービスディスカバリーは、プロバイダー設定で提供される`auth-url`を使用して、OpenStack Identity(Keystone)が管理するサービスカタログを一覧表示することで実現されます。
+プロバイダーは、Keystone以外のOpenStackサービスが利用できなくなった場合には、機能を緩やかに低下させ、影響を受ける機能のサポートを放棄します。
+特定の機能は、基盤となるクラウドでNeutronが公開している拡張機能のリストに基づいて有効または無効にされます。
+
+### cloud.conf
+Kubernetesはcloud.confというファイルを介して、OpenStackとのやりとり方法を知っています。
+これは、KubernetesにOpenStack認証エンドポイントの認証情報と場所を提供するファイルです。
+ファイル内に以下の詳細を指定することで、cloud.confファイルを作成できます。
+
+#### 典型的な設定
+以下の設定例は、最も頻繁に設定が必要な値に関するものです。
+プロバイダーをOpenStackクラウドのKeystoneエンドポイントに指定し、そのエンドポイントでの認証方法の詳細を提供し、さらにロードバランサーを設定します。
+
+```yaml
+[Global]
+username=user
+password=pass
+auth-url=https://<keystone_ip>/identity/v3
+tenant-id=c869168a828847f39f7f06edd7305637
+domain-id=2a73b8f597c04551a0fdc8e95544be8a
+
+[LoadBalancer]
+subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
+```
+
+##### グローバル
+これらのOpenStackプロバイダーの設定オプションは、グローバル設定に関連しており、`cloud.conf`ファイルの`[Global]`セクションに記述する必要があります。
+
+* `auth-url`(必死): 認証に使用するKeystone APIのURLです。OpenStackのコントロールパネルでは、Access and Security > API Access > Credentialsで確認できます。
+* `username`(必須): Keystoneに設定されている有効なユーザーのユーザー名を参照します。
+* `password`(必須): Keystoneで設定された有効なユーザーのパスワードを参照します。
+* `tenant-id`(必須): リソースを作成するプロジェクトのIDを指定するために使用します。
+* `tenant-name`(任意): リソースを作成するプロジェクトの名前を指定します。
+* `trust-id`(任意): 認証に使用するtrustの識別子を指定するために使用します。trustは、ユーザー(委託者)が他のユーザー(受託者)に役割を委譲したり、受託者が委託者になりすますことを許可したりする権限を表します。利用可能なtrustは、Keystone APIの`/v3/OS-TRUST/trusts`エンドポイントの下にあります。
+* `domain-id`(任意): ユーザーが所属するドメインのIDを指定するために使用します。
+* `domain-name`(任意): ユーザーが所属するドメイン名を指定するために使用します。
+* `region`(任意): マルチリージョンのOpenStackクラウド上で実行する際に使うリージョンの識別子を指定するために使用します。リージョンはOpenStackデプロイメントの一般的な区分です。リージョンには厳密な地理的な意味合いはありませんが、デプロイメントでは`us-east`のような地理的な名前をリージョンの識別子に使うことができます。利用可能なリージョンはKeystone APIの`/v3/regions`エンドポイントの下にあります。
+* `ca-file`(任意): カスタムCAファイルのパスを指定するために使用します。
+
+
+テナントをプロジェクトに変更するKeystone V3を使用している場合、`tenant-id`の値は自動的にAPIのプロジェクト構造体にマッピングされます。
+
+##### ロードバランサー
+これらのOpenStackプロバイダーの設定オプションは、ロードバランサー設定に関連しており、`cloud.conf`ファイルの`[LoadBalancer]`セクションに記述する必要があります。
+
+* `lb-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`または`v2`です。値が指定されていない場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。
+* `use-octavia`(任意): Octavia LBaaS V2サービスカタログエンドポイントを探して、利用するかどうかを決定するために使用します。有効な値は`true`または`false`です。`true`が指定され、Octaiva LBaaS V2エントリーが見つからなかった場合、プロバイダーはフォールバックして代わりにNeutron LBaaS V2エンドポイントを見つけようとします。デフォルト値は`false` です。
+* `subnet-id`(任意): ロードバランサーを作成したいサブネットのIDを指定します。Network > Networksにあります。サブネットを取得するには、それぞれのネットワークをクリックします。
+* `floating-network-id`(任意): 指定した場合、ロードバランサーのフローティングIPを作成します。
+* `lb-method`(任意): ロードバランサープールのメンバー間で負荷分散させるアルゴリズムを指定するために使用します。値には`ROUND_ROBIN`、`LEAST_CONNECTIONS`、`SOURCE_IP`を指定できます。何も指定しない場合のデフォルトの動作は`ROUND_ROBIN` です。
+* `lb-provider`(任意): ロードバランサーのプロバイダーを指定するために使用します。指定しない場合は、Neutronで設定されたデフォルトのプロバイダサービスが使用されます。
+* `create-monitor`(任意): Neutronロードバランサーのヘルスモニターを作成するかどうかを表します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`monitor-delay`、`monitor-timeout`、`monitor-max-retries`も設定しなければなりません。
+* `monitor-delay`(任意): ロードバランサーのメンバーにプローブを送信するまでの時間です。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。
+* `monitor-timeout`(任意): モニタリングがタイムアウトする前にpingの応答を待つための最大の時間です。この値はdelay値よりも小さくする必要があります。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。
+* `monitor-max-retries`(任意): ロードバランサーメンバーのステータスをINACTIVEに変更する前に許容されるpingの失敗の数です。1から10の間の数値でなければなりません。
+* `manage-security-groups`(任意): ロードバランサーがセキュリティーグループのルールを自動的に管理するかどうかを決定します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`node-security-group`も指定しなければなりません。
+* `node-security-group`(任意): 管理するセキュリティーグループのIDです。
+
+##### ブロックストレージ
+これらのOpenStackプロバイダーの設定オプションは、ブロックストレージ設定に関連しており、`cloud.conf`ファイルの`[BlockStorage]`セクションに記述する必要があります。
+
+* `bs-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`、`v2`、`v3`、`auto`です。`auto`が指定された場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。何も指定しない場合のデフォルト値は`auto`です。
+* `trust-device-path`(任意): ほとんどのシナリオでは、Cinderが提供するブロックデバイス名(例: `/dev/vda`)は信頼できません。このブール値はこの動作をトグルします。`true`に設定すると、Cinderが提供するブロックデバイス名を信頼することになります。デフォルト値の`false`は、シリアル番号と`/dev/disk/by-id`のマッピングに基づいてデバイスのパスを検出します。
+* `ignore-volume-az`(任意): Cinderボリュームをアタッチする際のアベイラビリティーゾーンの使用に影響を与えます。NovaとCinderのアベイラビリティーゾーンが異なる場合は、`true`に設定する必要があります。これは、Novaのアベイラビリティーゾーンが多くあるにも関わらず、Cinderのアベイラビリティーゾーンが1つしかない場合によく見られます。デフォルト値は以前のリリースで使用されていた動作を維持するために`false`になっていますが、将来的には変更される可能性があります。
+* `node-volume-attach-limit`(任意): ノードにアタッチできるボリュームの最大数で、デフォルトはCinderの256です。
+
+エンドポイントを区別するためにポートではなくパスを使用しているOpenStackデプロイメントにおいて、Kubernetesのバージョン1.8以下をデプロイする際、明示的に`bs-version`パラメーターの設定が必要な場合があります。パスベースのエンドポイントは`http://foo.bar/volume`の形式であり、ポートベースのエンドポイントは`http://foo.bar:xxx`の形式です。
+
+パスベースのエンドポイントを使う環境で、Kubernetesが古い自動検出ロジックを使用している場合、ボリュームの切り離しを試みると`BS API version autodetection failed.`というエラーが返されます。この問題を回避するには、クラウドプロバイダー設定に以下のように追記することで、Cinder APIバージョン2を強制的に使用することができます。
+
+```yaml
+[BlockStorage]
+bs-version=v2
+```
+
+##### メタデータ
+これらのOpenStackプロバイダーの設定オプションは、メタデータ設定に関連しており、`cloud.conf`ファイルの`[Metadata]`セクションに記述する必要があります。
+
+* `search-order`(任意): この設定のキーは、プロバイダーが実行するインスタンスに関連するメタデータの取得方法に影響します。デフォルト値の`configDrive,metadataService`について、プロバイダーは、コンフィグドライブが利用可能な場合は最初にインスタンスに関連するメタデータをそこから取得し、次にメタデータサービスから取得します。代替値は以下の通りです。
+  * `configDrive` - コンフィグドライブからのみ、インスタンスのメタデータを取得します。
+  * `metadataService` - メタデータサービスからのみ、インスタンスのメタデータを取得します。
+  * `metadataService,configDrive` - 最初にメタデータサービスからインスタンスのメタデータを取得し、次にコンフィグドライブから取得します。
+
+  コンフィグドライブ上のメタデータは時間の経過とともに陳腐化する可能性がありますが、メタデータサービスは常に最新の情報を提供するため、この動作を調整するのが望ましいです。しかし、すべてのOpenStackクラウドがコンフィグドライブとメタデータサービスの両方を提供しているわけではなく、どちらか一方しか利用できない場合もあるため、デフォルトでは両方をチェックするようになっています。
+
+##### ルート
+これらのOpenStackプロバイダーの設定オプションは、[kubenet](/ja/docs/concepts/cluster-administration/network-plugins/#kubenet)のKubernetesネットワークプラグインに関連しており、`cloud.conf`ファイルの`[Route]`セクションに記述する必要があります。
+
+
+* `router-id`(任意): 基盤となるクラウドのNeutronデプロイメントが`extraroutes`拡張機能をサポートしている場合は、`router-id`を使用してルートを追加するルーターを指定します。選択したルーターは、クラスターノードを含むプライベートネットワークにまたがっていなければなりません(通常、ノードネットワークは1つしかないので、この値はノードネットワークのデフォルトルーターになります)。この値は、OpenStackで[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)を使用するために必要です。
+
+## OVirt
+
+### ノード名
+
+OVirtクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名は、VMのFQDN(`<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`の下でOVirtによって報告されたもの)と一致しなければならないことに注意してください。
+
+## Photon
+
+### ノード名
+
+Photonクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名はPhoton VM名と一致しなければならないことに注意してください(もしくは、`--cloud-config`で`overrideIP`がtrueに設定されている場合は、Kubernetesノード名はPhoton VMのIPアドレスと一致しなければなりません)。
+
+## vSphere
+
+{{< tabs name="vSphere cloud provider" >}}
+{{% tab name="vSphere 6.7U3以上" %}}
+vSphere 6.7U3以上のすべてのvSphereデプロイメントでは、[external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere)と[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)の使用を推奨します。クイックスタートガイドについては、[Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)を参照してください。
+{{% /tab %}}
+{{% tab name="vSphere 6.7U3未満" %}}
+vSphere 6.7U3未満を実行している場合は、インツリーのvSphereクラウドプロバイダーを推奨します。クイックスタートガイドについては、[Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)を参照してください。
+{{% /tab %}}
+{{< /tabs >}}
+
+vSphereクラウドプロバイダーの詳細なドキュメントについては、[vSphereクラウドプロバイダーのドキュメントサイト](https://cloud-provider-vsphere.sigs.k8s.io)を参照してください。
+
+## IBM Cloud Kubernetes Service
+
+### コンピュートノード
+IBM Cloud Kubernetes Serviceプロバイダーを使用することで、仮想ノードと物理ノード(ベアメタル)を混在させたクラスターを単一のゾーン、またはリージョン内の複数のゾーンにまたがって作成することができます。詳細については、[Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)を参照してください。
+
+Kubernetes Nodeオブジェクトの名前は、IBM Cloud Kubernetes ServiceワーカーノードインスタンスのプライベートIPアドレスです。
+
+### ネットワーク
+IBM Cloud Kubernetes Serviceプロバイダーは、高品質なネットワークパフォーマンスとノードのネットワーク分離のためにVLANを提供します。カスタムファイアウォールやCalicoネットワークポリシーを設定して、クラスターにセキュリティーの追加レイヤーを加えたり、VPNを使用してクラスターをオンプレミスデータセンターに接続したりすることができます。詳細については、[Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)を参照してください。
+
+アプリケーションをパブリックまたはクラスター内で公開するには、NodePort、LoadBalancer、Ingressサービスを利用できます。また、Ingressアプリケーションのロードバランサーをアノテーションでカスタマイズすることもできます。詳細については、[Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)を参照してください。
+
+### ストレージ
+IBM Cloud Kubernetes Serviceプロバイダーは、Kubernetesネイティブの永続ボリュームを活用して、ユーザーがファイル、ブロック、およびクラウドオブジェクトストレージをアプリケーションにマウントできるようにします。また、データの永続ストレージにDatabase as a Serviceやサードパーティーのアドオンを使用することもできます。詳しくは、[Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)を参照してください。
+
+## Baidu Cloud Container Engine
+
+### ノード名
+
+Baiduクラウドプロバイダーは、ノードのプライベートIPアドレス(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名はBaidu VMのプライベートIPと一致しなければならないことに注意してください。
+
+## Tencent Kubernetes Engine
+
+この外部クラウドプロバイダーを利用したい場合、[TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)リポジトリーを参照してください。
+
+### ノード名
+
+Baiduクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名はTencent VMのプライベートIPと一致しなければならないことに注意してください。
+
+## Alibaba Cloud Kubernetes
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)リポジトリーを参照してください。
+
+### ノード名
+
+Alibaba Cloudではノード名の書式は必要ありませんが、kubeletでは`--provider-id=${REGION_ID}.${INSTANCE_ID}`を追加する必要があります。パラメーター`${REGION_ID}`はKubernetesのリージョンのIDを、`${INSTANCE_ID}`はAlibaba ECS(Elastic Compute Service)のIDを表します。
+
+### ロードバランサー
+
+[アノテーション](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)を設定することで、Alibaba Cloudの特定の機能を使用するように外部のロードバランサーを設定できます。
diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md
new file mode 100644
index 0000000000..90f96547d5
--- /dev/null
+++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md
@@ -0,0 +1,454 @@
+---
+reviewers:
+- 
+title: リソースの管理
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+アプリケーションをデプロイし、Serviceを介して外部に公開できました。さて、どうしますか？Kubernetesは、スケーリングや更新など、アプリケーションのデプロイを管理するための多くのツールを提供します。
+我々が取り上げる機能についての詳細は[設定ファイル](/ja/docs/concepts/configuration/overview/)と[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)について詳細に説明します。
+
+
+
+
+<!-- body -->
+
+## リソースの設定を管理する
+
+多くのアプリケーションではDeploymentやServiceなど複数のリソースの作成を要求します。複数のリソースの管理は、同一のファイルにひとまとめにしてグループ化すると簡単になります(YAMLファイル内で`---`で区切る)。
+例えば:
+
+{{< codenew file="application/nginx-app.yaml" >}}
+
+複数のリソースは単一のリソースと同様の方法で作成できます。
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml
+```
+
+```shell
+service/my-nginx-svc created
+deployment.apps/my-nginx created
+```
+
+リソースは、ファイル内に記述されている順番通りに作成されます。そのため、Serviceを最初に指定するのが理想です。スケジューラーがServiceに関連するPodを、Deploymentなどのコントローラーによって作成されるときに確実に拡散できるようにするためです。
+
+`kubectl apply`もまた、複数の`-f`による引数指定を許可しています。
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
+```
+
+個別のファイルに加えて、-fの引数としてディレクトリ名も指定できます:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/nginx/
+```
+
+`kubectl`は`.yaml`、`.yml`、`.json`といったサフィックスの付くファイルを読み込みます。
+
+同じマイクロサービス、アプリケーションティアーのリソースは同一のファイルにまとめ、アプリケーションに関するファイルをグループ化するために、それらのファイルを同一のディレクトリに配備するのを推奨します。アプリケーションのティアーがDNSを通じて互いにバインドされると、アプリケーションスタックの全てのコンポーネントをひとまとめにして簡単にデプロイできます。
+
+リソースの設定ソースとして、URLも指定できます。githubから取得した設定ファイルから直接手軽にデプロイができます:
+
+```shell
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
+```
+
+```shell
+deployment.apps/my-nginx created
+```
+
+## kubectlによる一括操作
+
+`kubectl`が一括して実行できる操作はリソースの作成のみではありません。作成済みのリソースの削除などの他の操作を実行するために、設定ファイルからリソース名を取得することができます。
+
+```shell
+kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
+```
+
+```shell
+deployment.apps "my-nginx" deleted
+service "my-nginx-svc" deleted
+```
+
+2つのリソースだけを削除する場合には、コマンドラインでリソース/名前というシンタックスを使うことで簡単に指定できます。
+
+```shell
+kubectl delete deployments/my-nginx services/my-nginx-svc
+```
+
+さらに多くのリソースに対する操作では、リソースをラベルでフィルターするために`-l`や`--selector`を使ってセレクター(ラベルクエリ)を指定するのが簡単です:
+
+```shell
+kubectl delete deployment,services -l app=nginx
+```
+
+```shell
+deployment.apps "my-nginx" deleted
+service "my-nginx-svc" deleted
+```
+
+`kubectl`は同様のシンタックスでリソース名を出力するので、`$()`や`xargs`を使ってパイプで操作するのが容易です:
+
+```shell
+kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
+```
+
+```shell
+NAME           TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
+my-nginx-svc   LoadBalancer   10.0.0.208   <pending>     80/TCP       0s
+```
+
+上記のコマンドで、最初に`examples/application/nginx/`配下でリソースを作成し、`-o name`という出力フォーマットにより、作成されたリソースの名前を表示します(各リソースをresource/nameという形式で表示)。そして"service"のみ`grep`し、`kubectl get`を使って表示させます。
+
+あるディレクトリ内の複数のサブディレクトリをまたいでリソースを管理するような場合、`--filename,-f`フラグと合わせて`--recursive`や`-R`を指定することでサブディレクトリに対しても再帰的に操作が可能です。
+
+例えば、開発環境用に必要な全ての{{< glossary_tooltip text="マニフェスト" term_id="manifest" >}}をリソースタイプによって整理している`project/k8s/development`というディレクトリがあると仮定します。
+
+```
+project/k8s/development
+├── configmap
+│   └── my-configmap.yaml
+├── deployment
+│   └── my-deployment.yaml
+└── pvc
+    └── my-pvc.yaml
+```
+
+デフォルトでは、`project/k8s/development`における一括操作は、どのサブディレクトリも処理せず、ディレクトリの第1階層で処理が止まります。下記のコマンドによってこのディレクトリ配下でリソースを作成しようとすると、エラーが発生します。
+
+```shell
+kubectl apply -f project/k8s/development
+```
+
+```shell
+error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
+```
+
+代わりに、下記のように`--filename,-f`フラグと合わせて`--recursive`や`-R`を指定してください:
+
+```shell
+kubectl apply -f project/k8s/development --recursive
+```
+
+```shell
+configmap/my-config created
+deployment.apps/my-deployment created
+persistentvolumeclaim/my-pvc created
+```
+
+`--recursive`フラグは`kubectl {create,get,delete,describe,rollout}`などのような`--filename,-f`フラグを扱うどの操作でも有効です。
+
+また、`--recursive`フラグは複数の`-f`フラグの引数を指定しても有効です。
+
+```shell
+kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive
+```
+
+```shell
+namespace/development created
+namespace/staging created
+configmap/my-config created
+deployment.apps/my-deployment created
+persistentvolumeclaim/my-pvc created
+```
+
+`kubectl`についてさらに知りたい場合は、[kubectlの概要](/docs/reference/kubectl/overview/)を参照してください。
+
+## ラベルを有効に使う
+
+これまで取り上げた例では、リソースに対して最大1つのラベルを適用してきました。リソースのセットを他のセットと区別するために、複数のラベルが必要な状況があります。
+
+例えば、異なるアプリケーション間では、異なる`app`ラベルを使用したり、[ゲストブックの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)のようなマルチティアーのアプリケーションでは、各ティアーを区別する必要があります。frontendというティアーでは下記のラベルを持ちます。:
+
+```yaml
+     labels:
+        app: guestbook
+        tier: frontend
+```
+
+Redisマスターやスレーブでは異なる`tier`ラベルを持ち、加えて`role`ラベルも持つことでしょう。:
+
+```yaml
+     labels:
+        app: guestbook
+        tier: backend
+        role: master
+```
+
+そして
+
+```yaml
+     labels:
+        app: guestbook
+        tier: backend
+        role: slave
+```
+
+ラベルを使用すると、ラベルで指定された任意の次元に沿ってリソースを分割できます。
+
+```shell
+kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
+kubectl get pods -Lapp -Ltier -Lrole
+```
+
+```shell
+NAME                           READY     STATUS    RESTARTS   AGE       APP         TIER       ROLE
+guestbook-fe-4nlpb             1/1       Running   0          1m        guestbook   frontend   <none>
+guestbook-fe-ght6d             1/1       Running   0          1m        guestbook   frontend   <none>
+guestbook-fe-jpy62             1/1       Running   0          1m        guestbook   frontend   <none>
+guestbook-redis-master-5pg3b   1/1       Running   0          1m        guestbook   backend    master
+guestbook-redis-slave-2q2yf    1/1       Running   0          1m        guestbook   backend    slave
+guestbook-redis-slave-qgazl    1/1       Running   0          1m        guestbook   backend    slave
+my-nginx-divi2                 1/1       Running   0          29m       nginx       <none>     <none>
+my-nginx-o0ef1                 1/1       Running   0          29m       nginx       <none>     <none>
+```
+
+```shell
+kubectl get pods -lapp=guestbook,role=slave
+```
+```shell
+NAME                          READY     STATUS    RESTARTS   AGE
+guestbook-redis-slave-2q2yf   1/1       Running   0          3m
+guestbook-redis-slave-qgazl   1/1       Running   0          3m
+```
+
+## Canary deployments カナリアデプロイ
+
+複数のラベルが必要な他の状況として、異なるリリース間でのDeploymentや、同一コンポーネントの設定を区別することが挙げられます。よく知られたプラクティスとして、本番環境の実際のトラフィックを受け付けるようにするために、新しいリリースを完全にロールアウトする前に、新しい*カナリア版*のアプリケーションを過去のリリースと合わせてデプロイする方法があります。
+
+例えば、異なるリリースバージョンを分けるために`track`ラベルを使用できます。
+
+主要な安定板のリリースでは`track`ラベルに`stable`という値をつけることがあるでしょう。:
+
+```yaml
+     name: frontend
+     replicas: 3
+     ...
+     labels:
+        app: guestbook
+        tier: frontend
+        track: stable
+     ...
+     image: gb-frontend:v3
+```
+
+そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。
+
+```yaml
+     name: frontend-canary
+     replicas: 1
+     ...
+     labels:
+        app: guestbook
+        tier: frontend
+        track: canary
+     ...
+     image: gb-frontend:v4
+```
+
+frontend Serviceは、トラフィックを両方のアプリケーションにリダイレクトさせるために、両方のアプリケーションに共通したラベルのサブセットを選択して両方のレプリカを扱えるようにします。:
+
+```yaml
+  selector:
+     app: guestbook
+     tier: frontend
+```
+
+安定版とカナリア版リリースで本番環境の実際のトラフィックを転送する割合を決めるため、双方のレプリカ数を変更できます(このケースでは3対1)。
+最新版のリリースをしても大丈夫な場合、安定版のトラックを新しいアプリケーションにして、カナリア版を削除します。
+
+さらに具体的な例については、[tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)を参照してください。
+
+## ラベルの更新
+
+新しいリソースを作成する前に、既存のPodと他のリソースのラベルの変更が必要な状況があります。これは`kubectl label`で実行できます。
+例えば、全てのnginx Podを frontendティアーとしてラベル付けするには、下記のコマンドを実行するのみです。
+
+```shell
+kubectl label pods -l app=nginx tier=fe
+```
+
+```shell
+pod/my-nginx-2035384211-j5fhi labeled
+pod/my-nginx-2035384211-u2c7e labeled
+pod/my-nginx-2035384211-u3t6x labeled
+```
+
+これは最初に"app=nginx"というラベルのついたPodをフィルターし、そのPodに対して"tier=fe"というラベルを追加します。
+ラベル付けしたPodを確認するには、下記のコマンドを実行してください。
+
+```shell
+kubectl get pods -l app=nginx -L tier
+```
+```shell
+NAME                        READY     STATUS    RESTARTS   AGE       TIER
+my-nginx-2035384211-j5fhi   1/1       Running   0          23m       fe
+my-nginx-2035384211-u2c7e   1/1       Running   0          23m       fe
+my-nginx-2035384211-u3t6x   1/1       Running   0          23m       fe
+```
+
+このコマンドでは"app=nginx"というラベルのついた全てのPodを出力し、Podのtierという項目も表示します(`-L`または`--label-columns`で指定)。
+
+さらなる情報は、[ラベル](/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。
+
+## アノテーションの更新
+
+リソースに対してアノテーションを割り当てたい状況があります。アノテーションは、ツール、ライブラリなどのAPIクライアントによって取得するための任意の非識別メタデータです。アノテーションの割り当ては`kubectl annotate`で可能です。例:
+
+```shell
+kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
+kubectl get pods my-nginx-v4-9gw19 -o yaml
+```
+```shell
+apiVersion: v1
+kind: pod
+metadata:
+  annotations:
+    description: my frontend running nginx
+...
+```
+
+さらなる情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。
+
+## アプリケーションのスケール
+
+アプリケーションの負荷が増減するとき、`kubectl`を使って簡単にスケールできます。例えば、nginxのレプリカを3から1に減らす場合、下記を実行します:
+
+```shell
+kubectl scale deployment/my-nginx --replicas=1
+```
+```shell
+deployment.apps/my-nginx scaled
+```
+
+実行すると、Deploymentによって管理されるPod数が1となります。
+
+```shell
+kubectl get pods -l app=nginx
+```
+```shell
+NAME                        READY     STATUS    RESTARTS   AGE
+my-nginx-2035384211-j5fhi   1/1       Running   0          30m
+```
+
+システムに対してnginxのレプリカ数を自動で選択させるには、下記のように1から3の範囲で指定します。:
+
+```shell
+kubectl autoscale deployment/my-nginx --min=1 --max=3
+```
+```shell
+horizontalpodautoscaler.autoscaling/my-nginx autoscaled
+```
+
+実行すると、nginxのレプリカは必要に応じて自動でスケールアップ、スケールダウンします。
+
+さらなる情報は、[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)、[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)を参照してください。
+
+
+## リソースの直接的アップデート
+
+場合によっては、作成したリソースに対して処理を中断させずに更新を行う必要があります。
+
+### kubectl apply
+
+開発者が設定するリソースをコードとして管理しバージョニングも行えるように、設定ファイルのセットをソースによって管理する方法が推奨されています。
+この場合、クラスターに対して設定の変更をプッシュするために[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)を使用できます。
+
+このコマンドは、リソース設定の過去のバージョンと、今適用した変更を比較し、差分に現れないプロパティーに対して上書き変更することなくクラスターに適用させます。
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
+deployment.apps/my-nginx configured
+```
+
+注意として、前回の変更適用時からの設定の変更内容を決めるため、`kubectl apply`はリソースに対してアノテーションを割り当てます。変更が実施されると`kubectl apply`は、1つ前の設定内容と、今回変更しようとする入力内容と、現在のリソースの設定との3つの間で変更内容の差分をとります。
+
+現在、リソースはこのアノテーションなしで作成されました。そのため、最初の`kubectl paply`の実行においては、与えられたにゅうチョクト、現在のリソースの設定の2つの間の差分が取られ、フォールバックします。この最初の実行の間、リソースが作成された時にプロパティーセットの削除を検知できません。この理由により、プロパティーの削除はされません。
+
+`kubectl apply`の実行後の全ての呼び出しや、`kubectl replace`や`kubectl edit`などの設定を変更する他のコマンドではアノテーションを更新します。`kubectl apply`した後の全ての呼び出しにおいて3-wayの差分取得によってプロパティの検知と削除を実施します。
+
+### kubectl edit
+
+その他に、`kubectl edit`によってリソースの更新もできます。:
+
+```shell
+kubectl edit deployment/my-nginx
+```
+
+このコマンドは、最初にリソースを`get`し、テキストエディタでリソースを編集し、更新されたバージョンでリソースを`apply`します。:
+
+```shell
+kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
+vi /tmp/nginx.yaml
+# yamlファイルを編集し、ファイルを保存します。
+
+kubectl apply -f /tmp/nginx.yaml
+deployment.apps/my-nginx configured
+
+rm /tmp/nginx.yaml
+```
+
+このコマンドによってより重大な変更を簡単に行えます。注意として、あなたの`EDITOR`や`KUBE_EDITOR`といった環境変数も指定できます。
+
+さらなる情報は、[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit)を参照してください。
+
+### kubectl patch
+
+APIオブジェクトの更新には`kubectl patch`を使うことができます。このコマンドはJSON patch、JSON merge patch、戦略的merge patchをサポートしています。
+[kubectl patchを使ったAPIオブジェクトの更新](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)や[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)を参照してください。
+
+## 破壊的なアップデート
+
+一度初期化された後、更新できないようなリソースフィールドの更新が必要な場合や、Deploymentによって作成され、壊れている状態のPodを修正するなど、再帰的な変更を即座に行いたい場合があります。このようなフィールドを変更するため、リソースの削除と再作成を行う`replace --force`を使用してください。このケースでは、シンプルに元の設定ファイルを修正するのみです。:
+
+```shell
+kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
+```
+```shell
+deployment.apps/my-nginx deleted
+deployment.apps/my-nginx replaced
+```
+
+## サービス停止なしでアプリケーションを更新する
+
+ある時点で、前述したカナリアデプロイのシナリオにおいて、新しいイメージやイメージタグを指定することによって、デプロイされたアプリケーションを更新が必要な場合があります。`kubectl`ではいくつかの更新操作をサポートしており、それぞれの操作が異なるシナリオに対して適用可能です。
+
+ここでは、Deploymentを使ってアプリケーションの作成と更新についてガイドします。
+
+まずnginxのバージョン1.14.2を稼働させていると仮定します。:
+
+```shell
+kubectl create deployment my-nginx --image=nginx:1.14.2
+```
+```shell
+deployment.apps/my-nginx created
+```
+
+レプリカ数を3にします(新旧のリビジョンは混在します)。:
+```shell
+kubectl scale deployment my-nginx --current-replicas=1 --replicas=3
+```
+```
+deployment.apps/my-nginx scaled
+```
+
+バージョン1.16.1に更新するには、上述したkubectlコマンドを使って`.spec.template.spec.containers[0].image`の値を`nginx:1.14.2`から`nginx:1.16.1`に変更するだけでできます。
+
+```shell
+kubectl edit deployment/my-nginx
+```
+
+できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/docs/concepts/workloads/controllers/deployment/)を参照してください。
+
+
+
+## {{% heading "whatsnext" %}}
+
+- [アプリケーションの調査とデバッグのための`kubectl`の使用方法](/docs/tasks/debug-application-cluster/debug-application-introspection/)について学んでください。
+- [設定のベストプラクティスとTIPS](/ja/docs/concepts/configuration/overview/)を参照してください。
+
diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md
index 53b899dc32..05af3690d1 100644
--- a/content/ja/docs/concepts/cluster-administration/networking.md
+++ b/content/ja/docs/concepts/cluster-administration/networking.md
@@ -9,7 +9,7 @@ weight: 50
 ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。
 Kubernetesには、4つの異なる対応すべきネットワークの問題があります:
 
-1. 高度に結合されたコンテナ間の通信: これは、[Pod](/ja/docs/concepts/workloads/pods/pod/)および`localhost`通信によって解決されます。
+1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pod" term_id="pod" >}}および`localhost`通信によって解決されます。
 2. Pod間の通信: 本ドキュメントの主な焦点です。
 3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
 4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。
@@ -24,7 +24,7 @@ Kubernetesは、言ってしまえばアプリケーション間でマシンを
 
 動的ポート割り当てはシステムに多くの複雑さをもたらします。すべてのアプリケーションはパラメータとしてポートを管理する必要があり、APIサーバーにて動的なポート番号を設定値として注入する方法が必要となり、各サービスはお互いにお互いを見つける方法が必要です。Kubernetesはこれに対処するのではなく、別のアプローチを取ります。
 
-## Kubernetesのネットワークモデル
+## Kubernetesのネットワークモデル {#the-kubernetes-network-model}
 
 すべての`Pod`は独自のIPアドレスを持ちます。これは、`Pod`間のリンクを明示的に作成する必要がなく、コンテナポートをホストポートにマッピングする必要がほとんどないことを意味します。こうすることで、ポート割り当て、名前解決、サービスディスカバリー、負荷分散、アプリケーション設定、および移行の観点から、`Pod`をVMまたは物理ホストと同様に扱うことができる、クリーンで後方互換性のあるモデルを生み出しています。
 
@@ -67,7 +67,7 @@ Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to i
 
 ### AOS from Apstra
 
-[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform.  AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs.
+[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform.  AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs.
 
 The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems.  These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs).  AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment.
 
@@ -75,7 +75,7 @@ AOS has a rich set of REST API endpoints that enable Kubernetes to quickly chang
 
 AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux.
 
-Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/
+Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/
 
 ### AWS VPC CNI for Kubernetes
 
@@ -97,7 +97,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https:/
 
 With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed.
 
-BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
+BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
 
 ### Cilium
 
@@ -109,7 +109,7 @@ 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://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](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](/ja/docs/concepts/cluster-administration/networking/#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.
 
@@ -131,11 +131,11 @@ network complexity required to deploy Kubernetes at scale within AWS.
 
 ### Contiv
 
-[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced.
+[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
 
 ### Contrail / Tungsten Fabric
 
-[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
+[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
 
 ### DANM
 
@@ -216,7 +216,7 @@ traffic to the internet.
 
 ### Kube-router
 
-[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
+[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
 
 ### L2 networks and linux bridging
 
@@ -226,8 +226,8 @@ Note that these instructions have only been tried very casually - it seems to
 work, but has not been thoroughly tested.  If you use this technique and
 perfect the process, please let us know.
 
-Follow the "With Linux Bridge devices" section of [this very nice
-tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
+Follow the "With Linux Bridge devices" section of
+[this very nice tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
 Lars Kellogg-Stedman.
 
 ### Multus (a Multi Network plugin)
@@ -236,6 +236,10 @@ Lars Kellogg-Stedman.
 
 Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
 
+### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin)
+
+[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
+
 ### NSX-T
 
 [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
@@ -244,7 +248,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p
 
 ### Nuage Networks VCS (Virtualized Cloud Services)
 
-[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
+[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
 
 The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
 
@@ -264,7 +268,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
 
 ### Project Calico
 
-[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
+[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
 
 Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)).  Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking.  Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
 
@@ -272,7 +276,7 @@ Calico can also be run in policy enforcement mode in conjunction with other netw
 
 ### Romana
 
-[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
+[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
 
 ### Weave Net from Weaveworks
 
diff --git a/content/ja/docs/concepts/cluster-administration/proxies.md b/content/ja/docs/concepts/cluster-administration/proxies.md
new file mode 100644
index 0000000000..4738993ab0
--- /dev/null
+++ b/content/ja/docs/concepts/cluster-administration/proxies.md
@@ -0,0 +1,66 @@
+---
+title: Kubernetesのプロキシー
+content_type: concept
+weight: 90
+---
+
+<!-- overview -->
+このページではKubernetesと併用されるプロキシーについて説明します。
+
+
+<!-- body -->
+
+## プロキシー
+
+Kubernetesを使用する際に、いくつかのプロキシーを使用する場面があります。
+
+1. [kubectlのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
+
+    - ユーザーのデスクトップ上かPod内で稼働します
+    - ローカルホストのアドレスからKubernetes apiserverへのプロキシーを行います
+    - クライアントからプロキシー間ではHTTPを使用します
+    - プロキシーからapiserverへはHTTPSを使用します
+    - apiserverの場所を示します
+    - 認証用のヘッダーを追加します
+
+1. [apiserverのプロキシー](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
+
+    - apiserver内で動作する踏み台となります
+    - これがなければ到達不可能であるクラスターIPへ、クラスターの外部からのユーザーを接続します
+    - apiserverのプロセス内で稼働します
+    - クライアントからプロキシー間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
+    - プロキシーからターゲット間では利用可能な情報を使用して、プロキシーによって選択されたHTTPかHTTPSのいずれかを使用します
+    - Node、Pod、Serviceへ到達するのに使えます
+    - Serviceへ到達するときは負荷分散を行います
+
+1.  [kube proxy](/ja/docs/concepts/services-networking/service/#ips-and-vips):
+
+    - 各ノード上で稼働します
+    - UDP、TCP、SCTPをプロキシーします
+    - HTTPを解釈しません
+    - 負荷分散機能を提供します
+    - Serviceへ到達させるためのみに使用されます
+
+1.  apiserverの前段にあるプロキシー/ロードバランサー:
+
+    - 実際に存在するかどうかと実装はクラスターごとに異なります(例: nginx)
+    - 全てのクライアントと、1つ以上のapiserverの間に位置します
+    - 複数のapiserverがあるときロードバランサーとして稼働します
+
+1.  外部サービス上で稼働するクラウドロードバランサー:
+
+    - いくつかのクラウドプロバイダーによって提供されます(例: AWS ELB、Google Cloud Load Balancer)
+    - `LoadBalancer`というtypeのKubernetes Serviceが作成されたときに自動で作成されます
+    - たいていのクラウドロードバランサーはUDP/TCPのみサポートしています
+    - SCTPのサポートはクラウドプロバイダーのロードバランサーの実装によって異なります
+    - ロードバランサーの実装はクラウドプロバイダーによって異なります
+
+Kubernetesユーザーのほとんどは、最初の2つのタイプ以外に心配する必要はありません。クラスター管理者はそれ以外のタイプのロードバランサーを正しくセットアップすることを保証します。
+
+## リダイレクトの要求
+
+プロキシーはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。
+
+
+
+
diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md
index 2a5dfc4a51..5f2fd15120 100644
--- a/content/ja/docs/concepts/configuration/overview.md
+++ b/content/ja/docs/concepts/configuration/overview.md
@@ -31,7 +31,7 @@ weight: 10
 
 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
 
-  明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
+  明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/job/)のほうが適切な場合もあるかもしれません。
 
 ## Service
 
@@ -68,11 +68,11 @@ weight: 10
 
 ## コンテナイメージ
 
-[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/admin/kubelet/)が特定のイメージをpullしようとしたときに作用します。
+[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が特定のイメージをpullしようとしたときに作用します。
 
 - `imagePullPolicy: IfNotPresent`: ローカルでイメージが見つからない場合にのみイメージをpullします。
 
-- `imagePullPolicy: Always`: Podの起動時に常にイメージをpullします。
+- `imagePullPolicy: Always`: kubeletがコンテナを起動する度に、kubeletはコンテナイメージレジストリに問い合わせて、イメージのダイジェストの名前解決を行います。もし、kubeletが同じダイジェストのコンテナイメージをローカルにキャッシュしていたら、kubeletはそのキャッシュされたイメージを利用します。そうでなければ、kubeletは解決されたダイジェストのイメージをダウンロードし、そのイメージを利用してコンテナを起動します。
 
 - `imagePullPolicy` のタグが省略されていて、利用してるイメージのタグが`:latest`の場合や省略されている場合、`Always`が適用されます。
 
@@ -98,6 +98,6 @@ weight: 10
 
 - `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
 
-
+- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment`や`kubectl expose`を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。
 
 
diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md
index 3e1c30f9b8..5b10416c0f 100755
--- a/content/ja/docs/concepts/containers/_index.md
+++ b/content/ja/docs/concepts/containers/_index.md
@@ -1,4 +1,33 @@
 ---
-title: "コンテナ"
+title: コンテナ
 weight: 40
+description: アプリケーションとランタイムの依存関係を一緒にパッケージ化するための技術
+reviewers:
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+
+実行するそれぞれのコンテナは繰り返し使用可能です。依存関係を含めて標準化されており、どこで実行しても同じ動作が得られることを意味しています。
+
+コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。
+
+
+
+
+<!-- body -->
+
+## コンテナイメージ
+[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
+
+設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
+
+## コンテナランタイム
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
+* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。
diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md
index 13ad6f2578..ba94bd6fab 100644
--- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md
@@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
 ハンドラーにパラメーターは渡されません。
 
-終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。
+終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
 
 ### フックハンドラーの実装
 
@@ -102,4 +102,3 @@ Events:
 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
 
 
-
diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md
new file mode 100644
index 0000000000..0ad4459d79
--- /dev/null
+++ b/content/ja/docs/concepts/containers/images.md
@@ -0,0 +1,273 @@
+---
+reviewers:
+title: イメージ
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+コンテナイメージはアプリケーションと依存関係のあるすべてソフトウェアをカプセル化したバイナリデータを表します。コンテナイメージはスタンドアロンで実行可能なソフトウェアをひとつにまとめ、ランタイム環境に関する想定を明確に定義しています。
+
+アプリケーションのコンテナイメージを作成し、一般的には{{< glossary_tooltip text="Pod" term_id="pod" >}}で参照する前にレジストリへPushします。
+
+このページではコンテナイメージの概要を説明します。
+
+<!-- body -->
+
+## イメージの名称
+
+コンテナイメージは、`pause`、`example/mycontainer`、または`kube-apiserver`のような名前が通常つけられます。
+イメージにはレジストリのホスト名も含めることができ（例：`fictional.registry.example/imagename`）、さらにポート番号も含めることが可能です（例：`fictional.registry.example:10443/imagename`）。
+
+レジストリのホスト名を指定しない場合は、KubernetesはDockerパブリックレジストリを意味していると見なします。
+
+イメージ名の後に、_タグ_ を追加することができます（`docker`や`podman`のようなコマンドを利用した場合と同様）。
+タグによって同じイメージの異なるバージョンを識別できます。
+
+イメージタグは大文字と小文字、数値、アンダースコア(`_`)、ピリオド(`.`)とマイナス(`-`)で構成されます。
+イメージタグでは区切り記号(`_`、`-`、`.`)を指定できる追加ルールがあります。
+タグを指定しない場合は、Kubernetesは`latest`タグを指定したと見なします。
+
+{{< caution >}}
+本番環境でコンテナをデプロイする場合は、`latest`タグの使用を避けるべきです。
+実行中のイメージのバージョンを追跡するのが難しく、機能しているバージョンへのロールバックがより困難になるためです。
+
+かわりに、`v1.42.0`のような特定できるタグを指定してください。
+{{< /caution >}}
+
+
+## イメージの更新
+
+デフォルトのpull policyでは、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}はイメージを既に取得済みの場合、イメージのPullをスキップさせる`IfNotPresent`が設定されています。
+常にPullを強制させたい場合は、次のいずれかの方法で実行できます。
+
+- コンテナの`imagePullPolicy`に`Always`を設定する
+- `imagePullPolicy`を省略し、使用するイメージに`:latest`タグを使用する
+- `imagePullPolicy`と使用するイメージのタグを省略する
+- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)アドミッションコントローラーを有効にする
+
+`imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。
+
+## マニフェストを使ったマルチアーキテクチャイメージ
+
+コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。
+マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
+
+Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つ名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。
+
+## プライベートレジストリを使用する方法
+
+プライベートレジストリではイメージを読み込む為にキーが必要になる場合があります。  
+認証情報はいくつかの方法で提供できます。
+
+  - プライベートレジストリへの認証をNodeに設定する
+    - すべてのPodがプライベートレジストリを読み取ることができる
+    - クラスター管理者によるNodeの設定が必要
+  - 事前にPullされたイメージ
+    - すべてのPodがNode上にキャッシュされたイメージを利用できる
+    - セットアップするためにはすべてのNodeに対するrootアクセスが必要
+  - PodでImagePullSecretsを指定する
+    - キーを提供したPodのみがプライベートレジストリへアクセスできる
+  - ベンダー固有またはローカルエクステンション
+    - カスタムNode構成を使っている場合、あなた(または、あなたのクラウドプロバイダー)はコンテナレジストリへの認証の仕組みを組み込むことができる
+
+これらのオプションについて、以下で詳しく説明します。
+
+### プライベートレジストリへの認証をNodeに設定する
+
+Node上でDockerを実行している場合、プライベートコンテナレジストリへの認証をDockerコンテナランタイムに設定できます。
+
+Node構成を制御できる場合は、この方法が適しています。
+
+{{< note >}}
+KubernetesはDocker構成の`auths`と`HttpHeaders`セクションのみをサポートしています。
+Docker認証情報ヘルパー(`credHelpers`または`credsStore`)はサポートされていません。
+{{< /note >}}
+
+
+Dockerは、`$HOME/.dockercfg`または`$HOME/.docker/config.json`ファイルの中に、プライベートレジストリのキーを保持します。
+下記リストの検索パスに同じファイルを配置した場合、kubeletはイメージをPullする時に認証情報プロバイダーとして利用します。
+
+
+* `{--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 >}}
+kubeletプロセスの環境では、明示的に`HOME=/root`を設定する必要がある場合があります。
+{{< /note >}}
+
+以下は、プライベートレジストリを使用する為にNodeを構成する推奨の手順です。この例では、デスクトップ/ノートPC上で実行します。
+
+   1. 使用したい認証情報のセット毎に `docker login [server]`を実行する。これであなたのPC上の`$HOME/.docker/config.json`が更新される
+   1. 使用したい認証情報が含まれているかを確認するため、エディターで`$HOME/.docker/config.json`を見る
+   1. Nodeの一覧を取得 例:
+      - 名称が必要な場合: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
+      - IPアドレスを取得したい場合: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
+   1. ローカルの`.docker/config.json`を上記の検索パスのいずれかにコピーする
+      - 例えば、これでテストを実施する: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
+
+{{< note >}}
+本番環境用クラスターでは、構成管理ツールを使用して必要なすべてのNodeに設定を反映してください。
+{{< /note >}}
+
+プライベートイメージを使用するPodを作成し確認します。
+例:
+
+```shell
+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
+```
+
+すべてが機能している場合は、しばらくしてから以下のコマンドを実行します。
+
+```shell
+kubectl logs private-image-test-1
+```
+コマンドの結果を確認してください。
+```
+SUCCESS
+```
+
+コマンドが失敗したと思われる場合には、以下を実行します。
+```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
+```
+
+
+クラスターのすべてのNodeが同じ`.docker/config.json`になっているかを確認する必要があります。
+そうでない場合、Podは一部のNodeで実行できますが他のNodeでは実行に失敗します。
+例えば、Nodeのオートスケールを使用している場合、各インスタンスのテンプレートに`.docker/config.json`が含まれている、またはこのファイルが含まれているドライブをマウントする必要があります。
+
+プライベートレジストリキーを`.docker/config.json`に追加した時点で、すべてのPodがプライベートレジストリのイメージに読み取りアクセス権も持つようになります。
+
+### 事前にPullしたイメージ
+
+{{< note >}}
+Node構成を制御できる場合、この方法が適しています。
+クラウドプロバイダーがNodeを管理し自動的に設定を置き換える場合は、確実に機能できません。
+{{< /note >}}
+
+デフォルトでは、kubeletは指定されたレジストリからそれぞれのイメージをPullしようとします。
+また一方では、コンテナの`imagePullPolicy`プロパティに`IfNotPresent`や`Never`が設定されている場合、ローカルのイメージが使用されます。(それぞれに対して、優先的またはか排他的に)
+
+レジストリ認証の代替として事前にPullしたイメージを利用したい場合、クラスターのすべてのNodeが同じ事前にPullしたイメージを持っていることを確認する必要があります。
+
+特定のイメージをあらかじめロードしておくことは高速化やプライベートレジストリへの認証の代替として利用することができます。
+
+すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。
+
+### PodでImagePullSecretsを指定する
+
+{{< note >}}
+この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。
+{{< /note >}}
+
+KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。
+
+#### Docker Configを利用してSecretを作成する。
+
+適切な大文字の値を置き換えて、次のコマンドを実行します。
+
+```shell
+kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
+```
+
+既にDocker認証情報ファイルを持っている場合は、上記のコマンドの代わりに、認証情報ファイルをKubernetes {{< glossary_tooltip text="Secrets" term_id="secret" >}}としてインポートすることができます。
+[既存のDocker認証情報に基づいてSecretを作成する](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) で、この設定方法を説明します.
+
+これは複数のプライベートコンテナレジストリを使用している場合に特に有効です。`kubectl create secret docker-registry`はひとつのプライベートレジストリにのみ機能するSecretを作成するからです。
+
+{{< note >}}
+Podは自分自身のNamespace内にあるimage pull secretsのみが参照可能であるため、この作業はNemespace毎に1回行う必要があります。
+{{< /note >}}
+
+#### PodのimagePullSecretsを参照する方法
+
+これで、`imagePullSecrets`セクションをPod定義へ追加することでSecretを参照するPodを作成できます。
+
+例:
+
+```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
+```
+
+これは、プライベートレジストリを使用する各Podで行う必要があります。
+
+ただし、この項目の設定は[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)リソースの中でimagePullSecretsを指定することで自動化することができます。
+
+詳細の手順は、[ImagePullSecretsをService Accountに追加する](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)をクリックしてください。
+
+これを各Nodeの`.docker/config.json`に組み合わせて利用できます。認証情報はマージされます。
+
+## ユースケース
+
+プライベートレジストリを設定するためのソリューションはいくつかあります。ここでは、いくつかの一般的なユースケースと推奨される解決方法を示します。
+
+1. クラスターに独自仕様でない(例えば、オープンソース)イメージだけを実行する。イメージを非公開にする必要がない
+   - Docker hubのパブリックイメージを利用する
+     - 設定は必要ない
+     - クラウドプロバイダーによっては、可用性の向上とイメージをPullする時間を短くする為に、自動的にキャッシュやミラーされたパプリックイメージが提供される
+1. 社外には非公開の必要があるが、すべてのクラスター利用者には見せてよい独自仕様のイメージをクラスターで実行している
+   - ホストされたプライペートな [Dockerレジストリ](https://docs.docker.com/registry/)を使用
+     - [Docker Hub](https://hub.docker.com/signup)または他の場所の上でホストされている場合がある
+     - 上記のように各Node上のdocker/config.jsonを手動で構成する
+   - または、オープンな読み取りアクセスを許可したファイヤーウォールの背後で内部向けプライベートレジストリを実行する
+     - Kubernetesの設定は必要ない
+   - イメージへのアクセスを制御できるホストされたコンテナイメージレジストリサービスを利用する
+     - Nodeを手動設定するよりもクラスターのオートスケーリングのほうがうまく機能する
+   - また、Node設定変更を自由にできないクラスターでは`imagePullSecrets`を使用する
+1. 独自仕様のイメージを含むクラスターで、いくつかは厳格なアクセス制御が必要である
+   - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化かを確認する必要がある。さもないと、全部のPodがすべてのイメージへのアクセスができてしまう可能性がある
+   - 機密データはイメージに含めてしまうのではなく、"Secret"リソースに移行する
+1. それぞれのテナントが独自のプライベートレジストリを必要とするマルチテナントのクラスターである
+   - [AlwaysPullImagesアドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)が有効化を確認する必要がある。さもないと、すべてのテナントの全Podが全部のイメージにアクセスできてしまう可能性がある
+   - 認証が必要なプライベートレジストリを実行する
+   - それぞれのテナントでレジストリ認証を生成し、Secretへ設定し、各テナントのNamespaceに追加する
+   - テナントは、Secretを各NamespaceのimagePullSecretsへ追加する
+
+複数のレジストリへのアクセスが必要な場合、それぞれのレジストリ毎にひとつのSecretを作成する事ができます。
+Kubeletは複数の`imagePullSecrets`を単一の仮想的な`.docker/config.json`にマージします。
+
+## {{% heading "whatsnext" %}}
+
+* [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を読みます。
diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md
index bd6cc59c49..8d89f7ff37 100644
--- a/content/ja/docs/concepts/containers/runtime-class.md
+++ b/content/ja/docs/concepts/containers/runtime-class.md
@@ -11,20 +11,18 @@ weight: 20
 
 このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。
 
-{{< warning >}}
-RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。
-{{< /warning >}}
-
-
+RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。
 
 
 <!-- body -->
 
-## RuntimeClassについて
+## RuntimeClassを使う動機
 
-RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。
+異なるPodに異なるRuntimeClassを設定することで、パフォーマンスとセキュリティのバランスをとることができます。例えば、ワークロードの一部に高レベルの情報セキュリティ保証が必要な場合、ハードウェア仮想化を使用するコンテナランタイムで実行されるようにそれらのPodをスケジュールすることを選択できます。その後、追加のオーバーヘッドを犠牲にして、代替ランタイムをさらに分離することでメリットが得られます。
 
-### セットアップ
+RuntimeClassを使用して、コンテナランタイムは同じで設定が異なるPodを実行することもできます。
+
+## セットアップ
 
 RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。
 その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。
@@ -32,7 +30,7 @@ RuntimeClass機能のフィーチャーゲートが有効になっているこ
 1. ノード上でCRI実装を設定する。(ランタイムに依存)
 2. 対応するRuntimeClassリソースを作成する。
 
-#### 1. ノード上でCRI実装を設定する。
+### 1. ノード上でCRI実装を設定する
 
 RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。
 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。
@@ -44,7 +42,7 @@ RuntimeClassは、クラスター全体で同じ種類のノード設定であ
 
 RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。
 
-#### 2. 対応するRuntimeClassリソースを作成する
+### 2. 対応するRuntimeClassリソースを作成する
 
 ステップ1にて設定する各項目は、関連する`ハンドラー` 名を持ちます。それはどの設定かを指定するものです。各ハンドラーにおいて、対応するRuntimeClassオブジェクトが作成されます。
 
@@ -68,7 +66,7 @@ RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター
 Overview](/docs/reference/access-authn-authz/authorization/)を参照してください。
 {{< /note >}}
 
-### 使用例
+## 使用例
 
 一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。  
 例えば
@@ -119,17 +117,15 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim
   runtime_path = "${PATH_TO_BINARY}"
 ```
 
-CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。
+詳細はCRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)を参照してください。
 
-[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
-
-### スケジューリング {#scheduling}
+## スケジューリング {#scheduling}
 
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
 
 Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。
 このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。
-スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです)
+スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)を有効にしなければなりません。(1.16ではデフォルトです)
 
 特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。
 RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。
@@ -138,40 +134,20 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
 もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。
 `nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。
 
-ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。
-
-[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/
+ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)を参照してください。
 
 ### Podオーバーヘッド
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。
-`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです)
+Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
+Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)
 
-PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。
+PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。
 このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。
 
-### RutimeClassをα版からβ版にアップグレードする
 
-RuntimeClassのβ版の機能は、下記の変更点を含みます。
-
-- `node.k8s.io`APIグループと`runtimeclasses.node.k8s.io`リソースはCustomResourceDefinitionからビルトインAPIへとマイグレーションされました。
-- `spec`はRuntimeClassの定義内にインライン化されました(RuntimeClassSpecはすでにありません)。
-- `runtimeHandler`フィールドは`handler`にリネームされました。
-- `handler`フィールドは、全てのAPIバージョンにおいて必須となりました。これはα版のAPIでの`runtimeHandler`フィールドもまた必須であることを意味します。
-- `handler`フィールドは正しいDNSラベルの形式である必要があり([RFC 1123](https://tools.ietf.org/html/rfc1123))、これは`.`文字はもはや含むことができないことを意味します(全てのバージョンにおいて)。有効なハンドラー名は、次の正規表現に従います。`^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
-
-**Action Required:** 次のアクションはRuntimeClassのα版からβ版へのアップグレードにおいて対応が必須です。
-
-- RuntimeClassリソースはKubernetes v1.14にアップグレードされた*後に* 再作成されなくてはなりません。そして`runtimeclasses.node.k8s.io`というCRDは手動で削除されるべきです。  
-  ```
-  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
-  ```
-- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
-
-
-### 参考文献
+## {{% heading "whatsnext" %}}
 
 - [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
 - [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
diff --git a/content/ja/docs/concepts/extend-kubernetes/_index.md b/content/ja/docs/concepts/extend-kubernetes/_index.md
index 7a162b4c57..e1b30a8ae8 100644
--- a/content/ja/docs/concepts/extend-kubernetes/_index.md
+++ b/content/ja/docs/concepts/extend-kubernetes/_index.md
@@ -1,4 +1,164 @@
 ---
 title: Kubernetesを拡張する
 weight: 110
+description: Kubernetesクラスターの挙動を変えるいろいろな方法
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+Kubernetesは柔軟な設定が可能で、高い拡張性を持っています。
+結果として、Kubernetesのプロジェクトソースコードをフォークしたり、パッチを当てて利用することは滅多にありません。
+このガイドは、Kubernetesクラスターをカスタマイズするための選択肢を記載します。
+管理しているKubernetesクラスターを、動作環境の要件にどのように適合させるべきかを理解したい{{< glossary_tooltip text="クラスター管理者" term_id="cluster-operator" >}}を対象にしています。
+将来の {{< glossary_tooltip text="プラットフォーム開発者" term_id="platform-developer" >}} 、またはKubernetesプロジェクトの{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}にとっても、どのような拡張のポイントやパターンが存在するのか、また、それぞれのトレードオフや制限事項を学ぶための導入として役立つでしょう。
+<!-- body -->
+## 概要
+カスタマイズのアプローチには大きく分けて、フラグ、ローカル設定ファイル、またはAPIリソースの変更のみを含んだ *設定* と、稼働しているプログラムまたはサービスも含んだ *拡張* があります。このドキュメントでは、主に拡張について説明します。
+## 設定
+
+*設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
+
+* [kubelet](/docs/admin/kubelet/)
+* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-scheduler](/docs/admin/kube-scheduler/)
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
+
+ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
+
+[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+
+## 拡張
+
+拡張はKubernetesを拡張し、深く統合されたソフトウェアの構成要素です。
+これは新しいタイプと、新しい種類のハードウェアをサポートするために利用されます。
+
+ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。
+結果として、ほとんどのKubernetesユーザーは既存の拡張を使えばよいため、新しい拡張を書く必要は無いと言えます。
+
+## 拡張パターン {#extension-patterns}
+
+Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。
+Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。
+*自動化機能* はクラスター上、またはクラスター外で実行できます。
+このドキュメントに後述のガイダンスに従うことで、高い可用性を持つ頑強な自動化機能を書くことができます。
+自動化機能は通常、ホスティングされているクラスター、マネージドな環境など、どのKubernetesクラスター上でも動きます。
+
+Kubernetes上でうまく動くクライアントプログラムを書くために、*コントローラー* パターンという明確なパターンがあります。
+コントローラーは通常、オブジェクトの `.spec` を読み取り、何らかの処理をして、オブジェクトの `.status` を更新します。
+
+コントローラーはKubernetesのクライアントです。Kubernetesがクライアントとして動き、外部のサービスを呼び出す場合、それは *Webhook* と呼ばれます。
+呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。
+
+Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
+*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
+バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
+
+下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
+
+<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
+
+## 拡張ポイント
+
+この図は、Kubernetesにおける拡張ポイントを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
+
+<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
+
+1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセス拡張](/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセス拡張と一緒に使われます。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラー拡張](/docs/concepts/extend-kubernetes/#scheduler-extensions)セクションに記載されています。
+5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。
+
+もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類の拡張を含んでいることを留意してください。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
+
+<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
+
+## API拡張
+### ユーザー定義タイプ
+
+新しいコントローラー、アプリケーションの設定に関するオブジェクト、また宣言型APIを定義し、それらを`kubectl`のようなKubernetesのツールから管理したい場合、Kubernetesにカスタムリソースを追加することを検討して下さい。
+
+カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。
+
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を参照して下さい。
+
+### 新しいAPIと自動化機能の連携
+
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+
+### ビルトインリソースの変更
+
+カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセス拡張の場合、その可能性があります。
+
+### APIアクセス拡張 {#api-access-extensions}
+
+リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
+
+これらの各ステップごとに拡張ポイントが用意されています。
+
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/)でカバーされています。
+
+### 認証
+
+[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+
+Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
+
+### 認可
+
+[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可メカニズムが要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
+
+### 動的Admission Control
+
+リクエストが認可された後、もしそれが書き込み操作だった場合、リクエストは[Admission Control](/docs/reference/access-authn-authz/admission-controllers/)のステップを通ります。ビルトインのステップに加え、いくつかの拡張が存在します:
+
+*   [イメージポリシーWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)は、コンテナでどのイメージを実行することができるかを制限する
+*   任意のAdmission Controlの決定を行うには、一般的な[Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)が利用できる。Admission Webhookは作成、更新を拒絶できる
+
+## インフラストラクチャ拡張
+
+### ストレージプラグイン
+
+[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+
+### デバイスプラグイン
+
+[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
+
+### ネットワークプラグイン
+
+他のネットワークファブリックが[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じてサポートされます。
+
+### スケジューラー拡張
+
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)を同時に動かすこともできます。
+
+これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
+
+スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラー拡張)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)についてより深く学ぶ
+* [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
+* インフラストラクチャ拡張についてより深く学ぶ
+  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+* [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
+* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index 3a14aab62c..50593a61b8 100644
--- a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -32,9 +32,9 @@ kube-apiserverとの間を5秒以内に往復するためには、ディスカ
 ## {{% heading "whatsnext" %}}
 
 
-* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します
-* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
-* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
+* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)します
+* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/extend-kubernetes/setup-extension-api-server/)します
+* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)方法を学んで下さい
 * [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい
 
 
diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index c05b35cdbc..3616f568c1 100644
--- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -18,7 +18,7 @@ weight: 10
 
 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
 
-カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/user-guide/kubectl-overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
+カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
 
 ## カスタムコントローラー
 
@@ -31,7 +31,7 @@ weight: 10
 
 ## カスタムリソースをクラスターに追加するべきか？
 
-新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。
+新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。
 
 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: |
 | ------------------------------ | ---------------------------- |
@@ -78,7 +78,7 @@ APIが宣言的ではない兆候として、次のものがあります:
 * ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい
 
 {{< note >}}
-センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください
+センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/ja/docs/concepts/configuration/secret/)を使ってください
 {{< /note >}}
 
 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください:
@@ -107,7 +107,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類
 
 ## CustomResourceDefinition
 
-[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
+[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
 CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。
 
 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。
@@ -136,7 +136,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
 | CRD                        | アグリゲートAPI |
 | -------------------------- | --------------- |
 | プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 |
-| 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
+| 追加のサービスは不要。CRDはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
 | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない |
 | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 |
 
@@ -146,17 +146,17 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。
 
 | 機能 | 詳細 | CRD | アグリゲートAPI |
 | ---- | ---- | --- | --------------- |
-| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 |
+| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 |
 | デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい |
-| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい |
+| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | はい |
 | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい |
 | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい |
-| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい |
-| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい |
+| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | はい |
+| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | はい |
 | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい |
-| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
+| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
 | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
-| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
+| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
 
 ### 一般的な機能
 
@@ -166,7 +166,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
 | ---- | -------------- |
 | CRUD | 新しいエンドポイントが、HTTP、`kubectl`を通じて、基本的なCRUD処理をサポート |
 | Watch | 新しいエンドポイントが、HTTPを通じて、KubernetesのWatch処理をサポート |
-| Discovery | kubectlやダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 |
+| Discovery | `kubectl`やダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 |
 | json-patch | 新しいエンドポイントが`Content-Type: application/json-patch+json`を用いたPATCHをサポート |
 | merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート |
 | HTTPS | 新しいエンドポイントがHTTPSを利用 |
@@ -205,11 +205,11 @@ CRDでは、APIサーバーのビルトインリソースと同じ認証、認
 
 ## カスタムリソースへのアクセス
 
-Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、GoとPythonのライブラリーはサポートしています。
+Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_ と _Python_ のライブラリーはサポートしています。
 
 カスタムリソースは、下記のような方法で操作できます:
 
-- kubectl
+- `kubectl`
 - kubernetesの動的クライアント
 - 自作のRESTクライアント
 - [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります)
@@ -220,4 +220,4 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl
 
 
 * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
-* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
+* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)について学ぶ
diff --git a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
index a1a1af7c6b..d8fe44547e 100644
--- a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -25,14 +25,14 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
 
 *設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
 
-* [kubelet](/docs/admin/kubelet/)
-* [kube-apiserver](/docs/admin/kube-apiserver/)
-* [kube-controller-manager](/docs/admin/kube-controller-manager/)
-* [kube-scheduler](/docs/admin/kube-scheduler/)
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
 
 ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
 
-[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/using-api/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
 
 ## エクステンション
 
@@ -58,7 +58,7 @@ Kubernetes上でうまく動くクライアントプログラムを書くため
 
 Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
 *バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
-バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。
+バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
 
 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
 
@@ -75,12 +75,12 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
 
 1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
-2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/docs/concepts/overview/extending#api-access-extensions)セクションに記載されています。
-3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/overview/extending#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
-4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/docs/concepts/overview/extending#scheduler-extensions)セクションに記載されています。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/ja/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/ja/docs/concepts/extend-kubernetes/#scheduler-extensions)セクションに記載されています。
 5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
-6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/overview/extending#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
-7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/overview/extending#storage-plugins)を通じてサポートされます。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/ja/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/ja/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。
 
 もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類のエクステンションを含んでいることを留意してください。
 
@@ -95,11 +95,11 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 
 カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。
 
-カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/docs/concepts/api-extension/custom-resources/)を参照して下さい。
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を参照して下さい。
 
 ### 新しいAPIと自動化機能の連携
 
-カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
 
 ### ビルトインリソースの変更
 
@@ -111,11 +111,11 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 
 これらの各ステップごとに拡張ポイントが用意されています。
 
-Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/)でカバーされています。
 
 ### 認証
 
-[認証](/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
 
 Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
 
@@ -134,19 +134,19 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
 
 ### ストレージプラグイン
 
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
 
 ### デバイスプラグイン
 
-[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
+[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
 
 ### ネットワークプラグイン
 
-他のネットワークファブリックが[ネットワークプラグイン](/docs/admin/network-plugins/)を通じてサポートされます。
+他のネットワークファブリックが[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じてサポートされます。
 
 ### スケジューラーエクステンション
 
-スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/administer-cluster/configure-multiple-schedulers/)を同時に動かすこともできます。
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)を同時に動かすこともできます。
 
 これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
 
@@ -157,12 +157,10 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
 ## {{% heading "whatsnext" %}}
 
 
-* [カスタムリソース](/docs/concepts/api-extension/custom-resources/)についてより深く学ぶ
+* [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)についてより深く学ぶ
 * [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
 * インフラストラクチャエクステンションについてより深く学ぶ
-  * [ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)
-  * [デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)
+  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 * [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
 * [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
-
-
diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md
index 507463359d..e9ac2054e8 100644
--- a/content/ja/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ja/docs/concepts/extend-kubernetes/operator.md
@@ -6,8 +6,8 @@ weight: 30
 
 <!-- overview -->
 
-オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。
-オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
+オペレーターは[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。
+オペレーターは、特に[制御ループ](/ja/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
 
 
 
@@ -75,7 +75,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
 ## 自分でオペレーターを書く {#writing-operator}
 
 必要な振る舞いを実装したオペレーターがエコシステム内に無い場合、自分で作成することができます。
-[次の項目](#what-s-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。
+[次の項目](#whats-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。
 
 オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。
 
@@ -95,4 +95,3 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
 * オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます
 * Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます
 
-
diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md
index a70f3d2e97..dbea76db1d 100644
--- a/content/ja/docs/concepts/overview/components.md
+++ b/content/ja/docs/concepts/overview/components.md
@@ -1,6 +1,8 @@
 ---
 title: Kubernetesのコンポーネント
 content_type: concept
+description: >
+  Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。
 weight: 20
 card: 
   name: concepts
@@ -53,20 +55,18 @@ Kubernetesをデプロイすると、クラスターが展開されます。
 
 ### cloud-controller-manager
 
-[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。
-cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
 
-cloud-controller-managerは、クラウドプロバイダー固有のコントローラーループのみを実行します。これらのコントローラーループはkube-controller-managerで無効にする必要があります。 kube-controller-managerの起動時に `--cloud-provider` フラグを `external` に設定することで、コントローラーループを無効にできます。
+cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。
+KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。
 
-cloud-controller-managerを使用すると、クラウドベンダーのコードとKubernetesコードを互いに独立して進化させることができます。以前のリリースでは、コアKubernetesコードは、機能的にクラウドプロバイダー固有のコードに依存していました。将来のリリースでは、クラウドベンダーに固有のコードはクラウドベンダー自身で管理し、Kubernetesの実行中にcloud-controller-managerにリンクする必要があります。
+kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。
 
-次のコントローラーには、クラウドプロバイダーへの依存関係があります。
+次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。
 
   * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。
   * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。
   * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
-  * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。
-
 ## ノードコンポーネント {#node-components}
 
 ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。
diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md
index 5d95929bef..251f671b6d 100644
--- a/content/ja/docs/concepts/overview/kubernetes-api.md
+++ b/content/ja/docs/concepts/overview/kubernetes-api.md
@@ -3,6 +3,9 @@ reviewers:
 title: Kubernetes API
 content_type: concept
 weight: 30
+description: >
+  Kubernetes APIを使用すると、Kubernetes内のオブジェクトの状態をクエリで操作できます。
+  Kubernetesのコントロールプレーンの中核は、APIサーバーとそれが公開するHTTP APIです。ユーザー、クラスターのさまざまな部分、および外部コンポーネントはすべて、APIサーバーを介して互いに通信します。
 card:
   name: concepts
   weight: 30
@@ -10,64 +13,80 @@ card:
 
 <!-- overview -->
 
-全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。
-
-APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。
-
-APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。
-
-Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。
-
-また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。
-
-Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。
+Kubernetesの中核である {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。
+APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。
 
+Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
 
+APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。
 
 <!-- body -->
 
 ## APIの変更
 
-我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。
+成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。
+したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。
+Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。
 
-何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。
+基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
+リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。
 
-## OpenAPIとSwaggerの定義
+互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。
 
-完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)に記載されています。
 
-Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポイントを通じて、OpenAPI仕様を提供しています。
-リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます:
+## OpenAPI 仕様 {#api-specification}
 
-ヘッダ | 設定可能な値
------- | ---------------
-Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません)
-Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています)
+完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。
 
-1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。
+Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。
+次のように要求ヘッダーを使用して、応答フォーマットを要求できます。
 
-**OpenAPI仕様の取得サンプル**:
 
-1.10より前 | Kubernetes1.10以降
------------ | -----------------------------
-GET /swagger.json | GET /openapi/v2 **Accept**: application/json
-GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
-GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip
+<table>
+  <thead>
+     <tr>
+        <th>Header</th>
+        <th style="min-width: 50%;">Possible values</th>
+        <th>Notes</th>
+     </tr>
+  </thead>
+  <tbody>
+     <tr>
+        <td><code>Accept-Encoding</code></td>
+        <td><code>gzip</code></td>
+        <td><em>このヘッダーを使わないことも可能</em></td>
+     </tr>
+     <tr>
+        <td rowspan="3"><code>Accept</code></td>
+        <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td>
+        <td><em>主にクラスター内での使用</em></td>
+     </tr>
+     <tr>
+        <td><code>application/json</code></td>
+        <td><em>デフォルト</em></td>
+     </tr>
+     <tr>
+        <td><code>*</code></td>
+        <td><code>application/json</code>を提供</td>
+     </tr>
+  </tbody>
+  <caption>OpenAPI v2クエリの有効なリクエストヘッダー値</caption>
+</table>
+
 
 Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
 
-また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。
-このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。
-
 ## APIバージョニング
 
-フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/extensions/v1beta1`のように、それぞれ異なるAPIのパスが割り当てられています。
+フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。
 
-APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。
+APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。
+
+JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。
 
 APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。
 
-異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます:
+異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます:
 
 - アルファレベル(版):
   - バージョン名に`alpha`を含みます(例、`v1alpha1`)。
@@ -88,29 +107,37 @@ APIとソフトウエアのバージョニングは、間接的にしか関連
 
 ## APIグループ {#api-groups}
 
-KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
+APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
 APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。
 
-現在、いくつかのAPIグループが利用されています:
+クラスターにはいくつかのAPIグループがあります:
 
-1. *core* グループ(たびたび、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
+1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
 
-1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。
+1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。
 
-[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています:
+[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります:
 
-1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。
-1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。
+1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。
+1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。
 
 ## APIグループの有効化、無効化
 
-いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
+いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。
 
-{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}}
+`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
 
-## APIグループextensions/v1beta1に含まれる特定のリソースの有効化
+{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}}
 
-APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。
-例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。
+## 永続性
 
-{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}}
+KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。
+
+
+## {{% heading "whatsnext" %}}
+
+[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
+
+全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。
+
+APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。
diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md
index 5f2f4bbf18..d1b792c0da 100644
--- a/content/ja/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md
@@ -71,11 +71,11 @@ Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密
 
 ## Kubernetesにないもの
 
-Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。
+Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散といったPaaSが提供するのと共通の機能をいくつか提供し、またユーザーはロギングやモニタリング及びアラートを行うソリューションを統合できます。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。
 
 Kubernetesは...
 
-* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
+* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
 * ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
 * ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
 * ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。
diff --git a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md
index 9212de948e..ee7e88eccd 100644
--- a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md
@@ -26,7 +26,7 @@ content_type: concept
 | キー                                 | 説明           | 例  | 型 |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | アプリケーション名 | `mysql` | 文字列 |
-| `app.kubernetes.io/instance`        | アプリケーションのインスタンスを特定するための固有名 | `wordpress-abcxzy` | 文字列 |
+| `app.kubernetes.io/instance`        | アプリケーションのインスタンスを特定するための固有名 | `mysql-abcxzy` | 文字列 |
 | `app.kubernetes.io/version`         | アプリケーションの現在のバージョン (例: セマンティックバージョン、リビジョンのハッシュなど) | `5.7.21` | 文字列 |
 | `app.kubernetes.io/component`       | アーキテクチャ内のコンポーネント | `database` | 文字列 |
 | `app.kubernetes.io/part-of`         | このアプリケーションによって構成される上位レベルのアプリケーション | `wordpress` | 文字列 |
@@ -40,7 +40,7 @@ kind: StatefulSet
 metadata:
   labels:
     app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
     app.kubernetes.io/version: "5.7.21"
     app.kubernetes.io/component: database
     app.kubernetes.io/part-of: wordpress
diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md
index ddf947212d..78930a469a 100644
--- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -17,12 +17,7 @@ kubectl get pods --field-selector status.phase=Running
 ```
 
 {{< note >}}
-フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、下記の2つの`kubectl`クエリが同じであることを意味します。  
-
-```shell
-kubectl get pods
-kubectl get pods --field-selector ""
-```
+フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、`kubectl`クエリの`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。  
 {{< /note >}}
 
 ## サポートされているフィールド
diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 48cbed282a..9b3eeb7332 100644
--- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -28,7 +28,7 @@ Kubernetesオブジェクトを操作するには、作成、変更、または
 
 ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。
 
-`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
+`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesシステムとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
 
 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
 
@@ -73,7 +73,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
 
 
 * [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
-* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。
+* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。
 * Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。
 
 
diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md
index c7ebacf360..b6abcb974d 100644
--- a/content/ja/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md
@@ -81,7 +81,7 @@ spec:
 
 ## ラベルセレクター {#label-selectors}
 
-[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。
+[名前とUID](/ja/docs/concepts/overview/working-with-objects/names/)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。
 
 *ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。
 
@@ -222,7 +222,7 @@ selector:
 
 #### *集合ベース* の要件指定をサポートするリソース
 
-[`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。  
+[`Job`](/docs/concepts/workloads/controllers/job/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。  
 ```yaml
 selector:
   matchLabels:
@@ -238,6 +238,6 @@ selector:
 
 #### Nodeのセットを選択する  
 ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。  
-さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 
+さらなる情報に関しては、[Node選定](/ja/docs/concepts/scheduling-eviction/assign-pod-node/) のドキュメントを参照してください。 
 
 
diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md
index 1b66e046f1..f9ebbabffd 100644
--- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md
@@ -33,6 +33,10 @@ Kubernetesの将来的なバージョンにおいて、同一のNamespace内の
 
 Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
 
+{{< note >}}
+　　プレフィックス`kube-`を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。
+{{< /note >}}
+
 ### Namespaceの表示
 
 ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。
@@ -41,18 +45,20 @@ Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメン
 kubectl get namespace
 ```
 ```
-NAME          STATUS    AGE
-default       Active    1d
-kube-system   Active    1d
-kube-public   Active    1d
+NAME              STATUS   AGE
+default           Active   1d
+kube-node-lease   Active   1d
+kube-system       Active   1d
+kube-public       Active   1d
 ```
 
-Kubernetesの起動時には3つの初期Namespaceが作成されています。
+Kubernetesの起動時には4つの初期Namespaceが作成されています。
 
    * `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace
    * `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace
    * `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。)
     このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。
+   * `kube-node-lease` クラスターのスケールに応じたノードハートビートのパフォーマンスを向上させる各ノードに関連したLeaseオブジェクトのためのNamespace。
 
 ### Namespaceの設定
 
@@ -79,7 +85,7 @@ kubectl config view --minify | grep namespace:
 
 ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。
 このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり、これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
-これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
+これはデベロップメント、ステージング、プロダクションといった複数のNamespaceをまたいで同じ設定を使う時に効果的です。
 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
 
 ## すべてのオブジェクトはNamespaceに属しているとは限らない
diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md
index 0cc930e473..e7368a8f94 100644
--- a/content/ja/docs/concepts/policy/resource-quotas.md
+++ b/content/ja/docs/concepts/policy/resource-quotas.md
@@ -23,7 +23,7 @@ weight: 10
 - 管理者は各名前空間で1つの`ResourceQuota`を作成します。
 - ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
-- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。
+- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。
 
 `ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
 
@@ -58,9 +58,9 @@ weight: 10
 
 ### 拡張リソースのためのリソースクォータ
 
-上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。
+上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。
 
-拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。
+拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`limits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。
 
 GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。
 
@@ -163,7 +163,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
 
 ### PriorityClass毎のリソースクォータ
 
-{{< feature-state for_k8s_version="1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
 
 Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
 
@@ -451,7 +451,8 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset
 ```
 
 ```shell
-kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
+kubectl create deployment nginx --image=nginx --namespace=myspace
+kubectl scale deployment nginx --replicas=2 --namespace=myspace
 ```
 
 ```shell
@@ -549,5 +550,5 @@ plugins:
 
 ## {{% heading "whatsnext" %}}
 
-さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
+- さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
 
diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md
similarity index 96%
rename from content/ja/docs/concepts/configuration/assign-pod-node.md
rename to content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md
index fc05700e28..0733690f0b 100644
--- a/content/ja/docs/concepts/configuration/assign-pod-node.md
+++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -136,7 +136,7 @@ Nodeアフィニティを使用したPodの例を以下に示します:
 
 この例ではオペレーター`In`が使われています。
 Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
-`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
+`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)に使用します。
 
 `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。
 
@@ -186,10 +186,10 @@ Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffin
 
 このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。
 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
-Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
-Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
+Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`topology.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
+Node Nがキー`topology.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
 Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
-(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
+(`topologyKey`が`topology.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
 PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
 
 PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
@@ -201,7 +201,7 @@ PodアフィニティとPodアンチアフィニティで使用できるオペ
 2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
 3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。
-4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。
+4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができます。
 
 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。
 省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。
@@ -361,7 +361,7 @@ spec:
 ## {{% heading "whatsnext" %}}
 
 
-[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
+[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
 
 [Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
 [Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
index 513b7d48a1..861e528cd9 100644
--- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -98,7 +98,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 
 - `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。
 
-- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/)にて確認できます。
+- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にて確認できます。
 
 - `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。
 
@@ -106,7 +106,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 
 - `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
 
-- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
+- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
 
 - `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
 
diff --git a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md
index 90930357a8..ba9d37d2ea 100644
--- a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -6,7 +6,7 @@ weight: 40
 
 
 <!-- overview -->
-[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は
+[_Nodeアフィニティ_](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)は
 {{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。
 
 _toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。
diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md
new file mode 100644
index 0000000000..b50a4ea1a5
--- /dev/null
+++ b/content/ja/docs/concepts/security/overview.md
@@ -0,0 +1,132 @@
+---
+reviewers:
+title: クラウドネイティブセキュリティの概要
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+この概要では、クラウドネイティブセキュリティにおけるKubernetesのセキュリティを考えるためのモデルを定義します。
+
+{{< warning >}}
+コンテナセキュリティモデルは、実証済の情報セキュリティポリシーではなく提案を提供します。
+{{< /warning >}}
+
+<!-- body -->
+
+## クラウドネイティブセキュリティの４C
+
+セキュリティは階層で考えることができます。クラウドネイティブの4Cは、クラウド、クラスター、コンテナ、そしてコードです。
+
+{{< note >}}
+階層化されたアプローチは、セキュリティに対する[多層防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))のアプローチを強化します。これはソフトウェアシステムを保護するベストプラクティスとして幅広く認知されています。
+{{< /note >}}
+
+{{< figure src="/images/docs/4c.png" title="クラウドネイティブセキュリティの４C" >}}
+
+クラウドネイティブセキュリティモデルの各レイヤーは次の最も外側のレイヤー上に構築します。コードレイヤーは、強固な基盤(クラウド、クラスター、コンテナ)セキュリティレイヤーから恩恵を受けます。コードレベルのセキュリティに対応しても基盤レイヤーが低い水準のセキュリティでは守ることができません。
+
+## クラウド
+
+いろいろな意味でも、クラウド(または同じ場所に設置されたサーバー、企業のデータセンター)はKubernetesクラスターの[トラステッド・コンピューティング・ベース](https://en.wikipedia.org/wiki/Trusted_computing_base)です。クラウドレイヤーが脆弱な(または脆弱な方法で構成されている)場合、この基盤の上に構築されたコンポーネントが安全であるという保証はありません。各クラウドプロバイダーは、それぞれの環境でワークロードを安全に実行させるためのセキュリティの推奨事項を作成しています。
+
+### クラウドプロバイダーのセキュリティ
+
+Kubernetesクラスターを所有しているハードウェアや様々なクラウドプロバイダー上で実行している場合、セキュリティのベストプラクティスに関するドキュメントを参考にしてください。ここでは人気のあるクラウドプロバイダーのセキュリティドキュメントの一部のリンクを紹介します。
+
+{{< table caption="Cloud provider security" >}}
+
+IaaSプロバイダー        | リンク |
+-------------------- | ------------ |
+Alibaba Cloud | https://www.alibabacloud.com/trust-center |
+Amazon Web Services | https://aws.amazon.com/security/ |
+Google Cloud Platform | https://cloud.google.com/security/ |
+IBM Cloud | https://www.ibm.com/cloud/security |
+Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
+VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+
+{{< /table >}}
+
+### インフラのセキュリティ {#infrastructure-security}
+
+Kubernetesクラスターのインフラを保護するための提案です。
+
+{{< table caption="Infrastructure security" >}}
+
+Kubernetesインフラに関する懸念事項 | 推奨事項 |
+--------------------------------------------- | -------------- |
+API Server(コントロールプレーン)へのネットワークアクセス| Kubernetesコントロールプレーンへのすべてのアクセスは、インターネット上での一般公開は許されず、クラスター管理に必要なIPアドレスに制限するネットワークアクセス制御リストによって制御されます。|
+Nodeへのネットワークアクセス | Nodeはコントロールプレーンの特定ポート _のみ_ 接続(ネットワークアクセス制御リストを介して)を受け入れるよう設定し、NodePortとLoadBalancerタイプのKubernetesのServiceに関する接続を受け入れるよう設定する必要があります。可能であれば、それらのNodeはパブリックなインターネットに完全公開しないでください。|
+KubernetesからのクラウドプロバイダーAPIへのアクセス | 各クラウドプロバイダーはKubernetesコントロールプレーンとNodeに異なる権限を与える必要があります。[最小権限の原則](https://en.wikipedia.org/wiki/Principle_of_least_privilege)に従い、管理に必要なリソースに対してクラウドプロバイダーへのアクセスをクラスターに提供するのが最善です。[Kopsドキュメント](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)にはIAMのポリシーとロールについての情報が記載されています。|
+etcdへのアクセス | etcd(Kubernetesのデータストア)へのアクセスはコントロールプレーンのみに制限すべきです。設定によっては、TLS経由でetcdを利用する必要があります。詳細な情報は[etcdドキュメント](https://github.com/etcd-io/etcd/tree/master/Documentation)を参照してください。|
+etcdの暗号化 | 可能な限り、保存時に全ドライブを暗号化することは良いプラクティスですが、etcdはクラスター全体(Secretを含む)の状態を保持しているため、そのディスクは特に暗号化する必要があります。|
+
+{{< /table >}}
+
+## クラスター
+
+Kubernetesを保護する為には２つの懸念事項があります。
+
+* 設定可能なクラスターコンポーネントの保護
+* クラスターで実行されるアプリケーションの保護
+
+### クラスターのコンポーネント {#cluster-components}
+
+想定外または悪意のあるアクセスからクラスターを保護して適切なプラクティスを採用したい場合、[クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)に関するアドバイスを読み従ってください。
+
+### クラスター内のコンポーネント(アプリケーション) {#cluster-applications}
+
+アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。
+
+
+ワークロードセキュリティに関する懸念事項 | 推奨事項 |
+------------------------------ | --------------------- |
+RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
+認証 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ |
+アプリケーションのSecret管理(およびetcdへの保存時に暗号化) | https://kubernetes.io/ja/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ |
+PodSecurityPolicy | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ |
+Quality of Service (およびクラスターリソース管理) | https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-service-pod/ |
+NetworkPolicy | https://kubernetes.io/docs/concepts/services-networking/network-policies/ |
+Kubernetes IngressのTLS | https://kubernetes.io/ja/docs/concepts/services-networking/ingress/#tls |
+
+
+## コンテナ
+
+コンテナセキュリティは本ガイドの範囲外になります。このトピックを検索するために一般的な推奨事項とリンクを以下に示します。
+
+コンテナに関する懸念事項 | 推奨事項 |
+------------------------------ | -------------- |
+コンテナの脆弱性スキャンとOS依存のセキュリティ | イメージをビルドする手順の一部として、既知の脆弱性がないかコンテナをスキャンする必要があります。 |
+イメージの署名と実施 | コンテナイメージを署名し、コンテナの中身に関する信頼性を維持します。 |
+特権ユーザーを許可しない | コンテナの構成時に、コンテナの目的を実行するために必要最低限なOS特権を持ったユーザーをコンテナ内部に作成する方法のドキュメントを参考にしてください。 |
+
+## コード
+
+アプリケーションコードは、あなたが最も制御できる主要な攻撃対象のひとつです。アプリケーションコードを保護することはKubernetesのセキュリティトピックの範囲外ですが、アプリケーションコードを保護するための推奨事項を以下に示します。
+
+### コードセキュリティ
+
+{{< table caption="Code security" >}}
+
+コードに関する懸念事項 | 推奨事項 |
+-------------------------| -------------- |
+TLS経由のアクセスのみ | コードがTCP通信を必要とする場合は、事前にクライアントとのTLSハンドシェイクを実行してください。 いくつかの例外を除いて、全ての通信を暗号化してください。さらに一歩すすめて、サービス間のネットワークトラフィックを暗号化することはよい考えです。これは、サービスを特定した2つの証明書で通信の両端を検証する相互認証、または[mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)して知られているプロセスを通じて実行できます。|
+通信ポートの範囲制限 | この推奨事項は一目瞭然かもしれませんが、可能なかぎり、通信とメトリクス収集に必要不可欠なサービスのポートのみを公開します。 |
+サードパティに依存するセキュリティ | 既知の脆弱性についてアプリケーションのサードパーティ製ライブラリーを定期的にスキャンすることを推奨します。それぞれの言語は自動でこのチェックを実行するツールを持っています。 |
+静的コード解析 | ほとんどの言語ではコードのスニペットを解析して、安全でない可能性のあるコーディングを分析する方法が提供しています。可能な限り、コードベースでスキャンして、よく起こるセキュリティエラーを検出できる自動ツールを使用してチェックを実行すべきです。一部のツールはここで紹介されています。 https://owasp.org/www-community/Source_Code_Analysis_Tools |
+動的プロービング攻撃 | よく知られているいくつかのサービス攻撃をサービスに対して試すことができる自動ツールがいくつかあります。これにはSQLインジェクション、CSRF、そしてXSSが含まれます。よく知られている動的解析ツールは[OWASP Zed Attack proxy](https://owasp.org/www-project-zap/)toolです。 |
+
+{{< /table >}}
+
+## {{% heading "whatsnext" %}}
+
+関連するKubernetesセキュリティについて学びます。
+
+* [Podのセキュリティ基準](/docs/concepts/security/pod-security-standards/)
+* [PodのNetworkPolicy](/docs/concepts/services-networking/network-policies/)
+* [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)
+* [APIアクセスコントロール](/docs/reference/access-authn-authz/controlling-access/)
+* コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/)
+* [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/)
+* [Kubernetes Secret](/ja/docs/concepts/configuration/secret/)
diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md
new file mode 100644
index 0000000000..7b0f16dff1
--- /dev/null
+++ b/content/ja/docs/concepts/security/pod-security-standards.md
@@ -0,0 +1,297 @@
+---
+title: Podセキュリティの標準
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+Podに対するセキュリティの設定は通常[Security Context](/docs/tasks/configure-pod-container/security-context/)を使用して適用されます。Security ContextはPod単位での特権やアクセスコントロールの定義を実現します。
+
+クラスターにおけるSecurity Contextの強制やポリシーベースの定義は[Pod Security Policy](/docs/concepts/policy/pod-security-policy/)によって実現されてきました。
+_Pod Security Policy_ はクラスターレベルのリソースで、Pod定義のセキュリティに関する設定を制御します。
+
+しかし、PodSecurityPolicyを拡張したり代替する、ポリシーを強制するための多くの方法が生まれてきました。
+このページの意図は、推奨されるPodのセキュリティプロファイルを特定の実装から切り離して詳しく説明することです。
+
+
+
+<!-- body -->
+
+## ポリシーの種別
+
+まず、幅広いセキュリティの範囲をカバーできる、基礎となるポリシーの定義が必要です。
+それらは強く制限をかけるものから自由度の高いものまでをカバーすべきです。
+
+- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い権限を提供します。このポリシーは既知の特権昇格を認めます。
+- **_ベースライン、デフォルト_** - 制限は最小限にされたポリシーですが、既知の特権昇格を防止します。デフォルト（最小の指定）のPod設定を許容します。
+- **_制限_** - 厳しく制限されたポリシーで、Podを強化するための現在のベストプラクティスに沿っています。
+
+## ポリシー
+
+### 特権
+
+特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは通常、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。
+
+特権ポリシーは制限がないことと定義されます。gatekeeperのようにデフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定せず、何も制限を適用しないことにあたります。
+一方で、Pod Security Policyのようにデフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化してコントロールできるようにする必要があります。
+
+### ベースライン、デフォルト
+
+ベースライン、デフォルトのプロファイルは一般的なコンテナ化されたランタイムに適用しやすく、かつ既知の特権昇格を防ぐことを意図しています。
+このポリシーはクリティカルではないアプリケーションの運用者または開発者を対象にしています。
+次の項目は強制、または無効化すべきです。
+
+<table>
+	<caption style="display:none">ベースラインポリシーの定義</caption>
+	<tbody>
+		<tr>
+			<td><strong>項目</strong></td>
+			<td><strong>ポリシー</strong></td>
+		</tr>
+		<tr>
+			<td>ホストのネームスペース</td>
+			<td>
+				ホストのネームスペースの共有は無効化すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.hostNetwork<br>
+				spec.hostPID<br>
+				spec.hostIPC<br>
+				<br><b>認められる値:</b> false<br>
+			</td>
+		</tr>
+		<tr>
+			<td>特権コンテナ</td>
+			<td>
+				特権を持つPodはほとんどのセキュリティ機構を無効化できるので、禁止すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.containers[*].securityContext.privileged<br>
+				spec.initContainers[*].securityContext.privileged<br>
+				<br><b>認められる値:</b> false, undefined/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<td>ケーパビリティー</td>
+			<td>
+				<a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">デフォルト</a>よりも多くのケーパビリティーを与えることは禁止すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.containers[*].securityContext.capabilities.add<br>
+				spec.initContainers[*].securityContext.capabilities.add<br>
+				<br><b>認められる値:</b> 空 (または既知のリストに限定)<br>
+			</td>
+		</tr>
+		<tr>
+			<td>HostPathボリューム</td>
+			<td>
+				HostPathボリュームは禁止すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.volumes[*].hostPath<br>
+				<br><b>認められる値:</b> undefined/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<td>ホストのポート</td>
+			<td>
+				HostPortは禁止するか、最小限の既知のリストに限定すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.containers[*].ports[*].hostPort<br>
+				spec.initContainers[*].ports[*].hostPort<br>
+				<br><b>認められる値:</b> 0, undefined (または既知のリストに限定)<br>
+			</td>
+		</tr>
+		<tr>
+			<td>AppArmor <em>(任意)</em></td>
+			<td>
+				サポートされるホストでは、AppArmorの'runtime/default'プロファイルがデフォルトで適用されます。デフォルトのポリシーはポリシーの上書きや無効化を防ぎ、許可されたポリシーのセットを上書きできないよう制限すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
+				<br><b>認められる値:</b> 'runtime/default', undefined<br>
+			</td>
+		</tr>
+		<tr>
+			<td>SELinux <em>(任意)</em></td>
+			<td>
+				SELinuxのオプションをカスタムで設定することは禁止すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.securityContext.seLinuxOptions<br>
+				spec.containers[*].securityContext.seLinuxOptions<br>
+				spec.initContainers[*].securityContext.seLinuxOptions<br>
+				<br><b>認められる値:</b> undefined/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<td>/procマウントタイプ</td>
+			<td>
+				攻撃対象を縮小するため/procのマスクを設定し、必須とすべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.containers[*].securityContext.procMount<br>
+				spec.initContainers[*].securityContext.procMount<br>
+				<br><b>認められる値:</b> undefined/nil, 'Default'<br>
+			</td>
+		</tr>
+		<tr>
+			<td>Sysctl</td>
+			<td>
+				Sysctlはセキュリティ機構を無効化したり、ホストの全てのコンテナに影響を与えたりすることが可能なので、「安全」なサブネットを除いては禁止すべきです。
+				コンテナまたはPodの中にsysctlがありネームスペースが分離されていて、同じノードの別のPodやプロセスから分離されている場合はsysctlは安全だと考えられます。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.securityContext.sysctls<br>
+				<br><b>認められる値:</b><br>
+				kernel.shm_rmid_forced<br>
+				net.ipv4.ip_local_port_range<br>
+				net.ipv4.tcp_syncookies<br>
+				net.ipv4.ping_group_range<br>
+				undefined/空文字列<br>
+			</td>
+		</tr>
+	</tbody>
+</table>
+
+### 制限
+
+制限ポリシーはいくらかの互換性を犠牲にして、Podを強化するためのベストプラクティスを強制することを意図しています。
+セキュリティ上クリティカルなアプリケーションの運用者や開発者、また信頼度の低いユーザーも対象にしています。
+下記の項目を強制、無効化すべきです。
+
+
+<table>
+	<caption style="display:none">制限ポリシーの定義</caption>
+	<tbody>
+		<tr>
+			<td><strong>項目</strong></td>
+			<td><strong>ポリシー</strong></td>
+		</tr>
+		<tr>
+			<td colspan="2"><em>デフォルトプロファイルにある項目全て</em></td>
+		</tr>
+		<tr>
+			<td>Volumeタイプ</td>
+			<td>
+				HostPathボリュームの制限に加え、制限プロファイルではコアでない種類のボリュームの利用をPersistentVolumeにより定義されたものに限定します。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.volumes[*].hostPath<br>
+				spec.volumes[*].gcePersistentDisk<br>
+				spec.volumes[*].awsElasticBlockStore<br>
+				spec.volumes[*].gitRepo<br>
+				spec.volumes[*].nfs<br>
+				spec.volumes[*].iscsi<br>
+				spec.volumes[*].glusterfs<br>
+				spec.volumes[*].rbd<br>
+				spec.volumes[*].flexVolume<br>
+				spec.volumes[*].cinder<br>
+				spec.volumes[*].cephFS<br>
+				spec.volumes[*].flocker<br>
+				spec.volumes[*].fc<br>
+				spec.volumes[*].azureFile<br>
+				spec.volumes[*].vsphereVolume<br>
+				spec.volumes[*].quobyte<br>
+				spec.volumes[*].azureDisk<br>
+				spec.volumes[*].portworxVolume<br>
+				spec.volumes[*].scaleIO<br>
+				spec.volumes[*].storageos<br>
+				spec.volumes[*].csi<br>
+				<br><b>認められる値:</b> undefined/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<td>特権昇格</td>
+			<td>
+				特権昇格(ファイルモードのset-user-IDまたはset-group-IDのような方法による)は禁止すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.containers[*].securityContext.allowPrivilegeEscalation<br>
+				spec.initContainers[*].securityContext.allowPrivilegeEscalation<br>
+				<br><b>認められる値:</b> false<br>
+			</td>
+		</tr>
+		<tr>
+			<td>root以外での実行</td>
+			<td>
+				コンテナはroot以外のユーザーで実行する必要があります。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.securityContext.runAsNonRoot<br>
+				spec.containers[*].securityContext.runAsNonRoot<br>
+				spec.initContainers[*].securityContext.runAsNonRoot<br>
+				<br><b>認められる値:</b> true<br>
+			</td>
+		</tr>
+		<tr>
+			<td>root以外のグループ <em>(任意)</em></td>
+			<td>
+				コンテナをrootのプライマリまたは補助GIDで実行することを禁止すべきです。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.securityContext.runAsGroup<br>
+				spec.securityContext.supplementalGroups[*]<br>
+				spec.securityContext.fsGroup<br>
+				spec.containers[*].securityContext.runAsGroup<br>
+				spec.initContainers[*].securityContext.runAsGroup<br>
+				<br><b>認められる値:</b><br>
+				0以外<br>
+				undefined / nil (`*.runAsGroup`を除く)<br>
+			</td>
+		</tr>
+		<tr>
+			<td>Seccomp</td>
+			<td>
+				SeccompのRuntimeDefaultを必須とする、または特定の追加プロファイルを許可することが必要です。<br>
+				<br><b>制限されるフィールド:</b><br>
+				spec.securityContext.seccompProfile.type<br>
+				spec.containers[*].securityContext.seccompProfile<br>
+				spec.initContainers[*].securityContext.seccompProfile<br>
+				<br><b>認められる値:</b><br>
+				'runtime/default'<br>
+				undefined / nil<br>
+			</td>
+		</tr>
+	</tbody>
+</table>
+
+## ポリシーの実例
+
+ポリシーの定義とポリシーの実装を切り離すことによって、ポリシーを強制する機構とは独立して、汎用的な理解や複数のクラスターにわたる共通言語とすることができます。
+
+機構が成熟してきたら、ポリシーごとに下記に定義されます。それぞれのポリシーを強制する方法についてはここでは定義しません。
+
+[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/)
+
+- [特権](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml)
+- [ベースライン](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml)
+- [制限](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml)
+
+## FAQ
+
+### 特権とデフォルトの間のプロファイルがないのはどうしてですか?
+
+ここで定義されている3つのプロファイルは最も安全(制限)から最も安全ではない(特権)まで、直線的に段階が設定されており、幅広いワークロードをカバーしています。
+ベースラインを超える特権が必要な場合、その多くはアプリケーションに特化しているため、その限られた要求に対して標準的なプロファイルを提供することはできません。
+これは、このような場合に必ず特権プロファイルを使用すべきだという意味ではなく、場合に応じてポリシーを定義する必要があります。
+
+将来、他のプロファイルの必要性が明らかになった場合、SIG Authはこの方針について再考する可能性があります。
+
+### セキュリティポリシーとセキュリティコンテキストの違いは何ですか?
+
+[Security Context](/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。
+Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します。
+
+セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。
+2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[Pod Security
+Policy](/docs/concepts/policy/pod-security-policy/)です。これはクラスター全体にわたってセキュリティポリシーを中央集権的に強制するものです。
+セキュリティポリシーを強制する他の手段もKubernetesのエコシステムでは開発が進められています。例えば[OPA
+Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。
+
+### WindowsのPodにはどのプロファイルを適用すればよいですか?
+
+Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。
+特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+したがって、現段階では標準化されたセキュリティポリシーは存在しません。
+
+### サンドボックス化されたPodはどのように扱えばよいでしょうか?
+
+現在のところ、Podがサンドボックス化されていると見なされるかどうかを制御できるAPI標準はありません。
+サンドボックス化されたPodはサンドボックス化されたランタイム（例えばgVisorやKata Containers）の使用により特定することは可能ですが、サンドボックス化されたランタイムの標準的な定義は存在しません。
+
+サンドボックス化されたランタイムに対して必要な保護は、それ以外に対するものとは異なります。
+例えば、ワークロードがその基になるカーネルと分離されている場合、特権を制限する必要性は小さくなります。
+これにより、強い権限を必要とするワークロードが隔離された状態を維持できます。
+
+加えて、サンドボックス化されたワークロードの保護はサンドボックス化の実装に強く依存します。
+したがって、全てのサンドボックス化されたワークロードに推奨される単一のポリシーは存在しません。
diff --git a/content/ja/docs/concepts/services-networking/_index.md b/content/ja/docs/concepts/services-networking/_index.md
index 3a33830f2f..4089dc17cf 100755
--- a/content/ja/docs/concepts/services-networking/_index.md
+++ b/content/ja/docs/concepts/services-networking/_index.md
@@ -1,4 +1,12 @@
 ---
 title: "Service、負荷分散とネットワーキング"
 weight: 60
+description: >
+  Kubernetesにおけるネットワーキングの概念とリソース。
 ---
+
+Kubernetesのネットワーキングは4つの懸念事項に対処します。
+- Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。
+- クラスターネットワーキングは、異なるPod間の通信を提供します。
+- Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。
+- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。
diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md
index 0d61ce938c..423b114096 100644
--- a/content/ja/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md
@@ -23,7 +23,6 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他
 このドキュメントの残りの部分では、このようなネットワークモデルで信頼できるサービスを実行する方法について詳しく説明します。
 
 このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。
-同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。
 
 
 
@@ -140,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク
 ## Serviceにアクセスする
 
 Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
-前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
+前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
 {{< note >}}
 サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
 {{< /note >}}
@@ -400,8 +399,8 @@ kubectl edit svc my-nginx
 kubectl get svc my-nginx
 ```
 ```
-NAME       TYPE        CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
-my-nginx   ClusterIP   10.0.162.149   162.222.184.144    80/TCP,81/TCP,82/TCP  21s
+NAME       TYPE           CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
+my-nginx   LoadBalancer   10.0.162.149     xx.xxx.xxx.xxx     8080:30163/TCP        21s
 ```
 ```
 curl https://<EXTERNAL-IP> -k
diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md
index 7e65022304..4375928a45 100644
--- a/content/ja/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md
@@ -42,6 +42,20 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返
 
 ## Pod
 
+### A/AAAAレコード
+
+一般的にPodは下記のDNS解決となります。
+
+`pod-ip-address.my-namespace.pod.cluster-domain.example`
+
+例えば、`default`ネームスペースのpodのIPアドレスが172.17.0.3で、クラスターのドメイン名が`cluster.local`の場合、PodのDNS名は以下になります。
+
+`172-17-0-3.default.pod.cluster.local`
+
+DeploymentかDaemonSetに作成され、Serviceに公開されるどのPodも以下のDNS解決が利用できます。
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`
+
 ### Podのhostnameとsubdomainフィールド
 
 現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。
@@ -113,9 +127,9 @@ A(AAAA)レコードはPodの名前に対して作成されないため、`hostna
 DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。
 
 - "`Default`": そのPodはPodが稼働しているNodeから名前解決の設定を継承します。詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)を参照してください。
-- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。
+- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。このような場合におけるDNSクエリー処理の詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)を参照してください。
 - "`ClusterFirstWithHostNet`": hostNetworkによって稼働しているPodに対しては、ユーザーは明示的にDNSポリシーを"`ClusterFirstWithHostNet`"とセットするべきです。
-- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-s-dns-config)を参照ください。
+- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-dns-config)を参照ください。
 
 {{< note >}}
 "Default"は、デフォルトのDNSポリシーではありません。もし`dnsPolicy`が明示的に指定されていない場合、"ClusterFirst"が使用されます。
@@ -142,7 +156,7 @@ spec:
   dnsPolicy: ClusterFirstWithHostNet
 ```
 
-### PodのDNS設定 {#pods-dns-config}
+### PodのDNS設定 {#pod-dns-config}
 
 PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。
 
diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md
new file mode 100644
index 0000000000..5a678baec7
--- /dev/null
+++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md
@@ -0,0 +1,108 @@
+---
+title: EndpointSlice
+content_type: concept
+weight: 15
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+
+*EndpointSlice*は、Kubernetesクラスター内にあるネットワークエンドポイントを追跡するための単純な手段を提供します。EndpointSliceは、よりスケーラブルでより拡張可能な、Endpointの代わりとなるものです。
+
+<!-- body -->
+
+## 動機
+
+Endpoints APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
+
+Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
+
+## EndpointSliceリソース {#endpointslice-resource}
+
+Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+
+一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。
+
+```yaml
+apiVersion: discovery.k8s.io/v1beta1
+kind: EndpointSlice
+metadata:
+  name: example-abc
+  labels:
+    kubernetes.io/service-name: example
+addressType: IPv4
+ports:
+  - name: http
+    protocol: TCP
+    port: 80
+endpoints:
+  - addresses:
+      - "10.1.2.3"
+    conditions:
+      ready: true
+    hostname: pod-1
+    topology:
+      kubernetes.io/hostname: node-1
+      topology.kubernetes.io/zone: us-west2-a
+```
+
+デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。
+
+EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
+
+### アドレスの種類
+
+EndpointSliceは次の3種類のアドレスをサポートします。
+
+* IPv4
+* IPv6
+* FQDN (Fully Qualified Domain Name、完全修飾ドメイン名)
+
+### トポロジー
+
+EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。
+
+* `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。
+* `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。
+* `topology.kubernetes.io/region` - このエンドポイントが存在するリージョン。
+
+これらのラベルの値はスライス内の各エンドポイントと関連するリソースから継承したものです。hostnameラベルは対応するPod上のNodeNameフィールドの値を表します。zoneとregionラベルは対応するNode上の同じ名前のラベルの値を表します。
+
+### 管理
+
+EndpointSliceはデフォルトではEndpointSliceコントローラーによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
+
+### 所有権
+
+ほとんどのユースケースでは、EndpointSliceは対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
+
+## EndpointSliceコントローラー
+
+EndpointSliceコントローラーは対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーはセレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceはServiceセレクターに一致するPodのIPを表します。
+
+### EndpointSliceのサイズ
+
+デフォルトでは、それぞれのEndpointSliceのサイズの上限は100個のEndpointsに制限されています。この制限は{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。
+
+### EndpointSliceの分散
+
+それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。
+
+コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
+
+1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。
+2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。
+3. まだ追加するべき新しいエンドポイントが残っていた場合、これまで変更されなかったスライスに追加を試み、その後、新しいスライスを作成する。
+
+ここで重要なのは、3番目のステップでEndpointSliceを完全に分散させることよりも、EndpointSliceの更新を制限することを優先していることです。たとえば、もし新しい追加するべきエンドポイントが10個あり、2つのEndpointSliceにそれぞれ5個の空きがあった場合、このアプローチでは2つの既存のEndpointSliceを充填する代わりに、新しいEndpointSliceが作られます。言い換えれば、1つのEndpointSliceを作成する方が複数のEndpointSliceを更新するよりも好ましいということです。
+
+各Node上で実行されているkube-proxyはEndpointSliceを監視しており、EndpointSliceに加えられた変更はクラスター内のすべてのNodeに送信されるため、比較的コストの高い処理になります。先ほどのアプローチは、たとえ複数のEndpointSliceが充填されない結果となるとしても、すべてのNodeへ送信しなければならない変更の数を抑制することを目的としています。
+
+現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントがすべて置換されるためです。
+
+## {{% heading "whatsnext" %}}
+
+* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices)
+* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む
+
diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md
index f19d21ef43..f1af46c3a2 100644
--- a/content/ja/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ja/docs/concepts/services-networking/ingress-controllers.md
@@ -21,11 +21,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン
 
 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。
 * [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。
-* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
+* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
 * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
 * [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
 * Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。
-* F5 Networksは[F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
+* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。
 * [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
 * [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
 * [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。
diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md
index 26feb3076c..76bb234f7e 100644
--- a/content/ja/docs/concepts/services-networking/ingress.md
+++ b/content/ja/docs/concepts/services-networking/ingress.md
@@ -33,15 +33,15 @@ weight: 40
    [ Services ]
 ```
 
-IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
+IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
 
 Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。
 
 ## Ingressを使用する上での前提条件
 
-Ingressを提供するためには[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。
+Ingressを提供するためには[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。
 
-[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択してください。
+[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の中から選択してください。
 
 理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすはずです。しかし実際には、各Ingressコントローラーは微妙に異なる動作をします。
 
@@ -65,14 +65,15 @@ spec:
   - http:
       paths:
       - path: /testpath
+        pathType: Prefix
         backend:
           serviceName: test
           servicePort: 80
 ```
 
-他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
+他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
 
-Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。
+Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
 
 ### Ingressのルール
 
@@ -86,10 +87,65 @@ Ingressコントローラーでは、デフォルトのバックエンドが設
 
 ### デフォルトのバックエンド
 
-ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
+ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
 
 IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
 
+### パスのタイプ
+
+Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。
+
+* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
+
+* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。
+
+* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
+  
+  {{< note >}}
+  パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。
+  {{< /note >}}
+
+#### 複数のパスとの一致
+
+リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。
+
+## Ingress Class
+
+Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。
+IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: IngressClass
+metadata:
+  name: external-lb
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    apiGroup: k8s.example.com/v1alpha
+    kind: IngressParameters
+    name: external-lb
+```
+
+IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。
+
+### 非推奨のアノテーション
+
+Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールドが追加される前は、Ingressの種別はIngressの`kubernetes.io/ingress.class`アノテーションにより指定されていました。
+このアノテーションは正式に定義されたことはありませんが、Ingressコントローラーに広くサポートされています。
+
+Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。
+アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。
+
+### デフォルトのIngress Class
+
+特定のIngressClassをクラスターでのデフォルトとすることができます。
+IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。
+
+{{< caution >}}
+複数のIngressClassをクラスターのデフォルトに設定すると、アドミッションコントローラーは`ingressClassName`が指定されていないIngressオブジェクトの作成を防ぐようになります。クラスターのデフォルトのIngressClassを1つ以下にすることで、これを解消することができます。
+{{< /caution >}}
+
 ## Ingressのタイプ
 
 ### 単一ServiceのIngress
@@ -176,7 +232,7 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
 
 {{< note >}}
-使用する[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
+使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
 {{< /note >}}
 
 ### 名前ベースのバーチャルホスティング
@@ -268,16 +324,16 @@ metadata:
 spec:
   tls:
   - hosts:
-    - sslexample.foo.com
+      - sslexample.foo.com
     secretName: testsecret-tls
   rules:
-    - host: sslexample.foo.com
-      http:
-        paths:
-        - path: /
-          backend:
-            serviceName: service1
-            servicePort: 80
+  - host: sslexample.foo.com
+    http:
+      paths:
+      - path: /
+        backend:
+          serviceName: service1
+          servicePort: 80
 ```
 
 {{< note >}}
@@ -288,7 +344,7 @@ spec:
 
 Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
 
-Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
 
 ## Ingressの更新
 
@@ -374,7 +430,7 @@ Events:
 
 ## アベイラビリティーゾーンをまたいだ障害について
 
-障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
+障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
 
 ## 将来追加予定の内容
 
@@ -390,6 +446,5 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
 
 ## {{% heading "whatsnext" %}}
 * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
-* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
+* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
 * [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
-
diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md
new file mode 100644
index 0000000000..61a798b947
--- /dev/null
+++ b/content/ja/docs/concepts/services-networking/network-policies.md
@@ -0,0 +1,200 @@
+---
+title: ネットワークポリシー
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
+
+NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
+
+<!-- body -->
+## 前提条件
+
+ネットワークポリシーは、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)により実装されます。ネットワークポリシーを使用するには、NetworkPolicyをサポートするネットワークソリューションを使用しなければなりません。ネットワークポリシーを実装したコントローラーを使用せずにNetworkPolicyリソースを作成した場合は、何も効果はありません。
+
+## 分離されたPodと分離されていないPod
+
+デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。
+
+Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(同じ名前空間内のPodでも、どのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。)
+
+ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。
+
+## NetworkPolicyリソース {#networkpolicy-resource}
+
+リソースの完全な定義については、リファレンスの[NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)のセクションを参照してください。
+
+以下は、NetworkPolicyの一例です。
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: test-network-policy
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+  - Ingress
+  - Egress
+  ingress:
+  - from:
+    - ipBlock:
+        cidr: 172.17.0.0/16
+        except:
+        - 172.17.1.0/24
+    - namespaceSelector:
+        matchLabels:
+          project: myproject
+    - podSelector:
+        matchLabels:
+          role: frontend
+    ports:
+    - protocol: TCP
+      port: 6379
+  egress:
+  - to:
+    - ipBlock:
+        cidr: 10.0.0.0/24
+    ports:
+    - protocol: TCP
+      port: 5978
+```
+
+{{< note >}}
+選択したネットワークソリューションがネットワークポリシーをサポートしていない場合には、これをクラスターのAPIサーバーにPOSTしても効果はありません。
+{{< /note >}}
+
+__必須フィールド__: 他のKubernetesの設定と同様に、NetworkPolicyにも`apiVersion`、`kind`、`metadata`フィールドが必須です。設定ファイルの扱い方に関する一般的な情報については、[ConfigMapを使用してコンテナを構成する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)と[オブジェクト管理](/ja/docs/concepts/overview/working-with-objects/object-management)を参照してください。
+
+__spec__: NetworkPolicyの[spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を見ると、指定した名前空間内で特定のネットワークポリシーを定義するのに必要なすべての情報が確認できます。
+
+__podSelector__: 各NetworkPolicyには、ポリシーを適用するPodのグループを選択する`podSelector`が含まれます。ポリシーの例では、ラベル"role=db"を持つPodを選択しています。`podSelector`を空にすると、名前空間内のすべてのPodが選択されます。
+
+__policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、`Egress`、またはその両方からなるリストが含まれます。`policyTypes`フィールドでは、指定したポリシーがどの種類のトラフィックに適用されるかを定めます。トラフィックの種類としては、選択したPodへの内向きのトラフィック(Ingress)、選択したPodからの外向きのトラフィック(Egress)、またはその両方を指定します。`policyTypes`を指定しなかった場合、デフォルトで常に
+`Ingress`が指定され、NetworkPolicyにegressルールが1つでもあれば`Egress`も設定されます。
+
+__ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。
+
+__egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`to`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。
+
+したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。
+
+1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(まだ分離されていない場合)
+2. (Ingressルール) "default"名前空間内の"role=db"ラベルが付いたすべてのPodのTCPの6379番ポートへの接続のうち、次の送信元からのものを許可する
+   * "default"名前空間内のラベル"role=frontend"が付いたすべてのPod
+   * ラベル"project=myproject"が付いた名前空間内のすべてのPod
+   * 172.17.0.0–172.17.0.255および172.17.2.0–172.17.255.255(言い換えれば、172.17.1.0/24の範囲を除く172.17.0.0/16)の範囲内のすべてのIPアドレス
+3. (Egressルール) "role=db"というラベルが付いた"default"名前空間内のすべてのPodからの、TCPの5978番ポート上でのCIDR 10.0.0.0/24への接続を許可する
+
+追加の例については、[ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)の説明を参照してください。
+
+## `to`と`from`のセレクターの振る舞い
+
+`ingress`の`from`セクションまたは`egress`の`to`セクションに指定できるセレクターは4種類あります。
+
+__podSelector__: NetworkPolicyと同じ名前空間内の特定のPodを選択して、ingressの送信元またはegressの送信先を許可します。
+
+__namespaceSelector__: 特定の名前空間を選択して、その名前空間内のすべてのPodについて、ingressの送信元またはegressの送信先を許可します。
+
+__namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エントリーで`namespaceSelector`と`podSelector`の両方を指定して、特定の名前空間内の特定のPodを選択します。正しいYAMLの構文を使うように気をつけてください。このポリシーの例を以下に示します。
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+      podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の付いたPodからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+    - podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+このポリシーには、`from`配列の中に2つの要素があります。そのため、ラベル`role=client`の付いた名前空間内にあるすべてのPodからの接続、*または*、任意の名前空間内にあるラベル`user=alice`の付いたすべてのPodからの接続を許可します。
+
+正しいルールになっているか自信がないときは、`kubectl describe`を使用すると、Kubernetesがどのようにポリシーを解釈したのかを確認できます。
+
+__ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元またはegressの送信先を許可します。PodのIPは一時的なもので予測できないため、ここにはクラスター外のIPを指定するべきです。
+
+クラスターのingressとegressの仕組みはパケットの送信元IPや送信先IPの書き換えを必要とすることがよくあります。その場合、NetworkPolicyの処理がIPの書き換えの前後どちらで行われるのかは定義されていません。そのため、ネットワークプラグイン、クラウドプロバイダー、`Service`の実装などの組み合わせによっては、動作が異なる可能性があります。
+
+内向きのトラフィックの場合は、実際のオリジナルの送信元IPに基づいてパケットをフィルタリングできる可能性もあれば、NetworkPolicyが対象とする「送信元IP」が`LoadBalancer`やPodのノードなどのIPになってしまっている可能性もあることになります。
+
+外向きのトラフィックの場合は、クラスター外のIPに書き換えられたPodから`Service`のIPへの接続は、`ipBlock`ベースのポリシーの対象になる場合とならない場合があることになります。
+
+## デフォルトのポリシー
+
+デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間内のPodの内向きと外向きのトラフィックはすべて許可されます。以下の例を利用すると、その名前空間内でのデフォルトの振る舞いを変更できます。
+
+### デフォルトですべての内向きのトラフィックを拒否する
+
+すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
+
+このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。
+
+### デフォルトで内向きのすべてのトラフィックを許可する
+
+(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
+
+### デフォルトで外向きのすべてのトラフィックを拒否する
+
+すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
+
+このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。
+
+### デフォルトで外向きのすべてのトラフィックを許可する
+
+(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
+
+### デフォルトで内向きと外向きのすべてのトラフィックを拒否する
+
+名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
+
+このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。
+
+## SCTPのサポート
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
+
+{{< note >}}
+SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。
+{{< /note >}}
+
+## {{% heading "whatsnext" %}}
+
+- [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。
+- NetworkPolicyリソースで実現できるよくあるシナリオのためのさまざまな[レシピ](https://github.com/ahmetb/kubernetes-network-policy-recipes)を確認する。
diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md
index e23ab9312f..2b3d6b26e0 100644
--- a/content/ja/docs/concepts/services-networking/service.md
+++ b/content/ja/docs/concepts/services-networking/service.md
@@ -143,6 +143,14 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊
 
 エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
 
+### アプリケーションプロトコル
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。
+
+アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。
+
 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}
 
 Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
@@ -272,7 +280,7 @@ Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主
 
 PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。
 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
-[makeLinkVariables関数](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
+[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
 
 例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。
 
@@ -373,6 +381,26 @@ NodePortの使用は、Kubernetesによって完全にサポートされてい
 注意点として、このServiceは`<NodeIP>:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。
 (もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、<NodeIP>はフィルターされたNodeIPとなります。)
 
+例えば:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  type: NodePort
+  selector:
+    app: MyApp
+  ports:
+      # デフォルトでは利便性のため、 `targetPort` は `port` と同じ値にセットされます。
+    - port: 80
+      targetPort: 80
+      # 省略可能なフィールド
+      # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲:30000-32767)
+      nodePort: 30007
+```
+
 ### LoadBalancer タイプ {#loadbalancer}
 
 外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。
@@ -461,6 +489,17 @@ metadata:
         service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+{{% /tab %}}
+{{% tab name="IBM Cloud" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
+[...]
+```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
 ```yaml
@@ -532,7 +571,7 @@ TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBは
 
 上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシーとなります。
 
-Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。
+Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。
 どのポリシーが使用できるかを確認するために、`aws`コマンドラインツールを使用できます。
 
 ```bash
@@ -654,7 +693,7 @@ AWSでNetwork Load Balancerを使用するには、値を`nlb`に設定してア
 ```
 
 {{< note >}}
-NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。
+NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。
 {{< /note >}}
 
 古いタイプのElastic Load Balancersとは異なり、Network Load Balancers (NLBs)はクライアントのIPアドレスをNodeに転送します。
@@ -663,7 +702,7 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー
 `.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。
 特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。
 
-均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。
+均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。
 
 また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。
 
@@ -689,7 +728,7 @@ spec:
 
 {{< /note >}}
 
-#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション
+#### Tencent Kubernetes Engine(TKE)におけるその他のCLBアノテーション
 
 以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。
 
@@ -700,7 +739,7 @@ spec:
         # 指定したノードでロードバランサーをバインドします
         service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)
         # 既存のロードバランサーのID
-        service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx
+        service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx
 
         # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません
         service.kubernetes.io/service.extensiveParameters: ""
@@ -714,7 +753,7 @@ spec:
         # パブリックネットワーク帯域幅の課金方法を指定します
         # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth)
         service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx
-        # 帯域幅の値を指定します(値の範囲：[1-2000] Mbps)。
+        # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。
         service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
         # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
         # そうでない場合、すべてのノードが登録されます
@@ -785,10 +824,10 @@ spec:
   - 80.11.12.10
 ```
 
-## Serviceのデメリット
+## Serviceの欠点
 
 仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。
-これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。
+これについては、[Serviceのデザインプロポーザル](https://github.com/kubernetes/kubernetes/issues/1107)にてさらなる詳細を確認できます。
 
 userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。
 これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。
@@ -812,8 +851,8 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
 各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。
 そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。
 
-コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesのマイグレーションも必要です)。
-また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
+コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesからのマイグレーションをサポートすることも必要です)。
+また、Kubernetesは(例えば、管理者の介入によって)無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
 
 ### ServiceのIPアドレス {#ips-and-vips}
 
@@ -894,9 +933,9 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}
 
-KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
+KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
 
-そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
+そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。
 
 #### 警告 {#caveat-sctp-overview}
@@ -936,5 +975,3 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理
 * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
-
-
diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md
index 848b152a4e..24bcea4ee5 100644
--- a/content/ja/docs/concepts/storage/persistent-volumes.md
+++ b/content/ja/docs/concepts/storage/persistent-volumes.md
@@ -11,7 +11,7 @@ weight: 20
 
 <!-- overview -->
 
-このドキュメントではKubernetesの`PersistentVolume`について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
+このドキュメントではKubernetesの _PersistentVolume_ について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
 
 
 
@@ -20,13 +20,13 @@ weight: 20
 
 ## 概要
 
-ストレージを管理することはインスタンスを管理することとは全くの別物です。`PersistentVolume`サブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するための`PersistentVolume`と`PersistentVolumeClaim`という2つの新しいAPIリソースを紹介します。
+ストレージを管理することはインスタンスを管理することとは全くの別物です。PersistentVolumeサブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するためのPersistentVolumeとPersistentVolumeClaimという2つの新しいAPIリソースを紹介します。
 
-`PersistentVolume`(PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。
+_PersistentVolume_ (PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。
 
-`PersistentVolumeClaim`(PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます。
+_PersistentVolumeClaim_ (PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、ReadWriteOnce、ReadOnlyMany、ReadWriteManyにマウントできます。詳しくは[アクセスモード](#access-modes)を参照してください)を要求することができます。
 
-`PersistentVolumeClaim`はユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持った`PersistentVolume`を必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々な`PersistentVolume`を提供できる必要があります。これらのニーズに応えるために`StorageClass`リソースがあります。
+PersistentVolumeClaimはユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持ったPersistentVolumeを必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々なPersistentVolumeを提供できる必要があります。これらのニーズに応えるために _StorageClass_ リソースがあります。
 
 [実例を含む詳細なチュートリアル](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)を参照して下さい。
 
@@ -45,8 +45,8 @@ PVは静的か動的どちらかでプロビジョニングされます。
 
 #### 動的
 
-ユーザーの`PersistentVolumeClaim`が管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
-このプロビジョニングは`StorageClass`に基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。
+ユーザーのPersistentVolumeClaimが管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
+このプロビジョニングはStorageClassに基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。
 
 ストレージクラスに基づいたストレージの動的プロビジョニングを有効化するには、クラスター管理者が`DefaultStorageClass`[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)をAPIサーバーで有効化する必要があります。
 これは例えば、`DefaultStorageClass`がAPIサーバーコンポーネントの`--enable-admission-plugins`フラグのコンマ区切りの順序付きリストの中に含まれているかで確認できます。
@@ -114,19 +114,19 @@ Events:            <none>
 
 ### 再クレーム
 
-ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。`PersistentVolume`の再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。
+ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。PersistentVolumeの再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。
 
 #### 保持
 
-`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。`PersistentVolumeClaim`が削除される時、`PersistentVolume`は依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。
+`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。PersistentVolumeClaimが削除される時、PersistentVolumeは依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。
 
-1. `PersistentVolume`を削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
+1. PersistentVolumeを削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
 1. ストレージアセットに関連するのデータを手動で適切にクリーンアップします。
-1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共に`PersistentVolume`を作成します。
+1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共にPersistentVolumeを作成します。
 
 #### 削除
 
-`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除すると`PersistentVolume`オブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[`StorageClass`の再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じて`StorageClass`を構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。
+`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除するとPersistentVolumeオブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[StorageClassの再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じてStorageClassを構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。
 
 #### リサイクル
 
@@ -136,7 +136,9 @@ Events:            <none>
 
 基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。
 
-管理者は[こちら](/docs/admin/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
+管理者は[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
+
+
 
 ```yaml
 apiVersion: v1
@@ -194,7 +196,7 @@ parameters:
 allowVolumeExpansion: true
 ```
 
-PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これにより`PersistentVolume`を受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しく`PersistentVolume`が作成されることはありません。代わりに既存のボリュームがリサイズされます。
+PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これによりPersistentVolumeを受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しくPersistentVolumeが作成されることはありません。代わりに既存のボリュームがリサイズされます。
 
 #### CSIボリュームの拡張
 
@@ -231,10 +233,19 @@ FlexVolumeのリサイズは、基盤となるドライバーがリサイズを
 EBSの拡張は時間がかかる操作です。また変更は、ボリュームごとに6時間に1回までというクォータもあります。
 {{< /note >}}
 
+#### ボリューム拡張時の障害からの復旧
+
+基盤ストレージの拡張に失敗した際には、クラスターの管理者はPersistent Volume Claim (PVC)の状態を手動で復旧し、リサイズ要求をキャンセルします。それをしない限り、リサイズ要求は管理者の介入なしにコントローラーによって継続的に再試行されます。  
+
+1. PersistentVolumeClaim(PVC)にバインドされているPersistentVolume(PV)を`Retain`再クレームポリシーとしてマークします。
+2. PVCを削除します。PVは`Retain`再クレームポリシーを持っているため、PVCを再び作成したときにいかなるデータも失うことはありません。  
+3. `claimRef`エントリーをPVスペックから削除して、新しいPVCがそれにバインドできるようにします。これによりPVは`Available`になります。  
+4. PVより小さいサイズでPVCを再作成し、PVCの`volumeName`フィールドをPVの名前に設定します。これにより新しいPVCを既存のPVにバインドします。  
+5. PVを再クレームポリシーを復旧することを忘れずに行ってください。  
 
 ## 永続ボリュームの種類
 
-`PersistentVolume`の種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
+PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
 
 * GCEPersistentDisk
 * AWSElasticBlockStore
@@ -297,13 +308,22 @@ spec:
 
 ### ボリュームモード
 
-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
-Kubernetes 1.9より前は、すべてのボリュームプラグインが永続ボリュームにファイルシステムを作成していました。現在はRawブロックデバイスを使うために`volumeMode`の値を`block`に設定するか、ファイルシステムを使うために`filesystem`を設定できます。値が省略された場合のデフォルトは`filesystem`です。これはオプションのAPIパラメーターです。
+KubernetesはPersistentVolumesの2つの`volumeModes`をサポートしています: `Filesystem`と`Block`です。  
+`volumeMode`は任意のAPIパラメーターです。  
+`Filesystem`は`volumeMode`パラメーターが省略されたときに使用されるデフォルトのモードです。  
+
+`volumeMode: Filesystem`であるボリュームはPodに*マウント*されてディレクトリになります。 ボリュームがブロックデバイスでデバイスが空の時、Kubernetesは初めてそれにマウントされる前にデバイスのファイルシステムを作成します。  
+
+`volumeMode`の値を`Block`に設定してボリュームをRAWブロックデバイスとして使用します。  
+このようなボリュームは、ファイルシステムを持たないブロックデバイスとしてPodに提示されます。  
+このモードは、Podとボリュームの間のファイルシステムレイヤなしにボリュームにアクセスする可能な限り最速の方法をPodに提供するのに便利です。一方で、Pod上で実行しているアプリケーションはRAWブロックデバイスの扱い方を知っていなければなりません。  
+Pod内で`volumeMode: Block`とともにボリュームを使用する例としては、[Raw Block Volume Support](#raw-block-volume-support)を参照してください。
 
 ### アクセスモード
 
-`PersistentVolume`は、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。
+PersistentVolumeは、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。
 
 アクセスモードは次の通りです。
 
@@ -476,7 +496,7 @@ PVCが`selector`を要求することに加えて`StorageClass`を指定する
 
 ## ボリュームとしてのクレーム
 
-Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援している`PersistentVolume`を取得します。次に、ボリュームがホストとPodにマウントされます。
+Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援しているPersistentVolumeを取得します。次に、ボリュームがホストとPodにマウントされます。
 
 ```yaml
 apiVersion: v1
@@ -498,29 +518,26 @@ spec:
 
 ### 名前空間に関する注意
 
-`PersistentVolume`バインドは排他的であり、`PersistentVolumeClaim`は名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。
+PersistentVolumeバインドは排他的であり、PersistentVolumeClaimは名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。
 
 ## Rawブロックボリュームのサポート
 
-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
 次のボリュームプラグインは、必要に応じて動的プロビジョニングを含むrawブロックボリュームをサポートします。
 
 * AWSElasticBlockStore
 * AzureDisk
+* CSI
 * FC (Fibre Channel)
 * GCEPersistentDisk
 * iSCSI
 * Local volume
+* OpenStack Cinder
 * RBD (Ceph Block Device)
-* VsphereVolume (alpha)
+* VsphereVolume 
 
-{{< note >}}
-Kubernetes 1.9では、FCおよびiSCSIボリュームのみがrawブロックボリュームをサポートしていました。
-追加のプラグインのサポートは1.10で追加されました。
-{{< /note >}}
-
-### Rawブロックボリュームを使用した永続ボリューム
+### Rawブロックボリュームを使用した永続ボリューム {#persistent-volume-using-a-raw-block-volume}
 
 ```yaml
 apiVersion: v1
@@ -584,7 +601,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス
 
 ### ブロックボリュームのバインド
 
-ユーザーが`PersistentVolumeClaim`specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。
+ユーザーがPersistentVolumeClaim specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。
 
 | PVボリュームモード | PVCボリュームモード | 結果         |
 | -------------------|:-------------------:| ------------:|
@@ -610,7 +627,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス
 
 ボリュームスナップショットのデータソースからボリュームを復元する機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
 
-### ボリュームスナップショットから永続ボリュームクレームを作成する
+### ボリュームスナップショットから永続ボリュームクレームを作成する {#create-persistent-volume-claim-from-volume-snapshot}
 
 ```yaml
 apiVersion: v1
@@ -632,13 +649,11 @@ spec:
 
 ## ボリュームの複製
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-
-ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
+[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)はCSIボリュームプラグインにのみ利用可能です。
 
 PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
 
-### 既存のPVCからの永続ボリュームクレーム作成
+### 既存のPVCからの永続ボリュームクレーム作成 {#create-persistent-volume-claim-from-an-existing-pvc} 
 
 ```yaml
 apiVersion: v1
@@ -664,7 +679,7 @@ spec:
 - 構成にPersistentVolumeClaimオブジェクトを含める(DeploymentやConfigMapと共に)
 - ユーザーが設定をインスタンス化する際にPersistentVolumeを作成する権限がない場合があるため、設定にPersistentVolumeオブジェクトを含めない。
 - テンプレートをインスタンス化する時にストレージクラス名を指定する選択肢をユーザーに与える
-  - ユーザーがストレージクラス名を指定する場合、`persistentVolumeClaim.storageClassName`フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
+  - ユーザーがストレージクラス名を指定する場合、persistentVolumeClaim.storageClassName フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
   - ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
 - ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
 
diff --git a/content/ja/docs/concepts/storage/storage-capacity.md b/content/ja/docs/concepts/storage/storage-capacity.md
new file mode 100644
index 0000000000..7e2f6c34f7
--- /dev/null
+++ b/content/ja/docs/concepts/storage/storage-capacity.md
@@ -0,0 +1,81 @@
+---
+title: ストレージ容量
+content_type: concept
+weight: 45
+---
+
+<!-- overview -->
+
+ストレージ容量は、Podが実行されるノードごとに制限があったり、大きさが異なる可能性があります。たとえば、NASがすべてのノードからはアクセスできなかったり、初めからストレージがノードローカルでしか利用できない可能性があります。
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+このページでは、Kubernetesがストレージ容量を追跡し続ける方法と、スケジューラーがその情報を利用して、残りの未作成のボリュームのために十分なストレージ容量へアクセスできるノード上にどのようにPodをスケジューリングするかについて説明します。もしストレージ容量の追跡がなければ、スケジューラーは、ボリュームをプロビジョニングするために十分な容量のないノードを選択してしまい、スケジューリングの再試行が複数回行われてしまう恐れがあります。
+
+ストレージ容量の追跡は、{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}(CSI)向けにサポートされており、CSIドライバーのインストール時に[有効にする必要があります](#enabling-storage-capacity-tracking)。
+
+<!-- body -->
+
+## API
+
+この機能には、以下の2つのAPI拡張があります。
+
+- [CSIStorageCapacity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csistoragecapacity-v1alpha1-storage-k8s-io)オブジェクト: このオブジェクトは、CSIドライバーがインストールされた名前空間に生成されます。各オブジェクトには1つのストレージクラスに対する容量の情報が含まれ、そのストレージに対してどのノードがアクセス権を持つかが定められています。
+
+- [`CSIDriverSpec.StorageCapacity`フィールド](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): `true`に設定すると、Kubernetesのスケジューラーが、CSIドライバーを使用するボリュームに対してストレージ容量を考慮するようになります。
+
+## スケジューリング
+
+ストレージ容量の情報がKubernetesのスケジューラーで利用されるのは、以下のすべての条件を満たす場合です。
+
+- `CSIStorageCapacity`フィーチャーゲートがtrueである
+- Podがまだ作成されていないボリュームを使用する時
+- そのボリュームが、CSIドライバーを参照し、[volume binding mode](/docs/concepts/storage/storage-classes/#volume-binding-mode)に`WaitForFirstConsumer`を使う{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を使用している
+- ドライバーに対する`CSIDriver`オブジェクトの`StorageCapacity`がtrueに設定されている
+
+その場合、スケジューラーはPodに対して、十分なストレージ容量が利用できるノードだけを考慮するようになります。このチェックは非常に単純で、ボリュームのサイズと、`CSIStorageCapacity`オブジェクトに一覧された容量を、ノードを含むトポロジーで比較するだけです。
+
+volume binding modeが`Immediate`のボリュームの場合、ストレージドライバーはボリュームを使用するPodとは関係なく、ボリュームを作成する場所を決定します。次に、スケジューラーはボリュームが作成された後、Podをボリュームが利用できるノードにスケジューリングします。
+
+[CSI ephemeral volumes](/docs/concepts/storage/volumes/#csi)の場合、スケジューリングは常にストレージ容量を考慮せずに行われます。このような動作になっているのは、このボリュームタイプはノードローカルな特別なCSIドライバーでのみ使用され、そこでは特に大きなリソースが必要になることはない、という想定に基づいています。
+
+## 再スケジューリング
+
+`WaitForFirstConsumer`ボリュームがあるPodに対してノードが選択された場合は、その決定はまだ一時的なものです。次のステップで、CSIストレージドライバーに対して、選択されたノード上でボリュームが利用可能になることが予定されているというヒントを使用してボリュームの作成を要求します。
+
+Kubernetesは古い容量の情報をもとにノードを選択する場合があるため、実際にはボリュームが作成できないという可能性が存在します。その場合、ノードの選択がリセットされ、KubernetesスケジューラーはPodに割り当てるノードを再び探します。
+
+## 制限
+
+ストレージ容量を追跡することで、1回目の試行でスケジューリングが成功する可能性が高くなります。しかし、スケジューラーは潜在的に古い情報に基づいて決定を行う可能性があるため、成功を保証することはできません。通常、ストレージ容量の情報が存在しないスケジューリングと同様のリトライの仕組みによって、スケジューリングの失敗に対処します。
+
+スケジューリングが永続的に失敗する状況の1つは、Podが複数のボリュームを使用する場合で、あるトポロジーのセグメントで1つのボリュームがすでに作成された後、もう1つのボリュームのために十分な容量が残っていないような場合です。この状況から回復するには、たとえば、容量を増加させたり、すでに作成されたボリュームを削除するなどの手動での対応が必要です。この問題に自動的に対処するためには、まだ[追加の作業](https://github.com/kubernetes/enhancements/pull/1703)が必要となっています。
+
+## ストレージ容量の追跡を有効にする {#enabling-storage-capacity-tracking}
+
+ストレージ容量の追跡は*アルファ機能*であり、`CSIStorageCapacity`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)と`storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}}を有効にした場合にのみ、有効化されます。詳細については、`--feature-gates`および`--runtime-config` [kube-apiserverパラメータ](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。
+
+Kubernetesクラスターがこの機能をサポートしているか簡単に確認するには、以下のコマンドを実行して、CSIStorageCapacityオブジェクトを一覧表示します。
+
+```shell
+kubectl get csistoragecapacities --all-namespaces
+```
+
+クラスターがCSIStorageCapacityをサポートしていれば、CSIStorageCapacityのリストが表示されるか、次のメッセージが表示されます。
+```
+No resources found
+```
+
+もしサポートされていなければ、代わりに次のエラーが表示されます。
+
+```
+error: the server doesn't have a resource type "csistoragecapacities"
+```
+
+クラスター内で機能を有効化することに加えて、CSIドライバーもこの機能をサポートしている必要があります。詳細については、各ドライバーのドキュメントを参照してください。
+
+## {{% heading "whatsnext" %}}
+
+ - 設計に関するさらなる情報について知るために、[Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)を読む。
+- この機能の今後の開発に関する情報について知るために、[enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)を参照する。
+- [Kubernetesのスケジューラー](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)についてもっと学ぶ。
diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md
index 32e3cfb1b0..fc1b7ae4b9 100644
--- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md
+++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md
@@ -6,7 +6,6 @@ weight: 30
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
 このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
 
 
@@ -31,6 +30,7 @@ weight: 30
 * 複製は同じストレージクラス内でのみサポートされます。
     - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。
     - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。
+* 複製は同じVolumeMode設定を使用する2つのボリューム間でのみ実行できます(ブロックモードのボリュームを要求する場合、ソースもブロックモードである必要があります)。
 
 
 ## プロビジョニング
diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md
index 60e8e68370..5f820a187a 100644
--- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md
@@ -8,7 +8,7 @@ weight: 80
 
 {{< feature-state for_k8s_version="v1.8" state="beta" >}}
 
-_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。
+_CronJob_ は繰り返しのスケジュールによって{{< glossary_tooltip term_id="job" text="Job" >}}を作成します。
 
 _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。
 [Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。
@@ -22,13 +22,25 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら
 CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。
 名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。
 
-cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
 
 
 
 <!-- body -->
 
-## CronJobの制限
+## CronJob
+
+CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。
+CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするなど、特定の時間に個々のタスクをスケジュールすることもできます。
+
+### 例
+
+このCronJobマニフェスト例は、毎分ごとに現在の時刻とhelloメッセージを表示します。
+
+{{< codenew file="application/job/cronjob.yaml" >}}
+
+([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
+
+## CronJobの制限 {#cron-job-limitations}
 
 cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1つのジョブオブジェクトを作成します。ここで _おおよそ_ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは _冪等_ であるべきです。
 
@@ -50,4 +62,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 
 CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
 
+## {{% heading "whatsnext" %}}
 
+[Cron表現形式](https://en.wikipedia.org/wiki/Cron)では、CronJobの`schedule`フィールドのフォーマットを説明しています。
+
+cronジョブの作成や動作の説明、CronJobマニフェストの例については、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)を見てください。
diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md
index a985ccf2fa..363a549997 100644
--- a/content/ja/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md
@@ -2,7 +2,7 @@
 reviewers:
 title: DaemonSet
 content_type: concept
-weight: 50
+weight: 40
 ---
 
 <!-- overview -->
@@ -11,12 +11,11 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー
 
 DaemonSetのいくつかの典型的な使用例は以下の通りです。
 
-- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。
-- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。
-- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。
+- クラスターのストレージデーモンを全てのNode上で稼働させる。
+- ログ集計デーモンを全てのNode上で稼働させる。
+- Nodeのモニタリングデーモンを全てのNode上で稼働させる。
 
-シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
-さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
+シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
 
 
 
@@ -27,8 +26,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
 
 ### DaemonSetの作成
 
-ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。  
-例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。
+ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。
 
 {{< codenew file="controllers/daemonset.yaml" >}}
 
@@ -40,8 +38,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 ### 必須のフィールド
 
-他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。  
-設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
+他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
 
 DaemonSetオブジェクトの名前は、有効な
 [DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
@@ -52,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な
 
 `.spec.template`は`.spec`内での必須のフィールドの1つです。
 
-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、[Pod](/ja/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。
 
 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
 
@@ -60,7 +57,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts
 
 ### Podセレクター
 
-`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)の`.spec.selector`と同じものです。
+`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。
 
 Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。
 
@@ -75,11 +72,10 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ
 
 また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{<glossary_tooltip term_id = "controller">}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。
 
-### 特定のいくつかのNode上のみにPodを稼働させる
+### 選択したNode上でPodを稼働させる
 
 もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node
-selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。  
-同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/configuration/assign-pod-node/)マッチするPodをNode上に作成します。
+selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするPodをNode上に作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)マッチするPodをNode上に作成します。
 もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。
 
 ## Daemon Podがどのようにスケジューリングされるか
@@ -94,7 +90,7 @@ DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働さ
  * 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。
  * [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。
 
-`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。
+`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます(ターゲットホストを選択する前に、元のNodeAffinityが考慮されます)。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。
 
 ```yaml
 nodeAffinity:
@@ -111,17 +107,16 @@ nodeAffinity:
 
 ### TaintsとTolerations
 
-DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。  
-下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
+DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
 
-| Toleration Key                           | Effect     | Version | Description                                                  |
-| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
-| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+    | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
-| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+    | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
-| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    |                                                              |
-| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    |                                                              |
-| `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。                                                |
-| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。  
+| Toleration Key                           | Effect     | Version | Description |
+| ---------------------------------------- | ---------- | ------- | ----------- |
+| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
+| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
+| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 |
+| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 |
 
 ## Daemon Podとのコミュニケーション
 
@@ -158,8 +153,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`
 
 ### 静的Pod Pods
 
-Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/concepts/cluster-administration/static-pod/)と呼ばれます。  
-DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
+Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
 
 ### Deployment
 
@@ -168,4 +162,3 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ
 フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
 Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
 
-
diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md
index f3b210ff4a..94e04e56ee 100644
--- a/content/ja/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ja/docs/concepts/workloads/controllers/deployment.md
@@ -6,14 +6,14 @@ feature:
     Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。
 
 content_type: concept
-weight: 30
+weight: 10
 ---
 
 <!-- overview -->
 
-_Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
+_Deployment_ は{{< glossary_tooltip text="Pod" term_id="pod" >}}と{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}の宣言的なアップデート機能を提供します。
 
-Deploymentにおいて_理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。
+Deploymentにおいて _理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。
 
 {{< note >}}
 Deploymentによって作成されたReplicaSetを管理しないでください。ご自身のユースケースが以下の項目に含まれない場合、メインのKubernetesリポジトリーにIssueを作成することを検討してください。
@@ -44,21 +44,22 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 この例では、
 
 * `.metadata.name`フィールドで指定された`nginx-deployment`という名前のDeploymentが作成されます。
-* このDeploymentは`replicas`フィールドで指定された通り、3つのレプリカPodを作成します。
-* `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(`app: nginx`)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
+* このDeploymentは`.spec.replicas`フィールドで指定された通り、3つのレプリカPodを作成します。
+* `.spec.selector`フィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(`app: nginx`)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
 
     {{< note >}}
-    `matchLabels`フィールドはキーバリューペアのマップです。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。
+    `.spec.selector.matchLabels`フィールドはキーバリューペアのマップです。
+    `matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。
     `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
     {{< /note >}}
 
 * `template`フィールドは、以下のサブフィールドを持ちます。:
-  * Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられます。
+  * Podは`.metadata.labels`フィールドによって指定された`app: nginx`というラベルがつけられます。
   * PodTemplate、または`.template.spec`フィールドは、Podが`nginx`という名前で[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.14.2が動くコンテナを1つ動かすことを示します。
-  * 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます。
+  * 1つのコンテナを作成し、`.spec.template.spec.containers[0].name`フィールドを使って`nginx`という名前をつけます。
 
-上記のDeploymentを作成するためには以下のステップにしたがってください。
 作成を始める前に、Kubernetesクラスターが稼働していることを確認してください。
+上記のDeploymentを作成するためには以下のステップにしたがってください:
 
 1. 以下のコマンドを実行してDeploymentを作成してください。
 
@@ -67,11 +68,12 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   ```
 
   {{< note >}}
-  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
+  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。
+  これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
   {{< /note >}}
 
 
-2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。
+2. Deploymentが作成されたことを確認するために、`kubectl get deployments`を実行してください。
 
   Deploymentがまだ作成中の場合、コマンドの実行結果は以下のとおりです。
   ```shell
@@ -95,14 +97,15 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   deployment.apps/nginx-deployment successfully rolled out
   ```
 
-4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は以下のとおりです。
+4. 数秒後、再度`kubectl get deployments`を実行してください。
+  コマンドの実行結果は以下のとおりです。
   ```shell
   NAME               READY   UP-TO-DATE   AVAILABLE   AGE
   nginx-deployment   3/3     3            3           18s
   ```
   Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
 
-5. Deploymentによって作成されたReplicaSet(`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は以下のとおりです。
+5. Deploymentによって作成されたReplicaSet(`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は以下のとおりです:
   ```shell
   NAME                          DESIRED   CURRENT   READY   AGE
   nginx-deployment-75675f5897   3         3         3       18s
@@ -110,15 +113,15 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   ReplicaSetの出力には次のフィールドが表示されます:
 
   * `NAME`は、名前空間内にあるReplicaSetの名前の一覧です。
-  * `DESIRED`は、アプリケーションの理想的な_レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
+  * `DESIRED`は、アプリケーションの理想的な _レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが _理想的な状態_ と呼ばれるものです。
   * `CURRENT`は現在実行されているレプリカの数です。
   * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
   * `AGE`は、アプリケーションが稼働してからの時間です。
 
   ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
 
-
-6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は以下のとおりです。
+6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。
+  コマンドの実行結果は以下のとおりです:
   ```shell
   NAME                                READY     STATUS    RESTARTS   AGE       LABELS
   nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
@@ -128,7 +131,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。
 
 {{< note >}}
-Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
+Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。
+
+ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
 {{< /note >}}
 
 ### pod-template-hashラベル
@@ -468,7 +473,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー
 
     実行結果は以下のとおりです。
     ```
-    deployment.apps/nginx-deployment
+    deployment.apps/nginx-deployment rolled back
     ```
     その他に、`--to-revision`を指定することにより特定のリビジョンにロールバックできます。
 
@@ -478,7 +483,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー
 
     実行結果は以下のとおりです。
     ```
-    deployment.apps/nginx-deployment
+    deployment.apps/nginx-deployment rolled back
     ```
 
     ロールアウトに関連したコマンドのさらなる情報は[`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)を参照してください。
@@ -756,7 +761,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し
 
 ### Deploymentの更新処理 {#progressing-deployment}
 
-以下のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。
+以下のタスクが実行中のとき、KubernetesはDeploymentの状態を _進行中_ にします。
 
 * Deploymentが新しいReplicaSetを作成します。
 * Deploymentが新しいReplicaSetをスケールアップさせています。
@@ -767,7 +772,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し
 
 ### Deploymentの更新処理の完了 {#complete-deployment}
 
-Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。
+Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを _完了_ にします。
 
 * Deploymentの全てのレプリカが、指定された最新のバージョンに更新されます。これは指定した更新処理が完了したことを意味します。
 * Deploymentの全てのレプリカが利用可能になります。
@@ -782,7 +787,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
 deployment.apps/nginx-deployment successfully rolled out
-$ echo $?
+```
+そして`kubectl rollout`の終了ステータスが0となります（成功です）:
+```shell
+echo $?
+```
+```
 0
 ```
 
@@ -821,7 +831,8 @@ Kubernetesは停止状態のDeploymentに対して、ステータス状態を報
 {{< /note >}}
 
 {{< note >}}
-Deploymentを停止すると、Kubernetesは指定したデッドラインを超えたかどうかチェックしません。ロールアウトの途中でもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
+Deploymentを停止すると、Kubernetesは指定したデッドラインを超えたかどうかチェックしません。
+ロールアウトの途中でもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
 {{< /note >}}
 
 設定したタイムアウトの秒数が小さかったり、一時的なエラーとして扱える他の種類のエラーが原因となり、Deploymentで一時的なエラーが出る場合があります。例えば、リソースの割り当てが不十分な場合を考えます。Deploymentの詳細情報を確認すると、以下のセクションが表示されます。
@@ -903,7 +914,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 error: deployment "nginx" exceeded its progress deadline
-$ echo $?
+```
+そして`kubectl rollout`の終了ステータスが1となります(エラーを示しています):
+```shell
+echo $?
+```
+```
 1
 ```
 
@@ -925,7 +941,8 @@ Deploymentを使って一部のユーザーやサーバーに対してリリー
 
 ## Deployment Specの記述
 
-他の全てのKubernetesの設定と同様に、Deploymentは`apiVersion`、`kind`や`metadata`フィールドを必要とします。設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
+他の全てのKubernetesの設定と同様に、Deploymentは`.apiVersion`、`.kind`や`.metadata`フィールドを必要とします。
+設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
 Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
 Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。
 
@@ -933,7 +950,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
 
 `.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
 
-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/ja/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。
 
 Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
 
@@ -967,9 +984,13 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 `.spec.strategy.type==Recreate`と指定されているとき、既存の全てのPodは新しいPodが作成される前に削除されます。
 
+{{< note >}}
+これは更新のための作成の前にPodを停止する事を保証するだけです。Deploymentを更新する場合、古いリビジョンのPodは全てすぐに停止されます。削除に成功するまでは、新しいリビジョンのPodは作成されません。手動でPodを削除すると、ライフサイクルがReplicaSetに制御されているのですぐに置き換えが実施されます（たとえ古いPodがまだ停止中のステータスでも）。Podに"高々この程度の"保証を求めるならば[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)の使用を検討してください。
+{{< /note >}}
+
 #### Deploymentのローリングアップデート
 
-`.spec.strategy.type==RollingUpdate`と指定されているとき、Deploymentは[ローリングアップデート](/docs/tasks/run-application/rolling-update-replication-controller/)によりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
+`.spec.strategy.type==RollingUpdate`と指定されているとき、DeploymentはローリングアップデートによりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
 
 ##### maxUnavailable
 
@@ -985,7 +1006,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 ### progressDeadlineSeconds
 
-`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
+`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。デフォルト値は600です。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
 
 この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。
 
@@ -993,10 +1014,6 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 `.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
 
-### rollbackTo
-
-`.spec.rollbackTo`は、`extensions/v1beta1`と`apps/v1beta1`のAPIバージョンにおいて非推奨で、`apps/v1beta2`以降のAPIバージョンではサポートされません。かわりに、[前のリビジョンへのロールバック](#rolling-back-to-a-previous-revision)で説明されているように`kubectl rollout undo`を使用するべきです。
-
 ### リビジョン履歴の保持上限
 
 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。
@@ -1008,8 +1025,3 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに
 ### paused
 
 `.spec.paused`はオプションのboolean値で、Deploymentの一時停止と再開のための値です。一時停止されているものと、そうでないものとの違いは、一時停止されているDeploymentはPodTemplateSpecのいかなる変更があってもロールアウトがトリガーされないことです。デフォルトではDeploymentは一時停止していない状態で作成されます。
-
-## Deploymentの代替案
-### kubectl rolling-update
-
-[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があるためです。
diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md
index 264984bae7..3a1e630d20 100644
--- a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md
@@ -83,9 +83,6 @@ Kubernetes1.7では、認証されていない従属オブジェクトがオー
 
 カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。
 
-Kubernetes1.9以前では多くのコントローラーにおけるデフォルトのガベージコレクションポリシーは`orphan`でした。
-この対象のコントローラーはReplicationController、ReplicaSet、StatefulSet、DaemonSetとDeploymentを含みます。`extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2`のグループバージョンに含まれるオブジェクト種においては、もしユーザーがガベージコレクションに他の値を設定しない限り、デフォルトで従属オブジェクトはみなしご(orphaned)になります。
-Kubernetes1.9において、`apps/v1`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。
 
 下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。
 
diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
deleted file mode 100644
index 386eb1dd5c..0000000000
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ /dev/null
@@ -1,387 +0,0 @@
----
-title: Job
-content_type: concept
-feature:
-  title: バッチ実行
-  description: >
-    Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。
-weight: 60
----
-
-<!-- overview -->
-
-Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。
-JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。
-
-簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。
-ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。
-
-また、Jobを使用して複数のPodを並行して実行することもできます。
-
-
-
-
-<!-- body -->
-
-## Jobの実行例
-
-ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。
-完了までに10秒程度かかります。
-
-{{< codenew file="controllers/job.yaml" >}}
-
-このコマンドで例を実行できます。
-
-```shell
-kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
-```
-```
-job.batch/pi created
-```
-
-Jobのステータスは、`kubectl`を用いて確認します。
-
-```shell
-kubectl describe jobs/pi
-```
-```
-Name:           pi
-Namespace:      default
-Selector:       controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
-Labels:         controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
-                job-name=pi
-Annotations:    kubectl.kubernetes.io/last-applied-configuration:
-                  {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
-Parallelism:    1
-Completions:    1
-Start Time:     Mon, 02 Dec 2019 15:20:11 +0200
-Completed At:   Mon, 02 Dec 2019 15:21:16 +0200
-Duration:       65s
-Pods Statuses:  0 Running / 1 Succeeded / 0 Failed
-Pod Template:
-  Labels:  controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
-           job-name=pi
-  Containers:
-   pi:
-    Image:      perl
-    Port:       <none>
-    Host Port:  <none>
-    Command:
-      perl
-      -Mbignum=bpi
-      -wle
-      print bpi(2000)
-    Environment:  <none>
-    Mounts:       <none>
-  Volumes:        <none>
-Events:
-  Type    Reason            Age   From            Message
-  ----    ------            ----  ----            -------
-  Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7
-```
-
-Jobの完了したPodを表示するには、`kubectl get pods`を使います。
-
-あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。
-
-```shell
-pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
-echo $pods
-```
-```
-pi-5rwd7
-```
-
-ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。
-
-
-いずれかのPodの標準出力を表示します。
-
-```shell
-kubectl logs $pods
-```
-出力例は以下の通りです。
-```shell
-3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
-```
-
-## Jobの仕様の作成
-
-他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。
-その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
-
-Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
-
-### Podテンプレート
-
-`.spec.template`は、`.spec`の唯一の必須フィールドです。
-
-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。
-ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。
-
-Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。
-
-`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。
-
-### Podセレクター {#pod-selector}
-
-`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。
-セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。
-
-
-### Jobの並列実行 {#parallel-jobs}
-
-Jobとして実行するのに適したタスクは、大きく分けて3つあります。
-
-1. 非並列Job
-   - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。
-   - そのPodが正常に終了するとすぐにJobが完了します。
-2. *固定の完了数*を持つ並列Job
-   - `.spec.completions`に、0以外の正の値を指定します。
-   - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。
-   - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。
-3. *ワークキュー*を持つ並列Job
-   - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。
-   - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。
-   - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。
-   - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。
-   - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。
-   - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。
-
-_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。
-
-_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。
-
-
-様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。
-
-#### 並列処理の制御
-
-並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。
-指定しない場合、デフォルトで1になります。
-0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。
-
-以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。
-
-- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。
-- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。
-- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。
-- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。
-- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。
-- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。
-
-## Podおよびコンテナの障害の処理
-
-Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。
-`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。
-
-さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。
-
-たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。
-
-`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。
-
-### Pod Backoff Failure Policy
-
-構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。
-そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。
-失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。
-JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。
-
-{{< note >}}
-Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。
-{{< /note >}}
-
-## Jobの終了とクリーンアップ
-
-Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。
-Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。
-
-デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。
-
-Jobを終了する別の方法は、アクティブな期限を設定することです。
-これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します
-`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。
-Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。
-
-Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。
-
-以下に例を挙げます。
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: pi-with-timeout
-spec:
-  backoffLimit: 5
-  activeDeadlineSeconds: 100
-  template:
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-```
-
-Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。
-
-`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。
-つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。
-
-## 終了したJobの自動クリーンアップ
-
-終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 
-
-### 終了したJobのTTLメカニズム
-
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-
-完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。
-
-TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。
-
-例は以下の通りです。
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: pi-with-ttl
-spec:
-  ttlSecondsAfterFinished: 100
-  template:
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-```
-
-Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。
-
-フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。
-
-このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。
-
-## Jobのパターン {#job-patterns}
-
-Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。
-
-例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。
-
-複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。
-
-並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。
-トレードオフは以下の通りです。
-
-- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。
-- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。
-- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。
-
-ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。
-パターン名は、例とより詳細な説明へのリンクでもあります。
-
-|                            パターン名                                                            | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ |  Kube 1.1で動作するか？ |
-| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
-| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/)                      |                   |                             |          ✓          |          ✓          |
-| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) |         ✓         |                             |      場合による      |          ✓          |
-| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/)         |         ✓         |             ✓               |                     |          ✓          |
-| 単一のJob静的な処理を割り当てる                                                                      |         ✓         |                             |          ✓          |                     |
-
-完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。
-
-以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。
-ここで、`W`はワークアイテム数とします。
-
-|                            パターン名                                                            | `.spec.completions` |  `.spec.parallelism` |
-| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:|
-| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/)                      |          1          |     1とする必要あり      |
-| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) |          W          |        任意           |
-| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/)         |          1          |        任意          |
-| 単一のJob静的な処理を割り当てる                                                                      |          W          |        任意           |
-
-
-## 高度な使用方法
-
-### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector}
-
-通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。
-システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。
-セレクターの値は、他のJobと重複しないように選択されます。
-
-しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。
-これを行うには、Jobの`.spec.selector`を指定します。
-
-これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。
-もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。
-
-ここでは、この機能を使いたくなるようなケースの例をご紹介します。
-`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。
-これらのフィールドは更新が不可能であるため、Jobを更新することはできません。
-そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。
-削除する前に、どのセレクターを使っているかメモしておきます。
-
-```
-kubectl get job old -o yaml
-```
-```
-kind: Job
-metadata:
-  name: old
-  ...
-spec:
-  selector:
-    matchLabels:
-      controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
-  ...
-```
-次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。
-既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。
-
-システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。
-
-```
-kind: Job
-metadata:
-  name: new
-  ...
-spec:
-  manualSelector: true
-  selector:
-    matchLabels:
-      controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
-  ...
-```
-
-新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。
-`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。
-
-## 代替案
-
-### ベアPod
-
-Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。
-このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。
-
-### レプリケーションコントローラー
-
-Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。
-レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。
-
-[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。
-(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。)
-
-### 単一のJobでコントローラーPodを起動
-
-もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。
-
-このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。
-
-このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。
-
-## Cron Job {#cron-jobs}
-
-Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。
diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md
index f554ffb55c..9f8ccfc377 100644
--- a/content/ja/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md
@@ -2,7 +2,7 @@
 reviewers:
 title: ReplicaSet
 content_type: concept
-weight: 10
+weight: 20
 ---
 
 <!-- overview -->
@@ -207,9 +207,9 @@ ReplicaSetオブジェクトの名前は、有効な
 `.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。
 [先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。
 先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました
-```shell
+```yaml
 matchLabels:
-	tier: frontend
+  tier: frontend
 ```
 
 そのReplicaSetにおいて、`.spec.template.metadata.labels`フィールドの値は`spec.selector`と一致しなくてはならず、一致しない場合はAPIによって拒否されます。
@@ -281,7 +281,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
 同様のことを行うための代替案として、`kubectl autoscale`コマンドも使用できます。(こちらの方がより簡単です。)
 
 ```shell
-kubectl autoscale rs frontend --max=10
+kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
 ```
 
 ## ReplicaSetの代替案
diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md
index a3b0aae707..1fa4c5c767 100644
--- a/content/ja/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md
@@ -2,7 +2,7 @@
 reviewers:
 title: StatefulSet
 content_type: concept
-weight: 40
+weight: 30
 ---
 
 <!-- overview -->
@@ -117,6 +117,15 @@ StatefulSetは、Podのドメインをコントロールするために[Headless
 このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。
 
+クラスターでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。
+この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリーをすでに送信していた場合に発生する可能性があります。
+(DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。
+
+Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。
+
+- DNSルックアップに依存するのではなく、Kubernetes APIに直接(例えばwatchを使って)問い合わせる。
+- Kubernetes DNS プロバイダーのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。
+
 [制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。
 
 ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。
@@ -150,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle
 
 StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
 
-上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
+上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
 
 もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。
 
@@ -167,7 +176,7 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM
 
 ## アップデートストラテジー
 
-Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。
+Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStrategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。
 
 ### OnDelete
 
@@ -199,4 +208,3 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
 * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
 * [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
-
diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
index d1b1cc3354..f863cb4e92 100644
--- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -2,7 +2,7 @@
 reviewers:
 title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources)
 content_type: concept
-weight: 65
+weight: 70
 ---
 
 <!-- overview -->
@@ -10,7 +10,7 @@ weight: 65
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}
 
 TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。  
-TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
+TTLコントローラーは現在{{< glossary_tooltip text="Job" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。
 
 α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
 
@@ -23,7 +23,7 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs
 
 ## TTLコントローラー
 
-TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。  
+TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。  
 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。
 
 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
@@ -50,8 +50,6 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
 ## {{% heading "whatsnext" %}}
 
 
-[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
-
-[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
-
+* [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
 
+* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
diff --git a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md
new file mode 100644
index 0000000000..0fa45de94b
--- /dev/null
+++ b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -0,0 +1,147 @@
+---
+title: エフェメラルコンテナ
+content_type: concept
+weight: 80
+---
+
+<!-- overview -->
+
+{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
+
+このページでは、特別な種類のコンテナであるエフェメラルコンテナの概要を説明します。エフェメラルコンテナは、トラブルシューティングなどのユーザーが開始するアクションを実行するために、すでに存在する{{< glossary_tooltip term_id="pod" >}}内で一時的に実行するコンテナです。エフェメラルコンテナは、アプリケーションの構築ではなく、serviceの調査のために利用します。
+
+{{< warning >}}
+エフェメラルコンテナは初期のアルファ状態であり、本番クラスタには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。
+{{< /warning >}}
+
+<!-- body -->
+
+## エフェメラルコンテナを理解する
+
+{{< glossary_tooltip text="Pod" term_id="pod" >}}は、Kubernetesのアプリケーションの基本的なビルディングブロックです。Podは破棄可能かつ置き換え可能であることが想定されているため、一度Podが作成されると新しいコンテナを追加することはできません。その代わりに、通常は{{< glossary_tooltip text="Deployment" term_id="deployment" >}}を使用してPodを削除して置き換えます。
+
+たとえば、再現困難なバグのトラブルシューティングなどのために、すでに存在するPodの状態を調査する必要が出てくることがあります。このような場合、既存のPod内でエフェメラルコンテナを実行することで、Podの状態を調査したり、任意のコマンドを実行したりできます。
+
+### エフェメラルコンテナとは何か？
+
+エフェメラルコンテナは、他のコンテナと異なり、リソースや実行が保証されず、自動的に再起動されることも決してないため、アプリケーションを構築する目的には適しません。エフェメラルコンテナは、通常のコンテナと同じ`ContainerSpec`で記述されますが、多くのフィールドに互換性がなかったり、使用できなくなっています。
+
+- エフェメラルコンテナはポートを持つことができないため、`ports`、`livenessProbe`、`readinessProbe`などは使えなくなっています。
+- Podリソースの割り当てはイミュータブルであるため、`resources`の設定が禁止されています。
+- 利用が許可されているフィールドの一覧については、[EphemeralContainerのリファレンスドキュメント](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)を参照してください。
+
+エフェメラルコンテナは、直接`pod.spec`に追加するのではなく、API内の特別な`ephemeralcontainers`ハンドラを使用して作成します。そのため、エフェメラルコンテナを`kubectl edit`を使用して追加することはできません。
+
+エフェメラルコンテナをPodに追加した後は、通常のコンテナのようにエフェメラルコンテナを変更または削除することはできません。
+
+## エフェメラルコンテナの用途
+
+エフェメラルコンテナは、コンテナがクラッシュしてしまったり、コンテナイメージにデバッグ用ユーティリティが同梱されていない場合など、`kubectl exec`では不十分なときにインタラクティブなトラブルシューティングを行うために役立ちます。
+
+特に、[distrolessイメージ](https://github.com/GoogleContainerTools/distroless)を利用すると、攻撃対象領域を減らし、バグや脆弱性を露出する可能性を減らせる最小のコンテナイメージをデプロイできるようになります。distrolessイメージにはシェルもデバッグ用のユーティリティも含まれないため、`kubectl exec`のみを使用してdistrolessイメージのトラブルシューティングを行うのは困難です。
+
+エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。
+
+エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)を参照してください。
+
+## Ephemeral containers API
+
+{{< note >}}
+このセクションの例を実行するには、`EphemeralContainers`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、Kubernetesクライアントとサーバーのバージョンをv1.16以上にする必要があります。
+{{< /note >}}
+
+このセクションの例では、API内でエフェメラルコンテナを表示する方法を示します。通常は、APIを直接呼び出すのではなく、`kubectl alpha debug`やその他の`kubectl`[プラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)を使用して、これらのステップを自動化します。
+
+エフェメラルコンテナは、Podの`ephemeralcontainers`サブリソースを使用して作成されます。このサブリソースは、`kubectl --raw`を使用して確認できます。まずはじめに、以下に`EphemeralContainers`リストとして追加するためのエフェメラルコンテナを示します。
+
+```json
+{
+    "apiVersion": "v1",
+    "kind": "EphemeralContainers",
+    "metadata": {
+            "name": "example-pod"
+    },
+    "ephemeralContainers": [{
+        "command": [
+            "sh"
+        ],
+        "image": "busybox",
+        "imagePullPolicy": "IfNotPresent",
+        "name": "debugger",
+        "stdin": true,
+        "tty": true,
+        "terminationMessagePolicy": "File"
+    }]
+}
+```
+
+すでに実行中の`example-pod`のエフェメラルコンテナを更新するには、次のコマンドを実行します。
+
+```shell
+kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
+```
+
+このコマンドを実行すると、新しいエフェメラルコンテナのリストが返されます。
+
+```json
+{
+   "kind":"EphemeralContainers",
+   "apiVersion":"v1",
+   "metadata":{
+      "name":"example-pod",
+      "namespace":"default",
+      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
+      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
+      "resourceVersion":"15886",
+      "creationTimestamp":"2019-08-29T06:41:42Z"
+   },
+   "ephemeralContainers":[
+      {
+         "name":"debugger",
+         "image":"busybox",
+         "command":[
+            "sh"
+         ],
+         "resources":{
+
+         },
+         "terminationMessagePolicy":"File",
+         "imagePullPolicy":"IfNotPresent",
+         "stdin":true,
+         "tty":true
+      }
+   ]
+}
+```
+
+新しく作成されたエフェメラルコンテナの状態を確認するには、`kubectl describe`を使用します。
+
+```shell
+kubectl describe pod example-pod
+```
+
+```
+...
+Ephemeral Containers:
+  debugger:
+    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
+    Image:         busybox
+    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
+    Port:          <none>
+    Host Port:     <none>
+    Command:
+      sh
+    State:          Running
+      Started:      Thu, 29 Aug 2019 06:42:21 +0000
+    Ready:          False
+    Restart Count:  0
+    Environment:    <none>
+    Mounts:         <none>
+...
+```
+
+新しいエフェメラルコンテナとやりとりをするには、他のコンテナと同じように、`kubectl attach`、`kubectl exec`、`kubectl logs`などのコマンドが利用できます。例えば、次のようなコマンドが実行できます。
+
+```shell
+kubectl attach -it example-pod -c debugger
+```
diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md
index 3486c55219..5e7baf0665 100644
--- a/content/ja/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ja/docs/concepts/workloads/pods/init-containers.md
@@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー
 
 Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。
 
-また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。
+また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`lifecycle`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。
 
 複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。
 
@@ -200,11 +200,11 @@ NAME        READY     STATUS    RESTARTS   AGE
 myapp-pod   1/1       Running   0          9m
 ```
 
-このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。
+このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#whats-next)にさらに詳細な使用例に関するリンクがあります。
 
 ## Initコンテナのふるまいに関する詳細 {#detailed-behavior}
 
-Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
+Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従ってPodのInitコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
 
 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。
 
diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
index 1cf9df1580..8afc01295d 100644
--- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -6,186 +6,110 @@ weight: 30
 
 <!-- overview -->
 
-このページではPodのライフサイクルについて説明します。
+このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。
 
+Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。
 
+Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。
+
+Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/scheduling-eviction/)されます。PodがNodeにスケジュール(割り当て)されると、Podは停止または[終了](#pod-termination)するまでそのNode上で実行されます。
 
 
 <!-- body -->
 
-## PodのPhase {#pod-phase}
+## Podのライフタイム
+
+個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。Podが作成されると、一意のID([UID](ja/docs/concepts/overview/working-with-objects/names/#uids))が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。  
+{{< glossary_tooltip term_id="node" >}}が停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に[削除](#pod-garbage-collection)されます。
+
+Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりポッドはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。
+
+特定のPod(UIDで定義)は新しいNodeに"再スケジュール"されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。
+
+{{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
+
+{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
+
+*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。*
+
+
+## Podのフェーズ {#pod-phase}
 
 Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。
 
-Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。
-このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。
+Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。
 
-Podの各フェーズの値と意味は厳重に守られています。
-ここに記載されているもの以外に`phase`の値は存在しないと思ってください。
+Podの各フェーズの値と意味は厳重に守られています。ここに記載されているもの以外に`phase`の値は存在しないと思ってください。
 
 これらが`phase`の取りうる値です。
 
 値 | 概要
 :-----|:-----------
-`Pending` | PodがKubernetesシステムによって承認されましたが、1つ以上のコンテナイメージが作成されていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。これには時間がかかることがあります。
+`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。
 `Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
 `Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。
 `Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
-`Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。
+`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。
 
-## Podのconditions {#pod-conditions}
-
-PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。
-PodCondition配列の各要素には、次の6つのフィールドがあります。
-
-* `lastProbeTime` は、Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。
-
-* `lastTransitionTime` は、最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。
-
-* `message` は、ステータスの遷移に関する詳細を示す人間向けのメッセージです。
-
-* `reason` は、最後の状態遷移の理由を示す、一意のキャメルケースでの単語です。
-
-* `status` は`True`と`False`、`Unknown`のうちのどれかです。
-
-* `type` 次の値を取る文字列です。
-
-  * `PodScheduled`: PodがNodeにスケジュールされました。
-  * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
-  * `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
-  * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
-
-
-## コンテナのProbe {#container-probes}
-
-[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。
-診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。
-Handlerには次の3つの種類があります:
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
-  コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
-  コンテナのIPの特定のポートにTCPチェックを行います。
-  そのポートが空いていれば診断を成功とみなします。
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
-  コンテナのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。
-  レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。
-
-各Probe 次の3つのうちの一つの結果を持ちます:
-
-* Success: コンテナの診断が成功しました。
-* Failure: コンテナの診断が失敗しました。
-* Unknown: コンテナの診断が失敗し、取れるアクションがありません。
-
-Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます:
-
-* `livenessProbe`: コンテナが動いているかを示します。
-   livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
-   コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。
-
-* `readinessProbe`: コンテナがServiceのリクエストを受けることができるかを示します。
-   readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。
-   initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。
-   コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。
-
-* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。
-   startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。
-   startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
-   コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。
-
-### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば
-livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。
-
-Probeに失敗したときにコンテナを殺したり再起動させたりするには、
-livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。
-
-### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
-この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、
-readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。
-コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。
-
-コンテナがメンテナンスのために停止できるようにするには、
-livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。
-
-Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。
-Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。
-Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
-
-### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。
-`periodSeconds`のデフォルトは30秒です。
-
-`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。
-
-livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、
-[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。
-
-## Podとコンテナのステータス {#pod-and-container-status}
-
-PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。
-Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。
+Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
 
 ## コンテナのステータス {#container-states}
 
-PodがスケジューラによってNodeに割り当てられると、
-kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。
-コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。
-コンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。
-Pod内のコンテナごとにStateの項目として表示されます。
+Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。
 
-* `Waiting`: コンテナのデフォルトの状態。コンテナがRunningまたはTerminatedのいずれの状態でもない場合コンテナはWaitingの状態になります。Waiting状態のコンテナは引き続きイメージを取得したりSecretsを適用したりするなど必要な操作を実行します。この状態に加えてメッセージに関する情報と状態に関する理由が表示されます。
+Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。
 
-    ```yaml
-   ...
-      State:          Waiting
-       Reason:       ErrImagePull
-   ...
-   ```
+Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。Pod内のコンテナごとにStateの項目として表示されます。
 
-* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
+各状態の意味は次のとおりです。
 
-   ```yaml
-   ...
-      State:          Running
-       Started:      Wed, 30 Jan 2019 16:46:38 +0530
-   ...
-   ```
+### `Waiting` {#container-state-waiting}
 
-* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
+コンテナが`Running`または`Terminated`のいずれの状態でもない場合コンテナは`Waiting`の状態になります。Waiting状態のコンテナは引き続きコンテナイメージレジストリからイメージを取得したり{{< glossary_tooltip text="Secret" term_id="secret" >}}を適用したりするなど必要な操作を実行します。`Waiting`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Waiting`の状態である理由の要約が表示されます。
 
-   ```yaml
-   ...
-      State:          Terminated
-        Reason:       Completed
-        Exit Code:    0
-        Started:      Wed, 30 Jan 2019 11:45:26 +0530
-        Finished:     Wed, 30 Jan 2019 11:45:26 +0530
-    ...
-   ```
+### `Running` {#container-state-running}
 
-## PodReadinessGate {#pod-readiness-gate}
+`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。
+
+### `Terminated` {#container-state-terminated}
+
+`Terminated`状態のコンテナは実行されて、完了したときまたは何らかの理由で失敗したことを示します。`Terminated`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。
+
+コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
+
+## コンテナの再起動ポリシー {#restart-policy}
+
+Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。
+
+`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。
+
+## PodのCondition {#pod-conditions}
+
+PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。
+
+* `PodScheduled`: PodがNodeにスケジュールされました。
+* `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
+* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
+* `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
+
+フィールド名         | 内容
+:--------------------|:-----------
+`type`               | このPodの状態の名前です。
+`status`             | その状態が適用可能かどうか示します。可能な値は"`True`"と"`False`"、"`Unknown`"のうちのいずれかです。
+`lastProbeTime`      | Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。
+`lastTransitionTime` | 最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。
+`reason`             | 最後の状態遷移の理由を示す、機械可読のアッパーキャメルケースのテキストです。
+`message`            | ステータスの遷移に関する詳細を示す人間向けのメッセージです。
+
+## PodのReadiness {#pod-readiness-gate}
 
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
-追加のフィードバックやシグナルを`PodStatus`に注入できるようにしてPodのReadinessに拡張性を持たせるため、
-Kubernetes 1.11 では[Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)という機能が導入されました。
-`PodSpec`の新しいフィールド`ReadinessGate`を使用して、PodのRedinessを評価する追加の状態を指定できます。
-KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、
-ステータスはデフォルトで`False`になります。以下はその例です。
+追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。
+
+ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。
+
+以下はその例です。
 
 ```yaml
 Kind: Pod
@@ -209,130 +133,139 @@ status:
 ...
 ```
 
-新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
-`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、
-新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。
+PodのConditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
 
-新しいPod Conditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます:
+### PodのReadinessの状態 {#pod-readiness-status}
+
+`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていません。Podにこれらの`status.conditions`を設定するには、アプリケーションと{{< glossary_tooltip term_id="operator-pattern" text="operators">}}は`PATCH`アクションを使用する必要があります。[Kubernetes client library](/docs/reference/using-api/client-libraries/)を使用して、PodのReadinessのためにカスタムのPodのConditionを設定するコードを記述できます。
+
+カスタムのPodのConditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます:
 
 * Pod内のすべてのコンテナが準備完了している。
 * `ReadinessGates`で指定された条件が全て`True`である。
 
-PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。
+Podのコンテナは準備完了ですが、少なくとも1つのカスタムのConditionが欠落しているか「False」の場合、kubeletはPodの[Condition](#pod-condition)を`ContainersReady`に設定します。
 
-## RestartPolicy {#restart-policy}
+## コンテナのProbe {#container-probes}
 
-PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。
-デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。
-`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。
-kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。
+[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります:
 
-## Podのライフタイム {#pod-lifetime}
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+  コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。
 
-一般にPodは人間またはコントローラーが明示的に削除するまで存在します。
-コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。
-これはPodが作成されて時間とともに終了するため、リソースリークを避けます。
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+  PodのIPの特定のポートにTCPチェックを行います。
+  そのポートが空いていれば診断を成功とみなします。
 
-次の3種類のコントローラがあります。
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+  PodのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。
+  レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。
 
-- バッチ計算などのように終了が予想されるPodに対しては、[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用します。
-   Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。
+各Probe 次の3つのうちの一つの結果を持ちます:
 
-- 停止することを期待しないPod（たとえばWebサーバーなど）には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。
+* `Success`: コンテナの診断が成功しました。
+* `Failure`: コンテナの診断が失敗しました。
+* `Unknown`: コンテナの診断が失敗し、取れるアクションがありません。
 
-- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を使用します。
+Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます:
 
-3種類のコントローラにはすべてPodTemplateが含まれます。
-Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。
-これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。
+* `livenessProbe`: コンテナが動いているかを示します。
+   livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
+   コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。
 
-Nodeが停止したりクラスタの他のNodeから切断された場合、
-Kubernetesは失われたノード上のすべてのPodの`phase`をFailedに設定するためのポリシーを適用します。
+* `readinessProbe`: コンテナがリクエスト応答する準備ができているかを示します。
+   readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。
+   initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。
+   コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。
 
-## 例
+* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。
+   startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。
+   startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
+   コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。
 
-### 高度なliveness probeの例
+livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、[Liveness Probe、Readiness ProbeおよびStartup Probeを使用する](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。
 
-Liveness Probeはkubeletによって実行されるため、
-すべてのリクエストはkubeletネットワークのnamespaceで行われます。
+### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}
 
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  labels:
-    test: liveness
-  name: liveness-http
-spec:
-  containers:
-  - args:
-    - /server
-    image: k8s.gcr.io/liveness
-    livenessProbe:
-      httpGet:
-        # "host" が定義されていない場合、"PodIP"が使用されます
-        # host: my-host
-        # "scheme"が定義されていない場合、HTTPスキームが使用されます。"HTTP"と"HTTPS"のみ
-        # scheme: HTTPS
-        path: /healthz
-        port: 8080
-        httpHeaders:
-        - name: X-Custom-Header
-          value: Awesome
-      initialDelaySeconds: 15
-      timeoutSeconds: 1
-    name: liveness
-```
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
 
-### statesの例
+コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です.
+この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。
 
-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。
-     * 完了のイベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: Podの`phase`はSucceededになります。
-       * Never: Podの`phase`はSucceededになります。
+Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。
 
-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。
-     * 失敗イベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: Podの`phase`はFailedになります。
+### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}
 
-   * Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。
-     * 失敗イベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: コンテナを再起動しません。Podの`phase`はRunningのままです。
-     * コンテナ1が死んでいてコンテナ2は動いている場合
-       * 失敗イベントを記録します。
-       * `restartPolicy`が、
-         * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-         * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-         * Never: Podの`phase`はFailedになります。
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
 
-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。
-     * コンテナは失敗で終了します。
-     * OOMイベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: 失敗イベントを記録します。Podの`phase`はFailedになります。
+Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
+この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。
 
-   * Podが実行中ですがディスクは死んでいます。
-     * すべてのコンテナを殺します。
-     * 適切なイベントを記録します。
-     * Podの`phase`はFailedになります。
-     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。
+コンテナがメンテナンスのために停止できるようにするには、livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。
 
-   * Podが実行中ですがNodeが切り離されました。
-     * Nodeコントローラがタイムアウトを待ちます。
-     * NodeコントローラがPodの`phase`をFailedにします。
-     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。
+{{< note >}}
+Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
+{{< /note >}}
+
+### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。
+コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。
+
+## Podの終了 {#pod-termination}
+
+Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
+
+ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。
+
+通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。
+
+フローの例は下のようになります。
+
+1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するために`kubectl`コマンドを送信する。
+1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。  
+   削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。  
+   Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。
+    1. Pod内のコンテナの1つが`preStop`[フック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。
+   {{< note >}}
+   `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。
+   {{< /note >}}
+    1. kubeletはコンテナランタイムをトリガーして、コンテナ内のプロセス番号1にTERMシグナルを送信する。
+   {{< note >}}
+   Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。
+   {{< /note >}}
+1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。
+1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。
+1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。
+1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。
 
 
+### Podの強制削除 {#pod-termination-forced}
+
+{{< caution >}}
+強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
+{{< /caution >}}
+
+デフォルトでは、すべての削除は30秒以内に正常に行われます。`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=<seconds>` オプションをサポートします。
+
+`--grace-period`を`0`に設定した場合、PodはAPI serverから即座に強制的に削除されます。PodがNode上でまだ実行されている場合、その強制削除によりkubeletがトリガーされ、すぐにクリーンアップが開始されます。
+
+{{< note >}}
+強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。
+{{< /note >}}
+
+強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
+
+StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
+
+
+### 失敗したPodのガベージコレクション {#pod-garbage-collection}
+
+失敗したPodは人間または{{< glossary_tooltip term_id="controller" text="controller" >}}が明示的に削除するまで存在します。
+
+コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値(kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される)を超えたとき、それらのPodを削除します。これはPodが作成されて時間とともに終了するため、リソースリークを避けます。
 
 
 ## {{% heading "whatsnext" %}}
@@ -344,4 +277,4 @@ spec:
 
 * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ
 
-
+* APIのPod/コンテナステータスの詳細情報は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)および[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください
diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md
index 76e8f11a62..4d286fdbcf 100644
--- a/content/ja/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md
@@ -33,7 +33,7 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで
   * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
 
 各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。
-Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。
+Kubernetesにおいて、これは一般的に _レプリケーション_ と呼ばれます。
 レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。
 さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。
 
diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md
deleted file mode 100644
index fbb003c21b..0000000000
--- a/content/ja/docs/concepts/workloads/pods/pod.md
+++ /dev/null
@@ -1,188 +0,0 @@
----
-reviewers:
-title: Pod
-content_type: concept
-weight: 20
----
-
-<!-- overview -->
-
-_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。
-
-
-
-
-<!-- body -->
-
-## Podとは
-
-_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。
-
-Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。
-
-Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。
-Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。
-
-Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。
-また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。
-異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。
-これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。
-
-Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。
-このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。
-
-[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。
-
-個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。
-[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。
-Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。
-特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。
-代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。
-
-ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。
-そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。
-
-{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}
-
-*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。*
-
-## Podを用いる動機
-
-### 管理
-
-Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。
-構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。
-Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。
-Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。
-
-### リソース共有と通信
-
-Podは、構成要素間でのデータ共有および通信を可能にします。
-
-Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。
-このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。
-各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。
-
-Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。
-詳細は[クラスターネットワーク](/docs/concepts/cluster-administration/networking/)をご覧ください。
-
-Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。
-ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。
-
-## Podの用途
-
-Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。
-しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。
-
-* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
-* ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど
-* データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど
-* プロキシ、ブリッジ、およびアダプタ
-* コントローラー、マネージャー、コンフィギュレーター、およびアップデーター
-
-個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。
-
-詳細については、[The Distributed System ToolKit: Patterns for
-Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。
-
-## 考えられる代替案
-
-_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_
-
-1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。
-これは、ユーザーに多くの便益を提供します。
-1. ソフトウェアの依存関係を減らすため。
-個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。
-Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。
-1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
-1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。
-
-_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_
-
-このアプローチによって、コンテナの共同配置は提供されるでしょう。
-しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。
-
-
-## Podの耐久性(またはその欠如) {#pod-durability}
-
-Podは、耐久性のある存在として扱われることを意図していません。
-スケジューリングの失敗や、Nodeの故障には耐えられません。
-リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。
-
-一般に、ユーザーはPodを直接作成する必要はありません。
-ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/ja/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。
-コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。
-[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。
-
-主要なユーザー向けのプリミティブとして集合APIを使用することは、[Borg](https://research.google.com/pubs/pub43438.html)、 [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、[Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)などのクラスタースケジューリングシステムで比較的一般的です。
-
-Podは、以下のことを容易にするためにプリミティブとして公開されています。
-
-* スケジューラーとコントローラーをプラガブルにする
-* コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする
-* ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す
-* コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する
-* Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる
-* アプリケーションの可用性を高める。
-即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する
-
-## Podの終了 {#termination-of-pods}
-
-Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。
-ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。
-ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。
-猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。
-プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。
-
-フローの例は下のようになります。
-
-1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する
-1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
-1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
-1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
-    1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。
-    猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。
-    1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある
-1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。
-ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
-1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
-1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。
-PodはAPIから消え、クライアントからは見えなくなる
-
-デフォルトでは、すべての削除は30秒以内に正常に行われます。
-`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=<seconds>` オプションをサポートします。
-値 `0` はPodを[強制的に削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)します。
-kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。
-
-### Podの強制削除
-
-Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。
-強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。
-API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。
-Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。
-
-強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。
-StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
-
-## Podコンテナの特権モード {#privileged-mode-for-pod-containers}
-
-Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。
-これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。
-コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。
-特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。
-
-マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。
-それらは保留状態になります。
-ユーザーが `kubectl describe pod FooPodName` を実行すると、Podが保留状態になっている理由を確認できます。
-describeコマンド出力のイベントテーブルには、次のように表示されます。
-`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
-
-マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。
-ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。 
-`The Pod "FooPodName" is invalid.
-spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
-
-## APIオブジェクト
-
-PodはKubernetes REST APIのトップレベルのリソースです。
-APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。
diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md
index 42faf6bf0c..da0862be08 100644
--- a/content/ja/docs/concepts/workloads/pods/podpreset.md
+++ b/content/ja/docs/concepts/workloads/pods/podpreset.md
@@ -6,25 +6,36 @@ weight: 50
 ---
 
 <!-- overview -->
-このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。  
+{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
 
+このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。
 
 
 <!-- body -->
 ## PodPresetを理解する
 
-`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
-ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
+`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
 
-PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。  
-この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
+PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
 
-PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。
+
+## クラスターでPodPresetを有効にする {#enable-pod-preset}
+
+ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
+
+1.  `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
+1.  `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。例えば、Minikubeにおいては、クラスターの起動時に
+
+  ```shell
+  --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+  ```
+
+  を追加することで可能になります。
 
 ## PodPresetはどのように動くか
 
-Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。  
-Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。
+
+Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。
 
 1. 使用可能な全ての`PodPreset`を取得する。
 1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。
@@ -32,36 +43,22 @@ Pod作成要求が発生した時、Kubernetesシステムは下記の処理を
 1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。
 1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-<PodPreset名>: "<リソースのバージョン>"`という形式になります。
 
-各Podは0以上のPodPresetにマッチすることができます。そして各`PodPreset`は0以上のPodに適用されます。単一の`PodPreset`が1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`Env`、`EnvFrom`、`VolumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`Volume`への変更があった場合、KubernetesはそのPodのSpecを修正します。
+各Podは0以上のPodPresetにマッチすることができます。そして各PodPresetは0以上のPodに適用されます。単一のPodPresetが1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`env`、`envFrom`、`volumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`volumes`への変更があった場合、KubernetesはそのPodのSpecを修正します。
 
 {{< note >}}
-単一のPodPresetは必要に応じてPodのSpec内の`.spec.containers`を修正することができます。PodPresetからのリソース定義は`initContainers`フィールドに対して1つも適用されません。
+単一のPodPresetは必要に応じてPodのspec内の以下のフィールドを修正することができます。
+- `.spec.containers`フィールド
+- `.spec.initContainers`フィールド
 {{< /note >}}
 
 ### 特定のPodに対するPodPresetを無効にする
 
-PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。  
+PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodの`.spec`内に次のような形式のアノテーションを追加できます。  
 `podpreset.admission.kubernetes.io/exclude: "true"`
 
-## PodPresetを有効にする
-
-ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
-
-1.  `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
-1.  `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に
-
-  ```shell
-  --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
-  ```
-
-  を追加することで可能になります。
-1.  ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。
-
-
 
 ## {{% heading "whatsnext" %}}
 
+[PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
 
-* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
-
-
+PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。
diff --git a/content/ja/docs/contribute/localization.md b/content/ja/docs/contribute/localization.md
index 56b94407dc..f151b850e9 100644
--- a/content/ja/docs/contribute/localization.md
+++ b/content/ja/docs/contribute/localization.md
@@ -54,8 +54,8 @@ card:
 #### 既存のページの誤字脱字や古い記述を修正する場合の手順
 
 1. `kubernetes/website`リポジトリをフォークする
-2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
-3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する
+2. `dev-1.18-ja.2`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
+3. `dev-1.18-ja.2`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する
 
 ### マイルストーンについて {#milestones}
 
diff --git a/content/ja/docs/contribute/review/_index.md b/content/ja/docs/contribute/review/_index.md
new file mode 100644
index 0000000000..01fcdca0b7
--- /dev/null
+++ b/content/ja/docs/contribute/review/_index.md
@@ -0,0 +1,14 @@
+---
+title: 変更のレビュー
+weight: 30
+---
+
+<!-- overview -->
+
+このセクションでは、コンテンツのレビュー方法について説明します。
+
+
+
+<!-- body -->
+
+
diff --git a/content/ja/docs/contribute/style/content-guide.md b/content/ja/docs/contribute/style/content-guide.md
new file mode 100644
index 0000000000..eb165ca733
--- /dev/null
+++ b/content/ja/docs/contribute/style/content-guide.md
@@ -0,0 +1,62 @@
+---
+title: ドキュメントコンテンツガイド
+linktitle: コンテンツガイド
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+このページでは、Kubernetesのドキュメント上のコンテンツのガイドラインを説明します。
+
+許可されるコンテンツに関して疑問がある場合は、[Kubernetes Slack](https://slack.k8s.io/)の#sig-docsチャンネルに参加して質問してください！
+
+Kubernetes Slackには、<https://slack.k8s.io/> から参加登録ができます。
+
+Kubernetesドキュメントの新しいコンテンツの作成に関する情報については、[スタイルガイド](/docs/contribute/style/style-guide)に従ってください。
+
+<!-- body -->
+
+## 概要
+
+ドキュメントを含むKubernetesのウェブサイトのソースは、[kubernetes/website](https://github.com/kubernetes/website)リポジトリに置かれています。
+
+Kubernetesの主要なドキュメントは`kubernetes/website/content/<language_code>/docs`フォルダに置かれており、これらは[Kubernetesプロジェクト](https://github.com/kubernetes/kubernetes)を対象としています。
+
+## 許可されるコンテンツ
+
+Kubernetesのドキュメントにサードパーティーのコンテンツを掲載することが許されるのは、次の場合のみです。
+
+- コンテンツがKubernetesプロジェクト内のソフトウェアのドキュメントとなる場合
+- コンテンツがプロジェクト外のソフトウェアのドキュメントとなるが、Kubernetesを機能させるために必要である場合
+- コンテンツがkubernetes.ioの正規のコンテンツであるか、他の場所の正規のコンテンツへのリンクである場合
+
+### サードパーティーのコンテンツ
+
+Kubernetesのドキュメントには、Kubernetesプロジェクト([kubernetes](https://github.com/kubernetes)および[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizationsに存在するプロジェクト)の適用例が含まれています。
+
+Kubernetesプロジェクト内のアクティブなコンテンツへのリンクは常に許可されます。
+
+Kubernetesを機能させるためには、一部サードパーティーのコンテンツが必要です。たとえば、コンテナランタイム(containerd、CRI-O、Docker)、[ネットワークポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)(CNI plugin)、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)、[ロギング](/docs/concepts/cluster-administration/logging/)などです。
+
+ドキュメント内で、Kubernetesプロジェクト外のサードパーティーのオープンソースソフトウェア(OSS)にリンクすることができるのは、Kubernetesを機能させるために必要な場合のみです。
+
+### 情報源が重複するコンテンツ
+
+可能な限り、Kubernetesのドキュメントは正規の情報源にリンクするようにし、情報源が重複してしまうようなホスティングは行いません。
+
+情報源が重複したコンテンツは、メンテナンスするために2倍の労力(あるいはそれ以上！)が必要になり、より早く情報が古くなってしまいます。
+
+{{< note >}}
+
+あなたがKubernetesのプロジェクトのメンテナーであり、ドキュメントのホスティングに関して手助けが必要なときは、[Kubernetes Slackの#sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/)で教えてください。
+
+{{< /note >}}
+
+### その他の情報
+
+許可されるコンテンツに関して疑問がある場合は、[Kubernetes Slack](https://slack.k8s.io/)の#sig-docsチャンネルに参加して質問してください！
+
+## {{% heading "whatsnext" %}}
+
+* [スタイルガイド](/docs/contribute/style/style-guide)を読む
diff --git a/content/ja/docs/contribute/style/content-organization.md b/content/ja/docs/contribute/style/content-organization.md
new file mode 100644
index 0000000000..1ecc86307f
--- /dev/null
+++ b/content/ja/docs/contribute/style/content-organization.md
@@ -0,0 +1,123 @@
+---
+title: コンテンツの構造化
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+このサイトではHugoを使用しています。Hugoでは、[コンテンツの構造化](https://gohugo.io/content-management/organization/)がコアコンセプトとなっています。
+
+<!-- body -->
+
+{{% note %}}
+**Hugoのヒント:** コンテンツの編集を始めるときは、`hugo server --navigateToChanged`コマンドを使用してHugoを実行してください。
+{{% /note %}}
+
+## ページの一覧
+
+### ページの順序
+
+ドキュメントのサイドメニューやページブラウザーなどでは、Hugoのデフォルトのソート順序を使用して一覧を作成しています。デフォルトでは、weight(1から開始)、日付(最新のものが1番目)、最後にリンクのタイトルの順でソートされます。
+
+そのため、特定のページやセッションを上に移動したい場合には、ページのフロントマター内のweightを設定します。
+
+```yaml
+title: My Page
+weight: 10
+```
+
+{{% note %}}
+ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。
+{{% /note %}}
+
+### ドキュメントのメインメニュー
+
+ドキュメントのメインメニューは、`docs/`以下に置かれたセクションのコンテンツファイル`_index.md`のフロントマター内に`main_menu`フラグが設定されたものから生成されます。
+
+```yaml
+main_menu: true
+```
+
+リンクのタイトルは、ページの`linkTitle`から取得されることに注意してください。そのため、ページのタイトルとは異なるリンクテキストにしたい場合、コンテンツファイル内の値を以下のように設定します。
+
+```yaml
+main_menu: true
+title: ページタイトル
+linkTitle: リンク内で使われるタイトル
+```
+
+{{% note %}}
+上記の設定は言語ごとに行う必要があります。メニュー上にセクションが表示されないときは、Hugoからセクションとして認識されていないためである可能性が高いです。セクションフォルダー内に`_index.md`コンテンツファイルを作成してください。
+{{% /note %}}
+
+### ドキュメントのサイドメニュー
+
+ドキュメントのサイドバーメニューは、`docs/`以下の*現在のセクションツリー*から生成されます。
+
+セクションと、そのセクション内のページがすべて表示されます。
+
+特定のセクションやページをリストに表示したくない場合、フロントマター内の`toc_hide`フラグを`true`に設定してください。
+
+```yaml
+toc_hide: true
+```
+
+コンテンツが存在するセクションに移動すると、特定のセクションまたはページ(例:`index.md`)が表示されます。それ以外の場合、そのセクションの最初のページが表示されます。
+
+### ドキュメントのブラウザー
+
+ドキュメントのホームページのページブラウザーは、`docs`セクション直下のすべてのセクションとページを使用して生成されています。
+
+特定のセクションやページを表示したくない場合、フロントマターの`toc_hide`フラグを`true`に設定してください。
+
+```yaml
+toc_hide: true
+```
+
+### メインメニュー
+
+右上のメニュー(およびフッター)にあるサイトリンクは、page-lookupの機能を使用して実装されています。これにより、ページが実際に存在することを保証しています。そのため、たとえば`case-studies`のセクションが特定の言語のサイトに存在しない場合、メニューにはケーススタディのリンクが表示されません。
+
+## Page Bundle
+
+スタンドアローンのコンテンツページ(Markdownファイル)に加えて、Hugoでは、[Page Bundles](https://gohugo.io/content-management/page-bundles/)がサポートされています。
+
+Page Bundleの1つの例は、[カスタムのHugo Shortcode](/docs/contribute/style/hugo-shortcodes/)です。これは、`leaf bundle`であると見做されます。ディレクトリ内のすべてのファイルは、`index.md`を含めてバンドルの一部となります。これには、ページからの相対リンク、処理可能な画像なども含まれます。
+
+```bash
+en/docs/home/contribute/includes
+├── example1.md
+├── example2.md
+├── index.md
+└── podtemplate.json
+```
+
+もう1つのPage Bundleがよく使われる例は、`includes`バンドルです。フロントマターに`headless: true`を設定すると、自分自身のURLを持たなくなり、他のページ内でのみ使用されるようになります。
+
+```bash
+en/includes
+├── default-storage-class-prereqs.md
+├── index.md
+├── partner-script.js
+├── partner-style.css
+├── task-tutorial-prereqs.md
+├── user-guide-content-moved.md
+└── user-guide-migration-notice.md
+```
+
+バンドル内のファイルに関して、いくつか重要な注意点があります。
+
+* 翻訳されたバンドルに対しては、コンテンツ以外の見つからなかったファイルは上位の言語から継承されます。これにより重複が回避できます。
+* バンドル内のすべてのファイルは、Hugoが`Resources`と呼ぶファイルになり、フロントマター(YAMLファイルなど)をサポートしていない場合であっても、言語ごとにパラメーターやタイトルなどのメタデータを提供できます。詳しくは、[Page Resourcesメタデータ](https://gohugo.io/content-management/page-resources/#page-resources-metadata)を参照してください。
+* `Resource`の`.RelPermalink`から取得した値は、ページからの相対的なものとなっています。詳しくは、[Permalinks](https://gohugo.io/content-management/urls/#permalinks)を参照してください。
+
+## スタイル
+
+このサイトのスタイルシートの[SASS](https://sass-lang.com/)のソースは、`assets/sass`に置かれていて、Hugoによって自動的にビルドされます。
+
+## {{% heading "whatsnext" %}}
+
+* [カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)について学ぶ
+* [スタイルガイド](/docs/contribute/style/style-guide)について学ぶ
+* [コンテンツガイド](/docs/contribute/style/content-guide)について学ぶ
diff --git a/content/ja/docs/contribute/suggesting-improvements.md b/content/ja/docs/contribute/suggesting-improvements.md
new file mode 100644
index 0000000000..3a28a94e06
--- /dev/null
+++ b/content/ja/docs/contribute/suggesting-improvements.md
@@ -0,0 +1,45 @@
+---
+title: コンテンツの改善を提案する
+slug: suggest-improvements
+content_type: concept
+weight: 10
+card:
+  name: contribute
+  weight: 20
+---
+
+<!-- overview -->
+
+Kubernetesのドキュメントに何か問題を見つけたり、新しいコンテンツに関してアイデアを思い付いたときは、issueを作ってください。必要なものは、[GitHubアカウント](https://github.com/join)とウェブブラウザーだけです。
+
+Kubernetesのドキュメント上の新しい作業は、ほとんどの場合、GitHubのissueから始まります。Kubernetesのコントリビューターは、必要に応じてレビュー、分類、タグ付けを行います。次に、あなたやKubernetesコミュニティの他のメンバーが、そのissueを解決するための変更を加えるpull requestを開きます。
+
+<!-- body -->
+
+## issueを作る
+
+既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。
+
+1. ページの右側のサイドバーにある**ドキュメントのissueを作成**ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。
+2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。
+3. **Submit new issue**ボタンをクリックします。
+
+送信後、定期的にissueを確認するか、GitHubの通知を設定してください。レビュアや他のコミュニティメンバーが、issueに対して作業を行うために、あなたに何か質問をするかもしれません。
+
+## 新しいコンテンツの提案
+
+新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。
+
+- コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**ボタンをクリックする。
+- [GitHub](https://github.com/kubernetes/website/issues/new/)に移動し、直接issueを作る。
+
+## よいissueを作るには
+
+issueを作るときは、以下のことを心に留めてください。
+
+- 明確なissueの説明を書く。不足している点、古くなっている点、誤っている点、改善が必要な点など、どの点がそうであるか明確に書く。
+- issueがユーザーに与える具体的な影響を説明する。
+- 合理的な作業単位になるように、特定のissueのスコープを制限する。スコープの大きな問題については、小さな複数のissueに分割する。たとえば、"Fix the security docs"(セキュリティのドキュメントを修正する)というのはスコープが大きすぎますが、"Add details to the 'Restricting network access' topic"(トピック「ネットワークアクセスの制限」に詳細情報を追加する)であれば十分に作業可能な大きさです。
+- すでにあるissueを検索し、関連または同様のissueがないかどうか確認する。
+- 新しいissueがほかのissueやpull requestと関係する場合は、完全なURLを参照するか、issueやpull requestの数字の前に`#`の文字を付けて参照する。例えば、`Introduced by #987654`のように書きます。
+- [行動規範](/ja/community/code-of-conduct/)に従って、仲間のコントリビューターに敬意を払いましょう。たとえば、"The docs are terrible"(このドキュメントは最悪だ)のようなコメントは、役に立つ敬意のあるフィードバックではありません。
diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md
index a417966012..4276875967 100644
--- a/content/ja/docs/reference/_index.md
+++ b/content/ja/docs/reference/_index.md
@@ -31,16 +31,18 @@ content_type: concept
 ## CLIリファレンス
 
 * [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
-    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
 
-## 設定リファレンス
+## コンポーネントリファレンス
 
 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
+  * [kube-schedulerポリシー](/docs/reference/scheduling/policies)
+  * [kube-schedulerプロファイル](/docs/reference/scheduling/profiles)
 
 ## 設計のドキュメント
 
diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md
index 297bcce9d0..3f713636f3 100644
--- a/content/ja/docs/reference/access-authn-authz/authentication.md
+++ b/content/ja/docs/reference/access-authn-authz/authentication.md
@@ -13,7 +13,15 @@ weight: 10
 
 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。
 
-通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
+クラスターから独立したサービスは通常のユーザーを以下の方法で管理することを想定されています。
+
+- 秘密鍵を配布する管理者
+- KeystoneやGoogle Accountsのようなユーザーストア
+- ユーザー名とパスワードのリストを持つファイル
+
+これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
+
+APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(例えば、“/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。
 
 対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。
 
@@ -236,7 +244,7 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6
 
 重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。
 
-KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。
+KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。
 
 IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。
 
@@ -250,7 +258,7 @@ IDプロバイダーがKubernetesと連携するためには、以下のこと
 特定のシステム用のセットアップ手順は、以下を参照してください。
 
 - [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html)
-- [Dex](https://github.com/dexidp/dex/blob/master/Documentation/kubernetes.md)
+- [Dex](https://dexidp.io/docs/kubernetes/)
 - [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/)
 
 #### kubectlの使用
@@ -319,7 +327,7 @@ Webhook認証は、Bearerトークンを検証するためのフックです。
 * `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです
 * `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です
 
-設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。
+設定ファイルは、[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。
 ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。
 
 ```yaml
diff --git a/content/ja/docs/reference/access-authn-authz/rbac.md b/content/ja/docs/reference/access-authn-authz/rbac.md
new file mode 100644
index 0000000000..fee25f323e
--- /dev/null
+++ b/content/ja/docs/reference/access-authn-authz/rbac.md
@@ -0,0 +1,1102 @@
+---
+title: RBAC認可を使用する
+content_type: concept
+weight: 70
+---
+
+<!-- overview -->
+Role Based Access Control(RBAC)は、組織内の個々のユーザーのRoleをベースに、コンピューターまたはネットワークリソースへのアクセスを制御する方法です。
+
+
+<!-- body -->
+RBAC認可は{{< glossary_tooltip term_id="api-group" >}} `rbac.authorization.k8s.io`を使用して認可の決定を行い、Kubernetes APIを介して動的にポリシーを構成できるようにします。
+
+RBACを有効にするには、以下の例のように{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}の`--authorization-mode` フラグをコンマ区切りの`RBAC`を含むリストでスタートします。
+
+```shell
+kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
+```
+
+## APIオブジェクト{#api-overview}
+
+RBAC APIは4種類のKubernetesオブジェクト(_Role_、 _ClusterRole_、  _RoleBinding_ そして _ClusterRoleBinding_)を宣言します。他のKubernetesオブジェクトのように`kubectl`のようなツールを使って、[オブジェクトを記述](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)、または変更できます。
+
+{{< caution >}}
+これらのオブジェクトは設計上、アクセス制限を課します。学んできたように変更を行っている場合、
+[特権エスカレーション防止とブートストラップ](#特権昇格の防止とブートストラップ)
+を参照し、これらの制限がどのようにいつかの変更を防止するのかを理解しましょう。
+{{< /caution >}}
+
+### RoleとClusterRole
+
+RBACの _Role_ または _ClusterRole_ には、一連の権限を表すルールが含まれて言います。
+権限は完全な追加方式です(「deny」のルールはありません)。
+
+Roleは常に特定の{{< glossary_tooltip text="namespace" term_id="namespace" >}}で権限を設定します。
+つまり、Roleを作成する時は、Roleが属するNamespaceを指定する必要があります。
+
+対照的にClusterRoleは、Namespaceに属さないリソースです。Kubernetesオブジェクトは常にNamespaceに属するか、属さないかのいずれかである必要があり、リソースは異なる名前(RoleとClusterRole)を持っています。つまり、両方であることは不可能です。
+
+ClusterRolesにはいくつかの用途があります。ClusterRoleを利用して、以下のことができます。
+
+1. Namespaceに属するリソースに対する権限を定義し、個々のNamespace内で付与する
+2. Namespaceに属するリソースに対する権限を定義し、すべてのNamespaceにわたって付与する
+3. クラスター単位でスコープされているリソースに対するアクセス許可を定義する
+
+NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義する婆は、ClusterRoleを使用します
+
+#### Roleの例
+
+以下はNamespace「default」にあるRoleの例で、
+{{< glossary_tooltip text="Pod" term_id="pod" >}}への読み取りアクセス権の付与に使用できます。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  namespace: default
+  name: pod-reader
+rules:
+- apiGroups: [""] # "" はコアのAPIグループを示します
+  resources: ["pods"]
+  verbs: ["get", "watch", "list"]
+```
+
+#### ClusterRoleの例
+
+ClusterRoleを使用してRoleと同じ権限を付与できます。
+ClusterRolesはクラスター単位でスコープされているため、以下へのアクセスの許可もできます。
+
+* クラスター単位でスコープされているリソースに({{< glossary_tooltip text="node" term_id="node" >}}など)
+* 非リソースエンドポイントに(`/healthz`など)
+* すべてのNamespaceに渡ってNamespaceに属するリソースに(Podなど)。
+  例えば、ClusterRoleを使用して特定のユーザーに`kubectl get pods --all-namespaces`の実行を許可できます。
+
+以下は特定のNamespace、またはすべてのNamespace([バインド](#rolebindingとclusterrolebinding)方法によります)で{{< glossary_tooltip text="secrets" term_id="secret" >}}への読み取りアクセス権を付与するClusterRoleの例です。
+
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  # 「namespace」はClusterRolesがNamespaceに属していないため、省略されています
+  name: secret-reader
+rules:
+- apiGroups: [""]
+  #
+  # HTTPレベルでの、Secretにアクセスするリソースの名前
+  # オブジェクトは"secrets"
+  resources: ["secrets"]
+  verbs: ["get", "watch", "list"]
+```
+
+RoleまたはClusterRoleオブジェクトの名前は有効な
+[パスセグメント名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/)である必要があります。
+
+### RoleBindingとClusterRoleBinding
+
+RoleBindingはRoleで定義された権限をユーザーまたはユーザのセットに付与します。
+RoleBindingは*subjects* (ユーザー、グループ、サービスアカウント)のリストと、付与されるRoleへの参照を保持します。
+RoleBindingは特定のNamespace内の権限を付与しますが、ClusterRoleBindingはクラスター全体にアクセスする権限を付与します。
+
+RoleBindingは、同じNamespace内の任意のRoleを参照できます。
+または、RoleBindingはClusterRoleを参照し、そのClusterRoleをRoleBindingのNamespaceにバインドできます。
+ClusterRoleをクラスター内のすべてのNamespaceにバインドする場合は、ClusterRoleBindingを使用します。
+
+RoleBindingまたはClusterRoleBindingオブジェクトは有効な
+[パスセグメント名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/)である必要があります。
+
+#### RoleBindingの例 {#rolebinding-example}
+
+以下はNamespace「default」内でユーザー「jane」に「pod-reader」のRoleを付与するRoleBindingの例です。
+これにより、「jane」にNamespace「default」のポッドの読み取り許可されます。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+# このRoleBindingは「jane」にNamespace「default」のポッドの読み取りを許可する
+# そのNamespaceでRole「pod-reader」を既に持っている必要があります。
+kind: RoleBinding
+metadata:
+  name: read-pods
+  namespace: default
+subjects:
+# 一つ以上の「subject」を指定する必要があります
+- kind: User
+  name: jane # 「name」は大文字と小文字が区別されます
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  # 「roleRef」はRole/ClusterRoleへのバインドを指定します
+  kind: Role #RoleまたはClusterRoleである必要があります
+  name: pod-reader # これはバインドしたいRole名またはClusterRole名とマッチする必要があります
+  apiGroup: rbac.authorization.k8s.io
+```
+
+RoleBindingはClusterRoleを参照し、ClusterRoleで定義されている権限をRoleBinding内のNamespaceのリソースに権限付与もできます。この種類の参照を利用すると、クラスター全体で共通のRoleのセットを定義して、それらを複数のNamespace内での再利用できます。
+
+例えば、以下のRoleBindingがClusterRoleを参照している場合でも、
+「dave」(大文字と小文字が区別されるsubject)はRoleBindingのNamespace(メタデータ内)が「development」のため、Namespace「development」のSecretsのみの読み取りができます。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+# このRoleBindingは「dave」にNamespace「development」のSecretsの読み取りを許可する
+# ClusterRole「secret-reader」を既に持っている必要があります。
+kind: RoleBinding
+metadata:
+  name: read-secrets
+  #
+  # RoleBindingのNamespaceが、どこの権限が付与されるかを決定する。
+  # これはNamespace「development」内の権限のみ付与する。
+  namespace: development
+subjects:
+- kind: User
+  name: dave # nameは大文字、小文字を区別する
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: secret-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+#### ClusterRoleBindingの例
+
+クラスター全体に権限を付与するには、ClusterRoleBindingを使用できます。
+以下のClusterRoleBindingはグループ「manager」のすべてのユーザーに
+Secretsの読み取りを許可します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+# このClusterRoleBindingはグループ「manager」のすべてのユーザーに任意のNamespaceのSecretsの読み取りを許可します。
+kind: ClusterRoleBinding
+metadata:
+  name: read-secrets-global
+subjects:
+- kind: Group
+  name: manager # nameは大文字、小文字を区別します
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: secret-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+Bindingを作成後は、それが参照するRoleまたはClusterRoleを変更できません。
+Bindingの`roleRef`を変更しようとすると、バリデーションエラーが発生します。Bindingの`roleRef`を変更する場合は、Bindingのオブジェクトを削除して、代わりのオブジェクトを作成する必要があります。
+
+この制限には２つの理由があります。
+
+1. `roleRef`をイミュータブルにすることで、誰かに既存のオブジェクトに対する`update`権限を付与します。それにより、subjectsに付与されたRoleの変更ができなくても、subjectsのリストを管理できるようになります。
+2. 異なるRoleへのBindingは根本的に異なるBindingです。
+`roleRef`を変更するためにBindingの削除/再作成を要求することによって、(すべての既存のsubjectsを確認せずに、roleRefだけを誤って変更できるようにするのとは対照的に)Binding内のsubjectsのリストのすべてが意図された新しいRoleが付与されることを担保します。
+
+`kubectl auth reconcile` コマンドラインユーティリティーはRBACオブジェクトを含んだマニフェストファイルを作成または更新します。また、それらが参照しているRoleへの変更を要求されると、Bindingオブジェクトの削除と再作成を取り扱います。
+詳細は[command usage and examples](#kubectl-auth-reconcile)を確認してください。
+
+### リソースを参照する
+
+KubernetesのAPIでは、ほとんどのリソースはPodであれば`pods`のように、オブジェクト名の文字列表現を使用して表されます。RBACは、関連するAPIエンドポイントのURLに表示されるものとまったく同じ名前を使用するリソースを参照します。
+一部のKubernetes APIには、Podのログなどの
+_subresource_　が含まれます。Podのログのリクエストは次のようになります。
+
+```http
+GET /api/v1/namespaces/{namespace}/pods/{name}/log
+```
+
+この場合、`pods` はPodリソースのNamespaceに属するリソースであり、`log`は`pods`のサブリソースです。これをRBACRoleで表すには、スラッシュ(`/`)を使用してリソースとサブリソースを区切ります。サブジェクトへの`pods`の読み込みと各Podの`log`サブリソースへのアクセスを許可するには、次のように記述します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  namespace: default
+  name: pod-and-pod-logs-reader
+rules:
+- apiGroups: [""]
+  resources: ["pods", "pods/log"]
+  verbs: ["get", "list"]
+```
+
+`resourceNames`リストを通じて、特定のリクエストのリソースを名前で参照することもできます。
+指定すると、リクエストをリソースの個々のインスタンスに制限できます。
+以下は対象を`get`または`my-configmap`と名付けられた
+{{< glossary_tooltip term_id="ConfigMap" >}}を`update`のみに制限する例です。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  namespace: default
+  name: configmap-updater
+rules:
+- apiGroups: [""]
+  #
+  # HTTPレベルでの、ConfigMapにアクセスするリソースの名前
+  # オブジェクトは"configmaps"
+  resources: ["configmaps"]
+  resourceNames: ["my-configmap"]
+  verbs: ["update", "get"]
+```
+
+{{< note >}}
+`resourceNames`で`create`または`deletecollection`のリクエストを制限することはできません。この制限は`create`の場合、認証時にオブジェクト名がわからないためです。
+{{< /note >}}
+
+
+### 集約ClusterRole
+
+複数のClusterRoleを一つのClusterRoleに _集約_ できます。
+クラスターコントロールプレーンの一部として実行されるコントローラーは、`aggregationRule`セットを持つClusterRoleオブジェクトを監視します。`aggregationRule`はコントローラーが、このオブジェクトの`rules`フィールドに結合する必要のある他のClusterRoleオブジェクトを一致させるために使用するラベル{{< glossary_tooltip text="selector" term_id="selector" >}}を定義します。
+
+以下に、集約されたClusterRoleの例を示します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: monitoring
+aggregationRule:
+  clusterRoleSelectors:
+  - matchLabels:
+      rbac.example.com/aggregate-to-monitoring: "true"
+rules: [] # コントロールプレーンは自動的にルールを入力します
+```
+既存の集約されたClusterRoleのラベルセレクターと一致する新しいClusterRoleを作成すると、その変更をトリガーに、集約されたClusterRoleに新しいルールが追加されます。
+`rbac.example.com/aggregate-to-monitoring: true`ラベルが付けられた別のClusterRoleを作成して、ClusterRole「monitoring」にルールを追加する例を以下に示します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: monitoring-endpoints
+  labels:
+    rbac.example.com/aggregate-to-monitoring: "true"
+# ClusterRole「monitoring-endpoints」を作成すると、
+# 以下のルールがClusterRole「monitoring」に追加されます
+rules:
+- apiGroups: [""]
+  resources: ["services", "endpoints", "pods"]
+  verbs: ["get", "list", "watch"]
+```
+
+[デフォルトのユーザー向けRole](#デフォルトroleとclusterrolebinding)はClusterRoleの集約を使用します。これによりクラスター管理者として、 デフォルトroleを拡張するため、{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}}または集約されたAPIサーバーなどによって提供されたルールをカスタムリソースに含めることができます。
+
+例えば、次のClusterRoleでは、「admin」と「edit」のデフォルトのRoleでCronTabという名前のカスタムリソースを管理できますが、「view」のRoleではCronTabリソースに対して読み取りアクションのみを実行できます。CronTabオブジェクトは、APIサーバーから見たURLで`"crontabs"`と名前が付けられていると想定できます。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: aggregate-cron-tabs-edit
+  labels:
+    # デフォルトRoleの「admin」と「edit」にこれらの権限を追加する。
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+    rbac.authorization.k8s.io/aggregate-to-edit: "true"
+rules:
+- apiGroups: ["stable.example.com"]
+  resources: ["crontabs"]
+  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+---
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: aggregate-cron-tabs-view
+  labels:
+    # デフォルトRoleの「view」にこれらの権限を追加します。
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+rules:
+- apiGroups: ["stable.example.com"]
+  resources: ["crontabs"]
+  verbs: ["get", "list", "watch"]
+```
+
+#### Roleの例
+
+次の例は、RoleオブジェクトまたはClusterRoleオブジェクトからの抜粋であり、`rules`セクションのみを示しています。
+
+`"pods"`の読み取りを許可する
+{{< glossary_tooltip text="API Group" term_id="api-group" >}}。
+
+```yaml
+rules:
+- apiGroups: [""]
+  #
+  # HTTPレベルでの、Podにアクセスするリソースの名前
+  # オブジェクトは"pods"
+  resources: ["pods"]
+  verbs: ["get", "list", "watch"]
+```
+
+APIグループ`" extensions "`と `" apps "` の両方で、Deploymentsへの読み取り/書き込みを許可します。
+(HTTPレベルでURLのリソース部分に`"deployments"`を持つオブジェクトで)
+
+```yaml
+rules:
+- apiGroups: ["extensions", "apps"]
+  #
+  # HTTPレベルでの、Deploymentにアクセスするリソースの名前
+  # オブジェクトは"deployments"
+  resources: ["deployments"]
+  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+```
+
+コアAPIグループのPodの読み取り、および`"batch"`または`"extensions"`APIグループのJobリソースの読み取りまたは書き込みを許可します。
+
+
+```yaml
+rules:
+- apiGroups: [""]
+  #
+  # HTTPレベルでの、Podにアクセスするリソースの名前
+  # オブジェクトは"pods"
+  resources: ["pods"]
+  verbs: ["get", "list", "watch"]
+- apiGroups: ["batch", "extensions"]
+  #
+  # HTTPレベルでの、Jobにアクセスするリソースの名前
+  # オブジェクトは"jobs"
+  resources: ["jobs"]
+  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+```
+
+「my-config」という名前のConfigMapの読み取りを許可します(
+単一のNamespace内の単一のConfigMapに制限するRoleBinding)
+
+```yaml
+rules:
+- apiGroups: [""]
+  #
+  # HTTPレベルでの、ConfigMapにアクセスするリソースの名前
+  # オブジェクトは"configmaps"
+  resources: ["configmaps"]
+  resourceNames: ["my-config"]
+  verbs: ["get"]
+```
+
+
+コアグループ内のリソース `"nodes"`の読み取りを許可します(Nodeはクラスタースコープであり、ClusterRoleBindingが効果的であるため、ClusterRoleにバインドされている必要があります)。
+
+```yaml
+rules:
+- apiGroups: [""]
+  #
+  # HTTPレベルでの、Nodeにアクセスするリソースの名前
+  # オブジェクトは"nodes"
+  resources: ["nodes"]
+  verbs: ["get", "list", "watch"]
+```
+
+非リソースエンドポイント `/ healthz`およびすべてのサブパス(ClusterRoleBindingが効果的であるため、ClusterRoleにバインドされている必要があります)のGETおよびPOSTリクエストを許可します。
+
+```yaml
+rules:
+- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURLの「*」はサフィックスグロブマッチです
+  verbs: ["get", "post"]
+```
+
+### subjectsを参照する
+
+RoleBindingまたはClusterRoleBindingは、Roleをsubjectsにバインドします。subjectsはグループ、ユーザー、または{{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}にすることができます。
+
+Kubernetesはユーザー名を文字列として表します。
+これらは次のようにできます。「alice」などの単純な名前。「bob@example.com」のような電子メール形式の名前。または文字列として表される数値のユーザーID。 認証が必要な形式のユーザー名を生成するように[認証モジュール](https://kubernetes.io/ja/docs/reference/access-authn-authz/authentication/)を構成するかどうかは、クラスター管理者が決定します。
+
+{{< caution >}}
+プレフィックス`system:`はKubernetesシステムで使用するために予約されているため、誤って`system:`で始まる名前のユーザーまたはグループが存在しないようにする必要があります。
+この特別なプレフィックスを除いて、RBAC承認システムでは、ユーザー名の形式は問いません。
+{{< /caution >}}
+
+Kubernetesでは、Authenticatorモジュールがグループ情報を提供します。
+ユーザーと同様に、グループは文字列として表され、その文字列には、プレフィックス`system:`が予約されていることを除いて、フォーマット要件はありません。
+
+[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)の名前はプレフィックス`system:serviceaccount:`が付いており、名前のプレフィックス`system:serviceaccounts:`が付いているグループに属しています。
+
+{{< note >}}
+- `system:serviceaccount:` (単数)は、サービスアカウントのユーザー名のプレフィックスです。
+- `system:serviceaccounts:`(複数)は、サービスアカウントグループのプレフィックスです。
+{{< /note >}}
+
+#### RoleBindingの例 {#role-binding-examples}
+
+次の例は`RoleBinding`、`subjects`セクションのみを示す抜粋です。
+
+`alice@example.com`という名前のユーザーの場合。
+
+```yaml
+subjects:
+- kind: User
+  name: "alice@example.com"
+  apiGroup: rbac.authorization.k8s.io
+```
+
+`frontend-admins`という名前のグループの場合。
+
+```yaml
+subjects:
+- kind: Group
+  name: "frontend-admins"
+  apiGroup: rbac.authorization.k8s.io
+```
+
+Namespace「kube-system」のデフォルトのサービスアカウントの場合。
+
+```yaml
+subjects:
+- kind: ServiceAccount
+  name: default
+  namespace: kube-system
+```
+
+Namespace「qa」の全てのサービスアカウントの場合。
+
+```yaml
+subjects:
+- kind: Group
+  name: system:serviceaccounts:qa
+  apiGroup: rbac.authorization.k8s.io
+```
+
+任意のNamespaceの全てのサービスアカウントの場合。
+
+```yaml
+subjects:
+- kind: Group
+  name: system:serviceaccounts
+  apiGroup: rbac.authorization.k8s.io
+```
+
+すべての認証済みユーザーの場合。
+
+```yaml
+subjects:
+- kind: Group
+  name: system:authenticated
+  apiGroup: rbac.authorization.k8s.io
+```
+
+認証されていないすべてのユーザーの場合。
+
+```yaml
+subjects:
+- kind: Group
+  name: system:unauthenticated
+  apiGroup: rbac.authorization.k8s.io
+```
+
+すべてのユーザーの場合。
+
+```yaml
+subjects:
+- kind: Group
+  name: system:authenticated
+  apiGroup: rbac.authorization.k8s.io
+- kind: Group
+  name: system:unauthenticated
+  apiGroup: rbac.authorization.k8s.io
+```
+
+## デフォルトRoleとClusterRoleBinding
+
+APIサーバーは、デフォルトのClusterRoleオブジェクトとClusterRoleBindingオブジェクトのセットを作成します。
+これらの多くにはプレフィックス`system:`が付いています。これは、リソースがクラスターコントロールプレーンによって直接管理されることを示しています。
+デフォルトのすべてのClusterRoleおよびClusterRoleBindingには、ラベル`kubernetes.io/bootstrapping=rbac-defaults`が付いています。
+
+{{< caution >}}
+プレフィックスとして`system:`を含む名前で、ClusterRolesおよびClusterRoleBindingsを変更する場合は注意してください。
+これらのリソースを変更すると、クラスターが機能しなくなる可能性があります。
+{{< /caution >}}
+
+### 自動調整
+
+起動するたびに、APIサーバーはデフォルトのClusterRoleを不足している権限で更新し、
+デフォルトのClusterRoleBindingを不足しているsubjectsで更新します。
+これにより、誤った変更をクラスタが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、
+RoleとRoleBindingを最新の状態に保つことができます。
+
+この調整を無効化するには`rbac.authorization.kubernetes.io/autoupdate`をデフォルトのClusterRoleまたはRoleBindingのアノテーションを`false`に設定します。
+デフォルトの権限と subjectsがないと、クラスターが機能しなくなる可能性があることに注意してください。
+
+RBAC authorizerが有効な場合、自動調整はデフォルトで有効になっています。
+
+### APIディスカバリーRole {#discovery-roles}
+
+デフォルトのRoleBindingでは、認証されていないユーザーと認証されたユーザーが、パブリックアクセスが安全であると見なされるAPI情報(CustomResourceDefinitionを含む)の読み取りを認可しています。匿名の非認証アクセスを無効にするには、APIサーバー構成に`--anonymous-auth=false` 追加します。
+
+`kubectl`の実行によってこれらのRoleの構成を表示するには。
+
+```shell
+kubectl get clusterroles system:discovery -o yaml
+```
+
+{{< note >}}
+ClusterRoleを編集すると、変更が[自動調整](#自動調整)によるAPIサーバーの再起動時に上書きされます。この上書きを回避するにはRoleを手動で編集しないか、自動調整を無効にします。
+{{< /note >}}
+
+<table>
+<caption>Kubernetes RBAC APIディスカバリーRole</caption>
+<colgroup><col width="25%" /><col width="25%" /><col /></colgroup>
+<tr>
+<th>デフォルトのClusterRole</th>
+<th>デフォルトのClusterRoleBinding</th>
+<th>説明</th>
+</tr>
+<tr>
+<td><b>system:basic-user</b></td>
+<td><b>system:authenticated</b> group</td>
+<td>ユーザーに、自身に関する基本情報への読み取り専用アクセスを許可します。v1.14より前は、このRoleはデフォルトで<tt>system:unauthenticated</tt>にもバインドされていました。</td>
+</tr>
+<tr>
+<td><b>system:discovery</b></td>
+<td><b>system:authenticated</b> group</td>
+<td>APIレベルのディスカバリーとネゴシエーションに必要なAPIディスカバリーエンドポイントへの読み取り専用アクセスを許可します。v1.14より前は、このRoleはデフォルトで<tt>system:unauthenticated</tt>にもバインドされていました。</td>
+</tr>
+<tr>
+<td><b>system:public-info-viewer</b></td>
+<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
+<td>クラスターに関する機密情報以外への読み取り専用アクセスを許可します。Kubernetes v1.14で導入されました。</td>
+</tr>
+</table>
+
+### ユーザー向けRole
+
+一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスタ全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。
+
+ユーザー向けのClusterRolesは[ClusterRoleの集約](#集約clusterrole)を使用して、管理者がこれらのClusterRolesにカスタムリソースのルールを含めることができるようにします。ルールを`admin`、`edit`、または`view` Roleに追加するには、次のラベルの一つ以上でClusterRoleを作成します。
+
+```yaml
+metadata:
+  labels:
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+    rbac.authorization.k8s.io/aggregate-to-edit: "true"
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+```
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>デフォルトのClusterRole</th>
+<th>デフォルトのClusterRoleBinding</th>
+<th>説明</th>
+</tr>
+<tr>
+<td><b>cluster-admin</b></td>
+<td><b>system:masters</b> group</td>
+<td>スーパーユーザーが任意のリソースで任意のアクションを実行できるようにします。
+<b>ClusterRoleBinding</b>で使用すると、クラスター内およびすべてのNamespace内のすべてのリソースを完全に制御できます。
+<b>RoleBinding</b>で使用すると、Namespace自体を含む、RoleBindingのNamespace内のすべてのリソースを完全に制御できます。</td>
+</tr>
+<tr>
+<td><b>admin</b></td>
+<td>None</td>
+<td><b>RoleBinding</b>を使用してNamespace内で付与することを想定した、管理者アクセスを許可します。
+<b>RoleBinding</b>で使用した場合、Namespace内にRoleとRoleBindingを作成する機能を含め、Namespaceのほとんどのリソースへの読み取り/書き込みアクセスを許可します。
+このRoleは、リソースクォータまたはNamespace自体への書き込みアクセスを許可しません。</td>
+</tr>
+<tr>
+<td><b>edit</b></td>
+<td>None</td>
+<td>Namespace内のほとんどのオブジェクトへの読み取り/書き込みアクセスを許可します。
+
+このRoleは、RoleまたはRoleBindingの表示または変更を許可しません。
+ただし、このRoleでは、Secretsにアクセスして、Namespace内の任意のServiceAccountとしてPodsを実行できるため、Namespace内の任意のServiceAccountのAPIアクセスレベルを取得するために使用できます。</td>
+</tr>
+<tr>
+<td><b>view</b></td>
+<td>None</td>
+<td>Namespace内のほとんどのオブジェクトを表示するための読み取り専用アクセスを許可します。
+RoleまたはRoleBindingは表示できません。
+
+Secretsの内容を読み取るとNamespaceのServiceAccountのクレデンシャルにアクセスできるため、このRoleではSecretsの表示は許可されません。これにより、Namespace内の任意のServiceAccountとしてAPIアクセスが許可されます(特権昇格の形式)。</td>
+</tr>
+</table>
+
+### コアコンポーネントのRole
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>デフォルトのClusterRole</th>
+<th>デフォルトのClusterRoleBinding</th>
+<th>説明</th>
+</tr>
+<tr>
+<td><b>system:kube-scheduler</b></td>
+<td><b>system:kube-scheduler</b> user</td>
+<td>{{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}コンポーネントが必要とするリソースへのアクセスを許可します。</td>
+</tr>
+<tr>
+<td><b>system:volume-scheduler</b></td>
+<td><b>system:kube-scheduler</b> user</td>
+<td>kube-scheduleコンポーネントが必要とするリソースへのアクセスを許可します。</td>
+</tr>
+<tr>
+<td><b>system:kube-controller-manager</b></td>
+<td><b>system:kube-controller-manager</b> user</td>
+<td>{{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}}コンポーネントが必要とするリソースへのアクセスを許可します。
+個々のコントローラーに必要な権限については、<a href="#controller-roles">組み込みコントローラーのRoleで詳しく説明しています</a>。</td>
+</tr>
+<tr>
+<td><b>system:node</b></td>
+<td>None</td>
+<td><b>すべてのsecretへの読み取りアクセス、すべてのポッドステータスオブジェクトへの書き込みアクセスなど、</b>kubeletが必要とするリソースへのアクセスを許可します。
+
+<tt>system:node</tt>Roleの代わりに<a href="/docs/reference/access-authn-authz/node/">Node authorizer</a>と <a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction admission plugin</a>を使用し、それらで実行するようにスケジュールされたPodに基づいてkubeletへのAPIアクセスを許可する必要があります。
+
+<tt>system:node</tt>のRoleは、V1.8より前のバージョンからアップグレードしたKubernetesクラスターとの互換性のためだけに存在します。
+</td>
+</tr>
+<tr>
+<td><b>system:node-proxier</b></td>
+<td><b>system:kube-proxy</b> user</td>
+<td>{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}コンポーネントが必要とするリソースへのアクセスを許可します。</td>
+</tr>
+</table>
+
+### 他のコンポーネントのRole
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>デフォルトのClusterRole</th>
+<th>デフォルトのClusterRoleBinding</th>
+<th>説明</th>
+</tr>
+<tr>
+<td><b>system:auth-delegator</b></td>
+<td>None</td>
+<td>委任された認証と認可のチェックを許可します。
+これは一般に、認証と認可を統合するためにアドオンAPIサーバーで使用されます。</td>
+</tr>
+<tr>
+<td><b>system:heapster</b></td>
+<td>None</td>
+<td><a href="https://github.com/kubernetes/heapster">Heapster</a>コンポーネントのRole(非推奨)。</td>
+</tr>
+<tr>
+<td><b>system:kube-aggregator</b></td>
+<td>None</td>
+<td><a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a>コンポーネントのRole。</td>
+</tr>
+<tr>
+<td><b>system:kube-dns</b></td>
+<td><b><b>kube-system</b>Namespaceのサービスアカウントkube-dns</b></td>
+<td><a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a>コンポーネントのRole。</td>
+</tr>
+<tr>
+<td><b>system:kubelet-api-admin</b></td>
+<td>None</td>
+<td>kubelet APIへのフルアクセスを許可します。</td>
+</tr>
+<tr>
+<td><b>system:node-bootstrapper</b></td>
+<td>None</td>
+<td><a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">kubelet TLS bootstrapping</a>の実行に必要なリソースへのアクセスを許可します。</td>
+</tr>
+<tr>
+<td><b>system:node-problem-detector</b></td>
+<td>None</td>
+<td><a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a>コンポーネントのRole。</td>
+</tr>
+<tr>
+<td><b>system:persistent-volume-provisioner</b></td>
+<td>None</td>
+<td>ほとんどの<a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>が必要とするリソースへのアクセスを許可します。</td>
+</tr>
+</table>
+
+### 組み込みコントローラーのRole {#controller-roles}
+
+Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}}は、Kubernetesコントロールプレーンに組み込まれている{{< glossary_tooltip term_id="controller" text="controllers" >}}を実行します。
+`--use-service-account-credentials`を指定して呼び出すと、kube-controller-manager個別のサービスアカウントを使用して各コントローラーを起動します。
+組み込みコントローラーごとに、プレフィックス`system:controller:`付きの対応するRoleが存在します。
+コントローラーマネージャーが`--use-service-account-credentials`で開始されていない場合、コントローラマネージャーは、関連するすべてのRoleを付与する必要がある自身のクレデンシャルを使用して、すべてのコントロールループを実行します。
+これらのRoleは次のとおりです。
+
+* `system:controller:attachdetach-controller`
+* `system:controller:certificate-controller`
+* `system:controller:clusterrole-aggregation-controller`
+* `system:controller:cronjob-controller`
+* `system:controller:daemon-set-controller`
+* `system:controller:deployment-controller`
+* `system:controller:disruption-controller`
+* `system:controller:endpoint-controller`
+* `system:controller:expand-controller`
+* `system:controller:generic-garbage-collector`
+* `system:controller:horizontal-pod-autoscaler`
+* `system:controller:job-controller`
+* `system:controller:namespace-controller`
+* `system:controller:node-controller`
+* `system:controller:persistent-volume-binder`
+* `system:controller:pod-garbage-collector`
+* `system:controller:pv-protection-controller`
+* `system:controller:pvc-protection-controller`
+* `system:controller:replicaset-controller`
+* `system:controller:replication-controller`
+* `system:controller:resourcequota-controller`
+* `system:controller:root-ca-cert-publisher`
+* `system:controller:route-controller`
+* `system:controller:service-account-controller`
+* `system:controller:service-controller`
+* `system:controller:statefulset-controller`
+* `system:controller:ttl-controller`
+
+## 特権昇格の防止とブートストラップ
+
+RBAC APIは、RoleまたはRoleBindingを編集することにより、ユーザーが特権を昇格するのを防ぎます。
+これはAPIレベルで適用されるため、RBAC authorizerが使用されていない場合でも適用されます。
+
+### Roleの作成または更新に関する制限
+
+次の項目1つ以上が当てはまる場合にのみ、Roleを作成/更新できます。
+
+1. 変更対象のオブジェクトと同じスコープで、Roleに含まれるすべての権限を既に持っている(ClusterRoleの場合はクラスター全体。Roleの場合は、同じNamespace内またはクラスター全体)。
+2. `rbac.authorization.k8s.io`APIグループの` roles`または`clusterroles`リソースで` escalate` verbを実行する明示的な権限が付与されている。
+
+たとえば、 `user-1`にクラスター全体でSecretsを一覧表示する権限がない場合、それらにその権限を含むClusterRoleを作成できません。
+ユーザーがRoleを作成/更新できるようにするには、以下のいずれかを実施します。
+
+1. 必要に応じて、RoleオブジェクトまたはClusterRoleオブジェクトを作成/更新できるRoleを付与する。
+2. 作成/更新するRoleに特定の権限を含む権限を付与する。
+    * 暗黙的に、これらの権限を付与することにより(自分自身が付与されていない権限でRoleまたはClusterRoleを作成または変更しようとすると、APIリクエストは禁止されます)。
+    * または、`rbac.authorization.k8s.io`APIグループの` roles`または `clusterroles`リソースで` escalate` verbを実行する権限を与えることにより、 `Role`または` ClusterRole`で権限を指定することを明示的に許可する
+
+### RoleBindingの作成または更新に関する制限
+
+参照されるRoleに含まれるすべての権限を(RoleBindingと同じスコープで)すでに持っている場合、
+*または*参照されたRoleで`bind` verbを実行する認可されている場合のみ、RoleBindingを作成/更新できます。
+たとえば、 `user-1`にクラスター全体でSecretsを一覧表示する権限がない場合、ClusterRoleBindingを作成してもRoleにその権限を付与できません。
+ユーザーがRoleBindingを作成/更新できるようにするには、以下のいずれかを実施します。
+
+1. 必要に応じて、RoleBindingまたはClusterRoleBindingオブジェクトを作成/更新できるようにする役割を付与する。
+2. 特定の役割をバインドするために必要なアクセス許可を付与する。
+    * 暗黙的に、Roleに含まれる権限を付与することによって。
+    * 明示的に、特定のRole(またはClusterRole)で `bind` verbを実行する許可を与えることによって。
+
+たとえば、このClusterRoleとRoleBindingを使用すると、 `user-1`は他のユーザーにNamespace` user-1-namespace`の `admin`、` edit`、および `view`Roleを付与します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: role-grantor
+rules:
+- apiGroups: ["rbac.authorization.k8s.io"]
+  resources: ["rolebindings"]
+  verbs: ["create"]
+- apiGroups: ["rbac.authorization.k8s.io"]
+  resources: ["clusterroles"]
+  verbs: ["bind"]
+  resourceNames: ["admin","edit","view"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: role-grantor-binding
+  namespace: user-1-namespace
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: role-grantor
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: User
+  name: user-1
+```
+
+最初のRoleとRoleBindingをブートストラップするときは、最初のユーザーがまだ持っていない権限を付与する必要があります。
+初期RoleとRoleBindingをブートストラップするには、以下のいずれかを実施します。
+
+* 「system：masters」グループのクレデンシャルを使用します。このグループは、デフォルトのBindingによって「cluster-admin」スーパーユーザーRoleにバインドされています。
+* APIサーバーが安全でないポート(`--insecure-port`)を有効にして実行されている場合、そのポートを介してのAPI呼び出しもできます。これにより、認証や認可が実行されません。
+
+## コマンドラインユーティリティー
+
+### `kubectl create role`
+
+以下に、単一のNamespace内で権限を定義するRoleオブジェクトをいくつか例として作成します。
+
+* ユーザーがポッドで `get`、` watch`、および `list`を実行できるように「pod-reader」という名前のRoleを作成します。
+
+    ```shell
+    kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
+    ```
+
+* resourceNamesを指定して、「pod-reader」という名前のRoleを作成します。
+
+    ```shell
+    kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
+    ```
+
+* apiGroupsを指定して「foo」という名前のRoleを作成します。
+
+    ```shell
+    kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
+    ```
+
+* サブリソースの権限を持つ「foo」という名前のRoleを作成します。
+* Create a Role named "foo" with subresource permissions:
+
+    ```shell
+    kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
+    ```
+* 特定の名前のリソースを取得/更新する権限を持つ「my-component-lease-holder」という名前のRoleを作成します。
+
+    ```shell
+    kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
+    ```
+
+### `kubectl create clusterrole`
+
+以下にClusterRoleをいくつか例として作成します。
+
+* ユーザーがポッドに対して`get`、` watch`、および `list`を実行できるようにする「pod-reader」という名前のClusterRoleを作成します。
+
+    ```shell
+    kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
+    ```
+
+* resourceNamesを指定して、「pod-reader」という名前のClusterRoleを作成します。
+
+    ```shell
+    kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
+    ```
+
+* apiGroupsを指定して「foo」という名前のClusterRoleを作成します。
+
+    ```shell
+    kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
+    ```
+
+* サブリソースの権限を持つ「foo」という名前のClusterRoleを作成します。
+
+    ```shell
+    kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
+    ```
+
+* nonResourceURLを指定して「foo」という名前のClusterRoleを作成します。
+
+    ```shell
+    kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
+    ```
+
+* aggregationRuleを指定して、「monitoring」という名前のClusterRoleを作成します。
+
+    ```shell
+    kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
+    ```
+
+### `kubectl create rolebinding`
+
+以下に、特定のNamespace内でRoleまたはClusterRoleをいくつか例として付与します。
+
+* Namespace「acme」内で、「admin」ClusterRoleの権限を「bob」という名前のユーザーに付与します。
+
+    ```shell
+    kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
+    ```
+
+* Namespace「acme」内で、ClusterRole「view」へのアクセス許可を「myapp」というNamespace「acme」のサービスアカウントに付与します。
+
+    ```shell
+    kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
+    ```
+
+* Namespace「acme」内で、ClusterRole「view」へのアクセス許可を「myapp」というNamespace「myappnamespace」のサービスアカウントに付与します。
+
+    ```shell
+    kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
+    ```
+
+### `kubectl create clusterrolebinding`
+
+以下に、クラスタ全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。
+
+* クラスター全体で、ClusterRole「cluster-admin」へのアクセス許可を「root」という名前のユーザーに付与します。
+
+    ```shell
+    kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
+    ```
+
+* クラスター全体で、ClusterRole「system：node-proxier」へのアクセス許可を「system：kube-proxy」という名前のユーザーに付与します。
+
+    ```shell
+    kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
+    ```
+
+* クラスター全体で、ClusterRole「view」へのアクセス許可を、Namespace「acme」の「myapp」という名前のサービスアカウントに付与します。
+
+    ```shell
+    kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
+    ```
+
+### `kubectl auth reconcile` {#kubectl-auth-reconcile}
+
+マニフェストファイルから `rbac.authorization.k8s.io/v1`APIオブジェクトを作成または更新します。
+
+欠落しているオブジェクトが作成され、必要に応じて、Namespaceに属するオブジェクト用にオブジェクトを含むNamespaceが作成されます。
+
+既存のRoleが更新され、入力オブジェクトに権限が含まれるようになります。
+`--remove-extra-permissions`が指定されている場合は、余分な権限を削除します。
+
+既存のBindingが更新され、入力オブジェクトにsubjectsが含まれるようになります。
+`--remove-extra-subjects`が指定されている場合は、余分な件名を削除します。
+
+以下、例として。
+
+* RBACオブジェクトのマニフェストファイルをテストとして適用し、行われる変更を表示します。
+
+    ```
+    kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
+    ```
+
+* RBACオブジェクトのマニフェストファイルを適用し、(Role内の)追加のアクセス許可と(Binding内の)追加のsubjectsを保持します。
+
+    ```shell
+    kubectl auth reconcile -f my-rbac-rules.yaml
+    ```
+
+* RBACオブジェクトのマニフェストファイルを適用し、(Role内の)余分なアクセス許可と(Binding内の)余分なsubjectsを削除します。
+
+## ServiceAccount権限 {#service-account-permissions}
+
+デフォルトのRBACポリシーは、コントロールプレーンコンポーネント、ノード、
+およびコントローラーをスコープとして権限を付与しますが、 Namespace`kube-system`外のサービスアカウントには*no permissions*で付与します
+(すべての認証されたユーザーに与えられたディスカバリー権限に関わらず)。
+
+これにより、必要に応じて特定のServiceAccountに特定のRoleを付与できます。
+きめ細かいRoleBindingはセキュリティを強化しますが、管理にはより多くの労力が必要です。
+より広範な権限は、不必要な(そして潜在的にエスカレートする)APIアクセスをServiceAccountsに与える可能性がありますが、管理が簡単です。
+
+アプローチを最も安全なものから最も安全でないものの順に並べると、次のとおりです。
+
+1. アプリケーション固有のサービスアカウントにRoleを付与する(ベストプラクティス)
+    これには、アプリケーションがpodのspec、そして作成するサービスアカウント(API、アプリケーションマニフェスト、 `kubectl create serviceaccount`などを介して）で`serviceAccountName`を指定する必要があります。
+    たとえば、「my-namespace」内の読み取り専用権限を「my-sa」サービスアカウントに付与します。
+
+    ```shell
+    kubectl create rolebinding my-sa-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:my-sa \
+      --namespace=my-namespace
+    ```
+
+2. あるNamespaceのサービスアカウント「default」にRoleを付与します
+
+    アプリケーションが `serviceAccountName`を指定しない場合、サービスアカウント「default」を使用します。
+
+    {{< note >}}
+  サービスアカウント「default」に付与された権限は、`serviceAccountName`を指定しないNamespace内のすべてのポッドで利用できます。
+    {{< /note >}}
+
+    たとえば、「my-namespace」内の読み取り専用権限をサービスアカウント「default」に付与します。
+
+    ```shell
+    kubectl create rolebinding default-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:default \
+      --namespace=my-namespace
+    ```
+
+    多くの[アドオン](https://kubernetes.io/docs/concepts/cluster-administration/addons/)は、
+    Namespace`kube-system`のサービスアカウント「default」として実行されます。
+    これらのアドオンをスーパーユーザーアクセスでの実行を許可するには、Namespace`kube-system`のサービスアカウント「default」のcluster-admin権限を付与します。
+
+    {{< caution >}}
+    これを有効にすると、 Namespace`kube-systemにクラスターのAPIへのスーパーユーザーアクセス許可するSecretsが含まれます。
+    {{< /caution >}}
+
+    ```shell
+    kubectl create clusterrolebinding add-on-cluster-admin \
+      --clusterrole=cluster-admin \
+      --serviceaccount=kube-system:default
+    ```
+
+3. Namespace内のすべてのサービスアカウントにRoleを付与します
+
+    Namespace内のすべてのアプリケーションにRoleを持たせたい場合は、使用するサービスアカウントに関係なく、
+    そのNamespaceのサービスアカウントグループにRoleを付与できます。
+
+    たとえば、「my-namespace」内の読み取り専用アクセス許可を、そのNamespace内のすべてのサービスアカウントに付与します。
+
+    ```shell
+    kubectl create rolebinding serviceaccounts-view \
+      --clusterrole=view \
+      --group=system:serviceaccounts:my-namespace \
+      --namespace=my-namespace
+    ```
+
+4. クラスター全体のすべてのサービスアカウントに制限されたRoleを付与します(お勧めしません)
+
+    Namespaceごとのアクセス許可を管理したくない場合は、すべてのサービスアカウントにクラスター全体の役割を付与できます。
+
+    たとえば、クラスター内のすべてのサービスアカウントに、すべてのNamespaceで読み取り専用のアクセス許可を付与します。
+
+    ```shell
+    kubectl create clusterrolebinding serviceaccounts-view \
+      --clusterrole=view \
+     --group=system:serviceaccounts
+    ```
+
+5. クラスター全体のすべてのサービスアカウントへのスーパーユーザーアクセスを許可します。(強くお勧めしません)
+
+    権限の分割をまったく考慮しない場合は、すべてのサービスアカウントにスーパーユーザーアクセスを許可できます。
+
+    {{< warning >}}
+    これにより、すべてのアプリケーションにクラスターへのフルアクセスが許可され、Secretsの読み取りアクセス権(または任意のポッドを作成する機能)を持つユーザーに、クラスターへのフルアクセスが許可されます。
+    {{< /warning >}}
+
+    ```shell
+    kubectl create clusterrolebinding serviceaccounts-cluster-admin \
+      --clusterrole=cluster-admin \
+      --group=system:serviceaccounts
+    ```
+
+## ABACからアップグレードする
+
+以前は古いバージョンのKubernetesを実行していたクラスターは、すべてのサービスアカウントに完全なAPIアクセスを許可するなど、permissiveなABACポリシーを使用することがよくありました。
+
+デフォルトのRBACポリシーは、コントロールプレーンコンポーネント、ノード、
+およびコントローラーをスコープとして権限を付与しますが、 Namespace`kube-system`外のサービスアカウントには*no permissions*で付与します
+(すべての認証されたユーザーに与えられたディスカバリー権限に関わらず)。
+
+これははるかに安全ですが、API権限を自動的に受け取ることを期待している既存のワークロードを混乱させる可能性があります。
+この移行を管理するための2つのアプローチは次のとおりです。
+
+### 並行認可
+
+
+RBACとABACの両方のauthorizerを実行し、[legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format)を含むポリシーファイルを指定します。
+
+```
+--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json
+```
+
+最初のコマンドラインオプションを詳細に説明すると、Nodeなどの以前のauthorizerが
+要求を拒否すると、RBAC authorizerはAPI要求を認可しようとします。 RBACの場合
+また、そのAPI要求を拒否すると、ABAC authorizerが実行されます。これにより、すべてのリクエストが
+RBACまたはABACポリシーの*いずれか*で許可されます。
+
+RBACコンポーネントのログレベルが5以上でkube-apiserverを実行した場合(`--vmodule = rbac * = 5`または` --v = 5`)、APIサーバーログでRBACの拒否を確認できます(プレフィックスは「RBAC」)。
+その情報を使用して、どのRoleをどのユーザー、グループ、またはサービスアカウントに付与する必要があるかを判断できます。
+
+[サービスアカウントに付与されたRole](#service-account-permissions)を取得し、
+ワークロードがサーバーログにRBACの拒否メッセージがない状態で実行されている場合は、ABAC authorizerを削除できます。
+
+### Permissive RBAC権限
+
+RBACRoleBindingを使用して、permissive ABACポリシーを複製できます。
+
+{{< warning >}}
+次のポリシーでは、**すべて**のサービスアカウントがクラスター管理者としてふるまうことを許可しています。
+コンテナで実行されているアプリケーションは、サービスアカウントのクレデンシャルを自動的に受け取ります。
+secretsの表示や権限の変更など、APIに対して任意のアクションを実行できます。
+これは推奨されるポリシーではありません。
+
+```shell
+kubectl create clusterrolebinding permissive-binding \
+  --clusterrole=cluster-admin \
+  --user=admin \
+  --user=kubelet \
+  --group=system:serviceaccounts
+```
+{{< /warning >}}
+
+RBACの使用に移行後、クラスターが情報セキュリティのニーズを確実に満たすように、アクセスコントロールを調整する必要があります。
diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md
index 4c2da51da6..2fc9f826f7 100644
--- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md
@@ -35,23 +35,18 @@ content_type: concept
 
 | 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン |
 |---------|---------|-------|-------|-------|
+| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | |
 | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
 | `APIListChunking` | `true` | Beta | 1.9 | |
 | `APIPriorityAndFairness` | `false` | Alpha | 1.17 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
 | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
-| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
-| `BlockVolume` | `true` | Beta | 1.13 | - |
 | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
 | `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
 | `CPUManager` | `true` | Beta | 1.10 | |
 | `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 |
 | `CRIContainerLogRotation` | `true` | Beta| 1.11 | |
-| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
-| `CSIBlockVolume` | `true` | Beta | 1.14 | |
-| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
-| `CSIDriverRegistry` | `true` | Beta | 1.14 | |
 | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
 | `CSIInlineVolume` | `true` | Beta | 1.16 | - |
 | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
@@ -68,6 +63,7 @@ content_type: concept
 | `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
 | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
+| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
 | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
@@ -80,6 +76,8 @@ content_type: concept
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
 | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | Beta | 1.17 | |
+| `EndpointSlice` | `true` | Beta | 1.18 | |
+| `EndpointSliceProxying` | `false` | Alpha | 1.18 | |
 | `EphemeralContainers` | `false` | Alpha | 1.16 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
@@ -88,9 +86,12 @@ content_type: concept
 | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `EvenPodsSpread` | `false` | Alpha | 1.16 | |
+| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 |
+| `EvenPodsSpread` | `true` | Beta | 1.18 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
+| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | |
 | `HyperVContainer` | `false` | Alpha | 1.10 | |
+| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | |
 | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | Beta | 1.15 | |
 | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
@@ -100,6 +101,8 @@ content_type: concept
 | `MountContainers` | `false` | Alpha | 1.9 | |
 | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
 | `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
+| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 |
+| `PodDisruptionBudget` | `true` | Beta | 1.5 | |
 | `PodOverhead` | `false` | Alpha | 1.16 | - |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
@@ -114,8 +117,12 @@ content_type: concept
 | `SCTPSupport` | `false` | Alpha | 1.12 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
+| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
-| `StartupProbe` | `true` | Beta | 1.17 | |
+| `ServiceTopology` | `false` | Alpha | 1.17 | |
+| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
+| `StartupProbe` | `true` | Beta | 1.18 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
 | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
@@ -125,8 +132,6 @@ content_type: concept
 | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
 | `SupportPodPidsLimit` | `true` | Beta | 1.14 | |
 | `Sysctls` | `true` | Beta | 1.11 | |
-| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
-| `TaintBasedEvictions` | `true` | Beta | 1.13 | |
 | `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
 | `TokenRequest` | `true` | Beta | 1.12 | |
 | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
@@ -160,6 +165,15 @@ content_type: concept
 | `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
 | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
 | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
+| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
+| `BlockVolume` | `true` | Beta | 1.13 | 1.17 |
+| `BlockVolume` | `true` | GA | 1.18 | - |
+| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
+| `CSIBlockVolume` | `true` | Beta | 1.14 | 1.17 |
+| `CSIBlockVolume` | `true` | GA | 1.18 | - |
+| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
+| `CSIDriverRegistry` | `true` | Beta | 1.14 | 1.17 |
+| `CSIDriverRegistry` | `true` | GA | 1.18 | |
 | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
 | `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 |
 | `CSINodeInfo` | `true` | GA | 1.17 | |
@@ -240,9 +254,18 @@ content_type: concept
 | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
 | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
+| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
+| `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 |
+| `TaintBasedEvictions` | `true` | GA | 1.18 | - |
 | `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
 | `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 |
 | `TaintNodesByCondition` | `true` | GA | 1.17 | - |
+| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
+| `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 |
+| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
+| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
+| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
+| `VolumeScheduling` | `true` | GA | 1.13 | - |
 | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
@@ -253,6 +276,12 @@ content_type: concept
 | `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
 | `WatchBookmark` | `true` | Beta | 1.16 | 1.16 |
 | `WatchBookmark` | `true` | GA | 1.17 | - |
+| `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 |
+| `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 |
+| `WindowsGMSA` | `true` | GA | 1.18 | - |
+| `WindowsRunAsUserName` | `false` | Alpha | 1.16 | 1.16 |
+| `WindowsRunAsUserName` | `true` | Beta | 1.17 | 1.17 |
+| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
 {{< /table >}}
 
 ## 機能を使用する
@@ -292,7 +321,8 @@ GAになってからさらなる変更を加えることは現実的ではない
 
 - `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。
 - `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。
-- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
+- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
+- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}の`DataSource`としてカスタムリソースの使用を有効にします。
 - `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。
 - `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
 `APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
@@ -302,6 +332,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
 - `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。
+- `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。
 - `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。
 - `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。
 - `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。
@@ -309,7 +340,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。
 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。
 - `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
-- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。 CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。
+- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。
 - `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
 - `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。
 - `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
@@ -325,9 +356,9 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。
 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
-- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
-- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
-- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
+- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
+- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
+- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。
 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。
 - `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
@@ -340,29 +371,33 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。
 - `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。
 - `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。
-- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。
+- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。
 - `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。
-- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
+- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
+- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。
 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
 - `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
+- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。
 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
 - `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。
+- `ImmutableEphemeralVolumes`: 安全性とパフォーマンスを向上させるために、個々のSecretとConfigMapが不変となるように指定できるようにします。
 - `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。
 - `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。
-- `KubeletPodResources`: kubeletのpodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)で確認できます。
+- `KubeletPodResources`: kubeletのPodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)で確認できます。
 - `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。
-- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
+- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
 - `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。
-- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはpodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
+- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
 - `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。
 - `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。
 - `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。
-- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。
+- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、Podアフィニティを指定する必要があります。
 - `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
+- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。
 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
-- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
+- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
@@ -375,26 +410,30 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
 - `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
 - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
+- `ServiceAccountIssuerDiscovery`: APIサーバーにてサービスアカウント発行者のOIDC検出エンドポイント（発行者とJWKS URL）を有効にします。詳細については、[Podのサービスアカウント設定](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)をご覧ください。
+- `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。
 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
+- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
 - `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
 - `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
 - `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
 - `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。
-- `Sysctls`: 各podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
-- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。
-- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。
+- `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
+- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。
+- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。
 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
-- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。
+- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。
 - `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
 - `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。
 - `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。
 - `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。
-- `WindowsGMSA`: GMSA資格仕様をpodからコンテナランタイムに渡せるようにします。
+- `WindowsGMSA`: GMSA資格仕様をPodからコンテナランタイムに渡せるようにします。
+- `WindowsRunAsUserName`: デフォルト以外のユーザーでWindowsコンテナアプリケーションを実行するためのサポートを有効にします。詳細については、[RunAsUserNameの設定](/docs/tasks/configure-pod-container/configure-runasusername)を参照してください。
 - `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。
 - `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。
 
@@ -402,4 +441,3 @@ GAになってからさらなる変更を加えることは現実的ではない
 ## {{% heading "whatsnext" %}}
 
 * Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。
-
diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md
new file mode 100755
index 0000000000..6e9c9104da
--- /dev/null
+++ b/content/ja/docs/reference/glossary/cloud-controller-manager.md
@@ -0,0 +1,18 @@
+---
+title: クラウドコントローラーマネージャー
+id: cloud-controller-manager
+date: 2018-04-12
+full_link: /ja/docs/concepts/architecture/cloud-controller/
+short_description: >
+  サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント
+aka: 
+tags:
+- core-object
+- architecture
+- operation
+---
+ クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
+
+<!--more-->
+
+Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。
diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md
index 1153d68db8..00fd3ab3e3 100644
--- a/content/ja/docs/reference/glossary/control-plane.md
+++ b/content/ja/docs/reference/glossary/control-plane.md
@@ -11,3 +11,15 @@ tags:
 - fundamental
 ---
  コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
+
+ <!--more-->
+
+ このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。
+
+ * {{< glossary_tooltip text="etcd" term_id="etcd" >}}
+ * {{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}
+ * {{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}
+ * {{< glossary_tooltip text="コントローラーマネージャー" term_id="kube-controller-manager" >}}
+ * {{< glossary_tooltip text="クラウドコントローラーマネージャー" term_id="cloud-controller-manager" >}}
+
+ これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。
diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md
index 569cbbd6a1..7c9f090102 100755
--- a/content/ja/docs/reference/glossary/deployment.md
+++ b/content/ja/docs/reference/glossary/deployment.md
@@ -4,7 +4,7 @@ id: deployment
 date: 2018-04-12
 full_link: /ja/docs/concepts/workloads/controllers/deployment/
 short_description: >
-  複製されたアプリケーションを管理するAPIオブジェクトです。
+  クラスター上の複製されたアプリケーションを管理します。
 
 aka: 
 tags:
@@ -12,8 +12,9 @@ tags:
 - core-object
 - workload
 ---
- 複製されたアプリケーションを管理するAPIオブジェクトです。
+ 複製されたアプリケーションを管理するAPIオブジェクトで、通常はステートレスなPodを実行します。
 
 <!--more--> 
 
-各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。
+各レプリカは{{< glossary_tooltip text="Pod" term_id="pod" >}}で表され、Podはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。
+ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。
diff --git a/content/ja/docs/reference/glossary/node.md b/content/ja/docs/reference/glossary/node.md
index 0eb8976c1b..153b856243 100755
--- a/content/ja/docs/reference/glossary/node.md
+++ b/content/ja/docs/reference/glossary/node.md
@@ -15,3 +15,4 @@ tags:
 <!--more--> 
 
 ワーカーノードは、クラスターに応じてVMまたは物理マシンの場合があります。{{< glossary_tooltip text="Pod" term_id="pod" >}}の実行に必要なローカルデーモンまたはサービスがあり、コントロールプレーンによって管理されます。ノード上のデーモンには、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}、および{{< glossary_tooltip term_id="docker" >}}などの{{< glossary_tooltip text="CRI" term_id="cri" >}}を実装するコンテナランタイムが含まれます。
+Kubernetesの初期バージョンでは、ノードは"Minion"と呼ばれていました。
diff --git a/content/ja/docs/reference/glossary/platform-developer.md b/content/ja/docs/reference/glossary/platform-developer.md
index e5526cedf8..be1e695184 100755
--- a/content/ja/docs/reference/glossary/platform-developer.md
+++ b/content/ja/docs/reference/glossary/platform-developer.md
@@ -14,4 +14,4 @@ tags:
 
 <!--more--> 
 
-プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/docs/concepts/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/docs/concepts/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
+プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md
index 1fad77bd62..eb78c21fe3 100755
--- a/content/ja/docs/reference/glossary/statefulset.md
+++ b/content/ja/docs/reference/glossary/statefulset.md
@@ -4,7 +4,7 @@ id: statefulset
 date: 2018-04-12
 full_link: /ja/docs/concepts/workloads/controllers/statefulset/
 short_description: >
-  StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。
+  StatefulSetはDeploymentとPodのセットのスケーリングを管理し、永続化ストレージと各Podの永続的な識別子を備えています。
 
 aka: 
 tags:
@@ -20,5 +20,4 @@ StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}の
 
 {{< glossary_tooltip term_id="deployment" >}}のように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。
 
-StatefulSetは他のコントローラーと同様のパターンで動作します。ユーザーはStatefulSet*オブジェクト* の理想的な状態を定義し、StatefulSet*コントローラー* は現在の状態から、理想状態になるために必要なアップデートを行います。
-
+ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。
diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md
index 6a81f84522..b7021ad4e4 100644
--- a/content/ja/docs/reference/glossary/volume.md
+++ b/content/ja/docs/reference/glossary/volume.md
@@ -4,17 +4,17 @@ id: volume
 date: 2018-04-12
 full_link: /docs/concepts/storage/volumes/
 short_description: >
-  Pod内のコンテナからアクセス可能なデータを含むディレクトリです。
+  データを格納するディレクトリで、Pod内のコンテナからアクセス可能です。
 
-aka: 
+aka:
 tags:
 - core-object
 - fundamental
 ---
- {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。
+ データを格納するディレクトリで、{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。
 
-<!--more--> 
+<!--more-->
 
-Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。
+Kubernetesボリュームはボリュームを含んだPodが存在する限り有効です。そのため、ボリュームはPod内で実行されるどのコンテナよりも長く存在し、コンテナが再起動してもボリューム内のデータは維持されます。
 
-詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。
+詳しくは[ストレージ](/ja/docs/concepts/storage/)をご覧ください。
diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md
index d63654bd38..caf2fc783c 100644
--- a/content/ja/docs/reference/kubectl/cheatsheet.md
+++ b/content/ja/docs/reference/kubectl/cheatsheet.md
@@ -8,7 +8,7 @@ card:
 
 <!-- overview -->
 
-[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
+[Kubectl概要](/ja/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
 
 このページは`kubectl`コマンドの概要です。
 
@@ -37,14 +37,14 @@ complete -F __start_kubectl k
 ### ZSH
 
 ```bash
-source <(kubectl completion zsh)  # 現在のzshシェルでコマンド補完を設定します
+source <(kubectl completion zsh)  # 現在のzshシェルにコマンド補完を設定します
 echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
 ```
 
 ## Kubectlコンテキストの設定
 
 `kubectl`がどのKubernetesクラスターと通信するかを設定します。
-設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。
+設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。
 
 ```bash
 kubectl config view # マージされたkubeconfigの設定を表示します。
@@ -63,10 +63,10 @@ kubectl config get-contexts                          # コンテキストのリ
 kubectl config current-context                       # 現在のコンテキストを表示します
 kubectl config use-context my-cluster-name           # デフォルトのコンテキストをmy-cluster-nameに設定します
 
-# basic認証をサポートする新たなクラスターをkubeconfigに追加します
+# basic認証をサポートする新たなユーザーをkubeconfigに追加します
 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
 
-# 現在のコンテキストでkubectlのサブコマンドのネームスペースを永続的に変更します
+# 現在のコンテキストでkubectlのサブコマンドの名前空間を永続的に変更します
 kubectl config set-context --current --namespace=ggckad-s2
 
 # 特定のユーザー名と名前空間を使用してコンテキストを設定します
@@ -141,18 +141,18 @@ EOF
 
 ```bash
 # Getコマンドで基本的な情報を確認します
-kubectl get services                          # 現在のネームスペース上にあるすべてのサービスのリストを表示します
-kubectl get pods --all-namespaces             # すべてのネームスペース上にあるすべてのPodのリストを表示します
-kubectl get pods -o wide                      # 現在のネームスペース上にあるすべてのPodについてより詳細なリストを表示します
+kubectl get services                          # 現在の名前空間上にあるすべてのサービスのリストを表示します
+kubectl get pods --all-namespaces             # すべての名前空間上にあるすべてのPodのリストを表示します
+kubectl get pods -o wide                      # 現在の名前空間上にあるすべてのPodについてより詳細なリストを表示します
 kubectl get deployment my-dep                 # 特定のDeploymentを表示します
-kubectl get pods                              # 現在のネームスペース上にあるすべてのPodのリストを表示します
+kubectl get pods                              # 現在の名前空間上にあるすべてのPodのリストを表示します
 kubectl get pod my-pod -o yaml                # PodのYAMLを表示します
 
 # Describeコマンドで詳細な情報を確認します
 kubectl describe nodes my-node
 kubectl describe pods my-pod
 
-# 名前順にソートしたリストを表示します
+# 名前順にソートしたServiceのリストを表示します
 kubectl get services --sort-by=.metadata.name
 
 # Restartカウント順にPodのリストを表示します
@@ -165,33 +165,33 @@ kubectl get pv --sort-by=.spec.capacity.storage
 kubectl get pods --selector=app=cassandra -o \
   jsonpath='{.items[*].metadata.labels.version}'
 
+# 'ca.crt'のようなピリオドが含まれるキーの値を取得します
+kubectl get configmap myconfig \
+  -o jsonpath='{.data.ca\.crt}'
+
 # すべてのワーカーノードを取得します（セレクターを使用して、
 # 「node-role.kubernetes.io/master」という名前のラベルを持つ結果を除外します）
 kubectl get node --selector='!node-role.kubernetes.io/master'
 
-# 現在のネームスペースでrunning状態のPodをリストを表示します
+# 現在の名前空間でrunning状態のPodのリストを表示します
 kubectl get pods --field-selector=status.phase=Running
 
-# すべてのノードのExternal IPをリストを表示します
+# すべてのノードのExternal IPのリストを表示します
 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
 
 # 特定のRCに属するPodの名前のリストを表示します
 # `jq`コマンドは複雑なjsonpathを変換する場合に便利であり、https://stedolan.github.io/jq/で見つけることが可能です
-
 sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
 echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
 
 # すべてのPod(またはラベル付けをサポートする他のKubernetesオブジェクト)のラベルのリストを表示します
-
 kubectl get pods --show-labels
 
 # どのノードがready状態か確認します
-
 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
  && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
 
 # Podで現在使用中のSecretをすべて表示します
-
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
 
 # すべてのPodのInitContainerのコンテナIDのリストを表示します
@@ -199,17 +199,21 @@ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secre
 kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
 
 # タイムスタンプでソートされたEventのリストを表示します
-
 kubectl get events --sort-by=.metadata.creationTimestamp
 
 # クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。
 kubectl diff -f ./my-manifest.yaml
+
+# Nodeから返されるすべてのキーをピリオド区切りの階層表記で生成します。
+# 複雑にネストされたJSON構造をもつキーを指定したい時に便利です
+kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+
+# Pod等から返されるすべてのキーをピリオド区切り階層表記で生成します。
+kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
 ```
 
 ## リソースのアップデート
 
-version 1.11で`rolling-update`は廃止されました、代わりに`rollout`コマンドをお使いください(詳しくはこちらをご覧ください [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))。
-
 ```bash
 kubectl set image deployment/frontend www=image:v2               # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします
 kubectl rollout history deployment/frontend                      # frontend Deploymentの改訂履歴を確認します
@@ -219,11 +223,6 @@ kubectl rollout status -w deployment/frontend                    # frontend Depl
 kubectl rollout restart deployment/frontend                      # frontend Deployment を再起動します
 
 
-# これらのコマンドは1.11から廃止されました
-kubectl rolling-update frontend-v1 -f frontend-v2.json           # (廃止) frontend-v1 Podをローリングアップデートします
-kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (廃止) リソース名とイメージを変更します
-kubectl rolling-update frontend --image=image:v2                 # (廃止) frontendのイメージを変更します
-kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (廃止) 現在実行中のローリングアップデートを中止します
 cat pod.json | kubectl replace -f -                              # 標準入力から渡されたJSONに基づいてPodを置き換えます
 
 # リソースを強制的に削除してから再生成し、置き換えます。サービスの停止が発生します
@@ -260,7 +259,6 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1",
 ```
 
 ## リソースの編集
-
 任意のエディターでAPIリソースを編集します。
 
 ```bash
@@ -301,10 +299,10 @@ kubectl logs -f my-pod                              # Podのログをストリ
 kubectl logs -f my-pod -c my-container              # 複数のコンテナがあるPodで、特定のコンテナのログをストリームで確認します(標準出力)
 kubectl logs -f -l name=myLabel --all-containers    # name-myLabelラベルを持つすべてのコンテナのログをストリームで確認します(標準出力)
 kubectl run -i --tty busybox --image=busybox -- sh  # Podをインタラクティブシェルとして実行します
-kubectl run nginx --image=nginx --restart=Never -n 
-mynamespace                                         # 特定のネームスペースでnginx Podを実行します
-kubectl run nginx --image=nginx --restart=Never     # nginx Podを実行し、マニフェストファイルををpod.yamlという名前で書き込みます
---dry-run -o yaml > pod.yaml
+kubectl run nginx --image=nginx -n 
+mynamespace                                         # 特定の名前空間でnginx Podを実行します
+kubectl run nginx --image=nginx                     # nginx Podを実行し、マニフェストファイルをpod.yamlという名前で書き込みます
+--dry-run=client -o yaml > pod.yaml
 kubectl attach my-pod -i                            # 実行中のコンテナに接続します
 kubectl port-forward my-pod 5000:6000               # ローカルマシンのポート5000を、my-podのポート6000に転送します
 kubectl exec my-pod -- ls /                         # 既存のPodでコマンドを実行(単一コンテナの場合)
@@ -315,9 +313,9 @@ kubectl top pod POD_NAME --containers               # 特定のPodとそのコ
 ## ノードおよびクラスターとの対話処理
 
 ```bash
-kubectl cordon my-node                                                # my-nodeにスケーリングされないように設定します
+kubectl cordon my-node                                                # my-nodeをスケーリングされないように設定します
 kubectl drain my-node                                                 # メンテナンスの準備としてmy-nodeで動作中のPodを空にします
-kubectl uncordon my-node                                              # my-nodeにスケーリングされるように設定します
+kubectl uncordon my-node                                              # my-nodeをスケーリングされるように設定します
 kubectl top node my-node                                              # 特定のノードのメトリクスを表示します
 kubectl cluster-info                                                  # Kubernetesクラスターのマスターとサービスのアドレスを表示します
 kubectl cluster-info dump                                             # 現在のクラスター状態を標準出力にダンプします
@@ -329,7 +327,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
 
 ### リソースタイプ
 
-サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
+サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/ja/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。
 
 ```bash
 kubectl api-resources
@@ -352,7 +350,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
 
 出力フォーマット | 説明
 ---------------- | -----------
-`-o=custom-columns=<spec>` | カスタムカラムを使用してコンマ区切りのテーブルを表示します
+`-o=custom-columns=<spec>` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します
 `-o=custom-columns-file=<filename>` | `<filename>`ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します
 `-o=json`     | JSON形式のAPIオブジェクトを出力します
 `-o=jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
@@ -361,13 +359,27 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
 `-o=wide`     | 追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。
 `-o=yaml`     | YAML形式のAPIオブジェクトを出力します
 
+`-o=custom-columns`を使用したサンプル:
+
+```bash
+# クラスター内で実行中のすべてのイメージ名を表示する
+kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
+
+# "k8s.gcr.io/coredns:1.6.2"を除いたすべてのイメージ名を表示する
+kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
+
+# 名前に関係なくmetadata以下のすべてのフィールドを表示する
+kubectl get pods -A -o=custom-columns='DATA:metadata.*'
+```
+
+
 ### Kubectlのログレベルとデバッグ
 kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。
 
 ログレベル    | 説明
 --------------| -----------
 `--v=0`       | これは、クラスターオペレーターにログレベルが0であることを"常に"見えるようにするために役立ちます
-`--v=1`       | 冗長性が必要ない場合は、妥当なデフォルトのログレベルです
+`--v=1`       | ログレベルが必要ない場合に、妥当なデフォルトのログレベルです
 `--v=2`       | サービスに関する重要な定常状態情報と、システムの重要な変更に関連する可能性がある重要なログメッセージを表示します。 これは、ほとんどのシステムで推奨されるデフォルトのログレベルです。
 `--v=3`       | 変更に関するより詳細なログレベルを表示します
 `--v=4`       | デバックにむいたログレベルで表示します
@@ -381,12 +393,10 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
 ## {{% heading "whatsnext" %}}
 
 
-* kubectlについてより深く学びたい方は[kubectl概要](/docs/reference/kubectl/overview/)をご覧ください。
+* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)をご覧ください。
 
 * オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
 
 * また[kubectlの利用パターン](/docs/reference/kubectl/conventions/)では再利用可能なスクリプトでkubectlを利用する方法を学べます。
 
 * コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
-
-
diff --git a/content/ja/docs/reference/kubectl/overview.md b/content/ja/docs/reference/kubectl/overview.md
index dc018cd40c..71ce1844ec 100644
--- a/content/ja/docs/reference/kubectl/overview.md
+++ b/content/ja/docs/reference/kubectl/overview.md
@@ -8,9 +8,9 @@ card:
 ---
 
 <!-- overview -->
-`kubectl`は、Kubernetesクラスターを制御するためのコマンドラインツールです。`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
+`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
+この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。
 
-この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/kubectl/install/)をご覧ください。
 
 
 <!-- body -->
@@ -29,11 +29,11 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 * `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。
 
-      ```shell
-      kubectl get pod pod1
-      kubectl get pods pod1
-      kubectl get po pod1
-      ```
+   ```shell
+   kubectl get pod pod1
+   kubectl get pods pod1
+   kubectl get po pod1
+   ```
 
 * `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。
 
@@ -49,7 +49,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 
    * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。
 
-      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/docs/concepts/configuration/overview/#general-configuration-tips)。<br/>
+      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。<br/>
      例: `kubectl get pod -f ./pod.yaml`
 
 * `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。<br/>
@@ -64,42 +64,59 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。
 
-操作       | 構文    |       説明
+操作&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;       | 構文    |       説明
 -------------------- | -------------------- | --------------------
+`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。
 `annotate`    | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのアノテーションを、追加または更新します。
-`api-versions`    | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを表示します。
+`api-resources`    | `kubectl api-resources [flags]` | 利用可能なAPIリソースを一覧表示します。
+`api-versions`    | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを一覧表示します。
 `apply`            | `kubectl apply -f FILENAME [flags]`| ファイルまたは標準出力から、リソースの設定変更を適用します。
 `attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。
+`auth`    | `kubectl auth [flags] [options]` | 認可を検査します。
 `autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | ReplicationControllerで管理されているPodのセットを、自動的にスケールします。
+`certificate`    | `kubectl certificate SUBCOMMAND [options]` | 証明書のリソースを変更します。
 `cluster-info`    | `kubectl cluster-info [flags]` | クラスター内のマスターとサービスに関するエンドポイント情報を表示します。
+`completion`    | `kubectl completion SHELL [options]` | 指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。
 `config`        | `kubectl config SUBCOMMAND [flags]` | kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。
+`convert`    | `kubectl convert -f FILENAME [options]` | 異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。
+`cordon`    | `kubectl cordon NODE [options]` | Nodeをスケジュール不可に設定します。
+`cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | コンテナとの間でファイルやディレクトリをコピーします。
 `create`        | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。
 `delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。
 `describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 1つ以上のリソースの詳細な状態を表示します。
 `diff`        | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。
+`drain`    | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。
 `edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。
 `exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。
 `explain`    | `kubectl explain  [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。
 `expose`        | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。
 `get`        | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 1つ以上のリソースを表示します。
+`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。
 `label`        | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのラベルを、追加または更新します。
 `logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。
+`options`    | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。
 `patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。
-`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のリーカルポートを、Podに転送します。
+`plugin`    | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。
+`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。
 `proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
 `replace`        | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
-`rolling-update`    | <code>kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE &#124; -f NEW_CONTROLLER_SPEC) [flags]</code> | 指定されたReplicationControllerとそのPodを徐々に置き換えることで、ローリングアップデートを実行します。
-`run`        | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=server|client|none] [--overrides=inline-json] [flags]` | 指定したイメージを、クラスタ上で実行します。
-`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | していしたReplicationControllerのサイズを更新します。
+`rollout`    | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
+`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
+`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定したReplicationControllerのサイズを更新します。
+`set`    | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。
+`taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。
+`top`    | `kubectl top [flags] [options]` | リソース(CPU/メモリー/ストレージ)の使用量を表示します。
+`uncordon`    | `kubectl uncordon NODE [options]` | Nodeをスケジュール可に設定します。
 `version`        | `kubectl version [--client] [flags]` | クライアントとサーバーで実行中のKubernetesのバージョンを表示します。
+`wait`    | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。
 
-コマンド操作の詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。
+コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。
 
 ## リソースタイプ {#resource-types}
 
 以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。
 
-(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確です。)
+(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。)
 
 | リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
 |---|---|---|---|---|
@@ -155,7 +172,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 ## 出力オプション
 
-ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントをご覧ください。
+ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。
 
 ### 出力のフォーマット
 
@@ -188,13 +205,12 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
 kubectl get pod web-pod-13je7 -o yaml
 ```
 
-各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。
+各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。
 
 #### カスタムカラム {#custom-columns}
 
 カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、`custom-columns`オプションを使います。カスタムカラムをインラインで定義するか、`-o custom-columns=<spec>`または`-o custom-columns-file=<filename>`のようにテンプレートファイルを使用するかを選択できます。
 
-
 ##### 例
 
 インラインで定義する例は、以下の通りです。
@@ -215,10 +231,9 @@ kubectl get pods <pod-name> -o custom-columns-file=template.txt
 NAME          RSRC
 metadata.name metadata.resourceVersion
 ```
-
 どちらのコマンドを実行した場合でも、以下の結果を得ます。
 
-```shell
+```
 NAME           RSRC
 submit-queue   610995
 ```
@@ -229,22 +244,21 @@ submit-queue   610995
 つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。
 これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。
 
-この機能は、`kubectl`1.11以降ではデフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
+この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
 
 ##### 例
 
 Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。
 
-
 ```shell
 kubectl get pods <pod-name> --server-print=false
 ```
 
 以下のように出力されます。
 
-```shell
-NAME       READY     STATUS              RESTARTS   AGE
-pod-name   1/1       Running             0          1m
+```
+NAME       AGE
+pod-name   1m
 ```
 
 ### オブジェクトリストのソート
@@ -315,6 +329,7 @@ kubectl describe pods/<pod-name>
 
 # ReplicationController <rc-name>が管理しているすべてのPodの詳細を表示します。
 # ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。
+kubectl describe pods <rc-name>
 
 # すべてのPodの詳細を表示します。
 kubectl describe pods
@@ -330,8 +345,8 @@ kubectl describe pods
 # pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。
 kubectl delete -f pod.yaml
 
-# name=<label-name>というラベルを持つPodとServiceをすべて削除します。
-kubectl delete pods,services -l name=<label-name>
+# '<label-key>=<label-value>'というラベルを持つPodとServiceをすべて削除します。
+kubectl delete pods,services -l <label-key>=<label-value>
 
 # 初期化されていないPodを含む、すべてのPodを削除します。
 kubectl delete pods --all
@@ -341,14 +356,13 @@ kubectl delete pods --all
 
 ```shell
 # Pod <pod-name>から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。
-kubectl exec <pod-name> date
+kubectl exec <pod-name> -- date
 
 # Pod <pod-name>のコンテナ <container-name>から、'date'を実行している時の出力を取得します。
-kubectl exec <pod-name> -c <container-name> date
+kubectl exec <pod-name> -c <container-name> -- date
 
 # インタラクティブな TTY を取得し、Pod <pod-name>から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。
-Get an interactive TTY and run /bin/bash from pod <pod-name>. By default, output is from the first container.
-kubectl exec -ti <pod-name> /bin/bash
+kubectl exec -ti <pod-name> -- /bin/bash
 ```
 
 `kubectl logs` - Pod内のコンテナのログを表示します。
@@ -379,16 +393,20 @@ cat service.yaml | kubectl diff -f -
 # 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに
 # プレフィックス"kubectl-"で始まる名前を付けます。
 cat ./kubectl-hello
-#!/bin/bash
+```
+```shell
+#!/bin/sh
 
 # このプラグインは、"hello world"という単語を表示します。
 echo "hello world"
-
-# プラグインを書いたら、実行可能にします。
-sudo chmod +x ./kubectl-hello
+```
+プラグインを書いたら、実行可能にします。
+```bash
+chmod a+x ./kubectl-hello
 
 # さらに、PATH内の場所に移動させます。
 sudo mv ./kubectl-hello /usr/local/bin
+sudo chown root:root /usr/local/bin
 
 # これでkubectlプラグインを作成し、"インストール"できました。
 # 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。
@@ -399,14 +417,16 @@ hello world
 ```
 
 ```shell
-# 単純にPATHから削除することで、プラグインを"アンインストール"できます。
+# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。
 sudo rm /usr/local/bin/kubectl-hello
 ```
 
-`kubectl`で利用可能なプラグインをすべて表示するには、以下のように`kubectl plugin list`サブコマンドを使用します。
+`kubectl`で利用可能なプラグインをすべて表示するには、`kubectl plugin list`サブコマンドを使用してください。
+
 ```shell
 kubectl plugin list
 ```
+出力は以下のようになります。
 ```
 The following kubectl-compatible plugins are available:
 
@@ -414,9 +434,10 @@ The following kubectl-compatible plugins are available:
 /usr/local/bin/kubectl-foo
 /usr/local/bin/kubectl-bar
 ```
+
+`kubectl plugin list`コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。
 ```shell
-# このコマンドで、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。
-sudo chmod -x /usr/local/bin/kubectl-foo
+sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。
 kubectl plugin list
 ```
 ```
@@ -434,14 +455,19 @@ error: one plugin warning was found
 
 ```shell
 cat ./kubectl-whoami
+```
+次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。
+The next few examples assume that you already made `kubectl-whoami` have
+the following contents:
+```shell
 #!/bin/bash
 
 # このプラグインは、`kubectl config`コマンドを使って
 # 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。
-kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}'
+kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
 ```
 
-上記のプラグインを実行すると、以下のように、KUBECONFIGファイルの中で現在選択されているユーザーを含む出力が得られます。
+上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。
 
 ```shell
 # ファイルを実行可能にします。
@@ -454,10 +480,8 @@ kubectl whoami
 Current user: plugins-user
 ```
 
-プラグインについてより詳しく知りたい場合は、[example cli plugin](https://github.com/kubernetes/sample-cli-plugin)をご覧ください。
-
-
 ## {{% heading "whatsnext" %}}
 
-[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。
+* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。
 
+* プラグインについてより詳しく知りたい場合は, [example cli plugin](https://github.com/kubernetes/sample-cli-plugin)を御覧ください。
diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md
index 2d602e9300..6f7153f445 100644
--- a/content/ja/docs/setup/_index.md
+++ b/content/ja/docs/setup/_index.md
@@ -17,12 +17,11 @@ card:
 <!-- overview -->
 
 このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。
+Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。
 
-各Kubernetesソリューションはそれぞれ、メンテナンス性、セキュリティ、管理、利用可能なリソース、クラスターの運用に専門知識が必要など、異なる要件があります。
 
-Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションを選ぶことも可能です。
+Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。
 
-簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。
 
 
 
@@ -30,25 +29,14 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの
 
 ## 環境について学ぶ
 
-Kubernetesについて学んでいる場合、Dockerベースのソリューションを使いましょう。これらはKubernetesコミュニティにサポートされていたり、あるいはKubernetesクラスターをローカル環境にセットアップするエコシステムを持っていたりします。
+Kubernetesについて学んでいる場合、Kubernetesコミュニティにサポートされているツールや、Kubernetesクラスターをローカルマシンにセットアップするエコシステム内のツールを使いましょう。
 
-{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}}
-
-|コミュニティ           |エコシステム     |
-| ------------       | --------     |
-| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
-| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
-|                     | [Minishift](https://docs.okd.io/latest/minishift/)|
-|                     | [MicroK8s](https://microk8s.io/)|
-|                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
-|                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
-|                     | [k3s](https://k3s.io)|
 
 
 ## 本番環境
 
 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。
 
-[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。
+[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)を参照してください。
 
 
diff --git a/content/ja/docs/setup/best-practices/certificates.md b/content/ja/docs/setup/best-practices/certificates.md
index 7f67ee7006..7fbf4bf8b8 100644
--- a/content/ja/docs/setup/best-practices/certificates.md
+++ b/content/ja/docs/setup/best-practices/certificates.md
@@ -26,10 +26,10 @@ Kubernetesは下記の用途でPKIを必要とします：
 * APIサーバーがetcdと通信するためのクライアント証明書
 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig
 * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig
-* [front-proxy][proxy]用のクライアント証明書およびサーバー証明書
+* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用のクライアント証明書およびサーバー証明書
 
 {{< note >}}
-`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。
+`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/extend-kubernetes/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。
 {{< /note >}}
 
 さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。
@@ -52,7 +52,7 @@ kubeadmで証明書を生成したくない場合は、下記の方法のいず
 |------------------------|---------------------------|----------------------------------|
 | ca.crt,key             | kubernetes-ca             | Kubernetes全体の認証局　　　        |
 | etcd/ca.crt,key        | etcd-ca                   | etcd用　　　　　　　　　　　　　　   |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy]用　　　 |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用　　　 |
 
 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。
 
@@ -72,9 +72,9 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
 | kube-apiserver-kubelet-client | kubernetes-ca             | system:masters | client                                 |                                             |
 | front-proxy-client            | kubernetes-front-proxy-ca |                | client                                 |                                             |
 
-[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)
+[1]: クラスターに接続するIPおよびDNS名( [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)
 
-`kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます:
+`kind`は下記の[x509の鍵用途](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)のタイプにマッピングされます:
 
 | 種類   | 鍵の用途  　　　                                                                     |
 |--------|---------------------------------------------------------------------------------|
@@ -96,7 +96,8 @@ kubeadm利用者のみ：
 
 ### 証明書のパス
 
-証明書は推奨パスに配置するべきです([kubeadm][kubeadm]を使用する場合と同様)。パスは場所に関係なく与えられた引数で特定されます。
+証明書は推奨パスに配置するべきです([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様)。
+パスは場所に関係なく与えられた引数で特定されます。
 
 | デフォルトCN                   | 鍵の推奨パス        　　　　　　 | 証明書の推奨パス    　　　　　   | コマンド        | 鍵を指定する引数               | 証明書を指定する引数                          |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
@@ -157,8 +158,5 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 |
 | scheduler.conf          | kube-scheduler          | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。          |
 
-[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
-[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
 
 
diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md
index 438a692fbf..bc59b1b8ee 100644
--- a/content/ja/docs/setup/best-practices/cluster-large.md
+++ b/content/ja/docs/setup/best-practices/cluster-large.md
@@ -12,15 +12,12 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
 * No more than 300000 total containers
 * No more than 100 pods per node
 
-<br>
-
-{{< toc >}}
 
 ## 構築
 
 A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
 
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
 
 Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
 
@@ -80,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
 
 ### アドオンのリソース
 
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)).
 
 For example:
 
@@ -94,28 +91,26 @@ For example:
         memory: 200Mi
 ```
 
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
 
 To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
 
 * Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
-  * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+  * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
 * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
-  * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
 * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
-  * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+  * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
 
 Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
 and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
 out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
 
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+For directions on how to detect if addon containers are hitting resource limits, see the
+[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
 
 ### 少数のノードの起動の失敗を許容する
 
diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md
index 3590f6fa8c..29370c78b6 100644
--- a/content/ja/docs/setup/best-practices/multiple-zones.md
+++ b/content/ja/docs/setup/best-practices/multiple-zones.md
@@ -14,93 +14,50 @@ This page describes how to run a cluster in multiple zones.
 
 ## 始めに
 
-Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
-(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
-This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
-nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
-Full Cluster Federation allows combining separate
-Kubernetes clusters running in different regions or cloud providers
-(or on-premises data centers).  However, many
-users simply want to run a more available Kubernetes cluster in multiple zones
-of their single cloud provider, and this is what the multizone support in 1.2 allows
-(this previously went by the nickname "Ubernetes Lite").
+Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
+これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
+完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。
 
-Multizone support is deliberately limited: a single Kubernetes cluster can run
-in multiple zones, but only within the same region (and cloud provider).  Only
-GCE and AWS are currently supported automatically (though it is easy to
-add similar support for other clouds or even bare metal, by simply arranging
-for the appropriate labels to be added to nodes and volumes).
+マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。
 
 
 ## 機能性
 
-When nodes are started, the kubelet automatically adds labels to them with
-zone information.
+ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。
 
-Kubernetes will automatically spread the pods in a replication controller
-or service across nodes in a single-zone cluster (to reduce the impact of
-failures.)  With multiple-zone clusters, this spreading behavior is
-extended across zones (to reduce the impact of zone failures.)  (This is
-achieved via `SelectorSpreadPriority`).  This is a best-effort
-placement, and so if the zones in your cluster are heterogeneous
-(e.g. different numbers of nodes, different types of nodes, or
-different pod resource requirements), this might prevent perfectly
-even spreading of your pods across zones. If desired, you can use
-homogeneous zones (same number and types of nodes) to reduce the
-probability of unequal spreading.
+Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード，異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。
 
-When persistent volumes are created, the `PersistentVolumeLabel`
-admission controller automatically adds zone labels to them.  The scheduler (via the
-`VolumeZonePredicate` predicate) will then ensure that pods that claim a
-given volume are only placed into the same zone as that volume, as volumes
-cannot be attached across zones.
+永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。
 
 ## 制限
 
-There are some important limitations of the multizone support:
+マルチゾーンサポートにはいくつか重要な制限があります:
 
-* We assume that the different zones are located close to each other in the
-network, so we don't perform any zone-aware routing.  In particular, traffic
-that goes via services might cross zones (even if some pods backing that service
-exist in the same zone as the client), and this may incur additional latency and cost.
+* 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。
 
-* Volume zone-affinity will only work with a `PersistentVolume`, and will not
-work if you directly specify an EBS volume in the pod spec (for example).
+* Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。
 
-* Clusters cannot span clouds or regions (this functionality will require full
-federation support).
+* クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。
 
-* Although your nodes are in multiple zones, kube-up currently builds
-a single master node by default.  While services are highly
-available and can tolerate the loss of a zone, the control plane is
-located in a single zone.  Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに配置されます。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。
 
 ### ボリュームの制限
-The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
 
-* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
-  pod affinity or anti-affinity policies.
+以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。
 
-* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
-  may not provide a uniform distribution of storage across zones.
+* 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。
 
-* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
-  needs to be configured for a specific single zone, or the PVs need to be
-  statically provisioned in a specific zone. Another workaround is to use a
-  StatefulSet, which will ensure that all the volumes for a replica are
-  provisioned in the same zone.
+* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。
+
+* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の1つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。
 
 ## 全体の流れ
 
-We're now going to walk through setting up and using a multi-zone
-cluster on both GCE & AWS.  To do so, you bring up a full cluster
-(specifying `MULTIZONE=true`), and then you add nodes in additional zones
-by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
+GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`KUBE_USE_EXISTING_MASTER=true`と指定する)。
 
 ### クラスターの立ち上げ
 
-Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
+通常と同様にクラスターを作成します、しかし複数のゾーンを管理するためにMULTIZONEをクラスターに設定します。ノードをus-central1-aに作成します。
 
 GCE:
 
@@ -114,37 +71,33 @@ AWS:
 curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
 ```
 
-This step brings up a cluster as normal, still running in a single zone
-(but `MULTIZONE=true` has enabled multi-zone capabilities).
+このステップは通常と同様にクラスターを立ち上げ、1つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。
+
 
 ### ノードはラベルが付与される
 
-View the nodes; you can see that they are labeled with zone information.
-They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far.  The
-labels are `failure-domain.beta.kubernetes.io/region` for the region,
-and `failure-domain.beta.kubernetes.io/zone` for the zone:
+ノードを見てください。それらがゾーン情報と共にラベルされているのが分かります。
+それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`topology.kubernetes.io/region`がリージョンに、`topology.kubernetes.io/zone`はゾーンに付けられています:
+
 
 ```shell
 kubectl get nodes --show-labels
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
 ```
 
 ### 2つ目のゾーンにさらにノードを追加
 
-Let's add another set of nodes to the existing cluster, reusing the
-existing master, running in a different zone (us-central1-b or us-west-2b).
-We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
-kube-up will not create a new master, but will reuse one that was previously
-created instead.
+それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう1つのノードのセットを追加しましょう。
+kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。
 
 GCE:
 
@@ -152,37 +105,36 @@ GCE:
 KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
 ```
 
-On AWS we also need to specify the network CIDR for the additional
-subnet, along with the master internal IP address:
+
+AWSではマスターの内部IPアドレスに加えて追加のサブネット用のネットワークCIDRを指定する必要があります:
 
 ```shell
 KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
 ```
 
 
-View the nodes again; 3 more nodes should have launched and be tagged
-in us-central1-b:
+ノードをもう1度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです:
 
 ```shell
 kubectl get nodes --show-labels
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
-kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
+kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
+kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
 ```
 
 ### ボリュームのアフィニティ
 
-Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
+動的ボリュームを使用してボリュームを作成します(PersistentVolumeのみがゾーンアフィニティに対してサポートされています):
 
 ```bash
 kubectl apply -f - <<EOF
@@ -210,30 +162,28 @@ EOF
 ```
 
 {{< note >}}
-For version 1.3+ Kubernetes will distribute dynamic PV claims across
-the configured zones. For version 1.2, dynamic persistent volumes were
-always created in the zone of the cluster master
-(here us-central1-a / us-west-2a); that issue
+バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。
+バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。
+(ここではus-central1-a / us-west-2a); このイシューは
 ([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
-was addressed in 1.3+.
+にバージョン1.3以降で記載されています。
 {{< /note >}}
 
-Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
+それでは、KubernetesがPVが作成されたゾーン及びリージョンを自動的にラベルしているか確認しましょう。
 
 ```shell
 kubectl get pv --show-labels
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
 NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
-pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
+pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a
 ```
 
-So now we will create a pod that uses the persistent volume claim.
-Because GCE PDs / AWS EBS volumes cannot be attached across zones,
-this means that this pod can only be created in the same zone as the volume:
+では永続ボリュームクレームを使用するPodを作成します。
+GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します:
 
 ```yaml
 kubectl apply -f - <<EOF
@@ -255,8 +205,7 @@ spec:
 EOF
 ```
 
-Note that the pod was automatically created in the same zone as the volume, as
-cross-zone attachments are not generally permitted by cloud providers:
+一般的にゾーンを跨いだアタッチはクラウドプロバイダーによって許可されていないため、Podは自動的にボリュームと同じゾーンに作成されることに注意してください:
 
 ```shell
 kubectl describe pod mypod | grep Node
@@ -266,7 +215,7 @@ kubectl describe pod mypod | grep Node
 Node:        kubernetes-minion-9vlv/10.240.0.5
 ```
 
-And check node labels:
+ノードのラベルをチェックします:
 
 ```shell
 kubectl get node kubernetes-minion-9vlv --show-labels
@@ -274,13 +223,12 @@ kubectl get node kubernetes-minion-9vlv --show-labels
 
 ```shell
 NAME                     STATUS    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
 ```
 
 ### Podがゾーンをまたがって配置される
 
-Pods in a replication controller or service are automatically spread
-across zones.  First, let's launch more nodes in a third zone:
+レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、3つ目のゾーンに更なるノードを立ち上げましょう:
 
 GCE:
 
@@ -294,19 +242,19 @@ AWS:
 KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
 ```
 
-Verify that you now have nodes in 3 zones:
+3つのゾーンにノードがあることを確認します:
 
 ```shell
 kubectl get nodes --show-labels
 ```
 
-Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
+シンプルなWebアプリケーションを動作する、3つのRCを持つguestbook-goの例を作成します:
 
 ```shell
 find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
 ```
 
-The pods should be spread across all 3 zones:
+Podは3つの全てのゾーンにデプロイされているはずです:
 
 ```shell
 kubectl describe pod -l app=guestbook | grep Node
@@ -324,50 +272,49 @@ kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion
 
 ```shell
 NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
+kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
 ```
 
 
-Load-balancers span all zones in a cluster; the guestbook-go example
-includes an example load-balanced service:
+ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます:
 
 ```shell
 kubectl describe service guestbook | grep LoadBalancer.Ingress
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
 LoadBalancer Ingress:   130.211.126.21
 ```
 
-Set the above IP:
+IPの上に設定します:
 
 ```shell
 export IP=130.211.126.21
 ```
 
-Explore with curl via IP:
+IPをcurlを通じて探索します:
 
 ```shell
 curl -s http://${IP}:3000/env | grep HOSTNAME
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
   "HOSTNAME": "guestbook-44sep",
 ```
 
-Again, explore multiple times:
+再び、複数回探索します:
 
 ```shell
 (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
   "HOSTNAME": "guestbook-44sep",
@@ -375,11 +322,11 @@ The output is similar to this:
   "HOSTNAME": "guestbook-ppm40",
 ```
 
-The load balancer correctly targets all the pods, even though they are in multiple zones.
+ロードバランサーは、たとえPodが複数のゾーンに存在していても、全てのPodをターゲットします。
 
 ### クラスターの停止
 
-When you're done, clean up:
+終了したら、クリーンアップします:
 
 GCE:
 
@@ -397,4 +344,3 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k
 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
 ```
 
-
diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md
index 0db9cb4432..355dfdf366 100644
--- a/content/ja/docs/setup/best-practices/node-conformance.md
+++ b/content/ja/docs/setup/best-practices/node-conformance.md
@@ -3,7 +3,6 @@ title: ノードのセットアップの検証
 weight: 30
 ---
 
-{{< toc >}}
 
 ## ノード適合テスト
 
diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md
index 67b0002946..54a0411132 100644
--- a/content/ja/docs/setup/learning-environment/minikube.md
+++ b/content/ja/docs/setup/learning-environment/minikube.md
@@ -50,7 +50,8 @@ MinikubeのサポートするKubernetesの機能:
    特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。
 
 2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。
-単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。
+
+   単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。
 
    ```shell
    kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
@@ -69,6 +70,7 @@ MinikubeのサポートするKubernetesの機能:
    ```
 
    `--type=NodePort`オプションで、Serviceのタイプを指定します。
+
    出力はこのようになります:
 
    ```
@@ -78,6 +80,7 @@ MinikubeのサポートするKubernetesの機能:
 4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。
 
    Podが稼働しているか確認します:
+
    ```shell
    kubectl get pod
    ```
@@ -110,19 +113,19 @@ MinikubeのサポートするKubernetesの機能:
    Hostname: hello-minikube-7c77b68cff-8wdzq
    
    Pod Information:
-   	-no pod information available-
+    -no pod information available-
    
    Server values:
-   	server_version=nginx: 1.13.3 - lua: 10008
+    server_version=nginx: 1.13.3 - lua: 10008
    
    Request Information:
-   	client_address=172.17.0.1
-   	method=GET
-   	real path=/
-   	query=
-   	request_version=1.1
-   	request_scheme=http
-   	request_uri=http://192.168.99.100:8080/
+    client_address=172.17.0.1
+    method=GET
+    real path=/
+    query=
+    request_version=1.1
+    request_scheme=http
+    request_uri=http://192.168.99.100:8080/
    
    Request Headers:
    	accept=*/*
@@ -168,8 +171,8 @@ MinikubeのサポートするKubernetesの機能:
    出力はこのようになります:
 
    ```
-   Stopping local Kubernetes cluster...
    Stopping "minikube"...
+   "minikube" stopped.
    ```
 
    詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。
@@ -222,24 +225,27 @@ minikube start --kubernetes-version {{< param "fullversion" >}}
 
 #### VMドライバーの指定
 
-もしVMドライバーを変更したい場合は、`--vm-driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
+もしVMドライバーを変更したい場合は、`--driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
 
 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```
 
 Minikubeは以下のドライバーをサポートしています:
  {{< note >}}
-サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。
+サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/)を参照してください。
 {{< /note >}}
 
-* virtualbox  
+* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/))
+* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/))
+* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (実験的)
 * vmwarefusion
-* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
-* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/))
+* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/))
+* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/))
 注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。
 * vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver)
+* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/))
 * none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします)
 
 {{< caution >}}
@@ -372,7 +378,12 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し
 このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。
 
 ### minikubeのアップグレード {#upgrading-minikube}
-[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。
+macOSを使用し[Brew Package Manager](https://brew.sh/)がインストールされている場合、以下を実行します:
+
+```shell
+brew update
+brew upgrade minikube
+```
 
 ## クラスターに触れてみよう {#interacting-with-your-cluster}
 
@@ -383,9 +394,11 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し
 
 Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください:
 
-`kubectl config use-context minikube`,
+`kubectl config use-context minikube`
 
-もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube`
+もしくは各コマンドにコンテキストを次のように渡します:
+
+ `kubectl get pods --context=minikube`
 
 ### ダッシュボード
 
@@ -500,13 +513,13 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr
 
 ## 追加リンク集
 
-* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。
-* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。
-* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。
-* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。
-* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。
+* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)を参照してください。
+* **開発ガイド**: プルリクエストを送る方法の概要については、[コントリビュートする](https://minikube.sigs.k8s.io/docs/contrib/)を参照してください。
+* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://minikube.sigs.k8s.io/docs/contrib/building/)を参照してください。
+* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/drivers/)を参照してください。
+* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/addons/)を参照してください。
 * **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。
 
 ## コミュニティ
 
-コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
+コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md
index 667726bc64..372523091a 100644
--- a/content/ja/docs/setup/production-environment/container-runtimes.md
+++ b/content/ja/docs/setup/production-environment/container-runtimes.md
@@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ
 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、
 コンテナホストシステム上で任意のコマンドを実行する可能性があります。
 
-この問題の更なる情報は以下のリンクを参照してください。
-[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736)
+この問題の更なる情報は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。
 {{< /caution >}}
 
 ### 適用性
@@ -60,34 +59,44 @@ kubeletを再起動しても問題は解決しないでしょう。
 ## Docker
 
 それぞれのマシンに対してDockerをインストールします。
-バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
+バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。
 
 システムへDockerをインストールするには、次のコマンドを実行します。
 
 {{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
-# Docker CEのインストール
+{{% tab name="Ubuntu 16.04+" %}}
+
+```shell
+# (Install Docker CE)
 ## リポジトリをセットアップ
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 apt-get update && apt-get install -y \
   apt-transport-https ca-certificates curl software-properties-common gnupg2
+```
 
-### Docker公式のGPG鍵を追加
+```shell
+# Docker公式のGPG鍵を追加:
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+```
 
-### Dockerのaptリポジトリを追加
+```shell
+# Dockerのaptレポジトリを追加:
 add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
+```
 
-## Docker CEのインストール
+```shell
+# Docker CEのインストール
 apt-get update && apt-get install -y \
-  containerd.io=1.2.10-3 \
-  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
+containerd.io=1.2.13-2 \
+docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+```
 
+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -99,33 +108,47 @@ cat > /etc/docker/daemon.json <<EOF
   "storage-driver": "overlay2"
 }
 EOF
+```
 
+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```
 
+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
 
-# Docker CEのインストール
+```shell
+# (Docker CEのインストール)
 ## リポジトリをセットアップ
 ### 必要なパッケージのインストール
 yum install -y yum-utils device-mapper-persistent-data lvm2
+```
 
+```shell
 ### Dockerリポジトリの追加
 yum-config-manager --add-repo \
   https://download.docker.com/linux/centos/docker-ce.repo
+```
 
+```shell
 ## Docker CEのインストール
 yum update -y && yum install -y \
-  containerd.io-1.2.10 \
-  docker-ce-19.03.4 \
-  docker-ce-cli-19.03.4
+  containerd.io-1.2.13 \
+  docker-ce-19.03.11 \
+  docker-ce-cli-19.03.11
+```
 
+```shell
 ## /etc/docker ディレクトリを作成
 mkdir /etc/docker
+```
 
+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -140,15 +163,26 @@ cat > /etc/docker/daemon.json <<EOF
   ]
 }
 EOF
+```
 
+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```
 
+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}
 
+ブート時にDockerサービスを開始させたい場合は、以下のコマンドを入力してください:
+
+```shell
+sudo systemctl enable docker
+```
+
 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。
 
 ## CRI-O
@@ -179,54 +213,78 @@ sysctl --system
 ```
 
 {{< tabs name="tab-cri-cri-o-installation" >}}
-{{< tab name="Debian" codelang="bash" >}}
+{{% tab name="Debian" %}}
+
+```shell
 # Debian Unstable/Sid
 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
 wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
+```
 
+```shell
 # Debian Testing
 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
 wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
-
+```
+```shell
 # Debian 10
 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
 wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
+```
 
+```shell
 # Raspbian 10
 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
 wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
+```
 
-# CRI-Oのインストール
+それでは、CRI-Oをインストールします:
+```shell
 sudo apt-get install cri-o-1.17
-{{< /tab >}}
+```
+{{% /tab %}}
 
-{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}}
-# リポジトリの設定
+{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}
+
+```shell
+# パッケージレポジトリを設定する
 . /etc/os-release
 sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
 wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
 sudo apt-get update
+```
 
+```shell
 # CRI-Oのインストール
 sudo apt-get install cri-o-1.17
-{{< /tab >}}
+```
+{{% /tab %}}
 
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
+
+```shell
 # 必要なパッケージのインストール
-yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo
+```
 
+```shell
 # CRI-Oのインストール
-yum install --nogpgcheck -y cri-o
-{{< /tab >}}
+yum install -y cri-o
+```
+{{% /tab %}}
 
-{{< tab name="openSUSE Tumbleweed" codelang="bash" >}}
+{{% tab name="openSUSE Tumbleweed" %}}
+
+```shell
 sudo zypper install cri-o
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}
 
 ### CRI-Oの起動
 
-```
+```shell
 systemctl daemon-reload
 systemctl start crio
 ```
@@ -264,51 +322,75 @@ sysctl --system
 
 {{< tabs name="tab-cri-containerd-installation" >}}
 {{< tab name="Ubuntu 16.04" codelang="bash" >}}
-# containerdのインストール
+
+```shell
+# (containerdのインストール)
 ## リポジトリの設定
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+```
 
-### Docker公式のGPG鍵を追加
+```shell
+## Docker公式のGPG鍵を追加
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+```
 
-### Dockerのaptリポジトリの追加
+```
+## Dockerのaptリポジトリの追加
 add-apt-repository \
     "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
     $(lsb_release -cs) \
     stable"
+```
 
+```shell
 ## containerdのインストール
 apt-get update && apt-get install -y containerd.io
+```
 
+```shell
 # containerdの設定
 mkdir -p /etc/containerd
 containerd config default > /etc/containerd/config.toml
+```
 
+```shell
 # containerdの再起動
 systemctl restart containerd
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
-# containerdのインストール
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
+
+```shell
+# (containerdのインストール)
 ## リポジトリの設定
 ### 必要なパッケージのインストール
 yum install -y yum-utils device-mapper-persistent-data lvm2
+```
 
-### Dockerのリポジトリの追加
+```shell
+## Dockerのリポジトリの追加
 yum-config-manager \
     --add-repo \
     https://download.docker.com/linux/centos/docker-ce.repo
+```
 
+```shell
 ## containerdのインストール
 yum update -y && yum install -y containerd.io
+```
 
-# containerdの設定
+```shell
+## containerdの設定
 mkdir -p /etc/containerd
 containerd config default > /etc/containerd/config.toml
+```
 
+```shell
 # containerdの再起動
 systemctl restart containerd
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}
 
 ### systemd
diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index c0156a4e6f..9c096a6698 100644
--- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -63,7 +63,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。
 1. (推奨)シングルコントロールプレーンの`kubeadm`クラスターを高可用性クラスターにアップグレードする予定がある場合、`--control-plane-endpoint`を指定して、すべてのコントロールプレーンノードとエンドポイントを共有する必要があります。エンドポイントにはDNSネームやロードバランサーのIPアドレスが使用できます。
 1. Podネットワークアドオンを選んで、`kubeadm init`に引数を渡す必要があるかどうか確認してください。選んだサードパーティーのプロバイダーによっては、`--pod-network-cidr`をプロバイダー固有の値に設定する必要がある場合があります。詳しくは、[Podネットワークアドオンのインストール](#pod-network)を参照してください。
 1. (オプション)バージョン1.14から、`kubeadm`はよく知られたドメインソケットのパスリストを用いて、Linux上のコンテナランタイムの検出を試みます。異なるコンテナランタイムを使用する場合やプロビジョニングするノードに2つ以上のランタイムがインストールされている場合、`kubeadm init`に`--cri-socket`引数を指定してください。詳しくは、[ランタイムのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)を読んでください。
-1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertize-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
+1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertise-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
 1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。
 
 コントロールプレーンノードを初期化するには、次のコマンドを実行します。
diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index c821fca425..676f7f8a48 100644
--- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -539,7 +539,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ
 
     Kubernetes Podでは、インフラストラクチャまたは「pause」コンテナが最初に作成され、コンテナエンドポイントをホストします。インフラストラクチャやワーカーコンテナなど、同じPodに属するコンテナは、共通のネットワークネームスペースとエンドポイント（同じIPとポートスペース）を共有します。Pauseコンテナは、ネットワーク構成を失うことなくクラッシュまたは再起動するワーカーコンテナに対応するために必要です。
 
-    「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)をご覧ください。
+    「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)をご覧ください。
 
 ### さらなる調査
 
diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
index 6edce770c1..9f54861a94 100644
--- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
+++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-nodes.md
@@ -217,7 +217,7 @@ All code snippets in Windows sections are to be run in a PowerShell environment
     ```
 
     {{< note >}}
-    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using "docker pull mcr.microsoft.com/k8s/core/pause:1.2.0". The DOCKERFILE is available at https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat.
+    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using "docker pull mcr.microsoft.com/k8s/core/pause:1.2.0". The DOCKERFILE is available at https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile.
     {{< /note >}}
 
 1. Prepare a Windows directory for Kubernetes
diff --git a/content/ja/docs/tasks/_index.md b/content/ja/docs/tasks/_index.md
index 758500260b..b90950aea8 100644
--- a/content/ja/docs/tasks/_index.md
+++ b/content/ja/docs/tasks/_index.md
@@ -5,82 +5,8 @@ weight: 50
 content_type: concept
 ---
 
-{{< toc >}}
-
 <!-- overview -->
 
-Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。
-タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
-
-
-
-<!-- body -->
-
-## Web UI (ダッシュボード)
-
-ダッシュボードWeb UIを展開してアクセスし、Kubernetesクラスター内のコンテナ化されたアプリケーションの管理と監視に役立てます。
-
-## kubectlコマンドラインツールの使用
-
-Kubernetesクラスターを直接管理するために使用される`kubectl`コマンドラインツールをインストールしてセットアップします。
-
-## Podとコンテナの設定
-
-Podとコンテナの一般的な設定タスクを実行します。
-
-## アプリケーションの実行
-
-ローリングアップデート、Podへの情報の注入、水平Podオートスケーリングなど、一般的なアプリケーション管理タスクを実行します。
-
-## ジョブの実行
-
-並列処理を使用してジョブを実行します。
-
-## クラスター内のアプリケーションへのアクセス
-
-クラスター内のアプリケーションにアクセスするために、負荷分散、ポート転送を設定するか、ファイアウォールまたはDNSの設定をセットアップします。
-
-## 監視、ログ、デバッグ
-
-クラスタのトラブルシューティングまたはコンテナ化されたアプリケーションのデバッグのために、監視とログを設定します。
-
-## Kubernetes APIへのアクセス
-
-Kubernetes APIに直接アクセスするためのさまざまな方法を学びます。
-
-## TLSの使用
-
-クラスタールート認証局(CA)を信頼して使用するようにアプリケーションを設定します。
-
-## クラスターの管理
-
-クラスターを管理するための一般的なタスクを学びます。
-
-## フェデレーションの管理
-
-クラスタフェデレーションのコンポーネントを設定します。
-
-## ステートフルなアプリケーションの管理
-
-StatefulSetのスケーリング、削除、デバッグなど、ステートフルなアプリケーションを管理するための一般的なタスクを実行します。
-
-## クラスターデーモン
-
-ローリングアップデートの実行など、DaemonSetを管理するための一般的なタスクを実行します。
-
-## GPUの管理
-
-クラスター内のノードがリソースとして使用するNVIDIA GPUを設定およびスケジュールします。
-
-## Huge Pageの管理
-
-クラスター内のスケジュール可能なリソースとしてHuge Pageを構成およびスケジュールします。
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-タスクページを作成する場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。
-
+Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
 
+タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/contribute/new-content/open-a-pr/)を参照してください。
diff --git a/content/ja/docs/tasks/access-application-cluster/_index.md b/content/ja/docs/tasks/access-application-cluster/_index.md
index dda8899f73..dc48e62246 100755
--- a/content/ja/docs/tasks/access-application-cluster/_index.md
+++ b/content/ja/docs/tasks/access-application-cluster/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "クラスター内アプリケーションへのアクセス"
+description: クラスター内アプリケーションへアクセスできるようにするために、ロードバランシングやポートフォワーディングの設定、ファイアウォールやDNS設定のセットアップを行います。
 weight: 60
 ---
diff --git a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
index fa5cc9f976..8a0d37d28e 100644
--- a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+++ b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
@@ -100,12 +100,15 @@ nginxコンテナへのシェルを取得します:
 debianコンテナがnginxルートディレクトリに`index.html`ファイルを作成したことを思い出してください。
 `curl`を使用して、GETリクエストをnginxサーバーに送信します:
 
-    root@two-containers:/# curl localhost
+```
+root@two-containers:/# curl localhost
+```
 
 出力は、nginxがdebianコンテナによって書かれたWebページを提供することを示しています:
 
-    Hello from the debian container
-
+```
+Hello from the debian container
+```
 
 
 
diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index 2dc61d16a9..b2ebc16d18 100644
--- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -21,7 +21,9 @@ card:
 ## {{% heading "prerequisites" %}}
 
 
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}
+
+{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバーの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。
 
 
 
@@ -306,7 +308,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
 ```
 ### Windows Powershell
 ```shell
-$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config)
+$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME/.kube/config"
 ```
 
 `KUBECONFIG`環境変数内のファイルからまとめられた設定情報を確認してください。`config-exercise`ディレクトリ内から、以下のコマンドを実行してください:
@@ -319,11 +321,11 @@ kubectl config view
 
 `KUBECONFIG`環境変数を元に戻してください。例えば:
 
-Linux:
+### Linux:
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```
-Windows PowerShell
+### Windows PowerShell
 ```shell
 $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 ```
@@ -335,4 +337,3 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 
 * [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
-
diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index dbe76f3267..a1d167c441 100644
--- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -26,10 +26,10 @@ weight: 70
 ## {{% heading "prerequisites" %}}
 
 
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-* このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。
-  ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。
+このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。
+ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。
 
 
 
@@ -186,8 +186,19 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま
 {"message":"Hello"}
 ```
 
+## {{% heading "cleanup" %}}
 
+Serviceを削除するには、このコマンドを入力してください：
 
+```shell
+kubectl delete services frontend hello
+```
+
+バックエンドとフロントエンドアプリケーションを実行しているDeploymentとReplicaSetとPodを削除するために、このコマンドを入力してください：
+
+```shell
+kubectl delete deployment frontend hello
+```
 
 ## {{% heading "whatsnext" %}}
 
@@ -197,4 +208,3 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま
 
 
 
-
diff --git a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md
index 3d36d99539..b20a1d77d0 100644
--- a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md
+++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -25,13 +25,13 @@ weight: 100
 
 - `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します
 - `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。
-  - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。
+  - jsonpathの使い方については、[jsonpathリファレンス](/docs/reference/kubectl/jsonpath/)を参照してください。
 - `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。
   - `tr`を使用してスペースを改行に置換します。
   - `sort`を使用して結果を並べ替えます。
   - `uniq`を使用してイメージ数を集計します。
 
-```sh
+```shell
 kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
@@ -42,7 +42,7 @@ uniq -c
 
 別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます:
 
-```sh
+```shell
 kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
 ```
 
@@ -61,7 +61,7 @@ jsonpathは次のように解釈されます:
 
 `range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。
 
-```sh
+```shell
 kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
 sort
 ```
@@ -70,7 +70,7 @@ sort
 
 特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。
 
-```sh
+```shell
 kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
 ```
 
@@ -78,7 +78,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
 
 特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。
 
-```sh
+```shell
 kubectl get pods --namespace kube-system -o jsonpath="{..image}"
 ```
 
@@ -87,7 +87,7 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}"
 jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています:
 
 
-```sh
+```shell
 kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
 ```
 
@@ -104,7 +104,7 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r
 
 ### 参照
 
-* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド
+* [jsonpath](/docs/reference/kubectl/jsonpath/)参照ガイド
 * [Go template](https://golang.org/pkg/text/template/)参照ガイド
 
 
diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
index 1fe8e47e7b..d566f09566 100644
--- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -43,13 +43,7 @@ weight: 60
    ```shell
    kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
    ```
-    このコマンドは
-    [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
-    オブジェクトとそれに紐付く
-    [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
-    オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの
-    [Pod](/ja/docs/concepts/workloads/pods/pod/)
-    から構成されます。
+    このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。
 
 1. Deploymentの情報を表示します:
    ```shell
diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 8087e5602e..8235e113ae 100644
--- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -10,7 +10,13 @@ card:
 
 <!-- overview -->
 
-ダッシュボードは、WebベースのKubernetesユーザーインターフェイスです。ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。
+ダッシュボードは、WebベースのKubernetesユーザーインターフェイスです。
+ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、
+コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。
+ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、
+個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。
+たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、
+デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。
 
 ダッシュボードでは、クラスター内のKubernetesリソースの状態や、発生した可能性のあるエラーに関する情報も提供されます。
 
@@ -25,13 +31,16 @@ card:
 ダッシュボードUIはデフォルトではデプロイされていません。デプロイするには、以下のコマンドを実行します:
 
 ```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
 ```
 
 ## ダッシュボードUIへのアクセス
 
 
-クラスターデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。このデモ用のトークンを作成するには、[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。
+クラスターデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。
+現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。
+このデモ用のトークンを作成するには、
+[サンプルユーザーの作成](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md)ガイドに従ってください。
 
 {{< warning >}}
 チュートリアルで作成されたサンプルユーザーには管理者権限が与えられ、教育目的のみに使用されます。
@@ -54,13 +63,16 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
 
 ## ウェルカムビュー
 
-空のクラスターでダッシュボードにアクセスすると、ウェルカムページが表示されます。このページには、このドキュメントへのリンクと、最初のアプリケーションをデプロイするためのボタンが含まれています。さらに、クラスターの`kube-system`[名前空間](/docs/tasks/administer-cluster/namespaces/)でデフォルトで実行されているシステムアプリケーション、たとえばダッシュボード自体を見ることができます。
+空のクラスターでダッシュボードにアクセスすると、ウェルカムページが表示されます。
+このページには、このドキュメントへのリンクと、最初のアプリケーションをデプロイするためのボタンが含まれています。
+さらに、クラスターの`kube-system`[名前空間](/docs/tasks/administer-cluster/namespaces/)でデフォルトで実行されているシステムアプリケーション、たとえばダッシュボード自体を見ることができます。
 
 ![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)
 
 ## コンテナ化されたアプリケーションのデプロイ
 
-ダッシュボードを使用すると、簡単なウィザードでコンテナ化されたアプリケーションをDeploymentとオプションのServiceとして作成してデプロイすることができます。アプリケーションの詳細を手動で指定するか、アプリケーションの設定を含むYAMLまたはJSONファイルをアップロードすることができます。
+ダッシュボードを使用すると、簡単なウィザードでコンテナ化されたアプリケーションをDeploymentとオプションのServiceとして作成してデプロイすることができます。
+アプリケーションの詳細を手動で指定するか、アプリケーションの設定を含むYAMLまたはJSONファイルをアップロードすることができます。
 
 任意のページの右上にある**CREATE**ボタンをクリックして開始します。
 
@@ -68,27 +80,39 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
 
 デプロイウィザードでは、以下の情報を入力する必要があります:
 
-- **App name** (必須): アプリケーションの名前です。その名前の[label](/ja/docs/concepts/overview/working-with-objects/labels/)は、デプロイされるDeploymentとServiceに追加されます。
+- **App name** (必須): アプリケーションの名前です。
+  その名前の[label](/ja/docs/concepts/overview/working-with-objects/labels/)は、デプロイされるDeploymentとServiceに追加されます。
 
-  アプリケーション名は、選択したKubernetes[名前空間](/docs/tasks/administer-cluster/namespaces/)内で一意である必要があります。小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。
+  アプリケーション名は、選択したKubernetes[名前空間](/docs/tasks/administer-cluster/namespaces/)内で一意である必要があります。
+  小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。
 
-- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。コンテナイメージの指定はコロンで終わらせる必要があります。
-
-- **Number of pods** (必須): アプリケーションをデプロイするPodの数です。値は正の整数である必要があります。
+- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。
+  コンテナイメージの指定はコロンで終わらせる必要があります。
 
   クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
 
-- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。外部サービスの場合は、そのために1つ以上のポートを開放する必要があるでしょう。詳細は[こちら](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)を参照してください。
+- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、
+  [Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。
+  
+  {{< note >}}
+  外部サービスの場合は、そのために1つ以上のポートを開放する必要があるでしょう。
+  {{< /note >}}
 
   クラスター内部からしか見えないその他のサービスは、内部サービスと呼ばれます。
 
-  サービスの種類にかかわらず、サービスを作成し、コンテナがポート(受信)をリッスンする場合は、2つのポートを指定する必要があります。サービスは、ポート(受信)をコンテナから見たターゲットポートにマッピングして作成されます。このサービスは、デプロイされたPodにルーティングされます。サポートされるプロトコルはTCPとUDPです。このサービスの内部DNS名は、上記のアプリケーション名として指定した値になります。
+  サービスの種類にかかわらず、サービスを作成し、コンテナがポート(受信)をリッスンする場合は、
+  2つのポートを指定する必要があります。
+  サービスは、ポート(受信)をコンテナから見たターゲットポートにマッピングして作成されます。
+  このサービスは、デプロイされたPodにルーティングされます。サポートされるプロトコルはTCPとUDPです。
+  このサービスの内部DNS名は、上記のアプリケーション名として指定した値になります。
 
 必要に応じて、**高度なオプション**セクションを展開して、より多くの設定を指定することができます:
 
-- **Description**: ここで入力したテキストは、[アノテーション](/ja/docs/concepts/overview/working-with-with-objects/annotations/)としてDeploymentに追加され、アプリケーションの詳細に表示されます。
+- **Description**: ここで入力したテキストは、
+  [アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)としてDeploymentに追加され、アプリケーションの詳細に表示されます。
 
-- **Labels**: アプリケーションに使用するデフォルトの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)は、アプリケーション名とバージョンです。リリース、環境、ティア、パーティション、リリーストラックなど、Deployment、Service(存在する場合)、Podに適用する追加のラベルを指定できます。
+- **Labels**: アプリケーションに使用するデフォルトの[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)は、アプリケーション名とバージョンです。
+  リリース、環境、ティア、パーティション、リリーストラックなど、Deployment、Service(存在する場合)、Podに適用する追加のラベルを指定できます。
 
   例:
 
@@ -99,61 +123,93 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
    track=stable
    ```
 
-- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。これにより、リソースを論理的に名前のついたグループに分割することができます。
+- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。
+  これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。
+  これにより、リソースを論理的に名前のついたグループに分割することができます。
 
-  ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。名前空間名には、最大63文字の英数字とダッシュ(-)を含めることができますが、大文字を含めることはできません。
-  名前空間名は数字だけで構成されるべきではありません。名前が10などの数値として設定されている場合、Podはデフォルトの名前空間に配置されます。
+  ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。
+  名前空間名には、最大63文字の英数字とダッシュ(-)を含めることができますが、大文字を含めることはできません。
+  名前空間名は数字だけで構成されるべきではありません。
+  名前が10などの数値として設定されている場合、Podはデフォルトの名前空間に配置されます。
 
-  名前空間の作成に成功した場合は、デフォルトで選択されます。作成に失敗した場合は、最初の名前空間が選択されます。
+  名前空間の作成に成功した場合は、デフォルトで選択されます。
+  作成に失敗した場合は、最初の名前空間が選択されます。
 
-- **Image Pull Secret**: 指定されたDockerコンテナイメージが非公開の場合、[pull secret](/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。
+- **Image Pull Secret**:
+  指定されたDockerコンテナイメージが非公開の場合、
+  [pull secret](/ja/docs/concepts/configuration/secret/)の認証情報が必要になる場合があります。
 
-  ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。Secret名は最大253文字で構成されます。
+  ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。
+  Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。
+  Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。
+  Secret名は最大253文字で構成されます。
 
   イメージプルシークレットの作成に成功した場合は、デフォルトで選択されています。作成に失敗した場合は、シークレットは適用されません。
 
-- **CPU requirement (cores)**と**Memory requirement (MiB)**: コンテナの最小[リソース制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)を指定することができます。デフォルトでは、PodはCPUとメモリの制限がない状態で実行されます。
+- **CPU requirement (cores)**と**Memory requirement (MiB)**:
+  コンテナの最小[リソース制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)を指定することができます。デフォルトでは、PodはCPUとメモリの制限がない状態で実行されます。
 
-- **Run command**と**Run command arguments**: デフォルトでは、コンテナは指定されたDockerイメージのデフォルトの[entrypointコマンド](/docs/tasks/inject-data-application/define-command-argument-container/)を実行します。コマンドのオプションと引数を使ってデフォルトを上書きすることができます。
+- **Run command**と**Run command arguments**:
+  デフォルトでは、コンテナは指定されたDockerイメージのデフォルトの[entrypointコマンド](/docs/tasks/inject-data-application/define-command-argument-container/)を実行します。
+  コマンドのオプションと引数を使ってデフォルトを上書きすることができます。
 
-- **Run as privileged**: この設定は、[特権コンテナ](/ja/docs/concepts/workloads/pods/pod/#privileged-mode-for-pod-containers)内のプロセスが、ホスト上でrootとして実行されているプロセスと同等であるかどうかを決定します。特権コンテナは、ネットワークスタックの操作やデバイスへのアクセスなどの機能を利用できます。
+- **Run as privileged**: この設定は、[特権コンテナ](/ja/docs/concepts/workloads/pods/pod/#privileged-mode-for-pod-containers)内のプロセスが、ホスト上でrootとして実行されているプロセスと同等であるかどうかを決定します。特権コンテナは、
+  ネットワークスタックの操作やデバイスへのアクセスなどの機能を利用できます。
 
-- **Environment variables**: Kubernetesは[環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)を介してServiceを公開しています。環境変数を作成したり、環境変数の値を使ってコマンドに引数を渡したりすることができます。環境変数の値はServiceを見つけるためにアプリケーションで利用できます。値は`$(VAR_NAME)`構文を使用して他の変数を参照できます。
+- **Environment variables**: Kubernetesは[環境変数](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)を介してServiceを公開しています。
+  環境変数を作成したり、環境変数の値を使ってコマンドに引数を渡したりすることができます。
+  環境変数の値はServiceを見つけるためにアプリケーションで利用できます。
+  値は`$(VAR_NAME)`構文を使用して他の変数を参照できます。
 
 ### YAMLまたはJSONファイルのアップロード
 
-Kubernetesは宣言的な設定をサポートしています。このスタイルでは、すべての設定は Kubernetes [API](/ja/docs/concepts/overview/kubernetes-api/)リソーススキーマを使用してYAMLまたは JSON設定ファイルに格納されます。
+Kubernetesは宣言的な設定をサポートしています。
+このスタイルでは、すべての設定は Kubernetes [API](/ja/docs/concepts/overview/kubernetes-api/)リソーススキーマを使用してYAMLまたは JSON設定ファイルに格納されます。
 
-デプロイウィザードでアプリケーションの詳細を指定する代わりに、YAMLまたはJSONファイルでアプリケーションを定義し、ダッシュボードを使用してファイルをアップロードできます。
+デプロイウィザードでアプリケーションの詳細を指定する代わりに、
+YAMLまたはJSONファイルでアプリケーションを定義し、ダッシュボードを使用してファイルをアップロードできます。
 
 ## ダッシュボードの使用
 以下のセクションでは、Kubernetes Dashboard UIのビュー、それらが提供するものとその使用方法について説明します。
 
 ### ナビゲーション
 
-クラスターにKubernetesオブジェクトが定義されている場合、ダッシュボードではそれらのオブジェクトが初期表示されます。デフォルトでは_default_ 名前空間のオブジェクトのみが表示されますが、これはナビゲーションメニューにある名前空間セレクターで変更できます。
+クラスターにKubernetesオブジェクトが定義されている場合、ダッシュボードではそれらのオブジェクトが初期表示されます。
+デフォルトでは _default_ 名前空間のオブジェクトのみが表示されますが、これはナビゲーションメニューにある名前空間セレクターで変更できます。
 
 ダッシュボードにはほとんどのKubernetesオブジェクトの種類が表示され、いくつかのメニューカテゴリーにグループ化されています。
 
 #### 管理者の概要
-クラスターと名前空間の管理者向けに、ダッシュボードにはノード、名前空間、永続ボリュームが一覧表示され、それらの詳細ビューが用意されています。ノードリストビューには、すべてのノードにわたって集計されたCPUとメモリーのメトリクスが表示されます。詳細ビューには、ノードのメトリクス、仕様、ステータス、割り当てられたリソース、イベント、ノード上で実行されているPodが表示されます。
+クラスターと名前空間の管理者向けに、ダッシュボードにはノード、名前空間、永続ボリュームが一覧表示され、それらの詳細ビューが用意されています。
+ノードリストビューには、すべてのノードにわたって集計されたCPUとメモリーのメトリクスが表示されます。
+詳細ビューには、ノードのメトリクス、仕様、ステータス、割り当てられたリソース、イベント、ノード上で実行されているPodが表示されます。
 
 #### ワークロード
-選択した名前空間で実行されているすべてのアプリケーションを表示します。このビューでは、アプリケーションがワークロードの種類(例：Deployment、ReplicaSet、StatefulSetなど)ごとに一覧表示され、各ワークロードの種類を個別に表示することができます。リストには、ReplicaSetの準備ができたPodの数やPodの現在のメモリ使用量など、ワークロードに関する実用的な情報がまとめられています。
 
-ワークロードの詳細ビューには、ステータスや仕様情報、オブジェクト間の表面関係が表示されます。たとえば、ReplicaSetが制御しているPodや、新しいReplicaSet、DeploymentのためのHorizontal Pod Autoscalerなどです。
+選択した名前空間で実行されているすべてのアプリケーションを表示します。
+このビューでは、アプリケーションがワークロードの種類(例：Deployment、ReplicaSet、StatefulSetなど)ごとに一覧表示され、各ワークロードの種類を個別に表示することができます。
+リストには、ReplicaSetの準備ができたPodの数やPodの現在のメモリ使用量など、ワークロードに関する実用的な情報がまとめられています。
+
+ワークロードの詳細ビューには、ステータスや仕様情報、オブジェクト間の表面関係が表示されます。
+たとえば、ReplicaSetが制御しているPodや、新しいReplicaSet、DeploymentのためのHorizontal Pod Autoscalerなどです。
 
 #### Service
-外部の世界にサービスを公開し、クラスター内でサービスを発見できるようにするKubernetesリソースを表示します。そのため、ServiceとIngressのビューには、それらが対象とするPod、クラスター接続の内部エンドポイント、外部ユーザーの外部エンドポイントが表示されます。
+外部の世界にサービスを公開し、クラスター内でサービスを発見できるようにするKubernetesリソースを表示します。
+そのため、ServiceとIngressのビューには、それらが対象とするPod、クラスター接続の内部エンドポイント、外部ユーザーの外部エンドポイントが表示されます。
 
 #### ストレージ
+
 ストレージビューには、アプリケーションがデータを保存するために使用するPersistentVolumeClaimリソースが表示されます。
 
 #### ConfigMapとSecret
-クラスターで実行されているアプリケーションのライブ設定に使用されているすべてのKubernetesリソースを表示します。このビューでは、設定オブジェクトの編集と管理が可能で、デフォルトで非表示になっているSecretを表示します。
+
+クラスターで実行されているアプリケーションのライブ設定に使用されているすべてのKubernetesリソースを表示します。
+このビューでは、設定オブジェクトの編集と管理が可能で、デフォルトで非表示になっているSecretを表示します。
 
 #### ログビューアー
-Podのリストと詳細ページは、ダッシュボードに組み込まれたログビューアーにリンクしています。このビューアーでは、単一のPodに属するコンテナからログをドリルダウンすることができます。
+
+Podのリストと詳細ページは、ダッシュボードに組み込まれたログビューアーにリンクしています。
+このビューアーでは、単一のPodに属するコンテナからログをドリルダウンすることができます。
 
 ![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
 
@@ -161,4 +217,3 @@ Podのリストと詳細ページは、ダッシュボードに組み込まれ
 ## {{% heading "whatsnext" %}}
 
 詳細については[Kubernetes Dashboardプロジェクトページ](https://github.com/kubernetes/dashboard)をご覧ください。
-
diff --git a/content/ja/docs/tasks/administer-cluster/_index.md b/content/ja/docs/tasks/administer-cluster/_index.md
index 0f075ca038..b7a34be8db 100755
--- a/content/ja/docs/tasks/administer-cluster/_index.md
+++ b/content/ja/docs/tasks/administer-cluster/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "クラスターの管理"
+description: クラスターの管理のための一般的なタスクについて学びます。
 weight: 20
 ---
diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md
index 068832e852..a2c05085f1 100644
--- a/content/ja/docs/tasks/administer-cluster/coredns.md
+++ b/content/ja/docs/tasks/administer-cluster/coredns.md
@@ -50,6 +50,10 @@ Kubernetesバージョン1.11以降でCoreDNSを実行している場合、ア
 Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。
 {{< /note >}}
 
+{{< warning >}}
+Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンでは削除されます。
+{{< /warning >}}
+
 1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します:
 
 ```
@@ -76,4 +80,3 @@ CoreDNSだけをアップグレードしたい場合や、独自のカスタム
 [CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。
 
 
-
diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
index 5d1614ffa4..36e28ea455 100644
--- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
@@ -5,35 +5,29 @@ content_type: concept
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.11" state="beta" >}}
-今後のリリースで、クラウドコントローラーマネージャーはKubernetesを任意のクラウドと統合するための良い方法となります。これによりクラウドプロバイダーはKubernetesのコアリリースサイクルから独立して機能を開発できるようになります。
-
-{{< feature-state for_k8s_version="1.8" state="alpha" >}}
-
-独自のクラウドコントローラーマネージャーを構築する方法を説明する前に、クラウドコントローラーマネージャーがKubernetesの内部でどのように機能するかに関する背景を知っておくと役立ちます。
-クラウドコントローラーマネージャーはGoインターフェースを利用する`kube-controller-manager`のコードで、任意のクラウドの実装をプラグインとして利用できるようになっています。スキャフォールディングと汎用のコントローラー実装の大部分はKubernetesのコアになりますが、[クラウドプロバイダーのインターフェイス](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)が満たされていれば提供されているクラウドプロバイダーのインターフェイスが実行されるようになります。
-
-実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。
-
-
-
+{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}}
 
 <!-- body -->
 
+## 背景
+
+クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。
+
+Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。
+
 ## 開発
 
 ### Kubernetesには登録されていない独自クラウドプロバイダー
 
-Kubernetesには登録されていない独自のクラウドプロバイダーのクラウドコントローラーマネージャーを構築するには、次の3つのステップに従ってください。
+Kubernetesには登録されていない独自のクラウドプロバイダーのクラウドコントローラーマネージャーを構築するには、
 
 1. [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす go パッケージを実装します。
-2. Kubernetesのコアにある[cloud-controller-managerのmain.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)をあなたのmain.goのテンプレートとして利用します。上で述べたように、唯一の違いはインポートされるクラウドパッケージのみです。
-3. クラウドパッケージを `main.go` にインポートし、パッケージに [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go) を実行するための `init` ブロックがあることを確認します。
+2. Kubernetesのコアにある[cloud-controller-managerの`main.go`](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)をあなたの`main.go`のテンプレートとして利用します。上で述べたように、唯一の違いはインポートされるクラウドパッケージのみです。
+3. クラウドパッケージを `main.go` にインポートし、パッケージに [`cloudprovider.RegisterCloudProvider`](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go) を実行するための `init` ブロックがあることを確認します。
 
-既存の独自クラウドプロバイダーの実装例を利用すると役立つでしょう。独自クラウドプロバイダーの実装例のリストは[こちら](/docs/tasks/administer-cluster/running-cloud-controller.md#examples)にあります。
+多くのクラウドプロバイダーはオープンソースとしてコントローラーマネージャーのコードを公開しています。新たにcloud-controller-managerをスクラッチから開発する際には、既存のKubernetesには登録されていない独自クラウドプロバイダーのコントローラーマネージャーを開始地点とすることができます。
 
 ### Kubernetesに登録されているクラウドプロバイダー
 
-Kubernetesに登録されているクラウドプロバイダーであれば、[Daemonset](https://kubernetes.io/examples/admin/cloud/ccm-example.yaml) を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャードキュメント](/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。
-
+Kubernetesに登録されているクラウドプロバイダーであれば、{{< glossary_tooltip term_id="daemonset" >}}を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャー](/ja/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。
 
diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
index ddab0bb95d..0718205ded 100644
--- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
+++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
@@ -27,20 +27,16 @@ EndpointSliceは、KubernetesのEndpointsに対してスケーラブルで拡張
 EndpointSliceは、最終的には既存のEndpointsを置き換える可能性がありますが、多くのKubernetesコンポーネントはまだ既存のEndpointsに依存しています。現時点ではEndpointSliceを有効化することは、Endpointsの置き換えではなく、クラスター内のEndpointsへの追加とみなされる必要があります。
 {{< /note >}}
 
-EndpointSliceはベータ版の機能とみなされますが、デフォルトではAPIのみが有効です。kube-proxyによるEndpointSliceコントローラーとEndpointSliceの使用は、デフォルトでは有効になっていません。
+EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{<  glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointSliceではなくEndpointsを使用します。
 
-EndpointSliceコントローラーはクラスター内にEndpointSliceを作成し、管理します。これは、{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}と{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}の`EndpointSlice`の[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)で有効にできます(`--feature-gates=EndpointSlice=true`)。
-
-スケーラビリティ向上のため、{{<glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}でフィーチャーゲートを有効にして、Endpointsの代わりにEndpointSliceをデータソースとして使用することもできます。
+スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetes API間のトラフィックの量を削減します。
 
 ## EndpointSliceの使用
 
-クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含める必要があります。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。
+クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含みます。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。
 
 ## {{% heading "whatsnext" %}}
 
 
 * [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
-
-
diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
new file mode 100644
index 0000000000..62e610b277
--- /dev/null
+++ b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -0,0 +1,181 @@
+---
+title: Windowsノードの追加
+min-kubernetes-server-version: 1.17
+content_type: tutorial
+weight: 30
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+Kubernetesを使用してLinuxノードとWindowsノードを混在させて実行できるため、Linuxで実行するPodとWindowsで実行するPodを混在させることができます。このページでは、Windowsノードをクラスターに登録する方法を示します。
+
+
+
+
+## {{% heading "prerequisites" %}}
+ {{< version-check >}}
+
+* WindowsコンテナをホストするWindowsノードを構成するには、[Windows Server 2019ライセンス](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)(またはそれ以上)を取得します。
+VXLAN/オーバーレイネットワークを使用している場合は、[KB4489899](https://support.microsoft.com/help/4489899)もインストールされている必要があります。
+
+* コントロールプレーンにアクセスできるLinuxベースのKubernetes kubeadmクラスター([kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照)
+
+
+
+
+## {{% heading "objectives" %}}
+
+
+* Windowsノードをクラスターに登録する
+* LinuxとWindowsのPodとServiceが相互に通信できるようにネットワークを構成する
+
+
+
+
+<!-- lessoncontent -->
+
+## はじめに: クラスターへのWindowsノードの追加
+
+### ネットワーク構成
+
+LinuxベースのKubernetesコントロールプレーンノードを取得したら、ネットワーキングソリューションを選択できます。このガイドでは、簡単にするためにVXLANモードでのFlannelの使用について説明します。
+
+#### Flannel構成
+
+1. FlannelのためにKubernetesコントロールプレーンを準備する
+
+    クラスター内のKubernetesコントロールプレーンでは、多少の準備が推奨されます。Flannelを使用する場合は、iptablesチェーンへのブリッジIPv4トラフィックを有効にすることをお勧めします。すべてのLinuxノードで次のコマンドを実行する必要があります:
+
+    ```bash
+    sudo sysctl net.bridge.bridge-nf-call-iptables=1
+    ```
+
+1. Linux用のFlannelをダウンロードして構成する
+
+    最新のFlannelマニフェストをダウンロード:
+
+    ```bash
+    wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
+    ```
+
+    VNIを4096、ポートを4789に設定するために、flannelマニフェストの`net-conf.json`セクションを変更します。次のようになります:
+
+    ```json
+    net-conf.json: |
+        {
+          "Network": "10.244.0.0/16",
+          "Backend": {
+            "Type": "vxlan",
+            "VNI" : 4096,
+            "Port": 4789
+          }
+        }
+    ```
+
+    {{< note >}}Linux上のFlannelがWindows上のFlannelと相互運用するには、VNIを4096およびポート4789に設定する必要があります。これらのフィールドの説明については、[VXLANドキュメント](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)を参照してください。{{< /note >}}
+
+    {{< note >}}L2Bridge/Host-gatewayモードを使用するには、代わりに`Type`の値を`"host-gw"`に変更し、`VNI`と`Port`を省略します。{{< /note >}}
+
+1. Flannelマニフェストを適用して検証する
+
+    Flannelの構成を適用しましょう:
+
+    ```bash
+    kubectl apply -f kube-flannel.yml
+    ```
+
+    数分後、Flannel Podネットワークがデプロイされていれば、すべてのPodが実行されていることがわかります。
+
+    ```bash
+    kubectl get pods -n kube-system
+    ```
+
+    出力結果には、実行中のLinux flannel DaemonSetが含まれているはずです:
+
+    ```
+    NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE
+    ...
+    kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
+    ```
+
+1. Windows Flannelとkube-proxy DaemonSetを追加する
+
+    これで、Windows互換バージョンのFlannelおよびkube-proxyを追加できます。
+    互換性のあるバージョンのkube-proxyを確実に入手するには、イメージのタグを置換する必要があります。
+    次の例は、Kubernetes{{< param "fullversion" >}}の使用方法を示していますが、
+    独自のデプロイに合わせてバージョンを調整する必要があります。
+
+    ```bash
+    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
+    kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
+    ```
+    {{< note >}}
+    ホストゲートウェイを使用している場合は、代わりに https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml を使用してください。
+    {{< /note >}}
+
+    {{< note >}}
+Windowsノードでイーサネット(「Ethernet0 2」など)ではなく別のインターフェースを使用している場合は、次の行を変更する必要があります:
+
+```powershell
+wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
+```
+
+`flannel-host-gw.yml`または`flannel-overlay.yml`ファイルで、それに応じてインターフェースを指定します。
+
+```bash
+# 例
+curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
+```
+    {{< /note >}}
+    
+
+
+### Windowsワーカーノードの参加
+{{< note >}}
+`Containers`機能をインストールし、Dockerをインストールする必要があります。
+行うための指示としては、[Dockerエンジンのインストール - Windowsサーバー上のエンタープライズ](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)を利用できます。
+{{< /note >}}
+
+{{< note >}}
+Windowsセクションのすべてのコードスニペットは、
+Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実行されます。
+{{< /note >}}
+
+1. wins、kubelet、kubeadmをインストールします。
+
+   ```PowerShell
+   curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+   .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
+   ```
+
+1. `kubeadm`を実行してノードに参加します
+
+    コントロールプレーンホストで`kubeadm init`を実行したときに提供されたコマンドを使用します。
+    このコマンドがなくなった場合、またはトークンの有効期限が切れている場合は、`kubeadm token create --print-join-command`
+    (コントロールプレーンホスト上で)を実行して新しいトークンを生成します。
+
+
+#### インストールの確認
+次のコマンドを実行して、クラスター内のWindowsノードを表示できるようになります:
+
+```bash
+kubectl get nodes -o wide
+```
+
+新しいノードが`NotReady`状態の場合は、flannelイメージがまだダウンロード中の可能性があります。
+`kube-system`名前空間のflannel Podを確認することで、以前と同様に進行状況を確認できます:
+
+```shell
+kubectl -n kube-system get pods -l app=flannel
+```
+
+flannel Podが実行されると、ノードは`Ready`状態になり、ワークロードを処理できるようになります。
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+- [Windows kubeadmノードのアップグレード](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
new file mode 100644
index 0000000000..3c367aaa22
--- /dev/null
+++ b/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
@@ -0,0 +1,92 @@
+---
+title: Windowsノードのアップグレード
+min-kubernetes-server-version: 1.17
+content_type: task
+weight: 40
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+このページでは、[kubeadmで作られた](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。
+
+
+
+
+## {{% heading "prerequisites" %}}
+ 
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+* [残りのkubeadmクラスターをアップグレードするプロセス](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)を理解します。
+Windowsノードをアップグレードする前にコントロールプレーンノードをアップグレードしたいと思うかもしれません。
+
+
+
+
+<!-- steps -->
+
+## ワーカーノードをアップグレード
+
+### kubeadmをアップグレード
+
+1.  Windowsノードから、kubeadmをアップグレードします。:
+
+    ```powershell
+    # {{< param "fullversion" >}}を目的のバージョンに置き換えます
+    curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
+    ```
+
+### ノードをドレインする
+
+1.  Kubernetes APIにアクセスできるマシンから、
+    ノードをスケジュール不可としてマークして、ワークロードを削除することでノードのメンテナンスを準備します:
+
+    ```shell
+    # <node-to-drain>をドレインするノードの名前に置き換えます
+    kubectl drain <node-to-drain> --ignore-daemonsets
+    ```
+
+    このような出力結果が表示されるはずです:
+
+    ```
+    node/ip-172-31-85-18 cordoned
+    node/ip-172-31-85-18 drained
+    ```
+
+### kubeletの構成をアップグレード
+
+1. Windowsノードから、次のコマンドを呼び出して新しいkubelet構成を同期します:
+
+    ```powershell
+    kubeadm upgrade node
+    ```
+
+### kubeletをアップグレード
+
+1.  Windowsノードから、kubeletをアップグレードして再起動します:
+
+    ```powershell
+    stop-service kubelet
+    curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
+    restart-service kubelet
+    ```
+
+### ノードをオンライン状態に
+
+1.  Kubernetes APIにアクセスできるマシンから、
+スケジュール可能としてマークして、ノードをオンラインに戻します:
+
+    ```shell
+    # <node-to-drain>をノードの名前に置き換えます
+    kubectl uncordon <node-to-drain>
+    ```
+### kube-proxyをアップグレード
+
+1. Kubernetes APIにアクセスできるマシンから、次を実行します、
+もう一度{{< param "fullversion" >}}を目的のバージョンに置き換えます:
+
+    ```shell
+    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
+    ```
+
+
diff --git a/content/ja/docs/tasks/administer-cluster/nodelocaldns.md b/content/ja/docs/tasks/administer-cluster/nodelocaldns.md
new file mode 100644
index 0000000000..5b7b9e58e8
--- /dev/null
+++ b/content/ja/docs/tasks/administer-cluster/nodelocaldns.md
@@ -0,0 +1,87 @@
+---
+reviewers:
+title: KubernetesクラスターでNodeLocal DNSキャッシュを使用する
+content_type: task
+---
+ 
+<!-- overview -->
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+このページでは、KubernetesのNodeLocal DNSキャッシュの機能の概要について説明します。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+ {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+ <!-- steps -->
+
+## イントロダクション
+
+NodeLocal DNSキャッシュは、クラスターノード上でDNSキャッシュエージェントをDaemonSetで稼働させることで、クラスターのDNSパフォーマンスを向上させます。現在のアーキテクチャーにおいて、ClusterFirstのDNSモードでのPodは、DNSクエリー用にkube-dnsのService IPに疎通します。これにより、kube-proxyによって追加されたiptablesを介してkube-dns/CoreDNSのエンドポイントへ変換されます。この新しいアーキテクチャーによって、Podは同じノード上で稼働するDNSキャッシュエージェントに対して疎通し、それによってiptablesのDNATルールとコネクショントラッキングを回避します。ローカルのキャッシュエージェントはクラスターのホスト名(デフォルトではcluster.localというサフィックス)に対するキャッシュミスがあるときはkube-dnsサービスへ問い合わせます。
+
+
+## 動機
+
+* 現在のDNSアーキテクチャーでは、ローカルのkube-dns/CoreDNSがないとき、DNSへの秒間クエリー数が最も高いPodは他のノードへ疎通する可能性があります。ローカルでキャッシュを持つことにより、この状況におけるレイテンシーの改善に役立ちます。
+
+* iptables DNATとコネクショントラッキングをスキップすることは[conntrackの競合](https://github.com/kubernetes/kubernetes/issues/56903)を減らし、UDPでのDNSエントリーがconntrackテーブルを満杯にすることを避けるのに役立ちます。
+
+* ローカルのキャッシュエージェントからkube-dnsサービスへの接続がTCPにアップグレードされます。タイムアウトをしなくてはならないUDPエントリーと比べ、TCPのconntrackエントリーはコネクションクローズ時に削除されます([デフォルトの](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt) `nf_conntrack_udp_timeout` は30秒です)。
+
+* DNSクエリーをUDPからTCPにアップグレードすることで、UDPパケットの欠損や、通常30秒(10秒のタイムアウトで3回再試行する)であるDNSのタイムアウトによるテイルレイテンシーを減少させます。NodeLocalキャッシュはUDPのDNSクエリーを待ち受けるため、アプリケーションを変更する必要はありません。
+
+* DNSクエリーに対するノードレベルのメトリクスと可視性を得られます。
+
+* DNSの不在応答のキャッシュも再度有効にされ、それによりkube-dnsサービスに対するクエリー数を減らします。
+
+## アーキテクチャー図
+
+この図はNodeLocal DNSキャッシュが有効にされた後にDNSクエリーがあったときの流れとなります。
+
+
+{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCacheのフロー" caption="この図は、NodeLocal DNSキャッシュがDNSクエリーをどう扱うかを表したものです。" >}}
+
+## 設定
+{{< note >}} NodeLocal DNSキャッシュ用のローカルに待ち受けているIPアドレスは、169.254.20.0/16の範囲のIPか、既存のIPと衝突しないことが保証されている他のIPとなります。このドキュメントでは例として169.254.10を使用します。
+{{< /note >}}
+
+この機能は、下記の手順により有効化できます。
+
+* [`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml)と同様のマニフェストを用意し、`nodelocaldns.yaml`という名前で保存してください。
+* マニフェスト内の変数を正しい値に置き換えてください。
+
+     * kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
+
+     * domain=`<cluster-domain>`
+
+     * localdns=`<node-local-address>`
+
+     `<cluster-domain>`はデフォルトで"cluster.local"です。`<node-local-address>` はNodeLocal DNSキャッシュ用に確保されたローカルの待ち受けIPアドレスです。
+
+   * kube-proxyがIPTABLESモードで稼働中のとき:
+
+     ``` bash
+     sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
+     ```
+
+     `__PILLAR__CLUSTER__DNS__`と`__PILLAR__UPSTREAM__SERVERS__`はnode-local-dnsというPodによって生成されます。
+     このモードでは、node-local-dns Podは`<node-local-address>`とkube-dnsのサービスIPの両方で待ち受けるため、PodはIPアドレスでもDNSレコードのルップアップができます。
+
+  * kube-proxyがIPVSモードで稼働中のとき:
+
+    ``` bash
+     sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
+    ```
+     このモードでは、node-local-dns Podは`<node-local-address>`上のみで待ち受けます。node-local-dnsのインターフェースはkube-dnsのクラスターIPをバインドしません。なぜならばIPVSロードバランシング用に使われているインターフェースは既にこのアドレスを使用しているためです。
+     `__PILLAR__UPSTREAM__SERVERS__` はnode-local-dns Podにより生成されます。
+
+* `kubectl create -f nodelocaldns.yaml`を実行してください。
+* kube-proxyをIPVSモードで使用しているとき、NodeLocal DNSキャッシュが待ち受けている`<node-local-address>`を使用するため、kubeletに対する`--cluster-dns`フラグを修正する必要があります。IPVSモード以外のとき、`--cluster-dns`フラグの値を修正する必要はありません。なぜならNodeLocal DNSキャッシュはkube-dnsのサービスIPと`<node-local-address>`の両方で待ち受けているためです。
+
+一度有効にすると、クラスターの各Node上で、kube-systemという名前空間でnode-local-dns Podが、稼働します。このPodは[CoreDNS](https://github.com/coredns/coredns)をキャッシュモードで稼働させるため、異なるプラグインによって公開された全てのCoreDNSのメトリクスがNode単位で利用可能となります。
+
+`kubectl delete -f <manifest>`を実行してDaemonSetを削除することによって、この機能を無効にできます。また、kubeletの設定に対して行った全ての変更をリバートすべきです。
+ 
diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
index 9a06821517..04dfd62f8b 100644
--- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -1,15 +1,15 @@
 ---
-title: Kubernetesクラウドコントローラーマネージャー
+title: クラウドコントローラーマネージャーの運用管理
 content_type: concept
 ---
 
 <!-- overview -->
 
-{{< feature-state state="beta" >}}
+{{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
-Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`cloud-controller-manager`バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。
+クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを{{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}}バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。
 
-`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。
+`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。
 
 
 
@@ -38,7 +38,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に
 * `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。
 * クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。
 
-v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。
+クラウドコントローラーマネージャーは以下を実装できます。
 
 * ノードコントローラー - クラウドAPIを使用してkubernetesノードを更新し、クラウドで削除されたkubernetesノードを削除します。
 * サービスコントローラー - タイプLoadBalancerのサービスに対応してクラウド上のロードバランサーを操作します。
@@ -52,12 +52,6 @@ v1.8の時点でクラウドコントローラーマネージャーは以下を
 
 Kubernetesのコアリポジトリにないクラウドコントローラーマネージャーの場合、クラウドベンダーまたはsigリードが管理するリポジトリでプロジェクトを見つけることができます。
 
-* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
-* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
-* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
-
-
 すでにKubernetesのコアリポジトリにあるプロバイダーの場合、クラスター内でデーモンセットとしてKubernetesリポジトリ内部のクラウドコントローラーマネージャーを実行できます。以下をガイドラインとして使用してください。
 
 {{< codenew file="admin/cloud/ccm-example.yaml" >}}
@@ -73,18 +67,16 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ
 
 ### スケーラビリティ
 
-クラウドプロバイダーの以前のアーキテクチャではローカルメタデータサービスを使用して自身のノード情報を取得するkubeletに依存していました。新しいアーキテクチャではクラウドコントローラーマネージャーがすべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。
+cloud-controller-managerは、クラウドプロバイダーのAPIにクエリーを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。
 
 ### 鶏と卵
 
 クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。
 
-これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。
+これの良い例は、KubeletのTLSブートストラップ機能です。TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。
 
 このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。
 
-## 独自のクラウドコントローラマネージャーを開発する
-
-独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)のドキュメントを参照してください。
-
+## {{% heading "whatsnext" %}}
 
+独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)を参照してください。
diff --git a/content/ja/docs/tasks/configure-pod-container/_index.md b/content/ja/docs/tasks/configure-pod-container/_index.md
index 94b5079fa8..324a19b22b 100755
--- a/content/ja/docs/tasks/configure-pod-container/_index.md
+++ b/content/ja/docs/tasks/configure-pod-container/_index.md
@@ -1,5 +1,6 @@
 ---
 title: "Podとコンテナの設定"
+description: Podとコンテナの一般的な設定のタスクを行います。
 weight: 20
 ---
 
diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 8091ded576..1be44e3a75 100644
--- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -16,7 +16,7 @@ weight: 20
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-クラスターの各ノードには、少なくとも1つ以上のCPUが必要になります。
+タスク例を実行するには、クラスターに少なくとも利用可能な1 CPUが必要です。
 
 このページのいくつかの手順では、クラスターにて[metrics-server](https://github.com/kubernetes-incubator/metrics-server)サービスを実行する必要があります。すでにmetrics-serverが動作している場合、これらの手順をスキップできます。
 
@@ -106,7 +106,7 @@ cpu-demo                    974m         <something>
 `-cpu "2"`を設定することで、コンテナが2 CPU利用しようとすることを思い出してください。しかしながら、コンテナは約1 CPUしか使用することができません。コンテナが制限よりも多くのCPUリソースを利用しようとしているため、コンテナのCPUの利用が抑制されています。
 
 {{< note >}}
-CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、各ノードに少なくとも1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。
+CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、クラスターに少なくとも利用可能な1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。
 {{< /note >}}
 
 ## CPUの単位
@@ -152,9 +152,6 @@ kubectl get pod cpu-demo-2 --namespace=cpu-example
 
 この出力では、Podのステータスが待機中であることを示しています。つまり、Podがどのノードに対しても実行するようスケジュールされておらず、いつまでも待機状態のままであることを表しています:
 
-```shell
-kubectl get pod cpu-demo-2 --namespace=cpu-example
-```
 ```
 NAME         READY     STATUS    RESTARTS   AGE
 cpu-demo-2   0/1       Pending   0          7m
@@ -222,17 +219,17 @@ kubectl delete namespace cpu-example
 
 ### クラスター管理者向け
 
-* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/)
+* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
 
-* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/)
+* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
 
-* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/)
+* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
 
-* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
+* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
 
-* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
+* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
 
-* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/)
+* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
 
 * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
 
diff --git a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
index 1af80012fc..944ce4b715 100644
--- a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
+++ b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -302,17 +302,17 @@ kubectl delete namespace mem-example
 
 ### クラスター管理者向け
 
-* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/)
+* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
 
-* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/)
+* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
 
-* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/)
+* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
 
-* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
+* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
 
-* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
+* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
 
-* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/)
+* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
 
 * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
 
diff --git a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index 1c875edc1f..1aa194a745 100644
--- a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -63,7 +63,7 @@ Pod内で実行されているコンテナでシェルを実行します:
 ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。
 
 Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。
-コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)を参照してください。
+コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
 
 {{< note >}}
 Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。
diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index bd5ec92082..68929ec5bb 100644
--- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -8,7 +8,7 @@ weight: 110
 
 このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。
 
-[kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。
 例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。
 このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。
 
@@ -296,7 +296,7 @@ Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制
 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。
 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。
 デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。
-* `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。
+* `failureThreshold`: Probeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。
 Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。
 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。
 
diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md
index 4666e6c7f2..7bcacd13a4 100644
--- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md
+++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md
@@ -577,6 +577,10 @@ SPECIAL_TYPE
 `/etc/config/`ディレクトリに何かファイルがある場合、それらは削除されます。
 {{< /caution >}}
 
+{{< note >}}
+テキストデータはUTF-8文字エンコーディングを使用しているファイルとして公開されます。他の文字エンコーディングを使用する場合は、バイナリデータを使用してください。
+{{< /note >}}
+
 ### ConfigMapデータをボリュームの特定のパスに追加する
 
 `path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。
@@ -665,5 +669,5 @@ data:
 
 
 ## {{% heading "whatsnext" %}}
-* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。
+* 実践例[ConfigMapを使ったRedisの設定](/ja/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。
 
diff --git a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
index 010af1dc64..012921d2bf 100644
--- a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -241,17 +241,17 @@ kubectl delete namespace qos-example
 
 ### クラスター管理者向け
 
-* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/)
+* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
 
-* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/)
+* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
 
-* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/)
+* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
 
-* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
+* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
 
-* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
+* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
 
-* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/)
+* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
 
 * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/)
 
diff --git a/content/ja/docs/tasks/debug-application-cluster/_index.md b/content/ja/docs/tasks/debug-application-cluster/_index.md
index cbf41f43ff..bc8639bb94 100755
--- a/content/ja/docs/tasks/debug-application-cluster/_index.md
+++ b/content/ja/docs/tasks/debug-application-cluster/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "監視、ログ、デバッグ"
+description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とログをセットアップします。
 weight: 80
 ---
diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index fc17886ebe..570134b84d 100644
--- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -47,9 +47,9 @@ Podをスケジュールできない理由に関するスケジューラーか
 クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。
 この場合、いくつかのことを試すことができます。
 
-* クラスターに[ノードを追加します](/docs/admin/cluster-management/#resizing-a-cluster)。
+* クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。
 
-* [不要なPodを終了](/docs/user-guide/pods/single-container/#deleting_a_pod)して、
+* [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、
   `Pending`状態のPodのための空きリソースを作ります。
 
 * Podがノードよりも大きくないことを確認します。
@@ -86,37 +86,7 @@ Podが`Waiting`状態となる最も一般的な原因は、イメージをプ
 
 ### Podがクラッシュする、あるいはUnhealthy状態
 
-最初に、現在のコンテナのログを確認して下さい。
-
-```shell
-kubectl logs ${POD_NAME} ${CONTAINER_NAME}
-```
-
-以前にコンテナがクラッシュした場合、次のコマンドで以前のコンテナのクラッシュログにアクセスできます。
-
-```shell
-kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
-```
-
-別の方法として、`exec`を使用してそのコンテナ内でコマンドを実行できます。
-
-```shell
-kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
-```
-
-{{< note >}}
-`-c ${CONTAINER_NAME}`はオプションです。単一のコンテナのみを含むPodの場合は省略できます。
-{{< /note >}}
-
-例えば、実行中のCassandra Podのログを確認するには、次のコマンドを実行します。
-
-```shell
-kubectl exec cassandra -- cat /var/log/cassandra/system.log
-```
-
-クラスターで有効にしていれば、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) を既存のPodに追加することもできます。 新しい一時的なコンテナを利用して、たとえばPod内の問題の診断のために任意のコマンドを実行することができます。利用できる機能を含む詳細については、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) のページを参照してください。
-
-これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。
+Podがスケジュールされると、[動作中のPodをデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。
 
 ## ReplicationControllerのデバッグ
 
diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md
index a8332cbcfb..5daefb2f59 100644
--- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md
@@ -34,9 +34,9 @@ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
 
 このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
 
+
 ```shell
-kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
-                      --replicas=3
+kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname
 ```
 ```none
 deployment.apps/hostnames created
@@ -45,6 +45,15 @@ deployment.apps/hostnames created
 
 `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。
 
+Deploymentを3つのレプリカにスケールさせてみましょう。
+
+```shell
+kubectl scale deployment hostnames --replicas=3
+```
+```none
+deployment.apps/hostnames scaled
+```
+
 これは、次のYAMLでDeploymentを開始した場合と同じです。
 
 ```yaml
@@ -52,27 +61,29 @@ apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: hostnames
+  labels:
+    app: hostnames
 spec:
   selector:
     matchLabels:
-      run: hostnames
+      app: hostnames
   replicas: 3
   template:
     metadata:
       labels:
-        run: hostnames
+        app: hostnames
     spec:
       containers:
       - name: hostnames
         image: k8s.gcr.io/serve_hostname
 ```
 
-"run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。
+"app"ラベルは`kubectl create deployment`によって、Deploymentの名前に自動的にセットされます。
 
 Podが実行されていることを確認できます。
 
 ```shell
-kubectl get pods -l run=hostnames
+kubectl get pods -l app=hostnames
 ```
 ```none
 NAME                        READY     STATUS    RESTARTS   AGE
@@ -84,7 +95,7 @@ hostnames-632524106-tlaok   1/1       Running   0          2m
 Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。
 
 ```shell
-kubectl get pods -l run=hostnames \
+kubectl get pods -l app=hostnames \
     -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
 ```
 ```none
@@ -106,9 +117,9 @@ done
 次のように表示されます。
 
 ```
-hostnames-0uton
-hostnames-bvc05
-hostnames-yp2kp
+hostnames-632524106-bbpiw
+hostnames-632524106-ly40y
+hostnames-632524106-tlaok
 ```
 
 この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。
@@ -312,7 +323,7 @@ kubectl get service hostnames -o json
         "resourceVersion": "347189",
         "creationTimestamp": "2015-07-07T15:24:29Z",
         "labels": {
-            "run": "hostnames"
+            "app": "hostnames"
         }
     },
     "spec": {
@@ -326,7 +337,7 @@ kubectl get service hostnames -o json
             }
         ],
         "selector": {
-            "run": "hostnames"
+            "app": "hostnames"
         },
         "clusterIP": "10.0.1.175",
         "type": "ClusterIP",
@@ -351,15 +362,15 @@ kubectl get service hostnames -o json
 以前に、Podが実行されていることを確認しました。再確認しましょう。
 
 ```shell
-kubectl get pods -l run=hostnames
+kubectl get pods -l app=hostnames
 ```
 ```none
 NAME              READY     STATUS    RESTARTS   AGE
-hostnames-0uton   1/1       Running   0          1h
-hostnames-bvc05   1/1       Running   0          1h
-hostnames-yp2kp   1/1       Running   0          1h
+hostnames-632524106-bbpiw   1/1       Running   0          1h
+hostnames-632524106-ly40y   1/1       Running   0          1h
+hostnames-632524106-tlaok   1/1       Running   0          1h
 ```
-`-l run=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
+`-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
 
 "AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
 
@@ -374,7 +385,7 @@ NAME        ENDPOINTS
 hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
 ```
 
-これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
+これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスやその他のエラー、たとえばDeployment作成にも`kubectl run`が使われた1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
 
 ## Podは機能しているか？
 
@@ -395,9 +406,9 @@ done
 次のように表示されます。
 
 ```
-hostnames-0uton
-hostnames-bvc05
-hostnames-yp2kp
+hostnames-632524106-bbpiw
+hostnames-632524106-ly40y
+hostnames-632524106-tlaok
  ```
 
 Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
@@ -510,7 +521,7 @@ iptables-save | grep hostnames
 curl 10.0.1.175:80
 ```
 ```none
-hostnames-0uton
+hostnames-632524106-bbpiw
 ```
 
 もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
@@ -521,7 +532,7 @@ hostnames-0uton
 curl localhost:48577
 ```
 ```none
-hostnames-yp2kp
+hostnames-632524106-tlaok
 ```
 
 もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。
@@ -534,7 +545,7 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
 
 ### エッジケース: PodがService IP経由で自身に到達できない {#a-pod-fails-to-reach-itself-via-the-service-ip}
 
-これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
+これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/reference/command-line-tools-reference/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。
 
 この問題をトラブルシューティングする一般的な手順は次のとおりです。
 
@@ -580,13 +591,11 @@ UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
 
 ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
 
-[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
+[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。
 
 
 
 ## {{% heading "whatsnext" %}}
 
 
-詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。
-
-
+詳細については、[トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)をご覧ください。
diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
index 2f42f38cc2..7c8e6eeec8 100644
--- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
@@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP
 kubectl get pods -l app=myapp
 ```
 
-Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/manage-stateful-set/delete-pods/)タスクを参照してください。
+Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。
 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。
 
 
@@ -39,4 +39,3 @@ Podが長期間`Unknown`または`Terminating`の状態になっていること
 
 
 
-
diff --git a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
index 7ec722caa6..fdddb859ce 100644
--- a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+++ b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
@@ -67,6 +67,8 @@ content_type: task
 
 Kubernetesは、コンテナの`terminationMessagePath`フィールドで指定されている終了メッセージファイルから終了メッセージを取得します。デフォルト値は`/dev/termination-log`です。このフィールドをカスタマイズすることで、Kubernetesに別のファイルを使うように指示できます。Kubernetesは指定されたファイルの内容を使用して、成功と失敗の両方についてコンテナのステータスメッセージを入力します。
 
+終了メッセージはアサーションエラーメッセージのように、最終状態を簡潔に示します。kubeletは4096バイトより長いメッセージは切り詰めます。全コンテナの合計メッセージの長さの上限は12キビバイトです。デフォルトの終了メッセージのパスは`/dev/termination-log`です。Pod起動後に終了メッセージのパスを設定することはできません。
+
 次の例では、コンテナはKubernetesが取得するために終了メッセージを`/tmp/my-log`に書き込みます:
 
 ```yaml
diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
index 684fa981c1..bada044869 100644
--- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
+++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md
@@ -43,7 +43,7 @@ kubectl get pod shell-demo
 実行中のコンテナへのシェルを取得します:
 
 ```shell
-kubectl exec -it shell-demo -- /bin/bash
+kubectl exec --stdin --tty shell-demo -- /bin/bash
 ```
 {{< note >}}
 
@@ -54,23 +54,25 @@ kubectl exec -it shell-demo -- /bin/bash
 シェル内で、ルートディレクトリーのファイル一覧を表示します:
 
 ```shell
-root@shell-demo:/# ls /
+# このコマンドをコンテナ内で実行します
+ls /
 ```
 
 シェル内で、他のコマンドを試しましょう。以下がいくつかの例です:
 
 ```shell
-root@shell-demo:/# ls /
-root@shell-demo:/# cat /proc/mounts
-root@shell-demo:/# cat /proc/1/maps
-root@shell-demo:/# apt-get update
-root@shell-demo:/# apt-get install -y tcpdump
-root@shell-demo:/# tcpdump
-root@shell-demo:/# apt-get install -y lsof
-root@shell-demo:/# lsof
-root@shell-demo:/# apt-get install -y procps
-root@shell-demo:/# ps aux
-root@shell-demo:/# ps aux | grep nginx
+# これらのサンプルコマンドをコンテナ内で実行することができます
+ls /
+cat /proc/mounts
+cat /proc/1/maps
+apt-get update
+apt-get install -y tcpdump
+tcpdump
+apt-get install -y lsof
+lsof
+apt-get install -y procps
+ps aux
+ps aux | grep nginx
 ```
 
 ## nginxのルートページへの書き込み
@@ -81,25 +83,31 @@ Podの設定ファイルを再度確認します。Podは`emptyDir`ボリュー
 シェル内で、`/usr/share/nginx/html`ディレクトリに`index.html`を作成します。
 
 ```shell
-root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
+# このコマンドをコンテナ内で実行します
+echo 'Hello shell demo' > /usr/share/nginx/html/index.html
 ```
 
 シェル内で、nginxサーバーにGETリクエストを送信します:
 
 ```shell
-root@shell-demo:/# apt-get update
-root@shell-demo:/# apt-get install curl
-root@shell-demo:/# curl localhost
+# これらのコマンドをコンテナ内のシェルで実行します
+apt-get update
+apt-get install curl
+curl http://localhost/
 ```
 
 出力に`index.html`ファイルに書き込んだ文字列が表示されます:
 
-```shell
+```
 Hello shell demo
 ```
 
 シェルを終了する場合、`exit`を入力します。
 
+```shell
+exit # コンテナ内のシェルを終了する
+```
+
 ## コンテナ内での各コマンドの実行
 
 シェルではない通常のコマンドウインドウ内で、実行中のコンテナの環境変数の一覧を表示します:
@@ -111,9 +119,9 @@ kubectl exec shell-demo env
 他のコマンドを試します。以下がいくつかの例です:
 
 ```shell
-kubectl exec shell-demo ps aux
-kubectl exec shell-demo ls /
-kubectl exec shell-demo cat /proc/1/mounts
+kubectl exec shell-demo -- ps aux
+kubectl exec shell-demo -- ls /
+kubectl exec shell-demo -- cat /proc/1/mounts
 ```
 
 
@@ -123,22 +131,21 @@ kubectl exec shell-demo cat /proc/1/mounts
 ## Podが1つ以上のコンテナを持つ場合にシェルを開く
 
 Podが1つ以上のコンテナを持つ場合、`--container`か`-c`を使用して、`kubectl exec`コマンド内でコンテナを指定します。
-例えば、my-podという名前のPodがあり、そのPodがmain-appとhelper-appという2つのコンテナを持つとします。
-以下のコマンドはmain-appのコンテナへのシェルを開きます。
+例えば、my-podという名前のPodがあり、そのPodが _main-app_ と _helper-app_ という2つのコンテナを持つとします。
+以下のコマンドは _main-app_ のコンテナへのシェルを開きます。
 
 ```shell
-kubectl exec -it my-pod --container main-app -- /bin/bash
+kubectl exec -i -t my-pod --container main-app -- /bin/bash
 ```
 
-
-
+{{< note >}}
+ショートオプションの`-i`と`-t`は、ロングオプションの`--stdin`と`--tty`と同様です。
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
 
-* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
-
-
+* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む
 
 
 
diff --git a/content/ja/docs/tasks/inject-data-application/_index.md b/content/ja/docs/tasks/inject-data-application/_index.md
index 52c5ca5128..a28c380a26 100644
--- a/content/ja/docs/tasks/inject-data-application/_index.md
+++ b/content/ja/docs/tasks/inject-data-application/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "アプリケーションへのデータ注入"
+description: ワークロードを実行するPodの構成とその他のデータを指定します。
 weight: 30
 ---
diff --git a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md
index 3457783864..2427603f35 100644
--- a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -22,11 +22,11 @@ weight: 20
 
 Podを作成するとき、そのPodで実行するコンテナに環境変数を設定することができます。環境変数を設定するには、設定ファイルに `env` または `envFrom` フィールドを含めます。
 
-この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定ファイルを以下に示します:
+この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定マニフェストを以下に示します:
 
 {{< codenew file="pods/inject/envars.yaml" >}}
 
-1. YAML設定ファイルに基づいてPodを作成します:
+1. マニフェストに基づいてPodを作成します:
 
     ```shell
     kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
@@ -54,7 +54,8 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数
 1. シェルで`printenv`コマンドを実行すると、環境変数の一覧が表示されます。
 
     ```shell
-    root@envar-demo:/# printenv
+    # コンテナ内のシェルで以下のコマンドを実行します
+    printenv
     ```
 
     出力は以下のようになります:
@@ -74,6 +75,10 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数
 `env`または`envFrom`フィールドを使用して設定された環境変数は、コンテナイメージで指定された環境変数を上書きします。
 {{< /note >}}
 
+{{< note >}}
+環境変数は相互に参照でき、循環して使用可能です。使用する前に順序に注意してください。
+{{< /note >}}
+
 ## 設定の中で環境変数を使用する {#using-environment-variables-inside-of-your-config}
 
 Podの設定で定義した環境変数は、Podのコンテナに設定したコマンドや引数など、設定の他の場所で使用することができます。以下の設定例では、環境変数`GREETING`、`HONORORIFIC`、`NAME`にそれぞれ `Warm greetings to`、`The Most Honorable`、`Kubernetes`を設定しています。これらの環境変数は、`env-print-demo`コンテナに渡されるCLI引数で使われます。
diff --git a/content/ja/docs/tasks/run-application/_index.md b/content/ja/docs/tasks/run-application/_index.md
index c00f88f4bb..17d2339e7e 100755
--- a/content/ja/docs/tasks/run-application/_index.md
+++ b/content/ja/docs/tasks/run-application/_index.md
@@ -1,5 +1,6 @@
 ---
 title: "アプリケーションの実行"
+description: ステートレスアプリケーションとステートフルアプリケーションの両方を実行および管理します。
 weight: 40
 ---
 
diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md
index 42f22c1b74..659dabec17 100644
--- a/content/ja/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md
@@ -51,7 +51,7 @@ kubectl delete pods -l app=myapp
 
 ### 永続ボリューム
 
-StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
+StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが終了した後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。
 
 {{< note >}}
 データを損失する可能性があるため、PVCを削除するときは注意してください。
diff --git a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
index 7d6830a50f..83f7b52c85 100644
--- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -31,13 +31,13 @@ StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する
 kubectl delete pods <pod>
 ```
 
-上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。
+上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前にPodが[適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)ことを保証します。
 
-Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
+Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/concepts/architecture/nodes/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
 
-   * (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。<br/>
-   * 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。<br/>
-   * ユーザーによりPodを強制削除します。
+* (ユーザーまたは[Node Controller](/ja/docs/concepts/architecture/nodes/)によって)Nodeオブジェクトが削除されます。
+* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
+* ユーザーによりPodを強制削除します。
 
 推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。
 
diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
index d76e60f5c3..18b4dda5bb 100644
--- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
+++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
@@ -21,11 +21,11 @@ weight: 30
 
 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 * {{< include "default-storage-class-prereqs.md" >}}
-* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/)
+* このチュートリアルは、あなたが[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)
   と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、
-  さらには[Pod](/ja/docs/concepts/workloads/pods/pod/)、
+  さらには[Pod](/ja/docs/concepts/workloads/pods/)、
   [Service](/ja/docs/concepts/services-networking/service/)、
-  [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの
+  [ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)などの
   他のコアな概念に精通していることを前提としています。
 * MySQLに関する知識は記事の理解に役立ちますが、
   このチュートリアルは他のシステムにも役立つ一般的なパターンを提示することを目的としています。
@@ -264,7 +264,7 @@ Podを強制的にReadyではない状態にする間、上記の`SELECT @@serve
 ### Readiness Probeを壊す
 
 `mysql`コンテナに対する
-[readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
+[readiness probe](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
 は、`mysql -h 127.0.0.1 -e 'SELECT 1'`コマンドを実行することで、サーバーが起動していてクエリーが実行できることを確認します。
 
 このreadiness probeを失敗させる1つの方法は、そのコマンドを壊すことです。
diff --git a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md
index 88a35b7d84..963df78524 100644
--- a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md
+++ b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md
@@ -96,7 +96,7 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー
 
 ## Deploymentの更新
 
-新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.8を使用するように指定しています。
+新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.16.1を使用するように指定しています。
 
 {{< codenew file="application/deployment-update.yaml" >}}
 
diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index bd9bc35465..eced279efc 100644
--- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -13,7 +13,7 @@ content_type: task
 
 ## {{% heading "prerequisites" %}}
 
-* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。
+* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。
 * サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
 * KubernetesクラスターのクラスターDNSを有効化する必要があります。
   * クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。
diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
index a0211e2a18..86b4e589e6 100644
--- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -12,7 +12,7 @@ GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-ser
 
 ## {{% heading "prerequisites" %}}
 
-* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。
+* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。
 * [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。
 * SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。
 * サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md
index bad7d8bef2..ac97313bb8 100755
--- a/content/ja/docs/tasks/tools/_index.md
+++ b/content/ja/docs/tasks/tools/_index.md
@@ -1,4 +1,28 @@
 ---
 title: "ツールのインストール"
+description: Kubernetesのツールをローカルのコンピュータ上にセットアップします。
 weight: 10
+no_list: true
 ---
+
+## kubectl
+
+Kubernetesのコマンドラインツール`kubectl`を使用すると、Kubernetesクラスターに対してコマンドを実行できるようになります。kubectlは、アプリケーションのデプロイ、クラスターリソースの調査と管理、ログの表示などに使用できます。
+
+`kubectl`のダウンロードとインストールを行い、クラスターへのアクセスをセットアップする方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。
+
+また、[`kubectl`リファレンスドキュメント](/ja/docs/reference/kubectl/)も参照できます。
+
+## Minikube
+
+[Minikube](https://minikube.sigs.k8s.io/)は、Kubernetesをローカルで実行するツールです。MinikubeはシングルノードのKubernetesクラスターをパーソナルコンピューター上(Windows、macOS、Linux PCを含む)で実行することで、Kubernetesを試したり、日常的な開発作業のために利用できます。
+
+ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従うか、[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を読んでください。
+
+Minikubeが起動したら、[サンプルアプリケーションの実行](/ja/docs/tutorials/hello-minikube/)を試すことができます。
+
+## kind
+
+Minikubeと同じように、[kind](https://kind.sigs.k8s.io/docs/)もローカルコンピューター上でKubernetesを実行するツールです。Minikubeとは違い、kindは1種類のコンテナランタイム上でしか動作しません。実行には[Docker](https://docs.docker.com/get-docker/)のインストールと設定が必要です。
+
+[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/)に、kindの起動に必要な手順が説明されています。
diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md
index e468404469..2ab3ca50f7 100644
--- a/content/ja/docs/tasks/tools/install-kubectl.md
+++ b/content/ja/docs/tasks/tools/install-kubectl.md
@@ -9,7 +9,7 @@ card:
 ---
 
 <!-- overview -->
-Kubernetesのコマンドラインツールである[kubectl](/docs/user-guide/kubectl/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理および検査を行うことができます。kubectlの操作に関する完全なリストは、[Overview of kubectl](/docs/reference/kubectl/overview/)を参照してください。
+Kubernetesのコマンドラインツールである[kubectl](/ja/docs/reference/kubectl/overview/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理、検査およびログの表示を行うことができます。kubectlの操作に関する完全なリストは、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。
 
 
 ## {{% heading "prerequisites" %}}
@@ -26,7 +26,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと
 1. 次のコマンドにより、最新リリースをダウンロードしてください:
 
     ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
+    curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
     ```
 
     特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。
@@ -59,7 +59,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと
 
 {{< tabs name="kubectl_install" >}}
 {{< tab name="Ubuntu、DebianまたはHypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https
+sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
 echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
 sudo apt-get update
@@ -88,7 +88,7 @@ Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマ
 ```shell
 snap install kubectl --classic
 
-kubectl version
+kubectl version --client
 ```
 {{% /tab %}}
 {{% tab name="Homebrew" %}}
@@ -96,7 +96,7 @@ Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネ
 ```shell
 brew install kubectl
 
-kubectl version
+kubectl version --client
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -107,34 +107,34 @@ kubectl version
 
 1. 最新リリースをダウンロードしてください:
 
-    ```
-    curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
-    ```
+   ```bash
+   curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
+   ```
 
-    特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。
+   特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。
 
-    たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します:
+   たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します:
 
-    ```
+   ```bash
     curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
-    ```
+   ```
 
 2. kubectlバイナリを実行可能にしてください。
 
-    ```
-    chmod +x ./kubectl
-    ```
+   ```bash
+   chmod +x ./kubectl
+   ```
 
 3. バイナリをPATHの中に移動させてください。
 
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
+   ```bash
+   sudo mv ./kubectl /usr/local/bin/kubectl
+   ```
 4. インストールしたバージョンが最新であることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```
 
 ### Homebrewを使用してmacOSへインストールする
 
@@ -142,20 +142,20 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用
 
 1. インストールコマンドを実行してください:
 
-    ```
-    brew install kubectl
-    ```
-    または
+   ```bash
+   brew install kubectl
+   ```
+   または
 
-    ```
-    brew install kubernetes-cli
-    ```
+   ```bash
+   brew install kubernetes-cli
+   ```
 
 2. インストールしたバージョンが最新であることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```
 
 ### MacPortsを使用してmacOSへインストールする
 
@@ -163,16 +163,16 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
 
 1. インストールコマンドを実行してください:
 
-    ```
-    sudo port selfupdate
-    sudo port install kubectl
-    ```
+   ```bash
+   sudo port selfupdate
+   sudo port install kubectl
+   ```
 
 2. インストールしたバージョンが最新であることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```
 
 ## Windowsへkubectlをインストールする {#install-kubectl-on-windows}
 
@@ -180,20 +180,20 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使
 
 1. [こちらのリンク](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)から、最新リリースである{{< param "fullversion" >}}をダウンロードしてください。
 
-    または、`curl`をインストールされていれば、次のコマンドも使用できます:
+   または、`curl`をインストールされていれば、次のコマンドも使用できます:
 
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
-    ```
+    ```bash
+   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
+   ```
 
-    最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。
+   最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。
 
 2. バイナリをPATHに追加します
 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```
 {{< note >}}
 [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。
 {{< /note >}}
@@ -204,68 +204,77 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー
 
 1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください):
 
-    ```
-    Install-Script -Name install-kubectl -Scope CurrentUser -Force
-    install-kubectl.ps1 [-DownloadLocation <path>]
-    ```
+   ```powershell
+   Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
+   install-kubectl.ps1 [-DownloadLocation <path>]
+   ```
 
-    {{< note >}}`DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。{{< /note >}}
+   {{< note >}}
+   `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。
+   {{< /note >}}
 
-    インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。
+   インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。
 
 2. インストールしたバージョンが最新であることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```powershell
+   kubectl version --client
+   ```
 
-    {{< note >}}アップデートする際は、手順1に示した2つのコマンドを再実行してください。{{< /note >}}
+{{< note >}}
+アップデートする際は、手順1に示した2つのコマンドを再実行してください。
+{{< /note >}}
 
 ### ChocolateyまたはScoopを使用してWindowsへインストールする
 
-Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。
-{{< tabs name="kubectl_win_install" >}}
-{{% tab name="choco" %}}
+1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。
 
-    choco install kubernetes-cli
+   {{< tabs name="kubectl_win_install" >}}
+   {{% tab name="choco" %}}
+   ```powershell
+   choco install kubernetes-cli
+   ```
+   {{% /tab %}}
+   {{% tab name="scoop" %}}
+   ```powershell
+   scoop install kubectl
+   ```
+   {{% /tab %}}
+   {{< /tabs >}}
 
-{{% /tab %}}
-{{% tab name="scoop" %}}
-
-    scoop install kubectl
-
-{{% /tab %}}
-{{< /tabs >}}
 2. インストールしたバージョンが最新であることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```powershell
+   kubectl version --client
+   ```
 
 3. ホームディレクトリへ移動してください:
 
-    ```
-    cd %USERPROFILE%
-    ```
+   ```powershell
+   # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。
+   cd ~
+   ```
 4. `.kube`ディレクトリを作成してください:
 
-    ```
-    mkdir .kube
-    ```
+   ```powershell
+   mkdir .kube
+   ```
 
 5. 作成した`.kube`ディレクトリへ移動してください:
 
-    ```
-    cd .kube
-    ```
+   ```powershell
+   cd .kube
+   ```
 
 6. リモートのKubernetesクラスターを使うために、kubectlを設定してください:
 
-    ```
-    New-Item config -type file
-    ```
+   ```powershell
+   New-Item config -type file
+   ```
 
-    {{< note >}}Notepadなどの選択したテキストエディターから設定ファイルを編集してください。{{< /note >}}
+{{< note >}}
+Notepadなどの選択したテキストエディターから設定ファイルを編集してください。
+{{< /note >}}
 
 ## Google Cloud SDKの一部としてダウンロードする
 
@@ -274,19 +283,19 @@ Google Cloud SDKの一部として、kubectlをインストールすることも
 1. [Google Cloud SDK](https://cloud.google.com/sdk/)をインストールしてください。
 2. `kubectl`のインストールコマンドを実行してください:
 
-    ```
-    gcloud components install kubectl
-    ```
+   ```shell
+   gcloud components install kubectl
+   ```
 
 3. インストールしたバージョンが最新であることを確認してください:
 
-    ```
-    kubectl version --client
-    ```
+   ```shell
+   kubectl version --client
+   ```
 
 ## kubectlの設定を検証する
 
-kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。
+kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。
 
 クラスターの状態を取得し、kubectlが適切に設定されていることを確認してください:
 
@@ -297,7 +306,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ
 
 以下のようなメッセージが表示されている場合は、kubectlは正しく設定されていないか、Kubernetesクラスターに接続できていません。
 
-```shell
+```
 The connection to the server <server-name:port> was refused - did you specify the right host or port?
 ```
 
@@ -335,7 +344,7 @@ bash-completionは多くのパッケージマネージャーから提供され
 
 これを調べるには、シェルをリロードしてから`type _init_completion`を実行してください。コマンドが成功していればすでに設定済みです。そうでなければ、`~/.bashrc`に以下を追記してください:
 
-```shell
+```bash
 source /usr/share/bash-completion/bash_completion
 ```
 
@@ -347,21 +356,21 @@ source /usr/share/bash-completion/bash_completion
 
 - 補完スクリプトを`~/.bashrc`内でsourceしてください:
 
-    ```shell
-    echo 'source <(kubectl completion bash)' >>~/.bashrc
-    ```
+   ```bash
+   echo 'source <(kubectl completion bash)' >>~/.bashrc
+   ```
 
 - 補完スクリプトを`/etc/bash_completion.d`ディレクトリに追加してください:
 
-    ```shell
-    kubectl completion bash >/etc/bash_completion.d/kubectl
-    ```
+   ```bash
+   kubectl completion bash >/etc/bash_completion.d/kubectl
+   ```
 - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
 
-    ```shell
-    echo 'alias k=kubectl' >>~/.bashrc
-    echo 'complete -F __start_kubectl k' >>~/.bashrc
-    ```
+```bash
+echo 'alias k=kubectl' >>~/.bashrc
+echo 'complete -F __start_kubectl k' >>~/.bashrc
+```
 
 {{< note >}}
 bash-completionは`/etc/bash_completion.d`内のすべての補完スクリプトをsourceします。
@@ -389,19 +398,19 @@ bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSの
 
 ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。
 
-```shell
+```bash
 echo $BASH_VERSION
 ```
 
 バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。
 
-```shell
+```bash
 brew install bash
 ```
 
 シェルをリロードし、希望するバージョンを使用していることを確認してください。
 
-```shell
+```bash
 echo $BASH_VERSION $SHELL
 ```
 
@@ -415,13 +424,13 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。
 
 `type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます:
 
-```shell
+```bash
 brew install bash-completion@2
 ```
 
-このコマンドの出力で示されたように、`~/.bashrc`に以下を追記してください:
+このコマンドの出力で示されたように、`~/.bash_profile`に以下を追記してください:
 
-```shell
+```bash
 export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
 [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
 ```
@@ -433,30 +442,30 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
 
 すべてのシェルセッションにてkubectlの補完スクリプトをsourceできるようにしなければなりません。これを行うには複数の方法があります:
 
-- 補完スクリプトを`~/.bashrc`内でsourceする:
+- 補完スクリプトを`~/.bash_profile`内でsourceする:
 
-    ```shell
-    echo 'source <(kubectl completion bash)' >>~/.bashrc
-    ```
+   ```bash
+   echo 'source <(kubectl completion bash)' >>~/.bash_profile
+   ```
 
 - 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する:
 
-    ```shell
-    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
-    ```
+   ```bash
+   kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
+   ```
 
 - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
 
-    ```shell
-    echo 'alias k=kubectl' >>~/.bashrc
-    echo 'complete -F __start_kubectl k' >>~/.bashrc
-    ```
+   ```bash
+   echo 'alias k=kubectl' >>~/.bash_profile
+   echo 'complete -F __start_kubectl k' >>~/.bash_profile
+   ```
 
 - kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。
 
-{{< note >}}
-Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。
-{{< /note >}}
+   {{< note >}}
+   Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。
+   {{< /note >}}
 
 どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。
 {{% /tab %}}
@@ -465,15 +474,15 @@ Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_
 
 Zshにおけるkubectlの補完スクリプトは`kubectl completion zsh`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。
 
-すべてのシェルセッションで使用するには、`~/.bashrc`に以下を追記してください:
+すべてのシェルセッションで使用するには、`~/.zshrc`に以下を追記してください:
 
-```shell
+```zsh
 source <(kubectl completion zsh)
 ```
 
 kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます:
 
-```shell
+```zsh
 echo 'alias k=kubectl' >>~/.zshrc
 echo 'complete -F __start_kubectl k' >>~/.zshrc
 ```
@@ -482,7 +491,7 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc
 
 `complete:13: command not found: compdef`のようなエラーが出力された場合は、以下を`~/.zshrc`の先頭に追記してください:
 
-```shell
+```zsh
 autoload -Uz compinit
 compinit
 ```
@@ -494,8 +503,7 @@ compinit
 ## {{% heading "whatsnext" %}}
 
 * [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/)
-* クラスターの作成に関する詳細を[スタートガイド](/docs/setup/)で確認する
-* [アプリケーションを起動して公開する方法を学ぶ](/docs/tasks/access-application-cluster/service-access-application-cluster/)
-* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
+* クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する
+* [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
 * [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する
-
diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md
index 30b15718ca..730145740c 100644
--- a/content/ja/docs/tasks/tools/install-minikube.md
+++ b/content/ja/docs/tasks/tools/install-minikube.md
@@ -76,7 +76,7 @@ kubectlがインストールされていることを確認してください。
 
 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
 
-Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。
+Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--driver=none`オプションもサポートしています。
 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。
 
 Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。
@@ -84,7 +84,7 @@ Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッ
 
 {{< caution >}}
 `none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。
-`--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。
+`--driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。
 {{< /caution >}}
 
 MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。
@@ -209,12 +209,16 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window
 
 {{< note >}}
 
-`minikube start`で`--vm-driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。
+`minikube start`で`--driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--driver`値のすべてのリストは、[specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。
 
 {{< /note >}}
 
+{{< caution >}}
+KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu:///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu:///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。
+{{< /caution >}}
+
 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```
 
 `minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。
diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md
index 3d82984243..1c1d55300a 100644
--- a/content/ja/docs/tutorials/_index.md
+++ b/content/ja/docs/tutorials/_index.md
@@ -1,6 +1,7 @@
 ---
 title: チュートリアル
 main_menu: true
+no_list: true
 weight: 60
 content_type: concept
 ---
@@ -54,6 +55,6 @@ content_type: concept
 ## {{% heading "whatsnext" %}}
 
 
-チュートリアルを書きたい場合は、[ページテンプレートの使用](/docs/contribute/style/page-templates/)を参照し、チュートリアルのページタイプとチュートリアルテンプレートについてご確認ください。
+チュートリアルのページタイプについての情報は、[Content Page Types](/docs/contribute/style/page-content-types/)を参照してください。
 
 
diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md
index 98a9286503..530e53ffd5 100644
--- a/content/ja/docs/tutorials/hello-minikube.md
+++ b/content/ja/docs/tutorials/hello-minikube.md
@@ -7,7 +7,7 @@ menu:
     title: "Get Started"
     weight: 10
     post: >
-      <p>手を動かす準備はできていますか？本チュートリアルでは、Node.jsを使った簡単な"Hello World"を実行するKubernetesクラスタをビルドします。</p>
+      <p>手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスターをビルドします。</p>
 card: 
   name: tutorials
   weight: 10
@@ -15,7 +15,7 @@ card:
 
 <!-- overview -->
 
-このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
+このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でサンプルアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。
 
 {{< note >}}
 [Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。
@@ -26,7 +26,7 @@ card:
 ## {{% heading "objectives" %}}
 
 
-* Minikubeへのhello worldアプリケーションのデプロイ
+* Minikubeへのサンプルアプリケーションのデプロイ
 * アプリケーションの実行
 * アプリケーションログの確認
 
@@ -35,25 +35,23 @@ card:
 ## {{% heading "prerequisites" %}}
 
 
-このチュートリアルは下記のファイルからビルドされるコンテナーイメージを提供します:
+このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナイメージを提供します。
 
-{{< codenew language="js" file="minikube/server.js" >}}
 
-{{< codenew language="conf" file="minikube/Dockerfile" >}}
-
-`docker build`コマンドについての詳細な情報は、[Dockerのドキュメント](https://docs.docker.com/engine/reference/commandline/build/)を参照してください。
 
 
 
 <!-- lessoncontent -->
 
-## Minikubeクラスタの作成
+## Minikubeクラスターの作成
 
 1. **Launch Terminal** をクリックしてください
 
     {{< kat-button >}}
 
-    {{< note >}}Minikubeをローカルにインストール済みの場合は、`minikube start`を実行してください。{{< /note >}}
+{{< note >}}
+    Minikubeをローカルにインストール済みの場合は、`minikube start`を実行してください。
+{{< /note >}}
 
 2. ブラウザーでKubernetesダッシュボードを開いてください:
 
@@ -67,7 +65,7 @@ card:
 
 ## Deploymentの作成
 
-Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。
+Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。
 
 1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。
 
@@ -101,7 +99,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
     hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
     ```
 
-4. クラスタイベントを確認します:
+4. クラスターイベントを確認します:
 
     ```shell
     kubectl get events
@@ -113,11 +111,13 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
     kubectl config view
     ```
 
-    {{< note >}} `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。{{< /note >}}
+{{< note >}}
+`kubectl`コマンドの詳細な情報は[kubectl overview](/ja/docs/reference/kubectl/overview/)を参照してください。
+{{< /note >}}
 
 ## Serviceの作成
 
-通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。
+通常、PodはKubernetesクラスター内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。
 
 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します:
 
@@ -125,7 +125,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
     kubectl expose deployment hello-node --type=LoadBalancer --port=8080
     ```
 
-    `--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。
+    `--type=LoadBalancer`フラグはServiceをクラスター外部に公開したいことを示しています。
 
 2. 作成したServiceを確認します:
 
@@ -154,7 +154,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ
 
 5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。
 
-    "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。
+    アプリケーションとその応答が表示されるブラウザーウィンドウが開きます。
 
 ## アドオンの有効化
 
@@ -243,7 +243,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a
 
 ## クリーンアップ
 
-クラスタに作成したリソースをクリーンアップします:
+クラスターに作成したリソースをクリーンアップします:
 
 ```shell
 kubectl delete service hello-node
@@ -270,5 +270,3 @@ minikube delete
 * [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)について学ぶ.
 * [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)について学ぶ.
 * [Serviceオブジェクト](/ja/docs/concepts/services-networking/service/)について学ぶ.
-
-
diff --git a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index 4d99a7b1cc..ae52322786 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -19,9 +19,9 @@ weight: 20
 
         <div class="katacoda">
             <div class="katacoda__alert">
-                ターミナルを使うには、PCまたはタブレットをお使いください
+                ターミナルを使うにはスクリーンが狭い場合は、PCまたはタブレットをお使いください
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 9b59db721b..71e04ef76b 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
         <div class="row">
             <div class="col-md-12">
                 <p>
-                    Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Podの詳細はこちらです</a>。
+                    Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。<a href="/ja/docs/concepts/workloads/pods/">Podの詳細はこちらです</a>。
                 </p>
             </div>
         </div>
@@ -30,7 +30,7 @@ weight: 20
                 ターミナルを使うには、PCまたはタブレットをお使いください
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
index 8bb7a2e6c8..d0b22024b4 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
@@ -28,7 +28,7 @@ weight: 10
             <div class="col-md-8">
                 <h3>Kubernetes Deployments</h3>
                 <p>
-                実行中のKubernetesクラスターを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、Kubernetesの<b>Deployment</b> の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、Kubernetesマスターは指定されたアプリケーションインスタンスをクラスター内の個々のノードにスケジュールします。
+                実行中のKubernetesクラスターを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、Kubernetesの<b>Deployment</b> の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、KubernetesマスターはDeployment内に含まれるアプリケーションインスタンスをクラスター内の個々のノードで実行するようにスケジュールします。
                 </p>
 
                 <p>アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているノードが停止、削除された場合、Deploymentコントローラーはそのインスタンスをクラスター内の別のノード上のインスタンスと置き換えます。<b>これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。</b></p>
@@ -72,7 +72,7 @@ weight: 10
 
                 <p>Kubernetesのコマンドラインインターフェイスである<b>kubectl</b>を使用して、Deploymentを作成、管理できます。kubectlはKubernetes APIを使用してクラスターと対話します。このモジュールでは、Kubernetesクラスターでアプリケーションを実行するDeploymentを作成するために必要な、最も一般的なkubectlコマンドについて学びます。</p>
 
-                <p>Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要があります。Deploymentを更新することで、あとでその情報を変更できます。チュートリアルのモジュール<a href="/ja/docs/tutorials/kubernetes-basics/scale-intro/">5</a>と<a href="/ja/docs/tutorials/kubernetes-basics/update-intro/">6</a>では、Deploymentをどのようにスケール、更新できるかについて説明します。</p>
+                <p>Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要があります。Deploymentを更新することで、あとでその情報を変更できます。チュートリアルのモジュール<a href="/ja/docs/tutorials/kubernetes-basics/scale/scale-intro/">5</a>と<a href="/ja/docs/tutorials/kubernetes-basics/update/update-intro/">6</a>では、Deploymentをどのようにスケール、更新できるかについて説明します。</p>
 
             </div>
             <div class="col-md-4">
diff --git a/content/ja/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index 2b35d0eefb..78f62dd310 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 ターミナルを使うには、PCまたはタブレットをお使いください
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 0f02900cd5..eadf0ed06d 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 ターミナルを使うには、PCまたはタブレットをお使いください
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index ea39fbd94e..3111e67396 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ weight: 10
 			<div class="col-md-8">
 			<h3>Kubernetes Serviceの概要</h3>
 
-			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod-overview/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
+			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
 
 			<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
 
diff --git a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index 77b5890c8a..2a6185b57e 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 ターミナルを使うには、PCまたはタブレットをお使いください
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html
index 602fd843e5..343894e58c 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html
@@ -40,7 +40,7 @@ weight: 10
                     </ul>
                 </div>
                 <div class="content__box content__box_fill">
-                    <p><i>kubectl runコマンドの--replicasパラメーターを使用することで、最初から複数のインスタンスを含むDeploymentを作成できます。</i></p>
+                    <p><i>kubectl create deploymentコマンドの--replicasパラメーターを使用することで、最初から複数のインスタンスを含むDeploymentを作成できます。</i></p>
                 </div>
             </div>
         </div>
diff --git a/content/ja/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/update/update-interactive.html
index ae0c72cbd3..dd8e0a6266 100644
--- a/content/ja/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 ターミナルを使うには、PCまたはタブレットをお使いください
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md
index 69c626d532..05a54152a3 100644
--- a/content/ja/docs/tutorials/services/source-ip.md
+++ b/content/ja/docs/tutorials/services/source-ip.md
@@ -148,7 +148,7 @@ ip addr
 そして、`wget`を使用してローカルのウェブサーバーに問い合わせます。
 
 ```shell
-# 10.0.170.92 の部分をウェブサーバーのPodのIPv4アドレスに置き換えてください
+# "10.0.170.92" の部分をService名が"clusterip"のIPv4アドレスに置き換えてください
 wget -qO - 10.0.170.92
 ```
 ```
@@ -176,7 +176,7 @@ service/nodeport exposed
 
 ```shell
 NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
-NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
+NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
 ```
 
 クラウドプロバイダーで実行する場合、上に示した`nodes:nodeport`に対してファイアウォールのルールを作成する必要があるかもしれません。それでは、上で割り当てたノードポート経由で、クラスターの外部からServiceにアクセスしてみましょう。
@@ -204,17 +204,19 @@ client_address=10.240.0.3
 
 図で表すと次のようになります。
 
-```
-          client
-             \ ^
-              \ \
-               v \
-   node 1 <--- node 2
-    | ^   SNAT
-    | |   --->
-    v |
- endpoint
-```
+{{< mermaid >}}
+graph LR;
+  client(client)-->node2[Node 2];
+  node2-->client;
+  node2-. SNAT .->node1[Node 1];
+  node1-. SNAT .->node2;
+  node1-->endpoint(Endpoint);
+
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  class node1,node2,endpoint k8s;
+  class client plain;
+{{</ mermaid >}}
 
 クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシーリクエストだけをプロキシーし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。
 
@@ -253,17 +255,20 @@ client_address=198.51.100.79
 
 図で表すと次のようになります。
 
-```
-        client
-       ^ /   \
-      / /     \
-     / v       X
-   node 1     node 2
-    ^ |
-    | |
-    | v
- endpoint
-```
+{{< mermaid >}}
+graph TD;
+  client --> node1[Node 1];
+  client(client) --x node2[Node 2];
+  node1 --> endpoint(endpoint);
+  endpoint --> node1;
+
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  class node1,node2,endpoint k8s;
+  class client plain;
+{{</ mermaid >}}
+
+
 
 ## `Type=LoadBalancer`を使用したServiceでの送信元IP
 
@@ -312,17 +317,7 @@ client_address=10.240.0.5
 
 図で表すと次のようになります。
 
-```
-                      client
-                        |
-                      lb VIP
-                     / ^
-                    v /
-ヘルスチェック --->   node 1   node 2 <--- ヘルスチェック
-        200  <---   ^ |             ---> 500
-                    | V
-                 endpoint
-```
+![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg)
 
 アノテーションを設定することで動作をテストできます。
 
@@ -397,7 +392,7 @@ client_address=198.51.100.79
 
 2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。
 
-1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。
+1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。
 
 ## {{% heading "cleanup" %}}
 
diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md
index 32b215e62d..c5f8ed3986 100644
--- a/content/ja/docs/tutorials/stateful-application/cassandra.md
+++ b/content/ja/docs/tutorials/stateful-application/cassandra.md
@@ -5,14 +5,18 @@ weight: 30
 ---
 
 <!-- overview -->
-このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。データベースの一種であるCassandraには、データの耐久性(アプリケーションの*状態*)を提供するために永続ストレージが必要です。この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。
+このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。
+データベースの一種であるCassandraには、データの耐久性(アプリケーションの _状態_)を提供するために永続ストレージが必要です。
+この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。
 
-*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。
+*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。
+このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。
 
 {{< note >}}
-CassandraとKubernetesは、ともにクラスターのメンバーを表すために*ノード*という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(*ring*と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。
+CassandraとKubernetesは、ともにクラスターのメンバーを表すために _ノード_ という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター( _ring_ と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。
 
-Cassandraノードが開始すると、*シードリスト*を使ってring上の他のノードの検出が始まります。このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。
+Cassandraノードが開始すると、 _シードリスト_ を使ってring上の他のノードの検出が始まります。
+このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。
 {{< /note >}}
 
 
@@ -34,7 +38,8 @@ Cassandraノードが開始すると、*シードリスト*を使ってring上
 ### Minikubeのセットアップに関する追加の設定手順
 
 {{< caution >}}
-[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください。
+[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。
+デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください:
 
 ```shell
 minikube start --memory 5120 --cpus=4
@@ -48,7 +53,7 @@ minikube start --memory 5120 --cpus=4
 
 Kubernetesでは、{{< glossary_tooltip text="Service" term_id="service" >}}は同じタスクを実行する{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合を表します。
 
-以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます。
+以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます:
 
 {{< codenew file="application/cassandra/cassandra-service.yaml" >}}
 
@@ -82,12 +87,13 @@ cassandra   ClusterIP   None         <none>        9042/TCP   45s
 以下に示すStatefulSetマニフェストは、3つのPodからなるCassandra ringを作成します。
 
 {{< note >}}
-この例ではMinikubeのデフォルトのプロビジョナーを使用しています。クラウドを使用している場合、StatefulSetを更新してください。
+この例ではMinikubeのデフォルトのプロビジョナーを使用しています。
+クラウドを使用している場合、StatefulSetを更新してください。
 {{< /note >}}
 
 {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
 
-`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します。
+`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します:
 
 ```shell
 # cassandra-statefulset.yaml を編集せずにapplyできる場合は、このコマンドを使用してください
@@ -110,7 +116,7 @@ kubectl apply -f cassandra-statefulset.yaml
     kubectl get statefulset cassandra
     ```
 
-    結果は次のようになるはずです。
+    結果は次のようになるはずです:
 
     ```
     NAME        DESIRED   CURRENT   AGE
@@ -125,7 +131,7 @@ kubectl apply -f cassandra-statefulset.yaml
     kubectl get pods -l="app=cassandra"
     ```
 
-    結果は次のようになるはずです。
+    結果は次のようになるはずです:
 
     ```shell
     NAME          READY     STATUS              RESTARTS   AGE
@@ -133,7 +139,7 @@ kubectl apply -f cassandra-statefulset.yaml
     cassandra-1   0/1       ContainerCreating   0          8s
     ```
 
-    3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します。
+    3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します:
 
     ```
     NAME          READY     STATUS    RESTARTS   AGE
@@ -148,7 +154,7 @@ kubectl apply -f cassandra-statefulset.yaml
     kubectl exec -it cassandra-0 -- nodetool status
     ```
 
-    結果は次のようになるはずです。
+    結果は次のようになるはずです:
 
     ```
     Datacenter: DC1-K8Demo
@@ -171,7 +177,8 @@ kubectl apply -f cassandra-statefulset.yaml
     kubectl edit statefulset cassandra
     ```
 
-    このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。以下の例は、StatefulSetファイルの抜粋です。
+    このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。
+    以下の例は、StatefulSetファイルの抜粋です:
 
     ```yaml
     # Please edit the object below. Lines beginning with a '#' will be ignored,
@@ -197,13 +204,13 @@ kubectl apply -f cassandra-statefulset.yaml
 
     これで、StatefulSetが4つのPodを実行するようにスケールされました。
 
-1. CassandraのStatefulSetを取得して、変更を確かめます。
+1. CassandraのStatefulSetを取得して、変更を確かめます:
 
     ```shell
     kubectl get statefulset cassandra
     ```
 
-    結果は次のようになるはずです。
+    結果は次のようになるはずです:
 
     ```
     NAME        DESIRED   CURRENT   AGE
@@ -214,13 +221,14 @@ kubectl apply -f cassandra-statefulset.yaml
 
 ## {{% heading "cleanup" %}}
 
-StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。
+StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。
+StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。
 
 {{< warning >}}
 ストレージクラスやreclaimポリシーによっては、*PersistentVolumeClaim*を削除すると、関連するボリュームも削除される可能性があります。PersistentVolumeClaimの削除後にもデータにアクセスできるとは決して想定しないでください。
 {{< /warning >}}
 
-1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します。
+1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します:
 
     ```shell
     grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
@@ -230,7 +238,7 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関
       && kubectl delete persistentvolumeclaim -l app=cassandra
     ```
 
-1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します。
+1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します:
 
     ```shell
     kubectl delete service -l app=cassandra
@@ -240,7 +248,8 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関
 
 このチュートリアルのPodでは、Googleの[コンテナレジストリ](https://cloud.google.com/container-registry/docs/)の[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)イメージを使用しました。このDockerイメージは[debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)をベースにしており、OpenJDK 8が含まれています。
 
-このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。
+このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。
+環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。
 
 | 環境変数                  | デフォルト値      |
 | ------------------------ |:---------------: |
@@ -258,4 +267,3 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関
 * カスタムの[Seed Providerの設定](https://git.k8s.io/examples/cassandra/java/README.md)についてもっと学ぶ。
 
 
-
diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
index 7aed33777e..5e7b77443d 100644
--- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -188,8 +188,8 @@ kubectl apply -k ./
       結果は次のようになるはずです。
 
       ```
-      NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
-      wordpress   ClusterIP   10.0.0.89    <pending>     80:32406/TCP   4m
+      NAME        TYPE            CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
+      wordpress   LoadBalancer    10.0.0.89    <pending>     80:32406/TCP   4m
       ```
 
       {{< note >}}
diff --git a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md
index c4b76e1e3f..2dad39cfa9 100644
--- a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -46,7 +46,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
 ```
 
 
-上記のコマンドにより、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)オブジェクトを作成し、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)オブジェクトを関連づけます。ReplicaSetには5つの[Pod](/ja/docs/concepts/workloads/pods/pod/)があり、それぞれHello Worldアプリケーションが起動しています。
+上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}を作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}を関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。
 
 1. Deploymentに関する情報を表示します:
 
diff --git a/content/ja/examples/pods/pod-with-pod-affinity.yaml b/content/ja/examples/pods/pod-with-pod-affinity.yaml
index 1897af901f..e3f38f1dd5 100644
--- a/content/ja/examples/pods/pod-with-pod-affinity.yaml
+++ b/content/ja/examples/pods/pod-with-pod-affinity.yaml
@@ -12,7 +12,7 @@ spec:
             operator: In
             values:
             - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
     podAntiAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 100
diff --git a/content/ja/examples/service/networking/network-policy-allow-all-egress.yaml b/content/ja/examples/service/networking/network-policy-allow-all-egress.yaml
new file mode 100644
index 0000000000..42b2a2a296
--- /dev/null
+++ b/content/ja/examples/service/networking/network-policy-allow-all-egress.yaml
@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-egress
+spec:
+  podSelector: {}
+  egress:
+  - {}
+  policyTypes:
+  - Egress
diff --git a/content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml
new file mode 100644
index 0000000000..462912dae4
--- /dev/null
+++ b/content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml
@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-ingress
+spec:
+  podSelector: {}
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
diff --git a/content/ja/examples/service/networking/network-policy-default-deny-all.yaml b/content/ja/examples/service/networking/network-policy-default-deny-all.yaml
new file mode 100644
index 0000000000..5c0086bd71
--- /dev/null
+++ b/content/ja/examples/service/networking/network-policy-default-deny-all.yaml
@@ -0,0 +1,10 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-all
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
+  - Egress
diff --git a/content/ja/examples/service/networking/network-policy-default-deny-egress.yaml b/content/ja/examples/service/networking/network-policy-default-deny-egress.yaml
new file mode 100644
index 0000000000..a4659e1417
--- /dev/null
+++ b/content/ja/examples/service/networking/network-policy-default-deny-egress.yaml
@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-egress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Egress
diff --git a/content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml
new file mode 100644
index 0000000000..e823802487
--- /dev/null
+++ b/content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml
@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-ingress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
diff --git a/content/ja/includes/partner-style.css b/content/ja/includes/partner-style.css
index 7aeb255dd5..dc120872e0 100644
--- a/content/ja/includes/partner-style.css
+++ b/content/ja/includes/partner-style.css
@@ -82,7 +82,6 @@
 .button{
   max-width: 100%;
 	box-sizing: border-box;
-	font-family: "Roboto", sans-serif;
 	margin: 0;
 	display: inline-block;
 	border-radius: 6px;
diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html
index 6762f56dec..b3e7dc0648 100644
--- a/content/ja/training/_index.html
+++ b/content/ja/training/_index.html
@@ -112,7 +112,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
   </div>
 </div>
diff --git a/content/ko/_index.html b/content/ko/_index.html
index 0916d04245..93dc84d13b 100644
--- a/content/ko/_index.html
+++ b/content/ko/_index.html
@@ -2,11 +2,13 @@
 title: "운영 수준의 컨테이너 오케스트레이션"
 abstract: "자동화된 컨테이너 배포, 스케일링과 관리"
 cid: home
+sitemap:
+  priority: 1.0
 ---
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-### [쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
+[쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
 
 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
 {{% /blocks/feature %}}
@@ -41,11 +43,6 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon EU virtually on August 17-20, 2020</a>
-        <br>
-        <br>
-        <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
 </div>
 <div id="videoPlayer">
diff --git a/content/ko/case-studies/adform/index.html b/content/ko/case-studies/adform/index.html
index be35a2d837..1de43d0637 100644
--- a/content/ko/case-studies/adform/index.html
+++ b/content/ko/case-studies/adform/index.html
@@ -3,116 +3,84 @@ title: Adform Case Study
 linkTitle: Adform
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: adform_featured_logo.png
 draft: false
 featured: true
 weight: 47
 quote: >
   Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/adform/banner1.jpg
+heading_title_logo: /images/adform_logo.png
+subheading: >
+  Improving Performance and Morale with Cloud Native
+case_study_details:
+  - Company: AdForm
+  - Location: Copenhagen, Denmark
+  - Industry: Adtech
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/adform/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/adform_logo.png" style="width:15%;margin-bottom:0%" class="header_logo"><br> <div class="subhead">Improving Performance and Morale with Cloud Native
+<h2>Challenge</h2>
 
-</div></h1>
+<p><a href="https://site.adform.com/">Adform's</a> mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company's growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn't have self-healing infrastructure."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>AdForm</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Copenhagen, Denmark</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Adtech</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    <a href="https://site.adform.com/">Adform’s</a> mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."
-
-
-<br>
-
- <h2>Solution</h2>
-    The team, which had already been using <a href="https://prometheus.io/">Prometheus</a> for monitoring, embraced <a href="https://kubernetes.io/">Kubernetes</a> and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."
-
-
-</div>
-
-<div class="col2">
+<p>The team, which had already been using <a href="https://prometheus.io/">Prometheus</a> for monitoring, embraced <a href="https://kubernetes.io/">Kubernetes</a> and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."</p>
 
 <h2>Impact</h2>
- "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in <a href="https://grafana.com/">Grafana</a> dashboards provides great insight on your systems."
 
+<p>"Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in <a href="https://grafana.com/">Grafana</a> dashboards provides great insight on your systems."</p>
 
-</div>
+{{< case-studies/quote author="Edgaras Apšega, IT Systems Engineer, Adform" >}}
+"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier."  
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
+{{< case-studies/lead >}}
+Adform made <a href="https://www.wsj.com/articles/fake-ad-operation-used-to-steal-from-publishers-is-uncovered-1511290981">headlines</a> last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
+<p>With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a <a href="https://site.adform.com/media/85132/hyphbot_whitepaper_.pdf">white paper</a> revealing what it did—and others could too—to limit customers' exposure to the scam.</p>
 
+<p>In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>Adform made <a href="https://www.wsj.com/articles/fake-ad-operation-used-to-steal-from-publishers-is-uncovered-1511290981">headlines</a> last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day.</h2>With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a <a href="https://site.adform.com/media/85132/hyphbot_whitepaper_.pdf">white paper</a> revealing what it did—and others could too—to limit customers’ exposure to the scam. <br><br>
-In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.<br><br>
-The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."
+<p>The company has a large infrastructure: <a href="https://www.openstack.org/">OpenStack</a>-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company's growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn't have self-healing infrastructure."</p>
 
+{{< case-studies/quote
+  image="/images/case-studies/adform/banner3.jpg"
+  author="Edgaras Apšega, IT Systems Engineer, Adform"
+>}}
+"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it's open source, you can contribute."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/adform/banner3.jpg')">
-  <div class="banner3text">
-    "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."</p>
 
-The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."<br><br>
-A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.
-Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they’re still doing it."
-<br><br>
-The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."
+<p>A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.</p>
 
+<p>Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they're still doing it."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/adform/banner4.jpg')">
-  <div class="banner4text">
-"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Andrius Cibulskis, IT Systems Engineer, Adform</span>
-  </div>
-</div>
+<p>The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."</p>
 
-<section class="section5">
-<div class="fullcol">
-This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before. <br><br>
-The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines. <br><br>
-Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."
+{{< case-studies/quote
+  image="/images/case-studies/adform/banner4.jpg"
+  author="Andrius Cibulskis, IT Systems Engineer, Adform"
+>}}
+"Releases are really nice for them, because they just push their code to Git and that's it. They don't have to worry about their virtual machines anymore."  
+{{< /case-studies/quote >}}
 
+<p>This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before.</p>
 
+<p>The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines.</p>
 
-</div>
+<p>Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."</p>
 
-<div class="banner5">
-  <div class="banner5text">
- "I think that our company just started our cloud native journey. It seems like a huge road ahead, but we’re really happy that we joined it." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
-  </div>
-</div>
+{{< case-studies/quote author="Edgaras Apšega, IT Systems Engineer, Adform" >}}
+"I think that our company just started our cloud native journey. It seems like a huge road ahead, but we're really happy that we joined it."  
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they’re happy because they can easily inspect the containers."
-The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it’s cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we’re interested in is the <a href="https://github.com/virtual-kubelet/virtual-kubelet">Virtual Kubelet</a> that lets you spin up the working nodes on different clouds to do some computing."
-<br><br>
-Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we’re really happy that we joined it."
+<p>All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that's it. They don't have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they're happy because they can easily inspect the containers."</p>
 
+<p>The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it's cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we're interested in is the <a href="https://github.com/virtual-kubelet/virtual-kubelet">Virtual Kubelet</a> that lets you spin up the working nodes on different clouds to do some computing."</p>
 
-
-</div>
-
-</section>
+<p>Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we're really happy that we joined it."</p>
diff --git a/content/ko/case-studies/amadeus/index.html b/content/ko/case-studies/amadeus/index.html
index 8b6294d4f9..bd647003ec 100644
--- a/content/ko/case-studies/amadeus/index.html
+++ b/content/ko/case-studies/amadeus/index.html
@@ -1,105 +1,84 @@
 ---
 title: Amadeus Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_amadeus.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/amadeus/banner1.jpg
+heading_title_logo: /images/amadeus_logo.png
+subheading: >
+  Another Technical Evolution for a 30-Year-Old Company
+case_study_details:
+  - Company: Amadeus IT Group
+  - Location: Madrid, Spain
+  - Industry: Travel Technology
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/amadeus_logo.png" class="header_logo"><br> <div class="subhead">Another Technical Evolution for a 30-Year-Old Company
-</div></h1>
-</div>
-<div class="details">
-    Company &nbsp;<b>Amadeus IT Group</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Madrid, Spain</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Travel Technology</b>
-</div>
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-      In the past few years, Amadeus, which provides IT solutions to the travel industry around the world, found itself in need of a new platform for the 5,000 services supported by its service-oriented architecture. The 30-year-old company operates its own data center in Germany, and there were growing demands internally and externally for solutions that needed to be geographically dispersed. And more generally, "we had objectives of being even more highly available," says Eric Mountain, Senior Expert, Distributed Systems at Amadeus. Among the company’s goals: to increase automation in managing its infrastructure, optimize the distribution of workloads, use data center resources more efficiently, and adopt new technologies more easily.
-      </div>
-<div class="col2">
-  <h2>Solution</h2>
-      Mountain has been overseeing the company’s migration to <a href="http://kubernetes.io/">Kubernetes</a>, using <a href="https://www.openshift.org/">OpenShift</a> Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>’s enterprise container platform.
-<br><br>
+<h2>Challenge</h2>
+
+<p>In the past few years, Amadeus, which provides IT solutions to the travel industry around the world, found itself in need of a new platform for the 5,000 services supported by its service-oriented architecture. The 30-year-old company operates its own data center in Germany, and there were growing demands internally and externally for solutions that needed to be geographically dispersed. And more generally, "we had objectives of being even more highly available," says Eric Mountain, Senior Expert, Distributed Systems at Amadeus. Among the company's goals: to increase automation in managing its infrastructure, optimize the distribution of workloads, use data center resources more efficiently, and adopt new technologies more easily.</p>
+
+<h2>Solution</h2>
+
+<p>Mountain has been overseeing the company's migration to <a href="http://kubernetes.io/">Kubernetes</a>, using <a href="https://www.openshift.org/">OpenShift</a> Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>'s enterprise container platform.</p>
+
 <h2>Impact</h2>
-      One of the first projects the team deployed in Kubernetes was the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume. "It’s now handling in production several thousand transactions per second, and it’s deployed in multiple data centers throughout the world," says Mountain. "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."
-</div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "We want multi-data center capabilities, and we want them for our mainstream system as well. We didn’t think that we could achieve them with our existing system. We need new automation, things that Kubernetes and OpenShift bring."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Eric Mountain, Senior Expert, Distributed Systems at Amadeus IT Group</span>
-  </div>
-</div>
-<section class="section2">
+<p>One of the first projects the team deployed in Kubernetes was the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume. "It's now handling in production several thousand transactions per second, and it's deployed in multiple data centers throughout the world," says Mountain. "It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."</p>
 
-<div class="fullcol">
-    <h2>In his two decades at Amadeus, Eric Mountain has been the migrations guy. </h2>
-    Back in the day, he worked on the company’s move from Unix to Linux, and now he’s overseeing the journey to cloud native. "Technology just keeps changing, and we embrace it," he says. "We are celebrating our 30 years this year, and we continue evolving and innovating to stay cost-efficient and enhance everyone’s travel experience, without interrupting workflows for the customers who depend on our technology."<br><br>
-    That was the challenge that Amadeus—which provides IT solutions to the travel industry around the world, from flight searches to hotel bookings to customer feedback—faced in 2014. The technology team realized it was in need of a new platform for the 5,000 services supported by its service-oriented architecture.<br><br>
-    The tipping point occurred when they began receiving many requests, internally and externally, for solutions that needed to be geographically outside the company’s main data center in Germany. "Some requests were for running our applications on customer premises," Mountain says. "There were also new services we were looking to offer that required response time to the order of a few hundred milliseconds, which we couldn’t achieve with transatlantic traffic. Or at least, not without eating into a considerable portion of the time available to our applications for them to process individual queries."<br><br>
-    More generally, the company was interested in leveling up on high availability, increasing automation in managing infrastructure, optimizing the distribution of workloads and using data center resources more efficiently. "We have thousands and thousands of servers," says Mountain. "These servers are assigned roles, so even if the setup is highly automated, the machine still has a given role. It’s wasteful on many levels. For instance, an application doesn’t necessarily use the machine very optimally. Virtualization can help a bit, but it’s not a silver bullet. If that machine breaks, you still want to repair it because it has that role and you can’t simply say, ‘Well, I’ll bring in another machine and give it that role.’ It’s not fast. It’s not efficient. So we wanted the next level of automation."<br><br>
-</div>
-</section>
+{{< case-studies/quote author="Eric Mountain, Senior Expert, Distributed Systems at Amadeus IT Group" >}}
+"We want multi-data center capabilities, and we want them for our mainstream system as well. We didn't think that we could achieve them with our existing system. We need new automation, things that Kubernetes and OpenShift bring."
+{{< /case-studies/quote >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    "We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."
-  </div>
-</div>
+{{< case-studies/lead >}}
+In his two decades at Amadeus, Eric Mountain has been the migrations guy.
+{{< /case-studies/lead >}}
 
-<section class="section3">
-<div class="fullcol">
-  While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like <a href="https://www.python.org/">Python</a> and databases like <a href="https://www.couchbase.com/">Couchbase</a>, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.
-  <br><br>
-  All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of <a href="http://kubernetes.io/">Kubernetes</a> whatever happens to be missing from our point of view, or go with <a href="https://www.openshift.com/">OpenShift</a> and build whatever remains there."
-<br><br>
-  The team decided against building everything themselves—though they’d done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.
-<br><br>
-  Ultimately, they went with OpenShift Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>’s Kubernetes-based enterprise offering, instead of building on top of Kubernetes because "there was a lot of synergy between what we wanted and the way Red Hat was anticipating going with OpenShift," says Mountain. "They were clearly developing Kubernetes, and developing certain things ahead of time in OpenShift, which were important to us, such as more security."
-<br><br>
-  The hope was that those particular features would eventually be built into Kubernetes, and, in the case of security, Mountain feels that has happened. "We realize that there’s always a certain amount of automation that we will probably have to develop ourselves to compensate for certain gaps," says Mountain. "The less we do that, the better for us. We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."
-</div>
-</section>
+<p>Back in the day, he worked on the company's move from Unix to Linux, and now he's overseeing the journey to cloud native. "Technology just keeps changing, and we embrace it," he says. "We are celebrating our 30 years this year, and we continue evolving and innovating to stay cost-efficient and enhance everyone's travel experience, without interrupting workflows for the customers who depend on our technology."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."
-  </div>
-</div>
+<p>That was the challenge that Amadeus—which provides IT solutions to the travel industry around the world, from flight searches to hotel bookings to customer feedback—faced in 2014. The technology team realized it was in need of a new platform for the 5,000 services supported by its service-oriented architecture.</p>
 
-<section class="section4">
-<div class="fullcol">
-  The first project the team tackled was one that they knew had to run outside the data center in Germany. Because of the project’s needs, "We couldn’t rely only on the built-in Kubernetes service discovery; we had to layer on top of that an extra service discovery level that allows us to load balance at the operation level within our system," says Mountain. They also built a stream dedicated to monitoring, which at the time wasn’t offered in the Kubernetes or OpenShift ecosystem. Now that <a href="https://www.prometheus.io/">Prometheus</a> and other products are available, Mountain says the company will likely re-evaluate their monitoring system: "We obviously always like to leverage what Kubernetes and OpenShift can offer."
-<br><br>
-  The second project ended up going into production first: the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume and was deployed in public cloud. Launched in early 2016, it is "now handling in production several thousand transactions per second, and it’s deployed in multiple data centers throughout the world," says Mountain. "It’s not a migration of an existing workload; it’s a whole new workload that we couldn’t have done otherwise. [This platform] gives us access to market opportunities that we didn’t have before."
-<br><br>
-  Having been through this kind of technical evolution more than once, Mountain has advice on how to handle the cultural changes. "That’s one aspect that we can tackle progressively," he says. "We have to go on supplying our customers with new features on our pre-existing products, and we have to keep existing products working. So we can’t simply do absolutely everything from one day to the next. And we mustn’t sell it that way."
-<br><br>
-  The first order of business, then, is to pick one or two applications to demonstrate that the technology works. Rather than choosing a high-impact, high-risk project, Mountain’s team selected a smaller application that was representative of all the company’s other applications in its complexity: "We just made sure we picked something that’s complex enough, and we showed that it can be done."
-</div>
-</section>
+<p>The tipping point occurred when they began receiving many requests, internally and externally, for solutions that needed to be geographically outside the company's main data center in Germany. "Some requests were for running our applications on customer premises," Mountain says. "There were also new services we were looking to offer that required response time to the order of a few hundred milliseconds, which we couldn't achieve with transatlantic traffic. Or at least, not without eating into a considerable portion of the time available to our applications for them to process individual queries."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don’t think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."
-  </div>
-</div>
+<p>More generally, the company was interested in leveling up on high availability, increasing automation in managing infrastructure, optimizing the distribution of workloads and using data center resources more efficiently. "We have thousands and thousands of servers," says Mountain. "These servers are assigned roles, so even if the setup is highly automated, the machine still has a given role. It's wasteful on many levels. For instance, an application doesn't necessarily use the machine very optimally. Virtualization can help a bit, but it's not a silver bullet. If that machine breaks, you still want to repair it because it has that role and you can't simply say, 'Well, I'll bring in another machine and give it that role.' It's not fast. It's not efficient. So we wanted the next level of automation."</p>
 
-<section class="section5">
-<div class="fullcol">
-  Next comes convincing people. "On the operations side and on the R&D side, there will be people who say quite rightly, ‘There is a system, and it works, so why change?’" Mountain says. "The only thing that really convinces people is showing them the value." For Amadeus, people realized that the Airline Cloud Availability product could not have been made available on the public cloud with the company’s existing system. The question then became, he says, "Do we go into a full-blown migration? Is that something that is justified?"
-<br><br>
-  "The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don’t think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."
-<br><br>
-  So how do you get everyone on board? "Make sure you have good links between your R&D and your operations," he says. "Also make sure you’re going to talk early on to the investors and stakeholders. Figure out what it is that they will be expecting from you, that will convince them or not, that this is the right way for your company."
-<br><br>
-  His other advice is simply to make the technology available for people to try it. "Kubernetes and OpenShift Origin are open source software, so there’s no complicated license key for the evaluation period and you’re not limited to 30 days," he points out. "Just go and get it running." Along with that, he adds, "You’ve got to be prepared to rethink how you do things. Of course making your applications as cloud native as possible is how you’ll reap the most benefits: 12 factors, CI/CD, which is continuous integration, continuous delivery, but also continuous deployment."
-<br><br>
-  And while they explore that aspect of the technology, Mountain and his team will likely be practicing what he preaches to others taking the cloud native journey. "See what happens when you break it, because it’s important to understand the limits of the system," he says. Or rather, he notes, the advantages of it. "Breaking things on Kube is actually one of the nice things about it—it recovers. It’s the only real way that you’ll see that you might be able to do things."
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/amadeus/banner3.jpg" >}}
+"We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."
+{{< /case-studies/quote >}}
+
+<p>While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like <a href="https://www.python.org/">Python</a> and databases like <a href="https://www.couchbase.com/">Couchbase</a>, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.</p>
+
+<p>All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of <a href="http://kubernetes.io/">Kubernetes</a> whatever happens to be missing from our point of view, or go with <a href="https://www.openshift.com/">OpenShift</a> and build whatever remains there."</p>
+
+<p>The team decided against building everything themselves—though they'd done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.</p>
+
+<p>Ultimately, they went with OpenShift Container Platform, <a href="https://www.redhat.com/en">Red Hat</a>'s Kubernetes-based enterprise offering, instead of building on top of Kubernetes because "there was a lot of synergy between what we wanted and the way Red Hat was anticipating going with OpenShift," says Mountain. "They were clearly developing Kubernetes, and developing certain things ahead of time in OpenShift, which were important to us, such as more security."</p>
+
+<p>The hope was that those particular features would eventually be built into Kubernetes, and, in the case of security, Mountain feels that has happened. "We realize that there's always a certain amount of automation that we will probably have to develop ourselves to compensate for certain gaps," says Mountain. "The less we do that, the better for us. We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."</p>
+
+{{< case-studies/quote image="/images/case-studies/amadeus/banner4.jpg" >}}
+"It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."
+{{< /case-studies/quote >}}
+
+<p>The first project the team tackled was one that they knew had to run outside the data center in Germany. Because of the project's needs, "We couldn't rely only on the built-in Kubernetes service discovery; we had to layer on top of that an extra service discovery level that allows us to load balance at the operation level within our system," says Mountain. They also built a stream dedicated to monitoring, which at the time wasn't offered in the Kubernetes or OpenShift ecosystem. Now that <a href="https://www.prometheus.io/">Prometheus</a> and other products are available, Mountain says the company will likely re-evaluate their monitoring system: "We obviously always like to leverage what Kubernetes and OpenShift can offer."
+</p>
+
+<p>The second project ended up going into production first: the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume and was deployed in public cloud. Launched in early 2016, it is "now handling in production several thousand transactions per second, and it's deployed in multiple data centers throughout the world," says Mountain. "It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."</p>
+
+<p>Having been through this kind of technical evolution more than once, Mountain has advice on how to handle the cultural changes. "That's one aspect that we can tackle progressively," he says. "We have to go on supplying our customers with new features on our pre-existing products, and we have to keep existing products working. So we can't simply do absolutely everything from one day to the next. And we mustn't sell it that way."</p>
+
+<p>The first order of business, then, is to pick one or two applications to demonstrate that the technology works. Rather than choosing a high-impact, high-risk project, Mountain's team selected a smaller application that was representative of all the company's other applications in its complexity: "We just made sure we picked something that's complex enough, and we showed that it can be done."</p>
+
+{{< case-studies/quote >}}
+"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don't think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."
+{{< /case-studies/quote >}}
+
+<p>Next comes convincing people. "On the operations side and on the R&D side, there will be people who say quite rightly, 'There is a system, and it works, so why change?'" Mountain says. "The only thing that really convinces people is showing them the value." For Amadeus, people realized that the Airline Cloud Availability product could not have been made available on the public cloud with the company's existing system. The question then became, he says, "Do we go into a full-blown migration? Is that something that is justified?"</p>
+
+<p>"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don't think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."</p>
+
+<p>So how do you get everyone on board? "Make sure you have good links between your R&D and your operations," he says. "Also make sure you're going to talk early on to the investors and stakeholders. Figure out what it is that they will be expecting from you, that will convince them or not, that this is the right way for your company."</p>
+
+<p>His other advice is simply to make the technology available for people to try it. "Kubernetes and OpenShift Origin are open source software, so there's no complicated license key for the evaluation period and you're not limited to 30 days," he points out. "Just go and get it running." Along with that, he adds, "You've got to be prepared to rethink how you do things. Of course making your applications as cloud native as possible is how you'll reap the most benefits: 12 factors, CI/CD, which is continuous integration, continuous delivery, but also continuous deployment."</p>
+
+<p>And while they explore that aspect of the technology, Mountain and his team will likely be practicing what he preaches to others taking the cloud native journey. "See what happens when you break it, because it's important to understand the limits of the system," he says. Or rather, he notes, the advantages of it. "Breaking things on Kube is actually one of the nice things about it—it recovers. It's the only real way that you'll see that you might be able to do things."</p>
diff --git a/content/ko/case-studies/ancestry/index.html b/content/ko/case-studies/ancestry/index.html
index a992a284ac..8cab3c19c6 100644
--- a/content/ko/case-studies/ancestry/index.html
+++ b/content/ko/case-studies/ancestry/index.html
@@ -1,117 +1,92 @@
 ---
 title: Ancestry Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_ancestry.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ancestry/banner1.jpg
+heading_title_logo: /images/ancestry_logo.png
+subheading: >
+  Digging Into the Past With New Technology
+case_study_details:
+  - Company: Ancestry
+  - Location: Lehi, Utah
+  - Industry: Internet Company, Online Services
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/ancestry_logo.png" width="22%" style="margin-bottom:-12px;margin-left:3px;"><br> <div class="subhead">Digging Into the Past With New Technology</div></h1>
-
-</div>
-
-<div class="details">
-  Company &nbsp;<b>Ancestry</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Lehi, Utah</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Internet Company, Online Services</b>
-</div>
-
-<hr>
-
-<section class="section1">
-<div class="cols">
-<div class="col1">
-
 <h2>Challenge</h2>
-Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. <a href="https://www.ancestry.com">Ancestry</a> currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, <a href="https://www.ancestry.com">ancestry.com</a>, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our&nbsp;products."
 
-<br>
+<p>Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. <a href="https://www.ancestry.com">Ancestry</a> currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, <a href="https://www.ancestry.com">ancestry.com</a>, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our&nbsp;products."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="col2">
-  <h2>Solution</h2>
+<p>The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.</p>
 
-  The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.<br>
-<br>
 <h2>Impact</h2>
-  "Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
-</div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'"<br><br><span style="font-size:16px">- PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY</span>
-  </div>
-</div>
+<p>"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We've truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>It started with a Shaky Leaf.</h2>
+{{< case-studies/quote author="PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY" >}}
+"At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'"  
+{{< /case-studies/quote >}}
 
-    Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.<br><br>
-    So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on <a href="https://kubernetes.io">Kubernetes</a>, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."<br><br>
-    And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."<br><br>
-    The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."
-</div>
-</section>
+{{< case-studies/lead >}}
+It started with a Shaky Leaf.
+{{< /case-studies/lead >}}
 
-<div class="banner3">
-  <div class="banner3text">
+<p>Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.</p>
+
+<p>So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on <a href="https://kubernetes.io">Kubernetes</a>, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."</p>
+
+<p>And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."</p>
+
+<p>The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."</p>
+
+{{< case-studies/quote image="/images/case-studies/ancestry/banner3.jpg" >}}
 "And when it [Kubernetes] went live smoothly in early 2016, 'our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes,' MacKay adds. 'The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation.'"
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section3">
-<div class="fullcol">
-  That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like <a href="https://www.java.com/en/">Java</a> and <a href="https://www.python.org">Python</a> on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.<br><br>
-  His team looked at orchestration platforms offered by <a href="https://docs.docker.com/compose/">Docker Compose</a>, <a href="http://mesos.apache.org">Mesos</a> and <a href="https://www.openstack.org/software/">OpenStack</a>, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."<br><br>
-  <div class="quote">
-  Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since."</div><br>
-  Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."<br><br>
-  Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."<br><br>
-  Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.
-<br><br>
-</div>
-</section>
+<p>That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like <a href="https://www.java.com/en/">Java</a> and <a href="https://www.python.org">Python</a> on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.</p>
 
-<div class="banner4">
-<div class="banner4text">
+<p>His team looked at orchestration platforms offered by <a href="https://docs.docker.com/compose/">Docker Compose</a>, <a href="http://mesos.apache.org">Mesos</a> and <a href="https://www.openstack.org/software/">OpenStack</a>, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."</p>
 
+{{< case-studies/lead >}}
+Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since."
+{{< /case-studies/lead >}}
+
+<p>Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."</p>
+
+<p>Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."</p>
+
+<p>Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.
+</p>
+
+{{< case-studies/quote image="/images/case-studies/ancestry/banner4.jpg" >}}
 "The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology."
+{{< /case-studies/quote >}}
 
-</div>
-</div>
+<p>With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."</p>
 
-<section class="section4">
-<div class="fullcol">
-  With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."<br><br>
-  The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."<br><br>
-  A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."<br><br>
-  The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."
-</div>
-</section>
+<p>The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "... 'I believe in Kubernetes. I believe in containerization. I think
-    if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about,
-    and it'll&nbsp;go&nbsp;forward.'"
-  </div>
-</div>
+<p>A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."</p>
 
-<section class="section5">
-<div class="fullcol">
+<p>The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."</p>
 
+{{< case-studies/quote >}}
+"... 'I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll&nbsp;go&nbsp;forward.'"
+{{< /case-studies/quote >}}
 
-Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."<br><br>
-That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."<br><br>
-As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending <a href="https://www.meetup.com/Utah-Kubernetes-Meetup/">meetups</a> to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."
-<br><br>When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."<br><br>
-With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.<br><br>
-"I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."<br><br>
-He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"
+<p>Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."</p>
 
+<p>That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."</p>
 
-</div>
-</section>
+<p>As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending <a href="https://www.meetup.com/Utah-Kubernetes-Meetup/">meetups</a> to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."</p>
+
+<p>When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."</p>
+
+<p>With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.</p>
+
+<p>"I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."</p>
+
+<p>He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"</p>
diff --git a/content/ko/case-studies/blablacar/index.html b/content/ko/case-studies/blablacar/index.html
index 2d55ffb8d0..e6537a672f 100644
--- a/content/ko/case-studies/blablacar/index.html
+++ b/content/ko/case-studies/blablacar/index.html
@@ -1,98 +1,85 @@
 ---
 title: BlaBlaCar Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_blablacar.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/blablacar/banner1.jpg
+heading_title_logo: /images/blablacar_logo.png
+subheading: >
+  Turning to Containerization to Support Millions of Rideshares
+case_study_details:
+  - Company: BlaBlaCar
+  - Location: Paris, France
+  - Industry: Ridesharing Company
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/blablacar_logo.png" class="header_logo"><br /> <div class="subhead">Turning to Containerization to Support Millions of Rideshares</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The world's largest long-distance carpooling community, <a href="https://www.blablacar.com/">BlaBlaCar</a>, connects 40 million members across 22 countries. The company has been experiencing exponential growth since 2012 and needed its infrastructure to keep up. "When you're thinking about doubling the number of servers, you start thinking, 'What should I do to be more efficient?'" says Simon Lallemand, Infrastructure Engineer at BlaBlaCar. "The answer is not to hire more and more people just to deal with the servers and installation." The team knew they had to scale the platform, but wanted to stay on their own bare metal servers.</p>
 
-<div class="details">
-    Company &nbsp;<b>BlaBlaCar</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Paris, France</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Ridesharing Company</b>
-</div>
+<h2>Solution</h2>
 
-<hr />
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The world’s largest long-distance carpooling community, <a href="https://www.blablacar.com/">BlaBlaCar</a>, connects 40 million members across 22 countries. The company has been experiencing exponential growth since 2012 and needed its infrastructure to keep up. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Simon Lallemand, Infrastructure Engineer at BlaBlaCar. "The answer is not to hire more and more people just to deal with the servers and installation." The team knew they had to scale the platform, but wanted to stay on their own bare metal servers.
-    <br />
-    <br />
-      <h2>Solution</h2>
-        Opting not to shift to cloud virtualization or use a private cloud on their own servers, the BlaBlaCar team became early adopters of containerization, using the CoreOs runtime <a href="https://coreos.com/rkt">rkt</a>, initially deployed using <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> cluster manager. Last year, the company switched to <a href="http://kubernetes.io/">Kubernetes</a> orchestration, and now also uses <a href="https://prometheus.io/">Prometheus</a> for monitoring.
-      </div>
+<p>Opting not to shift to cloud virtualization or use a private cloud on their own servers, the BlaBlaCar team became early adopters of containerization, using the CoreOs runtime <a href="https://coreos.com/rkt">rkt</a>, initially deployed using <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> cluster manager. Last year, the company switched to <a href="http://kubernetes.io/">Kubernetes</a> orchestration, and now also uses <a href="https://prometheus.io/">Prometheus</a> for monitoring.</p>
 
-<div class="col2">
 <h2>Impact</h2>
-        "Before using containers, it would take sometimes a day, sometimes two, just to create a new service," says Lallemand. "With all the tooling that we made around the containers, copying a new service now is a matter of minutes. It’s really a huge gain. We are better at capacity planning in our data center because we have fewer constraints due to this abstraction between the services and the hardware we run on. For the developers, it also means they can focus only on the features that they’re developing, and not on the infrastructure."
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "When you’re switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br />- Simon Lallemand, Infrastructure Engineer at BlaBlaCar</span>
-  </div>
-</div>
 
-<section class="section2">
-<div class="fullcol">
-  <h2>For the 40 million users of <a href="https://www.blablacar.com/">BlaBlaCar</a>, it’s easy to find strangers headed in the same direction to share rides and costs. You can even choose how much "bla bla" chatter you want from a long-distance ride mate.</h2>
-  Behind the scenes, though, the infrastructure was falling woefully behind the rider community’s exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."<br /><br />
-  By 2015, the company had about 50 bare metal servers. The team was using a <a href="https://www.mysql.com/">MySQL</a> database and <a href="http://php.net/">PHP</a>, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, <a href="https://www.chef.io/chef/">Chef</a>, but had little automation in its process. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."<br /><br />
-  Instead, BlaBlaCar began its cloud-native journey but wasn’t sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn’t want to go to virtualization on premise.<br /><br />
-  The solution: containerization. This was early 2015 and containers were still relatively new. "It was a bold move at the time," says Lallemand. "We decided that the next servers that we would buy in the new data center would all be the same model, so we could outsource the maintenance of the servers. And we decided to go with containers and with <a href="https://coreos.com/">CoreOS</a> Container Linux as an abstraction for this hardware. It seemed future-proof to go with containers because we could see what companies were already doing with containers."
-</div>
-</section>
+<p>"Before using containers, it would take sometimes a day, sometimes two, just to create a new service," says Lallemand. "With all the tooling that we made around the containers, copying a new service now is a matter of minutes. It's really a huge gain. We are better at capacity planning in our data center because we have fewer constraints due to this abstraction between the services and the hardware we run on. For the developers, it also means they can focus only on the features that they're developing, and not on the infrastructure."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "With all the tooling that we made around the containers, copying a new service is a matter of minutes. It’s a huge gain. For the developers, it means they can focus only on the features that they’re developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
-  </div>
-</div>
+{{< case-studies/quote author="Simon Lallemand, Infrastructure Engineer at BlaBlaCar" >}}
+"When you're switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before."
+{{< /case-studies/quote >}}
 
-<section class="section3">
-<div class="fullcol">
-    Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with <a href="https://www.docker.com/">Docker</a> but decided to go with <a href="https://coreos.com/rkt">rkt</a>. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time,  the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.<br /><br />
-    Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand’s team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you’re focused on your product sometimes you forget if it’s really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."<br /><br />
-    After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as <a href="https://github.com/blablacar/dgr">dgr</a>, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools <a href="https://github.com/airbnb/nerve">Nerve</a> and <a href="http://airbnb.io/projects/synapse/">Synapse</a>; their versions, <a href="https://github.com/blablacar/go-nerve">Go-Nerve</a> and <a href="https://github.com/blablacar/go-synapse">Go-Synapse</a>, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.<br /><br />
-    At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It’s now at 100 percent.) "It’s a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."<br /><br />
-    In the middle of that peak season for carpooling, everything worked well. "The biggest impact that we had was for the deployment of new services," says Lallemand. "Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it’s really a huge gain. For the developers, it means they can focus only on the features that they’re developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
-</div>
-</section>
+{{< case-studies/lead >}}
+For the 40 million users of <a href="https://www.blablacar.com/">BlaBlaCar</a>, it's easy to find strangers headed in the same direction to share rides and costs. You can even choose how much "bla bla" chatter you want from a long-distance ride mate.
+{{< /case-studies/lead >}}
 
-<div class="banner4">
-  <div class="banner4text">
-    "We realized that there was a really strong community around it [Kubernetes], which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes."
-  </div>
-</div>
+<p>Behind the scenes, though, the infrastructure was falling woefully behind the rider community's exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."</p>
 
-<section class="section4">
-<div class="fullcol">
-    In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> tool from CoreOS to deploy their containers. (They did build a tool called <a href="https://github.com/blablacar/ggn">GGN</a>, which they’ve open-sourced, to make it more manageable for their system engineers to use.)<br /><br />
-    Still, the team knew that they’d want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don’t want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in <a href="http://kubernetes.io/">Kubernetes</a>, which had just begun supporting rkt implementation.<br /><br />
-    After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using <a href="https://prometheus.io/">Prometheus</a>, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.<br /><br />
-    BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It’s really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."<br /><br />
-    The team is particularly happy that they’re now able to plan capacity better in the company’s data center. "We have fewer constraints since we have this abstraction between the services and the hardware we run on," says Lallemand. "If we lose a server because there’s a hardware problem on it, we just move the containers onto another server. It’s much more efficient. We do that by just changing a line in the configuration file. And with Kubernetes, it should be automatic, so we would have nothing to do."
-</div>
-</section>
+<p>By 2015, the company had about 50 bare metal servers. The team was using a <a href="https://www.mysql.com/">MySQL</a> database and <a href="http://php.net/">PHP</a>, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, <a href="https://www.chef.io/chef/">Chef</a>, but had little automation in its process. "When you're thinking about doubling the number of servers, you start thinking, 'What should I do to be more efficient?'" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "If we lose a server because there’s a hardware problem on it, we just move the containers onto another server. It’s much more efficient. We do that by just changing a line in the configuration file. With Kubernetes, it should be automatic, so we would have nothing to do."
-  </div>
-</div>
+<p>Instead, BlaBlaCar began its cloud-native journey but wasn't sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn't want to go to virtualization on premise.</p>
 
-<section class="section5">
-<div class="fullcol">
-    And these advances ultimately trickle down to BlaBlaCar’s users. "We have improved availability overall on our website," says Lallemand. "When you’re switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."<br /><br />
-    Within BlaBlaCar’s technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different ‘tribes’—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster." <br /><br />
-    This DevOps transformation turned out to be a positive one for the company’s staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants." <br /><br />
-    With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don’t say microservices because they’re not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have." <br /><br />
-    When Lallemand speaks to other European companies curious about what BlaBlaCar has done with its infrastructure, he tells them to come along for the ride. "I tell them that it’s such a pleasure to deal with the infrastructure that we have today compared to what we had before," he says. "They just need to keep in mind their real motive, whether it’s flexibility in development or reliability or so on, and then go step by step towards reaching those objectives. That’s what we’ve done. It’s important not to do technology for the sake of technology. Do it for a purpose. Our focus was on helping the developers."
-</div>
-</section>
+<p>The solution: containerization. This was early 2015 and containers were still relatively new. "It was a bold move at the time," says Lallemand. "We decided that the next servers that we would buy in the new data center would all be the same model, so we could outsource the maintenance of the servers. And we decided to go with containers and with <a href="https://coreos.com/">CoreOS</a> Container Linux as an abstraction for this hardware. It seemed future-proof to go with containers because we could see what companies were already doing with containers."</p>
+
+{{< case-studies/quote image="/images/case-studies/blablacar/banner3.jpg">}}
+"With all the tooling that we made around the containers, copying a new service is a matter of minutes. It's a huge gain. For the developers, it means they can focus only on the features that they're developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
+{{< /case-studies/quote >}}
+
+<p>Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with <a href="https://www.docker.com/">Docker</a> but decided to go with <a href="https://coreos.com/rkt">rkt</a>. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time,  the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.</p>
+
+<p>Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand's team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you're focused on your product sometimes you forget if it's really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."</p>
+
+<p>After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as <a href="https://github.com/blablacar/dgr">dgr</a>, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools <a href="https://github.com/airbnb/nerve">Nerve</a> and <a href="http://airbnb.io/projects/synapse/">Synapse</a>; their versions, <a href="https://github.com/blablacar/go-nerve">Go-Nerve</a> and <a href="https://github.com/blablacar/go-synapse">Go-Synapse</a>, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.</p>
+
+<p>At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It's now at 100 percent.) "It's a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."</p>
+
+<p>In the middle of that peak season for carpooling, everything worked well. "The biggest impact that we had was for the deployment of new services," says Lallemand. "Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it's really a huge gain. For the developers, it means they can focus only on the features that they're developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."</p>
+
+{{< case-studies/quote image="/images/case-studies/blablacar/banner4.jpg" >}}
+"We realized that there was a really strong community around it [Kubernetes], which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> tool from CoreOS to deploy their containers. (They did build a tool called <a href="https://github.com/blablacar/ggn">GGN</a>, which they've open-sourced, to make it more manageable for their system engineers to use.)</p>
+
+<p>Still, the team knew that they'd want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don't want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in <a href="http://kubernetes.io/">Kubernetes</a>, which had just begun supporting rkt implementation.</p>
+
+<p>After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using <a href="https://prometheus.io/">Prometheus</a>, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.</p>
+
+<p>BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It's really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."</p>
+
+<p>The team is particularly happy that they're now able to plan capacity better in the company's data center. "We have fewer constraints since we have this abstraction between the services and the hardware we run on," says Lallemand. "If we lose a server because there's a hardware problem on it, we just move the containers onto another server. It's much more efficient. We do that by just changing a line in the configuration file. And with Kubernetes, it should be automatic, so we would have nothing to do."</p>
+
+{{< case-studies/quote >}}
+"If we lose a server because there's a hardware problem on it, we just move the containers onto another server. It's much more efficient. We do that by just changing a line in the configuration file. With Kubernetes, it should be automatic, so we would have nothing to do."
+{{< /case-studies/quote >}}
+
+<p>And these advances ultimately trickle down to BlaBlaCar's users. "We have improved availability overall on our website," says Lallemand. "When you're switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."</p>
+
+<p>Within BlaBlaCar's technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different 'tribes'—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster."</p>
+
+<p>This DevOps transformation turned out to be a positive one for the company's staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants."</p>
+
+<p>With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don't say microservices because they're not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have."</p>
+
+<p>When Lallemand speaks to other European companies curious about what BlaBlaCar has done with its infrastructure, he tells them to come along for the ride. "I tell them that it's such a pleasure to deal with the infrastructure that we have today compared to what we had before," he says. "They just need to keep in mind their real motive, whether it's flexibility in development or reliability or so on, and then go step by step towards reaching those objectives. That's what we've done. It's important not to do technology for the sake of technology. Do it for a purpose. Our focus was on helping the developers."</p>
diff --git a/content/ko/case-studies/blackrock/index.html b/content/ko/case-studies/blackrock/index.html
index 6bef0ec708..725d6bc057 100644
--- a/content/ko/case-studies/blackrock/index.html
+++ b/content/ko/case-studies/blackrock/index.html
@@ -1,112 +1,83 @@
 ---
 title: BlackRock Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_blackrock.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/blackrock/banner1.jpg
+heading_title_logo: /images/blackrock_logo.png
+subheading: >
+  Rolling Out Kubernetes in Production in 100 Days
+case_study_details:
+  - Company: BlackRock
+  - Location: New York, NY
+  - Industry: Financial Services
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY: <img src="/images/blackrock_logo.png" class="header_logo"><br>
-    <div class="subhead">Rolling Out Kubernetes in Production in 100 Days</div>
-  </h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The world's largest asset manager, <a href="https://www.blackrock.com/investing">BlackRock</a> operates a very controlled static deployment scheme, which has allowed for scalability over the years. But in their data science division, there was a need for more dynamic access to resources. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Michael Francis, a Managing Director in BlackRock's  Product Group, which runs the company's investment management platform. "Managing complex Python installations on users' desktops is really hard because everyone ends up with slightly different environments. We have existing environments that do these things, but we needed to make it real, expansive and scalable. Being able to spin that up on demand, tear it down, make that much more dynamic, became a critical thought process for us. It's not so much that we had to solve our main core production problem, it's how do we extend that? How do we evolve?"</p>
 
-<div class="details">
-    Company &nbsp;<b>BlackRock</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, NY</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Financial Services</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>Drawing from what they learned during a pilot done last year using <a href="https://www.docker.com">Docker</a> environments, Francis put together a cross-sectional team of 20 to build an investor research web app using <a href="https://kubernetes.io">Kubernetes</a> with the goal of getting it into production within one quarter.</p>
 
-<section class="section1">
-
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The world’s largest asset manager, <a href="https://www.blackrock.com/investing">BlackRock</a> operates a very controlled static deployment scheme, which has allowed for scalability over the years. But in their data science division, there was a need for more dynamic access to resources. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Michael Francis, a Managing Director in BlackRock’s  Product Group, which runs the company’s investment management platform. "Managing complex Python installations on users’ desktops is really hard because everyone ends up with slightly different environments. We have existing environments that do these things, but we needed to make it real, expansive and scalable. Being able to spin that up on demand, tear it down, make that much more dynamic, became a critical thought process for us. It’s not so much that we had to solve our main core production problem, it’s how do we extend that? How do we evolve?"
-      </div>
-
-<div class="col2">
-  <h2>Solution</h2>
-    Drawing from what they learned during a pilot done last year using <a href="https://www.docker.com">Docker</a> environments, Francis put together a cross-sectional team of 20 to build an investor research web app using <a href="https://kubernetes.io">Kubernetes</a> with the goal of getting it into production within one quarter.
-<br><br>
 <h2>Impact</h2>
-        "Our goal was: How do you give people tools rapidly without having to install them on their desktop?" says Francis. And the team hit the goal within 100 days. Francis is pleased with the results and says, "We’re going to use this infrastructure for lots of other application workloads as time goes on. It’s not just data science; it’s this style of application that needs the dynamism. But I think we’re 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues. What’s interesting is that just having this technology there is changing the way our developers are starting to think about their future development."
 
-</div>
-</div>
+<p>"Our goal was: How do you give people tools rapidly without having to install them on their desktop?" says Francis. And the team hit the goal within 100 days. Francis is pleased with the results and says, "We're going to use this infrastructure for lots of other application workloads as time goes on. It's not just data science; it's this style of application that needs the dynamism. But I think we're 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues. What's interesting is that just having this technology there is changing the way our developers are starting to think about their future development."</p>
 
-</section>
+{{< case-studies/quote author="Michael Francis, Managing Director, BlackRock">}}
+"My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don't have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."
+{{< /case-studies/quote >}}
 
-<div class="banner2">
-  <div class="banner2text">
-    "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don’t have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Michael Francis, Managing Director, BlackRock</span>
-  </div>
-</div>
+<p>One of the management objectives for BlackRock's  Product Group employees in 2017 was to "build cool stuff." Led by Managing Director Michael Francis, a cross-sectional group of 20 did just that: They rolled out a full production Kubernetes environment and released a new investor research web app on it. In 100 days.</p>
 
-<section class="section2">
+<p>For a company that's the world's largest asset manager, "just equipment procurement can take 100 days sometimes, let alone from inception to delivery," says Karl Wieman, a Senior System Administrator. "It was an aggressive schedule. But it moved the dial." In fact, the project achieved two goals: It solved a business problem (creating the needed web app) as well as provided real-world, in-production experience with Kubernetes, a cloud-native technology that the company was eager to explore. "It's not so much that we had to solve our main core production problem, it's how do we extend that? How do we evolve?" says Francis. The ultimate success of this project, beyond delivering the app, lies in the fact that "we've managed to integrate a radically new thought process into a controlled infrastructure that we didn't want to change."</p>
 
-<div class="fullcol">
-  One of the management objectives for BlackRock’s  Product Group employees in 2017 was to "build cool stuff." Led by Managing Director Michael Francis, a cross-sectional group of 20 did just that: They rolled out a full production Kubernetes environment and released a new investor research web app on it. In 100 days.<br><br>
-  For a company that’s the world’s largest asset manager, "just equipment procurement can take 100 days sometimes, let alone from inception to delivery," says Karl Wieman, a Senior System Administrator. "It was an aggressive schedule. But it moved the dial."
-  In fact, the project achieved two goals: It solved a business problem (creating the needed web app) as well as provided real-world, in-production experience with Kubernetes, a cloud-native technology that the company was eager to explore. "It’s not so much that we had to solve our main core production problem, it’s how do we extend that? How do we evolve?" says Francis. The ultimate success of this project, beyond delivering the app, lies in the fact that "we’ve managed to integrate a radically new thought process into a controlled infrastructure that we didn’t want to change."<br><br>
-  After all, in its three decades of existence, BlackRock has "a very well-established environment for managing our compute resources," says Francis. "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that’s very cloudish in concept. We’re able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."<br><br>
-  Though that works well for the core production, the company has found that some data science workloads require more dynamic access to resources. "It’s a very bursty process," says Francis, who is head of data for the company’s Aladdin investment management platform division.<br><br>
-  Aladdin, which connects the people, information and technology needed for money management in real time, is used internally and is also sold as a platform to other asset managers and insurance companies. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Francis. But "managing complex Python installations on users’ desktops is really hard because everyone ends up with slightly different environments. Docker allows us to flatten that environment."
-</div>
-</section>
+<p>After all, in its three decades of existence, BlackRock has "a very well-established environment for managing our compute resources," says Francis. "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that's very cloudish in concept. We're able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that’s very cloudish in concept. We’re able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."
-  </div>
-</div>
+<p>Though that works well for the core production, the company has found that some data science workloads require more dynamic access to resources. "It's a very bursty process," says Francis, who is head of data for the company's Aladdin investment management platform division.</p>
 
-<section class="section3">
-<div class="fullcol">
-  Still, challenges remain. "If you have a shared cluster, you get this storming herd problem where everyone wants to do the same thing at the same time," says Francis. "You could put limits on it, but you’d have to build an infrastructure to define limits for our processes, and the Python notebooks weren’t really designed for that. We have existing environments that do these things, but we needed to make it real, expansive, and scalable. Being able to spin that up on demand, tear it down, and make that much more dynamic, became a critical thought process for us."<br><br>
-  Made up of managers from technology, infrastructure, production operations, development and information security, Francis’s team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using <a href="https://www.ansible.com">Ansible</a> and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don’t understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn’t build anywhere near the amount we thought we were going to end up building."<br><br>
-  In search of a solution in which they could manage usage on a user-by-user level, Francis’s team gravitated to Red Hat’s <a href="https://www.openshift.com">OpenShift</a> Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years’ time, in some form. And right now, in this space, Kubernetes feels like the one that’s going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that’s an indicator of the momentum."<br><br>
-  Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock’s existing framework. "It’s about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"<br><br>
-  The first (anticipated) speed bump was working around issues behind BlackRock’s corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn’t necessarily work." The team ran into these types of problems using <a href="/docs/getting-started-guides/minikube/">Minikube</a> and did a few small pushes back to the open source project.
+<p>Aladdin, which connects the people, information and technology needed for money management in real time, is used internally and is also sold as a platform to other asset managers and insurance companies. "We want to be able to give every investor access to data science, meaning <a href="https://www.python.org">Python</a> notebooks, or even something much more advanced, like a MapReduce engine based on <a href="https://spark.apache.org">Spark</a>," says Francis. But "managing complex Python installations on users' desktops is really hard because everyone ends up with slightly different environments. Docker allows us to flatten that environment."</p>
 
+{{< case-studies/quote image="/images/case-studies/blackrock/banner3.jpg">}}
+"We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that's very cloudish in concept. We're able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>Still, challenges remain. "If you have a shared cluster, you get this storming herd problem where everyone wants to do the same thing at the same time," says Francis. "You could put limits on it, but you'd have to build an infrastructure to define limits for our processes, and the Python notebooks weren't really designed for that. We have existing environments that do these things, but we needed to make it real, expansive, and scalable. Being able to spin that up on demand, tear it down, and make that much more dynamic, became a critical thought process for us."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "Typically we make technology choices that we believe are going to be here in 5-10 years’ time, in some form. And right now, in this space, Kubernetes feels like the one that’s going to be there."
-  </div>
-</div>
+<p>Made up of managers from technology, infrastructure, production operations, development and information security, Francis's team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using <a href="https://www.ansible.com">Ansible</a> and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don't understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn't build anywhere near the amount we thought we were going to end up building."</p>
 
-<section class="section4">
-<div class="fullcol">
-  There were also questions about service discovery. "You can think of Aladdin as a cloud of services with APIs between them that allows us to build applications rapidly," says Francis. "It’s all on a proprietary message bus, which gives us all sorts of advantages but at the same time, how does that play in a third party [platform]?"<br><br>
-  Another issue they had to navigate was that in BlackRock’s existing system, the messaging protocol has different instances in the different development, test and production environments. While Kubernetes enables a more DevOps-style model, it didn’t make sense for BlackRock. "I think what we are very proud of is that the ability for us to push into production is still incredibly rapid in this [new] infrastructure, but we have the control points in place, and we didn’t have to disrupt everything," says Francis. "A lot of the cost of this development was thinking how best to leverage our internal tools. So it was less costly than we actually thought it was going to be."<br><br>
-  The project leveraged tools associated with the messaging bus, for example. "The way that the Kubernetes cluster will talk to our internal messaging platform is through a gateway program, and this gateway program already has built-in checks and throttles," says Morris. "We can use them to control and potentially throttle the requests coming in from Kubernetes’s very elastic infrastructure to the production infrastructure. We’ll continue to go in that direction. It enables us to scale as we need to from the operational perspective."<br><br>
-  The solution also had to be complementary with BlackRock’s centralized operational support team structure. "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools," Morris explains. "That means that I don’t need to hire more people."<br><br>
-  With those points established, the team created a procedure for the project: "We rolled this out first to a development environment, then moved on to a testing environment and then eventually to two production environments, in that sequential order," says Maskallis. "That drove a lot of our learning curve. We have all these moving parts, the software components on the infrastructure side, the software components with Kubernetes directly, the interconnectivity with the rest of the environment that we operate here at BlackRock, and how we connect all these pieces. If we came across issues, we fixed them, and then moved on to the different environments to replicate that until we eventually ended up in our production environment where this particular cluster is supposed to live."<br><br>
-  The team had weekly one-hour working sessions with all the members (who are located around the world) participating, and smaller breakout or deep-dive meetings focusing on specific technical details. Possible solutions would be reported back to the group and debated the following week. "I think what made it a successful experiment was people had to work to learn, and they shared their experiences with others," says Vice President and Software Developer Fouad Semaan. Then, Francis says, "We gave our engineers the space to do what they’re good at. This hasn’t been top-down."
+<p>In search of a solution in which they could manage usage on a user-by-user level, Francis's team gravitated to Red Hat's <a href="https://www.openshift.com">OpenShift</a> Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years' time, in some form. And right now, in this space, Kubernetes feels like the one that's going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that's an indicator of the momentum."</p>
 
+<p>Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock's existing framework. "It's about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"</p>
 
-</div>
-</section>
+<p>The first (anticipated) speed bump was working around issues behind BlackRock's corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn't necessarily work." The team ran into these types of problems using <a href="/docs/getting-started-guides/minikube/">Minikube</a> and did a few small pushes back to the open source project.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools. That means that I don’t need to hire more people."
+{{< case-studies/quote image="/images/case-studies/blackrock/banner4.jpg">}}
+"Typically we make technology choices that we believe are going to be here in 5-10 years' time, in some form. And right now, in this space, Kubernetes feels like the one that's going to be there."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
+<p>There were also questions about service discovery. "You can think of Aladdin as a cloud of services with APIs between them that allows us to build applications rapidly," says Francis. "It's all on a proprietary message bus, which gives us all sorts of advantages but at the same time, how does that play in a third party [platform]?"</p>
 
-<section class="section5">
-<div class="fullcol">
-  They were led by one key axiom: To stay focused and avoid scope creep. This meant that they wouldn’t use features that weren’t in the core of Kubernetes and Docker. But if there was a real need, they’d build the features themselves. Luckily, Francis says, "Because of the rapidity of the development, a lot of things we thought we would have to build ourselves have been rolled into the core product. [The package manager<a href="https://helm.sh"> Helm</a> is one example]. People have similar problems."<br><br>
-  By the end of the 100 days, the app was up and running for internal BlackRock users. The initial capacity of 30 users was hit within hours, and quickly increased to 150. "People were immediately all over it," says Francis. In the next phase of this project, they are planning to scale up the cluster to have more capacity.<br><br>
-  Even more importantly, they now have in-production experience with Kubernetes that they can continue to build on—and a complete framework for rolling out new applications. "We’re going to use this infrastructure for lots of other application workloads as time goes on. It’s not just data science; it’s this style of application that needs the dynamism," says Francis. "Is it the right place to move our core production processes onto? It might be. We’re not at a point where we can say yes or no, but we felt that having real production experience with something like Kubernetes at some form and scale would allow us to understand that. I think we’re 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues."<br><br>
-  For other big companies considering a project like this, Francis says commitment and dedication are key: "We got the signoff from [senior management] from day one, with the commitment that we were able to get the right people. If I had to isolate what makes something complex like this succeed, I would say senior hands-on people who can actually drive it make a huge difference." With that in place, he adds, "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don’t have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."
+<p>Another issue they had to navigate was that in BlackRock's existing system, the messaging protocol has different instances in the different development, test and production environments. While Kubernetes enables a more DevOps-style model, it didn't make sense for BlackRock. "I think what we are very proud of is that the ability for us to push into production is still incredibly rapid in this [new] infrastructure, but we have the control points in place, and we didn't have to disrupt everything," says Francis. "A lot of the cost of this development was thinking how best to leverage our internal tools. So it was less costly than we actually thought it was going to be."</p>
 
-</div>
-</section>
+<p>The project leveraged tools associated with the messaging bus, for example. "The way that the Kubernetes cluster will talk to our internal messaging platform is through a gateway program, and this gateway program already has built-in checks and throttles," says Morris. "We can use them to control and potentially throttle the requests coming in from Kubernetes's very elastic infrastructure to the production infrastructure. We'll continue to go in that direction. It enables us to scale as we need to from the operational perspective."</p>
+
+<p>The solution also had to be complementary with BlackRock's centralized operational support team structure. "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools," Morris explains. "That means that I don't need to hire more people."</p>
+
+<p>With those points established, the team created a procedure for the project: "We rolled this out first to a development environment, then moved on to a testing environment and then eventually to two production environments, in that sequential order," says Maskallis. "That drove a lot of our learning curve. We have all these moving parts, the software components on the infrastructure side, the software components with Kubernetes directly, the interconnectivity with the rest of the environment that we operate here at BlackRock, and how we connect all these pieces. If we came across issues, we fixed them, and then moved on to the different environments to replicate that until we eventually ended up in our production environment where this particular cluster is supposed to live."</p>
+
+<p>The team had weekly one-hour working sessions with all the members (who are located around the world) participating, and smaller breakout or deep-dive meetings focusing on specific technical details. Possible solutions would be reported back to the group and debated the following week. "I think what made it a successful experiment was people had to work to learn, and they shared their experiences with others," says Vice President and Software Developer Fouad Semaan. Then, Francis says, "We gave our engineers the space to do what they're good at. This hasn't been top-down."</p>
+
+{{< case-studies/quote >}}
+"The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools. That means that I don't need to hire more people."
+{{< /case-studies/quote >}}
+
+<p>They were led by one key axiom: To stay focused and avoid scope creep. This meant that they wouldn't use features that weren't in the core of Kubernetes and Docker. But if there was a real need, they'd build the features themselves. Luckily, Francis says, "Because of the rapidity of the development, a lot of things we thought we would have to build ourselves have been rolled into the core product. [The package manager<a href="https://helm.sh"> Helm</a> is one example]. People have similar problems."</p>
+
+<p>By the end of the 100 days, the app was up and running for internal BlackRock users. The initial capacity of 30 users was hit within hours, and quickly increased to 150. "People were immediately all over it," says Francis. In the next phase of this project, they are planning to scale up the cluster to have more capacity.</p>
+
+<p>Even more importantly, they now have in-production experience with Kubernetes that they can continue to build on—and a complete framework for rolling out new applications. "We're going to use this infrastructure for lots of other application workloads as time goes on. It's not just data science; it's this style of application that needs the dynamism," says Francis. "Is it the right place to move our core production processes onto? It might be. We're not at a point where we can say yes or no, but we felt that having real production experience with something like Kubernetes at some form and scale would allow us to understand that. I think we're 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues."</p>
+
+<p>For other big companies considering a project like this, Francis says commitment and dedication are key: "We got the signoff from [senior management] from day one, with the commitment that we were able to get the right people. If I had to isolate what makes something complex like this succeed, I would say senior hands-on people who can actually drive it make a huge difference." With that in place, he adds, "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don't have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."</p>
diff --git a/content/ko/case-studies/box/index.html b/content/ko/case-studies/box/index.html
index bead8eb01a..058ff7f9a2 100644
--- a/content/ko/case-studies/box/index.html
+++ b/content/ko/case-studies/box/index.html
@@ -2,113 +2,99 @@
 title: Box Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_box.css
 video: https://www.youtube.com/embed/of45hYbkIZs?autoplay=1
 quote: >
   Kubernetes has the opportunity to be the new cloud platform. The amount of innovation that's going to come from being able to standardize on Kubernetes as a platform is incredibly exciting - more exciting than anything I've seen in the last 10 years of working on the cloud.
 
+new_case_study_styles: true
+heading_background: /images/case-studies/box/banner1.jpg
+heading_title_logo: /images/box_logo.png
+subheading: >
+  An Early Adopter Envisions a New Cloud Platform
+case_study_details:
+  - Company: Box
+  - Location: Redwood City, California
+  - Industry: Technology
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/box_logo.png" width="10%" style="margin-bottom:-6px"><br>
-    <div class="subhead">An Early Adopter Envisions
-      a New Cloud Platform</div>
-  </h1>
-</div>
+<h2>Challenge</h2>
 
+<p>Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company's own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It's been a huge challenge because of different clouds, especially bare metal, have very different interfaces."</p>
 
-<div class="details">
-    Company &nbsp;<b>Box</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Redwood City, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Technology</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box's developers to "target a universal set of concepts that are portable across all clouds."</p>
 
-<section class="section1">
+<h2>Impact</h2>
 
-<div class="cols">
-  <div class="col1">
+<p>"Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Today, a new microservice takes less than five days to deploy. And we're working on getting it to an hour."</p>
 
-      <h2>Challenge</h2>
-        Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company’s own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It’s been a huge challenge because of different clouds, especially bare metal, have very different interfaces."
-        <br>
-  </div>
+{{< case-studies/quote author="SAM GHOUDS, CO-FOUNDER AND SERVICES ARCHITECT OF BOX" >}}
+"We looked at a lot of different options, but Kubernetes really stood out....the fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as&nbsp;well."
+{{< /case-studies/quote >}}
 
-  <div class="col2">
-    <h2>Solution</h2>
-      Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box’s developers to "target a universal set of concepts that are portable across all clouds."<br><br>
+{{< case-studies/lead >}}
+In the summer of 2014, Box was feeling the pain of a decade's worth of hardware and software infrastructure that wasn't keeping up with the company's needs.
+{{< /case-studies/lead >}}
 
-    <h2>Impact</h2>
-      "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Today, a new microservice takes less than five days to deploy. And we’re working on getting it to an hour."
-  </div>
-</div>
+<p>A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It's been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."</p>
 
-</section>
+<p>Box's cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.</p>
 
-<div class="banner2">
-  <div class="banner2text">
-      "We looked at a lot of different options, but Kubernetes really stood out....the fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as&nbsp;well."<br><br><span style="font-size:15px;letter-spacing:0.08em">- SAM GHOUDS, CO-FOUNDER AND SERVICES ARCHITECT OF BOX</span>
-  </div>
-</div>
+<p>At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google's internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."</p>
 
-<section class="section2">
+<p>Another plus: Ghods liked that <a href="https://kubernetes.io/">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."</p>
 
-  <div class="fullcol">
-      <h2>In the summer of 2014, Box was feeling the pain of a decade’s worth of hardware and software infrastructure that wasn’t keeping up with the company’s needs.</h2>
+<p>Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods's team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn't fail synchronous incoming requests from customers."</p>
 
-      A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."<br><br>
-      Box’s cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.<br><br>
-      At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google’s internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."<br><br>
-      Another plus: Ghods liked that <a href="https://kubernetes.io/">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."<br><br>
-      Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods’s team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn’t fail synchronous incoming requests from customers."
+{{< case-studies/quote image="/images/case-studies/box/banner3.jpg">}}
+"As we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we [can have Kubernetes help] run our workload across many different environments and many different cloud infrastructure providers."
+{{< /case-studies/quote >}}
 
-  </div>
-</section>
+<p>The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that's ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that's going to be expanding a lot over the next 12 months, probably too many hundreds if not thousands."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "As we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we [can have Kubernetes help] run our workload across many different environments and many different cloud infrastructure providers."
-  </div>
-</div>
+<p>While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods&nbsp;notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</p>
 
-<section class="section3">
-  <div class="fullcol">
-    The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that’s ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that’s going to be expanding a lot over the next 12 months, probably too many hundreds if not thousands."<br><br>
-    While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods&nbsp;notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
-    <br><br><div class="quote">"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</div><br>
-    Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we’d upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."<br><br>
-    In any case, Box didn’t have to make too many modifications to Kubernetes for it to work for the company. "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing (and often legacy) infrastructure," says Ghods, "such as upgrading our base operating system from RHEL6 to RHEL7 or integrating it into <a href="https://www.nagios.org/">Nagios</a>, our monitoring infrastructure. But overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."<br><br>
-    Perhaps the bigger challenge for Box was a cultural one. "Kubernetes, and cloud native in general, represents a pretty big paradigm shift, and it’s not very incremental," Ghods says. "We’re essentially making this pitch that Kubernetes is going to solve everything because it does things the right way and everything is just suddenly better. But it’s important to keep in mind that it’s not nearly as proven as many other solutions out there. You can’t say how long this or that company took to do it because there just aren’t that many yet. Our team had to really fight for resources because our project was a bit of a moonshot."
-  </div>
-</section>
+{{< case-studies/lead >}}
+"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
+{{< /case-studies/lead >}}
 
-  <div class="banner4">
-    <div class="banner4text">
-    "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing [and often legacy] infrastructure....overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."
-    </div>
-  </div>
+<p>Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we'd upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."</p>
 
-<section class="section4">
-  <div class="fullcol">
-    Having learned from experience, Ghods offers these two pieces of advice for companies going through similar challenges:
-    <h2>1. Deliver early and often.</h2> Service discovery was a huge problem for Box, and the team had to decide whether to build an interim solution or wait for Kubernetes to natively satisfy Box’s unique requirements. After much debate, "we just started focusing on delivering something that works, and then dealing with potentially migrating to a more native solution later," Ghods says. "The above-all-else target for the team should always be to serve real production use cases on the infrastructure, no matter how trivial. This helps keep the momentum going both for the team itself and for the organizational perception of the project." </br></br>
-    <h2>2. Keep an open mind about what your company has to abstract away from developers and what it&nbsp;doesn’t.</h2> Early on, the team built an abstraction on top of Docker files to help ensure that images had the right security updates.
-    This turned out to be superfluous work, since container images are considered immutable and you can easily scan them post-build to ensure they do not contain vulnerabilities. Because managing infrastructure through containerization is such a discontinuous leap, it’s better to start by interacting directly with the native tools and learning their unique advantages and caveats. An abstraction should be built only after a practical need for it arises.</br></br>
-    In the end, the impact has been powerful. "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Now a new microservice takes less than five days to deploy. And we’re working on getting it to an hour. Granted, much of that six months was due to how broken our systems were, but bare metal is intrinsically a difficult platform to support unless you have a system like Kubernetes to help manage&nbsp;it."</br></br>
-    By Ghods’s estimate, Box is still several years away from his goal of being a 90-plus percent Kubernetes shop. "We’re very far along on having a mission-critical, stable Kubernetes deployment that provides a lot of value," he says. "Right now about five percent of all of our compute runs on Kubernetes, and I think in the next six months we’ll likely be between 20 to 50 percent. We’re working hard on enabling all stateless service use cases, and shift our focus to stateful services after&nbsp;that."
-  </div>
-</section>
+<p>In any case, Box didn't have to make too many modifications to Kubernetes for it to work for the company. "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing (and often legacy) infrastructure," says Ghods, "such as upgrading our base operating system from RHEL6 to RHEL7 or integrating it into <a href="https://www.nagios.org/">Nagios</a>, our monitoring infrastructure. But overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we've been running it very successfully on our bare metal infrastructure."</p>
 
-  <div class="banner5">
-    <div class="banner5text">
-    "Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. '...because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure.'"
-    </div>
-  </div>
+<p>Perhaps the bigger challenge for Box was a cultural one. "Kubernetes, and cloud native in general, represents a pretty big paradigm shift, and it's not very incremental," Ghods says. "We're essentially making this pitch that Kubernetes is going to solve everything because it does things the right way and everything is just suddenly better. But it's important to keep in mind that it's not nearly as proven as many other solutions out there. You can't say how long this or that company took to do it because there just aren't that many yet. Our team had to really fight for resources because our project was a bit of a moonshot."</p>
 
-<section class="section5">
-  <div class="fullcol">
-    In fact, that’s what he envisions across the industry: Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. Kubernetes provides an API consistent across different cloud platforms including bare metal, and "I don’t think people have seen the full potential of what’s possible when you can program against one single interface," he says. "The same way <a href="https://aws.amazon.com/">AWS</a> changed infrastructure so that you don’t have to think about servers or cabinets or networking equipment anymore, Kubernetes enables you to focus exclusively on the containers that you’re running, which is pretty exciting. That’s the vision."</br></br>
-    Ghods points to projects that are already in development or recently released for Kubernetes as a cloud platform: cluster federation, the Dashboard UI, and <a href="https://coreos.com/">CoreOS</a>’s etcd operator. "I honestly believe it’s the most exciting thing I’ve seen in cloud infrastructure," he says, "because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</br></br>
-    Box, with its early decision to use bare metal, embarked on its Kubernetes journey out of necessity. But Ghods says that even if companies don’t have to be agnostic about cloud providers today, Kubernetes may soon become the industry standard, as more and more tooling and extensions are built around the API.</br></br>
-    "The same way it doesn’t make sense to deviate from Linux because it’s such a standard," Ghods says, "I think Kubernetes is going down the same path. It is still early days—the documentation still needs work and the user experience for writing and publishing specs to the Kubernetes clusters is still rough. When you’re on the cutting edge you can expect to bleed a little. But the bottom line is, this is where the industry is going. Three to five years from now it’s really going to be shocking if you run your infrastructure any other way."
-  </div>
-</section>
+{{< case-studies/quote image="/images/case-studies/box/banner4.jpg">}}
+"The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing [and often legacy] infrastructure....overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we've been running it very successfully on our bare metal infrastructure."
+{{< /case-studies/quote >}}
+
+<p>Having learned from experience, Ghods offers these two pieces of advice for companies going through similar challenges:</p>
+
+{{< case-studies/lead >}}
+1. Deliver early and often.
+{{< /case-studies/lead >}}
+
+<p>Service discovery was a huge problem for Box, and the team had to decide whether to build an interim solution or wait for Kubernetes to natively satisfy Box's unique requirements. After much debate, "we just started focusing on delivering something that works, and then dealing with potentially migrating to a more native solution later," Ghods says. "The above-all-else target for the team should always be to serve real production use cases on the infrastructure, no matter how trivial. This helps keep the momentum going both for the team itself and for the organizational perception of the project."</p>
+
+{{< case-studies/lead >}}
+2. Keep an open mind about what your company has to abstract away from developers and what it doesn't.
+{{< /case-studies/lead >}}
+
+<p>Early on, the team built an abstraction on top of Docker files to help ensure that images had the right security updates. This turned out to be superfluous work, since container images are considered immutable and you can easily scan them post-build to ensure they do not contain vulnerabilities. Because managing infrastructure through containerization is such a discontinuous leap, it's better to start by interacting directly with the native tools and learning their unique advantages and caveats. An abstraction should be built only after a practical need for it arises.</p>
+
+<p>In the end, the impact has been powerful. "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Now a new microservice takes less than five days to deploy. And we're working on getting it to an hour. Granted, much of that six months was due to how broken our systems were, but bare metal is intrinsically a difficult platform to support unless you have a system like Kubernetes to help manage it."</p>
+
+<p>By Ghods's estimate, Box is still several years away from his goal of being a 90-plus percent Kubernetes shop. "We're very far along on having a mission-critical, stable Kubernetes deployment that provides a lot of value," he says. "Right now about five percent of all of our compute runs on Kubernetes, and I think in the next six months we'll likely be between 20 to 50 percent. We're working hard on enabling all stateless service use cases, and shift our focus to stateful services after that."</p>
+
+{{< case-studies/quote >}}
+"Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. '...because it's a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure.'"
+{{< /case-studies/quote >}}
+
+<p>In fact, that's what he envisions across the industry: Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. Kubernetes provides an API consistent across different cloud platforms including bare metal, and "I don't think people have seen the full potential of what's possible when you can program against one single interface," he says. "The same way <a href="https://aws.amazon.com/">AWS</a> changed infrastructure so that you don't have to think about servers or cabinets or networking equipment anymore, Kubernetes enables you to focus exclusively on the containers that you're running, which is pretty exciting. That's the vision."</p>
+
+<p>Ghods points to projects that are already in development or recently released for Kubernetes as a cloud platform: cluster federation, the Dashboard UI, and <a href="https://coreos.com/">CoreOS</a>'s etcd operator. "I honestly believe it's the most exciting thing I've seen in cloud infrastructure," he says, "because it's a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</p>
+
+<p>Box, with its early decision to use bare metal, embarked on its Kubernetes journey out of necessity. But Ghods says that even if companies don't have to be agnostic about cloud providers today, Kubernetes may soon become the industry standard, as more and more tooling and extensions are built around the API.</p>
+
+<p>"The same way it doesn't make sense to deviate from Linux because it's such a standard," Ghods says, "I think Kubernetes is going down the same path. It is still early days—the documentation still needs work and the user experience for writing and publishing specs to the Kubernetes clusters is still rough. When you're on the cutting edge you can expect to bleed a little. But the bottom line is, this is where the industry is going. Three to five years from now it's really going to be shocking if you run your infrastructure any other way."</p>
diff --git a/content/ko/case-studies/buffer/index.html b/content/ko/case-studies/buffer/index.html
index 333db6a74e..bcf0896445 100644
--- a/content/ko/case-studies/buffer/index.html
+++ b/content/ko/case-studies/buffer/index.html
@@ -1,112 +1,83 @@
 ---
 title: Buffer Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_buffer.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/buffer/banner3.jpg
+heading_title_logo: /images/buffer.png
+subheading: >
+  Making Deployments Easy for a Small, Distributed Team
+case_study_details:
+  - Company: Buffer
+  - Location: Around the World
+  - Industry: Social Media Technology
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/buffer.png" width="18%" style="margin-bottom:-5px;margin-left:10px;"><br>
-  <div class="subhead">Making Deployments Easy for a Small, Distributed Team</div>
-</h1>
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company&nbsp;<b>Buffer</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Around the World</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Social Media Technology</b>
-</div>
+<p>With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary."</p>
 
-<hr>
+<h2>Solution</h2>
 
-<section class="section1">
-  <div class="cols">
-    <div class="col1">
+<p>Embracing containerization, Buffer moved its infrastructure from Amazon Web Services' Elastic Beanstalk to Docker on AWS, orchestrated with Kubernetes.</p>
 
-    <h2>Challenge</h2>
-      With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as&nbsp;necessary."
-</div>
-
-<div class="col2">
-  <h2>Solution</h2>
-      Embracing containerization, Buffer moved its infrastructure from Amazon Web Services’ Elastic Beanstalk to Docker on AWS, orchestrated with&nbsp;Kubernetes.
-      <br>
-      <br>
 <h2>Impact</h2>
-      The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it’s going to work has shortened things up a lot. Our feedback cycles are a lot faster now&nbsp;too."
-    </div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it’s there in the next release or it’s coming in the next few months."<br><br><span style="font-size:16px;letter-spacing:2px;">- DAN FARRELLY, BUFFER ARCHITECT</span>
-  </div>
-</div>
+<p>The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it's going to work has shortened things up a lot. Our feedback cycles are a lot faster now too."</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>Dan Farrelly uses a carpentry analogy to explain the problem his company, <a href="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.</h2>
+{{< case-studies/quote author="DAN FARRELLY, BUFFER ARCHITECT" >}}
+"It's amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it's there in the next release or it's coming in the next few months."
+{{< /case-studies/quote >}}
 
-    "If you’re building a table by yourself, it’s fine," the company’s architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you’re sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.<br><br>
-    Since around 2012, Buffer had already been using <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <a href="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <a href="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn’t spend too much time on it. If things were getting a little bit slow, we’d maybe use a faster server or just scale up one instance, and it would be good enough. We’d move on."<br><br>
-    But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer’s then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company’s team was already successfully using <a href="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn’t see real user traffic. They wanted to go further with Docker, and the next step was looking at options for&nbsp;orchestration.
-</div>
-</section>
+{{< case-studies/lead >}}
+Dan Farrelly uses a carpentry analogy to explain the problem his company, <a href="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.
+{{< /case-studies/lead >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it&nbsp;[Kubernetes]."
-  </div>
-</div>
+<p>"If you're building a table by yourself, it's fine," the company's architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you're sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.</p>
 
-<section class="section3">
-<div class="fullcol">
-    First they considered <a href="https://mesosphere.com">Mesosphere</a>, <a href="https://dcos.io">DC/OS</a> and <a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn’t need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes’ controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."<br><br>
-    And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."<br><br>
-    Above all, it provided a powerful solution for one of the company’s most distinguishing characteristics: their remote team that’s spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It’s been really cool to see people moving much faster."
-    <br><br>
-    With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies&nbsp;might."
-</div>
-</section>
+<p>Since around 2012, Buffer had already been using <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <a href="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <a href="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn't spend too much time on it. If things were getting a little bit slow, we'd maybe use a faster server or just scale up one instance, and it would be good enough. We'd move on."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the&nbsp;door."
-  </div>
-</div>
+<p>But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer's then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company's team was already successfully using <a href="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn't see real user traffic. They wanted to go further with Docker, and the next step was looking at options for orchestration.</p>
 
-<section class="section4">
-<div class="fullcol">
-    To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <a href="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <a href="https://slack.com">Slack</a> command, ‘/deploy,’ and it goes out instantly. They don’t need to wait on these slow turnaround times. They don’t even know where it’s running; it doesn’t matter."
-    <br><br>
-    One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.
-    <br><br>
-    To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door."
-    <br><br>
-    Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."
-    <br><br>
-    Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing&nbsp;risk."
+{{< case-studies/quote image="/images/case-studies/buffer/banner1.jpg" >}}
+And all the things Kubernetes did well suited Buffer's needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>First they considered <a href="https://mesosphere.com">Mesosphere</a>, <a href="https://dcos.io">DC/OS</a> and <a href="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn't need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes' controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this&nbsp;way."
-  </div>
-</div>
+<p>And all the things Kubernetes did well suited Buffer's needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."</p>
 
-<section class="section5">
-<div class="fullcol">
-    By October 2016, 54 percent of Buffer’s traffic was going through their Kubernetes cluster. "There’s a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."
-    <br><br>
-    The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they’ve pulled out of their old infrastructure, plus the new services they’re developing in Kubernetes, on another cluster. "I want to bring all the benefits that we’ve seen on our early services to everyone on the team," says Farrelly.
-    <br><br>
-    <h2>For Buffer’s engineers, it’s an exciting process. "Every time we’re deploying a new service, we need to figure out: OK, what’s the architecture? How do these services communicate? What’s the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It’s enabling us to experiment as we’re learning how to design a service-oriented architecture. Before, we just wouldn’t have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it."
-    </h2>
-    Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It’s cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We’re very deep in Amazon but it’s nice to know we could move away if we need to."
-    <br><br>
-    At this point, the team at Buffer can’t imagine running their infrastructure any other way—and they’re happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this&nbsp;way."
-  <br><br>
-</div>
-</section>
+<p>Above all, it provided a powerful solution for one of the company's most distinguishing characteristics: their remote team that's spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It's been really cool to see people moving much faster."</p>
+
+<p>With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies might."</p>
+
+{{< case-studies/quote image="/images/case-studies/buffer/banner4.jpg" >}}
+"In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it's out the door."
+{{< /case-studies/quote >}}
+
+<p>To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <a href="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <a href="https://slack.com">Slack</a> command, '/deploy,' and it goes out instantly. They don't need to wait on these slow turnaround times. They don't even know where it's running; it doesn't matter."</p>
+
+<p>One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.</p>
+
+<p>To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it's out the door."</p>
+
+<p>Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."</p>
+
+<p>Another thing they weren't able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of 'fingers crossed.' And this is something that gets run 800,000 times a day, the core of our business. If it doesn't work, our business doesn't work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn't working. This has leveled up our ability to deploy and roll out new changes quickly while reducing risk."</p>
+
+{{< case-studies/quote >}}
+"If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We're a relatively small team that's actually running Kubernetes, and we've never run anything like it before. So it's more approachable than you might think. That's the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."
+{{< /case-studies/quote >}}
+
+<p>By October 2016, 54 percent of Buffer's traffic was going through their Kubernetes cluster. "There's a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."</p>
+
+<p>The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they've pulled out of their old infrastructure, plus the new services they're developing in Kubernetes, on another cluster. "I want to bring all the benefits that we've seen on our early services to everyone on the team," says Farrelly.</p>
+
+{{< case-studies/lead >}}
+For Buffer's engineers, it's an exciting process. "Every time we're deploying a new service, we need to figure out: OK, what's the architecture? How do these services communicate? What's the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It's enabling us to experiment as we're learning how to design a service-oriented architecture. Before, we just wouldn't have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it."
+{{< /case-studies/lead >}}
+
+<p>Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It's cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We're very deep in Amazon but it's nice to know we could move away if we need to."</p>
+
+<p>At this point, the team at Buffer can't imagine running their infrastructure any other way—and they're happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We're a relatively small team that's actually running Kubernetes, and we've never run anything like it before. So it's more approachable than you might think. That's the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."</p>
diff --git a/content/ko/case-studies/capital-one/index.html b/content/ko/case-studies/capital-one/index.html
index f95fb2acc7..7474b71b10 100644
--- a/content/ko/case-studies/capital-one/index.html
+++ b/content/ko/case-studies/capital-one/index.html
@@ -2,95 +2,60 @@
 title: Capital One Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/capitalone/banner1.jpg
+heading_title_logo: /images/capitalone-logo.png
+subheading: >
+  Supporting Fast Decisioning Applications with Kubernetes
+case_study_details:
+  - Company: Capital One
+  - Location: McLean, Virginia
+  - Industry: Retail banking
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/capitalone/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/capitalone-logo.png" style="margin-bottom:-2%" class="header_logo"><br> <div class="subhead">Supporting Fast Decisioning Applications with Kubernetes
+<h2>Challenge</h2>
 
-</div></h1>
+<p>The team set out to build a provisioning platform for <a href="https://www.capitalone.com/">Capital One</a> applications deployed on AWS that use streaming, big-data decisioning, and machine learning. One of these applications handles millions of transactions a day; some deal with critical functions like fraud detection and credit decisioning. The key considerations: resilience and speed—as well as full rehydration of the cluster from base AMIs.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Capital One</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>McLean, Virginia</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Retail banking</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    The team set out to build a provisioning platform for <a href="https://www.capitalone.com/">Capital One</a> applications deployed on AWS that use streaming, big-data decisioning, and machine learning. One of these applications handles millions of transactions a day; some deal with critical functions like fraud detection and credit decisioning. The key considerations: resilience and speed—as well as full rehydration of the cluster from base AMIs.
-
-<br>
-    <h2>Solution</h2>
-    The decision to run <a href="https://kubernetes.io/">Kubernetes</a> "is very strategic for us," says John Swift, Senior Director Software Engineering. "We use Kubernetes as a substrate or an operating system, if you will. There’s a degree of affinity in our product development."
-</div>
-
-<div class="col2">
+<p>The decision to run <a href="https://kubernetes.io/">Kubernetes</a> "is very strategic for us," says John Swift, Senior Director Software Engineering. "We use Kubernetes as a substrate or an operating system, if you will. There's a degree of affinity in our product development."</p>
 
 <h2>Impact</h2>
-  "Kubernetes is a significant productivity multiplier," says Lead Software Engineer Keith Gasser, adding that to run the platform without Kubernetes would "easily see our costs triple, quadruple what they are now for the amount of pure AWS expense." Time to market has been improved as well: "Now, a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer." Deployments increased by several orders of magnitude. Plus, the rehydration/cluster-rebuild process, which took a significant part of a day to do manually, now takes a couple hours with Kubernetes automation and declarative configuration.
 
+<p>"Kubernetes is a significant productivity multiplier," says Lead Software Engineer Keith Gasser, adding that to run the platform without Kubernetes would "easily see our costs triple, quadruple what they are now for the amount of pure AWS expense." Time to market has been improved as well: "Now, a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer." Deployments increased by several orders of magnitude. Plus, the rehydration/cluster-rebuild process, which took a significant part of a day to do manually, now takes a couple hours with Kubernetes automation and declarative configuration.</p>
 
-</div>
+{{< case-studies/quote author="Jamil Jadallah, Scrum Master" >}}
+<iframe width="560" height="315" src="https://www.youtube.com/embed/UHVW01ksg-s" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<br>
+"With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-<iframe width="560" height="315" src="https://www.youtube.com/embed/UHVW01ksg-s" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe><br><br>
-"With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before." <span style="font-size:16px;text-transform:uppercase">— Jamil Jadallah, Scrum Master</span>
-</div>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2></h2>
-  As a top 10 U.S. retail bank, Capital One has applications that handle millions of transactions a day. Big-data decisioning—for fraud detection, credit approvals and beyond—is core to the business. To support the teams that build applications with those functions for the bank, the cloud team led by Senior Director Software Engineering John Swift embraced Kubernetes for its provisioning platform. "Kubernetes and its entire ecosystem are very strategic for us," says Swift. "We use Kubernetes as a substrate or an operating system, if you will. There’s a degree of affinity in our product development."<br><br>
-  Almost two years ago, the team embarked on this journey by first working with Docker. Then came Kubernetes. "We wanted to put streaming services into Kubernetes as one feature of the workloads for fast decisioning, and to be able to do batch alongside it," says Lead Software Engineer Keith Gasser. "Once the data is streamed and batched, there are so many tool sets in <a href="https://flink.apache.org/">Flink</a> that we use for decisioning. We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
+<p>As a top 10 U.S. retail bank, Capital One has applications that handle millions of transactions a day. Big-data decisioning—for fraud detection, credit approvals and beyond—is core to the business. To support the teams that build applications with those functions for the bank, the cloud team led by Senior Director Software Engineering John Swift embraced Kubernetes for its provisioning platform. "Kubernetes and its entire ecosystem are very strategic for us," says Swift. "We use Kubernetes as a substrate or an operating system, if you will. There's a degree of affinity in our product development."</p>
 
+<p>Almost two years ago, the team embarked on this journey by first working with Docker. Then came Kubernetes. "We wanted to put streaming services into Kubernetes as one feature of the workloads for fast decisioning, and to be able to do batch alongside it," says Lead Software Engineer Keith Gasser. "Once the data is streamed and batched, there are so many tool sets in <a href="https://flink.apache.org/">Flink</a> that we use for decisioning. We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."</p>
 
+{{< case-studies/quote image="/images/case-studies/capitalone/banner3.jpg" >}}
+"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/capitalone/banner3.jpg')">
-  <div class="banner3text">
-    "We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
+<p>In this first year, the impact has already been great. "Time to market is really huge for us," says Gasser. "Especially with fraud, you have to be very nimble in the way you respond to threats in the marketplace—being able to add and push new rules, detect new patterns of behavior, detect anomalies in account and transaction flows." With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."</p>
 
+<p>Teams now have the tools to be autonomous in their deployments, and as a result, deployments have increased by two orders of magnitude. "And that was with just seven dedicated resources, without needing a whole group sitting there watching everything," says Scrum Master Jamil Jadallah. "That's a huge cost savings. With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  In this first year, the impact has already been great. "Time to market is really huge for us," says Gasser. "Especially with fraud, you have to be very nimble in the way you respond to threats in the marketplace—being able to add and push new rules, detect new patterns of behavior, detect anomalies in account and transaction flows." With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."<br><br>
-  Teams now have the tools to be autonomous in their deployments, and as a result, deployments have increased by two orders of magnitude. "And that was with just seven dedicated resources, without needing a whole group sitting there watching everything," says Scrum Master Jamil Jadallah. "That’s a huge cost savings. With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."
+{{< case-studies/quote image="/images/case-studies/capitalone/banner4.jpg" >}}
+With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/capitalone/banner4.jpg')">
-  <div class="banner4text">
-    With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
-  </div>
-</div>
+<p>Kubernetes has also been a great time-saver for Capital One's required period "rehydration" of clusters from base AMIs. To minimize the attack vulnerability profile for applications in the cloud, "Our entire clusters get rebuilt from scratch periodically, with new fresh instances and virtual server images that are patched with the latest and greatest security patches," says Gasser. This process used to take the better part of a day, and personnel, to do manually. It's now a quick Kubernetes job.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-    Kubernetes has also been a great time-saver for Capital One’s required period "rehydration" of clusters from base AMIs. To minimize the attack vulnerability profile for applications in the cloud, "Our entire clusters get rebuilt from scratch periodically, with new fresh instances and virtual server images that are patched with the latest and greatest security patches," says Gasser. This process used to take the better part of a day, and personnel, to do manually. It’s now a quick Kubernetes job.<br><br>
-  Savings extend to both capital and operating expenses. "It takes very little to get into Kubernetes because it’s all open source," Gasser points out. "We went the DIY route for building our cluster, and we definitely like the flexibility of being able to embrace the latest from the community immediately without waiting for a downstream company to do it. There’s capex related to those licenses that we don’t have to pay for. Moreover, there’s capex savings for us from some of the proprietary software that we get to sunset in our particular domain. So that goes onto our ledger in a positive way as well." (Some of those open source technologies include Prometheus, Fluentd, gRPC, Istio, CNI, and Envoy.)
+<p>Savings extend to both capital and operating expenses. "It takes very little to get into Kubernetes because it's all open source," Gasser points out. "We went the DIY route for building our cluster, and we definitely like the flexibility of being able to embrace the latest from the community immediately without waiting for a downstream company to do it. There's capex related to those licenses that we don't have to pay for. Moreover, there's capex savings for us from some of the proprietary software that we get to sunset in our particular domain. So that goes onto our ledger in a positive way as well." (Some of those open source technologies include Prometheus, Fluentd, gRPC, Istio, CNI, and Envoy.)</p>
 
-</div>
+{{< case-studies/quote >}}
+"If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn't account for personnel to deploy and maintain all the additional infrastructure."
+{{< /case-studies/quote >}}
 
-<div class="banner5">
-  <div class="banner5text">
-   "If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn’t account for personnel to deploy and maintain all the additional infrastructure."
-  </div>
-</div>
+<p>And on the opex side, Gasser says, the savings are high. "We run dozens of services, we have scores of pods, many daemon sets, and since we're data-driven, we take advantage of EBS-backed volume claims for all of our stateful services. If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn't account for personnel to deploy and maintain all the additional infrastructure."</p>
 
-<div class="fullcol">
-  And on the opex side, Gasser says, the savings are high. "We run dozens of services, we have scores of pods, many daemon sets, and since we’re data-driven, we take advantage of EBS-backed volume claims for all of our stateful services. If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn’t account for personnel to deploy and maintain all the additional infrastructure."<br><br>
-  The team is confident that the benefits will continue to multiply—without a steep learning curve for the engineers being exposed to the new technology. "As we onboard additional tenants in this ecosystem, I think the need for folks to understand Kubernetes may not necessarily go up. In fact, I think it goes down, and that’s good," says Gasser. "Because that really demonstrates the scalability of the technology. You start to reap the benefits, and they can concentrate on all the features they need to build for great decisioning in the business— fraud decisions, credit decisions—and not have to worry about, ‘Is my AWS server broken? Is my pod not running?’"
-</div>
-
-</section>
+<p>The team is confident that the benefits will continue to multiply—without a steep learning curve for the engineers being exposed to the new technology. "As we onboard additional tenants in this ecosystem, I think the need for folks to understand Kubernetes may not necessarily go up. In fact, I think it goes down, and that's good," says Gasser. "Because that really demonstrates the scalability of the technology. You start to reap the benefits, and they can concentrate on all the features they need to build for great decisioning in the business— fraud decisions, credit decisions—and not have to worry about, 'Is my AWS server broken? Is my pod not running?'"</p>
diff --git a/content/ko/case-studies/crowdfire/index.html b/content/ko/case-studies/crowdfire/index.html
index 227a5c0839..98caae2830 100644
--- a/content/ko/case-studies/crowdfire/index.html
+++ b/content/ko/case-studies/crowdfire/index.html
@@ -1,101 +1,85 @@
 ---
 title: Crowdfire Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_crowdfire.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/crowdfire/banner1.jpg
+heading_title_logo: /images/crowdfire_logo.png
+subheading: >
+  How to Keep Iterating a Fast-Growing App With a Cloud-Native Approach
+case_study_details:
+  - Company: Crowdfire
+  - Location: Mumbai, India
+  - Industry: Social Media Software
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/crowdfire_logo.png" class="header_logo"><br> <div class="subhead">How to Keep Iterating a Fast-Growing App With a Cloud-Native Approach</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p><a href="https://www.crowdfireapp.com/">Crowdfire</a> helps content creators create their content anywhere on the Internet and publish it everywhere else in the right format. Since its launch in 2010, it has grown to 16 million users. The product began as a monolith app running on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, and in 2015, the company began a transformation to microservices running on Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>. "It was okay for our use cases initially, but as the number of services, development teams and scale increased, the deploy times, self-healing capabilities and resource utilization started to become problems for us," says Software Engineer Amanpreet Singh, who leads the infrastructure team for Crowdfire.</p>
 
-<div class="details">
-    Company &nbsp;<b>Crowdfire</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Mumbai, India</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Social Media Software</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        <a href="https://www.crowdfireapp.com/">Crowdfire</a> helps content creators create their content anywhere on the Internet and publish it everywhere else in the right format. Since its launch in 2010, it has grown to 16 million users. The product began as a monolith app running on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, and in 2015, the company began a transformation to microservices running on Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>. "It was okay for our use cases initially, but as the number of services, development teams and scale increased, the deploy times, self-healing capabilities and resource utilization started to become problems for us," says Software Engineer Amanpreet Singh, who leads the infrastructure team for Crowdfire.<br>
-        <h2>Solution</h2>
-            "We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>.
-      <br>
-      </div>
-
-<div class="col2">
+<p>"We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>.</p>
 
 <h2>Impact</h2>
-      "Kubernetes has helped us reduce the deployment time from 15 minutes to less than a minute," says Singh. "Due to Kubernetes’s self-healing nature, the operations team doesn’t need to do any manual intervention in case of a node or pod failure." Plus, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it’s finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines."
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-  "In the 15 months that we’ve been using Kubernetes, it has been amazing for us. It enabled us to iterate quickly, increase development speed, and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Amanpreet Singh, Software Engineer at Crowdfire</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-    <h2>"If you build it, they will come."</h2>
-    For most content creators, only half of that movie quote may ring true. Sure, platforms like Wordpress, YouTube and Shopify have made it simple for almost anyone to start publishing new content online, but attracting an audience isn’t as easy. Crowdfire "helps users publish their content to all possible places where their audience exists," says Amanpreet Singh, a Software Engineer at the company based in Mumbai, India. Crowdfire has gained more than 16 million users—from bloggers and artists to makers and small businesses—since its launch in 2010.<br><br>
-    With that kind of growth—and a high demand from users for new features and continuous improvements—the Crowdfire team struggled to keep up behind the scenes. In 2015, they moved their monolith Java application to Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a> and started breaking it down into microservices.<br><br>
-    It was a good first step, but the team soon realized they needed to go further down the cloud-native path, which would lead them to Kubernetes. "It was okay for our use cases initially, but as the number of services and development teams increased and we scaled further, deploy times, self-healing capabilities and resource utilization started to become problematic," says Singh, who leads the infrastructure team at Crowdfire. "We realized that we needed a more cloud-native approach to deal with these issues."<br><br>
-    As he looked around for solutions, Singh had a checklist of what Crowdfire needed. "We wanted to keep some things separate so they could be shipped independent of other things; this would help remove blockers and let different teams work at their own pace," he says. "We also make a lot of data-driven decisions, so shipping a feature and its iterations quickly was a must."<br><br>
-    Kubernetes checked all the boxes and then some. "One of the best things was the built-in service discovery," he says. "When you have a bunch of microservices that need to call each other, having internal DNS readily available and service IPs and ports automatically set as environment variables help a lot." Plus, he adds, "Kubernetes’s opinionated approach made it easier to get started."
+<p>"Kubernetes has helped us reduce the deployment time from 15 minutes to less than a minute," says Singh. "Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." Plus, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines."</p>
 
-</div>
-</section>
-<div class="banner3">
-  <div class="banner3text">
-    "We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on Terraform and Ansible."
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  There was another compelling business reason for the cloud-native approach. "In today’s world of ever-changing business requirements, using cloud native technology provides a variety of options to choose from—even the ability to run services in a hybrid cloud environment," says Singh. "Businesses can keep services in a region closest to the users, and thus benefit from high-availability and resiliency."<br><br>
-  So in February 2016, Singh set up a test Kubernetes cluster using the kube-up scripts provided. "I explored the features and was able to deploy an application pretty easily," he says. "However, it seemed like a black box since I didn’t understand the components completely, and had no idea what the kube-up script did under the hood. So when it broke, it was hard to find the issue and fix it." <br><br>
-  To get a better understanding, Singh dove into the internals of Kubernetes, reading the docs and even some of the code. And he looked to the Kubernetes community for more insight. "I used to stay up a little late every night (a lot of users were active only when it’s night here in India) and would try to answer questions on the Kubernetes community Slack from users who were getting started," he says. "I would also follow other conversations closely. I must admit I was able to avoid a lot of issues in our setup because I knew others had faced the same issues."<br><br>
-  Based on the knowledge he gained, Singh decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>. "I wrote Terraform to launch Kubernetes master and nodes (Auto Scaling Groups) and an Ansible playbook to install the required components," he says. (The company recently switched to using prebaked <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html">AMIs</a> to make the node bringup faster, and is planning to change its networking layer.) <br><br>
+{{< case-studies/quote author="Amanpreet Singh, Software Engineer at Crowdfire" >}}
+"In the 15 months that we've been using Kubernetes, it has been amazing for us. It enabled us to iterate quickly, increase development speed, and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4">
-  <div class="banner4text">
-    "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes’s self-healing nature, the operations team doesn’t need to do any manual intervention in case of a node or pod failure."
-  </div>
-</div>
+{{< case-studies/lead >}}
+"If you build it, they will come."
+{{< /case-studies/lead >}}
 
-<section class="section4">
-<div class="fullcol">
-  First, the team migrated a few staging services from Elastic Beanstalk to the new Kubernetes staging cluster, and then set up a production cluster a month later to deploy some services. The results were convincing. "By the end of March 2016, we established that all the new services must be deployed on Kubernetes," says Singh. "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes’s self-healing nature, the operations team doesn’t need to do any manual intervention in case of a node or pod failure." On top of that, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it’s finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines. This brings more visibility into the changes being made, and keeping an audit trail."<br><br>
-  Over the next six months, the team worked on migrating all the services from Elastic Beanstalk to Kubernetes, except for the few that were deprecated and would soon be terminated anyway. The services were moved one at a time, and their performance was monitored for two to three days each. Today, "We’re completely migrated and we run all new services on Kubernetes," says Singh. <br><br>
-  The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.<br><br>
-  All 30 engineers at Crowdfire were onboarded at once. "I gave an internal talk where I shared the basic components and demoed the usage of kubectl," says Singh. "Everyone was excited and happy about using Kubernetes. Developers have more control and visibility into their applications running in production now. Most of all, they’re happy with the low deploy times and self-healing services." <br><br>
-  And they’re much more productive, too. "Where we used to do about 5 deployments per day," says Singh, "now we’re doing 30+ production and 50+ staging deployments almost every day."
+<p>For most content creators, only half of that movie quote may ring true. Sure, platforms like Wordpress, YouTube and Shopify have made it simple for almost anyone to start publishing new content online, but attracting an audience isn't as easy. Crowdfire "helps users publish their content to all possible places where their audience exists," says Amanpreet Singh, a Software Engineer at the company based in Mumbai, India. Crowdfire has gained more than 16 million users—from bloggers and artists to makers and small businesses—since its launch in 2010.</p>
 
+<p>With that kind of growth—and a high demand from users for new features and continuous improvements—the Crowdfire team struggled to keep up behind the scenes. In 2015, they moved their monolith Java application to Amazon Web Services <a href="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a> and started breaking it down into microservices.</p>
 
-</div>
-</section>
-<div class="banner5">
-  <div class="banner5text">
-    The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.
+<p>It was a good first step, but the team soon realized they needed to go further down the cloud-native path, which would lead them to Kubernetes. "It was okay for our use cases initially, but as the number of services and development teams increased and we scaled further, deploy times, self-healing capabilities and resource utilization started to become problematic," says Singh, who leads the infrastructure team at Crowdfire. "We realized that we needed a more cloud-native approach to deal with these issues."</p>
 
-  </div>
-</div>
-<section class="section5">
-<div class="fullcol">
+<p>As he looked around for solutions, Singh had a checklist of what Crowdfire needed. "We wanted to keep some things separate so they could be shipped independent of other things; this would help remove blockers and let different teams work at their own pace," he says. "We also make a lot of data-driven decisions, so shipping a feature and its iterations quickly was a must."</p>
 
-   Singh notes that almost all of the engineers interact with the staging cluster on a daily basis, and that has created a cultural change at Crowdfire. "Developers are more aware of the cloud infrastructure now," he says. "They’ve started following cloud best practices like better health checks, structured logs to stdout [standard output], and config via files or environment variables."<br><br>
-  With Crowdfire’s commitment to Kubernetes, Singh is looking to expand the company’s cloud-native stack. The team already uses <a href="https://prometheus.io/">Prometheus</a> for monitoring, and he says he is evaluating <a href="https://linkerd.io/">Linkerd</a> and <a href="https://envoyproxy.github.io/">Envoy Proxy</a> as a way to "get more metrics about request latencies and failures, and handle them better." Other CNCF projects, including <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://grpc.io/">gRPC</a> are also on his radar.<br><br>
-  Singh has found that the cloud-native community is growing in India, too, particularly in Bangalore. "A lot of startups and new companies are starting to run their infrastructure on Kubernetes," he says. <br><br>
-  And when people ask him about Crowdfire’s experience, he has this advice to offer: "Kubernetes is a great piece of technology, but it might not be right for you, especially if you have just one or two services or your app isn’t easy to run in a containerized environment," he says. "Assess your situation and the value that Kubernetes provides before going all in. If you do decide to use Kubernetes, make sure you understand the components that run under the hood and what role they play in smoothly running the cluster. Another thing to consider is if your apps are ‘Kubernetes-ready,’ meaning if they have proper health checks and handle termination signals to shut down gracefully."<br><br>
-  And if your company fits that profile, go for it. Crowdfire clearly did—and is now reaping the benefits. "In the 15 months that we’ve been using Kubernetes, it has been amazing for us," says Singh. "It enabled us to iterate quickly, increase development speed and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."
+<p>Kubernetes checked all the boxes and then some. "One of the best things was the built-in service discovery," he says. "When you have a bunch of microservices that need to call each other, having internal DNS readily available and service IPs and ports automatically set as environment variables help a lot." Plus, he adds, "Kubernetes's opinionated approach made it easier to get started."</p>
 
+{{< case-studies/quote image="/images/case-studies/crowdfire/banner3.jpg" >}}
+"We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on Terraform and Ansible."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>There was another compelling business reason for the cloud-native approach. "In today's world of ever-changing business requirements, using cloud native technology provides a variety of options to choose from—even the ability to run services in a hybrid cloud environment," says Singh. "Businesses can keep services in a region closest to the users, and thus benefit from high-availability and resiliency."</p>
+
+<p>So in February 2016, Singh set up a test Kubernetes cluster using the kube-up scripts provided. "I explored the features and was able to deploy an application pretty easily," he says. "However, it seemed like a black box since I didn't understand the components completely, and had no idea what the kube-up script did under the hood. So when it broke, it was hard to find the issue and fix it."</p>
+
+<p>To get a better understanding, Singh dove into the internals of Kubernetes, reading the docs and even some of the code. And he looked to the Kubernetes community for more insight. "I used to stay up a little late every night (a lot of users were active only when it's night here in India) and would try to answer questions on the Kubernetes community Slack from users who were getting started," he says. "I would also follow other conversations closely. I must admit I was able to avoid a lot of issues in our setup because I knew others had faced the same issues."</p>
+
+<p>Based on the knowledge he gained, Singh decided to implement a custom setup of Kubernetes based on <a href="https://www.terraform.io/">Terraform</a> and <a href="https://www.ansible.com/">Ansible</a>. "I wrote Terraform to launch Kubernetes master and nodes (Auto Scaling Groups) and an Ansible playbook to install the required components," he says. (The company recently switched to using prebaked <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html">AMIs</a> to make the node bringup faster, and is planning to change its networking layer.)</p>
+
+{{< case-studies/quote image="/images/case-studies/crowdfire/banner4.jpg" >}}
+"Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure."
+{{< /case-studies/quote >}}
+
+<p>First, the team migrated a few staging services from Elastic Beanstalk to the new Kubernetes staging cluster, and then set up a production cluster a month later to deploy some services. The results were convincing. "By the end of March 2016, we established that all the new services must be deployed on Kubernetes," says Singh. "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." On top of that, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines. This brings more visibility into the changes being made, and keeping an audit trail."</p>
+
+<p>Over the next six months, the team worked on migrating all the services from Elastic Beanstalk to Kubernetes, except for the few that were deprecated and would soon be terminated anyway. The services were moved one at a time, and their performance was monitored for two to three days each. Today, "We're completely migrated and we run all new services on Kubernetes," says Singh.</p>
+
+<p>The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.</p>
+
+<p>All 30 engineers at Crowdfire were onboarded at once. "I gave an internal talk where I shared the basic components and demoed the usage of kubectl," says Singh. "Everyone was excited and happy about using Kubernetes. Developers have more control and visibility into their applications running in production now. Most of all, they're happy with the low deploy times and self-healing services."</p>
+
+<p>And they're much more productive, too. "Where we used to do about 5 deployments per day," says Singh, "now we're doing 30+ production and 50+ staging deployments almost every day."</p>
+
+{{< case-studies/quote >}}
+The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.
+{{< /case-studies/quote >}}
+
+<p>Singh notes that almost all of the engineers interact with the staging cluster on a daily basis, and that has created a cultural change at Crowdfire. "Developers are more aware of the cloud infrastructure now," he says. "They've started following cloud best practices like better health checks, structured logs to stdout [standard output], and config via files or environment variables."</p>
+
+<p>With Crowdfire's commitment to Kubernetes, Singh is looking to expand the company's cloud-native stack. The team already uses <a href="https://prometheus.io/">Prometheus</a> for monitoring, and he says he is evaluating <a href="https://linkerd.io/">Linkerd</a> and <a href="https://envoyproxy.github.io/">Envoy Proxy</a> as a way to "get more metrics about request latencies and failures, and handle them better." Other CNCF projects, including <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://grpc.io/">gRPC</a> are also on his radar.</p>
+
+<p>Singh has found that the cloud-native community is growing in India, too, particularly in Bangalore. "A lot of startups and new companies are starting to run their infrastructure on Kubernetes," he says.</p>
+
+<p>And when people ask him about Crowdfire's experience, he has this advice to offer: "Kubernetes is a great piece of technology, but it might not be right for you, especially if you have just one or two services or your app isn't easy to run in a containerized environment," he says. "Assess your situation and the value that Kubernetes provides before going all in. If you do decide to use Kubernetes, make sure you understand the components that run under the hood and what role they play in smoothly running the cluster. Another thing to consider is if your apps are 'Kubernetes-ready,' meaning if they have proper health checks and handle termination signals to shut down gracefully."</p>
+
+<p>And if your company fits that profile, go for it. Crowdfire clearly did—and is now reaping the benefits. "In the 15 months that we've been using Kubernetes, it has been amazing for us," says Singh. "It enabled us to iterate quickly, increase development speed and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."</p>
diff --git a/content/ko/case-studies/golfnow/index.html b/content/ko/case-studies/golfnow/index.html
index f4bf4d4f27..9e82d90cd1 100644
--- a/content/ko/case-studies/golfnow/index.html
+++ b/content/ko/case-studies/golfnow/index.html
@@ -1,125 +1,89 @@
 ---
 title: GolfNow Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_golfnow.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/golfnow/banner1.jpg
+heading_title_logo: /images/golfnow_logo.png
+subheading: >
+  Saving Time and Money with Cloud Native Infrastructure
+case_study_details:
+  - Company: GolfNow
+  - Location: Orlando, Florida
+  - Industry: Golf Industry Technology and Services Provider
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/golfnow_logo.png" width="20%" style="margin-bottom:-6px"><br>
-    <div class="subhead">Saving Time and Money with Cloud Native Infrastructure</div>
-  </h1>
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company&nbsp;<b>GolfNow</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location&nbsp;<b>Orlando, Florida</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry&nbsp;<b>Golf Industry Technology and Services Provider</b>
-</div>
+<p>A member of the <a href="http://www.nbcunicareers.com/our-businesses/nbc-sports-group">NBC Sports Group</a>, <a href="https://www.golfnow.com/">GolfNow</a> is the golf industry's technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow's monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow's Director, Architecture. "We wanted the ability to more easily expand globally."</p>
 
-<hr>
+<h2>Solution</h2>
 
-<section class="section1">
-  <div class="cols">
-    <div class="col1">
+<p>Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on <a href="https://www.docker.com/">Docker</a> and <a href="http://kubernetes.io/">Kubernetes.</a></p>
 
-    <h2>Challenge</h2>
-      A member of the <a href="http://www.nbcunicareers.com/our-businesses/nbc-sports-group">NBC Sports Group</a>, <a href="https://www.golfnow.com/">GolfNow</a> is the golf industry’s technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow’s monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow’s Director, Architecture. "We wanted the ability to more easily expand globally."
-      <br>
-  </div>
+<h2>Impact</h2>
 
-  <div class="col2">
-    <h2>Solution</h2>
-      Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on <a href="https://www.docker.com/">Docker</a> and <a href="http://kubernetes.io/">Kubernetes.</a><br><br>
+<p>The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.</p>
 
-    <h2>Impact</h2>
-      The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.
-    </div>
-  </div>
-</section>
+{{< case-studies/quote author="SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW" >}}
+"With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."
+{{< /case-studies/quote >}}
 
+{{< case-studies/lead >}}
+It's not every day that you can say you've slashed an operating expense by half.
+{{< /case-studies/lead >}}
 
-<div class="banner2">
-  <div class="banner2text">
-      "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."<br><br><span style="font-size:15px;letter-spacing:0.08em">- SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW</span>
-  </div>
-</div>
+<p>But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, <a href="https://www.golfnow.com/">GolfNow</a>, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.</p>
 
-<section class="section2">
-  <div class="fullcol">
-      <h2>It’s not every day that you can say you’ve slashed an operating expense by half.</h2>
+<p>A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow's Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we'd have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."</p>
 
-      But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, <a href="https://www.golfnow.com/">GolfNow</a>, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.
-      <br> <br>
-      A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow’s Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we’d have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."
-      <br> <br>
-      In moving just the first of GolfNow’s important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.
-      <br> <br>
-      The path to those stellar results began in late 2014. In order to support GolfNow’s global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from <a href="https://www.microsoft.com/net">C#.NET</a> and <a href="https://www.microsoft.com/en-cy/sql-server/sql-server-2016">SQL Server</a> since it didn’t run very well on Linux, where everything container was running smoothly."
-      <br> <br>
-      To that end, the team shifted to working with <a href="https://nodejs.org/">Node.js</a>, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and <a href="https://www.mongodb.com/">MongoDB</a>, the open-source database program. At the time, <a href="https://www.docker.com/">Docker</a>, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that’s the way the industry is heading."
-  </div>
-</section>
+<p>In moving just the first of GolfNow's important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all.'"
-  </div>
-</div>
+<p>The path to those stellar results began in late 2014. In order to support GolfNow's global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from <a href="https://www.microsoft.com/net">C#.NET</a> and <a href="https://www.microsoft.com/en-cy/sql-server/sql-server-2016">SQL Server</a> since it didn't run very well on Linux, where everything container was running smoothly."</p>
 
-<section class="section3">
-  <div class="fullcol">
-    GolfNow’s dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? ‘It worked on my machine!’ But then we started getting to the point of, ‘How do we make sure that these things stay up and running?’" <br><br>
-    That led the team on a quest to find the right orchestration system for the company’s needs. Sheriff says the first few options they tried were either too heavy or "didn’t feel quite right." In late summer 2015, they discovered the just-released <a href="http://kubernetes.io/">Kubernetes</a>, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."
-    <br><br>
-    But before they could go with Kubernetes, <a href="http://www.nbc.com/">NBC</a>, GolfNow’s parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company’s platform user interface, but didn’t like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff’s VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who’s now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company’s platform.
-    <br><br>
-    "We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."
-    <br><br>
-    At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, ‘Alright, it’s over. Kubernetes wins.’"
-    <br><br>
-    The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn’t quite finished yet. At the time, it was running in <a href="https://devcenter.heroku.com/articles/mongohq">Heroku Compose</a> and other third-party services—resulting in a large monthly bill.
+<p>To that end, the team shifted to working with <a href="https://nodejs.org/">Node.js</a>, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and <a href="https://www.mongodb.com/">MongoDB</a>, the open-source database program. At the time, <a href="https://www.docker.com/">Docker</a>, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that's the way the industry is heading."</p>
 
-  </div>
-</section>
+{{< case-studies/quote image="/images/case-studies/golfnow/banner3.jpg" >}}
+"The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn't have to pay extra money at all.'"
+{{< /case-studies/quote >}}
 
-  <div class="banner4">
-    <div class="banner4text">
-    "'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night.'"
-    </div>
-  </div>
+<p>GolfNow's dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? 'It worked on my machine!' But then we started getting to the point of, 'How do we make sure that these things stay up and running?'"</p>
 
-<section class="section4">
-  <div class="fullcol">
-    "The goal was to take all of that out and put it within this new platform we’ve created with Kubernetes on <a href="https://cloud.google.com/compute/">Google Compute Engine (GCE)</a>," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We’d take the config, change it and make it hit the database that was running in our cluster."
-    <br><br>
-    Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."
-    <br><br>
-    After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all."
-    <br><br>
-    Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night."
-    <br><br>
-    A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into <a href="https://www.microsoft.com/net/core">.NET Core</a> [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.
-    <br><br>
-    Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with <a href="https://github.com/drone/drone">Drone</a>, an open-source continuous delivery platform, to make it more developer-centric. "Now they’re able to manage configuration, they’re able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."
+<p>That led the team on a quest to find the right orchestration system for the company's needs. Sheriff says the first few options they tried were either too heavy or "didn't feel quite right." In late summer 2015, they discovered the just-released <a href="http://kubernetes.io/">Kubernetes</a>, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."</p>
 
-  </div>
-</section>
+<p>But before they could go with Kubernetes, <a href="http://www.nbc.com/">NBC</a>, GolfNow's parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company's platform user interface, but didn't like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff's VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who's now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company's platform.</p>
 
-  <div class="banner5">
-    <div class="banner5text">
-    "Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient.'"
-    </div>
-  </div>
+<p>"We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."</p>
 
-<section class="section5">
-  <div class="fullcol">
-    And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We’re actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."
-    <br><br>
-    The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that’s more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We’ve tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you’ve given us."
-    <br><br>
-    Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they’ve learned: "You’ve got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can’t have people who are half in, half out." And if you don’t have buy-in from the get go, proving it out will get you there.
-    <br><br>
-    "This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient."
+<p>At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, 'Alright, it's over. Kubernetes wins.'"</p>
 
-  </div>
-</section>
+<p>The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn't quite finished yet. At the time, it was running in <a href="https://devcenter.heroku.com/articles/mongohq">Heroku Compose</a> and other third-party services—resulting in a large monthly bill.</p>
+
+{{< case-studies/quote image="/images/case-studies/golfnow/banner4.jpg" >}}
+"'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven't come from the Kubernetes world you wouldn't believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn't sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I've been sleeping at night.'"
+{{< /case-studies/quote >}}
+
+<p>"The goal was to take all of that out and put it within this new platform we've created with Kubernetes on <a href="https://cloud.google.com/compute/">Google Compute Engine (GCE)</a>," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We'd take the config, change it and make it hit the database that was running in our cluster."</p>
+
+<p>Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."</p>
+
+<p>After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn't have to pay extra money at all."</p>
+
+<p>Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven't come from the Kubernetes world you wouldn't believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn't sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I've been sleeping at night."</p>
+
+<p>A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into <a href="https://www.microsoft.com/net/core">.NET Core</a> [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.</p>
+
+<p>Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with <a href="https://github.com/drone/drone">Drone</a>, an open-source continuous delivery platform, to make it more developer-centric. "Now they're able to manage configuration, they're able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."</p>
+
+{{< case-studies/quote >}}
+"Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They're faster, they're more resilient.'"
+{{< /case-studies/quote >}}
+
+<p>And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We're actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."</p>
+
+<p>The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that's more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We've tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you've given us."</p>
+
+<p>Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they've learned: "You've got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can't have people who are half in, half out." And if you don't have buy-in from the get go, proving it out will get you there.</p>
+
+<p>"This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They're faster, they're more resilient."</p>
diff --git a/content/ko/case-studies/haufegroup/index.html b/content/ko/case-studies/haufegroup/index.html
index f4256ff569..580a282683 100644
--- a/content/ko/case-studies/haufegroup/index.html
+++ b/content/ko/case-studies/haufegroup/index.html
@@ -1,112 +1,85 @@
 ---
 title: Haufe Group Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_haufegroup.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/haufegroup/banner1.jpg
+heading_title_logo: /images/haufegroup_logo.png
+subheading: >
+  Paving the Way for Cloud Native for Midsize Companies
+case_study_details:
+  - Company: Haufe Group
+  - Location: Freiburg, Germany
+  - Industry: Media and Software
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/haufegroup_logo.png" class="header_logo"><br> <div class="subhead">Paving the Way for Cloud Native for Midsize Companies</div></h1>
+<p>Founded in 1930 as a traditional publisher, Haufe Group has grown into a media and software company with 95 percent of its sales from digital products. Over the years, the company has gone from having "hardware in the basement" to outsourcing its infrastructure operations and IT. More recently, the development of new products, from Internet portals for tax experts to personnel training software, has created demands for increased speed, reliability and scalability. "We need to be able to move faster," says Solution Architect Martin Danielsson. "Adapting workloads is something that we really want to be able to do."</p>
 
-</div>
+<h2>Solution</h2>
+<p>Haufe Group began its cloud-native journey when <a href="https://azure.microsoft.com/">Microsoft Azure</a> became available in Europe; the company needed cloud deployments for its desktop apps with bandwidth-heavy download services. "After that, it has been different projects trying out different things," says Danielsson. Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy.</p>
 
-<div class="details">
-    Company &nbsp;<b>Haufe Group</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Freiburg, Germany</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Media and Software</b>
-</div>
+<p>A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. The company is now getting ready to go live with two services in production using <a href="https://kubernetes.io/">Kubernetes</a> orchestration on <a href="https://azure.microsoft.com/">Microsoft Azure</a> and <a href="https://aws.amazon.com/">Amazon Web Services</a>. The team is also working on breaking up one of their core Java Enterprise desktop products into microservices to allow for better evolvability and dynamic scaling in the cloud.</p>
 
-<hr>
-
-<section class="section1">
-
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        Founded in 1930 as a traditional publisher, Haufe Group has grown into a media and software company with 95 percent of its sales from digital products. Over the years, the company has gone from having "hardware in the basement" to outsourcing its infrastructure operations and IT. More recently, the development of new products, from Internet portals for tax experts to personnel training software, has created demands for increased speed, reliability and scalability. "We need to be able to move faster," says Solution Architect Martin Danielsson. "Adapting workloads is something that we really want to be able to do."
-    <br>
-    <br>
-      <h2>Solution</h2>
-      Haufe Group began its cloud-native journey when <a href="https://azure.microsoft.com/">Microsoft Azure</a> became available in Europe; the company needed cloud deployments for its desktop apps with bandwidth-heavy download services. "After that, it has been different projects trying out different things," says Danielsson. Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy.
-      </div>
-<div class="col2">
-  A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. The company is now getting ready to go live with two services in production using <a href="https://kubernetes.io/">Kubernetes</a> orchestration on <a href="https://azure.microsoft.com/">Microsoft Azure</a> and <a href="https://aws.amazon.com/">Amazon Web Services</a>. The team is also working on breaking up one of their core Java Enterprise desktop products into microservices to allow for better evolvability and dynamic scaling in the cloud.
-<br>
-<br>
 <h2>Impact</h2>
-        With the ability to adapt workloads, Danielsson says, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." Plus, shorter release times have had a major impact. "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," he says. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."
+<p>With the ability to adapt workloads, Danielsson says, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." Plus, shorter release times have had a major impact. "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," he says. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."</p>
 
-</div>
-</div>
+{{< case-studies/quote author="Martin Danielsson, Solution Architect, Haufe Group" >}}
+"Over the next couple of years, people won't even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution."
+{{< /case-studies/quote >}}
 
-</section>
+{{< case-studies/lead >}}
+More than 80 years ago, Haufe Group was founded as a traditional publishing company, printing books and commentary on paper.
+{{< /case-studies/lead >}}
 
-<div class="banner2">
-  <div class="banner2text">
-     "Over the next couple of years, people won’t even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Martin Danielsson, Solution Architect, Haufe Group</span>
-  </div>
-</div>
+<p>By the 1990s, though, the company's leaders recognized that the future was digital, and to their credit, were able to transform Haufe Group into a media and software business that now gets 95 percent of its sales from digital products. "Among the German companies doing this, we were one of the early adopters," says Martin Danielsson, Solution Architect for Haufe Group.</p>
 
-<section class="section2">
+<p>And now they're leading the way for midsize companies embracing cloud-native technology like Kubernetes. "The really big companies like Ticketmaster and Google get it right, and the startups get it right because they're faster," says Danielsson. "We're in this big lump of companies in the middle with a lot of legacy, a lot of structure, a lot of culture that does not easily fit the cloud technologies. We're just 1,500 people, but we have hundreds of customer-facing applications. So we're doing things that will be relevant for many companies of our size or even smaller."</p>
 
-<div class="fullcol">
-    <h2>More than 80 years ago, Haufe Group was founded as a traditional publishing company, printing books and commentary on paper.</h2> By the 1990s, though, the company’s leaders recognized that the future was digital, and to their credit, were able to transform Haufe Group into a media and software business that now gets 95 percent of its sales from digital products. "Among the German companies doing this, we were one of the early adopters," says Martin Danielsson, Solution Architect for Haufe Group.<br><br>
-    And now they’re leading the way for midsize companies embracing cloud-native technology like Kubernetes. "The really big companies like Ticketmaster and Google get it right, and the startups get it right because they’re faster," says Danielsson. "We’re in this big lump of companies in the middle with a lot of legacy, a lot of structure, a lot of culture that does not easily fit the cloud technologies. We’re just 1,500 people, but we have hundreds of customer-facing applications. So we’re doing things that will be relevant for many companies of our size or even smaller."<br><br>
-    Many of those legacy challenges stemmed from simply following the technology trends of the times. "We used to do full DevOps," he says. In the 1990s and 2000s, "that meant that you had your hardware in the basement. And then 10 years ago, the hype of the moment was to outsource application operations, outsource everything, and strip down your IT department to take away the distraction of all these hardware things. That’s not our area of expertise. We didn’t want to be an infrastructure provider. And now comes the backlash of that."<br><br>
-    Haufe Group began feeling the pain as they were developing more new products, from Internet portals for tax experts to personnel training software, that have created demands for increased speed, reliability and scalability. "Right now, we have this break in workflows, where we go from writing concepts to developing, handing it over to production and then handing that over to your host provider," he says. "And then when things go bad we have no clue what went wrong. We definitely want to take back control, and we want to move a lot faster. Adapting workloads is something that we really want to be able to do."<br><br>
-    Those needs led them to explore cloud-native technology. Their first foray into the cloud was doing deployments in <a href="https://azure.microsoft.com/">Microsoft Azure</a>, once it became available in Europe, for desktop products that had built-in download services. Hosting expenses for such bandwidth-heavy services were too high, so the company turned to the cloud. "After that, it has been different projects trying out different things," says Danielsson.
-</div>
-</section>
+<p>Many of those legacy challenges stemmed from simply following the technology trends of the times. "We used to do full DevOps," he says. In the 1990s and 2000s, "that meant that you had your hardware in the basement. And then 10 years ago, the hype of the moment was to outsource application operations, outsource everything, and strip down your IT department to take away the distraction of all these hardware things. That's not our area of expertise. We didn't want to be an infrastructure provider. And now comes the backlash of that."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn’t fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."
-  </div>
-</div>
+<p>Haufe Group began feeling the pain as they were developing more new products, from Internet portals for tax experts to personnel training software, that have created demands for increased speed, reliability and scalability. "Right now, we have this break in workflows, where we go from writing concepts to developing, handing it over to production and then handing that over to your host provider," he says. "And then when things go bad we have no clue what went wrong. We definitely want to take back control, and we want to move a lot faster. Adapting workloads is something that we really want to be able to do."</p>
 
-<section class="section3">
-<div class="fullcol">
+<p>Those needs led them to explore cloud-native technology. Their first foray into the cloud was doing deployments in <a href="https://azure.microsoft.com/">Microsoft Azure</a>, once it became available in Europe, for desktop products that had built-in download services. Hosting expenses for such bandwidth-heavy services were too high, so the company turned to the cloud. "After that, it has been different projects trying out different things," says Danielsson.</p>
 
-      Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy. A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker.
-      Some experiments went further than others; German regulations about sensitive data proved to be a road block in moving some workloads to Azure and Amazon Web Services. "Due to our history, Germany is really strict with things like personally identifiable data," Danielsson says.<br><br>
-      These experiments took on new life with the arrival of the Azure Sovereign Cloud for Germany (an Azure clone run by the German T-Systems provider). With the availability of Azure.de—which conforms to Germany’s privacy regulations—teams started to seriously consider deploying production loads in Docker into the cloud. "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn’t fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."<br><br>
-      In parallel, Danielsson had built an API management system with the aim of supporting CI/CD scenarios, aspects of which were missing in off-the-shelf API management products. With a foundation based on <a href="https://getkong.org/">Mashape’s Kong</a> gateway, it is open-sourced as <a href="http://wicked.haufe.io/">wicked.haufe.io</a>. He put wicked.haufe.io to use with his product team.<br><br> Otherwise, Danielsson says his philosophy was "don’t try to reinvent the wheel all the time. Go for what’s there and 99 percent of the time it will be enough. And if you think you really need something custom or additional, think perhaps once or twice again. One of the things that I find so amazing with this cloud-native framework is that everything ties in."<br><br>
-      Currently, Haufe Group is working on two projects using Kubernetes in production. One is a new mobile application for researching legislation and tax laws. "We needed a way to take out functionality from a legacy core and put an application on top of that with an API gateway—a lot of moving parts that screams containers," says Danielsson. So the team moved the build pipeline away from "deploying to some old, huge machine that you could deploy anything to" and onto a Kubernetes cluster where there would be automatic CI/CD "with feature branches and all these things that were a bit tedious in the past."
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/haufegroup/banner3.jpg" >}}
+"We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn't fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."
+{{< /case-studies/quote >}}
 
-<div class="banner4">
-  <div class="banner4text">
-     "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."
-  </div>
-</div>
+<p>Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy. A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. Some experiments went further than others; German regulations about sensitive data proved to be a road block in moving some workloads to Azure and Amazon Web Services. "Due to our history, Germany is really strict with things like personally identifiable data," Danielsson says.</p>
 
-<section class="section4">
-<div class="fullcol">
-      It was a proof of concept effort, and the proof was in the pudding. "Everyone was really impressed at what we accomplished in a week," says Danielsson. "We did these kinds of integrations just to make sure that we got a handle on how Kubernetes works. If you can create optimism and buzz around something, it’s half won. And if the developers and project managers know this is working, you’re more or less done." Adds Reinhardt: "You need to create some very visible, quick wins in order to overcome the status quo."<br><br>
-      The impact on the speed of deployment was clear: "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days." <br><br>
-      The potential impact on cost was another bonus. "Hosting applications is quite expensive, so moving to the cloud is something that we really want to be able to do," says Danielsson. With the ability to adapt workloads, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." <br><br>
-      Just as importantly, Danielsson says, there’s added flexibility: "When we try to move or rework applications that are really crucial, it’s often tricky to validate whether the path we want to take is going to work out well. In order to validate that, we would need to reproduce the environment and really do testing, and that’s prohibitively expensive and simply not doable with traditional host providers. Cloud native gives us the ability to do risky changes and validate them in a cost-effective way."<br><br>
-      As word of the two successful test projects spread throughout the company, interest in Kubernetes has grown. "We want to be able to support our developers in running Kubernetes clusters but we’re not there yet, so we allow them to do it as long as they’re aware that they are on their own," says Danielsson. "So that’s why we are also looking at things like [the managed Kubernetes platform] <a href="https://coreos.com/tectonic/">CoreOS Tectonic</a>, <a href="https://azure.microsoft.com/en-us/services/container-service/">Azure Container Service</a>, <a href="https://aws.amazon.com/ecs/">ECS</a>, etc. These kinds of services will be a lot more relevant to midsize companies that want to leverage cloud native but don’t have the IT departments or the structure around that."<br><br>
-      In the next year and a half, Danielsson says the company will be working on moving one of their legacy desktop products, a web app for researching legislation and tax laws originally built in Java Enterprise, onto cloud-native technology. "We’re doing a microservice split out right now so that we can independently deploy the different parts," he says. The main website, which provides free content for customers, is also moving to cloud native.
+<p>These experiments took on new life with the arrival of the Azure Sovereign Cloud for Germany (an Azure clone run by the German T-Systems provider). With the availability of Azure.de—which conforms to Germany's privacy regulations—teams started to seriously consider deploying production loads in Docker into the cloud. "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn't fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."</p>
 
-</div>
-</section>
+<p>In parallel, Danielsson had built an API management system with the aim of supporting CI/CD scenarios, aspects of which were missing in off-the-shelf API management products. With a foundation based on <a href="https://getkong.org/">Mashape's Kong</a> gateway, it is open-sourced as <a href="http://wicked.haufe.io/">wicked.haufe.io</a>. He put wicked.haufe.io to use with his product team.<br><br> Otherwise, Danielsson says his philosophy was "don't try to reinvent the wheel all the time. Go for what's there and 99 percent of the time it will be enough. And if you think you really need something custom or additional, think perhaps once or twice again. One of the things that I find so amazing with this cloud-native framework is that everything ties in."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-     "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."
+<p>Currently, Haufe Group is working on two projects using Kubernetes in production. One is a new mobile application for researching legislation and tax laws. "We needed a way to take out functionality from a legacy core and put an application on top of that with an API gateway—a lot of moving parts that screams containers," says Danielsson. So the team moved the build pipeline away from "deploying to some old, huge machine that you could deploy anything to" and onto a Kubernetes cluster where there would be automatic CI/CD "with feature branches and all these things that were a bit tedious in the past."</p>
 
-  </div>
-</div>
+{{< case-studies/quote image="/images/case-studies/haufegroup/banner4.jpg" >}}
+"Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."
+{{< /case-studies/quote >}}
 
-<section class="section5">
-<div class="fullcol">
-  But with these goals, Danielsson believes there are bigger cultural challenges that need to be constantly addressed. The move to new technology, not to mention a shift toward DevOps, means a lot of change for employees. "The roles were rather fixed in the past," he says. "You had developers, you had project leads, you had testers. And now you get into these really, really important things like test automation. Testers aren’t actually doing click testing anymore, and they have to write automated testing. And if you really want to go full-blown CI/CD, all these little pieces have to work together so that you get the confidence to do a check in, and know this check in is going to land in production, because if I messed up, some test is going to break. This is a really powerful thing because whatever you do, whenever you merge something into the trunk or to the master, this is going live. And that’s where you either get the people or they run away screaming."
-  Danielsson understands that it may take some people much longer to get used to the new ways.<br><br>
-  "Culture is nothing that you can force on people," he says. "You have to live it for yourself. You have to evangelize. You have to show the advantages time and time again: This is how you can do it, this is what you get from it." To that end, his team has scheduled daylong workshops for the staff, bringing in outside experts to talk about everything from API to Devops to cloud. <br><br>
-  For every person who runs away screaming, many others get drawn in. "Get that foot in the door and make them really interested in this stuff," says Danielsson. "Usually it catches on. We have people you never would have expected chanting, ‘Docker Docker Docker’ now. It’s cool to see them realize that there is a world outside of their Python libraries. It’s awesome to see them really work with Kubernetes."<br><br>
-  Ultimately, Reinhardt says, "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."
+<p>It was a proof of concept effort, and the proof was in the pudding. "Everyone was really impressed at what we accomplished in a week," says Danielsson. "We did these kinds of integrations just to make sure that we got a handle on how Kubernetes works. If you can create optimism and buzz around something, it's half won. And if the developers and project managers know this is working, you're more or less done." Adds Reinhardt: "You need to create some very visible, quick wins in order to overcome the status quo."</p>
 
-</div>
-</section>
+<p>The impact on the speed of deployment was clear: "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."</p>
+
+<p>The potential impact on cost was another bonus. "Hosting applications is quite expensive, so moving to the cloud is something that we really want to be able to do," says Danielsson. With the ability to adapt workloads, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost."</p>
+
+<p>Just as importantly, Danielsson says, there's added flexibility: "When we try to move or rework applications that are really crucial, it's often tricky to validate whether the path we want to take is going to work out well. In order to validate that, we would need to reproduce the environment and really do testing, and that's prohibitively expensive and simply not doable with traditional host providers. Cloud native gives us the ability to do risky changes and validate them in a cost-effective way."</p>
+
+<p>As word of the two successful test projects spread throughout the company, interest in Kubernetes has grown. "We want to be able to support our developers in running Kubernetes clusters but we're not there yet, so we allow them to do it as long as they're aware that they are on their own," says Danielsson. "So that's why we are also looking at things like [the managed Kubernetes platform] <a href="https://coreos.com/tectonic/">CoreOS Tectonic</a>, <a href="https://azure.microsoft.com/en-us/services/container-service/">Azure Container Service</a>, <a href="https://aws.amazon.com/ecs/">ECS</a>, etc. These kinds of services will be a lot more relevant to midsize companies that want to leverage cloud native but don't have the IT departments or the structure around that."</p>
+
+<p>In the next year and a half, Danielsson says the company will be working on moving one of their legacy desktop products, a web app for researching legislation and tax laws originally built in Java Enterprise, onto cloud-native technology. "We're doing a microservice split out right now so that we can independently deploy the different parts," he says. The main website, which provides free content for customers, is also moving to cloud native.</p>
+
+{{< case-studies/quote >}}
+"the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."
+{{< /case-studies/quote >}}
+
+<p>But with these goals, Danielsson believes there are bigger cultural challenges that need to be constantly addressed. The move to new technology, not to mention a shift toward DevOps, means a lot of change for employees. "The roles were rather fixed in the past," he says. "You had developers, you had project leads, you had testers. And now you get into these really, really important things like test automation. Testers aren't actually doing click testing anymore, and they have to write automated testing. And if you really want to go full-blown CI/CD, all these little pieces have to work together so that you get the confidence to do a check in, and know this check in is going to land in production, because if I messed up, some test is going to break. This is a really powerful thing because whatever you do, whenever you merge something into the trunk or to the master, this is going live. And that's where you either get the people or they run away screaming." Danielsson understands that it may take some people much longer to get used to the new ways.</p>
+
+<p>"Culture is nothing that you can force on people," he says. "You have to live it for yourself. You have to evangelize. You have to show the advantages time and time again: This is how you can do it, this is what you get from it." To that end, his team has scheduled daylong workshops for the staff, bringing in outside experts to talk about everything from API to Devops to cloud.</p>
+
+<p>For every person who runs away screaming, many others get drawn in. "Get that foot in the door and make them really interested in this stuff," says Danielsson. "Usually it catches on. We have people you never would have expected chanting, 'Docker Docker Docker' now. It's cool to see them realize that there is a world outside of their Python libraries. It's awesome to see them really work with Kubernetes."</p>
+
+<p>Ultimately, Reinhardt says, "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."</p>
diff --git a/content/ko/case-studies/huawei/index.html b/content/ko/case-studies/huawei/index.html
index 29de86f5c4..ec1cd212f2 100644
--- a/content/ko/case-studies/huawei/index.html
+++ b/content/ko/case-studies/huawei/index.html
@@ -1,101 +1,73 @@
 ---
 title: Huawei Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_huawei.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/huawei/banner1.jpg
+heading_title_logo: /images/huawei_logo.png
+subheading: >
+  Embracing Cloud Native as a User – and a Vendor
+case_study_details:
+  - Company: Huawei
+  - Location: Shenzhen, China
+  - Industry: Telecommunications Equipment
 ---
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/huawei_logo.png" class="header_logo"><br> <div class="subhead">Embracing Cloud Native as a User – and a Vendor</div></h1>
 
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>Huawei</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Shenzhen, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Telecommunications Equipment</b>
-</div>
+<p>A multinational company that's the largest telecommunications equipment manufacturer in the world, Huawei has more than 180,000 employees. In order to support its fast business development around the globe, <a href="http://www.huawei.com/">Huawei</a> has eight data centers for its internal I.T. department, which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. With the rapid increase of new applications, the cost and efficiency of management and deployment of VM-based apps all became critical challenges for business agility. "It's very much a distributed system so we found that managing all of the tasks in a more consistent way is always a challenge," says Peixin Hou, the company's Chief Software Architect and Community Director for Open Source. "We wanted to move into a more agile and decent practice."</p>
 
-<hr>
+<h2>Solution</h2>
 
-<section class="section1">
+<p>After deciding to use container technology, Huawei began moving the internal I.T. department's applications to run on <a href="http://kubernetes.io/">Kubernetes</a>. So far, about 30 percent of these applications have been transferred to cloud native.</p>
 
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        A multinational company that’s the largest telecommunications equipment manufacturer in the world, Huawei has more than 180,000 employees. In order to support its fast business development around the globe, <a href="http://www.huawei.com/">Huawei</a> has eight data centers for its internal I.T. department, which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. With the rapid increase of new applications, the cost and efficiency of management and deployment of VM-based apps all became critical challenges for business agility. "It’s very much a distributed system so we found that managing all of the tasks in a more consistent way is always a challenge," says Peixin Hou, the company’s Chief Software Architect and Community Director for Open Source. "We wanted to move into a more agile and decent practice."
-      </div>
-
-<div class="col2">
-  <h2>Solution</h2>
-      After deciding to use container technology, Huawei began moving the internal I.T. department’s applications to run on <a href="http://kubernetes.io/">Kubernetes</a>. So far, about 30 percent of these applications have been transferred to cloud native.
-<br>
-<br>
 <h2>Impact</h2>
-      "By the end of 2016, Huawei’s internal I.T. department managed more than 4,000 nodes with tens of thousands containers using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou. "The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold." For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent, which we think is very helpful for our business." Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies into <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a>, the PaaS solution it offers its customers.
-</div>
 
-</div>
+<p>"By the end of 2016, Huawei's internal I.T. department managed more than 4,000 nodes with tens of thousands containers using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou. "The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold." For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent, which we think is very helpful for our business." Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies into <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a>, the PaaS solution it offers its customers.</p>
 
-</section>
+{{< case-studies/quote author="Peixin Hou, chief software architect and community director for open source" >}}
+"If you're a vendor, in order to convince your customer, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology."
+{{< /case-studies/quote >}}
 
-<div class="banner2">
-  <div class="banner2text">
-    "If you’re a vendor, in order to convince your customer, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Peixin Hou, chief software architect and community director for open source</span>
-  </div>
-</div>
+<p>Huawei's Kubernetes journey began with one developer. Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested in <a href="http://kubernetes.io/">Kubernetes</a>, the technology for managing application containers across clusters of hosts, and started contributing to its open source community. As the technology developed and the community grew, he kept telling his managers about it.</p>
 
-<section class="section2">
+<p>And as fate would have it, at the same time, Huawei was looking for a better orchestration system for its internal enterprise I.T. department, which supports every business flow processing. "We have more than 180,000 employees worldwide, and a complicated internal procedure, so probably every week this department needs to develop some new applications," says Peixin Hou, Huawei's Chief Software Architect and Community Director for Open Source. "Very often our I.T. departments need to launch tens of thousands of containers, with tasks running across thousands of nodes across the world. It's very much a distributed system, so we found that managing all of the tasks in a more consistent way is always a challenge."</p>
 
-<div class="fullcol">
-      Huawei’s Kubernetes journey began with one developer.
-    Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested in <a href="http://kubernetes.io/">Kubernetes</a>, the technology for managing application containers across clusters of hosts, and started contributing to its open source community. As the technology developed and the community grew, he kept telling his managers about it.<br><br>
-    And as fate would have it, at the same time, Huawei was looking for a better orchestration system for its internal enterprise I.T. department, which supports every business flow processing. "We have more than 180,000 employees worldwide, and a complicated internal procedure, so probably every week this department needs to develop some new applications," says Peixin Hou, Huawei’s Chief Software Architect and Community Director for Open Source. "Very often our I.T. departments need to launch tens of thousands of containers, with tasks running across thousands of nodes across the world. It’s very much a distributed system, so we found that managing all of the tasks in a more consistent way is always a challenge."<br><br>
-    In the past, Huawei had used virtual machines to encapsulate applications, but "every time when we start a VM," Hou says, "whether because it’s a new service or because it was a service that was shut down because of some abnormal node functioning, it takes a lot of time."  Huawei turned to containerization, so the timing was right to try Kubernetes. It took a year to adopt that engineer’s suggestion – the process "is not overnight," says Hou – but once in use, he says, "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."<br><br>
-    Hou sees great benefits to the company that come with using this technology: "Kubernetes brings agility, scale-out capability, and DevOps practice to the cloud-based applications," he says. "It provides us with the ability to customize the scheduling architecture, which makes possible the affinity between container tasks that gives greater efficiency. It supports multiple container formats. It has extensive support for various container networking solutions and container storage."
-</div>
-</section>
+<p>In the past, Huawei had used virtual machines to encapsulate applications, but "every time when we start a VM," Hou says, "whether because it's a new service or because it was a service that was shut down because of some abnormal node functioning, it takes a lot of time."  Huawei turned to containerization, so the timing was right to try Kubernetes. It took a year to adopt that engineer's suggestion – the process "is not overnight," says Hou – but once in use, he says, "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."</p>
 
-<div class="banner3">
-  <div class="banner3text">
-    "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."
-  </div>
-</div>
+<p>Hou sees great benefits to the company that come with using this technology: "Kubernetes brings agility, scale-out capability, and DevOps practice to the cloud-based applications," he says. "It provides us with the ability to customize the scheduling architecture, which makes possible the affinity between container tasks that gives greater efficiency. It supports multiple container formats. It has extensive support for various container networking solutions and container storage."</p>
 
-<section class="section3">
-<div class="fullcol">
-      And not least of all, there’s an impact on the bottom line. Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent, which is very helpful for our business."<br><br>
-    Pleased with those initial results, and seeing a demand for cloud native technologies from its customers, Huawei doubled down on Kubernetes. In the spring of 2016, the company became not only a user but also a vendor.<br><br>
-    "We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei’s <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a> PaaS offering. "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them. We’ve started to work with some Chinese banks, and we see a lot of interest from our customers like <a href="http://www.chinamobileltd.com/">China Mobile</a> and <a href="https://www.telekom.com/en">Deutsche Telekom</a>."<br><br>
-    "If you’re just a user, you’re just a user," adds Hou. "But if you’re a vendor, in order to even convince your customers, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology. We provide customer wisdom." While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei’s solutions. It’s a big selling point that most of the public cloud providers now support Kubernetes. "This makes the cross-cloud transition much easier than with other solutions," says Hou.<br><br>
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/huawei/banner3.jpg" >}}
+"Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."
+{{< /case-studies/quote >}}
 
-<div class="banner4">
-  <div class="banner4text">
-    "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them."
-  </div>
-</div>
+<p>And not least of all, there's an impact on the bottom line. Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent, which is very helpful for our business."</p>
 
-<section class="section4">
-<div class="fullcol">
-  Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes, Hou is looking to convince more departments to move over to the cloud native development cycle and practice. "We have a lot of software developers, so we will provide them with our platform as a service solution, our own product," he says. "We would like to see significant cuts in their iteration cycle."<br><br>
-    Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology: "When you start to design the architecture of your application, think about cloud native, think about microservice architecture from the beginning," he says. "I think you will benefit from that."<br><br>
-  But if you already have legacy applications, "start from some microservice-friendly part of those applications first, parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says. "Don’t think from day one that within how many days I want to move the whole architecture, or move everything into microservices. Don’t put that as a kind of target. You should do it in a gradual manner. And I would say for legacy applications, not every piece would be suitable for microservice architecture. No need to force it."<br><br>
-  After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There’s still 20 percent that’s not, but it’s fine. If we can make 80 percent of our workload really be cloud native, to have agility, it’s a much better world at the end of the day."
+<p>Pleased with those initial results, and seeing a demand for cloud native technologies from its customers, Huawei doubled down on Kubernetes. In the spring of 2016, the company became not only a user but also a vendor.</p>
 
-</div>
-</section>
+<p>"We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei's <a href="http://developer.huawei.com/ict/en/site-paas">FusionStage™</a> PaaS offering. "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them. We've started to work with some Chinese banks, and we see a lot of interest from our customers like <a href="http://www.chinamobileltd.com/">China Mobile</a> and <a href="https://www.telekom.com/en">Deutsche Telekom</a>."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "In the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There’s still 20 percent that’s not, but it’s fine. If we can make 80 percent of our workload really be cloud native, to have agility, it’s a much better world at the end of the day."
+<p>"If you're just a user, you're just a user," adds Hou. "But if you're a vendor, in order to even convince your customers, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology. We provide customer wisdom." While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei's solutions. It's a big selling point that most of the public cloud providers now support Kubernetes. "This makes the cross-cloud transition much easier than with other solutions," says Hou.</p>
 
-  </div>
-</div>
-<section class="section5">
-<div class="fullcol">
-  In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes, not least of all the ones that Huawei is contributing to. Huawei engineers have worked on the federation feature (which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling, container networking and storage, and a just-announced technology called <a href="http://containerops.org/">Container Ops</a>, which is a DevOps pipeline engine. "This will put every DevOps job into a container," he explains. "And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes. With that mechanism, we can make the containerized DevOps jobs be created, shared and managed much more easily than before."<br><br>
-  Still, Hou sees this technology as only halfway to its full potential. First and foremost, he’d like to expand the scale it can orchestrate, which is important for supersized companies like Huawei –  as well as some of its customers.<br><br>
-  Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes, Huawei is now a top contributor to the community. "We’ve learned that the more you contribute to the community," he says, "the more you get back."
+{{< case-studies/quote image="/images/case-studies/huawei/banner4.jpg" >}}
+"Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+<p>Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes, Hou is looking to convince more departments to move over to the cloud native development cycle and practice. "We have a lot of software developers, so we will provide them with our platform as a service solution, our own product," he says. "We would like to see significant cuts in their iteration cycle."</p>
+
+<p>Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology: "When you start to design the architecture of your application, think about cloud native, think about microservice architecture from the beginning," he says. "I think you will benefit from that."</p>
+
+<p>But if you already have legacy applications, "start from some microservice-friendly part of those applications first, parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says. "Don't think from day one that within how many days I want to move the whole architecture, or move everything into microservices. Don't put that as a kind of target. You should do it in a gradual manner. And I would say for legacy applications, not every piece would be suitable for microservice architecture. No need to force it."</p>
+
+<p>After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There's still 20 percent that's not, but it's fine. If we can make 80 percent of our workload really be cloud native, to have agility, it's a much better world at the end of the day."</p>
+
+{{< case-studies/quote >}}
+"In the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There's still 20 percent that's not, but it's fine. If we can make 80 percent of our workload really be cloud native, to have agility, it's a much better world at the end of the day."
+{{< /case-studies/quote >}}
+
+<p>In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes, not least of all the ones that Huawei is contributing to. Huawei engineers have worked on the federation feature (which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling, container networking and storage, and a just-announced technology called <a href="http://containerops.org/">Container Ops</a>, which is a DevOps pipeline engine. "This will put every DevOps job into a container," he explains. "And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes. With that mechanism, we can make the containerized DevOps jobs be created, shared and managed much more easily than before."</p>
+
+<p>Still, Hou sees this technology as only halfway to its full potential. First and foremost, he'd like to expand the scale it can orchestrate, which is important for supersized companies like Huawei –  as well as some of its customers.</p>
+
+<p>Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes, Huawei is now a top contributor to the community. "We've learned that the more you contribute to the community," he says, "the more you get back."</p>
diff --git a/content/ko/case-studies/ibm/index.html b/content/ko/case-studies/ibm/index.html
index e9a78a9443..aa3f108e1c 100644
--- a/content/ko/case-studies/ibm/index.html
+++ b/content/ko/case-studies/ibm/index.html
@@ -1,108 +1,80 @@
 ---
 title: IBM Case Study
-
 linkTitle: IBM
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: ibm_featured_logo.svg
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ibm/banner1.jpg
+heading_title_logo: /images/ibm_logo.png
+subheading: >
+  Building an Image Trust Service on Kubernetes with Notary and TUF
+case_study_details:
+  - Company: IBM
+  - Location: Armonk, New York
+  - Industry: Cloud Computing
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/ibm/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ibm_logo.png" class="header_logo" style="width:10%"><br> <div class="subhead">Building an Image Trust Service on Kubernetes with Notary and TUF</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p><a href="https://www.ibm.com/cloud/">IBM Cloud</a> offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed <a href="https://kubernetes.io">Kubernetes</a> and containers, to <a href="https://www.cloudfoundry.org">Cloud Foundry</a> platform as a service (PaaS). These runtimes are combined with the power of the company's enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM's Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service.</p>
 
-<div class="details">
-    Company &nbsp;<b>IBM</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Armonk, New York</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Cloud Computing</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:95%">
-    <h2>Challenge</h2>
-        <a href="https://www.ibm.com/cloud/">IBM Cloud</a> offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed <a href="https://kubernetes.io">Kubernetes</a> and containers, to <a href="https://www.cloudfoundry.org">Cloud Foundry</a> platform as a service (PaaS). These runtimes are combined with the power of the company’s enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM’s Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service.
-<br><br>
- <h2>Solution</h2>
-      The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the <a href="https://www.cncf.io">Cloud Native Computing Foundation (CNCF)</a> open source project <a href="https://github.com/theupdateframework/notary">Notary</a>, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM’s trust story, since it makes it possible for users to consume the company’s Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM’s cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they're loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification.
-
-      </div>
-
-<div class="col2" style="width:95%">
+<h2>Solution</h2>
 
+<p>The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the <a href="https://www.cncf.io">Cloud Native Computing Foundation (CNCF)</a> open source project <a href="https://github.com/theupdateframework/notary">Notary</a>, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM's trust story, since it makes it possible for users to consume the company's Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM's cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they're loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification.</p>
 
 <h2>Impact</h2>
-     IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose."
 
+<p>IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose."</p>
 
-</div>
+{{< case-studies/quote author="Michael Hough, a software developer with the IBM Container Registry team" >}}
+"We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-   "We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Michael Hough, a software developer with the IBM Container Registry team</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Docker had already created the Notary project as an implementation of <a href="https://github.com/theupdateframework/specification" style="text-decoration:underline">The Update Framework (TUF)</a>, and this implementation of TUF provided the capabilities for Docker Content Trust.</h2> "After contribution to CNCF of both TUF and Notary, we perceived that it was becoming the de facto standard for image signing in the container ecosystem", says Michael Hough, a software developer with the IBM Cloud Container Registry team.
-<br><br>
-The key reason for selecting Notary was that it was already compatible with the existing authentication stack IBM’s container registry was using. So was the design of TUF, which does not require the registry team to have to enter the business of key management. Both of these were "attractive design decisions that confirmed our choice of Notary," he says.
-<br><br>
-The introduction of Notary to implement image signing capability in IBM Cloud encourages increased security across IBM's cloud platform, "where we expect it will include both the signing of official IBM images as well as expected use by security-conscious enterprise customers," Hough says. "When combined with security policy implementations, we expect an increased use of deployment policies in CI/CD pipelines that allow for fine-grained control of service deployment based on image signers."
-The availability of image signing "is a huge benefit to security-conscious customers who require this level of image provenance and security," Hough says. "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."
+{{< case-studies/lead >}}
+Docker had already created the Notary project as an implementation of <a href="https://github.com/theupdateframework/specification">The Update Framework (TUF)</a>, and this implementation of TUF provided the capabilities for Docker Content Trust.
+{{< /case-studies/lead >}}
 
+<p>"After contribution to CNCF of both TUF and Notary, we perceived that it was becoming the de facto standard for image signing in the container ecosystem", says Michael Hough, a software developer with the IBM Cloud Container Registry team.</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ibm/banner3.jpg')">
-  <div class="banner3text">
-    "Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-    Now that the Notary-implemented service is generally available in IBM’s public cloud as a component of its existing IBM Cloud Container Registry, it is deployed as a highly available service across five IBM Cloud regions. This high-availability deployment has three instances across two zones in each of the five regions, load balanced with failover support. "We have also deployed it with end-to-end TLS support through to our back-end IBM Cloudant persistence storage service," Hough says.
-<br><br>
-    The IBM team has created and open sourced a Kubernetes admission controller called Portieris, which uses Notary signing information combined with customer-defined security policies to control image deployment into their cluster. "We are hoping to drive adoption of Portieris through its use of our Notary offering," Hough says.
-    <br><br>
-    IBM has been a key player in the creation and support of open source foundations, including CNCF. Todd Moore, IBM's vice president of Open Technology, is the current CNCF governing board chair and a number of IBMers are active across many of the CNCF member projects.
+<p>The key reason for selecting Notary was that it was already compatible with the existing authentication stack IBM's container registry was using. So was the design of TUF, which does not require the registry team to have to enter the business of key management. Both of these were "attractive design decisions that confirmed our choice of Notary," he says.</p>
 
+<p>The introduction of Notary to implement image signing capability in IBM Cloud encourages increased security across IBM's cloud platform, "where we expect it will include both the signing of official IBM images as well as expected use by security-conscious enterprise customers," Hough says. "When combined with security policy implementations, we expect an increased use of deployment policies in CI/CD pipelines that allow for fine-grained control of service deployment based on image signers."</p>
 
+<p>The availability of image signing "is a huge benefit to security-conscious customers who require this level of image provenance and security," Hough says. "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ibm/banner4.jpg')">
-  <div class="banner4text">
-     "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span>
-  </div>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ibm/banner3.jpg"
+  author="Michael Hough, a software developer with the IBM Cloud Container Registry team"
+>}}
+"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"
+{{< /case-studies/quote >}}
 
-<section class="section4">
-<div class="fullcol">
-  "Given that, we see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project," Hough says. Because the entire cloud native world is a fast-moving area with many competing vendors and solutions, "we see the CNCF model as an arbiter of openness and fair play across the ecosystem," he says.
-<br><br>
-With both TUF and Notary as part of CNCF, IBM expects there to be standardization around these capabilities beyond just de facto standards for signing and provenance. IBM has determined to not simply consume Notary, but also to contribute to the open source project where applicable. "IBMers have contributed a CouchDB backend to support our use of IBM Cloudant as the persistent store; and are working on generalization of the pkcs11 provider, allowing support of other security hardware devices beyond Yubikey," Hough says.
+<p>Now that the Notary-implemented service is generally available in IBM's public cloud as a component of its existing IBM Cloud Container Registry, it is deployed as a highly available service across five IBM Cloud regions. This high-availability deployment has three instances across two zones in each of the five regions, load balanced with failover support. "We have also deployed it with end-to-end TLS support through to our back-end IBM Cloudant persistence storage service," Hough says.</p>
 
-</div>
-</section>
-<div class="banner5">
-  <div class="banner5text">
-   "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Michael Hough, a software developer with the IBM Cloud Container Registry team</span>
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-The company has used other CNCF projects <a href="https://containerd.io">containerd</a>, <a href="https://www.envoyproxy.io">Envoy</a>, <a href="https://prometheus.io">Prometheus</a>, <a href="https://grpc.io">gRPC</a>, and <a href="https://github.com/containernetworking">CNI</a>, and is looking into <a href="https://github.com/spiffe">SPIFFE</a> and <a href="https://github.com/spiffe/spire">SPIRE</a> as well for potential future use.
-<br><br>
-What advice does Hough have for other companies that are looking to deploy Notary or a cloud native infrastructure?
-<br><br>
-"While this is true for many areas of cloud native infrastructure software, we found that a high-availability, multi-region deployment of Notary requires a solid implementation to handle certificate management and rotation," he says. "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."
+<p>The IBM team has created and open sourced a Kubernetes admission controller called Portieris, which uses Notary signing information combined with customer-defined security policies to control image deployment into their cluster. "We are hoping to drive adoption of Portieris through its use of our Notary offering," Hough says.</p>
 
-</div>
+<p>IBM has been a key player in the creation and support of open source foundations, including CNCF. Todd Moore, IBM's vice president of Open Technology, is the current CNCF governing board chair and a number of IBMers are active across many of the CNCF member projects.</p>
 
-</section>
+{{< case-studies/quote
+  image="/images/case-studies/ibm/banner4.jpg"
+  author="Michael Hough, a software developer with the IBM Cloud Container Registry team"
+>}}
+"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."
+{{< /case-studies/quote >}}
+
+<p>"Given that, we see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project," Hough says. Because the entire cloud native world is a fast-moving area with many competing vendors and solutions, "we see the CNCF model as an arbiter of openness and fair play across the ecosystem," he says.</p>
+
+<p>With both TUF and Notary as part of CNCF, IBM expects there to be standardization around these capabilities beyond just de facto standards for signing and provenance. IBM has determined to not simply consume Notary, but also to contribute to the open source project where applicable. "IBMers have contributed a CouchDB backend to support our use of IBM Cloudant as the persistent store; and are working on generalization of the pkcs11 provider, allowing support of other security hardware devices beyond Yubikey," Hough says.</p>
+
+{{< case-studies/quote author="Michael Hough, a software developer with the IBM Cloud Container Registry team" >}}
+"There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."
+{{< /case-studies/quote >}}
+
+<p>The company has used other CNCF projects <a href="https://containerd.io">containerd</a>, <a href="https://www.envoyproxy.io">Envoy</a>, <a href="https://prometheus.io">Prometheus</a>, <a href="https://grpc.io">gRPC</a>, and <a href="https://github.com/containernetworking">CNI</a>, and is looking into <a href="https://github.com/spiffe">SPIFFE</a> and <a href="https://github.com/spiffe/spire">SPIRE</a> as well for potential future use.</p>
+
+<p>What advice does Hough have for other companies that are looking to deploy Notary or a cloud native infrastructure?</p>
+
+<p>"While this is true for many areas of cloud native infrastructure software, we found that a high-availability, multi-region deployment of Notary requires a solid implementation to handle certificate management and rotation," he says. "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."</p>
diff --git a/content/ko/case-studies/ing/index.html b/content/ko/case-studies/ing/index.html
index 943daec2de..037ba9775d 100644
--- a/content/ko/case-studies/ing/index.html
+++ b/content/ko/case-studies/ing/index.html
@@ -5,95 +5,74 @@ case_study_styles: true
 cid: caseStudies
 weight: 50
 featured: true
-css: /css/style_case_studies.css
 quote: >
-  The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that’s quite feasible to us.
+  The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ing/banner1.jpg
+heading_title_logo: /images/ing_logo.png
+subheading: >
+  Driving Banking Innovation with Cloud Native
+case_study_details:
+  - Company: ING
+  - Location: Amsterdam, Netherlands
+  - Industry: Finance
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/ing/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ing_logo.png" style="margin-bottom:-1.5%;" class="header_logo"><br> <div class="subhead"> Driving Banking Innovation with Cloud Native
-</div></h1>
+<p>After undergoing an agile transformation, <a href="https://www.ing.com/">ING</a> realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with <a href="https://www.docker.com/">Docker</a>, Docker Swarm, <a href="https://kubernetes.io/">Kubernetes</a>, <a href="https://mesosphere.com/">Mesos</a>. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>ING</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Amsterdam, Netherlands
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Finance</b>
-</div>
+<p>Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app <a href="https://www.yolt.com/">Yolt</a> in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.</p>
 
-<hr>
-<section class="section1">
-<div class="cols" style="width:85% !important;margin-left:10% !important">
-  <div class="col1" style="width:100% !important;">
-    <h2>Challenge</h2>
-    After undergoing an agile transformation, <a href="https://www.ing.com/">ING</a> realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with <a href="https://www.docker.com/">Docker</a>, Docker Swarm, <a href="https://kubernetes.io/">Kubernetes</a>, <a href="https://mesosphere.com/">Mesos</a>. Well, it’s not really useful for a company to have one hundred wheels, instead of one good wheel.
-<br>
-    <br>
-    <h2>Solution</h2>
-    Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app <a href="https://www.yolt.com/">Yolt</a> in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based&nbsp;platform.
+<h2>Impact</h2>
 
-    <br>
-    </div>
+<p>"Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."</p>
 
-<div class="col2"  style="width:100% !important;padding-right:8%">
-<br>
-  <h2>Impact</h2>
-    "Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."
-  <br>
-</div>
-</div>
-</section>
-  <div class="banner2" style="padding-top:% !important">
-    <div class="banner2text" style="width:70% !important">
-      "The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that’s quite feasible to us."
-      <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Thijs Ebbers, Infrastructure Architect, ING</span>
-    </div>
-  </div>
-<section class="section2">
-<div class="fullcol">
-  <h2>ING has long embraced innovation in banking, launching the internet-based ING Direct in&nbsp;1997. </h2>In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it’s not really useful for a company to have one hundred wheels, instead of one good wheel." <br><br>
-  Looking to standardize the deployment process within the company’s strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."<br><br>
-  They also embraced Docker to address a major pain point in ING’s CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they’ve done the work, the containers get killed again."
+{{< case-studies/quote author="Thijs Ebbers, Infrastructure Architect, ING">}}
+"The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ing/banner3.jpg')">
-  <div class="banner3text">
-  "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."
-  <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Thijs Ebbers, Infrastructure Architect, ING</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex." For that reason, ING has chosen to start on the <a href="https://www.openshift.org/">OpenShift Origin</a> Kubernetes distribution. <br><br>
-  Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."<br><br>
-  The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.
+{{< case-studies/lead >}}
+ING has long embraced innovation in banking, launching the internet-based ING Direct in 1997.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ing/banner4.jpg')">
-  <div class="banner4text">
-    "We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Onno Van der Voort,  Infrastructure Architect, ING</span>
-  </div>
-</div>
+<p>In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel."</p>
 
+<p>Looking to standardize the deployment process within the company's strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."</p>
 
-<div class="fullcol">
-  The team, however, doesn’t see the bank’s back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn’t hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it’s not about how cool this technology is, it’s about finding the right technology and the right approach."<br><br>
-  The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to <a href="https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en">PSD2</a>, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called <a href="https://www.yolt.com/">Yolt</a>, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We’ve been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.
+<p>They also embraced Docker to address a major pain point in ING's CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they've done the work, the containers get killed again."</p>
 
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="banner5">
-  <div class="banner5text">
-Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING</span></div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ing/banner3.jpg"
+  author="Thijs Ebbers, Infrastructure Architect, ING"
+>}}
+"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran. <br><br>
-  The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that’s quite feasible to us."
+<p>Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." For that reason, ING has chosen to start on the <a href="https://www.openshift.org/">OpenShift Origin</a> Kubernetes distribution.</p>
 
-</div>
+<p>Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."</p>
 
-</section>
+<p>The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ing/banner4.jpg"
+  author="Onno Van der Voort,  Infrastructure Architect, ING"
+>}}
+"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex."
+{{< /case-studies/quote >}}
+
+<p>The team, however, doesn't see the bank's back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn't hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it's not about how cool this technology is, it's about finding the right technology and the right approach."</p>
+
+<p>The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to <a href="https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en">PSD2</a>, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called <a href="https://www.yolt.com/">Yolt</a>, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We've been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.</p>
+
+{{< case-studies/quote author="Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING" >}}
+Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology."
+{{< /case-studies/quote >}}
+
+<p>Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran.</p>
+
+<p>The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that's quite feasible to us."</p>
diff --git a/content/ko/case-studies/naic/index.html b/content/ko/case-studies/naic/index.html
index 3deb91e480..89ef6cb8de 100644
--- a/content/ko/case-studies/naic/index.html
+++ b/content/ko/case-studies/naic/index.html
@@ -1,113 +1,87 @@
 ---
 title: NAIC Case Study
-
 linkTitle: NAIC
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: naic_featured_logo.png
 featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/naic/banner1.jpg
+heading_title_logo: /images/naic_logo.png
+subheading: >
+  A Culture and Technology Transition Enabled by Kubernetes
+case_study_details:
+  - Company: NAIC
+  - Location: Washington, DC
+  - Industry: Regulatory
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/naic/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/naic_logo.png" class="header_logo" style="width:18%"><br> <div class="subhead" style="margin-top:1%">A Culture and Technology Transition Enabled by Kubernetes</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The <a href="http://www.naic.org/">National Association of Insurance Commissioners (NAIC)</a>, the U.S. standard-setting and regulatory support organization, was looking for a way to deliver new services faster to provide more value for members and staff. It also needed greater agility to improve productivity internally.</p>
 
-<div class="details" style="font-size:1em">
-    Company &nbsp;<b>National Association of Insurance Commissioners (NAIC)</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Washington, DC</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Regulatory</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The <a href="http://www.naic.org/">National Association of Insurance Commissioners (NAIC)</a>, the U.S. standard-setting and regulatory support organization, was looking for a way to deliver new services faster to provide more value for members and staff. It also needed greater agility to improve productivity internally.
-<br><br>
- <h2>Solution</h2>
-     Beginning in 2016, they started using <a href="https://www.cncf.io/">Cloud Native Computing Foundation (CNCF)</a> tools such as <a href="https://prometheus.io/">Prometheus</a>. NAIC began hosting internal systems and development systems on <a href="https://kubernetes.io/">Kubernetes</a> at the beginning of 2018, as part of a broad move toward the public cloud. "Our culture and technology transition is a strategy embraced by our top leaders," says Dan Barker, Chief Enterprise Architect. "It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."
-
-
-
-      </div>
-
-<div class="col2">
+<h2>Solution</h2>
 
+<p>Beginning in 2016, they started using <a href="https://www.cncf.io/">Cloud Native Computing Foundation (CNCF)</a> tools such as <a href="https://prometheus.io/">Prometheus</a>. NAIC began hosting internal systems and development systems on <a href="https://kubernetes.io/">Kubernetes</a> at the beginning of 2018, as part of a broad move toward the public cloud. "Our culture and technology transition is a strategy embraced by our top leaders," says Dan Barker, Chief Enterprise Architect. "It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."</p>
 
 <h2>Impact</h2>
-     Leveraging Kubernetes, "our development teams can create rapid prototypes far faster than they used to," Barker said. Applications running on Kubernetes are more resilient than those running in other environments. The deployment of open source solutions is helping influence company culture, as NAIC becomes a more open and transparent organization.
-    <br><br>
-    "We completed a small prototype in two days that would have previously taken at least a month," Barker says. Resiliency is currently measured in how much downtime systems have. "They’ve basically had none, and the occasional issue is remedied in minutes," he says.
 
+<p>Leveraging Kubernetes, "our development teams can create rapid prototypes far faster than they used to," Barker said. Applications running on Kubernetes are more resilient than those running in other environments. The deployment of open source solutions is helping influence company culture, as NAIC becomes a more open and transparent organization.</p>
 
-</div>
+<p>"We completed a small prototype in two days that would have previously taken at least a month," Barker says. Resiliency is currently measured in how much downtime systems have. "They've basically had none, and the occasional issue is remedied in minutes," he says.</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-   "Our culture and technology transition is a strategy embraced by our top leaders. It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- NAIC—which was created and overseen by the chief insurance regulators from the 50 states, the District of Columbia and five U.S. territories—provides a means through which state insurance regulators establish standards and best practices, conduct peer reviews, and coordinate their regulatory oversight. Their staff supports these efforts and represents the collective views of regulators in the United States and internationally. NAIC members, together with the organization’s central resources, form the national system of state-based insurance regulation in the United States.<br><br>
-The organization has been using the cloud for years, and wanted to find more ways to quickly deliver new services that provide more value for members and staff. They looked to Kubernetes for a solution. Within NAIC, several groups are leveraging Kubernetes, one being the Platform Engineering Team. "The team building out these tools are not only deploying and operating Kubernetes, but they’re also using them," Barker says. "In fact, we’re using GitLab to deploy Kubernetes with a pipeline using <a href="https://github.com/kubernetes/kops">kops</a>. This team was created from developers, operators, and quality engineers from across the company, so their jobs have changed quite a bit."<br><br>
-In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they’re starting to use Kubernetes to deploy simple applications that help their internal processes.
+{{< case-studies/quote author="Dan Barker, Chief Enterprise Architect, NAIC" >}}
+"Our culture and technology transition is a strategy embraced by our top leaders. It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."
+{{< /case-studies/quote >}}
 
+<p>NAIC—which was created and overseen by the chief insurance regulators from the 50 states, the District of Columbia and five U.S. territories—provides a means through which state insurance regulators establish standards and best practices, conduct peer reviews, and coordinate their regulatory oversight. Their staff supports these efforts and represents the collective views of regulators in the United States and internationally. NAIC members, together with the organization's central resources, form the national system of state-based insurance regulation in the United States.</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/naic/banner3.jpg')">
-  <div class="banner3text">
- "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-    "We needed greater agility to enable our own productivity internally," he says. "We decided it was right for us to move everything to the public cloud [Amazon Web Services] to help with that process and be able to access many of the native tools that allows us to move faster by not needing to build everything."
-The NAIC also wanted to be cloud-agnostic, "and Kubernetes helps with this for our compute layer," Barker says. "Compute is pretty standard across the clouds, and now we can take advantage of any of them while getting all of the other features Kubernetes offers."<br><br>
-The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."
-The native integrations into Kubernetes at NAIC has made it easy to write code and have it running in minutes instead of weeks. Applications running on Kubernetes have also proven to be more resilient than those running in other environments. "We even have teams using this to create more internal tools to help with communication or automating some of their current tasks," Barker says.
-<br><br>
-"We knew that Kubernetes had become the de facto standard for container orchestration," he says. "Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."
-<br><br>
-As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes to continue using it moving forward because of the seamless integration with Kubernetes. The Association also is considering <a href="https://grpc.io/">gRPC</a> as its internal communications standard, <a href="https://www.envoyproxy.io/">Envoy</a> in conjunction with Istio for service mesh, <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://www.jaegertracing.io">Jaeger</a> for tracing aggregation, and <a href="https://www.fluentd.org/">Fluentd</a> with its Elasticsearch cluster.
+<p>The organization has been using the cloud for years, and wanted to find more ways to quickly deliver new services that provide more value for members and staff. They looked to Kubernetes for a solution. Within NAIC, several groups are leveraging Kubernetes, one being the Platform Engineering Team. "The team building out these tools are not only deploying and operating Kubernetes, but they're also using them," Barker says. "In fact, we're using GitLab to deploy Kubernetes with a pipeline using <a href="https://github.com/kubernetes/kops">kops</a>. This team was created from developers, operators, and quality engineers from across the company, so their jobs have changed quite a bit."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/naic/banner4.jpg')">
-  <div class="banner4text">
-     "We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
-  </div>
-  </div>
-</div>
+<p>In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they're starting to use Kubernetes to deploy simple applications that help their internal processes.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
+{{< case-studies/quote
+  image="/images/case-studies/naic/banner3.jpg"
+  author="Dan Barker, Chief Enterprise Architect, NAIC"
+>}}
+"In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community."
+{{< /case-studies/quote >}}
 
-The open governance and broad industry participation in CNCF provided a comfort level with the technology, Barker says. "We also see it as helping to influence our own company culture," he says. "We’re moving to be a more open and transparent company, and we are encouraging our staff to get involved with the different working groups and codebases. We recently became CNCF members to help further our commitment to community contribution and transparency."<br><br>
-Factors such as vendor-neutrality and cross-industry investment were important in the selection. "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community," Barker says.<br><br>
-NAIC is a largely Oracle shop, Barker says, and has been running mostly Java on JBoss. "However, we have years of history with other applications," he says. "Some of these have been migrated by completely rewriting the application, while others are just being modified slightly to fit into this new paradigm."<br><br>
-Running on AWS cloud, the Association has not specifically taken a microservices approach. "We are moving to microservices where practical, but we haven’t found that it’s a necessity to operate them within Kubernetes," Barker says<br><br>
-All of its databases are currently running within public cloud services, but they have explored eventually running those in Kubernetes, as it makes sense. "We’re doing this to get more reuse from common components and to limit our failure domains to something more manageable and observable," Barker says.
+<p>"We needed greater agility to enable our own productivity internally," he says. "We decided it was right for us to move everything to the public cloud [Amazon Web Services] to help with that process and be able to access many of the native tools that allows us to move faster by not needing to build everything."
+The NAIC also wanted to be cloud-agnostic, "and Kubernetes helps with this for our compute layer," Barker says. "Compute is pretty standard across the clouds, and now we can take advantage of any of them while getting all of the other features Kubernetes offers."</p>
 
+<p>The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."</p>
 
-</div>
+<p>The native integrations into Kubernetes at NAIC has made it easy to write code and have it running in minutes instead of weeks. Applications running on Kubernetes have also proven to be more resilient than those running in other environments. "We even have teams using this to create more internal tools to help with communication or automating some of their current tasks," Barker says.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Dan Barker, Chief Enterprise Architect, NAIC</span>
+<p>"We knew that Kubernetes had become the de facto standard for container orchestration," he says. "Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."</p>
 
-  </div>
-</div>
-<div class="fullcol">
+<p>As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes to continue using it moving forward because of the seamless integration with Kubernetes. The Association also is considering <a href="https://grpc.io/">gRPC</a> as its internal communications standard, <a href="https://www.envoyproxy.io/">Envoy</a> in conjunction with Istio for service mesh, <a href="http://opentracing.io/">OpenTracing</a> and <a href="https://www.jaegertracing.io">Jaeger</a> for tracing aggregation, and <a href="https://www.fluentd.org/">Fluentd</a> with its Elasticsearch cluster.</p>
 
-NAIC has seen a significant business impact from its efforts. "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."
-He says the organization is moving toward continuous deployment "because the business case makes sense. The research is becoming very hard to argue with. We want to reduce our batch sizes and optimize on delivering value to customers and not feature count. This is requiring a larger cultural shift than just a technology shift."
-NAIC is "becoming more open and transparent, as well as more resilient to failure," Barker says. "Even our customers are wanting more and more of this and trying to figure out how they can work with us to accomplish our mutual goals faster. Members of the insurance industry have reached out so that we can better learn together and grow as an industry."
+{{< case-studies/quote
+  image="/images/case-studies/naic/banner4.jpg"
+  author="Dan Barker, Chief Enterprise Architect, NAIC"
+>}}
+"We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."
+{{< /case-studies/quote >}}
 
-</div>
+<p>The open governance and broad industry participation in CNCF provided a comfort level with the technology, Barker says. "We also see it as helping to influence our own company culture," he says. "We're moving to be a more open and transparent company, and we are encouraging our staff to get involved with the different working groups and codebases. We recently became CNCF members to help further our commitment to community contribution and transparency."</p>
 
-</section>
+<p>Factors such as vendor-neutrality and cross-industry investment were important in the selection. "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community," Barker says.</p>
+
+<p>NAIC is a largely Oracle shop, Barker says, and has been running mostly Java on JBoss. "However, we have years of history with other applications," he says. "Some of these have been migrated by completely rewriting the application, while others are just being modified slightly to fit into this new paradigm."</p>
+
+<p>Running on AWS cloud, the Association has not specifically taken a microservices approach. "We are moving to microservices where practical, but we haven't found that it's a necessity to operate them within Kubernetes," Barker says.</p>
+
+<p>All of its databases are currently running within public cloud services, but they have explored eventually running those in Kubernetes, as it makes sense. "We're doing this to get more reuse from common components and to limit our failure domains to something more manageable and observable," Barker says.</p>
+
+{{< case-studies/quote author="Dan Barker, Chief Enterprise Architect, NAIC" >}}
+"We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."
+{{< /case-studies/quote >}}
+
+<p>NAIC has seen a significant business impact from its efforts. "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."</p>
+
+<p>He says the organization is moving toward continuous deployment "because the business case makes sense. The research is becoming very hard to argue with. We want to reduce our batch sizes and optimize on delivering value to customers and not feature count. This is requiring a larger cultural shift than just a technology shift."</p>
+
+<p>NAIC is "becoming more open and transparent, as well as more resilient to failure," Barker says. "Even our customers are wanting more and more of this and trying to figure out how they can work with us to accomplish our mutual goals faster. Members of the insurance industry have reached out so that we can better learn together and grow as an industry."</p>
diff --git a/content/ko/case-studies/newyorktimes/index.html b/content/ko/case-studies/newyorktimes/index.html
index c65b5fe883..ae57a9ec7d 100644
--- a/content/ko/case-studies/newyorktimes/index.html
+++ b/content/ko/case-studies/newyorktimes/index.html
@@ -2,107 +2,73 @@
 title: New York Times Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/newyorktimes/banner1.jpg
+heading_title_logo: /images/newyorktimes_logo.png
+subheading: >
+  The New York Times: From Print to the Web to Cloud Native
+case_study_details:
+  - Company: New York Times
+  - Location: New York, N.Y.
+  - Industry: News Media
 ---
 
-<div class="banner1" style="padding-left:8% !important;background-image: url('/images/CaseStudy_newyorktimes_banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/newyorktimes_logo.png" class="header_logo"><br> <div class="subhead">The New York Times: From Print to the Web to Cloud Native
+<h2>Challenge</h2>
 
-</div></h1>
+<p>When the company decided a few years ago to move out of its data centers, its first deployments on the public cloud were smaller, less critical applications managed on virtual machines. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center," says Deep Kapadia, Executive Director, Engineering at The New York Times. Kapadia was tapped to lead a Delivery Engineering Team that would "design for the abstractions that cloud providers offer us."</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details" style="padding-left:6% !important">
-    Company &nbsp;<b>New York Times</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, N.Y.
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>News Media</b>
-</div>
+<p>The team decided to use <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.</p>
 
-<hr />
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    When the company decided a few years ago to move out of its data centers, its first deployments on the public cloud were smaller, less critical applications managed on virtual machines. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center," says Deep Kapadia, Executive Director, Engineering at The New York Times. Kapadia was tapped to lead a Delivery Engineering Team that would "design for the abstractions that cloud providers offer us."
+<h2>Impact</h2>
 
-    <br><br>
-    <h2>Solution</h2>
-    The team decided to use <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.
-    <br />
-    </div>
+<p>Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.</p>
 
-<div class="col2">
-
-  <h2>Impact</h2>
-  Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.
-  <br />
-</div>
-
-</div>
-</section>
-<div class="banner2" style="padding-bottom:0% !important;padding-left:10% !important;">
-    <div class="banner2text" style="width:100% !important;padding-left:5% !important;padding-right:5% !important">
-    <div class="video" style="float:left;width:90%;">
-    <iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-      <iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-    </div>
-  </div>
-  </div>
-  <br><br>
-  <div class="banner2" style="padding-top:10% !important;padding-left:5% !important;">
-    <div class="banner2text" style="padding-top:5% !important">
+{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times">}}
+<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 <br>
-      "I think once you get over the initial hump, things get a lot easier and actually a lot faster." — Deep Kapadia, Executive Director, Engineering at The&nbsp;New&nbsp;York&nbsp;Times</div>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.<br /><br />
-  At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on <a href="https://aws.amazon.com/">AWS</a> as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."<br /><br />
-  To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.<br /><br />
-  At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"<br /><br />
-  In early 2017, the first production application—the nytimes.com mobile homepage—began running on Kubernetes, serving just 1% of the traffic. Today, almost 100% of the nytimes.com site’s end-user facing applications run on GCP, with the majority on Kubernetes.
+"I think once you get over the initial hump, things get a lot easier and actually a lot faster."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_newyorktimes_banner3.jpg')">
-  <div class="banner3text">
-  "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.</p>
 
-  The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."<br /><br />
-  The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, which has been the main platform for the company’s experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I’m really excited about experimenting with deploying those on App Engine Flex and <a href="https://aws.amazon.com/fargate/">AWS Fargate</a> and seeing how that feels, because that’s a great migration path."<br /><br />
-  There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they’re using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."<br /><br />
-  Kapadia acknowledges that there was a steep learning curve for some engineers, but "I think once you get over the initial hump, things get a lot easier and actually a lot faster."
+<p>At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on <a href="https://aws.amazon.com/">AWS</a> as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_newyorktimes_banner4.jpg')">
-  <div class="banner4text">
-    "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
+<p>To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.</p>
 
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  At The New York Times, they did. As teams started sharing their own best practices with each other, "We’re no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We’ve sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, ‘If this works for you as is, great! If not, come talk to us and we’ll figure out how to make it work for you.’"<br /><br />
-  As a result, "It’s really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."<br /><br />
-  Another benefit to adopting Kubernetes: allowing for a more unified approach to deployment across the engineering staff. "Before, many teams were building their own tools for deployment," says Balser. With Kubernetes—as well as the other CNCF projects The New York Times uses, including Fluentd to collect logs for all of its AWS servers, gRPC for its <a href="https://open.nytimes.com/publishing-with-apache-kafka-at-the-new-york-times-7f0e3b7d2077">Publishing Pipeline</a>, Prometheus, and Envoy—"we can benefit from the advances that each of these technologies make, instead of trying to catch up."
+<p>At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"</p>
 
-</div>
+<p>In early 2017, the first production application—the nytimes.com mobile homepage—began running on Kubernetes, serving just 1% of the traffic. Today, almost 100% of the nytimes.com site's end-user facing applications run on GCP, with the majority on Kubernetes.</p>
 
-<div class="banner5">
-  <div class="banner5text">
+{{< case-studies/quote image="/images/case-studies/newyorktimes/banner3.jpg" >}}
+"We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
+{{< /case-studies/quote >}}
 
-Li calls the Cloud Native Computing Foundation’s projects "a northern star that we can all look at and follow."
-  </div>
-</div>
+<p>The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."</p>
 
-<div class="fullcol">
-  These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We’re running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."<br /><br />
-  Li calls the Cloud Native Computing Foundation’s projects "a northern star that we can all look at and follow." Led by that star, the team is looking ahead to a year of onboarding the remaining half of the 40 or so product engineering teams to extract even more value out of the technology. "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
+<p>The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, which has been the main platform for the company's experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I'm really excited about experimenting with deploying those on App Engine Flex and <a href="https://aws.amazon.com/fargate/">AWS Fargate</a> and seeing how that feels, because that's a great migration path."</p>
 
-</div>
-</section>
+<p>There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they're using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."</p>
+
+<p>Kapadia acknowledges that there was a steep learning curve for some engineers, but "I think once you get over the initial hump, things get a lot easier and actually a lot faster."</p>
+
+{{< case-studies/quote image="/images/case-studies/newyorktimes/banner4.jpg" >}}
+"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
+{{< /case-studies/quote >}}
+
+<p>At The New York Times, they did. As teams started sharing their own best practices with each other, "We're no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We've sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, 'If this works for you as is, great! If not, come talk to us and we'll figure out how to make it work for you.'"</p>
+
+<p>As a result, "It's really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."</p>
+
+<p>Another benefit to adopting Kubernetes: allowing for a more unified approach to deployment across the engineering staff. "Before, many teams were building their own tools for deployment," says Balser. With Kubernetes—as well as the other CNCF projects The New York Times uses, including Fluentd to collect logs for all of its AWS servers, gRPC for its <a href="https://open.nytimes.com/publishing-with-apache-kafka-at-the-new-york-times-7f0e3b7d2077">Publishing Pipeline</a>, Prometheus, and Envoy—"we can benefit from the advances that each of these technologies make, instead of trying to catch up."</p>
+
+{{< case-studies/quote >}}
+Li calls the Cloud Native Computing Foundation's projects "a northern star that we can all look at and follow."
+{{< /case-studies/quote >}}
+
+<p>These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We're running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."</p>
+
+<p>Li calls the Cloud Native Computing Foundation's projects "a northern star that we can all look at and follow." Led by that star, the team is looking ahead to a year of onboarding the remaining half of the 40 or so product engineering teams to extract even more value out of the technology. "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."</p>
diff --git a/content/ko/case-studies/nordstrom/index.html b/content/ko/case-studies/nordstrom/index.html
index 788453de35..73bc4e147e 100644
--- a/content/ko/case-studies/nordstrom/index.html
+++ b/content/ko/case-studies/nordstrom/index.html
@@ -2,109 +2,74 @@
 title: Nordstrom Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/nordstrom/banner1.jpg
+heading_title_logo: /images/nordstrom_logo.png
+subheading: >
+  Finding Millions in Potential Savings in a Tough Retail Climate
+case_study_details:
+  - Company: Nordstrom
+  - Location: Seattle, Washington
+  - Industry: Retail
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">Finding Millions in Potential Savings in a Tough Retail Climate
+<h2>Challenge</h2>
 
+<p>Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
+<p>After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>.</p>
 
-<div class="details">
-    Company &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Seattle, Washington</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Retail</b>
-</div>
+<h2>Impact</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.
+<p>Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren't effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."</p>
 
-<br>
-    <h2>Solution</h2>
-    After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>.
+{{< case-studies/quote author="Dhawal Patel, senior engineer at Nordstrom" >}}
+"We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It's a win-win."
+{{< /case-studies/quote >}}
 
-  <br>
+<p>When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer's website, he realized there was an opportunity to help speed up development cycles.</p>
 
+<p>In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."</p>
 
-      </div>
+<p>The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom's cloud native journey.</p>
 
-<div class="col2">
+<p>Dev and Ops team members built a CI/CD pipeline, working with the company's servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."</p>
 
-  <h2>Impact</h2>
-  Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren’t effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."
+<p>But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company's 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.</p>
 
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It’s a win-win."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-— Dhawal Patel, senior engineer at Nordstrom</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer’s website, he realized there was an opportunity to help speed up development cycles.
-<br><br>
-    In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."
-<br><br>
-    The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom’s cloud native journey.
-<br><br>
-    Dev and Ops team members built a CI/CD pipeline, working with the company’s servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."
-    <br><br>But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company’s 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
+"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')">
-  <div class="banner3text">
-    "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>"The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."</p>
 
-"The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."
-<br><br>
-Nordstrom’s first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.
-While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."
-<br><br>
-The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
+<p>Nordstrom's first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')">
-  <div class="banner4text">
- "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
-  </div>
-</div>
+<p>While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."</p>
 
-<section class="section5">
-<div class="fullcol">
-  To support these early adopters, Patel’s team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.
- <br><br>
-There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."
- <br><br>
-For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications.  One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.
-</div>
+<p>The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead."
-  </div>
-</div>
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
+"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead."
-<br><br>
-  Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they’re only working with Kubernetes."
-  For that reason, Patel is eagerly following Kubernetes’ development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."
-<br><br>
-  That kind of possibility—as well as the impact that Grigoriu and Patel’s team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu.  "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It’s a win-win."
+<p>To support these early adopters, Patel's team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.</p>
 
-</div>
-</section>
+<p>There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."</p>
+
+<p>For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications.  One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.</p>
+
+{{< case-studies/quote >}}
+"With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."
+{{< /case-studies/quote >}}
+
+<p>Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."</p>
+
+<p>Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they're only working with Kubernetes."</p>
+
+<p>For that reason, Patel is eagerly following Kubernetes' development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."</p>
+
+<p>That kind of possibility—as well as the impact that Grigoriu and Patel's team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu.  "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It's a win-win."</p>
diff --git a/content/ko/case-studies/northwestern-mutual/index.html b/content/ko/case-studies/northwestern-mutual/index.html
index 47b4bbc7be..a25d25484c 100644
--- a/content/ko/case-studies/northwestern-mutual/index.html
+++ b/content/ko/case-studies/northwestern-mutual/index.html
@@ -2,98 +2,68 @@
 title: Northwestern Mutual Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/northwestern/banner1.jpg
+heading_title_logo: /images/northwestern_logo.png
+subheading: >
+  Cloud Native at Northwestern Mutual
+case_study_details:
+  - Company: Northwestern Mutual
+  - Location: Milwaukee, WI
+  - Industry: Insurance and Financial Services
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/northwestern/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/northwestern_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Cloud Native at Northwestern Mutual
+<h2>Challenge</h2>
 
+<p>In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual's leading products and services and meld it with LearnVest's digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company's existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
-
-<div class="details">
-    Company &nbsp;<b>Northwestern Mutual</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Milwaukee, WI</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Insurance and Financial Services</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.
-<br>
-    <h2>Solution</h2>
-    The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced <a href="https://github.com/northwesternmutual/kanali">Kanali</a>, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC.
-
-
-</div>
-
-<div class="col2">
+<p>The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they're building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced <a href="https://github.com/northwesternmutual/kanali">Kanali</a>, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC.</p>
 
 <h2>Impact</h2>
-  Before, infrastructure deployments could take weeks; now, it is done in a matter of minutes. The number of deployments has increased dramatically, from about 24 a year to over 500 in just the first 10 months of 2017. Availability has also increased: There used to be a six-hour control window for commits every Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now we have eliminated the planned outage windows," says Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. Kanali has had an impact on the bottom line. The vendor API management product that the company previously used required 23 servers, "dedicated, to only API management," says Pfremmer. "Now it’s all integrated in the existing stack and running as another deployment on Kubernetes. And that’s just one environment. Between the three that we had plus the test, that’s hard dollar savings."
-  <br>
-</div>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text" style="width:70% !important;padding-left:15%">
-"In a large enterprise, you’re going to have people using Kubernetes, but then you’re also going to have people using WAS and .NET. You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff." <span style="font-size:16px;text-transform:uppercase">— Frank Greco Jr., Cloud Native Engineer at Northwestern Mutual</span></div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>For more than 160 years, Northwestern Mutual has maintained its industry leadership in part by keeping a strong focus on risk management. </h2>
-  For many years, the company took a similar approach to managing its technology and has recently undergone a digital transformation to advance the company’s digital strategy - including making a lot of noise in the cloud-native world.<br><br>
-In the spring of 2015, this insurance and financial services company acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on an on-premise datacenter; deployments were very traditional and had to many manual steps that were error prone. <br><br>
-In order to give the company’s 4.5 million clients the digital experience they’d come to expect, says Williams, "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website. We essentially said, 'You build the system that you think is necessary to support a new, modern-facing one.’ That’s why we departed from anything legacy."
+<p>Before, infrastructure deployments could take weeks; now, it is done in a matter of minutes. The number of deployments has increased dramatically, from about 24 a year to over 500 in just the first 10 months of 2017. Availability has also increased: There used to be a six-hour control window for commits every Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now we have eliminated the planned outage windows," says Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. Kanali has had an impact on the bottom line. The vendor API management product that the company previously used required 23 servers, "dedicated, to only API management," says Pfremmer. "Now it's all integrated in the existing stack and running as another deployment on Kubernetes. And that's just one environment. Between the three that we had plus the test, that's hard dollar savings."</p>
 
+{{< case-studies/quote author="Frank Greco Jr., Cloud Native Engineer at Northwestern Mutual">}}
+"In a large enterprise, you're going to have people using Kubernetes, but then you're also going to have people using WAS and .NET. You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/northwestern/banner3.jpg')">
-  <div class="banner3text">
-    "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."
+{{< case-studies/lead >}}
+For more than 160 years, Northwestern Mutual has maintained its industry leadership in part by keeping a strong focus on risk management.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."<br><br>
-As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board.
-The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
+<p>For many years, the company took a similar approach to managing its technology and has recently undergone a digital transformation to advance the company's digital strategy - including making a lot of noise in the cloud-native world.</p>
 
+<p>In the spring of 2015, this insurance and financial services company acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual's leading products and services and meld it with LearnVest's digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company's existing infrastructure had been optimized for batch workflows hosted on an on-premise datacenter; deployments were very traditional and had to many manual steps that were error prone.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/northwestern/banner4.jpg')">
-  <div class="banner4text">
+<p>In order to give the company's 4.5 million clients the digital experience they'd come to expect, says Williams, "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website. We essentially said, 'You build the system that you think is necessary to support a new, modern-facing one.' That's why we departed from anything legacy."</p>
+
+{{< case-studies/quote image="/images/case-studies/northwestern/banner3.jpg" >}}
+"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they're building and deliver very quickly and frequently."
+{{< /case-studies/quote >}}
+
+<p>Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they're building and deliver very quickly and frequently."</p>
+
+<p>As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company's 1,500 engineers are using it and more are eager to get on board.</p>
+
+<p>The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.</p>
+
+{{< case-studies/quote image="/images/case-studies/northwestern/banner4.jpg" >}}
 "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it."
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important;">
-<div class="fullcol">
-  The process used to be so cumbersome that minor bug releases would be bundled with feature releases. With the new streamlined system enabled by Kubernetes, the number of deployments has increased from about 24 a year to more than 500 in just the first 10 months of 2017. Availability has also been improved: There used to be a six-hour control window for commits every early Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now there’s no planned outage window," notes Pfremmer.<br><br>
-Northwestern Mutual built that API management tool—called <a href="https://github.com/northwesternmutual/kanali">Kanali</a>—and open sourced it in the summer of 2017. The team took on the project because it was a key capability for what they were building and prior the solution worked in an "anti-cloud native way that was different than everything else we were doing," says Greco. Now API management is just another container deployed to Kubernetes along with a separate Jaeger deployment.<br><br>
-Now the engineers using the Kubernetes deployment platform have the added benefit of visibility in production—and autonomy. Before, a centralized team and would have to run a trace. "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." says Greco.
+<p>The process used to be so cumbersome that minor bug releases would be bundled with feature releases. With the new streamlined system enabled by Kubernetes, the number of deployments has increased from about 24 a year to more than 500 in just the first 10 months of 2017. Availability has also been improved: There used to be a six-hour control window for commits every early Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now there's no planned outage window," notes Pfremmer.</p>
 
+<p>Northwestern Mutual built that API management tool—called <a href="https://github.com/northwesternmutual/kanali">Kanali</a>—and open sourced it in the summer of 2017. The team took on the project because it was a key capability for what they were building and prior the solution worked in an "anti-cloud native way that was different than everything else we were doing," says Greco. Now API management is just another container deployed to Kubernetes along with a separate Jaeger deployment.</p>
 
-</div>
+<p>Now the engineers using the Kubernetes deployment platform have the added benefit of visibility in production—and autonomy. Before, a centralized team and would have to run a trace. "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." says Greco.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-  "We’re trying to make what we’re doing known so that we can find people who are like, 'Yeah, that’s interesting. I want to come do it!’"
-  </div>
-</div>
+{{< case-studies/quote >}}
+"We're trying to make what we're doing known so that we can find people who are like, 'Yeah, that's interesting. I want to come do it!'"
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
-  But the team didn’t stop there. "In a large enterprise, you’re going to have people using Kubernetes, but then you’re also going to have people using WAS and .NET," says Greco. "You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."<br><br>
-  As the team continues to improve its stack and share its Kubernetes best practices, it feels that Northwestern Mutual’s reputation as a technology-first company is evolving too. "No one would think a company that’s 160-plus years old is foraying this deep into the cloud and infrastructure stack," says Pfremmer. And they’re hoping that means they’ll be able to attract new talent. "We’re trying to make what we’re doing known so that we can find people who are like, 'Yeah, that’s interesting. I want to come do it!’"
+<p>But the team didn't stop there. "In a large enterprise, you're going to have people using Kubernetes, but then you're also going to have people using WAS and .NET," says Greco. "You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."</p>
 
-
-</div>
-
-</section>
+<p>As the team continues to improve its stack and share its Kubernetes best practices, it feels that Northwestern Mutual's reputation as a technology-first company is evolving too. "No one would think a company that's 160-plus years old is foraying this deep into the cloud and infrastructure stack," says Pfremmer. And they're hoping that means they'll be able to attract new talent. "We're trying to make what we're doing known so that we can find people who are like, 'Yeah, that's interesting. I want to come do it!'"</p>
diff --git a/content/ko/case-studies/ocado/index.html b/content/ko/case-studies/ocado/index.html
index 79ac9bf3a8..59374f820e 100644
--- a/content/ko/case-studies/ocado/index.html
+++ b/content/ko/case-studies/ocado/index.html
@@ -1,99 +1,83 @@
 ---
 title: Ocado Case Study
-
 linkTitle: Ocado
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: ocado_featured_logo.png
 featured: true
 weight: 4
 quote: >
- People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing.
+  People at Ocado Technology have been quite amazed. They ask, 'Can we do this on a Dev cluster?' and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ocado/banner1.jpg
+heading_title_logo: /images/ocado_logo.png
+subheading: >
+  Ocado: Running Grocery Warehouses with a Cloud Native Platform
+case_study_details:
+  - Company: Ocado Technology
+  - Location: Hatfield, England
+  - Industry: Grocery retail technology and platforms
 ---
-<div class="banner1" style="background-image: url('/images/case-studies/ocado/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ocado_logo.png" class="header_logo"><br> <div class="subhead">Ocado: Running Grocery Warehouses with a Cloud Native Platform</div></h1>
 
-</div>
+<h2>Challenge</h2>
 
-<div class="details">
-    Company &nbsp;<b>Ocado Technology</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Hatfield, England</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Grocery retail technology and platforms</b>
-</div>
+<p>The world's largest online-only grocery retailer, <a href="http://www.ocadogroup.com/">Ocado</a> developed the Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other retailers such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses for the platform, Ocado shifted from virtual machines and <a href="https://puppet.com/">Puppet</a> infrastructure to <a href="https://www.docker.com/">Docker</a> containers, using CoreOS's <a href="https://github.com/coreos/fleet">fleet</a> scheduler to provision all the services on its <a href="https://www.openstack.org/">OpenStack</a>-based private cloud on bare metal. As the Smart Platform grew and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-        The world’s largest online-only grocery retailer, <a href="http://www.ocadogroup.com/">Ocado</a> developed the Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other retailers such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses for the platform, Ocado shifted from virtual machines and <a href="https://puppet.com/">Puppet</a> infrastructure to <a href="https://www.docker.com/">Docker</a> containers, using CoreOS’s <a href="https://github.com/coreos/fleet">fleet</a> scheduler to provision all the services on its <a href="https://www.openstack.org/">OpenStack</a>-based private cloud on bare metal. As the Smart Platform grew and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."<br><br>
- <h2>Solution</h2>
-      The team decided to migrate from fleet to <a href="https://www.kubernetes.io">Kubernetes</a> on Ocado’s private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm/">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing. The first app on Kubernetes, a business-critical service in the warehouses, went into production in the summer of 2017, with a mass migration continuing into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes.
-
-      </div>
-
-<div class="col2">
+<h2>Solution</h2>
 
+<p>The team decided to migrate from fleet to <a href="https://www.kubernetes.io">Kubernetes</a> on Ocado's private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm/">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing. The first app on Kubernetes, a business-critical service in the warehouses, went into production in the summer of 2017, with a mass migration continuing into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes.</p>
 
 <h2>Impact</h2>
-     With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments."
 
-</div>
+<p>With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I'd estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-   "People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Mike Bryant, Platform Engineer, Ocado</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-    <h2>When it was founded in 2000, Ocado was an online-only grocery retailer in the U.K. In the years since, it has expanded from delivering produce to families to providing technology to other grocery retailers.</h2>
-The company began developing its Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other grocery chains around the world, such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses on the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS’s fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew, and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."<br><br>
-Bryant had already been using Kubernetes with <a href="https://www.codeforlife.education/">Code for Life</a>, a children’s education project that’s part of Ocado’s charity arm. "We really liked it, so we started looking at it seriously for our production workloads," says Bryant. The team that managed fleet had researched orchestration solutions and landed on Kubernetes as well. "We were looking for a platform with wide adoption, and that was where the momentum was," says DevOps Team Leader Kevin McCormack. The two paths converged, and "We didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose," says Bryant.
+{{< case-studies/quote author="Mike Bryant, Platform Engineer, Ocado" >}}
+"People at Ocado Technology have been quite amazed. They ask, 'Can we do this on a Dev cluster?' and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ocado/banner3.jpg')">
-  <div class="banner3text">
-    "We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose," <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Kevin McCormack, DevOps Team Leader, Ocado</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-    In the summer of 2016, the team began migrating from fleet to <a href="https://kubernetes.io/">Kubernetes</a> on Ocado’s private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing. <br><br>
-    The first app on Kubernetes, a business-critical service in the warehouses, went into production a year later. Once that app was running smoothly, a mass migration continued into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes, and the platform is live in Ocado’s warehouses, managing tens of thousands of orders a week. At full capacity, Ocado’s latest warehouse in Erith, southeast London, will deliver more than 200,000 orders per week, making it the world’s largest facility for online grocery. <br><br>
-    There are about 150 microservices now running on Kubernetes, with multiple instances of many of them. "We’re not just deploying all these microservices at once. We’re deploying them all for one warehouse, and then they’re all being deployed again for the next warehouse, and again and again," says Bryant.<br><br>
-    The move to Kubernetes was eye-opening for many people at Ocado Technology. "In the early days of putting the platform into our test infrastructure, the technical architect asked what network performance was like on <a href="https://www.weave.works/oss/net/">Weave Net</a> with encryption turned on," recalls Bryant. "So we found a Docker container for <a href="https://iperf.fr/">iPerf</a>, wrote a daemon set, deployed it. A few moments later, we’ve deployed the entire thing across this cluster. He was pretty blown away by that."
+{{< case-studies/lead >}}
+When it was founded in 2000, Ocado was an online-only grocery retailer in the U.K. In the years since, it has expanded from delivering produce to families to providing technology to other grocery retailers.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ocado/banner4.jpg')">
-  <div class="banner4text">
-     "The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Mike Bryant, Platform Engineer, Ocado</span>
-  </div>
-  </div>
-</div>
+<p>The company began developing its Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other grocery chains around the world, such as <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">Kroger</a>. To set up the first warehouses on the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS's fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew, and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Indeed, the impact has been profound. "Prior to containerization, we had quite restrictive deployment windows in our warehouses," says Bryant. "Moving to microservices, we’ve been able to deploy much more frequently. We’ve been able to move towards continuous delivery in a number of areas. In our older warehouse, new application deployments involve talking to a bunch of different teams for different levels of the stack: from VM provisioning, to storage, to load balancers, and so on. The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."<br><br>
-  The rate of deployment has gone from as few as two per week to dozens per week. "With Kubernetes, some of our development teams have been able to deploy their application to production on the new platform without us noticing," says Bryant, "which means they’re faster at doing what they need to do and we have less work."<br><br>
-  Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. "That lets us shrink quite a lot of our deployments from being per-core VM deployments to having fractions of the core," says Bryant. Adds McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster. This means we use our hardware better since if we have to always have two nodes of excess capacity available in case of node failures then we only need two extra instead of 20."
+<p>Bryant had already been using Kubernetes with <a href="https://www.codeforlife.education/">Code for Life</a>, a children's education project that's part of Ocado's charity arm. "We really liked it, so we started looking at it seriously for our production workloads," says Bryant. The team that managed fleet had researched orchestration solutions and landed on Kubernetes as well. "We were looking for a platform with wide adoption, and that was where the momentum was," says DevOps Team Leader Kevin McCormack. The two paths converged, and "We didn't even go through any proof-of-concept stage. The Code for Life work served that purpose," says Bryant.</p>
 
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/ocado/banner3.jpg"
+  author="Kevin McCormack, DevOps Team Leader, Ocado"
+>}}
+"We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn't even go through any proof-of-concept stage. The Code for Life work served that purpose,"
+{{< /case-studies/quote >}}
 
-<div class="banner5">
-  <div class="banner5text">
-    "CNCF have provided us with support of different technologies. We’ve been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We’re not being asked to commit to this one way of doing things. The vast diversity of viewpoints in CNCF lead to better technology." <span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Mike Bryant, Platform Engineer, Ocado</span>
+<p>In the summer of 2016, the team began migrating from fleet to <a href="https://kubernetes.io/">Kubernetes</a> on Ocado's private cloud. The Kubernetes stack currently uses <a href="https://github.com/kubernetes/kubeadm">kubeadm</a> for bootstrapping, <a href="https://github.com/containernetworking">CNI</a> with <a href="https://www.weave.works/oss/net/">Weave Net</a> for networking, <a href="https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html">Prometheus Operator</a> for monitoring, <a href="https://www.fluentd.org/">Fluentd</a> for logging, and <a href="http://opentracing.io/">OpenTracing</a> for distributed tracing.</p>
 
-  </div>
-</div>
+<p>The first app on Kubernetes, a business-critical service in the warehouses, went into production a year later. Once that app was running smoothly, a mass migration continued into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes, and the platform is live in Ocado's warehouses, managing tens of thousands of orders a week. At full capacity, Ocado's latest warehouse in Erith, southeast London, will deliver more than 200,000 orders per week, making it the world's largest facility for online grocery.</p>
 
-<div class="fullcol">
-  The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resource to host the same applications in Kubernetes in our test environments."<br><br>
-  One of the broader benefits of cloud native, says Bryant, is the unified API. "We have one method of doing our deployments that covers the wide range of things we need to do, and we can extend the API," he says. In addition to using Prometheus Operator, the Ocado team has started writing its own operators, some of which have been <a href="https://github.com/ocadotechnology">open sourced</a>. Plus, "CNCF has provided us with support of these different technologies. We’ve been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We’re not being asked to commit to this one way of doing things. The vast diversity of viewpoints in the CNCF leads to better technology."<br><br>
-  Ocado’s own technology, in the form of its Smart Platform, will soon be used <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">around</a> the world. And cloud native plays a crucial role in this global expansion. "I wouldn’t have wanted to try it without Kubernetes," says Bryant. "Kubernetes has made it so much nicer, especially to have that consistent way of deploying all of the applications, then taking the same thing and being able to replicate it. It’s very valuable."
+<p>There are about 150 microservices now running on Kubernetes, with multiple instances of many of them. "We're not just deploying all these microservices at once. We're deploying them all for one warehouse, and then they're all being deployed again for the next warehouse, and again and again," says Bryant.</p>
 
-</div>
-</section>
+<p>The move to Kubernetes was eye-opening for many people at Ocado Technology. "In the early days of putting the platform into our test infrastructure, the technical architect asked what network performance was like on <a href="https://www.weave.works/oss/net/">Weave Net</a> with encryption turned on," recalls Bryant. "So we found a Docker container for <a href="https://iperf.fr/">iPerf</a>, wrote a daemon set, deployed it. A few moments later, we've deployed the entire thing across this cluster. He was pretty blown away by that."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ocado/banner4.jpg"
+  author="Mike Bryant, Platform Engineer, Ocado"
+>}}
+"The unified API of Kubernetes means this is all in one place, and it's one flow for approval and rollout. I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."
+{{< /case-studies/quote >}}
+
+<p>Indeed, the impact has been profound. "Prior to containerization, we had quite restrictive deployment windows in our warehouses," says Bryant. "Moving to microservices, we've been able to deploy much more frequently. We've been able to move towards continuous delivery in a number of areas. In our older warehouse, new application deployments involve talking to a bunch of different teams for different levels of the stack: from VM provisioning, to storage, to load balancers, and so on. The unified API of Kubernetes means this is all in one place, and it's one flow for approval and rollout. I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."</p>
+
+<p>The rate of deployment has gone from as few as two per week to dozens per week. "With Kubernetes, some of our development teams have been able to deploy their application to production on the new platform without us noticing," says Bryant, "which means they're faster at doing what they need to do and we have less work."</p>
+
+<p>Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. "That lets us shrink quite a lot of our deployments from being per-core VM deployments to having fractions of the core," says Bryant. Adds McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster. This means we use our hardware better since if we have to always have two nodes of excess capacity available in case of node failures then we only need two extra instead of 20."</p>
+
+{{< case-studies/quote author="Mike Bryant, Platform Engineer, Ocado" >}}
+"CNCF have provided us with support of different technologies. We've been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We're not being asked to commit to this one way of doing things. The vast diversity of viewpoints in CNCF lead to better technology."
+{{< /case-studies/quote >}}
+
+<p>The team also uses <a href="https://prometheus.io/">Prometheus</a> and <a href="https://grafana.com/">Grafana</a> to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I'd estimate that we use about 15-25% less hardware resource to host the same applications in Kubernetes in our test environments."</p>
+
+<p>One of the broader benefits of cloud native, says Bryant, is the unified API. "We have one method of doing our deployments that covers the wide range of things we need to do, and we can extend the API," he says. In addition to using Prometheus Operator, the Ocado team has started writing its own operators, some of which have been <a href="https://github.com/ocadotechnology">open sourced</a>. Plus, "CNCF has provided us with support of these different technologies. We've been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We're not being asked to commit to this one way of doing things. The vast diversity of viewpoints in the CNCF leads to better technology."</p>
+
+<p>Ocado's own technology, in the form of its Smart Platform, will soon be used <a href="http://fortune.com/2018/05/17/ocado-kroger-warehouse-automation-amazon-walmart/">around</a> the world. And cloud native plays a crucial role in this global expansion. "I wouldn't have wanted to try it without Kubernetes," says Bryant. "Kubernetes has made it so much nicer, especially to have that consistent way of deploying all of the applications, then taking the same thing and being able to replicate it. It's very valuable."</p>
diff --git a/content/ko/case-studies/openAI/index.html b/content/ko/case-studies/openAI/index.html
index 1b95ec5f35..543c1dee64 100644
--- a/content/ko/case-studies/openAI/index.html
+++ b/content/ko/case-studies/openAI/index.html
@@ -2,98 +2,68 @@
 title: OpenAI Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/openAI/banner1.jpg
+heading_title_logo: /images/openAI_logo.png
+subheading: >
+  Launching and Scaling Up Experiments, Made Simple
+case_study_details:
+  - Company: OpenAI
+  - Location: San Francisco, California
+  - Industry: Artificial Intelligence Research
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/openAI/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/openAI_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Launching and Scaling Up Experiments, Made Simple
+<h2>Challenge</h2>
 
-</div></h1>
+<p>An artificial intelligence research lab, OpenAI needed infrastructure for deep learning that would allow experiments to be run either in the cloud or in its own data center, and to easily scale. Portability, speed, and cost were the main drivers.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>OpenAI</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>San Francisco, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Artificial Intelligence Research</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    An artificial intelligence research lab, OpenAI needed infrastructure for deep learning that would allow experiments to be run either in the cloud or in its own data center, and to easily scale. Portability, speed, and cost were the main drivers.
-<br>
-    <h2>Solution</h2>
-    OpenAI began running Kubernetes on top of AWS in 2016, and in early 2017 migrated to Azure. OpenAI runs key experiments in fields including robotics and gaming both in Azure and in its own data centers, depending on which cluster has free capacity. "We use Kubernetes mainly as a batch scheduling system and rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster," says Christopher Berner, Head of Infrastructure. "This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."
-</div>
-
-<div class="col2">
+<p>OpenAI began running Kubernetes on top of AWS in 2016, and in early 2017 migrated to Azure. OpenAI runs key experiments in fields including robotics and gaming both in Azure and in its own data centers, depending on which cluster has free capacity. "We use Kubernetes mainly as a batch scheduling system and rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster," says Christopher Berner, Head of Infrastructure. "This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."</p>
 
 <h2>Impact</h2>
-  The company has benefited from greater portability: "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. Being able to use its own data centers when appropriate is "lowering costs and providing us access to hardware that we wouldn’t necessarily have access to in the cloud," he adds. "As long as the utilization is high, the costs are much lower there." Launching experiments also takes far less time: "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days. In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
 
+<p>The company has benefited from greater portability: "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. Being able to use its own data centers when appropriate is "lowering costs and providing us access to hardware that we wouldn't necessarily have access to in the cloud," he adds. "As long as the utilization is high, the costs are much lower there." Launching experiments also takes far less time: "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days. In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."</p>
 
-</div>
+{{< case-studies/quote >}}
+<iframe width="560" height="315" src="https://www.youtube.com/embed/v4N3Krzb8Eg" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<br>
+Check out "Building the Infrastructure that Powers the Future of AI" presented by  Vicki Cheung, Member of Technical Staff & Jonas Schneider, Member of Technical Staff at OpenAI from KubeCon/CloudNativeCon Europe 2017.
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
+{{< case-studies/lead >}}
+From experiments in robotics to old-school video game play research, OpenAI's work in artificial intelligence technology is meant to be shared.
+{{< /case-studies/lead >}}
 
-<div class="video">
-<iframe width="560" height="315" src="https://www.youtube.com/embed/v4N3Krzb8Eg" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe><br>
-<span style="font-size:21px;line-height:0.5em !important;width:60%;">Check out "Building the Infrastructure that Powers the Future of AI" presented by  Vicki Cheung, Member of Technical Staff & Jonas Schneider, Member of Technical Staff at OpenAI from KubeCon/CloudNativeCon Europe 2017.</span>
-</div>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>From experiments in robotics to old-school video game play research, OpenAI’s work in artificial intelligence technology is meant to be shared.</h2>
-  With a mission to ensure powerful AI systems are safe, OpenAI cares deeply about open source—both benefiting from it and contributing safety technology into it. "The research that we do, we want to spread it as widely as possible so everyone can benefit," says OpenAI’s Head of Infrastructure Christopher Berner. The lab’s philosophy—as well as its particular needs—lent itself to embracing an open source, cloud native strategy for its deep learning infrastructure.<br><br>
-  OpenAI started running Kubernetes on top of AWS in 2016, and a year later, migrated the Kubernetes clusters to Azure. "We probably use Kubernetes differently from a lot of people," says Berner. "We use it for batch scheduling and as a workload manager for the cluster. It’s a way of coordinating a large number of containers that are all connected together. We rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster. This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration." <br><br>
-  In the past year, Berner has overseen the launch of several Kubernetes clusters in OpenAI’s own data centers. "We run them in a hybrid model where the control planes—the Kubernetes API servers, <a href="https://github.com/coreos/etcd">etcd</a> and everything—are all in Azure, and then all of the Kubernetes nodes are in our own data center," says Berner. "The cloud is really convenient for managing etcd and all of the masters, and having backups and spinning up new nodes if anything breaks. This model allows us to take advantage of lower costs and have the availability of more specialized hardware in our own data center."
+<p>With a mission to ensure powerful AI systems are safe, OpenAI cares deeply about open source—both benefiting from it and contributing safety technology into it. "The research that we do, we want to spread it as widely as possible so everyone can benefit," says OpenAI's Head of Infrastructure Christopher Berner. The lab's philosophy—as well as its particular needs—lent itself to embracing an open source, cloud native strategy for its deep learning infrastructure.</p>
 
+<p>OpenAI started running Kubernetes on top of AWS in 2016, and a year later, migrated the Kubernetes clusters to Azure. "We probably use Kubernetes differently from a lot of people," says Berner. "We use it for batch scheduling and as a workload manager for the cluster. It's a way of coordinating a large number of containers that are all connected together. We rely on our <a href="https://github.com/openai/kubernetes-ec2-autoscaler">autoscaler</a> to dynamically scale up and down our cluster. This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/openAI/banner3.jpg')">
-  <div class="banner3text">
-    OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..."
+<p>In the past year, Berner has overseen the launch of several Kubernetes clusters in OpenAI's own data centers. "We run them in a hybrid model where the control planes—the Kubernetes API servers, <a href="https://github.com/coreos/etcd">etcd</a> and everything—are all in Azure, and then all of the Kubernetes nodes are in our own data center," says Berner. "The cloud is really convenient for managing etcd and all of the masters, and having backups and spinning up new nodes if anything breaks. This model allows us to take advantage of lower costs and have the availability of more specialized hardware in our own data center."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Different teams at OpenAI currently run a couple dozen projects. While the largest-scale workloads manage bare cloud VMs directly, most of OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. The on-prem clusters are generally "used for workloads where you need lots of GPUs, something like training an ImageNet model. Anything that’s CPU heavy, that’s run in the cloud. But we also have a number of teams that run their experiments both in Azure and in our own data centers, just depending on which cluster has free capacity, and that’s hugely valuable."<br><br>
-  Berner has made the Kubernetes clusters available to all OpenAI teams to use if it’s a good fit. "I’ve worked a lot with our games team, which at the moment is doing research on classic console games," he says. "They had been running a bunch of their experiments on our dev servers, and they had been trying out Google cloud, managing their own VMs. We got them to try out our first on-prem Kubernetes cluster, and that was really successful. They’ve now moved over completely to it, and it has allowed them to scale up their experiments by 10x, and do that without needing to invest significant engineering time to figure out how to manage more machines. A lot of people are now following the same path."
+{{< case-studies/quote image="/images/case-studies/openAI/banner3.jpg" >}}
+OpenAI's experiments take advantage of Kubernetes' benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/openAI/banner4.jpg')">
-  <div class="banner4text">
+<p>Different teams at OpenAI currently run a couple dozen projects. While the largest-scale workloads manage bare cloud VMs directly, most of OpenAI's experiments take advantage of Kubernetes' benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. The on-prem clusters are generally "used for workloads where you need lots of GPUs, something like training an ImageNet model. Anything that's CPU heavy, that's run in the cloud. But we also have a number of teams that run their experiments both in Azure and in our own data centers, just depending on which cluster has free capacity, and that's hugely valuable."</p>
+
+<p>Berner has made the Kubernetes clusters available to all OpenAI teams to use if it's a good fit. "I've worked a lot with our games team, which at the moment is doing research on classic console games," he says. "They had been running a bunch of their experiments on our dev servers, and they had been trying out Google cloud, managing their own VMs. We got them to try out our first on-prem Kubernetes cluster, and that was really successful. They've now moved over completely to it, and it has allowed them to scale up their experiments by 10x, and do that without needing to invest significant engineering time to figure out how to manage more machines. A lot of people are now following the same path."</p>
+
+{{< case-studies/quote image="/images/case-studies/openAI/banner4.jpg" >}}
 "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
-  </div>
-</div>
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important;">
-<div class="fullcol">
-  That path has been simplified by frameworks and tools that two of OpenAI’s teams have developed to handle interaction with Kubernetes. "You can just write some Python code, fill out a bit of configuration with exactly how many machines you need and which types, and then it will prepare all of those specifications and send it to the Kube cluster so that it gets launched there," says Berner. "And it also provides a bit of extra monitoring and better tooling that’s designed specifically for these machine learning projects."<br><br>
-  The impact that Kubernetes has had at OpenAI is impressive. With Kubernetes, the frameworks and tooling, including the autoscaler, in place, launching experiments takes far less time. "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."  <br><br>
-  Plus, the flexibility they now have to use their on-prem Kubernetes cluster when appropriate is "lowering costs and providing us access to hardware that we wouldn’t necessarily have access to in the cloud," he says. "As long as the utilization is high, the costs are much lower in our data center. To an extent, you can also customize your hardware to exactly what you need."
+<p>That path has been simplified by frameworks and tools that two of OpenAI's teams have developed to handle interaction with Kubernetes. "You can just write some Python code, fill out a bit of configuration with exactly how many machines you need and which types, and then it will prepare all of those specifications and send it to the Kube cluster so that it gets launched there," says Berner. "And it also provides a bit of extra monitoring and better tooling that's designed specifically for these machine learning projects."</p>
 
+<p>The impact that Kubernetes has had at OpenAI is impressive. With Kubernetes, the frameworks and tooling, including the autoscaler, in place, launching experiments takes far less time. "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."</p>
 
-</div>
+<p>Plus, the flexibility they now have to use their on-prem Kubernetes cluster when appropriate is "lowering costs and providing us access to hardware that we wouldn't necessarily have access to in the cloud," he says. "As long as the utilization is high, the costs are much lower in our data center. To an extent, you can also customize your hardware to exactly what you need."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "Research teams can now take advantage of the frameworks we’ve built on top of Kubernetes, which make it easy to launch experiments, scale them by 10x or 50x, and take little effort to manage." <br><span style="font-size:14px;letter-spacing:0.12em;padding-top:20px">— CHRISTOPHER BERNER, HEAD OF INFRASTRUCTURE FOR OPENAI</span>
-  </div>
-</div>
+{{< case-studies/quote author="CHRISTOPHER BERNER, HEAD OF INFRASTRUCTURE FOR OPENAI" >}}
+"Research teams can now take advantage of the frameworks we've built on top of Kubernetes, which make it easy to launch experiments, scale them by 10x or 50x, and take little effort to manage."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
+<p>OpenAI is also benefiting from other technologies in the CNCF cloud-native ecosystem. <a href="https://grpc.io/">gRPC</a> is used by many of its systems for communications between different services, and <a href="https://prometheus.io/">Prometheus</a> is in place "as a debugging tool if things go wrong," says Berner. "We actually haven't had any real problems in our Kubernetes clusters recently, so I don't think anyone has looked at our Prometheus monitoring in a while. If something breaks, it will be there."</p>
 
-  OpenAI is also benefiting from other technologies in the CNCF cloud-native ecosystem. <a href="https://grpc.io/">gRPC</a> is used by many of its systems for communications between different services, and <a href="https://prometheus.io/">Prometheus</a> is in place "as a debugging tool if things go wrong," says Berner. "We actually haven’t had any real problems in our Kubernetes clusters recently, so I don’t think anyone has looked at our Prometheus monitoring in a while. If something breaks, it will be there."<br><br>
-  One of the things Berner continues to focus on is Kubernetes’ ability to scale, which is essential to deep learning experiments. OpenAI has been able to push one of its Kubernetes clusters on Azure up to more than <a href="https://blog.openai.com/scaling-kubernetes-to-2500-nodes/">2,500 nodes</a>. "I think we’ll probably hit the 5,000-machine number that Kubernetes has been tested at before too long," says Berner, adding, "We’re definitely <a href="https://jobs.lever.co/openai">hiring</a> if you’re excited about working on these things!"
-</div>
-
-</section>
+<p>One of the things Berner continues to focus on is Kubernetes' ability to scale, which is essential to deep learning experiments. OpenAI has been able to push one of its Kubernetes clusters on Azure up to more than <a href="https://blog.openai.com/scaling-kubernetes-to-2500-nodes/">2,500 nodes</a>. "I think we'll probably hit the 5,000-machine number that Kubernetes has been tested at before too long," says Berner, adding, "We're definitely <a href="https://jobs.lever.co/openai">hiring</a> if you're excited about working on these things!"</p>
diff --git a/content/ko/case-studies/peardeck/index.html b/content/ko/case-studies/peardeck/index.html
index 688754a620..4398277677 100644
--- a/content/ko/case-studies/peardeck/index.html
+++ b/content/ko/case-studies/peardeck/index.html
@@ -1,111 +1,87 @@
 ---
 title: Pear Deck Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_peardeck.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/peardeck/banner3.jpg
+heading_title_logo: /images/peardeck_logo.png
+subheading: >
+  Infrastructure for a Growing EdTech Startup
+case_study_details:
+  - Company: Pear Deck
+  - Location: Iowa City, Iowa
+  - Industry: Educational Software
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/peardeck_logo.png"  width="22%" style="margin-bottom:-0px"><br> <div class="subhead">Infrastructure for a Growing EdTech Startup</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript app was built on Google's web app development platform <a href="https://firebase.google.com/">Firebase</a>, using <a href="https://www.heroku.com/">Heroku</a>. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn't have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.</p>
 
-<div class="details">
-    Company &nbsp;<b>Pear Deck</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Iowa City, Iowa</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Educational Software</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>In 2016, the company began moving their code from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.</p>
 
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-      The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript app was built on Google’s web app development platform <a href="https://firebase.google.com/">Firebase</a>, using <a href="https://www.heroku.com/">Heroku</a>. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
-</div>
-
-<div class="col2">
-  <h2>Solution</h2>
-    In 2016, the company began moving their code from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.
-    <br>
-    <br>
 <h2>Impact</h2>
-      The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."
-</div>
-</div>
-</section>
 
-<div class="banner2">
-  <div class="banner2text">
-    "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app. I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."<br><br><span style="font-size:16px;letter-spacing:2px;">– RILEY EYNON-LYNCH, CEO OF PEAR DECK</span>
-  </div>
-</div>
+<p>The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."</p>
 
-<section class="section2">
-<div class="fullcol">
-<h2>With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating.</h2>
-As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It’s a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."<br><br>
-Eynon-Lynch and his partners quickly built a JavaScript web app on Google’s web app development platform <a href="https://firebase.google.com/">Firebase</a>, and launched the minimum viable product [MVP] on <a href="https://www.heroku.com/">Heroku</a> "because it was fast and easy," he says. "We made everything as easy as we could."
-<br><br>
-But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version. Tracing and monitoring became basically impossible."
-<br><br>
-On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
-<br><br>
-The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.
-</div>
-</section>
+{{< case-studies/quote author="RILEY EYNON-LYNCH, CEO OF PEAR DECK" >}}
+"We didn't even realize how stressed out we were about our lack of insight into what was happening with the app. I'm really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."
+{{< /case-studies/quote >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch.
-  </div>
-</div>
+{{< case-studies/lead >}}
+With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating.
+{{< /case-studies/lead >}}
 
-<section class="section3">
-<div class="fullcol">
-  They had considered other options like Google’s App Engine (which they were already using for one service) and Amazon’s <a href="https://aws.amazon.com/ec2/">Elastic Compute Cloud</a> (EC2), while experimenting with running one small service that wasn’t accessible to the Internet in Kubernetes. "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn’t really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."<br><br>
-  Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never   staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that’s always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it’s become invisible how great it is."
-  <br><br>
-  Along with Kubernetes came Prometheus. "Until pretty recently we didn’t have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use Google Kubernetes Engine’s <a href="https://cloud.google.com/stackdriver/">Stackdriver</a> monitoring, but had problems making it work, and considered <a href="https://newrelic.com/">New Relic</a>. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.<br><br>
-  The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
-</div>
-</section>
+<p>As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It's a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."</p>
 
-<div class="banner4">
-  <div class="banner4text">
-    "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
-  </div>
-</div>
+<p>Eynon-Lynch and his partners quickly built a JavaScript web app on Google's web app development platform <a href="https://firebase.google.com/">Firebase</a>, and launched the minimum viable product [MVP] on <a href="https://www.heroku.com/">Heroku</a> "because it was fast and easy," he says. "We made everything as easy as we could."</p>
 
-<section class="section4">
-<div class="fullcol">
-  With Pear Deck’s specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn’t working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.<br><br>
-  To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren’t going to have to figure out, ‘Where do we send these metrics? How do we aggregate the metrics? How do we understand them?’"<br><br>
-  Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day’s loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we’re using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."<br><br>
-  Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it’s not a widespread problem. "Just to be sure, we can go and double check the graphs and say, ‘Yep, there’s currently 10,000 people connected to that Firebase node. It’s definitely working. Let’s investigate your network settings, customer,’" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."<br><br>
-  Pear Deck is also giving back to the community, building and open-sourcing a <a href="https://github.com/peardeck/prometheus-user-metrics">metrics aggregator</a> that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."<br><br>
-  Most of Pear Deck’s services have now been moved onto Kubernetes. And all of the team’s new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.
-</div>
-</section>
+<p>But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn't have the developers quickly stage a version. Tracing and monitoring became basically impossible."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says.
-  </div>
-</div>
+<p>On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.</p>
 
-<section class="section5">
-<div class="fullcol">
-  Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that’s still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there’s autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it’s definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it’s such a pain to deploy it."
-<br><br>
-They’re also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we’re interested in building our own web-socket solution that doesn’t have to be super stateful but will have maybe an hour’s worth of state on it."
-<br><br>
-That project will also involve Prometheus, for a dark launch of web socket connections. "We don’t know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don’t know what work Firebase has done to make them more reliable. So I’m really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it’s working. That’s our next new adventure, into stateful servers."
-<br><br>
-As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven’t instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they’re down, which sometimes they don’t do for a long time. So I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."
-<br><br>
-For a spry startup that’s continuing to grow rapidly—and yes, they’re <a href="https://www.peardeck.com/careers/">hiring</a>!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."
+<p>The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.</p>
 
-  <br><br>
-</div>
-</section>
+{{< case-studies/quote image="/images/case-studies/peardeck/banner1.jpg" >}}
+"When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch.
+{{< /case-studies/quote >}}
+
+<p>They had considered other options like Google's App Engine (which they were already using for one service) and Amazon's <a href="https://aws.amazon.com/ec2/">Elastic Compute Cloud</a> (EC2), while experimenting with running one small service that wasn't accessible to the Internet in Kubernetes. "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn't really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."</p>
+
+<p>Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never   staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that's always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it's become invisible how great it is."</p>
+
+<p>Along with Kubernetes came Prometheus. "Until pretty recently we didn't have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use Google Kubernetes Engine's <a href="https://cloud.google.com/stackdriver/">Stackdriver</a> monitoring, but had problems making it work, and considered <a href="https://newrelic.com/">New Relic</a>. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.</p>
+
+<p>The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"</p>
+
+{{< case-studies/quote image="/images/case-studies/peardeck/banner2.jpg" >}}
+"We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
+{{< /case-studies/quote >}}
+
+<p>With Pear Deck's specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn't even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn't working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.</p>
+
+<p>To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren't going to have to figure out, 'Where do we send these metrics? How do we aggregate the metrics? How do we understand them?'"</p>
+
+<p>Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day's loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we're using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."</p>
+
+<p>Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it's not a widespread problem. "Just to be sure, we can go and double check the graphs and say, 'Yep, there's currently 10,000 people connected to that Firebase node. It's definitely working. Let's investigate your network settings, customer,'" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."</p>
+
+<p>Pear Deck is also giving back to the community, building and open-sourcing a <a href="https://github.com/peardeck/prometheus-user-metrics">metrics aggregator</a> that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."</p>
+
+<p>Most of Pear Deck's services have now been moved onto Kubernetes. And all of the team's new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.</p>
+
+{{< case-studies/quote >}}
+"A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says.
+{{< /case-studies/quote >}}
+
+<p>Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that's still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there's autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it's definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it's such a pain to deploy it."</p>
+
+<p>They're also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we're interested in building our own web-socket solution that doesn't have to be super stateful but will have maybe an hour's worth of state on it."</p>
+
+<p>That project will also involve Prometheus, for a dark launch of web socket connections. "We don't know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don't know what work Firebase has done to make them more reliable. So I'm really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it's working. That's our next new adventure, into stateful servers."</p>
+
+<p>As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven't instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they're down, which sometimes they don't do for a long time. So I'm really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."</p>
+
+<p>For a spry startup that's continuing to grow rapidly—and yes, they're <a href="https://www.peardeck.com/careers/">hiring</a>!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."</p>
diff --git a/content/ko/case-studies/pearson/index.html b/content/ko/case-studies/pearson/index.html
index 78f70228e5..501bcea8e7 100644
--- a/content/ko/case-studies/pearson/index.html
+++ b/content/ko/case-studies/pearson/index.html
@@ -3,85 +3,81 @@ title: Pearson Case Study
 linkTitle: Pearson
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
 quote: >
-  We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
+  We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/pearson/banner1.jpg
+heading_title_logo: /images/pearson_logo.png
+subheading: >
+  Reinventing the World's Largest Education Company With Kubernetes
+case_study_details:
+  - Company: Pearson
+  - Location: Global
+  - Industry: Education
 ---
-<div class="banner1" style="background-image: url('/images/case-studies/pearson/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/pearson_logo.png" style="margin-bottom:-1.5%;" class="header_logo"><br> <div class="subhead">Reinventing the World’s Largest Education Company With Kubernetes
-  </div></h1>
-</div>
-<div class="details">
-  Company &nbsp;<b>Pearson</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Global
-  </b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Education</b>
-</div>
-<hr>
-<section class="section1">
-  <div class="cols">
-    <div class="col1">
-      <h2>Challenge</h2>
-      A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.
-      <br>
-      <h2>Solution</h2>
-      "To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity."
-      <br>
-    </div>
-    <div class="col2">
-      <h2>Impact</h2>
-      With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they’ve achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there’s high confidence in their ability to meet aggressive customer SLAs.
-      <br>
-    </div>
-  </div>
-</section>
-<div class="banner2" style="padding-top:% !important">
-  <div class="banner2text" style="width:70% !important">
-    "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."<br><br><span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;">— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span>
-  </div>
-</div>
-<section class="section2">
-  <div class="fullcol">
-    In 2015, Pearson was already serving 75 million learners as the world’s largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.<br><br>
-    That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." <br><br>
-    With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity," he says.<br><br>
-    The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
-  </div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/pearson/banner3.jpg')">
-  <div class="banner3text">
-    "Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."<span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span>
-  </div>
-</div>
-<section class="section3">
-  <div class="fullcol">
-    That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We’re an education company, so we want to share what we can," says Somogyi.<br><br>
-    Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.  <br><br>
-    According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers’ preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."<br><br>
-    Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
-  </div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/pearson/banner4.jpg')">
-  <div class="banner4text">
-    "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!" <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Chris Jackson, Director for Cloud Platforms & SRE at Pearson</span>
-  </div>
-</div>
-<section class="section5" style="padding:0px !important">
-  <div class="fullcol">
-    Availability has also been positively impacted. The back-to-school period is the company’s busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.
-    <br><br>
-    "You can’t even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."
-    <br><br>
-    The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."
-    <br><br>
-    Guided by Pearson’s overarching goal of getting to 200 million users, the team has run internal tests of the platform’s scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to <a href="https://locust.io/">Locust</a>for that one. So that’s amazing."
-  </div>
-  <div class="banner5">
-    <div class="banner5text">
-      "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can’t even begin to put a price on how much that saves the company." <span style="font-size:16px;text-transform:uppercase;letter-spacing:0.1em;"><br><br>— Benjamin Somogyi, Principal Systems Architect at Pearson</span></div>
-    </div>
-    <div class="fullcol">
-      In just two years, "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."<br><br>
-      So far, about 15 production products are running on the new platform, including Pearson’s new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley. <br><br>
-      But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven’t started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."
-    </div>
-  </section>
+
+<h2>Challenge</h2>
+
+<p>A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.</p>
+
+<h2>Solution</h2>
+
+<p>"To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers' productivity."</p>
+
+<h2>Impact</h2>
+
+<p>With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we've gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they've achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there's high confidence in their ability to meet aggressive customer SLAs.</p>
+
+{{< case-studies/quote author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson" >}}
+"We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
+{{< /case-studies/quote >}}
+
+<p>In 2015, Pearson was already serving 75 million learners as the world's largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.</p>
+
+<p>That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way."</p>
+
+<p>With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers' productivity," he says.</p>
+
+<p>The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes' benefits are huge. We're trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/pearson/banner3.jpg"
+  author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson"
+>}}
+"Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."
+{{< /case-studies/quote >}}
+
+<p>That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We're an education company, so we want to share what we can," says Somogyi.</p>
+
+<p>Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we've gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.</p>
+
+<p>According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers' preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."</p>
+
+<p>Jackson estimates they've achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/pearson/banner4.jpg"
+  author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson"
+>}}
+"Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
+{{< /case-studies/quote >}}
+
+<p>Availability has also been positively impacted. The back-to-school period is the company's busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We're not worried about 9s. There aren't any. It's 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.</p>
+
+<p>"You can't even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."</p>
+
+<p>The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."</p>
+
+<p>Guided by Pearson's overarching goal of getting to 200 million users, the team has run internal tests of the platform's scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to <a href="https://locust.io/">Locust</a>for that one. So that's amazing."</p>
+
+{{< case-studies/quote author="Benjamin Somogyi, Principal Systems Architect at Pearson" >}}
+"We have 100% uptime. We're not worried about 9s. There aren't any. It's 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can't even begin to put a price on how much that saves the company."
+{{< /case-studies/quote >}}
+
+<p>In just two years, "We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."</p>
+
+<p>So far, about 15 production products are running on the new platform, including Pearson's new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley.</p>
+
+<p>But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven't started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."</p>
diff --git a/content/ko/case-studies/pinterest/index.html b/content/ko/case-studies/pinterest/index.html
index e4be7031bb..b95fff054a 100644
--- a/content/ko/case-studies/pinterest/index.html
+++ b/content/ko/case-studies/pinterest/index.html
@@ -3,106 +3,82 @@ title: Pinterest Case Study
 linkTitle: Pinterest
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: false
 weight: 30
 quote: >
   We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/pinterest/banner1.jpg
+heading_title_logo: /images/pinterest_logo.png
+subheading: >
+  Pinning Its Past, Present, and Future on Cloud Native
+case_study_details:
+  - Company: Pinterest
+  - Location: San Francisco, California
+  - Industry: Web and Mobile App
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/pinterest/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/pinterest_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Pinning Its Past, Present, and Future on Cloud Native
+<p>After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
-
-<div class="details">
-    Company &nbsp;<b>Pinterest</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>San Francisco, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Web and Mobile App</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-<br><br>
-    <h2>Challenge</h2>
-    After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.
-
-<br><br>
-
- <h2>Solution</h2>
-    The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.
-
-<br><br>
+<p>The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.</p>
 
 <h2>Impact</h2>
-  "By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
 
-</div>
-</div>
+<p>"By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."</p>
 
-</section>
-<div class="banner2" style="text-align:center">
-  <iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
-  <div class="banner2text"><br><br>
-"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we&nbsp;were&nbsp;pushing&nbsp;for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest</span>
+{{< case-studies/quote author="Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest" >}}
+<iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<br>
+"So far it's been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- <h2></h2>Pinterest was born on the cloud—running on <a href="https://aws.amazon.com/">AWS</a> since day one in 2010—but even cloud native companies can experience some growing pains.</h2> Since its launch, Pinterest has become a household name, with more than 200 million active monthly users and 100 billion objects saved. Underneath the hood, there are 1,000 microservices running and hundreds of thousands of data jobs.<br><br>
-With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production.
-So in 2016, the company launched a roadmap toward a new compute platform, led by the vision of having the fastest path from an idea to production, without making engineers worry about the underlying infrastructure. <br><br>
-The first phase involved moving to Docker. "Pinterest has been heavily running on virtual machines, on EC2 instances directly, for the longest time," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group. "To solve the problem around packaging software and not make engineers own portions of the fleet and those kinds of challenges, we standardized the packaging mechanism and then moved that to the container on top of the VM. Not many drastic changes. We didn’t want to boil the ocean at that point."
+{{< case-studies/lead >}}
+Pinterest was born on the cloud—running on <a href="https://aws.amazon.com/">AWS</a> since day one in 2010—but even cloud native companies can experience some growing pains.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/pinterest/banner3.jpg')">
-  <div class="banner3text">
-    "Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>Since its launch, Pinterest has become a household name, with more than 200 million active monthly users and 100 billion objects saved. Underneath the hood, there are 1,000 microservices running and hundreds of thousands of data jobs.</p>
 
-The first service that was migrated was the monolith API fleet that powers most of Pinterest. At the same time, Benedict’s infrastructure governance team built chargeback and capacity planning systems to analyze how the company uses its virtual machines on AWS. "It became clear that running on VMs is just not sustainable with what we’re doing," says Benedict. "A lot of resources were underutilized. There were efficiency efforts, which worked fine at a certain scale, but now you have to move to a more decentralized way of managing that. So orchestration was something we thought could help solve that piece."<br><br>
-That led to the second phase of the roadmap. In July 2017, after an eight-week evaluation period, the team chose Kubernetes over other orchestration platforms. "Kubernetes lacked certain things at the time—for example, we wanted Spark on Kubernetes," says Benedict. "But we realized that the dev cycles we would put in to even try building that is well worth the outcome, both for Pinterest as well as the community. We’ve been in those conversations in the Big Data SIG. We realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."<br><br>
-At the beginning of 2018, the team began onboarding its first use case into the Kubernetes system: Jenkins workloads. "Although we have builds happening during a certain period of the day, we always need to allocate peak capacity," says Benedict. "They don’t have any auto-scaling capabilities, so that capacity stays constant. It is difficult to speed up builds because ramping up takes more time. So given those kind of concerns, we thought that would be a perfect use case for us to work on."
+<p>With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production. So in 2016, the company launched a roadmap toward a new compute platform, led by the vision of having the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.</p>
 
+<p>The first phase involved moving to Docker. "Pinterest has been heavily running on virtual machines, on EC2 instances directly, for the longest time," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group. "To solve the problem around packaging software and not make engineers own portions of the fleet and those kinds of challenges, we standardized the packaging mechanism and then moved that to the container on top of the VM. Not many drastic changes. We didn't want to boil the ocean at that point."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/pinterest/banner4.jpg')">
-  <div class="banner4text">
-"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/pinterest/banner3.jpg"
+  author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST"
+>}}
+"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we'll be able to leverage what the community is doing."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
- They ramped up the cluster, and working with a team of four people, got the Jenkins Kubernetes cluster ready for production. "We still have our static Jenkins cluster," says Benedict, "but on Kubernetes, we are doing similar builds, testing the entire pipeline, getting the artifact ready and just doing the comparison to see, how much time did it take to build over here. Is the SLA okay, is the artifact generated correct, are there issues there?" <br><br>
-"So far it’s been good," he adds, "especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."<br><br>
-By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the <a href="https://github.com/jenkinsci/kubernetes-plugin">Jenkins Kubernetes Plugin</a> to manage the lifecycle of workers. "We’re currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
+<p>The first service that was migrated was the monolith API fleet that powers most of Pinterest. At the same time, Benedict's infrastructure governance team built chargeback and capacity planning systems to analyze how the company uses its virtual machines on AWS. "It became clear that running on VMs is just not sustainable with what we're doing," says Benedict. "A lot of resources were underutilized. There were efficiency efforts, which worked fine at a certain scale, but now you have to move to a more decentralized way of managing that. So orchestration was something we thought could help solve that piece."</p>
 
+<p>That led to the second phase of the roadmap. In July 2017, after an eight-week evaluation period, the team chose Kubernetes over other orchestration platforms. "Kubernetes lacked certain things at the time—for example, we wanted Spark on Kubernetes," says Benedict. "But we realized that the dev cycles we would put in to even try building that is well worth the outcome, both for Pinterest as well as the community. We've been in those conversations in the Big Data SIG. We realized that by the time we get to productionizing many of those things, we'll be able to leverage what the community is doing."</p>
 
-</div>
+<p>At the beginning of 2018, the team began onboarding its first use case into the Kubernetes system: Jenkins workloads. "Although we have builds happening during a certain period of the day, we always need to allocate peak capacity," says Benedict. "They don't have any auto-scaling capabilities, so that capacity stays constant. It is difficult to speed up builds because ramping up takes more time. So given those kind of concerns, we thought that would be a perfect use case for us to work on."</p>
 
-<div class="banner5">
-  <div class="banner5text">
- "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/pinterest/banner4.jpg"
+  author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST"
+>}}
+"So far it's been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
- Benedict points to a "pretty robust roadmap" going forward. In addition to the Pinterest big data team’s experiments with Spark on Kubernetes, the company collaborated with Amazon’s EKS team on an ENI/CNI plug in. <br><br>
-Once the Jenkins cluster is up and running out of dark mode, Benedict hopes to establish best practices, including having governance primitives established—including integration with the chargeback system—before moving on to migrating the next service. "We have a healthy pipeline of use-cases to be on-boarded. After Jenkins, we want to enable support for Tensorflow and Apache Spark. At some point, we aim to move the company’s monolithic API service. If we move that and understand the complexity around that, it builds our confidence," says Benedict. "It sets us up for migration of all our other services."<br><br>
-After years of being a cloud native pioneer, Pinterest is eager to share its ongoing journey. "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do," says Benedict. "We’re in a great position to contribute back some of those learnings."
+<p>They ramped up the cluster, and working with a team of four people, got the Jenkins Kubernetes cluster ready for production. "We still have our static Jenkins cluster," says Benedict, "but on Kubernetes, we are doing similar builds, testing the entire pipeline, getting the artifact ready and just doing the comparison to see, how much time did it take to build over here. Is the SLA okay, is the artifact generated correct, are there issues there?"</p>
 
+<p>"So far it's been good," he adds, "especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."</p>
 
+<p>By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the <a href="https://github.com/jenkinsci/kubernetes-plugin">Jenkins Kubernetes Plugin</a> to manage the lifecycle of workers. "We're currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."</p>
 
-</div>
+{{< case-studies/quote author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST">}}
+"We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do."
+{{< /case-studies/quote >}}
 
-</section>
+<p>Benedict points to a "pretty robust roadmap" going forward. In addition to the Pinterest big data team's experiments with Spark on Kubernetes, the company collaborated with Amazon's EKS team on an ENI/CNI plug in.</p>
+
+<p>Once the Jenkins cluster is up and running out of dark mode, Benedict hopes to establish best practices, including having governance primitives established—including integration with the chargeback system—before moving on to migrating the next service. "We have a healthy pipeline of use-cases to be on-boarded. After Jenkins, we want to enable support for Tensorflow and Apache Spark. At some point, we aim to move the company's monolithic API service. If we move that and understand the complexity around that, it builds our confidence," says Benedict. "It sets us up for migration of all our other services."</p>
+
+<p>After years of being a cloud native pioneer, Pinterest is eager to share its ongoing journey. "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do," says Benedict. "We're in a great position to contribute back some of those learnings."</p>
diff --git a/content/ko/case-studies/slingtv/index.html b/content/ko/case-studies/slingtv/index.html
index 349ed8c2de..6de46f35ff 100644
--- a/content/ko/case-studies/slingtv/index.html
+++ b/content/ko/case-studies/slingtv/index.html
@@ -3,108 +3,77 @@ title: SlingTV Case Study
 linkTitle: Sling TV
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 featured: true
 weight: 49
 quote: >
   I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/slingtv/banner1.jpg
+heading_title_logo: /images/slingtv_logo.png
+subheading: >
+  Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale
+case_study_details:
+  - Company: Sling TV
+  - Location: Englewood, Colorado
+  - Industry: Streaming television
 ---
 
+<h2>Challenge</h2>
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/slingtv/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/slingtv_logo.png" style="margin-bottom:-1.5%;width:15% !important" class="header_logo"><br> <div class="subhead" style="padding-top:1% !important">Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale
+<p>Launched by DISH Network in 2015, Sling TV experienced great customer growth from the beginning. After just a year, "we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future," says Brad Linder, Sling TV's Cloud Native & Big Data Evangelist. The company has particular challenges: "We take live TV and distribute it over the internet out to a user's device that we do not control," says Linder. "In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer's service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and good customer experience at web scale."</p>
 
-</div></h1>
+<h2>Solution</h2>
 
-</div>
-
-<div class="details">
-    Company &nbsp;<b>Sling TV</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Englewood, Colorado</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Streaming television</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:95% !important;padding-left:5%">
-    <h2>Challenge</h2>
-    Launched by DISH Network in 2015, Sling TV experienced great customer growth from the beginning. After just a year, “we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future,” says Brad Linder, Sling TV’s Cloud Native & Big Data Evangelist. The company has particular challenges: “We take live TV and distribute it over the internet out to a user’s device that we do not control,” says Linder. “In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer’s service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and good customer experience at web scale.”
-
-<br><br>
-
- <h2>Solution</h2>
-   Led by the belief that “the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of that sort of customer base,” Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build Sling TV’s next-generation platform around Kubernetes. “We are going to need to enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business at some point, so getting that sort of abstraction was a real goal,” he says. “That is one of the biggest reasons why we picked Kubernetes.” The team launched its first applications on Kubernetes in Sling TV’s two internal data centers. The push to enable AWS as a data center option is underway and should be available by the end of 2018. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.
-
-</div>
-<br><br>
-<div class="col2" style="width:95% !important;padding-left:5%;padding-top:2% !important">
+<p>Led by the belief that "the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of that sort of customer base," Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build Sling TV's next-generation platform around Kubernetes. "We are going to need to enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business at some point, so getting that sort of abstraction was a real goal," he says. "That is one of the biggest reasons why we picked Kubernetes." The team launched its first applications on Kubernetes in Sling TV's two internal data centers. The push to enable AWS as a data center option is underway and should be available by the end of 2018. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company's existing tool sets: Zenoss, New Relic and ELK.</p>
 
 <h2>Impact</h2>
- “We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale.”
+
+<p>"We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps," says Linder. "We have really enabled a platform thinking based approach to allowing applications to consume common tools.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale."</p>
+
+{{< case-studies/quote author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV" >}}
+"I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+The beauty of streaming television, like the service offered by <a href="https://www.sling.com/">Sling TV</a>, is that you can watch it from any device you want, wherever you want.
+{{< /case-studies/lead >}}
 
 
-</div>
+<p>Of course, from the provider side of things, that creates a particular set of challenges "We take live TV and distribute it over the internet out to a user's device that we do not control," says Brad Linder, Sling TV's Cloud Native & Big Data Evangelist. "In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer's service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and we have to do it at web scale."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
- “I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span>
+<p>Indeed, Sling TV experienced great customer growth from the beginning of its launch by <a href="https://www.dish.com/">DISH Network</a> in 2015. After just a year, "we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future," says Linder. Tasked with building a next-generation web scale platform for the "personalized customer experience," Linder has spent the past year bringing Kubernetes to Sling TV.</p>
 
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
- <h2>The beauty of streaming television, like the service offered by <a href="https://www.sling.com/" style="text-decoration:underline">Sling TV</a>, is that you can watch it from any device you want, wherever you want.</h2> Of course, from the provider side of things, that creates a particular set of challenges
-“We take live TV and distribute it over the internet out to a user’s device that we do not control,” says Brad Linder, Sling TV’s Cloud Native & Big Data Evangelist. “In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer’s service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and we have to do it at web scale.”<br><br>
-Indeed, Sling TV experienced great customer growth from the beginning of its launch by <a href="https://www.dish.com/">DISH Network</a> in 2015. After just a year, “we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future,” says Linder. Tasked with building a next-generation web scale platform for the “personalized customer experience,” Linder has spent the past year bringing Kubernetes to Sling TV.<br><br>
-Led by the belief that “the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of our customers,” Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build the platform around Kubernetes. “They have really helped us get our head around how to use Kubernetes,” he says. “We needed the flexibility to enable our use case versus just a simple orchestrater.  Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”
+<p>Led by the belief that "the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of our customers," Linder partnered with <a href="http://rancher.com">Rancher Labs</a> to build the platform around Kubernetes. "They have really helped us get our head around how to use Kubernetes," he says. "We needed the flexibility to enable our use case versus just a simple orchestrater.  Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition."</p>
 
+{{< case-studies/quote
+  image="/images/case-studies/slingtv/banner3.jpg"
+  author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV"
+>}}
+"We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/slingtv/banner3.jpg')">
-  <div class="banner3text">
-    “We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value&nbsp;proposition.” <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to "enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business," he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. "We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications' well-being," says Linder. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company's existing tool sets: Zenoss, New Relic and ELK.</p>
 
-One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to “enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business,” he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. “We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications’ well-being,” says Linder. The team has added <a href="https://prometheus.io/">Prometheus</a> for monitoring and <a href="https://github.com/jaegertracing/jaeger">Jaeger</a> for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.<br><br>
-With the emphasis on common tooling, “We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools and services.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web&nbsp;scale.”<br><br>
+<p>With the emphasis on common tooling, "We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps," says Linder. "We have really enabled a platform thinking based approach to allowing applications to consume common tools and services.  A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy.  That does not consider the training of our operations staff to manage this new application.  It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/slingtv/banner4.jpg')">
-  <div class="banner4text">
-“We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV</span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/slingtv/banner4.jpg"
+  author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV"
+>}}
+"We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers."
+{{< /case-studies/quote >}}
 
-<section class="section5" style="padding:0px !important">
+<p>The team launched its first applications on Kubernetes in Sling TV's two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.</p>
 
-<div class="fullcol">
- The team launched its first applications on Kubernetes in Sling TV’s two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.
-The first application that went into production is a web socket-based back-end notification service. “It allows back-end changes to trigger messages to our clients in the field without the polling,” says Linder. “We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”<br><br>
- Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. “We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer.  That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly,” says Linder.
+<p>The first application that went into production is a web socket-based back-end notification service. "It allows back-end changes to trigger messages to our clients in the field without the polling," says Linder. "We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables."</p>
 
+<p>Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. "We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer.  That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly," says Linder.</p>
 
-</div>
+{{< case-studies/quote author="BRAD LINDER, CLOUD NATIVE & BIG DATA EVANGELIST FOR SLING TV">}}
+This undertaking is about "trying to marry Kubernetes with AI to enable web scale that just works".
+{{< /case-studies/quote >}}
 
-<div class="banner5">
-  <div class="banner5text">
-  This undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works". <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— BRAD LINDER, CLOUD NATIVE & BIG DATA EVANGELIST FOR SLING TV </span>
-  </div>
-</div>
+<p>Ultimately, this undertaking is about "trying to marry Kubernetes with AI to enable web scale that just works," he adds. "We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, 'Hey we need more capacity for this service so please add more nodes.' From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a 'millions of users' sort of environment, that implosion is going to be catastrophic.  We are on our way to this goal and have learned a lot along the way."</p>
 
-<div class="fullcol">
- Ultimately, this undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works,” he adds. “We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, ‘Hey we need more capacity for this service so please add more nodes.’ From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a ‘millions of users’ sort of environment, that implosion is going to be catastrophic.  We are on our way to this goal and have learned a lot along the way.”<br><br>
-For Sling TV, moving to cloud native has been exactly what they needed. “We have to be able to react to changes and hiccups in the matrix,” says Linder. “It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect.”
-
-
-
-
-
-</div>
-
-</section>
+<p>For Sling TV, moving to cloud native has been exactly what they needed. "We have to be able to react to changes and hiccups in the matrix," says Linder. "It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect."</p>
diff --git a/content/ko/case-studies/squarespace/index.html b/content/ko/case-studies/squarespace/index.html
index 27340835f4..461e466d8c 100644
--- a/content/ko/case-studies/squarespace/index.html
+++ b/content/ko/case-studies/squarespace/index.html
@@ -2,100 +2,70 @@
 title: Squarespace Case Study
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/squarespace/banner1.jpg
+heading_title_logo: /images/squarespace_logo.png
+subheading: >
+  Squarespace: Gaining Productivity and Resilience with Kubernetes
+case_study_details:
+  - Company: Squarespace
+  - Location: New York, N.Y.
+  - Industry: Software as a Service, Website-Building Platform
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/squarespace/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/squarespace_logo.png" class="header_logo"><br> <div class="subhead">Squarespace: Gaining Productivity and Resilience with Kubernetes
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>Moving from a monolith to microservices in 2014 "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace. "The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."</p>
 
-<div class="details">
-    Company &nbsp;<b>Squarespace</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, N.Y.</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Software as a Service, Website-Building Platform</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    Moving from a monolith to microservices in 2014 "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace. "The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."
-<br>
 <h2>Solution</h2>
-The team experimented with container orchestration platforms, and found that Kubernetes "answered all the questions that we had," says Lynch. The company began running Kubernetes in its data centers in&nbsp;2016.
 
-      </div>
-
-<div class="col2">
+<p>The team experimented with container orchestration platforms, and found that Kubernetes "answered all the questions that we had," says Lynch. The company began running Kubernetes in its data centers in 2016.</p>
 
 <h2>Impact</h2>
-Since Squarespace moved to Kubernetes, in conjunction with modernizing its networking stack, deployment time has been reduced by almost 85%. Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes, and have actual instances containerized, running in our staging environment at that point." Because of that, "productivity time is the big cost saver," he adds. "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on." Resilience has also been improved with Kubernetes: "If a node goes down, it’s rescheduled immediately and there’s no performance&nbsp;impact."
 
-</div>
+<p>Since Squarespace moved to Kubernetes, in conjunction with modernizing its networking stack, deployment time has been reduced by almost 85%. Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes, and have actual instances containerized, running in our staging environment at that point." Because of that, "productivity time is the big cost saver," he adds. "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on." Resilience has also been improved with Kubernetes: "If a node goes down, it's rescheduled immediately and there's no performance impact."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    <iframe width="560" height="315" src="https://www.youtube.com/embed/feQkzJkW-SA" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-    <br><br>"Once you prove that Kubernetes solves one problem, everyone immediately starts solving other problems without you even having to evangelize it."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Since it was started in a dorm room in 2003, Squarespace has made it simple for millions of people to create their own websites.</h2> Behind the scenes, though, the company’s monolithic Java application was making things not so simple for its developers to keep improving the platform. So in 2014, the company decided to "go down the microservices path," says Kevin Lynch, staff engineer on Squarespace’s Site Reliability team. "But we were always deploying our applications in vCenter VMware VMs [in our own data centers]. Microservices solved a problem on the development side, but it pushed that problem to the Infrastructure team. The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."<br><br>
-  After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." Deploying it in the data center rather than the public cloud was their biggest challenge, and at the time, not a lot of other companies were doing that. "We had to figure out how to deploy this in our infrastructure for ourselves, and we had to integrate it with our other applications," says Lynch.<br><br>
-  At the same time, Squarespace’s Network Engineering team was modernizing its networking stack, switching from a traditional layer-two network to a layer-three spine-and-leaf network. "It mapped beautifully with what we wanted to do with Kubernetes," says Lynch. "It gives us the ability to have our servers communicate directly with the top-of-rack switches. We use Calico for <a href="https://github.com/containernetworking/cni">CNI networking for Kubernetes</a>, so we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs."
+{{< case-studies/quote author="Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace" >}}
+<iframe width="560" height="315" src="https://www.youtube.com/embed/feQkzJkW-SA" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<br>
+"Once you prove that Kubernetes solves one problem, everyone immediately starts solving other problems without you even having to evangelize it."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/squarespace/banner3.jpg')">
-  <div class="banner3text">
-    After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
+{{< case-studies/lead >}}
+Since it was started in a dorm room in 2003, Squarespace has made it simple for millions of people to create their own websites.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">fluentd</a> to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."
-<br><br>
-  And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that’s not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there’s some business delay in there as well."
-<br><br>
-  With faster deployments, "productivity time is the big cost saver," says Lynch. "We had a team that was implementing a new file storage service, and they just started integrating that with our storage back end without our involvement"—which wouldn’t have been possible before Kubernetes. He adds: "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on."
+<p>Behind the scenes, though, the company's monolithic Java application was making things not so simple for its developers to keep improving the platform. So in 2014, the company decided to "go down the microservices path," says Kevin Lynch, staff engineer on Squarespace's Site Reliability team. "But we were always deploying our applications in vCenter VMware VMs [in our own data centers]. Microservices solved a problem on the development side, but it pushed that problem to the Infrastructure team. The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."</p>
 
+<p>After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." Deploying it in the data center rather than the public cloud was their biggest challenge, and at the time, not a lot of other companies were doing that. "We had to figure out how to deploy this in our infrastructure for ourselves, and we had to integrate it with our other applications," says Lynch.</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/squarespace/banner4.jpg')">
-  <div class="banner4text">
-  "We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
-  </div>
-</div>
+<p>At the same time, Squarespace's Network Engineering team was modernizing its networking stack, switching from a traditional layer-two network to a layer-three spine-and-leaf network. "It mapped beautifully with what we wanted to do with Kubernetes," says Lynch. "It gives us the ability to have our servers communicate directly with the top-of-rack switches. We use Calico for <a href="https://github.com/containernetworking/cni">CNI networking for Kubernetes</a>, so we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  There’s also been a positive impact on the application’s resilience. "When we’re deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it’s rescheduled immediately and there’s no performance impact."
-<br><br>
-  Another big benefit is autoscaling. "It wasn’t really possible with the way we’ve been using VMware," says Lynch, "but now we can just add the appropriate autoscaling features via Kubernetes directly, and boom, it’s scaling up as demand increases. And it worked out of the box."
-<br><br>
-  For others starting out with Kubernetes, Lynch says his best advice is to "fail fast": "Once you’ve planned things out, just execute. Kubernetes has been really great for trying something out quickly and seeing if it works or not."
+{{< case-studies/quote image="/images/case-studies/squarespace/banner3.jpg" >}}
+After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
+{{< /case-studies/quote >}}
 
+<p>Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects <a href="https://prometheus.io/">Prometheus</a> and <a href="https://www.fluentd.org/">fluentd</a> to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."</p>
 
-</div>
+<p>And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that's not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there's some business delay in there as well."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "When we’re deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it’s rescheduled immediately and there’s no performance impact."
-  </div>
-</div>
+<p>With faster deployments, "productivity time is the big cost saver," says Lynch. "We had a team that was implementing a new file storage service, and they just started integrating that with our storage back end without our involvement"—which wouldn't have been possible before Kubernetes. He adds: "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on."</p>
 
-<div class="fullcol">
-  Lynch and his team are planning to open source some of the tools they’ve developed to extend Kubernetes and use it as an API itself. The first tool injects dependent applications as containers in a pod. "When you ship an application, usually it comes along with a whole bunch of dependent applications that need to be shipped with that, for example, fluentd for logging," he explains. With this tool, the developer doesn’t need to worry about the configurations.
-<br><br>
-  Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can. About a quarter of existing services have been migrated. "Our monolithic application is going to be the last one, just because it’s so big and complex," says Lynch. "But now I’m seeing other services get moved over, like the file storage service. Someone just did it and it worked—painlessly. So I believe if we tackle it, it’s probably going to be a lot easier than we fear. Maybe I should just take my own advice and fail fast!"
+{{< case-studies/quote image="/images/case-studies/squarespace/banner4.jpg" >}}
+"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
+{{< /case-studies/quote >}}
 
-</div>
+<p>There's also been a positive impact on the application's resilience. "When we're deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it's rescheduled immediately and there's no performance impact."</p>
 
-</section>
+<p>Another big benefit is autoscaling. "It wasn't really possible with the way we've been using VMware," says Lynch, "but now we can just add the appropriate autoscaling features via Kubernetes directly, and boom, it's scaling up as demand increases. And it worked out of the box."</p>
+
+<p>For others starting out with Kubernetes, Lynch says his best advice is to "fail fast": "Once you've planned things out, just execute. Kubernetes has been really great for trying something out quickly and seeing if it works or not."</p>
+
+{{< case-studies/quote >}}
+"When we're deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it's rescheduled immediately and there's no performance impact."
+{{< /case-studies/quote >}}
+
+<p>Lynch and his team are planning to open source some of the tools they've developed to extend Kubernetes and use it as an API itself. The first tool injects dependent applications as containers in a pod. "When you ship an application, usually it comes along with a whole bunch of dependent applications that need to be shipped with that, for example, fluentd for logging," he explains. With this tool, the developer doesn't need to worry about the configurations.</p>
+
+<p>Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can. About a quarter of existing services have been migrated. "Our monolithic application is going to be the last one, just because it's so big and complex," says Lynch. "But now I'm seeing other services get moved over, like the file storage service. Someone just did it and it worked—painlessly. So I believe if we tackle it, it's probably going to be a lot easier than we fear. Maybe I should just take my own advice and fail fast!"</p>
diff --git a/content/ko/case-studies/wikimedia/index.html b/content/ko/case-studies/wikimedia/index.html
index abc74e3ee3..b10002af83 100644
--- a/content/ko/case-studies/wikimedia/index.html
+++ b/content/ko/case-studies/wikimedia/index.html
@@ -1,96 +1,66 @@
 ---
 title: Wikimedia Case Study
-
-class: gridPage
+case_study_styles: true
 cid: caseStudies
+
+new_case_study_styles: true
+heading_title_text: Wikimedia
+use_gradient_overlay: true
+subheading: >
+  Using Kubernetes to Build Tools to Improve the World's Wikis
+case_study_details:
+  - Company: Wikimedia
+  - Location: San Francisco, CA
 ---
 
-<section id="hero" class="light-text">
-    <h1> Wikimedia Case Study</h1>
-</section>
+<p>The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.</p>
 
-<section id="mainContent">
-    <main>
-        <div class="content">
-            <h3 id="caseStudyTitle">Using Kubernetes to Build Tools to Improve the World's Wikis</h3>
-            <p>
-                The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.
-            </p>
-            <div class="feature">
-                <img src="/images/wikimedia_logo.png" alt="Wikimedia">
-                <p class="quote">
-                    "Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better."
-                </p>
-                <p class="attrib">— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs</p>
-            </div>
-        </div>
-    </main>
-</section>
+{{< case-studies/quote author="Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs">}}
+<img src="/images/wikimedia_logo.png" alt="Wikimedia">
+<br>
+<br>
+"Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better."
+{{< /case-studies/quote >}}
 
-<section class="bullets">
-    <main>
-        <div class="content">
-            <div class="bullet">
-                <h4>Challenges:</h4>
-                <ul>
-                    <li>Simplify a complex, difficult-to-manage infrastructure</li>
-                    <li>Allow developers to continue writing tools and bots using existing techniques</li>
-                </ul>
-            </div>
-            <div class="bullet">
-                <h4>Why Kubernetes:</h4>
-                <ul>
-                    <li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
-                </ul>
-            </div>
-            <div class="bullet">
-                <h4>Approach:</h4>
-                <ul>
-                    <li>Migrate old systems and a complex infrastructure to Kubernetes</li>
-                </ul>
-            </div>
-            <div class="bullet">
-                <h4>Results:</h4>
-                <ul>
-                    <li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
-                    <li>A 25-node cluster that keeps up with each new Kubernetes release</li>
-                    <li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
-                </ul>
-            </div>
-        </div>
-    </main>
-</section>
+<h2>Challenges</h2>
 
-<section class="details">
-    <main>
-        <div class="content">
-            <h4>Using Kubernetes to provide tools for maintaining wikis</h4>
-            <p>
-                Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It's incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."
-            </p>
-            <p>
-                To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.
-            </p>
-            <p>
-                "With Kubernetes, I've been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users' code also runs in a more stable way than previously," says Yuvi.
-            </p>
-        </div>
-    </main>
-</section>
+<ul>
+  <li>Simplify a complex, difficult-to-manage infrastructure</li>
+  <li>Allow developers to continue writing tools and bots using existing techniques</li>
+</ul>
 
-<section class="details">
-    <main>
-        <div class="content">
-            <h4>Simplifying infrastructure and keeping wikis running better</h4>
-            <p>
-                Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don't have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.
-            </p>
-            <p>
-                In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs' web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.
-            </p>
-            <p>
-                "Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.
-            </p>
-        </div>
-    </main>
-</section>
+<h2>Why Kubernetes</h2>
+
+<ul>
+  <li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
+</ul>
+
+<h2>Approach</h2>
+
+<ul>
+  <li>Migrate old systems and a complex infrastructure to Kubernetes</li>
+</ul>
+
+<h2>Results</h2>
+
+<ul>
+  <li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
+  <li>A 25-node cluster that keeps up with each new Kubernetes release</li>
+  <li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
+</ul>
+
+<h2>Using Kubernetes to provide tools for maintaining wikis</h2>
+
+<p>Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It's incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."</p>
+
+<p>To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.</p>
+
+<p>"With Kubernetes, I've been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users' code also runs in a more stable way than previously," says Yuvi.</p>
+
+<h2>Simplifying infrastructure and keeping wikis running better</h2>
+
+<p>Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don't have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.</p>
+
+<p>In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs' web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.</p>
+
+<p>"Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.</p>
diff --git a/content/ko/case-studies/wink/index.html b/content/ko/case-studies/wink/index.html
index 3f47f8c779..1f8ea4c89d 100644
--- a/content/ko/case-studies/wink/index.html
+++ b/content/ko/case-studies/wink/index.html
@@ -1,109 +1,87 @@
 ---
 title: Wink Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_wink.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/wink/banner1.jpg
+heading_title_logo: /images/wink_logo.png
+subheading: >
+  Cloud-Native Infrastructure Keeps Your Smart Home Connected
+case_study_details:
+  - Company: Wink
+  - Location: New York, N.Y.
+  - Industry: Internet of Things Platform
 ---
 
-<div class="banner1">
-  <h1>CASE STUDY: <img src="/images/wink_logo.png" width="13%" style="margin-bottom:-4px"><br>
-    <div class="subhead">Cloud-Native Infrastructure Keeps Your Smart Home Connected</div>
-  </h1>
-</div>
+<h2>Challenge</h2>
 
+<p>Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company's consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.</p>
 
-<div class="details">
-    Company &nbsp;<b>Wink</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>New York, N.Y.</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Internet of Things Platform</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
+<p>Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.</p>
 
-<section class="section1">
-<div class="cols">
-  <div class="col1">
+<h2>Impact</h2>
 
-      <h2>Challenge</h2>
-        Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company’s consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.
-        <br><br>
-      <h2>Solution</h2>
-        Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.<br><br>
-  </div>
+<p>"Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware," Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink's workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively easy."</p>
 
-  <div class="col2">
-    <h2>Impact</h2>
-      "Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware,” Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink’s workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively&nbsp;easy.”
-  </div>
+{{< case-studies/quote author="KIT KLEIN, HEAD OF ENGINEERING, WINK" >}}
+"It's not proprietary, it's totally open, it's really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That's the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
+{{< case-studies/lead >}}
+How many people does it take to turn on a light bulb?
+{{< /case-studies/lead >}}
 
+<p>Kit Klein whips out his phone to demonstrate. With a few swipes, the head of engineering at Wink pulls up the smart-home app created by the New York City-based company and taps the light button. "Honestly when you're holding the phone and you're hitting the light," he says, "by the time you feel the pressure of your finger on the screen, it's on. It takes as long as the signal to travel to your brain."</p>
 
-<div class="banner2">
-  <div class="banner2text">
-      "It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><span style="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
-  </div>
-</div>
+<p>Sure, it takes just one finger and less than 200 milliseconds to turn on the light – or lock a door or change a thermostat. But what allows Wink to help consumers manage their connected smart-home products with such speed and ease is a sophisticated, cloud native infrastructure that Klein and his team built and continue to develop using a unified stack of CoreOS, the open-source operating system designed for clustered deployments, and Kubernetes, an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. "When you have a big, complex network of interdependent microservices that need to be able to discover each other, and need to be horizontally scalable and tolerant to failure, that's what this is really optimized for," says Klein. "A lot of people end up relying on proprietary services [offered by some big cloud providers] to do some of this stuff, but what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate."</p>
 
+<p>Indeed, Wink did. The company's mission statement is to make the connected home accessible – that is, user-friendly for non-technical owners, affordable and perhaps most importantly, reliable. "If you can't trust that when you hit the switch, you know a light is going to go on, or if you're remote and you're checking on your house and that information isn't accurate, then the convenience of the system is lost," says Klein. "So that's where the infrastructure comes in."</p>
 
-<section class="section2">
-  <div class="fullcol">
-      <h2>How many people does it take to turn on a light bulb?</h2>
+<p>Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.</p>
 
-      Kit Klein whips out his phone to demonstrate. With a few swipes, the head of engineering at Wink pulls up the smart-home app created by the New York City-based company and taps the light button. "Honestly when you’re holding the phone and you’re hitting the light,” he says, "by the time you feel the pressure of your finger on the screen, it’s on. It takes as long as the signal to travel to your brain.”<br><br>
-      Sure, it takes just one finger and less than 200 milliseconds to turn on the light – or lock a door or change a thermostat. But what allows Wink to help consumers manage their connected smart-home products with such speed and ease is a sophisticated, cloud native infrastructure that Klein and his team built and continue to develop using a unified stack of CoreOS, the open-source operating system designed for clustered deployments, and Kubernetes, an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. "When you have a big, complex network of interdependent microservices that need to be able to discover each other, and need to be horizontally scalable and tolerant to failure, that’s what this is really optimized for,” says Klein. "A lot of people end up relying on proprietary services [offered by some big cloud providers] to do some of this stuff, but what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate.”<br><br>
-      Indeed, Wink did. The company’s mission statement is to make the connected home accessible – that is, user-friendly for non-technical owners, affordable and perhaps most importantly, reliable. "If you can’t trust that when you hit the switch, you know a light is going to go on, or if you’re remote and you’re checking on your house and that information isn’t accurate, then the convenience of the system is lost,” says Klein. "So that’s where the infrastructure comes in.”<br><br>
-      Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.<br><br>
-      "When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product,” says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it.”
+<p>"When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product," says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it."</p>
 
-  </div>
-</section>
+{{< case-studies/quote image="/images/case-studies/wink/banner3.jpg">}}
+"...what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate."
+{{< /case-studies/quote >}}
 
-<div class="banner3">
-  <div class="banner3text">
-    "...what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate.”
-  </div>
-</div>
+<p>Concern number one: Wink's products need to connect to consumer devices in people's homes, behind a firewall. "You don't have an end point like a URL, and you don't even know what ports are open behind that firewall," Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it's really, really important that it's persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights."</p>
 
-<section class="section3">
-  <div class="fullcol">
-    Concern number one: Wink’s products need to connect to consumer devices in people’s homes, behind a firewall. "You don’t have an end point like a URL, and you don’t even know what ports are open behind that firewall,” Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights.”<br><br>
-    With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink’s software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.
-    <br><br>
-    <h2>"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent...you never know when someone is going to turn on the&nbsp;lights.”</h2>
-    In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service,” says Klein. "We’ve always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker.”<br><br>
-    At the time – just over two years ago – Docker wasn’t yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn’t really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads.”<br><br>
-    Once Wink’s backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can’t just start the containers and hope everything goes well,” Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure.”
+<p>With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink's software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.</p>
 
-  </div>
-</section>
+{{< case-studies/lead >}}
+"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it's really, really important that it's persistent...you never know when someone is going to turn on the lights."
+{{< /case-studies/lead >}}
 
-  <div class="banner4">
-    <div class="banner4text">
-    "Obviously you can’t just start the containers and hope everything goes well,” Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure.”
-    </div>
-  </div>
+<p>In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service," says Klein. "We've always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker."</p>
 
-<section class="section4">
-  <div class="fullcol">
-    Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed,” he says. "We didn’t have to futz around with trying to take something like a Linux distro and install everything. It’s got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It’s not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed.”<br><br>
-    Wink’s hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they’ve moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters. <br><br>
-    Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn’t take care of routing, sharing configurations, secrets, et cetera, among instances of a service,” Klein says. "All of those layers of functionality can be implemented, of course, but if you don’t want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did.”<br><br>
-    Wink quickly embraced the Kubernetes container cluster manager when it was launched in 2015 and integrated with CoreOS core technology, and as promised, it ended up providing the features Wink wanted and had planned to build. "If not for Kubernetes, we likely would have taken the logic and library we implemented for the automation tool that we created, and would have used it in a higher level abstraction and tool that could be used by non-DevOps engineers from the command line to create and manage clusters,” Klein says. "But Kubernetes made that totally unnecessary – and is written and maintained by people with a lot more experience in cluster management than us, so all the better.” Now, an estimated 80 percent of Wink’s workload is run on Kubernetes on top of CoreOS Container Linux.
+<p>At the time – just over two years ago – Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."</p>
 
-  </div>
-</section>
+<p>Once Wink's backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."</p>
 
-  <div class="banner5">
-    <div class="banner5text">
-      "Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”
-    </div>
-  </div>
+{{< case-studies/quote image="/images/case-studies/wink/banner4.jpg" >}}
+"Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."
+{{< /case-studies/quote >}}
 
-<section class="section5">
-  <div class="fullcol">
-    Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
-    Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people,” he says. "In order to take advantage of this, you really have to keep up with the technology. You can’t treat it like it’s a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”<br><br>
-    Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What’s next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware,” Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has have built.<br><br>
-    Wink’s engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs,” he says. "It’s like data pipelines as microservices.” Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You’re not reinventing the wheel every time,” he says. "You can just get down to work.”  </div>
-</section>
+<p>Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed," he says. "We didn't have to futz around with trying to take something like a Linux distro and install everything. It's got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It's not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed."</p>
+
+<p>Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.</p>
+
+<p>Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn't take care of routing, sharing configurations, secrets, et cetera, among instances of a service," Klein says. "All of those layers of functionality can be implemented, of course, but if you don't want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did."</p>
+
+<p>Wink quickly embraced the Kubernetes container cluster manager when it was launched in 2015 and integrated with CoreOS core technology, and as promised, it ended up providing the features Wink wanted and had planned to build. "If not for Kubernetes, we likely would have taken the logic and library we implemented for the automation tool that we created, and would have used it in a higher level abstraction and tool that could be used by non-DevOps engineers from the command line to create and manage clusters," Klein says. "But Kubernetes made that totally unnecessary – and is written and maintained by people with a lot more experience in cluster management than us, so all the better." Now, an estimated 80 percent of Wink's workload is run on Kubernetes on top of CoreOS Container Linux.</p>
+
+{{< case-studies/quote >}}
+"Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it."
+{{< /case-studies/quote >}}
+
+<p>Wink's reasons for going all in are clear: "It's not proprietary, it's totally open, it's really portable," Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That's the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time."</p>
+
+<p>Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people," he says. "In order to take advantage of this, you really have to keep up with the technology. You can't treat it like it's a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it."</p>
+
+<p>Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What's next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware," Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has have built.</p>
+
+<p>Wink's engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs," he says. "It's like data pipelines as microservices." Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You're not reinventing the wheel every time," he says. "You can just get down to work."</p>
diff --git a/content/ko/case-studies/workiva/index.html b/content/ko/case-studies/workiva/index.html
index 1c09503bfb..d8945bfd34 100644
--- a/content/ko/case-studies/workiva/index.html
+++ b/content/ko/case-studies/workiva/index.html
@@ -3,111 +3,91 @@ title: Workiva Case Study
 linkTitle: Workiva
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 draft: true
 featured: true
 weight: 20
 quote: >
   With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/workiva/banner1.jpg
+heading_title_logo: /images/workiva_logo.png
+subheading: >
+  Using OpenTracing to Help Pinpoint the Bottlenecks
+case_study_details:
+  - Company: Workiva
+  - Location: Ames, Iowa
+  - Industry: Enterprise Software
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/workiva/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/workiva_logo.png" style="margin-bottom:0%" class="header_logo"><br> <div class="subhead">Using OpenTracing to Help Pinpoint the Bottlenecks
+<h2>Challenge</h2>
 
-</div></h1>
+<p><a href="https://www.workiva.com/">Workiva</a> offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company's first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva's existing system, Broad's team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn't impact overall speed.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Workiva</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Ames, Iowa</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Enterprise Software</b>
-</div>
+<p>Broad's team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    <a href="https://www.workiva.com/">Workiva</a> offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed.
-
-<br>
-
-</div>
-
-<div class="col2">
- <h2>Solution</h2>
-    Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.
-<br>
 <h2>Impact</h2>
-  Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
 
-</div>
+<p>Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-"With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MacLeod Broad, Senior Software Architect at Workiva</span>
+{{< case-studies/quote author="MacLeod Broad, Senior Software Architect at Workiva" >}}
+"With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code."
+{{< /case-studies/quote >}}
 
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Last fall, MacLeod Broad’s platform team at Workiva was prepping one of the company’s first products utilizing <a href="https://aws.amazon.com/">Amazon Web Services</a> when they ran into a roadblock.</h2>
-  Early on, Workiva’s backend had run mostly on <a href="https://cloud.google.com/appengine/">Google App Engine</a>. But things changed along the way as Workiva’s SaaS offering, <a href="https://www.workiva.com/wdesk">Wdesk</a>, a cloud-based platform for managing and reporting business data, grew its customer base to more than 70 percent of the Fortune 500 companies. "As customer needs grew and the product offering expanded, we started to leverage a wider offering of services such as Amazon Web Services as well as other Google Cloud Platform services, creating a multi-vendor environment."<br><br>
-With this new product, there was a "sync and link" feature by which data "went through a whole host of services starting with the new spreadsheet system [<a href="https://aws.amazon.com/rds/aurora/">Amazon Aurora</a>] into what we called our linking system, and then pushed through http to our existing system, and then a number of calculations would go on, and the results would be transmitted back into the new system," says Broad. "We were trying to optimize that for speed. We thought we had made this great optimization and then it would turn out to be a micro optimization, which didn’t really affect the overall speed of things." <br><br>
-The challenges faced by Broad’s team may sound familiar to other companies that have also made the shift from monoliths to more distributed, microservice-based systems. "We had a number of people working on this, all on different teams, so it was difficult to get our head around what the issues were and where the bottlenecks were," says Broad.<br><br>
- "Each service team was going through different iterations of their architecture and it was very hard to follow what was actually going on in each teams’ system," he adds. "We had circular dependencies where we’d have three or four different service teams unsure of where the issues really were, requiring a lot of back and forth communication. So we wasted a lot of time saying, ‘What part of this is slow? Which part of this is sometimes slow depending on the use case? Which part is degrading over time? Which part of this process is asynchronous so it doesn’t really matter if it’s long-running or not? What are we doing that’s redundant, and which part of this is buggy?’"
+{{< case-studies/lead >}}
+Last fall, MacLeod Broad's platform team at Workiva was prepping one of the company's first products utilizing <a href="https://aws.amazon.com/">Amazon Web Services</a> when they ran into a roadblock.
+{{< /case-studies/lead >}}
 
+<p>Early on, Workiva's backend had run mostly on <a href="https://cloud.google.com/appengine/">Google App Engine</a>. But things changed along the way as Workiva's SaaS offering, <a href="https://www.workiva.com/wdesk">Wdesk</a>, a cloud-based platform for managing and reporting business data, grew its customer base to more than 70 percent of the Fortune 500 companies. "As customer needs grew and the product offering expanded, we started to leverage a wider offering of services such as Amazon Web Services as well as other Google Cloud Platform services, creating a multi-vendor environment."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/workiva/banner3.jpg')">
-  <div class="banner3text">
-    "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>With this new product, there was a "sync and link" feature by which data "went through a whole host of services starting with the new spreadsheet system [<a href="https://aws.amazon.com/rds/aurora/">Amazon Aurora</a>] into what we called our linking system, and then pushed through http to our existing system, and then a number of calculations would go on, and the results would be transmitted back into the new system," says Broad. "We were trying to optimize that for speed. We thought we had made this great optimization and then it would turn out to be a micro optimization, which didn't really affect the overall speed of things."</p>
 
-Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."<br><br>
-With Workiva’s back-end code running on <a href="https://cloud.google.com/compute/">Google Compute Engine</a> as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."<br><br>
-Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"<br><br>
-Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it’s doing a SQL call or it’s making an RPC. And so it was really easy to say, ‘OK, we know that it’s going to page through all these requests. Do the work once and stuff it in cache.’ And we were done basically. All those calls became sub-second calls immediately."<br><br>
+<p>The challenges faced by Broad's team may sound familiar to other companies that have also made the shift from monoliths to more distributed, microservice-based systems. "We had a number of people working on this, all on different teams, so it was difficult to get our head around what the issues were and where the bottlenecks were," says Broad.</p>
 
+<p>"Each service team was going through different iterations of their architecture and it was very hard to follow what was actually going on in each teams' system," he adds. "We had circular dependencies where we'd have three or four different service teams unsure of where the issues really were, requiring a lot of back and forth communication. So we wasted a lot of time saying, 'What part of this is slow? Which part of this is sometimes slow depending on the use case? Which part is degrading over time? Which part of this process is asynchronous so it doesn't really matter if it's long-running or not? What are we doing that's redundant, and which part of this is buggy?'"</p>
 
+{{< case-studies/quote
+  image="/images/case-studies/workiva/banner3.jpg"
+  author="MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA"
+>}}
+"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it's a lot faster than never figuring out the problem and just moving on."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/workiva/banner4.jpg')">
-  <div class="banner4text">
-"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to&nbsp;use." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA</span>
-  </div>
-</div>
+<p>Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it's a lot faster than never figuring out the problem and just moving on."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  After the success of the first use case, everyone involved in the trial went back and fully instrumented their products. Tracing was added to a few more use cases. "We wanted to get through the initial implementation pains early without bringing the whole department along for the ride," says Broad. "Now, a lot of teams add it when they’re starting up a new service. We’re really pushing adoption now more than we were before." <br><br>
-Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." <br><br>
-Most of Workiva’s major products are now traced using OpenTracing, with data pushed into <a href="https://cloud.google.com/stackdriver/">Google StackDriver</a>. Even the products that aren’t fully traced have some components and libraries that are. <br><br>
-Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."<br><br>
-But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing."
-In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."
+<p>With Workiva's back-end code running on <a href="https://cloud.google.com/compute/">Google Compute Engine</a> as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn't want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."</p>
 
+<p>Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva's existing code that was slowing things down, that wasn't exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, 'Why is it doing all this work again?'"</p>
 
-</div>
+<p>Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it's doing a SQL call or it's making an RPC. And so it was really easy to say, 'OK, we know that it's going to page through all these requests. Do the work once and stuff it in cache.' And we were done basically. All those calls became sub-second calls immediately."</p>
 
-<div class="banner5">
-  <div class="banner5text">
-   "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in&nbsp;a&nbsp;single&nbsp;fix." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase"><br>— Michael Davis, Software Engineer, Workiva </span>
-  </div>
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/workiva/banner4.jpg"
+  author="MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA"
+>}}
+"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn't want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
- For Workiva, OpenTracing has become an essential tool for zeroing in on optimizations and determining what’s actually a micro-optimization by observing usage patterns. "On some projects we often assume what the customer is doing, and we optimize for these crazy scale cases that we hit 1 percent of the time," says Broad. "It’s been really helpful to be able to say, ‘OK, we’re adding 100 milliseconds on every request that does X, and we only need to add that 100 milliseconds if it’s the worst of the worst case, which only happens one out of a thousand requests or one out of a million requests."<br><br>
-Unlike many other companies, Workiva also traces the client side. "For us, the user experience is important—it doesn’t matter if the RPC takes 100 milliseconds if it still takes 5 seconds to do the rendering to show it in the browser," says Broad. "So for us, those client times are important. We trace it to see what parts of loading take a long time. We’re in the middle of working on a definition of what is ‘loaded.’ Is it when you have it, or when it’s rendered, or when you can interact with it? Those are things we’re planning to use tracing for to keep an eye on and to better understand."<br><br>
-That also requires adjusting for differences in external and internal clocks. "Before time correcting, it was horrible; our traces were more misleading than anything," says Broad. "So we decided that we would return a timestamp on the response headers, and then have the client reorient its time based on that—not change its internal clock but just calculate the offset on the response time to when the client got it. And if you end up in an impossible situation where a client RPC spans 210 milliseconds but the time on the response time is outside of that window, then we have to reorient that."<br><br>
-Broad is excited about the impact OpenTracing has already had on the company, and is also looking ahead to what else the technology can enable. One possibility is using tracing to update documentation in real time. "Keeping documentation up to date with reality is a big challenge," he says. "Say, we just ran a trace simulation or we just ran a smoke test on this new deploy, and the architecture doesn’t match the documentation. We can find whose responsibility it is and let them know and have them update it. That’s one of the places I’d like to get in the future with tracing."
+<p>After the success of the first use case, everyone involved in the trial went back and fully instrumented their products. Tracing was added to a few more use cases. "We wanted to get through the initial implementation pains early without bringing the whole department along for the ride," says Broad. "Now, a lot of teams add it when they're starting up a new service. We're really pushing adoption now more than we were before."</p>
 
-</div>
+<p>Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."</p>
 
-</section>
+<p>Most of Workiva's major products are now traced using OpenTracing, with data pushed into <a href="https://cloud.google.com/stackdriver/">Google StackDriver</a>. Even the products that aren't fully traced have some components and libraries that are.</p>
+
+<p>Broad points out that because some of the engineers were working on App Engine and already had experience with the platform's Appstats library for profiling performance, it didn't take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they're working on. Questions about passing the context around and how that's done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they'd used other systems that didn't require that."But the benefits clearly outweighed the concerns, and today, Workiva's official policy is to use tracing."</p>
+
+<p>In fact, Broad believes that tracing naturally fits in with Workiva's existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it's being created and when it's being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."</p>
+
+{{< case-studies/quote author="Michael Davis, Software Engineer, Workiva" >}}
+"Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
+{{< /case-studies/quote >}}
+
+<p>For Workiva, OpenTracing has become an essential tool for zeroing in on optimizations and determining what's actually a micro-optimization by observing usage patterns. "On some projects we often assume what the customer is doing, and we optimize for these crazy scale cases that we hit 1 percent of the time," says Broad. "It's been really helpful to be able to say, 'OK, we're adding 100 milliseconds on every request that does X, and we only need to add that 100 milliseconds if it's the worst of the worst case, which only happens one out of a thousand requests or one out of a million requests."</p>
+
+<p>Unlike many other companies, Workiva also traces the client side. "For us, the user experience is important—it doesn't matter if the RPC takes 100 milliseconds if it still takes 5 seconds to do the rendering to show it in the browser," says Broad. "So for us, those client times are important. We trace it to see what parts of loading take a long time. We're in the middle of working on a definition of what is 'loaded.' Is it when you have it, or when it's rendered, or when you can interact with it? Those are things we're planning to use tracing for to keep an eye on and to better understand."</p>
+
+<p>That also requires adjusting for differences in external and internal clocks. "Before time correcting, it was horrible; our traces were more misleading than anything," says Broad. "So we decided that we would return a timestamp on the response headers, and then have the client reorient its time based on that—not change its internal clock but just calculate the offset on the response time to when the client got it. And if you end up in an impossible situation where a client RPC spans 210 milliseconds but the time on the response time is outside of that window, then we have to reorient that."</p>
+
+<p>Broad is excited about the impact OpenTracing has already had on the company, and is also looking ahead to what else the technology can enable. One possibility is using tracing to update documentation in real time. "Keeping documentation up to date with reality is a big challenge," he says. "Say, we just ran a trace simulation or we just ran a smoke test on this new deploy, and the architecture doesn't match the documentation. We can find whose responsibility it is and let them know and have them update it. That's one of the places I'd like to get in the future with tracing."</p>
diff --git a/content/ko/case-studies/ygrene/index.html b/content/ko/case-studies/ygrene/index.html
index c07443249a..9afc1ec45b 100644
--- a/content/ko/case-studies/ygrene/index.html
+++ b/content/ko/case-studies/ygrene/index.html
@@ -1,111 +1,82 @@
 ---
 title: Ygrene Case Study
-
 linkTitle: Ygrene
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
 logo: ygrene_featured_logo.png
 featured: true
 weight: 48
 quote: >
-  We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company.
+  We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ygrene/banner1.jpg
+heading_title_logo: /images/ygrene_logo.png
+subheading: >
+  Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry
+case_study_details:
+  - Company: Ygrene
+  - Location: Petaluma, Calif.
+  - Industry: Clean energy financing
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/case-studies/ygrene/banner1.jpg')">
-  <h1> CASE STUDY:<img src="/images/ygrene_logo.png" style="margin-bottom:-1%" class="header_logo"><br> <div class="subhead">Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry
+<h2>Challenge</h2>
 
-</div></h1>
+<p>A PACE (Property Assessed Clean Energy) financing company, Ygrene has funded more than $1 billion in loans since 2010. In order to approve and process those loans, "We have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data," says Ygrene Development Manager Austin Adams. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically. We had a really unstable system that became overwhelmed with requests just for doing background data processing in real time. The performance the users saw was very poor. We needed a solution that wouldn't require us to make huge refactors to the code base." As a finance company, Ygrene also needed to ensure that they were shipping their applications securely.</p>
 
-</div>
+<h2>Solution</h2>
 
-<div class="details">
-    Company &nbsp;<b>Ygrene</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Petaluma, Calif.</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Clean energy financing</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    A PACE (Property Assessed Clean Energy) financing company, Ygrene has funded more than $1 billion in loans since 2010. In order to approve and process those loans, "We have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data," says Ygrene Development Manager Austin Adams. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically. We had a really unstable system that became overwhelmed with requests just for doing background data processing in real time. The performance the users saw was very poor. We needed a solution that wouldn’t require us to make huge refactors to the code base." As a finance company, Ygrene also needed to ensure that they were shipping their applications securely.
-
-<br>
-
- <h2>Solution</h2>
-    Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: <a href="https://kubernetes.io/">Kubernetes</a> to help scale out vertically and distribute workloads, <a href="https://github.com/theupdateframework/notary">Notary</a> to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and <a href="https://www.fluentd.org/">Fluentd</a> for "observing every part of our stack," all running on <a href="https://aws.amazon.com/ec2/spot/">Amazon EC2 Spot</a>.
-
-</div>
-
-<div class="col2">
+<p>Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: <a href="https://kubernetes.io/">Kubernetes</a> to help scale out vertically and distribute workloads, <a href="https://github.com/theupdateframework/notary">Notary</a> to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and <a href="https://www.fluentd.org/">Fluentd</a> for "observing every part of our stack," all running on <a href="https://aws.amazon.com/ec2/spot/">Amazon EC2 Spot</a>.</p>
 
 <h2>Impact</h2>
-  Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on."
 
+<p>Before, deployments typically took three to four hours, and two or three months' worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we're able to deploy three or four times a week, with just one week's or two days' worth of work," Adams says. "We're deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we're adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn't tell our investors and team members that we knew what was going on."</p>
 
-</div>
+{{< case-studies/quote author="Austin Adams, Development Manager, Ygrene Energy Fund" >}}
+"CNCF projects are helping Ygrene determine the security and observability standards for the entire PACE industry. We're an emerging finance industry, and without these projects, especially Kubernetes, we couldn't be the industry leader that we are today."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-"CNCF projects are helping Ygrene determine the security and observability standards for the entire PACE industry. We’re an emerging finance industry, and without these projects, especially Kubernetes, we couldn’t be the industry leader that we are today." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Austin Adams, Development Manager, Ygrene Energy Fund</span>
+{{< case-studies/lead >}}
+In less than a decade, <a href="https://ygrene.com/">Ygrene</a> has funded more than $1 billion in loans for renewable energy projects.
+{{< /case-studies/lead >}}
 
-  </div>
-</div>
+<p>A <a href="https://www.energy.gov/eere/slsc/property-assessed-clean-energy-programs">PACE</a> (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams.</p>
 
-<div class="fullcol">
- <h2>In less than a decade, <a href="https://ygrene.com/" style="text-decoration:underline">Ygrene</a> has funded more than $1 billion in loans for renewable energy&nbsp;projects.</h2> A <a href="https://www.energy.gov/eere/slsc/property-assessed-clean-energy-programs">PACE</a> (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams. <br><br>
-In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time." <br><br>
-By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn’t solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn’t handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."
+<p>In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time."</p>
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/ygrene/banner3.jpg')">
-  <div class="banner3text">
-    "CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Austin Adams, Development Manager, Ygrene Energy Fund</span>
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
+<p>By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn't solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn't handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."</p>
 
-Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn’t require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams. <br><br>
-With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."<br><br>
-How? Cloud native has "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on." <br><br>
-Notary, in particular, "has been a godsend," says Adams. "We need to know that our attack surface on third-party dependencies is low, or at least managed. We use it as a trust system and we also use it as a separation, so production images are signed by Notary, but some development images we don’t sign. That is to ensure that they can’t get into the production cluster. We’ve been using it in the test cluster to feel more secure about our builds."
+{{< case-studies/quote
+  image="/images/case-studies/ygrene/banner3.jpg"
+  author="Austin Adams, Development Manager, Ygrene Energy Fund"
+>}}
+"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It's actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
+{{< /case-studies/quote >}}
 
+<p>Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn't require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams.</p>
 
+<p>With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company."</p>
 
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/ygrene/banner4.jpg')">
-  <div class="banner4text">
-"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."</span>
-  </div>
-</div>
+<p>How? Cloud native has "changed the game for scalability, observability, and security—we're adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn't tell our investors and team members that we knew what was going on."</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
- By using the kops project, Ygrene was able to move from Elastic Beanstalk to running its Kubernetes clusters on AWS EC2 Spot, at a tenth of the previous cost. "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."<br><br>
-That also helped them mitigate the risk that comes with running in the public cloud. "We figured out, essentially, that if we’re able to select instance classes using EC2 Spot that had an extremely low likelihood of interruption and zero history of interruption, and we’re willing to pay a price high enough, that we could virtually get the same guarantee using Kubernetes because we have enough nodes," says Software Engineer Zach Arnold, who led the migration to Kubernetes. "Now that we’ve re-architected these pieces of the application to not live on the same server, we can push out to many different servers and have a more stable deployment."<br><br>
-As a result, the team can now ship code any time of day. "That was risky because it could bring down your whole loan management software with it," says Arnold. "But we now can deploy safely and securely during the day."
+<p>Notary, in particular, "has been a godsend," says Adams. "We need to know that our attack surface on third-party dependencies is low, or at least managed. We use it as a trust system and we also use it as a separation, so production images are signed by Notary, but some development images we don't sign. That is to ensure that they can't get into the production cluster. We've been using it in the test cluster to feel more secure about our builds."</p>
 
+{{< case-studies/quote image="/images/case-studies/ygrene/banner4.jpg">}}
+"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company."
+{{< /case-studies/quote >}}
 
-</div>
+<p>By using the kops project, Ygrene was able to move from Elastic Beanstalk to running its Kubernetes clusters on AWS EC2 Spot, at a tenth of the previous cost. "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."</p>
 
-<div class="banner5">
-  <div class="banner5text">
- "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."</span>
-  </div>
-</div>
+<p>That also helped them mitigate the risk that comes with running in the public cloud. "We figured out, essentially, that if we're able to select instance classes using EC2 Spot that had an extremely low likelihood of interruption and zero history of interruption, and we're willing to pay a price high enough, that we could virtually get the same guarantee using Kubernetes because we have enough nodes," says Software Engineer Zach Arnold, who led the migration to Kubernetes. "Now that we've re-architected these pieces of the application to not live on the same server, we can push out to many different servers and have a more stable deployment."</p>
 
-<div class="fullcol">
- Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for an overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down for 30 minutes to an hour, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed."<br><br>
-Cloud native also affected how Ygrene’s 50+ developers and contractors work. Adams and Arnold spent considerable time "teaching people to think distributed out of the box," says Arnold. "We ended up picking what we call the Four S’s of Shipping: safely, securely, stably, and speedily." (For more on the security piece of it, see their <a href="https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/">article</a> on their "continuous hacking" strategy.) As for the engineers, says Adams, "they have been able to advance as their software has advanced. I think that at the end of the day, the developers feel better about what they’re doing, and they also feel more connected to the modern software development community."<br><br>
-Looking ahead, Adams is excited to explore more CNCF projects, including SPIFFE and SPIRE. "CNCF has been an amazing incubator for so many projects," he says. "Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
+<p>As a result, the team can now ship code any time of day. "That was risky because it could bring down your whole loan management software with it," says Arnold. "But we now can deploy safely and securely during the day."</p>
 
+{{< case-studies/quote >}}
+"In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."
+{{< /case-studies/quote >}}
 
+<p>Before, deployments typically took three to four hours, and two or three months' worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for an overall deploy with smoke testing. And "we're able to deploy three or four times a week, with just one week's or two days' worth of work," Adams says. "We're deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down for 30 minutes to an hour, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed."</p>
 
-</div>
+<p>Cloud native also affected how Ygrene's 50+ developers and contractors work. Adams and Arnold spent considerable time "teaching people to think distributed out of the box," says Arnold. "We ended up picking what we call the Four S's of Shipping: safely, securely, stably, and speedily." (For more on the security piece of it, see their <a href="https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/">article</a> on their "continuous hacking" strategy.) As for the engineers, says Adams, "they have been able to advance as their software has advanced. I think that at the end of the day, the developers feel better about what they're doing, and they also feel more connected to the modern software development community."</p>
 
-</section>
+<p>Looking ahead, Adams is excited to explore more CNCF projects, including SPIFFE and SPIRE. "CNCF has been an amazing incubator for so many projects," he says. "Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It's actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."</p>
diff --git a/content/ko/case-studies/zalando/index.html b/content/ko/case-studies/zalando/index.html
index 49bad6ff9e..23363da401 100644
--- a/content/ko/case-studies/zalando/index.html
+++ b/content/ko/case-studies/zalando/index.html
@@ -1,101 +1,83 @@
 ---
 title: Zalando Case Study
-
 case_study_styles: true
 cid: caseStudies
-css: /css/style_zalando.css
+
+new_case_study_styles: true
+heading_background: /images/case-studies/zalando/banner1.jpg
+heading_title_logo: /images/zalando_logo.png
+subheading: >
+  Europe's Leading Online Fashion Platform Gets Radical with Cloud Native
+case_study_details:
+  - Company: Zalando
+  - Location: Berlin, Germany
+  - Industry: Online Fashion
 ---
 
-<div class="banner1">
-  <h1> CASE STUDY:<img src="/images/zalando_logo.png" class="header_logo"><br> <div class="subhead">Europe’s Leading Online Fashion Platform Gets Radical with Cloud Native
-</div></h1>
+<h2>Challenge</h2>
 
-</div>
+<p>Zalando, Europe's leading online fashion platform, has experienced exponential growth since it was founded in 2008. In 2015, with plans to further expand its original e-commerce site to include new services and products, Zalando embarked on a <a href="https://jobs.zalando.com/tech/blog/radical-agility-study-notes/">radical transformation</a> resulting in autonomous self-organizing teams. This change requires an infrastructure that could scale with the growth of the engineering organization. Zalando's technology department began rewriting its applications to be cloud-ready and started moving its infrastructure from on-premise data centers to the cloud. While orchestration wasn't immediately considered, as teams migrated to <a href="https://aws.amazon.com/">Amazon Web Services</a> (AWS): "We saw the pain teams were having with infrastructure and Cloud Formation on AWS," says Henning Jacobs, Head of Developer Productivity. "There's still too much operational overhead for the teams and compliance. " To provide better support, cluster management was brought into play.</p>
 
-<div class="details">
-    Company &nbsp;<b>Zalando</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Berlin, Germany</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Online Fashion</b>
-</div>
+<h2>Solution</h2>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1">
-    <h2>Challenge</h2>
-    Zalando, Europe’s leading online fashion platform, has experienced exponential growth since it was founded in 2008. In 2015, with plans to further expand its original e-commerce site to include new services and products, Zalando embarked on a <a href="https://jobs.zalando.com/tech/blog/radical-agility-study-notes/">radical transformation</a> resulting in autonomous self-organizing teams. This change requires an infrastructure that could scale with the growth of the engineering organization. Zalando’s technology department began rewriting its applications to be cloud-ready and started moving its infrastructure from on-premise data centers to the cloud. While orchestration wasn’t immediately considered, as teams migrated to <a href="https://aws.amazon.com/">Amazon Web Services</a> (AWS): "We saw the pain teams were having with infrastructure and Cloud Formation on AWS," says Henning Jacobs, Head of Developer Productivity. "There’s still too much operational overhead for the teams and compliance. " To provide better support, cluster management was brought into play.
+<p>The company now runs its Docker containers on AWS using Kubernetes orchestration.</p>
 
-      </div>
-
-<div class="col2">
-  <h2>Solution</h2>
-      The company now runs its Docker containers on AWS using Kubernetes orchestration.
-<br>
 <h2>Impact</h2>
-      With the old infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs on the Linux kernel. This makes a lot of people pretty happy. The engineers love autonomy."
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "We envision all Zalando delivery teams running their containerized applications on a state-of-the-art, reliable and scalable cluster infrastructure provided by Kubernetes."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Henning Jacobs, Head of Developer Productivity at Zalando</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-    <h2>When Henning Jacobs arrived at Zalando in 2010, the company was just two years old with 180 employees running an online store for European shoppers to buy fashion items.</h2>
-    "It started as a PHP e-commerce site which was easy to get started with, but was not scaling with the business' needs" says Jacobs, Head of Developer Productivity at Zalando.<br><br>
-    At that time, the company began expanding beyond its German origins into other European markets. Fast-forward to today and Zalando now has more than 14,000 employees, 3.6 billion Euro in revenue for 2016 and operates across 15 countries. "With growth in all dimensions, and constant scaling, it has been a once-in-a-lifetime experience," he says.<br><br>
-    Not to mention a unique opportunity for an infrastructure specialist like Jacobs. Just after he joined, the company began rewriting all their applications in-house. "That was generally our strategy," he says. "For example, we started with our own logistics warehouses but at first you don’t know how to do logistics software, so you have some vendor software. And then we replaced it with our own because with off-the-shelf software you’re not competitive. You need to optimize these processes based on your specific business needs."<br><br>
-    In parallel to rewriting their applications, Zalando had set a goal of expanding beyond basic e-commerce to a platform offering multi-tenancy, a dramatic increase in assortments and styles, same-day delivery and even <a href="https://www.zalon.de">your own personal online stylist</a>.<br><br>
-    The need to scale ultimately led the company on a cloud-native journey. As did its embrace of a microservices-based software architecture that gives engineering teams more autonomy and ownership of projects. "This move to the cloud was necessary because in the data center you couldn’t have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app," Jacobs says.
 
-</div>
-</section>
-<div class="banner3">
-  <div class="banner3text">
-    "This move to the cloud was necessary because in the data center you couldn’t have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app."
+<p>With the old infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs on the Linux kernel. This makes a lot of people pretty happy. The engineers love autonomy."</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Zalando began moving its infrastructure from two on-premise data centers to the cloud, requiring the migration of older applications for cloud-readiness. "We decided to have a clean break," says Jacobs. "Our <a href="https://aws.amazon.com/">Amazon Web Services</a> infrastructure was set up like so: Every team has its own AWS account, which is completely isolated, meaning there’s no ‘lift and shift.’ You basically have to rewrite your application to make it cloud-ready even down to the persistence layer. We bravely went back to the drawing board and redid everything, first choosing Docker as a common containerization, then building the infrastructure from there."<br><br>
-  The company decided to hold off on orchestration at the beginning, but as teams were migrated to AWS, "we saw the pain teams were having with infrastructure and cloud formation on AWS," says Jacobs. <br><br>
-  Zalandos 200+ autonomous engineering teams decide what technologies to use and could operate their own applications using their own AWS accounts. This setup proved to be a compliance challenge. Even with strict rules-of-play and automated compliance checks in place, engineering teams and IT-compliance were overburdened addressing compliance issues. "Violations appear for non-compliant behavior, which we detect when scanning the cloud infrastructure," says Jacobs. "Everything is possible and nothing enforced, so you have to live with violations (and resolve them) instead of preventing the error in the first place. This means overhead for teams—and overhead for compliance and operations. It also takes time to spin up new EC2 instances on AWS, which affects our deployment velocity." <br><br>
-  The team realized they needed to "leverage the value you get from cluster management," says Jacobs. When they first looked at Platform as a Service (PaaS) options in 2015, the market was fragmented; but "now there seems to be a clear winner. It seemed like a good bet to go with Kubernetes."<br><br>
-  The transition to Kubernetes started in 2016 during Zalando’s <a href="https://jobs.zalando.com/tech/blog/hack-week-5-is-live/?gh_src=4n3gxh1">Hack Week</a> where participants deployed their projects to a Kubernetes cluster. From there 60 members of the tech infrastructure department were on-boarded - and then engineering teams were brought on one at a time. "We always start by talking with them and make sure everyone’s expectations are clear," says Jacobs. "Then we conduct some Kubernetes training, which is mostly training for our CI/CD setup, because the user interface for our users is primarily through the CI/CD system. But they have to know fundamental Kubernetes concepts and the API. This is followed by a weekly sync with each team to check their progress. Once they have something in production, we want to see if everything is fine on top of what we can improve."
+{{< case-studies/quote author="Henning Jacobs, Head of Developer Productivity at Zalando" >}}
+"We envision all Zalando delivery teams running their containerized applications on a state-of-the-art, reliable and scalable cluster infrastructure provided by Kubernetes."
+{{< /case-studies/quote >}}
 
-</div>
-</section>
-<div class="banner4">
-  <div class="banner4text">
-  Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs.
-  </div>
-</div>
+{{< case-studies/lead >}}
+When Henning Jacobs arrived at Zalando in 2010, the company was just two years old with 180 employees running an online store for European shoppers to buy fashion items.
+{{< /case-studies/lead >}}
 
-<section class="section4">
-<div class="fullcol">
-  At the moment, Zalando is running an initial 40 Kubernetes clusters with plans to scale for the foreseeable future.
-  Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs. "The self-healing infrastructure provides a frictionless experience with higher-level abstractions built upon low-level best practices. We envision all Zalando delivery teams will run their containerized applications on a state-of-the-art reliable and scalable cluster infrastructure provided by Kubernetes."<br><br>
-  With the old on-premise infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs in the Linux kernel. This makes a lot of people pretty happy. The engineers love the autonomy."
-  There were a few challenges in Zalando’s Kubernetes implementation. "We are a team of seven people providing clusters to different engineering teams, and our goal is to provide a rock-solid experience for all of them," says Jacobs. "We don’t want pet clusters. We don’t want to have to understand what workload they have; it should just work out of the box. With that in mind, cluster autoscaling is important. There are many different ways of doing cluster management, and this is not part of the core. So we created two components to provision clusters, have a registry for clusters, and to manage the whole cluster life cycle."<br><br>
-  Jacobs’s team also worked to improve the Kubernetes-AWS integration. "Thus you're very restricted. You need infrastructure to scale each autonomous team’s idea.""<br><br>
-  Plus, "there are still a lot of best practices missing," says Jacobs. The team, for example, recently solved a pod security policy issue. "There was already a concept in Kubernetes but it wasn’t documented, so it was kind of tricky," he says. The large Kubernetes community was a big help to resolve the issue. To help other companies start down the same path, Jacobs compiled his team’s learnings in a document called <a href="http://kubernetes-on-aws.readthedocs.io/en/latest/admin-guide/kubernetes-in-production.html">Running Kubernetes in Production</a>.
+<p>"It started as a PHP e-commerce site which was easy to get started with, but was not scaling with the business' needs" says Jacobs, Head of Developer Productivity at Zalando.</p>
 
-</div>
-</section>
+<p>At that time, the company began expanding beyond its German origins into other European markets. Fast-forward to today and Zalando now has more than 14,000 employees, 3.6 billion Euro in revenue for 2016 and operates across 15 countries. "With growth in all dimensions, and constant scaling, it has been a once-in-a-lifetime experience," he says.</p>
 
-<div class="banner5">
-  <div class="banner5text">
-    "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years... We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."
-  </div>
-</div>
-<section class="section5">
-<div class="fullcol">
-  In the end, Kubernetes made it possible for Zalando to introduce and maintain the new products the company envisioned to grow its platform. "<a href="https://www.zalon.de/">The fashion advice</a> product used Scala, and there were struggles to make this possible with our former infrastructure," says Jacobs. "It was a workaround, and that team needed more and more support from the platform team, just because they used different technologies. Now with Kubernetes, it’s autonomous. Whatever the workload is, that team can just go their way, and Kubernetes prevents other bottlenecks."<br><br>
-  Looking ahead, Jacobs sees Zalando’s new infrastructure as a great enabler for other things the company has in the works, from its new logistics software, to a platform feature connecting brands, to products dreamed up by data scientists. "One vision is if you watch the next James Bond movie and see the suit he’s wearing, you should be able to automatically order it, and have it delivered to you within an hour," says Jacobs. "It’s about connecting the full fashion sphere. This is definitely not possible if you have a bottleneck with everyone running in the same data center and thus very restricted. You need infrastructure to scale each autonomous team’s idea."<br><br>
-  For other companies considering this technology, Jacobs says he wouldn’t necessarily advise doing it exactly the same way Zalando did. "It’s okay to do so if you’re ready to fail at some things," he says. "You need to set the right expectations. Not everything will work. Rewriting apps and this type of organizational change can be disruptive. The first product we moved was critical. There were a lot of dependencies, and it took longer than expected. Maybe we should have started with something less complicated, less business critical, just to get our toes wet."<br><br>
-  But once they got to the other side "it was clear for everyone that there’s no big alternative," Jacobs adds. "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years. Zalando Technology benefits from migrating to Kubernetes as we are able to leverage our existing knowledge to create an engineering platform offering flexibility and speed to our engineers while significantly reducing the operational overhead. We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."
+<p>Not to mention a unique opportunity for an infrastructure specialist like Jacobs. Just after he joined, the company began rewriting all their applications in-house. "That was generally our strategy," he says. "For example, we started with our own logistics warehouses but at first you don't know how to do logistics software, so you have some vendor software. And then we replaced it with our own because with off-the-shelf software you're not competitive. You need to optimize these processes based on your specific business needs."</p>
 
-</div>
+<p>In parallel to rewriting their applications, Zalando had set a goal of expanding beyond basic e-commerce to a platform offering multi-tenancy, a dramatic increase in assortments and styles, same-day delivery and even <a href="https://www.zalon.de">your own personal online stylist</a>.</p>
 
-</section>
+<p>The need to scale ultimately led the company on a cloud-native journey. As did its embrace of a microservices-based software architecture that gives engineering teams more autonomy and ownership of projects. "This move to the cloud was necessary because in the data center you couldn't have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app," Jacobs says.</p>
+
+{{< case-studies/quote image="/images/case-studies/zalando/banner3.jpg" >}}
+"This move to the cloud was necessary because in the data center you couldn't have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app."
+{{< /case-studies/quote >}}
+
+<p>Zalando began moving its infrastructure from two on-premise data centers to the cloud, requiring the migration of older applications for cloud-readiness. "We decided to have a clean break," says Jacobs. "Our <a href="https://aws.amazon.com/">Amazon Web Services</a> infrastructure was set up like so: Every team has its own AWS account, which is completely isolated, meaning there's no 'lift and shift.' You basically have to rewrite your application to make it cloud-ready even down to the persistence layer. We bravely went back to the drawing board and redid everything, first choosing Docker as a common containerization, then building the infrastructure from there."</p>
+
+<p>The company decided to hold off on orchestration at the beginning, but as teams were migrated to AWS, "we saw the pain teams were having with infrastructure and cloud formation on AWS," says Jacobs.</p>
+
+<p>Zalandos 200+ autonomous engineering teams decide what technologies to use and could operate their own applications using their own AWS accounts. This setup proved to be a compliance challenge. Even with strict rules-of-play and automated compliance checks in place, engineering teams and IT-compliance were overburdened addressing compliance issues. "Violations appear for non-compliant behavior, which we detect when scanning the cloud infrastructure," says Jacobs. "Everything is possible and nothing enforced, so you have to live with violations (and resolve them) instead of preventing the error in the first place. This means overhead for teams—and overhead for compliance and operations. It also takes time to spin up new EC2 instances on AWS, which affects our deployment velocity."</p>
+
+<p>The team realized they needed to "leverage the value you get from cluster management," says Jacobs. When they first looked at Platform as a Service (PaaS) options in 2015, the market was fragmented; but "now there seems to be a clear winner. It seemed like a good bet to go with Kubernetes."</p>
+
+<p>The transition to Kubernetes started in 2016 during Zalando's <a href="https://jobs.zalando.com/tech/blog/hack-week-5-is-live/?gh_src=4n3gxh1">Hack Week</a> where participants deployed their projects to a Kubernetes cluster. From there 60 members of the tech infrastructure department were on-boarded - and then engineering teams were brought on one at a time. "We always start by talking with them and make sure everyone's expectations are clear," says Jacobs. "Then we conduct some Kubernetes training, which is mostly training for our CI/CD setup, because the user interface for our users is primarily through the CI/CD system. But they have to know fundamental Kubernetes concepts and the API. This is followed by a weekly sync with each team to check their progress. Once they have something in production, we want to see if everything is fine on top of what we can improve."</p>
+
+{{< case-studies/quote image="/images/case-studies/zalando/banner4.jpg" >}}
+Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs.
+{{< /case-studies/quote >}}
+
+<p>At the moment, Zalando is running an initial 40 Kubernetes clusters with plans to scale for the foreseeable future. Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs. "The self-healing infrastructure provides a frictionless experience with higher-level abstractions built upon low-level best practices. We envision all Zalando delivery teams will run their containerized applications on a state-of-the-art reliable and scalable cluster infrastructure provided by Kubernetes."</p>
+
+<p>With the old on-premise infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs in the Linux kernel. This makes a lot of people pretty happy. The engineers love the autonomy."</p>
+
+<p>There were a few challenges in Zalando's Kubernetes implementation. "We are a team of seven people providing clusters to different engineering teams, and our goal is to provide a rock-solid experience for all of them," says Jacobs. "We don't want pet clusters. We don't want to have to understand what workload they have; it should just work out of the box. With that in mind, cluster autoscaling is important. There are many different ways of doing cluster management, and this is not part of the core. So we created two components to provision clusters, have a registry for clusters, and to manage the whole cluster life cycle."</p>
+
+<p>Jacobs's team also worked to improve the Kubernetes-AWS integration. "Thus you're very restricted. You need infrastructure to scale each autonomous team's idea." Plus, "there are still a lot of best practices missing," says Jacobs. The team, for example, recently solved a pod security policy issue. "There was already a concept in Kubernetes but it wasn't documented, so it was kind of tricky," he says. The large Kubernetes community was a big help to resolve the issue. To help other companies start down the same path, Jacobs compiled his team's learnings in a document called <a href="http://kubernetes-on-aws.readthedocs.io/en/latest/admin-guide/kubernetes-in-production.html">Running Kubernetes in Production</a>.</p>
+
+{{< case-studies/quote >}}
+"The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years... We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."
+{{< /case-studies/quote >}}
+
+<p>In the end, Kubernetes made it possible for Zalando to introduce and maintain the new products the company envisioned to grow its platform. "<a href="https://www.zalon.de/">The fashion advice</a> product used Scala, and there were struggles to make this possible with our former infrastructure," says Jacobs. "It was a workaround, and that team needed more and more support from the platform team, just because they used different technologies. Now with Kubernetes, it's autonomous. Whatever the workload is, that team can just go their way, and Kubernetes prevents other bottlenecks."</p>
+
+<p>Looking ahead, Jacobs sees Zalando's new infrastructure as a great enabler for other things the company has in the works, from its new logistics software, to a platform feature connecting brands, to products dreamed up by data scientists. "One vision is if you watch the next James Bond movie and see the suit he's wearing, you should be able to automatically order it, and have it delivered to you within an hour," says Jacobs. "It's about connecting the full fashion sphere. This is definitely not possible if you have a bottleneck with everyone running in the same data center and thus very restricted. You need infrastructure to scale each autonomous team's idea."</p>
+
+<p>For other companies considering this technology, Jacobs says he wouldn't necessarily advise doing it exactly the same way Zalando did. "It's okay to do so if you're ready to fail at some things," he says. "You need to set the right expectations. Not everything will work. Rewriting apps and this type of organizational change can be disruptive. The first product we moved was critical. There were a lot of dependencies, and it took longer than expected. Maybe we should have started with something less complicated, less business critical, just to get our toes wet."</p>
+
+<p>But once they got to the other side "it was clear for everyone that there's no big alternative," Jacobs adds. "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years. Zalando Technology benefits from migrating to Kubernetes as we are able to leverage our existing knowledge to create an engineering platform offering flexibility and speed to our engineers while significantly reducing the operational overhead. We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."</p>
diff --git a/content/ko/docs/_index.md b/content/ko/docs/_index.md
index e3c4620130..af7043cf61 100644
--- a/content/ko/docs/_index.md
+++ b/content/ko/docs/_index.md
@@ -1,3 +1,6 @@
 ---
+linktitle: 쿠버네티스 문서
 title: 문서
+sitemap:
+  priority: 1.0
 ---
diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md
index b3806591c2..f7666ef0c3 100644
--- a/content/ko/docs/concepts/architecture/cloud-controller.md
+++ b/content/ko/docs/concepts/architecture/cloud-controller.md
@@ -23,7 +23,7 @@ weight: 40
 
 ## 디자인
 
-![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.png)
+![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.svg)
 
 클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로,
 파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일
@@ -213,4 +213,3 @@ rules:
 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다.
 
 플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참조한다.
-
diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md
index 7d5e86837e..2fdaf7599c 100644
--- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md
@@ -16,7 +16,7 @@ aliases:
 
 ## 노드에서 컨트롤 플레인으로의 통신
 쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
-특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
+특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
 
 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
 
diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md
index 7782d27855..836b4a5b6b 100644
--- a/content/ko/docs/concepts/architecture/controller.md
+++ b/content/ko/docs/concepts/architecture/controller.md
@@ -6,14 +6,14 @@ weight: 30
 
 <!-- overview -->
 
-로보틱스와 자동화에서 _컨트롤 루프_ 는 
+로보틱스와 자동화에서 _컨트롤 루프_ 는
 시스템 상태를 조절하는 종료되지 않는 루프이다.
 
 컨트롤 루프의 예시: 실내 온도 조절기
 
 사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를
 온도 조절기에 알려준다.
-*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 
+*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
 현재 상태를 의도한 상태에 가깝게 만든다.
 
 {{< glossary_definition term_id="controller" length="short">}}
@@ -28,64 +28,64 @@ weight: 30
 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
 이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
 는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
-해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 
+해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
 상태에 가깝게 만드는 역할을 한다.
 
-컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, 
-쿠버네티스에서는 컨트롤러가 
+컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로,
+쿠버네티스에서는 컨트롤러가
 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 로
 유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다.
 
 {{< comment >}}
-네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는 
-오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는 
+네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는
+오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는
 자세한 설명을 생략한다.
 {{< /comment >}}
 
 ### API 서버를 통한 제어
 
-{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스 
-내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 
+{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스
+내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와
 상호 작용하며 상태를 관리한다.
 
-잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 
-작업을 수행한 다음 중지하는 
+잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고,
+작업을 수행한 다음 중지하는
 쿠버네티스 리소스 이다.
 
-(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet 
+(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet
 의 의도한 상태 중 일부가 된다.)
 
-잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 
+잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
 노드 집합의 kubelet이 작업을 수행하기에 적합한
 수의 파드를 실행하게 한다.
 잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다.
-대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 
+대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
 지시한다.
-{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의
 다른 컴포넌트는 신규 정보
-(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, 
+(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
 결국 해당 작업을 완료시킨다.
 
 새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다.
-잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 
-만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 
+잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
+만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
 잡이 완료에 가까워 지도록 한다.
 
 또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다.
 예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는
 잡 오브젝트가 `Finished`  로 표시되도록 업데이트한다.
 
-(이것은 지금 방 온도가 설정한 온도인 것을 표시하기 
+(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
 위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).
 
 ### 직접 제어
 
-잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 
+잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
 변경해야 할 필요가 있다.
 
-예를 들어, 만약 컨트롤 루프를 사용해서 
+예를 들어, 만약 컨트롤 루프를 사용해서
 클러스터에 충분한 {{< glossary_tooltip text="노드들" term_id="node" >}}이
-있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 
+있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
 현재 클러스터 외부의 무언가를 필요로 한다.
 
 외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한
@@ -101,7 +101,7 @@ weight: 30
 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
 변화에 대응할 수 있다.
 
-작업이 발생함에 따라 어떤 시점에서든 클러스터가 
+작업이 발생함에 따라 어떤 시점에서든 클러스터가
 변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로,
 클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.
 
@@ -110,26 +110,26 @@ weight: 30
 
 ## 디자인
 
-디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 
+디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
-(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 
+(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
 만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는
-잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 
+잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
 확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
 잡은 다른 컨트롤러가 생성한다.
 
-컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, 
-간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 
+컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
+간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
 허용하도록 디자인되었다.
 
 {{< note >}}
 동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
-이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 
+이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
 연결된 리소스에만 주의를 기울인다.
 
 예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다.
-잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다. 
-이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는 
+잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
+이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
 정보({{< glossary_tooltip term_id="label" text="레이블" >}})가 있기 때문이다.
 {{< /note >}}
 
@@ -139,14 +139,14 @@ weight: 30
 내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이
 내장 컨트롤러는 중요한 핵심 동작을 제공한다.
 
-디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 
+디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
 자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다.
-쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, 
+쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
 어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.
 
 컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다.
 또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다.
-소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, 
+소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
 따라 달라진다.
 
@@ -154,8 +154,7 @@ weight: 30
 
 ## {{% heading "whatsnext" %}}
 
-* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기
-* [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자.
+* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기
+* [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자.
 * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
 * 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
-
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
index eab7eb0de2..d27845e654 100644
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@@ -12,7 +12,7 @@ weight: 10
 {{< glossary_tooltip text="파드" term_id="pod" >}}를
 실행하는데 필요한 서비스가 포함되어 있다.
 
-일반적으로 클러스터에는 여러개의 노드가 있으며, 학습 또는 리소스가 제한되는
+일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는
 환경에서는 하나만 있을 수도 있다.
 
 노드의 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에는
diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md
index cde1b093b5..daa1dfd702 100755
--- a/content/ko/docs/concepts/cluster-administration/_index.md
+++ b/content/ko/docs/concepts/cluster-administration/_index.md
@@ -47,11 +47,11 @@ no_list: true
 
 * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
 
-* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
+* [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다.
 
 * [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
 
-* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
+* [인가](/ko/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
 
 * [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
 
diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md
index 067ebab037..325cad9907 100644
--- a/content/ko/docs/concepts/cluster-administration/addons.md
+++ b/content/ko/docs/concepts/cluster-administration/addons.md
@@ -5,12 +5,12 @@ content_type: concept
 
 <!-- overview -->
 
+{{% thirdparty-content %}}
+
 애드온은 쿠버네티스의 기능을 확장한다.
 
 이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다.
 
-각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다.
-
 <!-- body -->
 
 ## 네트워킹과 네트워크 폴리시
@@ -29,7 +29,7 @@ content_type: concept
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
 * [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
-* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
 
 ## 서비스 검색
 
diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md
deleted file mode 100644
index 9c1c556808..0000000000
--- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md
+++ /dev/null
@@ -1,433 +0,0 @@
----
-title: 클라우드 제공자
-content_type: concept
-weight: 30
----
-
-<!-- overview -->
-이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에
-대해 설명한다.
-
-<!-- body -->
-### kubeadm
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다.
-kubeadm에는 클라우드 제공자에 대한 구성 정보를 지정하는 구성 옵션이 있다. 예를 들어
-kubeadm을 사용하여 일반적인 인-트리(in-tree) 클라우드 제공자를 아래와 같이 구성할 수 있다.
-
-```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: InitConfiguration
-nodeRegistration:
-  kubeletExtraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
----
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
-apiServer:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-controllerManager:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-```
-
-인-트리 클라우드 제공자는 일반적으로
-[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
-[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
-및 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다.
-각 제공자에 대해 `--cloud-config` 에 지정된 파일의 내용도 아래에 설명되어 있다.
-
-모든 외부 클라우드 제공자의 경우, 아래 제공자에 대한 제목 아래에 있는 개별 리포지터리의 지침을 따르거나,
-[모든 리포지터리 목록](https://github.com/kubernetes?q=cloud-provider-&type=&language=)을 볼 수 있다
-
-## AWS
-이 섹션에서는 Amazon Web Services에서 쿠버네티스를 실행할 때 사용할 수 있는
-모든 구성에 대해 설명한다.
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)이다.
-
-### 노드 이름
-
-AWS 클라우드 제공자는 AWS 인스턴스의 프라이빗 DNS 이름을 쿠버네티스 노드 오브젝트의 이름으로 사용한다.
-
-### 로드 밸런서
-아래와 같이 어노테이션을 구성하여 AWS의 특정 기능을 사용하도록
-[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 설정할 수 있다.
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: example
-  namespace: kube-system
-  labels:
-    run: example
-  annotations:
-     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #이 값을 교체한다
-     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
-spec:
-  type: LoadBalancer
-  ports:
-  - port: 443
-    targetPort: 5556
-    protocol: TCP
-  selector:
-    app: example
-```
-_어노테이션_ 을 사용하여 AWS의 로드 밸런서 서비스에 다른 설정을 적용할 수 있다. 다음은 AWS ELB에서 지원하는 어노테이션에 대해 설명한다.
-
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: 액세스 로그 방출 간격을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: 서비스에서 액세스 로그를 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: 액세스 로그 s3 버킷 이름을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: 액세스 로그 s3 버킷 접두사를 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: 서비스에서 쉼표로 구분된 키-값 쌍의 목록을 지정하여 ELB에 추가 태그로 기록된다. 예를 들면 다음과 같다. `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`
-* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: 서비스에서 리스너 뒤의 백엔드(파드)가 언급한 프로토콜을 지정하는 데 사용된다. 만약 `http` (기본값) 또는 `https` 인 경우, 연결을 종료하고 헤더를 파싱하는 HTTPS 리스너가 생성된다. `ssl` 이나 `tcp` 로 설정된 경우, "원시(raw)" SSL 리스너가 사용된다. `http` 로 설정하고 `aws-load-balancer-ssl-cert` 를 사용하지 않았다면 HTTP 리스너가 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: 서비스에서 보안 리스너를 요청하는 데 사용된다. 값은 유효한 인증서 ARN이다. 자세한 내용은, [ELB 리스너 구성](https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/classic/elb-listener-config.html)을 참고한다. CertARN은 IAM 또는 CM 인증서 ARN이다(예: `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`).
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 서비스에서 연결 드레이닝(draining)을 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 서비스에서 연결 드레이닝 타임아웃 값을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: 서비스에서 유휴 연결 타임아웃 값을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: 서비스에서 교차 영역의 로드 밸런싱을 활성화하거나 비활성화하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 생성된 ELB에 추가할 보안 그룹을 지정하는 데 사용된다. 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. 여기에 정의된 보안 그룹은 서비스 간에 공유해서는 안된다.
-* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 서비스에서 생성된 ELB에 추가할 추가적인 보안 그룹을 지정하는 데 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-internal`: 서비스에서 내부 ELB 사용 희망을 표시하기 위해 사용된다.
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: 서비스에서 ELB에서 프록시 프로토콜을 활성화하는 데 사용된다. 현재는 모든 ELB 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPS 리스너를 사용할 쉼표로 구분된 포트의 목록을 지정하기 위해 서비스에서 사용된다. 기본값은 `*`(모두)이다.
-
-AWS 어노테이션에 대한 정보 출처는 [aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)의 코멘트이다.
-
-## Azure
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)이다.
-
-### 노드 이름
-
-Azure 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름(hostname)을 사용한다.
-참고로 쿠버네티스 노드 이름은 Azure VM 이름과 일치해야 한다.
-
-## CloudStack
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)이다.
-
-### 노드 이름
-
-CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
-참고로 쿠버네티스 노드 이름은 CloudStack VM 이름과 일치해야 한다.
-
-## GCE
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)이다.
-
-### 노드 이름
-
-GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
-참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함).
-
-## HUAWEI CLOUD
-
-외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다.
-
-### 노드 이름
-
-HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다.
-노드에서 kubelet을 시작할 때 반드시 `--hostname-override=<node private IP>` 를 사용한다.
-
-## OpenStack
-이 섹션에서는 쿠버네티스와 함께 OpenStack을 사용할 때 사용할 수 있는
-모든 구성에 대해 설명한다.
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)이다.
-
-### 노드 이름
-
-OpenStack 클라우드 제공자는 (OpenStack 메타데이터에서 결정한) 인스턴스 이름을 쿠버네티스 노드 오브젝트의 이름으로 사용한다.
-참고로 kubelet이 노드 오브젝트를 성공적으로 등록하려면 인스턴스 이름이 유효한 쿠버네티스 노드 이름이어야 한다.
-
-### 서비스
-
-쿠버네티스에 대한
-OpenStack 클라우드 제공자 구현은 사용 가능한 경우 기본 클라우드에서
-이러한 OpenStack 서비스 사용을 지원한다.
-
-| 서비스                    | API 버전         | 필수      |
-|--------------------------|----------------|----------|
-| 블록 스토리지 (Cinder)      | V1†, V2, V3    | 아니오     |
-| 컴퓨트 (Nova)              | V2             | 아니오    |
-| 아이덴티티(Identity) (Keystone) | V2‡,  V3       | 예        |
-| 로드 밸런싱 (Neutron)       | V1§, V2        | 아니오     |
-| 로드 밸런싱 (Octavia)       | V2             | 아니오     |
-
-† 블록 스토리지 V1 API 지원은 사용 중단(deprecated)되며, 쿠버네티스 1.9에서 블록 스토리지
-V3 API 지원이 추가되었다.
-
-‡ 아이덴티티 V2 API 지원은 사용 중단되며, 향후 릴리스에서는 제공자에서
-제거될 예정이다. "Queens" 릴리스부터 OpenStack은 더 이상 아이덴티티 V2 API를
-공개하지 않는다.
-
-§ 로드 밸런싱 V1 API 지원이 쿠버네티스 1.9에서 제거되었다.
-
-서비스 디스커버리는 제공자 구성에서 제공된 `auth-url` 을 사용하여
-OpenStack 아이덴티티(Keystone)에서 관리하는 서비스 카탈로그를
-나열하여 수행된다. Keystone 이외의 OpenStack 서비스를 사용할 수 없고
-영향을 받는 기능에 대한 지원을 거부할 경우 제공자는 기능이
-점진적으로 떨어진다. 기본 클라우드에서 Neutron이 게시한 확장 목록을 기반으로
-특정 기능을 활성화하거나 비활성화할 수도 있다.
-
-### cloud.conf
-쿠버네티스는 cloud.conf 파일을 통해 OpenStack과 상호 작용하는 방법을 알고 있다. 쿠버네티스에
-OpenStack 인증 엔드포인트의 자격 증명과 위치를 제공하는 파일이다.
-다음의 세부 정보를 지정하여 cloud.conf 파일을 만들 수 있다.
-
-#### 일반적인 구성
-이것은 가장 자주 설정해야 하는 값에 대한 일반적인 구성의
-예시이다. OpenStack 클라우드의 Keystone
-엔드포인트에서, 제공자를 가리키고 이를 인증하는 방법에 대한 세부 사항을 제공하고,
-로드 밸런서를 구성한다.
-
-```yaml
-[Global]
-username=user
-password=pass
-auth-url=https://<keystone_ip>/identity/v3
-tenant-id=c869168a828847f39f7f06edd7305637
-domain-id=2a73b8f597c04551a0fdc8e95544be8a
-
-[LoadBalancer]
-subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
-```
-
-##### 글로벌
-OpenStack 제공자에 대한 다음의 구성 옵션은 글로벌
-구성과 관련이 있으며 `cloud.conf` 파일의 `[Global]` 섹션에 있어야
-한다.
-
-* `auth-url` (필수): 인증에 사용되는 Keystone API의 URL이다.
-  OpenStack 제어판의 액세스 및 보안 > API 액세스 >
-  자격 증명에서 찾을 수 있다.
-* `username` (필수): Keystone에 설정된 유효한 사용자의 username을 나타낸다.
-* `password` (필수): Keystone에 설정된 유효한 사용자의 password를 나타낸다.
-* `tenant-id` (필수): 리소스를 생성하려는 프로젝트의 id를 지정하는 데
-  사용된다.
-* `tenant-name` (선택): 리소스를 생성하려는 프로젝트의 이름을
-  지정하는 데 사용된다.
-* `trust-id` (선택): 권한 부여에 사용할 트러스트(trust)의 식별자를 지정하는 데
-  사용된다. 트러스트는 한 사용자(트러스터(trustor))의 권한을 다른 사용자(트러스티(trustee))에게 역할을
-  위임하고, 선택적으로 트러스티가 트러스터를 가장하도록
-  허용한다. 사용 가능한 트러스트는
-  Keystone API의 `/v3/OS-TRUST/trusts` 엔드포인트 아래에 있다.
-* `domain-id` (선택): 사용자가 속한 도메인의 id를 지정하는 데
-  사용된다.
-* `domain-name` (선택): 사용자가 속한 도메인의 이름을 지정하는 데
-  사용된다.
-* `region` (선택): 멀티-리전(multi-region) OpenStack 클라우드에서
-  실행할 때 사용할 리전의 식별자를 지정하는 데 사용된다. 리전은 OpenStack 디플로이먼트의
-  일반 디비전(division)이다. 리전에 엄격한 지리적 의미는 없지만,
-  디플로이먼트 시 `us-east` 와 같은
-  리전의 식별자에 지리적 이름을 사용할 수 있다. 사용 가능한 지역은
-  Keystone API의 `/v3/regions` 엔드포인트 아래에 있다.
-* `ca-file` (선택): 사용자 지정 CA 파일의 경로를 지정하는 데 사용된다.
-
-
-테넌트를 프로젝트로 변경하는 Keystone V3을 사용하면 `tenant-id` 값이
-API의 프로젝트 구성에 자동으로 매핑된다.
-
-#####  로드 밸런서
-OpenStack 제공자에 대한 다음의 구성 옵션은 로드 밸런서와 관련이 있으며
-`cloud.conf` 파일의 `[LoadBalancer]` 섹션에 있어야
-한다.
-
-* `lb-version` (선택): 자동 버전 감지를 대체하는 데 사용된다. 유효한
-  값은 `v1` 또는 `v2` 이다. 값이 제공되지 않는 경우 자동 감지는
-  기본 OpenStack 클라우드에 의해 제공되는 가장 최신의 지원되는 버전을
-  선택한다.
-* `use-octavia` (선택): Octavia LBaaS V2 서비스 카탈로그 엔드포인트를 찾고 사용할지의
-  여부를 결정하는 데 사용된다. 유효한 값은 `true` 또는 `false` 이다.
-  `true` 가 지정되고 Octaiva LBaaS V2 항목을 찾을 수 없는 경우,
-  제공자는 폴백(fall back)하고 대신 Neutron LBaaS V2 엔드포인트를 찾으려고
-  시도한다. 기본값은 `false` 이다.
-* `subnet-id` (선택): 로드 밸런서를 생성하려는 서브넷의 id를
-  지정하는 데 사용된다. Network > Networks 에서 찾을 수 있다. 해당
-  네트워크를 클릭하여 서브넷을 가져온다.
-* `floating-network-id` (선택): 지정된 경우, 로드 밸런서에 대한 유동 IP를
-  생성한다.
-* `lb-method` (선택): 로드 밸런서 풀(pool)의 멤버 간에 부하가
-  분산되는 알고리즘을 지정하는 데 사용된다. 값은
-  `ROUND_ROBIN`, `LEAST_CONNECTIONS` 또는 `SOURCE_IP` 가 될 수 있다. 지정되지
-  않은 경우 기본 동작은 `ROUND_ROBIN` 이다.
-* `lb-provider` (선택): 로드 밸런서의 제공자를 지정하는 데 사용된다.
-  지정하지 않으면, neutron에 구성된 기본 제공자 서비스가
-  사용된다.
-* `create-monitor` (선택): Neutron 로드 밸런서에 대한 헬스 모니터를
-  생성할지의 여부를 나타낸다. 유효한 값은 `true` 및 `false` 이다.
-  기본값은 `false` 이다. `true` 가 지정되면 `monitor-delay`,
-  `monitor-timeout` 및 `monitor-max-retries` 도 설정해야 한다.
-* `monitor-delay` (선택): 로드 밸런서의 멤버에게 프로브(probe)를
-  보내는 간격의 시간이다. 유효한 시간 단위를 지정해야 한다. 유효한 시간 단위는 "ns", "us"(또는 "µs"), "ms", "s", "m", "h"이다.
-* `monitor-timeout` (선택): 모니터가 타임아웃 되기 전에 핑(ping) 응답을
-  기다리는 최대 시간이다. 값은 지연 값보다 작아야
-  한다. 유효한 시간 단위를 지정해야 한다. 유효한 시간 단위는 "ns", "us"(또는 "µs"), "ms", "s", "m", "h"이다.
-* `monitor-max-retries` (선택): 로드 밸런서 멤버의 상태를 INACTIVE로
-  변경하기 전에 허용되는 핑 오류 수이다. 1에서 10 사이의
-  숫자여야 한다.
-* `manage-security-groups` (선택): 로드 밸런서가 보안 그룹 규칙을
-  자동으로 관리해야 하는지의 여부를 결정한다. 유효한 값은
-  `true` 및 `false` 이다. 기본값은 `false` 이다. `true` 가 지정되면
-  `node-security-group` 도 제공해야 한다.
-* `node-security-group` (선택): 관리할 보안 그룹의 ID이다.
-
-##### 블록 스토리지
-OpenStack 제공자에 대한 다음의 구성 옵션은 블록 스토리지와 관련이 있으며
-`cloud.conf` 파일의 `[BlockStorage]` 섹션에 있어야 한다.
-
-* `bs-version` (선택): 자동 버전 감지를 대체하는 데 사용된다. 유효한
-  값은 `v1`, `v2`, `v3` 및 `auto` 이다. `auto` 가 지정되면 자동
-  감지는 기본 OpenStack 클라우드에 의해 노출되는 가장 최신의 지원되는
-  버전을 선택한다. 제공되지 않은 경우 기본값은 `auto` 이다.
-* `trust-device-path` (선택): 대부분의 시나리오에서 Cinder가 제공한
-  블록 장치 이름(예: `/dev/vda`)을 신뢰할 수 없다. 이 부울은
-  이 동작을 토글(toggle)한다. 이를 `true` 로 설정하면 Cinder에서 제공한
-  블록 장치 이름을 신뢰하게 된다. 기본값인 `false` 는 일련 번호와
-  `/dev/disk/by-id` 를 매핑하여 장치 경로를 검색하게 하며
-  권장하는 방법이다.
-* `ignore-volume-az` (선택): Cinder 볼륨을 연결할 때 가용 영역(availability zone)
-  사용에 영향을 주기 위해 사용된다. Nova와 Cinder의 가용성
-  영역이 서로 다른 경우, 이 값을 `true` 로 설정해야 한다. 이는 가장 일반적인 상황으로 Nova 가용 영역은
-  많지만 Cinder는 하나의 가용 영역만 있는 경우이다.
-  이전 릴리스에서 사용된 동작을 유지하기 위해 기본값은 `false`
-  이지만, 나중에 변경될 수 있다.
-* `node-volume-attach-limit` (선택): 노드에 연결할 수 있는
-  최대 볼륨 수이다. 기본값은 cinder의 경우 256이다.
-
-포트가 아닌 경로를 사용하여 엔드포인트를 구별하는 OpenStack
-디플로이먼트에서 1.8 이하의 쿠버네티스 버전을 배포하는 경우
-명시적으로 `bs-version` 파라미터를 설정해야 한다. 경로 기반의 엔드포인트는
-`http://foo.bar/volume` 형식이며 포트 기반의 엔드포인트는
-`http://foo.bar:xxx` 형식이다.
-
-경로 기반의 엔드포인트를 사용하고 쿠버네티스가 이전 자동 감지 로직을 사용하는 환경에서는
-볼륨 분리 시도 시 `BS API version autodetection failed.` 오류가
-리턴된다. 이 문제를 해결하려면 클라우드 제공자 구성에
-다음을 추가하여 Cinder API 버전 2를 강제로
-사용할 수 있다.
-
-```yaml
-[BlockStorage]
-bs-version=v2
-```
-
-##### 메타데이터
-OpenStack 제공자에 대한 다음의 구성 옵션은 메타데이터와 관련이 있으며
-`cloud.conf` 파일의 `[Metadata]` 섹션에 있어야 한다.
-
-* `search-order` (선택): 이 구성 키는 실행되는 인스턴스와
-  관련된 메타데이터를 제공자가 검색하는 방식에 영향을 준다. 기본값인
-  `configDrive,metadataService` 를 사용할 수 있는 경우에 제공자가
-  먼저 구성 드라이브에서 인스턴스와 관련된 메타데이터를
-  검색한 다음 메타데이터 서비스를 검색하게 한다. 대체할 수 있는 값은 다음과 같다.
-  * `configDrive` - 구성 드라이브에서 인스턴스 메타데이터만
-    검색한다.
-  * `metadataService` - 메타데이터 서비스에서 인스턴스 메타데이터만
-    검색한다.
-  * `metadataService,configDrive` - 사용할 수 있는 경우 먼저 메타데이터
-    서비스에서 인스턴스 메타데이터를 검색한 다음, 구성 드라이브를 검색한다.
-
-  구성 드라이브의 메타데이터는 시간이 지남에 따라
-  오래될 수 있지만, 메타데이터 서비스는 항상 최신 뷰를 제공하므로
-  이러한 설정은 바람직하다. 모든 OpenStack 클라우드가
-  구성 드라이브와 메타데이터 서비스를 모두 제공하는 것은 아니며 하나 또는 다른 하나만
-  사용할 수 있으므로 기본값은 둘 다를 확인하는 것이다.
-
-##### 라우트
-
-OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet]
-쿠버네티스 네트워크 플러그인과 관련이 있으며 `cloud.conf` 파일의 `[Route]` 섹션에
-있어야 한다.
-
-* `router-id` (선택): 기본 클라우드의 Neutron 디플로이먼트가
-  `extraroutes` 확장을 지원하는 경우 경로를 추가할 라우터를 지정하는 데 `router-id`
-  를 사용한다. 선택한 라우터는 클러스터 노드를 포함하는 프라이빗 네트워크에
-  걸쳐 있어야 한다(일반적으로 하나의 노드 네트워크만 있으며, 이 값은
-  노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서
-  [kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을
-  사용하는 데 필요하다.
-
-## OVirt
-
-### 노드 이름
-
-OVirt 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
-참고로 쿠버네티스 노드 이름은 VM FQDN(Ovirt의 `<vm><guest_info><fqdn>...</fqdn></guest_info></vm>` 아래에서 보고된)과 일치해야 한다.
-
-## Photon
-
-### 노드 이름
-
-Photon 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
-참고로 쿠버네티스 노드 이름은 Photon VM 이름(또는 `--cloud-config` 에서 `overrideIP` 가 true로 설정된 경우, 쿠버네티스 노드 이름은 Photon VM IP 주소와 일치해야 함)과 일치해야 한다.
-
-## vSphere
-
-{{< tabs name="vSphere cloud provider" >}}
-{{% tab name="vSphere 6.7U3 이상" %}}
-vSphere 6.7U3 이상의 모든 vSphere 디플로이먼트의 경우, [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)와 함께 [외부 vSphere 클라우드 제공자](https://github.com/kubernetes/cloud-provider-vsphere)를 권장한다. 퀵스타트 가이드는 [CSI와 CPI를 사용하여 vSphere에 쿠버네티스 클러스터 배포하기](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)를 참고한다.
-{{% /tab %}}
-{{% tab name="vSphere 6.7U3 미만" %}}
-vSphere 6.7U3 미만을 사용할 경우, 인-트리 vSphere 클라우드 제공자를 권장한다. 퀵스타트 가이드는 [kubeadm을 사용하여 vSphere에 쿠버네티스 클러스터 실행하기](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)를 참고한다.
-{{% /tab %}}
-{{< /tabs >}}
-
-vSphere 클라우드 제공자에 대한 자세한 문서를 보려면, [vSphere 클라우드 제공자 문서 사이트](https://cloud-provider-vsphere.sigs.k8s.io)를 방문한다.
-
-## IBM 클라우드 쿠버네티스 서비스
-
-### 컴퓨트 노드
-IBM 클라우드 쿠버네티스 서비스 제공자를 사용하면, 단일 영역 또는 하나의 리전에서 여러 영역에 걸쳐 가상 노드와 물리(베어 메탈) 노드가 혼합된 클러스터를 생성할 수 있다. 자세한 정보는, [클러스터와 워커(worker) 노드 설정 계획](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)을 참고한다.
-
-쿠버네티스 노드 오브젝트의 이름은 IBM 클라우드 쿠버네티스 서비스 워커 노드 인스턴스의 프라이빗 IP 주소이다.
-
-### 네트워킹
-IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [클러스터 네트워킹 구성](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)을 참고한다.
-
-퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [앱을 노출할 서비스 선택하기](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다.
-
-### 스토리지
-IBM 클라우드 쿠버네티스 서비스 제공자는 쿠버네티스-네이티브 퍼시스턴트 볼륨을 활용하여 사용자가 파일, 블록 및 클라우드 오브젝트 스토리지를 앱에 마운트할 수 있도록 한다. 데이터를 지속적으로 저장하기 위해 서비스로서의-데이터베이스(database-as-a-service)와 써드파티 애드온을 사용할 수도 있다. 자세한 정보는 [고가용성 퍼시스턴트 스토리지 계획](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)을 참고한다.
-
-## Baidu 클라우드 컨테이너 엔진
-
-### 노드 이름
-
-Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 프라이빗 IP 주소를 사용한다.
-참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다.
-
-## Tencent 쿠버네티스 엔진
-
-이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다.
-
-### 노드 이름
-
-Tencent 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
-참고로 쿠버네티스 노드 이름은 Tencent VM 프라이빗 IP와 일치해야 한다.
-
-## Alibaba 클라우드 쿠버네티스
-
- 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)이다.
-
-### 노드 이름
-
-Alibaba 클라우드는 노드 이름의 형식을 요구하지는 않지만, kubelet은 `--provider-id=${REGION_ID}.${INSTANCE_ID}` 를 추가해야만 한다. 파라미터 `${REGION_ID}` 는 쿠버네티스의 지역 ID에 해당하고, `${INSTANCE_ID}` 는 Alibaba ECS (Elastic Compute Service) ID를 의미한다.
-
-### 로드 밸런서
-
-[어노테이션](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)을 구성해서 Alibaba 클라우드의 특정 기능을 사용하도록 외부 로드 밸런서를 설정할 수 있다.
diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md
index 4896a8e7b8..4a0b700e02 100644
--- a/content/ko/docs/concepts/cluster-administration/logging.md
+++ b/content/ko/docs/concepts/cluster-administration/logging.md
@@ -6,7 +6,7 @@ weight: 60
 
 <!-- overview -->
 
-애플리케이션과 시스템 로그는 클러스터 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
+애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
 
 그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다.
 
@@ -91,6 +91,7 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를
 그 후 `kubectl logs` 는 빈 응답을 반환한다.
 {{< /note >}}
 
+[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
 ### 시스템 컴포넌트 로그
 
 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
@@ -257,5 +258,3 @@ fluentd를 구성하는 것에 대한 자세한 내용은,
 모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을
 구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은
 쿠버네티스의 범위를 벗어난다.
-
-
diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md
index e5c492491a..63877bc535 100644
--- a/content/ko/docs/concepts/cluster-administration/networking.md
+++ b/content/ko/docs/concepts/cluster-administration/networking.md
@@ -77,6 +77,8 @@ VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모
 이 목록은 알파벳 순으로 정렬되어 있으며, 정렬된 순서가
 우선 상태를 의미하는 것은 아니다.
 
+{{% thirdparty-content %}}
+
 ### ACI
 
 [Cisco 애플리케이션 센트릭 인프라스트럭처(Application Centric Infrastructure)](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html)는 컨테이너, 가상 머신 및 베어메탈 서버를 지원하는 통합 오버레이 및 언더레이 SDN 솔루션을 제공한다. [ACI](https://www.github.com/noironetworks/aci-containers)는 ACI를 위한 컨테이너 네트워킹 통합을 제공한다. 통합의 개요는 [여기](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)에서 제공된다.
@@ -312,4 +314,3 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
 네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
 [네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에
 자세히 설명되어 있다.
-
diff --git a/content/ko/docs/concepts/cluster-administration/monitoring.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md
similarity index 100%
rename from content/ko/docs/concepts/cluster-administration/monitoring.md
rename to content/ko/docs/concepts/cluster-administration/system-metrics.md
diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md
index 8e025addd3..d26f800f8c 100644
--- a/content/ko/docs/concepts/configuration/configmap.md
+++ b/content/ko/docs/concepts/configuration/configmap.md
@@ -16,7 +16,6 @@ weight: 20
 {{< /caution >}}
 
 
-
 <!-- body -->
 ## 사용 동기
 
@@ -24,25 +23,38 @@ weight: 20
 
 예를 들어, 자신의 컴퓨터(개발용)와 클라우드(실제 트래픽 처리)에서
 실행할 수 있는 애플리케이션을 개발한다고 가정해보자.
-`DATABASE_HOST` 라는
-환경 변수를 찾기 위해 코드를 작성한다. 로컬에서는 해당 변수를
-`localhost` 로 설정한다. 클라우드에서는, 데이터베이스
-컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를 참조하도록
-설정한다.
-
+`DATABASE_HOST` 라는 환경 변수를 찾기 위해 코드를 작성한다.
+로컬에서는 해당 변수를 `localhost` 로 설정한다. 클라우드에서는, 데이터베이스
+컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를
+참조하도록 설정한다.
 이를 통해 클라우드에서 실행 중인 컨테이너 이미지를 가져와
 필요한 경우 정확히 동일한 코드를 로컬에서 디버깅할 수 있다.
 
+컨피그맵은 많은 양의 데이터를 보유하도록 설계되지 않았다. 컨피그맵에 저장된
+데이터는 1MiB를 초과할 수 없다. 이 제한보다 큰 설정을
+저장해야 하는 경우, 볼륨을 마운트하는 것을 고려하거나 별도의
+데이터베이스 또는 파일 서비스를 사용할 수 있다.
+
 ## 컨피그맵 오브젝트
 
 컨피그맵은 다른 오브젝트가 사용할 구성을 저장할 수 있는
 API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)이다.
-`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리,
-컨피그맵에는 항목(키)과 해당 값을 저장하는 `data` 섹션이 있다.
+`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
+필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
+`binaryData` 는 모두 선택 사항이다. `data` 필드는
+UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를
+포함하도록 설계되었다.
 
 컨피그맵의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
+`data` 또는 `binaryData` 필드 아래의 각 키는
+영숫자 문자, `-`, `_` 또는 `.` 으로 구성되어야 한다. `data` 에 저장된 키는
+`binaryData` 필드의 키와 겹치지 않아야 한다.
+
+v1.19부터 컨피그맵 정의에 `immutable` 필드를 추가하여
+[변경할 수 없는 컨피그맵](#configmap-immutable)을 만들 수 있다.
+
 ## 컨피그맵과 파드
 
 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를
@@ -62,7 +74,7 @@ data:
   # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
   player_initial_lives: "3"
   ui_properties_file_name: "user-interface.properties"
-  #
+
   # 파일과 비슷한 키
   game.properties: |
     enemy.types=aliens,monsters
@@ -94,6 +106,7 @@ data:
 기술을 사용하여 다른 네임스페이스의 컨피그맵에 접근할 수도 있다.
 
 다음은 `game-demo` 의 값을 사용하여 파드를 구성하는 파드 예시이다.
+
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -102,7 +115,8 @@ metadata:
 spec:
   containers:
     - name: demo
-      image: game.example/demo-game
+      image: alpine
+      command: ["sleep", "3600"]
       env:
         # 환경 변수 정의
         - name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과
@@ -134,7 +148,6 @@ spec:
           path: "user-interface.properties"
 ```
 
-
 컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
 구분하지 않는다.
 더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다.
@@ -153,7 +166,6 @@ spec:
 노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
 컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
 
-{{< note >}}
 컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의
 파드에서 실행되는 컨테이너에 대한 설정을 구성하는 것이다. 컨피그맵을
 별도로 사용할 수도 있다.
@@ -162,16 +174,23 @@ spec:
 컨피그맵에 기반한 동작을 조정하는 {{< glossary_tooltip text="애드온" term_id="addons" >}}이나
 {{< glossary_tooltip text="오퍼레이터" term_id="operator-pattern" >}}를
 사용할 수도 있다.
-{{< /note >}}
 
 ### 파드에서 컨피그맵을 파일로 사용하기
 
 파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.
 
-1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다.
-1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다.
-1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
-1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다.
+1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을
+   참조할 수 있다.
+1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은
+   원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name`
+   필드를 설정한다.
+1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를
+   추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고
+   컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로
+   `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
+1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을
+   수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의
+   파일 이름이 된다.
 
 다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다.
 
@@ -214,19 +233,25 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
+## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
 
-쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
 사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
 데이터 변경을 방지하면 다음과 같은 이점이 있다.
 
 - 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
-- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
+- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써
+  클러스터의 성능을 향상시킴
+
+이 기능은 `ImmutableEphemeralVolumes`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 의해 제어된다.
+`immutable` 필드를 `true` 로 설정하여 변경할 수 없는 컨피그맵을 생성할 수 있다.
+다음은 예시이다.
 
-이 기능을 사용하려면 `ImmutableEphemeralVolumes`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
-시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -238,16 +263,15 @@ immutable: true
 ```
 
 {{< note >}}
-컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나
-`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다.
-기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는
-것을 권장한다.
+컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
+삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
+유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
 {{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
-
-* [시크릿](/docs/concepts/configuration/secret/)에 대해 읽어본다.
+* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 읽어본다.
 * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다.
 * 코드를 구성에서 분리하려는 동기를 이해하려면
   [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.
diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md
index 99e5c27298..1f01481270 100644
--- a/content/ko/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md
@@ -47,6 +47,13 @@ feature:
 또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다
 다른 방식으로 동일한 제약을 구현할 수 있다.
 
+{{< note >}}
+컨테이너가 자체 메모리 제한을 지정하지만, 메모리 요청을 지정하지 않는 경우, 쿠버네티스는
+제한과 일치하는 메모리 요청을 자동으로 할당한다. 마찬가지로, 컨테이너가 자체 CPU 제한을
+지정하지만, CPU 요청을 지정하지 않는 경우, 쿠버네티스는 제한과 일치하는 CPU 요청을 자동으로
+할당한다.
+{{< /note >}}
+
 ## 리소스 타입
 
 *CPU* 와 *메모리* 는 각각 *리소스 타입* 이다. 리소스 타입에는 기본 단위가 있다.
@@ -112,7 +119,7 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
 
 `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
 E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를
-일반 정수 또는 고정 소수점 정수로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
+일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
 
 ```shell
@@ -134,7 +141,6 @@ spec:
   containers:
   - name: app
     image: images.my-company.example/app:v4
-    env:
     resources:
       requests:
         memory: "64Mi"
@@ -311,7 +317,7 @@ _임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수
 * `spec.containers[].resources.requests.ephemeral-storage`
 
 `ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와
-같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 정수로 표현할 수 있다.
+같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
 Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
 예를 들어, 다음은 대략 동일한 값을 나타낸다.
 
diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md
index eb7aa1ff93..5e2047b367 100644
--- a/content/ko/docs/concepts/configuration/overview.md
+++ b/content/ko/docs/concepts/configuration/overview.md
@@ -101,4 +101,4 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 
 - `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/ko/docs/concepts/cluster-administration/manage-deployment/#효과적인-레이블-사용)를 참고할 수 있다.
 
-- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
+- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl create deployment` 와 `kubectl expose` 를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md
index da165814da..28867b4066 100644
--- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md
@@ -8,7 +8,7 @@ weight: 70
 
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
-[파드](/ko/docs/concepts/workloads/pods/pod/)는 _우선순위_ 를 가질 수 있다. 우선순위는
+[파드](/ko/docs/concepts/workloads/pods/)는 _우선순위_ 를 가질 수 있다. 우선순위는
 다른 파드에 대한 상대적인 파드의 중요성을 나타낸다. 파드를 스케줄링할 수 없는 경우,
 스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를
 스케줄링할 수 있게 한다.
@@ -48,40 +48,6 @@ weight: 70
 이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
 {{< /note >}}
 
-## 선점을 비활성화하는 방법
-
-{{< caution >}}
-중요 파드는 클러스터에 리소스 압박(resource pressure)이 가해지면
-스케줄러 선점에 따라 스케줄링된다. 이런 이유로, 선점을 비활성화하지
-않는 것을 권장한다.
-{{< /caution >}}
-
-{{< note >}}
-쿠버네티스 1.15 이상에서, `NonPreemptingPriority` 기능이 활성화된 경우,
-프라이어리티클래스는 옵션을 `preemptionPolicy: Never` 로 설정할 수 있다.
-이렇게 하면 해당 프라이어리티클래스의 파드가 다른 파드를 축출할 수 없다.
-{{< /note >}}
-
-선점은 기본값이 `false`로 설정된 `disablePreemption` kube-scheduler
-플래그에 의해 제어된다.
-위의 주의에도 불구하고 선점을 비활성화하려는 경우,
-`disablePreemption` 을 `true` 로 설정할 수 있다.
-
-이 옵션은 컴포넌트 구성에서만 사용할 수 있으며
-이전 스타일의 커맨드 라인 옵션에서는 사용할 수 없다. 다음은 선점을 비활성화하는 샘플 컴포넌트
-구성이다.
-
-```yaml
-apiVersion: kubescheduler.config.k8s.io/v1alpha1
-kind: KubeSchedulerConfiguration
-algorithmSource:
-  provider: DefaultProvider
-
-...
-
-disablePreemption: true
-```
-
 ## 프라이어리티클래스
 
 프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을
@@ -135,7 +101,7 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사
 
 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
 
-{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 `PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
 앞쪽에 배치되지만,
@@ -159,10 +125,6 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사
 `PreemptionPolicy` 가 `Never` 로 설정된 경우,
 해당 프라이어리티클래스의 파드는 비-선점될 것이다.
 
-`PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
-활성화되어야 한다.
-
 예제 유스케이스는 데이터 과학 관련 워크로드이다.
 사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만,
 실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다.
@@ -306,7 +268,7 @@ spec:
 *   파드 P는 노드 N에 대해 고려된다.
 *   파드 Q는 노드 N과 동일한 영역의 다른 노드에서 실행 중이다.
 *   파드 P는 파드 Q(`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`)와 영역(zone) 전체의 안티-어피니티를 갖는다.
+    topology.kubernetes.io/zone`)와 영역(zone) 전체의 안티-어피니티를 갖는다.
 *   영역에서 파드 P와 다른 파드 간의 안티-어피니티에 대한 다른 경우는
     없다.
 *   노드 N에서 파드 P를 스케줄링하기 위해, 파드 Q를 축출할 수 있지만, 스케줄러는
diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md
index 5b95d9a484..a934d173d1 100644
--- a/content/ko/docs/concepts/configuration/secret.md
+++ b/content/ko/docs/concepts/configuration/secret.md
@@ -35,6 +35,12 @@ weight: 30
 - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
 
+시크릿 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
+
+`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로
+구성되어야 한다.
+
 ### 빌트인 시크릿
 
 #### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함
@@ -50,399 +56,15 @@ weight: 30
 서비스 어카운트 작동 방식에 대한 자세한 내용은
 [서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다.
 
-### 자신만의 시크릿 생성하기
+### 시크릿 생성하기
 
-#### `kubectl` 사용하여 시크릿 생성하기
+시크릿을 생성하기 위한 몇 가지 옵션이 있다.
 
-시크릿에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다.
-예를 들어, 데이터베이스 연결 문자열은
-사용자명(username)과 비밀번호(password)로 구성된다. 사용자명은 `./username.txt` 파일에
-저장하고 비밀번호는 로컬 시스템의 `./password.txt` 파일에 저장할 수 있다.
+- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
 
-```shell
-# 예제를 위해서 필요한 파일들을 생성한다.
-echo -n 'admin' > ./username.txt
-echo -n '1f2d1e2e67df' > ./password.txt
-```
-
-`kubectl create secret` 명령은 이러한 파일을 시크릿으로 패키징하고
-API 서버에 오브젝트를 생성한다.
-시크릿 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-
-```shell
-kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret "db-user-pass" created
-```
-
-기본 키 이름은 파일명(filename)이다. 선택적으로 `--from-file=[key=]source]` 를 사용하여 키 이름을 설정할 수 있다.
-
-```shell
-kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
-```
-
-{{< note >}}
-`$`, `\`, `*`, `=`, 그리고 `!` 등의 특수 문자는 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다.
-대부분의 셸에서, 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다.
-예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다.
-
-```shell
-kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
-```
-
-파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다.
-{{< /note >}}
-
-다음의 명령으로 시크릿이 생성되었는지 확인할 수 있다.
-
-```shell
-kubectl get secrets
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-NAME                  TYPE                                  DATA      AGE
-db-user-pass          Opaque                                2         51s
-```
-
-시크릿에 대한 설명을 볼 수 있다.
-
-```shell
-kubectl describe secrets/db-user-pass
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-{{< note >}}
-`kubectl get` 명령과 `kubectl describe` 명령은 기본적으로 시크릿의 내용을 표시하지
-않는다. 이는 시크릿이 우연히 다른 사람에게 노출되거나,
-터미널 로그에 저장되지 않도록 보호하기 위함이다.
-{{< /note >}}
-
-시크릿 내용을 보는 방법을 익히기 위해서는 [시크릿 디코딩하기](#시크릿-디코딩하기)를 참고한다.
-
-#### 수동으로 시크릿 생성하기
-
-먼저 JSON 또는 YAML 형식으로 파일에 시크릿을 생성한
-다음 해당 오브젝트를 생성할 수도 있다.
-시크릿 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)은
-두 개의 맵(`data` 와 `stringData`)을
-포함한다. `data` 필드는 base64를 사용하여, 인코딩된 임의 데이터를 저장하는 데
-사용된다. `stringData` 필드는 편의를 위해 제공되며, 시크릿 데이터를 인코딩되지 않은
-문자열로 제공할 수 있다.
-
-예를 들어, `data` 필드를 사용하여 시크릿에 두 개의 문자열을 저장하려면, 다음과 같이
-문자열을 base64로 변환한다.
-
-```shell
-echo -n 'admin' | base64
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-YWRtaW4=
-```
-
-```shell
-echo -n '1f2d1e2e67df' | base64
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-MWYyZDFlMmU2N2Rm
-```
-
-다음과 같은 시크릿을 작성한다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-이제 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 사용하여 시크릿을 생성한다.
-
-```shell
-kubectl apply -f ./secret.yaml
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret "mysecret" created
-```
-
-특정 시나리오의 경우, `stringData` 필드를 대신 사용할 수 있다. 이
-필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며,
-시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다.
-
-이에 대한 실질적인 예는 애플리케이션 배포 시에
-구성 파일 저장을 위해서 시크릿을 사용하되, 배포 프로세스 중에 해당 구성 파일의
-일부를 채우려는 경우이다.
-
-예를 들어, 애플리케이션이 다음 구성 파일을 사용하는 경우,
-
-```yaml
-apiUrl: "https://my.api.com/api/v1"
-username: "user"
-password: "password"
-```
-
-다음 정의를 사용하여 이를 시크릿에 저장할 수 있다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-stringData:
-  config.yaml: |-
-    apiUrl: "https://my.api.com/api/v1"
-    username: {{username}}
-    password: {{password}}
-```
-
-그런 다음 `kubectl apply` 를 실행하기 전에 배포 도구로
-`{{username}}` 및 `{{password}}` 템플릿 변수를 바꿀 수 있다.
-
-`stringData` 필드는 쓰기 전용의 편의 필드이다. 이 내용은 시크릿을
-검색할 때 출력되지 않는다. 예를 들어, 다음 명령을 실행해본다.
-
-```shell
-kubectl get secret mysecret -o yaml
-```
-
-출력 결과는 다음과 비슷하다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2018-11-15T20:40:59Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7225"
-  uid: c280ad2e-e916-11e8-98f2-025000000001
-type: Opaque
-data:
-  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
-```
-
-`username` 과 같은 필드가 `data` 와 `stringData` 모두에 지정되면,
-`stringData` 의 값이 사용된다. 예를 들어, 다음의 시크릿 정의를 보자.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-data:
-  username: YWRtaW4=
-stringData:
-  username: administrator
-```
-
-아래의 시크릿에서 결과는 다음과 같다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2018-11-15T20:46:46Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7579"
-  uid: 91460ecb-e917-11e8-98f2-025000000001
-type: Opaque
-data:
-  username: YWRtaW5pc3RyYXRvcg==
-```
-
-위의 `YWRtaW5pc3RyYXRvcg==` 를 디코딩하면 `administrator` 가 된다.
-
-`data` 와 `stringData` 의 키는 영숫자,
-'-', '_' 또는 '.'로 구성되어야 한다.
-
-{{< note >}}
-시크릿 데이터의 직렬화된 JSON 및 YAML 값은
-base64 문자열로 인코딩된다. 줄바꿈은 이러한 문자열 내에서 유효하지 않으므로
-생략해야 한다. Darwin/macOS에서 `base64` 유틸리티를 사용할 때,
-사용자는 긴 라인을 분할하는 `-b` 옵션을 사용하면 안된다. 반대로, 리눅스 사용자는
-`-w` 옵션을 사용할 수 없는 경우 `base64` 명령이나 `base64 | tr -d '\n'` 파이프라인에
-`-w 0` 옵션을 추가 *해야 한다*.
-{{< /note >}}
-
-#### 생성기를 통해 시크릿 생성하기
-
-쿠버네티스 v1.14부터 `kubectl` 은 [Kustomize를 사용한 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. Kustomize는 시크릿과 컨피그맵(ConfigMap)을 생성하기 위한
-리소스 생성기를 제공한다. Kustomize 생성기는 디렉터리 내의
-`kustomization.yaml` 파일에 지정되어야 한다. 시크릿을 생성한 후,
-`kubectl apply` 를 사용하여 API 서버에서 시크릿을 만들 수 있다.
-
-#### 파일을 통해 시크릿 생성하기
-
-./username.txt 와 ./password.txt 파일에서
-`secretGenerator` 를 정의하여 시크릿을 생성할 수 있다.
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
-- name: db-user-pass
-  files:
-  - username.txt
-  - password.txt
-EOF
-```
-
-`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
-
-```shell
-kubectl apply -k .
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret/db-user-pass-96mffmfh4k created
-```
-
-시크릿이 생성되었는지 다음의 명령으로 확인할 수 있다.
-
-```shell
-kubectl get secrets
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-NAME                             TYPE                                  DATA      AGE
-db-user-pass-96mffmfh4k          Opaque                                2         51s
-```
-
-```shell
-kubectl describe secrets/db-user-pass-96mffmfh4k
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-#### 문자열 리터럴(literals)을 통해 시크릿 생성하기
-
-문자열 리터럴인 `username=admin` 과 `password=secret` 을
-`secretGenerator` 에 정의하여 시크릿을 만들 수 있다.
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
-- name: db-user-pass
-  literals:
-  - username=admin
-  - password=secret
-EOF
-```
-
-`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
-
-```shell
-kubectl apply -k .
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-secret/db-user-pass-dddghtt9b5 created
-```
-
-{{< note >}}
-시크릿이 생성될 때, 시크릿의 이름은 시크릿 데이터를
-해시하고, 해시된 값을 이름에 추가하는 방식으로 만들어진다. 이 방식은
-데이터가 수정될 때마다 새로운 시크릿이 생성되도록 만든다.
-{{< /note >}}
-
-#### 시크릿 디코딩하기
-
-`kubectl get secret` 을 실행하여 시크릿을 검색할 수 있다.
-예를 들어, 다음 명령을 실행하여 이전 섹션에서
-생성된 시크릿을 볼 수 있다.
-
-```shell
-kubectl get secret mysecret -o yaml
-```
-
-출력 결과는 다음과 비슷하다.
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2016-01-22T18:41:56Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "164619"
-  uid: cfee02d6-c137-11e5-8d73-42010af00002
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-`password` 필드를 디코딩한다.
-
-```shell
-echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-1f2d1e2e67df
-```
-
-#### 시크릿 편집하기
+### 시크릿 편집하기
 
 기존 시크릿은 다음 명령을 사용하여 편집할 수 있다.
 
@@ -713,37 +335,6 @@ kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신
 받지 않는다.
 {{< /note >}}
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
-
-쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은
-개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
-클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
-다음과 같은 이점이 있다.
-
-- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
-- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
-크게 줄임으로써 클러스터의 성능을 향상시킴
-
-이 기능을 사용하려면, `ImmutableEphemeralVolumes`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
-시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  ...
-data:
-  ...
-immutable: true
-```
-
-{{< note >}}
-시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
-`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
-기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
-권장한다.
-{{< /note >}}
-
 ### 시크릿을 환경 변수로 사용하기
 
 파드에서 {{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}에
@@ -804,6 +395,40 @@ echo $SECRET_PASSWORD
 1f2d1e2e67df
 ```
 
+## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
+개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
+클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
+다음과 같은 이점이 있다.
+
+- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
+- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
+크게 줄임으로써 클러스터의 성능을 향상시킴
+
+이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
+게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
+의해 제어된다. `immutable` 필드를 `true` 로 설정하여
+변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
+기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
+권장한다.
+{{< /note >}}
+
 ### imagePullSecrets 사용하기
 
 `imagePullSecrets` 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다.
@@ -1000,6 +625,8 @@ kubectl create secret generic prod-db-secret --from-literal=username=produser --
 secret "prod-db-secret" created
 ```
 
+테스트 환경의 자격 증명에 대한 시크릿을 만들 수도 있다.
+
 ```shell
 kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
 ```
@@ -1266,3 +893,10 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
    API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
    영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
    기능이다.
+
+
+## {{% heading "whatsnext" %}}
+
+- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
+- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
+- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md
index 76b1756a19..fa56660f1a 100755
--- a/content/ko/docs/concepts/containers/_index.md
+++ b/content/ko/docs/concepts/containers/_index.md
@@ -28,7 +28,7 @@ no_list: true
 
 설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를
 변경할 수 없다. 컨테이너화된 애플리케이션이 있고
-변경하려는 경우, 변경 사항이 포함된 새 컨테이너를 빌드한
+변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한
 다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다.
 
 ## 컨테이너 런타임
diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
index 0fe4bb9b9d..662ac71522 100644
--- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
@@ -6,7 +6,7 @@ weight: 30
 
 <!-- overview -->
 
-이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서 
+이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서
 컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다.
 
 
@@ -16,9 +16,9 @@ weight: 30
 
 ## 개요
 
-Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게, 
+Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게,
 쿠버네티스도 컨테이너에 라이프사이클 훅을 제공한다.
-훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는 
+훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는
 라이프사이클 훅이 실행될 때 핸들러에 구현된 코드를 실행할 수 있게 한다.
 
 ## 컨테이너 훅
@@ -33,12 +33,12 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 
 `PreStop`
 
-이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다. 
-그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로, 
-컨테이너를 삭제하기 위한 호출이 전송되기 전에 완료되어야한다.
+이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
+그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
+컨테이너를 중지하기 위한 신호가 전송되기 전에 완료되어야 한다.
 파라미터는 핸들러에 전달되지 않는다.
 
-종료 동작에 더 자세한 대한 설명은 
+종료 동작에 더 자세한 대한 설명은
 [파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다.
 
 ### 훅 핸들러 구현
@@ -52,34 +52,46 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 
 ### 훅 핸들러 실행
 
-컨테이너 라이프사이클 관리 훅이 호출되면, 
-쿠버네티스 관리 시스템은 해당 훅이 등록된 컨테이너에서 핸들러를 실행한다.
+컨테이너 라이프사이클 관리 훅이 호출되면,
+쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
+`exec` 와 `tcpSocket` 은 컨테이너에서 실행되고, `httpGet` 은 kubelet 프로세스에 의해 실행된다.
 
-훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 맥락과 동기적으로 동작한다. 
-이것은 `PostStart` 훅에 대해서, 
+훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
+이것은 `PostStart` 훅에 대해서,
 훅이 컨테이너 엔트리포인트와는 비동기적으로 동작함을 의미한다.
-그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면, 
+그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
 컨테이너는 `running` 상태에 이르지 못한다.
 
-이러한 동작은 `PreStop` 훅에 대해서도 비슷하게 일어난다.
-만약 훅이 실행되던 도중에 매달려 있다면, 
-파드의 단계(phase)는 `Terminating` 상태에 머물고 해당 훅은 파드의 `terminationGracePeriodSeconds`가 끝난 다음에 종료된다.
+`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로
+실행되지 않는다. 훅은 신호를 보내기 전에 실행을
+완료해야 한다.
+실행 중에 `PreStop` 훅이 중단되면,
+파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가
+만료된 후 파드가 종료될 때까지 남아 있다.
+이 유예 기간은 `PreStop` 훅이 실행되고 컨테이너가
+정상적으로 중지되는 데 걸리는 총 시간에 적용된다.
+예를 들어, `terminationGracePeriodSeconds` 가 60이고, 훅이
+완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후
+정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
+컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데
+걸리는 총 시간(55+10)보다 적다.
+
 만약 `PostStart` 또는 `PreStop` 훅이 실패하면,
 그것은 컨테이너를 종료시킨다.
 
 사용자는 훅 핸들러를 가능한 한 가볍게 만들어야 한다.
-그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이, 
+그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이,
 오래 동작하는 커맨드가 의미 있는 경우도 있다.
 
 ### 훅 전달 보장
 
-훅 전달은 *한 번 이상* 으로 의도되어 있는데, 
-이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서, 
+훅 전달은 *한 번 이상* 으로 의도되어 있는데,
+이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서,
 훅이 여러 번 호출될 수 있다는 것을 의미한다.
 이것을 올바르게 처리하는 것은 훅의 구현에 달려 있다.
 
 일반적으로, 전달은 단 한 번만 이루어진다.
-예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도, 
+예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도,
 재전송을 시도하지 않는다.
 그러나, 드문 경우로, 이중 전달이 발생할 수 있다.
 예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
@@ -88,8 +100,8 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
 ### 디버깅 훅 핸들러
 
 훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
-만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다. 
-`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며, 
+만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
+`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
 `PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
 이 이벤트는 `kubectl describe pod <파드_이름>`를 실행하면 볼 수 있다.
 다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
@@ -117,5 +129,3 @@ Events:
 * [컨테이너 환경](/ko/docs/concepts/containers/container-environment/)에 대해 더 배우기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
   실습 경험하기.
-
-
diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
index f17841027b..497f4cbfda 100644
--- a/content/ko/docs/concepts/containers/images.md
+++ b/content/ko/docs/concepts/containers/images.md
@@ -94,7 +94,7 @@ weight: 10
 이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다.
 
 {{< note >}}
-쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다.
+기본 쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다.
 도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다.
 {{< /note >}}
 
@@ -262,7 +262,7 @@ EOF
 
 이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다.
 
-그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-accounts/)) 리소스에
+그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 리소스에
 imagePullSecrets을 셋팅하여 자동화할 수 있다.
 
 자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다.
diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md
index 3da41dfde0..315b83ce99 100644
--- a/content/ko/docs/concepts/containers/runtime-class.md
+++ b/content/ko/docs/concepts/containers/runtime-class.md
@@ -77,7 +77,7 @@ handler: myconfiguration  # 상응하는 CRI 설정의 이름임
 {{< note >}}
 런타임클래스 쓰기 작업(create/update/patch/delete)은
 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
-더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
+더 자세한 정보는 [권한 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참고한다.
 {{< /note >}}
 
 ## 사용
@@ -178,7 +178,7 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc
 ## {{% heading "whatsnext" %}}
 
 
-- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
-- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
 - [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md
index e6d64bdfb7..ec09e00446 100644
--- a/content/ko/docs/concepts/extend-kubernetes/_index.md
+++ b/content/ko/docs/concepts/extend-kubernetes/_index.md
@@ -91,7 +91,7 @@ kubectl에서
 
 1.   사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
 2.   apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
-3.   apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
+3.   apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
 4.   쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
 5.   쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
 6.   kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
@@ -126,7 +126,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 
 ### API 접근 익스텐션
 
-요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
+요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
 
 이러한 각 단계는 익스텐션 포인트를 제공한다.
 
diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index fd8f2c0107..7e8a10e8b1 100644
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -7,7 +7,7 @@ weight: 10
 <!-- overview -->
 
 애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
-추가 API는 [서비스-카탈로그](/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
+추가 API는 [서비스-카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
 
 애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다.
 
@@ -31,6 +31,6 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경
 ## {{% heading "whatsnext" %}}
 
 * 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
-* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
+* 다음에, [확장 API 서버를 구성해서](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
 * 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.
 * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다.
diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 18b98db97c..f4301e2933 100644
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -96,7 +96,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
 * 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다.
 
 {{< note >}}
-민감한 데이터에는 [시크릿](/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다.
+민감한 데이터에는 [시크릿](/ko/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다.
 {{< /note >}}
 
 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 2c57af0b5d..70a7d1ea27 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -45,7 +45,7 @@ service Registration {
 해당 자원을 API 서버에 알리는 역할을 한다.
 예를 들어, 장치 플러그인이 kubelet에 `hardware-vendor.example/foo` 를 등록하고
 노드에 두 개의 정상 장치를 보고하고 나면, 노드 상태가 업데이트되어
-노드에 2개의 “Foo” 장치가 설치되어 사용 가능함을 알릴 수 있다.
+노드에 2개의 "Foo" 장치가 설치되어 사용 가능함을 알릴 수 있다.
 
 그러고 나면, 사용자가
 [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 명세에 있는 장치를 요청할 수 있다.
@@ -91,6 +91,9 @@ spec:
 
   ```gRPC
   service DevicePlugin {
+		    // GetDevicePluginOptions는 장치 관리자와 통신할 옵션을 반환한다.
+        rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
+
     		// ListAndWatch는 장치 목록 스트림을 반환한다.
 		    // 장치 상태가 변경되거나 장치가 사라질 때마다, ListAndWatch는
 		    // 새 목록을 반환한다.
@@ -100,10 +103,31 @@ spec:
 				// 플러그인이 장치별 작업을 실행하고 Kubelet에 장치를
 				// 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다.
         rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
+
+        // GetPreferredAllocation은 사용 가능한 장치 목록에서 할당할
+				// 기본 장치 집합을 반환한다. 그 결과로 반환된 선호하는 할당은
+				// devicemanager가 궁극적으로 수행하는 할당이 되는 것을 보장하지
+				// 않는다. 가능한 경우 devicemanager가 정보에 입각한 할당 결정을
+				// 내릴 수 있도록 설계되었다.
+        rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
+
+        // PreStartContainer는 등록 단계에서 장치 플러그인에 의해 표시되면 각 컨테이너가
+				// 시작되기 전에 호출된다. 장치 플러그인은 장치를 컨테이너에서 사용할 수 있도록 하기 전에
+				// 장치 재설정과 같은 장치별 작업을 실행할 수 있다.
+        rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
   }
   ```
 
-*	플러그인은 호스트 경로 `/var/lib/kubelet/device-plugins/kubelet.sock` 에서
+  {{< note >}}
+  `GetPreferredAllocation()` 또는 `PreStartContainer()` 에 대한 유용한 구현을
+  제공하기 위해 플러그인이 필요하지 않다. 이러한 호출(있는 경우) 중
+  사용할 수 있는 경우를 나타내는 플래그는 `GetDevicePluginOptions()`
+  호출에 의해 다시 전송된 `DevicePluginOptions` 메시지에 설정되어야 한다. `kubelet` 은
+  항상 `GetDevicePluginOptions()` 를 호출하여 사용할 수 있는
+  선택적 함수를 확인한 후 직접 호출한다.
+  {{< /note >}}
+
+* 플러그인은 호스트 경로 `/var/lib/kubelet/device-plugins/kubelet.sock` 에서
   유닉스 소켓을 통해 kubelet에 직접 등록한다.
 
 * 성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를
@@ -183,7 +207,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 
 
 ## 토폴로지 관리자와 장치 플러그인 통합
 
-{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 토폴로지 관리자는 Kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. 이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다.
 
@@ -229,4 +253,6 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 * 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
 * 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
-* [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기
+* [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
+
+
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index df26abccc5..76c2bdd003 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -7,21 +7,17 @@ weight: 10
 
 <!-- overview -->
 
-{{< feature-state state="alpha" >}}
-{{< caution >}}알파 기능은 빨리 변경될 수 있다. {{< /caution >}}
-
 쿠버네티스의 네트워크 플러그인은 몇 가지 종류가 있다.
 
-* CNI 플러그인: 상호 운용성을 위해 설계된 appc/CNI 명세를 준수한다.
+* CNI 플러그인: 상호 운용성을 위해 설계된 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 명세를 준수한다.
+* 쿠버네티스는 CNI 명세의 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 릴리스를 따른다.
 * Kubenet 플러그인: `bridge` 와 `host-local` CNI 플러그인을 사용하여 기본 `cbr0` 구현한다.
 
-
-
 <!-- body -->
 
 ## 설치
 
-kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(rkt는 자체 CNI 플러그인을 관리하므로 Docker에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
+kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
 
 * `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
 * `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 단순히 "cni"이다.
@@ -30,7 +26,7 @@ kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에
 
 파드 네트워킹을 구성하고 정리하기 위해 [`NetworkPlugin` 인터페이스](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
 
-kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 Docker 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
+kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
 
 ### CNI
 
@@ -146,7 +142,7 @@ Kubenet은 `cbr0` 라는 리눅스 브리지를 만들고 각 쌍의 호스트 
 
 최상의 네트워킹 성능을 얻으려면 MTU를 항상 올바르게 구성해야 한다. 네트워크 플러그인은 일반적으로 합리적인 MTU를
 유추하려고 시도하지만, 때로는 로직에 따라 최적의 MTU가 지정되지 않는다. 예를 들어,
-Docker 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
+도커 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
 IPSEC 캡슐화를 사용하는 경우, MTU를 줄여야 하며, 이 계산은 대부분의
 네트워크 플러그인에서 범위를 벗어난다.
 
@@ -161,10 +157,3 @@ AWS에서 `eth0` MTU는 일반적으로 9001이므로, `--network-plugin-mtu=900
 * `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
 * `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge` 및 `host-local` 플러그인과 함께 kubenet 네트워크 플러그인을 사용하도록 지정한다.
 * 현재 kubenet 네트워크 플러그인에서만 사용하는 `--network-plugin-mtu=9001` 은 사용할 MTU를 지정한다.
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-
diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
index 8a98d9bd28..3fe6451755 100644
--- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -92,8 +92,8 @@ kubectl에서
 
 1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
 2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
-3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
-4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다.
+3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
+4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/#스케줄러-익스텐션) 섹션에 설명되어 있다.
 5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
 6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
 7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
@@ -127,7 +127,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 
 ### API 접근 익스텐션
 
-요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
+요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다.
 
 이러한 각 단계는 익스텐션 포인트를 제공한다.
 
diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md
index bcd9bb9945..f6c80d8067 100644
--- a/content/ko/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ko/docs/concepts/extend-kubernetes/operator.md
@@ -9,7 +9,7 @@ weight: 30
 오퍼레이터(Operator)는
 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를
 사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는
-쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다.
+쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/architecture/controller/)를 따른다.
 
 <!-- body -->
 
@@ -122,10 +122,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
   * [kubebuilder](https://book.kubebuilder.io/) 사용하기
   * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
     사용하여 직접 구현하기
-  * [오퍼레이터 프레임워크](https://github.com/operator-framework/getting-started) 사용하기
+  * [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
 * 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기
 * 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기
-
-
-
diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md
index 0b3df10062..353b222785 100755
--- a/content/ko/docs/concepts/overview/_index.md
+++ b/content/ko/docs/concepts/overview/_index.md
@@ -2,4 +2,6 @@
 title: "개요"
 weight: 20
 description: 쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다.
+sitemap:
+  priority: 0.9
 ---
diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md
index ace13900c6..d4b77e9319 100644
--- a/content/ko/docs/concepts/overview/components.md
+++ b/content/ko/docs/concepts/overview/components.md
@@ -5,7 +5,7 @@ description: >
   쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인
   컴포넌트로 구성된다.
 weight: 20
-card: 
+card:
   name: concepts
   weight: 20
 ---
@@ -19,7 +19,7 @@ card:
 
 여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다.
 
-![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.png)
+![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.svg)
 
 
 
diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md
index 8ce410330c..65662da9d0 100644
--- a/content/ko/docs/concepts/overview/kubernetes-api.md
+++ b/content/ko/docs/concepts/overview/kubernetes-api.md
@@ -3,7 +3,7 @@ title: 쿠버네티스 API
 content_type: concept
 weight: 30
 description: >
-  쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다. 
+  쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다.
   쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다.
 card:
   name: concepts
@@ -20,24 +20,17 @@ card:
 쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
 
-API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다.
+대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
+커맨드 라인 인터페이스 또는 API를 사용하는
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과
+같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
+그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
+
+쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우
+[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다.
 
 <!-- body -->
 
-## API 변경
-
-새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다.
-따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다.
-쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_,
-다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다.
-
-일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다.
-리소스나 필드를 없애는 일은 다음의
-[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다.
-
-호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은
-[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다.
-
 ## OpenAPI 명세 {#api-specification}
 
 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
@@ -46,6 +39,7 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
 다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다.
 
 <table>
+  <caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
   <thead>
      <tr>
         <th>Header</th>
@@ -73,99 +67,69 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
         <td><em>serves </em><code>application/json</code></td>
      </tr>
   </tbody>
-  <caption>Valid request header values for OpenAPI v2 queries</caption>
 </table>
 
-쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다.
+쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
+Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
+자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과
+API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
+IDL(인터페이스 정의 언어) 파일을 참고한다.
 
-## API 버전 규칙
+## API 변경 사항
 
-필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
-쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
-각각 다른 API 경로에서 복수의 API 버전을 지원한다.
+성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
+따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
+쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
+적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
 
-버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를
-제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록
-리소스 또는 필드 수준이 아닌 API 수준에서 수행된다.
+일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
+리소스 또는 필드를 제거하려면
+[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
 
-JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다.
+호환 가능한 변경 사항과 API 변경 방법은
+[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.
 
-참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다.
-[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
-제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다.
+## API 그룹과 버전 규칙
 
-API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은
-[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
-상세히 다룬다. 요약하자면 다음과 같다.
+필드를 쉽게 제거하거나 리소스 표현을 재구성하기 위해,
+쿠버네티스는 각각 `/api/v1` 또는 `/apis/rbac.authorization.k8s.io/v1alpha1` 과
+같은 서로 다른 API 경로에서 여러 API 버전을 지원한다.
 
-- 알파(Alpha) 수준:
-  - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
-  - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
-  - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
-  - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
-  - 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
-- 베타(Beta) 수준:
-  - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
-  - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
-  - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
-  - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우,
-    다음 버전으로 이관할 수 있는 가이드를 제공할 것이다.
-    이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
-  - 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다.
-    복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다.
-  - **베타 기능을 사용하고 피드백을 주기를 바란다! 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.**
-- 안정화(stable) 수준:
-  - 버전 이름이 `vX`이고 `X` 는 정수다.
-  - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
+버전 규칙은 리소스나 필드 수준이 아닌 API 수준에서 수행되어
+API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제공하고
+수명 종료 및/또는 실험적 API에 대한 접근을
+제어할 수 있도록 한다.
 
-## API 그룹
+보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는
+[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가
+가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다.
 
-쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다.
-API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
+API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
+(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
+기본 데이터를 제공하고 API 버전 간의 변환을 투명하게
+처리할 수 있다. 이 모든 다른 버전은 실제로
+동일한 리소스의 표현이다. 예를 들어, 동일한 리소스에 대해 두 가지
+버전 `v1` 과 `v1beta1` 이 있다고 가정한다. 그런 다음 `v1beta1` 버전에서
+생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 읽고 업데이트하고
+삭제할 수 있다.
 
-클러스터에 다양한 API 그룹이 있다.
+API 버전 수준 정의에 대한 자세한 내용은
+[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.
 
-1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다.
+## API 확장
 
-1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
-  (예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은
-  [쿠버네티스 API 참조](/ko/docs/reference/)에 있다.
-
-
-[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다.
-
-1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은
-   API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
-1. 또한, [자신의 확장 API 서버 구현](/docs/tasks/extend-kubernetes/setup-extension-api-server/)과
-   [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를
-   사용해서 클라이언트를 원활하게 만들 수 있다.
-
-
-## API 그룹 활성화 또는 비활성화하기
-
-특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를
-설정해서 활성화하거나 비활성화할 수 있다.
-
-`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면,
-`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을
-설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
-
-{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와
-controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}}
-
-## 지속성
-
-쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에
-기록하고 저장한다.
+쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
 
+1. [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를
+   사용하면 API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
+1. [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
+   구현하여 쿠버네티스 API를 확장할 수도 있다.
 
 ## {{% heading "whatsnext" %}}
 
-[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가
-API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다.
-
-전체 API 규약은
-[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
-문서에 설명되어 있다.
-
-API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다.
+- 자체 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)을
+  추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기.
+- [API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)는
+  클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
+- [API 레퍼런스](/docs/reference/kubernetes-api/)를
+  읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md
index ad083dd49d..7d6c8c1f0e 100644
--- a/content/ko/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md
@@ -7,6 +7,8 @@ weight: 10
 card:
   name: concepts
   weight: 10
+sitemap:
+  priority: 0.9
 ---
 
 <!-- overview -->
diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md
index 96db884a4f..944d7340ba 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md
@@ -63,7 +63,7 @@ weight: 50
 
 ## 문법과 캐릭터 셋
 
-_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 하위 도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
+_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 서브도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
 
 접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :`kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.
 
diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md
index 8abdacb09d..b67a524a7f 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md
@@ -58,15 +58,15 @@ metadata:
 
 ## 애플리케이션과 애플리케이션 인스턴스
 
-애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에
-한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가
-설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다.
+애플리케이션은 동일한 쿠버네티스 클러스터에, 
+심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
+워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
 
-애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다.
-예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 
-`app.kubernetes.io/instance` 에 `wordpress-abcxzy` 의 값을 가진다.
-이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다.
-모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
+애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. 
+예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, 
+애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 
+`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 
+식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
 
 ## 예시
 
@@ -170,4 +170,3 @@ metadata:
 
 MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.
 
-
diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md
index a007375673..a6f03a907f 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md
@@ -129,7 +129,7 @@ spec:
 
 ### _집합성 기준_ 요건
 
-_집합성 기준_ 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. `in`,`notin` and `exists`(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,
+_집합성 기준_ 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. `in`,`notin`과 `exists`(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,
 
 ```
 environment in (production, qa)
diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
index 3d11774cce..905375bdc5 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
@@ -24,9 +24,6 @@ weight: 30
 
 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 통해) 여러 사용자 사이에서 나누는 방법이다.
 
-이후 버전의 쿠버네티스에서는 같은 네임스페이스의 오브젝트는 기본적으로
-동일한 접근 제어 정책을 갖게 된다.
-
 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
 여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
 구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을
diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md
index a81038e444..c1e7bc56a9 100644
--- a/content/ko/docs/concepts/policy/pod-security-policy.md
+++ b/content/ko/docs/concepts/policy/pod-security-policy.md
@@ -138,7 +138,7 @@ RBAC 바인딩에 대한 자세한 예는,
 ### 문제 해결
 
 - [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
-[보안 API 포트](/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
+[보안 API 포트](/ko/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
 슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고,
 모든 파드시큐리티폴리시 오브젝트가 허용되며
 사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한
@@ -593,8 +593,11 @@ spec:
 
 ### Seccomp
 
-파드에서 seccomp 프로파일의 사용은 파드시큐리티폴리시의 어노테이션을 통해
-제어할 수 있다. Seccomp는 쿠버네티스의 알파 기능이다.
+쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서
+`seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을
+제어](/docs/tutorials/clusters/seccomp)할 수 있다. 이전 버전에서는, 파드에
+어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여
+이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.
 
 **seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에
 적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은
@@ -607,7 +610,14 @@ spec:
   되었다. 대신 `runtime/default` 사용을 권장한다.
 - `localhost/<path>` - `<seccomp_root>/<path>`에 있는 노드에서 파일을 프로파일로
   지정한다. 여기서 `<seccomp_root>`는 Kubelet의 `--seccomp-profile-root` 플래그를
-  통해 정의된다.
+  통해 정의된다. `--seccomp-profile-root` 플래그가
+  정의되어 있지 않으면, `<root-dir>` 이 `--root-dir` 플래그로
+  지정된 `<root-dir>/seccomp` 기본 경로가 사용된다.
+
+{{< note >}}
+  `--seccomp-profile-root` 플래그는 쿠버네티스 v1.19부터 더 이상 사용되지
+  않는다. 사용자는 기본 경로를 사용하는 것이 좋다.
+{{< /note >}}
 
 **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 파드 seccomp
 어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된
diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md
index 13107a0613..028209a07e 100644
--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.md
@@ -206,6 +206,19 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
 
 쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다.
 
+`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다.
+
+* `pods`
+* `cpu`
+* `memory`
+* `ephemeral-storage`
+* `limits.cpu`
+* `limits.memory`
+* `limits.ephemeral-storage`
+* `requests.cpu`
+* `requests.memory`
+* `requests.ephemeral-storage`
+
 이 예에서는 쿼터 오브젝트를 생성하여 특정 우선 순위의 파드와 일치시킨다.
 예제는 다음과 같이 작동한다.
 
@@ -495,8 +508,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset
 ```
 
 ```shell
-kubectl create deployment nginx --image=nginx --namespace=myspace
-kubectl scale deployment nginx --replicas=2 --namespace=myspace
+kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
 ```
 
 ```shell
diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
index 4694533315..caca717323 100644
--- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -69,17 +69,7 @@ spec:
 ## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
 
 [붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
-표준 레이블 셋이 미리 채워져 있다. 이 레이블들은 다음과 같다.
-
-* [`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-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)
+표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)를 참고한다.
 
 {{< note >}}
 이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
@@ -206,8 +196,8 @@ spec:
 `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값
 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다.
 (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키
-`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고,
-노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와
+`topology.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고,
+노드 N이 키 `topology.kubernetes.io/zone` 와
 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
 파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와
 동일한 영역의 노드에 스케줄되지 않는다.
diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
index a306a26a23..a3bf6a5a25 100644
--- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -77,12 +77,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지
 방법이 있다.
 
-1. [스케줄링 정책](/docs/reference/scheduling/policies)을 사용하면
-   필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
-1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면
-   `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의
-   다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록
-   kube-scheduler를 구성할 수도 있다.
+1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
+1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
 
 
 ## {{% heading "whatsnext" %}}
@@ -93,3 +89,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기
+* 볼륨을 사용하느 파드의 스케줄링에 대해 배우기
+  * [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)
+  * [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/)
+  * [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/)
diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
similarity index 100%
rename from content/ko/docs/concepts/configuration/pod-overhead.md
rename to content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
similarity index 99%
rename from content/ko/docs/concepts/configuration/resource-bin-packing.md
rename to content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
index 998456ca49..b6efd38404 100644
--- a/content/ko/docs/concepts/configuration/resource-bin-packing.md
+++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -168,7 +168,7 @@ Node Score:
 
 intel.com/foo  = resourceScoringFunction((2+2),8)
                =  (100 - ((8-4)*100/8)
-               =  (100 - 25)
+               =  (100 - 50)
                =  50
                =  rawScoringFunction(50)
                = 5
diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
index b564eda5fb..4ed5c58a63 100644
--- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@@ -1,7 +1,7 @@
 ---
 title: 스케줄러 성능 튜닝
 content_type: concept
-weight: 70
+weight: 80
 ---
 
 <!-- overview -->
@@ -46,17 +46,13 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
 
 이를 변경한 후에 다음을 실행해서
+
 ```bash
-kubectl get componentstatuses
-```
-kube-scheduler 컴포넌트가 정상인지 확인할 수 있다. 출력은 다음과 유사하다.
-```
-NAME                 STATUS    MESSAGE             ERROR
-controller-manager   Healthy   ok
-scheduler            Healthy   ok
-...
+kubectl get pods -n kube-system | grep kube-scheduler
 ```
 
+kube-scheduler 컴포넌트가 정상인지 확인할 수 있다.
+
 ## 노드 스코어링(scoring) 임계값 {#percentage-of-nodes-to-score}
 
 스케줄링 성능을 향상시키기 위해 kube-scheduler는 실행 가능한
diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md
index bcbc22d915..af5c9ba574 100644
--- a/content/ko/docs/concepts/security/overview.md
+++ b/content/ko/docs/concepts/security/overview.md
@@ -103,7 +103,7 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
 ------------------------------ | ------------ |
 RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
 인증 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
-애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
 파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
 서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/
@@ -147,7 +147,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 
 * [파드 보안 표준](/docs/concepts/security/pod-security-standards/)
 * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
 * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
-* [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)
+* [API 접근 통제](/ko/docs/reference/access-authn-authz/controlling-access/)
 * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
-* [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)
+* [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md
index 97345c0efb..05f514b26b 100644
--- a/content/ko/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md
@@ -225,7 +225,7 @@ Address 1: 10.0.162.149
 
 * https에 대한 자체 서명한 인증서 (신원 인증서를 가지고 있지 않은 경우)
 * 인증서를 사용하도록 구성된 nginx 서버
-* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/docs/concepts/configuration/secret/)
+* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/)
 
 [nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
 
@@ -419,6 +419,6 @@ LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
 ## {{% heading "whatsnext" %}}
 
 
-* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
+* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
 * [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
 * [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md
index 927201d90c..a7e3336fa2 100644
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@@ -163,6 +163,24 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
 또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
 {{< /note >}}
 
+### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field}
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+**전제 조건**: `SetHostnameAsFQDN` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
+{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
+대해 활성화해야 한다.
+
+파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
+
+파드 명세에서 `setHostnameAsFQDN: true` 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, `hostname` 과 `hostname --fqdn` 은 모두 파드의 FQDN을 반환한다.
+
+{{< note >}}
+리눅스에서, 커널의 호스트네임 필드(`struct utsname` 의 `nodename` 필드)는 64자로 제한된다.
+
+파드에서 이 기능을 사용하도록 설정하고 FQDN이 64자보다 길면, 시작되지 않는다. 파드는 파드 호스트네임과 클러스터 도메인에서 FQDN을 구성하지 못한다거나, FQDN `long-FDQN` 이 너무 길다(최대 64자, 70자 요청인 경우)와 같은 오류 이벤트를 생성하는 `Pending` 상태(`kubectl` 에서 표시하는 `ContainerCreating`)로 유지된다. 이 시나리오에서 사용자 경험을 개선하는 한 가지 방법은 사용자가 최상위 레벨을 오브젝트(예를 들어, 디플로이먼트)를 생성할 때 FQDN 크기를 제어하기 위해 [어드미션 웹훅 컨트롤러](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)를 생성하는 것이다.
+{{< /note >}}
+
 ### 파드의 DNS 정책
 
 DNS 정책은 파드별로 설정할 수 있다.
@@ -188,7 +206,7 @@ DNS 정책은 파드별로 설정할 수 있다.
 
 {{< note >}}
 "Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
-“ClusterFirst”가 기본값으로 사용된다.
+"ClusterFirst"가 기본값으로 사용된다.
 {{< /note >}}
 
 
diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md
index 6efe70de75..844ff7bd2b 100644
--- a/content/ko/docs/concepts/services-networking/dual-stack.md
+++ b/content/ko/docs/concepts/services-networking/dual-stack.md
@@ -43,6 +43,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요
 
    * kube-apiserver:
       * `--feature-gates="IPv6DualStack=true"`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
    * kube-controller-manager:
       * `--feature-gates="IPv6DualStack=true"`
       * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
@@ -104,4 +105,4 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급
 ## {{% heading "whatsnext" %}}
 
 
-* [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹
+* [IPv4/IPv6 이중 스택 확인](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md
index d5f7a2abf3..22af37603a 100644
--- a/content/ko/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md
@@ -1,7 +1,7 @@
 ---
 title: 엔드포인트슬라이스
 content_type: concept
-weight: 15
+weight: 35
 ---
 
 
@@ -21,7 +21,9 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
 
 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
 간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
-서비스가 점점 더 커짐에 따라, 이 API의 한계가 더욱 눈에 띄게 되었다.
+{{< glossary_tooltip text="서비스" term_id="service" >}}가 더 많은 수의 백엔드 파드로
+더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
+되었다.
 특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
 어려움이 있었다.
 
@@ -34,16 +36,17 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
 
 ## 엔드포인트슬라이스 리소스 {#endpointslice-resource}
 
-쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한
+쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
 참조를 포함한다. 쿠버네티스 서비스에 {{< glossary_tooltip text="셀렉터"
-term_id="selector" >}} 가 지정되면 EndpointSlice
-컨트롤러는 자동으로 엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
+term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
+엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
-고유한 서비스와 포트 조합을 통해 네트워크 엔드포인트를 그룹화 한다.
-EndpointSlice 오브젝트의 이름은 유효한
+프로토콜, 포트 번호 및 서비스 이름의 고유한 조합을 통해 네트워크 엔드포인트를
+그룹화한다.
+엔드포인트슬라이스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
-예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 EndpointSlice
+예를 들어, 여기에 `example` 쿠버네티스 서비스를 위한 엔드포인트슬라이스
 리소스 샘플이 있다.
 
 ```yaml
@@ -69,28 +72,30 @@ endpoints:
       topology.kubernetes.io/zone: us-west2-a
 ```
 
-기본적으로, EndpointSlice 컨트롤러가 관리하는 엔드포인트슬라이스에는
-각각 100개 이하의 엔드포인트를 가지고 있다. 이 스케일 아래에서 엔드포인트슬라이스는
-엔드포인트 및 서비스와 1:1로 매핑해야하며, 유사한 성능을 가져야 한다.
+기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
+갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice`
+{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
+플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
 
-엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해 kube-proxy에
+엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
+{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}에
 신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
 서비스에 대해 성능 향상을 제공해야 한다.
 
 ### 주소 유형
 
-EndpointSlice는 다음 주소 유형을 지원한다.
+엔드포인트슬라이스는 다음 주소 유형을 지원한다.
 
 * IPv4
 * IPv6
-* FQDN (Fully Qualified Domain Name)
+* FQDN (전체 주소 도메인 이름)
 
-### 토폴로지
+### 토폴로지 정보 {#토폴로지}
 
 엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
 이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
-엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면
-다음의 토폴로지 레이블이 엔드포인트슬라이스 컨트롤러에 의해 설정된다.
+엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
+컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다.
 
 * `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름.
 * `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름.
@@ -103,37 +108,48 @@ NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
 
 ### 관리
 
-기본적으로 엔드포인트슬라이스는 엔드포인트슬라이스 컨트롤러에의해
-생성되고 관리된다. 서비스 메시 구현과 같은 다른 엔드포인트슬라이스
-유스 케이스는 다른 엔터티나 컨트롤러가 추가 엔드포인트슬라이스
-집합을 관리할 수 있게 할 수 있다. 여러 엔티티가 서로 간섭하지 않고
-엔드포인트슬라이스를 관리할 수 있도록 엔드포인트슬라이스를 관리하는
-엔티티를 나타내는데 `endpointslice.kubernetes.io/managed-by` 레이블이 사용된다.
-엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트
-슬라이스에 레이블의 값으로 `endpointslice-controller.k8s.io` 를 설정한다.
-엔드포인트슬라이스를 관리하는 다른 엔티티도 이 레이블에
-고유한 값을 설정해야 한다.
+대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는
+엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
+엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
+엔드포인트슬라이스에 대한 다양한 다른 유스케이스가 있다.
+
+여러 엔티티가 서로 간섭하지 않고 엔드포인트슬라이스를
+관리할 수 있도록 쿠버네티스는 엔드포인트슬라이스를 관리하는
+엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by`
+{{< glossary_tooltip term_id="label" text="레이블" >}}을
+정의한다.
+엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
+`endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를
+관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.
 
 ### 소유권
 
-대부분의 유스 케이스에서 엔드포인트를 추적하는 서비스가 엔드포인트슬라이스를
-소유한다. 이는 각 엔드포인트슬라이스의 참조와 서비스에 속하는 모든
-엔드포인트슬라이스를 간단하게 조회할 수 있는 `kubernetes.io/service-name`
-레이블로 표시된다.
+대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
+추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
+참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
+`kubernetes.io/service-name` 레이블로 표시된다.
 
-## 엔드포인트슬라이스 컨트롤러
+### 엔드포인트슬라이스 미러링
 
-엔드포인트슬라이스 컨트롤러는 해당 엔드포인트슬라이스가 최신 상태인지
-확인하기 위해 서비스와 파드를 감시한다. 컨트롤러가 셀렉터로 지정한 모든
-서비스에 대해 엔드포인트슬라이스를 관리한다. 이는 서비스 셀렉터와
-일치하는 파드의 IP를 나타내게 된다.
+경우에 따라, 애플리케이션이 사용자 지정 엔드포인트 리소스를 생성한다. 이러한
+애플리케이션이 엔드포인트와 엔드포인트슬라이스 리소스에 동시에 쓸 필요가 없도록
+클러스터의 컨트롤 플레인은 대부분의 엔드포인트 리소스를
+해당 엔드포인트슬라이스에 미러링한다.
 
-### 엔드포인트슬라이스의 크기
+컨트롤 플레인은 다음을 제외하고 엔드포인트 리소스를 미러링한다.
 
-기본적으로 엔드포인트슬라이스는 각각 100개의 엔드포인트 크기로 제한된다.
-최대 1000개까지 `--max-endpoints-per-slice` {{< glossary_tooltip
-text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그를
-사용해서 구성할 수 있다.
+* 엔드포인트 리소스에는 `endpointslice.kubernetes.io/skip-mirror` 레이블이
+  `true` 로 설정되어 있다.
+* 엔드포인트 리소스에는 `control-plane.alpha.kubernetes.io/leader`
+  어노테이션이 있다.
+* 해당 서비스 리소스가 존재하지 않는다.
+* 해당 서비스 리소스에 nil이 아닌 셀렉터가 있다.
+
+개별 엔드포인트 리소스는 여러 엔드포인트슬라이스로 변환될 수 있다.
+엔드포인트 리소스에 여러 하위 집합이 있거나 여러 IP 제품군(IPv4 및 IPv6)이 있는
+엔드포인트가 포함된 경우 변환이 일어난다. 하위 집합 당 최대 1000개의 주소가
+엔드포인트슬라이스에 미러링된다.
 
 ### 엔드포인트슬라이스의 배포
 
@@ -143,8 +159,8 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
 엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는
 방식의 논리와 유사하다.
 
-컨트롤러는 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
-적극적으로 재조정하지는 않는다. 컨트롤러의 동작은 매우 직관적이다.
+컨트롤 플레인은 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
+적극적으로 재조정하지는 않는다. 로직은 매우 직관적이다.
 
 1. 기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를
    제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다.
@@ -173,10 +189,17 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그
 교체되는 엔드포인트에 대해서 엔드포인트슬라이스를
 자연스럽게 재포장한다.
 
+### 중복 엔드포인트
 
+엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
+엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
+대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
+도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
+엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
+중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 `kube-proxy` 의
+`EndpointSliceCache` 구현에서 찾을 수 있다.
 
 ## {{% heading "whatsnext" %}}
 
-
-* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
+* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기
 * [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기
diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md
index 5d6dbefafe..72e077de6c 100644
--- a/content/ko/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@@ -44,9 +44,9 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 
 * [NGINX, Inc.](https://www.nginx.com/)는
   [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
-* [Traefik](https://github.com/containous/traefik)은
+* [Traefik](https://github.com/traefik/traefik)은
   모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
-  [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다.
+  [Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다.
 
 ## 여러 인그레스 컨트롤러 사용
 
diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md
index 9ec0d2f5bf..c4d18ada98 100644
--- a/content/ko/docs/concepts/services-networking/ingress.md
+++ b/content/ko/docs/concepts/services-networking/ingress.md
@@ -5,7 +5,7 @@ weight: 40
 ---
 
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.1" state="beta" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
 {{< glossary_definition term_id="ingress" length="all" >}}
 
 
@@ -23,19 +23,30 @@ weight: 40
 
 ## 인그레스란?
 
-[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
+[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
 {{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
 
-```none
-    internet
-        |
-   [ Ingress ]
-   --|-----|--
-   [ Services ]
-```
+다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
+{{< mermaid >}}
+graph LR;
+  client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스];
+  ingress-->|라우팅 규칙|service[서비스];
+  subgraph 클러스터
+  ingress;
+  service-->pod1[파드];
+  service-->pod2[파드];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service,pod1,pod2 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
-인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
+
+인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
 
 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
 [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
@@ -59,23 +70,7 @@ weight: 40
 
 최소한의 인그레스 리소스 예제:
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - http:
-      paths:
-      - path: /testpath
-        pathType: Prefix
-        backend:
-          serviceName: test
-          servicePort: 80
-```
+{{< codenew file="service/networking/minimal-ingress.yaml" >}}
 
 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
 인그레스 오브젝트의 이름은 유효한
@@ -98,44 +93,100 @@ spec:
 * 선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드
   HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예,
   foo.bar.com), 규칙이 해당 호스트에 적용된다.
-* 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련
-  백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가
-  모두 수신 요청의 내용과 일치해야 한다.
-* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이
+* 경로 목록 (예, `/testpath`)에는 각각 `service.name` 과
+  `service.port.name` 또는 `service.port.number` 가 정의되어 있는 관련
+  백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로
+  보내기 전에 호스트와 경로가 모두 수신 요청의 내용과
+  일치해야 한다.
+* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/) 또는 [사용자 정의 리소스 백엔드](#resource-backend)에 설명된 바와 같이
   서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
   HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
 
-기본 백엔드는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스
+`defaultBackend` 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스
 컨트롤러에 구성되는 경우가 많다.
 
-### 기본 벡엔드
+### DefaultBackend {#default-backend}
 
-규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본
-백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
+규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로
+[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
 
 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
 기본 백엔드로 라우팅 된다.
 
-### 경로(Path) 유형
+### 리소스 백엔드 {#resource-backend}
 
-인그레스의 각 경로에는 해당하는 경로 유형이 있다. 지원되는 세 가지의 경로
-유형이 있다.
+`Resource` 백엔드는 인그레스 오브젝트와 동일한 네임스페이스 내에 있는
+다른 쿠버네티스 리소스에 대한 ObjectRef이다. `Resource` 는 서비스와
+상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. `Resource`
+백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를
+수신하는 것이다.
 
-* _`ImplementationSpecific`_ (기본): 이 경로 유형의 일치 여부는 IngressClass에 따라
+{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
+
+위의 인그레스를 생성한 후, 다음의 명령으로 확인할 수 있다.
+
+```bash
+kubectl describe ingress ingress-resource-backend
+```
+
+```
+Name:             ingress-resource-backend
+Namespace:        default
+Address:
+Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
+Rules:
+  Host        Path  Backends
+  ----        ----  --------
+  *
+              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
+Annotations:  <none>
+Events:       <none>
+```
+
+### 경로 유형
+
+인그레스의 각 경로에는 해당 경로 유형이 있어야 한다. 명시적
+`pathType` 을 포함하지 않는 경로는 유효성 검사에 실패한다. 지원되는
+경로 유형은 세 가지이다.
+
+* `ImplementationSpecific`: 이 경로 유형의 일치 여부는 IngressClass에 따라
   달라진다. 이를 구현할 때 별도 `pathType` 으로 처리하거나, `Prefix` 또는 `Exact`
   경로 유형과 같이 동일하게 처리할 수 있다.
 
-* _`Exact`_: URL 경로의 대소문자를 엄격하게 일치시킨다.
+* `Exact`: URL 경로의 대소문자를 엄격하게 일치시킨다.
 
-* _`Prefix`_: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다.
+* `Prefix`: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다.
   일치는 대소문자를 구분하고,
   요소별로 경로 요소에 대해 수행한다.
   모든 _p_ 가 요청 경로의 요소별 접두사가 _p_ 인 경우
   요청은 _p_ 경로에 일치한다.
 
-  {{< note >}}
-  경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다).
-  {{< /note >}}
+  {{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막
+  요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와
+  `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}}
+
+### 예제
+
+| 종류    | 경로                             | 요청 경로                       | 일치 여부                            |
+|--------|---------------------------------|-------------------------------|------------------------------------|
+| Prefix | `/`                             | (모든 경로)                     | 예                                  |
+| Exact  | `/foo`                          | `/foo`                        | 예                                  |
+| Exact  | `/foo`                          | `/bar`                        | 아니오                               |
+| Exact  | `/foo`                          | `/foo/`                       | 아니오                               |
+| Exact  | `/foo/`                         | `/foo`                        | 아니오                               |
+| Prefix | `/foo`                          | `/foo`, `/foo/`               | 예                                  |
+| Prefix | `/foo/`                         | `/foo`, `/foo/`               | 예                                  |
+| Prefix | `/aaa/bb`                       | `/aaa/bbb`                    | 아니오                               |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb`                    | 예                                  |
+| Prefix | `/aaa/bbb/`                     | `/aaa/bbb`                    | 예, 마지막 슬래시 무시함                 |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/`                   | 예, 마지막 슬래시 일치함                 |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/ccc`                | 예, 하위 경로 일치함                    |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbbxyz`                 | 아니오, 문자열 접두사 일치하지 않음         |
+| Prefix | `/`, `/aaa`                     | `/aaa/ccc`                    | 예, `/aaa` 접두사 일치함                |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/aaa/bbb`                    | 예, `/aaa/bbb` 접두사 일치함            |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/ccc`                        | 예, `/` 접두사 일치함                   |
+| Prefix | `/aaa`                          | `/ccc`                        | 아니오, 기본 백엔드 사용함                |
+| Mixed  | `/foo` (Prefix), `/foo` (Exact) | `/foo`                        | 예, Exact 선호함                      |
 
 #### 다중 일치
 경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다.
@@ -143,6 +194,20 @@ spec:
 여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다
 정확한(exact) 경로 유형을 가진 경로가 사용 된다.
 
+## 호스트네임 와일드카드
+호스트는 정확한 일치(예: "`foo.bar.com`") 또는 와일드카드(예:
+"`* .foo.com`")일 수 있다. 정확한 일치를 위해서는 HTTP `host` 헤더가
+`host` 필드와 일치해야 한다. 와일드카드 일치를 위해서는 HTTP `host` 헤더가
+와일드카드 규칙의 접미사와 동일해야 한다.
+
+| 호스트        | 호스트 헤더         | 일치 여부                                            |
+| ----------- |-------------------| --------------------------------------------------|
+| `*.foo.com` | `bar.foo.com`     | 공유 접미사를 기반으로 일치함                            |
+| `*.foo.com` | `baz.bar.foo.com` | 일치하지 않음, 와일드카드는 단일 DNS 레이블만 포함함          |
+| `*.foo.com` | `foo.com`         | 일치하지 않음, 와일드카드는 단일 DNS 레이블만 포함함          |
+
+{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
+
 ## 인그레스 클래스
 
 인그레스는 서로 다른 컨트롤러에 의해 구현될 수 있으며, 종종 다른 구성으로
@@ -150,18 +215,7 @@ spec:
 이름을 포함하여 추가 구성이 포함된 IngressClass
 리소스에 대한 참조 클래스를 지정해야 한다.
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: IngressClass
-metadata:
-  name: external-lb
-spec:
-  controller: example.com/ingress-controller
-  parameters:
-    apiGroup: k8s.example.com/v1alpha
-    kind: IngressParameters
-    name: external-lb
-```
+{{< codenew file="service/networking/external-lb.yaml" >}}
 
 IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
 추가 구성을 참조하는데 사용할 수 있다.
@@ -179,7 +233,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
 이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이
 포함된 인그레스 클래스 리소스에 대한 참조이다.
 
-### 기본 인그레스 클래스
+### 기본 IngressClass {#default-ingress-class}
 
 특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass
 리소스에서 `ingressclass.kubernetes.io/is-default-class` 를 `true` 로
@@ -195,24 +249,24 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
 
 ## 인그레스 유형들
 
-### 단일 서비스 인그레스
+### 단일 서비스로 지원되는 인그레스 {#single-service-ingress}
 
 단일 서비스를 노출할 수 있는 기존 쿠버네티스 개념이 있다
 ([대안](#대안)을 본다). 인그레스에 규칙 없이 *기본 백엔드* 를 지정해서
 이를 수행할 수 있다.
 
-{{< codenew file="service/networking/ingress.yaml" >}}
+{{< codenew file="service/networking/test-ingress.yaml" >}}
 
 만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의
 상태를 볼 수 있어야 한다.
 
-```shell
+```bash
 kubectl get ingress test-ingress
 ```
 
 ```
-NAME           HOSTS     ADDRESS           PORTS     AGE
-test-ingress   *         203.0.113.123   80        59s
+NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
+test-ingress   external-lb   *       203.0.113.123   80      59s
 ```
 
 여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해
@@ -229,34 +283,29 @@ test-ingress   *         203.0.113.123   80        59s
 트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를
 최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다.
 
-```none
-foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
-                                 / bar    service2:8080
-```
+{{< mermaid >}}
+graph LR;
+  client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
+  ingress-->|/foo|service1[서비스 service1:4200];
+  ingress-->|/bar|service2[서비스 service2:8080];
+  subgraph 클러스터
+  ingress;
+  service1-->pod1[파드];
+  service1-->pod2[파드];
+  service2-->pod3[파드];
+  service2-->pod4[파드];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 다음과 같은 인그레스가 필요하다.
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: simple-fanout-example
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - path: /foo
-        backend:
-          serviceName: service1
-          servicePort: 4200
-      - path: /bar
-        backend:
-          serviceName: service2
-          servicePort: 8080
-```
+{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
 
 `kubectl apply -f` 를 사용해서 인그레스를 생성 할 때 다음과 같다.
 
@@ -275,8 +324,6 @@ Rules:
   foo.bar.com
                /foo   service1:4200 (10.8.0.90:4200)
                /bar   service2:8080 (10.8.0.91:8080)
-Annotations:
-  nginx.ingress.kubernetes.io/rewrite-target:  /
 Events:
   Type     Reason  Age                From                     Message
   ----     ------  ----               ----                     -------
@@ -289,8 +336,8 @@ Events:
 볼 수 있다.
 
 {{< note >}}
-사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
-에 따라 default-http-backend
+사용 중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에
+따라 default-http-backend
 [서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
 {{< /note >}}
 
@@ -298,77 +345,50 @@ Events:
 
 이름 기반의 가상 호스트는 동일한 IP 주소에서 여러 호스트 이름으로 HTTP 트래픽을 라우팅하는 것을 지원한다.
 
-```none
-foo.bar.com --|                 |-> foo.bar.com service1:80
-              | 178.91.123.132  |
-bar.foo.com --|                 |-> bar.foo.com service2:80
-```
+{{< mermaid >}}
+graph LR;
+  client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
+  ingress-->|호스트: foo.bar.com|service1[서비스 service1:80];
+  ingress-->|호스트: bar.foo.com|service2[서비스 service2:80];
+  subgraph 클러스터
+  ingress;
+  service1-->pod1[파드];
+  service1-->pod2[파드];
+  service2-->pod3[파드];
+  service2-->pod4[파드];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
+
 
 다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을
 라우팅 하기 위해 뒷단의 로드 밸런서를 알려준다.
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: bar.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-```
+{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
 
 만약 규칙에 정의된 호스트 없이 인그레스 리소스를 생성하는 경우,
 이름 기반 가상 호스트가 없어도 인그레스 컨트롤러의 IP 주소에 대한 웹
 트래픽을 일치 시킬 수 있다.
 
-예를 들어, 다음 인그레스 리소스는 `first.bar.com`에 요청된 트래픽을
+예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
 `service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지
 않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
 트래픽은 `service3`로 라우팅 한다.
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: first.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: second.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-  - http:
-      paths:
-      - backend:
-          serviceName: service3
-          servicePort: 80
-```
+{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
 
 ### TLS
 
-TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}}
-을 지정해서 인그레스를 보호할 수 있다. 현재 인그레스는
-단일 TLS 포트인 443만 지원하며 TLS 종료를 가정한다. 만약 인그레스의 TLS
-구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해
+TLS 개인 키 및 인증서가 포함된 {{< glossary_tooltip term_id="secret" >}}을
+지정해서 인그레스를 보호할 수 있다. 인그레스 리소스는
+단일 TLS 포트인 443만 지원하고 인그레스 지점에서 TLS 종료를
+가정한다(서비스 및 해당 파드에 대한 트래픽은 일반 텍스트임).
+인그레스의 TLS 구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해
 지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱
 된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는
 `tls.crt` 와 `tls.key` 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와
@@ -388,28 +408,10 @@ type: kubernetes.io/tls
 
 인그레스에서 시크릿을 참조하면 인그레스 컨트롤러가 TLS를 사용하여
 클라이언트에서 로드 밸런서로 채널을 보호하도록 지시한다. 생성한
-TLS 시크릿이 `sslexample.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고
+TLS 시크릿이 `https-example.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고
 하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다.
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: tls-example-ingress
-spec:
-  tls:
-  - hosts:
-      - sslexample.foo.com
-    secretName: testsecret-tls
-  rules:
-  - host: sslexample.foo.com
-    http:
-      paths:
-      - path: /
-        backend:
-          serviceName: service1
-          servicePort: 80
-```
+{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
 
 {{< note >}}
 TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
@@ -419,7 +421,7 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
 플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다.
 {{< /note >}}
 
-### 로드밸런싱
+### 로드 밸런싱 {#load-balancing}
 
 인그레스 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 구성표 등
 모든 인그레스에 적용되는 일부 로드 밸런싱
@@ -432,8 +434,8 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
 [준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)와
 같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이
 있다는 점도 주목할 가치가 있다. 컨트롤러 별
-설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(
-[nginx](https://git.k8s.io/ingress-nginx/README.md),
+설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(예:
+[nginx](https://git.k8s.io/ingress-nginx/README.md), 또는
 [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
 
 ## 인그레스 업데이트
@@ -476,16 +478,22 @@ spec:
     http:
       paths:
       - backend:
-          serviceName: service1
-          servicePort: 80
+          service:
+            name: service1
+            port:
+              number: 80
         path: /foo
+        pathType: Prefix
   - host: bar.baz.com
     http:
       paths:
       - backend:
-          serviceName: service2
-          servicePort: 80
+          service:
+            name: service2
+            port:
+              number: 80
         path: /foo
+        pathType: Prefix
 ..
 ```
 
@@ -523,15 +531,7 @@ Events:
 ## 가용성 영역에 전체에서의 실패
 
 장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
-자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
-를 참조할 수 있다.
-
-## 앞으로의 할일
-
-[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
-를 추적하여 인그레스와 진행중인 리소스의 발전에 대한 자세한 내용을 알아 본다. 다양한
-인그레스 컨트롤러의 발전에 대한 자세한 내용은
-[인그레스 리포지터리](https://github.com/kubernetes/ingress/tree/master)에서 추적할 수 있다.
+자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다.
 
 ## 대안
 
@@ -546,4 +546,4 @@ Events:
 
 * [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
-* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
+* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube/)
diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md
index 4d8bb47bda..76076f5965 100644
--- a/content/ko/docs/concepts/services-networking/network-policies.md
+++ b/content/ko/docs/concepts/services-networking/network-policies.md
@@ -5,11 +5,18 @@ weight: 50
 ---
 
 <!-- overview -->
-네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
 
-`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
+IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다.
 
+파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
 
+1. 허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음)
+2. 허용되는 네임스페이스
+3. IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨)
+
+pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 사용하여 셀렉터와 일치하는 파드와 주고받는 트래픽을 지정한다.
+
+한편, IP 기반의 네트워크폴리시가 생성되면, IP 블록(CIDR 범위)을 기반으로 정책을 정의한다.
 
 <!-- body -->
 ## 전제 조건
@@ -199,17 +206,29 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 
 ## SCTP 지원
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
-기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
+베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
 
 {{< note >}}
 SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
 {{< /note >}}
 
+# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
 
+쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.
 
+- 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
+- TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
+- 노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음).
+- 이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
+- 타사 공급사가 이행한 "정책 요청"의 생성 또는 관리.
+- 모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음).
+- 고급 정책 쿼리 및 도달 가능성 도구.
+- 단일 정책 선언에서 포트 범위를 대상으로 하는 기능.
+- 네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결).
+- 명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음).
+- 루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음).
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md
index 90ec166c03..e79762e9e7 100644
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@@ -22,8 +22,8 @@ weight: 10
 
 ## 동기
 
-쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 수명이 있다.
-파드는 생성되고, 소멸된 후 부활하지 않는다.
+쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
+일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
 만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
 동적으로 파드를 생성하고 제거할 수 있다.
 
@@ -31,8 +31,8 @@ weight: 10
 한 시점에 실행되는 파드 집합이
 잠시 후 실행되는 해당 파드 집합과 다를 수 있다.
 
-이는 다음과 같은 문제를 야기한다. (“백엔드”라 불리는) 일부 파드 집합이
-클러스터의 (“프론트엔드”라 불리는) 다른 파드에 기능을 제공하는 경우,
+이는 다음과 같은 문제를 야기한다. ("백엔드"라 불리는) 일부 파드 집합이
+클러스터의 ("프론트엔드"라 불리는) 다른 파드에 기능을 제공하는 경우,
 프론트엔드가 워크로드의 백엔드를 사용하기 위해,
 프론트엔드가 어떻게 연결할 IP 주소를 찾아서 추적할 수 있는가?
 
@@ -44,8 +44,8 @@ _서비스_ 로 들어가보자.
 정책을 정의하는 추상적 개념이다. (때로는 이 패턴을
 마이크로-서비스라고 한다.) 서비스가 대상으로 하는 파드 집합은 일반적으로
 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 결정한다.
-(셀렉터가 _없는_ 서비스가 필요한 이유는 [아래](#셀렉터가-없는-서비스)를
-참조한다).
+서비스 엔드포인트를 정의하는 다른 방법에 대한 자세한 내용은
+[셀렉터가 _없는_ 서비스](#셀렉터가-없는-서비스)를 참고한다.
 
 예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를
 생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를
@@ -89,7 +89,7 @@ spec:
       targetPort: 9376
 ```
 
-이 명세는 “my-service”라는 새로운 서비스 오브젝트를 생성하고,
+이 명세는 "my-service"라는 새로운 서비스 오브젝트를 생성하고,
 `app=MyApp` 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다.
 
 쿠버네티스는 이 서비스에 서비스 프록시가 사용하는 IP 주소 ("cluster IP"라고도 함)
@@ -97,7 +97,7 @@ spec:
 (이하 [가상 IP와 서비스 프록시](#가상-ip와-서비스-프록시) 참고)
 
 서비스 셀렉터의 컨트롤러는 셀렉터와 일치하는 파드를 지속적으로 검색하고,
-“my-service”라는 엔드포인트 오브젝트에 대한
+"my-service"라는 엔드포인트 오브젝트에 대한
 모든 업데이트를 POST한다.
 
 {{< note >}}
@@ -127,12 +127,12 @@ spec:
 다른 종류의 백엔드를 추상화할 수도 있다.
 예를 들면
 
-  * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
-    테스트 환경에서는 자체 데이터베이스를 사용한다.
-  * 한 서비스에서 다른
-    {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
-  * 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
-    쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
+* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
+  테스트 환경에서는 자체 데이터베이스를 사용한다.
+* 한 서비스에서 다른
+  {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
+* 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
+  쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
 
 이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
 예를 들면
@@ -150,7 +150,7 @@ spec:
 ```
 
 이 서비스에는 셀렉터가 없으므로, 해당 엔드포인트 오브젝트가 자동으로
-생성되지 *않는다*. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
+생성되지 않는다. 엔드포인트 오브젝트를 수동으로 추가하여, 서비스를 실행 중인 네트워크 주소 및 포트에
 서비스를 수동으로 매핑할 수 있다.
 
 ```yaml
@@ -186,6 +186,7 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
 
 ### 엔드포인트슬라이스
+
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
@@ -200,14 +201,10 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
 
 ### 애플리케이션 프로토콜
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을
-지정하는 방법을 제공한다.
-
-알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면,
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서
-`ServiceAppProtocol` 을 활성화해야 한다.
+`AppProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
+이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 리소스에 의해 미러링된다.
 
 ## 가상 IP와 서비스 프록시
 
@@ -225,20 +222,19 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
 
 서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다.
 
- * 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
-   캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
- * 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
- * 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
-   낮거나 0이면 DNS에 부하가 높아 관리하기가
-   어려워 질 수 있다.
+* 레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
+  캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
+* 일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
+* 앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
+  낮거나 0이면 DNS에 부하가 높아 관리하기가
+  어려워 질 수 있다.
 
 ### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
 
 이 모드에서는, kube-proxy는 쿠버네티스 마스터의 서비스, 엔드포인트 오브젝트의
 추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
 포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
-연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로
-프록시된다.
+연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
 kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
 `SessionAffinity` 설정을 고려한다.
 
@@ -299,12 +295,12 @@ IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을
 IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다.
 다음과 같다.
 
-- `rr`: 라운드-로빈
-- `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
-- `dh`: 목적지 해싱
-- `sh`: 소스 해싱
-- `sed`: 최단 예상 지연 (shortest expected delay)
-- `nq`: 큐 미사용 (never queue)
+* `rr`: 라운드-로빈
+* `lc`: 최소 연결 (가장 적은 수의 열려있는 연결)
+* `dh`: 목적지 해싱
+* `sh`: 소스 해싱
+* `sed`: 최단 예상 지연 (shortest expected delay)
+* `nq`: 큐 미사용 (never queue)
 
 {{< note >}}
 IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
@@ -391,7 +387,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
 
 예를 들어, TCP 포트 6379를 개방하고
-클러스터 IP 주소 10.0.0.11이 할당된 서비스 `"redis-master"`는,
+클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
 다음 환경 변수를 생성한다.
 
 ```shell
@@ -424,18 +420,18 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위
 모든 파드는 DNS 이름으로 서비스를 자동으로
 확인할 수 있어야 한다.
 
-예를 들면, 쿠버네티스 네임스페이스 `"my-ns"`에 `"my-service"`라는
+예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는
 서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
-`"my-service.my-ns"`에 대한 DNS 레코드를 만든다. `"my-ns"` 네임 스페이스의 파드들은
+`my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은
 간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다
-(`"my-service.my-ns"` 역시 동작함).
+(`my-service.my-ns` 역시 동작함).
 
 다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은
 서비스에 할당된 클러스터 IP로 변환된다.
 
 쿠버네티스는 또한 알려진 포트에 대한 DNS SRV (서비스) 레코드를 지원한다.
-`"my-service.my-ns"` 서비스에 프로토콜이 `TCP`로 설정된 `"http"`라는 포트가 있는 경우,
-IP 주소와 `"http"`에 대한 포트 번호를 검색하기 위해 `_http._tcp.my-service.my-ns` 에 대한
+`my-service.my-ns` 서비스에 프로토콜이 `TCP`로 설정된 `http`라는 포트가 있는 경우,
+IP 주소와 `http`에 대한 포트 번호를 검색하기 위해 `_http._tcp.my-service.my-ns` 에 대한
 DNS SRV 쿼리를 수행할 수 있다.
 
 쿠버네티스 DNS 서버는 `ExternalName` 서비스에 접근할 수 있는 유일한 방법이다.
@@ -468,9 +464,9 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 `엔드포인트` 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고
 구성한다.
 
-  * [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
-  * 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
-    대한 레코드
+* [`ExternalName`](#externalname)-유형 서비스에 대한 CNAME 레코드
+* 다른 모든 유형에 대해, 서비스의 이름을 공유하는 모든 `엔드포인트`에
+  대한 레코드
 
 ## 서비스 퍼블리싱 (ServiceTypes) {#publishing-services-service-types}
 
@@ -482,26 +478,26 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 
 `Type` 값과 그 동작은 다음과 같다.
 
-   * `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
-     클러스터 내에서만 서비스에 도달할 수 있다. 이것은
-     `ServiceTypes`의 기본 값이다.
-   * [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
-     노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
-     자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
-     클러스터 외부에서
-     `NodePort` 서비스에 접속할 수 있다.
-   * [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
-     서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
-     `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
-   * [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
-     `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
-     매핑한다.
-     어떤 종류의 프록시도 설정되어 있지 않다.
-     {{< note >}}
-     `ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다.
-     {{< /note >}}
+* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
+  클러스터 내에서만 서비스에 도달할 수 있다. 이것은
+  `ServiceTypes`의 기본 값이다.
+* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
+  노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
+  자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
+  클러스터 외부에서
+  `NodePort` 서비스에 접속할 수 있다.
+* [`LoadBalancer`](#loadbalancer): 클라우드 공급자의 로드 밸런서를 사용하여
+  서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
+  `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다.
+* [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를
+  `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에
+  매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
+  {{< note >}}`ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는
+  CoreDNS 버전 1.7 이상이 필요하다.
+  {{< /note >}}
 
-[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
+[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
+노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
 
 ### NodePort 유형 {#nodeport}
 
@@ -510,7 +506,6 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
 서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.
 
-
 포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
 이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
 
@@ -531,6 +526,7 @@ NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설
 `.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)
 
 예를 들면
+
 ```yaml
 apiVersion: v1
 kind: Service
@@ -607,19 +603,21 @@ SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의
 {{< /note >}}
 
 #### 내부 로드 밸런서 {#internal-load-balancer}
+
 혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
-라우팅해야하는 경우가 있다.
+라우팅해야 하는 경우가 있다.
 
 수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는 두 개의 서비스가 필요하다.
 
-서비스에 다음 어노테이션 중 하나를 추가하여 이를 수행할 수 있다.
-추가할 어노테이션은 사용 중인 클라우드 서비스 공급자에 따라 다르다.
+내부 로드 밸런서를 설정하려면, 사용 중인 클라우드 서비스 공급자에 따라
+다음의 어노테이션 중 하나를 서비스에 추가한다.
 
 {{< tabs name="service_tabs" >}}
 {{% tab name="Default" %}}
 탭 중 하나를 선택
 {{% /tab %}}
 {{% tab name="GCP" %}}
+
 ```yaml
 [...]
 metadata:
@@ -628,8 +626,10 @@ metadata:
         cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -638,8 +638,10 @@ metadata:
         service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -648,8 +650,10 @@ metadata:
         service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -658,8 +662,10 @@ metadata:
         service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -668,8 +674,10 @@ metadata:
         service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -678,8 +686,10 @@ metadata:
         service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Tencent Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -687,8 +697,10 @@ metadata:
     service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Alibaba Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -696,10 +708,10 @@ metadata:
     service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
 [...]
 ```
+
 {{% /tab %}}
 {{< /tabs >}}
 
-
 #### AWS에서 TLS 지원 {#ssl-support-on-aws}
 
 AWS에서 실행되는 클러스터에서 부분적으로 TLS / SSL을 지원하기 위해, `LoadBalancer` 서비스에 세 가지
@@ -824,7 +836,6 @@ Classic ELB의 연결 드레이닝은
 사용하여 인스턴스를 해제하기 전에,
 기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로 설정할 수도 있다.
 
-
 ```yaml
     metadata:
       name: my-service
@@ -862,13 +873,22 @@ Classic ELB의 연결 드레이닝은
         service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
         # 개별 인스턴스의 상태 점검 사이의
         # 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다.
+
         service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
         # 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위)
         # 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
         # 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.
 
+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
+        # 생성된 ELB에 추가할 기존 보안 그룹 목록.
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다.
+
         service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
         # ELB에 추가될 추가 보안 그룹(security group) 목록
+
+        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
+        # 로드 밸런서의 대상 노드를 선택하는 데
+        # 사용되는 키-값 쌍의 쉼표로 구분된 목록
 ```
 
 #### AWS의 네트워크 로드 밸런서 지원 {#aws-nlb-support}
@@ -987,6 +1007,7 @@ spec:
   type: ExternalName
   externalName: my.database.example.com
 ```
+
 {{< note >}}
 ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
 정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
@@ -1041,7 +1062,7 @@ spec:
 
 ## 단점
 
-VIP용으로 유저스페이스 프록시를 사용하면, 중소 급 스케일에서는 동작하지만, 수천 개의
+VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의
 서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
 [포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이
 있다.
@@ -1169,12 +1190,12 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
 
 {{< note >}}
 서비스 대신 {{< glossary_tooltip term_id="ingress" text="인그레스" >}} 를 사용하여
-HTTP / HTTPS 서비스를 노출할 수도 있다.
+HTTP/HTTPS 서비스를 노출할 수도 있다.
 {{< /note >}}
 
 ### PROXY 프로토콜
 
-클라우드 공급자가 지원하는 경우에 (예: [AWS](/ko/docs/concepts/cluster-administration/cloud-providers/#aws)),
+클라우드 공급자가 지원하는 경우에,
 LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부에
 로드 밸런서를 구성할 수 있으며, 이때 접두사가
 [PROXY 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 인 연결을 전달하게 된다.
@@ -1185,15 +1206,16 @@ LoadBalancer 모드의 서비스를 사용하여 쿠버네티스 자체 외부
 ```
 PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 ```
+
 클라이언트 데이터가 뒤따라온다.
 
 ### SCTP
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-쿠버네티스는 서비스, 엔드포인트, 네트워크 정책 및 파드 정의에서 알파 기능으로 SCTP를 `프로토콜` 값으로 지원한다. 이 기능을 활성화하기 위해서는, 클러스터 관리자가 API 서버에서 `--feature-gates=SCTPSupport=true,…`처럼 `SCTPSupport` 기능 게이트를 활성화해야 한다.
+쿠버네티스는 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 및 파드 정의에서 SCTP를 `protocol` 값으로 지원한다. 이 기능은 베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에서 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
 
-기능 게이트가 활성화되면, 서비스, 엔드포인트, 네트워크 정책 또는 파드의 `프로토콜` 필드를 `SCTP`로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다.
+기능 게이트가 활성화되면, 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 또는 파드의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다.
 
 #### 경고 {#caveat-sctp-overview}
 
@@ -1223,11 +1245,8 @@ SCTP는 윈도우 기반 노드를 지원하지 않는다.
 kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
 {{< /warning >}}
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기
 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기
diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md
index 87ce9c9d27..412645e734 100644
--- a/content/ko/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md
@@ -80,7 +80,7 @@ v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVol
 관리자가 구성한 `StorageClass` 의 이름과
 일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고)
 
-예를 들어 “fast” 스토리지 클래스를 선택하려면 다음과
+예를 들어 "fast" 스토리지 클래스를 선택하려면 다음과
 같은 `PersistentVolumeClaim` 을 생성한다.
 
 ```yaml
@@ -127,4 +127,3 @@ spec:
 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를
 프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를
 설정해서 수행할 수 있다.
-
diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md
index 71e78eae96..4cf129a3e6 100644
--- a/content/ko/docs/concepts/storage/persistent-volumes.md
+++ b/content/ko/docs/concepts/storage/persistent-volumes.md
@@ -25,7 +25,7 @@ _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 
 
 퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
 
-[실습 예제와 함께 상세한 내용](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.
+[실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.
 
 ## 볼륨과 클레임 라이프사이클
 
@@ -140,7 +140,7 @@ Events:            <none>
 기본 볼륨 플러그인에서 지원하는 경우 `Recycle` 반환 정책은 볼륨에서 기본 스크럽(`rm -rf /thevolume/*`)을 수행하고 새 클레임에 다시 사용할 수 있도록 한다.
 
 그러나 관리자는 [레퍼런스](/docs/reference/command-line-tools-reference/kube-controller-manager/)에
-설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를
+설명된 대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를
 사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다.
 사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가
 포함되어야 한다.
@@ -168,6 +168,45 @@ spec:
 
 그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다.
 
+### 퍼시스턴트볼륨 예약
+
+컨트롤 플레인은 클러스터에서 [퍼시스턴트볼륨클레임을 일치하는 퍼시스턴트볼륨에 바인딩](#바인딩)할
+수 있다. 그러나, PVC를 특정 PV에 바인딩하려면, 미리 바인딩해야 한다.
+
+퍼시스턴트볼륨클레임에서 퍼시스턴트볼륨을 지정하여, 특정 PV와 PVC 간의 바인딩을 선언한다.
+퍼시스턴트볼륨이 존재하고 `claimRef` 필드를 통해 퍼시스턴트볼륨클레임을 예약하지 않은 경우, 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이 바인딩된다.
+
+바인딩은 노드 선호도(affinity)를 포함하여 일부 볼륨 일치(matching) 기준과 관계없이 발생한다.
+컨트롤 플레인은 여전히 [스토리지 클래스](https://kubernetes.io/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다.
+
+```
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: foo-pvc
+  namespace: foo
+spec:
+  volumeName: foo-pv
+  ...
+```
+
+이 메서드는 퍼시스턴트볼륨에 대한 바인딩 권한을 보장하지 않는다. 다른 퍼시스턴트볼륨클레임에서 지정한 PV를 사용할 수 있는 경우, 먼저 해당 스토리지 볼륨을 예약해야 한다. PV의 `claimRef` 필드에 관련 퍼시스턴트볼륨클레임을 지정하여 다른 PVC가 바인딩할 수 없도록 한다.
+
+```
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: foo-pv
+spec:
+  claimRef:
+    name: foo-pvc
+    namespace: foo
+  ...
+```
+
+이는 기존 PV를 재사용하는 경우를 포함하여 `claimPolicy` 가
+`Retain` 으로 설정된 퍼시스턴트볼륨을 사용하려는 경우에 유용하다.
+
 ### 퍼시스턴트 볼륨 클레임 확장
 
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}
@@ -248,6 +287,16 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하
 EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다.
 {{< /note >}}
 
+#### 볼륨 확장 시 오류 복구
+
+기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다.
+
+1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다.
+2. PVC를 삭제한다. PV에는 `Retain` 반환 정책이 있으므로 PVC를 재생성할 때 데이터가 손실되지 않는다.
+3. 새 PVC를 바인딩할 수 있도록 PV 명세에서 `claimRef` 항목을 삭제한다. 그러면 PV가 `Available` 상태가 된다.
+4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다.
+5. PV의 반환 정책을 복원하는 것을 잊지 않는다.
+
 
 ## 퍼시스턴트 볼륨의 유형
 
@@ -745,8 +794,8 @@ spec:
   ## {{% heading "whatsnext" %}}
 
 
-* [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기
-* [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기
+* [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기
+* [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기
 * [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기
 
 ### 참고
diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md
index 69b74ddefe..38d59b6fb0 100644
--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@@ -410,6 +410,21 @@ parameters:
 
 ### vSphere
 
+vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다.
+
+- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com`
+- [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume`
+
+인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다.
+
+#### CSI 프로비저닝 도구 {#vsphere-provisioner-csi}
+
+vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다.
+
+#### vCP 프로비저닝 도구
+
+다음 예시에서는 VMware 클라우드 공급자(vCP) 스토리지클래스 프로비저닝 도구를 사용한다.
+
 1. 사용자 지정 디스크 형식으로 스토리지클래스를 생성한다.
 
     ```yaml
@@ -575,7 +590,7 @@ parameters:
   이 Quobyte 테넌트는 이미 Quobyte에 있어야 한다.
   기본값은 "DEFAULT".
 
-### Azure 디스크크
+### Azure 디스크
 
 #### Azure 비관리 디스크 스토리지 클래스 {#azure-unmanaged-disk-storage-class}
 
diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md
index 9aadbe3726..5ad5a938eb 100644
--- a/content/ko/docs/concepts/storage/volume-snapshots.md
+++ b/content/ko/docs/concepts/storage/volume-snapshots.md
@@ -87,14 +87,14 @@ spec:
 
 사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다.
 
-```
+```yaml
 apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshot
 metadata:
   name: test-snapshot
 spec:
   source:
-        volumeSnapshotContentName: test-content
+    volumeSnapshotContentName: test-content
 ```
 
 ## 볼륨 스냅샷 컨텐츠
diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md
index f57a003d13..9077eec5d2 100644
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@@ -150,7 +150,7 @@ awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, 
 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI
 드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
 를 설치하고 `CSIMigration` 과 `CSIMigrationAWS`
-베타 기능을 활성화 해야 한다.
+베타 기능을 활성화해야 한다.
 
 #### CSI 마이그레이션 완료
 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}
@@ -165,14 +165,14 @@ awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, 
 
 #### CSI 마이그레이션
 
-{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서
 `disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI
 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk`
-알파 기능을 활성화 해야 한다.
+기능을 활성화해야 한다.
 
 ### azureFile {#azurefile}
 
@@ -190,7 +190,7 @@ azureFile의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리
 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI
 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver)
 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
-알파 기능을 활성화 해야 한다.
+알파 기능을 활성화해야 한다.
 
 ### cephfs {#cephfs}
 
@@ -210,8 +210,7 @@ CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 
 ### cinder {#cinder}
 
 {{< note >}}
-전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. 클라우드 공급자
-구성에 대해서는 [오픈스택 클라우드 공급자](/ko/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다.
+전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스.
 {{< /note >}}
 
 `cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다.
@@ -493,7 +492,7 @@ GCE PD의 CSI 마이그레이션 기능이 활성화된 경우 기존 트리 내
 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI
 드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)
 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE`
-베타 기능을 활성화 해야 한다.
+베타 기능을 활성화해야 한다.
 
 ### gitRepo (사용 중단(deprecated)) {#gitrepo}
 
@@ -752,7 +751,7 @@ spec:
 ### persistentVolumeClaim {#persistentvolumeclaim}
 
 `persistentVolumeClaim` 볼륨은
-[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes)을 파드에 마운트하는데 사용한다.  퍼시스턴트볼륨은
+[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes)을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨클레임은
 사용자가 특정 클라우드 환경의 세부 내용을 몰라도 내구성이있는 스토리지 (GCE 퍼시스턴트디스크 또는
 iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다.
 
@@ -1035,7 +1034,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
 업데이트를 수신하지 못한다.
 {{< /note >}}
 
-시크릿에 대해서 [여기](/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다.
+시크릿에 대해서 [여기](/ko/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다.
 
 ### storageOS {#storageos}
 
@@ -1151,6 +1150,38 @@ spec:
 
 더 많은 예시는 [여기](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)에서 확인할 수 있다.
 
+#### CSI 마이그레이션
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+vsphereVolume용 CSI 마이그레이션 기능이 활성화되면, 기존 인-트리 플러그인에서
+`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 shim한다.
+이 기능을 사용하려면, [vSphere CSI
+드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가
+클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
+
+또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다.
+
+{{< note >}}
+빌트인 vsphereVolume 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다.
+
+* `diskformat`
+* `hostfailurestotolerate`
+* `forceprovisioning`
+* `cachereservation`
+* `diskstripes`
+* `objectspacereservation`
+* `iopslimit`
+
+이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만, vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다.
+{{< /note >}}
+
+#### CSI 마이그레이션 완료
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+vsphereVolume 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 true로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치되어 있어야 한다.
+
 
 ## subPath 사용하기
 
@@ -1194,7 +1225,6 @@ spec:
 
 
 `subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다.
-이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다.
 `subPath` 와 `subPathExpr` 속성은 상호 배타적이다.
 
 이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다.  호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다.
@@ -1284,8 +1314,11 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
 `csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결, 마운트,
 등을 할 수 있다.
 
-`csi` 볼륨 유형은 파드에서의 직접 참조를 지원하지 않으며
-`PersistentVolumeClaim` 오브젝트를 통해 파드에서 참조할 수 있다.
+`csi` 볼륨은 세 가지 방법으로 파드에서 사용할 수 있다.
+- [`persistentVolumeClaim`](#persistentvolumeclaim)에 대한 참조를 통해서
+- [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 (알파 기능)
+- 드라이버가 지원하는 경우
+  [CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) (베타 기능)
 
 스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을
 구성할 수 있다.
@@ -1348,38 +1381,14 @@ CSI 설정 변경 없이 평소와 같이
 
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
 
-이 기능을 사용하면 CSI 볼륨을 퍼시스턴트볼륨 대신에 파드 사양에 직접적으로 포함할 수 있다.
-이러한 방식으로 지정된 볼륨은 임시적이고 파드 재시작시에는 유지되지 않는다.
+파드 명세 내에서 CSI 볼륨을 직접 구성할 수
+있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며
+파드가 다시 시작할 때 지속되지 않는다. 자세한 내용은 [임시
+볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)을
+참고한다.
 
-예시
+#### {{% heading "whatsnext" %}}
 
-```yaml
-kind: Pod
-apiVersion: v1
-metadata:
-  name: my-csi-app
-spec:
-  containers:
-    - name: my-frontend
-      image: busybox
-      volumeMounts:
-      - mountPath: "/data"
-        name: my-csi-inline-vol
-      command: [ "sleep", "1000000" ]
-  volumes:
-    - name: my-csi-inline-vol
-      csi:
-        driver: inline.storage.kubernetes.io
-        volumeAttributes:
-          foo: bar
-```
-
-이 기능을 사용하려면 CSIInlineVolume 기능 게이트를 활성화 해야 한다.
-쿠버네티스 1.16 시작시 기본적으로 활성화 되어있다.
-
-CSI 임시 볼륨은 CSI 드라이버의 하위집합에서만 지원된다. CSI 드라이버의 목록은 [여기](https://kubernetes-csi.github.io/docs/drivers.html)를 본다.
-
-# 개발자 리소스
 CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi
 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.
 
diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md
index c898502b39..a020124b6d 100644
--- a/content/ko/docs/concepts/workloads/_index.md
+++ b/content/ko/docs/concepts/workloads/_index.md
@@ -3,4 +3,55 @@ title: "워크로드"
 weight: 50
 description: >
   쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화
+no_list: true
 ---
+
+{{< glossary_definition term_id="workload" length="short" >}}
+워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
+[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
+쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
+집합을 나타낸다.
+
+파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고
+해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서
+심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
+최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다.
+
+그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다.
+대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다.
+이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
+실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를
+구성한다.
+
+이러한 워크로드 리소스에는 다음이 포함된다.
+
+* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
+  (레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체);
+* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/);
+* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는
+  파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
+* 완료될 때까지 실행되는 작업에 대한
+  [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및
+  [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cronjob/)
+
+관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
+* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
+  제거된 후 클러스터에서 오브젝트를 정리한다.
+* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
+  완료된 이후 정의된 시간이 경과되면 잡을 제거한다.
+
+## {{% heading "whatsnext" %}}
+
+각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
+
+* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
+* 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
+  또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
+* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
+
+일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로
+사용하거나, 웹 애플리케이션의 경우에만
+[인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다.
+
+[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의
+메커니즘에 대해 알아볼 수도 있다.
diff --git a/content/ko/docs/concepts/workloads/controllers/_index.md b/content/ko/docs/concepts/workloads/controllers/_index.md
index 8193613bfe..1c4271adf9 100644
--- a/content/ko/docs/concepts/workloads/controllers/_index.md
+++ b/content/ko/docs/concepts/workloads/controllers/_index.md
@@ -1,4 +1,4 @@
 ---
-title: "컨트롤러"
+title: "워크로드 리소스"
 weight: 20
 ---
diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
index 44590ccdfc..fe46abd604 100644
--- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
@@ -44,7 +44,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 
 {{< codenew file="application/job/cronjob.yaml" >}}
 
-([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는
+([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
 이 예시를 더 자세히 설명한다.)
 
 ## 크론잡의 한계 {#cron-job-limitations}
@@ -85,4 +85,4 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 크론잡 `schedule` 필드의 포맷을 문서화 한다.
 
 크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
-예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
+예는 [크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md
index dca5a651f4..3fd5f2830a 100644
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@@ -1,7 +1,7 @@
 ---
 title: 데몬셋
 content_type: concept
-weight: 50
+weight: 40
 ---
 
 <!-- overview -->
diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md
index e782c7c60d..0c6a278031 100644
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@@ -6,7 +6,7 @@ feature:
     쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다.
 
 content_type: concept
-weight: 30
+weight: 10
 ---
 
 <!-- overview -->
@@ -82,7 +82,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
 
   만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
-   ```shell
+   ```
    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   0/3     0            0           1s
    ```
@@ -98,21 +98,21 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
 
    다음과 유사하게 출력된다.
-   ```shell
+   ```
    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-   deployment.apps/nginx-deployment successfully rolled out
+   deployment "nginx-deployment" successfully rolled out
    ```
 
 4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다.
    다음과 유사하게 출력된다.
-   ```shell
+   ```
    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           18s
    ```
    디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
 
 5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면, `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다.
-   ```shell
+   ```
    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-75675f5897   3         3         3       18s
    ```
@@ -129,7 +129,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 
 6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다.
    다음과 유사하게 출력된다.
-   ```shell
+   ```
    NAME                                READY     STATUS    RESTARTS   AGE       LABELS
    nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
    nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
@@ -203,7 +203,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
     ```
     또는
     ```
-    deployment.apps/nginx-deployment successfully rolled out
+    deployment "nginx-deployment" successfully rolled out
     ```
 
 업데이트된 디플로이먼트에 대해 자세한 정보 보기
@@ -855,7 +855,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 이와 유사하게 출력된다.
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 ```
 그리고 `kubectl rollout` 의 종료 상태는 0(success)이다.
 ```shell
@@ -1015,7 +1015,7 @@ echo $?
 ### 실패한 디플로이먼트에서의 운영
 
 완료된 디플로이먼트에 적용되는 모든 행동은 실패한 디플로이먼트에도 적용된다.
-디플로이먼트 파드 템플릿에서 여러개의 수정사항을 적용해야하는 경우 스케일 업/다운 하거나, 이전 수정 버전으로 롤백하거나, 일시 중지할 수 있다.
+디플로이먼트 파드 템플릿에서 여러 개의 수정사항을 적용해야하는 경우 스케일 업/다운 하거나, 이전 수정 버전으로 롤백하거나, 일시 중지할 수 있다.
 
 ## 정책 초기화
 
diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
index 902326a9a4..cf6641958e 100644
--- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
@@ -1,7 +1,7 @@
 ---
 title: 가비지(Garbage) 수집
 content_type: concept
-weight: 70
+weight: 60
 ---
 
 <!-- overview -->
@@ -152,7 +152,7 @@ kubectl delete replicaset my-repset --cascade=false
 ### 디플로이먼트에 대한 추가 참고
 
 1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 `propagationPolicy: Foreground`
-를 사용해서 생성된 레플리카셋 뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
+를 사용해서 생성된 레플리카셋뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
 유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
 더 많은 정보는 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)를 본다.
 
diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md
index a77678a975..5c505a3286 100644
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@@ -1,11 +1,11 @@
 ---
-title: 잡 - 실행부터 완료까지
+title: 잡
 content_type: concept
 feature:
   title: 배치 실행
   description: >
     쿠버네티스는 서비스 외에도 배치와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다.
-weight: 70
+weight: 50
 ---
 
 <!-- overview -->
@@ -116,6 +116,7 @@ kubectl logs $pods
 
 `.spec.template` 은 `.spec` 의 유일한 필수 필드이다.
 
+
 `.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 같은 스키마를 가지고 있다.
 
 추가로 파드의 필수 필드 외에도 잡의 파드 템플릿은 적절한
@@ -129,7 +130,7 @@ kubectl logs $pods
 [자신의 파드 셀렉터를 지정하기](#자신의-파드-셀렉터를-지정하기) 섹션을 참고한다.
 
 
-### 병렬 잡
+### 잡에 대한 병렬 실행 {#parallel-jobs}
 
 잡으로 실행하기에 적합한 작업 유형은 크게 세 가지가 있다.
 
@@ -199,7 +200,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 두 번 시작하는 경우가 있다는 점을 참고한다.
 
 `.spec.parallelism` 그리고 `.spec.completions` 를 모두 1보다 크게 지정한다면 한번에
-여러개의 파드가 실행될 수 있다.  따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.
+여러 개의 파드가 실행될 수 있다.  따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.
 
 ### 파드 백오프(backoff) 실패 정책
 
@@ -212,9 +213,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프
 카운트가 재설정된다.
 
-{{< note >}}
-1.12 이전 버전의 쿠버네티스 버전에 대해 여전히 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) 이슈가 있다.
-{{< /note >}}
 {{< note >}}
 만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
 도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
@@ -333,7 +331,7 @@ spec:
 - 각 작업 항목에 대한 하나의 잡 오브젝트 vs 모든 작업 항목에 대한 단일 잡 오브젝트.  후자는
   작업 항목 수가 많은 경우 더 적합하다.  전자는 사용자와 시스템이 많은 수의 잡 오브젝트를
   관리해야 하는 약간의 오버헤드를 만든다.
-- 작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리
+- 작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리.
   전자는 일반적으로 기존 코드와 컨테이너를 거의 수정할 필요가 없다.  후자는
   이전 글 머리표(-)와 비슷한 이유로 많은 수의 작업 항목에 적합하다.
 - 여러 접근 방식이 작업 큐를 사용한다.  이를 위해서는 큐 서비스를 실행하고,
@@ -346,9 +344,9 @@ spec:
 
 |                            패턴                                   | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정하지 않은 앱을 사용하는가? |  Kube 1.1에서 작동하는가? |
 | -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
-| [잡 템플릿 확장](/docs/tasks/job/parallel-processing-expansion/)            |                   |                             |          ✓          |          ✓          |
+| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/)            |                   |                             |          ✓          |          ✓          |
 | [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/)   |         ✓         |                             |      때때로      |          ✓          |
-| [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/)  |         ✓         |             ✓               |                     |          ✓          |
+| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)  |         ✓         |             ✓               |                     |          ✓          |
 | 정적 작업이 할당된 단일 잡                               |         ✓         |                             |          ✓          |                     |
 
 `.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
@@ -362,9 +360,9 @@ spec:
 
 |                             패턴                                  | `.spec.completions` |  `.spec.parallelism` |
 | -------------------------------------------------------------------- |:-------------------:|:--------------------:|
-| [잡 템플릿 확장](/docs/tasks/job/parallel-processing-expansion/)           |          1          |     1이어야 함      |
+| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/)           |          1          |     1이어야 함      |
 | [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/)   |          W          |        any           |
-| [가변 파드 수를 가진 큐](/docs/tasks/job/fine-parallel-processing-work-queue/)  |          1          |        any           |
+| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)  |          1          |        any           |
 | 정적 작업이 할당된 단일 잡                               |          W          |        any           |
 
 
diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md
index a23c3605cf..5c0852dc12 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md
@@ -1,7 +1,7 @@
 ---
 title: 레플리카셋
 content_type: concept
-weight: 10
+weight: 20
 ---
 
 <!-- overview -->
@@ -241,9 +241,10 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
 `.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)이다.
 [앞서](#레플리카-셋의-작동-방식) 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다.
 우리 `frontend.yaml` 예제에서의 셀렉터는 다음과 같다.
-```shell
+
+```yaml
 matchLabels:
-	tier: frontend
+  tier: frontend
 ```
 
 레플리카셋에서 `.spec.template.metadata.labels`는 `spec.selector`과 일치해야 하며
diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
index e800a253d7..5c5b5c750f 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -7,7 +7,7 @@ feature:
     오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다.
 
 content_type: concept
-weight: 20
+weight: 90
 ---
 
 <!-- overview -->
@@ -112,20 +112,20 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
 레플리케이션 컨트롤러 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
+컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
 
-레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
+레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
 
 ### 파드 템플릿
 
 `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다.
 
-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿) 이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
 
 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와
 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라.
 
-오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 만 허용되며, 특별히 지정되지 않으면 기본값이다.
+오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)만 허용되며, 특별히 지정되지 않으면 기본값이다.
 
 로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다.
 예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다.
@@ -139,7 +139,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 
 ### 파드 셀렉터
 
-`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
+`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
 직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
 삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
 레플리케이션 컨트롤러를 교체할 수 있다.
@@ -181,14 +181,14 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적
 
 해당 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 삭제할 수 있다.
 
-kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 에 옵션으로 `--cascade=false`를 지정하라.
+kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라.
 
 REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러 오브젝트를 삭제하라.
 
 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
 새로운 파드 템플릿과 일치시키려는 노력은 하지 않을 것이다.
-새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 [롤링 업데이트](#롤링-업데이트) 를 사용하라.
+새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 [롤링 업데이트](#롤링-업데이트)를 사용하라.
 
 ### 레플리케이션 컨트롤러에서 파드 격리
 
@@ -208,7 +208,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
 
 레플리케이션 컨트롤러는 파드를 하나씩 교체함으로써 서비스에 대한 롤링 업데이트를 쉽게 하도록 설계되었다.
 
-[#1353](https://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
+[#1353](https://issue.k8s.io/1353)에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
 
 이상적으로 롤링 업데이트 컨트롤러는 애플리케이션 준비 상태를 고려하며 주어진 시간에 충분한 수의 파드가 생산적으로 제공되도록 보장할 것이다.
 
@@ -229,15 +229,15 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
 
 ## 레플리케이션을 위한 프로그램 작성
 
-레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html) 와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다.
+레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다.
 
 ## 레플리케이션 컨트롤러의 책임
 
 레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
 
-레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170)) 까지도 고려해야 한다.
+레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다.
 
-레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
+레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
 
 
 ## API 오브젝트
@@ -250,14 +250,14 @@ API 오브젝트에 대한 더 자세한 것은
 
 ### 레플리카셋
 
-[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
-이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
+[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건)이다.
+이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
 
 
 ### 디플로이먼트 (권장되는)
 
-[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
+[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
 
 ### 베어 파드
 
@@ -266,12 +266,12 @@ API 오브젝트에 대한 더 자세한 것은
 ### 잡
 
 자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우
-레플리케이션 컨트롤러 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라.
+레플리케이션 컨트롤러 대신 [`Job`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라.
 
 ### 데몬셋
 
 머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
-[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
+[`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
 
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index d588276b25..6b8299a0c3 100644
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -1,7 +1,7 @@
 ---
 title: 스테이트풀셋
 content_type: concept
-weight: 40
+weight: 30
 ---
 
 <!-- overview -->
diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md
index 42e0b14607..5c5748e24e 100644
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@@ -13,7 +13,7 @@ card:
 _파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
 
 _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
-{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 그룹이다.
+[컨테이너](/ko/docs/concepts/containers/)의 그룹이다.
 이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
 함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
 애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
@@ -120,11 +120,11 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 {{< /note >}}
 
 파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한
-[DNS 하위 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
 
 ### 파드와 컨트롤러
 
-워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 ​​있다. 리소스에 대한 컨트롤러는
+워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는
 파드 장애 시 복제 및 롤아웃과 자동 복구를
 처리한다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중지했음을
 인식하고 대체 파드를 생성한다. 스케줄러는
@@ -142,9 +142,9 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 _파드 템플릿_ 에서 파드를 생성하고 사용자 대신 해당 파드를 관리한다.
 
 파드템플릿(PodTemplate)은 파드를 생성하기 위한 명세이며,
-[디플로이먼트](/docs/concepts/workloads/controllers/deployment/),
-[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/) 및
-[데몬셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함된다.
+[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/),
+[잡](/ko/docs/concepts/workloads/controllers/job/) 및
+[데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함된다.
 
 워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 `PodTemplate` 을
 사용하여 실제 파드를 생성한다. `PodTemplate` 은 앱을 실행하는 데 사용되는 워크로드 리소스가
@@ -255,7 +255,7 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 * [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
   다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
-* [PodDisruptionBudget](https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
+* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
 * 파드는 쿠버네티스 REST API의 최상위 리소스이다.
   [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
   오브젝트 정의는 오브젝트를 상세히 설명한다.
diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md
index 8d0ca2008a..3267f5b04d 100644
--- a/content/ko/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/init-containers.md
@@ -26,8 +26,8 @@ weight: 40
 * 초기화 컨테이너는 항상 완료를 목표로 실행된다.
 * 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
 
-만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
-반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
+만약 파드의 초기화 컨테이너가 실패하면, kubelet은 초기화 컨테이너가 성공할 때까지 반복적으로 재시작한다.
+그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.
 
 컨테이너를 초기화 컨테이너로 지정하기 위해서는,
 파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
index 43d54aff46..00aed3c13d 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -13,7 +13,8 @@ weight: 30
 
 파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시
 시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너
-[상태](#컨테이너-상태)와 핸들을 추적한다.
+[상태](#컨테이너-상태)를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를
+결정한다.
 
 쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다.
 파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다.
@@ -45,7 +46,7 @@ ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가
 상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다.
 
 UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신,
-해당 파드는 사용자가 원하는 이름은 같지만, UID가 다른, 거의 동일한 새 파드로
+해당 파드는 사용자가 원한다면 이름은 같지만, UID가 다른, 거의 동일한 새 파드로
 대체될 수 있다.
 
 {{< glossary_tooltip term_id="volume" text="볼륨" >}}과
@@ -91,7 +92,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
 
 전체 파드의 [단계](#파드의-단계)뿐 아니라, 쿠버네티스는 파드 내부의
 각 컨테이너 상태를 추적한다.
-[컨테이너 라이프사이클 훅(hook)](/docs/concepts/containers/container-lifecycle-hooks/)을
+[컨테이너 라이프사이클 훅(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)을
 사용하여 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있다.
 
 일단 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}가
@@ -118,7 +119,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
 ### `Running` {#container-state-running}
 
 `Running` 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. `postStart` 훅이
-구성되어 있었다면, 이미 실행이 완료되었다. `kubectl` 을
+구성되어 있었다면, 이미 실행되고 완료되었다. `kubectl` 을
 사용하여 컨테이너가 `Running` 인 파드를 쿼리하면, 컨테이너가 `Running` 상태에 진입한 시기에 대한
 정보도 볼 수 있다.
 
@@ -314,7 +315,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 
 ### 언제 스타트업 프로브를 사용해야 하는가?
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
 파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
@@ -341,8 +342,10 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 적용되면, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 정상
 종료를 시도한다.
 
-일반적으로, 컨테이너 런타임은 TERM 시그널을 각 컨테이너의 기본 프로세스로
-전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
+일반적으로, 컨테이너 런타임은 각 컨테이너의 기본 프로세스에 TERM 신호를
+전송한다. 많은 컨테이너 런타임은 컨테이너 이미지에 정의된 `STOPSIGNAL` 값을 존중하며
+TERM 대신 이 값을 보낸다.
+일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
 전송되고, 그런 다음 파드는
 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가
 종료될 때까지 기다리는 동안 kubelet 또는 컨테이너 런타임의 관리 서비스가 다시 시작되면, 클러스터는
@@ -437,7 +440,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
 * [활성, 준비성 및 스타트업 프로브 설정](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)하는
   핸즈온 연습을 해보자.
 
-* [컨테이너 라이프사이클 훅](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자.
+* [컨테이너 라이프사이클 훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자.
 
 * API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
 그리고
diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 8fe6e45134..e45d00eef7 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -6,8 +6,6 @@ weight: 40
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
-
 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
 
 
@@ -16,13 +14,6 @@ weight: 40
 
 ## 필수 구성 요소
 
-### 기능 게이트 활성화
-
-를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
-{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해
-`EvenPodsSpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
-활성화되어야 한다.
-
 ### 노드 레이블
 
 토폴로지 분배 제약 조건은 노드 레이블을 의지해서 각 노드가 속한 토폴로지 도메인(들)을 인식한다. 예를 들어, 노드에 다음과 같은 레이블을 가지고 있을 수 있다. `node=node1,zone=us-east-1a,region=us-east-1`
@@ -39,13 +30,23 @@ node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
 
 그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph TB
+    subgraph "zoneB"
+        n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        n1(Node1)
+        n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다.
 
@@ -53,7 +54,7 @@ node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
 
 ### API
 
-`pod.spec.topologySpreadConstraints` 필드는 1.16에서 다음과 같이 도입되었다.
+API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
 
 ```
 apiVersion: v1
@@ -70,7 +71,15 @@ spec:
 
 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
 
-- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 한다.
+- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
+  이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는
+  파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야
+  한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
+  - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
+    대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에
+    허용되는 최대 차이이다.
+  - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
+    왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
 - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
 - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
   - `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
@@ -81,17 +90,25 @@ spec:
 
 ### 예시: 단수 토폴로지 분배 제약 조건
 
-4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
+4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 신규 파드가 기존 파드와 함께 영역에 걸쳐서 균등하게 분배되도록 하려면, 스펙(spec)은 다음과 같이 주어질 수 있다.
 
@@ -101,15 +118,46 @@ spec:
 
 만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 `maxSkew: 1` 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.
 
-```
-+---------------+---------------+      +---------------+---------------+
-|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+OR
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n3
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 사용자는 파드 스펙을 조정해서 다음과 같은 다양한 요구사항을 충족할 수 있다.
 
@@ -119,35 +167,53 @@ spec:
 
 ### 예시: 다중 토폴로지 분배 제약 조건
 
-4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
+4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 사용자는 2개의 TopologySpreadConstraints를 사용해서 영역과 노드에 파드를 분배하는 것을 제어할 수 있다.
 
 {{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
 
-이 경우에는, 첫번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
+이 경우에는, 첫 번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
 
 다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.
 
-```
-+---------------+-------+
-|     zoneA     | zoneB |
-+-------+-------+-------+
-| node1 | node2 | node3 |
-+-------+-------+-------+
-|  P P  |   P   |  P P  |
-+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p4(Pod) --> n3(Node3)
+        p5(Pod) --> n3
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n1
+        p3(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 만약 사용자가 "two-constraints.yaml" 을 이 클러스터에 적용하면, "mypod"가 `Pending` 상태로 유지되는 것을 알게 된다. 이러한 이유는, 첫 번째 제약 조건을 충족하기 위해 "mypod"는 오직 "zoneB"에만 놓을 수 있다. 두 번째 제약 조건에서는 "mypod"는 오직 "node2"에만 놓을 수 있다. 그러면 "zoneB"와 "node2"의 공동 결과는 아무것도 반환되지 않는다.
 
@@ -170,15 +236,37 @@ spec:
 
     zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
 
-    ```
-    +---------------+---------------+-------+
-    |     zoneA     |     zoneB     | zoneC |
-    +-------+-------+-------+-------+-------+
-    | node1 | node2 | node3 | node4 | node5 |
-    +-------+-------+-------+-------+-------+
-    |   P   |   P   |   P   |       |       |
-    +-------+-------+-------+-------+-------+
-    ```
+    {{<mermaid>}}
+    graph BT
+        subgraph "zoneB"
+            p3(Pod) --> n3(Node3)
+            n4(Node4)
+        end
+        subgraph "zoneA"
+            p1(Pod) --> n1(Node1)
+            p2(Pod) --> n2(Node2)
+        end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+    {{< /mermaid >}}
+
+    {{<mermaid>}}
+    graph BT
+        subgraph "zoneC"
+            n5(Node5)
+        end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n5 k8s;
+    class zoneC cluster;
+    {{< /mermaid >}}
 
     그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
 
@@ -186,7 +274,7 @@ spec:
 
 ### 클러스터 수준의 기본 제약 조건
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
@@ -194,7 +282,7 @@ spec:
 - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
 - 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
 
-기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서
+기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서
 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
@@ -203,27 +291,58 @@ spec:
 예시 구성은 다음과 같다.
 
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1alpha2
+apiVersion: kubescheduler.config.k8s.io/v1beta1
 kind: KubeSchedulerConfiguration
 
 profiles:
-  pluginConfig:
-    - name: PodTopologySpread
-      args:
-        defaultConstraints:
-          - maxSkew: 1
-            topologyKey: failure-domain.beta.kubernetes.io/zone
-            whenUnsatisfiable: ScheduleAnyway
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints:
+            - maxSkew: 1
+              topologyKey: topology.kubernetes.io/zone
+              whenUnsatisfiable: ScheduleAnyway
 ```
 
 {{< note >}}
 기본 스케줄링 제약 조건에 의해 생성된 점수는
-[`DefaultPodTopologySpread` 플러그인](/docs/reference/scheduling/profiles/#scheduling-plugins)에
+[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에
 의해 생성된 점수와 충돌 할 수 있다.
 `PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
 이 플러그인을 비활성화 하는 것을 권장한다.
 {{< /note >}}
 
+#### 내부 기본 제약
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+`DefaultPodTopologySpread` 기능 게이트를 활성화하면, 기존
+`SelectorSpread` 플러그인이 비활성화된다.
+kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
+기본 토폴로지 제약 조건을 사용한다.
+
+```yaml
+defaultConstraints:
+  - maxSkew: 3
+    topologyKey: "kubernetes.io/hostname"
+    whenUnsatisfiable: ScheduleAnyway
+  - maxSkew: 5
+    topologyKey: "topology.kubernetes.io/zone"
+    whenUnsatisfiable: ScheduleAnyway
+```
+
+또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이
+비활성화된다.
+
+{{< note >}}
+노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
+레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
+대신 자체 제약 조건을 정의한다.
+
+`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
+없는 노드에 점수를 매기지 않는다.
+{{< /note >}}
+
 ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
 
 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
@@ -234,13 +353,19 @@ profiles:
 - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에
   단 하나의 파드만 스케줄 될 수 있다.
 
-"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서
-고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
-더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다.
+더 세밀한 제어를 위해, 토폴로지 분배 제약 조건을 지정하여 다양한 토폴로지 도메인에 파드를
+분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을
+제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
+더 자세한 내용은
+[모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를
+참고한다.
 
 ## 알려진 제한사항
 
-1.18을 기준으로 이 기능은 베타(Beta)이며, 몇 가지 알려진 제한사항이 있다.
-
 - 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다.
 - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
+
+## {{% heading "whatsnext" %}}
+
+- [블로그: PodTopologySpread 소개](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)에서는
+  `maxSkew` 에 대해 자세히 설명하고, 몇 가지 고급 사용 예제를 제공한다.
diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md
index d5f424cdc7..4b14ad3c80 100644
--- a/content/ko/docs/contribute/_index.md
+++ b/content/ko/docs/contribute/_index.md
@@ -13,6 +13,13 @@ card:
 
 <!-- overview -->
 
+*쿠버네티스는 신규 및 숙련된 모든 기여자의 개선을 환영합니다!*
+
+{{< note >}}
+일반적인 쿠버네티스에 기여하는 방법에 대한 자세한 내용은
+[기여자 문서](https://www.kubernetes.dev/docs/)를 참고한다.
+{{< /note >}}
+
 이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다.
 
 쿠버네티스 문서 기여자들은
@@ -22,8 +29,6 @@ card:
 - 문서를 번역합니다.
 - 쿠버네티스 릴리스 주기에 맞추어 문서 부분을 관리하고 발행합니다.
 
-쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다!
-
 <!-- body -->
 
 ## 시작하기
diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md
index 59cde62dea..fe506a7bb1 100644
--- a/content/ko/docs/contribute/localization_ko.md
+++ b/content/ko/docs/contribute/localization_ko.md
@@ -125,9 +125,9 @@ weight: 10
 기존에 번역된 문서를 참고한다.
 
 {{% note %}}
-한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 1회 적용하고 이후에는 한글만 표기한다.
-한영 병기의 대상에는 제목도 포함되므로 제목에 한영 병기가 제공된 경우, 문서 내부에는
-한글만 표기한다.
+한영 병기는 페이지 내에서 해당 용어가 처음 사용될 때, 1회 적용하고 이후에는 한글만 표기한다.
+그러나 필요(예: 자연스러움, 명확성 향상 등)에 따라 추가적인 한영 병기를 허용한다.
+한영 병기의 대상에는 제목도 포함된다.
 {{% /note %}}
 
 ### API 오브젝트 용어 한글화 방침
diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md
index 00dc7e0251..5c8f6569da 100644
--- a/content/ko/docs/contribute/new-content/overview.md
+++ b/content/ko/docs/contribute/new-content/overview.md
@@ -43,7 +43,7 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동
 시나리오   | 브랜치
 :---------|:------------
 현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `master`
-기능 변경 릴리스의 콘텐츠 | `dev-release-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `{{< latest-version >}}` 에서 기능이 변경된 경우, ``dev-{{< release-branch >}}`` 에 문서 변경을 추가한다.
+기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
 다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
 
 
diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md
index d614905f0a..a70374295f 100644
--- a/content/ko/docs/contribute/participate/pr-wranglers.md
+++ b/content/ko/docs/contribute/participate/pr-wranglers.md
@@ -16,7 +16,7 @@ SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites
 
 PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
 
-- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)를 참고한다.
+- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다.
 - [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
   - 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다.
 - PR 기여자들이 [CLA]()에 서명했는지 확인한다.
diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md
index 252d07b332..354e9d669f 100644
--- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md
+++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md
@@ -65,7 +65,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
 최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른
 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다.
 
-1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해줄 두 명의
+1. 멤버십을 [후원](/ko/docs/contribute/advanced#새로운-기여자-후원)해줄 두 명의
    [리뷰어](#리뷰어) 또는 [승인자](#승인자)를
    찾는다.
 
diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md
index 2e76e101be..ff1c33f383 100644
--- a/content/ko/docs/contribute/review/for-approvers.md
+++ b/content/ko/docs/contribute/review/for-approvers.md
@@ -221,6 +221,3 @@ https://github.com/kubernetes/kubernetes 에서
 
 문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
 ```
-
-
-
diff --git a/content/ko/docs/contribute/suggesting-improvements.md b/content/ko/docs/contribute/suggesting-improvements.md
index c7fe87ac07..7dd9f80a71 100644
--- a/content/ko/docs/contribute/suggesting-improvements.md
+++ b/content/ko/docs/contribute/suggesting-improvements.md
@@ -24,7 +24,7 @@ card:
 
 기존 콘텐츠에 대한 개선을 제안하거나, 오류를 발견하면, 이슈를 연다.
 
-1. 페이지 하단으로 이동하여 **이슈 생성하기** 버튼을 클릭한다. 그러면 헤더가
+1. 오른쪽 사이드바에서 **문서에 이슈 생성** 링크를 클릭한다. 그러면 헤더가
  미리 채워진 GitHub 이슈 페이지로 리디렉션된다.
 2. 개선을 위한 문제나 제안 사항을 설명한다. 가능한 한 많은 정보를 제공한다.
 3. **Submit new issue** 를 클릭한다.
@@ -61,5 +61,3 @@ card:
 - [행동 강령](/ko/community/code-of-conduct/)을 따른다. 동료 기여자를
   존중한다. 예를 들어, "문서가 끔찍하다"는 도움이
   되지 않거나 예의 바르지 않은 피드백이다.
-
-
diff --git a/content/ko/docs/home/supported-doc-versions.md b/content/ko/docs/home/supported-doc-versions.md
index 9bf7edfedf..07d33e49b9 100644
--- a/content/ko/docs/home/supported-doc-versions.md
+++ b/content/ko/docs/home/supported-doc-versions.md
@@ -1,28 +1,9 @@
 ---
-title: 쿠버네티스 문서의 버전 지원
-content_type: concept
+title: 사용 가능한 문서의 버전
+content_type: custom
+layout: supported-versions
 card:
   name: about
   weight: 10
-  title: 문서의 버전 지원
+  title: 사용 가능한 문서 버전
 ---
-
-<!-- overview -->
-
-이 웹 사이트에는 현재 버전의 쿠버네티스와 이전 4개 버전의
-쿠버네티스에 대한 문서가 포함되어 있습니다.
-
-
-
-<!-- body -->
-
-## 현재 버전
-
-현재 버전은
-[{{< param "version" >}}](/).
-
-## 이전 버전
-
-{{< versions-other >}}
-
-
diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md
index 148abd29a3..86c67f4b06 100644
--- a/content/ko/docs/reference/_index.md
+++ b/content/ko/docs/reference/_index.md
@@ -33,7 +33,7 @@ content_type: concept
 ## CLI 레퍼런스
 
 * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
-    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
 
 ## 컴포넌트 레퍼런스
@@ -43,11 +43,11 @@ content_type: concept
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
-  * [kube-scheduler 정책](/docs/reference/scheduling/policies)
-  * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles)
+  * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
+  * [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
 
 ## 설계 문서
 
-쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
-
-
+쿠버네티스 기능에 대한 설계 문서의 아카이브.
+[쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와
+[쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
diff --git a/content/ko/docs/reference/access-authn-authz/_index.md b/content/ko/docs/reference/access-authn-authz/_index.md
new file mode 100644
index 0000000000..c075922ad1
--- /dev/null
+++ b/content/ko/docs/reference/access-authn-authz/_index.md
@@ -0,0 +1,4 @@
+---
+title: API 접근하기
+weight: 20
+---
\ No newline at end of file
diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md
new file mode 100644
index 0000000000..3fe13d7ced
--- /dev/null
+++ b/content/ko/docs/reference/access-authn-authz/authorization.md
@@ -0,0 +1,201 @@
+---
+title: 인가 개요
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한
+쿠버네티스 인가에 대해 자세히 알아보자.
+
+
+<!-- body -->
+쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
+인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)를
+참고한다.
+
+쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
+이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는
+기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과
+연동된다는 것을 의미한다.
+
+## 요청 허용 또는 거부 결정
+쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다.
+모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다.
+계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다.
+이는 기본적으로 승인이 거부된다는 것을 의미한다.
+
+(쿠버네티스는 API 서버를 사용하지만,
+특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은
+어드미션 컨트롤러에 의해 처리된다.)
+
+여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다.
+어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다.
+모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다.
+요청 거부는 HTTP 상태 코드 403을 반환한다.
+
+## 요청 속성 검토
+쿠버네티스는 다음 API 요청 속성만 검토한다.
+
+ * **user** - 인증 중에 제공된 `user` 문자열.
+ * **group** - 인증된 사용자가 속한 그룹 이름 목록.
+ * **extra** - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
+ * **API** - 요청이 API 리소스에 대한 것인지 여부.
+ * **Request path** - `/api` 또는 `/healthz`와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
+ * **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/ko/docs/reference/access-authn-authz/authorization/#요청-동사-결정)을 참고한다.
+ * **HTTP request verb** - `get`, `post`, `put`, `delete`처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
+ * **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
+ * **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
+ * **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
+ * **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 지정한다.
+
+## 요청 동사 결정
+
+**리소스가 아닌 요청**
+`/api/v1/...` 또는 `/apis/<group>/<version>/...` 이외에 다른 엔드포인트에 대한 요청은
+"리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다.
+예를 들어, `/api` 또는 `/healthz`와 같은 엔드포인트에 대한 `GET` 요청은 `get`을 동사로 사용할 것이다.
+
+**리소스 요청**
+리소스 API 엔드포인트에 대한 요청 동사를 결정하려면
+사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를
+검토한다.
+
+HTTP 동사 | 요청 동사
+----------|---------------
+POST      | create
+GET, HEAD | get(개별 리소스), list(전체 오브젝트 내용을 포함한 리소스 모음), watch(개별 리소스 또는 리소스 모음을 주시)
+PUT       | update
+PATCH     | patch
+DELETE    | delete(개별 리소스), deletecollection(리소스 모음)
+
+쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
+
+* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)
+  * `policy` API 그룹의 `podsecuritypolicies` 리소스에 대한 `use` 동사.
+* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
+  * `rbac.authorization.k8s.io` API 그룹의 `roles` 및 `clusterroles` 리소스에 대한 `bind` 동사.
+* [인증](/docs/reference/access-authn-authz/authentication/)
+  * 핵심 API 그룹의 `users`, `groups`, `serviceaccounts`와 `authentication.k8s.io` API 그룹의 `userextras` 동사.
+
+## 인가 모드 {#authorization-modules}
+
+쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.
+
+ * **Node** - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 [Node 인가](/docs/reference/access-authn-authz/node/)을 참조한다.
+ * **ABAC** - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 [ABAC 모드](/docs/reference/access-authn-authz/abac/)를 참조한다.
+ * **RBAC** - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 [RBAC 모드](/docs/reference/access-authn-authz/rbac/)를 참조한다.
+   * 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 `rbac.authorization.k8s.io` API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.
+   * RBAC을 활성화하려면 `--authorization-mode=RBAC`로 API 서버를 시작한다.
+ * **Webhook** - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 [Webhook 모드](/docs/reference/access-authn-authz/webhook/)를 참조한다.
+
+#### API 접근 확인
+
+`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다.
+이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며,
+사용되는 인가 모드에 관계없이 작동한다.
+
+
+```bash
+kubectl auth can-i create deployments --namespace dev
+```
+```
+yes
+```
+
+```shell
+kubectl auth can-i create deployments --namespace prod
+```
+```
+no
+```
+
+관리자는 이를 [사용자 가장(impersonation)](/docs/reference/access-authn-authz/authentication/#user-impersonation)과
+병행하여 다른 사용자가 수행할 수 있는 작업을 결정할 수 있다.
+
+```bash
+kubectl auth can-i list secrets --namespace dev --as dave
+```
+```
+no
+```
+
+`SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서
+API 서버 인가를 외부 서비스에 노출시킨다.
+이 그룹의 기타 리소스에는 다음이 포함된다.
+
+* `SubjectAccessReview` - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다.
+* `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다.
+* `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.
+
+이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인
+일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.
+
+```bash
+kubectl create -f - -o yaml << EOF
+apiVersion: authorization.k8s.io/v1
+kind: SelfSubjectAccessReview
+spec:
+  resourceAttributes:
+    group: apps
+    resource: deployments
+    verb: create
+    namespace: dev
+EOF
+```
+
+생성된 `SelfSubjectAccessReview` 는 다음과 같다.
+```
+apiVersion: authorization.k8s.io/v1
+kind: SelfSubjectAccessReview
+metadata:
+  creationTimestamp: null
+spec:
+  resourceAttributes:
+    group: apps
+    resource: deployments
+    namespace: dev
+    verb: create
+status:
+  allowed: true
+  denied: false
+```
+
+## 인가 모듈에 플래그 사용
+
+정책에 포함된 인가 모듈을 나타내기 위해
+정책에 플래그를 포함시켜야 한다.
+
+다음 플래그를 사용할 수 있다.
+
+  * `--authorization-mode=ABAC` 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다.
+  * `--authorization-mode=RBAC` 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다.
+  * `--authorization-mode=Webhook` WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다.
+  * `--authorization-mode=Node` 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다.
+  * `--authorization-mode=AlwaysDeny` 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다.
+  * `--authorization-mode=AlwaysAllow` 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.
+
+하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에
+우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
+
+## 파드 생성을 통한 권한 확대
+
+네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는
+해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다.
+네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다.
+사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나
+서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.
+
+{{< caution >}}
+시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다.
+네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는
+네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고
+네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다.
+이는 인가 모드에 관계없이 적용된다.
+{{< /caution >}}
+
+
+## {{% heading "whatsnext" %}}
+
+* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
+* 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다.
diff --git a/content/ko/docs/reference/access-authn-authz/controlling-access.md b/content/ko/docs/reference/access-authn-authz/controlling-access.md
new file mode 100644
index 0000000000..d9f34a202e
--- /dev/null
+++ b/content/ko/docs/reference/access-authn-authz/controlling-access.md
@@ -0,0 +1,161 @@
+---
+title: 쿠버네티스 API 접근 제어하기
+content_type: concept
+weight: 5
+---
+
+<!-- overview -->
+이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.
+
+
+<!-- body -->
+사용자는 `kubectl`, 클라이언트 라이브러리
+또는 REST 요청을 통해
+[API에 접근한다](/ko/docs/tasks/access-application-cluster/access-cluster/).
+사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
+요청이 API에 도달하면,
+다음 다이어그램에 설명된 몇 가지 단계를 거친다.
+
+![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
+
+## 전송 보안
+
+일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
+API 서버는 인증서를 제시한다.
+이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
+API 서버의 인증서에 대한 루트 인증서를 포함하며,
+시스템 기본 루트 인증서 대신 사용된다.
+`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
+이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
+클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
+
+## 인증
+
+TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
+이는 다이어그램에 **1**단계로 표시되어 있다.
+클러스터 생성 스크립트 또는 클러스터 관리자는
+API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
+인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
+
+인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
+일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
+
+인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
+JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
+
+여러 개의 인증 모듈을 지정할 수 있으며,
+이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
+
+GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
+
+요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
+이 외에는 사용자가 특정 `username`으로 인증되며,
+이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
+일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면,
+이외의 인증기는 그렇지 않다.
+
+쿠버네티스는 접근 제어 결정과 요청 기록 시 `usernames`를 사용하지만,
+`user` 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를
+오브젝트 저장소에 저장하지도 않는다.
+
+## 인가
+
+특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 **2**단계로 표시되어 있다.
+
+요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
+
+예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 `projectCaribou` 네임스페이스에서만 파드를 읽을 수 있다.
+
+```json
+{
+    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
+    "kind": "Policy",
+    "spec": {
+        "user": "bob",
+        "namespace": "projectCaribou",
+        "resource": "pods",
+        "readonly": true
+    }
+}
+```
+Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의 오브젝트를 읽을 수 있기 때문에 요청이 인가된다.
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "projectCaribou",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    }
+  }
+}
+```
+Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.
+
+쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
+
+쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
+
+인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.
+
+
+## 어드미션 제어
+
+어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다.
+인가 모듈에서 사용할 수 있는 속성 외에도
+어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
+
+어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
+어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
+여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
+
+이는 다이어그램에 **3**단계로 표시되어 있다.
+
+인증 및 인가 모듈과 달리,
+어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
+
+어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도
+필드의 복잡한 기본값을 설정할 수 있다.
+
+사용 가능한 어드미션 제어 모듈은 [여기](/docs/reference/access-authn-authz/admission-controllers/)에 서술되어 있다.
+
+요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
+오브젝트 저장소에 기록(**4**단계)된다.
+
+
+## API 서버 포트와 IP
+
+이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
+API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
+
+기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
+
+  1. `로컬호스트 포트`:
+
+      - 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
+        (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
+      - TLS가 없다.
+      - 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다.
+      - 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
+      - 요청이 인증 및 인가 모듈을 **우회한다**.
+      - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
+      - 호스트 접근 요구로부터 보호를 받는다.
+
+  2. `보안 포트`:
+
+      - 가능한 항상 사용하는 것이 좋다.
+      - TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
+      - 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
+      - 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
+      - 요청이 인증 및 인가 모듈에 의해 처리된다.
+      - 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
+      - 인증 및 인가 모듈을 실행한다.
+
+GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
+API 서버는 포트 443에서 서비스한다.
+GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
+이외에 클러스터 설정 방법은 다양하다.
diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
new file mode 100644
index 0000000000..1b7da703dc
--- /dev/null
+++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
@@ -0,0 +1,112 @@
+---
+title: 서비스 어카운트 관리하기
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
+독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
+
+인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
+가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.
+
+
+<!-- body -->
+## 사용자 어카운트와 서비스 어카운트 비교
+
+쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
+구분한다.
+
+  - 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
+    위한 것이다.
+  - 사용자 어카운트는 전역을 대상으로 고려된다.
+    클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다.
+    서비스 어카운트는 네임스페이스에 할당된다.
+  - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
+    여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
+    서비스 어카운트 생성은
+    클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록
+    보다 가볍게 만들어졌다.
+  - 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
+  - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
+    서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에
+    이러한 설정은 이식성이 좋다.
+
+## 서비스 어카운트 자동화
+
+서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
+
+  - 서비스 어카운트 어드미션 컨트롤러
+  - 토큰 컨트롤러
+  - 서비스 어카운트 컨트롤러
+
+### 서비스 어카운트 어드미션 컨트롤러
+
+파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
+라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다.
+파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
+이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
+
+  1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다.
+  1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다.
+  1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다.
+  1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
+  1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다.
+
+v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
+서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
+[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다.
+
+### 토큰 컨트롤러
+
+토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
+
+- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다.
+- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다.
+- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다.
+- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다.
+
+서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다.
+개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
+마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다.
+공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.
+
+#### 추가적인 API 토큰 생성
+
+컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다.
+서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해
+서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면
+컨트롤러가 새로 생성된 토큰으로 갱신한다.
+
+secret.json:
+
+```json
+{
+    "kind": "Secret",
+    "apiVersion": "v1",
+    "metadata": {
+        "name": "mysecretname",
+        "annotations": {
+            "kubernetes.io/service-account.name": "myserviceaccount"
+        }
+    },
+    "type": "kubernetes.io/service-account-token"
+}
+```
+
+```shell
+kubectl create -f ./secret.json
+kubectl describe secret mysecretname
+```
+
+#### 서비스 어카운트 토큰 삭제/무효화
+
+```shell
+kubectl delete secret mysecretname
+```
+
+### 서비스 어카운트 컨트롤러
+
+서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고
+"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md
index 0639d05b15..14025d0f71 100644
--- a/content/ko/docs/reference/command-line-tools-reference/_index.md
+++ b/content/ko/docs/reference/command-line-tools-reference/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 커맨드 라인 도구 레퍼런스
 weight: 60
-toc-hide: true
 ---
diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
index 1e2796b484..11dc7f26b6 100644
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@@ -67,7 +67,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
 | `CSIMigrationAWS` | `false` | 베타 | 1.17 | |
 | `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | |
-| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | |
+| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
+| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | |
 | `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | |
 | `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | |
 | `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | |
@@ -76,15 +77,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | |
 | `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | |
 | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
+| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
+| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
+| `CSIStorageCapacity` | `false` | 알파 | 1.19 | |
+| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | |
 | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
 | `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
+| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | |
 | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | 베타 | 1.10 | |
+| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.20 |
 | `DryRun` | `false` | 알파 | 1.12 | 1.12 |
 | `DryRun` | `true` | 베타 | 1.13 | |
-| `DynamicAuditing` | `false` | 알파 | 1.13 | |
 | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | |
 | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
@@ -99,12 +105,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
-| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
-| `EvenPodsSpread` | `true` | 베타 | 1.18 | |
+| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | |
 | `HPAScaleToZero` | `false` | 알파 | 1.16 | |
-| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | |
+| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
+| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
 | `HyperVContainer` | `false` | 알파 | 1.10 | |
-| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | |
+| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
+| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | |
 | `IPv6DualStack` | `false` | 알파 | 1.16 | |
 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | 베타 | 1.15 | |
@@ -113,34 +120,37 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
 | `MountContainers` | `false` | 알파 | 1.9 | |
-| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | |
-| `NonPreemptingPriority` | `false` | 알파 | 1.15 | |
+| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
+| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | |
+| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
+| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
 | `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
 | `PodDisruptionBudget` | `true` | 베타 | 1.5 | |
 | `PodOverhead` | `false` | 알파 | 1.16 | - |
 | `ProcMountType` | `false` | 알파 | 1.12 | |
 | `QOSReserved` | `false` | 알파 | 1.11 | |
 | `RemainingItemCount` | `false` | 알파 | 1.15 | |
-| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | |
-| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | |
 | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
 | `RunAsGroup` | `true` | 베타 | 1.14 | |
 | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | 베타 | 1.14 | |
-| `SCTPSupport` | `false` | 알파 | 1.12 | |
+| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | 베타 | 1.19 | |
+| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
 | `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
-| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | |
+| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
+| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
+| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | |
 | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
 | `StartupProbe` | `true` | 베타 | 1.18 | |
 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | 베타 | 1.15 | |
-| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
-| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | |
 | `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 |
 | `SupportNodePidsLimit` | `true` | 베타 | 1.15 | |
 | `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 |
@@ -156,6 +166,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
 | `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
 | `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | - |
+| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |
 | `WindowsGMSA` | `false` | 알파 | 1.14 | |
 | `WindowsGMSA` | `true` | 베타 | 1.16 | |
 | `WinDSR` | `false` | 알파 | 1.14 | |
@@ -210,6 +221,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 |
 | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
+| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
+| `DynamicAuditing` | - | 사용 중단 | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
@@ -218,6 +231,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
 | `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - |
+| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
+| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
+| `EvenPodsSpread` | `true` | GA | 1.19 | - |
 | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | 알파 | 1.8 | 1.9 |
@@ -251,9 +267,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
 | `PVCProtection` | - | 사용 중단 | 1.10 | - |
 | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 |
+| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 |
+| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | - |
 | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 |
 | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 |
 | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
+| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 |
+| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
 | `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
 | `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16  |
 | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
@@ -262,6 +282,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
 | `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
+| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
+| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 |
+| `StreamingProxyRedirects` | - | 사용 중단| 1.19 | - |
 | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
@@ -343,13 +366,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의
   `DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다.
 - `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`) 리소스를 청크(chunks)로 검색할 수 있도록 한다.
-- `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 ​​있다. (`RequestManagement` 에서 이름이 변경됨)
+- `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
 - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
 - `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
    자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
 - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
   대한 제한을 보고하도록 한다.
-   자세한 내용은 [동적 볼륨 제한](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)을 참고한다.
+   자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
 - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
   포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
   더 가까운 노드가 선호된다.
@@ -377,11 +400,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 필요하다.
 - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
 - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
 - `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
 - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
   호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
   마운트할 수 있다.
   자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
+- `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
+  자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
+- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다.
 - `CustomCPUCFSQuotaPeriod`: 노드가 CPUCFSQuotaPeriod를 변경하도록 한다.
 - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
   자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
@@ -395,11 +423,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
   생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
   실행 중인 파드 문제를 해결한다.
+- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/).
 - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
   기반 리소스 프로비저닝을 활성화한다.
+- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
+  [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
 - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
   요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
 - `DynamicAuditing`: [동적 감사](/docs/tasks/debug-application-cluster/audit/#dynamic-backend) 기능을 활성화한다.
+- `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
 - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
 - `DynamicProvisioningScheduling`: 볼륨 스케줄을 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다.
   이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다.
@@ -420,10 +452,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
   재 매핑이 활성화된 경우에만 활성화해야 한다.
 - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한
   엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
-- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, kube-proxy는
-  엔드포인트슬라이스를 엔드포인트 대신 기본 데이터 소스로 사용하여
-  확장성과 성능을 향상시킨다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, 리눅스에서 실행되는
+  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
+  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
+  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+- `WindowsEndpointSliceProxying`: 이 기능 게이트가 활성화되면, 윈도우에서 실행되는
+  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
+  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
+  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
+- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
 - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다.
 - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다.
 - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다.
@@ -435,9 +473,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
   플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
 - `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다.
    자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다.
-- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다.
+- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다.
 - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다.
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 대해 `LocalStorageCapacityIsolation`이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)에 대한 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 프로젝트 쿼터를 사용하여 파일시스템 사용보다는 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 `LocalStorageCapacityIsolation` 이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는 프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
 - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
 - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
   자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
@@ -460,7 +498,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
   삭제되지 않도록 한다.  
 - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서
   요청된 리소스로 파열되는 것을 방지한다(현재 메모리만 해당).
-- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중
+- `ResourceLimitsPriorityFunction` (*사용 중단됨*): 입력 파드의 CPU 및 메모리 한도 중
   하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는
   스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진
   노드 사이의 관계를 끊는 것이다.
@@ -472,7 +510,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다.
 - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다.
 - `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다.
-- `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다.
+- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다.
 - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다.
 - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다.
 - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
@@ -480,6 +518,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다.
   "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다.
 - `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다.
+- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
 - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다.
 - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
   사용 중인 경우 삭제를 연기한다.
diff --git a/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
new file mode 100644
index 0000000000..61f0b35d1f
--- /dev/null
+++ b/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
@@ -0,0 +1,83 @@
+---
+title: Kubelet 인증/인가
+---
+
+
+## 개요
+
+kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 노출시키며,
+노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.
+
+이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.
+
+## Kubelet 인증
+
+기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 kubelet의 HTTPS 엔드포인트에 대한 요청은
+익명의 요청으로 처리되며, `system:anonymous`의 사용자 이름과 `system:unauthenticated`
+의 그룹이 부여된다.
+
+익명의 접근을 비활성화하고 인증되지 않은 요청에 `401 Unauthorized` 응답을 보내려면 아래를 참고한다.
+
+* `--anonymous-auth=false` 플래그로 kubelet을 시작
+
+kubelet의 HTTPS 엔드포인트에 대한 X509 클라이언트 인증서 인증을 활성화하려면 아래를 참고한다.
+
+* `--client-ca-file` 플래그로 kubelet을 시작하면 클라이언트 인증서를 확인할 수 있는 CA 번들을 제공
+* `--kubelet-client-certificate` 및 `--kubelet-client-key` 플래그로 apiserver를 시작
+* 자세한 내용은 [apiserver 인증 문서](/docs/reference/access-authn-authz/authentication/#x509-client-certs)를 참고
+
+API bearer 토큰(서비스 계정 토큰 포함)을 kubelet의 HTTPS 엔드포인트 인증에 사용하려면 아래를 참고한다.
+
+* API 서버에서 `authentication.k8s.io/v1beta1` API 그룹이 사용 가능한지 확인
+* `--authentication-token-webhook` 및 `--kubeconfig` 플래그로 kubelet을 시작
+* kubelet은 구성된 API 서버의 `TokenReview` API를 호출하여 bearer 토큰에서 사용자 정보를 결정
+
+## Kubelet 승인
+
+성공적으로 인증된 모든 요청(익명 요청 포함)이 승인된다. 기본 인가 모드는 모든 요청을 허용하는 `AlwaysAllow` 이다.
+
+kubelet API에 대한 접근을 세분화하는 데는 다양한 이유가 있다.
+
+* 익명 인증을 사용할 수 있지만, 익명 사용자의 kubelet API 호출 기능은 제한되어야 함
+* bearer 토큰 인증을 사용할 수 있지만, 임의의 API 사용자(API 계정)의 kubelet API 호출 기능은 제한되어야 함
+* 클라이언트 인증을 사용할 수 있지만, 구성된 CA에서 서명한 일부 클라이언트 인증서만 kubelet API를 사용하도록 허용해야 함
+
+kubelet API에 대한 접근을 세분화하려면 API 서버에 권한을 위임한다.
+
+* `authorization.k8s.io/v1beta1` API 그룹이 API 서버에서 사용 가능한지 확인
+* `--authorization-mode=Webhook` 및 `--kubeconfig` 플래그로 kubelet을 시작
+* kubelet은 구성된 API 서버의 `SubjectAccessReview` API를 호출하여 각각의 요청이 승인되었는지 여부를 확인
+
+kubelet은 API 요청을 apiserver와 동일한 [요청 속성](/ko/docs/reference/access-authn-authz/authorization/#요청-속성-검토) 접근 방식을 사용하여 승인한다.
+
+동사는 들어오는 요청의 HTTP 동사로부터 결정된다.
+
+HTTP 동사 | 요청 동사
+----------|---------------
+POST      | create
+GET, HEAD | get
+PUT       | update
+PATCH     | patch
+DELETE    | delete
+
+리소스 및 하위 리소스는 들어오는 요청의 경로로부터 결정된다.
+
+Kubelet API  | 리소스 | 하위 리소스
+-------------|----------|------------
+/stats/\*     | nodes    | stats
+/metrics/\*   | nodes    | metrics
+/logs/\*      | nodes    | log
+/spec/\*      | nodes    | spec
+*all others* | nodes    | proxy
+
+네임스페이스와 API 그룹 속성은 항상 빈 문자열이며,
+리소스 이름은 항상 kubelet의 `Node` API 오브젝트 이름이다.
+
+이 모드로 실행할 때, `--kubelet-client-certificate` 및 `--kubelet-client-key` 플래그로 식별된 사용자에게
+다음 속성에 대한 권한이 있는지 확인한다.
+
+* verb=\*, resource=nodes, subresource=proxy
+* verb=\*, resource=nodes, subresource=stats
+* verb=\*, resource=nodes, subresource=log
+* verb=\*, resource=nodes, subresource=spec
+* verb=\*, resource=nodes, subresource=metrics
diff --git a/content/ko/docs/reference/glossary/cloud-provider.md b/content/ko/docs/reference/glossary/cloud-provider.md
index e649147b32..31bf473f46 100644
--- a/content/ko/docs/reference/glossary/cloud-provider.md
+++ b/content/ko/docs/reference/glossary/cloud-provider.md
@@ -2,7 +2,6 @@
 title: 클라우드 공급자
 id: cloud-provider
 date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
 short_description: >
   클라우드 컴퓨팅 플랫폼을 제공하는 조직.
 
@@ -26,6 +25,6 @@ Infrastructure as a Service 또는 IaaS 라 부른다).
 
 사용자는 쿠버네티스를 관리되는 서비스로 찾을 수 있다. 때로는 이것을
 Platform as a Service 또는 PaaS라 부른다. 관리되는 쿠버네티스를 사용하면
-클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라, 
+클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라,
 노드와 연관되는 인프라(네트워킹, 스토리지 그리고 로드밸런서와 같은 기타 요소)
 를 책임진다.
diff --git a/content/ko/docs/reference/glossary/index.md b/content/ko/docs/reference/glossary/index.md
index c7a4b3a927..9af1b3d078 100755
--- a/content/ko/docs/reference/glossary/index.md
+++ b/content/ko/docs/reference/glossary/index.md
@@ -7,6 +7,6 @@ weight: 5
 card:
   name: reference
   weight: 10
-  title: Glossary
+  title: 용어집
 ---
 
diff --git a/content/ko/docs/reference/glossary/kube-apiserver.md b/content/ko/docs/reference/glossary/kube-apiserver.md
index b219acb340..201bc3780e 100644
--- a/content/ko/docs/reference/glossary/kube-apiserver.md
+++ b/content/ko/docs/reference/glossary/kube-apiserver.md
@@ -2,21 +2,21 @@
 title: API 서버
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-apiserver/
+full_link: /ko/docs/concepts/overview/components/#kube-apiserver
 short_description: >
   쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트.
 
-aka: 
+aka:
 - kube-apiserver
 tags:
 - architecture
 - fundamental
 ---
- API 서버는 쿠버네티스 API를 
+ API 서버는 쿠버네티스 API를
 노출하는 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다.
 API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.
 
-<!--more--> 
+<!--more-->
 
 쿠버네티스 API 서버의 주요 구현은 [kube-apiserver](/docs/reference/generated/kube-apiserver/) 이다.
 kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다.
diff --git a/content/ko/docs/reference/glossary/kubelet.md b/content/ko/docs/reference/glossary/kubelet.md
index 671a50173b..caf6ba894b 100644
--- a/content/ko/docs/reference/glossary/kubelet.md
+++ b/content/ko/docs/reference/glossary/kubelet.md
@@ -6,14 +6,12 @@ full_link: /docs/reference/generated/kubelet
 short_description: >
   클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.
 
-aka: 
+aka:
 tags:
 - fundamental
-- core-object
 ---
  클러스터의 각 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행되는 에이전트. Kubelet은 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 {{< glossary_tooltip text="컨테이너" term_id="container" >}}가 확실하게 동작하도록 관리한다.
 
-<!--more--> 
+<!--more-->
 
 Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
-
diff --git a/content/ko/docs/reference/glossary/managed-service.md b/content/ko/docs/reference/glossary/managed-service.md
index 282bc7e9d6..7ecf8aa1d8 100644
--- a/content/ko/docs/reference/glossary/managed-service.md
+++ b/content/ko/docs/reference/glossary/managed-service.md
@@ -1,18 +1,22 @@
 ---
-title: 매니지드 서비스
+title: 매니지드 서비스(Managed Service)
 id: managed-service
 date: 2018-04-12
-full_link: 
+full_link:
 short_description: >
   타사 공급자가 유지보수하는 소프트웨어.
 
-aka: 
+aka:
 
 tags:
 - extension
 ---
- 타사 공급자가 유지보수하는 소프트웨어. 
+ 타사 공급자가 유지보수하는 소프트웨어.
 
-<!--more--> 
+<!--more-->
 
-매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다. [서비스 카탈로그](/docs/concepts/service-catalog/)는 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
+매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고
+GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다.
+[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
+{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는
+매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
diff --git a/content/ko/docs/reference/glossary/pod-lifecycle.md b/content/ko/docs/reference/glossary/pod-lifecycle.md
index 52f107ecb9..cdec826e9d 100644
--- a/content/ko/docs/reference/glossary/pod-lifecycle.md
+++ b/content/ko/docs/reference/glossary/pod-lifecycle.md
@@ -16,4 +16,4 @@ short-description: >
 
 <!--more--> 
  
-[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
+[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. [파드 스테이터스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)의 `phase` 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.
diff --git a/content/ko/docs/reference/glossary/service-broker.md b/content/ko/docs/reference/glossary/service-broker.md
new file mode 100644
index 0000000000..bd67184898
--- /dev/null
+++ b/content/ko/docs/reference/glossary/service-broker.md
@@ -0,0 +1,22 @@
+---
+title: 서비스 브로커(Service Broker)
+id: service-broker
+date: 2018-04-12
+full_link:
+short_description: >
+  서드파티에서 제공하고 유지 관리하는 일련의 매니지드 서비스에 대한 엔드포인트이다.
+
+aka:
+tags:
+- extension
+---
+ 서드파티에서 제공하고 유지 관리하는 일련의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}에 대한 엔드포인트이다.
+
+<!--more-->
+
+{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}는
+[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)를
+구현하고 애플리케이션이 매니지드 서비스를 사용할 수 있도록 표준 인터페이스를 제공한다.
+[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
+서비스 브로커가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
+
diff --git a/content/ko/docs/reference/issues-security/_index.md b/content/ko/docs/reference/issues-security/_index.md
index a1f56bc08e..596a6e01a4 100644
--- a/content/ko/docs/reference/issues-security/_index.md
+++ b/content/ko/docs/reference/issues-security/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 쿠버네티스 이슈와 보안
 weight: 10
-toc-hide: true
 ---
diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md
index 3446c11a06..bf3e0cc81d 100644
--- a/content/ko/docs/reference/kubectl/cheatsheet.md
+++ b/content/ko/docs/reference/kubectl/cheatsheet.md
@@ -8,16 +8,10 @@ card:
 
 <!-- overview -->
 
-참고 항목: [Kubectl 개요](/ko/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath).
-
-이 페이지는 `kubectl` 커맨드의 개요이다.
-
-
+이 페이지는 일반적으로 사용하는 `kubectl` 커맨드와 플래그에 대한 목록을 포함한다.
 
 <!-- body -->
 
-# kubectl - 치트 시트
-
 ## Kubectl 자동 완성
 
 ### BASH
@@ -77,7 +71,8 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
 kubectl config unset users.foo                       # foo 사용자 삭제
 ```
 
-## Apply
+## Kubectl apply
+
 `apply`는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. `kubectl apply`를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. [Kubectl Book](https://kubectl.docs.kubernetes.io)을 참고한다.
 
 ## 오브젝트 생성
@@ -200,6 +195,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp
 
 # 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다.
 kubectl diff -f ./my-manifest.yaml
+
+# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
+# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
+kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+
+# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
+kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
 ```
 
 ## 리소스 업데이트
@@ -249,6 +251,7 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1",
 ```
 
 ## 리소스 편집
+
 편집기로 모든 API 리소스를 편집.
 
 ```bash
@@ -382,15 +385,12 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
 `--v=8` | HTTP 요청 내용을 표시.
 `--v=9` | 내용을 잘라 내지 않고 HTTP 요청 내용을 표시.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
-* [kubectl 개요](/ko/docs/reference/kubectl/overview/)에 대해 더 배워보자.
+* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자.
 
 * [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
 
 * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다.
 
-* 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인
+* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.
diff --git a/content/ko/docs/reference/kubectl/conventions.md b/content/ko/docs/reference/kubectl/conventions.md
new file mode 100644
index 0000000000..de771c2d65
--- /dev/null
+++ b/content/ko/docs/reference/kubectl/conventions.md
@@ -0,0 +1,62 @@
+---
+title: kubectl 사용 규칙
+
+
+content_type: concept
+---
+
+<!-- overview -->
+`kubectl`에 대한 권장 사용 규칙.
+
+
+<!-- body -->
+
+## 재사용 가능한 스크립트에서 `kubectl` 사용
+
+스크립트의 안정적인 출력을 위해서
+
+* `-o name`, `-o json`, `-o yaml`, `-o go-template` 혹은 `-o jsonpath`와 같은 머신 지향(machine-oriented) 출력 양식 중 하나를 요청한다.
+* 예를 들어 `jobs.v1.batch/myjob`과 같이 전체 버전을 사용한다. 이를 통해 `kubectl`이 시간이 지남에 따라 변경될 수 있는 기본 버전을 사용하지 않도록 한다.
+* 문맥, 설정 또는 기타 암묵적 상태에 의존하지 않는다.
+
+## 모범 사례
+
+### `kubectl run`
+
+`kubectl run`으로 infrastructure as code를 충족시키기 위해서
+
+* 버전이 명시된 태그로 이미지를 태그하고 그 태그를 새로운 버전으로 이동하지 않는다. 예를 들어, `:latest`가 아닌 `:v1234`, `v1.2.3`, `r03062016-1-4`를 사용한다(자세한 정보는 [구성 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다).
+* 많은 파라미터가 적용된 이미지를 위한 스크립트를 작성한다.
+* 필요하지만 `kubectl run` 플래그를 통해 표현할 수 없는 기능은 구성 파일을 소스 코드 버전 관리 시스템에 넣어서 전환한다.
+
+`--dry-run` 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.
+
+{{< note >}}
+모든 `kubectl`의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 [목록](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
+{{< /note >}}
+
+#### 생성기
+`kubectl create --dry-run -o yaml`라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성 할 수 있다.
+```
+  clusterrole         클러스터롤(ClusterRole)를 생성한다.
+  clusterrolebinding  특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
+  configmap           로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
+  cronjob             지정된 이름으로 크론잡(CronJob)을 생성한다.
+  deployment          지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
+  job                 지정된 이름으로 잡(Job)을 생성한다.
+  namespace           지정된 이름으로 네임스페이스(Namespace)를 생성한다.
+  poddisruptionbudget 지정된 이름으로 pod disruption budget을 생성한다.
+  priorityclass       지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
+  quota               지정된 이름으로 쿼터(Quota)를 생성한다.
+  role                단일 규칙으로 롤(Role)을 생성한다.
+  rolebinding         특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
+  secret              지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
+  service             지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
+  serviceaccount      지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
+```
+
+### `kubectl apply`
+
+* `kubectl apply`를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 [Kubectl 책](https://kubectl.docs.kubernetes.io)을 참고한다.
+
+
diff --git a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md
new file mode 100644
index 0000000000..e81dd65b4a
--- /dev/null
+++ b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md
@@ -0,0 +1,372 @@
+---
+title: 도커 사용자를 위한 kubectl
+content_type: concept
+
+
+
+---
+
+<!-- overview -->
+당신은 쿠버네티스 커맨드 라인 도구인 kubectl을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl과 같은 명령어를 설명한다.
+
+
+<!-- body -->
+## docker run
+
+nginx 디플로이먼트(Deployment)를 실행하고 해당 디플로이먼트를 노출시키려면, [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-)을 참고한다.
+docker:
+
+```shell
+docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
+```
+```
+55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
+```
+
+```shell
+docker ps
+```
+```
+CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
+55c103fa1296        nginx               "nginx -g 'daemon of…"   9 seconds ago       Up 9 seconds        0.0.0.0:80->80/tcp   nginx-app
+```
+
+kubectl:
+
+```shell
+# nginx 실행하는 파드를 시작한다
+kubectl create deployment --image=nginx nginx-app
+```
+
+```shell
+# nginx-app 에 env를 추가한다
+kubectl set env deployment/nginx-app  DOMAIN=cluster
+```
+```
+deployment.apps/nginx-app created
+```
+
+```
+# nginx-app 에 env를 추가한다
+kubectl set env deployment/nginx-app  DOMAIN=cluster
+```
+```
+deployment.apps/nginx-app env updated
+```
+
+{{< note >}}
+`kubectl` 커맨드는 생성되거나 변경된 리소스의 유형과 이름을 출력하므로, 이를 후속 커맨드에 사용할 수 있다. 디플로이먼트가 생성된 후에는 새로운 서비스를 노출할 수 있다.
+{{< /note >}}
+
+```shell
+# 서비스를 통해 포트를 노출
+kubectl expose deployment nginx-app --port=80 --name=nginx-http
+```
+```
+service "nginx-http" exposed
+```
+
+kubectl을 사용하면, N개의 파드가 nginx를 실행하도록 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 생성할 수 있다. 여기서 N은 스펙에 명시된 레플리카 수이며, 기본값은 1이다. 또한 파드의 레이블과 셀럭터를 사용하여 서비스를 생성할 수 있다. 자세한 내용은 [클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster)를 참고한다.
+
+기본적으로 이미지는 `docker run -d ...` 와 비슷하게 백그라운드로 실행된다. 포그라운드로 실행하려면 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하여 파드를 생성한다.
+```shell
+kubectl run [-i] [--tty] --attach <name> --image=<image>
+```
+
+`docker run ...` 과 달리 `--attach` 를 지정하면 `표준 입력(stdin)`, `표준 출력(stdout)` 및 `표준 오류(stderr)`가 붙는다. 연결된(attached) 스트림을 제어할 수 없다(`docker -a ...`).
+해당 컨테이너에서 분리(detach)하려면 이스케이프 시퀀스(escape sequence) Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
+
+## docker ps
+
+현재 실행 중인 목록을 보기 위해서는 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)을 참고한다.
+
+docker:
+
+```shell
+docker ps -a
+```
+```
+CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                     PORTS                NAMES
+14636241935f        ubuntu:16.04        "echo test"              5 seconds ago        Exited (0) 5 seconds ago                        cocky_fermi
+55c103fa1296        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute          0.0.0.0:80->80/tcp   nginx-app
+```
+
+kubectl:
+
+```shell
+kubectl get po
+```
+```
+NAME                        READY     STATUS      RESTARTS   AGE
+nginx-app-8df569cb7-4gd89   1/1       Running     0          3m
+ubuntu                      0/1       Completed   0          20s
+```
+
+## docker attach
+
+이미 실행 중인 컨테이너에 연결하려면 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)를 참고한다.
+
+docker:
+
+```shell
+docker ps
+```
+```
+CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
+55c103fa1296        nginx               "nginx -g 'daemon of…"   5 minutes ago       Up 5 minutes        0.0.0.0:80->80/tcp   nginx-app
+```
+
+```shell
+docker attach 55c103fa1296
+...
+```
+
+kubectl:
+
+```shell
+kubectl get pods
+```
+```
+NAME              READY     STATUS    RESTARTS   AGE
+nginx-app-5jyvm   1/1       Running   0          10m
+```
+
+```shell
+kubectl attach -it nginx-app-5jyvm
+...
+```
+
+컨테이너에서 분리하려면 이스케이프 시퀀스 Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
+
+## docker exec
+
+컨테이너에서 커맨드를 실행하려면 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 참고한다.
+
+docker:
+
+```shell
+docker ps
+```
+```
+CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
+55c103fa1296        nginx               "nginx -g 'daemon of…"   6 minutes ago       Up 6 minutes        0.0.0.0:80->80/tcp   nginx-app
+```
+```shell
+docker exec 55c103fa1296 cat /etc/hostname
+```
+```
+55c103fa1296
+```
+
+kubectl:
+
+```shell
+kubectl get po
+```
+```
+NAME              READY     STATUS    RESTARTS   AGE
+nginx-app-5jyvm   1/1       Running   0          10m
+```
+
+```shell
+kubectl exec nginx-app-5jyvm -- cat /etc/hostname
+```
+```
+nginx-app-5jyvm
+```
+
+대화형 커맨드를 사용한다.
+
+
+docker:
+
+```shell
+docker exec -ti 55c103fa1296 /bin/sh
+# exit
+```
+
+kubectl:
+
+```shell
+kubectl exec -ti nginx-app-5jyvm -- /bin/sh
+# exit
+```
+
+자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
+
+## docker logs
+
+실행 중인 프로세스의 표준 입력(stdout)/표준 오류(stderr)를 수행하려면 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)를 참고한다.
+
+
+docker:
+
+```shell
+docker logs -f a9e
+```
+```
+192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
+192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
+```
+
+kubectl:
+
+```shell
+kubectl logs -f nginx-app-zibvs
+```
+```
+10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
+10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
+```
+
+파드와 컨테이너에는 근소한 차이가 있다. 기본적으로 파드는 프로세스가 종료되어도 종료되지 않는다. 대신 파드가 프로세스를 다시 시작한다. 이는 도커의 실행 옵션인 `--restart=always`와 유사하지만, 한 가지 큰 차이점이 있다. 도커에서는 프로세스의 각 호출에 대한 출력이 연결되지만, 쿠버네티스의 경우 각 호출은 별개다. 쿠버네티스에서 이전 실행의 출력 내용을 보려면 다음을 수행한다.
+
+```shell
+kubectl logs --previous nginx-app-zibvs
+```
+```
+10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
+10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
+```
+
+자세한 정보는 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참고한다.
+
+## docker stop 과 docker rm
+
+실행 중인 프로세스를 중지하고 삭제하려면 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)을 참고한다.
+
+docker:
+
+```shell
+docker ps
+```
+```
+CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                         NAMES
+a9ec34d98787        nginx               "nginx -g 'daemon of"  22 hours ago        Up 22 hours         0.0.0.0:80->80/tcp, 443/tcp   nginx-app
+```
+
+```shell
+docker stop a9ec34d98787
+```
+```
+a9ec34d98787
+```
+
+```shell
+docker rm a9ec34d98787
+```
+```
+a9ec34d98787
+```
+
+kubectl:
+
+```shell
+kubectl get deployment nginx-app
+```
+```
+NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+nginx-app    1/1     1            1           2m
+```
+
+```shell
+kubectl get po -l run=nginx-app
+```
+```
+NAME                         READY     STATUS    RESTARTS   AGE
+nginx-app-2883164633-aklf7   1/1       Running   0          2m
+```
+```shell
+kubectl delete deployment nginx-app
+```
+```
+deployment "nginx-app" deleted
+```
+
+```shell
+kubectl get po -l run=nginx-app
+# 아무것도 반환하지 않는다
+```
+
+{{< note >}}
+kubectl을 사용할 때는 파드를 직접 삭제하지 않는다. 먼저 파드를 소유한 디플로이먼트를 삭제해야 한다. 만약 파드를 직접 삭제하면 디플로이먼트가 파드를 재생성할 것이다.
+{{< /note >}}
+
+## docker login
+
+kubectl은 `docker login`와 직접적인 유사점은 없다. 프라이빗 레지스트리와 함께 쿠버네티스를 사용하려면 [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)을 참고한다.
+
+## docker version
+
+클라이언트와 서버의 버전을 가져오려면 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)을 참고한다.
+
+docker:
+
+```shell
+docker version
+```
+```
+Client version: 1.7.0
+Client API version: 1.19
+Go version (client): go1.4.2
+Git commit (client): 0baf609
+OS/Arch (client): linux/amd64
+Server version: 1.7.0
+Server API version: 1.19
+Go version (server): go1.4.2
+Git commit (server): 0baf609
+OS/Arch (server): linux/amd64
+```
+
+kubectl:
+
+```shell
+kubectl version
+```
+```
+Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
+Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
+```
+
+## docker info
+
+환경 및 설정에 대한 자세한 정보는 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)를 참고한다.
+
+docker:
+
+```shell
+docker info
+```
+```
+Containers: 40
+Images: 168
+Storage Driver: aufs
+ Root Dir: /usr/local/google/docker/aufs
+ Backing Filesystem: extfs
+ Dirs: 248
+ Dirperm1 Supported: false
+Execution Driver: native-0.2
+Logging Driver: json-file
+Kernel Version: 3.13.0-53-generic
+Operating System: Ubuntu 14.04.2 LTS
+CPUs: 12
+Total Memory: 31.32 GiB
+Name: k8s-is-fun.mtv.corp.google.com
+ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
+WARNING: No swap limit support
+```
+
+kubectl:
+
+```shell
+kubectl cluster-info
+```
+```
+Kubernetes master is running at https://203.0.113.141
+KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
+kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
+Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
+Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
+```
+
diff --git a/content/ko/docs/reference/kubectl/kubectl.md b/content/ko/docs/reference/kubectl/kubectl.md
new file mode 100644
index 0000000000..fe60f87d8f
--- /dev/null
+++ b/content/ko/docs/reference/kubectl/kubectl.md
@@ -0,0 +1,370 @@
+---
+title: kubectl
+content_type: tool-reference
+weight: 30
+---
+
+## {{% heading "synopsis" %}}
+
+
+kubectl은 쿠버네티스 클러스터 관리자를 제어한다.
+
+ 자세한 정보는 https://kubernetes.io/docs/reference/kubectl/overview/ 에서 확인한다.
+
+```
+kubectl [flags]
+```
+
+## {{% heading "options" %}}
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--add-dir-header</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">true인 경우, 로그 메시지의 헤더에 파일 디렉터리를 추가한다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--alsologtostderr</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">표준 에러와 파일에 로그를 기록한다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--as string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">작업을 수행할 사용자 이름</td>
+</tr>
+
+<tr>
+<td colspan="2">--as-group stringArray</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">작업을 수행할 그룹. 이 플래그를 반복해서 여러 그룹을 지정할 수 있다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--azure-container-registry-config string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Azure 컨테이너 레지스트리 구성 정보가 포함된 파일의 경로이다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: "$HOME/.kube/cache"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">기본 캐시 디렉터리</td>
+</tr>
+
+<tr>
+<td colspan="2">--certificate-authority string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">인증 기관의 인증서에 대한 파일 경로</td>
+</tr>
+
+<tr>
+<td colspan="2">--client-certificate string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">TLS용 클라이언트 인증서의 파일 경로</td>
+</tr>
+
+<tr>
+<td colspan="2">--client-key string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">TLS용 클라이언트 키의 파일 경로</td>
+</tr>
+
+<tr>
+<td colspan="2">--cloud-provider-gce-l7lb-src-cidrs cidrs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 130.211.0.0/22,35.191.0.0/16</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">L7 LB 트래픽 프록시 및 상태 확인을 위해 GCE 방화벽에서 오픈된 CIDR</td>
+</tr>
+
+<tr>
+<td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">L4 LB 트래픽 프록시 및 상태 확인을 위해 GCE 방화벽에서 오픈된 CIDR</td>
+</tr>
+
+<tr>
+<td colspan="2">--cluster string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">사용할 kubeconfig 클러스터의 이름</td>
+</tr>
+
+<tr>
+<td colspan="2">--context string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">사용할 kubeconfig 콘텍스트의 이름</td>
+</tr>
+
+<tr>
+<td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 300</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">아직 톨러레이션(toleration)이 없는 모든 파드에 기본적으로 추가되는 notReady:NoExecute에 대한 톨러레이션의 tolerationSeconds를 나타낸다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 300</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">아직 톨러레이션이 없어서 기본인 unreachable:NoExecute가 추가된 모든 파드에 대한 톨러레이션의 tolerationSeconds를 나타낸다.</td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">kubectl에 대한 도움말</td>
+</tr>
+
+<tr>
+<td colspan="2">--insecure-skip-tls-verify</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">true인 경우, 서버 인증서의 유효성을 확인하지 않는다. 이렇게 하면 사용자의 HTTPS 연결이 안전하지 않게 된다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--kubeconfig string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">CLI 요청에 사용할 kubeconfig 파일의 경로이다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: :0</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">로깅이 file:N에 도달했을 때 스택 트레이스를 내보낸다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-dir string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">비어 있지 않으면, 이 디렉터리에 로그 파일을 작성한다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-file string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">비어 있지 않으면, 이 로그 파일을 사용한다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-file-max-size uint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 1800</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">로그 파일이 커질 수 있는 최대 크기를 정의한다. 단위는 메가 바이트이다. 값이 0이면, 파일의 최대 크기는 무제한이다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 5s</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">로그를 비우는 간격의 최대 시간(초)</td>
+</tr>
+
+<tr>
+<td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: true</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">파일 대신 표준 에러에 기록</td>
+</tr>
+
+<tr>
+<td colspan="2">--match-server-version</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">클라이언트 버전과 일치하는 서버 버전 필요</td>
+</tr>
+
+<tr>
+<td colspan="2">-n, --namespace string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">지정된 경우, 해당 네임스페이스가 CLI 요청의 범위가 됨</td>
+</tr>
+
+<tr>
+<td colspan="2">--password string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">API 서버에 대한 기본 인증을 위한 비밀번호</td>
+</tr>
+
+<tr>
+<td colspan="2">--profile string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: "none"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">캡처할 프로파일의 이름. (none|cpu|heap|goroutine|threadcreate|block|mutex) 중 하나</td>
+</tr>
+
+<tr>
+<td colspan="2">--profile-output string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: "profile.pprof"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">프로파일을 쓸 파일의 이름</td>
+</tr>
+
+<tr>
+<td colspan="2">--request-timeout string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: "0"</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">단일 서버 요청을 포기하기 전에 대기하는 시간이다. 0이 아닌 값에는 해당 시간 단위(예: 1s, 2m, 3h)가 포함되어야 한다. 값이 0이면 요청 시간이 초과되지 않는다.</td>
+</tr>
+
+<tr>
+<td colspan="2">-s, --server string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">쿠버네티스 API 서버의 주소와 포트</td>
+</tr>
+
+<tr>
+<td colspan="2">--skip-headers</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">true이면, 로그 메시지에서 헤더 접두사를 사용하지 않는다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--skip-log-headers</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">true이면, 로그 파일을 열 때 헤더를 사용하지 않는다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--stderrthreshold severity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;기본값: 2</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">이 임계값 이상의 로그는 표준 에러로 이동한다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--tls-server-name string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면, 서버에 접속하는 데 사용되는 호스트 이름이 사용된다.</td>
+</tr>
+
+<tr>
+<td colspan="2">--token string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">API 서버 인증을 위한 베어러(Bearer) 토큰</td>
+</tr>
+
+<tr>
+<td colspan="2">--user string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">사용할 kubeconfig 사용자의 이름</td>
+</tr>
+
+<tr>
+<td colspan="2">--username string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">API 서버에 대한 기본 인증을 위한 사용자 이름</td>
+</tr>
+
+<tr>
+<td colspan="2">-v, --v Level</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">로그 수준의 자세한 정도를 나타내는 숫자</td>
+</tr>
+
+<tr>
+<td colspan="2">--version version[=true]</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">버전 정보를 출력하고 종료</td>
+</tr>
+
+<tr>
+<td colspan="2">--vmodule moduleSpec</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">파일 필터링 로깅을 위한 쉼표로 구분된 pattern=N 설정 목록</td>
+</tr>
+
+<tr>
+<td colspan="2">--warnings-as-errors</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">서버에서 받은 경고를 오류로 처리하고 0이 아닌 종료 코드로 종료</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+## {{% heading "seealso" %}}
+
+* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha)	 - 알파 기능에 대한 커맨드
+* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate)	 - 리소스에 대한 어노테이션 업데이트
+* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources)	 - 서버에서 지원되는 API 리소스 출력
+* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions)	 - "그룹/버전" 형식으로 서버에서 지원되는 API 버전을 출력
+* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply)	 - 파일명 또는 표준 입력으로 리소스에 구성 적용
+* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach)	 - 실행 중인 컨테이너에 연결
+* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth)	 - 권한 검사
+* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)	 - 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 레플리케이션컨트롤러(ReplicationController) 자동 스케일링
+* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate)	 - 인증서 리소스 수정
+* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info)	 - 클러스터 정보 표시
+* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion)	 - 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드 출력
+* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)	 - kubeconfig 파일 수정
+* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert)	 - 다른 API 버전 간에 구성 파일 변환
+* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon)	 - 노드를 unschedulable로 표시
+* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp)	 - 컨테이너 간에 파일과 디렉터리 복사
+* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create)	 - 파일 또는 표준 입력에서 리소스를 생성
+* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete)	 - 파일명, 표준 입력, 리소스 및 이름, 또는 리소스 및 레이블 셀렉터로 리소스 삭제
+* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe)	 - 특정 리소스 또는 리소스 그룹의 세부 정보를 표시
+* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff)	 - 적용 예정 버전과 라이브 버전 비교
+* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain)	 - 유지 보수 준비 중 노드 드레인
+* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit)	 - 서버에서 리소스 편집
+* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec)	 - 컨테이너에서 커맨드 실행
+* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain)	 - 리소스의 문서
+* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose)	 - 레플리케이션 컨트롤러, 서비스, 디플로이먼트 또는 파드를 가져와서 새로운 쿠버네티스 서비스로 노출
+* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get)	 - 하나 이상의 리소스 표시
+* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize)	 - 디렉터리 또는 원격 URL에서 kustomization 대상을 빌드
+* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label)	 - 리소스의 레이블 업데이트
+* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs)	 - 파드의 컨테이너에 대한 로그 출력
+* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options)	 - 모든 커맨드에서 상속된 플래그 목록을 출력
+* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	 - 전략적 병합 패치를 사용하여 리소스 필드를 업데이트
+* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin)	 - 플러그인과 상호 작용하기 위한 유틸리티를 제공
+* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward)	 - 하나 이상의 로컬 포트를 파드로 전달
+* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy)	 - 쿠버네티스 API 서버에 대한 프록시 실행
+* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace)	 - 파일명 또는 표준 입력으로 리소스 교체
+* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout)	 - 리소스 롤아웃 관리
+* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run)	 - 클러스터에서 특정 이미지 실행
+* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale)	 - 디플로이먼트, 레플리카셋 또는 레플리케이션 컨트롤러의 새 크기 설정
+* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set)	 - 오브젝트에 특정 기능 설정
+* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)	 - 하나 이상의 노드에서 테인트(taint) 업데이트
+* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top)	 - 리소스(CPU/메모리/스토리지) 사용량을 표시
+* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon)	 - 노드를 schedulable로 표시
+* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version)	 - 클라이언트 및 서버 버전 정보 출력
+* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait)	 - 실험적(experimental) 기능: 하나 이상의 리소스에 대해서 특정 조건이 만족될 때까지 대기(wait)
diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md
index 6eab3cbafe..6626947c2a 100644
--- a/content/ko/docs/reference/kubectl/overview.md
+++ b/content/ko/docs/reference/kubectl/overview.md
@@ -8,10 +8,16 @@ card:
 ---
 
 <!-- overview -->
-Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. 구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다.
-
-이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다.
+Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다.
+구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다.
+KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+파일을 지정할 수 있다.
 
+이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
+지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
+설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다.
 
 <!-- body -->
 
@@ -25,9 +31,12 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
 
-* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예: `create`, `get`, `describe`, `delete`
+* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
+예: `create`, `get`, `describe`, `delete`
 
-* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
+* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
+  단수형, 복수형 또는 약어 형식을 지정할 수 있다.
+  예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
 
    ```shell
    kubectl get pod pod1
@@ -116,14 +125,15 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
 
-(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치했다.)
+(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
 
-| 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 |
+| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
 |---|---|---|---|---|
-| `bindings` | | | true | Binding|
+| `bindings` | | | true | Binding |
 | `componentstatuses` | `cs` | | false | ComponentStatus |
 | `configmaps` | `cm` | | true | ConfigMap |
 | `endpoints` | `ep` | | true | Endpoints |
+| `events` | `ev` | | true | Event |
 | `limitranges` | `limits` | | true | LimitRange |
 | `namespaces` | `ns` | | false | Namespace |
 | `nodes` | `no` | | false | Node |
@@ -131,14 +141,14 @@ kubectl [command] [TYPE] [NAME] [flags]
 | `persistentvolumes` | `pv` | | false | PersistentVolume |
 | `pods` | `po` | | true | Pod |
 | `podtemplates` | | | true | PodTemplate |
-| `replicationcontrollers` | `rc` | | true| ReplicationController |
+| `replicationcontrollers` | `rc` | | true | ReplicationController |
 | `resourcequotas` | `quota` | | true | ResourceQuota |
 | `secrets` | | | true | Secret |
 | `serviceaccounts` | `sa` | | true | ServiceAccount |
 | `services` | `svc` | | true | Service |
 | `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
 | `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
-| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
+| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
 | `apiservices` | | apiregistration.k8s.io | false | APIService |
 | `controllerrevisions` | | apps | true | ControllerRevision |
 | `daemonsets` | `ds` | apps | true | DaemonSet |
@@ -155,9 +165,15 @@ kubectl [command] [TYPE] [NAME] [flags]
 | `jobs` | | batch | true | Job |
 | `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
 | `leases` | | coordination.k8s.io | true | Lease |
+| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
 | `events` | `ev` | events.k8s.io | true | Event |
 | `ingresses` | `ing` | extensions | true | Ingress |
+| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
+| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
+| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
+| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
 | `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
+| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
 | `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
 | `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
 | `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
@@ -167,7 +183,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 | `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
 | `csidrivers` | | storage.k8s.io | false | CSIDriver |
 | `csinodes` | | storage.k8s.io | false | CSINode |
-| `storageclasses` | `sc` | storage.k8s.io |  false | StorageClass |
+| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
 | `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
 
 ## 출력 옵션
@@ -205,11 +221,13 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
 kubectl get pod web-pod-13je7 -o yaml
 ```
 
-기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다.
+기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
+[kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
 
 #### 사용자 정의 열 {#custom-columns}
 
-사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다. 사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
+사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다.
+사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
 
 ##### 예제
 
@@ -493,8 +511,6 @@ kubectl whoami
 Current user: plugins-user
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
 * [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다.
diff --git a/content/ko/docs/reference/scheduling/_index.md b/content/ko/docs/reference/scheduling/_index.md
new file mode 100644
index 0000000000..7a37a35981
--- /dev/null
+++ b/content/ko/docs/reference/scheduling/_index.md
@@ -0,0 +1,5 @@
+---
+title: 스케줄링
+weight: 70
+toc-hide: true
+---
diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md
new file mode 100644
index 0000000000..f2cae65b68
--- /dev/null
+++ b/content/ko/docs/reference/scheduling/policies.md
@@ -0,0 +1,118 @@
+---
+title: 스케줄링 정책
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다.
+
+`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)을 사용하여 스케줄링 정책을 설정할 수 있다.
+
+
+
+<!-- body -->
+
+## 단정 {#predicates}
+
+다음의 *단정* 은 필터링을 구현한다.
+
+- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는
+  포트(네트워크 프로토콜 종류)가 있는지 확인한다.
+
+- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다.
+
+- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는
+  리소스(예: CPU 및 메모리)가 있는지 확인한다.
+
+- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
+  노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다.
+
+- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면
+  파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지
+  평가한다.
+
+- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해
+  파드가 노드에 적합한지 평가한다.
+
+- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와
+  구성된 제한을 초과하는지 여부를 결정한다.
+
+- `CheckNodeMemoryPressure`: 노드가 메모리 압박을 보고하고 있고, 구성된
+  예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
+
+- `CheckNodePIDPressure`: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된
+  예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
+
+- `CheckNodeDiskPressure`: 노드가 스토리지 압박(파일시스템이 가득차거나
+  거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
+
+- `CheckNodeCondition`: 노드는 파일시스템이 완전히 가득찼거나,
+  네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다.
+  노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가
+  해당 노드에 스케줄되지 않는다.
+
+- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이
+  노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다.
+
+- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다.
+  이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와
+  바인딩되지 않은 PVC 모두에 적용된다.
+
+## 우선순위 {#priorities}
+
+다음의 *우선순위* 는 스코어링을 구현한다.
+
+- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}},
+  {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는
+  {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는
+  파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다.
+
+- `InterPodAffinityPriority`: 선호된
+  [파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다.
+
+- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉,
+  노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가
+  많을수록 이 정책이 부여하는 순위가 낮아진다.
+
+- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다.
+  이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된
+  파드를 맞춘다.
+
+- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다.
+
+- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다.
+
+- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
+  노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가
+  동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다.
+
+- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링
+  설정에 따라 노드의 우선순위를 지정한다.
+  이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다.
+
+- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로,
+  모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을
+  고려하여 노드의 순위를 조정한다.
+
+- `ImageLocalityPriority`: 해당 파드의
+  {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된
+  노드를 선호한다.
+
+- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한
+  파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한
+  파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는
+  서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다.
+
+- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다.
+
+- `EvenPodsSpreadPriority`: 선호된
+  [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다.
+
+
+
+## {{% heading "whatsnext" %}}
+
+* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
+* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md
index 268a280c50..051fba4c5d 100644
--- a/content/ko/docs/reference/setup-tools/_index.md
+++ b/content/ko/docs/reference/setup-tools/_index.md
@@ -1,6 +1,4 @@
 ---
 title: 설치 도구 레퍼런스
 weight: 50
-toc-hide: true
 ---
-
diff --git a/content/ko/docs/reference/setup-tools/kubeadm/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/_index.md
index 085b1e1ef9..683f78000b 100644
--- a/content/ko/docs/reference/setup-tools/kubeadm/_index.md
+++ b/content/ko/docs/reference/setup-tools/kubeadm/_index.md
@@ -1,6 +1,30 @@
 ---
 title: "Kubeadm"
 weight: 10
-toc-hide: true
+no_list: true
+content_type: concept
+card:
+  name: reference
+  weight: 40
 ---
 
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 `kubeadm init` 과 `kubeadm join` 을 제공하도록 만들어진 도구이다.
+
+kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다.
+
+대신, 우리는 더 높은 수준의 맞춤형 도구가 kubeadm 위에 구축될 것으로 기대하며, 이상적으로는, 모든 배포의 기반으로 kubeadm을 사용하면 규격을 따르는 클러스터를 더 쉽게 생성할 수 있다.
+
+## 설치 방법
+
+kubeadm을 설치하려면, [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참고한다.
+
+## {{% heading "whatsnext" %}}
+
+* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다.
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다.
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다.
+* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다.
+* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join` 을 위한 토큰을 관리한다.
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다.
+* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력한다.
+* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.
diff --git a/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md
deleted file mode 100644
index f011459dd6..0000000000
--- a/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: kubeadm 개요
-weight: 10
-card:
-  name: reference
-  weight: 40
----
-<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터를 "빠른 경로"로 생성하기 위한 모범 사례인 `kubeadm init`과 `kubeadm join`을 제공하기 위해 구성된 도구이다.
-
-kubeadm은 최소 기능 클러스터(minimum viable cluster)를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계상, 부트스트랩만 다루며, 머신을 프로비저닝하지는 않는다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드 별 애드온과 같은 다양한 기능을 갖춘 애드온을 설치하는 것은 범위에 포함되지 않는다.
-
-대신, kubeadm 위에 있는 더 높은 수준의 맞춤형 도구가 구축될 것으로 예상되며, 모든 배포의 기초로서 kubeadm을 사용하면 적합한 클러스터를 보다 쉽게 만들 수 있다.
-
-## 설치하는 방법
-
-kubeadm을 설치하려면 [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참조한다.
-
-## 다음 내용
-
-* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩 함
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커 노드를 부트스트랩 후 클러스터에 결합시킴
-* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 최신 버전으로 업그레이드
-* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x이하의 버전을 사용하여 클러스터를 초기화한 경우, 클러스터를 설정하여 `kubeadm upgrade`하기 위해 사용
-* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join`을 위한 토큰 관리
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init`나 `kubeadm join`를 의한 호스트에 대해서 변경된 사항을 되돌림
-* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티의 피드백 수집을 위해서 기능 미리 보기를 제공
-
diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md
index a224824aa1..7751aef2f4 100644
--- a/content/ko/docs/reference/using-api/_index.md
+++ b/content/ko/docs/reference/using-api/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 쿠버네티스 API 사용하기
 weight: 10
-toc-hide: true
 ---
diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md
index 0ac842ccc6..4bf982fc1b 100644
--- a/content/ko/docs/reference/using-api/api-overview.md
+++ b/content/ko/docs/reference/using-api/api-overview.md
@@ -9,62 +9,61 @@ card:
 ---
 
 <!-- overview -->
+
 이 페이지는 쿠버네티스 API에 대한 개요를 제공한다.
 
 
 <!-- body -->
-REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
+
+REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작,
+컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는
+REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
 API 오브젝트로 취급되고,
 [API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다.
 
-대부분의 작업은 API에 의존하고 있는
-[kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다.
-그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다.
-
-쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우
-[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다.
-
 ## API 버전 규칙
 
-필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
-쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
-각각 다른 API 경로에서 복수의 API 버전을 지원한다.
+JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
+동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
 
-아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다.
-
-- API가 시스템 리소스와 동작에 대해 명확하고 일관성 있게 표현하는 것을 보장
-- 수명 종료(end-of-life) 또는 실험적인 API 접근 제어 활성화
-
-JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
-
-{{< note >}}
 API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
-[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
-{{< /note >}}
+[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
+API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
 
-API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
+API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
+[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서
+각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
 
 아래는 각 수준의 기준에 대한 요약이다.
 
 - 알파(Alpha) 수준:
   - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
-  - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
+  - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다.
+    기본적으로 비활성화되어 있다.
   - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
   - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
-  - 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
+  - 버그의 위험이 높고 장기간 지원되지 않으므로
+    단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
 
 - 베타(Beta) 수준:
   - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`).
-  - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다.
+  - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다.
+    기본적으로 활성화되어 있다.
   - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
-  - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 이때 API 오브젝트의 삭제, 편집 또는 재생성이
-    필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
-  - 이후 여러 버전에서 잠재적으로 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 안심이 될 수도 있겠다.
 
- {{< note >}}
-베타 기능을 사용해보고 피드백을 제공하자. 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.
- {{< /note >}}
+  - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서
+    호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로
+    이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이
+    필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다.
+    이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
+  - 이 소프트웨어는 프로덕션 용도로 권장되지 않는다. 이후 여러 버전에서
+    호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서
+    독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
+
+  {{< note >}}
+  베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는
+  실질적으로 더 많은 변경이 어렵다.
+  {{< /note >}}
 
 - 안정화(stable) 수준:
   - 버전 이름이 `vX`이고 `X` 는 정수다.
@@ -72,32 +71,43 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
 
 ## API 그룹
 
-[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다.
+[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은
+쿠버네티스 API를 더 쉽게 확장하게 해준다.
+API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에
+명시된다.
 
-현재 다음과 같은 다양한 API 그룹이 사용되고 있다:
+현재 다음과 같은 다양한 API 그룹이 사용되고 있다.
 
-*  *핵심* (또는 *레거시* 라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
-*  이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
-   (예를 들어 `apiVersion: batch/v1`).  지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다.
+*  *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다.
+   핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를
+   들어, `apiVersion: v1` 와 같다.
+*  이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며
+   `apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`).
+   지원되는 API 그룹 전체의 목록은
+   [쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에서 확인할 수 있다.
 
-[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다.
+## API 그룹 활성화 또는 비활성화   {#enabling-or-disabling}
 
- - 기본적인 CRUD 요구에는
-   [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
- - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
+특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서
+`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다.
+`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는
+쉼표로 구분된 `<key>=<value>` 쌍을 허용한다. 예를 들면, 다음과 같다.
 
-
-## API 그룹 활성화 또는 비활성화 하기
-
-특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나
-비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어:
-
- - batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정
- - batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정
-
-이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다.
+ - `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정
+ - `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정
 
 {{< note >}}
 그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
 `--runtime-config` 변경을 반영해야 한다.
 {{< /note >}}
+
+## 지속성
+
+쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서
+직렬화된 상태를 저장한다.
+
+## {{% heading "whatsnext" %}}
+
+- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기
+- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에
+  대한 디자인 문서 읽기
diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md
index a0a87e0837..9a6e07293f 100644
--- a/content/ko/docs/reference/using-api/client-libraries.md
+++ b/content/ko/docs/reference/using-api/client-libraries.md
@@ -22,8 +22,8 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 
 ## 공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리
 
-다음의 클라이언트 라이브러리들은 [쿠버네티스 SIG API
-Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다.
+다음의 클라이언트 라이브러리들은
+[쿠버네티스 SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다.
 
 
 | 언어      | 클라이언트 라이브러리 | 예제 프로그램 |
@@ -38,6 +38,8 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 
 ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리
 
+{{% thirdparty-content %}}
+
 다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌
 각각의 저자들이 제공하고 관리한다.
 
@@ -58,6 +60,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 | PHP                  | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
 | PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
 | PHP                  | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
+| PHP                  | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
 | Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
 | Python               | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
@@ -73,6 +76,3 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
 | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
 | Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
-
-
-
diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md
index 42b94acf5e..5595e0ac3d 100644
--- a/content/ko/docs/setup/best-practices/certificates.md
+++ b/content/ko/docs/setup/best-practices/certificates.md
@@ -29,7 +29,7 @@ weight: 40
 * [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 위한 클라이언트와 서버 인증서
 
 {{< note >}}
-`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
+`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다.
 {{< /note >}}
 
 etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
@@ -120,8 +120,8 @@ kubeadm 사용자만 해당:
 
 | 개인키 경로             | 공개 키 경로             | 명령어                 | 파라미터                             |
 |------------------------------|-----------------------------|-------------------------|--------------------------------------|
-|  sa.key                      |                             | kube-controller-manager | service-account-private              |
-|                              | sa.pub                      | kube-apiserver          | service-account-key                  |
+|  sa.key                      |                             | kube-controller-manager | --service-account-private-key-file   |
+|                              | sa.pub                      | kube-apiserver          | --service-account-key-file           |
 
 ## 각 사용자 계정을 위한 인증서 설정하기
 
@@ -157,4 +157,3 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 | kubelet.conf            | kubelet                 | 클러스터 각 노드를 위해 필요하다.                            |
 | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. |
 | scheduler.conf          | kube-scheduler          | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다.          |
-
diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md
index 0693169e5d..189dbed654 100644
--- a/content/ko/docs/setup/best-practices/multiple-zones.md
+++ b/content/ko/docs/setup/best-practices/multiple-zones.md
@@ -1,398 +1,140 @@
 ---
-title: 여러 영역에서 구동
-weight: 10
+title: 여러 영역에서 실행
+weight: 20
 content_type: concept
 ---
 
 <!-- overview -->
 
-이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다.
-
-
+이 페이지에서는 여러 영역에서 쿠버네티스를 실행하는 방법을 설명한다.
 
 <!-- body -->
 
-## 소개
+## 배경
 
-Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
-(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
-This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
-nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
-Full Cluster Federation allows combining separate
-Kubernetes clusters running in different regions or cloud providers
-(or on-premises data centers).  However, many
-users simply want to run a more available Kubernetes cluster in multiple zones
-of their single cloud provider, and this is what the multizone support in 1.2 allows
-(this previously went by the nickname "Ubernetes Lite").
+쿠버네티스는 단일 쿠버네티스 클러스터가 여러 장애 영역에서
+실행될 수 있도록 설계되었다. 일반적으로 이러한 영역은 _지역(region)_ 이라는
+논리적 그룹 내에 적합하다. 주요 클라우드 제공자는 지역을 일관된 기능 집합을
+제공하는 장애 영역 집합(_가용성 영역_ 이라고도 함)으로
+정의한다. 지역 내에서 각 영역은 동일한 API 및
+서비스를 제공한다.
 
-Multizone support is deliberately limited: a single Kubernetes cluster can run
-in multiple zones, but only within the same region (and cloud provider).  Only
-GCE and AWS are currently supported automatically (though it is easy to
-add similar support for other clouds or even bare metal, by simply arranging
-for the appropriate labels to be added to nodes and volumes).
+일반적인 클라우드 아키텍처는 한 영역의 장애가 다른 영역의 서비스도
+손상시킬 가능성을 최소화하는 것을 목표로 한다.
 
+## 컨트롤 플레인 동작
 
-## 기능
+모든 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)는
+컴포넌트별로 복제되는 교환 가능한 리소스 풀로 실행을
+지원한다.
 
-When nodes are started, the kubelet automatically adds labels to them with
-zone information.
-
-Kubernetes will automatically spread the pods in a replication controller
-or service across nodes in a single-zone cluster (to reduce the impact of
-failures.)  With multiple-zone clusters, this spreading behavior is
-extended across zones (to reduce the impact of zone failures.)  (This is
-achieved via `SelectorSpreadPriority`).  This is a best-effort
-placement, and so if the zones in your cluster are heterogeneous
-(e.g. different numbers of nodes, different types of nodes, or
-different pod resource requirements), this might prevent perfectly
-even spreading of your pods across zones. If desired, you can use
-homogeneous zones (same number and types of nodes) to reduce the
-probability of unequal spreading.
-
-When persistent volumes are created, the `PersistentVolumeLabel`
-admission controller automatically adds zone labels to them.  The scheduler (via the
-`VolumeZonePredicate` predicate) will then ensure that pods that claim a
-given volume are only placed into the same zone as that volume, as volumes
-cannot be attached across zones.
-
-## 제한 사항
-
-There are some important limitations of the multizone support:
-
-* We assume that the different zones are located close to each other in the
-network, so we don't perform any zone-aware routing.  In particular, traffic
-that goes via services might cross zones (even if some pods backing that service
-exist in the same zone as the client), and this may incur additional latency and cost.
-
-* Volume zone-affinity will only work with a `PersistentVolume`, and will not
-work if you directly specify an EBS volume in the pod spec (for example).
-
-* Clusters cannot span clouds or regions (this functionality will require full
-federation support).
-
-* Although your nodes are in multiple zones, kube-up currently builds
-a single master node by default.  While services are highly
-available and can tolerate the loss of a zone, the control plane is
-located in a single zone.  Users that want a highly available control
-plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
-
-### Volume limitations
-The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드).
-
-* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
-  pod affinity or anti-affinity policies.
-
-* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
-  may not provide a uniform distribution of storage across zones.
-
-* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
-  needs to be configured for a specific single zone, or the PVs need to be
-  statically provisioned in a specific zone. Another workaround is to use a
-  StatefulSet, which will ensure that all the volumes for a replica are
-  provisioned in the same zone.
-
-## 연습
-
-We're now going to walk through setting up and using a multi-zone
-cluster on both GCE & AWS.  To do so, you bring up a full cluster
-(specifying `MULTIZONE=true`), and then you add nodes in additional zones
-by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
-
-### 클러스터 가져오기
-
-Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
-
-GCE:
-
-```shell
-curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
-```
-
-AWS:
-
-```shell
-curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
-```
-
-This step brings up a cluster as normal, still running in a single zone
-(but `MULTIZONE=true` has enabled multi-zone capabilities).
-
-### 라벨이 지정된 노드 확인
-
-View the nodes; you can see that they are labeled with zone information.
-They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far.  The
-labels are `failure-domain.beta.kubernetes.io/region` for the region,
-and `failure-domain.beta.kubernetes.io/zone` for the zone:
-
-```shell
-kubectl get nodes --show-labels
-```
-
-The output is similar to this:
-
-```shell
-NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-```
-
-### 두번째 영역에 더 많은 노드 추가하기
-
-Let's add another set of nodes to the existing cluster, reusing the
-existing master, running in a different zone (us-central1-b or us-west-2b).
-We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
-kube-up will not create a new master, but will reuse one that was previously
-created instead.
-
-GCE:
-
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
-```
-
-On AWS we also need to specify the network CIDR for the additional
-subnet, along with the master internal IP address:
-
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
-```
-
-
-View the nodes again; 3 more nodes should have launched and be tagged
-in us-central1-b:
-
-```shell
-kubectl get nodes --show-labels
-```
-
-The output is similar to this:
-
-```shell
-NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
-kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
-```
-
-### 볼륨 어피니티
-
-Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
-
-```bash
-kubectl apply -f - <<EOF
-{
-  "apiVersion": "v1",
-  "kind": "PersistentVolumeClaim",
-  "metadata": {
-    "name": "claim1",
-    "annotations": {
-        "volume.alpha.kubernetes.io/storage-class": "foo"
-    }
-  },
-  "spec": {
-    "accessModes": [
-      "ReadWriteOnce"
-    ],
-    "resources": {
-      "requests": {
-        "storage": "5Gi"
-      }
-    }
-  }
-}
-EOF
-```
+클러스터 컨트롤 플레인을 배포할 때, 여러 장애 영역에
+컨트롤 플레인 컴포넌트의 복제본을 배치한다. 가용성이
+중요한 문제인 경우, 3개 이상의 장애 영역을 선택하고
+각 개별 컨트롤 플레인 컴포넌트(API 서버, 스케줄러, etcd,
+클러스터 컨트롤러 관리자)를 3개 이상의 장애 영역에 복제한다.
+클라우드 컨트롤러 관리자를 실행 중인 경우 선택한
+모든 장애 영역에 걸쳐 이를 복제해야 한다.
 
 {{< note >}}
-For version 1.3+ Kubernetes will distribute dynamic PV claims across
-the configured zones. For version 1.2, dynamic persistent volumes were
-always created in the zone of the cluster master
-(here us-central1-a / us-west-2a); that issue
-([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
-was addressed in 1.3+.
+쿠버네티스는 API 서버 엔드포인트에 대한 교차 영역 복원성을 제공하지
+않는다. DNS 라운드-로빈, SRV 레코드 또는 상태 확인 기능이 있는
+써드파티 로드 밸런싱 솔루션을 포함하여 다양한 기술을 사용하여
+클러스터 API 서버의 가용성을 향상시킬 수 있다.
 {{< /note >}}
 
-Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
+## 노드 동작
 
-```shell
-kubectl get pv --show-labels
-```
+쿠버네티스는 클러스터의 여러 노드에 걸쳐
+워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
+또는 {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}})에
+대한 파드를 자동으로 분배한다. 이러한 분배는
+실패에 대한 영향을 줄이는 데 도움이 된다.
 
-The output is similar to this:
+노드가 시작되면, 각 노드의 kubelet이 쿠버네티스 API에서
+특정 kubelet을 나타내는 노드 오브젝트에
+{{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다.
+이러한 레이블에는
+[영역 정보](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
 
-```shell
-NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
-pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
-```
+클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
+[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과
+함께 노드 레이블을 사용하여
+파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
+분산되는 방식을 제어할 수 있다.
+이러한 힌트를 통해
+{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
+더 나은 예상 가용성을 위해 파드를 배치할 수 있으므로, 상관 관계가 있는
+오류가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있다.
 
-So now we will create a pod that uses the persistent volume claim.
-Because GCE PDs / AWS EBS volumes cannot be attached across zones,
-this means that this pod can only be created in the same zone as the volume:
+예를 들어, 가능할 때마다 스테이트풀셋의
+3개 복제본이 모두 서로 다른 영역에서 실행되도록 제약 조건을
+설정할 수 있다. 각 워크로드에 사용 중인
+가용 영역을 명시적으로 정의하지 않고 이를 선언적으로
+정의할 수 있다.
 
-```yaml
-kubectl apply -f - <<EOF
-kind: Pod
-apiVersion: v1
-metadata:
-  name: mypod
-spec:
-  containers:
-    - name: myfrontend
-      image: nginx
-      volumeMounts:
-      - mountPath: "/var/www/html"
-        name: mypd
-  volumes:
-    - name: mypd
-      persistentVolumeClaim:
-        claimName: claim1
-EOF
-```
+### 여러 영역에 노드 분배
 
-Note that the pod was automatically created in the same zone as the volume, as
-cross-zone attachments are not generally permitted by cloud providers:
+쿠버네티스의 코어는 사용자를 위해 노드를 생성하지 않는다. 사용자가 직접 수행하거나,
+[클러스터 API](https://cluster-api.sigs.k8s.io/)와 같은 도구를 사용하여
+사용자 대신 노드를 관리해야 한다.
 
-```shell
-kubectl describe pod mypod | grep Node
-```
+클러스터 API와 같은 도구를 사용하면 여러 장애 도메인에서
+클러스터의 워커 노드로 실행할 머신 집합과 전체 영역 서비스 중단 시
+클러스터를 자동으로 복구하는 규칙을 정의할 수 있다.
 
-```shell
-Node:        kubernetes-minion-9vlv/10.240.0.5
-```
+## 파드에 대한 수동 영역 할당
 
-And check node labels:
+생성한 파드와 디플로이먼트, 스테이트풀셋, 잡(Job)과
+같은 워크로드 리소스의 파드 템플릿에 [노드 셀렉터 제약 조건](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)을
+적용할 수 있다.
 
-```shell
-kubectl get node kubernetes-minion-9vlv --show-labels
-```
+## 영역에 대한 스토리지 접근
 
-```shell
-NAME                     STATUS    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-```
+퍼시스턴트 볼륨이 생성되면, `PersistentVolumeLabel`
+[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는
+특정 영역에 연결된 모든 퍼시스턴트볼륨(PersistentVolume)에 영역 레이블을 자동으로
+추가한다. 그런 다음 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}는
+`NoVolumeZoneConflict` 프레디케이트(predicate)를 통해 주어진 퍼시스턴트볼륨을 요구하는 파드가
+해당 볼륨과 동일한 영역에만 배치되도록 한다.
 
-### 여러 영역에 파드 분배하기
+해당 클래스의 스토리지가 사용할 수 있는 장애 도메인(영역)을 지정하는
+퍼시스턴트볼륨클레임(PersistentVolumeClaims)에 대한
+{{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 지정할 수 있다.
+장애 도메인 또는 영역을 인식하는 스토리지클래스 구성에 대한 자세한 내용은
+[허용된 토폴로지](/ko/docs/concepts/storage/storage-classes/#허용된-토폴로지)를 참고한다.
 
-Pods in a replication controller or service are automatically spread
-across zones.  First, let's launch more nodes in a third zone:
+## 네트워킹
 
-GCE:
+쿠버네티스가 스스로 영역-인지(zone-aware) 네트워킹을 포함하지는 않는다.
+[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을
+사용하여 클러스터 네트워킹을 구성할 수 있으며, 해당 네트워크 솔루션에는 영역별 요소가
+있을 수 있다. 예를 들어, 클라우드 제공자가
+`type=LoadBalancer` 를 사용하여 서비스를 지원하는 경우, 로드 밸런서는 지정된 연결을 처리하는
+로드 밸런서 요소와 동일한 영역에서 실행 중인 파드로만 트래픽을 보낼 수 있다.
+자세한 내용은 클라우드 제공자의 문서를 확인한다.
 
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
-```
+사용자 정의 또는 온-프레미스 배포의 경우, 비슷한 고려 사항이 적용된다.
+다른 장애 영역 처리를 포함한 {{< glossary_tooltip text="서비스" term_id="service" >}}와
+{{< glossary_tooltip text="인그레스(Ingress)" term_id="ingress" >}} 동작은
+클러스터가 설정된 방식에 명확히 의존한다.
 
-AWS:
+## 장애 복구
 
-```shell
-KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
-```
+클러스터를 설정할 때, 한 지역의 모든 장애 영역이 동시에
+오프라인 상태가 되는 경우 설정에서 서비스를 복원할 수 있는지
+여부와 방법을 고려해야 할 수도 있다. 예를 들어, 영역에서 파드를 실행할 수 있는
+노드가 적어도 하나 이상 있어야 하는가?
+클러스터에 중요한 복구 작업이 클러스터에
+적어도 하나 이상의 정상 노드에 의존하지 않는지 확인한다. 예를 들어, 모든 노드가
+비정상인 경우, 하나 이상의 노드를 서비스할 수 있을 만큼 복구를 완료할 수 있도록 특별한
+{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}으로
+복구 작업을 실행해야 할 수 있다.
 
-Verify that you now have nodes in 3 zones:
+쿠버네티스는 이 문제에 대한 답을 제공하지 않는다. 그러나,
+고려해야 할 사항이다.
 
-```shell
-kubectl get nodes --show-labels
-```
+## {{% heading "whatsnext" %}}
 
-Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
-
-```shell
-find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
-```
-
-The pods should be spread across all 3 zones:
-
-```shell
-kubectl describe pod -l app=guestbook | grep Node
-```
-
-```shell
-Node:        kubernetes-minion-9vlv/10.240.0.5
-Node:        kubernetes-minion-281d/10.240.0.8
-Node:        kubernetes-minion-olsh/10.240.0.11
-```
-
-```shell
-kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
-```
-
-```shell
-NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
-```
-
-
-Load-balancers span all zones in a cluster; the guestbook-go example
-includes an example load-balanced service:
-
-```shell
-kubectl describe service guestbook | grep LoadBalancer.Ingress
-```
-
-The output is similar to this:
-
-```shell
-LoadBalancer Ingress:   130.211.126.21
-```
-
-Set the above IP:
-
-```shell
-export IP=130.211.126.21
-```
-
-Explore with curl via IP:
-
-```shell
-curl -s http://${IP}:3000/env | grep HOSTNAME
-```
-
-The output is similar to this:
-
-```shell
-  "HOSTNAME": "guestbook-44sep",
-```
-
-Again, explore multiple times:
-
-```shell
-(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
-```
-
-The output is similar to this:
-
-```shell
-  "HOSTNAME": "guestbook-44sep",
-  "HOSTNAME": "guestbook-hum5n",
-  "HOSTNAME": "guestbook-ppm40",
-```
-
-The load balancer correctly targets all the pods, even though they are in multiple zones.
-
-### 클러스터 강제 종료
-
-When you're done, clean up:
-
-GCE:
-
-```shell
-KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
-```
-
-AWS:
-
-```shell
-KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
-KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
-```
+스케줄러가 구성된 제약 조건을 준수하면서, 클러스터에 파드를 배치하는 방법을 알아보려면,
+[스케줄링과 축출(eviction)](/ko/docs/concepts/scheduling-eviction/)을 참고한다.
diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md
index d4579e2f89..9e9a65bee9 100644
--- a/content/ko/docs/setup/best-practices/node-conformance.md
+++ b/content/ko/docs/setup/best-practices/node-conformance.md
@@ -10,12 +10,6 @@ weight: 30
 테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참
 여할 자격이 주어진다.
 
-## 제한 사항
-
-쿠버네티스 1.5에서는 노드 적합성 테스트가 아래의 제약이 있다.
-
-* 노드 적합성 테스트는 컨테이너 런타임으로 Docker만 지원한다.
-
 ## 노드 필수 구성 요소
 
 노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다.
diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md
index 18e4811457..191da08404 100644
--- a/content/ko/docs/setup/learning-environment/minikube.md
+++ b/content/ko/docs/setup/learning-environment/minikube.md
@@ -447,11 +447,11 @@ spec:
 
 | Driver | OS | HostFolder | VM |
 | --- | --- | --- | --- |
-| VirtualBox | 리눅스 | /home | /hosthome |
-| VirtualBox | macOS | /Users | /Users |
-| VirtualBox | 윈도우 | C://Users | /c/Users |
-| VMware Fusion | macOS | /Users | /mnt/hgfs/Users |
-| Xhyve | macOS | /Users | /Users |
+| VirtualBox | 리눅스 | `/home` | `/hosthome` |
+| VirtualBox | macOS | `/Users` | `/Users` |
+| VirtualBox | 윈도우 | `C://Users` | `/c/Users` |
+| VMware Fusion | macOS | `/Users` | `/mnt/hgfs/Users` |
+| Xhyve | macOS | `/Users` | `/Users` |
 
 ## 프라이빗 컨테이너 레지스트리
 
diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md
index 39c2d07464..0bc616419b 100644
--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@@ -29,9 +29,6 @@ weight: 10
 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
 {{< /note >}}
 
-이 가이드의 모든 명령은 `root`로 실행해야 한다.
-예를 들어,`sudo`로 접두사를 붙이거나, `root` 사용자가 되어 명령을 실행한다.
-
 ### Cgroup 드라이버
 
 리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는
@@ -68,24 +65,24 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
 시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다.
 
 {{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04+" >}}
+{{% tab name="Ubuntu 16.04+" %}}
 
 ```shell
 # (도커 CE 설치)
 ## 리포지터리 설정
 ### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
-apt-get update && apt-get install -y \
+sudo apt-get update && sudo apt-get install -y \
   apt-transport-https ca-certificates curl software-properties-common gnupg2
 ```
 
 ```shell
 # 도커 공식 GPG 키 추가
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
 ```
 
 ```shell
 # 도커 apt 리포지터리 추가.
-add-apt-repository \
+sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
@@ -93,7 +90,7 @@ add-apt-repository \
 
 ```shell
 # 도커 CE 설치.
-apt-get update && apt-get install -y \
+sudo apt-get update && sudo apt-get install -y \
   containerd.io=1.2.13-2 \
   docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
   docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
@@ -101,7 +98,7 @@ apt-get update && apt-get install -y \
 
 ```shell
 # 도커 데몬 설정
-cat > /etc/docker/daemon.json <<EOF
+cat <<EOF | sudo tee /etc/docker/daemon.json
 {
   "exec-opts": ["native.cgroupdriver=systemd"],
   "log-driver": "json-file",
@@ -114,33 +111,33 @@ EOF
 ```
 
 ```shell
-mkdir -p /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
 ```
 
 ```shell
 # 도커 재시작.
-systemctl daemon-reload
-systemctl restart docker
+sudo systemctl daemon-reload
+sudo systemctl restart docker
 ```
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" >}}
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
 
 ```shell
 # (도커 CE 설치)
 ## 리포지터리 설정
 ### 필요한 패키지 설치
-yum install -y yum-utils device-mapper-persistent-data lvm2
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
 ```
 
 ```shell
 ## 도커 리포지터리 추가
-yum-config-manager --add-repo \
+sudo yum-config-manager --add-repo \
   https://download.docker.com/linux/centos/docker-ce.repo
 ```
 
 ```shell
 # 도커 CE 설치.
-yum update -y && yum install -y \
+sudo yum update -y && sudo yum install -y \
   containerd.io-1.2.13 \
   docker-ce-19.03.11 \
   docker-ce-cli-19.03.11
@@ -148,12 +145,12 @@ yum update -y && yum install -y \
 
 ```shell
 ## /etc/docker 생성.
-mkdir /etc/docker
+sudo mkdir /etc/docker
 ```
 
 ```shell
 # 도커 데몬 설정.
-cat > /etc/docker/daemon.json <<EOF
+cat <<EOF | sudo tee /etc/docker/daemon.json
 {
   "exec-opts": ["native.cgroupdriver=systemd"],
   "log-driver": "json-file",
@@ -169,15 +166,15 @@ EOF
 ```
 
 ```shell
-mkdir -p /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
 ```
 
 ```shell
 # 도커 재시작.
-systemctl daemon-reload
-systemctl restart docker
+sudo systemctl daemon-reload
+sudo systemctl restart docker
 ```
-{{< /tab >}}
+{{% /tab %}}
 {{< /tabs >}}
 
 부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다.
@@ -203,98 +200,145 @@ CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 
 ### 선행 조건
 
 ```shell
-modprobe overlay
-modprobe br_netfilter
+sudo modprobe overlay
+sudo modprobe br_netfilter
 
 # 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
 net.bridge.bridge-nf-call-iptables  = 1
 net.ipv4.ip_forward                 = 1
 net.bridge.bridge-nf-call-ip6tables = 1
 EOF
 
-sysctl --system
+sudo sysctl --system
 ```
 
 {{< tabs name="tab-cri-cri-o-installation" >}}
-{{< tab name="Debian" >}}
+{{% tab name="Debian" %}}
 
+다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다.
+
+| 운영 체제          | $OS               |
+| ---------------- | ----------------- |
+| Debian Unstable  | `Debian_Unstable` |
+| Debian Testing   | `Debian_Testing`  |
+
+<br />
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
+예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
+사용자의 설치를 특정 릴리스에 고정할 수 있다.
+버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다.
+<br />
+
+그런 다음, 아래를 실행한다.
 ```shell
-# Debian 개발 배포본(Unstable/Sid)
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
-```
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+"deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /"
+EOF
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+"deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /"
+EOF
 
-```shell
-# Debian Testing
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
-```
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -
 
-```shell
-# Debian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
-```
-
-```shell
-# Raspbian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
-```
-
-그리고 다음과 같이 CRI-O 설치한다.
-```shell
-sudo apt-get install cri-o-1.17
-```
-{{< /tab >}}
-
-{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}}
-
-```shell
-#  패키지 리포지터리 설정
-. /etc/os-release
-sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
 sudo apt-get update
+sudo apt-get install cri-o cri-o-runc
 ```
+{{% /tab %}}
 
+{{% tab name="Ubuntu" %}}
+
+다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다.
+
+| 운영 체제          | $OS               |
+| ---------------- | ----------------- |
+| Ubuntu 20.04     | `xUbuntu_20.04`   |
+| Ubuntu 19.10     | `xUbuntu_19.10`   |
+| Ubuntu 19.04     | `xUbuntu_19.04`   |
+| Ubuntu 18.04     | `xUbuntu_18.04`   |
+
+<br />
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
+예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
+사용자의 설치를 특정 릴리스에 고정할 수 있다.
+버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다.
+<br />
+
+그런 다음, 아래를 실행한다.
 ```shell
-# CRI-O 설치
-sudo apt-get install cri-o-1.17
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
+
+apt-get update
+apt-get install cri-o cri-o-runc
 ```
-{{< /tab >}}
+{{% /tab %}}
 
-{{< tab name="CentOS/RHEL 7.4+" >}}
+{{% tab name="CentOS" %}}
 
+다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다.
+
+| 운영 체제          | $OS               |
+| ---------------- | ----------------- |
+| Centos 8         | `CentOS_8`        |
+| Centos 8 Stream  | `CentOS_8_Stream` |
+| Centos 7         | `CentOS_7`        |
+
+<br />
+그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
+예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
+사용자의 설치를 특정 릴리스에 고정할 수 있다.
+버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다.
+<br />
+
+그런 다음, 아래를 실행한다.
 ```shell
-# 선행 조건 설치
-curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
-curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo
+sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
+sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
+sudo yum install cri-o
 ```
 
-```shell
-# CRI-O 설치
-yum install -y cri-o
-```
+{{% /tab %}}
 
-{{< tab name="openSUSE Tumbleweed" >}}
+{{% tab name="openSUSE Tumbleweed" %}}
 
 ```shell
 sudo zypper install cri-o
 ```
-{{< /tab >}}
+{{% /tab %}}
+{{% tab name="Fedora" %}}
+
+`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
+예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
+
+사용할 수 있는 버전을 찾으려면 다음을 실행한다.
+```shell
+sudo dnf module list cri-o
+```
+CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다.
+
+그런 다음, 아래를 실행한다.
+```shell
+sudo dnf module enable cri-o:$VERSION
+sudo dnf install cri-o
+```
+
+{{% /tab %}}
 {{< /tabs >}}
 
 ### CRI-O 시작
 
 ```shell
-systemctl daemon-reload
-systemctl start crio
+sudo systemctl daemon-reload
+sudo systemctl start crio
 ```
 
-자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)
-를 참고한다.
+자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를
+참고한다.
 
 ## Containerd
 
@@ -305,44 +349,44 @@ Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사
 ### 선행 조건
 
 ```shell
-cat > /etc/modules-load.d/containerd.conf <<EOF
+cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
 overlay
 br_netfilter
 EOF
 
-modprobe overlay
-modprobe br_netfilter
+sudo modprobe overlay
+sudo modprobe br_netfilter
 
 # 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅에서도 유지된다.
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
 net.bridge.bridge-nf-call-iptables  = 1
 net.ipv4.ip_forward                 = 1
 net.bridge.bridge-nf-call-ip6tables = 1
 EOF
 
-sysctl --system
+sudo sysctl --system
 ```
 
 ### containerd 설치
 
 {{< tabs name="tab-cri-containerd-installation" >}}
-{{< tab name="Ubuntu 16.04" >}}
+{{% tab name="Ubuntu 16.04" %}}
 
 ```shell
 # (containerd 설치)
 ## 리포지터리 설정
 ### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
-apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
 ```
 
 ```shell
 ## 도커 공식 GPG 키 추가
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
 ```
 
 ```shell
 ## 도커 apt 리포지터리 추가.
-add-apt-repository \
+sudo add-apt-repository \
     "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
     $(lsb_release -cs) \
     stable"
@@ -350,62 +394,91 @@ add-apt-repository \
 
 ```shell
 ## containerd 설치
-apt-get update && apt-get install -y containerd.io
+sudo apt-get update && sudo apt-get install -y containerd.io
 ```
 
 ```shell
 # containerd 설정
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
 ```
 
 ```shell
 # containerd 재시작
-systemctl restart containerd
+sudo systemctl restart containerd
 ```
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" >}}
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
 
 ```shell
 # (containerd 설치)
 ## 리포지터리 설정
 ### 필요한 패키지 설치
-yum install -y yum-utils device-mapper-persistent-data lvm2
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
 ```
 
 ```shell
 ## 도커 리포지터리 추가
-yum-config-manager \
+sudo yum-config-manager \
     --add-repo \
     https://download.docker.com/linux/centos/docker-ce.repo
 ```
 
 ```shell
 ## containerd 설치
-yum update -y && yum install -y containerd.io
+sudo yum update -y && yum install -y containerd.io
 ```
 
 ```shell
 ## containerd 설정
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
 ```
 
 ```shell
 # containerd 재시작
-systemctl restart containerd
+sudo systemctl restart containerd
 ```
-{{< /tab >}}
+{{% /tab %}}
+{{% tab name="윈도우 (PowerShell)" %}}
+```powershell
+# (containerd 설치)
+# containerd 다운로드
+cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz
+cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz
+```
+
+```powershell
+# 압축을 풀고 구성
+Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
+cd $Env:ProgramFiles\containerd\
+.\containerd.exe config default | Out-File config.toml -Encoding ascii
+
+# 구성을 검토한다. 설정에 따라 아래를 조정할 수 있다.
+# - sandbox_image (쿠버네티스 pause 이미지)
+# - cni bin_dir 및 conf_dir 위치
+Get-Content config.toml
+```
+
+```powershell
+# containerd 시작
+.\containerd.exe --register-service
+Start-Service containerd
+```
+{{% /tab %}}
 {{< /tabs >}}
 
 ### systemd
 
-`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`의 `plugins.cri.systemd_cgroup = true`을 설정한다.
+`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`에 다음을 설정한다.
+
+```
+[plugins.cri]
+systemd_cgroup = true
+```
 kubeadm을 사용하는 경우에도 마찬가지로, 수동으로
 [kubelet을 위한 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 설정한다.
 
 ## 다른 CRI 런타임: frakti
 
 자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다.
-
-
diff --git a/content/ko/docs/setup/production-environment/on-premises-vm/_index.md b/content/ko/docs/setup/production-environment/on-premises-vm/_index.md
deleted file mode 100644
index d9b92bea18..0000000000
--- a/content/ko/docs/setup/production-environment/on-premises-vm/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: 온-프레미스 VM
-weight: 40
----
diff --git a/content/ko/docs/setup/production-environment/tools/_index.md b/content/ko/docs/setup/production-environment/tools/_index.md
index 5beb1d5a9d..9b334ba262 100644
--- a/content/ko/docs/setup/production-environment/tools/_index.md
+++ b/content/ko/docs/setup/production-environment/tools/_index.md
@@ -1,4 +1,4 @@
 ---
-title: Installing Kubernetes with deployment tools
+title: 배포 도구로 쿠버네티스 설치하기
 weight: 30
 ---
diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md
index 0df78ff580..4ec5386d2f 100644
--- a/content/ko/docs/setup/production-environment/tools/kops.md
+++ b/content/ko/docs/setup/production-environment/tools/kops.md
@@ -198,7 +198,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
 
 만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은
 쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를
-통해 만들어진다. 사용자는 여러개의 인스턴스 그룹을 관리할 수 있는데,
+통해 만들어진다. 사용자는 여러 개의 인스턴스 그룹을 관리할 수 있는데,
 예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
 
 
diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md
new file mode 100644
index 0000000000..9763c7decd
--- /dev/null
+++ b/content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -0,0 +1,67 @@
+---
+reviewers:
+title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기
+content_type: concept
+weight: 100
+---
+
+<!-- overview -->
+
+### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting}
+
+kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
+해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
+통해 kubelet에 구성된 [스태틱(static) 파드](/docs/tasks/configure-pod-container/static-pod/)
+대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/docs/concepts/workloads/controllers/daemonset/)
+로 실행된다.
+
+자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
+명령어를 확인한다.
+
+<!-- body -->
+
+#### 주의사항
+
+{{< caution >}}
+이 기능은 클러스터를 지원되지 않는 상태로 전환하여 더 이상 클러스터를 관리할 수 없게 만든다.
+이것은 `kubeadm upgrade`를 포함한다.
+{{< /caution >}}
+
+1. 1.8 이후 버전에서 자체 호스팅은 몇 가지 중요한 한계가 있다.
+  특히 자체 호스팅된 클러스터는 수동 조정 없이는
+  _컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
+
+1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
+  [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
+  자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
+  관리되지 않는다.
+
+1. 컨트롤 플레인의 자체 호스팅된 부분에는 스태틱 파드로 실행되는 etcd가
+  포함되지 않는다.
+
+#### 프로세스
+
+자체 호스팅 부트스트랩 프로세스는 [kubeadm 설계
+문서](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)에 기록되어 있다.
+
+요약하면 `kubeadm alpha selfhosting`은 다음과 같이 작동한다.
+
+  1. 부트스트랩 스태틱 컨트롤 플레인이 실행되고 정상 상태가 될 때까지 기다린다.
+    이것은 자체 호스팅이 없는 `kubeadm init` 프로세스와 동일하다.
+
+  1. 스태틱 컨트롤 플레인 파드 매니페스트를 사용하여 자체 호스팅된 컨트롤
+    플레인을 실행할 데몬셋 매니페스트 집합을 구성한다. 또한 필요한 경우
+    해당 매니페스트를 수정한다. 예를 들어, 시크릿을 위한 새로운 볼륨을
+    추가한다.
+
+  1. `kube-system` 네임스페이스에 데몬셋을 생성하고 결과 파드가 실행될 때까지
+    대기한다.
+
+  1. 일단 자체 호스팅된 파드가 동작하면 관련 스태틱 파드가 삭제되고
+    kubeadm은 계속해서 다음 구성 요소를 설치한다.
+    이것은 kubelet이 스태틱 파드를 멈추게 한다.
+
+  1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
+    리스닝 포트에 바인딩하여 활성화할 수 있다.
+
+
diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md
new file mode 100644
index 0000000000..c4373a15d3
--- /dev/null
+++ b/content/ko/docs/setup/production-environment/tools/kubespray.md
@@ -0,0 +1,119 @@
+---
+title: Kubespray로 쿠버네티스 설치하기
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+
+이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
+
+Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
+
+* 고가용성을 지닌 클러스터
+* 구성할 수 있는 속성들
+* 대부분의 인기있는 리눅스 배포판들에 대한 지원
+    * Ubuntu 16.04, 18.04, 20.04
+    * CentOS/RHEL/Oracle Linux 7, 8
+    * Debian Buster, Jessie, Stretch, Wheezy
+    * Fedora 31, 32
+    * Fedora CoreOS
+    * openSUSE Leap 15
+    * Flatcar Container Linux by Kinvolk
+* 지속적인 통합 (CI) 테스트
+
+클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
+
+<!-- body -->
+
+## 클러스터 생성하기
+
+
+### (1/5) 아래의 요건 충족하기
+
+언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다.
+
+* **Ansible의 명령어를 실행하기 위해 Ansible v 2.9와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**
+* **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다**
+* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
+* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
+* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
+* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
+* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
+
+Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:
+
+* 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트:
+  * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
+  * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
+  * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
+
+### (2/5) 인벤토리 파일 구성하기
+
+서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/intro_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자.
+
+### (3/5) 클러스터 디플로이먼트 계획하기
+
+Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의(customize)할 수 있다:
+
+* 디플로이먼트 모드의 선택: kubeadm 또는 그 외
+* CNI(네트워킹) 플러그인
+* DNS 설정
+* 컨트롤 플레인 선택: 네이티브/바이너리 또는 컨테이너화 된 것
+* 컴포넌트 버전
+* Calico 라우터 리플렉터
+* 컴포넌트 런타임 옵션
+  * {{< glossary_tooltip term_id="docker" >}}
+  * {{< glossary_tooltip term_id="containerd" >}}
+  * {{< glossary_tooltip term_id="cri-o" >}}
+* 인증서 생성 방법
+
+Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.
+
+### (4/5) 클러스터 배포하기
+
+다음으로, 클러스터를 배포한다.
+
+[Ansible-플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment)을 이용한 클러스터 디플로이먼트
+
+```shell
+ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
+  --private-key=~/.ssh/private_key
+```
+
+규모가 큰 디플로이먼트는 (100개 이상의 노드) 최적의 결과를 얻기 위해 [특정한 조정](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)을 필요로 할 수도 있다.
+
+### (5/5) 디플로이먼트 검증하기
+
+Kubespray는 Netchecker를 사용하여 파드 사이의 연결성과 DNS 해석을 검증할 방법을 제공한다. Netchecker는 netchecker-agents 파드들이 DNS 요청을 해석하고 기본(default) 네임스페이스 내부에서 서로에게 ping을 보낼 수 있도록 보장한다. 그 파드들은 나머지 워크로드의 유사한 동작을 모방하고 클러스터의 상태 표시기 역할을 한다.
+
+## 클러스터 동작
+
+Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _scale_ 과 _upgrade_ 를 제공한다.
+
+### 클러스터 스케일링하기
+
+scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
+
+### 클러스터 업그레이드 하기
+
+upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할 수 있다. 더 자세히 알고 싶다면 "[업그레이드](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)" 문서를 확인하자.
+
+## 클린업
+
+[reset 플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml)을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.
+
+{{< caution >}} 
+reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타겟으로 삼지 않도록 해야 한다!
+{{< /caution >}}
+
+## 피드백
+
+* Slack 채널: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) ([이 곳](https://slack.k8s.io/)에서 초대를 받을 수 있다)
+* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
+
+## {{% heading "whatsnext" %}}
+
+
+Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
+
diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
new file mode 100644
index 0000000000..b41120f7be
--- /dev/null
+++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -0,0 +1,678 @@
+---
+title: 쿠버네티스의 윈도우 지원 소개
+content_type: concept
+weight: 65
+---
+
+<!-- overview -->
+
+윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. [윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 ​​사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다.
+
+
+
+<!-- body -->
+
+## 쿠버네티스의 윈도우 컨테이너
+
+쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함하기만 하면 된다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것만큼 간단하고 쉽다.
+
+윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다.
+
+{{< note >}}
+[마스터 컴포넌트](/ko/docs/concepts/overview/components/)를 포함한 쿠버네티스 컨트롤 플레인은 리눅스에서 계속 실행된다. 윈도우 전용 쿠버네티스 클러스터는 계획이 없다.
+{{< /note >}}
+
+{{< note >}}
+이 문서에서 윈도우 컨테이너에 대해 이야기할 때 프로세스 격리된 윈도우 컨테이너를 의미한다. [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)가 있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다.
+{{< /note >}}
+
+## 지원되는 기능 및 제한
+
+### 지원되는 기능
+
+#### 윈도우 OS 버전 지원
+
+쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다.
+
+| 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
+| --- | --- | --- | --- |
+| *Kubernetes v1.14* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.15* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.16* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 |
+| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 |
+| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
+
+{{< note >}}
+지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다.
+{{< /note >}}
+{{< note >}}
+모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
+{{< /note >}}
+{{< note >}}
+윈도우 서버 호스트 운영 체제에는 [윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 [윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다.
+{{< /note >}}
+{{< note >}}
+프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, [여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다.
+{{< /note >}}
+
+#### 컴퓨트
+
+API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 [제한 섹션](#제한)에 요약된 주요 기능에는 몇 가지 눈에 띄는 차이점이 있다.
+
+윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다.
+
+* [파드](/ko/docs/concepts/workloads/pods/)
+
+    파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.
+
+  * 프로세스 분리 및 볼륨 공유 기능을 갖춘 파드 당 하나 또는 여러 개의 컨테이너
+  * 파드 상태 필드
+  * 준비성(readiness) 및 활성 프로브(liveness probe)
+  * postStart 및 preStop 컨테이너 라이프사이클 이벤트
+  * 컨피그맵(ConfigMap), 시크릿(Secrets): 환경 변수 또는 볼륨으로
+  * EmptyDir
+  * 명명된 파이프 호스트 마운트
+  * 리소스 제한
+* [컨트롤러](/ko/docs/concepts/workloads/controllers/)
+
+    쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다.
+
+  * 레플리카셋(ReplicaSet)
+  * 레플리케이션컨트롤러(ReplicationController)
+  * 디플로이먼트(Deployment)
+  * 스테이트풀셋(StatefulSet)
+  * 데몬셋(DaemonSet)
+  * 잡(Job)
+  * 크론잡(CronJob)
+* [서비스](/ko/docs/concepts/services-networking/service/)
+
+    쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 다음의 유형, 속성 및 기능을 활용할 수 있다.
+
+  * 서비스 환경 변수
+  * 노드포트(NodePort)
+  * 클러스터IP(ClusterIP)
+  * 로드밸런서(LoadBalancer)
+  * ExternalName
+  * 헤드리스 서비스(Headless services)
+
+파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 충분하지 않다. 다음 기능에 대한 지원이 추가되었다.
+
+* 파드와 컨테이너 메트릭
+* Horizontal Pod Autoscaler 지원
+* kubectl Exec
+* 리소스쿼터(Resource Quotas)
+* 스케쥴러 선점(preemption)
+
+#### 컨테이너 런타임
+
+##### Docker EE
+
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+
+Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다.
+
+##### CRI-ContainerD
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+{{< caution >}}
+커널 패치가 필요한 윈도우 네트워크 공유에 접근하기 위해 ContainerD와 함께 GMSA를 사용할 때 [알려진 제한](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있다. [Microsoft 윈도우 컨테이너 이슈 트래커](https://github.com/microsoft/Windows-Containers/issues/44)에서 업데이트를 확인한다.
+{{< /caution >}}
+
+{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0-beta.2+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다.
+
+쿠버네티스 v1.18은 윈도우에서 ContainerD에 대한 초기 지원을 추가한다. 윈도우에서 ContainerD의 진행 상황은 [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001)에서 확인할 수 있다.
+
+[윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) 방법을 확인한다.
+
+#### 퍼시스턴트 스토리지(Persistent Storage)
+
+쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 [플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다.
+
+##### 인-트리(In-tree) 볼륨 플러그인
+인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다.
+
+* [awsElasticBlockStore](/ko/docs/concepts/storage/volumes/#awselasticblockstore)
+* [azureDisk](/ko/docs/concepts/storage/volumes/#azuredisk)
+* [azureFile](/ko/docs/concepts/storage/volumes/#azurefile)
+* [gcePersistentDisk](/ko/docs/concepts/storage/volumes/#gcepersistentdisk)
+* [vsphereVolume](/ko/docs/concepts/storage/volumes/#vspherevolume)
+
+##### FlexVolume 플러그인
+[FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다.
+
+* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
+* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
+
+##### CSI 플러그인
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 플러그인으로 구성된다.
+
+CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 다양한 특권이 필요한(privileged) 작업을 수행해야 한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, 각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 사용하여 지원된다. 자세한 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다.
+
+#### 네트워킹
+
+윈도우 컨테이너용 네트워킹은 [CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다. 윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다.
+
+* 가상 네트워크(vSwitch 생성 포함)
+* 엔드포인트 / vNIC
+* 네임스페이스
+* 정책(패킷 캡슐화, 로드 밸런싱 규칙, ACL, NAT 규칙 등)
+
+다음의 서비스 사양 유형이 지원된다.
+
+* NodePort
+* ClusterIP
+* LoadBalancer
+* ExternalName
+
+##### 네트워크 모드
+윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다.
+
+| 네트워크 드라이버 | 설명 | 컨테이너 패킷 수정 | 네트워크 플러그인 | 네트워크 플러그인 특성 |
+| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
+| L2bridge | 컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. | MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 호스트 IP에 다시 쓰여질 수 있다. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel 호스트 게이트웨이는 win-bridge를 사용한다. | win-bridge는 L2bridge 네트워크 모드를 사용하고, 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. |
+| L2Tunnel | 이것은 l2bridge의 특별한 케이스이지만 Azure에서만 사용된다. 모든 패킷은 SDN 정책이 적용되는 가상화 호스트로 전송된다. | MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, [Azure Virtual Network에서 제공하는](https://azure.microsoft.com/ko-kr/services/virtual-network/) 기능 집합을 활용할 수 있다. 예를 들어 Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. [azure-cni 예제](https://docs.microsoft.com/ko-kr/azure/aks/concepts-network#azure-cni-advanced-networking)를 참고한다. |
+| 오버레이(쿠버네티스에서 윈도우용 오버레이 네트워킹은 *알파* 단계에 있음) | 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. | 외부 헤더로 캡슐화된다. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN(win-overlay 사용) | win-overlay는 가상 컨테이너 네트워크를 호스트의 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 윈도우 서버 2019에서 [KB4489899](https://support.microsoft.com/help/4489899)가 필요하다. |
+| Transparent([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)의 특수한 유스케이스) | 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다. | 패킷은 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 또는 [STT](https://datatracker.ietf.org/doc/draft-davie-stt)를 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다. <br/> 패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. <br/> NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible을 통해 배포](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)한다. 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 iptables/netsh를 사용하지 않고 수행된다. |
+| NAT(*쿠버네티스에서 사용되지 않음*) | 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)라는 내부 컴포넌트를 사용하여 제공된다. | MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 완전성을 위해 여기에 포함되었다. |
+
+위에서 설명한대로 [플라넬(Flannel)](https://github.com/coreos/flannel) CNI [메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 [VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**alpha 지원**, win-overlay에 위임) 및 [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (안정적인 지원, win-bridge에 위임)를 통해 [윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다.
+
+노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다.
+
+* 파드 -> 파드(IP)
+* 파드 -> 파드(Name)
+* 파드 -> 서비스(Cluster IP)
+* 파드 -> 서비스(PQDN, 단 "."이 없는 경우에만)
+* 파드 -> 서비스(FQDN)
+* 파드 -> External(IP)
+* 파드 -> External(DNS)
+* 노드 -> 파드
+* 파드 -> 노드
+
+##### IP 주소 관리(IPAM) {#ipam}
+윈도우에서는 다음 IPAM 옵션이 지원된다.
+
+* [호스트-로컬](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
+* HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다)
+* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cni 전용)
+
+##### 로드 밸런싱과 서비스
+
+윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 구성할 수 있다.
+
+{{< table caption="윈도우 서비스 구성" >}}
+| 기능 | 설명 | 지원되는 쿠버네티스 버전 | 지원되는 윈도우 OS 빌드 | 활성화하는 방법 |
+| ------- | ----------- | ----------------------------- | -------------------------- | ------------- |
+| 세션 어피니티 | 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 한다. | v1.19 이상 | [윈도우 서버 vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) 이상 | `service.spec.sessionAffinity`를 "ClientIP"로 설정 |
+| 직접 서버 반환 | IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 설정된 상태로 도착한다. 낮은 지연 시간과 확장성을 약속한다. | v1.15 이상 | 윈도우 서버, 버전 2004 | kube-proxy에서 다음 플래그를 설정한다. `--feature-gates="WinDSR=true" --enable-dsr=true` |
+| 대상 보존(Preserve-Destination) | 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 대상 서비스의 가상 IP를 보존한다. 이 설정은 또한 수신 패킷의 클라이언트 IP가 보존되도록 한다. | v1.15 이상 | 윈도우 서버, 버전 1903 (이상) | 서비스 어느테이션에서 `"preserve-destination": "true"`를 설정하고 kube-proxy에서 DSR 플래그를 활성화한다. |
+| IPv4/IPv6 이중 스택 네트워킹 | 클러스터 내/외부 기본 IPv4-to-IPv4 통신과 함께 IPv6-to-IPv6 통신 | v1.19 이상 | 윈도우 서버 vNext Insider Preview Build 19603(또는 그 이상) | [IPv4/IPv6 이중 스택](#ipv4ipv6-이중-스택)을 참고한다. |
+{{< /table >}}
+
+#### IPv4/IPv6 이중 스택
+`IPv6DualStack` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)을 참조한다.
+
+{{< note >}}
+윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 vNext Insider Preview Build 19603 이상이 필요하다.
+{{< /note >}}
+
+{{< note >}}
+윈도우의 오버레이(VXLAN) 네트워크는 현재 이중 스택 네트워킹을 지원하지 않는다.
+{{< /note >}}
+
+### 제한
+
+#### 컨트롤 플레인
+
+윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.
+
+#### 컴퓨트
+
+##### 리소스 관리 및 프로세스 격리
+
+ 리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다.
+
+##### 운영 체제 제한
+
+윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
+
+##### 기능 제한
+
+* TerminationGracePeriod: 구현되지 않음
+* 단일 파일 매핑: CRI-ContainerD로 구현 예정
+* 종료 메시지: CRI-ContainerD로 구현 예정
+* 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
+* HugePages: 현재 윈도우 컨테이너에서 지원되지 않음
+* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다.
+* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조).
+
+##### 메모리 예약 및 처리
+
+윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다.
+
+2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다.
+
+오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다.
+
+플래그의 동작은 아래에 설명된 대로 다르게 동작한다.
+
+* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트
+* `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다.
+* `--eviction-hard`와 `--eviction-soft`를 사용한 축출은 구현되지 않았다.
+* MemoryPressure 조건은 구현되지 않았다.
+* kubelet이 취한 OOM 축출 조치가 없다.
+* 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다.
+
+#### 스토리지
+
+윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다.
+
+* 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉터리만 대상으로 할 수 있다.
+* 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다.
+* 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다.
+* 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다.
+
+결과적으로, 다음 스토리지 기능은 윈도우 노드에서 지원되지 않는다.
+
+* 볼륨 하위 경로(subpath) 마운트. 전체 볼륨만 윈도우 컨테이너에 마운트할 수 있다.
+* 시크릿에 대한 하위 경로 볼륨 마운트
+* 호스트 마운트 프로젝션
+* DefaultMode(UID/GID 종속성에 기인함)
+* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 ​​읽기 전용을 지원한다.
+* 블록 디바이스 매핑
+* 저장 매체로서의 메모리
+* uui/guid, 사용자별 리눅스 파일시스템 권한과 같은 파일시스템 기능
+* NFS 기반 스토리지/볼륨 지원
+* 마운트된 볼륨 확장(resizefs)
+
+#### 네트워킹
+
+윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다.
+
+윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다.
+
+다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다.
+
+* 윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다.
+* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서 작동)
+* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다.
+* kube-proxy의 오버레이 네트워킹 지원은 알파 릴리스이다. 또한 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 설치해야 한다.
+* 로컬 트래픽 정책 및 DSR 모드
+* l2bridge, l2tunnel 또는 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이러한 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다.
+* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은 ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다.
+  * 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 ICMP 패킷은 예상대로 제한 없이 작동한다.
+  * TCP/UDP 패킷은 예상대로 제한 없이 작동한다.
+  * 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 소스로 다시 라우팅되지 않는다.
+  * TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에 `ping <destination>`을 `curl <destination>`으로 대체하여 외부와의 연결을 디버깅할 수 있다.
+
+해당 기능은 쿠버네티스 v1.15에 추가되었다.
+
+* `kubectl port-forward`
+
+##### CNI 플러그인
+
+* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 현재 "CHECK" 구현 누락으로 인해 [CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0을 구현하지 않는다.
+* Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다.
+
+1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 있는 로컬 파드에서만 가능하다.
+2. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) 백엔드 문서를 참고한다.
+
+##### DNS {#dns-limitations}
+
+* ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다.
+* 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 연결된 DNS 접미사인 DNS 접미사 1개만 있다. 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS 접미사 **default.svc.cluster.local**이 있다. 윈도우 파드에서는 **kubernetes.default.svc.cluster.local** 및 **kubernetes**를 모두 확인할 수 있지만 **kubernetes.default** 또는 **kubernetes.default.svc**와 같은 중간 항목은 확인할 수 없다.
+* 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 사용하는 것이 좋다.
+
+##### IPv6
+윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다.
+
+
+##### 세션 어피니티(affinity)
+`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다.
+
+##### 보안
+
+시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다.
+
+1. 파일 ACL을 사용하여 시크릿 파일 위치를 보호한다.
+2. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용한 볼륨-레벨 암호화를 사용한다.
+
+[RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)는 현재 윈도우에서 지원되지 않는다. 해결 방법(workaround)은 컨테이너를 패키징하기 전에 로컬 계정을 만드는 것이다. RunAsUsername 기능은 향후 릴리스에 추가될 수 있다.
+
+SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다.
+
+또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 않는다.
+
+#### API
+
+대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. 중요한 차이점은 OS와 컨테이너 런타임의 차이로 귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 설계되었다.
+
+높은 수준에서 이러한 OS 개념은 다르다.
+
+* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다.
+* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다.
+* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 일반적으로 두 가지를 모두 허용하고 작동하도록 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
+* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다.
+  * UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다.
+  * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다.
+  * 서비스는 SERVICE_CONTROL_STOP 제어 코드를 수용할 수 있는 Service Control Handler 함수를 등록한다.
+
+종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. 특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다.
+
+##### V1.Container
+
+* V1.Container.ResourceRequirements.limits.cpu 및 V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 스케일된다. [참고: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [참고: Microsoft 문서 내 리소스 제어](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/resource-controls)
+  * Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 [사용자 권한(privilege) 어설트](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가 필요하다.
+* V1.Container.ResourceRequirements.requests.cpu 및 V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 모범 사례로 모든 컨테이너에 적용해야 한다.
+* V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 불가능하며, 어떤 기능도 연결되지 않는다.
+* V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 구현되지 않는다.
+* V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 지원하지 않는다.
+* V1.Container.SecurityContext.procMount - 윈도우에는 /proc 파일시스템이 없다.
+* V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 필요하다.
+* V1.Container.SecurityContext.runAsGroup - 윈도우에서는 불가능하며, GID 지원이 없다.
+* V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 ContainerAdministrator이다.
+* V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID 지원이 없다.
+* V1.Container.SecurityContext.seLinuxOptions - 윈도우에서는 불가능하며, SELinux가 없다.
+* V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 작동한다.
+
+##### V1.Pod
+
+* V1.Pod.hostIPC, v1.pod.hostpid - 윈도우에서 호스트 네임스페이스 공유가 불가능하다.
+* V1.Pod.hostNetwork - 호스트 네트워크를 공유하기 위한 윈도우 OS 지원이 없다.
+* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 지원되지 않는다.
+* V1.Pod.podSecurityContext - 아래 V1.PodSecurityContext 내용을 참고한다.
+* V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다.
+* V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 완전히 구현되지 않았다. [참조](https://github.com/moby/moby/issues/25982)의 내용을 참고한다. 현재 동작은 ENTRYPOINT 프로세스가 CTRL_SHUTDOWN_EVENT로 전송된 다음, 윈도우가 기본적으로 5초를 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다. 5초 기본값은 실제로 [컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다.
+* V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다.
+* V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 TestGrid에 테스트가 있다.
+  * V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다.
+* V1.VolumeMount.mountPropagation - 마운트 전파(propagation)는 윈도우에서 지원되지 않는다.
+
+##### V1.PodSecurityContext
+
+PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 나열한다.
+
+* V1.PodSecurityContext.SELinuxOptions - SELinux는 윈도우에서 사용할 수 없다.
+* V1.PodSecurityContext.RunAsUser - 윈도우에서는 사용할 수 없는 UID를 제공한다.
+* V1.PodSecurityContext.RunAsGroup - 윈도우에서는 사용할 수 없는 GID를 제공한다.
+* V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티인 ContainerAdministrator이다.
+* V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다.
+* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다.
+
+## 도움 받기 및 트러블슈팅 {#troubleshooting}
+
+쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 [섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows [로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다.
+
+1. start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가?
+
+    kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 한다.
+
+1. 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가?
+
+    Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 자동으로 다시 시작하여 복원력(resiliency)을 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 두 가지 옵션이 있다.
+
+    1. 네이티브 윈도우 서비스
+
+        Kubelet와 kube-proxy는 `sc.exe`를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다.
+
+        ```powershell
+        # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성
+        sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>"
+
+        # 인자에 공백이 포함된 경우 이스케이프 되어야 한다.
+        sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>"
+
+        # 서비스 시작
+        Start-Service kubelet
+        Start-Service kube-proxy
+
+        # 서비스 중지
+        Stop-Service kubelet (-Force)
+        Stop-Service kube-proxy (-Force)
+
+        # 서비스 상태 질의
+        Get-Service kubelet
+        Get-Service kube-proxy
+        ```
+
+    1. nssm.exe 사용
+
+        또한 언제든지 [nssm.exe](https://nssm.cc/)와 같은 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, kube-proxy)를 실행할 수 있다. 이 [샘플 스크립트](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)를 사용하여 백그라운드에서 윈도우 서비스로 실행하기 위해 nssm.exe를 활용하여 kubelet, kube-proxy, flanneld.exe를 등록할 수 있다.
+
+        ```powershell
+        register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP <Kube-dns 서비스 IP> -LogDir <로그 위치 디렉터리>
+
+        # NetworkMode      = 네트워크 모드 l2bridge(flannel host-gw, 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan)
+        # ManagementIP     = 윈도우 노드에 할당된 IP 주소. ipconfig를 사용하여 찾을 수 있다.
+        # ClusterCIDR      = 클러스터 서브넷 범위. (기본값 10.244.0.0/16)
+        # KubeDnsServiceIP = 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10)
+        # LogDir           = kubelet 및 kube-proxy 로그가 각각의 출력 파일로 리다이렉션되는 디렉터리(기본값 C:\k)
+        ```
+
+        위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 nssm.exe를 수동으로 구성할 수 있다.
+        ```powershell
+        # flanneld.exe 등록
+        nssm install flanneld C:\flannel\flanneld.exe
+        nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1
+        nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname>
+        nssm set flanneld AppDirectory C:\flannel
+        nssm start flanneld
+
+        # kubelet.exe 등록
+        # Microsoft는 mcr.microsoft.com/k8s/core/pause:1.2.0에서 pause 인프라 컨테이너를 릴리스했다.
+        nssm install kubelet C:\k\kubelet.exe
+        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+        nssm set kubelet AppDirectory C:\k
+        nssm start kubelet
+
+        # kube-proxy.exe 등록 (l2bridge / host-gw)
+        nssm install kube-proxy C:\k\kube-proxy.exe
+        nssm set kube-proxy AppDirectory c:\k
+        nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false
+        nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
+        nssm set kube-proxy DependOnService kubelet
+        nssm start kube-proxy
+
+        # kube-proxy.exe 등록 (overlay / vxlan)
+        nssm install kube-proxy C:\k\kube-proxy.exe
+        nssm set kube-proxy AppDirectory c:\k
+        nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
+        nssm set kube-proxy DependOnService kubelet
+        nssm start kube-proxy
+        ```
+
+
+        초기 트러블슈팅을 위해 [nssm.exe](https://nssm.cc/)에서 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다.
+
+        ```powershell
+        nssm set <Service Name> AppStdout C:\k\mysvc.log
+        nssm set <Service Name> AppStderr C:\k\mysvc.log
+        ```
+
+        자세한 내용은 공식 [nssm 사용](https://nssm.cc/usage) 문서를 참고한다.
+
+1. 내 윈도우 파드에 네트워크 연결이 없다.
+
+    가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 활성화되어 있는지 확인한다.
+
+1. 내 윈도우 파드가 외부 리소스를 ping 할 수 없다.
+
+    윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, `ping <IP>`를 해당 `curl <IP>`명령으로 대체한다.
+
+    여전히 문제가 발생하는 경우, [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다.
+
+    쿠버네티스 네트워킹 요구 사항 중 하나([쿠버네티스 모델](/ko/docs/concepts/cluster-administration/networking/))는 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 `cni.conf`의 ExceptionList는 다음과 같아야 한다.
+
+    ```conf
+    "ExceptionList": [
+                    "10.244.0.0/16",  # 클러스터 서브넷
+                    "10.96.0.0/12",   # 서비스 서브넷
+                    "10.127.130.0/24" # 관리(호스트) 서브넷
+                ]
+    ```
+
+1. 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다.
+
+    노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다.
+
+1. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다.
+
+    이 문제는 `hostname-override` 파라미터가 [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.
+
+    ```powershell
+    C:\k\kube-proxy.exe --hostname-override=$(hostname)
+    ```
+
+1. 플라넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다.
+
+    이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다.
+
+    ```powershell
+    Remove-Item C:\k\SourceVip.json
+    Remove-Item C:\k\SourceVipRequest.json
+    ```
+
+1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다.
+
+    이 [조사 중인 이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때 타이밍 이슈일 가능성이 높다. 해결 방법은 간단히 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다.
+
+    ```powershell
+    PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
+    PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
+    ```
+
+1. `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다.
+
+    이것은 플라넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 `/run/flannel/subnet.env`에서 윈도우 워커 노드의 `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다.
+
+    ```env
+    FLANNEL_NETWORK=10.244.0.0/16
+    FLANNEL_SUBNET=10.244.4.1/24
+    FLANNEL_MTU=1500
+    FLANNEL_IPMASQ=true
+    ```
+
+1. 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다.
+
+    이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다.
+
+1. kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다.
+
+    윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다.
+
+    ```powershell
+    Get-HnsNetwork | ? Name -ieq "cbr0"
+    Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
+    ```
+
+    호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
+
+1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
+
+    pause 이미지가 OS 버전과 호환되는지 확인한다. [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다.
+
+    쿠버네티스 v1.14부터 Microsoft는 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 pause 인프라 컨테이너를 릴리스한다.
+
+1. DNS 확인(resolution)이 제대로 작동하지 않는다.
+
+    이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다.
+
+1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.
+
+    이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
+    자체 pause 인프라 컨테이너를 빌드하려면 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다.
+
+1. 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다.
+
+    프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 정의해야 한다.
+
+    ```PowerShell
+    [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+    [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+    ```
+
+1. `pause` 컨테이너란 무엇인가?
+
+    쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다.
+
+    "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 참고한다.
+
+### 추가 조사
+
+이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는데 도움을 받을 수 있다.
+
+* 스택오버플로우 [윈도우 서버 컨테이너](https://stackoverflow.com/questions/tagged/windows-server-container) 주제
+* 쿠버네티스 공식 포럼 [discuss.kubernetes.io](https://discuss.kubernetes.io/)
+* 쿠버네티스 슬랙 [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
+
+## 이슈 리포팅 및 기능 요청
+
+버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면, [GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 활용한다. [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)에서 이슈를 열고 SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 이슈에 대한 경험을 언급하고 추가 로그를 첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다.
+
+버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 포함한다.
+
+* 쿠버네티스 버전: kubectl version
+* 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 구성, 도커 버전
+* 문제를 재현하기 위한 세부 단계
+* [관련 로그](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
+* SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 이슈에 sig/windows 태그를 지정한다.
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+로드맵에는 많은 기능이 있다. 요약된 높은 수준의 목록이 아래에 포함되어 있지만, [로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 [기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 윈도우 지원을 개선하는데 도움이 주는 것이 좋다.
+
+### Hyper-V 격리(isolation)
+
+쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 Hyper-V 격리가 필요하다.
+
+* 추가 보안을 위해 파드 간 하이퍼바이저 기반 격리
+* 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 최신 윈도우 서버 버전을 실행할 수 있다.
+* 파드에 대한 특정 CPU/NUMA 설정
+* 메모리 격리 및 예약
+
+v1.10의 실험적(experimental) 기능인 기존 Hyper-V 격리 지원은 위에서 언급한 CRI-ContainerD와 런타임클래스(RuntimeClass) 기능을 위해 향후 사용 중단(deprecated)된다. 현재 기능을 사용하고 Hyper-V 격리된 컨테이너를 만들려면, kubelet을 기능 게이트(feature gates) `HyperVContainer=true`로 시작해야 하고 파드에 `experimental.windows.kubernetes.io/isolation-type=hyperv` 어노테이션을 포함해야 한다. 실험 릴리스에서 이 기능은 파드 당 컨테이너 1개로 제한된다.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: iis
+spec:
+  selector:
+    matchLabels:
+      app: iis
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: iis
+      annotations:
+        experimental.windows.kubernetes.io/isolation-type: hyperv
+    spec:
+      containers:
+      - name: iis
+        image: microsoft/iis
+        ports:
+        - containerPort: 80
+```
+
+### kubeadm 및 클러스터 API를 사용한 배포
+
+Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이
+되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만
+[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
+또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에
+투자하고 있다.
+
+### 몇 가지 기타 주요 기능
+* 그룹 관리 서비스 어카운트(Service Accounts)에 대한 베타 지원
+* 더 많은 CNI
+* 더 많은 스토리지 플러그인
diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
index 41001c38df..f129386a62 100644
--- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
@@ -19,7 +19,7 @@ weight: 75
 
 ## 시작하기 전에
 
-* [윈도우 서버에서 운영하는 마스터와 워커 노드](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다.
+* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다.
 * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다.
 
 ## 시작하기: 윈도우 컨테이너 배포하기
diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md
index 740d468acc..9fec5907b9 100644
--- a/content/ko/docs/setup/release/notes.md
+++ b/content/ko/docs/setup/release/notes.md
@@ -1,800 +1,2415 @@
 ---
-title: v1.18 릴리스 노트
+title: v1.19 릴리스 노트
 weight: 10
 card:
   name: release-notes
   weight: 20
   anchors:
   - anchor: "#"
-    title: 최신 릴리스 노트
+    title: 현재 릴리스 노트
   - anchor: "#긴급-업그레이드-노트"
     title: 긴급 업그레이드 노트
 ---
 
 <!-- NEW RELEASE NOTES ENTRY -->
 
-# v1.18.0
+# v1.19.0
 
 [문서](https://docs.k8s.io)
 
-## v1.18.0 다운로드
+## v1.19.0 다운로드
 
 파일명 | sha512 해시
 -------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes.tar.gz) | `cd5b86a3947a4f2cea6d857743ab2009be127d782b6f2eb4d37d88918a5e433ad2c7ba34221c34089ba5ba13701f58b657f0711401e51c86f4007cb78744dee7`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-src.tar.gz) | `fb42cf133355ef18f67c8c4bb555aa1f284906c06e21fa41646e086d34ece774e9d547773f201799c0c703ce48d4d0e62c6ba5b2a4d081e12a339a423e111e52`
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes.tar.gz) | `448b941e973a519a500eb24786f6deb7eebd0e1ecb034941e382790ff69dfc2838715a222cfc53bea7b75f2c6aedc7425eded4aad69bf88773393155c737f9c0`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-src.tar.gz) | `47d253e6eb1f6da730f4f3885e205e6bfde88ffe66d92915465108c9eaf8e3c5d1ef515f8bf804a726db057433ecd25008ecdef624ee68ad9c103d1c7a615aad`
 
 ### 클라이언트 바이너리
 
 파일명 | sha512 해시
 -------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-386.tar.gz) | `26df342ef65745df12fa52931358e7f744111b6fe1e0bddb8c3c6598faf73af997c00c8f9c509efcd7cd7e82a0341a718c08fbd96044bfb58e80d997a6ebd3c2`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-darwin-amd64.tar.gz) | `803a0fed122ef6b85f7a120b5485723eaade765b7bc8306d0c0da03bd3df15d800699d15ea2270bb7797fa9ce6a81da90e730dc793ea4ed8c0149b63d26eca30`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-386.tar.gz) | `110844511b70f9f3ebb92c15105e6680a05a562cd83f79ce2d2e25c2dd70f0dbd91cae34433f61364ae1ce4bd573b635f2f632d52de8f72b54acdbc95a15e3f0`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-amd64.tar.gz) | `594ca3eadc7974ec4d9e4168453e36ca434812167ef8359086cd64d048df525b7bd46424e7cc9c41e65c72bda3117326ba1662d1c9d739567f10f5684fd85bee`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm.tar.gz) | `d3627b763606557a6c9a5766c34198ec00b3a3cd72a55bc2cb47731060d31c4af93543fb53f53791062bb5ace2f15cbaa8592ac29009641e41bd656b0983a079`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-arm64.tar.gz) | `ba9056eff1452cbdaef699efbf88f74f5309b3f7808d372ebf6918442d0c9fea1653c00b9db3b7626399a460eef9b1fa9e29b827b7784f34561cbc380554e2ea`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-ppc64le.tar.gz) | `f80fb3769358cb20820ff1a1ce9994de5ed194aabe6c73fb8b8048bffc394d1b926de82c204f0e565d53ffe7562faa87778e97a3ccaaaf770034a992015e3a86`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-linux-s390x.tar.gz) | `a9b658108b6803d60fa3cd4e76d9e58bf75201017164fe54054b7ccadbb68c4ad7ba7800746940bc518d90475e6c0a96965a26fa50882f4f0e56df404f4ae586`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-386.tar.gz) | `18adffab5d1be146906fd8531f4eae7153576aac235150ce2da05aee5ae161f6bd527e8dec34ae6131396cd4b3771e0d54ce770c065244ad3175a1afa63c89e1`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-client-windows-amd64.tar.gz) | `162396256429cef07154f817de2a6b67635c770311f414e38b1e2db25961443f05d7b8eb1f8da46dec8e31c5d1d2cd45f0c95dad1bc0e12a0a7278a62a0b9a6b`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-darwin-amd64.tar.gz) | `7093a34298297e46bcd1ccb77a9c83ca93b8ccb63ce2099d3d8cd8911ccc384470ac202644843406f031c505a8960d247350a740d683d8910ca70a0b58791a1b`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-386.tar.gz) | `891569cff7906732a42b20b86d1bf20a9fe873f87b106e717a5c0f80728b5823c2a00c7ccea7ec368382509f095735089ddd582190bc51dcbbcef6b8ebdbd5cc`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-amd64.tar.gz) | `1590d4357136a71a70172e32820c4a68430d1b94cf0ac941ea17695fbe0c5440d13e26e24a2e9ebdd360c231d4cd16ffffbbe5b577c898c78f7ebdc1d8d00fa3`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-arm.tar.gz) | `bc0fb19fb6af47f591adc64b5a36d3dffcadc35fdfd77a4a222e037dbd2ee53fafb84f13c4e307910cfa36b3a46704063b42a14ceaad902755ec14c492ccd51d`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-arm64.tar.gz) | `6ff47f4fdfb3b5f2bfe18fd792fe9bfc747f06bf52de062ee803cda87ac4a98868d8e1211742e32dd443a4bdb770018bbdde704dae6abfc6d80c02bdfb4e0311`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-ppc64le.tar.gz) | `d8816518adc3a7fc00f996f23ff84e6782a3ebbba7ef37ba44def47b0e6506fefeeaf37d0e197cecf0deb5bd1a8f9dd1ba82af6c29a6b9d21b8e62af965b6b81`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-linux-s390x.tar.gz) | `662fd4618f2b747d2b0951454b9148399f6cd25d3ca7c40457b6e02cb20df979138cad8cccd18fc8b265d9426c90828d3f0b2a6b40d9cd1a1bdc17219e35ed33`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-windows-386.tar.gz) | `d90cb92eb33ecbfab7a0e3a2da60ab10fc59132e4bc9abe0a1461a13222b5016704a7cfe0bf9bcf5d4ec55f505ffbbf53162dfe570e8f210e3f68b0d3a6bf7e3`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-client-windows-amd64.tar.gz) | `6ec32a8a62b69363a524c4f8db765ff4bd16ea7e5b0eb04aa5a667f8653eda18c357a97513d9e12f0ba1612516acb150deffb6e3608633c62b97a15b6efa7cc0`
 
 ### 서버 바이너리
 
 파일명 | sha512 해시
 -------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-amd64.tar.gz) | `a92f8d201973d5dfa44a398e95fcf6a7b4feeb1ef879ab3fee1c54370e21f59f725f27a9c09ace8c42c96ac202e297fd458e486c489e05f127a5cade53b8d7c4`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm.tar.gz) | `62fbff3256bc0a83f70244b09149a8d7870d19c2c4b6dee8ca2714fc7388da340876a0f540d2ae9bbd8b81fdedaf4b692c72d2840674db632ba2431d1df1a37d`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-arm64.tar.gz) | `842910a7013f61a60d670079716b207705750d55a9e4f1f93696d19d39e191644488170ac94d8740f8e3aa3f7f28f61a4347f69d7e93d149c69ac0efcf3688fe`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-ppc64le.tar.gz) | `95c5b952ac1c4127a5c3b519b664972ee1fb5e8e902551ce71c04e26ad44b39da727909e025614ac1158c258dc60f504b9a354c5ab7583c2ad769717b30b3836`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-server-linux-s390x.tar.gz) | `a46522d2119a0fd58074564c1fa95dd8a929a79006b82ba3c4245611da8d2db9fd785c482e1b61a9aa361c5c9a6d73387b0e15e6a7a3d84fffb3f65db3b9deeb`
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-amd64.tar.gz) | `7c268bd58e67d3c5016f3fcc9f4b6d2da7558af5a2c708ff3baf767b39e847e3d35d4fd2fa0f640bedbfb09a445036cafbe2f04357a88dada405cfc2ded76972`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-arm.tar.gz) | `fcbf8d9004f1cd244a82b685abaf81f9638c3cc1373d78e705050042cfa6a004f8eed92f4721539dcd169c55b662d10416af19cff7537a8dfef802dc41b4088b`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-arm64.tar.gz) | `e21f54a35ff29e919e98fe81758f654ea735983d5a9d08dab9484598b116843830a86ceb5cf0a23d27b7f9aba77e5f0aa107c171a0837ba781d508ebbea76f55`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-ppc64le.tar.gz) | `c7014c782683f8f612c7805654b632aab4c5dce895ee8f9ef24360616e24240ce59ddf3cf27c3170df5450d8fe14fbca3fb7cddfc9b74ae37943081f0fa4b6b3`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-server-linux-s390x.tar.gz) | `3ac2d6b273e5b650f63260aae164fc6781ad5760f63cca911f5db9652c4bf32e7e7b25728987befc6dfda89c5c56969681b75f12b17141527d4e1d12f3d41f3c`
 
 ### 노드 바이너리
 
 파일명 | sha512 해시
 -------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-amd64.tar.gz) | `f714f80feecb0756410f27efb4cf4a1b5232be0444fbecec9f25cb85a7ccccdcb5be588cddee935294f460046c0726b90f7acc52b20eeb0c46a7200cf10e351a`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm.tar.gz) | `806000b5f6d723e24e2f12d19d1b9b3d16c74b855f51c7063284adf1fcc57a96554a3384f8c05a952c6f6b929a05ed12b69151b1e620c958f74c9600f3db0fcb`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-arm64.tar.gz) | `c207e9ab60587d135897b5366af79efe9d2833f33401e469b2a4e0d74ecd2cf6bb7d1e5bc18d80737acbe37555707f63dd581ccc6304091c1d98dafdd30130b7`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-ppc64le.tar.gz) | `a542ed5ed02722af44ef12d1602f363fcd4e93cf704da2ea5d99446382485679626835a40ae2ba47a4a26dce87089516faa54479a1cfdee2229e8e35aa1c17d7`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-linux-s390x.tar.gz) | `651e0db73ee67869b2ae93cb0574168e4bd7918290fc5662a6b12b708fa628282e3f64be2b816690f5a2d0f4ff8078570f8187e65dee499a876580a7a63d1d19`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0/kubernetes-node-windows-amd64.tar.gz) | `d726ed904f9f7fe7e8831df621dc9094b87e767410a129aa675ee08417b662ddec314e165f29ecb777110fbfec0dc2893962b6c71950897ba72baaa7eb6371ed`
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-amd64.tar.gz) | `d5e21432a4ab019f00cd1a52bbbdb00feb3db2ce96b41a58b1ee27d8847c485f5d0efe13036fd1155469d6d15f5873a5a892ecc0198f1bae1bf5b586a0129e75`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-arm.tar.gz) | `bd57adf060813b06be2b33439d6f60d13630c0251ef96ba473274073200ea118f5622ec31ed714cc57bd9da410655e958a7700a5742ae7e4b6406ab12fbf21f3`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-arm64.tar.gz) | `3ee70abc0a5cbf1ef5dde0d27055f4d17084585c36a2cf41e3fd925d206df0b583f50dc1c118472f198788b65b2c447aa40ad41646b88791659d2dfb69b3890b`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-ppc64le.tar.gz) | `0f4368f229c082b2a75e7089a259e487d60b20bc8edf650dd7ca0fe23c51632397c2ef24c9c6cef078c95fce70d9229a5b4ff682c34f65a44bc4be3329c8ccde`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-linux-s390x.tar.gz) | `8f0b6839fc0ad51300221fa7f32134f8c687073715cc0839f7aacb21a075c66dab113369707d03e9e0e53be62ca2e1bdf04d4b26cff805ae9c7a5a4b864e3eae`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0/kubernetes-node-windows-amd64.tar.gz) | `587651158c9999e64e06186ef2e65fe14d46ffdae28c5d8ee6261193bfe4967717f997ebe13857fa1893bbf492e1cc1f816bce86a94c6df9b7a0264848391397`
 
-## v1.17.0 이후 체인지로그
-
-릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0)에서 사용자 정의 가능한
-형식으로 호스팅된다. 확인하고 의견을 보내주기
-바란다!
+## v1.18.0 이후 체인지로그
 
 ## 새로운 소식 (주요 테마)
 
-### 쿠버네티스 토폴로지 매니저가 베타로 전환 - 정렬!
+### 사용 중단 경고
 
-릴리스 1.18의 쿠버네티스 베타 기능인 [토폴로지 매니저 기능](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md)은 저-지연(low-latency)에 최적화된 환경에서 워크로드를 실행할 수 있도록 CPU 및 장치(예: SR-IOV VF)를 NUMA 정렬 할 수 있다. 토폴로지 매니저가 도입되기 전에, CPU와 장치 관리자는 서로 독립적으로 리소스 할당 결정을 내렸다. 이로 인해 다중-소켓 시스템에 의도하지 않은 할당이 발생하여, 지연에 민감한 애플리케이션의 성능을 저하시킬 수 있었다.
+SIG API Machinery는 `kubectl` 사용자 및 API 사용자에게 표시되는 [사용 중단된 API 사용 시 경고](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#rest-resources-aka-api-objects)와 
+클러스터 관리자에게 표시되는 메트릭을 구현하였다.
+사용 중단된 API에 대한 요청은 대상 제거 릴리스 및 대체 API를 포함하는 경고와 함께 반환된다.
+경고는 [어드미션 웹훅](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admissionreview-response-warning)에서도 
+반환될 수 있으며, [사용자 정의 리소스의 사용 중단된 버전](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#version-deprecation)에 대해 지정된다.
 
-### 서버 사이드(server-side) 적용 - 베타 2
+### 영구적인 베타(beta) 회피하기
 
-서버-사이드 적용은 1.16에서 베타로 승격되었지만, 1.18에서 두 번째 베타가 도입된다. 이 새 버전은 모든 새로운 쿠버네티스 오브젝트의 필드 변경 사항을 추적하고 관리하여, 리소스의 변경된 부분과 시기를 알 수 있다.
+쿠버네티스 1.20에서부터, SIG Architecture는 9개월 이내에 모든 REST API들을 베타에서 안정 버전으로 전환하는 새로운 정책을 구현한다. 새로운 정책의 이면에 있는 아이디어는 기능이 오랫동안 베타 상태로 유지되는 것을 피하기 위함이다. 일단 새로운 API가 베타 단계에 진입하면, 9개월 동안 다음 중 하나를 수행하게 된다.
 
-### 인그레스 확장 및 IngressClass로 사용 중단(deprecated) 어노테이션을 교체
+ - GA에 도달하여, 베타 지원 중단 혹은
+ - 새로운 베타 버전을 보유 _(및 이전 베타 지원 중단)_.
 
-쿠버네티스 1.18에서 인그레스에 두 가지 중요한 추가 사항이 있는데, 그것은 새로운 `pathType` 필드와 새로운 `IngressClass` 리소스이다. `pathType` 필드는 경로(path)를 일치시키는 방법을 지정한다. 기본 `ImplementationSpecific` 유형 외에도 새로운 `Exact` 와 `Prefix` 경로 유형이 있다.
+REST API가 9개월의 카운트 다운이 끝나면, 다음 쿠버네티스 릴리스에서 해당 API 버전이 사용 중단된다. 더 자세한 내용은 [쿠버네티스 블로그](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/)에서 확인할 수 있다.
 
-`IngressClass` 리소스는 쿠버네티스 클러스터 내에서 인그레스 유형을 설명하는 데 사용된다. 인그레스는 인그레스에서 새로운 `ingressClassName` 필드를 사용하여 연관된 클래스를 지정할 수 있다. 이 새 리소스와 필드는 사용 중단된 `kubernetes.io/ingress.class` 어노테이션을 대체한다.
+### 워크로드 및 노드 디버깅을 위한 확장된 CLI 지원
 
-### SIG CLI의 kubectl 디버그 소개
+SIG CLI는 `kubectl` 로 디버깅을 확장하여, 다음의 두 가지 새로운 디버깅 워크플로(workflows)를 지원한다. 복사본을 생성하여 워크로드를 디버깅하고, 호스트 네임스페이스에 컨테이너를 생성하여 노드를 디버깅한다. 이는 아래의 작업을 할 때 유용하다.
+ - 임시(Ephemeral) 컨테이너가 활성화되지 않은 클러스터에서 디버그 컨테이너 삽입
+ - busybox와 같은 이미지나 `sleep 1d` 와 같은 명령어를 변경하여 쉽게 디버깅할 수 있도록, 손상된 컨테이너를 수정하여 `kubectl exec` 를 사용할 수 있는 시간 확보
+ - 노드의 호스트 파일시스템에서 구성 파일 검사
 
-SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다.
+이러한 새로운 워크플로에는 신규 클러스터 기능이 필요하지 않으므로, `kubectl alpha debug` 를 통해 기존 클러스터로 테스트할 수 있다. `kubectl` 을 사용한 디버깅에 대해 사용자의 의견을 기대한다. 이슈를 열거나, [#sig-cli](https://kubernetes.slack.com/messages/sig-cli)를 방문하거나 기능 개선에 대한 이슈 [#1441](https://features.k8s.io/1441)에 코멘트를 남겨서 SIG CLI와 연락할 수 있다.
 
-### 쿠버네티스를 위한 윈도우 CSI 지원 알파 소개
+### 구조화된 로깅
 
-쿠버네티스 1.18 릴리스에서는 윈도우 용 CSI 프록시(CSI Proxy)의 알파 버전이 릴리스 된다. CSI 프록시를 사용하면 권한이 없는(사전 승인된) 컨테이너가 윈도우에서 권한이 있는 스토리지 작업을 수행할 수 있다. CSI 프록시를 활용하여 윈도우에서 CSI 드라이버를 지원할 수 있다.
-SIG 스토리지는 1.18 릴리스에서 많은 진전을 이루었다.
-특히, 다음 스토리지 기능이 쿠버네티스 1.18에서 GA 되었다.
-- 원시(Raw) 블록 지원: 볼륨을 마운트된 파일시스템 대신, 컨테이너 내에 블록 장치로 표시할 수 있다.
-- 볼륨 복제: CSI를 통해 쿠버네티스 API를 사용하여 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 및 기본 스토리지 볼륨을 복제한다.
-- CSIDriver 쿠버네티스 API 오브젝트: CSI 드라이버 검색을 단순화하고 CSI 드라이버가 쿠버네티스 동작을 사용자 정의할 수 있게 한다.
+SIG Instrumentation은 로그 메시지의 구조와 쿠버네티스 오브젝트에 대한 참조를 표준화했다. 구조화된 로깅을 사용하면 로그를 더 쉽게 구문 분석, 처리, 저장, 질의 및 분석할 수 있다. klog 라이브러리의 새 메소드는 로그 메시지 구조를 강제 적용한다.
 
-SIG 스토리지는 쿠버네티스 1.18에서 다음과 같은 새로운 스토리지 기능을 알파로 도입했다.
-- 윈도우 CSI 지원: 새로운 [CSIProxy](https://github.com/kubernetes-csi/csi-proxy)를 통해 윈도우에서 컨테이너화 된 CSI 노드 플러그인 활성화한다.
-- 재귀 볼륨 소유권 OnRootMismatch 옵션: 소유권 변경이 필요하고 많은 디렉터리와 파일이 있는 볼륨의 마운트 시간을 단축할 수 있는 새로운 “OnRootMismatch” 정책을 추가한다.
+### 엔드포인트슬라이스(EndpointSlices)가 기본적으로 활성화
 
-### 다른 중요한 발표
+엔드포인트슬라이스는 엔드포인트(EndPoint) API에 대한 스케일 및 확장 가능한 대안을 제공하는 훌륭한 신규 API이다. 엔드포인트슬라이스는 서비스를 지원하는 파드에 대한 IP 주소, 포트, 준비성 게이트(readiness gate) 상태 및 토폴로지 정보를 추적한다.
 
-새로운 CI 작업으로 테스트 커버리지를 크게 늘린 이후, SIG 네트워크는 쿠버네티스 1.18에서 IPv6를 베타로 전환한다.
+쿠버네티스 1.19에서 이 기능은, 엔드포인트 대신 엔드포인트슬라이스에서 읽는 kube-proxy와 함께 기본적으로 활성화된다. 이는 대부분 눈에 띄지 않는 변경이지만, 대규모 클러스터에서는 눈에 띄게 확장성이 향상된다. 또한 토폴로지 인식 라우팅과 같은 향후 쿠버네티스 릴리스에서 중요한 신규 기능을 사용할 수 있다.
 
-NodeLocal DNSCache는 dnsCache 파드를 데몬셋으로 실행하여 clusterDNS 성능과 안정성을 향상시키는 애드온이다. 이 기능은 1.13 릴리스 이후 알파 버전으로 존재해왔다. SIG 네트워크는 Node Local DNSCache [#1351](https://github.com/kubernetes/enhancements/pull/1351)의 GA를 발표한다.
+### 인그레스(ingress)를 안정 기능(General Availability)으로 전환
+
+SIG Network는 널리 사용되고 있는 [인그레스 API](https://kubernetes.io/ko/docs/concepts/services-networking/ingress/)를 쿠버네티스 1.19의 안정 기능으로 전환했다. 이 변경은 쿠버네티스 기여자들의 수 년간의 노력을 인정하고, 쿠버네티스의 향후 네트워킹 API에 대한 추가 작업을 위한 기반을 마련한다.
+
+### seccomp를 안정 기능으로 전환
+
+쿠버네티스에 대한 seccomp(보안 컴퓨팅 모드) 지원이 안정 기능(GA)로 전환되었다. 이 기능은 파드(모든 컨테이너에 적용) 또는 단일 컨테이너에 대한 시스템 호출을 제한하여 워크로드 보안을 강화하는 데 사용될 수 있다.
+
+기술적으로 이것은 일급 객체(first class)인 `seccompProfile` 필드가 파드 및 컨테이너 `securityContext` 오브젝트에 추가되었음을 의미한다.
+
+```yaml
+securityContext:
+  seccompProfile:
+    type: RuntimeDefault|Localhost|Unconfined # 셋 중 하나를 선택
+    localhostProfile: my-profiles/profile-allow.json # type == Localhost 일때만 필요
+```
+
+`seccomp.security.alpha.kubernetes.io/pod` 및 `container.seccomp.security.alpha.kubernetes.io/...` 어노테이션에 대한 지원은 이제 사용 중단되었으며, 쿠버네티스 v1.22.0에서 제거된다. 현재 자동 버전 차이(skew)에 대한 처리는 새로운 필드를 어노테이션으로 변환하며 그 반대의 경우도 동일하게 동작한다. 즉, 클러스터의 기존 워크로드를 변환하는데 별도의 조치가 필요하지 않다.
+
+새로운 [Kubernetes.io의 문서 페이지][seccomp-docs]에서 seccomp로 컨테이너 시스템 호출을 제한하는 방법에 대한 자세한 정보를 찾을 수 있다.
+
+[seccomp-docs]: https://kubernetes.io/docs/tutorials/clusters/seccomp/
+
+
+### 운영용 이미지가 커뮤니티 제어로 이동
+
+쿠버네티스 v1.19부터 쿠버네티스 컨테이너 이미지는 `{asia,eu,us}.gcr.io/k8s-artifacts-prod` 에 있는 
+커뮤니티 제어 기반의 스토리지 버킷에 저장된다. `k8s.gcr.io` 가상 도메인(vanity domain)이 새 버킷으로 
+업데이트되었다. 이는 커뮤니티 제어 하에 운영 아티팩트(production artifacts)를 가져온다.
+
+### KubeSchedulerConfiguration를 베타로 전환
+
+SIG Scheduling은 `KubeSchedulerConfiguration` 를 베타로 전환했다. [KubeSchedulerConfiguration](https://kubernetes.io/docs/reference/scheduling/config) 기능을 사용하면 kube-scheduler의 알고리즘 및 기타 설정을 조정할 수 있다. 남은 구성을 다시 작성하지 않고도, 선택한 일정 단계에서 특정 기능(플러그인에 포함된)을 쉽게 활성화하거나 비활성화할 수 있다. 또한 단일 kube-scheduler 인스턴스는 프로파일이라고 불리는 다양한 구성을 제공한다. 파드는 `.spec.schedulerName` 필드를 통해 스케줄링하려는 프로파일을 선택할 수 있다.
+
+### CSI 마이그레이션 - AzureDisk 및 vSphere (베타)
+ 
+인-트리(In-tree) 볼륨 플러그인 및 모든 클라우드 공급자의 의존성이 쿠버네티스 코어 밖으로 이동된다. CSI 마이그레이션 기능을 사용하면 모든 볼륨 작업을 해당 CSI 드라이버로 라우팅하여 코드가 제거된 경우에도 레거시 API를 사용하는 기존 볼륨이 계속 동작할 수 있다. 이 기능의 AzureDisk 및 vSphere 구현이 베타로 승격되었다.
+
+### 스토리지 용량 추적
+
+전통적으로 쿠버네티스 스케줄러는 추가 퍼시스턴트 스토리지가 클러스터의 모든 곳에서 사용할 수 있고 그 용량이 무한하다고 가정했다. 토폴로지 제약 사항은 첫 번째 요점을 다루었지만, 남은 스토리지 용량이 새 파드를 시작하기에 충분하지 않을 수 있다는 점을 고려하지 않은 채로 파드 스케줄링이 수행되었다. 새로운 알파(alpha) 기능인 [스토리지 용량 추적](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking)은 CSI 드라이버에 API를 추가하여, 스토리지 용량을 전달하고 파드의 노드를 선택할 때 쿠버네티스 스케줄러에서 해당 정보를 사용한다. 이 기능은 용량이 더 제한된 로컬 볼륨 및 기타 볼륨 유형에 대한 동적 프로비저닝을 지원하기 위한 디딤돌 역할이다.
+
+### CSI 볼륨 상태 모니터링
+
+CSI 상태 모니터링의 알파 버전은 쿠버네티스 1.19와 함께 릴리스된다. 이 기능을 사용하면 CSI 드라이버가 기본 스토리지 시스템의 비정상적인 볼륨 조건을 쿠버네티스와 공유하여 PVC 또는 파드의 이벤트를 전달할 수 있다. 이 기능은 쿠버네티스 개별 볼륨 상태 문제를 프로그래밍 방식으로 감지하고 해결하기 위한 디딤돌 역할이다.
+
+### 일반적인 임시 볼륨
+
+쿠버네티스는 라이프사이클이 파드에 연결되어 있고 스크래치 공간(예: 기본 제공되는 "empty dir" 볼륨 타입)으로 사용되거나 일부 데이터를 파드에 로드(예: 기본 제공되는 컨피그맵(ConfigMap) 및 시크릿(Secret) 볼륨 유형 또는 "CSI 인라인 볼륨")할 수 있는 볼륨 플러그인을 제공한다. 새로운 [일반적인 임시 볼륨](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1698-generic-ephemeral-volumes) 알파 기능은 동적 프로비저닝을 지원하는 기존 스토리지 드라이버를 볼륨의 라이프사이클이 포함된 파드에 바인딩된 임시 볼륨으로 사용한다.
+ - 예를 들어 퍼시스턴트 메모리나 해당 노드의 별도 로컬 디스크와 같은, 루트 디스크와는 다른 스크래치 스토리지를 제공하는데 사용
+ - 볼륨 프로비저닝을 위한 모든 스토리지클래스(StorageClass) 파라미터 지원
+ - 스토리지 용량 추적, 스냅샷 및 복원, 볼륨 크기 조정과 같이 퍼시스턴트볼륨클레임(PersistentVolumeClaim)에서 지원하는 모든 기능을 지원
+
+### 변경할 수 없는(immutable) 시크릿 및 컨피그맵 (베타)
+
+시크릿 및 컨피그맵 볼륨은 immutable로 표시될 수 있으므로, 클러스터에 시크릿 및 컨피그맵 볼륨이 많은 경우 API 서버의 로드가 크게 줄어든다.
+자세한 내용은 [컨피그맵](https://kubernetes.io/ko/docs/concepts/configuration/configmap/) 및 [시크릿](https://kubernetes.io/ko/docs/concepts/configuration/secret/)을 참고한다.
+
+### 윈도우에 대한 CSI 프록시
+
+윈도우용 CSI 프록시는 1.19 릴리스와 함께 베타로 승격되었다. 이 CSI 프록시를 사용하면 윈도우의 컨테이너가 권한 있는 스토리지 작업을 수행할 수 있도록 CSI 드라이버를 윈도우에서 실행할 수 있다. 베타에서 윈도우용 CSI 프록시는 직접 연결된 디스크 및 SMB를 사용하는 스토리지 드라이버를 지원한다.
+
+### 대시보드 v2
+
+SIG UI는 쿠버네티스 대시보드 애드온 v2를 릴리스했다. [쿠버네티스/대시보드](https://github.com/kubernetes/dashboard/releases) 리포지터리에서 최신 릴리스를 찾을 수 있다. 쿠버네티스 대시보드에는 이제 CRD 지원, 새로운 번역 및 AngularJS의 업데이트된 버전이 포함된다.
+
+### 윈도우 컨테이너 지원을 베타로 전환
+
+쿠버네티스 1.18에서 처음 도입된 윈도우 컨테이너 지원이 이번 릴리스에서 베타로 전환된다. 여기에는 윈도우 서버 버전 2004에 대한 추가 지원이 포함된다(전체 버전 호환성은 [윈도우용 문서](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd)에서 찾을 수 있다).
+
+SIG Windows는 이번 릴리스에 대한 몇 가지 추가 사항도 포함한다.
+ - DSR(Direct Server Return) 모드 지원으로 많은 서비스를 효율적으로 확장 가능
+ - 윈도우 컨테이너가 CPU 한계를 준수
+ - 메트릭 및 요약 모음에 대한 성능 개선
+
+### 쿠버네티스 지원 기간을 1년으로 늘림
+
+쿠버네티스 1.19부터, 쿠버네티스 마이너(minor) 릴리스에 대한 패치 릴리스를 통한 버그 수정 지원이 9개월에서 1년으로 늘었다.
+
+2019년 초에 워킹그룹(WG) 장기 지원(LTS)에서 실시한 설문 조사에 따르면 쿠버네티스 최종 사용자의 상당 부분이 이전 9개월 지원 기간 내에 업그레이드에 실패한 것으로 보인다.
+연간 지원 기간은 최종 사용자가 원하는 대로 '추가적인 기간(쿠션)'을 제공하며, 이러한 방식을 통해 연간 계획 주기와도 더 적절하게 어울린다. 
 
 ## 알려진 이슈
 
-알려진 이슈가 보고되지 않음
+새로운 스토리지 용량 추적 알파 기능은 WaitForFirstConsumer 볼륨 바인딩 모드 제한의 영향을 받는 것으로 알려져 있다. [#94217](https://github.com/kubernetes/kubernetes/issues/94217)
 
 ## 긴급 업그레이드 노트
 
-### (업그레이드하기 전에 반드시 읽어야 한다)
-
-#### kube-apiserver:
-- `--encryption-provider-config` 설정 파일에서, 명시적인 `cacheSize: 0` 파라미터는 이전에는 묵시적으로 1000개의 키를 캐싱하도록 기본으로 설정되었다. 쿠버네티스 1.18에서 이것은 이제 설정 유효성 검사 오류를 반환한다. 캐싱을 비활성화하려면 쿠버네티스 1.18 이상에서 음의 cacheSize 값을 지정할 수 있다.
-- 'certificatesigningrequests/approval' API 사용자는 이제 CSR이 요청한 특정 서명자(signer)에 대해 CSR을 '승인'할 권한이 있어야 한다. 새 signerName 필드 및 필수 권한 부여에 대한 자세한 정보는 https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests#authorization ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, 앱, 인증, CLI, 노드 및 테스트] 에서 확인할 수 있다.
-- 다음 기능은 무조건 활성화되며, 다음의 `--feature-gates`의 플래그가 제거되었다. `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` 및 `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness)) [SIG 앱과 스케줄]
-
-#### kubelet:
-- `--enable-cadvisor-endpoints` 는 이제 기본적으로 비활성화되어 있다. cAdvisor v1 Json API에 접근해야 하는 경우, kubelet 커맨드 라인에서 명시적으로 활성화한다. 이 플래그는 1.15에서 사용 중단되었으며 1.19에서 제거될 것이다. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, 노드 및 테스트]
-- CSIMigrationOpenStack을 베타로 승격한다(OpenStack Cinder CSI 드라이버를 설치해야 하므로 기본적으로 해제되어 있다). 인-트리(in-tree) AWS OpenStack Cinder 드라이버 "kubernetes.io/cinder"는 1.16에서 사용 중단되었으며, 1.20에서 제거될 것이다. 사용자는 CSIMigration + CSIMigrationOpenStack 기능을 활성화하고 OpenStack Cinder CSI 드라이버 (https://github.com/kubernetes-sigs/cloud-provider-openstack)를 설치하여 기존 파드와 PVC 오브젝트가 중단되지 않도록 해야한다. 사용자는 새 볼륨에 대해 OpenStack Cinder CSI 드라이버를 직접 사용해야 한다. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG 클라우드 공급자]
-
-#### kubectl:
-- `kubectl` 및 k8s.io/client-go의 기본값은 더 이상 `http://localhost:8080`의 서버 주소가 아니다. 이러한 레거시 클러스터 중 하나를 소유한 경우, 서버를 안전하게 보호하는 것을 *강력히* 권장한다. 서버를 보호할 수 없다면, `$KUBERNETES_MASTER` 환경 변수를 `http://localhost:8080`으로 설정하여 서버 주소의 기본값을 계속 유지할 수 있다. `kubectl` 사용자는 `--server` 플래그를 사용하거나 `--kubeconfig` 또는 `$KUBECONFIG`를 통해 지정된 kubeconfig 파일에서 서버 주소를 설정할 수도 있다. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI 및 테스트]
-- `kubectl run`은 파드 생성과 관련이 없는 플래그와 함께, 이전에 사용 중단된 생성기(generator)를 삭제했다. `kubectl run`은 이제 파드만 생성한다. 파드 이외의 오브젝트를 만드려면, 특정 `kubectl create` 하위 커맨드를 참조한다.
-([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, CLI 및 테스트]
-- 사용 중단된 커맨드 `kubectl rolling-update`는 삭제되었다. ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG 아키텍처, CLI 및 테스트]
-
-#### client-go:
-- 생성된 클라이언트 세트, 동적, 메타데이터 및 스케일 클라이언트의 메소드에 대한 서명이 `context.Context`를 첫 번째 인수로 채택하도록 수정되었다. Create, Update 및 Patch 메소드의 서명이 각각 CreateOptions, UpdateOptions 및 PatchOptions를 허용하도록 업데이트되었다. Delete 및 DeleteCollection 메소드의 서명은 이제 참조 대신 값으로 DeleteOptions를 허용한다. 이전 인터페이스를 사용하여 생성된 클라이언트 세트가 새로운 "사용 중단된" 패키지에 추가되어 새로운 API로 증분(incremental) 마이그레이션 할 수 있다. 사용 중단된 패키지는 1.21 릴리스에서 제거된다. http://sigs.k8s.io/clientgofix 에서 도구를 사용하여 새로운 서명에 대한 메소드 호출을 다시 쓸 수 있다.
-
-- 다음의 사용 중단된 메트릭이 제거되었다. 해당 메트릭으로 변환한다.
-  - 다음 교체 메트릭은 v1.14.0부터 제공된다.
-      - `rest_client_request_latency_seconds` -> `rest_client_request_duration_seconds`
-      - `scheduler_scheduling_latency_seconds` -> `scheduler_scheduling_duration_seconds `
-      - `docker_operations` -> `docker_operations_total`
-      - `docker_operations_latency_microseconds` -> `docker_operations_duration_seconds`
-      - `docker_operations_errors` -> `docker_operations_errors_total`
-      - `docker_operations_timeout` -> `docker_operations_timeout_total`
-      - `network_plugin_operations_latency_microseconds` -> `network_plugin_operations_duration_seconds`
-      - `kubelet_pod_worker_latency_microseconds` -> `kubelet_pod_worker_duration_seconds`
-      - `kubelet_pod_start_latency_microseconds` -> `kubelet_pod_start_duration_seconds`
-      - `kubelet_cgroup_manager_latency_microseconds` -> `kubelet_cgroup_manager_duration_seconds`
-      - `kubelet_pod_worker_start_latency_microseconds` -> `kubelet_pod_worker_start_duration_seconds`
-      - `kubelet_pleg_relist_latency_microseconds` -> `kubelet_pleg_relist_duration_seconds`
-      - `kubelet_pleg_relist_interval_microseconds` -> `kubelet_pleg_relist_interval_seconds`
-      - `kubelet_eviction_stats_age_microseconds` -> `kubelet_eviction_stats_age_seconds`
-      - `kubelet_runtime_operations` -> `kubelet_runtime_operations_total`
-      - `kubelet_runtime_operations_latency_microseconds` -> `kubelet_runtime_operations_duration_seconds`
-      - `kubelet_runtime_operations_errors` -> `kubelet_runtime_operations_errors_total`
-      - `kubelet_device_plugin_registration_count` -> `kubelet_device_plugin_registration_total`
-      - `kubelet_device_plugin_alloc_latency_microseconds` -> `kubelet_device_plugin_alloc_duration_seconds`
-      - `scheduler_e2e_scheduling_latency_microseconds` -> `scheduler_e2e_scheduling_duration_seconds`
-      - `scheduler_scheduling_algorithm_latency_microseconds` -> `scheduler_scheduling_algorithm_duration_seconds`
-      - `scheduler_scheduling_algorithm_predicate_evaluation` -> `scheduler_scheduling_algorithm_predicate_evaluation_seconds`
-      - `scheduler_scheduling_algorithm_priority_evaluation` -> `scheduler_scheduling_algorithm_priority_evaluation_seconds`
-      - `scheduler_scheduling_algorithm_preemption_evaluation` -> `scheduler_scheduling_algorithm_preemption_evaluation_seconds`
-      - `scheduler_binding_latency_microseconds` -> `scheduler_binding_duration_seconds`
-      - `kubeproxy_sync_proxy_rules_latency_microseconds` -> `kubeproxy_sync_proxy_rules_duration_seconds`
-      - `apiserver_request_latencies` -> `apiserver_request_duration_seconds`
-      - `apiserver_dropped_requests` -> `apiserver_dropped_requests_total`
-      - `etcd_request_latencies_summary` -> `etcd_request_duration_seconds`
-      - `apiserver_storage_transformation_latencies_microseconds ` -> `apiserver_storage_transformation_duration_seconds`
-      - `apiserver_storage_data_key_generation_latencies_microseconds` -> `apiserver_storage_data_key_generation_duration_seconds`
-      - `apiserver_request_count` -> `apiserver_request_total`
-      - `apiserver_request_latencies_summary`
-  - 다음 교체 메트릭은 v1.15.0부터 제공된다.
-      - `apiserver_storage_transformation_failures_total` -> `apiserver_storage_transformation_operations_total` ([#76496](https://github.com/kubernetes/kubernetes/pull/76496), [@danielqsj](https://github.com/danielqsj)) [SIG API Machinery, 클러스터 라이프사이클, Instrumentation, 네트워크, 노드 및 스케줄링]
+### (업그레이드 전에 반드시 읽어야 함)
 
+- 조치 필요: 코어 마스터 기본 이미지(kube-controller-manager)를 debian에서 distroless로 전환한다. 스크립트를 사용하여 Flex 볼륨 지원이 필요한 경우 필요한 패키지(bash와 같은)로 자체 이미지를 빌드하라. ([#91329](https://github.com/kubernetes/kubernetes/pull/91329), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release, Storage 및 Testing]
+- 조치 필요: --basic-auth-file 플래그를 통한 기본 인증 지원이 제거되었다. 사용자는 유사한 기능을 위해 --token-auth-file 플래그로 마이그레이션해야 한다. ([#89069](https://github.com/kubernetes/kubernetes/pull/89069), [@enj](https://github.com/enj)) [SIG API Machinery]
+ - Azure blob 디스크 기능(`kind`: `Shared`, `Dedicated`)이 더 이상 사용되지 않는다. `kubernetes.io/azure-disk` 스토리지 클래스에 있는 `kind`: `Managed` 를 사용해야 한다. ([#92905](https://github.com/kubernetes/kubernetes/pull/92905), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+ - CVE-2020-8559(Medium): 손상된 노드에서 클러스터로 권한 상승. 자세한 내용은 https://github.com/kubernetes/kubernetes/issues/92914 를 참고한다.
+  API 서버는 더이상 업그레이드 요청에 대해 101이 아닌 응답을 프록시하지 않는다. 이로 인해 101이 아닌 응답 코드로 업그레이드 요청에 응답하는 프록시된 백엔드(확장 API 서버와 같은)가 손상될 수 있다. ([#92941](https://github.com/kubernetes/kubernetes/pull/92941), [@tallclair](https://github.com/tallclair)) [SIG API Machinery]
+ - Kubeadm은 /var/lib/kubelet/kubeadm-flags.env에서 사용 중단된 '--cgroup-driver' 플래그를 설정하지 않으며, kubelet의 config.yaml 파일에 설정한다. /var/lib/kubelet/kubeadm-flags.env 파일이나 /etc/default/kubelet 파일에 (RPM의 경우 /etc/sysconfig/kubelet) 이 플래그가 있는 경우 제거 후에 KubeletConfiguration을 사용하여 값을 지정해야 한다. ([#90513](https://github.com/kubernetes/kubernetes/pull/90513), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+ - Kubeadm은 이제 ClusterConfiguration에서 사용자가 지정한 etcd 버전을 준수하고 올바르게 사용한다. 사용자가 ClusterConfiguration에 지정된 버전을 유지하지 않으려면, kubeadm-config 컨피그맵을 편집하고 삭제해야 한다. ([#89588](https://github.com/kubernetes/kubernetes/pull/89588), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+ - Kubeadm은 systemd-resolved 서비스가 활성화된 경우에도 사용자가 설정한 resolvConfg 값을 따른다. kubeadm은 더이상 /var/lib/kubelet/kubeadm-flags.env 파일에 있는 '--resolv-conf' 플래그를 설정하지 않는다. /var/lib/kubelet/kubeadm-flags.env 파일이나 /etc/default/kubelet 파일에(RPM의 경우 /etc/sysconfig/kubelet) 이 플래그가 있는 경우 제거 후에 KubeletConfiguration을 사용하여 값을 지정해야 한다. ([#90394](https://github.com/kubernetes/kubernetes/pull/90394), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+ - Kubeadm: "kubeadm init 단계: kubelet-start"가 "kubeconfig" 단계 이후인, 초기화 워크 플로의 후반부로 이동한다. 이렇게 하면 kubeadm이 KubeletConfiguration 구성 설정 파일이 생성된 후에만 kubelet을 시작하고, OpenRC와 같은 초기화 시스템이 kubelet 서비스를 크래시루프(crashloop)할 수 없는 문제가 해결된다.
+ - 'kubeadm config upload' 명령어는 전체 GA 사용 중단 주기 후에 최종적으로 제거되었다. 만약 그래도 사용해야 할 경우, 대안으로 'kubeadm init phase upload-config'를 사용한다. ([#92610](https://github.com/kubernetes/kubernetes/pull/92610), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+ - kubescheduler.config.k8s.io/v1alpha2를 kubescheduler.config.k8s.io/v1beta1로 업그레이드
+  
+   - `.bindTimeoutSeconds` 가 `VolumeBinding` 에 대한 플러그인 인수의 일부로 이동되었으며,
+     [프로파일](&#35;profiles)별로 별도 구성할 수 있다.
+   - `.extenders` 가 API 표준을 충족하도록 업데이트되었다. 다음을 참고한다.
+     - `.extenders` 디코딩은 대소문자를 구분한다. 모든 필드가 영향을 받는다.
+     - `.extenders[*].httpTimeout` 은 `metav1.Duration` 유형이다.
+     - `.extenders[*].enableHttps` 가 `.extenders[*].enableHTTPS` 로 이름이 변경되었다.
+   - `RequestedToCapacityRatio` 인수 디코딩은 대소문자를 구분한다. 모든 필드가 영향을 받는다.
+   - `DefaultPodTopologySpread` [플러그인](&#35;scheduling-plugins)이 `SelectorSpread` 로 이름이 변경되었다.
+   - `Unreserve` 익스텐션 포인트가 프로파일 정의에서 제거되었다. 모든 `Reserve`
+     플러그인은 `Unreserve` 호출을 구현한다.
+   - `.disablePreemption` 이 제거되었다. 사용자는 "DefaultPreemption" PostFilter 플러그인을
+     비활성화하여 선점에 대해 비활성화할 수 있다. ([#91420](https://github.com/kubernetes/kubernetes/pull/91420), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
+ 
 ## 종류(Kind)별 변경
 
 ### 사용 중단
 
-#### kube-apiserver:
-- 다음의 사용 중단된 API는 더 이상 제공되지 않는다.
-  - `apps/v1beta1`와 `apps/v1beta2`의 모든 리소스 대신 `apps/v1`을 사용한다.
-  - `extensions/v1beta1`의 `daemonsets`, `deployments`, `replicasets` 리소스 대신 `apps/v1`을 사용한다.
-  - `extensions/v1beta1`의 `networkpolicies` 리소스 대신 `networking.k8s.io/v1`을 사용한다.
-  - `extensions/v1beta1`의 `podsecuritypolicies`의 리소스 대신 `policy/v1beta1`을 사용한다. ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 앱, 클러스터 라이프사이클, Instrumentation 및 테스트]
+- vSphere CSI 드라이버로의 vSphere 인-트리 볼륨 마이그레이션에 대한 지원이 추가되었다. 인-트리 vSphere 볼륨 플러그인은 더이상 사용되지 않으며, 향후 릴리스에서 제거된다.
+  
+  vSphere에 쿠버네티스를 자체 배포하는 사용자는 CSIMigration + CSIMigrationSphere 기능을 활성화하고 vSphere CSI 드라이버(https://github.com/kubernetes-sigs/vsphere-csi-driver)를 설치하여 기존 파드 및 PVC 오브젝트에 대한 중단을 방지해야 한다. 사용자는 새 볼륨에 대해 vSphere CSI 드라이버를 직접 사용하기 시작해야 한다.
+  
+  vSphere 볼륨용 CSI 마이그레이션 기능을 사용하려면 최소 vSphere vCenter/ESXi 버전이 7.0u1이고 최소 HW 버전이 VM 버전 15여야 한다.
+  
+  vSAN 원시 정책 파라미터는 인-트리 vSphere 볼륨 플러그인에서 더이상 사용되지 않으며 향후 릴리스에서 제거될 예정이다. ([#90911](https://github.com/kubernetes/kubernetes/pull/90911), [@divyenpatel](https://github.com/divyenpatel)) [SIG API Machinery, Node 및 Storage]
+- Apiextensions.k8s.io/v1beta1은 사용 중단되었으며, apiextensions.k8s.io/v1을 사용한다. ([#90673](https://github.com/kubernetes/kubernetes/pull/90673), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Apiregistration.k8s.io/v1beta1은 사용 중단되었으며, apiregistration.k8s.io/v1을 사용한다. ([#90672](https://github.com/kubernetes/kubernetes/pull/90672), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Authentication.k8s.io/v1beta1 및 authorization.k8s.io/v1beta1은 1.19에서 사용 중단되었으며, v1 level을 사용하고, 1.22에서 제거될 예정이다. ([#90458](https://github.com/kubernetes/kubernetes/pull/90458), [@deads2k](https://github.com/deads2k)) [SIG API Machinery 및 Auth]
+- Autoscaling/v2beta1은 사용 중단되었으며, autoscaling/v2beta2를 사용한다. ([#90463](https://github.com/kubernetes/kubernetes/pull/90463), [@deads2k](https://github.com/deads2k)) [SIG Autoscaling]
+- Coordination.k8s.io/v1beta1은 1.19에서 사용 중단되어, 1.22에서 제거될 예정이며, 대신 v1을 사용한다. ([#90559](https://github.com/kubernetes/kubernetes/pull/90559), [@deads2k](https://github.com/deads2k)) [SIG Scalability]
+- nodeExpansion CSI 호출에 볼륨 기능 및 스테이징 대상 필드가 있는지 확인해야 한다.
 
-#### kube-controller-manager:
-- Azure 서비스 어노테이션 service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset은 사용 중단되었다. 향후 릴리스에서는 지원이 제거될 것이다. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-
-#### kubelet:
-- StreamingProxyRedirects 기능과 `--redirect-container-streaming` 플래그는 사용 중단되었으며, 향후 릴리스에서 제거될 예정이다. 디폴트 동작 (kubelet을 통한 프록시 스트리밍 요청)이 유일하게 지원되는 옵션이다. `--redirect-container-streaming=true`로 설정하는 경우, 이 설정으로부터 마이그레이션 해야 한다. v1.20부터는 이 플래그를 더 이상 사용할 수 없다. 플래그를 설정하지 않으면, 아무것도 할 필요가 없다. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery와 노드]
-- `/metrics/resource/v1alpha1` 리소스 메트릭 엔드포인트와 이 엔드포인트 이하 모든 메트릭은 사용 중단되었다. `/metrics/resource` 엔드포인트에서 생성된 다음의 메트릭으로 변환해야 한다.
-      - scrape_error --> scrape_error
-      - node_cpu_usage_seconds_total --> node_cpu_usage_seconds
-      - node_memory_working_set_bytes --> node_memory_working_set_bytes
-      - container_cpu_usage_seconds_total --> container_cpu_usage_seconds
-      - container_memory_working_set_bytes --> container_memory_working_set_bytes
-      - scrape_error --> scrape_error
-      ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango)) [SIG 노드]
-- 향후 릴리스에서, kubelet은 CSI 명세에 따라 더 이상 CSI NodePublishVolume 대상 디렉터리를 만들지 않는다. 대상 경로를 적절하게 생성하고 처리하려면 CSI 드라이버를 상황에 맞게 업데이트해야 한다. ([#75535](https://github.com/kubernetes/kubernetes/issues/75535)) [SIG 스토리지]
-
-#### kube-proxy:
-- `--healthz-port`와 `--metrics-port` 플래그는 사용 중단되었으므로, 대신 `--healthz-bind-address`와 `--metrics-bind-address`를 사용한다. ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG 네트워크]
-- kube-proxy에서 엔드포인트슬라이스(EndpointSlice)의 사용을 제어하기 위해 새로운 `EndpointSliceProxying` 기능 게이트가 추가되었다. 이 동작을 제어하는데 사용된 엔드포인트슬라이스 기능 게이트는 더 이상 kube-proxy에 영향을 미치지 않는다. 이 기능은 기본적으로 비활성화되어 있다. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
-
-#### kubeadm:
-- `kubeadm upgrade node`에 대한 커맨드 라인 옵션 "kubelet-version"은 사용 중단되었으며 향후 릴리스에서 제거될 예정이다. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- `kubeadm alpha certs renew` 커맨드에서 실험용 플래그 `--use-api`의 사용을 중단한다. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- kube-dns는 사용 중단되었으며 향후 버전에서 지원되지 않는다. ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- kubeadm-config 컨피그맵(ConfigMap)에 있는 `ClusterStatus` 구조체는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. 제거될 때까지 kubeadm에 의해 유지 관리된다. 동일 정보는 `etcd`, `kube-apiserver` 파드 어노테이션, `kubeadm.kubernetes.io/etcd.advertise-client-urls`, `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint`에서 각각 찾을 수 있다. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG 클러스터 라이프사이클]
-
-#### kubectl:
-- --dry-run 플래그의 boolean 값과 설정되지 않은 값은 사용 중단되었으며 이후 버전에서는 --dry-run=server|client|none 값이 필요하다. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-- `kubectl apply --server-dry-run` 은 사용 중단되었으며 --dry-run=server로 대체되었다. ([# 87580] (https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto) [SIG CLI]
-
-#### add-ons:
-- 클러스터-모니터링 애드온을 제거한다. ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius)) [SIG 클러스터 라이프사이클, Instrumentation, 확장성, 테스트]
-
-#### kube-scheduler:
-- `scheduling_duration_seconds` 요약 메트릭은 사용 중단되었다. ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG 스케줄링]
-- `scheduling_algorithm_predicate_evaluation_seconds`,
- `scheduling_algorithm_priority_evaluation_seconds` 메트릭은 사용 중단되었으며, `framework_extension_point_duration_seconds[extension_point="Filter"]`, `framework_extension_point_duration_seconds[extension_point="Score"]`으로 대체되었다. ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei)) [SIG 스케줄링]
-- 스케줄러 정책 API에서 `AlwaysCheckAllPredicates`는 사용 중단되었다. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG 스케줄링]
-
-#### 기타 사용 중단:
-- k8s.io/node-api 컴포넌트는 더 이상 업데이트되지 않는다. 대신, k8s.io/api의 RuntimeClass 타입과 k8s.io/client-go의 생성된 클라이언트를 사용한다. ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG 노드와 릴리스]
-- apiserver_request_total에서 'client' 레이블을 제거했다. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery 와 Instrumentation]
+  NodeStage 및 NodePublish 간에 호출되는 NodeExpandVolume의 동작은 CSI 볼륨에 대해 사용 중단된다. CSI 드라이버는 노드 EXPAND_VOLUME 기능이 있는 경우 NodePublish 후 NodeExpandVolume 호출을 지원해야 한다. ([#86968](https://github.com/kubernetes/kubernetes/pull/86968), [@gnufied](https://github.com/gnufied)) [SIG Storage]
+- 기능: azure 디스크 마이그레이션이 1.19에서 베타 버전으로 변경된다. 기능 게이트 CSIMigration이 베타(기본적으로 설정되는)로 전환되며, CSIMigrationAzureDisk가 베타(AzureDisk CSI 드라이버가 설치되야 하므로 기본적으로 설정되어 있지 않은)로 전환된다. 
+  인-트리 AzureDisk 플러그인 "kubernetes.io/azure-disk"는 이제 사용 중단되며, 1.23에서 제거된다. 사용자는 CSIMigration + CSIMigrationAzureDisk 기능을 사용하도록 설정하고 AzureDisk CSI 드라이버(https://github.com/kubernetes-sigs/azuredisk-csi-driver)를 설치하여 해당 시점에 기존 파드 및 PVC 오브젝트가 중단되지 않도록 해야 한다.
+  사용자는 모든 새 볼륨에 대해 AzureDisk CSI 드라이버를 직접 사용해야 한다. ([#90896](https://github.com/kubernetes/kubernetes/pull/90896), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- Kube-apiserver: componentstatus API가 사용 중단된다. 이 API는 etcd, kube-scheduler 및 kube-controller-manager 컴포넌트의 상태를 제공했지만, 해당 컴포넌트가 API 서버에 대해 로컬이며, kube-scheduler 및 kube-controller-manager가 보안되지 않은 상태의 엔드포인트를 노출한 경우에만 동작했다. 이 API 대신 etcd의 상태 확인은 kube-apiserver의 상태 확인에 포함되고, kube-scheduler/kube-controller-manager 상태 확인은 해당 컴포넌트의 상태 엔드포인트에 대해 직접 수행될 수 있다. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps 및 Cluster Lifecycle]
+- Kubeadm: `kubeadm config view` 명령은 사용 중단되며, 기능 릴리스에서 제거될 예정이다. `kubectl get cm -o yaml -n kube-system kubeadm-config` 를 사용하여 kubeadm 설정을 직접 가져와야 한다. ([#92740](https://github.com/kubernetes/kubernetes/pull/92740), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: "kubeadm alpha kubelet config enable-dynamic" 명령이 사용 중단된다. 이 기능을 계속 사용하려면 k8s.io에서 "동적 Kubelet 구성"을 참조한다. ([#92881](https://github.com/kubernetes/kubernetes/pull/92881), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: `--experimental-kustomize` 기능이 사용 중단되며, 대신 `--experimental-patches` 기능을 사용한다. 지원되는 패치 형식은 "kubectl patch"와 동일하다. 디렉터리에서 파일로 읽히며, 초기화/조인/업그레이드 도중에 kubeadm 컴포넌트에 적용될 수 있다. 당분간은 정적 파드의 패치만 지원된다. ([#92017](https://github.com/kubernetes/kubernetes/pull/92017), [@neolit123](https://github.com/neolit123))
+- Kubeadm: "kubeadm alpha certs renew" 명령어에 대해 사용 중단된 "--use-api"  플래그가 제거되었다. ([#90143](https://github.com/kubernetes/kubernetes/pull/90143), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- 쿠버네티스는 더이상 hyperkube 이미지 빌드를 지원하지 않는다. ([#88676](https://github.com/kubernetes/kubernetes/pull/88676), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle 및 Release]
+- kubectl get 명령어에서 --export 플래그가 제거되었다. ([#88649](https://github.com/kubernetes/kubernetes/pull/88649), [@oke-py](https://github.com/oke-py)) [SIG CLI 및 Testing]
+- 스케줄러의 알파 기능인 'ResourceLimitsPriorityFunction'은 사용을 많이 하지 않아 완전히 제거되었다. ([#91883](https://github.com/kubernetes/kubernetes/pull/91883), [@SataQiu](https://github.com/SataQiu)) [SIG Scheduling 및 Testing]
+- Storage.k8s.io/v1beta1은 사용 중단되었으며, 대신 storage.k8s.io/v1이 사용된다. ([#90671](https://github.com/kubernetes/kubernetes/pull/90671), [@deads2k](https://github.com/deads2k)) [SIG Storage]
 
 ### API 변경
 
-#### 새로운 API 타입/버전:
-- 새로운 IngressClass 리소스가 추가되어 보다 나은 인그레스 구성이 가능하다. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, 앱, CLI, 네트워크, 노드, 테스트]
-- CSIDriver API는 storage.k8s.io/v1을 졸업했으며, 이제 사용이 가능하다. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG 스토리지]
-
-#### 새로운 API 필드:
-- autoscaling/v2beta2 HorizontalPodAutoscaler는 스케일 동작을 구성할 수 있는 `spec.behavior` 필드를 추가했다. 스케일 업과 다운에 대한 동작은 별도로 지정된다. 정책 목록과 정책 선택 방법 뿐만 아니라, 양 방향에서 안정화 윈도우를 지정할 수 있다. 정책은 추가되거나 제거되는 절대 파드 개수 또는 파드 비율을 제한할 수 있다.] ([#74525](https://github.com/kubernetes/kubernetes/pull/74525), [@gliush](https://github.com/gliush)) [SIG API Machinery, 앱, 오토스케일링, CLI]
-- 인그레스:
-  - `spec.ingressClassName`은 사용 중단된 `kubernetes.io/ingress.class` 어노테이션을 대체하고, 인그레스 오브젝트를 특정 컨트롤러와 연결할 수 있게 한다.
-  - 경로 정의는 `pathType` 필드를 추가했는데, 지정 경로가 유입되는 요청과 어떻게 일치해야 하는지 표시하는 것을 허용한다. 유효한 값은 `Exact`, `Prefix`, `ImplementationSpecific` 이다. ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG 앱, 클러스터 라이프사이클과 네트워크]
-- 알파 기능인 `AnyVolumeDataSource`는 퍼시스턴트볼륨클레임 오브젝트가 spec.dataSource 필드를 사용하여 사용자 정의 유형을 데이터 소스로 참조할 수 있도록 한다. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG 앱, 스토리지]
-- 알파 기능인 `ConfigurableFSGroupPolicy`는 v1 파드가 spec.securityContext.fsGroupChangePolicy 정책을 지정하여 파드에 마운트된 볼륨에 파일 권한이 적용되는 방식을 제어할 수 있다. ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG 스토리지]
-- 알파 기능인 `ServiceAppProtocol`을 사용하면 ServicePort 및 EndpointPort 정의에서 `appProtocol` 필드를 설정할 수 있다. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG 앱, 네트워크]
-- 알파 기능인 `ImmutableEphemeralVolumes`는 시크릿(Secret) 및 컨피그맵 오브젝트의 `immutable` 필드를 통해 내용을 변경할 수 없는(immutable) 것으로 표시할 수 있다. ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t)) [SIG 앱, CLI, 테스팅]
-
-#### 다른 API 변경:
-- 베타 기능인 `ServerSideApply`는 모든 새로운 오브젝트에 대해 변경된 필드를 추적하고 관리할 수 있게 해준다. 이는 관리자와 그것의 자체 필드에 대한 목록과 함께 `metadata`에 `managedFields`가 있음을 의미한다.
-- 알파 기능인 `ServiceAccountIssuerDiscovery`는 서비스 어카운트 토큰을 발행하도록 구성된 API 서버에 의해 `/.well-known/openid-configuration` 및 `/openid/v1/jwks` 엔드포인트에 위치한 OIDC 디스커버리 정보 및 서비스 어카운트 토큰 검증 키를 공개할 수 있게 한다. ([#80724](https://github.com/kubernetes/kubernetes/pull/80724), [@cceckman](https://github.com/cceckman)) [SIG API Machinery, 인증, 클러스터 라이프사이클, 테스트]
-- `x-kubernetes-list-map-keys`를 사용하여 목록 아이템을 고유하게 식별하는 속성을 지정하는 커스텀리소스데피니션(CustomResourceDefinition) 스키마는 해당 속성이 모든 목록 아이템에 존재하도록 하기 위해, 해당 속성을 필수로 설정하거나 기본값을 가져야 한다. 자세한 내용은 https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy 를 확인한다. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery, 테스트]
-- `x-kubernetes-list-type: map` 또는 `x-kubernetes-list-type: set`을 사용하는 커스텀리소스데피니션 스키마는 이제 해당 커스텀 리소스의 목록 아이템이 고유한지 확인할 수 있다. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-
-#### 설정 파일 변경:
-
-#### kube-apiserver:
-- `--egress-selector-config-file` 설정 파일은 이제 apiserver.k8s.io/v1beta1 EgressSelectorConfiguration 설정 오브젝트를 수용하며, 네트워크 프록시에 대한 HTTP 또는 GRPC 연결을 지정할 수 있도록 업데이트되었다. ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, 클라우드 공급자, 클러스터 라이프사이클]
-
-#### kube-scheduler:
-- 다중 스케줄링 프로파일을 지원하는 kubescheduler.config.k8s.io/v1alpha2 설정 파일 버전이 승인되었다. ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링]
-  - `kubescheduler.config.k8s.io/v1alpha2`에서 HardPodAffinityWeight가 최상위 ComponentConfig 파라미터에서 InterPodAffinity 플러그인의 PluginConfig 파라미터로 이동했다. ([#88002](https://github.com/kubernetes/kubernetes/pull/88002), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링, 테스트]
-  - Kube-scheduler는 둘 이상의 스케줄링 프로파일을 실행할 수 있다. 파드가 주어지면, 프로파일은 `.spec.schedulerName`을 사용하여 선택된다. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG 앱, 스케줄링, 테스트]
-  - v1alpha2 컴포넌트 설정에서 스케줄러 확장자(Scheduler Extender)를 설정할 수 있다. ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG 릴리스, 스케줄링, 테스트]
-  - 스케줄러 프레임워크의 PostFilter는 kubescheduler.config.k8s.io/v1alpha2에서 PreScore로 이름이 변경되었다. ([#87751](https://github.com/kubernetes/kubernetes/pull/87751), [@skilxn-go](https://github.com/skilxn-go)) [SIG 스케줄링, 테스트]
-
-#### kube-proxy:
-- IPVS 연결 타임아웃을 설정하기 위해 kube-proxy 플래그 `--ipvs-tcp-timeout`, `--ipvs-tcpfin-timeout`, `--ipvs-udp-timeout`을 추가했다. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim)) [SIG 클러스터 라이프사이클, 네트워크]
-- kube-proxy에 옵션 `--detect-local-mode` 플래그를 추가했다. 유효한 값은 "ClusterCIDR"(기본값은 이전 동작과 일치)과 "NodeCIDR"이다. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG 클러스터 라이프사이클, 네트워크, 스케줄링]
-- Kube-controller-manager와 kube-scheduler는 기본적으로 kube-apiserver와 일치하도록 프로파일링을 노출한다. 비활성화하려면 `--enable-profiling=false`를 사용한다. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, 클라우드 공급자, 스케줄링]
-- Kubelet 파드 리소스 API는 이제 활성화(active)된 파드에 대한 정보만 제공한다. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG 노드]
-- kube-controller-manager의 새로운 플래그 `--endpointslice-updates-batch-period`를 사용하여 파드 변경으로 생성된 엔드포인트슬라이스 업데이트 수를 줄일 수 있다. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, 앱, 네트워크]
-- kube-proxy, kubelet, kube-controller-manager 및 kube-scheduler의 새로운 플래그 `--show-hidden-metrics-for-version`은 이전 마이너 릴리스에서 사용 중단된 모든 숨겨진 메트릭을 표시하는 데 사용할 수 있다. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango)) [SIG 클러스터 라이프사이클, 네트워크]
-
-#### 베타가 된 기능:
-  - StartupProbe ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx)) [SIG 노드, Scalability, 테스트]
-
-#### GA 된 기능:
-  - VolumePVCDataSource ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG 스토리지]
-  - TaintBasedEvictions ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, 앱, 노드, 스케줄링, 테스트]
-  - BlockVolume 및 CSIBlockVolume ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG 스토리지]
-  - 윈도우 RunAsUserName ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG 앱 및 윈도우]
-- 이전 릴리스에서는 관련 기능이 무조건 활성화되었으므로, 다음 기능 게이트가 제거되었다. CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- CSI드라이버(CSIDriver)가 볼륨 소유권 및 권한 수정을 지원하는지 여부를 지정할 수 있도록, 새로운 알파 수준의 필드인, `SupportsFsGroup` 가 도입되었다. 이 필드를 사용하려면 `CSIVolumeSupportFSGroup` 기능 게이트를 활성화해야 한다. ([#92001](https://github.com/kubernetes/kubernetes/pull/92001), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, CLI 및 Storage]
+- 사용 중단된 어노테이션을 신규 API 서버의 필드와 동기화하기 위해 seccomp 프로파일에 대한 파드 버전 비대칭 전략이 추가되었다. 자세한 설명은 [KEP의](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md&#35;version-skew-strategy) 해당 섹션을 참고한다. ([#91408](https://github.com/kubernetes/kubernetes/pull/91408), [@saschagrunert](https://github.com/saschagrunert)) [SIG Apps, Auth, CLI 및 Node]
+- Kubelet에서 수집한 가속기/GPU 메트릭을 비활성화하는 기능이 추가되었다. ([#91930](https://github.com/kubernetes/kubernetes/pull/91930), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node]
+- 이제 어드미션 웹훅은 어드미션 리뷰 응답의 `.response.warnings` 필드를 사용하여 API 클라이언트에 표시되는 경고 메시지를 반환할 수 있다. ([#92667](https://github.com/kubernetes/kubernetes/pull/92667), [@liggitt](https://github.com/liggitt)) [SIG API Machinery 및 Testing]
+- CertificateSigningRequest API의 조건이 업데이트되었다.
+  - `status` 필드가 추가되었다. 이 필드의 기본값은 `True` 이며 `Approved`, `Denied` 및 `Failed` 조건에 대해서만 `True` 로 설정될 수 있다.
+  - `lastTransitionTime` 필드가 추가되었다.
+  - 서명자가 영구적인 실패를 표시할 수 있도록 `Failed` 조건 유형이 추가되었다. 이 조건은 `certificatesigningrequests/status` 하위 리소스를 통해 추가될 수 있다.
+  - `Approved` 및 `Denied` 조건은 상호 배타적이다.
+  - `Approved`, `Denied` , `Failed` 조건은 더이상 CSR에서 제거할 수 없다. ([#90191](https://github.com/kubernetes/kubernetes/pull/90191), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, Auth, CLI 및 Node]
+- 클러스터 관리자는 이제 kubelet 구성 파일에서 enableSystemLogHandler를 false로 설정하여 kubelet에서 /logs 엔드포인트를 끌 수 있다. enableSystemLogHandler는 오직 enableDebuggingHandlers도 true로 설정된 경우에만 true로 설정할 수 있다. ([#87273](https://github.com/kubernetes/kubernetes/pull/87273), [@SaranBalaji90](https://github.com/SaranBalaji90)) [SIG Node]
+- 사용자 정의 엔드포인트는 이제 새로운 EndpointSliceMirroring 컨트롤러에 의해 엔드포인트슬라이스에 미러링된다. ([#91637](https://github.com/kubernetes/kubernetes/pull/91637), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network 및 Testing]
+- CustomResourceDefinitions은 `spec.versions[*].deprecated` 를 `true` 로 설정하여 버전을 사용 중단됨으로 표시하고, 선택적으로 `spec.versions[*].deprecationWarning` 필드로 기본 지원 중단 경고를 재정의할 수 있도록 지원한다.  ([#92329](https://github.com/kubernetes/kubernetes/pull/92329), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- EnvVarSource api 문서의 버그가 수정되었다. ([#91194](https://github.com/kubernetes/kubernetes/pull/91194), [@wawa0210](https://github.com/wawa0210)) [SIG Apps]
+- "Too large resource version" 오류에서 복구할 수 없는 리플렉터(reflector)의 버그를 수정하였다. ([#92537](https://github.com/kubernetes/kubernetes/pull/92537), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- 고침: 이제 로그 타임스탬프에 고정 너비를 유지하기 위해 후행에 0이 포함된다. ([#91207](https://github.com/kubernetes/kubernetes/pull/91207), [@iamchuckss](https://github.com/iamchuckss)) [SIG Apps 및 Node]
+- `GenericEphemeralVolume` 기능 게이트의 새로운 알파 기능인 일반 임시 볼륨은 `EmptyDir` 볼륨에 대한 보다 유연한 대안을 제공한다. `EmptyDir` 과 마찬가지로 쿠버네티스에 의해 각 파드에 대한 볼륨이 자동으로 생성되고 삭제된다. 그러나 일반적인 프로비저닝 프로세스(`PersistentVolumeClaim`)를 사용하기 때문에, 스토리지는 타사 스토리지 공급 업체에서 제공할 수 있으며, 일반적인 모든 볼륨 기능이 작동한다. 볼륨은 비워둘 필요가 없다. 예를 들어, 스냅샷으로부터의 복원이 지원된다. ([#92784](https://github.com/kubernetes/kubernetes/pull/92784), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage 및 Testing]
+- 이제 쿠버네티스 빌드를 위하여 최소 Go1.14.4 이상의 버전이 필요하다. ([#92438](https://github.com/kubernetes/kubernetes/pull/92438), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Storage 및 Testing]
+- kubectl edit 명령어에서 managedFields가 숨겨졌다. ([#91946](https://github.com/kubernetes/kubernetes/pull/91946), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- K8s.io/apimachinery - scheme.Convert()는 이제 명시적으로 등록된 변환만을 사용한다. 기본 리플렉션 기반 변환은 더이상 사용할 수 없다. `+k8s:conversion-gen` 태그는 `k8s.io/code-generator` 컴포넌트와 함께 사용하여 변환을 생성할 수 있다. ([#90018](https://github.com/kubernetes/kubernetes/pull/90018), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps 및 Testing]
+- Kube-proxy: 포트 바인딩 실패를 치명적인 오류로 처리하기 위해 `--bind-address-hard-fail` 플래그가 추가되었다. ([#89350](https://github.com/kubernetes/kubernetes/pull/89350), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle 및 Network]
+- Kubebuilder 유효성 검사 태그는 CRD 생성을 위해 metav1.Condition에 설정된다. ([#92660](https://github.com/kubernetes/kubernetes/pull/92660), [@damemi](https://github.com/damemi)) [SIG API Machinery]
+- Kubelet의 --runonce 옵션은 이제 Kubelet의 설정 파일에서 `runOnce` 로도 사용할 수 있다. ([#89128](https://github.com/kubernetes/kubernetes/pull/89128), [@vincent178](https://github.com/vincent178)) [SIG Node]
+- Kubelet: 구조화된 로깅을 지원하기 위해 '--logging-format' 플래그가 추가되었다. ([#91532](https://github.com/kubernetes/kubernetes/pull/91532), [@afrouzMashaykhi](https://github.com/afrouzMashaykhi)) [SIG API Machinery, Cluster Lifecycle, Instrumentation 및 Node]
+- 쿠버네티스는 이제 golang 1.15.0-rc.1로 빌드된다.
+  - 주체 대체 이름(Subject Alternative Names)이 없을 때, 인증서를 제공하는 X.509의 CommonName 필드를 호스트 이름으로 처리하는, 더이상 사용되지 않는 레거시 동작은 이제 기본적으로 비활성화된다. GODEBUG 환경 변수에 x509ignoreCN=0 값을 추가하여 일시적으로 다시 활성화할 수도 있다. ([#93264](https://github.com/kubernetes/kubernetes/pull/93264), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage 및 Testing]
+- 변경할 수 없는 시크릿/컨피그맵 기능을 베타로 승격하고 기본적으로 기능이 활성화된다.
+  이를 통해 시크릿 또는 컨피그맵 오브젝트의 `Immutable` 필드를 설정하여 내용을 immutable로 표시할 수 있다. ([#89594](https://github.com/kubernetes/kubernetes/pull/89594), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps 및 Testing]
+- 스케줄 구성 `KubeSchedulerConfiguration` 에서 `BindTimeoutSeconds` 가 제거되었다. ([#91580](https://github.com/kubernetes/kubernetes/pull/91580), [@cofyc](https://github.com/cofyc)) [SIG Scheduling 및 Testing]
+- kubescheduler.config.k8s.io/v1alpha1이 제거되었다. ([#89298](https://github.com/kubernetes/kubernetes/pull/89298), [@gavinfish](https://github.com/gavinfish)) [SIG Scheduling]
+- 예약에 실패한 예약 플러그인은 예약 해제 익스텐션 포인트를 트리거하게 된다. ([#92391](https://github.com/kubernetes/kubernetes/pull/92391), [@adtac](https://github.com/adtac)) [SIG Scheduling 및 Testing]
+- 예전 API 클라이언트가 제출한 업데이트/패치 요청에서 처리하는 `metadata.managedFields` 의 회귀 문제가 해결되었다. ([#91748](https://github.com/kubernetes/kubernetes/pull/91748), [@apelisse](https://github.com/apelisse))
+- 스케줄러: 바인딩되지 않은 볼륨이 있는 파드를 예약하기 전에 선택적으로 사용 가능한 스토리지 용량을 확인한다. (신규 기능 게이트인 `CSIStorageCapacity` 가 있는 알파 기능, CSI 드라이버에서만 작동하며, CSI 드라이버 배포의 기능 지원에 따라 상이하다.) ([#92387](https://github.com/kubernetes/kubernetes/pull/92387), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, Scheduling, Storage 및 Testing]
+- Seccomp 지원이 GA로 전환되었다. 새로운 `seccompProfile` 필드가 파드 및 컨테이너의 securityContext 오브젝트에 추가된다. `seccomp.security.alpha.kubernetes.io/pod` 및 `container.seccomp.security.alpha.kubernetes.io/...` 어노테이션에 대한 지원은 사용 중단되며, v1.22에서 제거된다. ([#91381](https://github.com/kubernetes/kubernetes/pull/91381), [@pjbgf](https://github.com/pjbgf)) [SIG Apps, Auth, Node, Release, Scheduling 및 Testing]
+- ServiceAppProtocol 기능 게이트는 이제 베타 버전이며 기본적으로 활성화되어 서비스 및 엔드포인트에 새 AppProtocol 필드를 추가한다. ([#90023](https://github.com/kubernetes/kubernetes/pull/90023), [@robscott](https://github.com/robscott)) [SIG Apps 및 Network]
+- SetHostnameAsFQDN은 PodSpec의 새 필드이다. true로 설정하면, 
+  파드의 정규화된 도메인 이름(FQDN)이 해당 컨테이너의 호스트 이름으로 설정된다.
+  리눅스 컨테이너에서 이는 커널의 hostname 필드(utsname 구조체의 nodename 필드)에
+  FQDN을 설정하는 것을 의미한다. 윈도우 컨테이너에서 이는
+  레지스트리 키 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters에 대한 호스트 이름의 레지스트리 값을 FQDN으로 설정하는 것을 의미한다.
+  파드에 FQDN이 없는 경우에는 아무런 효과가 없다. ([#91699](https://github.com/kubernetes/kubernetes/pull/91699), [@javidiaz](https://github.com/javidiaz)) [SIG Apps, Network, Node 및 Testing]
+- The CertificateSigningRequest API는 다음의 변경 사항과 함께 certificates.k8s.io/v1로 승격되었다.
+  - 이제 `spec.signerName` 이 필요하며, `certificates.k8s.io/v1` API를 통해 `kubernetes.io/legacy-unknown` 요청을 생성하는것이 허용되지 않는다.
+  - `spec.usages` 가 필요하며, 중복값을 포함할 수 없으며, 알려진 사용법만 포함해야 한다.
+  - `status.conditions` 는 중복 유형을 포함할 수 없다.
+  - `status.conditions[*].status` 가 필요하다.
+  - `status.certificate` 는 PEM으로 반드시 인코딩되어야 하며, CERTIFICATE 블록만을 포함해야 한다. ([#91685](https://github.com/kubernetes/kubernetes/pull/91685), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, Auth, CLI 및 Testing]
+- 이제 HugePageStorageMediumSize 기능 게이트는 기본적으로 켜져 있으며, 컨테이너 수준에서 여러 크기의 huge page 리소스를 사용할 수 있다. ([#90592](https://github.com/kubernetes/kubernetes/pull/90592), [@bart0sh](https://github.com/bart0sh)) [SIG Node]
+- Kubelet의 --node-status-max-images 옵션은 이제 Kubelet 구성 파일의 nodeStatusMaxImage 필드를 통해 사용할 수 있다. ([#91275](https://github.com/kubernetes/kubernetes/pull/91275), [@knabben](https://github.com/knabben)) [SIG Node]
+- Kubelet의 --seccomp-profile-root 옵션은 사용 중단된 것으로 표시된다. ([#91182](https://github.com/kubernetes/kubernetes/pull/91182), [@knabben](https://github.com/knabben)) [SIG Node]
+- Kubelet의 `--bootstrap-checkpoint-path` 옵션이 제거되었다. ([#91577](https://github.com/kubernetes/kubernetes/pull/91577), [@knabben](https://github.com/knabben)) [SIG Apps 및 Node]
+- Kubelet의 `--cloud-provider` 및 `--cloud-config` 옵션은 사용 중단된 것으로 표시된다. ([#90408](https://github.com/kubernetes/kubernetes/pull/90408), [@knabben](https://github.com/knabben)) [SIG Cloud Provider 및 Node]
+- Kubelet의 `--enable-server` 및 `--provider-id` 옵션은 이제 각각 Kubelet 구성 파일의 `enableServer` 및 `providerID` 필드를 통해 사용할 수 있다. ([#90494](https://github.com/kubernetes/kubernetes/pull/90494), [@knabben](https://github.com/knabben)) [SIG Node]
+- Kubelet의 `--kernel-memcg-notification` 옵션은 이제 Kubelet 구성 파일의 kernelMemcgNotification 필드를 통해 사용할 수 있다. ([#91863](https://github.com/kubernetes/kubernetes/pull/91863), [@knabben](https://github.com/knabben)) [SIG Cloud Provider, Node 및 Testing]
+- Kubelet의 `--really-crash-for-testing` 및 `--chaos-chance` 옵션은 사용 중단된 것으로 표시된다. ([#90499](https://github.com/kubernetes/kubernetes/pull/90499), [@knabben](https://github.com/knabben)) [SIG Node]
+- Kubelet의 `--volume-plugin-dir` 옵션은 이제 Kubelet 구성 파일의 `VolumePluginDir` 필드를 통해 사용할 수 있다. ([#88480](https://github.com/kubernetes/kubernetes/pull/88480), [@savitharaghunathan](https://github.com/savitharaghunathan)) [SIG Node]
+- `DefaultIngressClass` 기능은 이제 GA로 전환되었다. `--feature-gate` 파라미터는 1.20에서 제거된다. ([#91957](https://github.com/kubernetes/kubernetes/pull/91957), [@cmluciano](https://github.com/cmluciano)) [SIG API Machinery, Apps, Network 및 Testing]
+- 알파 `DynamicAuditing` 기능 게이트 및 `auditregistration.k8s.io/v1alpha1` API가 제거되었으며 더이상 지원되지 않는다. ([#91502](https://github.com/kubernetes/kubernetes/pull/91502), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth 및 Testing]
+- kube-controller-manager 관리 서명자는 이제 고유한 서명 인증서와 키를 소유할 수 있다. `--cluster-signing-[signer-name]-{cert,key}-file` 에 대한 도움말을 참고한다. `--cluster-signing-{cert,key}-file` 는 여전히 기본값이다. ([#90822](https://github.com/kubernetes/kubernetes/pull/90822), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps 및 Auth]
+- v1.14부터 사용 중단된, 사용하지 않는 `series.state` 필드는 `events.k8s.io/v1beta1` 및 `v1` 이벤트 유형에서 삭제되었다. ([#90449](https://github.com/kubernetes/kubernetes/pull/90449), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps]
+- 스케줄러 플러그인에 대한 예약 해제 익스텐션 포인트가 예약 익스텐션 포인트로 병합되었다. ([#92200](https://github.com/kubernetes/kubernetes/pull/92200), [@adtac](https://github.com/adtac)) [SIG Scheduling 및 Testing]
+- Golang 버전이 v1.14.4로 변경되었다. ([#88638](https://github.com/kubernetes/kubernetes/pull/88638), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Cloud Provider, Release 및 Testing]
+- Service.Spec.IPFamily에 대한 API 문서를 변경하여, 이중 스택 기능이
+  GA 되기 전에 정확한 의미가 변경될 수 있으며, 사용자는
+  기존 서비스가 IPv4, IPv6 혹은 이중 스택인지 확인하기 위해 
+  IPFamily가 아닌 ClusterIP 또는 엔드포인트를 살펴봐야 한다. ([#91527](https://github.com/kubernetes/kubernetes/pull/91527), [@danwinship](https://github.com/danwinship)) [SIG Apps 및 Network]
+- 사용자는 리소스 그룹을 무시하도록 리소스 접두사를 구성할 수 있다. ([#88842](https://github.com/kubernetes/kubernetes/pull/88842), [@angao](https://github.com/angao)) [SIG Node 및 Scheduling]
+- `Ingress` 및 `IngressClass` 리소스가 `networking.k8s.io/v1` 로 변경되었다. `extensions/v1beta1` 및 `networking.k8s.io/v1beta1` API 버전의 인그레스 및 인그레스클래스 유형은 사용 중단되었으며, 더이상 1.22 이상에서 제공되지 않는다. 지속형 오브젝트는 `networking.k8s.io/v1` API를 통해 접근할 수 있다. v1 인그레스 오브젝트의 주목할만한 변경 사항은 다음과 같다. (v1beta1 필드 이름은 변경되지 않았다.)
+  - `spec.backend` -> `spec.defaultBackend`
+  - `serviceName` -> `service.name`
+  - `servicePort` -> `service.port.name` (string 값에 대하여)
+  - `servicePort` -> `service.port.number` (numeric 값에 대하여)
+  - `pathType` 은 더이상 v1에서 기본값을 갖지 않는다. "Exact", "Prefix" 또는 "ImplementationSpecific" 중에서 지정되어야 한다.
+  기타 인그레스 API 변경 사항:
+  - 백엔드는 이제 리소스 또는 서비스 백엔드가 될 수 있다.
+  - `path` 는 더이상 유효한 정규 표현식이 아니어도 된다. ([#89778](https://github.com/kubernetes/kubernetes/pull/89778), [@cmluciano](https://github.com/cmluciano)) [SIG API Machinery, Apps, CLI, Network 및 Testing]
+- `NodeResourcesLeastAllocated` 및 `NodeResourcesMostAllocated` 플러그인은 이제 CPU 및 메모리에 대한 사용자 정의 가중치를 지원한다. [#90544](https://github.com/kubernetes/kubernetes/pull/90544), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+- v1beta1 버전의 스케줄러 구성 설정 API에 `PostFilter` 유형이 추가되었다. ([#91547](https://github.com/kubernetes/kubernetes/pull/91547), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- `RequestedToCapacityRatioArgs` 인코딩은 이제 엄격하게 작동한다. ([#91603](https://github.com/kubernetes/kubernetes/pull/91603), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
+- `v1beta1` 스케줄러의 `Extender` 인코딩은 대소문자를 구분하며(`v1alpha1`/`v1alpha2` 는 대소문자를 구분하지 않았다.), `httpTimeout` 필드는 기간 인코딩을 사용하며(예를 들어, 1초는 `"1s"` 로 지정된다.), `v1alpha1`/`v1alpha2` 의 `enableHttps` 필드 이름이 `enableHTTPS` 로 변경되었다. ([#91625](https://github.com/kubernetes/kubernetes/pull/91625), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
 
 ### 기능
 
-- (많은 요청으로 인한) API 요청량 제한이 이제 로그 레벨 2의 client-go 로그에 리포트 된다. 메시지는 `Throttling request took 1.50705208s, request: GET:<URL>` 형태이다. 이러한 메시지가 있으면 관리자에게 클러스터를 적절히 조정해야 함을 알릴 수 있다. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery]
-- FC 볼륨 플러그인에 마운트 옵션 지원이 추가된다. ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG 스토리지]
-- 이용자 그룹(audience) 클레임의 spn: 접두사 없이 AAD 토큰을 가져올 수 있도록 azure 인증 모듈에 config-mode 플래그를 추가한다. 지정하지 않으면, 디폴트 동작이 변경되지 않는다. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, 인증, CLI, 클라우드 공급자]
-- CoreDNS 레플리카 개수 설정을 허용한다. ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick)) [SIG 클러스터 라이프사이클]
-- kubectl exec 호출 시 --filename 플래그를 사용하여 리소스를 지정할 수 있도록 허용 ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI, 테스트]
-- Apiserver는 HTTP/2 클라이언트가 단일 apiserver에 갇히는 것을 방지하기 위해 그레이스풀(GOAWAY)하게 닫히게 하는 요청의 일부인 새로운 플래그 --goaway-chance를 추가했다. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
-- Azure 클라우드 공급자는 이제 쿠버네티스 클러스터와 다른 AAD 테넌트 및 구독에서 Azure 네트워크 리소스(가상 네트워크, 로드 밸런서, 퍼블릭 IP, 라우팅 테이블, 네트워크 보안 그룹 등) 사용을 지원한다. 이 기능을 사용하려면, 다음을 참고한다.  https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md#host-network-resources-in-different-aad-tenant-and-subscription. ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG 클라우드 공급자]
-- Azure VMSS/VMSSVM 클라이언트는 이제 스로틀링(throttling) 요청을 금지한다. ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Azure 클라우드 공급자 캐시 TTL은 설정 가능하며, Azure 클라우드 공급자 목록은 다음과 같다.
-  - "availabilitySetNodesCacheTTLInSeconds"
-  - "vmssCacheTTLInSeconds"
-  - "vmssVirtualMachinesCacheTTLInSeconds"
-  - "vmCacheTTLInSeconds"
-  - "loadBalancerCacheTTLInSeconds"
-  - "nsgCacheTTLInSeconds"
-  - "routeTableCacheTTLInSeconds"
-  ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1)) [SIG 클라우드 공급자]
-- Azure 글로벌 속도 제한(rate limit)은 클라이언트별로 전환된다. 새로운 속도 제한 설정 옵션이 도입되었고, 다음과 같다. routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit, VirtualMachineSizeRateLimit. 원래 속도 제한 옵션은 새 클라이언트의 속도 리미터(limiter)의 디폴트 값이다. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Azure 네트워크 및 VM 클라이언트가 이제 스로틀링 요청을 금지한다. ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Azure 스토리지 클라이언트가 이제 스로틀링 요청을 금지한다. ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Azure: 단일 스택 IPv6에 대한 지원을 추가한다. ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG 클라우드 공급자]
-- 스케줄러의 ComponentConfig에서 PodTopologySpread 플러그인에 대한 DefaultConstraints를 지정할 수 있다. ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링]
-- VMSS 클러스터의 VM list 작업을 피하기 위해 DisableAvailabilitySetNodes가 추가되었다. vmType이 "vmss"이고 모든 노드(컨트롤 플레인 노드 포함)가 VMSS 가상 머신인 경우에만 사용해야 한다. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Elasticsearch는 advertise 주소 자동 설정을 지원한다. ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클, Instrumentation]
-- 엔드포인트슬라이스가 이제 디폴트로 활성화된다. 새로운 `EndpointSliceProxying` 기능 게이트는 kube-proxy가 엔드포인트슬라이스를 사용할지 여부를 결정하며, 디폴트로 비활성화되어 있다. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott)) [SIG 네트워크]
-- Kube-proxy: iptables 프록시에 이중 스택 IPv4/IPv6 지원이 추가되었다. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG 네트워크]
-- Kubeadm은 이제 kube-controller-manager에 대한 이중 스택 노드 cidr 마스크의 자동 계산을 지원한다. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 잡(Job)을 배포하는 업그레이드된 헬스 체크를 추가한다. ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는
-클러스터를 생성할 수 있게 한다. "kubeadm alpha certs renew"을 사용하여 기존 ECDSA 인증서의 갱신도 지원되지만, 즉시 또는 업그레이드 중에 RSA와 ECDSA 알고리즘간에 전환하지는 않는다. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth 및 클러스터 라이프사이클]
-- Kubeadm: JSON, YAML, Go 템플릿 및 JsonPath 형식으로 'kubeadm config images list' 커맨드의 구조화된 출력을 구현했다. ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클]
-- Kubeadm: kubeconfig 인증서 갱신 시, 내장된 CA를 디스크의 CA와 동기화된 상태로 유지한다. ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 같은 이름의 노드가 이미 존재하는 경우 클러스터에 조인하려는 노드를 거부한다. ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: kubeadm-flags.env에서 윈도우 특화된 kubelet 플래그를 지원한다. ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG 클러스터 라이프사이클, 윈도우]
-- Kubeadm: 이미지를 가져오는 데 실패한 후 자동 재시도를 지원한다. ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 알 수 없는 k8s 버전이 전달되면 가장 근접한 알려진 etcd 버전으로 폴백(fallback) 업그레이드를 지원한다. ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- Kubectl/drain: 축출 비활성화(disable-eviction) 옵션을 추가한다. 축출이 지원되는 경우에도, 삭제하기 위해 강제로 드레인(drain)한다. 이것은 PodDisruptionBudgets 확인을 우회하므로 주의해서 사용해야 한다. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI]
-- Kubectl/drain: skip-wait-for-delete-timeout 옵션을 추가한다. 파드의 `DeletionTimestamp`가 N초 보다 오래된 경우, 파드를 기다리는 것을 건너뛴다. 건너뛰려면 0초보다 커야 한다. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino)) [SIG CLI]
-- 사전 구성된 로드 밸런서의 Azure 클라우드 공급자에 `preConfiguredBackendPoolLoadBalancerTypes` 옵션이 추가됐다. 가능한 값: `""`, `"internal"`, `"external"`,`"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion)) [SIG 클라우드 공급자]
-- PodTopologySpread 플러그인은 이제 스케줄링 결정을 할 때 terteringPod를 제외한다. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG 스케줄링]
-- 클라우드 공급자/azure : 네트워크 보안 그룹은 이제 별도의 리소스 그룹에 있을 수 있다. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon)) [SIG 클라우드 공급자]
-- SafeSysctlWhitelist: net.ipv4.ping_group_range를 추가한다. ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda)) [SIG 인증]
-- 스케줄러 프레임워크 허용 플러그인은 이제 예약 플러그인 후 스케줄링 주기가 끝나는 시점에 플러그인이 실행된다. 바인딩 주기 시작 시 허가 대기 상태가 유지된다. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG 스케줄링]
-- 스케줄러: DefaultBinder 플러그인을 추가한다. ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링, 테스트]
-- TopologySpreadConstraints를 정의하는 파드에 대한 디폴트 스프레드 스코어링(spreading scoring) 플러그인을 건너뛴다. ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG 스케줄링]
-- kubectl --dry-run 플래그는 이제 클라이언트-사이드와 서버-사이드의 dry-run 전략을 지원하기 위해 'client', 'server', 'none' 값을 허용한다. --dry-run 플래그의 boolean 값과 설정되지 않은 값은 사용 중단(deprecated)되었으며 향후 버전에서는 값이 필요하다. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-- apply, patch, create, run, annotate, label, set, autoscale, drain, rollout undo, 그리고 expose를 포함한 명령에 대해 --dry-run=server를 사용하여 kubectl에서 서버-사이드 dry-run을 지원한다. ([#87714](https://github.com/kubernetes/kubernetes/pull/87714), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, CLI, 테스트]
-- --dry-run=server|client를 kubectl delete, taint, replace에 추가한다. ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI, 테스트]
-- PodTopologySpread(기능 게이트 `EvenPodsSpread`) 기능은 1.18에서 디폴트로 활성화되었다. ([#88105](https://github.com/kubernetes/kubernetes/pull/88105), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG 스케줄링, 테스트]
-- kubelet 및 디폴트 도커 런타임은 이제 대상 컨테이너의 리눅스 프로세스 네임스페이스에서 임시 컨테이너 실행을 지원한다. 다른 컨테이너 런타임은 이 기능에 대한 지원을 구현해야 해당 런타임에서 사용할 수 있다. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG 노드]
-- `CPUManager` 상태 파일의 기본 형식이 변경되었다. 업그레이드는 원활해야 하지만, 이전 형식을 참조하는 써드파티 도구는 업데이트해야 한다. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska)) [SIG 노드, 테스트]
-- CNI 버전을 v0.8.5로 업데이트한다. ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, 클러스터 라이프사이클, 네트워크, 릴리스, 테스트]
-- Webhook은 네트워크 프록시를 알파 버전으로 지원한다. ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, 인증, 테스트]
-- 클라이언트 인증서 파일이 제공되면, 새 연결을 위해 파일을 다시 로드하고 인증서가 변경되면 연결을 닫는다. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, 인증, 노드, 테스트]
-- --force 플래그로 kubectl을 사용하여 오브젝트를 삭제할 때, 더 이상 --grace-period=0을 지정할 필요가 없다. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- GCE의 윈도우 노드는 컨트롤 플레인에 가상 TPM-기반 인증을 사용할 수 있다. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh)) [SIG 클러스터 라이프사이클]
-- 이제 "--node-ip ::"를 kubelet에 전달하여 노드의 기본 주소로 사용할 IPv6 주소를 자동으로 감지해야 함을 나타낼 수 있다. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship)) [SIG 클라우드 공급자, 네트워크, 노드]
-- `kubectl`은 이제 `kubectl alpha debug` 명령을 포함한다. 이 명령을 사용하면 디버깅 목적으로 임시 컨테이너를 실행 중인 파드에 연결할 수 있다. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI]
-- kubeconfig 파일 및 kubectl의 --tls-server-name을 통해 TLS 서버 이름 재정의를 지정할 수 있다. ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, 인증, CLI]
+- defaultpreemption 플러그인은 기존 하드코딩된 파드 선점 로직을 대체하는 스케줄러에 등록되고 활성화된다. ([#92049](https://github.com/kubernetes/kubernetes/pull/92049), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling 및 Testing]
+- 스케줄링 필터 실패를 해결하기 위해, 필터 단계 후에 실행되는 스케줄러 프레임워크에 새로운 익스텐션 포인트인 `PostFilter` 가 도입되었다. 전형적인 구현은 선점 로직을 실행하는 것이다. ([#91314](https://github.com/kubernetes/kubernetes/pull/91314), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling 및 Testing]
+- 조치 필요: CoreDNS v1.7.0에서, [메트릭의 이름이 변경되어](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md&#35;metric-changes) 이전 메트릭의 이름을 사용하는 기존 리포팅 공식과 역호환(backward incompatible)되지 않는다. 업그레이드하기 전에 공식을 새 이름으로 조정해야 한다.
+  
+  Kubeadm은 이제 CoreDNS 버전 v1.7.0이 포함된다. 주요 변경 사항은 다음과 같다.
+  -  CoreDNS가 서비스 기록 업데이트를 중단할 수 있는 버그가 수정되었다.
+  -  어떤 정책이 설정되어 있어도 항상 첫 번째 업스트림 서버만 선택되는 포워드 플러그인의 버그가 수정되었다.
+  -  쿠버네티스 플러그인에서 이미 사용 중단된 `resyncperiod` 및 `upstream` 이 제거되었다.
+  -  프로메테우스(Prometheus) 메트릭 이름 변경을 포함한다. (표준 프로메테우스 메트릭 명명 규칙에 맞게 변경). 이전 메트릭의 이름을 사용하는 기존 리포팅 공식과 역호환된다.
+  -  페더레이션 플러그인(v1 쿠버네티스 페더레이션을 허용)이 제거되었다.
+  자세한 내용은 https://coredns.io/2020/06/15/coredns-1.7.0-release/ 에서 확인할 수 있다. ([#92651](https://github.com/kubernetes/kubernetes/pull/92651), [@rajansandeep](https://github.com/rajansandeep)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle 및 Instrumentation]
+- 사용 중단된 버전에 대한 API 요청은 이제 API 응답에서 경고 헤더를 수신하고, 사용 중단된 API의 사용을 나타내는 메트릭이 표시되도록 한다.
+  - `kubectl` 은 표준 에러 출력으로 경고를 출력하며, `--warnings-as-errors` 옵션을 허용하여 경고를 치명적인 오류로 처리한다.
+  - `k8s.io/client-go` 은 기본적으로 표준 에러 출력에 경고를 출력한다. `config.WarningHandler` 를 설정하여 클라이언트 별로 재정의하거나, `rest.SetDefaultWarningHandler()` 로 프로세스별로 재정의한다.
+  - `kube-apiserver` 는 요청된, 사용 중단된 API에 대해 `group`, `version`, `resource`, `subresource` 및 `removed_release` 레이블을 표시하고 `apiserver_requested_deprecated_apis` 게이지 메트릭을 `1` 로 설정한다. ([#73032](https://github.com/kubernetes/kubernetes/pull/73032), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, CLI, Instrumentation 및 Testing]
+- component-base에 --logging-format 플래그가 추가되었다. 기본값은 변경되지 않은 klog를 사용하는 "text"이다. ([#89683](https://github.com/kubernetes/kubernetes/pull/89683), [@yuzhiquan](https://github.com/yuzhiquan)) [SIG Instrumentation]
+- kubectl create deployment 명령어에 --port 플래그가 추가되었다. ([#91113](https://github.com/kubernetes/kubernetes/pull/91113), [@soltysh](https://github.com/soltysh)) [SIG CLI 및 Testing]
+- cmd/cloud-controller-manager에 .import-restrictions 파일이 추가되었다. ([#90630](https://github.com/kubernetes/kubernetes/pull/90630), [@nilo19](https://github.com/nilo19)) [SIG API Machinery 및 Cloud Provider]
+- CRI-API ImageSpec 오브젝트에 어노테이션이 추가되었다. ([#90061](https://github.com/kubernetes/kubernetes/pull/90061), [@marosset](https://github.com/marosset)) [SIG Node 및 Windows]
+- 스케줄러의 PodSchedulingDuration 메트릭에 시도(attempts)에 대한 레이블이 추가되었다. ([#92650](https://github.com/kubernetes/kubernetes/pull/92650), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation 및 Scheduling]
+- kubectl scale 명령어에 클라이언트측과 서버측에 대한 드라이런(dry-run) 지원이 추가되었다. ([#89666](https://github.com/kubernetes/kubernetes/pull/89666), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI 및 Testing]
+- kubectl diff에 셀렉터가 추가되었다. ([#90857](https://github.com/kubernetes/kubernetes/pull/90857), [@sethpollack](https://github.com/sethpollack)) [SIG CLI]
+- cgroups v2 노드의 유효성 검사에 대한 지원이 추가되었다. ([#89901](https://github.com/kubernetes/kubernetes/pull/89901), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle  및 Node]
+- 노드 수준에서, 다른 크기로 사전 할당된 huge page에 대한 지원이 추가되었다. ([#89252](https://github.com/kubernetes/kubernetes/pull/89252), [@odinuge](https://github.com/odinuge)) [SIG Apps 및 Node]
+- Azure 파일 드라이버에 대한 태그 지원이 추가되었다. ([#92825](https://github.com/kubernetes/kubernetes/pull/92825), [@ZeroMagic](https://github.com/ZeroMagic)) [SIG Cloud Provider 및 Storage]
+- azure 디스크 드라이버에 대한 태그 지원이 추가되었다. ([#92356](https://github.com/kubernetes/kubernetes/pull/92356), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- kubectl run 명령어에 --privileged 플래그가 추가되었다. ([#90569](https://github.com/kubernetes/kubernetes/pull/90569), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- `v1beta1` 장비 플러그인 API에 새로운 `GetPreferredAllocation()` 호출이 추가되었다. ([#92665](https://github.com/kubernetes/kubernetes/pull/92665), [@klueska](https://github.com/klueska)) [SIG Node 및 Testing]
+- 쿠버네티스 서비스의 세션 어피니티를 설정하기 위해 윈도우에 대한 기능 지원이 추가되었다.
+  필요: [윈도우 서버 vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/)(또는 그 이상) ([#91701](https://github.com/kubernetes/kubernetes/pull/91701), [@elweb9858](https://github.com/elweb9858)) [SIG Network 및 Windows]
+- kube-apiserver 메트릭 추가: apiserver_current_inflight_request_measures. (API 우선순위(Priority) 및 공정성(Fairness)이 활성화된 경우, windowed_request_stats). ([#91177](https://github.com/kubernetes/kubernetes/pull/91177), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery, Instrumentation 및 Testing]
+- AWS 로드밸런서 서비스의 대상 노드에 service.beta.kubernetes.io/aws-load-balancer-target-node-labels 어노테이션이 추가되었다. ([#90943](https://github.com/kubernetes/kubernetes/pull/90943), [@foobarfran](https://github.com/foobarfran)) [SIG Cloud Provider]
+- 서로 다른 세분성을 갖는 흐름-제어 시스템의 내부 상태를 덤프하기 위해 접두사 "/debug/flowcontrol/*" 아래에 디버깅 엔드포인트 집합이 추가되었다. ([#90967](https://github.com/kubernetes/kubernetes/pull/90967), [@yue9944882](https://github.com/yue9944882)) [SIG API Machinery]
+- kube-scheduler의 메트릭인 framework_extension_point_duration_seconds에 프로파일 레이블이 추가되었다.([#92268](https://github.com/kubernetes/kubernetes/pull/92268), [@alculquicondor](https://github.com/alculquicondor)) [SIG Instrumentation 및 Scheduling]
+- kube-scheduler의 메트릭인 schedule_attempts_total에 프로파일 레이블이 추가되었다.
+  - e2e_scheduling_duration_seconds에 결과 및 프로파일 레이블이 추가되었다. 이제 스케줄링 불가능 및 오류 시도 횟수가 기록된다. ([#92202](https://github.com/kubernetes/kubernetes/pull/92202), [@alculquicondor](https://github.com/alculquicondor)) [SIG Instrumentation 및 Scheduling]
+- 사용 중단된 API 버전에 대한 API 요청의 감사(audit) 이벤트는 이제 `"k8s.io/deprecated": "true"` 감사 어노테이션을 포함한다. 대상에 대한 제거 릴리스(removal release)가 식별되면, 해당 감사 이벤트는 `"k8s.io/removal-release": "<majorVersion>.<minorVersion>"` 감사 어노테이션도 포함한다. ([#92842](https://github.com/kubernetes/kubernetes/pull/92842), [@liggitt](https://github.com/liggitt)) [SIG API Machinery 및 Instrumentation]
+- 대시보드가 v2.0.1로 격상되었다. ([#91526](https://github.com/kubernetes/kubernetes/pull/91526), [@maciaszczykm](https://github.com/maciaszczykm)) [SIG Cloud Provider]
+- 클라우드 노드-컨트롤러는 InstancesV2를 사용한다. ([#91319](https://github.com/kubernetes/kubernetes/pull/91319), [@gongguan](https://github.com/gongguan)) [SIG Apps, Cloud Provider, Scalability 및 Storage]
+- 의존성: Golang 버전이 1.13.9로 변경되었다.
+  - 빌드: kube-cross 이미지 빌드가 제거되었다. ([#89275](https://github.com/kubernetes/kubernetes/pull/89275), [@justaugustus](https://github.com/justaugustus)) [SIG Release 및 Testing]
+- 세부 스케줄러 점수 결과는 레벨(verbose) 10에서 표시된다. ([#89384](https://github.com/kubernetes/kubernetes/pull/89384), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- E2e.test는 클러스터가 적합하다고 평가되기 위해, 통과해야 하는 적합성 테스트 목록을 표시할 수 있다. ([#88924](https://github.com/kubernetes/kubernetes/pull/88924), [@dims](https://github.com/dims)) [SIG Architecture 및 Testing]
+- PodTopologySpread 플러그인을 사용하여 defaultspreading을 수행하려면 DefaultPodTopologySpread 기능 게이트를 활성화해야 한다. 이렇게 하면, 레거시 DefaultPodTopologySpread 플러그인이 비활성화된다. ([#91793](https://github.com/kubernetes/kubernetes/pull/91793), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- EndpointSlice 컨트롤러가 실패한 동기화를 재시도하기 위해 더 오래 대기하게 된다. ([#89438](https://github.com/kubernetes/kubernetes/pull/89438), [@robscott](https://github.com/robscott)) [SIG Apps 및 Network]
+- 로컬 영역(AWS local zone)을 지원하기 위해, AWS azToRegion 메서드가 확장된다. ([#90874](https://github.com/kubernetes/kubernetes/pull/90874), [@Jeffwan](https://github.com/Jeffwan)) [SIG Cloud Provider]
+- 기능: azure 공유 디스크 지원이 추가되었다. ([#89511](https://github.com/kubernetes/kubernetes/pull/89511), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- 기능: azure 디스크 api-version이 변경되었다. ([#89250](https://github.com/kubernetes/kubernetes/pull/89250), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- 기능: [Azure 공유 디스크](https://docs.microsoft.com/ko-kr/azure/virtual-machines/disks-shared-enable?tabs=azure-cli)를 지원하며, azure 디스크 스토리지 클래스에 새로운 필드(`maxShares`)가 추가되었다.
 
-#### 메트릭:
-- `rest_client_rate_limiter_duration_seconds` 메트릭을 컴포넌트 기반에 추가하여 클라이언트 사이드 속도 제한기(rate limiter) 지연(latency)을 초 단위로 추적한다. 동사(verb)와 URL로 분류된다. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, 클러스터 라이프사이클, Instrumentation]
-- exec 인증에 대한 두 개의 클라이언트 인증서 메트릭을 추가했다.
-    - `rest_client_certificate_expiration_seconds`는 현재 클라이언트 인증서의 수명을 보고하는 측정기이다. UTC 1970년 1월 1일 이후 만료 시간을 초 단위로 보고한다.
-    - `rest_client_certificate_rotation_age`는 방금 교체한 클라이언트 인증서의 수명을 초 단위로 보고하는 히스토그램이다. ([#84382](https://github.com/kubernetes/kubernetes/pull/84382), [@sambdavidson](https://github.com/sambdavidson)) [SIG API Machinery, 인증, 클러스터 라이프사이클, Instrumentation]
-- 컨트롤러 관리자는 작업큐 메트릭을 제공한다. ([#87967](https://github.com/kubernetes/kubernetes/pull/87967), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
-- 다음의 메트릭 기능이 꺼져 있다.
-  - kubelet_pod_worker_latency_microseconds
-  - kubelet_pod_start_latency_microseconds
-  - kubelet_cgroup_manager_latency_microseconds
-  - kubelet_pod_worker_start_latency_microseconds
-  - kubelet_pleg_relist_latency_microseconds
-  - kubelet_pleg_relist_interval_microseconds
-  - kubelet_eviction_stats_age_microseconds
-  - kubelet_runtime_operations
-  - kubelet_runtime_operations_latency_microseconds
-  - kubelet_runtime_operations_errors
-  - kubelet_device_plugin_registration_count
-  - kubelet_device_plugin_alloc_latency_microseconds
-  - kubelet_docker_operations
-  - kubelet_docker_operations_latency_microseconds
-  - kubelet_docker_operations_errors
-  - kubelet_docker_operations_timeout
-  - network_plugin_operations_latency_microseconds ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango)) [SIG 네트워크, 노드]
-- Kube-apiserver 메트릭은 이제 /healthz, /livez, /readyz 요청에 대한 요청 수, 대기 시간 및 응답 크기를 포함한다. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery]
-- Kubelet은 이제 인증서 로테이션(rotation)을 수행할 수 없는 경우, `server_expiration_renew_failure` 및 `client_expiration_renew_failure` 메트릭 카운터를 제공한다. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips)) [SIG API Machinery, 인증, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation, 노드, 릴리스]
-- Kubelet: 메트릭 process_start_time_seconds는 ALPHA 안정성 레벨로 표시된다. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, 클러스터 라이프사이클, Instrumentation, 노드]
-- 헬스 상태가 좋지 않은 PLEG의 진단을 돕기 위한 새로운 메트릭 `kubelet_pleg_last_seen_seconds`를 추가한다. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham)) [SIG 노드]
+  kind: StorageClass
+  apiVersion: storage.k8s.io/v1
+  metadata:
+    name: shared-disk
+  provisioner: kubernetes.io/azure-disk
+  parameters:
+    skuname: Premium_LRS  &#35; 현재는 프리미엄 SSD만 사용 가능하다.
+    cachingMode: None  &#35; 읽기전용 호스트 캐싱은 maxShares>1 인 프리미엄 SSD에 사용할 수 없다.
+    maxShares: 2 ([#89328](https://github.com/kubernetes/kubernetes/pull/89328), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- 가상 서버 주소가 이미 바인딩되지 않은 경우, `EnsureDummyInterface` 만 실행하여 IPVS 프록시 성능을 향상시킬 수 있다. ([#92609](https://github.com/kubernetes/kubernetes/pull/92609), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
+- 이제 Kube-Proxy는 EndpointSliceProxying 기능 게이트를 통해 윈도우에서 엔드포인트슬라이스를 지원한다. ([#90909](https://github.com/kubernetes/kubernetes/pull/90909), [@kumarvin123](https://github.com/kumarvin123)) [SIG Network 및 Windows]
+- 이제 Kube-Proxy는 IPv6DualStack 기능 게이트를 사용하여 윈도우에서 IPv6DualStack 기능을 지원한다. ([#90853](https://github.com/kubernetes/kubernetes/pull/90853), [@kumarvin123](https://github.com/kumarvin123)) [SIG Network, Node 및 Windows]
+- Kube-addon-manager가 v9.1.1로 변경되어, 허용된 리소스의 기본 목록을 재정의할 수 있다. (https://github.com/kubernetes/kubernetes/pull/91018) ([#91240](https://github.com/kubernetes/kubernetes/pull/91240), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability 및 Testing]
+- etcd3에서 지원하는 Kube-apiserver는 데이터베이스 파일 크기를 표시하는 메트릭을 추출할 수 있다. ([#89151](https://github.com/kubernetes/kubernetes/pull/89151), [@jingyih](https://github.com/jingyih)) [SIG API Machinery]
+- Kube-apiserver, kube-scheduler 및 kube-controller manager는 이제 유닉스 시스템에서 실행되는 경우 --bind-address 및 --secure-port 플래그로 정의된 주소에서 수신 대기할 때, SO_REUSEPORT 소켓 옵션을 사용한다(윈도우는 지원되지 않는다). 이를 통해 동일한 구성으로 단일 호스트에서 이러한 프로세스의 여러 인스턴스를 실행할 수 있으므로, 다운타임 없이 정상적으로 변경/재시작이 가능하다. ([#88893](https://github.com/kubernetes/kubernetes/pull/88893), [@invidian](https://github.com/invidian)) [SIG API Machinery, Scheduling 및 Testing]
+- Kube-apiserver: NodeRestriction 어드미션 플러그인은 이제 새 노드를 만들 때, kubelet이 설정할 수 있는 노드 레이블을 1.16 이상에서 kubelet이 허용하는, `--node-labels` 파라미터로 제한한다. ([#90307](https://github.com/kubernetes/kubernetes/pull/90307), [@liggitt](https://github.com/liggitt)) [SIG Auth 및 Node]
+- Kube-controller-manager: 구조화된 로깅을 지원하기 위해 '--logging-format' 플래그가 추가되었다. ([#91521](https://github.com/kubernetes/kubernetes/pull/91521), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery 및 Instrumentation]
+- Kube-controller-manager: `--experimental-cluster-signing-duration` 플래그는 v1.22에서 사용 중단된 것으로 표시되며, `--cluster-signing-duration` 으로 대체된다. ([#91154](https://github.com/kubernetes/kubernetes/pull/91154), [@liggitt](https://github.com/liggitt)) [SIG Auth 및 Cloud Provider]
+- 이제 Kube-proxy는 리눅스에서 기본적으로 엔드포인트 대신 엔드포인트슬라이스를 사용한다. 새로운 알파 `WindowsEndpointSliceProxying` 기능 게이트를 통해 윈도우에서 기능을 활성화할 수 있다. ([#92736](https://github.com/kubernetes/kubernetes/pull/92736), [@robscott](https://github.com/robscott)) [SIG Network]
+- Kube-scheduler: 구조화된 로깅을 지원하기 위해 '--logging-format' 플래그가 추가되었다. ([#91522](https://github.com/kubernetes/kubernetes/pull/91522), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery, Cluster Lifecycle, Instrumentation 및 Scheduling]
+- Kubeadm은 이제 생성된 컴포넌트와 사용자 제공 컴포넌트의 설정을 구분하여, 구성 업그레이드가 필요한 경우 이전 컴포넌트를 다시 생성한다. ([#86070](https://github.com/kubernetes/kubernetes/pull/86070), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: 수동으로 업그레이드된 컴포넌트의 설정이, 업그레이드 계획 및 적용 중에 --config 옵션을 통해 YAML 파일에서 적용될 수 있다.  클러스터에 저장된 모든 것을 덮어쓰는 kubeadm 구성 및 컴포넌트의 설정이 보존되는 기존의 --config 동작도 유지된다. --config와 함께 사용되는 동작은 이제 kubeadm 설정 API 오브젝트(API group "kubeadm.kubernetes.io")가 파일에 제공되었는지의 여부에 따라 결정된다. ([#91980](https://github.com/kubernetes/kubernetes/pull/91980), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: 구동이 느린 컨테이너를 보호하기 위해 정적 파드에 대한 시작 프로브가 추가되었다. ([#91179](https://github.com/kubernetes/kubernetes/pull/91179), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: "kubeadm init phase certs" 하위 명령어의 "--csr-only" 및 "--csr-dir" 플래그는 사용 중단되었다. 대신 "kubeadm alpha certs generate-csr" 를 사용해야 한다. 이 신규 명령어를 사용하면 모든 컨트롤 플레인 컴포넌트에 대한 새로운 개인키 및 인증서 서명 요청을 생성할 수 있으므로, 외부 CA로 인증서에 서명할 수 있다. ([#92183](https://github.com/kubernetes/kubernetes/pull/92183), [@wallrj](https://github.com/wallrj)) [SIG Cluster Lifecycle]
+- Kubeadm: 'upgrade apply' 도중에, kube-proxy 컨피그맵이 누락된 경우, kube-proxy가 업그레이드되지 않아야 한다고 가정한다. DNS 서버 애드온에서 kube-dns/coredns 컨피그맵이 누락된 경우에도 동일하게 적용된다. 이는 'upgrade apply' 지원 단계까지의 일시적인 해결 방법이다. 해당 단계가 지원되면, kube-proxy/dns 수동으로 넘겨져야 한다. ([#89593](https://github.com/kubernetes/kubernetes/pull/89593), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: 컨트롤-플레인 정적 파드는 "시스템-노드-크리티컬" 우선순위 클래스로 전환되었다. ([#90063](https://github.com/kubernetes/kubernetes/pull/90063), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: upgrade plan은 이제 업그레이드 전에, 알려진 컴포넌트의 설정 상태를 나타내는 표를 출력한다. ([#88124](https://github.com/kubernetes/kubernetes/pull/88124), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubectl 명령어는 지정하지 않고(전체 리소스 이름을 입력할 필요 없음) 바로 taint no와 같이 사용할 수 있다. ([#88723](https://github.com/kubernetes/kubernetes/pull/88723), [@wawa0210](https://github.com/wawa0210)) [SIG CLI]
+- Kubelet: 다음의 메트릭 이름이 변경되었다.
+  kubelet_running_container_count --> kubelet_running_containers
+  kubelet_running_pod_count --> kubelet_running_pods ([#92407](https://github.com/kubernetes/kubernetes/pull/92407), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation 및 Node]
+- 클라이언트 인증서를 교체하도록 설정된 kubelet은 이제 인증서 만료까지 남은 시간(초)을 나타내는 `certificate_manager_server_ttl_seconds` 게이지 메트릭을 표시한다. ([#91148](https://github.com/kubernetes/kubernetes/pull/91148), [@liggitt](https://github.com/liggitt)) [SIG Auth 및 Node]
+- PodTopologySpreading이 더 잘 확산될 수 있도록 새로운 점수 계산 함수가 도입되었다. ([#90475](https://github.com/kubernetes/kubernetes/pull/90475), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- 유틸리티 라이브러리가 소폭 향상되었으며, 별도의 조치가 필요하진 않다. ([#92440](https://github.com/kubernetes/kubernetes/pull/92440), [@luigibk](https://github.com/luigibk)) [SIG Network]
+- PodTolerationRestriction: 에러에서 네임스페이스 허용 목록이 표시된다. ([#87582](https://github.com/kubernetes/kubernetes/pull/87582), [@mrueg](https://github.com/mrueg)) [SIG Scheduling]
+- 공급자별 참고 사항: vsphere: vsphere.conf - 성능 문제를 위해 자격증명 시크릿 관리를 비활성화하는 새로운 옵션 ([#90836](https://github.com/kubernetes/kubernetes/pull/90836), [@Danil-Grigorev](https://github.com/Danil-Grigorev)) [SIG Cloud Provider]
+- pod_preemption_metrics의 이름이 preemption_metrics로 변경되었다. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation 및 Scheduling]
+- Rest.Config는 이제, 이전에는 환경 변수를 통해서만 구성할 수 있었던 프록시 구성을 재정의하는 플래그를 지원한다. ([#81443](https://github.com/kubernetes/kubernetes/pull/81443), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery 및 Node]
+- PodTopologySpreading의 점수는 maxSkew가 증가함에 따라 차이가 감소되었다. ([#90820](https://github.com/kubernetes/kubernetes/pull/90820), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- 적용된 구성으로부터 필드가 제거된 경우 서버측 적용 동작이 정규화되었다. 다른 소유자가 없는 제거된 필드는 생성된 오브젝트에서 제거되거나 기본값이 있는 경우, 기본값으로 재설정된다. 기본값으로 재설정하지 않고 HPA로 `replicas` 필드를 이전하는 것과 같은 안전한 소유권 이전은 [소유권 이전](https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;transferring-ownership)에 설명되어 있다. ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation 및 Testing]
+- 서비스 컨트롤러: 노드의 관련 필드가 변경될 때에만 LB 노드 풀이 동기화된다. ([#90769](https://github.com/kubernetes/kubernetes/pull/90769), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps 및 Network]
+- CSIMigrationvSphere 기능 게이트가 베타로 전환되었다.
+  사용자는 CSIMigration + CSIMigrationvSphere 기능을 활성화하고 vSphere CSI 드라이버(https://github.com/kubernetes-sigs/vsphere-csi-driver)를 설치하여 인-트리 vSphere 플러그인 "kubernetes.io/vsphere-volume" 에서 vSphere CSI 드라이버로 워크로드를 이동해야 한다.
 
-### 기타 (버그, 정리(Cleanup) or Flake(플레이크))
+  요구사항: vSphere vCenter/ESXi 버전: 7.0u1, HW 버전: VM 버전 15 ([#92816](https://github.com/kubernetes/kubernetes/pull/92816), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider 및 Storage]
+- `kubectl create deployment` 명령에 대하여 --replicas 플래그가 지원된다. ([#91562](https://github.com/kubernetes/kubernetes/pull/91562), [@zhouya0](https://github.com/zhouya0))
+- 클라이언트측 적용에서 서버측 적용으로의 원활한 업그레이드를 지원하며, 해당하는 다운그레이드 또한 지원한다. ([#90187](https://github.com/kubernetes/kubernetes/pull/90187), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery 및 Testing]
+- VMSS의 비동기식 생성/변경을 지원한다. ([#89248](https://github.com/kubernetes/kubernetes/pull/89248), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
+- cgroups v2 통합 모드를 사용하는 호스트에서의 실행을 지원한다. ([#85218](https://github.com/kubernetes/kubernetes/pull/85218), [@giuseppe](https://github.com/giuseppe)) [SIG Node]
+- 코어 마스터 베이스 이미지(kube-apiserver, kube-scheduler)를 debian에서 distroless로 전환하였다. ([#90674](https://github.com/kubernetes/kubernetes/pull/90674), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release 및 Scalability]
+- etcd 이미지(마이그레이션 스크립트 포함)를 debian에서 distroless로 전환하였다. ([#91171](https://github.com/kubernetes/kubernetes/pull/91171), [@dims](https://github.com/dims)) [SIG API Machinery 및 Cloud Provider]
+- RotateKubeletClientCertificate 기능 게이트가 GA로 승격되었으며, kubelet --feature-gate RotateKubeletClientCertificate 파라미터는 1.20에서 제거된다. ([#91780](https://github.com/kubernetes/kubernetes/pull/91780), [@liggitt](https://github.com/liggitt)) [SIG Auth 및 Node]
+- SCTPSupport 기능이 기본적으로 활성화된다. ([#88932](https://github.com/kubernetes/kubernetes/pull/88932), [@janosi](https://github.com/janosi)) [SIG Network]
+- `certificatesigningrequests/approval` 하위 리소스는 이제 패치 API 요청을 지원한다. ([#91558](https://github.com/kubernetes/kubernetes/pull/91558), [@liggitt](https://github.com/liggitt)) [SIG Auth 및 Testing]
+- `kubernetes_build_info` 의 메트릭 레이블 이름이 `camel case` 에서 `snake case` 로 변경되었다.
+  - gitVersion --> git_version
+  - gitCommit --> git_commit
+  - gitTreeState --> git_tree_state
+  - buildDate --> build_date
+  - goVersion --> go_version
 
-- 1.16 이상의 API 서버에 대해, 1.15 이전으로 클라이언트 회귀가 파드 상태의 podIP 또는 노드 명세의 podCIDR을 업데이트할 수 없었던 문제를 수정했다. ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG 앱, 네트워크]
-- 롤링 업데이트 파티션에 대한 "kubectl describe statefulsets.apps" 출력 가비지를 수정했다. ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI]
-- PV의 파일시스템이 디스크의 실제 파일시스템과 일치하지 않을 때 PV에 이벤트를 추가한다. ([#86982](https://github.com/kubernetes/kubernetes/pull/86982), [@gnufied](https://github.com/gnufied)) [SIG 스토리지]
-- azure 디스크 WriteAccelerator 지원을 추가한다. ([#87945](https://github.com/kubernetes/kubernetes/pull/87945), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- VM 인스턴스 업데이트를 위해 고 루틴(goroutines) 간 지연(delay)을 추가한다. ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG 클라우드 공급자]
-- 클러스터 덤프 정보에 init 컨테이너 로그를 추가한다. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- 애드온 : elasticsearch 디스커버리는 IPv6를 지원한다. ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클, Instrumentation]
-- PV 및 PVC에 "volume.beta.kubernetes.io/migrated-to" 어노테이션을 추가하면, PV 및 PVC가 마이그레이션되어 프로비저닝과 삭제를 위해 해당 오브젝트를 선택할 수 있도록 외부 프로비저너에 신호를 보낸다. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG 스토리지]
-- 모든 api-server 로그 요청 라인은 grep으로 찾기 쉬운 형식으로 되어 있다. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp)) [SIG API Machinery]
-- Azure VMSS LoadBalancerBackendAddressPools 업데이트는 순차적-동기(sequential-sync) + 동시-비동기(concurrent-async) 요청으로 개선되었다. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Azure 클라우드 공급자는 이제 이용자 그룹 클레임에 spn: 접두사가 없는 AAD 토큰을 얻는다. ([#87590](https://github.com/kubernetes/kubernetes/pull/87590), [@weinong](https://github.com/weinong)) [SIG 클라우드 공급자]
-- AzureFile 및 CephFS는 민감한 마운트 옵션의 로깅을 방지하는 새로운 마운트 라이브러리를 사용한다. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG 스토리지]
-- 리눅스 노드와 윈도우 노드를 포함하는 쿠버네티스 클러스터에서 윈도우 스케줄링을 피하기 위해, dns-horizontal 컨테이너를 리눅스 노드에 바인딩한다. ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, 윈도우]
-- 윈도우 스케줄링을 피하기 위해 kube-dns 컨테이너를 리눅스 노드에 바인딩한다. ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, 윈도우]
-- 리눅스 노드와 윈도우 노드를 포함하는 쿠버네티스 클러스터에서 윈도우 스케줄링을 피하기 위해, metadata-agent 컨테이너를 리눅스 노드에 바인딩한다. ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, Instrumentation, 윈도우]
-- 리눅스 노드와 윈도우 노드를 포함하는 쿠버네티스 클러스터에서 윈도우 스케줄링을 피하기 위해, metrics-server 컨테이너를 리눅스 노드에 바인딩한다. ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210)) [SIG 클러스터 라이프사이클, Instrumentation, 윈도우]
-- 버그 수정: 최신 패키지 노드를 포함해야 한다. &#35;351 (@caseydavenport) ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera)) [SIG 클러스터 라이프사이클]
-- CPU 상한(limit)은 이제 윈도우 컨테이너에 적용된다. 노드가 오버-프로비저닝된 경우, 가중치가 사용되지 않으며 상한만 고려된다. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG 노드, 테스트, 윈도우]
-- COS 노드의 core_pattern을 절대 경로로 변경했다. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml)) [SIG 클러스터 라이프사이클, 노드]
-- Client-go 인증서 관리자 교체는 발급된 인증서와 함께 선택적인 중급(intermediate)의 체인을 유지하는 기능을 얻었다. ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, 인증]
-- 클라우드 공급자 설정인 CloudProviderBackoffMode가 더 이상 사용되지 않으므로 제거되었다. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- debian-hyperkube-base 이미지가 사용 중단되고 제거되므로 적합(Conformance) 이미지는 이제 stretch-slim에 의존한다. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG 클러스터 라이프사이클, 릴리스, 테스트]
-- kubectl create 커맨드에서 --generator 플래그는 사용 중단(deprecated)됨 ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI]
-- 초기화 단계(preflight) 동안, kubeadm은 이제 conntrack 실행 파일이 있는지 확인한다. ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni)) [SIG 클러스터 라이프사이클]
-- 엔드포인트슬라이스에는 파드 종료를 위한 엔드포인트가 없어야 한다. ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG 앱, 네트워크]
-- 임시 저장 한도를 초과하는 파드로 인한 축출은 이제 `kubelet_evictions` 메트릭에 의해 기록되며 경고할 수 있다. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG 노드]
-- kubectl이 널(null) 값을 잘못 거부하지 않도록 하기 위해 널 입력 가능(nullable), 필수/비필수 필드를 만들어 공개된 OpenAPI 스키마를 필터링한다. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-- --shutdown-delay-duration이 경과하기 전에, 종료가 시작된 직후 오류를 반환하도록 /readyz를 수정한다. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]
-- 감시(watch) 요청 처리 시 API Server 잠재적 메모리 누수 이슈를 수정한다. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
-- 엔드포인트슬라이스 컨트롤러 경합 조건(race condition)을 수정하고 엔드포인트슬라이스의 외부 변경을 처리하는지 확인한다. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott)) [SIG 앱, 네트워크]
-- 순수한 ipv6 vsphere 환경에서 손실된 IPv6 주소 이슈를 수정한다. ([#86001](https://github.com/kubernetes/kubernetes/pull/86001), [@hubv](https://github.com/hubv)) [SIG 클라우드 공급자]
-- 예기치 않은 LoadBalancer 업데이트가 발생하지 않도록 LoadBalancer 규칙 검사를 수정한다. ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- Kube-proxy에서 다른 IP 군으로 로드 밸런서를 사용할 때 다운되는 버그를 수정한다. ([#87117](https://github.com/kubernetes/kubernetes/pull/87117), [@aojea](https://github.com/aojea)) [SIG 네트워크]
-- port-forward 버그 수정: 이름이 지정된 포트가 서비스와 작동하지 않는 문제를 수정한다. ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py)) [SIG CLI]
-- 오래된 IPv6 엔드포인트가 정리되지 않은 이중 스택 IPVS 프록시의 버그를 수정한다. ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG 네트워크]
-- orphan 리비전(revision)을 채택할 수 없고 스테이트풀셋(statefulset)을 동기화 할 수 없는 버그를 수정한다. ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli)) [SIG 앱]
-- ExternalTrafficPolicy가 ExternalIP 서비스에 적용되지 않는 버그를 수정한다. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG 네트워크]
-- kubenet이 tc 출력을 파싱(parse)하지 못하는 버그를 수정한다. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG 네트워크]
-- 파드가 IP 주소를 얻지 못하게 하는 kubenet의 회귀 문제를 수정한다. ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs)) [SIG 네트워크, 노드]
-- azure 파일 AuthorizationFailure를 수정한다. ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- 엔드포인트슬라이스 컨트롤러가 공유 오브젝트를 수정하려고 하는 버그를 수정한다. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott)) [SIG API Machinery, 앱, 네트워크]
-- aws-load-balancer-security-groups 어노테이션 처리 문제를 수정한다. 이 어노테이션이 할당된 보안 그룹은 더 이상 쿠버네티스에 의해 수정되지 않으며, 대부분의 사용자가 예상하는 동작이다. 이 어노테이션을 사용하면, 더 이상 불필요한 보안 그룹이 만들어지지 않는다. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG 클라우드 공급자]
-- 부정확한 캐시로 인한 잘못된 VMSS 업데이트를 수정한다. ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG 클라우드 공급자]
-- hostname의 종속성을 제거하여 윈도우 용 isCurrentInstance를 수정한다. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- LoadBalancer가 또다른 리소스 그룹에 지정된 경우 azure 클라우드 공급자에서 찾을 수 없는 리소스에 대한 이슈 #85805를 수정한다. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm)) [SIG 클라우드 공급자]
-- local=true로 설정한 경우 kubectl annotate 오류를 수정한다. ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- kubectl create deployment 커맨드가 사용하는 이미지 이름을 수정한다. ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- `kubectl drain ignore` 데몬셋(daemonset) 및 기타 오류를 수정한다. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- 노드 이벤트에서 "involvedObject"에 대한 "apiVersion"이 누락되는 문제를 수정한다. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG 앱, 노드]
-- azure 클라우드 공급자에서 nil 포인터 역참조를 수정한다. ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx)) [SIG 클라우드 공급자]
-- 스테이트풀셋을 여러 번 적용하지 못하게 하는 스테이트풀셋 변환에서 회귀 문제를 수정 ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG 앱, 테스트]
-- 여러 경로를 함께 업데이트 할 때 경로 충돌된 경로 업데이트 작업을 수정한다. ([#88209](https://github.com/kubernetes/kubernetes/pull/88209), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- 파드 볼륨 처리가 실패할 때 kubelet이 PVC/PV 오브젝트를 반복적으로 가져오는 것을 방지하도록 수정한다. 이렇게 하면 이 같은 오류 시나리오에서 API 서버로의 계속적인 연결시도(hammering)를 막을 수 있지만, 파드 볼륨 처리의 일부 오류가 재시도되기까지 최대 2-3분이 소요될 수 있다. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG 노드, 스토리지]
-- DNS 레이블 서비스 어노테이션이 설정되지 않은 경우, PIP의 DNS가 삭제되는 버그를 수정한다. ([#87246] ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19)) [SIG 클라우드 공급자]
-- 컨트롤 플레인을 사용할 수 없게 하는 etcd LIST에서 썬더링 허드(thundering herd)를 야기하는 컨트롤 플레인 호스트 롤링 업그레이드를 수정한다. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, 노드, 테스트]
-- 수정: CSINode에 대한 azure 디스크 마이그레이션 지원을 추가한다. ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- 수정: azure 클라이언트에서 다시 시도할 수 없는(non-retriable) 오류를 추가한다. ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자]
-- 수정: azure 디스크 연결/해제 시 복구를 추가한다. ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자]
-- 수정: azure 데이터 디스크는 기본적으로 os 디스크와 동일한 키를 사용해야 한다. ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자]
-- 수정: azure 디스크를 Standard_DC4s/DC2s 인스턴스에 마운트할 수 없다. ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- 수정: azure 파일 마운트 타임아웃 이슈를 해결한다. ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- 수정: azure 디스크 전에 디스크 상태를 확인한다. ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자]
-- 수정: csi 드라이버에서 손상된 마운트 포인트를 해결한다. ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG 스토리지]
-- 수정: azure 디스크 lun 이슈를 해결한다. ([#88158](https://github.com/kubernetes/kubernetes/pull/88158), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- 수정: azure 디스크 최대 개수를 업데이트한다. ([#88201](https://github.com/kubernetes/kubernetes/pull/88201), [@andyzhangx](https://github.com/andyzhangx)) [SIG 클라우드 공급자, 스토리지]
-- AWS에서 "디바이스 X를 ​​요청했지만 Y를 찾음" 연결 오류를 수정했다. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane)) [SIG 클라우드 공급자, 스토리지]
-- CIDR 범위를 벗어나면 `Except` 값이 허용되는 네트워크폴리시(NetworkPolicy) 유효성 검사를 수정했다. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG 네트워크]
-- TopologyManager의 버그를 수정했다. 이전에는 컨테이너 생성이 직렬화된(serialized) 상황에서만 TopologyManager가 정렬을 보장했다. 이제는 컨테이너 생성의 모든 시나리오에서 정렬이 보장된다. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG 노드]
-- 노드가 추가될 때 공급자 ID를 판별하는 중에 오류가 발생하면 공급자 ID가 노드에 대해 설정되지 않는 버그가 수정되었다. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs)) [SIG 앱, 클라우드 공급자]
-- kubelet 이미지 관리자에서 스태틱(static) 파드 워커가 아무 경고 없이 작업을 중지시킬 수 있는 데이터 경합을 수정했다. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG 노드]
-- kubelet이 파드 볼륨을 정리하는 문제를 수정했다. ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu)) [SIG 스토리지]
-- kubelet이 파드의 준비(ready) 상태를 업데이트하지 못하는 회귀 문제를 수정했다. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu)) [SIG 노드]
-- kubelet이 동시 파드 조정(reconciliation) 루프를 잘못 실행하여 충돌하는 문제를 수정했다. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG 노드]
-- 타임아웃 후 블록 CSI 볼륨 정리 문제를 수정했다. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG 스토리지]
-- 타임아웃 후 CSI 원시 블록 볼륨 정리 문제를 수정했다. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG 스토리지]
-- AWS 클라우드 공급자가 프로비저닝하지 않은 LoadBalancer 보안 그룹을 삭제 시도하도록 수정했으며, `service.beta.kubernetes.io/aws-load-balancer-security-groups` 어노테이션이 있더라도 AWS 클라우드 공급자가 기본 LoadBalancer 보안 그룹을 생성하도록 수정했다. aws-load-balancer-security-groups의 의도된 동작은 로드 밸런서에 할당된 모든 보안 그룹을 바꾸는 것이다. ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919)) [SIG 클라우드 공급자]
-- 두 개의 스케줄러 메트릭(pending_pods와 schedule_attempts_total)이 기록되지 않는 문제를 수정했다. ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG 스케줄링]
-- 삭제/재생성된 파드에 대해 kubelet이 보고한(kubelet-reported) 파드 상태와 관련된 이슈를 수정했다. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt)) [SIG 노드]
-- 커스텀 리소스의 no-op 패치 또는 업데이트 시 metadata.generation의 증가를 야기하는 멀티-버전 커스텀 리소스의 변환(conversion) 오류를 수정했다. ([#88995](https://github.com/kubernetes/kubernetes/pull/88995), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
-- kubectl이 획득한 AAD 토큰이 on-behalf-of flow 및 oidc와 호환되지 않는 문제를 수정했다. 이 수정 이전의 이용자 그룹은 "spn:" 접두사를 가진다. 이 수정 후에는 "spn:" 접두사가 생략된다. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong)) [SIG API Machinery, 인증, 클라우드 공급자]
-- c2, n2, m1, m2 머신 유형에 15개 이상의 GCE 퍼시스턴트(Persistent) 디스크를 연결할 수 없는 문제를 수정했다. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG 스토리지]
-- 윈도우에서 엔드포인트슬라이스 기능 게이트를 활성화할 때 kube-proxy가 지원하도록 수정한다. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott)) [SIG 인증, 네트워크]
-- 클라이언트 인증서 교체 사례에서 kubelet이 크래시되는 이슈를 수정한다. ([#88079](https://github.com/kubernetes/kubernetes/pull/88079), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 인증, 노드]
-- 서비스 어카운트(service account) 토큰 컨트롤러를 실행하지 않는 클러스터에서 서비스 어카운트 토큰 승인 오류를 수정한다. ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt)) [SIG 인증]
-- 65536개의 IP 주소보다 큰 IPv4 범위를 사용하여 --service-cluster-ip-range 처리 중 v1.17.0 회귀 문제를 수정한다. ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt)) [SIG 네트워크]
-- 네트워크 폴리시(NetworkPolicy) PolicyTypes의 잘못된 유효성 검사 결과를 수정한다. ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn)) [SIG 네트워크]
-- 하위 프로토콜 교섭(negotiation)의 경우 클라이언트 및 서버 프로토콜이 모두 필요하다. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu)) [SIG API Machinery, 노드]
-- 여러 노드에서 연결을 허용하는 볼륨의 경우 이제 다른 노드에서 연결 및 분리 작업이 병렬로 실행된다. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG 스토리지]
-- 분리(orphan) 전파 정책으로 스테이트풀셋이 삭제되면 가비지 수집기가 ControllerRevisions를 올바르게 분리할 수 있다. ([#84984](https://github.com/kubernetes/kubernetes/pull/84984), [@cofyc](https://github.com/cofyc)) [SIG 앱]
-- `Get-kube.sh`는 공급자가 메타데이터 서버 기본값 대신 GCE 또는 GKE 인 경우, 인증을 위해 gcloud의 현재 로컬 GCP 서비스 계정을 사용한다. ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG 클러스터 라이프사이클]
-- CVE-2020-9283에 대한 수정 사항을 제공하도록 Golang/x/net이 업데이트되었다. ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation]
-- 서빙 인증서(serving certificate)의 파라미터가 SNI 인증서의 IP인 이름을 지정하면 서버 연결에 응답하는 데 우선 순위가 부여된다. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
-- yaml 파싱 성능을 개선했다. ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen)) [SIG API Machinery, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation, 노드]
-- 노드 인증자(authorizer)의 성능을 개선한다. ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG 인증]
-- GKE 알파 클러스터에서는 서비스 어노테이션 `cloud.google.com/network-tier: Standard`를 사용할 수 있다. ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG 클라우드 공급자]
-- CSI 퍼시스턴트 볼륨을 설명할 때 FSType을 포함한다. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca)) [SIG CLI, 스토리지]
-- Iptables/유저스페이스(userspace) 프록시: 모든 외부 IP 대신, 동기화 루프 당 하나씩 로컬 주소를 가져옴으로써 성능을 개선한다 ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, 클라우드 공급자, 클러스터 라이프사이클, Instrumentation , 네트워크]
-- Kube-aggregator: 항상 서비스의 현재 상태를 반영하기 위해 unavailableGauge 메트릭을 설정한다. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
-- Kube-apiserver: gracePeriodSeconds=0 및 resourceVersion 전제 조건(precondition)이 있는 파드를 삭제하는 중에 발생하는 충돌 오류를 수정했다. ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery]
-- Kube-proxy가 더 이상 공유 엔드포인트슬라이스를 수정하지 않는다. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott)) [SIG 네트워크]
-- Kube-proxy: 이중 스택 모드에서 엔드포인트의 IP Family를 얻을 수 없는 경우, 주소가 없는 엔드포인트에 대한 로그가 넘치지 않도록 경고 대신 InfoV(4) 레벨로 로그를 남긴다. ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG 네트워크]
-- Kubeadm을 사용하면 이중 스택이 활성화된 경우 단일 스택 클러스터를 구성할 수 있다. ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, 클러스터 라이프사이클, 네트워크]
-- Kubeadm에 이제 CoreDNS 버전 1.6.7이 포함된다. ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG 클러스터 라이프사이클]
-- Kubeadm 업그레이드는 항상 스택에 대한 etcd 백업을 유지한다. ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 'kubeadm alpha kubelet config download'가 제거되었다. 대신 'kubeadm upgrade node phase kubelet-config'를 사용한다. ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 클러스터 이름을 controller-manager 인수(argument)로 포워딩한다. ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 더 이상 존재하지 않는 "ci-cross/*" 대신 "ci/k8s-master" 버전 레이블 지원을 추가한다. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 동시 etcd 멤버 조인에 대한 잠정 지원을 추가로 개선한다. 여러 구성원이 동일한 호스트 이름을 받을 수 있는 버그를 수정한다. etcd 클라이언트 다이얼 타임아웃을 늘리고 추가/제거/... 작업에 대한 타임아웃을 다시 시도한다. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: "upgrade apply"에 kubelet 환경 파일을 쓰지 않도록 한다. ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 손상된 kubelet.conf 파일로 "kubeadm reset"을 실행할 때 발생할 수 있는 문제를 수정한다. ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 단일 노드 클러스터에서 'kubeadm upgrade'가 멈추는 버그를 수정한다. ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 태그가 변경되지 않았지만 내용이 변경된 경우에도 이미지를 미리 가져오도록 한다. ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클]
-- Kubeadm: v1.15에서 사용 중단(deprecated) 되었으므로 'kubeadm upgrade node config' 명령을 제거한다. 대신 'kubeadm upgrade node phase kubelet-config'를 사용한다. ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG 클러스터 라이프사이클]
-- Kubeadm: 사용 중단된 CoreDNS 기능-게이트(feature-gate)를 제거한다. 기능이 GA로 전환된 v1.11 이후부터 'true'로 설정되었다. v1.13에서는 CLI에서 사용 중단(deprecated) 및 히든(hidden)으로 표시되었다. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: apiserver가 응답하지 않으면 `kubeadm-config` 컨피그맵 생성 또는 변경(mutation)을 다시 시도한다. 이것은 새로운 컨트롤 플레인 노드에 조인할 때 복원력을 향상시킨다. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre)) [SIG 클러스터 라이프사이클]
-- Kubeadm: kubeconfig 파일에서 인증 기관(certificate authority) PEM 데이터의 유효성을 검사할 때 공백을 허용한다. ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클]
-- Kubeadm: bind-address 옵션을 사용하여 kube-controller-manager 및 kube-scheduler http 프로브(probe)를 구성한다. ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea)) [SIG 클러스터 라이프사이클]
-- Kubeadm: api-server AdvertiseAddress IP family를 사용하여 비 외부(non external) etcd 클러스터에 대한 etcd 엔드포인트 IP family를 선택한다. ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea)) [SIG 클러스터 라이프사이클]
-- kubectl cluster-info dump --output-directory=xxx 는 이제 출력 형식에 따라 확장자가 있는 파일을 생성한다. ([#82070](https://github.com/kubernetes/kubernetes/pull/82070), [@olivierlemasle](https://github.com/olivierlemasle)) [SIG CLI]
-- `kubectl describe <type>` 및 `kubectl top pod`는 표시할 결과가 없는 경우 `"No resources found"` 또는 `"No resources found in <namespace> namespace"` 라는 메시지를 반환한다. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- `kubectl drain node --dry-run`은 축출되거나 삭제될 파드를 나열한다. ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom)) [SIG CLI]
-- `kubectl set resources`는 리소스에 대한 빈(empty) 변경 사항을 전달하면 더 이상 오류를 반환하지 않는다. `kubectl set subject`는 리소스에 대한 빈 변경 사항을 전달하면 더 이상 오류를 반환하지 않는다. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) [SIG CLI]
-- metrics-server 또는 prometheus를 통해 수집한 Kubelet 메트릭은 더 이상 3개 이상의 파드를 실행하는 윈도우 노드에 대해 타임아웃되지 않아야 한다. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG 노드, 테스트, 윈도우]
-- kubelet 메트릭이 버킷(bucket)으로 변경되었다. 예를 들어 `exec/{podNamespace}/{podID}/{containerName}`은 이제 exec 일뿐이다. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG 노드]
-- kubelet은 API 서버에서 불필요한 파드 상태 업데이트 작업을 줄인다. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG 노드, 확장성]
-- 쿠버네티스는 매초가 아닌 5초 동안 100 msec마다 iptables 잠금을 획득하려고 시도한다. 이는 이탈률이 높은 iptables 모드에서 kube-proxy를 사용하는 환경에 특히 유용하다. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea)) [SIG 네트워크]
-- GCE 대상 풀에 대한 단일 업데이트의 인스턴스 수를 1000으로 제한한다. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG 클라우드 공급자, Network, 확장성]
-- Azure 클라이언트가 지정된 HTTP 상태 코드에서만 다시 시도한다. ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- 오류 메시지 및 서비스 이벤트 메시지를 보다 명확하게 만든다. ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- externalTrafficPolicy가 로컬로 설정된 경우 AWS NLB 헬스 체크 타임아웃을 최소화한다. ([#73363](https://github.com/kubernetes/kubernetes/pull/73363), [@kellycampbell](https://github.com/kellycampbell)) [SIG 클라우드 공급자]
-- Pause 이미지에 non-amd64 이미지의 "Architecture"가 포함된다. ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG 릴리스]
-- kubelet 및 kubeadm에서 pause 이미지가 3.2로 업그레이드되었다. ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder)) [SIG CLI, 클러스터 라이프사이클, 노드, 테스트]
-- 스케줄러를 실행할 때 플러그인/PluginConfig 및 정책 API는 상호 배타적이다. ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링]
-- `PreScore` 인터페이스에서 `FilteredNodesStatuses` 인수를 제거한다. ([#88189](https://github.com/kubernetes/kubernetes/pull/88189), [@skilxn-go](https://github.com/skilxn-go)) [SIG 스케줄링, 테스트]
-- 노드 인증자(node authorizer) 인덱스 유지보수에서 성능 문제를 해결했다. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG 인증]
-- v1.17.0-rc.1에서 승인(admission), 인증(authentication) 및 권한(authorization) 웹훅(webhook) 성능의 회귀를 해결했다. ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 테스트]
-- `kubectl get all` 과 `NewDiscoveryClientForConfig` 또는 `NewDiscoveryClientForConfigOrDie`를 사용하여 구성된 client-go 디스커버리 클라이언트에서 성능 회귀를 해결했다. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
-- oidc claim spn: 접두사가 생략되어 기존 Azure AD OIDC 활성화된 api-server와의 동작이 중단되는 kubectl azure 인증 모듈 변경을 되돌렸다. ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, 인증, 클라우드 공급자]
-- 공유 정보 제공자(Shared informers)는 이제 네트워크 중단 시에 더 안정적이다. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery]
-- 동일한 플러그인에 대해 PluginConfig를 두 번 이상 지정하면 스케줄러 시작을 실패한다.
-  Extender 지정 및 NodeResourcesFit 플러그인에 대한 .ignoredResources 구성이 실패된다. ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG 스케줄링]
-- restartPolicy=Never 파드의 종료(terminate)가 실제로 실패했을 때 더 이상 파드가 성공했다고 보고할 수 없다. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG 노드, 테스트]
-- CSR 서명 인증서/키 페어는 kube-apiserver 인증서/키 페어와 같이 디스크에서 다시 로드된다. ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, 앱, 인증]
-- k8s.io/client-go/tools/events의 EventRecorder는 관련 오브젝트에 설정되어 있지 않은 경우 (kube-system 대신) 디폴트 네임스페이스에 이벤트를 생성한다. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery]
-- 이제 감사(audit) 이벤트 소스 IP 목록은 요청을 API 서버로 보낸 IP로 항상 끝난다. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery, 인증]
-- 쿠버네티스 v1.17.0 샘플 apiserver를 사용하도록 sample-apiserver 집계 적합성 테스트가 업데이트되었다. ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, 아키텍처, CLI, 테스트]
-- 스로틀링 가능성을 줄이기 위해, Azure 노드 프로비저닝 상태가 삭제될 때 VM 캐시가 nil로 설정된다. ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG 클라우드 공급자]
-- VMSS 캐시가 추가되어 VMSS GET 스로틀링 가능성이 감소한다. ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19)) [SIG 클라우드 공급자]
-- 윈도우 노드에서 10초 이내로 kubelet 및 kube-proxy가 준비될 때까지 대기한다. ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031)) [SIG 클러스터 라이프사이클]
-- `kubectl apply -f <file> --prune -n ​​<namespace>`는 cli 지정 네임스페이스에서 파일에 정의되지 않은 모든 리소스를 제거(prune)해야 한다. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu)) [SIG CLI]
-- `kubectl create clusterrolebinding`는 rbac.authorization.k8s.io/v1 오브젝트를 생성한다. ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI]
-- `kubectl diff`는 이제 diff가 변경 내역을 찾은 경우에만 1을, kubectl 오류에서는 >1을 반환한다. "exit status code 1" 메시지도 뮤트(mute)되었다. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI, 테스트]
+  이 변경 사항은 `kube-apiserver`、`kube-scheduler`、`kube-proxy` 및 `kube-controller-manager` 에서 발생한다. ([#91805](https://github.com/kubernetes/kubernetes/pull/91805), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle 및 Instrumentation]
+- apiserver 로그의 추적 출력이 더 체계적이고 포괄적으로 변경되었다. 추적은 중첩되며, 오래 실행되지 않은 모든 요청 엔드포인트에 대해 전체 필터 체인이 계측된다(예: 인증 확인이 포함된다.). ([#88936](https://github.com/kubernetes/kubernetes/pull/88936), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation 및 Scheduling]
+- 시간 초과 직전에 감시 북마크를 보내는 것 외에도, 주기적으로(요청된 경우) 보내도록 변경되었다. ([#90560](https://github.com/kubernetes/kubernetes/pull/90560), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- cri-tools이 v1.18.0으로 변경되었다. ([#89720](https://github.com/kubernetes/kubernetes/pull/89720), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cloud Provider, Cluster Lifecycle, Release 및 Scalability]
+- etcd 클라이언트측이 v3.4.4로 변경되었다. ([#89169](https://github.com/kubernetes/kubernetes/pull/89169), [@jingyih](https://github.com/jingyih)) [SIG API Machinery 및 Cloud Provider]
+- etcd 클라이언트측이 v3.4.7로 변경되었다. ([#89822](https://github.com/kubernetes/kubernetes/pull/89822), [@jingyih](https://github.com/jingyih)) [SIG API Machinery 및 Cloud Provider]
+- etcd 클라이언트측이 v3.4.9로 변경되었다. ([#92075](https://github.com/kubernetes/kubernetes/pull/92075), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider 및 Instrumentation]
+- azure-sdk가 v40.2.0으로 변경되었다. ([#89105](https://github.com/kubernetes/kubernetes/pull/89105), [@andyzhangx](https://github.com/andyzhangx)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Storage 및 Testing]
+- 이제 `kubectl port-forward` 가 UDP를 지원하지 않음을 사용자에게 경고하게 된다. ([#91616](https://github.com/kubernetes/kubernetes/pull/91616), [@knight42](https://github.com/knight42)) [SIG CLI]
+- PodTopologySpread의 가중치 확산 스케줄링 점수가 2배로 늘어났다. ([#91258](https://github.com/kubernetes/kubernetes/pull/91258), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- `EventRecorder()` 는 `FrameworkHandle` 인터페이스에 노출되어 스케줄러 플러그인 개발자가 클러스터 수준 이벤트를 기록하도록 선택할 수 있다. ([#92010](https://github.com/kubernetes/kubernetes/pull/92010), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- `kubectl alpha debug` 명령어는 이제 원본을 복사하여 파드 디버깅을 지원한다. ([#90094](https://github.com/kubernetes/kubernetes/pull/90094), [@aylei](https://github.com/aylei)) [SIG CLI]
+- `kubectl alpha debug` 명령어는 이제 노드의 호스트 네임스페이스에서 실행되는 디버깅 컨테이너를 생성하여 노드를 디버깅하는 방식을 지원한다. ([#92310](https://github.com/kubernetes/kubernetes/pull/92310), [@verb](https://github.com/verb)) [SIG CLI]
+- `local-up-cluster.sh` 는 이제 기본적으로 CSI snapshotter를 설치하며, `ENABLE_CSI_SNAPSHOTTER=false` 로 비활성화할 수 있다. ([#91504](https://github.com/kubernetes/kubernetes/pull/91504), [@pohly](https://github.com/pohly))
+- `ImageLocality` 플러그인의 `maxThreshold` 는 이제 파드의 이미지 수에 따라 크기가 조정되어, 여러 이미지가 있는 파드의 노드 우선순위를 구분하는데 도움을 줄 수 있다. ([#91138](https://github.com/kubernetes/kubernetes/pull/91138), [@chendave](https://github.com/chendave)) [SIG Scheduling]
 
-## 의존성(Dependencies)
+### 문서
 
-- v3.8.4로 칼리코(Calico) 업데이트 ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera))[SIG 클러스터 라이프사이클]
-- v1.28.2로 aws-sdk-go 의존성 업데이트 ([#87253](https://github.com/kubernetes/kubernetes/pull/87253), [@SaranBalaji90](https://github.com/SaranBalaji90))[SIG API Machinery, 클라우드 공급자]
-- v0.8.5로 CNI 버전 업데이트 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus))[SIG 릴리스, 테스트, 네트워크, 클러스터 라이프사이클, API Machinery]
-- v1.17.0으로 cri-tools 업데이트 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert))[SIG 릴리스, 클러스터 라이프사이클]
-- kubelet 및 kubeadm에서 Pause 이미지가 3.2로 업그레이드 ([#88173](https://github.com/kubernetes/kubernetes/pull/88173), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, 노드, 테스트, 클러스터 라이프사이클]
-- kubeadm에서 1.6.7로 CoreDNS 버전 업데이트 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep))[SIG 클러스터 라이프사이클]
-- CVE-2020-9283을 수정하기 위해 golang.org/x/crypto를 업데이트 ([#8838](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder))[SIG CLI, Instrumentation, API Machinery, 클러스터 라이프사이클, 클라우드 공급자]
-- 1.13.8로 Go 업데이트 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov))[SIG 릴리스, 테스트]
-- 1.18.0으로 Cluster-Autoscaler 업데이트 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk))[SIG 오토스케일링, 클러스터 라이프사이클]
+- 샘플 앱 배포 지침이 변경되었다. ([#82785](https://github.com/kubernetes/kubernetes/pull/82785), [@ashish-billore](https://github.com/ashish-billore)) [SIG API Machinery]
+
+### 실패 테스트
+
+- Kube-proxy iptables min-sync-period 의 기본값은 1초로 변경되었다. (이전 값은 0 이다.) ([#92836](https://github.com/kubernetes/kubernetes/pull/92836), [@aojea](https://github.com/aojea)) [SIG Network]
+
+### 버그 또는 회귀(Regression)
+
+- 인-트리 소스의 PV 집합은 CSIPersistentVolumeSource로 변환될 때 노드 어피니티에서 주문된 요구사항 값을 갖는다. ([#88987](https://github.com/kubernetes/kubernetes/pull/88987), [@jiahuif](https://github.com/jiahuif)) [SIG Storage]
+- `informer-sync` 헬스 체커로 인한 apiserver의 패닉이 수정되었다. ([#93600](https://github.com/kubernetes/kubernetes/pull/93600), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery]
+- 이제 GCP cloud-controller-manager 가 클러스터 외부에서 실행되어 새 노드를 초기화하지 못하는 문제가 수정되었다. ([#90057](https://github.com/kubernetes/kubernetes/pull/90057), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Apps 및 Cloud Provider]
+- Kubelets 용 GCE CloudProvider를 초기화 할 때 GCE API 호출을 하지 않는다. ([#90218](https://github.com/kubernetes/kubernetes/pull/90218), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider 및 Scalability]
+- IP 별칭을 추가하거나 GCE 클라우드 제공 업체의 노드 객체에 반영할 때, 불필요한 GCE API 호출을 하지 않는다. ([#90242](https://github.com/kubernetes/kubernetes/pull/90242), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, Cloud Provider 및 Network]
+- 파드가 스케줄 되는 동안, 어노테이션이 변경될 때 불필요한 스케줄링 변동을 방지한다. ([#90373](https://github.com/kubernetes/kubernetes/pull/90373), [@fabiokung](https://github.com/fabiokung)) [SIG Scheduling]
+- kubectl 용 Azure 인증 모듈은 이제 갱신 토큰이 만료된 후에 로그인을 요청한다. ([#86481](https://github.com/kubernetes/kubernetes/pull/86481), [@tdihp](https://github.com/tdihp)) [SIG API Machinery 및 Auth]
+- Azure: lb 생성시 발생하는 동시성 해결 ([#89604](https://github.com/kubernetes/kubernetes/pull/89604), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Azure: 연결된 VMSS 가 많은 클러스터에서 스로틀링(throttling)을 방지하기 위해 전역 VMSS VMs 캐시를 VMSS 별 VM 캐시로 전환하였다. ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Azure: IPv6 인바운드 보안 규칙에 대한 대상 접두사 및 포트를 설정하였다. ([#91831](https://github.com/kubernetes/kubernetes/pull/91831), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- 베이스-이미지: kube-cross:v1.13.9-5 으로 업데이트 되었다. ([#90963](https://github.com/kubernetes/kubernetes/pull/90963), [@justaugustus](https://github.com/justaugustus)) [SIG Release 및 Testing]
+- 기존 servicePort의 nodePort가 수동으로 변경된 경우 AWS NLB 서비스에 대한 버그가 수정되었다. ([#89562](https://github.com/kubernetes/kubernetes/pull/89562), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- APIServer에 연결할 수 없거나 kubelet에 아직 올바른 자격증명이 없는 경우, CSINode 초기화는 시작할때 kubelet을 중단하지 않는다. ([#89589](https://github.com/kubernetes/kubernetes/pull/89589), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- CVE-2020-8557 (Medium): 컨테이너의 /etc/hosts 파일을 통한 노드-로컬 간 서비스 거부. 자세한 내용은 https://github.com/kubernetes/kubernetes/issues/93032 을 참조한다. ([#92916](https://github.com/kubernetes/kubernetes/pull/92916), [@joelsmith](https://github.com/joelsmith)) [SIG Node]
+- Client-go: watch를 재구성하는 대신 타임아웃이 발생하면, 정보 제공자가 전체 목록 요청으로 돌아가는 문제가 해결되었다. ([#89652](https://github.com/kubernetes/kubernetes/pull/89652), [@liggitt](https://github.com/liggitt)) [SIG API Machinery 및 Testing]
+- CloudNodeLifecycleController는 노드 모니터링을 할 때, 셧다운 상태 전에 노드의 존재 상태를 확인하게 된다. ([#90737](https://github.com/kubernetes/kubernetes/pull/90737), [@jiahuif](https://github.com/jiahuif)) [SIG Apps 및 Cloud Provider]
+- `startupProbe` 는 지정하지만 `readinessProbe` 는 지정하지 않은 컨테이너는 이전에는 `startupProbe` 가 완료되기 전에 "준비(ready)"된 것으로 간주되었지만 이제는 "준비되지 않은(not-ready)" 것으로 간주된다. ([#92196](https://github.com/kubernetes/kubernetes/pull/92196), [@thockin](https://github.com/thockin)) [SIG Node]
+- 이제 Cordon 된 노드가 AWS 대상 그룹에서 등록 취소된다. ([#85920](https://github.com/kubernetes/kubernetes/pull/85920), [@hoelzro](https://github.com/hoelzro)) [SIG Cloud Provider]
+- kubernetes.azure.com/managed=false 레이블이 지정된 노드를 로드 밸런서의 백엔드 풀에 추가하지 않는다. ([#93034](https://github.com/kubernetes/kubernetes/pull/93034), [@matthias50](https://github.com/matthias50)) [SIG Cloud Provider]
+- CSI 드라이버가 FailedPrecondition 오류를 반환하는 경우 볼륨 확장을 재시도 하지 않는다. ([#92986](https://github.com/kubernetes/kubernetes/pull/92986), [@gnufied](https://github.com/gnufied)) [SIG Node 및 Storage]
+- Dockershim 보안: 이제 파드 샌드박스가 항상 `no-new-privileges` 및 `runtime/default` seccomp 프로필로 실행된다.
+  dockershim seccomp: 이제 파드 수준에서 설정할 때 사용자 지정 프로필이 더 작은 seccomp 프로필을 가질 수 있다. ([#90948](https://github.com/kubernetes/kubernetes/pull/90948), [@pjbgf](https://github.com/pjbgf)) [SIG Node]
+- 이중-스택: 서비스 clusterIP가 지정된 ipFamily를 따르지 않는 버그가 수정되었다. ([#89612](https://github.com/kubernetes/kubernetes/pull/89612), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
+- EndpointSliceMirroring 컨트롤러는 이제 엔드포인트에서 엔드포인트슬라이스로 레이블을 복사한다. ([#93442](https://github.com/kubernetes/kubernetes/pull/93442), [@robscott](https://github.com/robscott)) [SIG Apps 및 Network]
+- Azure 가용성 영역(availability zone)이 항상 소문자인지 확인한다. ([#89722](https://github.com/kubernetes/kubernetes/pull/89722), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- DeletionTimestamp가 0이 아닌 파드에 대한 축출 요청이 항상 성공하게 된다. ([#91342](https://github.com/kubernetes/kubernetes/pull/91342), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps]
+- 리소스 이름이 내장 오브젝트와 동일한 CRD를 설명한다. ([#89505](https://github.com/kubernetes/kubernetes/pull/89505), [@knight42](https://github.com/knight42)) [SIG API Machinery, CLI 및 Testing]
+- 내부 정보가 동기화 되었는지를 확인하는 새로운 "informer-sync" 검사로 kube-apiserver의 /readyz 를 확장한다. ([#92644](https://github.com/kubernetes/kubernetes/pull/92644), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery 및 Testing]
+- winkernel kube-proxy 에 있는 DSR 로드밸런서 버전이 HNS 버전 9.3-9.max, 10.2+ 로 확장되었다. ([#93080](https://github.com/kubernetes/kubernetes/pull/93080), [@elweb9858](https://github.com/elweb9858)) [SIG Network]
+- 필수 어피니티 용어가 있는 첫번째 파드는 토폴로지 키가 일치하는 노드에서만 예약할 수 있게 된다. ([#91168](https://github.com/kubernetes/kubernetes/pull/91168), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- 연결 해제된 상태의 CIDR이 존재하는 경우에 대한 AWS 로드밸런서 VPC CIDR 계산이 수정되었다. ([#92227](https://github.com/kubernetes/kubernetes/pull/92227), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- 관리되지 않는 노드에 대한 InstanceMetadataByProviderID 가 수정되었다. ([#92572](https://github.com/kubernetes/kubernetes/pull/92572), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- 고객이 VMSS orchestrationMode를 설정한 경우 `VirtualMachineScaleSets.virtualMachines.GET` 이 허용되지 않았던 문제가 수정되었다. ([#91097](https://github.com/kubernetes/kubernetes/pull/91097), [@feiskyer](https://github.com/feiskyer))
+- 앞에 0이 있는 IPv6 주소 사용을 허용하지 않던 버그가 수정되었다. ([#89341](https://github.com/kubernetes/kubernetes/pull/89341), [@aojea](https://github.com/aojea)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle 및 Instrumentation]
+- ExternalTrafficPolicy 가 ExternalIPs 서비스에 적용되지 않던 버그를 수정하였다. ([#90537](https://github.com/kubernetes/kubernetes/pull/90537), [@freehan](https://github.com/freehan)) [SIG Network]
+- VMSS 캐시에서 nil VM 항목이 만료될 때의 조건이 수정되었다. ([#92681](https://github.com/kubernetes/kubernetes/pull/92681), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
+- 스케줄러가 불필요한 스케줄 시도를 수행할 수 있는 레이싱(racing) 이슈가 수정되었다. ([#90660](https://github.com/kubernetes/kubernetes/pull/90660), [@Huang-Wei](https://github.com/Huang-Wei))
+- 수정된 컨피그맵 또는 시크릿 하위 경로(subpath)의 볼륨 마운트를 사용하여 컨테이너가 다시 시작되는 문제가 수정되었다. ([#89629](https://github.com/kubernetes/kubernetes/pull/89629), [@fatedier](https://github.com/fatedier)) [SIG Architecture, Storage 및 Testing]
+- 다중 마스터 HA 클러스터에서 정적으로 할당 된 portNumber가 있는 NodePort 생성이 충돌하는 포트 할당 로직 버그가 수정되었다. ([#89937](https://github.com/kubernetes/kubernetes/pull/89937), [@aojea](https://github.com/aojea)) [SIG Network 및 Testing]
+- xfs_repair가 xfs 마운트를 중지하는 버그가 수정되었다. ([#89444](https://github.com/kubernetes/kubernetes/pull/89444), [@gnufied](https://github.com/gnufied)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation 및 Storage]
+- 클러스터 덤프 정보에 대한 네임스페이스 플래그가 작동하지 않는 문제가 수정되었다. ([#91890](https://github.com/kubernetes/kubernetes/pull/91890), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- OOM 으로 컨테이너가 손상된 경우, SystemOOM 감지에 대한 버그가 수정되었다. ([#88871](https://github.com/kubernetes/kubernetes/pull/88871), [@dashpole](https://github.com/dashpole)) [SIG Node]
+- 이미지 파일 시스템 감지, devicemapper에 대한 디스크 메트릭, 5.0+ 리눅스 커널에서 OOM Kill 감지에 대한 버그가 수정되었다. ([#92919](https://github.com/kubernetes/kubernetes/pull/92919), [@dashpole](https://github.com/dashpole)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation 및 Node]
+- etcd 이미지에서 etcd 버전 마이그레이션 스크립트가 수정되었다. ([#91925](https://github.com/kubernetes/kubernetes/pull/91925), [@wenjiaswe](https://github.com/wenjiaswe)) [SIG API Machinery]
+- Azure 파일 CSI 번역의 결함이 수정되었다. ([#90162](https://github.com/kubernetes/kubernetes/pull/90162), [@rfranzke](https://github.com/rfranzke)) [SIG Release 및 Storage]
+- 짧은 시간에 Azure 노드를 다시 만들 경우, 인스턴스를 찾을 수 없는 문제가 수정되었다. ([#93316](https://github.com/kubernetes/kubernetes/pull/93316), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- 지원되는 거대 페이지의 크기를 변경할 시 발생하는 문제가 수정되었다. ([#80831](https://github.com/kubernetes/kubernetes/pull/80831), [@odinuge](https://github.com/odinuge)) [SIG Node 및 Testing]
+- 준비 상태(readiness)를 보고하기 전까지 APIServices가 HTTP 핸들러에 설치될 때까지 기다리도록 kube-apiserver 시작 작업이 수정되었다. ([#89147](https://github.com/kubernetes/kubernetes/pull/89147), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- kubectl create --dryrun 클라이언트가 네임스페이스를 무시하는 문제가 수정되었다. ([#90502](https://github.com/kubernetes/kubernetes/pull/90502), [@zhouya0](https://github.com/zhouya0))
+- kubectl create secret docker-registry 명령어의 --from-file 플래그를 사용할 수 없는 문제가 수정되었다. ([#90960](https://github.com/kubernetes/kubernetes/pull/90960), [@zhouya0](https://github.com/zhouya0)) [SIG CLI 및 Testing]
+- kubectl describe CSINode 명령어의 nil pointer 에러가 수정되었다. ([#89646](https://github.com/kubernetes/kubernetes/pull/89646), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- 리스(Lease) 정보에 접근할 수 없는 사용자를 위해 kubectl describe node 명령어가 수정되었다. ([#90469](https://github.com/kubernetes/kubernetes/pull/90469), [@uthark](https://github.com/uthark)) [SIG CLI]
+- 빈 어노테이션에 대한 kubectl describe 명령어의 출력 형식이 수정되었다. ([#91405](https://github.com/kubernetes/kubernetes/pull/91405), [@iyashu](https://github.com/iyashu)) [SIG CLI]
+- 실제로 패치를 지속하지 않도록 kubectl diff 명령어가 수정되었다. ([#89795](https://github.com/kubernetes/kubernetes/pull/89795), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI 및 Testing]
+- kubectl run 명령어의 --dry-run=client 플래그가 네임스페이스를 무시하는 문제가 수정되었다. ([#90785](https://github.com/kubernetes/kubernetes/pull/90785), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- kubectl version 명령이 설정 파일 없이 버전 정보를 표시하도록 변경되었다. ([#89913](https://github.com/kubernetes/kubernetes/pull/89913), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery 및 CLI]
+- `kubectl alpha debug` 명령어의 `--container` 플래그에 대하여 `-c` 축약표현이 누락된 문제가 수정되었다. ([#89674](https://github.com/kubernetes/kubernetes/pull/89674), [@superbrothers](https://github.com/superbrothers)) [SIG CLI]
+- 오브젝트의 평균 값이 무시되어 출력되는 문제가 수정되었다. ([#89142](https://github.com/kubernetes/kubernetes/pull/89142), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery]
+- Azure VMs에 공용 IP를 할당 한 후 공용 IP가 표시되지 않는 문제가 수정되었다. ([#90886](https://github.com/kubernetes/kubernetes/pull/90886), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- 파드보다 먼저 노드를 제거할 때 스케줄러의 충돌이 일어나는 문제를 수정하였다. ([#89908](https://github.com/kubernetes/kubernetes/pull/89908), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- 로드밸런서 backendPools 에 대해 Azure VMSS를 업데이트 할 때 VMSS 이름 및 리소스 그룹의 이름 수정에 대한 버그가 수정되었다. ([#89337](https://github.com/kubernetes/kubernetes/pull/89337), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Azure VM 컴퓨터 이름의 접두사가 VMSS 이름과 다른 경우의 스로틀링 문제가 해결되었다. ([#92793](https://github.com/kubernetes/kubernetes/pull/92793), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- 수정: Azure 할당 해제 노드가 종료된 것으로 간주 ([#92257](https://github.com/kubernetes/kubernetes/pull/92257), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- 수정: azure 디스크 PV에 대한 GetLabelsForVolume 패닉 문제 ([#92166](https://github.com/kubernetes/kubernetes/pull/92166), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- 수정: 어노테이션 지원에 Azure 파일 마이그레이션 지원 추가 ([#91093](https://github.com/kubernetes/kubernetes/pull/91093), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Node]
+- 수정: API 스로틀링(throttling)을 유발할 수 있는 Azure 디스크 댕글링(dangling) 연결 문제 ([#90749](https://github.com/kubernetes/kubernetes/pull/90749), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- 수정: ip 제품군을 기반으로 올바른 ip 결정 ([#93043](https://github.com/kubernetes/kubernetes/pull/93043), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- 수정: 비어있는 경우 도커 구성 캐시를 사용하지 않음 ([#92330](https://github.com/kubernetes/kubernetes/pull/92330), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- 수정: Azure 디스크 스토리지 클래스 마이그레이션에서 토폴로지 문제 수정 ([#91196](https://github.com/kubernetes/kubernetes/pull/91196), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- 수정: 최대 개수 테이블에 항목이 누락되어 디스크 연결 오류 발생 ([#89768](https://github.com/kubernetes/kubernetes/pull/89768), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- 수정: 잘못된 최대 Azure 디스크 최대 개수 ([#92331](https://github.com/kubernetes/kubernetes/pull/92331), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- 수정: Azure 디스크 및 파일 마운트 시 초기 지연 ([#93052](https://github.com/kubernetes/kubernetes/pull/93052), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider 및 Storage]
+- 수정: Azure에서 삭제된 비 VMSS 인스턴스에 의해 지원되는 노드 제거 지원 ([#91184](https://github.com/kubernetes/kubernetes/pull/91184), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- 수정: Azure 디스크에 강제 분리 사용 ([#91948](https://github.com/kubernetes/kubernetes/pull/91948), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- wait.Forever에서 첫 번째 반복에서 백오프 기간을 건너 뛰는 1.18 회귀 문제가 수정되었다. ([#90476](https://github.com/kubernetes/kubernetes/pull/90476), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
+- 엔드포인트 슬라이스 업데이트에서 newObj 를 oldObj 로 잘못 사용하는 버그가 수정되었다. ([#92339](https://github.com/kubernetes/kubernetes/pull/92339), [@fatkun](https://github.com/fatkun)) [SIG Apps 및 Network]
+- 중첩 범위가 있는 jsonpath 출력 표현식으로 kubectl 명령을 실행하면, 중첩 범위 다음의 표현식이 무시되는 버그가 수정되었다. ([#88464](https://github.com/kubernetes/kubernetes/pull/88464), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery]
+- TopologyManager가 활성화 되었을 때, 재사용 가능한 CPU 및 장치 할당이 적용되지 않는 버그가 수정되었다. ([#93189](https://github.com/kubernetes/kubernetes/pull/93189), [@klueska](https://github.com/klueska)) [SIG Node]
+- 깊이 중첩된 오브젝트에 json 패치를 적용하는 성능 문제가 수정되었다. ([#92069](https://github.com/kubernetes/kubernetes/pull/92069), [@tapih](https://github.com/tapih)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle 및 Instrumentation]
+- RBAC 역할 및 바인딩 오브젝트의 가비지 수집을 방지하는 회귀 문제가 수정되었다. ([#90534](https://github.com/kubernetes/kubernetes/pull/90534), [@apelisse](https://github.com/apelisse)) [SIG Auth]
+- kubeconfig 파일이 없을 때 --local 또는 --dry-run 플래그를 사용하여 kubectl 명령을 실행하는 회귀 문제가 수정되었다. ([#90243](https://github.com/kubernetes/kubernetes/pull/90243), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI 및 Testing]
+- 베어러 토큰(kubectl --token=..)과 exec 자격증명 플러그인이 동일한 컨텍스트로 구성되었을 때 모호하게 동작하는 문제가 수정되었다. 이제 전달자 토큰이 우선하게 된다. ([#91745](https://github.com/kubernetes/kubernetes/pull/91745), [@anderseknert](https://github.com/anderseknert)) [SIG API Machinery, Auth 및 Testing]
+- 이름에 `.` 문자가 포함된 서비스 어카운트의 사용자 인증 정보 마운트 문제가 수정되었다. ([#89696](https://github.com/kubernetes/kubernetes/pull/89696), [@nabokihms](https://github.com/nabokihms)) [SIG Auth]
+- 노드 삭제 시 파드의 nominatedNodeName을 지울 수 없는 문제가 수정되었다. ([#91750](https://github.com/kubernetes/kubernetes/pull/91750), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling 및 Testing]
+- zsh 완료가 성공적으로 초기화되었지만 zsh 완료를 초기화 할때 0이 아닌 종료 코드가 반환되는 버그가 수정되었다. ([#88165](https://github.com/kubernetes/kubernetes/pull/88165), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- endpointSliceTracker의 메모리 누수 문제가 수정되었다. ([#92838](https://github.com/kubernetes/kubernetes/pull/92838), [@tnqn](https://github.com/tnqn)) [SIG Apps 및 Network]
+- iSCSI 및 FibreChannel 볼륨 플러그인의 고정 마운트 옵션이 수정되었다. ([#89172](https://github.com/kubernetes/kubernetes/pull/89172), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- 영역 전체의 노드 수에 불균형이 있는 클러스터의 kube-scheduler 에서 손실된 노드 데이터에 대한 문제가 수정되었다. ([#93355](https://github.com/kubernetes/kubernetes/pull/93355), [@maelk](https://github.com/maelk))
+- IPv6DualStack 기능 게이트가 활성화된 클러스터에서 서비스를 생성하거나
+  변경할 때 IPFamily 필드와 관련된 몇 가지 버그가 수정되었다. 
+  
+  IPFamily 필드의 동작이 이상하고 일관성이 없으며, 이중-스택 
+  기능이 GA가 되기 전에 변경될 가능성이 있다. 사용자는 현재 
+  이 필드를 "쓰기 전용" 으로 취급해야 하며 현재 IPFamily 값을 
+  기반으로 서비스에 대한 어떤 가정도 하지 않아야 한다. ([#91400](https://github.com/kubernetes/kubernetes/pull/91400), [@danwinship](https://github.com/danwinship)) [SIG Apps 및 Network]
+- OwnerReferencesPermissionEnforcement 유효성 검사 승인 플러그인이 활성화된 클러스터에서 엔드포인트슬라이스 컨트롤러가 오류없이 실행되도록 수정되었다. ([#89741](https://github.com/kubernetes/kubernetes/pull/89741), [@marun](https://github.com/marun)) [SIG Auth 및 Networking]
+- IPv6-전용 파드에 대한 엔드포인트를 올바르게 생성하도록 엔드포인트슬라이스컨트롤러가 수정되었다.
+
+  IPv6DualStack 기능 게이트가 활성화된 경우 서비스에서 
+  `ipFamily: IPv6` 을 지정하여 IPv6 헤드리스 서비스를 허용하도록
+  엔드포인트컨트롤러가 수정되었다. (이것은 이미 엔드포인트슬라이스컨트롤러와 함께 작동되었다.) ([#91399](https://github.com/kubernetes/kubernetes/pull/91399), [@danwinship](https://github.com/danwinship)) [SIG Apps 및 Network]
+- 여러 파드에서 읽기 전용 iSCSI 볼륨을 사용할 때 발생하는 문제가 수정되었다. ([#91738](https://github.com/kubernetes/kubernetes/pull/91738), [@jsafrane](https://github.com/jsafrane)) [SIG Storage 및 Testing]
+- 정보제공자(informer)를 사용하는 CSI 볼륨 첨부 스케일링의 문제가 수정되었다. ([#91307](https://github.com/kubernetes/kubernetes/pull/91307), [@yuga711](https://github.com/yuga711)) [SIG API Machinery, Apps, Node, Storage 및 Testing]
+- 스케일 하위리소스가 활성화된 사용자 지정 리소스 정의의 복제본 필드에 대한 기본값을 수정하는 버그가 수정되었다. ([#89833](https://github.com/kubernetes/kubernetes/pull/89833), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle 및 Instrumentation]
+- 디렉토리가 아닌 hostpath 타입이 HostPathFile로 인식될 수 있는 버그가 수정되었으며, HostPathType에 대한 e2e 테스트가 추가되었다. ([#64829](https://github.com/kubernetes/kubernetes/pull/64829), [@dixudx](https://github.com/dixudx)) [SIG Apps, Storage 및 Testing]
+- 1.16 에서 처음 널리 알려졌던, 일부 VXLAN-기반 네트워크 
+  플러그인에서 63-초 또는 1-초 연결 지연 문제가 수정되었다. 
+  (일부 사용자는 특정 네트워크 플러그인에서 이 문제를 더 일찍 확인했다.) 
+  이전에 ethtool 을 사용하여 기본 네트워크 인터페이스에서 체크섬 오프로드를 
+  비활성화한 경우 이제 그 작업을 중지할 수 있다. ([#92035](https://github.com/kubernetes/kubernetes/pull/92035), [@danwinship](https://github.com/danwinship)) [SIG Network 및 Node]
+- API 요청에서 캐시-제어 헤더가 삭제된 1.17 의 회귀문제가 수정되었다. ([#90468](https://github.com/kubernetes/kubernetes/pull/90468), [@liggitt](https://github.com/liggitt)) [SIG API Machinery 및 Testing]
+- 잘못된 주석이 있는 HorizontalPodAutoscaler 오브젝트의 변환 오류가 수정되었다. ([#89963](https://github.com/kubernetes/kubernetes/pull/89963), [@liggitt](https://github.com/liggitt)) [SIG Autoscaling]
+- 오류가 발생했을 경우, 중지하는 대신 올바르게 빌드된 모든 오브젝트에 적용하도록 kubectl 이 수정되었다. ([#89848](https://github.com/kubernetes/kubernetes/pull/89848), [@seans3](https://github.com/seans3)) [SIG CLI 및 Testing]
+- 부정확한 시간에 독점 CPU를 해제하는 CPUManager 의 회귀 문제가 수정되었다. ([#90377](https://github.com/kubernetes/kubernetes/pull/90377), [@cbf123](https://github.com/cbf123)) [SIG Cloud Provider 및 Node]
+- 초기화(init) 컨테이너로부터 상속된 앱 컨테이너에서 독점 CPU를 해제할 가능성이 거의 없는 CPUManager 의 회귀 문제가 수정되었다. ([#90419](https://github.com/kubernetes/kubernetes/pull/90419), [@klueska](https://github.com/klueska)) [SIG Node]
+- 로컬 및 원격 포트를 지정할 때 `kubectl port-forward` 에서 v1.18.0-rc.1 로의 회귀문제가 수정되었다. ([#89401](https://github.com/kubernetes/kubernetes/pull/89401), [@liggitt](https://github.com/liggitt))
+- 엔드포인트슬라이스 컨트롤러 가비지 수집에 대한 경합(race) 조건이 수정되었다. ([#91311](https://github.com/kubernetes/kubernetes/pull/91311), [@robscott](https://github.com/robscott)) [SIG Apps, Network 및 Testing]
+- GCE 클러스터 공급자의 경우, 단일 영역에서 노드가 1000 개 이상인 클러스터에 대해 내부 유형의 로드 밸런서를 만들수 없는 버그가 수정되었다. ([#89902](https://github.com/kubernetes/kubernetes/pull/89902), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network 및 Scalability]
+- 외부 스토리지 e2e 테스트 스위트(suite) 의 경우, VolumeSnapshotClass가 입력으로 명시적으로 제공되는 경우, VolumeSnapshotClass에서 스냅샷 프로비저닝 도구를 선택하도록 외부 드라이버가 변경되었다. ([#90878](https://github.com/kubernetes/kubernetes/pull/90878), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage 및 Testing]
+- Get-kube.sh: 올바른 버킷에서 바이너리를 가져오도록 순서가 수정되었다. ([#91635](https://github.com/kubernetes/kubernetes/pull/91635), [@cpanato](https://github.com/cpanato)) [SIG Release]
+- firstTimestamp가 설정되지 않은 경우 이벤트를 출력할 때, eventTime 을 사용하도록 수정되었다. ([#89999](https://github.com/kubernetes/kubernetes/pull/89999), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- 파라미터 cgroupPerQos=false 및 cgroupRoot=/docker 를 설정하면 이 함수는 nodeAllocatableRoot=/docker/kubepods 를 반환하는데 이는 옳지 않다. 올바른 반환은 /docker.cm.NodeAllocatableRoot(s.CgroupRoot, s.CgroupDriver)
+  이어야 한다.
+
+  kubeDeps.CAdvisorInterface, err = cadvisor.New(imageFsInfoProvider, s.RootDirectory, cgroupRoots, cadvisor.UsingLegacyCadvisorStats(s.ContainerRuntime, s.RemoteRuntimeEndpoint))
+  위 함수는 cgroupRoots를 사용하여 cadvisor 인터페이스를 만들 때, 잘못된 파라미터 cgroupRoots 로 인해 제거 관리자가 /docker 에서 메트릭을 수집하지 않도록 유도하고 kubelet은 이러한 오류를 자주 표시하게된다.
+  E0303 17:25:03.436781 63839 summary_sys_containers.go:47] Failed to get system container stats for "/docker": failed to get cgroup stats for "/docker": failed to get container info for "/docker": unknown container "/docker"
+  E0303 17:25:03.436809 63839 helpers.go:680] eviction manager: failed to construct signal: "allocatableMemory.available" error: system container "pods" not found in metrics ([#88970](https://github.com/kubernetes/kubernetes/pull/88970), [@mysunshine92](https://github.com/mysunshine92)) [SIG Node]
+- HA 환경에서, 대기 스케줄러가 API 서버와의 연결이 끊어진 기간 동안 파드를 삭제하고 다시 생성한 후 대기 스케줄러가 마스터가 되면 스케줄러 캐시가 손상될 수 있다. 이 PR은 이 문제를 해결한다. ([#91126](https://github.com/kubernetes/kubernetes/pull/91126), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- /metrics/resource 의 kubelet 리소스 메트릭 엔드포인트에서 다음 메트릭의 이름이 변경되었다.
+  - node_cpu_usage_seconds --> node_cpu_usage_seconds_total
+  - container_cpu_usage_seconds --> container_cpu_usage_seconds_total
+  이것은 1.18.0에서 추가된 &#35;86282의 부분적인 되돌리기이며, 처음에는 _total 접미사가 제거되었다. ([#89540](https://github.com/kubernetes/kubernetes/pull/89540), [@dashpole](https://github.com/dashpole)) [SIG Instrumentation 및 Node]
+- Ipvs: 지원되는 커널에서만 sysctlconnreuse 설정을 시도한다. ([#88541](https://github.com/kubernetes/kubernetes/pull/88541), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
+- kubectl/client-go의 Jsonpath 지원은 복잡한 유형(맵/슬라이스/구조체)을 Go-구문 대신 json으로 직렬화 한다. ([#89660](https://github.com/kubernetes/kubernetes/pull/89660), [@pjferrell](https://github.com/pjferrell)) [SIG API Machinery, CLI 및 Cluster Lifecycle]
+- Kube-aggregator 인증서는 디스크에서 변경시 동적으로 로드된다. ([#92791](https://github.com/kubernetes/kubernetes/pull/92791), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
+- Kube-apiserver: 불필요한 409 충돌 오류를 클라이언트에 반환하지 않도록 스케일 하위 리소스 패치 처리가 수정되었다. ([#90342](https://github.com/kubernetes/kubernetes/pull/90342), [@liggitt](https://github.com/liggitt)) [SIG Apps, Autoscaling 및 Testing]
+- Kube-apiserver: 연속적인 재귀 하강 연산자가 있는 jsonpath 표현식은 더 이상 사용자 정의 리소스 표시 열에 대해 해석되지 않는다. ([#93408](https://github.com/kubernetes/kubernetes/pull/93408), [@joelsmith](https://github.com/joelsmith)) [SIG API Machinery]
+- Kube-apiserver: 단일 X-Stream-Protocol-Version 헤더의 여러 쉼표로 구분된 프로토콜이 이제 RFC2616을 준수하는 여러 헤더와 함께 인식된다. ([#89857](https://github.com/kubernetes/kubernetes/pull/89857), [@tedyu](https://github.com/tedyu)) [SIG API Machinery]
+- Kube-proxy IP 군은 프록시가 사용하는 nodeIP에 의해 결정된다. 우선순위는:
+  1. 바인드 주소가 0.0.0.0 또는 ::가 아닌 경우 구성된 --bind-address 의 값
+  2. 설정된 경우, 노드 개체의 기본 IP
+  3. IP를 찾을 수 없는 경우, NodeIP 의 기본값은 127.0.0.1 이며 IP 군은 IPv4 이다. ([#91725](https://github.com/kubernetes/kubernetes/pull/91725), [@aojea](https://github.com/aojea)) [SIG Network]
+- 이중-스택 모드에서 Kube-proxy는 `Service.Spec.IPFamily` 필드를 사용하는 대신 ClusterIP에서 서비스 IP 계열을 유추한다. ([#91357](https://github.com/kubernetes/kubernetes/pull/91357), [@aojea](https://github.com/aojea))
+- 이제 Kube-up에 CoreDNS 버전 v1.7.0이 포함된다. 주요 변경 사항은 다음과 같다.
+  -  CoreDNS가 서비스 기록 업데이트를 중단할 수 있는 버그가 수정되었다.
+  -  어떤 정책이 설정되어도 항상 첫 번째 업스트림 서버만 선택되는 포워드 플러그인의 버그가 수정되었다.
+  -  쿠버네티스 플러그인에서 이미 사용 중단된 옵션 `resyncperiod` 및 `upstream` 가 제거되었다.
+  -  Prometheus 메트릭 이름 변경을 포함한다(표준 Prometheus 메트릭 명명 규칙에 맞게 변경). 이전 메트릭의 이름을 사용하는 기존 보고 공식과 역호환 된다.
+  -  페더레이션 플러그인 (v1 쿠버네티스 페더레이션 허용) 이 제거되었다.
+  자세한 내용은 https://coredns.io/2020/06/15/coredns-1.7.0-release/ 에서 확인할 수 있다. ([#92718](https://github.com/kubernetes/kubernetes/pull/92718), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cloud Provider]
+- Kube-up: 승인 웹훅 자격증명 구성의 확인 설정이 수정되었다. ([#91995](https://github.com/kubernetes/kubernetes/pull/91995), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider 및 Cluster Lifecycle]
+- Kubeadm의 TLS 부트스트랩 프로세스가 조인 시 완료되는 시간 제한이 5 분으로 증가하였다. ([#89735](https://github.com/kubernetes/kubernetes/pull/89735), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: 이 작업을 반복 재시도 함으로써, 업데이트 상태를 보다 탄력적으로 만들기 위하여, join / UpdateStatus에 대한 재시도를 추가하였다. ([#91952](https://github.com/kubernetes/kubernetes/pull/91952), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- Kubeadm: 안전하지 않은 서비스를 비활성화하기 위하여 사용 중단된 플래그인 --port=0 을 kube-controller-manager 및 kube-scheduler 매니페스트에 추가하였다. 이 플래그가 없으면 기본적으로 구성 요소(예: /metrics)가 (--adress에 의해 제어되는)기본노드 인터페이스에서 안전하지 않게 제공된다. 이 동작을 재정의하고 안전하지 않은 서비스를 활성화하려는 사용자의 경우, 이러한 구성 요소에 대한 kubeadm의 "extraArgs" 메커니즘을 통해 사용자 정의 포트로 --port=X 를 전달할 수 있다. ([#92720](https://github.com/kubernetes/kubernetes/pull/92720), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: "조인" 과정에서, 이미 클러스터에 존재하는 경우 etcd 구성원을 다시 추가하지 않는다. ([#92118](https://github.com/kubernetes/kubernetes/pull/92118), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: "리셋" 과정에서, 클러스터에 남아서 쌓여있는 etcd 멤버만 제거하지 않고, 로컬 etcd 스토리지의 정리를 계속 진행한다. ([#91145](https://github.com/kubernetes/kubernetes/pull/91145), [@tnqn](https://github.com/tnqn)) [SIG Cluster Lifecycle]
+- Kubeadm: 조인 중에 동일한 이름의 노드가 클러스터에 이미 존재하는지 확인하는 경우 NodeReady 조건이 올바르게 검증되었는지를 확인한다. ([#89602](https://github.com/kubernetes/kubernetes/pull/89602), [@kvaps](https://github.com/kvaps)) [SIG Cluster Lifecycle]
+- Kubeadm: 업그레이드 단계에서 `image-pull-timeout` 플래그가 준수되었는지 확인한다. ([#90328](https://github.com/kubernetes/kubernetes/pull/90328), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: 1.18.x로 업그레이드 후 RBAC 누락으로 인해 노드가 클러스터에 조인할 수 없는 버그가 수정되었다. ([#89537](https://github.com/kubernetes/kubernetes/pull/89537), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: 'kubeadm join'에서 컨트롤 플레인과 관련된 플래그 전달에 대한 잘못된 경고가 수정되었다. ([#89596](https://github.com/kubernetes/kubernetes/pull/89596), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: 느린 설정에서 etcd 멤버를 추가할 때 "kubeadm join" 에 대한 견고성이 향상되었다. ([#90645](https://github.com/kubernetes/kubernetes/pull/90645), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: 생성된 인증서에서 중복된 DNS 이름 및 IP 주소가 제거된다. ([#92753](https://github.com/kubernetes/kubernetes/pull/92753), [@QianChenglong](https://github.com/QianChenglong)) [SIG Cluster Lifecycle]
+- Kubectl azure 인증: 1.18.0에서 "spn:" 접두사가 예기치 않게 kubeconfig 파일의 `apiserver-id` 구성에 추가되는 회귀현상을 수정하였다. ([#89706](https://github.com/kubernetes/kubernetes/pull/89706), [@weinong](https://github.com/weinong)) [SIG API Machinery 및 Auth]
+- Kubectl: 오토스케일이 '--name' 플래그를 따르지 않던 버그가 수정되었다. ([#91855](https://github.com/kubernetes/kubernetes/pull/91855), [@SataQiu](https://github.com/SataQiu)) [SIG CLI]
+- Kubectl: kubectl scale이 '--timeout' 플래그를 따르지 않던 버그가 수정되었다. ([#91858](https://github.com/kubernetes/kubernetes/pull/91858), [@SataQiu](https://github.com/SataQiu)) [SIG CLI]
+- Kubelet: kubelet 도움말 정보가 올바른 유형의 플래그를 표시할 수 없던 버그가 수정되었다. ([#88515](https://github.com/kubernetes/kubernetes/pull/88515), [@SataQiu](https://github.com/SataQiu)) [SIG Docs 및 Node]
+- Kuberuntime 보안: 파드 샌드박스는 이제 항상 `runtime/default` seccomp 프로필로 실행된다.
+  kuberuntime seccomp: 사용자 정의 프로필은 이제 파드 수준에서 설정할 때 더 작은 seccomp 프로필을 가질 수 있다. ([#90949](https://github.com/kubernetes/kubernetes/pull/90949), [@pjbgf](https://github.com/pjbgf)) [SIG Node]
+- Kubelet 부트 스트랩 인증서 신호를 인식하게 되었다. ([#92786](https://github.com/kubernetes/kubernetes/pull/92786), [@answer1991](https://github.com/answer1991)) [SIG API Machinery, Auth 및 Node]
+- 노드 ([#89677](https://github.com/kubernetes/kubernetes/pull/89677), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- 여러 네트워크 인터페이스가 있는 AWS 노드에서, kubelet은 이제 보조 인터페이스의 주소를 보다 안정적으로 보고해야 한다. ([#91889](https://github.com/kubernetes/kubernetes/pull/91889), [@anguslees](https://github.com/anguslees)) [SIG Cloud Provider]
+- 리스케줄링 시도를 위한 파드의 조건 업데이트는 생략된다. ([#91252](https://github.com/kubernetes/kubernetes/pull/91252), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- 이제 이전에 지정된 노드가 예약 및 확인할 수 없게 된 후 파드를 선점 대상으로 고려할 수 있게 된다. ([#92604](https://github.com/kubernetes/kubernetes/pull/92604), [@soulxu](https://github.com/soulxu))
+- 볼륨을 확장하거나 생성할 때 PVC 요청크기에 대한 오버플로를 방지한다. ([#90907](https://github.com/kubernetes/kubernetes/pull/90907), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider 및 Storage]
+- 프라이빗 Azure 클라우드의 클러스터가 동일한 클라우드의 ACR에 인증할 수 있도록 수정을 허용한다. ([#90425](https://github.com/kubernetes/kubernetes/pull/90425), [@DavidParks8](https://github.com/DavidParks8)) [SIG Cloud Provider]
+- AWS 로드밸런서 워커 노드의 SG 규칙 논리를 결정적으로 변경하였다. ([#92224](https://github.com/kubernetes/kubernetes/pull/92224), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- 서버측 적용을 사용하지 않는 생성/업데이트/패치 요청에서 처리되는 metadata.managedFields의 회귀 문제가 해결되었다. ([#91690](https://github.com/kubernetes/kubernetes/pull/91690), [@apelisse](https://github.com/apelisse)) [SIG API Machinery 및 Testing]
+- 윈도우 볼륨을 마운트하는 v1.18.0-rc.1의 회귀 문제가 해결되었다. ([#89319](https://github.com/kubernetes/kubernetes/pull/89319), [@mboersma](https://github.com/mboersma)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation 및 Storage]
+- v1 CSR API를 제공하는 서버에 대해 `kubectl certificate approve/deny` 를 사용하는 문제가 해결되었다. ([#91691](https://github.com/kubernetes/kubernetes/pull/91691), [@liggitt](https://github.com/liggitt)) [SIG Auth 및 CLI]
+- --namespace 플래그 없이 `kubectl apply --prune` 기능이 복원되었다. 1.17부터 `kubectl apply --prune` 은 기본 네임스페이스(또는 kubeconfig에서) 또는 명령줄 플래그에 명시적으로 지정된 리소스만 제거하였다. 그러나 이것은 구성 파일의 모든 네임스페이스에서 리소스를 제거할 수 있는 kubectl 1.16의 변경사항을 호환되지 않는다. 이 패치는 kubectl 1.16 의 동작을 복원한다. ([#89551](https://github.com/kubernetes/kubernetes/pull/89551), [@tatsuhiro-t](https://github.com/tatsuhiro-t)) [SIG CLI 및 Testing]
+- 클러스터/gce/매니페스트의 컨트롤 플레인 매니페스트에서 정적 컨트롤 플레인 파드의 우선순위를 복원한다. ([#89970](https://github.com/kubernetes/kubernetes/pull/89970), [@liggitt](https://github.com/liggitt)) [SIG Cluster Lifecycle 및 Node]
+- 1.19-rc1에 추가된, 윈도우 노드를 위한 devicemanager 가 복귀되었다. ([#93263](https://github.com/kubernetes/kubernetes/pull/93263), [@liggitt](https://github.com/liggitt)) Node 및 Windows]
+- 스케줄러 v1 정책 구성 또는 알고리즘 제공 업체 설정을 v1beta1 컴포넌트컨피그(ComponentConfig)와 함께 전달하여 정책에서 CC로의 전환을 지원한다. ([#92531](https://github.com/kubernetes/kubernetes/pull/92531), [@damemi](https://github.com/damemi)) [SIG Scheduling]
+- 사용 가능한 노드가 없어서 발생하는 스케줄링 실패의 경우 이제 ```schedule_attempts_total``` 메트릭 하위에 스케줄링 불가능으로 보고된다. ([#90989](https://github.com/kubernetes/kubernetes/pull/90989), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- 이제 파드에 바인딩 된 서비스 어카운트 토큰을 파드 삭제 유예 기간 동안 사용할 수 있다. ([#89583](https://github.com/kubernetes/kubernetes/pull/89583), [@liggitt](https://github.com/liggitt)) [SIG Auth]
+- 서비스 로드 밸런서는 더 이상 스케줄링 불가능으로 표시된 노드를 후보 노드에서 제외하지 않는다. 대신 서비스 로드 밸런서 제외 레이블을 사용해야 한다.
+
+  코돈(cordon) 노드를 보유하고 있는 1.18 클러스터에서 업그레이드 하려는 사용자는, 해당 노드가 서비스 로드 밸런서에서 제외시키려 할 경우, 업그레이드 하기 전에 영향을 받는 노드에 `node.kubernetes.io/exclude-from-external-load-balancers` 레이블을 설정해야 한다. ([#90823](https://github.com/kubernetes/kubernetes/pull/90823), [@smarterclayton](https://github.com/smarterclayton)) [SIG Apps, Cloud Provider 및 Network]
+- kubectl annotate 명령어의 --list 옵션이 지원된다. ([#92576](https://github.com/kubernetes/kubernetes/pull/92576), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- 노드 추가/삭제 이벤트에서 서비스 `Type=LoadBalancer`에 대한 LB 백엔드 노드를 동기화한다. ([#81185](https://github.com/kubernetes/kubernetes/pull/81185), [@andrewsykim](https://github.com/andrewsykim))
+- 비어있지 않고, 인수가 필요하지 않는 다음의 구성요소는 이제 인수가 지정된 경우 오류 메세지를 출력하고 종료된다. cloud-controller-manager, kube-apiserver, kube-controller-manager, kube-proxy, kubeadm {alpha|config|token|version}, kubemark. 플래그는 짦은 형식의 경우 단일 대시 "-" (0x45), 긴 형식의 경우 이중 대시 "--"로 시작해야 한다. 이 변경 이전에는 잘못된 플래그 (예를 들어, 0x8211: "–" 와 같은 아스키가 아닌 대시문자로 시작)가 위치 인수로 처리되고 무시되었다. ([#91349](https://github.com/kubernetes/kubernetes/pull/91349), [@neolit123](https://github.com/neolit123)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle, Network 및 Scheduling]
+- 파드 사양의 terminationGracePeriodSeconds가 미러 파드에 적용된다. ([#92442](https://github.com/kubernetes/kubernetes/pull/92442), [@tedyu](https://github.com/tedyu)) [SIG Node 및 Testing]
+- 이전 커널과의 IPVS 호환성 문제를 해결하기 위해 github.com/moby/ipvs를 v1.0.1로 변경하였다. ([#90555](https://github.com/kubernetes/kubernetes/pull/90555), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
+- status 하위 리소스를 경유하는 파드의 상태 업데이트는 이제 `status.podIP` 및 `status.podIPs` 필드의 형식이 올바른지 확인한다. ([#90628](https://github.com/kubernetes/kubernetes/pull/90628), [@liggitt](https://github.com/liggitt)) [SIG 앱 및 Node]
+- 준비상태(readiness)를 보고하기 전에 모든 CRD는 디스커버리 엔드포인트가 확인될 때까지 기다린다. ([#89145](https://github.com/kubernetes/kubernetes/pull/89145), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- 파드를 제거할 때, PDB를 확인하지 않고 Pending 상태의 파드가 제거된다. ([#83906](https://github.com/kubernetes/kubernetes/pull/83906), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery, Apps, Node 및 Scheduling]
+- [보안] golang.org/x/text/encoding/unicode 의 취약성 ([#92219](https://github.com/kubernetes/kubernetes/pull/92219), [@voor](https://github.com/voor)) Cloud Provider, Cluster Lifecycle, Instrumentation 및 Node
+
+### 기타 (정리(Cleanup) or Flake(플레이크))
+
+- --cache-dir은 http 및 디스커버리 모두에 대해 캐시 디렉토리를 설정하며 기본값은 $HOME/.kube/cache이다. ([#92910](https://github.com/kubernetes/kubernetes/pull/92910), [@soltysh](https://github.com/soltysh)) [SIG API Machinery 및 CLI]
+- 이미지 로그에 `pod.Namespace` 가 추가되었다. ([#91945](https://github.com/kubernetes/kubernetes/pull/91945), [@zhipengzuo](https://github.com/zhipengzuo))
+- DISABLE_KUBECONFIG_LOCK 환경 변수를 통해 kubeconfig 파일 잠금을 비활성화 하는 기능이 추가되었다. ([#92513](https://github.com/kubernetes/kubernetes/pull/92513), [@soltysh](https://github.com/soltysh)) [SIG API Machinery 및 CLI]
+- udp 파드의 conntrack 모듈이 정리되었는지 확인하기 위한 별도의 테스트가 추가되었다. ([#90180](https://github.com/kubernetes/kubernetes/pull/90180), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Architecture, Network 및 Testing]
+- fsType이 지정되지 않은 경우, cinder 값의 fsType 을 `ext4` 로 조정한다. ([#90608](https://github.com/kubernetes/kubernetes/pull/90608), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
+- 베이스-이미지(base-image): debian-base:v2.1.0를 사용한다. ([#90697](https://github.com/kubernetes/kubernetes/pull/90697), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery 및 Release]
+- 베이스-이미지: debian-iptables:v12.1.0를 사용한다. ([#90782](https://github.com/kubernetes/kubernetes/pull/90782), [@justaugustus](https://github.com/justaugustus)) [SIG Release]
+- Beta.kubernetes.io/arch는 v1.14 이후 이미 사용 중단되었으며, v1.18은 제거 대상이다. ([#89462](https://github.com/kubernetes/kubernetes/pull/89462), [@wawa0210](https://github.com/wawa0210)) [SIG Testing]
+- 빌드: debian-base@v2.1.2 및 debian-iptables@v12.1.1로 변경되었다. ([#93667](https://github.com/kubernetes/kubernetes/pull/93667), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release 및 Testing]
+- beta.kubernetes.io/os를 kubernetes.io/os로 변경하였다. ([#89460](https://github.com/kubernetes/kubernetes/pull/89460), [@wawa0210](https://github.com/wawa0210)) [SIG Testing 및 Windows]
+- beta.kubernetes.io/os를 kubernetes.io/os로 변경하였다. ([#89461](https://github.com/kubernetes/kubernetes/pull/89461), [@wawa0210](https://github.com/wawa0210)) [SIG Cloud Provider 및 Cluster Lifecycle]
+- `kubectl get` 을 사용하여 네임스페이스가 지정되지 않는 리소스를 검색할 때, 리소스가 없을 때의 출력 메세지가 변경되었다. ([#89861](https://github.com/kubernetes/kubernetes/pull/89861), [@rccrdpccl](https://github.com/rccrdpccl)) [SIG CLI]
+- CoreDNS는 더 이상 kube-dns 컨피그맵에 대한 페더레이션 데이터 변환을 지원하지 않는다. ([#92716](https://github.com/kubernetes/kubernetes/pull/92716), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle]
+- 힙스터와 관련된 kubectl top 명령어의 플래그가 사용 중단 되었다.
+  kubectl top 에서 힙스터 지원이 중단 되었다. ([#87498](https://github.com/kubernetes/kubernetes/pull/87498), [@serathius](https://github.com/serathius)) [SIG CLI]
+- 더 이상 사용되지 않는 `--target-ram-md` 플래그가 사용 중단되었다. ([#91818](https://github.com/kubernetes/kubernetes/pull/91818), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- Kubelet API에 직접 의존하는 일부 적합성 테스트가 삭제되었다. ([#90615](https://github.com/kubernetes/kubernetes/pull/90615), [@dims](https://github.com/dims)) [SIG Architecture, Network, Release 및 Testing]
+- 바인딩 되지 않은 PVC가 지연 바인딩 모드에 있지만 파드에서 사용하는 경우, `WaitingForPodScheduled` 이벤트를 보내게 된다. ([#91455](https://github.com/kubernetes/kubernetes/pull/91455), [@cofyc](https://github.com/cofyc)) [SIG Storage]
+- 수정: blob 디스크 기능의 라이선스 문제 ([#92824](https://github.com/kubernetes/kubernetes/pull/92824), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- 전용 kubectl 하위명령어의 필드 관리자를 설정하여 서버측 적용의 충돌 오류를 개선하였다. ([#88885](https://github.com/kubernetes/kubernetes/pull/88885), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI 및 Testing]
+- IsFullyQualifiedDomainName()은 IsDNS1123Label을 기반으로 각 레이블의 유효성을 검사한다. ([#90172](https://github.com/kubernetes/kubernetes/pull/90172), [@nak3](https://github.com/nak3)) [SIG API Machinery 및 Network]
+- 이제 서비스 어노테이션 `cloud.google.com/network-tier: Standard` 을 사용하여 GCE 로드밸런서의 네트워크 등급을 구성할 수 있다. ([#88532](https://github.com/kubernetes/kubernetes/pull/88532), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider, Network 및 Testing]
+- Kube-aggregator: aggregator_unavailable_apiservice_count 메트릭의 이름을 aggregator_unavailable_apiservice_total로 변경하였다. ([#88156](https://github.com/kubernetes/kubernetes/pull/88156), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
+- Kube-apiserver: 사용자 정의 리소스 용으로 게시된 openapi 스키마는 이제 표준 ListMeta 스키마 정의를 참조한다. ([#92546](https://github.com/kubernetes/kubernetes/pull/92546), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- Kube-proxy는 kube-proxy에 대한 변경 사항이 적용되기 위해 대기열에 마지막으로 대기한 시간을 나타내는 새로운 메트릭인, `kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds` 를 노출해야 한다. ([#90175](https://github.com/kubernetes/kubernetes/pull/90175), [@squeed](https://github.com/squeed)) [SIG Instrumentation 및 Network]
+- Kube-scheduler: 메트릭 항목 `scheduler_total_preemption_attempts` 의 이름이 `scheduler_preemption_attempts_total` 로 변경되었다. ([#91448](https://github.com/kubernetes/kubernetes/pull/91448), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation 및 Scheduling]
+- Kube-up: 1.17 이전의 동작과 일치하도록 중요 파드를 kube-system 네임스페이스로 기본적으로 제한한다. ([#93121](https://github.com/kubernetes/kubernetes/pull/93121), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider 및 Scheduling]
+- Kubeadm은 이제 kubelet 명령줄 대신 kubelet 구성 요소 설정을 사용하여 IPv6DualStack 기능 게이트를 전달한다. ([#90840](https://github.com/kubernetes/kubernetes/pull/90840), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: "kubeadm upgrade apply" 중에 컨트롤 플레인 이미지를 미리 가져오기 위하여 데몬셋(DaemonSet)을 사용하지 않는다. 개별 노드의 업그레이드는 이제 사전 구동 검사를 하여 필요한 이미지를 가져온다. "kubeadm upgrade apply" 에 대한 "--image-pull-timeout" 플래그는 이제 사용 중단되었으며, GA 지원 중단 정책에 따라 향후 릴리스에서 제거된다. ([#90788](https://github.com/kubernetes/kubernetes/pull/90788), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- Kubeadm: /healthz 를 사용하는 대신 kube-apiserver의 스태틱(static) 파드에 대해 /livez 및 /readyz 에 대해 두 개의 개별 검사를 사용한다. ([#90970](https://github.com/kubernetes/kubernetes/pull/90970), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+- 없음 ([#91597](https://github.com/kubernetes/kubernetes/pull/91597), [@elmiko](https://github.com/elmiko)) [SIG Autoscaling 및 Testing]
+- Openapi-controller: 등급 제한 메트릭 `APIServiceOpenAPIAggregationControllerQueue1` 에서 후행의 `1` 문자리터럴을 제거하고, 프로메테우스의 모범 사례를 준수하도록 이름을 `open_api_aggregation_controller` 로 변경하였다. ([#77979](https://github.com/kubernetes/kubernetes/pull/77979), [@s-urbaniak](https://github.com/s-urbaniak)) [SIG API Machinery]
+- 볼륨 작동 오류시 이벤트 스팸이 감소하였다. ([#89794](https://github.com/kubernetes/kubernetes/pull/89794), [@msau42](https://github.com/msau42)) [SIG Storage]
+- 로컬 nodeipam 범위 할당자를 리팩토링하고 다음의 메트릭을 사용하여, 할당된 CIDR을 저장하는데 사용된 cidr집합을 계측한다.
+  "cidrset_cidrs_allocations_total",
+  "cidrset_cidrs_releases_total",
+  "cidrset_usage_cidrs",
+  "cidrset_allocation_tries_per_request", ([#90288](https://github.com/kubernetes/kubernetes/pull/90288), [@aojea](https://github.com/aojea)) [SIG 앱, Instrumentation, Network 및 확장성]
+- kubectl apply 명령어에서 사용 중단된 --server-dry-run 플래그가 제거되었다. ([#91308](https://github.com/kubernetes/kubernetes/pull/91308), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI 및 Testing]
+- 기능 게이트 DefaultPodTopologySpread와의 이름 충돌을 피하기 위해 DefaultPodTopologySpread 플러그인의 이름을 SelectorSpread 플러그인으로 변경하였다. ([#92501](https://github.com/kubernetes/kubernetes/pull/92501), [@rakeshreddybandi](https://github.com/rakeshreddybandi)) [SIG Release, Scheduling 및 Testing]
+- framework.Failf가 ExpectNoError로 변경되었다. ([#91811](https://github.com/kubernetes/kubernetes/pull/91811), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG Instrumentation, Storage 및 Testing]
+- 필터링 된 노드가 하나 이하인 경우, 스케줄러 PreScore 플러그인이 실행되지 않는다. ([#89370](https://github.com/kubernetes/kubernetes/pull/89370), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- "HostPath는 볼륨에 올바른 모드를 제공해야 한다."는 이제 적합성 테스트에서 제외된다. ([#90861](https://github.com/kubernetes/kubernetes/pull/90861), [@dims](https://github.com/dims)) [SIG Architecture 및 Testing]
+- Kubelet의 `--experimental-allocatable-ignore-eviction` 옵션은 이제 사용 중단된 것으로 표시된다. ([#91578](https://github.com/kubernetes/kubernetes/pull/91578), [@knabben](https://github.com/knabben)) [SIG Node]
+- Kubelet의 `--experimental-mounter-path` 및 `--experimental-check-node-capabilities-before-mount` 옵션은 이제 사용 중단된 것으로 표시된다. ([#91373](https://github.com/kubernetes/kubernetes/pull/91373), [@knabben](https://github.com/knabben))
+- PR은 PV 또는 PVC 처리에서 특정 실패가 발생할 때 이벤트를 생성하는 기능을 추가한다. 이 이벤트는 사용자가 사용 실패 이유를 파악하여 필요한 복구 조치를 취할 수 있도록 도와준다. ([#89845](https://github.com/kubernetes/kubernetes/pull/89845), [@yuga711](https://github.com/yuga711)) [SIG Apps]
+- PodShareProcessNamespace 기능 게이트가 제거되고, PodShareProcessNamespace 는 항상 활성화된다. ([#90099](https://github.com/kubernetes/kubernetes/pull/90099), [@tanjunchen](https://github.com/tanjunchen)) [SIG Node]
+- kube-apiserver의 `--kubelet-https` 플래그가 사용 중단 된다. kubelet에 대한 kube-apiserver의 연결은 이제 항상 `https` 를 사용한다. (kubelet은 v1.0 이전부터 apiserver가 통신하는 엔드포인트를 제공하기 위해 언제나 `https` 를 사용하였다.) ([#91630](https://github.com/kubernetes/kubernetes/pull/91630), [@liggitt](https://github.com/liggitt)) [SIG API Machinery 및 Node]
+- CNI가 v0.8.6로 변경되었다. ([#91370](https://github.com/kubernetes/kubernetes/pull/91370), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Release 및 Testing]
+- Golang이 v1.14.5로 변경되었다.
+  - Update repo-infra to 0.0.7 (go1.14.5 및 go1.13.13을 지원하기 위해)
+    - 포함:
+      - bazelbuild/bazel-toolchains@3.3.2
+      - bazelbuild/rules_go@v0.22.7 ([#93088](https://github.com/kubernetes/kubernetes/pull/93088), [@justaugustus](https://github.com/justaugustus)) [SIG Release 및 Testing]
+- Golang이 v1.14.6로 변경되었다.
+  - repo-infra가 0.0.8로 변경되었다. (go1.14.6 및 go1.13.14을 지원하기 위해)
+    - 포함:
+      - bazelbuild/bazel-toolchains@3.4.0
+      - bazelbuild/rules_go@v0.22.8 ([#93198](https://github.com/kubernetes/kubernetes/pull/93198), [@justaugustus](https://github.com/justaugustus)) [SIG Release 및 Testing]
+- corefile-migration 라이브러리가 1.0.8로 변경되었다. ([#91856](https://github.com/kubernetes/kubernetes/pull/91856), [@wawa0210](https://github.com/wawa0210)) [SIG Node]
+- 기본 etcd 서버 버전이 3.4.4로 변경되었다. ([#89214](https://github.com/kubernetes/kubernetes/pull/89214), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle 및 Testing]
+- 기본 etcd 서버 버전이 3.4.7로 변경되었다. ([#89895](https://github.com/kubernetes/kubernetes/pull/89895), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle 및 Testing]
+- 기본 etcd 서버 버전이 3.4.9로 변경되었다. ([#92349](https://github.com/kubernetes/kubernetes/pull/92349), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle 및 Testing]
+- go.etcd.io/bbolt가 v1.3.5로 변경되었다. ([#92350](https://github.com/kubernetes/kubernetes/pull/92350), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery 및 Cloud Provider]
+- opencontainers/runtime-spec 의존성이 v1.0.2로 변경되었다. ([#89644](https://github.com/kubernetes/kubernetes/pull/89644), [@saschagrunert](https://github.com/saschagrunert)) [SIG Node]
+- `beta.kubernetes.io/os` 및 `beta.kubernetes.io/arch` 노드 레이블은 사용 중단되었다. `kubernetes.io/os` 및 `kubernetes.io/arch` 를 사용하도록 노드 셀렉터를 변경해야한다. ([#91046](https://github.com/kubernetes/kubernetes/pull/91046), [@wawa0210](https://github.com/wawa0210)) [SIG Apps 및 Node]
+- `kubectl config view` 는 이제 클라이언트 인증서와 유사하게 기본적으로 베어러 토큰을 수정한다. `--raw` 플래그는 여전히 전체 컨텐츠를 출력하는데 사용될 수 있다. ([#88985](https://github.com/kubernetes/kubernetes/pull/88985), [@puerco](https://github.com/puerco))
+
+## 의존성
+
+### 추가
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/checkpoint-restore/go-criu/v4: [v4.0.2](https://github.com/checkpoint-restore/go-criu/v4/tree/v4.0.2)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/containerd/cgroups: [0dbf7f0](https://github.com/containerd/cgroups/tree/0dbf7f0)
+- github.com/containerd/continuity: [aaeac12](https://github.com/containerd/continuity/tree/aaeac12)
+- github.com/containerd/fifo: [a9fb20d](https://github.com/containerd/fifo/tree/a9fb20d)
+- github.com/containerd/go-runc: [5a6d9f3](https://github.com/containerd/go-runc/tree/5a6d9f3)
+- github.com/containerd/ttrpc: [v1.0.0](https://github.com/containerd/ttrpc/tree/v1.0.0)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/coreos/go-systemd/v22: [v22.1.0](https://github.com/coreos/go-systemd/v22/tree/v22.1.0)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/docopt/docopt-go: [ee0de3b](https://github.com/docopt/docopt-go/tree/ee0de3b)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0)
+- github.com/godbus/dbus/v5: [v5.0.3](https://github.com/godbus/dbus/v5/tree/v5.0.3)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/ishidawataru/sctp: [7c296d4](https://github.com/ishidawataru/sctp/tree/7c296d4)
+- github.com/moby/ipvs: [v1.0.1](https://github.com/moby/ipvs/tree/v1.0.1)
+- github.com/moby/sys/mountinfo: [v0.1.3](https://github.com/moby/sys/mountinfo/tree/v0.1.3)
+- github.com/moby/term: [672ec06](https://github.com/moby/term/tree/672ec06)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27)
+- google.golang.org/protobuf: v1.24.0
+- gotest.tools/v3: v3.0.2
+- k8s.io/klog/v2: v2.2.0
+
+### 변경
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/Azure/azure-sdk-for-go: [v35.0.0+incompatible → v43.0.0+incompatible](https://github.com/Azure/azure-sdk-for-go/compare/v35.0.0...v43.0.0)
+- github.com/Azure/go-autorest/autorest/adal: [v0.5.0 → v0.8.2](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.5.0...v0.8.2)
+- github.com/Azure/go-autorest/autorest/date: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.1.0...v0.2.0)
+- github.com/Azure/go-autorest/autorest/mocks: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.2.0...v0.3.0)
+- github.com/Azure/go-autorest/autorest: [v0.9.0 → v0.9.6](https://github.com/Azure/go-autorest/autorest/compare/v0.9.0...v0.9.6)
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/Microsoft/go-winio: [v0.4.14 → fc70bd9](https://github.com/Microsoft/go-winio/compare/v0.4.14...fc70bd9)
+- github.com/Microsoft/hcsshim: [672e52e → 5eafd15](https://github.com/Microsoft/hcsshim/compare/672e52e...5eafd15)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/cilium/ebpf: [95b36a5 → 1c8d4c9](https://github.com/cilium/ebpf/compare/95b36a5...1c8d4c9)
+- github.com/containerd/console: [84eeaae → v1.0.0](https://github.com/containerd/console/compare/84eeaae...v1.0.0)
+- github.com/containerd/containerd: [v1.0.2 → v1.3.3](https://github.com/containerd/containerd/compare/v1.0.2...v1.3.3)
+- github.com/containerd/typeurl: [2a93cfd → v1.0.0](https://github.com/containerd/typeurl/compare/2a93cfd...v1.0.0)
+- github.com/containernetworking/cni: [v0.7.1 → v0.8.0](https://github.com/containernetworking/cni/compare/v0.7.1...v0.8.0)
+- github.com/coredns/corefile-migration: [v1.0.6 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.6...v1.0.10)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/docker/docker: [be7ac8b → aa6a989](https://github.com/docker/docker/compare/be7ac8b...aa6a989)
+- github.com/docker/go-connections: [v0.3.0 → v0.4.0](https://github.com/docker/go-connections/compare/v0.3.0...v0.4.0)
+- github.com/evanphx/json-patch: [v4.2.0+incompatible → e83c0a1](https://github.com/evanphx/json-patch/compare/v4.2.0...e83c0a1)
+- github.com/fsnotify/fsnotify: [v1.4.7 → v1.4.9](https://github.com/fsnotify/fsnotify/compare/v1.4.7...v1.4.9)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/go-logr/logr: [v0.1.0 → v0.2.0](https://github.com/go-logr/logr/compare/v0.1.0...v0.2.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.2 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.2...v1.4.2)
+- github.com/google/cadvisor: [v0.35.0 → v0.37.0](https://github.com/google/cadvisor/compare/v0.35.0...v0.37.0)
+- github.com/google/go-cmp: [v0.3.0 → v0.4.0](https://github.com/google/go-cmp/compare/v0.3.0...v0.4.0)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/googleapis/gnostic: [v0.1.0 → v0.4.1](https://github.com/googleapis/gnostic/compare/v0.1.0...v0.4.1)
+- github.com/gorilla/mux: [v1.7.0 → v1.7.3](https://github.com/gorilla/mux/compare/v1.7.0...v1.7.3)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.10)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/konsorten/go-windows-terminal-sequences: [v1.0.1 → v1.0.3](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.1...v1.0.3)
+- github.com/kr/pretty: [v0.1.0 → v0.2.0](https://github.com/kr/pretty/compare/v0.1.0...v0.2.0)
+- github.com/mattn/go-isatty: [v0.0.9 → v0.0.4](https://github.com/mattn/go-isatty/compare/v0.0.9...v0.0.4)
+- github.com/matttproud/golang_protobuf_extensions: [v1.0.1 → c182aff](https://github.com/matttproud/golang_protobuf_extensions/compare/v1.0.1...c182aff)
+- github.com/mistifyio/go-zfs: [v2.1.1+incompatible → f784269](https://github.com/mistifyio/go-zfs/compare/v2.1.1...f784269)
+- github.com/mrunalp/fileutils: [7d4729f → abd8a0e](https://github.com/mrunalp/fileutils/compare/7d4729f...abd8a0e)
+- github.com/opencontainers/runc: [v1.0.0-rc10 → 819fcc6](https://github.com/opencontainers/runc/compare/v1.0.0-rc10...819fcc6)
+- github.com/opencontainers/runtime-spec: [v1.0.0 → 237cc4f](https://github.com/opencontainers/runtime-spec/compare/v1.0.0...237cc4f)
+- github.com/opencontainers/selinux: [5215b18 → v1.5.2](https://github.com/opencontainers/selinux/compare/5215b18...v1.5.2)
+- github.com/pkg/errors: [v0.8.1 → v0.9.1](https://github.com/pkg/errors/compare/v0.8.1...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.7.1)
+- github.com/prometheus/common: [v0.4.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.4.1...v0.10.0)
+- github.com/prometheus/procfs: [v0.0.2 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.2...v0.1.3)
+- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102)
+- github.com/sirupsen/logrus: [v1.4.2 → v1.6.0](https://github.com/sirupsen/logrus/compare/v1.4.2...v1.6.0)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- github.com/urfave/cli: [v1.20.0 → v1.22.2](https://github.com/urfave/cli/compare/v1.20.0...v1.22.2)
+- github.com/vishvananda/netlink: [v1.0.0 → v1.1.0](https://github.com/vishvananda/netlink/compare/v1.0.0...v1.1.0)
+- github.com/vishvananda/netns: [be1fbed → 52d707b](https://github.com/vishvananda/netns/compare/be1fbed...52d707b)
+- go.etcd.io/bbolt: v1.3.3 → v1.3.5
+- go.etcd.io/etcd: 3cf2f69 → 18dfb9c
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/crypto: bac4c82 → 75b2880
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/mod: 4bf6d31 → v0.3.0
+- golang.org/x/net: 13f9640 → ab34263
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- golang.org/x/sys: fde4db3 → ed371f2
+- golang.org/x/text: v0.3.2 → v0.3.3
+- golang.org/x/time: 9d24e82 → 555d28b
+- golang.org/x/tools: 65e3620 → c1934b7
+- golang.org/x/xerrors: a985d34 → 9bdfabe
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: 24fa4b2 → cb27e3a
+- google.golang.org/grpc: v1.26.0 → v1.27.0
+- gopkg.in/check.v1: 788fd78 → 41f04d3
+- honnef.co/go/tools: v0.0.1-2019.2.2 → v0.0.1-2019.2.3
+- k8s.io/gengo: 36b2048 → 8167cfd
+- k8s.io/kube-openapi: bf4fb3b → 656914f
+- k8s.io/system-validators: v1.0.4 → v1.1.2
+- k8s.io/utils: 0a110f9 → d5654de
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → v0.0.9
+- sigs.k8s.io/structured-merge-diff/v3: v3.0.0 → 43c19bb
+
+### 제거
+- github.com/OpenPeeDeeP/depguard: [v1.0.1](https://github.com/OpenPeeDeeP/depguard/tree/v1.0.1)
+- github.com/Rican7/retry: [v0.1.0](https://github.com/Rican7/retry/tree/v0.1.0)
+- github.com/StackExchange/wmi: [5d04971](https://github.com/StackExchange/wmi/tree/5d04971)
+- github.com/anmitsu/go-shlex: [648efa6](https://github.com/anmitsu/go-shlex/tree/648efa6)
+- github.com/bazelbuild/bazel-gazelle: [70208cb](https://github.com/bazelbuild/bazel-gazelle/tree/70208cb)
+- github.com/bazelbuild/buildtools: [69366ca](https://github.com/bazelbuild/buildtools/tree/69366ca)
+- github.com/bazelbuild/rules_go: [6dae44d](https://github.com/bazelbuild/rules_go/tree/6dae44d)
+- github.com/bradfitz/go-smtpd: [deb6d62](https://github.com/bradfitz/go-smtpd/tree/deb6d62)
+- github.com/cespare/prettybench: [03b8cfe](https://github.com/cespare/prettybench/tree/03b8cfe)
+- github.com/checkpoint-restore/go-criu: [17b0214](https://github.com/checkpoint-restore/go-criu/tree/17b0214)
+- github.com/client9/misspell: [v0.3.4](https://github.com/client9/misspell/tree/v0.3.4)
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/cpuguy83/go-md2man: [v1.0.10](https://github.com/cpuguy83/go-md2man/tree/v1.0.10)
+- github.com/docker/libnetwork: [c8a5fca](https://github.com/docker/libnetwork/tree/c8a5fca)
+- github.com/gliderlabs/ssh: [v0.1.1](https://github.com/gliderlabs/ssh/tree/v0.1.1)
+- github.com/go-critic/go-critic: [1df3008](https://github.com/go-critic/go-critic/tree/1df3008)
+- github.com/go-lintpack/lintpack: [v0.5.2](https://github.com/go-lintpack/lintpack/tree/v0.5.2)
+- github.com/go-ole/go-ole: [v1.2.1](https://github.com/go-ole/go-ole/tree/v1.2.1)
+- github.com/go-toolsmith/astcast: [v1.0.0](https://github.com/go-toolsmith/astcast/tree/v1.0.0)
+- github.com/go-toolsmith/astcopy: [v1.0.0](https://github.com/go-toolsmith/astcopy/tree/v1.0.0)
+- github.com/go-toolsmith/astequal: [v1.0.0](https://github.com/go-toolsmith/astequal/tree/v1.0.0)
+- github.com/go-toolsmith/astfmt: [v1.0.0](https://github.com/go-toolsmith/astfmt/tree/v1.0.0)
+- github.com/go-toolsmith/astinfo: [9809ff7](https://github.com/go-toolsmith/astinfo/tree/9809ff7)
+- github.com/go-toolsmith/astp: [v1.0.0](https://github.com/go-toolsmith/astp/tree/v1.0.0)
+- github.com/go-toolsmith/pkgload: [v1.0.0](https://github.com/go-toolsmith/pkgload/tree/v1.0.0)
+- github.com/go-toolsmith/strparse: [v1.0.0](https://github.com/go-toolsmith/strparse/tree/v1.0.0)
+- github.com/go-toolsmith/typep: [v1.0.0](https://github.com/go-toolsmith/typep/tree/v1.0.0)
+- github.com/gobwas/glob: [v0.2.3](https://github.com/gobwas/glob/tree/v0.2.3)
+- github.com/godbus/dbus: [2ff6f7f](https://github.com/godbus/dbus/tree/2ff6f7f)
+- github.com/golangci/check: [cfe4005](https://github.com/golangci/check/tree/cfe4005)
+- github.com/golangci/dupl: [3e9179a](https://github.com/golangci/dupl/tree/3e9179a)
+- github.com/golangci/errcheck: [ef45e06](https://github.com/golangci/errcheck/tree/ef45e06)
+- github.com/golangci/go-misc: [927a3d8](https://github.com/golangci/go-misc/tree/927a3d8)
+- github.com/golangci/go-tools: [e32c541](https://github.com/golangci/go-tools/tree/e32c541)
+- github.com/golangci/goconst: [041c5f2](https://github.com/golangci/goconst/tree/041c5f2)
+- github.com/golangci/gocyclo: [2becd97](https://github.com/golangci/gocyclo/tree/2becd97)
+- github.com/golangci/gofmt: [0b8337e](https://github.com/golangci/gofmt/tree/0b8337e)
+- github.com/golangci/golangci-lint: [v1.18.0](https://github.com/golangci/golangci-lint/tree/v1.18.0)
+- github.com/golangci/gosec: [66fb7fc](https://github.com/golangci/gosec/tree/66fb7fc)
+- github.com/golangci/ineffassign: [42439a7](https://github.com/golangci/ineffassign/tree/42439a7)
+- github.com/golangci/lint-1: [ee948d0](https://github.com/golangci/lint-1/tree/ee948d0)
+- github.com/golangci/maligned: [b1d8939](https://github.com/golangci/maligned/tree/b1d8939)
+- github.com/golangci/misspell: [950f5d1](https://github.com/golangci/misspell/tree/950f5d1)
+- github.com/golangci/prealloc: [215b22d](https://github.com/golangci/prealloc/tree/215b22d)
+- github.com/golangci/revgrep: [d9c87f5](https://github.com/golangci/revgrep/tree/d9c87f5)
+- github.com/golangci/unconvert: [28b1c44](https://github.com/golangci/unconvert/tree/28b1c44)
+- github.com/google/go-github: [v17.0.0+incompatible](https://github.com/google/go-github/tree/v17.0.0)
+- github.com/google/go-querystring: [v1.0.0](https://github.com/google/go-querystring/tree/v1.0.0)
+- github.com/gostaticanalysis/analysisutil: [v0.0.3](https://github.com/gostaticanalysis/analysisutil/tree/v0.0.3)
+- github.com/jellevandenhooff/dkim: [f50fe3d](https://github.com/jellevandenhooff/dkim/tree/f50fe3d)
+- github.com/klauspost/compress: [v1.4.1](https://github.com/klauspost/compress/tree/v1.4.1)
+- github.com/logrusorgru/aurora: [a7b3b31](https://github.com/logrusorgru/aurora/tree/a7b3b31)
+- github.com/mattn/go-shellwords: [v1.0.5](https://github.com/mattn/go-shellwords/tree/v1.0.5)
+- github.com/mattn/goveralls: [v0.0.2](https://github.com/mattn/goveralls/tree/v0.0.2)
+- github.com/mesos/mesos-go: [v0.0.9](https://github.com/mesos/mesos-go/tree/v0.0.9)
+- github.com/mitchellh/go-ps: [4fdf99a](https://github.com/mitchellh/go-ps/tree/4fdf99a)
+- github.com/mozilla/tls-observatory: [8791a20](https://github.com/mozilla/tls-observatory/tree/8791a20)
+- github.com/nbutton23/zxcvbn-go: [eafdab6](https://github.com/nbutton23/zxcvbn-go/tree/eafdab6)
+- github.com/pquerna/ffjson: [af8b230](https://github.com/pquerna/ffjson/tree/af8b230)
+- github.com/quasilyte/go-consistent: [c6f3937](https://github.com/quasilyte/go-consistent/tree/c6f3937)
+- github.com/ryanuber/go-glob: [256dc44](https://github.com/ryanuber/go-glob/tree/256dc44)
+- github.com/shirou/gopsutil: [c95755e](https://github.com/shirou/gopsutil/tree/c95755e)
+- github.com/shirou/w32: [bb4de01](https://github.com/shirou/w32/tree/bb4de01)
+- github.com/shurcooL/go-goon: [37c2f52](https://github.com/shurcooL/go-goon/tree/37c2f52)
+- github.com/shurcooL/go: [9e1955d](https://github.com/shurcooL/go/tree/9e1955d)
+- github.com/sourcegraph/go-diff: [v0.5.1](https://github.com/sourcegraph/go-diff/tree/v0.5.1)
+- github.com/tarm/serial: [98f6abe](https://github.com/tarm/serial/tree/98f6abe)
+- github.com/timakin/bodyclose: [87058b9](https://github.com/timakin/bodyclose/tree/87058b9)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- github.com/ultraware/funlen: [v0.0.2](https://github.com/ultraware/funlen/tree/v0.0.2)
+- github.com/valyala/bytebufferpool: [v1.0.0](https://github.com/valyala/bytebufferpool/tree/v1.0.0)
+- github.com/valyala/fasthttp: [v1.2.0](https://github.com/valyala/fasthttp/tree/v1.2.0)
+- github.com/valyala/quicktemplate: [v1.1.1](https://github.com/valyala/quicktemplate/tree/v1.1.1)
+- github.com/valyala/tcplisten: [ceec8f9](https://github.com/valyala/tcplisten/tree/ceec8f9)
+- go4.org: 417644f
+- golang.org/x/build: 2835ba2
+- golang.org/x/perf: 6e6d33e
+- gopkg.in/airbrake/gobrake.v2: v2.0.9
+- gopkg.in/gemnasium/logrus-airbrake-hook.v2: v2.1.2
+- gotest.tools/gotestsum: v0.3.5
+- grpc.go4.org: 11d0a25
+- k8s.io/klog: v1.0.0
+- k8s.io/repo-infra: v0.0.1-alpha.1
+- mvdan.cc/interfacer: c200402
+- mvdan.cc/lint: adc824a
+- mvdan.cc/unparam: fbb5962
+- sourcegraph.com/sqs/pbtypes: d3ebe8f
+
+
+## 의존성
+
+### 추가
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/checkpoint-restore/go-criu/v4: [v4.0.2](https://github.com/checkpoint-restore/go-criu/v4/tree/v4.0.2)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/containerd/cgroups: [0dbf7f0](https://github.com/containerd/cgroups/tree/0dbf7f0)
+- github.com/containerd/continuity: [aaeac12](https://github.com/containerd/continuity/tree/aaeac12)
+- github.com/containerd/fifo: [a9fb20d](https://github.com/containerd/fifo/tree/a9fb20d)
+- github.com/containerd/go-runc: [5a6d9f3](https://github.com/containerd/go-runc/tree/5a6d9f3)
+- github.com/containerd/ttrpc: [v1.0.0](https://github.com/containerd/ttrpc/tree/v1.0.0)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/coreos/go-systemd/v22: [v22.1.0](https://github.com/coreos/go-systemd/v22/tree/v22.1.0)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/docopt/docopt-go: [ee0de3b](https://github.com/docopt/docopt-go/tree/ee0de3b)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0)
+- github.com/godbus/dbus/v5: [v5.0.3](https://github.com/godbus/dbus/v5/tree/v5.0.3)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/ishidawataru/sctp: [7c296d4](https://github.com/ishidawataru/sctp/tree/7c296d4)
+- github.com/moby/ipvs: [v1.0.1](https://github.com/moby/ipvs/tree/v1.0.1)
+- github.com/moby/sys/mountinfo: [v0.1.3](https://github.com/moby/sys/mountinfo/tree/v0.1.3)
+- github.com/moby/term: [672ec06](https://github.com/moby/term/tree/672ec06)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27)
+- google.golang.org/protobuf: v1.24.0
+- gotest.tools/v3: v3.0.2
+- k8s.io/klog/v2: v2.2.0
+- sigs.k8s.io/structured-merge-diff/v4: v4.0.1
+
+### 변경
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/Azure/azure-sdk-for-go: [v35.0.0+incompatible → v43.0.0+incompatible](https://github.com/Azure/azure-sdk-for-go/compare/v35.0.0...v43.0.0)
+- github.com/Azure/go-autorest/autorest/adal: [v0.5.0 → v0.8.2](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.5.0...v0.8.2)
+- github.com/Azure/go-autorest/autorest/date: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.1.0...v0.2.0)
+- github.com/Azure/go-autorest/autorest/mocks: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.2.0...v0.3.0)
+- github.com/Azure/go-autorest/autorest: [v0.9.0 → v0.9.6](https://github.com/Azure/go-autorest/autorest/compare/v0.9.0...v0.9.6)
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/Microsoft/go-winio: [v0.4.14 → fc70bd9](https://github.com/Microsoft/go-winio/compare/v0.4.14...fc70bd9)
+- github.com/Microsoft/hcsshim: [672e52e → 5eafd15](https://github.com/Microsoft/hcsshim/compare/672e52e...5eafd15)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/cilium/ebpf: [95b36a5 → 1c8d4c9](https://github.com/cilium/ebpf/compare/95b36a5...1c8d4c9)
+- github.com/containerd/console: [84eeaae → v1.0.0](https://github.com/containerd/console/compare/84eeaae...v1.0.0)
+- github.com/containerd/containerd: [v1.0.2 → v1.3.3](https://github.com/containerd/containerd/compare/v1.0.2...v1.3.3)
+- github.com/containerd/typeurl: [2a93cfd → v1.0.0](https://github.com/containerd/typeurl/compare/2a93cfd...v1.0.0)
+- github.com/containernetworking/cni: [v0.7.1 → v0.8.0](https://github.com/containernetworking/cni/compare/v0.7.1...v0.8.0)
+- github.com/coredns/corefile-migration: [v1.0.6 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.6...v1.0.10)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/docker/docker: [be7ac8b → aa6a989](https://github.com/docker/docker/compare/be7ac8b...aa6a989)
+- github.com/docker/go-connections: [v0.3.0 → v0.4.0](https://github.com/docker/go-connections/compare/v0.3.0...v0.4.0)
+- github.com/evanphx/json-patch: [v4.2.0+incompatible → v4.9.0+incompatible](https://github.com/evanphx/json-patch/compare/v4.2.0...v4.9.0)
+- github.com/fsnotify/fsnotify: [v1.4.7 → v1.4.9](https://github.com/fsnotify/fsnotify/compare/v1.4.7...v1.4.9)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/go-logr/logr: [v0.1.0 → v0.2.0](https://github.com/go-logr/logr/compare/v0.1.0...v0.2.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.2 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.2...v1.4.2)
+- github.com/google/cadvisor: [v0.35.0 → v0.37.0](https://github.com/google/cadvisor/compare/v0.35.0...v0.37.0)
+- github.com/google/go-cmp: [v0.3.0 → v0.4.0](https://github.com/google/go-cmp/compare/v0.3.0...v0.4.0)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/googleapis/gnostic: [v0.1.0 → v0.4.1](https://github.com/googleapis/gnostic/compare/v0.1.0...v0.4.1)
+- github.com/gorilla/mux: [v1.7.0 → v1.7.3](https://github.com/gorilla/mux/compare/v1.7.0...v1.7.3)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.10)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/konsorten/go-windows-terminal-sequences: [v1.0.1 → v1.0.3](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.1...v1.0.3)
+- github.com/kr/pretty: [v0.1.0 → v0.2.0](https://github.com/kr/pretty/compare/v0.1.0...v0.2.0)
+- github.com/mattn/go-isatty: [v0.0.9 → v0.0.4](https://github.com/mattn/go-isatty/compare/v0.0.9...v0.0.4)
+- github.com/matttproud/golang_protobuf_extensions: [v1.0.1 → c182aff](https://github.com/matttproud/golang_protobuf_extensions/compare/v1.0.1...c182aff)
+- github.com/mistifyio/go-zfs: [v2.1.1+incompatible → f784269](https://github.com/mistifyio/go-zfs/compare/v2.1.1...f784269)
+- github.com/mrunalp/fileutils: [7d4729f → abd8a0e](https://github.com/mrunalp/fileutils/compare/7d4729f...abd8a0e)
+- github.com/opencontainers/runc: [v1.0.0-rc10 → 819fcc6](https://github.com/opencontainers/runc/compare/v1.0.0-rc10...819fcc6)
+- github.com/opencontainers/runtime-spec: [v1.0.0 → 237cc4f](https://github.com/opencontainers/runtime-spec/compare/v1.0.0...237cc4f)
+- github.com/opencontainers/selinux: [5215b18 → v1.5.2](https://github.com/opencontainers/selinux/compare/5215b18...v1.5.2)
+- github.com/pkg/errors: [v0.8.1 → v0.9.1](https://github.com/pkg/errors/compare/v0.8.1...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.7.1)
+- github.com/prometheus/common: [v0.4.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.4.1...v0.10.0)
+- github.com/prometheus/procfs: [v0.0.2 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.2...v0.1.3)
+- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102)
+- github.com/sirupsen/logrus: [v1.4.2 → v1.6.0](https://github.com/sirupsen/logrus/compare/v1.4.2...v1.6.0)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- github.com/urfave/cli: [v1.20.0 → v1.22.2](https://github.com/urfave/cli/compare/v1.20.0...v1.22.2)
+- github.com/vishvananda/netlink: [v1.0.0 → v1.1.0](https://github.com/vishvananda/netlink/compare/v1.0.0...v1.1.0)
+- github.com/vishvananda/netns: [be1fbed → 52d707b](https://github.com/vishvananda/netns/compare/be1fbed...52d707b)
+- go.etcd.io/bbolt: v1.3.3 → v1.3.5
+- go.etcd.io/etcd: 3cf2f69 → 17cef6e
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/crypto: bac4c82 → 75b2880
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/mod: 4bf6d31 → v0.3.0
+- golang.org/x/net: 13f9640 → ab34263
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- golang.org/x/sys: fde4db3 → ed371f2
+- golang.org/x/text: v0.3.2 → v0.3.3
+- golang.org/x/time: 9d24e82 → 555d28b
+- golang.org/x/tools: 65e3620 → c1934b7
+- golang.org/x/xerrors: a985d34 → 9bdfabe
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: 24fa4b2 → cb27e3a
+- google.golang.org/grpc: v1.26.0 → v1.27.0
+- gopkg.in/check.v1: 788fd78 → 41f04d3
+- honnef.co/go/tools: v0.0.1-2019.2.2 → v0.0.1-2019.2.3
+- k8s.io/gengo: 36b2048 → 8167cfd
+- k8s.io/kube-openapi: bf4fb3b → 6aeccd4
+- k8s.io/system-validators: v1.0.4 → v1.1.2
+- k8s.io/utils: a9aa75a → d5654de
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → v0.0.9
+
+### 제거
+- github.com/OpenPeeDeeP/depguard: [v1.0.1](https://github.com/OpenPeeDeeP/depguard/tree/v1.0.1)
+- github.com/Rican7/retry: [v0.1.0](https://github.com/Rican7/retry/tree/v0.1.0)
+- github.com/StackExchange/wmi: [5d04971](https://github.com/StackExchange/wmi/tree/5d04971)
+- github.com/anmitsu/go-shlex: [648efa6](https://github.com/anmitsu/go-shlex/tree/648efa6)
+- github.com/bazelbuild/bazel-gazelle: [70208cb](https://github.com/bazelbuild/bazel-gazelle/tree/70208cb)
+- github.com/bazelbuild/buildtools: [69366ca](https://github.com/bazelbuild/buildtools/tree/69366ca)
+- github.com/bazelbuild/rules_go: [6dae44d](https://github.com/bazelbuild/rules_go/tree/6dae44d)
+- github.com/bradfitz/go-smtpd: [deb6d62](https://github.com/bradfitz/go-smtpd/tree/deb6d62)
+- github.com/cespare/prettybench: [03b8cfe](https://github.com/cespare/prettybench/tree/03b8cfe)
+- github.com/checkpoint-restore/go-criu: [17b0214](https://github.com/checkpoint-restore/go-criu/tree/17b0214)
+- github.com/client9/misspell: [v0.3.4](https://github.com/client9/misspell/tree/v0.3.4)
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/cpuguy83/go-md2man: [v1.0.10](https://github.com/cpuguy83/go-md2man/tree/v1.0.10)
+- github.com/docker/libnetwork: [c8a5fca](https://github.com/docker/libnetwork/tree/c8a5fca)
+- github.com/gliderlabs/ssh: [v0.1.1](https://github.com/gliderlabs/ssh/tree/v0.1.1)
+- github.com/go-critic/go-critic: [1df3008](https://github.com/go-critic/go-critic/tree/1df3008)
+- github.com/go-lintpack/lintpack: [v0.5.2](https://github.com/go-lintpack/lintpack/tree/v0.5.2)
+- github.com/go-ole/go-ole: [v1.2.1](https://github.com/go-ole/go-ole/tree/v1.2.1)
+- github.com/go-toolsmith/astcast: [v1.0.0](https://github.com/go-toolsmith/astcast/tree/v1.0.0)
+- github.com/go-toolsmith/astcopy: [v1.0.0](https://github.com/go-toolsmith/astcopy/tree/v1.0.0)
+- github.com/go-toolsmith/astequal: [v1.0.0](https://github.com/go-toolsmith/astequal/tree/v1.0.0)
+- github.com/go-toolsmith/astfmt: [v1.0.0](https://github.com/go-toolsmith/astfmt/tree/v1.0.0)
+- github.com/go-toolsmith/astinfo: [9809ff7](https://github.com/go-toolsmith/astinfo/tree/9809ff7)
+- github.com/go-toolsmith/astp: [v1.0.0](https://github.com/go-toolsmith/astp/tree/v1.0.0)
+- github.com/go-toolsmith/pkgload: [v1.0.0](https://github.com/go-toolsmith/pkgload/tree/v1.0.0)
+- github.com/go-toolsmith/strparse: [v1.0.0](https://github.com/go-toolsmith/strparse/tree/v1.0.0)
+- github.com/go-toolsmith/typep: [v1.0.0](https://github.com/go-toolsmith/typep/tree/v1.0.0)
+- github.com/gobwas/glob: [v0.2.3](https://github.com/gobwas/glob/tree/v0.2.3)
+- github.com/godbus/dbus: [2ff6f7f](https://github.com/godbus/dbus/tree/2ff6f7f)
+- github.com/golangci/check: [cfe4005](https://github.com/golangci/check/tree/cfe4005)
+- github.com/golangci/dupl: [3e9179a](https://github.com/golangci/dupl/tree/3e9179a)
+- github.com/golangci/errcheck: [ef45e06](https://github.com/golangci/errcheck/tree/ef45e06)
+- github.com/golangci/go-misc: [927a3d8](https://github.com/golangci/go-misc/tree/927a3d8)
+- github.com/golangci/go-tools: [e32c541](https://github.com/golangci/go-tools/tree/e32c541)
+- github.com/golangci/goconst: [041c5f2](https://github.com/golangci/goconst/tree/041c5f2)
+- github.com/golangci/gocyclo: [2becd97](https://github.com/golangci/gocyclo/tree/2becd97)
+- github.com/golangci/gofmt: [0b8337e](https://github.com/golangci/gofmt/tree/0b8337e)
+- github.com/golangci/golangci-lint: [v1.18.0](https://github.com/golangci/golangci-lint/tree/v1.18.0)
+- github.com/golangci/gosec: [66fb7fc](https://github.com/golangci/gosec/tree/66fb7fc)
+- github.com/golangci/ineffassign: [42439a7](https://github.com/golangci/ineffassign/tree/42439a7)
+- github.com/golangci/lint-1: [ee948d0](https://github.com/golangci/lint-1/tree/ee948d0)
+- github.com/golangci/maligned: [b1d8939](https://github.com/golangci/maligned/tree/b1d8939)
+- github.com/golangci/misspell: [950f5d1](https://github.com/golangci/misspell/tree/950f5d1)
+- github.com/golangci/prealloc: [215b22d](https://github.com/golangci/prealloc/tree/215b22d)
+- github.com/golangci/revgrep: [d9c87f5](https://github.com/golangci/revgrep/tree/d9c87f5)
+- github.com/golangci/unconvert: [28b1c44](https://github.com/golangci/unconvert/tree/28b1c44)
+- github.com/google/go-github: [v17.0.0+incompatible](https://github.com/google/go-github/tree/v17.0.0)
+- github.com/google/go-querystring: [v1.0.0](https://github.com/google/go-querystring/tree/v1.0.0)
+- github.com/gostaticanalysis/analysisutil: [v0.0.3](https://github.com/gostaticanalysis/analysisutil/tree/v0.0.3)
+- github.com/jellevandenhooff/dkim: [f50fe3d](https://github.com/jellevandenhooff/dkim/tree/f50fe3d)
+- github.com/klauspost/compress: [v1.4.1](https://github.com/klauspost/compress/tree/v1.4.1)
+- github.com/logrusorgru/aurora: [a7b3b31](https://github.com/logrusorgru/aurora/tree/a7b3b31)
+- github.com/mattn/go-shellwords: [v1.0.5](https://github.com/mattn/go-shellwords/tree/v1.0.5)
+- github.com/mattn/goveralls: [v0.0.2](https://github.com/mattn/goveralls/tree/v0.0.2)
+- github.com/mesos/mesos-go: [v0.0.9](https://github.com/mesos/mesos-go/tree/v0.0.9)
+- github.com/mitchellh/go-ps: [4fdf99a](https://github.com/mitchellh/go-ps/tree/4fdf99a)
+- github.com/mozilla/tls-observatory: [8791a20](https://github.com/mozilla/tls-observatory/tree/8791a20)
+- github.com/nbutton23/zxcvbn-go: [eafdab6](https://github.com/nbutton23/zxcvbn-go/tree/eafdab6)
+- github.com/pquerna/ffjson: [af8b230](https://github.com/pquerna/ffjson/tree/af8b230)
+- github.com/quasilyte/go-consistent: [c6f3937](https://github.com/quasilyte/go-consistent/tree/c6f3937)
+- github.com/ryanuber/go-glob: [256dc44](https://github.com/ryanuber/go-glob/tree/256dc44)
+- github.com/shirou/gopsutil: [c95755e](https://github.com/shirou/gopsutil/tree/c95755e)
+- github.com/shirou/w32: [bb4de01](https://github.com/shirou/w32/tree/bb4de01)
+- github.com/shurcooL/go-goon: [37c2f52](https://github.com/shurcooL/go-goon/tree/37c2f52)
+- github.com/shurcooL/go: [9e1955d](https://github.com/shurcooL/go/tree/9e1955d)
+- github.com/sourcegraph/go-diff: [v0.5.1](https://github.com/sourcegraph/go-diff/tree/v0.5.1)
+- github.com/tarm/serial: [98f6abe](https://github.com/tarm/serial/tree/98f6abe)
+- github.com/timakin/bodyclose: [87058b9](https://github.com/timakin/bodyclose/tree/87058b9)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- github.com/ultraware/funlen: [v0.0.2](https://github.com/ultraware/funlen/tree/v0.0.2)
+- github.com/valyala/bytebufferpool: [v1.0.0](https://github.com/valyala/bytebufferpool/tree/v1.0.0)
+- github.com/valyala/fasthttp: [v1.2.0](https://github.com/valyala/fasthttp/tree/v1.2.0)
+- github.com/valyala/quicktemplate: [v1.1.1](https://github.com/valyala/quicktemplate/tree/v1.1.1)
+- github.com/valyala/tcplisten: [ceec8f9](https://github.com/valyala/tcplisten/tree/ceec8f9)
+- go4.org: 417644f
+- golang.org/x/build: 2835ba2
+- golang.org/x/perf: 6e6d33e
+- gopkg.in/airbrake/gobrake.v2: v2.0.9
+- gopkg.in/gemnasium/logrus-airbrake-hook.v2: v2.1.2
+- gotest.tools/gotestsum: v0.3.5
+- grpc.go4.org: 11d0a25
+- k8s.io/klog: v1.0.0
+- k8s.io/repo-infra: v0.0.1-alpha.1
+- mvdan.cc/interfacer: c200402
+- mvdan.cc/lint: adc824a
+- mvdan.cc/unparam: fbb5962
+- sigs.k8s.io/structured-merge-diff/v3: v3.0.0
+- sourcegraph.com/sqs/pbtypes: d3ebe8f
 
 
 
-# v1.18.0-rc.1
+# v1.19.0-rc.4
 
-[Documentation](https://docs.k8s.io)
 
-## Downloads for v1.18.0-rc.1
+## Downloads for v1.19.0-rc.4
+
+### Source Code
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes.tar.gz) | `c17231d5de2e0677e8af8259baa11a388625821c79b86362049f2edb366404d6f4b4587b8f13ccbceeb2f32c6a9fe98607f779c0f3e1caec438f002e3a2c8c21`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-src.tar.gz) | `e84ffad57c301f5d6e90f916b996d5abb0c987928c3ca6b1565f7b042588f839b994ca12c43fc36f0ffb63f9fabc15110eb08be253b8939f49cd951e956da618`
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes.tar.gz) | 98bb6e2ac98a3176a9592982fec04b037d189de73cb7175d51596075bfd008c7ec0a2301b9511375626581f864ea74b5731e2ef2b4c70363f1860d11eb827de1
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-src.tar.gz) | d4686f8d07fe6f324f46880a4dc5af9afa314a6b7dca82d0edb50290b769d25d18babcc5257a96a51a046052c7747e324b025a90a36ca5e62f67642bb03c44f6
 
-### Client Binaries
+### Client binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-386.tar.gz) | `1aea99923d492436b3eb91aaecffac94e5d0aa2b38a0930d266fda85c665bbc4569745c409aa302247df3b578ce60324e7a489eb26240e97d4e65a67428ea3d1`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-darwin-amd64.tar.gz) | `07fa7340a959740bd52b83ff44438bbd988e235277dad1e43f125f08ac85230a24a3b755f4e4c8645743444fa2b66a3602fc445d7da6d2fc3770e8c21ba24b33`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-386.tar.gz) | `48cebd26448fdd47aa36257baa4c716a98fda055bbf6a05230f2a3fe3c1b99b4e483668661415392190f3eebb9cb6e15c784626b48bb2541d93a37902f0e3974`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-amd64.tar.gz) | `c3a5fedf263f07a07f59c01fea6c63c1e0b76ee8dc67c45b6c134255c28ed69171ccc2f91b6a45d6a8ec5570a0a7562e24c33b9d7b0d1a864f4dc04b178b3c04`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm.tar.gz) | `a6b11a55bd38583bbaac14931a6862f8ce6493afe30947ba29e5556654a571593358278df59412bbeb6888fa127e9ae4c0047a9d46cb59394995010796df6b14`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-arm64.tar.gz) | `9e15331ac8010154a9b64f5488969fc8ee2f21059639896cb84c5cf4f05f4c9d1d8970cb6f9831de6b34013848227c1972c12a698d07aac1ecc056e972fe6f79`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-ppc64le.tar.gz) | `f828fe6252678de9d4822e482f5873309ae9139b2db87298ab3273ce45d38aa07b6b9b42b76c140705f27ba71e101d58b43e59ac7259d7c08dc647ea809e207c`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-linux-s390x.tar.gz) | `19da4b45f0666c063934af616f3e7ed3caa99d4ee1e46d53efadc7a8a4d38e43a36ced7249acd7ad3dcc4b4f60d8451b4f7ec7727e478ee2fadd14d353228bce`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-386.tar.gz) | `775c9afb6cb3e7c4ba53e9f48a5df2cf207234a33059bd74448bc9f177dd120fb3f9c58ab45048a566326acc43bc8a67e886e10ef99f20780c8f63bb17426ebd`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-client-windows-amd64.tar.gz) | `208d2595a5b57ac97aac75b4a2a6130f0c937f781a030bde1a432daf4bc51f2fa523fca2eb84c38798489c4b536ee90aad22f7be8477985d9691d51ad8e1c4dc`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-darwin-amd64.tar.gz) | e9184ceb37491764c1ea2ef0b1eca55f27109bb973c7ff7c78e83c5945840baf28fdead21ef861b0c5cb81f4dc39d0af86ed7b17ed6f087f211084d0033dad11
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-386.tar.gz) | c9f1ec4e8d9c6245f955b2132c0fae6d851a6a49a5b7a2333c01ba9fafa3c4e8a07c6462e525179c25e308520502544ab4dc570e1b9d0090d58b6d18bcfcba47
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-amd64.tar.gz) | d23858b03c3554ad12517ce5f7855ceccaa9425c2d19fbc9cf902c0e796a8182f8b0e8eeeeefff0f46e960dfee96b2a2033a04a3194ac34dfd2a32003775d060
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-arm.tar.gz) | a745b3a06fe992713e4d7f921e2f36c5b39222d7b1a3e13299d15925743dd99965c2bdf05b4deda30a6f6232a40588e154fdd83f40d9d260d7ac8f70b18cad48
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-arm64.tar.gz) | 719b1f30e4bbb05d638ee78cf0145003a1e783bbd0c2f0952fcb30702dd27dfd44c3bc85baaf9a776e490ed53c638327ed1c0e5a882dc93c24d7cac20e4f1dd0
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-ppc64le.tar.gz) | fba0794e9dc0f231da5a4e85e37c2d8260e5205574e0421f5122a7d60a05ca6546912519a28e8d6c241904617234e1b0b5c94f890853ad5ae4e329ef8085a092
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-linux-s390x.tar.gz) | edce96e37e37fd2b60e34fe56240461094e5784985790453becdfe09011305fcbd8a50ee5bf6d82a70d208d660796d0ddf160bed0292271b6617049db800962f
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-windows-386.tar.gz) | 06c849b35d886bebedfd8d906ac37ccda10e05b06542fefe6440268c5e937f235915e53daafe35076b68e0af0d4ddeab4240da55b09ee52fa26928945f1a2ecd
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-client-windows-amd64.tar.gz) | a13e6ec70f76d6056d5668b678ba6f223e35756cded6c84dfb58e28b3741fecfa7cb5e6ae2239392d770028d1b55ca8eb520c0b24e13fc3bd38720134b472d53
 
-### Server Binaries
+### Server binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-amd64.tar.gz) | `dcf832eae04f9f52ff473754ef5cfe697b35f4dc1a282622c94fa10943c8c35f4a8777a0c58c7de871c3c428c8973bf72d6bcd8751416d4c682125268b8fcefe`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm.tar.gz) | `a04e34bea28eb1c8b492e8b1dd3c0dd87ebee71a7dbbef72be10a335e553361af7e48296e504f9844496b04e66350871114d20cfac3f3b49550d8be60f324ba3`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-arm64.tar.gz) | `a6af086b07a8c2e498f32b43e6511bf6a5e6baf358c572c6910c8df17cd6cae94f562f459714fcead1595767cb14c7f639c5735f1411173bbd38d5604c082a77`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-ppc64le.tar.gz) | `5a960ef5ba0c255f587f2ac0b028cd03136dc91e4efc5d1becab46417852e5524d18572b6f66259531ec6fea997da3c4d162ac153a9439672154375053fec6c7`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-server-linux-s390x.tar.gz) | `0f32c7d9b14bc238b9a5764d8f00edc4d3bf36bcf06b340b81061424e6070768962425194a8c2025c3a7ffb97b1de551d3ad23d1591ae34dd4e3ba25ab364c33`
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-amd64.tar.gz) | ff7fbf211c29b94c19466337e6c142e733c8c0bac815a97906168e57d21ad1b2965e4b0033b525de8fed9a91ab943e3eb6d330f8095660e32be2791f8161a6a2
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-arm.tar.gz) | 218a35466ebcc0bc0e8eff9bbb2e58f0ac3bec6a75f45a7c1487aa4fc3e2bddb90b74e91a2b81bbbbb1eb1de2df310adab4c07c2a2c38a9973580b4f85734a1f
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-arm64.tar.gz) | 8a81d727e63875d18336fda8bb6f570084553fc346b7e7df2fc3e1c04a8ef766f61d96d445537e4660ce2f46b170a04218a4d8a270b3ad373caa3f815c0fec93
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-ppc64le.tar.gz) | 9b5afa44ac2e1232cd0c54b3602a2027bc8a08b30809b3ef973f75793b35a596491e6056d7995e493a1e4f48d83389240ac2e609b9f76d2715b8e115e6648716
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-server-linux-s390x.tar.gz) | f3034b2e88b5c1d362d84f78dfd1761d0fc21ada1cd6b1a6132a709c663a1206651df96c948534b3661f6b70b651e33021aced3a7574a0e5fc88ace73fff2a6f
 
-### Node Binaries
+### Node binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-amd64.tar.gz) | `27d8955d535d14f3f4dca501fd27e4f06fad84c6da878ea5332a5c83b6955667f6f731bfacaf5a3a23c09f14caa400f9bee927a0f269f5374de7f79cd1919b3b`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm.tar.gz) | `0d56eccad63ba608335988e90b377fe8ae978b177dc836cdb803a5c99d99e8f3399a666d9477ca9cfe5964944993e85c416aec10a99323e3246141efc0b1cc9e`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-arm64.tar.gz) | `79bb9be66f9e892d866b28e5cc838245818edb9706981fab6ccbff493181b341c1fcf6fe5d2342120a112eb93af413f5ba191cfba1ab4c4a8b0546a5ad8ec220`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-ppc64le.tar.gz) | `3e9e2c6f9a2747d828069511dce8b4034c773c2d122f005f4508e22518055c1e055268d9d86773bbd26fbd2d887d783f408142c6c2f56ab2f2365236fd4d2635`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-linux-s390x.tar.gz) | `4f96e018c336fa13bb6df6f7217fe46a2b5c47f806f786499c429604ccba2ebe558503ab2c72f63250aa25b61dae2d166e4b80ae10f6ab37d714f87c1dcf6691`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-rc.1/kubernetes-node-windows-amd64.tar.gz) | `ab110d76d506746af345e5897ef4f6993d5f53ac818ba69a334f3641047351aa63bfb3582841a9afca51dd0baff8b9010077d9c8ec85d2d69e4172b8d4b338b0`
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-amd64.tar.gz) | 2061a8f5bc2060b071564c92b693950eda7768a9ceb874982f0e91aa78284fb477becb55ecf099acae73c447271240caecefc19b3b29024e9b818e0639c2fc70
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-arm.tar.gz) | c06b817b191ff9a4b05bf70fc14edcf01d4ded204e489966b1761dd68d45d054028870301e45ebba648c0be097c7c42120867c8b28fdd625c8eb5a5bc3ace71d
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-arm64.tar.gz) | 21efb3bf23628546de97210074f48e928fec211b81215eff8b10c3f5f7e79bb5911c1393a66a8363a0183fe299bf98b316c0c2d77a13c8c5b798255c056bd806
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-ppc64le.tar.gz) | ce31dd65b9cbfaabdc3c93e8afee0ea5606c64e6bf4452078bee73b1d328d23ebdbc871a00edd16fa4e676406a707cf9113fdaec76489681c379c35c3fd6aeb0
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-linux-s390x.tar.gz) | 523a8e1d6e0eff70810e846c171b7f74a4aaecb25237addf541a9f8adb3797402b6e57abf9030f62d5bb333d5f5e8960199a44fe48696a4da98f7ed7d993cde1
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.4/kubernetes-node-windows-amd64.tar.gz) | a7fbcd11ea8b6427e7846e39b2fdeae41d484320faa8f3e9b6a777d87ba62e7399ad0ec6a33d9a4675001898881e444f336eebd5c97b3903dee803834a646f3d
 
-## Changelog since v1.18.0-beta.2
-
-## Changes by Kind
-
-### API Change
-
-- Removes ConfigMap as suggestion for IngressClass parameters ([#89093](https://github.com/kubernetes/kubernetes/pull/89093), [@robscott](https://github.com/robscott)) [SIG Network]
-
-### Other (Bug, Cleanup or Flake)
-
-- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
-- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network]
-- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
-- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fixed a data race in kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node]
-- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node]
-- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network]
-- Update Cluster Autoscaler to 1.18.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk)) [SIG Autoscaling and Cluster Lifecycle]
-
-
-# v1.18.0-beta.2
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-beta.2
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes.tar.gz) | `3017430ca17f8a3523669b4a02c39cedfc6c48b07281bc0a67a9fbe9d76547b76f09529172cc01984765353a6134a43733b7315e0dff370bba2635dd2a6289af`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-src.tar.gz) | `c5fd60601380a99efff4458b1c9cf4dc02195f6f756b36e590e54dff68f7064daf32cf63980dddee13ef9dec7a60ad4eeb47a288083fdbbeeef4bc038384e9ea`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-386.tar.gz) | `7e49ede167b9271d4171e477fa21d267b2fb35f80869337d5b323198dc12f71b61441975bf925ad6e6cd7b61cbf6372d386417dc1e5c9b3c87ae651021c37237`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | `3f5cdf0e85eee7d0773e0ae2df1c61329dea90e0da92b02dae1ffd101008dc4bade1c4951fc09f0cad306f0bcb7d16da8654334ddee43d5015913cc4ac8f3eda`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-386.tar.gz) | `b67b41c11bfecb88017c33feee21735c56f24cf6f7851b63c752495fc0fb563cd417a67a81f46bca091f74dc00fca1f296e483d2e3dfe2004ea4b42e252d30b9`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | `1fef2197cb80003e3a5c26f05e889af9d85fbbc23e27747944d2997ace4bfa28f3670b13c08f5e26b7e274176b4e2df89c1162aebd8b9506e63b39b311b2d405`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm.tar.gz) | `84e5f4d9776490219ee94a84adccd5dfc7c0362eb330709771afcde95ec83f03d96fe7399eec218e47af0a1e6445e24d95e6f9c66c0882ef8233a09ff2022420`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | `ba613b114e0cca32fa21a3d10f845aa2f215d3af54e775f917ff93919f7dd7075efe254e4047a85a1f4b817fc2bd78006c2e8873885f1208cbc02db99e2e2e25`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | `502a6938d8c4bbe04abbd19b59919d86765058ff72334848be4012cec493e0e7027c6cd950cf501367ac2026eea9f518110cb72d1c792322b396fc2f73d23217`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | `c24700e0ed2ef5c1d2dd282d638c88d90392ae90ea420837b39fd8e1cfc19525017325ccda71d8472fdaea174762208c09e1bba9bbc77c89deef6fac5e847ba2`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-386.tar.gz) | `0d4c5a741b052f790c8b0923c9586ee9906225e51cf4dc8a56fc303d4d61bb5bf77fba9e65151dec7be854ff31da8fc2dcd3214563e1b4b9951e6af4aa643da4`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | `841ef2e306c0c9593f04d9528ee019bf3b667761227d9afc1d6ca8bf1aa5631dc25f5fe13ff329c4bf0c816b971fd0dec808f879721e0f3bf51ce49772b38010`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | `b373df2e6ef55215e712315a5508e85a39126bd81b7b93c6b6305238919a88c740077828a6f19bcd97141951048ef7a19806ef6b1c3e1772dbc45715c5fcb3af`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm.tar.gz) | `b8103cb743c23076ce8dd7c2da01c8dd5a542fbac8480e82dc673139c8ee5ec4495ca33695e7a18dd36412cf1e18ed84c8de05042525ddd8e869fbdfa2766569`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | `8f8f05cf64fb9c8d80cdcb4935b2d3e3edc48bdd303231ae12f93e3f4d979237490744a11e24ba7f52dbb017ca321a8e31624dcffa391b8afda3d02078767fa0`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | `b313b911c46f2ec129537407af3f165f238e48caeb4b9e530783ffa3659304a544ed02bef8ece715c279373b9fb2c781bd4475560e02c4b98a6d79837bc81938`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | `a1b6b06571141f507b12e5ef98efb88f4b6b9aba924722b2a74f11278d29a2972ab8290608360151d124608e6e24da0eb3516d484cb5fa12ff2987562f15964a`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | `20e02ca327543cddb2568ead3d5de164cbfb2914ab6416106d906bf12fcfbc4e55b13bea4d6a515e8feab038e2c929d72c4d6909dfd7881ba69fd1e8c772ab99`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm.tar.gz) | `ecd817ef05d6284f9c6592b84b0a48ea31cf4487030c9fb36518474b2a33dad11b9c852774682e60e4e8b074e6bea7016584ca281dddbe2994da5eaf909025c0`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | `0020d32b7908ffd5055c8b26a8b3033e4702f89efcfffe3f6fcdb8a9921fa8eaaed4193c85597c24afd8c523662454f233521bb7055841a54c182521217ccc9d`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | `e065411d66d486e7793449c1b2f5a412510b913bf7f4e728c0a20e275642b7668957050dc266952cdff09acc391369ae6ac5230184db89af6823ba400745f2fc`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | `082ee90413beaaea41d6cbe9a18f7d783a95852607f3b94190e0ca12aacdd97d87e233b87117871bfb7d0a4b6302fbc7688549492a9bc50a2f43a5452504d3ce`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | `fb5aca0cc36be703f9d4033eababd581bac5de8399c50594db087a99ed4cb56e4920e960eb81d0132d696d094729254eeda2a5c0cb6e65e3abca6c8d61da579e`
-
-## Changelog since v1.18.0-beta.1
-
-## Urgent Upgrade Notes
-
-### (No, really, you MUST read this before you upgrade)
-
-- `kubectl` no longer defaults to `http://localhost:8080`.  If you own one of these legacy clusters, you are *strongly- encouraged to secure your server.   If you cannot secure your server, you can set `KUBERNETES_MASTER` if you were relying on that behavior and you're a client-go user. Set `--server`, `--kubeconfig` or `KUBECONFIG` to make it work in `kubectl`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
+## Changelog since v1.19.0-rc.3
 
 ## Changes by Kind
 
 ### Deprecation
 
-- AlgorithmSource is removed from v1alpha2 Scheduler ComponentConfig ([#87999](https://github.com/kubernetes/kubernetes/pull/87999), [@damemi](https://github.com/damemi)) [SIG Scheduling]
-- Kube-proxy: deprecate `--healthz-port` and `--metrics-port` flag, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
-- Kubeadm: deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Cluster Lifecycle]
 
-### API Change
+### Bug or Regression
 
-- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing]
-- Added GenericPVCDataSource feature gate to enable using arbitrary custom resources as the data source for a PVC. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage]
-- Allow user to specify fsgroup permission change policy for pods ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage]
-- BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage]
-- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
-- Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network]
-- Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network]
-- Ingress: Add alternate backends via TypedLocalObjectReference ([#88775](https://github.com/kubernetes/kubernetes/pull/88775), [@cmluciano](https://github.com/cmluciano)) [SIG Apps and Network]
-- Ingress: allow wildcard hosts in IngressRule ([#88858](https://github.com/kubernetes/kubernetes/pull/88858), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
-- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver.  Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling]
-- Move TaintBasedEvictions feature gates to GA ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing]
-- New flag --endpointslice-updates-batch-period in kube-controller-manager can be used to reduce number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network]
-- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
-- The apiserver/v1alph1&#35;EgressSelectorConfiguration API is now beta. ([#88502](https://github.com/kubernetes/kubernetes/pull/88502), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery]
-- The storage.k8s.io/CSIDriver has moved to GA, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, Apps, Auth, Node, Scheduling, Storage and Testing]
-- VolumePVCDataSource moves to GA in 1.18 release ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Apps, CLI and Cluster Lifecycle]
+- A panic in the apiserver caused by the `informer-sync` health checker is now fixed. ([#93600](https://github.com/kubernetes/kubernetes/pull/93600), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery]
+- EndpointSliceMirroring controller now copies labels from Endpoints to EndpointSlices. ([#93442](https://github.com/kubernetes/kubernetes/pull/93442), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- Kube-apiserver: jsonpath expressions with consecutive recursive descent operators are no longer evaluated for custom resource printer columns ([#93408](https://github.com/kubernetes/kubernetes/pull/93408), [@joelsmith](https://github.com/joelsmith)) [SIG API Machinery]
 
-### Feature
+### Other (Cleanup or Flake)
 
-- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
-- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
-- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver.
-  After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect.
-  The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
-  Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
-- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
-- DefaultConstraints can be specified for the PodTopologySpread plugin in the component config ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows]
-- Kubectl cluster-info dump changed to only display a message telling you the location where the output was written when the output is not standard output. ([#88765](https://github.com/kubernetes/kubernetes/pull/88765), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- Print NotReady when pod is not ready based on its conditions. ([#88240](https://github.com/kubernetes/kubernetes/pull/88240), [@soltysh](https://github.com/soltysh)) [SIG CLI]
-- Scheduler Extender API is now located under k8s.io/kube-scheduler/extender ([#88540](https://github.com/kubernetes/kubernetes/pull/88540), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
-- Signatures on scale client methods have been modified to accept `context.Context` as a first argument. Signatures of Get, Update, and Patch methods have been updated to accept GetOptions, UpdateOptions and PatchOptions respectively. ([#88599](https://github.com/kubernetes/kubernetes/pull/88599), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, Apps, Autoscaling and CLI]
-- Signatures on the dynamic client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88906](https://github.com/kubernetes/kubernetes/pull/88906), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, CLI, Cluster Lifecycle, Storage and Testing]
-- Signatures on the metadata client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88910](https://github.com/kubernetes/kubernetes/pull/88910), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing]
-- Webhooks will have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing]
-- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing]
-- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI]
+- Build: Update to debian-base@v2.1.0 and debian-iptables@v12.1.1 ([#93667](https://github.com/kubernetes/kubernetes/pull/93667), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing]
 
-### Documentation
+## Dependencies
 
-- Update Japanese translation for kubectl help ([#86837](https://github.com/kubernetes/kubernetes/pull/86837), [@inductor](https://github.com/inductor)) [SIG CLI and Docs]
-- `kubectl plugin` now prints a note how to install krew ([#88577](https://github.com/kubernetes/kubernetes/pull/88577), [@corneliusweig](https://github.com/corneliusweig)) [SIG CLI]
+### Added
+_Nothing has changed._
 
-### Other (Bug, Cleanup or Flake)
+### Changed
+- k8s.io/utils: 0bdb4ca → d5654de
 
-- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with squential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- AzureFile and CephFS use new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
-- Build: Enable kube-cross image-building on K8s Infra ([#88562](https://github.com/kubernetes/kubernetes/pull/88562), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
-- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth]
-- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing]
-- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI]
-- FIX: prevent apiserver from panicking when failing to load audit webhook config file ([#88879](https://github.com/kubernetes/kubernetes/pull/88879), [@JoshVanL](https://github.com/JoshVanL)) [SIG API Machinery and Auth]
-- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]
-- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
-- Fix describe ingress annotations not sorted. ([#88394](https://github.com/kubernetes/kubernetes/pull/88394), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider]
-- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node]
-- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage]
-- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage]
-- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node]
-- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Node and Storage]
-- Fixes issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage]
-- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Apps, Node and Storage]
-- Hide kubectl.kubernetes.io/last-applied-configuration in describe command ([#88758](https://github.com/kubernetes/kubernetes/pull/88758), [@soltysh](https://github.com/soltysh)) [SIG Auth and CLI]
-- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider]
-- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
-- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
-
-  Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
-- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
-- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery]
-- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth]
-- Update to use golang 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Release and Testing]
-- Validate kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout ([#88657](https://github.com/kubernetes/kubernetes/pull/88657), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
+### Removed
+_Nothing has changed._
 
 
-# v1.18.0-beta.1
 
-[Documentation](https://docs.k8s.io)
+# v1.19.0-rc.3
 
-## Downloads for v1.18.0-beta.1
+
+## Downloads for v1.19.0-rc.3
+
+### Source Code
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes.tar.gz) | `7c182ca905b3a31871c01ab5fdaf46f074547536c7975e069ff230af0d402dfc0346958b1d084bd2c108582ffc407484e6a15a1cd93e9affbe34b6e99409ef1f`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-src.tar.gz) | `d104b8c792b1517bd730787678c71c8ee3b259de81449192a49a1c6e37a6576d28f69b05c2019cc4a4c40ddeb4d60b80138323df3f85db8682caabf28e67c2de`
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes.tar.gz) | 31f98fb8d51c6dfa60e2cf710a35af14bc17a6b3833b3802cebc92586b01996c091943087dc818541fc13ad75f051d20c176d9506fc0c86ab582a9295fb7ed59
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-src.tar.gz) | 4886180edf6287adf9db1cdab1e8439c41296c6b5b40af9c4642bb6cfd1fb894313c6d1210c2b882f1bc40dbfd17ed20c5159ea3a8c79ad2ef7a7630016e99de
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-darwin-amd64.tar.gz) | 19b0f9fe95e135329ce2cb9dd3e95551f3552be035ce7235e055c9d775dfa747c773b0806b5c2eef1e69863368be13adcb4c5ef78ae05af65483434686e9a773
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-386.tar.gz) | 219a15b54ba616938960ac38869c87be573e3cd7897e4790c31cdeb819415fcefb4f293fc49d63901b42f70e66555c72a8a774cced7ec15a93592dffef3b1336
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-amd64.tar.gz) | 7c5a2163e0e163d3b1819acc7c4475d35b853318dd5a6084ea0785744a92063edf65254b0f0eae0f69f4598561c182033a9722c1b8a61894959333f1357cb1f9
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-arm.tar.gz) | 5d48f78da6a54b63d8ea68e983d780c672b546b4a5d1fb2c15033377dd3098f0011516b55cc47db316dacabdbbd3660108014d12899ef1f4a6a03158ef503101
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-arm64.tar.gz) | c2db09db465f8ea2bd7b82971a59a2be394b2f9a8c15ff78ab06c3a41d9f1292175de19fdc7450cc28746027d59dc3162cb47b64555e91d324d33d699d89f408
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-ppc64le.tar.gz) | f28c9c672bc2c5e780f6fdcf019a5dad7172537e38e2ab7d52a1ea55babb41d296cef97b482133c7fce0634b1aed1b5322d1e0061d30c3848e4c912a7e1ca248
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-linux-s390x.tar.gz) | 22844af3c97eb9f36a038c552e9818b8670cd02acc98defe5c131c7f88621014cd51c343c1e0921b88ebbfd9850a5c277f50df78350f7565db4e356521d415d4
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-windows-386.tar.gz) | edabe78a1337f73caa81c885d722544fec443f875297291e57608d4f486c897af6c602656048a4325fcc957ce1d7acb1c1cf06cab0bd2e36acee1d6be206d3c6
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-client-windows-amd64.tar.gz) | f1a370b9ec298838e302909dd826760b50b593ee2d2247416d345ff00331973e7b6b29cef69f07d6c1477ab534d6ec9d1bbf5d3c2d1bb9b5b2933e088c8de3f1
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-amd64.tar.gz) | 193c023306d7478c2e43c4039642649c77598c05b07dbc466611e166f0233a7ea2a7f2ff61763b2630988c151a591f44428942d8ee06ce6766641e1dcfaac588
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-arm.tar.gz) | c1aa489779fb74855385f24120691771a05b57069064c99471b238e5d541d94d4356e7d2cd5b66c284c46bde1fc3eff2a1cebfcd9e72a78377b76e32a1dbf57a
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-arm64.tar.gz) | 73400003571f9f0308051ca448b1f96d83e9d211876a57b572ffb787ad0c3bb5f1e20547d959f0fac51a916cf7f26f8839ddddd55d4a38e59c8270d5eb48a970
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-ppc64le.tar.gz) | bebf75d884d024ffebfda40abaa0bfec99a6d4cd3cc0fac904a1c4c190e6eb8fc9412c7790b2f8a2b3cc8ccdf8556d9a93eec37e5c298f8abd62ee41de641a42
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-server-linux-s390x.tar.gz) | 8374dfb689abae31480814d6849aaa51e30666b7203cdcf204d49c9a0344391232f40d135671ec8316e26d1685e1cbbea4b829ff3b9f83c08c2d1ba50cd5aeb2
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-amd64.tar.gz) | 194ee29b012463e6d90c346f76d53f94778f75cc916b0e10a5ee174983fac6e848438e0d9e36a475c5d7ba7b0f3ad5debc039ec8f95fdfb6229843f04dfacb53
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-arm.tar.gz) | f0d075eaa84dae7ce2101dfa421021b0bfea235fe606d693e881775cd37ff0b82ca6a419dfe48becd2eddc5f882e97ba838164e6ac5991445225c31f147b4f97
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-arm64.tar.gz) | 3dc69981f31b01a2d8c439f7047f73e5699a121501c516ed17b3e91ed358ee97e43fa955eb9e1434cbf7864e51097e76c216075d34f4b455930a44af6c64be5c
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-ppc64le.tar.gz) | 4a77720373960a0cc20bbcfcdfe17f8d5ddaaf2e38bad607cfe05831029e8e14559e78cd0b5b80ab9c9268a04a8b6bd54ad7232c29301a1f6a6392fcd38ecedf
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-linux-s390x.tar.gz) | 319e684340aab739e3da46c6407851ff1c42463ba176bf190e58faa48d143975f02df3443ac287cdfcf652b5d6b6e6721d9e4f35995c4e705297a97dd777fe7e
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.3/kubernetes-node-windows-amd64.tar.gz) | 1ff22497a3f0844ffa8593a2a444a8fcb45d0123da49fd58e17cfc1477d22be7f6809d923898b6aa7a9ce519b0a6e0825f575f6cf71da5c8a0fa5f6b4d0905b6
+
+## Changelog since v1.19.0-rc.2
+
+## Changes by Kind
+
+### API Change
+
+- Adds the ability to disable Accelerator/GPU metrics collected by Kubelet ([#91930](https://github.com/kubernetes/kubernetes/pull/91930), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node]
+- Kubernetes is now built with golang 1.15.0-rc.1.
+  - The deprecated, legacy behavior of treating the CommonName field on X.509 serving certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable. ([#93264](https://github.com/kubernetes/kubernetes/pull/93264), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage and Testing]
+
+### Bug or Regression
+
+- Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Extended DSR loadbalancer feature in winkernel kube-proxy to HNS versions 9.3-9.max, 10.2+ ([#93080](https://github.com/kubernetes/kubernetes/pull/93080), [@elweb9858](https://github.com/elweb9858)) [SIG Network]
+- Fix instance not found issues when an Azure Node is recreated in a short time ([#93316](https://github.com/kubernetes/kubernetes/pull/93316), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+
+## Dependencies
+
+### Added
+- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27)
+
+### Changed
+- github.com/Microsoft/hcsshim: [v0.8.9 → 5eafd15](https://github.com/Microsoft/hcsshim/compare/v0.8.9...5eafd15)
+- github.com/containerd/cgroups: [bf292b2 → 0dbf7f0](https://github.com/containerd/cgroups/compare/bf292b2...0dbf7f0)
+- github.com/urfave/cli: [v1.22.1 → v1.22.2](https://github.com/urfave/cli/compare/v1.22.1...v1.22.2)
+- golang.org/x/crypto: bac4c82 → 75b2880
+- golang.org/x/mod: v0.1.0 → v0.3.0
+- golang.org/x/net: d3edc99 → ab34263
+- golang.org/x/tools: c00d67e → c1934b7
+
+### Removed
+- github.com/godbus/dbus: [ade71ed](https://github.com/godbus/dbus/tree/ade71ed)
+
+
+
+# v1.19.0-rc.2
+
+
+## Downloads for v1.19.0-rc.2
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes.tar.gz) | 7a9fa6af3772be18f8c427d8b96836bd77e271a08fffeba92d01b3fac4bd69d2be1bbc404cdd4fc259dda42b16790a7943eddb7c889b918d7631857e127a724c
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-src.tar.gz) | 60184627a181ac99cd914acb0ba61c22f31b315ef13be5504f3cb43dea1fa84abb2142c8a1ba9e98e037e0d9d2765e8d85bd12903b03a86538d7638ceb6ac5c9
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-darwin-386.tar.gz) | 03332cd70ce6a9c8e533d93d694da32b549bef486cf73c649bcb1c85fc314b0ac0f95e035de7b54c81112c1ac39029abeb8f246d359384bde2119ea5ea3ebe66
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-darwin-amd64.tar.gz) | e82c2908366cc27cbc1d72f89fdc13414b484dfdf26c39c6180bf2e5734169cc97d77a2d1ac051cdb153582a38f4805e5c5b5b8eb88022c914ffb4ef2a8202d3
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-386.tar.gz) | 948be72e8162ee109c670a88c443ba0907acfd0ffb64df62afe41762717bc2fb9308cbc4eb2012a14e0203197e8576e3700ad9f105379841d46acafad2a4c6dc
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-amd64.tar.gz) | 54e1980b6967dab1e70be2b4df0cd0171f04c92f12dcdf80908b087facb9d5cc1399a7d9455a4a799daa8e9d48b6ad86cb3666a131e5adfcd36b008d25138fa3
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-arm.tar.gz) | 4edcd2e1a866a16b8b0f6228f93b4a61cdd43dca36dcb53a5dbd865cc5a143ef6fd3b8575925acc8af17cff21dee993df9b88db5724320e7b420ca9d0427677f
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-arm64.tar.gz) | 138b215e35cfb5d05bda766763e92352171e018a090d516dbf0c280588c5e6f36228163a75a8147c7bac46e773ad0353daaf550d8fa0e91b1e05c5bc0242531c
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-ppc64le.tar.gz) | 3b8e7f5f1f2e34df5dbb06c12f07f660a2a732846c56d0f4b0a939b8121361d381325565bdda3182ef8951f4c2513a2c255940f97011034063ffb506d5aedeab
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-linux-s390x.tar.gz) | b695cc0695bd324c51084e64bea113aaad3c0b5ba44b5d122db9da6e359a4108008a80944cbe96c405bd2cf57f5f31b3eaf50f33c23d980bdb9f272937c88d1c
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-windows-386.tar.gz) | 8e370a66545cdebe0ae0816afe361c7579c7c6e8ee5652e4e01c6fcc3d6d2a6557101be39be24ceb14302fb30855730894a17f6ae11586759257f12406c653e2
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-client-windows-amd64.tar.gz) | 89e0fe5aac33c991891b08e5a3891ecbda3e038f0ee6a5cdd771ea294ec84292bd5f65f1a895f23e6892ec28f001f66d0166d204bf135cb1aa467ae56ccc1260
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-amd64.tar.gz) | 2b0a1b107bf31913d9deec57eab9d3db2ea512c995ce3b4fe247f91c36fdebcc4484a2f8ff53d40a5bc6a04c7144827b85b40ac90c46a9b0cec8a680700f1b1c
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-arm.tar.gz) | 2f1ab3bcacd82a9b6d92e09b7cdd63f57fc44623cdfb517512b634264fed87999d78b8571c7930839381b1ed4793b68343e85956d7a8c5bae77ba8f8ade06afa
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-arm64.tar.gz) | ea67613c8356f650891a096881546afb27f00e86a9c777617817583628d38b4725f0f65da3b0732414cbc8f97316b3029a355177342a4b1d94cf02d79542e4cd
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-ppc64le.tar.gz) | d1b151f3f47c28ead2304d2477fa25f24d12e3fd80e9d1b3b593db99b9a1c5821db4d089f4f1dd041796ea3fd814000c225a7e75aac1e5891a4e16517bcaceee
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-server-linux-s390x.tar.gz) | 69bf215fdc3ad53834eaa9a918452feb0803dffe381b6e03b73141364a697a576e5ed0242d448616707cb386190c21564fe89f8cf3409a7c621a86d86b2c7680
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-amd64.tar.gz) | 88ae137316bab3bb1dcb6c78a4d725face618d41714400505b97ce9d3fa37a6caa036b9e8508ade6dd679e3a8c483a32aef9e400ab08d86b6bf39bc13f34e435
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-arm.tar.gz) | 7eaaf2a2a4ee5181cb4c1567e99b8bf82a3da342799f5d2b34dd7f133313c3e3d2ac5a778110e178161788cb226bd64836fba35fbec21c8384e7725cae9b756c
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-arm64.tar.gz) | 4f0ef95abc52da0e5d0c40434f8c324ddfb218a577114c4ead00f2ac1c01439922aee6fe347f702927a73b0166cd8b9f4c491d3a18a1a951d24c9ea7259d2655
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-ppc64le.tar.gz) | 0424896e2fedae3a566a5aa2e4af26977a578066d49e3ad66307839c2d2dd1c53d1afcf16b2f6cebf0c74d2d60dbc118e6446d9c02aaab27e95b3a6d26889f51
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-linux-s390x.tar.gz) | 294788687a6e6d1ca2e4d56435b1174e4330abe64cc58b1372c3b9caaab4455586da4e3bfc62616b52ea7d678561fb77ce1f8d0023fd7d1e75e1db348c69939c
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.2/kubernetes-node-windows-amd64.tar.gz) | 61389f8c05c682102e3432a2f05f41b11d531124f61443429627f94ef6e970d44240d44d32aa467b814de0b54a17208b2d2696602ba5dd6d30f64db964900230
+
+## Changelog since v1.19.0-rc.1
+
+## Changes by Kind
+
+### API Change
+
+- A new alpha-level field, `SupportsFsGroup`, has been introduced for CSIDrivers to allow them to specify whether they support volume ownership and permission modifications. The `CSIVolumeSupportFSGroup` feature gate must be enabled to allow this field to be used. ([#92001](https://github.com/kubernetes/kubernetes/pull/92001), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, CLI and Storage]
+- The kube-controller-manager managed signers can now have distinct signing certificates and keys.  See the help about `--cluster-signing-[signer-name]-{cert,key}-file`.  `--cluster-signing-{cert,key}-file` is still the default. ([#90822](https://github.com/kubernetes/kubernetes/pull/90822), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth]
+
+### Feature
+
+- Added kube-apiserver metrics: apiserver_current_inflight_request_measures and, when API Priority and Fairness is enable, windowed_request_stats. ([#91177](https://github.com/kubernetes/kubernetes/pull/91177), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery, Instrumentation and Testing]
+- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
+
+### Bug or Regression
+
+- Do not add nodes labeled with kubernetes.azure.com/managed=false to backend pool of load balancer. ([#93034](https://github.com/kubernetes/kubernetes/pull/93034), [@matthias50](https://github.com/matthias50)) [SIG Cloud Provider]
+- Do not retry volume expansion if CSI driver returns FailedPrecondition error ([#92986](https://github.com/kubernetes/kubernetes/pull/92986), [@gnufied](https://github.com/gnufied)) [SIG Node and Storage]
+- Fix: determine the correct ip config based on ip family ([#93043](https://github.com/kubernetes/kubernetes/pull/93043), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Fix: initial delay in mounting azure disk & file ([#93052](https://github.com/kubernetes/kubernetes/pull/93052), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fixed the EndpointSliceController to correctly create endpoints for IPv6-only pods.
+  
+  Fixed the EndpointController to allow IPv6 headless services, if the IPv6DualStack
+  feature gate is enabled, by specifying `ipFamily: IPv6` on the service. (This already
+  worked with the EndpointSliceController.) ([#91399](https://github.com/kubernetes/kubernetes/pull/91399), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+
+### Other (Cleanup or Flake)
+
+- Kube-up: defaults to limiting critical pods to the kube-system namespace to match behavior prior to 1.17 ([#93121](https://github.com/kubernetes/kubernetes/pull/93121), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Scheduling]
+- Update Golang to v1.14.5
+  - Update repo-infra to 0.0.7 (to support go1.14.5 and go1.13.13)
+    - Includes:
+      - bazelbuild/bazel-toolchains@3.3.2
+      - bazelbuild/rules_go@v0.22.7 ([#93088](https://github.com/kubernetes/kubernetes/pull/93088), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Update Golang to v1.14.6
+  - Update repo-infra to 0.0.8 (to support go1.14.6 and go1.13.14)
+    - Includes:
+      - bazelbuild/bazel-toolchains@3.4.0
+      - bazelbuild/rules_go@v0.22.8 ([#93198](https://github.com/kubernetes/kubernetes/pull/93198), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- Update default etcd server version to 3.4.9 ([#92349](https://github.com/kubernetes/kubernetes/pull/92349), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- go.etcd.io/etcd: 54ba958 → 18dfb9c
+- k8s.io/utils: 6e3d28b → 0bdb4ca
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-rc.1
+
+
+## Downloads for v1.19.0-rc.1
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes.tar.gz) | d4bc1d86ff77a1a8695091207b8181a246c8964ae1dd8967392aae95197c0339c7915a016c017ecab0b9d203b3205221ca766ce568d7ee52947e7f50f057af4f
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-src.tar.gz) | 79af4e01b0d5432f92b026730a0c60523069d312858c30fdcaeaf6ee159c71f3413a5075d82c0acd9b135b7a06d5ecb0c0d38b8a8d0f301a9d9bffb35d22f029
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-darwin-386.tar.gz) | 7d21bf9733810659576e67986d129208894adea3c571de662dbf80fb822e18abfc1644ea60a4e5fbe244a23b56aa973b76dafe789ead1bf7539f41bdd9bca886
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-darwin-amd64.tar.gz) | b4622e06c09bb08a0dc0115bfcd991c50459c7b772889820648ed1c05a425605d10b71b92c58c119b77baa3bca209f9c75827d2cde69d128a5cfcada5f37be39
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-386.tar.gz) | f51032ad605543f68a2a4da3bede1f3e7be0dd63b03b751fef5f133e8d64bec02bfe7433b75e3d0c4ae122d4e0cf009095800c638d2cc81f6fb81b488f5a6dab
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-amd64.tar.gz) | 48489d22969f69a5015988e596d597c64ea18675649afe55ad119dbbe98ba9a4104d5e323704cf1f3cbdfca3feac629d3813e260a330a72da12f1a794d054f76
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-arm.tar.gz) | d9f8a6f6f3d09be9c08588c2b5153a4d8cc9db496bde3da2f3af472c260566d1391cd8811f2c05d4f302db849a38432f25228d9bbb59aaaf0dfba64b33f8ee8e
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-arm64.tar.gz) | 1c3590750a3f02e0e5845e1135cc3ab990309bdecfe64c089842a134eae57b573488531696796185ed12dde2d6f95d2e3656dd9893d04cd0adbe025513ffff30
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-ppc64le.tar.gz) | 158a562d5dbbe90cd56b5d757823adda1919e9b5db8005fb6e2523358e5a20628d55ec1903c0e317a0d8ac9b9a649eea23d9ea746db22b73d6d580ae8c067077
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-linux-s390x.tar.gz) | 47c140567dc593caf065f295ed6006efcde010a526a96c8d3ef5f3d9a9dc6b413bc197dc822648067fe16299908ada7046c2a8a3213d4296b04b51a264ad40e9
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-windows-386.tar.gz) | e25d7d4ad3e6f6e6cfba181c5871e56de2751f88b640502745f6693ddd86ccd7eef8aebaa30955afdbbd0320a5b51d4e9e17f71baab37a470aac284178a0e21c
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-client-windows-amd64.tar.gz) | fd8463b04b5d7f115104245fa1dd53de6656b349dad4cfd55f239012d4f2c1a8e35aa3f3554138df9ddfea9d7702b51a249f6db698c0cea7c36e5bc98a017fe7
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-amd64.tar.gz) | 96acce78bba3779bef616de28da5d75bc4dc0b52fe0bf03b169c469ade9a8cd38b19c4620d222d67bff9ceeb0c5ebf893f55c1de02356bcebe5689890d0478f7
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-arm.tar.gz) | 1e561f3edbc66d2ab7f6f1ffe8dc1c01cec13ee3ba700458bd5d87202723cc832f3305a864a3b569463c96d60c9f60c03b77f210663cc40589e40515b3a32e75
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-arm64.tar.gz) | ba8fc011ac0e54cb1a0e0e3ee5f1cff4d877f4fdd75e15bf25b1cf817b3cf2bc85f9809d3cc76e9145f07a837960843ca68bdf02fe970c0043fc9ff7b53da021
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-ppc64le.tar.gz) | 1f506676284ab2f6bd3fc8a29a062f4fddf5346ef30be9363f640467c64011144381180c5bf74ec885d2f54524e82e21c745c5d2f1b191948bc40db2a09a2900
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-server-linux-s390x.tar.gz) | 5a7101288d51297c3346d028176b4b997afd8652d6481cec82f8863a91209fec6e8a9286a9bd7543b428e6ef82c1c68a7ce0782191c4682634015a032f749554
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-amd64.tar.gz) | 6852edc9818cb51a7e738e44a8bca2290777320e62518c024962fddd05f7ef390fb5696537068fd75e340bae909602f0bbc2aa5ebf6c487c7b1e990250f16810
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-arm.tar.gz) | f13edad4684d0de61e4cd7e524f891c75e0efe1050911d9bf0ee3a77cac28f57dca68fb990df6b5d9646e9b389527cbb861de10e12a84e57788f339db05936cb
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-arm64.tar.gz) | 69480150325525459aed212b8c96cb1865598cb5ecbeb57741134142d65e8a96258ec298b86d533ce88d2c499c4ad17e66dd3f0f7b5e9c34882889e9cb384805
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-ppc64le.tar.gz) | 774cfa9a4319ede166674d3e8c46900c9319d98ffba5b46684244e4bb15d94d31df8a6681e4711bc744d7e92fd23f207505eda98f43c8e2383107badbd43f289
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-linux-s390x.tar.gz) | 7e696988febb1e913129353134191b23c6aa5b0bea7c9c9168116596b827c091a88049ca8b8847dda25ecd4467cca4cc48cae8699635b5e78b83aab482c109f5
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-rc.1/kubernetes-node-windows-amd64.tar.gz) | 067182292d9e17f0d4974051681bedcf5ed6017dc80485541f89ea1f211085714165941a5262a4997b7bfc2bd190f2255df4c1b39f86a3278487248111d83cd4
+
+## Changelog since v1.19.0-rc.0
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+ - Azure blob disk feature(`kind`: `Shared`, `Dedicated`) has been deprecated, you should use `kind`: `Managed` in `kubernetes.io/azure-disk` storage class. ([#92905](https://github.com/kubernetes/kubernetes/pull/92905), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+ 
+## Changes by Kind
+
+### Deprecation
+
+- Kubeadm: deprecate the "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. ([#92881](https://github.com/kubernetes/kubernetes/pull/92881), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+
+### API Change
+
+- Added pod version skew strategy for seccomp profile to synchronize the deprecated annotations with the new API Server fields. Please see the corresponding section [in the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.mdversion-skew-strategy) for more detailed explanations. ([#91408](https://github.com/kubernetes/kubernetes/pull/91408), [@saschagrunert](https://github.com/saschagrunert)) [SIG Apps, Auth, CLI and Node]
+- Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. ([#91637](https://github.com/kubernetes/kubernetes/pull/91637), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing]
+- Generic ephemeral volumes, a new alpha feature under the `GenericEphemeralVolume` feature gate, provide a more flexible alternative to `EmptyDir` volumes: as with `EmptyDir`, volumes are created and deleted for each pod automatically by Kubernetes. But because the normal provisioning process is used (`PersistentVolumeClaim`), storage can be provided by third-party storage vendors and all of the usual volume features work. Volumes don't need to be empt; for example, restoring from snapshot is supported. ([#92784](https://github.com/kubernetes/kubernetes/pull/92784), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing]
+
+### Feature
+
+- ACTION REQUIRED : In CoreDNS v1.7.0, [metrics names have been changed](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md&#35;metric-changes) which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading. 
+  
+  Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include:
+  -  Fixed a bug that could cause CoreDNS to stop updating service records.
+  -  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
+  -  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
+  -  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
+  -  The federation plugin (allows for v1 Kubernetes federation) has been removed.
+  More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92651](https://github.com/kubernetes/kubernetes/pull/92651), [@rajansandeep](https://github.com/rajansandeep)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Add tags support for Azure File Driver ([#92825](https://github.com/kubernetes/kubernetes/pull/92825), [@ZeroMagic](https://github.com/ZeroMagic)) [SIG Cloud Provider and Storage]
+- Audit events for API requests to deprecated API versions now include a `"k8s.io/deprecated": "true"` audit annotation. If a target removal release is identified, the audit event includes a `"k8s.io/removal-release": "<majorVersion>.<minorVersion>"` audit annotation as well. ([#92842](https://github.com/kubernetes/kubernetes/pull/92842), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Instrumentation]
+- Cloud node-controller use InstancesV2 ([#91319](https://github.com/kubernetes/kubernetes/pull/91319), [@gongguan](https://github.com/gongguan)) [SIG Apps, Cloud Provider, Scalability and Storage]
+- Kubeadm: deprecate the "--csr-only" and "--csr-dir" flags of the "kubeadm init phase certs" subcommands. Please use "kubeadm alpha certs generate-csr" instead. This new command allows you to generate new private keys and certificate signing requests for all the control-plane components, so that the certificates can be signed by an external CA. ([#92183](https://github.com/kubernetes/kubernetes/pull/92183), [@wallrj](https://github.com/wallrj)) [SIG Cluster Lifecycle]
+- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
+- Set CSIMigrationvSphere feature gates to beta.
+  Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
+  
+  Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15 ([#92816](https://github.com/kubernetes/kubernetes/pull/92816), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider and Storage]
+- Support a smooth upgrade from client-side apply to server-side apply without conflicts, as well as support the corresponding downgrade. ([#90187](https://github.com/kubernetes/kubernetes/pull/90187), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery and Testing]
+- Trace output in apiserver logs is more organized and comprehensive. Traces are nested, and for all non-long running request endpoints, the entire filter chain is instrumented (e.g. authentication check is included). ([#88936](https://github.com/kubernetes/kubernetes/pull/88936), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Scheduling]
+- `kubectl alpha debug` now supports debugging nodes by creating a debugging container running in the node's host namespaces. ([#92310](https://github.com/kubernetes/kubernetes/pull/92310), [@verb](https://github.com/verb)) [SIG CLI]
+
+### Failing Test
+
+- Kube-proxy iptables min-sync-period defaults to 1 sec. Previously, it was 0. ([#92836](https://github.com/kubernetes/kubernetes/pull/92836), [@aojea](https://github.com/aojea)) [SIG Network]
+
+### Bug or Regression
+
+- Dockershim security: pod sandbox now always run with `no-new-privileges` and `runtime/default` seccomp profile
+  dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90948](https://github.com/kubernetes/kubernetes/pull/90948), [@pjbgf](https://github.com/pjbgf)) [SIG Node]
+- Eviction requests for pods that have a non-zero DeletionTimestamp will always succeed ([#91342](https://github.com/kubernetes/kubernetes/pull/91342), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps]
+- Fix detection of image filesystem, disk metrics for devicemapper, detection of OOM Kills on 5.0+ linux kernels. ([#92919](https://github.com/kubernetes/kubernetes/pull/92919), [@dashpole](https://github.com/dashpole)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
+- Fixed memory leak in endpointSliceTracker ([#92838](https://github.com/kubernetes/kubernetes/pull/92838), [@tnqn](https://github.com/tnqn)) [SIG Apps and Network]
+- Kube-aggregator certificates are dynamically loaded on change from disk ([#92791](https://github.com/kubernetes/kubernetes/pull/92791), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
+- Kube-up now includes CoreDNS version v1.7.0. Some of the major changes include:
+  -  Fixed a bug that could cause CoreDNS to stop updating service records.
+  -  Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
+  -  Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin.
+  -  Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
+  -  The federation plugin (allows for v1 Kubernetes federation) has been removed.
+  More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92718](https://github.com/kubernetes/kubernetes/pull/92718), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cloud Provider]
+- The apiserver will no longer proxy non-101 responses for upgrade requests. This could break proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code. ([#92941](https://github.com/kubernetes/kubernetes/pull/92941), [@tallclair](https://github.com/tallclair)) [SIG API Machinery]
+- The terminationGracePeriodSeconds from pod spec is respected for the mirror pod. ([#92442](https://github.com/kubernetes/kubernetes/pull/92442), [@tedyu](https://github.com/tedyu)) [SIG Node and Testing]
+
+### Other (Cleanup or Flake)
+
+- --cache-dir sets cache directory for both http and discovery, defaults to $HOME/.kube/cache ([#92910](https://github.com/kubernetes/kubernetes/pull/92910), [@soltysh](https://github.com/soltysh)) [SIG API Machinery and CLI]
+- Fix: license issue in blob disk feature ([#92824](https://github.com/kubernetes/kubernetes/pull/92824), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- github.com/cilium/ebpf: [9f1617e → 1c8d4c9](https://github.com/cilium/ebpf/compare/9f1617e...1c8d4c9)
+- github.com/coredns/corefile-migration: [v1.0.8 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.8...v1.0.10)
+- github.com/google/cadvisor: [8450c56 → v0.37.0](https://github.com/google/cadvisor/compare/8450c56...v0.37.0)
+- github.com/json-iterator/go: [v1.1.9 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.9...v1.1.10)
+- github.com/opencontainers/runc: [1b94395 → 819fcc6](https://github.com/opencontainers/runc/compare/1b94395...819fcc6)
+- github.com/prometheus/client_golang: [v1.6.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.6.0...v1.7.1)
+- github.com/prometheus/common: [v0.9.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.9.1...v0.10.0)
+- github.com/prometheus/procfs: [v0.0.11 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.11...v0.1.3)
+- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102)
+- sigs.k8s.io/structured-merge-diff/v3: v3.0.0 → 43c19bb
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-beta.2
+
+
+## Downloads for v1.19.0-beta.2
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes.tar.gz) | 806c1734a57dfc1800730fcb25aeb60d50d19d248c0e2a92ede4b6c4565745b4f370d4fd925bef302a96fba89102b7560b8f067240e0f35f6ec6caa29971dea4
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-src.tar.gz) | 507372c6d7ea380ec68ea237141a2b62953a2e1d1d16288f37820b605e33778c5f43ac5a3dedf39f7907d501749916221a8fa4d50be1e5a90b3ce23d36eaa075
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-darwin-386.tar.gz) | 6d20ca8d37b01213dcb98a1e49d44d414043ce485ae7df9565dfb7914acb1ec42b7aeb0c503b8febc122a8b444c6ed13eec0ff3c88033c6db767e7af5dbbc65d
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | e9caa5463a662869cfc8b9254302641aee9b53fa2119244bd65ef2c66e8c617f7db9b194a672ff80d7bc42256e6560db9fe8a00b2214c0ef023e2d6feed58a3a
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-386.tar.gz) | 48296417fcd2c2f6d01c30dcf66956401ea46455c52a2bbd76feb9b117502ceaa2fb10dae944e087e7038b9fdae5b835497213894760ca01698eb892087490d2
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | e2cc7819974316419a8973f0d77050b3262c4e8d078946ff9f6f013d052ec1dd82893313feff6e4493ae0fd3fb62310e6ce4de49ba6e80f8b9979650debf53f2
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-arm.tar.gz) | 484aac48a7a736970ea0766547453b7d37b25ed29fdee771734973e3e080b33f6731eecc458647db962290b512d32546e675e4658287ced3214e87292b98a643
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | f793078dc2333825a6679126b279cb0a3415ded8c650478e73c37735c6aa9576b68b2a4165bb77ef475884d50563ea236d8db4c72b2e5552b5418ea06268daae
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | 4c204b8d3b2717470ee460230b6bdc63725402ad3d24789397934bfe077b94d68041a376864b618e01f541b5bd00d0e63d75aa531a327ab0082c01eb4b9aa5ee
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | d0f6e4ddbf122ebcb4c5a980d5f8e33a23213cb438983341870f288afd17e73ec42f0ded55a3a9622c57700e68999228508d449ca206aca85f3254f7622375db
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-windows-386.tar.gz) | a615a7821bba1f8e4115b7981347ed94a79947c78d32c692cd600e21e0de29fedfc4a39dc08ca516f2f35261cf4a6d6ce557008f034e0e1d311fa9e75478ec0c
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | 34046130c5ebb3afe17e6e3cf88229b8d3281a9ac9c28dece1fd2d49a11b7be011700b74d9b8111dee7d0943e5ebfa208185bae095c2571aa54e0f9201e2cddd
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | c922058ce9c665e329d3d4647aac5d2dd22d9a8af63a21e6af98943dfd14f2b90268c53876f42a64093b96499ee1109803868c9aead4c15fd8db4b1bbec58fd9
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-arm.tar.gz) | 4f17489b946dc04570bfab87015f2c2401b139b9ee745ed659bc94ccd116f3f23e249f83e19aaa418aa980874fffb478b1ec7340aa25292af758c9eabd4c2022
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | 69e44a63d15962de95a484e311130d415ebfec16a9da54989afc53a835c5b67de20911d71485950d07259a0f8286a299f4d74f90c73530e905da8dc60e391597
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | 66b30ebad7a8226304150aa42a1bd660a0b3975fecbfd8dbbea3092936454d9f81c8083841cc67c6645ab771383b66c7f980dd65319803078c91436c55d5217a
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | 0e197280f99654ec9e18ea01a9fc848449213ce28521943bc5d593dd2cac65310b6a918f611ea283b3a0377347eb718e99dd59224b8fad8adb223d483fa9fecb
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | f40afee38155c5163ba92e3fa3973263ca975f3b72ac18535799fb29180413542ef86f09c87681161affeef94eb0bd38e7cf571a73ab0f51a88420f1aedeaeec
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-arm.tar.gz) | 6088b11767b77f0ec932a9f1aee9f0c7795c3627529f259edf4d8b1be2e1a324a75c89caed65c6aa277c2fd6ee23b3ebeb05901f351cd2dde0a833bbbd6d6d07
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | e790c491d057721b94d0d2ad22dd5c75400e8602e95276471f20cd2181f52c5be38e66b445d8360e1fb671627217eb0b7735b485715844d0e9908cf3de249464
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | 04f696cfab66f92b4b22c23807a49c344d6a157a9ac3284a267613369b7f9f5887f67902cb8a2949caa204f89fdc65fe442a03c2c454013523f81b56476d39a0
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | c671e20f69f70ec567fb16bbed2fecac3099998a3365def1e0755e41509531fd65768f7a04015b27b17e6a5884e65cddb82ff30a8374ed011c5e2008817259db
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | 23d712fb2d455b5095d31b9c280d92442f7871786808528a1b39b9babf169dc7ae467f1ee2b2820089d69aa2342441d0290edf4f710808c78277e612f870321d
+
+## Changelog since v1.19.0-beta.1
+
+## Changes by Kind
+
+### Deprecation
+
+- Kubeadm: remove the deprecated "--use-api" flag for "kubeadm alpha certs renew" ([#90143](https://github.com/kubernetes/kubernetes/pull/90143), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Scheduler's alpha feature 'ResourceLimitsPriorityFunction' is completely removed due to lack of usage ([#91883](https://github.com/kubernetes/kubernetes/pull/91883), [@SataQiu](https://github.com/SataQiu)) [SIG Scheduling and Testing]
+
+### API Change
+
+- Remove `BindTimeoutSeconds` from schedule configuration `KubeSchedulerConfiguration` ([#91580](https://github.com/kubernetes/kubernetes/pull/91580), [@cofyc](https://github.com/cofyc)) [SIG Scheduling and Testing]
+- Resolve regression in metadata.managedFields handling in update/patch requests submitted by older API clients ([#91748](https://github.com/kubernetes/kubernetes/pull/91748), [@apelisse](https://github.com/apelisse)) [SIG API Machinery and Testing]
+- The CertificateSigningRequest API is promoted to certificates.k8s.io/v1 with the following changes:
+  - `spec.signerName` is now required, and requests for `kubernetes.io/legacy-unknown` are not allowed to be created via the `certificates.k8s.io/v1` API
+  - `spec.usages` is now required, may not contain duplicate values, and must only contain known usages
+  - `status.conditions` may not contain duplicate types
+  - `status.conditions[*].status` is now required
+  - `status.certificate` must be PEM-encoded, and contain only CERTIFICATE blocks ([#91685](https://github.com/kubernetes/kubernetes/pull/91685), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Architecture, Auth, CLI and Testing]
+- The Kubelet's `--cloud-provider` and `--cloud-config` options are now marked as deprecated. ([#90408](https://github.com/kubernetes/kubernetes/pull/90408), [@knabben](https://github.com/knabben)) [SIG Cloud Provider and Node]
+
+### Feature
+
+- A new extension point `PostFilter` is introduced to scheduler framework which runs after Filter phase to resolve scheduling filter failures. A typical implementation is running preemption logic. ([#91314](https://github.com/kubernetes/kubernetes/pull/91314), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Added --privileged flag to kubectl run ([#90569](https://github.com/kubernetes/kubernetes/pull/90569), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- Enable feature Gate DefaultPodTopologySpread to use PodTopologySpread plugin to do defaultspreading. In doing so, legacy DefaultPodTopologySpread plugin is disabled. ([#91793](https://github.com/kubernetes/kubernetes/pull/91793), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Extend AWS azToRegion method to support Local Zones ([#90874](https://github.com/kubernetes/kubernetes/pull/90874), [@Jeffwan](https://github.com/Jeffwan)) [SIG Cloud Provider]
+- Kube-Proxy now supports IPv6DualStack on Windows with the IPv6DualStack feature gate. ([#90853](https://github.com/kubernetes/kubernetes/pull/90853), [@kumarvin123](https://github.com/kumarvin123)) [SIG Network, Node and Windows]
+- Kube-controller-manager: the `--experimental-cluster-signing-duration` flag is marked as deprecated for removal in v1.22, and is replaced with `--cluster-signing-duration`. ([#91154](https://github.com/kubernetes/kubernetes/pull/91154), [@liggitt](https://github.com/liggitt)) [SIG Auth and Cloud Provider]
+- Support kubectl create deployment with replicas ([#91562](https://github.com/kubernetes/kubernetes/pull/91562), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- The RotateKubeletClientCertificate feature gate has been promoted to GA, and the kubelet --feature-gate RotateKubeletClientCertificate parameter will be removed in 1.20. ([#91780](https://github.com/kubernetes/kubernetes/pull/91780), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- The metric label name of `kubernetes_build_info` has been updated from `camel case` to `snake case`:
+  - gitVersion --> git_version
+  - gitCommit --> git_commit
+  - gitTreeState --> git_tree_state
+  - buildDate --> build_date
+  - goVersion --> go_version
+  
+  This change happens in `kube-apiserver`、`kube-scheduler`、`kube-proxy` and `kube-controller-manager`. ([#91805](https://github.com/kubernetes/kubernetes/pull/91805), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
+- `EventRecorder()` is exposed to `FrameworkHandle` interface so that scheduler plugin developers can choose to log cluster-level events. ([#92010](https://github.com/kubernetes/kubernetes/pull/92010), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+
+### Bug or Regression
+
+- Azure: set dest prefix and port for IPv6 inbound security rule ([#91831](https://github.com/kubernetes/kubernetes/pull/91831), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Fix etcd version migration script in etcd image. ([#91925](https://github.com/kubernetes/kubernetes/pull/91925), [@wenjiaswe](https://github.com/wenjiaswe)) [SIG API Machinery]
+- Fix issues when supported huge page sizes changes ([#80831](https://github.com/kubernetes/kubernetes/pull/80831), [@odinuge](https://github.com/odinuge)) [SIG Node and Testing]
+- Fix kubectl describe output format for empty annotations. ([#91405](https://github.com/kubernetes/kubernetes/pull/91405), [@iyashu](https://github.com/iyashu)) [SIG CLI]
+- Fixed an issue that a Pod's nominatedNodeName cannot be cleared upon node deletion. ([#91750](https://github.com/kubernetes/kubernetes/pull/91750), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Fixed several bugs involving the IPFamily field when creating or updating services
+  in clusters with the IPv6DualStack feature gate enabled.
+  
+  Beware that the behavior of the IPFamily field is strange and inconsistent and will
+  likely be changed before the dual-stack feature goes GA. Users should treat the
+  field as "write-only" for now and should not make any assumptions about a service
+  based on its current IPFamily value. ([#91400](https://github.com/kubernetes/kubernetes/pull/91400), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network]
+- Kube-apiserver: fixes scale subresource patch handling to avoid returning unnecessary 409 Conflict error to clients ([#90342](https://github.com/kubernetes/kubernetes/pull/90342), [@liggitt](https://github.com/liggitt)) [SIG Apps, Autoscaling and Testing]
+- Kube-up: fixes setup of validating admission webhook credential configuration ([#91995](https://github.com/kubernetes/kubernetes/pull/91995), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Cluster Lifecycle]
+- Kubeadm: Add retries for kubeadm join / UpdateStatus to make update status more resilient by adding a retry loop to this operation ([#91952](https://github.com/kubernetes/kubernetes/pull/91952), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- On AWS nodes with multiple network interfaces, kubelet should now more reliably report addresses from secondary interfaces. ([#91889](https://github.com/kubernetes/kubernetes/pull/91889), [@anguslees](https://github.com/anguslees)) [SIG Cloud Provider]
+- Resolve regression in metadata.managedFields handling in create/update/patch requests not using server-side apply ([#91690](https://github.com/kubernetes/kubernetes/pull/91690), [@apelisse](https://github.com/apelisse)) [SIG API Machinery and Testing]
+
+### Other (Cleanup or Flake)
+
+- Deprecate the `--target-ram-md` flags that is no longer used for anything. ([#91818](https://github.com/kubernetes/kubernetes/pull/91818), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+- Replace framework.Failf with ExpectNoError ([#91811](https://github.com/kubernetes/kubernetes/pull/91811), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG Instrumentation, Storage and Testing]
+- The Kubelet's `--experimental-allocatable-ignore-eviction` option is now marked as deprecated. ([#91578](https://github.com/kubernetes/kubernetes/pull/91578), [@knabben](https://github.com/knabben)) [SIG Node]
+- Update corefile-migration library to 1.0.8 ([#91856](https://github.com/kubernetes/kubernetes/pull/91856), [@wawa0210](https://github.com/wawa0210)) [SIG Node]
+
+## Dependencies
+
+### Added
+_Nothing has changed._
+
+### Changed
+- github.com/Azure/azure-sdk-for-go: [v40.2.0+incompatible → v43.0.0+incompatible](https://github.com/Azure/azure-sdk-for-go/compare/v40.2.0...v43.0.0)
+- github.com/coredns/corefile-migration: [v1.0.6 → v1.0.8](https://github.com/coredns/corefile-migration/compare/v1.0.6...v1.0.8)
+- k8s.io/klog/v2: v2.0.0 → v2.1.0
+
+### Removed
+_Nothing has changed._
+
+
+
+# v1.19.0-beta.1
+
+
+## Downloads for v1.19.0-beta.1
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes.tar.gz) | c4ab79e987790fbda842310525abecee60861e44374c414159e60d74e85b4dd36d9d49253b8e7f08aec36a031726f9517d0a401fb748e41835ae2dc86aee069d
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-src.tar.gz) | 08d1aadb8a31b35f3bc39f44d8f97b7e98951f833bb87f485f318c6acfdb53539851fbb2d4565036e00b6f620c5b1882c6f9620759c3b36833da1d6b2b0610f2
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-darwin-386.tar.gz) | 55eb230fdb4e60ded6c456ec6e03363c6d55e145a956aa5eff0c2b38d8ecfe848b4a404169def45d392e747e4d04ee71fe3182ab1e6426110901ccfb2e1bc17f
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | ddc03644081928bd352c40077f2a075961c90a7159964be072b3e05ec170a17d6d78182d90210c18d24d61e75b45eae3d1b1486626db9e28f692dfb33196615c
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-386.tar.gz) | 6e1e00a53289bd9a4d74a61fce4665786051aafe8fef8d1d42de88ba987911bfb7fd5f4a2c3771ae830819546cf9f4badd94fd90c50ca74367c1ace748e8eafd
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | 2c4db87c61bc4a528eb2af9246648fc7a015741fe52f551951fda786c252eca1dc48a4325be70e6f80f1560f773b763242334ad4fe06657af290e610f10bc231
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-arm.tar.gz) | 8a2bebf67cbd8f91ba38edc36a239aa50d3e58187827763eb5778a5ca0d9d35be97e193b794bff415e8f5de071e47659033dc0420e038d78cc32e841a417a62a
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | f2d0029efc03bf17554c01c11e77b161b8956d9da4b17962ca878378169cbdee04722bbda87279f4b7431c91db0e92bfede45dcc6d971f34d3fe891339b7c47b
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | 45eb3fe40951ba152f05aa0fe41b7c17ffb91ee3cecb12ec19d2d9cdb467267c1eb5696660687852da314eb8a14a9ebf5f5da21eca252e1c2e3b18dca151ad0d
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | 2097ac5d593dd0951a34df9bdf7883b5c228da262042904ee3a2ccfd1f9c955ff6a3a59961850053e41646bce8fc70a023efe9e9fe49f14f9a6276c8da22f907
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-windows-386.tar.gz) | c38b034e8ac3a5972a01f36b184fe1a195f6a422a3c6564f1f3faff858b1220173b6ab934e7b7ec200931fd7d9456e947572620d82d02e7b05fc61a7fb67ec70
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | 0501694734381914882836e067dc177e8bccd48a4826e286017dc5f858f27cdef348edbb664dda59162f6cd3ac14a9e491e314a3ea032dec43bc77610ce8c8bc
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | 0dd2058889eabbf0b05b6fafd593997ff9911467f0fc567c142583adf0474f4d0e2f4024b4906ff9ee4264d1cbbfde66596ccb8c73b3d5bb79f67e5eb4b3258a
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-arm.tar.gz) | 9c3a33d7c198116386178a4f8ee7d4df82e810d6f26833f19f93eff112c29f9f89e5ee790013ad1d497856ecb2662ee95a49fc6a41f0d33cc67e431d06135b88
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | 11f83132f729bec4a4d84fc1983dbd5ddd1643d000dc74c6e05f35637de21533834a572692fc1281c7b0bd29ee93e721fb00e276983e36c327a1950266b17f6d
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | 949334065d968f10207089db6175dcc4bf9432b3b48b120f689cd39c56562a0f4f60d774c95a20a5391d0467140a4c3cb6b2a2dfedccfda6c20f333a63ebcf81
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | 29e8f6a22969d8ab99bf6d272215f53d8f7a125d0c5c20981dcfe960ed440369f831c71a94bb61974b486421e4e9ed936a9421a1be6f02a40e456daab4995663
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | 3d9767e97a40b501f29bbfc652c8fd841eae1dee22a97fdc20115e670081de7fa8e84f6e1be7bbf2376b59c5eef15fb5291415ae2e24ce4c9c5e141faa38c47c
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-arm.tar.gz) | 8ccf401e0bd0c59403af49046b49cf556ff164fca12c5233169a80e18cc4367f404fd7edd236bb862bff9fd25b687d48a8d57d5567809b89fd2727549d0dc48f
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | 3e1fa2bde05a4baec6ddd43cd1994d155a143b9c825ab5dafe766efc305cb1aad92d6026c41c05e9da114a04226361fb6b0510b98e3b05c3ed510da23db403b3
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | 01df4be687f5634afa0ab5ef06f8cee17079264aa452f00a45eccb8ace654c9acc6582f4c74e8242e6ca7715bc48bf2a7d2c4d3d1eef69106f99c8208bc245c4
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | 5523b0b53c30b478b1a9e1df991607886acdcde8605e1b44ef91c94993ca2256c74f6e38fbdd24918d7dbf7afd5cd73d24a3f7ff911e9762819776cc19935363
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | 8e7ebf000bc8dec1079a775576807c0a11764d20a59e16f89d93c948532ba5e6864efd3e08c3e8cc5bd7e7f97bb65baefbf2f01cb226897abd5e01997a4c4f75
+
+## Changelog since v1.19.0-alpha.3
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+ - ACTION REQUIRED : Switch core master base images (kube-controller-manager) from debian to distroless. If you need Flex Volumes support using scripts, please build your own image with required packages (like bash) ([#91329](https://github.com/kubernetes/kubernetes/pull/91329), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release, Storage and Testing]
+  - Kubeadm: Move the "kubeadm init" phase "kubelet-start" later in the init workflow, after the "kubeconfig" phase. This makes kubeadm start the kubelet only after the KubeletConfiguration component config file (/var/lib/kubelet/config.yaml) is generated and solves a problem where init systems like OpenRC cannot crashloop the kubelet service. ([#90892](https://github.com/kubernetes/kubernetes/pull/90892), [@xphoniex](https://github.com/xphoniex)) [SIG Cluster Lifecycle]
+ 
+## Changes by Kind
+
+### API Change
+
+- CertificateSigningRequest API conditions were updated:
+  - a `status` field was added; this field defaults to `True`, and may only be set to `True` for `Approved`, `Denied`, and `Failed` conditions
+  - a `lastTransitionTime` field was added
+  - a `Failed` condition type was added to allow signers to indicate permanent failure; this condition can be added via the `certificatesigningrequests/status` subresource.
+  - `Approved` and `Denied` conditions are mutually exclusive
+  - `Approved`, `Denied`, and `Failed` conditions can no longer be removed from a CSR ([#90191](https://github.com/kubernetes/kubernetes/pull/90191), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, Auth, CLI and Node]
+- EnvVarSource api doc bug fixes ([#91194](https://github.com/kubernetes/kubernetes/pull/91194), [@wawa0210](https://github.com/wawa0210)) [SIG Apps]
+- Fixed: log timestamps now include trailing zeros to maintain a fixed width ([#91207](https://github.com/kubernetes/kubernetes/pull/91207), [@iamchuckss](https://github.com/iamchuckss)) [SIG Apps and Node]
+- The Kubelet's --node-status-max-images option is now available via the Kubelet config file field nodeStatusMaxImage ([#91275](https://github.com/kubernetes/kubernetes/pull/91275), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's --seccomp-profile-root option is now available via the Kubelet config file field seccompProfileRoot. ([#91182](https://github.com/kubernetes/kubernetes/pull/91182), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--enable-server` and `--provider-id` option is now available via the Kubelet config file field `enableServer` and `providerID` respectively. ([#90494](https://github.com/kubernetes/kubernetes/pull/90494), [@knabben](https://github.com/knabben)) [SIG Node]
+- The Kubelet's `--really-crash-for-testing` and  `--chaos-chance` options are now marked as deprecated. ([#90499](https://github.com/kubernetes/kubernetes/pull/90499), [@knabben](https://github.com/knabben)) [SIG Node]
+- The alpha `DynamicAuditing` feature gate and `auditregistration.k8s.io/v1alpha1` API have been removed and are no longer supported. ([#91502](https://github.com/kubernetes/kubernetes/pull/91502), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and Testing]
+- `NodeResourcesLeastAllocated` and `NodeResourcesMostAllocated` plugins now support customized weight on the CPU and memory. ([#90544](https://github.com/kubernetes/kubernetes/pull/90544), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+- `PostFilter` type is added to scheduler component config API on version v1beta1. ([#91547](https://github.com/kubernetes/kubernetes/pull/91547), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- `kubescheduler.config.k8s.io` is now beta ([#91420](https://github.com/kubernetes/kubernetes/pull/91420), [@pancernik](https://github.com/pancernik)) [SIG Scheduling]
+
+### Feature
+
+- Add --logging-format flag for component-base. Defaults to "text" using unchanged klog. ([#89683](https://github.com/kubernetes/kubernetes/pull/89683), [@yuzhiquan](https://github.com/yuzhiquan)) [SIG Instrumentation]
+- Add --port flag to kubectl create deployment ([#91113](https://github.com/kubernetes/kubernetes/pull/91113), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
+- Add .import-restrictions file to cmd/cloud-controller-manager. ([#90630](https://github.com/kubernetes/kubernetes/pull/90630), [@nilo19](https://github.com/nilo19)) [SIG API Machinery and Cloud Provider]
+- Add Annotations to CRI-API ImageSpec objects. ([#90061](https://github.com/kubernetes/kubernetes/pull/90061), [@marosset](https://github.com/marosset)) [SIG Node and Windows]
+- Added feature support to Windows for configuring session affinity of Kubernetes services.
+  required: [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) (or higher) ([#91701](https://github.com/kubernetes/kubernetes/pull/91701), [@elweb9858](https://github.com/elweb9858)) [SIG Network and Windows]
+- Added service.beta.kubernetes.io/aws-load-balancer-target-node-labels annotation to target nodes in AWS LoadBalancer Services ([#90943](https://github.com/kubernetes/kubernetes/pull/90943), [@foobarfran](https://github.com/foobarfran)) [SIG Cloud Provider]
+- Feat: azure disk migration go beta in 1.19 ([#90896](https://github.com/kubernetes/kubernetes/pull/90896), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-addon-manager has been updated to v9.1.1 to allow overriding the default list of whitelisted resources (https://github.com/kubernetes/kubernetes/pull/91018) ([#91240](https://github.com/kubernetes/kubernetes/pull/91240), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing]
+- Kubeadm now distinguishes between generated and user supplied component configs, regenerating the former ones if a config upgrade is required ([#86070](https://github.com/kubernetes/kubernetes/pull/86070), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: add startup probes for static Pods to protect slow starting containers ([#91179](https://github.com/kubernetes/kubernetes/pull/91179), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubelets configured to rotate client certificates now publish a `certificate_manager_server_ttl_seconds` gauge metric indicating the remaining seconds until certificate expiration. ([#91148](https://github.com/kubernetes/kubernetes/pull/91148), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Local-up-cluster.sh installs CSI snapshotter by default now, can be disabled with ENABLE_CSI_SNAPSHOTTER=false. ([#91504](https://github.com/kubernetes/kubernetes/pull/91504), [@pohly](https://github.com/pohly)) [SIG Storage]
+- Rest.Config now supports a flag to override proxy configuration that was previously only configurable through environment variables. ([#81443](https://github.com/kubernetes/kubernetes/pull/81443), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery and Node]
+- Scores from PodTopologySpreading have reduced differentiation as maxSkew increases. ([#90820](https://github.com/kubernetes/kubernetes/pull/90820), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Service controller: only sync LB node pools when relevant fields in Node changes ([#90769](https://github.com/kubernetes/kubernetes/pull/90769), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+- Switch core master base images (kube-apiserver, kube-scheduler) from debian to distroless ([#90674](https://github.com/kubernetes/kubernetes/pull/90674), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release and Scalability]
+- Switch etcd image (with migration scripts) from debian to distroless ([#91171](https://github.com/kubernetes/kubernetes/pull/91171), [@dims](https://github.com/dims)) [SIG API Machinery and Cloud Provider]
+- The `certificatesigningrequests/approval` subresource now supports patch API requests ([#91558](https://github.com/kubernetes/kubernetes/pull/91558), [@liggitt](https://github.com/liggitt)) [SIG Auth and Testing]
+- Update cri-tools to v1.18.0 ([#89720](https://github.com/kubernetes/kubernetes/pull/89720), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cloud Provider, Cluster Lifecycle, Release and Scalability]
+- Weight of PodTopologySpread scheduling Score is doubled. ([#91258](https://github.com/kubernetes/kubernetes/pull/91258), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- `maxThreshold` of `ImageLocality` plugin is now scaled by the number of images in the pod, which helps to distinguish the node priorities for pod with several images. ([#91138](https://github.com/kubernetes/kubernetes/pull/91138), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+
+### Bug or Regression
+
+- Add support for TLS 1.3 ciphers: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 and TLS_AES_256_GCM_SHA384. ([#90843](https://github.com/kubernetes/kubernetes/pull/90843), [@pjbgf](https://github.com/pjbgf)) [SIG API Machinery, Auth and Cluster Lifecycle]
+- Base-images: Update to kube-cross:v1.13.9-5 ([#90963](https://github.com/kubernetes/kubernetes/pull/90963), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+- CloudNodeLifecycleController will check node existence status before shutdown status when monitoring nodes. ([#90737](https://github.com/kubernetes/kubernetes/pull/90737), [@jiahuif](https://github.com/jiahuif)) [SIG Apps and Cloud Provider]
+- First pod with required affinity terms can schedule only on nodes with matching topology keys. ([#91168](https://github.com/kubernetes/kubernetes/pull/91168), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- Fix VirtualMachineScaleSets.virtualMachines.GET not allowed issues when customers have set VMSS orchestrationMode. ([#91097](https://github.com/kubernetes/kubernetes/pull/91097), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix a racing issue that scheduler may perform unnecessary scheduling attempt. ([#90660](https://github.com/kubernetes/kubernetes/pull/90660), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+- Fix kubectl create --dryrun client ignore namespace ([#90502](https://github.com/kubernetes/kubernetes/pull/90502), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix kubectl create secret docker-registry --from-file not usable ([#90960](https://github.com/kubernetes/kubernetes/pull/90960), [@zhouya0](https://github.com/zhouya0)) [SIG CLI and Testing]
+- Fix kubectl describe node for users not having access to lease information. ([#90469](https://github.com/kubernetes/kubernetes/pull/90469), [@uthark](https://github.com/uthark)) [SIG CLI]
+- Fix kubectl run  --dry-run client  ignore namespace ([#90785](https://github.com/kubernetes/kubernetes/pull/90785), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix public IP not shown issues after assigning public IP to Azure VMs ([#90886](https://github.com/kubernetes/kubernetes/pull/90886), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix: add azure file migration support on annotation support ([#91093](https://github.com/kubernetes/kubernetes/pull/91093), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Node]
+- Fix: azure disk dangling attach issue which would cause API throttling ([#90749](https://github.com/kubernetes/kubernetes/pull/90749), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: fix topology issue in azure disk storage class migration ([#91196](https://github.com/kubernetes/kubernetes/pull/91196), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: support removal of nodes backed by deleted non VMSS instances on Azure ([#91184](https://github.com/kubernetes/kubernetes/pull/91184), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+- Fixed a regression preventing garbage collection of RBAC role and binding objects ([#90534](https://github.com/kubernetes/kubernetes/pull/90534), [@apelisse](https://github.com/apelisse)) [SIG Auth]
+- For external storage e2e test suite, update external driver, to pick snapshot provisioner from VolumeSnapshotClass, when a VolumeSnapshotClass is explicitly provided as an input. ([#90878](https://github.com/kubernetes/kubernetes/pull/90878), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing]
+- Get-kube.sh: fix order to get the binaries from the right bucket ([#91635](https://github.com/kubernetes/kubernetes/pull/91635), [@cpanato](https://github.com/cpanato)) [SIG Release]
+- In a HA env, during the period a standby scheduler lost connection to API server, if a Pod is deleted and recreated, and the standby scheduler becomes master afterwards, there could be a scheduler cache corruption. This PR fixes this issue. ([#91126](https://github.com/kubernetes/kubernetes/pull/91126), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- Kubeadm: during "reset" do not remove the only remaining stacked etcd member from the cluster and just proceed with the cleanup of the local etcd storage. ([#91145](https://github.com/kubernetes/kubernetes/pull/91145), [@tnqn](https://github.com/tnqn)) [SIG Cluster Lifecycle]
+- Kubeadm: increase robustness for "kubeadm join" when adding etcd members on slower setups ([#90645](https://github.com/kubernetes/kubernetes/pull/90645), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Pod Conditions updates are skipped for re-scheduling attempts ([#91252](https://github.com/kubernetes/kubernetes/pull/91252), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Prevent PVC requested size overflow when expanding or creating a volume ([#90907](https://github.com/kubernetes/kubernetes/pull/90907), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage]
+- Resolves an issue using `kubectl certificate approve/deny` against a server serving the v1 CSR API ([#91691](https://github.com/kubernetes/kubernetes/pull/91691), [@liggitt](https://github.com/liggitt)) [SIG Auth and CLI]
+- Scheduling failures due to no nodes available are now reported as unschedulable under ```schedule_attempts_total``` metric. ([#90989](https://github.com/kubernetes/kubernetes/pull/90989), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- The following components that do not expect non-empty, non-flag arguments will now print an error message and exit if an argument is specified: cloud-controller-manager, kube-apiserver, kube-controller-manager, kube-proxy, kubeadm {alpha|config|token|version}, kubemark. Flags should be prefixed with a single dash "-" (0x45) for short form or double dash "--" for long form. Before this change, malformed flags (for example, starting with a non-ascii dash character such as 0x8211: "–") would have been silently treated as positional arguments and ignored. ([#91349](https://github.com/kubernetes/kubernetes/pull/91349), [@neolit123](https://github.com/neolit123)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle, Network and Scheduling]
+- When evicting, Pods in Pending state are removed without checking PDBs. ([#83906](https://github.com/kubernetes/kubernetes/pull/83906), [@michaelgugino](https://github.com/michaelgugino)) [SIG API Machinery, Apps, Node and Scheduling]
+
+### Other (Cleanup or Flake)
+
+- Adds additional testing to ensure that udp pods conntrack are cleaned up ([#90180](https://github.com/kubernetes/kubernetes/pull/90180), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Architecture, Network and Testing]
+- Adjusts the fsType for cinder values to be `ext4` if no fsType is specified. ([#90608](https://github.com/kubernetes/kubernetes/pull/90608), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
+- Change beta.kubernetes.io/os to kubernetes.io/os ([#89461](https://github.com/kubernetes/kubernetes/pull/89461), [@wawa0210](https://github.com/wawa0210)) [SIG Cloud Provider and Cluster Lifecycle]
+- Content-type and verb for request metrics are now bounded to a known set. ([#89451](https://github.com/kubernetes/kubernetes/pull/89451), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery and Instrumentation]
+- Emit `WaitingForPodScheduled` event if the unbound PVC is in delay binding mode but used by a pod ([#91455](https://github.com/kubernetes/kubernetes/pull/91455), [@cofyc](https://github.com/cofyc)) [SIG Storage]
+- Improve server-side apply conflict errors by setting dedicated kubectl subcommand field managers ([#88885](https://github.com/kubernetes/kubernetes/pull/88885), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- It is now possible to use the service annotation `cloud.google.com/network-tier: Standard` to configure the Network Tier of the GCE Loadbalancer ([#88532](https://github.com/kubernetes/kubernetes/pull/88532), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider, Network and Testing]
+- Kube-scheduler: The metric name `scheduler_total_preemption_attempts` has been renamed to `scheduler_preemption_attempts_total`. ([#91448](https://github.com/kubernetes/kubernetes/pull/91448), [@RainbowMango](https://github.com/RainbowMango)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Scheduling]
+- Kubeadm now forwards the IPv6DualStack feature gate using the kubelet component config, instead of the kubelet command line ([#90840](https://github.com/kubernetes/kubernetes/pull/90840), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: do not use a DaemonSet for the pre-pull of control-plane images during "kubeadm upgrade apply". Individual node upgrades now pull the required images using a preflight check. The flag "--image-pull-timeout" for "kubeadm upgrade apply" is now deprecated and will be removed in a future release following a GA deprecation policy. ([#90788](https://github.com/kubernetes/kubernetes/pull/90788), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+- Kubeadm: use two separate checks on /livez and /readyz for the kube-apiserver static Pod instead of using /healthz ([#90970](https://github.com/kubernetes/kubernetes/pull/90970), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+- NONE ([#91597](https://github.com/kubernetes/kubernetes/pull/91597), [@elmiko](https://github.com/elmiko)) [SIG Autoscaling and Testing]
+- Remove deprecated --server-dry-run flag from kubectl apply ([#91308](https://github.com/kubernetes/kubernetes/pull/91308), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- The "HostPath should give a volume the correct mode" is no longer a conformance test ([#90861](https://github.com/kubernetes/kubernetes/pull/90861), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+- The Kubelet's --experimental-mounter-path and --experimental-check-node-capabilities-before-mount options are now marked as deprecated. ([#91373](https://github.com/kubernetes/kubernetes/pull/91373), [@knabben](https://github.com/knabben)) [SIG Node]
+- The kube-apiserver `--kubelet-https` flag is deprecated. kube-apiserver connections to kubelets now unconditionally use `https` (kubelets have unconditionally used `https` to serve the endpoints the apiserver communicates with since before v1.0). ([#91630](https://github.com/kubernetes/kubernetes/pull/91630), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Node]
+- Update CNI to v0.8.6 ([#91370](https://github.com/kubernetes/kubernetes/pull/91370), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Release and Testing]
+- `beta.kubernetes.io/os` and `beta.kubernetes.io/arch` node labels are deprecated. Update node selectors to use `kubernetes.io/os` and `kubernetes.io/arch`. ([#91046](https://github.com/kubernetes/kubernetes/pull/91046), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and Node]
+- base-images: Use debian-base:v2.1.0 ([#90697](https://github.com/kubernetes/kubernetes/pull/90697), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery and Release]
+- base-images: Use debian-iptables:v12.1.0 ([#90782](https://github.com/kubernetes/kubernetes/pull/90782), [@justaugustus](https://github.com/justaugustus)) [SIG Release]
+
+## Dependencies
+
+### Added
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/containerd/cgroups: [bf292b2](https://github.com/containerd/cgroups/tree/bf292b2)
+- github.com/containerd/continuity: [aaeac12](https://github.com/containerd/continuity/tree/aaeac12)
+- github.com/containerd/fifo: [a9fb20d](https://github.com/containerd/fifo/tree/a9fb20d)
+- github.com/containerd/go-runc: [5a6d9f3](https://github.com/containerd/go-runc/tree/5a6d9f3)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/google/renameio: [v0.1.0](https://github.com/google/renameio/tree/v0.1.0)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/rogpeppe/go-internal: [v1.3.0](https://github.com/rogpeppe/go-internal/tree/v1.3.0)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- golang.org/x/mod: v0.1.0
+- google.golang.org/protobuf: v1.23.0
+- gopkg.in/errgo.v2: v2.1.0
+- k8s.io/klog/v2: v2.0.0
+
+### Changed
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/Microsoft/hcsshim: [672e52e → v0.8.9](https://github.com/Microsoft/hcsshim/compare/672e52e...v0.8.9)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.3 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.3...v1.4.2)
+- github.com/google/cadvisor: [8af10c6 → 6a8d614](https://github.com/google/cadvisor/compare/8af10c6...6a8d614)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.9](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.9)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.6.0](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.6.0)
+- github.com/prometheus/common: [v0.4.1 → v0.9.1](https://github.com/prometheus/common/compare/v0.4.1...v0.9.1)
+- github.com/prometheus/procfs: [v0.0.5 → v0.0.11](https://github.com/prometheus/procfs/compare/v0.0.5...v0.0.11)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: f3c370f → ca5a221
+- honnef.co/go/tools: e561f67 → v0.0.1-2019.2.3
+- k8s.io/gengo: e0e292d → 8167cfd
+- k8s.io/kube-openapi: e1beb1b → 656914f
+- k8s.io/utils: a9aa75a → 2df71eb
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → 33b9978
+
+### Removed
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- k8s.io/klog: v1.0.0
+
+
+
+# v1.19.0-beta.0
+
+
+## Downloads for v1.19.0-beta.0
+
+### Source Code
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes.tar.gz) | 8c7e820b8bd7a8f742b7560cafe6ae1acc4c9836ae23d1b10d987b4de6a690826be75c68b8f76ec027097e8dfd861afb1d229b3687f0b82afcfe7b4d6481242e
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-src.tar.gz) | 543e9d36fd8b2de3e19631d3295d3a7706e6e88bbd3adb2d558b27b3179a3961455f4f04f0d4a5adcff1466779e1b08023fe64dc2ab39813b37adfbbc779dec7
+
+### Client binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-darwin-386.tar.gz) | 3ef37ef367a8d9803f023f6994d73ff217865654a69778c1ea3f58c88afbf25ff5d8d6bec9c608ac647c2654978228c4e63f30eec2a89d16d60f4a1c5f333b22
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-darwin-amd64.tar.gz) | edb02b0b8d6a1c2167fbce4a85d84fb413566d3a76839fd366801414ca8ad2d55a5417b39b4cac6b65fddf13c1b3259791a607703773241ca22a67945ecb0014
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-386.tar.gz) | dafe93489df7328ae23f4bdf0a9d2e234e18effe7e042b217fe2dd1355e527a54bab3fb664696ed606a8ebedce57da4ee12647ec1befa2755bd4c43d9d016063
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-amd64.tar.gz) | d8e2bf8c9dd665410c2e7ceaa98bc4fc4f966753b7ade91dcef3b5eff45e0dda63bd634610c8761392a7804deb96c6b030c292280bf236b8b29f63b7f1af3737
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-arm.tar.gz) | d590d3d07d0ebbb562bce480c7cbe4e60b99feba24376c216fe73d8b99a246e2cd2acb72abe1427bde3e541d94d55b7688daf9e6961e4cbc6b875ac4eeea6e62
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-arm64.tar.gz) | f9647a99a566c9febd348c1c4a8e5c05326058eab076292a8bb5d3a2b882ee49287903f8e0e036b40af294aa3571edd23e65f3de91330ac9af0c10350b02583d
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-ppc64le.tar.gz) | 662f009bc393734a89203d7956942d849bad29e28448e7baa017d1ac2ec2d26d7290da4a44bccb99ed960b2e336d9d98908c98f8a3d9fe1c54df2d134c799cad
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-linux-s390x.tar.gz) | 61fdf4aff78dcdb721b82a3602bf5bc94d44d51ab6607b255a9c2218bb3e4b57f6e656c2ee0dd68586fb53acbeff800d6fd03e4642dded49735a93356e7c5703
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-windows-386.tar.gz) | 20d1e803b10b3bee09a7a206473ba320cc5f1120278d8f6e0136c388b2720da7264b917cd4738488b1d0a9aa922eb581c1f540715a6c2042c4dd7b217b6a9a0a
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-client-windows-amd64.tar.gz) | b85d729ec269f6aad0b6d2f95f3648fbea84330d2fbfde2267a519bc08c42d70d7b658b0e41c3b0d5f665702a8f1bbb37652753de34708ae3a03e45175c8b92c
+
+### Server binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-amd64.tar.gz) | c3641bdb0a8d8eff5086d24b71c6547131092b21f976b080dc48129f91de3da560fed6edf880eab1d205017ad74be716a5b970e4bbc00d753c005e5932b3d319
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-arm.tar.gz) | 7c29b8e33ade23a787330d28da22bf056610dae4d3e15574c56c46340afe5e0fdb00126ae3fd64fd70a26d1a87019f47e401682b88fa1167368c7edbecc72ccf
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-arm64.tar.gz) | 27cd6042425eb94bb468431599782467ed818bcc51d75e8cb251c287a806b60a5cce50d4ae7525348c5446eaa45f849bc3fe3e6ac7248b54f3ebae8bf6553c3f
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-ppc64le.tar.gz) | ede896424eb12ec07dd3756cbe808ca3915f51227e7b927795402943d81a99bb61654fd8f485a838c2faf199d4a55071af5bd8e69e85669a7f4a0b0e84a093cc
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-server-linux-s390x.tar.gz) | 4e48d4f5afd22f0ae6ade7da4877238fd2a5c10ae3dea2ae721c39ac454b0b295e1d7501e26bddee4bc0289e79e33dadca255a52a645bee98cf81acf937db0ef
+
+### Node binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-amd64.tar.gz) | 8025bd8deb9586487fcf268bdaf99e8fd9f9433d9e7221c29363d1d66c4cbd55a2c44e6c89bc8133828c6a1aa0c42c2359b74846dfb71765c9ae8f21b8170625
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-arm.tar.gz) | 25787d47c8cc1e9445218d3a947b443d261266033187f8b7bc6141ae353a6806503fe72e3626f058236d4cd7f284348d2cc8ccb7a0219b9ddd7c6a336dae360b
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-arm64.tar.gz) | ff737a7310057bdfd603f2853b15f79dc2b54a3cbbbd7a8ffd4d9756720fa5a02637ffc10a381eeee58bef61024ff348a49f3044a6dfa0ba99645fda8d08e2da
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-ppc64le.tar.gz) | 2b1144c9ae116306a2c3214b02361083a60a349afc804909f95ea85db3660de5025de69a1860e8fc9e7e92ded335c93b74ecbbb20e1f6266078842d4adaf4161
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-linux-s390x.tar.gz) | 822ec64aef3d65faa668a91177aa7f5d0c78a83cc1284c5e30629eda448ee4b2874cf4cfa6f3d68ad8eb8029dd035bf9fe15f68cc5aa4b644513f054ed7910ae
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-beta.0/kubernetes-node-windows-amd64.tar.gz) | 3957cae43211df050c5a9991a48e23ac27d20aec117c580c53fc7edf47caf79ed1e2effa969b5b972968a83e9bdba0b20c46705caca0c35571713041481c1966
+
+## Changelog since v1.19.0-alpha.3
+
+## Changes by Kind
+
+### API Change
+ - EnvVarSource api doc bug fixes ([#91194](https://github.com/kubernetes/kubernetes/pull/91194), [@wawa0210](https://github.com/wawa0210)) [SIG Apps]
+ - The Kubelet's `--really-crash-for-testing` and  `--chaos-chance` options are now marked as deprecated. ([#90499](https://github.com/kubernetes/kubernetes/pull/90499), [@knabben](https://github.com/knabben)) [SIG Node]
+ - `NodeResourcesLeastAllocated` and `NodeResourcesMostAllocated` plugins now support customized weight on the CPU and memory. ([#90544](https://github.com/kubernetes/kubernetes/pull/90544), [@chendave](https://github.com/chendave)) [SIG Scheduling]
+
+### Feature
+ - Add .import-restrictions file to cmd/cloud-controller-manager. ([#90630](https://github.com/kubernetes/kubernetes/pull/90630), [@nilo19](https://github.com/nilo19)) [SIG API Machinery and Cloud Provider]
+ - Add Annotations to CRI-API ImageSpec objects. ([#90061](https://github.com/kubernetes/kubernetes/pull/90061), [@marosset](https://github.com/marosset)) [SIG Node and Windows]
+ - Kubelets configured to rotate client certificates now publish a `certificate_manager_server_ttl_seconds` gauge metric indicating the remaining seconds until certificate expiration. ([#91148](https://github.com/kubernetes/kubernetes/pull/91148), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+ - Rest.Config now supports a flag to override proxy configuration that was previously only configurable through environment variables. ([#81443](https://github.com/kubernetes/kubernetes/pull/81443), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery and Node]
+ - Scores from PodTopologySpreading have reduced differentiation as maxSkew increases. ([#90820](https://github.com/kubernetes/kubernetes/pull/90820), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+ - Service controller: only sync LB node pools when relevant fields in Node changes ([#90769](https://github.com/kubernetes/kubernetes/pull/90769), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+ - Switch core master base images (kube-apiserver, kube-scheduler) from debian to distroless ([#90674](https://github.com/kubernetes/kubernetes/pull/90674), [@dims](https://github.com/dims)) [SIG Cloud Provider, Release and Scalability]
+ - Update cri-tools to v1.18.0 ([#89720](https://github.com/kubernetes/kubernetes/pull/89720), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cloud Provider, Cluster Lifecycle, Release and Scalability]
+
+### Bug or Regression
+ - Add support for TLS 1.3 ciphers: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 and TLS_AES_256_GCM_SHA384. ([#90843](https://github.com/kubernetes/kubernetes/pull/90843), [@pjbgf](https://github.com/pjbgf)) [SIG API Machinery, Auth and Cluster Lifecycle]
+ - Base-images: Update to kube-cross:v1.13.9-5 ([#90963](https://github.com/kubernetes/kubernetes/pull/90963), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
+ - CloudNodeLifecycleController will check node existence status before shutdown status when monitoring nodes. ([#90737](https://github.com/kubernetes/kubernetes/pull/90737), [@jiahuif](https://github.com/jiahuif)) [SIG Apps and Cloud Provider]
+ - First pod with required affinity terms can schedule only on nodes with matching topology keys. ([#91168](https://github.com/kubernetes/kubernetes/pull/91168), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+ - Fix VirtualMachineScaleSets.virtualMachines.GET not allowed issues when customers have set VMSS orchestrationMode. ([#91097](https://github.com/kubernetes/kubernetes/pull/91097), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+ - Fix a racing issue that scheduler may perform unnecessary scheduling attempt. ([#90660](https://github.com/kubernetes/kubernetes/pull/90660), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing]
+ - Fix kubectl run  --dry-run client  ignore namespace ([#90785](https://github.com/kubernetes/kubernetes/pull/90785), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+ - Fix public IP not shown issues after assigning public IP to Azure VMs ([#90886](https://github.com/kubernetes/kubernetes/pull/90886), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+ - Fix: azure disk dangling attach issue which would cause API throttling ([#90749](https://github.com/kubernetes/kubernetes/pull/90749), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+ - Fix: support removal of nodes backed by deleted non VMSS instances on Azure ([#91184](https://github.com/kubernetes/kubernetes/pull/91184), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider]
+ - Fixed a regression preventing garbage collection of RBAC role and binding objects ([#90534](https://github.com/kubernetes/kubernetes/pull/90534), [@apelisse](https://github.com/apelisse)) [SIG Auth]
+ - For external storage e2e test suite, update external driver, to pick snapshot provisioner from VolumeSnapshotClass, when a VolumeSnapshotClass is explicitly provided as an input. ([#90878](https://github.com/kubernetes/kubernetes/pull/90878), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing]
+ - In a HA env, during the period a standby scheduler lost connection to API server, if a Pod is deleted and recreated, and the standby scheduler becomes master afterwards, there could be a scheduler cache corruption. This PR fixes this issue. ([#91126](https://github.com/kubernetes/kubernetes/pull/91126), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+ - Kubeadm: increase robustness for "kubeadm join" when adding etcd members on slower setups ([#90645](https://github.com/kubernetes/kubernetes/pull/90645), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+ - Prevent PVC requested size overflow when expanding or creating a volume ([#90907](https://github.com/kubernetes/kubernetes/pull/90907), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage]
+ - Scheduling failures due to no nodes available are now reported as unschedulable under ```schedule_attempts_total``` metric. ([#90989](https://github.com/kubernetes/kubernetes/pull/90989), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+
+### Other (Cleanup or Flake)
+ - Adds additional testing to ensure that udp pods conntrack are cleaned up ([#90180](https://github.com/kubernetes/kubernetes/pull/90180), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Architecture, Network and Testing]
+ - Adjusts the fsType for cinder values to be `ext4` if no fsType is specified. ([#90608](https://github.com/kubernetes/kubernetes/pull/90608), [@huffmanca](https://github.com/huffmanca)) [SIG Storage]
+ - Change beta.kubernetes.io/os to kubernetes.io/os ([#89461](https://github.com/kubernetes/kubernetes/pull/89461), [@wawa0210](https://github.com/wawa0210)) [SIG Cloud Provider and Cluster Lifecycle]
+ - Improve server-side apply conflict errors by setting dedicated kubectl subcommand field managers ([#88885](https://github.com/kubernetes/kubernetes/pull/88885), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+ - It is now possible to use the service annotation `cloud.google.com/network-tier: Standard` to configure the Network Tier of the GCE Loadbalancer ([#88532](https://github.com/kubernetes/kubernetes/pull/88532), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider, Network and Testing]
+ - Kubeadm now forwards the IPv6DualStack feature gate using the kubelet component config, instead of the kubelet command line ([#90840](https://github.com/kubernetes/kubernetes/pull/90840), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+ - Kubeadm: do not use a DaemonSet for the pre-pull of control-plane images during "kubeadm upgrade apply". Individual node upgrades now pull the required images using a preflight check. The flag "--image-pull-timeout" for "kubeadm upgrade apply" is now deprecated and will be removed in a future release following a GA deprecation policy. ([#90788](https://github.com/kubernetes/kubernetes/pull/90788), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle]
+ - Kubeadm: use two separate checks on /livez and /readyz for the kube-apiserver static Pod instead of using /healthz ([#90970](https://github.com/kubernetes/kubernetes/pull/90970), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+ - The "HostPath should give a volume the correct mode" is no longer a conformance test ([#90861](https://github.com/kubernetes/kubernetes/pull/90861), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+ - `beta.kubernetes.io/os` and `beta.kubernetes.io/arch` node labels are deprecated. Update node selectors to use `kubernetes.io/os` and `kubernetes.io/arch`. ([#91046](https://github.com/kubernetes/kubernetes/pull/91046), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and Node]
+ - base-images: Use debian-base:v2.1.0 ([#90697](https://github.com/kubernetes/kubernetes/pull/90697), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery and Release]
+ - base-images: Use debian-iptables:v12.1.0 ([#90782](https://github.com/kubernetes/kubernetes/pull/90782), [@justaugustus](https://github.com/justaugustus)) [SIG Release]
+
+## Dependencies
+
+### Added
+- cloud.google.com/go/bigquery: v1.0.1
+- cloud.google.com/go/datastore: v1.0.0
+- cloud.google.com/go/pubsub: v1.0.1
+- cloud.google.com/go/storage: v1.0.0
+- dmitri.shuralyov.com/gpu/mtl: 666a987
+- github.com/cespare/xxhash/v2: [v2.1.1](https://github.com/cespare/xxhash/v2/tree/v2.1.1)
+- github.com/chzyer/logex: [v1.1.10](https://github.com/chzyer/logex/tree/v1.1.10)
+- github.com/chzyer/readline: [2972be2](https://github.com/chzyer/readline/tree/2972be2)
+- github.com/chzyer/test: [a1ea475](https://github.com/chzyer/test/tree/a1ea475)
+- github.com/coreos/bbolt: [v1.3.2](https://github.com/coreos/bbolt/tree/v1.3.2)
+- github.com/cpuguy83/go-md2man/v2: [v2.0.0](https://github.com/cpuguy83/go-md2man/v2/tree/v2.0.0)
+- github.com/go-gl/glfw/v3.3/glfw: [12ad95a](https://github.com/go-gl/glfw/v3.3/glfw/tree/12ad95a)
+- github.com/google/renameio: [v0.1.0](https://github.com/google/renameio/tree/v0.1.0)
+- github.com/ianlancetaylor/demangle: [5e5cf60](https://github.com/ianlancetaylor/demangle/tree/5e5cf60)
+- github.com/rogpeppe/go-internal: [v1.3.0](https://github.com/rogpeppe/go-internal/tree/v1.3.0)
+- github.com/russross/blackfriday/v2: [v2.0.1](https://github.com/russross/blackfriday/v2/tree/v2.0.1)
+- github.com/shurcooL/sanitized_anchor_name: [v1.0.0](https://github.com/shurcooL/sanitized_anchor_name/tree/v1.0.0)
+- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4)
+- golang.org/x/mod: v0.1.0
+- google.golang.org/protobuf: v1.23.0
+- gopkg.in/errgo.v2: v2.1.0
+- k8s.io/klog/v2: v2.0.0
+
+### Changed
+- cloud.google.com/go: v0.38.0 → v0.51.0
+- github.com/GoogleCloudPlatform/k8s-cloud-provider: [27a4ced → 7901bc8](https://github.com/GoogleCloudPlatform/k8s-cloud-provider/compare/27a4ced...7901bc8)
+- github.com/alecthomas/template: [a0175ee → fb15b89](https://github.com/alecthomas/template/compare/a0175ee...fb15b89)
+- github.com/alecthomas/units: [2efee85 → c3de453](https://github.com/alecthomas/units/compare/2efee85...c3de453)
+- github.com/beorn7/perks: [v1.0.0 → v1.0.1](https://github.com/beorn7/perks/compare/v1.0.0...v1.0.1)
+- github.com/coreos/pkg: [97fdf19 → 399ea9e](https://github.com/coreos/pkg/compare/97fdf19...399ea9e)
+- github.com/go-kit/kit: [v0.8.0 → v0.9.0](https://github.com/go-kit/kit/compare/v0.8.0...v0.9.0)
+- github.com/go-logfmt/logfmt: [v0.3.0 → v0.4.0](https://github.com/go-logfmt/logfmt/compare/v0.3.0...v0.4.0)
+- github.com/golang/groupcache: [02826c3 → 215e871](https://github.com/golang/groupcache/compare/02826c3...215e871)
+- github.com/golang/protobuf: [v1.3.3 → v1.4.2](https://github.com/golang/protobuf/compare/v1.3.3...v1.4.2)
+- github.com/google/cadvisor: [8af10c6 → 6a8d614](https://github.com/google/cadvisor/compare/8af10c6...6a8d614)
+- github.com/google/pprof: [3ea8567 → d4f498a](https://github.com/google/pprof/compare/3ea8567...d4f498a)
+- github.com/googleapis/gax-go/v2: [v2.0.4 → v2.0.5](https://github.com/googleapis/gax-go/v2/compare/v2.0.4...v2.0.5)
+- github.com/json-iterator/go: [v1.1.8 → v1.1.9](https://github.com/json-iterator/go/compare/v1.1.8...v1.1.9)
+- github.com/jstemmer/go-junit-report: [af01ea7 → v0.9.1](https://github.com/jstemmer/go-junit-report/compare/af01ea7...v0.9.1)
+- github.com/prometheus/client_golang: [v1.0.0 → v1.6.0](https://github.com/prometheus/client_golang/compare/v1.0.0...v1.6.0)
+- github.com/prometheus/common: [v0.4.1 → v0.9.1](https://github.com/prometheus/common/compare/v0.4.1...v0.9.1)
+- github.com/prometheus/procfs: [v0.0.5 → v0.0.11](https://github.com/prometheus/procfs/compare/v0.0.5...v0.0.11)
+- github.com/spf13/cobra: [v0.0.5 → v1.0.0](https://github.com/spf13/cobra/compare/v0.0.5...v1.0.0)
+- github.com/spf13/viper: [v1.3.2 → v1.4.0](https://github.com/spf13/viper/compare/v1.3.2...v1.4.0)
+- github.com/tmc/grpc-websocket-proxy: [89b8d40 → 0ad062e](https://github.com/tmc/grpc-websocket-proxy/compare/89b8d40...0ad062e)
+- go.opencensus.io: v0.21.0 → v0.22.2
+- go.uber.org/atomic: v1.3.2 → v1.4.0
+- golang.org/x/exp: 4b39c73 → da58074
+- golang.org/x/image: 0694c2d → cff245a
+- golang.org/x/lint: 959b441 → fdd1cda
+- golang.org/x/mobile: d3739f8 → d2bd2a2
+- golang.org/x/oauth2: 0f29369 → 858c2ad
+- google.golang.org/api: 5213b80 → v0.15.1
+- google.golang.org/appengine: v1.5.0 → v1.6.5
+- google.golang.org/genproto: f3c370f → ca5a221
+- honnef.co/go/tools: e561f67 → v0.0.1-2019.2.3
+- k8s.io/gengo: e0e292d → 8167cfd
+- k8s.io/kube-openapi: e1beb1b → 656914f
+- k8s.io/utils: a9aa75a → 2df71eb
+- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.7 → 33b9978
+
+### Removed
+- github.com/coreos/go-etcd: [v2.0.0+incompatible](https://github.com/coreos/go-etcd/tree/v2.0.0)
+- github.com/ugorji/go/codec: [d75b2dc](https://github.com/ugorji/go/codec/tree/d75b2dc)
+- k8s.io/klog: v1.0.0
+
+
+
+# v1.19.0-alpha.3
+
+[Documentation](https://docs.k8s.io)
+
+## Downloads for v1.19.0-alpha.3
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes.tar.gz) | `49df3a77453b759d3262be6883dd9018426666b4261313725017eed42da1bc8dd1af037ec6c11357a6360c0c32c2486490036e9e132c9026f491325ce353c84b`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-src.tar.gz) | `ddbb0baaf77516dc885c41017f4a8d91d0ff33eeab14009168a1e4d975939ccc6a053a682c2af14346c67fe7b142aa2c1ba32e86a30f2433cefa423764c5332d`
 
 ### Client Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-386.tar.gz) | `bc337bb8f200a789be4b97ce99b9d7be78d35ebd64746307c28339dc4628f56d9903e0818c0888aaa9364357a528d1ac6fd34f74377000f292ec502fbea3837e`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | `38dfa5e0b0cfff39942c913a6bcb2ad8868ec43457d35cffba08217bb6e7531720e0731f8588505f4c81193ce5ec0e5fe6870031cf1403fbbde193acf7e53540`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-386.tar.gz) | `8e63ec7ce29c69241120c037372c6c779e3f16253eabd612c7cbe6aa89326f5160eb5798004d723c5cd72d458811e98dac3574842eb6a57b2798ecd2bbe5bcf9`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | `c1be9f184a7c3f896a785c41cd6ece9d90d8cb9b1f6088bdfb5557d8856c55e455f6688f5f54c2114396d5ae7adc0361e34ebf8e9c498d0187bd785646ccc1d0`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm.tar.gz) | `8eab02453cfd9e847632a774a0e0cf3a33c7619fb4ced7f1840e1f71444e8719b1c8e8cbfdd1f20bb909f3abe39cdcac74f14cb9c878c656d35871b7c37c7cbe`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | `f7df0ec02d2e7e63278d5386e8153cfe2b691b864f17b6452cc824a5f328d688976c975b076e60f1c6b3c859e93e477134fbccc53bb49d9e846fb038b34eee48`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | `36dd5b10addca678a518e6d052c9d6edf473e3f87388a2f03f714c93c5fbfe99ace16cf3b382a531be20a8fe6f4160f8d891800dd2cff5f23c9ca12c2f4a151b`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | `5bdbb44b996ab4ccf3a383780270f5cfdbf174982c300723c8bddf0a48ae5e459476031c1d51b9d30ffd621d0a126c18a5de132ef1d92fca2f3e477665ea10cc`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-386.tar.gz) | `5dea3d4c4e91ef889850143b361974250e99a3c526f5efee23ff9ccdcd2ceca4a2247e7c4f236bdfa77d2150157da5d676ac9c3ba26cf3a2f1e06d8827556f77`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | `db298e698391368703e6aea7f4345aec5a4b8c69f9d8ff6c99fb5804a6cea16d295fb01e70fe943ade3d4ce9200a081ad40da21bd331317ec9213f69b4d6c48f`
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-darwin-386.tar.gz) | `c0fb1afb5b22f6e29cf3e5121299d3a5244a33b7663e041209bcc674a0009842b35b9ebdafa5bd6b91a1e1b67fa891e768627b97ea5258390d95250f07c2defc`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | `f32596863fed32bc8e3f032ef1e4f9f232898ed506624cb1b4877ce2ced2a0821d70b15599258422aa13181ab0e54f38837399ca611ab86cbf3feec03ede8b95`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-386.tar.gz) | `37290244cee54ff05662c2b14b69445eee674d385e6b05ca0b8c8b410ba047cf054033229c78af91670ca1370807753103c25dbb711507edc1c6beca87bd0988`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | `3753eb28b9d68a47ef91fff3e91215015c28bce12828f81c0bbddbde118fd2cf4d580e474e54b1e8176fa547829e2ed08a4df36bbf83b912c831a459821bd581`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | `86b1cdb59a6b4e9de4496e5aa817b1ae7687ac6a93f8b8259cdeb356020773711d360a2ea35f7a8dc1bdd6d31c95e6491abf976afaff3392eb7d2df1008e192c`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | `fbf324e92b93cd8048073b2a627ddc8866020bc4f086604d82bf4733d463411a534d8c8f72565976eb1b32be64aecae8858cd140ef8b7a3c96fcbbf92ca54689`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | `7a6551eca17d29efb5d818e360b53ab2f0284e1091cc537e0a7ce39843d0b77579f26eb14bdeca9aa9e0aa0ef92ce1ccde34bdce84b4a5c1e090206979afb0ea`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | `46352be54882cf3edb949b355e71daea839c9b1955ccfe1085590b81326665d81cabde192327d82e56d6a157e224caefdcfbec3364b9f8b18b5da0cfcb97fc0c`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-windows-386.tar.gz) | `d049bf5f27e5e646ea4aa657aa0a694de57394b0dc60eadf1f7516d1ca6a6db39fc89d34bb6bba0a82f0c140113c2a91c41ad409e0ab41118a104f47eddcb9d2`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | `2e585f6f97b86443a6e3a847c8dfaa29c6323f8d5bbfdb86dc7bf5465ba54f64b35ee55a6d38e9be105a67fff39057ad16db3f3b1c3b9c909578517f4da7e51e`
 
 ### Server Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | `c6284929dd5940e750b48db72ffbc09f73c5ec31ab3db283babb8e4e07cd8cbb27642f592009caae4717981c0db82c16312849ef4cbafe76acc4264c7d5864ac`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm.tar.gz) | `6fc9552cf082c54cc0833b19876117c87ba7feb5a12c7e57f71b52208daf03eaef3ca56bd22b7bce2d6e81b5a23537cf6f5497a6eaa356c0aab1d3de26c309f9`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | `b794b9c399e548949b5bfb2fe71123e86c2034847b2c99aca34b6de718a35355bbecdae9dc2a81c49e3c82fb4b5862526a3f63c2862b438895e12c5ea884f22e`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | `fddaed7a54f97046a91c29534645811c6346e973e22950b2607b8c119c2377e9ec2d32144f81626078cdaeca673129cc4016c1a3dbd3d43674aa777089fb56ac`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | `65951a534bb55069c7419f41cbcdfe2fae31541d8a3f9eca11fc2489addf281c5ad2d13719212657da0be5b898f22b57ac39446d99072872fbacb0a7d59a4f74`
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | `8c41c6abf32ba7040c2cc654765d443e615d96891eacf6bcec24146a8aaf79b9206d13358518958e5ec04eb911ade108d4522ebd8603b88b3e3d95e7d5b24e60`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | `7e54c60bf724e2e3e2cff1197512ead0f73030788877f2f92a7e0deeeabd86e75ce8120eb815bf63909f8a110e647a5fcfddd510efffbd9c339bd0f90caa6706`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | `7c57fd80b18be6dd6b6e17558d12ec0c07c06ce248e99837737fdd39b7f5d752597679748dc6294563f30def986ed712a8f469f3ea1c3a4cbe5d63c44f1d41dc`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | `d22b1d4d8ccf9e9df8f90d35b8d2a1e7916f8d809806743cddc00b15d8ace095c54c61d7c9affd6609a316ee14ba43bf760bfec4276aee8273203aab3e7ac3c1`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | `3177c9a2d6bd116d614fa69ff9cb16b822bee4e36e38f93ece6aeb5d118ae67dbe61546c7f628258ad719e763c127ca32437ded70279ea869cfe4869e06cbdde`
 
 ### Node Binaries
 
 filename | sha512 hash
 -------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | `992059efb5cae7ed0ef55820368d854bad1c6d13a70366162cd3b5111ce24c371c7c87ded2012f055e08b2ff1b4ef506e1f4e065daa3ac474fef50b5efa4fb07`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm.tar.gz) | `c63ae0f8add5821ad267774314b8c8c1ffe3b785872bf278e721fd5dfdad1a5db1d4db3720bea0a36bf10d9c6dd93e247560162c0eac6e1b743246f587d3b27a`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | `47adb9ddf6eaf8f475b89f59ee16fbd5df183149a11ad1574eaa645b47a6d58aec2ca70ba857ce9f1a5793d44cf7a61ebc6874793bb685edaf19410f4f76fd13`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | `a3bc4a165567c7b76a3e45ab7b102d6eb3ecf373eb048173f921a4964cf9be8891d0d5b8dafbd88c3af7b0e21ef3d41c1e540c3347ddd84b929b3a3d02ceb7b2`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | `109ddf37c748f69584c829db57107c3518defe005c11fcd2a1471845c15aae0a3c89aafdd734229f4069ed18856cc650c80436684e1bdc43cfee3149b0324746`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | `a3a75d2696ad3136476ad7d811e8eabaff5111b90e592695e651d6111f819ebf0165b8b7f5adc05afb5f7f01d1e5fb64876cb696e492feb20a477a5800382b7a`
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | `543248e35c57454bfc4b6f3cf313402d7cf81606b9821a5dd95c6758d55d5b9a42e283a7fb0d45322ad1014e3382aafaee69879111c0799dac31d5c4ad1b8041`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | `c94bed3861376d3fd41cb7bc93b5a849612bc7346ed918f6b5b634449cd3acef69ff63ca0b6da29f45df68402f64f3d290d7688bc50f46dac07e889219dac30c`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | `3649dbca59d08c3922830b7acd8176e8d2f622fbf6379288f3a70045763d5d72c944d241f8a2c57306f23e6e44f7cc3b912554442f77e0f90e9f876f240114a8`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | `5655d1d48a1ae97352af2d703954c7a28c2d1c644319c4eb24fe19ccc5fb546c30b34cc86d8910f26c88feee88d7583bc085ebfe58916054f73dcf372a824fd9`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | `55190804357a687c37d1abb489d5aef7cea209d1c03778548f0aa4dab57a0b98b710fda09ff5c46d0963f2bb674726301d544b359f673df8f57226cafa831ce3`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | `d8ffbe8dc9a0b0b55db357afa6ef94e6145f9142b1bc505897cac9ee7c950ef527a189397a8e61296e66ce76b020eccb276668256927d2273d6079b9ffebef24`
 
-## Changelog since v1.18.0-beta.0
+## Changelog since v1.19.0-alpha.2
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+- Kubeadm does not set the deprecated '--cgroup-driver' flag in /var/lib/kubelet/kubeadm-flags.env, it will be set in the kubelet config.yaml. If you have this flag in /var/lib/kubelet/kubeadm-flags.env or /etc/default/kubelet (/etc/sysconfig/kubelet for RPMs) please remove it and set the value using KubeletConfiguration ([#90513](https://github.com/kubernetes/kubernetes/pull/90513), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+
+- Kubeadm respects resolvConf value set by user even if systemd-resolved service is active. kubeadm no longer sets the flag in '--resolv-conf' in /var/lib/kubelet/kubeadm-flags.env. If you have this flag in /var/lib/kubelet/kubeadm-flags.env or /etc/default/kubelet (/etc/sysconfig/kubelet for RPMs) please remove it and set the value using KubeletConfiguration ([#90394](https://github.com/kubernetes/kubernetes/pull/90394), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+
+## Changes by Kind
+
+### Deprecation
+
+- Apiextensions.k8s.io/v1beta1 is deprecated in favor of apiextensions.k8s.io/v1 ([#90673](https://github.com/kubernetes/kubernetes/pull/90673), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Apiregistration.k8s.io/v1beta1 is deprecated in favor of apiregistration.k8s.io/v1 ([#90672](https://github.com/kubernetes/kubernetes/pull/90672), [@deads2k](https://github.com/deads2k)) [SIG API Machinery]
+- Authentication.k8s.io/v1beta1 and authorization.k8s.io/v1beta1 are deprecated in 1.19 in favor of v1 levels and will be removed in 1.22 ([#90458](https://github.com/kubernetes/kubernetes/pull/90458), [@deads2k](https://github.com/deads2k)) [SIG API Machinery and Auth]
+- Autoscaling/v2beta1 is deprecated in favor of autoscaling/v2beta2 ([#90463](https://github.com/kubernetes/kubernetes/pull/90463), [@deads2k](https://github.com/deads2k)) [SIG Autoscaling]
+- Coordination.k8s.io/v1beta1 is deprecated in 1.19, targeted for removal in 1.22, use v1 instead. ([#90559](https://github.com/kubernetes/kubernetes/pull/90559), [@deads2k](https://github.com/deads2k)) [SIG Scalability]
+- Storage.k8s.io/v1beta1 is deprecated in favor of storage.k8s.io/v1 ([#90671](https://github.com/kubernetes/kubernetes/pull/90671), [@deads2k](https://github.com/deads2k)) [SIG Storage]
+
+### API Change
+
+- K8s.io/apimachinery - scheme.Convert() now uses only explicitly registered conversions - default reflection based conversion is no longer available. `+k8s:conversion-gen` tags can be used with the `k8s.io/code-generator` component to generate conversions. ([#90018](https://github.com/kubernetes/kubernetes/pull/90018), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps and Testing]
+- Kubelet's --runonce option is now also available in Kubelet's config file as `runOnce`. ([#89128](https://github.com/kubernetes/kubernetes/pull/89128), [@vincent178](https://github.com/vincent178)) [SIG Node]
+- Promote Immutable Secrets/ConfigMaps feature to Beta and enable the feature by default.
+  This allows to set `Immutable` field in Secrets or ConfigMap object to mark their contents as immutable. ([#89594](https://github.com/kubernetes/kubernetes/pull/89594), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps and Testing]
+- The unused `series.state` field, deprecated since v1.14, is removed from the `events.k8s.io/v1beta1` and `v1` Event types. ([#90449](https://github.com/kubernetes/kubernetes/pull/90449), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps]
+
+### Feature
+
+- Kube-apiserver: The NodeRestriction admission plugin now restricts Node labels kubelets are permitted to set when creating a new Node to the `--node-labels` parameters accepted by kubelets in 1.16+. ([#90307](https://github.com/kubernetes/kubernetes/pull/90307), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Kubectl supports taint no without specifying(without having to type the full resource name) ([#88723](https://github.com/kubernetes/kubernetes/pull/88723), [@wawa0210](https://github.com/wawa0210)) [SIG CLI]
+- New scoring for PodTopologySpreading that yields better spreading ([#90475](https://github.com/kubernetes/kubernetes/pull/90475), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- No ([#89549](https://github.com/kubernetes/kubernetes/pull/89549), [@happinesstaker](https://github.com/happinesstaker)) [SIG API Machinery, Auth, Instrumentation and Testing]
+- Try to send watch bookmarks (if requested) periodically in addition to sending them right before timeout ([#90560](https://github.com/kubernetes/kubernetes/pull/90560), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery]
+
+### Bug or Regression
+
+- Avoid GCE API calls when initializing GCE CloudProvider for Kubelets. ([#90218](https://github.com/kubernetes/kubernetes/pull/90218), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider and Scalability]
+- Avoid unnecessary scheduling churn when annotations are updated while Pods are being scheduled. ([#90373](https://github.com/kubernetes/kubernetes/pull/90373), [@fabiokung](https://github.com/fabiokung)) [SIG Scheduling]
+- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#90537](https://github.com/kubernetes/kubernetes/pull/90537), [@freehan](https://github.com/freehan)) [SIG Network]
+- Fixed a regression in wait.Forever that skips the backoff period on the first repeat ([#90476](https://github.com/kubernetes/kubernetes/pull/90476), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
+- Fixes a bug that non directory hostpath type can be recognized as HostPathFile and adds e2e tests for HostPathType ([#64829](https://github.com/kubernetes/kubernetes/pull/64829), [@dixudx](https://github.com/dixudx)) [SIG Apps, Storage and Testing]
+- Fixes a regression in 1.17 that dropped cache-control headers on API requests ([#90468](https://github.com/kubernetes/kubernetes/pull/90468), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- Fixes regression in CPUManager that caused freeing of exclusive CPUs at incorrect times ([#90377](https://github.com/kubernetes/kubernetes/pull/90377), [@cbf123](https://github.com/cbf123)) [SIG Cloud Provider and Node]
+- Fixes regression in CPUManager that had the (rare) possibility to release exclusive CPUs in app containers inherited from init containers. ([#90419](https://github.com/kubernetes/kubernetes/pull/90419), [@klueska](https://github.com/klueska)) [SIG Node]
+- Jsonpath support in kubectl / client-go serializes complex types (maps / slices / structs) as json instead of Go-syntax. ([#89660](https://github.com/kubernetes/kubernetes/pull/89660), [@pjferrell](https://github.com/pjferrell)) [SIG API Machinery, CLI and Cluster Lifecycle]
+- Kubeadm: ensure `image-pull-timeout` flag is respected during upgrade phase ([#90328](https://github.com/kubernetes/kubernetes/pull/90328), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubeadm: fix misleading warning for the kube-apiserver authz modes during "kubeadm init" ([#90064](https://github.com/kubernetes/kubernetes/pull/90064), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Provides a fix to allow a cluster in a private Azure cloud to authenticate to ACR in the same cloud. ([#90425](https://github.com/kubernetes/kubernetes/pull/90425), [@DavidParks8](https://github.com/DavidParks8)) [SIG Cloud Provider]
+- Update github.com/moby/ipvs to v1.0.1 to fix IPVS compatiblity issue with older kernels ([#90555](https://github.com/kubernetes/kubernetes/pull/90555), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
+- Updates to pod status via the status subresource now validate that `status.podIP` and `status.podIPs` fields are well-formed. ([#90628](https://github.com/kubernetes/kubernetes/pull/90628), [@liggitt](https://github.com/liggitt)) [SIG Apps and Node]
+
+### Other (Cleanup or Flake)
+
+- Drop some conformance tests that rely on Kubelet API directly ([#90615](https://github.com/kubernetes/kubernetes/pull/90615), [@dims](https://github.com/dims)) [SIG Architecture, Network, Release and Testing]
+- Kube-proxy exposes a new metric, `kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds`, that indicates the last time a change for kube-proxy was queued to be applied. ([#90175](https://github.com/kubernetes/kubernetes/pull/90175), [@squeed](https://github.com/squeed)) [SIG Instrumentation and Network]
+- Kubeadm: fix badly formatted error message for small service CIDRs ([#90411](https://github.com/kubernetes/kubernetes/pull/90411), [@johscheuer](https://github.com/johscheuer)) [SIG Cluster Lifecycle]
+- None. ([#90484](https://github.com/kubernetes/kubernetes/pull/90484), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
+- Remove the repeated calculation of nodeName and hostname during kubelet startup, these parameters are all calculated in the `RunKubelet` method ([#90284](https://github.com/kubernetes/kubernetes/pull/90284), [@wawa0210](https://github.com/wawa0210)) [SIG Node]
+- UI change ([#87743](https://github.com/kubernetes/kubernetes/pull/87743), [@u2takey](https://github.com/u2takey)) [SIG Apps and Node]
+- Update opencontainers/runtime-spec dependency to v1.0.2 ([#89644](https://github.com/kubernetes/kubernetes/pull/89644), [@saschagrunert](https://github.com/saschagrunert)) [SIG Node]
+
+
+# v1.19.0-alpha.2
+
+[Documentation](https://docs.k8s.io)
+
+## Downloads for v1.19.0-alpha.2
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes.tar.gz) | `a1106309d18a5d73882650f8a5cbd1f287436a0dc527136808e5e882f5e98d6b0d80029ff53abc0c06ac240f6b879167437f15906e5309248d536ec1675ed909`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-src.tar.gz) | `c24c0b2a99ad0d834e0f017d7436fa84c6de8f30e8768ee59b1a418eb66a9b34ed4bcc25e03c04b19ea17366564f4ee6fe55a520fa4d0837e86c0a72fc7328c1`
+
+### Client Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-darwin-386.tar.gz) | `51ede026b0f8338f7fd293fb096772a67f88f23411c3280dff2f9efdd3ad7be7917d5c32ba764162c1a82b14218a90f624271c3cd8f386c8e41e4a9eac28751f`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | `4ed4358cabbecf724d974207746303638c7f23d422ece9c322104128c245c8485e37d6ffdd9d17e13bb1d8110e870c0fe17dcc1c9e556b69a4df7d34b6ff66d5`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-386.tar.gz) | `a57b10f146083828f18d809dbe07938b72216fa21083e7dbb9acce7dbcc3e8c51b8287d3bf89e81c8e1af4dd139075c675cc0f6ae7866ef69a3813db09309b97`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | `099247419dd34dc78131f24f1890cc5c6a739e887c88fae96419d980c529456bfd45c4e451ba5b6425320ddc764245a2eab1bd5e2b5121d9a2774bdb5df9438b`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | `d12704bc6c821d3afcd206234fbd32e57cefcb5a5d15a40434b6b0ef4781d7fa77080e490678005225f24b116540ff51e436274debf66a6eb2247cd1dc833e6c`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | `da0d110751fa9adac69ed2166eb82b8634989a32b65981eff014c84449047abfb94fe015e2d2e22665d57ff19f673e2c9f6549c578ad1b1e2f18b39871b50b81`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | `7ac2b85bba9485dd38aed21895d627d34beb9e3b238e0684a9864f4ce2cfa67d7b3b7c04babc2ede7144d05beacdbe11c28c7d53a5b0041004700b2854b68042`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | `ac447eabc5002a059e614b481d25e668735a7858134f8ad49feb388bb9f9191ff03b65da57bb49811119983e8744c8fdc7d19c184d9232bd6d038fae9eeec7c6`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-windows-386.tar.gz) | `7c7dac7af329e4515302e7c35d3a19035352b4211942f254a4bb94c582a89d740b214d236ba6e35b9e78945a06b7e6fe8d70da669ecc19a40b7a9e8eaa2c0a28`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | `0c89b70a25551123ffdd7c5d3cc499832454745508c5f539f13b4ea0bf6eea1afd16e316560da9cf68e5178ae69d91ccfe6c02d7054588db3fac15c30ed96f4b`
+
+### Server Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | `3396e6e0516a09999ec26631e305cf0fb1eb0109ca1490837550b7635eb051dd92443de8f4321971fc2b4030ea2d8da4bfe8b85887505dec96e2a136b6a46617`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | `cdea122a2d8d602ec0c89c1135ecfc27c47662982afc5b94edf4a6db7d759f27d6fe8d8b727bddf798bfec214a50e8d8a6d8eb0bca2ad5b1f72eb3768afd37f1`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | `6543186a3f4437fb475fbc6a5f537640ab00afb2a22678c468c3699b3f7493f8b35fb6ca14694406ffc90ff8faad17a1d9d9d45732baa976cb69f4b27281295a`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | `fde8dfeb9a0b243c8bef5127a9c63bf685429e2ff7e486ac8bae373882b87a4bd1b28a12955e3cce1c04eb0e6a67aabba43567952f9deef943a75fcb157a949c`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | `399d004ee4db5d367f37a1fa9ace63b5db4522bd25eeb32225019f3df9b70c715d2159f6556015ddffe8f49aa0f72a1f095f742244637105ddbed3fb09570d0d`
+
+### Node Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | `fd865c2fcc71796d73c90982f90c789a44a921cf1d56aee692bd00efaa122dcc903b0448f285a06b0a903e809f8310546764b742823fb8d10690d36ec9e27cbd`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | `63aeb35222241e2a9285aeee4190b4b49c49995666db5cdb142016ca87872e7fdafc9723bc5de1797a45cc7e950230ed27be93ac165b8cda23ca2a9f9233c27a`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | `3532574d9babfc064ce90099b514eadfc2a4ce69091f92d9c1a554ead91444373416d1506a35ef557438606a96cf0e5168a83ddd56c92593ea4adaa15b0b56a8`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | `de59d91e5b0e4549e9a97f3a0243236e97babaed08c70f1a17273abf1966e6127db7546e1f91c3d66e933ce6eeb70bc65632ab473aa2c1be2a853da026c9d725`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | `0cb8cf6f8dffd63122376a2f3e8986a2db155494a45430beea7cb5d1180417072428dabebd1af566ea13a4f079d46368c8b549be4b8a6c0f62a974290fd2fdb0`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | `f1faf695f9f6fded681653f958b48779a2fecf50803af49787acba192441790c38b2b611ec8e238971508c56e67bb078fb423e8f6d9bddb392c199b5ee47937c`
+
+## Changelog since v1.19.0-alpha.1
+
+## Urgent Upgrade Notes
+
+### (No, really, you MUST read this before you upgrade)
+
+- Kubeadm now respects user specified etcd versions in the ClusterConfiguration and properly uses them. If users do not want to stick to the version specified in the ClusterConfiguration, they should edit the kubeadm-config config map and delete it. ([#89588](https://github.com/kubernetes/kubernetes/pull/89588), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+
+## Changes by Kind
+
+### API Change
+
+- Kube-proxy: add `--bind-address-hard-fail` flag to treat failure to bind to a port as fatal ([#89350](https://github.com/kubernetes/kubernetes/pull/89350), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle and Network]
+- Remove kubescheduler.config.k8s.io/v1alpha1 ([#89298](https://github.com/kubernetes/kubernetes/pull/89298), [@gavinfish](https://github.com/gavinfish)) [SIG Scheduling]
+- ServiceAppProtocol feature gate is now beta and enabled by default, adding new AppProtocol field to Services and Endpoints. ([#90023](https://github.com/kubernetes/kubernetes/pull/90023), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- The Kubelet's `--volume-plugin-dir` option is now available via the Kubelet config file field `VolumePluginDir`. ([#88480](https://github.com/kubernetes/kubernetes/pull/88480), [@savitharaghunathan](https://github.com/savitharaghunathan)) [SIG Node]
+
+### Feature
+
+- Add client-side and server-side dry-run support to kubectl scale ([#89666](https://github.com/kubernetes/kubernetes/pull/89666), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Add support for cgroups v2 node validation ([#89901](https://github.com/kubernetes/kubernetes/pull/89901), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle and Node]
+- Detailed scheduler scoring result can be printed at verbose level 10. ([#89384](https://github.com/kubernetes/kubernetes/pull/89384), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
+- E2e.test can print the list of conformance tests that need to pass for the cluster to be conformant. ([#88924](https://github.com/kubernetes/kubernetes/pull/88924), [@dims](https://github.com/dims)) [SIG Architecture and Testing]
+- Feat: add azure shared disk support ([#89511](https://github.com/kubernetes/kubernetes/pull/89511), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-apiserver backed by etcd3 exports metric showing the database file size. ([#89151](https://github.com/kubernetes/kubernetes/pull/89151), [@jingyih](https://github.com/jingyih)) [SIG API Machinery]
+- Kube-apiserver: The NodeRestriction admission plugin now restricts Node labels kubelets are permitted to set when creating a new Node to the `--node-labels` parameters accepted by kubelets in 1.16+. ([#90307](https://github.com/kubernetes/kubernetes/pull/90307), [@liggitt](https://github.com/liggitt)) [SIG Auth and Node]
+- Kubeadm: during 'upgrade apply', if the kube-proxy ConfigMap is missing, assume that kube-proxy should not be upgraded. Same applies to a missing kube-dns/coredns ConfigMap for the DNS server addon. Note that this is a temporary workaround until 'upgrade apply' supports phases. Once phases are supported the kube-proxy/dns upgrade should be skipped manually. ([#89593](https://github.com/kubernetes/kubernetes/pull/89593), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: switch control-plane static Pods to the "system-node-critical" priority class ([#90063](https://github.com/kubernetes/kubernetes/pull/90063), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Support for running on a host that uses cgroups v2 unified mode ([#85218](https://github.com/kubernetes/kubernetes/pull/85218), [@giuseppe](https://github.com/giuseppe)) [SIG Node]
+- Update etcd client side to v3.4.7 ([#89822](https://github.com/kubernetes/kubernetes/pull/89822), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider]
+
+### Bug or Regression
+
+- An issue preventing GCP cloud-controller-manager running out-of-cluster to initialize new Nodes is now fixed. ([#90057](https://github.com/kubernetes/kubernetes/pull/90057), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Apps and Cloud Provider]
+- Avoid unnecessary GCE API calls when adding IP alises or reflecting them in Node object in GCE cloud provider. ([#90242](https://github.com/kubernetes/kubernetes/pull/90242), [@wojtek-t](https://github.com/wojtek-t)) [SIG Apps, Cloud Provider and Network]
+- Azure: fix concurreny issue in lb creation ([#89604](https://github.com/kubernetes/kubernetes/pull/89604), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- Bug fix for AWS NLB service when nodePort for existing servicePort changed manually. ([#89562](https://github.com/kubernetes/kubernetes/pull/89562), [@M00nF1sh](https://github.com/M00nF1sh)) [SIG Cloud Provider]
+- CSINode initialization does not crash kubelet on startup when APIServer is not reachable or kubelet has not the right credentials yet. ([#89589](https://github.com/kubernetes/kubernetes/pull/89589), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Client-go: resolves an issue with informers falling back to full list requests when timeouts are encountered, rather than re-establishing a watch. ([#89652](https://github.com/kubernetes/kubernetes/pull/89652), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing]
+- Dual-stack: fix the bug that Service clusterIP does not respect specified ipFamily ([#89612](https://github.com/kubernetes/kubernetes/pull/89612), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
+- Ensure Azure availability zone is always in lower cases. ([#89722](https://github.com/kubernetes/kubernetes/pull/89722), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Explain CRDs whose resource name are the same as builtin objects ([#89505](https://github.com/kubernetes/kubernetes/pull/89505), [@knight42](https://github.com/knight42)) [SIG API Machinery, CLI and Testing]
+- Fix flaws in Azure File CSI translation ([#90162](https://github.com/kubernetes/kubernetes/pull/90162), [@rfranzke](https://github.com/rfranzke)) [SIG Release and Storage]
+- Fix kubectl describe CSINode nil pointer error ([#89646](https://github.com/kubernetes/kubernetes/pull/89646), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix kubectl diff so it doesn't actually persist patches ([#89795](https://github.com/kubernetes/kubernetes/pull/89795), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Fix kubectl version should print version info without config file ([#89913](https://github.com/kubernetes/kubernetes/pull/89913), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery and CLI]
+- Fix missing `-c` shorthand for `--container` flag of `kubectl alpha debug` ([#89674](https://github.com/kubernetes/kubernetes/pull/89674), [@superbrothers](https://github.com/superbrothers)) [SIG CLI]
+- Fix printers ignoring object average value ([#89142](https://github.com/kubernetes/kubernetes/pull/89142), [@zhouya0](https://github.com/zhouya0)) [SIG API Machinery]
+- Fix scheduler crash when removing node before its pods ([#89908](https://github.com/kubernetes/kubernetes/pull/89908), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Fix: get attach disk error due to missing item in max count table ([#89768](https://github.com/kubernetes/kubernetes/pull/89768), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fixed a bug where executing a kubectl command with a jsonpath output expression that has a nested range would ignore expressions following the nested range. ([#88464](https://github.com/kubernetes/kubernetes/pull/88464), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery]
+- Fixed a regression running kubectl commands with  --local or --dry-run flags when no kubeconfig file is present ([#90243](https://github.com/kubernetes/kubernetes/pull/90243), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
+- Fixed an issue mounting credentials for service accounts whose name contains `.` characters ([#89696](https://github.com/kubernetes/kubernetes/pull/89696), [@nabokihms](https://github.com/nabokihms)) [SIG Auth]
+- Fixed mountOptions in iSCSI and FibreChannel volume plugins. ([#89172](https://github.com/kubernetes/kubernetes/pull/89172), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Fixed the EndpointSlice controller to run without error on a cluster with the OwnerReferencesPermissionEnforcement validating admission plugin enabled. ([#89741](https://github.com/kubernetes/kubernetes/pull/89741), [@marun](https://github.com/marun)) [SIG Auth and Network]
+- Fixes a bug defining a default value for a replicas field in a custom resource definition that has the scale subresource enabled ([#89833](https://github.com/kubernetes/kubernetes/pull/89833), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fixes conversion error for HorizontalPodAutoscaler objects with invalid annotations ([#89963](https://github.com/kubernetes/kubernetes/pull/89963), [@liggitt](https://github.com/liggitt)) [SIG Autoscaling]
+- Fixes kubectl to apply all validly built objects, instead of stopping on error. ([#89848](https://github.com/kubernetes/kubernetes/pull/89848), [@seans3](https://github.com/seans3)) [SIG CLI and Testing]
+- For GCE cluster provider, fix bug of not being able to create internal type load balancer for clusters with more than 1000 nodes in a single zone. ([#89902](https://github.com/kubernetes/kubernetes/pull/89902), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability]
+- If firstTimestamp is not set use eventTime when printing event ([#89999](https://github.com/kubernetes/kubernetes/pull/89999), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- If we set parameter cgroupPerQos=false and cgroupRoot=/docker，this function will retrun  nodeAllocatableRoot=/docker/kubepods, it is not right, the correct return should be /docker.
+  cm.NodeAllocatableRoot(s.CgroupRoot, s.CgroupDriver)
+  
+  kubeDeps.CAdvisorInterface, err = cadvisor.New(imageFsInfoProvider, s.RootDirectory, cgroupRoots, cadvisor.UsingLegacyCadvisorStats(s.ContainerRuntime, s.RemoteRuntimeEndpoint))
+  the above funtion，as we use cgroupRoots to create cadvisor interface，the wrong parameter cgroupRoots will lead eviction manager not  to collect metric from /docker, then kubelet frequently print those error：
+  E0303 17:25:03.436781 63839 summary_sys_containers.go:47] Failed to get system container stats for "/docker": failed to get cgroup stats for "/docker": failed to get container info for "/docker": unknown container "/docker"
+  E0303 17:25:03.436809 63839 helpers.go:680] eviction manager: failed to construct signal: "allocatableMemory.available" error: system container "pods" not found in metrics ([#88970](https://github.com/kubernetes/kubernetes/pull/88970), [@mysunshine92](https://github.com/mysunshine92)) [SIG Node]
+- In the kubelet resource metrics endpoint at /metrics/resource, change the names of the following metrics:
+  - node_cpu_usage_seconds --> node_cpu_usage_seconds_total
+  - container_cpu_usage_seconds --> container_cpu_usage_seconds_total
+  This is a partial revert of &#35;86282, which was added in 1.18.0, and initially removed the _total suffix ([#89540](https://github.com/kubernetes/kubernetes/pull/89540), [@dashpole](https://github.com/dashpole)) [SIG Instrumentation and Node]
+- Kube-apiserver: multiple comma-separated protocols in a single X-Stream-Protocol-Version header are now recognized, in addition to multiple headers, complying with RFC2616 ([#89857](https://github.com/kubernetes/kubernetes/pull/89857), [@tedyu](https://github.com/tedyu)) [SIG API Machinery]
+- Kubeadm increased to 5 minutes its timeout for the TLS bootstrapping process to complete upon join ([#89735](https://github.com/kubernetes/kubernetes/pull/89735), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle]
+- Kubeadm: during join when a check is performed that a Node with the same name already exists in the cluster, make sure the NodeReady condition is properly validated ([#89602](https://github.com/kubernetes/kubernetes/pull/89602), [@kvaps](https://github.com/kvaps)) [SIG Cluster Lifecycle]
+- Kubeadm: fix a bug where post upgrade to 1.18.x, nodes cannot join the cluster due to missing RBAC ([#89537](https://github.com/kubernetes/kubernetes/pull/89537), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: fix misleading warning about passing control-plane related flags on 'kubeadm join' ([#89596](https://github.com/kubernetes/kubernetes/pull/89596), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubectl azure authentication: fixed a regression in 1.18.0 where "spn:" prefix was unexpectedly added to the `apiserver-id` configuration in the kubeconfig file ([#89706](https://github.com/kubernetes/kubernetes/pull/89706), [@weinong](https://github.com/weinong)) [SIG API Machinery and Auth]
+- Restore the ability to `kubectl apply --prune` without --namespace flag.  Since 1.17, `kubectl apply --prune` only prunes resources in the default namespace (or from kubeconfig) or explicitly specified in command line flag.  But this is s breaking change from kubectl 1.16, which can prune resources in all namespace in config file.  This patch restores the kubectl 1.16 behaviour. ([#89551](https://github.com/kubernetes/kubernetes/pull/89551), [@tatsuhiro-t](https://github.com/tatsuhiro-t)) [SIG CLI and Testing]
+- Restores priority of static control plane pods in the cluster/gce/manifests control-plane manifests ([#89970](https://github.com/kubernetes/kubernetes/pull/89970), [@liggitt](https://github.com/liggitt)) [SIG Cluster Lifecycle and Node]
+- Service account tokens bound to pods can now be used during the pod deletion grace period. ([#89583](https://github.com/kubernetes/kubernetes/pull/89583), [@liggitt](https://github.com/liggitt)) [SIG Auth]
+- Sync LB backend nodes for Service Type=LoadBalancer on Add/Delete node events. ([#81185](https://github.com/kubernetes/kubernetes/pull/81185), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
+
+### Other (Cleanup or Flake)
+
+- Change beta.kubernetes.io/os  to kubernetes.io/os ([#89460](https://github.com/kubernetes/kubernetes/pull/89460), [@wawa0210](https://github.com/wawa0210)) [SIG Testing and Windows]
+- Changes not found message when using `kubectl get` to retrieve not namespaced resources ([#89861](https://github.com/kubernetes/kubernetes/pull/89861), [@rccrdpccl](https://github.com/rccrdpccl)) [SIG CLI]
+- Node ([#76443](https://github.com/kubernetes/kubernetes/pull/76443), [@mgdevstack](https://github.com/mgdevstack)) [SIG Architecture, Network, Node, Testing and Windows]
+- None. ([#90273](https://github.com/kubernetes/kubernetes/pull/90273), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
+- Reduce event spam during a volume operation error. ([#89794](https://github.com/kubernetes/kubernetes/pull/89794), [@msau42](https://github.com/msau42)) [SIG Storage]
+- The PR adds functionality to generate events when a PV or PVC processing encounters certain failures. The events help users to know the reason for the failure so they can take necessary recovery actions. ([#89845](https://github.com/kubernetes/kubernetes/pull/89845), [@yuga711](https://github.com/yuga711)) [SIG Apps]
+- The PodShareProcessNamespace feature gate has been removed, and the PodShareProcessNamespace is unconditionally enabled. ([#90099](https://github.com/kubernetes/kubernetes/pull/90099), [@tanjunchen](https://github.com/tanjunchen)) [SIG Node]
+- Update default etcd server version to 3.4.4 ([#89214](https://github.com/kubernetes/kubernetes/pull/89214), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle and Testing]
+- Update default etcd server version to 3.4.7 ([#89895](https://github.com/kubernetes/kubernetes/pull/89895), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cluster Lifecycle and Testing]
+
+
+# v1.19.0-alpha.1
+
+[Documentation](https://docs.k8s.io)
+
+## Downloads for v1.19.0-alpha.1
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes.tar.gz) | `d5930e62f98948e3ae2bc0a91b2cb93c2009202657b9e798e43fcbf92149f50d991af34a49049b2640db729efc635d643d008f4b3dd6c093cac4426ee3d5d147`
+[kubernetes-src.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-src.tar.gz) | `5d92125ec3ca26b6b0af95c6bb3289bb7cf60a4bad4e120ccdad06ffa523c239ca8e608015b7b5a1eb789bfdfcedbe0281518793da82a7959081fb04cf53c174`
+
+### Client Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-darwin-386.tar.gz) | `08d307dafdd8e1aa27721f97f038210b33261d1777ea173cc9ed4b373c451801988a7109566425fce32d38df70bdf0be6b8cfff69da768fbd3c303abd6dc13a5`
+[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | `08c3b722a62577d051e300ebc3c413ead1bd3e79555598a207c704064116087323215fb402bae7584b9ffd08590f36fa8a35f13f8fea1ce92e8f144e3eae3384`
+[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-386.tar.gz) | `0735978b4d4cb0601171eae3cc5603393c00f032998f51d79d3b11e4020f4decc9559905e9b02ddcb0b6c3f4caf78f779940ebc97996e3b96b98ba378fbe189d`
+[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | `ca55fc431d59c1a0bf1f1c248da7eab65215e438fcac223d4fc3a57fae0205869e1727b2475dfe9b165921417d68ac380a6e42bf7ea6732a34937ba2590931ce`
+[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | `4e1aa9e640d7cf0ccaad19377e4c3ca9a60203daa2ce0437d1d40fdea0e43759ef38797e948cdc3c676836b01e83f1bfde51effc0579bf832f6f062518f03f06`
+[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | `fca5df8c2919a9b3d99248120af627d9a1b5ddf177d9a10f04eb4e486c14d4e3ddb72e3abc4733b5078e0d27204a51e2f714424923fb92a5351137f82d87d6ea`
+[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | `6a98a4f99aa8b72ec815397c5062b90d5c023092da28fa7bca1cdadf406e2d86e2fd3a0eeab28574064959c6926007423c413d9781461e433705452087430d57`
+[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | `94724c17985ae2dbd3888e6896f300f95fec8dc2bf08e768849e98b05affc4381b322d802f41792b8e6da4708ce1ead2edcb8f4d5299be6267f6559b0d49e484`
+[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-windows-386.tar.gz) | `5a076bf3a5926939c170a501f8292a38003552848c45c1f148a97605b7ac9843fb660ef81a46abe6d139f4c5eaa342d4b834a799ee7055d5a548d189b31d7124`
+[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | `4b395894bfd9cfa0976512d1d58c0056a80bacefc798de294db6d3f363bd5581fd3ce2e4bdc1b902d46c8ce2ac87a98ced56b6b29544c86e8444fb8e9465faea`
+
+### Server Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | `6720d1b826dc20e56b0314e580403cd967430ff25bdbe08e8bf453fed339557d2a4ace114c2f524e6b6814ec9341ccdea870f784ebb53a52056ca3ab22e5cc36`
+[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | `f09b295f5a95cc72494eb1c0e9706b237a8523eacda182778e9afdb469704c7eacd29614aff6d3d7aff3bc1783fb277d52ad56a1417f1bd973eeb9bdc8086695`
+[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | `24787767abd1d67a4d0234433e1693ea3e1e906364265ee03e58ba203b66583b75d4ce0c4185756fc529997eb9a842d65841962cd228df9c182a469dbd72493d`
+[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | `a117e609729263d7bd58aac156efa33941f0f9aa651892d1abf32cfa0a984aa495fccd3be8385cae083415bfa8f81942648d5978f72e950103e42184fd0d7527`
+[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | `19280a6dc20f019d23344934f8f1ec6aa17c3374b9c569d4c173535a8cd9e298b8afcabe06d232a146c9c7cb4bfe7d1d0e10aa2ab9184ace0b7987e36973aaef`
+
+### Node Binaries
+
+filename | sha512 hash
+-------- | -----------
+[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | `c4b23f113ed13edb91b59a498d15de8b62ff1005243f2d6654a11468511c9d0ebaebb6dc02d2fa505f18df446c9221e77d7fc3147fa6704cde9bec5d6d80b5a3`
+[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | `8dcf5531a5809576049c455d3c5194f09ddf3b87995df1e8ca4543deff3ffd90a572539daff9aa887e22efafedfcada2e28035da8573e3733c21778e4440677a`
+[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | `4b3f4dfee2034ce7d01fef57b8766851fe141fc72da0f9edeb39aca4c7a937e2dccd2c198a83fbb92db7911d81e50a98bd0a17b909645adbeb26e420197db2cd`
+[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | `df0e87f5e42056db2bbc7ef5f08ecda95d66afc3f4d0bc57f6efcc05834118c39ab53d68595d8f2bb278829e33b9204c5cce718d8bf841ce6cccbb86d0d20730`
+[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | `3a6499b008a68da52f8ae12eb694885d9e10a8f805d98f28fc5f7beafea72a8e180df48b5ca31097b2d4779c61ff67216e516c14c2c812163e678518d95f22d6`
+[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.19.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | `c311373506cbfa0244ac92a709fbb9bddb46cbeb130733bdb689641ecee6b21a7a7f020eae4856a3f04a3845839dc5e0914cddc3478d55cd3d5af3d7804aa5ba`
+
+## Changelog since v1.19.0-alpha.0
 
 ## Urgent Upgrade Notes
 
@@ -803,568 +2418,186 @@ filename | sha512 hash
 - The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option.
   If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node]
 
-- Yes.
-
-  Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster.
-
-  Changes in Pull Request:
-
-    1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources.
-    2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature.
-    3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature.
-    4. Related unit tests.
-
-  None.
-
-  User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
+- `kubectl` no longer defaults to `http://localhost:8080`.  If you own one of these legacy clusters, you are *strongly- encouraged to secure your server.   If you cannot secure your server, you can set `KUBERNETES_MASTER` if you were relying on that behavior and you're client-go user. Set `--server`, `--kubeconfig` or `KUBECONFIG` to make it work in `kubectl`. ([#86173](https://github.com/kubernetes/kubernetes/pull/86173), [@soltysh](https://github.com/soltysh)) [SIG API Machinery, CLI and Testing]
 
 ## Changes by Kind
 
 ### Deprecation
 
+- AlgorithmSource is removed from v1alpha2 Scheduler ComponentConfig ([#87999](https://github.com/kubernetes/kubernetes/pull/87999), [@damemi](https://github.com/damemi)) [SIG Scheduling]
 - Azure service annotation service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset has been deprecated. Its support would be removed in a future release. ([#88462](https://github.com/kubernetes/kubernetes/pull/88462), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Kube-proxy: deprecate `--healthz-port` and `--metrics-port` flag, please use `--healthz-bind-address` and `--metrics-bind-address` instead ([#88512](https://github.com/kubernetes/kubernetes/pull/88512), [@SataQiu](https://github.com/SataQiu)) [SIG Network]
+- Kubeadm: deprecate the usage of the experimental flag '--use-api' under the 'kubeadm alpha certs renew' command. ([#88827](https://github.com/kubernetes/kubernetes/pull/88827), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubernetes no longer supports building hyperkube images ([#88676](https://github.com/kubernetes/kubernetes/pull/88676), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle and Release]
 
 ### API Change
 
+- A new IngressClass resource has been added to enable better Ingress configuration. ([#88509](https://github.com/kubernetes/kubernetes/pull/88509), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, CLI, Network, Node and Testing]
 - API additions to apiserver types ([#87179](https://github.com/kubernetes/kubernetes/pull/87179), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Cloud Provider and Cluster Lifecycle]
 - Add Scheduling Profiles to kubescheduler.config.k8s.io/v1alpha2 ([#88087](https://github.com/kubernetes/kubernetes/pull/88087), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing]
+- Added GenericPVCDataSource feature gate to enable using arbitrary custom resources as the data source for a PVC. ([#88636](https://github.com/kubernetes/kubernetes/pull/88636), [@bswartz](https://github.com/bswartz)) [SIG Apps and Storage]
 - Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage]
+- Allow user to specify fsgroup permission change policy for pods ([#88488](https://github.com/kubernetes/kubernetes/pull/88488), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage]
 - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage]
+- Consumers of the 'certificatesigningrequests/approval' API must now grant permission to 'approve' CSRs for the 'signerName' specified on the CSR. More information on the new signerName field can be found at https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190607-certificates-api.md&#35;signers ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, Apps, Auth, CLI, Node and Testing]
+- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing]
 - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery]
-- Introduces optional --detect-local flag to kube-proxy.
-  Currently the only supported value is "cluster-cidr",
+- Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network]
+- Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network]
+- Ingress: Add alternate backends via TypedLocalObjectReference ([#88775](https://github.com/kubernetes/kubernetes/pull/88775), [@cmluciano](https://github.com/cmluciano)) [SIG Apps and Network]
+- Ingress: allow wildcard hosts in IngressRule ([#88858](https://github.com/kubernetes/kubernetes/pull/88858), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
+- Introduces optional --detect-local flag to kube-proxy. 
+  Currently the only supported value is "cluster-cidr", 
   which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling]
+- Kube-controller-manager and kube-scheduler expose profiling by default to match the kube-apiserver.  Use `--enable-profiling=false` to disable. ([#88663](https://github.com/kubernetes/kubernetes/pull/88663), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Cloud Provider and Scheduling]
 - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing]
+- Move TaintBasedEvictions feature gates to GA ([#87487](https://github.com/kubernetes/kubernetes/pull/87487), [@skilxn-go](https://github.com/skilxn-go)) [SIG API Machinery, Apps, Node, Scheduling and Testing]
 - Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows]
+- New flag --endpointslice-updates-batch-period in kube-controller-manager can be used to reduce number of endpointslice updates generated by pod changes. ([#88745](https://github.com/kubernetes/kubernetes/pull/88745), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Apps and Network]
+- New flag `--show-hidden-metrics-for-version` in kubelet can be used to show all hidden metrics that deprecated in the previous minor release. ([#85282](https://github.com/kubernetes/kubernetes/pull/85282), [@serathius](https://github.com/serathius)) [SIG Node]
+- Removes ConfigMap as suggestion for IngressClass parameters ([#89093](https://github.com/kubernetes/kubernetes/pull/89093), [@robscott](https://github.com/robscott)) [SIG Network]
+- Scheduler Extenders can now be configured in the v1alpha2 component config ([#88768](https://github.com/kubernetes/kubernetes/pull/88768), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
+- The apiserver/v1alph1&#35;EgressSelectorConfiguration API is now beta. ([#88502](https://github.com/kubernetes/kubernetes/pull/88502), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery]
+- The storage.k8s.io/CSIDriver has moved to GA, and is now available for use. ([#84814](https://github.com/kubernetes/kubernetes/pull/84814), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, Apps, Auth, Node, Scheduling, Storage and Testing]
+- VolumePVCDataSource moves to GA in 1.18 release ([#88686](https://github.com/kubernetes/kubernetes/pull/88686), [@j-griffith](https://github.com/j-griffith)) [SIG Apps, CLI and Cluster Lifecycle]
 
 ### Feature
 
+- deps: Update to Golang 1.13.9
+  - build: Remove kube-cross image building ([#89275](https://github.com/kubernetes/kubernetes/pull/89275), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
 - Add --dry-run to kubectl delete, taint, replace ([#88292](https://github.com/kubernetes/kubernetes/pull/88292), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI and Testing]
+- Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
 - Add huge page stats to Allocated resources in "kubectl describe node" ([#80605](https://github.com/kubernetes/kubernetes/pull/80605), [@odinuge](https://github.com/odinuge)) [SIG CLI]
+- Add support for pre allocated huge pages with different sizes, on node level ([#89252](https://github.com/kubernetes/kubernetes/pull/89252), [@odinuge](https://github.com/odinuge)) [SIG Apps and Node]
+- Adds support for NodeCIDR as an argument to --detect-local-mode ([#88935](https://github.com/kubernetes/kubernetes/pull/88935), [@satyasm](https://github.com/satyasm)) [SIG Network]
+- Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing]
+- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. 
+  After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. 
+  The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
+  Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery]
+- Azure Cloud Provider now supports using Azure network resources (Virtual Network, Load Balancer, Public IP, Route Table, Network Security Group, etc.) in different AAD Tenant and Subscription than those for the Kubernetes cluster. To use the feature, please reference https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md&#35;host-network-resources-in-different-aad-tenant-and-subscription. ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider]
+- Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
+- DefaultConstraints can be specified for the PodTopologySpread plugin in the component config ([#88671](https://github.com/kubernetes/kubernetes/pull/88671), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- EndpointSlice controller waits longer to retry failed sync. ([#89438](https://github.com/kubernetes/kubernetes/pull/89438), [@robscott](https://github.com/robscott)) [SIG Apps and Network]
+- Feat: change azure disk api-version ([#89250](https://github.com/kubernetes/kubernetes/pull/89250), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Feat: support [Azure shared disk](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-shared-enable), added a new field(`maxShares`) in azure disk storage class:
+  
+  kind: StorageClass
+  apiVersion: storage.k8s.io/v1
+  metadata:
+    name: shared-disk
+  provisioner: kubernetes.io/azure-disk
+  parameters:
+    skuname: Premium_LRS  &#35; Currently only available with premium SSDs.
+    cachingMode: None  &#35; ReadOnly host caching is not available for premium SSDs with maxShares>1
+    maxShares: 2 ([#89328](https://github.com/kubernetes/kubernetes/pull/89328), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Kube-apiserver, kube-scheduler and kube-controller manager now use SO_REUSEPORT socket option when listening on address defined by --bind-address and --secure-port flags, when running on Unix systems (Windows is NOT supported). This allows to run multiple instances of those processes on a single host with the same configuration, which allows to update/restart them in a graceful way, without causing downtime. ([#88893](https://github.com/kubernetes/kubernetes/pull/88893), [@invidian](https://github.com/invidian)) [SIG API Machinery, Scheduling and Testing]
 - Kubeadm: The ClusterStatus struct present in the kubeadm-config ConfigMap is deprecated and will be removed on a future version. It is going to be maintained by kubeadm until it gets removed. The same information can be found on `etcd` and `kube-apiserver` pod annotations, `kubeadm.kubernetes.io/etcd.advertise-client-urls` and `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint` respectively. ([#87656](https://github.com/kubernetes/kubernetes/pull/87656), [@ereslibre](https://github.com/ereslibre)) [SIG Cluster Lifecycle]
 - Kubeadm: add the experimental feature gate PublicKeysECDSA that can be used to create a
   cluster with ECDSA certificates from "kubeadm init". Renewal of existing ECDSA certificates is
   also supported using "kubeadm alpha certs renew", but not switching between the RSA and
   ECDSA algorithms on the fly or during upgrades. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth and Cluster Lifecycle]
 - Kubeadm: on kubeconfig certificate renewal, keep the embedded CA in sync with the one on disk ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
+- Kubeadm: support Windows specific kubelet flags in kubeadm-flags.env ([#88287](https://github.com/kubernetes/kubernetes/pull/88287), [@gab-satchi](https://github.com/gab-satchi)) [SIG Cluster Lifecycle and Windows]
 - Kubeadm: upgrade supports fallback to the nearest known etcd version if an unknown k8s version is passed ([#88373](https://github.com/kubernetes/kubernetes/pull/88373), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubectl cluster-info dump changed to only display a message telling you the location where the output was written when the output is not standard output. ([#88765](https://github.com/kubernetes/kubernetes/pull/88765), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
 - New flag `--show-hidden-metrics-for-version` in kube-scheduler can be used to show all hidden metrics that deprecated in the previous minor release. ([#84913](https://github.com/kubernetes/kubernetes/pull/84913), [@serathius](https://github.com/serathius)) [SIG Instrumentation and Scheduling]
+- Print NotReady when pod is not ready based on its conditions. ([#88240](https://github.com/kubernetes/kubernetes/pull/88240), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- Scheduler Extender API is now located under k8s.io/kube-scheduler/extender ([#88540](https://github.com/kubernetes/kubernetes/pull/88540), [@damemi](https://github.com/damemi)) [SIG Release, Scheduling and Testing]
 - Scheduler framework permit plugins now run at the end of the scheduling cycle, after reserve plugins. Waiting on permit will remain in the beginning of the binding cycle. ([#88199](https://github.com/kubernetes/kubernetes/pull/88199), [@mateuszlitwin](https://github.com/mateuszlitwin)) [SIG Scheduling]
+- Signatures on scale client methods have been modified to accept `context.Context` as a first argument. Signatures of Get, Update, and Patch methods have been updated to accept GetOptions, UpdateOptions and PatchOptions respectively. ([#88599](https://github.com/kubernetes/kubernetes/pull/88599), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery, Apps, Autoscaling and CLI]
+- Signatures on the dynamic client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88906](https://github.com/kubernetes/kubernetes/pull/88906), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps, CLI, Cluster Lifecycle, Storage and Testing]
+- Signatures on the metadata client methods have been modified to accept `context.Context` as a first argument. Signatures of Delete and DeleteCollection methods now accept DeleteOptions by value instead of by reference. ([#88910](https://github.com/kubernetes/kubernetes/pull/88910), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing]
+- Support create or update VMSS asynchronously. ([#89248](https://github.com/kubernetes/kubernetes/pull/89248), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider]
 - The kubelet and the default docker runtime now support running ephemeral containers in the Linux process namespace of a target container. Other container runtimes must implement this feature before it will be available in that runtime. ([#84731](https://github.com/kubernetes/kubernetes/pull/84731), [@verb](https://github.com/verb)) [SIG Node]
+- Update etcd client side to v3.4.4 ([#89169](https://github.com/kubernetes/kubernetes/pull/89169), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider]
+- Upgrade to azure-sdk v40.2.0 ([#89105](https://github.com/kubernetes/kubernetes/pull/89105), [@andyzhangx](https://github.com/andyzhangx)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Storage and Testing]
+- Webhooks will have alpha support for network proxy ([#85870](https://github.com/kubernetes/kubernetes/pull/85870), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Auth and Testing]
+- When client certificate files are provided, reload files for new connections, and close connections when a certificate changes. ([#79083](https://github.com/kubernetes/kubernetes/pull/79083), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery, Auth, Node and Testing]
+- When deleting objects using kubectl with the --force flag, you are no longer required to also specify --grace-period=0. ([#87776](https://github.com/kubernetes/kubernetes/pull/87776), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
+- `kubectl` now contains a `kubectl alpha debug` command. This command allows attaching an ephemeral container to a running pod for the purposes of debugging. ([#88004](https://github.com/kubernetes/kubernetes/pull/88004), [@verb](https://github.com/verb)) [SIG CLI]
+
+### Documentation
+
+- Improved error message for incorrect auth field. ([#82829](https://github.com/kubernetes/kubernetes/pull/82829), [@martin-schibsted](https://github.com/martin-schibsted)) [SIG Auth]
+- Update Japanese translation for kubectl help ([#86837](https://github.com/kubernetes/kubernetes/pull/86837), [@inductor](https://github.com/inductor)) [SIG CLI and Docs]
+- Updated the instructions for deploying the sample app. ([#82785](https://github.com/kubernetes/kubernetes/pull/82785), [@ashish-billore](https://github.com/ashish-billore)) [SIG API Machinery]
+- `kubectl plugin` now prints a note how to install krew ([#88577](https://github.com/kubernetes/kubernetes/pull/88577), [@corneliusweig](https://github.com/corneliusweig)) [SIG CLI]
 
 ### Other (Bug, Cleanup or Flake)
 
+- A PV set from in-tree source will have ordered requirement values in NodeAffinity when converted to CSIPersistentVolumeSource ([#88987](https://github.com/kubernetes/kubernetes/pull/88987), [@jiahuif](https://github.com/jiahuif)) [SIG Storage]
 - Add delays between goroutines for vm instance update ([#88094](https://github.com/kubernetes/kubernetes/pull/88094), [@aramase](https://github.com/aramase)) [SIG Cloud Provider]
 - Add init containers log to cluster dump info. ([#88324](https://github.com/kubernetes/kubernetes/pull/88324), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Azure VMSS LoadBalancerBackendAddressPools updating has been improved with squential-sync + concurrent-async requests. ([#88699](https://github.com/kubernetes/kubernetes/pull/88699), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Azure auth module for kubectl now requests login after refresh token expires. ([#86481](https://github.com/kubernetes/kubernetes/pull/86481), [@tdihp](https://github.com/tdihp)) [SIG API Machinery and Auth]
+- AzureFile and CephFS use new Mount library that prevents logging of sensitive mount options. ([#88684](https://github.com/kubernetes/kubernetes/pull/88684), [@saad-ali](https://github.com/saad-ali)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Beta.kubernetes.io/arch is already deprecated since v1.14, are targeted for removal in v1.18 ([#89462](https://github.com/kubernetes/kubernetes/pull/89462), [@wawa0210](https://github.com/wawa0210)) [SIG Testing]
+- Build: Enable kube-cross image-building on K8s Infra ([#88562](https://github.com/kubernetes/kubernetes/pull/88562), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing]
 - CPU limits are now respected for Windows containers. If a node is over-provisioned, no weighting is used - only limits are respected. ([#86101](https://github.com/kubernetes/kubernetes/pull/86101), [@PatrickLang](https://github.com/PatrickLang)) [SIG Node, Testing and Windows]
+- Client-go certificate manager rotation gained the ability to preserve optional intermediate chains accompanying issued certificates ([#88744](https://github.com/kubernetes/kubernetes/pull/88744), [@jackkleeman](https://github.com/jackkleeman)) [SIG API Machinery and Auth]
 - Cloud provider config CloudProviderBackoffMode has been removed since it won't be used anymore. ([#88463](https://github.com/kubernetes/kubernetes/pull/88463), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Conformance image now depends on stretch-slim instead of debian-hyperkube-base as that image is being deprecated and removed. ([#88702](https://github.com/kubernetes/kubernetes/pull/88702), [@dims](https://github.com/dims)) [SIG Cluster Lifecycle, Release and Testing]
+- Deprecate --generator flag from kubectl create commands ([#88655](https://github.com/kubernetes/kubernetes/pull/88655), [@soltysh](https://github.com/soltysh)) [SIG CLI]
+- Deprecate kubectl top flags related to heapster
+  Drop support of heapster in kubectl top ([#87498](https://github.com/kubernetes/kubernetes/pull/87498), [@serathius](https://github.com/serathius)) [SIG CLI]
+- EndpointSlice should not contain endpoints for terminating pods ([#89056](https://github.com/kubernetes/kubernetes/pull/89056), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network]
 - Evictions due to pods breaching their ephemeral storage limits are now recorded by the `kubelet_evictions` metric and can be alerted on. ([#87906](https://github.com/kubernetes/kubernetes/pull/87906), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node]
+- FIX: prevent apiserver from panicking when failing to load audit webhook config file ([#88879](https://github.com/kubernetes/kubernetes/pull/88879), [@JoshVanL](https://github.com/JoshVanL)) [SIG API Machinery and Auth]
+- Fix /readyz to return error immediately after a shutdown is initiated, before the --shutdown-delay-duration has elapsed. ([#88911](https://github.com/kubernetes/kubernetes/pull/88911), [@tkashem](https://github.com/tkashem)) [SIG API Machinery]
+- Fix a bug that didn't allow to use IPv6 addresses with leading zeros ([#89341](https://github.com/kubernetes/kubernetes/pull/89341), [@aojea](https://github.com/aojea)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Fix a bug where ExternalTrafficPolicy is not applied to service ExternalIPs. ([#88786](https://github.com/kubernetes/kubernetes/pull/88786), [@freehan](https://github.com/freehan)) [SIG Network]
+- Fix a bug where kubenet fails to parse the tc output. ([#83572](https://github.com/kubernetes/kubernetes/pull/83572), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
+- Fix bug with xfs_repair from stopping xfs mount ([#89444](https://github.com/kubernetes/kubernetes/pull/89444), [@gnufied](https://github.com/gnufied)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Fix describe ingress annotations not sorted. ([#88394](https://github.com/kubernetes/kubernetes/pull/88394), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix detection of SystemOOMs in which the victim is a container. ([#88871](https://github.com/kubernetes/kubernetes/pull/88871), [@dashpole](https://github.com/dashpole)) [SIG Node]
+- Fix handling of aws-load-balancer-security-groups annotation. Security-Groups assigned with this annotation are no longer modified by kubernetes which is the expected behaviour of most users. Also no unnecessary Security-Groups are created anymore if this annotation is used. ([#83446](https://github.com/kubernetes/kubernetes/pull/83446), [@Elias481](https://github.com/Elias481)) [SIG Cloud Provider]
+- Fix invalid VMSS updates due to incorrect cache ([#89002](https://github.com/kubernetes/kubernetes/pull/89002), [@ArchangelSDY](https://github.com/ArchangelSDY)) [SIG Cloud Provider]
+- Fix isCurrentInstance for Windows by removing the dependency of hostname. ([#89138](https://github.com/kubernetes/kubernetes/pull/89138), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
+- Fix kube-apiserver startup to wait for APIServices to be installed into the HTTP handler before reporting readiness. ([#89147](https://github.com/kubernetes/kubernetes/pull/89147), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- Fix kubectl create deployment image name ([#86636](https://github.com/kubernetes/kubernetes/pull/86636), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Fix missing "apiVersion" for "involvedObject" in Events for Nodes. ([#87537](https://github.com/kubernetes/kubernetes/pull/87537), [@uthark](https://github.com/uthark)) [SIG Apps and Node]
+- Fix that prevents repeated fetching of PVC/PV objects by kubelet when processing of pod volumes fails. While this prevents hammering API server in these error scenarios, it means that some errors in processing volume(s) for a pod could now take up to 2-3 minutes before retry. ([#88141](https://github.com/kubernetes/kubernetes/pull/88141), [@tedyu](https://github.com/tedyu)) [SIG Node and Storage]
+- Fix the VMSS name and resource group name when updating Azure VMSS for LoadBalancer backendPools ([#89337](https://github.com/kubernetes/kubernetes/pull/89337), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
 - Fix: add remediation in azure disk attach/detach ([#88444](https://github.com/kubernetes/kubernetes/pull/88444), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fix: check disk status before disk azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: azure file mount timeout issue ([#88610](https://github.com/kubernetes/kubernetes/pull/88610), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
+- Fix: check disk status before delete azure disk ([#88360](https://github.com/kubernetes/kubernetes/pull/88360), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
+- Fix: corrupted mount point in csi driver ([#88569](https://github.com/kubernetes/kubernetes/pull/88569), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage]
+- Fixed a bug in the TopologyManager. Previously, the TopologyManager would only guarantee alignment if container creation was serialized in some way. Alignment is now guaranteed under all scenarios of container creation. ([#87759](https://github.com/kubernetes/kubernetes/pull/87759), [@klueska](https://github.com/klueska)) [SIG Node]
+- Fixed a data race in kubelet image manager that can cause static pod workers to silently stop working. ([#88915](https://github.com/kubernetes/kubernetes/pull/88915), [@roycaihw](https://github.com/roycaihw)) [SIG Node]
+- Fixed an issue that could cause the kubelet to incorrectly run concurrent pod reconciliation loops and crash. ([#89055](https://github.com/kubernetes/kubernetes/pull/89055), [@tedyu](https://github.com/tedyu)) [SIG Node]
+- Fixed block CSI volume cleanup after timeouts. ([#88660](https://github.com/kubernetes/kubernetes/pull/88660), [@jsafrane](https://github.com/jsafrane)) [SIG Node and Storage]
+- Fixed bug where a nonzero exit code was returned when initializing zsh completion even though zsh completion was successfully initialized ([#88165](https://github.com/kubernetes/kubernetes/pull/88165), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
 - Fixed cleaning of CSI raw block volumes. ([#87978](https://github.com/kubernetes/kubernetes/pull/87978), [@jsafrane](https://github.com/jsafrane)) [SIG Storage]
+- Fixes conversion error in multi-version custom resources that could cause metadata.generation to increment on no-op patches or updates of a custom resource. ([#88995](https://github.com/kubernetes/kubernetes/pull/88995), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
+- Fixes issue where you can't attach more than 15 GCE Persistent Disks to c2, n2, m1, m2 machine types. ([#88602](https://github.com/kubernetes/kubernetes/pull/88602), [@yuga711](https://github.com/yuga711)) [SIG Storage]
+- Fixes v1.18.0-rc.1 regression in `kubectl port-forward` when specifying a local and remote port ([#89401](https://github.com/kubernetes/kubernetes/pull/89401), [@liggitt](https://github.com/liggitt)) [SIG CLI]
+- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#88678](https://github.com/kubernetes/kubernetes/pull/88678), [@verult](https://github.com/verult)) [SIG Apps, Node and Storage]
 - Get-kube.sh uses the gcloud's current local GCP service account for auth when the provider is GCE or GKE instead of the metadata server default ([#88383](https://github.com/kubernetes/kubernetes/pull/88383), [@BenTheElder](https://github.com/BenTheElder)) [SIG Cluster Lifecycle]
 - Golang/x/net has been updated to bring in fixes for CVE-2020-9283 ([#88381](https://github.com/kubernetes/kubernetes/pull/88381), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation]
+- Hide kubectl.kubernetes.io/last-applied-configuration in describe command ([#88758](https://github.com/kubernetes/kubernetes/pull/88758), [@soltysh](https://github.com/soltysh)) [SIG Auth and CLI]
+- In GKE alpha clusters it will be possible to use the service annotation `cloud.google.com/network-tier: Standard` ([#88487](https://github.com/kubernetes/kubernetes/pull/88487), [@zioproto](https://github.com/zioproto)) [SIG Cloud Provider]
+- Ipvs: only attempt setting of sysctlconnreuse on supported kernels ([#88541](https://github.com/kubernetes/kubernetes/pull/88541), [@cmluciano](https://github.com/cmluciano)) [SIG Network]
+- Kube-proxy: on dual-stack mode, if it is not able to get the IP Family of an endpoint, logs it with level InfoV(4) instead of Warning, avoiding flooding the logs for endpoints without addresses ([#88934](https://github.com/kubernetes/kubernetes/pull/88934), [@aojea](https://github.com/aojea)) [SIG Network]
 - Kubeadm now includes CoreDNS version 1.6.7 ([#86260](https://github.com/kubernetes/kubernetes/pull/86260), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cluster Lifecycle]
 - Kubeadm: fix the bug that 'kubeadm upgrade' hangs in single node cluster ([#88434](https://github.com/kubernetes/kubernetes/pull/88434), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
+- Kubelet: fix the bug that kubelet help information can not show the right type of flags ([#88515](https://github.com/kubernetes/kubernetes/pull/88515), [@SataQiu](https://github.com/SataQiu)) [SIG Docs and Node]
+- Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability]
 - Optimize kubectl version help info ([#88313](https://github.com/kubernetes/kubernetes/pull/88313), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
+- Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
 - Removes the deprecated command `kubectl rolling-update` ([#88057](https://github.com/kubernetes/kubernetes/pull/88057), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG Architecture, CLI and Testing]
-
-
-# v1.18.0-alpha.5
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.5
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes.tar.gz) | `6452cac2b80721e9f577cb117c29b9ac6858812b4275c2becbf74312566f7d016e8b34019bd1bf7615131b191613bf9b973e40ad9ac8f6de9007d41ef2d7fd70`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-src.tar.gz) | `e41d9d4dd6910a42990051fcdca4bf5d3999df46375abd27ffc56aae9b455ae984872302d590da6aa85bba6079334fb5fe511596b415ee79843dee1c61c137da`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-386.tar.gz) | `5c95935863492b31d4aaa6be93260088dafea27663eb91edca980ca3a8485310e60441bc9050d4d577e9c3f7ffd96db516db8d64321124cec1b712e957c9fe1c`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-darwin-amd64.tar.gz) | `868faa578b3738604d8be62fae599ccc556799f1ce54807f1fe72599f20f8a1f98ad8152fac14a08a463322530b696d375253ba3653325e74b587df6e0510da3`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-386.tar.gz) | `76a89d1d30b476b47f8fb808e342f89608e5c1c1787c4c06f2d7e763f9482e2ae8b31e6ad26541972e2b9a3a7c28327e3150cdd355e8b8d8b050a801bbf08d49`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-amd64.tar.gz) | `07ad96a09b44d1c707d7c68312c5d69b101a3424bf1e6e9400b2e7a3fba78df04302985d473ddd640d8f3f0257be34110dbe1304b9565dd9d7a4639b7b7b85fd`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm.tar.gz) | `c04fed9fa370a75c1b8e18b2be0821943bb9befcc784d14762ea3278e73600332a9b324d5eeaa1801d20ad6be07a553c41dcf4fa7ab3eadd0730ab043d687c8c`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-arm64.tar.gz) | `4199147dea9954333df26d34248a1cb7b02ebbd6380ffcd42d9f9ed5fdabae45a59215474dab3c11436c82e60bd27cbd03b3dde288bf611cd3e78b87c783c6a9`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-ppc64le.tar.gz) | `4f6d4d61d1c52d3253ca19031ebcd4bad06d19b68bbaaab5c8e8c590774faea4a5ceab1f05f2706b61780927e1467815b3479342c84d45df965aba78414727c4`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-linux-s390x.tar.gz) | `e2a454151ae5dd891230fb516a3f73f73ab97832db66fd3d12e7f1657a569f58a9fe2654d50ddd7d8ec88a5ff5094199323a4c6d7d44dcf7edb06cca11dd4de1`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-386.tar.gz) | `14b262ba3b71c41f545db2a017cf1746075ada5745a858d2a62bc9df7c5dc10607220375db85e2c4cb85307b09709e58bc66a407488e0961191e3249dc7742b0`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-client-windows-amd64.tar.gz) | `26353c294755a917216664364b524982b7f5fc6aa832ce90134bb178df8a78604963c68873f121ea5f2626ff615bdbf2ffe54e00578739cde6df42ffae034732`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-amd64.tar.gz) | `ba77e0e7c610f59647c1b2601f82752964a0f54b7ad609a89b00fcfd553d0f0249f6662becbabaa755bb769b36a2000779f08022c40fb8cc61440337481317a1`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm.tar.gz) | `45e87b3e844ea26958b0b489e8c9b90900a3253000850f5ff9e87ffdcafba72ab8fd17b5ba092051a58a4bc277912c047a85940ec7f093dff6f9e8bf6fed3b42`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-arm64.tar.gz) | `155e136e3124ead69c594eead3398d6cfdbb8f823c324880e8a7bbd1b570b05d13a77a69abd0a6758cfcc7923971cc6da4d3e0c1680fd519b632803ece00d5ce`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-ppc64le.tar.gz) | `3fa0fb8221da19ad9d03278961172b7fa29a618b30abfa55e7243bb937dede8df56658acf02e6b61e7274fbc9395e237f49c62f2a83017eca2a69f67af31c01c`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-server-linux-s390x.tar.gz) | `db3199c3d7ba0b326d71dc8b80f50b195e79e662f71386a3b2976d47d13d7b0136887cc21df6f53e70a3d733da6eac7bbbf3bab2df8a1909a3cee4b44c32dd0b`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-amd64.tar.gz) | `addcdfbad7f12647e6babb8eadf853a374605c8f18bf63f416fa4d3bf1b903aa206679d840433206423a984bb925e7983366edcdf777cf5daef6ef88e53d6dfa`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm.tar.gz) | `b2ac54e0396e153523d116a2aaa32c919d6243931e0104cd47a23f546d710e7abdaa9eae92d978ce63c92041e63a9b56f5dd8fd06c812a7018a10ecac440f768`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-arm64.tar.gz) | `7aab36f2735cba805e4fd109831a1af0f586a88db3f07581b6dc2a2aab90076b22c96b490b4f6461a8fb690bf78948b6d514274f0d6fb0664081de2d44dc48e1`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-ppc64le.tar.gz) | `a579936f07ebf86f69f297ac50ba4c34caf2c0b903f73190eb581c78382b05ef36d41ade5bfd25d7b1b658cfcbee3d7125702a18e7480f9b09a62733a512a18a`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-linux-s390x.tar.gz) | `58fa0359ddd48835192fab1136a2b9b45d1927b04411502c269cda07cb8a8106536973fb4c7fedf1d41893a524c9fe2e21078fdf27bfbeed778273d024f14449`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.5/kubernetes-node-windows-amd64.tar.gz) | `9086c03cd92b440686cea6d8c4e48045cc46a43ab92ae0e70350b3f51804b9e2aaae7178142306768bae00d9ef6dd938167972bfa90b12223540093f735a45db`
-
-## Changelog since v1.18.0-alpha.3
-
-### Deprecation
-
-- Kubeadm: command line option "kubelet-version" for `kubeadm upgrade node` has been deprecated and will be removed in a future release. ([#87942](https://github.com/kubernetes/kubernetes/pull/87942), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-
-### API Change
-
-- Kubelet podresources API now provides the information about active pods only. ([#79409](https://github.com/kubernetes/kubernetes/pull/79409), [@takmatsu](https://github.com/takmatsu)) [SIG Node]
-- Remove deprecated fields from .leaderElection in kubescheduler.config.k8s.io/v1alpha2 ([#87904](https://github.com/kubernetes/kubernetes/pull/87904), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Signatures on generated clientset methods have been modified to accept `context.Context` as a first argument. Signatures of generated Create, Update, and Patch methods have been updated to accept CreateOptions, UpdateOptions and PatchOptions respectively. Clientsets that with the previous interface have been added in new "deprecated" packages to allow incremental migration to the new APIs. The deprecated packages will be removed in the 1.21 release. ([#87299](https://github.com/kubernetes/kubernetes/pull/87299), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, Apps, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Scheduling, Storage, Testing and Windows]
-- The k8s.io/node-api component is no longer updated. Instead, use the RuntimeClass types located within k8s.io/api, and the generated clients located within k8s.io/client-go ([#87503](https://github.com/kubernetes/kubernetes/pull/87503), [@liggitt](https://github.com/liggitt)) [SIG Node and Release]
-
-### Feature
-
-- Add indexer for storage cacher ([#85445](https://github.com/kubernetes/kubernetes/pull/85445), [@shaloulcy](https://github.com/shaloulcy)) [SIG API Machinery]
-- Add support for mount options to the FC volume plugin ([#87499](https://github.com/kubernetes/kubernetes/pull/87499), [@ejweber](https://github.com/ejweber)) [SIG Storage]
-- Added a config-mode flag in azure auth module to enable getting AAD token without spn: prefix in audience claim. When it's not specified, the default behavior doesn't change. ([#87630](https://github.com/kubernetes/kubernetes/pull/87630), [@weinong](https://github.com/weinong)) [SIG API Machinery, Auth, CLI and Cloud Provider]
-- Introduced BackoffManager interface for backoff management ([#87829](https://github.com/kubernetes/kubernetes/pull/87829), [@zhan849](https://github.com/zhan849)) [SIG API Machinery]
-- PodTopologySpread plugin now excludes terminatingPods when making scheduling decisions. ([#87845](https://github.com/kubernetes/kubernetes/pull/87845), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
-- Promote CSIMigrationOpenStack to Beta (off by default since it requires installation of the OpenStack Cinder CSI Driver)
-  The in-tree AWS OpenStack Cinder "kubernetes.io/cinder" was already deprecated a while ago and will be removed in 1.20. Users should enable CSIMigration + CSIMigrationOpenStack features and install the OpenStack Cinder CSI Driver (https://github.com/kubernetes-sigs/cloud-provider-openstack) to avoid disruption to existing Pod and PVC objects at that time.
-  Users should start using the OpenStack Cinder CSI Driver directly for any new volumes. ([#85637](https://github.com/kubernetes/kubernetes/pull/85637), [@dims](https://github.com/dims)) [SIG Cloud Provider]
-
-### Design
-
-- The scheduler Permit extension point doesn't return a boolean value in its Allow() and Reject() functions. ([#87936](https://github.com/kubernetes/kubernetes/pull/87936), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling]
-
-### Other (Bug, Cleanup or Flake)
-
-- Adds "volume.beta.kubernetes.io/migrated-to" annotation to PV's and PVC's when they are migrated to signal external provisioners to pick up those objects for Provisioning and Deleting. ([#87098](https://github.com/kubernetes/kubernetes/pull/87098), [@davidz627](https://github.com/davidz627)) [SIG Apps and Storage]
-- Fix a bug in the dual-stack IPVS proxier where stale IPv6 endpoints were not being cleaned up ([#87695](https://github.com/kubernetes/kubernetes/pull/87695), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network]
-- Fix kubectl drain ignore daemonsets and others. ([#87361](https://github.com/kubernetes/kubernetes/pull/87361), [@zhouya0](https://github.com/zhouya0)) [SIG CLI]
-- Fix: add azure disk migration support for CSINode ([#88014](https://github.com/kubernetes/kubernetes/pull/88014), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage]
-- Fix: add non-retriable errors in azure clients ([#87941](https://github.com/kubernetes/kubernetes/pull/87941), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
-- Fixed NetworkPolicy validation that Except values are accepted when they are outside the CIDR range. ([#86578](https://github.com/kubernetes/kubernetes/pull/86578), [@tnqn](https://github.com/tnqn)) [SIG Network]
-- Improves performance of the node authorizer ([#87696](https://github.com/kubernetes/kubernetes/pull/87696), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- Iptables/userspace proxy: improve performance by getting local addresses only once per sync loop, instead of for every external IP ([#85617](https://github.com/kubernetes/kubernetes/pull/85617), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Network]
-- Kube-aggregator: always sets unavailableGauge metric to reflect the current state of a service. ([#87778](https://github.com/kubernetes/kubernetes/pull/87778), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery]
-- Kubeadm allows to configure single-stack clusters if dual-stack is enabled ([#87453](https://github.com/kubernetes/kubernetes/pull/87453), [@aojea](https://github.com/aojea)) [SIG API Machinery, Cluster Lifecycle and Network]
-- Kubeadm:  'kubeadm alpha kubelet config download' has been removed, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87944](https://github.com/kubernetes/kubernetes/pull/87944), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubeadm: remove 'kubeadm upgrade node config' command since it was deprecated in v1.15, please use 'kubeadm upgrade node phase kubelet-config' instead ([#87975](https://github.com/kubernetes/kubernetes/pull/87975), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-- Kubectl describe <type> and kubectl top pod will return a message saying "No resources found" or "No resources found in <namespace> namespace" if there are no results to display. ([#87527](https://github.com/kubernetes/kubernetes/pull/87527), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- Kubelet metrics gathered through metrics-server or prometheus should no longer timeout for Windows nodes running more than 3 pods. ([#87730](https://github.com/kubernetes/kubernetes/pull/87730), [@marosset](https://github.com/marosset)) [SIG Node, Testing and Windows]
-- Kubelet metrics have been changed to buckets.
-  For example the exec/{podNamespace}/{podID}/{containerName} is now just exec. ([#87913](https://github.com/kubernetes/kubernetes/pull/87913), [@cheftako](https://github.com/cheftako)) [SIG Node]
-- Limit number of instances in a single update to GCE target pool to 1000. ([#87881](https://github.com/kubernetes/kubernetes/pull/87881), [@wojtek-t](https://github.com/wojtek-t)) [SIG Cloud Provider, Network and Scalability]
-- Make Azure clients only retry on specified HTTP status codes ([#88017](https://github.com/kubernetes/kubernetes/pull/88017), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Pause image contains "Architecture" in non-amd64 images ([#87954](https://github.com/kubernetes/kubernetes/pull/87954), [@BenTheElder](https://github.com/BenTheElder)) [SIG Release]
-- Pods that are considered for preemption and haven't started don't produce an error log. ([#87900](https://github.com/kubernetes/kubernetes/pull/87900), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- Prevent error message from being displayed when running kubectl plugin list and your path includes an empty string ([#87633](https://github.com/kubernetes/kubernetes/pull/87633), [@brianpursley](https://github.com/brianpursley)) [SIG CLI]
-- `kubectl create clusterrolebinding` creates rbac.authorization.k8s.io/v1 object ([#85889](https://github.com/kubernetes/kubernetes/pull/85889), [@oke-py](https://github.com/oke-py)) [SIG CLI]
-
-# v1.18.0-alpha.4
-
-[Documentation](https://docs.k8s.io)
-
-## Important note about manual tag
-
-Due to a [tagging bug in our Release Engineering tooling](https://github.com/kubernetes/release/issues/1080) during `v1.18.0-alpha.3`, we needed to push a manual tag (`v1.18.0-alpha.4`).
-
-**No binaries have been produced or will be provided for `v1.18.0-alpha.4`.**
-
-The changelog for `v1.18.0-alpha.4` is included as part of the [changelog since v1.18.0-alpha.3][#changelog-since-v1180-alpha3] section.
-
-# v1.18.0-alpha.3
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.3
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes.tar.gz) | `60bf3bfc23b428f53fd853bac18a4a905b980fcc0bacd35ccd6357a89cfc26e47de60975ea6b712e65980e6b9df82a22331152d9f08ed4dba44558ba23a422d4`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-src.tar.gz) | `8adf1016565a7c93713ab6fa4293c2d13b4f6e4e1ec4dcba60bd71e218b4dbe9ef5eb7dbb469006743f498fc7ddeb21865cd12bec041af60b1c0edce8b7aecd5`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-386.tar.gz) | `abb32e894e8280c772e96227b574da81cd1eac374b8d29158b7f222ed550087c65482eef4a9817dfb5f2baf0d9b85fcdfa8feced0fbc1aacced7296853b57e1f`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | `5e4b1a993264e256ec1656305de7c306094cae9781af8f1382df4ce4eed48ce030827fde1a5e757d4ad57233d52075c9e4e93a69efbdc1102e4ba810705ccddc`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-386.tar.gz) | `68da39c2ae101d2b38f6137ceda07eb0c2124794982a62ef483245dbffb0611c1441ca085fa3127e7a9977f45646788832a783544ff06954114548ea0e526e46`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | `dc236ffa8ad426620e50181419e9bebe3c161e953dbfb8a019f61b11286e1eb950b40d7cc03423bdf3e6974973bcded51300f98b55570c29732fa492dcde761d`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | `ab0a8bd6dc31ea160b731593cdc490b3cc03668b1141cf95310bd7060dcaf55c7ee9842e0acae81063fdacb043c3552ccdd12a94afd71d5310b3ce056fdaa06c`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | `159ea083c601710d0d6aea423eeb346c99ffaf2abd137d35a53e87a07f5caf12fca8790925f3196f67b768fa92a024f83b50325dbca9ccd4dde6c59acdce3509`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | `16b0459adfa26575d13be49ab53ac7f0ffd05e184e4e13d2dfbfe725d46bb8ac891e1fd8aebe36ecd419781d4cc5cf3bd2aaaf5263cf283724618c4012408f40`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | `d5aa1f5d89168995d2797eb839a04ce32560f405b38c1c0baaa0e313e4771ae7bb3b28e22433ad5897d36aadf95f73eb69d8d411d31c4115b6b0adf5fe041f85`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-386.tar.gz) | `374e16a1e52009be88c94786f80174d82dff66399bf294c9bee18a2159c42251c5debef1109a92570799148b08024960c6c50b8299a93fd66ebef94f198f34e9`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | `5a94c1068c19271f810b994adad8e62fae03b3d4473c7c9e6d056995ff7757ea61dd8d140c9267dd41e48808876673ce117826d35a3c1bb5652752f11a044d57`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | `a677bec81f0eba75114b92ff955bac74512b47e53959d56a685dae5edd527283d91485b1e86ad74ef389c5405863badf7eb22e2f0c9a568a4d0cb495c6a5c32f`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | `2fb696f86ff13ebeb5f3cf2b254bf41303644c5ea84a292782eac6123550702655284d957676d382698c091358e5c7fe73f32803699c19be7138d6530fe413b6`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | `738e95da9cfb8f1309479078098de1c38cef5e1dd5ee1129b77651a936a412b7cd0cf15e652afc7421219646a98846ab31694970432e48dea9c9cafa03aa59cf`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | `7a85bfcbb2aa636df60c41879e96e788742ecd72040cb0db2a93418439c125218c58a4cfa96d01b0296c295793e94c544e87c2d98d50b49bc4cb06b41f874376`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | `1f1cdb2efa3e7cac857203d8845df2fdaa5cf1f20df764efffff29371945ec58f6deeba06f8fbf70b96faf81b0c955bf4cb84e30f9516cb2cc1ed27c2d2185a6`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | `4ccfced3f5ba4adfa58f4a9d1b2c5bdb3e89f9203ab0e27d11eb1c325ac323ebe63c015d2c9d070b233f5d1da76cab5349da3528511c1cd243e66edc9af381c4`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | `d695a69d18449062e4c129e54ec8384c573955f8108f4b78adc2ec929719f2196b995469c728dd6656c63c44cda24315543939f85131ebc773cfe0de689df55b`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | `21df1da88c89000abc22f97e482c3aaa5ce53ec9628d83dda2e04a1d86c4d53be46c03ed6f1f211df3ee5071bce39d944ff7716b5b6ada3b9c4821d368b0a898`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | `ff77e3aacb6ed9d89baed92ef542c8b5cec83151b6421948583cf608bca3b779dce41fc6852961e00225d5e1502f6a634bfa61a36efa90e1aee90dedb787c2d2`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | `57d75b7977ec1a0f6e7ed96a304dbb3b8664910f42ca19aab319a9ec33535ff5901dfca4abcb33bf5741cde6d152acd89a5f8178f0efe1dc24430e0c1af5b98f`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | `63fdbb71773cfd73a914c498e69bb9eea3fc314366c99ffb8bd42ec5b4dae807682c83c1eb5cfb1e2feb4d11d9e49cc85ba644e954241320a835798be7653d61`
-
-## Changelog since v1.18.0-alpha.2
-
-### Deprecation
-
-- Remove all the generators from kubectl run. It will now only create pods. Additionally, deprecates all the flags that are not relevant anymore. ([#87077](https://github.com/kubernetes/kubernetes/pull/87077), [@soltysh](https://github.com/soltysh)) [SIG Architecture, SIG CLI, and SIG Testing]
-- kubeadm: kube-dns is deprecated and will not be supported in a future version ([#86574](https://github.com/kubernetes/kubernetes/pull/86574), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle]
-
-### API Change
-
-- Add kubescheduler.config.k8s.io/v1alpha2 ([#87628](https://github.com/kubernetes/kubernetes/pull/87628), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
-- --enable-cadvisor-endpoints is now disabled by default. If you need access to the cAdvisor v1 Json API please enable it explicitly in the kubelet command line. Please note that this flag was deprecated in 1.15 and will be removed in 1.19. ([#87440](https://github.com/kubernetes/kubernetes/pull/87440), [@dims](https://github.com/dims)) [SIG Instrumentation, SIG Node, and SIG Testing]
-- The following feature gates are removed, because the associated features were unconditionally enabled in previous releases: CustomResourceValidation, CustomResourceSubresources, CustomResourceWebhookConversion, CustomResourcePublishOpenAPI, CustomResourceDefaulting ([#87475](https://github.com/kubernetes/kubernetes/pull/87475), [@liggitt](https://github.com/liggitt)) [SIG API Machinery]
-
-### Feature
-
-- aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery]
-- API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2.  The messages are of the form
-
-  Throttling request took 1.50705208s, request: GET:<URL>
-
-  The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery]
-- kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- The kubectl --dry-run flag now accepts the values 'client', 'server', and 'none', to support client-side and server-side dry-run strategies. The boolean and unset values for the --dry-run flag are deprecated and a value will be required in a future version. ([#87580](https://github.com/kubernetes/kubernetes/pull/87580), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG CLI]
-- Add support for pre-allocated hugepages for more than one page size ([#82820](https://github.com/kubernetes/kubernetes/pull/82820), [@odinuge](https://github.com/odinuge)) [SIG Apps]
-- Update CNI version to v0.8.5 ([#78819](https://github.com/kubernetes/kubernetes/pull/78819), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, SIG Cluster Lifecycle, SIG Network, SIG Release, and SIG Testing]
-- Skip default spreading scoring plugin for pods that define TopologySpreadConstraints ([#87566](https://github.com/kubernetes/kubernetes/pull/87566), [@skilxn-go](https://github.com/skilxn-go)) [SIG Scheduling]
-- Added more details to taint toleration errors ([#87250](https://github.com/kubernetes/kubernetes/pull/87250), [@starizard](https://github.com/starizard)) [SIG Apps, and SIG Scheduling]
-- Scheduler: Add DefaultBinder plugin ([#87430](https://github.com/kubernetes/kubernetes/pull/87430), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling, and SIG Testing]
-- Kube-apiserver metrics will now include request counts, latencies, and response sizes for /healthz, /livez, and /readyz requests. ([#83598](https://github.com/kubernetes/kubernetes/pull/83598), [@jktomer](https://github.com/jktomer)) [SIG API Machinery]
-
-### Other (Bug, Cleanup or Flake)
-
-- Fix the masters rolling upgrade causing thundering herd of LISTs on etcd leading to control plane unavailability. ([#86430](https://github.com/kubernetes/kubernetes/pull/86430), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, SIG Node, and SIG Testing]
-- `kubectl diff` now returns 1 only on diff finding changes, and >1 on kubectl errors. The "exit status code 1" message as also been muted. ([#87437](https://github.com/kubernetes/kubernetes/pull/87437), [@apelisse](https://github.com/apelisse)) [SIG CLI, and SIG Testing]
-- To reduce chances of throttling, VM cache is set to nil when Azure node provisioning state is deleting ([#87635](https://github.com/kubernetes/kubernetes/pull/87635), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider]
-- Fix regression in statefulset conversion which prevented applying a statefulset multiple times. ([#87706](https://github.com/kubernetes/kubernetes/pull/87706), [@liggitt](https://github.com/liggitt)) [SIG Apps, and SIG Testing]
-- fixed two scheduler metrics (pending_pods and schedule_attempts_total) not being recorded ([#87692](https://github.com/kubernetes/kubernetes/pull/87692), [@everpeace](https://github.com/everpeace)) [SIG Scheduling]
-- Resolved a performance issue in the node authorizer index maintenance. ([#87693](https://github.com/kubernetes/kubernetes/pull/87693), [@liggitt](https://github.com/liggitt)) [SIG Auth]
-- Removed the 'client' label from apiserver_request_total. ([#87669](https://github.com/kubernetes/kubernetes/pull/87669), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, and SIG Instrumentation]
-- `(*"k8s.io/client-go/rest".Request).{Do,DoRaw,Stream,Watch}` now require callers to pass a `context.Context` as an argument. The context is used for timeout and cancellation signaling and to pass supplementary information to round trippers in the wrapped transport chain. If you don't need any of this functionality, it is sufficient to pass a context created with `context.Background()` to these functions. The `(*"k8s.io/client-go/rest".Request).Context` method is removed now that all methods that execute a request accept a context directly. ([#87597](https://github.com/kubernetes/kubernetes/pull/87597), [@mikedanese](https://github.com/mikedanese)) [SIG API Machinery, SIG Apps, SIG Auth, SIG Autoscaling, SIG CLI, SIG Cloud Provider, SIG Cluster Lifecycle, SIG Instrumentation, SIG Network, SIG Node, SIG Scheduling, SIG Storage, and SIG Testing]
-- For volumes that allow attaches across multiple nodes, attach and detach operations across different nodes are now executed in parallel. ([#87258](https://github.com/kubernetes/kubernetes/pull/87258), [@verult](https://github.com/verult)) [SIG Apps, SIG Node, and SIG Storage]
-- kubeadm: apply further improvements to the tentative support for concurrent etcd member join. Fixes a bug where multiple members can receive the same hostname. Increase the etcd client dial timeout and retry timeout for add/remove/... operations. ([#87505](https://github.com/kubernetes/kubernetes/pull/87505), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Reverted a kubectl azure auth module change where oidc claim spn: prefix was omitted resulting a breaking behavior with existing Azure AD OIDC enabled api-server ([#87507](https://github.com/kubernetes/kubernetes/pull/87507), [@weinong](https://github.com/weinong)) [SIG API Machinery, SIG Auth, and SIG Cloud Provider]
-- Update cri-tools to v1.17.0 ([#86305](https://github.com/kubernetes/kubernetes/pull/86305), [@saschagrunert](https://github.com/saschagrunert)) [SIG Cluster Lifecycle, and SIG Release]
-- kubeadm: remove the deprecated CoreDNS feature-gate. It was set to "true" since v1.11 when the feature went GA. In v1.13 it was marked as deprecated and hidden from the CLI. ([#87400](https://github.com/kubernetes/kubernetes/pull/87400), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle]
-- Shared informers are now more reliable in the face of network disruption. ([#86015](https://github.com/kubernetes/kubernetes/pull/86015), [@squeed](https://github.com/squeed)) [SIG API Machinery]
-- the CSR signing cert/key pairs will be reloaded from disk like the kube-apiserver cert/key pairs ([#86816](https://github.com/kubernetes/kubernetes/pull/86816), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, SIG Apps, and SIG Auth]
-- "kubectl describe statefulsets.apps" prints garbage for rolling update partition ([#85846](https://github.com/kubernetes/kubernetes/pull/85846), [@phil9909](https://github.com/phil9909)) [SIG CLI]
-
-
-<!-- NEW RELEASE NOTES ENTRY -->
-
-
-# v1.18.0-alpha.2
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.2
-
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes.tar.gz) | `7af83386b4b35353f0aa1bdaf73599eb08b1d1ca11ecc2c606854aff754db69f3cd3dc761b6d7fc86f01052f615ca53185f33dbf9e53b2f926b0f02fc103fbd3`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-src.tar.gz) | `a14b02a0a0bde97795a836a8f5897b0ee6b43e010e13e43dd4cca80a5b962a1ef3704eedc7916fed1c38ec663a71db48c228c91e5daacba7d9370df98c7ddfb6`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-386.tar.gz) | `427f214d47ded44519007de2ae87160c56c2920358130e474b768299751a9affcbc1b1f0f936c39c6138837bca2a97792a6700896976e98c4beee8a1944cfde1`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | `861fd81ac3bd45765575bedf5e002a2294aba48ef9e15980fc7d6783985f7d7fcde990ea0aef34690977a88df758722ec0a2e170d5dcc3eb01372e64e5439192`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-386.tar.gz) | `7d59b05d6247e2606a8321c72cd239713373d876dbb43b0fb7f1cb857fa6c998038b41eeed78d9eb67ce77b0b71776ceed428cce0f8d2203c5181b473e0bd86c`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | `7cdefb4e32bad9d2df5bb8e7e0a6f4dab2ae6b7afef5d801ac5c342d4effdeacd799081fa2dec699ecf549200786c7623c3176252010f12494a95240dd63311d`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | `6212bbf0fa1d01ced77dcca2c4b76b73956cd3c6b70e0701c1fe0df5ff37160835f6b84fa2481e0e6979516551b14d8232d1c72764a559a3652bfe2a1e7488ff`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | `1f0d9990700510165ee471acb2f88222f1b80e8f6deb351ce14cf50a70a9840fb99606781e416a13231c74b2bd7576981b5348171aa33b628d2666e366cd4629`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | `77e00ba12a32db81e96f8de84609de93f32c61bb3f53875a57496d213aa6d1b92c09ad5a6de240a78e1a5bf77fac587ff92874f34a10f8909ae08ca32fda45d2`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | `a39ec2044bed5a4570e9c83068e0fc0ce923ccffa44380f8bbc3247426beaff79c8a84613bcb58b05f0eb3afbc34c79fe3309aa2e0b81abcfd0aa04770e62e05`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-386.tar.gz) | `1a0ab88f9b7e34b60ab31d5538e97202a256ad8b7b7ed5070cae5f2f12d5d4edeae615db7a34ebbe254004b6393c6b2480100b09e30e59c9139492a3019a596a`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | `1966eb5dfb78c1bc33aaa6389f32512e3aa92584250a0164182f3566c81d901b59ec78ee4e25df658bc1dd221b5a9527d6ce3b6c487ca3e3c0b319a077caa735`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | `f814d6a3872e4572aa4da297c29def4c1fad8eba0903946780b6bf9788c72b99d71085c5aef9e12c01133b26fa4563c1766ba724ad2a8af2670a24397951a94d`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | `56aa08225e546c92c2ff88ac57d3db7dd5e63640772ea72a429f080f7069827138cbc206f6f5fe3a0c01bfca043a9eda305ecdc1dcb864649114893e46b6dc84`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | `fb87128d905211ba097aa860244a376575ae2edbaca6e51402a24bc2964854b9b273e09df3d31a2bcffc91509f7eecb2118b183fb0e0eb544f33403fa235c274`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | `6d21fbf39b9d3a0df9642407d6f698fabdc809aca83af197bceb58a81b25846072f407f8fb7caae2e02dc90912e3e0f5894f062f91bcb69f8c2329625d3dfeb7`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | `ddcda4dc360ca97705f71bf2a18ddacd7b7ddf77535b62e699e97a1b2dd24843751313351d0112e238afe69558e8271eba4d27ab77bb67b4b9e3fbde6eec85c9`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | `78915a9bde35c70c67014f0cea8754849db4f6a84491a3ad9678fd3bc0203e43af5a63cfafe104ae1d56b05ce74893a87a6dcd008d7859e1af6b3bce65425b5d`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | `3218e811abcb0cb09d80742def339be3916db5e9bbc62c0dc8e6d87085f7e3d9eeed79dea081906f1de78ddd07b7e3acdbd7765fdb838d262bb35602fd1df106`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | `fa22de9c4440b8fb27f4e77a5a63c5e1c8aa8aa30bb79eda843b0f40498c21b8c0ad79fff1d841bb9fef53fe20da272506de9a86f81a0b36d028dbeab2e482ce`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | `bbda9b5cc66e8f13d235703b2a85e2c4f02fa16af047be4d27a3e198e11eb11706e4a0fbb6c20978c770b069cd4cd9894b661f09937df9d507411548c36576e0`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | `b2ed1eda013069adce2aac00b86d75b84e006cfce9bafac0b5a2bafcb60f8f2cb346b5ea44eafa72d777871abef1ea890eb3a2a05de28968f9316fa88886a8ed`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | `bd8eb23dba711f31b5148257076b1bbe9629f2a75de213b2c779bd5b29279e9bf22f8bde32f4bc814f4c0cc49e19671eb8b24f4105f0fe2c1490c4b78ec3c704`
-
-## Changelog since v1.18.0-alpha.1
-
-### Other notable changes
-
-* Bump golang/mock version to v1.3.1 ([#87326](https://github.com/kubernetes/kubernetes/pull/87326), [@wawa0210](https://github.com/wawa0210))
-* fix a bug that orphan revision cannot be adopted and statefulset cannot be synced ([#86801](https://github.com/kubernetes/kubernetes/pull/86801), [@likakuli](https://github.com/likakuli))
-* Azure storage clients now suppress requests on throttling ([#87306](https://github.com/kubernetes/kubernetes/pull/87306), [@feiskyer](https://github.com/feiskyer))
-* Introduce Alpha field `Immutable` in both Secret and ConfigMap objects to mark their contents as immutable. The implementation is hidden behind feature gate `ImmutableEphemeralVolumes` (currently in Alpha stage). ([#86377](https://github.com/kubernetes/kubernetes/pull/86377), [@wojtek-t](https://github.com/wojtek-t))
-* EndpointSlices will now be enabled by default. A new `EndpointSliceProxying` feature gate determines if kube-proxy will use EndpointSlices, this is disabled by default. ([#86137](https://github.com/kubernetes/kubernetes/pull/86137), [@robscott](https://github.com/robscott))
-* kubeadm upgrades always persist the etcd backup for stacked ([#86861](https://github.com/kubernetes/kubernetes/pull/86861), [@SataQiu](https://github.com/SataQiu))
-* Fix the bug PIP's DNS is deleted if no DNS label service annotation isn't set. ([#87246](https://github.com/kubernetes/kubernetes/pull/87246), [@nilo19](https://github.com/nilo19))
-* New flag `--show-hidden-metrics-for-version` in kube-controller-manager can be used to show all hidden metrics that deprecated in the previous minor release. ([#85281](https://github.com/kubernetes/kubernetes/pull/85281), [@RainbowMango](https://github.com/RainbowMango))
-* Azure network and VM clients now suppress requests on throttling ([#87122](https://github.com/kubernetes/kubernetes/pull/87122), [@feiskyer](https://github.com/feiskyer))
-* `kubectl apply  -f <file> --prune -n <namespace>` should prune all resources not defined in the file in the cli specified namespace. ([#85613](https://github.com/kubernetes/kubernetes/pull/85613), [@MartinKaburu](https://github.com/MartinKaburu))
-* Fixes service account token admission error in clusters that do not run the service account token controller ([#87029](https://github.com/kubernetes/kubernetes/pull/87029), [@liggitt](https://github.com/liggitt))
-* CustomResourceDefinition status fields are no longer required for client validation when submitting manifests.  ([#87213](https://github.com/kubernetes/kubernetes/pull/87213), [@hasheddan](https://github.com/hasheddan))
-* All apiservers log request lines in a more greppable format. ([#87203](https://github.com/kubernetes/kubernetes/pull/87203), [@lavalamp](https://github.com/lavalamp))
-* provider/azure: Network security groups can now be in a separate resource group. ([#87035](https://github.com/kubernetes/kubernetes/pull/87035), [@CecileRobertMichon](https://github.com/CecileRobertMichon))
-* Cleaned up the output from `kubectl describe CSINode <name>`. ([#85283](https://github.com/kubernetes/kubernetes/pull/85283), [@huffmanca](https://github.com/huffmanca))
-* Fixed the following  ([#84265](https://github.com/kubernetes/kubernetes/pull/84265), [@bhagwat070919](https://github.com/bhagwat070919))
-    * -  AWS Cloud Provider attempts to delete LoadBalancer security group it didn’t provision
-    * -  AWS Cloud Provider creates default LoadBalancer security group even if annotation [service.beta.kubernetes.io/aws-load-balancer-security-groups] is present
-* kubelet: resource metrics endpoint `/metrics/resource/v1alpha1` as well as all metrics under this endpoint have been deprecated. ([#86282](https://github.com/kubernetes/kubernetes/pull/86282), [@RainbowMango](https://github.com/RainbowMango))
-    * Please convert to the following metrics emitted by endpoint `/metrics/resource`:
-    * - scrape_error --> scrape_error
-    * - node_cpu_usage_seconds_total --> node_cpu_usage_seconds
-    * - node_memory_working_set_bytes --> node_memory_working_set_bytes
-    * - container_cpu_usage_seconds_total --> container_cpu_usage_seconds
-    * - container_memory_working_set_bytes --> container_memory_working_set_bytes
-    * - scrape_error --> scrape_error
-* You can now pass "--node-ip ::" to kubelet to indicate that it should autodetect an IPv6 address to use as the node's primary address. ([#85850](https://github.com/kubernetes/kubernetes/pull/85850), [@danwinship](https://github.com/danwinship))
-* kubeadm: support automatic retry after failing to pull image ([#86899](https://github.com/kubernetes/kubernetes/pull/86899), [@SataQiu](https://github.com/SataQiu))
-* TODO ([#87044](https://github.com/kubernetes/kubernetes/pull/87044), [@jennybuckley](https://github.com/jennybuckley))
-* Improved yaml parsing performance ([#85458](https://github.com/kubernetes/kubernetes/pull/85458), [@cjcullen](https://github.com/cjcullen))
-* Fixed a bug which could prevent a provider ID from ever being set for node if an error occurred determining the provider ID when the node was added. ([#87043](https://github.com/kubernetes/kubernetes/pull/87043), [@zjs](https://github.com/zjs))
-* fix a regression in kubenet that prevent pods to obtain ip addresses ([#85993](https://github.com/kubernetes/kubernetes/pull/85993), [@chendotjs](https://github.com/chendotjs))
-* Bind kube-dns containers to linux nodes to avoid Windows scheduling ([#83358](https://github.com/kubernetes/kubernetes/pull/83358), [@wawa0210](https://github.com/wawa0210))
-* The following features are unconditionally enabled and the corresponding `--feature-gates` flags have been removed: `PodPriority`, `TaintNodesByCondition`, `ResourceQuotaScopeSelectors` and `ScheduleDaemonSetPods` ([#86210](https://github.com/kubernetes/kubernetes/pull/86210), [@draveness](https://github.com/draveness))
-* Bind dns-horizontal containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83364](https://github.com/kubernetes/kubernetes/pull/83364), [@wawa0210](https://github.com/wawa0210))
-* fix kubectl annotate error when local=true is set ([#86952](https://github.com/kubernetes/kubernetes/pull/86952), [@zhouya0](https://github.com/zhouya0))
-* Bug fixes: ([#84163](https://github.com/kubernetes/kubernetes/pull/84163), [@david-tigera](https://github.com/david-tigera))
-    * Make sure we include latest packages node #351 ([@caseydavenport](https://github.com/caseydavenport))
-* fix kuebctl apply set-last-applied namespaces error   ([#86474](https://github.com/kubernetes/kubernetes/pull/86474), [@zhouya0](https://github.com/zhouya0))
-* Add VolumeBinder method to FrameworkHandle interface, which allows user to get the volume binder when implementing scheduler framework plugins. ([#86940](https://github.com/kubernetes/kubernetes/pull/86940), [@skilxn-go](https://github.com/skilxn-go))
-* elasticsearch supports automatically setting the advertise address ([#85944](https://github.com/kubernetes/kubernetes/pull/85944), [@SataQiu](https://github.com/SataQiu))
-* If a serving certificates param specifies a name that is an IP for an SNI certificate, it will have priority for replying to server connections. ([#85308](https://github.com/kubernetes/kubernetes/pull/85308), [@deads2k](https://github.com/deads2k))
-* kube-proxy: Added dual-stack IPv4/IPv6 support to the iptables proxier. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry))
-* Azure VMSS/VMSSVM clients now suppress requests on throttling ([#86740](https://github.com/kubernetes/kubernetes/pull/86740), [@feiskyer](https://github.com/feiskyer))
-* New metric kubelet_pleg_last_seen_seconds to aid diagnosis of PLEG not healthy issues. ([#86251](https://github.com/kubernetes/kubernetes/pull/86251), [@bboreham](https://github.com/bboreham))
-* For subprotocol negotiation, both client and server protocol is required now. ([#86646](https://github.com/kubernetes/kubernetes/pull/86646), [@tedyu](https://github.com/tedyu))
-* kubeadm: use bind-address option to configure the kube-controller-manager and kube-scheduler http probes ([#86493](https://github.com/kubernetes/kubernetes/pull/86493), [@aojea](https://github.com/aojea))
-* Marked scheduler's metrics scheduling_algorithm_predicate_evaluation_seconds and ([#86584](https://github.com/kubernetes/kubernetes/pull/86584), [@xiaoanyunfei](https://github.com/xiaoanyunfei))
-    * scheduling_algorithm_priority_evaluation_seconds as deprecated. Those are replaced by framework_extension_point_duration_seconds[extenstion_point="Filter"] and framework_extension_point_duration_seconds[extenstion_point="Score"] respectively.
-* Marked scheduler's scheduling_duration_seconds Summary metric as deprecated ([#86586](https://github.com/kubernetes/kubernetes/pull/86586), [@xiaoanyunfei](https://github.com/xiaoanyunfei))
-* Add instructions about how to bring up e2e test cluster ([#85836](https://github.com/kubernetes/kubernetes/pull/85836), [@YangLu1031](https://github.com/YangLu1031))
-* If a required flag is not provided to a command, the user will only see the required flag error message, instead of the entire usage menu. ([#86693](https://github.com/kubernetes/kubernetes/pull/86693), [@sallyom](https://github.com/sallyom))
-* kubeadm: tolerate whitespace when validating certificate authority PEM data in kubeconfig files ([#86705](https://github.com/kubernetes/kubernetes/pull/86705), [@neolit123](https://github.com/neolit123))
-* kubeadm: add support for the "ci/k8s-master" version label as a replacement for "ci-cross/*", which no longer exists. ([#86609](https://github.com/kubernetes/kubernetes/pull/86609), [@Pensu](https://github.com/Pensu))
-* Fix EndpointSlice controller race condition and ensure that it handles external changes to EndpointSlices. ([#85703](https://github.com/kubernetes/kubernetes/pull/85703), [@robscott](https://github.com/robscott))
-* Fix nil pointer dereference in azure cloud provider ([#85975](https://github.com/kubernetes/kubernetes/pull/85975), [@ldx](https://github.com/ldx))
-* fix: azure disk could not mounted on Standard_DC4s/DC2s instances ([#86612](https://github.com/kubernetes/kubernetes/pull/86612), [@andyzhangx](https://github.com/andyzhangx))
-* Fixes v1.17.0 regression in --service-cluster-ip-range handling with IPv4 ranges larger than 65536 IP addresses ([#86534](https://github.com/kubernetes/kubernetes/pull/86534), [@liggitt](https://github.com/liggitt))
-* Adds back support for AlwaysCheckAllPredicates flag. ([#86496](https://github.com/kubernetes/kubernetes/pull/86496), [@ahg-g](https://github.com/ahg-g))
-* Azure global rate limit is switched to per-client. A set of new rate limit configure options are introduced, including routeRateLimit, SubnetsRateLimit, InterfaceRateLimit, RouteTableRateLimit, LoadBalancerRateLimit, PublicIPAddressRateLimit, SecurityGroupRateLimit, VirtualMachineRateLimit, StorageAccountRateLimit, DiskRateLimit, SnapshotRateLimit, VirtualMachineScaleSetRateLimit and VirtualMachineSizeRateLimit. ([#86515](https://github.com/kubernetes/kubernetes/pull/86515), [@feiskyer](https://github.com/feiskyer))
-    * The original rate limit options would be default values for those new client's rate limiter.
-* Fix issue [#85805](https://github.com/kubernetes/kubernetes/pull/85805) about resource not found in azure cloud provider when lb specified in other resource group. ([#86502](https://github.com/kubernetes/kubernetes/pull/86502), [@levimm](https://github.com/levimm))
-* `AlwaysCheckAllPredicates` is deprecated in scheduler Policy API. ([#86369](https://github.com/kubernetes/kubernetes/pull/86369), [@Huang-Wei](https://github.com/Huang-Wei))
-* Kubernetes KMS provider for data encryption now supports disabling the in-memory data encryption key (DEK) cache by setting cachesize to a negative value. ([#86294](https://github.com/kubernetes/kubernetes/pull/86294), [@enj](https://github.com/enj))
-* option `preConfiguredBackendPoolLoadBalancerTypes` is added to azure cloud provider for the pre-configured load balancers, possible values: `""`, `"internal"`, "external"`, `"all"` ([#86338](https://github.com/kubernetes/kubernetes/pull/86338), [@gossion](https://github.com/gossion))
-* Promote StartupProbe to beta for 1.18 release ([#83437](https://github.com/kubernetes/kubernetes/pull/83437), [@matthyx](https://github.com/matthyx))
-* Fixes issue where AAD token obtained by kubectl is incompatible with on-behalf-of flow and oidc. ([#86412](https://github.com/kubernetes/kubernetes/pull/86412), [@weinong](https://github.com/weinong))
-    * The audience claim before this fix has "spn:" prefix. After this fix, "spn:" prefix is omitted.
-* change CounterVec to Counter about  PLEGDiscardEvent ([#86167](https://github.com/kubernetes/kubernetes/pull/86167), [@yiyang5055](https://github.com/yiyang5055))
-* hollow-node do not use remote CRI anymore ([#86425](https://github.com/kubernetes/kubernetes/pull/86425), [@jkaniuk](https://github.com/jkaniuk))
-* hollow-node use fake CRI ([#85879](https://github.com/kubernetes/kubernetes/pull/85879), [@gongguan](https://github.com/gongguan))
-
-
-
-# v1.18.0-alpha.1
-
-[Documentation](https://docs.k8s.io)
-
-## Downloads for v1.18.0-alpha.1
-
-
-filename | sha512 hash
--------- | -----------
-[kubernetes.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes.tar.gz) | `0c4904efc7f4f1436119c91dc1b6c93b3bd9c7490362a394bff10099c18e1e7600c4f6e2fcbaeb2d342a36c4b20692715cf7aa8ada6dfac369f44cc9292529d7`
-[kubernetes-src.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-src.tar.gz) | `0a50fc6816c730ca5ae4c4f26d5ad7b049607d29f6a782a4e5b4b05ac50e016486e269dafcc6a163bd15e1a192780a9a987f1bb959696993641c603ed1e841c8`
-
-### Client Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-client-darwin-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-386.tar.gz) | `c6d75f7f3f20bef17fc7564a619b54e6f4a673d041b7c9ec93663763a1cc8dd16aecd7a2af70e8d54825a0eecb9762cf2edfdade840604c9a32ecd9cc2d5ac3c`
-[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | `ca1f19db289933beace6daee6fc30af19b0e260634ef6e89f773464a05e24551c791be58b67da7a7e2a863e28b7cbcc7b24b6b9bf467113c26da76ac8f54fdb6`
-[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-386.tar.gz) | `af2e673653eb39c3f24a54efc68e1055f9258bdf6cf8fea42faf42c05abefc2da853f42faac3b166c37e2a7533020b8993b98c0d6d80a5b66f39e91d8ae0a3fb`
-[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | `9009032c3f94ac8a78c1322a28e16644ce3b20989eb762685a1819148aed6e883ca8e1200e5ec37ec0853f115c67e09b5d697d6cf5d4c45f653788a2d3a2f84f`
-[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | `afba9595b37a3f2eead6e3418573f7ce093b55467dce4da0b8de860028576b96b837a2fd942f9c276e965da694e31fbd523eeb39aefb902d7e7a2f169344d271`
-[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | `04fc3b2fe3f271807f0bc6c61be52456f26a1af904964400be819b7914519edc72cbab9afab2bb2e2ba1a108963079367cedfb253c9364c0175d1fcc64d52f5c`
-[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | `04c7edab874b33175ff7bebfff5b3a032bc6eb088fcd7387ffcd5b3fa71395ca8c5f9427b7ddb496e92087dfdb09eaf14a46e9513071d3bd73df76c182922d38`
-[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | `499287dbbc33399a37b9f3b35e0124ff20b17b6619f25a207ee9c606ef261af61fa0c328dde18c7ce2d3dfb2eea2376623bc3425d16bc8515932a68b44f8bede`
-[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-386.tar.gz) | `cf84aeddf00f126fb13c0436b116dd0464a625659e44c84bf863517db0406afb4eefd86807e7543c4f96006d275772fbf66214ae7d582db5865c84ac3545b3e6`
-[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | `69f20558ccd5cd6dbaccf29307210db4e687af21f6d71f68c69d3a39766862686ac1333ab8a5012010ca5c5e3c11676b45e498e3d4c38773da7d24bcefc46d95`
-
-### Server Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | `3f29df2ce904a0f10db4c1d7a425a36f420867b595da3fa158ae430bfead90def2f2139f51425b349faa8a9303dcf20ea01657cb6ea28eb6ad64f5bb32ce2ed1`
-[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | `4a21073b2273d721fbf062c254840be5c8471a010bcc0c731b101729e36e61f637cb7fcb521a22e8d24808510242f4fff8a6ca40f10e9acd849c2a47bf135f27`
-[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | `7f1cb6d721bedc90e28b16f99bea7e59f5ad6267c31ef39c14d34db6ad6aad87ee51d2acdd01b6903307c1c00b58ff6b785a03d5a491cc3f8a4df9a1d76d406c`
-[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | `8f2b552030b5274b1c2c7c166eacd5a14b0c6ca0f23042f4c52efe87e22a167ba4460dcd66615a5ecd26d9e88336be1fb555548392e70efe59070dd2c314da98`
-[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | `8d9f2c96f66edafb7c8b3aa90960d29b41471743842aede6b47b3b2e61f4306fb6fc60b9ebc18820c547ee200bfedfe254c1cde962d447c791097dd30e79abdb`
-
-### Node Binaries
-
-filename | sha512 hash
--------- | -----------
-[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | `84194cb081d1502f8ca68143569f9707d96f1a28fcf0c574ebd203321463a8b605f67bb2a365eaffb14fbeb8d55c8d3fa17431780b242fb9cba3a14426a0cd4a`
-[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | `0091e108ab94fd8683b89c597c4fdc2fbf4920b007cfcd5297072c44bc3a230dfe5ceed16473e15c3e6cf5edab866d7004b53edab95be0400cc60e009eee0d9d`
-[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | `b7e85682cc2848a35d52fd6f01c247f039ee1b5dd03345713821ea10a7fa9939b944f91087baae95eaa0665d11857c1b81c454f720add077287b091f9f19e5d3`
-[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | `cd1f0849e9c62b5d2c93ff0cebf58843e178d8a88317f45f76de0db5ae020b8027e9503a5fccc96445184e0d77ecdf6f57787176ac31dbcbd01323cd0a190cbb`
-[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | `e1e697a34424c75d75415b613b81c8af5f64384226c5152d869f12fd7db1a3e25724975b73fa3d89e56e4bf78d5fd07e68a709ba8566f53691ba6a88addc79ea`
-[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.18.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | `c725a19a4013c74e22383ad3fb4cb799b3e161c4318fdad066daf806730a89bc3be3ff0f75678d02b3cbe52b2ef0c411c0639968e200b9df470be40bb2c015cc`
-
-## Changelog since v1.17.0
-
-### Action Required
-
-* action required ([#85363](https://github.com/kubernetes/kubernetes/pull/85363), [@immutableT](https://github.com/immutableT))
-    * 1. Currently, if users were to explicitly specify CacheSize of 0 for KMS provider, they would end-up with a provider that caches up to 1000 keys. This PR changes this behavior.
-    * Post this PR, when users supply 0 for CacheSize this will result in a validation error.
-    * 2. CacheSize type was changed from int32 to *int32. This allows defaulting logic to differentiate between cases where users explicitly supplied 0 vs. not supplied any value.
-    * 3. KMS Provider's endpoint (path to Unix socket) is now validated when the EncryptionConfiguration files is loaded. This used to be handled by the GRPCService.
-
-### Other notable changes
-
-* fix: azure data disk should use same key as os disk by default ([#86351](https://github.com/kubernetes/kubernetes/pull/86351), [@andyzhangx](https://github.com/andyzhangx))
-* New flag `--show-hidden-metrics-for-version` in kube-proxy can be used to show all hidden metrics that deprecated in the previous minor release. ([#85279](https://github.com/kubernetes/kubernetes/pull/85279), [@RainbowMango](https://github.com/RainbowMango))
-* Remove cluster-monitoring addon ([#85512](https://github.com/kubernetes/kubernetes/pull/85512), [@serathius](https://github.com/serathius))
-* Changed core_pattern on COS nodes to be an absolute path. ([#86329](https://github.com/kubernetes/kubernetes/pull/86329), [@mml](https://github.com/mml))
-* Track mount operations as uncertain if operation fails with non-final error ([#82492](https://github.com/kubernetes/kubernetes/pull/82492), [@gnufied](https://github.com/gnufied))
-* add kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout to configure IPVS connection timeouts. ([#85517](https://github.com/kubernetes/kubernetes/pull/85517), [@andrewsykim](https://github.com/andrewsykim))
-* The sample-apiserver aggregated conformance test has updated to use the Kubernetes v1.17.0 sample apiserver ([#84735](https://github.com/kubernetes/kubernetes/pull/84735), [@liggitt](https://github.com/liggitt))
-* The underlying format of the `CPUManager` state file has changed. Upgrades should be seamless, but any third-party tools that rely on reading the previous format need to be updated. ([#84462](https://github.com/kubernetes/kubernetes/pull/84462), [@klueska](https://github.com/klueska))
-* kubernetes will try to acquire the iptables lock every 100 msec during 5 seconds instead of every second. This specially useful for environments using kube-proxy in iptables mode with a high churn rate of services. ([#85771](https://github.com/kubernetes/kubernetes/pull/85771), [@aojea](https://github.com/aojea))
-* Fixed a panic in the kubelet cleaning up pod volumes ([#86277](https://github.com/kubernetes/kubernetes/pull/86277), [@tedyu](https://github.com/tedyu))
-* azure cloud provider cache TTL is configurable, list of the azure cloud provider is as following: ([#86266](https://github.com/kubernetes/kubernetes/pull/86266), [@zqingqing1](https://github.com/zqingqing1))
-    * - "availabilitySetNodesCacheTTLInSeconds"
-    * - "vmssCacheTTLInSeconds"
-    * - "vmssVirtualMachinesCacheTTLInSeconds"
-    * - "vmCacheTTLInSeconds"
-    * - "loadBalancerCacheTTLInSeconds"
-    * - "nsgCacheTTLInSeconds"
-    * - "routeTableCacheTTLInSeconds"
-* Fixes kube-proxy when EndpointSlice feature gate is enabled on Windows. ([#86016](https://github.com/kubernetes/kubernetes/pull/86016), [@robscott](https://github.com/robscott))
-* Fixes wrong validation result of NetworkPolicy PolicyTypes ([#85747](https://github.com/kubernetes/kubernetes/pull/85747), [@tnqn](https://github.com/tnqn))
-* Fixes an issue with kubelet-reported pod status on deleted/recreated pods. ([#86320](https://github.com/kubernetes/kubernetes/pull/86320), [@liggitt](https://github.com/liggitt))
-* kube-apiserver no longer serves the following deprecated APIs: ([#85903](https://github.com/kubernetes/kubernetes/pull/85903), [@liggitt](https://github.com/liggitt))
-        * All resources under `apps/v1beta1` and `apps/v1beta2` - use `apps/v1` instead
-        * `daemonsets`, `deployments`, `replicasets` resources under `extensions/v1beta1` - use `apps/v1` instead
-        * `networkpolicies` resources under `extensions/v1beta1` - use `networking.k8s.io/v1` instead
-        * `podsecuritypolicies` resources under `extensions/v1beta1` - use `policy/v1beta1` instead
-* kubeadm: fix potential panic when executing "kubeadm reset" with a corrupted kubelet.conf file ([#86216](https://github.com/kubernetes/kubernetes/pull/86216), [@neolit123](https://github.com/neolit123))
-* Fix a bug in port-forward: named port not working with service ([#85511](https://github.com/kubernetes/kubernetes/pull/85511), [@oke-py](https://github.com/oke-py))
-* kube-proxy no longer modifies shared EndpointSlices. ([#86092](https://github.com/kubernetes/kubernetes/pull/86092), [@robscott](https://github.com/robscott))
-* allow for configuration of CoreDNS replica count ([#85837](https://github.com/kubernetes/kubernetes/pull/85837), [@pickledrick](https://github.com/pickledrick))
-* Fixed a regression where the kubelet would fail to update the ready status of pods. ([#84951](https://github.com/kubernetes/kubernetes/pull/84951), [@tedyu](https://github.com/tedyu))
-* Resolves performance regression in client-go discovery clients constructed using `NewDiscoveryClientForConfig` or `NewDiscoveryClientForConfigOrDie`. ([#86168](https://github.com/kubernetes/kubernetes/pull/86168), [@liggitt](https://github.com/liggitt))
-* Make error message and service event message more clear ([#86078](https://github.com/kubernetes/kubernetes/pull/86078), [@feiskyer](https://github.com/feiskyer))
-* e2e-test-framework: add e2e test namespace dump if all tests succeed but the cleanup fails. ([#85542](https://github.com/kubernetes/kubernetes/pull/85542), [@schrodit](https://github.com/schrodit))
-* SafeSysctlWhitelist: add net.ipv4.ping_group_range ([#85463](https://github.com/kubernetes/kubernetes/pull/85463), [@AkihiroSuda](https://github.com/AkihiroSuda))
-* kubelet: the metric process_start_time_seconds be marked as with the ALPHA stability level. ([#85446](https://github.com/kubernetes/kubernetes/pull/85446), [@RainbowMango](https://github.com/RainbowMango))
-* API request throttling (due to a high rate of requests) is now reported in the kubelet (and other component) logs by default.  The messages are of the form ([#80649](https://github.com/kubernetes/kubernetes/pull/80649), [@RobertKrawitz](https://github.com/RobertKrawitz))
-    * Throttling request took 1.50705208s, request: GET:<URL>
-    * The presence of large numbers of these messages, particularly with long delay times, may indicate to the administrator the need to tune the cluster accordingly.
-* Fix API Server potential memory leak issue in processing watch request. ([#85410](https://github.com/kubernetes/kubernetes/pull/85410), [@answer1991](https://github.com/answer1991))
-* Verify kubelet & kube-proxy can recover after being killed on Windows nodes ([#84886](https://github.com/kubernetes/kubernetes/pull/84886), [@YangLu1031](https://github.com/YangLu1031))
-* Fixed an issue that the scheduler only returns the first failure reason. ([#86022](https://github.com/kubernetes/kubernetes/pull/86022), [@Huang-Wei](https://github.com/Huang-Wei))
-* kubectl/drain: add skip-wait-for-delete-timeout option. ([#85577](https://github.com/kubernetes/kubernetes/pull/85577), [@michaelgugino](https://github.com/michaelgugino))
-    * If pod DeletionTimestamp older than N seconds, skip waiting for the pod.  Seconds must be greater than 0 to skip.
-* Following metrics have been turned off: ([#83841](https://github.com/kubernetes/kubernetes/pull/83841), [@RainbowMango](https://github.com/RainbowMango))
-    * - kubelet_pod_worker_latency_microseconds
-    * - kubelet_pod_start_latency_microseconds
-    * - kubelet_cgroup_manager_latency_microseconds
-    * - kubelet_pod_worker_start_latency_microseconds
-    * - kubelet_pleg_relist_latency_microseconds
-    * - kubelet_pleg_relist_interval_microseconds
-    * - kubelet_eviction_stats_age_microseconds
-    * - kubelet_runtime_operations
-    * - kubelet_runtime_operations_latency_microseconds
-    * - kubelet_runtime_operations_errors
-    * - kubelet_device_plugin_registration_count
-    * - kubelet_device_plugin_alloc_latency_microseconds
-    * - kubelet_docker_operations
-    * - kubelet_docker_operations_latency_microseconds
-    * - kubelet_docker_operations_errors
-    * - kubelet_docker_operations_timeout
-    * - network_plugin_operations_latency_microseconds
-* - Renamed Kubelet metric certificate_manager_server_expiration_seconds to certificate_manager_server_ttl_seconds and changed to report the second until expiration at read time rather than absolute time of expiry. ([#85874](https://github.com/kubernetes/kubernetes/pull/85874), [@sambdavidson](https://github.com/sambdavidson))
-    * - Improved accuracy of Kubelet metric rest_client_exec_plugin_ttl_seconds.
-* Bind metadata-agent containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83363](https://github.com/kubernetes/kubernetes/pull/83363), [@wawa0210](https://github.com/wawa0210))
-* Bind metrics-server containers to linux nodes to avoid Windows scheduling on kubernetes cluster includes linux nodes and windows nodes ([#83362](https://github.com/kubernetes/kubernetes/pull/83362), [@wawa0210](https://github.com/wawa0210))
-* During initialization phase (preflight), kubeadm now verifies the presence of the conntrack executable ([#85857](https://github.com/kubernetes/kubernetes/pull/85857), [@hnanni](https://github.com/hnanni))
-* VMSS cache is added so that less chances of VMSS GET throttling ([#85885](https://github.com/kubernetes/kubernetes/pull/85885), [@nilo19](https://github.com/nilo19))
-* Update go-winio module version from 0.4.11 to 0.4.14 ([#85739](https://github.com/kubernetes/kubernetes/pull/85739), [@wawa0210](https://github.com/wawa0210))
-* Fix LoadBalancer rule checking so that no unexpected LoadBalancer updates are made ([#85990](https://github.com/kubernetes/kubernetes/pull/85990), [@feiskyer](https://github.com/feiskyer))
-* kubectl drain node --dry-run will list pods that would be evicted or deleted ([#82660](https://github.com/kubernetes/kubernetes/pull/82660), [@sallyom](https://github.com/sallyom))
-* Windows nodes on GCE can use TPM-based authentication to the master. ([#85466](https://github.com/kubernetes/kubernetes/pull/85466), [@pjh](https://github.com/pjh))
-* kubectl/drain: add disable-eviction option. ([#85571](https://github.com/kubernetes/kubernetes/pull/85571), [@michaelgugino](https://github.com/michaelgugino))
-    * Force drain to use delete, even if eviction is supported. This will bypass checking PodDisruptionBudgets, and should be used with caution.
-* kubeadm now errors out whenever a not supported component config version is supplied for the kubelet and kube-proxy ([#85639](https://github.com/kubernetes/kubernetes/pull/85639), [@rosti](https://github.com/rosti))
-* Fixed issue with addon-resizer using deprecated extensions APIs ([#85793](https://github.com/kubernetes/kubernetes/pull/85793), [@bskiba](https://github.com/bskiba))
-* Includes FSType when describing CSI persistent volumes. ([#85293](https://github.com/kubernetes/kubernetes/pull/85293), [@huffmanca](https://github.com/huffmanca))
-* kubelet now exports a "server_expiration_renew_failure" and "client_expiration_renew_failure" metric counter if the certificate rotations cannot be performed. ([#84614](https://github.com/kubernetes/kubernetes/pull/84614), [@rphillips](https://github.com/rphillips))
-* kubeadm: don't write the kubelet environment file on "upgrade apply" ([#85412](https://github.com/kubernetes/kubernetes/pull/85412), [@boluisa](https://github.com/boluisa))
-* fix azure file AuthorizationFailure ([#85475](https://github.com/kubernetes/kubernetes/pull/85475), [@andyzhangx](https://github.com/andyzhangx))
-* Resolved regression in admission, authentication, and authorization webhook performance in v1.17.0-rc.1 ([#85810](https://github.com/kubernetes/kubernetes/pull/85810), [@liggitt](https://github.com/liggitt))
-* kubeadm: uses the apiserver AdvertiseAddress IP family to choose the etcd endpoint IP family for non external etcd clusters ([#85745](https://github.com/kubernetes/kubernetes/pull/85745), [@aojea](https://github.com/aojea))
-* kubeadm: Forward cluster name to the controller-manager arguments ([#85817](https://github.com/kubernetes/kubernetes/pull/85817), [@ereslibre](https://github.com/ereslibre))
-* Fixed "requested device X but found Y" attach error on AWS. ([#85675](https://github.com/kubernetes/kubernetes/pull/85675), [@jsafrane](https://github.com/jsafrane))
-* addons: elasticsearch discovery supports IPv6 ([#85543](https://github.com/kubernetes/kubernetes/pull/85543), [@SataQiu](https://github.com/SataQiu))
-* kubeadm: retry `kubeadm-config` ConfigMap creation or mutation if the apiserver is not responding. This will improve resiliency when joining new control plane nodes. ([#85763](https://github.com/kubernetes/kubernetes/pull/85763), [@ereslibre](https://github.com/ereslibre))
-* Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk))
-* Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts))
-* kubectl set resources will no longer return an error if passed an empty change for a resource.  ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom))
-    * kubectl set subject will no longer return an error if passed an empty change for a resource.
-* kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino))
-* kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123))
-* kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh))
-* kube-apiserver: Fixes a bug that hidden metrics can not be enabled by the command-line option `--show-hidden-metrics-for-version`. ([#85444](https://github.com/kubernetes/kubernetes/pull/85444), [@RainbowMango](https://github.com/RainbowMango))
-* kubeadm now supports automatic calculations of dual-stack node cidr masks to kube-controller-manager.  ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal))
-* Fix bug where EndpointSlice controller would attempt to modify shared objects. ([#85368](https://github.com/kubernetes/kubernetes/pull/85368), [@robscott](https://github.com/robscott))
-* Use context to check client closed instead of http.CloseNotifier in processing watch request which will reduce 1 goroutine for each request if proto is HTTP/2.x . ([#85408](https://github.com/kubernetes/kubernetes/pull/85408), [@answer1991](https://github.com/answer1991))
-* kubeadm: reset raises warnings if it cannot delete folders ([#85265](https://github.com/kubernetes/kubernetes/pull/85265), [@SataQiu](https://github.com/SataQiu))
-* Wait for kubelet & kube-proxy to be ready on Windows node within 10s ([#85228](https://github.com/kubernetes/kubernetes/pull/85228), [@YangLu1031](https://github.com/YangLu1031))
+- Resolved a regression in v1.18.0-rc.1 mounting windows volumes ([#89319](https://github.com/kubernetes/kubernetes/pull/89319), [@mboersma](https://github.com/mboersma)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
+- Scheduler PreScore plugins are not executed if there is one filtered node or less. ([#89370](https://github.com/kubernetes/kubernetes/pull/89370), [@ahg-g](https://github.com/ahg-g)) [SIG Scheduling]
+- Specifying PluginConfig for the same plugin more than once fails scheduler startup.
+  
+  Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling]
+- Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI]
+- Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing]
+- The EventRecorder from k8s.io/client-go/tools/events will now create events in the default namespace (instead of kube-system) when the related object does not have it set. ([#88815](https://github.com/kubernetes/kubernetes/pull/88815), [@enj](https://github.com/enj)) [SIG API Machinery]
+- The audit event sourceIPs list will now always end with the IP that sent the request directly to the API server. ([#87167](https://github.com/kubernetes/kubernetes/pull/87167), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Auth]
+- Update Cluster Autoscaler to 1.18.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.18.0 ([#89095](https://github.com/kubernetes/kubernetes/pull/89095), [@losipiuk](https://github.com/losipiuk)) [SIG Autoscaling and Cluster Lifecycle]
+- Update to use golang 1.13.8 ([#87648](https://github.com/kubernetes/kubernetes/pull/87648), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Release and Testing]
+- Validate kube-proxy flags --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout ([#88657](https://github.com/kubernetes/kubernetes/pull/88657), [@chendotjs](https://github.com/chendotjs)) [SIG Network]
+- Wait for all CRDs to show up in discovery endpoint before reporting readiness. ([#89145](https://github.com/kubernetes/kubernetes/pull/89145), [@sttts](https://github.com/sttts)) [SIG API Machinery]
+- `kubectl config view` now redacts bearer tokens by default, similar to client certificates. The `--raw` flag can still be used to output full content. ([#88985](https://github.com/kubernetes/kubernetes/pull/88985), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery and CLI]
diff --git a/content/ko/docs/sitemap.md b/content/ko/docs/sitemap.md
deleted file mode 100644
index c0a8e6c299..0000000000
--- a/content/ko/docs/sitemap.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
----
-<script language="JavaScript">
-var dropDownsPopulated = false;
-$( document ).ready(function() {
-  // When the document loads, get the metadata JSON, and kick off tbl render
-  $.get("/metadata.txt", function(data, status) {
-    metadata = $.parseJSON(data);
-    metadata.pages.sort(dynamicSort("t"));
-    mainLogic()
-    $(window).bind( 'hashchange', function(e) {
-      mainLogic();
-    });
-  });
-});
-function mainLogic()
-{
-  // If there's a tag filter, change the table/drop down output
-  if (!dropDownsPopulated) populateDropdowns();
-  var tag=window.location.hash.replace("#","");
-  if(tag) {
-    tag = $.trim(tag);
-    for (i=0;i<tagName.length;i++) {
-      querystringTag = tagName[i] + "=";
-      if (tag.indexOf(querystringTag) > -1)
-      {
-        console.log("in mainLog: querystringTag of " + querystringTag + " matches tag of " + tag);
-        tag = tag.replace(querystringTag,"");
-        selectDropDown(tagName[i],tag);
-        topicsFilter(tagName[i],tag,"output");
-      }
-    }
-  } else {
-    currentTopics = metadata.pages;
-  }
-  renderTable(currentTopics,"output");
-
-}
-function populateDropdowns()
-{
-  // Keeping mainLogic() brief by functionalizing the initialization of the
-  // drop-down filter boxes
-
-  for(i=0;i<metadata.pages.length;i++)
-  {
-    var metadataArrays = [metadata.pages[i].cr,metadata.pages[i].or,metadata.pages[i].mr];
-    for(j=0;j<metadataArrays.length;j++)
-    {
-      if (metadataArrays[j]) {
-        for (k=0;k<metadataArrays[j].length;k++) {
-          if (typeof storedTagsArrays[j] == 'undefined') storedTagsArrays[j] = new Array();
-          storedTagsArrays[j][metadataArrays[j][k][tagName[j]]] = true;
-          // ^ conceptList[metadata.pages[i].cr[k].concept] = true; (if rolling through concepts)
-          // ^ conceptList['container'] = true; (ultimate result)
-          // ^ objectList[metadata.pages[i].or[k].object] = true; (if rolling through objects)
-          // ^ objectList['restartPolicy'] = true; (ultimate result)
-        }
-      }
-    }
-  }
-  var output = new Array();
-  for(i=0;i<tagName.length;i++)
-  {
-    // Phew! All tags in conceptList, objectList, and commandList!
-    // Loop through them and populate those drop-downs through html() injection
-    output = [];
-    output.push("<select id='" + tagName[i] + "' onchange='dropFilter(this)'>");
-    output.push("<option>---</option>");
-    Object.keys(storedTagsArrays[i]).sort().forEach(function (key) {
-      output.push("<option>" + key + "</option>");
-    });
-    output.push("</select>")
-    $(dropDowns[i]).html(output.join(""));
-  }
-  dropDownsPopulated = true;
-}
-function dropFilter(srcobj)
-{
-  // process the change of a drop-down value
-  // the ID of the drop down is either command, object, or concept
-  // these exact values are what topicsFilter() expects, plus a filter val
-  // which we get from .text() of :selected
-  console.log("dropFilter:" + $(srcobj).attr('id') + ":" + $(srcobj).find(":selected").text());
-  topicsFilter($(srcobj).attr('id').replace("#",""),$(srcobj).find(":selected").text(),"output");
-  for(i=0;i<tagName.length;i++)
-  {
-    if($(srcobj).attr('id')!=tagName[i]) selectDropDown(tagName[i],"---");
-  }
-}
-function selectDropDown(type,tag)
-{
-  // change drop-down selection w/o filtering
-  $("#" + type).val(tag);
-}
-</script>
-<style>
-#filters select{
-  font-size: 14px;
-  border: 1px #000 solid;
-}
-#filters {
-  padding-top: 20px;
-}
-</style>
-
-필터하려면 태그를 클릭하거나 드롭 다운을 사용하세요. 정순 또는 역순으로 정렬하려면 테이블 헤더를 클릭하세요.
-
-<p id="filters">
-개념으로 필터: <span id="conceptFilter" /><br/>
-오브젝트로 필터: <span id="objectFilter" /><br/>
-커맨드로 필터: <span id="commandFilter" />
-</p>
-
-<div id="output" />
diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md
index e6c80f32ed..89b653cb6f 100644
--- a/content/ko/docs/tasks/_index.md
+++ b/content/ko/docs/tasks/_index.md
@@ -12,4 +12,4 @@ content_type: concept
 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다.
 
 만약 태스크 페이지를 작성하고 싶다면,
-[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다.
+[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/open-a-pr/)를 참조한다.
diff --git a/content/ko/docs/tasks/access-application-cluster/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md
index 603b186517..3576ebd0a6 100755
--- a/content/ko/docs/tasks/access-application-cluster/_index.md
+++ b/content/ko/docs/tasks/access-application-cluster/_index.md
@@ -1,5 +1,5 @@
 ---
-title: "클러스터 내 어플리케이션 액세스"
+title: "클러스터 내 어플리케이션 접근"
 description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다.
 weight: 60
 ---
diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md
index c28c51ea16..39226c89be 100644
--- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md
@@ -1,5 +1,5 @@
 ---
-title: 클러스터 액세스
+title: 클러스터 접근
 weight: 20
 content_type: concept
 ---
@@ -8,17 +8,14 @@ content_type: concept
 
 여기에서는 클러스터와 통신을 하는 다양한 방식에 대해서 다룰 것이다.
 
-
-
-
 <!-- body -->
 
-## 처음이라면 kubectl을 사용하여 액세스
+## 처음이라면 kubectl을 사용하여 접근
 
-최초로 쿠버네티스 API에 액세스할 때 우리는
+최초로 쿠버네티스 API에 접근할 때 우리는
 쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다.
 
-클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
+클러스터에 접근하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
 인증정보를 가져야 한다. 일반적으로 이는 당신이
 [Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나,
 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.
@@ -29,14 +26,15 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
 kubectl config view
 ```
 
-많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며
-완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다.
+많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서
+kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는
+[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다.
 
-## REST API에 직접 액세스
+## REST API에 직접 접근
 
 kubectl은 apiserver의 위치 파악과 인증을 처리한다.
 만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
-REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
+REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
 
   - kubectl을 proxy 모드로 실행.
     - 권장하는 접근 방식.
@@ -151,11 +149,11 @@ root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.
 
 localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
 요구하지 않지만 이는 표준이 아니다.
-[Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
-는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
+[API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은
+클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
 이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.
 
-## API에 프로그래밍 방식으로 액세스
+## API에 프로그래밍 방식으로 접근
 
 쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트)
 클라이언트 라이브러리를 지원한다.
@@ -165,16 +163,16 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
 * 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다.
 * client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다.
 
-Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
+Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다.
 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
 
-만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다.
+만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-접근)을 참조하기를 바란다.
 
 ### Python 클라이언트
 
 Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다.
 
-Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
+Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용할 수 있다.
 [예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다.
 
 ### 다른 언어
@@ -182,7 +180,7 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와
 다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/ko/docs/reference/using-api/client-libraries/)도 존재한다.
 이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다.
 
-## 파드에서 API 액세스
+## 파드에서 API 접근
 
 파드에서 API를 접속한다면 apiserver의
 위치지정과 인증은 다소 다르다.
@@ -215,11 +213,13 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
 
 각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.
 
-## 클러스터에서 실행되는 서비스로 액세스
+## 클러스터에서 실행되는 서비스로 접근
 
 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
 쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
-[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은
+[노드들](/ko/docs/concepts/architecture/nodes/),
+[파드들](/ko/docs/concepts/workloads/pods/),
+[서비스들](/ko/docs/concepts/services-networking/service/)은
 모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
 클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
 할 수 없을 것이다.
@@ -228,9 +228,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
 
 클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.
 
-  - 공인 IP를 통해 서비스에 액세스.
+  - 공인 IP를 통해 서비스에 접근.
     - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
-      서비스를 사용한다. [서비스](/docs/user-guide/services)와
+      서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
       [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
     - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
       인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
@@ -238,19 +238,19 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
     - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
       해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다.
     - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
-      액세스할 필요는 없다.
-  - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스.
-    - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
+      접근할 필요는 없다.
+  - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
+    - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
       서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
-      액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다.
+      접근을 하려고 하거나 debugging을 하려면 이를 사용한다.
     - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다.
     - HTTP/HTTPS에서만 동작한다.
     - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
-  - 클러스터 내 노드 또는 파드에서 액세스.
+  - 클러스터 내 노드 또는 파드에서 접근.
     - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
       해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다.
     - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
-      클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
+      클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
       다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
 
 ### 빌트인 서비스들의 발견
@@ -273,10 +273,10 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic
 heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 ```
 
-이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다.
+이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다.
 예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
-`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로
-`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다.
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다.
 (인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
 
 #### 수작업으로 apiserver proxy URL을 구축
@@ -298,8 +298,8 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
 
 ##### 예제들
 
- * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
- * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
+ * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
+ * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
 
 ```json
 {
@@ -316,7 +316,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
 }
 ```
 
-### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 액세스
+### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근
 
 브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만
 
@@ -333,7 +333,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
 
 쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다.
 
-1.  [kubectl proxy](#rest-api에-직접-액세스):
+1.  [kubectl proxy](#rest-api에-직접-접근):
 
     - 사용자의 데스크탑이나 파드 내에서 실행한다
     - localhost 주소에서 쿠버네티스 apiserver로 proxy한다
diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
index 5a585eddd4..40e0a05fcf 100644
--- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
@@ -6,20 +6,15 @@ weight: 110
 
 <!-- overview -->
 
-이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지
-살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자.
-
-
-
+이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에,
+어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에
+[프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를
+통해 통신할 수 있는 방법을 참고하자.
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
-
 <!-- steps -->
 
 ## 두 개의 컨테이너를 실행하는 파드 생성
@@ -103,14 +98,15 @@ nginx 컨테이너의 쉘(shell)을 실행한다.
 Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 디렉터리에 `index.html` 파일을 생성했었음을 상기하자.
 `curl`을 이용하여 nginx 웹 서버에 HTTP GET 요청을 보낸다.
 
-    root@two-containers:/# curl localhost
+```
+root@two-containers:/# curl localhost
+```
 
 출력을 보면, nginx 웹 서버에서 debian 컨테이너에서 쓰여진 웹 페이지를 제공하는 것을 알 수 있다.
 
-    debian 컨테이너에서 안녕하세요
-
-
-
+```
+debian 컨테이너에서 안녕하세요
+```
 
 <!-- discussion -->
 
@@ -127,20 +123,14 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 
 이 예제에서 볼륨은 파드의 생명 주기 동안 컨테이너를 위한 통신 방법으로 이용했다.
 파드가 삭제되고 재생성되면, 공유 볼륨에 저장된 데이터는 잃어버린다.
 
-
-
-
 ## {{% heading "whatsnext" %}}
 
 
-* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여
-더 공부한다.
+* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다.
 
-* [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
-더 공부한다.
+* [모듈 구조를 위한 합성 컨테이너 구조](https://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다.
 
-* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여
-확인한다.
+* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 확인한다.
 
 * [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다.
 
diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index 9f99c6acbd..7312feec01 100644
--- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -30,7 +30,7 @@ card:
 
 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
 `kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
-[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
+[마이너 버전 하나 차이 이내](/docs/setup/release/version-skew-policy/#kubectl)여야
 한다.
 
 
diff --git a/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md
new file mode 100644
index 0000000000..e79d655d01
--- /dev/null
+++ b/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -0,0 +1,212 @@
+---
+title: 서비스를 사용하여 프론트엔드를 백엔드에 연결
+content_type: tutorial
+weight: 70
+---
+
+<!-- overview -->
+
+이 작업은 프론트엔드와 마이크로서비스 백엔드를 어떻게 생성하는지를
+설명한다. 백엔드 마이크로서비스는 인사하기(hello greeter)이다.
+프론트엔드와 백엔드는 쿠버네티스 {{< glossary_tooltip term_id="service" text="서비스" >}}
+오브젝트를 이용해 연결되어 있다.
+
+## {{% heading "objectives" %}}
+
+* {{< glossary_tooltip term_id="deployment" text="디플로이먼트(Deployment)" >}} 오브젝트를 사용해 마이크로서비스를 생성하고 실행한다.
+* 프론트엔드를 사용하여 백엔드로 트래픽을 전달한다.
+* 프론트엔드 애플리케이션을 백엔드 애플리케이션에 연결하기 위해
+  서비스 오브젝트를 사용한다.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+이 작업은
+지원되는 환경이 필요한
+[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#nodeport) 서비스 타입을
+대신 사용할 수 있다.
+
+<!-- lessoncontent -->
+
+## 디플로이먼트를 사용해 백엔드 생성하기
+
+백엔드는 인사하기라는 간단한 마이크로서비스이다. 여기에 백엔드 디플로이먼트
+구성 파일이 있다.
+
+{{< codenew file="service/access/hello.yaml" >}}
+
+백엔드 디플로이먼트를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
+```
+
+백엔드 디플로이먼트에 관한 정보를 본다.
+
+```shell
+kubectl describe deployment hello
+```
+
+결과는 아래와 같다.
+
+```
+Name:                           hello
+Namespace:                      default
+CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
+Labels:                         app=hello
+                                tier=backend
+                                track=stable
+Annotations:                    deployment.kubernetes.io/revision=1
+Selector:                       app=hello,tier=backend,track=stable
+Replicas:                       7 desired | 7 updated | 7 total | 7 available | 0 unavailable
+StrategyType:                   RollingUpdate
+MinReadySeconds:                0
+RollingUpdateStrategy:          1 max unavailable, 1 max surge
+Pod Template:
+  Labels:       app=hello
+                tier=backend
+                track=stable
+  Containers:
+   hello:
+    Image:              "gcr.io/google-samples/hello-go-gke:1.0"
+    Port:               80/TCP
+    Environment:        <none>
+    Mounts:             <none>
+  Volumes:              <none>
+Conditions:
+  Type          Status  Reason
+  ----          ------  ------
+  Available     True    MinimumReplicasAvailable
+  Progressing   True    NewReplicaSetAvailable
+OldReplicaSets:                 <none>
+NewReplicaSet:                  hello-3621623197 (7/7 replicas created)
+Events:
+...
+```
+
+## 백엔드 서비스 오브젝트 생성하기
+
+프론트엔드와 백엔드를 연결하는 방법은 백엔드
+서비스이다. 서비스는 백엔드 마이크로서비스에 언제든 도달하기 위해
+변하지 않는 IP 주소와 DNS 이름 항목을 생성한다. 서비스는
+트래픽을 보내는 파드를 찾기 위해
+{{< glossary_tooltip text="selectors" term_id="selector" text="셀렉터" >}}를 사용한다.
+
+먼저, 서비스 구성 파일을 살펴보자.
+
+{{< codenew file="service/access/hello-service.yaml" >}}
+
+구성 파일에서 서비스가 `app: hello` 과 `tier: backend` 레이블을 갖는
+파드에 트래픽을 보내는 것을 볼 수 있다.
+
+`hello` 서비스를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
+```
+
+이 시점에서, 백엔드 디플로이먼트는 Running 중이며, 해당 백엔드로
+트래픽을 보내는 서비스를 갖고 있다.
+
+## 프론트엔드 생성하기
+
+이제 백엔드가 있기 때문에 백엔드와 연결하는 프론트엔드를 생성할 수 있다.
+프론트엔드는 백엔드 서비스에서 제공된 DNS 이름을 사용해 백엔드 워커
+파드에 연결할 수 있다. DNS 이름은 "hello" 이고, 앞선
+서비스 구성 파일의 `name` 항목의 값이다.
+
+프론트엔드 디플로이먼트 안에 파드는 hello 백엔드 서비스를 찾도록
+구성된 nginx 이미지를 실행한다. 여기에 nginx 구성 파일이 있다.
+
+{{< codenew file="service/access/frontend.conf" >}}
+
+백엔드와 같이, 프론트엔드는 디플로이먼트와 서비스를 갖고 있다.
+서비스의 구성은 `type: LoadBalancer` 이며, 이는 서비스가
+클라우드 공급자의 기본 로드 밸런서를 사용하는 것을 의미한다.
+
+{{< codenew file="service/access/frontend.yaml" >}}
+
+프론트엔드 디플로이먼트와 서비스를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
+```
+
+결과는 두 리소스가 생성되었음을 확인한다.
+
+```
+deployment.apps/frontend created
+service/frontend created
+```
+
+{{< note >}}
+nginx 구성은 [컨테이너 이미지](/examples/service/access/Dockerfile)에
+반영 되었다. 이를 실행하는 더 좋은 방법은
+구성을
+보다 쉽게 변경할
+수 있는 [컨피그맵(ConfigMap)](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하는 것이다.
+{{< /note >}}
+
+## 프론트엔드 서비스와 통신하기
+
+일단 로드밸런서 타입의 서비스를 생성하면, 이 명령어를
+사용해 외부 IP를 찾을 수 있다.
+
+```shell
+kubectl get service frontend --watch
+```
+
+`frontend` 서비스의 구성을 보여주고, 변경 사항을
+주시한다. 처음에, 외부 IP는 `<pending>` 으로 나열된다.
+
+```
+NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)  AGE
+frontend   LoadBalancer   10.51.252.116   <pending>     80/TCP   10s
+```
+
+하지만, 외부 IP가 생성되자마자 구성은
+`EXTERNAL-IP` 제목 아래에 새로운 IP를 포함하여 갱신한다.
+
+```
+NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)  AGE
+frontend   LoadBalancer   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m
+```
+
+이제 해당 IP는 클러스터 외부에서 `frontend` 서비스와 통신하는데
+사용된다.
+
+## 프론트엔드 통해서 트래픽 보내기
+
+이제 프론트엔드와 백엔드가 연결되었다. 프론트엔드 서비스의 외부 IP에서
+curl 명령을 사용해 엔드포인트에 도달할 수 있다.
+
+```shell
+curl http://${EXTERNAL_IP} # 앞의 예에서 본 EXTERNAL-IP로 수정한다
+```
+
+결과로 백엔드에서 생성된 메시지가 보인다.
+
+```json
+{"message":"Hello"}
+```
+
+## {{% heading "cleanup" %}}
+
+서비스를 삭제하기 위해, 아래 명령어를 입력하자.
+
+```shell
+kubectl delete services frontend hello
+```
+
+백엔드와 프론트엔드 애플리케이션에서 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하기 위해, 아래 명령어를 입력하자.
+
+```shell
+kubectl delete deployment frontend hello
+```
+
+## {{% heading "whatsnext" %}}
+
+* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 알아본다.
+* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)에 대해 더 알아본다.
+
diff --git a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index 5a91ebd66e..0856cc355d 100644
--- a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -7,7 +7,7 @@ min-kubernetes-server-version: v1.10
 
 <!-- overview -->
 
-이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서 
+이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서
 실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
 디버깅에 유용할 수 있다.
 
@@ -29,7 +29,7 @@ min-kubernetes-server-version: v1.10
 ## Redis 디플로이먼트와 서비스 생성하기
 
 1. Redis를 실행하기 위해 디플로이먼트를 생성한다.
-    
+
     ```shell
     kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
     ```
@@ -151,7 +151,7 @@ min-kubernetes-server-version: v1.10
     또는 다음과 같다.
 
     ```shell
-    kubectl port-forward svc/redis-master 7000:6379
+    kubectl port-forward service/redis-master 7000:redis
     ```
 
     위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
@@ -203,7 +203,3 @@ UDP 프로토콜에 대한 지원은
 ## {{% heading "whatsnext" %}}
 
 [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)에 대해 더 알아본다.
-
-
-
-
diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 3aa05a92b0..d0cfee3009 100644
--- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -5,20 +5,24 @@ weight: 10
 card:
   name: tasks
   weight: 30
-  title: Use the Web UI Dashboard
+  title: 웹 UI 대시보드 사용
 ---
 
 <!-- overview -->
 
-대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
+대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다.
+대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고,
+컨테이너화 된 애플리케이션을 트러블슈팅할 수 있으며, 클러스터 리소스들을 관리할 수 있다.
+대시보드를 통해 클러스터에서 동작 중인 애플리케이션의 정보를 볼 수 있고,
+개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등)
+생성하거나 수정할 수 있다.
+예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나
+또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
 
 또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
 
 ![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png)
 
-
-
-
 <!-- body -->
 
 ## 대시보드 UI 배포
@@ -32,7 +36,10 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
 ## 대시보드 UI 접근
 
 
-클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
+클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다.
+현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다.
+본 시연을 위한 토큰을 생성하기 위해서는,
+[샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
 
 {{< warning >}}
 시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
@@ -45,7 +52,7 @@ kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로
 kubectl proxy
 ```
 
-kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
+kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
 
 UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
 
@@ -55,13 +62,17 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 
 
 ## 웰컴 뷰
 
-초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
+초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다.
+이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다.
+게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system`
+[네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
 
 ![Kubernetes Dashboard welcome page](/images/docs/ui-dashboard-zerostate.png)
 
 ## 컨테이너화 된 애플리케이션 배포
 
-대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
+대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다.
+애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다.
 
 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
 
@@ -69,17 +80,29 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 
 
 배포 마법사는 다음 정보를 제공한다.
 
-- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
+- **앱 이름** (필수): 애플리케이션 이름.
+  [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은
+  배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
 
-  애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
+  애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다.
+  소문자로 시작해야 하며, 소문자 또는 숫자로 끝나고,
+  소문자, 숫자 및 대쉬(-)만을 포함해야 한다. 24 문자만을 제한한다.
+  처음과 끝의 스페이스는 무시된다.
 
-- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
+- **컨테이너 이미지** (필수):
+  레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/)
+  또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL.
+  컨테이너 이미지 사양은 콜론으로 끝난다.
 
-- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다.
+- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수.
+  값은 양의 정수만 허용됩니다.
 
-  클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
+  클러스터에 의도한 파드의 수를 유지하기 위해서
+  [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
 
-- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다.
+- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의
+  퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를
+  노출시키고 싶을 수 있다.
 
   {{< note >}}
   외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
@@ -87,13 +110,22 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 
 
   클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
 
-  서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
+  서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면,
+  두 개의 포트를 정의해야 한다.
+  서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다.
+  서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다.
+  서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
 
 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
 
-- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
+- **설명**: 입력하는 텍스트값은 디플로이먼트에
+  [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로
+  추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
 
-- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
+- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은
+  애플리케이션 이름과 버전이다.
+  릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를
+  생성할 때 추가적으로 정의할 수 있다.
 
   예를 들면:
 
@@ -104,66 +136,111 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 
   track=stable
   ```
 
-- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.
+- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다.
+  이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다.
+  논리적으로 명명된 그룹으로 리소스들을 분할할 수 있다.
 
-  대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
-  네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
+  대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다.
+  네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
+  네임스페이스 이름은 숫자로만 구성할 수 없다.
+  만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
 
-  네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
+  네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다.
+  만약 생성에 실패하면, 첫 번째 네임스페이스가 선택된다.
 
-- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
+- **이미지 풀(Pull) 시크릿**:
+  특정 도커 컨테이너 이미지가 프라이빗한 경우,
+  [풀(Pull) 시크릿](/ko/docs/concepts/configuration/secret/) 자격 증명을 요구한다.
 
-  대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
+  대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다.
+  시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다.
+  시크릿 내용은 base64 인코딩 방식이며,
+  [`.dockercfg`](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시) 파일로 정의된다.
+  시크릿 이름은 최대 253 문자를 포함할 수 있다.
 
   이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
 
-- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
+- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**:
+  컨테이너를 위한 최소 [리소스 상한](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을
+  정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
 
-- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
+- **커맨드 실행** 와 **커맨드 인수 실행**:
+  기본적으로, 컨테이너는 선택된 도커 이미지의
+  [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다.
+  커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
 
-- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
+- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이
+  [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/#컨테이너에-대한-특권-모드)의
+  프로세스들과 동등한지 아닌지 정의한다.
+  특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
 
-- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
+- **환경 변수**: 쿠버네티스 서비스를
+  [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
+  환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
+  애플리케이션들이 서비스를 찾는데 사용된다.
+  값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
 
 ### YAML 또는 JSON 파일 업로드
 
-쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
+쿠버네티스는 선언적인 설정을 제공한다.
+이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를
+이용하여 YAML 또는 JSON 설정 파일에 저장한다.
 
-배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
+배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신,
+애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
 
 ## 대시보드 사용
 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
 
 ### 탐색
 
-클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
+클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다.
+기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데,
+이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
 
 대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
 
 #### 어드민 개요
-클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
+클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다.
+노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다.
+세부사항은 각 노드들에 대한 사용량, 사양, 상태,
+할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
 
 #### 워크로드
-선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
 
-워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
+선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
+애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고
+각각의 워크로드 종류는 따로 보여진다.
+리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
+워크로드에 대한 실용적인 정보를 요약한다.
+
+워크로드에 대한 세부적인 것들은 상태와 사양 정보,
+오프젝트들 간의 관계를 보여준다.
+예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
 
 #### 서비스
-외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
+
+외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는
+쿠버네티스 리소스들을 보여준다.
+이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과
+외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
 
 #### 스토리지
+
 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
 
 #### 컨피그 맵과 시크릿
-클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
+
+클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다.
+컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
 
 #### 로그 뷰어
-파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
+
+파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다.
+뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
 
 ![Logs viewer](/images/docs/ui-dashboard-logs-view.png)
 
-
-
 ## {{% heading "whatsnext" %}}
 
 
diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md
index 1b92c1283a..ba4a794d23 100644
--- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md
@@ -6,13 +6,10 @@ content_type: task
 <!-- overview -->
 이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다.
 
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
 <!-- steps -->
 
 ## 쿠버네티스 API에 접근
@@ -151,7 +148,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
 
 일부 클러스터에서, API 서버는 인증이 필요하지 않다.
 로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
-없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은
+없다. [API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은
 클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
 고 가용성 지원과 충돌할 수 있다.
 
@@ -170,11 +167,14 @@ client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기
 
 {{< /note >}}
 
-Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
 사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
 
 ```golang
+package main
+
 import (
+  "context"
   "fmt"
   "k8s.io/apimachinery/pkg/apis/meta/v1"
   "k8s.io/client-go/kubernetes"
@@ -188,7 +188,7 @@ func main() {
   // clientset을 생성한다
   clientset, _ := kubernetes.NewForConfig(config)
   // 파드를 나열하기 위해 API에 접근한다
-  pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
+  pods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{})
   fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
 }
 ```
@@ -199,7 +199,7 @@ func main() {
 
 [Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다.
 
-Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다.
 
 ```python
@@ -229,7 +229,7 @@ mvn install
 
 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다.
 
-Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다.
 
 ```java
@@ -283,7 +283,7 @@ public class KubeConfigFileClientExample {
 
 [dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다.
 
-dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다.
 
 ```csharp
@@ -318,7 +318,7 @@ namespace simple
 
 [JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다.
 
-JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을
 사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다.
 
 ```javascript
@@ -387,7 +387,7 @@ exampleWithKubeConfig = do
 호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
 이를 자동으로 수행한다.
 
-API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts)
+API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
 자격 증명을 사용하는 것이다. 기본적으로, 파드는
 서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
 해당 파드에 있는 각 컨테이너의 파일시스템 트리의
diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md
index 0b1cf9540f..f8f707eb33 100644
--- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md
+++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md
@@ -17,7 +17,8 @@ content_type: task
 
 ## 클러스터에서 실행되는 서비스에 접근
 
-쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
+쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
+[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
 고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
 없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
 도달할 수 없다.
diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md
index 440ece1531..b57e07db65 100644
--- a/content/ko/docs/tasks/administer-cluster/cluster-management.md
+++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md
@@ -10,9 +10,6 @@ content_type: concept
 노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
 쿠버네티스 API 버전 업그레이드.
 
-
-
-
 <!-- body -->
 
 ## 클러스터 생성과 설정
@@ -77,24 +74,33 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레
 * [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
 * ...
 
-위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) 페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다.
+위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
+페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다.
 
 ## 클러스터 크기 재조정
 
-[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
-[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
+[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인
+클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다.
+GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
+[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면
+`Compute > Compute Engine > Instance groups > your group > Edit group`에서
+인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
 
 ```shell
 gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
 ```
 
-인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에 Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다. 사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다.
+인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에
+Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다.
+사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다.
 
 다른 환경에서는 사용자가 직접 머신을 구성하고 어떤 머신에서 API 서버가 동작하는지를 Kubelet에 알려줘야 할 수도 있다.
 
 ### Azure Kubernetes Service (AKS) 클러스터 크기 재조정
 
-Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서 이를 설명하고 있다.
+Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며
+[Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서
+이를 설명하고 있다.
 
 
 ### 클러스터 오토스케일링
@@ -102,7 +108,8 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터
 GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
 재조정하도록 클러스터를 구성할 수 있다.
 
-[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. 
+[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼
+사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
 이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
 여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
 다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
@@ -181,22 +188,11 @@ kubectl uncordon $NODENAME
 
 해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
 자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
-이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
+이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.)
+상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
 
 ## 고급 주제들
 
-### 다른 API 버전으로 업그레이드
-
-신규 API 버전이 릴리스 되었을 때, 해당 신규 API 버전을 지원하려면 클러스터를 업그레이드해야 할 수 있다.(예. 'v2'가 출시되었을 때 'v1'에서 'v2'로 변경)
-
-이는 드문 경우지만 세심한 관리가 요구된다. 신규 API 버전으로 업그레이드하는데는 일련의 과정이 존재한다.
-
-   1. 신규 API 버전을 ON한다.
-   1. 신규 버전을 사용하도록 클러스터의 스토리지를 업그레이드한다.
-   1. 모든 구성 파일들을 업그레이드한다. 구식 API 버전 엔드포인트의 사용자들을 식별한다.
-   1. `cluster/update-storage-objects.sh`을 실행하여 스토리지 내에 기존 객체들을 신규 버전으로 업데이트한다.
-   1. 구식 API 버전을 OFF한다.
-
 ### 클러스터에서 API 버전을 ON/OFF 하기
 
 특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
diff --git a/content/ko/docs/tasks/administer-cluster/declare-network-policy.md b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md
index 58865f9443..7a7a97576d 100644
--- a/content/ko/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md
@@ -6,6 +6,7 @@ content_type: task
 <!-- overview -->
 이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다.
 
+{{% thirdparty-content %}}
 
 ## {{% heading "prerequisites" %}}
 
@@ -20,11 +21,6 @@ content_type: task
 * [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
 * [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
 
-{{< note >}}
-위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다.
-{{< /note >}}
-
-
 <!-- steps -->
 
 ## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기
@@ -63,7 +59,7 @@ NAME                        READY         STATUS        RESTARTS   AGE
 pod/nginx-701339712-e0qfq   1/1           Running       0          35s
 ```
 
-## 다른 파드에서 접근하여 서비스 테스트하기 
+## 다른 파드에서 접근하여 서비스 테스트하기
 
 사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
 
@@ -84,11 +80,11 @@ remote file exists
 
 ## `nginx` 서비스에 대해 접근 제한하기
 
-`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다. 
+`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.
 
 {{< codenew file="service/networking/nginx-policy.yaml" >}}
 
-네트워크폴리시 오브젝트의 이름은 유효한 
+네트워크폴리시 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
 
 {{< note >}}
diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
index 0e5a87bc82..ad76009844 100644
--- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -5,16 +5,16 @@ min-kubernetes-server-version: v1.12
 ---
 
 <!-- overview -->
-이 페이지는 클러스터 안에서 사용자의 
-DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고 
+이 페이지는 클러스터 안에서 사용자의
+DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고
 DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다.
 
 ## {{% heading "prerequisites" %}}
 
 {{< include "task-tutorial-prereqs.md" >}}
 
-클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. 
-[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기) 
+클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
+[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
 는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.  
 
 {{% version-check %}}
@@ -23,11 +23,11 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
 
 ## 소개
 
-DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 
-사용하여 자동으로 시작되는 쿠버네티스 
+DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
+사용하여 자동으로 시작되는 쿠버네티스
 내장 서비스이다.
 
-쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, 
+쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
 CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
 
 {{< note >}}
@@ -35,19 +35,19 @@ CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 
 이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
 {{< /note >}}
 
-CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. 
+CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
 Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
 
-DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를 
+DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
 통하여 로컬 도메인을 설정할 수 있다.
 
 DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
 더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
 
-만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, 
+만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
 파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
 파드의 DNS 변환도 노드와 동일하게 작동해야 한다.
-그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다.
+그 외에는 [알려진 이슈](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues)를 참고한다.
 
 만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우,
 사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다.
@@ -63,7 +63,7 @@ CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/speci
 CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
 이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다.
 클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
-해당 클러스터에 대한 DNS 서비스 검색 동작을 
+해당 클러스터에 대한 DNS 서비스 검색 동작을
 변경할 수 있다.
 
 쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다.
@@ -164,7 +164,7 @@ data:
     }
 ```
 
-`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 
+`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
 자동 변환을 지원한다.
 
 {{< note >}}
@@ -248,11 +248,11 @@ my.cluster.local:53 {
 
 ## CoreDNS로의 이관
 
-kube-dns에서 CoreDNS로 이관하기 위하여, 
+kube-dns에서 CoreDNS로 이관하기 위하여,
 kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는
 [블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
 
-또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 
+또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
 사용하여 이관할 수도 있다.
 
 
diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
index 9e48ea900a..e18c3e0808 100644
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@@ -2,17 +2,18 @@
 title: kubeadm 클러스터 업그레이드
 content_type: task
 weight: 20
-min-kubernetes-server-version: 1.18
+min-kubernetes-server-version: 1.19
 ---
 
 <!-- overview -->
 
 이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
-1.17.x 버전에서 1.18.x 버전으로, 1.18.x 버전에서 1.18.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
+1.18.x 버전에서 1.19.x 버전으로, 1.19.x 버전에서 1.19.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
 
 이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
 이 페이지 대신 다음의 페이지들을 참고한다.
 
+- [kubeadm 클러스터를 1.17에서 1.18로 업그레이드](https://v1-18.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
@@ -24,12 +25,9 @@ min-kubernetes-server-version: 1.18
 1. 추가 컨트롤 플레인 노드를 업그레이드한다.
 1. 워커(worker) 노드를 업그레이드한다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
-- 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
+- 1.18.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
 - [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
 - 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
 - [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다.
@@ -43,25 +41,23 @@ min-kubernetes-server-version: 1.18
   또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다.
   예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다.
 
-
-
 <!-- steps -->
 
 ## 업그레이드할 버전 결정
 
-최신의 안정 버전인 1.18을 찾는다.
+최신의 안정 버전인 1.19를 찾는다.
 
 {{< tabs name="k8s_install_versions" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
     apt update
     apt-cache madison kubeadm
-    # 목록에서 최신 버전 1.18을 찾는다
-    # 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
+    # 목록에서 최신 버전 1.19를 찾는다
+    # 1.19.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
     yum list --showduplicates kubeadm --disableexcludes=kubernetes
-    # 목록에서 최신 버전 1.18을 찾는다
-    # 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
+    # 목록에서 최신 버전 1.19를 찾는다
+    # 1.19.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -73,18 +69,18 @@ min-kubernetes-server-version: 1.18
 
 {{< tabs name="k8s_install_kubeadm_first_cp" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다.
+    # 1.19.x-00에서 x를 최신 패치 버전으로 바꾼다.
     apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
+    apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
     apt-mark hold kubeadm
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
+    apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다.
-    yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다.
+    yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -116,45 +112,63 @@ min-kubernetes-server-version: 1.18
     [preflight] Running pre-flight checks.
     [upgrade] Running cluster health checks
     [upgrade] Fetching available versions to upgrade to
-    [upgrade/versions] Cluster version: v1.17.3
-    [upgrade/versions] kubeadm version: v1.18.0
-    [upgrade/versions] Latest stable version: v1.18.0
-    [upgrade/versions] Latest version in the v1.17 series: v1.18.0
+    [upgrade/versions] Cluster version: v1.18.4
+    [upgrade/versions] kubeadm version: v1.19.0
+    [upgrade/versions] Latest stable version: v1.19.0
+    [upgrade/versions] Latest version in the v1.18 series: v1.19.0
 
     Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
     COMPONENT   CURRENT             AVAILABLE
-    Kubelet     1 x v1.17.3   v1.18.0
+    Kubelet     1 x v1.18.4         v1.19.0
 
-    Upgrade to the latest version in the v1.17 series:
+    Upgrade to the latest version in the v1.18 series:
 
     COMPONENT            CURRENT   AVAILABLE
-    API Server           v1.17.3   v1.18.0
-    Controller Manager   v1.17.3   v1.18.0
-    Scheduler            v1.17.3   v1.18.0
-    Kube Proxy           v1.17.3   v1.18.0
-    CoreDNS              1.6.5     1.6.7
-    Etcd                 3.4.3     3.4.3-0
+    API Server           v1.18.4   v1.19.0
+    Controller Manager   v1.18.4   v1.19.0
+    Scheduler            v1.18.4   v1.19.0
+    Kube Proxy           v1.18.4   v1.19.0
+    CoreDNS              1.6.7     1.7.0
+    Etcd                 3.4.3-0   3.4.7-0
 
     You can now apply the upgrade by executing the following command:
 
-        kubeadm upgrade apply v1.18.0
+        kubeadm upgrade apply v1.19.0
 
     _____________________________________________________________________
+
+    아래 표는 이 버전의 kubeadm에서 이해하는 컴포넌트 구성의 현재 상태를 보여준다.
+    "MANUAL UPGRADE REQUIRED" 열에 "yes" 표시가 있는 구성은 성공적인 업그레이드를
+    수행하기 전에 수동 구성 업그레이드 또는 kubeadm 기본값으로 재설정이 필요하다. 수동으로
+    업그레이드할 버전은 "PREFERRED VERSION" 열에 표시된다.
+
+    API GROUP                 CURRENT VERSION   PREFERRED VERSION   MANUAL UPGRADE REQUIRED
+    kubeproxy.config.k8s.io   v1alpha1          v1alpha1            no
+    kubelet.config.k8s.io     v1beta1           v1beta1             no
+    _____________________________________________________________________
+
     ```
 
     이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다.
+    또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다.
 
 {{< note >}}
 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다.
 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다.
-자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
+자세한 내용은 [인증서 관리 가이드](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
+{{</ note >}}
+
+{{< note >}}
+`kubeadm upgrade plan` 이 수동 업그레이드가 필요한 컴포넌트 구성을 표시하는 경우, 사용자는
+`--config` 커맨드 라인 플래그를 통해 대체 구성이 포함된 구성 파일을 `kubeadm upgrade apply` 에 제공해야 한다.
+그렇게 하지 않으면 `kubeadm upgrade apply` 가 오류와 함께 종료되고 업그레이드를 수행하지 않는다.
 {{</ note >}}
 
 -  업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다.
 
     ```shell
     # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
-    sudo kubeadm upgrade apply v1.18.x
+    sudo kubeadm upgrade apply v1.19.x
     ```
 
 
@@ -166,75 +180,78 @@ min-kubernetes-server-version: 1.18
     [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
     [preflight] Running pre-flight checks.
     [upgrade] Running cluster health checks
-    [upgrade/version] You have chosen to change the cluster version to "v1.18.0"
-    [upgrade/versions] Cluster version: v1.17.3
-    [upgrade/versions] kubeadm version: v1.18.0
+    [upgrade/version] You have chosen to change the cluster version to "v1.19.0"
+    [upgrade/versions] Cluster version: v1.18.4
+    [upgrade/versions] kubeadm version: v1.19.0
     [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
-    [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
-    [upgrade/prepull] Prepulling image for component etcd.
-    [upgrade/prepull] Prepulling image for component kube-apiserver.
-    [upgrade/prepull] Prepulling image for component kube-controller-manager.
-    [upgrade/prepull] Prepulling image for component kube-scheduler.
-    [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
-    [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
-    [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
-    [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
-    [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
-    [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
-    [upgrade/prepull] Prepulled image for component etcd.
-    [upgrade/prepull] Prepulled image for component kube-apiserver.
-    [upgrade/prepull] Prepulled image for component kube-controller-manager.
-    [upgrade/prepull] Prepulled image for component kube-scheduler.
-    [upgrade/prepull] Successfully prepulled the images for all the control plane components
-    [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"...
-    Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
-    Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
-    Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
+    [upgrade/prepull] Pulling images required for setting up a Kubernetes cluster
+    [upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection
+    [upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull'
+    [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.19.0"...
+    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+    Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
+    Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
     [upgrade/etcd] Upgrading to TLS for etcd
-    [upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
-    [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012"
-    W0308 18:48:14.535122    3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
+    Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
+    [upgrade/staticpods] Preparing for "etcd" upgrade
+    [upgrade/staticpods] Renewing etcd-server certificate
+    [upgrade/staticpods] Renewing etcd-peer certificate
+    [upgrade/staticpods] Renewing etcd-healthcheck-client certificate
+    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/etcd.yaml"
+    [upgrade/staticpods] Waiting for the kubelet to restart the component
+    [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
+    Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
+    Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
+    Static pod: etcd-kind-control-plane hash: 59e40b2aab1cd7055e64450b5ee438f0
+    [apiclient] Found 1 Pods for label selector component=etcd
+    [upgrade/staticpods] Component "etcd" upgraded successfully!
+    [upgrade/etcd] Waiting for etcd to become available
+    [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests999800980"
     [upgrade/staticpods] Preparing for "kube-apiserver" upgrade
     [upgrade/staticpods] Renewing apiserver certificate
     [upgrade/staticpods] Renewing apiserver-kubelet-client certificate
     [upgrade/staticpods] Renewing front-proxy-client certificate
     [upgrade/staticpods] Renewing apiserver-etcd-client certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml"
+    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-apiserver.yaml"
     [upgrade/staticpods] Waiting for the kubelet to restart the component
     [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
-    Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4
+    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+    Static pod: kube-apiserver-kind-control-plane hash: f717874150ba572f020dcd89db8480fc
     [apiclient] Found 1 Pods for label selector component=kube-apiserver
     [upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
     [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
     [upgrade/staticpods] Renewing controller-manager.conf certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml"
+    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-controller-manager.yaml"
     [upgrade/staticpods] Waiting for the kubelet to restart the component
     [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
-    Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156
+    Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
+    Static pod: kube-controller-manager-kind-control-plane hash: b155b63c70e798b806e64a866e297dd0
     [apiclient] Found 1 Pods for label selector component=kube-controller-manager
     [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
     [upgrade/staticpods] Preparing for "kube-scheduler" upgrade
     [upgrade/staticpods] Renewing scheduler.conf certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml"
+    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-scheduler.yaml"
     [upgrade/staticpods] Waiting for the kubelet to restart the component
     [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
-    Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d
+    Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
+    Static pod: kube-scheduler-kind-control-plane hash: 260018ac854dbf1c9fe82493e88aec31
     [apiclient] Found 1 Pods for label selector component=kube-scheduler
     [upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
     [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
-    [kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
-    [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
+    [kubelet] Creating a ConfigMap "kubelet-config-1.19" in namespace kube-system with the configuration for the kubelets in the cluster
     [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
+    [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
     [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
     [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
     [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
+    W0713 16:26:14.074656    2986 dns.go:282] the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. The existing CoreDNS Corefile configuration and deployment has been retained.
     [addons] Applied essential addon: CoreDNS
     [addons] Applied essential addon: kube-proxy
 
-    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy!
+    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.19.0". Enjoy!
 
     [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
     ```
@@ -276,18 +293,18 @@ sudo kubeadm upgrade apply
 
 {{< tabs name="k8s_install_kubelet" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
+    # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
+    apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+    apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
+    yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -309,18 +326,18 @@ sudo systemctl restart kubelet
 
 {{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
+    # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
+    apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
     apt-mark hold kubeadm
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
+    apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
+    yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -355,18 +372,18 @@ sudo systemctl restart kubelet
 
 {{< tabs name="k8s_kubelet_and_kubectl" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
+    # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
+    apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+    apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
+    yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -429,6 +446,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면, 
   - 컨트롤 플레인이 정상적으로 동작한다
 - 버전 차이(skew) 정책을 적용한다.
 - 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다.
+- 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다.
 - 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다.
 - 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
 - API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다.
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index f41b5cd716..eb953143be 100644
--- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -63,13 +63,13 @@ deployment.apps/cilium-operator created
 ```
 
 시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
-L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예, HTTP)의 보안 정책을
+L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, HTTP)의 보안 정책을
 적용하는 방법을 설명한다.
 
 ## 실리움을 실 서비스 용도로 배포하기
 
 실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
-[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/kubernetes/intro/)를 살펴본다.
+[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)를 살펴본다.
 이 문서는 자세한 요구사항, 방법과
 실제 데몬셋 예시를 포함한다.
 
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
index d59cdd3e15..1b0873f74a 100644
--- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -10,14 +10,9 @@ weight: 40
 
 이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
-[kubeadm 시작하기](/docs/getting-started-guides/kubeadm/)의 1, 2, 3 단계를 완료하자.
-
-
+[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)의 1, 2, 3 단계를 완료하자.
 
 <!-- steps -->
 
@@ -33,9 +28,8 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman
     * [Romana 네트워크 폴리시의 예](https://github.com/romana/core/blob/master/doc/policy.md).
 * 네트워크 폴리시 API.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
-로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해
+[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를
+따라 할 수 있다.
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
index 3aea719c56..736572c808 100644
--- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -8,22 +8,21 @@ weight: 50
 
 이 페이지는 네트워크 폴리시(NetworkPolicy)로 위브넷(Weave Net)를 사용하는 방법을 살펴본다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
-쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 [kubeadm 시작하기 안내서](/docs/getting-started-guides/kubeadm/)를 따른다.
-
-
+쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서
+[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)를 따른다.
 
 <!-- steps -->
 
 ## Weave Net 애드온을 설치한다
 
-[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다.
+[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) 가이드를 따른다.
 
-쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 네크워크 정책 어노테이션을 자동으로 모니터링하며, 정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 [네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
+쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의
+네크워크 정책 어노테이션을 자동으로 모니터링하며,
+정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는
+[네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)와 함께 제공된다.
 
 ## 설치 시험
 
@@ -47,9 +46,9 @@ weave-net-pmw8w                         2/2       Running   0          9d
 
 위브넷 파드를 가진 각 노드와 모든 파드는 `Running`이고 `2/2 READY`이다(`2/2`는 각 파드가 `weave`와 `weave-npc`를 가지고 있음을 뜻한다).
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
-위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
+위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해
+[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를
+따라 할 수 있다. 질문이 있으면
+[슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
new file mode 100644
index 0000000000..4c1679b8a3
--- /dev/null
+++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
@@ -0,0 +1,287 @@
+---
+title: 스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정하기
+content_type: task
+weight: 60
+---
+
+<!-- overview -->
+
+이 페이지는 스토리지에 대해
+{{< glossary_tooltip text="퍼시스턴트볼륨클레임(PersistentVolumeClaim)" term_id="persistent-volume-claim" >}}을
+사용하도록 파드를 설정하는 방법을 보여준다.
+과정의 요약은 다음과 같다.
+
+1. 클러스터 관리자로서, 물리적 스토리지와 연결되는 퍼시스턴트볼륨을 
+생성한다. 볼륨을 특정 파드와 연결하지 않는다.
+
+1. 그 다음 개발자 / 클러스터 사용자의 역할로서, 적합한 
+퍼시스턴트볼륨에 자동으로 바인딩되는 퍼시스턴트볼륨클레임을 
+생성한다.
+
+1. 스토리지에 대해 위의 퍼시스턴트볼륨클레임을 사용하는 파드를 생성한다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+* 사용자는 노드가 단 하나만 있는 쿠버네티스 클러스터가 필요하고,
+{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
+커맨드라인 툴이 사용자의 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약 사용자가 
+아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/setup/learning-environment/minikube/)를 
+사용하여 클러스터 하나를 생성할 수 있다.
+
+* [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)의 
+관련 자료에 익숙해지도록 한다.
+
+<!-- steps -->
+
+## 사용자 노드에 index.html 파일 생성하기
+
+사용자 클러스터의 단일 노드에 연결되는 셸을 연다. 셸을 여는 방법은 
+클러스터 설정에 따라 달라진다. 예를 들어 Minikube를 사용하는 경우, 
+`minikube ssh` 명령어를 입력하여 노드로 연결되는 셸을 열 수 있다. 
+
+해당 노드의 셸에서 `/mnt/data` 디렉터리를 생성한다.
+
+```shell
+# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
+# "sudo"를 사용한다고 가정한다
+sudo mkdir /mnt/data
+```
+
+
+`/mnt/data` 디렉터리에서 `index.html` 파일을 생성한다.
+
+```shell
+# 이번에도 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
+# "sudo"를 사용한다고 가정한다
+sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
+```
+
+{{< note >}}
+사용자 노드에서 `sudo` 이외의 슈퍼유저 접근 툴을 사용하는 경우,
+`sudo` 를 해당 툴의 이름으로 바꾸면, 동일하게 작업을 수행할 수 있다.
+{{< /note >}}
+
+`index.html` 파일이 존재하는지 테스트한다.
+
+```shell
+cat /mnt/data/index.html
+```
+
+결과는 다음과 같다.
+```
+Hello from Kubernetes storage
+```
+
+이제 사용자 노드에서 셸을 종료해도 된다.
+
+## 퍼시스턴트볼륨 생성하기
+
+이 예제에서, 사용자는 *hostPath* 퍼시스턴트볼륨을 생성한다. 쿠버네티스는 단일 노드에서의 
+개발과 테스트를 위해 hostPath를 지원한다. hostPath 퍼시스턴트볼륨은 
+네트워크로 연결된 스토리지를 모방하기 위해, 노드의 파일이나 디렉터리를 사용한다.
+
+운영 클러스터에서, 사용자가 hostPath를 사용하지는 않는다. 대신, 클러스터 관리자는 
+Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic 
+Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는 
+[스토리지클래스(StorageClasses)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage)를 
+사용하여 
+[동적 프로비저닝](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)을 설정할 수도 있다. 
+
+hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다.
+
+{{< codenew file="pods/storage/pv-volume.yaml" >}}
+
+설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고
+지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
+읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를
+지정한다. 여기서는 
+퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 
+`manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 
+이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
+
+퍼시스턴트볼륨을 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
+```
+
+퍼시스턴트볼륨에 대한 정보를 조회한다.
+
+```shell
+kubectl get pv task-pv-volume
+```
+
+결과는 퍼시스턴트볼륨의 `STATUS` 가 `Available` 임을 보여준다. 이는 
+아직 퍼시스턴트볼륨클레임이 바인딩되지 않았다는 것을 의미한다.
+
+    NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
+    task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s
+
+## 퍼시스턴트볼륨클레임 생성하기
+
+다음 단계는 퍼시스턴트볼륨클레임을 생성하는 단계이다. 파드는 퍼시스턴트볼륨클레임을 
+사용하여 물리적인 스토리지를 요청한다. 이 예제에서, 사용자는 적어도 
+하나 이상의 노드에 대해 읽기-쓰기 접근을 지원하며 최소 3 기가바이트의 볼륨을 요청하는
+퍼시스턴트볼륨클레임을 생성한다.
+
+퍼시스턴트볼륨클레임에 대한 설정 파일은 다음과 같다.
+
+{{< codenew file="pods/storage/pv-claim.yaml" >}}
+
+퍼시스턴트볼륨클레임을 생성한다.
+
+    kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml
+
+사용자가 퍼시스턴트볼륨클레임을 생성한 후에, 쿠버네티스 컨트롤 플레인은 
+클레임의 요구사항을 만족하는 퍼시스턴트볼륨을 찾는다. 컨트롤 플레인이 
+동일한 스토리지클래스를 갖는 적절한 퍼시스턴트볼륨을 찾으면, 
+볼륨에 클레임을 바인딩한다.
+
+퍼시스턴트볼륨을 다시 확인한다.
+
+```shell
+kubectl get pv task-pv-volume
+```
+
+이제 결과는 `STATUS` 가 `Bound` 임을 보여준다.
+
+    NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
+    task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m
+
+퍼시스턴트볼륨클레임을 확인한다.
+
+```shell
+kubectl get pvc task-pv-claim
+```
+
+결과는 퍼시스턴트볼륨클레임이 사용자의 퍼시스턴트볼륨인 `task-pv-volume` 에 
+바인딩되어 있음을 보여준다.
+
+    NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
+    task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s
+
+## 파드 생성하기
+
+다음 단계는 볼륨으로 퍼시스턴트볼륨클레임을 사용하는 파드를 만드는 단계이다.
+
+파드에 대한 설정 파일은 다음과 같다.
+
+{{< codenew file="pods/storage/pv-pod.yaml" >}}
+
+파드의 설정 파일은 퍼시스턴트볼륨클레임을 지정하지만, 
+퍼시스턴트볼륨을 지정하지는 않는다는 것을 유념하자. 파드의 관점에서 볼때, 
+클레임은 볼륨이다.
+
+파드를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
+```
+
+파드의 컨테이너가 실행 중임을 확인한다.
+
+```shell
+kubectl get pod task-pv-pod
+```
+
+사용자 파드에서 구동되고 있는 컨테이너에 셸로 접근한다.
+
+```shell
+kubectl exec -it task-pv-pod -- /bin/bash
+```
+
+사용자의 셸에서, nginx가 hostPath 볼륨으로부터 `index.html` 파일을 
+제공하는지 확인한다.
+
+```shell
+# 이전 단계에서 "kubectl exec" 명령을 실행한 root 셸 안에서 
+# 다음의 3개 명령을 실행해야 한다.
+apt update
+apt install curl
+curl http://localhost/
+```
+
+결과는 hostPath 볼륨에 있는 `index.html` 파일에 사용자가 작성한 텍스트를
+보여준다.
+
+    Hello from Kubernetes storage
+
+
+만약 사용자가 위와 같은 메시지를 확인하면, 파드가 퍼시스턴트볼륨클레임의 스토리지를 
+사용하도록 성공적으로 설정한 것이다.
+
+## 정리하기
+
+파드, 퍼시스턴트볼륨클레임, 퍼시스턴트볼륨을 삭제한다.
+
+```shell
+kubectl delete pod task-pv-pod
+kubectl delete pvc task-pv-claim
+kubectl delete pv task-pv-volume
+```
+
+만약 클러스터의 노드에 대한 셸이 열려져 있지 않은 경우, 
+이전과 동일한 방식으로 새로운 셸을 연다.
+
+사용자 노드의 셸에서, 생성한 파일과 디렉터리를 제거한다.
+
+```shell
+# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여
+# "sudo"를 사용한다고 가정한다
+sudo rm /mnt/data/index.html
+sudo rmdir /mnt/data
+```
+
+이제 사용자 노드에서 셸을 종료해도 된다.
+
+
+
+
+<!-- discussion -->
+
+## 접근 제어
+
+그룹 ID(GID)로 설정된 스토리지는 동일한 GID를 사용하는 파드에서만 쓰기 
+작업을 허용한다. GID가 일치하지 않거나 누락되었을 경우 권한 
+거부 오류가 발생한다. 사용자와의 조정 필요성을 줄이기 위하여 관리자는 
+퍼시스턴트 볼륨에 GID로 어노테이션을 달 수 있다. 그 뒤에, 퍼시스턴트볼륨을 
+사용하는 모든 파드에 대하여 GID가 자동으로 추가된다.
+
+다음과 같이 `pv.beta.kubernetes.io/gid` 어노테이션을 사용한다.
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv1
+  annotations:
+    pv.beta.kubernetes.io/gid: "1234"
+```
+파드가 GID 어노테이션이 있는 퍼시스턴트볼륨을 사용하면, 어노테이션으로
+달린 GID가 파드의 보안 컨텍스트에 지정된 GID와 동일한 방식으로
+파드의 모든 컨테이너에 적용된다. 파드의 명세 혹은 퍼시스턴트볼륨의
+어노테이션으로부터 생성된 모든 GID는, 각 컨테이너에서 실행되는 첫 번째
+프로세스에 적용된다.
+
+{{< note >}}
+파드가 퍼시스턴트볼륨을 사용할 때, 퍼시스턴트볼륨과 연관된 
+GID는 파드 리소스 자체에는 존재하지 않는다.
+{{< /note >}}
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기.
+* [퍼시스턴트 스토리지 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)에 대해 읽어보기.
+
+### Reference
+
+* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
+* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
+* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
+* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
diff --git a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md
index ee7d5a9f82..92abf6e4f6 100644
--- a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md
+++ b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md
@@ -37,7 +37,7 @@ weight: 130
 `/usr/share/nginx/html` 에 마운트한다. 초기화 컨테이너는 다음 명령을 실행 후
 종료한다.
 
-    wget -O /work-dir/index.html http://kubernetes.io
+    wget -O /work-dir/index.html http://info.cern.ch
 
 초기화 컨테이너는 nginx 서버의 루트 디렉터리 내 `index.html` 파일을
 저장한다.
@@ -67,16 +67,13 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
 
 출력 결과는 nginx가 초기화 컨테이너에 의해 저장된 웹 페이지를 제공하고 있음을 보여준다.
 
-    <!Doctype html>
-    <html id="home">
+    <html><head></head><body><header>
+    <title>http://info.cern.ch</title>
+    </header>
 
-    <head>
-    ...
-    "url": "http://kubernetes.io/"}</script>
-    </head>
-    <body>
+    <h1>http://info.cern.ch - home of the first website</h1>
       ...
-      <p>Kubernetes is open source giving you the freedom to take advantage ...</p>
+      <li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
       ...
 
 
diff --git a/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md
index b202417ee1..73c7493909 100644
--- a/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md
+++ b/content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -136,7 +136,7 @@ Redis 파드의
 
 * [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 참고한다.
 
-* 쿠버네티스는 `emptyDir` 이 제공하는 로컬 디스크 스토리지 뿐만 아니라,
+* 쿠버네티스는 `emptyDir` 이 제공하는 로컬 디스크 스토리지뿐만 아니라,
 중요한 데이터에 선호하는 GCE의 PD, EC2의 EBS를 포함해서
 네트워크 연결 스토리지(NAS) 솔루션을 지원하며,
 노드의 디바이스 마운트, 언마운트와 같은 세부사항을 처리한다.
diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
index 939919b2e6..34cb102f83 100644
--- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
+++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
@@ -206,7 +206,7 @@ kubectl get pod private-reg
 ## {{% heading "whatsnext" %}}
 
 
-* [시크릿](/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
+* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
 * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
 * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
diff --git a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
index 77ac7ce6d5..2d1d482585 100644
--- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -80,7 +80,7 @@ spec:
       requests:
         cpu: 700m
         memory: 200Mi
-  ...
+    ...
 status:
   qosClass: Guaranteed
 ```
@@ -269,4 +269,3 @@ kubectl delete namespace qos-example
 * [API 오브젝트 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/)
 
 * [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)
-
diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md
index dc774b9ce3..a831f5d267 100644
--- a/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -5,24 +5,20 @@ content_type: task
 
 <!-- overview -->
 
-이 페이지는 초기화 컨테이너의 실행과 관련된 문제를 
-조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로, 
-초기화 컨테이너를 `<init-container-1>` 과 
+이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
+조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
+초기화 컨테이너를 `<init-container-1>` 과
 `<init-container-2>` 로 표시한다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의 
+* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
   기본 사항에 익숙해야 한다.
 * 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다.
 
-
-
 <!-- steps -->
 
 ## 초기화 컨테이너의 상태 체크하기
@@ -33,7 +29,7 @@ content_type: task
 kubectl get pod <pod-name>
 ```
 
-예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중 
+예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
 하나가 성공적으로 완료되었음을 나타낸다.
 
 ```
@@ -41,7 +37,7 @@ NAME         READY     STATUS     RESTARTS   AGE
 <pod-name>   0/1       Init:1/2   0          7s
 ```
 
-상태값과 그 의미에 대한 추가 예제는 
+상태값과 그 의미에 대한 추가 예제는
 [파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다.
 
 ## 초기화 컨테이너에 대한 상세 정보 조회하기
@@ -82,7 +78,7 @@ Init Containers:
     ...
 ```
 
-파드 스펙의 `status.initContainerStatuses` 필드를 읽어서 
+파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
 프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다.
 
 
@@ -102,8 +98,8 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
 kubectl logs <pod-name> -c <init-container-2>
 ```
 
-셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가 
-실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에 
+셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
+실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
 `set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다.
 
 
@@ -112,8 +108,8 @@ kubectl logs <pod-name> -c <init-container-2>
 
 ## 파드의 상태 이해하기
 
-`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의 
-실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는 
+`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
+실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
 동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다.
 
 상태 | 의미
diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
new file mode 100644
index 0000000000..4efe37f77b
--- /dev/null
+++ b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -0,0 +1,103 @@
+---
+title: 파드와 레플리케이션컨트롤러(ReplicationController) 디버그하기
+content_type: task
+---
+
+<!-- overview -->
+
+이 페이지에서는 파드와 레플리케이션컨트롤러를 디버깅하는 방법을 소개한다.
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+* 사용자는
+  {{< glossary_tooltip text="파드" term_id="pod" >}} 기본 사항과 파드의  
+  [라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 잘 알고 있어야 한다.
+
+<!-- steps -->
+
+## 파드 디버깅
+
+파드 디버깅의 첫 번째 단계는 파드를 살펴 보는 것이다. 다음의 명령어를
+사용하여 파드의 현재 상태와 최근 이벤트를 점검한다.
+
+```shell
+kubectl describe pods ${POD_NAME}
+```
+
+파드 내부 컨테이너의 상태를 확인한다. 모두 `Running` 상태인가?
+최근에 재시작 되었는가?
+
+파드의 상태에 따라 디버깅을 계속한다.
+
+### 파드가 pending 상태로 유지
+
+파드가 `Pending` 상태로 멈춰 있는 경우는, 노드에 스케줄 될 수 없음을 의미한다.
+일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다.
+상단의 `kubectl describe ...` 명령의 결과를 확인하자.
+파드를 스케줄 할 수 없는 이유에 대한 스케줄러의 메세지가 있어야 한다.
+이유는 다음과 같다.
+
+#### 부족한 리소스
+
+사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우
+몇 가지 방법을 시도할 수 있다.
+
+* 클러스터에 [노드를 더 추가하기](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-크기-재조정).
+
+* pending 상태인 파드를 위한 공간을 확보하기 위해
+  [불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
+
+* 파드가 노드보다 크지 않은지 확인한다. 예를 들어 모든
+  노드가 `cpu:1` 의 용량을 가지고 있을 경우, `cpu: 1.1` 을 요청하는 파드는
+  절대 스케줄 될 수 없다.
+
+	사용자는 `kubectl get nodes -o <format>` 명령으로 노드의
+	용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지
+	명령의 예이다.
+
+    ```shell
+    kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
+    kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
+    ```
+
+  [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)
+  기능은 사용할 수 있는 전체 리소스의 양을 제한하도록 설정할 수 있다.
+  네임스페이스와 함께 사용하면,
+  한 팀이 모든 리소스를 점유하는 것을 방지할 수 있다.
+
+#### hostPort 사용하기
+
+파드를 `hostPort` 에 바인딩 할 때 파드를 스케줄링 할 수 있는
+위치는 제한되어 있다. 대부분의 경우 `hostPort` 는 불필요하다. 서비스 오브젝트를
+사용하여 파드를 노출하도록 한다. `hostPort` 가 필요한 경우
+컨테이너 클러스터에 있는 노드의 수만큼 파드를 스케줄 할 수 있다.
+
+### 파드가 waiting 상태로 유지
+
+파드가 `Waiting` 상태에서 멈춘 경우, 워커 노드에 스케줄 되었지만, 해당 장비에서 사용할 수 없다.
+거듭 강조하지만, `kubectl describe ...` 의 정보는 유익하게 사용되어야 한다.
+`Waiting` 파드의 가장 일반적인 원인은 이미지를 가져오지 못하는 경우이다.
+확인해야 할 3가지 사항이 있다.
+
+* 이미지 이름이 올바른지 확인한다.
+* 이미지를 저장소에 푸시하였는가?
+* 이미지가 풀 될 수 있는지 보기 위해, 사용자의 장비에서 `docker pull <image>` 를 수동으로
+  실행한다.
+
+### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
+
+일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에
+기술된 메서드를 디버깅에 사용할 수 있다.
+
+
+## 레플리케이션컨트롤러 디버깅
+
+레플리케이션컨트롤러는 매우 간단하다. 이 오브젝트는 파드를 만들거나
+만들 수 없는 경우뿐이다. 만약 파드를 만들 수 없는 경우,
+[위의 지침](#파드-디버깅)을 참조하여 파드를 디버그한다.
+
+사용자는 `kubectl describe rc ${CONTROLLER_NAME}` 을 사용하여 레플리케이션 컨트롤러와
+관련된 이벤트를 검사할 수도 있다.
diff --git a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index cf0b639cbd..54a2ae61b0 100644
--- a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -7,7 +7,7 @@ title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로
 
 Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
 [스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
-[스택드라이버 로깅으로 로깅하기](/docs/user-guide/logging/stackdriver)에 자세히 설명되어 있다.
+[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다.
 
 이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
 [엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
@@ -87,7 +87,8 @@ monitoring-influx-grafana-v1-o79xf             2/2       Running   0          2h
 
 엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
 있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
-[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에 대한 지침을 참고한다.
+[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에
+대한 지침을 참고한다.
 
 브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
 다음과 같은 상태 페이지가 표시된다.
@@ -118,5 +119,3 @@ monitoring-influx-grafana-v1-o79xf             2/2       Running   0          2h
 
 키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
 아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.
-
-
diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index ee6991ef30..a9c9bf182d 100644
--- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -7,19 +7,16 @@ content_type: concept
 
 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
 쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
-`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
+`kubectl top` 커맨드 사용하여 사용자가 직접적으로 액세스하거나,
 Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
 
-
-
-
 <!-- body -->
 
 ## 메트릭 API
 
-메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
+메트릭 API를 통해, 주어진 노드나 파드에서 현재 사용중인
 리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
-않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
+않으므로, 예를 들어, 지정된 노드에서 10분 전에 사용된 리소스의 양을
 가져오는 것과 같은 일을 할 수는 없다.
 
 이 API와 다른 API는 차이가 없다.
@@ -38,22 +35,30 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 
 
 ### CPU
 
-CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
+CPU는 일정 기간 동안
+[CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서
+평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는
+누적 CPU 카운터보다 높은 비율을 적용해서 얻는다.
+kubelet은 비율 계산에 사용할 윈도우를 선택한다.
 
 ### 메모리
 
-메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. 이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. 그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. 쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. 호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
+메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다.
+이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다.
+그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다.
+쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다.
+호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
 
 ## 메트릭 서버
 
 [메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
-`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
+기본적으로, `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 메트릭 서버가
 디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다.
 
-메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
-
-메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
+메트릭 서버는 각 노드에서 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해
+노출된 Summary API에서 메트릭을 수집하고, [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
 통해 메인 API 서버에 등록된다.
 
-[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다.
+[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서
+메트릭 서버에 대해 자세하게 배울 수 있다.
diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index 34c51ad860..87856b9cfe 100644
--- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -5,38 +5,41 @@ title: 리소스 모니터링 도구
 
 <!-- overview -->
 
-애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, 
-애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. 
-컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), 
-[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 
-검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 
+애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
+애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
+컨테이너, [파드](/ko/docs/concepts/workloads/pods/),
+[서비스](/ko/docs/concepts/services-networking/service),
+그리고 전체 클러스터의 특성을 검사하여
+쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
-이 정보는 애플리케이션의 성능을 평가하고 
+이 정보는 애플리케이션의 성능을 평가하고
 병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다.
 
-
-
 <!-- body -->
 
-쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
+쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
+신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는
+[완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다.
 
 ## 리소스 메트릭 파이프라인
 
-리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
-컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는
+리소스 메트릭 파이프라인은
+[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
+컨트롤러와 같은 클러스터 구성요소나
+`kubectl top` 유틸리티에 관련되어 있는
 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에
-의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. 
+의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다.
 
-metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 
-[Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리 
+metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
+[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 CPU와 메모리 
 사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서
 머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는
 컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서
-개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의 
+개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
 통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드
 리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는
-kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서 
+kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서
 제공된다.
 
 ## 완전한 메트릭 파이프라인
@@ -50,5 +53,3 @@ kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1
 
 CNCF 프로젝트인, [프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
 CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다.
-
-
diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
index 68ee4726a5..aae34dc3b9 100644
--- a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
+++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
@@ -89,8 +89,8 @@ command: ["/bin/echo"]
 args: ["$(MESSAGE)"]
 ```
 
-이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure
--pod-configmap/)과 [시크릿](/docs/concepts/configuration/secret/)을
+이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)과
+[시크릿](/ko/docs/concepts/configuration/secret/)을
 포함해, 환경 변수를 정의하는데 활용할 수 있는 모든 방법들을 활용해서 파드를 위한 인자를
 정의할
 수 있다는 것을 의미한다.
diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
index c7057c1887..191e82021c 100644
--- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -9,28 +9,21 @@ weight: 20
 본 페이지는 쿠버네티스 파드의 컨테이너를 위한 환경 변수를
 정의하는 방법에 대해 설명한다.
 
-
-
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
-
 <!-- steps -->
 
 ## 컨테이너를 위한 환경 변수 정의하기
 
-파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할 
+파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할
 수 있다. 환경 변수를 설정하려면, 구성 파일에 `env`나 `envFrom` 필드를
 포함시켜야 한다.
 
 이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
 파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는
-값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 
+값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트
 예시이다.
 
 {{< codenew file="pods/inject/envars.yaml" >}}
@@ -81,24 +74,24 @@ weight: 20
 1. 셸에서 빠져나오기 위해, `exit`을 입력한다.
 
 {{< note >}}
-`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 
+`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
 안에서 명시된 모든 환경 변수들을 오버라이딩한다.
 {{< /note >}}
 
 {{< note >}}
-환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다. 
+환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다.
 사용하기 전에 순서에 주의한다.
 {{< /note >}}
 
 ## 설정 안에서 환경 변수 사용하기
 
-파드의 구성 파일 안에서 정의한 환경 변수는 
-파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, 
-구성 파일 안의 다른 곳에서 사용할 수 있다. 
-아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 
-`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 
-그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은 
-이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 
+파드의 구성 파일 안에서 정의한 환경 변수는
+파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이,
+구성 파일 안의 다른 곳에서 사용할 수 있다.
+아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고
+`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`,
+그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은
+이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서
 사용된다.
 
 ```yaml
@@ -123,12 +116,8 @@ spec:
 
 컨테이너가 생성되면, `echo Warm greetings to The Most Honorable Kubernetes` 커맨드가 컨테이너에서 실행된다.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
-* [시크릿을 환경 변수로 사용하기](/docs/user-guide/secrets/#using-secrets-as-environment-variables)에 대해 알아본다.
+* [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다.
 * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
-
diff --git a/content/ko/docs/tasks/job/_index.md b/content/ko/docs/tasks/job/_index.md
new file mode 100644
index 0000000000..b93792b7f8
--- /dev/null
+++ b/content/ko/docs/tasks/job/_index.md
@@ -0,0 +1,5 @@
+---
+title: "잡(Job) 실행"
+description: 병렬 처리를 사용하여 잡을 실행한다.
+weight: 50
+---
diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
new file mode 100644
index 0000000000..e2b1435464
--- /dev/null
+++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
@@ -0,0 +1,208 @@
+---
+title: 크론잡(CronJob)으로 자동화된 작업 실행
+min-kubernetes-server-version: v1.8
+content_type: task
+weight: 10
+---
+
+<!-- overview -->
+
+시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
+이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
+
+크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
+크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
+
+크론 잡에는 제한 사항과 특이점이 있다.
+예를 들어, 특정 상황에서는 하나의 크론 잡이 여러 잡을 생성할 수 있다.
+따라서, 잡은 멱등성을 가져야 한다.
+
+제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+* {{< include "task-tutorial-prereqs.md" >}}
+
+
+
+<!-- steps -->
+
+## 크론 잡 생성
+
+크론 잡은 구성 파일이 필요하다.
+아래의 크론 잡 구성 `.spec` 파일의 예제는 매 분마다 현재 시간과 hello 메시지를 출력한다.
+
+{{< codenew file="application/job/cronjob.yaml" >}}
+
+다음 명령을 사용하여 크론잡 예제를 실행한다.
+
+```shell
+kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml
+```
+출력 결과는 다음과 비슷하다.
+
+```
+cronjob.batch/hello created
+```
+
+크론 잡을 생성한 후, 다음 명령을 사용하여 상태를 가져온다.
+
+```shell
+kubectl get cronjob hello
+```
+출력 결과는 다음과 비슷하다.
+
+```
+NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
+hello   */1 * * * *   False     0        <none>          10s
+```
+
+명령의 결과에서 알 수 있듯이, 크론 잡은 아직 잡을 스케줄하거나 실행하지 않았다.
+약 1분 내로 잡이 생성되는지 확인한다.
+
+```shell
+kubectl get jobs --watch
+```
+출력 결과는 다음과 비슷하다.
+
+```
+NAME               COMPLETIONS   DURATION   AGE
+hello-4111706356   0/1                      0s
+hello-4111706356   0/1           0s         0s
+hello-4111706356   1/1           5s         5s
+```
+
+이제 "hello" 크론 잡에 의해 스케줄된 실행 중인 작업을 확인했다.
+잡 감시를 중지한 뒤에 크론 잡이 다시 스케줄되었는지를 확인할 수 있다.
+
+```shell
+kubectl get cronjob hello
+```
+출력 결과는 다음과 비슷하다.
+
+```
+NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
+hello   */1 * * * *   False     0        50s             75s
+```
+
+크론 잡 `hello` 가 `LAST SCHEDULE` 에 지정된 시간에 성공적으로 잡을 스케줄했는지 확인해야 한다. 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
+
+이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
+
+{{< note >}}
+잡 이름과 파드 이름은 다르다.
+{{< /note >}}
+
+```shell
+# "hello-4111706356"을 사용자의 시스템에 있는 잡 이름으로 바꾼다
+pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})
+```
+파드의 로그를 출력한다.
+
+```shell
+kubectl logs $pods
+```
+출력 결과는 다음과 비슷하다.
+
+```
+Fri Feb 22 11:02:09 UTC 2019
+Hello from the Kubernetes cluster
+```
+
+## 크론 잡 삭제
+
+더 이상 크론 잡이 필요하지 않으면, `kubectl delete cronjob <cronjob name>` 명령을 사용해서 삭제한다.
+
+```shell
+kubectl delete cronjob hello
+```
+
+크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
+[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
+
+## 크론 잡 명세 작성
+
+다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
+작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
+[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
+
+크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
+
+{{< note >}}
+크론 잡, 특히 해당 잡의 `.spec` 에 대한 모든 수정 사항은 다음 번 실행에만 적용된다.
+{{< /note >}}
+
+### 스케줄
+
+`.spec.schedule` 은 `.spec` 의 필수 필드이다.
+이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
+
+이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은
+[FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
+
+> 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/<number>` 를
+> 지정하여 범위 내에서 숫자만큼의 값을 건너뛴다. 예를 들어,
+> 시간 필드에 `0-23/2` 를 사용하여 매 2시간마다 명령 실행을
+> 지정할 수 있다(V7 표준의 대안은 `0,2,4,6,8,10,12,14,16,18,20,22`
+> 이다). 별표(asterisk) 뒤에 붙이는 스텝도 허용되며,
+> "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
+
+{{< note >}}
+스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
+{{< /note >}}
+
+### 잡 템플릿
+
+`.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
+이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
+잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
+
+### 시작 기한
+
+`.spec.startingDeadlineSeconds` 필드는 선택 사항이다.
+어떤 이유로든 스케줄된 시간을 놓친 경우 잡의 시작 기한을 초 단위로 나타낸다.
+기한이 지나면, 크론 잡이 잡을 시작하지 않는다.
+이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
+이 필드를 지정하지 않으면, 잡에 기한이 없다.
+
+크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다.
+
+예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다.
+
+`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다.
+
+예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다.
+
+### 동시성 정책
+
+`.spec.concurrencyPolicy` 필드도 선택 사항이다.
+이것은 이 크론 잡에 의해 생성된 잡의 동시 실행을 처리하는 방법을 지정한다.
+명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
+
+* `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
+* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
+* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
+
+참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
+크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
+
+### 일시 정지
+
+`.spec.suspend` 필드도 선택 사항이다.
+`true` 로 설정되면, 모든 후속 실행이 일시 정지된다.
+이 설정은 이미 시작된 실행에는 적용되지 않는다.
+기본값은 false이다.
+
+{{< caution >}}
+스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
+[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
+{{< /caution >}}
+
+### 잡 히스토리 한도
+
+`.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
+이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
+기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
diff --git a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
new file mode 100644
index 0000000000..aeaac4803d
--- /dev/null
+++ b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
@@ -0,0 +1,328 @@
+---
+title: 작업 대기열을 사용한 거친 병렬 처리
+min-kubernetes-server-version: v1.8
+content_type: task
+weight: 30
+---
+
+
+<!-- overview -->
+
+이 예제에서는, 여러 병렬 워커 프로세스를 활용해 쿠버네티스 잡(Job)을
+실행한다. 
+
+이 예제에서는, 각 파드가 생성될 때 작업 대기열에서 하나의 작업 단위를
+선택하여, 완료하고, 대기열에서 삭제하고, 종료한다. 
+
+이 예제에서의 단계에 대한 개요는 다음과 같다.
+
+1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도
+   된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다.
+1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 
+   이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
+1. **대기열에서 작업을 수행하는 잡을 시작한다.**  잡은 여러 파드를 시작한다. 각 파드는
+   메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
+
+## {{% heading "prerequisites" %}}
+
+
+기본적이고, 병렬 작업이 아닌,
+[잡](/ko/docs/concepts/workloads/controllers/job/)의 사용법에 대해 잘 알고 있어야 한다.
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+## 메시지 대기열 서비스 시작
+
+이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다.
+
+실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
+구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.
+
+다음과 같이 RabbitMQ를 시작한다.
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-service.yaml
+```
+```
+service "rabbitmq-service" created
+```
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-controller.yaml
+```
+```
+replicationcontroller "rabbitmq-controller" created
+```
+
+이 문서에서는 [celery-rabbitmq 예제](https://github.com/kubernetes/kubernetes/tree/release-1.3/examples/celery-rabbitmq)에 나오는 정도로만 rabbitmq를 사용한다.
+
+## 메시지 대기열 서비스 테스트하기
+
+이제, 메시지 대기열을 이용해 실험할 수 있다. 임시
+대화형 파드를 만들어 그 위에 도구들을 설치하고,
+대기열을 실험해본다. 
+
+먼저 임시 대화형 파드를 만든다. 
+
+```shell
+# 임시 대화형 컨테이너를 만든다.
+kubectl run -i --tty temp --image ubuntu:18.04
+```
+```
+Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
+... [ previous line repeats several times .. hit return when it stops ] ...
+```
+
+참고로 파드 이름과 명령 프롬프트는 위와 다를 수 있다.
+
+다음으로 `amqp-tools`를 설치하여 메시지 대기열을 활용할 수 있게 한다.
+
+```shell
+# 도구들을 설치한다.
+root@temp-loe07:/# apt-get update
+.... [ lots of output ] ....
+root@temp-loe07:/# apt-get install -y curl ca-certificates amqp-tools python dnsutils
+.... [ lots of output ] ....
+```
+
+후에, 이 패키지들을 포함하는 도커 이미지를 만든다.
+
+다음으로, rabbitmq 서비스를 발견할 수 있는지 확인한다.
+
+```
+# rabbitmq-service가 쿠버네티스로부터 주어진 DNS 이름을 갖는다.
+
+root@temp-loe07:/# nslookup rabbitmq-service
+Server:        10.0.0.10
+Address:    10.0.0.10#53
+
+Name:    rabbitmq-service.default.svc.cluster.local
+Address: 10.0.147.152
+
+# 주소는 다를 수 있다.
+```
+
+만약 Kube-DNS가 적절히 구축되지 않았다면, 전 단계 작업이 작동하지 않을 수 있다.
+환경 변수를 통해서도 서비스 IP를 찾을 수 있다.
+
+```
+# env | grep RABBIT | grep HOST
+RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152
+# 주소는 다를 수 있다.
+```
+
+다음으로 대기열을 생성하고, 메시지를 발행하고 사용할 수 있는지 확인한다.
+
+```shell
+# 다음 줄에서, rabbitmq-service는 rabbitmq-service에 접근할 수 있는 
+# 호스트네임이다. 5672는 rabbitmq의 표준 포트이다.
+
+root@temp-loe07:/# export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672
+# 만약 전 단계에서 "rabbitmq-service"가 주소로 변환되지 않는다면,
+# 이 커맨드를 대신 사용하면 된다.
+# root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672
+
+# 이제 대기열을 생성한다.
+
+root@temp-loe07:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d
+foo
+
+# 대기열에 메시지를 하나 발행한다.
+
+root@temp-loe07:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello
+
+# 다시 메시지를 돌려받는다.
+
+root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo
+Hello
+root@temp-loe07:/#
+```
+
+마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를
+받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터
+받은 값을 바로 출력하고 있고,  echo가 캐리지 리턴을 더해주어
+출력 결과가 보여진다.
+
+## 작업으로 대기열 채우기
+
+이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을
+출력하는 것이다.
+
+실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다. 
+
+- 처리되어야 하는 파일들의 이름
+- 프로그램의 추가 플래그
+- 데이터베이스 테이블의 키(key) 범위
+- 시뮬레이션의 구성 파라미터
+- 렌더링해야 하는 씬(scene)의 프레임 번호
+
+실제로는, 잡의 모든 파드에서 읽기-전용 모드로 필요한 큰 데이터가
+있다면, 일반적으로 그 데이터를 NFS와 같은 공유 파일시스템에 넣고
+모든 파드에 읽기 전용으로 마운트하거나, 파드 안에 있는 프로그램이 기본적으로 HDFS와 같은
+클러스터 파일시스템으로부터 데이터를 불러들인다.
+
+본 예제에서는, 대기열을 만들고 amqp 커맨드라인 도구를 이용해 대기열을 채울 것이다.
+실제로는, amqp 라이브러리를 이용해 대기열을 채우는 프로그램을 작성하게 된다.
+
+```shell
+/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1  -d
+job1
+```
+```shell
+for f in apple banana cherry date fig grape lemon melon
+do
+  /usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f
+done
+```
+
+8개의 메시지로 대기열을 채웠다.
+
+## 이미지 생성
+
+이제 잡으로 실행할 이미지를 만들 준비가 되었다.
+
+`amqp-consume` 유틸리티를 이용해 대기열로부터 메시지를 읽고,
+실제 프로그램을 실행해 볼 것이다.
+여기에 아주 간단한 예제 프로그램이 있다.
+
+{{< codenew language="python" file="application/job/rabbitmq/worker.py" >}}
+
+스크립트에 실행 권한을 준다.
+
+```shell
+chmod +x worker.py
+```
+
+이제 이미지를 빌드한다. 만약 소스 트리 안에서 작업하고
+있다면, `examples/job/work-queue-1`로 디렉터리를 옮긴다.
+아니면, 임시 디렉터리를 만들고, 그 디렉터리로 옮긴다.
+[Dockerfile](/examples/application/job/rabbitmq/Dockerfile)과
+[worker.py](/examples/application/job/rabbitmq/worker.py)를 다운로드한다.
+위 두 경우 모두, 다음의 명령을 이용해 이미지를 빌드한다.
+
+```shell
+docker build -t job-wq-1 .
+```
+
+[도커 허브](https://hub.docker.com/)를 이용하기 위해, 앱 이미지를
+사용자의 username으로 태깅하고 아래의 명령어를 이용해 허브에 푸시한다.
+`<username>`을 사용자의 허브 username으로 대체한다.
+
+```shell
+docker tag job-wq-1 <username>/job-wq-1
+docker push <username>/job-wq-1
+```
+
+만약 [구글 컨테이너
+레지스트리](https://cloud.google.com/tools/container-registry/)를 이용하고 있다면, 
+앱 이미지를 사용자의 프로젝트 ID를 이용해 태깅하고, GCR에 푸시한다.
+`<proejct>` 부분을 사용자의 프로젝트 ID로 대체한다.
+
+```shell
+docker tag job-wq-1 gcr.io/<project>/job-wq-1
+gcloud docker -- push gcr.io/<project>/job-wq-1
+```
+
+## 잡 정의
+
+다음은 잡 정의이다. 잡의 사본을 만들고 위에서 정한 이름에 맞게
+이미지를 수정하고, 파일 이름을 `./job.yaml`이라 정한다.
+
+
+{{< codenew file="application/job/rabbitmq/job.yaml" >}}
+
+이 예시에서는, 각 파드가 대기열로부터 얻은 하나의 아이템을 수행하고 종료한다.
+그래서, 잡의 완료 횟수가 완료된 작업 아이템의 숫자에 대응한다.
+예시에서 `.spec.completions: 8`이라 정한 것도, 대기열에 8개의 아이템을 넣었기 때문이다.
+
+## 잡 실행
+
+이제 잡을 실행한다.
+
+```shell
+kubectl apply -f ./job.yaml
+```
+
+이제 조금 기다린 다음, 잡을 확인한다.
+
+```shell
+kubectl describe jobs/job-wq-1
+```
+```
+Name:             job-wq-1
+Namespace:        default
+Selector:         controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
+Labels:           controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
+                  job-name=job-wq-1
+Annotations:      <none>
+Parallelism:      2
+Completions:      8
+Start Time:       Wed, 06 Sep 2017 16:42:02 +0800
+Pods Statuses:    0 Running / 8 Succeeded / 0 Failed
+Pod Template:
+  Labels:       controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
+                job-name=job-wq-1
+  Containers:
+   c:
+    Image:      gcr.io/causal-jigsaw-637/job-wq-1
+    Port:
+    Environment:
+      BROKER_URL:       amqp://guest:guest@rabbitmq-service:5672
+      QUEUE:            job1
+    Mounts:             <none>
+  Volumes:              <none>
+Events:
+  FirstSeen  LastSeen   Count    From    SubobjectPath    Type      Reason              Message
+  ─────────  ────────   ─────    ────    ─────────────    ──────    ──────              ───────
+  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-hcobb
+  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-weytj
+  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-qaam5
+  27s        27s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-b67sr
+  26s        26s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-xe5hj
+  15s        15s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-w2zqe
+  14s        14s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-d6ppa
+  14s        14s        1        {job }                   Normal    SuccessfulCreate    Created pod: job-wq-1-p17e0
+```
+
+모든 파드가 성공했다. 야호.
+
+
+
+<!-- discussion -->
+
+## 대안
+
+이러한 접근은 "워커" 프로그램을 작업 대기열에 맞게 수정하지 않아도 
+된다는 장점이 있다.
+
+이 접근을 이용하려면, 메시지 대기열 서비스를 실행해야만 한다.
+만약 메시지 대기열 서비스를 실행하는 게 불편하다면, 
+다른 [잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)을 고려해볼 수 있다.
+
+이 접근은 모든 작업 아이템에 대해 파드를 생성한다. 만약 작업 아이템이 오직 몇 초밖에 걸리지 않는 작업이라면, 
+매 작업마다 파드를 생성하는 것은 아주 큰 오버헤드를 더할 수 있다. 하나의 파드가
+여러 작업 아이템을 수행하는 이 [예제](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)를 고려해보자.
+
+이 예제에서는, `amqp-consume` 유틸리티를 이용해 대기열로부터 메시지를 읽어
+실제 프로그램을 실행했다. 이러면 메시지 대기열을 이용하기 위해 프로그램을 수정하지
+않아도 된다는 장점이 있다.
+[다른 예제](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)는 
+클라이언트 라이브러리를 이용해 작업 대기열과 소통하는 방법을 보여준다.
+
+## 주의 사항
+
+만약 작업 완료 수가 대기열에 있는 아이템의 숫자보다 적게 설정되면, 
+모든 아이템 처리되지 않는다.
+
+만약 작업 완료 수가 큐에 있는 아이템의 숫자보다 많게 설정되면,
+대기열에 있는 아이템이 모두 처리되어도, 잡이 완료됐다고 표시되지
+않고, 메시지를 기다리는 과정에서 막히는 파드를
+추가적으로 실행시킨다.
+
+이 패턴에서는 경쟁 상태(race)가 잘 나타나지 않는다. 만약 amqp-consume 명령으로부터
+메시지가 인정되는 시간과 컨테이너가 성공적으로 종료되는
+시간 사이에 컨테이너가 종료되거나, kubelet이 api-server에게 파드가 성공했음을 알리기 전에
+노드가 비정상적으로 종료되면, 대기열의 모든 아이템이 처리되었다 해도,
+잡이 완료되었다고 표시되지 않는다.
diff --git a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md
new file mode 100644
index 0000000000..8788477c17
--- /dev/null
+++ b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md
@@ -0,0 +1,233 @@
+---
+title: 작업 대기열을 사용한 정밀 병렬 처리
+content_type: task
+min-kubernetes-server-version: v1.8
+weight: 40
+---
+
+<!-- overview -->
+
+이 예에서는, 지정된 파드에서 여러 병렬 워커 프로세스가 있는
+쿠버네티스 잡(Job)을 실행한다.
+
+이 예에서는, 각 파드가 생성될 때, 작업 대기열에서 하나의 작업 단위를
+선택하여, 처리하고, 대기열이 비워질 때까지 반복한다.
+
+이 예에서의 단계에 대한 개요는 다음과 같다.
+
+1. **작업 대기열을 보관할 스토리지 서비스를 시작한다.**  이 예에서는, Redis를 사용하여
+   작업 항목을 저장한다. 이전 예에서는, RabbitMQ를 사용했다. 이 예에서는, AMQP가 길이가
+   정해져 있는 작업 대기열이 비어있을 때 클라이언트가 이를 감지할 수 있는 좋은 방법을 제공하지
+   않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
+   Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
+1. **대기열을 만들고, 메시지로 채운다.**  각 메시지는 수행할 하나의 작업을 나타낸다. 이
+   예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
+1. **대기열에서 작업을 수행하는 잡을 시작한다.**  잡은 여러 파드를 시작한다. 각 파드는
+   메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+[잡](/ko/docs/concepts/workloads/controllers/job/)의 기본적이고,
+병렬 작업이 아닌, 사용법에 대해 잘 알고 있어야 한다.
+
+<!-- steps -->
+
+## Redis 시작
+
+이 문서의 예시에서는, 단순함을 위해, Redis의 단일 인스턴스를 시작한다.
+Redis를 확장 가능하고 중복적으로 배포하는 예에 대해서는
+[Redis 예시](https://github.com/kubernetes/examples/tree/master/guestbook)를 참고한다.
+
+다음 파일을 직접 다운로드할 수도 있다.
+
+- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
+- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
+- [`Dockerfile`](/examples/application/job/redis/Dockerfile)
+- [`job.yaml`](/examples/application/job/redis/job.yaml)
+- [`rediswq.py`](/examples/application/job/redis/rediswq.py)
+- [`worker.py`](/examples/application/job/redis/worker.py)
+
+
+## 작업으로 대기열 채우기
+
+이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제의 작업은 문자열을 출력하는
+것이다.
+
+Redis CLI를 실행하기 위한 임시 대화형 파드를 시작한다.
+
+```shell
+kubectl run -i --tty temp --image redis --command "/bin/sh"
+Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
+Hit enter for command prompt
+```
+
+이제 엔터 키를 누르고, redis CLI를 시작하고, 몇몇 작업 항목이 포함된 목록을 생성한다.
+
+```
+# redis-cli -h redis
+redis:6379> rpush job2 "apple"
+(integer) 1
+redis:6379> rpush job2 "banana"
+(integer) 2
+redis:6379> rpush job2 "cherry"
+(integer) 3
+redis:6379> rpush job2 "date"
+(integer) 4
+redis:6379> rpush job2 "fig"
+(integer) 5
+redis:6379> rpush job2 "grape"
+(integer) 6
+redis:6379> rpush job2 "lemon"
+(integer) 7
+redis:6379> rpush job2 "melon"
+(integer) 8
+redis:6379> rpush job2 "orange"
+(integer) 9
+redis:6379> lrange job2 0 -1
+1) "apple"
+2) "banana"
+3) "cherry"
+4) "date"
+5) "fig"
+6) "grape"
+7) "lemon"
+8) "melon"
+9) "orange"
+```
+
+자, 키 `job2` 가 있는 목록이 작업 대기열이 된다.
+
+참고: Kube DNS를 올바르게 설정하지 않은 경우, 위 블록의
+첫 번째 단계를 `redis-cli -h $REDIS_SERVICE_HOST` 로 변경해야 할 수 있다.
+
+
+## 이미지 생성
+
+이제 실행할 이미지를 만들 준비가 되었다.
+
+redis 클라이언트와 함께 python 워커 프로그램을 사용하여
+메시지 큐에서 메시지를 읽는다.
+
+rediswq.py([다운로드](/examples/application/job/redis/rediswq.py))라는
+간단한 Redis 작업 대기열 클라이언트 라이브러리가 제공된다.
+
+잡의 각 파드에 있는 "워커" 프로그램은 작업 대기열
+클라이언트 라이브러리를 사용하여 작업을 가져온다. 다음은 워커 프로그램이다.
+
+{{< codenew language="python" file="application/job/redis/worker.py" >}}
+
+[`worker.py`](/examples/application/job/redis/worker.py),
+[`rediswq.py`](/examples/application/job/redis/rediswq.py) 및
+[`Dockerfile`](/examples/application/job/redis/Dockerfile) 파일을 다운로드할 수 있고, 그런 다음
+이미지를 만들 수도 있다.
+
+```shell
+docker build -t job-wq-2 .
+```
+
+### 이미지 푸시
+
+[도커 허브(Docker Hub)](https://hub.docker.com/)를 위해, 아래 명령으로
+사용자의 username과 앱 이미지에 태그하고 허브에 푸시한다. `<username>` 을
+사용자의 허브 username으로 바꾼다.
+
+```shell
+docker tag job-wq-2 <username>/job-wq-2
+docker push <username>/job-wq-2
+```
+
+공용 저장소로 푸시하거나 [개인 저장소에 접근할 수 있도록
+클러스터를 구성](/ko/docs/concepts/containers/images/)해야 한다.
+
+[Google Container
+Registry](https://cloud.google.com/tools/container-registry/)를 사용하는 경우,
+사용자의 프로젝트 ID로 앱 이미지에 태그를 지정하고 GCR로 푸시한다. `<project>` 를
+사용자의 프로젝트 ID로 바꾼다.
+
+```shell
+docker tag job-wq-2 gcr.io/<project>/job-wq-2
+gcloud docker -- push gcr.io/<project>/job-wq-2
+```
+
+## 잡 정의
+
+다음은 잡 정의이다.
+
+{{< codenew file="application/job/redis/job.yaml" >}}
+
+사용자 자신의 경로로 `gcr.io/myproject` 를
+변경하려면 잡 템플릿을 편집해야 한다.
+
+이 예에서, 각 파드는 대기열의 여러 항목에 대해 작업한 다음 더 이상 항목이 없을 때 종료된다.
+워커는 작업 대기열이 비어있을 때를 감지하고 잡 컨트롤러는 작업 대기열에 대해
+알지 못하기 때문에, 작업이 완료되면 워커에게 신호를 보낸다.
+워커는 성공적으로 종료하여 대기열이 비어 있음을 알린다. 따라서, 워커가 성공적으로
+종료하자마자, 컨트롤러는 작업이 완료되었음을 인식하고, 파드가 곧 종료된다.
+따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
+기다린다.
+
+## 잡 실행
+
+이제 잡을 실행한다.
+
+```shell
+kubectl apply -f ./job.yaml
+```
+
+이제 조금 기다린 다음, 잡을 확인한다.
+
+```shell
+kubectl describe jobs/job-wq-2
+Name:             job-wq-2
+Namespace:        default
+Selector:         controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+Labels:           controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+                  job-name=job-wq-2
+Annotations:      <none>
+Parallelism:      2
+Completions:      <unset>
+Start Time:       Mon, 11 Jan 2016 17:07:59 -0800
+Pods Statuses:    1 Running / 0 Succeeded / 0 Failed
+Pod Template:
+  Labels:       controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
+                job-name=job-wq-2
+  Containers:
+   c:
+    Image:              gcr.io/exampleproject/job-wq-2
+    Port:
+    Environment:        <none>
+    Mounts:             <none>
+  Volumes:              <none>
+Events:
+  FirstSeen    LastSeen    Count    From            SubobjectPath    Type        Reason            Message
+  ---------    --------    -----    ----            -------------    --------    ------            -------
+  33s          33s         1        {job-controller }                Normal      SuccessfulCreate  Created pod: job-wq-2-lglf8
+
+
+kubectl logs pods/job-wq-2-7r7b2
+Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
+Initial queue state: empty=False
+Working on banana
+Working on date
+Working on lemon
+```
+
+보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
+
+<!-- discussion -->
+
+## 대안
+
+대기열 서비스를 실행하거나 작업 대기열을 사용하도록 컨테이너를 수정하는 것이 불편한 경우, 다른
+[잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)
+중 하나를 고려할 수 있다.
+
+만약 실행할 백그라운드 처리 작업의 연속 스트림이 있는 경우,
+`ReplicaSet` 이 있는 백그라운드 워커를 실행하는 것과,
+[https://github.com/resque/resque](https://github.com/resque/resque)와 같은
+백그라운드 처리 라이브러리를 실행하는 것이 좋다.
diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md
new file mode 100644
index 0000000000..341739ba62
--- /dev/null
+++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md
@@ -0,0 +1,310 @@
+---
+title: 확장을 사용한 병렬 처리
+content_type: task
+min-kubernetes-server-version: v1.8
+weight: 20
+---
+
+<!-- overview -->
+
+이 태스크는 공통 템플릿을 기반으로 하는 여러 개의 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을
+실행하는 것을 보여준다. 이 접근 방식을 사용하여 일괄 작업을 병렬로 처리할 수
+있다.
+
+이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다.
+샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
+
+이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면
+[실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다.
+
+## {{% heading "prerequisites" %}}
+
+사용자는 기본적인 내용과, 병렬 작업이 아닌
+[잡](/ko/docs/concepts/workloads/controllers/job/) 사용에 대해 익숙해야 한다.
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+기본 템플릿을 사용하려면 커맨드 라인 유틸리티 `sed` 가 필요하다.
+
+고급 템플릿 예제를 따라하려면, [파이썬(Python)](https://www.python.org/)과
+파이썬용 Jinja2 템플릿 라이브러리의 설치가
+필요하다.
+
+파이썬을 설정했으면, 다음을 실행하여 Jinja2를 설치할 수 있다.
+
+```shell
+pip install --user jinja2
+```
+
+<!-- steps -->
+
+## 템플릿 기반의 잡 생성하기
+
+먼저, 다음의 잡 템플릿을 다운로드해서 `job-tmpl.yaml` 파일로 저장한다.
+다운로드할 내용은 다음과 같다.
+
+{{< codenew file="application/job/job-tmpl.yaml" >}}
+
+```shell
+# job-tmpl.yaml를 다운로드하기 위해 curl을 사용한다
+curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
+```
+
+다운로드한 파일은 아직 유효한 쿠버네티스
+{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}가 아니다.
+대신 해당 템플릿은 사용하기 전에 채워야하는 자리 표시자가 있는 잡 오브젝트의
+YAML 표현이다. `$ITEM` 구문은 쿠버네티스에 의미가 있지 않다.
+
+
+### 템플릿에서 매니페스트 생성하기
+
+다음의 셸 스니펫은 `sed` 를 사용하여 루프 변수로 `$ITEM` 문자열을 바꾸고,
+`jobs` 라는 임시 디렉터리에 기록한다. 다음과 같이 실행한다.
+
+```shell
+# 처리할 각 항목에 대해 하나씩, 템플릿을 여러 파일로 확장한다.
+mkdir ./jobs
+for i in apple banana cherry
+do
+  cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
+done
+```
+
+작동하는지 확인한다.
+
+```shell
+ls jobs/
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+job-apple.yaml
+job-banana.yaml
+job-cherry.yaml
+```
+
+모든 유형의 템플릿 언어(예를 들어, Jinja2, ERB)를 사용하거나,
+프로그램을 작성하여 잡 매니페스트를 생성할 수 있다.
+
+### 매니페스트에서 잡 생성하기
+
+다음으로, 하나의 kubectl 명령으로 모든 잡을 생성한다.
+
+```shell
+kubectl create -f ./jobs
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+job.batch/process-item-apple created
+job.batch/process-item-banana created
+job.batch/process-item-cherry created
+```
+
+이제, 작업을 확인한다.
+
+```shell
+kubectl get jobs -l jobgroup=jobexample
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+NAME                  COMPLETIONS   DURATION   AGE
+process-item-apple    1/1           14s        22s
+process-item-banana   1/1           12s        21s
+process-item-cherry   1/1           12s        20s
+```
+
+kubectl 명령에 `-l` 옵션을 사용하면 이 잡 그룹의
+일부인 잡만 선택된다(시스템에서 관련이 없는 다른 잡이 있을 수 있음).
+
+파드도 동일한 {{< glossary_tooltip text="레이블 셀렉터" term_id="selector" >}}를
+사용하여 확인할 수 있다.
+
+
+```shell
+kubectl get pods -l jobgroup=jobexample
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+NAME                        READY     STATUS      RESTARTS   AGE
+process-item-apple-kixwv    0/1       Completed   0          4m
+process-item-banana-wrsf7   0/1       Completed   0          4m
+process-item-cherry-dnfu9   0/1       Completed   0          4m
+```
+
+이 단일 명령을 사용하여 모든 잡의 출력을 한 번에 확인할 수 있다.
+
+```shell
+kubectl logs -f -l jobgroup=jobexample
+```
+
+출력 결과는 다음과 같아야 한다.
+
+```
+Processing item apple
+Processing item banana
+Processing item cherry
+```
+
+### 정리 {#cleanup-1}
+
+```shell
+# 생성한 잡 제거
+# 클러스터가 자동으로 잡의 파드들을 정리
+kubectl delete job -l jobgroup=jobexample
+```
+
+## 고급 템플릿 파라미터 사용하기
+
+[첫 번째 예제](#템플릿-기반의-잡-생성하기)에서, 템플릿의 각 인스턴스는 하나의
+파라미터를 가지고, 해당 파라미터는 잡의 이름에도 사용되었다. 그러나,
+[이름](/ko/docs/concepts/overview/working-with-objects/names/#names)은
+특정 문자들만 포함하도록 제한된다.
+
+이런 약간 더 복잡한 예제는 [Jinja 템플릿 언어](https://palletsprojects.com/p/jinja/)를
+사용하여 각 잡에 대한 여러 파라미터로 매니페스트를 생성한 다음
+해당 매니페스트에서 오브젝트를 생성한다.
+
+태스크의 이 부분에서는, 한줄 파이썬 스크립트를 사용하여
+매니페스트 집합으로 템플릿을 변환한다.
+
+먼저, 다음의 잡 오브젝트 템플릿을 복사하고 붙여넣기하여, `job.yaml.jinja2` 파일로 저장한다.
+
+
+```liquid
+{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
+                  { "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
+                  { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
+%}
+{%- for p in params %}
+{%- set name = p["name"] %}
+{%- set url = p["url"] %}
+---
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: jobexample-{{ name }}
+  labels:
+    jobgroup: jobexample
+spec:
+  template:
+    metadata:
+      name: jobexample
+      labels:
+        jobgroup: jobexample
+    spec:
+      containers:
+      - name: c
+        image: busybox
+        command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
+      restartPolicy: Never
+{%- endfor %}
+```
+
+위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해
+두 개의 파라미터를 정의한다. `for` 루프는 각 파라미터의 집합(나머지 행)에 대해
+하나의 잡 매니페스트를 방출한다.
+
+이 예제는 YAML의 기능에 의존한다. 하나의 YAML 파일은 여러
+문서(이 경우, 쿠버네티스 매니페스트)를 포함할 수 있으며, 행에 있는 `---` 로
+구분된다.
+출력 결과를 `kubectl` 에 직접 파이프를 사용해 잡을 생성할 수 있다.
+
+다음으로, 이 한 줄 파이썬 프로그램을 사용하여 템플릿을 확장한다.
+
+```shell
+alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
+```
+
+`render_template` 을 사용해서 파라미터와 템플릿을 쿠버네티스 매니페스트가
+포함된 하나의 YAML 파일로 변환한다.
+
+```shell
+# 앞에서 정의한 앨리어스(alias)가 필요하다
+cat job.yaml.jinja2 | render_template > jobs.yaml
+```
+
+`render_template` 스크립트가 제대로 동작하는지 확인하기 위해 `jobs.yaml` 을
+볼 수 있다.
+
+`render_template` 스크립트가 원하는대로 동작하는 것을 확인했다면,
+스크립트의 출력 결과를 파이프를 사용하여 `kubectl` 에 보낼 수 있다.
+
+```shell
+cat job.yaml.jinja2 | render_template | kubectl apply -f -
+```
+
+쿠버네티스는 생성한 잡을 수락하고 실행한다.
+
+### 정리 {#cleanup-2}
+
+```shell
+# 생성한 잡 제거
+# 클러스터가 자동으로 잡이 있던 파드를 정리
+kubectl delete job -l jobgroup=jobexample
+```
+
+
+<!-- discussion -->
+
+## 실제 워크로드에서 잡 사용하기
+
+실제 유스케이스에서, 각 잡은 동영상의 프레임을 렌더링하거나, 데이터베이스에서 행 범위를
+처리하는 것과 같은 상당한 규모의 계산을 수행한다. 동영상을 렌더링하는 경우 프레임 번호에
+`$ITEM` 을 설정한다. 데이터베이스에서 행을 처리하는
+경우, 처리할 데이터베이스 행의 범위를 나타내도록 `$ITEM` 을 설정한다.
+
+이번 태스크에서, 로그를 가져와 파드에서 출력 결과를 수집하는 명령어를
+실행했다. 실제 유스케이스에서, 잡의 각 파드는 완료하기 전에 출력 결과를
+내구성있는 스토리지에 기록한다. 각 잡에 대해 퍼시스턴트볼륨(PersistentVolume)을
+사용하거나 외장 스토리지 서비스를 사용할 수 있다. 예를 들어, 동영상의 프레임을 렌더링하는 경우,
+HTTP를 사용하여 렌더링된 프레임 데이터를 각 프레임에 대한 다른 URL을 사용해서 URL에  `PUT`
+한다.
+
+## 잡과 파드의 레이블
+
+잡을 생성한 후, 쿠버네티스는 한 잡의 파드를 다른 잡의 파드와 구별하기 위해서
+추가 {{< glossary_tooltip text="레이블" term_id="label" >}}을
+자동으로 추가한다.
+
+이 예시에서, 각 잡과 잡의 파드 템플릿은 `jobgroup=jobexample`
+레이블을 갖는다.
+
+쿠버네티스 자체는 `jobgroup` 이라는 레이블에 신경쓰지 않는다. 템플릿에서
+생성한 모든 잡에 대해 레이블을 설정하면 한번에 모든 잡을 편리하게
+조작할 수 있다.
+[첫 번째 예제](#템플릿-기반의-잡-생성하기)에서 템플릿을 사용해서
+여러 잡을 생성했다. 템플릿은 각 파드도 동일한 레이블을 가질 수 있도록 보장하므로,
+단일 명령어로 이러한 템플릿 기반 잡들의 모든 파드에서 확인할 수 있다.
+
+{{< note >}}
+레이블 키 `jobgroup` 은 특별하거나 예약되어 있지 않다.
+고유한 레이블링 체계를 선택할 수 있다.
+원하는 경우 사용할 수 있는
+[권장 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#레이블)이 있다.
+{{< /note >}}
+
+## 대안
+
+많은 수의 잡 오브젝트의 생성을 계획 중이라면, 아마도 다음의 사항을 파악하게 될 것이다.
+
+- 레이블을 사용해도, 너무 많은 잡을 관리하는 것은 번거롭다.
+- 일괄적으로 많은 잡을 생성하는 경우, 쿠버네티스 컨트롤 플레인에
+  높음 부하를 가할 수 있다. 대안으로, 쿠버네티스 API 서버가
+  속도를 제한하여 429 상태의 사용자 요청을 일시적으로 거부할 수 있다.
+- 사용자는 잡의 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}로
+  제한될 수 있다. 한번에 많은 작업을 생성하면 API 서버가 사용자의 요청 중
+  일부를 영구적으로 거부한다.
+
+아주 많은 잡 오브젝트를 생성하지 않고 많은 양의 작업을 처리하는데 사용할 수 있는
+다른 [잡 패턴](/ko/docs/concepts/workloads/controllers/job/#잡-패턴)도
+있다.
+
+잡 오브젝트를 자동으로 관리하기 위해 자체 [컨트롤러](/ko/docs/concepts/architecture/controller/)를
+작성하는 것도 고려할 수 있다.
diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md
index 925f174206..659836833a 100644
--- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md
@@ -10,17 +10,10 @@ weight: 10
 
 이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다.
 
-
-
-
 ## {{% heading "prerequisites" %}}
 
 * 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다.
 
-
-
-
-
 <!-- steps -->
 
 ## 데몬셋 업데이트 전략
@@ -164,7 +157,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
 
 {{< note >}}
 삭제된 파드가 컨트롤러에 의해 제어되지 않거나 파드가 복제되지 않은 경우 서비스 중단이
-발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)정책도 적용되지
+발생한다. 이 때 [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)정책도 적용되지
 않는다.
 {{< /note >}}
 
@@ -200,5 +193,3 @@ kubectl delete ds fluentd-elasticsearch -n kube-system
 * [태스크: 데몬셋에서 롤백
   수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다.
 * [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다.
-
-
diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
index 515b9c2cdd..ececc7beee 100644
--- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
+++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
@@ -115,4 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
 glossary_tooltip text="kube-apiserver"
 term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
 `HugePageStorageMediumSize` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
+게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 비활성화할 수 있다.
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
index f3b15d3206..26fa2830ff 100644
--- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -1005,5 +1005,5 @@ template:
 
 * [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
 * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
-* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
index ac7690a325..28655ed57b 100644
--- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -37,7 +37,7 @@ weight: 30
 지원한다. 쿠버네티스 오브젝트 타입에 익숙하지 않은 사용자가 인지할 수 있도록 커맨드
 이름이 지어졌다.
 
-- `run`: 하나 이상의 파드 내 컨테이너를 실행하도록 새로운 디플로이먼트 오브젝트를 생성한다.
+- `run`: 컨테이너를 실행할 새로운 파드를 생성한다.
 - `expose`: 파드에 걸쳐 트래픽을 로드 밸런스하도록 새로운 서비스 오브젝트를 생성한다.
 - `autoscale`: 디플로이먼트와 같이, 하나의 컨트롤러에 대해 자동으로 수평적 스케일이 이루어 지도록 새로운 Autoscaler 오브젝트를 생성한다.
 
@@ -167,5 +167,5 @@ kubectl create --edit -f /tmp/srv.yaml
 
 * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
 * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
-* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
index 49691c341b..9e4f8de774 100644
--- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -64,6 +64,18 @@ weight: 40
 
 * `kubectl delete -f <파일명|url>`
 
+{{< note >}}
+구성 파일이 `metadata` 섹션에서 `name` 필드 대신 `generateName`
+필드를 지정한 경우, `kubectl delete -f <filename|url>` 을 사용하여
+오브젝트를 삭제할 수 없다.
+오브젝트를 삭제하려면 다른 플래그를 사용해야 한다. 예를 들면, 다음과 같다.
+
+```shell
+kubectl delete <type> <name>
+kubectl delete <type> -l <label>
+```
+{{< /note >}}
+
 ## 오브젝트 확인 방법
 
 구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
@@ -150,5 +162,5 @@ template:
 
 * [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
 * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
-* [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
index 6a45b5a73b..91d97ee049 100644
--- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
+++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -7,7 +7,7 @@ weight: 20
 <!-- overview -->
 
 [Kustomize](https://github.com/kubernetes-sigs/kustomize)는
-[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을
+[kustomization 파일](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization)을
 통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다.
 
 1.14 이후로, kubectl도
@@ -832,6 +832,6 @@ deployment.apps "dev-my-nginx" deleted
 
 
 * [Kustomize](https://github.com/kubernetes-sigs/kustomize)
-* [Kubectl Book](https://kubectl.docs.kubernetes.io)
-* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
-* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+* [Kubectl 북](https://kubectl.docs.kubernetes.io)
+* [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
+* [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md
index 5364e7bebb..7265fd964e 100644
--- a/content/ko/docs/tasks/network/validate-dual-stack.md
+++ b/content/ko/docs/tasks/network/validate-dual-stack.md
@@ -13,7 +13,6 @@ content_type: task
 
 * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
 * 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)  (예. Kubenet 또는 Calico)
-* IPVS 모드로 구동되는 Kube-proxy
 * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
 
 {{< version-check >}}
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index b42f8952b8..c9c694e237 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -10,11 +10,9 @@ Horizontal Pod Autoscaler는
 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
 레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
 
-이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
-
-
-
-
+이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다.
+Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는
+[Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
 
 ## {{% heading "prerequisites" %}}
 
@@ -110,11 +108,7 @@ php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1
 
 
 ```shell
-kubectl run -it --rm load-generator --image=busybox /bin/sh
-
-Hit enter for command prompt
-
-while true; do wget -q -O- http://php-apache; done
+kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
 ```
 
 실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다.
@@ -388,7 +382,7 @@ object:
 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
 위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고,
 `Object` 대신에 `External` 메트릭 타입을 사용한다.
-만일 여러개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
+만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
 외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고,
 `Object` 타입을 사용할 때와 똑같이 동작한다.
 
@@ -457,12 +451,12 @@ Events:
 ## 부록: 수량
 
 HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
-쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다.
+쿠버네티스에서 사용하는
+{{< glossary_tooltip term_id="quantity" text="수량">}} 숫자 표기법을 사용한다.
 예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다.
 메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며,
 일반적으로 수량을 밀리단위로 반환한다.
 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다.
-더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다.
 
 ## 부록: 다른 가능한 시나리오
 
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
index 4afcb6927d..7a7d129525 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -406,6 +406,9 @@ behavior:
 
 마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
 전략을 추가할 수 있다.
+분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
+정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면
+자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.
 
 ```yaml
 behavior:
@@ -417,7 +420,7 @@ behavior:
     - type: Pods
       value: 5
       periodSeconds: 60
-    selectPolicy: Max
+    selectPolicy: Min
 ```
 
 ### 예시: 스케일 다운 비활성화
diff --git a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
index 8642c374af..f3debe8781 100644
--- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
+++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
@@ -47,7 +47,7 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
 동적 프로비저너에 의해서 충족된다.
 
 참고: config yaml 파일에 정의된 비밀번호는 안전하지 않다. 더 안전한 해결방법을 위해 
-[쿠버네티스 시크릿](/docs/concepts/configuration/secret/)
+[쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
 을 보자
 
 {{< codenew file="application/mysql/mysql-deployment.yaml" >}}
diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md
index 7f7422411c..b23bf2a600 100644
--- a/content/ko/docs/tasks/tls/certificate-rotation.md
+++ b/content/ko/docs/tasks/tls/certificate-rotation.md
@@ -10,7 +10,7 @@ content_type: task
 이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다.
 
 
-{{< feature-state for_k8s_version="v1.8" state="beta" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
 
 ## {{% heading "prerequisites" %}}
 
@@ -39,13 +39,11 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
 `kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라
 kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는
 `--rotate-certificates` 인자를 허용한다.
-인증서 갱신은 베타 기능이므로 기능 플래그는
-`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다.
 
 
 `kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는
-`--experimental-cluster-signing-duration` 인자를
-허용한다.
+`--cluster-signing-duration` (1.19 이전은 `--experimental-cluster-signing-duration`)
+인자를 허용한다.
 
 ## 인증서 갱신 구성에 대한 이해
 
@@ -62,7 +60,7 @@ kubectl get csr
 인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가
 자동으로 승인한 후 상태가 `Approved` 가 된다.
 다음으로, 컨트롤러 관리자는
-`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안
+`--cluster-signing-duration` 파라미터에 의해 지정된 기간 동안
 발행된 인증서에 서명하고
 서명된 인증서는 인증서 서명 요청에 첨부된다.
 
@@ -77,7 +75,3 @@ kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서
 kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다.
 그런 다음 새로운 인증서를 사용한 재연결을 위해서
 가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다.
-
-
-
-
diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md
index 8f45c8ddc2..9753772c5f 100755
--- a/content/ko/docs/tasks/tools/_index.md
+++ b/content/ko/docs/tasks/tools/_index.md
@@ -8,34 +8,41 @@ no_list: true
 ## kubectl
 
 쿠버네티스 커맨드 라인 도구인 `kubectl` 사용하면 쿠버네티스 클러스터에 대해 명령을
-실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
+실행할 수 있다. `kubectl` 을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
 관리하고, 로그를 볼 수 있다.
 
 클러스터에 접근하기 위해 `kubectl` 을 다운로드 및 설치하고 설정하는 방법에 대한 정보는
-[kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
+[`kubectl` 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을
+참고한다.
 
-`kubectl` 레퍼런스 문서를 읽어볼 수도 있다.
+<a class="btn btn-primary" href="/ko/docs/tasks/tools/install-kubectl/" role="button" aria-label="kubectl 설치 및 설정 가이드 보기">kubectl 설치 및 설정 가이드 보기</a>
 
-## Minikube
+[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를 읽어볼 수도 있다.
 
-[Minikube](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
-도구이다. Minikube는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
+## minikube
+
+[`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
+도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
 단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을
 수행할 수 있다.
 
-공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/)
-가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면
-[Minikube 설치](/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
+도구 설치에 중점을 두고 있다면 공식 사이트에서의
+[시작하기!](https://minikube.sigs.k8s.io/docs/start/)
+가이드를 따라 해볼 수 있다.
 
-Minikube가 작동하면, 이를 사용하여
-[샘플 애플리케이션을 실행](/docs/tutorials/hello-minikube/)해볼 수 있다.
+<a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/" role="button" aria-label="minikube 시작하기! 가이드 보기">minikube 시작하기! 가이드 보기</a>
+
+`minikube` 가 작동하면, 이를 사용하여
+[샘플 애플리케이션을 실행](/ko/docs/tutorials/hello-minikube/)해볼 수 있다.
 
 ## kind
 
-Minikube와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
-쿠버네티스를 실행할 수 있다. Minikuke와 달리, kind는 단일 컨테이너 런타임에서만 작동한다.
-kind는 [도커](https://docs.docker.com/get-docker/)를 설치하고
+`minikube` 와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
+쿠버네티스를 실행할 수 있다. `minikube` 와 달리, `kind` 는 단일 컨테이너 런타임에서만 작동한다.
+`kind` 는 [도커](https://docs.docker.com/get-docker/)를 설치하고
 구성해야 한다.
 
-[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 kind를 시작하고 실행하기 위해
+[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 `kind` 를 시작하고 실행하기 위해
 수행해야 하는 작업을 보여준다.
+
+<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/" role="button" aria-label="kind 시작하기 가이드 보기">kind 시작하기 가이드 보기</a>
diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md
index baf003f595..2f2e6c4fe0 100644
--- a/content/ko/docs/tasks/tools/install-kubectl.md
+++ b/content/ko/docs/tasks/tools/install-kubectl.md
@@ -9,13 +9,18 @@ card:
 ---
 
 <!-- overview -->
-쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/user-guide/kubectl/)을 사용하면, 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다.
+쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/reference/kubectl/kubectl/)을 사용하면,
+쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
+kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며
+로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는,
+[kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다.
 
 
 ## {{% heading "prerequisites" %}}
 
-클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
-
+클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다.
+예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다.
+최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
 
 <!-- steps -->
 
@@ -57,7 +62,7 @@ card:
 
 {{< tabs name="kubectl_install" >}}
 {{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
+sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
 echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
 sudo apt-get update
@@ -306,7 +311,12 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다.
 
 ## kubectl 구성 확인
 
-kubectl이 쿠버네티스 클러스터를 찾아 접근하려면, [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를 사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)이 필요하다. 기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
+kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
+[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를
+사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
+[kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)이
+필요하다.
+기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
 
 클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
 
@@ -513,6 +523,7 @@ compinit
 
 * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/)
 * 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다.
-* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
-* 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
+* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* 직접 생성하지 않은 클러스터에 접근해야하는 경우,
+  [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
 * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기
diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md
deleted file mode 100644
index 04c4ca64a6..0000000000
--- a/content/ko/docs/tasks/tools/install-minikube.md
+++ /dev/null
@@ -1,262 +0,0 @@
----
-title: Minikube 설치
-content_type: task
-weight: 20
-card:
-  name: tasks
-  weight: 10
----
-
-<!-- overview -->
-
-이 페이지는 단일 노드 쿠버네티스 클러스터를 노트북의 가상 머신에서 구동하는 도구인 [Minikube](/ko/docs/tutorials/hello-minikube)의 설치 방법을 설명한다.
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-{{< tabs name="minikube_before_you_begin" >}}
-{{% tab name="리눅스" %}}
-리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다.
-```
-grep -E --color 'vmx|svm' /proc/cpuinfo
-```
-{{% /tab %}}
-
-{{% tab name="맥OS" %}}
-맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다.
-```
-sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
-```
-만약 출력 중에 (색상으로 강조된) `VMX`를 볼 수 있다면, VT-x 기능이 머신에서 활성화된 것이다.
-{{% /tab %}}
-
-{{% tab name="윈도우" %}}
-윈도우 8 이후 버전에서 가상화 지원 여부를 확인하려면, 다음 명령어를 윈도우 터미널이나 명령 프롬프트에서 실행한다.
-```
-systeminfo
-```
-아래와 같은 내용을 볼 수 있다면, 윈도우에서 가상화를 지원한다.
-```
-Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
-                          Virtualization Enabled In Firmware: Yes
-                          Second Level Address Translation: Yes
-                          Data Execution Prevention Available: Yes
-```
-
-다음의 출력을 확인할 수 있다면, 이미 하이퍼바이저가 설치되어 있는 것으로 다음 단계를 건너 뛸 수 있다.
-```
-Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.
-```
-
-
-{{% /tab %}}
-{{< /tabs >}}
-
-
-
-<!-- steps -->
-
-## minikube 설치하기
-
-{{< tabs name="tab_with_md" >}}
-{{% tab name="리눅스" %}}
-
-### kubectl 설치
-
-kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#리눅스에-kubectl-설치)의 요령을 따라서 설치할 수 있다.
-
-## 하이퍼바이저(hypervisor) 설치
-
-하이퍼바이저를 설치하지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다.
-
-• [KVM](https://www.linux-kvm.org/), 또한 QEMU를 사용한다
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--driver=none` 옵션도 지원한다.
-이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경이 필요하지만, 하이퍼바이저는 필요하지 않다.
-
-데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우,
-Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다.
-[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다.
-
-{{< caution >}}
-`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다.
-`--driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다.
-{{< /caution >}}
-
-Minikube는 도커 드라이브와 비슷한 `vm-driver=podman` 도 지원한다. 슈퍼사용자 권한(root 사용자)으로 실행되는 Podman은 컨테이너가 시스템에서 사용 가능한 모든 기능에 완전히 접근할 수 있는 가장 좋은 방법이다.
-
-{{< caution >}}
-일반 사용자 계정은 컨테이너를 실행하는 데 필요한 모든 운영 체제 기능에 완전히 접근할 수 없기에 `podman` 드라이버는 컨테이너를 root로 실행해야 한다.
-{{< /caution >}}
-
-### 패키지를 이용하여 Minikube 설치
-
-Minikube를 위한 *실험적인* 패키지가 있다.
-리눅스 (AMD64) 패키지는 GitHub의 Minikube의 [릴리스](https://github.com/kubernetes/minikube/releases)에서 찾을 수 있다.
-
-적절한 패키지를 설치하기 위해 리눅스 배포판의 패키지 도구를 사용한다.
-
-### Minikube를 직접 다운로드하여 설치
-
-패키지를 통해 설치하지 못하였다면,
-바이너리 자체를 다운로드 받고 사용할 수 있다.
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
-  && chmod +x minikube
-```
-
-Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.
-
-```shell
-sudo mkdir -p /usr/local/bin/
-sudo install minikube /usr/local/bin/
-```
-
-### Homebrew를 이용해서 Minikube 설치하기
-
-또 다른 대안으로 리눅스 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다.
-
-```shell
-brew install minikube
-```
-
-{{% /tab %}}
-{{% tab name="맥OS" %}}
-### kubectl 설치
-
-kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#macos에-kubectl-설치)의 요령을 따라서 설치할 수 있다.
-
-### 하이퍼바이저(hypervisor) 설치
-
-하이퍼바이저를 설치하지 않았다면, 다음 중 하나를 지금 설치한다.
-
-• [HyperKit](https://github.com/moby/hyperkit)
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-• [VMware Fusion](https://www.vmware.com/products/fusion)
-
-### Minikube 설치
-가장 쉽게 맥OS에 Minikube를 설치하는 방법은 [Homebrew](https://brew.sh)를 이용하는 것이다.
-
-```shell
-brew install minikube
-```
-
-실행 바이너리를 다운로드 받아서 맥OS에 설치할 수도 있다.
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
-  && chmod +x minikube
-```
-
-Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.
-
-```shell
-sudo mv minikube /usr/local/bin
-```
-
-{{% /tab %}}
-{{% tab name="윈도우" %}}
-### kubectl 설치하기
-
-kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#windows에-kubectl-설치)의 요령을 따라서 설치할 수 있다.
-
-### 하이퍼바이저(hypervisor) 설치하기
-
-하이퍼바이저가 설치 안 되어 있다면 아래중 하나를 지금 설치한다.
-
-• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-{{< note >}}
-Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows 10 Enterprise, Windows 10 Professional, Windows 10 Education.
-{{< /note >}}
-
-### Chocolatey를 이용한 Minikube 설치
-
-윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행).
-
-```shell
-choco install minikube
-```
-
-Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다.
-
-### 인스톨러 실행파일을 통한 Minikube 설치
-
-[윈도우 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)를 사용하여 윈도우에 Minikube를 수동으로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다.
-
-### 직접 다운로드하여 Minikube 설치
-
-윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 다운로드 받아서, 파일 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## 설치 확인
-
-하이퍼바이저와 Minikube의 성공적인 설치를 확인하려면, 다음 명령어를 실행해서 로컬 쿠버네티스 클러스터를 시작할 수 있다.
-
-{{< note >}}
-
-`minikube start` 시 `--driver` 를 설정하려면, 아래에 `<driver_name>` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 지정하기 문서](/ko/docs/setup/learning-environment/minikube/#vm-드라이버-지정하기)에서 확인할 수 있다.
-
-{{< /note >}}
-
-{{< caution >}}
-KVM을 사용할 때 Debian과 다른 시스템에서 libvirt의 기본 QEMU URI는 `qemu:///session`이고, Minikube의 기본 QEMU URI는 `qemu:///system`이다. 시스템이 이런 환경이라면, `--kvm-qemu-uri qemu:///session`을 `minikube start`에 전달해야 한다.
-{{< /caution >}}
-
-```shell
-minikube start --driver=<driver_name>
-```
-
-`minikube start` 가 완료되면, 아래 명령을 실행해서 클러스터의 상태를 확인한다.
-
-```shell
-minikube status
-```
-
-만약 클러스터가 실행 중이면, `minikube status` 의 출력은 다음과 유사해야 한다.
-
-```
-host: Running
-kubelet: Running
-apiserver: Running
-kubeconfig: Configured
-```
-
-Minikube가 선택한 하이퍼바이저와 작동하는지 확인한 후에는, Minikube를 계속 사용하거나 클러스터를 중지할 수 있다. 클러스터를 중지하려면 다음을 실행한다.
-
-```shell
-minikube stop
-```
-
-## 새롭게 시작하기 위해 모두 정리하기 {#cleanup-local-state}
-
-이전에 Minikube를 설치했었다면, 다음을 실행한다.
-```shell
-minikube start
-```
-
-그리고 `minikube start`는 에러를 보여준다.
-```shell
-machine does not exist
-```
-
-이제 구성 파일을 삭제해야 한다.
-```shell
-minikube delete
-```
-
-## {{% heading "whatsnext" %}}
-
-
-* [Minikube로 로컬에서 쿠버네티스 실행하기](/ko/docs/setup/learning-environment/minikube/)
diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md
index 803b58594c..74008f9961 100644
--- a/content/ko/docs/tutorials/clusters/apparmor.md
+++ b/content/ko/docs/tutorials/clusters/apparmor.md
@@ -1,6 +1,7 @@
 ---
-title: AppArmor
+title: AppArmor를 사용하여 리소스에 대한 컨테이너의 접근 제한
 content_type: tutorial
+weight: 10
 ---
 
 
@@ -77,7 +78,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한
 
 3. 컨테이너 런타임이 AppArmor을 지원한다. -- 현재 모든 일반적인 쿠버네티스를 지원하는
 {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="cri-o" >}} 또는
-{{< glossary_tooltip term_id="containerd" >}} 와 같은 컨테이너 런타임들은 AppArmor를 지원해야 한다. 
+{{< glossary_tooltip term_id="containerd" >}} 와 같은 컨테이너 런타임들은 AppArmor를 지원해야 한다.
 이 런타임 설명서를 참조해서 클러스터가 AppArmor를 사용하기 위한
 요구 사항을 충족하는지 확인해야 한다.
 
@@ -469,5 +470,3 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 
 * [퀵 가이드 AppArmor 프로파일 언어](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
 * [AppArmor 코어 정책 참고](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
-
-
diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md
index 35b4365eb2..699902295e 100644
--- a/content/ko/docs/tutorials/hello-minikube.md
+++ b/content/ko/docs/tutorials/hello-minikube.md
@@ -118,7 +118,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
     ```
 
 {{< note >}}
-    `kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자.
+`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자.
 {{< /note >}}
 
 ## 서비스 만들기
@@ -137,6 +137,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
     `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기
     원한다는 뜻이다.
 
+    `k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
+    사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
+
 2. 방금 생성한 서비스 살펴보기
 
     ```shell
diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index 1dc1733cf8..d9d621d867 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,10 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 화면이 너무 좁아 터미널과 상호작용할 수 없습니다. 데스크톱/태블릿을 사용해주세요.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/1"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                 data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab"
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
index 6f0fb013d6..e2296b84bf 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
@@ -35,7 +35,7 @@ weight: 10
                     방식으로 패키지할 필요가 있다. 즉, 컨테이너화 해야 한다. 컨테이너화된 애플리케이션은 호스트에
                     매우 깊이 통합된 패키지로써, 특정 머신에 직접 설치되는 예전의 배포 모델보다 유연하고 가용성이 높다.
                     <b>쿠버네티스는 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 보다 효율적으로
-                        자동화한다.</b> 
+                        자동화한다.</b>
                     쿠버네티스는 오픈소스 플랫폼이고 운영 수준의 안정성을 가졌다.
                 </p>
                 <p>쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.
@@ -56,7 +56,7 @@ weight: 10
                 </div>
                 <div class="content__box content__box_fill">
                     <p><i>
-                        쿠버네티스는 컴퓨터 클러스터에 걸쳐서 애플리케이션 컨테이너의 위치(스케줄링)와 실행을 
+                        쿠버네티스는 컴퓨터 클러스터에 걸쳐서 애플리케이션 컨테이너의 위치(스케줄링)와 실행을
                         오케스트레이션하는 운영 수준의 오픈소스 플랫폼이다.
                     </i></p>
                 </div>
@@ -84,7 +84,7 @@ weight: 10
                     클러스터 내 모든 활동을 조율한다.</p>
                 <p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로써 동작하는 VM 또는 물리적인 컴퓨터다.</b>
                     각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는
-                    컨테이너 운영을 담당하는 Docker 또는 rkt와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스
+                    컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스
                     클러스터는 최소 세 대의 노드를 가져야한다.</p>
 
             </div>
@@ -103,10 +103,10 @@ weight: 10
                     사용해서 클러스터와 상호작용할 수 있다.</p>
 
                 <p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면
-                    Minikube를 사용할 수 있다. Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 
-                    클러스터를 배포하는 가벼운 쿠버네티스 구현체다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 
-                    구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 
-                    부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 
+                    Minikube를 사용할 수 있다. Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한
+                    클러스터를 배포하는 가벼운 쿠버네티스 구현체다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서
+                    구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인
+                    부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는
                     온라인 터미널을 사용할 것이다.</p>
 
                 <p>이제 쿠버네티스가 무엇인지 알아봤으니, 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index e2b8098b9e..2cf9daa6e1 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -31,10 +31,7 @@ weight: 20
                 터미널로 상호 작용하기 위해서, 데스크탑/태블릿 버전을 사용해주세요
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/7"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                 data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab"
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index 01e7fcbf11..f82846a390 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,10 +24,7 @@ weight: 20
                 터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다.
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/4"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                 data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab"
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html
index 8fa348393e..2e34002571 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html
@@ -29,7 +29,7 @@ weight: 10
 
             <div class="col-md-8">
                 <h2>쿠버네티스 파드</h2>
-                <p>모듈 <a href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 <b>파드</b>를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:</p>
+                <p>모듈 <a href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 <b>파드</b>를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:</p>
                 <ul>
                     <li>볼륨과 같은, 공유 스토리지</li>
                     <li>클러스터 IP 주소와 같은, 네트워킹</li>
@@ -51,7 +51,7 @@ weight: 10
                 </div>
                 <div class="content__box content__box_fill">
                         <p><i>
-                          파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커 또는 rkt와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다.
+                          파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다.
                         </i></p>
                 </div>
             </div>
@@ -79,7 +79,7 @@ weight: 10
                 <p>모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.</p>
                 <ul>
                     <li>Kubelet은, 쿠버네티스 마스터와 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.</li>
-                    <li>(도커, rkt)와 같은 컨테이너 런타임은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다. </li>
+                    <li>컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다. </li>
                 </ul>
 
             </div>
@@ -123,7 +123,7 @@ weight: 10
             </div>
             <div class="col-md-4">
                 <div class="content__box content__box_fill">
-                    <p><i> 노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러개의 파드는 하나의 노드 위에서 동작할 수 있다.</i></p>
+                    <p><i> 노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러 개의 파드는 하나의 노드 위에서 동작할 수 있다.</i></p>
                 </div>
             </div>
         </div>
diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index f81c1fd09a..bfbb0eb1c8 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index a4e3aa4ed1..31c1d859a2 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,10 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 터미널로 상호 작용하기 위해서, 데스크탑/태블릿 버전을 사용해주세요
             </div>
-            <div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/5"
-                 data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false"
-                 data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab"
-                 data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 029acc6331..24da082b89 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 터미널과 상호작용하기 위해, 데스크탑/태블릿 버전을 이용한다.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md
index 382f096375..9d47599589 100644
--- a/content/ko/docs/tutorials/services/source-ip.md
+++ b/content/ko/docs/tutorials/services/source-ip.md
@@ -150,7 +150,7 @@ ip addr
 
 그런 다음 `wget` 을 사용해서 로컬 웹 서버에 쿼리한다.
 ```shell
-# 10.0.170.92를 파드의 IPv4 주소로 변경한다.
+# "10.0.170.92"를 "clusterip"라는 이름의 서비스의 IPv4 주소로 변경한다.
 wget -qO - 10.0.170.92
 ```
 ```
@@ -409,10 +409,10 @@ client_address=198.51.100.79
 끝나는 패킷 전달자를 이용한다.
 
 첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해
-HTTP [Forwarded]](https://tools.ietf.org/html/rfc7239#section-5.2)
+HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)
 또는 [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)
 헤더 또는
-[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과
+[프록시 프로토콜](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과
 같은 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다.
 두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는
 HTTP 헬스 체크를 생성하여
diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
index c7d57d8633..047fb9b6dd 100644
--- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -85,6 +85,8 @@ statefulset.apps/web created
 
 ```shell
 kubectl get service nginx
+```
+```
 NAME      TYPE         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
 nginx     ClusterIP    None         <none>        80/TCP    12s
 ```
@@ -92,6 +94,7 @@ nginx     ClusterIP    None         <none>        80/TCP    12s
 ```shell
 kubectl get statefulset web
 ```
+```
 NAME      DESIRED   CURRENT   AGE
 web       2         1         20s
 ```
@@ -1023,7 +1026,7 @@ web-1
 다시 생성되고 `web-0`과 `web-1`은 계속
 각 호스트네임을 제공한다.
 
-최종적으로 `web` 스테이트풀셋을 삭제한다.
+최종적으로 `nginx` 서비스를 삭제한다.
 
 ```shell
 kubectl delete service nginx
@@ -1031,7 +1034,7 @@ kubectl delete service nginx
 ```
 service "nginx" deleted
 ```
-그리고 `nginx` 서비스를 삭제한다.
+그리고 `web` 스테이트풀셋을 삭제한다.
 ```shell
 kubectl delete statefulset web
 ```
diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md
index ea6b3063cc..33fdcb4dbe 100644
--- a/content/ko/docs/tutorials/stateful-application/cassandra.md
+++ b/content/ko/docs/tutorials/stateful-application/cassandra.md
@@ -7,9 +7,13 @@ weight: 30
 
 
 <!-- overview -->
-이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다.
+이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다.
+데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_).
+이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다.
 
-*스테이트풀셋* 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 참조한다.
+*스테이트풀셋* 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다.
+이 튜토리얼에서 이용할 기능의 자세한 정보는
+[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 참조한다.
 
 {{< note >}}
 카산드라와 쿠버네티스는 클러스터 맴버라는 의미로 _노드_ 라는 용어를 사용한다. 이
@@ -38,12 +42,17 @@ weight: 30
 
 {{< include "task-tutorial-prereqs.md" >}}
 
-이 튜토리얼을 완료하려면 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip text="서비스" term_id="service" >}}, {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다.
+이 튜토리얼을 완료하려면,
+{{< glossary_tooltip text="파드" term_id="pod" >}},
+{{< glossary_tooltip text="서비스" term_id="service" >}},
+{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다.
 
 ### 추가적인 Minikube 설정 요령
 
 {{< caution >}}
-[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자.
+[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다.
+이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가
+발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자.
 
 ```shell
 minikube start --memory 5120 --cpus=4
@@ -51,11 +60,11 @@ minikube start --memory 5120 --cpus=4
 {{< /caution >}}
 
 
-
 <!-- lessoncontent -->
 ## 카산드라를 위한 헤드리스 서비스 생성하기 {#creating-a-cassandra-headless-service}
 
-쿠버네티스 에서 {{< glossary_tooltip text="서비스" term_id="service" >}}는 동일 작업을 수행하는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 집합을 기술한다.
+쿠버네티스 에서 {{< glossary_tooltip text="서비스" term_id="service" >}}는 동일 작업을 수행하는
+{{< glossary_tooltip text="파드" term_id="pod" >}}의 집합을 기술한다.
 
 다음의 서비스는 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다.
 
@@ -83,14 +92,17 @@ NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
 cassandra   ClusterIP   None         <none>        9042/TCP   45s
 ```
 
-이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한 [서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를 읽어보자.
+`cassandra` 서비스가 보이지 않는다면, 이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한
+[서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를
+읽어보자.
 
 ## 카산드라 링을 생성하는 스테이트풀셋 이용하기
 
 스테이트풀셋 매니페스트에는 다음을 포함하는데 3개 파드로 구성된 카산드라 링을 생성한다.
 
 {{< note >}}
-이 예는 Minikube를 위한 기본 프로비저너이다. 다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다.
+이 예는 Minikube를 위한 기본 프로비저너이다.
+다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다.
 {{< /note >}}
 
 {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
@@ -182,12 +194,13 @@ kubectl apply -f cassandra-statefulset.yaml
     kubectl edit statefulset cassandra
     ```
 
-    이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다. 다음 예제는 스테이트풀셋 파일에서 발췌했다.
+    이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다.
+    다음 예제는 스테이트풀셋 파일에서 발췌했다.
 
     ```yaml
-    # Please edit the object below. Lines beginning with a '#' will be ignored,
-    # and an empty file will abort the edit. If an error occurs while saving this file will be
-    # reopened with the relevant failures.
+    # 다음의 오브젝트를 수정한다. '#'로 시작하는 행은 무시되고,
+    # 빈 파일은 편집을 중단한다. 저장할 때 오류가 발생하면 이 파일이
+    # 관련 실패와 함께 다시 열린다.
     #
     apiVersion: apps/v1
     kind: StatefulSet
@@ -225,10 +238,12 @@ kubectl apply -f cassandra-statefulset.yaml
 
 ## {{% heading "cleanup" %}}
 
-스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다. 당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다.
+스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다.
+당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다.
 
 {{< warning >}}
-스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도 삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자.
+스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도
+삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자.
 {{< /warning >}}
 
 1. 다음 명령어(한 줄로 연결된)를 실행하여 카산드라 스테이트풀셋을 모두 제거하자.
@@ -271,6 +286,3 @@ kubectl apply -f cassandra-statefulset.yaml
 * 어떻게 [스테이트풀셋 스케일](/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다.
 * [*쿠버네티스시드제공자*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)에 대해 더 살펴본다.
 * 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다.
-
-
-
diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
index 1e0aefd4a3..7c3721d72c 100644
--- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -2,7 +2,7 @@
 title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기"
 content_type: tutorial
 weight: 20
-card: 
+card:
   name: tutorials
   weight: 40
   title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨"
@@ -13,7 +13,7 @@ card:
 <!-- overview -->
 이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다.
 
-[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.
+[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/ko/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.
 
 {{< warning >}}
 이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자.
@@ -76,7 +76,7 @@ MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필
 ## kustomization.yaml 생성하기
 
 ### 시크릿 생성자 추가
-[시크릿](/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다.
+[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다.
 
 다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다.
 
@@ -98,7 +98,7 @@ EOF
 다음의 매니페스트는 단일-인스턴스 WordPress 디플로이먼트를 기술한다. WordPress 컨테이너는
 웹사이트 데이터 파일을 위해 `/var/www/html`에 퍼시스턴트볼륨을 마운트한다. `WORDPRESS_DB_HOST` 환경 변수에는
 위에서 정의한 MySQL 서비스의 이름이 설정되며, WordPress는 서비스를 통해 데이터베이스에 접근한다.
-`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다. 
+`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다.
 
 {{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
 
@@ -107,13 +107,13 @@ EOF
       ```shell
       curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
       ```
-            
+
 2. WordPress 구성 파일을 다운로드한다.
 
       ```shell
       curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
       ```
-      
+
 3. 두 파일을 `kustomization.yaml`에 추가하자.
 
 ```shell
@@ -151,7 +151,7 @@ kubectl apply -k ./
       ```shell
       kubectl get pvc
       ```
-      
+
       {{< note >}}
       PV를 프로비저닝하고 정착(bound)시키는데 수 분이 걸릴 수 있다.
       {{< /note >}}
@@ -240,6 +240,3 @@ kubectl apply -k ./
 * [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자.
 * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
 * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
-
-
-
diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md
index a253f04a0b..8e17a85527 100644
--- a/content/ko/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md
@@ -7,25 +7,23 @@ weight: 40
 <!-- overview -->
 이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org)
 쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과
-[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과
-[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
-
+[PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)과
+[파드안티어피니티(PodAntiAffinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
 
 ## {{% heading "prerequisites" %}}
 
-
 이 튜토리얼을 시작하기 전에
 다음 쿠버네티스 개념에 친숙해야 한다.
 
--   [파드](/docs/user-guide/pods/single-container/)
+-   [파드](/ko/docs/concepts/workloads/pods/)
 -   [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
 -   [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
 -   [퍼시스턴트볼륨](/ko/docs/concepts/storage/volumes/)
 -   [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 -   [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
--   [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
--   [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)
--   [kubectl CLI](/docs/user-guide/kubectl/)
+-   [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
+-   [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
+-   [kubectl CLI](/docs/reference/kubectl/kubectl/)
 
 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
 
@@ -42,7 +40,7 @@ weight: 40
 -   어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
 -   어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가.
 -   어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
--   어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
+-   어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
 
 
 <!-- lessoncontent -->
@@ -63,17 +61,17 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변
 
 ## ZooKeeper 앙상블 생성하기
 
-아래 메니페스트에는
+아래 매니페스트에는
 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스),
 [서비스](/ko/docs/concepts/services-networking/service/),
-[파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
+[PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets),
 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다.
 
 {{< codenew file="application/zookeeper/zookeeper.yaml" >}}
 
 터미널을 열고
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 명령어로
-메니페스트를 생성하자.
+매니페스트를 생성하자.
 
 ```shell
 kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
@@ -118,7 +116,7 @@ zk-2      1/1       Running   0         40s
 ```
 
 스테이트풀셋 컨트롤러는 3개의 파드를 생성하고, 각 파드는
-[ZooKeeper](http://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다.
+[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다.
 
 
 ### 리더 선출 촉진
@@ -339,7 +337,7 @@ zk-0      0/1       Terminating   0         11m
 zk-0      0/1       Terminating   0         11m
 ```
 
-`zookeeper.yaml` 메니페스트를 다시 적용한다.
+`zookeeper.yaml` 매니페스트를 다시 적용한다.
 
 ```shell
 kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
@@ -446,7 +444,7 @@ volumeMounts:
 
 `zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을
 ZooKeeper의 서버 디렉터리에 마운트한다.
-파드를 재스케쥴할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와
+파드를 재스케줄할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와
 모든 그 스냅샷도 내구성을 유지한다.
 
 ## 일관된 구성 보장하기
@@ -456,7 +454,7 @@ ZooKeeper의 서버 디렉터리에 마운트한다.
 ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다.
 또한 Zab 프로토콜의 일관된 설정도
 네트워크에 걸쳐 올바르게 동작하기 위해서
-필요하다. 이 예시에서는 메니페스트에 구성을 직접 포함시켜서 일관된 구성을
+필요하다. 이 예시에서는 매니페스트에 구성을 직접 포함시켜서 일관된 구성을
 달성한다.
 
 `zk` 스테이트풀셋을 살펴보자.
@@ -495,7 +493,7 @@ ZooKeeper 서버를 시작하는데 사용한 명령어는 커맨드라인 파
 ### 로깅 설정하기
 
 `zkGenConfig.sh` 스크립트로 생성된 파일 중 하나는 ZooKeeper의 로깅을 제어한다.
-ZooKeeper는 [Log4j](http://logging.apache.org/log4j/2.x/)를 이용하며
+ZooKeeper는 [Log4j](https://logging.apache.org/log4j/2.x/)를 이용하며
 기본 로깅 구성으로는 시간과 파일 크기 기준의 롤링 파일 어펜더를 사용한다.
 
  `zk` `스테이트풀셋`의 한 파드에서 로깅 설정을 살펴보는 아래 명령어를 이용하자.
@@ -517,7 +515,10 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
 log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
 ```
 
-이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다. 표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다. 또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여 로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다.
+이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다.
+표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다.
+또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여
+로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다.
 
 파드의 마지막 20줄의 로그를 가져오는 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) 명령을 이용하자.
 
@@ -787,7 +788,7 @@ zk-0      1/1       Running   1         1h
 
 ### 준비도 테스트
 
-준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케쥴링되고 건강하다.
+준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케줄링되고 건강하다.
 프로세스가 준비되면 입력을 처리할 수 있다. 활성도는 필수적이나 준비도의 조건으로는
 충분하지 않다. 몇몇 경우
 특별히 초기화와 종료 시에 프로세스는 살아있지만
@@ -796,7 +797,7 @@ zk-0      1/1       Running   1         1h
 준비도 검사를 지정하면, 쿠버네티스는 준비도가 통과할 때까지
 애플리케이션 프로세스가 네트워크 트래픽을 수신하지 않게 한다.
 
-ZooKeeper 서버에서는 준비도가 활성도를 내포한다. 그러므로 `zookeeper.yaml` 메니페스트에서
+ZooKeeper 서버에서는 준비도가 활성도를 내포한다. 그러므로 `zookeeper.yaml` 매니페스트에서
 준비도 검사는 활성도 검사와 동일하다.
 
 ```yaml
@@ -823,7 +824,9 @@ ZooKeeper는 변조된 데이터를 성공적으로 커밋하기 위한 서버
 중단을 방지하기 위해 개별 시스템의 손실로 인해 모범 사례에서는 동일한 시스템에
 여러 인스턴스의 응용 프로그램을 함께 배치하는 것을 배제한다.
 
-기본적으로 쿠버네티스는 동일 노드상에 `스테이트풀셋`의 파드를 위치시킬 수 있다. 생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고 ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케쥴링될 때까지 작동 중단을 경험할 것이다.
+기본적으로 쿠버네티스는 동일 노드상에 `스테이트풀셋`의 파드를 위치시킬 수 있다.
+생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고
+ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케줄링될 때까지 작동 중단을 경험할 것이다.
 
 노드 실패하는 사건 중에도 중요 시스템의 프로세스가 재스케줄될 수 있게
 항상 추가적인 용량을 프로비전해야 한다. 그렇게 하면 쿠버네티스 스케줄러가
@@ -909,7 +912,7 @@ zk-pdb    N/A             1                 1
 kubectl get pods -w -l app=zk
 ```
 
-다른 터미널에서 현재 스케쥴되는 파드의 노드를 살펴보자.
+다른 터미널에서 현재 스케줄되는 파드의 노드를 살펴보자.
 
 ```shell
 for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
@@ -921,7 +924,7 @@ kubernetes-node-ixsl
 kubernetes-node-i4c4
 ```
 
-`zk-0`파드가 스케쥴되는 노드를 통제하기 위해
+`zk-0`파드가 스케줄되는 노드를 통제하기 위해
 [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)를 이용하자.
 
 ```shell
@@ -937,7 +940,7 @@ node "kubernetes-node-group-pb41" drained
 ```
 
 클러스터에 4개 노드가 있기 때문에 `kubectl drain`이 성공하여
-`zk-0`을 다른 노드로 재스케쥴링 된다.
+`zk-0`을 다른 노드로 재스케줄링 된다.
 
 ```
 NAME      READY     STATUS    RESTARTS   AGE
@@ -957,7 +960,7 @@ zk-0      1/1       Running   0         1m
 ```
 
 계속해서 `스테이트풀셋`의 파드를 첫 터미널에서 지켜보고
-`zk-1` 이 스케쥴된 노드를 비워보자.
+`zk-1` 이 스케줄된 노드를 비워보자.
 
 ```shell
 kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
@@ -969,7 +972,8 @@ pod "zk-1" deleted
 node "kubernetes-node-ixsl" drained
 ```
 
-`zk-1` 파드는 스케쥴되지 않는데 이는 `zk` `스테이트풀셋`이 오직 2개 노드가 스케쥴되도록 파드를 위치시키는 것을 금하는 `파드안티어피니티` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다.
+`zk-1` 파드는 스케줄되지 않는데 이는 `zk` `StatefulSet`이 오직 2개 노드가 스케줄되도록 파드를 위치시키는 것을 금하는
+`PodAntiAffinity` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다.
 
 ```shell
 kubectl get pods -w -l app=zk
@@ -1051,7 +1055,7 @@ kubectl uncordon kubernetes-node-pb41
 node "kubernetes-node-pb41" uncordoned
 ```
 
-`zk-1`은 이 노드에서 재스케쥴된다. `zk-1`이 Running과 Ready가 될 때까지 기다리자.
+`zk-1`은 이 노드에서 재스케줄된다. `zk-1`이 Running과 Ready가 될 때까지 기다리자.
 
 ```shell
 kubectl get pods -w -l app=zk
@@ -1083,7 +1087,7 @@ zk-1      0/1       Running   0         13m
 zk-1      1/1       Running   0         13m
 ```
 
-`zk-2`가 스케쥴된 노드를 비워보자.
+`zk-2`가 스케줄된 노드를 비워보자.
 
 ```shell
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
@@ -1111,7 +1115,10 @@ kubectl uncordon kubernetes-node-ixsl
 node "kubernetes-node-ixsl" uncordoned
 ```
 
-`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
+`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다.
+drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면
+서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다.
+파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
 
 
 ## {{% heading "cleanup" %}}
diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
index 9d5cf7713b..cc02b6651d 100644
--- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
+++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
@@ -58,23 +58,15 @@ kubectl create clusterrolebinding cluster-admin-binding \
 ## kube-state-metrics 설치
 
 [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다.
-
-### kube-state-metrics 실행 여부 확인
-```shell
-kubectl get pods --namespace=kube-system | grep kube-state
-```
-### 필요하면 kube-state-metrics 설치
-
 ```shell
 git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
 kubectl apply -f kube-state-metrics/examples/standard
-kubectl get pods --namespace=kube-system | grep kube-state-metrics
-```
-kube-state-metrics이 실행 중이고 준비되었는지 확인한다.
-```shell
-kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics
 ```
 
+### kube-state-metrics 실행 여부 확인
+```shell
+kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
+```
 출력
 ```shell
 NAME                                 READY   STATUS    RESTARTS   AGE
diff --git a/content/ko/examples/application/guestbook/redis-master-service.yaml b/content/ko/examples/application/guestbook/redis-master-service.yaml
index a484014f1f..65cef2191c 100644
--- a/content/ko/examples/application/guestbook/redis-master-service.yaml
+++ b/content/ko/examples/application/guestbook/redis-master-service.yaml
@@ -8,7 +8,8 @@ metadata:
     tier: backend
 spec:
   ports:
-  - port: 6379
+  - name: redis
+    port: 6379
     targetPort: 6379
   selector:
     app: redis
diff --git a/content/ko/examples/application/job/job-tmpl.yaml b/content/ko/examples/application/job/job-tmpl.yaml
new file mode 100644
index 0000000000..790025b38b
--- /dev/null
+++ b/content/ko/examples/application/job/job-tmpl.yaml
@@ -0,0 +1,18 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: process-item-$ITEM
+  labels:
+    jobgroup: jobexample
+spec:
+  template:
+    metadata:
+      name: jobexample
+      labels:
+        jobgroup: jobexample
+    spec:
+      containers:
+      - name: c
+        image: busybox
+        command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
+      restartPolicy: Never
diff --git a/content/ko/examples/application/job/rabbitmq/job.yaml b/content/ko/examples/application/job/rabbitmq/job.yaml
new file mode 100644
index 0000000000..4e1a61892b
--- /dev/null
+++ b/content/ko/examples/application/job/rabbitmq/job.yaml
@@ -0,0 +1,20 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: job-wq-1
+spec:
+  completions: 8
+  parallelism: 2
+  template:
+    metadata:
+      name: job-wq-1
+    spec:
+      containers:
+      - name: c
+        image: gcr.io/<project>/job-wq-1
+        env:
+        - name: BROKER_URL
+          value: amqp://guest:guest@rabbitmq-service:5672
+        - name: QUEUE
+          value: job1
+      restartPolicy: OnFailure
diff --git a/content/ko/examples/application/job/rabbitmq/worker.py b/content/ko/examples/application/job/rabbitmq/worker.py
new file mode 100644
index 0000000000..e2f0ae5c20
--- /dev/null
+++ b/content/ko/examples/application/job/rabbitmq/worker.py
@@ -0,0 +1,7 @@
+#!/usr/bin/env python
+
+# 표준 출력만 출력하고 10초 동안 대기한다.
+import sys
+import time
+print("Processing " + sys.stdin.readlines()[0])
+time.sleep(10)
diff --git a/content/ko/examples/application/job/redis/job.yaml b/content/ko/examples/application/job/redis/job.yaml
new file mode 100644
index 0000000000..ee7a06c732
--- /dev/null
+++ b/content/ko/examples/application/job/redis/job.yaml
@@ -0,0 +1,14 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: job-wq-2
+spec:
+  parallelism: 2
+  template:
+    metadata:
+      name: job-wq-2
+    spec:
+      containers:
+      - name: c
+        image: gcr.io/myproject/job-wq-2
+      restartPolicy: OnFailure
diff --git a/content/ko/examples/application/job/redis/worker.py b/content/ko/examples/application/job/redis/worker.py
new file mode 100644
index 0000000000..b8abbee917
--- /dev/null
+++ b/content/ko/examples/application/job/redis/worker.py
@@ -0,0 +1,23 @@
+#!/usr/bin/env python
+
+import time
+import rediswq
+
+host="redis"
+# Uncomment next two lines if you do not have Kube-DNS working.
+# import os
+# host = os.getenv("REDIS_SERVICE_HOST")
+
+q = rediswq.RedisWQ(name="job2", host="redis")
+print("Worker with sessionID: " +  q.sessionID())
+print("Initial queue state: empty=" + str(q.empty()))
+while not q.empty():
+  item = q.lease(lease_secs=10, block=True, timeout=2) 
+  if item is not None:
+    itemstr = item.decode("utf-8")
+    print("Working on " + itemstr)
+    time.sleep(10) # Put your actual work here instead of sleep.
+    q.complete(item)
+  else:
+    print("Waiting for work")
+print("Queue empty, exiting")
diff --git a/content/ko/examples/pods/init-containers.yaml b/content/ko/examples/pods/init-containers.yaml
index ad96425dd5..e83beec9af 100644
--- a/content/ko/examples/pods/init-containers.yaml
+++ b/content/ko/examples/pods/init-containers.yaml
@@ -19,7 +19,7 @@ spec:
     - wget
     - "-O"
     - "/work-dir/index.html"
-    - http://kubernetes.io
+    - http://info.cern.ch
     volumeMounts:
     - name: workdir
       mountPath: "/work-dir"
diff --git a/content/ko/examples/pods/pod-with-pod-affinity.yaml b/content/ko/examples/pods/pod-with-pod-affinity.yaml
index 35e645ef1f..6d075e0860 100644
--- a/content/ko/examples/pods/pod-with-pod-affinity.yaml
+++ b/content/ko/examples/pods/pod-with-pod-affinity.yaml
@@ -12,7 +12,7 @@ spec:
             operator: In
             values:
             - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
     podAntiAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 100
@@ -23,7 +23,7 @@ spec:
               operator: In
               values:
               - S2
-          topologyKey: failure-domain.beta.kubernetes.io/zone
+          topologyKey: topology.kubernetes.io/zone
   containers:
   - name: with-pod-affinity
     image: k8s.gcr.io/pause:2.0
diff --git a/content/ko/examples/pods/storage/pv-claim.yaml b/content/ko/examples/pods/storage/pv-claim.yaml
new file mode 100644
index 0000000000..b33f6faa4c
--- /dev/null
+++ b/content/ko/examples/pods/storage/pv-claim.yaml
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: task-pv-claim
+spec:
+  storageClassName: manual
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 3Gi
diff --git a/content/ko/examples/pods/storage/pv-pod.yaml b/content/ko/examples/pods/storage/pv-pod.yaml
new file mode 100644
index 0000000000..a2eddcf088
--- /dev/null
+++ b/content/ko/examples/pods/storage/pv-pod.yaml
@@ -0,0 +1,20 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: task-pv-pod
+spec:
+  volumes:
+    - name: task-pv-storage
+      persistentVolumeClaim:
+        claimName: task-pv-claim
+  containers:
+    - name: task-pv-container
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: task-pv-storage
+
+
diff --git a/content/ko/examples/pods/storage/pv-volume.yaml b/content/ko/examples/pods/storage/pv-volume.yaml
new file mode 100644
index 0000000000..36fe3c5424
--- /dev/null
+++ b/content/ko/examples/pods/storage/pv-volume.yaml
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: task-pv-volume
+  labels:
+    type: local
+spec:
+  storageClassName: manual
+  capacity:
+    storage: 10Gi
+  accessModes:
+    - ReadWriteOnce
+  hostPath:
+    path: "/mnt/data"
diff --git a/content/ko/examples/service/access/Dockerfile b/content/ko/examples/service/access/Dockerfile
new file mode 100644
index 0000000000..b7b09d492a
--- /dev/null
+++ b/content/ko/examples/service/access/Dockerfile
@@ -0,0 +1,4 @@
+FROM nginx:1.17.3
+
+RUN rm /etc/nginx/conf.d/default.conf
+COPY frontend.conf /etc/nginx/conf.d
diff --git a/content/ko/examples/service/access/frontend.conf b/content/ko/examples/service/access/frontend.conf
new file mode 100644
index 0000000000..9a1f5a0ed6
--- /dev/null
+++ b/content/ko/examples/service/access/frontend.conf
@@ -0,0 +1,11 @@
+upstream hello {
+    server hello;
+}
+
+server {
+    listen 80;
+
+    location / {
+        proxy_pass http://hello;
+    }
+}
diff --git a/content/ko/examples/service/access/frontend.yaml b/content/ko/examples/service/access/frontend.yaml
new file mode 100644
index 0000000000..9f5b6b757f
--- /dev/null
+++ b/content/ko/examples/service/access/frontend.yaml
@@ -0,0 +1,39 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: frontend
+spec:
+  selector:
+    app: hello
+    tier: frontend
+  ports:
+  - protocol: "TCP"
+    port: 80
+    targetPort: 80
+  type: LoadBalancer
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: frontend
+spec:
+  selector:
+    matchLabels:
+      app: hello
+      tier: frontend
+      track: stable
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: hello
+        tier: frontend
+        track: stable
+    spec:
+      containers:
+      - name: nginx
+        image: "gcr.io/google-samples/hello-frontend:1.0"
+        lifecycle:
+          preStop:
+            exec:
+              command: ["/usr/sbin/nginx","-s","quit"]
diff --git a/content/ko/examples/service/access/hello-service.yaml b/content/ko/examples/service/access/hello-service.yaml
new file mode 100644
index 0000000000..71344ecb8b
--- /dev/null
+++ b/content/ko/examples/service/access/hello-service.yaml
@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: hello
+spec:
+  selector:
+    app: hello
+    tier: backend
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: http
diff --git a/content/ko/examples/service/access/hello.yaml b/content/ko/examples/service/access/hello.yaml
new file mode 100644
index 0000000000..85dff18ee1
--- /dev/null
+++ b/content/ko/examples/service/access/hello.yaml
@@ -0,0 +1,24 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: hello
+spec:
+  selector:
+    matchLabels:
+      app: hello
+      tier: backend
+      track: stable
+  replicas: 7
+  template:
+    metadata:
+      labels:
+        app: hello
+        tier: backend
+        track: stable
+    spec:
+      containers:
+        - name: hello
+          image: "gcr.io/google-samples/hello-go-gke:1.0"
+          ports:
+            - name: http
+              containerPort: 80
diff --git a/content/ko/examples/service/networking/external-lb.yaml b/content/ko/examples/service/networking/external-lb.yaml
new file mode 100644
index 0000000000..adcf7a2fd0
--- /dev/null
+++ b/content/ko/examples/service/networking/external-lb.yaml
@@ -0,0 +1,10 @@
+apiVersion: networking.k8s.io/v1
+kind: IngressClass
+metadata:
+  name: external-lb
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    apiGroup: k8s.example.com
+    kind: IngressParameters
+    name: external-lb
diff --git a/content/ko/examples/service/networking/ingress-resource-backend.yaml b/content/ko/examples/service/networking/ingress-resource-backend.yaml
new file mode 100644
index 0000000000..87b6bbd0f3
--- /dev/null
+++ b/content/ko/examples/service/networking/ingress-resource-backend.yaml
@@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: ingress-resource-backend
+spec:
+  defaultBackend:
+    resource:
+      apiGroup: k8s.example.com
+      kind: StorageBucket
+      name: static-assets
+  rules:
+    - http:
+        paths:
+          - path: /icons
+            pathType: ImplementationSpecific
+            backend:
+              resource:
+                apiGroup: k8s.example.com
+                kind: StorageBucket
+                name: icon-assets
diff --git a/content/ko/examples/service/networking/ingress-wildcard-host.yaml b/content/ko/examples/service/networking/ingress-wildcard-host.yaml
new file mode 100644
index 0000000000..2be7016706
--- /dev/null
+++ b/content/ko/examples/service/networking/ingress-wildcard-host.yaml
@@ -0,0 +1,26 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: ingress-wildcard-host
+spec:
+  rules:
+  - host: "foo.bar.com"
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/bar"
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
+  - host: "*.foo.com"
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/foo"
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
diff --git a/content/ko/examples/service/networking/ingress.yaml b/content/ko/examples/service/networking/ingress.yaml
deleted file mode 100644
index 56a0d5138f..0000000000
--- a/content/ko/examples/service/networking/ingress.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-spec:
-  backend:
-    serviceName: testsvc
-    servicePort: 80
-
diff --git a/content/ko/examples/service/networking/minimal-ingress.yaml b/content/ko/examples/service/networking/minimal-ingress.yaml
new file mode 100644
index 0000000000..76640b9447
--- /dev/null
+++ b/content/ko/examples/service/networking/minimal-ingress.yaml
@@ -0,0 +1,17 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: minimal-ingress
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /testpath
+        pathType: Prefix
+        backend:
+          service:
+            name: test
+            port:
+              number: 80
diff --git a/content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml b/content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml
new file mode 100644
index 0000000000..16a560b1ff
--- /dev/null
+++ b/content/ko/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml
@@ -0,0 +1,35 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress-no-third-host
+spec:
+  rules:
+  - host: first.bar.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
+  - host: second.bar.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
+  - http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service3
+            port:
+              number: 80
diff --git a/content/ko/examples/service/networking/name-virtual-host-ingress.yaml b/content/ko/examples/service/networking/name-virtual-host-ingress.yaml
new file mode 100644
index 0000000000..213a73d261
--- /dev/null
+++ b/content/ko/examples/service/networking/name-virtual-host-ingress.yaml
@@ -0,0 +1,26 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
+  - host: bar.foo.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
diff --git a/content/ko/examples/service/networking/simple-fanout-example.yaml b/content/ko/examples/service/networking/simple-fanout-example.yaml
new file mode 100644
index 0000000000..19fef9455b
--- /dev/null
+++ b/content/ko/examples/service/networking/simple-fanout-example.yaml
@@ -0,0 +1,23 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: simple-fanout-example
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - path: /foo
+        pathType: Prefix
+        backend:
+          service:
+            name: service1
+            port:
+              number: 4200
+      - path: /bar
+        pathType: Prefix
+        backend:
+          service:
+            name: service2
+            port:
+              number: 8080
diff --git a/content/ko/examples/service/networking/test-ingress.yaml b/content/ko/examples/service/networking/test-ingress.yaml
new file mode 100644
index 0000000000..acd384ab56
--- /dev/null
+++ b/content/ko/examples/service/networking/test-ingress.yaml
@@ -0,0 +1,10 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: test-ingress
+spec:
+  defaultBackend:
+    service:
+      name: test
+      port:
+        number: 80
diff --git a/content/ko/examples/service/networking/tls-example-ingress.yaml b/content/ko/examples/service/networking/tls-example-ingress.yaml
new file mode 100644
index 0000000000..fe5d52a0cb
--- /dev/null
+++ b/content/ko/examples/service/networking/tls-example-ingress.yaml
@@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: tls-example-ingress
+spec:
+  tls:
+  - hosts:
+      - https-example.foo.com
+    secretName: testsecret-tls
+  rules:
+  - host: https-example.foo.com
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
diff --git a/content/ko/partners/_index.html b/content/ko/partners/_index.html
index 3bd6a375f2..429a789071 100644
--- a/content/ko/partners/_index.html
+++ b/content/ko/partners/_index.html
@@ -7,7 +7,6 @@ cid: partners
 ---
 
 <section id="users">
-  <main class="main-section">
     <h5>쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.</h5>
     <div class="col-container">
       <div class="col-nav">
@@ -17,7 +16,7 @@ cid: partners
           </h5>
           <br>기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다.
           <br><br><br>
-          <button id="kcsp" class="button" onClick="updateSrc(this.id)">KCSP 파트너 보기</button>
+          <button class="button landscape-trigger landscape-default" data-landscape-types="kubernetes-certified-service-provider" id="kcsp">KCSP 파트너 보기</button>
           <br><br><a href="https://www.cncf.io/certification/kcsp/">KCSP</a>에
 	  관심이 있으신가요?
         </center>
@@ -40,57 +39,13 @@ cid: partners
 	  </h5>
           <br>클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다.
           <br><br><br>
-          <button id="ktp" class="button" onClick="updateSrc(this.id)">KTP 파트너 보기</button>
+          <button class="button landscape-trigger" data-landscape-types="kubernetes-training-partner" id="ktp">KTP 파트너 보기</button>
           <br><br><a href="https://www.cncf.io/certification/training/">KTP</a>에
 	  관심이 있으신가요?
         </center>
       </div>
     </div>
-    <script crossorigin="anonymous" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
-    <script type="text/javascript">
-
-      var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes";
-      var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes";
-      var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes";
-
-      function updateSrc(buttonId) {
-        if (buttonId == "kcsp") {
-          $("#landscape").attr("src", defaultLink);
-          window.location.hash = "#kcsp";
-        }
-        if (buttonId == "conformance") {
-          $("#landscape").attr("src", firstLink);
-          window.location.hash = "#conformance";
-        }
-        if (buttonId == "ktp") {
-          $("#landscape").attr("src", secondLink);
-          window.location.hash = "#ktp";
-        }
-      }
-
-      // Automatically load the correct iframe based on the URL fragment
-      document.addEventListener("DOMContentLoaded", function() {
-        var showContent = "kcsp";
-        if (window.location.hash) {
-          console.log("hash is:", window
-            .location
-            .hash
-            .substring(1));
-          showContent = window
-            .location
-            .hash
-            .substring(1);
-        }
-        updateSrc(showContent);
-      });
-    </script>
-    <body>
-      <div id="frameHolder">
-        <iframe frameborder="0" id="landscape" scrolling="no" src="" style="width: 1px; min-width: 100%" title="CNCF Landscape"></iframe>
-        <script src="https://landscape.cncf.io/iframeResizer.js"></script>
-      </div>
-    </body>
-  </main>
+    {{< cncf-landscape helpers=true >}}
 </section>
 
 <style>
diff --git a/content/ko/training/_index.html b/content/ko/training/_index.html
index 574881401c..a46e95cb85 100644
--- a/content/ko/training/_index.html
+++ b/content/ko/training/_index.html
@@ -112,7 +112,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
   </div>
 </div>
diff --git a/content/pl/_common-resources/images/kub_video_banner_homepage.jpg b/content/pl/_common-resources/images/kub_video_banner_homepage.jpg
index 57582e4938..e40d92a503 100644
Binary files a/content/pl/_common-resources/images/kub_video_banner_homepage.jpg and b/content/pl/_common-resources/images/kub_video_banner_homepage.jpg differ
diff --git a/content/pl/_index.html b/content/pl/_index.html
index 1e759a89e7..1096114700 100644
--- a/content/pl/_index.html
+++ b/content/pl/_index.html
@@ -2,11 +2,14 @@
 title: "Produkcyjny system zarządzania kontenerami"
 abstract: "Automatyzacja wdrażania, skalowania i zarządzania kontenerami"
 cid: home
+sitemap:
+  priority: 1.0
+
 ---
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach.
+[Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}), znany też jako K8s, to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach.
 
 Kubernetes grupuje kontenery, które są częścią jednej aplikacji, w logicznie grupy, ułatwiając ich odnajdywanie i zarządzanie nimi. Korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](http://queue.acm.org/detail.cfm?id=2898444) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
 {{% /blocks/feature %}}
@@ -26,7 +29,7 @@ Niezależnie, czy prowadzisz tylko testy, czy globalny koncern, dzięki elastycz
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="suitcase" %}}
-#### Działa w każdym środowisku
+#### K8s działa w każdym środowisku
 
 Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z prywatnego centrum danych, infrastruktury hybrydowej lub chmury publicznej. Bez wysiłku możesz przenieść swoje aplikacje tam, gdzie są najbardziej potrzebne.
 
@@ -41,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Obejrzyj wideo</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon EU 17-20.08.2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon NA, 17-20.11.2020</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon NA w 17-20.11.2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Weź udział w wirtualnym KubeCon EU 4–7.05.2021</a>
 
 </div>
 <div id="videoPlayer">
diff --git a/content/pl/docs/_index.md b/content/pl/docs/_index.md
index 22120af73a..63048e8df9 100644
--- a/content/pl/docs/_index.md
+++ b/content/pl/docs/_index.md
@@ -1,4 +1,6 @@
 ---
 linktitle: Dokumentacja Kubernetesa
 title: Dokumentacja
+sitemap:
+  priority: 1.0
 ---
diff --git a/content/pl/docs/concepts/overview/_index.md b/content/pl/docs/concepts/overview/_index.md
index 32ab47ea71..1c0ee2815d 100755
--- a/content/pl/docs/concepts/overview/_index.md
+++ b/content/pl/docs/concepts/overview/_index.md
@@ -2,4 +2,6 @@
 title: "Przegląd"
 weight: 20
 description: Ogólny zarys Kubernetesa i komponentów, z których jest zbudowany.
+sitemap:
+  priority: 0.9
 ---
diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md
index ce4ea28ff2..dba2d1e782 100644
--- a/content/pl/docs/concepts/overview/components.md
+++ b/content/pl/docs/concepts/overview/components.md
@@ -11,7 +11,7 @@ card:
 ---
 
 <!-- overview -->
-W wyniku instalacji Kubernetes otrzymujesz klaster.
+W wyniku instalacji Kubernetesa otrzymujesz klaster.
 
 {{< glossary_definition term_id="cluster" length="all" prepend="Klaster Kubernetes to">}}
 
@@ -19,7 +19,7 @@ W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, popr
 
 Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego różnymi częściami składowymi.
 
-![Składniki Kubernetes](/images/docs/components-of-kubernetes.png)
+![Składniki Kubernetes](/images/docs/components-of-kubernetes.svg)
 
 
 <!-- body -->
diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md
index 5761b20c61..cd376dab1d 100644
--- a/content/pl/docs/concepts/overview/kubernetes-api.md
+++ b/content/pl/docs/concepts/overview/kubernetes-api.md
@@ -1,5 +1,5 @@
 ---
-title: API Kubernetes
+title: API Kubernetesa
 content_type: concept
 weight: 30
 description: >
@@ -18,32 +18,25 @@ API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami
 
 API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_).
 
-Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/).
+Większość operacji może zostać wykonana poprzez
+interfejs linii komend (CLI) [kubectl](/docs/reference/kubectl/overview/) lub inne
+programy, takie jak [kubeadm](/docs/reference/setup-tools/kubeadm/), które używają
+API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST.
+
+Jeśli piszesz aplikację używającą API Kubernetesa,
+warto rozważyć użycie jednej z [bibliotek klienckich](/docs/reference/using-api/client-libraries/).
 
 <!-- body -->
 
-## Zmiany w API
-
-Jednym z wymagań, które odnoszą się do każdego systemu, który odniósł sukces, jest zdolność do rozwoju i ewolucji w miarę pojawiających się i zmieniających potrzeb.
-Dlatego Kubernetes został zaprojektowany tak, aby umożliwić ciągły rozwój i zmiany w API.
-Celem projektu Kubernetes jest _zachowanie_ zgodności z istniejącymi klientami i utrzymanie tej zgodności
-przez odpowiednio długi czas, pozwalający innym projektom na stopniowe dostosowanie.
-
-W skrócie, nowe zasoby API i nowe pola dla konkretnych zasobów mogą być dodawane stosunkowo często.
-Usunięcie zasobów lub pól wymaga stosowania
-[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-
-Szczegółowe objaśnienia, jak wygląda zmiana, która zachowuje zgodność i jak zmieniać API, znajdują się w dokumencie
-[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
-
 ## Specyfikacja OpenAPI {#api-specification}
 
 Pełną specyfikację API udokumentowano za pomocą [OpenAPI](https://www.openapis.org/).
 
 Serwer API Kubernetes API udostępnia specyfikację OpenAPI poprzez ścieżkę `/openapi/v2`.
-Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z:
+Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą:
 
 <table>
+<caption style="display:none">Dopuszczalne wartości nagłówka żądania dla zapytań OpenAPI v2</caption>
   <thead>
      <tr>
         <th>Nagłówek</th>
@@ -71,93 +64,63 @@ Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z:
         <td><em>udostępnia </em><code>application/json</code></td>
      </tr>
   </tbody>
-  <caption>Dozwolone nagłówki żądań dla zapytania OpenAPI v2</caption>
 </table>
 
-W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API.
+W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf,
+który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze
+i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md).
+Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API.
 
-## Obsługa wersji API
+## Zmiany API
+
+Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb.
+Dlatego Kubernetes został tak zaprojektowany, aby API mogło się zmieniać i rozrastać.
+Projekt Kubernetes dąży do tego, aby nie wprowadzać zmian niezgodnych z istniejącymi aplikacjami klienckimi
+i utrzymywać zgodność przez wystarczająco długi czas, aby inne projekty zdążyły się dostosować do zmian.
+
+W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól
+jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/).
+Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach
+w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md).
+
+## Grupy i wersje API
 
 Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje
 równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub
 `/apis/rbac.authorization.k8s.io/v1alpha1`.
 
-Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym,
+Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, aby być pewnym,
 że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala
 na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej.
 
-Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich.
+Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md),
+które mogą być [włączane i wyłączane](/docs/reference/using-api/#enabling-or-disabling).
 
-Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. Proponowany
-[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania.
+Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_,  
+o ile ma zastosowanie) oraz nazwę. Serwer API może obsługiwać
+te same dane poprzez różne wersje API i przeprowadzać konwersję między
+różnymi wersjami API w sposób niewidoczny dla użytkownika. Wszystkie te różne wersje
+reprezentują w rzeczywistości ten sam zasób. Załóżmy przykładowo, że istnieją dwie
+wersje `v1` i `v1beta1` tego samego zasobu. Obiekt utworzony przez
+wersję `v1beta1` może być odczytany, zaktualizowany i skasowany zarówno przez wersję
+`v1beta1`, jak i `v1`.
 
-Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo
-w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).
-Podsumowanie zamieszczono poniżej:
+Zajrzyj do [API versions reference](/docs/reference/using-api/#api-versioning)
+po szczegółowe informacje, jak definiuje się poziomy wersji API.
 
-- Poziom Alfa:
-  - Nazwa wersji zawiera słowo `alpha` (np. `v1alpha1`).
-  - Może zawierać błędy. Włączenie tej funkcjonalności może wyeksponować różne błędy. Domyślnie jest wyłączona.
-  - Wsparcie dla tej funkcjonalności może być zakończone w dowolnej chwili bez uprzedniego powiadomienia.
-  - W kolejnych wersjach API może zostać zmienione w sposób niezgodny z wersjami wcześniejszymi.
-  - Rekomendowana do użycia tylko na często przebudowywanych klastrach testowych ze względu na duże ryzyko wystąpienia błędów i brak gwarancji  wsparcia w dalszym horyzoncie.
-- Poziom Beta:
-  - Nazwa wersji zawiera słowo `beta` (np. `v2beta3`).
-  - Oprogramowanie jest dobrze przetestowane. Włączenie tej funkcjonalności uznaje się za bezpieczne. Funkcjonalność domyślnie włączona.
-  - Wsparcie dla funkcjonalności będzie utrzymywane, choć może zmieniać się w niektórych szczegółach.
-  - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce,
-    dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API.
-    Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają.
-  - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania.
-    Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć.
-  - **Testuj nasze funkcjonalności w fazie beta i zgłaszaj swoje uwagi! Po wyjściu z fazy beta, możemy nie mieć już możliwości — ze względów praktycznych — wprowadzać w nich żadnych zmian.**
-- Poziom Stabilny:
-  - Nazwa wersji jest w postaci `vX`, gdzie `X` jest liczbą naturalną.
-  - Stabilne funkcjonalności będą dostępne w wielu kolejnych wersjach oprogramowania.
+## Rozbudowa API
 
-## Grupy API
+API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby:
 
-Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
-Grupa API jest określona przez ścieżkę API i pole `apiVersion` serializowanego obiektu.
-
-Obecne w użyciu jest kilka grup API:
-
-1. Grupa *podstawowa* (*core*), nazywana także *legacy group*, jest dostępna przez ścieżkę REST `/api/v1` i używa `apiVersion: v1`.
-
-1. Nazwane grupy udostępnione są przez ścieżkę REST `/apis/$GROUP_NAME/$VERSION` i używają `apiVersion: $GROUP_NAME/$VERSION`
-   (np. `apiVersion: batch/v1`). Pełna lista wpieranych grup API jest dostępna w [Kubernetes API reference](/pl/docs/reference/).
-
-API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/):
-
-1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
-   jest przewidziana dla użytkowników z minimalnymi wymaganiami CRUD.
-1. Użytkownicy, którzy potrzebują pełnej semantyki API Kubernetes, mogą zaimplementować własny apiserver
-   i użyć [agregatora](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/),
-   aby zintegrować je w sposób niezauważalny dla klientów.
-
-## Włączanie i wyłączanie grup API
-
-Określone zasoby i grupy API są włączone domyślnie. Włączanie i wyłączanie odbywa się poprzez ustawienie `--runtime-config`
-w kube-apiserver.
-
-`--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić
-`--runtime-config=batch/v1=false`, aby włączyć batch/v2alpha1, należy ustawić `--runtime-config=batch/v2alpha1`.
-Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą serwera API.
-
-{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager,
-aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}}
-
-## Trwałość
-
-Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w
-{{< glossary_tooltip term_id="etcd" >}}.
+1. [Definicje zasobów własnych](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+   pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane zasoby API.
+1. Można także rozszerzać API Kubernetesa implementując
+   [warstwę agregacji](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 
 ## {{% heading "whatsnext" %}}
 
-[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje
-sposoby, jakimi klaster zarządza dostępem do API.
-
-Ogólne wytyczne dotyczące API opisano w
-[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions).
-
-Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/).
+- Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych
+  [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
+- [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje
+  sposoby, jakimi klaster zarządza dostępem do API.
+- Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/).
diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md
index 75321bfbb5..db8ea18b70 100644
--- a/content/pl/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md
@@ -7,6 +7,8 @@ weight: 10
 card:
   name: concepts
   weight: 10
+sitemap:
+  priority: 0.9
 ---
 
 <!-- overview -->
@@ -35,7 +37,7 @@ Wirtualizacja pozwala lepiej wykorzystywać zasoby fizycznego serwera i lepiej s
 Każda maszyna wirtualna jest pełną maszyną zawierającą własny system operacyjny pracujący na zwirtualizowanej warstwie sprzętowej.
 
 **Era wdrożeń w kontenerach:**
-Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny. Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna, kontener posiada własny system plików, procesor, pamięć, przestrzeń procesów itd. Ponieważ kontenery nie są związane z leżącymi poniżej warstwami infrastruktury, mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego.
+Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny. Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna, kontener posiada własny system plików, udział w zasobach procesora, pamięć, przestrzeń procesów itd. Ponieważ kontenery nie są związane z leżącymi poniżej warstwami infrastruktury, mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego.
 
 Kontenery zyskały popularność ze względu na swoje zalety, takie jak:
 
@@ -85,10 +87,7 @@ Kubernetes:
 * Nie zapewnia, ani nie wykorzystuje żadnego ogólnego systemu do zarządzania konfiguracją, utrzymaniem i samo-naprawianiem maszyn.
 * Co więcej, nie jest zwykłym systemem planowania *(orchestration)*. W rzeczywistości, eliminuje konieczność orkiestracji. Zgodnie z definicją techniczną, orkiestracja to wykonywanie określonego ciągu zadań: najpierw A, potem B i następnie C. Dla kontrastu, Kubernetes składa się z wielu niezależnych, możliwych do złożenia procesów sterujących, których zadaniem jest doprowadzenie stanu faktycznego do stanu oczekiwanego. Nie ma znaczenia, w jaki sposób przechodzi się od A do C. Nie ma konieczności scentralizowanego zarządzania. Dzięki temu otrzymujemy system, który jest potężniejszy, bardziej odporny i niezawodny i dający więcej możliwości rozbudowy.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-*   Dowiedz się o [komponentach Kubernetesa](/pl/docs/concepts/overview/components/)
-*   Jesteś gotowy [zacząć pracę](/pl/docs/setup/)?
-
+* Dowiedz się o [komponentach Kubernetesa](/pl/docs/concepts/overview/components/)
+* Jesteś gotowy [zacząć pracę](/pl/docs/setup/)?
diff --git a/content/pl/docs/contribute/_index.md b/content/pl/docs/contribute/_index.md
index a6f9356a58..c107ec357d 100644
--- a/content/pl/docs/contribute/_index.md
+++ b/content/pl/docs/contribute/_index.md
@@ -1,17 +1,24 @@
 ---
 content_type: concept
-title: Współtwórz dokumentację Kubernetesa
+title: Współtwórz dokumentację K8s
 linktitle: Weź udział
 main_menu: true
 weight: 80
 card:
   name: contribute
   weight: 10
-  title: Weź udział
+  title: Współtwórz K8s
 ---
 
 <!-- overview -->
 
+Kubernetes zaprasza do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych!
+
+{{< note >}}
+Aby dowiedzieć się więcej ogólnych informacji o współpracy przy tworzeniu Kubernetesa, zajrzyj
+do [contributor documentation](https://www.kubernetes.dev/docs/).
+{{< /note >}}
+
 Tym serwisem www opiekuje się [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
 
 Współtwórcy dokumentacji Kubernetesa:
@@ -21,8 +28,6 @@ Współtwórcy dokumentacji Kubernetesa:
 - Tłumaczą dokumentację
 - Zarządzają i publikują dokumentację w ramach cyklu wydawniczego Kubernetesa
 
-Zapraszamy do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych!
-
 <!-- body -->
 
 ## Jak zacząć?
diff --git a/content/pl/docs/home/_index.md b/content/pl/docs/home/_index.md
index 5c8facdbc5..1e2ecfe14b 100644
--- a/content/pl/docs/home/_index.md
+++ b/content/pl/docs/home/_index.md
@@ -30,7 +30,7 @@ cards:
   button: "Samouczki"
   button_path: "/docs/tutorials"
 - name: setup
-  title: "Uruchom klaster"
+  title: "Uruchom klaster K8s"
   description: "Uruchom klaster Kubernetes dopasowany do Twoich potrzeb i możliwości."
   button: "Uruchom Kubernetesa"
   button_path: "/docs/setup"
@@ -55,7 +55,7 @@ cards:
   button: Weź udział
   button_path: /docs/contribute
 - name: release-notes
-  title: Informacje o wydaniu
+  title: Informacje o wydaniu K8s
   description: Jeśli instalujesz lub aktualizujesz Kubernetesa, zajrzyj do informacji o najnowszym wydaniu.
 - name: about
   title: O dokumentacji
diff --git a/content/pl/docs/home/supported-doc-versions.md b/content/pl/docs/home/supported-doc-versions.md
index 19e08be721..0ad302706a 100644
--- a/content/pl/docs/home/supported-doc-versions.md
+++ b/content/pl/docs/home/supported-doc-versions.md
@@ -1,25 +1,12 @@
 ---
-title: Wspierane wersje dokumentacji Kubernetesa
-content_type: concept
+title: Dostępne wersje dokumentacji
+content_type: custom
+layout: supported-versions
 card:
   name: about
   weight: 10
-  title: Wspierane wersje dokumentacji
+  title: Dostępne wersje dokumentacji
+  
 ---
 
-<!-- overview -->
-
 Ten serwis zawiera dokumentację do bieżącej i czterech poprzednich wersji Kubernetesa.
-
-
-
-<!-- body -->
-
-## Bieżąca wersja
-
-Bieżąca wersja to
-[{{< param "version" >}}](/).
-
-## Poprzednie wersje
-
-{{< versions-other >}}
diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md
index 40e3724fa0..bfc120218c 100644
--- a/content/pl/docs/reference/_index.md
+++ b/content/pl/docs/reference/_index.md
@@ -10,14 +10,12 @@ content_type: concept
 
 Tutaj znajdziesz dokumentację źródłową Kubernetes.
 
-
-
 <!-- body -->
 
 ## Dokumentacja API
 
-* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Ogólne informacje na temat Kubernetes API.
-  * [Dokumentacja źródłowa Kubernetes API {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+* [Dokumentacja źródłowa API Kubernetesa {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+* [Using The Kubernetes API](/docs/reference/using-api/) - ogólne informacje na temat API Kubernetesa.
 
 ## Biblioteki klientów API
 
diff --git a/content/pl/docs/reference/glossary/kubelet.md b/content/pl/docs/reference/glossary/kubelet.md
index 86d7a2c7f1..73baa719e5 100755
--- a/content/pl/docs/reference/glossary/kubelet.md
+++ b/content/pl/docs/reference/glossary/kubelet.md
@@ -9,7 +9,6 @@ short_description: >
 aka:
 tags:
 - fundamental
-- core-object
 ---
  Agent, który działa na każdym {{< glossary_tooltip text="węźle" term_id="node" >}} klastra. Odpowiada za uruchamianie {{< glossary_tooltip text="kontenerów" term_id="container" >}} w ramach {{< glossary_tooltip text="poda" term_id="pod" >}}.
 
diff --git a/content/pl/docs/reference/tools.md b/content/pl/docs/reference/tools.md
index 33a665438c..5d60370ee3 100644
--- a/content/pl/docs/reference/tools.md
+++ b/content/pl/docs/reference/tools.md
@@ -18,7 +18,7 @@ Kubernetes zawiera różne wbudowane narzędzia służące do pracy z systemem:
 
 ## Minikube
 
-[`minikube`](/docs/tasks/tools/install-minikube/) to narzędzie do łatwego uruchamiania lokalnego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów.
+[`minikube`](https://minikube.sigs.k8s.io/docs/) to narzędzie do łatwego uruchamiania lokalnego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów.
 
 ## Pulpit *(Dashboard)*
 
@@ -38,7 +38,7 @@ Helm-a można używać do:
 
 ## Kompose
 
-[`Kompose`](https://github.com/kubernetes-incubator/kompose) to narzędzie, które ma pomóc użytkownikom Docker Compose przenieść się na Kubernetes.
+[`Kompose`](https://github.com/kubernetes/kompose) to narzędzie, które ma pomóc użytkownikom Docker Compose przenieść się na Kubernetes.
 
 Kompose można używać do:
 
diff --git a/content/pl/docs/search.md b/content/pl/docs/search.md
deleted file mode 100644
index 9ae06bfa7d..0000000000
--- a/content/pl/docs/search.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-layout: search
-title: Wyniki wyszukiwania
----
-
diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md
index 5593490dc3..e9f8ed32d8 100644
--- a/content/pl/docs/tutorials/_index.md
+++ b/content/pl/docs/tutorials/_index.md
@@ -18,11 +18,11 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
 
 ## Podstawy
 
-* [Podstawy Kubernetes](/docs/tutorials/kubernetes-basics/) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości.
+* [Podstawy Kubernetesa](/pl/docs/tutorials/kubernetes-basics/) (PL) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości.
 
 * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
 
-* [Hello Minikube](/docs/tutorials/hello-minikube/)
+* [Hello Minikube](/pl/docs/tutorials/hello-minikube/) (PL)
 
 ## Konfiguracja
 
diff --git a/content/pl/docs/tutorials/hello-minikube.md b/content/pl/docs/tutorials/hello-minikube.md
index a56396843c..2c68bc3b5f 100644
--- a/content/pl/docs/tutorials/hello-minikube.md
+++ b/content/pl/docs/tutorials/hello-minikube.md
@@ -16,40 +16,35 @@ card:
 <!-- overview -->
 
 Ten samouczek pokaże, jak uruchomić przykładową aplikację
-na Kubernetes przy użyciu [Minikube](/docs/setup/learning-environment/minikube) oraz Katacoda.
+na Kubernetesie przy użyciu minikube oraz Katacoda.
 Katacoda to darmowe środowisko Kubernetes dostępne bezpośrednio z przeglądarki web.
 
 {{< note >}}
-Możesz też skorzystać z tego samouczka, jeśli już zainstalowałeś [Minikube lokalnie](/docs/tasks/tools/install-minikube/).
+Możesz też skorzystać z tego samouczka, jeśli już zainstalowałeś minikube.
+Odwiedź stronę [minikube start](https://minikube.sigs.k8s.io/docs/start/), aby dowiedzieć się, jak go zainstalować.
 {{< /note >}}
 
-
-
 ## {{% heading "objectives" %}}
 
-
-* Skonfiguruj przykładową aplikację do uruchomienia w Minikube.
+* Skonfiguruj przykładową aplikację do uruchomienia w minikube.
 * Uruchom aplikację.
 * Przejrzyj jej logi.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyświetlić z powrotem wszystkie przychodzące zapytania.
 
-
-
 <!-- lessoncontent -->
 
-## Stwórz klaster Minikube
+## Stwórz klaster minikube
 
 1. Kliknij w **Launch Terminal**
 
     {{< kat-button >}}
 
-    {{< note >}}Jeśli masz Minikube zainstalowane lokalnie, uruchom `minikube start`.{{< /note >}}
+    {{< note >}}
+    Jeśli masz minikube zainstalowane lokalnie, uruchom `minikube start`.
+    {{< /note >}}
 
 2. Otwórz panel Kubernetes w przeglądarce:
 
@@ -135,6 +130,9 @@ jako [*Serwis*](/docs/concepts/services-networking/service/) Kubernetes.
     Opcja `--type=LoadBalancer` wskazuje, że chcesz udostępnić swój Serwis
     na zewnątrz klastra.
 
+    Aplikacja, która jest umieszczona w obrazie kontenera `k8s.gcr.io/echoserver`, nasłuchuje jedynie na porcie TCP 8080. Jeśli użyłeś
+    `kubectl expose` do wystawienia innego portu, aplikacje klienckie mogą nie móc się podłączyć do tamtego innego portu.
+
 2. Sprawdź Serwis, który właśnie utworzyłeś:
 
     ```
@@ -151,7 +149,7 @@ jako [*Serwis*](/docs/concepts/services-networking/service/) Kubernetes.
 
     U dostawców usług chmurowych, którzy obsługują *load balancers*,
     zostanie przydzielony zewnętrzny adres IP na potrzeby serwisu.
-    W Minikube, typ `LoadBalancer` udostępnia serwis poprzez polecenie
+    W minikube, typ `LoadBalancer` udostępnia serwis poprzez polecenie
     `minikube service`.
 
 3. Uruchom poniższe polecenie:
@@ -168,7 +166,7 @@ jako [*Serwis*](/docs/concepts/services-networking/service/) Kubernetes.
 
 ## Włącz dodatki
 
-Minikube ma zestaw wbudowanych {{< glossary_tooltip text="dodatków" term_id="addons" >}}, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
+Narzędzie minikube dysponuje zestawem wbudowanych {{< glossary_tooltip text="dodatków" term_id="addons" >}}, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.
 
 1. Lista aktualnie obsługiwanych dodatków:
 
@@ -272,13 +270,8 @@ minikube stop
 minikube delete
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * Dowiedz się więcej o [obiektach typu Deployment](/docs/concepts/workloads/controllers/deployment/).
 * Dowiedz się więcej o [instalowaniu aplikacji](/docs/tasks/run-application/run-stateless-application-deployment/).
 * Dowiedz się więcej o [obiektach typu Serwis](/docs/concepts/services-networking/service/).
-
-
diff --git a/content/pl/docs/tutorials/kubernetes-basics/_index.html b/content/pl/docs/tutorials/kubernetes-basics/_index.html
index 780c21d0ff..39d8bf63c9 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/_index.html
@@ -1,6 +1,7 @@
 ---
 title: Naucz się podstaw
-linkTitle: Podstawy Kubernetes
+linkTitle: Podstawy Kubernetesa
+no_list: true
 weight: 10
 card:
   name: tutorials
@@ -22,7 +23,7 @@ card:
 
     <div class="row">
       <div class="col-md-9">
-        <h2>Podstawy Kubernetes</h2>
+        <h2>Podstawy Kubernetesa</h2>
         <p>Ten samouczek poprowadzi Cię przez podstawy systemu zarządzania zadaniami na klastrze Kubernetes. W każdym module znajdziesz najważniejsze informacje o głównych pojęciach i funkcjonalnościach Kubernetes oraz interaktywny samouczek online. Dzięki samouczkom nauczysz się zarządzać prostym klasterem i skonteneryzowanymi aplikacjami uruchamianymi na tym klastrze.</p>
         <p>Nauczysz się, jak:</p>
         <ul>
diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index 019b6837fe..12211e42b6 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Ekran jest za wąski do pracy z terminalem. Użyj wersji na desktop/tablet.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
index e5d4769916..3955e557c4 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
@@ -72,7 +72,7 @@ weight: 10
         <div class="row">
             <div class="col-md-8">
                 <p><b>Master odpowiada za zarządzanie klastrem.</b> Master koordynuje wszystkie działania klastra, takie jak zlecanie uruchomienia aplikacji, utrzymywanie pożądanego stanu aplikacji, skalowanie aplikacji i instalowanie nowych wersji.</p>
-                <p><b>Węzeł to maszyna wirtualna (VM) lub fizyczny serwer, który jest maszyną roboczą w klastrze Kubernetes.</b> Na każdym węźle działa Kubelet, agent zarządzający tym węzłem i komunikujący się z masterem Kubernetes. Węzeł zawiera także narzędzia do obsługi kontenerów, takie jak Docker lub rkt. Klaster Kubernetes w środowisku produkcyjnym powinien składać się minimum z trzech węzłów.</p>
+                <p><b>Węzeł to maszyna wirtualna (VM) lub fizyczny serwer, który jest maszyną roboczą w klastrze Kubernetes.</b> Na każdym węźle działa Kubelet, agent zarządzający tym węzłem i komunikujący się z masterem Kubernetes. Węzeł zawiera także narzędzia do obsługi kontenerów, takie jak containerd lub Docker. Klaster Kubernetes w środowisku produkcyjnym powinien składać się minimum z trzech węzłów.</p>
 
             </div>
             <div class="col-md-4">
diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 4b6676a0c2..64c1a0a9a1 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -32,7 +32,7 @@ weight: 20
                 Do pracy z terminalem użyj wersji na desktop/tablet
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index 1fded17990..1ae1e88382 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 Do pracy z terminalem użyj wersji na desktop/tablet
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 3d61cf2d1d..a1aca99ce3 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Do pracy z terminalem użyj wersji na desktop/tablet
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index f4cbe234bb..e8017f5ad6 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Do pracy z terminalem użyj wersji na desktop/tablet
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 46a3172ee8..07731b5849 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Do pracy z terminalem użyj wersji na desktop/tablet
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/pl/training/_index.html b/content/pl/training/_index.html
index cc6579781d..2dd7ed433e 100644
--- a/content/pl/training/_index.html
+++ b/content/pl/training/_index.html
@@ -10,16 +10,19 @@ class: training
 <section class="call-to-action">
   <div class="main-section">
     <div class="call-to-action" id="cta-certification">
-      <div class="logo-certification cta-image cta-image-before" id="logo-cka">
-        <img src="/images/training/kubernetes-cka-white.svg"/>
-      </div>
-      <div class="logo-certification cta-image cta-image-after" id="logo-ckad">
-        <img src="/images/training/kubernetes-ckad-white.svg"/>
-      </div>
       <div class="cta-text">
         <h2>Kariera <em>Cloud Native</em></h2>
         <p>Kubernetes stanowi serce całego ruchu <em>cloud native</em>. Korzystając ze szkoleń i certyfikacji oferowanych przez Linux Foundation i naszych partnerów zainwestujesz w swoją karierę, nauczysz się korzystać z Kubernetesa i sprawisz, że Twoje projekty <em>cloud native</em> osiągną sukces.</p>
       </div>
+      <div class="logo-certification cta-image" id="logo-cka">
+        <img src="/images/training/kubernetes-cka-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image" id="logo-ckad">
+        <img src="/images/training/kubernetes-ckad-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image" id="logo-cks">
+        <img src="/images/training/kubernetes-cks-white.svg"/>
+      </div>
     </div>
   </div>
 </section>
@@ -74,31 +77,36 @@ class: training
   </div>
 </div>
 
-<section>
+<section id="get-certified">
   <div class="main-section padded">
-    <center>
-        <h2>Uzyskaj certyfikat Kubernetes</h2>
-    </center>
+    <h2>Uzyskaj certyfikat Kubernetes</h2>
     <div class="col-container">
       <div class="col-nav">
-        <center>
           <h5>
             <b>Certified Kubernetes Application Developer (CKAD)</b>
           </h5>
           <p>Egzamin na certyfikowanego dewelopera aplikacji (Certified Kubernetes Application Developer) potwierdza umiejętności projektowania, budowania, konfigurowania i udostępniania "rdzennych" aplikacji dla Kubernetesa.</p>
+          <p>CKAD potrafi określić zasoby wymagane przez aplikację oraz wykorzystać bazowe elementy do budowy, monitorowania i rozwiązywania problemów skalowalnych aplikacji oraz narzędzi w Kubernetesie.</p>
           <br>
           <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Przejdź do certyfikacji</a>
-        </center>
       </div>
       <div class="col-nav">
-        <center>
           <h5>
             <b>Certified Kubernetes Administrator (CKA)</b>
           </h5>
           <p>Program certyfikowanego administratora Kubernetes (Certified Kubernetes Administrator) potwierdza umiejętności, wiedzę i kompetencje do podejmowania się zadań administracji Kubernetesem.</p>
+          <p>Certyfikowany administrator Kubernetesa udowodnił swoje umiejętności prostej instalacji oraz konfiguracji i zarządzania klastrem Kubernetesa jakości produkcyjnej.</p>
           <br>
           <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Przejdź do certyfikacji</a>
-        </center>
+      </div>
+      <div class="col-nav">
+          <h5>
+            <b>Certified Kubernetes Security Specialist (CKS)</b>
+          </h5>
+          <p>Program certyfikowanego specjalisty bezpieczeństwa Kubernetesa zapewnia, że jego posiadacz jest kompetentny i biegły w stosowaniu w szerokim zakresie najlepszych praktyk. Certyfikacja CKS obejmuje umiejętności niezbędne do zapewnienia bezpieczeństwa aplikacji uruchamianych w kontenerach i platformy Kubernetes na etapie budowy, instalacji i działania.</p>
+          <p><em>Kandydaci na CKS muszą posiadać ważny certyfikat Certified Kubernetes Administrator (CKA), aby udowodnić, że posiadają wystarczające doświadczenie w pracy z Kubernetesem przed przystąpieniem do egzaminu CKS.</em></p>
+          <br>
+          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">Przejdź do certyfikacji</a>
       </div>
     </div>
   </div>
@@ -112,7 +120,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
   </div>
 </div>
diff --git a/content/pt/_index.html b/content/pt/_index.html
index c2374521be..628047e85c 100644
--- a/content/pt/_index.html
+++ b/content/pt/_index.html
@@ -42,8 +42,7 @@ O Kubernetes é Open Source, o que te oferece a liberdade de utilizá-lo em seu
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Assista Video</button>
         <br>
         <br>
-        <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">KubeCon em Barcelona em Maio 20-23 de 2019</a>
+        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">KubeCon em Barcelona on Maio 20-23, 2019</a>
         <br>
         <br>
         <br>
diff --git a/content/pt/case-studies/chinaunicom/index.html b/content/pt/case-studies/chinaunicom/index.html
index 63131d0031..d01e01a1e9 100644
--- a/content/pt/case-studies/chinaunicom/index.html
+++ b/content/pt/case-studies/chinaunicom/index.html
@@ -1,96 +1,78 @@
 ---
 title: Estudo de caso China Unicom
-
 linkTitle: chinaunicom
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
-logo: chinaunicom_featured_logo.png
-featured: true
-weight: 1
-quote: >
-   O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem. Atualmente, não há tecnologia alternativa que possa substituí-lo.
+featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/chinaunicom/banner1.jpg
+heading_title_logo: /images/chinaunicom_logo.png
+title_prefix: "ESTUDO DE CASO:"
+subheading: >
+  China Unicom: Como o Kubernetes alavancou a utilização de recursos, aumentando sua eficiência operacional e menores custos em TI
+case_study_details:
+  - Empresa: China Unicom
+  - Localização: Beijing, China
+  - Indústria: Telecom
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_chinaunicom_banner1.jpg')">
-  <h1> ESTUDO DE CASO:<img src="/images/chinaunicom_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;line-height:1.4em">China Unicom: Como o Kubernetes alavancou a utilização de recursos, aumentando sua eficiência operacional e menores custos em TI
+<h2>Desafio</h2>
 
-</div></h1>
+<p>A China Unicom é uma das três principais operadoras de telecomunicações da China e, para atender seus 300 milhões de usuários, a empresa administra vários data centers com milhares de servidores em cada um, usando <a href="https://www.docker.com/">Docker</a> Contêiner, <a href="https://www.vmware.com/">VMWare</a> e <a href="https://www.openstack.org/">OpenStack</a> em sua infra-estrutura desde 2016. Infelizmente, "a taxa de utilização de recursos era relativamente baixa", diz Chengyu Zhang, líder do Grupo de Pesquisa e Desenvolvimento de Tecnologia de Plataforma, "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos". Outrora uma empresa totalmente estatal, a China Unicom, nos últimos anos, obteve investimentos privados da BAT (Baidu, Alibaba, Tencent) e JD.com, e agora está se concentrando no desenvolvimento interno usando tecnologia open source, ao invés de produtos comerciais. Como tal, a equipe do China Unicom Lab de Zhang começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem.</p>
 
-</div>
+<h2>Solução</h2>
 
-<div class="details">
-    Empresa &nbsp;<b>China Unicom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Localização &nbsp;<b>Beijing, China</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Indústria &nbsp;<b>Telecom</b>
-</div>
+<p>Por causa de seu crescimento rápido e comunidade madura de código aberto, o Kubernetes foi uma escolha natural para a China Unicom. A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. "O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo." A China Unicom também usa o <a href="https://istio.io/">Istio</a> para sua estrutura de microsserviço, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://coredns.io/">CoreDNS</a> e <a href="https://www.fluentd.org/">Fluentd</a>.</p>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>Desafio</h2>
-    A China Unicom é uma das três principais operadoras de telecomunicações da China e, para atender seus 300 milhões de usuários, a empresa administra vários data centers com milhares de servidores em cada um, usando <a href="https://www.docker.com/">Docker</a> Contêiner, <a href="https://www.vmware.com/">VMWare</a> e <a href="https://www.openstack.org/">OpenStack</a> em sua infra-estrutura desde 2016. Infelizmente, "a taxa de utilização de recursos era relativamente baixa", diz Chengyu Zhang, líder do Grupo de Pesquisa e Desenvolvimento de Tecnologia de Plataforma, "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos". Outrora uma empresa totalmente estatal, a China Unicom, nos últimos anos, obteve investimentos privados da BAT (Baidu, Alibaba, Tencent) e JD.com, e agora está se concentrando no desenvolvimento interno usando tecnologia open source, ao invés de produtos comerciais. Como tal, a equipe do China Unicom Lab de Zhang começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem.
-<br><br>
-    <h2>Solução</h2>
-    Por causa de seu crescimento rápido e comunidade madura de código aberto, o Kubernetes foi uma escolha natural para a China Unicom. A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. "O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo." A China Unicom também usa o <a href="https://istio.io/">Istio</a> para sua estrutura de microsserviço, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://coredns.io/">CoreDNS</a> e <a href="https://www.fluentd.org/">Fluentd</a>.
-<br><br>
 <h2>Impacto</h2>
-    Na China Unicom, o Kubernetes melhorou a eficiência operacional e de desenvolvimento. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à autocorreção e à escalabilidade, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas. Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo".
 
-</div>
+<p>Na China Unicom, o Kubernetes melhorou a eficiência operacional e de desenvolvimento. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à autocorreção e à escalabilidade, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas. Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo".</p>
 
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    "O Kubernetes melhorou nossa experiência usando a infraestrutura em nuvem. Atualmente, não há tecnologia alternativa que possa substituí-lo."
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang, Líder do Grupo de Pesquisa e Desenvolvimento em Tecnologia de Plataforma, China Unicom</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>Com mais de 300 milhões de usuários, a China Unicom é uma das três principais operadoras de telecomunicações do país. </h2>
+{{< case-studies/quote author="Chengyu Zhang, Líder do Grupo de Pesquisa e Desenvolvimento em Tecnologia de Plataforma, China Unicom" >}}
+"O Kubernetes melhorou nossa experiência usando a infraestrutura em nuvem. Atualmente, não há tecnologia alternativa que possa substituí-lo."
+{{< /case-studies/quote >}}
 
-  Nos bastidores, a empresa administra vários datacenters com milhares de servidores em cada um, usando contêineres Docker, infra-estrutura VMWare e OpenStack desde 2016. Infelizmente, "a taxa de utilização de recursos foi relativamente baixa", diz Chengyu Zhang, líder de pesquisa e desenvolvimento de plataformas tecnológicas. "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos". <br> <br>
-  A equipe de Zhang, responsável por novas tecnologias, pesquisa e desenvolvimento e plataformas, decidiu encontrar uma solução de gerenciamento de TI. Anteriormente uma empresa totalmente estatal, a China Unicom tem, nos últimos anos, feito investimentos privados da BAT (Baidu, Alibaba, Tencent) e da JD.com, e agora está se concentrando no desenvolvimento local usando tecnologia open source, ao invés de produtos comerciais. Por esse motivo, a equipe começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem.
+{{< case-studies/lead >}}
+Com mais de 300 milhões de usuários, a China Unicom é uma das três principais operadoras de telecomunicações do país.
+{{< /case-studies/lead >}}
 
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_chinaunicom_banner3.jpg');width:100%;padding-left:0;">
-  <div class="banner3text">
-    "Nós nunca poderíamos imaginar que alcançaríamos essa escalabilidade em tão pouco tempo."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang, Líder do Grupo de Tecnologia de Plataforma de Pesquisa e Desenvolvimento, China Unicom</span>
+<p>Nos bastidores, a empresa administra vários datacenters com milhares de servidores em cada um, usando contêineres Docker, infra-estrutura VMWare e OpenStack desde 2016. Infelizmente, "a taxa de utilização de recursos foi relativamente baixa", diz Chengyu Zhang, líder de pesquisa e desenvolvimento de plataformas tecnológicas. "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos".</p>
 
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-  Embora a China Unicom já estivesse usando o Mesos para um sistema central de operadoras de telecomunicações, a equipe sentiu que o Kubernetes era uma escolha natural para a nova plataforma de nuvem. "A principal razão foi que tem uma comunidade madura", diz Zhang. "Ela cresce muito rapidamente e, portanto, podemos aprender muito com as melhores práticas das outras pessoas". A China Unicom também usa o Istio para sua estrutura de microsserviço, Envoy, CoreDNS e Fluentd. <br> <br>
-  A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. Os desenvolvedores da China Unicom podem facilmente aproveitar a tecnologia por meio de APIs, sem fazer o trabalho de desenvolvimento por conta própria. A plataforma de nuvem fornece 20 a 30 serviços conectados à plataforma PaaS de data center da empresa, além de oferecer suporte a análises de big data para usuários internos nas filiais das 31 províncias da China. <br> <br>
-  "O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo."
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_chinaunicom_banner4.jpg');width:100%">
-  <div class="banner4text">
-    "Essa tecnologia é relativamente complicada, mas quando os desenvolvedores se acostumarem, eles poderão desfrutar de todos os benefícios." <br style="height:25px"> <span style = "font-size: 14px; letter-spacing: 2px; text-transform: uppercase; margin-top: 5%! important;"> <br> - Jie Jia , Membro da Plataforma de Tecnologia de I & D, China Unicom </ span>
-  </div>
-</div>
+<p>A equipe de Zhang, responsável por novas tecnologias, pesquisa e desenvolvimento e plataformas, decidiu encontrar uma solução de gerenciamento de TI. Anteriormente uma empresa totalmente estatal, a China Unicom tem, nos últimos anos, feito investimentos privados da BAT (Baidu, Alibaba, Tencent) e da JD.com, e agora está se concentrando no desenvolvimento local usando tecnologia open source, ao invés de produtos comerciais. Por esse motivo, a equipe começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem.</p>
 
-<section class="section5" style="padding:0px !important">
-<div class="fullcol">
-  Na verdade, o Kubernetes aumentou a eficiência operacional e de desenvolvimento na China Unicom. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à auto-correção e escalabilidade do Kubernetes, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas". <br> <br>
-  Com os ganhos que a China Unicom experimentou com o Kubernetes, Zhang e sua equipe estão ansiosos para devolver à comunidade. Isso começa com a participação em encontros e conferências, e oferecendo conselhos para outras empresas que estão considerando um caminho semelhante. "Especialmente para as empresas que têm um sistema tradicional de computação em nuvem, eu realmente recomendo que elas se juntem à comunidade de computação nativa da nuvem", diz Zhang.
-</div>
+{{< case-studies/quote
+  image="/images/case-studies/chinaunicom/banner3.jpg"
+  author="Chengyu Zhang, Líder do Grupo de Pesquisa e Desenvolvimento em Tecnologia de Plataforma, China Unicom"
+>}}
+"Nós nunca poderíamos imaginar que alcançaríamos essa escalabilidade em tão pouco tempo."
+{{< /case-studies/quote >}}
 
-<div class="banner5" >
-  <div class="banner5text">
-    "As empresas podem usar os serviços gerenciados oferecidos por empresas como a Rancher, porque eles já personalizaram essa tecnologia, e você pode aproveitar essa tecnologia com facilidade." <br style="height: 25px"> <span style ="font-size: 14px; letter-spacing: 2px; text-transform: uppercase; margin-top: 5%! important; "> <br> - Jie Jia, membro da Plataforma de Tecnologia de P&D, China Unicom </span> </div>
-</div>
+<p>Embora a China Unicom já estivesse usando o Mesos para um sistema central de operadoras de telecomunicações, a equipe sentiu que o Kubernetes era uma escolha natural para a nova plataforma de nuvem. "A principal razão foi que tem uma comunidade madura", diz Zhang. "Ela cresce muito rapidamente e, portanto, podemos aprender muito com as melhores práticas das outras pessoas". A China Unicom também usa o Istio para sua estrutura de microsserviço, Envoy, CoreDNS e Fluentd.</p>
 
-<div class="fullcol">
-  Jie Jia, membro da equipe de Tecnologia de P&D da Plataforma, acrescenta que, embora "essa tecnologia seja relativamente complicada, desde que os desenvolvedores se acostumem a ela, eles poderão desfrutar de todos os benefícios". E Zhang ressalta que, em sua própria experiência com a nuvem de máquinas virtuais, "o Kubernetes e essas tecnologias nativas de nuvem são relativamente mais simples". <br> <br>
-  Além disso, "as empresas podem usar os serviços gerenciados oferecidos por empresas como <a href="https://rancher.com/">Rancher</a>, porque eles já personalizaram essa tecnologia", diz Jia. "Você pode facilmente aproveitar essa tecnologia". <br> <br>
-  Olhando para o futuro, a China Unicom planeja desenvolver mais aplicativos no Kubernetes, com foco em big data e aprendizado de máquina. A equipe continua a otimizar a plataforma de nuvem que construiu e espera passar no teste de conformidade para se juntar ao <a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">programa de Certificação Kubernetes com 32 distros e plataformas compatíveis</a>. Eles também esperam, um dia, contribuir com o código para a comunidade. <br> <br>
-  Se isso soa ambicioso, é porque os resultados que eles obtiveram ao adotar o Kubernetes foram além de suas maiores expectativas. Zhang diz: "Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo".
-</div>
-</section>
-</body>
-</html>
+<p>A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. Os desenvolvedores da China Unicom podem facilmente aproveitar a tecnologia por meio de APIs, sem fazer o trabalho de desenvolvimento por conta própria. A plataforma de nuvem fornece 20 a 30 serviços conectados à plataforma PaaS de data center da empresa, além de oferecer suporte a análises de big data para usuários internos nas filiais das 31 províncias da China.</p>
+
+<p>"O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo."</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/chinaunicom/banner4.jpg"
+  author="Jie Jia, Membro da Plataforma de Tecnologia de I & D, China Unicom"
+>}}
+"Essa tecnologia é relativamente complicada, mas quando os desenvolvedores se acostumarem, eles poderão desfrutar de todos os benefícios."
+{{< /case-studies/quote >}}
+
+<p>Na verdade, o Kubernetes aumentou a eficiência operacional e de desenvolvimento na China Unicom. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à auto-correção e escalabilidade do Kubernetes, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas".</p>
+
+<p>Com os ganhos que a China Unicom experimentou com o Kubernetes, Zhang e sua equipe estão ansiosos para devolver à comunidade. Isso começa com a participação em encontros e conferências, e oferecendo conselhos para outras empresas que estão considerando um caminho semelhante. "Especialmente para as empresas que têm um sistema tradicional de computação em nuvem, eu realmente recomendo que elas se juntem à comunidade de computação nativa da nuvem", diz Zhang.</p>
+
+{{< case-studies/quote author="Jie Jia, Membro da Plataforma de Tecnologia de I & D, China Unicom" >}}
+"As empresas podem usar os serviços gerenciados oferecidos por empresas como a Rancher, porque eles já personalizaram essa tecnologia, e você pode aproveitar essa tecnologia com facilidade."
+{{< /case-studies/quote >}}
+
+<p>Jie Jia, membro da equipe de Tecnologia de P&D da Plataforma, acrescenta que, embora "essa tecnologia seja relativamente complicada, desde que os desenvolvedores se acostumem a ela, eles poderão desfrutar de todos os benefícios". E Zhang ressalta que, em sua própria experiência com a nuvem de máquinas virtuais, "o Kubernetes e essas tecnologias nativas de nuvem são relativamente mais simples".</p>
+
+<p>Além disso, "as empresas podem usar os serviços gerenciados oferecidos por empresas como <a href="https://rancher.com/">Rancher</a>, porque eles já personalizaram essa tecnologia", diz Jia. "Você pode facilmente aproveitar essa tecnologia".</p>
+
+<p>Olhando para o futuro, a China Unicom planeja desenvolver mais aplicativos no Kubernetes, com foco em big data e aprendizado de máquina. A equipe continua a otimizar a plataforma de nuvem que construiu e espera passar no teste de conformidade para se juntar ao <a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">programa de Certificação Kubernetes com 32 distros e plataformas compatíveis</a>. Eles também esperam, um dia, contribuir com o código para a comunidade.</p>
+
+<p>Se isso soa ambicioso, é porque os resultados que eles obtiveram ao adotar o Kubernetes foram além de suas maiores expectativas. Zhang diz: "Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo".</p>
diff --git a/content/ru/_index.html b/content/ru/_index.html
index 7298da03f4..aaf9f136f5 100644
--- a/content/ru/_index.html
+++ b/content/ru/_index.html
@@ -41,12 +41,12 @@ Kubernetes — это проект с открытым исходным кодо
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Смотреть видео</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Посетите KubeCon в Амстердаме, с 30 марта по 2 апреля 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Посетите KubeCon NA онлайн, 17-20 ноября 2020</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton"> Посетите KubeCon в Шанхае, с 28 по 30 июля 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Посетите KubeCon EU онлайн, 4 – 7 мая 2021</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
diff --git a/content/ru/community/_index.html b/content/ru/community/_index.html
new file mode 100644
index 0000000000..20d7ac5e79
--- /dev/null
+++ b/content/ru/community/_index.html
@@ -0,0 +1,236 @@
+---
+title: Сообщество
+layout: basic
+cid: community
+---
+
+<div class="newcommunitywrapper">
+<div class="banner1">
+  <img src="/images/community/kubernetes-community-final-02.jpg" alt="Галерея конференции Kubernetes" style="width:100%;padding-left:0px" class="desktop">
+  <img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Галерея конференции Kubernetes" style="width:100%;padding-left:0px" class="mobile">
+</div>
+
+<div class="intro">
+<br class="mobile">
+<p>Сообщество Kubernetes — пользователи, участники проекта, и культура, которую мы создаём вместе — одна из главных причин космической скорости роста этого проекта с открытым исходным кодом. Наши культура и ценности продолжают расти и изменяться вместе с проектом. Мы все стремимся к постоянному улучшению проекта и того, как мы над ним работаем.
+<br><br>Мы — люди которые докладывают о проблемах и вносят изменения, участвуют во встречах, митапах Kubernetes, и KubeCon, продвигают его внедрение и развитие, запускают <code>kubectl get pods</code>, и поддерживают проект ещё множеством способов. Узнайте как стать частью этого прекрасного сообщества.</p>
+<br class="mobile">
+</div>
+
+<div class="community__navbar">
+
+<a href="#conduct">Кодекс поведения </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<a href="#videos">Видео</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<a href="#discuss">Обсуждения</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<a href="#events">Конференции и митапы</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<a href="#news">Новости</a>
+
+</div>
+<br class="mobile"><br class="mobile">
+<div class="imagecols">
+<br class="mobile">
+  <div class="imagecol">
+    <img src="/images/community/kubernetes-community-final-03.jpg" alt="Галерея конференции Kubernetes" style="width:100%" class="desktop">
+  </div>
+
+  <div class="imagecol">
+    <img src="/images/community/kubernetes-community-final-04.jpg" alt="Галерея конференции Kubernetes" style="width:100%" class="desktop">
+  </div>
+
+  <div class="imagecol" style="margin-right:0% important">
+    <img src="/images/community/kubernetes-community-final-05.jpg" alt="Галерея конференции Kubernetes" style="width:100%;margin-right:0% important" class="desktop">
+  </div>
+  <img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Галерея конференции Kubernetes" style="width:100%;margin-bottom:3%" class="mobile">
+
+<a name="conduct"></a>
+</div>
+
+
+
+<div class="conduct">
+<div class="conducttext">
+<br class="mobile"><br class="mobile">
+<br class="tablet"><br class="tablet">
+<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Кодекс поведения</h1>
+Сообщество Kubernetes ценит уважение и инклюзивность, и следит за соблюдением Кодекса поведения. Если вы столкнулись с нарушением Кодекса поведения на конференции или митапе, в Slack, или другом средстве коммуникации, обратитесь в Комитет Кодекса поведения Kubernetes на <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>. Все обращения анонимны. Вы можете почитать о комитете&nbsp;<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">здесь</a>.
+<br>
+<a href="https://kubernetes.io/community/code-of-conduct/">
+<br class="mobile"><br class="mobile">
+
+<span class="fullbutton">
+УЗНАТЬ БОЛЬШЕ
+</span>
+</a>
+</div><a name="videos"></a>
+</div>
+</div>
+
+
+
+<div class="videos">
+<br class="mobile"><br class="mobile">
+<br class="tablet"><br class="tablet">
+<h1 style="margin-top:0px">Видео</h1>
+
+<div style="margin-bottom:4%;font-weight:300;text-align:center;padding-left:10%;padding-right:10%">У нас много видео на YouTube. Подписывайтесь чтобы не пропустить видео на самые разные&nbsp;темы.</div>
+
+<div class="videocontainer">
+
+<div class="video">
+
+  <iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="Ежемесячные офисные часы" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+
+<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
+<div class="videocta">
+Ежемесячные офисные часы&nbsp;&#9654;</div>
+</a>
+</div>
+
+<div class="video">
+  <iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="Еженедельные встречи сообщества" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
+<div class="videocta">
+Еженедельные встречи сообщества&nbsp;&#9654;
+</div>
+</a>
+</div>
+
+<div class="video">
+
+<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="Доклады от участников сообщества" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+
+<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
+<div class="videocta">
+Доклады от участников сообщества&nbsp;&#9654;
+</div>
+
+</a>
+<a name="discuss"></a>
+</div>
+</div>
+</div>
+
+
+<div class="resources">
+<br class="mobile"><br class="mobile">
+<br class="tablet"><br class="tablet">
+<h1 style="padding-top:1%">Обсуждения</h1>
+
+<div style="font-weight:300;text-align:center">Мы много общаемся. Присоединяйтесь к нам на платформе которая вам&nbsp;подходит.</div>
+
+<div class="resourcecontainer">
+
+<div class="resourcebox">
+<img src="/images/community/discuss.png" alt=Форум" style="width:80%;padding-bottom:2%">
+<a href="https://discuss.kubernetes.io/" style="color:#0662EE;display:block;margin-top:1%">
+форум&nbsp;&#9654;
+</a>
+<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
+Тематические технические дискуссии о документации, StackOverflow, и многом&nbsp;другом
+</div>
+</div>
+
+<div class="resourcebox">
+<img src="/images/community/twitter.png" alt="Твиттер" style="width:80%;padding-bottom:2%">
+<a href="https://twitter.com/kubernetesio" style="color:#0662EE;display:block;margin-top:1%">
+Твиттер&nbsp;&#9654;
+</a>
+<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">Анонсы блогов, событий, новостей и идей в реальном времени
+</div>
+</div>
+
+<div class="resourcebox">
+<img src="/images/community/github.png" alt="Гитхаб" style="width:80%;padding-bottom:2%">
+<a href="https://github.com/kubernetes/kubernetes" style="color:#0662EE;display:block;margin-top:1%">
+Гитхаб&nbsp;&#9654;
+</a>
+<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
+Отслеживание issue проекта, и конечно же исходный код
+</div>
+</div>
+
+<div class="resourcebox">
+<img src="/images/community/stack.png" alt="Stack Overflow" style="width:80%;padding-bottom:2%">
+<a href="https://stackoverflow.com/search?q=kubernetes" style="color:#0662EE;display:block;margin-top:1%">
+stack overflow&nbsp;&#9654;
+</a>
+<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
+  Техническая помощь на любой&nbsp;случай
+  <a name="events"></a>
+</div>
+</div>
+
+<!--
+<div class="resourcebox">
+
+<img src="/images/community/slack.png" style="width:80%">
+
+slack&nbsp;&#9654;
+
+<div class="resourceboxtext" style="font-size:11px;text-transform:none !important;font-weight:200;line-height:1.4em;color:#333333;margin-top:4%">
+With 170+ channels, you'll find one that fits your needs.
+</div>
+
+</div>-->
+
+</div>
+</div>
+<div class="events">
+  <br class="mobile"><br class="mobile">
+  <br class="tablet"><br class="tablet">
+<div class="eventcontainer">
+ <h1 style="color:white !important">Предстоящие события</h1>
+    {{< upcoming-events >}}
+</div>
+</div>
+
+<div class="meetups">
+<div class="meetupcol">
+<div class="meetuptext">
+<h1 style="text-align:left">Мировое сообщество</h1>
+Мы провели уже более 150 митапов по всему миру. Найдите участников сообщества рядом с вами, а если таких нет, то возьмите ситуацию в свои руки и создайте сообщество.
+</div>
+<a href="https://www.meetup.com/topics/kubernetes/">
+<div class="button">
+НАЙТИ МИТАП
+</div>
+</a>
+<a name="news"></a>
+</div>
+</div>
+
+
+<!--
+<div class="contributor">
+<div class="contributortext">
+<br>
+<h1 style="text-align:left">
+New Contributors Site
+ </h1>
+Text about new contributors site.
+
+<br><br>
+
+<div class="button">
+VISIT SITE
+</div>
+</div>
+</div>
+
+-->
+
+<div class="news">
+<br class="mobile"><br class="mobile">
+<br class="tablet"><br class="tablet">
+<h1 style="margin-bottom:2%">Последние новости</h1>
+
+<br>
+<div class="twittercol1">
+<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">Твиты от kubernetesio</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
+</div>
+
+<br>
+<br><br><br><br>
+</div>
+
+</div>
diff --git a/content/ru/community/code-of-conduct.md b/content/ru/community/code-of-conduct.md
new file mode 100644
index 0000000000..a4386b67e4
--- /dev/null
+++ b/content/ru/community/code-of-conduct.md
@@ -0,0 +1,26 @@
+---
+title: Сообщество
+layout: basic
+cid: community
+css: /css/community.css
+---
+
+<div class="community_main">
+<h1>Кодекс поведения сообщества Kubernetes</h1>
+
+Kubernetes следует
+<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">Кодексу Поведения CNCF</a>.
+Текст кодекса CNCF продублирован здесь, на момент
+<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">коммита 214585e</a>.
+Если вы заметили что он устарел, пожалуйста
+<a href="https://github.com/kubernetes/website/issues/new">создайте issue</a>.
+
+Если вы столкнулись с нарушением кодекса поведения во время конференции или митапа, в Slack, или другом средстве общения, обратитесь в
+<a href="https://git.k8s.io/community/committee-code-of-conduct">Комитет кодекса поведения Kubernetes</a>.
+Вы можете написать нам на электронную почту <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
+Ваша анонимность гарантирована.
+
+<div class="cncf_coc_container">
+{{< include "/static/cncf-code-of-conduct.md" >}}
+</div>
+</div>
diff --git a/content/ru/community/static/README.md b/content/ru/community/static/README.md
new file mode 100644
index 0000000000..4a448d9754
--- /dev/null
+++ b/content/ru/community/static/README.md
@@ -0,0 +1,2 @@
+Файлы в этой диркетории было импортированы из других источников.
+Не редактируйте их напрямую, вместо этого заменяйте их более новыми версиями.
diff --git a/content/ru/community/static/cncf-code-of-conduct.md b/content/ru/community/static/cncf-code-of-conduct.md
new file mode 100644
index 0000000000..34adc86258
--- /dev/null
+++ b/content/ru/community/static/cncf-code-of-conduct.md
@@ -0,0 +1,42 @@
+<!-- Не редактируйте этот файл напрямую. Используйте последнюю версию с
+     https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ru.md -->
+Кодекс поведения Сообщества CNCF v1.0
+------------------------------------
+
+### Кодекс поведения Сообщества
+
+В качестве участников и кураторов этого проекта, а также в интересах создания
+открытого и гостеприимного сообщества, мы обязуемся уважать всех людей, которые вносят свой вклад
+через сообщения о неполадках, разработку нового функционала, обновление документации,
+исправление неполадок, а также другие действия.
+
+Мы стремимся сделать участие в этом проекте беспрепятственным для
+каждого, независимо от опыта, пола, гендерной идентичности и самовыражения,
+сексуальной ориентации, наличия инвалидности, внешности, роста, расы, этнической принадлежности, возраста,
+религии или национальности.
+
+Недопустимы следующие примеры поведения участников:
+
+* Использование оборотов речи или изображений сексуального характера
+* Личностные оскорбления
+* Троллинг или оскорбительные / уничижительные комментарии
+* Домогательства любой формы и проявления
+* Публикация личной информации других лиц, такой как физические или электронные адреса,
+  без явного разрешения от этих лиц
+* Другое неэтичное или непрофессиональное поведение.
+
+Кураторы проекта имеют право и ответственность удалять, редактировать или отклонять
+комментарии, коммиты, код, правки вики, вопросы и другие материалы, которые не соответствуют критериям Кодекса поведения. Приняв этот Кодекс поведения, кураторы проекта
+берут на себя обязательство справедливо и последовательно применять эти принципы к каждому аспекту
+управления этим проектом. Участники проекта, которые не следуют или не соблюдают Кодекс
+Поведения могут быть навсегда удалены из проекта.
+
+Этот кодекс поведения применяется, как внутри проекта так и в публичных местах,
+когда человек представляет проект или его сообщество.
+
+Чтобы проинформировать о злоупотреблении, преследовании и других видах неприемлемого поведения в Kubernetes, отправьте сообщение в [Комитет правил поведения в Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) на электронный адрес: <conduct@kubernetes.io>. Информацию о других проектах можно получить у координатора проектов фонда CNCF или нашего посредника Миши Чоундари (Mishi Choudhary) <mishi@linux.com>.
+
+### Кодекс поведения на мероприятия CNCF
+
+Мероприятия и Эвенты CNCF регулируются Linux Foundation [Кодекс поведения] (https://events.linuxfoundation.org/code-of-conduct/), доступным на странице мероприятий. Он разработан
+в соответствии с вышеупомянутой политикой и также включает больше деталей относительно того, как реагировать на инциденты.
diff --git a/content/ru/docs/contribute/intermediate.md b/content/ru/docs/contribute/intermediate.md
index d43d415314..ba3b06511f 100644
--- a/content/ru/docs/contribute/intermediate.md
+++ b/content/ru/docs/contribute/intermediate.md
@@ -493,7 +493,7 @@ PR объединяется, когда у него есть комментар
 
 #### Заявки с помощью или отчёты об ошибке в коде
 
-Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `triage/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого).
+Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `kind/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого).
 
 Пример ответа на запрос о помощи:
 
diff --git a/content/ru/docs/reference/kubectl/overview.md b/content/ru/docs/reference/kubectl/overview.md
index 9f1fd9906e..58305f2d95 100644
--- a/content/ru/docs/reference/kubectl/overview.md
+++ b/content/ru/docs/reference/kubectl/overview.md
@@ -74,7 +74,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 `apply`            | `kubectl apply -f FILENAME [flags]`| Внести изменения в конфигурацию ресурса из файла или потока stdin.
 `attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Подключиться к запущенному контейнеру либо для просмотра потока вывода, либо для работы с контейнером (stdin).
 `autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | Автоматически промасштабировать набор подов, управляемых контроллером репликации.
-`cluster-info`    | `kubectl cluster-info [flags]` | Показать информацию о главном узле и сервисов в кластере.
+`cluster-info`    | `kubectl cluster-info [flags]` | Показать информацию о главном узле и сервисах в кластере.
 `config`        | `kubectl config SUBCOMMAND [flags]` | Изменить файлы kubeconfig. Подробные сведения смотрите в отдельных подкомандах.
 `create`        | `kubectl create -f FILENAME [flags]` | Создать один или несколько ресурсов из файла или stdin.
 `delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов.
diff --git a/content/ru/docs/setup/learning-environment/minikube.md b/content/ru/docs/setup/learning-environment/minikube.md
index af7c8b293c..500d171abe 100644
--- a/content/ru/docs/setup/learning-environment/minikube.md
+++ b/content/ru/docs/setup/learning-environment/minikube.md
@@ -28,7 +28,7 @@ Minikube поддерживает следующие возможности Kube
 * Поддержка CNI (Container Network Interface)
 * Ingress
 
-## Установке
+## Установка
 
 Посмотрите страницу [Установка Minikube](/ru/docs/tasks/tools/install-minikube/).
 
diff --git a/content/ru/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ru/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index a473d280d3..a918dd2d6f 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
               Данный экран слишком маленький, чтобы работать с терминалом, пожалуйста, используйте компьютер или планшет.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index f95fd9537b..02b45c8da2 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -31,7 +31,7 @@ weight: 20
                 Для работы с терминалом, пожалуйста, используйте компьютер или планшет.
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/ru/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ru/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index b0c9e767cb..ec9f66a43c 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 Для работы с терминалом, пожалуйста, используйте компьютер или планшет.
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ru/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ru/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 791d1a82e2..be2d9c85a8 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для работы с терминалом, пожалуйста, используйте компьютер или планшет.
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ru/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ru/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index e429b92118..d7d82990bf 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для работы с терминалом, пожалуйста, используйте компьютер или планшет
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/ru/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ru/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 5dbfa154df..1c7b42b73e 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для работы с терминалом, пожалуйста, используйте компьютер или планшет
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/uk/_index.html b/content/uk/_index.html
index 4bef7023f6..ae7873ea7a 100644
--- a/content/uk/_index.html
+++ b/content/uk/_index.html
@@ -62,12 +62,13 @@ Kubernetes - проект з відкритим вихідним кодом. В
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Переглянути відео</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Відвідати KubeCon в Амстердамі, 30.03-02.04 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Відвідайте KubeCon NA онлайн, 17-20 листопада 2020 року</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Відвідати KubeCon у Шанхаї, 28-30 липня 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Відвідайте KubeCon EU онлайн, 17-20 травня 2021 року</a>
+
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
diff --git a/content/uk/docs/tasks/tools/install-minikube.md b/content/uk/docs/tasks/tools/install-minikube.md
new file mode 100644
index 0000000000..3ddc95faa0
--- /dev/null
+++ b/content/uk/docs/tasks/tools/install-minikube.md
@@ -0,0 +1,264 @@
+---
+title: Встановлення Minikube
+content_template: task
+weight: 20
+card:
+  name: tasks
+  weight: 10
+---
+
+<!-- overview -->
+
+<!--This page shows you how to install [Minikube](/docs/tutorials/hello-minikube),
+a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
+-->
+
+Ця сторінка описує як встановити [Minikube](/docs/tutorials/hello-minikube), інструмент який дозволяє
+запустити  Kubernetes кластер з однієї ноди у віртуальній машині на вашому персональному комп'ютері.
+
+
+## {{% heading "prerequisites" %}}
+
+{{< tabs name="minikube_before_you_begin" >}}
+{{% tab name="Linux" %}}
+Для перевірки, чи підтримується віртуалізація на Linux, запустіть наступну команду і впевніться що вивід команди не пустий:
+```
+grep -E --color 'vmx|svm' /proc/cpuinfo
+```
+{{% /tab %}}
+
+{{% tab name="macOS" %}}
+Для перевірки, чи підтримується віртуалізація на macOS, запустіть наступну команду в терміналі.
+```
+sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
+```
+Якщо ви бачите `VMX` у виводі (має бути кольоровий), то VT-x опція включена на вашому хості.
+{{% /tab %}}
+
+{{% tab name="Windows" %}}
+Для перевірки, чи підтримується віртуалізація на  Windows 8 та версіях вище, запустіть наступну команду в терміналі
+вашого або через command prompt.
+```
+systeminfo
+```
+Якщо ви бачите наступне, віртуалізація підтримується на Windows.
+```
+Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
+                          Virtualization Enabled In Firmware: Yes
+                          Second Level Address Translation: Yes
+                          Data Execution Prevention Available: Yes
+```
+
+Якщо ви бачите наступнний вивід, на вашій системі вже встановлен гіпервізор і ви можете пропустити наступний крок.
+```
+Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.
+```
+
+
+{{% /tab %}}
+{{< /tabs >}}
+
+
+
+<!-- steps -->
+
+# Встановлення Minikube
+
+{{< tabs name="tab_with_md" >}}
+{{% tab name="Linux" %}}
+
+### Встановлення kubectl
+
+Впевніться що kubectl встановлен. Ви можете встановити kubectl згідно інструкції [Установка та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
+
+### Встановлення Hypervisor
+
+Якщо у вас немає встановленого гіпервізора, то встановіть один з наступних:
+
+• [KVM](https://www.linux-kvm.org/), який також використовує QEMU
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+Minikube також пітримує опцію `--driver=none` яка дозволяє запускати компоненти Kubernetes
+на хост системі, ні в віртуальній машині.
+Використання цього драйвера вимагає [Docker](https://www.docker.com/products/docker-desktop) та Linux оточення але не гіпервізор.
+
+Якщо ви використувуєте `none` драйвер у Debian або похідних дістрибутивах, використовуйте `.deb` пакети для
+Docker замість встановлення snap пакетів, які не працюють з Minikube.
+Ви можете скачати `.deb` пакети звідси [Docker](https://www.docker.com/products/docker-desktop).
+
+{{< caution >}}
+`none` VM драйвер може привести до проблем з безпекою та втрати даних.
+Перед тим, як використовувати `--driver=none`, ознайомтесь [з цієй документацієй](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) для отримання додаткової інформації.
+{{< /caution >}}
+
+Minikube також підтримує `vm-driver=podman` схожий на Docker драйвер. Podman запущений як суперюзер (root user) це найкрайщий  шлях забезпечити повний доступ ваших контейнерів до будь-якої функції, наявної у вашій системі.
+
+{{< caution >}}
+`podman` драйвер вимагає запущені контейнери з під root користувача оскільки звичайні облікові записи користувачів не мають повного доступу до всіх функцій операційної системи, які, можливо, потребуватимуть їх роботи.
+{{< /caution >}}
+
+### Встановлення Minikube як Linux пакет
+
+Доступні *experimental* пакети для Minikube; ви можете знайти Linux (AMD64) пакети
+для Minikube's [releases](https://github.com/kubernetes/minikube/releases) на сторінці GitHub.
+
+Використовувайте ваш Linux інсталер пакетів для того, шоб поставити відповідний пакет.
+
+### Встановлення Minikube за допомогою прямого завантаження
+
+Якщо ви не можете встановити Minikube за допомогою пакета, ви можете скачати автономний бінарний файл,
+та використати його.
+
+```shell
+curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
+  && chmod +x minikube
+```
+
+Ось простий спосіб додати виконуваний файл Minikube до вашого шляху:
+
+```shell
+sudo mkdir -p /usr/local/bin/
+sudo install minikube /usr/local/bin/
+```
+
+### Встановлення Minikube використовуючи Homebrew
+
+Як альтернативний варіант, ви можете установити Minikube використовуючи Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux):
+
+```shell
+brew install minikube
+```
+
+{{% /tab %}}
+{{% tab name="macOS" %}}
+### Встановлення kubectl
+
+Впевніться шо kubectl встановлен. Ви можете встановити kubectl згідно інструкції [Установка та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
+
+### Встановлення Hypervisor
+
+Якщо у вас немає встановленого гіпервізора, то встановіть один з наступних:
+
+• [HyperKit](https://github.com/moby/hyperkit)
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+• [VMware Fusion](https://www.vmware.com/products/fusion)
+
+### Встановлення Minikube
+Найпростіший спосіб встановити Minikube на macOS це використати [Homebrew](https://brew.sh):
+
+```shell
+brew install minikube
+```
+
+Ви також можете встановити Minikube за допомогою автономного бінарного файла:
+
+```shell
+curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
+  && chmod +x minikube
+```
+
+Ось простий спосіб додати виконуваний файл Minikube до вашого шляху:
+
+```shell
+sudo mv minikube /usr/local/bin
+```
+
+{{% /tab %}}
+{{% tab name="Windows" %}}
+### Встановлення kubectl
+
+Впевніться шо kubectl встановлен. Ви можете встановити kubectl згідно інструкції [Установка та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
+
+### Встановлення Hypervisor
+
+Якщо у вас немає встановленого гіпервізора, то встановіть один з наступних:
+
+• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+{{< note >}}
+Hyper-V може бути запущен на трьох версіях Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
+{{< /note >}}
+
+### Встановлення Minikube за допомогою Chocolatey
+
+Найпростіший спосіб встановити Minikube на  Windows за допомогою [Chocolatey](https://chocolatey.org/) (run as an administrator):
+
+```shell
+choco install minikube
+```
+
+Коли Minikube закінчив установку, закрийте поточну CLI сесію та перезавантажтесь. Minikube має бути додан до вашого шляху автоматично.
+
+### Встановлення Minikube за допомогою програми встановлення
+
+Для установкі Minikube вручну на Windows за допомогою [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), скачайте [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) та виконайте програму.
+
+### Встановлення Minikube за допомогою прямого завантаження
+
+Для встановлення Minikube вручну на Windows, скачайте [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), перейменуйте  в `minikube.exe`, та додайте до вашего шляху.
+
+{{% /tab %}}
+{{< /tabs >}}
+
+
+
+## {{% heading "whatsnext" %}}
+
+* [Запуск Kubernetes локально за допомогою Minikube](/docs/setup/learning-environment/minikube/)
+
+
+## Підтвердження встановлення
+
+Щоб підтвердити успішну установку як гіпервізора, так і Minikube, ви можете запустити таку команду, щоб запустити локальний кластер Kubernetes:
+
+{{< note >}}
+
+Щоб встановити `--driver` за допомогою` minikube start`, введіть ім'я гіпервізора, який ви встановили, малими літерами, де `<driver_name>` згадано нижче. Повний список значень `--driver` доступний у [вказуванні документації на драйвер VM](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
+
+{{< /note >}}
+
+```shell
+minikube start --driver=<driver_name>
+```
+
+Як тількі `minikube start` закінчився, запустіть команду нижче, щоб перевірити стан кластера:
+
+```shell
+minikube status
+```
+Якщо ваш кластер працює, вивід із "minikube status" має бути аналогічним:
+
+```
+host: Running
+kubelet: Running
+apiserver: Running
+kubeconfig: Configured
+```
+
+Після того, як ви підтвердили, чи Minikube працює з обраним вами гіпервізором, ви можете продовжувати використовувати Minikube або ви можете зупинити кластер. Щоб зупинити кластер, запустіть:
+
+```shell
+minikube stop
+```
+
+## Очистити локальний стан {#cleanup-local-state}
+
+Якщо ви раніше встановили Minikube та запустили:
+```shell
+minikube start
+```
+
+але `minikube start` повертає помилку:
+```
+machine does not exist
+```
+
+тоді вам треба очистити локальний стан minikube:
+```shell
+minikube delete
+```
diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index f90f229c2a..ddcbbc1416 100644
--- a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для роботи з терміналом використовуйте комп'ютер або планшет
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index d91c2bb1c0..0974776265 100644
--- a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -23,7 +23,7 @@ weight: 20
                 Для роботи з терміналом використовуйте комп'ютер або планшет
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index 56a3793019..59a46eabaf 100644
--- a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 Для роботи з терміналом використовуйте комп'ютер або планшет
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 9ed658fa21..cd52d244cb 100644
--- a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для роботи з терміналом використовуйте комп'ютер або планшет
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index a405a98e92..253e6119ad 100644
--- a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для роботи з терміналом використовуйте комп'ютер або планшет
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 0ac0d169a8..9ecd8aa95a 100644
--- a/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Для роботи з терміналом використовуйте комп'ютер або планшет
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/vi/_index.html b/content/vi/_index.html
index f782a0fcb2..ec3e946481 100644
--- a/content/vi/_index.html
+++ b/content/vi/_index.html
@@ -41,7 +41,6 @@ Kubernetes là dự án mã nguồn mở cho phép bạn tự do tận dụng c
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Xem Video</button>
         <br>
         <br>
-        <br>
         <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Tham gia KubeCon Amsterdam 30/03-02/04/2020</a>
         <br>
         <br>
diff --git a/content/vi/docs/tutorials/kubernetes-basics/_index.html b/content/vi/docs/tutorials/kubernetes-basics/_index.html
new file mode 100644
index 0000000000..2440ca5e67
--- /dev/null
+++ b/content/vi/docs/tutorials/kubernetes-basics/_index.html
@@ -0,0 +1,116 @@
+---
+title: Học kiến thức cơ bản về Kubernetes
+linkTitle: Học kiến thức cơ bản về Kubernetes
+weight: 10
+card:
+  name: Các hướng dẫn
+  weight: 20
+  title: Hướng dẫn những điều cơ bản
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+  <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+  <main class="content">
+
+    <div class="row">
+      <div class="col-md-9">
+        <h2>Kiến thức cơ bản về Kubernetes</h2>
+        <p>Hướng dẫn này cung cấp những kiến thức cơ bản về một cụm Kubernetes. Mỗi mô-đun chứa một số thông tin cơ bản về các tính năng cũng như khái niệm chính của Kubernetes, đồng thời bao gồm một hướng dẫn tương tác trực tuyến. Các hướng dẫn tương tác này giúp bạn quản lý một cluster đơn giản và các ứng dụng được đóng gói của bạn.</p>
+        <p>Bằng các hướng dẫn tương tác, bạn có thể học cách:</p>
+        <ul>
+        <li>Triển khai một ứng dụng container trong một cluster.</li>
+        <li>Thay đổi quy mô triển khai.</li>
+        <li>Cập nhật ứng dụng container.</li>
+        <li>Debug ứng dụng container.</li>
+        </ul>
+        <p>Những hướng dẫn này dùng Katacoda để chạy một terminal ảo trên trình duyệt web của bạn chạy Minikube. Không cần phải cài đặt và cấu hình bất kỳ phần mềm nào; mỗi hướng dẫn tương tác chạy trực tiếp từ trình duyệt web của bạn.</p>
+      </div>
+    </div>
+
+    <br>
+
+    <div class="row">
+      <div class="col-md-9">
+        <h2>Kubernetes có thế làm những gì?</h2>
+        <p>Với các dịch vụ web hiện đại, người dùng mong muốn các ứng dụng luôn sẵn sàng hoạt động 24/7 và các lập trình viên muốn triển khai các phiên bản của ứng dụng đó nhiều lần trong ngày. Việc đóng gói ứng dụng vào container giúp giải quyết mục tiêu này, cho phép các ứng dụng được phát hành và cập nhật một cách dễ dàng, nhanh chóng mà không có downtime. Kubernetes giúp bạn đảm bảo các ứng dụng container chạy ở bất kì đâu và bất kì lúc nào bạn muốn, đồng thời giúp chúng tìm thấy các tài nguyên và công cụ cần thiết để chạy. Kubernetes là nền tảng mã nguồn mở, chạy được trong môi trường production, được thiết kế và phát triển bởi Google, kết hợp với những ý tưởng tốt nhất từ cộng đồng.</p>
+      </div>
+    </div>
+
+    <br>
+    
+    <div id="basics-modules" class="content__modules">
+      <h2>Những mô-đun Kubernetes cơ bản</h2>
+      <div class="row">
+        <div class="col-md-12">
+          <div class="row">
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><h5>1. Tạo mới một cụm Kubernetes</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><h5>2. Triển khai ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><h5>3. Khám phá ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-12">
+          <div class="row">
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><h5>4. Đưa ứng dụng ra public</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_05.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/"><h5>5. Scale ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/update/update-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_06.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/update/update-intro/"><h5>6. Cập nhật ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+          </div>
+        </div>
+      </div>
+    </div>
+
+  </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index b9adf950b8..76fd8004ee 100644
--- a/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -21,7 +21,7 @@ weight: 20
             <div class="katacoda__alert">
                 Để tương tác với Terminal, hãy dùng phiên bản dành cho desktop/tablet
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/vi/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/vi/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 9cba9b9ee6..b3b0b141af 100644
--- a/content/vi/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/vi/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -23,7 +23,7 @@ weight: 20
                 Để tương tác với Terminal, hãy sử dụng phiên bản dành cho desktop/tablet
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index c592705757..2a8d45f170 100644
--- a/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -24,7 +24,7 @@ weight: 20
                 Để tương tác với Terminal, hãy sử dụng phiên bản dành cho desktop/tablet
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md b/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
index 86c0fd1ae3..5606cf9c2c 100644
--- a/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
+++ b/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
@@ -615,7 +615,7 @@ kubectl cp <local file> <namespace>/<pod>:/root/airflow/dags -c scheduler
 
 
 
-This feature is just the beginning of multiple major efforts to improves Apache Airflow integration into Kubernetes. The Kubernetes Operator has been merged into the 1.10 release branch of Airflow (the executor in experimental mode), along with a fully k8s native scheduler called the Kubernetes Executor (article to come). These features are still in a stage where early adopters/contributers can have a huge influence on the future of these features.
+This feature is just the beginning of multiple major efforts to improves Apache Airflow integration into Kubernetes. The Kubernetes Operator has been merged into the 1.10 release branch of Airflow (the executor in experimental mode), along with a fully k8s native scheduler called the Kubernetes Executor (article to come). These features are still in a stage where early adopters/contributors can have a huge influence on the future of these features.
 
 
 
diff --git a/content/zh/blog/_posts/2019-09-24-san-diego-contributor-summit.md b/content/zh/blog/_posts/2019-09-24-san-diego-contributor-summit.md
new file mode 100644
index 0000000000..66f572a305
--- /dev/null
+++ b/content/zh/blog/_posts/2019-09-24-san-diego-contributor-summit.md
@@ -0,0 +1,136 @@
+---
+layout: blog
+title: "San Diego 贡献者峰会开放注册！"
+date: 2019-09-24
+slug: san-diego-contributor-summit
+---
+<!--
+---
+layout: blog
+title: "Contributor Summit San Diego Registration Open!"
+date: 2019-09-24
+slug: san-diego-contributor-summit
+---
+--->
+
+<!--
+**Authors: Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware)**
+--->
+**作者：Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware)**
+
+
+
+<!--
+[Contributor Summit San Diego 2019 Event Page]  
+Registration is now open and in record time, we’ve hit capacity for the
+*new contributor workshop* session of the event! Waitlist is now available.
+--->
+[2019 San Diego 贡献者峰会活动页面](https://events.linuxfoundation.org/events/kubernetes-contributor-summit-north-america-2019/)
+注册已经开放，并且在创纪录的时间内，*新贡献者研讨会* 活动已满员！候补名单已经开放。
+
+<!--
+**Sunday, November 17**  
+Evening Contributor Celebration:  
+[QuartYard]*  
+Address: 1301 Market Street, San Diego, CA 92101  
+Time: 6:00PM - 9:00PM  
+--->
+**11月17日，星期日**  
+晚间贡献者庆典：  
+[QuartYard]*  
+地址: 1301 Market Street, San Diego, CA 92101  
+时间: 下午6:00 - 下午9:00
+
+<!--
+**Monday, November 18**  
+All Day Contributor Summit:  
+[Marriott Marquis San Diego Marina]  
+Address: 333 W Harbor Dr, San Diego, CA 92101  
+Time: 9:00AM - 5:00PM  
+--->
+**11月18日，星期一**  
+全天贡献者峰会：  
+[Marriott Marquis San Diego Marina]  
+地址: 333 W Harbor Dr, San Diego, CA 92101  
+时间: 上午9:00 - 下午5:00  
+
+
+<!--
+While the Kubernetes project is only five years old, we’re already going into our
+9th Contributor Summit this November in San Diego before KubeCon + CloudNativeCon.
+The rapid increase is thanks to adding European and Asian Contributor Summits to
+the North American events we’ve done previously. We will continue to run Contributor
+Summits across the globe, as it is important that our contributor base grows in
+all forms of diversity.
+--->
+虽然 Kubernetes 项目只有五年的历史，但是在 KubeCon + CloudNativeCon 之前，今年11月在圣迭戈时我们举办的第九届贡献者峰会了。快速增长的原因是在我们之前所做的北美活动中增加了欧洲和亚洲贡献者峰会。我们将继续在全球举办贡献者峰会，因为重要的是，我们的贡献者要以各种形式的多样性地成长。
+
+<!--
+Kubernetes has a large distributed remote contributing team, from [individuals and
+organizations] all over the world. The Contributor Summits give the community three
+chances a year to get together, work on community topics, and have hallway track
+time. The upcoming San Diego summit is expected to bring over 450 attendees, and
+will contain multiple tracks with something for everyone. The focus will be around
+contributor growth and sustainability. We're going to stop here with capacity for
+future summits; we want this event to offer value to individuals and the project.
+We've heard from past summit attendee feedback that getting work done, learning,
+and meeting folks face to face is a priority. By capping attendance and offering
+the contributor gatherings in more locations, it will help us achieve those goals.
+--->
+Kubernetes 拥有一个庞大的分布式远程贡献团队，由来自世界各地的 [个人和组织](https://k8s.devstats.cncf.io/d/8/company-statistics-by-repository-group?orgId=1&var-period=y&var-metric=contributions&var-repogroup_name=All&var-companies=All) 组成。贡献者峰会每年为社区提供三次聚会的机会，围绕社区主题开展工作，并有互相了解的时间。即将举行的 San Diego 峰会预计将吸引 450 多名与会者，并将包含多个方向，适合所有人。重点将围绕贡献者的增长和可持续性。我们将在这里停留，为举行未来峰会做准备；我们希望这次活动为个人和项目提供价值。我们已经从峰会与会者的反馈中得知，完成工作、学习和与人们面对面交流是当务之急。通过限制参加人数并在更多地方提供贡献者聚会，将有助于我们实现这些目标。
+
+<!--
+This summit is unique as we’ve taken big moves on sustaining ourselves, the
+contributor experience events team. Taking a page from the release team’s playbook,
+we have added additional core team and shadow roles making it a natural mentoring
+(watching+doing) relationship. The shadows are expected to fill another role at
+one of the three events in 2020, and core team members to take the lead.
+In preparation for this team, we’ve open sourced our [rolebooks, guidelines,
+best practices] and opened up our [meetings] and [project board]. Our team makes up
+many parts of the Kubernetes project and takes care of making sure all voices
+are represented.
+--->
+这次峰会是独一无二的，因为我们在贡献者体验活动团队的坚持自我方面已采取了重大举措。从发行团队的手册中摘录，我们添加了其他核心团队和跟随学习角色，使其成为天然的辅导关系（包括监督和实施）。预计跟随学习者将在 2020 年的三项活动中扮演另一个角色，核心团队成员将带头完成。为这个团队做准备，我们开源了 [技术手册，指南，最佳做法](https://github.com/kubernetes/community/tree/master/events/events-team)，并开放了 [会议](https://docs.google.com/document/d/1oLXv5_rM4f645jlXym_Vd7AUq7x6DV-O87E6tcW1sjU/edit?usp=sharing) 和 [项目委员会](https://github.com/orgs/kubernetes/projects/21)。我们的团队组成了 Kubernetes 项目的许多部分，并确保所有声音都得到体现。
+
+<!--
+Are you at KubeCon + CloudNativeCon but can’t make it to the summit? Check out
+the [SIG Intro and Deep Dive sessions] during KubeCon + CloudNativeCon to
+participate in Q&A and hear what’s up with each Special interest Group (SIG).
+We’ll also record all of Contributor Summit’s presentation sessions, take notes
+in discussions, and share it back with you, after the event is complete.
+--->
+您是否已经在 KubeCon + CloudNativeCon 上，但无法参与会议？ 在 KubeCon + CloudNativeCon 期间查看 [SIG入门和深潜课程](https://kccncna19.sched.com/overview/type/Maintainer+Track+Sessions?iframe=yes) 参与问答，并听取每个特殊兴趣小组（SIG）的最新消息。活动结束后，我们还将记录所有贡献者峰会的课题，在讨论中做笔记，并与您分享。
+
+<!--
+We hope to see you all at Kubernetes Contributor Summit San Diego, make sure you
+head over and [register right now]! This event will sell out - here’s your warning.
+:smiley:
+--->
+我们希望能在 San Diego 的 Kubernetes 贡献者峰会上与大家见面，确保您直接进入并点击 [立即注册](https://events.linuxfoundation.org/events/kubernetes-contributor-summit-north-america-2019/)！ 此活动将关闭 - 特此提醒。 ：笑脸：
+
+<!--
+Check out past blogs on [persona building around our events] and the [Barcelona summit story].
+
+![Group Picture in 2018](/images/blog/2019-09-24-san-diego-contributor-summit/IMG_2588.JPG)
+--->
+查看往期博客有关 [围绕我们的活动构建角色](https://kubernetes.io/blog/2019/03/20/a-look-back-and-whats-in-store-for-kubernetes-contributor-summits/) 和 [巴塞罗那峰会故事](https://kubernetes.io/blog/2019/06/25/recap-of-kubernetes-contributor-summit-barcelona-2019/)。
+
+！[2018年集体照](/images/blog/2019-09-24-san-diego-contributor-summit/IMG_2588.JPG)
+
+<!--
+*=QuartYard has a huge stage! Want to perform something in front of your contributor peers? Reach out to us! community@kubernetes.io
+--->
+*=QuartYard 有一个巨大的舞台！想要在您的贡献者同行面前做点什么？加入我们吧！ community@kubernetes.io
+
+
+[Contributor Summit San Diego 2019 Event Page]: https://events.linuxfoundation.org/events/kubernetes-contributor-summit-north-america-2019/
+[QuartYard]: https://quartyardsd.com/
+[Marriott Marquis San Diego Marina]: https://www.marriott.com/hotels/travel/sandt-marriott-marquis-san-diego-marina/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2
+[individuals and organizations]: https://k8s.devstats.cncf.io/d/8/company-statistics-by-repository-group?orgId=1&var-period=y&var-metric=contributions&var-repogroup_name=All&var-companies=All
+[rolebooks, guidelines, best practices]: https://github.com/kubernetes/community/tree/master/events/events-team
+[meetings]: https://docs.google.com/document/d/1oLXv5_rM4f645jlXym_Vd7AUq7x6DV-O87E6tcW1sjU/edit?usp=sharing
+[project board]: https://github.com/orgs/kubernetes/projects/21
+[SIG Intro and Deep Dive sessions]: https://kccncna19.sched.com/overview/type/Maintainer+Track+Sessions?iframe=yes
+[register right now]: https://events.linuxfoundation.org/events/kubernetes-contributor-summit-north-america-2019/
+[persona building around our events]: https://kubernetes.io/blog/2019/03/20/a-look-back-and-whats-in-store-for-kubernetes-contributor-summits/
+[Barcelona summit story]: https://kubernetes.io/blog/2019/06/25/recap-of-kubernetes-contributor-summit-barcelona-2019/
diff --git a/content/zh/case-studies/adform/index.html b/content/zh/case-studies/adform/index.html
index e9a8acc7a2..be35a2d837 100644
--- a/content/zh/case-studies/adform/index.html
+++ b/content/zh/case-studies/adform/index.html
@@ -12,7 +12,7 @@ quote: >
   Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_adform_banner1.jpg')">
+<div class="banner1 desktop" style="background-image: url('/images/case-studies/adform/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/adform_logo.png" style="width:15%;margin-bottom:0%" class="header_logo"><br> <div class="subhead">Improving Performance and Morale with Cloud Native
 
 </div></h1>
@@ -66,7 +66,7 @@ The company has a large infrastructure: <a href="https://www.openstack.org/">Ope
 
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_adform_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/adform/banner3.jpg')">
   <div class="banner3text">
     "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."<span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Edgaras Apšega, IT Systems Engineer, Adform</span>
   </div>
@@ -83,7 +83,7 @@ The first production cluster was launched in the spring of 2018, and is now up t
 
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_adform_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/adform/banner4.jpg')">
   <div class="banner4text">
 "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Andrius Cibulskis, IT Systems Engineer, Adform</span>
   </div>
diff --git a/content/zh/case-studies/ant-financial/index.html b/content/zh/case-studies/ant-financial/index.html
index 92b46526de..1711ef97b8 100644
--- a/content/zh/case-studies/ant-financial/index.html
+++ b/content/zh/case-studies/ant-financial/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
 featured: false
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_antfinancial_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/antfinancial/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/antfinancial_logo.png" class="header_logo" style="width:20%;margin-bottom:-2.5%"><br> <div class="subhead" style="margin-top:1%">Ant Financial’s Hypergrowth Strategy Using Kubernetes
 
 </div></h1>
@@ -50,7 +50,7 @@ featured: false
   To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced <a href="https://www.docker.com/">Docker</a> containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_antfinancial_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/antfinancial/banner3.jpg')">
   <div class="banner3text">
     "On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL</span>
 
@@ -65,7 +65,7 @@ featured: false
   All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing. Ant’s platform also leverages a number of other CNCF projects, including <a href="https://prometheus.io/">Prometheus</a>, <a href="https://opentracing.io/">OpenTracing</a>, <a href="https://coreos.com/etcd/">etcd</a> and <a href="https://coredns.io/">CoreDNS</a>.  “On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress,” says Ranger Yu, Global Technology Partnership & Development.
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_antfinancial_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/antfinancial/banner4.jpg')">
   <div class="banner4text">
   "We’re very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We’re definitely embracing the community and open source more in the future." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL</span>
   </div>
diff --git a/content/zh/case-studies/appdirect/index.html b/content/zh/case-studies/appdirect/index.html
index 16d93cce5c..ca6b0b8fe9 100644
--- a/content/zh/case-studies/appdirect/index.html
+++ b/content/zh/case-studies/appdirect/index.html
@@ -12,7 +12,7 @@ quote: >
    We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem.
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_appdirect_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/appdirect/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/appdirect_logo.png" class="header_logo" style="margin-bottom:-2%"><br> <div class="subhead" style="margin-top:1%;font-size:0.5em">AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess
 </div></h1>
 
@@ -53,7 +53,7 @@ quote: >
 
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_appdirect_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/appdirect/banner3.jpg')">
   <div class="banner3text">
   "We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Alexandre Gervais, Staff Software Developer, AppDirect
 </span>
@@ -69,7 +69,7 @@ quote: >
   Lacerte’s strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require <a href="https://www.atlassian.com/software/jira">Jira</a> tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_appdirect_banner4.jpg');width:100%;">
+<div class="banner4" style="background-image: url('/images/case-studies/appdirect/banner4.jpg');width:100%;">
   <div class="banner4text">
   "I think our velocity would have slowed down a lot if we didn’t have this new infrastructure."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect</span>
   </div>
diff --git a/content/zh/case-studies/bose/index.html b/content/zh/case-studies/bose/index.html
index d22de2187a..c77f416c13 100644
--- a/content/zh/case-studies/bose/index.html
+++ b/content/zh/case-studies/bose/index.html
@@ -11,7 +11,7 @@ quote: >
    The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles.
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_bose_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/bose/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/bose_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes
 
 </div></h1>
@@ -56,7 +56,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
 
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_bose_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/bose/banner3.jpg')">
   <div class="banner3text">
     "Everybody on the team thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we’ve built with them is a huge piece of that."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Dylan O’Mahony, Cloud Architecture Manager, Bose</span>
 
@@ -70,7 +70,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
 
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_bose_banner4.jpg');width:100%">
+<div class="banner4" style="background-image: url('/images/case-studies/bose/banner4.jpg');width:100%">
   <div class="banner4text">
   "The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Josh West, Lead Cloud Engineer, Bose</span>
   </div>
diff --git a/content/zh/case-studies/capital-one/index.html b/content/zh/case-studies/capital-one/index.html
index 773db4869e..f95fb2acc7 100644
--- a/content/zh/case-studies/capital-one/index.html
+++ b/content/zh/case-studies/capital-one/index.html
@@ -5,7 +5,7 @@ cid: caseStudies
 css: /css/style_case_studies.css
 ---
 
-<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_capitalone_banner1.jpg')">
+<div class="banner1 desktop" style="background-image: url('/images/case-studies/capitalone/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/capitalone-logo.png" style="margin-bottom:-2%" class="header_logo"><br> <div class="subhead">Supporting Fast Decisioning Applications with Kubernetes
 
 </div></h1>
@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
 
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_capitalone_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/capitalone/banner3.jpg')">
   <div class="banner3text">
     "We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."
 
@@ -69,7 +69,7 @@ css: /css/style_case_studies.css
 
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_capitalone_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/capitalone/banner4.jpg')">
   <div class="banner4text">
     With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
   </div>
diff --git a/content/zh/case-studies/ccp-games/ccp_logo.png b/content/zh/case-studies/ccp-games/ccp_logo.png
deleted file mode 100644
index cbf3d267ba..0000000000
Binary files a/content/zh/case-studies/ccp-games/ccp_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/ccp-games/index.html b/content/zh/case-studies/ccp-games/index.html
deleted file mode 100644
index 8867cbb323..0000000000
--- a/content/zh/case-studies/ccp-games/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: CCP Games
-content_url: https://cloud.google.com/customers/ccp-games/
----
\ No newline at end of file
diff --git a/content/zh/case-studies/cern/index.html b/content/zh/case-studies/cern/index.html
index 9bd7970245..48e965d7fb 100644
--- a/content/zh/case-studies/cern/index.html
+++ b/content/zh/case-studies/cern/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
 logo: cern_featured_logo.png
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_cern_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/cern/banner1.jpg')">
   <h1> CASE STUDY: CERN<br> <div class="subhead" style="margin-top:1%">CERN: Processing Petabytes of Data More Efficiently with Kubernetes
 
 </div></h1>
@@ -52,7 +52,7 @@ logo: cern_featured_logo.png
 
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_cern_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/cern/banner3.jpg')">
   <div class="banner3text">
     "Before, the tendency was always: ‘I need this, I get a couple of developers, and I implement it.’ Right now it’s ‘I need this, I’m sure other people also need this, so I’ll go and ask around.’ The CNCF is a good source because there’s a very large catalog of applications available. It’s very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It’s much easier for us to try it out, and if we see it’s a good solution, we try to reach out to the community and start working with that community." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Ricardo Rocha, Software Engineer, CERN</span>
 
@@ -66,7 +66,7 @@ logo: cern_featured_logo.png
 
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_cern_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/cern/banner4.jpg')">
   <div class="banner4text">
   "With Kubernetes, there’s a well-established technology and a big community that we can contribute to. It allows us to do our physics analysis without having to focus so much on the lower level software. This is just exciting. We are looking forward to keep contributing to the community and collaborating with everyone."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Ricardo Rocha, Software Engineer, CERN</span>
   </div>
diff --git a/content/zh/case-studies/chinaunicom/index.html b/content/zh/case-studies/chinaunicom/index.html
index 675273c47f..94a1822a25 100644
--- a/content/zh/case-studies/chinaunicom/index.html
+++ b/content/zh/case-studies/chinaunicom/index.html
@@ -12,7 +12,7 @@ quote: >
    Kubernetes has improved our experience using cloud infrastructure. There is currently no alternative technology that can replace it.
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_chinaunicom_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/chinaunicom/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/chinaunicom_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;line-height:1.4em">China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency<br>and Lower IT&nbsp;Costs
 
 </div></h1>
@@ -55,7 +55,7 @@ quote: >
 
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_chinaunicom_banner3.jpg');width:100%;padding-left:0;">
+<div class="banner3" style="background-image: url('/images/case-studies/chinaunicom/banner3.jpg');width:100%;padding-left:0;">
   <div class="banner3text">
     "We could never imagine we can achieve this scalability in such a short time."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom</span>
 
@@ -69,7 +69,7 @@ quote: >
 
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_chinaunicom_banner4.jpg');width:100%">
+<div class="banner4" style="background-image: url('/images/case-studies/chinaunicom/banner4.jpg');width:100%">
   <div class="banner4text">
   "This technology is relatively complicated, but as long as developers get used to it, they can enjoy all the benefits." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Jie Jia, Member of Platform Technology R&D, China Unicom</span>
   </div>
diff --git a/content/zh/case-studies/city-of-montreal/index.html b/content/zh/case-studies/city-of-montreal/index.html
index 151ce44b21..55378c649e 100644
--- a/content/zh/case-studies/city-of-montreal/index.html
+++ b/content/zh/case-studies/city-of-montreal/index.html
@@ -7,7 +7,7 @@ css: /css/style_case_studies.css
 featured: false
 ---
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_montreal_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/montreal/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/montreal_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed&nbsp;Architecture&nbsp;with&nbsp;Kubernetes
 
 </div></h1>
@@ -50,7 +50,7 @@ featured: false
   The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_montreal_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/montreal/banner3.jpg')">
   <div class="banner3text">
     "Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It’s no longer dependent on deployment. Deployment is so fast that it’s negligible."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MARC KHOUZAM, SOLUTIONS ARCHITECT, CITY OF MONTRÉAL</span>
 
@@ -65,7 +65,7 @@ featured: false
   Another important factor in the decision was vendor neutrality. “As a government entity, it is essential for us to be neutral in our selection of products and providers,” says Thibault. “The independence of the Cloud Native Computing Foundation from any company provides this.”
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_montreal_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/montreal/banner4.jpg')">
   <div class="banner4text">
   "Kubernetes has been great. It’s been stable, and it provides us with elasticity, resilience, and robustness. While re-architecting for Kubernetes, we also benefited from the monitoring and logging aspects, with centralized logging, Prometheus logging, and Grafana dashboards. We have enhanced visibility of what’s being deployed." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL</span>
   </div>
diff --git a/content/zh/case-studies/comcast/comcast_logo.png b/content/zh/case-studies/comcast/comcast_logo.png
deleted file mode 100644
index 3f0ef76645..0000000000
Binary files a/content/zh/case-studies/comcast/comcast_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/comcast/index.html b/content/zh/case-studies/comcast/index.html
deleted file mode 100644
index 054df14696..0000000000
--- a/content/zh/case-studies/comcast/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Comcast
-content_url: https://youtu.be/lmeFkH-rHII
----
diff --git a/content/zh/case-studies/concur/concur_featured_logo.png b/content/zh/case-studies/concur/concur_featured_logo.png
deleted file mode 100644
index 473427a3ba..0000000000
Binary files a/content/zh/case-studies/concur/concur_featured_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/concur/index.html b/content/zh/case-studies/concur/index.html
deleted file mode 100644
index 977399a5fc..0000000000
--- a/content/zh/case-studies/concur/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Concur
-content_url: http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production
----
diff --git a/content/zh/case-studies/ebay/ebay_featured.png b/content/zh/case-studies/ebay/ebay_featured.png
deleted file mode 100644
index 4ad17a4af5..0000000000
Binary files a/content/zh/case-studies/ebay/ebay_featured.png and /dev/null differ
diff --git a/content/zh/case-studies/ebay/ebay_logo.png b/content/zh/case-studies/ebay/ebay_logo.png
deleted file mode 100644
index 830913c52b..0000000000
Binary files a/content/zh/case-studies/ebay/ebay_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/ebay/index.html b/content/zh/case-studies/ebay/index.html
deleted file mode 100644
index 2a0d9cc18e..0000000000
--- a/content/zh/case-studies/ebay/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Ebay
-content_url: http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/
----
diff --git a/content/zh/case-studies/goldman-sachs/gs_logo.png b/content/zh/case-studies/goldman-sachs/gs_logo.png
deleted file mode 100644
index 5cc8c14566..0000000000
Binary files a/content/zh/case-studies/goldman-sachs/gs_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/goldman-sachs/index.html b/content/zh/case-studies/goldman-sachs/index.html
deleted file mode 100644
index 93d3022d12..0000000000
--- a/content/zh/case-studies/goldman-sachs/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Goldman Sachs
-content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/
----
\ No newline at end of file
diff --git a/content/zh/case-studies/homeoffice/homeoffice_logo.png b/content/zh/case-studies/homeoffice/homeoffice_logo.png
deleted file mode 100644
index 35d9722611..0000000000
Binary files a/content/zh/case-studies/homeoffice/homeoffice_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/homeoffice/index.html b/content/zh/case-studies/homeoffice/index.html
deleted file mode 100644
index 589c7507d4..0000000000
--- a/content/zh/case-studies/homeoffice/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Home Office UK
-content_url: https://www.youtube.com/watch?v=F3iMkz_NSvU
----
diff --git a/content/zh/case-studies/jd/index.html b/content/zh/case-studies/jd/index.html
deleted file mode 100644
index 8fbf434a56..0000000000
--- a/content/zh/case-studies/jd/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: JD.COM
-content_url: https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack
----
diff --git a/content/zh/case-studies/jd/jd_logo.png b/content/zh/case-studies/jd/jd_logo.png
deleted file mode 100644
index 58ef32a322..0000000000
Binary files a/content/zh/case-studies/jd/jd_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/liveperson/index.html b/content/zh/case-studies/liveperson/index.html
deleted file mode 100644
index 0cadb0f274..0000000000
--- a/content/zh/case-studies/liveperson/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: LivePerson
-content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson
----
\ No newline at end of file
diff --git a/content/zh/case-studies/liveperson/liveperson_logo.png b/content/zh/case-studies/liveperson/liveperson_logo.png
deleted file mode 100644
index b7e63d94f7..0000000000
Binary files a/content/zh/case-studies/liveperson/liveperson_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/monzo/index.html b/content/zh/case-studies/monzo/index.html
deleted file mode 100644
index 99d4f35934..0000000000
--- a/content/zh/case-studies/monzo/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Monzo
-content_url: https://youtu.be/YkOY7DgXKyw
----
\ No newline at end of file
diff --git a/content/zh/case-studies/monzo/monzo_logo.png b/content/zh/case-studies/monzo/monzo_logo.png
deleted file mode 100644
index 854409d17e..0000000000
Binary files a/content/zh/case-studies/monzo/monzo_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/netease/index.html b/content/zh/case-studies/netease/index.html
index 0ce8d133e2..f5c70dedff 100644
--- a/content/zh/case-studies/netease/index.html
+++ b/content/zh/case-studies/netease/index.html
@@ -6,11 +6,11 @@ css: /css/style_case_studies.css
 ---
 
 
-<!-- <div class="banner1" style="background-image: url('/images/CaseStudy_netease_banner1.jpg')">
+<!-- <div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> How NetEase Leverages Kubernetes to Support Internet Business Worldwide</div></h1>
 
 </div> -->
-<div class="banner1" style="background-image: url('/images/CaseStudy_netease_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
   <h1> 案例研究：<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> 网易如何利用 Kubernetes 支持在全球的互联网业务</div></h1>
 
 </div>
@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
 在考虑构建自己的业务流程解决方案后，网易决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自谷歌，这一事实让团队有信心，它能够跟上网易的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”冯长健说。
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_netease_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/netease/banner3.jpg')">
   <div class="banner3text">
     <!-- "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment." -->
 “我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- 冯长健,网易云和容器托管平台架构师</span>
@@ -71,7 +71,7 @@ css: /css/style_case_studies.css
 团队正在继续改进。例如，企业的电子商务部分需要利用混合部署，过去需要使用两个单独的平台：基础架构即服务平台和 Kubernetes 平台。最近，网易创建了一个跨平台应用程序，支持将两者同时使用单命令部署。
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_netease_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/netease/banner4.jpg')">
   <div class="banner4text">
     <!-- "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span> -->
 “只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的有所助力的技术。”<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- 李兰青, 网易 Kubernetes 开发人员</span>
diff --git a/content/zh/case-studies/nordstrom/index.html b/content/zh/case-studies/nordstrom/index.html
index 40cfc7642d..11edf1c652 100644
--- a/content/zh/case-studies/nordstrom/index.html
+++ b/content/zh/case-studies/nordstrom/index.html
@@ -5,14 +5,14 @@ cid: caseStudies
 css: /css/style_case_studies.css
 ---
 
-<!-- <div class="banner1" style="background-image: url('/images/CaseStudy_nordstrom_banner1.jpg')">
+<!-- <div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">Finding Millions in Potential Savings in a Tough Retail Climate
 
 </div></h1>
 
 </div> -->
 
-<div class="banner1" style="background-image: url('/images/CaseStudy_nordstrom_banner1.jpg')">
+<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
   <h1> 案例研究:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">在艰难的零售环境下寻找数百万的潜在成本节约
 
 
@@ -87,7 +87,7 @@ Nordstrom 希望提高其技术运营的效率和速度，其中包括 Nordstrom
 但是，新环境仍然需要很长时间才能出现，因此下一步是在云中工作。如今，Nordstrom  Technology 已经构建了一个企业平台，允许公司的1500 名开发人员在云中部署以 Docker 容器身份运行的应用程序，这些应用程序由 Kubernetes 进行编排。
 </div>
 </section>
-<div class="banner3" style="background-image: url('/images/CaseStudy_nordstrom_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')">
 <div class="banner3text">
 <!-- "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," -->
 “了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”
@@ -108,7 +108,7 @@ Nordstrom 首次尝试在集群上调度容器，是基于 CoreOS fleet 的原
 对于加入的团队来说,这些好处是立竿见影的。Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_nordstrom_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')">
   <div class="banner4text">
  <!-- "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." -->
 Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。”
diff --git a/content/zh/case-studies/philips/index.html b/content/zh/case-studies/philips/index.html
deleted file mode 100644
index e45d41a776..0000000000
--- a/content/zh/case-studies/philips/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Philips
-content_url: https://cloud.google.com/customers/philips/
----
\ No newline at end of file
diff --git a/content/zh/case-studies/philips/philips_logo.png b/content/zh/case-studies/philips/philips_logo.png
deleted file mode 100644
index 9ba3421a61..0000000000
Binary files a/content/zh/case-studies/philips/philips_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/pokemon-go/index.html b/content/zh/case-studies/pokemon-go/index.html
deleted file mode 100644
index ed4e168019..0000000000
--- a/content/zh/case-studies/pokemon-go/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Pokemon GO
-content_url: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html
----
\ No newline at end of file
diff --git a/content/zh/case-studies/pokemon-go/pokemon_go_logo.png b/content/zh/case-studies/pokemon-go/pokemon_go_logo.png
deleted file mode 100644
index 3cf2b5c7ef..0000000000
Binary files a/content/zh/case-studies/pokemon-go/pokemon_go_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/samsung-sds/index.html b/content/zh/case-studies/samsung-sds/index.html
deleted file mode 100644
index db4aa479ab..0000000000
--- a/content/zh/case-studies/samsung-sds/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Samsung SDS
-content_url: http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/
----
\ No newline at end of file
diff --git a/content/zh/case-studies/samsung-sds/sds_logo.png b/content/zh/case-studies/samsung-sds/sds_logo.png
deleted file mode 100644
index 0a172df65d..0000000000
Binary files a/content/zh/case-studies/samsung-sds/sds_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/sap/index.html b/content/zh/case-studies/sap/index.html
deleted file mode 100644
index d94c034023..0000000000
--- a/content/zh/case-studies/sap/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: SAP
-content_url: https://youtu.be/4gyeixJLabo
----
diff --git a/content/zh/case-studies/sap/sap_logo.png b/content/zh/case-studies/sap/sap_logo.png
deleted file mode 100644
index 681a3fe5cf..0000000000
Binary files a/content/zh/case-studies/sap/sap_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/sap/sap_small.png b/content/zh/case-studies/sap/sap_small.png
deleted file mode 100644
index ada89de759..0000000000
Binary files a/content/zh/case-studies/sap/sap_small.png and /dev/null differ
diff --git a/content/zh/case-studies/soundcloud/index.html b/content/zh/case-studies/soundcloud/index.html
deleted file mode 100644
index c3c99ba715..0000000000
--- a/content/zh/case-studies/soundcloud/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: SoundCloud
-content_url: https://www.youtube.com/watch?v=5378N5iLb2Q
----
diff --git a/content/zh/case-studies/soundcloud/soundcloud_logo.png b/content/zh/case-studies/soundcloud/soundcloud_logo.png
deleted file mode 100644
index f8c12f05b5..0000000000
Binary files a/content/zh/case-studies/soundcloud/soundcloud_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/squarespace/index.html b/content/zh/case-studies/squarespace/index.html
index b78180f52c..c2ac30a7ba 100644
--- a/content/zh/case-studies/squarespace/index.html
+++ b/content/zh/case-studies/squarespace/index.html
@@ -14,13 +14,13 @@ css: /css/style_case_studies.css
 ---
 -->
 
-<!-- <div class="banner1 desktop" style="background-image: url('/images/CaseStudy_squarespace_banner1.jpg')">
+<!-- <div class="banner1 desktop" style="background-image: url('/images/case-studies/squarespace/banner1.jpg')">
   <h1> CASE STUDY:<img src="/images/squarespace_logo.png" class="header_logo"><br>
     <div class="subhead">Squarespace: Gaining Productivity and Resilience with Kubernetes</div>
   </h1>
 </div> -->
 
-<div class="banner1 desktop" style="background-image: url('/images/CaseStudy_squarespace_banner1.jpg')">
+<div class="banner1 desktop" style="background-image: url('/images/case-studies/squarespace/banner1.jpg')">
   <h1> 案例分析：<img src="/images/squarespace_logo.png" class="header_logo"><br>
     <div class="subhead">Squarespace: 借力 Kubernetes 提升效率和可靠性</div>
   </h1>
@@ -113,7 +113,7 @@ Kubernetes 也同样提升了可靠性：“如果一个节点宕掉，马上会
 </div>
 </section>
 
-<div class="banner3" style="background-image: url('/images/CaseStudy_squarespace_banner3.jpg')">
+<div class="banner3" style="background-image: url('/images/case-studies/squarespace/banner3.jpg')">
   <!-- <div class="banner3text">
     After experimenting with another container orchestration platform and "breaking it in very painful ways,"
     Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had."
@@ -157,7 +157,7 @@ Kubernetes 也同样提升了可靠性：“如果一个节点宕掉，马上会
 
 </div>
 </section>
-<div class="banner4" style="background-image: url('/images/CaseStudy_squarespace_banner4.jpg')">
+<div class="banner4" style="background-image: url('/images/case-studies/squarespace/banner4.jpg')">
   <div class="banner4text">
   <!-- "We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates,"
   Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. -->
diff --git a/content/zh/case-studies/wepay/index.html b/content/zh/case-studies/wepay/index.html
deleted file mode 100644
index b8ce8201d5..0000000000
--- a/content/zh/case-studies/wepay/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: WePay
-content_url: http://thenewstack.io/wepay-kubernetes-changed-business/
----
\ No newline at end of file
diff --git a/content/zh/case-studies/wepay/wepay_logo.png b/content/zh/case-studies/wepay/wepay_logo.png
deleted file mode 100644
index 4e35dd8fd6..0000000000
Binary files a/content/zh/case-studies/wepay/wepay_logo.png and /dev/null differ
diff --git a/content/zh/case-studies/zulily/index.html b/content/zh/case-studies/zulily/index.html
deleted file mode 100644
index d5caf422aa..0000000000
--- a/content/zh/case-studies/zulily/index.html
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Zulily
-content_url: https://www.youtube.com/embed/of45hYbkIZs
----
diff --git a/content/zh/case-studies/zulily/zulily_featured.png b/content/zh/case-studies/zulily/zulily_featured.png
deleted file mode 100644
index 81179f36d2..0000000000
Binary files a/content/zh/case-studies/zulily/zulily_featured.png and /dev/null differ
diff --git a/content/zh/case-studies/zulily/zulily_logo.png b/content/zh/case-studies/zulily/zulily_logo.png
deleted file mode 100644
index e144c7897b..0000000000
Binary files a/content/zh/case-studies/zulily/zulily_logo.png and /dev/null differ
diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md
index 5253b6cc54..47043364b8 100644
--- a/content/zh/docs/concepts/architecture/cloud-controller.md
+++ b/content/zh/docs/concepts/architecture/cloud-controller.md
@@ -1,359 +1,208 @@
 ---
 title: 云控制器管理器的基础概念
 content_type: concept
-weight: 30
+weight: 40
 ---
 
 <!--
----
 title: Concepts Underlying the Cloud Controller Manager
 content_type: concept
-weight: 30
----
+weight: 40
 -->
 
-
 <!-- overview -->
 
-<!--
-The cloud controller manager (CCM) concept (not to be confused with the binary) was originally created to allow cloud specific vendor code and the Kubernetes core to evolve independent of one another. The cloud controller manager runs alongside other master components such as the Kubernetes controller manager, the API server, and scheduler. It can also be started as a Kubernetes addon, in which case it runs on top of Kubernetes.
--->
-
-云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。
+{{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
 <!--
-The cloud controller manager's design is based on a plugin mechanism that allows new cloud providers to integrate with Kubernetes easily by using plugins. There are plans in place for on-boarding new cloud providers on Kubernetes and for migrating cloud providers from the old model to the new CCM model.
+Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds.
+Kubernetes believes in automated, API-driven infrastructure without tight coupling between
+components.
 -->
+使用云基础设施技术，你可以在公有云、私有云或者混合云环境中运行 Kubernetes。
+Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。
 
-云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。
+{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是">}}
 
 <!--
-This document discusses the concepts behind the cloud controller manager and gives details about its associated functions.
+The cloud-controller-manager is structured using a plugin
+mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
 -->
-
-本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。
-
-<!--
-Here's the architecture of a Kubernetes cluster without the cloud controller manager:
--->
-
-这是没有云控制器管理器的 Kubernetes 集群的架构：
-
-<!--
-![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
--->
-
-![没有云控制器管理器的 Kubernetes 架构](/images/docs/pre-ccm-arch.png)
-
-
-
+`cloud-controller-manager` 组件是基于一种插件机制来构造的，
+这种机制使得不同的云厂商都能将其平台与 Kubernetes 集成。
 
 <!-- body -->
-
 <!--
 ## Design
+
+![Kubernetes components](/images/docs/components-of-kubernetes.png)
+
+The cloud controller manager runs in the control plane as a replicated set of processes
+(usually, these are containers in Pods). Each cloud-controller-manager implements
+multiple {{< glossary_tooltip text="controllers" term_id="controller" >}} in a single
+process.
 -->
+## 设计  {#design}
 
+![Kubernetes 组件](/images/docs/components-of-kubernetes.png)
 
-## 设计
+云控制器管理器以一组多副本的进程集合的形式运行在控制面中，通常表现为 Pod
+中的容器。每个 `cloud-controller-manager` 在同一进程中实现多个
+{{< glossary_tooltip text="控制器" term_id="controller" >}}。
 
 <!--
-In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
+You can also run the cloud controller manager as a Kubernetes
+{{< glossary_tooltip text="addon" term_id="addons" >}} rather than as part
+of the control plane.
 -->
-
-在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：
-
-<!--
-* Kubelet
-* Kubernetes controller manager
-* Kubernetes API server
--->
-
-* Kubelet
-* Kubernetes 控制管理器
-* Kubernetes API 服务器
-
-<!--
-The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this:
--->
-
-CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：
-
-<!--
-![CCM Kube Arch](/images/docs/post-ccm-arch.png)
--->
-
-![含有云控制器管理器的 Kubernetes 架构](/images/docs/post-ccm-arch.png)
-
-<!--
-## Components of the CCM
--->
-## CCM 的组成部分
-
-<!--
-The CCM breaks away some of the functionality of Kubernetes controller manager (KCM) and runs it as a separate process. Specifically, it breaks away those controllers in the KCM that are cloud dependent. The KCM has the following cloud dependent controller loops:
- -->
-
-CCM 打破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个单独的进程运行。具体来说，它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器：
-
-<!--
- * Node controller
- * Volume controller
- * Route controller
- * Service controller
--->
-
-* 节点控制器
-* 卷控制器
-* 路由控制器
-* 服务控制器
-<!--
-In version 1.9, the CCM runs the following controllers from the preceding list:
- -->
-
-在 1.9 版本中，CCM 运行前述列表中的以下控制器：
-
-<!--
-* Node controller
-* Route controller
-* Service controller
--->
-
-* 节点控制器
-* 路由控制器
-* 服务控制器
-
 {{< note >}}
-<!--
-Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
--->
-
-注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。
-
+你也可以以 Kubernetes {{< glossary_tooltip text="插件" term_id="addons" >}} 
+的形式而不是控制面中的一部分来运行云控制器管理器。
 {{< /note >}}
 
 <!--
-The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
--->
+## Cloud controller manager functions {#functions-of-the-ccm}
 
-使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。
+The controllers inside the cloud controller manager include:
+-->
+## 云控制器管理器的功能 {#functions-of-the-ccm}
+
+云控制器管理器中的控制器包括：
 
 <!--
-Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
--->
+### Node controller
 
-考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。
+The node controller is responsible for creating {{< glossary_tooltip text="Node" term_id="node" >}} objects
+when new servers are created in your cloud infrastructure. The node controller obtains information about the
+hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
+-->
+### 节点控制器   {#node-controller}
+
+节点控制器负责在云基础设施中创建了新服务器时为之 创建
+{{< glossary_tooltip text="节点（Node）" term_id="node" >}}对象。
+节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能：
 
 <!--
-## Functions of the CCM
+1. Initialize a Node object for each server that the controller discovers through the cloud provider API.
+2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
+   is deployed into and the resources (CPU, memory, etc) that it has available.
+3. Obtain the node's hostname and network addresses.
+4. Verifying the node's health. In case a node becomes unresponsive, this controller checks with
+   your cloud provider's API to see if the server has been deactivated / deleted / terminated.
+   If the node has been deleted from the cloud, the controller deletes the Node object from your Kubernetes
+   cluster.
 -->
-
-## CCM 的功能
-
-<!--
-The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
--->
-
-CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。
-
-<!--
-### 1. Kubernetes controller manager
--->
-
-### 1. Kubernetes 控制器管理器
-
-<!--
-The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
--->
-
-CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。
-
-<!--
-* Node controller
-* Route controller
-* Service controller
--->
-
-* 节点控制器
-* 路由控制器
-* 服务控制器
-
-<!--
-#### Node controller
--->
-
-#### 节点控制器
-
-<!--
-The Node controller is responsible for initializing a node by obtaining information about the nodes running in the cluster from the cloud provider. The node controller performs the following functions:
--->
-
-节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点，节点控制器执行以下功能：
-
-<!--
-1. Initialize a node with cloud specific zone/region labels.
-2. Initialize a node with cloud specific instance details, for example, type and size.
-3. Obtain the node's network addresses and hostname.
-4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
-If the node has been deleted from the cloud, delete the Kubernetes Node object.
--->
-
-1. 使用特定于云的域（zone）/区（region）标签初始化节点；
-2. 使用特定于云的实例详细信息初始化节点，例如，类型和大小；
+1. 针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象；
+2. 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的
+   区域（Region）和所具有的资源（CPU、内存等等）；
 3. 获取节点的网络地址和主机名；
-4. 如果节点无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，请删除 Kubernetes 节点对象。
+4. 检查节点的健康状况。如果节点无响应，控制器通过云平台 API ll 查看该节点是否
+   已从云中禁用、删除或终止。如果节点已从云中删除，则控制器从 Kubernetes 集群
+   中删除 Node 对象。
 
 <!--
-#### Route controller
+Some cloud provider implementations split this into a node controller and a separate node
+lifecycle controller.
 -->
-
-#### 路由控制器
-
-<!--
-The Route controller is responsible for configuring routes in the cloud appropriately so that containers on different nodes in the Kubernetes cluster can communicate with each other. The route controller is only applicable for Google Compute Engine clusters.
--->
-
-Route 控制器负责适当地配置云中的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。
-
-<!--
-#### Service Controller
--->
-
-#### 服务控制器
-
-<!--
-The Service controller is responsible for listening to service create, update, and delete events. Based on the current state of the services in Kubernetes, it configures cloud load balancers (such as ELB , Google LB, or Oracle Cloud Infrastructure LB) to reflect the state of the services in Kubernetes. Additionally, it ensures that service backends for cloud load balancers are up to date.
--->
-
-<!--
-### 2. Kubelet
--->
-
-### 2. Kubelet
-
-<!--
-The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
--->
-
-节点控制器包含 kubelet 中云依赖的功能，在引入 CCM 之前，kubelet 负责使用特定于云平台的功能特性（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。
-
-<!--
-In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
--->
-
-在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。
-
-<!--
-## Plugin mechanism
--->
-
-## 插件机制
-
-<!--
-The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
--->
-
-云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说，它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。
-
-<!--
-The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
--->
-
-上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。
-
-<!--
-For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
- -->
-
-有关开发插件的更多信息，请参阅[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
-
-<!--
-## Authorization
--->
-
-## 授权
-
-<!--
-This section breaks down the access required on various API objects by the CCM to perform its operations.
--->
-
-本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。
-
-<!--
-### Node Controller
--->
-
-### 节点控制器
-
-<!--
-The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
--->
-
-Node 控制器仅适用于 Node 对象，它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。
-
-<!--
-v1/Node:
-
-- Get
-- List
-- Create
-- Update
-- Patch
-- Watch
-- Delete
--->
-
-v1/Node:
-
-- Get
-- List
-- Create
-- Update
-- Patch
-- Watch
-- Delete
+某些云驱动实现中，这些任务被划分到一个节点控制器和一个节点生命周期控制器中。
 
 <!--
 ### Route controller
--->
 
-### 路由控制器
+The route controller is responsible for configuring routes in the cloud
+appropriately so that containers on different nodes in your Kubernetes
+cluster can communicate with each other.
+
+Depending on the cloud provider, the route controller might also allocate blocks
+of IP addresses for the Pod network.
+-->
+### 路由控制器   {#route-controller}
+
+Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的
+容器之间可以相互通信。
+
+取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。
 
 <!--
-The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
+### Service controller
+
+{< glossary_tooltip text="Services" term_id="service" >}} integrate with cloud
+infrastructure components such as managed load balancers, IP addresses, network
+packet filtering, and target health checking. The service controller interacts with your
+cloud provider's APIs to set up load balancers and other infrastructure components
+when you declare a Service resource that requires them.
 -->
+### 服务控制器   {#service-controller}
 
-路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。
+{{< glossary_tooltip text="服务（Service）" term_id="service" >}}与受控的负载均衡器、
+IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。
+服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。
+你所创建的 Service 资源会需要这些组件服务。
 
-v1/Node:
+<!--
+## Authorization
+
+This section breaks down the access that the cloud controller managers requires
+on various API objects, in order to perform its operations.
+-->
+## 鉴权   {#authorization}
+
+本节分别讲述云控制器管理器为了完成自身工作而产生的对各类 API 对象的访问需求。
+
+<!--
+### Node controller {#authorization-node-controller}
+
+The Node controller only works with Node objects. It requires full access
+to read and modify Node objects.
+-->
+### 节点控制器  {#authorization-node-controller}
+
+节点控制器只操作 Node 对象。它需要读取和修改 Node 对象的完全访问权限。
+
+`v1/Node`:
+
+- Get
+- List
+- Create
+- Update
+- Patch
+- Watch
+- Delete
+
+<!--
+### Route controller {#authorization-route-controller}
+
+The route controller listens to Node object creation and configures
+routes appropriately. It requires Get access to Node objects.
+-->
+### 路由控制器 {#authorization-route-controller}
+
+路由控制器会监听 Node 对象的创建事件，并据此配置路由设施。
+它需要读取 Node 对象的 Get 权限。
+
+`v1/Node`:
 
 - Get
 
 <!--
-### Service controller
+### Service controller {#authorization-service-controller}
+
+The service controller listens to Service object Create, Update and Delete events and then configures Endpoints for those Services appropriately.
+
+To access Services, it requires List, and Watch access. To update Services, it requires Patch and Update access.
+
+To set up Endpoints resources for the Services, it requires access to Create, List, Get, Watch, and Update.
 -->
+### 服务控制器 {#authorization-service-controller}
 
-### 服务控制器
+服务控制器监测 Service 对象的 Create、Update 和 Delete 事件，并配置
+对应服务的 Endpoints 对象。
+为了访问 Service 对象，它需要 List、Watch 访问权限；为了更新 Service 对象
+它需要 Patch 和 Update 访问权限。
+为了能够配置 Service 对应的 Endpoints 资源，它需要 Create、List、Get、Watch
+和 Update 等访问权限。
 
-<!--
-The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
--->
-
-服务控制器侦听 Service 对象创建、更新和删除事件，然后适当地为这些服务配置端点。
-
-<!--
-To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
--->
-
-要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。
-
-<!--
-To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
--->
-
-要为服务设置端点，需要访问 create、list、get、watch 和 update。
-
-v1/Service:
+`v1/Service`:
 
 - List
 - Get
@@ -362,32 +211,40 @@ v1/Service:
 - Update
 
 <!--
-### Others
--->
+### Others {#authorization-miscellaneous}
 
-### 其它
+The implementation of the core of the cloud controller manager requires access to create Event objects, and to ensure secure operation, it requires access to create ServiceAccounts.
 
-<!--
-The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
--->
-
-CCM 核心的实现需要访问权限以创建事件，并且为了确保安全操作，它需要访问权限以创建服务账户。
-
-v1/Event:
+`v1/Event`:
 
 - Create
 - Patch
 - Update
 
-v1/ServiceAccount:
+`v1/ServiceAccount`:
 
 - Create
 
-<!--
-The RBAC ClusterRole for the CCM looks like this:
+The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole for the cloud
+controller manager looks like:
 -->
+### 其他  {#authorization-miscellaneous}
 
-针对 CCM 的 RBAC ClusterRole 看起来像这样：
+云控制器管理器的实现中，其核心部分需要创建 Event 对象的访问权限以及
+创建 ServiceAccount 资源以保证操作安全性的权限。
+
+`v1/Event`:
+
+- Create
+- Patch
+- Update
+
+`v1/ServiceAccount`:
+
+- Create
+
+用于云控制器管理器 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}
+的 ClusterRole 如下例所示：
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -451,50 +308,37 @@ rules:
   - update
 ```
 
-<!--
-## Vendor Implementations
--->
-
-## 供应商实施
+## {{% heading "whatsnext" %}}
 
 <!--
-The following cloud providers have implemented CCMs:
--->
+[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+has instructions on running and managing the cloud controller manager.
 
-以下云服务提供商已实现了 CCM：
+Want to know how to implement your own cloud controller manager, or extend an existing project?
+-->
+[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+给出了运行和管理云控制器管理器的指南。
+
+想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
 
 <!--
-* [AWS](https://github.com/kubernetes/cloud-provider-aws)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
-* [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)
+The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
 -->
-* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)  
-* [AWS](https://github.com/kubernetes/cloud-provider-aws)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
-* [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)
+云控制器管理器使用 Go 语言的接口，从而使得针对各种云平台的具体实现都可以接入。
+其中使用了在 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
+项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)
+文件所定义的 `CloudProvider` 接口。
 
 <!--
-## Cluster Administration
+The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
+
+For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
 -->
+本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及
+其他一些生成具有 CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
+特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
 
-## 群集管理
-
-<!--
-Complete instructions for configuring and running the CCM are provided
-[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
--->
-
-[这里](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
-
-
+关于如何开发插件的详细信息，可参考
+[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
+文档。
 
diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md
index 8dd4d9c7b5..182aaf5162 100644
--- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md
@@ -38,10 +38,10 @@ apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连
 或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
 
 <!--
-Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
+Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
 -->
 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。
-例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。
+一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。
 请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
 以了解如何自动提供 kubelet 客户端证书。
 
@@ -103,16 +103,16 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to pro
 If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an
 untrusted or public network.
 
-Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
+Finally, [Kubelet authentication and/or authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
 -->
-
 为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 apiserver 
 提供一个根证书包，用于 kubelet 的服务证书。
 
 如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和
 kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。
 
-最后，应该启用 [Kubelet 用户认证和/或鉴权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
+最后，应该启用
+[kubelet 用户认证和/或鉴权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
 来保护 kubelet API。
 
 <!--
diff --git a/content/zh/docs/concepts/architecture/controller.md b/content/zh/docs/concepts/architecture/controller.md
index dba00e9018..6178bd68f0 100644
--- a/content/zh/docs/concepts/architecture/controller.md
+++ b/content/zh/docs/concepts/architecture/controller.md
@@ -155,6 +155,27 @@ nodes in your cluster. See
 （实际上有一个控制器可以水平地扩展集群中的节点。请参阅
 [集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。
 
+<!--
+The important point here is that the controller makes some change to bring about
+your desired state, and then reports current state back to your cluster's API server.
+Other control loops can observe that reported data and take their own actions.
+-->
+这里，很重要的一点是，控制器做出了一些变更以使得事物更接近你的期望状态，
+之后将当前状态报告给集群的 API 服务器。
+其他控制回路可以观测到所汇报的数据的这种变化并采取其各自的行动。
+
+<!--
+In the thermostat example, if the room is very cold then a different controller
+might also turn on a frost protection heater. With Kubernetes clusters, the control
+plane indirectly works with IP address management tools, storage services,
+cloud provider APIS, and other services by
+[extending Kubernetes](/docs/concepts/extend-kubernetes/) to implement that.
+-->
+在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。
+就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动
+APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh/docs/concepts/extend-kubernetes/)
+来实现这点。
+
 <!--
 ## Desired versus current state {#desired-vs-current}
 
diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md
index 00e221aec1..3e2ec24243 100644
--- a/content/zh/docs/concepts/architecture/nodes.md
+++ b/content/zh/docs/concepts/architecture/nodes.md
@@ -381,7 +381,7 @@ You may read more about capacity and allocatable resources while learning how
 to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) on a Node.
 -->
 可以在学习如何在节点上[预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
-的时了解有关容量和可分配资源的更多信息。
+的时候了解有关容量和可分配资源的更多信息。
 
 <!--
 ### Info
@@ -487,7 +487,7 @@ a Lease object.
 <!--
 #### Reliability
 
-In most cases, node controller limits the eviction rate to
+In most cases, the node controller limits the eviction rate to
 `-node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
 from more than 1 node per 10 seconds.
 -->
diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md
index fd60a3457f..91ef1b5cc8 100644
--- a/content/zh/docs/concepts/cluster-administration/_index.md
+++ b/content/zh/docs/concepts/cluster-administration/_index.md
@@ -62,9 +62,9 @@ Before choosing a guide, here are some considerations:
 -->
 - 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
 - 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？
-- 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
+- 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
 - **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
-- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）**上运行？
+- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？
 - 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
 - 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。
 
@@ -102,7 +102,7 @@ Before choosing a guide, here are some considerations:
 
 * [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。
 * [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
-* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
+* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
 * [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
 * [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
 * [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md
index c0291a480d..aaed1402d0 100644
--- a/content/zh/docs/concepts/cluster-administration/addons.md
+++ b/content/zh/docs/concepts/cluster-administration/addons.md
@@ -5,6 +5,8 @@ content_type: concept
 
 <!-- overview -->
 
+{{% thirdparty-content %}}
+
 <!--
 Add-ons extend the functionality of Kubernetes.
 
@@ -34,10 +36,12 @@ Add-ons 扩展了 Kubernetes 的功能。
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes.
 * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
+* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
 * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
-* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
 -->
 ## 网络和网络策略
 
@@ -63,6 +67,15 @@ Add-ons 扩展了 Kubernetes 的功能。
 * [Multus](https://github.com/Intel-Corp/multus-cni) 是一个多插件，可在 Kubernetes 中提供多种网络支持，
   以支持所有 CNI 插件（例如 Calico，Cilium，Contiv，Flannel），
   而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) 是一个 Kubernetes 网络驱动，
+  基于 [OVN（Open Virtual Network）](https://github.com/ovn-org/ovn/)实现，是从 Open vSwitch (OVS)
+  项目衍生出来的虚拟网络实现。
+  OVN-Kubernetes 为 Kubernetes 提供基于覆盖网络的网络实现，包括一个基于 OVS 实现的负载均衡器
+  和网络策略。
+* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) 是一个基于 OVN 的 CNI
+  控制器插件，提供基于云原生的服务功能链条（Service Function Chaining，SFC）、多种 OVN 覆盖
+  网络、动态子网创建、动态虚拟网络创建、VLAN 驱动网络、直接驱动网络，并且可以
+  驳接其他的多网络插件，适用于基于边缘的、多集群联网的云原生工作负载。
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 容器插件（NCP）
   提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的
   CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。
@@ -71,7 +84,7 @@ Add-ons 扩展了 Kubernetes 的功能。
 * [Romana](https://romana.io) 是一个 pod 网络的第三层解决方案，并支持[
   NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。
   Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
-* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) 
   提供在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
 
 <!--
diff --git a/content/zh/docs/concepts/cluster-administration/certificates.md b/content/zh/docs/concepts/cluster-administration/certificates.md
index 75efede893..2c1dfc1b6c 100644
--- a/content/zh/docs/concepts/cluster-administration/certificates.md
+++ b/content/zh/docs/concepts/cluster-administration/certificates.md
@@ -198,7 +198,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
 1. 创建用于生成证书签名请求（CSR）的配置文件。
    确保在将其保存至文件（如 `csr.conf`）之前将尖括号标记的值（如 `<MASTER_IP>`）
    替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
-   (service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
+   （service cluster IP）。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
 
    ```
    [ req ]
@@ -259,7 +259,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
 <!--
 Finally, add the same parameters into the API server start parameters.
 -->
-最后，添加同样的参数到  API 服务器的启动参数中。
+最后，添加同样的参数到 API 服务器的启动参数中。
 
 ### cfssl
 
diff --git a/content/zh/docs/concepts/cluster-administration/cloud-providers.md b/content/zh/docs/concepts/cluster-administration/cloud-providers.md
deleted file mode 100644
index b463f1eb1f..0000000000
--- a/content/zh/docs/concepts/cluster-administration/cloud-providers.md
+++ /dev/null
@@ -1,727 +0,0 @@
----
-title: 云驱动
-content_type: concept
-weight: 30
----
-
-<!--
-title: Cloud Providers
-content_type: concept
-weight: 30
--->
-
-<!-- overview -->
-<!--
-This page explains how to manage Kubernetes running on a specific
-cloud provider.
--->
-本文介绍了如何管理运行在特定云驱动上的 Kubernetes 集群。
-
-
-<!-- body -->
-<!--
-### kubeadm
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters.
-kubeadm has configuration options to specify configuration information for cloud providers. For example a typical
-in-tree cloud provider can be configured using kubeadm as shown below:
--->
-### kubeadm
-
-[kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 是创建 kubernetes 集群的一种流行选择。
-kubeadm 通过提供配置选项来指定云驱动的配置信息。例如，一个典型的适用于“树内”云驱动的 kubeadm 配置如下：
-
-```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: InitConfiguration
-nodeRegistration:
-  kubeletExtraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
----
-apiVersion: kubeadm.k8s.io/v1beta2
-kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
-apiServer:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-controllerManager:
-  extraArgs:
-    cloud-provider: "openstack"
-    cloud-config: "/etc/kubernetes/cloud.conf"
-  extraVolumes:
-  - name: cloud
-    hostPath: "/etc/kubernetes/cloud.conf"
-    mountPath: "/etc/kubernetes/cloud.conf"
-```
-
-<!--
-The in-tree cloud providers typically need both `--cloud-provider` and `--cloud-config` specified in the command lines
-for the [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and the
-[kubelet](/docs/admin/kubelet/). The contents of the file specified in `--cloud-config` for each provider is documented below as well.
-
-For all external cloud providers, please follow the instructions on the individual repositories,
-which are listed under their headings below, or one may view [the list of all repositories](https://github.com/kubernetes?q=cloud-provider-&type=&language=)
--->
-“树内”的云驱动通常需要在命令行中为
-[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)、
-[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 和
-[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 指定
-`--cloud-provider` 和 `--cloud-config`。
-在 `--cloud-config` 中为每个供应商指定的文件内容的文档也可参见本文后文。
-对于所有外部云驱动，请遵循各自仓库的说明，或浏览
-[所有仓库清单](https://github.com/kubernetes?q=cloud-provider-&type=&language=)
-
-<!--
-## AWS
-This section describes all the possible configurations which can
-be used when running Kubernetes on Amazon Web Services.
-
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)
--->
-# AWS
-
-本节介绍在 Amazon Web Services 上运行 Kubernetes 时可以使用的所有配置。
-如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)
-
-<!--
-### Node Name
-
-The AWS cloud provider uses the private DNS name of the AWS instance as the name of the Kubernetes Node object.
--->
-### 节点名称
-
-云驱动 AWS 使用 AWS 实例的私有 DNS 名称作为 Kubernetes 节点对象的名称。
-
-<!--
-### Load Balancers
-You can setup [external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/)
-to use specific features in AWS by configuring the annotations as shown below.
--->
-### 负载均衡器
-
-用户可以通过配置注解（annotations）来设置
-[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，
-以在 AWS 中使用特定功能，如下所示：
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: example
-  namespace: kube-system
-  labels:
-    run: example
-  annotations:
-     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
-     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
-spec:
-  type: LoadBalancer
-  ports:
-  - port: 443
-    targetPort: 5556
-    protocol: TCP
-  selector:
-    app: example
-```
-<!--
-Different settings can be applied to a load balancer service in AWS using _annotations_. The following describes the annotations supported on AWS ELBs:
--->
-可以使用 _注解_ 将不同的设置应用于 AWS 中的负载均衡器服务。下面描述了 AWS ELB 所支持的注解：
-
-<!--
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: Used to specify access log emit interval.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: Used on the service to enable or disable access logs.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: Used to specify access log s3 bucket name.
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix.
-* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`.
-* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
-* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
-* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB.
-* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
-* `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: Used on the service to specify a comma-separated list of ports that will use SSL/HTTPS listeners. Defaults to `*` (all)
--->
-
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`：用于指定访问日志的间隔。
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`：用于在服务中启用或禁用访问日志。
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`：用于指定访问日志的 S3 桶名称。
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`：用于指定访问日志的 S3 桶前缀。
-* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`：用于在服务中指定一个逗号分隔的键值对列表，它将作为附加标签被记录在 ELB 中。例如： `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`。
-* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。
-  如果指定 `http`（默认）或 `https`，将创建一个终止连接和解析头的 HTTPS 监听器。
-  如果设置为 `ssl` 或 `tcp`，将会使用 “原生的” SSL 监听器。
-  如果设置为 `http` 且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的
-  证书 ARN（Amazon Resource Name）。更多内容请参考
-  [ELB 监听器配置](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。
-  证书 ARN 是 IAM（身份和访问管理）或 CM（证书管理）类型的 ARN，例如
-  `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`：用于在服务中启用或禁用连接耗尽（connection draining）。
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`：用于在服务中指定连接耗尽超时时间。
-* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`：用于在服务中指定空闲连接超时时间。
-* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`：用于在服务中启用或禁用跨区域负载平衡。
-* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`：用于在服务中指定要添加到创建的 ELB 中的其他安全组。
-* `service.beta.kubernetes.io/aws-load-balancer-internal`：用于在服务中表明需要内部 ELB。
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`：用于在 ELB 上启用代理协议。 当前仅接受 `*`值，也就是在所有 ELB 后端启用代理协议。将来可能进行调整，只允许特定的后端设置代理协议。
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`：用于在服务中指定一个逗号分隔的端口列表，这些端口会使用 SSL/HTTPS 监听器。默认为 `*`（全部）
-
-<!--
-The information for the annotations for AWS is taken from the comments on [aws.go](https://github.com/kubernetes/cloud-provider-aws/blob/master/pkg/cloudprovider/providers/aws/aws.go)
--->
-AWS 相关的注解信息取自 [aws.go](https://github.com/kubernetes/cloud-provider-aws/blob/master/pkg/cloudprovider/providers/aws/aws.go) 文件的注释。
-
-## Azure
-
-<!--
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)
--->
-如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)
-
-<!--
-### Node Name
-
-The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Azure VM name.
--->
-### 节点名称
-
-云驱动 Azure 使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
-注意 Kubernetes 节点名必须与 Azure 虚拟机的名称匹配。
-
-## CloudStack
-
-<!--
-If you wish to use the external cloud provider, its repository is [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)
--->
-
-如果希望使用此外部云驱动，其代码库位于 [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)。
-
-<!--
-### Node Name
-
-The CloudStack cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the CloudStack VM name.
--->
-### 节点名称
-
-云驱动 CloudStack 使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
-注意 Kubernetes 节点名必须与 CloudStack 虚拟机名匹配。
-
-## GCE
-<!--
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
--->
-如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
-
-<!--
-### Node Name
-
-The GCE cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the first segment of the Kubernetes Node name must match the GCE instance name (e.g. a Node named `kubernetes-node-2.c.my-proj.internal` must correspond to an instance named `kubernetes-node-2`).
--->
-### 节点名称
-
-GCE 云驱动使用节点的主机名（由 kubelet 确定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
-注意，Kubernetes 节点名的第一个字段必须匹配 GCE 实例名(例如，名为 `kubernetes-node-2.c.my-proj.internal` 的节点必须对应于一个名为 `kubernetes-node-2` 的实例)。
-
-## OpenStack
-<!--
-This section describes all the possible configurations which can
-be used when using OpenStack with Kubernetes.
-
-If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)
--->
-
-本节介绍了使用 OpenStack 运行 Kubernetes 时所有可用的配置。
-如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)
-
-<!--
-### Node Name
-
-The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object.
-Note that the instance name must be a valid Kubernetes Node name in order for the kubelet to successfully register its Node object.
--->
-### 节点名称
-
-OpenStack 云驱动使用实例名（由 OpenStack 元数据确定）作为 Kubernetes 节点对象的名称。
-请注意，实例名必须是一个有效的 Kubernetes 节点名，以便 kubelet 成功注册其节点对象。
-
-<!--
-### Services
-
-The OpenStack cloud provider
-implementation for Kubernetes supports the use of these OpenStack services from
-the underlying cloud, where available:
-
-| Service                  | API Version(s) | Required |
-|--------------------------|----------------|----------|
-| Block Storage (Cinder)   | V1†, V2, V3    | No       |
-| Compute (Nova)           | V2             | No       |
-| Identity (Keystone)      | V2‡,  V3       | Yes      |
-| Load Balancing (Neutron) | V1§, V2        | No       |
-| Load Balancing (Octavia) | V2             | No       |
-
--->
-### 服务
-
-Kubernetes 的 OpenStack 云驱动实现支持从底层云使用这些 OpenStack 服务：
-
-| 服务                     | API 版本       | 必需     |
-|--------------------------|----------------|----------|
-| 块存储 (Cinder)          | V1†, V2, V3    | No       |
-| 计算    (Nova)           | V2             | No       |
-| 身份认证 (Keystone)      | V2‡,  V3       | Yes      |
-| 负载均衡器 (Neutron)     | V1§, V2        | No       |
-| 负载均衡器 (Octavia)     | V2             | No       |
-
-<!--
-† Block Storage V1 API support is deprecated, Block Storage V3 API support was
-added in Kubernetes 1.9.
-‡ Identity V2 API support is deprecated and will be removed from the provider in
-a future release. As of the "Queens" release, OpenStack will no longer expose the
-Identity V2 API.
-§ Load Balancing V1 API support was removed in Kubernetes 1.9.
--->
-† 块存储 V1 版本的 API 被弃用，从 Kubernetes 1.9 版本开始加入了块存储 V3 版本 API。
-
-‡ 身份认证 V2 API 支持已被弃用，将在未来的版本中从供应商中移除。
-  从 “Queens” 版本开始，OpenStack 将不再支持身份认证 V2 版本的 API。
-
-§ Kubernetes 1.9 中取消了对 V1 版本负载均衡 API 的支持。
-
-<!--
-Service discovery is achieved by listing the service catalog managed by
-OpenStack Identity (Keystone) using the `auth-url` provided in the provider
-configuration. The provider will gracefully degrade in functionality when
-OpenStack services other than Keystone are not available and simply disclaim
-support for impacted features. Certain features are also enabled or disabled
-based on the list of extensions published by Neutron in the underlying cloud.
--->
-服务发现是通过使用供应商配置中提供的 `auth-url` 所列出 OpenStack 身份认证（Keystone）管理的服务目录来实现的。
-当除 Keystone 外的 OpenStack 服务不可用时，供应商将优雅地降低功能，并简单地放弃对受影响特性的支持。
-某些功能还可以根据 Neutron 在底层云中发布的扩展列表启用或禁用。
-
-### cloud.conf
-
-<!--
-Kubernetes knows how to interact with OpenStack via the file cloud.conf. It is
-the file that will provide Kubernetes with credentials and location for the OpenStack auth endpoint.
-You can create a cloud.conf file by specifying the following details in it
--->
-Kubernetes 知道如何通过 cloud.conf 文件与 OpenStack 交互。
-该文件将为 Kubernetes 提供 OpenStack 验证端点的凭据和位置。
-用户可在创建 cloud.conf 文件时指定以下信息：
-
-<!--
-#### Typical configuration
-This is an example of a typical configuration that touches the values that most
-often need to be set. It points the provider at the OpenStack cloud's Keystone
-endpoint, provides details for how to authenticate with it, and configures the
-load balancer:
--->
-#### 典型配置
-
-下面是一个典型配置的例子，它涉及到最常设置的值。它将供应商指向 OpenStack 云的 Keystone 端点，
-提供如何使用它进行身份验证的细节，并配置负载均衡器:
-
-```yaml
-[Global]
-username=user
-password=pass
-auth-url=https://<keystone_ip>/identity/v3
-tenant-id=c869168a828847f39f7f06edd7305637
-domain-id=2a73b8f597c04551a0fdc8e95544be8a
-
-[LoadBalancer]
-subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
-```
-<!--
-##### Global
-These configuration options for the OpenStack provider pertain to its global
-configuration and should appear in the `[Global]` section of the `cloud.conf`
-file:
--->
-##### 全局配置
-
-这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[global]` 部分:
-
-<!--
-* `auth-url` (Required): The URL of the keystone API used to authenticate. On
-  OpenStack control panels, this can be found at Access and Security > API
-  Access > Credentials.
-* `username` (Required): Refers to the username of a valid user set in keystone.
-* `password` (Required): Refers to the password of a valid user set in keystone.
-* `tenant-id` (Required): Used to specify the id of the project where you want
-  to create your resources.
-* `tenant-name` (Optional): Used to specify the name of the project where you
-  want to create your resources.
-* `trust-id` (Optional): Used to specify the identifier of the trust to use for
-  authorization. A trust represents a user's (the trustor) authorization to
-  delegate roles to another user (the trustee), and optionally allow the trustee
-  to impersonate the trustor. Available trusts are found under the
-  `/v3/OS-TRUST/trusts` endpoint of the Keystone API.
-* `domain-id` (Optional): Used to specify the id of the domain your user belongs
-  to.
-* `domain-name` (Optional): Used to specify the name of the domain your user
-  belongs to.
-* `region` (Optional): Used to specify the identifier of the region to use when
-  running on a multi-region OpenStack cloud. A region is a general division of
-  an OpenStack deployment. Although a region does not have a strict geographical
-  connotation, a deployment can use a geographical name for a region identifier
-  such as `us-east`. Available regions are found under the `/v3/regions`
-  endpoint of the Keystone API.
-* `ca-file` (Optional): Used to specify the path to your custom CA file.
--->
-
-* `auth-url` (必需): 用于认证的 Keystone API 的 URL。在 OpenStack 控制面板中，
-  这可以在“访问和安全（Access and Security）> API 访问（API Access）> 凭证（Credentials）”中找到。
-* `username` (必需): 指 keystone 中一个有效用户的用户名。
-* `password` (必需): 指 keystone 中一个有效用户的密码。
-* `tenant-id` (必需): 用于指定要创建资源的租户 ID。
-* `tenant-name` (可选): 用于指定要在其中创建资源的租户的名称。
-* `trust-id` (可选): 用于指定用于授权的信任的标识符。信任表示用户（委托人）
-  将角色委托给另一个用户(受托人)的授权，并可选的允许受托人模仿委托人。
-  可用的信任可以在 Keystone API 的 `/v3/OS-TRUST/trusts` 端点下找到。
-* `domain-id` (可选): 用于指定用户所属域的 ID。
-* `domain-name` (可选): 用于指定用户所属域的名称。
-* `region` (可选): 用于指定在多区域 OpenStack 云上运行时使用的区域标识符。
-  区域是 OpenStack 部署的一般性划分。虽然区域没有严格的地理含义，但部署可以使用地理名称表示区域标识符，
-  如 `us-east`。可用区域位于 Keystone API 的 `/v3/regions` 端点之下。
-* `ca-file` (可选): 用于指定自定义 CA 文件的路径。
-
-<!--
-When using Keystone V3 - which changes tenant to project - the `tenant-id` value
-is automatically mapped to the project construct in the API.
--->
-当使用 Keystone V3 时(它将tenant更改为project)，`tenant-id` 值会自动映射到 API 中的项目。
-
-<!--
-#####  Load Balancer
-These configuration options for the OpenStack provider pertain to the load
-balancer and should appear in the `[LoadBalancer]` section of the `cloud.conf`
-file:
--->
-####  负载均衡器
-
-这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[LoadBalancer]` 部分:
-
-<!--
-* `lb-version` (Optional): Used to override automatic version detection. Valid
-  values are `v1` or `v2`. Where no value is provided automatic detection will
-  select the highest supported version exposed by the underlying OpenStack
-  cloud.
-* `use-octavia` (Optional): Used to determine whether to look for and use an
-  Octavia LBaaS V2 service catalog endpoint. Valid values are `true` or `false`.
-  Where `true` is specified and an Octaiva LBaaS V2 entry can not be found, the
-  provider will fall back and attempt to find a Neutron LBaaS V2 endpoint
-  instead. The default value is `false`.
-* `subnet-id` (Optional): Used to specify the id of the subnet you want to
-  create your loadbalancer on. Can be found at Network > Networks. Click on the
-  respective network to get its subnets.
-* `floating-network-id` (Optional): If specified, will create a floating IP for
-  the load balancer.
-* `lb-method` (Optional): Used to specify an algorithm by which load will be
-  distributed amongst members of the load balancer pool. The value can be
-  `ROUND_ROBIN`, `LEAST_CONNECTIONS`, or `SOURCE_IP`. The default behavior if
-  none is specified is `ROUND_ROBIN`.
-* `lb-provider` (Optional): Used to specify the provider of the load balancer.
-  If not specified, the default provider service configured in neutron will be
-  used.
-* `create-monitor` (Optional): Indicates whether or not to create a health
-  monitor for the Neutron load balancer. Valid values are `true` and `false`.
-  The default is `false`. When `true` is specified then `monitor-delay`,
-  `monitor-timeout`, and `monitor-max-retries` must also be set.
-* `monitor-delay` (Optional): The time between sending probes to
-  members of the load balancer. Ensure that you specify a valid time unit. The valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h"
-* `monitor-timeout` (Optional): Maximum time for a monitor to wait
-  for a ping reply before it times out. The value must be less than the delay
-  value. Ensure that you specify a valid time unit. The valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h"
-* `monitor-max-retries` (Optional): Number of permissible ping failures before
-  changing the load balancer member's status to INACTIVE. Must be a number
-  between 1 and 10.
-* `manage-security-groups` (Optional): Determines whether or not the load
-  balancer should automatically manage the security group rules. Valid values
-  are `true` and `false`. The default is `false`. When `true` is specified
-  `node-security-group` must also be supplied.
-* `node-security-group` (Optional): ID of the security group to manage.
--->
-
-* `lb-version` (可选): 用于覆盖自动版本检测。有效值为 `v1` 或 `v2`。
-  如果没有提供值，则自动选择底层 OpenStack 云所支持的最高版本。
-* `use-octavia` (可选): 用于确定是否查找和使用 Octavia LBaaS V2 服务目录端点。
-  有效值是 `true` 或 `false`。
-  如果指定了“true”，并且无法找到 Octaiva LBaaS V2 入口，则提供者将退回并尝试寻找一个
-  Neutron LBaaS V2 端点。默认值是 `false`。
-* `subnet-id` (可选): 用于指定要在其上创建负载均衡器的子网的 ID。
-  可以在 “Network > Networks” 上找到。
-  单击相应的网络以获得其子网。
-* `floating-network-id` (可选): 如果指定，将为负载均衡器创建一个浮动 IP。
-* `lb-method` (可选): 用于指定将负载分配到负载均衡器池成员的算法。
-  值可以是 `ROUND_ROBIN`、`LEAST_CONNECTIONS` 或 `SOURCE_IP`。
-  如果没有指定，默认行为是 `ROUND_ROBIN`。
-* `lb-provider` (可选): 用于指定负载均衡器的提供程序。
-  如果没有指定，将使用在 Neutron 中配置的默认提供者服务。
-* `create-monitor` (可选): 指定是否为 Neutron 负载均衡器创建健康监视器。
-  有效值是 `true` 和 `false`。
-  默认为 `false`。当指定 `true` 时，还必须设置 `monitor-delay`、`monitor-timeout` 和 `monitor-max-retries`。
-* `monitor-delay` (可选): 向负载均衡器的成员发送探测之间的时间间隔。
-  确保您指定了一个有效的时间单位。
-  有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。
-* `monitor-timeout` (可选): 在超时之前，监视器等待 ping 响应的最长时间。
-  该值必须小于延迟值。确保您指定了一个有效的时间单位。
-  有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。
-* `monitor-max-retries` (可选): 在将负载均衡器成员的状态更改为非活动之前，允许 ping 失败的次数。
-  必须是 1 到 10 之间的数字。
-* `manage-security-groups` (可选): 确定负载均衡器是否应自动管理安全组规则。
-  有效值是 `true` 和 `false`。默认为 `false`。当指定 `true` 时，还必须提供 `node-security-group`。
-* `node-security-group` (可选): 要管理的安全组的 ID。
-
-<!--
-##### Block Storage
-These configuration options for the OpenStack provider pertain to block storage
-and should appear in the `[BlockStorage]` section of the `cloud.conf` file:
--->
-##### 块存储
-
-这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[BlockStorage]` 部分：
-
-<!--
-* `bs-version` (可选): Used to override automatic version detection. Valid
-  values are `v1`, `v2`, `v3` and `auto`. When `auto` is specified automatic
-  detection will select the highest supported version exposed by the underlying
-  OpenStack cloud. The default value if none is provided is `auto`.
-* `trust-device-path` (Optional): In most scenarios the block device names
-  provided by Cinder (e.g. `/dev/vda`) can not be trusted. This boolean toggles
-  this behavior. Setting it to `true` results in trusting the block device names
-  provided by Cinder. The default value of `false` results in the discovery of
-  the device path based on its serial number and `/dev/disk/by-id` mapping and is
-  the recommended approach.
-* `ignore-volume-az` (Optional): Used to influence availability zone use when
-  attaching Cinder volumes. When Nova and Cinder have different availability
-  zones, this should be set to `true`. This is most commonly the case where
-  there are many Nova availability zones but only one Cinder availability zone.
-  The default value is `false` to preserve the behavior used in earlier
-  releases, but may change in the future.
-* `node-volume-attach-limit` (Optional): Maximum number of Volumes that can be
-  attached to the node, default is 256 for cinder.
--->
-
-* `bs-version` (可选): 指所使用的块存储 API 版本。其合法值为 `v1`、`v2`、`v3`和 `auto`。
-  `auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。
-* `trust-device-path` (可选): 在大多数情况下，块设备名称由 Cinder 提供（例如：`/dev/vda`）不可信任。
-  此布尔值切换此行为。将其设置为 `true` 将导致信任 Cinder 提供的块设备名称。
-  默认值 `false` 会根据设备序列号和 `/dev/disk/by-id` 映射发现设备路径，推荐这种方法。
-* `ignore-volume-az` (可选): 用于在附加 Cinder 卷时影响可用区使用。
-  当 Nova 和 Cinder 有不同的可用区域时，应该将其设置为 `true`。
-  最常见的情况是，有许多 Nova 可用区，但只有一个 Cinder 可用区。
-  默认值是 `false`，以保持在早期版本中使用的行为，但是将来可能会更改。
-* `node-volume-attach-limit` (可选): 可连接到节点的最大卷数，对于 Cinder 默认为 256。
-   
-<!--
-If deploying Kubernetes versions <= 1.8 on an OpenStack deployment that uses
-paths rather than ports to differentiate between endpoints it may be necessary
-to explicitly set the `bs-version` parameter. A path based endpoint is of the
-form `http://foo.bar/volume` while a port based endpoint is of the form
-`http://foo.bar:xxx`.
-
-In environments that use path based endpoints and Kubernetes is using the older
-auto-detection logic a `BS API version autodetection failed.` error will be
-returned on attempting volume detachment. To workaround this issue it is
-possible to force the use of Cinder API version 2 by adding this to the cloud
-provider configuration:
--->
-如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（Endpoints），
-那么可能需要显式设置 `bs-version` 参数。
-基于路径的端点形如 `http://foo.bar/volume`，而基于端口的的端点形如 `http://foo.bar:xxx`。
-
-在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中，
-尝试卷卸载（Detachment）会返回 `BS API version autodetection failed.` 错误。
-为了解决这个问题，可以通过添加以下内容到云驱动配置中，来强制使用 Cinder API V2 版本。
-
-```yaml
-[BlockStorage]
-bs-version=v2
-```
-
-<!--
-##### Metadata
-These configuration options for the OpenStack provider pertain to metadata and
-should appear in the `[Metadata]` section of the `cloud.conf` file:
-
-* `search-order` (Optional): This configuration key influences the way that the
-  provider retrieves metadata relating to the instance(s) in which it runs. The
-  default value of `configDrive,metadataService` results in the provider
-  retrieving metadata relating to the instance from the config drive first if
-  available and then the metadata service. Alternative values are:
-  * `configDrive` - Only retrieve instance metadata from the configuration
-    drive.
-  * `metadataService` - Only retrieve instance metadata from the metadata
-    service.
-  * `metadataService,configDrive` - Retrieve instance metadata from the metadata
-    service first if available, then the configuration drive.
-
-  Influencing this behavior may be desirable as the metadata on the
-  configuration drive may grow stale over time, whereas the metadata service
-  always provides the most up to date view. Not all OpenStack clouds provide
-  both configuration drive and metadata service though and only one or the other
-  may be available which is why the default is to check both.
--->
-##### 元数据
-
-这些配置选项属于 OpenStack 提供程序的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[Metadata]` 部分：
-
-* `search-order` (可选): 此配置键影响提供者检索与其运行的实例相关的元数据的方式。
-  `configDrive，metadataService` 的默认值导致供应商首先从配置驱动器中检索与实例相关的元数据（如果可用的话），
-  然后检索元数据服务。
-  他们的替代值：
-
-  * `configDrive` - 仅从配置驱动器检索实例元数据。
-  * `metadataService` - 仅从元数据服务检索实例元数据。
-  * `metadataService,configDrive` - 如果可用，首先从元数据服务检索实例元数据，然后从配置驱动器检索。
-
-  影响这种行为可能是可取的，因为配置驱动器上的元数据可能会随着时间的推移而变得陈旧，
-  而元数据服务总是提供最新的数据视图。并不是所有的 OpenStack 云都同时提供配置驱动和元数据服务，
-  可能只有一个或另一个可用，这就是为什么默认情况下要同时检查两个。
-
-<!--
-##### Route
-
-These configuration options for the OpenStack provider pertain to the [kubenet]
-Kubernetes network plugin and should appear in the `[Route]` section of the
-`cloud.conf` file:
-
-* `router-id` (Optional): If the underlying cloud's Neutron deployment supports
-  the `extraroutes` extension then use `router-id` to specify a router to add
-  routes to.  The router chosen must span the private networks containing your
-  cluster nodes (typically there is only one node network, and this value should be
-  the default router for the node network).  This value is required to use
-  [kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)
-  on OpenStack.
--->
-
-##### 路由
-
-这些配置选项属于 OpenStack 驱动为 Kubernetes 网络插件 [kubenet] 提供的设置，并且应该出现在 `cloud.conf` 文件中的 `[Route]` 部分:
-
-* `router-id` (可选)：如果底层云的 Neutron 部署支持 `extraroutes` 扩展，
-  则使用 `router-id` 指定要添加路由的路由器。
-  选择的路由器必须跨越包含集群节点的私有网络（通常只有一个节点网络，这个值应该是节点网络的默认路由器）。
-  在 OpenStack 上使用 [kubenet](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)
-  时需要这个值。
-
-
-## OVirt
-
-<!--
-### Node Name
-
-The OVirt cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the VM FQDN (reported by OVirt under `<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`)
--->
-
-### 节点名称
-
-OVirt 云驱动使用节点的主机名（由 kubelet 确定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
-注意 Kubernetes 节点名必须与 VM FQDN 匹配（OVirt 在`<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`中说明）。
-
-## Photon
-
-<!--
-### Node Name
-
-The Photon cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Photon VM name (or if `overrideIP` is set to true in the `--cloud-config`, the Kubernetes Node name must match the Photon VM IP address).
--->
-
-### 节点名称
-
-Photon 云驱动使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）
-作为 Kubernetes 节点对象的名称。
-注意，Kubernetes 节点名必须与 Photon VM名匹配（或者，如果在 `--cloud-config` 中将
-`overrideIP` 设置为 `true`，则 Kubernetes 节点名必须与 Photon VM IP 地址匹配）。
-
-## VSphere
-
-<!--
-### Node Name
-
-The VSphere cloud provider uses the detected hostname of the node (as determined by the kubelet) as the name of the Kubernetes Node object.
-
-The `--hostname-override` parameter is ignored by the VSphere cloud provider.
--->
-### 节点名称
-
-VSphere 云驱动使用节点检测到的主机名(由 kubelet 确定)作为 Kubernetes 节点对象的名称。
-VSphere 云驱动会忽略 `--hostname-override` 参数。
-
-## IBM Cloud Kubernetes Service
-
-<!--
-### Compute nodes
-By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters).
-
-The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.
--->
-### 计算节点
-
-通过使用 IBM Cloud Kubernetes Service 驱动，您可以在单个区域或跨区域的多个区（Region）
-中创建虚拟和物理（裸金属）节点的集群。
-有关更多信息，请参见[规划您的集群和工作节点设置](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters)。
-
-Kubernetes 节点对象的名称是 IBM Cloud Kubernetes Services 工作节点实例的私有IP地址。
-
-<!--
-### Networking
-
-The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning in-cluster and private networking](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster).
-
-To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Planning to expose your apps with external networking](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
--->
-### 网络
-
-IBM Cloud Kubernetes Services 驱动提供 VLAN，用于提供高质量的网络性能和节点间的网络隔离。
-您可以设置自定义防火墙和 Calico 网络策略来为您的集群添加额外的安全层，或者通过 VPN
-将您的集群连接到自有数据中心。
-有关更多信息，请参见[规划集群内和私有网络](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)。
-
-要向公众或集群内部公开应用程序，您可以利用 NodePort、LoadBalancer 或 Ingress 服务。
-您还可以使用注释自定义 Ingress 应用程序负载均衡器。
-有关更多信息，请参见[计划使用外部网络公开您的应用程序](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)。
-
-<!--
-### Storage
-
-The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).
--->
-
-### 存储
-
-IBM Cloud Kubernetes Services 驱动利用 Kubernetes 原生的持久卷，使用户能够将文件、块和云对象存储
-装载到他们的应用程序中。还可以使用 database-as-a-service 和第三方附加组件来持久存储数据。
-有关更多信息，请参见[规划高可用性持久存储](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)。
-
-<!--
-## Baidu Cloud Container Engine
-
-### Node Name
-
-The Baidu cloud provider uses the private IP address of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Baidu VM private IP.
--->
-## 百度云容器引擎
-
-### 节点名称
-
-Baidu 云驱动使用节点的私有 IP 地址（由 kubelet 确定，或者用 `--hostname-override` 覆盖）
-作为 Kubernetes 节点对象的名称。
-注意 Kubernetes 节点名必须匹配百度 VM 的私有 IP。
diff --git a/content/zh/docs/concepts/cluster-administration/controller-metrics.md b/content/zh/docs/concepts/cluster-administration/controller-metrics.md
deleted file mode 100644
index c865ce7e5b..0000000000
--- a/content/zh/docs/concepts/cluster-administration/controller-metrics.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: 控制器管理器指标
-content_type: concept
-weight: 100
----
-
-<!--
----
-title: Controller manager metrics
-content_type: concept
-weight: 100
----
--->
-
-<!-- overview -->
-
-<!--
-Controller manager metrics provide important insight into the performance and health of
-the controller manager.
--->
-
-控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
-
-
-
-<!-- body -->
-
-<!--
-## What are controller manager metrics
-
-Controller manager metrics provide important insight into the performance and health of the controller manager.
-These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
-etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
-to gauge the health of a cluster.
-
-Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
-These metrics can be used to monitor health of persistent volume operations.
-
-For example, for GCE these metrics are called:
--->
-
-## 什么是控制器管理器度量
-
-控制器管理器指标为控制器管理器的性能和健康提供了重要的观测手段。
-这些度量包括常见的 Go 语言运行时度量，比如 go_routine 计数，以及控制器特定的度量，比如 etcd 请求延迟或 云提供商（AWS、GCE、OpenStack）的 API 延迟，这些参数可以用来测量集群的健康状况。
-
-从 Kubernetes 1.7 版本开始，详细的云提供商指标可用于 GCE、AWS、Vsphere 和 OpenStack 的存储操作。
-这些度量可用于监视持久卷操作的健康状况。
-
-例如，在 GCE 中这些指标叫做：
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-<!--
-## Configuration
-
-
-In a cluster, controller-manager metrics are available from `http://localhost:10252/metrics`
-from the host where the controller-manager is running.
-
-The metrics are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
-
-In a production environment you may want to configure prometheus or some other metrics scraper
-to periodically gather these metrics and make them available in some kind of time series database.
--->
-
-## 配置
-
-在集群中，控制器管理器指标可从它所在的主机上的 `http://localhost:10252/metrics` 中获得。
-
-这些指标是以 [prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/) 发出的，是人类可读的。
-
-在生产环境中，您可能想配置 prometheus 或其他一些指标收集工具，以定期收集这些指标数据，并将它们应用到某种时间序列数据库中。
-
-
diff --git a/content/zh/docs/concepts/cluster-administration/flow-control.md b/content/zh/docs/concepts/cluster-administration/flow-control.md
new file mode 100644
index 0000000000..2738b47fc9
--- /dev/null
+++ b/content/zh/docs/concepts/cluster-administration/flow-control.md
@@ -0,0 +1,884 @@
+---
+title: API 优先级和公平性
+content_type: concept
+min-kubernetes-server-version: v1.18
+---
+
+<!-- overview -->
+
+{{< feature-state state="alpha"  for_k8s_version="v1.18" >}}
+
+<!--
+Controlling the behavior of the Kubernetes API server in an overload situation
+is a key task for cluster administrators. The {{< glossary_tooltip
+term_id="kube-apiserver" text="kube-apiserver" >}} has some controls available
+(i.e. the `--max-requests-inflight` and `--max-mutating-requests-inflight`
+command-line flags) to limit the amount of outstanding work that will be
+accepted, preventing a flood of inbound requests from overloading and
+potentially crashing the API server, but these flags are not enough to ensure
+that the most important requests get through in a period of high traffic.
+-->
+对于集群管理员来说，控制 Kubernetes API 服务器在过载情况下的行为是一项关键任务。
+{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+有一些控件（例如：命令行标志 `--max-requests-inflight` 和 `--max-mutating-requests-inflight` ）,
+可以限制将要接受的未处理的请求，从而防止过量请求入站，潜在导致 API 服务器崩溃。
+但是这些标志不足以保证在高流量期间，最重要的请求仍能被服务器接受。
+
+<!--
+The API Priority and Fairness feature (APF) is an alternative that improves upon
+aforementioned max-inflight limitations. APF classifies
+and isolates requests in a more fine-grained way. It also introduces
+a limited amount of queuing, so that no requests are rejected in cases
+of very brief bursts.  Requests are dispatched from queues using a
+fair queuing technique so that, for example, a poorly-behaved
+{{< glossary_tooltip text="controller" term_id="controller" >}} need not
+starve others (even at the same priority level).
+-->
+API 优先级和公平性（ APF ）是一种替代方案，可提升上述最大并发限制。
+APF 以更细粒度的方式对请求进行分类和隔离。
+它还引入了空间有限的排队机制，因此在非常短暂的突发情况下，API 服务器不会拒绝任何请求。
+通过使用公平排队技术从队列中分发请求，这样，
+一个行为不佳的 {{< glossary_tooltip text="控制器" term_id="controller" >}}
+就不会饿死其他控制器（即使优先级相同）。
+
+<!--
+{{< caution >}}
+Requests classified as "long-running" — primarily watches — are not
+subject to the API Priority and Fairness filter. This is also true for
+the `--max-requests-inflight` flag without the API Priority and
+Fairness feature enabled.
+{{< /caution >}}
+-->
+{{< caution >}}
+属于“长时间运行”类型的请求（主要是 watch ）不受 API 优先级和公平性过滤器的约束。
+如果未启用 APF 特性，即便设置 `--max-requests-inflight` 标志，该类请求也不受约束。
+{{< /caution >}}
+
+
+<!-- body -->
+
+<!-- ## Enabling API Priority and Fairness -->
+## 启用 API 优先级和公平性    {#Enabling-API-Priority-and-Fairness}
+
+<!--
+The API Priority and Fairness feature is controlled by a feature gate
+and is not enabled by default.  See
+[Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
+for a general explanation of feature gates and how to enable and disable them.  The
+name of the feature gate for APF is "APIPriorityAndFairness".  This
+feature also involves an {{< glossary_tooltip term_id="api-group"
+text="API Group" >}} that must be enabled.  You can do these
+things by adding the following command-line flags to your
+`kube-apiserver` invocation:
+-->
+APF 特性由特性门控控制，默认情况下不启用。有关如何启用和禁用特性门控的描述，
+请参见[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。
+APF 的特性门控叫做 `APIPriorityAndFairness` 。
+此特性要求必须启用某个 {{< glossary_tooltip term_id="api-group" text="API Group" >}}。
+你可以在启动 `kube-apiserver` 时，添加以下命令行标志来完成这些操作：
+
+```shell
+kube-apiserver \
+--feature-gates=APIPriorityAndFairness=true \
+--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true \
+# …其他配置与之前相同
+```
+
+<!--
+The command-line flag `--enable-priority-and-fairness=false` will disable the
+API Priority and Fairness feature, even if other flags have enabled it.
+-->
+命令行标志 `--enable-priority-fairness=false` 将彻底禁用 APF 特性，即使其他标志启用它也是无效。
+
+<!--
+## Concepts
+There are several distinct features involved in the API Priority and Fairness
+feature. Incoming requests are classified by attributes of the request using
+_FlowSchemas_, and assigned to priority levels. Priority levels add a degree of
+isolation by maintaining separate concurrency limits, so that requests assigned
+to different priority levels cannot starve each other. Within a priority level,
+a fair-queuing algorithm prevents requests from different _flows_ from starving
+each other, and allows for requests to be queued to prevent bursty traffic from
+causing failed requests when the average load is acceptably low.
+-->
+## 概念    {#concepts}
+
+APF 特性包含几个不同的功能。
+传入的请求通过 _FlowSchema_ 按照其属性分类，并分配优先级。
+每个优先级维护自定义的并发限制，加强了隔离度，这样不同优先级的请求，就不会相互饿死。
+在同一个优先级内，公平排队算法可以防止来自不同 _flow_ 的请求相互饿死。
+该算法将请求排队，通过排队机制，防止在平均负载较低时，通信量突增而导致请求失败。
+
+<!--
+### Priority Levels
+Without APF enabled, overall concurrency in
+the API server is limited by the `kube-apiserver` flags
+`--max-requests-inflight` and `--max-mutating-requests-inflight`. With APF
+enabled, the concurrency limits defined by these flags are summed and then the sum is divided up
+among a configurable set of _priority levels_. Each incoming request is assigned
+to a single priority level, and each priority level will only dispatch as many
+concurrent requests as its configuration allows.
+-->
+### 优先级    {#Priority-Levels}
+
+如果未启用 APF，API 服务器中的整体并发量将受到 `kube-apiserver` 的参数
+`--max-requests-inflight` 和 `--max-mutating-requests-inflight` 的限制。
+启用 APF 后，将对这些参数定义的并发限制进行求和，然后将总和分配到一组可配置的 _优先级_ 中。
+每个传入的请求都会分配一个优先级；每个优先级都有各自的配置，设定允许分发的并发请求数。
+
+<!--
+The default configuration, for example, includes separate priority levels for
+leader-election requests, requests from built-in controllers, and requests from
+Pods. This means that an ill-behaved Pod that floods the API server with
+requests cannot prevent leader election or actions by the built-in controllers
+from succeeding.
+-->
+例如，默认配置包括针对领导者选举请求、内置控制器请求和 Pod 请求都单独设置优先级。
+这表示即使异常的 Pod 向 API 服务器发送大量请求，也无法阻止领导者选举或内置控制器的操作执行成功。
+
+
+<!--
+### Queuing
+Even within a priority level there may be a large number of distinct sources of
+traffic. In an overload situation, it is valuable to prevent one stream of
+requests from starving others (in particular, in the relatively common case of a
+single buggy client flooding the kube-apiserver with requests, that buggy client
+would ideally not have much measurable impact on other clients at all). This is
+handled by use of a fair-queuing algorithm to process requests that are assigned
+the same priority level. Each request is assigned to a _flow_, identified by the
+name of the matching FlowSchema plus a _flow distinguisher_ — which
+is either the requesting user, the target resource's namespace, or nothing — and the
+system attempts to give approximately equal weight to requests in different
+flows of the same priority level.
+-->
+### 排队    {#Queuing}
+
+即使在同一优先级内，也可能存在大量不同的流量源。
+在过载情况下，防止一个请求流饿死其他流是非常有价值的
+（尤其是在一个较为常见的场景中，一个有故障的客户端会疯狂地向 kube-apiserver 发送请求，
+理想情况下，这个有故障的客户端不应对其他客户端产生太大的影响）。
+公平排队算法在处理具有相同优先级的请求时，实现了上述场景。
+每个请求都被分配到某个 _流_ 中，该 _流_ 由对应的 FlowSchema 的名字加上一个 _流区分项（Flow Distinguisher）_ 来标识。
+这里的流区分项可以是发出请求的用户、目标资源的名称空间或什么都不是。
+系统尝试为不同流中具有相同优先级的请求赋予近似相等的权重。
+
+<!--
+After classifying a request into a flow, the API Priority and Fairness
+feature then may assign the request to a queue.  This assignment uses
+a technique known as {{< glossary_tooltip term_id="shuffle-sharding"
+text="shuffle sharding" >}}, which makes relatively efficient use of
+queues to insulate low-intensity flows from high-intensity flows.
+-->
+将请求划分到流中之后，APF 功能将请求分配到队列中。
+分配时使用一种称为 {{< glossary_tooltip term_id="shuffle-sharding" text="混洗分片（Shuffle-Sharding）" >}} 的技术。
+该技术可以相对有效地利用队列隔离低强度流与高强度流。
+
+<!--
+The details of the queuing algorithm are tunable for each priority level, and
+allow administrators to trade off memory use, fairness (the property that
+independent flows will all make progress when total traffic exceeds capacity),
+tolerance for bursty traffic, and the added latency induced by queuing.
+-->
+排队算法的细节可针对每个优先等级进行调整，并允许管理员在内存占用、
+公平性（当总流量超标时，各个独立的流将都会取得进展）、
+突发流量的容忍度以及排队引发的额外延迟之间进行权衡。
+
+<!--
+### Exempt requests
+Some requests are considered sufficiently important that they are not subject to
+any of the limitations imposed by this feature. These exemptions prevent an
+improperly-configured flow control configuration from totally disabling an API
+server.
+-->
+### 豁免请求    {#Exempt-requests}
+
+某些特别重要的请求不受制于此特性施加的任何限制。这些豁免可防止不当的流控配置完全禁用 API 服务器。
+
+<!--
+## Defaults
+The Priority and Fairness feature ships with a suggested configuration that
+should suffice for experimentation; if your cluster is likely to
+experience heavy load then you should consider what configuration will work best.
+The suggested configuration groups requests into five priority classes:
+-->
+## 默认值    {#Defaults}
+
+APF 特性附带推荐配置，该配置对实验场景应该足够；
+如果你的集群有可能承受较大的负载，那么你应该考虑哪种配置最有效。
+推荐配置将请求分为五个优先级：
+
+<!--
+* The `system` priority level is for requests from the `system:nodes` group,
+  i.e. Kubelets, which must be able to contact the API server in order for
+  workloads to be able to schedule on them.
+-->
+* `system` 优先级用于 `system:nodes` 组（即 Kubelets ）的请求；
+kubelets 必须能连上 API 服务器，以便工作负载能够调度到其上。
+
+<!--
+* The `leader-election` priority level is for leader election requests from
+  built-in controllers (in particular, requests for `endpoints`, `configmaps`,
+  or `leases` coming from the `system:kube-controller-manager` or
+  `system:kube-scheduler` users and service accounts in the `kube-system`
+  namespace). These are important to isolate from other traffic because failures
+  in leader election cause their controllers to fail and restart, which in turn
+  causes more expensive traffic as the new controllers sync their informers.
+-->
+* `leader-election` 优先级用于内置控制器的领导选举的请求
+（特别是来自 `kube-system` 名称空间中 `system:kube-controller-manager` 和
+`system:kube-scheduler` 用户和服务账号，针对 `endpoints`、`configmaps` 或 `leases` 的请求）。
+将这些请求与其他流量相隔离非常重要，因为领导者选举失败会导致控制器发生故障并重新启动，
+这反过来会导致新启动的控制器在同步信息时，流量开销更大。
+
+<!--
+* The `workload-high` priority level is for other requests from built-in
+  controllers.
+-->
+* `workload-high` 优先级用于内置控制器的请求。
+
+<!--
+* The `workload-low` priority level is for requests from any other service
+  account, which will typically include all requests from controllers running in
+  Pods.
+-->
+* `workload-low` 优先级适用于来自任何服务帐户的请求，通常包括来自 Pods 中运行的控制器的所有请求。
+
+<!--
+* The `global-default` priority level handles all other traffic, e.g.
+  interactive `kubectl` commands run by nonprivileged users.
+-->
+* `global-default` 优先级可处理所有其他流量，例如：非特权用户运行的交互式 `kubectl` 命令。
+
+<!--
+Additionally, there are two PriorityLevelConfigurations and two FlowSchemas that
+are built in and may not be overwritten:
+-->
+内置了两个 PriorityLevelConfiguration 和两个 FlowSchema，它们是内置的、不可重载的：
+
+<!--
+* The special `exempt` priority level is used for requests that are not subject
+  to flow control at all: they will always be dispatched immediately. The
+  special `exempt` FlowSchema classifies all requests from the `system:masters`
+  group into this priority level. You may define other FlowSchemas that direct
+  other requests to this priority level, if appropriate.
+-->
+* 特殊的 `exempt` 优先级的请求完全不受流控限制：它们总是立刻被分发。
+  特殊的 `exempt` FlowSchema 把 `system:masters` 组的所有请求都归入该优先级组。
+如果合适，你可以定义新的 FlowSchema，将其他请求定向到该优先级。
+
+<!--
+* The special `catch-all` priority level is used in combination with the special
+  `catch-all` FlowSchema to make sure that every request gets some kind of
+  classification. Typically you should not rely on this catch-all configuration,
+  and should create your own catch-all FlowSchema and PriorityLevelConfiguration
+  (or use the `global-default` configuration that is installed by default) as
+  appropriate. To help catch configuration errors that miss classifying some
+  requests, the mandatory `catch-all` priority level only allows one concurrency
+  share and does not queue requests, making it relatively likely that traffic
+  that only matches the `catch-all` FlowSchema will be rejected with an HTTP 429
+  error.
+-->
+* 特殊的 `catch-all` 优先级与特殊的 `catch-all` FlowSchema 结合使用，以确保每个请求都分类。
+一般地，你不应该依赖于 `catch-all` 的配置，而应适当地创建自己的 `catch-all` FlowSchema 和 PriorityLevelConfigurations
+（或使用默认安装的 `global-default` 配置）。
+为了帮助捕获部分请求未分类的配置错误，强制要求 `catch-all` 优先级仅允许一个并发份额，
+并且不对请求进行排队，使得仅与 `catch-all` FlowSchema 匹配的流量被拒绝的可能性更高，并显示 HTTP 429 错误。
+
+<!-- ## Health check concurrency exemption -->
+## 健康检查并发豁免    {#Health-check-concurrency-exemption}
+
+<!--
+The suggested configuration gives no special treatment to the health
+check requests on kube-apiservers from their local kubelets --- which
+tend to use the secured port but supply no credentials.  With the
+suggested config, these requests get assigned to the `global-default`
+FlowSchema and the corresponding `global-default` priority level,
+where other traffic can crowd them out.
+-->
+推荐配置没有为本地 kubelet 对 kube-apiserver 执行健康检查的请求进行任何特殊处理
+——它们倾向于使用安全端口，但不提供凭据。
+在推荐配置中，这些请求将分配 `global-default` FlowSchema 和 `global-default` 优先级，
+这样其他流量可以排除健康检查。
+
+<!--
+If you add the following additional FlowSchema, this exempts those
+requests from rate limiting.
+-->
+如果添加以下 FlowSchema，健康检查请求不受速率限制。
+
+{{< caution >}}
+
+<!--
+Making this change also allows any hostile party to then send
+health-check requests that match this FlowSchema, at any volume they
+like.  If you have a web traffic filter or similar external security
+mechanism to protect your cluster's API server from general internet
+traffic, you can configure rules to block any health check requests
+that originate from outside your cluster.
+-->
+进行此更改后，任何敌对方都可以发送与此 FlowSchema 匹配的任意数量的健康检查请求。
+如果你有 Web 流量过滤器或类似的外部安全机制保护集群的 API 服务器免受常规网络流量的侵扰，
+则可以配置规则，阻止所有来自集群外部的健康检查请求。
+
+{{< /caution >}}
+
+{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}}
+
+<!--
+## Resources
+The flow control API involves two kinds of resources.
+[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
+define the available isolation classes, the share of the available concurrency
+budget that each can handle, and allow for fine-tuning queuing behavior.
+[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
+are used to classify individual inbound requests, matching each to a single
+PriorityLevelConfiguration.
+-->
+## 资源    {#Resources}
+
+流控 API 涉及两种资源。
+[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
+定义隔离类型和可处理的并发预算量，还可以微调排队行为。
+[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
+用于对每个入站请求进行分类，并与一个 PriorityLevelConfigurations 相匹配。
+
+<!--
+### PriorityLevelConfiguration
+A PriorityLevelConfiguration represents a single isolation class. Each
+PriorityLevelConfiguration has an independent limit on the number of outstanding
+requests, and limitations on the number of queued requests.
+-->
+### PriorityLevelConfiguration    {#PriorityLevelConfiguration}
+
+一个 PriorityLevelConfiguration 表示单个隔离类型。每个 PriorityLevelConfigurations 对未完成的请求数有各自的限制，对排队中的请求数也有限制。
+
+<!--
+Concurrency limits for PriorityLevelConfigurations are not specified in absolute
+number of requests, but rather in "concurrency shares." The total concurrency
+limit for the API Server is distributed among the existing
+PriorityLevelConfigurations in proportion with these shares. This allows a
+cluster administrator to scale up or down the total amount of traffic to a
+server by restarting `kube-apiserver` with a different value for
+`--max-requests-inflight` (or `--max-mutating-requests-inflight`), and all
+PriorityLevelConfigurations will see their maximum allowed concurrency go up (or
+down) by the same fraction.
+-->
+PriorityLevelConfigurations 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。
+API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfigurations 中。
+集群管理员可以更改 `--max-requests-inflight` （或 `--max-mutating-requests-inflight` ）的值，
+再重新启动 `kube-apiserver` 来增加或减小服务器的总流量，
+然后所有的 PriorityLevelConfigurations 将看到其最大并发增加（或减少）了相同的比例。
+
+<!--
+With the Priority and Fairness feature enabled, the total concurrency limit for
+the server is set to the sum of `--max-requests-inflight` and
+`--max-mutating-requests-inflight`. There is no longer any distinction made
+between mutating and non-mutating requests; if you want to treat them
+separately for a given resource, make separate FlowSchemas that match the
+mutating and non-mutating verbs respectively.
+-->
+{{< caution >}}
+启用 APF 功能后，服务器的总并发量限制将设置为
+`--max-requests-inflight` 和 `--max-mutating-requests-inflight` 之和。
+可变请求和不可变请求之间不再有任何区别；
+如果对于某种资源，你需要区别对待不同请求，请创建不同的 FlowSchema 分别匹配可变请求和不可变请求。
+{{< /caution >}}
+
+<!--
+When the volume of inbound requests assigned to a single
+PriorityLevelConfiguration is more than its permitted concurrency level, the
+`type` field of its specification determines what will happen to extra requests.
+A type of `Reject` means that excess traffic will immediately be rejected with
+an HTTP 429 (Too Many Requests) error. A type of `Queue` means that requests
+above the threshold will be queued, with the shuffle sharding and fair queuing techniques used
+to balance progress between request flows.
+-->
+当入站请求的数量大于分配的 PriorityLevelConfigurations 中允许的并发级别时， `type` 字段将确定对额外请求的处理方式。
+`Reject` 类型，表示多余的流量将立即被 HTTP 429（请求过多）错误所拒绝。
+`Queue` 类型，表示对超过阈值的请求进行排队，将使用阈值分片和公平排队技术来平衡请求流之间的进度。
+
+<!--
+The queuing configuration allows tuning the fair queuing algorithm for a
+priority level. Details of the algorithm can be read in the [enhancement
+proposal](#whats-next), but in short:
+-->
+公平排队算法支持通过排队配置对优先级微调。 可以在[增强建议](#whats-next)中阅读算法的详细信息，但总之：
+
+<!--
+* Increasing `queues` reduces the rate of collisions between different flows, at
+  the cost of increased memory usage. A value of 1 here effectively disables the
+  fair-queuing logic, but still allows requests to be queued.
+-->
+* `queues` 递增能减少不同流之间的冲突概率，但代价是增加了内存使用量。
+值为1时，会禁用公平排队逻辑，但仍允许请求排队。
+
+<!--
+* Increasing `queueLengthLimit` allows larger bursts of traffic to be
+  sustained without dropping any requests, at the cost of increased
+  latency and memory usage.
+-->
+* `queueLengthLimit` 递增可以在不丢弃任何请求的情况下支撑更大的突发流量，
+但代价是增加了等待时间和内存使用量。
+
+<!--
+* Changing `handSize` allows you to adjust the probability of collisions between
+  different flows and the overall concurrency available to a single flow in an
+  overload situation.
+  {{< note >}}
+    A larger `handSize` makes it less likely for two individual flows to collide
+    (and therefore for one to be able to starve the other), but more likely that
+    a small number of flows can dominate the apiserver. A larger `handSize` also
+    potentially increases the amount of latency that a single high-traffic flow
+    can cause. The maximum number of queued requests possible from a
+    single flow is `handSize *queueLengthLimit`.
+  {{< /note >}}
+-->
+* 修改 `handSize` 允许你调整过载情况下不同流之间的冲突概率以及单个流可用的整体并发性。
+    {{< note >}}
+    较大的 `handSize` 使两个单独的流程发生碰撞的可能性较小（因此，一个流可以饿死另一个流），
+    但是更有可能的是少数流可以控制 apiserver。
+    较大的 `handSize` 还可能增加单个高并发流的延迟量。
+    单个流中可能排队的请求的最大数量为 `handSize *queueLengthLimit` 。
+    {{< /note >}}
+
+<!--
+Following is a table showing an interesting collection of shuffle
+sharding configurations, showing for each the probability that a
+given mouse (low-intensity flow) is squished by the elephants (high-intensity flows) for
+an illustrative collection of numbers of elephants. See
+https://play.golang.org/p/Gi0PLgVHiUg , which computes this table.
+-->
+下表显示了有趣的随机分片配置集合，
+每行显示给定的老鼠（低强度流）被不同数量的大象挤压（高强度流）的概率。
+表来源请参阅： https://play.golang.org/p/Gi0PLgVHiUg
+
+{{< table caption = "Example Shuffle Sharding Configurations" >}}
+<!-- HandSize | Queues | 1 elephant | 4 elephants | 16 elephants -->
+随机分片 | 队列数 | 1个大象 | 4个大象 | 16个大象
+|----------|-----------|------------|----------------|--------------------|
+| 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 |
+| 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 |
+| 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 |
+| 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 |
+| 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 |
+| 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 |
+| 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 |
+| 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 |
+| 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 |
+| 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 |
+| 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 |
+{{< /table >}}
+
+<!-- ### FlowSchema -->
+### FlowSchema    {#FlowSchema}
+
+<!--
+A FlowSchema matches some inbound requests and assigns them to a
+priority level. Every inbound request is tested against every
+FlowSchema in turn, starting with those with numerically lowest ---
+which we take to be the logically highest --- `matchingPrecedence` and
+working onward.  The first match wins.
+-->
+FlowSchema 匹配一些入站请求，并将它们分配给优先级。
+每个入站请求都会对所有 FlowSchema 测试是否匹配，
+首先从 `matchingPrecedence` 数值最低的匹配开始（我们认为这是逻辑上匹配度最高），
+然后依次进行，直到首个匹配出现。
+
+{{< caution >}}
+<!--
+Only the first matching FlowSchema for a given request matters. If multiple
+FlowSchemas match a single inbound request, it will be assigned based on the one
+with the highest `matchingPrecedence`. If multiple FlowSchemas with equal
+`matchingPrecedence` match the same request, the one with lexicographically
+smaller `name` will win, but it's better not to rely on this, and instead to
+ensure that no two FlowSchemas have the same `matchingPrecedence`.
+-->
+对一个请求来说，只有首个匹配的 FlowSchema  才有意义。
+如果一个入站请求与多个 FlowSchema 匹配，则将基于 `matchingPrecedence` 值最高的请求进行筛选。
+如果一个请求匹配多个 FlowSchema 且 `matchingPrecedence` 的值相同，则按 `name` 的字典序选择最小，
+但是最好不要依赖它，而是确保不存在两个 FlowSchema 具有相同的 `matchingPrecedence` 值。
+{{< /caution >}}
+
+<!--
+A FlowSchema matches a given request if at least one of its `rules`
+matches. A rule matches if at least one of its `subjects` *and* at least
+one of its `resourceRules` or `nonResourceRules` (depending on whether the
+incoming request is for a resource or non-resource URL) matches the request.
+-->
+当给定的请求与某个 FlowSchema 的 `rules` 的其中一条匹配，那么就认为该请求与该 FlowSchema 匹配。
+判断规则与该请求是否匹配，**不仅**要求该条规则的 `subjects` 字段至少存在一个与该请求相匹配，
+**而且**要求该条规则的 `resourceRules` 或 `nonResourceRules`
+（取决于传入请求是针对资源URL还是非资源URL）字段至少存在一个与该请求相匹配。
+
+<!--
+For the `name` field in subjects, and the `verbs`, `apiGroups`, `resources`,
+`namespaces`, and `nonResourceURLs` fields of resource and non-resource rules,
+the wildcard `*` may be specified to match all values for the given field,
+effectively removing it from consideration.
+-->
+对于 `subjects` 中的 `name` 字段和资源和非资源规则的
+`verbs`，`apiGroups`，`resources`，`namespaces` 和 `nonResourceURLs` 字段，
+可以指定通配符 `*` 来匹配任意值，从而有效地忽略该字段。
+
+<!--
+A FlowSchema's `distinguisherMethod.type` determines how requests matching that
+schema will be separated into flows. It may be
+either `ByUser`, in which case one requesting user will not be able to starve
+other users of capacity, or `ByNamespace`, in which case requests for resources
+in one namespace will not be able to starve requests for resources in other
+namespaces of capacity, or it may be blank (or `distinguisherMethod` may be
+omitted entirely), in which case all requests matched by this FlowSchema will be
+considered part of a single flow. The correct choice for a given FlowSchema
+depends on the resource and your particular environment.
+-->
+FlowSchema 的 `distinguisherMethod.type` 字段决定了如何把与该模式匹配的请求分散到各个流中。
+可能是 `ByUser` ，在这种情况下，一个请求用户将无法饿死其他容量的用户；
+或者是 `ByNamespace` ，在这种情况下，一个名称空间中的资源请求将无法饿死其它名称空间的资源请求；
+或者它可以为空（或者可以完全省略 `distinguisherMethod` ），
+在这种情况下，与此 FlowSchema 匹配的请求将被视为单个流的一部分。
+资源和你的特定环境决定了如何选择正确一个 FlowSchema。
+
+<!--
+## Diagnostics
+Every HTTP response from an API server with the priority and fairness feature
+enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and
+`X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request
+and the priority level to which it was assigned, respectively. The API objects'
+names are not included in these headers in case the requesting user does not
+have permission to view them, so when debugging you can use a command like
+-->
+## 诊断程序    {#Diagnostics}
+
+启用了 APF 的 API 服务器，它每个 HTTP 响应都有两个额外的 HTTP 头：
+`X-Kubernetes-PF-FlowSchema-UID` 和 `X-Kubernetes-PF-PriorityLevel-UID`，
+注意与请求匹配的 FlowSchema 和已分配的优先级。
+如果请求用户没有查看这些对象的权限，则这些 HTTP 头中将不包含 API 对象的名称，
+因此在调试时，你可以使用类似如下的命令：
+
+```shell
+kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
+kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
+```
+<!--
+to get a mapping of UIDs to names for both FlowSchemas and
+PriorityLevelConfigurations.
+-->
+来获取 UID 到 FlowSchema 的名称和 UID 到 PriorityLevelConfigurations 的名称的映射。
+
+<!-- ## Observability -->
+## 可观察性    {#Observability}
+
+<!-- ### Metrics -->
+### 指标    {#Metrics}
+
+<!--
+When you enable the API Priority and Fairness feature, the kube-apiserver
+exports additional metrics. Monitoring these can help you determine whether your
+configuration is inappropriately throttling important traffic, or find
+poorly-behaved workloads that may be harming system health.
+-->
+当你开启了 APF 后，kube-apiserver 会暴露额外指标。
+监视这些指标有助于判断你的配置是否不当地限制了重要流量，
+或者发现可能会损害系统健康的，行为不良的工作负载。
+
+<!--
+* `apiserver_flowcontrol_rejected_requests_total` is a counter vector
+  (cumulative since server start) of requests that were rejected,
+  broken down by the labels `flowSchema` (indicating the one that
+  matched the request), `priorityLevel` (indicating the one to which
+  the request was assigned), and `reason`.  The `reason` label will be
+  have one of the following values:
+    * `queue-full`, indicating that too many requests were already
+      queued,
+    * `concurrency-limit`, indicating that the
+      PriorityLevelConfiguration is configured to reject rather than
+      queue excess requests, or
+    * `time-out`, indicating that the request was still in the queue
+      when its queuing time limit expired.
+-->
+* `apiserver_flowcontrol_rejected_requests_total` 是一个计数器向量，
+记录被拒绝的请求数量（自服务器启动以来累计值），
+由标签 `flowSchema` （表示与请求匹配的 FlowSchema ）， `priorityLevel` （表示分配给请该求的优先级）和  `reason` 拆分。
+`reason` 标签将具有以下值之一：
+    * `queue-full` ，表明已经有太多请求排队，
+    * `concurrency-limit` ，表示将 PriorityLevelConfiguration 配置为 `Reject` 而不是 `Queue` ，或者
+    * `time-out`, 表示在其排队时间超期的请求仍在队列中。
+
+<!--
+* `apiserver_flowcontrol_dispatched_requests_total` is a counter
+  vector (cumulative since server start) of requests that began
+  executing, broken down by the labels `flowSchema` (indicating the
+  one that matched the request) and `priorityLevel` (indicating the
+  one to which the request was assigned).
+-->
+* `apiserver_flowcontrol_dispatched_requests_total` 是一个计数器向量，
+记录开始执行的请求数量（自服务器启动以来的累积值），
+由标签 `flowSchema` （表示与请求匹配的 FlowSchema ）和 `priorityLevel`（表示分配给该请求的优先级）拆分。
+
+<!--
+* `apiserver_current_inqueue_requests` is a gauge vector of recent
+  high water marks of the number of queued requests, grouped by a
+  label named `request_kind` whose value is `mutating` or `readOnly`.
+  These high water marks describe the largest number seen in the one
+  second window most recently completed.  These complement the older
+  `apiserver_current_inflight_requests` gauge vector that holds the
+  last window's high water mark of number of requests actively being
+  served.
+-->
+* `apiserver_current_inqueue_requests` 是一个表向量，
+记录最近排队请求数量的高水位线，
+由标签 `request_kind` 分组，标签的值为 `mutating` 或 `readOnly`。
+这些高水位线表示在最近一秒钟内看到的最大数字。
+它们补充说明了老的表向量 `apiserver_current_inflight_requests`
+（该量保存了最后一个窗口中，正在处理的请求数量的高水位线）。
+
+<!--
+* `apiserver_flowcontrol_read_vs_write_request_count_samples` is a
+  histogram vector of observations of the then-current number of
+  requests, broken down by the labels `phase` (which takes on the
+  values `waiting` and `executing`) and `request_kind` (which takes on
+  the values `mutating` and `readOnly`).  The observations are made
+  periodically at a high rate.
+-->
+* `apiserver_flowcontrol_read_vs_write_request_count_samples` 是一个直方图向量，
+记录当前请求数量的观察值，
+由标签 `phase` （取值为 `waiting` 和 `executing` ）和 `request_kind` （取值 `mutating` 和 `readOnly` ）拆分。
+定期以高速率观察该值。
+
+<!--
+* `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a
+  histogram vector of high or low water marks of the number of
+  requests broken down by the labels `phase` (which takes on the
+  values `waiting` and `executing`) and `request_kind` (which takes on
+  the values `mutating` and `readOnly`); the label `mark` takes on
+  values `high` and `low`.  The water marks are accumulated over
+  windows bounded by the times when an observation was added to
+  `apiserver_flowcontrol_read_vs_write_request_count_samples`.  These
+  water marks show the range of values that occurred between samples.
+-->
+* `apiserver_flowcontrol_read_vs_write_request_count_watermarks` 是一个直方图向量，
+记录请求数量的高/低水位线，
+由标签 `phase` （取值为 `waiting` 和 `executing` ）和 `request_kind` （取值为 `mutating` 和 `readOnly` ）拆分；
+标签 `mark` 取值为 `high` 和 `low` 。
+`apiserver_flowcontrol_read_vs_write_request_count_samples` 向量观察到有值新增，则该向量累积。
+这些水位线显示了样本值的范围。
+
+<!--
+* `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector
+  holding the instantaneous number of queued (not executing) requests,
+  broken down by the labels `priorityLevel` and `flowSchema`.
+-->
+* `apiserver_flowcontrol_current_inqueue_requests` 是一个表向量，
+记录包含排队中的（未执行）请求的瞬时数量，
+由标签 `priorityLevel` 和 `flowSchema` 拆分。
+
+<!--
+* `apiserver_flowcontrol_current_executing_requests` is a gauge vector
+  holding the instantaneous number of executing (not waiting in a
+  queue) requests, broken down by the labels `priorityLevel` and
+  `flowSchema`.
+-->
+* `apiserver_flowcontrol_current_executing_requests` 是一个表向量，
+记录包含执行中（不在队列中等待）请求的瞬时数量，
+由标签 `priorityLevel` 和 `flowSchema` 拆分。
+
+<!--
+* `apiserver_flowcontrol_priority_level_request_count_samples` is a
+  histogram vector of observations of the then-current number of
+  requests broken down by the labels `phase` (which takes on the
+  values `waiting` and `executing`) and `priorityLevel`.  Each
+  histogram gets observations taken periodically, up through the last
+  activity of the relevant sort.  The observations are made at a high
+  rate.
+-->
+* `apiserver_flowcontrol_priority_level_request_count_samples` 是一个直方图向量，
+记录当前请求的观测值，由标签 `phase` （取值为`waiting` 和 `executing`）和 `priorityLevel` 拆分。
+每个直方图都会定期进行观察，直到相关类别的最后活动为止。观察频率高。
+
+<!--
+* `apiserver_flowcontrol_priority_level_request_count_watermarks` is a
+  histogram vector of high or low water marks of the number of
+  requests broken down by the labels `phase` (which takes on the
+  values `waiting` and `executing`) and `priorityLevel`; the label
+  `mark` takes on values `high` and `low`.  The water marks are
+  accumulated over windows bounded by the times when an observation
+  was added to
+  `apiserver_flowcontrol_priority_level_request_count_samples`.  These
+  water marks show the range of values that occurred between samples.
+-->
+* `apiserver_flowcontrol_priority_level_request_count_watermarks` 是一个直方图向量，
+记录请求数的高/低水位线，由标签 `phase` （取值为 `waiting` 和 `executing` ）和 `priorityLevel` 拆分；
+标签 `mark` 取值为 `high` 和 `low` 。
+`apiserver_flowcontrol_priority_level_request_count_samples` 向量观察到有值新增，则该向量累积。
+这些水位线显示了样本值的范围。
+
+<!--
+* `apiserver_flowcontrol_request_queue_length_after_enqueue` is a
+  histogram vector of queue lengths for the queues, broken down by
+  the labels `priorityLevel` and `flowSchema`, as sampled by the
+  enqueued requests.  Each request that gets queued contributes one
+  sample to its histogram, reporting the length of the queue just
+  after the request was added.  Note that this produces different
+  statistics than an unbiased survey would.
+-->
+* `apiserver_flowcontrol_request_queue_length_after_enqueue` 是一个直方图向量，
+记录请求队列的长度，由标签 `priorityLevel` 和 `flowSchema` 拆分。
+每个排队中的请求都会为其直方图贡献一个样本，并在添加请求后立即上报队列的长度。
+请注意，这样产生的统计数据与无偏调查不同。
+    {{< note >}}
+    <!--
+    An outlier value in a histogram here means it is likely that a single flow
+    (i.e., requests by one user or for one namespace, depending on
+    configuration) is flooding the API server, and being throttled. By contrast,
+    if one priority level's histogram shows that all queues for that priority
+    level are longer than those for other priority levels, it may be appropriate
+    to increase that PriorityLevelConfiguration's concurrency shares.
+    -->
+    直方图中的离群值在这里表示单个流（即，一个用户或一个名称空间的请求，具体取决于配置）正在疯狂请求 API 服务器，并受到限制。
+    相反，如果一个优先级的直方图显示该优先级的所有队列都比其他优先级的队列长，则增加 PriorityLevelConfigurations 的并发份额是比较合适的。
+    {{< /note >}}
+
+<!--
+* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector
+  hoding the computed concurrency limit (based on the API server's
+  total concurrency limit and PriorityLevelConfigurations' concurrency
+  shares), broken down by the label `priorityLevel`.
+-->
+* `apiserver_flowcontrol_request_concurrency_limit` 是一个表向量，
+记录并发限制的计算值（基于 API 服务器的总并发限制和 PriorityLevelConfigurations 的并发份额），
+并按标签 `priorityLevel` 拆分。
+
+<!--
+* `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram
+  vector of how long requests spent queued, broken down by the labels
+  `flowSchema` (indicating which one matched the request),
+  `priorityLevel` (indicating the one to which the request was
+  assigned), and `execute` (indicating whether the request started
+  executing).
+-->
+* `apiserver_flowcontrol_request_wait_duration_seconds` 是一个直方图向量，
+记录请求排队的时间，
+由标签 `flowSchema` （表示与请求匹配的 FlowSchema ），
+`priorityLevel`  （表示分配该请求的优先级）
+和 `execute` （表示请求是否开始执行）拆分。
+    {{< note >}}
+    <!--
+    Since each FlowSchema always assigns requests to a single
+    PriorityLevelConfiguration, you can add the histograms for all the
+    FlowSchemas for one priority level to get the effective histogram for
+    requests assigned to that priority level.
+    -->
+    由于每个 FlowSchema 总会给请求分配 PriorityLevelConfigurations，因此你可以为一个优先级添加所有 FlowSchema 的直方图，以获取分配给该优先级的请求的有效直方图。
+    {{< /note >}}
+
+<!--
+* `apiserver_flowcontrol_request_execution_seconds` is a histogram
+  vector of how long requests took to actually execute, broken down by
+  the labels `flowSchema` (indicating which one matched the request)
+  and `priorityLevel` (indicating the one to which the request was
+  assigned).
+-->
+* `apiserver_flowcontrol_request_execution_seconds` 是一个直方图向量，
+记录请求实际执行需要花费的时间，
+由标签 `flowSchema` （表示与请求匹配的 FlowSchema ）和 `priorityLevel` （表示分配给该请求的优先级）拆分。
+
+<!-- ### Debug endpoints -->
+### 调试端点    {#Debug-endpoints}
+
+<!--
+When you enable the API Priority and Fairness feature,
+the kube-apiserver serves the following additional paths at its HTTP[S] ports.
+-->
+启用 APF 特性后， kube-apiserver 会在其 HTTP/HTTPS 端口提供以下路径：
+
+<!--
+- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each.
+You can fetch like this:
+-->
+- `/debug/api_priority_and_fairness/dump_priority_levels` —— 所有优先级及其当前状态的列表。你可以这样获取：
+  ```shell
+  kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels
+  ```
+
+  <!-- The output is similar to this: -->
+  输出类似于：
+  ```
+  PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests,
+  workload-low,      0,            true,   false,       0,               0,
+  global-default,    0,            true,   false,       0,               0,
+  exempt,            <none>,       <none>, <none>,      <none>,          <none>,
+  catch-all,         0,            true,   false,       0,               0,
+  system,            0,            true,   false,       0,               0,
+  leader-election,   0,            true,   false,       0,               0,
+  workload-high,     0,            true,   false,       0,               0,
+  ```
+
+<!--
+- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state.
+You can fetch like this:
+-->
+- `/debug/api_priority_and_fairness/dump_queues` ——所有队列及其当前状态的列表。你可以这样获取：
+  ```shell
+  kubectl get --raw /debug/api_priority_and_fairness/dump_queues
+  ```
+
+  <!-- The output is similar to this: -->
+  输出类似于：
+  ```
+  PriorityLevelName, Index,  PendingRequests, ExecutingRequests, VirtualStart,
+  workload-high,     0,      0,               0,                 0.0000,
+  workload-high,     1,      0,               0,                 0.0000,
+  workload-high,     2,      0,               0,                 0.0000,
+  ...
+  leader-election,   14,     0,               0,                 0.0000,
+  leader-election,   15,     0,               0,                 0.0000,
+  ```
+
+<!--
+- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue.
+You can fetch like this:
+-->
+- `/debug/api_priority_and_fairness/dump_requests` ——当前正在队列中等待的所有请求的列表。你可以这样获取：
+  ```shell
+  kubectl get --raw /debug/api_priority_and_fairness/dump_requests
+  ```
+
+  <!-- The output is similar to this: -->
+  输出类似于：
+  ```
+  PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher,       ArriveTime,
+  exempt,            <none>,         <none>,     <none>,              <none>,                <none>,
+  system,            system-nodes,   12,         0,                   system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
+  ```
+
+  <!--
+  In addition to the queued requests,
+  the output includes one phantom line for each priority level that is exempt from limitation.
+  -->
+  针对每个优先级别，输出中还包含一条虚拟记录，对应豁免限制。
+
+  <!-- You can get a more detailed listing with a command like this: -->
+  你可以使用以下命令获得更详细的清单：
+  ```shell
+  kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'
+  ```
+
+  <!-- The output is similar to this: -->
+  输出类似于：
+  ```
+  PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher,       ArriveTime,                     UserName,              Verb,   APIPath,                                                     Namespace, Name,   APIVersion, Resource, SubResource,
+  system,            system-nodes,   12,         0,                   system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+  system,            system-nodes,   12,         1,                   system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
+  ```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+For background information on design details for API priority and fairness, see the
+[enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
+You can make suggestions and feature requests via
+[SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
+-->
+有关API优先级和公平性的设计细节的背景信息，
+请参阅[增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md)。
+你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 提出建议和特性请求。
diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md
index ad44bbc5cb..762fc1c050 100644
--- a/content/zh/docs/concepts/cluster-administration/logging.md
+++ b/content/zh/docs/concepts/cluster-administration/logging.md
@@ -14,9 +14,9 @@ weight: 60
 <!-- overview -->
 
 <!--
-Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
+Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
 -->
-应用和系统日志可以让你了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。
+应用日志可以让你了解应用内部的运行状况。日志对调试问题和监控集群活动非常有用。
 大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。
 针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。
 
@@ -45,14 +45,13 @@ the description of how logs are stored and handled on the node to be useful.
 
 In this section, you can see an example of basic logging in Kubernetes that
 outputs data to the standard output stream. This demonstration uses
-a [pod specification](/examples/debug/counter-pod.yaml) with
-a container that writes some text to standard output once per second.
+a pod specification with a container that writes some text to standard output
+once per second.
 -->
 ## Kubernetes 中的基本日志记录
 
 本节，你会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。
-这里通过一个特定的 [Pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器，
-并令该容器每秒钟向标准输出写入数据。
+这里的示例为包含一个容器的 Pod 规约，该容器每秒钟向标准输出写入数据。
 
 {{< codenew file="debug/counter-pod.yaml" >}}
 
diff --git a/content/zh/docs/concepts/cluster-administration/monitoring.md b/content/zh/docs/concepts/cluster-administration/monitoring.md
deleted file mode 100644
index a7e8e5c3c8..0000000000
--- a/content/zh/docs/concepts/cluster-administration/monitoring.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-title: Kubernetes 控制面的指标
-content_type: concept
-weight: 60
-aliases:
-- controller-metrics.md
----
-
-<!-- overview -->
-
-<!--
-System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
-
-Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
--->
-系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。
-
-Kubernetes 控制面板中的指标是以
-[prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/)
-格式发出的，而且是易于阅读的。
-
-<!-- body -->
-
-<!--
-## Metrics in Kubernetes
-In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag.
--->
-## Kubernetes 的指标
-
-在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用。
-对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。
-
-<!--
-Examples of those components:
--->
-举例下面这些组件：
-
-* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
-* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
-* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
-* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
-* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
-
-<!--
-In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper
-to periodically gather these metrics and make them available in some kind of time series database.
-
-Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle.
-
-If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
-For example:
--->
-在生产环境中，你可能需要配置 [Prometheus 服务器](https://prometheus.io/) 
-或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。
-
-请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在
-`/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes`  等端点提供性能指标。
-这些指标的生命周期并不相同。
-
-如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}，
-那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，
-才有权限访问 `/metrics` 。
-
-举例：
-
-```
-apiVersion: rbac.authorization.k8s.io/v1	
-kind: ClusterRole	
-metadata:	
-  name: prometheus	
-rules:	
-  - nonResourceURLs:	
-      - "/metrics"	
-    verbs:	
-      - get
-```
-
-<!--
-## Metric lifecycle
-Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion
-
-Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time.
-
-Stable metrics can be guaranteed to not change; Specifically, stability means:
--->
-## 指标的生命周期
-
-内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除
-
-内测版指标没有任何稳定性保证，因此可能随时被修改或删除。
-
-稳定版指标可以保证不会改变，具体的说，稳定就意味着：
-
-<!--
-* the metric itself will not be deleted (or renamed)
-* the type of metric will not be modified
--->
-
-* 这个指标自身不会被删除或者重命名。
-* 这个指标类型不会被更改
-
-<!--
-Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated.
-
-Before deprecation:
--->
-弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，
-注释中包括该指标从哪个 kubernetes 版本被弃用。
-
-指标弃用前：
-
-```
-# HELP some_counter this counts things
-# TYPE some_counter counter
-some_counter 0
-```
-
-<!-- After deprecation: -->
-指标弃用后：
-
-```
-# HELP some_counter (Deprecated since 1.15.0) this counts things
-# TYPE some_counter counter
-some_counter 0
-```
-
-<!--
-Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component.
-
-Once a metric is deleted, the metric is not published. You cannot change this using an override.
--->
-一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。
-如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。
-
-一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。
-
-<!--
-## Show Hidden Metrics
-
-As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
-
-The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release.
-
-The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy.
-
-Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion:
--->
-## 显示隐藏指标
-
-综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。
-当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。
-
-`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。
-这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，
-尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。
-
-这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，
-那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。
-
-以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论：
-
-<!--
-* In release `1.n`, the metric is deprecated, and it can be emitted by default.
-* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
-* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
-
-If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14`
--->
-
-* 在 `1.n` 版本中，这个指标被弃用，并且默认情况下，这个指标还是可以发出.
-* 在 `1.n+1` 版本中，这个指标默认被隐藏，你可以通过设置参数 `show-hidden-metrics-for-version=1.n` 来使它可以被发出.
-* 在 `1.n+2` 版本中，这个指标就被从代码库中删除，也不会再有后门了.
-
-如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，
-你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12`，
-但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。
-
-<!--
-## Component metrics
-
-### kube-controller-manager metrics
-
-Controller manager metrics provide important insight into the performance and health of the controller manager.
-These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
-etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
-to gauge the health of a cluster.
-
-Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
-These metrics can be used to monitor health of persistent volume operations.
-
-For example, for GCE these metrics are called:
--->
-## 组件指标
-
-### kube-controller-manager 指标
-
-控制器管理器指标提供了有关控制器管理器性能和运行状况的重要见解。这些指标包括常见的一些 Go 语言运行时的重要指标（比如 go_routine 的数量）和一些控制器的特定指标（比如 etcd 的请求时延），还有一些云供应商（比如 AWS、GCE、OpenStack）的 API 请求延迟，用来评估集群的整体运行状况。
-
-从 Kubernetes 1.7 开始，详细的云供应商指标便可用于 GCE、 AWS、Vsphere 和 OpenStack 的存储操作，这些指标可用于监控持久卷运行时的健康状况。
-
-举例，GCE 的这些指标是这些：
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-## {{% heading "whatsnext" %}}
-
-<!--
-* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
-* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
-* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
--->
-
-* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
-* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
-* 了解有关 [Kubernetes 指标弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
-
-
diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md
index fdc5efd0a0..06ff565cff 100644
--- a/content/zh/docs/concepts/cluster-administration/networking.md
+++ b/content/zh/docs/concepts/cluster-administration/networking.md
@@ -140,6 +140,8 @@ imply any preferential status.
 
 接下来的网络技术是按照首字母排序，顺序本身并无其他意义。
 
+{{% thirdparty-content %}}
+
 <!--
 ### ACI
 
@@ -267,6 +269,19 @@ BCF 被 Gartner 认为是非常有远见的。
 而 BCF 的一条关于 Kubernetes 的本地部署（其中包括 Kubernetes、DC/OS 和在不同地理区域的多个
 DC 上运行的 VMware）也在[这里](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)被引用。
 
+<!--
+### Calico
+
+[Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
+-->
+### Calico
+
+[Calico](https://docs.projectcalico.org/) 是一个开源的联网及网络安全方案，
+用于基于容器、虚拟机和本地主机的工作负载。
+Calico 支持多个数据面，包括：纯 Linux eBPF 的数据面、标准的 Linux 联网数据面
+以及 Windwos HNS 数据面。Calico 在提供完整的联网堆栈的同时，还可与
+[云驱动 CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) 联合使用，以保证网络策略实施。
+
 <!--
 ### Cilium
 
@@ -637,27 +652,6 @@ OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方
 它允许创建逻辑交换器、逻辑路由、状态 ACL、负载均衡等等来建立不同的虚拟网络拓扑。
 该项目有一个特定的Kubernetes插件和文档 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)。
 
-<!--
-### Project Calico
-
-[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
-
-Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)).  Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking.  Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
-
-Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
--->
-### Calico 项目  {#project-calico}
-
-[Calico 项目](https://docs.projectcalico.org/) 是一个开源的容器网络提供者和网络策略引擎。
-
-Calico 提供了高度可扩展的网络和网络解决方案，使用基于与 Internet 相同的 IP 网络原理来连接 Kubernetes Pod，
-适用于 Linux （开放源代码）和 Windows（专有-可从 [Tigera](https://www.tigera.io/essentials/) 获得。
-可以无需封装或覆盖即可部署 Calico，以提供高性能，高可扩的数据中心网络。
-Calico 还通过其分布式防火墙为 Kubernetes Pod 提供了基于意图的细粒度网络安全策略。
-
-Calico 还可以和其他的网络解决方案（比如 Flannel、[canal](https://github.com/tigera/canal) 
-或原生 GCE、AWS、Azure 网络等）一起以策略实施模式运行。
-
 <!--
 ### Romana
 
diff --git a/content/zh/docs/concepts/cluster-administration/system-logs.md b/content/zh/docs/concepts/cluster-administration/system-logs.md
new file mode 100644
index 0000000000..14e455641b
--- /dev/null
+++ b/content/zh/docs/concepts/cluster-administration/system-logs.md
@@ -0,0 +1,209 @@
+---
+title: 系统日志
+content_type: concept
+weight: 60
+---
+<!-- 
+reviewers:
+- dims
+- 44past4
+title: System Logs
+content_type: concept
+weight: 60
+-->
+
+<!-- overview -->
+
+<!--
+System component logs record events happening in cluster, which can be very useful for debugging.
+You can configure log verbosity to see more or less detail.
+Logs can be as coarse-grained as showing errors within a component, or as fine-grained as showing step-by-step traces of events (like HTTP access logs, pod state changes, controller actions, or scheduler decisions).
+-->
+系统组件的日志记录集群中发生的事件，这对于调试非常有用。
+你可以配置日志的精细度，以展示更多或更少的细节。
+日志可以是粗粒度的，如只显示组件内的错误，
+也可以是细粒度的，如显示事件的每一个跟踪步骤（比如 HTTP 访问日志、pod 状态更新、控制器动作或调度器决策）。
+
+<!-- body -->
+
+## Klog
+
+<!--
+klog is the Kubernetes logging library. [klog](https://github.com/kubernetes/klog)
+generates log messages for the Kubernetes system components.
+
+For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/).
+
+An example of the klog native format:
+-->
+klog 是 Kubernetes 的日志库。 
+[klog](https://github.com/kubernetes/klog) 
+为 Kubernetes 系统组件生成日志消息。
+
+有关 klog 配置的更多信息，请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。
+
+klog 原始格式的示例：
+```
+I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
+```
+
+<!-- 
+### Structured Logging 
+-->
+### 结构化日志
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+<!--
+Migration to structured log messages is an ongoing process. Not all log messages are structured in this version. When parsing log files, you must also handle unstructured log messages.
+
+Log formatting and value serialization are subject to change.
+-->
+{{<warning>}}
+到结构化日志消息的迁移是一个持续的过程。
+在此版本中，并非所有日志消息都是结构化的。
+解析日志文件时，你也必须要处理非结构化日志消息。
+
+日志格式和值的序列化可能会发生变化。
+{{< /warning>}}
+
+<!--
+Structured logging is a effort to introduce a uniform structure in log messages allowing for easy extraction of information, making logs easier and cheaper to store and process.
+New message format is backward compatible and enabled by default.
+
+Format of structured logs:
+-->
+结构化日志记录旨在日志消息中引入统一结构，以方便提取信息，使日志的存储和处理更容易、成本更低。
+新的消息格式向后兼容，并默认启用。
+
+结构化日志的格式：
+```
+<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
+```
+
+<!-- Example: -->
+示例：
+```
+I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
+```
+
+
+<!--
+### JSON log format
+-->
+### JSON 日志格式
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+<!--
+JSON output does not support many standard klog flags. For list of unsupported klog flags, see the [Command line tool reference](/docs/reference/command-line-tools-reference/).
+
+Not all logs are guaranteed to be written in JSON format (for example, during process start). If you intend to parse logs, make sure you can handle log lines that are not JSON as well.
+
+Field names and JSON serialization are subject to change.
+-->
+{{<warning >}}
+JSON 输出并不支持太多标准 klog 参数。
+对于不受支持的 klog 参数的列表，请参见
+[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。
+
+并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。
+如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。
+
+字段名和 JSON 序列化可能会发生变化。
+{{< /warning >}}
+
+<!--
+The `--logging-format=json` flag changes the format of logs from klog native format to JSON format.
+Example of JSON log format (pretty printed):
+-->
+`--logging-format=json` 参数将日志格式从 klog 原生格式改为 JSON 格式。
+JSON 日志格式示例（美化输出）：
+```json
+{
+   "ts": 1580306777.04728,
+   "v": 4,
+   "msg": "Pod status updated",
+   "pod":{
+      "name": "nginx-1",
+      "namespace": "default"
+   },
+   "status": "ready"
+}
+```
+
+<!--
+Keys with special meaning:
+* `ts` - timestamp as Unix time (required, float)
+* `v` - verbosity (required, int, default 0)
+* `err` - error string (optional, string)
+* `msg` - message (required, string)
+
+List of components currently supporting JSON format:
+-->
+具有特殊意义的 key：
+* `ts` - Unix 时间风格的时间戳（必选项，浮点值）
+* `v` - 精细度（必选项，整数，默认值 0）
+* `err` - 错误字符串（可选项，字符串）
+* `msg` - 消息（必选项，字符串）
+
+当前支持JSON格式的组件列表：
+* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
+* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
+
+<!--
+### Log verbosity level
+
+The `-v` flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events.
+Increasing verbosity settings logs increasingly less severe events. A verbosity setting of 0 logs only critical events.
+-->
+### 日志精细度级别
+
+参数 `-v` 控制日志的精细度。增大该值会增大日志事件的数量。
+减小该值可以减小日志事件的数量。
+增大精细度会记录更多的不太严重的事件。
+精细度设置为 0 时只记录关键（critical）事件。
+
+<!--
+### Log location
+
+There are two types of system components: those that run in a container and those
+that do not run in a container. For example:
+
+* The Kubernetes scheduler and kube-proxy run in a container.
+* The kubelet and container runtime, for example Docker, do not run in containers.
+-->
+### 日志位置
+
+有两种类型的系统组件：运行在容器中的组件和不运行在容器中的组件。例如：
+* Kubernetes 调度器和 kube-proxy 在容器中运行。
+* kubelet 和容器运行时，例如 Docker，不在容器中运行。
+
+<!--
+On machines with systemd, the kubelet and container runtime write to journald.
+Otherwise, they write to `.log` files in the `/var/log` directory.
+System components inside containers always write to `.log` files in the `/var/log` directory,
+bypassing the default logging mechanism.
+Similar to the container logs, you should rotate system component logs in the `/var/log` directory.
+In Kubernetes clusters created by the `kube-up.sh` script, log rotation is configured by the `logrotate` tool.
+The `logrotate` tool rotates logs daily, or once the log size is greater than 100MB.
+-->
+在使用 systemd 的系统中，kubelet 和容器运行时写入 journald。
+在别的系统中，日志写入 `/var/log` 目录下的 `.log` 文件中。
+容器中的系统组件总是绕过默认的日志记录机制，写入 `/var/log` 目录下的 `.log` 文件。
+与容器日志类似，你应该轮转 `/var/log` 目录下系统组件日志。
+在 `kube-up.sh` 脚本创建的 Kubernetes 集群中，日志轮转由 `logrotate` 工具配置。
+ `logrotate` 工具，每天或者当日志大于 100MB 时，轮转日志。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Read about the [Kubernetes Logging Architecture](/docs/concepts/cluster-administration/logging/)
+* Read about [Structured Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
+* Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
+-->
+* 阅读 [Kubernetes 日志架构](/zh/docs/concepts/cluster-administration/logging/)
+* 阅读 [Structured Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
+* 阅读 [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
diff --git a/content/zh/docs/concepts/cluster-administration/system-metrics.md b/content/zh/docs/concepts/cluster-administration/system-metrics.md
new file mode 100644
index 0000000000..a55275c37d
--- /dev/null
+++ b/content/zh/docs/concepts/cluster-administration/system-metrics.md
@@ -0,0 +1,238 @@
+---
+title: Kubernetes 系统组件指标
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+<!--
+System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
+
+Kubernetes components emit metrics in [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/).
+This format is structured plain text, designed so that people and machines can both read it.
+-->
+系统组件指标可以更好地了解系统内部发生的情况。指标对于构建仪表板和告警特别有用。
+
+Kubernetes 组件以 [Prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/)生成度量值。
+这种格式是结构化的纯文本，旨在使人和机器都可以阅读。
+
+<!-- body -->
+
+<!--
+## Metrics in Kubernetes
+
+In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag.
+
+Examples of those components:
+
+* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
+* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
+* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
+
+In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper
+to periodically gather these metrics and make them available in some kind of time series database.
+
+Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle.
+
+If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
+For example:
+-->
+## Kubernetes 中的指标
+
+在大多数情况下，可以在 HTTP 服务器的 `/metrics` 端点上访问度量值。
+对于默认情况下不公开端点的组件，可以使用 `--bind-address` 标志启用。
+
+这些组件的示例：
+
+* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
+* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
+* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
+
+在生产环境中，你可能需要配置 [Prometheus 服务](https://prometheus.io/) 或
+某些其他指标搜集器以定期收集这些指标，并使它们在某种时间序列数据库中可用。
+
+请注意，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 还会在 `/metrics/cadvisor`，
+`/metrics/resource` 和 `/metrics/probes` 端点中公开度量值。这些度量值的生命周期各不相同。
+
+如果你的集群使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}，
+则读取指标需要通过基于用户、组或 ServiceAccount 的鉴权，要求具有允许访问 `/metrics` 的 ClusterRole。
+例如：
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: prometheus
+rules:
+  - nonResourceURLs:
+      - "/metrics"
+    verbs:
+      - get
+```
+
+<!--
+## Metric lifecycle
+
+Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion
+
+Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time.
+
+Stable metrics can be guaranteed to not change; Specifically, stability means:
+
+* the metric itself will not be deleted (or renamed)
+* the type of metric will not be modified
+
+Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated.
+-->
+## 指标生命周期
+
+Alpha 指标 →  稳定指标 →  弃用指标 →  隐藏指标 → 删除
+
+Alpha 指标没有稳定性保证，因此可以随时对其进行修改或者删除。
+
+稳定指标可以保证不会改变；具体而言，稳定意味着：
+
+* 指标本身不会被删除（或重命名）
+* 指标的类型不会被更改
+
+已弃用的指标表明该指标最终将被删除；要搞清楚对应版本，你需要检查其注解，
+其中包括从哪个 kubernetes 版本开始，将不再考虑该指标。
+
+过期前：
+
+```
+# HELP some_counter this counts things
+# TYPE some_counter counter
+some_counter 0
+```
+
+过期后:
+
+```
+# HELP some_counter (Deprecated since 1.15.0) this counts things
+# TYPE some_counter counter
+some_counter 0
+```
+
+<!--
+Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component.
+
+Once a metric is deleted, the metric is not published. You cannot change this using an override.
+-->
+隐藏指标后，默认情况下，该指标不会发布以供抓取。要使用隐藏指标，你需要覆盖相关集群组件的配置。
+
+指标一旦删除，就不会发布。你无法通过重载配置来改变这一点。
+
+<!--
+## Show Hidden Metrics
+
+As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
+
+The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release.
+
+The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy.
+
+Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion:
+-->
+## 显示隐藏指标
+
+综上所述，管理员可以通过设置可执行文件的命令行参数来启用隐藏指标，
+如果管理员错过了上一版本中已经弃用的指标的迁移，则可以把这个用作管理员的逃生门。
+
+`show-hidden-metrics-for-version` 标志接受版本号作为取值，版本号给出你希望显示该发行版本中已弃用的指标。
+版本表示为 x.y，其中 x 是主要版本，y 是次要版本。补丁程序版本不是必须的，
+即使指标可能会在补丁程序发行版中弃用，原因是指标弃用策略规定仅针对次要版本。
+
+该参数只能使用前一个次要版本。如果管理员将先前版本设置为 `show-hidden-metrics-for-version`，
+则先前版本中隐藏的度量值会再度生成。不允许使用过旧的版本，因为那样会违反指标弃用策略。
+
+以指标 `A` 为例，此处假设 `A` 在 1.n 中已弃用。根据指标弃用策略，我们可以得出以下结论：
+
+<!--
+* In release `1.n`, the metric is deprecated, and it can be emitted by default.
+* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
+* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
+
+If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14`
+-->
+* 在版本 `1.n` 中，这个指标已经弃用，且默认情况下可以生成。
+* 在版本 `1.n+1` 中，这个指标默认隐藏，可以通过命令行参数 `show-hidden-metrics-for-version=1.n` 来再度生成。
+* 在版本 `1.n+2` 中，这个指标就将被从代码中移除，不会再有任何逃生窗口。
+
+如果你要从版本 `1.12` 升级到 `1.13`，但仍依赖于 `1.12` 中弃用的指标 `A`，则应通过命令行设置隐藏指标：
+`--show-hidden-metrics=1.12`，并记住在升级到 `1.14` 版本之前删除此指标依赖项。
+
+<!--
+## Disable accelerator metrics
+
+The kubelet collects accelerator metrics through cAdvisor. To collect these metrics, for accelerators like NVIDIA GPUs, kubelet held an open handle on the driver. This meant that in order to perform infrastructure changes (for example, updating the driver), a cluster administrator needed to stop the kubelet agent.
+
+The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus).
+
+The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
+-->
+## 禁用加速器指标
+
+kubelet 通过 cAdvisor 收集加速器指标。为了收集这些指标，对于 NVIDIA GPU 之类的加速器，
+kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结构更改（例如更新驱动程序），
+集群管理员需要停止 kubelet 代理。
+
+现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器，
+并将其公开给指标服务（例如 Prometheus）。
+
+[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false)
+禁止由 kubelet 收集的指标。
+关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。
+
+<!--
+## Component metrics
+
+### kube-controller-manager metrics
+
+Controller manager metrics provide important insight into the performance and health of the controller manager.
+These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
+etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
+to gauge the health of a cluster.
+
+Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
+These metrics can be used to monitor health of persistent volume operations.
+
+For example, for GCE these metrics are called:
+-->
+## 组件指标
+
+### kube-controller-manager 指标
+
+控制器管理器指标可提供有关控制器管理器性能和运行状况的重要洞察。
+这些指标包括通用的 Go 语言运行时指标（例如 go_routine 数量）和控制器特定的度量指标，
+例如可用于评估集群运行状况的 etcd 请求延迟或云提供商（AWS、GCE、OpenStack）的 API 延迟等。
+
+从 Kubernetes 1.7 版本开始，详细的云提供商指标可用于 GCE、AWS、Vsphere 和 OpenStack 的存储操作。
+这些指标可用于监控持久卷操作的运行状况。
+
+比如，对于 GCE，这些指标称为：
+
+```
+cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
+cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
+```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
+* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
+* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
+-->
+* 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
+* 查看 [Kubernetes 稳定指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)的列表
+* 阅读有关 [Kubernetes 弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
diff --git a/content/zh/docs/concepts/configuration/_index.md b/content/zh/docs/concepts/configuration/_index.md
index c2419c817b..4cbc3843b8 100644
--- a/content/zh/docs/concepts/configuration/_index.md
+++ b/content/zh/docs/concepts/configuration/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "配置"
-weight: 70
+weight: 80
+description: Kubernetes 为配置 Pods 提供的资源。
 ---
diff --git a/content/zh/docs/concepts/configuration/configmap.md b/content/zh/docs/concepts/configuration/configmap.md
index d1aa8fa01a..a9240bff7f 100644
--- a/content/zh/docs/concepts/configuration/configmap.md
+++ b/content/zh/docs/concepts/configuration/configmap.md
@@ -15,10 +15,11 @@ If the data you want to store are confidential, use a
 {{< glossary_tooltip text="Secret" term_id="secret" >}} rather than a ConfigMap,
 or use additional (third party) tools to keep your data private.
 -->
-ConfigMap 并不提供保密或者加密功能。如果你想存储的数据是机密的，请使用 {{< glossary_tooltip text="Secret" term_id="secret" >}} ，或者使用其他第三方工具来保证你的数据的私密性，而不是用 ConfigMap。
+ConfigMap 并不提供保密或者加密功能。
+如果你想存储的数据是机密的，请使用 {{< glossary_tooltip text="Secret" term_id="secret" >}}，
+或者使用其他第三方工具来保证你的数据的私密性，而不是用 ConfigMap。
 {{< /caution >}}
 
-
 <!-- body -->
 <!--
 ## Motivation
@@ -27,31 +28,45 @@ Use a ConfigMap for setting configuration data separately from application code.
 
 For example, imagine that you are developing an application that you can run on your
 own computer (for development) and in the cloud (to handle real traffic).
-You write the code to
-look in an environment variable named `DATABASE_HOST`. Locally, you set that variable
-to `localhost`. In the cloud, you set it to refer to a Kubernetes
-{{< glossary_tooltip text="Service" term_id="service" >}} that exposes the database
-component to your cluster.
-
+You write the code to look in an environment variable named `DATABASE_HOST`.
+Locally, you set that variable to `localhost`. In the cloud, you set it to
+refer to a Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}}
+that exposes the database component to your cluster.
 This lets you fetch a container image running in the cloud and
 debug the exact same code locally if needed.
 -->
-
-## 动机
+## 动机   {#motivation}
 
 使用 ConfigMap 来将你的配置数据和应用程序代码分开。
 
-比如，假设你正在开发一个应用，它可以在你自己的电脑上（用于开发）和在云上（用于实际流量）运行。你的代码里有一段是用于查看环境变量 `DATABASE_HOST`，在本地运行时，你将这个变量设置为 `localhost`，在云上，你将其设置为引用 Kubernetes 集群中的公开数据库 {{< glossary_tooltip text="Service" term_id="service" >}} 中的组件。
+比如，假设你正在开发一个应用，它可以在你自己的电脑上（用于开发）和在云上
+（用于实际流量）运行。
+你的代码里有一段是用于查看环境变量 `DATABASE_HOST`，在本地运行时，
+你将这个变量设置为 `localhost`，在云上，你将其设置为引用 Kubernetes 集群中的
+公开数据库组件的 {{< glossary_tooltip text="服务" term_id="service" >}}。
 
-这让您可以获取在云中运行的容器镜像，并且如果有需要的话，在本地调试完全相同的代码。
+这让你可以获取在云中运行的容器镜像，并且如果有需要的话，在本地调试完全相同的代码。
+
+<!--
+A ConfigMap is not designed to hold large chunks of data. The data stored in a
+ConfigMap cannot exeed 1 MiB. If you need to store settings that are
+larger than this limit, you may want to consider mounting a volume or use a
+separate database or file service.
+-->
+ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过
+1 MiB。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷
+或者使用独立的数据库或者文件服务。
 
 <!--
 ## ConfigMap object
 
 A ConfigMap is an API [object](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
 that lets you store configuration for other objects to use. Unlike most
-Kubernetes objects that have a `spec`, a ConfigMap has a `data` section to
-store items (keys) and their values.
+Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
+fields. These fields accepts key-value pairs as their values.  Both the `data`
+field and the `binaryData` are optional. The `data` field is designed to
+contain UTF-8 byte sequences while the `binaryData` field is designed to
+contain binary data.
 
 The name of a ConfigMap must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -60,9 +75,28 @@ The name of a ConfigMap must be a valid
 
 ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)，
 让你可以存储其他对象所需要使用的配置。
-和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。
+和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 和
+`binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData`
+字段都是可选的。`data` 字段设计用来保存 UTF-8 字节序列，而 `binaryData` 则
+被设计用来保存二进制数据。
 
-ConfigMap 的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+ConfigMap 的名字必须是一个合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+
+<!--
+Each key under the `data` or the `binaryData` field must consist of
+alphanumeric characters, `-`, `_` or `.`. The keys stored in `data` must not
+overlap with the keys in the `binaryData` field.
+
+Starting from v1.19, you can add an `immutable` field to a ConfigMap
+definition to create an [immutable ConfigMap](#configmap-immutable).
+-->
+`data` 或 `binaryData` 字段下面的每个键的名称都必须由字母数字字符或者
+`-`、`_` 或 `.` 组成。在 `data` 下保存的键名不可以与在 `binaryData` 下
+出现的键名有重叠。
+
+从 v1.19 开始，你可以添加一个 `immutable` 字段到 ConfigMap 定义中，创建
+[不可变更的 ConfigMap](#configmap-immutable)。
 
 <!--
 ## ConfigMaps and Pods
@@ -77,9 +111,12 @@ format.
 -->
 ## ConfigMaps 和 Pods
 
-您可以写一个引用 ConfigMap 的 Pod 的 `spec`，并根据 ConfigMap 中的数据在该 Pod 中配置容器。这个 Pod 和 ConfigMap 必须要在同一个 {{< glossary_tooltip text="命名空间" term_id="namespace" >}} 中。
+你可以写一个引用 ConfigMap 的 Pod 的 `spec`，并根据 ConfigMap 中的数据
+在该 Pod 中配置容器。这个 Pod 和 ConfigMap 必须要在同一个
+{{< glossary_tooltip text="名字空间" term_id="namespace" >}} 中。
 
-这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是配置的片段格式。
+这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是
+配置的片段格式。
 
 ```yaml
 apiVersion: v1
@@ -90,7 +127,7 @@ data:
   # 类属性键；每一个键都映射到一个简单的值
   player_initial_lives: "3"
   ui_properties_file_name: "user-interface.properties"
-  #
+
   # 类文件键
   game.properties: |
     enemy.types=aliens,monsters
@@ -115,14 +152,16 @@ For the first three methods, the
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the data from
 the ConfigMap when it launches container(s) for a Pod.
 -->
-您可以使用四种方式来使用 ConfigMap 配置 Pod 中的容器：
+你可以使用四种方式来使用 ConfigMap 配置 Pod 中的容器：
 
 1. 容器 entrypoint 的命令行参数
 1. 容器的环境变量
 1. 在只读卷里面添加一个文件，让应用来读取
 1. 编写代码在 Pod 中运行，使用 Kubernetes API 来读取 ConfigMap
 
-这些不同的方法适用于不同的数据使用方式。对前三个方法，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 使用 ConfigMap 中的数据在 Pod 中启动容器。
+这些不同的方法适用于不同的数据使用方式。
+对前三个方法，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
+使用 ConfigMap 中的数据在 Pod 中启动容器。
 
 <!--
 The fourth method means you have to write code to read the ConfigMap and its data.
@@ -133,9 +172,13 @@ technique also lets you access a ConfigMap in a different namespace.
 
 Here's an example Pod that uses values from `game-demo` to configure a Pod:
 -->
-第四种方法意味着你必须编写代码才能读取 ConfigMap 和它的数据。然而，由于您是直接使用 Kubernetes API，因此只要 ConfigMap 发生更改，您的应用就能够通过订阅来获取更新，并且在这样的情况发生的时候做出反应。通过直接进入 Kubernetes API，这个技术也可以让你能够获取到不同的命名空间里的 ConfigMap。
+第四种方法意味着你必须编写代码才能读取 ConfigMap 和它的数据。然而，
+由于你是直接使用 Kubernetes API，因此只要 ConfigMap 发生更改，你的
+应用就能够通过订阅来获取更新，并且在这样的情况发生的时候做出反应。
+通过直接进入 Kubernetes API，这个技术也可以让你能够获取到不同的名字空间
+里的 ConfigMap。
 
-这是一个 Pod 的示例，它通过使用 `game-demo` 中的值来配置一个 Pod：
+下面是一个 Pod 的示例，它通过使用 `game-demo` 中的值来配置一个 Pod：
 
 ```yaml
 apiVersion: v1
@@ -145,7 +188,8 @@ metadata:
 spec:
   containers:
     - name: demo
-      image: game.example/demo-game
+      image: alpine
+      command: ["sleep", "3600"]
       env:
         # 定义环境变量
         - name: PLAYER_INITIAL_LIVES # 请注意这里和 ConfigMap 中的键名是不一样的
@@ -163,41 +207,56 @@ spec:
         mountPath: "/config"
         readOnly: true
   volumes:
-    # 您可以在 Pod 级别设置卷，然后将其挂载到 Pod 内的容器中
+    # 你可以在 Pod 级别设置卷，然后将其挂载到 Pod 内的容器中
     - name: config
       configMap:
         # 提供你想要挂载的 ConfigMap 的名字
         name: game-demo
+        # 来自 ConfigMap 的一组键，将被创建为文件
+        items:
+        - key: "game.properties"
+          path: "game.properties"
+        - key: "user-interface.properties"
+          path: "user-interface.properties"
 ```
 
 <!--
 A ConfigMap doesn't differentiate between single line property values and
 multi-line file-like values.
 What matters how Pods and other objects consume those values.
+
 For this example, defining a volume and mounting it inside the `demo`
-container as `/config` creates four files:
-
-- `/config/player_initial_lives`
-- `/config/ui_properties_file_name`
-- `/config/game.properties`
-- `/config/user-interface.properties`
-
-If you want to make sure that `/config` only contains files with a
-`.properties` extension, use two different ConfigMaps, and refer to both
-ConfigMaps in the `spec` for a Pod. The first ConfigMap defines
-`player_initial_lives` and `ui_properties_file_name`. The second
-ConfigMap defines the files that the kubelet places into `/config`.
+container as `/config` creates two files,
+`/config/game.properties` and `/config/user-interface.properties`,
+even though there are four keys in the ConfigMap. This is because the Pod
+definition specifies an `items` array in the `volumes` section.
+If you omit the `items` array entirely, every key  in the ConfigMap becomes
+a file with the same name as the key, and you get 4 files.
 -->
-ConfigMap 不会区分单行属性值和多行类似文件的值，重要的是 Pods 和其他对象如何使用这些值。比如，定义一个卷，并将它作为 `/config` 文件夹安装到 `demo` 容器内，并创建四个文件：
+ConfigMap 不会区分单行属性值和多行类似文件的值，重要的是 Pods 和其他对象
+如何使用这些值。
 
-- `/config/player_initial_lives`
-- `/config/ui_properties_file_name`
-- `/config/game.properties`
-- `/config/user-interface.properties`
+上面的例子定义了一个卷并将它作为 `/config` 文件夹挂载到 `demo` 容器内，
+创建两个文件，`/config/game.properties` 和
+`/config/user-interface.properties`，
+尽管 ConfigMap 中包含了四个键。
+这是因为 Pod 定义中在 `volumes` 节指定了一个 `items` 数组。
+如果你完全忽略 `items` 数组，则 ConfigMap 中的每个键都会变成一个与
+该键同名的文件，因此你会得到四个文件。
 
-如果您要确保 `/config` 只包含带有 `.properties` 扩展名的文件，可以使用两个不同的 ConfigMaps，并在 `spec` 中同时引用这两个 ConfigMaps 来创建 Pod。第一个 ConfigMap 定义了 `player_initial_lives` 和 `ui_properties_file_name`，第二个 ConfigMap 定义了 kubelet 放进 `/config` 的文件。
+<!--
+## Using ConfigMaps
+
+ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
+parts of the system, without being directly exposed to the Pod. For example,
+ConfigMaps can hold data that other parts of the system should use for configuration.
+-->
+## 使用 ConfigMap   {#using-configmaps}
+
+ConfigMap 可以作为数据卷挂载。ConfigMap 也可被系统的其他组件使用，而
+不一定直接暴露给 Pod。例如，ConfigMap 可以保存系统中其他组件要使用
+的配置数据。
 
-{{< note >}}
 <!--
 The most common way to use ConfigMaps is to configure settings for
 containers running in a Pod in the same namespace. You can also use a
@@ -208,12 +267,178 @@ might encounter {{< glossary_tooltip text="addons" term_id="addons" >}}
 or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
 adjust their behavior based on a ConfigMap.
 -->
-ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容器执行配置。您也可以单独使用 ConfigMap。
+ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容器执行配置。
+你也可以单独使用 ConfigMap。
 
-比如，您可能会遇到基于 ConfigMap 来调整其行为的 {{< glossary_tooltip text="插件" term_id="addons" >}} 或者 {{< glossary_tooltip text="operator" term_id="operator-pattern" >}}。
-{{< /note >}}
+比如，你可能会遇到基于 ConfigMap 来调整其行为的
+{{< glossary_tooltip text="插件" term_id="addons" >}} 或者
+{{< glossary_tooltip text="operator" term_id="operator-pattern" >}}。
 
+<!--
+### Using ConfigMaps as files from a Pod
 
+To consume a ConfigMap in a volume in a Pod:
+-->
+### 在 Pod 中将 ConfigMap 当做文件使用
+
+<!--
+1. Create a ConfigMap or use an existing one. Multiple Pods can reference the
+   same ConfigMap.
+1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name
+   the volume anything, and have a `.spec.volumes[].configMap.name` field set
+   to reference your ConfigMap object.
+1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the
+   ConfigMap. Specify `.spec.containers[].volumeMounts[].readOnly = true` and
+   `.spec.containers[].volumeMounts[].mountPath` to an unused directory name
+   where you would like the ConfigMap to appear.
+1. Modify your image or command line so that the program looks for files in
+   that directory. Each key in the ConfigMap `data` map becomes the filename
+   under `mountPath`.
+-->
+1. 创建一个 ConfigMap 对象或者使用现有的 ConfigMap 对象。多个 Pod 可以引用同一个
+   ConfigMap。
+1. 修改 Pod 定义，在 `spec.volumes[]` 下添加一个卷。
+   为该卷设置任意名称，之后将 `spec.volumes[].configMap.name` 字段设置为对
+   你的 ConfigMap 对象的引用。
+1. 为每个需要该 ConfigMap 的容器添加一个 `.spec.containers[].volumeMounts[]`。
+   设置 `.spec.containers[].volumeMounts[].readOnly=true` 并将
+   `.spec.containers[].volumeMounts[].mountPath` 设置为一个未使用的目录名，
+   ConfigMap 的内容将出现在该目录中。
+1. 更改你的镜像或者命令行，以便程序能够从该目录中查找文件。ConfigMap 中的每个
+   `data` 键会变成 `mountPath` 下面的一个文件名。
+
+<!--
+This is an example of a Pod that mounts a ConfigMap in a volume:
+-->
+下面是一个将 ConfigMap 以卷的形式进行挂载的 Pod 示例：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+      readOnly: true
+  volumes:
+  - name: foo
+    configMap:
+      name: myconfigmap
+```
+
+<!--
+Each ConfigMap you want to use needs to be referred to in `.spec.volumes`.
+
+If there are multiple containers in the Pod, then each container needs its
+own `volumeMounts` block, but only one `.spec.volumes` is needed per ConfigMap.
+-->
+你希望使用的每个 ConfigMap 都需要在 `spec.volumes` 中被引用到。
+
+如果 Pod 中有多个容器，则每个容器都需要自己的 `volumeMounts` 块，但针对
+每个 ConfigMap，你只需要设置一个 `spec.volumes` 块。
+
+<!--
+#### Mounted ConfigMaps are updated automatically
+
+When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well.
+The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync.
+However, the kubelet uses its local cache for getting the current value of the ConfigMap.
+The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in
+the [KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+-->
+#### 被挂载的 ConfigMap 内容会被自动更新
+
+当卷中使用的 ConfigMap 被更新时，所投射的键最终也会被更新。
+kubelet 组件会在每次周期性同步时检查所挂载的 ConfigMap 是否为最新。
+不过，kubelet 使用的是其本地的高速缓存来获得 ConfigMap 的当前值。
+高速缓存的类型可以通过
+[KubeletConfiguration 结构](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)
+的 `ConfigMapAndSecretChangeDetectionStrategy` 字段来配置。
+
+<!--
+A ConfigMap can be either propagated by watch (default), ttl-based, or simply redirecting
+all requests directly to the API server.
+As a result, the total delay from the moment when the ConfigMap is updated to the moment
+when new keys are projected to the Pod can be as long as the kubelet sync period + cache
+propagation delay, where the cache propagation delay depends on the chosen cache type
+(it equals to watch propagation delay, ttl of cache, or zero correspondingly).
+-->
+ConfigMap 既可以通过 watch 操作实现内容传播（默认形式），也可实现基于 TTL
+的缓存，还可以直接将所有请求重定向到 API 服务器。
+因此，从 ConfigMap 被更新的那一刻算起，到新的主键被投射到 Pod 中去，这一
+时间跨度可能与 kubelet 的同步周期加上高速缓存的传播延迟相等。
+这里的传播延迟取决于所选的高速缓存类型
+（分别对应 watch 操作的传播延迟、高速缓存的 TTL 时长或者 0）。
+
+<!--
+ConfigMaps consumed as environment variables are not updated automatically and require a pod restart. 
+-->
+以环境变量方式使用的 ConfigMap 数据不会被自动更新。
+更新这些数据需要重新启动 Pod。
+
+<!--
+## Immutable ConfigMaps {#configmap-immutable}
+-->
+## 不可变更的 ConfigMap     {#configmap-immutable}
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+<!--
+The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set
+individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps
+(at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their
+data has the following advantages:
+-->
+Kubernetes Beta 特性 _不可变更的 Secret 和 ConfigMap_ 提供了一种将各个
+Secret 和 ConfigMap 设置为不可变更的选项。对于大量使用 ConfigMap 的
+集群（至少有数万个各不相同的 ConfigMap 给 Pod 挂载）而言，禁止更改
+ConfigMap 的数据有以下好处：
+
+<!--
+- protects you from accidental (or unwanted) updates that could cause applications outages
+- improves performance of your cluster by significantly reducing load on kube-apiserver, by
+  closing watches for ConfigMaps marked as immutable.
+-->
+- 保护应用，使之免受意外（不想要的）更新所带来的负面影响。
+- 通过大幅降低对 kube-apiserver 的压力提升集群性能，这是因为系统会关闭
+  对已标记为不可变更的 ConfigMap 的监视操作。
+
+<!--
+This feature is controlled by the `ImmutableEphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+You can create an immutable ConfigMap by setting the `immutable` field to `true`.
+For example:
+-->
+此功能特性由 `ImmutableEphemeralVolumes`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+来控制。你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。
+例如：
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+<!--
+Once a ConfigMap is marked as immutable, it is _not_ possible to revert this change
+nor to mutate the contents of the `data` or the `binaryData` field. You can
+only delete and recreate the ConfigMap. Because existing Pods maintain a mount point
+to the deleted ConfigMap, it is recommended to recreate these pods.
+-->
+一旦某 ConfigMap 被标记为不可变更，则 _无法_ 逆转这一变化，，也无法更改
+`data` 或 `binaryData` 字段的内容。你只能删除并重建 ConfigMap。
+因为现有的 Pod 会维护一个对已删除的 ConfigMap 的挂载点，建议重新创建
+这些 Pods。
 
 ## {{% heading "whatsnext" %}}
 
@@ -227,4 +452,3 @@ ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容
 * 阅读 [配置 Pod 来使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
 * 阅读 [Twelve-Factor 应用](https://12factor.net/) 来了解将代码和配置分开的动机。
 
-
diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh/docs/concepts/configuration/manage-resources-containers.md
index ef14f7608d..bb5e7ba114 100644
--- a/content/zh/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/zh/docs/concepts/configuration/manage-resources-containers.md
@@ -54,7 +54,6 @@ For example, if you set a `memory` request of 256 MiB for a container, and that
 a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use
 more RAM.
 -->
-
 ## 请求和约束  {#requests-and-limits}
 
 如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源
@@ -77,7 +76,6 @@ Limits can be implemented either reactively (the system intervenes once it sees
 or by enforcement (the system prevents the container from ever exceeding the limit). Different
 runtimes can have different ways to implement the same restrictions.
 -->
-
 如果你将某容器的 `memory` 约束设置为 4 GiB，kubelet （和
 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}）
 就会确保该约束生效。
@@ -88,6 +86,19 @@ runtimes can have different ways to implement the same restrictions.
 约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现
 （系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。
 
+{{< note >}}
+<!--
+If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
+automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
+CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
+the limit.
+-->
+如果某 Container 设置了自己的内存限制但未设置内存请求，Kubernetes
+自动为其设置与内存限制相匹配的请求值。类似的，如果某 Container 设置了
+CPU 限制值但未设置 CPU 请求值，则 Kubernetes 自动为其设置 CPU 请求
+并使之与 CPU 限制值匹配。
+{{< /note >}}
+
 <!--
 ## Resource types
 
@@ -110,15 +121,19 @@ CPU 表达的是计算处理能力，其单位是 [Kubernetes CPUs](#meaning-of-
 如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。
 巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。
 
-例如，在默认页面大小为 4KiB 的系统上，您可以指定约束 `hugepages-2Mi: 80Mi`。
+例如，在默认页面大小为 4KiB 的系统上，你可以指定约束 `hugepages-2Mi: 80Mi`。
 如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。
 
-<!--
 {{< note >}}
+<!--
 You cannot overcommit `hugepages-*` resources.
 This is different from the `memory` and `cpu` resources.
+-->
+你不能过量使用 `hugepages- * `资源。
+这与 `memory` 和 `cpu` 资源不同。
 {{< /note >}}
 
+<!--
 CPU and memory are collectively referred to as *compute resources*, or just
 *resources*. Compute
 resources are measurable quantities that can be requested, allocated, and
@@ -127,13 +142,6 @@ consumed. They are distinct from
 [Services](/docs/concepts/services-networking/service/) are objects that can be read and modified
 through the Kubernetes API server.
 -->
-
-
-{{< note >}}
-您不能过量使用 `hugepages- * `资源。
-这与 `memory` 和 `cpu` 资源不同。
-{{< /note >}}
-
 CPU 和内存统称为*计算资源*，或简称为*资源*。
 计算资源的数量是可测量的，可以被请求、被分配、被消耗。
 它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。
@@ -191,8 +199,9 @@ be preferred.
 CPU is always requested as an absolute quantity, never as a relative quantity;
 0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine.
 -->
+## Kubernetes 中的资源单位  {#resource-units-in-kubernetes}
 
-## CPU 的含义 {#meaning-of-cpu}
+### CPU 的含义 {#meaning-of-cpu}
 
 CPU 资源的约束和请求以 *cpu* 为单位。
 
@@ -212,17 +221,17 @@ CPU 总是按绝对数量来请求的，不可以使用相对数量；
 ## Meaning of memory
 
 Limits and requests for `memory` are measured in bytes. You can express memory as
-a plain integer or as a fixed-point integer using one of these suffixes:
+a plain integer or as a fixed-point number using one of these suffixes:
 E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
 Mi, Ki. For example, the following represent roughly the same value:
 -->
 ## 内存的含义  {#meaning-of-memory}
 
-内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点整数形式来表示内存：
+内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点数字形式来表示内存：
 E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。
 例如，以下表达式所代表的是大致相同的值：
 
-```shell
+```
 128974848、129e6、129M、123Mi
 ```
 
@@ -233,7 +242,6 @@ and 64MiB (2<sup>26</sup> bytes) of memory. Each Container has a limit of 0.5
 cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128
 MiB of memory, and a limit of 1 cpu and 256MiB of memory.
 -->
-
 下面是个例子。
 
 以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（2<sup>26</sup> 字节）内存，
@@ -272,6 +280,7 @@ spec:
 
 <!--
 ## How Pods with resource requests are scheduled
+
 When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
 run on. Each node has a maximum capacity for each of the resource types: the
 amount of CPU and memory it can provide for Pods. The scheduler ensures that,
@@ -282,7 +291,6 @@ a Pod on a node if the capacity check fails. This protects against a resource
 shortage on a node when resource usage later increases, for example, during a
 daily peak in request rate.
 -->
-
 ## 带资源请求的 Pod 如何调度
 
 当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。
@@ -300,7 +308,6 @@ to the container runtime.
 
 When using Docker:
 -->
-
 ## 带资源约束的 Pod 如何运行
 
 当 kubelet 启动 Pod 中的 Container 时，它会将 CPU 和内存约束信息传递给容器运行时。
@@ -318,9 +325,7 @@ When using Docker:
   multiplied by 100. The resulting value is the total amount of CPU time that a container can use
   every 100ms. A container cannot use more than its share of CPU time during this interval.
 
-  {{< note >}}
   The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
-  {{</ note >}}
 
 - The `spec.containers[].resources.limits.memory` is converted to an integer, and
   used as the value of the
@@ -337,7 +342,7 @@ When using Docker:
   时间不会超过它被分配的时间。
 
   {{< note >}}
-  默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。
+  默认的配额（Quota）周期为 100 毫秒。CPU 配额的最小精度为 1 毫秒。
   {{</ note >}}
 
 - `spec.containers[].resources.limits.memory` 被转换为整数值，作为 `docker run` 命令中的
@@ -359,7 +364,6 @@ To determine whether a Container cannot be scheduled or is being killed due to
 resource limits, see the
 [Troubleshooting](#troubleshooting) section.
 -->
-
 如果 Container 超过其内存限制，则可能会被终止。如果容器可重新启动，则与所有其他类型的
 运行时失效一样，kubelet 将重新启动容器。
 
@@ -380,7 +384,6 @@ are available in your cluster, then Pod resource usage can be retrieved either
 from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
 directly or from your monitoring tools.
 -->
-
 ## 监控计算和内存资源用量
 
 Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。
@@ -422,11 +425,9 @@ The kubelet also uses this kind of storage to hold
 [node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
 container images, and the writable layers of running containers.
 
-{{< caution >}}
 If a node fails, the data in its ephemeral storage can be lost.  
 Your applications cannot expect any performance SLAs (disk IOPS for example)
 from local ephemeral storage.
-{{< /caution >}}
 
 As a beta feature, Kubernetes lets you track, reserve and limit the amount
 of ephemeral local storage a Pod can consume.
@@ -458,7 +459,6 @@ The kubelet also writes
 [node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
 and treats these similarly to ephemeral local storage.
 -->
-
 ### 本地临时性存储的配置
 
 Kubernetes 有两种方式支持节点上配置本地临时性存储：
@@ -555,7 +555,9 @@ than as local ephemeral storage.
 
 kubelet 能够度量其本地存储的用量。实现度量机制的前提是：
 
-- `LocalStorageCapacityIsolation` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且
+- `LocalStorageCapacityIsolation`
+  [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+  被启用（默认状态），并且
 - 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一
 
 如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。
@@ -573,7 +575,7 @@ You can use _ephemeral-storage_ for managing local ephemeral storage. Each Conta
 * `spec.containers[].resources.requests.ephemeral-storage`
 
 Limits and requests for `ephemeral-storage` are measured in bytes. You can express storage as
-a plain integer or as a fixed-point integer using one of these suffixes:
+a plain integer or as a fixed-point number using one of these suffixes:
 E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
 Mi, Ki. For example, the following represent roughly the same value:
 
@@ -581,21 +583,20 @@ Mi, Ki. For example, the following represent roughly the same value:
 128974848, 129e6, 129M, 123Mi
 ```
 -->
-
 ### 为本地临时性存储设置请求和约束值
 
-你可以使用_ephemeral-storage_来管理本地临时性存储。
+你可以使用 _ephemeral-storage_ 来管理本地临时性存储。
 Pod 中的每个 Container 可以设置以下属性：
 
 * `spec.containers[].resources.limits.ephemeral-storage`
 * `spec.containers[].resources.requests.ephemeral-storage`
 
-`ephemeral-storage` 的请求和约束值是按字节计量的。你可以使用一般整数或者定点整数
+`ephemeral-storage` 的请求和约束值是按字节计量的。你可以使用一般整数或者定点数字
 加上下面的后缀来表达存储量：E、P、T、G、M、K。
 你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。
 例如，下面的表达式所表达的大致是同一个值：
 
-```shell
+```
 128974848, 129e6, 129M, 123Mi
 ```
 
@@ -639,7 +640,7 @@ run on. Each node has a maximum amount of local ephemeral storage it can provide
 The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node.
 -->
 
-### 带 ephemeral-storage 的 Pods 的调度行为
+### 带临时性存储的 Pods 的调度行为
 
 当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。
 每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。
@@ -670,9 +671,7 @@ summing the limits for the containers in that Pod. In this case, if the sum of
 the local ephemeral storage usage from all containers and also the Pod's `emptyDir`
 volumes exceeds the overall Pod storage limit, then the kubelet also marks the Pod
 for eviction.
-
 -->
-
 ### 临时性存储消耗的管理 {#resource-emphemeralstorage-consumption}
 
 如果 kubelet 将本地临时性存储作为资源来管理，则 kubelet 会度量以下各处的存储用量：
@@ -736,7 +735,6 @@ still open, then the inode for the deleted file stays until you close
 that file but the kubelet does not categorize the space as in use.
 {{< /note >}}
 -->
-
 kubelet 支持使用不同方式来度量 Pod 的存储用量：
 
 {{< tabs name="resource-emphemeralstorage-measurement" >}}
@@ -795,7 +793,6 @@ If a file is created and deleted, but has an open file descriptor,
 it continues to consume space. Quota tracking records that space accurately
 whereas directory scans overlook the storage used by deleted files.
 -->
-
 Kubernetes 所使用的项目 ID 始于 `1048576`。
 所使用的 IDs 会注册在 `/etc/projects` 和 `/etc/projid` 文件中。
 如果该范围中的项目 ID 已经在系统中被用于其他目的，则已占用的项目 IDs
@@ -815,7 +812,7 @@ If you want to use project quotas, you should:
   [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
   in the kubelet configuration.
 
-* Ensure that the the root filesystem (or optional runtime filesystem)
+* Ensure that the root filesystem (or optional runtime filesystem)
   has project quotas enabled. All XFS filesystems support project quotas.
   For ext4 filesystems, you need to enable the project quota tracking feature
   while the filesystem is not mounted.
@@ -881,14 +878,13 @@ See [Device
 Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 for how to advertise device plugin managed resources on each node.
 -->
+### 管理扩展资源   {#managing-extended-resources}
 
-### 管理扩展资源
-
-#### 节点级扩展资源
+#### 节点级扩展资源     {#node-level-extended-resources}
 
 节点级扩展资源绑定到节点。
 
-##### 设备插件管理的资源
+##### 设备插件管理的资源   {#device-plugin-managed-resources}
 
 有关如何颁布在各节点上由设备插件所管理的资源，请参阅
 [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
@@ -905,8 +901,7 @@ asynchronously by the kubelet. Note that because the scheduler uses the	node
 delay between patching the node capacity with a new resource and the first Pod
 that requests the resource to be scheduled on that node.
 -->
-
-##### 其他资源
+##### 其他资源   {#other-resources}
 
 为了颁布新的节点级扩展资源，集群操作员可以向 API 服务器提交 `PATCH` HTTP 请求，
 以在集群中节点的 `status.capacity` 中为其配置可用数量。
@@ -943,7 +938,6 @@ in the patch path. The operation path value in JSON-Patch is interpreted as a
 JSON-Pointer. For more details, see
 {{< /note >}}
 -->
-
 {{< note >}}
 在前面的请求中，`~1` 是在 patch 路径中对字符 `/` 的编码。
 JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。
@@ -961,13 +955,13 @@ You can specify the extended resources that are handled by scheduler extenders
 in [scheduler policy
 configuration](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31).
 -->
-
-#### 集群层面的扩展资源
+#### 集群层面的扩展资源   {#cluster-level-extended-resources}
 
 集群层面的扩展资源并不绑定到具体节点。
 它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。
 
-您可以在[调度器策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度器扩展程序处理的扩展资源。
+你可以在[调度器策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)
+中指定由调度器扩展程序处理的扩展资源。
 
 <!--
 **Example:**
@@ -981,7 +975,6 @@ extender.
 - The `ignoredByScheduler` field specifies that the scheduler does not check
      the "example.com/foo" resource in its `PodFitsResources` predicate.
 -->
-
 **示例：**
 
 下面的调度器策略配置标明集群层扩展资源 "example.com/foo" 由调度器扩展程序处理。
@@ -1020,8 +1013,7 @@ The API server restricts quantities of extended resources to whole numbers.
 Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of
 _invalid_ quantities are `0.5` and `1500m`.
 -->
-
-### 使用扩展资源
+### 使用扩展资源  {#consuming-extended-resources}
 
 就像 CPU 和内存一样，用户可以在 Pod 的规约中使用扩展资源。
 调度器负责资源的核算，确保同时分配给 Pod 的资源总量不会超过可用数量。
@@ -1032,7 +1024,6 @@ Extended resources replace Opaque Integer Resources.
 Users can use any domain name prefix other than `kubernetes.io` which is reserved.
 {{< /note >}}
 -->
-
 {{< note >}}
 扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。
 用户可以使用 `kubernetes.io` （保留）以外的任何域名前缀。
@@ -1047,7 +1038,6 @@ Extended resources cannot be overcommitted, so request and limit
 must be equal if both are present in a container spec.
 {{< /note >}}
 -->
-
 要在 Pod 中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits`
 映射中包含资源名称作为键。
 
@@ -1064,7 +1054,6 @@ as long as the resource request cannot be satisfied.
 
 The Pod below requests 2 CPUs and 1 "example.com/foo" (an extended resource).
 -->
-
 仅当所有资源请求（包括 CPU、内存和任何扩展资源）都被满足时，Pod 才能被调度。
 在资源请求无法满足时，Pod 会保持在 `PENDING` 状态。
 
@@ -1098,7 +1087,6 @@ If the scheduler cannot find any node where a Pod can fit, the Pod remains
 unscheduled until a place can be found. An event is produced each time the
 scheduler fails to find a place for the Pod, like this:
 -->
-
 ## 疑难解答
 
 ### 我的 Pod 处于悬决状态且事件信息显示 failedScheduling
@@ -1139,7 +1127,7 @@ You can check node capacities and amounts allocated with the
 - 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是`cpu：1`，
   那么一个请求为 `cpu: 1.1` 的 Pod 永远不会被调度。
 
-您可以使用 `kubectl describe nodes` 命令检查节点容量和已分配的资源数量。 例如：
+你可以使用 `kubectl describe nodes` 命令检查节点容量和已分配的资源数量。 例如：
 
 ```shell
 kubectl describe nodes e2e-test-node-pool-4lw4
@@ -1187,17 +1175,17 @@ The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be conf
 to limit the total amount of resources that can be consumed. If used in conjunction
 with namespaces, it can prevent one team from hogging all the resources.
 -->
-
 在上面的输出中，你可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。
 
-通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。
+通过查看 `Pods` 部分，你将看到哪些 Pod 占用了节点上的资源。
 
 可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。
 [NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
 的 `allocatable` 字段给出了可用于 Pod 的资源量。
 有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。
 
-可以配置 [资源配额](/zh/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。
+可以配置 [资源配额](/zh/docs/concepts/policy/resource-quotas/) 功能特性
+以限制可以使用的资源总量。
 如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。
 
 <!--
@@ -1260,7 +1248,6 @@ Container in the Pod was terminated and restarted five times.
 You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status
 of previously terminated Containers:
 -->
-
 在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。
 
 你可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。
@@ -1296,10 +1283,10 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
 * Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
 -->
 
-* 获取将 [分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
-* 获取将 [分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
+* 获取[分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
+* 获取[分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
 * 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)
 * 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。
 * 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。
-* 阅读 XFS 中关于 [项目配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。
+* 阅读 XFS 中关于[项目配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。
 
diff --git a/content/zh/docs/concepts/configuration/overview.md b/content/zh/docs/concepts/configuration/overview.md
index e3cb9ce89b..77254b4b06 100644
--- a/content/zh/docs/concepts/configuration/overview.md
+++ b/content/zh/docs/concepts/configuration/overview.md
@@ -199,7 +199,7 @@ Deployment 描述了对象的期望状态，并且如果对该规范的更改被
 ## 容器镜像
 
 <!--
-The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image.
+The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull the specified image.
 -->
 [imagePullPolicy](/zh/docs/concepts/containers/images/#updating-images)和镜像标签会影响
 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 何时尝试拉取指定的镜像。
diff --git a/content/zh/docs/concepts/configuration/pod-priority-preemption.md b/content/zh/docs/concepts/configuration/pod-priority-preemption.md
index 885db86cb7..8b601a292a 100644
--- a/content/zh/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/zh/docs/concepts/configuration/pod-priority-preemption.md
@@ -23,8 +23,8 @@ scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
 pending Pod possible.
 -->
 [Pods](/zh/docs/concepts/workloads/pods/pod/) 可以有*优先级（Priority）*。
-优先级体现的是当前 Pod 与其他 Pod 相比的重要成都。如果 Pod 无法被调度，则
-调度器会尝试抢占（逐出）低优先级的 Pod，从而是的悬决的 Pod 可被调度。
+优先级体现的是当前 Pod 与其他 Pod 相比的重要程度。如果 Pod 无法被调度，则
+调度器会尝试抢占（逐出）低优先级的 Pod，从而使得悬决的 Pod 可被调度。
 
 <!-- body -->
 
@@ -61,7 +61,7 @@ To use priority and preemption:
 
 Keep reading for more information about these steps.
 -->
-## 如果使用优先级和抢占
+## 如何使用优先级和抢占
 
 要使用优先级和抢占特性：
 
@@ -377,7 +377,7 @@ the Pods are gone, P can be scheduled on the Node.
 Pod 被创建时会被放入一个队列中等待调度。调度器从队列中选择 Pod，尝试将其调度到某 Node 上。
 如果找不到能够满足 Pod 所设置需求的 Node，就会触发悬决 Pod 的抢占逻辑。
 假定 P 是悬决的 Pod，抢占逻辑会尝试找到一个这样的节点，在该节点上移除一个或者多个
-优先级比 P 低的 Pod 后，P 就可以被调度到丐姐点。如果调度器能够找到这样的节点，
+优先级比 P 低的 Pod 后，P 就可以被调度到该节点。如果调度器能够找到这样的节点，
 该节点上的一个或者多个优先级较低的 Pod 就会被逐出。当被逐出的 Pod 从该节点上
 消失时，P 就可以调度到此节点。
 
@@ -530,7 +530,7 @@ preempted. Here's an example:
 *   Pod P is being considered for Node N.
 *   Pod Q is running on another Node in the same Zone as Node N.
 *   Pod P has Zone-wide anti-affinity with Pod Q (`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`).
+    topology.kubernetes.io/zone`).
 *   There are no other cases of anti-affinity between Pod P and other Pods in
     the Zone.
 *   In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
@@ -540,7 +540,7 @@ preempted. Here's an example:
 * Pod P 正在考虑被调度到节点 N。
 * Pod Q 正运行在节点 N 所处区域（Zone）的另一个节点上。
 * Pod P 设置了区域范畴的与 Pod Q 的反亲和性
-  （`topologyKey: failure-domain.beta.kubernetes.io/zone`）。
+  （`topologyKey: topology.kubernetes.io/zone`）。
 * Pod P 与区域中的其他 Pod 之间都不存在反亲和性关系。
 * 为了将 P 调度到节点 N 上，Pod Q 可以被抢占，但是调度器不会执行跨节点的
   抢占操作。因此，Pod P 会被视为无法调度到节点 N 上执行。
diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md
index 44ab02eae1..66980089df 100644
--- a/content/zh/docs/concepts/configuration/secret.md
+++ b/content/zh/docs/concepts/configuration/secret.md
@@ -166,7 +166,7 @@ kubectl create secret generic dev-db-secret \
 You do not need to escape special characters in passwords from files (`--from-file`).
  -->
 {{< note >}}
-特殊字符（例如 `$`、`*`、`*`、`=` 和 `!`）可能会被你的
+特殊字符（例如 `$`、`\`、`*`、`=` 和 `!`）可能会被你的
 [Shell](https://en.wikipedia.org/wiki/Shell_(computing)) 解析，因此需要转义。
 在大多数 Shell 中，对密码进行转义的最简单方式是使用单引号（`'`）将其扩起来。
 例如，如果您的实际密码是 `S!B\*d$zDsb=` ，则应通过以下方式执行命令：
diff --git a/content/zh/docs/concepts/containers/_index.md b/content/zh/docs/concepts/containers/_index.md
index b4c6dc3821..c627f66f1e 100644
--- a/content/zh/docs/concepts/containers/_index.md
+++ b/content/zh/docs/concepts/containers/_index.md
@@ -1,4 +1,63 @@
 ---
 title: "容器"
-weight: 50
+weight: 40
+description: 打包应用及其运行依赖环境的技术。
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+<!--
+Each container that you run is repeatable; the standardization from having
+dependencies included means that you get the same behavior wherever you
+run it.
+
+Containers decouple applications from underlying host infrastructure.
+This makes deployment easier in different cloud or OS environments.
+-->
+
+每个运行的容器都是可重复的；
+包含依赖环境在内的标准，意味着无论您在哪里运行它，您都会得到相同的行为。
+
+容器将应用程序从底层的主机设施中解耦。
+这使得在不同的云或 OS 环境中部署更加容易。
+
+
+
+
+<!-- body -->
+<!--
+## Container images
+A [container image](/docs/concepts/containers/images/) is a ready-to-run
+software package, containing everything needed to run an application:
+the code and any runtime it requires, application and system libraries,
+and default values for any essential settings.
+
+By design, a container is immutable: you cannot change the code of a
+container that is already running. If you have a containerized application
+and want to make changes, you need to build a new image that includes
+the change, then recreate the container to start from the updated image.
+-->
+
+## 容器镜像 {#container-images}
+[容器镜像](/zh/docs/concepts/containers/images/)是一个随时可以运行的软件包，
+包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。
+
+根据设计，容器是不可变的：你不能更改已经运行的容器的代码。
+如果有一个容器化的应用程序需要修改，则需要构建包含更改的新镜像，然后再基于新构建的镜像重新运行容器。
+
+<!-- ## Container runtimes -->
+## 容器运行时  {#container-runtimes}
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+<!--
+* Read about [container images](/docs/concepts/containers/images/)
+* Read about [Pods](/docs/concepts/workloads/pods/)
+-->
+
+* 进一步阅读[容器镜像](/zh/docs/concepts/containers/images/)
+* 进一步阅读 [Pods](/zh/docs/concepts/workloads/pods/)
+
+
diff --git a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md
index 0408e7650f..07798a09d1 100644
--- a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/zh/docs/concepts/containers/container-lifecycle-hooks.md
@@ -48,11 +48,11 @@ There are two hooks that are exposed to Containers:
 `PostStart`
 
 <!--
-This hook executes immediately after a container is created.
+This hook is executed immediately after a container is created.
 However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
 No parameters are passed to the handler.
 -->
-这个回调在创建容器之后立即执行。
+这个回调在容器被创建之后立即被执行。
 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。
 没有参数传递给处理程序。
 
@@ -61,13 +61,13 @@ No parameters are passed to the handler.
 <!--
 This hook is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention and others. A call to the preStop hook fails if the container is already in terminated or completed state.
 It is blocking, meaning it is synchronous,
-so it must complete before the call to delete the container can be sent.
+so it must complete before the signal to stop the container can be sent.
 No parameters are passed to the handler.
 -->
 在容器因 API 请求或者管理事件（诸如存活态探针失败、资源抢占、资源竞争等）而被终止之前，
 此回调会被调用。
 如果容器已经处于终止或者完成状态，则对 preStop 回调的调用将失败。
-此调用是阻塞的，也是同步调用，因此必须在删除容器的调用之前完成。
+此调用是阻塞的，也是同步调用，因此必须在发出删除容器的信号之前完成。
 没有参数传递给处理程序。
 
 <!--
@@ -102,11 +102,13 @@ Resources consumed by the command are counted against the Container.
 ### Hook handler execution
 
 When a Container lifecycle management hook is called,
-the Kubernetes management system executes the handler in the Container registered for that hook. 
+the Kubernetes management system execute the handler according to the hook action,
+`exec` and `tcpSocket` are executed in the container, and `httpGet` is executed by the kubelet process.
 -->
 ### 回调处理程序执行
 
-当调用容器生命周期管理回调时，Kubernetes 管理系统在注册了回调的容器中执行处理程序。
+当调用容器生命周期管理回调时，Kubernetes 管理系统根据回调动作执行其处理程序，
+`exec` 和 `tcpSocket` 在容器内执行，而 `httpGet` 则由 kubelet 进程执行。
 
 <!--
 Hook handler calls are synchronous within the context of the Pod containing the Container.
@@ -120,15 +122,35 @@ the Container cannot reach a `running` state.
 但是，如果回调运行或挂起的时间太长，则容器无法达到 `running` 状态。
 
 <!--
-The behavior is similar for a `PreStop` hook.
-If the hook hangs during execution,
-the Pod phase stays in a `Terminating` state and is killed after `terminationGracePeriodSeconds` of pod ends.
-If a `PostStart` or `PreStop` hook fails,
+`PreStop` hooks are not executed asynchronously from the signal
+to stop the Container; the hook must complete its execution before
+the signal can be sent.
+If a `PreStop` hook hangs during execution,
+the Pod's phase will be `Terminating` and remain there until the Pod is
+killed after its `terminationGracePeriodSeconds` expires.
+This grace period applies to the total time it takes for both
+the `PreStop` hook to execute and for the Container to stop normally.
+If, for example, `terminationGracePeriodSeconds` is 60, and the hook
+takes 55 seconds to complete, and the Container takes 10 seconds to stop
+normally after receiving the signal, then the Container will be killed
+before it can stop normally, since `terminationGracePeriodSeconds` is
+less than the total time (55+10) it takes for these two things to happen.
+-->
+`PreStop` 回调并不会与停止容器的信号处理程序异步执行；回调必须在
+可以发送信号之前完成执行。
+如果 `PreStop` 回调在执行期间停滞不前，Pod 的阶段会变成 `Terminating`
+并且一致处于该状态，直到其 `terminationGracePeriodSeconds` 耗尽为止，
+这时 Pod 会被杀死。
+这一宽限期是针对 `PreStop` 回调的执行时间及容器正常停止时间的总和而言的。
+例如，如果 `terminationGracePeriodSeconds` 是 60，回调函数花了 55 秒钟
+完成执行，而容器在收到信号之后花了 10 秒钟来正常结束，那么容器会在其
+能够正常结束之前即被杀死，因为 `terminationGracePeriodSeconds` 的值
+小于后面两件事情所花费的总时间（55 + 10）。
+
+<!--
+If either a `PostStart` or `PreStop` hook fails,
 it kills the Container.
 -->
-行为与 `PreStop` 回调的行为类似。
-如果回调在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，
-并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。
 如果 `PostStart` 或 `PreStop` 回调失败，它会杀死容器。
 
 <!--
@@ -147,10 +169,11 @@ which means that a hook may be called multiple times for any given event,
 such as for `PostStart` or `PreStop`.
 It is up to the hook implementation to handle this correctly.
 -->
-### 回调寄送保证
+### 回调递送保证
 
-回调的寄送应该是 *至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，回调可以被调用多次。
-如何正确处理，是回调实现所要考虑的问题。
+回调的递送应该是 *至少一次*，这意味着对于任何给定的事件，
+例如 `PostStart` 或 `PreStop`，回调可以被调用多次。
+如何正确处理被多次调用的情况，是回调实现所要考虑的问题。
 
 <!--
 Generally, only single deliveries are made.
@@ -160,9 +183,9 @@ In some rare cases, however, double delivery may occur.
 For instance, if a kubelet restarts in the middle of sending a hook,
 the hook might be resent after the kubelet comes back up.
 -->
-通常情况下，只会进行单次寄送。
+通常情况下，只会进行单次递送。
 例如，如果 HTTP 回调接收器宕机，无法接收流量，则不会尝试重新发送。
-然而，偶尔也会发生重复寄送的可能。
+然而，偶尔也会发生重复递送的可能。
 例如，如果 kubelet 在发送回调的过程中重新启动，回调可能会在 kubelet 恢复后重新发送。
 
 <!--
diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md
index 946c74ce77..463705f659 100644
--- a/content/zh/docs/concepts/containers/images.md
+++ b/content/zh/docs/concepts/containers/images.md
@@ -81,13 +81,13 @@ Instead, specify a meaningful tag such as `v1.42.0`.
 -->
 {{< caution >}}
 你要避免在生产环境中使用 `latest` 标签，因为这会使得跟踪所运行的镜像版本变得
-非常困难，同时也很难会滚到之前运行良好的版本。
+非常困难，同时也很难回滚到之前运行良好的版本。
 
 正确的做法恰恰相反，你应该指定一个有意义的标签，如 `v1.42.0`。
 {{< /caution >}}
 
 <!--
-## Updating Images
+## Updating images
 
 The default pull policy is `IfNotPresent` which causes the
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
@@ -116,17 +116,18 @@ When `imagePullPolicy` is defined without a specific value, it is also set to `A
 如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。
 
 <!--
-## Multi-architecture Images with Manifests
+## Multi-architecture images with image indexes
 
-As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
+As well as providing binary images, a container registry can also serve a [container image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md). An image index can point to multiple [image manifests](https://github.com/opencontainers/image-spec/blob/master/manifest.md) for architecture-specific versions of a container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
 
 Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
 -->
-## 使用清单（manifest）构建多架构镜像
+## 带镜像索引的多架构镜像  {#multi-architecture-images-with-image-indexes}
 
 除了提供二进制的镜像之外，容器仓库也可以提供
-[容器镜像清单](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。
-清单文件（Manifest）可以为特定于体系结构的镜像版本引用其镜像清单。
+[容器镜像索引](https://github.com/opencontainers/image-spec/blob/master/image-index.md)。
+镜像索引可以根据特定于体系结构版本的容器指向镜像的多个
+[镜像清单](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。
 这背后的理念是让你可以为镜像命名（例如：`pause`、`example/mycontainer`、`kube-apiserver`）
 的同时，允许不同的系统基于它们所使用的机器体系结构取回正确的二进制镜像。
 
@@ -137,7 +138,7 @@ Kubernetes 自身通常在命名容器镜像时添加后缀 `-$(ARCH)`。
 YAML 文件也能兼容。
 
 <!--
-## Using a Private Registry
+## Using a private registry
 
 Private registries may require keys to read images from them.  
 Credentials can be provided in several ways:
@@ -179,7 +180,7 @@ These options are explaind in more detail below.
 下面将详细描述每一项。
 
 <!--
-### Configuring Nodes to authenticate to a Private Registry
+### Configuring nodes to authenticate to a private registry
 
 If you run Docker on your nodes, you can configure the Docker container
 runtime to authenticate to a private container registry.
@@ -333,7 +334,7 @@ registry keys are added to the `.docker/config.json`.
 在 `.docker/config.json` 中配置了私有仓库密钥后，所有 Pod 都将能读取私有仓库中的镜像。
 
 <!--
-### Pre-pulled Images
+### Pre-pulled images
 -->
 ### 提前拉取镜像   {#pre-pulled-images}
 
@@ -371,7 +372,7 @@ All pods will have read access to any pre-pulled images.
 所有的 Pod 都可以使用节点上提前拉取的镜像。
 
 <!--
-### Specifying ImagePullSecrets on a Pod
+### Specifying imagePullSecrets on a Pod
 -->
 ### 在 Pod 上指定 ImagePullSecrets   {#specifying-imagepullsecrets-on-a-pod}
 
@@ -389,7 +390,7 @@ Kubernetes supports specifying container image registry keys on a Pod.
 Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。
 
 <!--
-#### Creating a Secret with a Docker Config
+#### Creating a Secret with a Docker config
 
 Run the following command, substituting the appropriate uppercase values:
 -->
@@ -491,12 +492,12 @@ will be merged.
 来自不同来源的凭据会被合并。
 
 <!--
-### Use Cases
+## Use cases
 
 There are a number of solutions for configuring private registries.  Here are some
 common use cases and suggested solutions.
 -->
-### 使用案例  {#use-cases}
+## 使用案例  {#use-cases}
 
 配置私有仓库有多种方案，以下是一些常用场景和建议的解决方案。
 
diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md
index 4e1178670b..18610346fc 100644
--- a/content/zh/docs/concepts/containers/runtime-class.md
+++ b/content/zh/docs/concepts/containers/runtime-class.md
@@ -313,14 +313,14 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。
 ## {{% heading "whatsnext" %}}
 
 <!--
-- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
-- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
-- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
+- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
+- Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept
 - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
 -->
-- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
-- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
-- 阅读关于 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/) 的概念
+- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
+- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念
 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
 
 
diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md
index ab475eee2d..9721e674cd 100644
--- a/content/zh/docs/concepts/extend-kubernetes/_index.md
+++ b/content/zh/docs/concepts/extend-kubernetes/_index.md
@@ -97,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
 新的集群配置是可复用的，并且可以当作应用程序来管理。
 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
-一种[预定义的支持策略](/docs/reference/using-api/deprecation-policy/)。
+一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。
 
 <!--
@@ -195,12 +195,12 @@ This diagram shows the extension points in a Kubernetes system.
 
 <!--
 1.   Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
-2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
-3.   The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
-4.   The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
+2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section.
+3.   The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](#user-defined-types) section. Custom Resources are often used with API Access Extensions.
+4.   The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section.
 5.   Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
-6.   The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
-7.  The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
+6.   The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](#network-plugins) allow for different implementations of pod networking.
+7.  The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](#storage-plugins).
 
 If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
 -->
@@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
 
 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
 
-关于自定义资源的更多信息，可参见[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
 
 <!--
 ### Combining New APIs with Automation
@@ -289,7 +289,7 @@ API 组中。你不可以替换或更改现有的 API 组。
 <!--
 ### API Access Extensions
 
-When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
 
 Each of these steps offers extension points.
 
@@ -299,7 +299,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
 
 当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作，
 再之后要经过若干类型的准入控制器的检查。
-参见[控制 Kubernetes API 访问](/zh/docs/reference/access-authn-authz/controlling-access/)
+参见[控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)
 以了解此流程的细节。
 
 这些步骤中都存在扩展点。
@@ -319,11 +319,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证    {#authentication}
 
-[身份认证](/docs/reference/access-authn-authz/authentication/)负责将所有请求中
+[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
 的头部或证书映射到发出该请求的客户端的用户名。
 
 Kubernetes 提供若干种内置的认证方法，以及
-[认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
+[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
 方法以备内置方法无法满足你的要求。
 
 <!--
@@ -443,7 +443,7 @@ the nodes chosen for a pod.
 * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
 * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
 -->
-* 进一步了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
 * 进一步了解基础设施扩展
   * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
new file mode 100644
index 0000000000..a893ef8765
--- /dev/null
+++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -0,0 +1,557 @@
+---
+title: 定制资源
+content_type: concept
+weight: 10
+---
+<!--
+title: Custom Resources
+reviewers:
+- enisoc
+- deads2k
+content_type: concept
+weight: 10
+-->
+
+<!-- overview -->
+
+<!--
+*Custom resources* are extensions of the Kubernetes API. This page discusses when to add a custom
+resource to your Kubernetes cluster and when to use a standalone service. It describes the two
+methods for adding custom resources and how to choose between them.
+-->
+*定制资源（Custom Resource）* 是对 Kubernetes API 的扩展。
+本页讨论何时向 Kubernetes 集群添加定制资源，何时使用独立的服务。
+本页描述添加定制资源的两种方法以及怎样在二者之间做出抉择。
+
+<!-- body -->
+
+<!--
+## Custom resources
+
+A *resource* is an endpoint in the
+[Kubernetes API](/docs/concepts/overview/kubernetes-api/) that stores a collection of
+[API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) of
+a certain kind; for example, the built-in *pods* resource contains a
+collection of Pod objects.
+-->
+## 定制资源
+
+*资源（Resource）* 是
+[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 中的一个端点，
+其中存储的是某个类别的
+[API 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+的一个集合。
+例如内置的 *pods* 资源包含一组 Pod 对象。
+
+<!--
+A *custom resource* is an extension of the Kubernetes API that is not necessarily available in a default
+Kubernetes installation. It represents a customization of a particular Kubernetes installation. However,
+many core Kubernetes functions are now built using custom resources, making Kubernetes more modular.
+
+Custom resources can appear and disappear in a running cluster through dynamic registration,
+and cluster admins can update custom resources independently of the cluster itself.
+Once a custom resource is installed, users can create and access its objects using
+[kubectl](/docs/reference/kubectl/overview/), just as they do for built-in resources like
+*Pods*.
+-->
+*定制资源（Custom Resource）* 是对 Kubernetes API 的扩展，不一定在默认的
+Kubernetes 安装中就可用。定制资源所代表的是对特定 Kubernetes 安装的一种定制。
+不过，很多 Kubernetes 核心功能现在都用定制资源来实现，这使得 Kubernetes
+更加模块化。
+
+定制资源可以通过动态注册的方式在运行中的集群内或出现或消失，集群管理员可以独立于集群
+更新定制资源。一旦某定制资源被安装，用户可以使用 
+[kubectl](/zh/docs/reference/kubectl/overview/)
+来创建和访问其中的对象，就像他们为 *pods* 这种内置资源所做的一样。
+
+<!--
+## Custom controllers
+
+On their own, custom resources simply let you store and retrieve structured data.
+When you combine a custom resource with a *custom controller*, custom resources
+provide a true _declarative API_.
+-->
+## 定制控制器   {#custom-controllers}
+
+就定制资源本身而言，它只能用来存取结构化的数据。
+当你将定制资源与 *定制控制器（Custom Controller）* 相结合时，定制资源就能够
+提供真正的 _声明式 API（Declarative API）_。
+
+<!--
+A [declarative API](/docs/concepts/overview/kubernetes-api/)
+allows you to _declare_ or specify the desired state of your resource and tries to
+keep the current state of Kubernetes objects in sync with the desired state.
+The controller interprets the structured data as a record of the user's
+desired state, and continually maintains this state.
+-->
+使用[声明式 API](/zh/docs/concepts/overview/kubernetes-api/)，
+你可以 _声明_ 或者设定你的资源的期望状态，并尝试让 Kubernetes 对象的当前状态
+同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并
+持续地维护该状态。
+
+<!--
+You can deploy and update a custom controller on a running cluster, independently
+of the cluster's lifecycle. Custom controllers can work with any kind of resource,
+but they are especially effective when combined with custom resources. The
+[Operator pattern](https://coreos.com/blog/introducing-operators.html) combines custom
+resources and custom controllers. You can use custom controllers to encode domain knowledge
+for specific applications into an extension of the Kubernetes API.
+-->
+你可以在一个运行中的集群上部署和更新定制控制器，这类操作与集群的生命周期无关。
+定制控制器可以用于任何类别的资源，不过它们与定制资源结合起来时最为有效。
+[Operator 模式](https://coreos.com/blog/introducing-operators.html)就是将定制资源
+与定制控制器相结合的。你可以使用定制控制器来将特定于某应用的领域知识组织
+起来，以编码的形式构造对 Kubernetes API 的扩展。
+
+<!--
+## Should I add a custom resource to my Kubernetes Cluster?
+
+When creating a new API, consider whether to
+[aggregate your API with the Kubernetes cluster APIs](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+or let your API stand alone.
+-->
+## 我是否应该向我的 Kubernetes 集群添加定制资源？
+
+在创建新的 API 时，请考虑是
+[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+还是让你的 API 独立运行。
+
+<!--
+| Consider API aggregation if: | Prefer a stand-alone API if: |
+| ---------------------------- | ---------------------------- |
+| Your API is [Declarative](#declarative-apis). | Your API does not fit the [Declarative](#declarative-apis) model. |
+| You want your new types to be readable and writable using `kubectl`.| `kubectl` support is not required |
+| You want to view your new types in a Kubernetes UI, such as dashboard, alongside built-in types. | Kubernetes UI support is not required. |
+| You are developing a new API. | You already have a program that serves your API and works well. |
+| You are willing to accept the format restriction that Kubernetes puts on REST resource paths, such as API Groups and Namespaces. (See the [API Overview](/docs/concepts/overview/kubernetes-api/).) | You need to have specific REST paths to be compatible with an already defined REST API. |
+| Your resources are naturally scoped to a cluster or namespaces of a cluster. | Cluster or namespace scoped resources are a poor fit; you need control over the specifics of resource paths. |
+| You want to reuse [Kubernetes API support features](#common-features).  | You don't need those features. |
+-->
+| 考虑 API 聚合的情况 | 优选独立 API 的情况 |
+| ---------------------------- | ---------------------------- |
+| 你的 API 是[声明式的](#declarative-apis)。 | 你的 API 不符合[声明式](#declarative-apis)模型。 |
+| 你希望可以是使用 `kubectl` 来读写你的新资源类别。 | 不要求 `kubectl` 支持。 |
+| 你希望在 Kubernetes UI （如仪表板）中和其他内置类别一起查看你的新资源类别。 | 不需要 Kubernetes UI 支持。 |
+| 你在开发新的 API。 | 你已经有一个提供 API 服务的程序并且工作良好。 |
+| 你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 [API 概述](/zh/docs/concepts/overview/kubernetes-api/)） | 你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容。 |
+| 你的资源可以自然地界定为集群作用域或集群中某个名字空间作用域。 | 集群作用域或名字空间作用域这种二分法很不合适；你需要对资源路径的细节进行控制。 |
+| 你希望复用 [Kubernetes API 支持特性](#common-features)。  | 你不需要这类特性。 |
+
+<!--
+### Declarative APIs
+
+In a Declarative API, typically:
+
+ - Your API consists of a relatively small number of relatively small objects (resources).
+ - The objects define configuration of applications or infrastructure.
+ - The objects are updated relatively infrequently.
+ - Humans often need to read and write the objects.
+ - The main operations on the objects are CRUD-y (creating, reading, updating and deleting).
+ - Transactions across objects are not required: the API represents a desired state, not an exact state.
+-->
+### 声明式 APIs {#declarative-apis}
+
+典型地，在声明式 API 中：
+
+ - 你的 API 包含相对而言为数不多的、尺寸较小的对象（资源）。
+ - 对象定义了应用或者基础设施的配置信息。
+ - 对象更新操作频率较低。
+ - 通常需要人来读取或写入对象。
+ - 对象的主要操作是 CRUD 风格的（创建、读取、更新和删除）。
+ - 不需要跨对象的事务支持：API 对象代表的是期望状态而非确切实际状态。
+
+<!--
+Imperative APIs are not declarative.
+Signs that your API might not be declarative include:
+
+ - The client says "do this", and then gets a synchronous response back when it is done.
+ - The client says "do this", and then gets an operation ID back, and has to check a separate Operation object to determine completion of the request.
+ - You talk about Remote Procedure Calls (RPCs).
+ - Directly storing large amounts of data; for example, > a few kB per object, or > 1000s of objects.
+ - High bandwidth access (10s of requests per second sustained) needed.
+ - Store end-user data (such as images, PII, etc.) or other large-scale data processed by applications.
+ - The natural operations on the objects are not CRUD-y.
+ - The API is not easily modeled as objects.
+ - You chose to represent pending operations with an operation ID or an operation object.
+-->
+命令式 API（Imperative API）与声明式有所不同。
+以下迹象表明你的 API 可能不是声明式的：
+
+- 客户端发出“做这个操作”的指令，之后在该操作结束时获得同步响应。
+- 客户端发出“做这个操作”的指令，并获得一个操作 ID，之后需要检查一个 Operation（操作）
+  对象来判断请求是否成功完成。
+- 你会将你的 API 类比为远程过程调用（Remote Procedure Call，RPCs）。
+- 直接存储大量数据；例如每个对象几 kB，或者存储上千个对象。
+- 需要较高的访问带宽（长期保持每秒数十个请求）。
+- 存储有应用来处理的最终用户数据（如图片、个人标识信息（PII）等）或者其他大规模数据。
+- 在对象上执行的常规操作并非 CRUD 风格。
+- API 不太容易用对象来建模。
+- 你决定使用操作 ID 或者操作对象来表现悬决的操作。
+
+<!--
+## Should I use a configMap or a custom resource?
+
+Use a ConfigMap if any of the following apply:
+
+* There is an existing, well-documented config file format, such as a `mysql.cnf` or `pom.xml`.
+* You want to put the entire config file into one key of a configMap.
+* The main use of the config file is for a program running in a Pod on your cluster to consume the file to configure itself.
+* Consumers of the file prefer to consume via file in a Pod or environment variable in a pod, rather than the Kubernetes API.
+* You want to perform rolling updates via Deployment, etc., when the file is updated.
+-->
+## 我应该使用一个 ConfigMap 还是一个定制资源？
+
+如果满足以下条件之一，应该使用 ConfigMap：
+
+* 存在一个已有的、文档完备的配置文件格式约定，例如 `mysql.cnf` 或 `pom.xml`。
+* 你希望将整个配置文件放到某 configMap 中的一个主键下面。
+* 配置文件的主要用途是针对运行在集群中 Pod 内的程序，供后者依据文件数据配置自身行为。
+* 文件的使用者期望以 Pod 内文件或者 Pod 内环境变量的形式来使用文件数据，
+  而不是通过 Kubernetes API。
+* 你希望当文件被更新时通过类似 Deployment 之类的资源完成滚动更新操作。
+
+<!--
+Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
+-->
+{{< note >}}
+请使用 [Secret](/zh/docs/concepts/configuration/secret/) 来保存敏感数据。
+Secret 类似于 configMap，但更为安全。
+{{< /note >}}
+
+<!--
+Use a custom resource (CRD or Aggregated API) if most of the following apply:
+
+* You want to use Kubernetes client libraries and CLIs to create and update the new resource.
+* You want top-level support from `kubectl`; for example, `kubectl get my-object object-name`.
+* You want to build new automation that watches for updates on the new object, and then CRUD other objects, or vice versa.
+* You want to write automation that handles updates to the object.
+* You want to use Kubernetes API conventions like `.spec`, `.status`, and `.metadata`.
+* You want the object to be an abstraction over a collection of controlled resources, or a summarization of other resources.
+-->
+如果以下条件中大多数都被满足，你应该使用定制资源（CRD 或者 聚合 API）：
+
+* 你希望使用 Kubernetes 客户端库和 CLI 来创建和更改新的资源。
+* 你希望 `kubectl` 能够直接支持你的资源；例如，`kubectl get my-object object-name`。
+* 你希望构造新的自动化机制，监测新对象上的更新事件，并对其他对象执行 CRUD
+  操作，或者监测后者更新前者。
+* 你希望编写自动化组件来处理对对象的更新。
+* 你希望使用 Kubernetes API 对诸如 `.spec`、`.status` 和 `.metadata` 等字段的约定。
+* 你希望对象是对一组受控资源的抽象，或者对其他资源的归纳提炼。
+
+<!--
+## Adding custom resources
+
+Kubernetes provides two ways to add custom resources to your cluster:
+
+- CRDs are simple and can be created without any programming.
+- [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.
+-->
+## 添加定制资源   {#adding-custom-resources}
+
+Kubernetes 提供了两种方式供你向集群中添加定制资源：
+
+- CRD 相对简单，创建 CRD 可以不必编程。
+- [API 聚合](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+  需要编程，但支持对 API 行为进行更多的控制，例如数据如何存储以及在不同 API 版本间如何转换等。
+
+<!--
+Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility is compromised.
+
+Aggregated APIs are subordinate API servers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
+
+CRDs allow users to create new types of resources without adding another API server. You do not need to understand API Aggregation to use CRDs.
+
+Regardless of how they are installed, the new resources are referred to as Custom Resources to distinguish them from built-in Kubernetes resources (like pods).
+-->
+Kubernetes 提供这两种选项以满足不同用户的需求，这样就既不会牺牲易用性也不会牺牲灵活性。
+
+聚合 API 指的是一些下位的 API 服务器，运行在主 API 服务器后面；主 API
+服务器以代理的方式工作。这种组织形式称作
+[API 聚合（API Aggregation，AA）](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 。
+对用户而言，看起来仅仅是 Kubernetes API 被扩展了。
+
+CRD 允许用户创建新的资源类别同时又不必添加新的 API 服务器。
+使用 CRD 时，你并不需要理解 API 聚合。
+
+无论以哪种方式安装定制资源，新的资源都会被当做定制资源，以便与内置的
+Kubernetes 资源（如 Pods）相区分。
+
+<!--
+## CustomResourceDefinitions
+
+The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+API resource allows you to define custom resources.
+Defining a CRD object creates a new custom resource with a name and schema that you specify.
+The Kubernetes API serves and handles the storage of your custom resource.
+The name of a CRD object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+## CustomResourceDefinitions
+
+[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+API 资源允许你定义定制资源。
+定义 CRD 对象的操作会使用你所设定的名字和模式定义（Schema）创建一个新的定制资源，
+Kubernetes API 负责为你的定制资源提供存储和访问服务。
+CRD 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+
+<!--
+This frees you from writing your own API server to handle the custom resource,
+but the generic nature of the implementation means you have less flexibility than with
+[API server aggregation](#api-server-aggregation).
+
+Refer to the [custom controller example](https://github.com/kubernetes/sample-controller)
+for an example of how to register a new custom resource, work with instances of your new resource type,
+and use a controller to handle events.
+-->
+CRD 使得你不必编写自己的 API 服务器来处理定制资源，不过其背后实现的通用性也意味着
+你所获得的灵活性要比 [API 服务器聚合](#api-server-aggregation)少很多。
+
+关于如何注册新的定制资源、使用新资源类别的实例以及如何使用控制器来处理事件，
+相关的例子可参见[定制控制器示例](https://github.com/kubernetes/sample-controller)。
+
+<!--
+## API server aggregation
+
+Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also generically handle custom resources through [CRDs](#customresourcedefinitions).
+
+The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows you to provide specialized
+implementations for your custom resources by writing and deploying your own standalone API server.
+The main API server delegates requests to you for the custom resources that you handle,
+making them available to all of its clients.
+-->
+## API 服务器聚合  {#api-server-aggregation}
+
+通常，Kubernetes API 中的每个都需要处理 REST 请求和管理对象持久性存储的代码。
+Kubernetes API 主服务器能够处理诸如 *pods* 和 *services* 这些内置资源，也可以
+按通用的方式通过 CRD {#customresourcedefinitions} 来处理定制资源。
+
+[聚合层（Aggregation Layer）](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+使得你可以通过编写和部署你自己的独立的 API 服务器来为定制资源提供特殊的实现。
+主 API 服务器将针对你要处理的定制资源的请求全部委托给你来处理，同时将这些资源
+提供给其所有客户。
+
+<!--
+## Choosing a method for adding custom resources
+
+CRDs are easier to use. Aggregated APIs are more flexible. Choose the method that best meets your needs.
+
+Typically, CRDs are a good fit if:
+
+* You have a handful of fields
+* You are using the resource within your company, or as part of a small open-source project (as opposed to a commercial product)
+-->
+## 选择添加定制资源的方法
+
+CRD 更为易用；聚合 API 则更为灵活。请选择最符合你的需要的方法。
+
+通常，如何存在以下情况，CRD 可能更合适：
+
+* 定制资源的字段不多；
+* 你在组织内部使用该资源或者在一个小规模的开源项目中使用该资源，而不是
+  在商业产品中使用。
+
+<!--
+### Comparing ease of use
+
+CRDs are easier to create than Aggregated APIs.
+-->
+### 比较易用性  {#compare-ease-of-use}
+
+CRD 比聚合 API 更容易创建
+
+<!--
+| CRDs                        | Aggregated API |
+| --------------------------- | -------------- |
+| Do not require programming. Users can choose any language for a CRD controller. | Requires programming in Go and building binary and image. |
+| No additional service to run; CRDs are handled by API server. | An additional service to create and that could fail. |
+| No ongoing support once the CRD is created. Any bug fixes are picked up as part of normal Kubernetes Master upgrades. | May need to periodically pickup bug fixes from upstream and rebuild and update the Aggregated API server. |
+| No need to handle multiple versions of your API; for example, when you control the client for this resource, you can upgrade it in sync with the API. | You need to handle multiple versions of your API; for example, when developing an extension to share with the world. |
+-->
+| CRDs                        | 聚合 API       |
+| --------------------------- | -------------- |
+| 无需编程。用户可选择任何语言来实现 CRD 控制器。 | 需要使用 Go 来编程，并构建可执行文件和镜像。 |
+| 无需额外运行服务；CRD 由 API 服务器处理。 | 需要额外创建服务，且该服务可能失效。 |
+| 一旦 CRD 被创建，不需要持续提供支持。Kubernetes 主控节点升级过程中自动会带入缺陷修复。 | 可能需要周期性地从上游提取缺陷修复并更新聚合 API 服务器。 |
+| 无需处理 API 的多个版本；例如，当你控制资源的客户端时，你可以更新它使之与 API 同步。 | 你需要处理 API 的多个版本；例如，在开发打算与很多人共享的扩展时。 |
+
+<!--
+### Advanced features and flexibility
+
+Aggregated APIs offer more advanced API features and customization of other features; for example, the storage layer.
+-->
+### 高级特性与灵活性  {#advanced-features-and-flexibility}
+
+聚合 API 可提供更多的高级 API 特性，也可对其他特性实行定制；例如，对存储层进行定制。
+
+<!--
+| 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/extend-kubernetes/custom-resources/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/extend-kubernetes/custom-resources/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/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
+| Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | 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 |
+| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)  | Yes |
+| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | Yes |
+| Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
+| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes |
+| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
+| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
+-->
+| 特性    | 描述        | CRDs | 聚合 API       |
+| ------- | ----------- | ---- | -------------- |
+| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。|
+| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 |
+| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 |
+| 定制存储 | 支持使用具有不同性能模式的存储（例如，要使用时间序列数据库而不是键值存储），或者因安全性原因对存储进行隔离（例如对敏感信息执行加密）。 | 不可以。 | 可以。 |
+| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 |
+| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 |
+| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 |
+| 其他子资源 | 添加 CRUD 之外的操作，例如 "logs" 或 "exec"。 | 不可以。 | 可以。 |
+| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 |
+| 支持协议缓冲区 | 新的资源要支持想要使用协议缓冲区（Protocol Buffer）的客户端。 | 不可以。 | 可以。 |
+| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。|
+
+<!--
+### Common Features
+
+When you create a custom resource, either via a CRD or an AA, you get many features for your API, compared to implementing it outside the Kubernetes platform:
+-->
+### 公共特性  {#common-features}
+
+与在 Kubernetes 平台之外实现定制资源相比，
+无论是通过 CRD 还是通过聚合 API 来创建定制资源，你都会获得很多 API 特性：
+
+<!--
+| Feature  | What it does |
+| -------- | ------------ |
+| CRUD | The new endpoints support CRUD basic operations via HTTP and `kubectl` |
+| Watch | The new endpoints support Kubernetes Watch operations via HTTP |
+| Discovery | Clients like `kubectl` and dashboard automatically offer list, display, and field edit operations on your resources |
+| json-patch | The new endpoints support PATCH with `Content-Type: application/json-patch+json` |
+| merge-patch | The new endpoints support PATCH with `Content-Type: application/merge-patch+json` |
+| HTTPS | The new endpoints uses HTTPS |
+| Built-in Authentication | Access to the extension uses the core API server (aggregation layer) for authentication |
+| Built-in Authorization | Access to the extension can reuse the authorization used by the core API server; for example, RBAC. |
+| Finalizers | Block deletion of extension resources until external cleanup happens. |
+| Admission Webhooks | Set default values and validate extension resources during any create/update/delete operation. |
+| UI/CLI Display | Kubectl, dashboard can display extension resources. |
+| Unset versus Empty | Clients can distinguish unset fields from zero-valued fields. |
+| Client Libraries Generation | Kubernetes provides generic client libraries, as well as tools to generate type-specific client libraries. |
+| Labels and annotations | Common metadata across objects that tools know how to edit for core and custom resources. |
+-->
+| 功能特性 | 具体含义     |
+| -------- | ------------ |
+| CRUD | 新的端点支持通过 HTTP 和 `kubectl` 发起的 CRUD 基本操作 |
+| 监测（Watch） | 新的端点支持通过 HTTP 发起的 Kubernetes Watch 操作 |
+| 发现（Discovery） | 类似 `kubectl` 和仪表盘（Dashboard）这类客户端能够自动提供列举、显示、在字段级编辑你的资源的操作 |
+| json-patch | 新的端点支持带 `Content-Type: application/json-patch+json` 的 PATCH 操作 |
+| merge-patch | 新的端点支持带 `Content-Type: application/merge-patch+json` 的 PATCH 操作 |
+| HTTPS | 新的端点使用 HTTPS |
+| 内置身份认证 | 对扩展的访问会使用核心 API 服务器（聚合层）来执行身份认证操作 |
+| 内置鉴权授权 | 对扩展的访问可以复用核心 API 服务器所使用的鉴权授权机制；例如，RBAC |
+| Finalizers | 在外部清除工作结束之前阻止扩展资源被删除 |
+| 准入 Webhooks | 在创建、更新和删除操作中对扩展资源设置默认值和执行合法性检查 |
+| UI/CLI 展示 | `kubectl` 和仪表盘（Dashboard）可以显示扩展资源 |
+| 区分未设置值和空值 | 客户端能够区分哪些字段是未设置的，哪些字段的值是被显式设置为零值的。  |
+| 生成客户端库 | Kubernetes 提供通用的客户端库，以及用来生成特定类别客户端库的工具 |
+| 标签和注解 | 提供涵盖所有对象的公共元数据结构，且工具知晓如何编辑核心资源和定制资源的这些元数据 |
+
+<!--
+## Preparing to install a custom resource
+
+There are several points to be aware of before adding a custom resource to your cluster.
+-->
+## 准备安装定制资源
+
+在向你的集群添加定制资源之前，有些事情需要搞清楚。
+
+<!--
+### Third party code and new points of failure
+
+While creating a CRD does not automatically add any new points of failure (for example, by causing third party code to run on your API server), packages (for example, Charts) or other installation bundles often include CRDs as well as a Deployment of third-party code that implements the business logic for a new custom resource.
+
+Installing an Aggregated API server always involves running a new Deployment.
+-->
+### 第三方代码和新的失效点的问题
+
+尽管添加新的 CRD 不会自动带来新的失效点（Point of
+Failure），例如导致第三方代码被在 API 服务器上运行，
+类似 Helm Charts 这种软件包或者其他安装包通常在提供 CRD 的同时还包含带有第三方
+代码的 Deployment，负责实现新的定制资源的业务逻辑。
+
+安装聚合 API 服务器时，也总会牵涉到运行一个新的 Deployment。
+
+<!--
+### Storage
+
+Custom resources consume storage space in the same way that ConfigMaps do. Creating too many custom resources may overload your API server's storage space.
+
+Aggregated API servers may use the same storage as the main API server, in which case the same warning applies.
+-->
+### 存储
+
+定制资源和 ConfigMap 一样也会消耗存储空间。创建过多的定制资源可能会导致
+API 服务器上的存储空间超载。
+
+聚合 API 服务器可以使用主 API 服务器的同一存储。如果是这样，你也要注意
+此警告。
+
+<!--
+### Authentication, authorization, and auditing
+
+CRDs always use the same authentication, authorization, and audit logging as the built-in resources of your API server.
+
+If you use RBAC for authorization, most RBAC roles will not grant access to the new resources (except the cluster-admin role or any role created with wildcard rules). You'll need to explicitly grant access to the new resources. CRDs and Aggregated APIs often come bundled with new role definitions for the types they add.
+
+Aggregated API servers may or may not use the same authentication, authorization, and auditing as the primary API server.
+-->
+### 身份认证、鉴权授权以及审计
+
+CRD 通常与 API 服务器上的内置资源一样使用相同的身份认证、鉴权授权
+和审计日志机制。
+
+如果你使用 RBAC 来执行鉴权授权，大多数 RBAC 角色都会授权对新资源的访问
+（除了 cluster-admin 角色以及使用通配符规则创建的其他角色）。
+你要显式地为新资源的访问授权。CRD 和聚合 API 通常在交付时会包含
+针对所添加的类别的新的角色定义。
+
+聚合 API 服务器可能会使用主 API 服务器相同的身份认证、鉴权授权和审计
+机制，也可能不会。
+
+<!--
+## Accessing a custom resource
+
+Kubernetes [client libraries](/docs/reference/using-api/client-libraries/) can be used to access custom resources. Not all client libraries support custom resources. The _Go_ and _Python_ client libraries do.
+
+When you add a custom resource, you can access it using:
+
+- `kubectl`
+- The kubernetes dynamic client.
+- A REST client that you write.
+- A client generated using [Kubernetes client generation tools](https://github.com/kubernetes/code-generator) (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
+-->
+## 访问定制资源
+
+Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用来访问定制资源。
+并非所有客户端库都支持定制资源。_Go_ 和 _Python_ 客户端库是支持的。
+
+当你添加了新的定制资源后，可以用如下方式之一访问它们：
+
+- `kubectl`
+- Kubernetes 动态客户端
+- 你所编写的 REST 客户端
+- 使用 [Kubernetes 客户端生成工具](https://github.com/kubernetes/code-generator)
+  所生成的客户端。生成客户端的工作有些难度，不过某些项目可能会随着 CRD 或
+  聚合 API 一起提供一个客户端
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
+-->
+* 了解如何[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+
diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 5802bb4884..8814bbb160 100644
--- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -19,13 +19,19 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap
 and other similar computing resources that may require vendor specific initialization
 and setup.
 -->
-Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，你可以用来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。
+Kubernetes 提供了一个
+[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，你可以用它来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。
 
-供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。
+供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}}
+来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、
+InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。
 
 <!-- body -->
 
-## 注册设备插件
+<!--
+## Device plugin registration
+-->
+## 注册设备插件    {#device-plugin-registration}
 
 <!--
 The kubelet exports a `Registration` gRPC service:
@@ -45,7 +51,7 @@ During the registration, the device plugin needs to send:
   * The name of its Unix socket.
   * The Device Plugin API version against which it was built.
   * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
-    [extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources)
+    [extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
     as `vendor-domain/resourcetype`.
     (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
 
@@ -54,7 +60,7 @@ list of devices it manages, and the kubelet is then in charge of advertising tho
 resources to the API server as part of the kubelet node status update.
 For example, after a device plugin registers `hardware-vendor.example/foo` with the kubelet
 and reports two healthy devices on a node, the node status is updated
-to advertise that the node has 2 “Foo” devices installed and available.
+to advertise that the node has 2 "Foo" devices installed and available.
 -->
 设备插件可以通过此 gRPC 服务在 kubelet 进行注册。在注册期间，设备插件需要发送下面几样内容：
   
@@ -64,9 +70,12 @@ to advertise that the node has 2 “Foo” devices installed and available.
   [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
   类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）
 
-成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
+成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet
+负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
 
-比如，设备插件在 kubelet 中注册了 `hardware-vendor.example/foo` 并报告了节点上的两个运行状况良好的设备后，节点状态将更新以通告该节点已安装2个 `Foo` 设备并且是可用的。
+比如，设备插件在 kubelet 中注册了 `hardware-vendor.example/foo` 并报告了
+节点上的两个运行状况良好的设备后，节点状态将更新以通告该节点已安装 2 个
+"Foo" 设备并且是可用的。
 
 <!--
 Then, users can request devices in a
@@ -105,9 +114,9 @@ spec:
           hardware-vendor.example/foo: 2
 #
 # 这个 pod 需要两个 hardware-vendor.example/foo 设备
-# 而且只能够调度到满足需求的 node 上
+# 而且只能够调度到满足需求的节点上
 #
-# 如果该节点中有2个以上的设备可用，其余的可供其他 pod 使用
+# 如果该节点中有 2 个以上的设备可用，其余的可供其他 Pod 使用
 ```
 
 <!--
@@ -121,14 +130,16 @@ The general workflow of a device plugin includes the following steps:
 * The plugin starts a gRPC service, with a Unix socket under host path
   `/var/lib/kubelet/device-plugins/`, that implements the following interfaces:
 -->
-
-## 设备插件的实现
+## 设备插件的实现    {#device-plugin-implementation}
 
 设备插件的常规工作流程包括以下几个步骤：
 
-* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。
-* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口：
+* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，
+  以确保设备处于就绪状态。
+* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix 套接字启动
+  一个 gRPC 服务，该服务实现以下接口：
 
+  <!--
   ```gRPC
   service DevicePlugin {
         // ListAndWatch returns a stream of List of Devices
@@ -140,8 +151,58 @@ The general workflow of a device plugin includes the following steps:
         // Plugin can run device specific operations and instruct Kubelet
         // of the steps to make the Device available in the container
         rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
+
+        // GetPreferredAllocation returns a preferred set of devices to allocate
+        // from a list of available ones. The resulting preferred allocation is not
+        // guaranteed to be the allocation ultimately performed by the
+        // devicemanager. It is only designed to help the devicemanager make a more
+        // informed allocation decision when possible.
+        rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
+
+        // PreStartContainer is called, if indicated by Device Plugin during registeration phase,
+        // before each container start. Device plugin can run device specific operations
+        // such as resetting the device before making devices available to the container.
+        rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
   }
   ```
+  -->
+  ```gRPC
+  service DevicePlugin {
+        // ListAndWatch 返回 Device 列表构成的数据流。
+        // 当 Device 状态发生变化或者 Device 消失时，ListAndWatch
+        // 会返回新的列表。
+        rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
+
+        // Allocate 在容器创建期间调用，这样设备插件可以运行一些特定于设备的操作，
+        // 并告诉 kubelet 如何令 Device 可在容器中访问的所需执行的具体步骤
+        rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
+
+        // GetPreferredAllocation 从一组可用的设备中返回一些优选的设备用来分配，
+        // 所返回的优选分配结果不一定会是设备管理器的最终分配方案。
+        // 此接口的设计仅是为了让设备管理器能够在可能的情况下做出更有意义的决定。
+        rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
+
+        // PreStartContainer 在设备插件注册阶段根据需要被调用，调用发生在容器启动之前。
+        // 在将设备提供给容器使用之前，设备插件可以运行一些诸如重置设备之类的特定于
+        // 具体设备的操作，
+        rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
+  }
+  ```
+
+  {{< note >}}
+  <!--
+  Plugins are not required to provide useful implementations for
+  `GetPreferredAllocation()` or `PreStartContainer()`. Flags indicating which
+  (if any) of these calls are available should be set in the `DevicePluginOptions`
+  message sent back by a call to `GetDevicePluginOptions()`. The `kubelet` will
+  always call `GetDevicePluginOptions()` to see which optional functions are
+  available, before calling any of them directly.
+  -->
+  插件并非必须为 `GetPreferredAllocation()` 或 `PreStartContainer()` 提供有用
+  的实现逻辑，调用 `GetDevicePluginOptions()` 时所返回的 `DevicePluginOptions`
+  消息中应该设置这些调用是否可用。`kubelet` 在真正调用这些函数之前，总会调用
+  `GetDevicePluginOptions()` 来查看是否存在这些可选的函数。
+  {{< /note >}}
 
 <!--
 * The plugin registers itself with the kubelet through the Unix socket at host
@@ -155,7 +216,8 @@ If the operations succeed, the device plugin returns an `AllocateResponse` that
 runtime configurations for accessing the allocated devices. The kubelet passes this information
 to the container runtime.
 -->
-* 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 处向 kubelet 注册自身。
+* 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock`
+  处向 kubelet 注册自身。
 * 成功注册自身后，设备插件将以服务模式运行，在此期间，它将持续监控设备运行状况，
   并在设备状态发生任何变化时向 kubelet 报告。它还负责响应 `Allocate` gRPC 请求。
   在 `Allocate` 期间，设备插件可能还会做一些设备特定的准备；例如 GPU 清理或 QRNG 初始化。
@@ -174,8 +236,8 @@ of its Unix socket and re-register itself upon such an event.
 
 设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。
 在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins`
-下所有已经存在的 Unix sockets。
-设备插件需要能够监控到它的 Unix socket 被删除，并且当发生此类事件时重新注册自己。
+下所有已经存在的 Unix 套接字。
+设备插件需要能够监控到它的 Unix 套接字被删除，并且当发生此类事件时重新注册自己。
 
 <!--
 ## Device plugin deployment
@@ -197,10 +259,11 @@ Pod onto Nodes, to restart the daemon Pod after failure, and to help automate up
 
 你可以将你的设备插件作为节点操作系统的软件包来部署、作为 DaemonSet 来部署或者手动部署。
 
-规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件必须要在被授权的安全的上下文中运行。
+规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件
+必须要在被授权的安全的上下文中运行。
 如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的
 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
-中声明作为 {{< glossary_tooltip term_id="volume" >}} 被 mount 到插件中。
+中声明作为 {{< glossary_tooltip term_id="volume" >}} 被挂载到插件中。
 
 如果你选择 DaemonSet 方法，你可以通过 Kubernetes 进行以下操作：
 将设备插件的 Pod 放置在节点上，在出现故障后重新启动守护进程 Pod，来进行自动升级。
@@ -296,11 +359,12 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接
 
 {{< 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.
+
+The Topology Manager is a Kubelet component that allows resources to be co-ordinated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
 -->
 ## 设备插件与拓扑管理器的集成
 
-{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。
 为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。
diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index 7ad8153077..dd19252f01 100644
--- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -12,31 +12,28 @@ weight: 10
 
 <!-- overview -->
 
-{{< feature-state state="alpha" >}}
-<!--
-{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
--->
-{{< caution >}}Alpha 特性可能很快会变化。{{< /caution >}}
-
 <!--
 Network plugins in Kubernetes come in a few flavors:
 
-* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
+* CNI plugins: adhere to the [Container Network Interface](https://github.com/containernetworking/cni) (CNI) specification, designed for interoperability.
+  * Kubernetes follows the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) release of the CNI specification.
 * Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
 -->
 Kubernetes中的网络插件有几种类型：
 
-* CNI 插件： 遵守 appc/CNI 规约，为互操作性设计。
+* CNI 插件：遵守[容器网络接口（Container Network Interface，CNI）](https://github.com/containernetworking/cni)
+  规范，其设计上偏重互操作性。
+  * Kubernetes 遵从 CNI 规范的
+    [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md)
+    版本。
 * Kubenet 插件：使用 `bridge` 和 `host-local` CNI 插件实现了基本的 `cbr0`。
 
-
-
 <!-- body -->
 
 <!--
 ## Installation
 
-The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
+The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as CRI manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
 
 * `cni-bin-dir`: Kubelet probes this directory for plugins on startup
 * `network-plugin`: The network plugin to use from `cni-bin-dir`.  It must match the name reported by a plugin probed from the plugin directory.  For CNI plugins, this is simply "cni".
@@ -44,11 +41,14 @@ The kubelet has a single default network plugin, and a default network common to
 ## 安装
 
 kubelet 有一个单独的默认网络插件，以及一个对整个集群通用的默认网络。
-它在启动时探测插件，记住找到的内容，并在 pod 生命周期的适当时间执行所选插件（这仅适用于 Docker，因为 rkt 管理自己的 CNI 插件）。
-在使用插件时，需要记住两个 Kubelet 命令行参数：
+它在启动时探测插件，记住找到的内容，并在 Pod 生命周期的适当时间执行
+所选插件（这仅适用于 Docker，因为 CRI 管理自己的 CNI 插件）。
+在使用插件时，需要记住两个 kubelet 命令行参数：
 
-* `cni-bin-dir`： Kubelet 在启动时探测这个目录中的插件
-* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。它必须与从插件目录探测到的插件报告的名称匹配。对于 CNI 插件，其值为 "cni"。
+* `cni-bin-dir`： kubelet 在启动时探测这个目录中的插件
+* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。
+  它必须与从插件目录探测到的插件报告的名称匹配。
+  对于 CNI 插件，其值为 "cni"。
 
 <!--
 ## Network Plugin Requirements
@@ -59,12 +59,18 @@ By default if no kubelet network plugin is specified, the `noop` plugin is used,
 -->
 ## 网络插件要求
 
-除了提供[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)来配置和清理 pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。
+除了提供
+[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)
+来配置和清理 Pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。
 iptables 代理显然依赖于 iptables，插件可能需要确保 iptables 能够监控容器的网络通信。
-例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables` 系统参数设置为`1`，以确保 iptables 代理正常工作。
-如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制），它应该确保为代理对容器通信执行正确的路由。
+例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables`
+系统参数设置为`1`，以确保 iptables 代理正常工作。
+如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制），
+它应该确保为代理对容器通信执行正确的路由。
 
-默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件，该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置（如带网桥的 Docker ）与 iptables 代理正常工作。
+默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件，
+该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置
+（如带网桥的 Docker ）与 iptables 代理正常工作。
 
 <!--
 ### CNI
@@ -77,13 +83,20 @@ In addition to the CNI plugin specified by the configuration file, Kubernetes re
 -->
 ### CNI
 
-通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项来选择 CNI 插件。
-Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用该文件中的 CNI 配置来设置每个 pod 的网络。
-CNI 配置文件必须与 [CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)匹配，并且配置引用的任何所需的 CNI 插件都必须存在于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）。
+通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项可以选择 CNI 插件。
+Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用
+该文件中的 CNI 配置来设置各个 Pod 的网络。
+CNI 配置文件必须与
+[CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
+匹配，并且配置所引用的所有所需的 CNI 插件都应存在于
+`--cni-bin-dir`（默认是 `/opt/cni/bin`）下。
 
-如果这个目录中有多个 CNI 配置文件，kubelet 将会使用按文件名的字典顺序排列的第一个作为配置文件。
+如果这个目录中有多个 CNI 配置文件，kubelet 将会使用按文件名的字典顺序排列
+的第一个作为配置文件。
 
-除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 插件，最低版本是0.2.0。
+除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI
+[`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)
+插件，最低版本是0.2.0。
 
 <!--
 #### Support hostPort
@@ -96,8 +109,9 @@ For example:
 -->
 #### 支持 hostPort
 
-CNI 网络插件支持 `hostPort`。 您可以使用官方 [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
-插件，它由 CNI 插件团队提供，或者使用您自己的带有 portMapping 功能的插件。
+CNI 网络插件支持 `hostPort`。 你可以使用官方
+[portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
+插件，它由 CNI 插件团队提供，或者使用你自己的带有 portMapping 功能的插件。
 
 如果你想要启动 `hostPort` 支持，则必须在 `cni-conf-dir` 指定 `portMappings capability`。
 例如：
@@ -147,11 +161,13 @@ If you want to enable traffic shaping support, you must add the `bandwidth` plug
 **实验功能**
 
 CNI 网络插件还支持 pod 入口和出口流量整形。
-您可以使用 CNI 插件团队提供的 [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 插件，
-也可以使用您自己的具有带宽控制功能的插件。
+你可以使用 CNI 插件团队提供的
+[bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
+插件，也可以使用你自己的具有带宽控制功能的插件。
 
-如果您想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件
-（默认是 `/etc/cni/net.d`）并保证该可执行文件包含在您的 CNI 的 bin 文件夹内 (默认为 `/opt/cni/bin`)。
+如果你想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件
+（默认是 `/etc/cni/net.d`）并保证该可执行文件包含在你的 CNI 的 bin
+文件夹内 (默认为 `/opt/cni/bin`)。
 
 ```json
 {
@@ -185,8 +201,8 @@ CNI 网络插件还支持 pod 入口和出口流量整形。
 Now you can add the `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth` annotations to your pod.
 For example:
 -->
-现在，您可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth` 注解添加到 pod 中。
-例如：
+现在，你可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth`
+注解添加到 pod 中。例如：
 
 ```yaml
 apiVersion: v1
@@ -210,7 +226,7 @@ The plugin requires a few things:
 * The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `cni-bin-dir` to supply additional search path. The first found match will take effect.
 * Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin
 * Kubelet should also be run with the `--non-masquerade-cidr=<clusterCidr>` argument to ensure traffic to IPs outside this range will use IP masquerade.
-* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=<cidr>` controller-manager command-line options.
+* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true -cluster-cidr=<cidr>` controller-manager command-line options.
 -->
 ### kubenet
 
@@ -218,16 +234,23 @@ Kubenet 是一个非常基本的、简单的网络插件，仅适用于 Linux。
 它本身并不实现更高级的功能，如跨节点网络或网络策略。
 它通常与云驱动一起使用，云驱动为节点间或单节点环境中的通信设置路由规则。
 
-Kubenet 创建名为 `cbr0` 的网桥，并为每个 pod 创建了一个 veth 对，每个 pod 的主机端都连接到 `cbr0`。
-这个 veth 对的 pod 端会被分配一个 IP 地址，该 IP 地址隶属于节点所被分配的 IP 地址范围内。节点的 IP 地址范围则通过配置或控制器管理器来设置。
+Kubenet 创建名为 `cbr0` 的网桥，并为每个 pod 创建了一个 veth 对，
+每个 Pod 的主机端都连接到 `cbr0`。
+这个 veth 对的 Pod 端会被分配一个 IP 地址，该 IP 地址隶属于节点所被分配的 IP
+地址范围内。节点的 IP 地址范围则通过配置或控制器管理器来设置。
 `cbr0` 被分配一个 MTU，该 MTU 匹配主机上已启用的正常接口的最小 MTU。
 
 使用此插件还需要一些其他条件：
 
-* 需要标准的 CNI `bridge`、`lo` 以及 `host-local` 插件，最低版本是0.2.0。Kubenet 首先在 `/opt/cni/bin` 中搜索它们。 指定 `cni-bin-dir` 以提供其它的搜索路径。首次找到的匹配将生效。
+* 需要标准的 CNI `bridge`、`lo` 以及 `host-local` 插件，最低版本是0.2.0。
+  kubenet 首先在 `/opt/cni/bin` 中搜索它们。 指定 `cni-bin-dir` 以提供
+  其它搜索路径。首次找到的匹配将生效。
 * Kubelet 必须和 `--network-plugin=kubenet` 参数一起运行，才能启用该插件。
-* Kubelet 还应该和 `--non-masquerade-cidr=<clusterCidr>` 参数一起运行，以确保超出此范围的 IP 流量将使用 IP 伪装。
-* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=<cidr>` 来设置。
+* Kubelet 还应该和 `--non-masquerade-cidr=<clusterCidr>` 参数一起运行，
+  以确保超出此范围的 IP 流量将使用 IP 伪装。
+* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或
+  控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=<cidr>`
+  来设置。
 
 <!--
 ### Customizing the MTU (with kubenet)
@@ -249,11 +272,11 @@ This option is provided to the network-plugin; currently **only kubenet supports
 要获得最佳的网络性能，必须确保 MTU 的取值配置正确。
 网络插件通常会尝试推断出一个合理的 MTU，但有时候这个逻辑不会产生一个最优的 MTU。
 例如，如果 Docker 网桥或其他接口有一个小的 MTU, kubenet 当前将选择该 MTU。
-或者如果您正在使用 IPSEC 封装，则必须减少 MTU，并且这种计算超出了大多数网络插件的能力范围。
+或者如果你正在使用 IPSEC 封装，则必须减少 MTU，并且这种计算超出了大多数网络插件的能力范围。
 
-如果需要，您可以使用 `network-plugin-mtu` kubelet 选项显式的指定 MTU。
-例如：在 AWS 上 `eth0` MTU 通常是 9001，因此您可以指定 `--network-plugin-mtu=9001`。
-如果您正在使用 IPSEC ，您可以减少它以允许封装开销，例如 `--network-plugin-mtu=8873`。
+如果需要，你可以使用 `network-plugin-mtu` kubelet 选项显式的指定 MTU。
+例如：在 AWS 上 `eth0` MTU 通常是 9001，因此你可以指定 `--network-plugin-mtu=9001`。
+如果你正在使用 IPSEC ，你可以减少它以允许封装开销，例如 `--network-plugin-mtu=8873`。
 
 此选项会传递给网络插件； 当前 **仅 kubenet 支持 `network-plugin-mtu`**。
 
@@ -264,14 +287,15 @@ This option is provided to the network-plugin; currently **only kubenet supports
 * `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
 * `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
 -->
-## 使用总结
+## 用法总结
 
-* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于 `--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。
-* `--network-plugin=kubenet` 用来表明我们要使用 `kubenet` 网络插件，CNI `bridge` 和 `host-local` 插件位于 `/opt/cni/bin` 或 `cni-bin-dir` 中。
+* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件
+  可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于
+  `--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。
+* `--network-plugin=kubenet` 用来表明我们要使用 `kubenet` 网络插件，CNI `bridge`
+  和 `host-local` 插件位于 `/opt/cni/bin` 或 `cni-bin-dir` 中。
 * `--network-plugin-mtu=9001` 指定了我们使用的 MTU，当前仅被 `kubenet` 网络插件使用。
 
-
-
 ## {{% heading "whatsnext" %}}
 
 
diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
index cb1ace4a9c..68b52333db 100644
--- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -4,7 +4,6 @@ content_type: concept
 weight: 10
 ---
 <!--
----
 title: Extending your Kubernetes Cluster
 reviewers:
 - erictune
@@ -13,7 +12,6 @@ reviewers:
 - chenopis
 content_type: concept
 weight: 10
----
 -->
 
 <!-- overview -->
@@ -89,7 +87,7 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
 它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，
 并以与应用程序相同的方式进行管理。
 而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的
-[支持政策](/docs/reference/using-api/deprecation-policy/)。
+[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
 出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。
 
 <!--
@@ -238,12 +236,13 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
 
 ### 用户自定义类型  {#user-defined-types}
 
-如果你想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes 工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。
+如果你想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes
+工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。
 
 不要使用自定义资源作为应用、用户或者监控数据的数据存储。
 
 有关自定义资源的更多信息，请查看
-[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
 
 <!--
 ### Combining New APIs with Automation
@@ -272,7 +271,7 @@ Adding an API does not directly let you affect the behavior of existing APIs (e.
 <!--
 ### API Access Extensions
 
-When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
 
 Each of these steps offers extension points.
 
@@ -282,13 +281,13 @@ Kubernetes has several built-in authentication methods that it supports. It can
 
 当请求到达 Kubernetes API Server 时，它首先被要求进行用户认证，然后要进行授权检查，
 接着受到各种类型的准入控制的检查。有关此流程的更多信息，请参阅
-[Kubernetes API 访问控制](/zh/docs/reference/access-authn-authz/controlling-access/)。
+[Kubernetes API 访问控制](/zh/docs/concepts/security/controlling-access/)。
 
 上述每个步骤都提供了扩展点。
 
 Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部
 中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在
-[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。
+[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
 
 <!--
 ### Authentication
@@ -299,11 +298,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 -->
 ### 身份认证  {#authentication}
 
-[身份认证](/docs/reference/access-authn-authz/authentication/)
+[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
 将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。
 
 Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用
-[身份认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
+[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
 
 <!--
 ### Authorization
diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md
index f3777c6b2c..af62e4c767 100644
--- a/content/zh/docs/concepts/extend-kubernetes/operator.md
+++ b/content/zh/docs/concepts/extend-kubernetes/operator.md
@@ -16,12 +16,13 @@ weight: 30
 Operators are software extensions to Kubernetes that make use of [custom
 resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 to manage applications and their components. Operators follow
-Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
+Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/).
 -->
 
 Operator 是 Kubernetes 的扩展软件，它利用
 [自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
-Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。
+Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/architecture/controller/)
+方面。
 
 
 <!-- body -->
@@ -43,7 +44,8 @@ code to automate a task beyond what Kubernetes itself provides.
 Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。
 负责特定应用和 service 的运维人员，在系统应该如何运行、如何部署以及出现问题时如何处理等方面有深入的了解。
 
-在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。Operator 模式会封装您编写的（Kubernetes 本身提供功能以外的）任务自动化代码。
+在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。
+Operator 模式会封装你编写的（Kubernetes 本身提供功能以外的）任务自动化代码。
 
 <!--
 ## Operators in Kubernetes
@@ -57,14 +59,15 @@ Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
 concept lets you extend the cluster's behaviour without modifying the code
 of Kubernetes itself.
 Operators are clients of the Kubernetes API that act as controllers for
-a [Custom Resource](/docs/concepts/api-extension/custom-resources/).
+a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 -->
 ## Kubernetes 上的 Operator
 
-Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes 核心中获得许多内置的自动化功能。
-您可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。
+Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。
+你可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。
 
-Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
+Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 
+使你无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
 Operator 是 Kubernetes API 的客户端，充当
 [自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
 
@@ -123,15 +126,21 @@ detail:
 
 想要更详细的了解 Operator？这儿有一个详细的示例：
 
-1. 有一个名为 SampleDB 的自定义资源，您可以将其配置到集群中。
+1. 有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。
 2. 一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
 3. Operator 代码的容器镜像。
 4. 控制器代码，负责查询控制平面以找出已配置的 SampleDB 资源。
 5. Operator 的核心是告诉 API 服务器，如何使现实与代码里配置的资源匹配。
-   * 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job 来处理初始配置。
-   * 如果您删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
-6. Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator 会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于 ConfigMap 和/或 具有数据库连接详细信息和凭据的 Secret。
-7. 由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，如果是，则创建 Job 对象为您升级数据库。
+   * 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供
+     持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job
+     来处理初始配置。
+   * 如果你删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
+6. Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator
+   会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于
+   ConfigMap 和/或具有数据库连接详细信息和凭据的 Secret。
+7. 由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些
+   额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，
+   如果是，则创建 Job 对象为你升级数据库。
 
 <!--
 ## Deploying Operators
@@ -145,7 +154,10 @@ For example, you can run the controller in your cluster as a Deployment.
 -->
 ## 部署 Operator
 
-部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到您的集群中。跟运行容器化应用一样，Controller 通常会运行在 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。例如，您可以在集群中将控制器作为 Deployment 运行。
+部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到你的集群中。
+跟运行容器化应用一样，控制器通常会运行在
+{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。
+例如，你可以在集群中将控制器作为 Deployment 运行。
 
 <!--
 ## Using an Operator {#using-operators}
@@ -160,10 +172,10 @@ kubectl get SampleDB                   # find configured databases
 kubectl edit SampleDB/example-database # manually change some settings
 ```
 -->
-
 ## 使用 Operator {#using-operators}
 
-部署 Operator 后，您可以对 Operator 所使用的资源执行添加、修改或删除操作。按照上面的示例，您将为 Operator 本身建立一个 Deployment，然后：
+部署 Operator 后，你可以对 Operator 所使用的资源执行添加、修改或删除操作。
+按照上面的示例，你将为 Operator 本身建立一个 Deployment，然后：
 
 ```shell
 kubectl get SampleDB                   # 查找所配置的数据库
@@ -176,8 +188,7 @@ kubectl edit SampleDB/example-database # 手动修改某些配置
 
 ## Writing your own Operator {#writing-operator}
 -->
-
-可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态
+可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态。
 
 ## 编写你自己的 Operator {#writing-operator}
 
@@ -191,9 +202,11 @@ You also implement an Operator (that is, a Controller) using any language / runt
 that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
 -->
 
-如果生态系统中没可以实现您目标的 Operator，您可以自己编写代码。在[接下来](#what-s-next)一节中，您会找到编写自己的云原生 Operator 需要的库和工具的链接。
+如果生态系统中没可以实现你目标的 Operator，你可以自己编写代码。在
+[接下来](#what-s-next)一节中，你会找到编写自己的云原生 Operator
+需要的库和工具的链接。
 
-您还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/)
+你还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/)
 的语言或运行时来实现 Operator（即控制器）。
 
 ## {{% heading "whatsnext" %}}
@@ -206,20 +219,20 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
   * using [kubebuilder](https://book.kubebuilder.io/)
   * using [Metacontroller](https://metacontroller.app/) along with WebHooks that
     you implement yourself
-  * using the [Operator Framework](https://github.com/operator-framework/getting-started)
+  * using the [Operator Framework](https://operatorframework.io)
 * [Publish](https://operatorhub.io/) your operator for other people to use
 * Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
 * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
 -->
 
 * 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
-* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
-* 借助已有的工具来编写您自己的 Operator，例如：
+* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator
+* 借助已有的工具来编写你自己的 Operator，例如：
   * [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
   * [kubebuilder](https://book.kubebuilder.io/)
   * [Metacontroller](https://metacontroller.app/)，可与 Webhook 结合使用，以实现自己的功能。
-  * [Operator 框架](https://github.com/operator-framework/getting-started)
-* [发布](https://operatorhub.io/)您的 Operator，让别人也可以使用
+  * [Operator Framework](https://operatorframework.io)
+* [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用
 * 阅读 [CoreOS 原文](https://coreos.com/blog/introducing-operators.html)，其介绍了 Operator 介绍
 * 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的
   [文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
diff --git a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md
index 29b12f6bea..aa38076e44 100644
--- a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md
@@ -435,7 +435,7 @@ The following example describes how to map secret values into application enviro
 <!--
 * If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
 * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
+* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
 * View [svc-cat.io](https://svc-cat.io/docs/).
 -->
 * 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}，
@@ -443,7 +443,7 @@ The following example describes how to map secret values into application enviro
   到 Kubernetes 集群中。或者，你可以
   [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。
 * 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
-* 浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目
+* 浏览 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目
 * 查看 [svc-cat.io](https://svc-cat.io/docs/)
 
 
diff --git a/content/zh/docs/concepts/overview/_index.md b/content/zh/docs/concepts/overview/_index.md
index 932a448363..8c8aff7531 100644
--- a/content/zh/docs/concepts/overview/_index.md
+++ b/content/zh/docs/concepts/overview/_index.md
@@ -1,4 +1,7 @@
 ---
 title: 概述
 weight: 20
+description: 获得 Kubernetes 及其构件的高层次概要。
+sitemap:
+  priority: 0.9
 ---
diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md
index 7f9ef72b72..2a862f781a 100644
--- a/content/zh/docs/concepts/overview/components.md
+++ b/content/zh/docs/concepts/overview/components.md
@@ -24,14 +24,14 @@ card:
 
 <!--
 When you deploy Kubernetes, you get a cluster.
-{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
+{{</* glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of" */>}}
 
 This document outlines the various components you need to have
 a complete and working Kubernetes cluster.
 
 Here's the diagram of a Kubernetes cluster with all the components tied together.
 
-![Components of Kubernetes](/images/docs/components-of-kubernetes.png)
+![Components of Kubernetes](/images/docs/components-of-kubernetes.svg)
 -->
 <!-- overview -->
 当你部署完 Kubernetes, 即拥有了一个完整的集群。
@@ -41,22 +41,22 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
 
 这张图表展示了包含所有相互关联组件的 Kubernetes 集群。
 
-![Kubernetes 组件](/images/docs/components-of-kubernetes.png)
+![Kubernetes 组件](/images/docs/components-of-kubernetes.svg)
 
 <!-- body -->
 
 <!--
 ## Control Plane Components
 
-The Control Plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
+The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
  -->
 ## 控制平面组件（Control Plane Components）    {#control-plane-components}
 
 控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 `replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。
 
 <!--
-Control Plane components can be run on any machine in the cluster. However,
-for simplicity, set up scripts typically start all Control Plane components on
+Control plane components can be run on any machine in the cluster. However,
+for simplicity, set up scripts typically start all control plane components on
 the same machine, and do not run user containers on this machine. See
 [Building High-Availability Clusters](/docs/admin/high-availability/) for an example multi-master-VM setup.
  -->
@@ -84,11 +84,11 @@ the same machine, and do not run user containers on this machine. See
 <!--
 These controllers include:
 
-  * Node Controller: Responsible for noticing and responding when nodes go down.
-  * Replication Controller: Responsible for maintaining the correct number of pods for every replication
+  * Node controller: Responsible for noticing and responding when nodes go down.
+  * Replication controller: Responsible for maintaining the correct number of pods for every replication
   controller object in the system.
-  * Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
-  * Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
+  * Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
+  * Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
 -->
 这些控制器包括:
 
@@ -118,9 +118,9 @@ The following controllers can have cloud provider dependencies:
 
 {{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
 
-`cloud-controller-manager` 进运行特定于云平台的控制回路。
+`cloud-controller-manager` 仅运行特定于云平台的控制回路。
 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，
-所部属的环境中不需要云控制器管理器。
+所部署的环境中不需要云控制器管理器。
 
 与 `kube-controller-manager` 类似，`cloud-controller-manager` 将若干逻辑上独立的
 控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。
@@ -203,8 +203,7 @@ Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列
 -->
 ### Web 界面（仪表盘）   
 
-[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是K
-ubernetes 集群的通用的、基于 Web 的用户界面。
+[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是Kubernetes 集群的通用的、基于 Web 的用户界面。
 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
 
 <!--
@@ -221,7 +220,7 @@ about containers in a central database, and provides a UI for browsing that data
 <!--
 ### Cluster-level Logging
 
-A [Cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
+A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
 saving container logs to a central log store with search/browsing interface.
 -->
 ### 集群层面日志
@@ -234,7 +233,7 @@ saving container logs to a central log store with search/browsing interface.
 <!--
 * Learn about [Nodes](/docs/concepts/architecture/nodes/)
 * Learn about [Controllers](/docs/concepts/architecture/controller/)
-* Learn about [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
+* Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
 * Read etcd's official [documentation](https://etcd.io/docs/)
 -->
 * 进一步了解[节点](/zh/docs/concepts/architecture/nodes/)
diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md
index 6188d8f1f3..d44504680e 100644
--- a/content/zh/docs/concepts/overview/kubernetes-api.md
+++ b/content/zh/docs/concepts/overview/kubernetes-api.md
@@ -3,7 +3,9 @@ title: Kubernetes API
 content_type: concept
 weight: 30
 description: >
-  Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。
+  Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。
+  Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。
+  用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。
 card:
   name: concepts
   weight: 30
@@ -14,13 +16,17 @@ card:
 <!--
 The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
 is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server
-exposes an HTTP API that lets end users, different parts of your cluster, and external components
-communicate with one another.
+exposes an HTTP API that lets end users, different parts of your cluster, and
+external components communicate with one another.
 
 The Kubernetes API lets you query and manipulate the state of objects in the Kubernetes API
 (for example: Pods, Namespaces, ConfigMaps, and Events).
 
-API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
+Most operations can be performed through the
+[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
+command-line tools, such as
+[kubeadm](/docs/reference/setup-tools/kubeadm/), which in turn use the
+API. However, you can also access the API directly using REST calls.
 -->
 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}
 的核心是 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}。
@@ -29,38 +35,18 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和
 Kubernetes API 使你可以查询和操纵 Kubernetes API
 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。
 
-API 末端、资源类型以及示例都在[API 参考](/zh/docs/reference/kubernetes-api/)中描述。
-
-<!-- body -->
+大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/overview/) 命令行接口或
+类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行，
+这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。
 
 <!--
-## API changes
-
-Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
-Therefore, Kubernetes has design features to allow the Kubernetes API to continuously change and grow.
-The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
-compatibility for a length of time so that other projects have an opportunity to adapt.
-
-In general, new API resources and new resource fields can be added often and frequently.
-Elimination of resources or fields requires following the
-[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-
-What constitutes a compatible change, and how to change the API, are detailed in
-[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
+Consider using one of the [client libraries](/docs/reference/using-api/client-libraries/)
+if you are writing an application using the Kubernetes API.
 -->
-## API 变更     {#api-changes}
+如果你正在编写程序来访问 Kubernetes API，可以考虑使用
+[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。
 
-任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。
-为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。
-Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内
-维持这种兼容性，以便其他项目有机会作出适应性变更。
-
-一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
-删除资源或者字段则要遵从
-[API 废弃策略](/docs/reference/using-api/deprecation-policy/)。
-
-关于什么是兼容性的变更，如何变更 API 等详细信息，可参考
-[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
+<!-- body -->
 
 <!--
 ## OpenAPI specification {#api-specification}
@@ -70,7 +56,6 @@ Complete API details are documented using [OpenAPI](https://www.openapis.org/).
 The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
 You can request the response format using request headers as follows:
 -->
-
 ## OpenAPI 规范     {#api-specification}
 
 完整的 API 细节是用 [OpenAPI](https://www.openapis.org/) 来表述的。
@@ -142,204 +127,137 @@ Kubernetes API 服务器通过 `/openapi/v2` 末端提供 OpenAPI 规范。
 </table>
 
 <!--
-Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
+Kubernetes implements an alternative Protobuf based serialization format that
+is primarily intended for intra-cluster communication. For more information
+about this format, see the [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) design proposal and the
+Interface Definition Language (IDL) files for each schema located in the Go
+packages that define the API objects.
 -->
-Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部的通信。
-相关文档位于[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)。
-每种 Schema 对应的 IDL 位于定义 API 对象的 Go 包中。
+Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部通信。
+关于此格式的详细信息，可参考
+[Kubernetes Protobuf 序列化](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)
+设计提案。每种模式对应的接口描述语言（IDL）位于定义 API 对象的 Go 包中。
 
 <!--
-## API versioning
+## API changes
 
-To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
-multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/rbac.authorization.k8s.io/v1alpha1`.
+Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
+Therefore, Kubernetes has designed its features to allow the Kubernetes API to continuously change and grow.
+The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
+compatibility for a length of time so that other projects have an opportunity to adapt.
+
+In general, new API resources and new resource fields can be added often and frequently.
+Elimination of resources or fields requires following the
+[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
+
+What constitutes a compatible change, and how to change the API, are detailed in
+[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
 -->
-## API 版本   {#api-versioning}
+## API 变更     {#api-changes}
+
+任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。
+为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。
+Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内
+维持这种兼容性，以便其他项目有机会作出适应性变更。
+
+一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
+删除资源或者字段则要遵从
+[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。
+
+关于什么是兼容性的变更、如何变更 API 等详细信息，可参考
+[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
+
+<!--
+## API groups and versioning
+
+To make it easier to eliminate fields or restructure resource representations,
+Kubernetes supports multiple API versions, each at a different API path, such
+as `/api/v1` or `/apis/rbac.authorization.k8s.io/v1alpha1`.
+-->
+## API 组和版本   {#api-groups-and-versioning}
 
 为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本，
 每一个版本都在不同 API 路径下，例如 `/api/v1` 或
 `/apis/rbac.authorization.k8s.io/v1alpha1`。
 
 <!--
-Versioning is done at the API level rather than at the resource or field level to ensure that the
-API presents a clear, consistent view of system resources and behavior, and to enable controlling
-access to end-of-life and/or experimental APIs.
-
-The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
+Versioning is done at the API level rather than at the resource or field level
+to ensure that the API presents a clear, consistent view of system resources
+and behavior, and to enable controlling access to end-of-life and/or
+experimental APIs.
 -->
 版本化是在 API 级别而不是在资源或字段级别进行的，目的是为了确保 API
 为系统资源和行为提供清晰、一致的视图，并能够控制对已废止的和/或实验性 API 的访问。
 
-JSON 和 Protobuf 序列化模式遵循 schema 更改的相同准则 - 下面的所有描述都同时适用于这两种格式。
+<!--
+To make it easier to evolve and to extend its API, Kubernetes implements
+[API groups](/docs/reference/using-api/#api-groups) that can be
+[enabled or disabled](/docs/reference/using-api/#enabling-or-disabling).
+-->
+为了便于演化和扩展其 API，Kubernetes 实现了
+可被[启用或禁用](/zh/docs/reference/using-api/#enabling-or-disabling)的
+[API 组](/docs/reference/using-api/#api-groups)。
 
 <!--
-Note that API versioning and Software versioning are only indirectly related.  The
-[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
-proposal describes the relationship between API versioning and software versioning.
-
-Different API versions imply different levels of stability and support.  The criteria for each level are described
-in more detail in the
-[API Changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
-documentation.  They are summarized here:
+API resources are distinguished by their API group, resource type, namespace
+(for namespaced resources), and name. The API server may serve the same
+underlying data through multiple API version and handle the conversion between
+API versions transparently. All these different versions are actually
+representations of the same resource. For example, suppose there are two
+versions `v1` and `v1beta1` for the same resource. An object created by the
+`v1beta1` version can then be read, updated, and deleted by either the
+`v1beta1` or the `v1` versions.
 -->
-请注意，API 版本控制和软件版本控制只有间接相关性。
-[Kubernetes 发行版本提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
-中描述了 API 版本与软件版本之间的关系。
-
-不同的 API 版本名称意味着不同级别的软件稳定性和支持程度。
-每个级别的判定标准在
-[API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
-中有更详细的描述。
-这些标准主要概括如下：
+API 资源之间靠 API 组、资源类型、名字空间（对于名字空间作用域的资源而言）和
+名字来相互区分。API 服务器可能通过多个 API 版本来向外提供相同的下层数据，
+并透明地完成不同 API 版本之间的转换。所有这些不同的版本实际上都是同一资源
+的（不同）表现形式。例如，假定同一资源有 `v1` 和 `v1beta1` 版本，
+使用 `v1beta1` 创建的对象则可以使用 `v1beta1` 或者 `v1` 版本来读取、更改
+或者删除。
 
 <!--
-- Alpha level:
-  - The version names contain `alpha` (e.g. `v1alpha1`).
-  - May be buggy.  Enabling the feature may expose bugs.  Disabled by default.
-  - Support for feature may be dropped at any time without notice.
-  - The API may change in incompatible ways in a later software release without notice.
-  - Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
+Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
+for more details on the API version level definitions.
 -->
-- Alpha 级别：
-  - 版本名称包含 `alpha`（例如：`v1alpha1`）
-  - API 可能是有缺陷的。启用该功能可能会带来问题，默认情况是禁用的
-  - 对相关功能的支持可能在没有通知的情况下随时终止
-  - API 可能在将来的软件发布中出现不兼容性的变更，此类变更不会另行通知
-  - 由于缺陷风险较高且缺乏长期支持，推荐仅在短暂的集群测试中使用
+关于 API 版本级别的详细定义，请参阅
+[API 版本参考](/zh/docs/reference/using-api/#api-versioning)。
 
 <!--
-- Beta level:
-  - The version names contain `beta` (e.g. `v2beta3`).
-  - Code is well tested.  Enabling the feature is considered safe.  Enabled by default.
-  - Support for the overall feature will not be dropped, though details may change.
-  - The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release.  When this happens,
-    we will provide instructions for migrating to the next version.  This may require deleting, editing, and re-creating
-    API objects.  The editing process may require some thought.   This may require downtime for applications that rely on the feature.
-  - Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases.  If you have
-    multiple clusters which can be upgraded independently, you may be able to relax this restriction.
-  - **Please do try our beta features and give feedback on them!  Once they exit beta, it may not be practical for us to make more changes.**
+## API Extension
+
+The Kubernetes API can be extended in one of two ways:
 -->
-- Beta 级别：
-  - 版本名称包含 `beta`（例如：`v2beta3`）
-  - 代码已经充分测试过。启用该功能被认为是安全的，功能默认已启用。
-  - 所支持的功能作为一个整体不会被删除，尽管细节可能会发生变更。
-  - 对象的模式和/或语义可能会在后续的 beta 发行版或稳定版中以不兼容的方式进行更改。
-    发生这种情况时，我们将提供如何迁移到新版本的说明。
-    迁移操作可能需要删除、编辑和重新创建 API 对象。
-    执行编辑操作时可能需要动些脑筋。
-    迁移过程中可能需要停用依赖该功能的应用程序。
-  - 建议仅用于非业务关键性用途，因为后续版本中可能存在不兼容的更改。
-    如果你有多个可以独立升级的集群，则可以放宽此限制。
-  - **请尝试我们的 beta 版本功能并且给出反馈！一旦它们结束 beta 阶段，进一步变更可能就不太现实了。**
-<!--
-- Stable level:
-  - The version name is `vX` where `X` is an integer.
-  - Stable versions of features will appear in released software for many subsequent versions.
--->
-- 稳定级别：
-  - 版本名称是 `vX`，其中 `X` 是整数。
-  - 功能的稳定版本将出现在许多后续版本的发行软件中。
+## API 扩展  {#api-extension}
+
+有两种途径来扩展 Kubernetes API：
 
 <!--
-## API groups
-
-To make it easier to extend the Kubernetes API, Kubernetes implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
-The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
+1. [Custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+   let you declaratively define how the API server should provide your chosen resource API.
+1. You can also extend the Kubernetes API by implementing an
+   [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 -->
-## API 组  {#api-groups}
-
-为了更容易地扩展 Kubernetes API，Kubernetes 实现了
-[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。
-API 组在 REST 路径和序列化对象的 `apiVersion` 字段中指定。
-
-<!--
-There are several API groups in a cluster:
-
-1. The *core* group, also referred to as the *legacy* group, is at the REST path `/api/v1` and uses `apiVersion: v1`.
-
-1. *Named* groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
-   (e.g. `apiVersion: batch/v1`). The Kubernetes [API reference](/docs/reference/kubernetes-api/) has a
-   full list of available API groups.
--->
-集群中存在若干 API 组：
-
-1. *核心（Core）*组，通常被称为 *遗留（Legacy）* 组，位于 REST 路径 `/api/v1`，
-   使用 `apiVersion: v1`。
-
-1. *命名（Named）* 组 REST 路径 `/apis/$GROUP_NAME/$VERSION`，使用
-   `apiVersion: $GROUP_NAME/$VERSION`（例如 `apiVersion: batch/v1`）。
-   [Kubernetes API 参考](/zh/docs/reference/kubernetes-api/)中枚举了可用的 API 组的完整列表。
-
-<!--
-There are two paths to extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/):
-
-1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
-   lets you declaratively define how the API server should provide your chosen resource API.
-1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/)
-   and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
-   to make it seamless for clients.
--->
-有两种途径来扩展 Kubernetes API 以支持
-[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
-
-1. 使用 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
-   你可以用声明式方式来定义 API 如何提供你所选择的资源 API。 
-
-1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
-   并使用[聚合器](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
-   为客户提供无缝的服务。
-
-<!--
-## Enabling or disabling API groups
-
-Certain resources and API groups are enabled by default.  They can be enabled or disabled by setting `-runtime-config`
-on apiserver. `-runtime-config` accepts comma separated values. For example: to disable batch/v1, set
-`-runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `-runtime-config=batch/v2alpha1`.
-The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
-
-Enabling or disabling groups or resources requires restarting apiserver and controller-manager
-to pick up the `-runtime-config` changes.
--->
-## 启用或禁用 API 组  {#enabling-or-disabling-api-groups}
-
-某些资源和 API 组默认情况下处于启用状态。可以通过为 `kube-apiserver` 
-设置 `--runtime-config` 命令行选项来启用或禁用它们。
-`--runtime-config` 接受逗号分隔的值。
-例如：要禁用 `batch/v1`，设置 `--runtime-config=batch/v1=false`；
-要启用 `batch/v2alpha1`，设置`--runtime-config=batch/v2alpha1`。
-该标志接受逗号分隔的一组"key=value"键值对，用以描述 API 服务器的运行时配置。
-
-{{< note >}}
-启用或禁用组或资源需要重新启动 `kube-apiserver` 和 `kube-controller-manager`
-来使得 `--runtime-config` 更改生效。
-{{< /note >}}
-
-<!--
-## Persistence
-
-Kubernetes stores its serialized state in terms of the API resources by writing them into
-{{< glossary_tooltip term_id="etcd" >}}.
--->
-## 持久性    {#persistence}
-
-Kubernetes 也将其 API 资源的序列化状态保存起来，写入到 {{< glossary_tooltip term_id="etcd" >}}。
+1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+   来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 
+1. 你也可以选择实现自己的
+   [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+   来扩展 Kubernetes API。
 
 ## {{% heading "whatsnext" %}}
 
 <!--
-[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes
-how the cluster manages authentication and authorization for API access.
-
-Overall API conventions are described in the
-[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
-document.
-
-API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
+- Learn how to extend the Kubernetes API by adding your own
+  [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
+- [Controlling Access To The Kubernetes API](/docs/concepts/security/controlling-access/) describes
+  how the cluster manages authentication and authorization for API access.
+- Learn about API endpoints, resource types and samples by reading
+  [API Reference](/docs/reference/kubernetes-api/).
 -->
-* [控制 API 访问](/zh/docs/reference/access-authn-authz/controlling-access/)
-  描述了集群如何为 API 访问管理身份认证和权限判定；
-* 总体的 API 约定描述位于 [API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)中；
-* API 末端、资源类型和示例等均在 [API 参考文档](/zh/docs/reference/kubernetes-api/)中描述
-
+- 了解如何通过添加你自己的
+  [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
+  来扩展 Kubernetes API。
+- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)
+  页面描述了集群如何针对 API 访问管理身份认证和鉴权。
+- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)
+  了解 API 端点、资源类型以及示例。
 
diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md
index 4aab8132f1..3fa58f5da0 100644
--- a/content/zh/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md
@@ -9,7 +9,6 @@ card:
   weight: 10
 ---
 <!--
----
 reviewers:
 - bgrant0607
 - mikedanese
@@ -19,7 +18,6 @@ weight: 10
 card:
   name: concepts
   weight: 10
----
 -->
 
 <!-- overview -->
@@ -33,18 +31,22 @@ This page is an overview of Kubernetes.
 <!--
 Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
 -->
-Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
+Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
+Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
 
 <!--
 The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a [decade and a half of experience that Google has with running production workloads at scale](https://research.google/pubs/pub43438), combined with best-of-breed ideas and practices from the community.
 -->
-名称 **Kubernetes** 源于希腊语，意为 "舵手" 或 "飞行员"。Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438)的基础上，结合了社区中最好的想法和实践。
+名称 **Kubernetes** 源于希腊语，意为“舵手”或“飞行员”。Google 在 2014 年开源了 Kubernetes 项目。
+Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438)
+的基础上，结合了社区中最好的想法和实践。
 
 <!--
 ## Going back in time
 Let's take a look at why Kubernetes is so useful by going back in time.
 -->
-## 言归正传
+## 时光回溯
+
 让我们回顾一下为什么 Kubernetes 如此有用。
 
 <!--
@@ -54,24 +56,34 @@ Let's take a look at why Kubernetes is so useful by going back in time.
 
 <!--
 **Traditional deployment era:**
+
 Early on, organizations ran applications on physical servers. There was no way to define resource boundaries for applications in a physical server, and this caused resource allocation issues. For example, if multiple applications run on a physical server, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers.
 -->
 **传统部署时代：**
-早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。
+
+早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。
+例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，
+结果可能导致其他应用程序的性能下降。
+一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，
+并且组织维护许多物理服务器的成本很高。
 
 <!--
 **Virtualized deployment era:**
 As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization allows applications to be isolated between VMs and provides a level of security as the information of one application cannot be freely accessed by another application.
 -->
 **虚拟化部署时代：**
-作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。
+
+作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。
+虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全，因为一个应用程序的信息
+不能被另一应用程序随意访问。
 
 <!--
 Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more.
 
 Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware.
 -->
-因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。
+虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序
+而可以实现更好的可伸缩性，降低硬件成本等等。
 
 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。
 
@@ -80,12 +92,15 @@ Each VM is a full machine running all the components, including its own operatin
 Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
 -->
 **容器部署时代：**
-容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。
+
+容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。
+因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。
+由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
 
 <!--
 Containers are becoming popular because they have many benefits. Some of the container benefits are listed below:
 -->
-容器因具有许多优势而变得流行起来。下面列出了容器的一些好处：
+容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处：
 
 <!--
 * Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.
@@ -100,13 +115,18 @@ Containers are becoming popular because they have many benefits. Some of the con
 * Resource utilization: high efficiency and density.
 -->
 * 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
-* 持续开发、集成和部署：通过快速简单的回滚(由于镜像不可变性)，提供可靠且频繁的容器镜像构建和部署。
-* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
+* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的
+  容器镜像构建和部署。
+* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，
+  从而将应用程序与基础架构分离。
 * 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
 * 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
-* 云和操作系统分发的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。
-* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
-* 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
+* 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、
+  Google Kubernetes Engine 和其他任何地方运行。
+* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在
+  OS 上运行应用程序。
+* 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，
+  并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
 * 资源隔离：可预测的应用程序性能。
 * 资源利用：高效率和高密度。
 
@@ -118,59 +138,75 @@ Containers are becoming popular because they have many benefits. Some of the con
 <!--
 Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system?
 -->
-容器是打包和运行应用程序的好方式。在生产环境中，您需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
+容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。
+例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
 
 <!--
 That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of your scaling requirements, failover, deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system.
 -->
-这就是 Kubernetes 的救援方法！Kubernetes 为您提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。例如，Kubernetes 可以轻松管理系统的 Canary 部署。
+这就是 Kubernetes 来解决这些问题的方法！
+Kubernetes 为你提供了一个可弹性运行分布式系统的框架。
+Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
+例如，Kubernetes 可以轻松管理系统的 Canary 部署。
 
 <!--
 Kubernetes provides you with:
 -->
-Kubernetes 为您提供：
+Kubernetes 为你提供：
 
 <!--
 * **Service discovery and load balancing**  
 Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
 -->
-* **服务发现和负载均衡**  
-Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
+* **服务发现和负载均衡**
+
+  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大，
+  Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
 
 <!--
 * **Storage orchestration**  
 Kubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.
 -->
-* **存储编排**  
-Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。
+* **存储编排**
+
+  Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
 
 <!--
 * **Automated rollouts and rollbacks**  
 You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.
 -->
-* **自动部署和回滚**  
-您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
+* **自动部署和回滚**
+
+  你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态
+  更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器，
+  删除现有容器并将它们的所有资源用于新容器。
 
 <!--
 * **Automatic bin packing**  
 Kubernetes allows you to specify how much CPU and memory (RAM) each container needs. When containers have resource requests specified, Kubernetes can make better decisions to manage the resources for containers.
 -->
-* **自动二进制打包**  
-Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
+* **自动完成装箱计算**
+
+  Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。
+  当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
 
 <!--
 * **Self-healing**  
 Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
 -->
-* **自我修复**  
-Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
+* **自我修复**
+
+  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的
+  运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
 
 <!--
 * **Secret and configuration management**  
 Kubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration.
 -->
-* **密钥与配置管理**  
-Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
+* **密钥与配置管理**
+
+  Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。
+  你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
 
 <!--
 ## What Kubernetes is not
@@ -180,7 +216,11 @@ Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和
 <!--
 Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
 -->
-Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。由于 Kubernetes 在容器级别而不是在硬件级别运行，因此它提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡、日志记录和监视。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
+Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。
+由于 Kubernetes 在容器级别而不是在硬件级别运行，它提供了 PaaS 产品共有的一些普遍适用的功能，
+例如部署、扩展、负载均衡、日志记录和监视。
+但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。
+Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
 
 <!--
 Kubernetes:
@@ -192,22 +232,33 @@ Kubernetes：
 * Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements.
 * Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, mysql), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes through portable mechanisms, such as the Open Service Broker.
 -->
-* Kubernetes 不限制支持的应用程序类型。Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
-* Kubernetes 不部署源代码，也不构建您的应用程序。持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
-* Kubernetes 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统（例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如，[开放服务代理](https://openservicebrokerapi.org/)）来访问。
-
+* 不限制支持的应用程序类型。
+  Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。
+  如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
+* 不部署源代码，也不构建你的应用程序。
+  持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
+* 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、
+  数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统
+  （例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在
+  Kubernetes 上的应用程序通过可移植机制（例如，
+  [开放服务代理](https://openservicebrokerapi.org/)）来访问。
 <!--
 * Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics.
 * Does not provide nor mandate a configuration language/system (for example, jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications.
 * Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
 * Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
 -->
-* Kubernetes 不指定日志记录、监视或警报解决方案。它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
-* Kubernetes 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，该声明性 API 可以由任意形式的声明性规范所构成。
-* Kubernetes 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
-* 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。相比之下，Kubernetes 包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用且功能更强大、健壮、弹性和可扩展性。
-
-
+* 不要求日志记录、监视或警报解决方案。
+  它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
+* 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，
+  该声明性 API 可以由任意形式的声明性规范所构成。
+* 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
+* 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。
+  编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。
+  相比之下，Kubernetes 包含一组独立的、可组合的控制过程，
+  这些过程连续地将当前状态驱动到所提供的所需状态。
+  如何从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用
+  且功能更强大、系统更健壮、更为弹性和可扩展。
 
 ## {{% heading "whatsnext" %}}
 
@@ -215,5 +266,5 @@ Kubernetes：
 *   Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
 *   Ready to [Get Started](/docs/setup/)?
 -->
-*   查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
-*   开始 [Kubernetes 入门](/zh/docs/setup/)?
+* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
+* 开始 [Kubernetes 入门](/zh/docs/setup/)?
diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md
index f342a92113..5239861124 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/annotations.md
@@ -121,18 +121,18 @@ _注解（Annotations）_ 存储的形式是键/值对。有效的注解键分
 并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 
 前缀是可选的。如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，
 总计不超过253个字符，后跟斜杠（`/`）。
-如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释
+如果省略前缀，则假定注解键对用户是私有的。 由系统组件添加的注解
 （例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl`
-或其他第三方组件），必须为终端用户添加注释前缀。
+或其他第三方组件），必须为终端用户添加注解前缀。
 
 <!--
 The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
 
-For example, here’s the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` :
+For example, here's the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` :
 -->
 `kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。
 
-例如，这是Pod的配置文件，其注释为 `imageregistry: https://hub.docker.com/`：
+例如，下面是一个 Pod 的配置文件，其注解中包含 `imageregistry: https://hub.docker.com/`：
 
 ```yaml
 apiVersion: v1
diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index f5843e2573..96a863cfa0 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -191,11 +191,11 @@ and the `spec` format for a `Deployment` can be found
 ## {{% heading "whatsnext" %}}
 
 <!--
-* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
-* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
-* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
+* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
+* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
+* [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.
 -->
-* [Kubernetes API 总览](/zh/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述
-* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)
-* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)
+* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。
+* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。
+* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。
 
diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md
index 941cdaccb2..88f189287e 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md
@@ -239,7 +239,7 @@ Similarly the comma separator acts as an _AND_ operator. So filtering resources
 The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`.
 -->
 _基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `environment=production`
-等同于 `environment in（production`；`!=` 和 `notin` 也是类似的。
+等同于 `environment in（production）`；`!=` 和 `notin` 也是类似的。
 
 <!--
 _Set-based_ requirements can be mixed with _equality-based_ requirements. For example: `partition in (customerA, customerB),environment!=qa`.
@@ -307,7 +307,7 @@ and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationc
 also use label selectors to specify sets of other resources, such as
 [pods](/docs/concepts/workloads/pods/).
 -->
-### 在 API 对象上设置引用
+### 在 API 对象中设置引用
 
 一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/)
 和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ，
@@ -323,9 +323,11 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma
 -->
 #### Service 和 ReplicationController
 
-一个 `Service` 指向的一组 pods 是由标签选择算符定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择算符定义的。
+一个 `Service` 指向的一组 Pods 是由标签选择算符定义的。同样，一个 `ReplicationController`
+应该管理的 pods 的数量也是由标签选择算符定义的。
 
-两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于等值_ 需求的选择算符：
+两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持
+_基于等值_ 需求的选择算符：
 
 ```json
 "selector": {
diff --git a/content/zh/docs/concepts/overview/working-with-objects/names.md b/content/zh/docs/concepts/overview/working-with-objects/names.md
index 303a7e541d..678adea96d 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/names.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/names.md
@@ -13,7 +13,7 @@ Every Kubernetes object also has a [_UID_](#uids) that is unique across your who
 For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`.
 -->
 
-集群中的每一个对象都一个[_名称_](#names) 来标识在同类资源中的唯一性。
+集群中的每一个对象都有一个[_名称_](#names) 来标识在同类资源中的唯一性。
 
 每个 Kubernetes 对象也有一个[_UID_](#uids) 来标识在整个集群中的唯一性。
 
diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md
index be240bfb9b..f4907de51f 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md
@@ -47,12 +47,8 @@ resource can only be in one namespace.
 
 <!--
 Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
-
-In future versions of Kubernetes, objects in the same namespace will have the same
-access control policies by default.
 -->
 名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。
-在 Kubernetes 未来版本中，相同名字空间中的对象默认将具有相同的访问控制策略。
 
 <!--
 It is not necessary to use multiple namespaces just to separate slightly different
diff --git a/content/zh/docs/concepts/overview/working-with-objects/object-management.md b/content/zh/docs/concepts/overview/working-with-objects/object-management.md
index fc48eb7489..e7bcf9af09 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/object-management.md
@@ -324,10 +324,10 @@ Disadvantages compared to imperative object configuration:
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 -->
-- [使用命令式命令管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [使用命令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
 - [使用对象配置管理 Kubernetes 对象（命令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
-- [使用对象配置管理 Kubernetes 对象（声明式）](/docs/tasks/manage-kubernetes-objects/declarative-config/)
-- [使用 Kustomize（声明式）管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [使用对象配置管理 Kubernetes 对象（声明式）](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/zh/docs/concepts/policy/_index.md b/content/zh/docs/concepts/policy/_index.md
index 68973c7a85..fa69e7cae6 100644
--- a/content/zh/docs/concepts/policy/_index.md
+++ b/content/zh/docs/concepts/policy/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "策略"
-weight: 160
+weight: 90
+description: 可配置的、可应用到一组资源的策略。
 ---
diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md
index 38c97dcc6e..5d87012e66 100644
--- a/content/zh/docs/concepts/policy/pod-security-policy.md
+++ b/content/zh/docs/concepts/policy/pod-security-policy.md
@@ -69,7 +69,7 @@ Pod 安全策略允许管理员控制如下方面：
 | 分配拥有 Pod 卷的 FSGroup 账号      | [`fsGroup`](#volumes-and-file-systems)      |
 | 以只读方式访问根文件系统            | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
 | 设置容器的用户和组 ID               | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) |
-| 限制 roo 账号特权级提升             | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |
+| 限制 root 账号特权级提升             | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |
 | Linux 权能字（Capabilities）        | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) |
 | 设置容器的 SELinux 上下文           | [`seLinux`](#selinux)                       |
 | 指定容器可以挂载的 proc 类型        | [`allowedProcMountTypes`](#allowedprocmounttypes) |
@@ -380,7 +380,7 @@ The name of a PodSecurityPolicy object must be a valid
 -->
 ### 创建一个策略和一个 Pod
 
-在一个文件中定一个示例的 PodSecurityPolicy 对象。
+在一个文件中定义一个示例的 PodSecurityPolicy 对象。
 这里的策略只是用来禁止创建有特权要求的 Pods。
 PodSecurityPolicy 对象的名称必须是合法的
 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
@@ -862,7 +862,7 @@ to effectively limit access to the specified `pathPrefix`.
 
 {{< warning >}}
 容器如果对宿主文件系统拥有不受限制的访问权限，就可以有很多种方式提升自己的特权，
-包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）`的凭据信息等。
+包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）的凭据信息等。
 
 由可写入的目录所构造的 `hostPath` 卷能够允许容器写入数据到宿主文件系统，
 并且在写入时避开 `pathPrefix` 所设置的目录限制。
diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md
index f6bd8acf9e..be1cf5765d 100644
--- a/content/zh/docs/concepts/policy/resource-quotas.md
+++ b/content/zh/docs/concepts/policy/resource-quotas.md
@@ -30,7 +30,7 @@ Resource quotas are a tool for administrators to address this concern.
 A resource quota, defined by a `ResourceQuota` object, provides constraints that limit
 aggregate resource consumption per namespace.  It can limit the quantity of objects that can
 be created in a namespace by type, as well as the total amount of compute resources that may
-be consumed by resources in that project.
+be consumed by resources in that namespace.
 -->
 资源配额，通过 `ResourceQuota` 对象来定义，对每个命名空间的资源消耗总量提供限制。
 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。
@@ -43,9 +43,9 @@ Resource quotas work like this:
 <!--
 - Different teams work in different namespaces.  Currently this is voluntary, but
   support for making this mandatory via ACLs is planned.
-- The administrator creates one `ResourceQuota` for each namespace.
+- The administrator creates one ResourceQuota for each namespace.
 - Users create resources (pods, services, etc.) in the namespace, and the quota system
-  tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`.
+  tracks usage to ensure it does not exceed hard resource limits defined in a ResourceQuota.
 - If creating or updating a resource violates a quota constraint, the request will fail with HTTP
   status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
 - If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify
@@ -55,9 +55,9 @@ Resource quotas work like this:
 -->
 - 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过
   ACL (Access Control List 访问控制列表) 来实现强制性约束。
-- 集群管理员可以为每个命名空间创建一个或多个资源配额对象。
+- 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
 - 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会
-  跟踪集群的资源使用情况，以确保使用的资源用量不超过资源配额中定义的硬性资源限额。
+  跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
 - 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN），
   并在消息中给出有可能违反的约束。
 - 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为
@@ -68,10 +68,10 @@ Resource quotas work like this:
   [演练](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)示例。
 
 <!--
-The name of a `ResourceQuota` object must be a valid
+The name of a ResourceQuota object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
-ResourceQuota 对象的名称必须时合法的
+ResourceQuota 对象的名称必须是合法的
 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
 <!--
@@ -103,19 +103,19 @@ Neither contention nor changes to quota will affect already created resources.
 ## Enabling Resource Quota
 
 Resource Quota support is enabled by default for many Kubernetes distributions.  It is
-enabled when the apiserver `-enable-admission-plugins=` flag has `ResourceQuota` as
+enabled when the API server `--enable-admission-plugins=` flag has `ResourceQuota` as
 one of its arguments.
 -->
 ## 启用资源配额
 
-资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 apiserver `--enable-admission-plugins=`
+资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 API 服务器的 `--enable-admission-plugins=`
 参数中包含 `ResourceQuota` 时，资源配额会被启用。
 
 <!--
 A resource quota is enforced in a particular namespace when there is a
-`ResourceQuota` in that namespace.
+ResourceQuota in that namespace.
 -->
-当命名空间中存在一个 `ResourceQuota` 对象时，对于该命名空间而言，资源配额就是开启的。
+当命名空间中存在一个 ResourceQuota 对象时，对于该命名空间而言，资源配额就是开启的。
 
 <!--
 ## Compute Resource Quota
@@ -140,6 +140,9 @@ The following resource types are supported:
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
+| `hugepages-<size>` | Across all pods in a non-terminal state, the number of huge page requests of the specified size cannot exceed this value. |
+| `cpu` | Same as `requests.cpu` |
+| `memory` | Same as `requests.memory` |
 -->
 | 资源名称 | 描述 |
 | --------------------- | --------------------------------------------- |
@@ -147,6 +150,9 @@ The following resource types are supported:
 | `limits.memory` | 所有非终止状态的 Pod，其内存限额总量不能超过该值。 |
 | `requests.cpu` | 所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。 |
 | `requests.memory` | 所有非终止状态的 Pod，其内存需求总量不能超过该值。 |
+| `hugepages-<size>` | 对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。 |
+| `cpu` | 与 `requests.cpu` 相同。 |
+| `memory` | 与 `requests.memory` 相同。 |
 
 <!--
 ### Resource Quota For Extended Resources
@@ -198,16 +204,16 @@ In addition, you can limit consumption of storage resources based on associated
 | Resource Name | Description |
 | --------------------- | --------------------------------------------------------- |
 | `requests.storage` | Across all persistent volume claims, the sum of storage requests cannot exceed this value. |
-| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value. |
+| `persistentvolumeclaims` | The total number of [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the `<storage-class-name>`, the sum of storage requests cannot exceed this value. |
 | `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | Across all persistent volume claims associated with the storage-class-name, the total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
 -->
 | 资源名称 | 描述 |
 | --------------------- | ----------------------------------------------------------- |
 | `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 |
-| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
+| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 `<storage-class-name>` 相关的持久卷申领中，存储请求的总和不能超过该值。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
 
 <!--
 For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
@@ -228,22 +234,29 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f
 | ------------------------------- |----------------------------------------------------------- |
 | `requests.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage requests cannot exceed this value. |
 | `limits.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage limits cannot exceed this value. |
+| `ephemeral-storage` | Same as `requests.ephemeral-storage`. |
 -->
 | 资源名称 | 描述 |
 | ------------------------------- |----------------------------------------------------------- |
 | `requests.ephemeral-storage` | 在命名空间的所有 Pod 中，本地临时存储请求的总和不能超过此值。 |
 | `limits.ephemeral-storage` | 在命名空间的所有 Pod 中，本地临时存储限制值的总和不能超过此值。 |
+| `ephemeral-storage` | 与 `requests.ephemeral-storage` 相同。 |
 
 <!--
 ## Object Count Quota
 
-The 1.9 release added support to quota all standard namespaced resource types using the following syntax:
+You can set quota for the total number of certain resources of all standard,
+namespaced resource types using the following syntax:
+
+* `count/<resource>.<group>` for resources from non-core groups
+* `count/<resource>` for resources from the core group
 -->
 ## 对象数量配额
 
-Kubernetes 1.9 版本增加了使用以下语法对所有标准的、命名空间域的资源类型进行配额设置的支持。
+你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置：
 
-* `count/<resource>.<group>`
+* `count/<resource>.<group>`：用于非核心（core）组的资源
+* `count/<resource>`：用于核心组的资源
 
 <!--
 Here is an example set of resources users may want to put under object count quota:
@@ -260,33 +273,34 @@ Here is an example set of resources users may want to put under object count quo
 * `count/statefulsets.apps`
 * `count/jobs.batch`
 * `count/cronjobs.batch`
-* `count/deployments.extensions`
 
 <!--
-The 1.15 release added support for custom resources using the same syntax.
+The same syntax can be used for custom resources.
 For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`.
 -->
-Kubernetes 1.15 版本增加了对使用相同语法来约束自定义资源的支持。
+相同语法也可用于自定义资源。
 例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 `count/widgets.example.com`。
 
 <!--
 When using `count/*` resource quota, an object is charged against the quota if it exists in server storage.
 These types of quotas are useful to protect against exhaustion of storage resources.  For example, you may
-want to quota the number of secrets in a server given their large size.  Too many secrets in a cluster can
-actually prevent servers and controllers from starting!  You may choose to quota jobs to protect against
-a poorly configured cronjob creating too many jobs in a namespace causing a denial of service.
+want to limit the number of Secrets in a server given their large size. Too many Secrets in a cluster can
+actually prevent servers and controllers from starting. You can set a quota for Jobs to protect against
+a poorly configured CronJob. CronJobs that create too many Jobs in a namespace can lead to a denial of service.
 -->
 当使用 `count/*` 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。
-这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动！用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多作业而导致集群拒绝服务。
-
+这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中
+Secret 的数量进行配额限制。
+集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。
+用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。
 
 <!--
-Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources.
+It is possible to do generic object count quota on a limited set of resources.
 In addition, it is possible to further constrain quota for particular resources by their type.
 
 The following types are supported:
 -->
-在 Kubernetes 1.9 版本之前，可以在有限的一组资源上实施一般性的对象数量配额。
+对有限的一组资源上实施一般性的对象数量配额也是可能的。
 此外，还可以进一步按资源的类型设置其配额。
 
 支持以下类型：
@@ -294,26 +308,26 @@ The following types are supported:
 <!--
 | Resource Name | Description |
 | ----------------------------|--------------------------------------------- |
-| `configmaps` | The total number of config maps that can exist in the namespace. |
-| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `pods` | The total number of pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
-| `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. |
-| `resourcequotas` | The total number of [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) that can exist in the namespace. |
-| `services` | The total number of services that can exist in the namespace. |
-| `services.loadbalancers` | The total number of services of type load balancer that can exist in the namespace. |
-| `services.nodeports` | The total number of services of type node port that can exist in the namespace. |
-| `secrets` | The total number of secrets that can exist in the namespace. |
+| `configmaps` | The total number of ConfigMaps that can exist in the namespace. |
+| `persistentvolumeclaims` | The total number of [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
+| `pods` | The total number of Pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
+| `replicationcontrollers` | The total number of ReplicationControllers that can exist in the namespace. |
+| `resourcequotas` | The total number of ResourceQuotas that can exist in the namespace. |
+| `services` | The total number of Services that can exist in the namespace. |
+| `services.loadbalancers` | The total number of Services of type `LoadBalancer` that can exist in the namespace. |
+| `services.nodeports` | The total number of Services of type `NodePort` that can exist in the namespace. |
+| `secrets` | The total number of Secrets that can exist in the namespace. |
 -->
 | 资源名称 | 描述 |
 | ------------------------------- | ------------------------------------------------- |
 | `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 |
-| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
-| `pods` | 在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` = true |
-| `replicationcontrollers` | 在该命名空间中允许存在的 RC 总数上限。 |
-| `resourcequotas` | 在该命名空间中允许存在的资源配额总数上限。 |
+| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
+| `pods` | 在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` 为真。 |
+| `replicationcontrollers` | 在该命名空间中允许存在的 ReplicationController 总数上限。 |
+| `resourcequotas` | 在该命名空间中允许存在的 ResourceQuota 总数上限。 |
 | `services` | 在该命名空间中允许存在的 Service 总数上限。 |
-| `services.loadbalancers` | 在该命名空间中允许存在的 LoadBalancer 类型的服务总数上限。 |
-| `services.nodeports` | 在该命名空间中允许存在的 NodePort 类型的服务总数上限。 |
+| `services.loadbalancers` | 在该命名空间中允许存在的 LoadBalancer 类型的 Service 总数上限。 |
+| `services.nodeports` | 在该命名空间中允许存在的 NodePort 类型的 Service 总数上限。 |
 | `secrets` | 在该命名空间中允许存在的 Secret 总数上限。 |
 
 <!--
@@ -328,12 +342,12 @@ exhausts the cluster's supply of Pod IPs.
 <!--
 ## Quota Scopes
 
-Each quota can have an associated set of scopes.  A quota will only measure usage for a resource if it matches
+Each quota can have an associated set of `scopes`. A quota will only measure usage for a resource if it matches
 the intersection of enumerated scopes.
 -->
 ## 配额作用域   {#quota-scopes}
 
-每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。
+每个配额都有一组相关的 `scope`（作用域），配额只会对作用域内的资源生效。
 配额机制仅统计所列举的作用域的交集中的资源用量。
 
 <!--
@@ -350,6 +364,7 @@ Resources specified on the quota outside of the allowed set results in a validat
 | `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` |
 | `BestEffort` | Match pods that have best effort quality of service. |
 | `NotBestEffort` | Match pods that do not have best effort quality of service. |
+| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). |
 -->
 | 作用域 | 描述 |
 | ----- | ----------- |
@@ -357,30 +372,88 @@ Resources specified on the quota outside of the allowed set results in a validat
 | `NotTerminating` | 匹配所有 `spec.activeDeadlineSeconds` 是 nil 的 Pod。 |
 | `BestEffort` | 匹配所有 Qos 是 BestEffort 的 Pod。 |
 | `NotBestEffort` | 匹配所有 Qos 不是 BestEffort 的 Pod。 |
+| `PriorityClass` | 匹配所有引用了所指定的[优先级类](/zh/docs/concepts/configuration/pod-priority-preemption)的 Pods。 |
 
 <!--
-The `BestEffort` scope restricts a quota to tracking the following resource: `pods`
+The `BestEffort` scope restricts a quota to tracking the following resource:
 
-The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources:
--->
-`BestEffort` 作用域限制配额跟踪以下资源：`pods`
-
-`Terminating`、`NotTerminating` 和 `NotBestEffort` 这三种作用域限制配额跟踪以下资源：
-
-* `cpu`
-* `limits.cpu`
-* `limits.memory`
-* `memory`
 * `pods`
+
+The `Terminating`, `NotTerminating`, `NotBestEffort` and `PriorityClass`
+scopes restrict a quota to tracking the following resources:
+-->
+`BestEffort` 作用域限制配额跟踪以下资源：
+
+* `pods`
+
+`Terminating`、`NotTerminating`、`NotBestEffort` 和 `PriorityClass` 这些作用域限制配额跟踪以下资源：
+
+* `pods`
+* `cpu`
+* `memory`
 * `requests.cpu`
 * `requests.memory`
+* `limits.cpu`
+* `limits.memory`
+
+<!--
+Note that you cannot specify both the `Terminating` and the `NotTerminating`
+scopes in the same quota, and you cannot specify both the `BestEffort` and
+`NotBestEffort` scopes in the same quota either.
+
+The `scopeSelector` supports the following values in the `operator` field:
+-->
+需要注意的是，你不可以在同一个配额对象中同时设置 `Terminating` 和 `NotTerminating`
+作用域，你也不可以在同一个配额中同时设置 `BestEffort` 和 `NotBestEffort`
+作用域。
+
+`scopeSelector` 支持在 `operator` 字段中使用以下值：
+
+* `In`
+* `NotIn`
+* `Exists`
+* `DoesNotExist`
+
+<!--
+When using one of the following values as the `scopeName` when defining the
+`scopeSelector`, the `operator` must be `Exists`. 
+-->
+定义 `scopeSelector` 时，如果使用以下值之一作为 `scopeName` 的值，则对应的
+`operator` 只能是 `Exists`。
+
+* `Terminating`
+* `NotTerminating`
+* `BestEffort`
+* `NotBestEffort`
+
+<!--
+If the `operator` is `In` or `NotIn`, the `values` field must have at least
+one value. For example:
+-->
+如果 `operator` 是 `In` 或 `NotIn` 之一，则 `values` 字段必须至少包含一个值。
+例如：
+
+```yaml
+  scopeSelector:
+    matchExpressions:
+      - scopeName: PriorityClass
+        operator: In
+        values:
+          - middle
+```
+
+<!--
+If the `operator` is `Exists` or `DoesNotExist`, the `values field must *NOT* be
+specified.
+-->
+如果 `operator` 为 `Exists` 或 `DoesNotExist`，则*不*可以设置 `values` 字段。
 
 <!--
 ### Resource Quota Per PriorityClass
 -->
 ### 基于优先级类（PriorityClass）来设置资源配额
 
-{{< feature-state for_k8s_version="1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.17" state="stable" >}}
 
 <!--
 Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority).
@@ -392,12 +465,30 @@ Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priorit
 
 <!--
 A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod.
-
-This example creates a quota object and matches it with pods at specific priorities. The example
-works as follows:
 -->
 仅当配额规范中的 `scopeSelector` 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。
 
+<!--
+When quota is scoped for priority class using `scopeSelector` field, quota object is restricted to track only following resources:
+-->
+如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类，则配额对象只能
+跟踪以下资源：
+
+* `pods`
+* `cpu`
+* `memory`
+* `ephemeral-storage`
+* `limits.cpu`
+* `limits.memory`
+* `limits.ephemeral-storage`
+* `requests.cpu`
+* `requests.memory`
+* `requests.ephemeral-storage`
+
+<!--
+This example creates a quota object and matches it with pods at specific priorities. The example
+works as follows:
+-->
 本示例创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配。
 该示例的工作方式如下：
 
@@ -586,16 +677,6 @@ memory      0     20Gi
 pods        0     10
 ```
 
-<!--
-`scopeSelector` supports the following values in the `operator` field:
--->
-`scopeSelector` 在 `operator` 字段中支持以下值：
-
-* `In`
-* `NotIn`
-* `Exist`
-* `DoesNotExist`
-
 <!--
 ## Requests vs Limits
 
@@ -725,11 +806,11 @@ kubectl create namespace myspace
 ```
 
 ```shell
-kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
+kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
 ```
 
 ```shell
-kubectl create deployment nginx --image=nginx --namespace=myspace
+kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
 ```
 
 ```shell
@@ -741,37 +822,37 @@ Name:                         test
 Namespace:                    myspace
 Resource                      Used  Hard
 --------                      ----  ----
-count/deployments.extensions  1     2
+count/deployments.apps        1     2
 count/pods                    2     3
-count/replicasets.extensions  1     4
+count/replicasets.apps        1     4
 count/secrets                 1     4
 ```
 
 <!--
 ## Quota and Cluster Capacity
 
-`ResourceQuotas` are independent of the cluster capacity. They are
+ResourceQuotas are independent of the cluster capacity. They are
 expressed in absolute units.  So, if you add nodes to your cluster, this does *not*
 automatically give each namespace the ability to consume more resources.
 -->
 ## 配额和集群容量   {#quota-and-cluster-capacity}
 
-资源配额与集群资源总量是完全独立的。它们通过绝对的单位来配置。
+ResourceQuota 与集群资源总量是完全独立的。它们通过绝对的单位来配置。
 所以，为集群添加节点时，资源配额*不会*自动赋予每个命名空间消耗更多资源的能力。
 
 <!--
 Sometimes more complex policies may be desired, such as:
 
-  - Proportionally divide total cluster resources among several teams.
-  - Allow each tenant to grow resource usage as needed, but have a generous
-    limit to prevent accidental resource exhaustion.
-  - Detect demand from one namespace, add nodes, and increase quota.
+- Proportionally divide total cluster resources among several teams.
+- Allow each tenant to grow resource usage as needed, but have a generous
+  limit to prevent accidental resource exhaustion.
+- Detect demand from one namespace, add nodes, and increase quota.
 -->
 有时可能需要资源配额支持更复杂的策略，比如：
 
-  - 在几个团队中按比例划分总的集群资源。
-  - 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止资源意外耗尽。
-  - 探测某个命名空间的需求，添加物理节点并扩大资源配额值。
+- 在几个团队中按比例划分总的集群资源。
+- 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止资源意外耗尽。
+- 探测某个命名空间的需求，添加物理节点并扩大资源配额值。
 
 <!--
 Such policies could be implemented using `ResourceQuotas` as building blocks, by
@@ -790,7 +871,8 @@ restrictions around nodes: pods from several namespaces may run on the same node
 <!--
 ## Limit Priority Class consumption by default
 
-It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists.
+It may be desired that pods at a particular priority, eg. "cluster-services",
+should be allowed in a namespace, if and only if, a matching quota object exists.
 -->
 ## 默认情况下限制特定优先级的资源消耗
 
@@ -798,18 +880,19 @@ It may be desired that pods at a particular priority, eg. "cluster-services", sh
 （例如 "cluster-services"）的 Pod。
 
 <!--
-With this mechanism, operators will be able to restrict usage of certain high priority classes to a limited number of namespaces and not every namespace will be able to consume these priority classes by default.
+With this mechanism, operators will be able to restrict usage of certain high
+priority classes to a limited number of namespaces and not every namespace
+will be able to consume these priority classes by default.
 -->
 通过这种机制，操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中，
 而并非每个命名空间默认情况下都能够使用这些优先级类。
 
 <!--
-To enforce this, kube-apiserver flag `-admission-control-config-file` should be used to pass path to the following configuration file:
+To enforce this, kube-apiserver flag `-admission-control-config-file` should be
+used to pass path to the following configuration file:
 -->
 要实现此目的，应使用 kube-apiserver 标志 `--admission-control-config-file` 传递如下配置文件的路径：
 
-{{< tabs name="example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
 apiVersion: apiserver.config.k8s.io/v1
 kind: AdmissionConfiguration
@@ -825,27 +908,6 @@ plugins:
         operator: In
         values: ["cluster-services"]
 ```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# 在 Kubernetes 1.17 中已不推荐使用，请使用 apiserver.config.k8s.io/v1
-apiVersion: apiserver.k8s.io/v1alpha1
-kind: AdmissionConfiguration
-plugins:
-- name: "ResourceQuota"
-  configuration:
-    # 在 Kubernetes 1.17 中已不推荐使用，请使用 apiserver.config.k8s.io/v1, ResourceQuotaConfiguration
-    apiVersion: resourcequota.admission.k8s.io/v1beta1
-    kind: Configuration
-    limitedResources:
-    - resource: pods
-      matchScopes:
-      - scopeName: PriorityClass
-        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.
@@ -864,25 +926,17 @@ For example:
         values: ["cluster-services"]
 ```
 
-<!--
-See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information.
--->
-有关更多信息，请参见 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) 和
-[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
-
-<!--
-## Example
-
-See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
--->
-## 示例
-
-查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。
-
 ## {{% heading "whatsnext" %}}
 
 <!--
 - See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
+- See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
+- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md).
+- See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
 -->
 - 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)
+- 查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。
+- 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
   了解更多信息。
+- 参阅[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
+
diff --git a/content/zh/docs/concepts/scheduling-eviction/_index.md b/content/zh/docs/concepts/scheduling-eviction/_index.md
index 742a054e40..f7388ba108 100644
--- a/content/zh/docs/concepts/scheduling-eviction/_index.md
+++ b/content/zh/docs/concepts/scheduling-eviction/_index.md
@@ -1,4 +1,5 @@
 ---
-title: "调度和驱逐(Scheduling and Eviction)"
+title: 调度和驱逐 (Scheduling and Eviction)
 weight: 90
+description: 在Kubernetes中，调度 (Scheduling) 指的是确保 Pods 匹配到合适的节点，以便 kubelet 能够运行它们。驱逐 (Eviction) 是在资源匮乏的节点上，主动让一个或多个 Pods 失效的过程。
 ---
diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
index 29dec9c016..9a50a835c8 100644
--- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -24,7 +24,7 @@ that a pod ends up on a machine with an SSD attached to it, or to co-locate pods
 services that communicate a lot into the same availability zone.
 -->
 
-你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可以需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。
+你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可能需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。
 
 <!-- body -->
 
@@ -391,11 +391,11 @@ The affinity on this pod defines one pod affinity rule and one pod anti-affinity
 while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The
 pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone
 as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run
-on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V
-such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and
+on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V
+such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and
 value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
 rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label
-having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
+having key "security" and value "S2". (If the `topologyKey` were `topology.kubernetes.io/zone` then
 it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
 label having key "security" and value "S2".) See the
 [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
@@ -403,7 +403,7 @@ for many more examples of pod affinity and anti-affinity, both the `requiredDuri
 flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
 -->
 
-在这个 pod 的 affinity 配置定义了一条 pod 亲和规则和一条 pod 反亲和规则。在此示例中，`podAffinity` 配置为 `requiredDuringSchedulingIgnoredDuringExecution`，然而 `podAntiAffinity` 配置为 `preferredDuringSchedulingIgnoredDuringExecution`。pod 亲和规则表示，仅当节点和至少一个已运行且有键为“security”且值为“S1”的标签的 pod 处于同一区域时，才可以将该 pod 调度到节点上。（更确切的说，如果节点 N 具有带有键 `failure-domain.beta.kubernetes.io/zone` 和某个值 V 的标签，则 pod 有资格在节点 N 上运行，以便集群中至少有一个节点具有键 `failure-domain.beta.kubernetes.io/zone` 和值为 V 的节点正在运行具有键“security”和值“S1”的标签的 pod。）pod 反亲和规则表示，如果节点已经运行了一个具有键“security”和值“S2”的标签的 pod，则该 pod 不希望将其调度到该节点上。（如果 `topologyKey` 为 `failure-domain.beta.kubernetes.io/zone`，则意味着当节点和具有键“security”和值“S2”的标签的 pod 处于相同的区域，pod 不能被调度到该节点上。）查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)来获取更多 pod 亲和与反亲和的样例，包括 `requiredDuringSchedulingIgnoredDuringExecution`
+在这个 pod 的 affinity 配置定义了一条 pod 亲和规则和一条 pod 反亲和规则。在此示例中，`podAffinity` 配置为 `requiredDuringSchedulingIgnoredDuringExecution`，然而 `podAntiAffinity` 配置为 `preferredDuringSchedulingIgnoredDuringExecution`。pod 亲和规则表示，仅当节点和至少一个已运行且有键为“security”且值为“S1”的标签的 pod 处于同一区域时，才可以将该 pod 调度到节点上。（更确切的说，如果节点 N 具有带有键 `topology.kubernetes.io/zone` 和某个值 V 的标签，则 pod 有资格在节点 N 上运行，以便集群中至少有一个节点具有键 `topology.kubernetes.io/zone` 和值为 V 的节点正在运行具有键“security”和值“S1”的标签的 pod。）pod 反亲和规则表示，如果节点已经运行了一个具有键“security”和值“S2”的标签的 pod，则该 pod 不希望将其调度到该节点上。（如果 `topologyKey` 为 `topology.kubernetes.io/zone`，则意味着当节点和具有键“security”和值“S2”的标签的 pod 处于相同的区域，pod 不能被调度到该节点上。）查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)来获取更多 pod 亲和与反亲和的样例，包括 `requiredDuringSchedulingIgnoredDuringExecution`
 和 `preferredDuringSchedulingIgnoredDuringExecution` 两种配置。
 
 <!--
@@ -423,13 +423,13 @@ for performance and security reasons, there are some constraints on topologyKey:
 1. For affinity and for `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity,
 empty `topologyKey` is not allowed.
 2. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it.
-3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is interpreted as "all topologies" ("all topologies" here is now limited to the combination of `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` and `failure-domain.beta.kubernetes.io/region`).
+3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is interpreted as "all topologies" ("all topologies" here is now limited to the combination of `kubernetes.io/hostname`, `topology.kubernetes.io/zone` and `topology.kubernetes.io/region`).
 4. Except for the above cases, the `topologyKey` can be any legal label-key.
 -->
 
 1. 对于亲和与 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，`topologyKey` 不允许为空。
 2. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，准入控制器 `LimitPodHardAntiAffinityTopology` 被引入来限制 `topologyKey` 不为 `kubernetes.io/hostname`。如果你想使它可用于自定义拓扑结构，你必须修改准入控制器或者禁用它。
-3. 对于 `preferredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，空的 `topologyKey` 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为 `kubernetes.io/hostname`，`failure-domain.beta.kubernetes.io/zone` 和 `failure-domain.beta.kubernetes.io/region` 的组合）。
+3. 对于 `preferredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，空的 `topologyKey` 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为 `kubernetes.io/hostname`，`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region` 的组合）。
 4. 除上述情况外，`topologyKey` 可以是任何合法的标签键。
 
 <!--
diff --git a/content/zh/docs/concepts/scheduling-eviction/eviction-policy.md b/content/zh/docs/concepts/scheduling-eviction/eviction-policy.md
new file mode 100644
index 0000000000..769d27dcd0
--- /dev/null
+++ b/content/zh/docs/concepts/scheduling-eviction/eviction-policy.md
@@ -0,0 +1,47 @@
+---
+title: 驱逐策略
+content_type: concept
+weight: 60
+---
+<!--
+title: Eviction Policy
+content_type: concept
+weight: 60
+-->
+
+<!-- overview -->
+<!--
+This page is an overview of Kubernetes' policy for eviction.
+-->
+本页提供 Kubernetes 驱逐策略的概览。
+
+<!-- body -->
+
+<!--
+## Eviction Policy
+
+The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} proactively monitors for
+and prevents total starvation of a compute resource. In those cases, the `kubelet` can reclaim
+the starved resource by failing one or more Pods. When the `kubelet` fails
+a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
+If the evicted Pod is managed by a Deployment, the Deployment creates another Pod
+to be scheduled by Kubernetes.
+-->
+## 驱逐策略  {#eviction-policy}
+
+{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 主动监测和防止
+计算资源的全面短缺。在资源短缺时，`kubelet` 可以主动地结束一个或多个 Pod
+以回收短缺的资源。
+当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase`
+将变为 `Failed`。
+如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给
+Kubernetes 来调度。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- Learn how to [configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) with eviction signals and thresholds.
+-->
+- 阅读[配置资源不足的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，
+  进一步了解驱逐信号和阈值。
+
diff --git a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
index 7d0e65d619..f908ae1251 100644
--- a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -5,11 +5,9 @@ weight: 50
 ---
 
 <!--
----
 title: Kubernetes Scheduler
 content_type: concept
 weight: 50
----
 -->
 <!-- overview -->
 
@@ -140,13 +138,13 @@ of the scheduler:
 <!-- 
 1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to
   configure _Predicates_ for filtering and _Priorities_ for scoring.
-1. [Scheduling Profiles](/docs/reference/scheduling/profiles) allow you to
+1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you to
   configure Plugins that implement different scheduling stages, including:
   `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
   can also configure the kube-scheduler to run different profiles.
  -->
-1. [调度策略](/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。
-2. [调度配置](/docs/reference/scheduling/profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。
+1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。
+2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。
 
 
 ## {{% heading "whatsnext" %}}
@@ -158,7 +156,7 @@ of the scheduler:
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
 * Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
-* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
+* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
 -->
 
 * 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
@@ -166,5 +164,5 @@ of the scheduler:
 * 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
 * 了解关于 [配置多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式
 * 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
-* 了解关于 [Pod 额外开销](/zh/docs/concepts/configuration/pod-overhead/)
+* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
 
diff --git a/content/zh/docs/concepts/configuration/pod-overhead.md b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md
similarity index 95%
rename from content/zh/docs/concepts/configuration/pod-overhead.md
rename to content/zh/docs/concepts/scheduling-eviction/pod-overhead.md
index 4f785b152e..98febf6328 100644
--- a/content/zh/docs/concepts/configuration/pod-overhead.md
+++ b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md
@@ -1,306 +1,306 @@
----
-title: Pod 开销
-content_type: concept
-weight: 20
----
-
-<!-- overview -->
-
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
-
-<!--
-When you run a Pod on a Node, the Pod itself takes an amount of system resources. These
-resources are additional to the resources needed to run the container(s) inside the Pod.
-_Pod Overhead_ is a feature for accounting for the resources consumed by the Pod infrastructure
-on top of the container requests & limits.
--->
-
-在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。
-_POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。
-
-<!-- body -->
-
-<!--
-## Pod Overhead
--->
-
-## Pod 开销
-
-<!--
-In Kubernetes, the Pod's overhead is set at
-[admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
-time according to the overhead associated with the Pod's
-[RuntimeClass](/docs/concepts/containers/runtime-class/).
--->
-
-在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 相关联的开销在
-[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。
-
-<!--
-When Pod Overhead is enabled, the overhead is considered in addition to the sum of container
-resource requests when scheduling a Pod. Similarly, Kubelet will include the Pod overhead when sizing
-the Pod cgroup, and when carrying out Pod eviction ranking.
--->
-当启用 Pod 开销时，在调度 Pod 时，除了考虑容器资源请求的总和外，还要考虑 Pod 开销。类似地，Kubelet 将在确定 Pod cgroup 的大小和执行 Pod 驱逐排序时包含 Pod 开销。
-
-<!--
-## Enabling Pod Overhead {#set-up}
--->
-## 启用 Pod 开销 {#set-up}
-
-<!--
-You need to make sure that the `PodOverhead`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is on by default as of 1.18)
-across your cluster, and a `RuntimeClass` is utilized which defines the `overhead` field.
--->
-您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
-（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。
-
-<!-- 
-## Usage example
--->
-## 使用示例
-
-<!--
-To use the PodOverhead feature, you need a RuntimeClass that defines the `overhead` field. As
-an example, you could use the following RuntimeClass definition with a virtualizing container runtime
-that uses around 120MiB per Pod for the virtual machine and the guest OS:
--->
-要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass。
-作为例子，可以在虚拟机和寄宿操作系统中通过一个虚拟化容器运行时来定义
-RuntimeClass 如下，其中每个 Pod 大约使用 120MiB:
-
-```yaml
----
-kind: RuntimeClass
-apiVersion: node.k8s.io/v1beta1
-metadata:
-    name: kata-fc
-handler: kata-fc
-overhead:
-    podFixed:
-        memory: "120Mi"
-        cpu: "250m"
-```
-
-<!-- 
-Workloads which are created which specify the `kata-fc` RuntimeClass handler will take the memory and
-cpu overheads into account for resource quota calculations, node scheduling, as well as Pod cgroup sizing.
-
-Consider running the given example workload, test-pod:
--->
-通过指定 `kata-fc` RuntimeClass 处理程序创建的工作负载会将内存和 cpu 开销计入资源配额计算、节点调度以及 Pod cgroup 分级。
-
-假设我们运行下面给出的工作负载示例 test-pod:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: test-pod
-spec:
-  runtimeClassName: kata-fc
-  containers:
-  - name: busybox-ctr
-    image: busybox
-    stdin: true
-    tty: true
-    resources:
-      limits:
-        cpu: 500m
-        memory: 100Mi
-  - name: nginx-ctr
-    image: nginx
-    resources:
-      limits:
-        cpu: 1500m
-        memory: 100Mi
-```
-
-<!-- 
-At admission time the RuntimeClass [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
-updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
-the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
-to include an `overhead`.
--->
-在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含
- RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。
-在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`.
-
-<!-- 
-After the RuntimeClass admission controller, you can check the updated PodSpec:
--->
-在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec:
-
-```bash
-kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
-```
-
-<!-- 
-The output is:
--->
-输出：
-```
-map[cpu:250m memory:120Mi]
-```
-
-<!-- 
-If a ResourceQuota is defined, the sum of container requests as well as the
-`overhead` field are counted.
- -->
-如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。
-
-<!-- 
-When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's
-`overhead` as well as the sum of container requests for that Pod. For this example, the scheduler adds the
-requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB of memory available.
--->
-当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。
-
-<!-- 
-Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
-for the Pod. It is within this pod that the underlying container runtime will create containers. -->
-一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。
-
-<!-- 
-If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined),
-the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU
-and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead`
-defined in the PodSpec.
--->
-如果该资源对每一个容器都定义了一个限制（定义了受限的 Guaranteed QoS 或者 Bustrable QoS），kubelet 会为与该资源（CPU 的 cpu.cfs_quota_us 以及内存的 memory.limit_in_bytes）
-相关的 pod cgroup 设定一个上限。该上限基于容器限制总量与 PodSpec 中定义的 `overhead` 之和。
-
-<!--
-For CPU, if the Pod is Guaranteed or Burstable QoS, the kubelet will set `cpu.shares` based on the sum of container
-requests plus the `overhead` defined in the PodSpec.
--->
-对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`.
-
-<!-- 
-Looking at our example, verify the container requests for the workload:
--->
-请看这个例子，验证工作负载的容器请求：
-```bash
-kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
-```
-
-<!-- 
-The total container requests are 2000m CPU and 200MiB of memory:
--->
-容器请求总计 2000m CPU 和 200MiB 内存：
-```
-map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
-```
-
-<!-- 
-Check this against what is observed by the node:
- -->
-对照从节点观察到的情况来检查一下：
-```bash
-kubectl describe node | grep test-pod -B2
-```
-
-<!-- 
-The output shows 2250m CPU and 320MiB of memory are requested, which includes PodOverhead:
- -->
-该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内：
-```
-  Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
-  ---------                   ----                ------------  ----------   ---------------  -------------  ---
-  default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m
-```
-
-<!--
-## Verify Pod cgroup limits
--->
-## 验证 Pod cgroup 限制
-
-<!--
-Check the Pod's memory cgroups on the node where the workload is running. In the following example, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)
-is used on the node, which provides a CLI for CRI-compatible container runtimes. This is an
-advanced example to show PodOverhead behavior, and it is not expected that users should need to check
-cgroups directly on the node.
-
-First, on the particular node, determine the Pod identifier:ying
--->
-在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中，将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). 
-这是一个展示 PodOverhead 行为的进阶示例，用户并不需要直接在该节点上检查 cgroups.
-
-首先在特定的节点上确定该 Pod 的标识符：ying
-
-<!--
-```bash
-# Run this on the node where the Pod is scheduled
--->
-```bash
-# 在该 Pod 调度的节点上执行如下命令：
-POD_ID="$(sudo crictl pods --name test-pod -q)"
-```
-
-<!-- 
-From this, you can determine the cgroup path for the Pod:
- -->
-可以依此判断该 Pod 的 cgroup 路径：
-
-<!--
-```bash
-# Run this on the node where the Pod is scheduled
--->
-```bash
-# 在该 Pod 调度的节点上执行如下命令：
-sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
-```
-
-<!-- 
-The resulting cgroup path includes the Pod's `pause` container. The Pod level cgroup is one directory above.
--->
-执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。
-```
-        "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
-```
-
-<!-- 
-In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verify the Pod level cgroup setting for memory:
- -->
-在这个例子中，该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置：
-
-<!--
-```bash
-# Run this on the node where the Pod is scheduled.
-# Also, change the name of the cgroup to match the cgroup allocated for your pod.
--->
-```bash
-# 在该 Pod 调度的节点上执行这个命令。
-# 另外，修改 cgroup 的名称以匹配为该 pod 分配的 cgroup。
- cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
-```
-
-<!-- 
-This is 320 MiB, as expected:
--->
-和预期的一样是 320 MiB
-```
-335544320
-```
-
-<!-- 
-### Observability
--->
-### 可观察性
-
-<!--
-A `kube_pod_overhead` metric is available in [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
-to help identify when PodOverhead is being utilized and to help observe stability of workloads
-running with a defined Overhead. This functionality is not available in the 1.9 release of
-kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
-from source in the meantime.
--->
-在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。
-该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. 
-
-## {{% heading "whatsnext" %}}
-
-* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
-* [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
-
+---
+title: Pod 开销
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+<!--
+When you run a Pod on a Node, the Pod itself takes an amount of system resources. These
+resources are additional to the resources needed to run the container(s) inside the Pod.
+_Pod Overhead_ is a feature for accounting for the resources consumed by the Pod infrastructure
+on top of the container requests & limits.
+-->
+
+在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。
+_POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。
+
+<!-- body -->
+
+<!--
+## Pod Overhead
+-->
+
+## Pod 开销
+
+<!--
+In Kubernetes, the Pod's overhead is set at
+[admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
+time according to the overhead associated with the Pod's
+[RuntimeClass](/docs/concepts/containers/runtime-class/).
+-->
+
+在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 相关联的开销在
+[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。
+
+<!--
+When Pod Overhead is enabled, the overhead is considered in addition to the sum of container
+resource requests when scheduling a Pod. Similarly, Kubelet will include the Pod overhead when sizing
+the Pod cgroup, and when carrying out Pod eviction ranking.
+-->
+当启用 Pod 开销时，在调度 Pod 时，除了考虑容器资源请求的总和外，还要考虑 Pod 开销。类似地，Kubelet 将在确定 Pod cgroup 的大小和执行 Pod 驱逐排序时包含 Pod 开销。
+
+<!--
+## Enabling Pod Overhead {#set-up}
+-->
+## 启用 Pod 开销 {#set-up}
+
+<!--
+You need to make sure that the `PodOverhead`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is on by default as of 1.18)
+across your cluster, and a `RuntimeClass` is utilized which defines the `overhead` field.
+-->
+您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。
+
+<!-- 
+## Usage example
+-->
+## 使用示例
+
+<!--
+To use the PodOverhead feature, you need a RuntimeClass that defines the `overhead` field. As
+an example, you could use the following RuntimeClass definition with a virtualizing container runtime
+that uses around 120MiB per Pod for the virtual machine and the guest OS:
+-->
+要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass。
+作为例子，可以在虚拟机和寄宿操作系统中通过一个虚拟化容器运行时来定义
+RuntimeClass 如下，其中每个 Pod 大约使用 120MiB:
+
+```yaml
+---
+kind: RuntimeClass
+apiVersion: node.k8s.io/v1beta1
+metadata:
+    name: kata-fc
+handler: kata-fc
+overhead:
+    podFixed:
+        memory: "120Mi"
+        cpu: "250m"
+```
+
+<!-- 
+Workloads which are created which specify the `kata-fc` RuntimeClass handler will take the memory and
+cpu overheads into account for resource quota calculations, node scheduling, as well as Pod cgroup sizing.
+
+Consider running the given example workload, test-pod:
+-->
+通过指定 `kata-fc` RuntimeClass 处理程序创建的工作负载会将内存和 cpu 开销计入资源配额计算、节点调度以及 Pod cgroup 分级。
+
+假设我们运行下面给出的工作负载示例 test-pod:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-pod
+spec:
+  runtimeClassName: kata-fc
+  containers:
+  - name: busybox-ctr
+    image: busybox
+    stdin: true
+    tty: true
+    resources:
+      limits:
+        cpu: 500m
+        memory: 100Mi
+  - name: nginx-ctr
+    image: nginx
+    resources:
+      limits:
+        cpu: 1500m
+        memory: 100Mi
+```
+
+<!-- 
+At admission time the RuntimeClass [admission controller](/docs/reference/access-authn-authz/admission-controllers/)
+updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
+the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
+to include an `overhead`.
+-->
+在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含
+ RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。
+在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`.
+
+<!-- 
+After the RuntimeClass admission controller, you can check the updated PodSpec:
+-->
+在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec:
+
+```bash
+kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
+```
+
+<!-- 
+The output is:
+-->
+输出：
+```
+map[cpu:250m memory:120Mi]
+```
+
+<!-- 
+If a ResourceQuota is defined, the sum of container requests as well as the
+`overhead` field are counted.
+ -->
+如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。
+
+<!-- 
+When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's
+`overhead` as well as the sum of container requests for that Pod. For this example, the scheduler adds the
+requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB of memory available.
+-->
+当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。
+
+<!-- 
+Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
+for the Pod. It is within this pod that the underlying container runtime will create containers. -->
+一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。
+
+<!-- 
+If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined),
+the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU
+and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead`
+defined in the PodSpec.
+-->
+如果该资源对每一个容器都定义了一个限制（定义了受限的 Guaranteed QoS 或者 Bustrable QoS），kubelet 会为与该资源（CPU 的 cpu.cfs_quota_us 以及内存的 memory.limit_in_bytes）
+相关的 pod cgroup 设定一个上限。该上限基于容器限制总量与 PodSpec 中定义的 `overhead` 之和。
+
+<!--
+For CPU, if the Pod is Guaranteed or Burstable QoS, the kubelet will set `cpu.shares` based on the sum of container
+requests plus the `overhead` defined in the PodSpec.
+-->
+对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`.
+
+<!-- 
+Looking at our example, verify the container requests for the workload:
+-->
+请看这个例子，验证工作负载的容器请求：
+```bash
+kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
+```
+
+<!-- 
+The total container requests are 2000m CPU and 200MiB of memory:
+-->
+容器请求总计 2000m CPU 和 200MiB 内存：
+```
+map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
+```
+
+<!-- 
+Check this against what is observed by the node:
+ -->
+对照从节点观察到的情况来检查一下：
+```bash
+kubectl describe node | grep test-pod -B2
+```
+
+<!-- 
+The output shows 2250m CPU and 320MiB of memory are requested, which includes PodOverhead:
+ -->
+该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内：
+```
+  Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
+  ---------                   ----                ------------  ----------   ---------------  -------------  ---
+  default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m
+```
+
+<!--
+## Verify Pod cgroup limits
+-->
+## 验证 Pod cgroup 限制
+
+<!--
+Check the Pod's memory cgroups on the node where the workload is running. In the following example, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)
+is used on the node, which provides a CLI for CRI-compatible container runtimes. This is an
+advanced example to show PodOverhead behavior, and it is not expected that users should need to check
+cgroups directly on the node.
+
+First, on the particular node, determine the Pod identifier:
+-->
+在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中，将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). 
+这是一个展示 PodOverhead 行为的进阶示例，用户并不需要直接在该节点上检查 cgroups.
+
+首先在特定的节点上确定该 Pod 的标识符：
+
+<!--
+```bash
+# Run this on the node where the Pod is scheduled
+-->
+```bash
+# 在该 Pod 调度的节点上执行如下命令：
+POD_ID="$(sudo crictl pods --name test-pod -q)"
+```
+
+<!-- 
+From this, you can determine the cgroup path for the Pod:
+ -->
+可以依此判断该 Pod 的 cgroup 路径：
+
+<!--
+```bash
+# Run this on the node where the Pod is scheduled
+-->
+```bash
+# 在该 Pod 调度的节点上执行如下命令：
+sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
+```
+
+<!-- 
+The resulting cgroup path includes the Pod's `pause` container. The Pod level cgroup is one directory above.
+-->
+执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。
+```
+        "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
+```
+
+<!-- 
+In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verify the Pod level cgroup setting for memory:
+ -->
+在这个例子中，该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置：
+
+<!--
+```bash
+# Run this on the node where the Pod is scheduled.
+# Also, change the name of the cgroup to match the cgroup allocated for your pod.
+-->
+```bash
+# 在该 Pod 调度的节点上执行这个命令。
+# 另外，修改 cgroup 的名称以匹配为该 pod 分配的 cgroup。
+ cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
+```
+
+<!-- 
+This is 320 MiB, as expected:
+-->
+和预期的一样是 320 MiB
+```
+335544320
+```
+
+<!-- 
+### Observability
+-->
+### 可观察性
+
+<!--
+A `kube_pod_overhead` metric is available in [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
+to help identify when PodOverhead is being utilized and to help observe stability of workloads
+running with a defined Overhead. This functionality is not available in the 1.9 release of
+kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
+from source in the meantime.
+-->
+在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。
+该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. 
+
+## {{% heading "whatsnext" %}}
+
+* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
+* [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
+
diff --git a/content/zh/docs/concepts/configuration/resource-bin-packing.md b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
similarity index 79%
rename from content/zh/docs/concepts/configuration/resource-bin-packing.md
rename to content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
index dd4584c989..d9edf508ff 100644
--- a/content/zh/docs/concepts/configuration/resource-bin-packing.md
+++ b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -26,23 +26,25 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
 <!--
 ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
 
-Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
+Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
 consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
 -->
 
 ## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱
 
-在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量
-之比率对节点评分。
+在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）
+的请求数量和可用容量 之比率对节点评分。
 Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重，
 以便根据请求数量与可用容量之比率为节点评分。
 这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。
 `RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为
 `requestedToCapacityRatioArguments` 的配置选项进行控制。
 该标志由两个参数 `shape` 和 `resources` 组成。
-shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或
+`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求
+（least requested）或
 最多请求（most requested）计算。
-resources 由 `name` 和  `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 
+`resources` 包含由 `name` 和  `weight` 组成，`name` 指定评分时要考虑的资源，
+`weight` 指定每种资源的权重。 
 
 <!--
 Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
@@ -53,29 +55,29 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
 
 ```json
 {
-    "kind" : "Policy",
-    "apiVersion" : "v1",
-    ...
-    "priorities" : [
-       ...
-      {
-        "name": "RequestedToCapacityRatioPriority",
-        "weight": 2,
-        "argument": {
-          "requestedToCapacityRatioArguments": {
-            "shape": [
-              {"utilization": 0, "score": 0},
-              {"utilization": 100, "score": 10}
-            ],
-            "resources": [
-              {"name": "intel.com/foo", "weight": 3},
-              {"name": "intel.com/bar", "weight": 5}
-            ]
-          }
+  "kind": "Policy",
+  "apiVersion": "v1",
+  ...
+  "priorities": [
+     ...
+    {
+      "name": "RequestedToCapacityRatioPriority",
+      "weight": 2,
+      "argument": {
+        "requestedToCapacityRatioArguments": {
+          "shape": [
+            {"utilization": 0, "score": 0},
+            {"utilization": 100, "score": 10}
+          ],
+          "resources": [
+            {"name": "intel.com/foo", "weight": 3},
+            {"name": "intel.com/bar", "weight": 5}
+          ]
         }
       }
-    ],
-  }
+    }
+  ],
+}
 ```
 
 <!--
@@ -89,7 +91,6 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
 
 `shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
 -->
-
 ### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数
 
 `shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。
@@ -103,8 +104,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
 The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
 -->
 
-上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10，
-因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。
+上面的参数在 `utilization` 为 0% 时给节点评分为 0，在 `utilization` 为
+100% 时给节点评分为 10，因此启用了装箱行为。
+要启用最少请求（least requested）模式，必须按如下方式反转得分值。
 
 ```yaml
  {"utilization": 0, "score": 100},
@@ -223,7 +225,7 @@ NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
 
 intel.com/foo  = resourceScoringFunction((2+2),8)
                = (100 - ((8-4)*100/8)
-               = (100 - 25)
+               = (100 - 50)
                = 50
                = rawScoringFunction(50)
                = 5
diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
index 0efa384a27..e10b5b8854 100644
--- a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@@ -1,14 +1,14 @@
 ---
 title: 调度器性能调优
 content_type: concept
-weight: 70
+weight: 80
 ---
 <!--
 reviewers:
 - bsalamat
 title: Scheduler Performance Tuning
 content_type: concept
-weight: 70
+weight: 80
 -->
 
 <!-- overview -->
@@ -54,7 +54,8 @@ You configure this tuning setting via kube-scheduler setting
 `percentageOfNodesToScore`. This KubeSchedulerConfiguration setting determines
 a threshold for scheduling nodes in your cluster.
  -->
-在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）和精度（调度器很少做出糟糕的放置决策）。
+在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）
+和精度（调度器很少做出糟糕的放置决策）。
 
 你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。
 这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。
@@ -71,33 +72,32 @@ should use its compiled-in default.
 If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you
 had set a value of 100.
  -->
-`percentageOfNodesToScore` 选项接受从 0 到 100 之间的整数值。0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。
-如果你设置 `percentageOfNodesToScore` 的值超过了 100，kube-scheduler 的表现等价于设置值为 100。
+`percentageOfNodesToScore` 选项接受从 0 到 100 之间的整数值。
+0 值比较特殊，表示 kube-scheduler 应该使用其编译后的默认值。
+如果你设置 `percentageOfNodesToScore` 的值超过了 100，
+kube-scheduler 的表现等价于设置值为 100。
 
 <!-- 
 To change the value, edit the kube-scheduler configuration file (this is likely
 to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
  -->
-要修改这个值，编辑 kube-scheduler 的配置文件（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），然后重启调度器。
+要修改这个值，编辑 kube-scheduler 的配置文件
+（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），
+然后重启调度器。
 
 <!-- 
 After you have made this change, you can run
  -->
 修改完成后，你可以执行
+
 ```bash
-kubectl get componentstatuses
+kubectl get pods -n kube-system | grep kube-scheduler
 ```
 
 <!-- 
-to verify that the kube-scheduler component is healthy. The output is similar to:
+to verify that the kube-scheduler component is healthy.
  -->
-来检查该 kube-scheduler 组件是否健康。输出类似如下：
-```
-NAME                 STATUS    MESSAGE             ERROR
-controller-manager   Healthy   ok
-scheduler            Healthy   ok
-...
-```
+来检查该 kube-scheduler 组件是否健康。
 
 <!-- 
 ## Node scoring threshold {#percentage-of-nodes-to-score}
@@ -109,7 +109,8 @@ To improve scheduling performance, the kube-scheduler can stop looking for
 feasible nodes once it has found enough of them. In large clusters, this saves
 time compared to a naive approach that would consider every node.
  -->
-要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。
+要提升调度性能，kube-scheduler 可以在找到足够的可调度节点之后停止查找。
+在大规模集群中，比起考虑每个节点的简单方法相比可以节省时间。
 
 <!-- 
 You specify a threshold for how many nodes are enough, as a whole number percentage
@@ -141,8 +142,8 @@ If you don't specify a threshold, Kubernetes calculates a figure using a
 linear formula that yields 50% for a 100-node cluster and yields 10%
 for a 5000-node cluster. The lower bound for the automatic value is 5%.
  -->
-如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-node 集群下取 50%，在 5000-node 的集群下取 10%。
-这个自动设置的参数的最低值是 5%。
+如果你不指定阈值，Kubernetes 使用线性公式计算出一个比例，在 100-节点集群
+下取 50%，在 5000-节点的集群下取 10%。这个自动设置的参数的最低值是 5%。
 
 <!-- 
 This means that, the kube-scheduler always scores at least 5% of your cluster no
@@ -205,12 +206,14 @@ scheduler's performance significantly.
 {{< /note >}}
 -->
 {{< note >}}
-当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，因为可调度节点太少，不足以停止调度器最初的过滤选择。
+当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
+因为可调度节点太少，不足以停止调度器最初的过滤选择。
 
-同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为一个较低的值，则没有或者只有很小的效果。
-
-如果集群只有几百个节点或者更少，请保持这个配置的默认值。改变基本不会对调度器的性能有明显的提升。
+同理，在小规模集群中，如果你将 `percentageOfNodesToScore` 设置为
+一个较低的值，则没有或者只有很小的效果。
 
+如果集群只有几百个节点或者更少，请保持这个配置的默认值。
+改变基本不会对调度器的性能有明显的提升。
 {{< /note >}}
 
 <!--
@@ -226,9 +229,15 @@ percentage to anything below 10%, unless the scheduler's throughput is critical
 for your application and the score of nodes is not important. In other words, you
 prefer to run the Pod on any Node as long as it is feasible.
 -->
-值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，很多 node 都没有进入到打分阶段。这样就会造成一种后果，一个本来可以在打分阶段得分很高的 Node 甚至都不能进入打分阶段。
+值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，
+很多节点都没有进入到打分阶段。这样就会造成一种后果，
+一个本来可以在打分阶段得分很高的节点甚至都不能进入打分阶段。
 
-由于这个原因，这个参数不应该被设置成一个很低的值。通常的做法是不会将这个参数的值设置的低于 10。很低的参数值一般在调度器的吞吐量很高且对 node 的打分不重要的情况下才使用。换句话说，只有当你更倾向于在可调度节点中任意选择一个 Node 来运行这个 Pod 时，才使用很低的参数设置。
+由于这个原因，这个参数不应该被设置成一个很低的值。
+通常的做法是不会将这个参数的值设置的低于 10。
+很低的参数值一般在调度器的吞吐量很高且对节点的打分不重要的情况下才使用。
+换句话说，只有当你更倾向于在可调度节点中任意选择一个节点来运行这个 Pod 时，
+才使用很低的参数设置。
 
 <!--
 ### How the scheduler iterates over Nodes
@@ -250,14 +259,20 @@ Nodes as specified by `percentageOfNodesToScore`. For the next Pod, the
 scheduler continues from the point in the Node array that it stopped at when
 checking feasibility of Nodes for the previous Pod.
 -->
-在将 Pod 调度到 Node 上时，为了让集群中所有 Node 都有公平的机会去运行这些 Pod，调度器将会以轮询的方式覆盖全部的 Node。你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，将会来作为这次调度筛选 Node 开始的位置。
+在将 Pod 调度到节点上时，为了让集群中所有节点都有公平的机会去运行这些 Pod，
+调度器将会以轮询的方式覆盖全部的 Node。
+你可以将 Node 列表想象成一个数组。调度器从数组的头部开始筛选可调度节点，
+依次向后直到可调度节点的数量达到 `percentageOfNodesToScore` 参数的要求。
+在对下一个 Pod 进行调度的时候，前一个 Pod 调度筛选停止的 Node 列表的位置，
+将会来作为这次调度筛选 Node 开始的位置。
 
 <!--
 If Nodes are in multiple zones, the scheduler iterates over Nodes in various
 zones to ensure that Nodes from different zones are considered in the
 feasibility checks. As an example, consider six nodes in two zones:
 -->
-如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：
+如果集群中的 Node 在多个区域，那么调度器将从不同的区域中轮询 Node，
+来确保不同区域的 Node 接受可调度性检查。如下例，考虑两个区域中的六个节点：
 
 ```
 Zone 1: Node 1, Node 2, Node 3, Node 4
@@ -278,4 +293,3 @@ After going over all the Nodes, it goes back to Node 1.
 -->
 在评估完所有 Node 后，将会返回到 Node 1，从头开始。
 
-
diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
index d62f206d76..4e85bb9a38 100644
--- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
+++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
@@ -3,17 +3,15 @@ reviewers:
 - ahg-g
 title: 调度框架
 content_type: concept
-weight: 60
+weight: 70
 ---
 
 <!--
----
 reviewers:
 - ahg-g
 title: Scheduling Framework
 content_type: concept
 weight: 60
----
 -->
 
 <!-- overview -->
@@ -29,19 +27,17 @@ scheduling "core" simple and maintainable. Refer to the [design proposal of the
 scheduling framework][kep] for more technical information on the design of the
 framework.
 -->
-
-调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。请参考[调度框架的设计提案][kep]获取框架设计的更多技术信息。
-
-[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
-
-
+调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。
+它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。
+这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。
+请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md)
+获取框架设计的更多技术信息。
 
 <!-- body -->
 
 <!--
 # Framework workflow
 -->
-
 # 框架工作流程
 
 <!--
@@ -49,20 +45,18 @@ The Scheduling Framework defines a few extension points. Scheduler plugins
 register to be invoked at one or more extension points. Some of these plugins
 can change the scheduling decisions and some are informational only.
 -->
-
-调度框架定义了一些扩展点。调度器插件注册后在一个或多个扩展点处被调用。这些插件中的一些可以改变调度决策，而另一些仅用于提供信息。
+调度框架定义了一些扩展点。调度器插件注册后在一个或多个扩展点处被调用。
+这些插件中的一些可以改变调度决策，而另一些仅用于提供信息。
 
 <!--
 Each attempt to schedule one Pod is split into two phases, the **scheduling
 cycle** and the **binding cycle**.
 -->
-
 每次调度一个 Pod 的尝试都分为两个阶段，即 **调度周期** 和 **绑定周期**。
 
 <!--
 ## Scheduling Cycle & Binding Cycle
 -->
-
 ## 调度周期和绑定周期
 
 <!--
@@ -70,13 +64,12 @@ The scheduling cycle selects a node for the Pod, and the binding cycle applies
 that decision to the cluster. Together, a scheduling cycle and binding cycle are
 referred to as a "scheduling context".
 -->
-
-调度周期为 Pod 选择一个节点，绑定周期将该决策应用于集群。调度周期和绑定周期一起被称为“调度上下文”。
+调度周期为 Pod 选择一个节点，绑定周期将该决策应用于集群。
+调度周期和绑定周期一起被称为“调度上下文”。
 
 <!--
 Scheduling cycles are run serially, while binding cycles may run concurrently.
 -->
-
 调度周期是串行运行的，而绑定周期可能是同时运行的。
 
 <!--
@@ -84,13 +77,12 @@ A scheduling or binding cycle can be aborted if the Pod is determined to
 be unschedulable or if there is an internal error. The Pod will be returned to
 the queue and retried.
 -->
-
-如果确定 Pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。Pod 将返回队列并重试。
+如果确定 Pod 不可调度或者存在内部错误，则可以终止调度周期或绑定周期。
+Pod 将返回队列并重试。
 
 <!--
 ## Extension points
 -->
-
 ## 扩展点
 
 <!--
@@ -98,14 +90,13 @@ The following picture shows the scheduling context of a Pod and the extension
 points that the scheduling framework exposes. In this picture "Filter" is
 equivalent to "Predicate" and "Scoring" is equivalent to "Priority function".
 -->
-
-下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
+下图显示了一个 Pod 的调度上下文以及调度框架公开的扩展点。
+在此图片中，“过滤器”等同于“断言”，“评分”相当于“优先级函数”。
 
 <!--
 One plugin may register at multiple extension points to perform more complex or
 stateful tasks.
 -->
-
 一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。
 
 <!-- 
@@ -113,7 +104,6 @@ stateful tasks.
 -->
 {{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}}
 
-
 <!--
 ### QueueSort {#queue-sort}
 -->
@@ -124,13 +114,13 @@ These plugins are used to sort Pods in the scheduling queue. A queue sort plugin
 essentially provides a `less(Pod1, Pod2)` function. Only one queue sort
 plugin may be enabled at a time.
 -->
-
-队列排序插件用于对调度队列中的 Pod 进行排序。队列排序插件本质上提供 "less(Pod1, Pod2)" 函数。一次只能启动一个队列插件。
+队列排序插件用于对调度队列中的 Pod 进行排序。
+队列排序插件本质上提供 `less(Pod1, Pod2)` 函数。
+一次只能启动一个队列插件。
 
 <!--
 ### PreFilter {#pre-filter}
 -->
-
 ### 前置过滤 {#pre-filter}
 
 <!--
@@ -138,13 +128,12 @@ These plugins are used to pre-process info about the Pod, or to check certain
 conditions that the cluster or the Pod must meet. If a PreFilter plugin returns
 an error, the scheduling cycle is aborted.
 -->
-
-前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。如果 PreFilter 插件返回错误，则调度周期将终止。
+前置过滤插件用于预处理 Pod 的相关信息，或者检查集群或 Pod 必须满足的某些条件。
+如果 PreFilter 插件返回错误，则调度周期将终止。
 
 <!--
 ### Filter
 -->
-
 ### 过滤
 
 <!--
@@ -153,8 +142,27 @@ node, the scheduler will call filter plugins in their configured order. If any
 filter plugin marks the node as infeasible, the remaining plugins will not be
 called for that node. Nodes may be evaluated concurrently.
 -->
+过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，
+调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，
+则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。
 
-过滤插件用于过滤出不能运行该 Pod 的节点。对于每个节点，调度器将按照其配置顺序调用这些过滤插件。如果任何过滤插件将节点标记为不可行，则不会为该节点调用剩下的过滤插件。节点可以被同时进行评估。
+<!--
+### PostFilter {#post-filter}
+-->
+### 后置过滤 {#post-filter}
+
+<!--
+These plugins are called after Filter phase, but only when no feasible nodes
+were found for the pod. Plugins are called in their configured order. If
+any postFilter plugin marks the node as `Schedulable`, the remaining plugins
+will not be called. A typical PostFilter implementation is preemption, which
+tries to make the pod schedulable by preempting other Pods.
+-->
+
+这些插件在筛选阶段后调用，但仅在该 Pod 没有可行的节点时调用。
+插件按其配置的顺序调用。如果任何后过滤器插件标记节点为“可调度”，
+则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 Pod
+的资源使该 Pod 可以调度。
 
 <!-- 
 ### PreScore {#pre-score}
@@ -166,7 +174,8 @@ These plugins are used to perform "pre-scoring" work, which generates a sharable
 state for Score plugins to use. If a PreScore plugin returns an error, the
 scheduling cycle is aborted.
  -->
-前置评分插件用于执行 “前置评分” 工作，即生成一个可共享状态供评分插件使用。如果 PreScore 插件返回错误，则调度周期将终止。
+前置评分插件用于执行 “前置评分” 工作，即生成一个可共享状态供评分插件使用。
+如果 PreScore 插件返回错误，则调度周期将终止。
 
 <!-- 
 ### Score {#scoring}
@@ -180,13 +189,14 @@ defined range of integers representing the minimum and maximum scores. After the
 [NormalizeScore](#normalize-scoring) phase, the scheduler will combine node
 scores from all plugins according to the configured plugin weights.
 -->
-
-评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。将有一个定义明确的整数范围，代表最小和最大分数。在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重合并所有插件的节点分数。
+评分插件用于对通过过滤阶段的节点进行排名。调度器将为每个节点调用每个评分插件。
+将有一个定义明确的整数范围，代表最小和最大分数。
+在[标准化评分](#normalize-scoring)阶段之后，调度器将根据配置的插件权重
+合并所有插件的节点分数。
 
 <!--
 ### NormalizeScore {#normalize-scoring}
 -->
-
 ### 标准化评分 {#normalize-scoring}
 
 <!--
@@ -195,14 +205,14 @@ ranking of Nodes. A plugin that registers for this extension point will be
 called with the [Score](#scoring) results from the same plugin. This is called
 once per plugin per scheduling cycle.
 -->
-
-标准化评分插件用于在调度器计算节点的排名之前修改分数。在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。每个插件在每个调度周期调用一次。
+标准化评分插件用于在调度器计算节点的排名之前修改分数。
+在此扩展点注册的插件将使用同一插件的[评分](#scoring) 结果被调用。
+每个插件在每个调度周期调用一次。
 
 <!--
 For example, suppose a plugin `BlinkingLightScorer` ranks Nodes based on how
 many blinking lights they have.
 -->
-
 例如，假设一个 `BlinkingLightScorer` 插件基于具有的闪烁指示灯数量来对节点进行排名。
 
 ```go
@@ -216,8 +226,8 @@ However, the maximum count of blinking lights may be small compared to
 `NodeScoreMax`. To fix this, `BlinkingLightScorer` should also register for this
 extension point.
 -->
-
-然而，最大的闪烁灯个数值可能比 `NodeScoreMax` 小。要解决这个问题，`BlinkingLightScorer` 插件还应该注册该扩展点。
+然而，最大的闪烁灯个数值可能比 `NodeScoreMax` 小。要解决这个问题，
+`BlinkingLightScorer` 插件还应该注册该扩展点。
 
 ```go
 func NormalizeScores(scores map[string]int) {
@@ -235,7 +245,6 @@ func NormalizeScores(scores map[string]int) {
 If any NormalizeScore plugin returns an error, the scheduling cycle is
 aborted.
 -->
-
 如果任何 NormalizeScore 插件返回错误，则调度阶段将终止。
 
 <!--
@@ -249,8 +258,7 @@ NormalizeScore extension point.
 <!--
 ### Reserve
 -->
-
-### 保留
+### Reserve
 
 <!--
 This is an informational extension point. Plugins which maintain runtime state
@@ -259,37 +267,38 @@ scheduler when resources on a node are being reserved for a given Pod. This
 happens before the scheduler actually binds the Pod to the Node, and it exists
 to prevent race conditions while the scheduler waits for the bind to succeed.
 -->
-
-保留是一个信息性的扩展点。管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便调度器在节点给指定 Pod 预留了资源时能够通知该插件。这是在调度器真正将 Pod 绑定到节点之前发生的，并且它存在是为了防止在调度器等待绑定成功时发生竞争情况。
+Reserve 是一个信息性的扩展点。
+管理运行时状态的插件（也成为“有状态插件”）应该使用此扩展点，以便
+调度器在节点给指定 Pod 预留了资源时能够通知该插件。
+这是在调度器真正将 Pod 绑定到节点之前发生的，并且它存在是为了防止
+在调度器等待绑定成功时发生竞争情况。
 
 <!--
 This is the last step in a scheduling cycle. Once a Pod is in the reserved
 state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or
 [PostBind](#post-bind) plugins (on success) at the end of the binding cycle.
 -->
-
-这个是调度周期的最后一步。一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#不保留) 插件（失败时）或
-[绑定后](#post-bind) 插件（成功时）。
+这个是调度周期的最后一步。
+一旦 Pod 处于保留状态，它将在绑定周期结束时触发[不保留](#unreserve) 插件
+（失败时）或 [绑定后](#post-bind) 插件（成功时）。
 
 <!--
 ### Permit
 -->
-
-### 允许
+### Permit
 
 <!--
 _Permit_ plugins are invoked at the end of the scheduling cycle for each Pod, to
 prevent or delay the binding to the candidate node. A permit plugin can do one of
 the three things:
 -->
-
-_Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。一个允许插件可以做以下三件事之一：
+_Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 Pod 的绑定。
+一个允许插件可以做以下三件事之一：
 
 <!--
 1.  **approve** \
     Once all Permit plugins approve a Pod, it is sent for binding.
 -->
-
 1.  **批准** \
     一旦所有 Permit 插件批准 Pod 后，该 Pod 将被发送以进行绑定。
 
@@ -298,9 +307,9 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
     If any Permit plugin denies a Pod, it is returned to the scheduling queue.
     This will trigger [Unreserve](#unreserve) plugins.
 -->
-
 1.  **拒绝** \
-    如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。这将触发[不保留](#不保留) 插件。
+    如果任何 Permit 插件拒绝 Pod，则该 Pod 将被返回到调度队列。
+    这将触发[Unreserve](#unreserve) 插件。
 
 <!--
 1.  **wait** (with a timeout) \
@@ -310,9 +319,11 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
     and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
     plugins.
 -->
-
 1.  **等待**（带有超时） \
-    如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中” 的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到[批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod 将返回调度队列，从而触发[不保留](#不保留) 插件。
+    如果一个 Permit 插件返回 “等待” 结果，则 Pod 将保持在一个内部的 “等待中”
+    的 Pod 列表，同时该 Pod 的绑定周期启动时即直接阻塞直到得到
+    [批准](#frameworkhandle)。如果超时发生，**等待** 变成 **拒绝**，并且 Pod
+    将返回调度队列，从而触发 [Unreserve](#unreserve) 插件。
 
 
 <!-- 
@@ -322,13 +333,15 @@ plugins to approve binding of reserved Pods that are in "waiting" state. Once a
 is approved, it is sent to the [PreBind](#pre-bind) phase.
  -->
 {{< note >}}
-尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 (查看 [`FrameworkHandle`](#frameworkhandle))。我们希望只有允许插件可以批准处于 “等待中” 状态的 预留 Pod 的绑定。一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
+尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 
+(查看 [`FrameworkHandle`](#frameworkhandle))。
+我们希望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。
+一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
 {{< /note >}}
 
 <!--
 ### Pre-bind {#pre-bind}
 -->
-
 ### 预绑定 {#pre-bind}
 
 <!--
@@ -336,21 +349,21 @@ These plugins are used to perform any work required before a Pod is bound. For
 example, a pre-bind plugin may provision a network volume and mount it on the
 target node before allowing the Pod to run there.
 -->
-
-预绑定插件用于执行 Pod 绑定前所需的任何工作。例如，一个预绑定插件可能需要提供网络卷并且在允许 Pod 运行在该节点之前将其挂载到目标节点上。
+预绑定插件用于执行 Pod 绑定前所需的任何工作。
+例如，一个预绑定插件可能需要提供网络卷并且在允许 Pod 运行在该节点之前
+将其挂载到目标节点上。
 
 <!--
 If any PreBind plugin returns an error, the Pod is [rejected](#unreserve) and
 returned to the scheduling queue.
 -->
-
-如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#不保留) 并且返回到调度队列中。
+如果任何 PreBind 插件返回错误，则 Pod 将被[拒绝](#unreserve) 并且
+退回到调度队列中。
 
 <!--
 ### Bind
 -->
-
-### 绑定
+### Bind
 
 <!--
 These plugins are used to bind a Pod to a Node. Bind plugins will not be called
@@ -359,13 +372,13 @@ configured order. A bind plugin may choose whether or not to handle the given
 Pod. If a bind plugin chooses to handle a Pod, **the remaining bind plugins are
 skipped**.
 -->
-
-绑定插件用于将 Pod 绑定到节点上。直到所有的 PreBind 插件都完成，绑定插件才会被调用。每个绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。
+Bind 插件用于将 Pod 绑定到节点上。直到所有的 PreBind 插件都完成，Bind 插件才会被调用。
+各绑定插件按照配置顺序被调用。绑定插件可以选择是否处理指定的 Pod。
+如果绑定插件选择处理 Pod，**剩余的绑定插件将被跳过**。
 
 <!--
 ### PostBind {#post-bind}
 -->
-
 ### 绑定后 {#post-bind}
 
 <!--
@@ -373,34 +386,32 @@ This is an informational extension point. Post-bind plugins are called after a
 Pod is successfully bound. This is the end of a binding cycle, and can be used
 to clean up associated resources.
 -->
-
-这是个信息性的扩展点。绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
+这是个信息性的扩展点。
+绑定后插件在 Pod 成功绑定后被调用。这是绑定周期的结尾，可用于清理相关的资源。
 
 <!--
 ### Unreserve
 -->
-
-### 不保留
+### Unreserve
 
 <!--
 This is an informational extension point. If a Pod was reserved and then
 rejected in a later phase, then unreserve plugins will be notified. Unreserve
 plugins should clean up state associated with the reserved Pod.
 -->
-
-这是个信息性的扩展点。如果 Pod 被保留，然后在后面的阶段中被拒绝，则不保留插件将被通知。不保留插件应该清楚保留 Pod 的相关状态。
+这是个信息性的扩展点。
+如果 Pod 被保留，然后在后面的阶段中被拒绝，则 Unreserve 插件将被通知。
+Unreserve 插件应该清楚保留 Pod 的相关状态。
 
 <!--
 Plugins that use this extension point usually should also use
 [Reserve](#reserve).
 -->
-
-使用此扩展点的插件通常也使用[保留](#保留)。
+使用此扩展点的插件通常也使用[Reserve](#reserve)。
 
 <!--
 ## Plugin API
 -->
-
 ## 插件 API
 
 <!--
@@ -408,8 +419,8 @@ There are two steps to the plugin API. First, plugins must register and get
 configured, then they use the extension point interfaces. Extension point
 interfaces have the following form.
 -->
-
-插件 API 分为两个步骤。首先，插件必须注册并配置，然后才能使用扩展点接口。扩展点接口具有以下形式。
+插件 API 分为两个步骤。首先，插件必须完成注册并配置，然后才能使用扩展点接口。
+扩展点接口具有以下形式。
 
 ```go
 type Plugin interface {
@@ -432,7 +443,6 @@ type PreFilterPlugin interface {
 <!--
 # Plugin Configuration
 -->
-
 # 插件配置
 
 <!-- 
@@ -441,21 +451,26 @@ Kubernetes v1.18 or later, most scheduling
 [plugins](/docs/reference/scheduling/profiles/#scheduling-plugins) are in use and
 enabled by default.
  -->
-你可以在调度器配置中启用或禁用插件。如果你在使用 Kubernetes v1.18 或更高版本，大部分调度[插件](/docs/reference/scheduling/profiles/#scheduling-plugins) 都在使用中且默认启用。
+你可以在调度器配置中启用或禁用插件。
+如果你在使用 Kubernetes v1.18 或更高版本，大部分调度
+[插件](/zh/docs/reference/scheduling/profiles/#scheduling-plugins)
+都在使用中且默认启用。
 
 <!-- 
 In addition to default plugins, you can also implement your own scheduling
 plugins and get them configured along with default plugins. You can visit
 [scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) for more details.
  -->
-除了默认的插件，你同样可以实现自己的调度插件并且将他们与默认插件一起配置。你可以访问 [调度插件](https://github.com/kubernetes-sigs/scheduler-plugins) 了解更多详情。
+除了默认的插件，你还可以实现自己的调度插件并且将它们与默认插件一起配置。
+你可以访问[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins)
+了解更多信息。
 
 <!-- 
 If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
 a scheduler profile and then define multiple profiles to fit various kinds of workload.
 Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
  -->
-如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
-了解更多关于 [多配置文件](/docs/reference/scheduling/profiles/#multiple-profiles)。
-
+如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为
+一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。
+了解更多关于[多配置文件](/zh/docs/reference/scheduling/profiles/#multiple-profiles)。
 
diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
index 6d5c10b7b4..685f75bbdc 100644
--- a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -45,11 +45,11 @@ For example,
 您可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个污点。比如，
 
 ```shell
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes node1 key1=value1:NoSchedule
 ```
 
 <!--
-places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
+places a taint on node `node1`. The taint has key `key1`, value `value1`, and taint effect `NoSchedule`.
 This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
 
 ```shell
@@ -58,16 +58,12 @@ kubectl taint nodes node1 key:NoSchedule
 
 To remove the taint added by the command above, you can run:
 ```shell
-kubectl taint nodes node1 key:NoSchedule-
+kubectl taint nodes node1 key1=value1:NoSchedule-
 ```
 -->
 给节点 `node1` 增加一个污点，它的键名是 `key`，键值是 `value`，效果是 `NoSchedule`。
 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 `node1` 这个节点。
 
-```shell
-kubectl taint nodes node1 key:NoSchedule-
-```
-
 若要移除上述命令所添加的污点，你可以执行：
 
 ```shell
@@ -85,15 +81,15 @@ to schedule onto `node1`:
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Equal"
-  value: "value"
+  value: "value1"
   effect: "NoSchedule"
 ```
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Exists"
   effect: "NoSchedule"
 ```
@@ -127,7 +123,7 @@ There are two special cases:
 An empty `key` with operator `Exists` matches all keys, values and effects which means this
 will tolerate everything.
 
-An empty `effect` matches all effects with key `key`.
+An empty `effect` matches all effects with key `key1`.
 -->
 {{< note >}}
 存在两种特殊情况：
diff --git a/content/zh/docs/concepts/security/_index.md b/content/zh/docs/concepts/security/_index.md
index ec97d8f155..2f9cec262c 100644
--- a/content/zh/docs/concepts/security/_index.md
+++ b/content/zh/docs/concepts/security/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "安全"
 weight: 81
+description: 确保云原生工作负载安全的一组概念。
 ---
diff --git a/content/zh/docs/concepts/security/controlling-access.md b/content/zh/docs/concepts/security/controlling-access.md
new file mode 100644
index 0000000000..137d44c364
--- /dev/null
+++ b/content/zh/docs/concepts/security/controlling-access.md
@@ -0,0 +1,333 @@
+---
+title: Kubernetes API 访问控制
+content_type: concept
+---
+<!--  
+---
+reviewers:
+- erictune
+- lavalamp
+title: Controlling Access to the Kubernetes API
+content_type: concept
+---
+-->
+
+<!-- overview -->
+
+<!--  
+This page provides an overview of controlling access to the Kubernetes API.
+-->
+本页面概述了对 Kubernetes API 的访问控制。
+
+<!-- body -->
+<!--  
+Users access the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) using `kubectl`,
+client libraries, or by making REST requests.  Both human users and
+[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
+authorized for API access.
+When a request reaches the API, it goes through several stages, illustrated in the
+following diagram:
+-->
+用户使用 `kubectl`、客户端库或构造 REST 请求访问来 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。
+人类用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。
+当请求到达 API 时，它会经历多个阶段，如下图所示：
+
+![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg)
+
+<!-- ## Transport security -->
+## 传输安全 {#transport-security}
+
+<!--  
+In a typical Kubernetes cluster, the API serves on port 443, protected by TLS.
+The API server presents a certificate. This certificate may be signed using
+a private certificate authority (CA), or based on a public key infrastructure linked
+to a generally recognized CA.
+-->
+在典型的 Kubernetes 集群中，API 服务器在 443 端口上提供服务，受 TLS 保护。
+API 服务器出示证书。
+该证书可以使用私有证书颁发机构（CA）签名，也可以基于链接到公认的 CA 的公钥基础架构签名。
+
+<!--  
+If your cluster uses a private certificate authority, you need a copy of that CA
+certifcate configured into your `~/.kube/config` on the client, so that you can
+trust the connection and be confident it was not intercepted.
+
+Your client can present a TLS client certificate at this stage.
+-->
+如果你的集群使用私有证书颁发机构，你需要在客户端的 `~/.kube/config` 文件中提供该 CA 证书的副本，
+以便你可以信任该连接并确认该连接没有被拦截。
+
+你的客户端可以在此阶段出示 TLS 客户端证书。
+
+<!-- ## Authentication -->
+## 认证 {#authentication}
+
+<!--  
+Once TLS is established, the HTTP request moves to the Authentication step.
+This is shown as step **1** in the diagram.
+The cluster creation script or cluster admin configures the API server to run
+one or more Authenticator modules.
+Authenticators are described in more detail in
+[Authentication](/docs/reference/access-authn-authz/authentication/).
+-->
+如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。
+集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。
+身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。
+
+<!--  
+The input to the authentication step is the entire HTTP request; however, it typically
+just examines the headers and/or client certificate.
+
+Authentication modules include client certificates, password, and plain tokens,
+bootstrap tokens, and JSON Web Tokens (used for service accounts).
+
+Multiple authentication modules can be specified, in which case each one is tried in sequence,
+until one of them succeeds.
+-->
+认证步骤的输入整个 HTTP 请求；但是，通常组件只检查头部或/和客户端证书。
+
+认证模块包含客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌（JWT，用于服务账户）。
+
+可以指定多个认证模块，在这种情况下，服务器依次尝试每个验证模块，直到其中一个成功。
+
+<!-- 
+If the request cannot be authenticated, it is rejected with HTTP status code 401.
+Otherwise, the user is authenticated as a specific `username`, and the user name
+is available to subsequent steps to use in their decisions.  Some authenticators
+also provide the group memberships of the user, while other authenticators
+do not.
+
+While Kubernetes uses usernames for access control decisions and in request logging,
+it does not have a `User` object nor does it store usernames or other information about
+users in its API. 
+-->
+如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。
+反之，该用户被认证为特定的 `username`，并且该用户名可用于后续步骤以在其决策中使用。
+部分验证器还提供用户的组成员身份，其他则不提供。
+
+<!-- ## Authorization -->
+## 鉴权 {#authorization}
+
+<!--  
+After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
+
+A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
+
+For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
+-->
+如上图的步骤 **2** 所示，将请求验证为来自特定的用户后，请求必须被鉴权。
+
+请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。
+如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。
+
+例如，如果 Bob 有以下策略，那么他只能在 `projectCaribou` 名称空间中读取 Pod。
+
+```json
+{
+    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
+    "kind": "Policy",
+    "spec": {
+        "user": "bob",
+        "namespace": "projectCaribou",
+        "resource": "pods",
+        "readonly": true
+    }
+}
+```
+<!-- 
+If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace:
+-->
+如果 Bob 执行以下请求，那么请求会被鉴权，因为允许他读取 `projectCaribou` 名称空间中的对象。
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "projectCaribou",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    }
+  }
+}
+```
+<!--  
+If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. 
+If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
+
+Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. 
+It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
+-->
+如果 Bob 在 `projectCaribou` 名字空间中请求写（`create` 或 `update`）对象，其鉴权请求将被拒绝。
+如果 Bob 在诸如 `projectFish` 这类其它名字空间中请求读取（`get`）对象，其鉴权也会被拒绝。
+
+Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 
+使用 REST 格式很重要，因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。
+
+<!--  
+Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. 
+When an administrator creates a cluster, they configure the authorization modules that should be used in the API server. 
+If more than one authorization modules are configured, Kubernetes checks each module, 
+and if any module authorizes the request, then the request can proceed. 
+If all of the modules deny the request, then the request is denied (HTTP status code 403).
+
+To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, 
+see [Authorization](/docs/reference/access-authn-authz/authorization/).
+-->
+Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。
+管理员创建集群时，他们配置应在 API 服务器中使用的鉴权模块。
+如果配置了多个鉴权模块，则 Kubernetes 会检查每个模块，任意一个模块鉴权该请求，请求即可继续；
+如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。
+
+要了解更多有关 Kubernetes 鉴权的更多信息，包括有关使用支持鉴权模块创建策略的详细信息，
+请参阅[鉴权](/zh/docs/reference/access-authn-authz/authorization/)。
+
+<!-- ## Admission control -->
+## 准入控制 {#admission-control}
+
+<!--  
+Admission Control modules are software modules that can modify or reject requests.
+In addition to the attributes available to Authorization modules, Admission
+Control modules can access the contents of the object that is being created or modified.
+
+Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
+Admission controllers do not act on requests that merely read objects.
+When multiple admission controllers are configured, they are called in order.
+-->
+准入控制模块是可以修改或拒绝请求的软件模块。
+除鉴权模块可用的属性外，准入控制模块还可以访问正在创建或修改的对象的内容。
+
+准入控制器对创建、修改、删除或（通过代理）连接对象的请求进行操作。
+准入控制器不会对仅读取对象的请求起作用。
+有多个准入控制器被配置时，服务器将依次调用它们。
+
+<!--  
+This is shown as step **3** in the diagram.
+
+Unlike Authentication and Authorization modules, if any admission controller module
+rejects, then the request is immediately rejected.
+
+In addition to rejecting objects, admission controllers can also set complex defaults for
+fields.
+
+The available Admission Control modules are described in [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
+
+Once a request passes all admission controllers, it is validated using the validation routines
+for the corresponding API object, and then written to the object store (shown as step **4**).
+-->
+这一操作如上图的步骤 **3** 所示。
+
+与身份认证和鉴权模块不同，如果任何准入控制器模块拒绝某请求，则该请求将立即被拒绝。
+
+除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。
+
+可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。
+
+请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。
+
+<!-- ## API server ports and IPs -->
+## API 服务器端口和 IP {#api-server-ports-and-ips}
+
+<!--  
+The previous discussion applies to requests sent to the secure port of the API server
+(the typical case).  The API server can actually serve on 2 ports:
+
+By default the Kubernetes API server serves HTTP on 2 ports:
+-->
+前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务：
+
+默认情况下，Kubernetes API 服务器在 2 个端口上提供 HTTP 服务：
+
+<!--
+  1. `localhost` port:
+
+      - is intended for testing and bootstrap, and for other components of the master node
+        (scheduler, controller-manager) to talk to the API
+      - no TLS
+      - default is port 8080, change with `--insecure-port` flag.
+      - default IP is localhost, change with `--insecure-bind-address` flag.
+      - request **bypasses** authentication and authorization modules.
+      - request handled by admission control module(s).
+      - protected by need to have host access 
+
+  2. “Secure port”:
+
+      - use whenever possible
+      - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
+      - default is port 6443, change with `--secure-port` flag.
+      - default IP is first non-localhost network interface, change with `--bind-address` flag.
+      - request handled by authentication and authorization modules.
+      - request handled by admission control module(s).
+      - authentication and authorization modules run.
+ -->
+  1. `localhost` 端口:
+
+      - 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信
+      - 没有 TLS
+      - 默认为端口 8080，使用 `--insecure-port` 进行更改
+      - 默认 IP 为 localhost，使用 `--insecure-bind-address` 进行更改
+      - 请求 **绕过** 身份认证和鉴权模块
+      - 由准入控制模块处理的请求
+      - 受需要访问主机的保护
+
+  2. “安全端口”：
+
+      - 尽可能使用
+      - 使用 TLS。 用 `--tls-cert-file` 设置证书，用 `--tls-private-key-file` 设置密钥
+      - 默认端口 6443，使用 `--secure-port` 更改
+      - 默认 IP 是第一个非本地网络接口，使用 `--bind-address` 更改
+      - 请求须经身份认证和鉴权组件处理
+      - 请求须经准入控制模块处理
+      - 身份认证和鉴权模块运行
+  
+
+## {{% heading "whatsnext" %}}
+
+<!--  
+Read more documentation on authentication, authorization and API access control:
+
+- [Authenticating](/docs/reference/access-authn-authz/authentication/)
+   - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+   - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [Authorization](/docs/reference/access-authn-authz/authorization/)
+   - [Role Based Access Control](/docs/reference/access-authn-authz/rbac/)
+   - [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/)
+   - [Node Authorization](/docs/reference/access-authn-authz/node/)
+   - [Webhook Authorization](/docs/reference/access-authn-authz/webhook/)
+- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
+     and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
+- Service accounts
+  - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
+  - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
+
+You can learn about:
+- how Pods can use
+  [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
+  to obtain API credentials.
+-->
+阅读更多有关身份认证、鉴权和 API 访问控制的文档：
+
+- [认证](/zh/docs/reference/access-authn-authz/authentication/)
+   - [使用 Bootstrap 令牌进行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
+- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
+   - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
+- [鉴权](/zh/docs/reference/access-authn-authz/authorization/)
+   - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/)
+   - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/)
+   - [节点鉴权](/zh/docs/reference/access-authn-authz/node/)
+   - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/)
+- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
+   - 包括 [CSR 认证](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
+     和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
+- 服务账户
+  - [开发者指导](/zh/docs/tasks/configure-pod-container/configure-service-account/)
+  - [管理](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
+
+你可以了解
+- Pod 如何使用
+  [Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
+  获取 API 凭证.
\ No newline at end of file
diff --git a/content/zh/docs/concepts/security/overview.md b/content/zh/docs/concepts/security/overview.md
new file mode 100644
index 0000000000..19ce78672f
--- /dev/null
+++ b/content/zh/docs/concepts/security/overview.md
@@ -0,0 +1,275 @@
+---
+title: 云原生安全概述
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+<!--
+This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security.
+-->
+本概述定义了一个模型，用于在 Cloud Native 安全性上下文中考虑 Kubernetes 安全性。
+
+<!--
+This container security model provides suggestions, not proven information security policies.
+-->
+{{< warning >}}
+此容器安全模型只提供建议，而不是经过验证的信息安全策略。
+{{< /warning >}}
+
+<!-- body -->
+
+<!--
+## The 4C's of Cloud Native security
+
+You can think about security in layers. The 4C's of Cloud Native security are Cloud,
+Clusters, Containers, and Code.
+-->
+## 云原生安全的 4 个 C
+
+你可以分层去考虑安全性，云原生安全的 4 个 C 分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。
+
+<!--
+This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))
+computing approach to security, which is widely regarded as a best practice for securing
+software systems.
+-->
+{{< note >}}
+这种分层方法增强了[深度防护方法](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))在安全性方面的
+防御能力，该方法被广泛认为是保护软件系统的最佳实践。
+
+{{< /note >}}
+
+{{< figure src="/images/docs/4c.png" title="云原生安全的 4C" >}}
+
+<!--
+Each layer of the Cloud Native security model builds upon the next outermost layer.
+The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
+You cannot safeguard against poor security standards in the base layers by addressing
+security at the Code level.
+-->
+云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。你无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。
+
+## 云
+
+<!--
+In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the
+[trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base)
+of a Kubernetes cluster. If the Cloud layer is vulnerable (or
+configured in a vulnerable way) then there is no guarantee that the components built
+on top of this base are secure. Each cloud provider makes security recommendations
+for running workloads securely in their environment.
+-->
+在许多方面，云（或者位于同一位置的服务器，或者是公司数据中心）是 Kubernetes 集群中的
+[可信计算基](https://en.wikipedia.org/wiki/Trusted_computing_base)。
+如果云层容易受到攻击（或者被配置成了易受攻击的方式），就不能保证在此基础之上构建的组件是安全的。
+每个云提供商都会提出安全建议，以在其环境中安全地运行工作负载。
+
+<!--
+### Cloud provider security
+
+If you are running a Kubernetes cluster on your own hardware or a different cloud provider,
+consult your documentation for security best practices.
+Here are links to some of the popular cloud providers' security documentation:
+-->
+### 云提供商安全性
+
+如果您是在您自己的硬件或者其他不通的云提供商上运行 Kubernetes 集群，
+请查阅相关文档来获取最好的安全实践。
+
+下面是一些比较流行的云提供商的安全性文档链接：
+
+{{< table caption="云提供商安全" >}}
+
+IaaS 提供商        | 链接 |
+-------------------- | ------------ |
+Alibaba Cloud | https://www.alibabacloud.com/trust-center |
+Amazon Web Services | https://aws.amazon.com/security/ |
+Google Cloud Platform | https://cloud.google.com/security/ |
+IBM Cloud | https://www.ibm.com/cloud/security |
+Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
+VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+
+{{< /table >}}
+
+<!--
+### Infrastructure security {#infrastructure-security}
+
+Suggestions for securing your infrastructure in a Kubernetes cluster:
+
+{{< table caption="Infrastructure security" >}}
+
+Area of Concern for Kubernetes Infrastructure | Recommendation |
+--------------------------------------------- | -------------- |
+Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
+Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists)from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
+Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
+Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
+etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
+
+{{< /table >}}
+-->
+### 基础设施安全 {#infrastructure-security}
+
+关于在 Kubernetes 集群中保护你的基础设施的建议：
+
+{{< table caption="基础设施安全" >}}
+
+Kubetnetes 基础架构关注领域 | 建议 |
+--------------------------------------------- | -------------- |
+通过网络访问 API 服务（控制平面）|所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。|
+通过网络访问 Node（节点）| 节点应配置为 _仅能_ 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。|
+Kubernetes 访问云提供商的 API | 每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege)。[Kops 文档](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)提供有关 IAM 策略和角色的信息。|
+访问 etcd | 对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 [etcd 文档](https://github.com/etcd-io/etcd/tree/master/Documentation)中找到。|
+etcd 加密 | 在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。|
+
+{{< /table >}}
+
+<!--
+## Cluster
+
+There are two areas of concern for securing Kubernetes:
+
+* Securing the cluster components that are configurable
+* Securing the applications which run in the cluster
+-->
+## 集群
+
+保护 Kubernetes 有两个方面需要注意：
+
+* 保护可配置的集群组件
+* 保护在集群中运行的应用程序
+
+<!--
+### Components of the Cluster {#cluster-components}
+
+If you want to protect your cluster from accidental or malicious access and adopt
+good information practices, read and follow the advice about
+[securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/).
+-->
+### 集群组件 {#cluster-components}
+
+如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)的建议。
+
+<!--
+### Components in the cluster (your application) {#cluster-applications}
+
+Depending on the attack surface of your application, you may want to focus on specific
+aspects of security. For example: If you are running a service (Service A) that is critical
+in a chain of other resources and a separate workload (Service B) which is
+vulnerable to a resource exhaustion attack then the risk of compromising Service A
+is high if you do not limit the resources of Service B. The following table lists
+areas of security concerns and recommendations for securing workloads running in Kubernetes:
+
+Area of Concern for Workload Security | Recommendation |
+------------------------------ | --------------------- |
+RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
+Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
+Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+Pod Security Policies | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
+Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
+Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
+TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
+-->
+### 集群中的组件（您的应用） {#cluster-applications}
+
+根据您的应用程序的受攻击面，您可能需要关注安全性的特定面，比如：
+如果您正在运行中的一个服务（A 服务）在其他资源链中很重要，并且所运行的另一工作负载（服务 B）
+容易受到资源枯竭的攻击，则如果你不限制服务 B 的资源的话，损害服务 A 的风险就会很高。
+下表列出了安全性关注的领域和建议，用以保护 Kubernetes 中运行的工作负载：
+
+工作负载安全性关注领域 |  建议 |
+------------------------------ | --------------------- |
+RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
+认证方式 | https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
+应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh/docs/tasks/administer-cluster/encrypt-data/
+Pod 安全策略 | https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/
+服务质量（和集群资源管理）| https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
+网络策略 | https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/
+Kubernetes Ingress 的 TLS 支持 | https://kubernetes.io/zh/docs/concepts/services-networking/ingress/#tls
+
+<!--
+## Container
+
+Container security is outside the scope of this guide. Here are general recommendations and
+links to explore this topic:
+
+Area of Concern for Containers | Recommendation |
+------------------------------ | -------------- |
+Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
+Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
+Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
+-->
+## 容器
+
+容器安全性不在本指南的探讨范围内。下面是一些探索此主题的建议和连接：
+
+容器关注领域                   | 建议           |
+------------------------------ | -------------- |
+容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，您应该扫描您的容器里的已知漏洞。
+镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。
+禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。
+
+<!--
+## Code
+
+Application code is one of the primary attack surfaces over which you have the most control.
+While securing application code is outside of the Kubernetes security topic, here
+are recommendations to protect application code:
+-->
+## 代码
+
+应用程序代码是您最能够控制的主要攻击面之一，虽然保护应用程序代码不在 Kubernetes 安全主题范围内，但以下是保护应用程序代码的建议：
+
+<!--
+### Code security
+
+{{< table caption="Code security" >}}
+
+Area of Concern for Code | Recommendation |
+-------------------------| -------------- |
+Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
+Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
+3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. |
+Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools |
+Dynamic probing attacks | There are a few automated tools that you can run against your service to try some of the well known service attacks. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the [OWASP Zed Attack proxy](https://owasp.org/www-project-zap/) tool. |
+
+{{< /table >}}
+-->
+### 代码安全性
+
+{{< table caption="代码安全" >}}
+
+代码关注领域 | 建议 |
+-------------------------| -------------- |
+仅通过 TLS 访问 | 如果您的代码需要通过 TCP 通信，请提前与客户端执行 TLS 握手。除少数情况外，请加密传输中的所有内容。更进一步，加密服务之间的网络流量是一个好主意。这可以通过被称为相互 LTS 或 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) 的过程来完成，该过程对两个证书持有服务之间的通信执行双向验证。 |
+限制通信端口范围 | 此建议可能有点不言自明，但是在任何可能的情况下，你都只应公开服务上对于通信或度量收集绝对必要的端口。|
+第三方依赖性安全 | 最好定期扫描应用程序的第三方库以了解已知的安全漏洞。每种编程语言都有一个自动执行此检查的工具。 |
+静态代码分析 | 大多数语言都提供给了一种方法，来分析代码段中是否存在潜在的不安全的编码实践。只要有可能，你都应该使用自动工具执行检查，该工具可以扫描代码库以查找常见的安全错误，一些工具可以在以下连接中找到：https://owasp.org/www-community/Source_Code_Analysis_Tools |
+动态探测攻击 | 您可以对服务运行一些自动化工具，来尝试一些众所周知的服务攻击。这些攻击包括 SQL 注入、CSRF 和 XSS。[OWASP Zed Attack](https://owasp.org/www-project-zap/) 代理工具是最受欢迎的动态分析工具之一。 |
+
+{{< /table >}}
+
+## {{% heading "whatsnext" %}}
+
+<!--
+Learn about related Kubernetes security topics:
+
+* [Pod security standards](/docs/concepts/security/pod-security-standards/)
+* [Network policies for Pods](/docs/concepts/services-networking/network-policies/)
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
+* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
+* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
+* [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
+* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
+-->
+学习了解相关的 Kubernetes 安全主题：
+
+* [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
+* [Pod 的网络策略](/zh/docs/concepts/services-networking/network-policies/)
+* [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
+* [保护您的集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)
+* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/)
+* [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/)
+* [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/)
+
diff --git a/content/zh/docs/concepts/security/pod-security-standards.md b/content/zh/docs/concepts/security/pod-security-standards.md
new file mode 100644
index 0000000000..3a897686dc
--- /dev/null
+++ b/content/zh/docs/concepts/security/pod-security-standards.md
@@ -0,0 +1,520 @@
+---
+title: Pod 安全性标准
+content_type: concept
+weight: 10
+---
+<!--
+reviewers:
+- tallclair
+title: Pod Security Standards
+content_type: concept
+weight: 10
+-->
+
+<!-- overview -->
+
+<!--
+Security settings for Pods are typically applied by using [security
+contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the
+definition of privilege and access controls on a per-Pod basis.
+
+The enforcement and policy-based definition of cluster requirements of security contexts has
+previously been achieved using [Pod Security Policy](/docs/concepts/policy/pod-security-policy/). A
+_Pod Security Policy_ is a cluster-level resource that controls security sensitive aspects of the
+Pod specification.
+
+However, numerous means of policy enforcement have arisen that augment or replace the use of
+PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled
+from any specific instantiation.
+-->
+Pod 的安全性配置一般通过使用
+[安全性上下文（Security Context）](/zh/docs/tasks/configure-pod-container/security-context/)
+来保证。安全性上下文允许用户逐个 Pod 地定义特权级及访问控制。
+
+以前，对集群的安全性上下文的需求的实施及其基于策略的定义都通过使用
+[Pod 安全性策略](/zh/docs/concepts/policy/pod-security-policy/)来实现。
+_Pod 安全性策略（Pod Security Policy）_ 是一种集群层面的资源，控制 Pod 规约中
+安全性敏感的部分。
+
+不过，新的策略实施方式不断涌现，或增强或替换 PodSecurityPolicy 的使用。
+本页的目的是详细介绍建议实施的 Pod 安全框架；这些内容与具体的实现无关。
+
+<!-- body -->
+
+<!--
+## Policy Types
+
+There is an immediate need for base policy definitions to broadly cover the security spectrum. These
+should range from highly restricted to highly flexible:
+
+- **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This
+  policy allows for known privilege escalations.
+- **_Baseline/Default_** - Minimally restrictive policy while preventing known privilege
+  escalations. Allows the default (minimally specified) Pod configuration.
+- **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices.
+-->
+## 策略类型   {#policy-types}
+
+在进一步讨论整个策略谱系之前，有必要对基本的策略下个定义。
+策略可以是很严格的也可以是很宽松的：
+
+- **_Privileged_** - 不受限制的策略，提供最大可能范围的权限许可。这些策略
+  允许已知的特权提升。
+- **_Baseline/Default_** - 限制性最弱的策略，禁止已知的策略提升。
+  允许使用默认的（规定最少）Pod 配置。
+- **_Restricted_** - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。
+
+<!--
+## Policies
+
+### Privileged
+-->
+## 策略    {#policies}
+
+### Privileged
+
+<!--
+The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically
+aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
+
+The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
+mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
+rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
+Security Policy) the privileged policy should enable all controls (disable all restrictions).
+-->
+Privileged 策略是有目的地开放且完全无限制的策略。此类策略通常针对由
+特权较高、受信任的用户所管理的系统级或基础设施级负载。
+
+Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper），
+Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。
+与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言，
+Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
+
+### Baseline/Default
+
+<!--
+The Baseline/Default policy is aimed at ease of adoption for common containerized workloads while
+preventing known privilege escalations. This policy is targeted at application operators and
+developers of non-critical applications. The following listed controls should be
+enforced/disallowed:
+-->
+Baseline/Default 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。
+此策略针对的是应用运维人员和非关键性应用的开发人员。
+下面列举的控制应该被实施（禁止）：
+
+<table>
+	<!-- caption style="display:none">Baseline policy specification</caption -->
+	<caption style="display:none">Baseline 策略规范</caption>
+	<tbody>
+		<tr>
+			<td width="30%"><strong>控制（Control）</strong></td>
+			<td><strong>策略（Policy）</strong></td>
+		</tr>
+		<tr>
+			<!-- td>Host Namespaces</td -->
+			<td>宿主名字空间</td>
+			<!-- td>
+				Sharing the host namespaces must be disallowed.<br>
+				<br><b>限制的字段：</b><br>
+				spec.hostNetwork<br>
+				spec.hostPID<br>
+				spec.hostIPC<br>
+				<br><b>Allowed Values:</b> false<br>
+			</td -->
+			<td>
+				必须禁止共享宿主名字空间。<br>
+				<br><b>限制的字段：</b><br>
+				spec.hostNetwork<br>
+				spec.hostPID<br>
+				spec.hostIPC<br>
+				<br><b>允许的值：</b> false<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>Privileged Containers</td -->
+			<td>特权容器</td>
+			<!-- td>
+				Privileged Pods disable most security mechanisms and must be disallowed.<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].securityContext.privileged<br>
+				spec.initContainers[*].securityContext.privileged<br>
+				<br><b>Allowed Values:</b> false, undefined/nil<br>
+			</td -->
+			<td>
+				特权 Pod 禁用大多数安全性机制，必须被禁止。<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].securityContext.privileged<br>
+				spec.initContainers[*].securityContext.privileged<br>
+				<br><b>允许的值：</b> false、未定义/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>Capabilities</td -->
+			<td>权能</td>
+			<!-- td>
+				Adding additional capabilities beyond the <a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">default set</a> must be disallowed.<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].securityContext.capabilities.add<br>
+				spec.initContainers[*].securityContext.capabilities.add<br>
+				<br><b>Allowed Values:</b> empty (or restricted to a known list)<br>
+			</td -->
+			<td>
+				必须禁止添加<a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">默认集合</a>之外的权能。<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].securityContext.capabilities.add<br>
+				spec.initContainers[*].securityContext.capabilities.add<br>
+				<br><b>允许的值：</b> 空（或限定为一个已知列表）<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>HostPath Volumes</td -->
+			<td>HostPath 卷</td>
+			<!-- td>
+				HostPath volumes must be forbidden.<br>
+				<br><b>限制的字段：</b><br>
+				spec.volumes[*].hostPath<br>
+				<br><b>Allowed Values:</b> undefined/nil<br>
+			</td -->
+			<td>
+				必须禁止 HostPath 卷。<br>
+				<br><b>限制的字段：</b><br>
+				spec.volumes[*].hostPath<br>
+				<br><b>允许的值：</b> 未定义/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>Host Ports</td -->
+			<td>宿主端口</td>
+			<!-- td>
+				HostPorts should be disallowed, or at minimum restricted to a known list.<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].ports[*].hostPort<br>
+				spec.initContainers[*].ports[*].hostPort<br>
+				<br><b>Allowed Values:</b> 0, undefined (or restricted to a known list)<br>
+			</td -->
+			<td>
+				应禁止使用宿主端口，或者至少限定为已知列表。<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].ports[*].hostPort<br>
+				spec.initContainers[*].ports[*].hostPort<br>
+				<br><b>允许的值：</b> 0、未定义（或限定为已知列表）<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>AppArmor <em>(optional)</em></td -->
+			<td>AppArmor <em>（可选）</em></td>
+			<!-- td>
+				On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
+				<br><b>限制的字段：</b><br>
+				metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
+				<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
+			</td -->
+			<td>
+				在受支持的宿主上，默认应用 'runtime/default' AppArmor Profile。默认策略应禁止重载或者禁用该策略，或将重载限定未所允许的 profile 集合。<br>
+				<br><b>限制的字段：</b><br>
+				metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
+				<br><b>允许的值：</b> 'runtime/default'、未定义<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>SELinux <em>(optional)</em></td -->
+			<td>SELinux <em>（可选）</em></td>
+			<!-- td>
+				Setting custom SELinux options should be disallowed.<br>
+				<br><b>Restricted Fields:</b><br>
+				spec.securityContext.seLinuxOptions<br>
+				spec.containers[*].securityContext.seLinuxOptions<br>
+				spec.initContainers[*].securityContext.seLinuxOptions<br>
+				<br><b>Allowed Values:</b> undefined/nil<br>
+			</td -->
+			<td>
+				应禁止设置定制的 SELinux 选项。<br>
+				<br><b>限制的字段：</b><br>
+				spec.securityContext.seLinuxOptions<br>
+				spec.containers[*].securityContext.seLinuxOptions<br>
+				spec.initContainers[*].securityContext.seLinuxOptions<br>
+				<br><b>允许的值：</b> undefined/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>/proc Mount Type</td -->
+			<td>/proc 挂载类型</td>
+			<!-- td>
+				The default /proc masks are set up to reduce attack surface, and should be required.<br>
+				<br><b>Restricted Fields:</b><br>
+				spec.containers[*].securityContext.procMount<br>
+				spec.initContainers[*].securityContext.procMount<br>
+				<br><b>Allowed Values:</b> undefined/nil, 'Default'<br>
+			</td -->
+			<td>
+				要求使用默认的 <code>/proc</code> 掩码以减小攻击面。<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].securityContext.procMount<br>
+				spec.initContainers[*].securityContext.procMount<br>
+				<br><b>允许的值：</b> 未定义/nil、'Default'<br>
+			</td>
+		</tr>
+		<tr>
+			<td>Sysctls</td>
+			<!-- td>
+				Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset.
+				A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.<br>
+				<br><b>Restricted Fields:</b><br>
+				spec.securityContext.sysctls<br>
+				<br><b>Allowed Values:</b><br>
+				kernel.shm_rmid_forced<br>
+				net.ipv4.ip_local_port_range<br>
+				net.ipv4.tcp_syncookies<br>
+				net.ipv4.ping_group_range<br>
+				undefined/empty<br>
+			</td -->
+			<td>
+				Sysctls 可以禁用安全机制或影响宿主上所有容器，因此除了若干『安全』的子集之外，应该被禁止。
+				如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。<br>
+				<br><b>限制的字段：</b><br>
+				spec.securityContext.sysctls<br>
+				<br><b>允许的值：</b><br>
+				kernel.shm_rmid_forced<br>
+				net.ipv4.ip_local_port_range<br>
+				net.ipv4.tcp_syncookies<br>
+				net.ipv4.ping_group_range<br>
+				未定义/空值<br>
+			</td>
+		</tr>
+	</tbody>
+</table>
+
+### Restricted
+
+<!--
+The Restricted policy is aimed at enforcing current Pod hardening best practices, at the expense of
+some compatibility. It is targeted at operators and developers of security-critical applications, as
+well as lower-trust users.The following listed controls should be enforced/disallowed:
+-->
+Restricted 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作可能会牺牲一些兼容性。
+该类策略主要针对运维人员和安全性很重要的应用的开发人员，以及不太被信任的用户。
+下面列举的控制需要被实施（禁止）：
+
+<table>
+	<!-- caption style="display:none">Restricted policy specification</caption -->
+	<caption style="display:none">Restricted 策略规范</caption>
+	<tbody>
+		<tr>
+			<!-- td><strong>Control</strong></td -->
+			<td width="30%"><strong>控制（Control）</strong></td>
+			<!-- td><strong>Policy</strong></td -->
+			<td><strong>策略（Policy）</strong></td>
+		</tr>
+		<tr>
+			<!-- td colspan="2"><em>Everything from the default profile.</em></td -->
+			<td colspan="2"><em>Default 策略的所有要求。</em></td>
+		</tr>
+		<tr>
+			<!-- td>Volume Types</td -->
+			<td>卷类型</td>
+			<td>
+				<!-- In addition to restricting HostPath volumes, the restricted profile limits usage of non-core volume types to those defined through PersistentVolumes. -->
+				除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。<br>
+				<br><b>限制的字段：</b><br>
+				spec.volumes[*].hostPath<br>
+				spec.volumes[*].gcePersistentDisk<br>
+				spec.volumes[*].awsElasticBlockStore<br>
+				spec.volumes[*].gitRepo<br>
+				spec.volumes[*].nfs<br>
+				spec.volumes[*].iscsi<br>
+				spec.volumes[*].glusterfs<br>
+				spec.volumes[*].rbd<br>
+				spec.volumes[*].flexVolume<br>
+				spec.volumes[*].cinder<br>
+				spec.volumes[*].cephFS<br>
+				spec.volumes[*].flocker<br>
+				spec.volumes[*].fc<br>
+				spec.volumes[*].azureFile<br>
+				spec.volumes[*].vsphereVolume<br>
+				spec.volumes[*].quobyte<br>
+				spec.volumes[*].azureDisk<br>
+				spec.volumes[*].portworxVolume<br>
+				spec.volumes[*].scaleIO<br>
+				spec.volumes[*].storageos<br>
+				spec.volumes[*].csi<br>
+				<br><b>允许的值：</b> 未定义/nil<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>Privilege Escalation</td -->
+			<td>特权提升</td>
+			<td>
+				<!-- Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. -->
+				禁止（通过 SetUID 或 SetGID 文件模式）获得特权提升。<br>
+				<br><b>限制的字段：</b><br>
+				spec.containers[*].securityContext.allowPrivilegeEscalation<br>
+				spec.initContainers[*].securityContext.allowPrivilegeEscalation<br>
+				<br><b>允许的值：</b> false<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>Running as Non-root</td -->
+			<td>以非 root 账号运行 </td>
+			<td>
+				<!-- Containers must be required to run as non-root users. -->
+				必须要求容器以非 root 用户运行。<br>
+				<br><b>限制的字段：</b><br>
+				spec.securityContext.runAsNonRoot<br>
+				spec.containers[*].securityContext.runAsNonRoot<br>
+				spec.initContainers[*].securityContext.runAsNonRoot<br>
+				<br><b>允许的值：</b> true<br>
+			</td>
+		</tr>
+		<tr>
+			<!-- td>Non-root groups <em>(optional)</em></td -->
+			<td>非 root 组 <em>（可选）</em></td>
+			<td>
+				<!-- Containers should be forbidden from running with a root primary or supplementary GID. -->
+				禁止容器使用 root 作为主要或辅助 GID 来运行。<br>
+				<br><b>限制的字段：</b><br>
+				spec.securityContext.runAsGroup<br>
+				spec.securityContext.supplementalGroups[*]<br>
+				spec.securityContext.fsGroup<br>
+				spec.containers[*].securityContext.runAsGroup<br>
+				spec.initContainers[*].securityContext.runAsGroup<br>
+				<br><b>允许的值：</b><br>
+				非零值<br>
+				未定义/nil （<code>*.runAsGroup</code> 除外）<br>
+			</td>
+		</tr>
+		<tr>
+			<td>Seccomp</td>
+			<td>
+				<!-- The RuntimeDefault seccomp profile must be required, or allow specific additional profiles. -->
+				必须要求使用 RuntimeDefault seccomp profile 或者允许使用特定的 profiles。<br>
+				<br><b>限制的字段：</b><br>
+				spec.securityContext.seccompProfile.type<br>
+				spec.containers[*].securityContext.seccompProfile<br>
+				spec.initContainers[*].securityContext.seccompProfile<br>
+				<br><b>允许的值：</b><br>
+				'runtime/default'<br>
+				未定义/nil<br>
+			</td>
+		</tr>
+	</tbody>
+</table>
+
+<!--
+## Policy Instantiation
+
+Decoupling policy definition from policy instantiation allows for a common understanding and
+consistent language of policies across clusters, independent of the underlying enforcement
+mechanism.
+
+As mechanisms mature, they will be defined below on a per-policy basis. The methods of enforcement
+of individual policies are not defined here.
+-->
+## 策略实例化   {#policy-instantiation}
+
+将策略定义从策略实例中解耦出来有助于形成跨集群的策略理解和语言陈述，
+以免绑定到特定的下层实施机制。
+
+随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。
+
+[**PodSecurityPolicy**](/zh/docs/concepts/policy/pod-security-policy/)
+
+- [Privileged](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml)
+- [Baseline](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml)
+- [Restricted](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml)
+
+<!--
+## FAQ
+
+### Why isn't there a profile between privileged and default?
+-->
+## 常见问题    {#faq}
+
+### 为什么策略类型定义在 Privileged 和 Default 之间
+
+<!--
+The three profiles defined here have a clear linear progression from most secure (restricted) to least
+secure (privileged), and cover a broad set of workloads. Privileges required above the baseline
+policy are typically very application specific, so we do not offer a standard profile in this
+niche. This is not to say that the privileged profile should always be used in this case, but that
+policies in this space need to be defined on a case-by-case basis.
+
+SIG Auth may reconsider this position in the future, should a clear need for other profiles arise.
+-->
+这里定义的三种策略框架有一个明晰的线性递进关系，从最安全（Restricted）到最不安全，
+并且覆盖了很大范围的工作负载。特权要求超出 Baseline 策略者通常是特定于应用的需求，
+所以我们没有在这个范围内提供标准框架。
+这并不意味着在这样的情形下仍然只能使用 Privileged 框架，只是说处于这个范围的
+策略需要因地制宜地定义。
+
+SIG Auth 可能会在将来考虑这个范围的框架，前提是有对其他框架的需求。
+
+<!--
+### What's the difference between a security policy and a security context?
+
+[Security Contexts](/docs/tasks/configure-pod-container/security-context/) configure Pods and
+Containers at runtime. Security contexts are defined as part of the Pod and container specifications
+in the Pod manifest, and represent parameters to the container runtime.
+-->
+### 安全策略与安全上下文的区别是什么？
+
+[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
+和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，所代表的是
+传递给容器运行时的参数。
+
+<!--
+Security policies are control plane mechanisms to enforce specific settings in the Security Context,
+as well as other parameters outside the Security Context. As of February 2020, the current native
+solution for enforcing these security policies is [Pod Security
+Policy](/docs/concepts/policy/pod-security-policy/) - a mechanism for centrally enforcing security
+policy on Pods across a cluster. Other alternatives for enforcing security policy are being
+developed in the Kubernetes ecosystem, such as [OPA
+Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
+-->
+安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。
+在 2020 年 2 月，目前实施这些安全性策略的原生解决方案是
+[Pod 安全性策略](/zh/docs/concepts/policy/pod-security-policy/) - 一种对集群中
+Pod 的安全性策略进行集中控制的机制。
+Kubernetes 生态系统中还在开发一些其他的替代方案，例如
+[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)。
+
+<!--
+### What profiles should I apply to my Windows Pods?
+
+Windows in Kubernetes has some limitations and differentiators from standard Linux-based
+workloads. Specifically, the Pod SecurityContext fields [have no effect on
+Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As
+such, no standardized Pod Security profiles currently exists.
+-->
+### 我应该为我的 Windows Pod 实施哪种框架？
+
+Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。
+尤其是 Pod SecurityContext 字段
+[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+因此，目前没有对应的标准 Pod 安全性框架。
+
+<!--
+### What about sandboxed Pods?
+
+There is not currently an API standard that controls whether a Pod is considered sandboxed or
+not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata
+Containers), but there is no standard definition of what a sandboxed runtime is.
+
+The protections necessary for sandboxed workloads can differ from others. For example, the need to
+restrict privileged permissions is lessened when the workload is isolated from the underlying
+kernel. This allows for workloads requiring heightened permissions to still be isolated.
+
+Additionally, the protection of sandboxed workloads is highly dependent on the method of
+sandboxing. As such, no single recommended policy is recommended for all sandboxed workloads.
+-->
+### 沙箱（Sandboxed） Pod 怎么处理？
+
+现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。
+沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，不过
+目前还没有关于什么是沙箱化运行时的标准定义。
+
+沙箱化负载所需要的保护可能彼此各不相同。例如，当负载与下层内核直接隔离开来时，
+限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。
+
+此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
+因此，现在还没有针对所有沙箱化负载的建议策略。
+
diff --git a/content/zh/docs/concepts/services-networking/_index.md b/content/zh/docs/concepts/services-networking/_index.md
index b8cc1a2f58..f322d74216 100644
--- a/content/zh/docs/concepts/services-networking/_index.md
+++ b/content/zh/docs/concepts/services-networking/_index.md
@@ -1,4 +1,19 @@
 ---
 title: "服务、负载均衡和联网"
-weight: 80
+weight: 60
+description: Kubernetes 网络背后的概念和资源。
 ---
+
+<!--
+Kubernetes networking addresses four concerns:
+- Containers within a Pod use networking to communicate via loopback.
+- Cluster networking provides communication between different Pods.
+- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster.
+- You can also use Services to publish services only for consumption inside your cluster.
+-->
+
+Kubernetes 网络解决四方面的问题：
+- 一个 Pod 中的容器之间通过本地回路（loopback）通信。
+- 集群网络在不同 pod 之间提供通信。
+- Service 资源允许你对外暴露 Pods 中运行的应用程序，以支持来自于集群外部的访问。
+- 可以使用 Services 来发布仅供集群内部使用的服务。
\ No newline at end of file
diff --git a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
index 6db722eed5..4229689422 100644
--- a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+++ b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
@@ -2,52 +2,62 @@
 title: 使用 HostAliases 向 Pod /etc/hosts 文件添加条目
 content_type: concept
 weight: 60
+min-kubernetes-server-version: 1.7
 ---
 
-{{< toc >}}
+<!--
+reviewers:
+- rickypai
+- thockin
+title: Adding entries to Pod /etc/hosts with HostAliases
+content_type: concept
+weight: 60
+min-kubernetes-server-version: 1.7
+-->
 
 <!-- overview -->
 
 <!--
-Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. In 1.7, users can add these custom entries with the HostAliases field in PodSpec.
+Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
 
 Modification not using HostAliases is not suggested because the file is managed by Kubelet and can be overwritten on during Pod creation/restart.
 -->
+当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，
+可以在 Pod 级别覆盖对主机名的解析。你可以通过 PodSpec 的 HostAliases
+字段来添加这些自定义条目。
 
-当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。
-
-建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。
-
+建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且
+可以在 Pod 创建/重启过程中被重写。
 
 <!-- body -->
 
 <!--
 ## Default Hosts File Content
 
-Let's start an Nginx Pod which is assigned a Pod IP:
+Start an Nginx Pod which is assigned a Pod IP:
 -->
 ## 默认 hosts 文件内容
 
-让我们从一个 Nginx Pod 开始，给该 Pod 分配一个 IP：
+让我们从一个 Nginx Pod 开始，该 Pod 被分配一个 IP：
 
 ```shell
 kubectl run nginx --image nginx --generator=run-pod/v1
 ```
 
-```shell
+```
 pod/nginx created
 ```
 
 <!--
 Examine a Pod IP:
 -->
-检查Pod IP：
+检查 Pod IP：
 
 ```shell
 kubectl get pods --output=wide
 ```
 
-```shell
+```
 NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
 nginx    1/1       Running   0          13s    10.200.0.4   worker0
 ```
@@ -55,14 +65,13 @@ nginx    1/1       Running   0          13s    10.200.0.4   worker0
 <!--
 The hosts file content would look like this:
 -->
-
 主机文件的内容如下所示：
 
 ```shell
 kubectl exec nginx -- cat /etc/hosts
 ```
 
-```none
+```
 # Kubernetes-managed hosts file.
 127.0.0.1	localhost
 ::1	localhost ip6-localhost ip6-loopback
@@ -77,63 +86,63 @@ fe00::2	ip6-allrouters
 By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like
 `localhost` and its own hostname.
 -->
-默认，hosts 文件只包含 ipv4 和 ipv6 的样板内容，像 `localhost` 和主机名称。
+默认情况下，hosts 文件只包含 IPv4 和 IPv6 的样板内容，像 `localhost` 和主机名称。
 
 <!--
 ## Adding Additional Entries with HostAliases
 
 In addition to the default boilerplate, we can add additional entries to the
-`hosts` file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
-`bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under
+`hosts` file.
+For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
+`bar.remote` to `10.1.2.3`, we can configure HostAliases for a Pod under
 `.spec.hostAliases`:
 -->
+## 通过 HostAliases 增加额外条目
 
-## 通过 HostAliases 增加额外的条目
-
-除了默认的样板内容，我们可以向 hosts 文件添加额外的条目，将 `foo.local`、 `bar.local` 解析为`127.0.0.1`，
-将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在 `.spec.hostAliases` 下为 Pod 添加 HostAliases。
+除了默认的样板内容，我们可以向 hosts 文件添加额外的条目。
+例如，要将 `foo.local`、`bar.local` 解析为 `127.0.0.1`，
+将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在
+`.spec.hostAliases` 下为 Pod 配置 HostAliases。
 
 {{< codenew file="service/networking/hostaliases-pod.yaml" >}}
 
 <!--
-This Pod can be started with the following commands:
+You can start a Pod with that configuration by running:
 -->
-
-可以使用以下命令启动此Pod：
+你可以使用以下命令用此配置启动 Pod：
 
 ```shell
 kubectl apply -f hostaliases-pod.yaml
 ```
 
-```shell
+```
 pod/hostaliases-pod created
 ```
 
 <!--
-Examine a Pod IP and status:
+Examine a Pod's details to see its IPv4 address and its status:
 -->
-检查Pod IP 和状态：
+检查 Pod 详情，查看其 IPv4 地址和状态：
 
 ```shell
 kubectl get pod --output=wide
 ```
 
-```shell
-NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE
-hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0
+```
+NAME                READY     STATUS      RESTARTS   AGE       IP              NODE
+hostaliases-pod     0/1       Completed   0          6s        10.200.0.5      worker0
 ```
 
 <!--
-The `hosts` file content would look like this:
+The `hosts` file content looks like this:
 -->
-
 hosts 文件的内容看起来类似如下这样：
 
 ```shell
 kubectl logs hostaliases-pod
 ```
 
-```none
+```
 # Kubernetes-managed hosts file.
 127.0.0.1	localhost
 ::1	localhost ip6-localhost ip6-loopback
@@ -151,30 +160,31 @@ fe00::2	ip6-allrouters
 <!--
 With the additional entries specified at the bottom.
 -->
-
 在最下面额外添加了一些条目。
 
 <!--
-With the additional entries specified at the bottom.
-
 ## Why Does Kubelet Manage the Hosts File?
 
 Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
 `hosts` file for each container of the Pod to prevent Docker from
 [modifying](https://github.com/moby/moby/issues/17190) the file after the
 containers have already been started.
-
-Because of the managed-nature of the file, any user-written content will be
-overwritten whenever the `hosts` file is remounted by Kubelet in the event of
-a container restart or a Pod reschedule. Thus, it is not suggested to modify
-the contents of the file.
 -->
+## 为什么 kubelet 管理 hosts 文件？
 
-## 为什么 Kubelet 管理 hosts文件？
+kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod
+中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去
+[修改](https://github.com/moby/moby/issues/17190) 该文件。
 
-kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod 中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去 [修改](https://github.com/moby/moby/issues/17190) 该文件。
-
-因为该文件是托管性质的文件，无论容器重启或 Pod 重新调度，用户修改该 hosts 文件的任何内容，都会在 Kubelet 重新安装后被覆盖。因此，不建议修改该文件的内容。
+{{< caution >}}
+<!--
+Avoid making manual changes to the hosts file inside a container.
 
+If you make manual changes to the hosts file,
+those changes are lost when the container exits.
+-->
+请避免手工更改容器内的 hosts 文件内容。
 
+如果你对 hosts 文件做了手工修改，这些修改都会在容器退出时丢失。
+{{< /caution >}}
 
diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md
index 25bebe4d01..06d1744eb2 100644
--- a/content/zh/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md
@@ -205,9 +205,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
 
 Kubernetes supports 2 primary modes of finding a Service - environment variables
 and DNS. The former works out of the box while the latter requires the
-[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
+[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
 -->
-
 ## 访问 Service
 
 Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件]
diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md
index 48453424da..fc23f799ae 100644
--- a/content/zh/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md
@@ -42,8 +42,7 @@ considered implementation details and are subject to change without warning.
 For more up-to-date specification, see
 [Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
 -->
-
-## 怎样获取 DNS 名字?
+## 哪些对象会有 DNS 名字?     {#what-things-get-dns-names}
 
 在集群中定义的每个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。
 默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的名字空间和集群默认域。
@@ -74,7 +73,6 @@ Services, this resolves to the set of IPs of the pods selected by the Service.
 Clients are expected to consume the set or else use standard round-robin
 selection from the set.
 -->
-
 ### 服务  {#services}
 
 #### A/AAAA 记录
@@ -117,17 +115,35 @@ Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或
 <!--
 ### A/AAAA records
 
-Any pods created by a Deployment or DaemonSet have the following
-DNS resolution available:
+In general a pod has the following DNS resolution:
 
-`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
+`pod-ip-address.my-namespace.pod.cluster-domain.example`.
+
+For example, if a pod in the `default` namespace has the IP address 172.17.0.3,
+and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
+
+`172-17-0-3.default.pod.cluster.local`.
+
+Any pods created by a Deployment or DaemonSet exposed by a Service have the
+following DNS resolution available:
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
 -->
 ### A/AAAA 记录
 
-经由 Deployment 或者 DaemonSet 所创建的所有 Pods 都会有如下 DNS
-解析项与之对应：
+一般而言，Pod 会对应如下 DNS 名字解析：
 
-`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
+`pod-ip-address.my-namespace.pod.cluster-domain.example`
+
+例如，对于一个位于 `default` 名字空间，IP 地址为 172.17.0.3 的 Pod，
+如果集群的域名为 `cluster.local`，则 Pod 会对应 DNS 名称：
+
+`172-17-0-3.default.pod.cluster.local`.
+
+Deployment 或通过 Service 暴露出来的 DaemonSet 所创建的 Pod 会有如下 DNS
+解析名称可用：
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
 
 <!--
 ### Pod's hostname and subdomain fields
@@ -146,7 +162,6 @@ domain name (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`".
 
 Example:
 -->
-
 ### Pod 的 hostname 和 subdomain 字段
 
 当前，创建 Pod 时其主机名取自 Pod 的 `metadata.name` 值。
@@ -254,6 +269,51 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
 才会有与之对应的记录。
 {{< /note >}}
 
+<!--
+### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
+-->
+### Pod 的 setHostnameAsFQDN 字段  {#pod-sethostnameasfqdn-field}
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+<!--
+**Prerequisites**: The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+ The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+must be enabled for the
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
+
+When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and  the `hostname -fqdn` command returns the FQDN.
+-->
+**前置条件**：`SetHostnameAsFQDN`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+必须在 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
+上启用。
+
+当你在 Pod 规约中设置了 `setHostnameAsFQDN: true` 时，kubelet 会将 Pod
+的全限定域名（FQDN）作为该 Pod 的主机名记录到 Pod 所在名字空间。
+在这种情况下，`hostname` 和 `hostname --fqdn` 都会返回 Pod 的全限定域名。
+
+{{< note >}}
+<!--
+In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
+
+If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
+-->
+在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定
+最多 64 个字符。
+
+如果 Pod 启用这一特性，而其 FQDN 超出 64 字符，Pod 的启动会失败。
+Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerCreating`），
+并产生错误事件，例如 
+"Failed to construct FQDN from pod hostname and cluster domain, FQDN
+`long-FQDN` is too long (64 characters is the max, 70 characters requested)."
+（无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64
+字符，请求字符数为 70）。
+对于这种场景而言，改善用户体验的一种方式是创建一个
+[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)，
+在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。
+{{< /note >}}
+
 <!--
 ### Pod's DNS Policy
 
@@ -278,10 +338,15 @@ following pod-specific DNS policies. These policies are specified in the
   `dnsConfig` field in the Pod Spec.
   See [Pod's DNS config](#pod-s-dns-config) subsection below.
 -->
+### Pod 的 DNS 策略    {#pod-s-dns-policy}
 
-- "`Default`": Pod 从运行所在的节点继承名称解析配置。
-  参考[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。
-- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 “www.kubernetes.io”）
+DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。
+这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置：
+
+- "`Default`": Pod 从运行所在的节点继承名称解析配置。参考
+  [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
+  获取更多信息。
+- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"）
   都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
   参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
   了解在这些场景中如何处理 DNS 查询的信息。
@@ -293,10 +358,10 @@ following pod-specific DNS policies. These policies are specified in the
 
 <!--
 "Default" is not the default DNS policy. If `dnsPolicy` is not
-explicitly specified, then “ClusterFirst” is used.
+explicitly specified, then "ClusterFirst" is used.
 -->
 {{< note >}}
-"`Default`" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "`ClusterFirst`"。
+"Default" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "ClusterFirst"。
 {{< /note >}}
 
 <!--
diff --git a/content/zh/docs/concepts/services-networking/dual-stack.md b/content/zh/docs/concepts/services-networking/dual-stack.md
index f1bfba435f..c0c4402813 100644
--- a/content/zh/docs/concepts/services-networking/dual-stack.md
+++ b/content/zh/docs/concepts/services-networking/dual-stack.md
@@ -89,6 +89,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
 
    * kube-apiserver:
       * `--feature-gates="IPv6DualStack=true"`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
    * kube-controller-manager:
       * `--feature-gates="IPv6DualStack=true"`
       * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` 例如 `--cluster-cidr=10.244.0.0/16,fc00::/48`
@@ -175,13 +176,13 @@ On cloud providers which support IPv6 enabled external load balancers, setting t
 ## 出口流量
 
 <!--
-The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
+The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-sigsr/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
 -->
-公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层
-{{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。
+可以使用可公共路由和非可公共路由的 IPv6 地址块，前提是下层的
+{{< glossary_tooltip text="CNI" term_id="cni" >}} 提供程序可以实现这种传输。
 如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的
 （比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。
-[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈，
+[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 可以感知双栈，
 所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。
 
 <!--
@@ -190,9 +191,9 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac
 ## 已知问题
 
 <!--
-   * Kubenet forces IPv4,IPv6 positional reporting of IPs (-cluster-cidr)
+* Kubenet forces IPv4,IPv6 positional reporting of IPs (-cluster-cidr)
 -->
-   * Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`)
+* Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`)
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh/docs/concepts/services-networking/endpoint-slices.md
index d788da3d7d..f83b8154a9 100644
--- a/content/zh/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/zh/docs/concepts/services-networking/endpoint-slices.md
@@ -1,23 +1,13 @@
 ---
 title: 端点切片（Endpoint Slices）
-feature:
-  title: 端点切片
-  description: >
-    Kubernetes 集群中网络端点的可扩展跟踪。
-
 content_type: concept
-weight: 10
+weight: 35
 ---
 
 <!--
 title: Endpoint Slices
-feature:
-  title: Endpoint Slices
-  description: >
-    Scalable tracking of network endpoints in a Kubernetes cluster.
-
 content_type: concept
-weight: 10
+weight: 35
 -->
 
 <!-- overview -->
@@ -34,14 +24,50 @@ _端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kube
 
 <!-- body -->
 
+<!--
+## Motivation
+
+The Endpoints API has provided a simple and straightforward way of
+tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
+and {{< glossary_tooltip text="Services" term_id="service" >}} have grown to handle and
+send more traffic to more backend Pods, limitations of that original API became
+more visible.
+Most notably, those included challenges with scaling to larger numbers of
+network endpoints.
+-->
+## 动机    {#motivation}
+
+Endpoints API 提供了在 Kubernetes 跟踪网络端点的一种简单而直接的方法。
+不幸的是，随着 Kubernetes 集群和 {{< glossary_tooltip text="服务" term_id="service" >}}
+逐渐开始为更多的后端 Pods 处理和发送请求，原来的 API 的局限性变得越来越明显。
+最重要的是那些因为要处理大量网络端点而带来的挑战。
+
+<!--
+Since all network endpoints for a Service were stored in a single Endpoints
+resource, those resources could get quite large. That affected the performance
+of Kubernetes components (notably the master control plane) and resulted in
+significant amounts of network traffic and processing when Endpoints changed.
+EndpointSlices help you mitigate those issues as well as provide an extensible
+platform for additional features such as topological routing.
+-->
+由于任一服务的所有网络端点都保存在同一个 Endpoints 资源中，这类资源可能变得
+非常巨大，而这一变化会影响到 Kubernetes 组件（比如主控组件）的性能，并
+在 Endpoints 变化时需要处理大量的网络流量和处理。
+EndpointSlice 能够帮助你缓解这一问题，还能为一些诸如拓扑路由这类的额外
+功能提供一个可扩展的平台。
+
 <!--
 ## Endpoint Slice resources {#endpointslice-resource}
 
 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
-Slices group network endpoints together by unique Service and Port combinations.
+endpoints. The control plane automatically creates EndpointSlices
+for any Kubernetes Service that has a {{< glossary_tooltip text="selector"
+term_id="selector" >}} specified. These EndpointSlices include
+references to any Pods that match the Service selector. EndpointSlices group
+network endpoints together by unique combinations of protocol, port number, and
+Service name.  
+The name of a EndpointSlice object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 As an example, here's a sample EndpointSlice resource for the `example`
 Kubernetes Service.
@@ -49,10 +75,14 @@ Kubernetes Service.
 ## Endpoint Slice 资源 {#endpointslice-resource}
 
 在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。
-指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。
-这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。
+指定选择器后控制面会自动为设置了 {{< glossary_tooltip text="选择算符" term_id="selector" >}}
+的 Kubernetes 服务创建 EndpointSlice。
+这些 EndpointSlice 将包含对与服务选择算符匹配的所有 Pod 的引用。
+EndpointSlice 通过唯一的协议、端口号和服务名称将网络端点组织在一起。
+EndpointSlice 的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
-例如，这里是 Kubernetes服务 `example` 的示例 EndpointSlice 资源。
+例如，下面是 Kubernetes 服务 `example` 的 EndpointSlice 资源示例。
 
 ```yaml
 apiVersion: discovery.k8s.io/v1beta1
@@ -78,19 +108,25 @@ endpoints:
 ```
 
 <!--
-By default, Endpoint Slices managed by the EndpointSlice controller will have no
-more than 100 endpoints each. Below this scale, Endpoint Slices should map 1:1
-with Endpoints and Services and have similar performance.
+By default, the control plane creates and manages EndpointSlices to have no
+more than 100 endpoints each. You can configure this with the
+`-max-endpoints-per-slice`
+{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
+flag, up to a maximum of 1000.
 
-Endpoint Slices can act as the source of truth for kube-proxy when it comes to
+EndpointSlices can act as the source of truth for
+{{< glossary_tooltip term_id="kube-proxy" text="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.
 -->
-默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个端点。
-低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1:1 映射，并具有相似的性能。
+默认情况下，控制面创建和管理的 EndpointSlice 将包含不超过 100 个端点。
+你可以使用 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
+的 `--max-endpoints-per-slice` 标志设置此值，最大值为 1000。
 
-当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。
-启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。
+当涉及如何路由内部流量时，EndpointSlice 可以充当
+{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} 
+的决策依据。
+启用该功能后，在服务的端点数量庞大时会有可观的性能提升。
 
 <!--
 ## Address Types
@@ -110,33 +146,222 @@ EndpointSlice 支持三种地址类型：
 * FQDN (完全合格的域名)
 
 <!--
-## Motivation
+### Topology information {#topology}
 
-The Endpoints API has provided a simple and straightforward way of
-tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
-and Services have gotten larger, limitations of that API became more visible.
-Most notably, those included challenges with scaling to larger numbers of
-network endpoints.
-
-Since all network endpoints for a Service were stored in a single Endpoints
-resource, those resources could get quite large. That affected the performance
-of Kubernetes components (notably the master control plane) and resulted in
-significant amounts of network traffic and processing when Endpoints changed.
-Endpoint Slices help you mitigate those issues as well as provide an extensible
-platform for additional features such as topological routing.
+Each endpoint within an EndpointSlice can contain relevant topology information.
+This is used to indicate where an endpoint is, containing information about the
+corresponding Node, zone, and region. When the values are available, the
+control plane sets the following Topology labels for EndpointSlices:
 -->
-## 动机
+### 拓扑信息   {#topology}
 
-Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。
-不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。
-最值得注意的是，这包含了扩展到更多网络端点的挑战。
+EndpointSlice 中的每个端点都可以包含一定的拓扑信息。
+这一信息用来标明端点的位置，包含对应节点、可用区、区域的信息。
+当这些值可用时，控制面会为 EndpointSlice 设置如下拓扑标签：
 
-由于服务的所有网络端点都存储在单个 Endpoints 资源中，
-因此这些资源可能会变得很大。
-这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints 
-发生更改时导致大量网络流量和处理。
-Endpoint Slices 可帮助您缓解这些问题并提供可扩展的
-附加特性（例如拓扑路由）平台。
+<!--
+* `kubernetes.io/hostname` - The name of the Node this endpoint is on.
+* `topology.kubernetes.io/zone` - The zone this endpoint is in.
+* `topology.kubernetes.io/region` - The region this endpoint is in.
+-->
+* `kubernetes.io/hostname` - 端点所在的节点名称
+* `topology.kubernetes.io/zone` - 端点所处的可用区
+* `topology.kubernetes.io/region` - 端点所处的区域
+
+<!--
+The values of these labels are derived from resources associated with each
+endpoint in a slice. The hostname label represents the value of the NodeName
+field on the corresponding Pod. The zone and region labels represent the value
+of the labels with the same names on the corresponding Node.
+-->
+这些标签的值时根据与切片中各个端点相关联的资源来生成的。
+标签 `hostname` 代表的是对应的 Pod 的 NodeName 字段的取值。
+`zone` 和 `region` 标签则代表的是对应的节点所拥有的同名标签的值。
+
+<!--
+### Management
+
+Most often, the control plane (specifically, the endpoint slice
+{{< glossary_tooltip text="controller" term_id="controller" >}}) creates and
+manages EndpointSlice objects. There are a variety of other use cases for
+EndpointSlices, such as service mesh implementations, that could result in other
+entities or controllers managing additional sets of EndpointSlices.
+-->
+### 管理   {#management}
+
+通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="controller" term_id="controller" >}}）
+会创建和管理 EndpointSlice 对象。EndpointSlice 对象还有一些其他使用场景，
+例如作为服务网格（Service Mesh）的实现。这些场景都会导致有其他实体
+或者控制器负责管理额外的 EndpointSlice 集合。
+
+<!--
+To ensure that multiple entities can manage EndpointSlices without interfering
+with each other, Kubernetes defines the
+{{< glossary_tooltip term_id="label" text="label" >}}
+`endpointslice.kubernetes.io/managed-by`, which indicates the entity managing
+an EndpointSlice.
+The endpoint slice controller sets `endpointslice-controller.k8s.io` as the value
+for this label on all EndpointSlices it manages. Other entities managing
+EndpointSlices should also set a unique value for this label.
+-->
+为了确保多个实体可以管理 EndpointSlice 而且不会相互产生干扰，Kubernetes 定义了
+{{< glossary_tooltip term_id="label" text="标签" >}}
+`endpointslice.kubernetes.io/managed-by`，用来标明哪个实体在管理某个
+EndpointSlice。端点切片控制器会在自己所管理的所有 EndpointSlice 上将该标签值设置
+为 `endpointslice-controller.k8s.io`。
+管理 EndpointSlice 的其他实体也应该为此标签设置一个唯一值。
+
+<!--
+### Ownership
+
+In most use cases, EndpointSlices are owned by the Service that the endpoint
+slice object tracks endpoints for. This ownership is indicated by an owner
+reference on each EndpointSlice as well as a `kubernetes.io/service-name`
+label that enables simple lookups of all EndpointSlices belonging to a Service.
+-->
+### 属主关系   {#ownership}
+
+在大多数场合下，EndpointSlice 都由某个 Service 所有，（因为）该端点切片正是
+为该服务跟踪记录其端点。这一属主关系是通过为每个 EndpointSlice 设置一个
+属主（owner）引用，同时设置 `kubernetes.io/service-name` 标签来标明的，
+目的是方便查找隶属于某服务的所有 EndpointSlice。
+
+<!--
+### EndpointSlice mirroring
+
+In some cases, applications create custom Endpoints resources. To ensure that
+these applications do not need to concurrently write to both Endpoints and
+EndpointSlice resources, the cluster's control plane mirrors most Endpoints
+resources to corresponding EndpointSlices.
+-->
+### EndpointSlice 镜像    {#endpointslice-mirroring}
+
+在某些场合，应用会创建定制的 Endpoints 资源。为了保证这些应用不需要并发
+递更改 Endpoints 和 EndpointSlice 资源，集群的控制面将大多数 Endpoints
+映射到对应的 EndpointSlice 之上。
+
+<!--
+The control plane mirrors Endpoints resources unless:
+
+* the Endpoints resource has a `endpointslice.kubernetes.io/skip-mirror` label
+  set to `true`.
+* the Endpoints resource has a `control-plane.alpha.kubernetes.io/leader`
+  annotation.
+* the corresponding Service resource does not exist.
+* the corresponding Service resource has a non-nil selector.
+-->
+控制面对 Endpoints 资源进行映射的例外情况有：
+
+* Endpoints 资源上标签 `endpointslice.kubernetes.io/skip-mirror` 值为 `true`。
+* Endpoints 资源包含标签 `control-plane.alpha.kubernetes.io/leader`。
+* 对应的 Service 资源不存在。
+* 对应的 Service 的选择算符不为空。
+
+<!--
+Individual Endpoints resources may translate into multiple EndpointSlices. This
+will occur if an Endpoints resource has multiple subsets or includes endpoints
+with multiple IP families (IPv4 and IPv6). A maximum of 1000 addresses per
+subset will be mirrored to EndpointSlices.
+-->
+每个 Endpoints 资源可能会被翻译到多个 EndpointSlices 中去。
+当 Endpoints 资源中包含多个子网或者包含多个 IP 地址族（IPv4 和 IPv6）的端点时，
+就有可能发生这种状况。
+每个子网最多有 1000 个地址会被镜像到 EndpointSlice 中。
+
+<!--
+### Distribution of EndpointSlices
+
+Each EndpointSlice has a set of ports that applies to all endpoints within the
+resource. When named ports are used for a Service, Pods may end up with
+different target port numbers for the same named port, requiring different
+EndpointSlices. This is similar to the logic behind how subsets are grouped
+with Endpoints.
+-->
+### EndpointSlices 的分布问题  {#distribution-of-endpointslices}
+
+每个 EndpointSlice 都有一组端口值，适用于资源内的所有端点。
+当为服务使用命名端口时，Pod 可能会就同一命名端口获得不同的端口号，因而需要
+不同的 EndpointSlice。这有点像 Endpoints 用来对子网进行分组的逻辑。
+
+<!--
+The control plane tries to fill EndpointSlices as full as possible, but does not
+actively rebalance them. The logic is fairly straightforward:
+
+1. Iterate through existing EndpointSlices, remove endpoints that are no longer
+   desired and update matching endpoints that have changed.
+2. Iterate through EndpointSlices that have been modified in the first step and
+   fill them up with any new endpoints needed.
+3. If there's still new endpoints left to add, try to fit them into a previously
+   unchanged slice and/or create new ones.
+-->
+控制面尝试尽量将 EndpointSlice 填满，不过不会主动地在若干 EndpointSlice 之间
+执行再平衡操作。这里的逻辑也是相对直接的：
+
+1. 列举所有现有的 EndpointSlices，移除那些不再需要的端点并更新那些已经
+   变化的端点。
+2. 列举所有在第一步中被更改过的 EndpointSlices，用新增加的端点将其填满。
+3. 如果还有新的端点未被添加进去，尝试将这些端点添加到之前未更改的切片中，
+   或者创建新切片。
+
+<!--
+Importantly, the third step prioritizes limiting EndpointSlice updates over a
+perfectly full distribution of EndpointSlices. As an example, if there are 10
+new endpoints to add and 2 EndpointSlices with room for 5 more endpoints each,
+this approach will create a new EndpointSlice instead of filling up the 2
+existing EndpointSlices. In other words, a single EndpointSlice creation is
+preferrable to multiple EndpointSlice updates.
+-->
+这里比较重要的是，与在 EndpointSlice 之间完成最佳的分布相比，第三步中更看重
+限制 EndpointSlice 更新的操作次数。例如，如果有 10 个端点待添加，有两个
+EndpointSlice 中各有 5 个空位，上述方法会创建一个新的 EndpointSlice 而不是
+将现有的两个 EndpointSlice 都填满。换言之，与执行多个 EndpointSlice 更新操作
+相比较，方法会优先考虑执行一个 EndpointSlice 创建操作。
+
+<!--
+With kube-proxy running on each Node and watching EndpointSlices, every change
+to an EndpointSlice becomes relatively expensive since it will be transmitted to
+every Node in the cluster. This approach is intended to limit the number of
+changes that need to be sent to every Node, even if it may result with multiple
+EndpointSlices that are not full.
+-->
+由于 kube-proxy 在每个节点上运行并监视 EndpointSlice 状态，EndpointSlice 的
+每次变更都变得相对代价较高，因为这些状态变化要传递到集群中每个节点上。
+这一方法尝试限制要发送到所有节点上的变更消息个数，即使这样做可能会导致有
+多个 EndpointSlice 没有被填满。
+
+<!--
+In practice, this less than ideal distribution should be rare. Most changes
+processed by the EndpointSlice controller will be small enough to fit in an
+existing EndpointSlice, and if not, a new EndpointSlice is likely going to be
+necessary soon anyway. Rolling updates of Deployments also provide a natural
+repacking of EndpointSlices with all Pods and their corresponding endpoints
+getting replaced.
+-->
+在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice 控制器
+处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。并且，假使无法
+添加到已有的切片中，不管怎样都会快就会需要一个新的 EndpointSlice 对象。
+Deployment 的滚动更新为重新为 EndpointSlice 打包提供了一个自然的机会，所有
+Pod 及其对应的端点在这一期间都会被替换掉。
+
+<!--
+### Duplicate endpoints
+
+Due to the nature of EndpointSlice changes, endpoints may be represented in more
+than one EndpointSlice at the same time. This naturally occurs as changes to
+different EndpointSlice objects can arrive at the Kubernetes client watch/cache
+at different times. Implementations using EndpointSlice must be able to have the
+endpoint appear in more than one slice. A reference implementation of how to
+perform endpoint deduplication can be found in the `EndpointSliceCache`
+implementation in `kube-proxy`.
+-->
+### 重复的端点   {#duplicate-endpoints}
+
+由于 EndpointSlice 变化的自身特点，端点可能会同时出现在不止一个 EndpointSlice
+中。鉴于不同的 EndpointSlice 对象在不同时刻到达 Kubernetes 的监视/缓存中，
+这种情况的出现是很自然的。
+使用 EndpointSlice 的实现必须能够处理端点出现在多个切片中的状况。
+关于如何执行端点去重（deduplication）的参考实现，你可以在 `kube-proxy` 的
+`EndpointSlice` 实现中找到。
 
 ## {{% heading "whatsnext" %}}
 
@@ -144,6 +369,6 @@ Endpoint Slices 可帮助您缓解这些问题并提供可扩展的
 * [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 -->
-* [启用端点切片](/zh/docs/tasks/administer-cluster/enabling-endpointslices)
-* 阅读[使用服务链接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
+* 了解[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices)
+* 阅读[使用服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
 
diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md
index 4071ea6189..6b31e610d6 100644
--- a/content/zh/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md
@@ -25,7 +25,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
 为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
 
 与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。
-基于此页面，您可选择最适合您的集群的 ingress 控制器实现。
+基于此页面，你可选择最适合你的集群的 ingress 控制器实现。
 
 Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 
 和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
@@ -42,7 +42,7 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
 * [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/).
-* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). 
+* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](https://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).
 * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
 * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
   provided and supported by VMware.
@@ -95,7 +95,8 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
 * [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
   [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
-* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
+
+* [Traefik](https://github.com/traefik/traefik) is a fully featured ingress controller
   ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
   support by [Containous](https://containo.us/services).
 -->
@@ -107,9 +108,9 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
   [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
   提供支持和维护。
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。
-* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器
+* [Traefik](https://github.com/traefik/traefik) 是一个全功能的 Ingress 控制器。
   （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），
-  并且它也有来自 [Containous](https://containo.us/services) 的商业支持。
+  并且它也有来自 [Traefik Labs](https://traefik.io) 的商业支持。
 
 <!--
 ## Using multiple Ingress controllers
@@ -141,7 +142,7 @@ controllers operate slightly differently.
 Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
 -->
 {{< note >}}
-确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
+确保你查看了 ingress 控制器的文档，以了解选择它的注意事项。
 {{< /note >}}
 
 ## {{% heading "whatsnext" %}}
diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md
index 254f04cba2..e3dd00dede 100644
--- a/content/zh/docs/concepts/services-networking/ingress.md
+++ b/content/zh/docs/concepts/services-networking/ingress.md
@@ -10,20 +10,18 @@ weight: 40
 -->
 
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.1" state="beta" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
 {{< glossary_definition term_id="ingress" length="all" >}}
 
-
 <!-- body -->
 
 <!--
 ## Terminology
+
+For clarity, this guide defines the following terms:
 -->
 ## 术语
 
-<!-- 
-For clarity, this guide defines the following terms:
--->
 为了表达更加清晰，本指南定义了以下术语：
 
 <!-- 
@@ -36,35 +34,48 @@ For clarity, this guide defines the following terms:
 * 节点（Node）: Kubernetes 集群中其中一台工作机器，是集群的一部分。
 * 集群（Cluster）: 一组运行由 Kubernetes 管理的容器化应用程序的节点。
   在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。
-* 边缘路由器（Edge router）: 在集群中强制执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。
+* 边缘路由器（Edge router）: 在集群中强制执行防火墙策略的路由器（router）。
+  可以是由云提供商管理的网关，也可以是物理硬件。
 * 集群网络（Cluster network）: 一组逻辑的或物理的连接，根据 Kubernetes
   [网络模型](/zh/docs/concepts/cluster-administration/networking/) 在集群内实现通信。
 * 服务（Service）：Kubernetes {{< glossary_tooltip text="服务" term_id="service" >}}使用
-  {{< glossary_tooltip text="标签" term_id="label" >}} 选择算符（selectors）标识的一组 Pod。
+  {{< glossary_tooltip text="标签" term_id="label" >}}选择算符（selectors）标识的一组 Pod。
   除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
 
 <!--
 ## What is Ingress?
--->
-## Ingress 是什么？
 
-<!--
 [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) exposes HTTP and HTTPS routes from outside the cluster to
 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
 Traffic routing is controlled by rules defined on the Ingress resource.
 -->
+## Ingress 是什么？
 
 [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
 公开了从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。
 流量路由由 Ingress 资源上定义的规则控制。
 
-```none
-    internet
-        |
-   [ Ingress ]
-   --|-----|--
-   [ Services ]
-```
+<!--
+Here is a simple example where an Ingress sends all its traffic to one Service:
+-->
+下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例：
+
+{{< mermaid >}}
+graph LR;
+  client([客户端])-. Ingress-管理的 <br> 负载均衡器 .->ingress[Ingress];
+  ingress-->|路由规则|service[Service];
+  subgraph cluster
+  ingress;
+  service-->pod1[Pod];
+  service-->pod2[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service,pod1,pod2 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 <!-- 
 An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
@@ -111,7 +122,7 @@ controllers operate slightly differently.
 Make sure you review your Ingress controller's documentation to understand the caveats of choosing it.
 -->
 {{< note >}}
-确保您查看了 Ingress 控制器的文档，以了解选择它的注意事项。
+确保你查看了 Ingress 控制器的文档，以了解选择它的注意事项。
 {{< /note >}}
 
 <!--
@@ -119,27 +130,12 @@ Make sure you review your Ingress controller's documentation to understand the c
 
 A minimal Ingress resource example:
 -->
-## Ingress 资源
+## Ingress 资源  {#the-ingress-resource}
 
 一个最小的 Ingress 资源示例：
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - http:
-      paths:
-      - path: /testpath
-        pathType: Prefix
-        backend:
-          serviceName: test
-          servicePort: 80
-```
+
+{{< codenew file="service/networking/minimal-ingress.yaml" >}}
 
 <!-- 
 As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
@@ -159,7 +155,7 @@ Different [Ingress controller](/docs/concepts/services-networking/ingress-contro
  Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如
 [重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。
  不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
-支持不同的注解。查看文档以供您选择 Ingress 控制器，以了解支持哪些注解。
+支持不同的注解。查看文档以供你选择 Ingress 控制器，以了解支持哪些注解。
 
 <!-- 
 The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
@@ -174,12 +170,11 @@ Ingress 资源仅支持用于转发 HTTP 流量的规则。
 
 <!-- 
 ### Ingress rules
+
+Each HTTP rule contains the following information:
 -->
 ### Ingress 规则  {#ingress-rules}
 
-<!--
-Each HTTP rule contains the following information:
--->
 每个 HTTP 规则都包含以下信息：
 
 <!-- 
@@ -193,69 +188,112 @@ Each HTTP rule contains the following information:
   [Service doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
   Ingress that matches the host and path of the rule are sent to the listed backend.
 -->
-* 可选主机。在此示例中，未指定主机，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。
-  如果提供了主机（例如 foo.bar.com），则规则适用于该主机。
-* 路径列表（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。
+* 可选的 `host`。在此示例中，未指定 `host`，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。
+  如果提供了 `host`（例如 foo.bar.com），则 `rules` 适用于该 `host`。
+* 路径列表 paths（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。
   在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
-* 后端是 [Service 文档](/zh/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
-  与规则的主机和路径匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的后端。
+* `backend`（后端）是 [Service 文档](/zh/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
+  与规则的 `host` 和 `path` 匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的 `backend`。
 
 <!-- 
-A default backend is often configured in an Ingress controller to service any requests that do not
+A `defaultBackend` is often configured in an Ingress controller to service any requests that do not
 match a path in the spec. 
 -->
-通常在 Ingress 控制器中会配置默认后端，以服务任何不符合规范中路径的请求。
+通常在 Ingress 控制器中会配置 `defaultBackend`（默认后端），以服务于任何不符合规约中 `path` 的请求。
 
 <!-- 
-### Default Backend
+### DefaultBackend {#default-backend}
 
-An Ingress with no rules sends all traffic to a single default backend. The default
-backend is typically a configuration option of the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) and is not specified in your Ingress resources.
+An Ingress with no rules sends all traffic to a single default backend. The `defaultBackend` is conventionally a configuration option of the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) and is not specified in your Ingress resources.
 -->
-### 默认后端
+### DefaultBackend  {#default-backend}
 
-没有规则的 Ingress 将所有流量发送到同一个默认后端。
-默认后端通常是 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
-的配置选项，并且未在 Ingress 资源中指定。
+没有 `rules` 的 Ingress 将所有流量发送到同一个默认后端。
+`defaultBackend` 通常是 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
+的配置选项，而非在 Ingress 资源中指定。
 
 <!--
 If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is
 routed to your default backend.
 -->
-如果主机或路径都没有与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到默认后端。
+如果 `hosts` 或 `paths` 都没有与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到默认后端。
+
+<!--
+### Resource backends {#resource-backend}
+
+A `Resource` backend is an ObjectRef to another Kubernetes resource within the
+same namespace as the Ingress object. A `Resource` is a mutually exclusive
+setting with Service, and will fail validation if both are specified. A common
+usage for a `Resource` backend is to ingress data to an object storage backend
+with static assets.
+-->
+### 资源后端  {#resource-backend}
+
+`Resource` 后端是一个 `ObjectRef`，指向同一名字空间中的另一个
+Kubernetes，将其作为 Ingress 对象。`Resource` 与 `Service` 配置是互斥的，在
+二者均被设置时会无法通过合法性检查。
+`Resource` 后端的一种常见用法是将所有入站数据导向带有静态资产的对象存储后端。
+
+{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
+
+<!--
+After creating the Ingress above, you can view it with the following command:
+-->
+创建了如上的 Ingress 之后，你可以使用下面的命令查看它：
+
+```bash
+kubectl describe ingress ingress-resource-backend
+```
+
+```
+Name:             ingress-resource-backend
+Namespace:        default
+Address:
+Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
+Rules:
+  Host        Path  Backends
+  ----        ----  --------
+  *
+              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
+Annotations:  <none>
+Events:       <none>
+```
 
 <!-- 
 ### Path Types
 
-Each path in an Ingress has a corresponding path type. There are three supported
-path types:
+Each path in an Ingress is required to have a corresponding path type. Paths
+that do not include an explicit `pathType` will fail validation. There are three
+supported path types:
 -->
 ### 路径类型  {#path-types}
 
-Ingress 中的每个路径都有对应的路径类型。当前支持的路径类型有三种：
+Ingress 中的每个路径都需要有对应的路径类型（Path Type）。未明确设置 `pathType`
+的路径无法通过合法性检查。当前支持的路径类型有三种：
 
 <!-- 
-* _`ImplementationSpecific`_ (default): With this path type, matching is up to
+* `ImplementationSpecific`: With this path type, matching is up to
   the IngressClass. Implementations can treat this as a separate `pathType` or
   treat it identically to `Prefix` or `Exact` path types.
 
-* _`Exact`_: Matches the URL path exactly and with case sensitivity.
+* `Exact`: Matches the URL path exactly and with case sensitivity.
 
-* _`Prefix`_: Matches based on a URL path prefix split by `/`. Matching is case
+* `Prefix`: Matches based on a URL path prefix split by `/`. Matching is case
   sensitive and done on a path element by element basis. A path element refers
   to the list of labels in the path split by the `/` separator. A request is a
   match for path _p_ if every _p_ is an element-wise prefix of _p_ of the
   request path.
-    If the last element of the path is a substring of the
-    last element in request path, it is not a match (for example:
-    `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
+
+  If the last element of the path is a substring of the last
+  element in request path, it is not a match (for example: `/foo/bar`
+  matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
  -->
-* _`ImplementationSpecific`_ （默认）：对于这种类型，匹配取决于 IngressClass。
+* `ImplementationSpecific`：对于这种路径类型，匹配方法取决于 IngressClass。
   具体实现可以将其作为单独的 `pathType` 处理或者与 `Prefix` 或 `Exact` 类型作相同处理。
 
-* _`Exact`_：精确匹配 URL 路径，且对大小写敏感。
+* `Exact`：精确匹配 URL 路径，且区分大小写。
 
-* _`Prefix`_：基于以 `/` 分隔的 URL 路径前缀匹配。匹配对大小写敏感，并且对路径中的元素逐个完成。
+* `Prefix`：基于以 `/` 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个完成。
   路径元素指的是由 `/` 分隔符分隔的路径中的标签列表。
   如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。
 
@@ -264,8 +302,56 @@ Ingress 中的每个路径都有对应的路径类型。当前支持的路径类
   （例如：`/foo/bar` 匹配 `/foo/bar/baz`, 但不匹配 `/foo/barbaz`）。
   {{< /note >}}
 
+<!--
+### Examples
+
+| Kind   | Path(s)                         | Request path(s)             | Matches?                           |
+|--------|---------------------------------|-----------------------------|------------------------------------|
+| Prefix | `/`                             | (all paths)                 | Yes                                |
+| Exact  | `/foo`                          | `/foo`                      | Yes                                |
+| Exact  | `/foo`                          | `/bar`                      | No                                 |
+| Exact  | `/foo`                          | `/foo/`                     | No                                 |
+| Exact  | `/foo/`                         | `/foo`                      | No                                 |
+| Prefix | `/foo`                          | `/foo`, `/foo/`             | Yes                                |
+| Prefix | `/foo/`                         | `/foo`, `/foo/`             | Yes                                |
+| Prefix | `/aaa/bb`                       | `/aaa/bbb`                  | No                                 |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb`                  | Yes                                |
+| Prefix | `/aaa/bbb/`                     | `/aaa/bbb`                  | Yes, ignores trailing slash        |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/`                 | Yes,  matches trailing slash       |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/ccc`              | Yes, matches subpath               |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbbxyz`               | No, does not match string prefix   |
+| Prefix | `/`, `/aaa`                     | `/aaa/ccc`                  | Yes, matches `/aaa` prefix         |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/aaa/bbb`                  | Yes, matches `/aaa/bbb` prefix     |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/ccc`                      | Yes, matches `/` prefix            |
+| Prefix | `/aaa`                          | `/ccc`                      | No, uses default backend           |
+| Mixed  | `/foo` (Prefix), `/foo` (Exact) | `/foo`                      | Yes, prefers Exact                 |
+-->
+### 示例
+
+| 类型   | 路径                            | 请求路径        | 匹配与否？               |
+|--------|---------------------------------|-----------------|--------------------------|
+| Prefix | `/`                             | （所有路径）    | 是                       |
+| Exact  | `/foo`                          | `/foo`          | 是                       |
+| Exact  | `/foo`                          | `/bar`          | 否                       |
+| Exact  | `/foo`                          | `/foo/`         | 否                       |
+| Exact  | `/foo/`                         | `/foo`          | 否                       |
+| Prefix | `/foo`                          | `/foo`, `/foo/` | 是                       |
+| Prefix | `/foo/`                         | `/foo`, `/foo/` | 是                       |
+| Prefix | `/aaa/bb`                       | `/aaa/bbb`      | 否                       |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb`      | 是                       |
+| Prefix | `/aaa/bbb/`                     | `/aaa/bbb`      | 是，忽略尾部斜线         |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/`     | 是，匹配尾部斜线         |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/ccc`  | 是，匹配子路径           |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbbxyz`   | 否，字符串前缀不匹配     |
+| Prefix | `/`, `/aaa`                     | `/aaa/ccc`      | 是，匹配 `/aaa` 前缀     |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/aaa/bbb`      | 是，匹配 `/aaa/bbb` 前缀 |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/ccc`          | 是，匹配 `/` 前缀        |
+| Prefix | `/aaa`                          | `/ccc`          | 否，使用默认后端         |
+| 混合   | `/foo` (Prefix), `/foo` (Exact) | `/foo`          | 是，优选 Exact 类型      |
+
 <!-- 
 #### Multiple Matches
+
 In some cases, multiple paths within an Ingress will match a request. In those
 cases precedence will be given first to the longest matching path. If two paths
 are still equally matched, precedence will be given to paths with an exact path
@@ -277,8 +363,38 @@ type over prefix path type.
 这种情况下最长的匹配路径优先。
 如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。
 
+<!--
+## Hostname wildcards
+
+Hosts can be precise matches (for example “`foo.bar.com`”) or a wildcard (for
+example “`*.foo.com`”). Precise matches require that the HTTP `host` header
+matches the `host` field. Wildcard matches require the HTTP `host` header is
+equal to the suffix of the wildcard rule.
+-->
+## 主机名通配符   {#hostname-wildcards}
+
+主机名可以是精确匹配（例如“`foo.bar.com`”）或者使用通配符来匹配
+（例如“`*.foo.com`”）。
+精确匹配要求 HTTP `host` 头部字段与 `host` 字段值完全匹配。
+通配符匹配则要求 HTTP `host` 头部字段与通配符规则中的后缀部分相同。
+
+<!--
+| Host         | Host header        | Match?                                              |
+| ------------ |--------------------| ----------------------------------------------------|
+| `*.foo.com`  | `bar.foo.com`      | Matches based on shared suffix                      |
+| `*.foo.com`  | `baz.bar.foo.com`  | No match, wildcard only covers a single DNS label   |
+| `*.foo.com`  | `foo.com`          | No match, wildcard only covers a single DNS label   |
+-->
+| 主机         | host 头部          | 匹配与否？                          |
+| ------------ |--------------------| ------------------------------------|
+| `*.foo.com`  | `bar.foo.com`      | 基于相同的后缀匹配                  |
+| `*.foo.com`  | `baz.bar.foo.com`  | 不匹配，通配符仅覆盖了一个 DNS 标签 |
+| `*.foo.com`  | `foo.com`          | 不匹配，通配符仅覆盖了一个 DNS 标签 |
+
+{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
+
 <!-- 
-## Ingress Class
+## Ingress class
 
 Ingresses can be implemented by different controllers, often with different
 configuration. Each Ingress should specify a class, a reference to an
@@ -291,24 +407,13 @@ Ingress 可以由不同的控制器实现，通常使用不同的配置。
 每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。
 IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: IngressClass
-metadata:
-  name: external-lb
-spec:
-  controller: example.com/ingress-controller
-  parameters:
-    apiGroup: k8s.example.com/v1alpha
-    kind: IngressParameters
-    name: external-lb
-```
+{{< codenew file="service/networking/external-lb.yaml" >}}
 
 <!-- 
 IngressClass resources contain an optional parameters field. This can be used to
 reference additional configuration for this class.
  -->
-IngressClass 资源包含一个可选的参数字段，可用于为该类引用额外配置。
+IngressClass 资源包含一个可选的 `parameters` 字段，可用于为该类引用额外配置。
 
 <!-- 
 ### Deprecated Annotation
@@ -318,7 +423,7 @@ Kubernetes 1.18, Ingress classes were specified with a
 `kubernetes.io/ingress.class` annotation on the Ingress. This annotation was
 never formally defined, but was widely supported by Ingress controllers.
 -->
-### 废弃的注解
+### 废弃的注解  {#deprecated-annotation}
 
 在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前，
 Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。
@@ -337,7 +442,7 @@ Ingress 中新的 `ingressClassName` 字段是该注解的替代品，但并非
 包括 Ingress 控制器的名称。
 
 <!-- 
-### Default Ingress Class
+### Default IngressClass {#default-ingress-class}
 
 You can mark a particular IngressClass as default for your cluster. Setting the
 `ingressclass.kubernetes.io/is-default-class` annotation to `true` on an
@@ -346,7 +451,7 @@ IngressClass resource will ensure that new Ingresses without an
 -->
 ### 默认 Ingress 类  {#default-ingress-class}
 
-您可以将一个特定的 IngressClass 标记为集群默认选项。
+你可以将一个特定的 IngressClass 标记为集群默认 Ingress 类。
 将一个 IngressClass 资源的 `ingressclass.kubernetes.io/is-default-class` 注解设置为
 `true` 将确保新的未指定 `ingressClassName` 字段的 Ingress 能够分配为这个默认的
 IngressClass.
@@ -358,15 +463,15 @@ an `ingressClassName` specified. You can resolve this by ensuring that at most 1
 IngressClasess are marked as default in your cluster.
  -->
 {{< caution >}}
-如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 `ingressClassName`
-的 Ingress 对象。
+如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定
+`ingressClassName` 的 Ingress 对象。
 解决这个问题只需确保集群中最多只能有一个 IngressClass 被标记为默认。
 {{< /caution >}}
 
 <!--
 ## Types of Ingress
 
-### Single Service Ingress
+### Ingress backed by a single Service {#single-service-ingress}
 
 There are existing Kubernetes concepts that allow you to expose a single Service
 (see [alternatives](#alternatives)). You can also do this with an Ingress by specifying a
@@ -374,26 +479,26 @@ There are existing Kubernetes concepts that allow you to expose a single Service
 -->
 ## Ingress 类型  {#types-of-ingress}
 
-### 单服务 Ingress   {#single-service-ingress}
+### 由单个 Service 来完成的 Ingress   {#single-service-ingress}
 
-现有的 Kubernetes 概念允许您暴露单个 Service (查看[替代方案](#alternatives))。
+现有的 Kubernetes 概念允许你暴露单个 Service (参见[替代方案](#alternatives))。
 你也可以通过指定无规则的 *默认后端* 来对 Ingress 进行此操作。
 
-{{< codenew file="service/networking/ingress.yaml" >}}
+{{< codenew file="service/networking/test-ingress.yaml" >}}
 
 <!-- 
 If you create it using `kubectl apply -f` you should be able to view the state
 of the Ingress you just added:
 -->
-如果使用 `kubectl apply -f` 创建它，则应该能够查看刚刚添加的 Ingress 的状态：
+如果使用 `kubectl apply -f` 创建此 Ingress，则应该能够查看刚刚添加的 Ingress 的状态：
 
 ```shell
 kubectl get ingress test-ingress
 ```
 
 ```
-NAME           HOSTS     ADDRESS           PORTS     AGE
-test-ingress   *         203.0.113.123     80        59s
+NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
+test-ingress   external-lb   *       203.0.113.123   80      59s
 ```
 
 <!-- 
@@ -407,8 +512,8 @@ Ingress controllers and load balancers may take a minute or two to allocate an I
 Until that time, you often see the address listed as `<pending>`.
 -->
 {{< note >}}
-入口控制器和负载平衡器可能需要一两分钟才能分配 IP 地址。在此之前，您通常会看到地址字段的值被设定为
-`<pending>`。
+入口控制器和负载平衡器可能需要一两分钟才能分配 IP 地址。
+在此之前，你通常会看到地址字段的值被设定为 `<pending>`。
 {{< /note >}}
 
 <!--
@@ -418,42 +523,37 @@ A fanout configuration routes traffic from a single IP address to more than one
 based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
 down to a minimum. For example, a setup like:
 -->
-### 简单分列
+### 简单扇出  {#simple-fanout}
 
-一个分列配置根据请求的 HTTP URI 将流量从单个 IP 地址路由到多个服务。
-Ingress 允许您将负载均衡器的数量降至最低。例如，这样的设置：
+一个扇出（fanout）配置根据请求的 HTTP URI 将来自同一 IP 地址的流量路由到多个 Service。
+Ingress 允许你将负载均衡器的数量降至最低。例如，这样的设置：
 
-```none
-foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
-                                 / bar    service2:8080
-```
+{{< mermaid >}}
+graph LR;
+  client([客户端])-. Ingress-管理的 <br> 负载均衡器 .->ingress[Ingress, 178.91.123.132];
+  ingress-->|/foo|service1[Service service1:4200];
+  ingress-->|/bar|service2[Service service2:8080];
+  subgraph cluster
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 <!--
 would require an Ingress such as:
 -->
 将需要一个如下所示的 Ingress：
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: simple-fanout-example
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - path: /foo
-        backend:
-          serviceName: service1
-          servicePort: 4200
-      - path: /bar
-        backend:
-          serviceName: service2
-          servicePort: 8080
-```
+{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
 
 <!--
 When you create the Ingress with `kubectl apply -f`:
@@ -489,8 +589,9 @@ that satisfies the Ingress, as long as the Services (`service1`, `service2`) exi
 When it has done so, you can see the address of the load balancer at the
 Address field.
 -->
-Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress，只要 Service (`service1`，`service2`) 存在。
-当它这样做了，你会在地址字段看到负载均衡器的地址。
+Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress，
+只要 Service (`service1`，`service2`) 存在。
+当它这样做时，你会在 Address 字段看到负载均衡器的地址。
 
 <!--
 Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers)
@@ -498,7 +599,7 @@ you are using, you may need to create a default-http-backend
 [Service](/docs/concepts/services-networking/service/).
 -->
 {{< note >}}
-取决于你使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)，
+取决于你所使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)，
 你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。
 {{< /note >}}
 
@@ -507,15 +608,29 @@ you are using, you may need to create a default-http-backend
 
 Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
 -->
-### 基于名称的虚拟托管
+### 基于名称的虚拟托管   {#name-based-virtual-hosting}
 
 基于名称的虚拟主机支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上。
 
-```none
-foo.bar.com --|                 |-> foo.bar.com service1:80
-              | 178.91.123.132  |
-bar.foo.com --|                 |-> bar.foo.com service2:80
-```
+{{< mermaid >}}
+graph LR;
+  client([客户端])-. Ingress-管理的 <br> 负载均衡器 .->ingress[Ingress, 178.91.123.132];
+  ingress-->|Host: foo.bar.com|service1[Service service1:80];
+  ingress-->|Host: bar.foo.com|service2[Service service2:80];
+  subgraph cluster
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 <!--
 The following Ingress tells the backing load balancer to route requests based on
@@ -524,78 +639,37 @@ the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
 以下 Ingress 让后台负载均衡器基于[host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4)
 来路由请求。
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: bar.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-```
+{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
 
 <!-- 
 If you create an Ingress resource without any hosts defined in the rules, then any
 web traffic to the IP address of your Ingress controller can be matched without a name based
 virtual host being required.
 -->
-如果您创建的 Ingress 资源没有规则中定义的任何主机，则可以匹配指向 Ingress 控制器 IP 地址
-的任何网络流量，而无需基于名称的虚拟主机。
+如果你创建的 Ingress 资源没有在 `rules` 中定义的任何 `hosts`，则可以匹配指向
+Ingress 控制器 IP 地址的任何网络流量，而无需基于名称的虚拟主机。
 
 <!-- 
-For example, the following Ingress resource will route traffic
+For example, the following Ingress routes traffic
 requested for `first.bar.com` to `service1`, `second.foo.com` to `service2`, and any traffic
 to the IP address without a hostname defined in request (that is, without a request header being
 presented) to `service3`.
 -->
-例如，以下 Ingress 资源会将 `first.bar.com` 请求的流量路由到 `service1`，
-将 `second.foo.com` 请求的流量路由到 `service2`，
-而没有在请求中定义主机名的 IP 地址的流量路由（即，不提供请求标头）到 `service3`。
+例如，以下 Ingress 会将针对 `first.bar.com` 的请求流量路由到 `service1`，
+将针对 `second.foo.com` 的请求流量路由到 `service2`，
+而针对该 IP 地址的、没有在请求中定义主机名的请求流量会被路由（即，不提供请求标头）
+到 `service3`。
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: first.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: second.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-  - http:
-      paths:
-      - backend:
-          serviceName: service3
-          servicePort: 80
-```
+{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
 
 <!--
 ### TLS
 
 You can secure an Ingress by specifying a {{< glossary_tooltip term_id="secret" >}}
-that contains a TLS private key and certificate. Currently the Ingress only
-supports a single TLS port, 443, and assumes TLS termination. If the TLS
-configuration section in an Ingress specifies different hosts, they are
+that contains a TLS private key and certificate. The Ingress resource only
+supports a single TLS port, 443, and assumes TLS termination at the ingress point
+(traffic to the Service and its Pods is in plaintext).
+If the TLS configuration section in an Ingress specifies different hosts, they are
 multiplexed on the same port according to the hostname specified through the
 SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret
 must contain keys named `tls.crt` and `tls.key` that contain the certificate
@@ -605,8 +679,8 @@ and private key to use for TLS. For example:
 
 你可以通过设定包含 TLS 私钥和证书的{{< glossary_tooltip text="Secret" term_id="secret" >}}
 来保护 Ingress。
-目前，Ingress 只支持单个 TLS 端口 443，并假定 TLS 终止。
-
+Ingress 只支持单个 TLS 端口 443，并假定 TLS 连接终止于 Ingress 节点
+（与 Service 及其 Pod 之间的流量都以明文传输）。
 如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名
 （如果 Ingress 控制器支持 SNI）在同一端口上进行复用。
 TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的键名。
@@ -619,8 +693,8 @@ metadata:
   name: testsecret-tls
   namespace: default
 data:
-  tls.crt: base64 encoded cert
-  tls.key: base64 encoded key
+  tls.crt: base64 编码的 cert
+  tls.key: base64 编码的 key
 type: kubernetes.io/tls
 ```
 
@@ -628,31 +702,25 @@ type: kubernetes.io/tls
 Referencing this secret in an Ingress tells the Ingress controller to
 secure the channel from the client to the load balancer using TLS. You need to make
 sure the TLS secret you created came from a certificate that contains a Common
-Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `sslexample.foo.com`.
+Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `https-example.foo.com`.
 -->
 在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。
-你需要确保创建的 TLS Secret 来自包含 `sslexample.foo.com` 的公用名称（CN）的证书。
+你需要确保创建的 TLS Secret 创建自包含 `sslexample.foo.com` 的公用名称（CN）的证书。
 这里的公共名称也被称为全限定域名（FQDN）。
 
-```yaml
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: tls-example-ingress
-spec:
-  tls:
-  - hosts:
-    - sslexample.foo.com
-    secretName: testsecret-tls
-  rules:
-    - host: sslexample.foo.com
-      http:
-        paths:
-        - path: /
-          backend:
-            serviceName: service1
-            servicePort: 80
-```
+{{< note >}}
+<!--
+Keep in mind that TLS will not work on the default rule because the
+certificates would have to be issued for all the possible sub-domains. Therefore,
+`hosts` in the `tls` section need to explicitly match the `host` in the `rules`
+section.
+-->
+注意，默认规则上无法使用 TLS，因为需要为所有可能的子域名发放证书。
+因此，`tls` 节区的 `hosts` 的取值需要域 `rules` 节区的 `host`
+完全匹配。
+{{< /note >}}
+
+{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
 
 <!-- 
 There is a gap between TLS features supported by various Ingress
@@ -669,7 +737,7 @@ platform specific Ingress controller to understand how TLS works in your environ
 {{< /note >}}
 
 <!--
-### Loadbalancing
+### Load Balancing   {#load-balancing}
 
 An Ingress controller is bootstrapped with some load balancing policy settings
 that it applies to all Ingress, such as the load balancing algorithm, backend
@@ -678,7 +746,7 @@ weight scheme, and others. More advanced load balancing concepts
 Ingress. You can instead get these features through the load balancer used for
 a Service.
 -->
-### 负载均衡
+### 负载均衡  {#load-balancing}
 
 Ingress 控制器启动引导时使用一些适用于所有 Ingress 的负载均衡策略设置，
 例如负载均衡算法、后端权重方案和其他等。
@@ -694,19 +762,21 @@ specific documentation to see how they handle health checks (
 [nginx](https://git.k8s.io/ingress-nginx/README.md),
 [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
 -->
-值得注意的是，即使健康检查不是通过 Ingress 直接暴露的，在 Kubernetes
-中存在并行概念，比如[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
+值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes
+中存在并行的概念，比如
+[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)，
 允许你实现相同的目的。
-请检查特定控制器的说明文档，以了解它们是怎样处理健康检查的 (
+请检查特定控制器的说明文档（
 [nginx](https://git.k8s.io/ingress-nginx/README.md)，
-[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）
+以了解它们是怎样处理健康检查的。
 
 <!--
 ## Updating an Ingress
 
 To update an existing Ingress to add a new Host, you can update it by editing the resource:
 -->
-## 更新 Ingress
+## 更新 Ingress   {#updating-an-ingress}
 
 要更新现有的 Ingress 以添加新的 Host，可以通过编辑资源来对其进行更新：
 
@@ -753,6 +823,7 @@ spec:
           serviceName: service1
           servicePort: 80
         path: /foo
+        pathType: Prefix
   - host: bar.baz.com
     http:
       paths:
@@ -760,6 +831,7 @@ spec:
           serviceName: service2
           servicePort: 80
         path: /foo
+        pathType: Prefix
 ..
 ```
 
@@ -808,28 +880,13 @@ You can achieve the same outcome by invoking `kubectl replace -f` on a modified
 ## Failing across availability zones
 
 Techniques for spreading traffic across failure domains differs between cloud providers.
-Please check the documentation of the relevant [Ingress controller](/docs/concepts/services-networking/ingress-controllers) for details. You can also refer to the [federation documentation](https://github.com/kubernetes-sigs/federation-v2)
-for details on deploying Ingress in a federated cluster.
+Please check the documentation of the relevant [Ingress controller](/docs/concepts/services-networking/ingress-controllers) for details.
 -->
 ## 跨可用区失败  {#failing-across-availability-zones}
 
 不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。
-请查看相关[ Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 的文档以了解详细信息。
-你还可以参考[联邦文档](https://github.com/kubernetes-sigs/federation-v2)，以获取有关在联合集群中部署 Ingress 的详细信息。
-
-<!--
-## Future Work
-
-Track [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
-for more details on the evolution of Ingress and related resources. You may also track the
-[Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the
-evolution of various Ingress controllers.
--->
-## 未来工作
-跟踪 [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
-的活动以获得有关 Ingress 和相关资源演变的更多细节。
-你还可以跟踪 [Ingress 仓库](https://github.com/kubernetes/ingress/tree/master)
-以获取有关各种 Ingress 控制器的更多细节。
+请查看相关 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
+的文档以了解详细信息。
 
 <!--
 ## Alternatives
@@ -844,17 +901,17 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
 * Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
 * Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
 -->
-* 使用 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
-* 使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
+* 使用 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer)
+* 使用 [Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport)
 
 ## {{% heading "whatsnext" %}}
 
 <!--
-* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
+* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)
 * Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
-* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
+* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
 -->
 * 进一步了解 [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
 * 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
-* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)
+* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube/)
 
diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md
index 784455922a..6ea89e28f4 100644
--- a/content/zh/docs/concepts/services-networking/network-policies.md
+++ b/content/zh/docs/concepts/services-networking/network-policies.md
@@ -10,19 +10,43 @@ content_type: concept
 weight: 50
 -->
 
-{{< toc >}}
-
 <!-- overview -->
 
 <!--
-A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints.
-
-NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods.
+If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network.
 -->
+如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量，
+则你可以考虑为集群中特定应用使用 Kubernetes 网络策略（NetworkPolicy）。
+NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许
+{{< glossary_tooltip text="Pod" term_id="pod">}} 与网络上的各类网络“实体”
+（我们这里使用实体以避免过度使用诸如“端点”和“服务”这类常用术语，
+这些术语在 Kubernetes 中有特定含义）通信。
 
-网络策略（NetworkPolicy）是一种关于 {{< glossary_tooltip text="Pod" term_id="pod">}} 间及与其他网络端点间所允许的通信规则的规范。
+<!--
+The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers:
 
-NetworkPolicy 资源使用 {{< glossary_tooltip text="标签" term_id="label">}} 选择 Pod，并定义选定 Pod 所允许的通信规则。
+1. Other pods that are allowed (exception: a pod cannot block access to itself)
+2. Namespaces that are allowed
+3. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node)
+-->
+Pod 可以通信的 Pod 是通过如下三个标识符的组合来辩识的：
+
+1. 其他被允许的 Pods（例外：Pod 无法阻塞对自身的访问）
+2. 被允许的名字空间
+3. IP 组块（例外：与 Pod 运行所在的节点的通信总是被允许的，
+   无论 Pod 或节点的 IP 地址）
+
+<!--
+When defining a pod- or namespace- based NetworkPolicy, you use a {{< glossary_tooltip text="selector" term_id="selector">}} to specify what traffic is allowed to and from the Pod(s) that match the selector.
+
+Meanwhile, when IP based NetworkPolicies are created, we define policies based on IP blocks (CIDR ranges).
+-->
+在定义基于 Pod 或名字空间的 NetworkPolicy 时，你会使用 
+{{< glossary_tooltip text="选择算符" term_id="selector">}} 来设定哪些流量
+可以进入或离开与该算符匹配的 Pod。
+
+同时，当基于 IP 的 NetworkPolicy 被创建时，我们基于 IP 组块（CIDR 范围）
+来定义策略。
 
 <!-- body -->
 
@@ -31,12 +55,11 @@ NetworkPolicy 资源使用 {{< glossary_tooltip text="标签" term_id="label">}}
 
 Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect.
 -->
-
-## 前提
+## 前置条件   {#prerequisites}
 
 网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
-来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。
-创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。
+来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。
+创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。
 
 <!--
 ## Isolated and Non-isolated Pods
@@ -47,17 +70,18 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is
 
 Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
 -->
-## 隔离和非隔离的 Pod
+## 隔离和非隔离的 Pod   {#isolated-and-non-isolated-pods}
 
 默认情况下，Pod 是非隔离的，它们接受任何来源的流量。
 
-Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，
-该 Pod 会拒绝网络策略所不允许的连接。 
-（命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量）
+Pod 在被某 NetworkPolicy 选中时进入被隔离状态。
+一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy
+所不允许的连接。 
+（名字空间下其他未被 NetworkPolicy 所选择的 Pod 会继续接受所有的流量）
 
 网络策略不会冲突，它们是累积的。
 如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的
-ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。
+入站（Ingress）/出站（Egress）规则的并集。因此评估的顺序并不会影响策略的结果。
 
 <!--
 ## The NetworkPolicy resource {#networkpolicy-resource}
@@ -66,10 +90,10 @@ See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "vers
 
 An example NetworkPolicy might look like this:
 -->
-
 ## NetworkPolicy 资源 {#networkpolicy-resource}
 
-查看 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。
+参阅 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)
+来了解资源的完整定义。
 
 下面是一个 NetworkPolicy 的示例:
 
@@ -127,27 +151,41 @@ and [Object Management](/docs/concepts/overview/working-with-objects/object-mana
 __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
 
 __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace.
+-->
+__必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、
+`kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考
+[使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/),
+和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。
 
+__spec__：NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
+中包含了在一个名字空间中定义特定网络策略所需的所有信息。
+
+__podSelector__：每个 NetworkPolicy 都包括一个 `podSelector`，它对该策略所
+适用的一组 Pod 进行选择。示例中的策略选择带有 "role=db" 标签的 Pod。
+空的 `podSelector` 选择名字空间下的所有 Pod。
+
+<!--
 __policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules.
 
-__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules.  Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
+__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules.  Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
 
-__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules.  Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
+__egress__: Each NetworkPolicy may include a list of allowed `egress` rules.  Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
 -->
 
-__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、`kind` 和 `metadata` 字段。
-  关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/),
-  和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。
+__policyTypes__: 每个 NetworkPolicy 都包含一个 `policyTypes` 列表，其中包含
+`Ingress` 或 `Egress` 或两者兼具。`policyTypes` 字段表示给定的策略是应用于
+进入所选 Pod 的入站流量还是来自所选 Pod 的出站流量，或两者兼有。
+如果 NetworkPolicy 未指定 `policyTypes` 则默认情况下始终设置 `Ingress`；
+如果 NetworkPolicy 有任何出口规则的话则设置 `Egress`。
 
-__spec__: NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 中包含了在一个命名空间中定义特定网络策略所需的所有信息。
+__ingress__: 每个 NetworkPolicy 可包含一个 `ingress` 规则的白名单列表。
+每个规则都允许同时匹配 `from` 和 `ports` 部分的流量。示例策略中包含一条
+简单的规则： 它匹配某个特定端口，来自三个来源中的一个，第一个通过 `ipBlock`
+指定，第二个通过 `namespaceSelector` 指定，第三个通过 `podSelector` 指定。
 
-__podSelector__: 每个 NetworkPolicy 都包括一个 `podSelector` ，它对该策略所应用的一组 Pod 进行选择。示例中的策略选择带有 "role=db" 标签的 Pod。空的 `podSelector` 选择命名空间下的所有 Pod。
-
-__policyTypes__: 每个 NetworkPolicy 都包含一个 `policyTypes` 列表，其中包含 `Ingress` 或 `Egress` 或两者兼具。`policyTypes` 字段表示给定的策略是否应用于进入所选 Pod 的入口流量或者来自所选 Pod 的出口流量，或两者兼有。如果 NetworkPolicy 未指定 `policyTypes` 则默认情况下始终设置 `Ingress`，如果 NetworkPolicy 有任何出口规则的话则设置 `Egress`。
-
-__ingress__: 每个 NetworkPolicy 可包含一个 `ingress` 规则的白名单列表。每个规则都允许同时匹配 `from` 和 `ports` 部分的流量。示例策略中包含一条简单的规则： 它匹配一个单一的端口，来自三个来源中的一个， 第一个通过 `ipBlock` 指定，第二个通过 `namespaceSelector` 指定，第三个通过 `podSelector` 指定。
-
-__egress__: 每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列表。每个规则都允许匹配 `to` 和 `port` 部分的流量。该示例策略包含一条规则，该规则将单个端口上的流量匹配到 `10.0.0.0/24` 中的任何目的地。
+__egress__: 每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列表。
+每个规则都允许匹配 `to` 和 `port` 部分的流量。该示例策略包含一条规则，
+该规则将指定端口上的流量匹配到 `10.0.0.0/24` 中的任何目的地。
 
 <!--
 So, the example NetworkPolicy:
@@ -162,18 +200,22 @@ So, the example NetworkPolicy:
 
 See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples.
 -->
-
 所以，该网络策略示例:
 
-1. 隔离 "default" 命名空间下 "role=db" 的 Pod (如果它们不是已经被隔离的话)。
-2. （Ingress 规则）允许以下 Pod 连接到 "default" 命名空间下的带有 “role=db” 标签的所有 Pod 的 6379 TCP 端口：
+1. 隔离 "default" 名字空间下 "role=db" 的 Pod （如果它们不是已经被隔离的话）。
+2. （Ingress 规则）允许以下 Pod 连接到 "default" 名字空间下的带有 "role=db"
+   标签的所有 Pod 的 6379 TCP 端口：
 
-  * "default" 命名空间下任意带有 "role=frontend" 标签的 Pod
-  * 带有 "project=myproject" 标签的任意命名空间中的 Pod
-  * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16）
-3. （Egress 规则）允许从带有 "role=db" 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。
+   * "default" 名字空间下带有 "role=frontend" 标签的所有 Pod
+   * 带有 "project=myproject" 标签的所有名字空间中的 Pod
+   * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255
+     （即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16）
 
-查看[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练。
+3. （Egress 规则）允许从带有 "role=db" 标签的名字空间下的任何 Pod 到 CIDR
+   10.0.0.0/24 下 5978 TCP 端口的连接。
+
+参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)演练
+了解更多示例。
 
 <!--
 ## Behavior of `to` and `from` selectors
@@ -186,16 +228,19 @@ __namespaceSelector__: This selects particular namespaces for which all Pods sho
 
 __namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax; this policy:
 -->
+## 选择器 `to` 和 `from` 的行为   {#behavior-of-to-and-from-selectors}
 
-## 选择器 `to` 和 `from` 的行为
+可以在 `ingress` 的 `from` 部分或 `egress` 的 `to` 部分中指定四种选择器：
 
-可以在 `ingress` `from` 部分或 `egress` `to` 部分中指定四种选择器：
+__podSelector__: 此选择器将在与 NetworkPolicy 相同的名字空间中选择特定的
+Pod，应将其允许作为入站流量来源或出站流量目的地。
 
-__podSelector__: 这将在与 NetworkPolicy 相同的命名空间中选择特定的 Pod，应将其允许作为入口源或出口目的地。
+__namespaceSelector__：此选择器将选择特定的名字空间，应将所有 Pod 用作其
+入站流量来源或出站流量目的地。
 
-__namespaceSelector__: 这将选择特定的命名空间，应将所有 Pod 用作其输入源或输出目的地。
-
-__namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定命名空间中的特定 Pod。注意使用正确的 YAML 语法；这项策略：
+__namespaceSelector__ *和* __podSelector__： 一个指定 `namespaceSelector`
+和 `podSelector` 的 `to`/`from` 条目选择特定名字空间中的特定 Pod。
+注意使用正确的 YAML 语法；下面的策略：
 
 ```yaml
   ...
@@ -213,7 +258,8 @@ __namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 
 <!-- 
 contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy:
  -->
-在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod 且该 Pod 所在的命名空间中标有 `user=alice` 的连接。但是 *这项* 策略：
+在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod 且
+该 Pod 所在的名字空间中标有 `user=alice` 的连接。但是 *这项* 策略：
 
 ```yaml
   ...
@@ -230,7 +276,11 @@ contains a single `from` element allowing connections from Pods with the label `
 
 <!--
 contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`.
+-->
+在 `from` 数组中包含两个元素，允许来自本地名字空间中标有 `role=client` 的
+Pod 的连接，*或* 来自任何名字空间中标有 `user=alice` 的任何 Pod 的连接。
 
+<!--
 When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy.
 
 __ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.
@@ -247,18 +297,21 @@ the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node
 For egress, this means that connections from pods to `Service` IPs that get rewritten to
 cluster-external IPs may or may not be subject to `ipBlock`-based policies.
 -->
-
-在 `from` 数组中包含两个元素，允许来自本地命名空间中标有 `role=client` 的 Pod 的连接，*或* 来自任何命名空间中标有 `user = alice` 的任何 Pod 的连接。
-
 如有疑问，请使用 `kubectl describe` 查看 Kubernetes 如何解释该策略。
 
-__ipBlock__: 这将选择特定的 IP CIDR 范围以用作入口源或出口目的地。 这些应该是群集外部 IP，因为 Pod IP 存在时间短暂的且随机产生。
+__ipBlock__: 此选择器将选择特定的 IP CIDR 范围以用作入站流量来源或出站流量目的地。
+这些应该是集群外部 IP，因为 Pod IP 存在时间短暂的且随机产生。
 
-群集的入口和出口机制通常需要重写数据包的源 IP 或目标 IP。在发生这种情况的情况下，不确定在 NetworkPolicy 处理之前还是之后发生，并且对于网络插件，云提供商，`Service` 实现等的不同组合，其行为可能会有所不同。
+集群的入站和出站机制通常需要重写数据包的源 IP 或目标 IP。
+在发生这种情况时，不确定在 NetworkPolicy 处理之前还是之后发生，
+并且对于网络插件、云提供商、`Service` 实现等的不同组合，其行为可能会有所不同。
 
-在进入的情况下，这意味着在某些情况下，您可以根据实际的原始源 IP 过滤传入的数据包，而在其他情况下，NetworkPolicy 所作用的 `源IP` 则可能是 `LoadBalancer` 或 Pod 的节点等。
+对入站流量而言，这意味着在某些情况下，你可以根据实际的原始源 IP 过滤传入的数据包，
+而在其他情况下，NetworkPolicy 所作用的 `源IP` 则可能是 `LoadBalancer` 或
+Pod 的节点等。
 
-对于出口，这意味着从 Pod 到被重写为集群外部 IP 的 `Service` IP 的连接可能会或可能不会受到基于 `ipBlock` 的策略的约束。
+对于出站流量而言，这意味着从 Pod 到被重写为集群外部 IP 的 `Service` IP
+的连接可能会或可能不会受到基于 `ipBlock` 的策略的约束。
 
 <!--
 ## Default policies
@@ -266,37 +319,38 @@ __ipBlock__: 这将选择特定的 IP CIDR 范围以用作入口源或出口目
 By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior
 in that namespace.
 -->
+## 默认策略   {#default-policies}
 
-## 默认策略
-
-默认情况下，如果命名空间中不存在任何策略，则所有进出该命名空间中的 Pod 的流量都被允许。以下示例使您可以更改该命名空间中的默认行为。
+默认情况下，如果名字空间中不存在任何策略，则所有进出该名字空间中 Pod 的流量都被允许。
+以下示例使你可以更改该名字空间中的默认行为。
 
 <!--
 ### Default deny all ingress traffic
 
 You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods.
 -->
+### 默认拒绝所有入站流量
 
-### 默认拒绝所有入口流量
-
-您可以通过创建选择所有容器但不允许任何进入这些容器的入口流量的 NetworkPolicy 来为命名空间创建 "default" 隔离策略。
+你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy 
+来为名字空间创建 "default" 隔离策略。
 
 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
 
 <!--
 This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior.
 -->
-这样可以确保即使容器没有选择其他任何 NetworkPolicy，也仍然可以被隔离。此策略不会更改默认的出口隔离行为。
+这样可以确保即使容器没有选择其他任何 NetworkPolicy，也仍然可以被隔离。
+此策略不会更改默认的出口隔离行为。
 
 <!--
 ### Default allow all ingress traffic
 
 If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace.
 -->
+### 默认允许所有入站流量
 
-### 默认允许所有入口流量
-
-如果要允许所有流量进入某个命名空间中的所有 Pod（即使添加了导致某些 Pod 被视为“隔离”的策略），则可以创建一个策略来明确允许该命名空间中的所有流量。
+如果要允许所有流量进入某个名字空间中的所有 Pod（即使添加了导致某些 Pod 被视为
+“隔离”的策略），则可以创建一个策略来明确允许该名字空间中的所有流量。
 
 {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
 
@@ -305,10 +359,10 @@ If you want to allow all traffic to all pods in a namespace (even if policies ar
 
 You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.
 -->
+### 默认拒绝所有出站流量
 
-### 默认拒绝所有出口流量
-
-您可以通过创建选择所有容器但不允许来自这些容器的任何出口流量的 NetworkPolicy 来为命名空间创建 "default" egress 隔离策略。
+你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy 
+来为名字空间创建 "default" egress 隔离策略。
 
 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
 
@@ -316,18 +370,18 @@ You can create a "default" egress isolation policy for a namespace by creating a
 This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not
 change the default ingress isolation behavior.
 -->
-
-这样可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。此策略不会更改默认的 ingress 隔离行为。
+此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。
+此策略不会更改默认的入站流量隔离行为。
 
 <!--
 ### Default allow all egress traffic
 
 If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace.
 -->
+### 默认允许所有出站流量
 
-### 默认允许所有出口流量
-
-如果要允许来自命名空间中所有 Pod 的所有流量（即使添加了导致某些 Pod 被视为“隔离”的策略），则可以创建一个策略，该策略明确允许该命名空间中的所有出口流量。
+如果要允许来自名字空间中所有 Pod 的所有流量（即使添加了导致某些 Pod 被视为“隔离”的策略），
+则可以创建一个策略，该策略明确允许该名字空间中的所有出站流量。
 
 {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
 
@@ -336,41 +390,91 @@ If you want to allow all traffic from all pods in a namespace (even if policies
 
 You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.
 -->
+### 默认拒绝所有入口和所有出站流量
 
-### 默认拒绝所有入口和所有出口流量
-
-您可以为命名空间创建 "default" 策略，以通过在该命名空间中创建以下 NetworkPolicy 来阻止所有入站和出站流量。
+你可以为名字空间创建“默认”策略，以通过在该名字空间中创建以下 NetworkPolicy
+来阻止所有入站和出站流量。
 
 {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
 
 <!--
 This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic.
 -->
-
-这样可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许进入或流出流量。
+此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被
+允许入站或出站流量。
 
 <!--
 ## SCTP support
 -->
 ## SCTP 支持
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 <!--
-To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.
+As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=SCTPSupport=false,...`.
 When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.
 -->
-要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…`
-来启用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
-启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
+作为一个 Beta 特性，SCTP 支持默认是被启用的。
+要在集群层面禁用 SCTP，你（或你的集群管理员）需要为 API 服务器指定
+`--feature-gates=SCTPSupport=false,...`
+来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
 
 <!-- 
 You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
  -->
 {{< note >}}
-必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
+你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
 {{< /note >}}
 
+<!--
+## What you can't do with network policies (at least, not yet)
+
+As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.  Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API.
+-->
+## 你通过网络策略（至少目前还）无法完成的工作
+
+到 Kubernetes v1.20 为止，NetworkPolicy API 还不支持以下功能，不过
+你可能可以使用操作系统组件（如 SELinux、OpenVSwitch、IPTables 等等）
+或者第七层技术（Ingress 控制器、服务网格实现）或准入控制器来实现一些
+替代方案。
+如果你对 Kubernetes 中的网络安全性还不太了解，了解使用 NetworkPolicy API
+还无法实现下面的用户场景是很值得的。
+对这些用户场景中的一部分（而非全部）的讨论扔在进行，或许在将来 NetworkPolicy
+API 中会给出一定支持。
+
+<!--
+- Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy).
+- Anything TLS related (use a service mesh or ingress controller for this).
+- Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically).
+- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround).
+- Creation or management of "Policy requests" that are fulfilled by a third party.
+-->
+- 强制集群内部流量经过某公用网关（这种场景最好通过服务网格或其他代理来实现）；
+- 与 TLS 相关的场景（考虑使用服务网格或者 Ingress 控制器）；
+- 特定于节点的策略（你可以使用 CIDR 来表达这一需求不过你无法使用节点在
+  Kubernetes 中的其他标识信息来辩识目标节点）；
+- 基于名字来选择名字空间或者服务（不过，你可以使用 {{< glossary_tooltip text="标签" term_id="label" >}}
+  来选择目标 Pod 或名字空间，这也通常是一种可靠的替代方案）；
+- 创建或管理由第三方来实际完成的“策略请求”；
+<!--
+- Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this).
+- Advanced policy querying and reachability tooling.
+- The ability to target ranges of Ports in a single policy declaration.
+- The ability to log network security events (for example connections that are blocked or accepted).
+- The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules).
+- The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node).
+-->
+- 实现适用于所有名字空间或 Pods 的默认策略（某些第三方 Kubernetes 发行版本
+  或项目可以做到这点）；
+- 高级的策略查询或者可达性相关工具；
+- 在同一策略声明中选择目标端口范围的能力；
+- 生成网络安全事件日志的能力（例如，被阻塞或接收的连接请求）；
+- 显式地拒绝策略的能力（目前，NetworkPolicy 的模型默认采用拒绝操作，
+  其唯一的能力是添加允许策略）；
+- 禁止本地回路或指向宿主的网络流量（Pod 目前无法阻塞 localhost 访问，
+  它们也无法禁止来自所在节点的访问请求）。
+
 ## {{% heading "whatsnext" %}}
 
 <!--
@@ -378,9 +482,8 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha
   walkthrough for further examples.
 - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
 -->
-
-- 查看 [声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
-  来进行更多的示例演练
-- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见
+- 参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+  演练了解更多示例；
+- 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见
   [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。
 
diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md
index 294738085d..3155ca8751 100644
--- a/content/zh/docs/concepts/services-networking/service.md
+++ b/content/zh/docs/concepts/services-networking/service.md
@@ -3,7 +3,7 @@ title: 服务
 feature:
   title: 服务发现与负载均衡
   description: >
-    无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。
+    无需修改你的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。
 
 content_type: concept
 weight: 10
@@ -30,9 +30,9 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s
 Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods,
 and can load-balance across them.
 -->
-使用 Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。
+使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。
 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，
-并且可以在它们之间进行负载平衡。
+并且可以在它们之间进行负载均衡。
 
 <!-- body -->
 
@@ -60,12 +60,12 @@ Enter _Services_.
 
 Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期的。
 它们可以被创建，而且销毁之后不会再启动。
-如果您使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}}
-来运行您的应用程序，则它可以动态创建和销毁 Pod。
+如果你使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}}
+来运行你的应用程序，则它可以动态创建和销毁 Pod。
 
 每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。
 
-这导致了一个问题： 如果一组 Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能，
+这导致了一个问题： 如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能，
 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？
 
 进入 _Services_。
@@ -79,13 +79,13 @@ Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期
 In Kubernetes, a Service is an abstraction which defines a logical set of Pods
 and a policy by which to access them (sometimes this pattern is called
 a micro-service). The set of Pods targeted by a Service is usually determined
-by a {{< glossary_tooltip text="selector" term_id="selector" >}}
-(see [below](#services-without-selectors) for why you might want a Service
-_without_ a selector).
+by a {{< glossary_tooltip text="selector" term_id="selector" >}}.
+To learn about other ways to define Service endpoints,
+see [Services _without_ selectors](#services-without-selectors).
 -->
 Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。
 这一组 Pod 能够被 Service 访问到，通常是通过 {{< glossary_tooltip text="选择算符" term_id="selector" >}}
-（查看[下面](#services-without-selectors)了解，为什么你可能需要没有 selector 的 Service）实现的。
+要了解如何定义服务端点，请参阅[不带选择算符的服务](#services-without-selectors)。
 
 <!--
 For example, consider a stateless image-processing backend which is running with
@@ -114,7 +114,7 @@ balancer in between your application and the backend Pods.
 -->
 ### 云原生服务发现
 
-如果您想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询
+如果你想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询
 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
 的 Endpoints 资源，只要服务中的 Pod 集合发生更改，Endpoints 就会被更新。
 
@@ -126,6 +126,8 @@ balancer in between your application and the backend Pods.
 A Service in Kubernetes is a REST object, similar to a Pod.  Like all of the
 REST objects, you can `POST` a Service definition to the API server to create
 a new instance.
+The name of a Service object must be a valid
+[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).
 
 For example, suppose you have a set of Pods that each listen on TCP port 9376
 and carry a label `app=MyApp`:
@@ -135,6 +137,8 @@ and carry a label `app=MyApp`:
 
 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。
 像所有的 REST 对象一样，Service 定义可以基于 `POST` 方式，请求 API server 创建新的实例。
+Service 对象的名称必须是合法的
+[DNS 标签名称](/zh/docs/concepts/overview/working-with-objects/names#dns-label-names)。
 
 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 `app=MyApp` 标签。
 
@@ -197,12 +201,12 @@ As many Services need to expose more than one port, Kubernetes supports multiple
 port definitions on a Service object.
 Each port definition can have the same `protocol`, or a different one.
 -->
-Pod 中的端口定义是有名字的，你可以在服务的 `targetTarget` 属性中引用这些名称。
+Pod 中的端口定义是有名字的，你可以在服务的 `targetPort` 属性中引用这些名称。
 即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。
 这为部署和发展服务提供了很大的灵活性。
-例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。
+例如，你可以更改 Pods 在新版本的后端软件中公开的端口号，而不会破坏客户端。
 
-服务的默认协议是TCP。 您还可以使用任何其他[受支持的协议](#protocol-support)。
+服务的默认协议是TCP。 你还可以使用任何其他[受支持的协议](#protocol-support)。
 
 由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。
 每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。
@@ -231,7 +235,7 @@ For example:
 
   * 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
   * 希望服务指向另一个 {{< glossary_tooltip term_id="namespace" >}} 中或其它集群中的服务。
-  * 您正在将工作负载迁移到 Kubernetes。 在评估该方法时，您仅在 Kubernetes 中运行一部分后端。
+  * 你正在将工作负载迁移到 Kubernetes。 在评估该方法时，你仅在 Kubernetes 中运行一部分后端。
 
 在任何这些场景中，都能够定义没有选择算符的 Service。
 实例:
@@ -254,7 +258,7 @@ created automatically. You can manually map the Service to the network address a
 where it's running, by adding an Endpoint object manually:
 -->
 由于此服务没有选择算符，因此 *不会* 自动创建相应的 Endpoint 对象。
-您可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口：
+你可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口：
 
 ```yaml
 apiVersion: v1
@@ -267,6 +271,12 @@ subsets:
     ports:
       - port: 9376
 ```
+<!--
+The name of the Endpoints object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+Endpoints 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
 <!--
 The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or
@@ -300,11 +310,11 @@ ExternalName Service 是 Service 的特例，它没有选择算符，但是使
 有关更多信息，请参阅本文档后面的[`ExternalName`](#externalname)。
 
 <!--
-### Endpoint Slices
+### EndpointSlices
 -->
-### Endpoint 切片
+### EndpointSlice
 
-{{< 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
@@ -315,7 +325,7 @@ point additional Endpoint Slices will be created to store any additional
 endpoints.
 
 Endpoint Slices provide additional attributes and functionality which is
-described in detail in [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/).
+described in detail in [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/).
 -->
 Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
 尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。
@@ -323,26 +333,21 @@ Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的
 届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。
 
 Endpoint 切片提供了附加的属性和功能，这些属性和功能在
-[Endpoint 切片](/zh/docs/concepts/services-networking/endpoint-slices/)中有详细描述。
+[EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/)
+中有详细描述。
 
 <!-- 
 ### Application protocol
 
-The AppProtocol field provides a way to specify an application protocol to be
-used for each Service port.
-
-As an alpha feature, this field is not enabled by default. To use this field,
-enable the `ServiceAppProtocol` [feature
-gate](/docs/reference/command-line-tools-reference/feature-gates/).
+The `AppProtocol` field provides a way to specify an application protocol for each Service port.
+The value of this field is mirrored by corresponding Endpoints and EndpointSlice resources.
 -->
-### 应用程序协议
+### 应用程序协议   {#application-protocol}
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-`appProtocol` 字段提供了一种为每个 Service 端口指定应用程序协议的方式。
-
-作为一个 alpha 特性，该字段默认未启用。要使用该字段，请启用 `ServiceAppProtocol`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+`appProtocol` 字段提供了一种为每个 Service 端口指定应用协议的方式。
+此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 资源。
 
 <!--
 ## Virtual IPs and service proxies
@@ -351,8 +356,7 @@ Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
 responsible for implementing a form of virtual IP for `Services` of type other
 than [`ExternalName`](#externalname).
 -->
-
-## VIP 和 Service 代理 {#virtual-ips-and-service-proxies}
+## 虚拟 IP 和 Service 代理 {#virtual-ips-and-service-proxies}
 
 在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。
 `kube-proxy` 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是
@@ -376,33 +380,17 @@ There are a few reasons for using proxying for Services:
    on the DNS records could impose a high load on DNS that then becomes
    difficult to manage.
 -->
-
 ### 为什么不使用 DNS 轮询？
 
-时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？
-例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？
+时不时会有人问到为什么 Kubernetes 依赖代理将入站流量转发到后端。那其他方法呢？
+例如，是否可以配置具有多个 A 值（或 IPv6 为 AAAA）的 DNS 记录，并依靠轮询名称解析？
 
 使用服务代理有以下几个原因：
 
-  * DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。
-  * 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。
-  * 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给 DNS 带来高负载，从而使管理变得困难。
-
-<!--
-### Version compatibility
-
-Since Kubernetes v1.0 you have been able to use the
-[userspace proxy mode](#proxy-mode-userspace).
-Kubernetes v1.1 added iptables mode proxying, and in Kubernetes v1.2 the
-iptables mode for kube-proxy became the default.
-Kubernetes v1.8 added ipvs proxy mode.
--->
-
-### 版本兼容性
-
-从 Kubernetes v1.0 开始，您已经可以使用 [用户空间代理模式](#proxy-mode-userspace)。
-Kubernetes v1.1 添加了 iptables 模式代理，在 Kubernetes v1.2 中，kube-proxy 的 iptables 模式成为默认设置。
-Kubernetes v1.8 添加了 ipvs 代理模式。
+* DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。
+* 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。
+* 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给
+  DNS 带来高负载，从而使管理变得困难。
 
 <!--
 ### User space proxy mode {#proxy-mode-userspace}
@@ -434,7 +422,7 @@ By default, kube-proxy in userspace mode chooses a backend via a round-robin alg
 
 默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。
 
-![userspace代理模式下Service概览图](/images/docs/services-userspace-overview.svg)
+![userspace 代理模式下 Service 概览图](/images/docs/services-userspace-overview.svg)
 
 <!--
 ### `iptables` proxy mode {#proxy-mode-iptables}
@@ -481,9 +469,9 @@ having traffic sent via kube-proxy to a Pod that's known to have failed.
 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，
 并会自动使用其他后端 Pod 重试。
 
-您可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
+你可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。
-这样做意味着您避免将流量通过 kube-proxy 发送到已知已失败的Pod。
+这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。
 
 ![iptables代理模式下Service概览图](/images/docs/services-iptables-overview.svg)
 
@@ -513,7 +501,6 @@ higher throughput of network traffic.
 IPVS provides more options for balancing traffic to backend Pods;
 these are:
 -->
-
 在 `ipvs` 模式下，kube-proxy监视Kubernetes服务和端点，调用 `netlink` 接口相应地创建 IPVS 规则，
 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。 该控制循环可确保IPVS 
 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端Pod之一。
@@ -572,7 +559,7 @@ You can also set the maximum session sticky time by setting
 则可以通过将 `service.spec.sessionAffinity` 设置为 "ClientIP" 
 （默认值是 "None"），来基于客户端的 IP 地址选择会话关联。
 
-您还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 
+你还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 
 来设置最大会话停留时间。
 （默认值为 10800 秒，即 3 小时）。
 
@@ -585,10 +572,10 @@ When using multiple ports for a Service, you must give all of your ports names
 so that these are unambiguous.
 For example:
 -->
-## 多端口 Service
+## 多端口 Service   {#multi-port-services}
 
-对于某些服务，您需要公开多个端口。
-Kubernetes 允许您在 Service 对象上配置多个端口定义。
+对于某些服务，你需要公开多个端口。
+Kubernetes 允许你在 Service 对象上配置多个端口定义。
 为服务使用多个端口时，必须提供所有端口名称，以使它们无歧义。
 
 例如：
@@ -639,7 +626,6 @@ The IP address that you choose must be a valid IPv4 or IPv6 address from within
 If you try to create a Service with an invalid clusterIP address value, the API
 server will return a 422 HTTP status code to indicate that there's a problem.
 -->
-
 ## 选择自己的 IP 地址
 
 在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。
@@ -673,7 +659,7 @@ For example, the Service `"redis-master"` which exposes TCP port 6379 and has be
 allocated cluster IP address 10.0.0.11, produces the following environment
 variables:
 -->
-### 环境变量
+### 环境变量   {#environment-variables}
 
 当 Pod 运行在 `Node` 上，kubelet 会为每个活跃的 Service 添加一组环境变量。
 它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量
@@ -704,11 +690,11 @@ If you only use DNS to discover the cluster IP for a Service, you don't need to
 worry about this ordering issue.
 -->
 {{< note >}}
-当您具有需要访问服务的Pod时，并且您正在使用环境变量方法将端口和群集 IP 发布到客户端
+当你具有需要访问服务的 Pod 时，并且你正在使用环境变量方法将端口和集群 IP 发布到客户端
 Pod 时，必须在客户端 Pod 出现 *之前* 创建服务。
 否则，这些客户端 Pod 将不会设定其环境变量。
 
-如果仅使用 DNS 查找服务的群集 IP，则无需担心此设定问题。
+如果仅使用 DNS 查找服务的集群 IP，则无需担心此设定问题。
 {{< /note >}}
 
 ### DNS
@@ -721,7 +707,14 @@ A cluster-aware DNS server, such as CoreDNS, watches the Kubernetes API for new
 Services and creates a set of DNS records for each one.  If DNS has been enabled
 throughout your cluster then all Pods should automatically be able to resolve
 Services by their DNS name.
+-->
+你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/)
+为 Kubernetes 集群设置 DNS 服务。
 
+支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
+如果在整个集群中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。
+
+<!--
 For example, if you have a Service called `"my-service"` in a Kubernetes
 Namespace `"my-ns"`, the control plane and the DNS Service acting together
 create a DNS record for `"my-service.my-ns"`. Pods in the `"my-ns"` Namespace
@@ -730,7 +723,16 @@ should be able to find it by simply doing a name lookup for `my-service`
 
 Pods in other Namespaces must qualify the name as `my-service.my-ns`. These names
 will resolve to the cluster IP assigned for the Service.
+-->
+例如，如果你在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务，
+则控制平面和 DNS 服务共同为 `"my-service.my-ns"` 创建 DNS 记录。
+`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它
+（`"my-service.my-ns"` 也可以工作）。
 
+其他命名空间中的 Pod 必须将名称限定为 `my-service.my-ns`。
+这些名称将解析为为服务分配的集群 IP。
+
+<!--
 Kubernetes also supports DNS SRV (Service) records for named ports.  If the
 `"my-service.my-ns"` Service has a port named `"http"` with protocol set to
 `TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover
@@ -740,19 +742,6 @@ The Kubernetes DNS server is the only way to access `ExternalName` Services.
 You can find more information about `ExternalName` resolution in
 [DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/).
 -->
-您可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/)
-为 Kubernetes 集群设置 DNS 服务。
-
-支持群集的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
-如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。
-
-例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务，
-则控制平面和DNS服务共同为 `"my-service.my-ns"` 创建 DNS 记录。
-`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它
-（`"my-service.my-ns"` 也可以工作）。
-
-其他命名空间中的Pod必须将名称限定为 `my-service.my-ns`。这些名称将解析为为服务分配的群集 IP。
-
 Kubernetes 还支持命名端口的 DNS SRV（服务）记录。
 如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为 TCP，
 则可以对 `_http._tcp.my-service.my-ns` 执行 DNS SRV 查询查询以发现该端口号, 
@@ -762,9 +751,9 @@ Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的
 更多关于 `ExternalName` 信息可以查看
 [DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。
 
+<!--
 ## Headless Services  {#headless-services}
 
-<!--
 Sometimes you don't need load-balancing and a single Service IP.  In
 this case, you can create what are termed “headless” Services, by explicitly
 specifying `"None"` for the cluster IP (`.spec.clusterIP`).
@@ -777,11 +766,14 @@ these Services, and there is no load balancing or proxying done by the platform
 for them. How DNS is automatically configured depends on whether the Service has
 selectors defined:
 -->
+## 无头服务（Headless Services）  {#headless-services}
+
 有时不需要或不想要负载均衡，以及单独的 Service IP。
 遇到这种情况，可以通过指定 Cluster IP（`spec.clusterIP`）的值为 `"None"`
 来创建 `Headless` Service。
 
-您可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。
+你可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes
+的实现捆绑在一起。
 
 对这无头 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们，
 而且平台也不会为它们进行负载均衡和路由。
@@ -794,8 +786,7 @@ For headless Services that define selectors, the endpoints controller creates
 `Endpoints` records in the API, and modifies the DNS configuration to return
 records (addresses) that point directly to the `Pods` backing the Service.
 -->
-
-### 带选择算符的服务
+### 带选择算符的服务   {#with-selectors}
 
 对定义了选择算符的无头服务，Endpoint 控制器在 API 中创建了 Endpoints 记录，
 并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 Service 的后端 Pod 上。
@@ -807,18 +798,17 @@ For headless Services that do not define selectors, the endpoints controller doe
 not create `Endpoints` records. However, the DNS system looks for and configures
 either:
 
-  * CNAME records for [`ExternalName`](#externalname)-type Services.
-  * A records for any `Endpoints` that share a name with the Service, for all
-    other types.
+* CNAME records for [`ExternalName`](#externalname)-type Services.
+* A records for any `Endpoints` that share a name with the Service, for all
+  other types.
 -->
-
-### 无选择算符的服务
+### 无选择算符的服务  {#without-selectors}
 
 对没有定义选择算符的无头服务，Endpoint 控制器不会创建 `Endpoints` 记录。
 然而 DNS 系统会查找和配置，无论是：
 
-  * `ExternalName` 类型 Service 的 CNAME 记录
-  * 记录：与 Service 共享一个名称的任何 `Endpoints`，以及所有其它类型
+* 对于 [`ExternalName`](#external-name) 类型的服务，查找其 CNAME 记录
+* 对所有其他类型的服务，查找与 Service 名称相同的任何 `Endpoints` 的记录
 
 <!--
 ## Publishing Services (ServiceTypes) {#publishing-services-service-types}
@@ -830,52 +820,55 @@ Kubernetes `ServiceTypes` allow you to specify what kind of Service you want.
 The default is `ClusterIP`.
 
 `Type` values and their behaviors are:
-
-   * `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
-     makes the Service only reachable from within the cluster. This is the
-     default `ServiceType`.
-   * [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
-     (the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
-     routes, is automatically created.  You'll be able to contact the `NodePort` Service,
-     from outside the cluster,
-     by requesting `<NodeIP>:<NodePort>`.
-   * [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
-     provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
-     load balancer routes, are automatically created.
-   * [`ExternalName`](#externalname): Maps the Service to the contents of the
-     `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
-
-     with its value. No proxying of any kind is set up.
-     {{< note >}}
-     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.
 -->
-## 发布服务 —— 服务类型 {#publishing-services-service-types}
+## 发布服务（服务类型)      {#publishing-services-service-types}
 
-对一些应用（如前端）的某些部分，可能希望通过外部 Kubernetes 集群外部 IP 地址暴露 Service。
+对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部
+的 IP 地址。
 
-Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。
+Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型，默认是 `ClusterIP`。
 
 `Type` 的取值以及行为如下：
 
-  * `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。
-  * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。
-    `NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。
-    通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。
-  * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。
-    外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。
-  * [`ExternalName`](#externalname)：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName`
-    字段的内容（例如， `foo.bar.example.com`）。
-    没有任何类型代理被创建。
+<!--
+* `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
+  makes the Service only reachable from within the cluster. This is the
+  default `ServiceType`.
+* [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
+  (the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
+  routes, is automatically created.  You'll be able to contact the `NodePort` Service,
+  from outside the cluster,
+  by requesting `<NodeIP>:<NodePort>`.
+* [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
+  provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
+  load balancer routes, are automatically created.
+* [`ExternalName`](#externalname): Maps the Service to the contents of the
+  `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
+  with its value. No proxying of any kind is set up.
+  {{< note >}}
+  You need either kube-dns version 1.7 or CoreDNS version 0.0.8 or higher to use the `ExternalName` type.
+  {{< /note >}}
+-->
+* `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。
+  这也是默认的 `ServiceType`。
+* [`NodePort`](#nodeport)：通过每个节点上的 IP 和静态端口（`NodePort`）暴露服务。
+  `NodePort` 服务会路由到自动创建的 `ClusterIP` 服务。
+  通过请求 `<节点 IP>:<节点端口>`，你可以从集群的外部访问一个 `NodePort` 服务。
+* [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器向外部暴露服务。
+  外部负载均衡器可以将流量路由到自动创建的 `NodePort` 服务和 `ClusterIP` 服务上。
+* [`ExternalName`](#externalname)：通过返回 `CNAME` 和对应值，可以将服务映射到
+  `externalName` 字段的内容（例如，`foo.bar.example.com`）。
+  无需创建任何类型代理。
 
-    {{< note >}}
-    您需要 CoreDNS 1.7 或更高版本才能使用 `ExternalName` 类型。
-    {{< /note >}}
+  {{< note >}}
+  你需要 CoreDNS 1.7 或更高版本才能使用 `ExternalName` 类型。
+  {{< /note >}}
 
-您也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
-Ingress 不是服务类型，但它充当集群的入口点。
+<!--
+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.
+-->
+你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
+Ingress 不是一种服务类型，但它充当集群的入口点。
 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。
 
 <!--
@@ -888,15 +881,15 @@ Your Service reports the allocated port in its `.spec.ports[*].nodePort` field.
 
 If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s); this is supported since Kubernetes v1.10.
 This flag takes a comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 192.0.2.0/25) to specify IP address ranges that kube-proxy should consider as local to this node.
-
 -->
 ### NodePort 类型  {#nodeport}
 
-如果将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 `--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。
-每个节点将那个端口（每个节点上的相同端口号）代理到您的服务中。
-您的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。
+如果你将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在
+`--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。
+每个节点将那个端口（每个节点上的相同端口号）代理到你的服务中。
+你的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。
 
-如果您想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` 
+如果你想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` 
 标志设置为特定的 IP 块。从 Kubernetes v1.10 开始支持此功能。
 
 该标志采用逗号分隔的 IP 块列表（例如，`10.0.0.0/8`、`192.0.2.0/25`）来指定
@@ -912,13 +905,16 @@ This means that you need to take care about possible port collisions yourself.
 You also have to use a valid port number, one that's inside the range configured
 for NodePort use.
 -->
-例如，如果您使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，则 kube-proxy 仅选择 NodePort Services 的环回接口。
+例如，如果你使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，
+则 kube-proxy 仅选择 NodePort Services 的本地回路接口。
 `--nodeport-addresses` 的默认值是一个空列表。
 这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。
 （这也与早期的 Kubernetes 版本兼容）。
 
-如果需要特定的端口号，则可以在 `nodePort` 字段中指定一个值。控制平面将为您分配该端口或向API报告事务失败。
-这意味着您需要自己注意可能发生的端口冲突。您还必须使用有效的端口号，该端口号在配置用于NodePort的范围内。
+如果需要特定的端口号，你可以在 `nodePort` 字段中指定一个值。
+控制平面将为你分配该端口或报告 API 事务失败。
+这意味着你需要自己注意可能发生的端口冲突。
+你还必须使用有效的端口号，该端口号在配置用于 NodePort 的范围内。
 
 <!--
 Using a NodePort gives you the freedom to set up your own load balancing solution,
@@ -930,10 +926,11 @@ and `.spec.clusterIP:spec.ports[*].port`. (If the `-nodeport-addresses` flag in
 
 For example:
 -->
-使用 NodePort 可以让您自由设置自己的负载平衡解决方案，配置 Kubernetes 不完全支持的环境，
+使用 NodePort 可以让你自由设置自己的负载均衡解决方案，配置 Kubernetes 不完全支持的环境，
 甚至直接暴露一个或多个节点的 IP。
 
-需要注意的是，Service 能够通过 `<NodeIP>:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。
+需要注意的是，Service 能够通过 `<NodeIP>:spec.ports[*].nodePort` 和
+`spec.clusterIp:spec.ports[*].port` 而对外可见。
 
 例如：
 
@@ -998,24 +995,34 @@ status:
 <!--
 Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.
 
+For LoadBalancer type of Services, when there is more than one port defined, all
+ports must have the same protocol and the protocol must be one of `TCP`, `UDP`,
+and `SCTP`.
+-->
+来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。
+
+对于 LoadBalancer 类型的服务，当所定义的端口不止一个时，所有端口都必须
+使用相同的协议，并且其协议必须是 `TCP`、`UDP` 和 `SCTP` 之一。
+
+<!--
 Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created
 with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified,
 the loadBalancer is set up with an ephemeral IP address. If you specify a `loadBalancerIP`
 but your cloud provider does not support the feature, the `loadbalancerIP` field that you
 set is ignored.
 -->
-来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。
-
+某些云提供商允许设置 `loadBalancerIP`。
 在这些情况下，将根据用户设置的 `loadBalancerIP` 来创建负载均衡器。
-某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`，将会给负载均衡器指派一个临时 IP。
-如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 `loadBalancerIP` 值将会被忽略掉。
+如果没有设置 `loadBalancerIP` 字段，将会给负载均衡器指派一个临时 IP。
+如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的
+`loadBalancerIP` 值将会被忽略掉。
 
 <!--
 If you're using SCTP, see the [caveat](#caveat-sctp-loadbalancer-service-type) below about the
 `LoadBalancer` Service type.
 -->
 {{< note >}}
-如果您使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的
+如果你使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的
 [注意事项](#caveat-sctp-loadbalancer-service-type)。
 {{< /note >}}
 
@@ -1028,13 +1035,16 @@ For example, `MC_myResourceGroup_myAKSCluster_eastus`.
 Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
 -->
 {{< note >}}
-在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。
-此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。
+在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP`，则
+首先需要创建静态类型的公共 IP 地址资源。
+此公共 IP 地址资源应与集群中其他自动创建的资源位于同一资源组中。
+例如，`MC_myResourceGroup_myAKSCluster_eastus`。
 
-将分配的IP地址指定为 loadBalancerIP。 确保您已更新云提供程序配置文件中的 securityGroupName。
+将分配的 IP 地址设置为 loadBalancerIP。确保你已更新云提供程序配置文件中的
+securityGroupName。
 有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息，
-请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)
-或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。
+请参阅 [与 Azure Kubernetes服务（AKS）负载平衡器一起使用静态 IP 地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)
+或[在 AKS 集群上使用高级联网时出现 CreatingLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。
 {{< /note >}}
 
 <!--
@@ -1048,13 +1058,13 @@ In a split-horizon DNS environment you would need two Services to be able to rou
 You can achieve this by adding one the following annotations to a Service.
 The annotation to add depends on the cloud Service provider you're using.
 -->
-#### 内部负载均衡器
+#### 内部负载均衡器   {#internal-load-balancer}
 
 在混合环境中，有时有必要在同一(虚拟)网络地址块内路由来自服务的流量。
 
-在水平分割 DNS 环境中，您需要两个服务才能将内部和外部流量都路由到您的端点（Endpoints）。
-您可以通过向服务添加以下注释之一来实现此目的。
-要添加的注释取决于您使用的云服务提供商。
+在水平分割 DNS 环境中，你需要两个服务才能将内部和外部流量都路由到你的端点（Endpoints）。
+你可以通过向服务添加以下注解之一来实现此目的。
+要添加的注解取决于你使用的云服务提供商。
 
 {{< tabs name="service_tabs" >}}
 {{% tab name="Default" %}}
@@ -1072,14 +1082,10 @@ metadata:
         cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
-<!--
-Use `cloud.google.com/load-balancer-type: "internal"` for masters with version 1.7.0 to 1.7.3.
-For more information, see the [docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing).
--->
-将 `cloud.google.com/load-balancer-type: "internal"` 节点用于版本1.7.0至1.7.3的主服务器。
-有关更多信息，请参见[文档](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)。
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1088,8 +1094,10 @@ metadata:
         service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1098,8 +1106,10 @@ metadata:
         service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1108,8 +1118,10 @@ metadata:
         service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1118,8 +1130,10 @@ metadata:
         service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -1128,6 +1142,29 @@ metadata:
         service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
+{{% /tab %}}
+{{% tab name="Tencent Cloud" %}}
+
+```yaml
+[...]
+metadata:
+  annotations:
+    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
+[...]
+```
+
+{{% /tab %}}
+{{% tab name="Alibaba Cloud" %}}
+
+```yaml
+[...]
+metadata:
+  annotations:
+    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
+[...]
+```
+
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -1139,7 +1176,8 @@ annotations to a `LoadBalancer` service:
 -->
 ### AWS TLS 支持 {#ssl-support-on-aws}
 
-为了对在AWS上运行的集群提供部分TLS / SSL支持，您可以向 `LoadBalancer` 服务添加三个注释：
+为了对在 AWS 上运行的集群提供 TLS/SSL 部分支持，你可以向 `LoadBalancer`
+服务添加三个注解：
 
 ```yaml
 metadata:
@@ -1153,8 +1191,8 @@ The first specifies the ARN of the certificate to use. It can be either a
 certificate from a third party issuer that was uploaded to IAM or one created
 within AWS Certificate Manager.
 -->
-
-第一个指定要使用的证书的ARN。 它可以是已上载到 IAM 的第三方颁发者的证书，也可以是在 AWS Certificate Manager 中创建的证书。
+第一个指定要使用的证书的 ARN。 它可以是已上载到 IAM 的第三方颁发者的证书，
+也可以是在 AWS Certificate Manager 中创建的证书。
 
 ```yaml
 metadata:
@@ -1179,14 +1217,15 @@ modifying the headers.
 In a mixed-use environment where some ports are secured and others are left unencrypted,
 you can use the following annotations:
 -->
-第二个注释指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书通过加密连接对自己进行身份验证。
+第二个注解指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书
+通过加密连接对自己进行身份验证。
 
 HTTP 和 HTTPS 选择第7层代理：ELB 终止与用户的连接，解析标头，并在转发请求时向
 `X-Forwarded-For` 标头注入用户的 IP 地址（Pod 仅在连接的另一端看到 ELB 的 IP 地址）。
 
 TCP 和 SSL 选择第4层代理：ELB 转发流量而不修改报头。
 
-在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注释：
+在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注解：
 
 ```yaml
     metadata:
@@ -1204,10 +1243,9 @@ be proxied HTTP.
 From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
 To see which policies are available for use, you can use the `aws` command line tool:
 -->
-
 从 Kubernetes v1.9 起可以使用
 [预定义的 AWS SSL 策略](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)
-为您的服务使用 HTTPS 或 SSL 侦听器。
+为你的服务使用 HTTPS 或 SSL 侦听器。
 要查看可以使用哪些策略，可以使用 `aws` 命令行工具：
 
 ```bash
@@ -1219,8 +1257,8 @@ You can then specify any one of those policies using the
 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"
 annotation; for example:
 -->
-然后，您可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" 注解; 
-例如：
+然后，你可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"
+注解; 例如：
 
 ```yaml
     metadata:
@@ -1238,8 +1276,9 @@ annotation:
 -->
 #### AWS 上的 PROXY 协议支持
 
-为了支持在 AWS 上运行的集群，启用 [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。
-您可以使用以下服务注释：
+为了支持在 AWS 上运行的集群，启用
+[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。
+你可以使用以下服务注解：
 
 ```yaml
     metadata:
@@ -1252,7 +1291,7 @@ annotation:
 Since version 1.3.0, the use of this annotation applies to all ports proxied by the ELB
 and cannot be configured otherwise.
 -->
-从 1.3.0 版开始，此注释的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。
+从 1.3.0 版开始，此注解的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。
 
 <!--
 ### External IPs
@@ -1312,17 +1351,17 @@ specifies the logical hierarchy you created for your Amazon S3 bucket.
 -->
 #### AWS 上的 ELB 访问日志
 
-有几个注释可用于管理 AWS 上 ELB 服务的访问日志。
+有几个注解可用于管理 AWS 上 ELB 服务的访问日志。
 
-注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。
+注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。
 
 注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` 
-控制发布访问日志的时间间隔（以分钟为单位）。您可以指定 5 分钟或 60 分钟的间隔。
+控制发布访问日志的时间间隔（以分钟为单位）。你可以指定 5 分钟或 60 分钟的间隔。
 
-注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` 
+注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` 
 控制存储负载均衡器访问日志的 Amazon S3 存储桶的名称。
 
-注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`
+注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`
 指定为 Amazon S3 存储桶创建的逻辑层次结构。
 
 ```yaml
@@ -1330,13 +1369,13 @@ specifies the logical hierarchy you created for your Amazon S3 bucket.
       name: my-service
       annotations:
         service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
-        # Specifies whether access logs are enabled for the load balancer
+        # 指定是否为负载均衡器启用访问日志
         service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
-        # The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes).
+        # 发布访问日志的时间间隔。你可以将其设置为 5 分钟或 60 分钟。
         service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
-        # The name of the Amazon S3 bucket where the access logs are stored
+        # 用来存放访问日志的 Amazon S3 Bucket 名称
         service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
-        # The logical hierarchy you created for your Amazon S3 bucket, for example `my-bucket-prefix/prod`
+        # 你为 Amazon S3 Bucket 所创建的逻辑层次结构，例如 `my-bucket-prefix/prod`
 ```
 
 <!--
@@ -1352,7 +1391,7 @@ also be used to set maximum time, in seconds, to keep the existing connections o
 
 可以将注解 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`
 设置为 `"true"` 来管理 ELB 的连接排空。
-注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`
+注解 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`
 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。
 
 ```yaml
@@ -1370,7 +1409,7 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
 -->
 #### 其他 ELB 注解
 
-还有其他一些注释，用于管理经典弹性负载均衡器，如下所述。
+还有其他一些注解，用于管理经典弹性负载均衡器，如下所述。
 
 ```yaml
     metadata:
@@ -1403,8 +1442,16 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
         # 此值必须小于 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
         # 默认值为 5，必须介于 2 和 60 之间
 
+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
+        # 要添加到所创建的 ELB 之上的已有安全组列表。与注解
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 不同，此
+        # 注解会替换掉之前指派给 ELB 的所有其他安全组
+
         service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
         # 要添加到 ELB 上的额外安全组列表
+
+        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
+        # 用逗号分隔的一个键-值偶对列表，用来为负载均衡器选择目标节点
 ```
 
 <!--
@@ -1431,7 +1478,6 @@ To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernet
 NLB only works with certain instance classes; see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
 on Elastic Load Balancing for a list of supported instance types.
 -->
-
 {{< note >}}
 NLB 仅适用于某些实例类。有关受支持的实例类型的列表，
 请参见
@@ -1522,7 +1568,7 @@ the `my-service` Service in the `prod` namespace to `my.database.example.com`:
 ### ExternalName 类型         {#externalname}
 
 类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。
-您可以使用 `spec.externalName` 参数指定这些服务。
+你可以使用 `spec.externalName` 参数指定这些服务。
 
 例如，以下 Service 定义将 `prod` 名称空间中的 `my-service` 服务映射到 `my.database.example.com`：
 
@@ -1560,7 +1606,7 @@ Service's `type`.
 当查找主机 `my-service.prod.svc.cluster.local` 时，集群 DNS 服务返回 `CNAME` 记录，
 其值为 `my.database.example.com`。
 访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。
-如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。
+如果以后你决定将数据库移到集群中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。
 
 <!--
 This section is indebted to the [Kubernetes Tips - Part
@@ -1585,7 +1631,8 @@ In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10
 ### 外部 IP  {#external-ips}
 
 如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes Service 会被暴露给这些 externalIPs。
-通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量，将会被路由到 Service 的 Endpoint 上。
+通过外部 IP（作为目的 IP 地址）进入到集群，打到 Service 的端口上的流量，
+将会被路由到 Service 的 Endpoint 上。
 `externalIPs` 不会被 Kubernetes 管理，它属于集群管理员的职责范畴。
 
 根据 Service 的规定，`externalIPs` 可以同任意的 `ServiceType` 来一起指定。
@@ -1635,7 +1682,8 @@ but the current API requires it.
 
 使用用户空间代理，隐藏了访问 Service 的数据包的源 IP 地址。
 这使得一些类型的防火墙无法起作用。
-iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求客户端请求必须通过一个负载均衡器或 Node 端口。
+iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求客户端请求
+必须通过一个负载均衡器或 Node 端口。
 
 `Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。
 不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer`
@@ -1714,8 +1762,10 @@ each operate slightly differently.
 -->
 ### Service IP 地址 {#ips-and-vips}
 
-不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。
-相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。
+不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上
+不能通过单个主机来进行应答。
+相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个
+虚拟 IP 地址（VIP），它可以根据需要透明地进行重定向。
 当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。
 环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。
 
@@ -1744,9 +1794,11 @@ of which Pods they are actually accessing.
 作为一个例子，考虑前面提到的图片处理应用程序。
 当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
 假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。
-当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。
+当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到
+新端口的 iptables，并开始接收请求连接。
 
-当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 "服务代理" 的端口。
+当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到
+"服务代理" 的端口。
 "服务代理" 选择一个后端，并将客户端的流量代理到后端上。
 
 这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。
@@ -1793,9 +1845,11 @@ through a load-balancer, though in those cases the client IP does get altered.
 iptables operations slow down dramatically in large scale cluster e.g 10,000 Services.
 IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
 -->
-在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载平衡而设计，并基于内核内哈希表。
-因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。
-同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。
+在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS
+专为负载平衡而设计，并基于内核内哈希表。
+因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。
+同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、
+加权、持久性）。
 
 ## API 对象
 
@@ -1803,58 +1857,49 @@ IPVS is designed for load balancing and based on in-kernel hash tables. So you c
 Service is a top-level resource in the Kubernetes REST API. You can find more details
 about the API object at: [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
 -->
-Service 是 Kubernetes REST API 中的顶级资源。您可以在以下位置找到有关A PI 对象的更多详细信息：
+Service 是 Kubernetes REST API 中的顶级资源。你可以在以下位置找到有关 API 对象的更多详细信息：
 [Service 对象 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
 
 ## 受支持的协议 {#protocol-support}
 
 ### TCP
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 <!--
 You can use TCP for any kind of Service, and it's the default network protocol.
 -->
-您可以将 TCP 用于任何类型的服务，这是默认的网络协议。
+你可以将 TCP 用于任何类型的服务，这是默认的网络协议。
 
 ### UDP
 
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
 <!--
 You can use UDP for most Services. For type=LoadBalancer Services, UDP support
 depends on the cloud provider offering this facility.
 -->
-您可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。
+你可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。
 
 ### HTTP
 
-{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-
 <!--
 If your cloud provider supports it, you can use a Service in LoadBalancer mode
 to set up external HTTP / HTTPS reverse proxying, forwarded to the Endpoints
 of the Service.
 -->
-如果您的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。
+如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部
+HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。
 
 <!--
 You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service
 to expose HTTP / HTTPS Services.
 -->
 {{< note >}}
-您还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替 Service 来公开 HTTP/HTTPS 服务。
+你还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替
+Service 来公开 HTTP/HTTPS 服务。
 {{< /note >}}
 
 <!--
 ### PROXY protocol
--->
-### PROXY 协议
 
-{{< feature-state for_k8s_version="v1.1" state="stable" >}}
-
-<!--
-If your cloud provider supports it (eg, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)),
+If your cloud provider supports it,
 you can use a Service in LoadBalancer mode to configure a load balancer outside
 of Kubernetes itself, that will forward connections prefixed with
 [PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
@@ -1862,10 +1907,12 @@ of Kubernetes itself, that will forward connections prefixed with
 The load balancer will send an initial series of octets describing the
 incoming connection, similar to this example
 -->
+### PROXY 协议
 
-如果您的云提供商支持它（例如, [AWS](/zh/docs/concepts/cluster-administration/cloud-providers/#aws)），
+如果你的云提供商支持它，
 则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器，
-该负载均衡器将转发前缀为 [PROXY协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
+该负载均衡器将转发前缀为
+[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
 的连接。
 
 负载平衡器将发送一系列初始字节，描述传入的连接，类似于此示例
@@ -1881,19 +1928,22 @@ followed by the data from the client.
 
 ### SCTP
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 <!--
-Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPolicy and Pod definitions as an alpha feature. To enable this feature, the cluster administrator needs to enable the `SCTPSupport` feature gate on the apiserver, for example, `-feature-gates=SCTPSupport=true,…`.
+Kubernetes supports SCTP as a `protocol` value in Service, Endpoints, EndpointSlice, NetworkPolicy and Pod definitions. As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`.
 
-When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
+When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoints, EndpointSlice, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
 -->
+Kubernetes 支持 SCTP 作为 Service、Endpoint、EndpointSlice, NetworkPolicy
+和 Pod 定义中的 `protocol` 值。
+作为一种 Beta 特性，此功能默认是启用的。集群管理员需要在 API 服务器上使用
+`--feature-gates=SCTPSupport=false,...` 来关闭
+`SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+来在集群级别禁用 SCTP。
 
-作为一种 alpha 功能，Kubernetes 支持 SCTP 作为 Service、Endpoint、NetworkPolicy 和 Pod 定义中的 `protocol` 值。
-要启用此功能，集群管理员需要在 API 服务器上启用 `SCTPSupport` 特性门控，
-例如 `--feature-gates=SCTPSupport=true,...`。
-
-启用特性门控后，你可以将 Service、Endpoints、NetworkPolicy 或 Pod 的 `protocol` 字段设置为 `SCTP`。
+启用特性门控后，你可以将 Service、Endpoints、EndpointSlice、NetworkPolicy 或
+Pod 的 `protocol` 字段设置为 `SCTP`。
 Kubernetes 相应地为 SCTP 关联设置网络，就像为 TCP 连接所做的一样。
 
 <!--
@@ -1918,13 +1968,10 @@ NAT for multihomed SCTP associations requires special logic in the corresponding
 
 <!--
 ##### Service with type=LoadBalancer {#caveat-sctp-loadbalancer-service-type}
--->
 
-##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type}
-
-<!--
 You can only create a Service with `type` LoadBalancer plus `protocol` SCTP if the cloud provider's load balancer implementation supports SCTP as a protocol. Otherwise, the Service creation request is rejected. The current set of cloud load balancer providers (Azure, AWS, CloudStack, GCE, OpenStack) all lack support for SCTP.
 -->
+##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type}
 
 {{< warning >}}
 如果云提供商的负载平衡器实现支持将 SCTP 作为协议，则只能使用 `type` LoadBalancer 加上
@@ -1941,38 +1988,20 @@ SCTP is not supported on Windows based nodes.
 基于 Windows 的节点不支持 SCTP。
 {{< /warning >}}
 
+<!--
+##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace}
+
+The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
+-->
 ##### 用户空间 kube-proxy {#caveat-sctp-kube-proxy-userspace}
 
+{{< warning >}}
 <!--
 The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
 -->
-{{< warning >}}
 当 kube-proxy 处于用户空间模式时，它不支持 SCTP 关联的管理。
 {{< /warning >}}
 
-<!--
-## Future work
-
-In the future, the proxy policy for Services can become more nuanced than
-simple round-robin balancing, for example master-elected or sharded.  We also
-envision that some Services will have "real" load balancers, in which case the
-virtual IP address will simply transport the packets there.
-
-The Kubernetes project intends to improve support for L7 (HTTP) Services.
-
-The Kubernetes project intends to have more flexible ingress modes for Services
-which encompass the current ClusterIP, NodePort, and LoadBalancer modes and more.
--->
-## 未来工作
-
-未来我们能预见到，代理策略可能会变得比简单的轮转均衡策略有更多细微的差别，比如主控节点选举或分片。
-我们也能想到，某些 Service 将具有 “真正” 的负载均衡器，这种情况下 VIP 将简化数据包的传输。
-
-Kubernetes 项目打算为 L7（HTTP）服务改进支持。
-
-Kubernetes 项目打算为 Service 实现更加灵活的请求进入模式，
-这些模式包含当前的 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。
-
 ## {{% heading "whatsnext" %}}
 
 <!--
@@ -1980,8 +2009,7 @@ Kubernetes 项目打算为 Service 实现更加灵活的请求进入模式，
 * Read about [Ingress](/docs/concepts/services-networking/ingress/)
 * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
 -->
-
 * 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/)
 * 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)
-* 阅读了解 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)
+* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/)
 
diff --git a/content/zh/docs/concepts/storage/_index.md b/content/zh/docs/concepts/storage/_index.md
index c6accc5314..ce60d3a46a 100644
--- a/content/zh/docs/concepts/storage/_index.md
+++ b/content/zh/docs/concepts/storage/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "存储"
 weight: 70
+description: 为集群中的 Pods 提供长期和临时存储的方法。
 ---
diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh/docs/concepts/storage/dynamic-provisioning.md
index a45d65fd65..ae6d82ec4e 100644
--- a/content/zh/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/zh/docs/concepts/storage/dynamic-provisioning.md
@@ -22,7 +22,8 @@ automatically provisions storage when it is requested by users.
 -->
 动态卷供应允许按需创建存储卷。
 如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
-然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。
+然后在 Kubernetes 集群创建
+[`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
 动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
 
 <!-- body -->
@@ -46,7 +47,7 @@ that provisioner when provisioning.
 <!--
 A cluster administrator can define and expose multiple flavors of storage (from
 the same or different storage systems) within a cluster, each with a custom set
-of parameters. This design also ensures that end users don’t have to worry
+of parameters. This design also ensures that end users don't have to worry
 about the complexity and nuances of how storage is provisioned, but still
 have the ability to select from multiple storage options.
 -->
@@ -122,10 +123,10 @@ administrator (see [below](#enabling-dynamic-provisioning)).
 这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称（见[下面](#enabling-dynamic-provisioning)）。
 
 <!--
-To select the “fast” storage class, for example, a user would create the
-following `PersistentVolumeClaim`:
+To select the "fast" storage class, for example, a user would create the
+following PersistentVolumeClaim:
 -->
-例如，要选择 "fast" 存储类，用户将创建如下的 `PersistentVolumeClaim`：
+例如，要选择 “fast” 存储类，用户将创建如下的 PersistentVolumeClaim：
 
 ```yaml
 apiVersion: v1
@@ -151,7 +152,7 @@ provisioned. When the claim is deleted, the volume is destroyed.
 <!--
 ## Defaulting Behavior
 -->
-## 默认行为
+## 设置默认值的行为
 
 <!--
 Dynamic provisioning can be enabled on a cluster such that all claims are
@@ -186,7 +187,8 @@ Note that there can be at most one *default* storage class on a cluster, or
 a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot
 be created.
 -->
-请注意，群集上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定 `storageClassName` 的 `PersistentVolumeClaim`。
+请注意，群集上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定
+`storageClassName` 的 `PersistentVolumeClaim`。
 
 <!--
 ## Topology Awareness
@@ -199,7 +201,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
 Pods are scheduled. This can be accomplished by setting the [Volume Binding
 Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
 -->
-在[多区域](/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
+在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
 单区域存储后端应该被供应到 Pod 被调度到的区域。
 这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
 
diff --git a/content/zh/docs/concepts/storage/ephemeral-volumes.md b/content/zh/docs/concepts/storage/ephemeral-volumes.md
new file mode 100644
index 0000000000..32190eb3e9
--- /dev/null
+++ b/content/zh/docs/concepts/storage/ephemeral-volumes.md
@@ -0,0 +1,467 @@
+---
+title: 临时卷
+content_type: concept
+weight: 50
+---
+<!--
+reviewers:
+- jsafrane
+- saad-ali
+- msau42
+- xing-yang
+- pohly
+title: Ephemeral Volumes
+content_type: concept
+weight: 50
+-->
+
+<!-- overview -->
+
+<!--
+This document describes _ephemeral volumes_ in Kubernetes. Familiarity
+with [volumes](/docs/concepts/storage/volumes/) is suggested, in
+particular PersistentVolumeClaim and PersistentVolume.
+-->
+本文档描述 Kubernetes 中的 _临时卷（Ephemeral Volume）_。
+建议先了解[卷](/zh/docs/concepts/storage/volumes/)，特别是 PersistentVolumeClaim 和 PersistentVolume。
+
+<!-- body -->
+<!--
+Some application need additional storage but don't care whether that
+data is stored persistently across restarts. For example, caching
+services are often limited by memory size and can move infrequently
+used data into storage that is slower than memory with little impact
+on overall performance.
+-->
+有些应用程序需要额外的存储，但并不关心数据在重启后仍然可用，既是否被持久地保存。
+例如，缓存服务经常受限于内存大小，将不常用的数据转移到比内存慢、但对总体性能的影响很小的存储中。
+
+<!--
+Other applications expect some read-only input data to be present in
+files, like configuration data or secret keys.
+-->
+另有些应用程序需要以文件形式注入的只读数据，比如配置数据或密钥。
+
+<!--
+_Ephemeral volumes_ are designed for these use cases. Because volumes
+follow the Pod's lifetime and get created and deleted along with the
+Pod, Pods can be stopped and restarted without being limited to where
+some persistent volume is available.
+-->
+_临时卷_ 就是为此类用例设计的。因为卷会遵从 Pod 的生命周期，与 Pod 一起创建和删除，
+所以停止和重新启动 Pod 时，不会受持久卷在何处可用的限制。
+
+<!--
+Ephemeral volumes are specified _inline_ in the Pod spec, which
+simplifies application deployment and management.
+-->
+临时卷在 Pod 规范中以 _内联_ 方式定义，这简化了应用程序的部署和管理。
+
+<!--
+### Types of ephemeral volumes
+-->
+### 临时卷的类型 {#types-of-ephemeral-volumes}
+
+<!--
+Kubernetes supports several different kinds of ephemeral volumes for
+different purposes:
+- [emptyDir](/docs/concepts/storage/volumes/#emptydir): empty at Pod startup,
+  with storage coming locally from the kubelet base directory (usually
+  the root disk) or RAM
+- [configMap](/docs/concepts/storage/volumes/#configmap),
+  [downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
+  [secret](/docs/concepts/storage/volumes/#secret): inject different
+  kinds of Kubernetes data into a Pod
+- [CSI ephemeral volumes](#csi-ephemeral-volume):
+  similar to the previous volume kinds, but provided by special
+  [CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
+  which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)
+- [generic ephemeral volumes](#generic-ephemeral-volumes), which
+  can be provided by all storage drivers that also support persistent volumes
+-->
+Kubernetes 为了不同的目的，支持几种不同类型的临时卷：
+- [emptyDir](/zh/docs/concepts/storage/volumes/#emptydir)：
+  Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存
+- [configMap](/zh/docs/concepts/storage/volumes/#configmap)、
+  [downwardAPI](/zh/docs/concepts/storage/volumes/#downwardapi)、
+  [secret](/zh/docs/concepts/storage/volumes/#secret)：
+  将不同类型的 Kubernetes 数据注入到 Pod 中
+- [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi-ephemeral-volumes)：
+  类似于前面的卷类型，但由专门[支持此特性](https://kubernetes-csi.github.io/docs/drivers.html)
+  的指定
+  [CSI 驱动程序](https://github.com/container-storage-interface/spec/blob/master/spec.md)提供
+- [通用临时卷](#generic-ephemeral-volumes)：
+  它可以由所有支持持久卷的存储驱动程序提供
+
+<!--
+`emptyDir`, `configMap`, `downwardAPI`, `secret` are provided as
+[local ephemeral
+storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).
+They are managed by kubelet on each node.
+
+CSI ephemeral volumes *must* be provided by third-party CSI storage
+drivers.
+-->
+`emptyDir`、`configMap`、`downwardAPI`、`secret` 是作为
+[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)
+提供的。它们由各个节点上的 kubelet 管理。
+
+CSI 临时卷 *必须* 由第三方 CSI 存储驱动程序提供。
+
+<!--
+Generic ephemeral volumes *can* be provided by third-party CSI storage
+drivers, but also by any other storage driver that supports dynamic
+provisioning. Some CSI drivers are written specifically for CSI
+ephemeral volumes and do not support dynamic provisioning: those then
+cannot be used for generic ephemeral volumes.
+-->
+通用临时卷 *可以* 由第三方 CSI 存储驱动程序提供，也可以由支持动态配置的任何其他存储驱动程序提供。
+一些专门为 CSI 临时卷编写的 CSI 驱动程序，不支持动态供应：因此这些驱动程序不能用于通用临时卷。
+
+<!--
+The advantage of using third-party drivers is that they can offer
+functionality that Kubernetes itself does not support, for example
+storage with different performance characteristics than the disk that
+is managed by kubelet, or injecting different data.
+-->
+使用第三方驱动程序的优势在于，它们可以提供 Kubernetes 本身不支持的功能，
+例如，与 kubelet 管理的磁盘具有不同运行特征的存储，或者用来注入不同的数据
+
+<!--
+### CSI ephemeral volumes
+-->
+### CSI 临时卷 {#csi-ephemeral-volumes}
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+<!--
+This feature requires the `CSIInlineVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It
+is enabled by default starting with Kubernetes 1.16.
+
+CSI ephemeral volumes are only supported by a subset of CSI drivers.
+The Kubernetes CSI [Drivers list](https://kubernetes-csi.github.io/docs/drivers.html)
+shows which drivers support ephemeral volumes.
+-->
+该特性需要启用参数 `CSIInlineVolume` 
+[特性门控（feature gate）](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+该参数从 Kubernetes 1.16 开始默认启用。
+
+{{< note >}}
+只有一部分 CSI 驱动程序支持 CSI 临时卷。Kubernetes CSI 
+[驱动程序列表](https://kubernetes-csi.github.io/docs/drivers.html)
+显示了支持临时卷的驱动程序。
+{{< /note >}}
+
+<!--
+Conceptually, CSI ephemeral volumes are similar to `configMap`,
+`downwardAPI` and `secret` volume types: the storage is managed locally on each
+ node and is created together with other local resources after a Pod has been
+scheduled onto a node. Kubernetes has no concept of rescheduling Pods
+anymore at this stage. Volume creation has to be unlikely to fail,
+otherwise Pod startup gets stuck. In particular, [storage capacity
+aware Pod scheduling](/docs/concepts/storage-capacity/) is *not*
+supported for these volumes. They are currently also not covered by
+the storage resource usage limits of a Pod, because that is something
+that kubelet can only enforce for storage that it manages itself.
+
+
+Here's an example manifest for a Pod that uses CSI ephemeral storage:
+-->
+从概念上讲，CSI 临时卷类似于 `configMap`、`downwardAPI` 和 `secret` 类型的卷：
+其存储在每个节点本地管理，并在将 Pod 调度到节点后与其他本地资源一起创建。
+在这个阶段，Kubernetes 没有重新调度 Pods 的概念。卷创建不太可能失败，否则 Pod 启动将会受阻。
+特别是，这些卷 *不* 支持[感知存储容量的 Pod 调度](/zh/docs/concepts/storage/storage-capacity/)。
+它们目前也没包括在 Pod 的存储资源使用限制中，因为 kubelet 只能对它自己管理的存储强制执行。
+
+下面是使用 CSI 临时存储的 Pod 的示例清单：
+
+```yaml
+kind: Pod
+apiVersion: v1
+metadata:
+  name: my-csi-app
+spec:
+  containers:
+    - name: my-frontend
+      image: busybox
+      volumeMounts:
+      - mountPath: "/data"
+        name: my-csi-inline-vol
+      command: [ "sleep", "1000000" ]
+  volumes:
+    - name: my-csi-inline-vol
+      csi:
+        driver: inline.storage.kubernetes.io
+        volumeAttributes:
+          foo: bar
+```
+
+<!--
+The `volumeAttributes` determine what volume is prepared by the
+driver. These attributes are specific to each driver and not
+standardized. See the documentation of each CSI driver for further
+instructions.
+
+As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) to control which CSI drivers can be used in a Pod, specified with the
+[`allowedCSIDrivers` field](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy).
+-->
+`volumeAttributes` 决定驱动程序准备什么样的卷。这些属性特定于每个驱动程序，且没有实现标准化。
+有关进一步的说明，请参阅每个 CSI 驱动程序的文档。
+
+作为一个集群管理员，你可以使用 
+[PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/) 
+来控制在 Pod 中可以使用哪些 CSI 驱动程序，
+具体则是通过 [`allowedCSIDrivers` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)
+指定。
+
+<!--
+### Generic ephemeral volumes
+-->
+### 通用临时卷 {#generic-ephemeral-volumes}
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+<!--
+This feature requires the `GenericEphemeralVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be
+enabled. Because this is an alpha feature, it is disabled by default.
+-->
+这个特性需要启用 `GenericEphemeralVolume` 
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+因为这是一个alpha特性，默认禁用。
+
+<!--
+Generic ephemeral volumes are similar to `emptyDir` volumes, just more
+flexible:
+- Storage can be local or network-attached.
+- Volumes can have a fixed size that Pods are not able to exceed.
+- Volumes may have some initial data, depending on the driver and
+  parameters.
+- Typical operations on volumes are supported assuming that the driver
+  supports them, including
+  ([snapshotting](/docs/concepts/storage/volume-snapshots/),
+  [cloning](/docs/concepts/storage/volume-pvc-datasource/),
+  [resizing](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims),
+  and [storage capacity tracking](/docs/concepts/storage-capacity/).
+
+Example:
+-->
+通用临时卷类似于 `emptyDir` 卷，但更加灵活：
+- 存储可以是本地的，也可以是网络连接的。
+- 卷可以有固定的大小，pod不能超量使用。
+- 卷可能有一些初始数据，这取决于驱动程序和参数。
+- 当驱动程序支持，卷上的典型操作将被支持，包括（[快照](/zh/docs/concepts/storage/volume-snapshots/)、[克隆](/zh/docs/concepts/storage/volume-pvc-datasource/)、[调整大小](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)和[存储容量跟踪](/zh/docs/concepts/storage/storage-capacity/)）。
+
+示例：
+
+```yaml
+kind: Pod
+apiVersion: v1
+metadata:
+  name: my-app
+spec:
+  containers:
+    - name: my-frontend
+      image: busybox
+      volumeMounts:
+      - mountPath: "/scratch"
+        name: scratch-volume
+      command: [ "sleep", "1000000" ]
+  volumes:
+    - name: scratch-volume
+      ephemeral:
+        volumeClaimTemplate:
+          metadata:
+            labels:
+              type: my-frontend-volume
+          spec:
+            accessModes: [ "ReadWriteOnce" ]
+            storageClassName: "scratch-storage-class"
+            resources:
+              requests:
+                storage: 1Gi
+```
+
+<!--
+### Lifecycle and PersistentVolumeClaim
+-->
+### 生命周期和 PersistentVolumeClaim {#lifecycle-and-persistentvolumeclaim}
+
+<!--
+The key design idea is that the
+[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)
+are allowed inside a volume source of the Pod. Labels, annotations and
+the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
+created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
+object in the same namespace as the Pod and ensures that the PersistentVolumeClaim
+gets deleted when the Pod gets deleted.
+-->
+关键的设计思想是在 Pod 的卷来源中允许使用
+[卷申领的参数](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)。
+PersistentVolumeClaim 的标签、注解和整套字段集均被支持。
+创建这样一个 Pod 后，
+临时卷控制器在 Pod 所属的命名空间中创建一个实际的 PersistentVolumeClaim 对象，
+并确保删除 Pod 时，同步删除 PersistentVolumeClaim。
+
+<!--
+That triggers volume binding and/or provisioning, either immediately if
+the {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} uses immediate volume binding or when the Pod is
+tentatively scheduled onto a node (`WaitForFirstConsumer` volume
+binding mode). The latter is recommended for generic ephemeral volumes
+because then the scheduler is free to choose a suitable node for
+the Pod. With immediate binding, the scheduler is forced to select a node that has
+access to the volume once it is available.
+-->
+如上设置将触发卷的绑定与/或准备操作，相应动作或者在 
+{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 
+使用即时卷绑定时立即执行，
+或者当 Pod 被暂时性调度到某节点时执行 (`WaitForFirstConsumer` 卷绑定模式)。
+对于常见的临时卷，建议采用后者，这样调度器就可以自由地为 Pod 选择合适的节点。
+对于即时绑定，调度器则必须选出一个节点，使得在卷可用时，能立即访问该卷。
+
+<!--
+In terms of [resource ownership](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
+a Pod that has generic ephemeral storage is the owner of the PersistentVolumeClaim(s)
+that provide that ephemeral storage. When the Pod is deleted,
+the Kubernetes garbage collector deletes the PVC, which then usually
+triggers deletion of the volume because the default reclaim policy of
+storage classes is to delete volumes. You can create quasi-ephemeral local storage
+using a StorageClass with a reclaim policy of `retain`: the storage outlives the Pod, 
+and in this case you need to ensure that volume clean up happens separately.
+-->
+就[资源所有权](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)而言，
+拥有通用临时存储的 Pod 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。
+当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC，
+然后 PVC 通常会触发卷的删除，因为存储类的默认回收策略是删除卷。
+你可以使用带有 `retain` 回收策略的 StorageClass 创建准临时 (quasi-ephemeral) 本地存储：
+该存储比 Pod 寿命长，在这种情况下，你需要确保单独进行卷清理。
+
+<!--
+While these PVCs exist, they can be used like any other PVC. In
+particular, they can be referenced as data source in volume cloning or
+snapshotting. The PVC object also holds the current status of the
+volume.
+-->
+当这些 PVC 存在时，它们可以像其他 PVC 一样使用。
+特别是，它们可以被引用作为批量克隆或快照的数据源。
+PVC对象还保持着卷的当前状态。
+
+<!--
+### PersistentVolumeClaim naming
+-->
+### PersistentVolumeClaim 的命名 {#persistentvolumeclaim-naming}
+
+<!--
+Naming of the automatically created PVCs is deterministic: the name is
+a combination of Pod name and volume name, with a hyphen (`-`) in the
+middle. In the example above, the PVC name will be
+`my-app-scratch-volume`.  This deterministic naming makes it easier to
+interact with the PVC because one does not have to search for it once
+the Pod name and volume name are known.
+-->
+自动创建的 PVCs 的命名是确定的：此名称是 Pod 名称和卷名称的组合，中间由连字符(`-`)连接。
+在上面的示例中，PVC 将命名为 `my-app-scratch-volume` 。
+这种确定性命名方式使得与 PVC 交互变得更容易，因为一旦知道 Pod 名称和卷名，就不必搜索它。
+
+<!--
+The deterministic naming also introduces a potential conflict between different
+Pods (a Pod "pod-a" with volume "scratch" and another Pod with name
+"pod" and volume "a-scratch" both end up with the same PVC name
+"pod-a-scratch") and between Pods and manually created PVCs.
+-->
+这种确定性命名方式也引入了潜在的冲突，
+比如在不同的 Pod 之间（名为 “Pod-a” 的 Pod 挂载名为 "scratch" 的卷，
+名为 "pod" 的 Pod 挂载名为 “a-scratch” 的卷，这两者均会生成名为 "pod-a-scratch" 的PVC），
+或者在 Pod 和手工创建的 PVC 之间。
+
+<!--
+Such conflicts are detected: a PVC is only used for an ephemeral
+volume if it was created for the Pod. This check is based on the
+ownership relationship. An existing PVC is not overwritten or
+modified. But this does not resolve the conflict because without the
+right PVC, the Pod cannot start.
+-->
+以下冲突会被检测到：如果 PVC 是为 Pod 创建的，那么它只用于临时卷。
+此检测基于所有权关系。现有的 PVC 不会被覆盖或修改。
+但这并不能解决冲突，因为如果没有正确的 PVC，Pod 就无法启动。
+
+<!--
+Take care when naming Pods and volumes inside the
+same namespace, so that these conflicts can't occur.
+-->
+{{< caution >}}
+当命名 Pods 和卷出现在同一个命名空间中时，要小心，以防止发生此类冲突。
+{{< /caution >}}
+
+<!--
+### Security
+-->
+### 安全 {#security}
+
+<!--
+Enabling the GenericEphemeralVolume feature allows users to create
+PVCs indirectly if they can create Pods, even if they do not have
+permission to create PVCs directly. Cluster administrators must be
+aware of this. If this does not fit their security model, they have
+two choices:
+-->
+启用 GenericEphemeralVolume 特性会导致那些没有 PVCs 创建权限的用户，
+在创建 Pods 时，被允许间接的创建 PVCs。
+集群管理员必须意识到这一点。
+如果这不符合他们的安全模型，他们有两种选择：
+<!--
+- Explicitly disable the feature through the feature gate, to avoid
+  being surprised when some future Kubernetes version enables it
+  by default.
+- Use a [Pod Security
+  Policy](/docs/concepts/policy/pod-security-policy/) where the
+  `volumes` list does not contain the `ephemeral` volume type.
+-->
+- 通过特性门控显式禁用该特性，可以避免将来的 Kubernetes 版本默认启用时带来混乱。
+- 当`卷`列表不包含 `ephemeral` 卷类型时，使用
+  [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)。
+
+<!--
+The normal namespace quota for PVCs in a namespace still applies, so
+even if users are allowed to use this new mechanism, they cannot use
+it to circumvent other policies.
+-->
+在一个命名空间中，用于 PVCs 的常规命名空间配额仍然适用，
+因此即使允许用户使用这种新机制，他们也不能使用它来规避其他策略。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+### Ephemeral volumes managed by kubelet
+
+See [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).
+-->
+### kubelet 管理的临时卷 {#ephemeral-volumes-managed-by-kubelet}
+
+参阅[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。
+
+<!--
+### CSI ephemeral volumes
+
+- For more information on the design, see the [Ephemeral Inline CSI
+  volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md).
+- For more information on further development of this feature, see the [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596).
+-->
+### CSI 临时卷 {#csi-ephemeral-volumes}
+
+- 有关设计的更多信息，参阅
+  [Ephemeral Inline CSI volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)。
+- 本特性下一步开发的更多信息，参阅
+  [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596)。
+
+<!--
+### Generic ephemeral volumes
+
+- For more information on the design, see the
+[Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md).
+- For more information on further development of this feature, see the [enhancement tracking issue #1698](https://github.com/kubernetes/enhancements/issues/1698).
+-->
+### 通用临时卷 {#generic-ephemeral-volumes}
+
+- 有关设计的更多信息，参阅
+  [Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)。
+- 本特性下一步开发的更多信息，参阅
+  [enhancement tracking issue #1698](https://github.com/kubernetes/enhancements/issues/1698).
diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh/docs/concepts/storage/persistent-volumes.md
new file mode 100644
index 0000000000..48fbce7566
--- /dev/null
+++ b/content/zh/docs/concepts/storage/persistent-volumes.md
@@ -0,0 +1,1470 @@
+---
+title: 持久卷
+feature:
+  title: 存储编排
+  description: >
+    自动挂载所选存储系统，包括本地存储、诸如 <a href="https://cloud.google.com/storage/">GCP</a> 或 <a href="https://aws.amazon.com/products/storage/">AWS</a> 之类公有云提供商所提供的存储或者诸如 NFS、iSCSI、Gluster、Ceph、Cinder 或 Flocker 这类网络存储系统。
+
+content_type: concept
+weight: 20
+---
+<!--
+reviewers:
+- jsafrane
+- saad-ali
+- thockin
+- msau42
+- xing-yang
+title: Persistent Volumes
+feature:
+  title: Storage orchestration
+  description: >
+    Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
+
+content_type: concept
+weight: 20
+-->
+
+<!-- overview -->
+
+<!--
+This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
+-->
+本文描述 Kubernetes 中 _持久卷（Persistent Volume）_ 的当前状态。
+建议先熟悉[卷（Volume）](/zh/docs/concepts/storage/volumes/)的概念。
+
+<!-- body -->
+
+<!--
+## Introduction
+
+Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources:  PersistentVolume and PersistentVolumeClaim.
+-->
+## 介绍  {#introduction}
+
+存储的管理是一个与计算实例的管理完全不同的问题。PersistentVolume 子系统为用户
+和管理员提供了一组 API，将存储如何供应的细节从其如何被使用中抽象出来。
+为了实现这点，我们引入了两个新的 API 资源：PersistentVolume 和
+PersistentVolumeClaim。
+
+<!--
+A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
+-->
+持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者
+使用[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes/)来动态供应。
+持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用
+卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。
+此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
+
+<!--
+A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory).  Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see [AccessModes](#access-modes)).
+-->
+持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与 Pod 类似。
+Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU
+和内存）；同样 PVC 申领也可以请求特定的大小和访问模式
+（例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany
+模式之一来挂载，参见[访问模式](#access-modes)）。
+
+<!--
+While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.
+
+See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+-->
+尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源，常见的情况是针对不同的
+问题用户需要的是具有不同属性（如，性能）的 PersistentVolume 卷。
+集群管理员需要能够提供不同性质的 PersistentVolume，并且这些 PV 卷之间的差别不
+仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。
+为了满足这类需求，就有了 _存储类（StorageClass）_ 资源。
+
+参见[基于运行示例的详细演练](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
+
+<!--
+## Lifecycle of a volume and claim
+
+PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle:
+
+### Provisioning
+
+There are two ways PVs may be provisioned: statically or dynamically.
+-->
+## 卷和申领的生命周期   {#lifecycle-of-a-volume-and-claim}
+
+PV 卷是集群中的资源。PVC 申领是对这些资源的请求，也被用来执行对资源的申领检查。
+PV 卷和 PVC 申领之间的互动遵循如下生命周期：
+
+### 供应   {#provisioning}
+
+PV 卷的供应有两种方式：静态供应或动态供应。
+
+<!--
+#### Static
+
+A cluster administrator creates a number of PVs. 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.
+-->
+#### 静态供应  {#static}
+
+集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息，并且对集群
+用户可用（可见）。PV 卷对象存在于 Kubernetes  API 中，可供用户消费（使用）。
+
+<!--
+#### Dynamic
+
+When none of the static PVs the administrator created match a user's PersistentVolumeClaim,
+the cluster may try to dynamically provision a volume specially for the PVC.
+This provisioning is based on StorageClasses: the PVC must request a
+[storage class](/docs/concepts/storage/storage-classes/) and
+the administrator must have created and configured that class for dynamic
+provisioning to occur. Claims that request the class `""` effectively disable
+dynamic provisioning for themselves.
+-->
+#### 动态供应     {#dynamic}
+
+如果管理员所创建的所有静态 PV 卷都无法与用户的 PersistentVolumeClaim 匹配，
+集群可以尝试为该 PVC 申领动态供应一个存储卷。
+这一供应操作是基于 StorageClass 来实现的：PVC 申领必须请求某个
+[存储类](/zh/docs/concepts/storage/storage-classes/)，同时集群管理员必须
+已经创建并配置了该类，这样动态供应卷的动作才会发生。
+如果 PVC 申领指定存储类为 `""`，则相当于为自身禁止使用动态供应的卷。
+
+<!--
+To enable dynamic storage provisioning based on storage class, the cluster administrator
+needs to enable the `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
+on the API server. This can be done, for example, by ensuring that `DefaultStorageClass` is
+among the comma-delimited, ordered list of values for the `-enable-admission-plugins` flag of
+the API server component. For more information on API server command-line flags,
+check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.
+-->
+为了基于存储类完成动态的存储供应，集群管理员需要在 API 服务器上启用
+`DefaultStorageClass` [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)。
+举例而言，可以通过保证 `DefaultStorageClass` 出现在 API 服务器组件的
+`--enable-admission-plugins` 标志值中实现这点；该标志的值可以是逗号
+分隔的有序列表。关于 API 服务器标志的更多信息，可以参考
+[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
+文档。
+
+<!--
+### Binding
+
+A user creates, or in the case of dynamic provisioning, has already created, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, using a ClaimRef which is a bi-directional binding between the PersistentVolume and the PersistentVolumeClaim.
+
+Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
+-->
+### 绑定     {#binding}
+
+用户创建一个带有特定存储容量和特定访问模式需求的 PersistentVolumeClaim 对象；
+在动态供应场景下，这个 PVC 对象可能已经创建完毕。
+主控节点中的控制回路监测新的 PVC 对象，寻找与之匹配的 PV 卷（如果可能的话），
+并将二者绑定到一起。
+如果为了新的 PVC 申领动态供应了 PV 卷，则控制回路总是将该 PV 卷绑定到这一 PVC 申领。
+否则，用户总是能够获得他们所请求的资源，只是所获得的 PV 卷可能会超出所请求的配置。
+一旦绑定关系建立，则 PersistentVolumeClaim 绑定就是排他性的，无论该 PVC 申领是
+如何与 PV 卷建立的绑定关系。
+PVC 申领与 PV 卷之间的绑定是一种一对一的映射，实现上使用 ClaimRef 来记述 PV 卷
+与 PVC 申领间的双向绑定关系。
+
+<!--
+Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
+-->
+如果找不到匹配的 PV 卷，PVC 申领会无限期地处于未绑定状态。
+当与之匹配的 PV 卷可用时，PVC 申领会被绑定。
+例如，即使某集群上供应了很多 50 Gi 大小的 PV 卷，也无法与请求
+100 Gi 大小的存储的 PVC 匹配。当新的 100 Gi PV 卷被加入到集群时，该
+PVC 才有可能被绑定。
+
+<!--
+### Using
+
+Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a Pod. For volumes that support multiple access modes, the user specifies which mode is desired when using their claim as a volume in a Pod.
+-->
+### 使用    {#using}
+
+Pod 将 PVC 申领当做存储卷来使用。集群会检视 PVC 申领，找到所绑定的卷，并
+为 Pod 挂载该卷。对于支持多种访问模式的卷，用户要在 Pod 中以卷的形式使用申领
+时指定期望的访问模式。
+
+<!--
+Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a `persistentVolumeClaim` section in a Pod's `volumes` block. See [Claims As Volumes](#claims-as-volumes) for more details on this.
+-->
+一旦用户有了申领对象并且该申领已经被绑定，则所绑定的 PV 卷在用户仍然需要它期间
+一直属于该用户。用户通过在 Pod 的 `volumes` 块中包含 `persistentVolumeClaim`
+节区来调度 Pod，访问所申领的 PV 卷。
+相关细节可参阅[使用申领作为卷](#claims-as-volumes)。
+
+<!--
+### Storage Object in Use Protection
+
+The purpose of the Storage Object in Use Protection feature is to ensure that PersistentVolumeClaims (PVCs) in active use by a Pod and PersistentVolume (PVs) that are bound to PVCs are not removed from the system, as this may result in data loss.
+-->
+### 保护使用中的存储对象   {#storage-object-in-use-protection}
+
+保护使用中的存储对象（Storage Object in Use Protection）这一功能特性的目的
+是确保仍被 Pod 使用的 PersistentVolumeClaim（PVC）对象及其所绑定的
+PersistentVolume（PV）对象在系统中不会被删除，因为这样做可能会引起数据丢失。
+
+<!--
+PVC is in active use by a Pod when a Pod object exists that is using the PVC.
+-->
+{{< note >}}
+当使用某 PVC 的 Pod 对象仍然存在时，认为该 PVC 仍被此 Pod 使用。
+{{< /note >}}
+
+<!--
+If a user deletes a PVC in active use by a Pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any Pods. Also, if an admin deletes a PV that is bound to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is no longer bound to a PVC.
+
+You can see that a PVC is protected when the PVC's status is `Terminating` and the `Finalizers` list includes `kubernetes.io/pvc-protection`:
+-->
+如果用户删除被某 Pod 使用的 PVC 对象，该 PVC 申领不会被立即移除。
+PVC 对象的移除会被推迟，直至其不再被任何 Pod 使用。
+此外，如果管理员删除已绑定到某 PVC 申领的 PV 卷，该 PV 卷也不会被立即移除。
+PV 对象的移除也要推迟到该 PV 不再绑定到 PVC。
+
+你可以看到当 PVC 的状态为 `Terminating` 且其 `Finalizers` 列表中包含
+`kubernetes.io/pvc-protection` 时，PVC 对象是处于被保护状态的。
+
+```shell
+kubectl describe pvc hostpath
+```
+```
+Name:          hostpath
+Namespace:     default
+StorageClass:  example-hostpath
+Status:        Terminating
+Volume:
+Labels:        <none>
+Annotations:   volume.beta.kubernetes.io/storage-class=example-hostpath
+               volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
+Finalizers:    [kubernetes.io/pvc-protection]
+...
+```
+
+<!--
+You can see that a PV is protected when the PV's status is `Terminating` and the `Finalizers` list includes `kubernetes.io/pv-protection` too:
+-->
+你也可以看到当 PV 对象的状态为 `Terminating` 且其 `Finalizers` 列表中包含
+`kubernetes.io/pvc-protection` 时，PV 对象是处于被保护状态的。
+
+```shell
+kubectl describe pv task-pv-volume
+```
+```
+Name:            task-pv-volume
+Labels:          type=local
+Annotations:     <none>
+Finalizers:      [kubernetes.io/pv-protection]
+StorageClass:    standard
+Status:          Terminating
+Claim:
+Reclaim Policy:  Delete
+Access Modes:    RWO
+Capacity:        1Gi
+Message:
+Source:
+    Type:          HostPath (bare host directory volume)
+    Path:          /tmp/data
+    HostPathType:
+Events:            <none>
+```
+
+<!--
+### Reclaiming
+
+When a user is done with their volume, they can delete the PVC objects from the API that allows reclamation of the resource. The reclaim policy for a PersistentVolume tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled, or Deleted.
+-->
+### 回收   {#reclaiming}
+
+当用户不再使用其存储卷时，他们可以从 API 中将 PVC 对象删除，从而允许
+该资源被回收再利用。PersistentVolume 对象的回收策略告诉集群，当其被
+从申领中释放时如何处理该数据卷。
+目前，数据卷可以被 Retained（保留）、Recycled（回收）或 Deleted（删除）。
+
+<!--
+#### Retain
+
+The `Retain` reclaim policy allows for manual reclamation of the resource. When the PersistentVolumeClaim is deleted, the PersistentVolume still exists and the volume is considered "released". But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps.
+-->
+#### 保留（Retain）    {#retain}
+
+回收策略 `Retain` 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象
+被删除时，PersistentVolume 卷仍然存在，对应的数据卷被视为"已释放（released）"。
+由于卷上仍然存在这前一申领人的数据，该卷还不能用于其他申领。
+管理员可以通过下面的步骤来手动回收该卷：
+
+<!--
+1. Delete the PersistentVolume. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.
+1. Manually clean up the data on the associated storage asset accordingly.
+1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new PersistentVolume with the storage asset definition.
+-->
+1. 删除 PersistentVolume 对象。与之相关的、位于外部基础设施中的存储资产
+   （例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）在 PV 删除之后仍然存在。
+1. 根据情况，手动清除所关联的存储资产上的数据。
+1. 手动删除所关联的存储资产；如果你希望重用该存储资产，可以基于存储资产的
+   定义创建新的 PersistentVolume 卷对象。
+
+<!--
+#### Delete
+
+For volume plugins that support the `Delete` reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their StorageClass](#reclaim-policy), which defaults to `Delete`. The administrator should configure the StorageClass according to users' expectations; otherwise, the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
+-->
+#### 删除（Delete）    {#delete}
+
+对于支持 `Delete` 回收策略的卷插件，删除动作会将 PersistentVolume 对象从
+Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS、GCE PD、Azure Disk 或
+Cinder 卷）中移除所关联的存储资产。 
+动态供应的卷会继承[其 StorageClass 中设置的回收策略](#reclaim-policy)，该策略默认
+为 `Delete`。
+管理员需要根据用户的期望来配置 StorageClass；否则 PV 卷被创建之后必须要被
+编辑或者修补。参阅[更改 PV 卷的回收策略](/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
+
+<!--
+#### Recycle
+
+The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
+
+If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
+-->
+#### 回收（Recycle）     {#recycle}
+
+{{< warning >}}
+回收策略 `Recycle` 已被废弃。取而代之的建议方案是使用动态供应。
+{{< /warning >}}
+
+如果下层的卷插件支持，回收策略 `Recycle` 会在卷上执行一些基本的
+擦除（`rm -rf /thevolume/*`）操作，之后允许该卷用于新的 PVC 申领。
+
+<!--
+However, an administrator can configure a custom recycler Pod template using
+the Kubernetes controller manager command line arguments as described in the
+[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/).
+The custom recycler Pod template must contain a `volumes` specification, as
+shown in the example below:
+-->
+不过，管理员可以按
+[参考资料](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
+中所述，使用 Kubernetes 控制器管理器命令行参数来配置一个定制的回收器（Recycler）
+Pod 模板。此定制的回收器 Pod 模板必须包含一个 `volumes` 规约，如下例所示：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: pv-recycler
+  namespace: default
+spec:
+  restartPolicy: Never
+  volumes:
+  - name: vol
+    hostPath:
+      path: /any/path/it/will/be/replaced
+  containers:
+  - name: pv-recycler
+    image: "k8s.gcr.io/busybox"
+    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \"$(ls -A /scrub)\" || exit 1"]
+    volumeMounts:
+    - name: vol
+      mountPath: /scrub
+```
+
+<!--
+However, the particular path specified in the custom recycler Pod template in the `volumes` part is replaced with the particular path of the volume that is being recycled.
+-->
+定制回收器 Pod 模板中在 `volumes` 部分所指定的特定路径要替换为
+正被回收的卷的路径。
+
+<!--
+### Reserving a PersistentVolume
+
+The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) in the
+cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them.
+-->
+### 预留 PersistentVolume  {#reserving-a-persistentvolume}
+
+通过在 PersistentVolumeClaim 中指定 PersistentVolume，你可以声明该特定
+PV 与 PVC 之间的绑定关系。如果该 PersistentVolume 存在且未被通过其
+`claimRef` 字段预留给 PersistentVolumeClaim，则该 PersistentVolume
+会和该 PersistentVolumeClaim 绑定到一起。
+
+<!--
+The binding happens regardless of some volume matching criteria, including node affinity.
+The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
+-->
+绑定操作不会考虑某些卷匹配条件是否满足，包括节点亲和性等等。
+控制面仍然会检查
+[存储类](/zh/docs/concepts/storage/storage-classes/)、访问模式和所请求的
+存储尺寸都是合法的。
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: foo-pvc
+  namespace: foo
+spec:
+  storageClassName: "" # 此处须显式设置空字符串，否则会被设置为默认的 StorageClass
+  volumeName: foo-pv
+  ...
+```
+
+<!--
+This method does not guarantee any binding privileges to the PersistentVolume. If other PersistentVolumeClaims could use the PV that you specify, you first need to reserve that storage volume. Specify the relevant PersistentVolumeClaim in the `claimRef` field of the PV so that other PVCs can not bind to it.
+-->
+此方法无法对 PersistentVolume 的绑定特权做出任何形式的保证。
+如果有其他 PersistentVolumeClaim 可以使用你所指定的 PV，则你应该首先预留
+该存储卷。你可以将 PV 的 `claimRef` 字段设置为相关的 PersistentVolumeClaim
+以确保其他 PVC 不会绑定到该 PV 卷。
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: foo-pv
+spec:
+  storageClassName: ""
+  claimRef:
+    name: foo-pvc
+    namespace: foo
+  ...
+```
+
+<!--
+This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set
+to `Retain`, including cases where you are reusing an existing PV.
+-->
+如果你想要使用 `claimPolicy` 属性设置为 `Retain` 的 PersistentVolume 卷
+时，包括你希望复用现有的 PV 卷时，这点是很有用的
+
+<!--
+### Expanding Persistent Volumes Claims
+-->
+### 扩充 PVC 申领   {#expanding-persistent-volumes-claims}
+
+{{< feature-state for_k8s_version="v1.11" state="beta" >}}
+
+<!--
+Support for expanding PersistentVolumeClaims (PVCs) is now enabled by default. You can expand
+the following types of volumes:
+-->
+现在，对扩充 PVC 申领的支持默认处于被启用状态。你可以扩充以下类型的卷：
+
+* gcePersistentDisk
+* awsElasticBlockStore
+* Cinder
+* glusterfs
+* rbd
+* Azure File
+* Azure Disk
+* Portworx
+* FlexVolumes
+* CSI
+
+<!--
+You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true.
+-->
+只有当 PVC 的存储类中将 `allowVolumeExpansion` 设置为 true 时，你才可以扩充该 PVC 申领。
+
+``` yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: gluster-vol-default
+provisioner: kubernetes.io/glusterfs
+parameters:
+  resturl: "http://192.168.10.100:8080"
+  restuser: ""
+  secretNamespace: ""
+  secretName: ""
+allowVolumeExpansion: true
+```
+
+<!--
+To request a larger volume for a PVC, edit the PVC object and specify a larger
+size. This triggers expansion of the volume that backs the underlying PersistentVolume. A
+new PersistentVolume is never created to satisfy the claim. Instead, an existing volume is resized.
+-->
+如果要为某 PVC 请求较大的存储卷，可以编辑 PVC 对象，设置一个更大的尺寸值。
+这一编辑操作会触发为下层 PersistentVolume 提供存储的卷的扩充。
+Kubernetes 不会创建新的 PV 卷来满足此申领的请求。
+与之相反，现有的卷会被调整大小。
+
+<!--
+#### CSI Volume expansion
+-->
+#### CSI 卷的扩充     {#csi-volume-expansion}
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+<!--
+Support for expanding CSI volumes is enabled by default but it also requires a specific CSI driver to support volume expansion. Refer to documentation of the specific CSI driver for more information.
+-->
+对 CSI 卷的扩充能力默认是被启用的，不过扩充 CSI 卷要求 CSI 驱动支持
+卷扩充操作。可参阅特定 CSI 驱动的文档了解更多信息。
+
+<!--
+#### Resizing a volume containing a file system
+
+You can only resize volumes containing a file system if the file system is XFS, Ext3, or Ext4.
+-->
+#### 重设包含文件系统的卷的大小 {#resizing-a-volume-containing-a-file-system}
+
+只有卷中包含的文件系统是 XFS、Ext3 或者 Ext4 时，你才可以重设卷的大小。
+
+<!--
+When a volume contains a file system, the file system is only resized when a new Pod is using
+the PersistentVolumeClaim in `ReadWrite` mode. File system expansion is either done when a Pod is starting up
+or when a Pod is running and the underlying file system supports online expansion.
+
+FlexVolumes allow resize if the driver is set with the `RequiresFSResize` capability to `true`.
+The FlexVolume can be resized on Pod restart.
+-->
+当卷中包含文件系统时，只有在 Pod 使用 `ReadWrite` 模式来使用 PVC 申领的
+情况下才能重设其文件系统的大小。
+文件系统扩充的操作或者是在 Pod 启动期间完成，或者在下层文件系统支持在线
+扩充的前提下在 Pod 运行期间完成。
+
+如果 FlexVolumes 的驱动将 `RequiresFSResize` 能力设置为 `true`，则该
+FlexVolume 卷可以在 Pod 重启期间调整大小。
+
+<!--
+#### Resizing an in-use PersistentVolumeClaim
+-->
+#### 重设使用中 PVC 申领的大小    {#resizing-an-in-use-persistentvolumevlaim}
+
+{{< feature-state for_k8s_version="v1.15" state="beta" >}}
+
+<!--
+Expanding in-use PVCs is available as beta since Kubernetes 1.15, and as alpha since 1.11. The `ExpandInUsePersistentVolumes` feature must be enabled, which is the case automatically for many clusters for beta features. Refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information.
+-->
+{{< note >}}
+Kubernetes 从 1.15 版本开始将调整使用中 PVC 申领大小这一能力作为 Beta
+特性支持；该特性在 1.11 版本以来处于 Alpha 阶段。
+`ExpandInUsePersistentVolumes` 特性必须被启用；在很多集群上，与此类似的
+Beta 阶段的特性是自动启用的。
+可参考[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+文档了解更多信息。
+{{< /note >}}
+
+<!--
+In this case, you don't need to delete and recreate a Pod or deployment that is using an existing PVC.
+Any in-use PVC automatically becomes available to its Pod as soon as its file system has been expanded.
+This feature has no effect on PVCs that are not in use by a Pod or deployment. You must create a Pod that
+uses the PVC before the expansion can complete.
+-->
+在这种情况下，你不需要删除和重建正在使用某现有 PVC 的 Pod 或 Deployment。
+所有使用中的 PVC 在其文件系统被扩充之后，立即可供其 Pod 使用。
+此功能特性对于没有被 Pod 或 Deployment 使用的 PVC 而言没有效果。
+你必须在执行扩展操作之前创建一个使用该 PVC 的 Pod。
+
+<!--
+Similar to other volume types - FlexVolume volumes can also be expanded when in-use by a Pod.
+-->
+与其他卷类型类似，FlexVolume 卷也可以在被 Pod 使用期间执行扩充操作。
+
+<!--
+FlexVolume resize is possible only when the underlying driver supports resize.
+-->
+{{< note >}}
+FlexVolume 卷的重设大小只能在下层驱动支持重设大小的时候才可进行。
+{{< /note >}}
+
+<!--
+Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
+-->
+{{< note >}}
+扩充 EBS 卷的操作非常耗时。同时还存在另一个配额限制：
+每 6 小时只能执行一次（尺寸）修改操作。
+{{< /note >}}
+
+<!--
+#### Recovering from Failure when Expanding Volumes
+
+If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention.
+-->
+#### 处理扩充卷过程中的失败      {#recovering-from-failure-when-expanding-volumes}
+
+如果扩充下层存储的操作失败，集群管理员可以手动地恢复 PVC 申领的状态并
+取消重设大小的请求。否则，在没有管理员干预的情况下，控制器会反复重试
+重设大小的操作。
+
+<!--
+1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy.
+2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not lose any data when we recreate the PVC.
+3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`.
+4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV.
+5. Don't forget to restore the reclaim policy of the PV.
+-->
+1. 将绑定到 PVC 申领的 PV 卷标记为 `Retain` 回收策略；
+2. 删除 PVC 对象。由于 PV 的回收策略为 `Retain`，我们不会在重建 PVC 时丢失数据。
+3. 删除 PV 规约中的 `claimRef` 项，这样新的 PVC 可以绑定到该卷。
+   这一操作会使得 PV 卷变为 "可用（Available）"。
+4. 使用小于 PV 卷大小的尺寸重建 PVC，设置 PVC 的 `volumeName` 字段为 PV 卷的名称。
+   这一操作将把新的 PVC 对象绑定到现有的 PV 卷。
+5. 不要忘记恢复 PV 卷上设置的回收策略。
+
+<!--
+## Types of Persistent Volumes
+
+PersistentVolume types are implemented as plugins.  Kubernetes currently supports the following plugins:
+-->
+
+## 持久卷的类型     {#types-of-persistent-volumes}
+
+PV 持久卷是用插件的形式来实现的。Kubernetes 目前支持以下插件：
+
+* GCEPersistentDisk
+* AWSElasticBlockStore
+* AzureFile
+* AzureDisk
+* CSI
+* FC （光纤通道）
+* FlexVolume
+* Flocker
+* NFS
+* iSCSI
+* RBD （Ceph 块设备）
+* CephFS
+* Cinder （OpenStack 块存储）
+* Glusterfs
+* VsphereVolume
+* Quobyte 卷
+* HostPath （仅供单节点测试用，本地存储都是不支持的，在多节点集群中无法工作）
+* Portworx 卷
+* ScaleIO 卷
+* StorageOS
+
+<!--
+## Persistent Volumes
+
+Each PV contains a spec and status, which is the specification and status of the volume.
+The name of a PersistentVolume object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+## 持久卷    {#persistent-volumes}
+
+每个 PV 对象都包含 `spec` 部分和 `status` 部分，分别对应卷的规约和状态。
+PersistentVolume 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv0003
+spec:
+  capacity:
+    storage: 5Gi
+  volumeMode: Filesystem
+  accessModes:
+    - ReadWriteOnce
+  persistentVolumeReclaimPolicy: Recycle
+  storageClassName: slow
+  mountOptions:
+    - hard
+    - nfsvers=4.1
+  nfs:
+    path: /tmp
+    server: 172.17.0.2
+```
+
+<!--
+Helper programs relating to the volume type may be required for consumption of a PersistentVolume within a cluster.  In this example, the PersistentVolume is of type NFS and the helper program /sbin/mount.nfs is required to support the mounting of NFS filesystems.
+-->
+{{< note >}}
+在集群中使用持久卷存储通常需要一些特定于具体卷类型的辅助程序。
+在这个例子中，PersistentVolume 是 NFS 类型的，因此需要辅助程序 `/sbin/mount.nfs`
+来支持挂载 NFS 文件系统。
+{{< /note >}}
+
+<!--
+### Capacity
+
+Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`.
+
+Currently, storage size is the only resource that can be set or requested.  Future attributes may include IOPS, throughput, etc.
+-->
+### 容量    {#capacity}
+
+一般而言，每个 PV 卷都有确定的存储容量。
+容量属性是使用 PV 对象的 `capacity` 属性来设置的。
+参考 Kubernetes
+[资源模型（Resource Model）](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) 
+设计提案，了解 `capacity` 字段可以接受的单位。
+
+目前，存储大小是可以设置和请求的唯一资源。
+未来可能会包含 IOPS、吞吐量等属性。
+
+<!--
+### Volume Mode
+-->
+### 卷模式     {#volume-mode}
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+<!--
+Kubernetes supports two `volumeModes` of PersistentVolumes: `Filesystem` and `Block`.
+
+`volumeMode` is an optional API parameter.
+`Filesystem` is the default mode used when `volumeMode` parameter is omitted.
+
+A volume with `volumeMode: Filesystem` is *mounted* into Pods into a directory. If the volume
+is backed by a block device and the device is empty, Kuberneretes creates a filesystem
+on the device before mounting it for the first time.
+-->
+针对 PV 持久卷，Kuberneretes
+支持两种卷模式（`volumeModes`）：`Filesystem（文件系统）` 和 `Block（块）`。
+`volumeMode` 是一个可选的 API 参数。
+如果该参数被省略，默认的卷模式是 `Filesystem`。
+
+`volumeMode` 属性设置为 `Filesystem` 的卷会被 Pod *挂载（Mount）* 到某个目录。
+如果卷的存储来自某块设备而该设备目前为空，Kuberneretes 会在第一次挂载卷之前
+在设备上创建文件系统。
+
+<!--
+You can set the value of `volumeMode` to `Block` to use a volume as a raw block device.
+Such volume is presented into a Pod as a block device, without any filesystem on it.
+This mode is useful to provide a Pod the fastest possible way to access a volume, without
+any filesystem layer between the Pod and the volume. On the other hand, the application
+running in the Pod must know how to handle a raw block device.
+See [Raw Block Volume Support](#raw-block-volume-support)
+for an example on how to use a volume with `volumeMode: Block` in a Pod.
+-->
+你可以将 `volumeMode` 设置为 `Block`，以便将卷作为原始块设备来使用。
+这类卷以块设备的方式交给 Pod 使用，其上没有任何文件系统。
+这种模式对于为 Pod 提供一种使用最快可能方式来访问卷而言很有帮助，Pod 和
+卷之间不存在文件系统层。另外，Pod 中运行的应用必须知道如何处理原始块设备。
+关于如何在 Pod 中使用 `volumeMode: Block` 的卷，可参阅
+[原始块卷支持](#raw-block-volume-support)。
+
+<!--
+### Access Modes
+
+A PersistentVolume can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV's capabilities.
+-->
+### 访问模式   {#access-modes}
+
+PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。
+如下表所示，提供者（驱动）的能力不同，每个 PV 卷的访问模式都会设置为
+对应卷所支持的模式值。
+例如，NFS 可以支持多个读写客户，但是某个特定的 NFS PV 卷可能在服务器
+上以只读的方式导出。每个 PV 卷都会获得自身的访问模式集合，描述的是
+特定 PV 卷的能力。
+
+<!--
+The access modes are:
+
+* ReadWriteOnce -- the volume can be mounted as read-write by a single node
+* ReadOnlyMany -- the volume can be mounted read-only by many nodes
+* ReadWriteMany -- the volume can be mounted as read-write by many nodes
+-->
+访问模式有：
+
+* ReadWriteOnce -- 卷可以被一个节点以读写方式挂载；
+* ReadOnlyMany -- 卷可以被多个节点以只读方式挂载；
+* ReadWriteMany -- 卷可以被多个节点以读写方式挂载。
+
+<!--
+In the CLI, the access modes are abbreviated to:
+
+* RWO - ReadWriteOnce
+* ROX - ReadOnlyMany
+* RWX - ReadWriteMany
+-->
+在命令行接口（CLI）中，访问模式也使用以下缩写形式：
+
+* RWO - ReadWriteOnce
+* ROX - ReadOnlyMany
+* RWX - ReadWriteMany
+
+<!--
+> __Important!__ A volume can only be mounted using one access mode at a time, even if it supports many.  For example, a GCEPersistentDisk can be mounted as ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time.
+-->
+> __重要提醒！__ 每个卷只能同一时刻只能以一种访问模式挂载，即使该卷能够支持
+> 多种访问模式。例如，一个 GCEPersistentDisk 卷可以被某节点以 ReadWriteOnce
+> 模式挂载，或者被多个节点以 ReadOnlyMany 模式挂载，但不可以同时以两种模式
+> 挂载。
+
+<!--
+| Volume Plugin        | ReadWriteOnce          | ReadOnlyMany          | ReadWriteMany|
+-->
+
+| 卷插件               | ReadWriteOnce  | ReadOnlyMany | ReadWriteMany|
+| :---                 | :---:          | :---:        | :---:        |
+| AWSElasticBlockStore | &#x2713;       | -            | -            |
+| AzureFile            | &#x2713;       | &#x2713;     | &#x2713;     |
+| AzureDisk            | &#x2713;       | -            | -            |
+| CephFS               | &#x2713;       | &#x2713;     | &#x2713;     |
+| Cinder               | &#x2713;       | -            | -            |
+| CSI                  | 取决于驱动     | 取决于驱动   | 取决于驱动   |
+| FC                   | &#x2713;       | &#x2713;     | -            |
+| FlexVolume           | &#x2713;       | &#x2713;     | 取决于驱动   |
+| Flocker              | &#x2713;       | -            | -            |
+| GCEPersistentDisk    | &#x2713;       | &#x2713;     | -            |
+| Glusterfs            | &#x2713;       | &#x2713;     | &#x2713;     |
+| HostPath             | &#x2713;       | -            | -            |
+| iSCSI                | &#x2713;       | &#x2713;     | -            |
+| Quobyte              | &#x2713;       | &#x2713;     | &#x2713;     |
+| NFS                  | &#x2713;       | &#x2713;     | &#x2713;     |
+| RBD                  | &#x2713;       | &#x2713;     | -            |
+| VsphereVolume        | &#x2713;       | -            | - (Pod 运行于同一节点上时可行)  |
+| PortworxVolume       | &#x2713;       | -            | &#x2713;     |
+| ScaleIO              | &#x2713;       | &#x2713;     | -            |
+| StorageOS            | &#x2713;       | -            | -            |
+
+<!--
+### Class
+
+A PV can have a class, which is specified by setting the
+`storageClassName` attribute to the name of a
+[StorageClass](/docs/concepts/storage/storage-classes/).
+A PV of a particular class can only be bound to PVCs requesting
+that class. A PV with no `storageClassName` has no class and can only be bound
+to PVCs that request no particular class.
+-->
+### 类    {#class}
+
+每个 PV 可以属于某个类（Class），通过将其 `storageClassName` 属性设置为某个
+[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来指定。
+特定类的 PV 卷只能绑定到请求该类存储卷的 PVC 申领。
+未设置 `storageClassName` 的 PV 卷没有类设定，只能绑定到那些没有指定特定
+存储类的 PVC 申领。
+
+<!--
+In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead
+of the `storageClassName` attribute. This annotation is still working; however,
+it will become fully deprecated in a future Kubernetes release.
+-->
+早前，Kubernetes 使用注解 `volume.beta.kubernetes.io/storage-class` 而不是
+`storageClassName` 属性。这一注解目前仍然起作用，不过在将来的 Kubernetes
+发布版本中该注解会被彻底废弃。
+
+
+<!--
+### Reclaim Policy
+
+Current reclaim policies are:
+
+* Retain -- manual reclamation
+* Recycle -- basic scrub (`rm -rf /thevolume/*`)
+* Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted
+
+Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, and Cinder volumes support deletion.
+-->
+### 回收策略   {#reclaim-policy}
+
+目前的回收策略有：
+
+* Retain -- 手动回收
+* Recycle -- 基本擦除   (`rm -rf /thevolume/*`)
+* Delete -- 诸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷这类关联存储资产也被删除
+
+目前，仅 NFS 和 HostPath 支持回收（Recycle）。
+AWS EBS、GCE PD、Azure Disk 和 Cinder 卷都支持删除（Delete）。
+
+<!--
+### Mount Options
+
+A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node.
+-->
+### 挂载选项    {#mount-options}
+
+Kubernetes 管理员可以指定持久卷被挂载到节点上时使用的附加挂载选项。
+
+<!--
+Not all Persistent Volume types support mount options.
+-->
+{{< note >}}
+并非所有持久卷类型都支持挂载选项。
+{{< /note >}}
+
+<!--
+The following volume types support mount options:
+-->
+以下卷类型支持挂载选项：
+
+* AWSElasticBlockStore
+* AzureDisk
+* AzureFile
+* CephFS
+* Cinder （OpenStack 块存储）
+* GCEPersistentDisk
+* Glusterfs
+* NFS
+* Quobyte 卷
+* RBD （Ceph 块设备）
+* StorageOS
+* VsphereVolume
+* iSCSI
+
+<!--
+Mount options are not validated, so mount will simply fail if one is invalid.
+-->
+Kubernetes 不对挂载选项执行合法性检查，因此非法的挂载选项只是会导致挂载失败。
+
+<!--
+In the past, the annotation `volume.beta.kubernetes.io/mount-options` was used instead
+of the `mountOptions` attribute. This annotation is still working; however,
+it will become fully deprecated in a future Kubernetes release.
+-->
+早前，Kubernetes 使用注解 `volume.beta.kubernetes.io/mount-options` 而不是
+`mountOptions` 属性。这一注解目前仍然起作用，不过在将来的 Kubernetes
+发布版本中该注解会被彻底废弃。
+
+<!--
+### Node Affinity
+-->
+### 节点亲和性   {#node-affinity}
+
+<!--
+A PV can specify [node affinity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) to define constraints that limit what nodes this volume can be accessed from. Pods that use a PV will only be scheduled to nodes that are selected by the node affinity.
+-->
+每个 PV 卷可以通过设置
+[节点亲和性](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)
+来定义一些约束，进而限制从哪些节点上可以访问此卷。
+使用这些卷的 Pod 只会被调度到节点亲和性规则所选择的节点上执行。
+
+<!--
+For most volume types, you do not need to set this field. It is automatically populated for [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) and [Azure Disk](/docs/concepts/storage/volumes/#azuredisk) volume block types. You need to explicitly set this for [local](/docs/concepts/storage/volumes/#local) volumes.
+-->
+{{< note >}}
+对大多数类型的卷而言，你不需要设置节点亲和性字段。
+[AWS EBS](/zh/docs/concepts/storage/volumes/#awselasticblockstore)、
+[GCE PD](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) 和
+[Azure Disk](/zh/docs/concepts/storage/volumes/#azuredisk) 卷类型都能
+自动设置相关字段。
+你需要为 [local](/zh/docs/concepts/storage/volumes/#local) 卷显式地设置
+此属性。
+{{< /note >}}
+
+<!--
+### Phase
+
+A volume will be in one of the following phases:
+
+* Available -- a free resource that is not yet bound to a claim
+* Bound -- the volume is bound to a claim
+* Released -- the claim has been deleted, but the resource is not yet reclaimed by the cluster
+* Failed -- the volume has failed its automatic reclamation
+
+The CLI will show the name of the PVC bound to the PV.
+-->
+### 阶段   {#phase}
+
+每个卷会处于以下阶段（Phase）之一：
+
+* Available（可用）-- 卷是一个空闲资源，尚未绑定到任何申领；
+* Bound（已绑定）-- 该卷已经绑定到某申领；
+* Released（已释放）-- 所绑定的申领已被删除，但是资源尚未被集群回收；
+* Failed（失败）-- 卷的自动回收操作失败。
+
+命令行接口能够显示绑定到某 PV 卷的 PVC 对象。
+
+## PersistentVolumeClaims
+
+<!--
+Each PVC contains a spec and status, which is the specification and status of the claim.
+The name of a PersistentVolumeClaim object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+每个 PVC 对象都有 `spec` 和 `status` 部分，分别对应申领的规约和状态。
+PersistentVolumeClaim 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: myclaim
+spec:
+  accessModes:
+    - ReadWriteOnce
+  volumeMode: Filesystem
+  resources:
+    requests:
+      storage: 8Gi
+  storageClassName: slow
+  selector:
+    matchLabels:
+      release: "stable"
+    matchExpressions:
+      - {key: environment, operator: In, values: [dev]}
+```
+
+<!--
+### Access Modes
+
+Claims use the same conventions as volumes when requesting storage with specific access modes.
+-->
+### 访问模式   {#access-modes}
+
+申领在请求具有特定访问模式的存储时，使用与卷相同的访问模式约定。
+
+<!--
+### Volume Modes
+
+Claims use the same convention as volumes to indicate the consumption of the volume as either a filesystem or block device.
+-->
+### 卷模式   {#volume-modes}
+
+申领使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用。
+
+<!--
+### Resources
+
+Claims, like Pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) applies to both volumes and claims.
+-->
+### 资源    {#resources}
+
+申领和 Pod 一样，也可以请求特定数量的资源。在这个上下文中，请求的资源是存储。
+卷和申领都使用相同的
+[资源模型](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)。
+
+<!--
+### Selector
+
+Claims can specify a [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) to further filter the set of volumes. Only the volumes whose labels match the selector can be bound to the claim. The selector can consist of two fields:
+-->
+### 选择算符    {#selector}
+
+申领可以设置[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+来进一步过滤卷集合。只有标签与选择算符相匹配的卷能够绑定到申领上。
+选择算符包含两个字段：
+
+<!--
+* `matchLabels` - the volume must have a label with this value
+* `matchExpressions` - a list of requirements made by specifying key, list of values, and operator that relates the key and values. Valid operators include In, NotIn, Exists, and DoesNotExist.
+
+All of the requirements, from both `matchLabels` and `matchExpressions`, are ANDed together – they must all be satisfied in order to match.
+-->
+* `matchLabels` - 卷必须包含带有此值的标签
+* `matchExpressions` - 通过设定键（key）、值列表和操作符（operator）
+  来构造的需求。合法的操作符有 In、NotIn、Exists 和 DoesNotExist。
+
+来自 `matchLabels` 和 `matchExpressions` 的所有需求都按逻辑与的方式组合在一起。
+这些需求都必须被满足才被视为匹配。
+
+<!--
+### Class
+
+A claim can request a particular class by specifying the name of a
+[StorageClass](/docs/concepts/storage/storage-classes/)
+using the attribute `storageClassName`.
+Only PVs of the requested class, ones with the same `storageClassName` as the PVC, can
+be bound to the PVC.
+-->
+### 类      {#class}
+
+申领可以通过为 `storageClassName` 属性设置
+[StorageClass](/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。
+只有所请求的类的 PV 卷，即 `storageClassName` 值与 PVC 设置相同的 PV 卷，
+才能绑定到 PVC 申领。
+
+<!--
+PVCs don't necessarily have to request a class. A PVC with its `storageClassName` set
+equal to `""` is always interpreted to be requesting a PV with no class, so it
+can only be bound to PVs with no class (no annotation or one set equal to
+`""`). A PVC with no `storageClassName` is not quite the same and is treated differently
+by the cluster, depending on whether the
+[`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
+is turned on.
+-->
+PVC 申领不必一定要请求某个类。如果 PVC 的 `storageClassName` 属性值设置为 `""`，
+则被视为要请求的是没有设置存储类的 PV 卷，因此这一 PVC 申领只能绑定到未设置
+存储类的 PV 卷（未设置注解或者注解值为 `""` 的 PersistentVolume（PV）对象在系统中不会被删除，因为这样做可能会引起数据丢失。
+未设置 `storageClassName` 的 PVC 与此大不相同，也会被集群作不同处理。
+具体筛查方式取决于
+[`DefaultStorageClass` 准入控制器插件](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
+是否被启用。
+
+<!--
+* If the admission plugin is turned on, the administrator may specify a
+  default StorageClass. All PVCs that have no `storageClassName` can be bound only to
+  PVs of that default. Specifying a default StorageClass is done by setting the
+  annotation `storageclass.kubernetes.io/is-default-class` equal to `true` in
+  a StorageClass object. If the administrator does not specify a default, the
+  cluster responds to PVC creation as if the admission plugin were turned off. If
+  more than one default is specified, the admission plugin forbids the creation of
+  all PVCs.
+* If the admission plugin is turned off, there is no notion of a default
+  StorageClass. All PVCs that have no `storageClassName` can be bound only to PVs that
+  have no class. In this case, the PVCs that have no `storageClassName` are treated the
+  same way as PVCs that have their `storageClassName` set to `""`.
+-->
+* 如果准入控制器插件被启用，则管理员可以设置一个默认的 StorageClass。
+  所有未设置 `storageClassName` 的 PVC 都只能绑定到隶属于默认存储类的 PV 卷。
+  设置默认 StorageClass 的工作是通过将对应 StorageClass 对象的注解
+  `storageclass.kubernetes.io/is-default-class` 赋值为 `true` 来完成的。
+  如果管理员未设置默认存储类，集群对 PVC 创建的处理方式与未启用准入控制器插件
+  时相同。如果设定的默认存储类不止一个，准入控制插件会禁止所有创建 PVC 操作。
+* 如果准入控制器插件被关闭，则不存在默认 StorageClass 的说法。
+  所有未设置 `storageClassName` 的 PVC 都只能绑定到未设置存储类的 PV 卷。
+  在这种情况下，未设置 `storageClassName` 的 PVC 与 `storageClassName` 设置未
+  `""` 的 PVC 的处理方式相同。
+
+<!--
+Depending on installation method, a default StorageClass may be deployed
+to a Kubernetes cluster by addon manager during installation.
+
+When a PVC specifies a `selector` in addition to requesting a StorageClass,
+the requirements are ANDed together: only a PV of the requested class and with
+the requested labels may be bound to the PVC.
+-->
+取决于安装方法，默认的 StorageClass 可能在集群安装期间由插件管理器（Addon
+Manager）部署到集群中。
+
+当某 PVC 除了请求 StorageClass 之外还设置了 `selector`，则这两种需求会按
+逻辑与关系处理：只有隶属于所请求类且带有所请求标签的 PV 才能绑定到 PVC。
+
+<!--
+Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it.
+-->
+{{< note >}}
+目前，设置了非空 `selector` 的 PVC 对象无法让集群为其动态供应 PV 卷。
+{{< /note >}}
+
+<!--
+In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead
+of `storageClassName` attribute. This annotation is still working; however,
+it won't be supported in a future Kubernetes release.
+-->
+早前，Kubernetes 使用注解 `volume.beta.kubernetes.io/storage-class` 而不是
+`storageClassName` 属性。这一注解目前仍然起作用，不过在将来的 Kubernetes
+发布版本中该注解会被彻底废弃。
+
+<!--
+## Claims As Volumes
+
+Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the Pod using the claim. The cluster finds the claim in the Pod's namespace and uses it to get the PersistentVolume backing the claim. The volume is then mounted to the host and into the Pod.
+-->
+## 使用申领作为卷     {#claims-as-volumes}
+
+Pod 将申领作为卷来使用，并藉此访问存储资源。
+申领必须位于使用它的 Pod 所在的同一名字空间内。
+集群在 Pod 的名字空间中查找申领，并使用它来获得申领所使用的 PV 卷。
+之后，卷会被挂载到宿主上并挂载到 Pod 中。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+    - name: myfrontend
+      image: nginx
+      volumeMounts:
+      - mountPath: "/var/www/html"
+        name: mypd
+  volumes:
+    - name: mypd
+      persistentVolumeClaim:
+        claimName: myclaim
+```
+
+<!--
+### A Note on Namespaces
+
+PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
+-->
+### 关于名字空间的说明    {#a-note-on-namespaces}
+
+PersistentVolume 卷的绑定是排他性的。
+由于 PersistentVolumeClaim 是名字空间作用域的对象，使用
+"Many" 模式（`ROX`、`RWX`）来挂载申领的操作只能在同一名字空间内进行。
+
+<!--
+## Raw Block Volume Support
+-->
+## 原始块卷支持   {#raw-block-volume-support}
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+<!--
+The following volume plugins support raw block volumes, including dynamic provisioning where
+applicable:
+-->
+以下卷插件支持原始块卷，包括其动态供应（如果支持的话）的卷：
+
+* AWSElasticBlockStore
+* AzureDisk
+* CSI
+* FC （光纤通道）
+* GCEPersistentDisk
+* iSCSI
+* Local 卷
+* OpenStack Cinder
+* RBD （Ceph 块设备）
+* VsphereVolume
+
+<!--
+### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume}
+-->
+### 使用原始块卷的持久卷      {#persistent-volume-using-a-raw-block-volume}
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: block-pv
+spec:
+  capacity:
+    storage: 10Gi
+  accessModes:
+    - ReadWriteOnce
+  volumeMode: Block
+  persistentVolumeReclaimPolicy: Retain
+  fc:
+    targetWWNs: ["50060e801049cfd1"]
+    lun: 0
+    readOnly: false
+```
+
+<!--
+### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume}
+-->
+### 申请原始块卷的 PVC 申领      {#persistent-volume-claim-requesting-a-raw-block-volume}
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: block-pvc
+spec:
+  accessModes:
+    - ReadWriteOnce
+  volumeMode: Block
+  resources:
+    requests:
+      storage: 10Gi
+```
+
+<!--
+### Pod specification adding Raw Block Device path in container
+-->
+### 在容器中添加原始块设备路径的 Pod 规约
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: pod-with-block-volume
+spec:
+  containers:
+    - name: fc-container
+      image: fedora:26
+      command: ["/bin/sh", "-c"]
+      args: [ "tail -f /dev/null" ]
+      volumeDevices:
+        - name: data
+          devicePath: /dev/xvda
+  volumes:
+    - name: data
+      persistentVolumeClaim:
+        claimName: block-pvc
+```
+
+<!--
+When adding a raw block device for a Pod, you specify the device path in the container instead of a mount path.
+-->
+{{< note >}}
+向 Pod 中添加原始块设备时，你要在容器内设置设备路径而不是挂载路径。
+{{< /note >}}
+
+<!--
+### Binding Block Volumes
+
+If a user requests a raw block volume by indicating this using the `volumeMode` field in the PersistentVolumeClaim spec, the binding rules differ slightly from previous releases that didn't consider this mode as part of the spec.
+Listed is a table of possible combinations the user and admin might specify for requesting a raw block device. The table indicates if the volume will be bound or not given the combinations:
+Volume binding matrix for statically provisioned volumes:
+-->
+### 绑定块卷     {#binding-block-volumes}
+
+如果用户通过 PersistentVolumeClaim 规约的 `volumeMode` 字段来表明对原始
+块设备的请求，绑定规则与之前版本中未在规约中考虑此模式的实现略有不同。
+下面列举的表格是用户和管理员可以为请求原始块设备所作设置的组合。
+此表格表明在不同的组合下卷是否会被绑定。
+
+静态供应卷的卷绑定矩阵：
+
+<!--
+| PV volumeMode | PVC volumeMode  | Result           |
+| --------------|:---------------:| ----------------:|
+|   unspecified | unspecified     | BIND             |
+|   unspecified | Block           | NO BIND          |
+|   unspecified | Filesystem      | BIND             |
+|   Block       | unspecified     | NO BIND          |
+|   Block       | Block           | BIND             |
+|   Block       | Filesystem      | NO BIND          |
+|   Filesystem  | Filesystem      | BIND             |
+|   Filesystem  | Block           | NO BIND          |
+|   Filesystem  | unspecified     | BIND             |
+-->
+| PV volumeMode | PVC volumeMode  | Result           |
+| --------------|:---------------:| ----------------:|
+|   未指定      | 未指定          | 绑定             |
+|   未指定      | Block           | 不绑定           |
+|   未指定      | Filesystem      | 绑定             |
+|   Block       | 未指定          | 不绑定           |
+|   Block       | Block           | 绑定             |
+|   Block       | Filesystem      | 不绑定           |
+|   Filesystem  | Filesystem      | 绑定             |
+|   Filesystem  | Block           | 不绑定           |
+|   Filesystem  | 未指定          | 绑定             |
+
+<!--
+Only statically provisioned volumes are supported for alpha release. Administrators should take care to consider these values when working with raw block devices.
+-->
+{{< note >}}
+Alpha 发行版本中仅支持静态供应的卷。
+管理员需要在处理原始块设备时小心处理这些值。
+{{< /note >}}
+
+<!--
+## Volume Snapshot and Restore Volume from Snapshot Support
+-->
+## 对卷快照及从卷快照中恢复卷的支持
+
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+
+<!--
+Volume snapshot feature was added to support CSI Volume Plugins only. For details, see [volume snapshots](/docs/concepts/storage/volume-snapshots/).
+
+To enable support for restoring a volume from a volume snapshot data source, enable the
+`VolumeSnapshotDataSource` feature gate on the apiserver and controller-manager.
+-->
+卷快照（Volume Snapshot）功能的添加仅是为了支持 CSI 卷插件。
+有关细节可参阅[卷快照](/zh/docs/concepts/storage/volume-snapshots/)文档。
+
+要启用从卷快照数据源恢复数据卷的支持，可在 API 服务器和控制器管理器上启用
+`VolumeSnapshotDataSource` 特性门控。
+
+<!--
+### Create a PersistentVolumeClaim from a Volume Snapshot {#create-persistent-volume-claim-from-volume-snapshot}
+-->
+### 基于卷快照创建 PVC 申领     {#create-persistent-volume-claim-from-volume-snapshot}
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: restore-pvc
+spec:
+  storageClassName: csi-hostpath-sc
+  dataSource:
+    name: new-snapshot-test
+    kind: VolumeSnapshot
+    apiGroup: snapshot.storage.k8s.io
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+```
+
+<!--
+## Volume Cloning
+
+[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins.
+-->
+## 卷克隆     {#volume-cloning}
+
+[卷克隆](/zh/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于
+CSI 卷插件。
+
+<!--
+### Create PersistentVolumeClaim from an existing PVC {#create-persistent-volume-claim-from-an-existing-pvc}
+-->
+### 基于现有 PVC 创建新的 PVC 申领    {#create-persistent-volume-claim-from-an-existing-pvc}
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: cloned-pvc
+spec:
+  storageClassName: my-csi-plugin
+  dataSource:
+    name: existing-src-pvc-name
+    kind: PersistentVolumeClaim
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+```
+
+<!--
+## Writing Portable Configuration
+
+If you're writing configuration templates or examples that run on a wide range of clusters
+and need persistent storage, it is recommended that you use the following pattern:
+-->
+## 编写可移植的配置   {#writing-portable-configuration}
+
+如果你要编写配置模板和示例用来在很多集群上运行并且需要持久性存储，建议你使用以下模式：
+
+<!--
+- Include PersistentVolumeClaim objects in your bundle of config (alongside
+  Deployments, ConfigMaps, etc).
+- Do not include PersistentVolume objects in the config, since the user instantiating
+  the config may not have permission to create PersistentVolumes.
+-->
+- 将 PersistentVolumeClaim 对象包含到你的配置包（Bundle）中，和 Deployment
+  以及 ConfigMap 等放在一起。
+- 不要在配置中包含 PersistentVolume 对象，因为对配置进行实例化的用户很可能
+  没有创建 PersistentVolume 的权限。
+<!--
+- Give the user the option of providing a storage class name when instantiating
+  the template.
+  - If the user provides a storage class name, put that value into the
+    `persistentVolumeClaim.storageClassName` field.
+    This will cause the PVC to match the right storage
+    class if the cluster has StorageClasses enabled by the admin.
+  - If the user does not provide a storage class name, leave the
+    `persistentVolumeClaim.storageClassName` field as nil. This will cause a
+    PV to be automatically provisioned for the user with the default StorageClass
+    in the cluster. Many cluster environments have a default StorageClass installed,
+    or administrators can create their own default StorageClass.
+-->
+- 为用户提供在实例化模板时指定存储类名称的能力。
+  - 仍按用户提供存储类名称，将该名称放到 `persistentVolumeClaim.storageClassName` 字段中。
+    这样会使得 PVC 在集群被管理员启用了存储类支持时能够匹配到正确的存储类，
+  - 如果用户未指定存储类名称，将 `persistentVolumeClaim.storageClassName` 留空（nil）。
+    这样，集群会使用默认 `StorageClass` 为用户自动供应一个存储卷。
+    很多集群环境都配置了默认的 `StorageClass`，或者管理员也可以自行创建默认的
+    `StorageClass`。
+<!--
+- In your tooling, watch for PVCs that are not getting bound after some time
+  and surface this to the user, as this may indicate that the cluster has no
+  dynamic storage support (in which case the user should create a matching PV)
+  or the cluster has no storage system (in which case the user cannot deploy
+  config requiring PVCs).
+-->
+- 在你的工具链中，监测经过一段时间后仍未被绑定的 PVC 对象，要让用户知道这些对象，
+  因为这可能意味着集群没有动态存储支持（因而用户必须先创建一个匹配的 PV），或者
+  集群没有配置存储系统（因而用户无法配置需要 PVC 的工作负载配置）。 
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
+* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
+* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
+-->
+* 进一步了解[创建持久卷](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
+* 进一步学习[创建 PVC 申领](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
+* 阅读[持久存储的设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
+
+<!--
+### Reference
+
+* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
+* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
+* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
+* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
+-->
+### 参考    {#reference}
+
+* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
+* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
+* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
+* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
+
diff --git a/content/zh/docs/concepts/storage/storage-capacity.md b/content/zh/docs/concepts/storage/storage-capacity.md
new file mode 100644
index 0000000000..24c86537b8
--- /dev/null
+++ b/content/zh/docs/concepts/storage/storage-capacity.md
@@ -0,0 +1,223 @@
+---
+title: 存储容量
+content_type: concept
+weight: 45
+---
+
+<!-- overview -->
+<!--
+Storage capacity is limited and may vary depending on the node on
+which a pod runs: network-attached storage might not be accessible by
+all nodes, or storage is local to a node to begin with.
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+This page describes how Kubernetes keeps track of storage capacity and
+how the scheduler uses that information to schedule Pods onto nodes
+that have access to enough storage capacity for the remaining missing
+volumes. Without storage capacity tracking, the scheduler may choose a
+node that doesn't have enough capacity to provision a volume and
+multiple scheduling retries will be needed.
+
+Tracking storage capacity is supported for {{< glossary_tooltip
+text="Container Storage Interface" term_id="csi" >}} (CSI) drivers and
+[needs to be enabled](#enabling-storage-capacity-tracking) when installing a CSI driver.
+-->
+存储容量是有限的，并且会因为运行 pod 的节点不同而变化：网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 Pod 调度到能够访问到足够存储容量的节点上。
+如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。
+
+{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}（CSI）驱动程序支持跟踪存储容量，
+并且在安装 CSI 驱动程序时[需要启用](#enabling-storage-capacity-tracking)该功能。
+
+<!-- body -->
+<!--
+## API
+
+There are two API extensions for this feature:
+- [CSIStorageCapacity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csistoragecapacity-v1alpha1-storage-k8s-io) objects:
+  these get produced by a CSI driver in the namespace
+  where the driver is installed. Each object contains capacity
+  information for one storage class and defines which nodes have
+  access to that storage.
+- [The `CSIDriverSpec.StorageCapacity` field](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
+  when set to `true`, the Kubernetes scheduler will consider storage
+  capacity for volumes that use the CSI driver.
+-->
+## API
+
+这个特性有两个 API 扩展接口：
+- [CSIStorageCapacity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csistoragecapacity-v1alpha1-storage-k8s-io) 
+对象：这些对象由 CSI 驱动程序在安装驱动程序的命名空间中产生。每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。
+- [`CSIDriverSpec.StorageCapacity` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io)：
+设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。
+
+<!--
+## Scheduling
+
+Storage capacity information is used by the Kubernetes scheduler if:
+- the `CSIStorageCapacity` feature gate is true,
+- a Pod uses a volume that has not been created yet,
+- that volume uses a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} which references a CSI driver and
+  uses `WaitForFirstConsumer` [volume binding
+  mode](/docs/concepts/storage/storage-classes/#volume-binding-mode),
+  and
+- the `CSIDriver` object for the driver has `StorageCapacity` set to
+  true.
+
+In that case, the scheduler only considers nodes for the Pod which
+have enough storage available to them. This check is very
+simplistic and only compares the size of the volume against the
+capacity listed in `CSIStorageCapacity` objects with a topology that
+includes the node.
+
+For volumes with `Immediate` volume binding mode, the storage driver
+decides where to create the volume, independently of Pods that will
+use the volume. The scheduler then schedules Pods onto nodes where the
+volume is available after the volume has been created.
+
+For [CSI ephemeral volumes](/docs/concepts/storage/volumes/#csi),
+scheduling always happens without considering storage capacity. This
+is based on the assumption that this volume type is only used by
+special CSI drivers which are local to a node and do not need
+significant resources there.
+-->
+## 调度
+
+如果有以下情况，存储容量信息将会被 Kubernetes 调度程序使用：
+- `CSIStorageCapacity` 特性门控被设置为 true，
+- Pod 使用的卷还没有被创建，
+- 卷使用引用了 CSI 驱动的 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}，
+并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)，
+- 驱动程序的 `CSIDriver` 对象的 `StorageCapacity` 被设置为 true。
+
+在这种情况下，调度程序仅考虑将 Pod 调度到有足够存储容量的节点上。这个检测非常简单，
+仅将卷的大小与 `CSIStorageCapacity` 对象中列出的容量进行比较，并使用包含该节点的拓扑。
+
+对于具有 `Immediate` 卷绑定模式的卷，存储驱动程序将决定在何处创建该卷，而不取决于将使用该卷的 Pod。
+然后，调度程序将 Pod 调度到创建卷后可使用该卷的节点上。
+
+对于 [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi)，调度总是在不考虑存储容量的情况下进行。
+这是基于这样的假设：该卷类型仅由节点本地的特殊 CSI 驱动程序使用，并且不需要大量资源。
+
+<!--
+## Rescheduling
+
+When a node has been selected for a Pod with `WaitForFirstConsumer`
+volumes, that decision is still tentative. The next step is that the
+CSI storage driver gets asked to create the volume with a hint that the
+volume is supposed to be available on the selected node.
+
+Because Kubernetes might have chosen a node based on out-dated
+capacity information, it is possible that the volume cannot really be
+created. The node selection is then reset and the Kubernetes scheduler
+tries again to find a node for the Pod.
+-->
+## 重新调度
+
+当为带有 `WaitForFirstConsumer` 的卷的 Pod 来选择节点时，该决定仍然是暂定的。
+下一步是要求 CSI 存储驱动程序创建卷，并提示该卷在被选择的节点上可用。
+
+因为 Kubernetes 可能会根据已经过时的存储容量信息来选择一个节点，因此可能无法真正创建卷。
+然后就会重置节点选择，Kubernetes 调度器会再次尝试为 Pod 查找节点。
+
+<!--
+## Limitations
+
+Storage capacity tracking increases the chance that scheduling works
+on the first try, but cannot guarantee this because the scheduler has
+to decide based on potentially out-dated information. Usually, the
+same retry mechanism as for scheduling without any storage capacity
+information handles scheduling failures.
+
+One situation where scheduling can fail permanently is when a Pod uses
+multiple volumes: one volume might have been created already in a
+topology segment which then does not have enough capacity left for
+another volume. Manual intervention is necessary to recover from this,
+for example by increasing capacity or deleting the volume that was
+already created. [Further
+work](https://github.com/kubernetes/enhancements/pull/1703) is needed
+to handle this automatically.
+-->
+## 限制
+
+存储容量跟踪增加了调度器第一次尝试即成功的机会，但是并不能保证这一点，因为调度器必须根据可能过期的信息来进行决策。
+通常，与没有任何存储容量信息的调度相同的重试机制可以处理调度失败。
+
+当 Pod 使用多个卷时，调度可能会永久失败：一个卷可能已经在拓扑段中创建，而该卷又没有足够的容量来创建另一个卷，
+要想从中恢复，必须要进行手动干预，比如通过增加存储容量或者删除已经创建的卷。
+需要[进一步工作](https://github.com/kubernetes/enhancements/pull/1703)来自动处理此问题。
+
+<!--
+## Enabling storage capacity tracking
+
+Storage capacity tracking is an *alpha feature* and only enabled when
+the `CSIStorageCapacity` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/) and
+the `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}} are enabled. For details on
+that, see the `--feature-gates` and `--runtime-config` [kube-apiserver
+parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
+-->
+## 开启存储容量跟踪
+
+存储容量跟踪是一个 *alpha 特性*，只有当 `CSIStorageCapacity` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)
+和 `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API 组" term_id="api-group" >}}启用时才能启用。
+更多详细信息，可以查看`--feature-gates` 和 `--runtime-config` [kube-apiserver 参数](/docs/reference/command-line-tools-reference/kube-apiserver/)。
+
+<!--
+A quick check
+whether a Kubernetes cluster supports the feature is to list
+CSIStorageCapacity objects with:
+```shell
+kubectl get csistoragecapacities --all-namespaces
+```
+
+If your cluster supports CSIStorageCapacity, the response is either a list of CSIStorageCapacity objects or:
+```
+No resources found
+```
+-->
+快速检查 Kubernetes 集群是否支持这个特性，可以通过下面命令列出 CSIStorageCapacity 对象：
+
+```shell
+kubectl get csistoragecapacities --all-namespaces
+```
+
+如果集群支持 CSIStorageCapacity，就会返回 CSIStorageCapacity 的对象列表或者：
+```
+No resources found
+```
+
+<!--
+If not supported, this error is printed instead:
+```
+error: the server doesn't have a resource type "csistoragecapacities"
+```
+
+In addition to enabling the feature in the cluster, a CSI
+driver also has to
+support it. Please refer to the driver's documentation for
+details.
+-->
+如果不支持，下面这个错误就会被打印出来：
+```
+error: the server doesn't have a resource type "csistoragecapacities"
+```
+
+除了在集群中启用该功能外，CSI 驱动程序还必须支持它。有关详细信息，请参阅驱动程序的文档。
+
+
+## {{% heading "whatsnext" %}}
+
+<!--
+ - For more information on the design, see the
+[Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md).
+- For more information on further development of this feature, see the [enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472).
+- Learn about [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
+-->
+- 想要获得更多该设计的信息，查看 [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。
+- 有关此功能的进一步开发信息，查看[enhancement tracking issue #1472](https://github.com/kubernetes/enhancements/issues/1472)。
+- 学习 [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)。
\ No newline at end of file
diff --git a/content/zh/docs/concepts/storage/storage-classes.md b/content/zh/docs/concepts/storage/storage-classes.md
index 91761b546e..0edc83cd0b 100644
--- a/content/zh/docs/concepts/storage/storage-classes.md
+++ b/content/zh/docs/concepts/storage/storage-classes.md
@@ -18,7 +18,7 @@ with [volumes](/docs/concepts/storage/volumes/) and
 [persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
 -->
 本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
-[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
+[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
 
 <!-- body -->
 
@@ -67,7 +67,7 @@ for details.
  -->
 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
 更多详情请参阅
-[PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
+[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
 
 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -90,15 +90,16 @@ volumeBindingMode: Immediate
 Each StorageClass has a provisioner that determines what volume plugin is used
 for provisioning PVs. This field must be specified.
  -->
-### 存储分配器
+### 存储制备器  {#provisioner}
 
-每个 StorageClass 都有一个分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。
+每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。
+该字段必须指定。
 
 <!--
 | Volume Plugin        | Internal Provisioner| Config Example                       |
 -->
 
-| 卷插件               | 内置分配器 |               配置例子                |
+| 卷插件               | 内置制备器 |               配置例子                |
 |:---------------------|:----------:|:-------------------------------------:|
 | AWSElasticBlockStore |  &#x2713;  |          [AWS EBS](#aws-ebs)          |
 | AzureFile            |  &#x2713;  |       [Azure File](#azure-file)       |
@@ -131,24 +132,25 @@ run, what volume plugin it uses (including Flex), etc. The repository
 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 houses a library for writing external provisioners that implements the bulk of
 the specification. Some external provisioners are listed under the repository
-[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).
  -->
-您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
-您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的
+你不限于指定此处列出的 "内置" 制备器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
+你还可以运行和指定外部制备器，这些独立的程序遵循由 Kubernetes 定义的
 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。
 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。
 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
-包含一个用于为外部分配器编写功能实现的类库。可以通过下面的代码仓库，查看外部分配器列表。
+包含一个用于为外部制备器编写功能实现的类库。你可以访问代码仓库
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
+了解外部驱动列表。
 
-[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
 
 <!--
 For example, NFS doesn't provide an internal provisioner, but an external
 provisioner can be used. There are also cases when 3rd party storage
 vendors provide their own external provisioner.
  -->
-例如，NFS 没有内部分配器，但可以使用外部分配器。
-也有第三方存储供应商提供自己的外部分配器。
+例如，NFS 没有内部制备器，但可以使用外部制备器。
+也有第三方存储供应商提供自己的外部制备器。
 
 <!--
 ### Reclaim Policy
@@ -228,7 +230,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
 
 由 StorageClass 动态创建的 PersistentVolume 将使用类中 `mountOptions` 字段指定的挂载选项。
 
-如果卷插件不支持挂载选项，却指定了该选项，则分配操作会失败。
+如果卷插件不支持挂载选项，却指定了该选项，则制备操作会失败。
 挂载选项在 StorageClass 和 PV 上都不会做验证，所以如果挂载选项无效，那么这个 PV 就会失败。
 
 <!--
@@ -240,7 +242,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
 The `volumeBindingMode` field controls when [volume binding and dynamic
 provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
  -->
-`volumeBindingMode` 字段控制了[卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
+`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
 应该发生在什么时候。
 
 <!--
@@ -250,8 +252,9 @@ backends that are topology-constrained and not globally accessible from all Node
 in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling
 requirements. This may result in unschedulable Pods.
  -->
-默认情况下，`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态分配。
-对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者分配。
+默认情况下，`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。
+对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume
+会在不知道 Pod 调度要求的情况下绑定或者制备。
 
 <!--
 A cluster administrator can address this issue by specifying the `WaitForFirstConsumer` mode which
@@ -265,8 +268,8 @@ anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-a
 and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration).
 -->
 集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。
-该模式将延迟 PersistentVolume 的绑定和分配，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
-PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于
+该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
+PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。这些包括但不限于
 [资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、
 [节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、
 [pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、
@@ -279,7 +282,7 @@ The following plugins support `WaitForFirstConsumer` with dynamic provisioning:
 * [GCEPersistentDisk](#gce-pd)
 * [AzureDisk](#azure-disk)
 -->
-以下插件支持动态分配的 `WaitForFirstConsumer` 模式:
+以下插件支持动态供应的 `WaitForFirstConsumer` 模式:
 
 * [AWSElasticBlockStore](#aws-ebs)
 * [GCEPersistentDisk](#gce-pd)
@@ -304,7 +307,7 @@ and pre-created PVs, but you'll need to look at the documentation for a specific
 to see its supported topology keys and examples.
 -->
 动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)，
-但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
+但是你需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
 
 <!--
 ### Allowed Topologies
@@ -317,7 +320,8 @@ When a cluster operator specifies the `WaitForFirstConsumer` volume binding mode
 to restrict provisioning to specific topologies in most situations. However,
 if still required, `allowedTopologies` can be specified.
 -->
-当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式，在大部分情况下就没有必要将配置限制为特定的拓扑结构。
+当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式，
+在大部分情况下就没有必要将制备限制为特定的拓扑结构。
 然而，如果还有需要的话，可以使用 `allowedTopologies`。
 
 <!--
@@ -325,7 +329,8 @@ This example demonstrates how to restrict the topology of provisioned volumes to
 zones and should be used as a replacement for the `zone` and `zones` parameters for the
 supported plugins.
 -->
-这个例子描述了如何将分配卷的拓扑限制在特定的区域，在使用时应该根据插件支持情况替换 `zone` 和 `zones` 参数。
+这个例子描述了如何将供应卷的拓扑限制在特定的区域，在使用时应该根据插件
+支持情况替换 `zone` 和 `zones` 参数。
 
 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -359,10 +364,12 @@ exceed 256 KiB.
  -->
 ## 参数
 
-Storage class 具有描述属于卷的参数。取决于分配器，可以接受不同的参数。
-例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时，会使用默认值。
+Storage class 具有描述属于卷的参数。取决于制备器，可以接受不同的参数。
+例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。
+当参数被省略时，会使用默认值。
 
-一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能超过 256 KiB, 包括参数的键和值。
+一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能
+超过 256 KiB, 包括参数的键和值。
 
 ### AWS EBS
 
@@ -405,9 +412,11 @@ parameters:
 * `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见
   [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。
 * `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，
-  通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。
+  通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
+  `zone` 和 `zones` 参数不能同时使用。
 * `zones`(弃用)：以逗号分隔的 AWS 区域列表。
-  如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
+  如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的
+  活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
 * `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。
   AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，
   并将其限制在 20000 IOPS（AWS 支持的最高值，请参阅
@@ -465,7 +474,7 @@ parameters:
 <!--
 If `replication-type` is set to `none`, a regular (zonal) PD will be provisioned.
 -->
-如果 `replication-type` 设置为 `none`，会分配一个常规（当前区域内的）持久化磁盘。
+如果 `replication-type` 设置为 `none`，会制备一个常规（当前区域内的）持久化磁盘。
 
 <!--
 If `replication-type` is set to `regional-pd`, a
@@ -477,10 +486,10 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the
 `zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
 managed by the cluster.
 -->
-如果 `replication-type` 设置为 `regional-pd`，会分配一个
+如果 `replication-type` 设置为 `regional-pd`，会制备一个
 [区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。
 在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。
-如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。
+如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里制备。
 如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。
 如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。
 
@@ -530,8 +539,8 @@ parameters:
   for authentication to the REST server. This parameter is deprecated in favor
   of `secretNamespace` + `secretName`.
 -->
-* `resturl`：分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
-  通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态分配器的必需参数。
+* `resturl`：制备 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
+  通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态制备器的必需参数。
   如果 Heketi 服务在 OpenShift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于
   `http://heketi-storage-project.cloudapps.mystorage.com` 的格式，其中 fqdn 是可解析的 heketi 服务网址。
 * `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。
@@ -557,7 +566,8 @@ parameters:
     Example of a secret can be found in
     [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
 -->
-* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster REST 服务交互时使用的用户密码。
+* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster
+  REST 服务交互时使用的用户密码。
   这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。
   所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建：
 
@@ -581,12 +591,13 @@ parameters:
   specified, the volume will be provisioned with a value between 2000-2147483647
   which are defaults for gidMin and gidMax respectively.
 -->
-* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，
+* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当制备卷时，
   Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如：
   `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。
 * `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。
-  在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。
-  如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。
+  在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态制备卷。这些是可选的值。
+  如果不指定，所制备的卷为一个 2000-2147483647 之间的值，这是 gidMin 和
+  gidMax 的默认值。
 
 <!--
 * `volumetype` : The volume type and its parameters can be configured with this
@@ -609,18 +620,22 @@ parameters:
     `gluster-dynamic-<claimname>`. The dynamic endpoint and service are automatically
     deleted when the persistent volume claim is deleted.
 -->
-* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由分配器决定卷的类型。
-   例如：
+* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则
+  由制备器决定卷的类型。
+  例如：
 
-   * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
-   * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
-   * 'Distribute volume': `volumetype: none`
+  * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
+  * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
+  * 'Distribute volume': `volumetype: none`
 
-  有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
+  有关可用的卷类型和管理选项，请参阅
+  [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
 
-  更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
+  更多相关的参考信息，请参阅
+  [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
 
-  当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。
+  当动态制备持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>`
+  的端点和无头服务。在 PVC 被删除时动态端点和无头服务会自动被删除。
 
 ### OpenStack Cinder
 
@@ -638,7 +653,8 @@ parameters:
 * `availability`: Availability Zone. If not specified, volumes are generally
   round-robin-ed across all active zones where Kubernetes cluster has a node.
 -->
-* `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
+* `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点
+  所在的活动区域中轮转调度。
 
 <!--
 {{< note >}}
@@ -648,7 +664,8 @@ This internal provisioner of OpenStack is deprecated. Please use [the external c
  -->
 {{< note >}}
 {{< feature-state state="deprecated" for_k8s_version="1.11" >}}
-OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部驱动程序](https://github.com/kubernetes/cloud-provider-openstack)。
+OpenStack 的内部驱动已经被弃用。请使用
+[OpenStack 的外部云驱动](https://github.com/kubernetes/cloud-provider-openstack)。
 {{< /note >}}
 
 ### vSphere
@@ -658,104 +675,107 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
  -->
 1. 使用用户指定的磁盘格式创建一个 StorageClass。
 
-    ```yaml
-    apiVersion: storage.k8s.io/v1
-    kind: StorageClass
-    metadata:
-      name: fast
-    provisioner: kubernetes.io/vsphere-volume
-    parameters:
-      diskformat: zeroedthick
-    ```
+   ```yaml
+   apiVersion: storage.k8s.io/v1
+   kind: StorageClass
+   metadata:
+     name: fast
+   provisioner: kubernetes.io/vsphere-volume
+   parameters:
+     diskformat: zeroedthick
+   ```
 
-<!--
-    `diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
- -->
-    `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。
+   <!--
+   `diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
+   -->
+   `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。
 
 <!--
 2. Create a StorageClass with a disk format on a user specified datastore.
 -->
 2. 在用户指定的数据存储上创建磁盘格式的 StorageClass。
 
-    ```yaml
-    apiVersion: storage.k8s.io/v1
-    kind: StorageClass
-    metadata:
-      name: fast
-    provisioner: kubernetes.io/vsphere-volume
-    parameters:
-        diskformat: zeroedthick
-        datastore: VSANDatastore
-    ```
+   ```yaml
+   apiVersion: storage.k8s.io/v1
+   kind: StorageClass
+   metadata:
+     name: fast
+   provisioner: kubernetes.io/vsphere-volume
+   parameters:
+       diskformat: zeroedthick
+       datastore: VSANDatastore
+   ```
 
-<!--
-    `datastore`: The user can also specify the datastore in the StorageClass.
-    The volume will be created on the datastore specified in the storage class,
-    which in this case is `VSANDatastore`. This field is optional. If the
-    datastore is not specified, then the volume will be created on the datastore
-    specified in the vSphere config file used to initialize the vSphere Cloud
-    Provider.
--->
-    `datastore`：用户也可以在 StorageClass 中指定数据存储。
-    卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
-    该字段是可选的。
-    如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 
-    配置文件中指定的数据存储上创建该卷。
+   <!--
+   `datastore`: The user can also specify the datastore in the StorageClass.
+   The volume will be created on the datastore specified in the storage class,
+   which in this case is `VSANDatastore`. This field is optional. If the
+   datastore is not specified, then the volume will be created on the datastore
+   specified in the vSphere config file used to initialize the vSphere Cloud
+   Provider.
+   -->
+
+   `datastore`：用户也可以在 StorageClass 中指定数据存储。
+   卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
+   该字段是可选的。
+   如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 
+   配置文件中指定的数据存储上创建该卷。
 
 <!--
 3. Storage Policy Management inside kubernetes
 -->
 3. Kubernetes 中的存储策略管理
 
-<!--
-    * Using existing vCenter SPBM policy
+   <!--
+   * Using existing vCenter SPBM policy
 
-        One of the most important features of vSphere for Storage Management is
-        policy based Management. Storage Policy Based Management (SPBM) is a
-        storage policy framework that provides a single unified control plane
-        across a broad range of data services and storage solutions. SPBM enables
-        vSphere administrators to overcome upfront storage provisioning challenges,
-        such as capacity planning, differentiated service levels and managing
-        capacity headroom.
+     One of the most important features of vSphere for Storage Management is
+     policy based Management. Storage Policy Based Management (SPBM) is a
+     storage policy framework that provides a single unified control plane
+     across a broad range of data services and storage solutions. SPBM enables
+     vSphere administrators to overcome upfront storage provisioning challenges,
+     such as capacity planning, differentiated service levels and managing
+     capacity headroom.
+
+     The SPBM policies can be specified in the StorageClass using the
+     `storagePolicyName` parameter.
+    -->
 
-        The SPBM policies can be specified in the StorageClass using the
-        `storagePolicyName` parameter.
--->
     * 使用现有的 vCenter SPBM 策略
 
-        vSphere 用于存储管理的最重要特性之一是基于策略的管理。
-        基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
-        跨越广泛的数据服务和存储解决方案。
-        SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
+      vSphere 用于存储管理的最重要特性之一是基于策略的管理。
+      基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
+      跨越广泛的数据服务和存储解决方案。
+      SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
 
-        SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。
+      SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。
 
-<!--
+    <!--
     * Virtual SAN policy support inside Kubernetes
 
-        Vsphere Infrastructure (VI) Admins will have the ability to specify custom
-        Virtual SAN Storage Capabilities during dynamic volume provisioning. You
-        can now define storage requirements, such as performance and availability,
-        in the form of storage capabilities during dynamic volume provisioning.
-        The storage capability requirements are converted into a Virtual SAN
-        policy which are then pushed down to the Virtual SAN layer when a
-        persistent volume (virtual disk) is being created. The virtual disk is
-        distributed across the Virtual SAN datastore to meet the requirements.
+      Vsphere Infrastructure (VI) Admins will have the ability to specify custom
+      Virtual SAN Storage Capabilities during dynamic volume provisioning. You
+      can now define storage requirements, such as performance and availability,
+      in the form of storage capabilities during dynamic volume provisioning.
+      The storage capability requirements are converted into a Virtual SAN
+      policy which are then pushed down to the Virtual SAN layer when a
+      persistent volume (virtual disk) is being created. The virtual disk is
+      distributed across the Virtual SAN datastore to meet the requirements.
+
+      You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
+      for more details on how to use storage policies for persistent volumes
+      management.
+    -->
 
-        You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
-        for more details on how to use storage policies for persistent volumes
-        management.
--->
     * Kubernetes 内的 Virtual SAN 策略支持
 
-        Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
-        存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。
-        存储功能需求会转换为 Virtual SAN 策略，然后当持久卷（虚拟磁盘）在创建时，
-        会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
+      Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
+      存储功能。你现在可以在动态制备卷期间以存储能力的形式定义存储需求，例如性能和可用性。
+      存储能力需求会转换为 Virtual SAN 策略，之后当持久卷（虚拟磁盘）被创建时，
+      会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
 
-        更多有关 persistent volume 管理的存储策略的详细信息，
-        您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。
+      你可以参考[基于存储策略的动态制备卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)，
+      进一步了解有关持久卷管理的存储策略的详细信息。
 
 <!--
 There are few
@@ -763,7 +783,7 @@ There are few
 which you try out for persistent volume management inside Kubernetes for vSphere.
 -->
 有几个 [vSphere 例子](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)
-供您在 Kubernetes for vSphere 中尝试进行 persistent volume 管理。
+供你在 Kubernetes for vSphere 中尝试进行持久卷管理。
 
 ### Ceph RBD
 
@@ -878,7 +898,7 @@ parameters:
 * `registry`：用于挂载卷的 Quobyte registry。你可以指定 registry 为 ``<host>:<port>``
   或者如果你想指定多个 registry，你只需要在他们之间添加逗号，例如
   ``<host1>:<port>,<host2>:<port>,<host3>:<port>``。
-  主机可以是一个 IP 地址，或者如果您有正在运行的 DNS，您也可以提供 DNS 名称。
+  主机可以是一个 IP 地址，或者如果你有正在运行的 DNS，你也可以提供 DNS 名称。
 * `adminSecretNamespace`：`adminSecretName`的 namespace。
   默认值是 "default"。
 
@@ -916,7 +936,7 @@ parameters:
 -->
 * `user`：对这个用户映射的所有访问权限。默认是 "root"。
 * `group`：对这个组映射的所有访问权限。默认是 "nfsnobody"。
-* `quobyteConfig`：使用指定的配置来创建卷。您可以创建一个新的配置，或者，可以修改 Web console 或
+* `quobyteConfig`：使用指定的配置来创建卷。你可以创建一个新的配置，或者，可以修改 Web console 或
   quobyte CLI 中现有的配置。默认是 "BASE"。
 * `quobyteTenant`：使用指定的租户 ID 创建/删除卷。这个 Quobyte 租户必须已经于 Quobyte。
   默认是 "DEFAULT"。
@@ -1049,17 +1069,19 @@ mounting credentials. If the cluster has enabled both
 add the `create` permission of resource `secret` for clusterrole
 `system:controller:persistent-volume-binder`.
 -->
-在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
-[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
-为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。
+在存储制备期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
+[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和
+[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
+为 `system:controller:persistent-volume-binder` 的 clusterrole 添加
+`Secret` 资源的 `create` 权限。
 
 <!--
 In a multi-tenancy context, it is strongly recommended to set the value for
 `secretNamespace` explicitly, otherwise the storage account credentials may
 be read by other users.
 -->
-
-在多租户上下文中，强烈建议显式设置 `secretNamespace` 的值，否则其他用户可能会读取存储帐户凭据。
+在多租户上下文中，强烈建议显式设置 `secretNamespace` 的值，否则
+其他用户可能会读取存储帐户凭据。
 
 <!--
 ### Portworx Volume
@@ -1104,14 +1126,19 @@ parameters:
 * `block_size`：以 Kbytes 为单位的块大小（默认值：`32`）。
 * `repl`：同步副本数量，以复制因子 `1..3`（默认值：`1`）的形式提供。
   这里需要填写字符串，即，`"1"` 而不是 `1`。
-* `io_priority`：决定是否从更高性能或者较低优先级存储创建卷 `high/medium/low`（默认值：`low`）。
-* `snap_interval`：触发快照的时钟/时间间隔（分钟）。快照是基于与先前快照的增量变化，0 是禁用快照（默认：`0`）。
+* `io_priority`：决定是否从更高性能或者较低优先级存储创建卷
+  `high/medium/low`（默认值：`low`）。
+* `snap_interval`：触发快照的时钟/时间间隔（分钟）。
+  快照是基于与先前快照的增量变化，0 是禁用快照（默认：`0`）。
   这里需要填写字符串，即，是 `"70"` 而不是 `70`。
 * `aggregation_level`：指定卷分配到的块数量，0 表示一个非聚合卷（默认：`0`）。
   这里需要填写字符串，即，是 `"0"` 而不是 `0`。
-* `ephemeral`：指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true ，
-  `persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）
-  `true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
+* `ephemeral`：指定卷在卸载后进行清理还是持久化。
+  `emptyDir` 的使用场景可以将这个值设置为 true ，
+  `persistent volumes` 的使用场景可以将这个值设置为 false
+  （例如 Cassandra 这样的数据库）
+  `true/false`（默认为 `false`）。这里需要填写字符串，即，
+  是 `"true"` 而不是 `true`。
 
 ### ScaleIO
 
@@ -1167,8 +1194,8 @@ kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
 ```
 -->
 ScaleIO Kubernetes 卷插件需要配置一个 Secret 对象。
-secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的 PVC 所属的名称空间使用相同的值
-如下面的命令所示：
+Secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的
+PVC 所属的名称空间使用相同的值。如下面的命令所示：
 
 ```shell
 kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
@@ -1206,13 +1233,17 @@ parameters:
 * `adminSecretName`: The name of the secret to use for obtaining the StorageOS
   API credentials. If not specified, default values will be attempted.
 -->
-* `pool`：分配卷的 StorageOS 分布式容量池的名称。如果未指定，则使用通常存在的 `default` 池。
-* `description`：分配给动态创建的卷的描述。所有卷描述对于 storage class 都是相同的，
+* `pool`：制备卷的 StorageOS 分布式容量池的名称。如果未指定，则使用
+  通常存在的 `default` 池。
+* `description`：指定给动态创建的卷的描述。所有卷描述对于存储类而言都是相同的，
   但不同的 storage class 可以使用不同的描述，以区分不同的使用场景。
   默认为 `Kubernetas volume`。
-* `fsType`：请求的默认文件系统类型。请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
-* `adminSecretNamespace`：API 配置 secret 所在的命名空间。如果设置了 adminSecretName，则是必需的。
-* `adminSecretName`：用于获取 StorageOS API 凭证的 secret 名称。如果未指定，则将尝试默认值。
+* `fsType`：请求的默认文件系统类型。
+  请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
+* `adminSecretNamespace`：API 配置 secret 所在的命名空间。
+  如果设置了 adminSecretName，则是必需的。
+* `adminSecretName`：用于获取 StorageOS API 凭证的 secret 名称。
+  如果未指定，则将尝试默认值。
 
 <!--
 The StorageOS Kubernetes volume plugin can use a Secret object to specify an
@@ -1249,7 +1280,8 @@ and referenced with the `adminSecretNamespace` parameter. Secrets used by
 pre-provisioned volumes must be created in the same namespace as the PVC that
 references it.
 -->
-用于动态分配卷的 Secret 可以在任何名称空间中创建，并通过 `adminSecretNamespace` 参数引用。
+用于动态制备卷的 Secret 可以在任何名称空间中创建，并通过
+`adminSecretNamespace` 参数引用。
 预先配置的卷使用的 Secret 必须在与引用它的 PVC 在相同的名称空间中。
 
 <!--
@@ -1273,13 +1305,14 @@ Local volumes do not currently support dynamic provisioning, however a StorageCl
 should still be created to delay volume binding until pod scheduling. This is
 specified by the `WaitForFirstConsumer` volume binding mode.
 -->
-本地卷还不支持动态分配，然而还是需要创建 StorageClass 以延迟卷绑定，直到完成 pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。
+本地卷还不支持动态制备，然而还是需要创建 StorageClass 以延迟卷绑定，
+直到完成 Pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。
 
 <!--
 Delaying volume binding allows the scheduler to consider all of a pod's
 scheduling constraints when choosing an appropriate PersistentVolume for a
 PersistentVolumeClaim.
 -->
-延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的 PersistentVolume 时能考虑到所有 pod 的调度限制。
-
+延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的
+PersistentVolume 时能考虑到所有 Pod 的调度限制。
 
diff --git a/content/zh/docs/concepts/storage/volume-snapshot-classes.md b/content/zh/docs/concepts/storage/volume-snapshot-classes.md
index cbe8389fd1..c7b9971305 100644
--- a/content/zh/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/zh/docs/concepts/storage/volume-snapshot-classes.md
@@ -7,13 +7,13 @@ weight: 30
 <!-- overview -->
 
 <!--
-This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity
+This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity
 with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
 [storage classes](/docs/concepts/storage/storage-classes) is suggested.
 -->
-本文档描述了 Kubernetes 中 `VolumeSnapshotClass` 的概念。 建议熟悉[卷快照（Volume Snapshots）](/docs/concepts/storage/volume-snapshots/)和[存储类（Storage Class）](/docs/concepts/storage/storage-classes)。
-
-
+本文档描述了 Kubernetes 中 VolumeSnapshotClass 的概念。建议熟悉
+[卷快照（Volume Snapshots）](/zh/docs/concepts/storage/volume-snapshots/)和
+[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes)。
 
 
 <!-- body -->
@@ -21,37 +21,35 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
 <!--
 ## Introduction
 
-Just like `StorageClass` provides a way for administrators to describe the "classes"
-of storage they offer when provisioning a volume, `VolumeSnapshotClass` provides a
+Just like StorageClass provides a way for administrators to describe the "classes"
+of storage they offer when provisioning a volume, VolumeSnapshotClass provides a
 way to describe the "classes" of storage when provisioning a volume snapshot.
 -->
 ## 介绍 {#introduction}
 
-就像 `StorageClass` 为管理员提供了一种在配置卷时描述存储“类”的方法，`VolumeSnapshotClass` 提供了一种在配置卷快照时描述存储“类”的方法。
+就像 StorageClass 为管理员提供了一种在配置卷时描述存储“类”的方法，
+VolumeSnapshotClass 提供了一种在配置卷快照时描述存储“类”的方法。
 
 <!--
 ## The VolumeSnapshotClass Resource
 
-Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`,
-which are used when a `VolumeSnapshot` belonging to the class needs to be
+Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`,
+which are used when a VolumeSnapshot belonging to the class needs to be
 dynamically provisioned.
 
-The name of a `VolumeSnapshotClass` object is significant, and is how users can
+The name of a VolumeSnapshotClass object is significant, and is how users can
 request a particular class. Administrators set the name and other parameters
-of a class when first creating `VolumeSnapshotClass` objects, and the objects cannot
+of a class when first creating VolumeSnapshotClass objects, and the objects cannot
 be updated once they are created.
-
-Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapshots
-that don't request any particular class to bind to.
 -->
-## VolumeSnapshotClass 资源
+## VolumeSnapshotClass 资源  {#the-volumesnapshortclass-resource}
 
-每个 `VolumeSnapshotClass` 都包含 `driver` 、`deletionPolicy` 和 `parameters` 字段，当需要动态配置属于该类的 `VolumeSnapshot` 时使用。
+每个 VolumeSnapshotClass 都包含 `driver`、`deletionPolicy` 和 `parameters` 字段，
+在需要动态配置属于该类的 VolumeSnapshot 时使用。
 
-`VolumeSnapshotClass` 对象的名称很重要，是用户可以请求特定类的方式。
-管理员在首次创建 `VolumeSnapshotClass` 对象时设置类的名称和其他参数，对象一旦创建就无法更新。
-
-管理员可以为不请求任何特定类绑定的 VolumeSnapshots 指定默认的 `VolumeSnapshotClass`。
+VolumeSnapshotClass 对象的名称很重要，是用户可以请求特定类的方式。
+管理员在首次创建 VolumeSnapshotClass 对象时设置类的名称和其他参数，
+对象一旦创建就无法更新。
 
 ```yaml
 apiVersion: snapshot.storage.k8s.io/v1beta1
@@ -63,6 +61,26 @@ deletionPolicy: Delete
 parameters:
 ```
 
+<!--
+Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots
+that don't request any particular class to bind to by adding the
+`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation:
+-->
+管理员可以为未请求任何特定类绑定的 VolumeSnapshots 指定默认的 VolumeSnapshotClass，
+方法是设置注解 `snapshot.storage.kubernetes.io/is-default-class: "true"`：
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotClass
+metadata:
+  name: csi-hostpath-snapclass
+  annotations:
+    snapshot.storage.kubernetes.io/is-default-class: "true"
+driver: hostpath.csi.k8s.io
+deletionPolicy: Delete
+parameters:
+```
+
 <!--
 ### Driver
 
@@ -71,20 +89,25 @@ used for provisioning VolumeSnapshots. This field must be specified.
 -->
 ### 驱动程序 {#driver}
 
-卷快照类有一个驱动程序，用于确定配置 VolumeSnapshot 的 CSI 卷插件。 必须指定此字段。
+卷快照类有一个驱动程序，用于确定配置 VolumeSnapshot 的 CSI 卷插件。
+此字段必须指定。
 
 <!--
 ### 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.
+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.
+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.
 -->
 ### 删除策略 {#deletion-policy}
 
-卷快照类具有 `deletionPolicy` 属性。用户可以配置当所绑定的 `VolumeSnapshot` 对象将被删除时，如何处理 `VolumeSnapshotContent` 对象。卷快照的这个策略可以是 `Retain` 或者 `Delete`。这个策略字段必须指定。
+卷快照类具有 `deletionPolicy` 属性。用户可以配置当所绑定的 VolumeSnapshot
+对象将被删除时，如何处理 VolumeSnapshotContent 对象。
+卷快照的这个策略可以是 `Retain` 或者 `Delete`。这个策略字段必须指定。
 
-如果删除策略是 `Delete`，那么底层的存储快照会和 `VolumeSnapshotContent` 对象一起删除。如果删除策略是 `Retain`，那么底层快照和 `VolumeSnapshotContent` 对象都会被保留。
+如果删除策略是 `Delete`，那么底层的存储快照会和 VolumeSnapshotContent 对象
+一起删除。如果删除策略是 `Retain`，那么底层快照和 VolumeSnapshotContent
+对象都会被保留。
 
 <!--
 ## Parameters
@@ -95,6 +118,5 @@ the volume snapshot class. Different parameters may be accepted depending on the
 -->
 ## 参数 {#parameters}
 
-卷快照类具有描述属于该卷快照类的卷快照的参数。 可根据 `driver` 接受不同的参数。
-
+卷快照类具有描述属于该卷快照类的卷快照的参数，可根据 `driver` 接受不同的参数。
 
diff --git a/content/zh/docs/concepts/storage/volume-snapshots.md b/content/zh/docs/concepts/storage/volume-snapshots.md
index 7c6f9ee6b4..fe9360264a 100644
--- a/content/zh/docs/concepts/storage/volume-snapshots.md
+++ b/content/zh/docs/concepts/storage/volume-snapshots.md
@@ -18,7 +18,7 @@ weight: 20
 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/).
 -->
 在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
-的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
+的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
 
 <!-- body -->
 
@@ -48,6 +48,13 @@ A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is simila
 -->
 `VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。在从存储系统的相同卷上获取的快照之间，这些属性可能有所不同，因此不能通过使用与 `PersistentVolumeClaim` 相同的 `StorageClass` 来表示。
 
+<!--
+Volume snapshots provide Kubernetes users with a standardized way to copy a volume's contents at a particular point in time without creating an entirely new volume. This functionality enables, for example, database administrators to backup databases before performing edit or delete modifications.
+-->
+卷快照能力为 Kubernetes 用户提供了一种标准的方式来在指定时间点
+复制卷的内容，并且不需要创建全新的卷。例如，这一功能使得数据库管理员
+能够在执行编辑或删除之类的修改之前对数据库执行备份。
+
 <!--
 Users need to be aware of the following when using this feature:
 -->
@@ -171,7 +178,8 @@ A volume snapshot can request a particular class by specifying the name of a
 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
 using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
 -->
-`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。
+`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。
+这个字段是动态配置快照中的必填字段。
 
 卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/)
 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
@@ -182,14 +190,14 @@ For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName`
 如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。
 对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
 
-```
+```yaml
 apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshot
 metadata:
   name: test-snapshot
 spec:
   source:
-        volumeSnapshotContentName: test-content
+    volumeSnapshotContentName: test-content
 ```
 
 <!--
@@ -260,5 +268,6 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
 For more details, see
 [Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
 -->
-更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
+更多详细信息，请参阅
+[卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
 
diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md
index c6cbd24458..1a6ba538a0 100644
--- a/content/zh/docs/concepts/storage/volumes.md
+++ b/content/zh/docs/concepts/storage/volumes.md
@@ -314,13 +314,10 @@ See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "
 ### cinder {#cinder}
 
 <!--
-Prerequisite: Kubernetes with OpenStack Cloud Provider configured. For cloudprovider
-configuration please refer [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack).
+Prerequisite: Kubernetes with OpenStack Cloud Provider configured.
 -->
 {{< note >}}
 先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。
-有关 cloudprovider 配置，请参考
-[cloud provider openstack](/zh/docs/concepts/cluster-administration/cloud-providers/#openstack)。
 {{< /note >}}
 
 <!--
diff --git a/content/zh/docs/concepts/workloads/_index.md b/content/zh/docs/concepts/workloads/_index.md
index de9c41d3c2..911e8e0343 100644
--- a/content/zh/docs/concepts/workloads/_index.md
+++ b/content/zh/docs/concepts/workloads/_index.md
@@ -1,4 +1,118 @@
 ---
 title: "工作负载"
 weight: 50
+description: 理解 Pods，Kubernetes 中可部署的最小计算对象，以及辅助它运行它们的高层抽象对象。
 ---
+
+<!--
+title: "Workloads"
+weight: 50
+description: >
+  Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
+no_list: true
+-->
+
+{{< glossary_definition term_id="workload" length="short" >}}
+
+<!--
+Whether your workload is a single component or several that work together, on Kubernetes you run
+it inside a set of [Pods](/docs/concepts/workloads/pods).
+In Kubernetes, a Pod represents a set of running {{< glossary_tooltip text="containers" term_id="container" >}}
+on your cluster.
+
+A Pod has a defined lifecycle. For example, once a Pod is running in your cluster then
+a critical failure on the {{< glossary_tooltip text="node" term_id="node" >}} where that
+Pod is running means that all the Pods on that node fail. Kubernetes treats that level
+of failure as final: you would need to create a new Pod even if the node later recovers.
+-->
+无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你
+可以在一组 [Pods](/zh/docs/concepts/workloads/pods) 中运行它。
+在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组
+{{< glossary_tooltip text="容器" term_id="container" >}}。
+
+Pod 有确定的生命周期。例如，一旦某 Pod 在你的集群中运行，Pod 运行所在的
+{{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时，
+所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态：
+即使节点后来恢复正常运行，你也需要创建新的 Pod。
+
+<!--
+However, to make life considerably easier, you don't need to manage each Pod directly.
+Instead, you can use _workload resources_ that manage a set of Pods on your behalf.
+These resources configure {{< glossary_tooltip term_id="controller" text="controllers" >}}
+that make sure the right number of the right kind of Pod are running, to match the state
+you specified.
+
+Those workload resources include:
+-->
+不过，为了让用户的日子略微好过一些，你并不需要直接管理每个 Pod。
+相反，你可以使用 _负载资源_ 来替你管理一组 Pods。
+这些资源配置 {{< glossary_tooltip term_id="controller" text="控制器" >}}
+来确保合适类型的、处于运行状态的 Pod 个数是正确的，与你所指定的状态相一致。
+
+这些工作负载资源包括：
+
+<!--
+* [Deployment](/docs/concepts/workloads/controllers/deployment/) and [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
+  (replacing the legacy resource {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}});
+* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/);
+* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) for running Pods that provide
+  node-local facilities, such as a storage driver or network plugin;
+* [Job](/docs/concepts/workloads/controllers/job/) and
+  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/)
+  for tasks that run to completion.
+-->
+* [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和
+  [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
+  （替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）；
+* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/);
+* 用来运行提供节点本地支撑设施（如存储驱动或网络插件）的 Pods 的
+  [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)；
+* 用来执行运行到结束为止的
+  [Job](/zh/docs/concepts/workloads/controllers/job/) 和
+  [CronJob](/zh/docs/concepts/workloads/controllers/cron-jobs/)。
+
+<!--
+There are also two supporting concepts that you might find relevant:
+* [Garbage collection](/docs/concepts/workloads/controllers/garbage-collection/) tidies up objects
+  from your cluster after their _owning resource_ has been removed.
+* The [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/)
+  removes Jobs once a defined time has passed since they completed.
+-->
+你可能发现还有两种支撑概念很有用：
+
+* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在
+  对象的 _属主资源_ 被删除时在集群中清理这些对象。
+* [_结束后存在时间_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
+  会在 Job 结束之后的指定时间间隔之后删除它们。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+As well as reading about each resource, you can learn about specific tasks that relate to them:
+
+* [Run a stateless application using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/)
+* Run a stateful application either as a [single instance](/docs/tasks/run-application/run-single-instance-stateful-application/)
+  or as a [replicated set](/docs/tasks/run-application/run-replicated-stateful-application/)
+* [Run Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)
+-->
+除了阅读了解每类资源外，你还可以了解与这些资源相关的任务：
+
+* [使用 Deployment 运行一个无状态的应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
+* 以[单实例](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)
+  或者[多副本集合](/zh/docs/tasks/run-application/run-replicated-stateful-application/)
+  的形式运行有状态的应用；
+* [使用 CronJob 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)
+
+<!--
+Once your application is running, you might want to make it available on the internet as
+a [Service](/docs/concepts/services-networking/service/) or, for web application only,
+using an [Ingress](/docs/concepts/services-networking/ingress).
+
+You can also visit [Configuration](/docs/concepts/configuration/) to learn about Kubernetes'
+mechanisms for separating code from configuration.
+-->
+一旦你的应用处于运行状态，你就可能想要
+以[服务](/zh/docs/concepts/services-networking/service/)
+使之在互联网上可访问；或者对于 Web 应用而言，使用
+[Ingress](/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
+
diff --git a/content/zh/docs/concepts/workloads/controllers/_index.md b/content/zh/docs/concepts/workloads/controllers/_index.md
index 05824cb190..1518d9341d 100644
--- a/content/zh/docs/concepts/workloads/controllers/_index.md
+++ b/content/zh/docs/concepts/workloads/controllers/_index.md
@@ -1,4 +1,4 @@
 ---
-title: "控制器"
+title: "工作负载资源"
 weight: 20
 ---
diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md
index e04b2282db..ece35c15cf 100644
--- a/content/zh/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md
@@ -30,7 +30,7 @@ Some typical uses of a DaemonSet are:
 -->
 DaemonSet 的一些典型用法：
 
-- 在每个节点上运行集群存守护进程
+- 在每个节点上运行集群守护进程
 - 在每个节点上运行日志收集守护进程
 - 在每个节点上运行监控守护进程
 
@@ -65,7 +65,7 @@ You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` f
 <!--
 Create a DaemonSet based on the YAML file:
 -->
-基于 YAML 文件创建 DaemonSet:
+基于 YAML 文件创建 DaemonSet：
 
 ```
 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
@@ -199,7 +199,11 @@ If you do not specify either, then the DaemonSet controller will create Pods on
 -->
 ### 仅在某些节点上运行 Pod
 
-如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet 控制器将在能够与
+[Node 选择算符](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
+类似这种情况，可以指定 `.spec.template.spec.affinity`，之后 DaemonSet 控制器
+将在能够与[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)
+匹配的节点上创建 Pod。
 如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
 
 <!--
@@ -207,7 +211,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
 
 ### Scheduled by default scheduler
 -->
-## 如何调度 Daemon Pods
+## Daemon Pods 是如何被调度的
 
 ### 通过默认调度器调度
 
@@ -228,7 +232,7 @@ That introduces the following issues:
 -->
 DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
 通常，运行 Pod 的节点由 Kubernetes 调度器选择。
-不过，DaemonSet pods 由 DaemonSet 控制器创建和调度。这就带来了以下问题：
+不过，DaemonSet Pods 由 DaemonSet 控制器创建和调度。这就带来了以下问题：
 
 * Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
   DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
@@ -250,7 +254,7 @@ changes are made to the `spec.template` of the DaemonSet.
 默认调度器接下来将 Pod 绑定到目标主机。
 如果 DaemonSet Pod 的节点亲和性配置已存在，则被替换。
 DaemonSet 控制器仅在创建或修改 DaemonSet Pod 时执行这些操作，
-并且不回更改 DaemonSet 的 `spec.template`。
+并且不会更改 DaemonSet 的 `spec.template`。
 
 ```yaml
 nodeAffinity:
@@ -284,10 +288,10 @@ the related features.
 尽管 Daemon Pods 遵循[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration)
 规则，根据相关特性，控制器会自动将以下容忍度添加到 DaemonSet Pod：
 
-| 容忍度键名                               | 效果       | 版本   | 描述                                                          |
+| 容忍度键名                               | 效果       | 版本    | 描述                                                         |
 | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
 | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | 当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
-| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+    | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
+| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
 | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | |
 | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | |
 | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet Pod 能够容忍默认调度器所设置的 `unschedulable` 属性.  |
@@ -313,7 +317,7 @@ Some possible patterns for communicating with Pods in a DaemonSet are:
 
 与 DaemonSet 中的 Pod 进行通信的几种可能模式如下：
 
-- **Push**：配置 DaemonSet 中的 Pod，将更新发送到另一个服务，例如统计数据库。
+- **推送（Push）**：配置 DaemonSet 中的 Pod，将更新发送到另一个服务，例如统计数据库。
   这些服务没有客户端。
 
 - **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP
diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md
index d0537de82a..8969cad235 100644
--- a/content/zh/docs/concepts/workloads/controllers/deployment.md
+++ b/content/zh/docs/concepts/workloads/controllers/deployment.md
@@ -1,309 +1,291 @@
 ---
-reviewers:
-- janetkuo
 title: Deployments
 feature:
-  <!-- title: Automated rollouts and rollbacks -->
-  title: 自动化展开和回滚
+  title: 自动化上线和回滚
   description: >
-    <!-- Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions. -->
-    Kubernetes 会逐步推出针对应用或其配置的更改，确保在监视应用程序运行状况的同时，不会终止所有实例。如果出现问题，Kubernetes 会为您回滚更改。充分利用不断成长的部署解决方案生态系统。
-
+    Kubernetes 会分步骤地将针对应用或其配置的更改上线，同时监视应用程序运行状况以确保你不会同时终止所有实例。如果出现问题，Kubernetes 会为你回滚所作更改。你应该充分利用不断成长的部署方案生态系统。
 content_type: concept
 weight: 30
 ---
+<!--
+title: Deployments
+feature:
+  title: Automated rollouts and rollbacks
+  description: >
+    Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
+
+content_type: concept
+weight: 30
+-->
 
 <!-- overview -->
 
 <!--
-
 A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
-
 -->
-一个 _Deployment_ 控制器为 [Pods](/zh/docs/concepts/workloads/pods/)和 [ReplicaSets](/zh/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。
+一个 _Deployment_ 控制器为 {{< glossary_tooltip text="Pods" term_id="pod" >}}
+和 {{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}
+提供声明式的更新能力。
 
 <!--
-
 You describe a _desired state_ in a Deployment, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
 
 -->
-描述 Deployment 中的 _desired state_，并且 Deployment 控制器以受控速率更改实际状态，以达到期望状态。可以定义 Deployments 以创建新的 ReplicaSets ，或删除现有 Deployments ，并通过新的 Deployments 使用其所有资源。
+你负责描述 Deployment 中的 _目标状态_，而 Deployment 控制器以受控速率更改实际状态，
+使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment，
+并通过新的 Deployment 收养其资源。
 
-{{< note >}}
 <!--
-
 Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
-
 -->
-不要管理 Deployment 拥有的 ReplicaSets 。如果存在下面未介绍的用例，请考虑在主 Kubernetes 仓库中提出 issue。
-
+{{< note >}}
+不要管理 Deployment 所拥有的 ReplicaSet 。
+如果存在下面未覆盖的使用场景，请考虑在 Kubernetes 仓库中提出 Issue。
 {{< /note >}}
 
-
-
 <!-- body -->
 
 <!--
-
 ## Use Case
 
+The following are typical use cases for Deployments:
 -->
 ## 用例
 
-<!--
-
-The following are typical use cases for Deployments:
-
--->
-以下是典型的 Deployments 用例：
+以下是 Deployments 的典型用例：
 
 <!--
-
 * [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
-
--->
-* [创建 Deployment 以展开 ReplicaSet ](#creating-a-deployment)。 ReplicaSet 在后台创建 Pods。检查 ReplicaSet 展开的状态，查看其是否成功。
-
-<!--
-
 * [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
-
--->
-* [声明 Pod 的新状态](#updating-a-deployment) 通过更新 Deployment 的 PodTemplateSpec。将创建新的 ReplicaSet ，并且 Deployment 管理器以受控速率将 Pod 从旧 ReplicaSet 移动到新 ReplicaSet 。每个新的 ReplicaSet 都会更新 Deployment 的修改历史。
-
-<!--
-
 * [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
-
--->
-* [回滚到较早的 Deployment 版本](#rolling-back-a-deployment)，如果 Deployment 的当前状态不稳定。每次回滚都会更新 Deployment 的修改。
-
-<!--
-
 * [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
-
--->
-* [扩展 Deployment 以承担更多负载](#scaling-a-deployment).
-
-<!--
-
  * [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
-
--->
-* [暂停 Deployment ](#pausing-and-resuming-a-deployment) 对其 PodTemplateSpec 进行修改，然后恢复它以启动新的展开。
-
-<!--
-
  * [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
--->
-* [使用 Deployment 状态](#deployment-status) 作为卡住展开的指示器。
-
-<!--
-
  * [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
-
 -->
-* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不再需要的。
+* [创建 Deployment 以将 ReplicaSet 上线](#creating-a-deployment)。 ReplicaSet 在后台创建 Pods。
+  检查 ReplicaSet 的上线状态，查看其是否成功。
+* 通过更新 Deployment 的 PodTemplateSpec，[声明 Pod 的新状态](#updating-a-deployment) 。
+  新的 ReplicaSet 会被创建，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁移到新 ReplicaSet。
+  每个新的 ReplicaSet 都会更新 Deployment 的修订版本。
+* 如果 Deployment 的当前状态不稳定，[回滚到较早的 Deployment 版本](#rolling-back-a-deployment)。
+  每次回滚都会更新 Deployment 的修订版本。
+* [扩大 Deployment 规模以承担更多负载](#scaling-a-deployment)。
+* [暂停 Deployment ](#pausing-and-resuming-a-deployment) 以应用对 PodTemplateSpec 所作的多项修改，
+  然后恢复其执行以启动新的上线版本。
+* [使用 Deployment 状态](#deployment-status) 来判定上线过程是否出现停滞。
+* [清理较旧的不再需要的 ReplicaSet](#clean-up-policy) 。
 
 <!--
  ## Creating a Deployment
--->
-## 创建 Deployment
-
-<!--
 
 The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods:
-
 -->
-下面是 Deployment 示例。创建一个 ReplicaSet 展开三个 `nginx` Pods：
+## 创建 Deployment  {#creating-a-deployment}
+
+下面是 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 `nginx` Pods：
 
 {{< codenew file="controllers/nginx-deployment.yaml" >}}
 
 <!--
- In this example:
+In this example:
 -->
 在该例中：
 
 <!--
  * A Deployment named `nginx-deployment` is created, indicated by the `.metadata.name` field.
--->
-* 将创建名为 `nginx-deployment` 的 Deployment ，由 `.metadata.name` 字段指示。
-
-<!--
  * The Deployment creates three replicated Pods, indicated by the `replicas` field.
 -->
-*  Deployment 创建三个复制的 Pods，由 `replicas` 字段指示。
+* 创建名为 `nginx-deployment`（由 `.metadata.name` 字段标明）的 Deployment。
+* 该 Deployment 创建三个（由 `replicas` 字段标明）Pod 副本。
 
 <!--
- * The `selector` field defines how the Deployment finds which Pods to manage.
+* The `selector` field defines how the Deployment finds which Pods to manage.
   In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
   However, more sophisticated selection rules are possible,
   as long as the Pod template itself satisfies the rule.
 -->
 * `selector` 字段定义 Deployment 如何查找要管理的 Pods。
-  在这种情况下，只需选择在 Pod 模板（`app: nginx`）中定义的标签。但是，更复杂的选择规则是可能的，只要 Pod 模板本身满足规则。
-
-  {{< note >}}
+  在这里，你只需选择在 Pod 模板中定义的标签（`app: nginx`）。
+  不过，更复杂的选择规则是也可能的，只要 Pod 模板本身满足所给规则即可。
 
   <!--
-   The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
-    is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
-    and the values array contains only "value".
-    All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
+  The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
+  is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
+  and the values array contains only "value".
+  All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
   -->
-    `matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素，其键字段是“key”，运算符为“In”，值数组仅包含“value”。所有要求，从 `matchLabels` 和 `matchExpressions`，必须满足才能匹配。
+  {{< note >}}
+  `matchLabels` 字段是 `{key,value}` 偶对的映射。在 `matchLabels` 映射中的单个 `{key,value}`
+  映射等效于 `matchExpressions` 中的一个元素，即其 `key` 字段是 “key”，operator 为 “In”，`value`
+  数组仅包含 “value”。在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
   {{< /note >}}
 
 <!--
- * The `template` field contains the following sub-fields:
+* The `template` field contains the following sub-fields:
+   * The Pods are labeled `app: nginx`using the `labels` field.
+  * The Pod template's specification, or `.template.spec` field, indicates that
+    the Pods run one container, `nginx`, which runs the `nginx`
+    [Docker Hub](https://hub.docker.com/) image at version 1.14.2.
+  * Create one container and name it `nginx` using the `name` field.
 -->
 * `template` 字段包含以下子字段：
+  * Pod 被使用 `labels` 字段打上 `app: nginx` 标签。
+  * Pod 模板规约（即 `.template.spec` 字段）指示 Pods 运行一个 `nginx` 容器，
+    该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/)镜像。
+  * 创建一个容器并使用 `name` 字段将其命名为 `nginx`。
 
 <!--
- * The Pods are labeled `app: nginx`using the `labels` field.
--->
-  * Pod 标记为`app: nginx`，使用`labels`字段。
-
-  <!--
-   * The Pod template's specification, or `.template.spec` field, indicates that
-    the Pods run one container, `nginx`, which runs the `nginx`
-    [Docker Hub](https://hub.docker.com/) image at version 1.7.9.
-  -->
-  * Pod 模板规范或 `.template.spec` 字段指示 Pods 运行一个容器， `nginx`，运行 `nginx` [Docker Hub](https://hub.docker.com/)版本1.7.9的镜像 。
-
-  <!--
-   * Create one container and name it `nginx` using the `name` field.
-  -->
-  * 创建一个容器并使用`name`字段将其命名为 `nginx`。
-
-<!--
- Follow the steps given below to create the above Deployment:
+Before you begin, make sure your Kubernetes cluster is up and running.
+Follow the steps given below to create the above Deployment:
 -->
+开始之前，请确保的 Kubernetes 集群已启动并运行。
 按照以下步骤创建上述 Deployment ：
 
 <!--
- Before you begin, make sure your Kubernetes cluster is up and running.
--->
-开始之前，请确保的 Kubernetes 集群已启动并运行。
-
-<!--
- 1. Create the Deployment by running the following command:
+1. Create the Deployment by running the following command:
 -->
 1. 通过运行以下命令创建 Deployment ：
 
-    {{< note >}}
-    <!--
-    You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection.
-    -->
-      可以指定 `--record` 标志来写入在资源注释`kubernetes.io/change-cause`中执行的命令。它对以后的检查是有用的。
-    <!--
-    For example, to see the commands executed in each Deployment revision.
-    -->
-      例如，查看在每个 Deployment 修改中执行的命令。
-    {{< /note >}}
-
-    ```shell
-    kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
-    ```
+   ```shell
+   kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
+   ```
+   <!--
+   You may specify the `-record` flag to write the command executed in the resource annotation
+   `kubernetes.io/change-cause`. It is useful for future introspection.
+   For example, to see the commands executed in each Deployment revision.
+   -->
+   {{< note >}}
+   你可以设置 `--record` 标志将所执行的命令写入资源注解 `kubernetes.io/change-cause` 中。
+   这对于以后的检查是有用的。例如，要查看针对每个 Deployment 修订版本所执行过的命令。
+   {{< /note >}}
 
 <!--
  2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following:
 -->
-2. 运行 `kubectl get deployments` 以检查 Deployment 是否已创建。如果仍在创建 Deployment ，则输出以下内容：
+2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。如果仍在创建 Deployment，
+   则输出类似于：
 
-    ```shell
-    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-    nginx-deployment   3         0         0            0           1s
-    ```
+   ```
+   NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+   nginx-deployment   3         0         0            0           1s
+   ```
 
-    <!--
-    When you inspect the Deployments in your cluster, the following fields are displayed:
-    -->
-    检查集群中的 Deployments 时，将显示以下字段：
+   <!--
+   When you inspect the Deployments in your cluster, the following fields are displayed:
+   -->
+   在检查集群中的 Deployment 时，所显示的字段有：
 
-    <!--
-    * `NAME` lists the names of the Deployments in the cluster.
-        * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
-        * `CURRENT` displays how many replicas are currently running.
-        * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
-        * `AVAILABLE` displays how many replicas of the application are available to your users.
-        * `AGE` displays the amount of time that the application has been running.
-    -->
-    * `NAME` 列出了集群中 Deployments 的名称。
-    * `DESIRED` 显示应用程序的所需 _副本_ 数，在创建 Deployment 时定义这些副本。这是 _期望状态_。
-    * `CURRENT`显示当前正在运行的副本数。
-    * `UP-TO-DATE`显示已更新以实现期望状态的副本数。
-    * `AVAILABLE`显示应用程序可供用户使用的副本数。
-    * `AGE` 显示应用程序运行的时间量。
+   <!--
+   * `NAME` lists the names of the Deployments in the cluster.
+   * `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired.
+   * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
+   * `AVAILABLE` displays how many replicas of the application are available to your users.
+   * `AGE` displays the amount of time that the application has been running.
+   -->
+   * `NAME` 列出了集群中 Deployment 的名称。
+   * `READY` 显示应用程序的可用的 _副本_ 数。显示的模式是“就绪个数/期望个数”。
+   * `UP-TO-DATE` 显示为了打到期望状态已经更新的副本数。
+   * `AVAILABLE` 显示应用可供用户使用的副本数。
+   * `AGE` 显示应用程序运行的时间。
 
-    <!--
-    Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
-    -->
-    请注意，根据`.spec.replicas`副本字段，所需副本的数量为 3。
+   <!--
+   Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
+   -->
+   请注意期望副本数是根据 `.spec.replicas` 字段设置 3。
 
 <!--
  3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this:
 -->
-3. 要查看 Deployment 展开状态，运行 `kubectl rollout status deployment.v1.apps/nginx-deployment`。输出：
+3. 要查看 Deployment 上线状态，运行 `kubectl rollout status deployment.v1.apps/nginx-deployment`。
+   输出类似于：
 
-    ```shell
-    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-    deployment.apps/nginx-deployment successfully rolled out
-    ```
+   ```
+   Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+   deployment "nginx-deployment" successfully rolled out
+   ```
 
 <!--
- 4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
+4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
 -->
-4. 几秒钟后再次运行 `kubectl get deployments`。输出：
+4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于：
 
-    ```shell
-    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-    nginx-deployment   3         3         3            3           18s
-    ```
-    <!--
-    Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
-    -->
-    请注意， Deployment 已创建所有三个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板）并且可用。
+   ```
+   NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+   nginx-deployment   3         3         3            3           18s
+   ```
+
+   <!--
+   Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
+   -->
+   注意 Deployment 已创建全部三个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板）
+   并且可用。
 
 <!--
- 5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
+5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
 -->
-5. 要查看 Deployment 创建的 ReplicaSet  （`rs`），运行 `kubectl get rs`。输出：
+5. 要查看 Deployment 创建的 ReplicaSet（`rs`），运行 `kubectl get rs`。
+   输出类似于：
 
-    ```shell
-    NAME                          DESIRED   CURRENT   READY   AGE
-    nginx-deployment-75675f5897   3         3         3       18s
-    ```
-    <!--
-    Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
-            randomly generated and uses the pod-template-hash as a seed.
-    -->
-    请注意， ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子。
+   ```
+   NAME                          DESIRED   CURRENT   READY   AGE
+   nginx-deployment-75675f5897   3         3         3       18s
+   ```
+
+   <!--
+   ReplicaSet output shows the following fields:
+
+   * `NAME` lists the names of the ReplicaSets in the namespace.
+   * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
+   * `CURRENT` displays how many replicas are currently running.
+   * `READY` displays how many replicas of the application are available to your users.
+   * `AGE` displays the amount of time that the application has been running.
+   -->
+   ReplicaSet 输出中包含以下字段：
+
+   * `NAME` 列出名字空间中 ReplicaSet 的名称；
+   * `DESIRED` 显示应用的期望副本个数，即在创建 Deployment 时所定义的值。
+     此为期望状态；
+   * `CURRENT` 显示当前运行状态中的副本个数；
+   * `READY` 显示应用中有多少副本可以为用户提供服务；
+   * `AGE` 显示应用已经运行的时间长度。
+
+   <!--
+   Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
+   randomly generated and uses the pod-template-hash as a seed.
+   -->
+   注意 ReplicaSet 的名称始终被格式化为`[Deployment名称]-[随机字符串]`。
+   其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。
 
 <!--
- 6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned:
+ 6. To see the labels automatically generated for each Pod, run `kubectl get pods -show-labels`. The following output is returned:
 -->
 6. 要查看每个 Pod 自动生成的标签，运行 `kubectl get pods --show-labels`。返回以下输出：
 
-    ```shell
-    NAME                                READY     STATUS    RESTARTS   AGE       LABELS
-    nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
-    nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
-    nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
-    ```
+   ```
+   NAME                                READY     STATUS    RESTARTS   AGE       LABELS
+   nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
+   nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
+   nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
+   ```
 
-    <!--
-    The created ReplicaSet ensures that there are three `nginx` Pods.
-    -->
-    创建的复制集可确保有三个 `nginx` Pods。
+   <!--
+   The created ReplicaSet ensures that there are three `nginx` Pods.
+   -->
+   所创建的 ReplicaSet 确保总是存在三个 `nginx` Pod。
 
-{{< note >}}
 <!--
- You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
-  `app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
+You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
+`app: nginx`). Do not overlap labels or selectors with other controllers
+(including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping,
+and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
 -->
-  必须在 Deployment 中指定适当的选择器和 Pod 模板标签（在本例中为`app: nginx`）。不要与其他控制器（包括其他 Deployments 和状态设置）重叠标签或选择器。Kubernetes 不会阻止重叠，如果多个控制器具有重叠的选择器，这些控制器可能会冲突并运行意外。
+{{< note >}}
+你必须在 Deployment 中指定适当的选择算符和 Pod 模板标签（在本例中为 `app: nginx`）。
+标签或者选择算符不要与其他控制器（包括其他 Deployment 和 StatefulSet）重叠。
+Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符，它们可能会发生冲突
+执行难以预料的操作。
 {{< /note >}}
 
 <!--
@@ -311,202 +293,207 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
 -->
 ### Pod-template-hash 标签
 
+<!-- Do not change this label.  -->
 {{< note >}}
-<!--
- Do not change this label.
--->
 不要更改此标签。
 {{< /note >}}
 
 <!--
- The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
+The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet
+that a Deployment creates or adopts.
 -->
- Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment 创建或使用的每个 ReplicaSet 。
+Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment 所创建或收留的
+每个 ReplicaSet 。
 
 <!--
- This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels,
+This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels,
 and in any existing Pods that the ReplicaSet might have.
 -->
-此标签可确保 Deployment 的子 ReplicaSets 不重叠。它通过对 ReplicaSet 的 `PodTemplate` 进行哈希处理，并使用生成的哈希值添加到 ReplicaSet 选择器、Pod 模板标签,并在 ReplicaSet 可能具有的任何现有 Pod 中。
+此标签可确保 Deployment 的子 ReplicaSets 不重叠。
+标签是通过对 ReplicaSet 的 `PodTemplate` 进行哈希处理。
+所生成的哈希值被添加到 ReplicaSet 选择算符、Pod 模板标签，并存在于在 ReplicaSet
+可能拥有的任何现有 Pod 中。
 
 <!--
  ## Updating a Deployment
 -->
-## 更新 Deployment
+## 更新 Deployment   {#updating-a-deployment}
 
-{{< note >}}
 <!--
  A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, `.spec.template`)
 is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
 -->
-仅当 Deployment  Pod 模板（即 `.spec.template`）时，才会触发 Deployment 展开，例如，如果模板的标签或容器镜像已更新，其他更新（如扩展 Deployment ）不会触发展开。
+{{< note >}}
+仅当 Deployment Pod 模板（即 `.spec.template`）发生改变时，例如模板的标签或容器镜像被更新，
+才会触发 Deployment 上线。
+其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
 {{< /note >}}
 
 <!--
  Follow the steps given below to update your Deployment:
 -->
-按照以下步骤更新 Deployment ：
+按照以下步骤更新 Deployment：
 
 <!--
- 1. Let's update the nginx Pods to use the `nginx:1.9.1` image instead of the `nginx:1.7.9` image.
+1. Let's update the nginx Pods to use the `nginx:1.16.1` image instead of the `nginx:1.14.2` image.
 -->
-1. 让我们更新 nginx Pods，以使用 `nginx:1.9.1` 镜像 ，而不是 `nginx:1.7.9` 镜像 。
+1. 先来更新 nginx Pod 以使用 `nginx:1.16.1` 镜像，而不是 `nginx:1.14.2` 镜像。
 
-    ```shell
-    kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
-    ```
+   ```shell
+   kubectl --record deployment.apps/nginx-deployment set image \
+      deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
+   ```
+   <!-- or simply use the following command: -->
+   或者使用下面的命令：
+    
+   ```shell
+   kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    ```shell
-    deployment.apps/nginx-deployment image updated
-    ```
+   ```
+   deployment.apps/nginx-deployment image updated
+   ```
 
-    <!--
-    Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
-    -->
-    或者，可以 `edit`  Deployment 并将 `.spec.template.spec.containers[0].image` 从 `nginx:1.7.9` 更改至 `nginx:1.9.1`。
+   <!--
+   Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
+   -->
+   或者，可以 `edit`  Deployment 并将 `.spec.template.spec.containers[0].image` 从
+   `nginx:1.14.2` 更改至 `nginx:1.16.1`。
 
-    ```shell
-    kubectl edit deployment.v1.apps/nginx-deployment
-    ```
+   ```shell
+   kubectl edit deployment.v1.apps/nginx-deployment
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    输出：
-
-    ```shell
-    deployment.apps/nginx-deployment edited
-    ```
+   ```
+   deployment.apps/nginx-deployment edited
+   ```
 
 <!--
- 2. To see the rollout status, run:
+2. To see the rollout status, run:
 -->
-2. 要查看展开状态，运行：
+2. 要查看上线状态，运行：
 
-    ```shell
-    kubectl rollout status deployment.v1.apps/nginx-deployment
-    ```
+   ```shell
+   kubectl rollout status deployment.v1.apps/nginx-deployment
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    ```shell
-    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-    ```
-    <!--
-    or
-    -->
-    或者
+   ```
+   Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+   ```
+   <!-- or -->
+   或者
 
-    ```shell
-    deployment.apps/nginx-deployment successfully rolled out
-    ```
+   ```
+   deployment "nginx-deployment" successfully rolled out
+   ```
 
 <!--
- Get more details on your updated Deployment:
+Get more details on your updated Deployment:
 -->
-在更新后的 Deployment 上获取更多信息
+获取关于已更新的 Deployment 的更多信息：
 
 <!--
- * After the rollout succeeds, you can view the Deployment by running `kubectl get deployments`.
-    The output is similar to this:
+* After the rollout succeeds, you can view the Deployment by running `kubectl get deployments`.
+  The output is similar to this:
 -->
-* 在展开成功后，可以通过运行 `kubectl get deployments`来查看 Deployment 。
-    输出：
+* 在上线成功后，可以通过运行 `kubectl get deployments` 来查看 Deployment：
+  输出类似于：
 
-    ```shell
-    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-    nginx-deployment   3         3         3            3           36s
-    ```
+  ```shell
+  NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+  nginx-deployment   3         3         3            3           36s
+  ```
 
 <!--
- * Run `kubectl get rs` to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it
+* Run `kubectl get rs` to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it
 up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
 -->
-* 运行 `kubectl get rs` 以查看 Deployment 通过创建新的 ReplicaSet 并缩放它更新了 Pods 最多 3 个副本，以及将旧 ReplicaSet 缩放到 0 个副本。
+* 运行 `kubectl get rs` 以查看 Deployment 通过创建新的 ReplicaSet 并将其扩容到
+  3 个副本并将旧 ReplicaSet 缩容到 0 个副本完成了 Pod 的更新操作：
 
-    ```shell
-    kubectl get rs
-    ```
+  ```shell
+  kubectl get rs
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    NAME                          DESIRED   CURRENT   READY   AGE
-    nginx-deployment-1564180365   3         3         3       6s
-    nginx-deployment-2035384211   0         0         0       36s
-    ```
+  ```
+  NAME                          DESIRED   CURRENT   READY   AGE
+  nginx-deployment-1564180365   3         3         3       6s
+  nginx-deployment-2035384211   0         0         0       36s
+  ```
 
 <!--
- * Running `get pods` should now show only the new Pods:
+* Running `get pods` should now show only the new Pods:
 -->
-* 运行 `get pods` 现在应仅显示新的 Pods:
+* 现在运行 `get pods` 应仅显示新的 Pods:
 
-    ```shell
-    kubectl get pods
-    ```
+  ```shell
+  kubectl get pods
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    NAME                                READY     STATUS    RESTARTS   AGE
-    nginx-deployment-1564180365-khku8   1/1       Running   0          14s
-    nginx-deployment-1564180365-nacti   1/1       Running   0          14s
-    nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
-    ```
+  ```
+  NAME                                READY     STATUS    RESTARTS   AGE
+  nginx-deployment-1564180365-khku8   1/1       Running   0          14s
+  nginx-deployment-1564180365-nacti   1/1       Running   0          14s
+  nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
+  ```
 
-    <!--
-    Next time you want to update these Pods, you only need to update the Deployment's Pod template again.
-    -->
-    下次要更新这些 Pods 时，只需再次更新 Deployment  Pod 模板。
+  <!--
+  Next time you want to update these Pods, you only need to update the Deployment's Pod template again.
 
-    <!--
-    Deployment ensures that only a certain number of Pods are down while they are being updated. By default,
-        it ensures that at least 75% of the desired number of Pods are up (25% max unavailable).
-    -->
-     Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下，它确保至少 75%所需 Pods 运行（25%最大不可用）。
+  Deployment ensures that only a certain number of Pods are down while they are being updated. By default,
+  it ensures that at least 75% of the desired number of Pods are up (25% max unavailable).
+  -->
+  下次要更新这些 Pods 时，只需再次更新 Deployment Pod 模板即可。
 
-    <!--
-    Deployment also ensures that only a certain number of Pods are created above the desired number of Pods.
-        By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge).
-    -->
-     Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下，它可确保最多增加 25% 期望 Pods 数（25%最大增量）。
+  Deployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下，它确保至少所需 Pods
+  75% 处于运行状态（最大不可用比例为 25%）。
 
-    <!--   
-    For example, if you look at the above Deployment closely, you will see that it first created a new Pod,
-        then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of
-        new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed.
-        It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available.
-    -->
-    例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods，并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现，并没有创造新的 Pods，直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用，并且总共最多 4 个 Pods 可用。
+  <!--
+  Deployment also ensures that only a certain number of Pods are created above the desired number of Pods.
+  By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge).
+  -->
+  Deployment 还确保仅所创建 Pod 数量只可能比期望 Pods 数高一点点。
+  默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 25%（最大峰值 25%）。
+
+  <!--   
+  For example, if you look at the above Deployment closely, you will see that it first created a new Pod,
+  then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of
+  new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed.
+  It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available.
+  -->
+  例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods，
+  并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现。
+  在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用，同时
+  最多总共 4 个 Pod 可用。
 
 <!--
- * Get details of your Deployment:
+* Get details of your Deployment:
 -->
 * 获取 Deployment 的更多信息
+
   ```shell
   kubectl describe deployments
   ```
-  <!--
-    The output is similar to this:
-  -->
-  输出：
 
-  ```shell
+  <!-- The output is similar to this: -->
+  输出类似于：
+
+  ```
   Name:                   nginx-deployment
   Namespace:              default
   CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
@@ -521,7 +508,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
     Labels:  app=nginx
      Containers:
       nginx:
-        Image:        nginx:1.9.1
+        Image:        nginx:1.16.1
         Port:         80/TCP
         Environment:  <none>
         Mounts:       <none>
@@ -545,63 +532,77 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
       Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
   ```
 
-    <!--
-    Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
-        and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet
-        (nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at
-        least 2 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down
-        the new and the old ReplicaSet, with the same rolling update strategy. Finally, you'll have 3 available replicas
-        in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
-    -->
-    可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet  （nginx-deployment-2035384211）并将其直接扩展至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet （nginx-deployment-1564180365），并将其扩展为 1，然后将旧 ReplicaSet 缩小到 2，以便至少有 2 个 Pod 可用，并且最多创建 4 个 Pod。然后，它继续向上和向下扩展新的和旧的 ReplicaSet ，具有相同的滚动更新策略。最后，将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩小到 0。
+  <!--
+  Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
+  and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet
+  (nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at
+  least 2 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down
+  the new and the old ReplicaSet, with the same rolling update strategy. Finally, you'll have 3 available replicas
+  in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
+  -->
+  可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（nginx-deployment-2035384211）
+  并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet
+  （nginx-deployment-1564180365），并将其扩容为 1，然后将旧 ReplicaSet 缩容到 2，
+  以便至少有 2 个 Pod 可用且最多创建 4 个 Pod。
+  然后，它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。
+  最后，你将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩容到 0。
 
 <!--
- ### Rollover (aka multiple updates in-flight)
--->
-### 翻转（多 Deployment 动态更新）
+### Rollover (aka multiple updates in-flight)
 
-<!--
- Each time a new Deployment is observed by the Deployment controller, a ReplicaSet is created to bring up
+Each time a new Deployment is observed by the Deployment controller, a ReplicaSet is created to bring up
 the desired Pods. If the Deployment is updated, the existing ReplicaSet that controls Pods whose labels
 match `.spec.selector` but whose template does not match `.spec.template` are scaled down. Eventually, the new
 ReplicaSet is scaled to `.spec.replicas` and all old ReplicaSets is scaled to 0.
 -->
-每次 Deployment 控制器观察新 Deployment 时，都会创建一个 ReplicaSet 以启动所需的 Pods。如果更新了 Deployment ，则控制其标签的 Pods 的现有 ReplicaSet 匹配 `.spec.selector`，但其模板不匹配 `.spec.template` 被缩小。最终，新的 ReplicaSet 缩放为 `.spec.replicas`，所有旧 ReplicaSets 缩放为 0。
+### 翻转（多 Deployment 动态更新）
+
+Deployment 控制器每次注意到新的 Deployment 时，都会创建一个 ReplicaSet 以启动所需的 Pods。
+如果更新了 Deployment，则控制标签匹配 `.spec.selector` 但模板不匹配 `.spec.template` 的
+Pods 的现有 ReplicaSet 被缩容。最终，新的 ReplicaSet 缩放为 `.spec.replicas` 个副本，
+所有旧 ReplicaSets 缩放为 0 个副本。
 
 <!--
- If you update a Deployment while an existing rollout is in progress, the Deployment creates a new ReplicaSet
+If you update a Deployment while an existing rollout is in progress, the Deployment creates a new ReplicaSet
 as per the update and start scaling that up, and rolls over the ReplicaSet that it was scaling up previously
- -- it will add it to its list of old ReplicaSets and start scaling it down.
+- it will add it to its list of old ReplicaSets and start scaling it down.
 -->
-当 Deployment 正在展开时进行更新， Deployment 会为每个更新创建一个新的 ReplicaSet 并开始向上扩展，之前的 ReplicaSet 会被添加到旧 ReplicaSets 队列并开始向下扩展。
+当 Deployment 正在上线时被更新，Deployment 会针对更新创建一个新的 ReplicaSet
+并开始对其扩容，之前正在被扩容的 ReplicaSet 会被翻转，添加到旧 ReplicaSets 列表
+并开始缩容。
 
 <!--
- For example, suppose you create a Deployment to create 5 replicas of `nginx:1.7.9`,
-but then update the Deployment to create 5 replicas of `nginx:1.9.1`, when only 3
+For example, suppose you create a Deployment to create 5 replicas of `nginx:1.14.2`,
+but then update the Deployment to create 5 replicas of `nginx:1.16.1`, when only 3
 replicas of `nginx:1.7.9` had been created. In that case, the Deployment immediately starts
 killing the 3 `nginx:1.7.9` Pods that it had created, and starts creating
-`nginx:1.9.1` Pods. It does not wait for the 5 replicas of `nginx:1.7.9` to be created
+`nginx:1.9.1` Pods. It does not wait for the 5 replicas of `nginx:1.14.2` to be created
 before changing course.
 -->
-例如，假设创建一个 Deployment 以创建 `nginx:1.7.9` 的 5 个副本，然后更新 Deployment 以创建 5 个 `nginx:1.9.1` 的副本，而此时只有 3 个`nginx:1.7.9` 的副本已创建。在这种情况下， Deployment 会立即开始杀死3个 `nginx:1.7.9` Pods，并开始创建 `nginx:1.9.1` Pods。它不等待 `nginx:1.7.9` 的 5 个副本在改变任务之前完成创建。
+例如，假定你在创建一个 Deployment 以生成 `nginx:1.14.2` 的 5 个副本，但接下来
+更新 Deployment 以创建 5 个 `nginx:1.16.1` 的副本，而此时只有 3 个`nginx:1.14.2`
+副本已创建。在这种情况下，Deployment 会立即开始杀死 3 个 `nginx:1.14.2` Pods，
+并开始创建 `nginx:1.16.1` Pods。它不会等待 `nginx:1.14.2` 的 5 个副本都创建完成
+后才开始执行变更动作。
 
 <!--
- ### Label selector updates
--->
-### 使用标签选择器进行更新
+### Label selector updates
 
-<!--
  It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front.
 In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped
 all of the implications.
 -->
-通常不鼓励更新标签选择器，建议提前规划选择器。在任何情况下，如果需要执行标签选择器更新，请格外小心，并确保已掌握所有的含义。
+### 更改标签选择算符
+
+通常不鼓励更新标签选择算符。建议你提前规划选择算符。
+在任何情况下，如果需要更新标签选择算符，请格外小心，并确保自己了解
+这背后可能发生的所有事情。
 
-{{< note >}}
 <!--
- In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.
+In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.
 -->
-在 API 版本 `apps/v1` 中， Deployment 标签选择器在创建后是不可变的。
+{{< note >}}
+在 API 版本 `apps/v1` 中，Deployment 标签选择算符在创建后是不可变的。
 {{< /note >}}
 
 <!--
@@ -609,559 +610,550 @@ all of the implications.
 otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does
 not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and
 creating a new ReplicaSet.
-* Selector updates changes the existing value in a selector key -- result in the same behavior as additions.
-* Selector removals removes an existing key from the Deployment selector -- do not require any changes in the
+* Selector updates changes the existing value in a selector key - result in the same behavior as additions.
+* Selector removals removes an existing key from the Deployment selector - do not require any changes in the
 Pod template labels. Existing ReplicaSets are not orphaned, and a new ReplicaSet is not created, but note that the
 removed label still exists in any existing Pods and ReplicaSets.
 -->
-* 选择器添加还需要使用新标签更新 Deployment 规范中的 Pod 模板标签，否则将返回验证错误。此更改是非重叠的，这意味着新的选择器不选择使用旧选择器创建的 ReplicaSets 和 Pod，从而导致弃用所有旧 ReplicaSets 和创建新的 ReplicaSet 。
-* 选择器更新更改选择器键中的现有值 -- 导致发生与添加相同的行为。
-* 选择器删除从 Deployment 选择器中删除现有密钥 -- 不需要在Pod 模板标签做任意更改。现有 ReplicaSets 不会孤立，并且不会创建新的 ReplicaSet ，但请注意，已删除的标签仍然存在于任何现有的 Pods 和 ReplicaSets 中。
+* 添加选择算符时要求使用新标签更新 Deployment 规约中的 Pod 模板标签，否则将返回验证错误。
+  此更改是非重叠的，也就是说新的选择算符不会选择使用旧选择算符所创建的 ReplicaSet 和 Pod，
+  这会导致创建新的 ReplicaSet 时所有旧 ReplicaSet 都会被孤立。
+* 选择算符的更新如果更改了某个算符的键名，这会导致与添加算符时相同的行为。
+* 删除选择算符的操作会删除从 Deployment 选择算符中删除现有算符。
+  此操作不需要更改 Pod 模板标签。现有 ReplicaSet 不会被孤立，也不会因此创建新的 ReplicaSet，
+  但请注意已删除的标签仍然存在于现有的 Pod 和 ReplicaSet 中。
 
 <!--
- ## Rolling Back a Deployment
+## Rolling Back a Deployment
 -->
-## 回滚 Deployment
+## 回滚 Deployment {#rolling-back-a-deployment}
 
 <!--
  Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
 By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want
 (you can change that by modifying revision history limit).
 -->
-有时，可能需要回滚 Deployment ；例如，当 Deployment 不稳定时，例如循环崩溃。默认情况下，所有 Deployment 历史记录都保留在系统中，以便可以随时回滚（可以通过修改修改历史记录限制来更改该限制）。
+有时，你可能想要回滚 Deployment；例如，当 Deployment 不稳定时（例如进入反复崩溃状态）。
+默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚
+（你可以通过修改修订历史记录限制来更改这一约束）。
 
-{{< note >}}
 <!--
- A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
+A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
 new revision is created if and only if the Deployment's Pod template (`.spec.template`) is changed,
 for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
 do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling.
 This means that when you roll back to an earlier revision, only the Deployment's Pod template part is
 rolled back.
 -->
-触发 Deployment 展开时，将创建 Deployment 修改版。这意味着仅当 Deployment  Pod 模板 （`.spec.template`） 发生更改时，才会创建新修改版本，例如，如果更新模板的标签或容器镜像 。其他更新，如扩展 Deployment 、不要创建 Deployment 修改版，以便方便同时手动或自动缩放。这意味着，当回滚到较早的修改版时，只有 Deployment  Pod 模板部分回滚。
+{{< note >}}
+Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。
+这意味着仅当 Deployment 的 Pod 模板（`.spec.template`）发生更改时，才会创建新修订版本
+-- 例如，模板的标签或容器镜像发生变化。
+其他更新，如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。
+这是为了方便同时执行手动缩放或自动缩放。
+换言之，当你回滚到较早的修订版本时，只有 Deployment 的 Pod 模板部分会被回滚。
 {{< /note >}}
 
 <!--
- * Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
+* Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
 -->
-* 假设在更新 Deployment 时犯了一个拼写错误，将镜像名称命名为 `nginx:1.91` 而不是 `nginx:1.9.1`：
-    ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
-    ```
+* 假设你在更新 Deployment 时犯了一个拼写错误，将镜像名称命名设置为 `nginx:1.161` 而不是 `nginx:1.16.1`：
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  ```shell
+  kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
+  ```
 
-    ```shell
-    deployment.apps/nginx-deployment image updated
-    ```
+  <!-- The output is similar to this: -->
+  输出类似于：
+
+  ```shell
+  deployment.apps/nginx-deployment image updated
+  ```
 
 <!--
- * The rollout gets stuck. You can verify it by checking the rollout status:
+* The rollout gets stuck. You can verify it by checking the rollout status:
 -->
-* 展开遇到问题。可以通过检查展开状态来验证它：
+* 此上线进程会出现停滞。你可以通过检查上线状态来验证：
 
-    ```shell
-    kubectl rollout status deployment.v1.apps/nginx-deployment
-    ```
+  ```shell
+  kubectl rollout status deployment.v1.apps/nginx-deployment
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
-    ```
+  ```
+  Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
+  ```
 
 <!--
- * Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts,
+* Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts,
 [read more here](#deployment-status).
 -->
-* 按 Ctrl-C 停止上述展开状态表。有关卡住展开的详细信息，[参考这里](#deployment-status)
+* 按 Ctrl-C 停止上述上线状态观测。有关上线停滞的详细信息，[参考这里](#deployment-status)。
 
 <!--
  * You see that the number of old replicas (`nginx-deployment-1564180365` and `nginx-deployment-2035384211`) is 2, and new replicas (nginx-deployment-3066724191) is 1.
 -->
-<!--
- * You see that the number of old replicas
--->
-* 查看旧 ReplicaSets ：
-    ```shell
-    kubectl get rs
-    ```
+* 你可以看到旧的副本有两个（`nginx-deployment-1564180365` 和 `nginx-deployment-2035384211`），
+  新的副本有 1 个（`nginx-deployment-3066724191`）：
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  ```shell
+  kubectl get rs
+  ```
 
-    ```shell
-    NAME                          DESIRED   CURRENT   READY   AGE
-    nginx-deployment-1564180365   3         3         3       25s
-    nginx-deployment-2035384211   0         0         0       36s
-    nginx-deployment-3066724191   1         1         0       6s
-    ```
+  <!-- The output is similar to this: -->
+  输出类似于：
+
+  ```shell
+  NAME                          DESIRED   CURRENT   READY   AGE
+  nginx-deployment-1564180365   3         3         3       25s
+  nginx-deployment-2035384211   0         0         0       36s
+  nginx-deployment-3066724191   1         1         0       6s
+  ```
 
 <!--
- * Looking at the Pods created, you see that 1 Pod created by new ReplicaSet is stuck in an image pull loop.
+* Looking at the Pods created, you see that 1 Pod created by new ReplicaSet is stuck in an image pull loop.
 -->
-* 查看创建的 Pod，看到由新 ReplicaSet 创建的 1 个 Pod 卡在镜像拉取循环中。
+* 查看所创建的 Pod，你会注意到新 ReplicaSet 所创建的 1 个 Pod 卡顿在镜像拉取循环中。
 
-    ```shell
-    kubectl get pods
-    ```
+  ```shell
+  kubectl get pods
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    NAME                                READY     STATUS             RESTARTS   AGE
-    nginx-deployment-1564180365-70iae   1/1       Running            0          25s
-    nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
-    nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
-    nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
-    ```
+  ```shell
+  NAME                                READY     STATUS             RESTARTS   AGE
+  nginx-deployment-1564180365-70iae   1/1       Running            0          25s
+  nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
+  nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
+  nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
+  ```
 
-    {{< note >}}
-    <!--
-    The Deployment controller stops the bad rollout automatically, and stops scaling up the new
-        ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
-        Kubernetes by default sets the value to 25%.
-    -->
-    Deployment 控制器自动停止不良展开，并停止向上扩展新的 ReplicaSet 。这取决于指定的滚动更新参数（具体为 `maxUnavailable`）。默认情况下，Kubernetes 将值设置为 25%。
-    {{< /note >}}
+  <!--
+  The Deployment controller stops the bad rollout automatically, and stops scaling up the new
+  ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
+  Kubernetes by default sets the value to 25%.
+  -->
+  {{< note >}}
+  Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。
+  这行为取决于所指定的 rollingUpdate 参数（具体为 `maxUnavailable`）。
+  默认情况下，Kubernetes 将此值设置为 25%。
+  {{< /note >}}
 
 <!--
  * Get the description of the Deployment:
 -->
 * 获取 Deployment 描述信息：
-    ```shell
-    kubectl describe deployment
-    ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  ```shell
+  kubectl describe deployment
+  ```
 
-    ```shell
-    Name:           nginx-deployment
-    Namespace:      default
-    CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
-    Labels:         app=nginx
-    Selector:       app=nginx
-    Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
-    StrategyType:       RollingUpdate
-    MinReadySeconds:    0
-    RollingUpdateStrategy:  25% max unavailable, 25% max surge
-    Pod Template:
-      Labels:  app=nginx
-      Containers:
-       nginx:
-        Image:        nginx:1.91
-        Port:         80/TCP
-        Host Port:    0/TCP
-        Environment:  <none>
-        Mounts:       <none>
-      Volumes:        <none>
-    Conditions:
-      Type           Status  Reason
-      ----           ------  ------
-      Available      True    MinimumReplicasAvailable
-      Progressing    True    ReplicaSetUpdated
-    OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
-    NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
-    Events:
-      FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
-      --------- --------    -----   ----                    -------------   --------    ------              -------
-      1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
-      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
-      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
-      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
-      21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
-      21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
-      13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
-      13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
-    ```
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    <!--
-    To fix this, you need to rollback to a previous revision of Deployment that is stable.
-    -->
-    要解决此问题，需要回滚到以前稳定的 Deployment 版本。
+  ```shell
+  Name:           nginx-deployment
+  Namespace:      default
+  CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
+  Labels:         app=nginx
+  Selector:       app=nginx
+  Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
+  StrategyType:       RollingUpdate
+  MinReadySeconds:    0
+  RollingUpdateStrategy:  25% max unavailable, 25% max surge
+  Pod Template:
+    Labels:  app=nginx
+    Containers:
+     nginx:
+      Image:        nginx:1.91
+      Port:         80/TCP
+      Host Port:    0/TCP
+      Environment:  <none>
+      Mounts:       <none>
+    Volumes:        <none>
+  Conditions:
+    Type           Status  Reason
+    ----           ------  ------
+    Available      True    MinimumReplicasAvailable
+    Progressing    True    ReplicaSetUpdated
+  OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
+  NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
+  Events:
+    FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
+    --------- --------    -----   ----                    -------------   --------    ------              -------
+    1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
+    22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
+    22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
+    22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
+    21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
+    21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
+    13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
+    13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
+  ```
+
+  <!--
+  To fix this, you need to rollback to a previous revision of Deployment that is stable.
+  -->
+  要解决此问题，需要回滚到以前稳定的 Deployment 版本。
 
 <!--
- ### Checking Rollout History of a Deployment
--->
-### 检查 Deployment 展开历史
+### Checking Rollout History of a Deployment
 
-<!--
- Follow the steps given below to check the rollout history:
+Follow the steps given below to check the rollout history:
 -->
+### 检查 Deployment 上线历史
+
 按照如下步骤检查回滚历史：
 
 <!--
  1. First, check the revisions of this Deployment:
 -->
-1. 首先，检查 Deployment 修改历史：
+1. 首先，检查 Deployment 修订历史：
 
-    ```shell
-    kubectl rollout history deployment.v1.apps/nginx-deployment
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   ```shell
+   kubectl rollout history deployment.v1.apps/nginx-deployment
+   ```
 
-    ```shell
-    deployments "nginx-deployment"
-    REVISION    CHANGE-CAUSE
-    1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
-    2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
-    3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
-    ```
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    <!--
-    `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by:
-    -->
-    `CHANGE-CAUSE` 从 Deployment 注释 `kubernetes.io/change-cause` 创建时复制到其修改版。可以通过以下条件指定 `CHANGE-CAUSE` 消息：
+   ```shell
+   deployments "nginx-deployment"
+   REVISION    CHANGE-CAUSE
+   1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
+   2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+   3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
+   ```
 
-    <!--
-    * Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
-        * Append the `--record` flag to save the `kubectl` command that is making changes to the resource.
-        * Manually editing the manifest of the resource.
-    -->
-    * 使用 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`  Deployment 对 Deployment 进行分号。
-    * 追加 `--record` 以保存正在更改资源的 `kubectl` 命令。
-    * 手动编辑资源的清单。
+   <!--
+   `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by:
+   -->
+   `CHANGE-CAUSE` 的内容是从 Deployment 的 `kubernetes.io/change-cause` 注解复制过来的。
+   复制动作发生在修订版本创建时。你可以通过以下方式设置 `CHANGE-CAUSE` 消息：
+
+   <!--
+   * Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
+   * Append the `-record` flag to save the `kubectl` command that is making changes to the resource.
+   * Manually editing the manifest of the resource.
+   -->
+   * 使用 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` 为 Deployment 添加注解。
+   * 追加 `--record` 命令行标志以保存正在更改资源的 `kubectl` 命令。
+   * 手动编辑资源的清单。
 
 <!--
- 2. To see the details of each revision, run:
+2. To see the details of each revision, run:
 -->
-2. 查看修改历史的详细信息，运行：
+2. 要查看修订历史的详细信息，运行：
 
-    ```shell
-    kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
-    ```
+   ```shell
+   kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    ```shell
-    deployments "nginx-deployment" revision 2
-      Labels:       app=nginx
-              pod-template-hash=1159050644
-      Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
-      Containers:
-       nginx:
-        Image:      nginx:1.9.1
-        Port:       80/TCP
-         QoS Tier:
-            cpu:      BestEffort
-            memory:   BestEffort
-        Environment Variables:      <none>
-      No volumes.
-    ```
+   ```shell
+   deployments "nginx-deployment" revision 2
+     Labels:       app=nginx
+             pod-template-hash=1159050644
+     Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+     Containers:
+      nginx:
+       Image:      nginx:1.16.1
+       Port:       80/TCP
+        QoS Tier:
+           cpu:      BestEffort
+           memory:   BestEffort
+       Environment Variables:      <none>
+     No volumes.
+   ```
 
 <!--
- ### Rolling Back to a Previous Revision
+### Rolling Back to a Previous Revision
 Follow the steps given below to rollback the Deployment from the current version to the previous version, which is version 2.
 -->
-### 回滚到上一次修改
+### 回滚到之前的修订版本   {#rolling-back-to-a-previous-revision}
 
 按照下面给出的步骤将 Deployment 从当前版本回滚到以前的版本（即版本 2）。
 
 <!--
  1. Now you've decided to undo the current rollout and rollback to the previous revision:
 -->
-1. 现在已决定撤消当前展开并回滚到以前的版本：
+1. 假定现在你已决定撤消当前上线并回滚到以前的修订版本：
 
-    ```shell
-    kubectl rollout undo deployment.v1.apps/nginx-deployment
-    ```
+   ```shell
+   kubectl rollout undo deployment.v1.apps/nginx-deployment
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    ```shell
-    deployment.apps/nginx-deployment
-    ```
-    <!--
-    Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
-    -->
-    或者，可以通过使用 `--to-revision` 来回滚到特定修改版本：
+   ```
+   deployment.apps/nginx-deployment
+   ```
 
-    ```shell
-    kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
-    ```
+   <!--
+   Alternatively, you can rollback to a specific revision by specifying it with `-to-revision`:
+   -->
+   或者，你也可以通过使用 `--to-revision` 来回滚到特定修订版本：
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   ```shell
+   kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
+   ```
 
-    ```shell
-    deployment.apps/nginx-deployment
-    ```
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    <!--
-    For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
-    -->
-    更多有关回滚相关指令，请参考 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
+   ```
+   deployment.apps/nginx-deployment
+   ```
 
-    <!--
-    The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event
-        for rolling back to revision 2 is generated from Deployment controller.
-    -->
-    现在， Deployment 将回滚到以前的稳定版本。如所见， Deployment 回滚事件回滚到修改版 2 是从 Deployment 控制器生成的。
+   <!--
+   For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
+   -->
+   与回滚相关的指令的更详细信息，请参考 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)。
+
+   <!--
+   The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event
+   for rolling back to revision 2 is generated from Deployment controller.
+   -->
+   现在，Deployment 正在回滚到以前的稳定版本。正如你所看到的，Deployment 控制器生成了
+   回滚到修订版本 2 的 `DeploymentRollback` 事件。
 
 <!--
  2. Check if the rollback was successful and the Deployment is running as expected, run:
 -->
-2. 检查回滚是否成功、 Deployment 是否正在运行，运行：
+2. 检查回滚是否成功以及 Deployment 是否正在运行，运行：
 
-    ```shell
-    kubectl get deployment nginx-deployment
-    ```
+   ```shell
+   kubectl get deployment nginx-deployment
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    ```shell
-    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-    nginx-deployment   3         3         3            3           30m
-    ```
+   ```shell
+   NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+   nginx-deployment   3         3         3            3           30m
+   ```
 
 <!--
- 3. Get the description of the Deployment:
+3. Get the description of the Deployment:
 -->
 3. 获取 Deployment 描述信息：
 
-    ```shell
-    kubectl describe deployment nginx-deployment
-    ```
+   ```shell
+   kubectl describe deployment nginx-deployment
+   ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+   <!-- The output is similar to this: -->
+   输出类似于：
 
-    ```shell
-    Name:                   nginx-deployment
-    Namespace:              default
-    CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
-    Labels:                 app=nginx
-    Annotations:            deployment.kubernetes.io/revision=4
-                            kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
-    Selector:               app=nginx
-    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
-    StrategyType:           RollingUpdate
-    MinReadySeconds:        0
-    RollingUpdateStrategy:  25% max unavailable, 25% max surge
-    Pod Template:
-      Labels:  app=nginx
-      Containers:
-       nginx:
-        Image:        nginx:1.9.1
-        Port:         80/TCP
-        Host Port:    0/TCP
-        Environment:  <none>
-        Mounts:       <none>
-      Volumes:        <none>
-    Conditions:
-      Type           Status  Reason
-      ----           ------  ------
-      Available      True    MinimumReplicasAvailable
-      Progressing    True    NewReplicaSetAvailable
-    OldReplicaSets:  <none>
-    NewReplicaSet:   nginx-deployment-c4747d96c (3/3 replicas created)
-    Events:
-      Type    Reason              Age   From                   Message
-      ----    ------              ----  ----                   -------
-      Normal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
-      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
-      Normal  DeploymentRollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
-      Normal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0
-    ```
+   ```
+   Name:                   nginx-deployment
+   Namespace:              default
+   CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
+   Labels:                 app=nginx
+   Annotations:            deployment.kubernetes.io/revision=4
+                           kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+   Selector:               app=nginx
+   Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
+   StrategyType:           RollingUpdate
+   MinReadySeconds:        0
+   RollingUpdateStrategy:  25% max unavailable, 25% max surge
+   Pod Template:
+     Labels:  app=nginx
+     Containers:
+      nginx:
+       Image:        nginx:1.16.1
+       Port:         80/TCP
+       Host Port:    0/TCP
+       Environment:  <none>
+       Mounts:       <none>
+     Volumes:        <none>
+   Conditions:
+     Type           Status  Reason
+     ----           ------  ------
+     Available      True    MinimumReplicasAvailable
+     Progressing    True    NewReplicaSetAvailable
+   OldReplicaSets:  <none>
+   NewReplicaSet:   nginx-deployment-c4747d96c (3/3 replicas created)
+   Events:
+     Type    Reason              Age   From                   Message
+     ----    ------              ----  ----                   -------
+     Normal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
+     Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
+     Normal  DeploymentRollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
+     Normal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0
+   ```
 
 <!--
- ## Scaling a Deployment
--->
-## 缩放 Deployment
+## Scaling a Deployment
 
-
-<!--
- You can scale a Deployment by using the following command:
+You can scale a Deployment by using the following command:
 -->
-可以使用如下指令缩放 Deployment ：
+## 缩放 Deployment   {#scaling-a-deployment}
+
+你可以使用如下指令缩放 Deployment：
 
 ```shell
 kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
 ```
 
-<!--
- The output is similar to this:
--->
-输出：
+<!-- The output is similar to this: -->
+输出类似于：
 
-```shell
+```
 deployment.apps/nginx-deployment scaled
 ```
 
 <!--
- Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) is enabled
+Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) is enabled
 in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
 Pods you want to run based on the CPU utilization of your existing Pods.
 -->
-假设启用[水平自动缩放 Pod](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
-要基于现有 Pods 的 CPU 利用率运行的 Pods。
+假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
+你可以为 Deployment 设置自动缩放器，并基于现有 Pods 的 CPU 利用率选择
+要运行的 Pods 个数下限和上限。
 
 ```shell
 kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
 ```
 
-<!--
- The output is similar to this:
--->
-输出：
+<!-- The output is similar to this: -->
+输出类似于：
 
-```shell
+```
 deployment.apps/nginx-deployment scaled
 ```
 
 <!--
- ### Proportional scaling
--->
-### 比例缩放
+### Proportional scaling
 
-<!--
- RollingUpdate Deployments support running multiple versions of an application at the same time. When you
+RollingUpdate Deployments support running multiple versions of an application at the same time. When you
 or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress
 or paused), the Deployment controller balances the additional replicas in the existing active
 ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *proportional scaling*.
 -->
-滚动更新 Deployments 支持同时运行应用程序的多个版本。当自动缩放器缩放处于展开中间的滚动更新 Deployment （仍在进行中或暂停）时， Deployment 控制器平衡现有活动中的其他 ReplicaSets （带 Pods 的 ReplicaSets ），以降低风险。这称为比例缩放。
+### 比例缩放  {#proportional-scaling}
+
+RollingUpdate 的 Deployment 支持同时运行应用程序的多个版本。
+当自动缩放器缩放处于上线进程（仍在进行中或暂停）中的 RollingUpdate Deployment 时，
+Deployment 控制器会平衡现有的活跃状态的 ReplicaSets（含 Pods 的 ReplicaSets）中的额外副本，
+以降低风险。这称为 *比例缩放（Proportional Scaling）*。
 
 <!--
- For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surge)=3, and [maxUnavailable](#max-unavailable)=2.
+For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surge)=3, and [maxUnavailable](#max-unavailable)=2.
 -->
-例如，运行一个10个副本的 Deployment ，[最大增加](#max-surge)=3， [最大不可用](#max-unavailable)=2.
+例如，你正在运行一个 10 个副本的 Deployment，其 [maxSurge](#max-surge)=3，[maxUnavailable](#max-unavailable)=2。
 
 <!--
- * Ensure that the 10 replicas in your Deployment are running.
+* Ensure that the 10 replicas in your Deployment are running.
 -->
-* 确保这10个副本都在运行。
+* 确保 Deployment 的这 10 个副本都在运行。
+
   ```shell
   kubectl get deploy
   ```
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-  <!--
-  The output is similar to this:
-  -->
-  输出：
-
-  ```shell
+  ```
   NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   nginx-deployment     10        10        10           10          50s
   ```
 
 <!--
- * You update to a new image which happens to be unresolvable from inside the cluster.
+* You update to a new image which happens to be unresolvable from inside the cluster.
 -->
-* 更新到新镜像，该镜像恰好无法从集群内部解析。
-    ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
-    ```
+* 更新 Deployment 使用新镜像，碰巧该镜像无法从集群内部解析。
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  ```shell
+  kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
+  ```
 
-    ```shell
-    deployment.apps/nginx-deployment image updated
-    ```
+  <!-- The output is similar to this: -->
+  输出类似于：
+
+  ```
+  deployment.apps/nginx-deployment image updated
+  ```
 
 <!--
- * The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the
+* The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the
 `maxUnavailable` requirement that you mentioned above. Check out the rollout status:
 -->
-* 镜像更新使用 ReplicaSet  nginx-deployment-1989198191 启动新的展开，但由于上面提到的最大不可用要求。检查展开状态：
-    ```shell
-    kubectl get rs
-    ```
-    <!--
-    The output is similar to this:
-    -->
-      输出：
+* 镜像更新使用 ReplicaSet `nginx-deployment-1989198191` 启动新的上线过程，
+  但由于上面提到的 `maxUnavailable` 要求，该进程被阻塞了。检查上线状态：
 
-    ```shell
-    NAME                          DESIRED   CURRENT   READY     AGE
-    nginx-deployment-1989198191   5         5         0         9s
-    nginx-deployment-618515232    8         8         8         1m
-    ```
+  ```shell
+  kubectl get rs
+  ```
+  <!-- The output is similar to this: -->
+  输出类似于：
+
+  ```
+  NAME                          DESIRED   CURRENT   READY     AGE
+  nginx-deployment-1989198191   5         5         0         9s
+  nginx-deployment-618515232    8         8         8         1m
+  ```
 
 <!--
- * Then a new scaling request for the Deployment comes along. The autoscaler increments the Deployment replicas
+* Then a new scaling request for the Deployment comes along. The autoscaler increments the Deployment replicas
 to 15. The Deployment controller needs to decide where to add these new 5 replicas. If you weren't using
 proportional scaling, all 5 of them would be added in the new ReplicaSet. With proportional scaling, you
 spread the additional replicas across all ReplicaSets. Bigger proportions go to the ReplicaSets with the
 most replicas and lower proportions go to ReplicaSets with less replicas. Any leftovers are added to the
 ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled up.
 -->
-* 然后，出现了新的 Deployment 扩展请求。自动缩放器增加 Deployment 副本到15。 Deployment 控制器需要决定在何处添加这些新 5 个副本。如果未使用比例缩放，所有 5 个都将添加到新的 ReplicaSet 中。使用比例缩放，可以将其他副本分布到所有 ReplicaSets 。更大的比例转到 ReplicaSets 与大多数副本和较低的比例都转到副本较少的 ReplicaSets 。任何剩余部分都添加到具有最多副本的 ReplicaSet 。具有零副本的 ReplicaSets 不会放大。
+* 然后，出现了新的 Deployment 扩缩请求。自动缩放器将 Deployment 副本增加到 15。
+  Deployment 控制器需要决定在何处添加 5 个新副本。如果未使用比例缩放，所有 5 个副本
+  都将添加到新的 ReplicaSet 中。使用比例缩放时，可以将额外的副本分布到所有 ReplicaSet。
+  较大比例的副本会被添加到拥有最多副本的 ReplicaSet，而较低比例的副本会进入到
+  副本较少的 ReplicaSet。所有剩下的副本都会添加到副本最多的 ReplicaSet。
+  具有零副本的 ReplicaSets 不会被扩容。
 
 <!--
- In our example above, 3 replicas are added to the old ReplicaSet and 2 replicas are added to the
+In our example above, 3 replicas are added to the old ReplicaSet and 2 replicas are added to the
 new ReplicaSet. The rollout process should eventually move all replicas to the new ReplicaSet, assuming
 the new replicas become healthy. To confirm this, run:
 -->
-在上面的示例中，3 个副本添加到旧 ReplicaSet 中，2 个副本添加到新 ReplicaSet 。展开过程最终应将所有副本移动到新的 ReplicaSet ，假定新的副本变得正常。要确认这一点，请运行：
+在上面的示例中，3 个副本被添加到旧 ReplicaSet 中，2 个副本被添加到新 ReplicaSet。
+假定新的副本都很健康，上线过程最终应将所有副本迁移到新的 ReplicaSet 中。
+要确认这一点，请运行：
 
 ```shell
 kubectl get deploy
 ```
+<!-- The output is similar to this: -->
+输出类似于：
 
-<!--
- The output is similar to this:
--->
-输出：
-
-```shell
+```
 NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment     15        18        7            8           7m
 ```
 
 <!--
- The rollout status confirms how the replicas were added to each ReplicaSet.
+The rollout status confirms how the replicas were added to each ReplicaSet.
 -->
-展开状态确认副本如何添加到每个 ReplicaSet 。
+上线状态确认了副本是如何被添加到每个 ReplicaSet 的。
 
 ```shell
 kubectl get rs
 ```
 
-<!--
- The output is similar to this:
--->
-输出：
+<!-- The output is similar to this: -->
+输出类似于：
 
 ```shell
 NAME                          DESIRED   CURRENT   READY     AGE
@@ -1170,249 +1162,231 @@ nginx-deployment-618515232    11        11        11        7m
 ```
 
 <!--
- ## Pausing and Resuming a Deployment
--->
-## 暂停、恢复 Deployment
+## Pausing and Resuming a Deployment
 
-<!--
- You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
+You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
 apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
 -->
-可以在触发一个或多个更新之前暂停 Deployment ，然后继续它。这允许在暂停和恢复之间应用多个修补程序，而不会触发不必要的 Deployment 。
+## 暂停、恢复 Deployment   {#pausing-and-resuming-a-deployment}
+
+你可以在触发一个或多个更新之前暂停 Deployment，然后再恢复其执行。
+这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。
 
 <!--
- * For example, with a Deployment that was just created:
+* For example, with a Deployment that was just created:
   Get the Deployment details:
 -->
-* 例如，对于一个刚刚创建的 Deployment ：
+* 例如，对于一个刚刚创建的 Deployment：
   获取 Deployment 信息：
 
   ```shell
   kubectl get deploy
   ```
-    <!--
-    The output is similar to this:
-    -->
-  输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-  ```shell
+  ```
   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   nginx     3         3         3            3           1m
   ```
 
-    <!--
-    Get the rollout status:
-    -->
-  获取 Deployment 状态：
+  <!-- Get the rollout status: -->
+  获取上线状态：
 
   ```shell
   kubectl get rs
   ```
-  <!--
-  The output is similar to this:
-  -->
-  输出：
+
+  <!-- The output is similar to this: -->
+  输出类似于：
 
   ```shell
   NAME               DESIRED   CURRENT   READY     AGE
   nginx-2142116321   3         3         3         1m
   ```
 
-    <!--
-    * Pause by running the following command:
-    -->
-    使用如下指令中断运行：
+<!--
+* Pause by running the following command:
+-->
+* 使用如下指令暂停运行：
 
-    ```shell
-    kubectl rollout pause deployment.v1.apps/nginx-deployment
-    ```
+  ```shell
+  kubectl rollout pause deployment.v1.apps/nginx-deployment
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    deployment.apps/nginx-deployment paused
-    ```
+  ```shell
+  deployment.apps/nginx-deployment paused
+  ```
 
 <!--
- * Then update the image of the Deployment:
+* Then update the image of the Deployment:
 -->
-* 然后更新 Deployment 镜像：
+* 接下来更新 Deployment 镜像：
 
-    ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
-    ```
+  ```shell
+  kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    deployment.apps/nginx-deployment image updated
-    ```
+  ```
+  deployment.apps/nginx-deployment image updated
+  ```
 
 <!--
  * Notice that no new rollout started:
 -->
-* 注意没有新的展开：
+* 注意没有新的上线被触发：
 
-    ```shell
-    kubectl rollout history deployment.v1.apps/nginx-deployment
-    ```
+  ```shell
+  kubectl rollout history deployment.v1.apps/nginx-deployment
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    deployments "nginx"
-    REVISION  CHANGE-CAUSE
-    1   <none>
-    ```
+  ```shell
+  deployments "nginx"
+  REVISION  CHANGE-CAUSE
+  1   <none>
+  ```
 
 <!--
- * Get the rollout status to ensure that the Deployment is updates successfully:
+* Get the rollout status to ensure that the Deployment is updates successfully:
 -->
-* 获取展开状态确保 Deployment 更新已经成功：
+* 获取上线状态确保 Deployment 更新已经成功：
 
-    ```shell
-    kubectl get rs
-    ```
+  ```shell
+  kubectl get rs
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    NAME               DESIRED   CURRENT   READY     AGE
-    nginx-2142116321   3         3         3         2m
-    ```
+  ```shell
+  NAME               DESIRED   CURRENT   READY     AGE
+  nginx-2142116321   3         3         3         2m
+  ```
 
 <!--
- * You can make as many updates as you wish, for example, update the resources that will be used:
+* You can make as many updates as you wish, for example, update the resources that will be used:
 -->
-* 更新是很容易的，例如，可以这样更新使用到的资源：
+* 你可以根据需要执行很多更新操作，例如，可以要使用的资源：
 
-    ```shell
-    kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
-    ```
+  ```shell
+  kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    deployment.apps/nginx-deployment resource requirements updated
-    ```
+  ```
+  deployment.apps/nginx-deployment resource requirements updated
+  ```
 
-    <!--
-    The initial state of the Deployment prior to pausing it will continue its function, but new updates to
-        the Deployment will not have any effect as long as the Deployment is paused.
-    -->
-    暂停 Deployment 之前的初始状态将继续其功能，但新的更新只要暂停 Deployment ， Deployment 就不会产生任何效果。
+  <!--
+  The initial state of the Deployment prior to pausing it will continue its function, but new updates to
+  the Deployment will not have any effect as long as the Deployment is paused.
+  -->
+  暂停 Deployment 之前的初始状态将继续发挥作用，但新的更新在 Deployment 被
+  暂停期间不会产生任何效果。
 
 <!--
- * Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
+* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
 -->
-* 最后，恢复 Deployment 并观察新的 ReplicaSet ，并更新所有新的更新：
+* 最终，恢复 Deployment 执行并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新：
 
-    ```shell
-    kubectl rollout resume deployment.v1.apps/nginx-deployment
-    ```
+  ```shell
+  kubectl rollout resume deployment.v1.apps/nginx-deployment
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出：
 
-    ```shell
-    deployment.apps/nginx-deployment resumed
-    ```
-<!--
- * Watch the status of the rollout until it's done.
--->
-* 观察展开的状态，直到完成。
-
-    ```shell
-    kubectl get rs -w
-    ```
-
-    <!--
-    The output is similar to this:
-    -->
-    输出：
-
-    ```shell
-    NAME               DESIRED   CURRENT   READY     AGE
-    nginx-2142116321   2         2         2         2m
-    nginx-3926361531   2         2         0         6s
-    nginx-3926361531   2         2         1         18s
-    nginx-2142116321   1         2         2         2m
-    nginx-2142116321   1         2         2         2m
-    nginx-3926361531   3         2         1         18s
-    nginx-3926361531   3         2         1         18s
-    nginx-2142116321   1         1         1         2m
-    nginx-3926361531   3         3         1         18s
-    nginx-3926361531   3         3         2         19s
-    nginx-2142116321   0         1         1         2m
-    nginx-2142116321   0         1         1         2m
-    nginx-2142116321   0         0         0         2m
-    nginx-3926361531   3         3         3         20s
-    ```
+  ```shell
+  deployment.apps/nginx-deployment resumed
+  ```
 
 <!--
- * Get the status of the latest rollout:
+* Watch the status of the rollout until it's done.
 -->
-* 获取最近展开的状态：
+* 观察上线的状态，直到完成。
 
-    ```shell
-    kubectl get rs
-    ```
+  ```shell
+  kubectl get rs -w
+  ```
 
-    <!--
-    The output is similar to this:
-    -->
-    输出：
+  <!-- The output is similar to this: -->
+  输出类似于：
 
-    ```shell
-    NAME               DESIRED   CURRENT   READY     AGE
-    nginx-2142116321   0         0         0         2m
-    nginx-3926361531   3         3         3         28s
-    ```
+  ```
+  NAME               DESIRED   CURRENT   READY     AGE
+  nginx-2142116321   2         2         2         2m
+  nginx-3926361531   2         2         0         6s
+  nginx-3926361531   2         2         1         18s
+  nginx-2142116321   1         2         2         2m
+  nginx-2142116321   1         2         2         2m
+  nginx-3926361531   3         2         1         18s
+  nginx-3926361531   3         2         1         18s
+  nginx-2142116321   1         1         1         2m
+  nginx-3926361531   3         3         1         18s
+  nginx-3926361531   3         3         2         19s
+  nginx-2142116321   0         1         1         2m
+  nginx-2142116321   0         1         1         2m
+  nginx-2142116321   0         0         0         2m
+  nginx-3926361531   3         3         3         20s
+  ```
 
+<!--
+* Get the status of the latest rollout:
+-->
+* 获取最近上线的状态：
+
+  ```shell
+  kubectl get rs
+  ```
+
+  <!-- The output is similar to this: -->
+  输出类似于：
+
+  ```
+  NAME               DESIRED   CURRENT   READY     AGE
+  nginx-2142116321   0         0         0         2m
+  nginx-3926361531   3         3         3         28s
+  ```
+
+<!--
+You cannot rollback a paused Deployment until you resume it.
+-->
 {{< note >}}
-<!--
- You cannot rollback a paused Deployment until you resume it.
--->
-暂停的 Deployment 不可以回滚，除非恢复它以后。
+你不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。
 {{< /note >}}
 
 <!--
- ## Deployment status
--->
-##  Deployment 状态
+## Deployment status
 
-<!--
- A Deployment enters various states during its lifecycle. It can be [progressing](#progressing-deployment) while
+A Deployment enters various states during its lifecycle. It can be [progressing](#progressing-deployment) while
 rolling out a new ReplicaSet, it can be [complete](#complete-deployment), or it can [fail to progress](#failed-deployment).
 -->
-一个 Deployment 的生命周期中会有许多状态。当正在生产新的 ReplicaSet 时可能是[正在运行](#progressing-deployment)，可能是[已完成](#complete-deployment)，也可能是[ Deployment 失败](#failed-deployment)。
+##  Deployment 状态 {#deployment-status}
+
+Deployment 的生命周期中会有许多状态。上线新的 ReplicaSet 期间可能处于
+[Progressing（进行中）](#progressing-deployment)，可能是
+[Complete（已完成）](#complete-deployment)，也可能是
+[Failed（失败）](#failed-deployment)以至于无法继续进行。
 
 <!--
- ### Progressing Deployment
--->
-### 正在 Deployment
+### Progressing Deployment
 
-<!--
- Kubernetes marks a Deployment as _progressing_ when one of the following tasks is performed:
+Kubernetes marks a Deployment as _progressing_ when one of the following tasks is performed:
 -->
-Kubernetes 使用 _运行中_ 来标记一个 Deployment ，当下面的任务被执行时：
+### 进行中的 Deployment  {#progressing-deployment}
+
+执行下面的任务期间，Kubernetes 标记 Deployment 为 _进行中（Progressing）_：
 
 <!--
  * The Deployment creates a new ReplicaSet.
@@ -1420,74 +1394,67 @@ Kubernetes 使用 _运行中_ 来标记一个 Deployment ，当下面的任务
 * The Deployment is scaling down its older ReplicaSet(s).
 * New Pods become ready or available (ready for at least [MinReadySeconds](#min-ready-seconds)).
 -->
-* 创建新的 ReplicaSet 。
-* 正在向上扩展最新的 ReplicaSet 。
-*  Deployment 向下扩展旧的 ReplicaSet(s) 。
-* 新的 Pods 已经就绪或者可用（在[最小就绪时间](#min-ready-seconds)内就绪）。
+* Deployment 创建新的 ReplicaSet
+* Deployment 正在为其最新的 ReplicaSet 扩容
+* Deployment 正在为其旧有的 ReplicaSet(s) 缩容
+* 新的 Pods 已经就绪或者可用（就绪至少持续了 [MinReadySeconds](#min-ready-seconds) 秒）。
 
 <!--
- You can monitor the progress for a Deployment by using `kubectl rollout status`.
+You can monitor the progress for a Deployment by using `kubectl rollout status`.
 -->
-可以使用 `kubectl rollout status` 监视 Deployment 的进度。
+你可以使用 `kubectl rollout status` 监视 Deployment 的进度。
 
 <!--
- ### Complete Deployment
+### Complete Deployment
+
+Kubernetes marks a Deployment as _complete_ when it has the following characteristics:
 -->
-### 完成 Deployment
+### 完成的 Deployment    {#complete-deployment}
+
+当 Deployment 具有以下特征时，Kubernetes 将其标记为 _完成（Complete）_：
 
 <!--
- Kubernetes marks a Deployment as _complete_ when it has the following characteristics:
--->
-Kubernetes 将 Deployment 标记为 _完成_，当它具有以下特征时：
-
-<!--
- * All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any
+* All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any
 updates you've requested have been completed.
+* All of the replicas associated with the Deployment are available.
+* No old replicas for the Deployment are running.
 -->
-* 与 Deployment 关联的所有副本都已更新到指定的最新版本，这意味着请求的任何更新都已完成。
-
-<!--
- * All of the replicas associated with the Deployment are available.
--->
+* 与 Deployment 关联的所有副本都已更新到指定的最新版本，这意味着之前请求的所有更新都已完成。
 * 与 Deployment 关联的所有副本都可用。
-
-<!--
- * No old replicas for the Deployment are running.
--->
 * 未运行 Deployment 的旧副本。
 
 <!--
- You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed
+You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed
 successfully, `kubectl rollout status` returns a zero exit code.
 -->
-可以使用 `kubectl rollout status` 检查 Deployment 是否已完成。如果展开成功完成，`kubectl rollout status` 返回退出代码 0。
+你可以使用 `kubectl rollout status` 检查 Deployment 是否已完成。
+如果上线成功完成，`kubectl rollout status` 返回退出代码 0。
 
 ```shell
 kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 
-<!--
- The output is similar to this:
--->
-输出：
+<!-- The output is similar to this: -->
+输出类似于：
 
 ```shell
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment.apps/nginx-deployment successfully rolled out
+deployment "nginx-deployment" successfully rolled out
 $ echo $?
 0
 ```
 
 <!--
- ### Failed Deployment
+### Failed Deployment
 -->
-###  Deployment 失败
+### 失败的 Deployment   {#failed-deployment}
 
 <!--
- Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing. This can occur
+Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing. This can occur
 due to some of the following factors:
 -->
-你的 Deployment 可能会在未完成的情况下尝试 Deployment 其最新的 ReplicaSet 时遇到问题。可能发生此情况由于以下一些因素：
+你的 Deployment 可能会在尝试部署其最新的 ReplicaSet 受挫，一直处于未完成状态。
+造成此情况一些可能因素如下：
 
 <!--
  * Insufficient quota
@@ -1497,90 +1464,95 @@ due to some of the following factors:
 * Limit ranges
 * Application runtime misconfiguration
 -->
-* 配额不足
-* 就绪探测失败
+* 配额（Quota）不足
+* 就绪探测（Readiness Probe）失败
 * 镜像拉取错误
 * 权限不足
-* 限制范围
-* 应用程序运行时配置错误
+* 限制范围（Limit Ranges）问题
+* 应用程序运行时的配置错误
 
 <!--
- One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
+One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
 ([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denotes the
 number of seconds the Deployment controller waits before indicating (in the Deployment status) that the
 Deployment progress has stalled.
 -->
-检测此条件的一种方法是在 Deployment 规范中指定截止时间参数：（[`.spec.progressDeadlineSeconds`]（#progress-deadline-seconds））。`.spec.progressDeadlineSeconds` 进度截止时间秒表示 Deployment 控制器在指示（处于 Deployment 状态）之前等待的秒数 Deployment 进度已停止。
+检测此状况的一种方法是在 Deployment 规约中指定截止时间参数：
+（[`.spec.progressDeadlineSeconds`]（#progress-deadline-seconds））。
+`.spec.progressDeadlineSeconds` 给出的是一个秒数值，Deployment 控制器在（通过 Deployment 状态）
+标示 Deployment 进展停滞之前，需要等待所给的时长。
 
 <!--
- The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report
+The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report
 lack of progress for a Deployment after 10 minutes:
 -->
-以下 `kubectl` 命令设置具有进度的规范，使控制器报告 10 分钟后 Deployment 进度不足：
+以下 `kubectl` 命令设置规约中的 `progressDeadlineSeconds`，从而告知控制器
+在 10 分钟后报告 Deployment 没有进展：
 
 ```shell
 kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
 ```
 
-<!--
- The output is similar to this:
--->
-输出：
+<!-- The output is similar to this: -->
+输出类似于：
 
-```shell
+```
 deployment.apps/nginx-deployment patched
 ```
 
 <!--
- Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
+Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
 attributes to the Deployment's `.status.conditions`:
 -->
-超过截止时间后， Deployment 控制器将添加具有以下属性到 Deployment 的 `.status.conditions` ：
+超过截止时间后，Deployment 控制器将添加具有以下属性的 DeploymentCondition 到
+Deployment 的 `.status.conditions` 中：
 
 * Type=Progressing
 * Status=False
 * Reason=ProgressDeadlineExceeded
 
 <!--
- See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for more information on status conditions.
+See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for more information on status conditions.
 -->
-参考 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) 获取更多状态条件相关信息。
+参考
+[Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)
+获取更多状态状况相关的信息。
 
-{{< note >}}
 <!--
  Kubernetes takes no action on a stalled Deployment other than to report a status condition with
 `Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
 example, rollback the Deployment to its previous version.
--->
-Kubernetes 对已停止的 Deployment 不执行任何操作，只需使用`Reason=ProgressDeadlineExceeded`。更高级别的编排器可以利用它并相应地采取行动，例如，将 Deployment 回滚到其以前的版本。
-{{< /note >}}
 
+If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
+safely pause a Deployment in the middle of a rollout and resume without triggering the condition for
+exceeding the deadline.
+-->
 {{< note >}}
-<!--
- If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
-safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
-deadline.
--->
-如果暂停 Deployment ，Kubernetes 不会根据指定的截止时间检查进度。可以在展开栏中间安全地暂停 Deployment ，并在不触发超过最后期限时恢复。
+除了报告 `Reason=ProgressDeadlineExceeded` 状态之外，Kubernetes 对已停止的
+Deployment 不执行任何操作。更高级别的编排器可以利用这一设计并相应地采取行动。
+例如，将 Deployment 回滚到其以前的版本。
+
+如果你暂停了某个 Deployment，Kubernetes 不再根据指定的截止时间检查 Deployment 进展。
+你可以在上线过程中间安全地暂停 Deployment 再恢复其执行，这样做不会导致超出最后时限的问题。
 {{< /note >}}
 
 <!--
- You may experience transient errors with your Deployments, either due to a low timeout that you have set or
+You may experience transient errors with your Deployments, either due to a low timeout that you have set or
 due to any other kind of error that can be treated as transient. For example, let's suppose you have
 insufficient quota. If you describe the Deployment you will notice the following section:
 -->
- Deployments 可能会出现短暂的错误，既不是因为设置的超时时间过短，也不是因为任何真正的暂时性错误。例如配额不足。如果描述 Deployment ，将注意到以下部分：
+Deployment 可能会出现瞬时性的错误，可能因为设置的超时时间过短，
+也可能因为其他可认为是临时性的问题。例如，假定所遇到的问题是配额不足。
+如果描述 Deployment，你将会注意到以下部分：
 
 ```shell
 kubectl describe deployment nginx-deployment
 ```
 
-<!--
- The output is similar to this:
--->
-输出：
+<!-- The output is similar to this: -->
+输出类似于：
 
-```shell
+```
 <...>
 Conditions:
   Type            Status  Reason
@@ -1592,11 +1564,12 @@ Conditions:
 ```
 
 <!--
- If you run `kubectl get deployment nginx-deployment -o yaml`, the Deployment status is similar to this:
+If you run `kubectl get deployment nginx-deployment -o yaml`, the Deployment status is similar to this:
 -->
-如果运行 `kubectl get deployment nginx-deployment -o yaml`， Deployment 状态输出：
+如果运行 `kubectl get deployment nginx-deployment -o yaml`，Deployment 状态输出
+将类似于这样：
 
-```shell
+```
 status:
   availableReplicas: 2
   conditions:
@@ -1625,12 +1598,12 @@ status:
 ```
 
 <!--
- Eventually, once the Deployment progress deadline is exceeded, Kubernetes updates the status and the
+Eventually, once the Deployment progress deadline is exceeded, Kubernetes updates the status and the
 reason for the Progressing condition:
 -->
-最终，一旦超过 Deployment 进度截止时间，Kubernetes 将更新状态和进度状态：
+最终，一旦超过 Deployment 进度限期，Kubernetes 将更新状态和进度状况的原因：
 
-```shell
+```
 Conditions:
   Type            Status  Reason
   ----            ------  ------
@@ -1640,14 +1613,16 @@ Conditions:
 ```
 
 <!--
- You can address an issue of insufficient quota by scaling down your Deployment, by scaling down other
+You can address an issue of insufficient quota by scaling down your Deployment, by scaling down other
 controllers you may be running, or by increasing quota in your namespace. If you satisfy the quota
 conditions and the Deployment controller then completes the Deployment rollout, you'll see the
 Deployment's status update with a successful condition (`Status=True` and `Reason=NewReplicaSetAvailable`).
 -->
-可以通过缩减 Deployment 来解决配额不足的问题，或者直接在命名空间中增加配额。如果配额条件满足， Deployment 控制器完成了 Deployment 展开， Deployment 状态会更新为成功（`Status=True` and `Reason=NewReplicaSetAvailable`）。
+可以通过缩容 Deployment 或者缩容其他运行状态的控制器，或者直接在命名空间中增加配额
+来解决配额不足的问题。如果配额条件满足，Deployment 控制器完成了 Deployment 上线操作，
+Deployment 状态会更新为成功状况（`Status=True` and `Reason=NewReplicaSetAvailable`）。
 
-```shell
+```
 Conditions:
   Type          Status  Reason
   ----          ------  ------
@@ -1656,29 +1631,34 @@ Conditions:
 ```
 
 <!--
- `Type=Available` with `Status=True` means that your Deployment has minimum availability. Minimum availability is dictated
+`Type=Available` with `Status=True` means that your Deployment has minimum availability. Minimum availability is dictated
 by the parameters specified in the deployment strategy. `Type=Progressing` with `Status=True` means that your Deployment
 is either in the middle of a rollout and it is progressing or that it has successfully completed its progress and the minimum
 required new replicas are available (see the Reason of the condition for the particulars - in our case
 `Reason=NewReplicaSetAvailable` means that the Deployment is complete).
 -->
-`Type=Available`和 `Status=True` 表示 Deployment 具有最低可用性。最低可用性由 Deployment 策略中的参数指定。`Type=Progressing` 和 `Status=True` 表示 Deployment 处于展开中间，并且正在运行，或者已成功完成进度，最小所需新的副本处于可用（请参阅此种状态原因的相关细节，在我们的案例中`Reason=NewReplicaSetAvailable` 表示 Deployment 已完成）。
+`Type=Available` 加上 `Status=True` 意味着 Deployment 具有最低可用性。
+最低可用性由 Deployment 策略中的参数指定。
+`Type=Progressing` 加上 `Status=True` 表示 Deployment 处于上线过程中，并且正在运行，
+或者已成功完成进度，最小所需新副本处于可用。
+请参阅对应状况的 Reason 了解相关细节。
+在我们的案例中 `Reason=NewReplicaSetAvailable` 表示 Deployment 已完成。
 
 <!--
- You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status`
+You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status`
 returns a non-zero exit code if the Deployment has exceeded the progression deadline.
 -->
-可以使用 `kubectl rollout status` 检查 Deployment 是否未能取得进展。`kubectl rollout status`如果 Deployment 已超过进度截止时间，则返回非零退出代码。
+你可以使用 `kubectl rollout status` 检查 Deployment 是否未能取得进展。
+如果 Deployment 已超过进度限期，`kubectl rollout status` 返回非零退出代码。
 
 ```shell
 kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
-<!--
- The output is similar to this:
--->
-输出：
 
-```shell
+<!-- The output is similar to this: -->
+输出类似于：
+
+```
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 error: deployment "nginx" exceeded its progress deadline
 $ echo $?
@@ -1686,227 +1666,254 @@ $ echo $?
 ```
 
 <!--
- ### Operating on a failed deployment
+### Operating on a failed deployment
+
+All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down,
+roll back to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment
+Pod template.
 -->
-### 对失败 Deployment 的操作
+### 对失败 Deployment 的操作   {#operating-on-a-failed-deployment}
+
+可应用于已完成的 Deployment 的所有操作也适用于失败的 Deployment。
+你可以对其执行扩缩容、回滚到以前的修订版本等操作，或者在需要对 Deployment 的
+Pod 模板应用多项调整时，将 Deployment 暂停。
 
 <!--
- All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back
-to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment Pod template.
--->
-应用于完整 Deployment 的所有操作也适用于失败的 Deployment 。可以向上/向下扩展，回滚到以前的修改版，或者如果需要在 Deployment  Pod 模板中应用多个调整，甚至将其暂停。
+## Clean up Policy
 
-<!--
- ## Clean up Policy
--->
-## 清理策略
-
-<!--
- You can set `.spec.revisionHistoryLimit` field in a Deployment to specify how many old ReplicaSets for
+You can set `.spec.revisionHistoryLimit` field in a Deployment to specify how many old ReplicaSets for
 this Deployment you want to retain. The rest will be garbage-collected in the background. By default,
 it is 10.
 -->
-可以在 Deployment 中设置 `.spec.revisionHistoryLimit` ，以指定保留多少此 Deployment 的 ReplicaSets。其余的将在后台进行垃圾回收。默认情况下，是10。
+## 清理策略   {#clean-up-policy}
+
+你可以在 Deployment 中设置 `.spec.revisionHistoryLimit` 字段以指定保留此
+Deployment 的多少个旧有 ReplicaSet。其余的 ReplicaSet 将在后台被垃圾回收。
+默认情况下，此值为 10。
 
-{{< note >}}
 <!--
  Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
 thus that Deployment will not be able to roll back.
 -->
-显式将此字段设置为 0 将导致清理 Deployment 的所有历史记录，因此 Deployment 将无法回滚。
+{{< note >}}
+显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空，因此 Deployment 将无法回滚。
 {{< /note >}}
 
 <!--
- ## Canary Deployment
--->
-## 金丝雀 Deployment
+## Canary Deployment
 
-<!--
- If you want to roll out releases to a subset of users or servers using the Deployment, you
+If you want to roll out releases to a subset of users or servers using the Deployment, you
 can create multiple Deployments, one for each release, following the canary pattern described in
 [managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
 -->
-如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。
+## 金丝雀部署 {#canary-deployment}
+
+如果要使用 Deployment 向用户子集或服务器子集上线版本，则可以遵循
+[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
+所描述的金丝雀模式，创建多个 Deployment，每个版本一个。
 
 <!--
- ## Writing a Deployment Spec
--->
-## 编写 Deployment 脚本
+## Writing a Deployment Spec
 
-<!--
- As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
+As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
 For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
 configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
 -->
-同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
+## 编写 Deployment 规约       {#writing-a-deployment-spec}
+
+同其他 Kubernetes 配置一样， Deployment 需要 `apiVersion`，`kind` 和 `metadata` 字段。
+有关配置文件的其他信息，请参考
+[部署 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、配置容器和
+[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
 
 <!--
- A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
+The name of a Deployment object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
 -->
- Deployment 还需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
+Deployment 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+Deployment 还需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
 
 <!--
- ### Pod Template
--->
-### Pod 示例
+### Pod Template
 
-<!--
- The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.
+The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.
 -->
-`.spec`仅需要 `.spec.template` 和 `.spec.selector`。
+### Pod 模板     {#pod-template}
+
+`.spec` 中只有 `.spec.template` 和 `.spec.selector` 是必需的字段。
 
 <!--
  The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
 `apiVersion` or `kind`.
 -->
-`.spec.template` 是一个 [Pod 示例](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。
+`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
+它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。
+只是这里它是嵌套的，因此不需要 `apiVersion` 或 `kind`。
 
 <!--
- In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
+In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
 labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
 -->
-除了 Pod 的必填字段外， Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。对于标签，请确保不要与其他控制器重叠。请参考[选择器](#selector))。
+除了 Pod 的必填字段外，Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。
+对于标签，请确保不要与其他控制器重叠。请参考[选择算符](#selector)。
 
 <!--
- Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/#restart-policy) equal to `Always` is
+Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
 allowed, which is the default if not specified.
 -->
-只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。
+只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+等于 `Always` 才是被允许的，这也是在没有指定时的默认设置。
 
 <!--
- ### Replicas
--->
-### 副本
+### Replicas
 
-<!--
- `.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
+`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
 -->
+### 副本   {#replicas}
+
 `.spec.replicas` 是指定所需 Pod 的可选字段。它的默认值是1。
 
 <!--
- ### Selector
--->
-### 选择器
+### Selector
 
-<!--
- `.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
+`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
 for the Pods targeted by this Deployment.
--->
-`.spec.selector` 是指定本次 Deployment  Pods [标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)的必要字段。
 
-<!--
- `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
+`.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
 -->
+### 选择算符   {#selector}
+
+`.spec.selector` 是指定本 Deployment 的 Pod
+[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)的必需字段。
+
 `.spec.selector` 必须匹配 `.spec.template.metadata.labels`，否则请求会被 API 拒绝。
 
 <!--
  In API version `apps/v1`, `.spec.selector` and `.metadata.labels` do not default to `.spec.template.metadata.labels` if not set. So they must be set explicitly. Also note that `.spec.selector` is immutable after creation of the Deployment in `apps/v1`.
 -->
-在 API `apps/v1`版本中，`.spec.selector` 和 `.metadata.labels` 不会被默认设置为 `.spec.template.metadata.labels`，如果没有设置的话。所以需要明确进行设置。同时在 `apps/v1`版本中， Deployment 创建后 `.spec.selector` 是可变的。
+在 API `apps/v1`版本中，`.spec.selector` 和 `.metadata.labels` 如果没有设置的话，
+不会被默认设置为 `.spec.template.metadata.labels`，所以需要明确进行设置。
+同时在 `apps/v1`版本中，Deployment 创建后 `.spec.selector` 是不可变的。
 
 <!--
- A Deployment may terminate Pods whose labels match the selector if their template is different
+A Deployment may terminate Pods whose labels match the selector if their template is different
 from `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new
 Pods with `.spec.template` if the number of Pods is less than the desired number.
 -->
-当 Pods 的标签和选择器匹配时，此类 Pods 的模板和 `.spec.template` 不同，或者此类 Pods 的总数超过 `.spec.replicas`， Deployment 会终结这些 Pods。如果 Pods 总数达不到期望值，会用 `.spec.template` 创建新的 Pods。
+当 Pod 的标签和选择算符匹配，但其模板和 `.spec.template` 不同时，或者此类 Pod
+的总数超过 `.spec.replicas` 的设置时，Deployment 会终结之。
+如果 Pods 总数未达到期望值，Deployment 会基于 `.spec.template` 创建新的 Pod。
 
-{{< note >}}
 <!--
- You should not create other Pods whose labels match this selector, either directly, by creating
+You should not create other Pods whose labels match this selector, either directly, by creating
 another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
 do so, the first Deployment thinks that it created these other Pods. Kubernetes does not stop you from doing this.
 -->
-不应创建其标签与此选择器匹配的 Pods，或者直接创建另一个 Deployment ，或通过创建其他控制器（如 ReplicaSet 或复制控制器）。如果这样做，第一个 Deployment 认为它创建了这些其他 Pods。Kubernetes 不会阻止你这么做。
+{{< note >}}
+你不应直接创建、或者通过创建另一个 Deployment，或者创建类似 ReplicaSet
+或 ReplicationController 这类控制器来创建标签与此选择算符匹配的 Pod。
+如果这样做，第一个 Deployment 会认为它创建了这些 Pod。
+Kubernetes 不会阻止你这么做。
 {{< /note >}}
 
 <!--
- If you have multiple controllers that have overlapping selectors, the controllers will fight with each
+If you have multiple controllers that have overlapping selectors, the controllers will fight with each
 other and won't behave correctly.
 -->
-如果有多个具有重叠选择器的控制器，则控制器之间会因冲突而故障。
+如果有多个控制器的选择算符发生重叠，则控制器之间会因冲突而无法正常工作。
 
 <!--
- ### Strategy
--->
-### 策略
-<!--
- `.spec.strategy` specifies the strategy used to replace old Pods by new ones.
+### Strategy
+
+`.spec.strategy` specifies the strategy used to replace old Pods by new ones.
 `.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is
 the default value.
 -->
-`.spec.strategy` 策略指定用于用新 Pods 替换旧 Pods 的策略。`.spec.strategy.type` 可以是“Recreate”或“RollingUpdate”。“RollingUpdate”是默认值。
+### 策略   {#strategy}
+
+`.spec.strategy` 策略指定用于用新 Pods 替换旧 Pods 的策略。
+`.spec.strategy.type` 可以是 “Recreate” 或 “RollingUpdate”。“RollingUpdate” 是默认值。
 
 <!--
- #### Recreate Deployment
+#### Recreate Deployment
+
+All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`.
 -->
-#### 重新创建 Deployment
+#### 重新创建 Deployment   {#recreate-deployment}
+
+如果 `.spec.strategy.type==Recreate`，在创建新 Pods 之前，所有现有的 Pods 会被杀死。
 
 <!--
- All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`.
--->
-当 `.spec.strategy.type==Recreate`,所有现有的 Pods 在创建新 Pods 之前被杀死。
+#### Rolling Update Deployment
 
-<!--
- #### Rolling Update Deployment
--->
-#### 滚动更新 Deployment
-
-<!--
- The Deployment updates Pods in a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)
+The Deployment updates Pods in a rolling update
 fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
 the rolling update process.
 -->
- Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取滚动更新的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
+#### 滚动更新 Deployment   {#rolling-update-deployment}
+
+Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取
+滚动更新的方式更新 Pods。你可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新
+过程。
 
 <!--
- ##### Max Unavailable
+##### Max Unavailable
 -->
-##### 最大不可用
+##### 最大不可用   {#max-unavailable}
 
 <!--
- `.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number
+`.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number
 of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5)
 or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by
 rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%.
 -->
-`.spec.strategy.rollingUpdate.maxUnavailable` 是指定最大数量的可选字段，表示在更新过程中不可用的 Pods。该值可以是绝对数字（例如，5）或所需 Pods 的百分比（例如，10%）。绝对数按百分比计算，四舍五入下来。如果 `.spec.strategy.rollingUpdate.maxSurge` 为 0，则该值不能为 0。默认值为 25%。
+`.spec.strategy.rollingUpdate.maxUnavailable` 是一个可选字段，用来指定
+更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是
+所需 Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。
+如果 `.spec.strategy.rollingUpdate.maxSurge` 为 0，则此值不能为 0。
+默认值为 25%。
 
 <!--
- For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired
+For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired
 Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled
 down further, followed by scaling up the new ReplicaSet, ensuring that the total number of Pods available
 at all times during the update is at least 70% of the desired Pods.
 -->
-例如，当此值设置为 30% 时，滚动更新开始时会立即将旧 ReplicaSet 向下扩展到期望 Pods 的70%。新 Pods 准备就绪后，可以缩放旧 ReplicaSet 进一步向下，然后向上扩展新的 ReplicaSet ，确保可用的 Pods 总数在更新期间，任何时候都至少为 70% 所需的 Pods。
+例如，当此值设置为 30% 时，滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。
+新 Pod 准备就绪后，可以继续缩容旧有的 ReplicaSet，然后对新的 ReplicaSet 扩容，确保在更新期间
+可用的 Pods 总数在任何时候都至少为所需的 Pod 个数的 70%。
 
 <!--
- ##### Max Surge
--->
-##### 最大增量
+##### Max Surge
 
-<!--
  `.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
 that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a
 percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
 is calculated from the percentage by rounding up. The default value is 25%.
 -->
-`.spec.strategy.rollingUpdate.maxSurge`  是指定最大 Pods 数的可选字段可在所需的 Pods 数上创建。该值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。如果 `MaxUnavailable` 0，则值不能为 0。绝对数通过舍入从百分比计算。默认值为 25%。
+##### 最大峰值   {#max-surge}
+
+`.spec.strategy.rollingUpdate.maxSurge` 是一个可选字段，用来指定可以创建的超出
+期望 Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。
+如果 `MaxUnavailable` 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。
+此字段的默认值为 25%。
 
 <!--
- For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the
+For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the
 rolling update starts, such that the total number of old and new Pods does not exceed 130% of desired
 Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the
 total number of Pods running at any time during the update is at most 130% of desired Pods.
 -->
-例如，当此值设置为 30% 时，启动滚动更新后，会立即展开新的 ReplicaSet ，以便新旧 Pod 的总数不超过所需的 130%。一旦旧 Pods 被杀死，新的 ReplicaSet 可以进一步扩展，确保更新期间任何时间运行的 Pods 总数最多为所需 Pods 总数的130%。
+例如，当此值为 30% 时，启动滚动更新后，会立即对新的 ReplicaSet 扩容，同时保证新旧 Pod
+的总数不超过所需 Pod 总数的 130%。一旦旧 Pods 被杀死，新的 ReplicaSet 可以进一步扩容，
+同时确保更新期间的任何时候运行中的 Pods 总数最多为所需 Pods 总数的 130%。
 
 <!--
  ### Progress Deadline Seconds
--->
-###  Deployment 失败等待时间
 
-<!--
  `.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
 to wait for your Deployment to progress before the system reports back that the Deployment has
 [failed progressing](#failed-deployment) - surfaced as a condition with `Type=Progressing`, `Status=False`.
@@ -1914,89 +1921,70 @@ and `Reason=ProgressDeadlineExceeded` in the status of the resource. The Deploym
 retrying the Deployment. In the future, once automatic rollback will be implemented, the Deployment
 controller will roll back a Deployment as soon as it observes such a condition.
 -->
-`.spec.progressDeadlineSeconds` 是一个可选字段，用于指定等待的秒数而后在系统报告中返回[ Deployment 失败](#failed-deployment)，同时在资源状态中 `Type=Progressing`、 `Status=False` 、 `Reason=ProgressDeadlineExceeded` 。  Deployment 控制器将保留正在重试 Deployment 。将来，一旦实现自动回滚， Deployment 控制器将回滚 Deployment ，只要它探测到这样的条件。
+### 进度期限秒数    {#progress-deadline-seconds}
+ 
+`.spec.progressDeadlineSeconds` 是一个可选字段，用于指定系统在报告 Deployment
+[进展失败](#failed-deployment) 之前等待 Deployment 取得进展的秒数。
+这类报告会在资源状态中体现为 `Type=Progressing`、`Status=False`、
+`Reason=ProgressDeadlineExceeded`。Deployment 控制器将持续重试 Deployment。
+将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。
 
 <!--
- If specified, this field needs to be greater than `.spec.minReadySeconds`.
+If specified, this field needs to be greater than `.spec.minReadySeconds`.
 -->
-如果指定，则此字段需要大于 `.spec.minReadySeconds`。
+如果指定，则此字段值需要大于 `.spec.minReadySeconds` 取值。
 
 <!--
- ### Min Ready Seconds
--->
-### 最小就绪时间
+### Min Ready Seconds
 
-<!--
  `.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
 created Pod should be ready without any of its containers crashing, for it to be considered available.
 This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
 a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
 -->
-`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+### 最短就绪时间    {#min-ready-seconds}
+
+`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，
+只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。
+要了解何时 Pod 被视为就绪，可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
 
 <!--
- ### Rollback To
+### Revision History Limit
+
+A Deployment's revision history is stored in the ReplicaSets it controls.
 -->
-### 回滚
+### 修订历史限制
+
+Deployment 的修订历史记录存储在它所控制的 ReplicaSets 中。
 
 <!--
- Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
--->
-`.spec.rollbackTo` 字段已经在 API 版本 `extensions/v1beta1` 和 `apps/v1beta1`中废弃了，并且从 `apps/v1beta2`版本开始不在支持。相应的，会开始使用已经引入[回滚到上一个版本](#rolling-back-to-a-previous-revision)中的 `kubectl rollout undo`。
-
-<!--
- ### Revision History Limit
--->
-### 修改历史限制
-
-<!--
- A Deployment's revision history is stored in the ReplicaSets it controls.
--->
- Deployment 修改历史记录存储在它所控制的 ReplicaSets 中。
-
-<!--
- `.spec.revisionHistoryLimit` is an optional field that specifies the number of old ReplicaSets to retain
+`.spec.revisionHistoryLimit` is an optional field that specifies the number of old ReplicaSets to retain
 to allow rollback. These old ReplicaSets consume resources in `etcd` and crowd the output of `kubectl get rs`. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment. By default, 10 old ReplicaSets will be kept, however its ideal value depends on the frequency and stability of new Deployments.
 -->
-`.spec.revisionHistoryLimit` 修改历史记录限制是一个可选字段，用于指定要保留的旧 ReplicaSets 的数量以允许回滚。这些旧 ReplicaSets 消耗 etcd 中的资源，并占用 `kubectl get rs` 的输出。每个 Deployment 修改版的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet ，将失去回滚到 Deployment 版本的能力。默认情况下，将保留 10 个旧 ReplicaSets ，但其理想值取决于新 Deployment 的频率和稳定性。
+`.spec.revisionHistoryLimit` 是一个可选字段，用来设定出于会滚目的所要保留的旧 ReplicaSet 数量。
+这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 `kubectl get rs` 的输出。
+每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet，
+将失去回滚到 Deployment 的对应修订版本的能力。
+默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。
 
 <!--
- More specifically, setting this field to zero means that all old ReplicaSets with 0 replicas will be cleaned up.
+More specifically, setting this field to zero means that all old ReplicaSets with 0 replicas will be cleaned up.
 In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up.
 -->
-更具体地说，将此字段设置为 0 意味着将清理所有具有 0 个副本的旧 ReplicaSets 。在这种情况下，无法撤消新的 Deployment 展开，因为它的修改历史被清除了。
+更具体地说，将此字段设置为 0 意味着将清理所有具有 0 个副本的旧 ReplicaSet。
+在这种情况下，无法撤消新的 Deployment 上线，因为它的修订历史被清除了。
 
 <!--
- ### Paused
--->
-### 暂停
+### Paused
 
-<!--
- `.spec.paused` is an optional boolean field for pausing and resuming a Deployment. The only difference between
+`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. The only difference between
 a paused Deployment and one that is not paused, is that any changes into the PodTemplateSpec of the paused
 Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
 it is created.
 -->
-`.spec.paused` 是用于暂停和恢复 Deployment 的可选布尔字段。暂停的 Deployment 和未暂停的 Deployment 唯一的区别，只要暂停 Deployment 处于暂停状态， PodTemplateSpec 的任意修改都不会触发新的展开。默认 Deployment 在创建时是不会被暂停的。
-
-<!--
- ## Alternative to Deployments
--->
-##  Deployments 的替代方案
-
-<!--
- ### kubectl rolling update
--->
-### kubectl滚动更新
-
-<!--
- [`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) updates Pods and ReplicationControllers
--->
-
-<!--
- in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
-additional features, such as rolling back to any previous revision even after the rolling update is done.
--->
-[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)更新 Pods 和副本控制器的方式类似。但是，建议采取 Deployments 的方式来更新，因为它们是声明性的，在服务器端，并且具有其他功能，例如，即使在滚动更新完成后，也会回滚到以前的任何修改版本。
-
+### paused（暂停的）  {#paused}
 
+`.spec.paused` 是用于暂停和恢复 Deployment 的可选布尔字段。
+暂停的 Deployment 和未暂停的 Deployment 的唯一区别是，Deployment 处于暂停状态时，
+PodTemplateSpec 的任何修改都不会触发新的上线。
+Deployment 在创建时是默认不会处于暂停状态。
diff --git a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
index 0c34eda433..e1d076f764 100644
--- a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md
@@ -1,13 +1,13 @@
 ---
 title: 垃圾收集
 content_type: concept
-weight: 70
+weight: 60
 ---
 
 <!--
 title: Garbage Collection
 content_type: concept
-weight: 70
+weight: 60
 -->
 
 <!-- overview -->
diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md
index 513591b317..6690a96d13 100644
--- a/content/zh/docs/concepts/workloads/controllers/job.md
+++ b/content/zh/docs/concepts/workloads/controllers/job.md
@@ -5,7 +5,7 @@ feature:
   title: 批量执行
   description: >
     除了服务之外，Kubernetes 还可以管理你的批处理和 CI 工作负载，在期望时替换掉失效的容器。
-weight: 60
+weight: 50
 ---
 <!--
 reviewers:
@@ -17,7 +17,7 @@ feature:
   title: Batch execution
   description: >
     In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
-weight: 60
+weight: 50
 -->
 
 <!-- overview -->
diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md
index 60fb6bc36d..4446ad496b 100644
--- a/content/zh/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md
@@ -1,8 +1,17 @@
 ---
 title: ReplicaSet
 content_type: concept
-weight: 10
+weight: 20
 ---
+<!--
+reviewers:
+- Kashomon
+- bprashanth
+- madhusudancs
+title: ReplicaSet
+content_type: concept
+weight: 20
+-->
 
 <!-- overview -->
 
@@ -18,30 +27,25 @@ ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 
 <!--
 ## How a ReplicaSet works
 
-A ReplicaSet is defined with fields, including a selector that specifies how
-to identify Pods it can acquire, a number of replicas indicating how many Pods
-it should be maintaining, and a pod template specifying the data of new Pods
-it should create to meet the number of replicas criteria. A ReplicaSet then
-fulfills its purpose by creating and deleting Pods as needed to reach the
-desired number. When a ReplicaSet needs to create new Pods, it uses its Pod
+A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number
+of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods
+it should create to meet the number of replicas criteria. A ReplicaSet then fulfills its purpose by creating
+and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod
 template.
 -->
 ## ReplicaSet 的工作原理 {#how-a-replicaset-works}
 
 RepicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod
-的集合的选择算符，一个用来标明应该维护的副本个数的数值，一个用来指定应该创建新 Pod
-以满足副本个数条件时要使用的 Pod 模板等等。每个 ReplicaSet 都通过根据需要创建和
-删除 Pod 以使得副本个数达到期望值，进而实现其存在价值。当 ReplicaSet 需要创建
-新的 Pod 时，会使用所提供的 Pod 模板。
+的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod
+以满足副本个数条件时要使用的 Pod 模板等等。
+每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值，
+进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。
 
 <!--
-A ReplicaSet is linked to its Pods via the Pods'
-[metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
-field, which specifies what resource the current object is owned by. All Pods
-acquired by a ReplicaSet have their owning ReplicaSet's identifying
-information within their ownerReferences field. It's through this link that
-the ReplicaSet knows of the state of the Pods it is maintaining and plans
-accordingly.
+A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
+field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning
+ReplicaSet's identifying information within their ownerReferences field. It's through this link that the ReplicaSet
+knows of the state of the Pods it is maintaining and plans accordingly.
 -->
 ReplicaSet 通过 Pod 上的
 [metadata.ownerReferences](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
@@ -51,41 +55,14 @@ ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 R
 并据此计划其操作行为。
 
 <!--
-A ReplicaSet identifies new Pods to acquire by using its selector. If there is
-a Pod that has no OwnerReference or the OwnerReference is not a {{<
-glossary_tooltip term_id="controller" >}} and it matches a ReplicaSet's
-selector, it will be immediately acquired by said ReplicaSet.
+A ReplicaSet identifies new Pods to acquire by using its selector. If there is a Pod that has no OwnerReference or the
+OwnerReference is not a {{< glossary_tooltip term_id="controller" >}} and it matches a ReplicaSet's selector, it will be immediately acquired by said ReplicaSet.
 -->
 ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有
 OwnerReference 或者其 OwnerReference 不是一个 
 {{< glossary_tooltip text="控制器" term_id="controller" >}}，且其匹配到
 某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。
 
-<!--
-## How to use a ReplicaSet
-
-Most [`kubectl`](/docs/user-guide/kubectl/) commands that support
-Replication Controllers also support ReplicaSets. One exception is the
-[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) command. If
-you want the rolling update functionality please consider using Deployments
-instead. Also, the
-[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) command is
-imperative whereas Deployments are declarative, so we recommend using Deployments
-through the [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout) command.
-
-While ReplicaSets can be used independently, today it's mainly used by
-[Deployments](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate pod
-creation, deletion and updates. When you use Deployments you don't have to worry
-about managing the ReplicaSets that they create. Deployments own and manage
-their ReplicaSets.
--->
-## 怎样使用 ReplicaSet   {#how-to-use-a-replicaset}
-
-大多数支持 Replication Controllers 的[`kubectl`](/zh/docs/reference/kubectl/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
-
-虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
-当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。
-
 <!--
 ## When to use a ReplicaSet
 
@@ -98,14 +75,16 @@ you require custom update orchestration or don't require updates at all.
 This actually means that you may never need to manipulate ReplicaSet objects:
 use a Deployment instead, and define your application in the spec section.
 -->
-
-## 什么时候使用 ReplicaSet
+## 何时使用 ReplicaSet
 
 ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
-然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。
-因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet，除非您需要自定义更新业务流程或根本不需要更新。
+然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod
+提供声明式的更新以及许多其他有用的功能。
+因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet，除非
+你需要自定义更新业务流程或根本不需要更新。
 
-这实际上意味着，您可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义您的应用。
+这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用
+Deployment，并在 spec 部分定义你的应用。
 
 <!--
 ## Example
@@ -118,151 +97,349 @@ ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
 Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes cluster should
 create the defined ReplicaSet and the pods that it manages.
 -->
+将此清单保存到 `frontend.yaml` 中，并将其提交到 Kubernetes 集群，
+应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。
 
-将此清单保存到 `frontend.yaml` 中，并将其提交到 Kubernetes 集群，应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。
 
 ```shell
-$ kubectl create -f http://k8s.io/examples/controllers/frontend.yaml
-replicaset.apps/frontend created
-$ kubectl describe rs/frontend
+kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
+```
+
+<!--
+You can then get the current ReplicaSets deployed:
+-->
+你可以看到当前被部署的 ReplicaSet：
+
+```shell
+kubectl get rs
+```
+
+<!--
+And see the frontend one you created:
+-->
+并看到你所创建的前端：
+
+```
+NAME       DESIRED   CURRENT   READY   AGE
+frontend   3         3         3       6s
+```
+
+<!--
+You can also check on the state of the ReplicaSet:
+-->
+你也可以查看 ReplicaSet 的状态：
+
+```shell
+kubectl describe rs/frontend
+```
+
+<!--
+And you will see output similar to:
+-->
+你会看到类似如下的输出：
+
+```
 Name:		frontend
 Namespace:	default
-Selector:	tier=frontend,tier in (frontend)
+Selector:	tier=frontend
 Labels:		app=guestbook
 		tier=frontend
-Annotations:	<none>
+Annotations:  kubectl.kubernetes.io/last-applied-configuration:
+                {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
 Replicas:	3 current / 3 desired
 Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
 Pod Template:
-  Labels:       app=guestbook
-                tier=frontend
+  Labels:       tier=frontend
   Containers:
    php-redis:
     Image:      gcr.io/google_samples/gb-frontend:v3
-    Port:       80/TCP
-    Requests:
-      cpu:      100m
-      memory:   100Mi
-    Environment:
-      GET_HOSTS_FROM:   dns
+    Port:         <none>
+    Host Port:    <none>
+    Environment:  <none>
     Mounts:             <none>
   Volumes:              <none>
 Events:
-  FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
-  ---------    --------    -----    ----                -------------    --------    ------            -------
-  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-qhloh
-  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-dnjpy
-  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-9si5l
-$ kubectl get pods
-NAME             READY     STATUS    RESTARTS   AGE
-frontend-9si5l   1/1       Running   0          1m
-frontend-dnjpy   1/1       Running   0          1m
-frontend-qhloh   1/1       Running   0          1m
+  Type    Reason            Age   From                   Message
+  ----    ------            ----  ----                   -------
+  Normal  SuccessfulCreate  117s  replicaset-controller  Created pod: frontend-wtsmm
+  Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-b2zdv
+  Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-vcmts
 ```
 
+<!--
+And lastly you can check for the Pods brought up:
+-->
+最后可以查看启动了的 Pods：
+
+```shell
+kubectl get pods
+```
+
+<!--
+You should see Pod information similar to:
+-->
+你会看到类似如下的 Pod 信息：
+
+```
+NAME             READY   STATUS    RESTARTS   AGE
+frontend-b2zdv   1/1     Running   0          6m36s
+frontend-vcmts   1/1     Running   0          6m36s
+frontend-wtsmm   1/1     Running   0          6m36s
+```
+
+<!--
+You can also verify that the owner reference of these pods is set to the frontend ReplicaSet.
+To do this, get the yaml of one of the Pods running:
+-->
+你也可以查看 Pods 的属主引用被设置为前端的 ReplicaSet。
+要实现这点，可取回运行中的 Pods 之一的 YAML：
+
+```shell
+kubectl get pods frontend-b2zdv -o yaml
+```
+
+<!--
+The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field:
+-->
+输出将类似这样，frontend ReplicaSet 的信息被设置在 metadata 的
+`ownerReferences` 字段中：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  creationTimestamp: "2020-02-12T07:06:16Z"
+  generateName: frontend-
+  labels:
+    tier: frontend
+  name: frontend-b2zdv
+  namespace: default
+  ownerReferences:
+  - apiVersion: apps/v1
+    blockOwnerDeletion: true
+    controller: true
+    kind: ReplicaSet
+    name: frontend
+    uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
+...
+```
+
+<!--
+## Non-Template Pod acquisitions
+
+While you can create bare Pods with no problems, it is strongly recommended to make sure that the bare Pods do not have
+labels which match the selector of one of your ReplicaSets. The reason for this is because a ReplicaSet is not limited
+to owning Pods specified by its template - it can acquire other Pods in the manner specified in the previous sections.
+-->
+## 非模板 Pod 的获得
+
+<!--
+While you can create bare Pods with no problems, it is strongly recommended to
+make sure that the bare Pods do not have labels which match the selector of
+one of your ReplicaSets. The reason for this is because a ReplicaSet is not
+limited to owning Pods specified by its template - it can acquire other Pods
+in the manner specified in the previous sections.
+
+Take the previous frontend ReplicaSet example, and the Pods specified in the
+following manifest:
+-->
+尽管你完全可以直接创建裸的 Pods，强烈建议你确保这些裸的 Pods 并不包含可能与你
+的某个 ReplicaSet 的选择算符相匹配的标签。原因在于 ReplicaSet 并不仅限于拥有
+在其模板中设置的 Pods，它还可以像前面小节中所描述的那样获得其他 Pods。
+
+{{< codenew file="pods/pod-rs.yaml" >}}
+
+<!--
+As those Pods do not have a Controller (or any object) as their owner reference and match the selector of the frontend
+ReplicaSet, they will immediately be acquired by it.
+
+Suppose you create the Pods after the frontend ReplicaSet has been deployed and has set up its initial Pod replicas to
+fulfill its replica count requirement:
+-->
+由于这些 Pod 没有控制器（Controller，或其他对象）作为其属主引用，并且
+其标签与 frontend ReplicaSet 的选择算符匹配，它们会立即被该 ReplicaSet
+获取。
+
+假定你在 frontend ReplicaSet 已经被部署之后创建 Pods，并且你已经在 ReplicaSet
+中设置了其初始的 Pod 副本数以满足其副本计数需要：
+
+```shell
+kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
+```
+
+<!--
+The new Pods will be acquired by the ReplicaSet, and then immediately terminated as the ReplicaSet would be over
+its desired count.
+
+Fetching the Pods:
+-->
+新的 Pods 会被该 ReplicaSet 获取，并立即被 ReplicaSet 终止，因为
+它们的存在会使得 ReplicaSet 中 Pod 个数超出其期望值。
+
+取回 Pods：
+
+
+```shell
+kubectl get pods
+```
+
+<!--
+The output shows that the new Pods are either already terminated, or in the process of being terminated:
+-->
+输出显示新的 Pods 或者已经被终止，或者处于终止过程中：
+
+```shell
+NAME             READY   STATUS        RESTARTS   AGE
+frontend-b2zdv   1/1     Running       0          10m
+frontend-vcmts   1/1     Running       0          10m
+frontend-wtsmm   1/1     Running       0          10m
+pod1             0/1     Terminating   0          1s
+pod2             0/1     Terminating   0          1s
+```
+
+<!--
+If you create the Pods first:
+-->
+如果你先行创建 Pods：
+
+```shell
+kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
+```
+
+<!--
+And then create the ReplicaSet however:
+-->
+之后再创建 ReplicaSet：
+
+```shell
+kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
+```
+
+<!--
+You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the
+number of its new Pods and the original matches its desired count. As fetching the Pods:
+-->
+你会看到 ReplicaSet 已经获得了该 Pods，并仅根据其规约创建新的 Pods，直到
+新的 Pods 和原来的 Pods 的总数达到其预期个数。
+这时取回 Pods：
+
+```shell
+kubectl get pods
+```
+
+<!--
+Will reveal in its output:
+-->
+将会生成下面的输出：
+
+```
+NAME             READY   STATUS    RESTARTS   AGE
+frontend-hmmj2   1/1     Running   0          9s
+pod1             1/1     Running   0          36s
+pod2             1/1     Running   0          36s
+```
+
+采用这种方式，一个 ReplicaSet 中可以包含异质的 Pods 集合。
+
 <!--
 ## Writing a ReplicaSet Spec
 
-As with all other Kubernetes API objects, a ReplicaSet needs the `apiVersion`, `kind`, and `metadata` fields.  For
-general information about working with manifests, see [object management using kubectl](/docs/concepts/overview/object-management-kubectl/overview/).
+As with all other Kubernetes API objects, a ReplicaSet needs the `apiVersion`, `kind`, and `metadata` fields.
+For ReplicaSets, the kind is always just ReplicaSet.
+In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
+Refer to the first lines of the `frontend.yaml` example for guidance.
+
+The name of a ReplicaSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
 -->
+## 编写 ReplicaSet 的 spec
 
-## 编写 ReplicaSet Spec
+与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。
+对于 ReplicaSets 而言，其 kind 始终是 ReplicaSet。
+在 Kubernetes 1.9 中，ReplicaSet 上的 API 版本 `apps/v1` 是其当前版本，且被
+默认启用。API 版本 `apps/v1beta2` 已被废弃。
+参考 `frontend.yaml` 示例的第一行。
 
-与所有其他 Kubernetes API 对象一样，ReplicaSet  也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/zh/docs/concepts/overview/working-with-objects/object-management/)。
+ReplicaSet 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
 
-ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。
+ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)
+部分。
 
 <!--
 ### Pod Template
 
-The `.spec.template` is the only required field of the `.spec`. The `.spec.template` is a 
-[pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a 
-[pod](/docs/concepts/workloads/pods/pod/), except that it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates) which is also
+required to have labels in place. In our `frontend.yaml` example we had one label: `tier: frontend`.
+Be careful not to overlap with the selectors of other controllers, lest they try to adopt this Pod.
 
-In addition to required fields of a pod, a pod template in a ReplicaSet must specify appropriate
-labels and an appropriate restart policy.
-
-For labels, make sure to not overlap with other controllers. For more information, see [pod selector](#pod-selector).
-
-For [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), the only allowed value for `.spec.template.spec.restartPolicy` is `Always`, which is the default.
-
-For local container restarts, ReplicaSet delegates to an agent on the node,
-for example the [Kubelet](/docs/admin/kubelet/) or Docker.
+For the template's [restart policy](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) field,
+`.spec.template.spec.restartPolicy`, the only allowed value is `Always`, which is the default.
 -->
-
 ### Pod 模版
 
-`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
+`.spec.template` 是一个[Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)，
+要求设置标签。在 `frontend.yaml` 示例中，我们指定了标签 `tier: frontend`。
+注意不要将标签与其他控制器的选择算符重叠，否则那些控制器会尝试收养此 Pod。
 
-除了所需的 Pod 字段之外，ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。
-
-对于标签，请确保不要与其他控制器重叠。更多信息请参考 [Pod 选择器](#pod-selector)。
-
-对于 [重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
-
-对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker 去执行。
+对于模板的[重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+字段，`.spec.template.spec.restartPolicy`，唯一允许的取值是 `Always`，这也是默认值.
 
 <!--
 ### Pod Selector
 
-The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/). A ReplicaSet
-manages all the pods with labels that match the selector. It does not distinguish
-between pods that it created or deleted and pods that another person or process created or
-deleted. This allows the ReplicaSet to be replaced without affecting the running pods.
+The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/). As discussed
+[earlier](#how-a-replicaset-works) these are the labels used to identify potential Pods to acquire. In our
+`frontend.yaml` example, the selector was:
 
-The `.spec.template.metadata.labels` must match the `.spec.selector`, or it will
+```yaml
+matchLabels:
+  tier: frontend
+```
+
+In the ReplicaSet, `.spec.template.metadata.labels` must match `spec.selector`, or it will
 be rejected by the API.
-
-In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
 -->
+### Pod 选择算符   {#pod-selector}
 
-### Pod 选择器
+`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
+如前文中[所讨论的](how-a-replicaset-works)，这些是用来标识要被获取的 Pods
+的标签。在签名的 `frontend.yaml` 示例中，选择算符为：
 
-`.spec.selector` 字段是[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
+```yaml
+matchLabels:
+  tier: frontend
+```
 
-`.spec.template.metadata.labels` 必须匹配 `.spec.selector`，否则它将被 API 拒绝。
+在 ReplicaSet 中，`.spec.template.metadata.labels` 的值必须与 `spec.selector` 值
+相匹配，否则该配置会被 API 拒绝。
 
-Kubernetes 1.9 版本中，API 版本 `apps/v1` 中的 ReplicaSet 类型的版本是当前版本并默认开启。API 版本 `apps/v1beta2` 被弃用。
+{{< note >}}
+<!--
+For 2 ReplicaSets specifying the same `.spec.selector` but different `.spec.template.metadata.labels` and `.spec.template.spec` fields, each ReplicaSet ignores the Pods created by the other ReplicaSet.
+-->
+对于设置了相同的 `.spec.selector`，但 
+`.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的
+两个 ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所
+创建的 Pods。
+{{< /note >}}
 
 <!--
-Also you should not normally create any pods whose labels match this selector, either directly, with 
-another ReplicaSet, or with another controller such as a Deployment. If you do so, the ReplicaSet thinks that it 
-created the other pods. Kubernetes does not stop you from doing this.
-
-If you do end up with multiple controllers that have overlapping selectors, you
-will have to manage the deletion yourself.
--->
-
-另外，通常您不应该创建标签与此选择器匹配的任何 Pod，或者直接与另一个 ReplicaSet 或另一个控制器（如 Deployment）标签匹配的任何 Pod。
-如果你这样做，ReplicaSet 会认为它创造了其他 Pod。Kubernetes 并不会阻止您这样做。
-
-如果您最终使用了多个具有重叠选择器的控制器，则必须自己负责删除。
-
-<!--
-### Labels on a ReplicaSet
-
-The ReplicaSet can itself have labels (`.metadata.labels`).  Typically, you
-would set these the same as the `.spec.template.metadata.labels`.  However, they are allowed to be
-different, and the `.metadata.labels` do not affect the behavior of the ReplicaSet.
-
 ### Replicas
 
-You can specify how many pods should run concurrently by setting `.spec.replicas`. The number running at any time may be higher
-or lower, such as if the replicas were just increased or decreased, or if a pod is gracefully
-shut down, and a replacement starts early.
+You can specify how many Pods should run concurrently by setting `.spec.replicas`. The ReplicaSet will create/delete
+its Pods to match this number.
 
 If you do not specify `.spec.replicas`, then it defaults to 1.
 -->
-
 ### Replicas
 
-通过设置 `.spec.replicas` 您可以指定要同时运行多少个 Pod。
-在任何时间运行的 Pod 数量可能高于或低于 `.spec.replicas` 指定的数量，例如在副本刚刚被增加或减少后、或者 Pod 正在被优雅地关闭、以及替换提前开始。
+你可以通过设置 `.spec.replicas` 来指定要同时运行的 Pod 个数。
+ReplicaSet 创建、删除 Pods 以与此值匹配。
 
-如果您没有指定 `.spec.replicas`, 那么默认值为 1。
+如果你没有指定 `.spec.replicas`, 那么默认值为 1。
 
 <!--
 ## Working with ReplicaSets
@@ -273,58 +450,63 @@ To delete a ReplicaSet and all of its Pods, use [`kubectl delete`](/docs/referen
 
 When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Background` or `Foreground` in delete option. e.g. :
 -->
-
-## 使用 ReplicaSets 的具体方法
+## 使用 ReplicaSets
 
 ### 删除 ReplicaSet 和它的 Pod
 
-要删除 ReplicaSet 和它的所有 Pod，使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
-默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
+要删除 ReplicaSet 和它的所有 Pod，使用
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
+默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/)
+自动删除所有依赖的 Pod。
 
-当使用 REST API 或 `client-go` 库时，您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如：
+当使用 REST API 或 `client-go` 库时，你必须在删除选项中将 `propagationPolicy`
+设置为 `Background` 或 `Foreground`。例如：
 
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
-> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-> -H "Content-Type: application/json"
+   -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+   -H "Content-Type: application/json"
 ```
 
 <!--
 ### Deleting just a ReplicaSet
 
-You can delete a ReplicaSet without affecting any of its pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=false` option.
-When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`, e.g. :
+You can delete a ReplicaSet without affecting any of its pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `-cascade=false` option.
+When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`.
+For example:
 -->
-
 ### 只删除 ReplicaSet
 
-您可以只删除 ReplicaSet 而不影响它的 Pod，方法是使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令并设置 `--cascade=false` 选项。
+你可以只删除 ReplicaSet 而不影响它的 Pod，方法是使用
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)
+命令并设置 `--cascade=false` 选项。
 
-当使用 REST API 或 `client-go` 库时，您必须将 `propagationPolicy` 设置为 `Orphan`。例如：
+当使用 REST API 或 `client-go` 库时，你必须将 `propagationPolicy` 设置为 `Orphan`。
+例如：
 
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
-> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-> -H "Content-Type: application/json"
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+  -H "Content-Type: application/json"
 ```
 
 <!--
 Once the original is deleted, you can create a new ReplicaSet to replace it.  As long
 as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
 However, it will not make any effort to make existing pods match a new, different pod template.
-To update pods to a new spec in a controlled way, use a [rolling update](#rolling-updates).
+To update Pods to a new spec in a controlled way, use a
+[Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), as ReplicaSets do not support a rolling update directly.
 -->
-
 一旦删除了原来的 ReplicaSet，就可以创建一个新的来替换它。
 由于新旧 ReplicaSet 的 `.spec.selector` 是相同的，新的 ReplicaSet 将接管老的 Pod。
 但是，它不会努力使现有的 Pod 与新的、不同的 Pod 模板匹配。
-若想要以可控的方式将 Pod 更新到新的 spec，就要使用 [滚动更新](#rolling-updates)的方式。
-
+若想要以可控的方式更新 Pod 的规约，可以使用
+[Deployment](/zh/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)
+资源，因为 ReplicaSet 并不直接支持滚动更新。
 
 <!--
-
 ### Isolating pods from a ReplicaSet
 
 Pods may be removed from a ReplicaSet's target set by changing their labels. This technique may be used to remove pods 
@@ -332,10 +514,10 @@ from service for debugging, data recovery, etc. Pods that are removed in this wa
   assuming that the number of replicas is not also changed).
 
 -->
-
 ### 将 Pod 从 ReplicaSet 中隔离
 
-可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。
+可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。
+这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。
 以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。
 
 <!--
@@ -344,10 +526,10 @@ from service for debugging, data recovery, etc. Pods that are removed in this wa
 A ReplicaSet can be easily scaled up or down by simply updating the `.spec.replicas` field. The ReplicaSet controller
 ensures that a desired number of pods with a matching label selector are available and operational.
 -->
-
 ### 缩放 RepliaSet
 
-通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。
+通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet
+控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。
 
 <!--
 ### ReplicaSet as an Horizontal Pod Autoscaler Target
@@ -357,13 +539,13 @@ A ReplicaSet can also be a target for
 a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
 the ReplicaSet we created in the previous example.
 -->
-
 ### ReplicaSet 作为水平的 Pod 自动缩放器目标
 
-ReplicaSet 也可以作为 [水平的 Pod 缩放器 (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/) 的目标。也就是说，ReplicaSet 可以被 HPA 自动缩放。
+ReplicaSet 也可以作为
+[水平的 Pod 缩放器 (HPA)](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+的目标。也就是说，ReplicaSet 可以被 HPA 自动缩放。
 以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。
 
-
 {{< codenew file="controllers/hpa-rs.yaml" >}}
 
 <!--
@@ -371,23 +553,21 @@ Saving this manifest into `hpa-rs.yaml` and submitting it to a Kubernetes cluste
 create the defined HPA that autoscales the target ReplicaSet depending on the CPU usage
 of the replicated pods.
 -->
-
-将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的 HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。
+将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的
+HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。
 
 ```shell
-kubectl create -f https://k8s.io/examples/controllers/hpa-rs.yaml
+kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
 ```
 
 <!--
 Alternatively, you can use the `kubectl autoscale` command to accomplish the same
 (and it's easier!)
 -->
-
-或者，可以使用 `kubectl autoscale` 命令完成相同的操作。
-(而且它更简单！)
+或者，可以使用 `kubectl autoscale` 命令完成相同的操作。 (而且它更简单！)
 
 ```shell
-kubectl autoscale rs frontend
+kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
 ```
 
 <!--
@@ -395,43 +575,49 @@ kubectl autoscale rs frontend
 
 ### Deployment (Recommended)
 
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying ReplicaSets and their Pods
-in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality,
-because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features. For more information on running a stateless
-application using a Deployment, please read [Run a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
+[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is an object which can own ReplicaSets and update
+them and their Pods via declarative, server-side rolling updates.
+While ReplicaSets can be used independently, today they're  mainly used by Deployments as a mechanism to orchestrate Pod
+creation, deletion and updates. When you use Deployments you don't have to worry about managing the ReplicaSets that
+they create. Deployments own and manage their ReplicaSets.
+As such, it is recommended to use Deployments when you want ReplicaSets.
 -->
-
 ## ReplicaSet 的替代方案
 
 ### Deployment （推荐）
 
-[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
-如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 `kubectl rolling-update` 不同的是：它是声明式的、服务器端的、并且具有其他特性。
-有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
+[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个
+可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。
+尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为
+编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心
+如何管理它所创建的 ReplicaSet，Deployment 拥有并管理其 ReplicaSet。
+因此，建议你在需要 ReplicaSet 时使用 Deployment。
 
 <!--
 ### Bare Pods
 
-Unlike the case where a user directly created pods, a ReplicaSet replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicaSet delegates local container restarts to some agent on the node (for example, Kubelet or Docker).
+Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your application requires only a single Pod. Think of it similarly to a process supervisor, only it supervises multiple Pods across multiple nodes instead of individual processes on a single node. A ReplicaSet delegates local container restarts to some agent on the node (for example, Kubelet or Docker).
 -->
-
 ### 裸 Pod
 
-与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。
-因为这个好处，我们建议您使用 ReplicaSet，即使应用程序只需要一个 Pod。
-想像一下，ReplicaSet 类似于进程监视器，只不过它在多个节点上监视多个 Pod，而不是在单个节点上监视单个进程。
+与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的
+Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。
+因为这个原因，我们建议你使用 ReplicaSet，即使应用程序只需要一个 Pod。
+想像一下，ReplicaSet 类似于进程监视器，只不过它在多个节点上监视多个 Pod，
+而不是在单个节点上监视单个进程。
 ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理（例如，Kubelet 或 Docker）去完成。
 
 <!--
 ### Job
 
-Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicaSet for pods that are expected to terminate on their own
+Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet for Pods that are expected to terminate on their own
 (that is, batch jobs).
 -->
 
 ### Job
 
-使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
+使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet，
+可以用于那些期望自行终止的 Pod。
 
 <!--
 ### DaemonSet
@@ -441,11 +627,25 @@ machine-level function, such as machine monitoring or machine logging.  These po
 to a machine lifetime: the pod needs to be running on the machine before other pods start, and are
 safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
 -->
-
 ### DaemonSet
 
-对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
-这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止。
+对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，
+就要用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/)
+而不用 ReplicaSet。
+这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，
+并且在机器准备重新启动/关闭时安全地终止。
 
+### ReplicationController
 
+<!--
+ReplicaSets are the successors to [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/).
+The two serve the same purpose, and behave similarly, except that a ReplicationController does not support set-based
+selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
+As such, ReplicaSets are preferred over ReplicationControllers
+-->
+ReplicaSet 是 [ReplicationController](/zh/docs/concepts/workloads/controllers/replicationcontroller/)
+的后继者。二者目的相同且行为类似，只是 ReplicationController 不支持
+[标签用户指南](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+中讨论的基于集合的选择算符需求。
+因此，相比于 ReplicationController，应优先考虑 ReplicaSet。
 
diff --git a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
index 7c3b5988e1..bc28f4cbef 100644
--- a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -7,7 +7,7 @@ feature:
     重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会将它们公布给客户端。
 
 content_type: concept
-weight: 20
+weight: 90
 ---     
 
 <!--
@@ -22,7 +22,7 @@ feature:
     Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
 
 content_type: concept
-weight: 20
+weight: 90
 -->
 
 <!-- overview -->
@@ -499,7 +499,7 @@ API object can be found at:
 ### ReplicaSet
 
 [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is the next-generation ReplicationController that supports the new [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement).
-It’s mainly used by [`Deployment`](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate Pod creation, deletion and updates.
+It’s mainly used by [Deployment](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate Pod creation, deletion and updates.
 Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.
 -->
 ## ReplicationController 的替代方案
@@ -508,8 +508,10 @@ Note that we recommend using Deployments instead of directly using Replica Sets,
 
 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
 支持新的[基于集合的标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
-它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 用来作为一种编排 Pod 创建、删除及更新的机制。
-请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非你需要自定义更新编排或根本不需要更新。
+它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)
+用来作为一种编排 Pod 创建、删除及更新的机制。
+请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非
+你需要自定义更新编排或根本不需要更新。
 
 <!--
 ### Deployment (Recommended)
diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md
index a827581250..100343be99 100644
--- a/content/zh/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md
@@ -254,8 +254,6 @@ the StatefulSet.
 
 <!--
 ## Deployment and Scaling Guarantees
--->
-## 部署和扩缩保证  {#deployment-and-scaling-guarantees}
 
 * For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
 * When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md
index dc908e196a..dba92eebcf 100644
--- a/content/zh/docs/concepts/workloads/pods/_index.md
+++ b/content/zh/docs/concepts/workloads/pods/_index.md
@@ -276,13 +276,13 @@ from a _pod template_ and manage those Pods on your behalf.
 
 PodTemplates are specifications for creating Pods, and are included in workload resources such as
 [Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[Jobs](/docs/concepts/workloads/controllers/job/), and
 [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
 -->
 ### Pod 模版    {#pod-templates}
 
-{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用 _Pod 模板（Pod Template）_ 
-来替你创建 Pod 并管理它们。
+{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用
+_Pod 模板（Pod Template）_ 来替你创建 Pod 并管理它们。
 
 Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
@@ -405,7 +405,7 @@ or POSIX shared memory.  Containers in different Pods have distinct IP addresses
 and can not communicate by IPC without
 [special configuration](/docs/concepts/policy/pod-security-policy/).
 Containers that want to interact with a container running in a different Pod can
-use IP networking to comunicate.
+use IP networking to communicate.
 -->
 在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 发现对方。
 他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。
@@ -487,7 +487,7 @@ but cannot be controlled from there.
 <!--
 * Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
 * Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
-* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
+* Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
   configure different Pods with different container runtime configurations.
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
 * Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
@@ -506,7 +506,8 @@ but cannot be controlled from there.
 * Pod 在 Kubernetes REST API 中是一个顶层资源；
   [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
   对象的定义中包含了更多的细节信息。
-* 博客 [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 中解释了在同一 Pod 中包含多个容器时的几种常见布局。
+* 博客 [分布式系统工具箱：复合容器模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
+  中解释了在同一 Pod 中包含多个容器时的几种常见布局。
 
 <!--
 To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
@@ -516,9 +517,9 @@ To understand the context for why Kubernetes wraps a common Pod API in other res
 或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
 封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：
 
-  * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
-  * [Borg](https://research.google.com/pubs/pub43438.html)
-  * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
-  * [Omega](https://research.google/pubs/pub41684/)
-  * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
+* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+* [Borg](https://research.google.com/pubs/pub43438.html)
+* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+* [Omega](https://research.google/pubs/pub41684/)
+* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
 
diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md
index 3b97c72fdf..3c70c6ca68 100644
--- a/content/zh/docs/concepts/workloads/pods/disruptions.md
+++ b/content/zh/docs/concepts/workloads/pods/disruptions.md
@@ -161,7 +161,7 @@ disruptions, if any, to expect.
 自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，根本没有自愿干扰。然而，集群管理
 或托管提供商可能运行一些可能导致自愿干扰的额外服务。例如，节点软
 更新可能导致自愿干扰。另外，集群（节点）自动缩放的某些
-现可能导致碎片整理和紧缩节点的自愿干扰。集群
+实现可能导致碎片整理和紧缩节点的自愿干扰。集群
 理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。
 
 <!--
diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md
index 956b0518c2..31cd631f4e 100644
--- a/content/zh/docs/concepts/workloads/pods/init-containers.md
+++ b/content/zh/docs/concepts/workloads/pods/init-containers.md
@@ -3,20 +3,29 @@ approvers:
 - erictune
 title: Init 容器
 content_type: concept
+weight: 40
 ---
+<!---
+reviewers:
+- erictune
+title: Init Containers
+content_type: concept
+weight: 40
+-->
 
 <!-- overview -->
 
 <!--
-This page provides an overview of init containers: specialized containers that run before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+This page provides an overview of init containers: specialized containers that run
+before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
 Init containers can contain utilities or setup scripts not present in an app image.
 -->
-
-本页提供了 Init 容器的概览，它是一种特殊容器，在 {{< glossary_tooltip text="Pod" term_id="pod" >}}
-内的应用容器启动之前运行，可以包括一些应用镜像中不存在的实用工具和安装脚本。
+本页提供了 Init 容器的概览。Init 容器是一种特殊容器，在 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。
 
 <!--
-  You can specify init containers in the Pod specification alongside the `containers` array (which describes app containers).
+You can specify init containers in the Pod specification alongside the `containers`
+array (which describes app containers).
 -->
 你可以在 Pod 的规约中与用来描述应用容器的 `containers` 数组平行的位置指定
 Init 容器。
@@ -26,7 +35,9 @@ Init 容器。
 <!--
 ## Understanding init containers
 
-A {{< glossary_tooltip text="Pod" term_id="pod" >}} can have multiple containers running apps within it, but it can also have one or more init containers, which are run before the app containers are started.
+A {{< glossary_tooltip text="Pod" term_id="pod" >}} can have multiple containers
+running apps within it, but it can also have one or more init containers, which are run
+before the app containers are started.
 -->
 ## 理解 Init 容器
 
@@ -35,6 +46,7 @@ A {{< glossary_tooltip text="Pod" term_id="pod" >}} can have multiple containers
 
 <!--
 Init containers are exactly like regular containers, except:
+
 * Init containers always run to completion.
 * Each init container must complete successfully before the next one starts.
 -->
@@ -44,15 +56,20 @@ Init 容器与普通的容器非常像，除了如下两点：
 * 每个都必须在下一个启动之前成功完成。
 
 <!--
-If a Pod's init container fails, Kubernetes repeatedly restarts the Pod until the init container succeeds. However, if the Pod has a `restartPolicy` of Never, Kubernetes does not restart the Pod.
+If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds. 
+However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed.
 -->
-如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。
-然而，如果 Pod 对应的 `restartPolicy` 值为 Never，Kubernetes 不会重新启动 Pod。
+如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。
+然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，Kubernetes 不会重新启动 Pod。
 
 <!--
-To specify an init container for a Pod, add the `initContainers` field into the Pod specification, as an array of objects of type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), alongside the app `containers` array.
-
-The status of the init containers is returned in `.status.initContainerStatuses` field as an array of the container statuses (similar to the `.status.containerStatuses` field).
+To specify an init container for a Pod, add the `initContainers` field into
+the Pod specification, as an array of objects of type
+[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core),
+alongside the app `containers` array.
+The status of the init containers is returned in `.status.initContainerStatuses`
+field as an array of the container statuses (similar to the `.status.containerStatuses`
+field).
 -->
 为 Pod 设置 Init 容器需要在 Pod 的 `spec` 中添加 `initContainers` 字段，
 该字段以 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
@@ -62,9 +79,19 @@ Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态
 
 <!--
 ### Differences from regular containers
-Init containers support all the fields and features of app containers, including resource limits, volumes, and security settings. However, the resource requests and limits for an init container are handled differently, as documented in [Resources](#resources).
-Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` because they must run to completion before the Pod can be ready.
-If you specify multiple init containers for a Pod, Kubelet runs each init container sequentially. Each init container must succeed before the next can run. When all of the init containers have run to completion, Kubelet initializes the application containers for the Pod and runs them as usual.
+
+Init containers support all the fields and features of app containers,
+including resource limits, volumes, and security settings. However, the
+resource requests and limits for an init container are handled differently,
+as documented in [Resources](#resources).
+
+Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or
+`startupProbe` because they must run to completion before the Pod can be ready.
+
+If you specify multiple init containers for a Pod, Kubelet runs each init
+container sequentially. Each init container must succeed before the next can run.
+When all of the init containers have run to completion, Kubelet initializes
+the application containers for the Pod and runs them as usual.
 -->
 ### 与普通容器的不同之处
 
@@ -80,12 +107,24 @@ Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。
 
 <!--
 ## Using init containers
-Because init containers have separate images from app containers, they have some advantages for start-up related code:
-* Init containers can contain utilities or custom code for setup that are not present in an app image. For example, there is no need to make an image `FROM` another image just to use a tool like `sed`, `awk`, `python`, or `dig` during setup.
-* Init containers can securely run utilities that would make an app container image less secure.
-* The application image builder and deployer roles can work independently without the need to jointly build a single app image.
-* Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to {{< glossary_tooltip text="Secrets" term_id="secret" >}} that app containers cannot access.
-* Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel.
+
+Because init containers have separate images from app containers, they
+have some advantages for start-up related code:
+
+* Init containers can contain utilities or custom code for setup that are not present in an app
+  image. For example, there is no need to make an image `FROM` another image just to use a tool like
+  `sed`, `awk`, `python`, or `dig` during setup.
+* The application image builder and deployer roles can work independently without
+  the need to jointly build a single app image.
+* Init containers can run with a different view of the filesystem than app containers in the
+  same Pod. Consequently, they can be given access to
+  {{< glossary_tooltip text="Secrets" term_id="secret" >}} that app containers cannot access.
+* Because init containers run to completion before any app containers start, init containers offer
+  a mechanism to block or delay app container startup until a set of preconditions are met. Once
+  preconditions are met, all of the app containers in a Pod can start in parallel.
+* Init containers can securely run utilities or custom code that would otherwise make an app
+  container image less secure. By keeping unnecessary tools separate you can limit the attack
+  surface of your app container image.
 -->
 ## 使用 Init 容器
 
@@ -108,12 +147,15 @@ Because init containers have separate images from app containers, they have some
 
 <!--
 ### Examples
+
 Here are some ideas for how to use init containers:
+
 * Wait for a {{< glossary_tooltip text="Service" term_id="service">}} to
   be created, using a shell one-line command like:
   ```shell
   for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
   ```
+
  * Register this Pod with a remote server from the downward API with a command like:
   ```shell
   curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
@@ -124,7 +166,11 @@ Here are some ideas for how to use init containers:
   ```
 
 * Clone a Git repository into a {{< glossary_tooltip text="Volume" term_id="volume" >}}
-* Place values into a configuration file and run a template tool to dynamically generate a configuration file for the main app container. For example, place the `POD_IP` value in a configuration and generate the main app configuration file using Jinja.
+
+* Place values into a configuration file and run a template tool to dynamically
+  generate a configuration file for the main app container. For example,
+  place the `POD_IP` value in a configuration and generate the main app
+  configuration file using Jinja.
 -->
 ### 示例  {#examples}
 
@@ -156,24 +202,10 @@ Here are some ideas for how to use init containers:
 
 <!--
 #### Init containers in use
-This example defines a simple Pod that has two init containers. The first waits for `myservice`, and the second waits for `mydb`. Once both init containers complete, the Pod runs the app container from its `spec` section.
-```yaml
 
-```
-
-The following YAML file outlines the `mydb` and `myservice` services:
-```yaml
-
-```
-
-
-You can start this Pod by running:
-```shell
-```
-
-And check on its status with:
- ```shell
-```
+This example defines a simple Pod that has two init containers.
+The first waits for `myservice`, and the second waits for `mydb`. Once both
+init containers complete, the Pod runs the app container from its `spec` section.
 -->
 ### 使用 Init 容器的情况
 
@@ -201,63 +233,40 @@ spec:
     command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
 ```
 
-下面的 yaml 文件展示了 `mydb` 和 `myservice` 两个 Service：
-
-```
-kind: Service
-apiVersion: v1
-metadata:
-  name: myservice
-spec:
-  ports:
-    - protocol: TCP
-      port: 80
-      targetPort: 9376
----
-kind: Service
-apiVersion: v1
-metadata:
-  name: mydb
-spec:
-  ports:
-    - protocol: TCP
-      port: 80
-      targetPort: 9377
-```
-
-要启动这个 Pod，可以执行如下命令：
+<!--
+You can start this Pod by running:
+-->
+你通过运行下面的命令启动 Pod：
 
 ```shell
 kubectl apply -f myapp.yaml
 ```
-
-输出为：
-
 ```
 pod/myapp-pod created
 ```
 
-要检查其状态：
+<!--
+And check on its status with:
+-->
+使用下面的命令检查其状态：
 
 ```shell
 kubectl get -f myapp.yaml
 ```
-
-输出类似于：
-
 ```
 NAME        READY     STATUS     RESTARTS   AGE
 myapp-pod   0/1       Init:0/2   0          6m
 ```
 
-如需更详细的信息：
+<!--
+or for more details:
+-->
+或者查看更多详细信息：
 
 ```shell
 kubectl describe -f myapp.yaml
 ```
 
-输出类似于：
-
 ```
 Name:          myapp-pod
 Namespace:     default
@@ -293,6 +302,9 @@ Events:
   13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634
 ```
 
+<!--
+To see logs for the init containers in this Pod, run:
+-->
 如需查看 Pod 内 Init 容器的日志，请执行：
 
 ```shell
@@ -301,7 +313,8 @@ kubectl logs myapp-pod -c init-mydb      # 查看第二个 Init 容器
 ```
 
 <!--
-At this point, those init containers will be waiting to discover Services named `mydb` and `myservice`.
+At this point, those init containers will be waiting to discover Services named
+`mydb` and `myservice`.
 
 Here's a configuration you can use to make those Services appear:
 -->
@@ -332,23 +345,27 @@ spec:
     targetPort: 9377
 ```
 
+<!--
+To create the `mydb` and `myservice` services:
+-->
 创建 `mydb` 和 `myservice` 服务的命令：
 
 ```shell
 kubectl create -f services.yaml
 ```
-
-输出类似于：
-
 ```
 service "myservice" created
 service "mydb" created
 ```
 
+<!--
+You'll then see that those init containers complete, and that the `myapp-pod`
+Pod moves into the Running state:
+-->
 这样你将能看到这些 Init 容器执行完毕，随后 `my-app` 的 Pod 进入 `Running` 状态：
 
 ```shell
-$ kubectl get -f myapp.yaml
+kubectl get -f myapp.yaml
 ```
 
 ```
@@ -356,32 +373,43 @@ NAME        READY     STATUS    RESTARTS   AGE
 myapp-pod   1/1       Running   0          9m
 ```
 
-一旦我们启动了 `mydb` 和 `myservice` 这两个服务，我们能够看到 Init 容器完成，
-并且 `myapp-pod` 被创建。
-
 <!--
-This simple example should provide some inspiration for you to create your own init containers. [What's next](#what-s-next) contains a link to a more detailed example.
+This simple example should provide some inspiration for you to create your own
+init containers. [What's next](#whats-next) contains a link to a more detailed example.
 -->
 这个简单例子应该能为你创建自己的 Init 容器提供一些启发。
-[接下来](#what-s-next)节提供了更详细例子的链接。
+[接下来](#whats-next)节提供了更详细例子的链接。
 
 <!--
 ## Detailed behavior
 
-During the startup of a Pod, each init container starts in order, after the network and volumes are initialized. Each container must exit successfully before the next container starts. If a container fails to start due to the runtime or exits with failure, it is retried according to the Pod `restartPolicy`. However, if the Pod `restartPolicy` is set to Always, the init containers use `restartPolicy` OnFailure.
+During Pod startup, the kubelet delays running init containers until the networking
+and storage are ready. Then the kubelet runs the Pod's init containers in the order
+they appear in the Pod's spec.
 
-A Pod cannot be `Ready` until all init containers have succeeded. The ports on an init container are not aggregated under a Service. A Pod that is initializing
- is in the `Pending` state but should have a condition `Initializing` set to true.
+Each init container must exit successfully before
+the next container starts. If a container fails to start due to the runtime or
+exits with failure, it is retried according to the Pod `restartPolicy`. However,
+if the Pod `restartPolicy` is set to Always, the init containers use
+`restartPolicy` OnFailure.
 
-If the Pod [restarts](#pod-restart-reasons), or is restarted, all init containers must execute again.
+A Pod cannot be `Ready` until all init containers have succeeded. The ports on an
+init container are not aggregated under a Service. A Pod that is initializing
+is in the `Pending` state but should have a condition `Initialized` set to true.
+
+If the Pod [restarts](#pod-restart-reasons), or is restarted, all init containers
+must execute again.
 -->
 ## 具体行为 {#detailed-behavior}
 
-在 Pod 启动过程中，每个 Init 容器在网络和数据卷初始化之后会按顺序启动。
+在 Pod 启动过程中，每个 Init 容器会在网络和数据卷初始化之后按顺序启动。
+kubelet 运行依据 Init 容器在 Pod 规约中的出现顺序依次运行之。
+
 每个 Init 容器成功退出后才会启动下一个 Init 容器。
-如果它们因为容器运行时的原因无法启动，或以错误状态退出，它会根据 Pod 的 `restartPolicy` 策略进行重试。
-然而，如果 Pod 的 `restartPolicy` 设置为 "Always"，Init 容器失败时会使用 `restartPolicy`
-的 "OnFailure" 策略。
+如果某容器因为容器运行时的原因无法启动，或以错误状态退出，kubelet 会根据
+Pod 的 `restartPolicy` 策略进行重试。
+然而，如果 Pod 的 `restartPolicy` 设置为 "Always"，Init 容器失败时会使用
+`restartPolicy` 的 "OnFailure" 策略。
 
 在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。
 Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 `Pending` 状态，
@@ -390,11 +418,17 @@ Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的
 如果 Pod [重启](#pod-restart-reasons)，所有 Init 容器必须重新执行。
 
 <!--
-Changes to the init container spec are limited to the container image field. Altering an init container image field is equivalent to restarting the Pod.
+Changes to the init container spec are limited to the container image field.
+Altering an init container image field is equivalent to restarting the Pod.
 
-Because init containers can be restarted, retried, or re-executed, init container code should be idempotent. In particular, code that writes to files on `EmptyDirs` should be prepared for the possibility that an output file already exists.
+Because init containers can be restarted, retried, or re-executed, init container
+code should be idempotent. In particular, code that writes to files on `EmptyDirs`
+should be prepared for the possibility that an output file already exists.
+
+Init containers have all of the fields of an app container. However, Kubernetes
+prohibits `readinessProbe` from being used because init containers cannot
+define readiness distinct from completion. This is enforced during validation.
 
-Init containers have all of the fields of an app container. However, Kubernetes prohibits `readinessProbe` from being used because init containers cannot define readiness distinct from completion. This is enforced during validation.
 -->
 对 Init 容器规约的修改仅限于容器的 `image` 字段。
 更改 Init 容器的 `image` 字段，等同于重启该 Pod。
@@ -407,9 +441,12 @@ Init 容器具有应用容器的所有字段。然而 Kubernetes 禁止使用 `r
 Kubernetes 会在校验时强制执行此检查。
 
 <!--
-Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the container to prevent init containers from failing forever. The active deadline includes init containers.
+Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the container to
+prevent init containers from failing forever. The active deadline includes init
+containers.
 
-The name of each app and init container in a Pod must be unique; avalidation error is thrown for any container sharing a name with another.
+The name of each app and init container in a Pod must be unique; a
+validation error is thrown for any container sharing a name with another.
 -->
 在 Pod 上使用 `activeDeadlineSeconds` 和在容器上使用 `livenessProbe` 可以避免
 Init 容器一直重复失败。`activeDeadlineSeconds` 时间包含了 Init 容器启动的时间。
@@ -418,17 +455,21 @@ Init 容器一直重复失败。`activeDeadlineSeconds` 时间包含了 Init 容
 与任何其它容器共享同一个名称，会在校验时抛出错误。
 
 <!--
- ### Resources
-Given the ordering and execution for init containers, the following rules for resource usage apply:
-* The highest of any particular resource request or limit defined on all init containers is the *effective init request/limit*
+### Resources
+
+Given the ordering and execution for init containers, the following rules
+for resource usage apply:
+
+* The highest of any particular resource request or limit defined on all init
+  containers is the *effective init request/limit*
 * The Pod's *effective request/limit* for a resource is the higher of:
   * the sum of all app containers request/limit for a resource
   * the effective init request/limit for a resource
-* Scheduling is done based on effective requests/limits, which means init containers can reserve resources for initialization that are not used during the life of the Pod.
-* The QoS (quality of service) tier of the Pod's *effective QoS tier* is the QoS tier for init containers and app containers alike.
-
-Quota and limits are applied based on the effective Pod request and limit.
-Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler.
+* Scheduling is done based on effective requests/limits, which means
+  init containers can reserve resources for initialization that are not used
+  during the life of the Pod.
+* The QoS (quality of service) tier of the Pod's *effective QoS tier* is the
+  QoS tier for init containers and app containers alike.
 -->
 ### 资源 {#resources}
 
@@ -442,15 +483,27 @@ Pod level control groups (cgroups) are based on the effective Pod request and li
   这些资源在 Pod 生命周期过程中并没有被使用。
 * Pod 的 *有效 QoS 层* ，与 Init 容器和应用容器的一样。
 
-配额和限制适用于有效 Pod的 limit/request。
-Pod 级别的 cgroups 是基于有效 Pod 的 limit/request，和调度器相同。
+<!--
+Quota and limits are applied based on the effective Pod request and limit.
+Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler.
+-->
+配额和限制适用于有效 Pod 的请求和限制值。
+Pod 级别的 cgroups 是基于有效 Pod 的请求和限制值，和调度器相同。
 
 <!--
- ### Pod restart reasons
-A Pod can restart, causing re-execution of init containers, for the following reasons:
-* A user updates the Pod specification, causing the init container image to change. Any changes to the init container image restarts the Pod. App container image changes only restart the app container.
-* The Pod infrastructure container is restarted. This is uncommon and would have to be done by someone with root access to nodes.
-* All containers in a Pod are terminated while `restartPolicy` is set to Always, forcing a restart, and the init container completion record has been lost due to garbage collection.
+### Pod restart reasons
+
+A Pod can restart, causing re-execution of init containers, for the following
+reasons:
+
+* A user updates the Pod specification, causing the init container image to change.
+  Any changes to the init container image restarts the Pod. App container image
+  changes only restart the app container.
+* The Pod infrastructure container is restarted. This is uncommon and would
+  have to be done by someone with root access to nodes.
+* All containers in a Pod are terminated while `restartPolicy` is set to Always,
+  forcing a restart, and the init container completion record has been lost due
+  to garbage collection.
 -->
 ### Pod 重启的原因  {#pod-restart-reasons}
 
@@ -471,7 +524,6 @@ Pod 重启会导致 Init 容器重新执行，主要有如下几个原因：
 * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
 * Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
 -->
-
 * 阅读[创建包含 Init 容器的 Pod](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
 * 学习如何[调试 Init 容器](/zh/docs/tasks/debug-application-cluster/debug-init-containers/)
 
diff --git a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
index 3cbca2f16d..bd465ddcc8 100644
--- a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -19,7 +19,8 @@ of its primary containers starts OK, and then through either the `Succeeded` or
 
 Whilst a Pod is running, the kubelet is able to restart containers to handle some
 kind of faults. Within a Pod, Kubernetes tracks different container
-[states](#container-states) and handles
+[states](#container-states) and determines what action to take to make the Pod
+healthy again.
 -->
 本页面讲述 Pod 的生命周期。
 Pod 遵循一个预定义的生命周期，起始于 `Pending` [阶段](#pod-phase)，如果至少
@@ -28,7 +29,7 @@ Pod 遵循一个预定义的生命周期，起始于 `Pending` [阶段](#pod-pha
 
 在 Pod 运行期间，`kubelet` 能够重启容器以处理一些失效场景。
 在 Pod 内部，Kubernetes 跟踪不同容器的[状态](#container-states)
-并处理可能出现的状况。
+并确定使 Pod 重新变得健康所需要采取的动作。
 
 <!--
 In the Kubernetes API, Pods have both a specification and an actual status. The
@@ -88,7 +89,7 @@ Pod 自身不具有自愈能力。如果 Pod 被调度到某{{< glossary_tooltip
 
 <!--
 A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead,
-that Pod can be replaced by a new, near-identical Pod, with even the same name i
+that Pod can be replaced by a new, near-identical Pod, with even the same name if
 desired, but with a different UID.
 
 When something is said to have the same lifetime as a Pod, such as a
@@ -193,7 +194,7 @@ Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体
 `Terminated`（已终止）。
 
 <!--
-To the check state of a Pod's containers, you can use
+To check the state of a Pod's containers, you can use
 `kubectl describe pod <name-of-pod>`. The output shows the state for each container
 within that Pod.
 
@@ -207,7 +208,7 @@ Each state has a specific meaning:
 <!--
 ### `Waiting` {#container-state-waiting}
 
-If a container is not in either the `Running` or `Terminated` state, it `Waiting`.
+If a container is not in either the `Running` or `Terminated` state, it is `Waiting`.
 A container in the `Waiting` state is still running the operations it requires in
 order to complete start up: for example, pulling the container image from a container
 image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}}
@@ -228,23 +229,23 @@ Reason 字段，其中给出了容器处于等待状态的原因。
 ### `Running` {#container-state-running}
 
 The `Running` status indicates that a container is executing without issues. If there
-was a `postStart` hook configured, it has already executed and executed. When you use
+was a `postStart` hook configured, it has already executed and finished. When you use
 `kubectl` to query a Pod with a container that is `Running`, you also see information
 about when the container entered the `Running` state.
 -->
 ### `Running`（运行中）     {#container-state-running}
 
 `Running` 状态表明容器正在执行状态并且没有问题发生。
-如果配置了 `postStart` 回调，那么该回调已经执行完成。
+如果配置了 `postStart` 回调，那么该回调已经执行且已完成。
 如果你使用 `kubectl` 来查询包含 `Running` 状态的容器的 Pod 时，你也会看到
 关于容器进入 `Running` 状态的信息。
 
 <!--
 ### `Terminated` {#container-state-terminated}
 
-A container in the `Terminated` state has begin execution and has then either run to
-completion or has failed for some reason. When you use `kubectl` to query a Pod with
-a container that is `Terminated`, you see a reason, and exit code, and the start and
+A container in the `Terminated` state began execution and then either ran to
+completion or failed for some reason. When you use `kubectl` to query a Pod with
+a container that is `Terminated`, you see a reason, an exit code, and the start and
 finish time for that container's period of execution.
 
 If a container has a `preStop` hook configured, that runs before the container enters
@@ -268,8 +269,8 @@ and Never. The default value is Always.
 The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
 refers to restarts of the containers by the kubelet on the same node. After containers
 in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
-40s, …), that is capped at five minutes. Once a container has executed with no problems
-for 10 minutes without any problems, the kubelet resets the restart backoff timer for
+40s, …), that is capped at five minutes. Once a container has executed for 10 minutes
+without any problems, the kubelet resets the restart backoff timer for
 that container.
 -->
 ## 容器重启策略 {#restart-policy}
@@ -426,7 +427,8 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 ## Container probes
 
 A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
+performed periodically by the
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
 on a Container. To perform a diagnostic,
 the kubelet calls a
 [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
@@ -434,10 +436,10 @@ the container. There are three types of handlers:
 -->
 ## 容器探针    {#container-probes}
 
-[探针](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
+[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
 要执行诊断，kubelet 调用由容器实现的
-[Handler](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)
+[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)
 （处理程序）。有三种类型的处理程序：
 
 <!--
@@ -593,7 +595,7 @@ to stop.
 -->
 ### 何时该使用启动探针？   {#when-should-you-use-a-startup-probe}
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 <!--
 Startup probes are useful for Pods that have containers that take a long time to
@@ -647,14 +649,17 @@ shutdown.
 Pod。
 
 <!--
-Typically, the container runtime sends a a TERM signal is sent to the main process in each
-container. Once the grace period has expired, the KILL signal is sent to any remainig
+Typically, the container runtime sends a TERM signal to the main process in each
+container. Many container runtimes respect the `STOPSIGNAL` value defined in the container
+image and send this instead of TERM.
+Once the grace period has expired, the KILL signal is sent to any remainig
 processes, and the Pod is then deleted from the
 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
 container runtime's management service is restarted while waiting for processes to terminate, the
 cluster retries from the start including the full original grace period.
 -->
 通常情况下，容器运行时会发送一个 TERM 信号到每个容器中的主进程。
+很多容器运行时都能够注意到容器镜像中 `STOPSIGNAL` 的值，并发送该信号而不是 TERM。
 一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后
 Pod 就会被从 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
 上移除。如果 `kubelet` 或者容器运行时的管理服务在等待进程终止期间被重启，
@@ -666,9 +671,9 @@ An example flow:
 1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period
    (30 seconds).
 1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead"
-   along with the grace period.  
+   along with the grace period.
    If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as
-   "Terminating".  
+   "Terminating".
    On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked
    as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
    shutdown process.
@@ -737,7 +742,7 @@ An example flow:
    `SIGKILL` to any processes still running in any container in the Pod.
    The kubelet also cleans up a hidden `pause` container if that container runtime uses one.
 1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period
-   to 0 (immediate deletion).  
+   to 0 (immediate deletion).
 1. The API server deletes the Pod's API object, which is then no longer visible from any client.
 -->
 4. 超出终止宽限期线时，`kubelet` 会触发强制关闭过程。容器运行时会向 Pod 中所有容器内
@@ -745,14 +750,14 @@ An example flow:
    `kubelet` 也会清理隐藏的 `pause` 容器，如果容器运行时使用了这种容器的话。
 
 5. `kubelet` 触发强制从 API 服务器上删除 Pod 对象的逻辑，并将体面终止限期设置为 0
-   （这意味着马上删除）。  
+   （这意味着马上删除）。
 
 6. API 服务器删除 Pod 的 API 对象，从任何客户端都无法再看到该对象。
 
 <!--
 ### Forced Pod termination {#pod-termination-forced}
 
-Forced deletions can be potentially disruptiove for some workloads and their Pods.
+Forced deletions can be potentially disruptive for some workloads and their Pods.
 
 By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
 the `-grace-period=<seconds>` option which allows you to override the default and specify your
@@ -850,4 +855,3 @@ and
   可参阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
   和 [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)。
 
-
diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 4e7a2c5536..efa2621f06 100644
--- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,64 +1,66 @@
 ---
-title: Pod 拓扑扩展约束
+title: Pod 拓扑分布约束
 content_type: concept
-weight: 50
+weight: 40
 ---
 
 <!--
 title: Pod Topology Spread Constraints
 content_type: concept
-weight: 50
+weight: 40
 -->
 
-<!-- overview -->
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
+<!-- leave this shortcode in place until the note about EvenPodsSpread is
+obsolete -->
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+<!-- overview -->
 
 <!--
 You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
 -->
+你可以使用 _拓扑分布约束（Topology Spread Constraints）_ 来控制
+{{< glossary_tooltip text="Pods" term_id="Pod" >}} 在集群内故障域
+之间的分布，例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。
+这样做有助于实现高可用并提升资源利用率。
 
-可以使用*拓扑扩展约束*来控制 {{< glossary_tooltip text="Pods" term_id="Pod" >}} 在集群内故障域（例如地区，区域，节点和其他用户自定义拓扑域）之间的分布。这可以帮助实现高可用以及提升资源利用率。
+<!--
+{{< note >}}
+In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on
+the [API server](/docs/concepts/overview/components/#kube-apiserver) and the
+[scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod
+topology spread constraints.
+{{< /note >}}
+-->
+
+{{< note >}}
+在 v1.19 之前的 Kubernetes 版本中，如果要使用 Pod 拓扑扩展约束，你必须在 [API 服务器](/zh/docs/concepts/overview/components/#kube-apiserver) 
+和[调度器](/zh/docs/reference/command-line-tools-referene/kube-scheduler/)
+中启用 `EvenPodsSpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+{{< /note >}}
 
 <!-- body -->
 
 <!--
 ## Prerequisites
--->
-## 先决条件
 
-<!--
-### Enable Feature Gate
--->
-### 启用功能
-
-<!--
-Ensure the `EvenPodsSpread` feature gate is enabled (it is disabled by default
-in 1.16). See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
-for an explanation of enabling feature gates. The `EvenPodsSpread` feature gate must be enabled for the
-{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **and**
-{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}.
--->
-
-确保 `EvenPodsSpread` 功能已开启（在 1.16 版本中该功能默认关闭）。
-阅读[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)了解如何开启该功能。
-`EvenPodsSpread` 必须在 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} **和**
-{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} 中都开启。
-
-<!--
 ### Node Labels
 -->
-### 节点标签
+## 先决条件   {#prerequisites}
+
+### 节点标签   {#node-labels}
 
 <!--
 Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. For example, a Node might have labels: `node=node1,zone=us-east-1a,region=us-east-1`
 -->
-拓扑扩展约束依赖于节点标签来标识每个节点所在的拓扑域。例如，一个节点可能具有标签：`node=node1,zone=us-east-1a,region=us-east-1`
+拓扑分布约束依赖于节点标签来标识每个节点所在的拓扑域。
+例如，某节点可能具有标签：`node=node1,zone=us-east-1a,region=us-east-1`
 
 <!--
 Suppose you have a 4-node cluster with the following labels:
 -->
-假设你拥有一个具有以下标签的 4 节点集群：
+假设你拥有具有以下标签的一个 4 节点集群：
 
 ```
 NAME    STATUS   ROLES    AGE     VERSION   LABELS
@@ -73,28 +75,40 @@ Then the cluster is logically viewed as below:
 -->
 然后从逻辑上看集群如下：
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph TB
+    subgraph "zoneB"
+        n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        n1(Node1)
+        n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 <!--
 Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters.
 -->
-可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/kubernetes-api/labels-annotations-taints/)，而不是手动添加标签。
+你可以复用在大多数集群上自动创建和填充的
+[常用标签](/zh/docs/reference/kubernetes-api/labels-annotations-taints/)，
+而不是手动添加标签。
 
 <!--
 ## Spread Constraints for Pods
 -->
-## Pod 的拓扑约束
+## Pod 的分布约束    {#spread-constraints-for-pods}
 
 ### API
 
 <!--
-The field `pod.spec.topologySpreadConstraints` is introduced in 1.16 as below:
+The API field `pod.spec.topologySpreadConstraints` is defined as below:
 -->
 `pod.spec.topologySpreadConstraints` 字段定义如下所示：
 
@@ -114,10 +128,19 @@ spec:
 <!--
 You can define one or multiple `topologySpreadConstraint` to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are:
 -->
-可以定义一个或多个 `topologySpreadConstraint` 来指示 kube-scheduler 如何将每个传入的 Pod 根据与现有的 Pod 的关联关系在集群中部署。字段包括：
+你可以定义一个或多个 `topologySpreadConstraint` 来指示 kube-scheduler
+如何根据与现有的 Pod 的关联关系将每个传入的 Pod 部署到集群中。字段包括：
 
 <!--
-- **maxSkew** describes the degree to which Pods may be unevenly distributed. It's the maximum permitted difference between the number of matching Pods in any two topology domains of a given topology type. It must be greater than zero.
+- **maxSkew** describes the degree to which Pods may be unevenly distributed.
+  It's the maximum permitted difference between the number of matching Pods in
+  any two topology domains of a given topology type. It must be greater than
+  zero. Its semantics differs according to the value of `whenUnsatisfiable`:
+  - when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum
+    permitted difference between the number of matching pods in the target
+    topology and the global minimum.
+  - when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher
+    precedence to topologies that would help reduce the skew.
 - **topologyKey** is the key of node labels. If two Nodes are labelled with this key and have identical values for that label, the scheduler treats both Nodes as being in the same topology. The scheduler tries to place a balanced number of Pods into each topology domain.
 - **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint:
     - `DoNotSchedule` (default) tells the scheduler not to schedule it.
@@ -125,147 +148,220 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
 - **labelSelector** is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain. See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) for more details.
 -->
 
-- **maxSkew** 描述 pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中匹配的 pod 之间的最大允许差值。它必须大于零。
-- **topologyKey** 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值，则调度器会将这两个节点视为处于同一拓扑中。调度器试图在每个拓扑域中放置数量均衡的 pod。
-- **whenUnsatisfiable** 指示如果 pod 不满足扩展约束时如何处理：
-  - `DoNotSchedule`（默认）告诉调度器不用进行调度。
-  - `ScheduleAnyway` 告诉调度器在对最小化倾斜的节点进行优先级排序时仍对其进行调度。
-- **labelSelector** 用于查找匹配的 pod。匹配此标签的 pod 将被统计，以确定相应拓扑域中 pod 的数量。
+- **maxSkew** 描述 Pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中
+  匹配的 pod 之间的最大允许差值。它必须大于零。取决于 `whenUnsatisfiable` 的
+  取值，其语义会有不同。
+  - 当 `whenUnsatisfiable` 等于 "DoNotSchedule" 时，`maxSkew` 是目标拓扑域
+    中匹配的 Pod 数与全局最小值之间可存在的差异。
+  - 当 `whenUnsatisfiable` 等于 "ScheduleAnyway" 时，调度器会更为偏向能够降低
+    偏差值的拓扑域。
+- **topologyKey** 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值，
+  则调度器会将这两个节点视为处于同一拓扑域中。调度器试图在每个拓扑域中放置数量
+  均衡的 Pod。
+- **whenUnsatisfiable** 指示如果 Pod 不满足分布约束时如何处理：
+  - `DoNotSchedule`（默认）告诉调度器不要调度。
+  - `ScheduleAnyway` 告诉调度器仍然继续调度，只是根据如何能将偏差最小化来对
+    节点进行排序。
+- **labelSelector** 用于查找匹配的 pod。匹配此标签的 Pod 将被统计，以确定相应
+  拓扑域中 Pod 的数量。
   有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
 
 <!--
 You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
 -->
-执行 `kubectl explain Pod.spec.topologySpreadConstraints` 命令了解更多关于 topologySpreadConstraints 的信息。
+你可以执行 `kubectl explain Pod.spec.topologySpreadConstraints` 命令以
+了解关于 topologySpreadConstraints 的更多信息。
 
 <!--
 ### Example: One TopologySpreadConstraint
 
-Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
+Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively:
 -->
-### 例子：单个拓扑扩展约束
+### 例子：单个 TopologySpreadConstraint
 
-假设你拥有一个 4 节点集群，其中标记为 `foo:bar` 的 3 个 pod 分别位于 node1，node2 和 node3 中（`P` 表示 pod）：
+假设你拥有一个 4 节点集群，其中标记为 `foo:bar` 的 3 个 Pod 分别位于
+node1、node2 和 node3 中：
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 <!--
 If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as:
 -->
-如果希望传入的 pod 均匀散布在现有的 pod 区域，则可以指定字段如下：
+如果希望新来的 Pod 均匀分布在现有的可用区域，则可以按如下设置其规约：
 
 {{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
 
 <!--
 `topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:&lt;any value&gt;" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
 -->
-`topologyKey: zone` 意味着均匀分布将只应用于存在标签对为 "zone:&lt;any value&gt;" 的节点上。
-`whenUnsatisfiable: DoNotSchedule` 告诉调度器，如果传入的 pod 不满足约束，则让它保持悬决状态。
+`topologyKey: zone` 意味着均匀分布将只应用于存在标签键值对为
+"zone:&lt;any value&gt;" 的节点。
+`whenUnsatisfiable: DoNotSchedule` 告诉调度器如果新的 Pod 不满足约束，
+则让它保持悬决状态。
 
 <!--
 If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], 
 hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB":
 -->
-如果调度器将传入的 pod 放入 "zoneA"，pod 分布将变为 [3, 1]，因此实际的倾斜为 2（3 - 1）。
-这违反了 `maxSkew: 1`。此示例中，传入的 pod 只能放置在 "zoneB" 上：
+如果调度器将新的 Pod 放入 "zoneA"，Pods 分布将变为 [3, 1]，因此实际的偏差
+为 2（3 - 1）。这违反了 `maxSkew: 1` 的约定。此示例中，新 Pod 只能放置在
+"zoneB" 上：
 
-```
-+---------------+---------------+      +---------------+---------------+
-|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
-+-------+-------+-------+-------+      +-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
+
+或者
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        p4(mypod) --> n3
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 <!--
 You can tweak the Pod spec to meet various kinds of requirements:
 -->
-可以调整 pod 规格以满足各种要求：
+你可以调整 Pod 规约以满足各种要求：
 
 <!--
 - Change `maxSkew` to a bigger value like "2" so that the incoming Pod can be placed onto "zoneA" as well.
 - Change `topologyKey` to "node" so as to distribute the Pods evenly across nodes instead of zones. In the above example, if `maxSkew` remains "1", the incoming Pod can only be placed onto "node4".
 - Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway` to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it’s preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.)
 -->
-- 将 `maxSkew` 更改为更大的值，比如 "2"，这样传入的 pod 也可以放在 "zoneA" 上。
-- 将 `topologyKey` 更改为 "node"，以便将 pod 均匀分布在节点上而不是区域中。
-  在上面的例子中，如果 `maxSkew` 保持为 "1"，那么传入的 pod 只能放在 "node4" 上。
+- 将 `maxSkew` 更改为更大的值，比如 "2"，这样新的 Pod 也可以放在 "zoneA" 上。
+- 将 `topologyKey` 更改为 "node"，以便将 Pod 均匀分布在节点上而不是区域中。
+  在上面的例子中，如果 `maxSkew` 保持为 "1"，那么传入的 Pod 只能放在 "node4" 上。
 - 将 `whenUnsatisfiable: DoNotSchedule` 更改为 `whenUnsatisfiable: ScheduleAnyway`，
-  以确保传入的 Pod 始终可以调度（假设满足其他的调度 API）。
-  但是，最好将其放置在具有较少匹配 Pod 的拓扑域中。
-  （请注意，此优先性与其他内部调度优先级（如资源使用率等）一起进行标准化。）
+  以确保新的 Pod 始终可以被调度（假设满足其他的调度 API）。
+  但是，最好将其放置在匹配 Pod 数量较少的拓扑域中。
+  （请注意，这一优先判定会与其他内部调度优先级（如资源使用率等）排序准则一起进行标准化。）
 
 <!--
 ### Example: Multiple TopologySpreadConstraints
 -->
-### 例子：多个拓扑扩展约束
+### 例子：多个 TopologySpreadConstraints
 
 <!--
 This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod):
 -->
-
 下面的例子建立在前面例子的基础上。假设你拥有一个 4 节点集群，其中 3 个标记为 `foo:bar` 的
-Pod 分别位于 node1，node2 和 node3 上（`P` 表示 Pod）：
+Pod 分别位于 node1、node2 和 node3 上：
 
-```
-+---------------+---------------+
-|     zoneA     |     zoneB     |
-+-------+-------+-------+-------+
-| node1 | node2 | node3 | node4 |
-+-------+-------+-------+-------+
-|   P   |   P   |   P   |       |
-+-------+-------+-------+-------+
-```
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3 k8s;
+    class p4 plain;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
 <!--
 You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node:
 -->
-可以使用 2 个拓扑扩展约束来控制 pod 在 区域和节点两个维度上进行分布：
+可以使用 2 个 TopologySpreadConstraint 来控制 Pod 在 区域和节点两个维度上的分布：
 
 {{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
 
 <!--
 In this case, to match the first constraint, the incoming Pod can only be placed onto "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4".
 -->
-在这种情况下，为了匹配第一个约束，传入的 pod 只能放置在 "zoneB" 中；而在第二个约束中，
-传入的 Pod 只能放置在 "node4" 上。然后两个约束的结果加在一起，因此唯一可行的选择是放置在 "node4" 上。
+在这种情况下，为了匹配第一个约束，新的 Pod 只能放置在 "zoneB" 中；而在第二个约束中，
+新的 Pod 只能放置在 "node4" 上。最后两个约束的结果加在一起，唯一可行的选择是放置
+在 "node4" 上。
 
 <!--
 Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
 -->
-多个约束可能导致冲突。假设有一个跨越 2 个区域的 3 节点集群：
+多个约束之间可能存在冲突。假设有一个跨越 2 个区域的 3 节点集群：
+
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p4(Pod) --> n3(Node3)
+        p5(Pod) --> n3
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n1
+        p3(Pod) --> n2(Node2)
+    end
+
+    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+    class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
+    class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
-```
-+---------------+-------+
-|     zoneA     | zoneB |
-+-------+-------+-------+
-| node1 | node2 |  nod3 |
-+-------+-------+-------+
-|  P P  |   P   |  P P  |
-+-------+-------+-------+
-```
 
 <!--
 If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing.
 -->
 如果对集群应用 "two-constraints.yaml"，会发现 "mypod" 处于 `Pending` 状态。
 这是因为：为了满足第一个约束，"mypod" 只能放在 "zoneB" 中，而第二个约束要求
-"mypod" 只能放在 "node2" 上。pod 调度无法满足两种约束。
+"mypod" 只能放在 "node2" 上。Pod 调度无法满足两种约束。
 
 <!--
 To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`.
 -->
-为了克服这种情况，可以增加 `maxSkew` 或修改其中一个约束，让其使用
+为了克服这种情况，你可以增加 `maxSkew` 或修改其中一个约束，让其使用
 `whenUnsatisfiable: ScheduleAnyway`。
 
 <!--
@@ -273,58 +369,200 @@ To overcome this situation, you can either increase the `maxSkew` or modify one
 
 There are some implicit conventions worth noting here:
 -->
-### 约定
+### 约定   {#conventions}
 
 这里有一些值得注意的隐式约定：
 
 <!--
 - Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
+
 - Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that:
+
     1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA".
+
     2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".
 -->
-- 只有与传入 pod 具有相同命名空间的 pod 才能作为匹配候选者。
+- 只有与新的 Pod 具有相同命名空间的 Pod 才能作为匹配候选者。
 - 没有 `topologySpreadConstraints[*].topologyKey` 的节点将被忽略。这意味着：
-  1. 位于这些节点上的 pod 不影响 `maxSkew` 的计算。
+  1. 位于这些节点上的 Pod 不影响 `maxSkew` 的计算。
      在上面的例子中，假设 "node1" 没有标签 "zone"，那么 2 个 Pod 将被忽略，
      因此传入的 Pod 将被调度到 "zoneA" 中。
-  2. 传入的 Pod 没有机会被调度到这类节点上。
+
+  2. 新的 Pod 没有机会被调度到这类节点上。
      在上面的例子中，假设一个带有标签 `{zone-typo: zoneC}` 的 "node5" 加入到集群，
      它将由于没有标签键 "zone" 而被忽略。
 
 <!--
 - Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
 -->
-注意，如果传入 Pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的标签不匹配，将会发生什么。
-在上面的例子中，如果移除传入 Pod 的标签，Pod 仍然可以调度到 "zoneB"，因为约束仍然满足。
-然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 Pod，
-zoneB 有 1 个带有 {foo:bar} 标签的 Pod。
-因此，如果这不是你所期望的，建议工作负载的 `topologySpreadConstraints[*].labelSelector`
-与其自身的标签匹配。
+- 注意，如果新 Pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的
+  标签不匹配，将会发生什么。
+  在上面的例子中，如果移除新 Pod 上的标签，Pod 仍然可以调度到 "zoneB"，因为约束仍然满足。
+  然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 Pod，
+  zoneB 有 1 个带有 {foo:bar} 标签的 Pod。
+  因此，如果这不是你所期望的，建议工作负载的 `topologySpreadConstraints[*].labelSelector`
+  与其自身的标签匹配。
 
 <!--
 - If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed.
     Suppose you have a 5-node cluster ranging from zoneA to zoneC:
-    and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
 -->
+- 如果新 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，则
+  不匹配的节点会被忽略。
 
-- 如果传入的 pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，则将忽略不匹配的节点。
+  假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
 
-    假设有一个从 zonea 到 zonec 的 5 节点集群：
+  {{<mermaid>}}
+  graph BT
+      subgraph "zoneB"
+          p3(Pod) --> n3(Node3)
+          n4(Node4)
+      end
+      subgraph "zoneA"
+          p1(Pod) --> n1(Node1)
+          p2(Pod) --> n2(Node2)
+      end
 
-    ```
-    +---------------+---------------+-------+
-    |     zoneA     |     zoneB     | zoneC |
-    +-------+-------+-------+-------+-------+
-    | node1 | node2 | node3 | node4 | node5 |
-    +-------+-------+-------+-------+-------+
-    |   P   |   P   |   P   |       |       |
-    +-------+-------+-------+-------+-------+
-    ```
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class n1,n2,n3,n4,p1,p2,p3 k8s;
+  class p4 plain;
+  class zoneA,zoneB cluster;
+  {{< /mermaid >}}
 
-    你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml，以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector` 也要一样处理。
+  {{<mermaid>}}
+  graph BT
+      subgraph "zoneC"
+          n5(Node5)
+      end
 
-    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class n5 k8s;
+  class zoneC cluster;
+  {{< /mermaid >}}
+
+  <!--
+  and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
+  -->
+  而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml，
+  以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
+  也要一样处理。
+
+  {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+
+<!--
+### Cluster-level default constraints
+
+It is possible to set default topology spread constraints for a cluster. Default
+topology spread constraints are applied to a Pod if, and only if:
+
+- It doesn't define any constraints in its `.spec.topologySpreadConstraints`.
+- It belongs to a service, replication controller, replica set or stateful set.
+-->
+### 集群级别的默认约束   {#cluster-level-default-constraints}
+
+为集群设置默认的拓扑分布约束也是可能的。默认拓扑分布约束在且仅在以下条件满足
+时才会应用到 Pod 上：
+
+- Pod 没有在其 `.spec.topologySpreadConstraints` 设置任何约束；
+- Pod 隶属于某个服务、副本控制器、ReplicaSet 或 StatefulSet。
+
+<!--
+Default constraints can be set as part of the `PodTopologySpread` plugin args
+in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
+The constraints are specified with the same [API above](#api), except that
+`labelSelector` must be empty. The selectors are calculated from the services,
+replication controllers, replica sets or stateful sets that the Pod belongs to.
+
+An example configuration might look like follows:
+-->
+你可以在 [调度方案（Schedulingg Profile）](/zh/docs/reference/scheduling/config/#profiles)
+中将默认约束作为 `PodTopologySpread` 插件参数的一部分来设置。
+约束的设置采用[如前所述的 API](#api)，只是 `labelSelector` 必须为空。
+选择算符是根据 Pod 所属的服务、副本控制器、ReplicaSet 或 StatefulSet 来设置的。
+
+配置的示例可能看起来像下面这个样子：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints:
+            - maxSkew: 1
+              topologyKey: topology.kubernetes.io/zone
+              whenUnsatisfiable: ScheduleAnyway
+```
+
+{{< note >}}
+<!--
+The score produced by default scheduling constraints might conflict with the
+score produced by the
+[`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins).
+It is recommended that you disable this plugin in the scheduling profile when
+using default constraints for `PodTopologySpread`.
+-->
+默认调度约束所生成的评分可能与
+[`SelectorSpread` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins).
+所生成的评分有冲突。
+建议你在为 `PodTopologySpread` 设置默认约束是禁用调度方案中的该插件。
+{{< /note >}}
+
+<!--
+#### Internal default constraints
+-->
+#### 内部默认约束    {#internal-default-constraints}
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+<!--
+When you enable the `DefaultPodTopologySpread` feature gate, the
+legacy `SelectorSpread` plugin is disabled.
+kube-scheduler uses the following default topology constraints for the
+`PodTopologySpread` plugin configuration:
+-->
+当你启用了 `DefaultPodTopologySpread` 特性门控时，原来的
+`SelectorSpread` 插件会被禁用。
+kube-scheduler 会使用下面的默认拓扑约束作为 `PodTopologySpread` 插件的
+配置：
+
+```yaml
+defaultConstraints:
+  - maxSkew: 3
+    topologyKey: "kubernetes.io/hostname"
+    whenUnsatisfiable: ScheduleAnyway
+  - maxSkew: 5
+    topologyKey: "topology.kubernetes.io/zone"
+    whenUnsatisfiable: ScheduleAnyway
+```
+
+<!--
+Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
+is disabled.
+-->
+此外，原来用于提供等同行为的 `SelectorSpread` 插件也会被禁用。
+
+<!--
+If your nodes are not expected to have **both** `kubernetes.io/hostname` and
+`topology.kubernetes.io/zone` labels set, define your own constraints
+instead of using the Kubernetes defaults.
+
+The `PodTopologySpread` plugin does not score the nodes that don't have
+the topology keys specified in the spreading constraints.
+-->
+{{< note >}}
+如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和
+`topology.kubernetes.io/zone` 标签，你应该定义自己的约束而不是使用
+Kubernetes 的默认约束。
+
+插件 `PodTopologySpread` 不会为未设置分布约束中所给拓扑键的节点评分。
+{{< /note >}}
 
 <!--
 ## Comparison with PodAffinity/PodAntiAffinity
@@ -334,7 +572,7 @@ scheduled - more packed or more scattered.
 -->
 ## 与 PodAffinity/PodAntiAffinity 相比较
 
-在 Kubernetes 中，与 "Affinity" 相关的指令控制 pod 的调度方式（更密集或更分散）。
+在 Kubernetes 中，与“亲和性”相关的指令控制 Pod 的调度方式（更密集或更分散）。
 
 <!--
 - For `PodAffinity`, you can try to pack any number of Pods into qualifying
@@ -342,34 +580,46 @@ topology domain(s)
 - For `PodAntiAffinity`, only one Pod can be scheduled into a
 single topology domain.
 -->
-- 对于 `PodAffinity`，可以尝试将任意数量的 pod 打包到符合条件的拓扑域中。
-- 对于 `PodAntiAffinity`，只能将一个 pod 调度到单个拓扑域中。
+- 对于 `PodAffinity`，你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
+- 对于 `PodAntiAffinity`，只能将一个 Pod 调度到某个拓扑域中。
 
 <!--
+For finer control, you can specify topology spread constraints to distribute
+Pods across different topology domains - to achieve either high availability or
+cost-saving. This can also help on rolling update workloads and scaling out
+replicas smoothly. See
+[Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
+for more details.
+
+
 The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
 topology domains - to achieve high availability or cost-saving. This can also help on rolling update
 workloads and scaling out replicas smoothly.
 See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
 -->
-"EvenPodsSpread" 功能提供灵活的选项来将 pod 均匀分布到不同的拓扑域中，以实现高可用性或节省成本。
-这也有助于滚动更新工作负载和平滑扩展副本。
-有关详细信息，请参考[动机](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)。
+要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，
+从而实现高可用性或节省成本。这也有助于工作负载的滚动更新和平稳地扩展副本规模。
+有关详细信息，请参考
+[动机](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)文档。
 
 <!--
 ## Known Limitations
 
-As of 1.16, at which this feature is Alpha, there are some known limitations:
--->
-
-## 已知局限性
-
-1.16 版本（此功能为 alpha）存在下面的一些限制：
-
-<!--
-- Scaling down a `Deployment` may result in imbalanced Pods distribution.
+- Scaling down a Deployment may result in imbalanced Pods distribution.
 - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
 -->
-- `Deployment` 的缩容可能导致 pod 分布不平衡。
-- pod 匹配到污点节点是允许的。参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
+## 已知局限性
 
+- Deployment 缩容操作可能导致 Pod 分布不平衡。
+- 具有污点的节点上的 Pods 也会被统计。
+  参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- [Blog: Introducing PodTopologySpread](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)
+  explains `maxSkew` in details, as well as bringing up some advanced usage examples.
+-->
+- [博客: PodTopologySpread介绍](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)
+  详细解释了 `maxSkew`，并给出了一些高级的使用示例。
 
diff --git a/content/zh/docs/concepts/workloads/pods/podpreset.md b/content/zh/docs/concepts/workloads/pods/podpreset.md
index f4e0f85675..bb17654ddb 100644
--- a/content/zh/docs/concepts/workloads/pods/podpreset.md
+++ b/content/zh/docs/concepts/workloads/pods/podpreset.md
@@ -126,7 +126,7 @@ the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
 一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset` 
 可能不应用于任何 Pod，也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时，Kubernetes
 修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod
-中所有容器的规格，对于卷的改动，Kubernetes 会修改 Pod 规约。
+中所有容器 spec，对于卷的改动，Kubernetes 会修改 Pod spec。
 
 <!--
 A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
diff --git a/content/zh/docs/contribute/_index.md b/content/zh/docs/contribute/_index.md
index 0acea1e84a..79b23667aa 100644
--- a/content/zh/docs/contribute/_index.md
+++ b/content/zh/docs/contribute/_index.md
@@ -1,9 +1,190 @@
 ---
-title: 贡献新内容
-weight: 20
+content_type: concept
+title: 贡献 Kubernetes 文档
+linktitle: 贡献
+main_menu: true
+no_list: true
+weight: 80
+card:
+  name: contribute
+  weight: 10
+  title: 开始贡献
 ---
+<!--
+---
+content_type: concept
+title: Contribute to Kubernetes docs
+linktitle: Contribute
+main_menu: true
+no_list: true
+weight: 80
+card:
+  name: contribute
+  weight: 10
+  title: Start contributing
+---
+-->
+
+<!-- overview -->
 
 <!--
-title: Contributing new content
-weight: 20
+This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
+
+Kubernetes documentation contributors:
+
+- Improve existing content
+- Create new content
+- Translate the documentation
+- Manage and publish the documentation parts of the Kubernetes release cycle
+
+Kubernetes documentation welcomes improvements from all contributors, new and experienced!
 -->
+
+本网站由 [Kubernetes SIG（特别兴趣小组） Docs](/zh/docs/contribute/#get-involved-with-SIG-Docs) 维护.
+
+Kubernetes 文档项目的贡献者:
+
+- 改进现有内容
+- 创建新内容
+- 翻译文档
+- 管理并发布 Kubernetes 周期性发行版的文档
+
+Kubernetes 文档欢迎来自各方贡献者的改进，无论新手还是高手！
+
+<!-- body -->
+
+<!-- 
+## Getting started
+
+Anyone can open an issue about documentation, or contribute a change with a
+pull request (PR) to the
+[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website).
+You need to be comfortable with
+[git](https://git-scm.com/) and
+[GitHub](https://lab.github.com/)
+to work effectively in the Kubernetes community.
+
+To get involved with documentation:
+
+1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
+1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+   and the website's [static site generator](https://gohugo.io).
+1. Make sure you understand the basic processes for
+   [opening a pull request](/docs/contribute/new-content/open-a-pr/) and
+   [reviewing changes](/docs/contribute/review/reviewing-prs/).
+
+Some tasks require more trust and more access in the Kubernetes organization.
+See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
+roles and permissions.
+-->
+## 入门 {#getting-started}
+
+任何人都可以提出文档方面的问题（issue），或贡献一个变更，用拉取请求（PR）的方式提交到
+[GitHub 上的 `kubernetes/website` 仓库](https://github.com/kubernetes/website)。
+当然你需要熟练使用 [git](https://git-scm.com/) 和 [GitHub](https://lab.github.com/) 才能在 Kubernetes 社区中有效工作。
+
+参与文档编制:
+
+1. 签署 CNCF 的[贡献者许可协议](https://github.com/kubernetes/community/blob/master/CLA.md)。
+2. 熟悉[文档仓库](https://github.com/kubernetes/website)
+   和网站的[静态站点生成器](https://gohugo.io)。
+3. 确保理解
+   [发起 PR](/zh/docs/contribute/new-content/open-a-pr/) 和
+   [审查变更](/zh/docs/contribute/review/reviewing-prs/)的基本流程。
+
+有些任务要求 Kubernetes 组织内更高的信任级别和访问权限。
+阅读[参与 SIG Docs 工作](/zh/docs/contribute/participate/) ，获取角色和权限的更多细节。
+
+<!--
+## Your first contribution
+
+- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
+  learn about the different ways you can contribute.
+- Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/)
+  for issues that make good entry points.
+- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github)
+  to existing documentation and learn more about filing issues in GitHub.
+- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other
+  Kubernetes community members for accuracy and language.
+- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and
+  [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
+- Learn about [page content types](/docs/contribute/style/page-content-types/)
+  and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
+-->
+## 第一次贡献 {#your-first-contribution}
+
+- 通读[贡献概述](/zh/docs/contribute/new-content/overview/)，了解参与贡献的不同方式。
+- 查看[`kubernetes/website` 问题列表](https://github.com/kubernetes/website/issues/)
+  ，检索最适合作为切入点的问题。
+- 在现有文档上，
+  [使用 GitHub 提交 PR ](/zh/docs/contribute/new-content/open-a-pr/#changes-using-github)，
+  掌握在 GitHub 上登记 Issue 的方法。
+- Kubernetes 社区其他成员会[评审 PR ](/zh/docs/contribute/review/reviewing-prs/)，
+  以确保文档精准和语言流畅。
+- 阅读 kubernetes 的[内容指南](/zh/docs/contribute/style/content-guide/)和
+  [风格指南](/zh/docs/contribute/style/style-guide/)，以发表有见地的评论。
+- 了解[页面内容类型](/zh/docs/contribute/style/page-content-types/)和 
+  [Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)。
+
+<!--
+## Next steps
+
+- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo)
+  of the repository.
+- Document [features in a release](/docs/contribute/new-content/new-features/).
+- Participate in [SIG Docs](/docs/contribute/participate/), and become a
+  [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/).
+                       
+- Start or help with a [localization](/docs/contribute/localization/).
+-->
+## 下一步 {#next-teps}
+
+- 学习在仓库的[本地克隆中工作](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
+- 为[发行版的特性](/zh/docs/contribute/new-content/new-features/)编写文档。
+- 加入 [SIG Docs](/zh/docs/contribute/participate/), 并成为[成员或评审者](/zh/docs/contribute/participate/roles-and-responsibilities/)。
+                       
+- 开始或帮助[本地化](/zh/docs/contribute/localization/) 工作。
+
+<!--
+## Get involved with SIG Docs
+
+[SIG Docs](/docs/contribute/participate/) is the group of contributors who
+publish and maintain Kubernetes documentation and the website. Getting
+involved with SIG Docs is a great way for Kubernetes contributors (feature
+development or otherwise) to have a large impact on the Kubernetes project.
+
+SIG Docs communicates with different methods:
+
+- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to
+  introduce yourself!
+- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
+  where broader discussions take place and official decisions are recorded.
+- Join the [weekly SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs). Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
+-->
+## 参与 SIG Docs 工作 {#get-involved-with-SIG-Docs}
+
+[SIG Docs](/zh/docs/contribute/participate/) 是负责发布、维护 Kubernetes 文档的贡献者团体。
+参与 SIG Docs 是 Kubernetes 贡献者（开发者和其他人员）对 Kubernetes 项目产生重大影响力的好方式。
+
+SIG Docs 的几种沟通方式:
+
+- [加入 Kubernetes 在 Slack 上的`#sig-docs` 频道](https://slack.k8s.io/)。
+  一定记得自我介绍!
+- [加入`kubernetes-sig-docs` 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
+  这里有更广泛的讨论，和官方决策的记录。
+- 参加 [SIG Docs 的每周视频会议](https://github.com/kubernetes/community/tree/master/sig-docs)。会议总是在 `#sig-docs` 上宣告，同时添加到 
+  [Kubernetes社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。
+  你需要下载 [Zoom 客户端软件](https://zoom.us/download)，或电话拨号接入。
+
+<!--
+## Other ways to contribute
+
+- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
+- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
+- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
+-->
+## 其他贡献方式 {#other-ways-to-contribute}
+
+- 访问 [Kubernetes 社区网站](/zh/community/)。 参与 Twitter 或 Stack Overflow, 了解 Kubernetes 当地的聚会和活动, 等等。
+- 阅读[贡献者备忘单](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)，参与 Kubernetes 功能开发。
+- 提交一篇[博客文章或案例研究](/zh/docs/contribute/new-content/blogs-case-studies/)。
diff --git a/content/zh/docs/contribute/localization.md b/content/zh/docs/contribute/localization.md
index 2241265ec2..5ad2b88a87 100644
--- a/content/zh/docs/contribute/localization.md
+++ b/content/zh/docs/contribute/localization.md
@@ -3,7 +3,7 @@ title: 本地化 Kubernetes 文档
 content_type: concept
 weight: 50
 card:
-  name: 贡献
+  name: contribute
   weight: 50
   title: 翻译文档
 ---
@@ -455,7 +455,7 @@ Some language teams have their own language-specific style guide and glossary. F
 ### 特定语言的样式指南和词汇表
 
 一些语言团队有自己的特定语言样式指南和词汇表。
-例如，请参见[韩语本地化指南](/ko/docs/contribute/localization_ko/)。
+例如，请参见[中文本地化指南](/zh/docs/contribute/localization_zh/)。
 
 <!-- 
 ## Branching strategy 
diff --git a/content/zh/docs/contribute/localization_zh.md b/content/zh/docs/contribute/localization_zh.md
new file mode 100644
index 0000000000..38e5ee8000
--- /dev/null
+++ b/content/zh/docs/contribute/localization_zh.md
@@ -0,0 +1,485 @@
+---
+title: 中文本地化样式指南
+content_type: concept
+---
+
+<!-- overview -->
+
+本节详述文档中文本地化过程中须注意的事项。
+这里列举的内容包含了*中文本地化小组*早期给出的指导性建议和后续实践过程中
+积累的经验。
+在阅读、贡献、评阅中文本地化文档的过程中，如果对本文的指南有任何改进建议，
+都请直接提出 PR。我们欢迎任何形式的补充和更正！
+
+<!-- body -->
+
+## 一般规定
+
+本节列举一些译文中常见问题和约定。
+
+### 英文原文的保留
+
+为便于译文审查和变更追踪，所有中文本地化 Markdown 文件中都应使用 HTML 注释
+`<!--` 和 `-->` 将英文原文逐段注释起来，后跟对应中文译文。例如：
+
+```
+<!--
+This is English text ... 
+-->
+中文译文对应 ...
+```
+
+不建议采用下面的方式注释英文段落，除非英文段落非常非常短：
+
+```
+<!-- This is English text ...  -->
+中文译文对应 ...
+
+```
+
+无论英文原文或者中文译文中，都不要保留过多的、不必要的空白行。
+
+#### 段落划分
+
+请避免大段大段地注释和翻译。一般而言，每段翻译可对应两三个自然段。
+段落过长会导致译文很难评阅。但也不必每个段落都单独翻译。例如：
+
+```
+<!--
+## Overview
+
+### Concept
+
+First paragraph, not very long.
+-->
+## 概述 {#overview}
+
+### 概念 {#concept}
+
+第一段落，不太长。
+```
+
+以下风格是不必要的：
+
+```
+<!--
+## Overview
+-->
+## 概述 {#overview}
+
+<!--
+### Concept
+-->
+### 概念 {#concept}
+
+<!--
+First paragraph, not very long.
+-->
+第一段落，不太长。
+```
+
+#### 编号列表的处理
+
+编号列表需要编号的连续性，处理不好的话可能导致输出结果错误。
+由于有些列表可能很长，一次性等将整个列表注释掉再翻译也不现实。
+推荐采用下面的方式。
+
+假定英文为：
+
+```
+1. Prepare something
+1. Followed by a long step with code snippets and notes ...
+   this is a really long item
+1. Another long item ...
+   .. continues here
+1. Almost done ...
+```
+
+本地化处理：
+
+```
+<!--
+1. Prepare something
+-->
+1. 准备工作，...
+   这里每行缩进 3 个空格
+
+<!--
+1. Followed by a long step with code snippets and notes ...
+   this is a really long item
+-->
+2. 这里是第二个编号，但需要显式给出数字，不能沿用英文编号。
+   缩进内容同上，3 个空格。
+   即使有三个反引号的代码段或者短代码，都按 3 个空格缩进。
+
+<!--
+1. Another long item ...
+   .. continues here
+1. Almost done ...
+-->
+3. 继续列表。
+
+   如果条目有多个段落，也要
+   保持缩进对齐以确保排版正确。
+
+4. 列表终于结束
+```
+
+#### Frontmatter 的处理
+
+页面中的 Frontmatter 指的是文件头的两个 `---` 中间的部分。
+对这一部分，解析器有特殊处理，因此不能将英文部分放在前面，中文跟在后面。
+需要将二者顺序颠倒。如下所示：
+
+```
+---
+title: 译文标题
+type: concept
+weight: 30
+---
+
+<!--
+title: English title
+type: concept
+reviewers:
+  - john
+  - doe
+weight: 30
+-->
+```
+
+这里要注意的是：
+
+- `title`、`description` 的内容要翻译，其他字段一般不必（甚至不可）翻译。
+- `reviewers` 部分要删除，不然中文译文会转给英文作者来审阅。
+
+
+#### 短代码（shortcode）处理
+
+通过 HTML 注释的短代码仍会被运行，因此需要额外小心。建议处理方式：
+
+```
+<!--
+English text
+-->
+{{</* note */>}}
+中文译文
+{{</* /note */>}}
+```
+
+评阅人应该不难理解中英文段落的对应关系。但是如果采用下面的方式，则会出现
+两个 `note`，因此需要避免。这是因为被注释起来的短代码仍会起作用！
+
+```
+<!--
+{{</* note */>}}
+English text
+{{</* /note */>}}
+-->
+{{</* note */>}}
+中文译文
+{{</* /note */>}}
+```
+
+### 译与不译
+
+#### 资源名称或字段不译
+
+根据英文原文写作风格约定【也在持续修订改进】，对 Kubernetes 中的 API
+资源均按其规范中所给的大小写形式书写，例如：英文中会使用 Deployment 而不是
+deployment 来表示名为 "Deployment" 的 API 资源类型和对象实例。
+
+对这类词语，一般不应翻译。
+
+{{< note >}}
+英文原文在这方面并不严谨，译者或中文译文的评阅者要非常留心。
+比如 Secret 资源，很多时候被误写为 secret。这时在本地化版本中一定
+不能译为“秘密”，以免与原文的语义不符。
+{{< /note >}}
+
+#### 代码中的注释
+
+一般而言，代码中的注释需要翻译，包括存放在 `content/zh/examples/` 目录下
+的清单文件中的注释。
+
+
+#### 出站链接
+
+如果超级链接的目标是 Kubernetes 网站之外的纯英文网页，链接中的内容*可以*不翻译。
+例如：
+
+```
+<!--
+Please check [installation caveats](https://acme.com/docs/v1/caveats) ...
+-->
+请参阅 [installation caveats](https://acme.com/docs/v1/caveats) ...
+```
+
+注意，这里的 `installation` 与 `参阅` 之间留白，因为解析后属于中英文混排的情况。
+
+### 标点符号
+
+译文中标点符号要使用全角字符，除非以下两种情况：
+
+- 标点符号是英文命令的一部分；
+- 标点符号是 Markdown 语法的一部分。
+
+英文排比句式中采用的逗号，在译文中要使用顿号代替，复合中文书写习惯。
+
+## 更新译文
+
+由于整个文档站点会随着 Kubernetes 项目的开发进展而演化，英文版本的网站内容
+会不断更新。鉴于中文站点的基本翻译工作在 1.19 版本已完成，从 1.20 版本开始
+本地化的工作会集中在追踪英文内容变化上。
+
+为确保准确跟踪中文化版本与英文版本之间的差异，中文内容的 PR 所包含的每个页面
+都必须是“最新的”。这里的“最新”指的是对应的英文页面中的更改已全部同步到中文页面。
+如果某中文 PR 中包含对 `content/zh/docs/foo/bar.md` 的更改，且文件 `bar.md` 的
+上次更改日期是 `2020-10-01 01:02:03 UTC`，对应 GIT 标签 `abcd1234`，则
+`bar.md` 应包含自 `abcd1234` 以来 `content/en/docs/foo/bar.md` 的所有变更，
+否则视此 PR 为不完整 PR，会破坏我们对上游变更的跟踪。
+
+这一要求适用于所有更改，包括拼写错误、格式更正、链接修订等等。要查看文件
+`bar.md` 上次提交以来发生的所有变更，可使用：
+
+```
+./scripts/lsync.sh content/zh/docs/foo/bar.md
+```
+
+## 关于链接
+
+### 链接锚点
+
+英文 Markdown 中的各级标题会自动生成锚点，以便从其他页面中链接。
+在译为中文后，相应的链接必然会失效。为防止这类问题，建议在翻译
+各级标题时，使用英文方式显式给出链接锚点。例如：
+
+```
+<!--
+### Create a Pod
+-->
+### 创建 Pod   {#create-a-pod}
+```
+
+此类问题对于概念部分的页面最为突出，需要格外注意。
+
+
+### 中文链接目标
+
+由于大部分页面已经完成中文本地化，这意味着很多链接可以使用中文版本作为目标。
+例如：
+
+```
+<!--
+For more information, please check [volumes](/docs/concepts/storage/)
+...
+-->
+更多的信息可参考[卷](/zh/docs/concepts/storage/)页面。
+```
+
+如果对应目标页面尚未本地化，建议登记一个 Issue。
+
+{{< note >}}
+Website 的仓库中 `scripts/linkchecker.py` 是一个工具，可用来检查页面中的链接。
+例如，下面的命令检查中文本地化目录 `/content/zh/docs/concepts/containers/`
+中所有 Markdown 文件中的链接合法性：
+
+```
+./scripts/linkchecker.py -l zh -f /docs/concepts/containers/**/*.md
+```
+{{< /note >}}
+
+## 排版格式
+
+以下为译文 Markdown 排版格式要求：
+
+- 中英文之间留一个空格
+  * 这里的“英文”包括以英文呈现的超级链接
+  * 这里的中文、英文都不包括标点符号
+- 译文 Markdown 中不要使用长行，应适当断行。
+  * 可根据需要在 80-120 列断行
+  * 最好结合句子的边界断行，即一句话在一行，不必留几个字转到下一行
+  * 超级链接文字一般较长，可独立成行
+
+{{< warning >}}
+我们注意到有些贡献者可能使用了某种自动化工具，在 Markdown 英文原文中自动
+添加空格。虽然这些工具可一定程度提高效率，仍然需要提请作者注意，某些工具
+所作的转换可能是不对的，例如将 `foo=bar` 转换为 `foo = bar`、将
+`），另一些文字` 转换为 `） ，另一些文字` 等等，甚至将超级链接中的半角
+井号（`#`）转换为全角，导致链接失效。
+{{< /warning >}}
+
+英文中 "you" 翻译成 "你" 不必是 “您"
+文章内的链接用英文例如 (#deploying )，在对应的标题上后面加上 {#deploying}
+
+
+## 术语
+
+### 术语拼写
+
+按中文译文习惯，尽量不要在中文译文中使用首字母小写的拼写。例如：
+
+```
+列举所有 pods，查看其创建时间 ...       [No]
+列举所有 Pod，查看其创建时间 ...        [Yes]
+```
+
+*第一次*使用首字母缩写时，应标注其全称和中文译文。例如：
+
+```
+你可以创建一个 Pod 干扰预算（Pod Disruption Budget，PDB）来解决这一问题。
+所谓 PDB 实际上是 ...
+```
+
+对于某些特定于 Kubernetes 语境的术语，也应在*第一次*出现在页面中时给出其英文原文，
+以便读者对照阅读。例如：
+
+```
+镜像策略（Image Policy）用来控制集群可拉取的镜像仓库（Image Registry）源。
+```
+
+### 术语对照
+
+本节列举常见术语的统一译法。除极个别情况，对于专业术语应使用本节所列举的译法：
+
+- API Server，API 服务器
+- GA (general availability)，正式发布
+- addons，插件
+- admission controller，准入控制器
+- affinity，亲和性
+- annotation，注解
+- anti-affinity，反亲和性
+- attach，挂接
+- autoscale，自动扩缩容
+- bearer token，持有者令牌
+- capabilities权能字
+  * 当泛指某主体执行某操作的能力时，可直译为“能力”
+  * 当特指 Linux 操作系统上的[权限控制](http://man7.org/linux/man-pages/man7/capabilities.7.html)机制时，译为“权能字”
+- certificate authority，证书机构
+- certificate，证书
+- claim，申领
+- cloud provider
+  * 当用来指代下层云服务的提供厂商时，译为“云服务供应商”
+  * 当特指 Kubernetes 中对不同云平台的支持时，可酌情译为“云驱动”
+- cluster，集群
+- condition
+  * 大多数上下文中，可译为“条件”
+  * 在讨论 Kubernetes 资源的 condition 时，应译为“状况”
+- control loop，控制回路
+- control plane，控制平面，或控制面
+- controller，控制器
+- controller manager，控制器管理器
+- credential，登录凭据，凭据
+- custom，定制，或自定义
+- daemon，守护进程
+- dashboard，仪表板
+- dependent，附属或附属者
+- deprecated，已弃用的
+- deprecation，弃用
+- desired，预期的
+- desired state，预期状态
+- detach，解除挂接
+- distribution，发行版本
+- disruption，干扰（请勿译为“中断”）
+- drain，腾空
+- endpoint，端点
+- egress，出站
+- evict，驱逐
+- eviction，驱逐
+- feature gate，特性门控
+- federation，联邦
+- flags，命令行参数，参数
+- grace period，宽限期限
+- graceful termination，体面终止
+- hairpin，发夹
+- hash，哈希
+- headless service，无头服务
+- healthcheck，健康检查
+- hook，回调
+- host，主机，宿主机
+- hosting，托管
+- idempotent，幂等的
+- image，镜像
+- image registry，镜像仓库
+- ingress，入站
+- init container，Init 容器
+- key
+  * 在加密解密、安全认证上下文中，译为密钥
+  * 在配置文件、数据结构上下文中，译为主键，或键
+- label，标签
+- label selector，标签选择算符
+- lifecycle，生命周期
+- limit，限制，限值
+- liveness probe，存活态探针
+- load balance，负载均衡
+- load balancer，负载均衡器
+- log flush，清刷日志数据
+- loopback，本地回路
+- manifest，清单，清单文件
+- master node，主控节点
+- metric
+  * 用来指代被测量的数据源时，译为指标
+  * 用来指代测量观测结果时，译为度量值
+- mount，挂载
+- namespace，名字空间，命名空间
+- orphans，孤立或孤立的
+- override，覆写
+- owner，所有者，属主
+- pending，悬决的
+- persistent volume，持久卷
+- persistent volume claim，持久卷申领
+- pipeline，流水线
+- prerequisites，依赖，前提条件（根据上下文判断）
+- priority class，优先级类
+- probe，探针
+- provision，供应
+- pull，拉取
+- push，推送
+- quota，配额
+- readiness probe，就绪态探针
+- replica，副本
+- repo，仓库
+- repository，仓库
+- revision，修订版本
+- role，角色
+- role binding，角色绑定
+- rolling update，滚动更新
+- rollout，上线
+- rotate，轮换
+- round robin，轮转
+- runtime，运行时
+- scale in/out，横向缩容/扩容
+- scale up/down，纵向扩容/缩容
+- scale
+  * 做动词用时，译为“扩缩”，或者“改变...的规模”
+  * 做名词用时，译为“规模”
+- scheduler，调度器
+- service，服务
+- service account，服务账号
+- service account token，服务账号令牌
+- service discovery，服务发现
+- service mesh，服务网格
+- session，会话
+- sidecar，挂斗
+- skew，偏移
+- spec，规约
+- specification，规约
+- startup probe，启动探针
+- stateless，无状态的
+- static pod，静态 Pod
+- stderr，标准错误输出
+- stdin，标准输入
+- stdout，标准输出
+- storage class，存储类
+- taint，污点
+- threshold，阈值
+- toleration，容忍度
+- topology，拓扑
+- topology spread constraint，拓扑分布约束
+- traffic，流量
+  * 在某些上下文中，可以根据情况译为“服务请求”，“服务响应”
+- unmount，卸载
+- use case，用例，使用场景
+- volume，卷
+- worker node，工作节点
+- workload，工作负载
diff --git a/content/zh/docs/contribute/new-content/new-features.md b/content/zh/docs/contribute/new-content/new-features.md
index 5979fcef0b..3d261e956d 100644
--- a/content/zh/docs/contribute/new-content/new-features.md
+++ b/content/zh/docs/contribute/new-content/new-features.md
@@ -5,7 +5,7 @@ content_type: concept
 main_menu: true
 weight: 20
 card:
-  name: 贡献
+  name: contribute
   weight: 45
   title: 为发行版本撰写功能特性文档 
 ---
diff --git a/content/zh/docs/contribute/new-content/open-a-pr.md b/content/zh/docs/contribute/new-content/open-a-pr.md
index ed3476ca9b..53334aec6b 100644
--- a/content/zh/docs/contribute/new-content/open-a-pr.md
+++ b/content/zh/docs/contribute/new-content/open-a-pr.md
@@ -3,7 +3,7 @@ title: 发起拉取请求（PR）
 content_type: concept
 weight: 10
 card:
-  name: 贡献
+  name: contribute
   weight: 40
 ---
 <!--
diff --git a/content/zh/docs/contribute/new-content/overview.md b/content/zh/docs/contribute/new-content/overview.md
index 0deead5b8d..51cf482b7b 100644
--- a/content/zh/docs/contribute/new-content/overview.md
+++ b/content/zh/docs/contribute/new-content/overview.md
@@ -87,7 +87,7 @@ If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
 场景      | 分支
 :---------|:------------
 针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `master`
-针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-release-<version>`。例如，如果某功能特性在 `{{< latest-version >}}` 版本发生变化，则对应的文档变化要添加到 `dev-{{< release-branch >}}` 分支。
+针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-<version>`。例如，如果某功能特性在 `v{{< skew nextMinorVersion >}}` 版本发生变化，则对应的文档变化要添加到 ``dev-{{< skew nextMinorVersion >}}`` 分支。
 其他语言的内容（本地化）| 基于本地化团队的约定。参见[本地化分支策略](/zh/docs/contribute/localization/#branching-strategy)了解更多信息。
 
 如果你仍不能确定要选择哪个分支，请在 `#sig-docs` Slack 频道上提问。
diff --git a/content/zh/docs/contribute/review/for-approvers.md b/content/zh/docs/contribute/review/for-approvers.md
index b801e7efcf..5982ce7078 100644
--- a/content/zh/docs/contribute/review/for-approvers.md
+++ b/content/zh/docs/contribute/review/for-approvers.md
@@ -385,7 +385,7 @@ Issue，不必修复。
 
 Some docs issues are actually issues with the underlying code, or requests for
 assistance when something, for example a tutorial, doesn't work.
-For issues unrelated to docs, close the issue with the `triage/support` label and a comment
+For issues unrelated to docs, close the issue with the `kind/support` label and a comment
 directing the requester to support venues (Slack, Stack Overflow) and, if
 relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
 is a great place to start).
@@ -396,7 +396,7 @@ Sample response to a request for support:
 
 某些文档 Issues 实际上是关于底层代码的 Issue 或者在某方面请求协助的问题，
 例如某个教程无法正常工作。
-对于与文档无关的 Issues，关闭它并打上标签 `triage/support`，可以通过评论
+对于与文档无关的 Issues，关闭它并打上标签 `kind/support`，可以通过评论
 告知请求者其他支持渠道（Slack、Stack Overflow）。
 如果有相关的其他仓库，可以告诉请求者应该在哪个仓库登记与功能特性相关的 Issues
 （通常会是 `kubernetes/kubernetes`）。
diff --git a/content/zh/docs/contribute/style/content-organization.md b/content/zh/docs/contribute/style/content-organization.md
index cd9ebcd0b1..eb35c80b5f 100644
--- a/content/zh/docs/contribute/style/content-organization.md
+++ b/content/zh/docs/contribute/style/content-organization.md
@@ -180,8 +180,6 @@ Another widely used example is the `includes` bundle. It sets `headless: true` i
 ```bash
 en/includes
 ├── default-storage-class-prereqs.md
-├── federated-task-tutorial-prereqs.md
-├── federation-content-moved.md
 ├── index.md
 ├── partner-script.js
 ├── partner-style.css
diff --git a/content/zh/docs/contribute/style/page-content-types.md b/content/zh/docs/contribute/style/page-content-types.md
index a5526383f5..de72b6b4c4 100644
--- a/content/zh/docs/contribute/style/page-content-types.md
+++ b/content/zh/docs/contribute/style/page-content-types.md
@@ -3,7 +3,7 @@ title: 页面内容类型
 content_type: concept
 weight: 30
 card:
-  name: 贡献
+  name: contribute
   weight: 30
 ---
 <!--
diff --git a/content/zh/docs/contribute/suggesting-improvements.md b/content/zh/docs/contribute/suggesting-improvements.md
index 63383e5637..fe5b469f84 100644
--- a/content/zh/docs/contribute/suggesting-improvements.md
+++ b/content/zh/docs/contribute/suggesting-improvements.md
@@ -4,7 +4,7 @@ slug: suggest-improvements
 content_type: concept
 weight: 10
 card:
-  name: 贡献
+  name: contribute
   weight: 20
 ---
 <!--
diff --git a/content/zh/docs/doc-contributor-tools/README.md b/content/zh/docs/doc-contributor-tools/README.md
deleted file mode 100644
index fe0e37a2c7..0000000000
--- a/content/zh/docs/doc-contributor-tools/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-Kubernetes 文档贡献者的工具。 查看子目录内的 `README.md` 文件以获取更多信息。
-
-
-<!--
-Tools for Kubernetes docs contributors. View `README.md` files in
-subdirectories for more info.
--->
diff --git a/content/zh/docs/doc-contributor-tools/linkchecker/README.md b/content/zh/docs/doc-contributor-tools/linkchecker/README.md
new file mode 100644
index 0000000000..016907c2eb
--- /dev/null
+++ b/content/zh/docs/doc-contributor-tools/linkchecker/README.md
@@ -0,0 +1,161 @@
+<!-- 
+# Internal link checking tool
+ -->
+# 内置链接检查工具
+
+<!-- 
+You can use [htmltest](https://github.com/wjdp/htmltest) to check for broken links in [`/content/en/`](https://git.k8s.io/website/content/en/). This is useful when refactoring sections of content, moving pages around, or renaming files or page headers.
+ -->
+你可以使用 [htmltest](https://github.com/wjdp/htmltest) 来检查 [`/content/en/`](https://git.k8s.io/website/content/en/) 下面的失效链接。这在重构章节内容、移动页面或者重命名文件或页眉时非常有用。
+
+<!-- 
+## How the tool works
+ -->
+## 工作原理
+
+<!-- 
+`htmltest` scans links in the generated HTML files of the kubernetes website repository. It runs using a `make` command which does the following:
+ -->
+`htmltest` 会扫描 kubernetes website 仓库构建生成的 HTML 文件。通过执行 `make` 命令进行了下列操作：
+
+<!-- 
+- Builds the site and generates output HTML in the `/public` directory of your local `kubernetes/website` repository
+- Pulls the `wdjp/htmltest` Docker image
+- Mounts your local `kubernetes/website` repository to the Docker image
+- Scans the files generated in the `/public` directory and provides command line output when it encounters broken internal links 
+-->
+- 构建站点并输出 HTML 到本地 `kubernetes/website` 仓库下的 `/public` 目录中
+- 拉取 Docker 镜像 `wdjp/htmltest`
+- 挂载本地 `kubernetes/website` 仓库到 Docker 容器中
+- 扫描 `/public` 目录下生成的文件并将遇到的失效链接通过命令行打印出来
+
+<!-- 
+## What it does and doesn't check
+ -->
+## 哪些链接不会检查
+
+<!-- 
+The link checker scans generated HTML files, not raw Markdown. The htmltest tool depends on a configuration file, [`.htmltest.yml`](https://git.k8s.io/website/.htmltest.yml), to determine which content to examine.
+
+The link checker scans the following:
+ -->
+该链接检查器扫描生成的 HTML 文件，而非原始的 Markdown. 该 htmltest 工具依赖于一个配置文件，[`.htmltest.yml`](https://git.k8s.io/website/.htmltest.yml)，来决定检查哪些内容。
+
+该链接检查器扫描以下内容：
+
+<!-- 
+- All content generated from Markdown in [`/content/en/docs`](https://git.k8s.io/website/content/en/docs/) directory, excluding:
+  - Generated API references, for example https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
+- All internal links, excluding:
+  - Empty hashes (`<a href="#">` or `[title](#)`) and empty hrefs (`<a href="">` or `[title]()`)
+  - Internal links to images and other media files
+ -->
+- 所有由 [`/content/en/docs`](https://git.k8s.io/website/content/en/docs/) 目录下的 Markdown 文件生成的内容，但不包括：
+  - 生成的 API 参考，例如 https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
+- 所有的内部链接，但不包括：
+  - 空白锚点 (`<a href="#">` 或 `[title](#)`) 以及空白目标地址  (`<a href="">` 或 `[title]()`)
+  - 指向图片或其他媒体文件的内部链接
+
+<!-- 
+The link checker does not scan the following:
+ -->
+该链接检查器不会扫描以下内容：
+
+<!-- 
+- Links included in the top and side nav bars, footer links, or links in a page's `<head>` section, such as links to CSS stylesheets, scripts, and meta information
+- Top level pages and their children, for example: `/training`, `/community`, `/case-studies/adidas`
+- Blog posts
+- API Reference documentation, for example: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
+- Localizations
+ -->
+- 包含在顶部和侧边导航栏的链接，以及页脚链接或者页面的 `<head>` 部分中的链接，例如 CSS 样式表、脚本以及元信息的链接。
+- 顶级页面及其子页面，例如： `/training`, `/community`, `/case-studies/adidas`
+- 博客文章
+- API 参考文档，例如：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
+- 本地化内容
+
+<!-- 
+## Prerequisites and installation
+ -->
+## 先决条件以及安装说明
+
+<!-- 
+You must install
+ -->
+必须安装：
+* [Docker](https://docs.docker.com/get-docker/)
+* [make](https://www.gnu.org/software/make/)
+ 
+<!-- 
+## Running the link checker
+ -->
+## 运行链接检查器
+
+<!-- 
+To run the link checker:
+ -->
+运行链接检查器需要：
+
+<!-- 
+1. Navigate to the root directory of your local `kubernetes/website` repository.
+
+2. Run the following command:
+ -->
+1. 进入本地 `kubernetes/website` 仓库的根目录下。
+
+2. 执行如下命令：
+
+  ```
+  make docker-internal-linkcheck
+  ```
+
+<!-- 
+## Understanding the output
+ -->
+## 理解输出的内容
+
+<!-- 
+If the link checker finds broken links, the output is similar to the following:
+ -->
+如果链接检查器发现了失效链接，则输出内容类似如下：
+
+```
+tasks/access-kubernetes-api/custom-resources/index.html
+  hash does not exist --- tasks/access-kubernetes-api/custom-resources/index.html --> #preserving-unknown-fields
+  hash does not exist --- tasks/access-kubernetes-api/custom-resources/index.html --> #preserving-unknown-fields
+```
+
+<!-- 
+This is one set of broken links. The log adds an output for each page with broken links.
+
+In this output, the file with broken links is `tasks/access-kubernetes-api/custom-resources.md`.
+
+The tool gives a reason: `hash does not exist`. In most cases, you can ignore this.
+
+The target URL is `#preserving-unknown-fields`.
+
+One way to fix this is to:
+ -->
+这是一系列失效链接。该日志附带了每个页面下的失效链接。
+
+在这部分输出中，包含失效链接的文件是 `tasks/access-kubernetes-api/custom-resources.md`.
+
+该工具给出了一个理由：`hash does not exist`. 在大部分情况下，你可以忽略这个。
+
+目标链接是 `#preserving-unknown-fields`.
+
+修复这个问题的一种方式是：
+
+<!-- 
+1. Navigate to the Markdown file with a broken link.
+2. Using a text editor, do a full-text search (usually Ctrl+F or Command+F) for the broken link's URL, `#preserving-unknown-fields`.
+3. Fix the link. For a broken page hash (or _anchor_) link, check whether the topic was renamed or removed.
+ -->
+1. 转到含有失效链接的 Markdown 文件。
+2. 使用文本编辑器全文搜索失效链接的 URL（通常使用 Ctrl+F 或 Command+F）`#preserving-unknown-fields`.
+3. 修复该链接。对于一个失效的锚点（或者 _anchor_ ）链接，检查该主题是否已更名或者移除。
+
+<!-- 
+Run htmltest to verify that broken links are fixed.
+ -->
+运行 htmltest 来验证失效链接是否已修复。
\ No newline at end of file
diff --git a/content/zh/docs/doc-contributor-tools/snippets/README.md b/content/zh/docs/doc-contributor-tools/snippets/README.md
deleted file mode 100644
index 4058cbd4b6..0000000000
--- a/content/zh/docs/doc-contributor-tools/snippets/README.md
+++ /dev/null
@@ -1,84 +0,0 @@
-<!-- # Snippets for Atom -->
-# Atom 的代码段
-
-<!-- Snippets are bits of text that get inserted into your editor, to save typing and
-reduce syntax errors. The snippets provided in `atom-snippets.cson` are scoped to
-only work on Markdown files within Atom. -->
-
-代码段就是可以插入到编辑器中的一段文本，可以节省键入时间，减少语法错误。
-`atom-snippets.cson` 文件中所提供的代码段只用于在 Atom 中的 Markdown 文件。
-
-<!-- ## Installation -->
-## 安装
-
-<!-- Copy the contents of the `atom-snippets.cson` file into your existing
-`~/.atom/snippets.cson`. **Do not replace your existing file.** -->
-
-将 `atom-snippets.cson` 文件中的内容复制到现有的`~/.atom/snippets.cson` 之中。
-**不要替换现有的文件。**
-
-<!-- You do not need to restart Atom. -->
-不需要重启 Atom。
-
-<!-- ## Usage -->
-## 使用
-
-<!-- Have a look through `atom-snippets.cson` and note the titles and `prefix` values
-of the snippets. -->
-
-浏览一遍 `atom-snippets.cson` 文件，记下代码段的标题和 `prefix`。
-
-<!-- You can trigger a given snippet in one of two ways:
-
-- By typing the snippet's `prefix` and pressing the `<TAB>` key
-- By searching for the snippet's title in **Packages / Snippets / Available** -->
-
-你可以使用以下任意一种方式来触发相应的代码段：
-- 键入代码段的`prefix`，按下 `<TAB>` 键
-- 在 **Packages / Snippets / Available** 中搜索代码段的标题
-
-<!-- For example, open a Markdown file and type `anote` and press `<TAB>`. A blank
-note is added, with the correct Hugo shortcodes. -->
-
-例如，打开一个 Markdown 文件，键入 `anote`，按下 `<TAB>`。
-就会插入一段带有正确的 Hugo 短代码的空注释。
-
-<!-- A snippet can insert a single line or multiple lines of text. Some snippets
-have placeholder values. To get to the next placeholder, press `<TAB>` again. -->
-
-代码段可以插入一行或多行文本。一些代码行都设有预留值。想要切换到下一个预留值，再按一次`<TAB>` 键即可。
-
-<!-- Some of the snippets only insert partially-formed Markdown or Hugo syntax.
-For instance, `coverview` inserts the start of a concept overview tag, while
-`cclose` inserts a close-capture tag. This is because every type of capture
-needs a capture-close tab. -->
-
-一些代码段只会插入部分格式的 Markdown 或 Hugo 语法。
-例如，`coverview` 只会插入一个概念概览的开始标签，而`cclose`则会插入一个结束标签。
-这是因为每类 capture 都需要一个 capture-close 标签。
-
-<!-- ## Creating new topics using snippets -->
-## 使用代码段创建新的话题
-
-<!-- To create a new concept, task, or tutorial from a blank file, use one of the
-following: -->
-从空白文件中，创建一个新的概念，任务或者教程，使用以下的代码段：
-
-- `newconcept`
-- `newtask`
-- `newtutorial`
-
-<!-- Placeholder text is included. -->
-预设文本包含其中。
-
-<!-- ## Submitting new snippets -->
-## 提交新的代码段
-
-<!-- 1.  Develop the snippet locally and verify that it works as expected.
-2.  Copy the template's code into the `atom-snippets.cson` file on Github. Raise a
-    pull request, and ask for review from another Atom user in `#sig-docs` on
-    Kubernetes Slack. -->
-
-1. 本地开发代码段，验证是否有效。
-2. 将代码单复制到 Github 的 `atom-snippets.cson` 文件中。
-提交 pull request，邀请 Kubernetes Slack `#sig-docs` 中的另外一名 Atom 用户进行审查。
diff --git a/content/zh/docs/doc-contributor-tools/snippets/atom-snippets.cson b/content/zh/docs/doc-contributor-tools/snippets/atom-snippets.cson
deleted file mode 100644
index 878ccc4ed7..0000000000
--- a/content/zh/docs/doc-contributor-tools/snippets/atom-snippets.cson
+++ /dev/null
@@ -1,226 +0,0 @@
-# Your snippets
-#
-# Atom snippets allow you to enter a simple prefix in the editor and hit tab to
-# expand the prefix into a larger code block with templated values.
-#
-# You can create a new snippet in this file by typing "snip" and then hitting
-# tab.
-#
-# An example CoffeeScript snippet to expand log to console.log:
-#
-# '.source.coffee':
-#   'Console log':
-#     'prefix': 'log'
-#     'body': 'console.log $1'
-#
-# Each scope (e.g. '.source.coffee' above) can only be declared once.
-#
-# This file uses CoffeeScript Object Notation (CSON).
-# If you are unfamiliar with CSON, you can read more about it in the
-# Atom Flight Manual:
-# http://flight-manual.atom.io/using-atom/sections/basic-customization/#_cson
-
-'.source.gfm':
-
-  # Capture variables for concept template
-  # For full concept template see 'newconcept' below
-  'Insert concept template':
-    'prefix': 'ctemplate'
-    'body': 'content_template: templates/concept'
-  'Insert concept overview':
-    'prefix': 'coverview'
-    'body': '{{% capture overview %}}'
-  'Insert concept body':
-    'prefix': 'cbody'
-    'body': '{{% capture body %}}'
-  'Insert concept whatsnext':
-    'prefix': 'cnext'
-    'body': '{{% capture whatsnext %}}'
-
-
-  # Capture variables for task template
-  # For full task template see 'newtask' below
-  'Insert task template':
-    'prefix': 'ttemplate'
-    'body': 'content_template: templates/task'
-  'Insert task overview':
-    'prefix': 'toverview'
-    'body': '{{% capture overview %}}'
-  'Insert task prerequisites':
-    'prefix': 'tprereq'
-    'body': """
-      {{% capture prerequisites %}}
-
-      {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-      {{% /capture %}}
-    """
-  'Insert task steps':
-    'prefix': 'tsteps'
-    'body': '{{% capture steps %}}'
-  'Insert task discussion':
-    'prefix': 'tdiscuss'
-    'body': '{{% capture discussion %}}'
-
-
-  # Capture variables for tutorial template
-  # For full tutorial template see 'newtutorial' below
-  'Insert tutorial template':
-    'prefix': 'tutemplate'
-    'body': 'content_template: templates/tutorial'
-  'Insert tutorial overview':
-    'prefix': 'tuoverview'
-    'body': '{{% capture overview %}}'
-  'Insert tutorial prerequisites':
-    'prefix': 'tuprereq'
-    'body': '{{% capture prerequisites %}}'  
-  'Insert tutorial objectives':
-    'prefix': 'tuobjectives'
-    'body': '{{% capture objectives %}}'
-  'Insert tutorial lesson content':
-    'prefix': 'tulesson'
-    'body': '{{% capture lessoncontent %}}'
-  'Insert tutorial whatsnext':
-    'prefix': 'tunext'
-    'body': '{{% capture whatsnext %}}'
-  'Close capture':
-    'prefix': 'ccapture'
-    'body': '{{% /capture %}}'
-  'Insert note':
-    'prefix': 'anote'
-    'body': """
-      {{< note >}}
-      $1
-      {{< /note >}}
-    """
-  
-  # Admonitions
-  'Insert caution':
-    'prefix': 'acaution'
-    'body': """
-      {{< caution >}}
-      $1
-      {{< /caution >}}
-    """
-  'Insert warning':
-    'prefix': 'awarning'
-    'body': """
-      {{< warning >}}
-      $1
-      {{< /warning >}}
-    """
-  
-  # Misc one-liners
-  'Insert TOC':
-    'prefix': 'toc'
-    'body': '{{< toc >}}'
-  'Insert code from file':
-    'prefix': 'codefile'
-    'body': '{{< codenew file="$1" >}}'
-  'Insert feature state':
-    'prefix': 'fstate'
-    'body': '{{< feature-state for_k8s_version="$1" state="$2" >}}'
-  'Insert figure':
-    'prefix': 'fig'
-    'body': '{{< figure src="$1" title="$2" alt="$3" caption="$4" >}}'
-  'Insert Youtube link':
-    'prefix': 'yt'
-    'body': '{{< youtube $1 >}}'
-
-
-  # Full concept template
-  'Create new concept':
-    'prefix': 'newconcept'
-    'body': """
-      ---
-      reviewers:
-      - ${1:"github-id-or-group"}
-      title: ${2:"topic-title"}
-      content_template: templates/concept
-      ---
-      {{% capture overview %}}
-      ${3:"overview-content"}
-      {{% /capture %}}
-      
-      {{< toc >}}
-      
-      {{% capture body %}}
-      ${4:"h2-heading-per-subtopic"}
-      {{% /capture %}}
-      
-      {{% capture whatsnext %}}
-      ${5:"next-steps-or-delete"}
-      {{% /capture %}}
-    """
-
-
-  # Full task template
-  'Create new task':
-    'prefix': 'newtask'
-    'body': """
-      ---
-      reviewers:
-      - ${1:"github-id-or-group"}
-      title: ${2:"topic-title"}
-      content_template: templates/task
-      ---
-      {{% capture overview %}}
-      ${3:"overview-content"}
-      {{% /capture %}}
-      
-      {{< toc >}}
-      
-      {{% capture prerequisites %}}
-      
-      {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-      
-      ${4:"additional-prereqs-or-delete"}
-      
-      {{% /capture %}}
-      
-      {{% capture steps %}}
-      ${5:"h2-heading-per-step"}
-      {{% /capture %}}
-      
-      {{% capture discussion %}}
-      ${6:"task-discussion-or-delete"}
-      {{% /capture %}}
-    """
-
-  # Full tutorial template
-  'Create new tutorial':
-    'prefix': 'newtutorial'
-    'body': """
-      ---
-      reviewers:
-      - ${1:"github-id-or-group"}
-      title: ${2:"topic-title"}
-      content_template: templates/tutorial
-      ---
-      {{% capture overview %}}
-      ${3:"overview-content"}
-      {{% /capture %}}
-      
-      {{< toc >}}
-      
-      {{% capture prerequisites %}}
-      
-      {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-      
-      ${4:"additional-prereqs-or-delete"}
-      
-      {{% /capture %}}
-      
-      {{% capture objectives %}}
-      ${5:"tutorial-objectives"}
-      {{% /capture %}}
-      
-      {{% capture lessoncontent %}}
-      ${6:"lesson-content"}
-      {{% /capture %}}
-      
-      {{% capture whatsnext %}}
-      ${7:"next-steps-or-delete"}
-      {{% /capture %}}
-    """
-  
diff --git a/content/zh/docs/home/_index.md b/content/zh/docs/home/_index.md
index d0e81e59d9..51ceacb973 100644
--- a/content/zh/docs/home/_index.md
+++ b/content/zh/docs/home/_index.md
@@ -13,7 +13,7 @@ menu:
     title: "文档"
     weight: 20
     post: >
-      <p>通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p>
+      <p>通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude data-proofer-ignore>帮助贡献文档</a>！</p>
 # description: >
 #   Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation.
 description: >
diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md
index 64091816a7..76a6199865 100644
--- a/content/zh/docs/reference/_index.md
+++ b/content/zh/docs/reference/_index.md
@@ -4,6 +4,7 @@ linkTitle: "参考"
 main_menu: true
 weight: 70
 content_type: concept
+no_list: true
 ---
 
 <!--
@@ -29,22 +30,12 @@ This section of the Kubernetes documentation contains references.
 ## API Reference
 
 * [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/)
+* [Kubernetes API Reference {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
 -->
 ## API 参考
 
-* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。
-* Kubernetes API 版本
-  * [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/)
+* [Kubernetes API 概述](/zh/docs/reference/using-api/api-overview/) - Kubernetes API 概述。
+* [Kubernetes API 参考 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
 
 <!--
 ## API Client Libraries
@@ -61,7 +52,7 @@ client libraries:
 ## API 客户端库
 
 如果您需要通过编程语言调用 Kubernetes API，您可以使用
-[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库：
+[客户端库](/zh/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库：
 
 - [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/)
 - [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python)
@@ -78,28 +69,30 @@ client libraries:
 -->
 ## CLI 参考
 
-* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。
-    * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。
-* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
-* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。
+* [kubectl](/zh/docs/reference/kubectl/overview/) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。
+    * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。
+* [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
 
 <!--
-## Config Reference
+## Components Reference
 
-* [kubelet](/docs/admin/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
-* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API that validates and configures data for API objects such as  pods, services, replication controllers.
-* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
-* [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
-* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as  pods, services, replication controllers.
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
+  * [kube-scheduler Policies](/docs/reference/scheduling/policies)
+  * [kube-scheduler Profiles](/docs/reference/scheduling/config#profiles)
 -->
-## 配置参考
-
-* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。
-* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。
-* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。
-* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。
-* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。
+## 组件参考
 
+* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。
+* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 Pod、服务或副本控制器等）的数据。
+* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。
+* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) - 可进行简单的 TCP/UDP 流转发或针对一组后端执行轮流 TCP/UDP 转发。
+* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。
+  * [kube-scheduler 策略](/zh/docs/reference/scheduling/policies)
+  * [kube-scheduler 配置](/zh/docs/reference/scheduling/config#profiles)
 <!--
 ## Design Docs
 
diff --git a/content/zh/docs/reference/access-authn-authz/_index.md b/content/zh/docs/reference/access-authn-authz/_index.md
index aa4d8d2730..7c1caa8f24 100644
--- a/content/zh/docs/reference/access-authn-authz/_index.md
+++ b/content/zh/docs/reference/access-authn-authz/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 访问 API
 weight: 20
-toc-hide: true
 ---
diff --git a/content/zh/docs/reference/access-authn-authz/abac.md b/content/zh/docs/reference/access-authn-authz/abac.md
index 7274053412..789e1cd3db 100644
--- a/content/zh/docs/reference/access-authn-authz/abac.md
+++ b/content/zh/docs/reference/access-authn-authz/abac.md
@@ -63,7 +63,7 @@ properties:
     - Non-resource-matching properties:
       - `nonResourcePath`, type string; non-resource request paths.
         - Ex: `/version` or `/apis`
-        - Wildcard: 
+        - Wildcard:
           - `*` matches all non-resource requests.
           - `/foo/*` matches all subpaths of `/foo/`.
     - `readonly`, type boolean, when true, means that the Resource-matching policy only applies to get, list, and watch operations, Non-resource-matching policy only applies to get operation.
@@ -73,7 +73,7 @@ properties:
 
 基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。
 
-此文件格式是 [JSON Lines](http://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。
+此文件格式是 [JSON Lines](https://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。
 
 每一行都是一个策略对象，策略对象是具有以下属性的映射：
 
@@ -213,7 +213,7 @@ Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点来发现服务资源类
     {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
     ```
  -->
- 
+
 ## 例子 {#examples}
 
 1. Alice 可以对所有资源做任何事情：
@@ -270,7 +270,7 @@ system:serviceaccount:<namespace>:<serviceaccountname>
 
 -->
 
-[完整文件示例](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+[完整文件示例](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
 
 ## 服务帐户的快速说明
 
@@ -287,7 +287,7 @@ Creating a new namespace leads to the creation of a new service account in the f
 system:serviceaccount:<namespace>:default
 ```
 
-For example, if you wanted to grant the default service account (in the `kube-system` namespace) full 
+For example, if you wanted to grant the default service account (in the `kube-system` namespace) full
 privilege to the API using ABAC, you would add this line to your policy file:
 
 ```json
@@ -310,6 +310,3 @@ system:serviceaccount:<namespace>:default
 ```
 
 需要重新启动 apiserver 以获取新的策略行。
-
-
-
diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
index 93be72db24..893d1891d5 100644
--- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
@@ -48,7 +48,7 @@ webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#a
 which are configured in the API.
 -->
 
-准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。
+准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。
 
 
 <!--
@@ -178,7 +178,8 @@ This admission controller allows all pods into the cluster. It is deprecated bec
 
 ## 每个准入控制器的作用是什么？
 
-### AlwaysAdmit {#alwaysadmit} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### AlwaysAdmit {#alwaysadmit} 
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
 
 该准入控制器会允许所有的 pod 接入集群。已废弃，因为它的行为根本就和没有准入控制器一样。
 
@@ -198,13 +199,63 @@ required.
 如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 pod 都可以通过已了解到的镜像的名称（假设 pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。
 当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。
 
-### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### AlwaysDeny {#alwaysdeny} 
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
 
 <!--
 Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning.
 -->
 拒绝所有的请求。由于没有实际意义，已废弃。
 
+### CertificateApproval
+
+<!--
+This admission controller observes requests to 'approve' CertificateSigningRequest resources
+and performs additional authorization checks to ensure the approving user has permission 
+to approve certificate requests with the spec.signerName requested on the CertificateSigningRequest resource.
+-->
+
+此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的授权检查，
+以确保审批请求的用户有权限审批 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求。
+
+<!--
+See Certificate Signing Requests for more information on the permissions required 
+to perform different actions on CertificateSigningRequest resources.
+-->
+
+有关对证书签名请求资源执行不同操作所需权限的详细信息，
+请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/)
+
+### CertificateSigning
+
+<!--
+This admission controller observes updates to the status.certificate field of CertificateSigningRequest resources 
+and performs an additional authorization checks to ensure the signing user has permission 
+to sign certificate requests with the spec.signerName requested on the CertificateSigningRequest resource.
+-->
+
+此准入控制器获取 CertificateSigningRequest 资源的 `status.certificate` 字段更新请求并执行额外的授权检查，
+以确保签发证书的用户有权限为 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求`签发`证书。
+
+<!--
+See Certificate Signing Requests for more information on the permissions required 
+to perform different actions on CertificateSigningRequest resources.
+-->
+
+有关对证书签名请求资源执行不同操作所需权限的详细信息，
+请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/)
+
+### CertificateSubjectRestrictions 
+
+<!--
+This admission controller observes creation of CertificateSigningRequest resources 
+that have a spec.signerName of kubernetes.io/kube-apiserver-client. It rejects any request 
+that specifies a 'group' (or 'organization attribute') of system:masters.
+-->
+
+此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 CertificateSigningRequest 资源创建请求，
+它拒绝任何包含了 `system:masters` 一个“组”（或者“组织”）的请求。
+
 ### DefaultStorageClass {#defaultstorageclass}
 
 <!--
@@ -231,7 +282,7 @@ See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentatio
 storage classes and how to mark a storage class as default.
 -->
 
-关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/docs/concepts/storage/persistent-volumes/)。
+关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。
 
 ### DefaultTolerationSeconds {#defaulttolerationseconds}
 
@@ -240,12 +291,13 @@ This admission controller sets the default forgiveness toleration for pods to to
 the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes,
 if the pods don't already have toleration for taints
 `node.kubernetes.io/not-ready:NoExecute` or
-`node.alpha.kubernetes.io/unreachable:NoExecute`.
+`node.kubernetes.io/unreachable:NoExecute`.
 -->
 
-该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 污点。（如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 `node.alpha.kubernetes.io/unreachable：NoExecute` 污点的话）
+该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 污点。（如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 `node.kubernetes.io/unreachable：NoExecute` 污点的话）
 
-### DenyExecOnPrivileged {#denyexeconprivileged} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### DenyExecOnPrivileged {#denyexeconprivileged} 
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
 
 <!--
 This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
@@ -269,7 +321,8 @@ is recommended instead.
 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件），
 该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。
 
-### DenyEscalatingExec {#denyescalatingexec} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### DenyEscalatingExec {#denyescalatingexec} 
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
 
 <!--
 This admission controller will deny exec and attach commands to pods that run with escalated privileges that
@@ -292,7 +345,8 @@ DenyExecOnPrivileged 准入插件已被废弃，并将在 v1.18 被移除。
 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件），
 该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。
 
-### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+### EventRateLimit {#eventratelimit} 
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
 
 <!--
 This admission controller mitigates the problem where the API server gets flooded by
@@ -395,7 +449,7 @@ add these tolerations.
 
 该插件有助于创建可扩展资源的专用节点。
 如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等），
-那他们应该以扩展资源名称作为键名，[为节点设置污点](/docs/concepts/configuration/taint-and-toleration/#example-use-cases)。
+那他们应该以扩展资源名称作为键名，[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
 如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中，用户不必再手动添加这些容忍。
 
 ### ImagePolicyWebhook {#imagepolicywebhook}
@@ -505,7 +559,7 @@ plugins:
 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.
 -->
 
-ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。
+ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。
 
 <!--
 The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
@@ -550,7 +604,7 @@ users:
 For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
 -->
 
-HTTP 更多的配置，请参阅 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 文档。
+HTTP 更多的配置，请参阅 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。
 
 <!--
 #### Request Payloads
@@ -683,9 +737,10 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace.
 See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
 -->
 
-请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/docs/tasks/configure-pod-container/limit-range/)了解更多细节。
+请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)了解更多细节。
 
-### MutatingAdmissionWebhook {#mutatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}}
+### MutatingAdmissionWebhook {#mutatingadmissionwebhook} 
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
 
 <!--
 This admission controller calls any mutating webhooks which match the request. Matching
@@ -836,7 +891,8 @@ subresource of the referenced *owner* can change it.
 
 该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 “删除” 权限的用户才能对其进行更改。该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问，以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” 权限的用户才能对其进行更改。
 
-### PersistentVolumeLabel {#persistentvolumelabel} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
+### PersistentVolumeLabel {#persistentvolumelabel} 
+{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
 
 <!--
 This admission controller automatically attaches region or zone labels to PersistentVolumes
@@ -852,7 +908,7 @@ Starting from 1.11, this admission controller is disabled by default.
 该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS）定义的 PersistentVolumes 中。
 这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。
 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，以防止 Pod 挂载其他区域的卷。
-PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/docs/tasks/administer-cluster/running-cloud-controller/)接管。
+PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。
 从 1.11 开始，默认情况下禁用此准入控制器。
 
 ### PodNodeSelector {#podnodeselector}
@@ -1005,7 +1061,7 @@ allowVolumeExpansion: true
 For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
 -->
 
-关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
+关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
 
 ### PodPreset {#podpreset}
 
@@ -1037,7 +1093,7 @@ extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
 See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
 for more information.
 -->
-查看 [Pod 安全策略文档](/docs/concepts/policy/pod-security-policy/)了解更多细节。
+查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/)了解更多细节。
 
 ### PodTolerationRestriction {#podtolerationrestriction}
 
@@ -1094,7 +1150,7 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
 <!--
 See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
 -->
-请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/docs/concepts/policy/resource-quotas/)了解更多细节。
+请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。
 
 
 <!--
@@ -1107,19 +1163,20 @@ See also [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
 for more information.
 -->
 
-### 容器运行时类 {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+### 容器运行时类 {#runtimeclass} 
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
 
-[容器运行时类](/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。
+[容器运行时类](/zh/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。
 
-详情请参见 [Pod 开销](/docs/concepts/configuration/pod-overhead/)。
+详情请参见 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/)。
 
 ### SecurityContextDeny {#securitycontextdeny}
 
 <!--
 This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
 -->
-该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/docs/user-guide/security-context) 字段的 pod。
-如果集群没有使用 [pod 安全策略](/docs/user-guide/pod-security-policy)来限制安全上下文所能获取的值集，那么应该启用这个功能。
+该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 字段的 pod。
+如果集群没有使用 [pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)来限制安全上下文所能获取的值集，那么应该启用这个功能。
 
 ### ServiceAccount {#serviceaccount}
 
@@ -1127,7 +1184,7 @@ This admission controller will deny any pod that attempts to set certain escalat
 This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
 We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
 -->
-该准入控制器实现了 [serviceAccounts](/docs/user-guide/service-accounts) 的自动化。
+该准入控制器实现了 [serviceAccounts](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。
 如果您打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议您使用这个准入控制器。
 
 ### StorageObjectInUseProtection
@@ -1135,9 +1192,10 @@ We strongly recommend using this admission controller if you intend to make use
 <!--
 The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
 -->
-`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。
+`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。
 
-### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.12" state="beta" >}}
+### TaintNodesByCondition {#taintnodesbycondition} 
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
 
 <!--
 This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions.
@@ -1145,7 +1203,8 @@ This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}}
 该准入控制器 {{< glossary_tooltip text="污点" term_id="taint" >}} 新创建的 `NotReady` 和 `NoSchedule` 节点。
 避免了可能导致 Pod 在更新其污点以准确反映其所报告状况之前，就安排了在新节点上的竞争条件的情况。
 
-### ValidatingAdmissionWebhook {#validatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}}
+### ValidatingAdmissionWebhook {#validatingadmissionwebhook} 
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
 
 <!--
 This admission controller calls any validating webhooks which match the request. Matching
@@ -1179,7 +1238,7 @@ Yes. For Kubernetes version 1.10 and later, the recommended admission controller
 -->
 ## 有推荐的准入控制器吗？
 
-有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
+有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
 因此您无需显式指定它们。您可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。
 
 {{< note >}}
@@ -1217,5 +1276,3 @@ in the mutating phase.
 admission controllers ran in the exact order specified.
 -->
     对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。
-
-
diff --git a/content/zh/docs/reference/access-authn-authz/authentication.md b/content/zh/docs/reference/access-authn-authz/authentication.md
new file mode 100644
index 0000000000..4c01f7c08e
--- /dev/null
+++ b/content/zh/docs/reference/access-authn-authz/authentication.md
@@ -0,0 +1,1563 @@
+---
+title: 用户认证
+content_type: concept
+weight: 10
+---
+<!--
+reviewers:
+- erictune
+- lavalamp
+- ericchiang
+- deads2k
+- liggitt
+title: Authenticating
+content_type: concept
+weight: 10
+-->
+
+<!-- overview -->
+<!--
+This page provides an overview of authenticating.
+-->
+本页提供身份认证有关的概述。
+
+<!-- body -->
+<!--
+## Users in Kubernetes
+
+All Kubernetes clusters have two categories of users: service accounts managed
+by Kubernetes, and normal users.
+
+It is assumed that a cluster-independent service manages normal users in the following ways:
+
+- an administrator distributing private keys
+- a user store like Keystone or Google Accounts
+- a file with a list of usernames and passwords
+
+In this regard, _Kubernetes does not have objects which represent normal user
+accounts._ Normal users cannot be added to a cluster through an API call.
+-->
+## Kubernetes 中的用户  {#users-in-kubernetes}
+
+所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务账号和普通用户。
+
+Kuernetes 假定使用以下方式之一来利用与集群无关的服务来管理普通用户：
+
+- 负责分发私钥的管理员
+- 类似 Keystone 或者 Google Accounts 这类用户数据库
+- 包含用户名和密码列表的文件
+
+有鉴于此，_Kubernetes 并不包含用来代表普通用户账号的对象_。
+普通用户的信息无法通过 API 调用添加到集群中。
+
+<!--
+Even though normal user cannot be added via an API call, but any user that
+presents a valid certificate signed by the cluster’s certificate authority
+(CA) is considered authenticated. In this configuration, Kubernetes determines
+the username from the common name field in the ‘subject’ of the cert (e.g.,
+“/CN=bob”). From there, the role based access control (RBAC) sub-system would
+determine whether the user is authorized to perform a specific operation on a
+resource. For more details, refer to the normal users topic in
+[certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
+for more details about this.
+-->
+尽管无法通过 API 调用来添加普通用户，Kubernetes 仍然认为能够提供由集群的证书
+机构签名的合法证书的用户是通过身份认证的用户。基于这样的配置，Kubernetes
+使用证书中的 'subject' 的通用名称（Common Name）字段（例如，"/CN=bob"）来
+确定用户名。接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对
+某资源执行特定的操作。进一步的细节可参阅
+[证书请求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
+下普通用户主题。
+
+<!--
+In contrast, service accounts are users managed by the Kubernetes API. They are
+bound to specific namespaces, and created automatically by the API server or
+manually through API calls. Service accounts are tied to a set of credentials
+stored as `Secrets`, which are mounted into pods allowing in-cluster processes
+to talk to the Kubernetes API.
+
+API requests are tied to either a normal user or a service account, or are treated
+as [anonymous requests](#anonymous-requests). This means every process inside or outside the cluster, from
+a human user typing `kubectl` on a workstation, to `kubelets` on nodes, to members
+of the control plane, must authenticate when making requests to the API server,
+or be treated as an anonymous user.
+-->
+与此不同，服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间，
+或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret 保存
+的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes
+API。
+
+API 请求则或者与某普通用户相关联，或者与某服务账号相关联，亦或者被视作
+[匿名请求](#anonymous-requests)。这意味着集群内外的每个进程在向 API 服务器发起
+请求时都必须通过身份认证，否则会被视作匿名用户。这里的进程可以是在某工作站上
+输入 `kubectl` 命令的操作人员，也可以是节点上的 `kubelet` 组件，还可以是控制面
+的成员。
+
+<!--
+## Authentication strategies
+
+Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to
+authenticate API requests through authentication plugins. As HTTP requests are
+made to the API server, plugins attempt to associate the following attributes
+with the request:
+-->
+## 身份认证策略  {#authentication-strategies}
+
+Kubernetes 使用身份认证插件利用客户端证书、持有者令牌（Bearer Token）、身份认证代理（Proxy）
+或者 HTTP 基本认证机制来认证 API 请求的身份。HTTP 请求发给 API 服务器时，
+插件会将以下属性关联到请求本身：
+
+<!--
+* Username: a string which identifies the end user. Common values might be `kube-admin` or `jane@example.com`.
+* UID: a string which identifies the end user and attempts to be more consistent and unique than username.
+* Groups: a set of strings, each of which indicates the user's membership in a named logical collection of users. Common values might be `system:masters` or `devops-team`.
+* Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful.
+-->
+* 用户名：用来辩识最终用户的字符串。常见的值可以是 `kube-admin` 或 `jane@example.com`。
+* 用户 ID：用来辩识最终用户的字符串，旨在比用户名有更好的一致性和唯一性。
+* 用户组：取值为一组字符串，其中各个字符串用来标明用户是某个命名的用户逻辑集合的成员。
+  常见的值可能是 `system:masters` 或者 `devops-team` 等。
+* 附加字段：一组额外的键-值映射，键是字符串，值是一组字符串；用来保存一些鉴权组件可能
+  觉得有用的额外信息。
+
+<!--
+All values are opaque to the authentication system and only hold significance
+when interpreted by an [authorizer](/docs/reference/access-authn-authz/authorization/).
+
+You can enable multiple authentication methods at once. You should usually use at least two methods:
+
+ - service account tokens for service accounts
+ - at least one other method for user authentication.
+-->
+所有（属性）值对于身份认证系统而言都是不透明的，只有被
+[鉴权组件](/zh/docs/reference/access-authn-authz/authorization/)
+解释过之后才有意义。
+
+你可以同时启用多种身份认证方法，并且你通常会至少使用两种方法：
+
+- 针对服务账号使用服务账号令牌
+- 至少另外一种方法对用户的身份进行认证
+
+<!--
+When multiple authenticator modules are enabled, the first module
+to successfully authenticate the request short-circuits evaluation.
+The API server does not guarantee the order authenticators run in.
+
+The `system:authenticated` group is included in the list of groups for all authenticated users.
+
+Integrations with other authentication protocols (LDAP, SAML, Kerberos, alternate x509 schemes, etc)
+can be accomplished using an [authenticating proxy](#authenticating-proxy) or the
+[authentication webhook](#webhook-token-authentication).
+-->
+当集群中启用了多个身份认证模块时，第一个成功地对请求完成身份认证的模块会
+直接做出评估决定。API 服务器并不保证身份认证模块的运行顺序。
+
+对于所有通过身份认证的用户，`system:authenticated` 组都会被添加到其组列表中。
+
+与其它身份认证协议（LDAP、SAML、Kerberos、X509 的替代模式等等）都可以通过
+使用一个[身份认证代理](#authenticating-proxy)或
+[身份认证 Webhoook](#webhook-token-authentication)来实现。
+
+<!--
+### X509 Client Certs
+
+Client certificate authentication is enabled by passing the `-client-ca-file=SOMEFILE`
+option to API server. The referenced file must contain one or more certificate authorities
+to use to validate client certificates presented to the API server. If a client certificate
+is presented and verified, the common name of the subject is used as the user name for the
+request. As of Kubernetes 1.4, client certificates can also indicate a user's group memberships
+using the certificate's organization fields. To include multiple group memberships for a user,
+include multiple organization fields in the certificate.
+
+For example, using the `openssl` command line tool to generate a certificate signing request:
+-->
+### X509 客户证书   {#x509-client-certs}
+
+通过给 API 服务器传递 `--client-ca-file=SOMEFILE` 选项，就可以启动客户端证书身份认证。
+所引用的文件必须包含一个或者多个证书机构，用来验证向 API 服务器提供的客户端证书。
+如果提供了客户端证书并且证书被验证通过，则 subject 中的公共名称（Common Name）就被
+作为请求的用户名。
+自 Kubernetes 1.4 开始，客户端证书还可以通过证书的 organization 字段标明用户的组成员信息。
+要包含用户的多个组成员信息，可以在证书种包含多个 organization 字段。
+
+例如，使用 `openssl` 命令行工具生成一个证书签名请求：
+
+``` bash
+openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
+```
+
+<!--
+This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2".
+
+See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert.
+-->
+此命令将使用用户名 `jbeda` 生成一个证书签名请求（CSR），且该用户属于 "app" 和
+"app2" 两个用户组。
+
+参阅[管理证书](/zh/docs/concepts/cluster-administration/certificates/)了解如何生成客户端证书。
+
+<!--
+### Static Token File
+
+The API server reads bearer tokens from a file when given the `-token-auth-file=SOMEFILE` option on the command line.  Currently, tokens last indefinitely, and the token list cannot be
+changed without restarting API server.
+
+The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
+followed by optional group names.
+-->
+### 静态令牌文件  {#static-token-file}
+
+当 API 服务器的命令行设置了 `--token-auth-file=SOMEFILE` 选项时，会从文件中
+读取持有者令牌。目前，令牌会长期有效，并且在不重启 API 服务器的情况下
+无法更改令牌列表。
+
+令牌文件是一个 CSV 文件，包含至少 3 个列：令牌、用户名和用户的 UID。
+其余列被视为可选的组名。
+
+<!--
+If you have more than one group the column must be double quoted e.g.
+
+```conf
+token,user,uid,"group1,group2,group3"
+```
+-->
+{{< note >}}
+如果要设置的组名不止一个，则对应的列必须用双引号括起来，例如
+
+```conf
+token,user,uid,"group1,group2,group3"
+```
+{{< /note >}}
+
+<!--
+#### Putting a Bearer Token in a Request
+
+When using bearer token authentication from an http client, the API
+server expects an `Authorization` header with a value of `Bearer
+THETOKEN`.  The bearer token must be a character sequence that can be
+put in an HTTP header value using no more than the encoding and
+quoting facilities of HTTP.  For example: if the bearer token is
+`31ada4fd-adec-460c-809a-9e56ceb75269` then it would appear in an HTTP
+header as shown below.
+-->
+#### 在请求中放入持有者令牌   {#putting-a-bearer-token-in-a-request}
+
+当使用持有者令牌来对某 HTTP 客户端执行身份认证时，API 服务器希望看到
+一个名为 `Authorization` 的 HTTP 头，其值格式为 `Bearer THETOKEN`。
+持有者令牌必须是一个可以放入 HTTP 头部值字段的字符序列，至多可使用
+HTTP 的编码和引用机制。
+例如：如果持有者令牌为 `31ada4fd-adec-460c-809a-9e56ceb75269`，则其
+出现在 HTTP 头部时如下所示：
+
+```http
+Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
+```
+
+<!--
+### Bootstrap Tokens
+-->
+### 启动引导令牌    {#bootstrap-tokens}
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+<!--
+To allow for streamlined bootstrapping for new clusters, Kubernetes includes a
+dynamically-managed Bearer token type called a *Bootstrap Token*. These tokens
+are stored as Secrets in the `kube-system` namespace, where they can be
+dynamically managed and created. Controller Manager contains a TokenCleaner
+controller that deletes bootstrap tokens as they expire.
+-->
+为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型，
+称作 *启动引导令牌（Bootstrap Token）*。
+这些令牌以 Secret 的形式保存在 `kube-system` 名字空间中，可以被动态管理和创建。
+控制器管理器包含的 `TokenCleaner` 控制器能够在启动引导令牌过期时将其删除。
+
+<!--
+The tokens are of the form `[a-z0-9]{6}.[a-z0-9]{16}`.  The first component is a
+Token ID and the second component is the Token Secret.  You specify the token
+in an HTTP header as follows:
+-->
+这些令牌的格式为 `[a-z0-9]{6}.[a-z0-9]{16}`。第一个部分是令牌的 ID；第二个部分
+是令牌的 Secret。你可以用如下所示的方式来在 HTTP 头部设置令牌：
+
+```http
+Authorization: Bearer 781292.db7bc3a58fc5f07e
+```
+
+<!--
+You must enable the Bootstrap Token Authenticator with the
+`-enable-bootstrap-token-auth` flag on the API Server.  You must enable
+the TokenCleaner controller via the `-controllers` flag on the Controller
+Manager.  This is done with something like `-controllers=*,tokencleaner`.
+`kubeadm` will do this for you if you are using it to bootstrap a cluster.
+-->
+你必须在 API 服务器上设置 `--enable-bootstrap-token-auth` 标志来启用基于启动
+引导令牌的身份认证组件。
+你必须通过控制器管理器的 `--controllers` 标志来启用 TokenCleaner 控制器；
+这可以通过类似 `--controllers=*,tokencleaner` 这种设置来做到。
+如果你使用 `kubeadm` 来启动引导新的集群，该工具会帮你完成这些设置。
+
+<!--
+The authenticator authenticates as `system:bootstrap:<Token ID>`.  It is
+included in the `system:bootstrappers` group.  The naming and groups are
+intentionally limited to discourage users from using these tokens past
+bootstrapping.  The user names and group can be used (and are used by `kubeadm`)
+to craft the appropriate authorization policies to support bootstrapping a
+cluster.
+-->
+身份认证组件的认证结果为 `system:bootstrap:<令牌 ID>`，该用户属于
+`system:bootstrappers` 用户组。
+这里的用户名和组设置都是有意设计成这样，其目的是阻止用户在启动引导集群之后
+继续使用这些令牌。
+这里的用户名和组名可以用来（并且已经被 `kubeadm` 用来）构造合适的鉴权
+策略，以完成启动引导新集群的工作。
+
+<!--
+Please see [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) for in depth
+documentation on the Bootstrap Token authenticator and controllers along with
+how to manage these tokens with `kubeadm`.
+-->
+请参阅[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
+以了解关于启动引导令牌身份认证组件与控制器的更深入的信息，以及如何使用
+`kubeadm` 来管理这些令牌。
+
+<!--
+### Static Password File
+
+Basic authentication is enabled by passing the `-basic-auth-file=SOMEFILE`
+option to API server. Currently, the basic auth credentials last indefinitely,
+and the password cannot be changed without restarting API server. Note that basic
+authentication is currently supported for convenience while we finish making the
+more secure modes described above easier to use.
+-->
+### Static Password File
+
+通过向 API 服务器传递 `--basic-auth-file=SOMEFILE` 选项可以启用基本的
+身份认证。目前，基本身份认证所涉及的凭据信息会长期有效，并且在不重启 API
+服务器的情况下无法改变用户的密码。
+要注意的是，对基本身份认证的支持目前仅是出于方便性考虑。
+与此同时我们正在增强前述的、更为安全的模式的易用性。
+
+<!--
+The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id.
+In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
+comma-separated group names. If you have more than one group, you must enclose the fourth
+column value in double quotes ("). See the following example:
+-->
+基本身份认证数据文件是一个 CSV 文件，包含至少 3 列：密码、用户名和用户 ID。
+在 Kuernetes 1.6 及后续版本中，你可以指定一个可选的第 4 列，在其中给出用逗号
+分隔的用户组名。如果用户组名不止一个，你必须将第 4 列的值用双引号括起来。
+参见下面的例子：
+
+```conf
+password,user,uid,"group1,group2,group3"
+```
+
+<!--
+When using basic authentication from an http client, the API server expects an `Authorization` header
+with a value of `Basic BASE64ENCODED(USER:PASSWORD)`.
+-->
+当在 HTTP 客户端使用基本身份认证机制时，API 服务器会期望看到名为
+`Authorization` 的 HTTP 头部，其值形如 `Basic USER:PASSWORD的Base64编码字符串`
+
+<!--
+### Service Account Tokens
+
+A service account is an automatically enabled authenticator that uses signed
+bearer tokens to verify requests. The plugin takes two optional flags:
+
+* `-service-account-key-file` A file containing a PEM encoded key for signing bearer tokens.
+If unspecified, the API server's TLS private key will be used.
+* `-service-account-lookup` If enabled, tokens which are deleted from the API will be revoked.
+-->
+### 服务账号令牌   {#service-account-tokens}
+
+服务账号（Service Account）是一种自动被启用的用户认证机制，使用经过签名的
+持有者令牌来验证请求。该插件可接受两个可选参数：
+
+* `--service-account-key-file` 一个包含用来为持有者令牌签名的 PEM 编码密钥。
+  若未指定，则使用 API 服务器的 TLS 私钥。
+* `--service-account-lookup` 如果启用，则从 API 删除的令牌会被回收。
+
+<!--
+Service accounts are usually created automatically by the API server and
+associated with pods running in the cluster through the `ServiceAccount`
+[Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). Bearer tokens are
+mounted into pods at well-known locations, and allow in-cluster processes to
+talk to the API server. Accounts may be explicitly associated with pods using the
+`serviceAccountName` field of a `PodSpec`.
+-->
+服务账号通常由 API 服务器自动创建并通过 `ServiceAccount`
+[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
+关联到集群中运行的 Pod 上。
+持有者令牌会挂载到 Pod 中可预知的为之，允许集群内进程与 API 服务器通信。
+服务账号也可以使用 Pod 规约的 `serviceAccountName` 字段显式地关联到 Pod 上。
+
+<!--
+`serviceAccountName` is usually omitted because this is done automatically.
+-->
+{{< note >}}
+`serviceAccountName` 通常会被忽略，因为关联关系是自动建立的。
+{{< /note >}}
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  namespace: default
+spec:
+  replicas: 3
+  template:
+    metadata:
+    # ...
+    spec:
+      serviceAccountName: bob-the-bot
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+```
+
+<!--
+Service account bearer tokens are perfectly valid to use outside the cluster and
+can be used to create identities for long standing jobs that wish to talk to the
+Kubernetes API. To manually create a service account, simply use the `kubectl
+create serviceaccount (NAME)` command. This creates a service account in the
+current namespace and an associated secret.
+-->
+在集群外部使用服务账号持有者令牌也是完全合法的，且可用来为长时间运行的、需要与
+Kubernetes  API 服务器通信的任务创建标识。要手动创建服务账号，可以使用
+`kubectl create serviceaccount <名称>` 命令。此命令会在当前的名字空间中生成一个
+服务账号和一个与之关联的 Secret。
+
+```bash
+kubectl create serviceaccount jenkins
+```
+
+```
+serviceaccount/jenkins created
+```
+
+<!--
+Check an associated secret:
+-->
+查验相关联的 Secret：
+
+```bash
+kubectl get serviceaccounts jenkins -o yaml
+```
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  # ...
+secrets:
+- name: jenkins-token-1yvwg
+```
+
+<!--
+The created secret holds the public CA of the API server and a signed JSON Web
+Token (JWT).
+-->
+所创建的 Secret 中会保存 API 服务器的公开的 CA 证书和一个已签名的 JSON Web
+令牌（JWT）。
+
+```bash
+kubectl get secret jenkins-token-1yvwg -o yaml
+```
+
+<!--
+```yaml
+apiVersion: v1
+data:
+  ca.crt: (APISERVER'S CA BASE64 ENCODED)
+  namespace: ZGVmYXVsdA==
+  token: (BEARER TOKEN BASE64 ENCODED)
+kind: Secret
+metadata:
+  # ...
+type: kubernetes.io/service-account-token
+```
+-->
+```yaml
+apiVersion: v1
+data:
+  ca.crt: <Base64 编码的 API 服务器 CA>
+  namespace: ZGVmYXVsdA==
+  token: <Base64 编码的持有者令牌>
+kind: Secret
+metadata:
+  # ...
+type: kubernetes.io/service-account-token
+```
+
+<!--
+Values are base64 encoded because secrets are always base64 encoded.
+-->
+{{< note >}}
+字段值是按 Base64 编码的，这是因为 Secret 数据总是采用 Base64 编码来存储。
+{{< /note >}}
+
+<!--
+The signed JWT can be used as a bearer token to authenticate as the given service
+account. See [above](#putting-a-bearer-token-in-a-request) for how the token is included
+in a request.  Normally these secrets are mounted into pods for in-cluster access to
+the API server, but can be used from outside the cluster as well.
+-->
+已签名的 JWT 可以用作持有者令牌，并将被认证为所给的服务账号。
+关于如何在请求中包含令牌，请参阅[前文](#putting-a-bearer-token-in-a-request)。
+通常，这些 Secret 数据会被挂载到 Pod 中以便集群内访问 API 服务器时使用，
+不过也可以在集群外部使用。
+
+<!--
+Service accounts authenticate with the username `system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`,
+and are assigned to the groups `system:serviceaccounts` and `system:serviceaccounts:(NAMESPACE)`.
+
+WARNING: Because service account tokens are stored in secrets, any user with
+read access to those secrets can authenticate as the service account. Be cautious
+when granting permissions to service accounts and read capabilities for secrets.
+-->
+服务账号被身份认证后，所确定的用户名为 `system:serviceaccount:<名字空间>:<服务账号>`，
+并被分配到用户组 `system:serviceaccounts` 和 `system:serviceaccounts:<名字空间>`。
+
+警告：由于服务账号令牌保存在 Secret 对象中，任何能够读取这些 Secret 的用户
+都可以被认证为对应的服务账号。在为用户授予访问服务账号的权限时，以及对 Secret
+的读权限时，要格外小心。
+
+<!--
+### OpenID Connect Tokens
+
+[OpenID Connect](https://openid.net/connect/) is a flavor of OAuth2 supported by
+some OAuth2 providers, notably Azure Active Directory, Salesforce, and Google.
+The protocol's main extension of OAuth2 is an additional field returned with
+the access token called an [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
+This token is a JSON Web Token (JWT) with well known fields, such as a user's
+email, signed by the server.
+-->
+### OpenID Connect（OIDC）令牌   {#openid-connect-tokens}
+
+[OpenID Connect](https://openid.net/connect/) 是一种 OAuth2  认证方式，
+被某些 OAuth2 提供者支持，例如 Azure 活动目录、Salesforce 和 Google。
+协议对 OAuth2 的主要扩充体现在有一个附加字段会和访问令牌一起返回，
+这一字段称作 [ID Token（ID 令牌）](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)。
+ID 令牌是一种由服务器签名的 JSON Web 令牌（JWT），其中包含一些可预知的字段，
+例如用户的邮箱地址，
+
+<!--
+To identify the user, the authenticator uses the `id_token` (not the `access_token`)
+from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse)
+as a bearer token.  See [above](#putting-a-bearer-token-in-a-request) for how the token
+is included in a request.
+-->
+要识别用户，身份认证组件使用 OAuth2
+[令牌响应](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse)
+中的 `id_token`（而非 `access_token`）作为持有者令牌。
+关于如何在请求中设置令牌，可参见[前文](#putting-a-bearer-token-in-a-request)。
+
+![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)
+
+<!--
+1.  Login to your identity provider
+2.  Your identity provider will provide you with an `access_token`, `id_token` and a `refresh_token`
+3.  When using `kubectl`, use your `id_token` with the `-token` flag or add it directly to your `kubeconfig`
+4.  `kubectl` sends your `id_token` in a header called Authorization to the API server
+5.  The API server will make sure the JWT signature is valid by checking against the certificate named in the configuration
+6.  Check to make sure the `id_token` hasn't expired
+7.  Make sure the user is authorized
+8.  Once authorized the API server returns a response to `kubectl`
+9.  `kubectl` provides feedback to the user
+-->
+1.  登录到你的身份服务（Identity Provider）
+2.  你的身份服务将为你提供 `access_token`、`id_token` 和 `refresh_token`
+3.  在使用 `kubectl` 时，将 `id_token` 设置为 `--token` 标志值，或者将其直接添加到
+    `kubeconfig` 中
+4.  `kubectl` 将你的 `id_token` 放到一个称作 `Authorization` 的头部，发送给 API 服务器
+5.  API 服务器将负责通过检查配置中引用的证书来确认 JWT 的签名是合法的
+6.  检查确认 `id_token` 尚未过期
+7.  确认用户有权限执行操作
+8.  鉴权成功之后，API 服务器向 `kubectl` 返回响应
+9.  `kubectl` 向用户提供反馈信息
+
+<!--
+Since all of the data needed to validate who you are is in the `id_token`, Kubernetes doesn't need to
+"phone home" to the identity provider.  In a model where every request is stateless this provides a very scalable
+solution for authentication.  It does offer a few challenges:
+-->
+由于用来验证你是谁的所有数据都在 `id_token` 中，Kubernetes 不需要再去联系
+身份服务。在一个所有请求都是无状态请求的模型中，这一工作方式可以使得身份认证
+的解决方案更容易处理大规模请求。不过，此访问也有一些挑战：
+
+<!--
+1.  Kubernetes has no "web interface" to trigger the authentication process.  There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
+2.  The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
+3.  There's no easy way to authenticate to the Kubernetes dashboard without using the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
+-->
+1.  Kubernetes 没有提供用来触发身份认证过程的 "Web 界面"。
+    因为不存在用来收集用户凭据的浏览器或用户接口，你必须自己先行完成
+    对身份服务的认证过程。
+2.  `id_token` 令牌不可收回。因其属性类似于证书，其生命期一般很短（只有几分钟），
+    所以，每隔几分钟就要获得一个新的令牌这件事可能很让人头疼。
+3.  如果不使用 `kubectl proxy` 命令或者一个能够注入 `id_token` 的反向代理，
+    向 Kubernetes 控制面板执行身份认证是很困难的。
+
+<!--
+#### Configuring the API Server
+
+To enable the plugin, configure the following flags on the API server:
+-->
+#### 配置 API 服务器    {#configuring-the-api-server}
+
+要启用此插件，须在 API 服务器上配置以下标志：
+
+<!--
+| Parameter | Description | Example | Required |
+| --------- | ----------- | ------- | ------- |
+| `--oidc-issuer-url` | URL of the provider which allows the API server to discover public signing keys. Only URLs which use the `https://` scheme are accepted.  This is typically the provider's discovery URL without a path, for example "https://accounts.google.com" or "https://login.salesforce.com".  This URL should point to the level below .well-known/openid-configuration | If the discovery URL is `https://accounts.google.com/.well-known/openid-configuration`, the value should be `https://accounts.google.com` | Yes |
+| `--oidc-client-id` |  A client id that all tokens must be issued for. | kubernetes | Yes |
+| `--oidc-username-claim` | JWT claim to use as the user name. By default `sub`, which is expected to be a unique identifier of the end user. Admins can choose other claims, such as `email` or `name`, depending on their provider. However, claims other than `email` will be prefixed with the issuer URL to prevent naming clashes with other plugins. | sub | No |
+| `--oidc-username-prefix` | Prefix prepended to username claims to prevent clashes with existing names (such as `system:` users). For example, the value `oidc:` will create usernames like `oidc:jane.doe`. If this flag isn't provided and `--oidc-username-claim` is a value other than `email` the prefix defaults to `( Issuer URL )#` where `( Issuer URL )` is the value of `--oidc-issuer-url`. The value `-` can be used to disable all prefixing. | `oidc:` | No |
+| `--oidc-groups-claim` | JWT claim to use as the user's group. If the claim is present it must be an array of strings. | groups | No |
+| `--oidc-groups-prefix` | Prefix prepended to group claims to prevent clashes with existing names (such as `system:` groups). For example, the value `oidc:` will create group names like `oidc:engineering` and `oidc:infra`. | `oidc:` | No |
+| `--oidc-required-claim` | A key=value pair that describes a required claim in the ID Token. If set, the claim is verified to be present in the ID Token with a matching value. Repeat this flag to specify multiple claims. | `claim=value` | No |
+| `--oidc-ca-file` | The path to the certificate for the CA that signed your identity provider's web certificate.  Defaults to the host's root CAs. | `/etc/kubernetes/ssl/kc-ca.pem` | No |
+-->
+
+| 参数 | 描述 | 示例 | 必需？ |
+| --------- | ----------- | ------- | ------- |
+| `--oidc-issuer-url` | 允许 API 服务器发现公开的签名密钥的服务的 URL。只接受模式为 `https://` 的 URL。此值通常设置为服务的发现 URL，不含路径。例如："https://accounts.google.com" 或 "https://login.salesforce.com"。此 URL 应指向 .well-known/openid-configuration 下一层的路径。 | 如果发现 URL 是 `https://accounts.google.com/.well-known/openid-configuration`，则此值应为 `https://accounts.google.com` | 是 |
+| `--oidc-client-id` |  所有令牌都应发放给此客户 ID。 | kubernetes | 是 |
+| `--oidc-username-claim` | 用作用户名的 JWT 申领（JWT Claim）。默认情况下使用 `sub` 值，即最终用户的一个唯一的标识符。管理员也可以选择其他申领，例如 `email` 或者 `name`，取决于所用的身份服务。不过，除了 `email` 之外的申领都会被添加令牌发放者的 URL 作为前缀，以免与其他插件产生命名冲突。 | sub | 否 |
+| `--oidc-username-prefix` | 要添加到用户名申领之前的前缀，用来避免与现有用户名发生冲突（例如：`system:` 用户）。例如，此标志值为 `oidc:` 时将创建形如 `oidc:jane.doe` 的用户名。如果此标志未设置，且 `--oidc-username-claim` 标志值不是 `email`，则默认前缀为 `<令牌发放者的 URL>#`，其中 `<令牌发放者 URL >` 的值取自 `--oidc-issuer-url` 标志的设定。此标志值为 `-` 时，意味着禁止添加用户名前缀。 | `oidc:` | 否 |
+| `--oidc-groups-claim` | 用作用户组名的 JWT 申领。如果所指定的申领确实存在，则其值必须是一个字符串数组。 | groups | 否 |
+| `--oidc-groups-prefix` | 添加到组申领的前缀，用来避免与现有用户组名（如：`system:` 组）发生冲突。例如，此标志值为 `oidc:` 时，所得到的用户组名形如 `oidc:engineering` 和 `oidc:infra`。 | `oidc:` | 否 |
+| `--oidc-required-claim` | 取值为一个 key=value 偶对，意为 ID 令牌中必须存在的申领。如果设置了此标志，则 ID 令牌会被检查以确定是否包含取值匹配的申领。此标志可多次重复，以指定多个申领。 | `claim=value` | 否 |
+| `--oidc-ca-file` | 指向一个 CA 证书的路径，该 CA 负责对你的身份服务的 Web 证书提供签名。默认值为宿主系统的根 CA。 | `/etc/kubernetes/ssl/kc-ca.pem` | 否 |
+
+<!--
+Importantly, the API server is not an OAuth2 client, rather it can only be
+configured to trust a single issuer. This allows the use of public providers,
+such as Google, without trusting credentials issued to third parties. Admins who
+wish to utilize multiple OAuth clients should explore providers which support the
+`azp` (authorized party) claim, a mechanism for allowing one client to issue
+tokens on behalf of another.
+-->
+很重要的一点是，API 服务器并非一个 OAuth2 客户端，相反，它只能被配置为
+信任某一个令牌发放者。这使得使用公共服务（如 Google）的用户可以不信任发放给
+第三方的凭据。
+如果管理员希望使用多个 OAuth 客户端，他们应该研究一下那些支持 `azp`
+（Authorized Party，被授权方）申领的服务。
+`azp` 是一种允许某客户端代替另一客户端发放令牌的机制。
+
+<!--
+Kubernetes does not provide an OpenID Connect Identity Provider.
+You can use an existing public OpenID Connect Identity Provider (such as Google, or
+[others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
+Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
+[Keycloak](https://github.com/keycloak/keycloak),
+CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
+Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
+-->
+Kubernetes 并未提供 OpenID Connect 的身份服务。
+你可以使用现有的公共的 OpenID Connect 身份服务（例如 Google 或者
+[其他服务](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)）。
+或者，你也可以选择自己运行一个身份服务，例如
+CoreOS [dex](https://github.com/coreos/dex)、
+[Keycloak](https://github.com/keycloak/keycloak)、
+CloudFoundry [UAA](https://github.com/cloudfoundry/uaa) 或者
+Tremolo Security 的
+[OpenUnison](https://github.com/tremolosecurity/openunison)。
+
+<!--
+For an identity provider to work with Kubernetes it must:
+
+1.  Support [OpenID connect discovery](https://openid.net/specs/openid-connect-discovery-1_0.html); not all do.
+2.  Run in TLS with non-obsolete ciphers
+3.  Have a CA signed certificate (even if the CA is not a commercial CA or is self signed)
+-->
+要在 Kubernetes 环境中使用某身份服务，该服务必须：
+
+1.  支持 [OpenID connect 发现](https://openid.net/specs/openid-connect-discovery-1_0.html)；
+    但事实上并非所有服务都具备此能力
+2.  运行 TLS 协议且所使用的加密组件都未过时
+3.  拥有由 CA 签名的证书（即使 CA 不是商业 CA 或者是自签名的 CA 也可以）
+
+<!--
+A note about requirement #3 above, requiring a CA signed certificate.  If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed.  This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation.  If you don't have a CA handy, you can use [this script](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) from the CoreOS team to create a simple CA and a signed certificate and key pair.
+Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh) that generates SHA256 certs with a longer life and larger key size.
+-->
+关于上述第三条需求，即要求具备 CA 签名的证书，有一些额外的注意事项。
+如果你部署了自己的身份服务，而不是使用云厂商（如 Google 或 Microsoft）所提供的服务，
+你必须对身份服务的 Web 服务器证书进行签名，签名所用证书的 `CA` 标志要设置为
+`TRUE`，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证
+标准方面有非常严格的要求。如果你手头没有现成的 CA 证书，可以使用 CoreOS
+团队所开发的[这个脚本](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)来创建一个简单的 CA 和被签了名的证书与密钥对。
+或者你也可以使用[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)，生成一个合法期更长、密钥尺寸更大的 SHA256 证书。
+
+<!--
+Setup instructions for specific systems:
+-->
+特定系统的安装指令：
+
+- [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html)
+- [Dex](https://dexidp.io/docs/kubernetes/)
+- [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/)
+
+<!--
+#### Using kubectl
+
+##### Option 1 - OIDC Authenticator
+
+The first option is to use the kubectl `oidc` authenticator, which sets the `id_token` as a bearer token for all requests and refreshes the token once it expires. After you've logged into your provider, use kubectl to add your `id_token`, `refresh_token`, `client_id`, and `client_secret` to configure the plugin.
+
+Providers that don't return an `id_token` as part of their refresh token response aren't supported by this plugin and should use "Option 2" below.
+-->
+#### 使用 kubectl   {#using-kubectl}
+
+##### 选项一 - OIDC 身份认证组件
+
+第一种方案是使用 kubectl 的 `oidc` 身份认证组件，该组件将 `id_token` 设置
+为所有请求的持有者令牌，并且在令牌过期时自动刷新。在你登录到你的身份服务之后，
+可以使用 kubectl 来添加你的 `id_token`、`refresh_token`、`client_id` 和
+`client_secret`，以配置该插件。
+
+如果服务在其刷新令牌响应中不包含 `id_token`，则此插件无法支持该服务。
+这时你应该考虑下面的选项二。
+
+```bash
+kubectl config set-credentials USER_NAME \
+   --auth-provider=oidc \
+   --auth-provider-arg=idp-issuer-url=( issuer url ) \
+   --auth-provider-arg=client-id=( your client id ) \
+   --auth-provider-arg=client-secret=( your client secret ) \
+   --auth-provider-arg=refresh-token=( your refresh token ) \
+   --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
+   --auth-provider-arg=id-token=( your id_token )
+```
+
+<!--
+As an example, running the below command after authenticating to your identity provider:
+-->
+作为示例，在完成对你的身份服务的身份认证之后，运行下面的命令：
+
+```bash
+kubectl config set-credentials mmosley  \
+        --auth-provider=oidc  \
+        --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP  \
+        --auth-provider-arg=client-id=kubernetes  \
+        --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5  \
+        --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
+        --auth-provider-arg=idp-certificate-authority=/root/ca.pem \
+        --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
+```
+
+<!--
+Which would produce the below configuration:
+-->
+此操作会生成以下配置：
+
+```yaml
+users:
+- name: mmosley
+  user:
+    auth-provider:
+      config:
+        client-id: kubernetes
+        client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
+        id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
+        idp-certificate-authority: /root/ca.pem
+        idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
+        refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
+      name: oidc
+```
+
+<!--
+Once your `id_token` expires, `kubectl` will attempt to refresh your `id_token` using your `refresh_token` and `client_secret` storing the new values for the `refresh_token` and `id_token` in your `.kube/config`.
+-->
+当你的 `id_token` 过期时，`kubectl` 会尝试使用你的 `refresh_token` 来刷新你的
+`id_token`，并且在 `client_secret` 中存放 `refresh_token` 的新值，同时把
+`id_token` 的新值写入到 `.kube/config` 文件中。
+
+<!--
+##### Option 2 - Use the `--token` Option
+
+The `kubectl` command lets you pass in a token using the `--token` option.  Simply copy and paste the `id_token` into this option:
+-->
+##### 选项二 - 使用 `--token` 选项
+
+`kubectl` 命令允许你使用 `--token` 选项传递一个令牌。
+你可以将 `id_token` 的内容复制粘贴过来，作为此标志的取值：
+
+```bash
+kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes
+```
+
+<!--
+### Webhook Token Authentication
+
+Webhook authentication is a hook for verifying bearer tokens.
+
+* `--authentication-token-webhook-config-file` a configuration file describing how to access the remote webhook service.
+* `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
+-->
+### Webhook 令牌身份认证   {#webhook-token-authentication}
+
+Webhook 身份认证是一种用来验证持有者令牌的回调机制。
+
+* `--authentication-token-webhook-config-file` 指向一个配置文件，其中描述
+  如何访问远程的 Webhook 服务。
+* `--authentication-token-webhook-cache-ttl` 用来设定身份认证决定的缓存时间。
+  默认时长为 2 分钟。
+
+<!--
+The configuration file uses the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+file format. Within the file, `clusters` refers to the remote service and
+`users` refers to the API server webhook. An example would be:
+-->
+配置文件使用 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+文件的格式。文件中，`clusters` 指代远程服务，`users` 指代远程 API 服务
+Webhook。下面是一个例子：
+
+<!--
+```yaml
+# Kubernetes API version
+apiVersion: v1
+# kind of the API object
+kind: Config
+# clusters refers to the remote service.
+clusters:
+  - name: name-of-remote-authn-service
+    cluster:
+      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
+      server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
+
+# users refers to the API server's webhook configuration.
+users:
+  - name: name-of-api-server
+    user:
+      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
+      client-key: /path/to/key.pem          # key matching the cert
+
+# kubeconfig files require a context. Provide one for the API server.
+current-context: webhook
+contexts:
+- context:
+    cluster: name-of-remote-authn-service
+    user: name-of-api-sever
+  name: webhook
+```
+-->
+```yaml
+# Kubernetes API 版本
+apiVersion: v1
+# API 对象类别
+kind: Config
+# clusters 指代远程服务
+clusters:
+  - name: name-of-remote-authn-service
+    cluster:
+      certificate-authority: /path/to/ca.pem         # 用来验证远程服务的 CA
+      server: https://authn.example.com/authenticate # 要查询的远程服务 URL。必须使用 'https'。
+
+# users 指代 API 服务的 Webhook 配置
+users:
+  - name: name-of-api-server
+    user:
+      client-certificate: /path/to/cert.pem # Webhook 插件要使用的证书
+      client-key: /path/to/key.pem          # 与证书匹配的密钥
+
+# kubeconfig 文件需要一个上下文（Context），此上下文用于本 API 服务器
+current-context: webhook
+contexts:
+- context:
+    cluster: name-of-remote-authn-service
+    user: name-of-api-sever
+  name: webhook
+```
+
+<!--
+When a client attempts to authenticate with the API server using a bearer token
+as discussed [above](#putting-a-bearer-token-in-a-request),
+the authentication webhook POSTs a JSON-serialized `authentication.k8s.io/v1beta1` `TokenReview` object containing the token
+to the remote service. Kubernetes will not challenge a request that lacks such a header.
+-->
+当客户端尝试在 API 服务器上使用持有者令牌完成身份认证（
+如[前](#putting-a-bearer-token-in-a-request)所述）时，
+身份认证 Webhook 会用 POST 请求发送一个 JSON 序列化的对象到远程服务。
+该对象是 `authentication.k8s.io/v1beta1` 组的 `TokenReview` 对象，
+其中包含持有者令牌。
+Kubernetes 不会强制请求提供此 HTTP 头部。
+
+<!--
+Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/)
+as other Kubernetes API objects. Implementers should be aware of looser
+compatibility promises for beta objects and check the "apiVersion" field of the
+request to ensure correct deserialization. Additionally, the API server must
+enable the `authentication.k8s.io/v1beta1` API extensions group (`--runtime-config=authentication.k8s.io/v1beta1=true`).
+
+The POST body will be of the following format:
+-->
+要注意的是，Webhook API 对象和其他 Kubernetes API 对象一样，也要受到同一
+[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)约束。
+实现者要了解对 Beta 阶段对象的兼容性承诺，并检查请求的 `apiVersion` 字段，
+以确保数据结构能够正常反序列化解析。此外，API 服务器必须启用
+`authentication.k8s.io/v1beta1` API 扩展组
+（`--runtime-config=authentication.k8s.io/v1beta1=true`）。
+
+POST 请求的 Body 部分将是如下格式：
+
+<!--
+```json
+{
+  "apiVersion": "authentication.k8s.io/v1beta1",
+  "kind": "TokenReview",
+  "spec": {
+    "token": "(BEARERTOKEN)"
+  }
+}
+```
+-->
+```json
+{
+  "apiVersion": "authentication.k8s.io/v1beta1",
+  "kind": "TokenReview",
+  "spec": {
+    "token": "<持有者令牌>"
+  }
+}
+```
+
+<!--
+The remote service is expected to fill the `status` field of
+the request to indicate the success of the login. The response body's `spec`
+field is ignored and may be omitted. A successful validation of the bearer
+token would return:
+-->
+远程服务应该会填充请求的 `status` 字段，以标明登录操作是否成功。
+响应的 Body 中的 `spec` 字段会被忽略，因此可以省略。
+如果持有者令牌验证成功，应该返回如下所示的响应：
+
+```json
+{
+  "apiVersion": "authentication.k8s.io/v1beta1",
+  "kind": "TokenReview",
+  "status": {
+    "authenticated": true,
+    "user": {
+      "username": "janedoe@example.com",
+      "uid": "42",
+      "groups": [
+        "developers",
+        "qa"
+      ],
+      "extra": {
+        "extrafield1": [
+          "extravalue1",
+          "extravalue2"
+        ]
+      }
+    }
+  }
+}
+```
+
+<!--
+An unsuccessful request would return:
+-->
+而不成功的请求会返回：
+
+```json
+{
+  "apiVersion": "authentication.k8s.io/v1beta1",
+  "kind": "TokenReview",
+  "status": {
+    "authenticated": false
+  }
+}
+```
+
+<!--
+HTTP status codes can be used to supply additional error context.
+-->
+HTTP 状态码可用来提供进一步的错误语境信息。
+
+<!--
+### Authenticating Proxy
+
+The API server can be configured to identify users from request header values, such as `X-Remote-User`.
+It is designed for use in combination with an authenticating proxy, which sets the request header value.
+-->
+### 身份认证代理   {#authenticating-proxy}
+
+API 服务器可以配置成从请求的头部字段值（如 `X-Remote-User`）中辩识用户。
+这一设计是用来与某身份认证代理一起使用 API 服务器，代理负责设置请求的头部字段值。
+
+<!--
+* `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username.
+* `--requestheader-group-headers` 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
+* `-requestheader-extra-headers-prefix` 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed. The remainder of the header name is lowercased and [percent-decoded](https://tools.ietf.org/html/rfc3986#section-2.1) and becomes the extra key, and the header value is the extra value.
+-->
+* `--requestheader-username-headers` 必需字段，大小写不敏感。用来设置要获得用户身份所要检查的头部字段名称列表（有序）。第一个包含数值的字段会被用来提取用户名。
+* `--requestheader-group-headers` 可选字段，在 Kubernetes 1.6 版本以后支持，大小写不敏感。
+  建议设置为 "X-Remote-Group"。用来指定一组头部字段名称列表，以供检查用户所属的组名称。
+  所找到的全部头部字段的取值都会被用作用户组名。
+* `--requestheader-extra-headers-prefix` 可选字段，在 Kubernetes 1.6 版本以后支持，大小写不敏感。
+  建议设置为 "X-Remote-Extra-"。用来设置一个头部字段的前缀字符串，API 服务器会基于所给
+  前缀来查找与用户有关的一些额外信息。这些额外信息通常用于所配置的鉴权插件。
+  API 服务器会将与所给前缀匹配的头部字段过滤出来，去掉其前缀部分，将剩余部分
+  转换为小写字符串并在必要时执行[百分号解码](https://tools.ietf.org/html/rfc3986#section-2.1)
+  后，构造新的附加信息字段键名。原来的头部字段值直接作为附加信息字段的值。
+
+<!--
+Prior to 1.11.3 (and 1.10.7, 1.9.11), the extra key could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
+For example, with this configuration:
+-->
+{{< note >}}
+在 1.13.3 版本之前（包括 1.10.7、1.9.11），附加字段的键名只能包含
+[HTTP 头部标签的合法字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)。
+{{< /note >}}
+
+例如，使用下面的配置：
+
+```
+--requestheader-username-headers=X-Remote-User
+--requestheader-group-headers=X-Remote-Group
+--requestheader-extra-headers-prefix=X-Remote-Extra-
+```
+
+<!--
+this request:
+-->
+针对所收到的如下请求：
+
+```http
+GET / HTTP/1.1
+X-Remote-User: fido
+X-Remote-Group: dogs
+X-Remote-Group: dachshunds
+X-Remote-Extra-Acme.com%2Fproject: some-project
+X-Remote-Extra-Scopes: openid
+X-Remote-Extra-Scopes: profile
+```
+
+<!--
+would result in this user info:
+-->
+会生成下面的用户信息：
+
+```yaml
+name: fido
+groups:
+- dogs
+- dachshunds
+extra:
+  acme.com/project:
+  - some-project
+  scopes:
+  - openid
+  - profile
+```
+
+<!--
+In order to prevent header spoofing, the authenticating proxy is required to present a valid client
+certificate to the API server for validation against the specified CA before the request headers are
+checked. WARNING: do **not** reuse a CA that is used in a different context unless you understand
+the risks and the mechanisms to protect the CA's usage.
+
+* `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
+* `--requestheader-allowed-names` Optional. List of Common Name values (CNs). If set, a valid client certificate with a CN in the specified list must be presented before the request headers are checked for user names. If empty, any CN is allowed.
+-->
+为了防范头部信息侦听，在请求中的头部字段被检视之前，
+身份认证代理需要向 API 服务器提供一份合法的客户端证书，
+供后者使用所给的 CA 来执行验证。
+警告：*不要* 在不同的上下文中复用 CA 证书，除非你清楚这样做的风险是什么以及
+应如何保护 CA 用法的机制。
+
+* `--requestheader-client-ca-file` 必需字段，给出 PEM 编码的证书包。
+  在检查请求的头部字段以提取用户名信息之前，必须提供一个合法的客户端证书，
+  且该证书要能够被所给文件中的机构所验证。
+* `--requestheader-allowed-names` 可选字段，用来给出一组公共名称（CN）。
+  如果此标志被设置，则在检视请求中的头部以提取用户信息之前，必须提供
+  包含此列表中所给的 CN 名的、合法的客户端证书。
+
+<!--
+## Anonymous requests
+
+When enabled, requests that are not rejected by other configured authentication methods are
+treated as anonymous requests, and given a username of `system:anonymous` and a group of
+`system:unauthenticated`.
+-->
+## 匿名请求   {#anonymous-requests}
+
+启用匿名请求支持之后，如果请求没有被已配置的其他身份认证方法拒绝，则被视作
+匿名请求（Anonymous Requests）。这类请求获得用户名 `system:anonymous` 和
+对应的用户组 `system:unauthenticated`。
+
+<!--
+For example, on a server with token authentication configured, and anonymous access enabled,
+a request providing an invalid bearer token would receive a `401 Unauthorized` error.
+A request providing no bearer token would be treated as an anonymous request.
+
+In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by
+passing the `--anonymous-auth=true` option to the API server.
+-->
+例如，在一个配置了令牌身份认证且启用了匿名访问的服务器上，如果请求提供了非法的
+持有者令牌，则会返回 `401 Unauthorized` 错误。
+如果请求没有提供持有者令牌，则被视为匿名请求。
+
+在 1.5.1-1.5.x 版本中，匿名访问默认情况下是被禁用的，可以通过为 API 服务器设定
+`--anonymous-auth=true` 来启用。
+
+<!--
+In 1.6+, anonymous access is enabled by default if an authorization mode other than `AlwaysAllow`
+is used, and can be disabled by passing the `-anonymous-auth=false` option to the API server.
+Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the
+`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules
+that grant access to the `*` user or `*` group do not include anonymous users.
+-->
+在 1.6 及之后版本中，如果所使用的鉴权模式不是 `AlwaysAllow`，则匿名访问默认是被启用的。
+从 1.6 版本开始，ABAC 和 RBAC 鉴权模块要求对 `system:anonymous` 用户或者
+`system:unauthenticated` 用户组执行显式的权限判定，所以之前的为 `*` 用户或
+`*` 用户组赋予访问权限的策略规则都不再包含匿名用户。
+
+<!--
+## User impersonation
+
+A user can act as another user through impersonation headers. These let requests
+manually override the user info a request authenticates as. For example, an admin
+could use this feature to debug an authorization policy by temporarily
+impersonating another user and seeing if a request was denied.
+-->
+## 用户伪装  {#user-impersonation}
+
+一个用户可以通过伪装（Impersonation）头部字段来以另一个用户的身份执行操作。
+使用这一能力，你可以手动重载请求被身份认证所识别出来的用户信息。
+例如，管理员可以使用这一功能特性来临时伪装成另一个用户，查看请求是否被拒绝，
+从而调试鉴权策略中的问题，
+
+<!--
+Impersonation requests first authenticate as the requesting user, then switch
+to the impersonated user info.
+
+* A user makes an API call with their credentials _and_ impersonation headers.
+* API server authenticates the user.
+* API server ensures the authenticated users have impersonation privileges.
+* Request user info is replaced with impersonation values.
+* Request is evaluated, authorization acts on impersonated user info.
+-->
+带伪装的请求首先会被身份认证识别为发出请求的用户，之后会切换到使用被伪装的用户
+的用户信息。
+
+* 用户发起 API 调用时 _同时_ 提供自身的凭据和伪装头部字段信息
+* API 服务器对用户执行身份认证
+* API 服务器确认通过认证的用户具有伪装特权
+* 请求用户的信息被替换成伪装字段的值
+* 评估请求，鉴权组件针对所伪装的用户信息执行操作
+
+<!--
+The following HTTP headers can be used to performing an impersonation request:
+
+* `Impersonate-User`: The username to act as.
+* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User"
+* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
+-->
+以下 HTTP 头部字段可用来执行伪装请求：
+
+* `Impersonate-User`：要伪装成的用户名
+* `Impersonate-Group`：要伪装成的用户组名。可以多次指定以设置多个用户组。
+  可选字段；要求 "Impersonate-User" 必须被设置。
+* `Impersonate-Extra-<附加名称>`：一个动态的头部字段，用来设置与用户相关的附加字段。
+  此字段可选；要求 "Impersonate-User" 被设置。为了能够以一致的形式保留，
+  `<附加名称>`部分必须是小写字符，如果有任何字符不是
+  [合法的 HTTP 头部标签字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)，
+  则必须是 utf8 字符，且转换为[百分号编码](https://tools.ietf.org/html/rfc3986#section-2.1)。
+
+<!--
+Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
+-->
+{{< note >}}
+在 1.11.3 版本之前（以及 1.10.7、1.9.11），`<附加名称>` 只能包含
+合法的 HTTP 标签字符。
+{{< /note >}}
+
+<!--
+An example set of headers:
+-->
+头部字段集合的示例：
+
+```http
+Impersonate-User: jane.doe@example.com
+Impersonate-Group: developers
+Impersonate-Group: admins
+Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
+Impersonate-Extra-acme.com%2Fproject: some-project
+Impersonate-Extra-scopes: view
+Impersonate-Extra-scopes: development
+```
+
+<!--
+When using `kubectl` set the `--as` flag to configure the `Impersonate-User`
+header, set the `--as-group` flag to configure the `Impersonate-Group` header.
+-->
+在使用 `kubectl` 时，可以使用 `--as` 标志来配置 `Impersonate-User` 头部字段值，
+使用 `--as-group` 标志配置 `Impersonate-Group` 头部字段值。
+
+```bash
+kubectl drain mynode
+```
+
+```none
+Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
+```
+
+<!--
+Set the `--as` and `--as-group` flag:
+-->
+设置 `--as` 和 `--as-group` 标志：
+
+```bash
+kubectl drain mynode --as=superman --as-group=system:masters
+```
+
+```none
+node/mynode cordoned
+node/mynode drained
+```
+
+<!--
+To impersonate a user, group, or set extra fields, the impersonating user must
+have the ability to perform the "impersonate" verb on the kind of attribute
+being impersonated ("user", "group", etc.). For clusters that enable the RBAC
+authorization plugin, the following ClusterRole encompasses the rules needed to
+set user and group impersonation headers:
+-->
+要伪装成某个用户、某个组或者设置附加字段，执行伪装操作的用户必须具有对所伪装的
+类别（“user”、“group” 等）执行 “impersonate” 动词操作的能力。
+对于启用了 RBAC 鉴权插件的集群，下面的 ClusterRole 封装了设置用户和组伪装字段
+所需的规则：
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: impersonator
+rules:
+- apiGroups: [""]
+  resources: ["users", "groups", "serviceaccounts"]
+  verbs: ["impersonate"]
+```
+
+<!--
+Extra fields are evaluated as sub-resources of the resource "userextras". To
+allow a user to use impersonation headers for the extra field "scopes", a user
+should be granted the following role:
+-->
+附加字段会被作为 `userextras` 资源的子资源来执行权限评估。
+如果要允许用户为附加字段 “scopes” 设置伪装头部，该用户需要被授予以下规则：
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: scopes-impersonator
+rules:
+# 可以设置 "Impersonate-Extra-scopes" 头部
+- apiGroups: ["authentication.k8s.io"]
+  resources: ["userextras/scopes"]
+  verbs: ["impersonate"]
+```
+
+<!--
+The values of impersonation headers can also be restricted by limiting the set
+of `resourceNames` a resource can take.
+-->
+你也可以通过约束资源可能对应的 `resourceNames` 限制伪装头部的取值：
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: limited-impersonator
+rules:
+# 可以伪装成用户 "jane.doe@example.com"
+- apiGroups: [""]
+  resources: ["users"]
+  verbs: ["impersonate"]
+  resourceNames: ["jane.doe@example.com"]
+
+# 可以伪装成用户组 "developers" 和 "admins"
+- apiGroups: [""]
+  resources: ["groups"]
+  verbs: ["impersonate"]
+  resourceNames: ["developers","admins"]
+
+# 可以将附加字段 "scopes" 伪装成 "view" 和 "development"
+- apiGroups: ["authentication.k8s.io"]
+  resources: ["userextras/scopes"]
+  verbs: ["impersonate"]
+  resourceNames: ["view", "development"]
+```
+
+<!--
+## client-go credential plugins
+-->
+## client-go 凭据插件  {#client-go-credential-plugins}
+
+{{< feature-state for_k8s_version="v1.11" state="beta" >}}
+
+<!--
+`k8s.io/client-go` and tools using it such as `kubectl` and `kubelet` are able to execute an
+external command to receive user credentials.
+
+This feature is intended for client side integrations with authentication protocols not natively
+supported by `k8s.io/client-go` (LDAP, Kerberos, OAuth2, SAML, etc.). The plugin implements the
+protocol specific logic, then returns opaque credentials to use. Almost all credential plugin
+use cases require a server side component with support for the [webhook token authenticator](#webhook-token-authentication)
+to interpret the credential format produced by the client plugin.
+-->
+`k8s.io/client-go` 及使用它的工具（如 `kubectl` 和 `kubelet`）可以执行某个外部
+命令来获得用户的凭据信息。
+
+这一特性的目的是便于客户端与 `k8s.io/client-go` 并不支持的身份认证协议（LDAP、
+Kerberos、OAuth2、SAML 等）继承。
+插件实现特定于协议的逻辑，之后返回不透明的凭据以供使用。
+几乎所有的凭据插件使用场景中都需要在服务器端存在一个支持
+[Webhook 令牌身份认证组件](#webhook-token-authentication)的模块，
+负责解析客户端插件所生成的凭据格式。
+
+<!--
+### Example use case
+
+In a hypothetical use case, an organization would run an external service that exchanges LDAP credentials
+for user specific, signed tokens. The service would also be capable of responding to [webhook token
+authenticator](#webhook-token-authentication) requests to validate the tokens. Users would be required
+to install a credential plugin on their workstation.
+-->
+### 示例应用场景   {#example-use-case}
+
+在一个假想的应用场景中，某组织运行这一个外部的服务，能够将特定用户的已签名的
+令牌转换成 LDAP 凭据。此服务还能够对
+[Webhook 令牌身份认证组件](#webhook-token-authentication)的请求做出响应以
+验证所提供的令牌。用户需要在自己的工作站上安装一个凭据插件。
+
+<!--
+To authenticate against the API:
+
+* The user issues a `kubectl` command.
+* Credential plugin prompts the user for LDAP credentials, exchanges credentials with external service for a token.
+* Credential plugin returns token to client-go, which uses it as a bearer token against the API server.
+* API server uses the [webhook token authenticator](#webhook-token-authentication) to submit a `TokenReview` to the external service.
+* External service verifies the signature on the token and returns the user's username and groups.
+-->
+要对 API 服务器认证身份时：
+
+* 用户发出 `kubectl` 命令。
+* 凭据插件提示用户输入 LDAP 凭据，并与外部服务交互，获得令牌。
+* 凭据插件将令牌返回该 client-go，后者将其用作持有者令牌提交给 API 服务器。
+* API 服务器使用[Webhook 令牌身份认证组件](#webhook-token-authentication)向
+  外部服务发出 `TokenReview` 请求。
+* 外部服务检查令牌上的签名，返回用户的用户名和用户组信息。
+
+<!--
+### Configuration
+
+Credential plugins are configured through [kubectl config files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+as part of the user fields.
+-->
+### 配置  {#configuration}
+
+凭据插件通过 [kubectl 配置文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+来作为 user 字段的一部分设置。
+
+<!--
+```yaml
+apiVersion: v1
+kind: Config
+users:
+- name: my-user
+  user:
+    exec:
+      # Command to execute. Required.
+      command: "example-client-go-exec-plugin"
+
+      # API version to use when decoding the ExecCredentials resource. Required.
+      #
+      # The API version returned by the plugin MUST match the version listed here.
+      #
+      # To integrate with tools that support multiple versions (such as client.authentication.k8s.io/v1alpha1),
+      # set an environment variable or pass an argument to the tool that indicates which version the exec plugin expects.
+      apiVersion: "client.authentication.k8s.io/v1beta1"
+
+      # Environment variables to set when executing the plugin. Optional.
+      env:
+      - name: "FOO"
+        value: "bar"
+
+      # Arguments to pass when executing the plugin. Optional.
+      args:
+      - "arg1"
+      - "arg2"
+clusters:
+- name: my-cluster
+  cluster:
+    server: "https://172.17.4.100:6443"
+    certificate-authority: "/etc/kubernetes/ca.pem"
+contexts:
+- name: my-cluster
+  context:
+    cluster: my-cluster
+    user: my-user
+current-context: my-cluster
+```
+-->
+```yaml
+apiVersion: v1
+kind: Config
+users:
+- name: my-user
+  user:
+    exec:
+      # 要执行的命令。必需。
+      command: "example-client-go-exec-plugin"
+
+      # 解析 ExecCredentials 资源时使用的 API 版本。必需。
+      #
+      # 插件返回的 API 版本必需与这里列出的版本匹配。
+      #
+      # 要与支持多个版本的工具（如 client.authentication.k8sio/v1alpha1）集成，
+      # 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本。
+      apiVersion: "client.authentication.k8s.io/v1beta1"
+
+      # 执行此插件时要设置的环境变量。可选字段。
+      env:
+      - name: "FOO"
+        value: "bar"
+
+      # 执行插件时要传递的参数。可选字段。
+      args:
+      - "arg1"
+      - "arg2"
+clusters:
+- name: my-cluster
+  cluster:
+    server: "https://172.17.4.100:6443"
+    certificate-authority: "/etc/kubernetes/ca.pem"
+contexts:
+- name: my-cluster
+  context:
+    cluster: my-cluster
+    user: my-user
+current-context: my-cluster
+```
+
+<!--
+Relative command paths are interpreted as relative to the directory of the config file. If
+KUBECONFIG is set to `/home/jane/kubeconfig` and the exec command is `./bin/example-client-go-exec-plugin`,
+the binary `/home/jane/bin/example-client-go-exec-plugin` is executed.
+-->
+解析相对命令路径时，kubectl 将其视为与配置文件比较而言的相对路径。
+如果 KUBECONFIG 被设置为 `/home/jane/kubeconfig`，而 exec 命令为
+`./bin/example-client-go-exec-plugin`，则要执行的可执行文件为
+`/home/jane/bin/example-client-go-exec-plugin`。
+
+```yaml
+- name: my-user
+  user:
+    exec:
+      # 对 kubeconfig 目录而言的相对路径
+      command: "./bin/example-client-go-exec-plugin"
+      apiVersion: "client.authentication.k8s.io/v1beta1"
+```
+
+<!--
+### Input and output formats
+
+The executed command prints an `ExecCredential` object to `stdout`. `k8s.io/client-go`
+authenticates against the Kubernetes API using the returned credentials in the `status`.
+
+When run from an interactive session, `stdin` is exposed directly to the plugin. Plugins should use a
+[TTY check](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal) to determine if it's
+appropriate to prompt a user interactively.
+
+To use bearer token credentials, the plugin returns a token in the status of the `ExecCredential`.
+-->
+### 输出和输出格式   {#input-and-output-formats}
+
+所执行的命令会在 `stdout` 打印 `ExecCredential` 对象。
+`k8s.io/client-go` 使用 `status` 中返回的凭据信息向 Kubernetes API 服务器
+执行身份认证。
+
+在交互式会话中运行时，`stdin` 是直接暴露给插件使用的。
+插件应该使用
+[TTY check](https://godoc.org/golang.org/x/crypto/ssh/terminal#IsTerminal)
+来确定是否适合用交互方式请求用户输入。
+
+与使用持有者令牌凭据，插件在 `ExecCredential` 的状态中返回一个令牌：
+
+```json
+{
+  "apiVersion": "client.authentication.k8s.io/v1beta1",
+  "kind": "ExecCredential",
+  "status": {
+    "token": "my-bearer-token"
+  }
+}
+```
+
+<!--
+Alternatively, a PEM-encoded client certificate and key can be returned to use TLS client auth.
+If the plugin returns a different certificate and key on a subsequent call, `k8s.io/client-go`
+will close existing connections with the server to force a new TLS handshake.
+
+If specified, `clientKeyData` and `clientCertificateData` must both must be present.
+
+`clientCertificateData` may contain additional intermediate certificates to send to the server.
+-->
+另一种方案是，返回 PEM 编码的客户端证书和密钥，以便执行 TLS 客户端身份认证。
+如果插件在后续调用中返回了不同的证书或密钥，`k8s.io/client-go`
+会终止其与服务器的连接，从而强制执行新的 TLS 握手过程。
+
+如果指定了这种方式，则 `clientKeyData` 和 `clientCertificateData` 字段都必需存在。
+
+`clientCertificateData` 字段可能包含一些要发送给服务器的中间证书（Intermediate
+Certificates）。
+
+```json
+{
+  "apiVersion": "client.authentication.k8s.io/v1beta1",
+  "kind": "ExecCredential",
+  "status": {
+    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
+    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
+  }
+}
+```
+
+<!--
+Optionally, the response can include the expiry of the credential formatted as a
+RFC3339 timestamp. Presence or absence of an expiry has the following impact:
+
+- If an expiry is included, the bearer token and TLS credentials are cached until
+  the expiry time is reached, or if the server responds with a 401 HTTP status code,
+  or when the process exits.
+- If an expiry is omitted, the bearer token and TLS credentials are cached until
+  the server responds with a 401 HTTP status code or until the process exits.
+-->
+作为一种可选方案，响应中还可以包含以 RFC3339 时间戳格式给出的证书到期时间。
+证书到期时间的有无会有如下影响：
+
+- 如果响应中包含了到期时间，持有者令牌和 TLS 凭据会被缓存，直到到期期限到来、
+  或者服务器返回 401 HTTP 状态码，或者进程退出。
+- 如果未指定到期时间，则持有者令牌和 TLS 凭据会被缓存，直到服务器返回 401
+  HTTP 状态码或者进程退出。
+
+```json
+{
+  "apiVersion": "client.authentication.k8s.io/v1beta1",
+  "kind": "ExecCredential",
+  "status": {
+    "token": "my-bearer-token",
+    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
+  }
+}
+```
diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh/docs/reference/access-authn-authz/authorization.md
index 3c2a08a817..a2b5e22207 100644
--- a/content/zh/docs/reference/access-authn-authz/authorization.md
+++ b/content/zh/docs/reference/access-authn-authz/authorization.md
@@ -29,7 +29,7 @@ cloud-provider-wide access control systems which may handle other APIs besides
 the Kubernetes API. -->
 
 在 Kubernetes 中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
-请参阅 [访问控制概述](/docs/reference/access-authn-authz/controlling-access/).
+请参阅 [访问控制概述](/zh/docs/reference/access-authn-authz/controlling-access/).
 
 Kubernetes 期望 REST API 请求中常见的属性。
 这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统，
@@ -85,12 +85,12 @@ Kubernetes 仅审查以下 API 请求属性：
  * **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。
  * **API** - 指示请求是否针对 API 资源。
  * **Request path** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。
- * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。
+ * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/zh/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。
  * **HTTP request verb** - HTTP 动词 `get`，`post`，`put` 和 `delete` 用于非资源请求。
  * **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用 `get`，`update`，`patch` 和 `delete` 动词的资源请求，您必须提供资源名称。
  * **Subresource** - 正在访问的子资源（仅限资源请求）。
  * **Namespace** - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
- * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/docs/concepts/overview/kubernetes-api/)。
+ * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/concepts/overview/kubernetes-api/)。
 
 <!--
 ## Determine the Request Verb
@@ -128,9 +128,9 @@ DELETE    | delete (单个资源)，deletecollection (资源集合)
 
 Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如：
 
-* [Pod 安全策略](/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
-* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
-* [认证](/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
+* [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
+* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
+* [认证](/zh/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
 
 <!--
 ## Authorization Modules
@@ -143,12 +143,12 @@ Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例
  -->
 
 ## 授权模块
- * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/).
- * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/docs/reference/access-authn-authz/abac/)。
- * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/docs/reference/access-authn-authz/rbac/)。
+ * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/zh/docs/reference/access-authn-authz/node/).
+ * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。
+ * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。
    * 当指定的 RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
    * 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 apiserver 。
- * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/docs/reference/access-authn-authz/webhook/)。
+ * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。
 
 <!--
 #### Checking API Access
@@ -173,7 +173,7 @@ no
 Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
 to determine what action other users can perform.
 -->
-管理员可以将此与[用户模拟](/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。
+管理员可以将此与[用户模拟](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。
 
 ```bash
 $ kubectl auth can-i list secrets --namespace dev --as dave
@@ -300,5 +300,5 @@ mode.
 * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
 * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
 -->
-* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)。
-* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/)。
+* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)。
+* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。
diff --git a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md
index 77ca6f32d5..c36f1f9bba 100644
--- a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md
+++ b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md
@@ -9,9 +9,9 @@ title: 使用启动引导令牌（Bootstrap Tokens）认证
 ## 概述
 
 启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。
-它被设计成能够支持 [`kubeadm`](/docs/admin/kubeadm/)，但是也可以被用在其他的案例中以便用户在
+它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)，但是也可以被用在其他的案例中以便用户在
 不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 [Kubelet TLS
-Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。
+Bootstrapping](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统进行工作。
 
 启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于
 `kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。
diff --git a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md
new file mode 100644
index 0000000000..ab0854a207
--- /dev/null
+++ b/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md
@@ -0,0 +1,747 @@
+---
+title: 证书签名请求
+content_type: concept
+weight: 20
+---
+<!-- 
+reviewers:
+- liggitt
+- mikedanese
+- munnerz
+title: Certificate Signing Requests
+content_type: concept
+weight: 20
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
+
+<!-- 
+The Certificates API enables automation of
+[X.509](https://www.itu.int/rec/T-REC-X.509) credential provisioning by providing
+a programmatic interface for clients of the Kubernetes API to request and obtain
+X.509 {{< glossary_tooltip term_id="certificate" text="certificates" >}} 
+from a Certificate Authority (CA).
+
+A CertificateSigningRequest (CSR) resource is used to request that a certificate be signed
+by a denoted signer, after which the request may be approved or denied before
+finally being signed.
+-->
+证书 API 支持 
+[X.509](https://www.itu.int/rec/T-REC-X.509) 
+的自动化配置，
+它为 Kubernetes API 的客户端提供一个编程接口，
+用于从证书颁发机构（CA）请求并获取 X.509 
+{{< glossary_tooltip term_id="certificate" text="证书" >}}。
+
+CertificateSigningRequest（CSR）资源用来向指定的签名者申请证书签名，
+在最终签名之前，申请可能被批准，也可能被拒绝。
+
+<!-- body -->
+
+<!-- 
+## Request signing process
+
+The _CertificateSigningRequest_ resource type allows 
+a client to ask for an X.509 certificate
+be issued, based on a signing request.
+The CertificateSigningRequest object includes a PEM-encoded PKCS#10 
+signing request in
+the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the
+recipient that the request is being made to) using the `spec.signerName` field.
+Note that `spec.signerName` is a required key after api version `certificates.k8s.io/v1`.
+-->
+## 请求签名流程 {#request-signing-process}
+
+_CertificateSigningRequest_ 资源类型允许客户使用它申请签名 X.509 证书。
+CertificateSigningRequest 对象 在 `spec.request` 中 包括一个 PEM 编码的 PKCS#10 签名请求。
+CertificateSigningRequest 使用 `spec.signerName` 字段表示 _签名者_（请求的接收方）。
+注意，`spec.signerName` 在 `certificates.k8s.io/v1` 之后的 API 版本是必填项。
+
+<!-- 
+Once created, a CertificateSigningRequest must be approved before it can be signed.
+Depending on the signer selected, a CertificateSigningRequest may be automatically approved
+by a {{< glossary_tooltip text="controller" term_id="controller" >}}.
+Otherwise, a CertificateSigningRequest must be manually approved 
+either via the REST API (or client-go)
+or by running `kubectl certificate approve`. 
+Likewise, a CertificateSigningRequest may also be denied,
+which tells the configured signer that it must not sign the request.
+-->
+创建完成的 CertificateSigningRequest，要先通过批准，然后才能签名。
+根据所选的签名者，CertificateSigningRequest 可能会被
+{{< glossary_tooltip text="控制器" term_id="controller" >}}自动批准。
+否则，就必须人工批准，
+人工批准可以使用 REST API（或 go 客户端），也可以执行 `kubectl certificate approve` 命令。
+同样，CertificateSigningRequest 也可能被驳回，
+这就相当于通知了指定的签名者，这个证书不能签名。
+
+<!--  
+For certificates that have been approved, the next step is signing. 
+The relevant signing controller
+first validates that the signing conditions are met and then creates a certificate.
+The signing controller then updates the CertificateSigningRequest, 
+storing the new certificate into
+the `status.certificate` field of the existing CertificateSigningRequest object. The
+`status.certificate` field is either empty or contains a X.509 certificate, 
+encoded in PEM format.
+The CertificateSigningRequest `status.certificate` field is empty until the signer does this.
+-->
+对于已批准的证书，下一步是签名。
+对应的签名控制器首先验证签名条件是否满足，然后才创建证书。
+签名控制器然后更新 CertificateSigningRequest，
+将新证书保存到现有 CertificateSigningRequest 对象的 `status.certificate` 字段中。
+此时，字段 `status.certificate` 要么为空，要么包含一个用 PEM 编码的 X.509 证书。
+直到签名完成前，CertificateSigningRequest 的字段 `status.certificate` 都为空。
+
+<!-- 
+Once the `status.certificate` field has been populated, 
+the request has been completed and clients can now
+fetch the signed certificate PEM data from the CertificateSigningRequest resource.
+The signers can instead deny certificate signing if the approval conditions are not met.
+-->
+一旦 `status.certificate` 字段完成填充，请求既算完成，
+客户端现在可以从 CertificateSigningRequest 资源中获取已签名的证书的 PEM 数据。
+当然如果不满足签名条件，签名者可以拒签。
+
+<!-- 
+In order to reduce the number of old CertificateSigningRequest resources left 
+in a cluster, a garbage collection
+controller runs periodically. 
+The garbage collection removes CertificateSigningRequests that have not changed
+state for some duration:
+
+* Approved requests: automatically deleted after 1 hour
+* Denied requests: automatically deleted after 1 hour
+* Pending requests: automatically deleted after 1 hour
+-->
+为了减少集群中遗留的过时的 CertificateSigningRequest 资源的数量，
+一个垃圾收集控制器将会周期性地运行。
+此垃圾收集器会清除在一段时间内没有改变过状态的 CertificateSigningRequests：
+
+* 已批准的请求：1小时后自动删除
+* 已拒绝的请求：1小时后自动删除
+* 挂起的请求：1小时后自动删除
+
+<!-- 
+## Signers
+
+All signers should provide information about how they work 
+so that clients can predict what will happen to their CSRs.
+This includes:
+-->
+## 签名者 {#signers}
+
+所有签名者都应该提供自己工作方式的信息，
+以便客户端可以预期到他们的 CSR 将发生什么。
+此类信息包括：
+
+<!-- 
+1. **Trust distribution**: how trust (CA bundles) are distributed.
+2.  **Permitted subjects**: any restrictions on and behavior 
+   when a disallowed subject is requested.
+3. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, 
+   Email subjectAltNames, URI subjectAltNames etc, 
+   and behavior when a disallowed extension is requested.
+4. **Permitted key usages / extended key usages**: any restrictions on and behavior 
+   when usages different than the signer-determined usages are specified in the CSR.
+5. **Expiration/certificate lifetime**: whether it is fixed by the signer, 
+   configurable by the admin, determined by the CSR object etc and the behavior 
+   when an expiration is different than the signer-determined expiration 
+   that is specified in the CSR.
+6. **CA bit allowed/disallowed**: and behavior if a CSR contains a request 
+   a for a CA certificate when the signer does not permit it.
+-->
+1. **信任分发**：信任（CA 证书包）是如何分发的。
+2. **许可的主体**：当一个受限制的主体（subject）发送请求时，相应的限制和应对手段。
+3. **许可的 x509 扩展**：包括 IP subjectAltNames、DNS subjectAltNames、
+   Email subjectAltNames、URI subjectAltNames等，请求一个受限制的扩展项时的应对手段。
+4. **许可的密钥用途/扩展的密钥用途**：当 usages 和签名者在 CSR 中指定的 usage 不同时，相应的限制和应对手段。
+5. **过期时间/证书有效期**：过期时间由签名者确定、由管理员配置，还是由 CSR 对象指定等，
+   以及过期时间与签名者在 CSR 中指定过期时间不同时的应对手段。
+6. **允许/不允许 CA 位**：当 CSR 包含一个签名者并不允许的 CA 证书的请求时，相应的应对手段。
+
+<!-- 
+Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate 
+once the CSR is approved and the certificate is issued. 
+Some signers store multiple certificates into the `status.certificate` field. 
+In that case, the documentation for the signer 
+should specify the meaning of additional certificates; 
+for example, this might be the certificate plus intermediates 
+to be presented during TLS handshakes.
+-->
+一般来说，当 CSR 被批准通过，且证书被签名后，`status.certificate` 字段将包含一个 PEM 编码的 X.509 证书。
+有些签名者在 `status.certificate` 字段中存储多个证书。
+在这种情况下，签名者的说明文档应当指明附加证书的含义。
+例如，这是要在 TLS 握手时提供的证书和中继证书。
+
+<!-- 
+### Kubernetes signers
+
+Kubernetes provides built-in signers that each have a well-known `signerName`:
+-->
+### Kubernetes 签名者 {#kubernetes-signers}
+
+Kubernetes提供了内置的签名者，每个签名者都有一个众所周知的 `signerName`:
+
+<!-- 
+1. `kubernetes.io/kube-apiserver-client`: signs certificates that will be honored as client-certs by the kube-apiserver.
+  Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+    1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle is not distributed by any other means.
+    1. Permitted subjects - no subject restrictions, but approvers and signers may choose not to approve or sign. Certain subjects like cluster-admin level users or groups vary between distributions and installations, but deserve additional scrutiny before approval and signing. The `CertificateSubjectRestriction` admission plugin is available and enabled by default to restrict `system:masters`, but it is often not the only cluster-admin subject in a cluster.
+    1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
+    1. Permitted key usages - must include []string{"client auth"}. Must not include key usages beyond []string{"digital signature", "key encipherment", "client auth"}
+    1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
+    1. CA bit allowed/disallowed - not allowed.
+-->
+
+1. `kubernetes.io/kube-apiserver-client`: 签名的证书将被 kube-apiserver 视为客户证书。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。
+   1. 信任分发：签名的证书将被 kube-apiserver 视为客户端证书。CA 证书包不通过任何其他方式分发。
+   1. 许可的主体 — 没有主体限制，但审核人和签名者可以选择不批准或不签署。
+      某些主体，比如集群管理员级别的用户或组，因部署和安装方式不同而不同，
+      所以批准和签署之前需要进行额外仔细审查。
+      用来限制 `system:masters` 的 CertificateSubjectRestriction 准入插件默认处于启用状态，
+      但它通常不是集群中唯一的 cluster-admin 主体。
+   1. 许可的 x509 扩展 - 允许 subjectAltName 和 key usage 扩展，弃用其他扩展。
+   1. 许可的密钥用途 - 必须包含 `[]string{"client auth"}`，但不能包含 `[]string{"digital signature", "key encipherment", "client auth"}` 之外的键。
+   1. 过期时间/证书有效期 - CSR 签名者和请求中的较小者。签名者负责检查证书的有效期正常且可接受。
+   1. 允许/不允许 CA 位 - 不允许。
+
+    <!-- 
+    1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client-certs by the
+      kube-apiserver.
+      May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+        1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle
+          is not distributed by any other means.
+        1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
+        1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
+        1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}`
+        1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
+        1. CA bit allowed/disallowed - not allowed.
+    -->
+1. `kubernetes.io/kube-apiserver-client-kubelet`: 签名的证书将被 kube-apiserver 视为客户证书。{{< glossary_tooltip term_id="kube-controller-manager" >}} 可以自动批准它。
+    1. 信任分发： 签名的证书将被 kube-apiserver 视为客户端证书。CA 证书包不通过任何其他方式分发。
+    2. 许可的主体 - 组织名必须是 `[]string{"system:nodes"}`，用户名以 `"system:node:"` 开头
+    3. 许可的 x509 扩展 — 允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。
+    4. 许可的密钥用途 - 必须是 `[]string{"key encipherment", "digital signature", "client auth"}`
+    5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。签名者负责检查证书的有效期正常且可接受。
+    6. 允许/不允许 CA 位 - 不允许。
+
+    <!-- 
+    1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate
+      by the kube-apiserver, but has no other guarantees.
+      Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+        1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means.
+        2. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
+        3. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
+        4. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}`
+        5. Expiration/certificate lifetime - minimum of CSR signer or request.
+        6. CA bit allowed/disallowed - not allowed.
+    -->
+2. `kubernetes.io/kubelet-serving`: 签名服务证书，该服务证书被 kube-apiserver 视为有效的 kubelet 服务证书，但没有其他保证。{{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。
+   1. 信任分发 ：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。
+   2. 许可的主体 - 组织名必须是 `[]string{"system:nodes"}`，用户名以`"system:node:"`开头
+   3. 许可的 x509 扩展 — 允许 key usage、DNSName/IPAddress subjectAltName 等扩展，
+      禁止  EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。
+      至少有一个 DNS 或 IP 的 SubjectAltName 存在。
+   4. 许可的密钥用途 - 必须是 `[]string{"key encipherment", "digital signature", "client auth"}`
+   5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。
+   6. 允许/不允许 CA 位 - 不允许。
+
+    <!-- 
+    1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some third-party distributions of Kubernetes
+      may honor client certificates signed by it. The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and later)
+      does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
+      Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+        1. Trust distribution: None.  There is no standard trust or distribution for this signer in a Kubernetes cluster.
+        2. Permitted subjects - any
+        3. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
+        4. Permitted key usages - any
+        5. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible.
+        6. CA bit allowed/disallowed - not allowed.
+    -->
+3. `kubernetes.io/legacy-unknown`:  根本不能保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。稳定版的 CertificateSigningRequest API（`certificates.k8s.io/v1` 以及之后的版本） 不允许将 `signerName` 设置为 `kubernetes.io/legacy-unknown`。{{< glossary_tooltip term_id="kube-controller-manager" >}} 将不会自动批准它。
+   1. 信任分发：没有。有这个签名者在 Kubernetes 集群中没有标准的信任或分发。
+   2. 许可的主体 - 全部
+   3. 许可的 x509 扩展 — 允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。
+   4. 许可的密钥用途 - 全部
+   5. 过期时间/证书有效期 - CSR 签名者或请求中的较小者。签名者负责检查证书的有效期正常且可接受。
+   6. 允许/不允许 CA 位 - 不允许。
+ 
+
+<!-- 
+
+Failures for all of these are only reported in kube-controller-manager logs.
+
+Distribution of trust happens out of band for these signers.  Any trust outside of those described above are strictly
+coincidental. For instance, some distributions may honor `kubernetes.io/legacy-unknown` as client certificates for the
+kube-apiserver, but this is not a standard.
+None of these usages are related to ServiceAccount token secrets `.data[ca.crt]` in any way.  That CA bundle is only
+guaranteed to verify a connection to the kube-apiserver using the default service (`kubernetes.default.svc`).
+-->
+{{< note >}}
+注意：所有这些故障仅在 kube-controller-manager 日志中报告。
+{{< /note >}}
+
+对于这些签名者，信任的分发发生在带外（out of band）。
+上述信任之外的任何信任都是完全巧合的。
+例如，一些发行版可能会将 `kubernetes.io/legacy-unknown` 作为 kube-apiserver 的客户端证书，
+但这个做法并不标准。
+这些用途都没有以任何方式涉及到 ServiceAccount 中的 Secrets `.data[ca.crt]`。
+此 CA 证书包只保证使用默认的服务（`kubernetes.default.svc`）来验证到 kube-apiserver 的连接。
+
+<!-- 
+## Authorization
+
+To allow creating a CertificateSigningRequest and retrieving any CertificateSigningRequest:
+
+* Verbs: `create`, `get`, `list`, `watch`, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
+
+For example:
+-->
+## 鉴权 {#authorization}
+
+授权创建 CertificateSigningRequest 和检索 CertificateSigningRequest:
+
+* verbs（动词）: `create`, `get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests`
+
+例如：
+
+{{< codenew file="access/certificate-signing-request/clusterrole-create.yaml" >}}
+
+<!-- 
+To allow approving a CertificateSigningRequest:
+
+* Verbs: `get`, `list`, `watch`, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
+* Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/approval`
+* Verbs: `approve`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+For example:
+-->
+授权批准 CertificateSigningRequest：
+
+* verbs（动词）: `get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests`
+* verbs（动词）: `update`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests/approval`
+* verbs（动词）: `approve`, group（组）： `certificates.k8s.io`, resources（资源）：`signers`, resourceName: `<signerNameDomain>/<signerNamePath>` 或 `<signerNameDomain>/*`
+
+例如：
+
+{{< codenew file="access/certificate-signing-request/clusterrole-approve.yaml" >}}
+
+<!-- 
+To allow signing a CertificateSigningRequest:
+
+* Verbs: `get`, `list`, `watch`, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
+* Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/status`
+* Verbs: `sign`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+-->
+授权签名 CertificateSigningRequest ：
+
+* verbs（动词）：`get`, `list`, `watch`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests`
+* verbs（动词）：`update`, group（组）： `certificates.k8s.io`, resources（资源）：`certificatesigningrequests/status`
+* verbs（动词）：`sign`, group（组）： `certificates.k8s.io`, resources（资源）：`signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+{{< codenew file="access/certificate-signing-request/clusterrole-sign.yaml" >}}
+
+<!-- 
+## Normal User
+
+A few steps are required in order to get normal user to be able to authenticate 
+and invoke an API. First, this user must have certificate issued by the Kubernetes Cluster, 
+and then present that Certificate to the API call as the Certificate Header or through the kubectl.
+-->
+## 普通用户 {#nornal-user}
+
+为了让普通用户能够通过认证并调用 API，需要执行几个步骤。
+首先，该用户必须拥有 Kubernetes 集群签名的证书，
+然后将该证书作为 API 调用的证书头或通过 kubectl 提供出来。
+
+<!-- 
+### Create Private Key
+
+The following scripts show how to generate PKI private key and CSR. 
+It is important to set CN and O attribute of the CSR. 
+CN is the name of the user and O is the group that this user will belong to. 
+You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
+-->
+### 创建私钥 {#create-private-key}
+
+下面的脚本展示了如何生成 PKI 私钥和 CSR。
+设置 CSR 的 CN 和 O 字段很重要。CN 是用户名，O 是该用户归属的组。
+你可以参考 [RBAC](/docs/reference/access-authn-authz/rbac/) 获取标准组的信息。
+
+```
+openssl genrsa -out john.key 2048
+openssl req -new -key john.key -out john.csr
+```
+
+<!-- 
+### Create Certificate Request Kubernetes Object
+
+Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. 
+Below is a script to generate the CertificateSigningRequest.
+-->
+### 创建申请证书的 Kubernetes 对象 {#create-certificate-request-kubernetes-object}
+
+创建一个 CertificateSigningRequest，并通过 kubectl 将其提交到 Kubernetes 集群。
+下面是生成 CertificateSigningRequest 的脚本。
+
+```
+cat <<EOF | kubectl apply -f -
+apiVersion: certificates.k8s.io/v1
+kind: CertificateSigningRequest
+metadata:
+  name: john
+spec:
+  groups:
+  - system:authenticated
+  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
+  signerName: kubernetes.io/kube-apiserver-client
+  usages:
+  - client auth
+EOF
+```
+
+<!-- 
+Some points to note:
+
+- usage has to be 'client auth'
+- request is the base64 encoded value of the CSR file content. 
+  You can use this command to get that ```cat john.csr | base64 | tr -d "\n"```
+-->
+需要注意的几点:
+
+- usage 字段必须是 'client auth'
+- request 字段是 CSR 文件内容的 base64 编码值。
+  要得到该值，可以执行命令 ```cat john.csr | base64 | tr -d "\n"``` 。
+
+<!-- 
+### Approve Certificate Request
+
+Use kubeadmin to create a CSR and approve it.
+
+Get the list of CSRs
+-->
+### 批准证书请求 {#approve-certificate-request}
+
+使用 kubectl 创建 CSR 并批准。
+
+获取 CSR 列表
+```
+kubectl get csr
+```
+
+<!-- 
+Approve the CSR
+-->
+批准 CRS
+```
+kubectl certificate approve john
+```
+
+<!-- 
+### Get the Certificate
+
+Retrieve the Certificate from the CSR.
+-->
+### 取得证书 {#get-the-certificate}
+
+从 CSR 取得证书。
+
+```
+kubectl get csr/john -o yaml
+```
+
+<!-- 
+The Certificate value is in Base64-encoded format under status.certificate.
+
+### Create Role and Role Binding
+
+You get the Certificate already. 
+Now it is time to define the Role and Role Binding for this user 
+to access Kubernetes Cluster resources.
+
+This is a sample script to create role for this new user
+-->
+证书的内容使用 base64 编码，存放在字段 status.certificate。
+
+### 创建角色和角色绑定 {#create-role-and-role-binding}
+
+你已经拿到证书了。为了让这个用户能访问 Kubernetes 集群资源，现在就要创建 Role 和 Role Binding 了。
+
+这是为这个新用户创建角色的示例脚本
+
+```
+kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
+```
+
+<!-- 
+This is a sample script to create role binding for this new user
+-->
+这是为这个新用户创建角色绑定的示例脚本
+```
+kubectl create rolebinding developer-binding-john --role=developer --user=john
+```
+
+<!-- 
+### Add to KubeConfig
+
+The last step is to add this user into the KubeConfig. 
+We assume the key and crt files are located here "/home/vagrant/work/".
+
+First, we need to add new credentials
+-->
+### 添加到 KubeConfig
+
+最后一步是将这个用户添加到 KubeConfig。
+我们假设私钥和证书文件存放在 “/home/vagrant/work/” 目录中。
+
+首先，我们需要添加新的凭据
+
+```
+kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true
+
+```
+
+<!-- 
+Then, we need to add the context
+-->
+然后，我们需要添加上下文
+```
+kubectl config set-context john --cluster=kubernetes --user=john
+```
+
+<!-- 
+To test it, change kubecontext to john
+-->
+来测试一下，把 kubecontext 切换为 john
+```
+kubectl config use-context john
+```
+
+<!-- 
+## Approval & rejection
+
+### Control plane automated approval {#approval-rejection-control-plane}
+
+The kube-controller-manager ships with a built-in approver for certificates with
+a signerName of `kubernetes.io/kube-apiserver-client-kubelet` that delegates various
+permissions on CSRs for node credentials to authorization.
+The kube-controller-manager POSTs SubjectAccessReview resources to the API server
+in order to check authorization for certificate approval.
+-->
+## 批准和驳回 {#approval-rejection}
+
+### 控制平面的自动化批准 {#approval-rejection-control-plane}
+
+kube-controller-manager 内建了一个证书批准者，其 signerName 为 
+`kubernetes.io/kube-apiserver-client-kubelet`，
+该批准者将 CSR 上用于节点凭据的各种权限委托给权威认证机构。
+kube-controller-manager 将 SubjectAccessReview 资源发送（POST）到 API 服务器，
+以便检验批准证书的授权。
+
+<!-- 
+### Approval & rejection using `kubectl` {#approval-rejection-kubectl}
+
+A Kubernetes administrator (with appropriate permissions) can manually approve
+(or deny) CertificateSigningRequests by using the `kubectl certificate
+approve` and `kubectl certificate deny` commands.
+
+To approve a CSR with kubectl:
+-->
+### 使用 `kubectl` 批准和驳回
+
+Kubernetes 管理员（拥有足够的权限）可以手工批准（或驳回）CertificateSigningRequests，
+此操作使用 `kubectl certificate approve` 和 `kubectl certificate deny` 命令实现。
+
+使用 kubectl 批准一个 CSR：
+
+```bash
+kubectl certificate approve <certificate-signing-request-name>
+```
+<!-- 
+Likewise, to deny a CSR: 
+-->
+同样地，驳回一个 CSR：
+
+```bash
+kubectl certificate deny <certificate-signing-request-name>
+```
+
+<!-- 
+### Approval & rejection using the Kubernetes API {#approval-rejection-api-client}
+
+Users of the REST API can approve CSRs by submitting an UPDATE request to the `approval`
+subresource of the CSR to be approved. For example, you could write an
+{{< glossary_tooltip term_id="operator-pattern" text="operator" >}} that watches for a particular
+kind of CSR and then sends an UPDATE to approve them.
+
+When you make an approval or rejection request, set either the `Approved` or `Denied`
+status condition based on the state you determine:
+
+For `Approved` CSRs:
+-->
+### 使用  Kubernetes API 批准和驳回  {#approval-rejection-api-client}
+
+REST API 的用户可以通过向待批准的 CSR 的 `approval` 子资源提交更新请求来批准 CSR。
+例如，你可以编写一个
+{{< glossary_tooltip term_id="operator-pattern" text="operator" >}}
+来监视特定类型的 CSR，然后发送一个更新来批准它。
+
+当你发出批准或驳回的指令时，根据你期望的状态来选择设置 `Approved` 或 `Denied`。
+
+批准（`Approved`） 的 CSR：
+
+```yaml
+apiVersion: certificates.k8s.io/v1
+kind: CertificateSigningRequest
+...
+status:
+  conditions:
+  - lastUpdateTime: "2020-02-08T11:37:35Z"
+    lastTransitionTime: "2020-02-08T11:37:35Z"
+    message: Approved by my custom approver controller
+    reason: ApprovedByMyPolicy # You can set this to any string
+    type: Approved
+```
+<!-- 
+For `Denied` CSRs:
+-->
+驳回（`Denied`）的 CRS：
+
+```yaml
+apiVersion: certificates.k8s.io/v1
+kind: CertificateSigningRequest
+...
+status:
+  conditions:
+  - lastUpdateTime: "2020-02-08T11:37:35Z"
+    lastTransitionTime: "2020-02-08T11:37:35Z"
+    message: Denied by my custom approver controller
+    reason: DeniedByMyPolicy # You can set this to any string
+    type: Denied
+```
+
+<!-- 
+It's usual to set `status.conditions.reason` to a machine-friendly reason
+code using TitleCase; this is a convention but you can set it to anything
+you like. If you want to add a note just for human consumption, use the
+`status.conditions.message` field.
+-->
+`status.conditions.reason` 字段通常设置为一个首字母大写的对机器友好的原因码;
+这是一个命名约定，但你也可以随你的个人喜好设置。
+如果你想添加一个仅供人类使用的注释，那就用 `status.conditions.message`  字段。
+
+<!-- 
+## Signing
+
+### Control plane signer {#signer-control-plane}
+
+The Kubernetes control plane implements each of the [Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers),
+as part of the kube-controller-manager.
+
+Prior to Kubernetes v1.18, the kube-controller-manager would sign any CSRs that
+were marked as approved.
+-->
+## 签名
+
+### 控制平面签名者
+
+Kubernetes 控制平面实现了每一个 
+[Kubernetes 签名者](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)，
+每个签名者的实现都是 kube-controller-manager 的一部分。
+
+{{< note >}}
+在Kubernetes v1.18 之前，
+kube-controller-manager 签名所有标记为 approved  的 CSR。
+{{< /note >}}
+
+<!-- 
+### API-based signers {#signer-api}
+
+Users of the REST API can sign CSRs by submitting an UPDATE request to the `status`
+subresource of the CSR to be signed.
+
+As part of this request, the `status.certificate` field should be set to contain the
+signed certificate. This field contains one or more PEM-encoded certificates.
+
+All PEM blocks must have the "CERTIFICATE" label, contain no headers,
+and the encoded data must be a BER-encoded ASN.1 Certificate structure
+as described in [section 4 of RFC5280](https://tools.ietf.org/html/rfc5280#section-4.1).
+
+Example certificate content:
+-->
+### 基于 API 的签名者
+
+REST API 的用户可以通过向待签名的 CSR 的 `status` 子资源提交更新请求来对 CSR 进行签名。
+
+作为这个请求的一部分， `status.certificate` 字段应设置为已签名的证书。
+此字段可包含一个或多个 PEM 编码的证书。
+
+所有的 PEM 块必须具备 "CERTIFICATE" 标签，且不包含文件头，且编码的数据必须是
+[RFC5280 第 4 节](https://tools.ietf.org/html/rfc5280#section-4.1)
+中描述的 BER 编码的 ASN.1 证书结构。
+
+```
+-----BEGIN CERTIFICATE-----
+MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
+BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
+BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
+MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
+dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
+CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
++e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
+kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
+Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
+sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
+2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
+YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
+Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
+ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
+L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
+qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
+o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
+aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
+M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
+-----END CERTIFICATE-----
+```
+
+<!-- 
+Non-PEM content may appear before or after the CERTIFICATE PEM blocks and is unvalidated,
+to allow for explanatory text as described in section 5.2 of RFC7468.
+
+When encoded in JSON or YAML, this field is base-64 encoded.
+A CertificateSigningRequest containing the example certificate above would look like this:
+-->
+非 PEM 内容可能会出现在证书 PEM 块前后的位置，且未经验证，
+以允许使用 RFC7468 第5.2节 中描述的解释性文本。
+
+当使用 JSON 或 YAML 格式时，此字段是 base-64 编码。
+包含上述示例证书的 CertificateSigningRequest 如下所示：
+
+```yaml
+apiVersion: certificates.k8s.io/v1
+kind: CertificateSigningRequest
+...
+status:
+  certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+<!-- 
+* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
+* View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
+* View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
+* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
+* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
+-->
+* 参阅 [管理集群中的 TLS 认证](/zh/docs/tasks/tls/managing-tls-in-a-cluster/)
+* 查看 kube-controller-manager 中[签名者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)部分的源代码
+* 查看 kube-controller-manager 中[批准者](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)部分的源代码
+* 有关 X.509 本身的详细信息，请参阅 [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) 第3.1节
+* 有关 PKCS#10 证书签名请求语法的信息，请参阅 [RFC 2986](https://tools.ietf.org/html/rfc2986)
\ No newline at end of file
diff --git a/content/zh/docs/reference/access-authn-authz/controlling-access.md b/content/zh/docs/reference/access-authn-authz/controlling-access.md
deleted file mode 100644
index edfc3aab85..0000000000
--- a/content/zh/docs/reference/access-authn-authz/controlling-access.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-approvers:
-- erictune
-- lavalamp
-title: Kubernetes API 访问控制
----
-
-用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。
-请求到达 API 服务器后会经过几个阶段，具体说明如图：
-
-![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
-
-## 传输层安全
-
-在典型的 Kubernetes 集群中，API 通过 443 端口提供服务。
-API 服务器会提供一份证书。 该证书一般是自签名的， 所以用户机器上的 `$USER/.kube/config` 目录通常
-包含该 API 服务器证书的根证书，用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时，该证书通常会被自动写入用户的 `$USER/.kube/config`。  如果集群中存在多个用户，则创建者需要与其他用户共享证书。
-
-## 认证
-
-一旦 TLS 连接建立，HTTP 请求就进入到了认证的步骤。即图中的步骤 **1** 。
-集群创建脚本或集群管理员会为 API 服务器配置一个或多个认证模块。
-更具体的认证相关的描述详见[这里](/docs/admin/authentication/)。
-
-认证步骤的输入是整个 HTTP 请求，但这里通常只是检查请求头和 / 或客户端证书。
-
-认证模块支持客户端证书，密码和 Plain Tokens，
-Bootstrap Tokens，以及 JWT Tokens（用于服务账户）。
-
-（管理员）可以同时设置多种认证模块，在设置了多个认证模块的情况下，每个模块会依次尝试认证，
-直到其中一个认证成功。
-
-在 GCE 平台中，客户端证书，密码和 Plain Tokens，Bootstrap Tokens，以及 JWT Tokens 同时被启用。
-
-如果请求认证失败，则请求被拒绝，返回 401 状态码。
-如果认证成功，则被认证为具体的 `username`，该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系，另一些则没有。
-
-尽管 Kubernetes 使用“用户名”来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。
-
-## 授权
-
-当请求被认证为来自某个特定的用户后，该请求需要被授权。 即图中的步骤 **2** 。
-
-请求须包含请求者的用户名，请求动作，以及该动作影响的对象。 如果存在相应策略，声明该用户具有进行相应操作的权限，则该请求会被授权。
-
-例如，如果 Bob 有如下策略，那么他只能够读取 `projectCaribou` 命名空间下的 pod 资源：
-
-```json
-{
-    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
-    "kind": "Policy",
-    "spec": {
-        "user": "bob",
-        "namespace": "projectCaribou",
-        "resource": "pods",
-        "readonly": true
-    }
-}
-```
-如果 Bob 发起以下请求，那么请求能够通过授权，因为 Bob 被允许访问 `projectCaribou` 命名空间下的对象：
-
-```json
-{
-  "apiVersion": "authorization.k8s.io/v1beta1",
-  "kind": "SubjectAccessReview",
-  "spec": {
-    "resourceAttributes": {
-      "namespace": "projectCaribou",
-      "verb": "get",
-      "group": "unicorn.example.org",
-      "resource": "pods"
-    }
-  }
-}
-```
-如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果 Bob 请求读取 （`get`）其他命名空间，例如 `projectFish` 下的对象，其授权也会被拒绝。 
-
-Kubernetes 的授权要求使用通用的 REST 属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用 REST 格式是必要的，因为除 Kubernetes 外，这些访问控制系统还可能与其他的 API 进行交互。
-
-Kubernetes 支持多种授权模块，例如 ABAC 模式，RBAC 模式和 Webhook 模式。 管理员创建集群时，会配置 API 服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes 将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝（HTTP 状态码 403）。
-
-要了解更多的 Kubernetes 授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。
-
-
-## 准入控制
-
-准入控制模块是能够修改或拒绝请求的软件模块。
-作为授权模块的补充，准入控制模块会访问被创建或更新的对象的内容。
-它们作用于对象的创建，删除，更新和连接（proxy）阶段，但不包括对象的读取。
-
-可以同时配置多个准入控制器，它们会按顺序依次被调用。
-
-即图中的步骤 **3** 。
-
-与认证和授权模块不同的是，如果任一个准入控制器拒绝请求，那么整个请求会立即被拒绝。
-
-除了拒绝请求外，准入控制器还可以为对象设置复杂的默认值。
-
-可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。
-
-一旦请求通过所有准入控制器，将使用对应 API 对象的验证流程对其进行验证，然后写入对象存储 （如步骤 **4**）。
-
-
-## API 的端口和 IP
-
-上述讨论适用于发送请求到 API 服务器的安全端口（典型情况）。  
-实际上 API 服务器可以通过两个端口提供服务：
-
-默认情况下，API 服务器在 2 个端口上提供 HTTP 服务：
-
-  1. `Localhost Port`:
-
-          - 用于测试和启动，以及管理节点的其他组件
-            （scheduler, controller-manager）与 API 的交互
-          - 没有 TLS
-          - 默认值为 8080，可以通过 `--insecure-port` 标记来修改。
-          - 默认的 IP 地址为 localhost， 可以通过 `--insecure-bind-address` 标记来修改。
-          - 请求会 **绕过** 认证和鉴权模块。
-          - 请求会被准入控制模块处理。
-          - 其访问需要主机访问的权限。
-
-  2. `Secure Port`:
-
-          - 尽可能使用该端口访问
-          - 应用 TLS。 可以通过 `--tls-cert-file` 设置证书， 通过 `--tls-private-key-file` 设置私钥。
-          - 默认值为 6443，可以通过 `--secure-port` 标记来修改。
-          - 默认 IP 是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。
-          - 请求会经过认证和鉴权模块处理。
-          - 请求会被准入控制模块处理。
-          - 要求认证和授权模块正常运行。
-
-通过 `kube-up.sh` 创建集群时， 对 Google Compute Engine（GCE）
-和一些其他的云供应商来说， API 通过 443 端口提供服务。 对
-GCE 而言，项目上配置了防火墙规则，允许外部的 HTTPS 请求访问 API，其他（厂商的）集群设置方法各不相同。
diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
index 4b0fcf0584..9e42aa7bdf 100644
--- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -18,7 +18,7 @@ In addition to [compiled-in admission plugins](/docs/reference/access-authn-auth
 admission plugins can be developed as extensions and run as webhooks configured at runtime.
 This page describes how to build, configure, use, and monitor admission webhooks.
 -->
-除了[内置的 admission 插件](/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。
+除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。
 此页面描述了如何构建、配置、使用和监视 admission webhook。
 
 
@@ -37,7 +37,7 @@ and
 Mutating admission Webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
 -->
 Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。
-可以定义两种类型的 admission webhook，即 [validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
+可以定义两种类型的 admission webhook，即 [validating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
 Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。
 
 <!--
@@ -67,7 +67,7 @@ In the following, we describe how to quickly experiment with admission webhooks.
 ### 尝试 admission webhook
 
 admission webhook 本质上是集群控制平面的一部分。您应该非常谨慎地编写和部署它们。
-如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
+如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
 在下文中，我们将介绍如何快速试验 admission webhook。
 
 <!--
@@ -88,7 +88,7 @@ admission webhook 本质上是集群控制平面的一部分。您应该非常
 * 确保 Kubernetes 集群版本至少为 v1.16（以便使用 `admissionregistration.k8s.io/v1` API） 或者 v1.9 （以便使用 `admissionregistration.k8s.io/v1beta1` API）。
 
 * 确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。
-  [这里](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
+  [这里](/zh/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
   是一组推荐的 admission 控制器，通常可以启用。
 
 * 确保启用了 `admissionregistration.k8s.io/v1beta1` API。
@@ -281,7 +281,7 @@ the webhooks. There are three steps to complete the configuration.
 * 启动 apiserver 时，通过 `--admission-control-config-file` 参数指定准入控制配置文件的位置。
 
 * 在准入控制配置文件中，指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。
-凭证存储在 kubeConfig 文件中（是​​的，与 kubectl 使用的模式相同），因此字段名称为 `kubeConfigFile`。 
+凭证存储在 kubeConfig 文件中（是​​的，与 kubectl 使用的模式相同），因此字段名称为 `kubeConfigFile`。
 以下是一个准入控制配置文件示例：
 
 <!--
@@ -748,7 +748,7 @@ For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of
 当允许请求时，mutating admission webhook 也可以选择修改传入的对象。
 这是通过在响应中使用 `patch` 和 `patchType` 字段来完成的。
 当前唯一支持的 `patchType` 是 `JSONPatch`。
-有关更多详细信息，请参见 [JSON patch](http://jsonpatch.com/)。
+有关更多详细信息，请参见 [JSON patch](https://jsonpatch.com/)。
 对于 `patchType: JSONPatch`，`patch` 字段包含一个以 base64 编码的 JSON patch 操作数组。
 
 <!--
@@ -1060,7 +1060,7 @@ webhooks:
 <!--
 See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
 -->
-有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。
+有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
 
 <!--
 ### Matching requests: namespaceSelector
@@ -1187,7 +1187,7 @@ webhooks:
 <!--
 See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
 -->
-有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。
+有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
 
 <!--
 ### Matching requests: matchPolicy
@@ -1367,7 +1367,7 @@ Fragments ("#...") and query parameters ("?...") are also not allowed.
 <!--
 Here is an example of a mutating webhook configured to call a URL
 (and expects the TLS certificate to be verified using system trust roots, so does not specify a caBundle):
---> 
+-->
 这是配置为调用 URL 的 mutating Webhook 的示例（并且期望使用系统信任根证书来验证 TLS 证书，因此不指定 caBundle）：
 
 {{< tabs name="MutatingWebhookConfiguration_url" >}}
@@ -1793,7 +1793,7 @@ capturing if a request object is mutated by the invocation, and optionally gener
 patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of
 its execution, which is then pre-processed according to a certain policy and written to a backend.
 -->
-在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/docs/tasks/debug-application-cluster/audit/)操作。
+在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。
 每个调用都会生成一个审计注解，记述请求对象是否发生改变，可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。
 针对给定请求的给定执行阶段，注解被添加到审计事件中，然后根据特定策略进行预处理并写入后端。
 
@@ -2150,7 +2150,7 @@ If side effects are required during the admission evaluation, they must be suppr
 set to `NoneOnDryRun`. See [Side effects](#side-effects) for more detail.
 -->
 ### Side Effects
- 
+
 建议 admission webhook 应尽可能避免副作用，这意味着该 admission webhook 仅对发送给他们的 `AdmissionReview` 的内容起作用，并且不要进行额外更改。
 如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为 `None`。
 
@@ -2173,5 +2173,3 @@ plane, exclude the `kube-system` namespace from being intercepted using a
 `kube-system` 命名空间包含由 Kubernetes 系统创建的对象，例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。
 意外更改或拒绝 `kube-system` 命名空间中的请求可能会导致控制平面组件停止运行或者导致未知行为发生。
 如果您的 admission webhook 不想修改 Kubernetes 控制平面的行为，请使用 [`namespaceSelector`](#matching-requests-namespaceselector) 避免拦截 `kube-system` 命名空间。
-
-
diff --git a/content/zh/docs/reference/access-authn-authz/node.md b/content/zh/docs/reference/access-authn-authz/node.md
index 22573d5e82..dc1c86ee4f 100644
--- a/content/zh/docs/reference/access-authn-authz/node.md
+++ b/content/zh/docs/reference/access-authn-authz/node.md
@@ -3,7 +3,7 @@ title: 使用 Node 鉴权
 content_type: concept
 weight: 90
 ---
-<!-- 
+<!--
 ---
 reviewers:
 - timstclair
@@ -18,145 +18,145 @@ weight: 90
 
 <!-- overview -->
 节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求进行鉴权。
-<!-- 
+<!--
 Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
 -->
 
 
 <!-- body -->
 ## 概述
-<!-- 
-## Overview 
+<!--
+## Overview
 -->
 
 节点鉴权器允许 kubelet 执行 API 操作。包括：
-<!-- 
-The Node authorizer allows a kubelet to perform API operations. This includes: 
+<!--
+The Node authorizer allows a kubelet to perform API operations. This includes:
 -->
 
 读取操作：
-<!-- 
-Read operations: 
+<!--
+Read operations:
 -->
 
 * services
 * endpoints
 * nodes
 * pods
-* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷 
+* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷
 
-<!-- 
+<!--
 * services
 * endpoints
 * nodes
 * pods
-* secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node 
+* secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node
 -->
 
 写入操作：
-<!-- 
-Write operations: 
+<!--
+Write operations:
 -->
 
 * 节点和节点状态（启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点）
 * Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod)
 * 事件
 
-<!-- 
+<!--
 * nodes and node status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify its own node)
 * pods and pod status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify pods bound to itself)
-* events 
+* events
 -->
 
 鉴权相关操作：
-<!-- 
-Auth-related operations: 
+<!--
+Auth-related operations:
 -->
 
 * 对于基于 TLS 的启动引导过程时使用的 certificationsigningrequests API 的读/写权限
 * 为委派的身份验证/授权检查创建 tokenreviews 和 subjectaccessreviews 的能力
 
-<!-- 
+<!--
 * read/write access to the certificationsigningrequests API for TLS bootstrapping
-* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks 
+* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
 -->
 
 在将来的版本中，节点鉴权器可能会添加或删除权限，以确保 kubelet 具有正确操作所需的最小权限集。
-<!-- 
+<!--
 In future releases, the node authorizer may add or remove permissions to ensure kubelets
-have the minimal set of permissions required to operate correctly. 
+have the minimal set of permissions required to operate correctly.
 -->
 
 为了获得节点鉴权器的授权，kubelet 必须使用一个凭证以表示它在 `system:nodes` 组中，用户名为 `system:node:<nodeName>`。
-上述的组名和用户名格式要与 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。
-<!-- 
-In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as 
+上述的组名和用户名格式要与 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。
+<!--
+In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as
 being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
-This group and user name format match the identity created for each kubelet as part of 
-[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/). 
+This group and user name format match the identity created for each kubelet as part of
+[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
 -->
 
 要启用节点授权器，请使用 `--authorization-mode = Node` 启动 apiserver。
-<!-- 
-To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`. 
+<!--
+To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
 -->
 
-要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。
-<!-- 
+要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/zh/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。
+<!--
 To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
  -->
 
 ## 迁移考虑因素
-<!-- 
-## Migration considerations 
+<!--
+## Migration considerations
 -->
 
 ### 在 `system:nodes` 组之外的 Kubelet
-<!-- 
-### Kubelets outside the `system:nodes` group 
+<!--
+### Kubelets outside the `system:nodes` group
 -->
 
 `system:nodes` 组之外的 kubelet 不会被 `Node` 鉴权模式授权，并且需要继续通过当前授权它们的机制来授权。
 节点准入插件不会限制来自这些 kubelet 的请求。
-<!-- 
+<!--
 Kubelets outside the `system:nodes` group would not be authorized by the `Node` authorization mode,
 and would need to continue to be authorized via whatever mechanism currently authorizes them.
-The node admission plugin would not restrict requests from these kubelets. 
+The node admission plugin would not restrict requests from these kubelets.
 -->
 
 ### 具有无差别用户名的 Kubelet
-<!-- 
-### Kubelets with undifferentiated usernames 
+<!--
+### Kubelets with undifferentiated usernames
 -->
 
 在一些部署中，kubelet 具有 `system:nodes` 组的凭证，但是无法给出它们所关联的节点的标识，因为它们没有 `system:node:...` 格式的用户名。
 这些 kubelet 不会被 `Node` 授权模式授权，并且需要继续通过当前授权它们的任何机制来授权。
-<!-- 
+<!--
 In some deployments, kubelets have credentials that place them in the `system:nodes` group,
 but do not identify the particular node they are associated with,
 because they do not have a username in the `system:node:...` format.
 These kubelets would not be authorized by the `Node` authorization mode,
-and would need to continue to be authorized via whatever mechanism currently authorizes them. 
+and would need to continue to be authorized via whatever mechanism currently authorizes them.
 -->
 
 因为默认的节点标识符实现不会把它当作节点身份标识，`NodeRestriction` 准入插件会忽略来自这些 kubelet 的请求。
-<!-- 
+<!--
 The `NodeRestriction` admission plugin would ignore requests from these kubelets,
-since the default node identifier implementation would not consider that a node identity. 
+since the default node identifier implementation would not consider that a node identity.
 -->
 
 ### 相对于以前使用 RBAC 的版本的更新
-<!-- 
-### Upgrades from previous versions using RBAC 
+<!--
+### Upgrades from previous versions using RBAC
 -->
 
-升级的 1.7 之前的使用 [RBAC](/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。
-<!-- 
+升级的 1.7 之前的使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。
+<!--
 Upgraded pre-1.7 clusters using [RBAC](/docs/reference/access-authn-authz/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
 -->
 
 如果集群管理员希望开始使用 `Node` 鉴权器和 `NodeRestriction` 准入插件来限制节点对 API 的访问，这一需求可以通过下列操作来完成且不会影响已部署的应用：
-<!-- 
+<!--
 If a cluster admin wishes to start using the `Node` authorizer and `NodeRestriction` admission plugin
 to limit node access to the API, that can be done non-disruptively:
  -->
@@ -165,40 +165,39 @@ to limit node access to the API, that can be done non-disruptively:
 2. 确保所有 kubelet 的凭据符合组/用户名要求
 3. 审核 apiserver 日志以确保 `Node` 鉴权器不会拒绝来自 kubelet 的请求（日志中没有持续的 `NODE DENY` 消息）
 4. 删除 `system:node` 集群角色绑定
-<!-- 
+<!--
 1. Enable the `Node` authorization mode (`--authorization-mode=Node,RBAC`) and the `NodeRestriction` admission plugin
 2. Ensure all kubelets' credentials conform to the group/username requirements
 3. Audit apiserver logs to ensure the `Node` authorizer is not rejecting requests from kubelets (no persistent `NODE DENY` messages logged)
-4. Delete the `system:node` cluster role binding 
+4. Delete the `system:node` cluster role binding
 -->
 
 ### RBAC 节点权限
-<!-- 
-### RBAC Node Permissions 
+<!--
+### RBAC Node Permissions
 -->
 
-在 1.6 版本中，当使用 [RBAC 鉴权模式](/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。
-<!-- 
-In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/). 
+在 1.6 版本中，当使用 [RBAC 鉴权模式](/zh/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。
+<!--
+In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/).
 -->
 
 在 1.7 版本中，不再推荐将 `system:nodes` 组自动绑定到 `system:node` 角色，因为节点鉴权器通过对 secret 和 configmap 访问的额外限制完成了相同的任务。
 如果同时启用了 `Node` 和 `RBAC` 授权模式，1.7 版本则不会创建 `system:nodes` 组到 `system:node` 角色的自动绑定。
-<!-- 
+<!--
 In 1.7, the automatic binding of the `system:nodes` group to the `system:node` role is deprecated
 because the node authorizer accomplishes the same purpose with the benefit of additional restrictions
 on secret and configmap access. If the `Node` and `RBAC` authorization modes are both enabled,
-the automatic binding of the `system:nodes` group to the `system:node` role is not created in 1.7. 
+the automatic binding of the `system:nodes` group to the `system:node` role is not created in 1.7.
 -->
 
 在 1.8 版本中，绑定将根本不会被创建。
-<!-- 
-In 1.8, the binding will not be created at all. 
+<!--
+In 1.8, the binding will not be created at all.
 -->
 
 使用 RBAC 时，将继续创建 `system:node` 集群角色，以便与将其他用户或组绑定到该角色的部署方法兼容。
-<!-- 
+<!--
 When using RBAC, the `system:node` cluster role will continue to be created,
-for compatibility with deployment methods that bind other users or groups to that role. 
+for compatibility with deployment methods that bind other users or groups to that role.
 -->
-
diff --git a/content/zh/docs/reference/access-authn-authz/rbac.md b/content/zh/docs/reference/access-authn-authz/rbac.md
index 3d35e4e8bb..b0f8e5921c 100644
--- a/content/zh/docs/reference/access-authn-authz/rbac.md
+++ b/content/zh/docs/reference/access-authn-authz/rbac.md
@@ -244,7 +244,7 @@ roleRef:
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。 
+# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。
 kind: RoleBinding
 metadata:
   name: read-secrets
@@ -261,7 +261,7 @@ roleRef:
 
 <!--
 Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all
-namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read 
+namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read
 secrets in any namespace.
 
 ```yaml
@@ -288,10 +288,10 @@ There are two primary reasons for this restriction:
 1. A binding to a different role is a fundamentally different binding.
 Requiring a binding to be deleted/recreated in order to change the `roleRef`
 ensures the full list of subjects in the binding is intended to be granted
-the new role (as opposed to enabling accidentally modifying just the roleRef 
+the new role (as opposed to enabling accidentally modifying just the roleRef
 without verifying all of the existing subjects should be given the new role's permissions).
 2. Making `roleRef` immutable allows giving `update` permission on an existing binding object
-to a user, which lets them manage the list of subjects, without being able to change the 
+to a user, which lets them manage the list of subjects, without being able to change the
 role that is granted to those subjects.
 
 The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects,
@@ -709,7 +709,7 @@ reserved for Kubernetes system use, and so the admin should ensure
 usernames do not contain this prefix by accident.
 
 Group information in Kubernetes is currently provided by the Authenticator
-modules. Groups, like users, are represented as strings, and that string 
+modules. Groups, like users, are represented as strings, and that string
 has no format requirements, other than that the prefix `system:` is reserved.
 
 [Service Accounts](/docs/tasks/configure-pod-container/configure-service-account/) have usernames with the `system:serviceaccount:` prefix and belong
@@ -721,14 +721,14 @@ to groups with the `system:serviceaccounts:` prefix.
 主体可以是组，用户或者服务账户。
 
 用户是由字符串表示，它们可以是普通的用户名，像 "alice"，或者是
-邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/docs/reference/access-authn-authz/authentication/)
+邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/)
 需要的格式。RBAC 鉴权系统不对格式作任何要求，但是前缀 `system:` 是 Kubernetes 系统保留的，
 所以管理员要确保配置的用户名不能出现上述前缀格式。
 
 用户组信息是 Kubernetes 现在提供的一种身份验证模块，与用户一样，对组的字符串没有格式要求，
 只是不能使用保留的前缀 `system:` 。
 
-[服务账号](/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`，
+[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`，
 属于前缀为 `system:serviceaccounts:` 的用户组。
 
 <!--
@@ -918,7 +918,7 @@ and updates default cluster role bindings with any missing subjects.
 This allows the cluster to repair accidental modifications,
 and to keep roles and rolebindings up-to-date as permissions and subjects change in new releases.
 
-To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` 
+To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate`
 annotation on a default cluster role or rolebinding to `false`.
 Be aware that missing default permissions and subjects can result in non-functional clusters.
 
@@ -1321,7 +1321,7 @@ This is commonly used by add-on API servers for unified authentication and autho
 The [Kubernetes controller manager](/docs/admin/kube-controller-manager/) runs core control loops.
 When invoked with `--use-service-account-credentials`, each control loop is started using a separate service account.
 Corresponding roles exist for each control loop, prefixed with `system:controller:`.
-If the controller manager is not started with `--use-service-account-credentials`, 
+If the controller manager is not started with `--use-service-account-credentials`,
 it runs all control loops using its own credential, which must be granted all the relevant roles.
 These roles include:
 
@@ -1355,7 +1355,7 @@ These roles include:
 -->
 ### 控制器角色   {#controller-roles}
 
-[Kubernetes 控制器管理器](/docs/admin/kube-controller-manager/) 运行核心控制环。
+[Kubernetes 控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 运行核心控制环。
 当使用 `--use-service-account-credentials` 参数时, 每个控制环使用一个单独的服务账号启动。
 每个控制环都有相应的、前缀为 `system:controller:` 的角色。
 如果控制管理器启动时未设置 `--use-service-account-credentials`，
@@ -1410,7 +1410,7 @@ containing that permission. To allow a user to create/update roles:
     * implicitly, by giving them those permissions (if they attempt to create or modify a `Role` or `ClusterRole` with permissions they themselves have not been granted, the API request will be forbidden)
     * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer)
 
-A user can only create/update a role binding if they already have all the permissions contained in the referenced role 
+A user can only create/update a role binding if they already have all the permissions contained in the referenced role
 (at the same scope as the role binding) *or* if they've been given explicit permission to perform the `bind` verb on the referenced role.
 For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRoleBinding`
 to a role that grants that permission. To allow a user to create/update role bindings:
@@ -1422,7 +1422,7 @@ to a role that grants that permission. To allow a user to create/update role bin
 -->
 ## 初始化与预防权限升级
 
-RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 
+RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。
 由于这一点是在 API 级别实现的，所以在 RBAC 鉴权器（RBAC authorizer）未启用的状态下依然可以正常工作。
 
 用户只有在符合下列条件之一的情况下，才能创建/更新角色:
@@ -1465,6 +1465,7 @@ rules:
 - apiGroups: ["rbac.authorization.k8s.io"]
   resources: ["clusterroles"]
   verbs: ["bind"]
+  # omit resourceNames to allow binding any ClusterRole
   resourceNames: ["admin","edit","view"]
 ---
 apiVersion: rbac.authorization.k8s.io/v1
@@ -1502,6 +1503,7 @@ rules:
 - apiGroups: ["rbac.authorization.k8s.io"]
   resources: ["clusterroles"]
   verbs: ["bind"]
+  # 省略 resourceNames 则允许绑定任何 ClusterRole
   resourceNames: ["admin","edit","view"]
 ---
 apiVersion: rbac.authorization.k8s.io/v1
@@ -2078,7 +2080,7 @@ in the server logs, you can remove the ABAC authorizer.
 ### 平行鉴权
 
 同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含
-[现有的 ABAC 策略](/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件：
+[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件：
 
 ```
 --authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json
@@ -2134,5 +2136,3 @@ kubectl create clusterrolebinding permissive-binding \
   --group=system:serviceaccounts
 ```
 {{< /warning >}}
-
-
diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md
index 0cf89e8ec7..cb559d0505 100644
--- a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md
@@ -7,7 +7,7 @@ approvers:
 title: 管理 Service Accounts
 ---
 
-*这是一篇针对service accounts（服务账户）的集群管理员指南。  它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。*
+*这是一篇针对service accounts（服务账户）的集群管理员指南。  它呈现了 [User Guide to Service Accounts](/zh/docs/tasks/configure-pod-container/configure-service-account/)中的信息。*
 
 *对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述 service accounts，有时这些不完善的特性也会被提及。*
 
@@ -32,7 +32,7 @@ Kubernetes 区分用户账户和服务账户的概念主要基于以下原因：
 
 ### 服务账户准入控制器
 
-对 pod 的改动通过一个被称为 [Admission Controller](/docs/admin/admission-controllers) 的插件来实现。它是 apiserver 的一部分。
+对 pod 的改动通过一个被称为 [Admission Controller](/zh/docs/reference/access-authn-authz/admission-controllers/) 的插件来实现。它是 apiserver 的一部分。
 当 pod 被创建或更新时，它会同步地修改 pod。 当该插件处于激活状态 ( 在大多数发行版中都是默认的 )，当 pod 被创建或更新时它会进行以下动作：
 
   1. 如果该 pod 没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。
diff --git a/content/zh/docs/reference/access-authn-authz/webhook.md b/content/zh/docs/reference/access-authn-authz/webhook.md
index a77f9df2b5..8cfdc91592 100644
--- a/content/zh/docs/reference/access-authn-authz/webhook.md
+++ b/content/zh/docs/reference/access-authn-authz/webhook.md
@@ -8,7 +8,7 @@ title: Webhook 模式
 content_type: concept
 weight: 95
 ---
-<!-- 
+<!--
 ---
 reviewers:
 - erictune
@@ -18,47 +18,47 @@ reviewers:
 title: Webhook Mode
 content_type: concept
 weight: 95
---- 
+---
 -->
 
 <!-- overview -->
-<!-- 
-A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. 
+<!--
+A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
 -->
 WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
 
 
 <!-- body -->
-<!-- 
+<!--
 When specified, mode `Webhook` causes Kubernetes to query an outside REST
-service when determining user privileges. 
+service when determining user privileges.
 -->
 具体来说，当在判断用户权限时，`Webhook` 模式会使 Kubernetes 查询外部的 REST 服务。
 
-<!-- 
-## Configuration File Format 
+<!--
+## Configuration File Format
 -->
 ## 配置文件格式
 
-<!-- 
+<!--
 Mode `Webhook` requires a file for HTTP configuration, specify by the
-`--authorization-webhook-config-file=SOME_FILENAME` flag. 
+`--authorization-webhook-config-file=SOME_FILENAME` flag.
 -->
 `Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
 
-<!-- 
+<!--
 The configuration file uses the [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 file format. Within the file "users" refers to the API Server webhook and
-"clusters" refers to the remote service. 
+"clusters" refers to the remote service.
 -->
-配置文件的格式使用 [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。
+配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。
 
-<!-- 
-A configuration example which uses HTTPS client auth: 
+<!--
+A configuration example which uses HTTPS client auth:
 -->
 使用 HTTPS 客户端认证的配置例子：
 
-<!-- 
+<!--
 ```yaml
 # Kubernetes API version
 apiVersion: v1
@@ -87,7 +87,7 @@ contexts:
     cluster: name-of-remote-authz-service
     user: name-of-api-server
   name: webhook
-``` 
+```
 -->
 ```yaml
 # Kubernetes API 版本
@@ -119,31 +119,31 @@ contexts:
   name: webhook
 ```
 
-<!-- 
-## Request Payloads 
+<!--
+## Request Payloads
 -->
 ## 请求载荷
 
-<!-- 
+<!--
 When faced with an authorization decision, the API Server POSTs a JSON-
 serialized `authorization.k8s.io/v1beta1` `SubjectAccessReview` object describing the
 action. This object contains fields describing the user attempting to make the
 request, and either details about the resource being accessed or requests
-attributes. 
+attributes.
 -->
 在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。
 
-<!-- 
+<!--
 Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/)
 as other Kubernetes API objects. Implementers should be aware of looser
 compatibility promises for beta objects and check the "apiVersion" field of the
 request to ensure correct deserialization. Additionally, the API Server must
-enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`). 
+enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
 -->
-需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从[版本兼容规则](/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
+需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
 
-<!-- 
-An example request body: 
+<!--
+An example request body:
 -->
 一个请求内容的例子：
 
@@ -167,10 +167,10 @@ An example request body:
 }
 ```
 
-<!-- 
+<!--
 The remote service is expected to fill the `status` field of
 the request and respond to either allow or disallow access. The response body's
-`spec` field is ignored and may be omitted. A permissive response would return: 
+`spec` field is ignored and may be omitted. A permissive response would return:
 -->
 期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回:
 ```json
@@ -183,17 +183,17 @@ the request and respond to either allow or disallow access. The response body's
 }
 ```
 
-<!-- 
-For disallowing access there are two methods. 
+<!--
+For disallowing access there are two methods.
 -->
 为了禁止访问，有两种方法。
 
-<!-- 
+<!--
 The first method is preferred in most cases, and indicates the authorization
-webhook does not allow, or has "no opinion" about the request, but if other 
-authorizers are configured, they are given a chance to allow the request. 
-If there are no other authorizers, or none of them allow the request, the 
-request is forbidden. The webhook would return: 
+webhook does not allow, or has "no opinion" about the request, but if other
+authorizers are configured, they are given a chance to allow the request.
+If there are no other authorizers, or none of them allow the request, the
+request is forbidden. The webhook would return:
 -->
 在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求"无意见"，但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回:
 
@@ -208,11 +208,11 @@ request is forbidden. The webhook would return:
 }
 ```
 
-<!-- 
-The second method denies immediately, short-circuiting evaluation by other 
-configured authorizers. This should only be used by webhooks that have 
-detailed knowledge of the full authorizer configuration of the cluster. 
-The webhook would return: 
+<!--
+The second method denies immediately, short-circuiting evaluation by other
+configured authorizers. This should only be used by webhooks that have
+detailed knowledge of the full authorizer configuration of the cluster.
+The webhook would return:
 -->
 第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回:
 
@@ -228,8 +228,8 @@ The webhook would return:
 }
 ```
 
-<!-- 
-Access to non-resource paths are sent as: 
+<!--
+Access to non-resource paths are sent as:
 -->
 对于非资源的路径访问是这么发送的:
 
@@ -251,25 +251,21 @@ Access to non-resource paths are sent as:
 }
 ```
 
-<!-- 
+<!--
 Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
 `/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
 `/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
 and `/version` to discover what resources and versions are present on the server.
 Access to other non-resource paths can be disallowed without restricting access
-to the REST api. 
+to the REST api.
 -->
 非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`,
 `/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 和
 `/version`。客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便
 能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。
 
-<!-- 
+<!--
 For further documentation refer to the authorization.v1beta1 API objects and
-[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). 
+[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
 -->
 更多信息可以参考 authorization.v1beta1 API 对象和[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。
-
-
-
-
diff --git a/content/zh/docs/reference/command-line-tools-reference/_index.md b/content/zh/docs/reference/command-line-tools-reference/_index.md
index 4e2fcd252c..2fc8e545e3 100644
--- a/content/zh/docs/reference/command-line-tools-reference/_index.md
+++ b/content/zh/docs/reference/command-line-tools-reference/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 命令行工具参考
 weight: 60
-toc-hide: true
 ---
diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
index 295eb2a968..bd27310314 100644
--- a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
@@ -99,23 +99,18 @@ different Kubernetes components.
 
 | 特性 | 默认值 | 状态 | 开始(Since) | 结束(Until) |
 |---------|---------|-------|-------|-------|
+| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | |
 | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
 | `APIListChunking` | `true` | Beta | 1.9 | |
 | `APIPriorityAndFairness` | `false` | Alpha | 1.17 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
 | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
-| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
-| `BlockVolume` | `true` | Beta | 1.13 | - |
 | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
 | `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
 | `CPUManager` | `true` | Beta | 1.10 | |
 | `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 |
 | `CRIContainerLogRotation` | `true` | Beta| 1.11 | |
-| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
-| `CSIBlockVolume` | `true` | Beta | 1.14 | |
-| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
-| `CSIDriverRegistry` | `true` | Beta | 1.14 | |
 | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
 | `CSIInlineVolume` | `true` | Beta | 1.16 | - |
 | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
@@ -123,7 +118,8 @@ different Kubernetes components.
 | `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
 | `CSIMigrationAWS` | `false` | Beta | 1.17 | |
 | `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | |
-| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | |
+| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 |
+| `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | |
 | `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | |
 | `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | |
@@ -132,18 +128,27 @@ different Kubernetes components.
 | `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
 | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
+| `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
+| `CSIMigrationvSphereComplete` | `false` | Beta | 1.19 | |
+| `CSIStorageCapacity` | `false` | Alpha | 1.19 | |
+| `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | |
+| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
 | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
+| `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | |
 | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | Beta | 1.10 | |
+| `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.20 |
 | `DryRun` | `false` | Alpha | 1.12 | 1.12 |
 | `DryRun` | `true` | Beta | 1.13 | |
-| `DynamicAuditing` | `false` | Alpha | 1.13 | |
 | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
 | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | Beta | 1.17 | |
+| `EndpointSlice` | `true` | Beta | 1.18 | |
+| `EndpointSliceProxying` | `false` | Alpha | 1.18 | 1.18 |
+| `EndpointSliceProxying` | `true` | Beta | 1.19 | |
 | `EphemeralContainers` | `false` | Alpha | 1.16 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
@@ -152,9 +157,14 @@ different Kubernetes components.
 | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `EvenPodsSpread` | `false` | Alpha | 1.16 | |
+| `GenericEphemeralVolume` | `false` | Alpha | 1.19 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
+| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 |
+| `HugePageStorageMediumSize` | `true` | Beta | 1.19 | |
 | `HyperVContainer` | `false` | Alpha | 1.10 | |
+| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 |
+| `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | |
+| `IPv6DualStack` | `false` | Alpha | 1.16 | |
 | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | Beta | 1.15 | |
 | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
@@ -162,36 +172,41 @@ different Kubernetes components.
 | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
 | `MountContainers` | `false` | Alpha | 1.9 | |
-| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
-| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
+| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 |
+| `NodeDisruptionExclusion` | `true` | Beta | 1.19 | |
+| `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 |
+| `NonPreemptingPriority` | `true` | Beta | 1.19 | |
+| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 |
+| `PodDisruptionBudget` | `true` | Beta | 1.5 | |
 | `PodOverhead` | `false` | Alpha | 1.16 | - |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | |
-| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
-| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
 | `RunAsGroup` | `true` | Beta | 1.14 | |
 | `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | Beta | 1.14 | |
-| `SCTPSupport` | `false` | Alpha | 1.12 | |
+| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | Beta | 1.19 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
-| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
+| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
+| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
+| `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
 | `ServiceTopology` | `false` | Alpha | 1.17 | |
-| `StartupProbe` | `false` | Alpha | 1.16 | |
+| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | |
+| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
+| `StartupProbe` | `true` | Beta | 1.18 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
-| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
-| `StreamingProxyRedirects` | `true` | Beta | 1.6 | |
 | `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
 | `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
 | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
 | `SupportPodPidsLimit` | `true` | Beta | 1.14 | |
 | `Sysctls` | `true` | Beta | 1.11 | |
-| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
-| `TaintBasedEvictions` | `true` | Beta | 1.13 | |
 | `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
 | `TokenRequest` | `true` | Beta | 1.12 | |
 | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
@@ -200,10 +215,9 @@ different Kubernetes components.
 | `TopologyManager` | `false` | Alpha | 1.16 | |
 | `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
 | `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
-| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
-| `VolumePVCDataSource` | `true` | Beta | 1.16 | |
 | `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 |
 | `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | - |
+| `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | |
 | `WindowsGMSA` | `false` | Alpha | 1.14 | |
 | `WindowsGMSA` | `true` | Beta | 1.16 | |
 | `WinDSR` | `false` | Alpha | 1.14 | |
@@ -236,6 +250,15 @@ different Kubernetes components.
 | `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
 | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
 | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
+| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
+| `BlockVolume` | `true` | Beta | 1.13 | 1.17 |
+| `BlockVolume` | `true` | GA | 1.18 | - |
+| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
+| `CSIBlockVolume` | `true` | Beta | 1.14 | 1.17 |
+| `CSIBlockVolume` | `true` | GA | 1.18 | - |
+| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
+| `CSIDriverRegistry` | `true` | Beta | 1.14 | 1.17 |
+| `CSIDriverRegistry` | `true` | GA | 1.18 | |
 | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
 | `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 |
 | `CSINodeInfo` | `true` | GA | 1.17 | |
@@ -260,6 +283,8 @@ different Kubernetes components.
 | `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
 | `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
+| `DynamicAuditing` | `false` | Alpha | 1.13 | 1.18 |
+| `DynamicAuditing` | - | Deprecated | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
@@ -268,6 +293,9 @@ different Kubernetes components.
 | `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
 | `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - |
+| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 |
+| `EvenPodsSpread` | `true` | Beta | 1.18 | 1.18 |
+| `EvenPodsSpread` | `true` | GA | 1.19 | - |
 | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | Alpha | 1.8 | 1.9 |
@@ -301,9 +329,13 @@ different Kubernetes components.
 | `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
 | `PVCProtection` | - | Deprecated | 1.10 | - |
 | `RequestManagement` | `false` | Alpha | 1.15 | 1.16 |
+| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | 1.18 |
+| `ResourceLimitsPriorityFunction` | - | Deprecated | 1.19 | - |
 | `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
 | `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | 1.16 |
 | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
+| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | 1.18 |
+| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
 | `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
 | `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16  |
 | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
@@ -312,13 +344,22 @@ different Kubernetes components.
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
 | `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
+| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
+| `StreamingProxyRedirects` | `true` | Beta | 1.6 | 1.18 |
+| `StreamingProxyRedirects` | - | Deprecated| 1.19 | - |
 | `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
 | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
+| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
+| `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 |
+| `TaintBasedEvictions` | `true` | GA | 1.18 | - |
 | `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
 | `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 |
 | `TaintNodesByCondition` | `true` | GA | 1.17 | - |
+| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
+| `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 |
+| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
 | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
@@ -329,6 +370,12 @@ different Kubernetes components.
 | `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
 | `WatchBookmark` | `true` | Beta | 1.16 | 1.16 |
 | `WatchBookmark` | `true` | GA | 1.17 | - |
+| `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 |
+| `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 |
+| `WindowsGMSA` | `true` | GA | 1.18 | - |
+| `WindowsRunAsUserName` | `false` | Alpha | 1.16 | 1.16 |
+| `WindowsRunAsUserName` | `true` | Beta | 1.17 | 1.17 |
+| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
 
 {{< /table >}}
 
@@ -430,8 +477,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
 <!--
 - `Accelerators`: Enable Nvidia GPU support when using Docker
 - `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit)
-- `AffinityInAnnotations`(*deprecated*): Enable setting [Pod affinity or anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
+- `AffinityInAnnotations`(*deprecated*): Enable setting [Pod affinity or anti-affinity](docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).
 - `AllowExtTrafficLocalEndpoints`: Enable a service to route external requests to node local endpoints.
+- `AnyVolumeDataSource`: Enable use of any custom resource as the `DataSource` of a
+  {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}.
 - `APIListChunking`: Enable the API clients to retrieve (`LIST` or `GET`) resources from API server in chunks.
 - `APIPriorityAndFairness`: Enable managing request concurrency with prioritization and fairness at each server. (Renamed from `RequestManagement`)
 - `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests.
@@ -440,14 +489,15 @@ Each feature gate is designed for enabling/disabling a specific feature:
 -->
 
 - `Accelerators`：使用 Docker 时启用 Nvidia GPU 支持。
-- `AdvancedAuditing`：启用[高级审查功能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)。
-- `AffinityInAnnotations`（ *已弃用* ）：启用 [Pod 亲和力或反亲和力](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)。
+- `AdvancedAuditing`：启用[高级审计功能](/zh/docs/tasks/debug-application-cluster/audit/#advanced-audit)。
+- `AffinityInAnnotations`（ *已弃用* ）：启用 [Pod 亲和或反亲和](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)。
 - `AllowExtTrafficLocalEndpoints`：启用服务用于将外部请求路由到节点本地终端。
+- `AnyVolumeDataSource`: 允许使用任何自定义的资源来做作为 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}} 中的 `DataSource`.
 - `APIListChunking`：启用 API 客户端以块的形式从 API 服务器检索（“LIST” 或 “GET”）资源。
 - `APIPriorityAndFairness`: Enable managing request concurrency with prioritization and fairness at each server. (Renamed from `RequestManagement`)
 - `APIPriorityAndFairness`: 在每个服务器上启用优先级和公平性来管理请求并发。（由 `RequestManagement` 重命名而来）
 - `APIResponseCompression`：压缩 “LIST” 或 “GET” 请求的 API 响应。
-- `AppArmor`：使用 Docker 时，在 Linux 节点上启用基于 AppArmor 机制的强制访问控制。请参见 [AppArmor 教程](/docs/tutorials/clusters/apparmor/) 获取详细信息。
+- `AppArmor`：使用 Docker 时，在 Linux 节点上启用基于 AppArmor 机制的强制访问控制。请参见 [AppArmor 教程](/zh/docs/tutorials/clusters/apparmor/) 获取详细信息。
 
 <!--
 - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes
@@ -463,14 +513,16 @@ Each feature gate is designed for enabling/disabling a specific feature:
    ServiceAccountTokenVolumeProjection.
    Check [Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)
    for more details.
+- `ConfigurableFSGroupPolicy`: Allows user to configure volume permission change policy for fsGroups when mounting a volume in a Pod. See [Configure volume permission and ownership change policy for Pods](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods) for more details.
 - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
 -->
 
-- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参见[动态卷限制](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)。
+- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参见[动态卷限制](/zh/docs/concepts/storage/storage-limits/#dynamic-volume-limits)。
 - `BalanceAttachedNodeVolumes`：包括要在调度时进行平衡资源分配的节点上的卷数。scheduler 在决策时会优先考虑 CPU、内存利用率和卷数更近的节点。
-- `BlockVolume`：在 Pod 中启用原始块设备的定义和使用。有关更多详细信息，请参见[原始块卷支持](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
+- `BlockVolume`：在 Pod 中启用原始块设备的定义和使用。有关更多详细信息，请参见[原始块卷支持](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
 - `BoundServiceAccountTokenVolume`：迁移 ServiceAccount 卷以使用由 ServiceAccountTokenVolumeProjection 组成的预计卷。有关更多详细信息，请参见 [Service Account Token 卷](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)。
-- `CPUManager`：启用容器级别的 CPU 亲和力支持，有关更多详细信息，请参见 [CPU 管理策略](/docs/tasks/administer-cluster/cpu-management-policies/)。
+- `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup 配置卷访问权限和属主变更策略。请参见 [为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。
+- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见 [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。
 
 <!--
 - `CRIContainerLogRotation`: Enable container log rotation for cri container runtime.
@@ -487,35 +539,41 @@ Each feature gate is designed for enabling/disabling a specific feature:
 -->
 
 - `CRIContainerLogRotation`：为 cri 容器运行时启用容器日志轮换。
-- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见 [`csi` 原始块卷支持](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。
+- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见 [`csi` 原始块卷支持](/zh/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。
 - `CSIDriverRegistry`：在 csi.storage.k8s.io 中启用与 CSIDriver API 对象有关的所有逻辑。
 - `CSIInlineVolume`：为 Pod 启用 CSI 内联卷支持。
 - `CSIMigration`：确保填充和转换逻辑能够将卷操作从内嵌插件路由到相应的预安装 CSI 插件。
 - `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。如果节点未安装和配置 EBS CSI 插件，则支持回退到内嵌 EBS 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在群集中的所有节点上安装和配置 EBS CSI 插件。
+- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置 EBS CSI 插件。
 - `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 Azure 磁盘内嵌插件路由到 Azure 磁盘 CSI 插件。如果节点未安装和配置 AzureDisk CSI 插件，支持回退到内建 AzureDisk 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志，并在群集中的所有节点上安装和配置 AzureDisk CSI 插件。
+- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志，并在集群中的所有节点上安装和配置 AzureDisk CSI 插件。
 - `CSIMigrationAzureFile`：确保填充和转换逻辑能够将卷操作从 Azure 文件内嵌插件路由到 Azure 文件 CSI 插件。如果节点未安装和配置 AzureFile CSI 插件，支持回退到内嵌 AzureFile 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志，并在群集中的所有节点上安装和配置 AzureFile CSI 插件。
+- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志，并在集群中的所有节点上安装和配置 AzureFile CSI 插件。
 
 <!--
 - `CSIMigrationGCE`: Enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling back to in-tree GCE plugin if a node does not have PD CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
 - `CSIMigrationGCEComplete`: Stops registering the GCE-PD in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Requires CSIMigration and CSIMigrationGCE feature flags enabled and PD CSI plugin installed and configured on all nodes in the cluster.
 - `CSIMigrationOpenStack`: Enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Supports falling back to in-tree Cinder plugin if a node does not have Cinder CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
 - `CSIMigrationOpenStackComplete`: Stops registering the Cinder in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Requires CSIMigration and CSIMigrationOpenStack feature flags enabled and Cinder CSI plugin installed and configured on all nodes in the cluster.
+- `CSIMigrationvSphere`: Enables shims and translation logic to route volume operations from the vSphere in-tree plugin to vSphere CSI plugin. Supports falling back to in-tree vSphere plugin if a node does not have vSphere CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
+- `CSIMigrationvSphereComplete`: Stops registering the vSphere in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the vSphere in-tree plugin to vSphere CSI plugin. Requires CSIMigration and CSIMigrationvSphere feature flags enabled and vSphere CSI plugin installed and configured on all nodes in the cluster.
 - `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io.
 - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
   [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
   compatible volume plugin.
-  Check the [`csi` volume type](/docs/concepts/storage/volumes/#csi) documentation for more details.
 -->
 
-- `CSIMigrationGCE`：使 shims 和转换逻辑能够将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在群集中的所有节点上安装和配置 PD CSI 插件。
+- `CSIMigrationGCE`：启用 shims 和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。这需要启用 CSIMigration 特性标志。
+- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在集群中的所有节点上安装和配置 PD CSI 插件。
 - `CSIMigrationOpenStack`：确保填充和转换逻辑能够将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。如果节点未安装和配置 Cinder CSI 插件，支持回退到内嵌 Cinder 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件，并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在群集中的所有节点上安装和配置 Cinder CSI 插件。
+- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件，并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在集群中的所有节点上安装和配置 Cinder CSI 插件。
+- `CSIMigrationvSphere`: 启用 shims 和转换逻辑，将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。如果节点未安装和配置 vSphere CSI 插件，则支持回退到 vSphere 内嵌插件。这需要启用 CSIMigration 特性标志。
+- `CSIMigrationvSphereComplete`: 停止在 kubelet 和卷控制器中注册 vSphere 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。这需要启用 CSIMigration 和 CSIMigrationvSphere 特性标志，并在集群中的所有节点上安装和配置 vSphere CSI 插件。
 - `CSINodeInfo`：在 csi.storage.k8s.io 中启用与 CSINodeInfo API 对象有关的所有逻辑。
-- `CSIPersistentVolume`：启用发现并挂载通过 [CSI（容器存储接口）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)兼容卷插件配置的卷。有关更多详细信息，请参见 [`csi` 卷类型](/docs/concepts/storage/volumes/#csi)。
+- `CSIPersistentVolume`：启用发现和挂载通过 [CSI（容器存储接口）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)兼容卷插件配置的卷。
+- `CSIStorageCapacity`: 使 CSI 驱动程序可以发布存储容量信息，并使 Kubernetes 调度程序在调度 Pod 时使用该信息。 参见 [存储容量](/zh/docs/concepts/storage/storage-capacity/)。
+  详情请参见 [`csi` 卷类型](/zh/docs/concepts/storage/volumes/#csi)。
+- `CSIVolumeFSGroupPolicy`: 允许 CSIDrivers 使用 `fsGroupPolicy` 字段. 该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。
 
 <!--
 - `CustomCPUCFSQuotaPeriod`: Enable nodes to change CPUCFSQuotaPeriod.
@@ -525,41 +583,47 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `CustomResourceDefaulting`: Enable CRD support for default values in OpenAPI v3 validation schemas.
 - `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
 - `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
-  on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
+  on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 - `CustomResourceValidation`: Enable schema based validation on resources created from
-  [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
+  [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 - `CustomResourceWebhookConversion`: Enable webhook-based conversion
-  on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
+  on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
   troubleshoot a running Pod.
 -->
 
 - `CustomCPUCFSQuotaPeriod`：使节点能够更改 CPUCFSQuotaPeriod。
-- `CustomPodDNS`：使用其 `dnsConfig` 属性启用 Pod 的自定义 DNS 设置。有关更多详细信息，请参见 [Pod 的 DNS 配置](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。
+- `CustomPodDNS`：使用其 `dnsConfig` 属性启用 Pod 的自定义 DNS 设置。有关更多详细信息，请参见 [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。
 - `CustomResourceDefaulting`：为 OpenAPI v3 验证架构中的默认值启用 CRD 支持。
 - `CustomResourcePublishOpenAPI`：启用 CRD OpenAPI 规范的发布。
-- `CustomResourceSubresources`：对于从 [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/) 中创建的资源启用 `/status` 和 `/scale` 子资源。
-- `CustomResourceValidation`：对于从 [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/) 中创建的资源启用基于架构的验证。
-- `CustomResourceWebhookConversion`：对于从 [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/) 中创建的资源启用基于 Webhook 的转换。
+- `CustomResourceSubresources`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用 `/status` 和 `/scale` 子资源。
+- `CustomResourceValidation`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用基于模式的验证。
+- `CustomResourceWebhookConversion`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用基于 Webhook 的转换。
   对正在运行的 Pod 进行故障排除。
 
 <!--
+- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/system-metrics/).
 - `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
   based resource provisioning on nodes.
+- `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
+  [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
 - `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests
   so that validation, merging, and mutation can be tested without committing.
-- `DynamicAuditing`: Enable [dynamic auditing](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)
+- `DynamicAuditing`(*deprecated*): Used to enable dynamic auditing before v1.19.
 - `DynamicKubeletConfig`: Enable the dynamic configuration of kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/).
 - `DynamicProvisioningScheduling`: Extend the default scheduler to be aware of volume topology and handle PV provisioning.
   This feature is superseded by the `VolumeScheduling` feature completely in v1.12.
 - `DynamicVolumeProvisioning`(*deprecated*): Enable the [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/) of persistent volumes to Pods.
 -->
 
-- `DevicePlugins`：在节点上启用基于 [device-plugins](/docs/concepts/cluster-administration/device-plugins/) 的资源供应。
-- `DryRun`：启用服务器端 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 请求，以便无需提交即可测试验证、合并和差异化。
-- `DynamicAuditing`：确保[动态审查](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)。
-- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅[重新配置 kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/)。
+- `DisableAcceleratorUsageMetrics`: [禁用 kubelet 收集加速器指标](/zh/docs/concepts/cluster-administration/system-metrics/).
+- `DevicePlugins`：在节点上启用基于 [device-plugins](/zh/docs/concepts/cluster-administration/device-plugins/) 的资源供应。
+- `DefaultPodTopologySpread`: 启用 `PodTopologySpread` 调度插件来做
+  [默认的调度传播](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
+- `DryRun`：启用服务器端 [dry run](/zh/docs/reference/using-api/api-concepts/#dry-run) 请求，以便无需提交即可测试验证、合并和差异化。
+- `DynamicAuditing`（ *已弃用* ）：在 v1.19 版本前用于启用动态审计。
+- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅[重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。
 - `DynamicProvisioningScheduling`：扩展默认 scheduler 以了解卷拓扑并处理 PV 配置。此特性已在 v1.12 中完全被 `VolumeScheduling` 特性取代。
-- `DynamicVolumeProvisioning`（ *已弃用* ）：启用持久化卷到 Pod 的[动态预配置](/docs/concepts/storage/dynamic-provisioning/)。
+- `DynamicVolumeProvisioning`（ *已弃用* ）：启用持久化卷到 Pod 的[动态预配置](/zh/docs/concepts/storage/dynamic-provisioning/)。
 
 <!--
 - `EnableAggregatedDiscoveryTimeout` (*deprecated*): Enable the five second timeout on aggregated discovery calls.
@@ -577,9 +641,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。
 - `EphemeralContainers`：启用添加 {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} 到正在运行的 Pod 的特性。
 - `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
-- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅 [调整使用中的 PersistentVolumeClaim 的大小](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
+- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅[调整使用中的 PersistentVolumeClaim 的大小](/zh/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
 - `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅[扩展永久卷声明](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
-- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
+- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
 
 <!--
 - `ExperimentalHostUserNamespaceDefaultingGate`: Enabling the defaulting user
@@ -588,49 +652,66 @@ Each feature gate is designed for enabling/disabling a specific feature:
    capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled
    if user namespace remapping is enabled in the Docker daemon.
 - `EndpointSlice`: Enables Endpoint Slices for more scalable and extensible
-   network endpoints. Requires corresponding API and Controller to be enabled.
-   See [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
+   network endpoints. See [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
+- `EndpointSliceProxying`: When this feature gate is enabled, kube-proxy running
+   on Linux will use EndpointSlices as the primary data source instead of
+   Endpoints, enabling scalability and performance improvements. See
+   [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
+- `WindowsEndpointSliceProxying`: When this feature gate is enabled, kube-proxy
+   running on Windows will use EndpointSlices as the primary data source instead
+   of Endpoints, enabling scalability and performance improvements. See
+   [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
 - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE.
+- `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features of normal volumes (can be provided by third-party storage vendors, storage capacity tracking, restore from snapshot, etc.). See [Ephemeral Volumes](/docs/concepts/storage/ephemeral-volumes/).
 - `HugePages`: Enable the allocation and consumption of pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
+- `HugePageStorageMediumSize`: Enable support for multiple sizes pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
 -->
 
 - `ExperimentalHostUserNamespaceDefaultingGate`：启用主机默认的用户命名空间。这适用于使用其他主机命名空间、主机安装的容器，或具有特权或使用特定的非命名空间功能（例如MKNODE、SYS_MODULE等）的容器。如果在 Docker 守护程序中启用了用户命名空间重新映射，则启用此选项。
-- `EndpointSlice`：启用端点切片以实现更多可扩展的网络端点。需要启用相应的 API 和控制器，请参阅[启用端点切片](/docs/tasks/administer-cluster/enabling-endpointslices/)。
+- `EndpointSlice`：启用 EndpointSlice 以实现更多可扩展的网络端点。需要启用相应的 API 和控制器，请参阅[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+- `EndpointSliceProxying`：启用此特性门控后，Linux 上运行的 kube-proxy 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见
+   [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+- `WindowsEndpointSliceProxying`：启用此特性门控后，Windows 上运行的 kube-proxy 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见
+   [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
 - `GCERegionalPersistentDisk`：在 GCE 上启用区域 PD 特性。
-- `HugePages`: 启用分配和使用预分配的 [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)。
+- `GenericEphemeralVolume`：启用支持临时卷和内联卷的（可以由第三方存储供应商提供，存储容量跟踪，从快照还原，等等）所有功能。请参见[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。
+- `HugePages`：启用分配和使用预分配的[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
+- `HugePageStorageMediumSize`：启用支持多种大小的预分配[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
 
 <!--
 - `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers.
 - `HPAScaleToZero`: Enables setting `minReplicas` to 0 for `HorizontalPodAutoscaler` resources when using custom or external metrics.
+- `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as immutable for better safety and performance.
 - `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file.
   See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details.
 - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
   to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
 - `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
-   See [Support Device Monitoring](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md) for more details.
-- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels.
+   See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details.
+- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
 -->
 
 - `HyperVContainer`：为 Windows 容器启用[Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。
 - `HPAScaleToZero`：使用自定义指标或外部指标时，可将 `HorizontalPodAutoscaler` 资源的 `minReplicas` 设置为 0。
-- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。有关更多详细信息，请参见[通过配置文件设置 kubelet 参数](/docs/tasks/administer-cluster/kubelet-config-file/)。
-- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现插件，例如 [CSI 卷驱动程序](/docs/concepts/storage/volumes/#csi)。
-- `KubeletPodResources`：启用 kubelet 的 pod 资源 grpc 端点。有关更多详细信息，请参见[支持设备监控](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)。
-- `LegacyNodeRoleBehavior`：禁用此选项后，服务负载均衡中的旧版操作和节点中断将忽略 `node-role.kubernetes.io/master` 标签，而使用特性指定的标签。
+- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的，以提高安全性和性能。
+- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。有关更多详细信息，请参见[通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。
+- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现插件，例如 [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)。
+- `KubeletPodResources`：启用 kubelet 的 pod 资源 grpc 端点。有关更多详细信息，请参见[支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。
+- `LegacyNodeRoleBehavior`：禁用此选项后，服务负载均衡中的传统行为和节点中断将忽略 `node-role.kubernetes.io/master` 标签，而使用 `NodeDisruptionExclusion` 和 `ServiceNodeExclusion` 提供的特性指定的标签。
 
 <!--
-- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
+- `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
 - `MountContainers`: Enable using utility containers on host as the volume mounter.
 - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
   For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
 - `NodeDisruptionExclusion`: Enable use of the node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures.
 -->
 
-- `LocalStorageCapacityIsolation`：启用[本地临时存储](/docs/concepts/configuration/manage-compute-resources-container/)的消耗，以及 [emptyDir 卷](/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果为[本地临时存储](/docs/concepts/configuration/manage-compute-resources-container/)启用了 `LocalStorageCapacityIsolation`，并且 [emptyDir 卷](/docs/concepts/storage/volumes/#emptydir) 的后备文件系统支持项目配额，并且启用了这些配额，请使用项目配额来监视 [emptyDir 卷](/docs/concepts/storage/volumes/#emptydir)的存储消耗而不是遍历文件系统，以此获得更好的性能和准确性。
+- `LocalStorageCapacityIsolation`：允许使用[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)以及 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)启用了 `LocalStorageCapacityIsolation`，并且 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的后备文件系统支持项目配额，并且启用了这些配额，请使用项目配额来监视 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗而不是遍历文件系统，以此获得更好的性能和准确性。
 - `MountContainers`：在主机上启用将应用程序容器用作卷安装程序。
-- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。有关更多详细信息，请参见 [mount propagation](/docs/concepts/storage/volumes/#mount-propagation)。
+- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。有关更多详细信息，请参见[挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。
 - `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`，以防止在区域故障期间驱逐节点。
 
 <!--
@@ -638,7 +719,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `NonPreemptingPriority`: Enable NonPreempting option for PriorityClass and Pod.
 - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
   Pod affinity has to be specified if requesting a `local` volume.
-- `PodOverhead`: Enable the [PodOverhead](/docs/concepts/configuration/pod-overhead/) feature to account for pod overheads.
+- `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature.
+- `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/) feature to account for pod overheads.
 - `PodPriority`: Enable the descheduling and preemption of Pods based on their [priorities](/docs/concepts/configuration/pod-priority-preemption/).
 - `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending
   Pod readiness evaluation.  See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
@@ -648,8 +730,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `NodeLease`：启用新的租赁 API 以报告节点心跳，可用作节点运行状况信号。
 - `NonPreemptingPriority`：为 PriorityClass 和 Pod 启用 NonPreempting 选项。
 - `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。如果请求 “本地” 卷，则必须指定 Pod 亲和力。
-- `PodOverhead`：启用 [PodOverhead](/docs/concepts/configuration/pod-overhead/) 特性以解决 Pod 开销。
-- `PodPriority`：根据[优先级](/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。
+- `PodDisruptionBudget`：启用 [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 特性。
+- `PodOverhead`：启用 [PodOverhead](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 特性以考虑 Pod 开销。
+- `PodPriority`：根据[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。
 - `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
 
 <!--
@@ -661,20 +744,20 @@ Each feature gate is designed for enabling/disabling a specific feature:
   being deleted when it is still used by any Pod.
 - `QOSReserved`: Allows resource reservations at the QoS level preventing pods at lower QoS levels from
   bursting into resources requested at higher QoS levels (memory only for now).
-- `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that
+- `ResourceLimitsPriorityFunction` (*deprecated*): Enable a scheduler priority function that
   assigns a lowest possible score of 1 to a node that satisfies at least one of
   the input Pod's cpu and memory limits. The intent is to break ties between
   nodes with same scores.
 -->
 
-- `PodShareProcessNamespace`：在 Pod 中启用 `shareProcessNamespace` 的设置，以便在 Pod 中运行的容器之间共享单个进程命名空间。更多详细信息，请参见[在 Pod 中的容器之间共享进程命名空间](/docs/tasks/configure-pod-container/share-process-namespace/)。
+- `PodShareProcessNamespace`：在 Pod 中启用 `shareProcessNamespace` 的设置，
+   以便在 Pod 中运行的容器之间共享同一进程命名空间。更多详细信息，请参见[在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
 - `ProcMountType`：启用对容器的 ProcMountType 的控制。
-- `PVCProtection`：启用防止任何 Pod 仍使用 PersistentVolumeClaim(PVC) 删除的特性。可以在[此处](/docs/tasks/administer-cluster/storage-object-in-use-protection/)中找到更多详细信息。
+- `PVCProtection`：启用防止任何 Pod 仍使用 PersistentVolumeClaim(PVC) 删除的特性。可以在[此处](/zh/docs/tasks/administer-cluster/storage-object-in-use-protection/)中找到更多详细信息。
 - `QOSReserved`：允许在 QoS 级别进行资源预留，以防止处于较低 QoS 级别的 Pod 突发进入处于较高 QoS 级别的请求资源（仅适用于内存）。
-- `ResourceLimitsPriorityFunction`：启用 scheduler 优先级特性，该特性将最低可能得 1 分配给至少满足输入 Pod 的 cpu 和内存限制之一的节点，目的是打破得分相同的节点之间的联系。
-
+- `ResourceLimitsPriorityFunction` （ *已弃用* ）：启用某调度器优先级函数，该函数将最低得分 1 
+指派给至少满足输入 Pod 的 cpu 和内存限制之一的节点，目的是打破得分相同的节点之间的关联。
 <!--
-- `RequestManagement`: Enable managing request concurrency with prioritization and fairness at each server.
 - `ResourceQuotaScopeSelectors`: Enable resource quota scope selectors.
 - `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
   See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
@@ -685,31 +768,37 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
 -->
 
-- `RequestManagement`：在每个服务器上启用具有优先级和公平性的管理请求并发性。
 - `ResourceQuotaScopeSelectors`：启用资源配额范围选择器。
-- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
-- `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
+- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
+- `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
 - `RunAsGroup`：启用对容器初始化过程中设置的主要组 ID 的控制。
-- `RuntimeClass`：启用 [RuntimeClass](/docs/concepts/containers/runtime-class/) 特性用于选择容器运行时配置。
+- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 特性用于选择容器运行时配置。
 - `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是 DaemonSet 控制器进行调度。
 
 <!--
-- `SCTPSupport`: Enables the usage of SCTP as `protocol` value in `Service`, `Endpoint`, `NetworkPolicy` and `Pod` definitions
-- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
+- `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service, Endpoints, EndpointSlice, and NetworkPolicy definitions.
+- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/server-side-apply/) path at the API Server.
+- `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details.
+- `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints.
 - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
 - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
   A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key or `node.kubernetes.io/exclude-from-external-load-balancers`.
-- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) for more details.
+- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details.
+- `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain Name(FQDN) as hostname of pod. See [Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field).
 - `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet.
 - `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
   PersistentVolumeClaim objects if they are still being used.
 -->
 
-- `SCTPSupport`：在 “服务”、“端点”、“NetworkPolicy” 和 “Pod” 定义中，将 SCTP 用作 “协议” 值。
-- `ServerSideApply`：在 API 服务器上启用[服务器端应用（SSA）](/docs/reference/using-api/api-concepts/#server-side-apply) 路径。
+- `SCTPSupport`：在 Service、Endpoints、NetworkPolicy 和 Pod 定义中，允许将 _SCTP_ 用作 `protocol` 值。
+- `ServerSideApply`：在 API 服务器上启用[服务器端应用（SSA）](/zh/docs/reference/using-api/server-side-apply/) 路径。
+- `ServiceAccountIssuerDiscovery`：在 API 服务器中为服务帐户颁发者启用 OIDC 发现端点。
+   颁发者和 JWKS URL）。 详情请参见[为 Pod 配置服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) 。
+- `ServiceAppProtocol`：为 Service 和 Endpoints 启用 `AppProtocol` 字段。
 - `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器保护。
 - `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，则可以排除节点。
-- `ServiceTopology`: 启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见[Service 拓扑](https://kubernetes.io/zh/docs/concepts/services-networking/service-topology/)
+- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见 [Service 拓扑](/zh/docs/concepts/services-networking/service-topology/)。
+- `SetHostnameAsFQDN`：启用将全限定域名 （FQDN）设置为 Pod 主机名的功能。请参见[给 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。
 - `StartupProbe`：在 kubelet 中启用 [startup](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
 - `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 PersistentVolumeClaim 对象，则将其推迟。
 
@@ -727,13 +816,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
 
 - `StorageVersionHash`：允许 apiserver 在发现中公开存储版本的哈希值。
 - `StreamingProxyRedirects`：指示 API 服务器拦截（并遵循）从后端（kubelet）进行重定向以处理流请求。流请求的例子包括 `exec`、`attach` 和 `port-forward` 请求。
-- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。有关更多详细信息，请参见[服务代理](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。
+- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。有关更多详细信息，请参见[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。
 - `SupportPodPidsLimit`：启用支持限制 Pod 中的进程 PID。
-- `Sysctls`：启用对可以为每个 Pod 设置的命名空间内核参数（sysctls）的支持。有关更多详细信息，请参见 [sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)。
+- `Sysctls`：启用对可以为每个 Pod 设置的命名空间内核参数（sysctls）的支持。有关更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。
 
 <!--
 - `TaintBasedEvictions`: Enable evicting pods from nodes based on taints on nodes and tolerations on Pods.
-  See [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/) for more details.
+  See [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) for more details.
 - `TaintNodesByCondition`: Enable automatic tainting nodes based on [node conditions](/docs/concepts/architecture/nodes/#condition).
 - `TokenRequest`: Enable the `TokenRequest` endpoint on service account resources.
 - `TokenRequestProjection`: Enable the injection of service account tokens into
@@ -742,12 +831,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `TTLAfterFinished`: Allow a [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) to clean up resources after they finish execution.
 -->
 
-- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。有关更多详细信息，请参见[污点和容忍度](/docs/concepts/configuration/taint-and-toleration/)。
-- `TaintNodesByCondition`：根据[节点条件](/docs/concepts/configuration/taint-and-toleration/)启用自动在节点标记污点。
+- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。有关更多详细信息，请参见[污点和容忍度](/zh/docs/concepts/configuration/taint-and-toleration/)。
+- `TaintNodesByCondition`：根据[节点条件](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)启用自动在节点标记污点。
 - `TokenRequest`：在服务帐户资源上启用 `TokenRequest` 端点。
-- `TokenRequestProjection`：启用通过 [`projected` 卷](/docs/concepts/storage/volumes/#projected) 将服务帐户令牌注入到 Pod 中的特性。
-- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。详见 [控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)。
-- `TTLAfterFinished`：完成执行后，允许 [TTL 控制器](/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。
+- `TokenRequestProjection`：启用通过 [`projected` 卷](/zh/docs/concepts/storage/volumes/#projected) 将服务帐户令牌注入到 Pod 中的特性。
+- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。
+- `TTLAfterFinished`：完成执行后，允许 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。
 
 <!--
 - `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource.
@@ -766,6 +855,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `VolumeSubpathEnvExpansion`: Enable `subPathExpr` field for expanding environment variables into a `subPath`.
 - `WatchBookmark`: Enable support for watch bookmark events.
 - `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes.
+- `WindowsRunAsUserName` : Enable support for running applications in Windows containers with as a non-default user.
+  See [Configuring RunAsUserName](/docs/tasks/configure-pod-container/configure-runasusername) for more details.
 - `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
 - `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
 -->
@@ -773,6 +864,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `VolumeSubpathEnvExpansion`：启用 `subPathExpr` 字段用于将环境变量扩展为 `subPath`。
 - `WatchBookmark`：启用对监测 bookmark 事件的支持。
 - `WindowsGMSA`：允许将 GMSA 凭据规范从 Pod 传递到容器运行时。
+- `WindowsRunAsUserName`：提供使用非默认用户在 Windows 容器中运行应用程序的支持。
+  详情请参见[配置 RunAsUserName](/zh/docs/tasks/configure-pod-container/configure-runasusername)。
 - `WinDSR`：允许 kube-proxy 为 Windows 创建 DSR 负载均衡。
 - `WinOverlay`：允许 kube-proxy 在 Windows 的 overlay 模式下运行。
 
@@ -785,6 +878,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
   the project's approach to removing features and components.
 -->
 
-* Kubernetes 的 [弃用策略](/docs/reference/using-api/deprecation-policy/) 介绍了项目已移除的特性部件和组件的方法。
+* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 介绍了项目已移除的特性部件和组件的方法。
 
 
diff --git a/content/zh/docs/reference/glossary/cloud-provider.md b/content/zh/docs/reference/glossary/cloud-provider.md
old mode 100644
new mode 100755
index 30462f792b..0c07cd6fb8
--- a/content/zh/docs/reference/glossary/cloud-provider.md
+++ b/content/zh/docs/reference/glossary/cloud-provider.md
@@ -1,38 +1,59 @@
 ---
-title: 云供应商
+title: 云供应商（Cloud Provider）
 id: cloud-provider
 date: 2018-04-12
-full_link: /zh/docs/concepts/cluster-administration/cloud-providers/
 short_description: >
-  云供应商是提供可以用来运行 Kubernetes 集群的云计算平台的公司。
+  一个提供云计算平台的组织。
 
-aka: 
+aka:
+- 云服务供应商（Cloud Service Provider）
 tags:
 - community
 ---
+ 一个提供云计算平台的商业机构或其他组织。
 
 <!--
----
-title: Cloud Provider
+Cloud Provider）
 id: cloud-provider
 date: 2018-04-12
-full_link: /zh/docs/concepts/cluster-administration/cloud-providers/
 short_description: >
-  Cloud provider is a company that offers cloud computing platform that can run Kubernetes clusters.
+  An organization that offers a cloud computing platform.
 
-aka: 
+aka:
+- Cloud Service Provider
 tags:
 - community
----
--->
-<!--
- Cloud provider is a company that offers cloud computing platform that can run Kubernetes clusters.
--->
- 云供应商是提供可以用来运行 Kubernetes 集群的云计算平台的公司。
 
-<!--more--> 
-<!--
-Cloud providers or sometime called Cloud Service Provider (CSPs) provides cloud computing platforms.  They may offer services such as Infrastructure as a Service (IaaS) or Platform as a Service (PaaS).  Cloud providers host the Kubernetes cluster and also provide services that interact with the cluster, such as Load Balancers, Storage Classes etc. 
+ A business or other organization that offers a cloud computing platform.
 -->
 
-云供应商也叫云服务供应商（CSPs），他们可以为用户提供云计算平台。他们提供的服务可以是基础设施即服务（IaaS）或者平台即服务（PaaS）。云供应商除了运行 Kubernetes 集群，还提供一些集群交互的服务，例如负载均衡（Load Balancers）、存储类别（Storage Classes）等。
+<!--more-->
+
+<!--
+Cloud providers, sometimes called Cloud Service Providers (CSPs), offer
+cloud computing platforms or services.
+
+Many cloud providers offer managed infrastructure (also called
+Infrastructure as a Service or IaaS).
+With managed infrastructure the cloud provider is responsible for
+servers, storage, and networking while you manage layers on top of that
+such as running a Kubernetes cluster.
+
+You can also find Kubernetes as a managed service; sometimes called
+Platform as a Service, or PaaS. With managed Kubernetes, your
+cloud provider is responsible for the Kubernetes control plane as well
+as the glossary_tooltip term_id="node" text="nodes" and the
+infrastructure they rely on: networking, storage, and possibly other
+elements such as load balancers.
+-->
+云供应商，有时也称作云服务供应商（CSPs）提供云计算平台或服务。
+
+很多云供应商提供托管的基础设施（也称作基础设施即服务或 IaaS）。
+针对托管的基础设施，云供应商负责服务器、存储和网络，而用户（你）
+负责管理其上运行的各层软件，例如运行一个 Kubernetes 集群。
+
+你也会看到 Kubernetes 被作为托管服务提供；有时也称作平台即服务或 PaaS。
+针对托管的 Kubernetes，你的云供应商负责 Kubernetes 的控制面以及
+{{< glossary_tooltip term_id="node" text="节点" >}}及他们所依赖的基础设施：
+网络、存储以及其他一些诸如负载均衡器之类的元素。
+
diff --git a/content/zh/docs/reference/glossary/container-env-variables.md b/content/zh/docs/reference/glossary/container-env-variables.md
index d851c14c92..ae2b134643 100644
--- a/content/zh/docs/reference/glossary/container-env-variables.md
+++ b/content/zh/docs/reference/glossary/container-env-variables.md
@@ -2,7 +2,7 @@
 title: 容器环境变量
 id: container-env-variables
 date: 2018-04-12
-full_link: /docs/concepts/containers/container-environment-variables.md
+full_link: /zh/docs/concepts/containers/container-environment/
 short_description: >
   容器环境变量提供了运行容器化应用所必须的一些重要信息。
 
@@ -16,7 +16,7 @@ tags:
 title: Container Environment Variables
 id: container-env-variables
 date: 2018-04-12
-full_link: /docs/concepts/containers/container-environment-variables.md
+full_link: /zh/docs/concepts/containers/container-environment/
 short_description: >
   Container environment variables are name=value pairs that provide useful information into containers running in a Pod.
 
diff --git a/content/zh/docs/reference/glossary/container-runtime.md b/content/zh/docs/reference/glossary/container-runtime.md
index d5568e7fb8..7a68b6fd5c 100644
--- a/content/zh/docs/reference/glossary/container-runtime.md
+++ b/content/zh/docs/reference/glossary/container-runtime.md
@@ -2,7 +2,7 @@
 title: 容器运行环境（Container Runtime）
 id: container-runtime
 date: 2019-06-05
-full_link: /docs/reference/generated/container-runtime
+full_link: /docs/setup/production-environment/container-runtimes
 short_description: >
  容器运行环境是负责运行容器的软件。
 
@@ -16,7 +16,7 @@ tags:
 title: Container Runtime
 id: container-runtime
 date: 2019-06-05
-full_link: /docs/reference/generated/container-runtime
+full_link: /docs/setup/production-environment/container-runtimes
 short_description: >
  The container runtime is the software that is responsible for running containers.
 
@@ -35,11 +35,11 @@ The container runtime is the software that is responsible for running containers
 <!--more-->
 
 <!--
-Kubernetes supports several container runtimes: [Docker](http://www.docker.com),
-[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
-[rktlet](https://github.com/kubernetes-incubator/rktlet) and any implementation of
-the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
+Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}},
+{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
+and any implementation of the [Kubernetes CRI (Container Runtime
+Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
 -->
-Kubernetes 支持多个容器运行环境: [Docker](http://www.docker.com)、
-[containerd](https://containerd.io)、[cri-o](https://cri-o.io/)、
-[rktlet](https://github.com/kubernetes-incubator/rktlet) 以及任何实现 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)。
+Kubernetes 支持多个容器运行环境: {{< glossary_tooltip term_id="docker">}}、
+{{< glossary_tooltip term_id="containerd" >}}、{{< glossary_tooltip term_id="cri-o" >}}
+以及任何实现 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)。
diff --git a/content/zh/docs/reference/glossary/endpoint.md b/content/zh/docs/reference/glossary/endpoint.md
new file mode 100644
index 0000000000..ee9342cd6a
--- /dev/null
+++ b/content/zh/docs/reference/glossary/endpoint.md
@@ -0,0 +1,36 @@
+---
+title: 端点（Endpoints）
+id: endpoints
+date: 2020-04-23
+full_link: 
+short_description: >
+  端点负责记录与服务（Service）的选择器相匹配的 Pods 的 IP 地址。
+
+aka:
+tags:
+- networking
+---
+ 端点负责记录与服务的{{< glossary_tooltip text="选择器" term_id="selector" >}}相匹配的 Pods 的 IP 地址。
+
+<!--
+title: Endpoints
+id: endpoints
+date: 2020-04-23
+full_link: 
+short_description: >
+  Endpoints track the IP addresses of Pods with matching Service selectors.
+
+aka:
+tags:
+- networking
+ Endpoints track the IP addresses of Pods with matching  {{< glossary_tooltip text="selectors" term_id="selector" >}}.
+-->
+
+<!--more-->
+<!--
+Endpoints can be configured manually for Services without selectors specified.
+The EndpointSlice resource provides a scalable and extensible alternative to Endpoints.
+-->
+端点可以手动配置到{{< glossary_tooltip text="服务（Service）" term_id="service" >}}上，而不必设置选择算符。
+{{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} 资源为 Endpoints
+提供了一种可伸缩、可扩展的替代方案。
diff --git a/content/zh/docs/reference/glossary/kube-apiserver.md b/content/zh/docs/reference/glossary/kube-apiserver.md
index c2d0e8a9eb..05f9605b2a 100644
--- a/content/zh/docs/reference/glossary/kube-apiserver.md
+++ b/content/zh/docs/reference/glossary/kube-apiserver.md
@@ -2,9 +2,9 @@
 title: kube-apiserver
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-apiserver/
+full_link: /zh/docs/reference/command-line-tools-reference/kube-apiserver/
 short_description: >
-  主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。
+  提供 Kubernetes API 服务的控制面组件。
 
 aka: 
 tags:
@@ -16,9 +16,9 @@ tags:
 title: kube-apiserver
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-apiserver/
+full_link: /zh/docs/reference/command-line-tools-reference/kube-apiserver/
 short_description: >
-  Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. 
+  Control plane component that serves the Kubernetes API. 
 
 aka: 
 tags:
@@ -27,18 +27,21 @@ tags:
 -->
 
 <!--
- Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. 
+ The API server is a component of the Kubernetes
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}} that exposes the Kubernetes API.
+The API server is the front end for the Kubernetes control plane.
 -->
-
-主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。
+API 服务器是 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}的组件，
+该组件公开了 Kubernetes API。
+API 服务器是 Kubernetes 控制面的前端。
 
 <!--more--> 
 
 <!--
-It is designed to scale horizontally - that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability/).
+The main implementation of a Kubernetes API server is [kube-apiserver](/docs/reference/generated/kube-apiserver/).
+kube-apiserver is designed to scale horizontally&mdash;that is, it scales by deploying more instances.
+You can run several instances of kube-apiserver and balance traffic between those instances.
 -->
-
-kube-apiserver 在设计上考虑了水平扩缩的需要。
-换言之，通过部署多个实例可以实现扩缩。
-参见[构造高可用集群](/docs/admin/high-availability/)。
-
+Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。
+kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。
+你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
diff --git a/content/zh/docs/reference/glossary/mainfest.md b/content/zh/docs/reference/glossary/manifest.md
similarity index 91%
rename from content/zh/docs/reference/glossary/mainfest.md
rename to content/zh/docs/reference/glossary/manifest.md
index 3987ff67d6..2f489f87e9 100644
--- a/content/zh/docs/reference/glossary/mainfest.md
+++ b/content/zh/docs/reference/glossary/manifest.md
@@ -12,7 +12,6 @@ tags:
  JSON 或 YAML 格式的 Kubernetes API 对象规范。
 
 <!--
----
 title: Manifest
 id: manifest
 date: 2019-06-28
@@ -22,7 +21,6 @@ short_description: >
 aka:
 tags:
 - fundamental
----
  Specification of a Kubernetes API object in JSON or YAML format.
 -->
 
@@ -31,4 +29,4 @@ tags:
 <!-- 
 A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests.
  -->
-清单指定了在应用该清单时 Kubrenetes 将维护的对象的期望状态。每个配置文件可包含多个清单。
\ No newline at end of file
+清单指定了在应用该清单时 Kubrenetes 将维护的对象的期望状态。每个配置文件可包含多个清单。
diff --git a/content/zh/docs/reference/glossary/object.md b/content/zh/docs/reference/glossary/object.md
new file mode 100755
index 0000000000..31998e9a7a
--- /dev/null
+++ b/content/zh/docs/reference/glossary/object.md
@@ -0,0 +1,42 @@
+---
+title: 对象
+id: object
+date: 2020-10-12
+full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
+short_description: >
+   Kubernetes 系统中的实体, 代表了集群的部分状态。
+aka: 
+tags:
+- fundamental
+---
+<!-- 
+---
+title: Object
+id: object
+date: 2020-10-12
+full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
+short_description: >
+   A entity in the Kubernetes system, representing part of the state of your cluster.
+aka: 
+tags:
+- fundamental
+---
+-->
+<!-- 
+An entity in the Kubernetes system. The Kubernetes API uses these entities to represent the state
+of your cluster.
+-->
+Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。
+
+<!--more-->
+<!-- 
+A Kubernetes object is typically a “record of intent”—once you create the object, the Kubernetes
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}} works constantly to ensure
+that the item it represents actually exists.
+By creating an object, you're effectively telling the Kubernetes system what you want that part of
+your cluster's workload to look like; this is your cluster's desired state.
+-->
+Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes 
+{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 
+不断工作，以确保它代表的项目确实存在。
+创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。
\ No newline at end of file
diff --git a/content/zh/docs/reference/glossary/rkt.md b/content/zh/docs/reference/glossary/rkt.md
deleted file mode 100644
index 6ba0e19d7d..0000000000
--- a/content/zh/docs/reference/glossary/rkt.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: rkt
-id: rkt
-date: 2019-01-24
-translater: Coffey Gao
-full_link: https://coreos.com/rkt/
-short_description: >
-  一个安全的、基于标准的容器引擎。
-
-aka: 
-tags:
-- security
-- tool
----
-
-<!--
----
-title: rkt
-id: rkt
-date: 2019-01-24
-full_link: https://coreos.com/rkt/
-short_description: >
-  A security-minded, standards-based container engine.
-
-aka: 
-tags:
-- security
-- tool
----
--->
-
-<!--
- A security-minded, standards-based container engine.
--->
- 
- 一个安全的、基于标准的容器引擎。
-
-<!--more--> 
-
-<!--
-rkt is an application {{< glossary_tooltip text="container" term_id="container" >}} engine featuring a {{< glossary_tooltip text="Pod" term_id="pod" >}}-native approach, a pluggable execution environment, and a well-defined surface area. rkt allows users to apply different configurations at both the Pod and application level. Each Pod executes directly in the classic Unix process model, in a self-contained, isolated environment.
--->
-
-rkt 是一个应用程序 {{< glossary_tooltip text="容器" term_id="container" >}} 引擎，它具有原生的 {< glossary_tooltip text="Pod" term_id="pod" >}} 方法、可插拔的执行环境和定义良好的接口。rkt 允许用户在 Pod 和应用程序级别应用不同的配置。每个 Pod 在一个自包含的、独立的经典 Unix 进程模型中直接执行。
\ No newline at end of file
diff --git a/content/zh/docs/reference/glossary/shuffle-sharding.md b/content/zh/docs/reference/glossary/shuffle-sharding.md
new file mode 100644
index 0000000000..1f8d8a0990
--- /dev/null
+++ b/content/zh/docs/reference/glossary/shuffle-sharding.md
@@ -0,0 +1,84 @@
+---
+title: 混排切片（Shuffle Sharding）
+id: shuffle-sharding
+date: 2020-03-04
+full_link:
+short_description: >
+  一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。
+
+aka:
+tags:
+- fundamental
+---
+一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。
+
+<!--
+title: shuffle sharding
+id: shuffle-sharding
+date: 2020-03-04
+full_link:
+short_description: >
+  A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.
+
+aka:
+tags:
+- fundamental
+A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.
+-->
+
+<!--more--> 
+
+<!--
+We are often concerned with insulating different flows of requests
+from each other, so that a high-intensity flow does not crowd out low-intensity flows.
+A simple way to put requests into queues is to hash some
+characteristics of the request, modulo the number of queues, to get
+the index of the queue to use.  The hash function uses as input
+characteristics of the request that align with flows.  For example, in
+the Internet this is often the 5-tuple of source and destination
+address, protocol, and source and destination port.
+-->
+我们通常会关心不同的请求序列间的相互隔离问题，目的是为了确保密度较高的
+请求序列不会湮没密度较低的序列。
+将请求放入不同队列的一种简单方法是对请求的某些特征值执行哈希函数，
+将结果对队列的个数取模，从而得到要使用的队列的索引。
+这一哈希函数使用请求的与其序列相对应的特征作为其输入。例如，在因特网上，
+这一特征通常指的是由源地址、目标地址、协议、源端口和目标端口所组成的
+五元组。
+
+<!--
+That simple hash-based scheme has the property that any high-intensity flow
+will crowd out all the low-intensity flows that hash to the same queue.
+Providing good insulation for a large number of flows requires a large
+number of queues, which is problematic.  Shuffle sharding is a more
+nimble technique that can do a better job of insulating the low-intensity
+flows from the high-intensity flows.  The terminology of shuffle sharding uses
+the metaphor of dealing a hand from a deck of cards; each queue is a
+metaphorical card.  The shuffle sharding technique starts with hashing
+the flow-identifying characteristics of the request, to produce a hash
+value with dozens or more of bits.  Then the hash value is used as a
+source of entropy to shuffle the deck and deal a hand of cards
+(queues).  All the dealt queues are examined, and the request is put
+into one of the examined queues with the shortest length.  With a
+modest hand size, it does not cost much to examine all the dealt cards
+and a given low-intensity flow has a good chance to dodge the effects of a
+given high-intensity flow.  With a large hand size it is expensive to examine
+the dealt queues and more difficult for the low-intensity flows to dodge the
+collective effects of a set of high-intensity flows.  Thus, the hand size
+should be chosen judiciously.
+-->
+这种简单的基于哈希的模式有一种特性，高密度的请求序列（流）会湮没那些被
+哈希到同一队列的其他低密度请求序列（流）。
+为大量的序列提供较好的隔离性需要提供大量的队列，因此是有问题的。
+混排切片是一种更为灵活的机制，能够更好地将低密度序列与高密度序列隔离。
+混排切片的术语采用了对一叠扑克牌进行洗牌的类比，每个队列可类比成一张牌。
+混排切片技术首先对请求的特定于所在序列的特征执行哈希计算，生成一个长度
+为十几个二进制位或更长的哈希值。
+接下来，用该哈希值作为信息熵的来源，对一叠牌来混排，并对整个一手牌（队列）来洗牌。
+最后，对所有处理过的队列进行检查，选择长度最短的已检查队列作为请求的目标队列。
+在队列数量适中的时候，检查所有已处理的牌的计算量并不大，对于任一给定的
+低密度的请求序列而言，有相当的概率能够消除给定高密度序列的湮没效应。
+当队列数量较大时，检查所有已处理队列的操作会比较耗时，低密度请求序列
+消除一组高密度请求序列的湮没效应的机会也随之降低。因此，选择队列数目
+时要颇为谨慎。
+
diff --git a/content/zh/docs/reference/issues-security/_index.md b/content/zh/docs/reference/issues-security/_index.md
index fb724fc2a2..7d3da26e97 100644
--- a/content/zh/docs/reference/issues-security/_index.md
+++ b/content/zh/docs/reference/issues-security/_index.md
@@ -1,5 +1,4 @@
 ---
 title: Kubernetes 问题和安全
 weight: 10
-toc-hide: true
 ---
diff --git a/content/zh/docs/reference/kubectl/cheatsheet.md b/content/zh/docs/reference/kubectl/cheatsheet.md
index 0ede5fb604..1c351a7eab 100644
--- a/content/zh/docs/reference/kubectl/cheatsheet.md
+++ b/content/zh/docs/reference/kubectl/cheatsheet.md
@@ -24,7 +24,7 @@ See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Gu
 
 This page is an overview of the `kubectl` command.
 -->
-另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
+另见: [Kubectl 概述](/zh/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/zh/docs/reference/kubectl/jsonpath)。
 
 本页面是 `kubectl` 命令的概述。
 
@@ -85,15 +85,15 @@ detailed config file information.
 ##  Kubectl 上下文和配置
 
 设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看
-[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+[使用 kubeconfig 跨集群授权访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 文档获取配置文件详细信息。
 
-<!-- 
+<!--
 ``bash
 kubectl config view # Show Merged kubeconfig settings.
 
 # use multiple kubeconfig files at the same time and view merged config
-KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 
+KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
 
 kubectl config view
 
@@ -102,7 +102,7 @@ kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
 
 kubectl config view -o jsonpath='{.users[].name}'    # display the first user
 kubectl config view -o jsonpath='{.users[*].name}'   # get a list of users
-kubectl config get-contexts                          # display list of contexts 
+kubectl config get-contexts                          # display list of contexts
 kubectl config current-context			     # display the current-context
 kubectl config use-context my-cluster-name           # set the default context to my-cluster-name
 
@@ -115,7 +115,7 @@ kubectl config set-context --current --namespace=ggckad-s2
 # set a context utilizing a specific username and namespace.
 kubectl config set-context gce --user=cluster-admin --namespace=foo \
   && kubectl config use-context gce
- 
+
 kubectl config unset users.foo                       # delete user foo
 ```
 -->
@@ -402,7 +402,7 @@ kubectl diff -f ./my-manifest.yaml
 <!--
 ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
-kubectl rollout history deployment/frontend                      # Check the history of deployments including the revision 
+kubectl rollout history deployment/frontend                      # Check the history of deployments including the revision
 kubectl rollout undo deployment/frontend                         # Rollback to the previous deployment
 kubectl rollout undo deployment/frontend --to-revision=2         # Rollback to a specific revision
 kubectl rollout status -w deployment/frontend                    # Watch rolling update status of "frontend" deployment until completion
@@ -426,7 +426,7 @@ kubectl autoscale deployment foo --min=2 --max=10                # Auto scale a
 -->
 ```bash
 kubectl set image deployment/frontend www=image:v2               # 滚动更新 "frontend" Deployment 的 "www" 容器镜像
-kubectl rollout history deployment/frontend                      # 检查 Deployment 的历史记录，包括版本 
+kubectl rollout history deployment/frontend                      # 检查 Deployment 的历史记录，包括版本
 kubectl rollout undo deployment/frontend                         # 回滚到上次部署版本
 kubectl rollout undo deployment/frontend --to-revision=2         # 回滚到特定部署版本
 kubectl rollout status -w deployment/frontend                    # 监视 "frontend" Deployment 的滚动升级状态直到完成
@@ -465,13 +465,13 @@ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/
 # Disable a deployment livenessProbe using a json patch with positional arrays
 kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
 
-# Add a new element to a positional array 
+# Add a new element to a positional array
 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
 ```
 -->
 ```bash
 # 部分更新某节点
-kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' 
+kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
 
 # 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。
 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
@@ -482,7 +482,7 @@ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/
 # 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe
 kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
 
-# 在带位置数组中添加元素 
+# 在带位置数组中添加元素
 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
 ```
 
@@ -567,7 +567,7 @@ kubectl logs -f my-pod                              # stream pod logs (stdout)
 kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case)
 kubectl logs -f -l name=myLabel --all-containers    # stream all pods logs with label name=myLabel (stdout)
 kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell
-kubectl run nginx --image=nginx -n 
+kubectl run nginx --image=nginx -n
 mynamespace                                         # Run pod nginx in a specific namespace
 kubectl run nginx --image=nginx                     # Run pod nginx and write its spec into a file called pod.yaml
 --dry-run=client -o yaml > pod.yaml
@@ -641,7 +641,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
 <!--
 List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
 -->
-列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
+列出所支持的全部资源类型和它们的简称、[API 组](/zh/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/zh/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。
 
 ```bash
 kubectl api-resources
@@ -697,8 +697,8 @@ utput format | Description
 `-o=custom-columns=<spec>` | 使用逗号分隔的自定义列来打印表格
 `-o=custom-columns-file=<filename>` | 使用 `<filename>` 文件中的自定义列模板打印表格
 `-o=json`     | 输出 JSON 格式的 API 对象
-`-o=jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式中定义的字段
-`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式所指定的字段。
+`-o=jsonpath=<template>` | 打印 [jsonpath](/zh/docs/reference/kubectl/jsonpath) 表达式中定义的字段
+`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/zh/docs/reference/kubectl/jsonpath) 表达式所指定的字段。
 `-o=name`     | 仅打印资源名称而不打印其他内容
 `-o=wide`     | 以纯文本格式输出额外信息，对于 Pod 来说，输出中包含了节点名称
 `-o=yaml`     | 输出 YAML 格式的 API 对象
@@ -732,7 +732,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
 kubectl get pods -A -o=custom-columns='DATA:metadata.*'
 ```
 
-有关更多示例，请参看 kubectl [参考文档](/docs/reference/kubectl/overview/#custom-columns)。
+有关更多示例，请参看 kubectl [参考文档](/zh/docs/reference/kubectl/overview/#custom-columns)。
 
 <!--
 ### Kubectl output verbosity and debugging
@@ -778,8 +778,7 @@ Verbosity | Description
 * Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
 * See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
 -->
-* 进一步了解 [kubectl 概述](/docs/reference/kubectl/overview/)。
-* 参阅 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
-* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。
+* 进一步了解 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。
+* 参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 选项.
+* 参阅 [kubectl 使用约定](/zh/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。
 * 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
-
diff --git a/content/zh/docs/reference/kubectl/conventions.md b/content/zh/docs/reference/kubectl/conventions.md
index 2667f9f6e3..6313e27451 100644
--- a/content/zh/docs/reference/kubectl/conventions.md
+++ b/content/zh/docs/reference/kubectl/conventions.md
@@ -65,7 +65,7 @@ For `kubectl run` to satisfy infrastructure as code:
 * Switch to configuration files checked into source control for features that are needed, but not expressible via `kubectl run` flags.
 -->
 
-* 使用特定版本的标签标记镜像，不要将该标签移动到新版本。例如，使用 `:v1234`、`v1.2.3`、`r03062016-1-4`，而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/docs/concepts/configuration/overview/#container-images))。
+* 使用特定版本的标签标记镜像，不要将该标签移动到新版本。例如，使用 `:v1234`、`v1.2.3`、`r03062016-1-4`，而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/zh/docs/concepts/configuration/overview/#container-images))。
 * 固定到特定的[生成器](#生成器)版本，例如 `kubectl run --generator=run-pod/v1`。
 * 使用基于版本控制的脚本来记录所使用的参数，或者至少使用 `--record` 参数以便为所创建的对象添加注解，在使用轻度参数化的镜像时，记录下所使用的命令行。
 * 使用基于版本控制的脚本来运行包含大量参数的镜像。
@@ -107,9 +107,8 @@ You can create the following resources using `kubectl run` with the `--generator
 {{< /table >}}
 
 {{< note >}}
-<!--
-Generators other than `run-pod/v1` are deprecated.
- -->不推荐使用 `run-pod/v1` 以外的其他生成器。
+<!--Generators other than `run-pod/v1` are deprecated.-->
+不推荐使用 `run-pod/v1` 以外的其他生成器.
 {{< /note >}}
 
 <!--
@@ -156,5 +155,3 @@ You can use the `--dry-run` flag to preview the object that would be sent to you
 -->
 
 * 您可以使用 `kubectl apply` 命令创建或更新资源。有关使用 kubectl apply 更新资源的详细信息，请参阅 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。
-
-
diff --git a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md
index c6b4d1a38d..a89f43c32c 100644
--- a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md
+++ b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md
@@ -5,19 +5,19 @@ reviewers:
 - brendandburns
 - thockin
 ---
-<!-- 
+<!--
 ---
 title: kubectl for Docker Users
 content_type: concept
 reviewers:
 - brendandburns
 - thockin
---- 
+---
 -->
 
 <!-- overview -->
-<!-- 
-You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command. 
+<!--
+You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command.
 -->
 您可以使用 Kubernetes 命令行工具 kubectl 与 API 服务器进行交互。如果您熟悉 Docker 命令行工具，则使用 kubectl 非常简单。但是，docker 命令和 kubectl 命令之间有一些区别。以下显示了 docker 子命令，并描述了等效的 kubectl 命令。
 
@@ -48,11 +48,11 @@ CONTAINER ID        IMAGE               COMMAND                  CREATED
 
 kubectl:
 
-<!-- 
+<!--
 ```shell
 # start the pod running nginx
 kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
-``` 
+```
 -->
 ```shell
 # 启动运行 nginx 的 Pod
@@ -77,11 +77,11 @@ deployment.apps/nginx-app env updated
 `kubectl` 命令打印创建或突变资源的类型和名称，然后可以在后续命令中使用。部署后，您可以公开新服务。
 {{< /note >}}
 
-<!-- 
+<!--
 ```shell
 # expose a port through with a service
 kubectl expose deployment nginx-app --port=80 --name=nginx-http
-``` 
+```
 -->
 ```shell
 # 通过服务公开端口
@@ -91,10 +91,10 @@ kubectl expose deployment nginx-app --port=80 --name=nginx-http
 service "nginx-http" exposed
 ```
 
-<!-- 
-By using kubectl, you can create a [Deployment](/docs/concepts/workloads/controllers/deployment/) to ensure that N pods are running nginx, where N is the number of replicas stated in the spec and defaults to 1. You can also create a [service](/docs/concepts/services-networking/service/) with a selector that matches the pod labels. For more information, see [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster). 
+<!--
+By using kubectl, you can create a [Deployment](/docs/concepts/workloads/controllers/deployment/) to ensure that N pods are running nginx, where N is the number of replicas stated in the spec and defaults to 1. You can also create a [service](/docs/concepts/services-networking/service/) with a selector that matches the pod labels. For more information, see [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster).
 -->
-在 kubectl 命令中，我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数，默认为 1)。我们还创建了一个 [service](/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。查看[使用服务访问群集中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。
+在 kubectl 命令中，我们创建了一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数，默认为 1)。我们还创建了一个 [service](/zh/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。查看[使用服务访问群集中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。
 
 <!--
 By default images run in the background, similar to `docker run -d ...`. To run things in the foreground, use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to create pod:
@@ -105,27 +105,27 @@ By default images run in the background, similar to `docker run -d ...`. To run
 kubectl run [-i] [--tty] --attach <name> --image=<image>
 ```
 
-<!-- 
+<!--
 Unlike `docker run ...`, if you specify `--attach`, then you attach `stdin`, `stdout` and `stderr`. You cannot control which streams are attached (`docker -a ...`).
-To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q. 
+To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q.
 -->
 与 `docker run ...` 不同的是，如果指定了 `--attach` ，我们将连接到 `stdin`，`stdout` 和 `stderr`，而不能控制具体连接到哪个输出流（`docker -a ...`）。要从容器中退出，可以输入 Ctrl + P，然后按 Ctrl + Q。
 
-<!-- 
+<!--
 Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`.
-To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`. 
+To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`.
 -->
 因为我们使用 Deployment 启动了容器，如果您终止连接到的进程（例如 `ctrl-c`），容器将会重启，这跟 `docker run -it` 不同。
 如果想销毁该 Deployment（和它的 pod），您需要运行 `kubectl delete deployment <name>`。
 
 ## docker ps
 
-<!-- 
-To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get). 
+<!--
+To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get).
 -->
 如何列出哪些正在运行？查看 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)。
 
-<!-- 
+<!--
 docker:
  -->
 使用 docker 命令：
@@ -139,8 +139,8 @@ CONTAINER ID        IMAGE               COMMAND                  CREATED
 55c103fa1296        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute          0.0.0.0:80->80/tcp   nginx-app
 ```
 
-<!-- 
-kubectl: 
+<!--
+kubectl:
 -->
 使用 kubectl 命令：
 
@@ -155,13 +155,13 @@ ubuntu                      0/1       Completed   0          20s
 
 ## docker attach
 
-<!-- 
-To attach a process that is already running in a container, see [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach). 
+<!--
+To attach a process that is already running in a container, see [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach).
 -->
 如何连接到已经运行在容器中的进程？查看 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)。
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -193,20 +193,20 @@ kubectl attach -it nginx-app-5jyvm
 ...
 ```
 
-<!-- 
-To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q. 
+<!--
+To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q.
 -->
 要从容器中分离，可以输入 Ctrl + P，然后按 Ctrl + Q。
 
 ## docker exec
 
-<!-- 
-To execute a command in a container, see [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec). 
+<!--
+To execute a command in a container, see [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
 -->
 如何在容器中执行命令？查看 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)。
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -224,8 +224,8 @@ docker exec 55c103fa1296 cat /etc/hostname
 55c103fa1296
 ```
 
-<!-- 
-kubectl: 
+<!--
+kubectl:
 -->
 使用 kubectl 命令：
 
@@ -244,13 +244,13 @@ kubectl exec nginx-app-5jyvm -- cat /etc/hostname
 nginx-app-5jyvm
 ```
 
-<!-- 
-To use interactive commands. 
+<!--
+To use interactive commands.
 -->
 执行交互式命令怎么办？
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -266,21 +266,21 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
 # exit
 ```
 
-<!-- 
-For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/). 
+<!--
+For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
 -->
-更多信息请查看[获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。
+更多信息请查看[获取运行中容器的 Shell 环境](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)。
 
 ## docker logs
 
-<!-- 
-To follow stdout/stderr of a process that is running, see [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs). 
+<!--
+To follow stdout/stderr of a process that is running, see [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs).
 -->
 如何查看运行中进程的 stdout/stderr？查看 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)。
 
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -292,8 +292,8 @@ docker logs -f a9e
 192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
 ```
 
-<!-- 
-kubectl: 
+<!--
+kubectl:
 -->
 使用 kubectl 命令：
 
@@ -305,8 +305,8 @@ kubectl logs -f nginx-app-zibvs
 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
 ```
 
-<!-- 
-There is a slight difference between pods and containers; by default pods do not terminate if their processes exit. Instead the pods restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated, but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this: 
+<!--
+There is a slight difference between pods and containers; by default pods do not terminate if their processes exit. Instead the pods restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated, but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this:
 -->
 现在是时候提一下 pod 和容器之间的细微差别了；默认情况下如果 pod 中的进程退出 pod 也不会终止，相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项， 这是主要差别。在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 kubernetes，每个调用都是分开的。要查看以前在 kubernetes 中执行的输出，请执行以下操作：
 
@@ -318,20 +318,20 @@ kubectl logs --previous nginx-app-zibvs
 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
 ```
 
-<!-- 
-For more information, see [Logging Architecture](/docs/concepts/cluster-administration/logging/). 
+<!--
+For more information, see [Logging Architecture](/docs/concepts/cluster-administration/logging/).
 -->
-查看[日志架构](/docs/concepts/cluster-administration/logging/)获取更多信息。
+查看[日志架构](/zh/docs/concepts/cluster-administration/logging/)获取更多信息。
 
 ## docker stop and docker rm
 
-<!-- 
-To stop and delete a running process, see [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete). 
+<!--
+To stop and delete a running process, see [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete).
 -->
 如何停止和删除运行中的进程？查看 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)。
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -357,8 +357,8 @@ docker rm a9ec34d98787
 a9ec34d98787
 ```
 
-<!-- 
-kubectl: 
+<!--
+kubectl:
 -->
 使用 kubectl 命令：
 
@@ -390,28 +390,28 @@ kubectl get po -l run=nginx-app
 ```
 
 {{< note >}}
-<!-- 
-When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod. 
+<!--
+When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
 -->
 请注意，我们不直接删除 pod。使用 kubectl 命令，我们要删除拥有该 pod 的 Deployment。如果我们直接删除 pod，Deployment 将会重新创建该 pod。
 {{< /note >}}
 
 ## docker login
 
-<!-- 
-There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](/docs/concepts/containers/images/#using-a-private-registry). 
+<!--
+There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](/docs/concepts/containers/images/#using-a-private-registry).
 -->
-在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅[使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。
+在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅[使用私有镜像仓库](/zh/docs/concepts/containers/images/#using-a-private-registry)。
 
 ## docker version
 
-<!-- 
-To get the version of client and server, see [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version). 
+<!--
+To get the version of client and server, see [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version).
 -->
 如何查看客户端和服务端的版本？查看 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)。
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -431,8 +431,8 @@ Git commit (server): 0baf609
 OS/Arch (server): linux/amd64
 ```
 
-<!-- 
-kubectl: 
+<!--
+kubectl:
 -->
 使用 kubectl 命令：
 
@@ -446,13 +446,13 @@ Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4
 
 ## docker info
 
-<!-- 
-To get miscellaneous information about the environment and configuration, see [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info). 
+<!--
+To get miscellaneous information about the environment and configuration, see [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info).
 -->
 如何获取有关环境和配置的各种信息？查看 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)。
 
-<!-- 
-docker: 
+<!--
+docker:
 -->
 使用 docker 命令：
 
@@ -478,8 +478,8 @@ ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
 WARNING: No swap limit support
 ```
 
-<!-- 
-kubectl: 
+<!--
+kubectl:
 -->
 使用 kubectl 命令：
 
@@ -494,4 +494,3 @@ Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/servic
 Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
 ```
-
diff --git a/content/zh/docs/reference/kubectl/kubectl.md b/content/zh/docs/reference/kubectl/kubectl.md
index a40844d663..5fcf0780ef 100644
--- a/content/zh/docs/reference/kubectl/kubectl.md
+++ b/content/zh/docs/reference/kubectl/kubectl.md
@@ -24,24 +24,20 @@ kubectl 管理控制 Kubernetes 集群。
 <!--
 Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
 -->
-获取更多信息，请访问 [kubectl 概述](/docs/reference/kubectl/overview/)。
+获取更多信息，请访问 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。
 
 ```
 kubectl [flags]
 ```
 
-
-
 ## {{% heading "options" %}}
 
-
-<table style="width: 100%; table-layout: fixed;">
-  <colgroup>
-    <col span="1" style="width: 10px;" />
-    <col span="1" />
-  </colgroup>
-  <tbody>
-
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
     <tr>
       <td colspan="2">--add-dir-header</td>
     </tr>
@@ -53,7 +49,6 @@ kubectl [flags]
       设置为 true 表示添加文件目录到 header 中
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--alsologtostderr</td>
     </tr>
@@ -65,7 +60,6 @@ kubectl [flags]
       表示将日志输出到文件的同时输出到 stderr
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--as string</td>
     </tr>
@@ -77,7 +71,6 @@ kubectl [flags]
       以指定用户的身份执行操作
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--as-group stringArray</td>
     </tr>
@@ -89,7 +82,6 @@ kubectl [flags]
       模拟指定的组来执行操作，可以使用这个标志来指定多个组。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--azure-container-registry-config string</td>
     </tr>
@@ -101,7 +93,6 @@ kubectl [flags]
       包含 Azure 容器仓库配置信息的文件的路径。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "~/.kube/http-cache"</td>
     </tr>
@@ -113,7 +104,6 @@ kubectl [flags]
       默认 HTTP 缓存目录
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--certificate-authority string</td>
     </tr>
@@ -125,7 +115,6 @@ kubectl [flags]
       指向证书机构的 cert 文件路径
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--client-certificate string</td>
     </tr>
@@ -137,7 +126,6 @@ kubectl [flags]
       TLS 使用的客户端证书路径
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--client-key string</td>
     </tr>
@@ -149,7 +137,6 @@ kubectl [flags]
       TLS 使用的客户端密钥文件路径
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--cloud-provider-gce-lb-src-cidrs cidrs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16</td>
     </tr>
@@ -161,7 +148,6 @@ kubectl [flags]
       在 GCE 防火墙中打开 CIDR，以进行 LB 流量代理和运行状况检查。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--cluster string</td>
     </tr>
@@ -173,7 +159,6 @@ kubectl [flags]
       要使用的 kubeconfig 集群的名称
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--context string</td>
     </tr>
@@ -185,7 +170,6 @@ kubectl [flags]
       要使用的 kubeconfig 上下文的名称
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 300</td>
     </tr>
@@ -197,7 +181,6 @@ kubectl [flags]
       表示 `notReady` 状态的容忍度秒数：默认情况下，`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 300</td>
     </tr>
@@ -209,7 +192,6 @@ kubectl [flags]
       表示 `unreachable` 状态的容忍度秒数：默认情况下，`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">-h, --help</td>
     </tr>
@@ -221,7 +203,6 @@ kubectl [flags]
       kubectl 操作的帮助命令
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--insecure-skip-tls-verify</td>
     </tr>
@@ -233,7 +214,6 @@ kubectl [flags]
       设置为 true，则表示不会检查服务器证书的有效性。这样会导致您的 HTTPS 连接不安全。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--kubeconfig string</td>
     </tr>
@@ -245,7 +225,6 @@ kubectl [flags]
       CLI 请求使用的 kubeconfig 配置文件的路径。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--log-backtrace-at traceLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 0</td>
     </tr>
@@ -257,7 +236,6 @@ kubectl [flags]
       当日志机制运行到指定文件的指定行（file:N）时，打印调用堆栈信息
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--log-dir string</td>
     </tr>
@@ -269,7 +247,6 @@ kubectl [flags]
       如果不为空，则将日志文件写入此目录
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--log-file string</td>
     </tr>
@@ -281,7 +258,6 @@ kubectl [flags]
       如果不为空，则将使用此日志文件
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--log-file-max-size uint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 1800</td>
     </tr>
@@ -293,7 +269,6 @@ kubectl [flags]
       定义日志文件的最大尺寸。单位为兆字节。如果值设置为 0，则表示日志文件大小不受限制。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--log-flush-frequency duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 5s</td>
     </tr>
@@ -305,7 +280,6 @@ kubectl [flags]
       两次日志刷新操作之间的最长时间（秒）
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: true</td>
     </tr>
@@ -317,7 +291,6 @@ kubectl [flags]
       日志输出到 stderr 而不是文件中
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--match-server-version</td>
     </tr>
@@ -329,7 +302,6 @@ kubectl [flags]
       要求客户端版本和服务端版本相匹配
       </td>
     </tr>
-
     <tr>
       <td colspan="2">-n, --namespace string</td>
     </tr>
@@ -341,7 +313,6 @@ kubectl [flags]
       如果存在，CLI 请求将使用此命名空间
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--password string</td>
     </tr>
@@ -353,7 +324,6 @@ kubectl [flags]
       API 服务器进行基本身份验证的密码
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--profile string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "none"</td>
     </tr>
@@ -365,7 +335,6 @@ kubectl [flags]
       要记录的性能指标的名称。可取 (none|cpu|heap|goroutine|threadcreate|block|mutex) 其中之一。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--profile-output string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "profile.pprof"</td>
     </tr>
@@ -377,7 +346,6 @@ kubectl [flags]
       用于转储所记录的性能信息的文件名
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--request-timeout string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "0"</td>
     </tr>
@@ -389,7 +357,6 @@ kubectl [flags]
       放弃单个服务器请求之前的等待时间，非零值需要包含相应时间单位（例如：1s、2m、3h）。零值则表示不做超时要求。
       </td>
     </tr>
-
     <tr>
       <td colspan="2">-s, --server string</td>
     </tr>
@@ -401,7 +368,6 @@ kubectl [flags]
       Kubernetes API 服务器的地址和端口
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--skip-headers</td>
     </tr>
@@ -413,7 +379,6 @@ kubectl [flags]
       设置为 true 则表示跳过在日志消息中出现 header 前缀信息
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--skip-log-headers</td>
     </tr>
@@ -425,7 +390,6 @@ kubectl [flags]
       设置为 true 则表示在打开日志文件时跳过 header 信息
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--stderrthreshold severity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: 2</td>
     </tr>
@@ -437,7 +401,6 @@ kubectl [flags]
       等于或高于此阈值的日志将输出到标准错误输出（stderr）
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--token string</td>
     </tr>
@@ -449,7 +412,6 @@ kubectl [flags]
       用于对 API 服务器进行身份认证的持有者令牌
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--user string</td>
     </tr>
@@ -461,7 +423,6 @@ kubectl [flags]
       指定使用 kubeconfig 配置文件中的用户名
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--username string</td>
     </tr>
@@ -473,7 +434,6 @@ kubectl [flags]
       用于 API 服务器的基本身份验证的用户名
       </td>
     </tr>
-
     <tr>
       <td colspan="2">-v, --v Level</td>
     </tr>
@@ -485,7 +445,6 @@ kubectl [flags]
       指定输出日志的日志详细级别
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--version version[=true]</td>
     </tr>
@@ -497,7 +456,6 @@ kubectl [flags]
       打印 kubectl 版本信息并退出
       </td>
     </tr>
-
     <tr>
       <td colspan="2">--vmodule moduleSpec</td>
     </tr>
@@ -509,7 +467,6 @@ kubectl [flags]
       以逗号分隔的 pattern=N 设置列表，用于过滤文件的日志记录
       </td>
     </tr>
-
   </tbody>
 </table>
 
@@ -624,6 +581,3 @@ kubectl [flags]
 * [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon)	 - 标记节点为可调度的
 * [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version)	 - 打印客户端和服务器的版本信息
 * [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait)	 - 实验性：等待一个或多个资源达到某种状态
-
-
-
diff --git a/content/zh/docs/reference/kubectl/overview.md b/content/zh/docs/reference/kubectl/overview.md
index b06c66f95a..834175c5d8 100644
--- a/content/zh/docs/reference/kubectl/overview.md
+++ b/content/zh/docs/reference/kubectl/overview.md
@@ -27,12 +27,12 @@ card:
 <!--
 Kubectl is a command line interface for running commands against Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
 -->
-Kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。`kubectl` 在 $HOME/.kube 目录中寻找一个名为 config 的文件。您可以通过设置环境变量 KUBECONFIG 或设置 [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数指定其它 [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。
+Kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。`kubectl` 在 $HOME/.kube 目录中寻找一个名为 config 的文件。您可以通过设置环境变量 KUBECONFIG 或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。
 
 <!--
 This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
 -->
-本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。有关每个命令的详细信息，包括所有受支持的参数和子命令，请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。有关安装说明，请参见 [安装 kubectl](/docs/tasks/kubectl/install/) 。
+本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。有关每个命令的详细信息，包括所有受支持的参数和子命令，请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。有关安装说明，请参见 [安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 。
 
 
 
@@ -79,22 +79,22 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
 
    When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files:
 -->
- 
-* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。 
 
-  在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件： 
+* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
+
+  在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件：
 
 <!--
    * To specify resources by type and name:
-   
+
       * To group resources if they are all the same type:  `TYPE1 name1 name2 name<#>`.<br/>
       Example: `kubectl get pod example-pod1 example-pod2`
-        
+
       * To specify multiple resource types individually:  `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
       Example: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
-        
+
    * To specify resources with one or more files:  `-f file1 -f file2 -f file<#>`
-   
+
       * [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-config-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
      Example: `kubectl get pod -f ./pod.yaml`
 
@@ -102,17 +102,17 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
 -->
 
    * 要按类型和名称指定资源：
-   
+
       * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。<br/>
       例子：`kubectl get pod example-pod1 example-pod2`
-        
+
       * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。<br/>
       例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1`
-        
+
    * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>`
-   
-      * [使用 YAML 而不是 JSON](/docs/concepts/configuration/overview/#general-config-tips) 因为 YAML 更容易使用，特别是用于配置文件时。<br/>
-     例子：`kubectl get pod -f ./pod.yaml`
+
+      * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-config-tips) 因为 YAML 更容易使用，特别是用于配置文件时。<br/>
+     例子：`kubectl get -f ./pod.yaml`
 
 * `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 Kubernetes API 服务器的地址和端口。<br/>
 
@@ -206,7 +206,7 @@ Operation       | Syntax    |       Description
 <!--
 Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
 -->
-记住：有关命令操作的更多信息，请参阅 [kubectl](/docs/user-guide/kubectl/) 参考文档。
+记住：有关命令操作的更多信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。
 
 <!--
 ## Resource types
@@ -220,16 +220,18 @@ The following table includes a list of all the supported resource types and thei
 下表列出所有受支持的资源类型及其缩写别名:
 
 <!--
-(This output can be retrieved from `kubectl api-resources`, and is accurate as of Kubernetes 1.13.3.)
+(This output can be retrieved from `kubectl api-resources`, and is accurate as of Kubernetes 1.19.1.)
 -->
-(以下输出可以通过 `kubectl api-resources` 获取，内容以 Kubernetes 1.13.3 版本为准。)
+(以下输出可以通过 `kubectl api-resources` 获取，内容以 Kubernetes 1.19.1 版本为准。)
 
 <!--
-| Resource Name | Short Names | API Group | Namespaced | Resource Kind |
+| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
 |---|---|---|---|---|
+| `bindings` | | | true | Binding |
 | `componentstatuses` | `cs` | | false | ComponentStatus |
 | `configmaps` | `cm` | | true | ConfigMap |
 | `endpoints` | `ep` | | true | Endpoints |
+| `events` | `ev` | | true | Event |
 | `limitranges` | `limits` | | true | LimitRange |
 | `namespaces` | `ns` | | false | Namespace |
 | `nodes` | `no` | | false | Node |
@@ -237,14 +239,14 @@ The following table includes a list of all the supported resource types and thei
 | `persistentvolumes` | `pv` | | false | PersistentVolume |
 | `pods` | `po` | | true | Pod |
 | `podtemplates` | | | true | PodTemplate |
-| `replicationcontrollers` | `rc` | | true| ReplicationController |
+| `replicationcontrollers` | `rc` | | true | ReplicationController |
 | `resourcequotas` | `quota` | | true | ResourceQuota |
 | `secrets` | | | true | Secret |
 | `serviceaccounts` | `sa` | | true | ServiceAccount |
 | `services` | `svc` | | true | Service |
 | `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
 | `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
-| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
+| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
 | `apiservices` | | apiregistration.k8s.io | false | APIService |
 | `controllerrevisions` | | apps | true | ControllerRevision |
 | `daemonsets` | `ds` | apps | true | DaemonSet |
@@ -261,9 +263,15 @@ The following table includes a list of all the supported resource types and thei
 | `jobs` | | batch | true | Job |
 | `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
 | `leases` | | coordination.k8s.io | true | Lease |
+| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
 | `events` | `ev` | events.k8s.io | true | Event |
 | `ingresses` | `ing` | extensions | true | Ingress |
+| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
+| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
+| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
+| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
 | `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
+| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
 | `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
 | `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
 | `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
@@ -271,14 +279,18 @@ The following table includes a list of all the supported resource types and thei
 | `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
 | `roles` | | rbac.authorization.k8s.io | true | Role |
 | `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
-| `storageclasses` | `sc` | storage.k8s.io |  false | StorageClass |
+| `csidrivers` | | storage.k8s.io | false | CSIDriver |
+| `csinodes` | | storage.k8s.io | false | CSINode |
+| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
 | `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
 -->
 | 资源名 | 缩写名 | API 分组 | 按命名空间 | 资源类型 |
 |---|---|---|---|---|
+| `bindings` | | | true | Binding |
 | `componentstatuses` | `cs` | | false | ComponentStatus |
 | `configmaps` | `cm` | | true | ConfigMap |
 | `endpoints` | `ep` | | true | Endpoints |
+| `events` | `ev` | | true | Event |
 | `limitranges` | `limits` | | true | LimitRange |
 | `namespaces` | `ns` | | false | Namespace |
 | `nodes` | `no` | | false | Node |
@@ -286,14 +298,14 @@ The following table includes a list of all the supported resource types and thei
 | `persistentvolumes` | `pv` | | false | PersistentVolume |
 | `pods` | `po` | | true | Pod |
 | `podtemplates` | | | true | PodTemplate |
-| `replicationcontrollers` | `rc` | | true| ReplicationController |
+| `replicationcontrollers` | `rc` | | true | ReplicationController |
 | `resourcequotas` | `quota` | | true | ResourceQuota |
 | `secrets` | | | true | Secret |
 | `serviceaccounts` | `sa` | | true | ServiceAccount |
 | `services` | `svc` | | true | Service |
 | `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
 | `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
-| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
+| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
 | `apiservices` | | apiregistration.k8s.io | false | APIService |
 | `controllerrevisions` | | apps | true | ControllerRevision |
 | `daemonsets` | `ds` | apps | true | DaemonSet |
@@ -310,9 +322,15 @@ The following table includes a list of all the supported resource types and thei
 | `jobs` | | batch | true | Job |
 | `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
 | `leases` | | coordination.k8s.io | true | Lease |
+| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
 | `events` | `ev` | events.k8s.io | true | Event |
 | `ingresses` | `ing` | extensions | true | Ingress |
+| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
+| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
+| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
+| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
 | `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
+| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
 | `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
 | `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
 | `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
@@ -320,7 +338,9 @@ The following table includes a list of all the supported resource types and thei
 | `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
 | `roles` | | rbac.authorization.k8s.io | true | Role |
 | `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
-| `storageclasses` | `sc` | storage.k8s.io |  false | StorageClass |
+| `csidrivers` | | storage.k8s.io | false | CSIDriver |
+| `csinodes` | | storage.k8s.io | false | CSINode |
+| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
 | `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
 
 
@@ -333,7 +353,7 @@ The following table includes a list of all the supported resource types and thei
 <!--
 Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
 -->
-有关如何格式化或排序某些命令的输出的信息，请使用以下部分。有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/docs/user-guide/kubectl/) 参考文档。
+有关如何格式化或排序某些命令的输出的信息，请使用以下部分。有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。
 
 <!--
 ### Formatting output
@@ -376,8 +396,8 @@ Output format | Description
 `-o custom-columns=<spec>` | 使用逗号分隔的[自定义列](#custom-columns)列表打印表。
 `-o custom-columns-file=<filename>` | 使用 `<filename>` 文件中的[自定义列](#custom-columns)模板打印表。
 `-o json`     | 输出 JSON 格式的 API 对象
-`-o jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath/) 表达式定义的字段
-`-o jsonpath-file=<filename>` | 打印 `<filename>` 文件中 [jsonpath](/docs/reference/kubectl/jsonpath/) 表达式定义的字段。
+`-o jsonpath=<template>` | 打印 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式定义的字段
+`-o jsonpath-file=<filename>` | 打印 `<filename>` 文件中 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式定义的字段。
 `-o name`     | 仅打印资源名称而不打印任何其他内容。
 `-o wide`     | 以纯文本格式输出，包含任何附加信息。对于 pod 包含节点名。
 `-o yaml`     | 输出 YAML 格式的 API 对象。
@@ -401,7 +421,7 @@ kubectl get pod web-pod-13je7 -o yaml
 <!--
 Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation for details about which output format is supported by each command.
 -->
-请记住：有关每个命令支持哪种输出格式的详细信息，请参阅 [kubectl](/docs/user-guide/kubectl/) 参考文档。
+请记住：有关每个命令支持哪种输出格式的详细信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。
 
 <!--
 #### Custom columns
@@ -508,7 +528,7 @@ pod-name   1/1       Running             0          1m
 <!--
 To output objects to a sorted list in your terminal window, you can add the `--sort-by` flag to a supported `kubectl` command. Sort your objects by specifying any numeric or string field with the `--sort-by` flag. To specify a field, use a [jsonpath](/docs/reference/kubectl/jsonpath/) expression.
 -->
-要将对象排序后输出到终端窗口，可以将 `--sort-by` 参数添加到支持的 `kubectl` 命令。通过使用 `--sort-by` 参数指定任何数字或字符串字段来对对象进行排序。要指定字段，请使用 [jsonpath](/docs/reference/kubectl/jsonpath/) 表达式。
+要将对象排序后输出到终端窗口，可以将 `--sort-by` 参数添加到支持的 `kubectl` 命令。通过使用 `--sort-by` 参数指定任何数字或字符串字段来对对象进行排序。要指定字段，请使用 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式。
 
 <!--
 #### Syntax
@@ -694,7 +714,7 @@ kubectl delete pods --all
 ```shell
 # 从 pod <pod-name> 中获取运行 'date' 的输出。默认情况下，输出来自第一个容器。
 kubectl exec <pod-name> date
-  
+
 # 运行输出 'date' 获取在容器的 <container-name> 中 pod <pod-name> 的输出。
 kubectl exec <pod-name> -c <container-name> date
 
@@ -918,5 +938,3 @@ To find out more about plugins, take a look at the [example cli plugin](https://
 Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
 -->
 开始使用 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 命令。
-
-
diff --git a/content/zh/docs/reference/kubernetes-api/api-index.md b/content/zh/docs/reference/kubernetes-api/api-index.md
index 674e5ece7e..140233e659 100644
--- a/content/zh/docs/reference/kubernetes-api/api-index.md
+++ b/content/zh/docs/reference/kubernetes-api/api-index.md
@@ -1,6 +1,6 @@
 ---
-title: v1.17
+title: v1.19
 weight: 50
 ---
 
-[Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
\ No newline at end of file
+[Kubernetes API v1.19](/docs/reference/generated/kubernetes-api/v1.19/)
\ No newline at end of file
diff --git a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md
index e271e1885e..5a32824da0 100644
--- a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md
+++ b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md
@@ -1,5 +1,5 @@
 ---
-title: 知名标签（Label）、注解（Annotation）和 Taints
+title: 知名标签（Label）、注解（Annotation）和 污点（Taint）
 content_type: concept
 weight: 60
 ---
@@ -227,9 +227,9 @@ on the nodes if it makes sense in your topology.
 -->
 示例：
 
-`failure-domain.beta.kubernetes.io/region=us-east-1`
+`topology.kubernetes.io/region=us-east-1`
 
-`failure-domain.beta.kubernetes.io/zone=us-east-1c`
+`topology.kubernetes.io/zone=us-east-1c`
 
 用于：Node、PersistentVolume
 
@@ -271,5 +271,3 @@ adding the labels manually (or adding support for `PersistentVolumeLabel`). With
 -->
 如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod 跨区域进行卷的挂载，
 应考虑手动打标签 (或对 `PersistentVolumeLabel` 增加支持）。如果用户的基础设施没有这种约束，则不需要为卷添加区域标签。
-
-
diff --git a/content/zh/docs/reference/scheduling/_index.md b/content/zh/docs/reference/scheduling/_index.md
new file mode 100644
index 0000000000..438ac7ede3
--- /dev/null
+++ b/content/zh/docs/reference/scheduling/_index.md
@@ -0,0 +1,5 @@
+---
+title: 调度
+weight: 70
+toc-hide: true
+---
diff --git a/content/zh/docs/reference/scheduling/config.md b/content/zh/docs/reference/scheduling/config.md
new file mode 100644
index 0000000000..5fa8497097
--- /dev/null
+++ b/content/zh/docs/reference/scheduling/config.md
@@ -0,0 +1,509 @@
+---
+title: 调度器配置
+content_type: concept
+weight: 20
+---
+<!-- 
+title: Scheduler Configuration
+content_type: concept
+weight: 20
+-->
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+<!-- 
+You can customize the behavior of the `kube-scheduler` by writing a configuration
+file and passing its path as a command line argument. 
+-->
+你可以通过编写配置文件，并将其路径传给 `kube-scheduler` 的命令行参数，定制 `kube-scheduler` 的行为。
+
+<!-- overview -->
+
+<!-- body -->
+
+<!--  
+You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
+using the component config APIs
+([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
+or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)).
+The `v1alpha2` API allows you to configure kube-scheduler to run
+[multiple profiles](#multiple-profiles).
+-->
+你可以通过运行 `kube-scheduler --config <filename>` 来设置调度配置，
+配置文件使用组件配置的 API ([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
+或 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))。
+`v1alpha2` 可以配置 kube-scheduler 运行[多个配置文件](#multiple-profiles)。
+
+<!-- A minimal configuration looks as follows: -->
+最简单的配置如下：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+clientConnection:
+  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
+```
+
+<!-- ## Profiles -->
+## 配置文件    {#profiles}
+
+<!--  
+A scheduling Profile allows you to configure the different stages of scheduling
+in the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}.
+Each stage is exposed in an [extension point](#extension-points).
+[Plugins](#scheduling-plugins) provide scheduling behaviors by implementing one
+or more of these extension points.
+-->
+通过调度配置文件，你可以配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} 在不同阶段的调度行为。
+每个阶段都在一个[扩展点](#extension-points)中公开。
+[调度插件](#scheduling-plugins)通过实现一个或多个扩展点，来提供调度行为。
+
+<!--  
+You can configure a single instance of `kube-scheduler` to run
+[multiple profiles](#multiple-profiles).
+-->
+你可以配置同一 `kube-scheduler` 实例使用[多个配置文件](#multiple-profiles)。
+
+<!-- ### Extension points -->
+### 扩展点    {#extensions-points}
+
+<!--  
+Scheduling happens in a series of stages that are exposed through the following
+extension points:
+-->
+调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的：
+
+<!--  
+1. `QueueSort`: These plugins provide an ordering function that is used to
+   sort pending Pods in the scheduling queue. Exactly one queue sort plugin
+   may be enabled at a time.
+-->
+1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。
+   一次只能启用一个队列排序插件。
+<!-- 
+2. `PreFilter`: These plugins are used to pre-process or check information
+   about a Pod or the cluster before filtering. They can mark a pod as
+   unschedulable.
+ -->
+2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
+   它们可以将 Pod 标记为不可调度。
+<!-- 
+3. `Filter`: These plugins are the equivalent of Predicates in a scheduling
+   Policy and are used to filter out nodes that can not run the Pod. Filters
+   are called in the configured order. A pod is marked as unschedulable if no
+   nodes pass all the filters.
+-->
+3. `Filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。
+   过滤器的调用顺序是可配置的。
+   如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。
+<!-- 
+4. `PreScore`: This is an informational extension point that can be used
+   for doing pre-scoring work.
+-->
+4. `PreScore`：这是一个信息扩展点，可用于预打分工作。
+<!--  
+5. `Score`: These plugins provide a score to each node that has passed the
+   filtering phase. The scheduler will then select the node with the highest
+   weighted scores sum.
+-->
+5. `Score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
+<!--  
+6. `Reserve`: This is an informational extension point that notifies plugins
+   when resources have been reserved for a given Pod. Plugins also implement an
+   `Unreserve` call that gets called in the case of failure during or after
+   `Reserve`.
+-->
+6. `Reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。
+   这些插件还实现了 `Unreserve` 接口，在 `Reserve` 期间或之后出现故障时调用。
+<!-- 7. `Permit`: These plugins can prevent or delay the binding of a Pod. -->
+7. `Permit`：这些插件可以阻止或延迟 Pod 绑定。
+<!-- 8. `PreBind`: These plugins perform any work required before a Pod is bound.-->
+8. `PreBind`：这些插件在 Pod 绑定节点之前执行。
+<!--  
+9. `Bind`: The plugins bind a Pod to a Node. Bind plugins are called in order
+   and once one has done the binding, the remaining plugins are skipped. At
+   least one bind plugin is required.
+-->
+9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
+<!-- 
+10. `PostBind`: This is an informational extension point that is called after
+   a Pod has been bound.
+-->
+10.  `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。
+
+<!-- 
+For each extension point, you could disable specific [default plugins](#scheduling-plugins)
+or enable your own. For example:
+-->
+对每个扩展点，你可以禁用[默认插件](#scheduling-plugins)或者是启用自己的插件，例如：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+profiles:
+  - plugins:
+      score:
+        disabled:
+        - name: NodeResourcesLeastAllocated
+        enabled:
+        - name: MyCustomPluginA
+          weight: 2
+        - name: MyCustomPluginB
+          weight: 1
+```
+
+<!-- 
+You can use `*` as name in the disabled array to disable all default plugins
+for that extension point. This can also be used to rearrange plugins order, if
+desired.
+-->
+你可以在 `disabled` 数组中使用 `*` 禁用该扩展点的所有默认插件。
+如果需要，这个字段也可以用来对插件重新顺序。
+   
+<!-- ### Scheduling plugins -->
+### 调度插件    {#scheduling-plugin}
+
+<!-- 
+1. `UnReserve`: This is an informational extension point that is called if
+   a Pod is rejected after being reserved and put on hold by a `Permit` plugin.
+-->
+1. `UnReserve`：这是一个信息扩展点，如果一个 Pod 在预留后被拒绝，并且被 `Permit` 插件搁置，它就会被调用。
+
+<!-- ## Scheduling plugins -->
+## 调度插件   {#scheduling-plugins}
+
+<!--  
+The following plugins, enabled by default, implement one or more of these
+extension points:
+-->
+下面默认启用的插件实现了一个或多个扩展点：
+
+<!--  
+- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
+  {{< glossary_tooltip text="Services" term_id="service" >}},
+  {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
+  {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}
+  Extension points: `PreScore`, `Score`.
+-->
+- `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、
+  {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和
+  {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。
+  
+  实现的扩展点：`PreScore`，`Score`。
+<!--  
+- `ImageLocality`: Favors nodes that already have the container images that the
+  Pod runs.
+  Extension points: `Score`.
+-->
+- `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。
+  
+  实现的扩展点：`Score`。
+<!--  
+- `TaintToleration`: Implements
+  [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
+  Implements extension points: `Filter`, `Prescore`, `Score`.
+-->
+- `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+  
+  实现的扩展点：`Filter`，`Prescore`，`Score`。
+<!--  
+- `NodeName`: Checks if a Pod spec node name matches the current node.
+  Extension points: `Filter`.
+-->
+- `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `NodePorts`: Checks if a node has free ports for the requested Pod ports.
+  Extension points: `PreFilter`, `Filter`.
+-->
+- `NodePorts`：检查 Pod 请求的端口在节点上是否可用。
+  
+  实现的扩展点：`PreFilter`，`Filter`。
+<!--  
+- `NodePreferAvoidPods`: Scores nodes according to the node
+  {{< glossary_tooltip text=" " term_id="annotation" >}}
+  `scheduler.alpha.kubernetes.io/preferAvoidPods`.
+  Extension points: `Score`.
+-->
+- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} 
+  `scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。
+  
+  实现的扩展点：`Score`。
+<!--  
+- `NodeAffinity`: Implements
+  [node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
+  and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
+  Extension points: `Filter`, `Score`.
+-->
+- `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
+  和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。
+  
+  实现的扩展点：`Filter`，`Score`.
+<!--  
+- `PodTopologySpread`: Implements
+  [Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+  Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
+-->
+- `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
+  
+  实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
+<!--  
+- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
+  true.
+  Extension points: `Filter`.
+-->
+- `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is
+  requesting.
+  Extension points: `PreFilter`, `Filter`.
+-->
+- `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。
+  
+  实现的扩展点：`PreFilter`，`Filter`。
+<!--  
+- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more
+  balanced resource usage if the Pod is scheduled there.
+  Extension points: `Score`.
+-->
+- `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。
+  
+  实现的扩展点：`Score`。
+<!--  
+- `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of
+  resources.
+  Extension points: `Score`.
+-->
+- `NodeResourcesLeastAllocated`：选择资源分配较少的节点。
+  
+  实现的扩展点：`Score`。
+<!--  
+- `VolumeBinding`: Checks if the node has or if it can bind the requested
+  {{< glossary_tooltip text="volumes" term_id="volume" >}}.
+  Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`.
+-->
+- `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。
+  
+  实现的扩展点: `PreFilter`，`Filter`，`Reserve`，`PreBind`。
+<!-- 
+- `VolumeRestrictions`: Checks that volumes mounted in the node satisfy
+  restrictions that are specific to the volume provider.
+  Extension points: `Filter`. 
+-->
+- `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `VolumeZone`: Checks that volumes requested satisfy any zone requirements they
+  might have.
+  Extension points: `Filter`.
+-->
+- `VolumeZone`：检查请求的卷是否在任何区域都满足。
+  
+  实现的扩展点：`Filter`。
+<!-- 
+- `NodeVolumeLimits`: Checks that CSI volume limits can be satisfied for the
+  node.
+  Extension points: `Filter`. 
+-->
+- `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `EBSLimits`: Checks that AWS EBS volume limits can be satisfied for the node.
+  Extension points: `Filter`.
+-->
+- `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `GCEPDLimits`: Checks that GCP-PD volume limits can be satisfied for the node.
+  Extension points: `Filter`.
+-->
+- `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `AzureDiskLimits`: Checks that Azure disk volume limits can be satisfied for
+  the node.
+  Extension points: `Filter`.
+-->
+- `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `InterPodAffinity`: Implements
+  [inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity).
+  Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
+-->
+- `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。
+  
+  实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
+<!--  
+- `PrioritySort`: Provides the default priority based sorting.
+  Extension points: `QueueSort`.
+-->
+- `PrioritySort`：提供默认的基于优先级的排序。
+  
+  实现的扩展点：`QueueSort`。
+<!--  
+- `DefaultBinder`: Provides the default binding mechanism.
+  Extension points: `Bind`.
+-->
+- `DefaultBinder`：提供默认的绑定机制。
+  
+  实现的扩展点：`Bind`。
+<!--  
+- `DefaultPreemption`: Provides the default preemption mechanism.
+  Extension points: `PostFilter`.
+-->
+- `DefaultPreemption`：提供默认的抢占机制。
+  
+  实现的扩展点：`PostFilter`。
+
+<!--  
+You can also enable the following plugins, through the component config APIs,
+that are not enabled by default:
+-->
+你也可以通过组件配置 API 启用以下插件（默认不启用）:
+
+<!--  
+- `NodeResourcesMostAllocated`: Favors nodes that have a high allocation of
+  resources.
+  Extension points: `Score`.
+-->
+- `NodeResourcesMostAllocated`：选择已分配资源多的节点。
+  
+  实现的扩展点：`Score`。
+<!--  
+- `RequestedToCapacityRatio`: Favor nodes according to a configured function of
+  the allocated resources.
+  Extension points: `Score`.
+-->
+- `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。
+  
+  实现的扩展点：`Score`。
+<!--  
+- `NodeResourceLimits`: Favors nodes that satisfy the Pod resource limits.
+  Extension points: `PreScore`, `Score`.
+-->
+- `NodeResourceLimits`：选择满足 Pod 资源限制的节点。
+  
+  实现的扩展点：`PreScore`，`Score`。
+<!--  
+- `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied
+  for the node.
+  Extension points: `Filter`.
+-->
+- `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。
+  
+  实现的扩展点：`Filter`。
+<!--  
+- `NodeLabel`: Filters and / or scores a node according to configured
+  {{< glossary_tooltip text="label(s)" term_id="label" >}}.
+  Extension points: `Filter`, `Score`.
+-->
+- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} 
+  过滤节点和/或给节点打分。
+  
+  实现的扩展点：`Filter`，`Score`。
+<!--  
+- `ServiceAffinity`: Checks that Pods that belong to a
+  {{< glossary_tooltip term_id="service" >}} fit in a set of nodes defined by
+  configured labels. This plugin also favors spreading the Pods belonging to a
+  Service across nodes.
+  Extension points: `PreFilter`, `Filter`, `Score`.
+-->
+- `ServiceAffinity`：检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod
+  与配置的标签所定义的节点集是否适配。
+  这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。
+  
+  实现的扩展点：`PreFilter`，`Filter`，`Score`。
+
+<!-- ### Multiple profiles -->
+### 多配置文件    {#multiple-profiles}
+
+<!--  
+You can configure `kube-scheduler` to run more than one profile.
+Each profile has an associated scheduler name and can have a different set of
+plugins configured in its [extension points](#extension-points).
+-->
+你可以配置 `kube-scheduler` 运行多个配置文件。
+每个配置文件都有一个关联的调度器名称，并且可以在其扩展点中配置一组不同的插件。
+
+<!--  
+With the following sample configuration, the scheduler will run with two
+profiles: one with the default plugins and one with all scoring plugins
+disabled.
+-->
+使用下面的配置样例，调度器将运行两个配置文件：一个使用默认插件，另一个禁用所有打分插件。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+profiles:
+  - schedulerName: default-scheduler
+  - schedulerName: no-scoring-scheduler
+    plugins:
+      preScore:
+        disabled:
+        - name: '*'
+      score:
+        disabled:
+        - name: '*'
+```
+
+<!--  
+Pods that want to be scheduled according to a specific profile can include
+the corresponding scheduler name in its `.spec.schedulerName`.
+-->
+希望根据特定配置文件调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。
+
+<!--  
+By default, one profile with the scheduler name `default-scheduler` is created.
+This profile includes the default plugins described above. When declaring more
+than one profile, a unique scheduler name for each of them is required.
+-->
+默认情况下，将创建一个名为 `default-scheduler` 的配置文件。
+这个配置文件包括上面描述的所有默认插件。
+声明多个配置文件时，每个配置文件中调度器名称必须唯一。
+
+<!--  
+If a Pod doesn't specify a scheduler name, kube-apiserver will set it to
+`default-scheduler`. Therefore, a profile with this scheduler name should exist
+to get those pods scheduled.
+-->
+如果 Pod 未指定调度器名称，kube-apiserver 将会把它设置为 `default-scheduler`。
+因此，应该存在一个名为 `default-scheduler` 的配置文件来调度这些 Pod。
+
+{{< note >}}
+<!--  
+Pod's scheduling events have `.spec.schedulerName` as the ReportingController.
+Events for leader election use the scheduler name of the first profile in the
+list.
+-->
+Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController。
+领导者选择事件使用列表中第一个配置文件的调度器名称。
+{{< /note >}}
+
+{{< note >}}
+<!--  
+All profiles must use the same plugin in the QueueSort extension point and have
+the same configuration parameters (if applicable). This is because the scheduler
+only has one pending pods queue.
+-->
+所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。
+这是因为调度器只有一个的队列保存悬决的 Pod。
+
+{{< /note >}}
+
+## {{% heading "whatsnext" %}}
+
+<!--  
+* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
+* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
+-->
+* 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
+* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
\ No newline at end of file
diff --git a/content/zh/docs/reference/scheduling/policies.md b/content/zh/docs/reference/scheduling/policies.md
new file mode 100644
index 0000000000..248e3a7f84
--- /dev/null
+++ b/content/zh/docs/reference/scheduling/policies.md
@@ -0,0 +1,233 @@
+---
+title: 调度策略
+content_type: concept
+weight: 10
+---
+<!--  
+title: Scheduling Policies
+content_type: concept
+weight: 10
+-->
+
+<!-- overview -->
+
+<!--  
+A scheduling Policy can be used to specify the *predicates* and *priorities*
+that the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
+runs to [filter and score nodes](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation),
+respectively.
+-->
+{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
+根据调度策略指定的*断言（predicates）*和*优先级（priorities）*
+分别对节点进行[过滤和打分](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。
+
+<!--  
+You can set a scheduling policy by running
+`kube-scheduler --policy-config-file <filename>` or
+`kube-scheduler --policy-configmap <ConfigMap>`
+and using the [Policy type](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy).
+-->
+你可以通过执行 `kube-scheduler --policy-config-file <filename>` 或
+`kube-scheduler --policy-configmap <ConfigMap>` 
+设置并使用[调度策略](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)。
+
+
+<!-- body -->
+
+<!-- ## Predicates -->
+## 断言    {#predicates}
+
+
+<!-- The following *predicates* implement filtering: -->
+以下*断言*实现了过滤接口：
+
+<!-- 
+- `PodFitsHostPorts`: Checks if a Node has free ports (the network protocol kind)
+  for the Pod ports the Pod is requesting. 
+-->
+- `PodFitsHostPorts`：检查 Pod 请求的端口（网络协议类型）在节点上是否可用。
+
+<!-- - `PodFitsHost`: Checks if a Pod specifies a specific Node by its hostname. -->
+- `PodFitsHost`：检查 Pod 是否通过主机名指定了 Node。
+
+<!-- 
+- `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory)
+  to meet the requirement of the Pod.
+-->
+- `PodFitsResources`：检查节点的空闲资源（例如，CPU和内存）是否满足 Pod 的要求。
+
+<!--  
+- `MatchNodeSelector`: Checks if a Pod's Node {{< glossary_tooltip term_id="selector" >}}
+   matches the Node's {{< glossary_tooltip text="label(s)" term_id="label" >}}.
+-->
+- `MatchNodeSelector`：检查 Pod 的节点{{< glossary_tooltip text="选择算符" term_id="selector" >}}
+  和节点的 {{< glossary_tooltip text="标签" term_id="label" >}} 是否匹配。
+
+<!--  
+- `NoVolumeZoneConflict`: Evaluate if the {{< glossary_tooltip text="Volumes" term_id="volume" >}}
+  that a Pod requests are available on the Node, given the failure zone restrictions for
+  that storage.
+-->
+- `NoVolumeZoneConflict`：给定该存储的故障区域限制，
+  评估 Pod 请求的{{< glossary_tooltip text="卷" term_id="volume" >}}在节点上是否可用。
+
+<!--  
+- `NoDiskConflict`: Evaluates if a Pod can fit on a Node due to the volumes it requests,
+   and those that are already mounted.
+-->
+- `NoDiskConflict`：根据 Pod 请求的卷是否在节点上已经挂载，评估 Pod 和节点是否匹配。
+
+<!--  
+- `MaxCSIVolumeCount`: Decides how many {{< glossary_tooltip text="CSI" term_id="csi" >}}
+  volumes should be attached, and whether that's over a configured limit.
+-->
+- `MaxCSIVolumeCount`：决定附加 {{< glossary_tooltip text="CSI" term_id="csi" >}} 卷的数量，判断是否超过配置的限制。
+
+<!--  
+- `CheckNodeMemoryPressure`: If a Node is reporting memory pressure, and there's no
+  configured exception, the Pod won't be scheduled there.
+-->
+- `CheckNodeMemoryPressure`：如果节点正上报内存压力，并且没有异常配置，则不会把 Pod 调度到此节点上。
+
+<!--  
+- `CheckNodePIDPressure`: If a Node is reporting that process IDs are scarce, and
+  there's no configured exception, the Pod won't be scheduled there.
+-->
+- `CheckNodePIDPressure`：如果节点正上报进程 ID 稀缺，并且没有异常配置，则不会把 Pod 调度到此节点上。
+
+<!--  
+- `CheckNodeDiskPressure`: If a Node is reporting storage pressure (a filesystem that
+   is full or nearly full), and there's no configured exception, the Pod won't be
+   scheduled there.
+-->
+- `CheckNodeDiskPressure`：如果节点正上报存储压力（文件系统已满或几乎已满），并且没有异常配置，则不会把 Pod 调度到此节点上。
+
+<!--  
+- `CheckNodeCondition`: Nodes can report that they have a completely full filesystem,
+  that networking isn't available or that kubelet is otherwise not ready to run Pods.
+  If such a condition is set for a Node, and there's no configured exception, the Pod
+  won't be scheduled there.
+-->
+- `CheckNodeCondition`：节点可用上报自己的文件系统已满，网络不可用或者 kubelet 尚未准备好运行 Pod。
+  如果节点上设置了这样的状况，并且没有异常配置，则不会把 Pod 调度到此节点上。
+
+<!--  
+- `PodToleratesNodeTaints`: checks if a Pod's {{< glossary_tooltip text="tolerations" term_id="toleration" >}}
+  can tolerate the Node's {{< glossary_tooltip text="taints" term_id="taint" >}}.
+-->
+- `PodToleratesNodeTaints`：检查 Pod 的{{< glossary_tooltip text="容忍" term_id="toleration" >}}
+  是否能容忍节点的{{< glossary_tooltip text="污点" term_id="taint" >}}。
+
+<!-- 
+- `CheckVolumeBinding`: Evaluates if a Pod can fit due to the volumes it requests.
+  This applies for both bound and unbound
+  {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}}. 
+-->
+- `CheckVolumeBinding`：基于 Pod 的卷请求，评估 Pod 是否适合节点，这里的卷包括绑定的和未绑定的
+  {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} 都适用。
+
+
+<!-- ## Priorities -->
+## 优先级    {#priorities}
+
+<!-- The following *priorities* implement scoring: -->
+以下*优先级*实现了打分接口：
+
+<!--  
+- `SelectorSpreadPriority`: Spreads Pods across hosts, considering Pods that
+   belong to the same {{< glossary_tooltip text="Service" term_id="service" >}},
+   {{< glossary_tooltip term_id="statefulset" >}} or
+   {{< glossary_tooltip term_id="replica-set" >}}.
+-->
+- `SelectorSpreadPriority`：属于同一 {{< glossary_tooltip text="Service" term_id="service" >}}、
+  {{< glossary_tooltip term_id="statefulset" >}} 或
+  {{< glossary_tooltip term_id="replica-set" >}} 的 Pod，跨主机部署。
+
+<!--  
+- `InterPodAffinityPriority`: Implements preferred
+  [inter pod affininity and antiaffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity).
+-->
+- `InterPodAffinityPriority`：实现了 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)的优先级。
+
+<!--
+- `LeastRequestedPriority`: Favors nodes with fewer requested resources. In other
+  words, the more Pods that are placed on a Node, and the more resources those
+  Pods use, the lower the ranking this policy will give.  
+-->
+- `LeastRequestedPriority`：偏向最少请求资源的节点。 
+  换句话说，节点上的 Pod 越多，使用的资源就越多，此策略给出的排名就越低。
+
+<!--  
+- `MostRequestedPriority`: Favors nodes with most requested resources. This policy
+  will fit the scheduled Pods onto the smallest number of Nodes needed to run your
+  overall set of workloads.
+-->
+- `MostRequestedPriority`：支持最多请求资源的节点。
+  该策略将 Pod 调度到整体工作负载所需的最少的一组节点上。
+
+<!-- - `RequestedToCapacityRatioPriority`: Creates a requestedToCapacity based ResourceAllocationPriority using default resource scoring function shape. -->
+- `RequestedToCapacityRatioPriority`：使用默认的打分方法模型，创建基于 ResourceAllocationPriority 的 requestedToCapacity。
+
+<!-- - `BalancedResourceAllocation`: Favors nodes with balanced resource usage. -->
+- `BalancedResourceAllocation`：偏向平衡资源使用的节点。
+
+<!-- 
+- `NodePreferAvoidPodsPriority`: Prioritizes nodes according to the node annotation
+  `scheduler.alpha.kubernetes.io/preferAvoidPods`. You can use this to hint that
+  two different Pods shouldn't run on the same Node. 
+  -->
+- `NodePreferAvoidPodsPriority`：根据节点的注解 `scheduler.alpha.kubernetes.io/preferAvoidPods` 对节点进行优先级排序。
+  你可以使用它来暗示两个不同的 Pod 不应在同一节点上运行。
+
+<!--  
+- `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling
+   preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution.
+   You can read more about this in [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).
+-->
+- `NodeAffinityPriority`：根据节点亲和中 PreferredDuringSchedulingIgnoredDuringExecution 字段对节点进行优先级排序。
+  你可以在[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)中了解更多。
+
+<!--  
+- `TaintTolerationPriority`: Prepares the priority list for all the nodes, based on
+  the number of intolerable taints on the node. This policy adjusts a node's rank
+  taking that list into account.
+-->
+- `TaintTolerationPriority`：根据节点上无法忍受的污点数量，给所有节点进行优先级排序。
+  此策略会根据排序结果调整节点的等级。
+
+<!-- 
+- `ImageLocalityPriority`: Favors nodes that already have the
+  {{< glossary_tooltip text="container images" term_id="image" >}} for that
+  Pod cached locally.
+-->
+- `ImageLocalityPriority`：偏向已在本地缓存 Pod 所需容器镜像的节点。
+
+<!-- 
+- `ServiceSpreadingPriority`: For a given Service, this policy aims to make sure that
+  the Pods for the Service run on different nodes. It favours scheduling onto nodes
+  that don't have Pods for the service already assigned there. The overall outcome is
+  that the Service becomes more resilient to a single Node failure.
+-->
+- `ServiceSpreadingPriority`：对于给定的 Service，此策略旨在确保该 Service 关联的 Pod 在不同的节点上运行。
+  它偏向把 Pod 调度到没有该服务的节点。
+  整体来看，Service 对于单个节点故障变得更具弹性。
+
+<!-- - `EqualPriority`: Gives an equal weight of one to all nodes. -->
+- `EqualPriority`：给予所有节点相等的权重。
+
+<!-- 
+- `EvenPodsSpreadPriority`: Implements preferred
+  [pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). 
+-->
+- `EvenPodsSpreadPriority`：实现了 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)的优先级排序。
+
+
+
+## {{% heading "whatsnext" %}}
+
+<!--  
+* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
+* Learn about [kube-scheduler Configuration](/docs/reference/scheduling/config/)
+-->
+* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
+* 了解 [kube-scheduler 配置](/zh/docs/reference/scheduling/config/)
\ No newline at end of file
diff --git a/content/zh/docs/reference/setup-tools/_index.md b/content/zh/docs/reference/setup-tools/_index.md
index 9bb6809cde..9cd9d94f0d 100644
--- a/content/zh/docs/reference/setup-tools/_index.md
+++ b/content/zh/docs/reference/setup-tools/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 安装工具
 weight: 50
-toc-hide: true
 ---
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/_index.md b/content/zh/docs/reference/setup-tools/kubeadm/_index.md
index 6863791207..60204dfa6d 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/_index.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/_index.md
@@ -1,5 +1,59 @@
 ---
 title: "Kubeadm"
 weight: 10
-toc-hide: true
+no_list: true
+content_type: concept
+card:
+  name: reference
+  weight: 40
 ---
+
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">
+
+<!-- 
+Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice "fast paths" for creating Kubernetes clusters.
+ -->
+Kubeadm 是一个提供了 `kubeadm init` 和 `kubeadm join` 的工具，作为创建 Kubernetes 集群的 “快捷途径” 的最佳实践。
+
+<!-- 
+kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping,
+not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
+ -->
+kubeadm 通过执行必要的操作来启动和运行最小可用集群。按照设计，它只关注启动引导，而非配置机器。同样的，安装各种 “锦上添花” 的扩展，例如 Kubernetes Dashboard,
+监控方案，以及特定云平台的扩展，都不在讨论范围内。
+
+<!-- 
+Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
+ -->
+相反，我们希望在 kubeadm 之上构建更高级别以及更加合规的工具，理想情况下，使用 kubeadm 作为所有部署工作的基准将会更加易于创建一致性集群。
+
+<!-- 
+## How to install
+ -->
+## 如何安装
+
+<!-- 
+To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
+ -->
+要安装 kubeadm, 请查阅[安装指南](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+
+## {{% heading "whatsnext" %}}
+
+<!-- 
+* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes control-plane node
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
+* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
+* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
+* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
+* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
+ -->
+* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init) 用于搭建控制平面节点
+* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join) 用于搭建工作节点并将其加入到集群中
+* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 用于升级 Kubernetes 集群到新版本
+* [kubeadm config](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用了 v1.7.x 或更低版本的 kubeadm 版本初始化你的集群，则使用 `kubeadm upgrade` 来配置你的集群
+* [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token) 用于管理 `kubeadm join` 使用的令牌
+* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset) 用于恢复通过 `kubeadm init` 或者 `kubeadm join` 命令对节点进行的任何变更
+* [kubeadm version](/zh/docs/reference/setup-tools/kubeadm/kubeadm-version) 用于打印 kubeadm 的版本信息
+* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 用于预览一组可用于收集社区反馈的特性
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs.md
new file mode 100644
index 0000000000..dd1e3f5c78
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs.md
@@ -0,0 +1,55 @@
+
+<!-- ### Synopsis -->
+### 概要
+
+
+
+<!-- Commands related to handling kubernetes certificates -->
+与处理 kubernetes 证书相关的命令
+
+<!-- ### Options -->
+### 选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">help for certs</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><!-- help for certs-->certs 命令的帮助</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+<!-- ### Options inherited from parent commands -->
+### 继承于父命令的选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_generate-csr.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_generate-csr.md
new file mode 100644
index 0000000000..cbf2a6368e
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_certs_generate-csr.md
@@ -0,0 +1,111 @@
+
+<!-- ### Synopsis -->
+### 概要
+
+<!-- 
+Generates keys and certificate signing requests (CSRs) for all the certificates required to run the control plane. This command also generates partial kubeconfig files with private key data in the  "users &gt; user &gt; client-key-data" field, and for each kubeconfig file an accompanying ".csr" file is created.
+-->
+为运行控制平面所需的所有证书生成密钥和证书签名请求（CSR）。该命令会生成部分 kubeconfig 文件，
+其中 "users &gt; user &gt; client-key-data" 字段包含私钥数据，并为每个 kubeconfig 文件创建一个随附的".csr"文件。
+
+<!--  
+This command is designed for use in [Kubeadm External CA Mode](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing.
+-->
+该命令设计用于 [Kubeadm 外部 CA 模式](https://kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode)。 
+它生成 CSR，然后你可以将其提交给外部证书颁发机构进行签名。
+
+<!--  
+The PEM encoded signed certificates should then be saved alongside the key files, using ".crt" as the file extension, or in the case of kubeconfig files, the PEM encoded signed certificate should be base64 encoded and added to the kubeconfig file in the "users &gt; user &gt; client-certificate-data" field.
+-->
+然后，应使用 ".crt" 作为文件扩展名将 PEM 编码的签名证书与密钥文件一起保存，或者，对于 kubeconfig 文件，
+PEM 编码的签名证书应使用 base64 编码，并添加到 "users &gt; user &gt; client-certificate-data" 字段。
+
+```
+kubeadm alpha certs generate-csr [flags]
+```
+
+<!-- ### Examples -->
+### 示例
+
+<!-- 
+```
+  # The following command will generate keys and CSRs for all control-plane certificates and kubeconfig files:
+  kubeadm alpha certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki
+```
+-->
+```
+  # 以下命令将为所有控制平面证书和 kubeconfig 文件生成密钥和 CSR :
+  kubeadm alpha certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki
+```
+
+<!-- ### Options -->
+### 选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--cert-dir string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">The path where to save the certificates</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">保存证书的路径</td>
+</tr>
+
+<tr>
+<td colspan="2">--config string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径。</td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">help for generate-csr</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">generate-csr 命令的帮助</td>
+</tr>
+
+<tr>
+<!-- <td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes"</td> -->
+<td colspan="2">--kubeconfig-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值："/etc/kubernetes"</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">The path where to save the kubeconfig file.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">保存 kubeconfig 文件的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+<!-- ### Options inherited from parent commands -->
+### 继承于父命令的选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_download.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_download.md
deleted file mode 100644
index e2d07e53e1..0000000000
--- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_download.md
+++ /dev/null
@@ -1,129 +0,0 @@
-
-<!--
-### Synopsis
--->
-
-### 概要
-
-<!--
-Download the kubelet configuration from a ConfigMap of the form "kubelet-config-1.X" in the cluster, where X is the minor version of the kubelet. Either kubeadm autodetects the kubelet version by exec-ing "kubelet --version" or respects the --kubelet-version parameter.
--->
-
-从集群中形式为 "kubelet-config-1.X" 的 ConfigMap 中下载 kubelet 配置，其中 X 是 kubelet 的次要版本。
-kubeadm 要么通过执行 "kubelet --version" 自动检测 kubelet 版本，要么传递 --kubelet-version 参数。
-
-<!--
-Alpha Disclaimer: this command is currently alpha.
--->
-
-Alpha 免责声明：此命令当前为 Alpha 功能。
-
-```
-kubeadm alpha kubelet config download [flags]
-```
-
-<!--
-### Examples
--->
-
-### 示例
-
-<!--
-  # Download the kubelet configuration from the ConfigMap in the cluster. Autodetect the kubelet version.
-  kubeadm alpha phase kubelet config download
-
-  # Download the kubelet configuration from the ConfigMap in the cluster. Use a specific desired kubelet version.
-  kubeadm alpha phase kubelet config download kubelet-version 1.16.0
--->
-
-```
-# 从集群中的 ConfigMap 下载 kubelet 配置。自动检测 kubelet 版本。
-kubeadm alpha phase kubelet config download
-
-# 从集群中的 ConfigMap 下载 kubelet 配置。使用特定的所需 kubelet 版本。
-kubeadm alpha phase kubelet config download --kubelet-version 1.16.0
-```
-
-<!--
-### Options
--->
-
-### 选项
-
-   <table style="width: 100%; table-layout: fixed;">
-<colgroup>
-<col span="1" style="width: 10px;" />
-<col span="1" />
-</colgroup>
-<tbody>
-
-<tr>
-<td colspan="2">-h, --help</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">
-<!--
-help for download
--->
-download 的帮助命令
-</td>
-</tr>
-
-<tr>
-<td colspan="2">
-<!--
---kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"
--->
---kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值："/etc/kubernetes/admin.conf"
-</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">
-<!--
-If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
--->
-与集群通信时使用的 kubeconfig 文件。如果未设置该标志，可以在一组标准位置中搜索现有的 kubeconfig 文件。
-</td>
-</tr>
-
-<tr>
-<td colspan="2">--kubelet-version string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">
-<!-- The desired version for the kubelet. Defaults to being autodetected from 'kubelet -version'.  -->
-kubelet 所需版本。默认为从 'kubelet --version' 中自动检测到。
-</td>
-</tr>
-
-</tbody>
-</table>
-
-<!--
-### Options inherited from parent commands
--->
-
-### 从父命令继承的选项
-
-   <table style="width: 100%; table-layout: fixed;">
-<colgroup>
-<col span="1" style="width: 10px;" />
-<col span="1" />
-</colgroup>
-<tbody>
-
-<tr>
-<td colspan="2">--rootfs string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">
-<!--
-[EXPERIMENTAL] The path to the 'real' host root filesystem.
--->
-[实验] 到 '真实' 主机根文件系统的路径。
-</td>
-</tr>
-
-</tbody>
-</table>
-
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md
new file mode 100644
index 0000000000..644a8c604e
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md
@@ -0,0 +1,71 @@
+
+<!-- ### Synopsis -->
+### 概要
+
+<!-- Updates settings relevant to the kubelet after TLS bootstrap -->
+TLS 引导后更新与 kubelet 相关的设置
+
+```
+kubeadm init phase kubelet-finalize [flags]
+```
+
+<!-- ### Examples -->
+### 示例
+
+<!--  
+```
+  # Updates settings relevant to the kubelet after TLS bootstrap
+  kubeadm init phase kubelet-finalize all --config
+```
+-->
+```
+  # 在 TLS 引导后更新与 kubelet 相关的设置
+  kubeadm init phase kubelet-finalize all --config
+```
+
+<!-- ### Options -->
+### 选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kubelet-finalize</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">kubelet-finalize 操作的帮助命令</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+<!-- ### Options inherited from parent commands -->
+### 继承于父命令的选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md
new file mode 100644
index 0000000000..d99d6036a1
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md
@@ -0,0 +1,89 @@
+
+<!-- ### Synopsis -->
+### 概要
+
+
+<!-- Run all kubelet-finalize phases -->
+运行所有 kubelet-finalize 阶段
+
+```
+kubeadm init phase kubelet-finalize all [flags]
+```
+
+<!-- ### Examples -->
+### 示例
+
+<!--  
+```
+  # Updates settings relevant to the kubelet after TLS bootstrap
+  kubeadm init phase kubelet-finalize all --config
+```
+-->
+```
+  # 在 TLS 引导后更新与 kubelet 相关的设置
+  kubeadm init phase kubelet-finalize all --config
+```
+
+<!-- ### Options -->
+### 选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<!-- <td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td> -->
+<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "/etc/kubernetes/pki"</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">The path where to save and store the certificates.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">保存和存储证书的路径。</td>
+</tr>
+
+<tr>
+<td colspan="2">--config string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径。</td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">help for all</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">all 操作的帮助命令</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+<!-- ### Options inherited from parent commands -->
+### 继承于父命令的选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md
new file mode 100644
index 0000000000..77517935ca
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md
@@ -0,0 +1,75 @@
+
+<!-- ### Synopsis -->
+### 概要
+
+
+
+<!-- Enable kubelet client certificate rotation -->
+启用 kubelet 客户端证书轮换
+
+```
+kubeadm init phase kubelet-finalize experimental-cert-rotation [flags]
+```
+
+<!-- ### Options -->
+### 选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">The path where to save and store the certificates.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">保存和存储证书的路径。</td>
+</tr>
+
+<tr>
+<td colspan="2">--config string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">kubeadm 配置文件的路径。</td>
+</tr>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">help for experimental-cert-rotation</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">experimental-cert-rotation 操作的帮助命令</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+<!-- ### Options inherited from parent commands -->
+### 继承于父命令的选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md
new file mode 100644
index 0000000000..2fd33ffc63
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md
@@ -0,0 +1,69 @@
+
+<!-- ### Synopsis -->
+### 概要
+
+
+<!-- Run pre-flight checks for kubeadm upgrade node. -->
+
+执行 kubeadm 升级节点的预检。
+
+```
+kubeadm upgrade node phase preflight [flags]
+```
+
+<!-- ### Options -->
+### 选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">-h, --help</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">help for preflight</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">preflight 操作的帮助命令</td>
+</tr>
+
+<tr>
+<td colspan="2">--ignore-preflight-errors stringSlice</td>
+</tr>
+<tr>
+<!-- 
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.</td> 
+-->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">错误将显示为警告的检查清单。示例：'IsPrivilegedUser,Swap'。值为'all'表示忽略所有检查的错误。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
+<!-- ### Options inherited from parent commands -->
+### 继承于父命令的选项
+
+   <table style="width: 100%; table-layout: fixed;">
+<colgroup>
+<col span="1" style="width: 10px;" />
+<col span="1" />
+</colgroup>
+<tbody>
+
+<tr>
+<td colspan="2">--rootfs string</td>
+</tr>
+<tr>
+<!-- <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td> -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+</tr>
+
+</tbody>
+</table>
+
+
+
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md
index 6c64e38f0f..88f2510b6e 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md
@@ -102,15 +102,14 @@ kubeadm upgrade plan [version] [flags]
 
 -->
 
-```
-### 概述
 
+### 概述
 
 检查可升级到哪些版本，并验证您当前的集群是否可升级。 要跳过互联网检查，请传递可选的 [version] 参数 
 
-​```
+```
 kubeadm upgrade plan [version] [flags]
-​```
+```
 
 ### 选项
 
@@ -200,4 +199,3 @@ kubeadm upgrade plan [version] [flags]
 
 </tbody>
 </table>
-```
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md
new file mode 100644
index 0000000000..4d8ea53fa3
--- /dev/null
+++ b/content/zh/docs/reference/setup-tools/kubeadm/implementation-details.md
@@ -0,0 +1,1081 @@
+---
+title: 实现细节
+content_type: concept
+weight: 100
+---
+<!--  
+---
+reviewers:
+- luxas
+- jbeda
+title: Implementation details
+content_type: concept
+weight: 100
+---
+-->
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.10" state="stable" >}}
+
+<!--  
+`kubeadm init` and `kubeadm join` together provides a nice user experience for creating a best-practice but bare Kubernetes cluster from scratch.
+However, it might not be obvious _how_ kubeadm does that.
+-->
+`kubeadm init` 和 `kubeadm join` 结合在一起提供了良好的用户体验，因为从头开始创建实践最佳而配置最基本的 Kubernetes 集群。
+但是，kubeadm _如何_ 做到这一点可能并不明显。
+
+<!-- 
+This document provides additional details on what happen under the hood, 
+with the aim of sharing knowledge on Kubernetes cluster best practices. 
+-->
+本文档提供了更多幕后的详细信息，旨在分享有关 Kubernetes 集群最佳实践的知识。
+
+<!-- body -->
+<!-- ## Core design principles -->
+## 核心设计原则    {#core-design-principles}
+
+<!-- The cluster that `kubeadm init` and `kubeadm join` set up should be: -->
+`kubeadm init` 和 `kubeadm join` 设置的集群应为：
+
+<!-- 
+ - **Secure**: It should adopt latest best-practices like:
+   - enforcing RBAC
+   - using the Node Authorizer
+   - using secure communication between the control plane components
+   - using secure communication between the API server and the kubelets
+   - lock-down the kubelet API
+   - locking down access to the API for system components like the kube-proxy and CoreDNS
+   - locking down what a Bootstrap Token can access
+ - **Easy to use**: The user should not have to run anything more than a couple of commands:
+   - `kubeadm init`
+   - `export KUBECONFIG=/etc/kubernetes/admin.conf`
+   - `kubectl apply -f <network-of-choice.yaml>`
+   - `kubeadm join --token <token> <master-ip>:<master-port>`
+ - **Extendable**:
+   - It should _not_ favor any particular network provider. Configuring the cluster network is out-of-scope
+   - It should provide the possibility to use a config file for customizing various parameters
+ -->
+ - **安全**：它应采用最新的最佳实践，例如：
+   - 应用 RBAC
+   - 使用节点鉴权机制（Node Authorizer）
+   - 在控制平面组件之间使用安全通信
+   - 在 API 服务器和 kubelet 之间使用安全通信
+   - 锁定 kubelet API
+   - 锁定对系统组件（例如 kube-proxy 和 CoreDNS）的 API 的访问
+   - 锁定启动引导令牌（Bootstrap Token）可以访问的内容
+ - **易用**：用户只需要运行几个命令即可：
+   - `kubeadm init`
+   - `export KUBECONFIG=/etc/kubernetes/admin.conf`
+   - `kubectl apply -f <network-of-choice.yaml>`
+   - `kubeadm join --token <token> <master-ip>:<master-port>`
+ - **可扩展**：
+   - _不_ 应偏向任何特定的网络提供商。不涉及配置集群网络
+   - 应该可以使用配置文件来自定义各种参数
+
+<!-- ## Constants and well-known values and paths -->
+## 常量以及众所周知的值和路径  {#constants-and-well-known-values-and-paths}
+
+<!-- 
+In order to reduce complexity and to simplify development of higher level tools that build on top of kubeadm, it uses a
+limited set of constant values for well-known paths and file names.
+-->
+为了降低复杂性并简化基于 kubeadm 的高级工具的开发，对于众所周知的路径和文件名，它使用了一组有限的常量值。
+
+<!--  
+The Kubernetes directory `/etc/kubernetes` is a constant in the application, since it is clearly the given path
+in a majority of cases, and the most intuitive location; other constants paths and file names are:
+-->
+Kubernetes 目录 `/etc/kubernetes` 在应用程序中是一个常量，因为在大多数情况下它显然是给定的路径，并且是最直观的位置；
+其他路径常量和文件名有：
+
+<!--  
+- `/etc/kubernetes/manifests` as the path where kubelet should look for static Pod manifests. Names of static Pod manifests are:
+    - `etcd.yaml`
+    - `kube-apiserver.yaml`
+    - `kube-controller-manager.yaml`
+    - `kube-scheduler.yaml`
+- `/etc/kubernetes/` as the path where kubeconfig files with identities for control plane components are stored. Names of kubeconfig files are:
+    - `kubelet.conf` (`bootstrap-kubelet.conf` during TLS bootstrap)
+    - `controller-manager.conf`
+    - `scheduler.conf`
+    - `admin.conf` for the cluster admin and kubeadm itself
+- Names of certificates and key files :
+    - `ca.crt`, `ca.key` for the Kubernetes certificate authority
+    - `apiserver.crt`, `apiserver.key` for the API server certificate
+    - `apiserver-kubelet-client.crt`, `apiserver-kubelet-client.key` for the client certificate used by the API server to connect to the kubelets securely
+    - `sa.pub`, `sa.key` for the key used by the controller manager when signing ServiceAccount
+    - `front-proxy-ca.crt`, `front-proxy-ca.key` for the front proxy certificate authority
+    - `front-proxy-client.crt`, `front-proxy-client.key` for the front proxy client
+-->
+- `/etc/kubernetes/manifests` 作为 kubelet 查找静态 Pod 清单的路径。静态 Pod 清单的名称为：
+    - `etcd.yaml`
+    - `kube-apiserver.yaml`
+    - `kube-controller-manager.yaml`
+    - `kube-scheduler.yaml`
+- `/etc/kubernetes/` 作为带有控制平面组件身份标识的 kubeconfig 文件的路径。kubeconfig 文件的名称为：
+    - `kubelet.conf` (在 TLS 引导时名称为 `bootstrap-kubelet.conf` )
+    - `controller-manager.conf`
+    - `scheduler.conf`
+    - `admin.conf` 用于集群管理员和 kubeadm 本身
+- 证书和密钥文件的名称：
+    - `ca.crt`, `ca.key` 用于 Kubernetes 证书颁发机构
+    - `apiserver.crt`, `apiserver.key` 用于 API 服务器证书
+    - `apiserver-kubelet-client.crt`, `apiserver-kubelet-client.key` 用于 API 服务器安全地连接到 kubelet 的客户端证书
+    - `sa.pub`, `sa.key` 用于签署 ServiceAccount 时 控制器管理器使用的密钥
+    - `front-proxy-ca.crt`, `front-proxy-ca.key` 用于前端代理证书颁发机构
+    - `front-proxy-client.crt`, `front-proxy-client.key` 用于前端代理客户端
+
+<!-- ## kubeadm init workflow internal design -->
+## kubeadm init 工作流程内部设计  {#kubeadm-init-workflow-internal-design}
+
+<!--  
+The `kubeadm init` [internal workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow) consists of a sequence of atomic work tasks to perform,
+as described in `kubeadm init`.
+-->
+`kubeadm init` [内部工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow)包含一系列要执行的原子工作任务，
+如 `kubeadm init` 中所述。
+
+<!--  
+The [`kubeadm init phase`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) command allows users to invoke each task individually, and ultimately offers a reusable and composable API/toolbox that can be used by other Kubernetes bootstrap tools, by any IT automation tool or by an advanced user for creating custom clusters.
+-->
+[`kubeadm init phase`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) 命令允许用户分别调用每个任务，
+并最终提供可重用且可组合的 API 或工具箱，其他 Kubernetes 引导工具、任何 IT 自动化工具和高级用户都可以使用它用来创建的自定义集群。
+
+<!-- ### Preflight checks -->
+### 预检  {#preflight-checks}
+
+<!-- 
+Kubeadm executes a set of preflight checks before starting the init, with the aim to verify preconditions and avoid common cluster startup problems.
+The user can skip specific preflight checks or all of them with the `--ignore-preflight-errors` option. 
+-->
+Kubeadm 在启动 init 之前执行一组预检，目的是验证先决条件并避免常见的集群启动问题。
+用户可以使用 `--ignore-preflight-errors` 选项跳过特定的预检查或全部检查。
+
+<!--  
+- [warning] If the Kubernetes version to use (specified with the `--kubernetes-version` flag) is at least one minor version higher than the kubeadm CLI version.
+- Kubernetes system requirements:
+  - if running on linux:
+    - [error] if Kernel is older than the minimum required version
+    - [error] if required cgroups subsystem aren't in set up
+  - if using docker:
+    - [warning/error] if Docker service does not exist, if it is disabled, if it is not active.
+    - [error] if Docker endpoint does not exist or does not work
+    - [warning] if docker version is not in the list of validated docker versions
+  - If using other cri engine:
+    - [error] if crictl socket does not answer
+-->
+- [警告] 如果要使用的 Kubernetes 版本（由 `--kubernetes-version` 标志指定）比 kubeadm CLI 版本至少高一个小版本。
+- Kubernetes 系统要求：
+  - 如果在 linux上运行：
+    - [错误] 如果内核早于最低要求的版本
+    - [错误] 如果未设置所需的 cgroups 子系统
+  - 如果使用 docker：
+    - [警告/错误] 如果 Docker 服务不存在、被禁用或未激活。
+    - [错误] 如果 Docker 端点不存在或不起作用
+    - [警告] 如果 docker 版本不在经过验证的 docker 版本列表中
+  - 如果使用其他 cri 引擎：
+    - [错误] 如果 crictl 套接字未应答
+<!--  
+- [error] if user is not root
+- [error] if the machine hostname is not a valid DNS subdomain
+- [warning] if the host name cannot be reached via network lookup
+- [error] if kubelet version is lower that the minimum kubelet version supported by kubeadm (current minor -1)
+- [error] if kubelet version is at least one minor higher than the required controlplane version (unsupported version skew)
+- [warning] if kubelet service does not exist or if it is disabled
+- [warning] if firewalld is active
+- [error] if API server bindPort or ports 10250/10251/10252 are used
+- [Error] if `/etc/kubernetes/manifest` folder already exists and it is not empty
+- [Error] if `/proc/sys/net/bridge/bridge-nf-call-iptables` file does not exist/does not contain 1
+- [Error] if advertise address is ipv6 and `/proc/sys/net/bridge/bridge-nf-call-ip6tables` does not exist/does not contain 1.
+- [Error] if swap is on
+- [Error] if `conntrack`, `ip`, `iptables`,  `mount`, `nsenter` commands are not present in the command path
+- [warning] if `ebtables`, `ethtool`, `socat`, `tc`, `touch`, `crictl` commands are not present in the command path
+- [warning] if extra arg flags for API server, controller manager,  scheduler contains some invalid options
+- [warning] if connection to https://API.AdvertiseAddress:API.BindPort goes through proxy
+- [warning] if connection to services subnet goes through proxy (only first address checked)
+- [warning] if connection to Pods subnet goes through proxy (only first address checked)
+-->
+- [错误] 如果用户不是 root 用户
+- [错误] 如果机器主机名不是有效的 DNS 子域
+- [警告] 如果通过网络查找无法访问主机名
+- [错误] 如果 kubelet 版本低于 kubeadm 支持的最低 kubelet 版本（当前小版本 -1）
+- [错误] 如果 kubelet 版本比所需的控制平面板版本至少高一个小（不支持的版本偏斜）
+- [警告] 如果 kubelet 服务不存在或已被禁用
+- [警告] 如果 firewalld 处于活动状态
+- [错误] 如果 API ​​服务器绑定的端口或 10250/10251/10252 端口已被占用
+- [错误] 如果 `/etc/kubernetes/manifest` 文件夹已经存在并且不为空
+- [错误] 如果 `/proc/sys/net/bridge/bridge-nf-call-iptables` 文件不存在或不包含 1
+- [错误] 如果建议地址是 ipv6，并且 `/proc/sys/net/bridge/bridge-nf-call-ip6tables` 不存在或不包含 1
+- [错误] 如果启用了交换分区
+- [错误] 如果命令路径中没有 `conntrack`、`ip`、`iptables`、`mount`、`nsenter` 命令
+- [警告] 如果命令路径中没有 `ebtables`、`ethtool`、`socat`、`tc`、`touch`、`crictl` 命令
+- [警告] 如果 API 服务器、控制器管理器、调度程序的其他参数标志包含一些无效选项
+- [警告] 如果与 https://API.AdvertiseAddress:API.BindPort 的连接通过代理
+- [警告] 如果服务子网的连接通过代理（仅检查第一个地址）
+- [警告] 如果 Pod 子网的连接通过代理（仅检查第一个地址）
+<!-- 
+- If external etcd is provided:
+  - [Error] if etcd version is older than the minimum required version
+  - [Error] if etcd certificates or keys are specified, but not provided
+- If external etcd is NOT provided (and thus local etcd will be installed):
+  - [Error] if ports 2379 is used
+  - [Error] if Etcd.DataDir folder already exists and it is not empty
+- If authorization mode is ABAC:
+  - [Error] if abac_policy.json does not exist
+- If authorization mode is WebHook
+  - [Error] if webhook_authz.conf does not exist
+-->
+- 如果提供了外部 etcd：
+  - [错误] 如果 etcd 版本低于最低要求版本
+  - [错误] 如果指定了 etcd 证书或密钥，但无法找到
+- 如果未提供外部 etcd（因此将安装本地 etcd）：
+  - [错误] 如果端口 2379 已被占用
+  - [错误] 如果 Etcd.DataDir 文件夹已经存在并且不为空
+- 如果授权模式为 ABAC：
+  - [错误] 如果 abac_policy.json 不存在
+- 如果授权方式为 Webhook
+  - [错误] 如果 webhook_authz.conf 不存在
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. Preflight checks can be invoked individually with the [`kubeadm init phase preflight`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-preflight) command
+-->
+1. 可以使用 [`kubeadm init phase preflight`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-preflight) 命令单独触发预检。
+
+
+<!-- ### Generate the necessary certificates -->
+### 生成必要的证书  {#generate-the-necessary-certificate}
+
+<!-- Kubeadm generates certificate and private key pairs for different purposes: -->
+Kubeadm 生成用于不同目的的证书和私钥对：
+
+ <!-- 
+ - A self signed certificate authority for the Kubernetes cluster saved into `ca.crt` file and `ca.key` private key file 
+ - A serving certificate for the API server, generated using `ca.crt` as the CA, and saved into `apiserver.crt` file with
+   its private key `apiserver.key`. This certificate should contain following alternative names:
+     - The Kubernetes service's internal clusterIP (the first address in the services CIDR, e.g. `10.96.0.1` if service subnet is `10.96.0.0/12`)
+     - Kubernetes DNS names, e.g.  `kubernetes.default.svc.cluster.local` if `--service-dns-domain` flag value is `cluster.local`, plus default DNS names `kubernetes.default.svc`, `kubernetes.default`, `kubernetes`
+     - The node-name
+     - The `--apiserver-advertise-address`
+     - Additional alternative names specified by the user
+ - A client certificate for the API server to connect to the kubelets securely, generated using `ca.crt` as the CA and saved into
+   `apiserver-kubelet-client.crt` file with its private key `apiserver-kubelet-client.key`.
+   This certificate should be in the `system:masters` organization
+ - A private key for signing ServiceAccount Tokens saved into `sa.key` file along with its public key `sa.pub`
+ - A certificate authority for the front proxy saved into `front-proxy-ca.crt` file with its key `front-proxy-ca.key`
+ - A client cert for the front proxy client, generated using `front-proxy-ca.crt` as the CA and saved into `front-proxy-client.crt` file
+   with its private key`front-proxy-client.key`
+-->
+ - Kubernetes 集群的自签名证书颁发机构已保存到 `ca.crt` 文件和 `ca.key` 私钥文件中
+ - 用于 API 服务器的服务证书，使用 `ca.crt` 作为 CA 生成，并将证书保存到 `apiserver.crt` 文件中，私钥保存到 `apiserver.key` 文件中
+   该证书应包含以下备用名称：
+    - Kubernetes 服务的内部 clusterIP（服务 CIDR 的第一个地址，例如：如果服务的子网是 `10.96.0.0/12`，则为 `10.96.0.1`）
+    - Kubernetes DNS 名称，例如：如果 `--service-dns-domain` 标志值是 `cluster.local`，则为 `kubernetes.default.svc.cluster.local`；
+      加上默认的 DNS 名称 `kubernetes.default.svc`、`kubernetes.default` 和 `kubernetes`，
+    - 节点名称
+    - `--apiserver-advertise-address`
+    - 用户指定的其他备用名称 
+  - API 服务器用于安全连接到 kubelet 的客户端证书，使用 `ca.crt` 作为 CA 生成，并保存到 `apiserver-kubelet-client.key`， 
+    私钥保存到 `apiserver-kubelet-client.crt` 文件中。该证书应该在 `system:masters` 组织中
+  - 用于签名 ServiceAccount 令牌的私钥保存到 `sa.key` 文件中，公钥保存到 `sa.pub` 文件中
+  - 用于前端代理的证书颁发机构保存到 `front-proxy-ca.crt` 文件中，私钥保存到 `front-proxy-ca.key` 文件中
+  - 前端代理客户端的客户端证书，使用 `front-proxy-ca.crt` 作为 CA 生成，并保存到 `front-proxy-client.crt` 文件中，
+    私钥保存到 `front-proxy-client.key` 文件中
+
+<!-- 
+Certificates are stored by default in `/etc/kubernetes/pki`, but this directory is configurable using the `--cert-dir` flag. 
+-->
+证书默认情况下存储在 `/etc/kubernetes/pki` 中，但是该目录可以使用 `--cert-dir` 标志进行配置。
+
+ <!-- Please note that: -->
+ 请注意：
+
+<!-- 
+1. If a given certificate and private key pair both exist, and its content is evaluated compliant with the above specs, the existing files will
+   be used and the generation phase for the given certificate skipped. This means the user can, for example, copy an existing CA to
+   `/etc/kubernetes/pki/ca.{crt,key}`, and then kubeadm will use those files for signing the rest of the certs.
+   See also [using custom certificates](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#custom-certificates)
+2. Only for the CA, it is possible to provide the `ca.crt` file but not the `ca.key` file, if all other certificates and kubeconfig files
+   already are in place kubeadm recognize this condition and activates the ExternalCA , which also implies the `csrsigner`controller in
+   controller-manager won't be started
+3. If kubeadm is running in [external CA mode](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#external-ca-mode);
+   all the certificates must be provided by the user, because kubeadm cannot generate them by itself
+4. In case of kubeadm is executed in the `--dry-run` mode, certificates files are written in a temporary folder
+5. Certificate generation can be invoked individually with the [`kubeadm init phase certs all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-certs) command
+-->
+1. 如果证书和私钥对都存在，并且其内容经过评估符合上述规范，将使用现有文件，并且跳过给定证书的生成阶段。
+  这意味着用户可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.{crt,key}`，kubeadm 将使用这些文件对其余证书进行签名。
+  请参阅[使用自定义证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#custom-certificates)
+2. 仅对 CA 来说，如果所有其他证书和 kubeconfig 文件都已就位，则可以只提供 `ca.crt` 文件，而不提供 `ca.key` 文件。
+   kubeadm 已经识别出这种情况并启用 ExternalCA，这也意味着了控制器管理器中的 `csrsigner` 控制器将不会启动
+3. 如果 kubeadm 在[外部 CA 模式](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#external-ca-mode)下运行；
+   所有证书必须由用户提供，因为 kubeadm 无法自行生成它们
+4. 如果在 `--dry-run` 模式下执行 kubeadm，证书文件将写入一个临时文件夹中
+5. 可以使用 [`kubeadm init phase certs all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-certs) 
+   命令单独生成证书。
+
+<!-- ### Generate kubeconfig files for control plane components -->
+### 为控制平面组件生成 kubeconfig 文件  {#generate-kubeconfig-files-for-control-plane-components}
+
+<!-- 
+Kubeadm generates kubeconfig files with identities for control plane components:
+-->
+Kubeadm 生成具有用于控制平面组件身份标识的 kubeconfig 文件：
+
+<!--  
+- A kubeconfig file for the kubelet to use during TLS bootstrap - /etc/kubernetes/bootstrap-kubelet.conf. Inside this file there is a bootstrap-token or embedded client certificates for authenticating this node with the cluster.
+  This client cert should:
+    - Be in the `system:nodes` organization, as required by the [Node Authorization](/docs/reference/access-authn-authz/node/) module
+    - Have the Common Name (CN) `system:node:<hostname-lowercased>`
+- A kubeconfig file for controller-manager, `/etc/kubernetes/controller-manager.conf`; inside this file is embedded a client
+  certificate with controller-manager identity. This client cert should have the CN `system:kube-controller-manager`, as defined
+by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)
+- A kubeconfig file for scheduler, `/etc/kubernetes/scheduler.conf`; inside this file is embedded a client certificate with scheduler identity.
+  This client cert should have the CN `system:kube-scheduler`, as defined by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)
+-->
+- 供 kubelet 在 TLS 引导期间使用的 kubeconfig 文件——`/etc/kubernetes/bootstrap-kubelet.conf`。在此文件中，
+  有一个引导令牌或内嵌的客户端证书，向集群表明此节点身份。
+  此客户端证书应：
+    - 根据[节点鉴权](/zh/docs/reference/access-authn-authz/node/)模块的要求，属于 `system:nodes` 组织
+    - 具有通用名称（CN）：`system:node:<hostname-lowercased>`
+- 控制器管理器的 kubeconfig 文件——`/etc/kubernetes/controller-manager.conf`；
+  在此文件中嵌入了一个具有控制器管理器身份标识的客户端证书。
+  此客户端证书应具有 CN：`system:kube-controller-manager`，
+  这是由 [RBAC 核心组件角色](/zh/docs/reference/access-authn-authz/rbac/#core-component-roles)默认定义的。
+- 调度器的 kubeconfig 文件——`/etc/kubernetes/scheduler.conf`；在此文件中嵌入了具有调度器身份标识的客户端证书。
+  此客户端证书应具有 CN：`system:kube-scheduler`，
+  这是由 [RBAC 核心组件角色](/zh/docs/reference/access-authn-authz/rbac/#core-component-roles)默认定义的。
+
+<!-- 
+Additionally, a kubeconfig file for kubeadm itself and the admin is generated and saved into the `/etc/kubernetes/admin.conf` file.
+The "admin" here is defined as the actual person(s) that is administering the cluster and wants to have full control (**root**) over the cluster.
+The embedded client certificate for admin should be in the `system:masters` organization, as defined by default
+[RBAC user facing role bindings](/docs/reference/access-authn-authz/rbac/#user-facing-roles). It should also include a
+CN. Kubeadm uses the `kubernetes-admin` CN.
+-->
+另外，一个用于 kubeadm 本身和 admin 的 kubeconfig 文件也被生成并保存到 `/etc/kubernetes/admin.conf` 文件中。
+此处的 admin 定义为正在管理集群并希望完全控制集群（**root**）的实际人员。
+内嵌的 admin 客户端证书应是  `system:masters` 组织的成员，
+这是由默认的 [RBAC 面向用户的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#user-facing-roles)定义的。 
+它还应包括一个 CN。 Kubeadm 使用 `kubernetes-admin` CN。
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. `ca.crt` certificate is embedded in all the kubeconfig files.
+2. If a given kubeconfig file exists, and its content is evaluated compliant with the above specs, the existing file will be used and the generation phase for the given kubeconfig skipped
+3. If kubeadm is running in [ExternalCA mode](/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode), all the required kubeconfig must be provided by the user as well, because kubeadm cannot generate any of them by itself
+4. In case of kubeadm is executed in the `--dry-run` mode, kubeconfig files are written in a temporary folder
+5. Kubeconfig files generation can be invoked individually with the [`kubeadm init phase kubeconfig all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-kubeconfig) command
+-->
+1. `ca.crt` 证书内嵌在所有 kubeconfig 文件中。
+2. 如果给定的 kubeconfig 文件存在且其内容经过评估符合上述规范，则 kubeadm 将使用现有文件，并跳过给定 kubeconfig 的生成阶段
+3. 如果 kubeadm 以 [ExternalCA 模式](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#external-ca-mode)运行，
+   则所有必需的 kubeconfig 也必须由用户提供，因为 kubeadm 不能自己生成
+4. 如果在 `--dry-run` 模式下执行 kubeadm，则 kubeconfig 文件将写入一个临时文件夹中
+5. 可以使用 [`kubeadm init phase kubeconfig all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-kubeconfig)
+   命令分别生成 Kubeconfig 文件。
+
+<!-- ### Generate static Pod manifests for control plane components -->
+### 为控制平面组件生成静态 Pod 清单  {#generate-static-pod-manifests-for-control-plane-components}
+
+<!--  
+Kubeadm writes static Pod manifest files for control plane components to `/etc/kubernetes/manifests`. The kubelet watches this directory for Pods to create on startup.
+-->
+Kubeadm 将用于控制平面组件的静态 Pod 清单文件写入 `/etc/kubernetes/manifests` 目录。
+Kubelet 启动后会监视这个目录以便创建 Pod。
+
+<!-- Static Pod manifest share a set of common properties: -->
+静态 Pod 清单有一些共同的属性：
+
+<!--  
+- All static Pods are deployed on `kube-system` namespace
+- All static Pods get `tier:control-plane` and `component:{component-name}` labels
+- All static Pods use the `system-node-critical` priority class
+- `hostNetwork: true` is set on all static Pods to allow control plane startup before a network is configured; as a consequence:
+  * The `address` that the controller-manager and the scheduler use to refer the API server is `127.0.0.1`
+  * If using a local etcd server, `etcd-servers` address will be set to `127.0.0.1:2379`
+- Leader election is enabled for both the controller-manager and the scheduler
+- Controller-manager and the scheduler will reference kubeconfig files with their respective, unique identities
+- All static Pods get any extra flags specified by the user as described in [passing custom arguments to control plane components](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
+- All static Pods get any extra Volumes specified by the user (Host path)
+-->
+- 所有静态 Pod 都部署在 `kube-system` 命名空间
+- 所有静态 Pod 都打上 `tier:ontrol-plane` 和 `component:{component-name}` 标签
+- 所有静态 Pod 均使用 `system-node-critical` 优先级
+- 所有静态 Pod 都设置了 `hostNetwork:true`，使得控制平面在配置网络之前启动；结果导致：
+   * 控制器管理器和调度器用来调用 API 服务器的地址为 127.0.0.1。
+   * 如果使用本地 etcd 服务器，则 `etcd-servers` 地址将设置为 `127.0.0.1:2379`
+- 同时为控制器管理器和调度器启用了领导者选举
+- 控制器管理器和调度器将引用 kubeconfig 文件及其各自的唯一标识
+- 如[将自定义参数传递给控制平面组件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)中所述，
+  所有静态 Pod 都会获得用户指定的额外标志
+- 所有静态 Pod 都会获得用户指定的额外卷（主机路径）
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. All images will be pulled from k8s.gcr.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
+2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder
+3. Static Pod manifest generation for master components can be invoked individually with the [`kubeadm init phase control-plane all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command
+-->
+1. 所有镜像默认从 k8s.gcr.io 拉取。 
+   关于自定义镜像仓库，请参阅[使用自定义镜像](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)
+2. 如果在 `--dry-run` 模式下执行 kubeadm，则静态 Pod 文件写入一个临时文件夹中
+3. 可以使用 [`kubeadm init phase control-plane all`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) 
+   命令分别生成主控组件的静态 Pod 清单。
+
+<!-- #### API server -->
+#### API 服务器  {#api-server}
+
+<!-- 
+The static Pod manifest for the API server is affected by following parameters provided by the users: 
+-->
+API 服务器的静态 Pod 清单会受到用户提供的以下参数的影响:
+
+<!--  
+ - The `apiserver-advertise-address` and `apiserver-bind-port` to bind to; if not provided, those value defaults to the IP address of
+   the default network interface on the machine and port 6443
+ - The `service-cluster-ip-range` to use for services
+ - If an external etcd server is specified, the `etcd-servers` address and related TLS settings (`etcd-cafile`, `etcd-certfile`, `etcd-keyfile`);
+   if an external etcd server is not be provided, a local etcd will be used (via host network)
+ - If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with the  `--cloud-config` path
+   if such file exists (this is experimental, alpha and will be removed in a future version)
+-->
+- 要绑定的 `apiserver-advertise-address` 和 `apiserver-bind-port`；如果未提供，则这些值默认为机器上默认网络接口的 IP 地址和 6443 端口。
+  - `service-cluster-ip-range` 给 service 使用
+  - 如果指定了外部 etcd 服务器，则应指定 `etcd-servers` 地址和相关的 TLS 设置（`etcd-cafile`，`etcd-certfile`，`etcd-keyfile`）；
+    如果未提供外部 etcd 服务器，则将使用本地 etcd（通过主机网络）
+  - 如果指定了云提供商，则配置相应的 `--cloud-provider`，如果该路径存在，则配置 `--cloud-config`
+    （这是实验性的，是 Alpha 版本，将在以后的版本中删除）
+
+<!-- Other API server flags that are set unconditionally are: -->
+无条件设置的其他 API 服务器标志有：
+
+<!--  
+ - `--insecure-port=0` to avoid insecure connections to the api server
+ - `--enable-bootstrap-token-auth=true` to enable the `BootstrapTokenAuthenticator` authentication module.
+   See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details
+ - `--allow-privileged` to `true` (required e.g. by kube proxy)
+ - `--requestheader-client-ca-file` to `front-proxy-ca.crt`
+ - `--enable-admission-plugins` to:
+    - [`NamespaceLifecycle`](/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) e.g. to avoid deletion of
+      system reserved namespaces
+    - [`LimitRanger`](/docs/reference/access-authn-authz/admission-controllers/#limitranger) and [`ResourceQuota`](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) to enforce limits on namespaces
+    - [`ServiceAccount`](/docs/reference/access-authn-authz/admission-controllers/#serviceaccount) to enforce service account automation
+    - [`PersistentVolumeLabel`](/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) attaches region or zone labels to
+      PersistentVolumes as defined by the cloud provider (This admission controller is deprecated and will be removed in a future version.
+      It is not deployed by kubeadm by default with v1.9 onwards when not explicitly opting into using `gce` or `aws` as cloud providers)
+    - [`DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) to enforce default storage class on `PersistentVolumeClaim` objects
+    - [`DefaultTolerationSeconds`](/docs/reference/access-authn-authz/admission-controllers/#defaulttolerationseconds)
+    - [`NodeRestriction`](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) to limit what a kubelet can modify
+      (e.g. only pods on this node)
+ - `--kubelet-preferred-address-types` to `InternalIP,ExternalIP,Hostname;` this makes `kubectl logs` and other API server-kubelet
+   communication work in environments where the hostnames of the nodes aren't resolvable
+ - Flags for using certificates generated in previous steps:
+    - `--client-ca-file` to `ca.crt`
+    - `--tls-cert-file` to `apiserver.crt`
+    - `--tls-private-key-file` to `apiserver.key`
+    - `--kubelet-client-certificate` to `apiserver-kubelet-client.crt`
+    - `--kubelet-client-key` to `apiserver-kubelet-client.key`
+    - `--service-account-key-file` to `sa.pub`
+    - `--requestheader-client-ca-file` to`front-proxy-ca.crt`
+    - `--proxy-client-cert-file` to `front-proxy-client.crt`
+    - `--proxy-client-key-file` to `front-proxy-client.key`
+ - Other flags for securing the front proxy ([API Aggregation](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)) communications:
+    - `--requestheader-username-headers=X-Remote-User`
+    - `--requestheader-group-headers=X-Remote-Group`
+    - `--requestheader-extra-headers-prefix=X-Remote-Extra-`
+    - `--requestheader-allowed-names=front-proxy-client`
+-->
+ - `--insecure-port=0` 禁止到 API 服务器不安全的连接
+ - `--enable-bootstrap-token-auth=true` 启用 `BootstrapTokenAuthenticator` 身份验证模块
+   更多细节请参见 [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+ - `--allow-privileged` 设为 `true`（必要，例如 kube-proxy）
+ - `--requestheader-client-ca-file` 设为 `front-proxy-ca.crt`
+ - `--enable-admission-plugins` 设为：
+    - [`NamespaceLifecycle`](/zh/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) 
+      例如，避免删除系统保留的命名空间
+    - [`LimitRanger`](/zh/docs/reference/access-authn-authz/admission-controllers/#limitranger) 和
+      [`ResourceQuota`](/zh/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 对命名空间实施限制
+    - [`ServiceAccount`](/zh/docs/reference/access-authn-authz/admission-controllers/#serviceaccount) 实施服务账户自动化
+    - [`PersistentVolumeLabel`](/zh/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) 
+      将区域（Region）或区（Zone）标签附加到由云提供商定义的 PersistentVolumes（此准入控制器已被弃用并将在以后的版本中删除）。
+      如果未明确选择使用 `gce` 或 `aws` 作为云提供商，则默认情况下，v1.9 以后的版本 kubeadm 都不会部署。
+    - [`DefaultStorageClass`](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) 
+      在 `PersistentVolumeClaim` 对象上强制使用默认存储类型
+    - [`DefaultTolerationSeconds`](/zh/docs/reference/access-authn-authz/admission-controllers/#defaulttolerationseconds)
+    - [`NodeRestriction`](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 
+      限制 kubelet 可以修改的内容（例如，仅此节点上的 pod）
+ - `--kubelet-preferred-address-types` 设为 `InternalIP,ExternalIP,Hostname;` 
+   这使得在节点的主机名无法解析的环境中，`kubectl log` 和 API 服务器与 kubelet 的其他通信可以工作
+ - 使用在前面步骤中生成的证书的标志：
+    - `--client-ca-file` 设为 `ca.crt`
+    - `--tls-cert-file` 设为 `apiserver.crt`
+    - `--tls-private-key-file` 设为 `apiserver.key`
+    - `--kubelet-client-certificate` 设为 `apiserver-kubelet-client.crt`
+    - `--kubelet-client-key` 设为 `apiserver-kubelet-client.key`
+    - `--service-account-key-file` 设为 `sa.pub`
+    - `--requestheader-client-ca-file` 设为 `front-proxy-ca.crt`
+    - `--proxy-client-cert-file` 设为 `front-proxy-client.crt`
+    - `--proxy-client-key-file` 设为 `front-proxy-client.key`
+ - 其他用于保护前端代理（[API 聚合](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)）通信的标志:
+    - `--requestheader-username-headers=X-Remote-User`
+    - `--requestheader-group-headers=X-Remote-Group`
+    - `--requestheader-extra-headers-prefix=X-Remote-Extra-`
+    - `--requestheader-allowed-names=front-proxy-client`
+
+<!-- #### Controller manager -->
+#### 控制器管理器  {#controller-manager}
+
+<!-- 
+The static Pod manifest for the controller-manager is affected by following parameters provided by the users: 
+-->
+控制器管理器的静态 Pod 清单受用户提供的以下参数的影响:
+
+<!-- 
+- If kubeadm is invoked specifying a `--pod-network-cidr`, the subnet manager feature required for some CNI network plugins is enabled by
+   setting:
+   - `--allocate-node-cidrs=true`
+   - `--cluster-cidr` and `--node-cidr-mask-size` flags according to the given CIDR
+ - If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with the  `--cloud-config` path
+   if such configuration file exists (this is experimental, alpha and will be removed in a future version)
+-->
+- 如果调用 kubeadm 时指定了 `--pod-network-cidr` 参数，则可以通过以下方式启用某些 CNI 网络插件所需的子网管理器功能：
+    - 设置 `--allocate-node-cidrs=true`
+    - 根据给定 CIDR 设置 `--cluster-cidr` 和 `--node-cidr-mask-size` 标志
+  - 如果指定了云提供商，则指定相应的 `--cloud-provider`，如果存在这样的配置文件，则指定 `--cloud-config` 路径
+    （这是试验性的，是Alpha 版本，将在以后的版本中删除）
+
+<!-- Other flags that are set unconditionally are: -->
+其他无条件设置的标志包括：
+
+<!--  
+ - `--controllers` enabling all the default controllers plus `BootstrapSigner` and `TokenCleaner` controllers for TLS bootstrap.
+   See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details
+ - `--use-service-account-credentials` to `true`
+ - Flags for using certificates generated in previous steps:
+    - `--root-ca-file` to `ca.crt`
+    - `--cluster-signing-cert-file` to `ca.crt`, if External CA mode is disabled, otherwise to `""`
+    - `--cluster-signing-key-file` to `ca.key`, if External CA mode is disabled, otherwise to `""`
+    - `--service-account-private-key-file` to `sa.key`
+-->
+- `--controllers` 为 TLS 引导程序启用所有默认控制器以及 `BootstrapSigner` 和 `TokenCleaner` 控制器。
+    详细信息请参阅 [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+  - `--use-service-account-credentials` 设为 `true`
+  - 使用先前步骤中生成的证书的标志：
+     -`--root-ca-file` 设为 `ca.crt`
+     - 如果禁用了 External CA 模式，则 `--cluster-signing-cert-file` 设为 `ca.crt`，否则设为 `""`
+     - 如果禁用了 External CA 模式，则 `--cluster-signing-key-file` 设为 `ca.key`，否则设为 `""`
+     - `--service-account-private-key-file` 设为 `sa.key`
+
+<!-- #### Scheduler -->
+#### 调度器  {#scheduler}
+
+<!-- 
+The static Pod manifest for the scheduler is not affected by parameters provided by the users. 
+-->
+调度器的静态 Pod 清单不受用户提供的参数的影响。
+
+<!-- ### Generate static Pod manifest for local etcd -->
+### 为本地 etcd 生成静态 Pod 清单  {#generate-static-pod-manifest-for-local-etcd}
+
+<!--  
+If the user specified an external etcd this step will be skipped, otherwise kubeadm generates a static Pod manifest file for creating
+a local etcd instance running in a Pod with following attributes:
+-->
+如果用户指定了外部 etcd，则将跳过此步骤，否则 kubeadm 会生成静态 Pod 清单文件，以创建在 Pod 中运行的具有以下属性的本地 etcd 实例：
+
+<!--  
+- listen on `localhost:2379` and use `HostNetwork=true`
+- make a `hostPath` mount out from the `dataDir` to the host's filesystem
+- Any extra flags specified by the user
+-->
+- 在 `localhost:2379` 上监听并使用 `HostNetwork=true`
+- 将 `hostPath` 从 `dataDir` 挂载到主机的文件系统
+- 用户指定的任何其他标志
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. The etcd image will be pulled from `k8s.gcr.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
+2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder
+3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) command
+-->
+1. etcd 镜像默认从 `k8s.gcr.io` 拉取。有关自定义镜像仓库，请参阅[使用自定义镜像](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)
+2. 如果 kubeadm 以 `--dry-run` 模式执行，etcd 静态 Pod 清单将写入一个临时文件夹
+3. 可以使用 ['kubeadm init phase etcd local'](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) 命令
+   单独为本地 etcd 生成静态 Pod 清单
+
+<!-- ### Optional Dynamic Kubelet Configuration -->
+### 可选的动态 Kubelet 配置  {#optional-dynamic-kubelet-configuration}
+
+<!--  
+To use this functionality call `kubeadm alpha kubelet config enable-dynamic`. It writes the kubelet init configuration
+into `/var/lib/kubelet/config/init/kubelet` file.
+-->
+要使用这个功能，请调用 `kubeadm alpha kubelet config enable-dynamic`。
+它将 kubelet 的 init 配置写入 `/var/lib/kubelet/config/init/kubelet` 文件。
+
+<!--  
+The init configuration is used for starting the kubelet on this specific node, providing an alternative for the kubelet drop-in file;
+such configuration will be replaced by the kubelet base configuration as described in following steps.
+See [set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file) for additional info.
+-->
+init 配置用于在这个特定节点上启动 kubelet，从而为 kubelet 插件文件提供了一种替代方法。
+如以下步骤中所述，这种配置将由 kubelet 基本配置所替代。
+请参阅[通过配置文件设置 Kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file)了解更多信息。
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified
+   in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
+2. The kubelet configuration can be changed by passing a `KubeletConfiguration` object to `kubeadm init` or `kubeadm join` by using
+   a configuration file `--config some-file.yaml`. The `KubeletConfiguration` object can be separated from other objects such
+   as `InitConfiguration` using the `---` separator. For more details have a look at the `kubeadm config print-default` command.
+-->
+1. 要使动态 kubelet 配置生效，应在 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`
+   中指定 `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` 标志
+2. 通过使用配置文件 `--config some-file.yaml` 将 `KubeletConfiguration` 对象传递给 `kubeadm init` 或 `kubeadm join`
+   来更改 kubelet 配置。可以使用 `---` 分隔符将 `KubeletConfiguration` 对象与其他对象（例如 `InitConfiguration`）分开。
+   有关更多详细信息，请查看 `kubeadm config print-default` 命令。
+
+<!-- ### Wait for the control plane to come up -->
+### 等待控制平面启动  {#wait-for-the-control-plane-to-come-up}
+
+<!--  
+kubeadm waits (upto 4m0s) until `localhost:6443/healthz` (kube-apiserver liveness) returns `ok`. However in order to detect
+deadlock conditions, kubeadm fails fast if `localhost:10255/healthz` (kubelet liveness) or
+`localhost:10255/healthz/syncloop` (kubelet readiness) don't return `ok` within 40s and 60s respectively.
+-->
+kubeadm 等待（最多 4m0s），直到 `localhost:6443/healthz`（kube-apiserver 存活）返回 `ok`。 
+但是为了检测死锁条件，如果 `localhost:10255/healthz`（kubelet 存活）或
+`localhost:10255/healthz/syncloop`（kubelet 就绪）未能在 40s 和 60s 内未返回 `ok`，则 kubeadm 会快速失败。
+
+<!--  
+kubeadm relies on the kubelet to pull the control plane images and run them properly as static Pods.
+After the control plane is up, kubeadm completes the tasks described in following paragraphs.
+-->
+kubeadm 依靠 kubelet 拉取控制平面镜像并将其作为静态 Pod 正确运行。
+控制平面启动后，kubeadm 将完成以下段落中描述的任务。
+
+<!-- ### (optional) Write base kubelet configuration -->
+### （可选）编写基本 kubelet 配置  {#write-base-kubelet-configuration}
+
+{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
+
+<!-- If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: -->
+如果带 `--feature-gates=DynamicKubeletConfig` 参数调用 kubeadm：
+
+<!--  
+1. Write the kubelet base configuration into the `kubelet-base-config-v1.9` ConfigMap in the `kube-system` namespace
+2. Creates RBAC rules for granting read access to that ConfigMap to all bootstrap tokens and all kubelet instances
+   (that is `system:bootstrappers:kubeadm:default-node-token` and `system:nodes` groups)
+3. Enable the dynamic kubelet configuration feature for the initial control-plane node by pointing `Node.spec.configSource` to the newly-created ConfigMap
+-->
+1. 将 kubelet 基本配置写入 `kube-system` 命名空间的 `kubelet-base-config-v1.9` ConfigMap 中。
+2. 创建 RBAC 规则，以授予对所有引导令牌和所有 kubelet 实例对该 ConfigMap 的读取访问权限
+  （即 `system:bootstrappers:kubeadm:default-node-token` 组和 `system:nodes` 组）
+3. 通过将 `Node.spec.configSource` 指向新创建的 ConfigMap，为初始控制平面节点启用动态 kubelet 配置功能。
+
+<!-- ### Save the kubeadm ClusterConfiguration in a ConfigMap for later reference -->
+### 将 kubeadm ClusterConfiguration 保存在 ConfigMap 中以供以后参考  {#save-the-kubeadm-clusterConfiguration-in-a-configMap-for-later-reference}
+
+<!-- 
+kubeadm saves the configuration passed to `kubeadm init` in a ConfigMap named `kubeadm-config` under `kube-system` namespace. 
+-->
+kubeadm 将传递给 `kubeadm init` 的配置保存在 `kube-system` 命名空间下名为 `kubeadm-config` 的 ConfigMap 中。
+
+<!--  
+This will ensure that kubeadm actions executed in future (e.g `kubeadm upgrade`) will be able to determine the actual/current cluster
+state and make new decisions based on that data.
+-->
+这将确保将来执行的 kubeadm 操作（例如 `kubeadm upgrade`）将能够确定实际/当前集群状态，并根据该数据做出新的决策。
+
+<!-- Please note that: -->
+请注意：
+
+<!-- 
+1. Before saving the ClusterConfiguration, sensitive information like the token is stripped from the configuration
+2. Upload of master configuration can be invoked individually with the [`kubeadm init phase upload-config`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) command
+-->
+1. 在保存 ClusterConfiguration 之前，从配置中删除令牌等敏感信息。
+2. 可以使用 [`kubeadm init phase upload-config`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) 
+   命令单独上传主控节点配置。
+
+<!-- ### Mark the node as control-plane -->
+### 将节点标记为控制平面  {#mark-the-node-as-control-plane}
+
+<!-- As soon as the control plane is available, kubeadm executes following actions: -->
+一旦控制平面可用，kubeadm 将执行以下操作：
+
+<!-- 
+- Labels the node as control-plane with `node-role.kubernetes.io/master=""`
+- Taints the node with `node-role.kubernetes.io/master:NoSchedule`
+-->
+- 给节点打上 `node-role.kubernetes.io/master=""` 标签，标记为控制平面
+- 给节点打上 `node-role.kubernetes.io/master:NoSchedule` 污点
+
+<!-- Please note that: -->
+请注意：
+
+<!-- 
+1. Mark control-plane phase can be invoked individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-master) command
+-->
+1. 可以使用 [`kubeadm init phase mark-control-plane`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-master) 
+  命令单独触发控制平面标记
+
+<!-- ### Configure TLS-Bootstrapping for node joining -->c
+### 为即将加入的节点加入 TLS 启动引导  {#configure-tls-bootstrapping-for-node-joining}
+
+<!--
+Kubeadm uses [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) for joining new nodes to an
+existing cluster; for more details see also [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
+-->
+
+Kubeadm 使用[引导令牌认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)将新节点连接到现有集群；
+有关更多详细信息，请参见[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md)。
+
+<!-- 
+`kubeadm init` ensures that everything is properly configured for this process, and this includes following steps as well as
+setting API server and controller flags as already described in previous paragraphs.
+-->
+`kubeadm init` 确保为该过程正确配置了所有内容，这包括以下步骤以及设置 API 服务器和控制器标志，如前几段所述。
+
+<!-- Please note that: -->
+请注意：
+
+<!-- 
+1. TLS bootstrapping for nodes can be configured with the [`kubeadm init phase bootstrap-token`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token)
+   command, executing all the configuration steps described in following paragraphs; alternatively, each step can be invoked individually
+-->
+1. 可以使用 [`kubeadm init phase bootstrap-token`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-bootstrap-token) 
+   命令配置节点的 TLS 引导，执行以下段落中描述的所有配置步骤；或者每个步骤都单独触发。
+
+<!-- #### Create a bootstrap token -->
+#### 创建引导令牌  {#create-a-bootstrap-token}
+
+<!--  
+`kubeadm init` create a first bootstrap token, either generated automatically or provided by the user with the `--token` flag; as documented
+in bootstrap token specification, token should be saved as secrets with name `bootstrap-token-<token-id>` under `kube-system` namespace.
+-->
+`kubeadm init` 创建第一个引导令牌，该令牌是自动生成的或由用户提供的 `--token` 标志的值；如引导令牌规范中记录的那样，
+令牌应保存在 `kube-system` 命名空间下名为 `bootstrap-token-<token-id>` 的 secret 中。
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. The default token created by `kubeadm init` will be used to validate temporary user during TLS bootstrap process; those users will
+   be member of  `system:bootstrappers:kubeadm:default-node-token` group
+2. The token has a limited validity, default 24 hours (the interval may be changed with the `—token-ttl` flag)
+3. Additional tokens can be created with the [`kubeadm token`](/docs/reference/setup-tools/kubeadm/kubeadm-token/) command, that provide as well other useful functions
+   for token management
+-->
+1. 由 `kubeadm init` 创建的默认令牌将用于在 TLS 引导过程中验证临时用户；
+   这些用户会成为 `system:bootstrappers:kubeadm:default-node-token` 组的成员
+2. 令牌的有效期有限，默认为 24 小时（间隔可以通过 `-token-ttl` 标志进行更改）
+3. 可以使用 [`kubeadm token`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 命令创建其他令牌，
+   这些令牌还提供其他有用的令牌管理功能
+
+<!-- #### Allow joining nodes to call CSR API -->
+#### 允许加入的节点调用 CSR API  {#allow-joining-nodes-to-call-csr-api}
+
+<!-- Kubeadm ensures that users in  `system:bootstrappers:kubeadm:default-node-token` group are able to access the certificate signing API. -->
+Kubeadm 确保 `system:bootstrappers:kubeadm:default-node-token` 组中的用户能够访问证书签名 API。
+
+<!-- 
+This is implemented by creating a ClusterRoleBinding named `kubeadm:kubelet-bootstrap` between the group above and the default
+RBAC role `system:node-bootstrapper`.
+-->
+这是通过在上述组与默认 RBAC 角色 `system:node-bootstrapper` 之间创建名为 `kubeadm:kubelet-bootstrap` 的 ClusterRoleBinding 来实现的。
+
+
+<!-- #### Setup auto approval for new bootstrap tokens -->
+#### 为新的引导令牌设置自动批准  {#setup-auto-approval-for-new-bootstrap-tokens}
+
+<!-- Kubeadm ensures that the Bootstrap Token will get its CSR request automatically approved by the csrapprover controller.-->
+Kubeadm 确保 csrapprover 控制器自动批准引导令牌的 CSR 请求。
+
+<!-- 
+This is implemented by creating ClusterRoleBinding named `kubeadm:node-autoapprove-bootstrap` between
+the  `system:bootstrappers:kubeadm:default-node-token` group and the default role `system:certificates.k8s.io:certificatesigningrequests:nodeclient`.
+-->
+这是通过在 `system:bootstrappers:kubeadm:default-node-token` 组和 `system:certificates.k8s.io:certificatesigningrequests:nodeclient` 默认角色之间
+创建名为 `kubeadm:node-autoapprove-bootstrap` 的 ClusterRoleBinding 来实现的。
+
+<!-- 
+The role `system:certificates.k8s.io:certificatesigningrequests:nodeclient` should be created as well, granting
+POST permission to `/apis/certificates.k8s.io/certificatesigningrequests/nodeclient`.
+-->
+还应创建 `system:certificates.k8s.io:certificatesigningrequests:nodeclient` 角色，
+对 `/apis/certificates.k8s.io/certificatesigningrequests/nodeclient` 授予的 POST 权限。
+
+<!-- #### Setup nodes certificate rotation with auto approval -->
+#### 通过自动批准设置节点证书轮换 {#setup-nodes-certificate-rotation-with-auto-approval} 
+
+<!-- 
+Kubeadm ensures that certificate rotation is enabled for nodes, and that new certificate request for nodes will get its CSR request
+automatically approved by the csrapprover controller. 
+-->
+Kubeadm 确保节点启用了证书轮换，csrapprover 控制器将自动批准节点的新证书的 CSR 请求。
+
+<!-- 
+This is implemented by creating ClusterRoleBinding named `kubeadm:node-autoapprove-certificate-rotation` between the  `system:nodes` group
+and the default role `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`.
+-->
+这是通过在 `system:nodes` 组和 `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient` 默认角色之间创建名叫
+`kubeadm:node-autoapprove-certificate-rotation` 的 ClusterRoleBinding 实现的。
+
+<!-- #### Create the public cluster-info ConfigMap -->
+#### 创建公共 cluster-info ConfigMap
+
+<!-- This phase creates the `cluster-info` ConfigMap in the `kube-public` namespace. -->
+本步骤在 `kube-public` 命名空间中创建名为 `cluster-info` 的 ConfigMap。
+
+<!--  
+Additionally it creates a Role and a RoleBinding granting access to the ConfigMap for unauthenticated users
+(i.e. users in RBAC group `system:unauthenticated`).
+-->
+另外，它创建一个 Role 和一个 RoleBinding，为未经身份验证的用户授予对 ConfigMap 的访问权限
+（即 RBAC 组 `system:unauthenticated` 中的用户）。
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. The access to the `cluster-info` ConfigMap _is not_ rate-limited. This may or may not be a problem if you expose your master
+to the internet; worst-case scenario here is a DoS attack where an attacker uses all the in-flight requests the kube-apiserver
+can handle to serving the `cluster-info` ConfigMap.
+-->
+1. 对 `cluster-info` ConfigMap 的访问 _不受_ 速率限制。如果你把主控节点暴露到外网，这可能是一个问题，也可能不是；
+这里最坏的情况是 DoS 攻击，攻击者使用 kube-apiserver 能够处理的所有动态请求来为 `cluster-info` ConfigMap 提供服务。
+
+<!-- ### Install addons -->
+### 安装插件  {##install-addons}
+
+<!-- Kubeadm installs the internal DNS server and the kube-proxy addon components via the API server. -->
+Kubeadm 通过 API 服务器安装内部 DNS 服务器和 kube-proxy 插件。
+
+<!-- Please note that: -->
+请注意：
+
+<!-- 
+1. This phase can be invoked individually with the [`kubeadm init phase addon all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) command. 
+-->
+
+1. 此步骤可以调用 ['kubeadm init phase addon all'](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) 命令单独调用。
+
+<!-- #### proxy -->
+#### 代理  {#proxy}
+
+<!-- 
+A ServiceAccount for `kube-proxy` is created in the `kube-system` namespace; then kube-proxy is deployed as a DaemonSet: 
+-->
+在 `kube-system` 命名空间中创建一个用于 `kube-proxy` 的 ServiceAccount；然后以 DaemonSet 的方式部署 kube-proxy：
+
+<!--  
+- The credentials (`ca.crt` and `token`) to the master come from the ServiceAccount
+- The location of the master comes from a ConfigMap
+- The `kube-proxy` ServiceAccount is bound to the privileges in the `system:node-proxier` ClusterRole
+-->
+- 主控节点凭据（`ca.crt` 和 `token`）来自 ServiceAccount
+- 主控节点的位置来自 ConfigMap
+- `kube-proxy` 的 ServiceAccount 绑定了 `system:node-proxier` ClusterRole 中的特权
+
+#### DNS  {#dns}
+
+<!--  
+- In Kubernetes version 1.18 kube-dns usage with kubeadm is deprecated and will be removed in a future release
+- The CoreDNS service is named `kube-dns`. This is done to prevent any interruption
+in service when the user is switching the cluster DNS from kube-dns to CoreDNS or vice-versa
+the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)
+- A ServiceAccount for CoreDNS/kube-dns is created in the `kube-system` namespace.
+- The `kube-dns` ServiceAccount is bound to the privileges in the `system:kube-dns` ClusterRole
+-->
+- 在 Kubernetes 1.18 版本中，通过 kubeadm 部署 kube-dns 这一操作已经弃用，将在未来的版本中删除
+- CoreDNS 服务的名称为 `kube-dns`。这样做是为了防止当用户将集群 DNS 从 kube-dns 切换到 CoreDNS 或者反过来时，出现服务中断。
+  `--config` 方法在[这里](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)有描述
+- 在 `kube-system` 命名空间中创建 CoreDNS/kube-dns 的 ServiceAccount
+- `kube-dns` 的 ServiceAccount 绑定了 `system:kube-dns` ClusterRole 中的特权
+
+<!-- ## kubeadm join phases internal design -->
+## kubeadm join 步骤内部设计  {#kubeadm-join-phases-internal-design}
+
+<!-- 
+Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a sequence of atomic work tasks to perform. 
+-->
+与 `kubeadm init` 类似，`kubeadm join` 内部工作流由一系列待执行的原子工作任务组成。
+
+<!-- 
+This is split into discovery (having the Node trust the Kubernetes Master) and TLS bootstrap (having the Kubernetes Master trust the Node). 
+-->
+这分为发现（让该节点信任 Kubernetes 的主控节点）和 TLS 引导（让 Kubernetes 的主控节点信任该节点）。
+
+<!-- 
+see [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) or the corresponding [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md). 
+-->
+请参阅[使用引导令牌进行身份验证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
+或相应的[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md)。
+
+<!-- ### Preflight checks -->
+### 预检  {#preflight-checks}
+
+<!-- 
+`kubeadm` executes a set of preflight checks before starting the join, with the aim to verify preconditions and avoid common
+cluster startup problems.
+-->
+`kubeadm` 在开始执行之前执行一组预检，目的是验证先决条件，避免常见的集群启动问题。
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1. `kubeadm join` preflight checks are basically a subset `kubeadm init` preflight checks
+1. Starting from 1.9, kubeadm provides better support for CRI-generic functionality; in that case, docker specific controls
+   are skipped or replaced by similar controls for crictl.
+1. Starting from 1.9, kubeadm provides support for joining nodes running on Windows; in that case, linux specific controls are skipped.
+1. In any case the user can skip specific preflight checks (or eventually all preflight checks) with the `--ignore-preflight-errors` option.
+-->
+1. `kubeadm join` 预检基本上是 `kubeadm init` 预检的一个子集
+2. 从 1.9 开始，kubeadm 为 CRI 通用的功能提供了更好的支持；在这种情况下，docker 特定的控制参数将跳过或替换为 crictl 中与之相似的控制参数。
+3. 从 1.9 开始，kubeadm 支持加入在 Windows 上运行的节点；在这种情况下，将跳过 linux 特定的控制参数。
+4. 在任何情况下，用户都可以通过 `--ignore-preflight-errors` 选项跳过特定的预检（或者进而跳过所有预检）。
+
+<!-- ### Discovery cluster-info -->
+### 发现 cluster-info  {#discovery-cluster-info}
+
+<!--  
+There are 2 main schemes for discovery. The first is to use a shared token along with the IP address of the API server.
+The second is to provide a file (that is a subset of the standard kubeconfig file).
+-->
+主要有两种发现方案。第一种是使用一个共享令牌以及 API 服务器的 IP 地址。
+第二种是提供一个文件（它是标准 kubeconfig 文件的子集）。
+
+<!-- #### Shared token discovery -->
+#### 共享令牌发现  {#shared-token-discovery}
+
+<!--  
+If `kubeadm join` is invoked with `--discovery-token`, token discovery is used; in this case the node basically retrieves
+the cluster CA certificates from the  `cluster-info` ConfigMap in the `kube-public` namespace.
+-->
+如果带 `--discovery-token` 参数调用 `kubeadm join`，则使用了令牌发现功能；
+在这种情况下，节点基本上从  `kube-public` 命名空间中的 `cluster-info` ConfigMap 中检索集群 CA 证书。
+
+<!-- In order to prevent "man in the middle" attacks, several steps are taken: -->
+为了防止“中间人”攻击，采取了以下步骤：
+
+<!--  
+- First, the CA certificate is retrieved via insecure connection (this is possible because `kubeadm init` granted access to  `cluster-info` users for `system:unauthenticated` )
+- Then the CA certificate goes trough following validation steps:
+  - Basic validation: using the token ID against a JWT signature
+  - Pub key validation: using provided `--discovery-token-ca-cert-hash`. This value is available in the output of `kubeadm init` or can
+    be calculated using standard tools (the hash is calculated over the bytes of the Subject Public Key Info (SPKI) object as in RFC7469).
+    The `--discovery-token-ca-cert-hash flag` may be repeated multiple times to allow more than one public key.
+  - As a additional validation, the CA certificate is retrieved via secure connection and then compared with the CA retrieved initially
+-->
+- 首先，通过不安全连接检索 CA 证书（这是可能的，因为 `kubeadm init` 授予 `system:unauthenticated` 的用户对 `cluster-info` 访问权限）
+- 然后 CA 证书通过以下验证步骤：
+  - 基本验证：使用令牌 ID 而不是 JWT 签名
+  - 公钥验证：使用提供的 `--discovery-token-ca-cert-hash`。这个值来自 `kubeadm init` 的输出，
+    或者可以使用标准工具计算（哈希值是按 RFC7469 中主体公钥信息（SPKI）对象的字节计算的）
+    `--discovery-token-ca-cert-hash` 标志可以重复多次，以允许多个公钥。
+  - 作为附加验证，通过安全连接检索 CA 证书，然后与初始检索的 CA 进行比较
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+1.  Pub key validation can be skipped passing `--discovery-token-unsafe-skip-ca-verification` flag; This weakens the kubeadm security
+    model since others can potentially impersonate the Kubernetes Master.
+-->
+1. 通过 `--discovery-token-unsafe-skip-ca-verification` 标志可以跳过公钥验证；
+   这削弱了 kubeadm 安全模型，因为其他人可能冒充 Kubernetes 主控节点。
+
+<!-- #### File/https discovery -->
+#### 文件/HTTPS 发现  {#file-or-https-discovery}
+
+<!-- 
+If `kubeadm join` is invoked with `--discovery-file`, file discovery is used; this file can be a local file or downloaded via an HTTPS URL; in case of HTTPS, the host installed CA bundle is used to verify the connection. 
+-->
+如果带 `--discovery-file` 参数调用 `kubeadm join`，则使用文件发现功能；
+该文件可以是本地文件或通过 HTTPS URL 下载；对于 HTTPS，主机安装的 CA 包用于验证连接。
+
+<!--  
+With file discovery, the cluster CA certificates is provided into the file itself; in fact, the discovery file is a kubeconfig
+file with only `server` and `certificate-authority-data` attributes set, as described in [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/#file-or-https-based-discovery) reference doc;
+when the connection with the cluster is established, kubeadm try to access the `cluster-info` ConfigMap, and if available, uses it.
+-->
+通过文件发现，集群 CA 证书是文件本身提供；事实上，这个发现文件是一个 kubeconfig 文件，只设置了 `server` 和 `certificate-authority-data` 属性，
+如 [`kubeadm join`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/#file-or-https-based-discovery) 参考文档中所述;
+当与集群建立连接时，kubeadm 尝试访问 `cluster-info` ConfigMap，如果可用，就使用它。
+
+<!-- ## TLS Bootstrap -->
+## TLS 引导  {#tls-boostrap}
+
+<!--  
+Once the cluster info are known, the file `bootstrap-kubelet.conf` is written, thus allowing kubelet to do TLS Bootstrapping
+(conversely until v.1.7 TLS bootstrapping were managed by kubeadm).
+-->
+知道集群信息后，将写入文件 `bootstrap-kubelet.conf`，从而允许 kubelet 执行 TLS 引导（相反，在 v1.7 之前 TLS 引导都是由 kubeadm 管理）。
+
+<!--  
+The TLS bootstrap mechanism uses the shared token to temporarily authenticate with the Kubernetes Master to submit a certificate
+signing request (CSR) for a locally created key pair.
+-->
+TLS 引导机制使用共享令牌对 Kubernetes 主控节点进行临时身份验证，以便为本地创建的密钥对提交证书签名请求（CSR）。
+
+<!--  
+The request is then automatically approved and the operation completes saving `ca.crt` file and `kubelet.conf` file to be used
+by kubelet for joining the cluster, while`bootstrap-kubelet.conf` is deleted.
+-->
+该请求会被自动批准，并且该操作保存 `ca.crt` 文件和 `kubelet.conf` 文件，用于 kubelet 加入集群，同时删除 `bootstrap-kubelet.conf`。
+
+<!-- Please note that: -->
+请注意：
+
+<!--  
+- The temporary authentication is validated against the token saved during the `kubeadm init` process (or with additional tokens
+  created with `kubeadm token`)
+- The temporary authentication resolve to a user member of  `system:bootstrappers:kubeadm:default-node-token` group which was granted
+  access to CSR api during the `kubeadm init` process
+- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
+-->
+- 临时身份验证根据 `kubeadm init` 过程中保存的令牌进行验证（或者使用 `kubeadm token` 创建的其他令牌）
+- 临时身份验证解析到 `system:bootstrappers:kubeadm:default-node-token` 组的一个用户成员，
+  该成员在 `kubeadm init` 过程中被授予对 CSR API 的访问权
+- 根据 `kubeadm init` 过程的配置，自动 CSR 审批由 csrapprover 控制器管理
+
+<!-- ### (optional) Write init kubelet configuration -->
+### （可选）编写 init kubelet 配置  {#write-init-kubelet-configuration}
+
+{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
+
+<!-- If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: -->
+如果带 `--feature-gates=DynamicKubeletConfig` 参数调用 kubeadm：
+
+<!--  
+1. Read the kubelet base configuration from the `kubelet-base-config-v1.9` ConfigMap in the `kube-system` namespace  using the
+   Bootstrap Token credentials, and write it to disk as kubelet init configuration file  `/var/lib/kubelet/config/init/kubelet`
+2. As soon as kubelet starts with the Node's own credential (`/etc/kubernetes/kubelet.conf`), update current node configuration
+   specifying that the source for the node/kubelet configuration is the above ConfigMap.
+-->
+1. 使用引导令牌凭证从 `kube-system` 命名空间中 `kubelet-base-config-v1.9` ConfigMap 中读取 kubelet 基本配置，
+   并将其作为 kubelet init 配置文件 `/var/lib/kubelet/config/init/kubelet` 写入磁盘。
+2. 一旦 kubelet 开始使用节点自己的凭据（`/etc/kubernetes/kubelet.conf`），
+   就更新当前节点配置，指定该节点或 kubelet 配置来自上述 ConfigMap。
+
+<!-- Please note that: -->
+请注意：
+
+<!-- 
+1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 
+-->
+1. 要使动态 kubelet 配置生效，应在 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 中指定 `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` 标志。
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
index 856bd9fd21..313f47edb9 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
@@ -1,5 +1,6 @@
 ---
 title: kubeadm alpha
+content_type: concept
 weight: 90
 ---
 <!--
@@ -9,6 +10,7 @@ reviewers:
 - luxas
 - jbeda
 title: kubeadm alpha
+content_type: concept
 weight: 90
 ---
 -->
@@ -84,15 +86,13 @@ The `user` subcommand can be used for the creation of kubeconfig files for addit
 ## kubeadm alpha kubelet config {#cmd-phase-kubelet}
 
 <!--
-Use the following commands to either download the kubelet configuration from the cluster or
-to enable the DynamicKubeletConfiguration feature.
+Use the following command to enable the DynamicKubeletConfiguration feature.
 -->
-使用以下命令从集群中下载 kubelet 配置或启用 DynamicKubeletConfiguration 功能。
+使用以下命令启用 DynamicKubeletConfiguration 功能。
 
 {{< tabs name="tab-kubelet" >}}
 {{< tab name="kubelet" include="generated/kubeadm_alpha_kubelet.md" />}}
-{{< tab name="download" include="generated/kubeadm_alpha_kubelet_config_download.md" />}}
-{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_download.md" />}}
+{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}}
 {{< /tabs >}}
 
 
@@ -113,11 +113,8 @@ The subcommand `pivot` can be used to convert a static Pod-hosted control plane
 {{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}}
 {{< /tabs >}}
 
+## {{% heading "whatsnext" %}}
 
-<!--
-## What's next
--->
-## 接下来
 <!--
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
index ced5ab1ec7..70f058f594 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md
@@ -1,11 +1,13 @@
 ---
 title: kubeadm init phase
 weight: 90
+content_type: concept
 ---
 <!--
 ---
 title: kubeadm init phase
 weight: 90
+content_type: concept
 ---
 -->
 
@@ -260,14 +262,14 @@ For more details on each field in the `v1beta2` configuration you can navigate t
 -->
 有关 `v1beta2` 配置中每个字段的更多详细信息，可以访问 [API](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)。
 
+## {{% heading "whatsnext" %}}
+
 <!--
-## What's next
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
 * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality
 -->
-## 接下来
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index b975d3df60..50042ea558 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -5,7 +5,6 @@ weight: 20
 ---
 
 <!--
----
 reviewers:
 - mikedanese
 - luxas
@@ -13,9 +12,9 @@ reviewers:
 title: kubeadm init
 content_type: concept
 weight: 20
----
 -->
 <!-- overview -->
+
 <!--
 This command initializes a Kubernetes control-plane node.
 -->
@@ -30,34 +29,52 @@ This command initializes a Kubernetes control-plane node.
 ### Init workflow {#init-workflow}
 -->
 ### Init 命令的工作流程 {#init-workflow}
+
 <!--
 `kubeadm init` bootstraps a Kubernetes control-plane node by executing the
 following steps:
 -->
 `kubeadm init` 命令通过执行下列步骤来启动一个 Kubernetes 控制平面节点。
 
-<!-- 1. Runs a series of pre-flight checks to validate the system state
+<!--
+1. Runs a series of pre-flight checks to validate the system state
    before making changes. Some checks only trigger warnings, others are
    considered errors and will exit kubeadm until the problem is corrected or the
-   user specifies `--ignore-preflight-errors=<list-of-errors>`.  -->
-1.  在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告，其它的则会被视为错误并且退出 kubeadm，除非问题得到解决或者用户指定了 `--ignore-preflight-errors=<list-of-errors>` 参数。
-<!-- 2. Generates a self-signed CA (or using an existing one if provided) to set up
+   user specifies `-ignore-preflight-errors=<list-of-errors>`.
+-->
+1. 在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告，
+   其它的则会被视为错误并且退出 kubeadm，除非问题得到解决或者用户指定了
+   `--ignore-preflight-errors=<list-of-errors>` 参数。
+
+<!--
+2. Generates a self-signed CA (or using an existing one if provided) to set up
    identities for each component in the cluster. If the user has provided their
-   own CA cert and/or key by dropping it in the cert directory configured via `--cert-dir`
+   own CA cert and/or key by dropping it in the cert directory configured via `-cert-dir`
    (`/etc/kubernetes/pki` by default) this step is skipped as described in the
    [Using custom certificates](#custom-certificates) document.
-   The APIServer certs will have additional SAN entries for any `--apiserver-cert-extra-sans` arguments, lowercased if necessary. -->
+   The APIServer certs will have additional SAN entries for any `-apiserver-cert-extra-sans` arguments, lowercased if necessary.
+-->
+2. 生成一个自签名的 CA 证书 (或者使用现有的证书，如果提供的话) 来为集群中的每一个组件建立身份标识。
+   如果用户已经通过 `--cert-dir` 配置的证书目录（默认为 `/etc/kubernetes/pki`）提供了他们自己的
+   CA 证书以及/或者密钥，那么将会跳过这个步骤，正如文档[使用自定义证书](#custom-certificates)所述。
+   如果指定了 `--apiserver-cert-extra-sans` 参数, APIServer 的证书将会有额外的 SAN 条目，
+   如果必要的话，将会被转为小写。
 
-2.  生成一个自签名的 CA 证书 (或者使用现有的证书，如果提供的话) 来为集群中的每一个组件建立身份标识。如果用户已经通过 `--cert-dir` 配置的证书目录（默认为 `/etc/kubernetes/pki`）提供了他们自己的 CA 证书以及/或者密钥， 那么将会跳过这个步骤，正如文档[使用自定义证书](#custom-certificates)所述。如果指定了 `--apiserver-cert-extra-sans` 参数, APIServer 的证书将会有额外的 SAN 条目，如果必要的话，将会被转为小写。
-<!-- 3. Writes kubeconfig files in `/etc/kubernetes/`  for
+<!--
+3. Writes kubeconfig files in `/etc/kubernetes/`  for
    the kubelet, the controller-manager and the scheduler to use to connect to the
    API server, each with its own identity, as well as an additional
-   kubeconfig file for administration named `admin.conf`. -->
+   kubeconfig file for administration named `admin.conf`.
+-->
+3. 将 kubeconfig 文件写入 `/etc/kubernetes/` 目录以便 kubelet、控制器管理器和调度器用来连接到
+   API 服务器，它们每一个都有自己的身份标识，同时生成一个名为 `admin.conf` 的独立的 kubeconfig
+   文件，用于管理操作。
 
-3.  将 kubeconfig 文件写入 `/etc/kubernetes/` 目录以便 kubelet、控制器管理器和调度器用来连接到 API 服务器，它们每一个都有自己的身份标识，同时生成一个名为 `admin.conf` 的独立的 kubeconfig 文件，用于管理操作。
-<!-- 4. Generates static Pod manifests for the API server,controller-manager and scheduler. In case an external etcd is not provided,an additional static Pod manifest is generated for etcd. -->
-
-4.  为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd 服务的话，也会为 etcd 生成一份额外的静态 Pod 清单文件。
+<!--
+4. Generates static Pod manifests for the API server,controller-manager and scheduler. In case an external etcd is not provided,an additional static Pod manifest is generated for etcd.
+-->
+4. 为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd
+   服务的话，也会为 etcd 生成一份额外的静态 Pod 清单文件。
 
 <!--
 Static Pod manifests are written to `/etc/kubernetes/manifests`; the kubelet watches this directory for Pods to create on startup.
@@ -68,15 +85,29 @@ Once control plane Pods are up and running, the `kubeadm init` sequence can cont
 
 一旦控制平面的 Pod 都运行起来， `kubeadm init` 的工作流程就继续往下执行。
 
-<!-- 1. Apply labels and taints to the control-plane node so that no additional workloads will
-run there. -->1.  对控制平面节点应用 labels 和 taints 标记以便不会在它上面运行其它的工作负载。
+<!--
+1. Apply labels and taints to the control-plane node so that no additional workloads will
+run there.
+-->
+1. 对控制平面节点应用 labels 和 taints 标记以便不会在它上面运行其它的工作负载。
 
-<!-- 2. Generates the token that additional nodes can use to register themselves with a control-plane in the future. Optionally, the user can provide a token via `--token`, as described in the [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) docs. -->2.  生成令牌以便其它节点以后可以使用这个令牌向控制平面节点注册它们自己。(可选)，用户可以通过 `--token` 提供一个令牌，正如文档 [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 所述。
+<!--
+2. Generates the token that additional nodes can use to register themselves with a control-plane in the future. Optionally, the user can provide a token via `-token`, as described in the [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) docs.
+-->
+2. 生成令牌以便其它节点以后可以使用这个令牌向控制平面节点注册它们自己。
+   (可选)，用户可以通过 `--token` 提供一个令牌，正如文档
+   [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 所述。
 
-<!-- 3. Makes all the necessary configurations for allowing node joining with the [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and [TLS Bootstrap](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) mechanism:
+<!--
+3. Makes all the necessary configurations for allowing node joining with the [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and [TLS Bootstrap](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) mechanism:
 - Write a ConfigMap for making available all the information required for joining, and set up related RBAC access rules.
 - Let Bootstrap Tokens access the CSR signing API.
-- Configure auto-approval for new CSR requests. -->3.  为了使得节点能够遵照 [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) 和 [TLS Bootstrap](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 这两份文档中描述的机制加入到集群中，kubeadm 会执行所有的必要配置：
+- Configure auto-approval for new CSR requests.
+-->
+3. 为了使得节点能够遵照[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)
+   和 [TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+   这两份文档中描述的机制加入到集群中，kubeadm 会执行所有的必要配置：
+
    - 创建一份 ConfigMap 提供添加集群节点所需的信息，并为该 ConfigMap 设置相关的 RBAC 访问规则。
    - 使得 Bootstrap Tokens 可以访问 CSR 签名 API。
    - 对新的 CSR 请求配置为自动签发。
@@ -84,7 +115,7 @@ run there. -->1.  对控制平面节点应用 labels 和 taints 标记以便不
 <!--
 See [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) for additional info.
 -->
-查阅[kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档以获取更多信息。
+查阅[kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档以获取更多信息。
 
 <!-- 
 1. Installs a DNS server (CoreDNS) and the kube-proxy addon components via the API server.
@@ -94,7 +125,8 @@ See [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) for additi
    Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed. -->
 1.  通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。
    在 1.11 版本以及更新版本的 Kubernetes 中 CoreDNS 是默认的 DNS 服务器。
-   要安装 kube-dns 而不是 CoreDNS，必须在 kubeadm `ClusterConfiguration` 中配置 DNS 插件。有关配置的更多信息，请参见下面的 `Using kubeadm init with a configuration file` 一节。
+   要安装 kube-dns 而不是 CoreDNS，必须在 kubeadm `ClusterConfiguration` 中配置 DNS 插件。
+   有关配置的更多信息，请参见下面的"带配置文件使用 kubeadm init" 一节。
    请注意，尽管已部署 DNS 服务器，但直到安装 CNI 时才调度它。
 
 <!--
@@ -105,10 +137,10 @@ See [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) for additi
 <!--
 Kubeadm allows you to create a control-plane node in phases using the `kubeadm init phase` command.
 -->
-Kubeadm 允许您使用 `kubeadm init phase` 命令分阶段创建控制平面节点。
+Kubeadm 允许你使用 `kubeadm init phase` 命令分阶段创建控制平面节点。
 
 <!--
-To view the ordered list of phases and sub-phases you can call `kubeadm init --help`. The list will be located at the top of the help screen and each phase will have a description next to it.
+To view the ordered list of phases and sub-phases you can call `kubeadm init -help`. The list will be located at the top of the help screen and each phase will have a description next to it.
 Note that by calling `kubeadm init` all of the phases and sub-phases will be executed in this exact order.
 -->
 要查看阶段和子阶段的有序列表，可以调用 `kubeadm init --help`。
@@ -116,7 +148,7 @@ Note that by calling `kubeadm init` all of the phases and sub-phases will be exe
 注意，通过调用 `kubeadm init`，所有阶段和子阶段都将按照此确切顺序执行。
 
 <!--
-Some phases have unique flags, so if you want to have a look at the list of available options add `--help`, for example:
+Some phases have unique flags, so if you want to have a look at the list of available options add `-help`, for example:
 -->
 某些阶段具有唯一的标志，因此，如果要查看可用选项的列表，请添加 `--help`，例如：
 
@@ -125,18 +157,19 @@ sudo kubeadm init phase control-plane controller-manager --help
 ```
 
 <!--
-You can also use `--help` to see the list of sub-phases for a certain parent phase:
+You can also use `-help` to see the list of sub-phases for a certain parent phase:
 -->
-您也可以使用 `--help` 查看特定父阶段的子阶段列表：
+你也可以使用 `--help` 查看特定父阶段的子阶段列表：
 
 ```shell
 sudo kubeadm init phase control-plane --help
 ```
 
 <!--
-`kubeadm init` also exposes a flag called `--skip-phases` that can be used to skip certain phases. The flag accepts a list of phase names and the names can be taken from the above ordered list.
+`kubeadm init` also exposes a flag called `-skip-phases` that can be used to skip certain phases. The flag accepts a list of phase names and the names can be taken from the above ordered list.
 -->
-`kubeadm init` 还公开了一个名为 `--skip-phases` 的参数，该参数可用于跳过某些阶段。参数接受阶段名称列表，并且这些名称可以从上面的有序列表中获取。
+`kubeadm init` 还公开了一个名为 `--skip-phases` 的参数，该参数可用于跳过某些阶段。
+参数接受阶段名称列表，并且这些名称可以从上面的有序列表中获取。
 
 <!--
 An example:
@@ -149,32 +182,37 @@ An example:
 ```shell
 sudo kubeadm init phase control-plane all --config=configfile.yaml
 sudo kubeadm init phase etcd local --config=configfile.yaml
-# 您现在可以修改控制平面和 etcd 清单文件
+# 你现在可以修改控制平面和 etcd 清单文件
 sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml
 ```
 
 <!--
-What this example would do is write the manifest files for the control plane and etcd in `/etc/kubernetes/manifests` based on the configuration in `configfile.yaml`. This allows you to modify the files and then skip these phases using `--skip-phases`. By calling the last command you will create a control plane node with the custom manifest files.
+What this example would do is write the manifest files for the control plane and etcd in `/etc/kubernetes/manifests` based on the configuration in `configfile.yaml`. This allows you to modify the files and then skip these phases using `-skip-phases`. By calling the last command you will create a control plane node with the custom manifest files.
 -->
-该示例将执行的操作是基于 `configfile.yaml` 中的配置在 `/etc/kubernetes/manifests` 中写入控制平面和 etcd 的清单文件。这允许您修改文件，然后使用 `--skip-phases` 跳过这些阶段。通过调用最后一个命令，您将使用自定义清单文件创建一个控制平面节点。
+该示例将执行的操作是基于 `configfile.yaml` 中的配置在 `/etc/kubernetes/manifests` 
+中写入控制平面和 etcd 的清单文件。
+这允许你修改文件，然后使用 `--skip-phases` 跳过这些阶段。
+通过调用最后一个命令，你将使用自定义清单文件创建一个控制平面节点。
 
 <!--
 ### Using kubeadm init with a configuration file {#config-file}
 -->
 ### 结合一份配置文件来使用 kubeadm init {#config-file}
 
-{{< caution >}}
 <!--
 The config file is still considered beta and may change in future versions.
--->配置文件的功能仍然处于 alpha 状态并且在将来的版本中可能会改变。
+-->
+{{< caution >}}
+配置文件的功能仍然处于 alpha 状态并且在将来的版本中可能会改变。
 {{< /caution >}}
 
 <!--
 It's possible to configure `kubeadm init` with a configuration file instead of command
 line flags, and some more advanced features may only be available as
-configuration file options. This file is passed with the `--config` option.
+configuration file options. This file is passed with the `-config` option.
 -->
-通过一份配置文件而不是使用命令行参数来配置 `kubeadm init` 命令是可能的，但是一些更加高级的功能只能够通过配置文件设定。这份配置文件通过 `--config` 选项参数指定。
+通过一份配置文件而不是使用命令行参数来配置 `kubeadm init` 命令是可能的，
+但是一些更加高级的功能只能够通过配置文件设定。这份配置文件通过 `--config` 选项参数指定。
 
 <!--
 The default configuration can be printed out using the
@@ -186,11 +224,13 @@ the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/
 For more details on each field in the `v1beta2` configuration you can navigate to our
 [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2).
 -->
-可以使用[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/)命令打印出默认配置。
+可以使用 [kubeadm config print](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/)命令打印出默认配置。
 
-**推荐**使用[kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/)命令将旧的 `v1beta1` 版本的配置迁移到 `v1beta2` 版本。
+**推荐**使用 [kubeadm config migrate](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/)
+命令将旧的 `v1beta1` 版本的配置迁移到 `v1beta2` 版本。
 
-获取 `v1beta2` 版本配置中每个字段的细节说明，查看我们的[API 参考页面](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)。
+获取 `v1beta2` 版本配置中每个字段的细节说明，查看我们的
+[API 参考页面](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)。
 
 <!--
 ### Adding kube-proxy parameters {#kube-proxy}
@@ -219,7 +259,7 @@ kubeadm 配置中有关 kube-proxy 的说明请查看：
 For information about passing flags to control plane components see:
 - [control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/) -->
 有关向控制平面组件传递命令行参数的说明请查看：
-[控制平面命令行参数](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
+[控制平面命令行参数](//zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
 
 <!--
 ### Using custom images {#custom-images}
@@ -231,13 +271,13 @@ By default, kubeadm pulls images from `k8s.gcr.io`. If the
 requested Kubernetes version is a CI label (such as `ci/latest`)
 `gcr.io/kubernetes-ci-images` is used.
 -->
-默认情况下, kubeadm 会从 `k8s.gcr.io` 仓库拉取镜像。如果请求的 Kubernetes 版本是 CI label (例如 `ci/latest`)，则使用 `gcr.io/kubernetes-ci-images`。
+默认情况下, kubeadm 会从 `k8s.gcr.io` 仓库拉取镜像。如果请求的 Kubernetes 版本是 CI 标签
+（例如 `ci/latest`），则使用 `gcr.io/kubernetes-ci-images`。
 
 <!--
 You can override this behavior by using [kubeadm with a configuration file](#config-file).
 -->
-
-您可以通过使用[带有配置文件的 kubeadm](#config-file)来重写此操作。
+你可以通过使用[带有配置文件的 kubeadm](#config-file)来重写此操作。
 
 <!--
 Allowed customization are:
@@ -247,7 +287,6 @@ Allowed customization are:
 * To set `useHyperKubeImage` to `true` to use the HyperKube image.
 * To provide a specific `imageRepository` and `imageTag` for etcd or DNS add-on.
 -->
-
 允许的自定义功能有：
 
 * 使用其他的 `imageRepository` 来代替 `k8s.gcr.io`。
@@ -256,9 +295,10 @@ Allowed customization are:
 
 <!--
 Please note that the configuration field `kubernetesVersion` or the command line flag
-`--kubernetes-version` affect the version of the images.
+`-kubernetes-version` affect the version of the images.
 -->
-请注意配置文件中的配置项 `kubernetesVersion` 或者命令行参数 `--kubernetes-version` 会影响到镜像的版本。
+请注意配置文件中的配置项 `kubernetesVersion` 或者命令行参数 `--kubernetes-version`
+会影响到镜像的版本。
 
 <!--
 ### Uploading control-plane certificates to the cluster
@@ -266,14 +306,17 @@ Please note that the configuration field `kubernetesVersion` or the command line
 ### 将控制平面证书上传到集群
 
 <!--
-By adding the flag `--upload-certs` to `kubeadm init` you can temporary upload
+By adding the flag `-upload-certs` to `kubeadm init` you can temporary upload
 the control-plane certificates to a Secret in the cluster. Please note that this Secret
 will expire automatically after 2 hours. The certificates are encrypted using
-a 32byte key that can be specified using `--certificate-key`. The same key can be used
+a 32byte key that can be specified using `-certificate-key`. The same key can be used
 to download the certificates when additional control-plane nodes are joining, by passing
-`--control-plane` and `--certificate-key` to `kubeadm join`.
+`-control-plane` and `-certificate-key` to `kubeadm join`.
 -->
-通过将参数 `--upload-certs` 添加到 `kubeadm init`，您可以将控制平面证书临时上传到集群中的 Secret。请注意，此 Secret 将在 2 小时后自动过期。证书使用 32 字节密钥加密，可以使用 `--certificate-key` 指定。通过将 `--control-plane` 和 `--certificate-key` 传递给 `kubeadm join`，可以在添加其他控制平面节点时使用相同的密钥下载证书。
+通过将参数 `--upload-certs` 添加到 `kubeadm init`，你可以将控制平面证书临时上传到集群中的 Secret。
+请注意，此 Secret 将在 2 小时后自动过期。证书使用 32 字节密钥加密，可以使用 `--certificate-key` 指定。
+通过将 `--control-plane` 和 `--certificate-key` 传递给 `kubeadm join`，
+可以在添加其他控制平面节点时使用相同的密钥下载证书。
 
 <!--
 The following phase command can be used to re-upload the certificates after expiration:
@@ -285,10 +328,11 @@ kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE
 ```
 
 <!--
-If the flag `--certificate-key` is not passed to `kubeadm init` and
+If the flag `-certificate-key` is not passed to `kubeadm init` and
 `kubeadm init phase upload-certs` a new key will be generated automatically.
 -->
-如果未将参数 `--certificate-key` 传递给 `kubeadm init` 和 `kubeadm init phase upload-certs`，则会自动生成一个新密钥。
+如果未将参数 `--certificate-key` 传递给 `kubeadm init` 和 `kubeadm init phase upload-certs`，
+则会自动生成一个新密钥。
 
 <!--
 The following command can be used to generate a new key on demand:
@@ -313,10 +357,11 @@ You can override this behavior by providing your own certificates.
 
 <!--
 To do so, you must place them in whatever directory is specified by the
-`--cert-dir` flag or `CertificatesDir` configuration file key. By default this
+`-cert-dir` flag or `CertificatesDir` configuration file key. By default this
 is `/etc/kubernetes/pki`.
 -->
-如果要这样做, 你必须将证书文件放置在通过 `--cert-dir` 命令行参数或者配置文件里的 `CertificatesDir` 配置项指明的目录中。默认的值是 `/etc/kubernetes/pki`。
+如果要这样做, 你必须将证书文件放置在通过 `--cert-dir` 命令行参数或者配置文件里的
+`CertificatesDir` 配置项指明的目录中。默认的值是 `/etc/kubernetes/pki`。
 
 <!--
 If a given certificate and private key pair exists before running `kubeadm init`,
@@ -324,7 +369,9 @@ kubeadm will not overwrite them. This means you can, for example, copy an existi
 CA into `/etc/kubernetes/pki/ca.crt` and `/etc/kubernetes/pki/ca.key`,
 and kubeadm will use this CA for signing the rest of the certificates.
 -->
-如果在运行 `kubeadm init` 之前存在给定的证书和私钥对，则 kubeadm 将不会重写它们。例如，这意味着您可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.crt` 和 `/etc/kubernetes/pki/ca.key` 中，而 kubeadm 将使用此 CA 对其余证书进行签名。
+如果在运行 `kubeadm init` 之前存在给定的证书和私钥对，则 kubeadm 将不会重写它们。
+例如，这意味着你可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.crt` 和
+`/etc/kubernetes/pki/ca.key` 中，而 kubeadm 将使用此 CA 对其余证书进行签名。
 
 <!--
 #### External CA mode {#external-ca-mode}
@@ -339,13 +386,15 @@ this condition and activates the "External CA" mode. kubeadm will proceed withou
 CA key on disk.
 -->
 如果只提供了 `ca.crt` 文件但是没有提供 `ca.key` 文件也是可以的 (这只对 CA 根证书可用，其它证书不可用)。
-如果所有的其它证书和 kubeconfig 文件已就绪， kubeadm 检测到满足以上条件就会激活 "外部 CA" 模式。kubeadm 将会在没有 CA 密钥文件的情况下继续执行。
+如果所有的其它证书和 kubeconfig 文件已就绪， kubeadm 检测到满足以上条件就会激活 "外部 CA" 模式。
+kubeadm 将会在没有 CA 密钥文件的情况下继续执行。
 
 <!--
-Instead, run the controller-manager standalone with `--controllers=csrsigner` and
+Instead, run the controller-manager standalone with `-controllers=csrsigner` and
 point to the CA certificate and key.
 -->
-否则, kubeadm 将独立运行 controller-manager，附加一个 `--controllers=csrsigner` 的参数，并且指明 CA 证书和密钥。
+否则, kubeadm 将独立运行 controller-manager，附加一个 `--controllers=csrsigner` 的参数，
+并且指明 CA 证书和密钥。
 
 <!--
 ### Managing the kubeadm drop-in file for the kubelet {#kubelet-drop-in}
@@ -355,12 +404,15 @@ point to the CA certificate and key.
 <!--
 The `kubeadm` package ships with a configuration file for running the `kubelet` by `systemd`. Note that the kubeadm CLI never touches this drop-in file. This drop-in file is part of the kubeadm DEB/RPM package.
 -->
-`kubeadm` 包自带了关于 `systemd` 如何运行 `kubelet` 的配置文件。请注意 `kubeadm` 客户端命令行工具永远不会修改这份 `systemd` 配置文件。这份 `systemd` 配置文件属于 kubeadm DEB/RPM 包。
+`kubeadm` 包自带了关于 `systemd` 如何运行 `kubelet` 的配置文件。
+请注意 `kubeadm` 客户端命令行工具永远不会修改这份 `systemd` 配置文件。
+这份 `systemd` 配置文件属于 kubeadm DEB/RPM 包。
 
 <!--
 For further information, see [Managing the kubeadm drop-in file for systemd](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd).
 -->
-有关更多信息，请阅读[管理 systemd 的 kubeadm 内嵌文件](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd)。
+有关更多信息，请阅读
+[管理 systemd 的 kubeadm 内嵌文件](/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd)。
 
 <!--
 ### Use kubeadm with CRI runtimes
@@ -371,7 +423,8 @@ For further information, see [Managing the kubeadm drop-in file for systemd](/do
 By default kubeadm attempts to detect your container runtime. For more details on this detection, see
 the [kubeadm CRI installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
 -->
-默认情况下，kubeadm 尝试检测您的容器运行环境。有关此检测的更多详细信息，请参见[kubeadm CRI 安装指南](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)。
+默认情况下，kubeadm 尝试检测你的容器运行环境。有关此检测的更多详细信息，请参见
+[kubeadm CRI 安装指南](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)。
 
 <!--
 ### Setting the node name
@@ -379,12 +432,14 @@ the [kubeadm CRI installation guide](/docs/setup/production-environment/tools/ku
 ### 设置节点的名称
 
 <!--
-By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name` flag.
-The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
+By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `-node-name` flag.
+The flag passes the appropriate [`-hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
 value to the kubelet.
 -->
 默认情况下, `kubeadm` 基于机器的主机地址分配一个节点名称。你可以使用 `--node-name` 参数覆盖此设置。
-注意覆盖主机名称可能会[干扰到云服务提供商](https://github.com/kubernetes/website/pull/8873)。
+此标识将合适的
+[`--hostname-override`](/zh/docs/reference/command-line-tools-reference/kubelet/#options)
+值传递给 kubelet。
 
 <!--
 ### Running kubeadm without an internet connection
@@ -394,12 +449,12 @@ value to the kubelet.
 <!--
 For running kubeadm without an internet connection you have to pre-pull the required control-plane images.
 -->
-要在没有互联网连接的情况下运行 kubeadm，您必须提前拉取所需的控制平面镜像。
+要在没有互联网连接的情况下运行 kubeadm，你必须提前拉取所需的控制平面镜像。
 
 <!--
 You can list and pull the images using the `kubeadm config images` sub-command:
 -->
-您可以使用 `kubeadm config images` 子命令列出并拉取镜像：
+你可以使用 `kubeadm config images` 子命令列出并拉取镜像：
 
 ```shell
 kubeadm config images list
@@ -423,13 +478,16 @@ token distribution for easier automation. To implement this automation, you must
 know the IP address that the control-plane node will have after it is started,
 or use a DNS name or an address of a load balancer.
 -->
-不必像文档[kubeadm 基础教程](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)所述，将从 `kubeadm init` 取得的令牌复制到每个节点，而是简单自动地并行化令牌分发。要实现自动化，您必须知道控制平面节点启动后将拥有的 IP 地址，或使用 DNS 名称或负载均衡器的地址。
-
+不必像文档[kubeadm 基础教程](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)所述，
+将从 `kubeadm init` 取得的令牌复制到每个节点，你可以并行地分发令牌以实现简单自动化。要实现自动化，
+你必须知道控制平面节点启动后将拥有的 IP 地址，或使用 DNS 名称或负载均衡器的地址。
 
 <!--
 1.  Generate a token. This token must have the form  `<6 character string>.<16
 character string>`. More formally, it must match the regex: `[a-z0-9]{6}\.[a-z0-9]{16}`.
-kubeadm can generate a token for you: -->1.  生成一个令牌。这个令牌必须具有以下格式：`< 6 个字符的字符串>.< 16 个字符的字符串>`。更加正式的说法是，它必须符合以下正则表达式：`[a-z0-9]{6}\.[a-z0-9]{16}`。
+kubeadm can generate a token for you: -->
+1. 生成一个令牌。这个令牌必须具有以下格式：`< 6 个字符的字符串>.< 16 个字符的字符串>`。
+   更加正式的说法是，它必须符合以下正则表达式：`[a-z0-9]{6}\.[a-z0-9]{16}`。
    kubeadm 可以为你生成一个令牌：
 
    ```shell
@@ -438,11 +496,16 @@ kubeadm can generate a token for you: -->1.  生成一个令牌。这个令牌
 
 <!--
 2.  Start both the control-plane node and the worker nodes concurrently with this token.
-As they come up they should find each other and form the cluster. The same `--token` argument can be used on both `kubeadm init` and `kubeadm join`. 
--->2.  使用这个令牌同时启动控制平面节点和工作节点。它们一旦运行起来应该就会互相寻找对方并且建立集群。同样的 `--token` 参数可以同时用于 `kubeadm init` 和 `kubeadm join` 命令。
+As they come up they should find each other and form the cluster. The same `-token` argument can be used on both `kubeadm init` and `kubeadm join`. 
+-->
+2. 使用这个令牌同时启动控制平面节点和工作节点。它们一旦运行起来应该就会互相寻找对方并且建立集群。
+   同样的 `--token` 参数可以同时用于 `kubeadm init` 和 `kubeadm join` 命令。
+
+<!--
+3.  Similar can be done for `-certificate-key` when joining additional control-plane nodes. The key can be generated using:
+-->
+3. 当加入其他控制平面节点时，可以对 `--certificate-key` 执行类似的操作。可以使用以下方式生成密钥：
 
-<!-- 3.  Similar can be done for `--certificate-key` when joining additional control-plane nodes. The key can be generated using: -->3.  当加入其他控制平面节点时，可以对 `--certificate-key` 执行类似的操作。可以使用以下方式生成密钥：
-   
    ```shell
    kubeadm alpha certs certificate-key
    ```
@@ -451,17 +514,18 @@ As they come up they should find each other and form the cluster. The same `--to
 Once the cluster is up, you can grab the admin credentials from the control-plane node
 at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
 -->
-一旦集群启动起来，你就可以从控制平面节点的 `/etc/kubernetes/admin.conf` 文件获取管理凭证，然后你就可以使用这个凭证同集群通信。
+一旦集群启动起来，你就可以从控制平面节点的 `/etc/kubernetes/admin.conf` 文件获取管理凭证，
+并使用这个凭证同集群通信。
 
 <!--
 Note that this style of bootstrap has some relaxed security guarantees because
 it does not allow the root CA hash to be validated with
-`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
+`-discovery-token-ca-cert-hash` (since it's not generated when the nodes are
 provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
 -->
-注意这种搭建集群的方式在安全保证上会有一些宽松，因为这种方式不允许使用 `--discovery-token-ca-cert-hash` 来验证根 CA 的哈希值（因为当配置节点的时候，它还没有被生成）。获取需更多信息请参阅[kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档。
-
-
+注意这种搭建集群的方式在安全保证上会有一些宽松，因为这种方式不允许使用 `--discovery-token-ca-cert-hash` 
+来验证根 CA 的哈希值（因为当配置节点的时候，它还没有被生成）。
+更多信息请参阅[kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档。
 
 ## {{% heading "whatsnext" %}}
 
@@ -472,8 +536,8 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku
 * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
 -->
-* 了解更多有关[kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/)
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/)启动一个 Kubernetes 工作节点并且将其加入到集群
-* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/)将 Kubernetes 集群升级到新版本
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/)使用 `kubeadm init` 或 `kubeadm join` 来恢复对节点的变更
+* 进一步阅读了解[kubeadm init 阶段](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/)
+* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)启动一个 Kubernetes 工作节点并且将其加入到集群
+* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/)将 Kubernetes 集群升级到新版本
+* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/)使用 `kubeadm init` 或 `kubeadm join` 来恢复对节点的变更
 
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
index 8283ac7d22..17e604629a 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
@@ -81,10 +81,8 @@ Using this phase you can join a node as a control-plane instance.
 {{< tab name="mark-control-plane" include="generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md" />}}
 {{< /tabs >}}
 
-<!--
-## What's next
--->
-## 下一步
+## {{% heading "whatsnext" %}}
+
 <!--
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
index a579acca0c..785c983d99 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
@@ -1,10 +1,12 @@
 ---
 title: kubeadm reset phase
+content_type: concept
 weight: 90
 ---
 <!--
 ---
 title: kubeadm reset phase
+content_type: concept
 weight: 90
 ---
 -->
@@ -81,14 +83,14 @@ Using this phase you can perform cleanup on this node.
 {{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}}
 {{< /tabs >}}
 
+## {{% heading "whatsnext" %}}
+
 <!--
-## What's next
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
 * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality
 -->
-## 下一步
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
index 33b80a5486..22633af056 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md
@@ -1,6 +1,7 @@
 ---
 title: kubeadm upgrade phase
 weight: 90
+content_type: concept
 ---
 <!--
 In v1.15.0, kubeadm introduced preliminary support for `kubeadm upgrade node` phases.
@@ -30,16 +31,15 @@ be called on a primary control-plane node.
 {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}}
 {{< /tabs >}}
 
+## {{% heading "whatsnext" %}}
+
 <!--
-## What's next
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to connect a node to the cluster
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
 * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a kubeadm node
 * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality
 -->
-
-## 接下来
 * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导一个 Kubernetes 控制平面节点
 * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点加入到群集
 * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 还原 `kubeadm init` 或 `kubeadm join` 命令对主机所做的任何更改
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md
deleted file mode 100644
index ad5e7a2665..0000000000
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: kubeadm 概述
-weight: 10
-card:
-  name: reference
-  weight: 40
----
-<!--
-reviewers:
-- luxas
-- jbeda
-title: Overview of kubeadm
-weight: 10
-card:
-  name: reference
-  weight: 40
--->
-
-<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">
-<!--
-Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
--->
-Kubeadm 是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。
-
-<!--
-kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
--->
-kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是准备节点环境的工作。同样的，诸如安装各种各样的可有可无的插件，例如 Kubernetes 控制面板、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。
-
-<!--
-Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
--->
-相反，我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
-
-<!--
-## How to install
-
-To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
--->
-## 如何安装
-要安装 kubeadm，请参考[安装指南](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)。
-
-## 接下可以做什么
-
-<!--
-* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
-* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
-* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
-* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
-* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
--->
-* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动引导一个 Kubernetes 主节点
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动引导一个 Kubernetes 工作节点并且将其加入到集群
-* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新 Kubernetes 集群到新版本
-* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用 kubeadm v1.7.x 或者更低版本，你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令
-* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点所作改变
-* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈
-
diff --git a/content/zh/docs/reference/using-api/_index.md b/content/zh/docs/reference/using-api/_index.md
index 2f2a114cec..8d2c4b502c 100644
--- a/content/zh/docs/reference/using-api/_index.md
+++ b/content/zh/docs/reference/using-api/_index.md
@@ -1,5 +1,4 @@
 ---
 title: 使用 Kubernetes API
 weight: 10
-toc-hide: true
 ---
diff --git a/content/zh/docs/reference/using-api/api-concepts.md b/content/zh/docs/reference/using-api/api-concepts.md
new file mode 100644
index 0000000000..c3b7f54fec
--- /dev/null
+++ b/content/zh/docs/reference/using-api/api-concepts.md
@@ -0,0 +1,1902 @@
+---
+title: Kubernetes API 概念
+content_type: concept
+weight: 20
+---
+<!--
+title: Kubernetes API Concepts
+reviewers:
+- smarterclayton
+- lavalamp
+- liggitt
+content_type: concept
+weight: 20
+-->
+
+<!-- overview -->
+<!--
+This page describes common concepts in the Kubernetes API.
+-->
+本页描述 Kubernetes API 的通用概念。
+
+<!-- body -->
+<!--
+The Kubernetes API is a resource-based (RESTful) programmatic interface provided via HTTP. It supports retrieving, creating,
+updating, and deleting primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET), includes additional subresources for many objects that allow fine grained authorization (such as binding a pod to a node), and can accept and serve those resources in different representations for convenience or efficiency. It also supports efficient change notifications on resources via "watches" and consistent lists to allow other components to effectively cache and synchronize the state of resources.
+-->
+Kubernetes API 是基于资源的（RESTful）、通过 HTTP 提供的编程接口。
+API 支持通过标准的 HTTP 动词（POST、PUT、PATCH、DELETE 和  GET）
+检视、创建、更新和删除主要资源，为很多允许细粒度权限控制的对象提供子资源
+（如将 Pod 绑定到节点上），并且出于便利性或效率考虑，支持并提供这些资源的
+不同表示形式。
+Kubernetes  API 还通过 "watch" 和一致性的列表支持高效的资源变更通知，
+从而允许其他组件对资源的状态进行高效的缓存和同步。
+
+<!--
+## Standard API terminology
+
+Most Kubernetes API resource types are [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects): they represent a concrete instance of a concept on the cluster, like a pod or namespace. A smaller number of API resource types are "virtual" - they often represent operations rather than objects, such as a permission check (use a POST with a JSON-encoded body of `SubjectAccessReview` to the `subjectaccessreviews` resource). All objects will have a unique name to allow idempotent creation and retrieval, but virtual resource types may not have unique names if they are not retrievable or do not rely on idempotency.
+-->
+## 标准 API 术语  {#standard-api-terminology}
+
+大多数 Kubernetes API 资源类型都是
+[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)：
+它们代表的是集群中某一概念的具体实例，例如一个 Pod 或名字空间。
+为数不多的几个 API 资源类型是“虚拟的” - 它们通常代表的是操作而非对象本身，
+例如访问权限检查（使用 POST 请求发送一个 JSON 编码的 `SubjectAccessReview`
+负载到 `subjectaccessreviews` 资源）。
+所有对象都有一个唯一的名字，以便支持幂等的创建和检视操作，不过如果虚拟资源类型
+不可检视或者不要求幂等，可以不具有唯一的名字。
+
+<!--
+Kubernetes generally leverages standard RESTful terminology to describe the API concepts:
+
+* A **resource type** is the name used in the URL (`pods`, `namespaces`, `services`)
+* All resource types have a concrete representation in JSON (their object schema) which is called a **kind**
+* A list of instances of a resource type is known as a **collection**
+* A single instance of the resource type is called a **resource**
+-->
+Kubernetes 一般会利用标准的 RESTful 术语来描述 API 概念：
+
+* **资源类型（Resource Type）** 是在 URL 中使用的名称（`pods`、`namespaces`、`services`）
+* 所有资源类型都有具有一个 JSON 形式（其对象的模式定义）的具体表示，称作**类别（Kind）**
+* 某资源类型的实例的列表称作 **集合（Collection）**
+* 资源类型的单个实例被称作 **资源（Resource）**
+
+<!--
+All resource types are either scoped by the cluster (`/apis/GROUP/VERSION/*`) or to a namespace (`/apis/GROUP/VERSION/namespaces/NAMESPACE/*`). A namespace-scoped resource type will be deleted when its namespace is deleted and access to that resource type is controlled by authorization checks on the namespace scope. The following paths are used to retrieve collections and resources:
+
+* Cluster-scoped resources:
+  * `GET /apis/GROUP/VERSION/RESOURCETYPE` - return the collection of resources of the resource type
+  * `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME` - return the resource with NAME under the resource type
+* Namespace-scoped resources:
+  * `GET /apis/GROUP/VERSION/RESOURCETYPE` - return the collection of all instances of the resource type across all namespaces
+  * `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE` - return collection of all instances of the resource type in NAMESPACE
+  * `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME` - return the instance of the resource type with NAME in NAMESPACE
+-->
+所有资源类型要么是集群作用域的（`/apis/GROUP/VERSION/*`），要么是名字空间
+作用域的（`/apis/GROUP/VERSION/namespaces/NAMESPACE/*`）。
+名字空间作用域的资源类型会在其名字空间被删除时也被删除，并且对该资源类型的
+访问是由定义在名字空间域中的授权检查来控制的。
+下列路径用来检视集合和资源：
+
+* 集群作用域的资源：
+  * `GET /apis/GROUP/VERSION/RESOURCETYPE` - 返回指定资源类型的资源的集合
+  * `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME` - 返回指定资源类型下名称为 NAME 的资源
+* 名字空间作用域的资源：
+  * `GET /apis/GROUP/VERSION/RESOURCETYPE` - 返回所有名字空间中指定资源类型的全部实例的集合
+  * `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE` - 返回名字空间 NAMESPACE 内给定资源类型的全部实例的集合
+  * `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME` - 返回名字空间 NAMESPACE 中给定资源类型的名称为 NAME 的实例
+
+<!--
+Since a namespace is a cluster-scoped resource type, you can retrieve the list of all namespaces with `GET /api/v1/namespaces` and details about a particular namespace with `GET /api/v1/namespaces/NAME`.
+
+Almost all object resource types support the standard HTTP verbs - GET, POST, PUT, PATCH, and DELETE. Kubernetes uses the term **list** to describe returning a collection of resources to distinguish from retrieving a single resource which is usually called a **get**.
+-->
+由于名字空间本身是一个集群作用域的资源累;，你可以通过 `GET /api/v1/namespaces/`
+检视所有名字空间的列表，使用 `GET /api/v1/namespaces/NAME` 查看特定名字空间的
+详细信息。
+
+几乎所有对象资源类型都支持标准的 HTTP 动词 - GET、POST、PUT、PATCH 和 DELETE。
+Kubernetes 使用术语 **list** 来描述返回资源集合的操作，以便与返回单个资源的、
+通常称作 **get** 的操作相区分。
+
+<!--
+Some resource types will have one or more sub-resources, represented as sub paths below the resource:
+
+* Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
+* Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
+
+The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
+-->
+某些资源类型有一个或多个子资源（Sub-resource），表现为对应资源下面的子路径：
+
+* 集群作用域的子资源：`GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
+* 名字空间作用域的子资源：`GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
+
+取决于对象是什么，每个子资源所支持的动词有所不同 - 参见 API 文档以了解更多信息。
+跨多个资源来访问其子资源是不可能的 - 如果需要这一能力，则通常意味着需要一种
+新的虚拟资源类型了。
+
+<!--
+## Efficient detection of changes
+
+To enable clients to build a model of the current state of a cluster, all Kubernetes object resource types are required to support consistent lists and an incremental change notification feed called a **watch**.  Every Kubernetes object has a `resourceVersion` field representing the version of that resource as stored in the underlying database. When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a `resourceVersion` value that can be used to initiate a watch against the server. The server will return all changes (creates, deletes, and updates) that occur after the supplied `resourceVersion`. This allows a client to fetch the current state and then watch for changes without missing any updates. If the client watch is disconnected they can restart a new watch from the last returned `resourceVersion`, or perform a new collection request and begin again. See [Resource Version Semantics](#resource-versions) for more detail.
+
+For example:
+-->
+## 高效检测变更  {#efficient-detection-of-changes}
+
+为了使客户端能够构造一个模型来表达集群的当前状态，所有 Kubernetes 对象资源类型
+都需要支持一致的列表和一个称作 **watch** 的增量变更通知信源（feed）。
+每个 Kubernetes 对象都有一个 `resourceVersion` 字段，代表该资源在下层数据库中
+存储的版本。检视资源集合（名字空间作用域或集群作用域）时，服务器返回的响应
+中会包含 `resourceVersion` 值，可用来向服务器发起 watch 请求。
+服务器会返回所提供的 `resourceVersion` 之后发生的所有变更（创建、删除和更新）。
+这使得客户端能够取回当前的状态并监视其变更，且不会错过任何变更事件。
+客户端的监视连接被断开时，可以从最后返回的 `resourceVersion` 重启新的监视连接，
+或者执行一个新的集合请求之后从头开始监视操作。
+参阅[资源版本语义](#resource-versions)以了解更多细节。
+
+例如：
+
+<!--
+1. List all of the pods in a given namespace.
+-->
+1. 列举给定名字空间中的所有 Pods：
+
+   ```console
+   GET /api/v1/namespaces/test/pods
+   ---
+   200 OK
+   Content-Type: application/json
+   {
+     "kind": "PodList",
+     "apiVersion": "v1",
+     "metadata": {"resourceVersion":"10245"},
+     "items": [...]
+   }
+   ```
+
+<!--
+2. Starting from resource version 10245, receive notifications of any creates, deletes, or updates as individual JSON objects.
+-->
+2. 从资源版本 10245 开始，以 JSON 对象的形式接收所有创建、删除或更新操作的通知：
+
+   ```console
+   GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245
+   ---
+   200 OK
+   Transfer-Encoding: chunked
+   Content-Type: application/json
+
+   {
+     "type": "ADDED",
+     "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
+   }
+   {
+     "type": "MODIFIED",
+     "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...}
+   }
+   ...
+   ```
+
+<!--
+A given Kubernetes server will only preserve a historical list of changes for a limited time. Clusters using etcd3 preserve changes in the last 5 minutes by default.  When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code `410 Gone`, clearing their local cache, performing a list operation, and starting the watch from the `resourceVersion` returned by that new list operation. Most client libraries offer some form of standard tool for this logic. (In Go this is called a `Reflector` and is located in the `k8s.io/client-go/cache` package.)
+-->
+给定的 Kubernetes 服务器只会保留一定的时间内发生的历史变更列表。
+使用 etcd3 的集群默认保存过去 5 分钟内发生的变更。
+当所请求的 watch 操作因为资源的历史版本不存在而失败，客户端必须能够处理
+因此而返回的状态代码 `410 Gone`，清空其本地的缓存，重新执行 list 操作，
+并基于新的 list 操作所返回的 `resourceVersion` 来开始新的 watch 操作。
+大多数客户端库都能够提供某种形式的、包含此逻辑的工具。
+（在 Go 语言客户端库中，这一设施称作 `Reflector`，位于
+`k8s.io/client-go/cache` 包中。)
+
+<!--
+### Watch bookmarks
+
+To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to mark that all changes up to a given `resourceVersion` the client is requesting have already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.:
+-->
+### 监视书签（Watch Bookmark）
+
+为了处理历史窗口过短的问题，我们引入了 `bookmark（书签）` 监视事件的概念。
+该事件是一种特殊事件，用来标示客户端所请求的、指定的 `resourceVersion` 之前
+的所有变更都以被发送。该事件中返回的对象是所请求的资源类型，但其中仅包含
+`resourceVersion` 字段，例如：
+
+```console
+GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
+---
+200 OK
+Transfer-Encoding: chunked
+Content-Type: application/json
+
+{
+  "type": "ADDED",
+  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
+}
+...
+{
+  "type": "BOOKMARK",
+  "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
+}
+```
+
+<!--
+`Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event.
+-->
+通过在 watch 请求中设置 `allowWatchBookmarks=true` 选项，可以请求 `bookmark`
+事件，但是客户端不能假定服务器端会按某特定时间间隔返回书签事件，甚至也不能
+假定服务器一定会发送 `bookmark` 事件。
+
+<!--
+## Retrieving large results sets in chunks
+-->
+## 分块检视大体量结果
+
+{{< feature-state for_k8s_version="v1.9" state="beta" >}}
+
+<!--
+On large clusters, retrieving the collection of some resource types may result in very large responses that can impact the server and client. For instance, a cluster may have tens of thousands of pods, each of which is 1-2kb of encoded JSON. Retrieving all pods across all namespaces may result in a very large response (10-20MB) and consume a large amount of server resources. Starting in Kubernetes 1.9 the server supports the ability to break a single large collection request into many smaller chunks while preserving the consistency of the total request. Each chunk can be returned sequentially which reduces both the total size of the request and allows user-oriented clients to display results incrementally to improve responsiveness.
+-->
+在较大规模的集群中，检视某些资源类型的集合时可能会返回较大体量的响应数据，对
+服务器和客户端都会造成影响。例如，某集群可能包含数万个 Pod，每个 Pod 的 JSON
+编码都有 1-2 KB 的大小。返回所有名字空间的全部 Pod 时，其结果可能体量很大
+（10-20 MB）且耗用大量的服务器资源。
+从 Kubernetes 1.9 开始，服务器支持将单一的大体量集合请求分解成多个小数据块
+同时还保证整个请求的一致性的能力。
+各个数据块可以按顺序返回，进而降低请求的尺寸，允许面向用户的客户端以增量形式
+呈现返回结果，改进系统响应效果。
+
+<!--
+To retrieve a single list in chunks, two new parameters `limit` and `continue`
+are supported on collection requests and a new field `continue` is returned
+from all list operations in the list `metadata` field. A client should specify
+the maximum results they wish to receive in each chunk with `limit` and the
+server will return up to `limit` resources in the result and include a
+`continue` value if there are more resources in the collection. The client can
+then pass this `continue` value to the server on the next request to instruct
+the server to return the next chunk of results. By continuing until the server
+returns an empty `continue` value the client can consume the full set of
+results.
+-->
+为了用分块的形式返回一个列表，集合请求上可以设置两个新的参数 `limit` 和
+`continue`，并且所有 list 操作的返回结果列表的 `metadata` 字段中会包含一个
+新的 `continue` 字段。
+客户端应该将 `limit` 设置为希望在每个数据块中收到的结果个数上限，而服务器则
+会在结果中至多返回 `limit` 个资源并在集合中还有更多资源的时候包含一个
+`continue` 值。客户端在下次请求时则可以将此 `continue` 值传递给服务器，
+告知后者要从何处开始返回结果的下一个数据块。
+通过重复这一操作直到服务器端返回空的 `continue` 值，客户端可以受到结果的
+全集。
+
+<!--
+Like a watch operation, a `continue` token will expire after a short amount of time (by default 5 minutes) and return a `410 Gone` if more results cannot be returned. In this case, the client will need to start from the beginning or omit the `limit` parameter.
+
+For example, if there are 1,253 pods on the cluster and the client wants to receive chunks of 500 pods at a time, they would request those chunks as follows:
+-->
+与 watch 操作类似，`continue` 令牌也会在很短的时间（默认为 5 分钟）内过期，
+并在无法返回更多结果时返回 `410 Gone` 代码。
+这时，客户端需要从头开始执行上述检视操作或者忽略 `limit` 参数。
+
+例如，如果集群上有 1253 个 Pods，客户端希望每次收到包含至多 500 个 Pod 的
+数据块，它应按下面的步骤来请求数据块：
+
+<!--
+1. List all of the pods on a cluster, retrieving up to 500 pods each time.
+-->
+1. 列举集群中所有 Pod，每次接收至多 500 个 Pods：
+
+```console
+GET /api/v1/pods?limit=500
+---
+200 OK
+Content-Type: application/json
+
+{
+  "kind": "PodList",
+  "apiVersion": "v1",
+  "metadata": {
+    "resourceVersion":"10245",
+    "continue": "ENCODED_CONTINUE_TOKEN",
+    ...
+  },
+  "items": [...] // returns pods 1-500
+}
+```
+<!--
+2. Continue the previous call, retrieving the next set of 500 pods.
+-->
+2. 继续前面的调用，返回下一组 500 个 Pods：
+
+```console
+GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN
+---
+200 OK
+Content-Type: application/json
+
+{
+  "kind": "PodList",
+  "apiVersion": "v1",
+  "metadata": {
+    "resourceVersion":"10245",
+    "continue": "ENCODED_CONTINUE_TOKEN_2",
+    ...
+  },
+  "items": [...] // returns pods 501-1000
+}
+```
+
+<!--
+3. Continue the previous call, retrieving the last 253 pods.
+-->
+3. 继续前面的调用，返回最后 253 个 Pods：
+
+```console
+GET /api/v1/pods?limit=500&continue=ENCODED_CONTINUE_TOKEN_2
+---
+200 OK
+Content-Type: application/json
+
+{
+  "kind": "PodList",
+  "apiVersion": "v1",
+  "metadata": {
+    "resourceVersion":"10245",
+    "continue": "", // continue token is empty because we have reached the end of the list
+    ...
+  },
+  "items": [...] // returns pods 1001-1253
+}
+```
+
+<!--
+Note that the `resourceVersion` of the list remains constant across each request, indicating the server is showing us a consistent snapshot of the pods. Pods that are created, updated, or deleted after version `10245` would not be shown unless the user makes a list request without the `continue` token.  This allows clients to break large requests into smaller chunks and then perform a watch operation on the full set without missing any updates.
+-->
+注意 list 操作的 `resourceVersion` 在每个请求中都设置的是同一个数值，
+这表明服务器要向我们展示一个一致的 Pods 快照视图。
+在版本 `10245` 之后创建、更新或删除的 Pods 都不会显示出来，除非用户发出
+list 请求时不指定 `continue` 令牌。
+这一设计使得客户端能够将较大的响应切分为较小的数据块，且能够对较大的集合
+执行监视动作而不会错失任何更新事件。
+
+<!--
+## Receiving resources as Tables
+
+The output from the `kubectl get` command is a simple tabular representation of one or more instances of a particular resource type. In the past, clients were required to reproduce the tabular and describe output implemented in `kubectl` to perform simple lists of objects.
+A few limitations of that approach include non-trivial logic when dealing with certain objects. Additionally, types provided by API aggregation or third party resources are not known at compile time. This means that generic implementations had to be in place for types unrecognized by a client.
+-->
+## 以表格形式接收资源
+
+`kubectl get` 命令的输出是一个包含一个或多个资源的简单表格形式。
+过去，客户端需要重复 `kubectl` 中所实现的表格输出和描述输出逻辑，以执行
+简单的对象列表操作。
+这一方法在处理某些对象时，需要引入不容忽视的逻辑。
+此外，[API 聚合](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+和[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+所提供的资源类型都是编译时不可预知的。这意味着，客户端必须针对无法
+识别的类型提供通用的实现逻辑。
+
+<!--
+In order to avoid potential limitations as described above, clients may request the Table representation of objects, delegating specific details of printing to the server. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header containing a value of `application/json;as=Table;g=meta.k8s.io;v=v1beta1` with a `GET` call will request that the server return objects in the Table content type.
+
+For example:
+-->
+为了避免上述各种潜在的局限性，客户端可以请求服务器端返回对象的表格（Table）
+表现形式，从而将打印输出的特定细节委托给服务器。
+Kubernetes API 实现标准的 HTTP 内容类型（Content Type）协商：为 `GET` 调用
+传入一个值为 `application/json;as=Table;g=meta.k8s.io;v=v1beta1` 的 `Accept`
+头部即可请求服务器以 Table 的内容类型返回对象。
+
+例如，以 Table 格式列举集群中所有 Pods：
+
+```console
+GET /api/v1/pods
+Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1
+---
+200 OK
+Content-Type: application/json
+
+{
+    "kind": "Table",
+    "apiVersion": "meta.k8s.io/v1beta1",
+    ...
+    "columnDefinitions": [
+        ...
+    ]
+}
+```
+
+<!--
+For API resource types that do not have a custom Table definition on the
+server, a default Table response is returned by the server, consisting of the
+resource's `name` and `creationTimestamp` fields.
+-->
+对于在服务器上不存在定制的 Table 定义的 API 资源类型而言，服务器会返回
+一个默认的 Table 响应，其中包含资源的 `name` 和 `creationTimestamp` 字段。
+
+```console
+GET /apis/crd.example.com/v1alpha1/namespaces/default/resources
+---
+200 OK
+Content-Type: application/json
+...
+
+{
+    "kind": "Table",
+    "apiVersion": "meta.k8s.io/v1beta1",
+    ...
+    "columnDefinitions": [
+        {
+            "name": "Name",
+            "type": "string",
+            ...
+        },
+        {
+            "name": "Created At",
+            "type": "date",
+            ...
+        }
+    ]
+}
+```
+
+<!--
+Table responses are available beginning in version 1.10 of the kube-apiserver.
+As such, not all API resource types will support a Table response,
+specifically when using a client against older clusters. Clients that must
+work against all resource types, or can potentially deal with older clusters,
+should specify multiple content types in their `Accept` header to support
+fallback to non-Tabular JSON:
+-->
+`kube-apiserver` 从 1.10 版本开始提供 Table 响应。
+因此，并非所有 API 资源类型都支持 Table 响应，尤其是使用客户端访问较老的集群时。
+如果客户端需要能够处理所有资源类型，或者有可能需要与较老的集群交互，
+则需要在其 `Accept` 头部设定多个内容类型值，以便可以回退到非表格形式的 JSON
+表示。
+
+```
+Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1, application/json
+```
+
+<!--
+## Alternate representations of resources
+
+By default Kubernetes returns objects serialized to JSON with content type `application/json`. This is the default serialization format for the API. However, clients may request the more efficient Protobuf representation of these objects for better performance at scale. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header with a `GET` call will request that the server return objects in the provided content type, while sending an object in Protobuf to the server for a `PUT` or `POST` call takes the `Content-Type` header. The server will return a `Content-Type` header if the requested format is supported, or the `406 Not acceptable` error if an invalid content type is provided.
+
+See the API documentation for a list of supported content types for each API.
+
+For example:
+-->
+## 资源的其他表示形式
+
+默认情况下，Kubernetes 返回 JSON 序列化的的对象并设定内容类型为
+`application/json`。这是 API 的默认序列化格式。
+不过，客户端也可出于大规模环境中更佳性能的需求而请求对象的更为高效的 Protobuf
+表现形式。
+Kubernetes API 实现了标准的 HTTP 内容类型协商：为 `GET` 调用传递一个 `Accept`
+头部来请求服务器以所指定的内容类型返回对象，同时在通过 `PUT` 或 `POST` 调用
+向服务器发送 Protobuf 格式的对象时提供 `Content-Type` 头部。
+服务器会能够支持所请求的格式时返回 `Content-Type` 头部，并在所提供的内容类型
+不合法时返回 `406 Not acceptable（无法接受）` 错误。
+
+请参阅 API 文档了解每个 API 所支持的内容类型。
+
+例如：
+
+<!--
+1. List all of the pods on a cluster in Protobuf format.
+-->
+1. 以 Protobuf 格式列举集群上的所有 Pods：
+
+```console
+GET /api/v1/pods
+Accept: application/vnd.kubernetes.protobuf
+---
+200 OK
+Content-Type: application/vnd.kubernetes.protobuf
+
+... binary encoded PodList object
+```
+
+<!--
+2. Create a pod by sending Protobuf encoded data to the server, but request a response in JSON.
+-->
+2. 通过向服务器发送 Protobuf 编码的数据创建 Pod，但请求以 JSON 形式接收响应：
+
+```console
+POST /api/v1/namespaces/test/pods
+Content-Type: application/vnd.kubernetes.protobuf
+Accept: application/json
+... binary encoded Pod object
+---
+200 OK
+Content-Type: application/json
+
+{
+  "kind": "Pod",
+  "apiVersion": "v1",
+  ...
+}
+```
+
+<!--
+Not all API resource types will support Protobuf, specifically those defined
+via Custom Resource Definitions or those that are API extensions. Clients that
+must work against all resource types should specify multiple content types in
+their `Accept` header to support fallback to JSON:
+-->
+并非所有 API 资源类型都支持 Protobuf，尤其是那些通过定制资源定义（CRD）或通过
+API 扩展而加入的资源。如果客户端必须能够处理所有资源类型，则应在其 `Accept`
+头部指定多种内容类型以便可以回退到 JSON 格式：
+
+```
+Accept: application/vnd.kubernetes.protobuf, application/json
+```
+
+<!--
+### Protobuf encoding
+
+Kubernetes uses an envelope wrapper to encode Protobuf responses. That wrapper starts with a 4 byte magic number to help identify content in disk or in etcd as Protobuf (as opposed to JSON), and then is followed by a Protobuf encoded wrapper message, which describes the encoding and type of the underlying object and then contains the object.
+
+The wrapper format is:
+-->
+### Protobuf encoding
+
+Kubernetes 使用封套形式来对 Protobuf 响应进行编码。
+封套外层由 4 个字节的特殊数字开头，便于从磁盘文件或 etcd 中辩识 Protobuf
+格式的（而不是 JSON）数据。
+接下来存放的是 Protobuf 编码的封套消息，其中描述下层对象的编码和类型，最后
+才是对象本身。
+
+封套格式如下：
+
+<!--
+```
+A four byte magic number prefix:
+  Bytes 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]
+
+An encoded Protobuf message with the following IDL:
+  message Unknown {
+    // typeMeta should have the string values for "kind" and "apiVersion" as set on the JSON object
+    optional TypeMeta typeMeta = 1;
+
+    // raw will hold the complete serialized object in protobuf. See the protobuf definitions in the client libraries for a given kind.
+    optional bytes raw = 2;
+
+    // contentEncoding is encoding used for the raw data. Unspecified means no encoding.
+    optional string contentEncoding = 3;
+
+    // contentType is the serialization method used to serialize 'raw'. Unspecified means application/vnd.kubernetes.protobuf and is usually
+    // omitted.
+    optional string contentType = 4;
+  }
+
+  message TypeMeta {
+    // apiVersion is the group/version for this type
+    optional string apiVersion = 1;
+    // kind is the name of the object schema. A protobuf definition should exist for this object.
+    optional string kind = 2;
+  }
+```
+-->
+```
+四个字节的特殊数字前缀：
+  字节 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00]
+
+使用下面 IDL 来编码的 Protobuf 消息：
+  message Unknown {
+    // typeMeta 应该包含 "kind" 和 "apiVersion" 的字符串值，就像
+    // 对应的 JSON 对象中所设置的那样
+    optional TypeMeta typeMeta = 1;
+
+    // raw 中将保存用 protobuf 序列化的完整对象。
+    // 参阅客户端库中为指定 kind 所作的 protobuf 定义
+    optional bytes raw = 2;
+
+    // contentEncoding 用于 raw 数据的编码格式。未设置此值意味着没有特殊编码。
+    optional string contentEncoding = 3;
+
+    // contentType 包含 raw 数据所采用的序列化方法。
+    // 未设置此值意味着  application/vnd.kubernetes.protobuf，且通常被忽略
+    optional string contentType = 4;
+  }
+
+  message TypeMeta {
+    // apiVersion 是 type 对应的组名/版本
+    optional string apiVersion = 1;
+    // kind 是对象模式定义的名称。此对象应该存在一个 protobuf 定义。
+    optional string kind = 2;
+  }
+```
+
+<!--
+Clients that receive a response in `application/vnd.kubernetes.protobuf` that does not match the expected prefix should reject the response, as future versions may need to alter the serialization format in an incompatible way and will do so by changing the prefix.
+-->
+收到 `application/vnd.kubernetes.protobuf` 格式响应的客户端在响应与预期的前缀
+不匹配时应该拒绝响应，因为将来的版本可能需要以某种不兼容的方式更改序列化格式，
+并且这种更改是通过变更前缀完成的。
+
+<!--
+## Resource deletion
+
+Resources are deleted in two phases: 1) finalization, and 2) removal.
+-->
+## 资源删除
+
+资源删除要经过两个阶段：1) 终止（finalization），和 2）去除。
+
+```json
+{
+  "kind": "ConfigMap",
+  "apiVersion": "v1",
+  "metadata": {
+    "finalizers": {"url.io/neat-finalization", "other-url.io/my-finalizer"},
+    "deletionTimestamp": nil,
+  }
+}
+```
+
+<!--
+When a client first deletes a resource, the `.metadata.deletionTimestamp` is
+set to the current time.  Once the `.metadata.deletionTimestamp` is set,
+external controllers that act on finalizers may start performing their cleanup
+work at any time, in any order.  Order is NOT enforced because it introduces
+significant risk of stuck `.metadata.finalizers`.  `.metadata.finalizers` is a
+shared field, any actor with permission can reorder it.  If the finalizer list
+is processed in order, then this can lead to a situation in which the
+component responsible for the first finalizer in the list is waiting for a
+signal (field value, external system, or other) produced by a component
+responsible for a finalizer later in the list, resulting in a deadlock.
+Without enforced ordering finalizers are free to order amongst themselves and
+are not vulnerable to ordering changes in the list.
+
+Once the last finalizer is removed, the resource is actually removed from
+etcd.
+-->
+当客户端首先删除某资源时，其 `.metadata.deletionTimestamp` 会被设置为当前时间。
+一旦 `.metadata.deletionTimestamp` 被设置，则对终结器（finalizers）执行动作
+的外部控制器就可以在任何时候、以任何顺序执行其清理工作。
+这里不强调顺序是因为很可能带来 `.metadata.finalizers` 被锁定的风险。
+`.metadata.finalizers` 是一个共享的字段，任何具有相关权限的主体都可以对其
+执行重排序的操作。如果终结器列表要按顺序处理，则很可能导致负责列表中第一个
+终结器的组件要等待负责列表中排序靠后的终结器的组件的信号（可能是字段值变更、
+外部系统或者其他形式），从而导致死锁行为。
+在不对终结器顺序作强制要求的情况下，终结器可以自行排序，且不会因为其在列表
+中的顺序而引入任何不稳定因素。
+
+当最后一个终结器也被移除时，资源才真正从 etcd 中移除。
+
+<!--
+## Single resource API
+
+API verbs GET, CREATE, UPDATE, PATCH, DELETE and PROXY support single resources only.
+These verbs with single resource support have no support for submitting
+multiple resources together in an ordered or unordered list or transaction.
+Clients including kubectl will parse a list of resources and make
+single-resource API requests.
+
+API verbs LIST and WATCH support getting multiple resources, and
+DELETECOLLECTION supports deleting multiple resources.
+-->
+## 单个资源 API  {#single-resource-api}
+
+API 动词 GET、CREATE、UPDATE、PATCH、DELETE 和 PROXY 仅支持单个资源。
+这些支持单一资源的动词不支持以有序或无序列表甚或事务的形式同时提交给
+多个资源。
+包括 kubectl 在内的客户端将解析资源的列表，并执行单一资源的 API 请求。
+
+API 动词 LIST 和 WATCH 支持获取多个资源，而 DELETECOLLECTION 支持删除多个
+资源。
+
+<!--
+## Dry-run
+-->
+## 试运行  {#dry-run}
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+<!--
+The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a _dry run_ mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non-dry-run response. The system guarantees that dry-run requests will not be persisted in storage or have any other side effects.
+-->
+修改性质的动词（`POST`、`PUT`、`PATCH` 和 `DELETE`）可以支持 _试运行（dry
+run）_ 模式的请求。试运行模式可帮助通过典型的请求阶段（准入控制链、合法性
+检查、合并冲突）来评估请求，只是最终的对象不会写入存储。请求的响应主体与
+非试运行模式下的响应尽可能接近。系统会保证试运行模式的请求不会被写入到存储
+中，也不会产生其他副作用。
+
+<!--
+### Make a dry-run request
+
+Dry-run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and the only accepted values are:
+
+* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry-run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry-run requests.
+* Leave the value empty, which is also the default: Keep the default modifying behavior.
+
+For example:
+-->
+### 发起试运行请求  {#make-a-dry-run-request}
+
+通过设置 `dryRun` 查询参数可以触发试运行模式。此参数是一个字符串，以枚举值
+的形式工作且可接受的值只有：
+
+* `All`：每个阶段被会正常运行，除了最后的存储阶段。准入控制器会被运行来检查请求
+  是否合法，变更性（Mutating）控制器会变更请求，`PATCH` 请求也会触发合并操作，
+  对象字段的默认值也会被设置，且基于模式定义的合法性检查也会被执行。
+  所生成的变更不会被写入到下层的持久性存储中，但本来会写入到数据库中的最终对象
+  会和正常的状态代码一起被返回给用户。如果请求会触发准入控制器而该准入控制器
+  带有一定的副作用，则请求会失败而不是冒险产生不希望的副作用。
+  所有的内置准入控制器插件都支持试运行模式。此外，准入控制 Webhook 也可在其
+  [配置对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#webhook-v1beta1-admissionregistration-k8s-io)
+  中通过将 `sideEffects` 字段设置为 "None" 来声明自身不会产生副作用。
+  如果某 Webhook 确实会产生副作用，那么 `sideEffects` 字段应该设置为 "NoneOnDryRun"，
+  并且 Webhook 应该被更改以支持 AdmissionReview 中的 `dryRun` 字段，从而避免
+  在试运行时产生副作用。
+
+* 空字符串（也即默认值）：保留默认的修改行为。
+
+例如：
+
+```console
+POST /api/v1/namespaces/test/pods?dryRun=All
+Content-Type: application/json
+Accept: application/json
+```
+
+<!--
+The response would look the same as for non-dry-run request, but the values of some generated fields may differ.
+-->
+响应会与非试运行模式请求的响应看起来相同，只是某些生成字段的值可能会不同。
+
+<!--
+### Dry-run authorization
+
+Authorization for dry-run and non-dry-run requests is identical. Thus, to make
+a dry-run request, the user must be authorized to make the non-dry-run request.
+
+For example, to run a dry-run `PATCH` for Deployments, you must have the
+`PATCH` permission for Deployments, as in the example of the RBAC rule below.
+-->
+### 试运行的授权    {#dry-run-authorization}
+
+试运行和非试运行请求的鉴权是完全相同的。因此，要发起一个试运行请求，用户必须
+被授权执行非试运行请求。
+
+例如，要在 Deployment 对象上试运行 `PATCH` 操作，你必须具有对 Deployment 执行
+`PATCH` 操作的访问权限，如下面的 RBAC 规则所示：
+
+```yaml
+rules:
+- apiGroups: ["extensions", "apps"]
+  resources: ["deployments"]
+  verbs: ["patch"]
+```
+
+<!--
+See [Authorization Overview](/docs/reference/access-authn-authz/authorization/).
+-->
+参阅[鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)以了解鉴权细节。
+
+<!--
+### Generated values
+
+Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry-run request, since these values will likely be different in dry-run mode from when the real request is made. Some of these fields are:
+
+* `name`: if `generateName` is set, `name` will have a unique random name
+* `creationTimestamp`/`deletionTimestamp`: records the time of creation/deletion
+* `UID`: uniquely identifies the object and is randomly generated (non-deterministic)
+* `resourceVersion`: tracks the persisted version of the object
+* Any field set by a mutating admission controller
+* For the `Service` resource: Ports or IPs that kube-apiserver assigns to v1.Service objects
+-->
+### 生成的值  {#generated-values}
+
+对象的某些值通常是在对象被写入数据库之前生成的。很重要的一点是不要依赖试运行
+请求为这些字段所设置的值，因为试运行模式下所得到的这些值与真实请求所获得的
+值很可能不同。这类字段有：
+
+* `name`：如果设置了 `generateName` 字段，则 `name` 会获得一个唯一的随机名称
+* `creationTimestamp`/`deletionTimestamp`：记录对象的创建/删除时间
+* `UID`：唯一性标识对象，取值随机生成（非确定性）
+* `resourceVersion`： 跟踪对象的持久化（存储）版本
+* 变更性准入控制器所设置的字段
+* 对于 `Service` 资源：`kube-apiserver` 为 `v1.Service` 对象分配的端口和 IP
+
+<!--
+## Server Side Apply
+-->
+## 服务器端应用  {#server-side-apply}
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+<!--
+Starting from Kubernetes v1.18, if you have Server Side Apply enabled then the
+control plane tracks managed fields for all newly created objects.
+-->
+从 Kubernetes v1.18 开始，如果你启动了服务器端应用（Service Side Apply）功能
+特性，则控制面会跟踪所有新创建的对象的托管字段（Managed Fields）。
+
+<!--
+### Introduction
+
+Server Side Apply helps users and controllers manage their resources via
+declarative configurations. It allows them to create and/or modify their
+objects declaratively, simply by sending their fully specified intent.
+
+A fully specified intent is a partial object that only includes the fields and
+values for which the user has an opinion. That intent either creates a new
+object or is [combined](#merge-strategy), by the server, with the existing object.
+
+The system supports multiple appliers collaborating on a single object.
+-->
+### 介绍  {#introduction}
+
+服务器端应用可以通过声明式配置帮助用户和控制器管理其资源。此功能特性允许
+用户和控制器通过将完全设定的意愿发送到服务器以声明式方式创建与/或更改其对象。
+
+完全设定的意愿（Fully Specified Intent）是对象的一个部分，仅包含用户希望表达
+其意愿的字段和取值。此意愿或者是要创建一个新的对象，或者是由服务器来负责
+完成的、与现有对象的[合并](#merge-strategy)。
+
+系统支持多个施加者（Applier）同一个对象上进行协作。
+
+<!--
+Changes to an object's fields are tracked through a "[field management](#field-management)"
+mechanism. When a field's value changes, ownership moves from its current
+manager to the manager making the change. When trying to apply an object, fields
+that have a different value and are owned by another manager will result in a
+[conflict](#conflicts). This is done in order to signal that the operation might undo another
+collaborator's changes. Conflicts can be forced, in which case the value will be
+overridden, and the ownership will be transferred.
+-->
+对对象字段的变更是通过“[字段管理](#field-management)”来进行跟踪的。
+当字段的值发生变化时，其属主从其当前的管理器切换为作出变更的管理器。
+尝试应用对象时，取值不同的字段以及由另一个管理器所拥有的字段都会导致
+[冲突](#conflicts)。引发冲突的目的是通告该操作可能会撤销掉另一协作方
+所做的变更。冲突可以被强制解决，从而导致字段取值被覆盖且其属主关系
+被转移。
+
+<!--
+If you remove a field from a configuration and apply the configuration, server side apply checks
+if there are any other field managers that also own the field.  If the field is
+not owned by any other field managers, it is either deleted from the live
+object or reset to its default value, if it has one. The same rule applies to associative list or
+map items.
+
+Server side apply is meant both as a replacement for the original `kubectl
+apply` and as a simpler mechanism for controllers to enact their changes.
+-->
+如果你从配置中去除了一个字段并应用该配置，服务器端应用组件会检查是否有其他字段
+管理器也拥有该字段。如果该字段不再被任何其他字段管理器所拥有，则或者它会被
+从现时对象上删除，或者会被重置为其默认值（假设有的话）。
+同样的规则也适用于关联列表或映射条目。
+
+服务器端应用旨在成为原来的 `kubectl apply` 的替代技术，同时也作为控制器来
+施加其变更的一种更简单的机制。
+
+<!--
+### Field Management
+
+Compared to the `last-applied` annotation managed by `kubectl`, Server Side
+Apply uses a more declarative approach, which tracks a user's field management,
+rather than a user's last applied state. This means that as a side effect of
+using Server Side Apply, information about which field manager manages each
+field in an object also becomes available.
+
+For a user to manage a field, in the Server Side Apply sense, means that the
+user relies on and expects the value of the field not to change. The user who
+last made an assertion about the value of a field will be recorded as the
+current field manager. This can be done either by changing the value with
+`POST`, `PUT`, or non-apply `PATCH`, or by including the field in a config sent
+to the Server Side Apply endpoint. When using Server-Side Apply, trying to
+change a field which is managed by someone else will result in a rejected
+request (if not forced, see [Conflicts](#conflicts)).
+-->
+### 字段管理    {#field-management}
+
+与 `kubectl` 所管理的 `last-applied` 注解相比，服务器端应用机制使用的是一种
+更为贴近声明式管理的方法。该方法会跟踪用户的字段管理而不是其上一次应用的
+状态。这就意味着，作为服务器端应用的一种副作用，关于哪个字段管理器管理对象中
+哪个字段的信息也变得透明。
+
+从服务器端应用的角度，让用户来管理字段意味着用户可以相信并期望字段不会发生变更。
+上次对某字段取值做出断言的用户会被记录为当前的字段管理器。
+这一记录操作可以通过使用 `POST`、`PUT` 或非应用性（non-apply）的 `PATCH` 去
+更改字段值来实现，或者将字段包含在发送该服务器端应用末端的配置中来实现。
+当使用服务器端应用特性时，尝试更给由其他人所管理的字段会导致请求被拒绝
+（这里指非强制应用场景，参见[冲突](#conflicts)）。
+
+<!--
+When two or more appliers set a field to the same value, they share ownership of
+that field. Any subsequent attempt to change the value of the shared field, by any of
+the appliers, results in a conflict. Shared field owners may give up ownership
+of a field by removing it from their configuration.
+
+Field management is stored in a`managedFields` field that is part of an object's
+[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta).
+
+A simple example of an object created by Server Side Apply could look like this:
+-->
+当两个或者多个施加者将某字段设置为相同的值，它们会共享字段的属主地位。
+由任何施加者所发起的、尝试变更共享字段取值的请求都会导致冲突。
+共享字段的属主可以通过将字段从其配置中去除来放弃其属主角色。
+
+字段管理信息保存在 `managedFields` 字段中，而该字段是对象
+[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta)
+的一部分。
+
+通过服务器端应用创建的对象的一个简单例子看起来可能像这样：
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: test-cm
+  namespace: default
+  labels:
+    test-label: test
+  managedFields:
+  - manager: kubectl
+    operation: Apply
+    apiVersion: v1
+    time: "2010-10-10T0:00:00Z"
+    fieldsType: FieldsV1
+    fieldsV1:
+      f:metadata:
+        f:labels:
+          f:test-label: {}
+      f:data:
+        f:key: {}
+data:
+  key: some value
+```
+
+<!--
+The above object contains a single manager in `metadata.managedFields`. The
+manager consists of basic information about the managing entity itself, like
+operation type, api version, and the fields managed by it.
+
+This field is managed by the apiserver and should not be changed by
+the user.
+
+Nevertheless it is possible to change `metadata.managedFields` through an
+`Update` operation. Doing so is highly discouraged, but might be a reasonable
+option to try if, for example, the `managedFields` get into an inconsistent
+state (which clearly should not happen).
+
+The format of the `managedFields` is described in the [API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta).
+-->
+上面的对象在其 `metadata.managedFields` 中包含了唯一的管理器。管理器记录中
+包含了管理实体自身的一些基本信息，例如操作类型、API 版本以及所管理的字段。
+
+此字段由 API 服务器管理，因而不应被用户修改。
+
+尽管如此，通过 `Update` 操作来更改 `metadata.managedFields` 字段值还是可能的。
+这样做是非常不鼓励的，但在某些场合也可能是一种合理的选择。例如，`managedFields`
+陷入了某种不一致的状态（很明显这种事不应该发生）。
+
+`managedFields` 的格式在[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta)
+中有详细描述。
+
+### 冲突    {#conflicts}
+
+<!--
+A conflict is a special status error that occurs when an `Apply` operation tries
+to change a field, which another user also claims to manage. This prevents an
+applier from unintentionally overwriting the value set by another user. When
+this occurs, the applier has 3 options to resolve the conflicts:
+-->
+冲突是一种特殊的状态错误，发生在某 `Apply` 操作尝试变更某字段，而另一个用户
+也声称要管理之的时候。冲突的检测可以避免某一施加者不小心覆盖另一个用户所设置
+的字段值。当发生冲突时，解决它的方法有三种：
+
+<!--
+* **Overwrite value, become sole manager:** If overwriting the value was
+  intentional (or if the applier is an automated process like a controller) the
+  applier should set the `force` query parameter to true and make the request
+  again. This forces the operation to succeed, changes the value of the field,
+  and removes the field from all other managers' entries in managedFields.
+
+* **Don't overwrite value, give up management claim:** If the applier doesn't
+  care about the value of the field anymore, they can remove it from their
+  config and make the request again. This leaves the value unchanged, and causes
+  the field to be removed from the applier's entry in managedFields.
+
+* **Don't overwrite value, become shared manager:** If the applier still cares
+  about the value of the field, but doesn't want to overwrite it, they can
+  change the value of the field in their config to match the value of the object
+  on the server, and make the request again. This leaves the value unchanged,
+  and causes the field's management to be shared by the applier and all other
+  field managers that already claimed to manage it.
+-->
+- **覆盖字段值，成为唯一的管理器：** 如果有意要覆盖字段值（或者施加者本身是
+  一个控制器这种自动化进程），施加者应该设置查询参数 `force` 为 `true，并
+  再次发出请求。这样做会强迫操作成功，更改字段值，将字段从 `managedFields`
+  中其他管理器项中去除。
+
+- **不重载字段值，放弃管理主张：** 如果施加者不再关心字段取值，它们可以将字段
+  从其配置中删除并再次发出请求。这样做会保留字段值不变，同时从 `managedFields`
+  中施加者条目中删除该字段。
+
+- **不重载字段值，成为共享管理器：** 如果施加者仍然关心字段取值，但不想重载
+  其当前值，它可以将其配置中该字段的值更改为与服务器端对象上的值匹配，并再次
+  发出请求。这样做会保留字段取值不变，同时使得字段的管理权力被施加者以及所有
+  原来声称要管理该字段的其他字段管理器一起分享。
+
+<!--
+### Managers
+
+Managers identify distinct workflows that are modifying the object (especially
+useful on conflicts!), and can be specified through the `fieldManager` query
+parameter as part of a modifying request. It is required for the apply endpoint,
+though kubectl will default it to `kubectl`. For other updates, its default is
+computed from the user-agent.
+-->
+### 管理器   {#managers}
+
+管理器标示更改对象的不同工作流（尤其是在有冲突的场合），可以作为更改对象的请求
+的一部分，在 `fieldManager` 查询参数中设定。该参数对于 Apply 操作的端点是必需
+的，尽管 `kubectl` 会将其默认设置为 `kubectl`。对于其他更新操作，其默认值是
+基于用户代理（User-agent）计算而来的。
+
+<!--
+### Apply and Update
+
+The two operation types considered by this feature are `Apply` (`PATCH` with
+content type `application/apply-patch+yaml`) and `Update` (all other operations
+which modify the object). Both operations update the `managedFields`, but behave
+a little differently.
+-->
+### 应用与更新    {#apply-and-update}
+
+服务器端应用所考虑的两种操作分别是 `Apply` （内容类型设置为
+`application/apply-patch+yaml` 的 `PATCH` 操作）和 `Update`（所有其他会更改
+对象的操作）。这两种操作都会更新 `managedFields` 字段值，但其行为略有不同。
+
+<!--
+Whether you are submitting JSON data or YAML data, use `application/apply-patch+yaml` as the
+Content-Type header value.
+
+All JSON documents are valid YAML.
+-->
+{{< note >}}
+无论你所提交的是 JSON 数据或者 YAML 数据，都应将 `Content-Type` 头部字段
+的值设置为 `application/apply-patch+yaml`。
+
+所有 JSON 文档也都是合法的 YAML 文档。
+{{< /note >}}
+
+<!--
+For instance, only the apply operation fails on conflicts while update does
+not. Also, apply operations are required to identify themselves by providing a
+`fieldManager` query parameter, while the query parameter is optional for update
+operations. Finally, when using the apply operation you cannot have `managedFields` in the object that is being applied.
+
+An example object with multiple managers could look like this:
+-->
+例如，发生冲突时只有 Apply 操作会失败，而 Update 操作不会失败。
+还有，Apply 操作要求通过提供一个 `fieldManager` 查询参数来标识自身，而
+对于 Update 操作而言，这一查询参数是可选的。
+最后，使用 Apply 操作时，被应用的对象中不能包含 `managedFields` 字段。
+
+带有多个管理器的一个对象示例可能看起来是这个样子：
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: test-cm
+  namespace: default
+  labels:
+    test-label: test
+  managedFields:
+  - manager: kubectl
+    operation: Apply
+    apiVersion: v1
+    fields:
+      f:metadata:
+        f:labels:
+          f:test-label: {}
+  - manager: kube-controller-manager
+    operation: Update
+    apiVersion: v1
+    time: '2019-03-30T16:00:00.000Z'
+    fields:
+      f:data:
+        f:key: {}
+data:
+  key: new value
+```
+
+<!--
+In this example, a second operation was run as an `Update` by the manager called
+`kube-controller-manager`. The update changed a value in the data field which
+caused the field's management to change to the `kube-controller-manager`.
+-->
+在此例中，第二个操作是由一个称作 `kube-controller-manager` 的管理器所发起的
+`Update` 执行的。该 Update 操作更改了 data 字段的值，导致该字段的管理者被更改
+为 `kube-controller-manager`。
+
+<!--
+If this update would have been an `Apply` operation, the operation
+would have failed due to conflicting ownership.
+-->
+{{< note >}}
+如果此操作是一个 Apply 操作，则操作可能已因为属主冲突而失败。
+{{< /note >}}
+
+<!--
+### Merge strategy
+
+The merging strategy, implemented with Server Side Apply, provides a generally
+more stable object lifecycle. Server Side Apply tries to merge fields based on
+the fact who manages them instead of overruling just based on values. This way
+it is intended to make it easier and more stable for multiple actors updating
+the same object by causing less unexpected interference.
+
+When a user sends a "fully-specified intent" object to the Server Side Apply
+endpoint, the server merges it with the live object favoring the value in the
+applied config if it is specified in both places. If the set of items present in
+the applied config is not a superset of the items applied by the same user last
+time, each missing item not managed by any other appliers is removed. For
+more information about how an object's schema is used to make decisions when
+merging, see
+[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff).
+-->
+### 合并策略   {#merge-strategy}
+
+服务器端应用所实现的合并策略能够支持相对更为稳定的对象生命周期。
+服务器端应用机制尝试基于字段的管理器是谁来合并字段而不是仅仅基于字段取值来判断。
+这种机制旨在通过减少意外的干扰而将多个主体更新同一对象的操作变得更为简单和稳定。
+
+当用户发送一个“完全指定的意愿”对象到服务器端应用端点，如果字段值同时出现在现时
+对象中和所给的意愿对象中，服务器会优先选择应用配置中的字段值。
+如果应用的配置中存在的条目集合不是同一用户上次应用的条目集合的超集，所有未被其他
+施加者管理的、在应用的配置中缺失的条目都会被移除。
+关于如何使用对象的模式定义（Schema）来决定合并行为的更多信息，可参阅
+[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff)。
+
+<!--
+A number of markers were added in Kubernetes 1.16 and 1.17, to allow API
+developers to describe the merge strategy supported by lists, maps, and
+structs. These markers can be applied to objects of the respective type,
+in Go files or in the [OpenAPI schema definition of the
+CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io):
+-->
+Kubernetes 1.16 和 1.17 中都添加了若干的标志（Markers），便于 API 开发人员
+描述 list、map 和 struct 所支持的合并策略。这些标志可以应用到 Go 文件中
+对应类型的对象或者 [CRD 的 OpenAPI 模式定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)：
+
+<!--
+| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
+|----|----|----|----|----|
+| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16          |
+| `//+listMapKey` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. While there can be multiple keys, `listMapKey` is singular because keys need to be specified individually in the Go type. | 1.16 |
+| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
+| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |
+-->
+| Golang 标志 | OpenAPI 扩展 | 可接受的值 | 描述 | 引入版本 |
+|---|---|---|---|---|
+| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | 可应用到 list 类型。`atomic` 和 `set` 适用于仅包含标量的 list。`map` 适用于由内嵌类型组成的  list。如果配置为 `atomic`，则整个 list 会在合并时被替换掉；每次只会有一个管理器负责总体管理这个 list。如果配置为 `granular`，则不同的管理器可以分别管理不同的表项。 | 1.16  |
+| `//+listMapKey` | `x-kubernetes-list-map-keys` | 由 map 主键构成的可唯一标识表项的切片，例如 `["port", "protocol"]` | 仅当标记了 `+listType=map` 时适用。切片中各个字符串对应的取值的组合必须能够唯一性地标识 list 中的表项。尽管主键可以有多个，由于在 Go 语言类型中每个键需要独立设置，这里的 `listMapKey` 是单数形式。 | 1.16 |
+| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 map 类型。`atomic` 意味着 map 只能被某管理器整体替换。`granular` 则意味着 map 支持使用不同管理器来更新不同字段。 | 1.17 |
+| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 struct 类型。除此以外，其用法和 OpenAPI 注解都与 `//+mapType` 相同。 | 1.17 |
+
+<!--
+### Custom Resources
+
+By default, Server Side Apply treats custom resources as unstructured data. All
+keys are treated the same as struct fields, and all lists are considered atomic.
+
+If the Custom Resource Definition defines a
+[schema](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)
+that contains annotations as defined in the previous "Merge Strategy"
+section, these annotations will be used when merging objects of this
+type.
+-->
+### 定制资源  {#custom-resources}
+
+默认情况下，服务器端应用机制会将定制资源视为无结构的数据。其中所有键都会
+被视同 struct 的字段，而所有 list 都会被视为 atomic。
+
+如果定制资源定义（CRD）定义了包含如[合并策略](#merge-strategy)节所述的注解的
+[模式定义（Schema）](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)，
+则在合并该类型对象时会使用到这些注解。
+
+<!--
+### Using Server-Side Apply in a controller
+
+As a developer of a controller, you can use server-side apply as a way to
+simplify the update logic of your controller. The main differences with a
+read-modify-write and/or patch are the following:
+
+* the applied object must contain all the fields that the controller cares about.
+* there are no way to remove fields that haven't been applied by the controller
+  before (controller can still send a PATCH/UPDATE for these use-cases).
+* the object doesn't have to be read beforehand, `resourceVersion` doesn't have
+  to be specified.
+
+It is strongly recommended for controllers to always "force" conflicts, since they
+might not be able to resolve or act on these conflicts.
+-->
+### 在控制器中使用服务器端应用机制  {#using-server-side-apply-in-a-controller}
+
+作为控制器的开发人员，你可以将服务器端应用机制作为一种方法来简化你的控制器中的更新逻辑。
+与“读出-更改-写回”或“读出-更改-打补丁”方式相比，区别如下：
+
+* 所应用的对象必需包含控制器所关心的所有字段；
+* 没有办法移除控制器之前未曾应用过的字段（控制器在这些使用场景中仍然可以发送一个
+  PATCH/UPDATE 请求）。
+* 对象不需要事先读出，且不必指定 `resourceVersion` 值。
+
+强烈建议控制器总是“强制解决”冲突，因为它们可能无法更好地解决或者处理这些冲突。
+
+<!--
+### Transferring Ownership
+
+In addition to the concurrency controls provided by [conflict
+resolution](#conflicts), Server Side Apply provides ways to perform coordinated
+field ownership transfers from users to controllers.
+
+This is best explained by example. Let's look at how to safely transfer
+ownership of the `replicas` field from a user to a controller while enabling
+automatic horizontal scaling for a Deployment, using the HorizontalPodAutoscaler
+resource and its accompanying controller.
+
+Say a user has defined deployment with `replicas` set to the desired value:
+-->
+### 转移属主关系   {#transferring-ownership}
+
+除了[冲突解决](#conflicts)机制所提供的并发控制外，服务器端应用机制还提供了一些
+方法，通过协作式途径将字段属主从用户转移到控制器。
+
+这一转移操作最好通过示例来阐明。我们来看如何安全地将 `replicas` 字段的属主从
+一个用户转移给一个控制器，同时允许使用 HorizontalPodAutoscaler 资源及其相配套
+的控制器为 Deployment 提供自动的水平扩缩。
+
+假定一个用户定义了一个 Deployment，并将其 `replicas` 设置为其期望值：
+
+{{< codenew file="application/ssa/nginx-deployment.yaml" >}}
+
+<!--
+And the user has created the deployment using server side apply like so:
+-->
+用户使用服务器端应用机制创建了 Deployment：
+
+```shell
+kubectl apply -f application/ssa/nginx-deployment.yaml --server-side
+```
+
+<!--
+Then later, HPA is enabled for the deployment, e.g.:
+-->
+再接下来，为 Deployment 启用了 HPA，例如：
+
+```shell
+kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10
+```
+
+<!--
+Now, the user would like to remove `replicas` from their configuration, so they
+don't accidentally fight with the HPA controller. However, there is a race: it
+might take some time before HPA feels the need to adjust `replicas`, and if
+the user removes `replicas` before the HPA writes to the field and becomes
+its owner, then apiserver will set `replicas` to 1, its default value. This
+is not what the user wants to happen, even temporarily.
+-->
+现在，用户希望将 `replicas` 从其配置中移除，这样它们就不会与 HPA
+控制器产生冲突。不过，仍然会有竞争条件出现：在 HPA 觉得需要调整 `replicas`
+之前可能还有一段时间。如果用户在向 `replicas` 字段写入新值进而成为其属主之前，
+已经从配置中移除了该字段，则 API 服务器会将 `replicas` 设置为 1，也就是该字段
+的默认值。这一复位操作并非用户希望发生的事情，即使是临时性的复位也不可以。
+
+<!--
+There are two solutions:
+
+- (easy) Leave `replicas` in the configuration; when HPA eventually writes to that
+  field, the system gives the user a conflict over it. At that point, it is safe
+  to remove from the configuration.
+
+- (more advanced) If, however, the user doesn't want to wait, for example
+  because they want to keep the cluster legible to coworkers, then they can take
+  the following steps to make it safe to remove `replicas` from their
+  configuration:
+-->
+解决方案有两种：
+
+- （较容易的方案）在配置中保留 `replicas`，当 HPA 终于向该字段中写入取值时，
+  系统会向用户报告一个冲突事件。在这一刻，从配置中移除该字段是相对安全的。
+
+- （更高级的方案）如果用户不想等待 HPA 写入字段值的事件，例如他们希望集群状态对
+  他们的同事而言也是清晰明确的，则他们可以采取以下步骤安全地从他们的配置中移除
+  `replicas` 字段。
+
+<!--
+First, the user defines a new configuration containing only the `replicas` field:
+-->
+首先，用户定义一个新的，仅包含 `replicas` 字段的配置：
+
+{{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}}
+
+<!--
+The user applies that configuration using the field manager name `handover-to-hpa`:
+-->
+接下来使用名为 `handover-to-hpa` 的字段管理器应用该配置：
+
+```shell
+kubectl apply -f application/ssa/nginx-deployment-replicas-only.yaml --server-side --field-manager=handover-to-hpa --validate=false
+```
+
+<!--
+If the apply results in a conflict with the HPA controller, then do nothing. The
+conflict just indicates the controller has claimed the field earlier in the
+process than it sometimes does.
+
+At this point the user may remove the `replicas` field from their configuration.
+-->
+如果应用操作与 HPA 控制器发生冲突，则什么也不做。冲突恰好表明控制器比平时早了
+一点发出对该字段的主张：
+
+这时，用户可以从其配置中删除 `replicas` 字段。
+
+{{< codenew file="application/ssa/nginx-deployment-no-replicas.yaml" >}}
+
+<!--
+Note that whenever the HPA controller sets the `replicas` field to a new value,
+the temporary field manager will no longer own any fields and will be
+automatically deleted. No clean up is required.
+-->
+注意，无论 HPA 控制器何时将 `replicas` 字段设置为新的取值，临时性的字段管理器
+都不再拥有任何字段，并且会被自动删除。用户不需要执行清理操作。
+
+<!--
+### Transferring Ownership Between Users
+
+Users can transfer ownership of a field between each other by setting the field
+to the same value in both of their applied configs, causing them to share
+ownership of the field. Once the users share ownership of the field, one of them
+can remove the field from their applied configuration to give up ownership and
+complete the transfer to the other user.
+-->
+### 在用户间移交属主角色     {#transferring-ownership-between-users}
+
+用户之间可以通过在他们所应用的配置中将字段设置为相同的值来转移字段属主关系，
+这样做会共享对字段的拥有权。一旦用户间共享了字段的属主关系，其中一个用户就
+可以从其所应用的配置中移除该字段，放弃属主角色，从而完成了属主关系的移交。
+
+<!--
+### Comparison with Client Side Apply
+
+A consequence of the conflict detection and resolution implemented by Server
+Side Apply is that an applier always has up to date field values in their local
+state. If they don't, they get a conflict the next time they apply. Any of the
+three options to resolve conflicts results in the applied configuration being an
+up to date subset of the object on the server's fields.
+
+This is different from Client Side Apply, where outdated values which have been
+overwritten by other users are left in an applier's local config. These values
+only become accurate when the user updates that specific field, if ever, and an
+applier has no way of knowing whether their next apply will overwrite other
+users' changes.
+
+Another difference is that an applier using Client Side Apply is unable to
+change the API version they are using, but Server Side Apply supports this use
+case.
+-->
+### 与客户端应用的比较   {#comparison-with-client-side-apply}
+
+服务器端应用机制所实现的冲突检测和解决方案的后果之一是施加者在其本地状态中总是
+能够看到最新的字段值。如果他们看不到，则在下次执行 Apply 操作时会收到冲突事件。
+解决冲突的三种方法中，任何一种都会让所应用的配置成为服务器端对象字段的最新
+子集。
+
+这点与客户端应用不同，施加者本地配置中保留的可能是已经被其他用户更改过了的过时
+的取值。只有用户更新该字段时，相应的字段值才会变得准确。施加者也无法知道他们
+下次执行 Apply 操作时是否会重载其他用户做出的变更。
+
+另外一点区别在于使用客户端应用的施加者无法更改他们所使用的 API
+版本，但是服务器端应用能够支持这种使用场景。
+
+<!--
+### Upgrading from client-side apply to server-side apply
+
+Client-side apply users who manage a resource with `kubectl apply` can start
+using server-side apply with the following flag.
+-->
+### 从客户端应用升级到服务器端应用   {#upgrading-from-client-side-apply-to-server-side-apply}
+
+客户端应用机制的用户如果在使用 `kubectl apply` 来管理资源，可以使用下面的标志
+来开始使用服务器端应用：
+
+```shell
+kubectl apply --server-side [--dry-run=server]
+```
+
+<!--
+By default, field management of the object transfers from client-side apply
+to kubectl server-side apply without encountering conflicts.
+-->
+默认情况下，对象的字段管理会从客户端应用转移到 kubectl
+服务器端应用，且不会出现冲突状况。
+
+<!--
+Keep the `last-applied-configuration` annotation up to date. The annotation infers client-side apply's managed fields. Any fields not managed by client-side apply raise conflicts.
+
+For example, if you used `kubectl scale` to update the replicas field after client-side apply,
+then this field is not owned by client-side apply and creates conflicts on `kubectl apply -server-side`.
+-->
+{{< caution >}}
+请保持 `last-applied-configuration` 注解内容是最新的。该注解用来推测客户端
+应用所管理的字段。所有没有被客户端应用管理的字段都会引发冲突。
+
+例如，如果你在客户端应用操作后使用 `kubectl scale` 命令更新了 `replicas`
+字段，该字段不再由客户端应用所拥有，在 `kubectl apply --server-side` 时会
+引发冲突。
+{{< /caution >}}
+
+<!--
+This behavior applies to server-side apply with the `kubectl` field manager. As
+an exception, you can opt-out of this behavior by specifying a different,
+non-default field manager, as seen in the following example. The default field manager for kubectl
+server-side apply is `kubectl`.
+-->
+此行为适用于使用 `kubectl` 字段管理器执行的服务器端应用。
+作为一种例外情况，你也可以选择不采用这种行为，而是像下面的例子中所给的那样，
+指定一个不同的、非默认的字段管理器。用 `kubectl` 来执行服务器端应用时，默认
+的字段管理器总是 `kubectl`。
+
+```shell
+kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
+```
+
+<!--
+### Downgrading from server-side apply to client-side apply
+
+If you manage a resource with `kubectl apply -server-side`,
+you can downgrade to client-side apply directly with `kubectl apply`.
+
+Downgrading works because kubectl server-side apply keeps the
+`last-applied-configuration` annotation up-to-date if you use
+`kubectl apply`.
+
+This behavior applies to server-side apply with the `kubectl` field manager. As
+an exception, you can opt-out of this behavior by specifying a different,
+non-default field manager, as seen in the following example. The default field manager for kubectl
+server-side apply is `kubectl`.
+-->
+### 从服务器端应用降格为客户端应用   {#downgrading-from-server-side-apply-to-client-side-apply}
+
+如果你使用 `kubectl apply --server-side` 来管理资源，你可以直接使用
+`kubectl apply` 来降格到客户端应用机制。
+
+降格操作之所以能够有效是因为 kubectl 服务器端应用在你使用 `kubectl apply`
+时会保持 `last-applied-configuration` 注解内容一直是最新的。
+
+这一行为适用于使用 `kubectl` 字段管理器执行的服务器端应用。
+作为一种例外情况，你也可以选择不采用这种默认行为，而像下面例子中所展示的
+那样，设置一个不同的、非默认的字段管理器。`kubectl` 所触发的服务器端应用
+默认会将字段管理器设置为 `kubectl`。
+
+```shell
+kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
+```
+
+<!--
+### API Endpoint
+
+With the Server Side Apply feature enabled, the `PATCH` endpoint accepts the
+additional `application/apply-patch+yaml` content type. Users of Server Side
+Apply can send partially specified objects as YAML to this endpoint.
+When applying a configuration, one should always include all the fields
+that they have an opinion about.
+-->
+### API 端点    {#api-endpoint}
+
+启用了服务器端应用功能特性之后，`PATCH` 操作的端点能够接受
+`application/apply-patch+yaml` 内容类型。
+服务器端应用机制的用户可以以 YAML 格式将部分设定的对象发送到该端点。
+在应用配置时，用户应该包含希望设置的所有字段在内。
+
+<!--
+### Clearing ManagedFields
+
+It is possible to strip all managedFields from an object by overwriting them
+using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
+non-apply operation. This can be done by overwriting the managedFields field
+with an empty entry. Two examples are:
+-->
+### 清除 `managedFields`  {#clearing-managedfields}
+
+通过 `MergePatch`、`StrategicMergePatch`、`JSONPatch` 或 `Update` 等非 Apply
+操作是可以清除对象上的所有 `managedFields` 内容的。通过这些操作，用户可以将
+`managedFields` 字段重新设置为空的列表。
+下面是两个例子：
+
+
+```console
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/merge-patch+json
+Accept: application/json
+
+Data: {"metadata":{"managedFields": [{}]}}
+```
+
+```console
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/json-patch+json
+Accept: application/json
+
+Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
+```
+
+<!--
+This will overwrite the managedFields with a list containing a single empty
+entry that then results in the managedFields being stripped entirely from the
+object. Note that just setting the managedFields to an empty list will not reset
+the field. This is on purpose, so managedFields never get stripped by clients
+not aware of the field.
+
+In cases where the reset operation is combined with changes to other fields than
+the managedFields, this will result in the managedFields being reset first and
+the other changes being processed afterwards. As a result the applier takes
+ownership of any fields updated in the same request.
+-->
+上面的操作会覆盖 `managedFields` 字段取值，使之成为一个只有一个空表项的列表，
+进而使得 `managedFields` 整个会被充对象上剥离。
+注意，仅仅将 `managedFields` 设为空列表还不足以将字段取值复位。
+这样的设计是有意为之的，目的是避免 `managedFields` 字段被不了解该字段的客户端
+意外清除。
+
+如果此复位操作和对 `managedFields` 字段之外的其它字段的变更一起提交，则
+`managedFields` 的内容会首先被重置，之后才会处理其他字段变更。因此，施加者会
+成为同一请求中被更新的字段的属主。
+
+<!--
+Server Side Apply does not correctly track ownership on
+sub-resources that don't receive the resource object type. If you are
+using Server Side Apply with such a sub-resource, the changed fields
+won't be tracked.
+-->
+{{< caution >}}
+服务器端应用机制无法正确地跟踪某些子资源的属主，如果这些子资源不能接收资源
+对象类型数据的话。如果你针对这类子资源使用服务器端应用机制，则所变更的字段
+不会被跟踪记录。
+{{< /caution >}}
+
+<!--
+### Disabling the feature
+
+Server Side Apply is a beta feature, so it is enabled by default. To turn this
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates) off,
+you need to include the `-feature-gates ServerSideApply=false` flag when
+starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all
+should have the same flag setting.
+-->
+### 禁用此功能特性    {#disabling-the-feature}
+
+服务器端应用是一种 Beta 阶段的特性，因此默认是被启用的。如要将此
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)关闭，
+你需要在启动 `kube-apiserver` 时包含 `--feature-gates ServerSideApply=false`
+标志。如果你运行了多个 `kube-apiserver`
+副本，则每个副本上都要作同样的标志设置。
+
+<!--
+## Resource Versions
+
+Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
+-->
+## 资源版本   {#resource-versions}
+
+资源版本采用字符串来表达，用来标示对象的服务器端内部版本。
+客户端可以使用资源版本来判定对象是否被更改，或者在读取、列举或监视资源时
+用来表达数据一致性需求。
+客户端必需将资源版本视为不透明的对象，将其原封不动地传递回服务器端。
+例如，客户端一定不能假定资源版本是某种数值标识，也不可以对两个资源版本值
+进行比较看其是否相同（也就是不可以比较两个版本值以判断其中一个比另一个
+大或小）。
+
+<!--
+### ResourceVersion in metadata
+
+Clients find resource versions in resources, including the resources in watch events, and list responses returned from the server:
+
+[v1.meta/ObjectMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
+
+[v1.meta/ListMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
+-->
+### `metadata` 中的 `resourceVersion`
+
+客户端可以在资源中看到资源版本信息，这里的资源包括从服务器返回的 Watch 事件
+以及 list 操作响应：
+
+[v1.meta/ObjectMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectmeta-v1-meta) - 资源
+的 `metadata.resourceVersion` 值标明该实例上次被更改时的资源版本。
+
+[v1.meta/ListMeta](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#listmeta-v1-meta) - 资源集合
+（即 list 操作的响应）的 `metadata.resourceVersion` 所标明的是 list 响应被构造
+时的资源版本。
+
+<!--
+### The ResourceVersion Parameter
+
+The get, list and watch operations support the `resourceVersion` parameter.
+
+The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`.
+
+For get and list, the semantics of resource version are:
+
+**Get:**
+-->
+### `resourceVersion` 参数   {#the-resourceversion-parameter}
+
+GET、LIST 和 WATCH 操作都支持 `resourceVersion` 参数。
+
+参数的具体含义取决于所执行的操作和所给的 `resourceVersion` 值：
+
+对于 GET 和 LIST 而言，资源版本的语义为：
+
+**GET：**
+
+<!--
+| resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" |
+|------------------------|---------------------|----------------------------------------|
+| Most Recent           | Any                 | Not older than                         |
+-->
+| resourceVersion 未设置 | resourceVersion="0" | resourceVersion="\<非零值\>" |
+|------------------------|---------------------|----------------------------------------|
+| 最新版本               | 任何版本            | 不老于给定版本                         |
+
+
+**LIST：**
+
+<!--
+v1.19+ API servers and newer support the `resourceVersionMatch` parameter, which
+determines how resourceVersion is applied to list calls.  It is highly
+recommended that `resourceVersionMatch` be set for list calls where
+`resourceVersion` is set. If `resourceVersion` is unset, `resourceVersionMatch`
+is not allowed.  For backward compatibility, clients must tolerate the server
+ignoring `resourceVersionMatch`:
+-->
+v1.19 及以上版本的 API 服务器支持 `resourceVersionMatch` 参数，用以确定如何对
+LIST 调用应用 resourceVersion 值。
+强烈建议在为 LIST 调用设置了 `resourceVersion` 时也设置 `resourceVersionMatch`。
+如果 `resourceVersion` 未设置，则 `resourceVersionMatch` 是不允许设置的。
+为了向后兼容，客户端必须能够容忍服务器在某些场景下忽略 `resourceVersionMatch` 的行为：
+
+<!--
+- When using `resourceVersionMatch=NotOlderThan` and limit is set, clients must
+  handle HTTP 410 "Gone" responses. For example, the client might retry with a
+  newer `resourceVersion` or fall back to `resourceVersion=""`.
+
+- When using `resourceVersionMatch=Exact` and `limit` is unset, clients must
+  verify that the `resourceVersion` in the `ListMeta` of the response matches
+  the requested `resourceVersion`, and handle the case where it does not. For
+  example, the client might fall back to a request with `limit` set.
+-->
+- 当设置 `resourceVersionMatch=NotOlderThan` 且指定了 `limit` 时，客户端必须能够
+  处理 HTTP 410 "Gone" 响应。例如，客户端可以使用更新一点的 `resourceVersion`
+  来重试，或者回退到 `resourceVersion=""` （即允许返回任何版本）。
+
+- 当设置了 `resourceVersionMatch=Exact` 且未指定 `limit` 时，客户端必须验证
+  响应数据中 `ListMeta` 的 `resourceVersion` 与所请求的 `resourceVersion` 匹配，
+  并处理二者可能不匹配的情况。例如，客户端可以重试设置了 `limit` 的请求。
+
+<!--
+Unless you have strong consistency requirements, using `resourceVersionMatch=NotOlderThan` and
+a known `resourceVersion` is preferable since it can achieve better performance and scalability
+of your cluster than leaving `resourceVersion` and `resourceVersionMatch` unset, which requires
+quorum read to be served.
+-->
+除非你对一致性有着非常强烈的需求，使用 `resourceVersionMatch=NotOlderThan`
+同时为 `resourceVersion` 设定一个已知值是优选的交互方式，因为与不设置
+`resourceVersion` 和 `resourceVersionMatch` 相比，这种配置可以取得更好的
+集群性能和可扩缩性。后者需要提供带票选能力的读操作。
+
+<!--
+| resourceVersionMatch param              | paging params                  | resourceVersion unset  | resourceVersion="0"                        | resourceVersion="{value other than 0}" |
+|-----------------------------------------|--------------------------------|------------------------|--------------------------------------------|----------------------------------------|
+| resourceVersionMatch unset              | limit unset                    | Most Recent            | Any                                        | Not older than                         |
+| resourceVersionMatch unset              | limit="n", continue unset      | Most Recent            | Any                                        | Exact                                  |
+| resourceVersionMatch unset              | limit="n", continue="<token>"  | Continue Token, Exact  | Invalid, treated as Continue Token, Exact  | Invalid, HTTP `400 Bad Request`        |
+| resourceVersionMatch=Exact<sup>\*</sup> | limit unset                    | Invalid                | Invalid                                    | Exact                                  |
+| resourceVersionMatch=Exact<sup>\*</sup> | limit="n", continue unset      | Invalid                | Invalid                                    | Exact                                  |
+| resourceVersionMatch=NotOlderThan<sup>\*</sup> | limit unset               | Invalid              | Any                                        | Not older than                         |
+| resourceVersionMatch=NotOlderThan<sup>\*</sup> | limit="n", continue unset | Invalid              | Any                                        | Not older than                         |
+
+<br/>
+<small>
+
+**Footnotes:**
+
+\* If the server does not honor the `resourceVersionMatch` parameter, it is treated as if it is unset.
+</small>
+-->
+| resourceVersionMatch 参数               | 分页参数                        | resourceVersion 未设置  | resourceVersion="0"                     | resourceVersion="\<非零值\>"     |
+|-----------------------------------------|---------------------------------|-------------------------|-----------------------------------------|----------------------------------|
+| resourceVersionMatch 未设置             | limit 未设置                    | 最新版本                | 任意版本                                | 不老于指定版本                   |
+| resourceVersionMatch 未设置             | limit=n, continue 未设置        | 最新版本                | 任意版本                                | 精确匹配                         |
+| resourceVersionMatch 未设置             | limit=n, continue=\<token\>     | Continue 令牌、精确匹配 | 非法请求，视为 Continue 令牌、精确匹配  | 非法请求，HTTP `400 Bad Request` |
+| resourceVersionMatch=Exact<sup>\*</sup> | limit 未设置                    | 非法请求                | 非法请求                                | 精确匹配                         |
+| resourceVersionMatch=Exact<sup>\*</sup> | limit=n, continue 未设置        | 非法请求                | 非法请求                                | 精确匹配                         |
+| resourceVersionMatch=NotOlderThan<sup>\*</sup> | limit 未设置             | 非法请求                | 任意版本                                | 不老于指定版本                   |
+| resourceVersionMatch=NotOlderThan<sup>\*</sup> | limit=n, continue 未设置 | 非法请求                | 任意版本                                | 不老于指定版本                   |
+
+<br />
+<small>
+
+**脚注：**
+
+\* 如果服务器无法正确处理 `resourceVersionMatch` 参数，其行为与未设置该参数相同。
+</small>
+
+<!--
+The meaning of the get and list semantics are:
+
+- **Most Recent:** Return data at the most recent resource version. The returned data must be
+  consistent (i.e. served from etcd via a quorum read).
+- **Any:** Return data at any resource version. The newest available resource version is preferred,
+  but strong consistency is not required; data at any resource version may be served. It is possible
+  for the request to return data at a much older resource version that the client has previously
+  observed, particularly in high availabiliy configurations, due to partitions or stale
+  caches. Clients that cannot tolerate this should not use this semantic.
+-->
+GET 和 LIST 操作的语义含义如下：
+
+- **最新版本：** 返回资源版本为最新的数据。所返回的数据必须一致
+  （通过票选读操作从 etcd 中取出）。
+- **任意版本：** 返回任意资源版本的数据。优选最新可用的资源版本，不过不能保证
+  强一致性；返回的数据可能是任何资源版本的。请求返回的数据有可能是客户端以前
+  看到过的很老的资源版本。尤其在某些高可用配置环境中，网络分区或者高速缓存
+  未被更新等状态都可能导致这种状况。不能容忍这种不一致性的客户端不应采用此
+  语义。
+<!--
+- **Not older than:** Return data at least as new as the provided resourceVersion. The newest
+  available data is preferred, but any data not older than the provided resourceVersion may be
+  served.  For list requests to servers that honor the resourceVersionMatch parameter, this
+  guarantees that resourceVersion in the ListMeta is not older than the requested resourceVersion,
+  but does not make any guarantee about the resourceVersion in the ObjectMeta of the list items
+  since ObjectMeta.resourceVersion tracks when an object was last updated, not how up-to-date the
+  object is when served.
+- **Exact:** Return data at the exact resource version provided. If the provided resourceVersion is
+  unavailable, the server responds with HTTP 410 "Gone".  For list requests to servers that honor the
+  resourceVersionMatch parameter, this guarantees that resourceVersion in the ListMeta is the same as
+  the requested resourceVersion, but does not make any guarantee about the resourceVersion in the
+  ObjectMeta of the list items since ObjectMeta.resourceVersion tracks when an object was last
+  updated, not how up-to-date the object is when served.
+- **Continue Token, Exact:** Return data at the resource version of the initial paginated list
+  call. The returned Continue Tokens are responsible for keeping track of the initially provided
+  resource version for all paginated list calls after the initial paginated list call.
+-->
+- **不老于指定版本：** 返回至少比所提供的 `resourceVersion` 还要新的数据。
+  优选最新的可用数据，不过最终提供的可能是不老于所给 `resourceVersion` 的任何版本。
+  对于发给能够正确处理 `resourceVersionMatch` 参数的服务器的 LIST 请求，此语义
+  保证 `ListMeta` 中的 `resourceVersion` 不老于请求的 `resourceVersion`，不过
+  不对列表条目之 `ObjectMeta` 的 `resourceVersion` 提供任何保证。
+  这是因为 `ObjectMeta.resourceVersion` 所跟踪的是列表条目对象上次更新的时间，
+  而不是对象被返回时是否是最新。
+
+- **确定版本：** 返回精确匹配所给资源版本的数据。如果所指定的 resourceVersion
+  的数据不可用，服务器会响应 HTTP 410 "Gone"。
+  对于发送给能够正确处理 `resourceVersionMatch` 参数的服务器的 LIST 请求而言，
+  此语义会保证 ListMeta 中的 `resourceVersion` 与所请求的 `resourceVersion`
+  匹配， 不过不对列表条目之 `ObjectMeta` 的 `resourceVersion` 提供任何保证。
+  这是因为 `ObjectMeta.resourceVersion` 所跟踪的是列表条目对象上次更新的时间，
+  而不是对象被返回时是否是最新。
+
+- **Continue 令牌、精确匹配：** 返回原先带分页参数的 LIST 调用中指定的资源版本的数据。
+  在最初的带分页参数的 LIST 调用之后，所有分页式的 LIST 调用都使用所返回的 Continue
+  令牌来跟踪最初提供的资源版本，
+
+<!--
+For watch, the semantics of resource version are:
+-->
+对于 WATCH 操作而言，资源版本的语义如下：
+
+**WATCH：**
+
+<!--
+| resourceVersion unset               | resourceVersion="0"        | resourceVersion="{value other than 0}" |
+|-------------------------------------|----------------------------|----------------------------------------|
+| Get State and Start at Most Recent  | Get State and Start at Any | Start at Exact                         |
+-->
+| resourceVersion 未设置    | resourceVersion="0"      | resourceVersion="\<非零值\>" |
+|---------------------------|--------------------------|------------------------------|
+| 读取状态并从最新版本开始  | 读取状态并从任意版本开始 | 从指定版本开始               |
+
+<!--
+The meaning of the watch semantics are:
+
+- **Get State and Start at Most Recent:** Start a watch at the most recent
+  resource version, which must be consistent (i.e. served from etcd via a
+  quorum read). To establish initial state, the watch begins with synthetic
+  "Added" events of all resources instances that exist at the starting resource
+  version. All following watch events are for all changes that occurred after
+  the resource version the watch started at.
+-->
+WATCH 操作语义的含义如下：
+
+- **读取状态并从最新版本开始：** 从最新的资源版本开始 WATCH 操作。这里的
+  最新版本必须是一致的（即通过票选读操作从 etcd 中取出）。为了建立初始状态，
+  WATCH 首先会处理一组合成的 "Added" 事件，这些事件涵盖在初始资源版本中存在
+  的所有资源实例。
+  所有后续的 WATCH 事件都是关于 WATCH 开始时所处资源版本之后发生的变更。
+
+<!--
+- **Get State and Start at Any:** Warning: Watches initialize this way may
+  return arbitrarily stale data! Please review this semantic before using it,
+  and favor the other semantics where possible. Start a watch at any resource
+  version, the most recent resource version available is preferred, but not
+  required; any starting resource version is allowed. It is possible for the
+  watch to start at a much older resource version that the client has previously
+  observed, particularly in high availability configurations, due to partitions
+  or stale caches. Clients that cannot tolerate this should not start a watch
+  with this semantic. To establish initial state, the watch begins with
+  synthetic "Added" events for all resources instances that exist at the
+  starting resource version. All following watch events are for all changes that
+  occurred after the resource version the watch started at.
+-->
+- **读取状态并从任意版本开始：** 警告：通过这种方式初始化的 WATCH 操作可能会
+  返回任何状态的停滞数据。请在使用此语义之前执行复核，并在可能的情况下采用其他
+  语义。此语义会从任意资源版本开始执行 WATCH 操作，优选最新的可用的资源版本，
+  不过不是必须的；采用任何资源版本作为起始版本都是被允许的。
+  WATCH 操作有可能起始于客户端已经观测到的很老的版本。在高可用配置环境中，因为
+  网络分裂或者高速缓存未及时更新的原因都会造成此现象。
+  如果客户端不能容忍这种不一致性，就不要使用此语义来启动 WATCH 操作。
+  为了建立初始状态，WATCH 首先会处理一组合成的 "Added" 事件，这些事件涵盖在
+  初始资源版本中存在的所有资源实例。
+  所有后续的 WATCH 事件都是关于 WATCH 开始时所处资源版本之后发生的变更。
+
+<!--
+- **Start at Exact:** Start a watch at an exact resource version. The watch
+  events are for all changes after the provided resource version. Unlike "Get
+  State and Start at Most Recent" and "Get State and Start at Any", the watch is
+  not started with synthetic "Added" events for the provided resource version.
+  The client is assumed to already have the initial state at the starting
+  resource version since the client provided the resource version.
+-->
+- **从指定版本开始：** 从某确切资源版本开始执行 WATCH 操作。WATCH 事件都是
+  关于 WATCH 开始时所处资源版本之后发生的变更。与前面两种语义不同，WATCH 操作
+  开始的时候不会生成或处理为所提供资源版本合成的 "Added" 事件。
+  我们假定客户端既然能够提供确切资源版本，就应该已经拥有了起始资源版本对应的初始状态。
+
+<!--
+### "410 Gone" responses
+
+Servers are not required to serve all older resource versions and may return a
+HTTP `410 (Gone)` status code if a client requests a resourceVersion older
+than the server has retained. Clients must be able to tolerate `410 (Gone)`
+responses. See [Efficient detection of
+changes](#efficient-detection-of-changes) for details on how to handle `410
+(Gone)` responses when watching resources.
+
+If you request a a resourceVersion outside the applicable limit then,
+depending on whether a request is served from cache or not, the API server may
+reply with a `410 Gone` HTTP response.
+-->
+### "410 Gone" 响应     {#410-gone-responses}
+
+服务器不需要提供所有老的资源版本，在客户端请求的是早于服务器端所保留版本的
+`resourceVersion` 时，可以返回 HTTP `410 (Gone)` 状态码。
+客户端必须能够容忍 `410 (Gone)` 响应。
+参阅[高效检测变更](#efficient-detection-of-changes)以了解如何在监测资源时
+处理 `410 (Gone)` 响应。
+
+如果所请求的 `resourceVersion` 超出了可应用的 `limit`，那么取决于请求是否
+是通过高速缓存来满足的，API 服务器可能会返回一个 `410 Gone` HTTP 响应。
+
+<!--
+### Unavailable resource versions
+
+Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a resonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for a unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available.
+-->
+### 不可用的资源版本  {#unavailable-resource-versions}
+
+服务器不必未无法识别的资源版本提供服务。针对无法识别的资源版本的 LIST 和 GET 请求
+可能会短暂等待，以期资源版本可用。如果所给的资源版本在一定的时间段内仍未变得
+可用，服务器应该超时并返回 `504 (Gateway Timeout)`，且可在响应中添加
+`Retry-After` 响应头部字段，标明客户端在再次尝试之前应该等待多少秒钟。
+目前，`kube-apiserver` 也能使用 `Too large resource version（资源版本过高）`
+消息来标识这类响应。针对某无法识别的资源版本的 WATCH 操作可能会无限期
+（直到请求超时）地等待下去，直到资源版本可用。
+
diff --git a/content/zh/docs/reference/using-api/api-overview.md b/content/zh/docs/reference/using-api/api-overview.md
deleted file mode 100644
index 4c08851654..0000000000
--- a/content/zh/docs/reference/using-api/api-overview.md
+++ /dev/null
@@ -1,232 +0,0 @@
----
-title: Kubernetes API 总览
-content_type: concept
-weight: 10
-card:
-  name: reference
-  weight: 50
-  title: API 总览
----
-
-<!--
----
-title: Kubernetes API Overview
-reviewers:
-- erictune
-- lavalamp
-- jbeda
-content_type: concept
-weight: 10
-card:
-  name: reference
-  weight: 50
-  title: Overview of API
----
--->
-
-<!-- overview -->
-
-<!--
-This page provides an overview of the Kubernetes API.
--->
-此页提供 Kubernetes API 的总览
-
-
-
-<!-- body -->
-
-<!--
-The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes
-platform is treated as an API object and has a corresponding entry in the
-[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
-
-Most operations can be performed through the
-[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
-command-line tools, such as [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), which in turn use
-the API. However, you can also access the API directly using REST calls.
-
-Consider using one of the [client libraries](/docs/reference/using-api/client-libraries/)
-if you are writing an application using the Kubernetes API.
--->
-
-REST API 是 Kubernetes 的基础架构。组件之间的所有操作和通信，以及外部用户命令都是 API Server 处理的 REST API 调用。因此，Kubernetes 平台中的所有资源被视为 API 对象，并且在
-[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 中都有对应的定义项。
-
-大多数操作可以通过 [kubectl](/docs/reference/kubectl/overview/) 命令行界面或其他命令行工具执行，例如 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)，它们本身也使用 API。但是，您也可以使用 REST 调用直接访问 API。
-
-如果您正在使用 Kubernetes API 编写应用程序，请考虑使用 [客户端库](/docs/reference/using-api/client-libraries/)。
-
-<!--
-## API versioning
-
-To eliminate fields or restructure resource representations, Kubernetes supports
-multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/extensions/v1beta1`.
-
-The version is set at the API level rather than at the resource or field level to:
-
-- Ensure that the API presents a clear and consistent view of system resources and behavior.
-- Enable control access to end-of-life and/or experimental APIs.
-
-The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats.
--->
-## API 版本控制
-
-为了消除字段或重组资源表示形式，Kubernetes 支持多个 API 版本，每个版本在不同的 API 路径下。例如：`/api/v1` 或者 `/apis/extensions/v1beta1`。
-
-版本是在 API 级别而非资源或字段级别配置的：
-
-- 确保 API 呈现出清晰一致的系统资源和行为视图。
-- 允许控制对已寿终正寝的 API 和/或实验性 API 的访问。
-
-JSON 和 Protobuf 序列化模式在出现模式变更时均遵循这些准则。以下说明同时适用于这两种格式。
-
-<!--
-The API versioning and software versioning are indirectly related.  The [API and release
-versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and software versioning.
--->
-
-{{< note >}}
-API 版本和软件版本是间接相关的。[API 和发布版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) 描述了 API 版本和软件版本之间的关系。
-{{< /note >}}
-
-<!--
-Different API versions indicate different levels of stability and support. You can find more information about the criteria for each level in the [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).
-
-Here's a summary of each level:
-
-- Alpha:
-  - The version names contain `alpha` (for example, `v1alpha1`).
-  - The software may contain bugs. Enabling a feature may expose bugs. A feature may be disabled by default.
-  - The support for a feature may be dropped at any time without notice.
-  - The API may change in incompatible ways in a later software release without notice.
-  - The software is recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of  long-term support.
-
-- Beta:
-  - The version names contain `beta` (for example, `v2beta3`).
-  - The software is well tested. Enabling a feature is considered safe. Features are enabled by default.
-  - The support for a feature will not be dropped, though the details may change.
-  - The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, migration instructions are provided.  This may require deleting, editing, and re-creating
-    API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
-  - The software is recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters which can be upgraded independently, you may be able to relax this restriction.
--->
-不同的 API 版本表示不同级别的稳定性和支持级别。您可以在 [API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable) 中找到有关每个级别的条件的更多信息。
-
-以下是每个级别的摘要：
-
-- Alpha：
-  - 版本名称包含 `alpha`（例如，`v1alpha1`）。
-  - 该软件可能包含错误。启用功能可能会暴露错误。默认情况下，功能可能被禁用。
-  - 对功能的支持随时可能被删除，但不另行通知。
-  - 在以后的软件版本中，API 可能会以不兼容的方式更改，亦不另行通知。
-  - 由于存在更高的错误风险和缺乏长期支持，建议仅在短期测试集群中使用该软件。
-
-- Beta：
-  - 版本名称包含`beta`（例如，`v2beta3`）。
-  - 该软件已经过充分测试。启用功能被认为是安全的。默认情况下启用功能。
-  - 尽管细节可能会发生变更，对应功能不会被废弃。
-  - 在随后的 Beta 或稳定版本中，对象的模式和/或语义可能会以不兼容的方式更改。发生这种情况时，将提供迁移说明。迁移时可能需要删除、编辑和重新创建 API 对象。编辑过程可能需要一些思考。对于依赖该功能的应用程序，可能需要停机。
-  - 该软件仅建议用于非关键业务用途，因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的群集，则可以放宽此限制。
-
- {{< note >}}
-
-<!--
-Try the beta features and provide feedback. After the features exit beta, it may not be practical to make more changes.
--->
-
-请试用 Beta 版功能并提供反馈。功能结束 Beta 版之后，再进行变更可能是不切实际的。
-
- {{< /note >}}
-
-<!--
-- Stable:
-  - The version name is `vX` where `X` is an integer.
-  - The stable versions of features appear in released software for many subsequent versions.
--->
-
-- 稳定版：
-  - 版本名称为 `vX`，其中`X`为整数。
-  - 功能特性的稳定版本会持续出现在许多后续版本的发行软件中。
-
-<!--
-## API groups
-
-[*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
-
-Currently, there are several API groups in use:
-
-*  The *core* (also called *legacy*) group, which is at REST path `/api/v1` and is not specified as part of the `apiVersion` field, for example, `apiVersion: v1`.
-*  The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
-   (for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).
-
-The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
-
- - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
-   for basic CRUD needs.
- - [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) for a full set of Kubernetes API semantics to implement their own apiserver.
--->
-
-## API 组
-
-[ *API 组*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) 使扩展 Kubernetes API 更容易。API 组在 REST 路径和序列化对象的 apiVersion 字段中指定。
-
-当前，有几个正在使用的 API 组：
-
-* *core*（也称为 *legacy*）组，它位于 REST 路径`/api/v1`上，未指定为 apiVersion 字段的一部分，例如`apiVersion: v1`。
-* 特定名称的组位于 REST 路径`/apis/$GROUP_NAME/$VERSION`下，并使用`apiVersion:$GROUP_NAME/$VERSION`（例如，`apiVersion:batch/v1`）。您可以在 [Kubernetes API 参考](/docs/reference/) 中找到受支持的 API Group 的完整列表。
-
-有两种途径来使用 [自定义资源](/docs/concepts/api-extension/custom-resources/) 扩展 API，分别是：
-
- - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) 提供基本的 CRUD 需求。
- - [聚合器（Aggregator）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)具有完整的 Kubernetes API 语义，用以实现用户自己的 apiserver。
-
-<!--
-## Enabling or disabling API groups
-
-Certain resources and API groups are enabled by default. You can enable or disable them by setting `--runtime-config`
-on the apiserver. `--runtime-config` accepts comma separated values. For example:
- - to disable batch/v1, set `--runtime-config=batch/v1=false`
- - to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`
-The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
--->
-## 启用 API 组
-
-默认情况下，某些资源和 API 组处于启用状态。您可以通过设置`--runtime-config`来启用或禁用它们。
-`--runtime-config` 接受逗号分隔的值。例如：
- - 要禁用 `batch/v1`，请配置`--runtime-config=batch/v1=false`
- - 要启用 `batch/2alpha1`，请配置`--runtime-config=batch/v2alpha1`
-该标志接受描述 apiserver 的运行时配置的以逗号分隔的`key=value` 对集合。
-
-{{< note >}}
-
-<!--
-When you enable or disable groups or resources, you need to restart the apiserver and controller-manager
-to pick up the `--runtime-config` changes.
--->
-启用或禁用组或资源时，需要重新启动 apiserver 和控制器管理器以刷新 `--runtime-config` 的更改。
-
-{{< /note >}}
-
-<!--
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
--->
-
-## 启用 extensions/v1beta1 组中具体资源
-
-在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。
-例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。
-
-{{< note >}}
-
-<!--
-Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.
--->
-出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。
-
-{{< /note >}}
-
-
diff --git a/content/zh/docs/reference/using-api/client-libraries.md b/content/zh/docs/reference/using-api/client-libraries.md
index 20855fbe48..add068a61d 100644
--- a/content/zh/docs/reference/using-api/client-libraries.md
+++ b/content/zh/docs/reference/using-api/client-libraries.md
@@ -24,11 +24,11 @@ API from various programming languages.
 
 <!-- body -->
 <!--
-To write applications using the [Kubernetes REST API](/docs/reference/using-api/api-overview/),
+To write applications using the [Kubernetes REST API](/docs/reference/using-api/),
 you do not need to implement the API calls and request/response types yourself.
 You can use a client library for the programming language you are using.
 -->
-在使用 [Kubernetes REST API](/docs/reference/using-api/api-overview/) 编写应用程序时，
+在使用 [Kubernetes REST API](/zh/docs/reference/using-api/) 编写应用程序时，
 您并不需要自己实现 API 调用和 “请求/响应” 类型。
 您可以根据自己的编程语言需要选择使用合适的客户端库。
 
@@ -36,12 +36,12 @@ You can use a client library for the programming language you are using.
 Client libraries often handle common tasks such as authentication for you.
 Most client libraries can discover and use the Kubernetes Service Account to
 authenticate if the API client is running inside the Kubernetes cluster, or can
-understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
+understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 format to read the credentials and the API Server address.
 -->
 客户端库通常为您处理诸如身份验证之类的常见任务。
 如果 API 客户端在 Kubernetes 集群中运行，大多数客户端库可以发现并使用 Kubernetes 服务帐户进行身份验证，
-或者能够理解 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
+或者能够理解 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
 格式来读取凭据和 API 服务器地址。
 
 <!--
@@ -50,8 +50,8 @@ format to read the credentials and the API Server address.
 ## 官方支持的 Kubernetes 客户端库
 
 <!--
-The following client libraries are officially maintained by [Kubernetes SIG API
-Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
+The following client libraries are officially maintained by
+[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
 -->
 以下客户端库由 [Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 正式维护。
 
@@ -80,6 +80,8 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 -->
 ## 社区维护的客户端库
 
+{{% thirdparty-content %}}
+
 <!--
 The following Kubernetes API client libraries are provided and maintained by
 their authors, not the Kubernetes team.
@@ -103,6 +105,7 @@ their authors, not the Kubernetes team.
 | PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
 | PHP                  | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
 | PHP                  | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
+| PHP                  | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
 | Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
 | Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
@@ -132,6 +135,7 @@ their authors, not the Kubernetes team.
 | PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
 | PHP                  | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) |
 | PHP                  | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
+| PHP                  | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
 | Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
 | Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
diff --git a/content/zh/docs/reference/using-api/deprecation-policy.md b/content/zh/docs/reference/using-api/deprecation-policy.md
new file mode 100644
index 0000000000..a5fa369e96
--- /dev/null
+++ b/content/zh/docs/reference/using-api/deprecation-policy.md
@@ -0,0 +1,738 @@
+---
+title: Kubernetes 弃用策略
+content_type: concept
+weight: 40
+---
+<!--
+reviewers:
+- bgrant0607
+- lavalamp
+- thockin
+title: Kubernetes Deprecation Policy
+content_type: concept
+weight: 40
+-->
+
+<!-- overview -->
+<!--
+This document details the deprecation policy for various facets of the system.
+-->
+本文档详细解释系统中各个层面的弃用策略（Deprecation Policy）。
+
+<!-- body -->
+<!--
+Kubernetes is a large system with many components and many contributors.  As
+with any such software, the feature set naturally evolves over time, and
+sometimes a feature may need to be removed. This could include an API, a flag,
+or even an entire feature. To avoid breaking existing users, Kubernetes follows
+a deprecation policy for aspects of the system that are slated to be removed.
+-->
+Kubernetes 是一个组件众多、贡献者人数众多的大系统。
+就像很多类似的软件，所提供的功能特性集合会随着时间推移而自然发生变化，
+而且有时候某个功能特性可能需要被去除。被去除的可能是一个 API、一个参数标志或者
+甚至某整个功能特性。为了避免影响到现有用户，Kubernetes 对于其中渐次移除
+的各个方面规定了一种弃用策略并遵从此策略。
+
+<!--
+## Deprecating parts of the API
+
+Since Kubernetes is an API-driven system, the API has evolved over time to
+reflect the evolving understanding of the problem space. The Kubernetes API is
+actually a set of APIs, called "API groups", and each API group is
+independently versioned.  [API versions](/docs/reference/using-api/api-overview/#api-versioning) fall
+into 3 main tracks, each of which has different policies for deprecation:
+-->
+## 弃用 API 的一部分  {#deprecating-parts-of-the-api}
+
+由于 Kubernetes 是一个 API 驱动的系统，API 会随着时间推移而演化，以反映
+人们对问题共建的认识的变化。Kubernetes API 实际上是一个 API 集合，其中每个
+成员称作“API 组（API Group）”，并且每个 API 组都是独立管理版本的。
+[API 版本](/zh/docs/reference/using-api/api-overview/#api-versioning)会有
+三类，每类有不同的废弃策略：
+
+<!--
+| Example  | Track                            |
+|----------|----------------------------------|
+| v1       | GA (generally available, stable) |
+| v1beta1  | Beta (pre-release)               |
+| v1alpha1 | Alpha (experimental)             |
+-->
+| 示例     | 分类                             |
+|----------|----------------------------------|
+| v1       | 正式发布（Generally available，GA，稳定版本） |
+| v1beta1  | Beta （预发布）|
+| v1alpha1 | Alpha （试验性） |
+
+<!--
+A given release of Kubernetes can support any number of API groups and any
+number of versions of each.
+
+The following rules govern the deprecation of elements of the API.  This
+includes:
+-->
+给定的 Kubernetes 发布版本中可以支持任意数量的 API 组，且每组可以包含
+任意个数的版本。
+
+下面的规则负责指导 API 元素的弃用，具体元素包括：
+
+<!--
+   * REST resources (aka API objects)
+   * Fields of REST resources
+   * Annotations on REST resources, including "beta" annotations but not
+     including "alpha" annotations.
+   * Enumerated or constant values
+   * Component config structures
+-->
+* REST 资源（也即 API 对象）
+* REST 资源的字段
+* REST 资源的注解，包含“beta”类注解但不包含“alpha”类注解
+* 枚举值或者常数值
+* 组件配置结构
+
+<!--
+These rules are enforced between official releases, not between
+arbitrary commits to master or release branches.
+
+**Rule #1: API elements may only be removed by incrementing the version of the
+API group.**
+
+Once an API element has been added to an API group at a particular version, it
+can not be removed from that version or have its behavior significantly
+changed, regardless of track.
+-->
+以下是跨正式发布版本时要实施的规则，不适用于对 master 或发布分支上
+不同提交之间的变化。
+
+**规则 #1：只能在增加 API 组版本号时删除 API 元素。**
+
+一旦在某个特定 API 组版本中添加了 API 元素，则该元素不可从该版本中删除，
+且其行为也不能大幅度地变化，无论属于哪一类（GA、Alpha 或 Beta）。
+
+<!--
+For historical reasons, there are 2 "monolithic" API groups - "core" (no
+group name) and "extensions".  Resources will incrementally be moved from these
+legacy API groups into more domain-specific API groups.
+-->
+{{< note >}}
+由于历史原因，Kubernetes 中存在两个“单体式（Monolithic）”API 组 -
+“core”（无组名）和“extensions”。这两个遗留 API 组中的资源会被逐渐迁移到
+更为特定领域的 API 组中。
+{{< /note >}}
+
+<!--
+**Rule #2: API objects must be able to round-trip between API versions in a given
+release without information loss, with the exception of whole REST resources
+that do not exist in some versions.**
+-->
+**规则 #2：在给定的发布版本中，API 对象必须能够在不同的 API 版本之间来回
+转换且不造成信息丢失，除非整个 REST 资源在某些版本中完全不存在。**
+
+<!--
+For example, an object can be written as v1 and then read back as v2 and
+converted to v1, and the resulting v1 resource will be identical to the
+original.  The representation in v2 might be different from v1, but the system
+knows how to convert between them in both directions.  Additionally, any new
+field added in v2 must be able to round-trip to v1 and back, which means v1
+might have to add an equivalent field or represent it as an annotation.
+-->
+例如，一个对象可被用 v1 来写入之后用 v2 来读出并转换为 v1，所得到的 v1 必须
+与原来的 v1 对象完全相同。v2 中的表现形式可能与 v1 不同，但系统知道如何
+在两个版本之间执行双向转换。
+此外，v2 中添加的所有新字段都必须能够转换为 v1 再转换回来。这意味着 v1 必须
+添加一个新的等效字段或者将其表现为一个注解。
+
+<!--
+**Rule #3: An API version in a given track may not be deprecated until a new
+API version at least as stable is released.**
+
+GA API versions can replace GA API versions as well as beta and alpha API
+versions.  Beta API versions *may not* replace GA API versions.
+-->
+**规则 #3：给定类别的 API 版本在新的、稳定性未降低的 API 版本发布之前不可被废弃。**
+
+一个正式发布的（GA）API 版本可替换现有的正式 API 版本或 alpha、beta API 版本。
+Beta API 版本 *不可以* 替代正式的 API 版本。
+
+<!--
+**Rule #4a: Other than the most recent API versions in each track, older API
+versions must be supported after their announced deprecation for a duration of
+no less than:**
+
+   * **GA: 12 months or 3 releases (whichever is longer)**
+   * **Beta: 9 months or 3 releases (whichever is longer)**
+   * **Alpha: 0 releases**
+
+This covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/).
+-->
+**规则 #4a：除了每类 API 版本中的最新版本，旧的 API 版本在其被宣布被废弃之后
+至少以下时长内仍需被支持：**
+
+   * **GA：12 个月或者 3 个发布版本（取其较长者）**
+   * **Beta: 9 个月或者 3 个发布版本（取其较长者）**
+   * **Alpha: 0 个发布版本**
+
+这里也包含了关于[最大支持 2 个发布版本的版本偏差](/zh/docs/setup/release/version-skew-policy/)的约定。
+
+<!--
+Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
+resolved, no API versions that have been persisted to storage may be removed.
+Serving REST endpoints for those versions may be disabled (subject to the
+deprecation timelines in this document), but the API server must remain capable
+of decoding/converting previously persisted data from storage.
+-->
+{{< note >}}
+在[#52185](https://github.com/kubernetes/kubernetes/issues/52185)被解决之前，
+已经被保存到持久性存储中的 API 版本都不可以被去除。
+你可以禁止这些版本所对应的 REST 末端（在符合本文中弃用时间线的前提下），
+但是 API 服务器必须仍能解析和转换存储中以前写入的数据。
+{{< /note >}}
+
+<!--
+**Rule #4b: The "preferred" API version and the "storage version" for a given
+group may not advance until after a release has been made that supports both the
+new version and the previous version**
+-->
+**规则 #4b：标记为“preferred（优选的）” API 版本和给定 API 组的
+“storage version（存储版本）”在既支持老版本也支持新版本的 Kubernetes 发布
+版本出来以前不可以提升其版本号。**
+
+<!--
+Users must be able to upgrade to a new release of Kubernetes and then roll back
+to a previous release, without converting anything to the new API version or
+suffering breakages (unless they explicitly used features only available in the
+newer version).  This is particularly evident in the stored representation of
+objects.
+
+All of this is best illustrated by examples.  Imagine a Kubernetes release,
+version X, which introduces a new API group.  A new Kubernetes release is made
+every approximately 3 months (4 per year).  The following table describes which
+API versions are supported in a series of subsequent releases.
+-->
+用户必须能够升级到 Kubernetes 新的发行版本，之后再回滚到前一个发行版本，且
+整个过程中无需针对新的 API 版本做任何转换，也不允许出现功能损坏的情况，
+除非用户显式地使用了仅在较新版本中才存在的功能特性。
+就对象的存储表示而言，这一点尤其是不言自明的。
+
+以上所有规则最好通过例子来说明。假定现有 Kubernetes 发行版本为 X，其中引入了
+新的 API 组。大约每隔 3 个月会有一个新的 Kubernetes 版本被发布（每年 4 个版本）。
+下面的表格描述了在一系列后续的发布版本中哪些 API 版本是受支持的。
+
+<table>
+  <thead>
+    <tr>
+      <!-- th>Release</th>
+      <th>API Versions</th>
+      <th>Preferred/Storage Version</th>
+      <th>Notes</th -->
+      <th>发布版本</th>
+      <th>API 版本</th>
+      <th>优选/存储版本</th>
+      <th>注释</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>X</td>
+      <td>v1alpha1</td>
+      <td>v1alpha1</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+1</td>
+      <td>v1alpha2</td>
+      <td>v1alpha2</td>
+      <td>
+        <ul>
+           <!-- li>v1alpha1 is removed, "action required" relnote</li -->
+           <li>v1alpha1 被去除，发布说明中会包含 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+2</td>
+      <td>v1beta1</td>
+      <td>v1beta1</td>
+      <td>
+        <ul>
+          <!-- li>v1alpha2 is removed, "action required" relnote</li -->
+          <li>v1alpha2 被去除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+3</td>
+      <!-- td>v1beta2, v1beta1 (deprecated)</td -->
+      <td>v1beta2、v1beta1（已弃用）</td>
+      <td>v1beta1</td>
+      <td>
+        <ul>
+          <!-- li>v1beta1 is deprecated, "action required" relnote</li -->
+          <li>v1beta1 被弃用，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+4</td>
+      <!-- td>v1beta2, v1beta1 (deprecated)</td -->
+      <td>v1beta2、v1beta1（已弃用）</td>
+      <td>v1beta2</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+5</td>
+      <!-- td>v1, v1beta1 (deprecated), v1beta2 (deprecated)</td -->
+      <td>v1、v1beta1（已弃用）、v1beta2（已弃用）</td>
+      <td>v1beta2</td>
+      <td>
+        <ul>
+          <!-- li>v1beta2 is deprecated, "action required" relnote</li -->
+          <li>v1beta2 被弃用，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+6</td>
+      <!-- td>v1, v1beta2 (deprecated)</td -->
+      <td>v1、v1beta2（已弃用）</td>
+      <td>v1</td>
+      <td>
+        <ul>
+          <!-- li>v1beta1 is removed, "action required" relnote</li -->
+          <li>v1beta1 被去除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+7</td>
+      <!-- td>v1, v1beta2 (deprecated)</td -->
+      <td>v1、v1beta2（已弃用）</td>
+      <td>v1</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+8</td>
+      <td>v2alpha1、v1</td>
+      <td>v1</td>
+      <td>
+        <ul>
+          <!-- li>v1beta2 is removed, "action required" relnote</li -->
+          <li>v1beta2 被去除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+9</td>
+      <td>v2alpha2、v1</td>
+      <td>v1</td>
+      <td>
+        <ul>
+           <!-- li>v2alpha1 is removed, "action required" relnote</li -->
+           <li>v2alpha1 被删除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+10</td>
+      <td>v2beta1、v1</td>
+      <td>v1</td>
+      <td>
+        <ul>
+          <!-- li>v2alpha2 is removed, "action required" relnote</li -->
+          <li>v2alpha2 被删除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+11</td>
+      <!-- td>v2beta2, v2beta1 (deprecated), v1</td -->
+      <td>v2beta2、v2beta1（已弃用）、v1</td>
+      <td>v1</td>
+      <td>
+        <ul>
+          <!-- li>v2beta1 is deprecated, "action required" relnote</li -->
+          <li>v2beta1 被弃用，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+12</td>
+      <!-- td>v2, v2beta2 (deprecated), v2beta1 (deprecated), v1 (deprecated)</td -->
+      <td>v2、v2beta2（已弃用）、v2beta1（已弃用）、v1（已弃用）</td>
+      <td>v1</td>
+      <td>
+        <ul>
+          <!-- li>v2beta2 is deprecated, "action required" relnote</li>
+          <li>v1 is deprecated, "action required" relnote</li -->
+          <li>v2beta2 已被弃用，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+          <li>v1 已被弃用，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+13</td>
+      <!-- td>v2, v2beta1 (deprecated), v2beta2 (deprecated), v1 (deprecated)</td -->
+      <td>v2、v2beta1（已弃用）、v2beta2（已弃用）、v1（已弃用）</td>
+      <td>v2</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+14</td>
+      <!-- td>v2, v2beta2 (deprecated), v1 (deprecated)</td -->
+      <td>v2、v2beta2（已弃用）、v1（已弃用）</td>
+      <td>v2</td>
+      <td>
+        <ul>
+          <!-- li>v2beta1 is removed, "action required" relnote</li -->
+          <li>v2beta1 被删除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+15</td>
+      <!-- td>v2, v1 (deprecated)</td -->
+      <td>v2、v1（已弃用）</td>
+      <td>v2</td>
+      <td>
+        <ul>
+          <!-- li>v2beta2 is removed, "action required" relnote</li -->
+          <li>v2beta2 被删除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+16</td>
+      <!-- td>v2, v1 (deprecated)</td -->
+      <td>v2、v1（已弃用）</td>
+      <td>v2</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+17</td>
+      <td>v2</td>
+      <td>v2</td>
+      <td>
+        <ul>
+          <li>v1 被删除，发布说明中包含对应的 "action required（采取行动）" 说明</li>
+        </ul>
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+<!--
+### REST resources (aka API objects)
+
+Consider a hypothetical REST resource named Widget, which was present in API v1
+in the above timeline, and which needs to be deprecated.  We document and
+[announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the
+deprecation in sync with release X+1.  The Widget resource still exists in API
+version v1 (deprecated) but not in v2alpha1.  The Widget resource continues to
+exist and function in releases up to and including X+8.  Only in release X+9,
+when API v1 has aged out, does the Widget resource cease to exist, and the
+behavior get removed.
+-->
+### REST 资源（也即 API 对象）
+
+考虑一个假想的名为 Widget 的 REST 资源，在上述时间线中位于 API v1，
+而现在打算将其弃用。
+我们会在文档和
+[声明](https://groups.google.com/forum/#!forum/kubernetes-announce)
+中与 X+1 版本的发布同步记述此弃用决定。
+Wdiget 资源仍会在 API 版本 v1（已弃用）中存在，但不会出现在 v2alpha1 中。
+Widget 资源会 X+8 发布版本之前（含 X+8）一直存在并可用。
+只有在发布版本 X+9 中，API v1 寿终正寝时，Widget
+才彻底消失，相应的资源行为也被移除。
+
+<!--
+Starting in Kubernetes v1.19, making an API request to a deprecated REST API endpoint:
+
+1. Returns a `Warning` header (as defined in [RFC7234, Section 5.5](https://tools.ietf.org/html/rfc7234#section-5.5)) in the API response.
+2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request.
+3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver` 
+   process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined
+   to the `apiserver_request_total` metric, and a `removed_version` label that indicates the 
+   Kubernetes release in which the API will no longer be served. The following Prometheus query
+   returns information about requests made to deprecated APIs which will be removed in v1.22:
+   
+   ```promql
+   apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total
+   ```
+-->
+从 Kubernetes v1.19 开始，当 API 请求被发送到一个已弃用的 REST API 末端时：
+
+1. API 响应中会包含一个 `Warning` 头部字段（如 [RFC7234 5.5 节](https://tools.ietf.org/html/rfc7234#section-5.5)所定义）；
+2. 该请求会导致对应的 
+   [审计事件](/zh/docs/tasks/debug-application-cluster/audit/)
+   中会增加一个注解 `"k8s.io/deprecated":"true"`。
+3. `kube-apiserver` 进程的 `apiserver_requested_deprecated_apis` 度量值会被
+   设置为 `1`。
+   该度量值还附带 `group`、`version`、`resource` 和 `subresource` 标签
+   （可供添加到度量值 `apiserver_request_total` 上），
+   和一个 `removed_version` 标签，标明该 API 将消失的 Kubernetes 发布版本。
+   下面的 Prometheus 查询会返回对 v1.22 中将移除的、已弃用的 API
+   的请求的信息：
+   
+   ```promql
+   apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total
+   ```
+
+<!--
+### Fields of REST resources
+
+As with whole REST resources, an individual field which was present in API v1
+must exist and function until API v1 is removed.  Unlike whole resources, the
+v2 APIs may choose a different representation for the field, as long as it can
+be round-tripped.  For example a v1 field named "magnitude" which was
+deprecated might be named "deprecatedMagnitude" in API v2.  When v1 is
+eventually removed, the deprecated field can be removed from v2.
+-->
+### REST 资源的字段    {#fields-of-rest-resources}
+
+就像整个 REST 资源一样，在 API v1 中曾经存在的各个字段在 API v1 被移除
+之前必须一直存在且起作用。
+与整个资源上的规定不同，v2 API 可以选择为字段提供不同的表示方式，
+只要对应的资源对象可在不同版本之间来回转换即可。
+例如，v1 版本中一个名为 "magnitude" 的已弃用字段可能在 API v2 中被命名
+为 "deprecatedMagnitude"。当 v1 最终被移除时，废弃的字段也可以从 v2
+中移除。
+
+<!--
+### Enumerated or constant values
+
+As with whole REST resources and fields thereof, a constant value which was
+supported in API v1 must exist and function until API v1 is removed.
+-->
+### 枚举值或常数值 {#enumerated-or-constant-values}
+
+就像前文讲述的 REST 资源及其中的单个字段一样，API v1 中所支持的常数值
+必须在 API v1 被移除之前一直存在且起作用。
+
+<!--
+### Component config structures
+
+Component configs are versioned and managed just like REST resources.
+-->
+### 组件配置结构  {#component-config-structures}
+
+组件的配置也是有版本的，并且按 REST 资源的方式来管理。
+
+<!--
+### Future work
+
+Over time, Kubernetes will introduce more fine-grained API versions, at which
+point these rules will be adjusted as needed.
+-->
+### 将来的工作    {#future-work}
+
+随着时间推移，Kubernetes 会引入粒度更细的 API 版本。
+到那时，这里的规则会根据需要进行调整。
+
+<!--
+## Deprecating a flag or CLI
+
+The Kubernetes system is comprised of several different programs cooperating.
+Sometimes, a Kubernetes release might remove flags or CLI commands
+(collectively "CLI elements") in these programs.  The individual programs
+naturally sort into two main groups - user-facing and admin-facing programs,
+which vary slightly in their deprecation policies.  Unless a flag is explicitly
+prefixed or documented as "alpha" or "beta", it is considered GA.
+-->
+## 弃用一个标志或 CLI 命令
+
+Kubernetes 系统中包含若干不同的、相互协作的程序。
+有时，Kubernetes 可能会删除这些程序的某些标志或 CLI 命令（统称“命令行元素”）。
+这些程序可以天然地划分到两个大组中：面向用户的和面向管理员的程序。
+二者之间的弃用策略略有不同。
+除非某个标志显示地通过前缀或文档来标明其为“alpha”或“beta”，
+该标志要被视作正式发布的（GA）。
+
+<!--
+CLI elements are effectively part of the API to the system, but since they are
+not versioned in the same way as the REST API, the rules for deprecation are as
+follows:
+-->
+命令行元素相当于系统的 API 的一部分，不过因为它们并没有采用 REST API
+一样的方式来管理版本，其弃用规则规定如下： 
+
+<!--
+**Rule #5a: CLI elements of user-facing components (e.g. kubectl) must function
+after their announced deprecation for no less than:**
+
+   * **GA: 12 months or 2 releases (whichever is longer)**
+   * **Beta: 3 months or 1 release (whichever is longer)**
+   * **Alpha: 0 releases**
+-->
+**规则 #5a：面向用户的命令行元素（例如，kubectl）必须在其宣布被弃用其
+在以下时长内仍能使用：**
+
+   * **GA：12 个月或者 2 个发布版本（取其较长者）**
+   * **Beta：3 个月或者 1 个发布版本（取其较长者）**
+   * **Alpha：0 发布版本**
+
+<!--
+**Rule #5b: CLI elements of admin-facing components (e.g. kubelet) must function
+after their announced deprecation for no less than:**
+
+   * **GA: 6 months or 1 release (whichever is longer)**
+   * **Beta: 3 months or 1 release (whichever is longer)**
+   * **Alpha: 0 releases**
+-->
+**规则 #5b：面向管理员的命令行元素（例如，kubelet）必须在其被宣布弃用
+之后以下时长内保持可用：**
+
+   * **GA：6 个月或 1 个发行版本（取其较长者）**
+   * **Beta: 3 个月或 1 个发行版本（取其较长者）**
+   * **Alpha: 0 个发布版本**
+
+<!--
+**Rule #6: Deprecated CLI elements must emit warnings (optionally disable)
+when used.**
+-->
+**规则 #6：被弃用的 CLI 元素在被用到时必须能够产生警告，而警告的
+产生是可以被禁止的。**
+
+<!--
+## Deprecating a feature or behavior
+
+Occasionally a Kubernetes release needs to deprecate some feature or behavior
+of the system that is not controlled by the API or CLI.  In this case, the
+rules for deprecation are as follows:
+-->
+## 弃用某功能特性或行为  {#deprecating-a-feature-or-behavior}
+
+在一些较偶然的情形下，某 Kubernetes 发行版本需要弃用系统的某项功能
+特性或者行为，而对应的功能特性或行为并不受 API 或 CLI 控制。在这种情况下，
+其弃用规则如下：
+
+<!--
+**Rule #7: Deprecated behaviors must function for no less than 1 year after their
+announced deprecation.**
+-->
+**规则 #7：被弃用的行为必须在被宣布弃用之后至少 1 年时间内必须保持能用。**
+
+<!--
+This does not imply that all changes to the system are governed by this policy.
+This applies only to significant, user-visible behaviors which impact the
+correctness of applications running on Kubernetes or that impact the
+administration of Kubernetes clusters, and which are being removed entirely.
+-->
+这并不意味着对系统的所有更改都受此策略约束。
+此规则仅适用于重大的、用户可见的行为；这些行为会影响到在 Kubernetes
+中运行的应用的正确性，或者影响到 Kubernetes 集群的管理。
+此规则也适用于那些被整个移除的功能特性或行为。
+
+<!--
+An exception to the above rule is _feature gates_. Feature gates are key=value
+pairs that allow for users to enable/disable experimental features.
+
+Feature gates are intended to cover the development life cycle of a feature - they
+are not intended to be long-term APIs. As such, they are expected to be deprecated
+and removed after a feature becomes GA or is dropped.
+-->
+上述规则的一个例外是 _特性门控（Feature Gates）_。特性门控是一些键值偶对，
+允许用户启用或禁用一些试验性的功能特性。
+
+特性门控意在覆盖功能特性的整个开发周期，它们无意成为长期的 API。
+因此，它们会在某功能特性正式发布或被抛弃之后被弃用和删除。
+
+<!--
+As a feature moves through the stages, the associated feature gate evolves.
+The feature life cycle matched to its corresponding feature gate is:
+
+  * Alpha: the feature gate is disabled by default and can be enabled by the user.
+  * Beta: the feature gate is enabled by default and can be disabled by the user.
+  * GA: the feature gate is deprecated (see ["Deprecation"](#deprecation)) and becomes
+  non-operational.
+  * GA, deprecation window complete: the feature gate is removed and calls to it are
+  no longer accepted.
+-->
+随着一个功能特性经过不同的成熟阶段，相关的特性门控也会演化。
+与功能特性生命周期对应的特性门控状态为：
+
+* Alpha：特性门控默认被禁用，只能由用户显式启用。
+* Beta：特性门控默认被弃用，可被用户显式禁用。
+* GA: 特性门控被弃用（参见[弃用](#deprecation)），并且不再起作用。
+* GA，弃用窗口期结束：特性门控被删除，不再接受调用。
+
+<!--
+### Deprecation
+
+Features can be removed at any point in the life cycle prior to GA. When features are
+removed prior to GA, their associated feature gates are also deprecated.
+
+When an invocation tries to disable a non-operational feature gate, the call fails in order
+to avoid unsupported scenarios that might otherwise run silently.
+-->
+### 弃用   {#deprecation}
+
+功能特性在正式发布之前的生命周期内任何时间点都可被移除。
+当未正式发布的功能特性被移除时，它们对应的特性门控也被弃用。
+
+当尝试禁用一个不再起作用的特性门控时，该调用会失败，这样可以避免
+毫无迹象地执行一些不受支持的场景。
+
+<!--
+In some cases, removing pre-GA features requires considerable time. Feature gates can remain
+operational until their associated feature is fully removed, at which point the feature gate
+itself can be deprecated.
+
+When removing a feature gate for a GA feature also requires considerable time, calls to
+feature gates may remain operational if the feature gate has no effect on the feature,
+and if the feature gate causes no errors.
+-->
+在某些场合，移除一个即将正式发布的功能特性需要很长时间。特性门控
+可以保持其功能，直到对应的功能特性被彻底去除，直到那时特性门控
+自身才可被弃用。
+
+由于移除一个已经正式发布的功能特性对应的特性门控也需要一定时间，对特性
+门控的调用可能一直被允许，前提是特性门控对功能本身无影响且特性门控不会
+引发任何错误。
+
+<!--
+Features intended to be disabled by users should include a mechanism for disabling the
+feature in the associated feature gate.
+
+Versioning for feature gates is different from the previously discussed components,
+therefore the rules for deprecation are as follows:
+-->
+意在允许用户禁用的功能特性应该包含一个在相关联的特性门控中禁用该功能的机制。
+
+特性门控的版本管理与之前讨论的组件版本管理不同，因此其对应的弃用策略如下：
+
+**规则 #8：特性门控所对应的功能特性经历下面所列的成熟性阶段转换时，特性门控
+必须被弃用。特性门控弃用时必须在以下时长内保持其功能可用：**
+
+   * **Beta 特性转为 GA：6 个月或者 2 个发布版本（取其较长者）**
+   * **Beta 特性转为丢弃：3 个月或者 1 个发布版本（取其较长者）**
+   * **Alpha 特性转为丢弃：0 个发布版本**
+
+<!--
+**Rule #9: Deprecated feature gates must respond with a warning when used. When a feature gate
+is deprecated it must be documented in both in the release notes and the corresponding CLI help.
+Both warnings and documentation must indicate whether a feature gate is non-operational.**
+-->
+**规则 #9：已弃用的特色门控再被使用时必须给出警告回应。当特性门控被
+弃用时，必须在发布说明和对应的 CLI 帮助信息中通过文档宣布。
+警告信息和文档都要标明是否某特性门控不再起作用。**
+
+<!--
+## Exceptions
+
+No policy can cover every possible situation.  This policy is a living
+document, and will evolve over time.  In practice, there will be situations
+that do not fit neatly into this policy, or for which this policy becomes a
+serious impediment.  Such situations should be discussed with SIGs and project
+leaders to find the best solutions for those specific cases, always bearing in
+mind that Kubernetes is committed to being a stable system that, as much as
+possible, never breaks users. Exceptions will always be announced in all
+relevant release notes.
+-->
+## 例外   {#exceptions}
+
+没有策略可以覆盖所有情况。此策略文档是一个随时被更新的文档，会随着时间
+推移演化。在实践中，会有一些情况无法很好地匹配到这里的弃用策略，或者
+这里的策略变成了很严重的羁绊。这类情形要与 SIG 和项目牵头人讨论，
+寻求对应场景的最佳解决方案。请一直铭记，Kubernetes 承诺要成为一个
+稳定的系统，至少会尽力做到不会影响到其用户。此弃用策略的任何例外情况
+都会在所有相关的发布说明中公布。
+
diff --git a/content/zh/docs/reference/using-api/health-checks.md b/content/zh/docs/reference/using-api/health-checks.md
new file mode 100644
index 0000000000..7422ea0063
--- /dev/null
+++ b/content/zh/docs/reference/using-api/health-checks.md
@@ -0,0 +1,145 @@
+---
+title: Kubernetes API 健康端点
+content_type: concept
+weight: 50
+---
+<!-- 
+title: Kubernetes API health endpoints
+reviewers:
+- logicalhan
+content_type: concept
+weight: 50
+ -->
+
+<!-- overview -->
+<!-- 
+The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server.
+This page describes these API endpoints and explains how you can use them. 
+-->
+Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}} 提供 API 端点以指示 API 服务器的当前状态。
+本文描述了这些 API 端点，并说明如何使用。
+
+<!-- body -->
+
+<!-- ## API endpoints for health -->
+## API 健康端点  {#api-endpoints-for-health}
+
+<!-- 
+The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server.
+The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead.
+The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
+For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
+Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
+A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
+-->
+Kubernetes API 服务器提供 3 个 API 端点（`healthz`、`livez` 和 `readyz`）来表明 API 服务器的当前状态。
+`healthz` 端点已被弃用（自 Kubernetes v1.16 起），你应该使用更为明确的 `livez` 和 `readyz` 端点。
+`livez` 端点可与 `--livez-grace-period` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)一起使用，来指定启动持续时间。
+为了正常关机，你可以使用 `/readyz` 端点并指定 `--shutdown-delay-duration` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)。
+检查 API 服务器的 `health`/`livez`/`readyz` 端点的机器应依赖于 HTTP 状态代码。
+状态码 `200` 表示 API 服务器是 `healthy`、`live` 还是 `ready`，具体取决于所调用的端点。
+以下更详细的选项供操作人员使用，用来调试其集群或专门调试 API 服务器的状态。
+
+<!-- The following examples will show how you can interact with the health API endpoints. -->
+以下示例将显示如何与运行状况 API 端点进行交互。
+
+<!-- 
+For all endpoints you can use the `verbose` parameter to print out the checks and their status.
+This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+-->
+对于所有端点，都可以使用 `verbose` 参数来打印检查项以及检查状态。
+这对于操作人员调试 API 服务器的当前状态很有用，这些不打算给机器使用：
+
+```shell
+curl -k https://localhost:6443/livez?verbose
+```
+
+<!-- or from a remote host with authentication: -->
+或从具有身份验证的远程主机：
+
+```shell
+kubectl get --raw='/readyz?verbose'
+```
+
+<!-- The output will look like this: -->
+输出将如下所示：
+
+```shell
+[+]ping ok
+[+]log ok
+[+]etcd ok
+[+]poststarthook/start-kube-apiserver-admission-initializer ok
+[+]poststarthook/generic-apiserver-start-informers ok
+[+]poststarthook/start-apiextensions-informers ok
+[+]poststarthook/start-apiextensions-controllers ok
+[+]poststarthook/crd-informer-synced ok
+[+]poststarthook/bootstrap-controller ok
+[+]poststarthook/rbac/bootstrap-roles ok
+[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+[+]poststarthook/start-cluster-authentication-info-controller ok
+[+]poststarthook/start-kube-aggregator-informers ok
+[+]poststarthook/apiservice-registration-controller ok
+[+]poststarthook/apiservice-status-available-controller ok
+[+]poststarthook/kube-apiserver-autoregistration ok
+[+]autoregister-completion ok
+[+]poststarthook/apiservice-openapi-controller ok
+healthz check passed
+```
+
+<!-- 
+The Kubernetes API server also supports to exclude specific checks.
+The query parameters can also be combined like in this example:
+-->
+Kubernetes API 服务器也支持排除特定的检查项。
+查询参数也可以像以下示例一样进行组合：
+
+```shell
+curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+```
+
+<!-- The output show that the `etcd` check is excluded: -->
+输出显示排除了 `etcd` 检查：
+
+```shell
+[+]ping ok
+[+]log ok
+[+]etcd excluded: ok
+[+]poststarthook/start-kube-apiserver-admission-initializer ok
+[+]poststarthook/generic-apiserver-start-informers ok
+[+]poststarthook/start-apiextensions-informers ok
+[+]poststarthook/start-apiextensions-controllers ok
+[+]poststarthook/crd-informer-synced ok
+[+]poststarthook/bootstrap-controller ok
+[+]poststarthook/rbac/bootstrap-roles ok
+[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+[+]poststarthook/start-cluster-authentication-info-controller ok
+[+]poststarthook/start-kube-aggregator-informers ok
+[+]poststarthook/apiservice-registration-controller ok
+[+]poststarthook/apiservice-status-available-controller ok
+[+]poststarthook/kube-apiserver-autoregistration ok
+[+]autoregister-completion ok
+[+]poststarthook/apiservice-openapi-controller ok
+[+]shutdown ok
+healthz check passed
+```
+
+<!-- ## Individual health checks -->
+## 独立健康检查  {#individual-health-check}
+
+{{< feature-state state="alpha" >}}
+
+<!-- 
+Each individual health check exposes an http endpoint and could can be checked individually.
+The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server.
+The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
+These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
+-->
+每个单独的健康检查都会公开一个 http 端点，并且可以单独检查。
+单个运行状况检查的模式为 `/livez/<healthcheck-name>`，其中 `livez` 和 `readyz` 表明你要检查的是 API 服务器是否存活或就绪。
+`<healthcheck-name>` 的路径可以通过上面的 `verbose` 参数发现 ，并采用 `[+]` 和 `ok` 之间的路径。
+这些单独的健康检查不应由机器使用，但对于操作人员调试系统而言，是有帮助的：
+
+```shell
+curl -k https://localhost:6443/livez/etcd
+```
diff --git a/content/zh/docs/reference/using-api/server-side-apply.md b/content/zh/docs/reference/using-api/server-side-apply.md
new file mode 100644
index 0000000000..974e1f2f70
--- /dev/null
+++ b/content/zh/docs/reference/using-api/server-side-apply.md
@@ -0,0 +1,810 @@
+---
+title: 服务器端应用（Server-Side Apply）
+content_type: concept
+weight: 25
+min-kubernetes-server-version: 1.16
+---
+<!-- 
+---
+title: Server-Side Apply
+reviewers:
+- smarterclayton
+- apelisse
+- lavalamp
+- liggitt
+content_type: concept
+weight: 25
+min-kubernetes-server-version: 1.16
+---
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+<!-- 
+## Introduction
+
+Server Side Apply helps users and controllers manage their resources via
+declarative configurations. It allows them to create and/or modify their
+[objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+declaratively, simply by sending their fully specified intent.
+-->
+## 简介 {#introduction}
+
+服务器端应用协助用户、控制器通过声明式配置的方式管理他们的资源。
+它发送完整描述的目标（A fully specified intent），
+声明式地创建和/或修改
+[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)。
+
+<!-- 
+A fully specified intent is a partial object that only includes the fields and
+values for which the user has an opinion. That intent either creates a new
+object or is [combined](#merge-strategy), by the server, with the existing object.
+
+The system supports multiple appliers collaborating on a single object.
+-->
+一个完整描述的目标并不是一个完整的对象，仅包括能体现用户意图的字段和值。
+该目标（intent）可以用来创建一个新对象，
+也可以通过服务器来实现与现有对象的[合并](#merge-strategy)。
+
+系统支持多个应用者（appliers）在同一个对象上开展协作。
+
+<!-- 
+Changes to an object's fields are tracked through a "[field management](#field-management)"
+mechanism. When a field's value changes, ownership moves from its current
+manager to the manager making the change. When trying to apply an object,
+fields that have a different value and are owned by another manager will
+result in a [conflict](#conflicts). This is done in order to signal that the
+operation might undo another collaborator's changes. Conflicts can be forced,
+in which case the value will be overridden, and the ownership will be
+transferred.
+-->
+“[字段管理（field management）](#field-management)”机制追踪对象字段的变化。
+当一个字段值改变时，其所有权从当前管理器（manager）转移到施加变更的管理器。
+当尝试将新配置应用到一个对象时，如果字段有不同的值，且由其他管理器管理，
+将会引发[冲突](#conflicts)。
+冲突引发警告信号：此操作可能抹掉其他协作者的修改。
+冲突可以被刻意忽略，这种情况下，值将会被改写，所有权也会发生转移。
+
+<!-- 
+If you remove a field from a configuration and apply the configuration, server
+side apply checks if there are any other field managers that also own the
+field.  If the field is not owned by any other field managers, it is either
+deleted from the live object or reset to its default value, if it has one. The
+same rule applies to associative list or map items.
+-->
+当你从配置文件中删除一个字段，然后应用这个配置文件，
+这将触发服务端应用检查此字段是否还被其他字段管理器拥有。
+如果没有，那就从活动对象中删除该字段；如果有，那就重置为默认值。
+该规则同样适用于 list 或 map 项目。
+
+<!-- 
+Server side apply is meant both as a replacement for the original `kubectl
+apply` and as a simpler mechanism for controllers to enact their changes.
+
+If you have Server Side Apply enabled, the control plane tracks managed fields
+for all newlly created objects.
+-->
+服务器端应用既是原有 `kubectl apply` 的替代品，
+也是控制器发布自身变化的一个简化机制。
+
+如果你启用了服务器端应用，控制平面就会跟踪被所有新创建对象管理的字段。
+
+<!-- 
+## Field Management
+
+Compared to the `last-applied` annotation managed by `kubectl`, Server Side
+Apply uses a more declarative approach, which tracks a user's field management,
+rather than a user's last applied state. This means that as a side effect of
+using Server Side Apply, information about which field manager manages each
+field in an object also becomes available.
+-->
+## 字段管理 {#field-management}
+
+相对于通过 `kubectl` 管理的注解 `last-applied`，
+服务器端应用使用了一种更具声明式特点的方法：
+它持续的跟踪用户的字段管理，而不仅仅是最后一次的执行状态。
+这就意味着，作为服务器端应用的一个副作用，
+关于用哪一个字段管理器负责管理对象中的哪个字段的这类信息，都要对外界开放了。
+
+<!-- 
+For a user to manage a field, in the Server Side Apply sense, means that the
+user relies on and expects the value of the field not to change. The user who
+last made an assertion about the value of a field will be recorded as the
+current field manager. This can be done either by changing the value with
+`POST`, `PUT`, or non-apply `PATCH`, or by including the field in a config sent
+to the Server Side Apply endpoint. When using Server-Side Apply, trying to
+change a field which is managed by someone else will result in a rejected
+request (if not forced, see [Conflicts](#conflicts)).
+-->
+用户管理字段这件事，在服务器端应用的场景中，意味着用户依赖并期望字段的值不要改变。
+最后一次对字段值做出断言的用户将被记录到当前字段管理器。
+这可以通过发送 `POST`、 `PUT`、 
+或非应用（non-apply）方式的 `PATCH` 等命令来修改字段值的方式实现，
+或通过把字段放在配置文件中，然后发送到服务器端应用的服务端点的方式实现。
+当使用服务器端应用，尝试着去改变一个被其他人管理的字段，
+会导致请求被拒绝（在没有设置强制执行时，参见[冲突](#conflicts)）。
+
+<!-- 
+When two or more appliers set a field to the same value, they share ownership of
+that field. Any subsequent attempt to change the value of the shared field, by any of
+the appliers, results in a conflict. Shared field owners may give up ownership
+of a field by removing it from their configuration.
+
+Field management is stored in a`managedFields` field that is part of an object's
+[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta).
+
+A simple example of an object created by Server Side Apply could look like this:
+-->
+如果两个或以上的应用者均把同一个字段设置为相同值，他们将共享此字段的所有权。
+后续任何改变共享字段值的尝试，不管由那个应用者发起，都会导致冲突。
+共享字段的所有者可以放弃字段的所有权，这只需从配置文件中删除该字段即可。
+
+字段管理的信息存储在 `managedFields` 字段中，该字段是对象的 
+[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta)中的一部分。
+
+服务器端应用创建对象的简单示例如下：
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: test-cm
+  namespace: default
+  labels:
+    test-label: test
+  managedFields:
+  - manager: kubectl
+    operation: Apply
+    apiVersion: v1
+    time: "2010-10-10T0:00:00Z"
+    fieldsType: FieldsV1
+    fieldsV1:
+      f:metadata:
+        f:labels:
+          f:test-label: {}
+      f:data:
+        f:key: {}
+data:
+  key: some value
+```
+
+<!-- 
+The above object contains a single manager in `metadata.managedFields`. The
+manager consists of basic information about the managing entity itself, like
+operation type, API version, and the fields managed by it.
+
+This field is managed by the  API server and should not be changed by
+the user.
+-->
+上述对象在 `metadata.managedFields` 中包含了唯一的管理器。
+管理器由管理实体自身的基本信息组成，比如操作类型、API 版本、以及它管理的字段。
+
+{{< note >}}
+该字段由 API 服务器管理，用户不应该改动它。
+{{< /note >}}
+
+<!-- 
+Nevertheless it is possible to change `metadata.managedFields` through an
+`Update` operation. Doing so is highly discouraged, but might be a reasonable
+option to try if, for example, the `managedFields` get into an inconsistent
+state (which clearly should not happen).
+
+The format of the `managedFields` is described in the
+[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta).
+-->
+不过，执行 `Update` 操作修改 `metadata.managedFields` 也是可实现的。
+强烈不鼓励这么做，但当发生如下情况时，
+比如 `managedFields` 进入不一致的状态（显然不应该发生这种情况），
+这么做也是一个合理的尝试。
+
+`managedFields` 的格式在
+[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta)
+文档中描述。
+
+<!-- 
+## Conflicts
+
+A conflict is a special status error that occurs when an `Apply` operation tries
+to change a field, which another user also claims to manage. This prevents an
+applier from unintentionally overwriting the value set by another user. When
+this occurs, the applier has 3 options to resolve the conflicts:
+-->
+## 冲突 {#conflicts}
+
+冲突是一种特定的错误状态，
+发生在执行 `Apply` 改变一个字段，而恰巧该字段被其他用户声明过主权时。
+这可以防止一个应用者不小心覆盖掉其他用户设置的值。
+冲突发生时，应用者有三种办法来解决它：
+
+<!-- 
+* **Overwrite value, become sole manager:** If overwriting the value was
+  intentional (or if the applier is an automated process like a controller) the
+  applier should set the `force` query parameter to true and make the request
+  again. This forces the operation to succeed, changes the value of the field,
+  and removes the field from all other managers' entries in managedFields.
+
+* **Don't overwrite value, give up management claim:** If the applier doesn't
+  care about the value of the field anymore, they can remove it from their
+  config and make the request again. This leaves the value unchanged, and causes
+  the field to be removed from the applier's entry in managedFields.
+
+* **Don't overwrite value, become shared manager:** If the applier still cares
+  about the value of the field, but doesn't want to overwrite it, they can
+  change the value of the field in their config to match the value of the object
+  on the server, and make the request again. This leaves the value unchanged,
+  and causes the field's management to be shared by the applier and all other
+  field managers that already claimed to manage it.
+-->
+* **覆盖前值，成为唯一的管理器：** 如果打算覆盖该值（或应用者是一个自动化部件，比如控制器），
+  应用者应该设置查询参数 `force` 为 true，然后再发送一次请求。
+  这将强制操作成功，改变字段的值，从所有其他管理器的 managedFields 条目中删除指定字段。
+
+* **不覆盖前值，放弃管理权：** 如果应用者不再关注该字段的值，
+  可以从配置文件中删掉它，再重新发送请求。
+  这就保持了原值不变，并从 managedFields 的应用者条目中删除该字段。
+
+* **不覆盖前值，成为共享的管理器：** 如果应用者仍然关注字段值，并不想覆盖它，
+  他们可以在配置文件中把字段的值改为和服务器对象一样，再重新发送请求。
+  这样在不改变字段值的前提下，
+  就实现了字段管理被应用者和所有声明了管理权的其他的字段管理器共享。
+
+<!-- 
+## Managers
+
+Managers identify distinct workflows that are modifying the object (especially
+useful on conflicts!), and can be specified through the `fieldManager` query
+parameter as part of a modifying request. It is required for the apply endpoint,
+though kubectl will default it to `kubectl`. For other updates, its default is
+computed from the user-agent.
+-->
+## 管理器 {#managers}
+
+管理器识别出正在修改对象的工作流程（在冲突时尤其有用）,
+管理器可以通过修改请求的参数 `fieldManager` 指定。
+虽然 kubectl 默认发往 `kubectl` 服务端点，但它则请求到应用的服务端点（apply endpoint）。
+对于其他的更新，它默认的是从用户代理计算得来。
+
+<!-- 
+## Apply and Update
+
+The two operation types considered by this feature are `Apply` (`PATCH` with
+content type `application/apply-patch+yaml`) and `Update` (all other operations
+which modify the object). Both operations update the `managedFields`, but behave
+a little differently.
+
+Whether you are submitting JSON data or YAML data, use
+`application/apply-patch+yaml` as the `Content-Type` header value.
+
+All JSON documents are valid YAML.
+-->
+## 应用和更新 {#apply-and-update}
+
+此特性涉及两类操作，分别是 `Apply`
+（内容类型为 `application/apply-patch+yaml` 的 `PATCH` 请求）
+和 `Update` （所有修改对象的其他操作）。
+这两类操作都会更新字段 `managedFields`，但行为表现有一点不同。
+
+{{< note >}}
+不管你提交的是 JSON 数据还是 YAML 数据，
+都要使用 `application/apply-patch+yaml` 作为 `Content-Type` 的值。
+
+所有的 JSON 文档 都是合法的 YAML。
+{{< /note >}}
+
+<!-- 
+For instance, only the apply operation fails on conflicts while update does
+not. Also, apply operations are required to identify themselves by providing a
+`fieldManager` query parameter, while the query parameter is optional for update
+operations. Finally, when using the apply operation you cannot have
+`managedFields` in the object that is being applied.
+
+An example object with multiple managers could look like this:
+-->
+例如，在冲突发生的时候，只有 `apply` 操作失败，而 `update` 则不会。
+此外，`apply` 操作必须通过提供一个 `fieldManager` 查询参数来标识自身，
+而此查询参数对于 `update` 操作则是可选的。
+最后，当使用 `apply` 命令时，你不能在应用中的对象中持有 `managedFields`。
+
+一个包含多个管理器的对象，示例如下：
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: test-cm
+  namespace: default
+  labels:
+    test-label: test
+  managedFields:
+  - manager: kubectl
+    operation: Apply
+    apiVersion: v1
+    fields:
+      f:metadata:
+        f:labels:
+          f:test-label: {}
+  - manager: kube-controller-manager
+    operation: Update
+    apiVersion: v1
+    time: '2019-03-30T16:00:00.000Z'
+    fields:
+      f:data:
+        f:key: {}
+data:
+  key: new value
+```
+
+<!-- 
+In this example, a second operation was run as an `Update` by the manager called
+`kube-controller-manager`. The update changed a value in the data field which
+caused the field's management to change to the `kube-controller-manager`.
+
+If this update would have been an `Apply` operation, the operation
+would have failed due to conflicting ownership.
+-->
+在这个例子中，
+第二个操作被管理器 `kube-controller-manager` 以 `Update` 的方式运行。
+此 `update` 更改 data 字段的值，
+并使得字段管理器被改为 `kube-controller-manager`。
+
+如果把 `update` 操作改为 `Apply`，那就会因为所有权冲突的原因，导致操作失败。
+
+<!-- 
+## Merge strategy
+
+The merging strategy, implemented with Server Side Apply, provides a generally
+more stable object lifecycle. Server Side Apply tries to merge fields based on
+the fact who manages them instead of overruling just based on values. This way
+it is intended to make it easier and more stable for multiple actors updating
+the same object by causing less unexpected interference.
+-->
+## 合并策略 {#merge-strategy}
+
+由服务器端应用实现的合并策略，提供了一个总体更稳定的对象生命周期。
+服务器端应用试图依据谁管理它们来合并字段，而不只是根据值来否决。
+这么做是为了多个参与者可以更简单、更稳定的更新同一个对象，且避免引起意外干扰。
+
+<!-- 
+When a user sends a "fully-specified intent" object to the Server Side Apply
+endpoint, the server merges it with the live object favoring the value in the
+applied config if it is specified in both places. If the set of items present in
+the applied config is not a superset of the items applied by the same user last
+time, each missing item not managed by any other appliers is removed. For
+more information about how an object's schema is used to make decisions when
+merging, see
+[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff).
+-->
+当用户发送一个“完整描述的目标”对象到服务器端应用的服务端点，
+服务器会将它和活动对象做一次合并，如果两者中有重复定义的值，那就以配置文件的为准。
+如果配置文件中的项目集合不是此用户上一次操作项目的超集，
+所有缺少的、没有其他应用者管理的项目会被删除。
+关于合并时用来做决策的对象规格的更多信息，参见
+[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff).
+
+<!-- 
+A number of markers were added in Kubernetes 1.16 and 1.17, to allow API
+developers to describe the merge strategy supported by lists, maps, and
+structs. These markers can be applied to objects of the respective type,
+in Go files or in the OpenAPI schema definition of the 
+[CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io):
+-->
+Kubernetes 1.16 和 1.17 中添加了一些标记，
+允许 API 开发人员描述由 list、map、和 structs 支持的合并策略。
+这些标记可应用到相应类型的对象，在 Go 文件或在
+[CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)
+的 OpenAPI 的模式中定义：
+
+<!-- 
+| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
+|---|---|---|---|---|
+| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16          |
+| `//+listMapKey` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. While there can be multiple keys, `listMapKey` is singular because keys need to be specified individually in the Go type. | 1.16 |
+| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
+| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |
+-->
+| Golang 标记 | OpenAPI extension | 可接受的值 | 描述 | 引入版本 |
+|---|---|---|---|---|
+| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | 适用于 list。 `atomic` 和 `set` 适用于只包含标量元素的 list。 `map` 适用于只包含嵌套类型的 list。 如果配置为 `atomic`, 合并时整个列表会被替换掉; 任何时候，唯一的管理器都把列表作为一个整体来管理。如果是细粒度管理，不同的管理器也可以分开管理条目。 | 1.16          |
+| `//+listMapKey` | `x-kubernetes-list-map-keys` | 用来唯一标识条目的 map keys 切片，例如 `["port", "protocol"]` | 仅当 `+listType=map` 时适用。组合值的字符串切片必须唯一标识列表中的条目。尽管有多个 key，`listMapKey` 是单数的，这是因为 key 需要在 Go 类型中单独的指定。 | 1.16 |
+| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 map。 `atomic` 指 map 只能被单个的管理器整个的替换。 `granular` 指 map 支持多个管理器各自更新自己的字段。 | 1.17 |
+| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 structs；否则就像 `//+mapType` 有相同的用法和 openapi 注释.| 1.17 |
+
+<!-- 
+### Custom Resources
+
+By default, Server Side Apply treats custom resources as unstructured data. All
+keys are treated the same as struct fields, and all lists are considered atomic.
+
+If the Custom Resource Definition defines a
+[schema](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)
+that contains annotations as defined in the previous "Merge Strategy"
+section, these annotations will be used when merging objects of this
+type.
+-->
+### 自定义资源 {#custom-resources}
+
+默认情况下，服务器端应用把自定义资源看做非结构化数据。
+所有的键值（keys）就像 struct 的字段一样被处理，
+所有的 list 被认为是原子性的。
+
+如果自定义资源定义（Custom Resource Definition，CRD）定义了一个 
+[模式](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)，
+它包含类似以前“合并策略”章节中定义过的注解，
+这些注解将在合并此类型的对象时使用。
+
+<!-- 
+### Using Server-Side Apply in a controller
+
+As a developer of a controller, you can use server-side apply as a way to
+simplify the update logic of your controller. The main differences with a
+read-modify-write and/or patch are the following:
+
+* the applied object must contain all the fields that the controller cares about.
+* there are no way to remove fields that haven't been applied by the controller
+  before (controller can still send a PATCH/UPDATE for these use-cases).
+* the object doesn't have to be read beforehand, `resourceVersion` doesn't have
+  to be specified.
+
+It is strongly recommended for controllers to always "force" conflicts, since they
+might not be able to resolve or act on these conflicts.
+-->
+### 在控制器中使用服务器端应用 {#using-server-side-apply-in-controller}
+
+控制器的开发人员可以把服务器端应用作为简化控制器的更新逻辑的方式。
+读-改-写 和/或 patch 的主要区别如下所示：
+
+* 应用的对象必须包含控制器关注的所有字段。
+* 对于在控制器没有执行过应用操作之前就已经存在的字段，不能删除。
+  （控制器在这种用例环境下，依然可以发送一个 PATCH/UPDATE）
+* 对象不必事先读取，`resourceVersion` 不必指定。
+
+强烈推荐：设置控制器在冲突时强制执行，这是因为冲突发生时，它们没有其他解决方案或措施。
+
+<!-- 
+### Transferring Ownership
+
+In addition to the concurrency controls provided by [conflict resolution](#conflicts),
+Server Side Apply provides ways to perform coordinated
+field ownership transfers from users to controllers.
+
+This is best explained by example. Let's look at how to safely transfer
+ownership of the `replicas` field from a user to a controller while enabling
+automatic horizontal scaling for a Deployment, using the HorizontalPodAutoscaler
+resource and its accompanying controller.
+
+Say a user has defined deployment with `replicas` set to the desired value:
+-->
+### 转移所有权 {#transferring-ownership}
+
+除了通过[冲突解决方案](#conflicts)提供的并发控制，
+服务器端应用提供了一些协作方式来将字段所有权从用户转移到控制器。
+
+最好通过例子来说明这一点。
+让我们来看看，在使用 Horizo​​ntalPodAutoscaler 资源和与之配套的控制器，
+且开启了 Deployment 的自动水平扩展功能之后，
+怎么安全的将 `replicas` 字段的所有权从用户转移到控制器。
+
+假设用户定义了 Deployment，且 `replicas` 字段已经设置为期望的值：
+
+{{< codenew file="application/ssa/nginx-deployment.yaml" >}}
+
+<!-- 
+And the user has created the deployment using server side apply like so:
+-->
+并且，用户使用服务器端应用，像这样创建 Deployment：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment.yaml --server-side
+```
+
+<!-- 
+Then later, HPA is enabled for the deployment, e.g.:
+-->
+然后，为 Deployment 启用 HPA，例如：
+
+```shell
+kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10
+```
+
+<!-- 
+Now, the user would like to remove `replicas` from their configuration, so they
+don't accidentally fight with the HPA controller. However, there is a race: it
+might take some time before HPA feels the need to adjust `replicas`, and if
+the user removes `replicas` before the HPA writes to the field and becomes
+its owner, then apiserver will set `replicas` to 1, its default value. This
+is not what the user wants to happen, even temporarily.
+-->
+现在，用户希望从他们的配置中删除 `replicas`，所以他们总是和 HPA 控制器冲突。
+然而，这里存在一个竟态：
+在 HPA 需要调整 `replicas` 之前会有一个时间窗口，
+如果在 HPA 写入字段成为所有者之前，用户删除了`replicas`，
+那 API 服务器就会把 `replicas` 的值设为1， 也就是默认值。
+这不是用户希望发生的事情，即使是暂时的。
+
+<!-- 
+There are two solutions:
+
+- (easy) Leave `replicas` in the configuration; when HPA eventually writes to that
+  field, the system gives the user a conflict over it. At that point, it is safe
+  to remove from the configuration.
+
+- (more advanced) If, however, the user doesn't want to wait, for example
+  because they want to keep the cluster legible to coworkers, then they can take
+  the following steps to make it safe to remove `replicas` from their
+  configuration:
+
+First, the user defines a new configuration containing only the `replicas` field:
+-->
+这里有两个解决方案：
+
+- （容易） 把 `replicas` 留在配置文件中；当 HPA 最终写入那个字段，
+  系统基于此事件告诉用户：冲突发生了。在这个时间点，可以安全的删除配置文件。
+- （高级）然而，如果用户不想等待，比如他们想为合作伙伴保持集群清晰，
+  那他们就可以执行以下步骤，安全的从配置文件中删除 `replicas`。
+
+首先，用户新定义一个只包含 `replicas` 字段的配置文件：
+
+{{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}}
+
+<!-- 
+The user applies that configuration using the field manager name `handover-to-hpa`:
+-->
+用户使用名为 `handover-to-hpa` 的字段管理器，应用此配置文件。
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replicas-only.yaml \
+  --server-side --field-manager=handover-to-hpa \
+  --validate=false
+```
+
+<!-- 
+If the apply results in a conflict with the HPA controller, then do nothing. The
+conflict just indicates the controller has claimed the field earlier in the
+process than it sometimes does.
+
+At this point the user may remove the `replicas` field from their configuration.
+-->
+如果应用操作和 HPA 控制器产生冲突，那什么都不做。
+冲突只是表明控制器在更早的流程中已经对字段声明过所有权。
+
+在此时间点，用户可以从配置文件中删除 `replicas` 。
+
+{{< codenew file="application/ssa/nginx-deployment-no-replicas.yaml" >}}
+
+<!-- 
+Note that whenever the HPA controller sets the `replicas` field to a new value,
+the temporary field manager will no longer own any fields and will be
+automatically deleted. No clean up is required.
+-->
+注意，只要 HPA 控制器为 `replicas` 设置了一个新值，
+该临时字段管理器将不再拥有任何字段，会被自动删除。
+这里不需要执行清理工作。
+
+<!-- 
+## Transferring Ownership Between Users
+
+Users can transfer ownership of a field between each other by setting the field
+to the same value in both of their applied configs, causing them to share
+ownership of the field. Once the users share ownership of the field, one of them
+can remove the field from their applied configuration to give up ownership and
+complete the transfer to the other user.
+-->
+## 在用户之间转移所有权 {#transferring-ownership-between-users}
+
+通过在配置文件中把一个字段设置为相同的值，用户可以在他们之间转移字段的所有权，
+从而共享了字段的所有权。
+当用户共享了字段的所有权，任何一个用户可以从他的配置文件中删除该字段，
+并应用该变更，从而放弃所有权，并实现了所有权向其他用户的转移。
+
+<!-- 
+## Comparison with Client Side Apply
+
+A consequence of the conflict detection and resolution implemented by Server
+Side Apply is that an applier always has up to date field values in their local
+state. If they don't, they get a conflict the next time they apply. Any of the
+three options to resolve conflicts results in the applied configuration being an
+up to date subset of the object on the server's fields.
+
+This is different from Client Side Apply, where outdated values which have been
+overwritten by other users are left in an applier's local config. These values
+only become accurate when the user updates that specific field, if ever, and an
+applier has no way of knowing whether their next apply will overwrite other
+users' changes.
+
+Another difference is that an applier using Client Side Apply is unable to
+change the API version they are using, but Server Side Apply supports this use
+case.
+-->
+## 与客户端应用的对比 {#comparison-with-client-side-apply}
+
+由服务器端应用实现的冲突检测和解决方案的一个结果就是，
+应用者总是可以在本地状态中得到最新的字段值。
+如果得不到最新值，下次执行应用操作时就会发生冲突。
+解决冲突三个选项的任意一个都会保证：此应用过的配置文件是服务器上对象字段的最新子集。
+
+这和客户端应用（Client Side Apply） 不同，如果有其他用户覆盖了此值，
+过期的值被留在了应用者本地的配置文件中。
+除非用户更新了特定字段，此字段才会准确，
+应用者没有途径去了解下一次应用操作是否会覆盖其他用户的修改。
+
+另一个区别是使用客户端应用的应用者不能改变他们正在使用的 API 版本，但服务器端应用支持这个场景。
+
+<!-- 
+## Upgrading from client-side apply to server-side apply
+
+Client-side apply users who manage a resource with `kubectl apply` can start
+using server-side apply with the following flag.
+-->
+## 从客户端应用升级到服务器端应用 {#upgrading-from-client-side-apply-to-server-side-apply}
+
+客户端应用方式时，用户使用 `kubectl apply` 管理资源，
+可以通过使用下面标记切换为使用服务器端应用。
+
+```shell
+kubectl apply --server-side [--dry-run=server]
+```
+<!-- 
+By default, field management of the object transfers from client-side apply to
+kubectl server-side apply without encountering conflicts.
+
+Keep the `last-applied-configuration` annotation up to date.
+The annotation infers client-side apply's managed fields.
+Any fields not managed by client-side apply raise conflicts.
+
+For example, if you used `kubectl scale` to update the replicas field after
+client-side apply, then this field is not owned by client-side apply and
+creates conflicts on `kubectl apply --server-side`.
+
+This behavior applies to server-side apply with the `kubectl` field manager.
+As an exception, you can opt-out of this behavior by specifying a different,
+non-default field manager, as seen in the following example. The default field
+manager for kubectl server-side apply is `kubectl`.
+-->
+默认情况下，对象的字段管理从客户端应用方式迁移到 kubectl 触发的服务器端应用时，不会发生冲突。
+
+{{< caution >}}
+保持注解 `last-applied-configuration` 是最新的。
+从注解能推断出字段是由客户端应用管理的。
+任何没有被客户端应用管理的字段将引发冲突。
+
+举例说明，比如你在客户端应用之后，
+使用 `kubectl scale` 去更新 `replicas` 字段，
+可是该字段并没有被客户端应用所拥有，
+在执行 `kubectl apply --server-side` 时就会产生冲突。
+{{< /caution >}}
+
+此操作以 `kubectl` 作为字段管理器来应用到服务器端应用。
+作为例外，可以指定一个不同的、非默认字段管理器停止的这种行为，如下面的例子所示。
+对于 kubectl 触发的服务器端应用，默认的字段管理器是 `kubectl`。
+
+```shell
+kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
+```
+
+<!-- 
+## Downgrading from server-side apply to client-side apply
+
+If you manage a resource with `kubectl apply --server-side`,
+you can downgrade to client-side apply directly with `kubectl apply`.
+
+Downgrading works because kubectl server-side apply keeps the
+`last-applied-configuration` annotation up-to-date if you use
+`kubectl apply`.
+
+This behavior applies to server-side apply with the `kubectl` field manager.
+As an exception, you can opt-out of this behavior by specifying a different,
+non-default field manager, as seen in the following example. The default field
+manager for kubectl server-side apply is `kubectl`.
+-->
+## 从服务器端应用降级到客户端应用 {#downgrading-from-server-side-apply-to-client-side-apply}
+
+如果你用 `kubectl apply --server-side` 管理一个资源，
+可以直接用 `kubectl apply` 命令将其降级为客户端应用。
+
+降级之所以可行，这是因为 `kubectl server-side apply`
+会保存最新的 `last-applied-configuration` 注解。
+
+此操作以 `kubectl` 作为字段管理器应用到服务器端应用。
+作为例外，可以指定一个不同的、非默认字段管理器停止这种行为，如下面的例子所示。
+对于 kubectl 触发的服务器端应用，默认的字段管理器是 `kubectl`。
+
+```shell
+kubectl apply --server-side --field-manager=my-manager [--dry-run=server]
+```
+
+<!-- 
+## API Endpoint
+
+With the Server Side Apply feature enabled, the `PATCH` endpoint accepts the
+additional `application/apply-patch+yaml` content type. Users of Server Side
+Apply can send partially specified objects as YAML to this endpoint.  When
+applying a configuration, one should always include all the fields that they
+have an opinion about.
+-->
+## API 端点 {#api-endpoint}
+
+启用了服务器端应用特性之后，
+`PATCH` 服务端点接受额外的内容类型 `application/apply-patch+yaml`。
+服务器端应用的用户就可以把 YAMl 格式的
+部分定义对象（partially specified objects）发送到此端点。
+当一个配置文件被应用时，它应该包含所有体现你意图的字段。
+
+<!-- 
+## Clearing ManagedFields
+
+It is possible to strip all managedFields from an object by overwriting them
+using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
+non-apply operation. This can be done by overwriting the managedFields field
+with an empty entry. Two examples are:
+-->
+## 清除 ManagedFields {#clearing-managedfields}
+
+可以从对象中剥离所有 managedField，
+实现方法是通过使用 `MergePatch`、 `StrategicMergePatch`、 
+`JSONPatch`、 `Update`、以及所有的非应用方式的操作来覆盖它。
+这可以通过用空条目覆盖 managedFields 字段的方式实现。
+
+```console
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/merge-patch+json
+Accept: application/json
+Data: {"metadata":{"managedFields": [{}]}}
+```
+
+```console
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/json-patch+json
+Accept: application/json
+Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
+```
+
+<!-- 
+This will overwrite the managedFields with a list containing a single empty
+entry that then results in the managedFields being stripped entirely from the
+object. Note that just setting the managedFields to an empty list will not
+reset the field. This is on purpose, so managedFields never get stripped by
+clients not aware of the field.
+
+In cases where the reset operation is combined with changes to other fields
+than the managedFields, this will result in the managedFields being reset
+first and the other changes being processed afterwards. As a result the
+applier takes ownership of any fields updated in the same request.
+-->
+这一操作将用只包含一个空条目的 list 覆写 managedFields，
+来实现从对象中整个的去除 managedFields。
+注意，只把 managedFields 设置为空 list 并不会重置字段。
+这么做是有目的的，所以 managedFields 将永远不会被与该字段无关的客户删除。
+
+在重置操作结合 managedFields 以外其他字段更改的场景中，
+将导致 managedFields 首先被重置，其他改变被押后处理。
+其结果是，应用者取得了同一个请求中所有字段的所有权。
+
+<!-- 
+Server Side Apply does not correctly track ownership on
+sub-resources that don't receive the resource object type. If you are
+using Server Side Apply with such a sub-resource, the changed fields
+won't be tracked.
+-->
+{{< caution >}}
+对于不接受资源对象类型的子资源（sub-resources），
+服务器端应用不能正确地跟踪其所有权。
+如果你对这样的子资源使用服务器端应用，变更的字段将不会被跟踪。
+{{< /caution >}}
+
+<!-- 
+## Disabling the feature
+
+Server Side Apply is a beta feature, so it is enabled by default. To turn this
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates) off,
+you need to include the `--feature-gates ServerSideApply=false` flag when
+starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all
+should have the same flag setting.
+-->
+## 禁用此功能 {#disabling-the-feature}
+
+服务器端应用是一个 beta 版特性，默认启用。
+要关闭此[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)，
+你需要在启动 `kube-apiserver` 时包含参数 `--feature-gates ServerSideApply=false`。
+如果你有多个 `kube-apiserver` 副本，他们都应该有相同的标记设置。
\ No newline at end of file
diff --git a/content/zh/docs/setup/_index.md b/content/zh/docs/setup/_index.md
index 81e8d38ef8..16c58a7b6c 100644
--- a/content/zh/docs/setup/_index.md
+++ b/content/zh/docs/setup/_index.md
@@ -82,8 +82,8 @@ If you're learning Kubernetes, use the Docker-based solutions: tools supported b
 
 |社区           |生态系统     |
 | ------------       | --------     |
-| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
-| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
+| [Minikube](/zh/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
+| [kind (Kubernetes IN Docker)](/zh/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
 |                     | [MicroK8s](https://microk8s.io/)|
 
 
@@ -100,6 +100,5 @@ When evaluating a solution for a production environment, consider which aspects
 <!--
 [Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers.
 -->
-[Kubernetes 合作伙伴](https://kubernetes.io/partners/#conformance) 包括一个 [已认证的 Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 提供商列表。
-
-
+[Kubernetes 合作伙伴](https://kubernetes.io/zh/partners/#kcsp) 包括一个
+[已认证的 Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 提供商列表。
diff --git a/content/zh/docs/setup/best-practices/certificates.md b/content/zh/docs/setup/best-practices/certificates.md
index 67fe1c9942..cead60c2a0 100644
--- a/content/zh/docs/setup/best-practices/certificates.md
+++ b/content/zh/docs/setup/best-practices/certificates.md
@@ -6,13 +6,11 @@ content_type: concept
 weight: 40
 ---
 <!--
----
 title: PKI certificates and requirements
 reviewers:
 - sig-cluster-lifecycle
 content_type: concept
 weight: 40
----
 -->
 
 <!-- overview -->
@@ -20,10 +18,13 @@ weight: 40
 <!--
 Kubernetes requires PKI certificates for authentication over TLS.
 If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated.
-You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
+You can also generate your own certificates - for example, to keep your private keys more secure by not storing them on the API server.
 This page explains the certificates that your cluster requires.
 -->
-Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果您是使用 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 安装的 Kubernetes，则会自动生成集群所需的证书。您还可以生成自己的证书。例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。
+Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用
+[kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 安装的 Kubernetes，
+则会自动生成集群所需的证书。你还可以生成自己的证书。
+例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。
 
 
 
@@ -57,11 +58,13 @@ Kubernetes 需要 PKI 才能执行以下操作：
 * 调度器的客户端证书/kubeconfig，用于和 API server 的会话
 * [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书
 
-{{< note >}}
 <!--
 `front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/).
 -->
-只有当您运行 kube-proxy 并要支持[扩展 API 服务器](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)时，才需要 `front-proxy` 证书
+{{< note >}}
+只有当你运行 kube-proxy 并要支持
+[扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
+时，才需要 `front-proxy` 证书
 {{< /note >}}
 
 <!--
@@ -146,9 +149,12 @@ Required certificates:
 
 where `kind` maps to one or more of the [x509 key usage][usage] types:
 -->
-[1]: 用来连接到集群的不同 IP 或 DNS 名（就像 [kubeadm][kubeadm] 为负载均衡所使用的固定 IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）
+[1]: 用来连接到集群的不同 IP 或 DNS 名
+（就像 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 为负载均衡所使用的固定
+IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、
+`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）。
 
-其中，`kind` 对应一种或多种类型的 [x509 密钥用途][usage]：
+其中，`kind` 对应一种或多种类型的 [x509 密钥用途][https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage]：
 
 <!--
 | kind   | Key usage                                                                       |
@@ -217,8 +223,8 @@ Same considerations apply for the service account key pair:
 
 | 私钥路径            | 公钥路径            | 命令                 | 参数                             |
 |------------------------------|-----------------------------|-------------------------|--------------------------------------|
-|  sa.key                      |                             | kube-controller-manager | service-account-private              |
-|                              | sa.pub                      | kube-apiserver          | service-account-key                  |
+|  sa.key                      |                             | kube-controller-manager | --service-account-private-key-file              |
+|                              | sa.pub                      | kube-apiserver          | --service-account-key-file                  |
 
 <!--
 ## Configure certificates for user accounts
@@ -227,20 +233,21 @@ You must manually configure these administrator account and service accounts:
 -->
 ## 为用户帐户配置证书
 
-您必须手动配置以下管理员帐户和服务帐户：
+你必须手动配置以下管理员帐户和服务帐户：
 
-| 文件名                | 凭据名称            | 默认 CN                     | O (位于 Subject 中) |
-|-------------------------|----------------------------|--------------------------------|----------------|
-| admin.conf              | default-admin              | kubernetes-admin               | system:masters |
-| kubelet.conf            | default-auth               | system:node:`<nodeName>` (see note) | system:nodes   |
-| controller-manager.conf | default-controller-manager | system:kube-controller-manager |                |
-| scheduler.conf          | default-scheduler          | system:kube-scheduler          |                |
+| 文件名                  | 凭据名称                   | 默认 CN                        | O (位于 Subject 中) |
+|-------------------------|----------------------------|--------------------------------|---------------------|
+| admin.conf              | default-admin              | kubernetes-admin               | system:masters      |
+| kubelet.conf            | default-auth               | system:node:`<nodeName>` （参阅注释） | system:nodes |
+| controller-manager.conf | default-controller-manager | system:kube-controller-manager |                     |
+| scheduler.conf          | default-scheduler          | system:kube-scheduler          |                     |
 
-{{< note >}}
 <!--
 The value of `<nodeName>` for `kubelet.conf` **must** match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the [Node Authorization](/docs/reference/access-authn-authz/node/).
 -->
-`kubelet.conf` 中 `<nodeName>` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。有关更多详细信息，请阅读[节点授权](/docs/reference/access-authn-authz/node/)。
+{{< note >}}
+`kubelet.conf` 中 `<nodeName>` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。
+有关更多详细信息，请阅读[节点授权](/zh/docs/reference/access-authn-authz/node/)。
 {{< /note >}}
 
 <!--
@@ -278,5 +285,3 @@ These files are used as follows:
 | controller-manager.conf | kube-controller-manager | 必需添加到 `manifests/kube-controller-manager.yaml` 清单中               |
 | scheduler.conf          | kube-scheduler          | 必需添加到 `manifests/kube-scheduler.yaml` 清单中                        |
 
-[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
-[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
diff --git a/content/zh/docs/setup/best-practices/cluster-large.md b/content/zh/docs/setup/best-practices/cluster-large.md
index a9237ebc48..4a27b867e1 100644
--- a/content/zh/docs/setup/best-practices/cluster-large.md
+++ b/content/zh/docs/setup/best-practices/cluster-large.md
@@ -42,7 +42,9 @@ A cluster is a set of nodes (physical or virtual machines) running Kubernetes ag
 <!--
 Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
 -->
-通常，集群中的节点数由特定于云平台的配置文件 `config-default.sh`（可以参考 [GCE 平台的 `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)）中的 `NUM_NODES` 参数控制。
+通常，集群中的节点数由特定于云平台的配置文件 `config-default.sh`
+（可以参考 [GCE 平台的 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)）
+中的 `NUM_NODES` 参数控制。
 
 <!--
 Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
@@ -175,7 +177,9 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
 <!--
 To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
 -->
-为了防止内存泄漏或 [集群插件](https://releases.k8s.io/{{<param "githubbranch" >}}/cluster/addons) 中的其它资源问题导致节点上所有可用资源被消耗，Kubernetes 限制了插件容器可以消耗的 CPU 和内存资源（请参阅 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files)）。
+为了防止内存泄漏或 [集群插件](https://releases.k8s.io/{{<param "githubbranch" >}}/cluster/addons)
+中的其它资源问题导致节点上所有可用资源被消耗，Kubernetes 限制了插件容器可以消耗的 CPU 和内存资源
+（请参阅 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files)）。
 
 例如：
 
@@ -211,33 +215,34 @@ To avoid running into cluster addon resource issues, when creating a cluster wit
   * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
 -->
 * 根据集群的规模，如果使用了以下插件，提高其内存和 CPU 上限（每个插件都有一个副本处理整个群集，因此内存和 CPU 使用率往往与集群的规模/负载成比例增长） ：
-  * [InfluxDB 和 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns、dnsmasq 和 sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+  * [InfluxDB 和 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  * [kubedns、dnsmasq 和 sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
 * 根据集群的规模，如果使用了以下插件，调整其副本数量（每个插件都有多个副本，增加副本数量有助于处理增加的负载，但是，由于每个副本的负载也略有增加，因此也请考虑增加 CPU/内存限制）：
-  * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
 * 根据集群的规模，如果使用了以下插件，限制其内存和 CPU 上限（这些插件在每个节点上都有一个副本，但是 CPU/内存使用量也会随集群负载/规模而略有增加）：
-  * [FluentD 和 ElasticSearch 插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [FluentD 和 GCP 插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  * [FluentD 和 ElasticSearch 插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+  * [FluentD 和 GCP 插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
 
 <!--
 Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
 and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
 out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
 -->
-Heapster 的资源限制与您集群的初始大小有关（请参阅 [#16185](http://issue.k8s.io/16185)
+Heapster 的资源限制与您集群的初始大小有关（请参阅 [#16185](https://issue.k8s.io/16185)
 和 [#22940](http://issue.k8s.io/22940)）。如果您发现 Heapster 资源不足，您应该调整堆内存请求的计算公式（有关详细信息，请参阅相关 PR）。
 
 <!--
 For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
 -->
-关于如何检测插件容器是否达到资源限制，参见 [计算资源的故障排除](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting) 部分。
+关于如何检测插件容器是否达到资源限制，参见
+[计算资源的故障排除](/zh/docs/concepts/configuration/manage-resources-containers/#troubleshooting) 部分。
 
 <!--
 In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
 We welcome PRs that implement those features.
 -->
-[未来](http://issue.k8s.io/13048)，我们期望根据集群规模大小来设置所有群集附加资源限制，并在集群扩缩容时动态调整它们。
+[未来](https://issue.k8s.io/13048)，我们期望根据集群规模大小来设置所有群集附加资源限制，并在集群扩缩容时动态调整它们。
 我们欢迎您来实现这些功能。
 
 <!--
diff --git a/content/zh/docs/setup/best-practices/multiple-zones.md b/content/zh/docs/setup/best-practices/multiple-zones.md
new file mode 100644
index 0000000000..e0c1523a79
--- /dev/null
+++ b/content/zh/docs/setup/best-practices/multiple-zones.md
@@ -0,0 +1,606 @@
+---
+title: 运行于多区环境
+weight: 10
+content_type: concept
+---
+<!--
+reviewers:
+- jlowdermilk
+- justinsb
+- quinton-hoole
+title: Running in multiple zones
+weight: 10
+content_type: concept
+-->
+
+<!-- overview -->
+
+<!--
+This page describes how to run a cluster in multiple zones.
+-->
+本页描述如何在多个区（Zone）中运行集群。
+
+<!-- body -->
+
+<!--
+## Introduction
+
+Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
+(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
+This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
+nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
+Full Cluster Federation allows combining separate
+Kubernetes clusters running in different regions or cloud providers
+(or on-premises data centers).  However, many
+users simply want to run a more available Kubernetes cluster in multiple zones
+of their single cloud provider, and this is what the multizone support in 1.2 allows
+(this previously went by the nickname "Ubernetes Lite").
+-->
+## 介绍
+
+Kubernetes 1.2 添加了跨多个失效区（Failure Zone）运行同一集群的能力
+（GCE 把它们称作“区（Zones）”，AWS 把它们称作“可用区（Availability Zones）”，
+这里我们用“区（Zones）”指代它们）。
+此能力是更广泛的集群联邦（Cluster Federation）特性的一个轻量级版本。
+集群联邦之前有一个昵称
+["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。
+完全的集群联邦可以将运行在多个区域（Region）或云供应商（或本地数据中心）的多个
+Kubernetes 集群组合起来。
+不过，很多用户仅仅是希望在同一云厂商平台的多个区域运行一个可用性更好的集群，
+而这恰恰是 1.2 引入的多区支持所带来的特性
+（此特性之前有一个昵称 “Ubernetes Lite”）。
+
+<!--
+Multizone support is deliberately limited: a single Kubernetes cluster can run
+in multiple zones, but only within the same region (and cloud provider).  Only
+GCE and AWS are currently supported automatically (though it is easy to
+add similar support for other clouds or even bare metal, by simply arranging
+for the appropriate labels to be added to nodes and volumes).
+-->
+多区支持有意实现的有局限性：可以在跨多个区域运行同一 Kubernetes 集群，但只能
+在同一区域（Region）和云厂商平台。目前仅自动支持 GCE 和 AWS，尽管为其他云平台
+或裸金属平台添加支持页相对容易，只需要确保节点和卷上添加合适的标签即可。
+
+<!--
+## Functionality
+
+When nodes are started, the kubelet automatically adds labels to them with
+zone information.
+-->
+## 功能
+
+节点启动时，`kubelet` 自动向其上添加区信息标签。
+
+<!--
+Kubernetes will automatically spread the pods in a replication controller
+or service across nodes in a single-zone cluster (to reduce the impact of
+failures.)  With multiple-zone clusters, this spreading behavior is
+extended across zones (to reduce the impact of zone failures.)  (This is
+achieved via `SelectorSpreadPriority`).  This is a best-effort
+placement, and so if the zones in your cluster are heterogeneous
+(e.g. different numbers of nodes, different types of nodes, or
+different pod resource requirements), this might prevent perfectly
+even spreading of your pods across zones. If desired, you can use
+homogeneous zones (same number and types of nodes) to reduce the
+probability of unequal spreading.
+-->
+在单区（Single-Zone）集群中， Kubernetes 会自动将副本控制器或服务中的 Pod
+分布到不同节点，以降低节点失效的影响。
+在多区集群中，这一分布负载的行为被扩展到跨区分布，以降低区失效的影响，
+跨区分布的能力是通过 `SelectorSpreadPriority` 实现的。此放置策略亦仅仅是
+尽力而为，所以如果你的集群所跨区是异质的（例如，节点个数不同、节点类型
+不同或者 Pod 资源需求不同），放置策略都可能无法完美地跨区完成 Pod 的
+均衡分布。如果需要，你可以使用同质区（节点个数和类型相同）以降低不均衡
+分布的可能性。
+
+<!--
+When persistent volumes are created, the `PersistentVolumeLabel`
+admission controller automatically adds zone labels to them.  The scheduler (via the
+`VolumeZonePredicate` predicate) will then ensure that pods that claim a
+given volume are only placed into the same zone as that volume, as volumes
+cannot be attached across zones.
+-->
+持久卷被创建时，`PersistentVolumeLabel` 准入控制器会自动为其添加区标签。
+调度器使用 `VolumeZonePredicate` 断言确保申领某给定卷的 Pod 只会被放到
+该卷所在的区。这是因为卷不可以跨区挂载。
+
+<!--
+## Limitations
+
+There are some important limitations of the multizone support:
+
+* We assume that the different zones are located close to each other in the
+network, so we don't perform any zone-aware routing.  In particular, traffic
+that goes via services might cross zones (even if some pods backing that service
+exist in the same zone as the client), and this may incur additional latency and cost.
+-->
+## 局限性
+
+多区支持有一些很重要的局限性：
+
+* 我们假定不同的区之间在网络上彼此距离很近，所以我们不执行可感知区的路由。
+  尤其是，即使某些负责提供该服务的 Pod  与客户端位于同一区，通过服务末端
+  进入的流量可能会跨区，因而会导致一些额外的延迟和开销。
+
+<!--
+* Volume zone-affinity will only work with a `PersistentVolume`, and will not
+work if you directly specify an EBS volume in the pod spec (for example).
+
+* Clusters cannot span clouds or regions (this functionality will require full
+federation support).
+-->
+* 卷与区之间的亲和性仅适用于 PV 持久卷。例如，如果你直接在 Pod 规约中指定某 EBS
+  卷，这种亲和性支持就无法工作。
+
+* 集群无法跨多个云平台或者地理区域运行。这类功能需要完整的联邦特性支持。
+
+<!--
+* Although your nodes are in multiple zones, kube-up currently builds
+a single master node by default.  While services are highly
+available and can tolerate the loss of a zone, the control plane is
+located in a single zone.  Users that want a highly available control
+plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
+-->
+* 尽管你的节点位于多个区中，`kube-up` 脚本目前默认只能构造一个主控节点。
+  尽管服务是高可用的，能够忍受失去某个区的问题，控制面位于某一个区中。
+  希望运行高可用控制面的用户应该遵照
+  [高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
+  中的指令构建。
+
+<!--
+### Volume limitations
+
+The following limitations are addressed with
+[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
+
+* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
+  pod affinity or anti-affinity policies.
+-->
+### 卷局限性
+
+以下局限性通过
+[拓扑感知的卷绑定](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)解决：
+
+* 使用动态卷供应时，StatefulSet 卷的跨区分布目前与 Pod
+  亲和性和反亲和性策略不兼容。
+
+<!--
+* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
+  may not provide a uniform distribution of storage across zones.
+
+* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
+  needs to be configured for a specific single zone, or the PVs need to be
+  statically provisioned in a specific zone. Another workaround is to use a
+  StatefulSet, which will ensure that all the volumes for a replica are
+  provisioned in the same zone.
+-->
+* 如果 StatefulSet 的名字中包含连字符（"-"），卷的跨区分布可能无法实现存储的
+  跨区同一分布。
+
+* 当在一个 Deployment 或 Pod 规约中指定多个 PVC 申领时，则需要为某特定区域
+  配置 StorageClass，或者在某一特定区域中需要静态供应 PV 卷。
+  另一种解决方案是使用 StatefulSet，确保给定副本的所有卷都从同一区中供应。
+
+<!--
+## Walkthrough
+
+We're now going to walk through setting up and using a multi-zone
+cluster on both GCE & AWS.  To do so, you bring up a full cluster
+(specifying `MULTIZONE=true`), and then you add nodes in additional zones
+by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
+-->
+## 演练
+
+我们现在准备对在 GCE 和 AWS 上配置和使用多区集群进行演练。为了完成此演练，
+你需要设置 `MULTIZONE=true` 来启动一个完整的集群，之后指定
+`KUBE_USE_EXISTING_MASTER=true` 并再次运行 `kube-up` 添加其他区中的节点。
+
+<!--
+### Bringing up your cluster
+
+Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
+-->
+### 建立集群
+
+和往常一样创建集群，不过需要设置 MULTIZONE，以便告诉集群需要管理多个区。
+这里我们在 `us-central1-a` 创建节点。
+
+GCE:
+
+```shell
+curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
+```
+
+AWS:
+
+```shell
+curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
+```
+
+<!--
+This step brings up a cluster as normal, still running in a single zone
+(but `MULTIZONE=true` has enabled multi-zone capabilities).
+-->
+这一步骤和往常一样启动一个集群，不过尽管 `MULTIZONE=true`
+标志已经启用了多区功能特性支持，集群仍然运行在一个区内。
+
+<!--
+### Nodes are labeled
+
+View the nodes; you can see that they are labeled with zone information.
+They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far.  The
+labels are `topology.kubernetes.io/region` for the region,
+and `topology.kubernetes.io/zone` for the zone:
+-->
+### 节点已被打标签
+
+查看节点，你会看到节点上已经有了区信息标签。
+目前这些节点都在 `us-central1-a` (GCE) 或 `us-west-2a` (AWS)。
+对于区域（Region），标签为 `topology.kubernetes.io/region`，
+对于区（Zone），标签为 `topology.kubernetes.io/zone`：
+
+```shell
+kubectl get nodes --show-labels
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
+kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+```
+<!--
+### Add more nodes in a second zone
+
+Let's add another set of nodes to the existing cluster, reusing the
+existing master, running in a different zone (us-central1-b or us-west-2b).
+We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
+kube-up will not create a new master, but will reuse one that was previously
+created instead.
+-->
+### 添加第二个区中的节点
+
+让我们向现有集群中添加另外一组节点，复用现有的主控节点，但运行在不同的区
+（`us-central1-b` 或 `us-west-2b`）。
+我们再次运行 `kube-up`，不过设置 `KUBE_USE_EXISTING_MASTER=true`。
+`kube-up` 不会创建新的主控节点，而会复用之前创建的主控节点。
+
+GCE:
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
+```
+
+<!--
+On AWS we also need to specify the network CIDR for the additional
+subnet, along with the master internal IP address:
+-->
+在 AWS 上，我们还需要为额外的子网指定网络 CIDR，以及主控节点的内部 IP 地址：
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
+```
+
+<!--
+View the nodes again; 3 more nodes should have launched and be tagged
+in us-central1-b:
+-->
+再次查看节点，你会看到新启动了三个节点并且其标签表明运行在 `us-central1-b` 区：
+
+```shell
+kubectl get nodes --show-labels
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
+kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
+kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
+```
+
+<!--
+### Volume affinity
+
+Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
+-->
+### 卷亲和性
+
+通过动态卷供应创建一个卷（只有 PV 持久卷支持区亲和性）：
+
+```bash
+kubectl apply -f - <<EOF
+{
+  "apiVersion": "v1",
+  "kind": "PersistentVolumeClaim",
+  "metadata": {
+    "name": "claim1",
+    "annotations": {
+        "volume.alpha.kubernetes.io/storage-class": "foo"
+    }
+  },
+  "spec": {
+    "accessModes": [
+      "ReadWriteOnce"
+    ],
+    "resources": {
+      "requests": {
+        "storage": "5Gi"
+      }
+    }
+  }
+}
+EOF
+```
+
+<!--
+For version 1.3+ Kubernetes will distribute dynamic PV claims across
+the configured zones. For version 1.2, dynamic persistent volumes were
+always created in the zone of the cluster master
+(here us-central1-a / us-west-2a); that issue
+([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
+was addressed in 1.3+.
+-->
+{{< note >}}
+Kubernetes 1.3 及以上版本会将动态 PV 申领散布到所配置的各个区。
+在 1.2 版本中，动态持久卷总是在集群主控节点所在的区
+（这里的 `us-central1-a` 或 `us-west-2a`），
+对应的 Issue ([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
+在 1.3 及以上版本中已经解决。
+{{< /note >}}
+
+<!--
+Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
+-->
+现在我们来验证 Kubernetes 自动为 PV 打上了所在区或区域的标签：
+
+```shell
+kubectl get pv --show-labels
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
+pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a
+```
+
+<!--
+So now we will create a pod that uses the persistent volume claim.
+Because GCE PDs / AWS EBS volumes cannot be attached across zones,
+this means that this pod can only be created in the same zone as the volume:
+-->
+现在我们将创建一个使用 PVC 申领的 Pod。
+由于 GCE PD 或 AWS EBS 卷都不能跨区挂载，这意味着 Pod 只能创建在卷所在的区：
+
+```yaml
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+    - name: myfrontend
+      image: nginx
+      volumeMounts:
+      - mountPath: "/var/www/html"
+        name: mypd
+  volumes:
+    - name: mypd
+      persistentVolumeClaim:
+        claimName: claim1
+EOF
+```
+
+<!--
+Note that the pod was automatically created in the same zone as the volume, as
+cross-zone attachments are not generally permitted by cloud providers:
+-->
+注意 Pod 自动创建在卷所在的区，因为云平台提供商一般不允许跨区挂接存储卷。
+
+```shell
+kubectl describe pod mypod | grep Node
+```
+
+```
+Node:        kubernetes-minion-9vlv/10.240.0.5
+```
+
+<!--
+And check node labels:
+-->
+检查节点标签：
+
+```shell
+kubectl get node kubernetes-minion-9vlv --show-labels
+```
+
+```
+NAME                     STATUS    AGE    VERSION          LABELS
+kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+```
+
+<!--
+### Pods are spread across zones
+
+Pods in a replication controller or service are automatically spread
+across zones.  First, let's launch more nodes in a third zone:
+-->
+### Pod 跨区分布
+
+同一副本控制器或服务的多个 Pod 会自动完成跨区分布。
+首先，我们现在第三个区启动一些节点：
+
+GCE:
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
+```
+
+AWS:
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
+```
+
+<!--
+Verify that you now have nodes in 3 zones:
+-->
+验证你现在有来自三个区的节点：
+
+```shell
+kubectl get nodes --show-labels
+```
+
+<!--
+Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
+-->
+创建 `guestbook-go` 示例，其中包含副本个数为 3 的 RC，运行一个简单的 Web 应用：
+
+```shell
+find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
+```
+
+<!--
+The pods should be spread across all 3 zones:
+-->
+Pod 应该跨三个区分布：
+
+```shell
+kubectl describe pod -l app=guestbook | grep Node
+```
+
+```
+Node:        kubernetes-minion-9vlv/10.240.0.5
+Node:        kubernetes-minion-281d/10.240.0.8
+Node:        kubernetes-minion-olsh/10.240.0.11
+```
+
+```shell
+kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
+```
+
+```
+NAME                     STATUS    ROLES    AGE    VERSION          LABELS
+kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
+```
+
+<!--
+Load-balancers span all zones in a cluster; the guestbook-go example
+includes an example load-balanced service:
+-->
+负载均衡器也会跨集群中的所有区；`guestbook-go` 示例中包含了一个负载均衡
+服务的例子：
+
+```shell
+kubectl describe service guestbook | grep LoadBalancer.Ingress
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+LoadBalancer Ingress:   130.211.126.21
+```
+
+<!--
+Set the above IP:
+-->
+设置上面的 IP 地址：
+
+```shell
+export IP=130.211.126.21
+```
+
+<!--
+Explore with curl via IP:
+-->
+使用 curl 访问该 IP：
+
+
+```shell
+curl -s http://${IP}:3000/env | grep HOSTNAME
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+  "HOSTNAME": "guestbook-44sep",
+```
+
+<!--
+Again, explore multiple times:
+-->
+如果多次尝试该命令：
+
+```shell
+(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```shell
+  "HOSTNAME": "guestbook-44sep",
+  "HOSTNAME": "guestbook-hum5n",
+  "HOSTNAME": "guestbook-ppm40",
+```
+
+<!--
+The load balancer correctly targets all the pods, even though they are in multiple zones.
+-->
+负载均衡器正确地选择不同的 Pod，即使它们跨了多个区。
+
+<!--
+### Shutting down the cluster
+
+When you're done, clean up:
+-->
+### 停止集群
+
+当完成以上工作之后，清理任务现场：
+
+GCE:
+
+```shell
+KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
+```
+
+AWS:
+
+```shell
+KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
+```
+
+
diff --git a/content/zh/docs/setup/best-practices/node-conformance.md b/content/zh/docs/setup/best-practices/node-conformance.md
index bef833cf6c..9a5f72fe24 100644
--- a/content/zh/docs/setup/best-practices/node-conformance.md
+++ b/content/zh/docs/setup/best-practices/node-conformance.md
@@ -31,21 +31,6 @@ The test validates whether the node meets the minimum requirements for Kubernete
 -->
 该测试主要检测节点是否满足 Kubernetes 的最低要求，通过检测的节点有资格加入 Kubernetes 集群。
 
-<!--
-## Limitations
--->
-## 限制
-
-<!--
-In Kubernetes version 1.5, node conformance test has the following limitations:
--->
-在 Kubernetes 1.5 版中，节点一致性测试具有以下限制：
-
-<!--
-* Node conformance test only supports Docker as the container runtime.
-* -->
-* 节点一致性测试只支持 Docker 作为容器运行时环境。
-
 <!--
 ## Node Prerequisite
 -->
diff --git a/content/zh/docs/setup/independent/create-cluster-kubeadm.md b/content/zh/docs/setup/independent/create-cluster-kubeadm.md
deleted file mode 100644
index 2f80c85c2d..0000000000
--- a/content/zh/docs/setup/independent/create-cluster-kubeadm.md
+++ /dev/null
@@ -1,1113 +0,0 @@
----
-title: 使用 kubeadm 创建一个单主集群
-content_type: task
-weight: 30
----
-
-<!-- ---
-reviewers:
-- sig-cluster-lifecycle
-title: Creating a single master cluster with kubeadm
-content_type: task
-weight: 30
---- -->
-
-
-<!-- overview -->
-<!--
-<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices.  With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
-lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).  -->
-
-<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">**kubeadm** 能帮助您建立一个小型的符合最佳实践的 Kubernetes 集群。通过使用 kubeadm, 您的集群会符合 [Kubernetes 合规性测试](https://kubernetes.io/blog/2017/10/software-conformance-certification)的要求. Kubeadm 也支持其他的集群生命周期操作，比如升级、降级和管理[启动引导令牌](/docs/reference/access-authn-authz/bootstrap-tokens/)。
-
-<!-- Because you can install kubeadm on various types of machine (e.g. laptop, server,
-Raspberry Pi, etc.), it's well suited for integration with provisioning systems
-such as Terraform or Ansible. -->
-
-因为您可以在不同类型的机器（比如笔记本、服务器和树莓派等）上安装 kubeadm，因此它非常适合与 Terraform 或 Ansible 这类自动化管理系统集成。
-
-<!-- kubeadm's simplicity means it can serve a wide range of use cases:
-
-- New users can start with kubeadm to try Kubernetes out for the first time.
-- Users familiar with Kubernetes can spin up clusters with kubeadm and test their applications.
-- Larger projects can include kubeadm as a building block in a more complex system that can also include other installer tools. -->
-
-kubeadm 的简单便捷为大家带来了广泛的用户案例：
-
-- 新用户可以从 kubeadm 开始来试用 Kubernetes。
-- 熟悉 Kubernetes 的用户可以使用 kubeadm 快速搭建集群并测试他们的应用。
-- 大型的项目可以将 kubeadm 和其他的安装工具一起形成一个比较复杂的系统。
-
-<!-- kubeadm is designed to be a simple way for new users to start trying
-Kubernetes out, possibly for the first time, a way for existing users to
-test their application on and stitch together a cluster easily, and also to be
-a building block in other ecosystem and/or installer tool with a larger
-scope. -->
-
-kubeadm 的设计初衷是为新用户提供一种便捷的方式来首次试用 Kubernetes，
-同时也方便老用户搭建集群测试他们的应用。
-此外 kubeadm 也可以跟其它生态系统与/或安装工具集成到一起，提供更强大的功能。
-
-<!-- You can install _kubeadm_ very easily on operating systems that support
-installing deb or rpm packages. The responsible SIG for kubeadm,
-[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle), provides these packages pre-built for you,
-but you may also build them from source for other OSes. -->
-
-您可以很方便地在支持 rpm 或 deb 软件包的操作系统上安装 _kubeadm_。对应 kubeadm 的 SIG，
-[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle)，
-提供了预编译的这类安装包，当然您也可以自己基于源码为其它操作系统来构造安装包。
-
-<!-- ### kubeadm Maturity
-
-| Area                      | Maturity Level |
-|---------------------------|--------------- |
-| Command line UX           | beta           |
-| Implementation            | beta           |
-| Config file API           | alpha          |
-| Self-hosting              | alpha          |
-| kubeadm alpha subcommands | alpha          |
-| CoreDNS                   | GA             |
-| DynamicKubeletConfig      | alpha          | -->
-
-### kubeadm 成熟程度
-
-| 功能                       | 成熟程度        |
-|---------------------------|--------------- |
-| 命令行用户体验               | beta           |
-| 功能实现                    | beta           |
-| 配置文件 API                | alpha          |
-| 自托管                     | alpha          |
-| kubeadm alpha 子命令       | alpha          |
-| CoreDNS                   | GA             |
-| 动态 Kubelet 配置          | alpha          |
-
-<!-- kubeadm's overall feature state is **Beta** and will soon be graduated to
-**General Availability (GA)** during 2018. Some sub-features, like self-hosting
-or the configuration file API are still under active development. The
-implementation of creating the cluster may change slightly as the tool evolves,
-but the overall implementation should be pretty stable. Any commands under
-`kubeadm alpha` are by definition, supported on an alpha level. -->
-
-kubeadm 的整体功能目前还是 **Beta** 状态，然而很快在 2018 年就会转换成**正式发布 (GA)** 状态。
-一些子功能，比如自托管或者配置文件 API 还在开发过程当中。
-随着工具的发展，创建集群的方法可能会有所变化，但是整体部署方案还是比较稳定的。
-在 `kubeadm alpha` 下面的任何命令都只是 alpha 状态，目前只提供初期阶段的服务。
-
-<!-- ### Support timeframes
-
-Kubernetes releases are generally supported for nine months, and during that
-period a patch release may be issued from the release branch if a severe bug or
-security issue is found. Here are the latest Kubernetes releases and the support
-timeframe; which also applies to `kubeadm`.
-
-| Kubernetes version | Release month  | End-of-life-month |
-|--------------------|----------------|-------------------|
-| v1.6.x             | March 2017     | December 2017     |
-| v1.7.x             | June 2017      | March 2018        |
-| v1.8.x             | September 2017 | June 2018         |
-| v1.9.x             | December 2017  | September 2018    |
-| v1.10.x            | March 2018     | December 2018     |
-| v1.11.x            | June 2018      | March 2019        |
-| v1.12.x            | September 2018 | June 2019         |
--->
-
-### 维护周期
-
-Kubernetes 发布的版本通常只维护支持九个月，在维护周期内，如果发现有比较重大的 bug 或者安全问题的话，
-可能会发布一个补丁版本。下面是 Kubernetes 的发布和维护周期，同时也适用于 `kubeadm`。
-
-| Kubernetes 版本     | 发行月份        | 终止维护月份        |
-|--------------------|----------------|-------------------|
-| v1.6.x             | 2017 年 3 月    | 2017 年 12 月     |
-| v1.7.x             | 2017 年 6 月    | 2018 年 3 月      |
-| v1.8.x             | 2017 年 9 月    | 2018 年 6 月      |
-| v1.9.x             | 2017 年 12 月   |  2018 年 9 月     |
-| v1.10.x            | 2018 年 3 月    | 2018 年 12 月     |
-| v1.11.x            | 2018 年 6 月    | 2019 年 3 月      |
-| v1.12.x            | 2018 年 9 月    | 2019 年 6 月      |
-
-
-
-## {{% heading "prerequisites" %}}
-
-<!--
-
-- One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
-- 2 GB or more of RAM per machine. Any less leaves little room for your
-   apps.
-- 2 CPUs or more on the master
-- Full network connectivity among all machines in the cluster. A public or
-   private network is fine.
- -->
-
-- 一个或者多个兼容 deb 或者 rpm 软件包的操作系统，比如 Ubuntu 或者 CentOS
-- 每台机器 2 GB 以上的内存，内存不足时应用会受限制
-- 主节点上 2 CPU 以上
-- 集群里所有的机器有完全的网络连接，公有网络或者私有网络都可以
-
-
-<!-- steps -->
-<!--
-## Objectives
-
-* Install a single master Kubernetes cluster or [high availability cluster](https://kubernetes.io/docs/setup/independent/high-availability/)
-* Install a Pod network on the cluster so that your Pods can
-  talk to each other
--->
-
-## 目标
-
-* 搭建一个单主 Kubernetes 集群或者[高可用集群](/docs/setup/independent/high-availability/)
-* 在集群上安装 Pod 网络组件以便 Pod 之间可以互相通信
-
-<!-- ## Instructions
-
-### Installing kubeadm on your hosts
-
-See ["Installing kubeadm"](/docs/setup/independent/install-kubeadm/).
-
-{{< note >}}
-**Note:** If you have already installed kubeadm, run `apt-get update &&
-apt-get upgrade` or `yum update` to get the latest version of kubeadm.
-
-When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
-kubeadm to tell it what to do. This crashloop is expected and normal.
-After you initialize your master, the kubelet runs normally.
-{{< /note >}}-->
-
-## 步骤
-
-### 在您的机器上安装 kubeadm
-
-请查阅[安装 kubeadm](/docs/setup/independent/install-kubeadm/)。
-
-{{< note >}}
-如果您的机器已经安装了 kubeadm, 请运行 `apt-get update &&
-apt-get upgrade` 或者 `yum update` 来升级至最新版本的 kubeadm.
-
-升级过程中，kubelet 会每隔几秒钟重启并陷入了不断循环等待 kubeadm 发布指令的状态。
-这个死循环的过程是正常的，当升级并初始化完成您的主节点之后，kubelet 才会正常运行。
-{{< /note >}}
-
-<!-- ### Initializing your master
-
-The master is the machine where the control plane components run, including
-etcd (the cluster database) and the API server (which the kubectl CLI
-communicates with). -->
-
-### 初始化您的主节点
-
-主节点是集群里运行控制面的机器，包括 etcd (集群的数据库)和 API 服务（kubectl CLI 与之交互）。
-
-<!-- 1. Choose a Pod network add-on, and verify whether it requires any arguments to
-be passed to kubeadm initialization. Depending on which
-third-party provider you choose, you might need to set the `--Pod-network-cidr` to
-a provider-specific value. See [Installing a Pod network add-on](#Pod-network).
-1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
-with the default gateway to advertise the master's IP. To use a different
-network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
-to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
-must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
-1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
-connectivity to gcr.io registries.
-
-Now run:
-
-```bash
-kubeadm init <args>
-``` -->
-
-
-1. 选择一个 Pod 网络插件，并检查是否在 kubeadm 初始化过程中需要传入什么参数。这个取决于
-您选择的网络插件，您可能需要设置 `--Pod-network-cidr` 来指定网络驱动的 CIDR。请参阅[安装网络插件](#Pod-network)。
-1. (可选) 除非特别指定，kubeadm 会使用默认网关所在的网络接口广播其主节点的 IP 地址。若需使用其他网络接口，请
-给 `kubeadm init` 设置 `--apiserver-advertise-address=<ip-address>` 参数。如果需要部署
-IPv6 的集群，则需要指定一个 IPv6 地址，比如 `--apiserver-advertise-address=fd00::101`。
-1. (可选) 在运行 `kubeadm init` 之前请先执行 `kubeadm config images pull` 来测试与 gcr.io 的连接。
-
-现在运行:
-
-```bash
-kubeadm init <args>
-```
-
-<!-- ### More information
-
-For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
-
-For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
-
-To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/admin/kubeadm#custom-args). -->
-
-### 补充信息
-
-想了解更多关于 `kubeadm init` 的参数, 请参阅[kubeadm 参考指南](/docs/reference/setup-tools/kubeadm/kubeadm/)。
-
-想了解完整的配置选项，请参阅[配置文件](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)。
-
-如果想定制控制面组件，包括为活跃性探测和 etcd 服务提供 IPv6 支持以及为各组件提供额外参数，请参阅[定制参数](/docs/admin/kubeadm#custom-args)。
-
-<!-- To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
-
-If you join a node with a different architecture to your cluster, create a separate
-Deployment or DaemonSet for `kube-proxy` and `kube-dns` on the node. This is because the Docker images for these
-components do not currently support multi-architecture.
-
-`kubeadm init` first runs a series of prechecks to ensure that the machine
-is ready to run Kubernetes. These prechecks expose warnings and exit on errors. `kubeadm init`
-then downloads and installs the cluster control plane components. This may take several minutes.
-The output should look like: -->
-
-如果需要再次运行 `kubeadm init`，您必须先[卸载集群](#tear-down)。
-
-如果您需要将不同架构的节点加入您的集群，请单独在这类节点上为 `kube-proxy` 和 `kube-dns` 创建 Deployment 或 DaemonSet。
-这是因为这些组件的 Docker 镜像并不支持多架构。
-
-`kubeadm init` 首先会执行一系列的运行前检查来确保机器满足运行 Kubernetes 的条件。
-这些检查会抛出警告并在发现错误的时候终止整个初始化进程。
-然后 `kubeadm init` 会下载并安装集群的控制面组件，这可能会花费几分钟时间，其输出如下所示：
-
-```none
-[init] Using Kubernetes version: vX.Y.Z
-[preflight] Running pre-flight checks
-[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
-[certificates] Generated ca certificate and key.
-[certificates] Generated apiserver certificate and key.
-[certificates] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
-[certificates] Generated apiserver-kubelet-client certificate and key.
-[certificates] Generated sa key and public key.
-[certificates] Generated front-proxy-ca certificate and key.
-[certificates] Generated front-proxy-client certificate and key.
-[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
-[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
-[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
-[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
-[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
-[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
-[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
-[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
-[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
-[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
-[init] This often takes around a minute; or longer if the control plane images have to be pulled.
-[apiclient] All control plane components are healthy after 39.511972 seconds
-[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
-[markmaster] Will mark node master as master by adding a label and a taint
-[markmaster] Master master tainted and labelled with key/value: node-role.kubernetes.io/master=""
-[bootstraptoken] Using token: <token>
-[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
-[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
-[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
-[addons] Applied essential addon: CoreDNS
-[addons] Applied essential addon: kube-proxy
-
-Your Kubernetes master has initialized successfully!
-
-To start using your cluster, you need to run (as a regular user):
-
-  mkdir -p $HOME/.kube
-  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
-  sudo chown $(id -u):$(id -g) $HOME/.kube/config
-
-You should now deploy a Pod network to the cluster.
-Run "kubectl apply -f [Podnetwork].yaml" with one of the addon options listed at:
-  http://kubernetes.io/docs/admin/addons/
-
-You can now join any number of machines by running the following on each node
-as root:
-
-  kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
-```
-
-
-<!-- To make kubectl work for your non-root user, run these commands, which are
-also part of the `kubeadm init` output:
-
-```bash
-mkdir -p $HOME/.kube
-sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
-sudo chown $(id -u):$(id -g) $HOME/.kube/config
-``` -->
-
-如果需要让普通用户可以运行 kubectl，请运行如下命令，其实这也是 `kubeadm init` 输出的一部分：
-
-```bash
-mkdir -p $HOME/.kube
-sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
-sudo chown $(id -u):$(id -g) $HOME/.kube/config
-```
-
-<!-- Alternatively, if you are the `root` user, you can run:
-
-```bash
-export KUBECONFIG=/etc/kubernetes/admin.conf
-``` -->
-
-或者，如果您是 `root` 用户，则可以运行：
-
-```bash
-export KUBECONFIG=/etc/kubernetes/admin.conf
-```
-
-<!-- Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
-need this command to [join nodes to your cluster](#join-nodes).
-
-The token is used for mutual authentication between the master and the joining
-nodes.  The token included here is secret. Keep it safe, because anyone with this
-token can add authenticated nodes to your cluster. These tokens can be listed,
-created, and deleted with the `kubeadm token` command. See the
-[kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm-token/). -->
-
-请备份好 `kubeadm init` 输出中的 `kubeadm join` 命令，因为您会需要这个命令来[给集群添加节点](#join-nodes)。
-
-令牌是主节点和新添加的节点之间进行相互身份验证的，因此请确保其安全。任何人只要知道了这些令牌，就可以随便给您的集群添加节点。
-可以使用 `kubeadm token` 命令来列出、创建和删除这类令牌。
-请参阅[kubeadm 参考指南](/docs/reference/setup-tools/kubeadm/kubeadm-token/)。
-
-<!-- ### Installing a Pod network add-on {#Pod-network}
-
-{{< caution >}}
-**Caution:** This section contains important information about installation and deployment order. Read it carefully before proceeding.
-{{< /caution >}}
-
-You must install a Pod network add-on so that your Pods can communicate with
-each other. -->
-
-### 安装 Pod 网络插件 {#Pod-network}
-
-{{< caution >}}
-**注意:** 这一节包含了安装和部署顺序的重要信息，执行之前请仔细阅读。
-{{< /caution >}}
-
-您必须先安装 Pod 网络插件，以便您的 Pod 可以互相通信。
-
-<!-- **The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed.
-kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
-
-Several projects provide Kubernetes Pod networks using CNI, some of which also
-support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
-- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
-- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9. -->
-
-**网络必须在部署任何应用之前部署好。此外，在网络安装之前 CoreDNS 是不会启用的。
-kubeadm 只支持基于容器网络接口（CNI）的网络而且不支持 kubenet 。**
-
-有一些项目为 Kubernetes 提供使用 CNI 的 Pod 网络，其中一些也支持[网络策略](/docs/concepts/services-networking/networkpolicies/).
-请参阅[插件页面](/docs/concepts/cluster-administration/addons/)了解可用网络插件的完整列表。
-- [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0) 也提供了 IPv6 的支持。
-- [CNI 网桥](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) 和 [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) 是 Kubernetes 1.9 版本里提供的唯一支持 IPv6 的网络插件。
-
-<!-- Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/docs/reference/access-authn-authz/rbac/).
-Make sure that your network manifest supports RBAC.
-
-You can install a Pod network add-on with the following command:
-
-```bash
-kubectl apply -f <add-on.yaml>
-``` -->
-
-注意 kubeadm 默认会创建一个比较安全的集群并强制启用[RBAC](/docs/reference/access-authn-authz/rbac/)。
-请确保您的网络方案支持 RBAC。
-
-您可以使用下列命令安装网络插件：
-
-```bash
-kubectl apply -f <add-on.yaml>
-```
-
-<!-- You can install only one Pod network per cluster.
-
-{{< tabs name="tabs-Pod-install" >}}
-{{% tab name="Choose one..." %}}
-Please select one of the tabs to see installation instructions for the respective third-party Pod Network Provider.
-{{% /tab %}} -->
-
-您仅可以给任何一个集群安装一个网络插件。
-
-{{< tabs name="tabs-Pod-install" >}}
-{{% tab name="Choose one..." %}}
-请选择一个选项来查看对应的第三方网络插件驱动的安装向导。
-{{% /tab %}}
-
-<!--
-For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
-
-For Calico to work correctly, you need to pass `--Pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64` only.
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
-```
--->
-
-{{% tab name="Calico" %}}
-想了解关于 Calico 的使用的更多信息, 请参阅[Kubernetes上的Calico快速实践](https://docs.projectcalico.org/latest/getting-started/kubernetes/)、[安装 Calico 实现网络策略](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico)和其他相关资源。
-
-为了 Calico 可以正确工作，您需要给 `kubeadm init` 传递 `--Pod-network-cidr=192.168.0.0/16` 这样的选项，
-或者根据您的网络方案更新 `calico.yml` 。注意 Calico 只适用于 `amd64` 架构。
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-<!--
-Canal uses Calico for policy and Flannel for networking. Refer to the Calico documentation for the [official getting started guide](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
-
-For Canal to work correctly, `--Pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. Note that Canal works on `amd64` only.
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
-```
--->
-
-{{% tab name="Canal" %}}
-Canal 使用 Calico 提供的网络策略和 Flannel 提供的网络功能。请查阅 Calico 的官方文档
-[入门指引](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel)。
-
-为了 Canal 可以正确运行，`kubeadm init` 运行时需要设置`--Pod-network-cidr=10.244.0.0/16`，同时注意它只适用于 `amd64` 架构。
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
-```
-
-{{% /tab %}}
-<!--
-For more information about using Cilium with Kubernetes, see [Quickstart for Cilium on Kubernetes](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) and [Kubernetes Install guide for Cilium](http://docs.cilium.io/en/v1.2/kubernetes/install/).
-
-Passing `--Pod-network-cidr` option to `kubeadm init` is not required, but highly recommended.
-
-These commands will deploy Cilium with its own etcd managed by etcd operator.
-
-```shell
-# Download required manifests from Cilium repository
-wget https://github.com/cilium/cilium/archive/v1.2.0.zip
-unzip v1.2.0.zip
-cd cilium-1.2.0/examples/kubernetes/addons/etcd-operator
-
-# Generate and deploy etcd certificates
-export CLUSTER_DOMAIN=$(kubectl get ConfigMap --namespace kube-system coredns -o yaml | awk '/kubernetes/ {print $2}')
-tls/certs/gen-cert.sh $CLUSTER_DOMAIN
-tls/deploy-certs.sh
-
-# Label kube-dns with fixed identity label
-kubectl label -n kube-system Pod $(kubectl -n kube-system get Pods -l k8s-app=kube-dns -o jsonpath='{range .items[]}{.metadata.name}{" "}{end}') io.cilium.fixed-identity=kube-dns
-
-kubectl create -f ./
-
-# Wait several minutes for Cilium, coredns and etcd Pods to converge to a working state
-```
--->
-{{% tab name="Cilium" %}}
-想了解 Kubernetes 上使用 Cilium 的更多相关信息，请查参阅[Kubernetes 上 Cilium 的快速指南](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) 和 [Kubernetes 上 Cilium 的安装向导](http://docs.cilium.io/en/v1.2/kubernetes/install/)。
-
-尽管这里并不要求给 `kubeadm init` 设置 `--Pod-network-cidr` 参数，但是这是一个高度推荐操作的步骤。
-
-这些命令会部署 Cilium 和它自己受 etcd 操作者管理的 etcd。
-
-```shell
-# 从 Cilium 库下载所需清单文件
-wget https://github.com/cilium/cilium/archive/v1.2.0.zip
-unzip v1.2.0.zip
-cd cilium-1.2.0/examples/kubernetes/addons/etcd-operator
-
-# 生成并部署 etcd 证书
-export CLUSTER_DOMAIN=$(kubectl get ConfigMap --namespace kube-system coredns -o yaml | awk '/kubernetes/ {print $2}')
-tls/certs/gen-cert.sh $CLUSTER_DOMAIN
-tls/deploy-certs.sh
-
-# 为 kube-dns 设置固定的标识标签
-kubectl label -n kube-system Pod $(kubectl -n kube-system get Pods -l k8s-app=kube-dns -o jsonpath='{range .items[]}{.metadata.name}{" "}{end}') io.cilium.fixed-identity=kube-dns
-
-kubectl create -f ./
-
-# 等待几分钟，Cilium、coredns 和 etcd 的 Pods 会收敛到工作状态
-```
-
-{{% /tab %}}
-
-<!--
-
-For `flannel` to work correctly, you must pass `--Pod-network-cidr=10.244.0.0/16` to `kubeadm init`.
-
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
-to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
-please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-
-Note that `flannel` works on `amd64`, `arm`, `arm64` and `ppc64le`.
-
-```shell
-kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
-```
-
-For more information about `flannel`, see [the CoreOS flannel repository on GitHub
-](https://github.com/coreos/flannel).-->
-
-{{% tab name="Flannel" %}}
-
-为了让 `flannel` 能正确工作，您必须在运行 `kubeadm init` 时设置 `--Pod-network-cidr=10.244.0.0/16`。
-
-通过运行 `sysctl net.bridge.bridge-nf-call-iptables=1` 将 `/proc/sys/net/bridge/bridge-nf-call-iptables` 设置成 `1`，
-进而确保桥接的 IPv4 流量会传递给 iptables。
-这是一部分 CNI 插件运行的要求条件，请查看[这篇文档](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements)获取更详细信息。
-
-注意 `flannel` 适用于 `amd64`、`arm`、`arm64` 和 `ppc64le` 架构平台。
-
-```shell
-kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
-```
-
-想了解更多关于 `flannel` 的信息,请查阅[ GitHub 上的 CoreOS flannel 仓库](https://github.com/coreos/flannel)。
-{{% /tab %}}
-
-<!--
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
-to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
-please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-
-Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--Pod-network-cidr` flag.
-
-Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
-
-For information on setting up Kubernetes cluster with Kube-router using kubeadm, please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
--->
-
-{{% tab name="Kube-router" %}}
-通过运行 `sysctl net.bridge.bridge-nf-call-iptables=1` 将 `/proc/sys/net/bridge/bridge-nf-call-iptables` 设置成 `1`，
-确保桥接的 IPv4 流量会传递给 iptables。
-这是一部分 CNI 插件的运行条件。请查看[这篇文档](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements)了解更详细的信息。
-
-Kube-router 依赖于 kube-controller-manager 来给节点分配 CIDR， 因此需要设置 `kubeadm init` 的 `--Pod-network-cidr` 参数。
-
-Kube-router 提供 Pod 间联网、网络策略和和高效的基于 IPVS/LVS 的服务代理功能。
-
-想了解关于使用 kubeadm 搭建 Kubernetes 和 Kube-router 的更多信息。请查看官方的[安装指引](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md)。
-{{% /tab %}}
-
-<!--
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
-to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
-please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-
-The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm).
-
-Romana works on `amd64` only.
-
-```shell
-kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
-```
--->
-
-{{% tab name="Romana" %}}
-通过运行 `sysctl net.bridge.bridge-nf-call-iptables=1` 将 `/proc/sys/net/bridge/bridge-nf-call-iptables` 设置成 `1`，
-确保桥接的 IPv4 流量会传递给 iptables。这是一部分 CNI 插件的运行条件。
-请查看[这篇文档](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements)
-获取更详细的信息。
-
-官方的 Romana 安装指引在[这里](https://github.com/romana/romana/tree/master/containerize#using-kubeadm)。
-
-注意，Romana 只适用于 `amd64` 架构。
-
-```shell
-kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
-```
-{{% /tab %}}
-
-<!--
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
-to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
-please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-
-The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/).
-
-Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` without any extra action required.
-Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
-if they don't know their PodIP.
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
--->
-
-{{% tab name="Weave Net" %}}
-
-通过运行 `sysctl net.bridge.bridge-nf-call-iptables=1` 将 `/proc/sys/net/bridge/bridge-nf-call-iptables` 设置成 `1`，
-将桥接的 IPv4 流量传递给 iptables。这是一部分 CNI 插件的运行条件。
-请查看[这篇文档](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements)
-获取更详细的信息。
-
-官方的 Weave Net 配置向导在[这里](https://www.weave.works/docs/net/latest/kube-addon/)。
-
-Weave Net 适用于`amd64`、`arm`、`arm64` 和 `ppc64le` 而不需要其它额外的配置。
-Weave Net 默认启用 hairpin 模式，可以让 Pod 在不知道他们自己的 PodIP 的时候仍可以使用服务的 IP 地址来访问他们自己。
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-{{% /tab %}}
-
-<!--
-Provides overlay SDN solution, delivering multicloud networking, hybrid cloud networking,
-simultaneous overlay-underlay support, network policy enforcement, network isolation,
-service chaining and flexible load balancing.
-
-There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
-
-Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
--->
-
-{{% tab name="JuniperContrail/TungstenFabric" %}}
-提供了支持 overlay 的 SDN 解决方案，支持多云环境和混合云环境的网络方案，同时支持 overlay 和 underlay、网络策略、
-网络隔离、服务链和灵活的负载均衡。
-
-安装 JuniperContrail/TungstenFabric CNI 有很多灵活的方式。
-
-请查阅这个[安装指引](https://tungstenfabric.github.io/website/)。
-{{% /tab %}}
-{{< /tabs >}}
-
-<!-- Once a Pod network has been installed, you can confirm that it is working by
-checking that the CoreDNS Pod is Running in the output of `kubectl get Pods --all-namespaces`.
-And once the CoreDNS Pod is up and running, you can continue by joining your nodes.
-
-If your network is not working or CoreDNS is not in the Running state, check
-out our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/). -->
-
-一旦 Pod 网络安装完成，您就可以通过 `kubectl get Pods --all-namespaces` 的输出来验证 CoreDNS Pod 是否正常运行。
-只要确认了 CoreDNS 正常运行，您就可以向集群中添加节点了。
-
-如果您的网络不能工作或者 CoreDNS 不在运行状态，请查阅[查错方案](/docs/setup/independent/troubleshooting-kubeadm/)。
-
-<!-- ### Master Isolation
-
-By default, your cluster will not schedule Pods on the master for security
-reasons. If you want to be able to schedule Pods on the master, e.g. for a
-single-machine Kubernetes cluster for development, run:
-
-```bash
-kubectl taint nodes --all node-role.kubernetes.io/master-
-```
-
-With output looking something like:
-
-```
-node "test-01" untainted
-taint "node-role.kubernetes.io/master:" not found
-taint "node-role.kubernetes.io/master:" not found
-```
-
-This will remove the `node-role.kubernetes.io/master` taint from any nodes that
-have it, including the master node, meaning that the scheduler will then be able
-to schedule Pods everywhere. -->
-
-### 主节点隔离
-
-出于安全原因，默认您的主节点不会被调度运行任何 Pod。
-如果您需要在主节点上运行 Pod，比如说部署环境是一个单机器集群，运行：
-
-```bash
-kubectl taint nodes --all node-role.kubernetes.io/master-
-```
-
-输出类似这样：
-
-```
-node "test-01" untainted
-taint "node-role.kubernetes.io/master:" not found
-taint "node-role.kubernetes.io/master:" not found
-```
-
-这个操作会从任何有 `node-role.kubernetes.io/master` 这种标签的节点移除该标签，包括主节点，
-标签的移除意味着集群调度器可以将 Pod 调度到任何节点。
-
-<!-- ### Joining your nodes {#join-nodes}
-
-The nodes are where your workloads (containers and Pods, etc) run. To add new nodes to your cluster do the following for each machine:
-
-* SSH to the machine
-* Become root (e.g. `sudo su -`)
-* Run the command that was output by `kubeadm init`. For example:
-
-``` bash
-kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
-``` -->
-
-### 添加节点 {#join-nodes}
-
-节点就是工作负载（容器和 Pod 等）运行的地方。如需向集群添加新节点，可以在每台机器上面执行如下操作：
-
-* SSH 连接到机器上
-* 成为 root 用户（比如 `sudo su -`）
-* 运行 `kubeadm init` 输出里的命令，即：
-
-``` bash
-kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
-```
-<!--
-If you do not have the token, you can get it by running the following command on the master node:
-
-``` bash
-kubeadm token list
-```
-
-The output is similar to this:
-
-``` console
-TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
-8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
-                                                   signing          token generated by     bootstrappers:
-                                                                    'kubeadm init'.        kubeadm:
-                                                                                           default-node-token
-``` -->
-
-
-如果您没有保存令牌的话，可以通过在主节点上执行下面的命令来获取：
-
-``` bash
-kubeadm token list
-```
-
-输出类似这样:
-
-``` console
-TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
-8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
-                                                   signing          token generated by     bootstrappers:
-                                                                    'kubeadm init'.        kubeadm:
-                                                                                           default-node-token
-```
-
-<!-- By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired,
-you can create a new token by running the following command on the master node:
-
-``` bash
-kubeadm token create
-```
-
-The output is similar to this:
-
-``` console
-5didvk.d09sbcov8ph2amjw
-```
-
-If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the master node:
-
-``` bash
-openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
-   openssl dgst -sha256 -hex | sed 's/^.* //'
-```
-
-The output is similar to this:
-
-``` console
-8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
-``` -->
-
-默认情况下，令牌会在 24 小时内过期。如果在令牌过期之后添加节点，您可以在主节点上执行下面的命令创建一个新令牌：
-
-``` bash
-kubeadm token create
-```
-
-输出类似这样：
-
-``` console
-5didvk.d09sbcov8ph2amjw
-```
-
-如果您也不知道这个 `--discovery-token-ca-cert-hash` 的值，您也可以在主节点上运行下面的命令来获取：
-
-``` bash
-openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
-   openssl dgst -sha256 -hex | sed 's/^.* //'
-```
-
-输出类似这样：
-
-``` console
-8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
-```
-
-<!-- {{< note >}}
-**Note:** To specify an IPv6 tuple for `<master-ip>:<master-port>`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
-{{< /note >}}
-
-The output should look something like:
-
-```
-[preflight] Running pre-flight checks
-
-... (log output of join workflow) ...
-
-Node join complete:
-* Certificate signing request sent to master and response
-  received.
-* Kubelet informed of new secure connection details.
-
-Run 'kubectl get nodes' on the master to see this machine join.
-```
-
-A few seconds later, you should notice this node in the output from `kubectl get
-nodes` when run on the master. -->
-
-{{< note >}}
-若需为 `<master-ip>:<master-port>` 参数设定一个 IPv6 的元组，地址必须写在一对方括号里面，比如: `[fd00::101]:2073`。
-{{< /note >}}
-
-输出类似这样:
-
-```
-[preflight] Running pre-flight checks
-
-... (log output of join workflow) ...
-
-Node join complete:
-* Certificate signing request sent to master and response
-  received.
-* Kubelet informed of new secure connection details.
-
-Run 'kubectl get nodes' on the master to see this machine join.
-```
-
-几秒钟之后，您将能在主节点上的 `kubectl get nodes` 的输出里发现新添加的节点。
-
-<!-- ### (Optional) Controlling your cluster from machines other than the master
-
-In order to get a kubectl on some other computer (e.g. laptop) to talk to your
-cluster, you need to copy the administrator kubeconfig file from your master
-to your workstation like this:
-
-``` bash
-scp root@<master ip>:/etc/kubernetes/admin.conf .
-kubectl --kubeconfig ./admin.conf get nodes
-```
-
-{{< note >}}
-**Note:** The example above assumes SSH access is enabled for root. If that is not the
-case, you can copy the `admin.conf` file to be accessible by some other user
-and `scp` using that other user instead.
-
-The `admin.conf` file gives the user _superuser_ privileges over the cluster.
-This file should be used sparingly. For normal users, it's recommended to
-generate an unique credential to which you whitelist privileges. You can do
-this with the `kubeadm alpha phase kubeconfig user --client-name <CN>`
-command. That command will print out a KubeConfig file to STDOUT which you
-should save to a file and distribute to your user. After that, whitelist
-privileges by using `kubectl create (cluster)rolebinding`.
-{{< /note >}} -->
-
-### (可选) 在非主节点上控制集群
-
-为了能在其他机器（比如，笔记本）上使用 kubectl 来控制您的集群，您可以从主节点上复制管理员的
-kubeconfig 到您的机器上，像下面这样操作：
-
-``` bash
-scp root@<master ip>:/etc/kubernetes/admin.conf .
-kubectl --kubeconfig ./admin.conf get nodes
-```
-
-{{< note >}}
-上面的例子生效的前提是 SSH 允许 root 用户连接登录。
-如果root 用户不能连接的话，您可以将 `admin.conf` 复制到允许其他用户访问的其他地方并将 `scp` 命令里的用户改成相对应的用户再复制。
-
-这个 `admin.conf` 文件给予了用户整个集群的超级用户权限，因此这个操作必须小心谨慎。对于普通用户来说，
-更建议创建一个适用于白名单某些权限的验证文件。您可以通过这个命令来生成 `kubeadm alpha phase kubeconfig user --client-name <CN>`。
-这个命令会打印 KubeConfig 的内容到标准输出，然后您需要将它保存到一个文件里并分发给您的用户。然后再创建权限的白名单列表，
-命令如下： `kubectl create (cluster)rolebinding` 。
-{{< /note >}}
-
-<!-- ### (Optional) Proxying API Server to localhost
-
-If you want to connect to the API Server from outside the cluster you can use
-`kubectl proxy`:
-
-```bash
-scp root@<master ip>:/etc/kubernetes/admin.conf .
-kubectl --kubeconfig ./admin.conf proxy
-```
-
-You can now access the API Server locally at `http://localhost:8001/api/v1` -->
-
-### (可选) 将 API 服务代理到本地
-
-如果您需要从集群外部连接到您的 API 服务器，请运行`kubectl proxy`:
-
-```bash
-scp root@<master ip>:/etc/kubernetes/admin.conf .
-kubectl --kubeconfig ./admin.conf proxy
-```
-
-现在您就可以在本地访问 `http://localhost:8001/api/v1` 来连接 API 服务器了。
-
-<!-- ## Tear down {#tear-down}
-
-To undo what kubeadm did, you should first [drain the
-node](/docs/reference/generated/kubectl/kubectl-commands#drain) and make
-sure that the node is empty before shutting it down.
-
-Talking to the master with the appropriate credentials, run:
-
-```bash
-kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
-kubectl delete node <node name>
-```
-
-Then, on the node being removed, reset all kubeadm installed state:
-
-```bash
-kubeadm reset
-```
-
-If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
-appropriate arguments.
-
-More options and information about the
-[`kubeadm reset command`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).-->
-
-## 卸载集群 {#tear-down}
-
-想要回退 kubeadm 做出的修改，您需要首先[腾空节点](/docs/reference/generated/kubectl/kubectl-commands#drain)
-而且必须确保在关闭节点之前没有任何工作负载在运行。
-
-使用正确的登录凭据来连接到主节点：
-
-```bash
-kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
-kubectl delete node <node name>
-```
-
-然后在待移除的节点上，重置所有 kubeadm 的安装状态：
-
-```bash
-kubeadm reset
-```
-
-如果您只是想重新运行 `kubeadm init` 或者 `kubeadm join`，[`kubeadm reset`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/)页面有更多的信息可供参考.
-
-<!-- ## Maintaining a cluster {#lifecycle}
-
-Instructions for maintaining kubeadm clusters (e.g. upgrades,downgrades, etc.) can be found [here.](/docs/tasks/administer-cluster/kubeadm)
-
-## Explore other add-ons {#other-addons}
-
-See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons,
-including tools for logging, monitoring, network policy, visualization &amp;
-control of your Kubernetes cluster. -->
-
-## 集群维护 {#lifecycle}
-
-维护集群（比如升级，降级）的详细指令，可参考[这里](/docs/tasks/administer-cluster/kubeadm)。
-
-## 探索其他插件 {#other-addons}
-
-查看[插件列表](/docs/concepts/cluster-administration/addons/)来发现其他插件，包括日志、监控、网络策略、
-可视化和集群管理工具等等。
-
-<!-- ## What's next {#whats-next}
-
-* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
-* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
-* Configure log rotation. You can use **logrotate** for that. When using Docker, you can specify log rotation options for Docker daemon, for example `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`. See [Configure and troubleshoot the Docker daemon](https://docs.docker.com/engine/admin/) for more details.
-
-## Feedback {#feedback}
-
-* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
-* For support, visit kubeadm Slack Channel:
-  [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
-* General SIG Cluster Lifecycle Development Slack Channel:
-  [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
-* SIG Cluster Lifecycle [SIG information](#TODO)
-* SIG Cluster Lifecycle Mailing List:
-  [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle) -->
-
-## 后续 {#whats-next}
-
-* 使用 [Sonobuoy](https://github.com/heptio/sonobuoy) 验证集群是否正确运行
-* 阅读[kubeadm 参考文档](/docs/reference/setup-tools/kubeadm/kubeadm)，学习 kubeadm 的高级应用
-* 进一步了解 Kubernetes 的[概念](/docs/concepts/)和 [`kubectl`](/docs/user-guide/kubectl-overview/)
-* 您可以使用 **logrotate** 配置日志轮转。使用 Docker 的时候，您可以给 Docker 守护进程设置日志轮转的选项，
-比如 `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`。请查阅 [Docker 守护进程的配置和纠错](https://docs.docker.com/engine/admin/)。
-
-## 反馈 {#feedback}
-
-* 如果发现故障，请访问 [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
-* 如果需要支持，请访问 kubeadm 的 Slack 频道：[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
-* 访问 SIG cluster-lifecycle 开发者所使用的 Slack 频道：
-  [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
-* SIG cluster-lifecycle 的 [SIG 信息](#TODO)
-* SIG cluster-lifecycle 的邮件列表:
-  [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
-
-<!-- ## Version skew policy {#version-skew-policy}
-
-The kubeadm CLI tool of version vX.Y may deploy clusters with a control plane of version vX.Y or vX.(Y-1).
-kubeadm CLI vX.Y can also upgrade an existing kubeadm-created cluster of version vX.(Y-1).
-
-Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be able to deploy vX.(Y+1) clusters.
-
-Example: kubeadm v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
-v1.8.
-
-Please also check our [installation guide](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
-for more information on the version skew between kubelets and the control plane. -->
-
-## 版本偏差策略 {#version-skew-policy}
-
-vX.Y 版本的 kubeadm 命令行工具可能会部署一个控制面版本为 vX.Y 或者 vX.(Y-1) 的集群，也可以用于升级一个 vX.(Y-1) 的由 kubeadm 创建的集群。
-因为我们无法预见未来，版本为 vX.Y 的 kubeadm 可能可以也可能无法用于部署 vX.(Y+1) 版本的集群。
-例子: kubeadm v1.8 可以用于部署 v1.7 和 v1.8 的集群，也可以升级 v1.7 的由 kubeadm 创建的集群到 1.8 版本。
-请查看我们的[安装向导](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)，其中提供了关于 kubelet 和控制面版本偏差的更多信息。
-
-<!-- ## kubeadm works on multiple platforms {#multi-platform}
-
-kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x
-following the [multi-platform
-proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md).
-
-Only some of the network providers offer solutions for all platforms. Please consult the list of
-network providers above or the documentation from each provider to figure out whether the provider
-supports your chosen platform. -->
-
-## 跨多平台上使用 kubeadm {#multi-platform}
-
-kubeadm 的 deb/rpm 包和可执行文件都是适用于 amd64、arm (32位)、arm64、ppc64le 和 s390x等架构平台的，
-请查阅[多平台方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md)。
-
-只有一部分的网络驱动提供了所有平台的网络解决方案，请查询上面的网络驱动列表或者对应的官方文档来确定是否支持您的平台。
-
-<!-- ## Limitations {#limitations}
-
-Please note: kubeadm is a work in progress and these limitations will be
-addressed in due course.
-
-1. The cluster created here has a single master, with a single etcd database
-   running on it. This means that if the master fails, your cluster may lose
-   data and may need to be recreated from scratch. Adding HA support
-   (multiple etcd servers, multiple API servers, etc) to kubeadm is
-   still a work-in-progress.
-
-   Workaround: regularly
-   [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
-   etcd data directory configured by kubeadm is at `/var/lib/etcd` on the master.
-
-## Troubleshooting {#troubleshooting}
-
-If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/). -->
-
-## 局限 {#limitations}
-
-请注意，kubeadm 还处于正在开发的状态中，这些局限将会在适当的时间修正。
-
-1. 这篇文档介绍的创建的集群只能有单一的主节点和单一的 etcd 数据库，这表示如果主节点宕机，您的集群将会丢失数据
-   而且可能无法重新创建。目前给 kubeadm 添加高可用支持（比如多 etcd 多 API服务等等）的功能还在开发当中，因此可先参照下面的
-   临时解决方案: 经常性地[备份 etcd](https://coreos.com/etcd/docs/latest/admin_guide.html)。
-   由 kubeadm 配置的 etcd 数据位于主节点上的 `/var/lib/etcd` 目录。
-
-## 查错 {#troubleshooting}
-
-如果您在使用 kubeadm 发现任何问题，请查阅我们的[纠错文档](/docs/setup/independent/troubleshooting-kubeadm/)。
-
-
-
-
-
diff --git a/content/en/docs/setup/learning-environment/kind.md b/content/zh/docs/setup/learning-environment/kind.md
similarity index 50%
rename from content/en/docs/setup/learning-environment/kind.md
rename to content/zh/docs/setup/learning-environment/kind.md
index ac355bd157..d45686fc23 100644
--- a/content/en/docs/setup/learning-environment/kind.md
+++ b/content/zh/docs/setup/learning-environment/kind.md
@@ -1,23 +1,23 @@
 ---
-title: Installing Kubernetes with Kind
+title: 使用 Kind 安装 Kubernetes
 weight: 40
 content_type: concept
 ---
 
 <!-- overview -->
-
+<!--
 Kind is a tool for running local Kubernetes clusters using Docker container "nodes".
+-->
 
-
+Kind 是一个使用 Docker 容器“节点”运行本地 Kubernetes 集群的工具。
 
 <!-- body -->
-
+<!--
 ## Installation
 
 See [Installing Kind](https://kind.sigs.k8s.io/docs/user/quick-start/).
+-->
 
+## 安装  {#installation}
 
-
-
-
-
+参见[安装 Kind ](https://kind.sigs.k8s.io/docs/user/quick-start/)。
diff --git a/content/zh/docs/setup/learning-environment/minikube.md b/content/zh/docs/setup/learning-environment/minikube.md
deleted file mode 100644
index bd828ec871..0000000000
--- a/content/zh/docs/setup/learning-environment/minikube.md
+++ /dev/null
@@ -1,929 +0,0 @@
----
-title: 使用 Minikube 安装 Kubernetes
-content_type: concept
----
-<!--
----
-reviewers:
-- dlorenc
-- balopat
-- aaron-prindle
-title: Installing Kubernetes with Minikube
-content_type: concept
----
--->
-
-<!-- overview -->
-
-<!--
-Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a Virtual Machine (VM) on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
--->
-Minikube 是一种可以让您在本地轻松运行 Kubernetes 的工具。Minikube 在笔记本电脑上的虚拟机（VM）中运行单节点 Kubernetes 集群，供那些希望尝试 Kubernetes 或进行日常开发的用户使用。
-
-
-
-<!-- body -->
-
-<!--
-## Minikube Features
--->
-## Minikube 功能
-
-<!--
-Minikube supports the following Kubernetes features:
--->
-Minikube 支持以下 Kubernetes 功能：
-
-<!--
-* DNS
-* NodePorts
-* ConfigMaps and Secrets
-* Dashboards
-* Container Runtime: Docker, [CRI-O](https://github.com/kubernetes-incubator/cri-o), and [containerd](https://github.com/containerd/containerd)
-* Enabling CNI (Container Network Interface)
-* Ingress
--->
-
-* DNS
-* NodePorts
-* ConfigMaps 和 Secrets
-* Dashboards
-* 容器运行时: Docker、[CRI-O](https://github.com/kubernetes-incubator/cri-o) 以及 [containerd](https://github.com/containerd/containerd)
-* 启用 CNI （容器网络接口）
-* Ingress
-
-<!--
-## Installation
--->
-## 安装
-
-<!--
-See [Installing Minikube](/docs/tasks/tools/install-minikube/).
--->
-请参阅[安装 Minikube](/zh/docs/tasks/tools/install-minikube/)。
-
-<!--
-## Quickstart
--->
-## 快速开始
-
-<!--
-This brief demo guides you on how to start, use, and delete Minikube locally. Follow the steps given below to start and explore Minikube.
--->
-这个简短的演示将指导您如何在本地启动、使用和删除 Minikube。请按照以下步骤开始探索 Minikube。
-
-<!--
-1. Start Minikube and create a cluster:
--->
-1. 启动 Minikube 并创建一个集群：
-
-    ```shell
-    minikube start
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    Starting local Kubernetes cluster...
-    Running pre-create checks...
-    Creating machine...
-    Starting local Kubernetes cluster...
-    ```
-
-    <!--
-    For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster).
-    -->
-
-    有关使用特定 Kubernetes 版本、VM 或容器运行时启动集群的详细信息，请参阅[启动集群](#starting-a-cluster)。
-
-2. 现在，您可以使用 kubectl 与集群进行交互。有关详细信息，请参阅[与集群交互](#interacting-with-your-cluster)。
-
-    <!--
-    Now, you can interact with your cluster using kubectl. For more information, see [Interacting with Your Cluster](#interacting-with-your-cluster).
-    -->
-
-    <!--
-    Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`.
-    -->
-    让我们使用名为 `echoserver` 的镜像创建一个 Kubernetes Deployment，并使用 `--port` 在端口 8080 上暴露服务。`echoserver` 是一个简单的 HTTP 服务器。
-
-    ```shell
-    kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    deployment.apps/hello-minikube created
-    ```
-
-3. 要访问 `hello-minikube` Deployment，需要将其作为 Service 公开：
-
-    <!--
-    To access the `hello-minikube` Deployment, expose it as a Service:
-    -->
-
-    ```shell
-    kubectl expose deployment hello-minikube --type=NodePort --port=8080
-    ```
-    <!--
-    The option `--type=NodePort` specifies the type of the Service.
-    -->
-    选项 `--type = NodePort` 指定 Service 的类型。
-
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    service/hello-minikube exposed
-    ```
-
-4. 现在 `hello-minikube` Pod 已经启动，但是您必须等到 Pod 启动完全才能通过暴露的 Service 访问它。
-
-    <!--
-    The `hello-minikube` Pod is now launched but you have to wait until the Pod is up before accessing it via the exposed Service.
-    -->
-
-    <!--
-	Check if the Pod is up and running:
-    -->
-    检查 Pod 是否启动并运行：
-
-	```shell
-	kubectl get pod
-	```
-    <!--
-	If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created:
-    -->
-    如果输出显示 `STATUS` 为 `ContainerCreating`，则表明 Pod 仍在创建中：
-	```
-	NAME                              READY     STATUS              RESTARTS   AGE
-	hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
-	```
-    <!--
-	If the output shows the `STATUS` as `Running`, the Pod is now up and running:
-    -->
-    如果输出显示 `STATUS` 为 `Running`，则 Pod 现在正在运行：
-	```
-	NAME                              READY     STATUS    RESTARTS   AGE
-	hello-minikube-3383150820-vctvh   1/1       Running   0          13s
-	```
-
-5. 获取暴露 Service 的 URL 以查看 Service 的详细信息：
-
-    <!--
-    Get the URL of the exposed Service to view the Service details:
-    -->
-
-	```shell
-	minikube service hello-minikube --url
-	```
-
-6. 要查看本地集群的详细信息，请在浏览器中复制粘贴并访问上一步骤输出的 URL。
-
-    <!--
-    To view the details of your local cluster, copy and paste the URL you got as the output, on your browser.
-    -->
-
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    Hostname: hello-minikube-7c77b68cff-8wdzq
-
-    Pod Information:
-        -no pod information available-
-
-    Server values:
-        server_version=nginx: 1.13.3 - lua: 10008
-
-    Request Information:
-        client_address=172.17.0.1
-        method=GET
-        real path=/
-        query=
-        request_version=1.1
-        request_scheme=http
-        request_uri=http://192.168.99.100:8080/
-
-    Request Headers:
-        accept=*/*
-        host=192.168.99.100:30674
-        user-agent=curl/7.47.0
-
-    Request Body:
-        -no body in request-
-    ```
-    <!--
-	If you no longer want the Service and cluster to run, you can delete them.
-    -->
-    如果您不再希望运行 Service 和集群，则可以删除它们。
-
-7. 删除 `hello-minikube` Service：
-
-    <!--
-    Delete the `hello-minikube` Service:
-    -->
-
-    ```shell
-    kubectl delete services hello-minikube
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    service "hello-minikube" deleted
-    ```
-
-8. 删除 `hello-minikube` Deployment：
-
-    <!--
-    Delete the `hello-minikube` Deployment:
-    -->
-
-    ```shell
-    kubectl delete deployment hello-minikube
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    deployment.extensions "hello-minikube" deleted
-    ```
-
-9.  停止本地 Minikube 集群：
-
-    <!--
-    Stop the local Minikube cluster:
-    -->
-
-    ```shell
-    minikube stop
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    Stopping "minikube"...
-    "minikube" stopped.
-    ```
-    <!--
-	For more information, see [Stopping a Cluster](#stopping-a-cluster).
-    -->
-    有关更多信息，请参阅[停止集群](#stopsing-a-cluster)。
-
-10. 删除本地 Minikube 集群：
-
-    <!--
-    Delete the local Minikube cluster:
-    -->
-
-    ```shell
-    minikube delete
-    ```
-    <!--
-    The output is similar to this:
-    -->
-    输出类似于：
-
-    ```
-    Deleting "minikube" ...
-    The "minikube" cluster has been deleted.
-    ```
-    <!--
-	For more information, see [Deleting a cluster](#deleting-a-cluster).
-    -->
-    有关更多信息，请参阅[删除集群](#deletion-a-cluster)。
-
-<!--
-## Managing your Cluster
--->
-## 管理您的集群
-
-<!--
-### Starting a Cluster
--->
-### 启动集群 {#starting-a-cluster}
-
-<!--
-The `minikube start` command can be used to start your cluster.
--->
-`minikube start` 命令可用于启动集群。
-<!--
-This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
--->
-此命令将创建并配置一台虚拟机，使其运行单节点 Kubernetes 集群。
-<!--
-This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
--->
-此命令还会配置您的 [kubectl](/docs/user-guide/kubectl-overview/) 安装，以便使其能与您的 Kubernetes 集群正确通信。
-
-<!--
-If you are behind a web proxy, you need to pass this information to the `minikube start` command:
--->
-<!--
-Unfortunately, setting the environment variables alone does not work.
--->
-<!--
-Minikube also creates a "minikube" context, and sets it to default in kubectl.
--->
-<!--
-To switch back to this context, run this command: `kubectl config use-context minikube`.
--->
-
-{{< note >}}
-如果您启用了 web 代理，则需要将此信息传递给 `minikube start` 命令：
-
-```shell
-https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
-```
-
-不幸的是，单独设置环境变量不起作用。
-
-Minikube 还创建了一个 `minikube` 上下文，并将其设置为 kubectl 的默认上下文。
-
-要切换回此上下文，请运行以下命令：`kubectl config use-context minikube`。
-{{< /note >}}
-
-<!--
-#### Specifying the Kubernetes version
--->
-#### 指定 Kubernetes 版本
-
-<!--
-You can specify the version of Kubernetes for Minikube to use byadding the `--kubernetes-version` string to the `minikube start` command. Forexample, to run version {{< param "fullversion" >}}, you would run the following:
--->
-您可以通过将 `--kubernetes-version` 字符串添加到 `minikube start` 命令来指定要用于 Minikube 的 Kubernetes 版本。例如，要运行版本 {{< param "fullversion" >}}，您可以运行以下命令：
-
-```
-minikube start --kubernetes-version {{< param "fullversion" >}}
-```
-<!--
-#### Specifying the VM driver
-
-You can change the VM driver by adding the `--vm-driver=<enter_driver_name>` flag to `minikube start`.
--->
-#### 指定 VM 驱动程序 {#specifying-the-vm-driver}
-
-您可以通过将 `--vm-driver=<enter_driver_name>` 参数添加到 `minikube start` 来更改 VM 驱动程序。
-<!--
-For example the command would be.
--->
-例如命令：
-
-```shell
-minikube start --vm-driver=<driver_name>
-```
-<!--
- Minikube supports the following drivers:
--->
-Minikube 支持以下驱动程序：
-
-<!--
- See [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) for details on supported drivers and how to install plugins.
--->
-
-<!--
-* virtualbox
-* vmwarefusion
-* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
-* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
-Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
-* vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
-* none (Runs the Kubernetes components on the host and not in a VM. Using this driver requires Docker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) and a Linux environment)
--->
-
-
- {{< note >}}
-有关支持的驱动程序以及如何安装插件的详细信息，请参阅[驱动程序](https://minikube.sigs.k8s.io/docs/drivers/)。
-{{< /note >}}
-
-* virtualbox
-* vmwarefusion
-* kvm2 ([驱动安装](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
-* hyperkit ([驱动安装](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
-* hyperv ([驱动安装](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
-<!--
-Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
--->
-请注意，下面的 IP 是动态的，可以更改。可以使用 `minikube ip` 检索。
-* vmware ([驱动安装](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) （VMware 统一驱动）
-* none (在主机上运行Kubernetes组件，而不是在 VM 中。使用该驱动依赖 Docker ([安装 Docker](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) 和 Linux 环境)
-
-<!--
-#### Starting a cluster on alternative container runtimes
-
-You can start Minikube on the following container runtimes.
--->
-#### 通过别的容器运行时启动集群
-
-您可以通过以下容器运行时启动 Minikube。
-
-{{< tabs name="container_runtimes" >}}
-{{% tab name="containerd" %}}
-<!--
-To use [containerd](https://github.com/containerd/containerd) as the container runtime, run:
--->
-要使用 [containerd](https://github.com/containerd/containerd) 作为容器运行时，请运行：
-
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --container-runtime=containerd \
-    --bootstrapper=kubeadm
-```
-
-<!--
-Or you can use the extended version:
--->
-或者您可以使用扩展版本：
-
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --extra-config=kubelet.container-runtime=remote \
-    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
-    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
-    --bootstrapper=kubeadm
-```
-{{% /tab %}}
-{{% tab name="CRI-O" %}}
-<!--
-To use [CRI-O](https://github.com/kubernetes-incubator/cri-o) as the container runtime, run:
--->
-要使用 [CRI-O](https://github.com/kubernetes-incubator/cri-o) 作为容器运行时，请运行：
-
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --container-runtime=cri-o \
-    --bootstrapper=kubeadm
-```
-<!--
-Or you can use the extended version:
--->
-或者您可以使用扩展版本：
-
-```bash
-minikube start \
-    --network-plugin=cni \
-    --enable-default-cni \
-    --extra-config=kubelet.container-runtime=remote \
-    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
-    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
-    --bootstrapper=kubeadm
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-<!--
-#### Use local images by re-using the Docker daemon
--->
-#### 通过重用 Docker 守护进程使用本地镜像
-
-<!--
-When using a single VM for Kubernetes, it's useful to reuse Minikube's built-in Docker daemon. Reusing the built-in daemon means you don't have to build a Docker registry on your host machine and push the image into it. Instead, you can build inside the same Docker daemon as Minikube, which speeds up local experiments.
--->
-当为 Kubernetes 使用单个 VM 时，重用 Minikube 的内置 Docker 守护程序非常有用。重用内置守护程序意味着您不必在主机上构建 Docker 镜像仓库并将镜像推入其中。相反，您可以在与 Minikube 相同的 Docker 守护进程内部构建，这可以加速本地实验。
-
-{{< note >}}
-<!--
-Be sure to tag your Docker image with something other than latest and use that tag to pull the image. Because `:latest` is the default value, with a corresponding default image pull policy of `Always`, an image pull error (`ErrImagePull`) eventually results if you do not have the Docker image in the default Docker registry (usually DockerHub).
--->
-一定要用非 `latest` 的标签来标记你的 Docker 镜像，并使用该标签来拉取镜像。因为 `:latest` 标记的镜像，其默认镜像拉取策略是 `Always`，如果在默认的 Docker 镜像仓库（通常是 DockerHub）中没有找到你的 Docker 镜像，最终会导致一个镜像拉取错误（`ErrImagePull`）。
-{{< /note >}}
-
-<!--
-To work with the Docker daemon on your Mac/Linux host, use the `docker-env command` in your shell:
--->
-要在 Mac/Linux 主机上使用 Docker 守护程序，请在 shell 中运行 `docker-env command`：
-
-```shell
-eval $(minikube docker-env)
-```
-
-<!--
-You can now use Docker at the command line of your host Mac/Linux machine to communicate with the Docker daemon inside the Minikube VM:
--->
-您现在可以在 Mac/Linux 机器的命令行中使用 Docker 与 Minikube VM 内的 Docker 守护程序进行通信：
-
-```shell
-docker ps
-```
-
-{{< note >}}
-<!--
-On Centos 7, Docker may report the following error:
--->
-在 Centos 7 上，Docker 可能会报如下错误：
-
-```
-Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
-```
-
-<!--
-You can fix this by updating /etc/sysconfig/docker to ensure that Minikube's environment changes are respected:
--->
-您可以通过更新 /etc/sysconfig/docker 来解决此问题，以确保 Minikube 的环境更改得到遵守：
-
-```shell
-< DOCKER_CERT_PATH=/etc/docker
----
-> if [ -z "${DOCKER_CERT_PATH}" ]; then
->   DOCKER_CERT_PATH=/etc/docker
-> fi
-```
-{{< /note >}}
-
-<!--
-### Configuring Kubernetes
--->
-### 配置 Kubernetes
-
-<!--
-Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values.
--->
-Minikube 有一个 "configurator" 功能，允许用户使用任意值配置 Kubernetes 组件。
-<!--
-To use this feature, you can use the `--extra-config` flag on the `minikube start` command.
--->
-要使用此功能，可以在 `minikube start` 命令中使用 `--extra-config` 参数。
-
-<!--
-This flag is repeated, so you can pass it several times with several different values to set multiple options.
--->
-此参数允许重复，因此您可以使用多个不同的值多次传递它以设置多个选项。
-
-<!--
-This flag takes a string of the form `component.key=value`, where `component` is one of the strings from the below list, `key` is a value on the configuration struct and `value` is the value to set.
--->
-此参数采用 `component.key=value` 形式的字符串，其中 `component` 是下面列表中的一个字符串，`key` 是配置项名称，`value` 是要设置的值。
-
-<!--
-Valid keys can be found by examining the documentation for the Kubernetes `componentconfigs` for each component.
--->
-通过检查每个组件的 Kubernetes `componentconfigs` 的文档，可以找到有效的 key。
-<!--
-Here is the documentation for each supported configuration:
--->
-下面是每个组件所支持的配置的介绍文档：
-
-* [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
-* [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions)
-* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration)
-* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration)
-* [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig)
-* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration)
-
-<!--
-#### Examples
--->
-#### 例子
-
-<!--
-To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-config=kubelet.MaxPods=5`.
--->
-要在 Kubelet 上将 `MaxPods` 设置更改为 5，请传递此参数：`--extra-config=kubelet.MaxPods=5`。
-
-<!--
-This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
--->
-此功能还支持嵌套结构。要在调度程序上将 `LeaderElection.LeaderElect` 设置更改为 `true`，请传递此参数：`--extra-config=scheduler.LeaderElection.LeaderElect=true`。
-
-<!--
-To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.authorization-mode=RBAC`.
--->
-要将 `apiserver` 的 `AuthorizationMode` 设置为 `RBAC`，您可以使用：`--extra-config=apiserver.authorization-mode=RBAC`。
-
-<!--
-### Stopping a ClusterThe
-
-`minikube stop` command can be used to stop your cluster.
--->
-### 停止集群 {#stopsing-a-cluster}
-
-`minikube stop` 命令可用于停止集群。
-<!--
-This command shuts down the Minikube Virtual Machine, but preserves all cluster state and data.
--->
-此命令关闭 Minikube 虚拟机，但保留所有集群状态和数据。
-<!--
-Starting the cluster again will restore it to its previous state.
--->
-再次启动集群会将其恢复到以前的状态。
-
-<!--
-### Deleting a ClusterThe
-
-`minikube delete` command can be used to delete your cluster.
--->
-### 删除集群 {#deletion-a-cluster}
-
-`minikube delete` 命令可用于删除集群。
-<!--
-This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.
--->
-此命令将关闭并删除 Minikube 虚拟机，不保留任何数据或状态。
-
-<!--
-## Interacting with Your Cluster
--->
-## 与集群交互 {#interacting-with-your-cluster}
-
-<!--
-### Kubectl
--->
-### Kubectl
-
-<!--
-The `minikube start` command creates a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) called "minikube".
--->
-`minikube start` 命令创建一个名为 `minikube` 的 [kubectl 上下文](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-)。
-<!--
-This context contains the configuration to communicate with your Minikube cluster.
--->
-此上下文包含与 Minikube 集群通信的配置。
-
-<!--
-Minikube sets this context to default automatically, but if you need to switch back to it in the future, run:
--->
-Minikube 会自动将此上下文设置为默认值，但如果您以后需要切换回它，请运行：
-
-<!--
-`kubectl config use-context minikube`,
--->
-`kubectl config use-context minikube`，
-
-<!--
-Or pass the context on each command like this: `kubectl get pods --context=minikube`.
--->
-或者像这样，每个命令都附带其执行的上下文：`kubectl get pods --context=minikube`。
-
-<!--
-### Dashboard
--->
-### 仪表盘
-
-<!--
-To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting Minikube to get the address:
--->
-要访问 [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)，请在启动 Minikube 后在 shell 中运行此命令以获取地址：
-
-```shell
-minikube dashboard
-```
-
-<!--
-### Services
--->
-### Service
-
-<!--
-To access a Service exposed via a node port, run this command in a shell after starting Minikube to get the address:
--->
-要访问通过节点（Node）端口公开的 Service，请在启动 Minikube 后在 shell 中运行此命令以获取地址：
-
-```shell
-minikube service [-n NAMESPACE] [--url] NAME
-```
-
-<!--
-## Networking
--->
-## 网络
-
-<!--
-The Minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command.
--->
-Minikube VM 通过 host-only IP 暴露给主机系统，可以通过 `minikube ip` 命令获得该 IP。
-<!--
-Any services of type `NodePort` can be accessed over that IP address, on the NodePort.
--->
-在 NodePort 上，可以通过该 IP 地址访问任何类型为 `NodePort` 的服务。
-
-<!--
-To determine the NodePort for your service, you can use a `kubectl` command like this:
--->
-要确定服务的 NodePort，可以像这样使用 `kubectl` 命令：
-
-<!--
-`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
--->
-`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
-
-<!--
-## Persistent Volumes
-
-Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`.
--->
-## 持久卷（PersistentVolume）
-
-Minikube 支持 `hostPath` 类型的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
-<!--
-These PersistentVolumes are mapped to a directory inside the Minikube VM.
--->
-这些持久卷会映射为 Minikube VM 内的目录。
-
-<!--
-The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`).
--->
-Minikube VM 引导到 tmpfs，因此大多数目录不会在重新启动（`minikube stop`）之后保持不变。
-<!--
-However, Minikube is configured to persist files stored under the following host directories:
--->
-但是，Minikube 被配置为保存存储在以下主机目录下的文件：
-
-* `/data`
-* `/var/lib/minikube`
-* `/var/lib/docker`
-
-<!--
-Here is an example PersistentVolume config to persist data in the `/data` directory:
--->
-下面是一个持久卷配置示例，用于在 `/data` 目录中保存数据：
-
-```yaml
-apiVersion: v1
-kind: PersistentVolume
-metadata:
-  name: pv0001
-spec:
-  accessModes:
-    - ReadWriteOnce
-  capacity:
-    storage: 5Gi
-  hostPath:
-    path: /data/pv0001/
-```
-
-<!--
-## Mounted Host Folders
-
-Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host.  These are not configurable at the moment and different for the driver and OS you are using.
--->
-## 挂载宿主机文件夹
-
-一些驱动程序将在 VM 中挂载一个主机文件夹，以便您可以轻松地在 VM 和主机之间共享文件。目前这些都是不可配置的，并且根据您正在使用的驱动程序和操作系统的不同而不同。
-
-<!--
-Host folder sharing is not implemented in the KVM driver yet.
--->
-
-{{< note >}}
-KVM 驱动程序中尚未实现主机文件夹共享。
-{{< /note >}}
-
-| 驱动 | 操作系统 | 宿主机文件夹 | VM 文件夹 |
-| --- | --- | --- | --- |
-| VirtualBox | Linux | /home | /hosthome |
-| VirtualBox | macOS | /Users | /Users |
-| VirtualBox | Windows | C://Users | /c/Users |
-| VMware Fusion | macOS | /Users | /Users |
-| Xhyve | macOS | /Users | /Users |
-
-<!--
-## Private Container Registries
--->
-## 私有容器镜像仓库
-
-<!--
-To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/).
--->
-要访问私有容器镜像仓库，请按照[本页](/docs/concepts/containers/images/)上的步骤操作。
-
-<!--
-We recommend you use `ImagePullSecrets`, but if you would like to configure access on the Minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory.
--->
-我们建议您使用 `ImagePullSecrets`，但是如果您想在 Minikube VM 上配置访问权限，可以将 `.dockercfg` 放在 `/home/docker` 目录中，或将`config.json` 放在 `/home/docker/.docker` 目录。
-
-<!--
-## Add-ons
--->
-## 附加组件
-
-<!--
-In order to have Minikube properly start or restart custom addons,place the addons you wish to be launched with Minikube in the `~/.minikube/addons`directory. Addons in this folder will be moved to the Minikube VM and launched each time Minikube is started or restarted.
--->
-为了让 Minikube 正确启动或重新启动自定义插件，请将您希望用 Minikube 启动的插件放在 `~/.minikube/addons` 目录中。此文件夹中的插件将被移动到 Minikube VM 并在每次 Minikube 启动或重新启动时被启动。
-
-<!--
-## Using Minikube with an HTTP Proxy
--->
-## 基于 HTTP 代理使用 Minikube
-
-<!--
-Minikube creates a Virtual Machine that includes Kubernetes and a Docker daemon.
--->
-Minikube 创建了一个包含 Kubernetes 和 Docker 守护进程的虚拟机。
-<!--
-When Kubernetes attempts to schedule containers using Docker, the Docker daemon may require external network access to pull containers.
--->
-当 Kubernetes 尝试使用 Docker 调度容器时，Docker 守护程序可能需要访问外部网络来拉取容器镜像。
-
-<!--
-If you are behind an HTTP proxy, you may need to supply Docker with the proxy settings.
--->
-如果您配置了 HTTP 代理，则可能也需要为 Docker 进行代理设置。
-<!--
-To do this, pass the required environment variables as flags during `minikube start`.
--->
-要实现这一点，可以在 `minikube start` 期间将所需的环境变量作为参数传递给启动命令。
-
-<!--
-For example:
--->
-例如：
-
-```shell
-minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
-                 --docker-env https_proxy=https://$YOURPROXY:PORT
-```
-
-<!--
-If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent `kubectl` from directly reaching it.
--->
-如果您的虚拟机地址是 192.168.99.100，那么您的代理设置可能会阻止 `kubectl` 直接访问它。
-<!--
-To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with:
--->
-要绕过此 IP 地址的代理配置，您应该修改 no_proxy 设置。您可以这样做：
-
-```shell
-export no_proxy=$no_proxy,$(minikube ip)
-```
-
-<!--
-## Known Issues
--->
-## 已知的问题
-
-<!--
-Features that require multiple nodes will not work in Minikube.
--->
-需要多个节点的功能无法在 Minikube 中使用。
-
-<!--
-## Design
--->
-## 设计
-
-<!--
-Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [kubeadm](https://github.com/kubernetes/kubeadm) to provision a Kubernetes cluster.
--->
-Minikube 使用 [libmachine](https://github.com/docker/machine/tree/master/libmachine) 配置虚拟机，[kubeadm](https://github.com/kubernetes/kubeadm) 配置 Kubernetes 集群。
-
-<!--
-For more information about Minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
--->
-有关 Minikube 的更多信息，请参阅[提案](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md)。
-
-<!--
-## Additional Links
--->
-## 其他链接
-
-<!--
-* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
-* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests.
-* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
-* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube, see the [adding dependencies guide](https://minikube.sigs.k8s.io/docs/contrib/building/iso/).
-* **Adding a New Addon**: For instructions on how to add a new addon for Minikube, see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
-* **MicroK8s**: Linux users wishing to avoid running a virtual machine may consider [MicroK8s](https://microk8s.io/) as an alternative.
--->
-
-* **目标和非目标**: 有关 Minikube 项目的目标和非目标，请参阅我们的 [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md)。
-* **开发指南**: 请查阅 [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) 获取有关如何提交 Pull Request 的概述。
-* **构建 Minikube**: 有关如何从源代码构建/测试 Minikube 的说明，请参阅[构建指南](https://git.k8s.io/minikube/docs/contributors/build_guide.md)。
-* **添加新依赖**: 有关如何向 Minikube 添加新依赖的说明，请参阅[添加依赖项指南](https://minikube.sigs.k8s.io/docs/contrib/building/iso/)。
-* **添加新插件**: 有关如何为 Minikube 添加新插件的说明，请参阅[添加插件指南](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)。
-* **MicroK8s**: 希望避免运行虚拟机的 Linux 用户可以考虑使用 [MicroK8s](https://microk8s.io/) 作为替代品。
-
-<!--
-## Community
--->
-## 社区
-
-<!--
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
--->
-我们欢迎您向社区提交贡献、提出问题以及参与评论！Minikube 开发人员可以在 [Slack](https://kubernetes.slack.com) 的 #minikube 频道上互动交流（点击[这里](http://slack.kubernetes.io/)获得邀请）。我们还有 [kubernetes-dev Google Groups 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-dev)。如果您要发信到列表中，请在主题前加上 "minikube: "。
-
-
diff --git a/content/zh/docs/setup/production-environment/container-runtimes.md b/content/zh/docs/setup/production-environment/container-runtimes.md
index 2873951241..3c9f12fce5 100644
--- a/content/zh/docs/setup/production-environment/container-runtimes.md
+++ b/content/zh/docs/setup/production-environment/container-runtimes.md
@@ -7,542 +7,587 @@ content_type: concept
 weight: 10
 ---
 <!--
----
 reviewers:
 - vincepri
 - bart0sh
 title: Container runtimes
 content_type: concept
 weight: 10
----
 -->
+
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.6" state="stable" >}}
-<!--
-To run containers in Pods, Kubernetes uses a container runtime. Here are
-the installation instructions for various runtimes.
--->
-Kubernetes 使用容器运行时来实现在 pod 中运行容器。
-这是各种运行时的安装说明。
-
 
+<!-- 
+You need to install a
+{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
+into each node in the cluster so that Pods can run there. This page outlines
+what is involved and describes related tasks for setting up nodes.
+ -->
+你需要在集群内每个节点上安装一个 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}
+以使 Pod 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。
 
 <!-- body -->
 
-{{< caution >}}
-<!--
-A flaw was found in the way runc handled system file descriptors when running containers.
-A malicious container could use this flaw to overwrite contents of the runc binary and
-consequently run arbitrary commands on the container host system.
+<!-- 
+This page lists details for using several common container runtimes with
+Kubernetes, on Linux:
+ -->
+本文列出了在 Linux 上结合 Kubernetes 使用的几种通用容器运行时的详细信息： 
 
-Please refer to this link for more information about this issue
-[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
--->
-我们发现 runc 在运行容器，处理系统文件描述符时存在一个漏洞。
-恶意容器可以利用此漏洞覆盖 runc 二进制文件的内容，并以此在主机系统的容器上运行任意的命令。
-
-请参考此链接以获取有关此问题的更多信息 [cve-2019-5736 : runc vulnerability ](https://access.redhat.com/security/cve/cve-2019-5736)
-{{< /caution >}}
-
-<!--
-### Applicability
--->
-### 适用性
+- [containerd](#containerd)
+- [CRI-O](#cri-o)
+- [Docker](#docker)
 
+<!-- 
 {{< note >}}
-<!--
-This document is written for users installing CRI onto Linux. For other operating
-systems, look for documentation specific to your platform
--->
-本文档是为在 Linux 上安装 CRI 的用户编写的。
-对于其他操作系统，请查找特定于您平台的文档。
+For other operating systems, look for documentation specific to your platform.
 {{< /note >}}
+ -->
+提示：对于其他操作系统，请查阅特定于你所使用平台的相关文档。
 
 <!--
-You should execute all the commands in this guide as `root`. For example, prefix commands
-with `sudo `, or become `root` and run the commands as that user.
+## Cgroup drivers
 -->
-您应该以 `root` 身份执行本指南中的所有命令。
-例如，使用 `sudo` 前缀命令，或者成为 `root` 并以该用户身份运行命令。
-
-<!--
-### Cgroup drivers
--->
-### Cgroup 驱动程序
-
-<!--
-When systemd is chosen as the init system for a Linux distribution, the init process generates
-and consumes a root control group (`cgroup`) and acts as a cgroup manager. Systemd has a tight
-integration with cgroups and will allocate cgroups per process. It's possible to configure your
-container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside systemd means
-that there will then be two different cgroup managers.
--->
-当某个 Linux 系统发行版使用 systemd 作为其初始化系统时，初始化进程会生成并使用一个 root 控制组 （`cgroup`），并充当 cgroup 管理器。
-systemd 与 cgroup 集成紧密，并将为每个进程分配 cgroup。
-您也可以配置容器运行时和 kubelet 使用 `cgroupfs`。
-连同 systemd 一起使用 `cgroupfs` 意味着将有两个不同的 cgroup 管理器。
+## Cgroup 驱动程序
 
 <!--
 Control groups are used to constrain resources that are allocated to processes.
-A single cgroup manager will simplify the view of what resources are being allocated
-and will by default have a more consistent view of the available and in-use resources. When we have
-two managers we end up with two views of those resources. We have seen cases in the field
-where nodes that are configured to use `cgroupfs` for the kubelet and Docker, and `systemd`
-for the rest of the processes running on the node becomes unstable under resource pressure.
+
+When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init
+system for a Linux distribution, the init process generates and consumes a root control group
+(`cgroup`) and acts as a cgroup manager.
+Systemd has a tight integration with cgroups and allocates a cgroup per systemd unit. It's possible
+to configure your container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside
+systemd means that there will be two different cgroup managers.
 -->
 控制组用来约束分配给进程的资源。
+
+当某个 Linux 系统发行版使用 [systemd](https://www.freedesktop.org/wiki/Software/systemd/) 作为其初始化系统时，初始化进程会生成并使用一个 root 控制组 (`cgroup`), 并充当 cgroup 管理器。
+Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup。
+你也可以配置容器运行时和 kubelet 使用 `cgroupfs`。
+连同 systemd 一起使用 `cgroupfs` 意味着将有两个不同的 cgroup 管理器。
+
+<!--
+A single cgroup manager simplifies the view of what resources are being allocated
+and will by default have a more consistent view of the available and in-use resources.
+When there are two cgroup managers on a system, you end up with two views of those resources.
+In the field, people have reported cases where nodes that are configured to use `cgroupfs`
+for the kubelet and Docker, but `systemd` for the rest of the processes, become unstable under
+resource pressure.
+-->
 单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用中的资源具有更一致的视图。
-当有两个管理器时，最终将对这些资源产生两种视图。
-在此领域我们已经看到案例，某些节点配置让 kubelet 和 docker 使用 `cgroupfs`，而节点上运行的其余进程则使用 systemd；这类节点在资源压力下会变得不稳定。
+当有两个管理器共存于一个系统中时，最终将对这些资源产生两种视图。
+在此领域人们已经报告过一些案例，某些节点配置让 kubelet 和 docker 使用 `cgroupfs`，而节点上运行的其余进程则使用 systemd; 这类节点在资源压力下会变得不稳定。
 
 <!--
 Changing the settings such that your container runtime and kubelet use `systemd` as the cgroup driver
-stabilized the system. Please note the `native.cgroupdriver=systemd` option in the Docker setup below.
+stabilized the system. To configure this for Docker, set `native.cgroupdriver=systemd`.
 -->
 更改设置，令容器运行时和 kubelet 使用 `systemd` 作为 cgroup 驱动，以此使系统更为稳定。
-请注意在 docker  下设置 `native.cgroupdriver=systemd` 选项。
+对于 Docker, 设置 `native.cgroupdriver=systemd` 选项。
 
+<!--
 {{< caution >}}
-<!--
-Changing the cgroup driver of a Node that has joined a cluster is highly unrecommended.
+Changing the cgroup driver of a Node that has joined a cluster is strongly *not* recommended.  
 If the kubelet has created Pods using the semantics of one cgroup driver, changing the container
-runtime to another cgroup driver can cause errors when trying to re-create the PodSandbox
-for such existing Pods. Restarting the kubelet may not solve such errors. The recommendation
-is to drain the Node from its workloads, remove it from the cluster and re-join it.
--->
-强烈建议不要更改已加入集群的节点的 cgroup 驱动。
-如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，尝试更改运行时以使用别的 cgroup 驱动，为现有 Pods 重新创建 PodSandbox 时会产生错误。
-重启 kubelet 也可能无法解决此类问题。
-推荐将工作负载逐出节点，之后将节点从集群中删除并重新加入。
+runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox
+for such existing Pods. Restarting the kubelet may not solve such errors.
+
+If you have automation that makes it feasible, replace the node with another using the updated
+configuration, or reinstall it using automation.
 {{< /caution >}}
-
-<!--
-## Docker
-
-On each of your machines, install Docker.
-Version 19.03.4 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well.
-Keep track of the latest verified Docker version in the Kubernetes release notes.
-
-Use the following commands to install Docker on your system:
 -->
-## Docker
+注意：非常 *不* 建议更改已加入集群的节点的 cgroup 驱动。
+如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。重启 kubelet 也可能无法解决此类问题。
+如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点，或者使用自动化方案来重新安装。
 
-在您的每台机器上安装 Docker。
-推荐安装 19.03.4 版本，但是 1.13.1、17.03、17.06、17.09、18.06 和 18.09 版本也是可以的。
-请跟踪 Kubernetes 发行说明中经过验证的 Docker 最新版本变化。
+<!-- 
+## Container runtimes
+ -->
+## 容器运行时
 
-使用以下命令在您的系统上安装 Docker：
+{{% thirdparty-content %}}
 
-{{< tabs name="tab-cri-docker-installation" >}}
-{{% tab name="Ubuntu 16.04+" %}}
+### containerd
 
 <!--
-# Install Docker CE
-## Set up the repository:
+This section contains the necessary steps to use `containerd` as CRI runtime.
+
+Use the following commands to install Containerd on your system:
+
+Install and configure prerequisites:
+
+```shell
+cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
+overlay
+br_netfilter
+EOF
+
+sudo modprobe overlay
+sudo modprobe br_netfilter
+
+# Setup required sysctl params, these persist across reboots.
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
+net.bridge.bridge-nf-call-iptables  = 1
+net.ipv4.ip_forward                 = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+EOF
+
+# Apply sysctl params without reboot
+sudo sysctl --system
+```
+-->
+本节包含使用 `containerd` 作为 CRI 运行时的必要步骤。
+
+使用以下命令在系统上安装容器：
+
+安装和配置的先决条件：
+
+```shell
+cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
+overlay
+br_netfilter
+EOF
+
+sudo modprobe overlay
+sudo modprobe br_netfilter
+
+# 设置必需的 sysctl 参数，这些参数在重新启动后仍然存在。
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
+net.bridge.bridge-nf-call-iptables  = 1
+net.ipv4.ip_forward                 = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+EOF
+
+# Apply sysctl params without reboot
+sudo sysctl --system
+```
+
+<!--
+Install containerd:
+-->
+安装 containerd:
+
+{{< tabs name="tab-cri-containerd-installation" >}}
+{{% tab name="Ubuntu 16.04" %}}
+
+<!--
+```shell
+# (Install containerd)
+## Set up the repository
 ### Install packages to allow apt to use a repository over HTTPS
-apt-get update && apt-get install \
-  apt-transport-https ca-certificates curl software-properties-common
-
-### Add Docker’s official GPG key
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
--->
-
-```shell
-# 安装 Docker CE
-## 设置仓库
-### 安装软件包以允许 apt 通过 HTTPS 使用存储库
-apt-get update && apt-get install \
-  apt-transport-https ca-certificates curl software-properties-common
+sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
 ```
 
 ```shell
-### 新增 Docker 的 官方 GPG 秘钥
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+## Add Docker's official GPG key
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
 ```
-<!--
-### Add Docker apt repository.
-add-apt-repository \
-  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-  $(lsb_release -cs) \
-  stable"
 
-## Install Docker CE.
-apt-get update && apt-get install \
-  containerd.io=1.2.10-3 \
-  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
+```shell
+## Add Docker apt repository.
+sudo add-apt-repository \
+    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+    $(lsb_release -cs) \
+    stable"
+```
 
-# Setup daemon.
-cat > /etc/docker/daemon.json <<EOF
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2"
-}
-EOF
+```shell
+## Install containerd
+sudo apt-get update && sudo apt-get install -y containerd.io
+```
 
-mkdir -p /etc/systemd/system/docker.service.d
+```shell
+# Configure containerd
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
+```
+
+```shell
+# Restart containerd
+sudo systemctl restart containerd
+```
 -->
 ```shell
-### 添加 Docker apt 仓库
-add-apt-repository \
-  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-  $(lsb_release -cs) \
-  stable"
+# (安装 containerd)
+## (设置仓库)
+### (安装软件包以允许 apt 通过 HTTPS 使用存储库)
+sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
 ```
 
 ```shell
-## 安装 Docker CE
-apt-get update && apt-get install -y\
-  containerd.io=1.2.13-2 \
-  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+## 安装 Docker 的官方 GPG 密钥
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
 ```
 
 ```shell
-# 设置 daemon
-cat > /etc/docker/daemon.json <<EOF
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2"
-}
-EOF
+## 新增 Docker apt 仓库。
+sudo add-apt-repository \
+    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+    $(lsb_release -cs) \
+    stable"
 ```
 
 ```shell
-mkdir -p /etc/systemd/system/docker.service.d
+## 安装 containerd
+sudo apt-get update && sudo apt-get install -y containerd.io
 ```
-<!--
-# Restart docker.
-systemctl daemon-reload
-systemctl restart docker
--->
+
 ```shell
-# 重启 docker.
-systemctl daemon-reload
-systemctl restart docker
+# 配置 containerd
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
 ```
-{{% /tab %}}
+
+```shell
+# 重启 containerd
+sudo systemctl restart containerd
+```
+{{< /tab >}}
 {{% tab name="CentOS/RHEL 7.4+" %}}
 
 <!--
-# Install Docker CE
+```shell
+# (Install containerd)
 ## Set up the repository
-### Install required packages.
-yum install yum-utils device-mapper-persistent-data lvm2
+### Install required packages
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
+```
 
-### Add Docker repository.
-yum-config-manager \
+```shell
+## Add docker repository
+sudo yum-config-manager \
     --add-repo \
     https://download.docker.com/linux/centos/docker-ce.repo
+```
 
-## Install Docker CE.
-yum update && yum install \
-  containerd.io-1.2.10 \
-  docker-ce-19.03.4 \
-  docker-ce-cli-19.03.4
-
-## Create /etc/docker directory.
-mkdir /etc/docker
-
-# Setup daemon.
-cat > /etc/docker/daemon.json <<EOF
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2",
-  "storage-opts": [
-    "overlay2.override_kernel_check=true"
-  ]
-}
-EOF
-
-mkdir -p /etc/systemd/system/docker.service.d
--->
 ```shell
-# 安装 Docker CE
+## Install containerd
+sudo yum update -y && sudo yum install -y containerd.io
+```
+
+```shell
+## Configure containerd
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
+```
+
+```shell
+# Restart containerd
+sudo systemctl restart containerd
+```
+-->
+
+```shell
+# 安装 containerd
 ## 设置仓库
 ### 安装所需包
-yum install yum-utils device-mapper-persistent-data lvm2
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
 ```
 
 ```shell
-### 新增 Docker 仓库。
-yum-config-manager \
-  --add-repo \
-  https://download.docker.com/linux/centos/docker-ce.repo
+### 新增 Docker 仓库
+sudo yum-config-manager \
+    --add-repo \
+    https://download.docker.com/linux/centos/docker-ce.repo
 ```
 
 ```shell
-## 安装 Docker CE.
-yum update && yum install docker-ce-18.06.2.ce
+## 安装 containerd
+sudo yum update -y && sudo yum install -y containerd.io
 ```
 
 ```shell
-## 创建 /etc/docker 目录。
-mkdir /etc/docker
+# 配置 containerd
+sudo mkdir -p /etc/containerd
+sudo containerd config default > /etc/containerd/config.toml
 ```
 
 ```shell
-# 设置 daemon。
-cat > /etc/docker/daemon.json <<EOF
-{
-  "exec-opts": ["native.cgroupdriver=systemd"],
-  "log-driver": "json-file",
-  "log-opts": {
-    "max-size": "100m"
-  },
-  "storage-driver": "overlay2",
-  "storage-opts": [
-    "overlay2.override_kernel_check=true"
-  ]
-}
-EOF
-```
-
-```shell
-mkdir -p /etc/systemd/system/docker.service.d
-```
-<!--
-# Restart Docker
-systemctl daemon-reload
-systemctl restart docker
--->
-```shell
-# 重启 Docker
-systemctl daemon-reload
-systemctl restart docker
+# 重启 containerd
+sudo systemctl restart containerd
 ```
 {{% /tab %}}
-{{% /tabs %}}
-
-<!--
-If you want the docker service to start on boot, run the following command:
-
-```shell
-sudo systemctl enable docker
-```
--->
-
-如果你想开机即启动 docker 服务，执行以下命令：
-
-```shell
-sudo systemctl enable docker
+{{% tab name="Windows (PowerShell)" %}}
+<!-- 
+```powershell
+# (Install containerd)
+# download containerd
+cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz
+cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz
 ```
 
-<!--
-Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
-for more information.
+```powershell
+# extract and configure
+Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
+cd $Env:ProgramFiles\containerd\
+.\containerd.exe config default | Out-File config.toml -Encoding ascii
+
+# review the configuration. depending on setup you may want to adjust:
+# - the sandbox_image (kubernetes pause image)
+# - cni bin_dir and conf_dir locations
+Get-Content config.toml
+```
+
+```powershell
+# start containerd
+.\containerd.exe --register-service
+Start-Service containerd
+```
+ -->
+```powershell
+# （安装 containerd ）
+# 下载 contianerd
+cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz
+cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz
+```
+
+```powershell
+# 解压并配置
+Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
+cd $Env:ProgramFiles\containerd\
+.\containerd.exe config default | Out-File config.toml -Encoding ascii
+
+# 检查配置文件，基于你可能想要调整的设置：
+# - sandbox_image (kubernetes pause 镜像)
+# - CNI 的 bin_dir 和 conf_dir 路径
+Get-Content config.toml
+```
+
+```powershell
+# 启动 containerd
+.\containerd.exe --register-service
+Start-Service containerd
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+#### systemd {#containerd-systemd}
+
+<!-- 
+To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
+
+```
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
+  ...
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
+    SystemdCgroup = true
+```
+
+When using kubeadm, manually configure the
+[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
 -->
+结合 `runc` 使用 `systemd` cgroup 驱动，在 `/etc/containerd/config.toml` 中设置 
 
-请参阅[官方 Docker 安装指南](https://docs.docker.com/engine/installation/)
-来获取更多的信息。
+```
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
+  ...
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
+    SystemdCgroup = true
+```
+
+当使用 kubeadm 时，请手动配置
+[kubelet 的 cgroup 驱动](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
+
+### CRI-O
 
 <!--
-## CRI-O
-
-This section contains the necessary steps to install `CRI-O` as CRI runtime.
+This section contains the necessary steps to install CRI-O as a container runtime.
 
 Use the following commands to install CRI-O on your system:
 
-### Prerequisites
+{{< note >}}
+The CRI-O major and minor versions must match the Kubernetes major and minor versions.
+For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o).
+{{< /note >}}
+
+Install and configure prerequisites:
 
 ```shell
-modprobe overlay
-modprobe br_netfilter
+sudo modprobe overlay
+sudo modprobe br_netfilter
 
-# Setup required sysctl params, these persist across reboots.
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+# Set up required sysctl params, these persist across reboots.
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
 net.bridge.bridge-nf-call-iptables  = 1
 net.ipv4.ip_forward                 = 1
 net.bridge.bridge-nf-call-ip6tables = 1
 EOF
 
-sysctl --system
+sudo sysctl --system
 ```
 -->
-## CRI-O
-
-本节包含安装 `CRI-O` 作为 CRI 运行时的必要步骤。
+本节包含安装 CRI-O 作为容器运行时的必要步骤。
 
 使用以下命令在系统中安装 CRI-O：
 
-### 准备环境
+提示：CRI-O 的主要以及次要版本必须与 Kubernetes 的主要和次要版本相匹配。
+更多信息请查阅 [CRI-O 兼容性列表](https://github.com/cri-o/cri-o).
+
+安装以及配置的先决条件：
 
 ```shell
-modprobe overlay
-modprobe br_netfilter
+sudo modprobe overlay
+sudo modprobe br_netfilter
 
-# 设置必需的sysctl参数，这些参数在重新启动后仍然存在。
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+# 设置必需的 sysctl 参数，这些参数在重新启动后仍然存在。
+cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
 net.bridge.bridge-nf-call-iptables  = 1
 net.ipv4.ip_forward                 = 1
 net.bridge.bridge-nf-call-ip6tables = 1
 EOF
 
-sysctl --system
+sudo sysctl --system
 ```
 
 {{< tabs name="tab-cri-cri-o-installation" >}}
 {{% tab name="Debian" %}}
 
-<!--
+<!-- 
+To install CRI-O on the following operating systems, set the environment variable `OS`
+to the appropriate value from the following table:
+
+| Operating system | `$OS`             |
+|------------------|-------------------|
+| Debian Unstable  | `Debian_Unstable` |
+| Debian Testing   | `Debian_Testing`  |
+
+<br />
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+<br />
+
+Then run
+ -->
+在下列操作系统上安装 CRI-O, 使用下表中合适的值设置环境变量 `OS`:
+
+| 操作系统         | `$OS`             |
+|-----------------|-------------------|
+| Debian Unstable | `Debian_Unstable` |
+| Debian Testing  | `Debian_Testing`  |
+
+<br />
+然后，将 `$VERSION` 设置为与你的 Kubernetes 相匹配的 CRI-O 版本。
+例如，如果你要安装 CRI-O 1.18, 请设置 `VERSION=1.18`.
+你也可以安装一个特定的发行版本。
+例如要安装 1.18.3 版本，设置 `VERSION=1.18:1.18.3`.
+<br />
+
+然后执行
 ```shell
-# Debian Unstable/Sid
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
-```
--->
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
+EOF
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
+EOF
 
-```shell
-# Debian Unstable/Sid
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
-```
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg -
 
-<!--
-```shell
-# Debian Testing
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
-```
--->
-
-```shell
-# Debian Testing
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
-```
-
-<!--
-```shell
-# Debian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
-```
--->
-
-```shell
-# Debian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
-```
-
-<!--
-```shell
-# Raspbian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
-```
--->
-
-```shell
-# Raspbian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
-```
-
-<!--
-and then install CRI-O:
-```shell
-sudo apt-get install cri-o-1.17
-```
--->
-
-随后安装 CRI-O:
-
-```shell
-sudo apt-get install cri-o-1.17
-```
-
-{{% /tab %}}
-
-{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}
-
-<!--
-```shell
-# Configure package repository
-. /etc/os-release
-sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
 sudo apt-get update
+sudo apt-get install cri-o cri-o-runc
 ```
--->
 
+{{% /tab %}}
+
+{{% tab name="Ubuntu" %}}
+
+<!-- 
+To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table:
+
+| Operating system | `$OS`           |
+|------------------|-----------------|
+| Ubuntu 20.04     | `xUbuntu_20.04` |
+| Ubuntu 19.10     | `xUbuntu_19.10` |
+| Ubuntu 19.04     | `xUbuntu_19.04` |
+| Ubuntu 18.04     | `xUbuntu_18.04` |
+
+<br />
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+<br />
+
+Then run
+ -->
+在下列操作系统上安装 CRI-O, 使用下表中合适的值设置环境变量 `OS`:
+
+| 操作系统      | `$OS`           |
+|--------------|-----------------|
+| Ubuntu 20.04 | `xUbuntu_20.04` |
+| Ubuntu 19.10 | `xUbuntu_19.10` |
+| Ubuntu 19.04 | `xUbuntu_19.04` |
+| Ubuntu 18.04 | `xUbuntu_18.04` |
+
+<br />
+然后，将 `$VERSION` 设置为与你的 Kubernetes 相匹配的 CRI-O 版本。
+例如，如果你要安装 CRI-O 1.18, 请设置 `VERSION=1.18`.
+你也可以安装一个特定的发行版本。
+例如要安装 1.18.3 版本，设置 `VERSION=1.18:1.18.3`.
+<br />
+
+然后执行
 ```shell
-# 配置仓库
-. /etc/os-release
-sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
+EOF
+cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
+EOF
+
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg -
+
 sudo apt-get update
+sudo apt-get install cri-o cri-o-runc
 ```
-
-<!--
-```shell
-# Install CRI-O
-sudo apt-get install cri-o-1.17
-```
--->
-
-```shell
-# 安装 CRI-O
-sudo apt-get install cri-o-1.17
-```
+ 
 {{% /tab %}}
 
-{{% tab name="Ubuntu 16.04" %}}
+{{% tab name="CentOS" %}}
 
-<!--
-# Install prerequisites
-apt-get update
-apt-get install software-properties-common
+<!-- 
+To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table:
 
-add-apt-repository ppa:projectatomic/ppa
-apt-get update
+| Operating system | `$OS`             |
+|------------------|-------------------|
+| Centos 8         | `CentOS_8`        |
+| Centos 8 Stream  | `CentOS_8_Stream` |
+| Centos 7         | `CentOS_7`        |
 
-# Install CRI-O
-apt-get install cri-o-1.15
+<br />
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+<br />
+
+Then run
 -->
+在下列操作系统上安装 CRI-O, 使用下表中合适的值设置环境变量 `OS`:
+
+| 操作系统         | `$OS`             |
+|-----------------|-------------------|
+| Centos 8        | `CentOS_8`        |
+| Centos 8 Stream | `CentOS_8_Stream` |
+| Centos 7        | `CentOS_7`        |
+
+<br />
+然后，将 `$VERSION` 设置为与你的 Kubernetes 相匹配的 CRI-O 版本。
+例如，如果你要安装 CRI-O 1.18, 请设置 `VERSION=1.18`.
+你也可以安装一个特定的发行版本。
+例如要安装 1.18.3 版本，设置 `VERSION=1.18:1.18.3`.
+<br />
+
+然后执行
 ```shell
-# 安装必备软件
-apt-get update
-apt-get install software-properties-common
-
-add-apt-repository ppa:projectatomic/ppa
-apt-get update
-
-# 安装 CRI-O
-apt-get install cri-o-1.15
-```
-{{% /tab %}}
-{{% tab name="CentOS/RHEL 7.4+" codelang="bash" %}}
-
-<!--
-# Install prerequisites
-yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
-
-# Install CRI-O
-yum install --nogpgcheck cri-o
--->
-
-```shell
-# 安装必备软件
-yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
-```
-
-```shell
-# 安装 CRI-O
-yum install --nogpgcheck cri-o
+sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
+sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
+sudo yum install cri-o
 ```
 
 {{% /tab %}}
@@ -553,251 +598,315 @@ yum install --nogpgcheck cri-o
 sudo zypper install cri-o
 ```
 {{% /tab %}}
+{{% tab name="Fedora" %}}
 
+<!-- 
+Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, `VERSION=1.18`.
+
+You can find available versions with:
+```shell
+sudo dnf module list cri-o
+```
+CRI-O does not support pinning to specific releases on Fedora.
+
+Then run
+```shell
+sudo dnf module enable cri-o:$VERSION
+sudo dnf install cri-o
+```
+-->
+将 `$VERSION` 设置为与你的 Kubernetes 相匹配的 CRI-O 版本。
+例如，如果要安装 CRI-O 1.18，请设置 `VERSION=1.18`。
+你可以用下列命令查找可用的版本：
+
+```shell
+sudo dnf module list cri-o
+```
+CRI-O 不支持在 Fedora 上固定到特定的版本。
+
+然后执行
+```shell
+sudo dnf module enable cri-o:$VERSION
+sudo dnf install cri-o
+```
+
+{{% /tab %}}
 {{< /tabs >}}
 
-<!--
-### Start CRI-O
+<!-- 
+Start CRI-O:
 
-```
-systemctl daemon-reload
-systemctl start crio
+```shell
+sudo systemctl daemon-reload
+sudo systemctl start crio
 ```
 
 Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started)
 for more information.
--->
-### 启动 CRI-O
-
-```
-systemctl start crio
-```
-
-请参阅 [CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started)
-来获取更多的信息。
-
-<!--
-## Containerd
-
-This section contains the necessary steps to use `containerd` as CRI runtime.
-
-Use the following commands to install Containerd on your system:
-
-### Prerequisites
+ -->
+启动 CRI-O:
 
 ```shell
-cat > /etc/modules-load.d/containerd.conf <<EOF
-overlay
-br_netfilter
-EOF
-
-modprobe overlay
-modprobe br_netfilter
-
-# Setup required sysctl params, these persist across reboots.
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
-net.bridge.bridge-nf-call-iptables  = 1
-net.ipv4.ip_forward                 = 1
-net.bridge.bridge-nf-call-ip6tables = 1
-EOF
-
-sysctl --system
-```
--->
-## containerd
-
-本节包含使用 `containerd` 作为 CRI 运行时的必要步骤。
-
-使用以下命令在系统上安装容器：
-
-### 准备环境
-
-```shell
-cat > /etc/modules-load.d/containerd.conf <<EOF
-overlay
-br_netfilter
-EOF
-
-modprobe overlay
-modprobe br_netfilter
-
-# 设置必需的sysctl参数，这些参数在重新启动后仍然存在。
-cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
-net.bridge.bridge-nf-call-iptables  = 1
-net.ipv4.ip_forward                 = 1
-net.bridge.bridge-nf-call-ip6tables = 1
-EOF
-
-sysctl --system
+sudo systemctl daemon-reload
+sudo systemctl start crio
 ```
 
-<!--
-### Install containerd
--->
-### 安装 containerd
+更多信息请参阅 [CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started)。
+
+
+
+### Docker
+
+<!-- 
+On each of your nodes, install Docker CE.
+
+The Kubernetes release notes list which versions of Docker are compatible
+with that version of Kubernetes.
+
+Use the following commands to install Docker on your system:
+ -->
+在你每个节点上安装 Docker CE.
+
+Kubernetes 发行说明中列出了 Docker 的哪些版本与该版本的 Kubernetes 相兼容。
+
+在你的操作系统上使用如下命令安装 Docker:
+
+{{< tabs name="tab-cri-docker-installation" >}}
+{{% tab name="Ubuntu 16.04+" %}}
 
-{{< tabs name="tab-cri-containerd-installation" >}}
-{{% tab name="Ubuntu 16.04" %}}
 <!--
 ```shell
-# Install containerd
-## Set up the repository
+# (Install Docker CE)
+## Set up the repository:
 ### Install packages to allow apt to use a repository over HTTPS
-apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+sudo apt-get update && sudo apt-get install -y \
+  apt-transport-https ca-certificates curl software-properties-common gnupg2
 ```
 
 ```shell
-### Add Docker’s official GPG key
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-```
-
-```shell
-### Add Docker apt repository.
-add-apt-repository \
-    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-    $(lsb_release -cs) \
-    stable"
-```
-
-```shell
-## Install containerd
-apt-get update && apt-get install -y containerd.io
-```
-
-```shell
-# Configure containerd
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+# Add Docker's official GPG key:
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/docker.gpg -
 ```
 -->
 
 ```shell
-# 安装 containerd
-## 设置仓库
+# (安装 Docker CE)
+## 设置仓库:
 ### 安装软件包以允许 apt 通过 HTTPS 使用存储库
-apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+sudo apt-get update && sudo apt-get install -y \
+  apt-transport-https ca-certificates curl software-properties-common gnupg2
 ```
 
 ```shell
-### 安装 Docker 的官方 GPG 密钥
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-```
-
-```shell
-### 新增 Docker apt 仓库。
-add-apt-repository \
-    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-    $(lsb_release -cs) \
-    stable"
-```
-
-```shell
-## 安装 containerd
-apt-get update && apt-get install -y containerd.io
-```
-
-```shell
-# 配置 containerd
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+### 新增 Docker 的 官方 GPG 秘钥:
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/docker.gpg -
 ```
 
 <!--
 ```shell
-# Restart containerd
-systemctl restart containerd
+# Add the Docker apt repository:
+sudo add-apt-repository \
+  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+  $(lsb_release -cs) \
+  stable"
+```
+
+```shell
+# Install Docker CE
+sudo apt-get update && sudo apt-get install -y \
+  containerd.io=1.2.13-2 \
+  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+```
+
+```shell
+# Set up the Docker daemon
+cat <<EOF | sudo tee /etc/docker/daemon.json
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2"
+}
+EOF
+```
+
+```shell
+# Create /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
 ```
 -->
 ```shell
-# 重启 containerd
-systemctl restart containerd
+### 添加 Docker apt 仓库:
+sudo add-apt-repository \
+  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+  $(lsb_release -cs) \
+  stable"
 ```
-{{< /tab >}}
+
+```shell
+## 安装 Docker CE
+sudo apt-get update && sudo apt-get install -y \
+  containerd.io=1.2.13-2 \
+  docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+  docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+```
+
+```shell
+# 设置 Docker daemon
+cat <<EOF | sudo tee /etc/docker/daemon.json
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2"
+}
+EOF
+```
+
+```shell
+# Create /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
+```
+<!--
+# Restart docker.
+systemctl daemon-reload
+systemctl restart docker
+-->
+```shell
+# 重启 docker.
+sudo systemctl daemon-reload
+sudo systemctl restart docker
+```
+{{% /tab %}}
 {{% tab name="CentOS/RHEL 7.4+" %}}
+
 <!--
 ```shell
-# Install containerd
+# (Install Docker CE)
 ## Set up the repository
 ### Install required packages
-yum install yum-utils device-mapper-persistent-data lvm2
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
 ```
 
 ```shell
-### Add docker repository
-yum-config-manager \
-    --add-repo \
-    https://download.docker.com/linux/centos/docker-ce.repo
+## Add the Docker repository
+sudo yum-config-manager --add-repo \
+  https://download.docker.com/linux/centos/docker-ce.repo
 ```
 
 ```shell
-## Install containerd
-yum update && yum install containerd.io
+# Install Docker CE
+sudo yum update -y && sudo yum install -y \
+  containerd.io-1.2.13 \
+  docker-ce-19.03.11 \
+  docker-ce-cli-19.03.11
 ```
 
 ```shell
-# Configure containerd
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+## Create /etc/docker
+sudo mkdir /etc/docker
+```
+
+```shell
+# Set up the Docker daemon
+cat <<EOF | sudo tee /etc/docker/daemon.json
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2",
+  "storage-opts": [
+    "overlay2.override_kernel_check=true"
+  ]
+}
+EOF
+```
+
+```shell
+# Create /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
 ```
 -->
-
 ```shell
-# 安装 containerd
+# (安装 Docker CE)
 ## 设置仓库
 ### 安装所需包
-yum install yum-utils device-mapper-persistent-data lvm2
+sudo yum install -y yum-utils device-mapper-persistent-data lvm2
 ```
 
 ```shell
 ### 新增 Docker 仓库
-yum-config-manager \
-    --add-repo \
-    https://download.docker.com/linux/centos/docker-ce.repo
+sudo yum-config-manager --add-repo \
+  https://download.docker.com/linux/centos/docker-ce.repo
 ```
 
 ```shell
-## 安装 containerd
-yum update && yum install containerd.io
+## 安装 Docker CE
+sudo yum update -y && sudo yum install -y \
+  containerd.io-1.2.13 \
+  docker-ce-19.03.11 \
+  docker-ce-cli-19.03.11
 ```
 
 ```shell
-# 配置 containerd
-mkdir -p /etc/containerd
-containerd config default > /etc/containerd/config.toml
+## 创建 /etc/docker 目录
+sudo mkdir /etc/docker
+```
+
+```shell
+# 设置 Docker daemon
+cat <<EOF | sudo tee /etc/docker/daemon.json
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2",
+  "storage-opts": [
+    "overlay2.override_kernel_check=true"
+  ]
+}
+EOF
+```
+
+```shell
+# Create /etc/systemd/system/docker.service.d
+sudo mkdir -p /etc/systemd/system/docker.service.d
 ```
 <!--
-```shell
-# Restart containerd
-systemctl restart containerd
-```
+# Restart Docker
+systemctl daemon-reload
+systemctl restart docker
 -->
-
 ```shell
-# 重启 containerd
-systemctl restart containerd
+# 重启 Docker
+sudo systemctl daemon-reload
+sudo systemctl restart docker
 ```
 {{% /tab %}}
-{{< /tabs >}}
+{{% /tabs %}}
 
 <!--
-```shell
-### systemd
-
-To use the `systemd` cgroup driver, set `plugins.cri.systemd_cgroup = true` in `/etc/containerd/config.toml`.
-When using kubeadm, manually configure the
-[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
-
-## Other CRI runtimes: frakti
-
-Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information.
-```
+If you want the docker service to start on boot, run the following command:
 -->
-### systemd
+如果你想开机即启动 docker 服务，执行以下命令：
 
-使用 `systemd` cgroup 驱动，在 `/etc/containerd/config.toml` 中设置 `plugins.cri.systemd_cgroup = true`。
-当使用 kubeadm 时，请手动配置
-[kubelet 的 cgroup 驱动](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+```shell
+sudo systemctl enable docker
+```
 
-## 其他的 CRI 运行时：frakti
-
-请参阅 [Frakti 快速开始指南](https://github.com/kubernetes/frakti#quickstart) 来获取更多的信息。
+<!--
+Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
+for more information.
+-->
+请参阅 [官方 Docker 安装指南](https://docs.docker.com/engine/installation/)
+来获取更多的信息。
\ No newline at end of file
diff --git a/content/zh/docs/setup/production-environment/on-premises-vm/_index.md b/content/zh/docs/setup/production-environment/on-premises-vm/_index.md
deleted file mode 100644
index 13f3c62ce0..0000000000
--- a/content/zh/docs/setup/production-environment/on-premises-vm/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: 本地 VMs
-weight: 40
----
diff --git a/content/zh/docs/setup/production-environment/on-premises-vm/dcos.md b/content/zh/docs/setup/production-environment/on-premises-vm/dcos.md
deleted file mode 100644
index 563701695c..0000000000
--- a/content/zh/docs/setup/production-environment/on-premises-vm/dcos.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-reviewers:
-- smugcloud
-title: DC/OS 上的 Kubernetes
-content_type: concept
----
-<!--
----
-reviewers:
-- smugcloud
-title: Kubernetes on DC/OS
-content_type: concept
----
--->
-
-<!-- overview -->
-
-<!--
-Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https://mesosphere.com/product/), offering:
--->
-Mesosphere 提供了一个简单的选项来将 Kubernetes 设置到[DC/OS](https://mesosphere.com/product/)上，它提供：
-
-<!--
-* Pure upstream Kubernetes
-* Single-click cluster provisioning
-* Highly available and secure by default
-* Kubernetes running alongside fast-data platforms (e.g. Akka, Cassandra, Kafka, Spark)
--->
-* 纯上游 Kubernetes
-* 集群一键部署
-* 默认情况下高度可用且安全
-* 与快速数据平台 (例如 Akka、Cassandra、Kafka、Spark) 一起运行的 Kubernetes
-
-
-
-<!-- body -->
-
-<!--
-## Official Mesosphere Guide
--->
-## Mesosphere 官方指南
-
-<!--
-The canonical source of getting started on DC/OS is located in the [quickstart repo](https://github.com/mesosphere/dcos-kubernetes-quickstart).
--->
-DC/OS 入门的正式来源位于[quickstart 仓库](https://github.com/mesosphere/dcos-kubernetes-quickstart)中。
-
-
diff --git a/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md b/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md
deleted file mode 100644
index ea8790f452..0000000000
--- a/content/zh/docs/setup/production-environment/on-premises-vm/ovirt.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: oVirt
-content_type: concept
----
-<!--
----
-reviewers:
-- caesarxuchao
-- erictune
-title: oVirt
-content_type: concept
----
--->
-
-<!-- overview -->
-
-<!--
-oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
--->
-oVirt 是一个虚拟数据中心管理器，可以对多个主机上的多个虚拟机进行强大的管理。
-使用 KVM 和 libvirt ，可以将 oVirt 安装在 Fedora、CentOS 或者 Red Hat Enterprise Linux 主机上，以部署和管理您的虚拟数据中心。
-
-
-
-<!-- body -->
-
-<!--
-## oVirt Cloud Provider Deployment
--->
-## oVirt 云驱动的部署
-
-<!--
-The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your Kubernetes cluster.
-At the moment there are no community-supported or pre-loaded VM images including Kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes Kubernetes may work as well.
--->
-oVirt 云驱动可以轻松发现新 VM 实例并自动将其添加为 Kubernetes 集群的节点。
-目前，包括 Kubernetes 在内，尚无社区支持或预加载的 VM 镜像，但可以在 VM 中 [导入] 或 [安装] Project Atomic（或 Fedora）来 [生成模版]。
-包括 Kubernetes 的任何其他 Linux 发行版也可能可行。
-
-<!--
-It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to Kubernetes.
--->
-必须在寄宿系统中 [安装 ovirt-guest-agent]，才能将 VM 的 IP 地址和主机名报给 ovirt-engine 并最终报告给 Kubernetes。
-
-<!--
-Once the Kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider.
--->
-一旦 Kubernetes 模版可用，就可以开始创建可由云驱动发现的 VM。
-
-<!--
-[import]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
-[install]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
-[generate a template]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
-[install the ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
--->
-[导入]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
-[安装]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
-[生成模版]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
-[安装 ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
-
-<!--
-## Using the oVirt Cloud Provider
--->
-## 使用 oVirt 云驱动
-
-<!--
-The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file:
--->
-oVirt 云驱动需要访问 oVirt REST-API 来收集正确的信息，所需的凭据应在 `ovirt-cloud.conf` 文件中设定：
-
-```none
-[connection]
-uri = https://localhost:8443/ovirt-engine/api
-username = admin@internal
-password = admin
-```
-
-<!--
-In the same file it is possible to specify (using the `filters` section) what search query to use to identify the VMs to be reported to Kubernetes:
--->
-在同一文件中，可以指定（使用 `filters` 节区）搜索查询，用于辨识要报告给 Kubernetes 的 VM：
-
-```none
-[filters]
-# Search query used to find nodes
-vms = tag=kubernetes
-```
-
-<!--
-In the above example all the VMs tagged with the `kubernetes` label will be reported as nodes to Kubernetes.
--->
-在上面的示例中，所有带有 `kubernetes` 标签的虚拟机都将作为节点报告给 Kubernetes。
-
-<!--
-The `ovirt-cloud.conf` file then must be specified in kube-controller-manager:
--->
-然后必须向 kube-controller-manager 提供 `ovirt-cloud.conf` 文件：
-
-```shell
-kube-controller-manager ... --cloud-provider=ovirt --cloud-config=/path/to/ovirt-cloud.conf ...
-```
-
-<!--
-## oVirt Cloud Provider Screencast
--->
-## oVirt 云驱动截屏视频
-
-<!--
-This short screencast demonstrates how the oVirt Cloud Provider can be used to dynamically add VMs to your Kubernetes cluster.
--->
-这段简短的截屏视频演示了如何使用 oVirt 云提供商将 VM 动态添加到 Kubernetes 集群。
-
-<!--
-[![Screencast](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](https://www.youtube.com/watch?v=JyyST4ZKne8)
--->
-[![截屏视频](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](https://www.youtube.com/watch?v=JyyST4ZKne8)
-
-<!--
-## Support Level
--->
-## 支持级别
-
-
-<!--
-IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
--------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
-oVirt                |              |        |             | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/)                                  |          | Community ([@simon3z](https://github.com/simon3z))
--->
-IaaS 提供商        | 配置管理 | OS     | 联网  | 文件                                              | 遵从性 | 支持级别
------------------ | ------- | ------ | ---- | ------------------------------------------------- |------| ---------------
-oVirt | | | | [文件](/docs/setup/production-environment/on-premises-vm/ovirt/) | | 社区 ([@simon3z](https://github.com/simon3z))
-
-
-
-
diff --git a/content/zh/docs/setup/production-environment/tools/kops.md b/content/zh/docs/setup/production-environment/tools/kops.md
index 99c05d2fbf..871158dc89 100644
--- a/content/zh/docs/setup/production-environment/tools/kops.md
+++ b/content/zh/docs/setup/production-environment/tools/kops.md
@@ -4,11 +4,9 @@ content_type: concept
 weight: 20
 ---
 <!--
----
 title: Installing Kubernetes with kops
 content_type: concept
 weight: 20
----
 -->
 
 <!-- overview -->
@@ -29,14 +27,14 @@ kops 是一个自用的供应系统：
 * Fully automated installation
 * Uses DNS to identify clusters
 * Self-healing: everything runs in Auto-Scaling Groups
-* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md)
+* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
 * High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
 * Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
 -->
 * 全自动安装流程
 * 使用 DNS 识别集群
 * 自我修复：一切都在自动扩展组中运行
-* 支持多种操作系统（如 Debian、Ubuntu 16.04、CentOS、RHEL、Amazon Linux 和 CoreOS） - 参考 [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md)
+* 支持多种操作系统（如 Debian、Ubuntu 16.04、CentOS、RHEL、Amazon Linux 和 CoreOS） - 参考 [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
 * 支持高可用 - 参考 [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
 * 可以直接提供或者生成 terraform 清单 - 参考 [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
 
@@ -44,40 +42,35 @@ kops 是一个自用的供应系统：
 If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
 a building block.  kops builds on the kubeadm work.
 -->
-如果您有不同的观点，您可能更喜欢使用 [kubeadm](/docs/admin/kubeadm/) 作为构建工具来构建自己的集群。kops 建立在 kubeadm 工作的基础上。
-
-
+如果你有不同的观点，你可能更喜欢使用 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/)
+作为构建工具来构建自己的集群。kops 建立在 kubeadm 工作的基础上。
 
 <!-- body -->
 
 <!--
 ## Creating a cluster
+
+### (1/5) Install kops
+
+#### Requirements
+
+You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
 -->
 ## 创建集群
 
-<!--
-### (1/5) Install kops
--->
 ### (1/5) 安装 kops
 
-<!--
-#### Requirements
--->
 #### 前提条件
 
-<!--
-You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
--->
-您必须安装 [kubectl](/docs/tasks/tools/install-kubectl/) 才能使 kops 工作。
+你必须安装 [kubectl](/zh/docs/tasks/tools/install-kubectl/) 才能使 kops 工作。
 
 <!--
 #### Installation
+
+Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
 -->
 #### 安装
 
-<!--
-Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
--->
 从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops（从源代码构建也很容易）：
 
 <!--
@@ -90,7 +83,7 @@ On macOS:
 curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
 chmod +x kops-darwin-amd64
 mv kops-darwin-amd64 /usr/local/bin/kops
-# 您也可以使用 Homebrew 安装 kops
+# 你也可以使用 Homebrew 安装 kops
 brew update && brew install kops
 ```
 
@@ -107,28 +100,27 @@ mv kops-linux-amd64 /usr/local/bin/kops
 
 <!--
 ### (2/5) Create a route53 domain for your cluster
--->
-### (2/5) 为您的集群创建一个 route53 域名
 
-<!--
 kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server
 from clients.
 -->
-kops 在集群内部都使用 DNS 进行发现操作，因此您可以从客户端访问 kubernetes API 服务器。
+### (2/5) 为你的集群创建一个 route53 域名
+
+kops 在集群内部都使用 DNS 进行发现操作，因此你可以从客户端访问 kubernetes API 服务器。
 
 <!--
 kops has a strong opinion on the cluster name: it should be a valid DNS name.  By doing so you will
 no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
 and you can reach them without relying on remembering an IP address.
 -->
-kops 对集群名称有明显的要求：它应该是有效的 DNS 名称。这样一来，您就不会再使集群混乱，
+kops 对集群名称有明显的要求：它应该是有效的 DNS 名称。这样一来，你就不会再使集群混乱，
 可以与同事明确共享集群，并且无需依赖记住 IP 地址即可访问群集。
 
 <!--
 You can, and probably should, use subdomains to divide your clusters.  As our example we will use
 `useast1.dev.example.com`.  The API server endpoint will then be `api.useast1.dev.example.com`.
 -->
-您应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。
+你应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。
 然后，API 服务器端点域名将为 `api.useast1.dev.example.com`。
 
 <!--
@@ -137,53 +129,56 @@ but also `dev.example.com` or even `example.com`.  kops works with any of these,
 you choose for organization reasons (e.g. you are allowed to create records under `dev.example.com`,
 but not under `example.com`).
 -->
-Route53 托管区域可以服务子域名。您的托管区域可能是 `useast1.dev.example.com`，还有 `dev.example.com` 甚至 `example.com`。
-kops 可以与以上任何一种配合使用，因此通常您出于组织原因选择不同的托管区域。
-例如，允许您在 `dev.example.com` 下创建记录，但不能在 `example.com` 下创建记录。
+Route53 托管区域可以服务子域名。你的托管区域可能是 `useast1.dev.example.com`，还有 `dev.example.com` 甚至 `example.com`。
+kops 可以与以上任何一种配合使用，因此通常你出于组织原因选择不同的托管区域。
+例如，允许你在 `dev.example.com` 下创建记录，但不能在 `example.com` 下创建记录。
 
 <!--
 Let's assume you're using `dev.example.com` as your hosted zone.  You create that hosted zone using
 the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
 with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
 -->
-假设您使用 `dev.example.com` 作为托管区域。您可以使用[正常流程](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 或者使用诸如 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 之类的命令来创建该托管区域。
+假设你使用 `dev.example.com` 作为托管区域。你可以使用
+[正常流程](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html)
+或者使用诸如 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`
+之类的命令来创建该托管区域。
 
 <!--
 You must then set up your NS records in the parent domain, so that records in the domain will resolve.  Here,
 you would create NS records in `example.com` for `dev`.  If it is a root domain name you would configure the NS
 records at your domain registrar (e.g. `example.com` would need to be configured where you bought `example.com`).
 -->
-然后，您必须在父域名中设置您的 DNS 记录，以便该域名中的记录可以被解析。在这里，您将在 `example.com` 中为 `dev` 创建 DNS 记录。
-如果它是根域名，则可以在域名注册机构配置 DNS 记录。例如，您需要在购买 `example.com` 的地方配置 `example.com`。
+然后，你必须在父域名中设置你的 DNS 记录，以便该域名中的记录可以被解析。
+在这里，你将在 `example.com` 中为 `dev` 创建 DNS 记录。
+如果它是根域名，则可以在域名注册机构配置 DNS 记录。
+例如，你需要在购买 `example.com` 的地方配置 `example.com`。
 
 <!--
 This step is easy to mess up (it is the #1 cause of problems!)  You can double-check that
 your cluster is configured correctly if you have the dig tool by running:
 -->
 这一步很容易搞砸（这是问题的第一大原因！）
-如果您安装了 dig 工具，则可以通过运行以下步骤再次检查集群是否配置正确：
+如果你安装了 dig 工具，则可以通过运行以下步骤再次检查集群是否配置正确：
 
-<!--
-`dig NS dev.example.com`
--->
-`dig DNS dev.example.com`
+```shell
+dig DNS dev.example.com
+```
 
 <!--
 You should see the 4 NS records that Route53 assigned your hosted zone.
 -->
-您应该看到 Route53 分配了您的托管区域的 4 条 DNS 记录。
+你应该看到 Route53 分配了你的托管区域的 4 条 DNS 记录。
 
 <!--
 ### (3/5) Create an S3 bucket to store your clusters state
--->
-### (3/5) 创建一个 S3 存储桶来存储集群状态
 
-<!--
 kops lets you manage your clusters even after installation.  To do this, it must keep track of the clusters
 that you have created, along with their configuration, the keys they are using etc.  This information is stored
 in an S3 bucket.  S3 permissions are used to control access to the bucket.
 -->
-kops 使您即使在安装后也可以管理集群。为此，它必须跟踪已创建的集群及其配置、所使用的密钥等。
+### (3/5) 创建一个 S3 存储桶来存储集群状态
+
+kops 使你即使在安装后也可以管理集群。为此，它必须跟踪已创建的集群及其配置、所使用的密钥等。
 此信息存储在 S3 存储桶中。S3 权限用于控制对存储桶的访问。
 
 <!--
@@ -192,8 +187,8 @@ administer the same clusters - this is much easier than passing around kubecfg f
 to the S3 bucket will have administrative access to all your clusters, so you don't want to share it beyond
 the operations team.
 -->
-多个集群可以使用同一 S3 存储桶，并且您可以在管理同一集群的同事之间共享一个 S3 存储桶 - 这比传递 kubecfg 文件容易得多。
-但是有权访问 S3 存储桶的任何人都将拥有对所有集群的管理访问权限，因此您不想在运营团队之外共享它。
+多个集群可以使用同一 S3 存储桶，并且你可以在管理同一集群的同事之间共享一个 S3 存储桶 - 这比传递 kubecfg 文件容易得多。
+但是有权访问 S3 存储桶的任何人都将拥有对所有集群的管理访问权限，因此你不想在运营团队之外共享它。
 
 <!--
 So typically you have one S3 bucket for each ops team (and often the name will correspond
@@ -209,31 +204,23 @@ the S3 bucket name.
 
 <!--
 * Export `AWS_PROFILE` (if you need to select a profile for the AWS CLI to work)
--->
-* 导出 `AWS_PROFILE` 文件（如果您需要选择一个配置文件用来使 AWS CLI 正常工作）
-
-<!--
 * Create the S3 bucket using `aws s3 mb s3://clusters.dev.example.com`
--->
-* 使用 `aws s3 mb s3://clusters.dev.example.com` 创建 S3 存储桶
-
-<!--
 * You can `export KOPS_STATE_STORE=s3://clusters.dev.example.com` and then kops will use this location by default.
    We suggest putting this in your bash profile or similar.
 -->
-* 您可以进行 `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 操作，然后 kops 将默认使用此位置。
-   我们建议将其放入您的 bash profile 文件或类似文件中。
-
+* 导出 `AWS_PROFILE` 文件（如果你需要选择一个配置文件用来使 AWS CLI 正常工作）
+* 使用 `aws s3 mb s3://clusters.dev.example.com` 创建 S3 存储桶
+* 你可以进行 `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 操作，然后 kops 将默认使用此位置。
+  我们建议将其放入你的 bash profile 文件或类似文件中。
 
 <!--
 ### (4/5) Build your cluster configuration
--->
-### (4/5) 建立您的集群配置
 
-<!--
 Run "kops create cluster" to create your cluster configuration:
 -->
-运行 "kops create cluster" 以创建您的集群配置：
+### (4/5) 建立你的集群配置
+
+运行 "kops create cluster" 以创建你的集群配置：
 
 `kops create cluster --zones=us-east-1c useast1.dev.example.com`
 
@@ -242,8 +229,8 @@ kops will create the configuration for your cluster.  Note that it _only_ create
 not actually create the cloud resources - you'll do that in the next step with a `kops update cluster`.  This
 give you an opportunity to review the configuration or change it.
 -->
-kops 将为您的集群创建配置。请注意，它_仅_创建配置，实际上并没有创建云资源 - 您将在下一步中使用 `kops update cluster` 进行配置。
-这使您有机会查看配置或进行更改。
+kops 将为你的集群创建配置。请注意，它_仅_创建配置，实际上并没有创建云资源 - 你将在下一步中使用 `kops update cluster` 进行配置。
+这使你有机会查看配置或进行更改。
 
 <!--
 It prints commands you can use to explore further:
@@ -258,8 +245,8 @@ It prints commands you can use to explore further:
 -->
 * 使用以下命令列出集群：`kops get cluster`
 * 使用以下命令编辑该集群：`kops edit cluster useast1.dev.example.com`
-* 使用以下命令编辑您的节点实例组：`kops edit ig --name = useast1.dev.example.com nodes`
-* 使用以下命令编辑您的主实例组：`kops edit ig --name = useast1.dev.example.com master-us-east-1c`
+* 使用以下命令编辑你的节点实例组：`kops edit ig --name = useast1.dev.example.com nodes`
+* 使用以下命令编辑你的主实例组：`kops edit ig --name = useast1.dev.example.com master-us-east-1c`
 
 <!--
 If this is your first time using kops, do spend a few minutes to try those out!  An instance group is a
@@ -267,60 +254,62 @@ set of instances, which will be registered as kubernetes nodes.  On AWS this is
 You can have several instance groups, for example if you wanted nodes that are a mix of spot and on-demand instances, or
 GPU and non-GPU instances.
 -->
-如果这是您第一次使用 kops，请花几分钟尝试一下！ 实例组是一组实例，将被注册为 kubernetes 节点。
-在 AWS 上，这是通过 auto-scaling-groups 实现的。您可以有多个实例组，例如，如果您想要的是混合实例和按需实例的节点，或者
- GPU 和非 GPU 实例。
+如果这是你第一次使用 kops，请花几分钟尝试一下！ 实例组是一组实例，将被注册为 kubernetes 节点。
+在 AWS 上，这是通过 auto-scaling-groups 实现的。你可以有多个实例组。
+例如，如果你想要的是混合实例和按需实例的节点，或者 GPU 和非 GPU 实例。
 
 <!--
 ### (5/5) Create the cluster in AWS
+
+Run "kops update cluster" to create your cluster in AWS:
 -->
 ### (5/5) 在 AWS 中创建集群
 
-<!--
-Run "kops update cluster" to create your cluster in AWS:
--->
 运行 "kops update cluster" 以在 AWS 中创建集群：
 
-`kops update cluster useast1.dev.example.com --yes`
+```shell
+kops update cluster useast1.dev.example.com --yes
+```
 
 <!--
 That takes a few seconds to run, but then your cluster will likely take a few minutes to actually be ready.
 `kops update cluster` will be the tool you'll use whenever you change the configuration of your cluster; it
 applies the changes you have made to the configuration to your cluster - reconfiguring AWS or kubernetes as needed.
 -->
-这需要几秒钟的时间才能运行，但实际上集群可能需要几分钟才能准备就绪。每当更改集群配置时，都会使用 `kops update cluster` 工具。
-它将对配置进行的更改应用于您的集群 - 根据需要重新配置 AWS 或者 kubernetes。
+这需要几秒钟的时间才能运行，但实际上集群可能需要几分钟才能准备就绪。
+每当更改集群配置时，都会使用 `kops update cluster` 工具。
+它将对配置进行的更改应用于你的集群 - 根据需要重新配置 AWS 或者 kubernetes。
 
 <!--
 For example, after you `kops edit ig nodes`, then `kops update cluster --yes` to apply your configuration, and
 sometimes you will also have to `kops rolling-update cluster` to roll out the configuration immediately.
 -->
-例如，在您运行 `kops edit ig nodes` 之后，然后运行 `kops update cluster --yes` 应用您的配置，有时您还必须运行 `kops rolling-update cluster` 立即回滚更新配置。
+例如，在你运行 `kops edit ig nodes` 之后，然后运行 `kops update cluster --yes`
+应用你的配置，有时你还必须运行 `kops rolling-update cluster` 立即回滚更新配置。
 
 <!--
 Without `--yes`, `kops update cluster` will show you a preview of what it is going to do.  This is handy
 for production clusters!
 -->
-如果没有 `--yes` 参数，`kops update cluster` 操作将向您显示其操作的预览效果。这对于生产集群很方便！
+如果没有 `--yes` 参数，`kops update cluster` 操作将向你显示其操作的预览效果。这对于生产集群很方便！
 
 <!--
 ### Explore other add-ons
+
+See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp; control of your Kubernetes cluster.
 -->
 ### 探索其他附加组件
 
-<!--
-See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp; control of your Kubernetes cluster.
--->
-请参阅[附加组件列表](/docs/concepts/cluster-administration/addons/)探索其他附加组件，包括用于 Kubernetes 集群的日志记录、监视、网络策略、可视化和控制的工具。
+请参阅[附加组件列表](/zh/docs/concepts/cluster-administration/addons/)探索其他附加组件，
+包括用于 Kubernetes 集群的日志记录、监视、网络策略、可视化和控制的工具。
 
 <!--
 ## Cleanup
+
+* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
 -->
 ## 清理
 
-<!--
-* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
--->
 * 删除集群：`kops delete cluster useast1.dev.example.com --yes`
 
 <!--
@@ -332,21 +321,18 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
 * Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
 * [GitHub Issues](https://github.com/kubernetes/kops/issues)
 -->
-* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
+* Slack 频道: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
 * [GitHub Issues](https://github.com/kubernetes/kops/issues)
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
 * Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
 * See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
 -->
-* 了解有关 Kubernetes 的 [concepts](/docs/concepts/) 和 [`kubectl`](/docs/user-guide/kubectl-overview/) 的更多信息。
+* 了解有关 Kubernetes 的[概念](/zh/docs/concepts/) 和
+  [`kubectl`](/zh/docs/reference/kubectl/overview/) 的更多信息。
 * 了解 `kops` [高级用法](https://github.com/kubernetes/kops)。
 * 请参阅 `kops` [文档](https://github.com/kubernetes/kops) 获取教程、最佳做法和高级配置选项。
 
-
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
new file mode 100644
index 0000000000..b1ed43f952
--- /dev/null
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -0,0 +1,1005 @@
+---
+reviewers:
+- sig-cluster-lifecycle
+title: 使用 kubeadm 创建集群
+content_type: task
+weight: 30
+---
+
+<!-- ---
+reviewers:
+- sig-cluster-lifecycle
+title: Creating a cluster with kubeadm
+content_type: task
+weight: 30
+--- -->
+
+<!-- overview -->
+
+<!--
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Creating a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+`kubeadm` also supports other cluster
+lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
+-->
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">创建一个符合最佳实践的最小化 Kubernetes 集群。事实上，你可以使用 `kubeadm` 配置一个通过 [Kubernetes 一致性测试](https://kubernetes.io/blog/2017/10/software-conformance-certification) 的集群。
+`kubeadm` 还支持其他集群生命周期功能，
+例如 [启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) 和集群升级。
+
+<!--
+The `kubeadm` tool is good if you need:
+
+- A simple way for you to try out Kubernetes, possibly for the first time.
+- A way for existing users to automate setting up a cluster and test their application.
+- A building block in other ecosystem and/or installer tools with a larger
+  scope.
+-->
+kubeadm 工具很棒，如果你需要：
+
+- 一个尝试 Kubernetes 的简单方法。
+- 一个现有用户可以自动设置集群并测试其应用程序的途径。
+- 其他具有更大范围的生态系统和/或安装工具中的构建模块。
+
+<!--
+You can install and use `kubeadm` on various machines: your laptop, a set
+of cloud servers, a Raspberry Pi, and more. Whether you're deploying into the
+cloud or on-premises, you can integrate `kubeadm` into provisioning systems such
+as Ansible or Terraform.
+-->
+你可以在各种机器上安装和使用 `kubeadm`：笔记本电脑，
+一组云服务器，Raspberry Pi 等。无论是部署到云还是本地，
+你都可以将 `kubeadm` 集成到预配置系统中，例如 Ansible 或 Terraform。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+<!--
+To follow this guide, you need:
+
+- One or more machines running a deb/rpm-compatible Linux OS; for example: Ubuntu or CentOS.
+- 2 GiB or more of RAM per machine--any less leaves little room for your
+   apps.
+- At least 2 CPUs on the machine that you use as a control-plane node.
+- Full network connectivity among all machines in the cluster. You can use either a
+  public or a private network.
+-->
+要遵循本指南，你需要：
+
+- 一台或多台运行兼容 deb/rpm 的 Linux 操作系统的计算机；例如：Ubuntu 或 CentOS。
+- 每台机器 2 GB 以上的内存，内存不足时应用会受限制。
+- 用作控制平面节点的计算机上至少有2个 CPU。
+- 集群中所有计算机之间具有完全的网络连接。你可以使用公共网络或专用网络。
+
+<!--
+You also need to use a version of `kubeadm` that can deploy the version
+of Kubernetes that you want to use in your new cluster.
+-->
+你还需要使用可以在新集群中部署特定 Kubernetes 版本对应的 `kubeadm`。
+
+
+<!--
+[Kubernetes' version and version skew support policy](/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall.
+Check that policy to learn about what versions of Kubernetes and `kubeadm`
+are supported. This page is written for Kubernetes {{< param "version" >}}.
+-->
+[Kubernetes 版本及版本倾斜支持策略](/zh/docs/setup/release/version-skew-policy/#supported-versions) 适用于 `kubeadm` 以及整个 Kubernetes。
+查阅该策略以了解支持哪些版本的 Kubernetes 和 `kubeadm`。
+该页面是为 Kubernetes {{< param "version" >}} 编写的。
+
+<!--
+The `kubeadm` tool's overall feature state is General Availability (GA). Some sub-features are
+still under active development. The implementation of creating the cluster may change
+slightly as the tool evolves, but the overall implementation should be pretty stable.
+-->
+`kubeadm` 工具的整体功能状态为一般可用性（GA）。一些子功能仍在积极开发中。
+随着工具的发展，创建集群的实现可能会略有变化，但总体实现应相当稳定。
+
+<!--
+Any commands under `kubeadm alpha` are, by definition, supported on an alpha level.
+-->
+{{< note >}}
+根据定义，在 `kubeadm alpha` 下的所有命令均在 alpha 级别上受支持。
+{{< /note >}}
+
+
+
+<!-- steps -->
+
+<!--
+## Objectives
+-->
+## 目标
+
+<!--
+* Install a single control-plane Kubernetes cluster
+* Install a Pod network on the cluster so that your Pods can
+  talk to each other
+-->
+* 安装单个控制平面的 Kubernetes 集群
+* 在集群上安装 Pod 网络，以便你的 Pod 可以相互连通
+
+<!--
+## Instructions
+-->
+## 操作指南
+
+<!--
+### Installing kubeadm on your hosts
+-->
+### 在你的主机上安装安装 kubeadm
+
+<!--
+See ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+-->
+查看 ["安装 kubeadm"](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)。
+
+<!--
+If you have already installed kubeadm, run `apt-get update &&
+apt-get upgrade` or `yum update` to get the latest version of kubeadm.
+
+When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
+kubeadm to tell it what to do. This crashloop is expected and normal.
+After you initialize your control-plane, the kubelet runs normally.
+-->
+{{< note >}}
+如果你已经安装了kubeadm，执行 `apt-get update &&
+apt-get upgrade` 或 `yum update` 以获取 kubeadm 的最新版本。
+
+升级时，kubelet 每隔几秒钟重新启动一次，
+在 crashloop 状态中等待 kubeadm 发布指令。crashloop 状态是正常现象。
+初始化控制平面后，kubelet 将正常运行。
+{{< /note >}}
+
+<!--
+### Initializing your control-plane node
+-->
+### 初始化控制平面节点
+
+<!--
+The control-plane node is the machine where the control plane components run, including
+{{< glossary_tooltip term_id="etcd" >}} (the cluster database) and the
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
+(which the {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} command line tool
+communicates with).
+-->
+控制平面节点是运行控制平面组件的机器，
+包括 {{< glossary_tooltip term_id="etcd" >}} （集群数据库）
+和 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
+（命令行工具 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 与之通信）。
+
+<!--
+1. (Recommended) If you have plans to upgrade this single control-plane `kubeadm` cluster
+to high availability you should specify the `--control-plane-endpoint` to set the shared endpoint
+for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer.
+1. Choose a Pod network add-on, and verify whether it requires any arguments to
+be passed to `kubeadm init`. Depending on which
+third-party provider you choose, you might need to set the `--pod-network-cidr` to
+a provider-specific value. See [Installing a Pod network add-on](#pod-network).
+1. (Optional) Since version 1.14, `kubeadm` tries to detect the container runtime on Linux
+by using a list of well known domain socket paths. To use different container runtime or
+if there are more than one installed on the provisioned node, specify the `--cri-socket`
+argument to `kubeadm init`. See [Installing runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
+1. (Optional) Unless otherwise specified, `kubeadm` uses the network interface associated
+with the default gateway to set the advertise address for this particular control-plane node's API server.
+To use a different network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
+to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
+must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
+1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
+connectivity to the gcr.io container image registry.
+-->
+1. （推荐）如果计划将单个控制平面 kubeadm 集群升级成高可用，
+你应该指定 `--control-plane-endpoint` 为所有控制平面节点设置共享端点。
+端点可以是负载均衡器的 DNS 名称或 IP 地址。
+1. 选择一个Pod网络插件，并验证是否需要为 `kubeadm init` 传递参数。
+根据你选择的第三方网络插件，你可能需要设置 `--pod-network-cidr` 的值。
+请参阅 [安装Pod网络附加组件](#pod-network)。
+1. （可选）从版本1.14开始，`kubeadm` 尝试使用一系列众所周知的域套接字路径来检测 Linux 上的容器运行时。
+要使用不同的容器运行时，
+或者如果在预配置的节点上安装了多个容器，请为 `kubeadm init` 指定 `--cri-socket` 参数。
+请参阅[安装运行时](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)。
+1. （可选）除非另有说明，否则 `kubeadm` 使用与默认网关关联的网络接口来设置此控制平面节点 API server 的广播地址。
+要使用其他网络接口，请为 `kubeadm init` 设置 `--apiserver-advertise-address=<ip-address>` 参数。
+要部署使用 IPv6 地址的 Kubernetes 集群，
+必须指定一个 IPv6 地址，例如 `--apiserver-advertise-address=fd00::101`
+1. （可选）在 `kubeadm init` 之前运行 `kubeadm config images pull`，以验证与 gcr.io 容器镜像仓库的连通性。
+
+
+<!--
+To initialize the control-plane node run:
+-->
+要初始化控制平面节点，请运行：
+
+```bash
+kubeadm init <args>
+```
+
+<!--
+### Considerations about apiserver-advertise-address and ControlPlaneEndpoint
+-->
+### 关于 apiserver-advertise-address 和 ControlPlaneEndpoint 的注意事项
+
+<!--
+While `--apiserver-advertise-address` can be used to set the advertise address for this particular
+control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint
+for all control-plane nodes.
+-->
+`--apiserver-advertise-address`  可用于为控制平面节点的 API server 设置广播地址，
+`--control-plane-endpoint` 可用于为所有控制平面节点设置共享端点。
+
+<!--
+`--control-plane-endpoint` allows both IP addresses and DNS names that can map to IP addresses.
+Please contact your network administrator to evaluate possible solutions with respect to such mapping.
+-->
+`--control-plane-endpoint` 允许 IP 地址和可以映射到 IP 地址的 DNS 名称。
+请与你的网络管理员联系，以评估有关此类映射的可能解决方案。
+
+<!--
+Here is an example mapping:
+-->
+这是一个示例映射：
+
+```
+192.168.0.102 cluster-endpoint
+```
+
+<!--
+Where `192.168.0.102` is the IP address of this node and `cluster-endpoint` is a custom DNS name that maps to this IP.
+This will allow you to pass `--control-plane-endpoint=cluster-endpoint` to `kubeadm init` and pass the same DNS name to
+`kubeadm join`. Later you can modify `cluster-endpoint` to point to the address of your load-balancer in an
+high availability scenario.
+-->
+其中 `192.168.0.102` 是此节点的 IP 地址，`cluster-endpoint` 是映射到该 IP 的自定义 DNS 名称。
+这将允许你将 `--control-plane-endpoint=cluster-endpoint` 传递给 `kubeadm init`，并将相同的 DNS 名称传递给 `kubeadm join`。
+稍后你可以修改 `cluster-endpoint` 以指向高可用性方案中的负载均衡器的地址。
+
+<!--
+Turning a single control plane cluster created without `--control-plane-endpoint` into a highly available cluster
+is not supported by kubeadm.
+-->
+kubeadm 不支持将没有 `--control-plane-endpoint` 参数的单个控制平面集群转换为高可用性集群。
+
+<!--
+### More information
+-->
+### 更多信息
+
+<!--
+For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
+-->
+有关 `kubeadm init` 参数的更多信息，请参见 [kubeadm 参考指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)。
+
+<!--
+For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
+-->
+有关配置选项的完整列表，请参见[配置文件文档](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)。
+
+<!--
+To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
+-->
+要自定义控制平面组件，包括可选的对控制平面组件和 etcd 服务器的活动探针提供 IPv6 支持，请参阅[自定义参数](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)。
+
+<!--
+To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
+-->
+要再次运行 `kubeadm init`，你必须首先[卸载集群](#tear-down)。
+
+<!--
+If you join a node with a different architecture to your cluster, make sure that your deployed DaemonSets
+have container image support for this architecture.
+-->
+如果将具有不同架构的节点加入集群，
+请确保已部署的 DaemonSet 对这种体系结构具有容器镜像支持。
+
+
+<!--
+`kubeadm init` first runs a series of prechecks to ensure that the machine
+is ready to run Kubernetes. These prechecks expose warnings and exit on errors. `kubeadm init`
+then downloads and installs the cluster control plane components. This may take several minutes.
+The output should look like:
+-->
+`kubeadm init` 首先运行一系列预检查以确保机器
+准备运行 Kubernetes。这些预检查会显示警告并在错误时退出。然后 `kubeadm init`
+下载并安装集群控制平面组件。这可能会需要几分钟。
+输出应如下所示：
+
+```none
+[init] Using Kubernetes version: vX.Y.Z
+[preflight] Running pre-flight checks
+[preflight] Pulling images required for setting up a Kubernetes cluster
+[preflight] This might take a minute or two, depending on the speed of your internet connection
+[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
+[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
+[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
+[kubelet-start] Activating the kubelet service
+[certs] Using certificateDir folder "/etc/kubernetes/pki"
+[certs] Generating "etcd/ca" certificate and key
+[certs] Generating "etcd/server" certificate and key
+[certs] etcd/server serving cert is signed for DNS names [kubeadm-cp localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
+[certs] Generating "etcd/healthcheck-client" certificate and key
+[certs] Generating "etcd/peer" certificate and key
+[certs] etcd/peer serving cert is signed for DNS names [kubeadm-cp localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
+[certs] Generating "apiserver-etcd-client" certificate and key
+[certs] Generating "ca" certificate and key
+[certs] Generating "apiserver" certificate and key
+[certs] apiserver serving cert is signed for DNS names [kubeadm-cp kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
+[certs] Generating "apiserver-kubelet-client" certificate and key
+[certs] Generating "front-proxy-ca" certificate and key
+[certs] Generating "front-proxy-client" certificate and key
+[certs] Generating "sa" key and public key
+[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
+[kubeconfig] Writing "admin.conf" kubeconfig file
+[kubeconfig] Writing "kubelet.conf" kubeconfig file
+[kubeconfig] Writing "controller-manager.conf" kubeconfig file
+[kubeconfig] Writing "scheduler.conf" kubeconfig file
+[control-plane] Using manifest folder "/etc/kubernetes/manifests"
+[control-plane] Creating static Pod manifest for "kube-apiserver"
+[control-plane] Creating static Pod manifest for "kube-controller-manager"
+[control-plane] Creating static Pod manifest for "kube-scheduler"
+[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
+[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
+[apiclient] All control plane components are healthy after 31.501735 seconds
+[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
+[kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
+[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-cp" as an annotation
+[mark-control-plane] Marking the node kubeadm-cp as control-plane by adding the label "node-role.kubernetes.io/master=''"
+[mark-control-plane] Marking the node kubeadm-cp as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
+[bootstrap-token] Using token: <token>
+[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
+[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
+[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
+[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
+[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
+[addons] Applied essential addon: CoreDNS
+[addons] Applied essential addon: kube-proxy
+
+Your Kubernetes control-plane has initialized successfully!
+
+To start using your cluster, you need to run the following as a regular user:
+
+  mkdir -p $HOME/.kube
+  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
+  sudo chown $(id -u):$(id -g) $HOME/.kube/config
+
+You should now deploy a Pod network to the cluster.
+Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
+  /docs/concepts/cluster-administration/addons/
+
+You can now join any number of machines by running the following on each node
+as root:
+
+  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
+```
+
+<!--
+To make kubectl work for your non-root user, run these commands, which are
+also part of the `kubeadm init` output:
+-->
+要使非 root 用户可以运行 kubectl，请运行以下命令，
+它们也是 `kubeadm init` 输出的一部分：
+
+
+```bash
+mkdir -p $HOME/.kube
+sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
+sudo chown $(id -u):$(id -g) $HOME/.kube/config
+```
+
+<!--
+Alternatively, if you are the `root` user, you can run:
+-->
+或者，如果你是 `root` 用户，则可以运行：
+
+```bash
+export KUBECONFIG=/etc/kubernetes/admin.conf
+```
+
+<!--
+Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
+need this command to [join nodes to your cluster](#join-nodes).
+-->
+记录 `kubeadm init` 输出的 `kubeadm join` 命令。
+你需要此命令[将节点加入集群](#join-nodes)。
+
+<!--
+The token is used for mutual authentication between the control-plane node and the joining
+nodes. The token included here is secret. Keep it safe, because anyone with this
+token can add authenticated nodes to your cluster. These tokens can be listed,
+created, and deleted with the `kubeadm token` command. See the
+[kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm-token/).
+-->
+令牌用于控制平面节点和加入节点之间的相互身份验证。
+这里包含的令牌是密钥。确保它的安全，
+因为拥有此令牌的任何人都可以将经过身份验证的节点添加到你的集群中。
+可以使用 `kubeadm token` 命令列出，创建和删除这些令牌。
+请参阅 [kubeadm 参考指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/)。
+
+
+<!--
+### Installing a Pod network add-on {#pod-network}
+-->
+### 安装 Pod 网络附加组件 {#pod-network}
+
+{{< caution >}}
+<!--
+This section contains important information about networking setup and
+deployment order.
+Read all of this advice carefully before proceeding.
+-->
+本节包含有关网络设置和部署顺序的重要信息。
+在继续之前，请仔细阅读所有建议。
+
+<!--
+**You must deploy a
+{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}
+(CNI) based Pod network add-on so that your Pods can communicate with each other.
+Cluster DNS (CoreDNS) will not start up before a network is installed.**
+-->
+**你必须部署一个基于 Pod 网络插件的
+{{< glossary_tooltip text="容器网络接口" term_id="cni" >}}
+(CNI)，以便你的 Pod 可以相互通信。
+在安装网络之前，集群 DNS (CoreDNS) 将不会启动。**
+
+<!--
+- Take care that your Pod network must not overlap with any of the host
+  networks: you are likely to see problems if there is any overlap.
+  (If you find a collision between your network plugin's preferred Pod
+  network and some of your host networks, you should think of a suitable
+  CIDR block to use instead, then use that during `kubeadm init` with
+  `--pod-network-cidr` and as a replacement in your network plugin's YAML).
+-->
+- 注意你的 Pod 网络不得与任何主机网络重叠：
+  如果有重叠，你很可能会遇到问题。
+  （如果你发现网络插件的首选 Pod 网络与某些主机网络之间存在冲突，
+  则应考虑使用一个合适的 CIDR 块来代替，
+  然后在执行 `kubeadm init` 时使用 `--pod-network-cidr` 参数并在你的网络插件的 YAML 中替换它）。
+
+<!--
+- By default, `kubeadm` sets up your cluster to use and enforce use of
+  [RBAC](/docs/reference/access-authn-authz/rbac/) (role based access
+  control).
+  Make sure that your Pod network plugin supports RBAC, and so do any manifests
+  that you use to deploy it.
+-->
+- 默认情况下，`kubeadm` 将集群设置为使用和强制使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)（基于角色的访问控制）。
+  确保你的 Pod 网络插件支持 RBAC，以及用于部署它的 manifests 也是如此。
+
+<!--
+- If you want to use IPv6--either dual-stack, or single-stack IPv6 only
+  networking--for your cluster, make sure that your Pod network plugin
+  supports IPv6.
+  IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
+-->
+- 如果要为集群使用 IPv6（双协议栈或仅单协议栈 IPv6 网络），
+  请确保你的Pod网络插件支持 IPv6。
+  IPv6 支持已在 CNI [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0) 版本中添加。
+{{< /caution >}}
+
+<!--
+Currently Calico is the only CNI plugin that the kubeadm project performs e2e tests against.
+If you find an issue related to a CNI plugin you should log a ticket in its respective issue
+tracker instead of the kubeadm or kubernetes issue trackers.
+-->
+{{< note >}}
+目前 Calico 是 kubeadm 项目中执行 e2e 测试的唯一 CNI 插件。
+如果你发现与 CNI 插件相关的问题，应在其各自的问题跟踪器中记录而不是在 kubeadm 或 kubernetes 问题跟踪器中记录。
+{{< /note >}}
+
+<!--
+Several external projects provide Kubernetes Pod networks using CNI, some of which also
+support [Network Policy](/docs/concepts/services-networking/network-policies/).
+-->
+一些外部项目为 Kubernetes 提供使用 CNI 的 Pod 网络，其中一些还支持[网络策略](/zh/docs/concepts/services-networking/network-policies/)。
+
+<!--
+See a list of add-ons that implement the
+[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
+-->
+请参阅实现 [Kubernetes 网络模型](/zh/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model) 的附加组件列表。
+
+<!--
+You can install a Pod network add-on with the following command on the
+control-plane node or a node that has the kubeconfig credentials:
+-->
+你可以使用以下命令在控制平面节点或具有 kubeconfig 凭据的节点上安装 Pod 网络附加组件：
+
+```bash
+kubectl apply -f <add-on.yaml>
+```
+
+<!--
+You can install only one Pod network per cluster.
+-->
+每个集群只能安装一个 Pod 网络。
+
+<!--
+Once a Pod network has been installed, you can confirm that it is working by
+checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`.
+And once the CoreDNS Pod is up and running, you can continue by joining your nodes.
+-->
+安装 Pod 网络后，您可以通过在 `kubectl get pods --all-namespaces` 输出中检查 CoreDNS Pod 是否 `Running` 来确认其是否正常运行。
+一旦 CoreDNS Pod 启用并运行，你就可以继续加入节点。
+
+<!--
+If your network is not working or CoreDNS is not in the `Running` state, check out the
+[troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)
+for `kubeadm`.
+-->
+如果您的网络无法正常工作或CoreDNS不在“运行中”状态，请查看 `kubeadm` 的[故障排除指南](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。
+
+
+<!--
+### Control plane node isolation
+-->
+### 控制平面节点隔离
+
+<!--
+By default, your cluster will not schedule Pods on the control-plane node for security
+reasons. If you want to be able to schedule Pods on the control-plane node, for example for a
+single-machine Kubernetes cluster for development, run:
+-->
+默认情况下，出于安全原因，你的集群不会在控制平面节点上调度 Pod。
+如果你希望能够在控制平面节点上调度 Pod，
+例如用于开发的单机 Kubernetes 集群，请运行：
+
+```bash
+kubectl taint nodes --all node-role.kubernetes.io/master-
+```
+<!--
+With output looking something like:
+-->
+输出看起来像：
+
+```
+node "test-01" untainted
+taint "node-role.kubernetes.io/master:" not found
+taint "node-role.kubernetes.io/master:" not found
+```
+
+<!--
+This will remove the `node-role.kubernetes.io/master` taint from any nodes that
+have it, including the control-plane node, meaning that the scheduler will then be able
+to schedule Pods everywhere.
+-->
+这将从任何拥有 `node-role.kubernetes.io/master` taint 标记的节点中移除该标记，
+包括控制平面节点，这意味着调度程序将能够在任何地方调度 Pods。
+
+
+<!--
+### Joining your nodes {#join-nodes}
+-->
+### 加入节点 {#join-nodes}
+
+<!--
+The nodes are where your workloads (containers and Pods, etc) run. To add new nodes to your cluster do the following for each machine:
+-->
+节点是你的工作负载（容器和 Pod 等）运行的地方。要将新节点添加到集群，请对每台计算机执行以下操作：
+
+<!--
+* SSH to the machine
+* Become root (e.g. `sudo su -`)
+* Run the command that was output by `kubeadm init`. For example:
+-->
+* SSH 到机器
+* 成为 root （例如 `sudo su -`）
+* 运行 `kubeadm init` 输出的命令。例如：
+
+```bash
+kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>
+```
+
+<!--
+If you do not have the token, you can get it by running the following command on the control-plane node:
+-->
+如果没有令牌，可以通过在控制平面节点上运行以下命令来获取令牌：
+
+
+```bash
+kubeadm token list
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于以下内容：
+
+```console
+TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
+8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
+                                                   signing          token generated by     bootstrappers:
+                                                                    'kubeadm init'.        kubeadm:
+                                                                                           default-node-token
+```
+
+<!--
+By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired,
+you can create a new token by running the following command on the control-plane node:
+-->
+默认情况下，令牌会在24小时后过期。如果要在当前令牌过期后将节点加入集群，
+则可以通过在控制平面节点上运行以下命令来创建新令牌：
+
+
+```bash
+kubeadm token create
+```
+<!--
+The output is similar to this:
+-->
+输出类似于以下内容：
+
+```console
+5didvk.d09sbcov8ph2amjw
+```
+
+<!--
+If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the control-plane node:
+-->
+如果你没有 `--discovery-token-ca-cert-hash` 的值，则可以通过在控制平面节点上执行以下命令链来获取它：
+
+```bash
+openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
+   openssl dgst -sha256 -hex | sed 's/^.* //'
+```
+
+<!--
+The output is similar to:
+-->
+输出类似于以下内容：
+
+```console
+8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
+```
+
+<!--
+To specify an IPv6 tuple for `<control-plane-host>:<control-plane-port>`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
+-->
+{{< note >}}
+要为 `<control-plane-host>:<control-plane-port>` 指定 IPv6 元组，必须将 IPv6 地址括在方括号中，例如：`[fd00::101]:2073`
+{{< /note >}}
+
+<!--
+The output should look something like:
+-->
+输出应类似于：
+
+```
+[preflight] Running pre-flight checks
+
+... (log output of join workflow) ...
+
+Node join complete:
+* Certificate signing request sent to control-plane and response
+  received.
+* Kubelet informed of new secure connection details.
+
+Run 'kubectl get nodes' on control-plane to see this machine join.
+```
+
+<!--
+A few seconds later, you should notice this node in the output from `kubectl get
+nodes` when run on the control-plane node.
+-->
+几秒钟后，当你在控制平面节点上执行 `kubectl get nodes`，你会注意到该节点出现在输出中。
+
+<!--
+### (Optional) Controlling your cluster from machines other than the control-plane node
+-->
+### （可选）从控制平面节点以外的计算机控制集群
+
+<!--
+In order to get a kubectl on some other computer (e.g. laptop) to talk to your
+cluster, you need to copy the administrator kubeconfig file from your control-plane node
+to your workstation like this:
+-->
+为了使 kubectl 在其他计算机（例如笔记本电脑）上与你的集群通信，
+你需要将管理员 kubeconfig 文件从控制平面节点复制到工作站，如下所示：
+
+```bash
+scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
+kubectl --kubeconfig ./admin.conf get nodes
+```
+<!--
+The example above assumes SSH access is enabled for root. If that is not the
+case, you can copy the `admin.conf` file to be accessible by some other user
+and `scp` using that other user instead.
+
+The `admin.conf` file gives the user _superuser_ privileges over the cluster.
+This file should be used sparingly. For normal users, it's recommended to
+generate an unique credential to which you grant privileges. You can do
+this with the `kubeadm alpha kubeconfig user --client-name <CN>`
+command. That command will print out a KubeConfig file to STDOUT which you
+should save to a file and distribute to your user. After that, grant
+privileges by using `kubectl create (cluster)rolebinding`.
+-->
+{{< note >}}
+上面的示例假定为 root 用户启用了SSH访问。如果不是这种情况，
+你可以使用 `scp` 将 admin.conf 文件复制给其他允许访问的用户。
+
+admin.conf 文件为用户提供了对集群的超级用户特权。
+该文件应谨慎使用。对于普通用户，建议生成一个你为其授予特权的唯一证书。
+你可以使用 `kubeadm alpha kubeconfig user --client-name <CN>` 命令执行此操作。
+该命令会将 KubeConfig 文件打印到 STDOUT，你应该将其保存到文件并分发给用户。
+之后，使用 `kubectl create (cluster)rolebinding` 授予特权。
+{{< /note >}}
+
+<!--
+### (Optional) Proxying API Server to localhost
+-->
+### （可选）将API服务器代理到本地主机
+
+<!--
+If you want to connect to the API Server from outside the cluster you can use
+`kubectl proxy`:
+-->
+如果要从集群外部连接到 API 服务器，则可以使用 `kubectl proxy`：
+
+```bash
+scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
+kubectl --kubeconfig ./admin.conf proxy
+```
+<!--
+You can now access the API Server locally at `http://localhost:8001/api/v1`
+-->
+你现在可以在本地访问API服务器 http://localhost:8001/api/v1
+
+<!--
+## Clean up {#tear-down}
+-->
+## 清理 {#tear-down}
+
+<!--
+If you used disposable servers for your cluster, for testing, you can
+switch those off and do no further clean up. You can use
+`kubectl config delete-cluster` to delete your local references to the
+cluster.
+-->
+如果你在集群中使用了一次性服务器进行测试，则可以关闭这些服务器，而无需进一步清理。你可以使用 `kubectl config delete-cluster` 删除对集群的本地引用。
+
+<!--
+However, if you want to deprovision your cluster more cleanly, you should
+first [drain the node](/docs/reference/generated/kubectl/kubectl-commands#drain)
+and make sure that the node is empty, then deconfigure the node.
+-->
+但是，如果要更干净地取消配置群集，
+则应首先[清空节点](/docs/reference/generated/kubectl/kubectl-commands#drain)并确保该节点为空，
+然后取消配置该节点。
+
+
+<!--
+### Remove the node
+-->
+### 删除节点
+
+<!--
+Talking to the control-plane node with the appropriate credentials, run:
+-->
+使用适当的凭证与控制平面节点通信，运行：
+
+```bash
+kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
+```
+
+<!--
+Before removing the node, reset the state installed by `kubeadm`:
+-->
+在删除节点之前，请重置 `kubeadm` 安装的状态：
+
+```bash
+kubeadm reset
+```
+
+<!--
+The reset process does not reset or clean up iptables rules or IPVS tables. If you wish to reset iptables, you must do so manually:
+-->
+重置过程不会重置或清除 iptables 规则或 IPVS 表。如果你希望重置 iptables，则必须手动进行：
+
+```bash
+iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
+```
+
+<!--
+If you want to reset the IPVS tables, you must run the following command:
+-->
+如果要重置 IPVS 表，则必须运行以下命令：
+
+```bash
+ipvsadm -C
+```
+<!--
+Now remove the node:
+-->
+现在删除节点：
+
+```bash
+kubectl delete node <node name>
+```
+
+<!--
+If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
+appropriate arguments.
+-->
+如果你想重新开始，只需运行 `kubeadm init` 或 `kubeadm join` 并加上适当的参数。
+
+<!--
+### Clean up the control plane
+-->
+### 清理控制平面
+
+<!--
+You can use `kubeadm reset` on the control plane host to trigger a best-effort
+clean up.
+-->
+你可以在控制平面主机上使用 `kubeadm reset` 来触发尽力而为的清理。
+
+<!--
+See the [`kubeadm reset`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/)
+reference documentation for more information about this subcommand and its
+options.
+-->
+有关此子命令及其选项的更多信息，请参见[`kubeadm reset`](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/)参考文档。
+
+
+<!-- discussion -->
+
+<!--
+## What's next {#whats-next}
+-->
+## 下一步 {#whats-next}
+
+<!--
+* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
+* <a id="lifecycle" />See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+  for details about upgrading your cluster using `kubeadm`.
+* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
+* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
+  of Pod network add-ons.
+* <a id="other-addons" />See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to
+  explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp;
+  control of your Kubernetes cluster.
+* Configure how your cluster handles logs for cluster events and from
+  applications running in Pods.
+  See [Logging Architecture](/docs/concepts/cluster-administration/logging/) for
+  an overview of what is involved.
+-->
+* 使用 [Sonobuoy](https://github.com/heptio/sonobuoy) 验证集群是否正常运行
+* <a id="lifecycle" />有关使用kubeadm升级集群的详细信息，请参阅[升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。
+* 在[kubeadm 参考文档](/zh/docs/reference/setup-tools/kubeadm/kubeadm)中了解有关高级 `kubeadm` 用法的信息
+* 了解有关Kubernetes[概念](/zh/docs/concepts/)和[`kubectl`](/zh/docs/reference/kubectl/overview/)的更多信息。
+* 有关Pod网络附加组件的更多列表，请参见[集群网络](/zh/docs/concepts/cluster-administration/networking/)页面。
+* <a id="other-addons" />请参阅[附加组件列表](/zh/docs/concepts/cluster-administration/addons/)以探索其他附加组件，
+  包括用于 Kubernetes 集群的日志记录，监视，网络策略，可视化和控制的工具。
+* 配置集群如何处理集群事件的日志以及
+   在Pods中运行的应用程序。
+  有关所涉及内容的概述，请参见[日志架构](/zh/docs/concepts/cluster-administration/logging/)。
+
+<!--
+### Feedback {#feedback}
+-->
+### 反馈 {#feedback}
+
+<!--
+* For bugs, visit the [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* For support, visit the
+  [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/) Slack channel
+* General SIG Cluster Lifecycle development Slack channel:
+  [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
+* SIG Cluster Lifecycle [SIG information](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle#readme)
+* SIG Cluster Lifecycle mailing list:
+  [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
+-->
+* 有关 bugs, 访问 [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* 有关支持, 访问
+  [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/) Slack 频道
+* General SIG 集群生命周期开发 Slack 频道:
+  [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
+* SIG 集群生命周期 [SIG information](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle#readme)
+* SIG 集群生命周期邮件列表:
+  [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
+
+
+<!--
+## Version skew policy {#version-skew-policy}
+-->
+## 版本倾斜政策 {#version-skew-policy}
+
+<!--
+The `kubeadm` tool of version v{{< skew latestVersion >}} may deploy clusters with a control plane of version v{{< skew latestVersion >}} or v{{< skew prevMinorVersion >}}.
+`kubeadm` v{{< skew latestVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew prevMinorVersion >}}.
+-->
+版本 v{{< skew latestVersion >}} 的kubeadm 工具可以使用版本 v{{< skew latestVersion >}} 或 v{{< skew prevMinorVersion >}} 的控制平面部署集群。kubeadm v{{< skew latestVersion >}} 还可以升级现有的 kubeadm 创建的 v{{< skew prevMinorVersion >}} 版本的集群。
+
+<!--
+Due to that we can't see into the future, kubeadm CLI v{{< skew latestVersion >}} may or may not be able to deploy v{{< skew nextMinorVersion >}} clusters.
+-->
+由于没有未来，kubeadm CLI v{{< skew latestVersion >}} 可能会或可能无法部署 v{{< skew nextMinorVersion >}} 集群。
+
+<!--
+These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
+-->
+这些资源提供了有关 kubelet 与控制平面以及其他 Kubernetes 组件之间受支持的版本倾斜的更多信息：
+
+<!--
+* Kubernetes [version and version-skew policy](/docs/setup/release/version-skew-policy/)
+* Kubeadm-specific [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
+-->
+* Kubernetes [版本和版本偏斜政策](/zh/docs/setup/release/version-skew-policy/)
+* Kubeadm-specific [安装指南](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
+
+
+<!--
+## Limitations {#limitations}
+-->
+## 局限性 {#limitations}
+
+<!--
+### Cluster resilience {#resilience}
+-->
+### 集群弹性 {#resilience}
+
+<!--
+The cluster created here has a single control-plane node, with a single etcd database
+running on it. This means that if the control-plane node fails, your cluster may lose
+data and may need to be recreated from scratch.
+-->
+
+此处创建的集群具有单个控制平面节点，运行单个 etcd 数据库。
+这意味着如果控制平面节点发生故障，你的集群可能会丢失数据并且可能需要从头开始重新创建。
+
+<!--
+Workarounds:
+-->
+解决方法:
+
+<!--
+* Regularly [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
+  etcd data directory configured by kubeadm is at `/var/lib/etcd` on the control-plane node.
+-->
+* 定期[备份etcd](https://coreos.com/etcd/docs/latest/admin_guide.html)。
+  kubeadm 配置的 etcd 数据目录位于控制平面节点上的 `/var/lib/etcd` 中。
+
+<!--
+* Use multiple control-plane nodes. You can read
+  [Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) to pick a cluster
+  topology that provides [high-availability](/docs/setup/production-environment/tools/kubeadm/high-availability/).
+-->
+* 使用多个控制平面节点。你可以阅读
+  [可选的高可用性拓扑](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/) 选择集群拓扑提供的
+  [高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/).
+
+<!--
+### Platform compatibility {#multi-platform}
+-->
+### 平台兼容性 {#multi-platform}
+
+<!--
+kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x
+following the [multi-platform
+proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md).
+-->
+kubeadm deb/rpm 软件包和二进制文件是为 amd64，arm (32-bit)，arm64，ppc64le 和 s390x 构建的遵循[多平台提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md)。
+
+<!--
+Multiplatform container images for the control plane and addons are also supported since v1.12.
+-->
+从 v1.12 开始还支持用于控制平面和附加组件的多平台容器镜像。
+
+<!--
+Only some of the network providers offer solutions for all platforms. Please consult the list of
+network providers above or the documentation from each provider to figure out whether the provider
+supports your chosen platform.
+-->
+只有一些网络提供商为所有平台提供解决方案。请查阅上方的
+网络提供商清单或每个提供商的文档以确定提供商是否
+支持你选择的平台。
+
+<!--
+## Troubleshooting {#troubleshooting}
+-->
+## 故障排除 {#troubleshooting}
+
+<!--
+If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
+-->
+
+如果你在使用kubeadm时遇到困难，请查阅我们的[故障排除文档](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/zh/docs/setup/production-environment/tools/kubeadm/ha-topology.md
index f3f41d664d..fb41278c42 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/ha-topology.md
@@ -146,6 +146,6 @@ A minimum of three hosts for control plane nodes and three hosts for etcd nodes
 <!--
 - [Set up a highly available cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
 -->
- -  [使用 kubeadm 设置高可用集群](/docs/setup/production-environment/tools/kubeadm/high-availability/)
+ -  [使用 kubeadm 设置高可用集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
 
 
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/zh/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 3703563d4b..b0247ec776 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -42,12 +42,12 @@ in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new)
 
 See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15).
 -->
-在下一步之前，您应该仔细考虑哪种方法更好的满足您的应用程序和环境的需求。 [这是对比文档](/docs/setup/production-environment/tools/kubeadm/ha-topology/) 讲述了每种方法的优缺点。
+在下一步之前，您应该仔细考虑哪种方法更好的满足您的应用程序和环境的需求。 
+[这是对比文档](/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/) 讲述了每种方法的优缺点。
 
 如果您在安装 HA 集群时遇到问题，请在 kubeadm [问题跟踪](https://github.com/kubernetes/kubeadm/issues/new)里向我们提供反馈。
 
-您也可以阅读 [升级文件](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15)。
-
+您也可以阅读 [升级文件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 <!--
 This page does not address running your cluster on a cloud provider. In a cloud
 environment, neither approach documented here works with Service objects of type
@@ -77,8 +77,8 @@ For both methods you need this infrastructure:
 -->
 对于这两种方法，您都需要以下基础设施：
 
-- 配置三台机器[kubeadm 的最低要求](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin)给主节点
-- 配置三台机器 [kubeadm 的最低要求](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) 给工作节点
+- 配置三台机器 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) 给主节点
+- 配置三台机器 [kubeadm 的最低要求](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) 给工作节点
 - 在集群中，所有计算机之间的完全网络连接（公网或私网）
 - 所有机器上的 sudo 权限
 - 每台设备对系统中所有节点的 SSH 访问
@@ -129,11 +129,10 @@ option. Your cluster requirements may need a different configuration.
 
     - Make sure the address of the load balancer always matches
       the address of kubeadm's `ControlPlaneEndpoint`.
-      
+
     - Read the [Options for Software Load Balancing](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)
       guide for more details.
 -->
-
 1.  创建一个名为 kube-apiserver 的负载均衡器解析 DNS。
 
     - 在云环境中，应该将控制平面节点放置在 TCP 后面转发负载平衡。 该负载均衡器将流量分配给目标列表中所有运行状况良好的控制平面节点。健康检查 apiserver 是在 kube-apiserver 监听端口(默认值 `:6443`)上的一个 TCP 检查。
@@ -143,7 +142,7 @@ option. Your cluster requirements may need a different configuration.
     - 负载均衡器必须能够在 apiserver 端口上与所有控制平面节点通信。它还必须允许其监听端口的传入流量。
 
     - 确保负载均衡器的地址始终匹配 kubeadm 的 `ControlPlaneEndpoint` 地址。
-    
+
     - 阅读[软件负载平衡选项指南](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)以获取更多详细信息。
 
 <!--
@@ -161,17 +160,16 @@ option. Your cluster requirements may need a different configuration.
 
 1.  Add the remaining control plane nodes to the load balancer target group.
 -->
+2.  添加第一个控制平面节点到负载均衡器并测试连接：
 
-1.  添加第一个控制平面节点到负载均衡器并测试连接：
-
-    ```sh
+    ```shell
     nc -v LOAD_BALANCER_IP PORT
     ```
 
     - 由于 apiserver 尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。
    如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。
 
-1.  将其余控制平面节点添加到负载均衡器目标组。
+3.  将其余控制平面节点添加到负载均衡器目标组。
 
 <!-- ## Stacked control plane and etcd nodes -->
 ## 使用堆控制平面和 etcd 节点
@@ -180,7 +178,6 @@ option. Your cluster requirements may need a different configuration.
 ### 控制平面节点的第一步
 
 <!--
-
 1.  Initialize the control plane:
 
     ```sh
@@ -203,7 +200,6 @@ option. Your cluster requirements may need a different configuration.
     sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
     ```
 
-
     - 您可以使用 `--kubernetes-version` 标志来设置要使用的 Kubernetes 版本。建议将 kubeadm、kebelet、kubectl 和 Kubernetes 的版本匹配。
     - 这个 `--control-plane-endpoint` 标志应该被设置成负载均衡器的地址或 DNS 和端口。
     - 这个 `--upload-certs` 标志用来将在所有控制平面实例之间的共享证书上传到集群。如果正好相反，你更喜欢手动地通过控制平面节点或者使用自动化
@@ -224,7 +220,8 @@ To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kube
 set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
 -->
 {{< note >}}
-一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考 [CNI 网络文档](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
+一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考
+[CNI 网络文档](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
 通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者您可以使用 kubeadm 配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
 {{< /note >}}
 
@@ -323,7 +320,8 @@ As stated in the command output, the certificate key gives access to cluster sen
 
 -->
 1.  应用您选择的 CNI 插件：
-    [请遵循以下指示](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) 安装 CNI 提供程序。如果适用，请确保配置与 kubeadm 配置文件中指定的 Pod CIDR 相对应。
+    [请遵循以下指示](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
+    安装 CNI 提供程序。如果适用，请确保配置与 kubeadm 配置文件中指定的 Pod CIDR 相对应。
 
     在此示例中，我们使用 Weave Net：
 
@@ -414,7 +412,7 @@ in the kubeadm config file.
 
 ### 设置 ectd 集群
 
-1.  按照 [这些指示](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 去设置 etcd 集群。
+1.  按照 [这些指示](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) 去设置 etcd 集群。
 
 1.  设置 SSH 在 [这](#manual-certs)描述。
 
@@ -731,5 +729,3 @@ the creation of additional nodes could fail due to a lack of required SANs.
     mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
     mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
     ```
-
-
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index accb3a5b43..095f15875e 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -8,7 +8,6 @@ card:
   title: 安装 kubeadm 设置工具
 ---
 <!--
----
 title: Installing kubeadm
 content_type: task
 weight: 10
@@ -16,7 +15,6 @@ card:
   name: setup
   weight: 20
   title: Install the kubeadm setup tool
----
 -->
 
 <!-- overview -->
@@ -26,13 +24,11 @@ card:
 For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
 -->
 <img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">本页面显示如何安装 `kubeadm` 工具箱。
-有关在执行此安装过程后如何使用 kubeadm 创建集群的信息，请参见[使用 kubeadm 创建集群](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 页面。
-
-
+有关在执行此安装过程后如何使用 kubeadm 创建集群的信息，请参见
+[使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 页面。
 
 ## {{% heading "prerequisites" %}}
 
-
 <!--
 * One or more machines running one of:
   - Ubuntu 16.04+
@@ -65,7 +61,6 @@ For information how to create a cluster with kubeadm once you have performed thi
 * 禁用交换分区。为了保证 kubelet 正常工作，您 **必须** 禁用交换分区。
 
 
-
 <!-- steps -->
 
 <!--
@@ -187,7 +182,7 @@ documentation for the plugins about what port(s) those need.
 | TCP      | 入站   | 10250       | Kubelet API           | kubelet 自身、控制平面组件     |
 | TCP      | 入站   | 30000-32767 | NodePort 服务**   | 所有组件                     |
 
-** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。
+** [NodePort 服务](/zh/docs/concepts/services-networking/service/) 的默认端口范围。
 
 使用 * 标记的任意端口号都可以被覆盖，所以您需要保证所定制的端口是开放的。
 
@@ -255,7 +250,7 @@ Refer to the [CRI installation instructions](/docs/setup/cri) for more informati
 - [cri-o](https://cri-o.io/)
 - [frakti](https://github.com/kubernetes/frakti)
 
-请参考 [CRI 安装指南](/docs/setup/cri) 获取更多信息。
+请参考 [CRI 安装指南](/zh/docs/setup/production-environment/container-runtimes/)获取更多信息。
 
 <!--
 ## Installing kubeadm, kubelet and kubectl
@@ -294,7 +289,7 @@ kubeadm **不能** 帮您安装或者管理 `kubelet` 或 `kubectl`，所以您
 然而，控制平面与 kubelet 间的相差一个次要版本不一致是支持的，但 kubelet 的版本不可以超过 API 服务器的版本。
 例如，1.7.0 版本的 kubelet 可以完全兼容 1.8.0 版本的 API 服务器，反之则不可以。
 
-有关安装 `kubectl` 的信息，请参阅[安装和设置 kubectl](/docs/tasks/tools/install-kubectl/)文档。
+有关安装 `kubectl` 的信息，请参阅[安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/)文档。
 
 {{< warning >}}
 <!--
@@ -302,7 +297,8 @@ These instructions exclude all Kubernetes packages from any system upgrades.
 This is because kubeadm and Kubernetes require
 [special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/).
 -->
-这些指南不包括系统升级时使用的所有 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes 有[特殊的升级注意事项](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)。
+这些指南不包括系统升级时使用的所有 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes
+有[特殊的升级注意事项](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。
 {{</ warning >}}
 
 <!--
@@ -313,8 +309,8 @@ For more information on version skews, see:
 -->
 关于版本偏差的更多信息，请参阅以下文档：
 
-* Kubernetes [版本与版本间的偏差策略](/docs/setup/release/version-skew-policy/)
-* Kubeadm-specific [版本偏差策略](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
+* Kubernetes [版本与版本间的偏差策略](/zh/docs/setup/release/version-skew-policy/)
+* Kubeadm-specific [版本偏差策略](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
 
 {{< tabs name="k8s_install" >}}
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
@@ -475,7 +471,7 @@ The automatic detection of cgroup driver for other container runtimes
 like CRI-O and containerd is work in progress.
 
 -->
-## 在控制平面节点上配置 kubelet 使用的 cgroup 驱动程序
+## 在控制平面节点上配置 kubelet 使用的 cgroup 驱动程序  {#configure-cgroup-driver-used-by-kubelet-on-master-node}
 
 使用 docker 时，kubeadm 会自动为其检测 cgroup 驱动并在运行时对 `/var/lib/kubelet/kubeadm-flags.env` 文件进行配置。
 
@@ -506,7 +502,8 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
 -->
 ## 故障排查
 
-如果您在使用 kubeadm 时遇到困难，请参阅我们的[故障排查文档](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。
+如果您在使用 kubeadm 时遇到困难，请参阅我们的
+[故障排查文档](/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。
 
 ## {{% heading "whatsnext" %}}
 
@@ -514,6 +511,5 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
 <!--
 * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
 -->
-* [使用 kubeadm 创建集群](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
-
+* [使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
 
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index 8416f5969f..476c27f075 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -36,7 +36,7 @@ characteristics of a given machine, such as OS, storage, and networking. You can
 of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your
 kubelet configurations centrally](#configure-kubelets-using-kubeadm).
 -->
-kubeadm CLI 工具的生命周期与 [kubelet](/docs/reference/command-line-tools-reference/kubelet)解耦，它是一个守护程序，在 Kubernetes 集群中的每个节点上运行。
+kubeadm CLI 工具的生命周期与 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)解耦，它是一个守护程序，在 Kubernetes 集群中的每个节点上运行。
 当 Kubernetes 初始化或升级时，kubeadm CLI 工具由用户执行，而 kubelet 始终在后台运行。
 
 由于kubelet是守护程序，因此需要通过某种初始化系统或服务管理器进行维护。
@@ -319,10 +319,10 @@ This file specifies the default locations for all of the files managed by kubead
   `/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
   is last in the flag chain and has the highest priority in the event of conflicting settings.
 -->
-##  系统中的 kubelet 插件
+##  kubelet 的 systemd 文件 {#the-kubelet-drop-in-file-for-systemd}
 
-kubeadm 中附带了有关系统如何运行 kubelet 的配置。
-请注意 kubeadm CLI 命令不会触及此插件。
+kubeadm 中附带了有关系统如何运行 kubelet 的 systemd 配置文件。
+请注意 kubeadm CLI 命令不会修改此文件。
 
 通过 `kubeadm` [DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf) 或者 [RPM 包](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf) 安装的配置文件已被写入 `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` 并由系统使用。
 它加强了基础设施 [`kubelet.service` for RPM](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/kubelet.service) (resp. [`kubelet.service` for DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/kubelet.service)))：
@@ -372,7 +372,7 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是：
 
 | Package name | Description |
 |--------------|-------------|
-| `kubeadm`    | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 插件](#the-kubelet-drop-in-file-for-systemd)。 |
+| `kubeadm`    | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 的 systemd 文件](#the-kubelet-drop-in-file-for-systemd)。 |
 | `kubelet`    | 安装 `/usr/bin/kubelet` 二进制文件和 `/opt/cni/bin` CNI 二进制文件。 |
 | `kubectl`    | 安装 `/usr/bin/kubectl` 二进制文件。 |
 | `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-incubator/cri-tools)中安装 `/usr/bin/crictl` 二进制文件。 |
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md
index 66444b3101..d02d2b7a0c 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/self-hosting.md
@@ -1,18 +1,12 @@
 ---
-reviewers:
-- sig-cluster-lifecycle
 title: 配置您的 kubernetes 集群以自托管控制平台
 content_type: concept
 weight: 100
 ---
 <!--
----
-reviewers:
-- sig-cluster-lifecycle
 title: Configuring your kubernetes cluster to self-host the control plane
 content_type: concept
 weight: 100
----
 -->
 
 <!-- overview -->
@@ -30,15 +24,17 @@ configured via the Kubernetes API instead of [static pods](/docs/tasks/administe
 configured in the kubelet via static files.
 -->
 kubeadm 允许您实验性地创建 _self-hosted_ Kubernetes 控制平面。
-这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以 [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) 的身份运行，而不是通过静态文件将 [static pods](/docs/tasks/administer-cluster/static-pod/) 在 kubelet 中配置。
+这意味着 API 服务器，控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以
+[DaemonSet Pods](/zh/docs/concepts/workloads/controllers/daemonset/) 的身份运行，
+而不是通过静态文件在 kubelet 中配置[静态 Pods](/zh/docs/tasks/configure-pod-container/static-pod/)。
 
 <!--
 To create a self-hosted cluster see the
 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
 -->
-要创建自托管集群，请参见 [kubeadm alpha 自托管枢纽](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) 命令。
-
-
+要创建自托管集群，请参见
+[kubeadm alpha selfhosting pivot](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
+命令。
 
 <!-- body -->
 
@@ -47,11 +43,11 @@ To create a self-hosted cluster see the
 -->
 #### 警告
 
-{{< caution >}}
 <!--
 This feature pivots your cluster into an unsupported state, rendering kubeadm unable
 to manage you cluster any longer. This includes `kubeadm upgrade`.
 -->
+{{< caution >}}
 此功能将您的集群设置为不受支持的状态，从而使 kubeadm 无法再管理您的集群。
 这包括 `kubeadm 升级` 。
 {{< /caution >}}
@@ -62,7 +58,7 @@ to manage you cluster any longer. This includes `kubeadm upgrade`.
   without manual intervention.
 -->
 1. 1.8及更高版本中的自托管功能有一些重要限制。
-特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
+   特别是，自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
 
 <!--
 1. By default, self-hosted control plane Pods rely on credentials loaded from
@@ -70,30 +66,30 @@ to manage you cluster any longer. This includes `kubeadm upgrade`.
   volumes. Except for initial creation, these credentials are not managed by
   kubeadm.
 -->
-1. 默认情况下，自托管的控制平面 Pod 依赖于从  [`hostPath`](/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
-除初始创建外，这些凭据不由 kubeadm 管理。
+2. 默认情况下，自托管的控制平面 Pod 依赖于从
+   [`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
+   除初始创建外，这些凭据不由 kubeadm 管理。
 
 <!--
 1. The self-hosted portion of the control plane does not include etcd,
   which still runs as a static Pod.
 -->
-1. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。
+3. 控制平面的自托管部分不包括 etcd，后者仍作为静态 Pod 运行。
 
 <!--
 #### Process
--->
-#### 处理
 
-<!--
 The self-hosting bootstrap process is documented in the [kubeadm design
 document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
 -->
-自托管引导过程记录在 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
+#### 过程
+
+自托管引导过程描述于 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
 
 <!--
 In summary, `kubeadm alpha selfhosting` works as follows:
 -->
-总而言之，`kubeadm alpha 自托管` 的工作原理如下：
+总体而言，`kubeadm alpha 自托管` 的工作原理如下：
 
 <!--
   1. Waits for this bootstrap static control plane to be running and
@@ -107,28 +103,27 @@ In summary, `kubeadm alpha selfhosting` works as follows:
     It also modifies these manifests where necessary, for example adding new volumes
     for secrets.
 -->
-  1. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
+  2. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单，这些清单将运行自托管的控制平面。
      它还会在必要时修改这些清单，例如添加新的秘密卷。
 
 <!--
   1. Creates DaemonSets in the `kube-system` namespace and waits for the
      resulting Pods to be running.
 -->
-  1. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。
+  3. 在 `kube-system` 名称空间中创建 DaemonSets ，并等待生成的 Pod 运行。
 
 <!--
   1. Once self-hosted Pods are operational, their associated static Pods are deleted
      and kubeadm moves on to install the next component. This triggers kubelet to
      stop those static Pods.
 -->
- 1. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
-    这将触发 kubelet 停止那些静态 Pod 。
+  4. 自托管 Pod 运行后，将删除其关联的静态 Pod，然后 kubeadm 继续安装下一个组件。
+     这将触发 kubelet 停止那些静态 Pod 。
 
 <!--
   1. When the original static control plane stops, the new self-hosted control
     plane is able to bind to listening ports and become active.
 -->
-  1. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。
-
+  5. 当原始静态控制平面停止时，新的自托管控制平面能够绑定到侦听端口并变为活动状态。
 
 
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index e79718b204..b29cf2215c 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -414,17 +414,15 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这
     -->
     - 将 `${HOST0}` 设置为要测试的主机的 IP 地址
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 Once your have a working 3 member etcd cluster, you can continue setting up a
 highly available control plane using the [external etcd method with
 kubeadm](/docs/setup/independent/high-availability/).
 -->
-一旦拥有了一个正常工作的 3 成员的 etcd 集群，你就可以基于[使用 kubeadm 的外部 etcd 方法](/docs/setup/independent/high-availability/)，继续部署一个高可用的控制平面。
-
+一旦拥有了一个正常工作的 3 成员的 etcd 集群，你就可以基于
+[使用 kubeadm 的外部 etcd 方法](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)，
+继续部署一个高可用的控制平面。
 
 
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index 43176afae3..a5cf846a30 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -5,11 +5,9 @@ weight: 20
 ---
 
 <!--
----
 title: Troubleshooting kubeadm
 content_type: concept
 weight: 20
----
 -->
 <!-- overview -->
 
@@ -26,19 +24,18 @@ If your problem is not listed below, please follow the following steps:
 - If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
   relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
 -->
-与任何程序一样，您可能会在安装或者运行 kubeadm 时遇到错误。
-本文列举了一些常见的故障场景，并提供可帮助您理解和解决这些问题的步骤。
+与任何程序一样，你可能会在安装或者运行 kubeadm 时遇到错误。
+本文列举了一些常见的故障场景，并提供可帮助你理解和解决这些问题的步骤。
 
-如果您的问题未在下面列出，请执行以下步骤：
+如果你的问题未在下面列出，请执行以下步骤：
 
-- 如果您认为问题是 kubeadm 的错误：
+- 如果你认为问题是 kubeadm 的错误：
   - 转到 [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) 并搜索存在的问题。
   - 如果没有问题，请 [打开](https://github.com/kubernetes/kubeadm/issues/new) 并遵循问题模板。
 
-- 如果您对 kubeadm 的工作方式有疑问，可以在 [Slack](http://slack.k8s.io/) 上的 #kubeadm 频道提问，
+- 如果你对 kubeadm 的工作方式有疑问，可以在 [Slack](https://slack.k8s.io/) 上的 #kubeadm 频道提问，
 或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。
-请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助您。
-
+请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助你。
 
 
 <!-- body -->
@@ -67,8 +64,8 @@ Then you may be missing `ebtables`, `ethtool` or a similar executable on your no
 [preflight] WARNING: ethtool not found in system path
 ```
 
-那么或许在您的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
-您可以使用以下命令安装它们：
+那么或许在你的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。
+你可以使用以下命令安装它们：
 
 - 对于 Ubuntu/Debian 用户，运行 `apt install ebtables ethtool` 命令。
 - 对于 CentOS/Fedora 用户，运行 `yum install ebtables ethtool` 命令。
@@ -84,7 +81,7 @@ If you notice that `kubeadm init` hangs after printing out the following line:
 -->
 ## 在安装过程中，kubeadm 一直等待控制平面就绪
 
-如果您注意到 `kubeadm init` 在打印以下行后挂起：
+如果你注意到 `kubeadm init` 在打印以下行后挂起：
 
 ```sh
 [apiclient] Created API client, waiting for the control plane to become ready
@@ -114,9 +111,9 @@ This may be caused by a number of problems. The most common are:
 -->
 这可能是由许多问题引起的。最常见的是：
 
-- 网络连接问题。在继续之前，请检查您的计算机是否具有全部联通的网络连接。
+- 网络连接问题。在继续之前，请检查你的计算机是否具有全部联通的网络连接。
 - kubelet 的默认 cgroup 驱动程序配置不同于 Docker 使用的配置。
-  检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果您看见以下内容：
+  检查系统日志文件 (例如 `/var/log/message`) 或检查 `journalctl -u kubelet` 的输出。 如果你看见以下内容：
 
   ```shell
   error: failed to run Kubelet: failed to create kubelet:
@@ -125,12 +122,12 @@ This may be caused by a number of problems. The most common are:
 
   有两种常见方法可解决 cgroup 驱动程序问题：
 
- 1. 按照 [此处](/docs/setup/production-environment/container-runtimes/#docker) 的说明再次安装 Docker。
+  1. 按照 [此处](/zh/docs/setup/production-environment/container-runtimes/#docker) 的说明再次安装 Docker。
 
- 1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，您可以参考
-    [在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+  1. 更改 kubelet 配置以手动匹配 Docker cgroup 驱动程序，你可以参考
+     [在主节点上配置 kubelet 要使用的 cgroup 驱动程序](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
 
-- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。您可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
+- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。你可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。
 
 <!--
 ## kubeadm blocks when removing managed containers
@@ -181,7 +178,7 @@ sudo kubeadm reset
 
 检查 docker 的日志也可能有用：
 
-```sh
+```shell
 journalctl -ul docker
 ```
 
@@ -209,15 +206,17 @@ Right after `kubeadm init` there should not be any pods in these states.
 
 - 在 `kubeadm init` 命令执行完后，如果有 pods 处于这些状态之一，请在 kubeadm
   仓库提起一个 issue。`coredns` (或者 `kube-dns`) 应该处于 `Pending` 状态，
-  直到您部署了网络解决方案为止。
+  直到你部署了网络解决方案为止。
+
 - 如果在部署完网络解决方案之后，有 Pods 处于 `RunContainerError`、`CrashLoopBackOff`
   或 `Error` 状态之一，并且`coredns` （或者 `kube-dns`）仍处于 `Pending` 状态，
-  那很可能是您安装的网络解决方案由于某种原因无法工作。您或许需要授予它更多的
+  那很可能是你安装的网络解决方案由于某种原因无法工作。你或许需要授予它更多的
   RBAC 特权或使用较新的版本。请在 Pod Network 提供商的问题跟踪器中提交问题，
   然后在此处分类问题。
-- 如果您安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
+
+- 如果你安装的 Docker 版本早于 1.12.1，请在使用 `systemd` 来启动 `dockerd` 和重启 `docker` 时，
   删除 `MountFlags=slave` 选项。
-  您可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
+  你可以在 `/usr/lib/systemd/system/docker.service` 中看到 MountFlags。
   MountFlags 可能会干扰 Kubernetes 挂载的卷， 并使 Pods 处于 `CrashLoopBackOff` 状态。
   当 Kubernetes 不能找到 `var/run/secrets/kubernetes.io/serviceaccount` 文件时会发生错误。
 
@@ -232,8 +231,8 @@ before CoreDNS may be deployed fully. Hence the `Pending` state before the netwo
 ## `coredns` （或 `kube-dns`）停滞在 `Pending` 状态
 
 这一行为是 **预期之中** 的，因为系统就是这么设计的。
-kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod 的网络解决方案](/docs/concepts/cluster-administration/addons/)。
-您必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
+kubeadm 的网络供应商是中立的，因此管理员应该选择 [安装 pod 的网络解决方案](/zh/docs/concepts/cluster-administration/addons/)。
+你必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。
 在网络被配置好之前，DNS 组件会一直处于 `Pending` 状态。
 
 <!--
@@ -252,14 +251,16 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
 -->
 ## `HostPort` 服务无法工作
 
-此 `HostPort` 和 `HostIP` 功能是否可用取决于您的 Pod 网络配置。请联系 Pod 解决方案的作者，
+此 `HostPort` 和 `HostIP` 功能是否可用取决于你的 Pod 网络配置。请联系 Pod 解决方案的作者，
 以确认 `HostPort` 和 `HostIP` 功能是否可用。
 
 已验证 Calico、Canal 和 Flannel CNI 驱动程序支持 HostPort。
 
 有关更多信息，请参考 [CNI portmap 文档](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
 
-如果您的网络提供商不支持 portmap CNI 插件，您或许需要使用 [NodePort 服务的功能](/docs/concepts/services-networking/service/#nodeport) 或者使用 `HostNetwork=true`。
+如果你的网络提供商不支持 portmap CNI 插件，你或许需要使用
+[NodePort 服务的功能](/zh/docs/concepts/services-networking/service/#nodeport)
+或者使用 `HostNetwork=true`。
 
 <!--
 ## Pods are not accessible via their Service IP
@@ -277,10 +278,11 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
 -->
 ## 无法通过其服务 IP 访问 Pod
 
-- 许多网络附加组件尚未启用 [hairpin 模式](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
-  该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
+- 许多网络附加组件尚未启用 [hairpin 模式](/zh/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
+  该模式允许 Pod 通过其服务 IP 进行访问。这是与 [CNI](https://github.com/containernetworking/cni/issues/476) 有关的问题。
+  请与网络附加组件提供商联系，以获取他们所提供的 hairpin 模式的最新状态。
 
-- 如果您正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，您需要
+- 如果你正在使用 VirtualBox (直接使用或者通过 Vagrant 使用)，你需要
   确保 `hostname -i` 返回一个可路由的 IP 地址。默认情况下，第一个接口连接不能路由的仅主机网络。
   解决方法是修改 `/etc/hosts`，请参考示例 [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)。
 
@@ -334,19 +336,19 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
   可以用于查看证书信息。
 - 使用如下方法取消设置 `KUBECONFIG` 环境变量的值：
 
-  ```sh
+  ```shell
   unset KUBECONFIG
   ```
 
   或者将其设置为默认的 `KUBECONFIG` 位置：
 
-  ```sh
+  ```shell
   export KUBECONFIG=/etc/kubernetes/admin.conf
   ```
 
 - 另一个方法是覆盖 `kubeconfig` 的现有用户 "管理员" ：
 
-  ```sh
+  ```shell
   mv  $HOME/.kube $HOME/.kube.bak
   mkdir $HOME/.kube
   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
@@ -366,7 +368,7 @@ Error from server (NotFound): the server could not find the requested resource
 
   Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.
 
-  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
+  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `-iface eth1` flag to flannel so that the second interface is chosen.
 -->
 ## 在 Vagrant 中使用 flannel 作为 pod 网络时的默认 NIC
 
@@ -401,7 +403,7 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
   curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
   ```
 
-  The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
+  The workaround is to tell `kubelet` which IP to use using `-node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
 
   Then restart `kubelet`:
 
@@ -433,14 +435,15 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
 
   解决方法是通知 `kubelet` 使用哪个 `--node-ip`。当使用 Digital Ocean 时，可以是公网IP（分配给 `eth0`的），
   或者是私网IP（分配给 `eth1` 的）。私网 IP 是可选的。
-  这个 [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。
+  [kubadm `NodeRegistrationOptions` 结构的 `KubeletExtraArgs` 部分](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) 被用来处理这种情况。
 
   然后重启 `kubelet`：
 
-  ```sh
+  ```shell
   systemctl daemon-reload
   systemctl restart kubelet
   ```
+
 <!--
 ## `coredns` pods have `CrashLoopBackOff` or `Error` state
 
@@ -463,15 +466,16 @@ are available to avoid Kubernetes trying to restart the CoreDNS Pod every time C
 -->
 ## `coredns` pods 有 `CrashLoopBackOff` 或者 `Error` 状态
 
-如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，您或许会遇到 `coredns` pods 无法启动的情况。
-要解决此问题，您可以尝试以下选项之一：
+如果有些节点运行的是旧版本的 Docker，同时启用了 SELinux，你或许会遇到 `coredns` pods 无法启动的情况。
+要解决此问题，你可以尝试以下选项之一：
 
-- 升级到 [Docker 的较新版本](/docs/setup/production-environment/container-runtimes/#docker)。
+- 升级到 [Docker 的较新版本](/zh/docs/setup/production-environment/container-runtimes/#docker)。
 
 - [禁用 SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
+
 - 修改 `coredns` 部署以设置 `allowPrivilegeEscalation` 为 `true`：
 
-```bash
+```shell
 kubectl -n kube-system get deployment coredns -o yaml | \
   sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
   kubectl apply -f -
@@ -481,11 +485,11 @@ CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部
 到环路时。[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
 可以避免在每次 CoreDNS 监测到循环并退出时，Kubernetes 尝试重启 CoreDNS Pod 的情况。
 
-{{< warning >}}
 <!--
 Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
 the security of your cluster.
 -->
+{{< warning >}}
 禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
 {{< /warning >}}
 
@@ -510,65 +514,72 @@ yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1
 
 - Install one of the more recent recommended versions, such as 18.06:
 ```bash
-sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
+sudo yum-config-manager -add-repo https://download.docker.com/linux/centos/docker-ce.repo
 yum install docker-ce-18.06.1.ce-3.el7.x86_64
 ```
 -->
 ## etcd pods 持续重启
 
-如果您遇到以下错误：
+如果你遇到以下错误：
 
 ```
 rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
 ```
 
-如果您使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
+如果你使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。
 此版本的 Docker 会阻止 kubelet 在 etcd 容器中执行。
 
 为解决此问题，请选择以下选项之一：
 
 - 回滚到早期版本的 Docker，例如 1.13.1-75
-```
-yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
-```
+
+  ```shell
+  yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
+  ```
 
 - 安装较新的推荐版本之一，例如 18.06:
-```bash
-sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
-yum install docker-ce-18.06.1.ce-3.el7.x86_64
-```
+
+  ```shell
+  sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
+  yum install docker-ce-18.06.1.ce-3.el7.x86_64
+  ```
 
 <!--
-## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
+## Not possible to pass a comma separated list of values to arguments inside a `-component-extra-args` flag
 
-`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
+`kubeadm init` flags such as `-component-extra-args` allow you to pass custom arguments to a control-plane
 component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
 the values (`mapStringString`).
 
 If you decide to pass an argument that supports multiple, comma-separated values such as
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
+`-apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
 `flag: malformed pair, expect string=string`. This happens because the list of arguments for
-`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
+`-apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
 as a key that is missing a value.
 
 Alternatively, you can try separating the `key=value` pairs like so:
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
+`-apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
 but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
 
 A known workaround is to use the kubeadm [configuration file](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
 -->
 ## 无法将以逗号分隔的值列表传递给 `--component-extra-args` 标志内的参数
 
-`kubeadm init` 标志例如 `--component-extra-args` 允许您将自定义参数传递给像 kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。
+`kubeadm init` 标志例如 `--component-extra-args` 允许你将自定义参数传递给像
+kube-apiserver 这样的控制平面组件。然而，由于解析 (`mapStringString`) 的基础类型值，此机制将受到限制。
 
-如果您决定传递一个支持多个逗号分隔值（例如 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，将出现 `flag: malformed pair, expect string=string` 错误。
-发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，而这里的 `NamespacesExists` 被误认为是缺少取值的键名。
+如果你决定传递一个支持多个逗号分隔值（例如
+`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`）参数，
+将出现 `flag: malformed pair, expect string=string` 错误。
+发生这种问题是因为参数列表 `--apiserver-extra-args` 预期的是 `key=value` 形式，
+而这里的 `NamespacesExists` 被误认为是缺少取值的键名。
 
 一种解决方法是尝试分离 `key=value` 对，像这样：
 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
 但这将导致键 `enable-admission-plugins` 仅有值 `NamespaceExists`。
 
-已知的解决方法是使用 kubeadm [配置文件](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。
+已知的解决方法是使用 kubeadm
+[配置文件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)。
 
 <!--
 ## kube-proxy scheduled before node is initialized by cloud-controller-manager
@@ -599,17 +610,20 @@ The tracking issue for this problem is [here](https://github.com/kubernetes/kube
 这会导致 kube-proxy 无法正确获取节点的 IP 地址，并对管理负载平衡器的代理功能产生连锁反应。
 
 在 kube-proxy Pod 中可以看到以下错误：
+
 ```
 server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
 proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
 ```
 
-一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
-```
+一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它，
+而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除：
+
+```shell
 kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
 ```
 
-此问题的跟踪 [在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
+此问题的跟踪[在这里](https://github.com/kubernetes/kubeadm/issues/1027)。
 
 <!--
 ## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
@@ -631,20 +645,21 @@ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
 -->
 ## NodeRegistration.Taints 字段在编组 kubeadm 配置时丢失
 
-*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358) 仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*
+*注意：这个 [问题](https://github.com/kubernetes/kubeadm/issues/1358) 
+仅适用于操控 kubeadm 数据类型的工具（例如，YAML 配置文件）。它将在 kubeadm API v1beta2 修复。*
 
 默认情况下，kubeadm 将 `node-role.kubernetes.io/master:NoSchedule` 污点应用于控制平面节点。
-如果您希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
+如果你希望 kubeadm 不污染控制平面节点，并将 `InitConfiguration.NodeRegistration.Taints` 设置成空切片，则应在编组时省略该字段。
 如果省略该字段，则 kubeadm 将应用默认污点。
 
 至少有两种解决方法：
 
 1. 使用 `node-role.kubernetes.io/master:PreferNoSchedule` 污点代替空切片。
-除非其他节点具有容量，[否则将在主节点上调度 Pods](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)。
+  除非其他节点具有容量，[否则将在主节点上调度 Pods](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
 
 2. 在 kubeadm init 退出后删除污点：
-```bash
-kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
-```
 
+   ```shell
+   kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
+   ```
 
diff --git a/content/zh/docs/setup/production-environment/tools/kubespray.md b/content/zh/docs/setup/production-environment/tools/kubespray.md
new file mode 100644
index 0000000000..126d1a1305
--- /dev/null
+++ b/content/zh/docs/setup/production-environment/tools/kubespray.md
@@ -0,0 +1,256 @@
+---
+title: 使用 Kubespray 安装 Kubernetes
+content_type: concept
+weight: 30
+---
+<!--
+title: Installing Kubernetes with Kubespray
+content_type: concept
+weight: 30
+-->
+
+<!-- overview -->
+
+<!--
+This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
+-->
+此快速入门有助于使用 [Kubespray](https://github.com/kubernetes-sigs) 安装在 GCE、Azure、OpenStack、AWS、vSphere、Packet（裸机）、Oracle Cloud Infrastructure（实验性）或 Baremetal 上托管的 Kubernetes 集群。
+
+<!--
+Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+-->
+Kubespray 是一个由 [Ansible](https://docs.ansible.com/) playbooks、[清单（inventory）](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md)、供应工具和通用 OS/Kubernetes 集群配置管理任务的领域知识组成的。 Kubespray 提供：
+
+<!--
+* a highly available cluster
+* composable attributes
+* support for most popular Linux distributions
+  * Ubuntu 16.04, 18.04, 20.04
+  * CentOS/RHEL/Oracle Linux 7, 8
+  * Debian Buster, Jessie, Stretch, Wheezy
+  * Fedora 31, 32
+  * Fedora CoreOS
+  * openSUSE Leap 15
+  * Flatcar Container Linux by Kinvolk
+* continuous integration tests
+-->
+* 高可用性集群
+* 可组合属性
+* 支持大多数流行的 Linux 发行版
+   * Ubuntu 16.04、18.04、20.04
+   * CentOS / RHEL / Oracle Linux 7、8
+   * Debian Buster，Jessie，Stretch，Wheezy
+   * Fedora 31、32
+   * Fedora CoreOS
+   * openSUSE Leap 15
+   * Kinvolk 的 Flatcar Container Linux
+* 持续集成测试
+
+<!--
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
+-->
+要选择最适合你的用例的工具，请阅读[此比较](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)以
+ [kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 和 [kops](/zh/docs/setup/production-environment/tools/kops/) 。
+<!-- body -->
+
+<!--
+## Creating a cluster
+
+### (1/5) Meet the underlay requirements
+
+-->
+
+## 创建集群
+
+### （1/5）满足下层设施要求
+
+<!--
+Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
+-->
+按以下[要求](https://github.com/kubernetes-sigs/kubespray#requirements)来配置服务器：
+
+<!--
+* **Ansible v2.9 and python-netaddr is installed on the machine that will run Ansible commands**
+* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
+* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
+* The target servers are configured to allow **IPv4 forwarding**
+* **Your ssh key must be copied** to all the servers part of your inventory
+* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
+* If kubespray is ran from non-root user account, correct privilege escalation method should be configured in the target servers. Then the `ansible_become` flag or command parameters `--become` or `-b` should be specified
+-->
+* 在将运行 Ansible 命令的计算机上安装 Ansible v2.9 和 python-netaddr
+* **运行 Ansible Playbook 需要 Jinja 2.11（或更高版本）**
+* 目标服务器必须有权访问 Internet 才能拉取 Docker 镜像。否则，需要其他配置（[请参见离线环境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)）
+* 目标服务器配置为允许 IPv4 转发
+* **你的 SSH 密钥必须复制**到清单中的所有服务器部分
+* 防火墙不受管理，你将需要按照以前的方式实施自己的规则。为了避免在部署过程中出现任何问题，你应该禁用防火墙
+* 如果从非 root 用户帐户运行 kubespray，则应在目标服务器中配置正确的特权升级方法。然后应指定“ansible_become” 标志或命令参数 “--become” 或 “-b”
+
+<!--
+Kubespray provides the following utilities to help provision your environment:
+
+* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
+  * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
+  * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
+  * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
+-->
+Kubespray 提供以下实用程序来帮助你设置环境：
+
+* 为以下云驱动提供的 [Terraform](https://www.terraform.io/) 脚本：
+* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
+* [OpenStack](http://sitebeskuethree/contrigetbernform/contribeskubernform/contribeskupernform/https/sitebesku/master/)
+* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
+
+<!--
+### (2/5) Compose an inventory file
+
+After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+
+### (3/5) Plan your cluster deployment
+
+Kubespray provides the ability to customize many aspects of the deployment:
+
+-->
+### （2/5）编写清单文件
+
+设置服务器后，请创建一个 [Ansible 的清单文件](https://docs.ansible.com/ansible/intro_inventory.html)。你可以手动执行此操作，也可以通过动态清单脚本执行此操作。有关更多信息，请参阅“[建立你自己的清单](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)”。
+
+### （3/5）规划集群部署
+
+Kubespray 能够自定义部署的许多方面：
+
+<!--
+* Choice deployment mode: kubeadm or non-kubeadm
+* CNI (networking) plugins
+* DNS configuration
+* Choice of control plane: native/binary or containerized
+* Component versions
+* Calico route reflectors
+* Component runtime options
+  * {{< glossary_tooltip term_id="docker" >}}
+  * {{< glossary_tooltip term_id="containerd" >}}
+  * {{< glossary_tooltip term_id="cri-o" >}}
+* Certificate generation methods
+-->
+* 选择部署模式： kubeadm 或非 kubeadm
+* CNI（网络）插件
+* DNS 配置
+* 控制平面的选择：本机/可执行文件或容器化
+* 组件版本
+* Calico 路由反射器
+* 组件运行时选项
+  * {{< glossary_tooltip term_id="docker" >}}
+  * {{< glossary_tooltip term_id="containerd" >}}
+  * {{< glossary_tooltip term_id="cri-o" >}}
+* 证书生成方式
+
+<!--
+Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+-->
+
+可以修改[变量文件](https://docs.ansible.com/ansible/playbooks_variables.html)以进行 Kubespray 定制。
+如果你刚刚开始使用 Kubespray，请考虑使用 Kubespray 默认设置来部署你的集群并探索 Kubernetes 。
+<!--
+### (4/5) Deploy a Cluster
+
+Next, deploy your cluster:
+
+Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
+-->
+
+### （4/5）部署集群
+
+接下来，部署你的集群：
+
+使用 [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment) 进行j集群部署。
+
+```shell
+ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
+  --private-key=~/.ssh/private_key
+```
+<!--
+Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results.
+-->
+大型部署（超过 100 个节点）可能需要[特定的调整](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)，以获得最佳效果。
+
+<!--
+### (5/5) Verify the deployment
+
+Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
+-->
+### （5/5）验证部署
+
+Kubespray 提供了一种使用 [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md)
+验证 Pod 间连接和 DNS 解析的方法。
+Netchecker 确保 netchecker-agents pod 可以解析。
+DNS 请求并在默认名称空间内对每个请求执行 ping 操作。
+这些 Pods 模仿其余工作负载的类似行为，并用作集群运行状况指示器。
+<!--
+## Cluster operations
+
+Kubespray provides additional playbooks to manage your cluster: _scale_ and _upgrade_.
+-->
+## 集群操作
+
+Kubespray 提供了其他 Playbooks 来管理集群： _scale_ 和 _upgrade_。
+<!--
+### Scale your cluster
+
+You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
+You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
+-->
+### 扩展集群
+
+你可以通过运行 scale playbook 向集群中添加工作节点。有关更多信息，
+请参见 “[添加节点](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)”。
+你可以通过运行 remove-node playbook 来从集群中删除工作节点。有关更多信息，
+请参见 “[删除节点](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)”。
+<!--
+### Upgrade your cluster
+
+You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)".
+-->
+### 升级集群
+
+你可以通过运行 upgrade-cluster Playbook 来升级集群。有关更多信息，请参见
+“[升级](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)”。
+<!--
+## Cleanup
+
+You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml).
+
+{{< caution >}}
+When running the reset playbook, be sure not to accidentally target your production cluster!
+{{< /caution >}}
+-->
+## 清理
+
+你可以通过 [reset](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml) Playbook
+重置节点并清除所有与 Kubespray 一起安装的组件。
+
+{{< caution >}}
+运行 reset playbook 时，请确保不要意外地将生产集群作为目标！
+{{< /caution >}}
+
+<!--
+## Feedback
+
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
+* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
+-->
+## 反馈
+
+* Slack 频道：[#kubespray](https://kubernetes.slack.com/messages/kubespray/)（你可以在[此处](https://slack.k8s.io/)获得邀请）
+* [GitHub 问题](https://github.com/kubernetes-sigs/kubespray/issues)
+
+<!--
+## {{% heading "whatsnext" %}}
+
+
+Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
+-->
+## {{％heading“ whatsnext”％}}
+
+
+查看有关 Kubespray 的[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)的计划工作。
diff --git a/content/zh/docs/setup/production-environment/turnkey-solutions.md b/content/zh/docs/setup/production-environment/turnkey-solutions.md
new file mode 100644
index 0000000000..b8a4f55661
--- /dev/null
+++ b/content/zh/docs/setup/production-environment/turnkey-solutions.md
@@ -0,0 +1,25 @@
+---
+title: Turnkey 云解决方案
+content_type: concept
+weight: 30
+---
+<!-- 
+---
+title: Turnkey Cloud Solutions
+content_type: concept
+weight: 30
+---
+-->
+<!-- overview -->
+
+<!-- 
+This page provides a list of Kubernetes certified solution providers. From each
+provider page, you can learn how to install and setup production
+ready clusters.
+-->
+本页列示 Kubernetes 认证解决方案供应商。
+在每一个供应商分页，你可以学习如何安装和设置生产就绪的集群。
+
+<!-- body -->
+
+{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}}
diff --git a/content/zh/docs/setup/production-environment/turnkey/_index.md b/content/zh/docs/setup/production-environment/turnkey/_index.md
deleted file mode 100644
index 5faa0f682c..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: Turnkey 云解决方案
-weight: 30
----
diff --git a/content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md b/content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md
deleted file mode 100644
index 055d1c41c3..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-reviewers:
-- colemickens
-- brendandburns
-title: 在阿里云上运行 Kubernetes
----
-<!--
----
-reviewers:
-- colemickens
-- brendandburns
-title: Running Kubernetes on Alibaba Cloud
----
--->
-
-<!--
-## Alibaba Cloud Container Service
-
-The [Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service) lets you run and manage Docker applications on a cluster of Alibaba Cloud ECS instances. It supports the popular open source container orchestrators: Docker Swarm and Kubernetes.
-
-To simplify cluster deployment and management, use [Kubernetes Support for Alibaba Cloud Container Service](https://www.alibabacloud.com/product/kubernetes). You can get started quickly by following the [Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm), and there are some [tutorials for Kubernetes Support on Alibaba Cloud](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1) in Chinese.
-
-To use custom binaries or open source Kubernetes, follow the instructions below.
--->
-## 阿里云容器服务
-
-[阿里云容器服务](https://www.alibabacloud.com/product/container-service)使您可以在阿里云 ECS 实例集群上运行和管理 Docker 应用程序。它支持流行的开源容器编排引擎：Docker Swarm 和 Kubernetes。
-
-为了简化集群的部署和管理，请使用 [容器服务 Kubernetes 版](https://www.alibabacloud.com/product/kubernetes)。您可以按照 [Kubernetes 演练](https://www.alibabacloud.com/help/doc-detail/86737.htm)快速入门，其中有一些使用中文书写的[容器服务 Kubernetes 版教程](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)。
-
-要使用自定义二进制文件或开源版本的 Kubernetes，请按照以下说明进行操作。
-
-<!--
-## Custom Deployments
-
-The source code for [Kubernetes with Alibaba Cloud provider implementation](https://github.com/AliyunContainerService/kubernetes) is open source and available on GitHub.
-
-For more information, see "[Quick deployment of Kubernetes - VPC environment on Alibaba Cloud](https://www.alibabacloud.com/forum/read-830)" in English and [Chinese](https://yq.aliyun.com/articles/66474).
--->
-## 自定义部署
-
-[阿里云 Kubernetes Cloud Provider 实现](https://github.com/AliyunContainerService/kubernetes) 的源代码是开源的，可在 GitHub 上获得。
-
-有关更多信息，请参阅中文版本[快速部署 Kubernetes - 阿里云上的VPC环境](https://yq.aliyun.com/articles/66474)和[英文版本](https://www.alibabacloud.com/forum/read-830)。
\ No newline at end of file
diff --git a/content/zh/docs/setup/production-environment/turnkey/aws.md b/content/zh/docs/setup/production-environment/turnkey/aws.md
deleted file mode 100644
index 64bff1dab9..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/aws.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-reviewers:
-- justinsb
-- clove
-title: 在 AWS EC2 上运行 Kubernetes
-content_type: task
----
-<!--
----
-reviewers:
-- justinsb
-- clove
-title: Running Kubernetes on AWS EC2
-content_type: task
----
--->
-
-
-<!-- overview -->
-
-<!--
-This page describes how to install a Kubernetes cluster on AWS.
--->
-本页面介绍了如何在 AWS 上安装 Kubernetes 集群。
-
-
-
-## {{% heading "prerequisites" %}}
-
-<!--
-To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
--->
-在 AWS 上创建 Kubernetes 集群，您将需要 AWS 的 Access Key ID 和 Secret Access Key。
-
-<!--
-### Supported Production Grade Tools
--->
-### 支持的生产级别工具
-
-<!--
-* [conjure-up](/docs/getting-started-guides/ubuntu/) is an open-source installer for Kubernetes that creates Kubernetes clusters with native AWS integrations on Ubuntu.
--->
-* [conjure-up](/docs/getting-started-guides/ubuntu/) 是 Kubernetes 的开源安装程序，可在 Ubuntu 上创建与原生 AWS 集成的 Kubernetes 集群。
-
-<!--
-* [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS.
--->
-* [Kubernetes Operations](https://github.com/kubernetes/kops) - 生产级 K8s 的安装、升级和管理。支持在 AWS 运行 Debian、Ubuntu、CentOS 和 RHEL。
-
-<!--
-* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
--->
-* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) 使用 [Flatcar Linux](https://www.flatcar-linux.org/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。
-
-<!--
-* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
--->
-* [KubeOne](https://github.com/kubermatic/kubeone) 是一个开源集群生命周期管理工具，它可用于创建，升级和管理高可用 Kubernetes 集群。
-
-
-
-<!-- steps -->
-
-<!--
-## Getting started with your cluster
--->
-## 集群入门
-
-<!--
-### Command line administration tool: kubectl
--->
-### 命令行管理工具：kubectl
-
-<!--
-The cluster startup script will leave you with a `kubernetes` directory on your workstation.
-Alternately, you can download the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases).
-
-Next, add the appropriate binary folder to your `PATH` to access kubectl:
--->
-集群启动脚本将在您的工作站上为您提供一个 `kubernetes` 目录。
-或者，您可以从[此页面](https://github.com/kubernetes/kubernetes/releases)下载最新的 Kubernetes 版本。
-
-接下来，将适当的二进制文件夹添加到您的 `PATH` 以访问 kubectl： 
-
-```shell
-# macOS
-export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
-
-# Linux
-export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
-```
-
-<!--
-An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/)
-
-By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
-For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
--->
-此工具的最新文档页面位于此处：[kubectl 手册](/docs/user-guide/kubectl/) 
-
-默认情况下，`kubectl` 将使用在集群启动期间生成的 `kubeconfig` 文件对 API 进行身份验证。
-有关更多信息，请阅读 [kubeconfig 文件](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
-
-<!--
-### Examples
-
-See [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
-
-The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
-
-For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)
--->
-### 示例
-
-请参阅[一个简单的 nginx 示例](/docs/tasks/run-application/run-stateless-application-deployment/)试用您的新集群。
-
-“Guestbook” 应用程序是另一个入门 Kubernetes 的流行示例：[guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)。
-
-有关更完整的应用程序，请查看[示例目录](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)。
-
-<!--
-## Scaling the cluster
-
-Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation.
--->
-## 集群伸缩
-
-不支持通过 `kubectl` 添加和删除节点。您仍然可以通过调整在安装过程中创建的 [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html) 中的 “Desired” 和 “Max” 属性来手动伸缩节点数量。
-
-<!--
-## Tearing down the cluster
-
-Make sure the environment variables you used to provision your cluster are still exported, then call the following script inside the
-`kubernetes` directory:
--->
-## 集群拆除
-
-确保您用于配置集群的环境变量已被导出，然后在运行如下在 Kubernetes 目录的脚本：
-
-```shell
-cluster/kube-down.sh
-```
-
-<!--
-## Support Level
-
-IaaS Provider        | Config. Mgmt | OS            | Networking  | Docs                                          | Conforms | Support Level
--------------------- | ------------ | ------------- | ----------  | --------------------------------------------- | ---------| ----------------------------
-AWS                  | kops         | Debian        | k8s (VPC)   | [docs](https://github.com/kubernetes/kops)    |          | Community ([@justinsb](https://github.com/justinsb))
-AWS                  | CoreOS       | CoreOS        | flannel     | [docs](/docs/getting-started-guides/aws)      |          | Community
-AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | [docs](/docs/getting-started-guides/ubuntu)      | 100%     | Commercial, Community
-AWS                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community
--->
-## 支持等级
-
-IaaS 提供商          | 配置管理     | 操作系统      | 网络        | 文档                                          | 符合率   | 支持等级 
--------------------- | ------------ | ------------- | ----------  | --------------------------------------------- | ---------| ----------------------------
-AWS                  | kops         | Debian        | k8s (VPC)   | [docs](https://github.com/kubernetes/kops)    |          | Community ([@justinsb](https://github.com/justinsb))
-AWS                  | CoreOS       | CoreOS        | flannel     | [docs](/docs/getting-started-guides/aws)      |          | Community
-AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | [docs](/docs/getting-started-guides/ubuntu)      | 100%     | Commercial, Community
-AWS                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community
-
-<!--
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
--->
-## 进一步阅读
-
-请参阅 [Kubernetes 文档](/docs/)了解有关管理和使用 Kubernetes 集群的更多详细信息。
-
-
diff --git a/content/zh/docs/setup/production-environment/turnkey/azure.md b/content/zh/docs/setup/production-environment/turnkey/azure.md
deleted file mode 100644
index a6db01d27a..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/azure.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-reviewers:
-- colemickens
-- brendandburns
-title: 在 Azure 上运行 Kubernetes
----
-
-<!--
----
-reviewers:
-- colemickens
-- brendandburns
-title: Running Kubernetes on Azure
----
--->
-
-<!--
-## Azure Kubernetes Service (AKS)
-
-The [Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/) offers simple
-deployments for Kubernetes clusters.
-
-For an example of deploying a Kubernetes cluster onto Azure via the Azure Kubernetes Service:
-
-**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/zh-cn/azure/aks/intro-kubernetes)**
--->
-
-## Azure Kubernetes 服务 (AKS)
-
-[Azure Kubernetes 服务](https://azure.microsoft.com/zh-cn/services/kubernetes-service/)提供了简单的
-Kubernetes 集群部署方式。
-
-有关通过 Azure Kubernetes 服务将 Kubernetes 集群部署到 Azure 的示例：
-
-**[微软 Azure Kubernetes 服务](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)**
-
-<!--
-## Custom Deployments: AKS-Engine
-
-The core of the Azure Kubernetes Service is **open source** and available on GitHub for the community
-to use and contribute to: **[AKS-Engine](https://github.com/Azure/aks-engine)**. The legacy [ACS-Engine](https://github.com/Azure/acs-engine) codebase has been deprecated in favor of AKS-engine.
-
-AKS-Engine is a good choice if you need to make customizations to the deployment beyond what the Azure Kubernetes
-Service officially supports. These customizations include deploying into existing virtual networks, utilizing multiple
-agent pools, and more. Some community contributions to AKS-Engine may even become features of the Azure Kubernetes Service.
-
-The input to AKS-Engine is an apimodel JSON file describing the Kubernetes cluster. It is similar to the Azure Resource Manager (ARM) template syntax used to deploy a cluster directly with the Azure Kubernetes Service. The resulting output is an ARM template that can be checked into source control and used to deploy Kubernetes clusters to Azure.
-
-You can get started by following the **[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**.
--->
-## 定制部署：AKS 引擎
-
-Azure Kubernetes 服务的核心是**开源**，并且可以在 GitHub 上让社区使用和参与贡献：**[AKS 引擎](https://github.com/Azure/aks-engine)**。旧版 [ACS 引擎](https://github.com/Azure/acs-engine) 代码库已被弃用，以支持AKS-engine。
-
-如果您需要在 Azure Kubernetes  服务正式支持的范围之外对部署进行自定义，则 AKS  引擎是一个不错的选择。这些自定义包括部署到现有虚拟网络中，利用多个代理程序池等。一些社区对 AKS 引擎的贡献甚至可能成为 Azure Kubernetes 服务的特性。
-
-AKS 引擎的输入是一个描述 Kubernetes 集群的 apimodel JSON 文件。它和用于直接通过 Azure Kubernetes 服务部署集群的 Azure 资源管理器（ARM）模板语法相似。产生的输出是一个 ARM 模板，可以将其签入源代码管理，并使用它将 Kubernetes 集群部署到 Azure。
-
-您可以按照 **[AKS 引擎 Kubernetes 教程](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**开始使用。
-
-<!--
-## CoreOS Tectonic for Azure
-
-The CoreOS Tectonic Installer for Azure is **open source** and available on GitHub for the community to use and contribute to: **[Tectonic Installer](https://github.com/coreos/tectonic-installer)**.
-
-Tectonic Installer is a good choice when you need to make cluster customizations as it is built on [Hashicorp's Terraform](https://www.terraform.io/docs/providers/azurerm/) Azure Resource Manager (ARM) provider. This enables users to customize or integrate using familiar Terraform tooling.
-
-You can get started using the [Tectonic Installer for Azure Guide](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html).
--->
-## 适用于 Azure 的 CoreOS Tectonic
-
-适用于 Azure 的 CoreOS Tectonic Installer 是**开源的**，它可以让社区在 GitHub 上使用和参与贡献：**[Tectonic Installer](https://github.com/coreos/tectonic-installer)**。
-
-当您需要进行自定义集群时，Tectonic Installer是一个不错的选择，因为它是基于 [Hashicorp 的 Terraform](https://www.terraform.io/docs/providers/azurerm/)，Azure资源管理器（ARM）提供程序构建的。这使用户可以使用熟悉的 Terraform 工具进行自定义或集成。
-
-您可以开始使用 [在 Azure 上安装 Tectonic 指南](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html)。
\ No newline at end of file
diff --git a/content/zh/docs/setup/production-environment/turnkey/clc.md b/content/zh/docs/setup/production-environment/turnkey/clc.md
deleted file mode 100644
index 6be7d06157..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/clc.md
+++ /dev/null
@@ -1,532 +0,0 @@
----
-title: 在 CenturyLink Cloud 上运行 Kubernetes
----
-<!--
----
-title: Running Kubernetes on CenturyLink Cloud
----
---->
-
-
-<!--
-These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
-
-You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
---->
-这些脚本适用于在 CenturyLink Cloud 上创建、删除和扩展 Kubernetes 集群。
-
-您可以使用单个命令完成所有任务。我们提供了用于执行这些任务的 Ansible 手册 [点击这里](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
-
-<!--
-## Find Help
-
-If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
-
-- Submit a github issue
-- Send an email to Kubernetes AT ctl DOT io
-- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
---->
-## 寻求帮助
-
-如果运行出现问题或者想要寻求帮助，我们非常乐意帮忙。通过以下方式获取帮助：
-
-- 提交 github issue
-- 给 Kubernetes AT ctl DOT io 发送邮件
-- 访问 [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
-
-<!--
-## Clusters of VMs or Physical Servers, your choice.
-
-- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
-- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
-- Physical serves are only available in the VA1 and GB3 data centers.
-- VMs are available in all 13 of our public cloud locations
---->
-## 基于 VM 或物理服务器的集群可供选择
-
-- 我们在虚拟机或物理服务器上都支持 Kubernetes 集群。如果要将物理服务器用于辅助 Node（minions），则只需使用 --minion_type=bareMetal 标志。
-- 有关物理服务器的更多信息，请访问： [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
-- 仅在 VA1 和 GB3 数据中心提供物理服务。
-- 13个公共云位置都可以使用虚拟机。
-
-<!--
-## Requirements
-
-The requirements to run this script are:
-
-- A linux administrative host (tested on ubuntu and macOS)
-- python 2 (tested on 2.7.11)
-  - pip (installed with python as of 2.7.9)
-- git
-- A CenturyLink Cloud account with rights to create new hosts
-- An active VPN connection to the CenturyLink Cloud from your linux host
---->
-## 要求
-
-运行此脚本的要求有：
-
-- Linux 管理主机（在 ubuntu 和 macOS 上测试）
-- python 2（在 2.7.11 版本上测试）
-   - pip（从 2.7.9 版开始与 python 一起安装）
-- git
-- 具有新建主机权限的 CenturyLink Cloud 帐户
-- 从 Linux 主机到 CenturyLink Cloud 的有效 VPN 连接
-
-<!--
-## Script Installation
-
-After you have all the requirements met, please follow these instructions to install this script.
-
-1) Clone this repository and cd into it.
---->
-## 脚本安装
-
-满足所有要求后，请按照以下说明安装此脚本。
-
-1）克隆此存储库并通过 cd 进入。
-
-```shell
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
-```
-
-<!--
-2) Install all requirements, including
---->
-2）安装所有要求的部分，包括
-
-  * Ansible
-  * CenturyLink Cloud SDK
-  * Ansible Modules
-
-```shell
-sudo pip install -r ansible/requirements.txt
-```
-
-<!--
-3) Create the credentials file from the template and use it to set your ENV variables
---->
-3）从模板创建凭证文件，并使用它来设置您的 ENV 变量
-
-```shell
-cp ansible/credentials.sh.template ansible/credentials.sh
-vi ansible/credentials.sh
-source ansible/credentials.sh
-
-```
-
-<!--
-4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)
---->
-4）使用内网的虚拟机或 [ 配置与 CenturyLink Cloud 网络的 VPN 连接.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)   授予您的计算机对 CenturyLink Cloud 网络的访问权限。
-
-<!--
-#### Script Installation Example: Ubuntu 14 Walkthrough
-
-If you use an ubuntu 14, for your convenience we have provided a step by step guide to install the requirements and install the script.
---->
-#### 脚本安装示例：Ubuntu 14 演练
-
-如果您使用 Ubuntu 14，为方便起见，我们会提供分步指导帮助安装必备条件和脚本。
-
-```shell
-# system
-apt-get update
-apt-get install -y git python python-crypto
-curl -O https://bootstrap.pypa.io/get-pip.py
-python get-pip.py
-
-# installing this repository
-mkdir -p ~home/k8s-on-clc
-cd ~home/k8s-on-clc
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
-cd adm-kubernetes-on-clc/
-pip install -r requirements.txt
-
-# getting started
-cd ansible
-cp credentials.sh.template credentials.sh; vi credentials.sh
-source credentials.sh
-```
-
-
-
-<!--
-## Cluster Creation
-
-To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete
-list of script options and some examples are listed below.
---->
-## 创建集群
-
-要创建一个新的 Kubernetes 集群，只需运行 ```kube-up.sh``` 脚本即可。以下是一套完整的脚本选项列表和一些示例。
-
-```shell
-CLC_CLUSTER_NAME=[name of kubernetes cluster]
-cd ./adm-kubernetes-on-clc
-bash kube-up.sh -c="$CLC_CLUSTER_NAME"
-```
-
-<!--
-It takes about 15 minutes to create the cluster. Once the script completes, it
-will output some commands that will help you setup kubectl on your machine to
-point to the new cluster.
-
-When the cluster creation is complete, the configuration files for it are stored
-locally on your administrative host, in the following directory
---->
-创建集群大约需要15分钟。脚本完成后，它将输出一些命令，这些命令将帮助您在计算机上设置 kubectl 以指向新集群。
-
-完成集群创建后，其配置文件会存储在本地管理主机的以下目录中
-
-```shell
-> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/
-```
-
-
-<!--
-#### Cluster Creation: Script Options
---->
-#### 创建集群：脚本选项
-
-```shell
-Usage: kube-up.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-All options (both short and long form) require arguments, and must include "="
-between option name and option value.
-
-     -h (--help)                   display this help and exit
-     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
-     -t= (--minion_type=)          standard -> VM (default), bareMetal -> physical]
-     -d= (--datacenter=)           VA1 (default)
-     -m= (--minion_count=)         number of kubernetes minion nodes
-     -mem= (--vm_memory=)          number of GB ram for each minion
-     -cpu= (--vm_cpu=)             number of virtual cps for each minion node
-     -phyid= (--server_conf_id=)   physical server configuration id, one of
-                                      physical_server_20_core_conf_id
-                                      physical_server_12_core_conf_id
-                                      physical_server_4_core_conf_id (default)
-     -etcd_separate_cluster=yes    create a separate cluster of three etcd nodes,
-                                   otherwise run etcd on the master node
-```
-
-<!--
-## Cluster Expansion
-
-To expand an existing Kubernetes cluster, run the ```add-kube-node.sh```
-script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options).
-This script must be run from the same host that created the cluster (or a host
-that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```).
---->
-## 扩展集群
- 
-要扩展现有的Kubernetes集群，请运行```add-kube-node.sh``` 脚本。脚本选项的完整列表和一些示例在 [下面](#cluster-expansion-script-options) 列出。该脚本必须运行在创建集群的同一个主机（或储存集群工件文件的 ```~/.clc_kube/$cluster_name``` 主机）。
-
-```shell
-cd ./adm-kubernetes-on-clc
-bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
-```
-
-<!--
-#### Cluster Expansion: Script Options
---->
-#### 扩展集群：脚本选项
-
-```shell
-Usage: add-kube-node.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and add to an
-existing CLC kubernetes cluster
-
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-     -h (--help)                   display this help and exit
-     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
-     -m= (--minion_count=)         number of kubernetes minion nodes to add
-```
-
-<!--
-## Cluster Deletion
-
-There are two ways to delete an existing cluster:
-
-1) Use our python script:
---->
-## 删除集群
-
-有两种方法可以删除集群：
-
-1）使用 Python 脚本：
-
-```shell
-python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1
-```
-
-<!--
-2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
-Cloud control portal and delete the parent server group that contains the
-Kubernetes Cluster. We hope to add a scripted option to do this soon.
---->
-2）使用 CenturyLink Cloud UI。要删除集群，请登录 CenturyLink Cloud 控制页面并删除包含 Kubernetes 集群的父服务器组。我们希望能够添加脚本选项以尽快完成此操作。
-
-<!--
-## Examples
-
-Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
---->
-## 示例
-
-在 VA1 中创建一个集群，名称为 k8s_1，具备1个主 Node 和3个辅助 Minion（在物理机上）
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
-```
-
-<!--
-Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
---->
-在 VA1 中创建一个 ha etcd 集群，名称为 k8s_2，运行在3个虚拟机和6个辅助 Minion（在虚拟机上）
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
-```
-
-<!--
-Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
---->
-在 UC1 中创建一个集群，名称为k8s_3，具备1个主 Node 和10个具有更高 mem/cpu 的辅助 Minion（在虚拟机上）：
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
-```
-
-
-
-<!--
-## Cluster Features and Architecture
-
-We configure the Kubernetes cluster with the following features:
-
-* KubeDNS: DNS resolution and service discovery
-* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
-* Grafana: Kubernetes/Docker metric dashboard
-* KubeUI: Simple web interface to view Kubernetes state
-* Kube Dashboard: New web interface to interact with your cluster
---->
-## 集群功能和架构
-
-我们使用以下功能配置 Kubernetes 集群：
-
-* KubeDNS：DNS 解析和服务发现
-* Heapster / InfluxDB：用于指标收集，是 Grafana 和 auto-scaling 需要的。
-* Grafana：Kubernetes/Docker 指标仪表板
-* KubeUI：用于查看 Kubernetes 状态的简单 Web 界面
-* Kube 仪表板：新的 Web 界面可与您的集群进行交互
-
-<!--
-We use the following to create the Kubernetes cluster:
---->
-使用以下工具创建 Kubernetes 集群：
-
-* Kubernetes 1.1.7
-* Ubuntu 14.04
-* Flannel 0.5.4
-* Docker 1.9.1-0~trusty
-* Etcd 2.2.2
-
-<!--
-## Optional add-ons
-
-* Logging: We offer an integrated centralized logging ELK platform so that all
-  Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
-  and configure Kubernetes to send logs to it, follow [the log
-  aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as
-  the footprint isn't trivial.
---->
-## 可选附件
-* 日志记录：我们提供了一个集成的集中式日志记录 ELK 平台，以便将所有 Kubernetes 和 docker 日志发送到 ELK 堆栈。要安装 ELK 堆栈并配置 Kubernetes 向其发送日志，请遵循 [日志聚合文档](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md)。注意：默认情况下我们不安装此程序，因为占用空间并不小。
-
-<!--
-## Cluster management
-
-The most widely used tool for managing a Kubernetes cluster is the command-line
-utility ```kubectl```. If you do not already have a copy of this binary on your
-administrative machine, you may run the script ```install_kubectl.sh``` which will
-download it and install it in ```/usr/bin/local```.
---->
-## 管理集群
-
-管理 Kubernetes 集群最常用工具是 command-line 实用程序 ```kubectl```。如果您的管理器上还没有此二进制文件的副本，可以运行脚本 ```install_kubectl.sh```，它将下载该脚本并将其安装在 ```/usr/bin/local``` 中。 
-
-<!--
-The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
-authentication certificates for the particular cluster.  The configuration file is
-written to the  ```${CLC_CLUSTER_HOME}/kube``` directory
---->
-该脚本要求定义环境变量 ```CLC_CLUSTER_NAME```。```install_kubectl.sh``` 还将写入一个配置文件，该文件为特定集群嵌入必要的认证证书。配置文件被写入 ```${CLC_CLUSTER_HOME}/kube``` 目录中
-
-
-```shell
-export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
-kubectl version
-kubectl cluster-info
-```
-
-<!--
-### Accessing the cluster programmatically 
-
-It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice. 
-
-To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
---->
-### 以编程方式访问集群
-
-可以使用本地存储的客户端证书来访问 apiserver。例如，您可以使用 [Kubernetes API 客户端库](/docs/reference/using-api/client-libraries/) 选择编程语言对 Kubernetes 集群进行编程。
-
-为了演示如何使用这些本地存储的证书，我们提供以下示例，使用 ```curl``` 通过 https 与主 apiserver 进行通信：
-
-```shell
-curl \
-   --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt  \
-   --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
-   --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt  https://${MASTER_IP}:6443
-```
-
-<!--
-But please note, this *does not* work out of the box with the ```curl``` binary
-distributed with macOS.
---->
-但是请注意，这 *不能* 与 MacOS 一起发行的 ```curl``` 二进制文件分开使用。
-
-<!--
-### Accessing the cluster with a browser
-
-We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you
-create a cluster, the script should output URLs for these interfaces like this:
-
-kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
---->
-### 使用浏览器访问集群
-
-安装 [Kubernetes 仪表板](/docs/tasks/web-ui-dashboard/)。创建集群时，脚本会为这些接口输出 URL，如下所示：
-
-kubernetes-dashboard 在以下位置运行 ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```
-
-<!--
-Note on Authentication to the UIs: 
-
-The cluster is set up to use basic authentication for the user _admin_.
-Hitting the url at ```https://${MASTER_IP}:6443``` will 
-require accepting the self-signed certificate
-from the apiserver, and then presenting the admin 
-password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
---->
-对 UI 进行身份验证的注意事项：
-
-群集设置为对用户 _admin_ 使用基本的身份验证。进入 URL ```https://${MASTER_IP}:6443```  获取从 apiserver 上接收的自签名证书，然后出示管理员密码并写入文件 ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
-
-
-<!--
-### Configuration files
-
-Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
-to access the cluster from machines other than where you created the cluster from.
---->
-### 配置文件
-
-多个配置文件被写入几个子目录，子目录在 ```.clc_kube/${CLC_CLUSTER_NAME}``` 下的主目录 *CLC_CLUSTER_HOME* 中。使用这些文件可以从创建群集的计算机之外的其他计算机访问群集。
-
-<!--
-* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
-* ```hosts/```: hosts files listing access information for the Ansible playbooks
-* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API
-* ```pki/```: public key infrastructure files enabling TLS communication in the cluster
-* ```ssh/```: SSH keys for root access to the hosts
---->
-* ```config/```：Ansible 变量文件，包含描述主机和从机的参数
-* ```hosts/```: 主机文件，列出了 Ansible 手册的访问信息
-* ```kube/```: ```kubectl``` 配置文件，包含管理员访问 Kubernetes API 所需的基本身份验证密码
-* ```pki/```: 公钥基础结构文件，用于在集群中启用 TLS 通信
-* ```ssh/```: 对主机进行根访问的 SSH 密钥
-
-
-<!--
-## ```kubectl``` usage examples
-
-There are a great many features of _kubectl_.  Here are a few examples
-
-List existing nodes, pods, services and more, in all namespaces, or in just one:
---->
-## ```kubectl``` 使用示例
-
-_kubectl_ 有很多功能，例如
-
-列出所有或者一个命名空间中存在的 Node，Pod，服务等。
-
-```shell
-kubectl get nodes
-kubectl get --all-namespaces pods
-kubectl get --all-namespaces services
-kubectl get --namespace=kube-system replicationcontrollers
-```
-
-<!--
-The Kubernetes API server exposes services on web URLs, which are protected by requiring
-client certificates.  If you run a kubectl proxy locally, ```kubectl``` will provide
-the necessary certificates and serve locally over http.
---->
-Kubernetes API 服务器在 Web URL 上公开服务，这些 URL 受客户端证书的保护。如果您在本地运行 kubectl 代理，```kubectl``` 将提供必要的证书，并通过 http 在本地提供服务。
-
-```shell
-kubectl proxy -p 8001
-```
-
-<!--
-Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser.
---->
-然后，您可以访问 ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` 之类的 URL，不再需要浏览器中的客户端证书 。
-
-
-<!--
-## What Kubernetes features do not work on CenturyLink Cloud
-
-These are the known items that don't work on CenturyLink cloud but do work on other cloud providers:
-
-- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016.
-
-- At this time, there is no support for persistent storage volumes provided by
-  CenturyLink Cloud. However, customers can bring their own persistent storage
-  offering. We ourselves use Gluster.
---->
-## Kubernetes 的哪些功能无法在 CenturyLink Cloud 上使用
-
-这些是已知的在 CenturyLink Cloud 上不能使用，但在其他云提供商中可以使用：
-
-- 目前，没有 [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)类型的支持服务。我们正在为此积极努力，并希望在2016年4月左右发布更改。
-
-- 目前，不支持 CenturyLink Cloud 提供的永久存储卷。但是，客户可以自带永久性存储产品。我们自己使用 Gluster。
-
-
-<!--
-## Ansible Files
-
-If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
---->
-## Ansible 文件
-
-如果您想了解有关 Ansible 文件的更多信息，请 [浏览此文件](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
-
-<!--
-## Further reading
-
-Please see the [Kubernetes docs](/docs/) for more details on administering
-and using a Kubernetes cluster.
---->
-## 更多
-
-有关管理和使用 Kubernetes 集群的更多详细信息，请参见 [Kubernetes 文档](/docs/) 
-
-
-
diff --git a/content/zh/docs/setup/production-environment/turnkey/icp.md b/content/zh/docs/setup/production-environment/turnkey/icp.md
deleted file mode 100644
index 25ed57cd6c..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/icp.md
+++ /dev/null
@@ -1,162 +0,0 @@
----
-reviewers:
-- bradtopol
-title: 使用 IBM Cloud Private 在多个云上运行 Kubernetes
----
-
-<!--
----
-reviewers:
-- bradtopol
-title: Running Kubernetes on Multiple Clouds with IBM Cloud Private
----
--->
-
-<!--
-IBM® Cloud Private is a turnkey cloud solution and an on-premises turnkey cloud solution. IBM Cloud Private delivers pure upstream Kubernetes with the typical management components that are required to run real enterprise workloads. These workloads include health management, log management, audit trails, and metering for tracking usage of workloads on the platform.
--->
-IBM® Cloud Private 是一个 一站式云解决方案并且是一个本地的一站式云解决方案。 IBM Cloud Private 提供纯上游 Kubernetes，以及运行实际企业工作负载所需的典型管理组件。这些工作负载包括健康管理、日志管理、审计跟踪以及用于跟踪平台上工作负载使用情况的计量。
-
-<!--
-IBM Cloud Private is available in a community edition and a fully supported enterprise edition. The community edition is available at no charge from [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/). The enterprise edition supports high availability topologies and includes commercial support from IBM for Kubernetes and the IBM Cloud Private management platform. If you want to try IBM Cloud Private, you can use either the hosted trial, the tutorial, or the self-guided demo. You can also try the free community edition. For details, see [Get started with IBM Cloud Private](https://www.ibm.com/cloud/private/get-started).
--->
-IBM Cloud Private 提供了社区版和全支持的企业版。可从 [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/) 免费获得社区版本。企业版支持高可用性拓扑，并包括 IBM 对 Kubernetes 和 IBM Cloud Private 管理平台的商业支持。如果您想尝试 IBM Cloud Private，您可以使用托管试用版、教程或自我指导演示。您也可以尝试免费的社区版。有关详细信息，请参阅 [IBM Cloud Private 入门](https://www.ibm.com/cloud/private/get-started)。
-
-<!--
-For more information, explore the following resources:
-
-* [IBM Cloud Private](https://www.ibm.com/cloud/private)
-* [Reference architecture for IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
-* [IBM Cloud Private documentation](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
--->
-有关更多信息，请浏览以下资源：
-
-* [IBM Cloud Private](https://www.ibm.com/cloud/private)
-* [IBM Cloud Private 参考架构](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
-* [IBM Cloud Private 文档](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
-
-<!--
-## IBM Cloud Private and Terraform
-
-The following modules are available where you can deploy IBM Cloud Private by using Terraform:
-
-* AWS: [Deploy IBM Cloud Private to AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
-* Azure: [Deploy IBM Cloud Private to Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
-* IBM Cloud: [Deploy IBM Cloud Private cluster to IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
-* OpenStack: [Deploy IBM Cloud Private to OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
-* Terraform module: [Deploy IBM Cloud Private on any supported infrastructure vendor](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
-* VMware: [Deploy IBM Cloud Private to VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
--->
-## IBM Cloud Private 和 Terraform
-
-您可以利用一下模块使用 Terraform 部署 IBM Cloud Private：
-
-* AWS：[将 IBM Cloud Private 部署到 AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
-* Azure：[将 IBM Cloud Private 部署到 Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
-* IBM Cloud：[将 IBM Cloud Private 集群部署到 IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
-* OpenStack：[将IBM Cloud Private 部署到 OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
-* Terraform 模块：[在任何支持的基础架构供应商上部署 IBM Cloud Private](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
-* VMware：[将 IBM Cloud Private 部署到 VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
-
-
-<!--
-## IBM Cloud Private on AWS
--->
-## AWS 上的 IBM Cloud Private
-
-<!--
-You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.
--->
-您可以使用 AWS CloudFormation 或 Terraform 在 Amazon Web Services（AWS）上部署 IBM Cloud Private 集群。
-
-<!--
-IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide.
--->
-IBM Cloud Private 快速入门可以自动将 IBM Cloud Private 部署到 AWS Cloud 上的新虚拟私有云（VPC）中。常规部署大约需要60分钟，而高可用性（HA）部署大约需要75分钟。快速入门包括 AWS CloudFormation 模板和部署指南。
-
-<!--
-This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/).
--->
-这个快速入门适用于希望探索应用程序现代化并希望通过使用 IBM Cloud Private 和 IBM 工具加速实现其数字化转换目标的用户。快速入门可帮助用户在 AWS 上快速部署高可用性（HA）、生产级的 IBM Cloud Private 参考架构。有关所有详细信息和部署指南，请参阅 [IBM Cloud Private 在 AWS 上的快速入门 ](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/)。
-
-<!--
-IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md).
--->
-IBM Cloud Private 也可以通过使用 Terraform 在 AWS 云平台上运行。要在 AWS EC2 环境中部署 IBM Cloud Private，请参阅[在 AWS 上安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md)。
-
-<!--
-## IBM Cloud Private on Azure
-
-You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html).
--->
-## Azure 上的 IBM Cloud Private
-
-您可以启用 Microsoft Azure 作为 IBM Cloud Private 部署的云提供者，并利用 Azure 公共云上的所有 IBM Cloud Private 功能。有关更多信息，请参阅 [Azure 上的 IBM Cloud Private](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html)。
-
-<!--
-## IBM Cloud Private with Red Hat OpenShift
--->
-## 带有 Red Hat OpenShift 的 IBM Cloud Private
-
-<!--
-You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.
--->
-您可以将在 IBM Cloud Private 上运行的 IBM 认证的软件容器部署到 Red Hat OpenShift 上。
-
-<!--
-Integration capabilities:
-
-* Supports Linux® 64-bit platform in offline-only installation mode
-* Single-master configuration
-* Integrated IBM Cloud Private cluster management console and catalog
-* Integrated core platform services, such as monitoring, metering, and logging
-* IBM Cloud Private uses the OpenShift image registry
--->
-整合能力：
-
-* 在仅脱机安装模式下支持 Linux®64 位平台
-* 单主控节点配置
-* 集成的 IBM Cloud Private 集群管理控制台和目录
-* 集成的核心平台服务，例如监控、计量和日志
-* IBM Cloud Private 使用 OpenShift 镜像仓库
-
-<!--
-For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html).
--->
-有关更多信息，请参阅 [OpenShift 上的 IBM Cloud Private](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html)。
-
-<!--
-## IBM Cloud Private on VirtualBox
-
-To install IBM Cloud Private to a VirtualBox environment, see [Installing IBM Cloud Private on VirtualBox](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox).
--->
-## VirtualBox 上的 IBM Cloud Private
-
-要将 IBM Cloud Private 安装到 VirtualBox 环境，请参阅[在 VirtualBox 上安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox)。
-
-<!--
-## IBM Cloud Private on VMware
--->
-## VMware 上的 IBM Cloud Private
-
-<!--
-You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. For details, see the following projects:
--->
-您可以使用 Ubuntu 或 RHEL 镜像在 VMware 上安装 IBM Cloud Private。有关详细信息，请参见以下项目：
-
-<!--
-* [Installing IBM Cloud Private with Ubuntu](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
-* [Installing IBM Cloud Private with Red Hat Enterprise](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
--->
-* [使用 Ubuntu 安装IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
-* [使用 Red Hat Enterprise 安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
-
-<!--
-The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.
--->
-IBM Cloud Private Hosted 服务会自动在您的 VMware vCenter Server 实例上部署 IBM Cloud Private Hosted。此服务将微服务和容器的功能带到 IBM Cloud上的VMware 环境中。使用此服务，您可以将同样熟悉的 VMware 和 IBM Cloud Private 操作模型和工具从本地扩展到 IBM Cloud。
-
-<!--
-For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview).
--->
-有关更多信息，请参阅 [IBM Cloud Private Hosted 服务](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview)。
diff --git a/content/zh/docs/setup/production-environment/turnkey/tencent.md b/content/zh/docs/setup/production-environment/turnkey/tencent.md
deleted file mode 100644
index 5a684987e7..0000000000
--- a/content/zh/docs/setup/production-environment/turnkey/tencent.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: 在腾讯云容器服务上运行 Kubernetes
----
-
-<!--
----
-title: Running Kubernetes on Tencent Kubernetes Engine
----
--->
-
-<!--
-## Tencent Kubernetes Engine
-
- [Tencent Cloud Tencent Kubernetes Engine (TKE)](https://intl.cloud.tencent.com/product/tke) provides native Kubernetes container management services. You can deploy and manage a Kubernetes cluster with TKE in just a few steps. For detailed directions, see [Deploy Tencent Kubernetes Engine](https://intl.cloud.tencent.com/document/product/457/11741).
-
- TKE is a [Certified Kubernetes product](https://www.cncf.io/certification/software-conformance/).It is fully compatible with the native Kubernetes API.
--->
-## 腾讯云容器服务
-
-[腾讯云容器服务（TKE）](https://intl.cloud.tencent.com/product/tke)提供本地 Kubernetes 容器管理服务。您只需几个步骤即可使用 TKE 部署和管理 Kubernetes 集群。有关详细说明，请参阅[部署腾讯云容器服务](https://intl.cloud.tencent.com/document/product/457/11741)。
-
- TKE 是[认证的 Kubernetes 产品](https://www.cncf.io/certification/software-conformance/)。它与原生 Kubernetes API 完全兼容。
-
-<!--
-## Custom Deployment
-
- The core of Tencent Kubernetes Engine is open source and available [on GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/).
-
- When using TKE to create a Kubernetes cluster, you can choose managed mode or independent deployment mode. In addition, you can customize the deployment as needed; for example, you can choose an existing Cloud Virtual Machine instance for cluster creation or enable Kube-proxy in IPVS mode.
--->
-## 定制部署
-
-腾讯 Kubernetes Engine 的核心是开源的，并且可以在 [GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/) 上使用。
-
-使用 TKE 创建 Kubernetes 集群时，可以选择托管模式或独立部署模式。另外，您可以根据需要自定义部署。例如，您可以选择现有的 Cloud Virtual Machine 实例来创建集群，也可以在 IPVS 模式下启用 Kube-proxy。
-
-<!--
-## What's Next
-
- To learn more, see the [TKE documentation](https://intl.cloud.tencent.com/document/product/457).
--->
-## 下一步
-
- 要了解更多信息，请参阅 [TKE 文档](https://intl.cloud.tencent.com/document/product/457)。
\ No newline at end of file
diff --git a/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-install.gif b/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-install.gif
deleted file mode 100644
index e3d94b9b54..0000000000
Binary files a/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-install.gif and /dev/null differ
diff --git a/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-join.gif b/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-join.gif
deleted file mode 100644
index 828417d685..0000000000
Binary files a/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-join.gif and /dev/null differ
diff --git a/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif b/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif
deleted file mode 100644
index e71d40d6df..0000000000
Binary files a/content/zh/docs/setup/production-environment/windows/kubecluster.ps1-reset.gif and /dev/null differ
diff --git a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md
index 314b0de627..80a470cfad 100644
--- a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md
@@ -1,20 +1,15 @@
 ---
-reviewers:
-- michmike
-- patricklang
 title: Kubernetes 中调度 Windows 容器的指南
 content_type: concept
 weight: 75
 ---
 <!--
----
 reviewers:
 - michmike
 - patricklang
 title: Guide for scheduling Windows containers in Kubernetes
 content_type: concept
 weight: 75
----
 -->
 
 <!-- overview -->
@@ -22,9 +17,8 @@ weight: 75
 <!--
 Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
 -->
-Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。
-
-
+Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。
+本指南将引导您完成在 Kubernetes 中配置和部署 Windows 容器的步骤。
 
 <!-- body -->
 
@@ -47,8 +41,10 @@ Windows 应用程序构成了许多组织中运行的服务和应用程序的很
 -->
 ## 在你开始之前
 
-* 创建一个 Kubernetes 集群，其中包括一个[运行 Windows Server 的主节点和工作节点](../user-guide-windows-nodes)
-* 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes  上创建和部署服务和工作负载的行为几乎相同。与集群接口的  [Kubectl  命令](/docs/reference/kubectl/overview/)相同。提供以下部分中的示例只是为了快速启动  Windows 容器的使用体验。
+* 创建一个 Kubernetes 集群，其中包括一个
+  [运行 Windows 服务器的主节点和工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
+* 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes  上创建和部署服务和工作负载的行为几乎相同。
+  与集群接口的  [Kubectl 命令](/zh/docs/reference/kubectl/overview/)相同。提供以下部分中的示例只是为了快速启动  Windows 容器的使用体验。
 
 <!--
 ## Getting Started: Deploying a Windows container
@@ -57,7 +53,9 @@ To deploy a Windows container on Kubernetes, you must first create an example ap
 -->
 ## 入门：部署 Windows 容器
 
-要在 Kubernetes 上部署 Windows 容器，您必须首先创建一个示例应用程序。下面的示例 YAML  文件创建了一个简单的 Web 服务器应用程序。创建一个名为  `win-webserver.yaml`  的服务规约，其内容如下：
+要在 Kubernetes 上部署 Windows 容器，您必须首先创建一个示例应用程序。
+下面的示例 YAML  文件创建了一个简单的 Web 服务器应用程序。
+创建一个名为  `win-webserver.yaml`  的服务规约，其内容如下：
 
 ```yaml
 apiVersion: v1
@@ -103,10 +101,10 @@ spec:
       kubernetes.io/os: windows
 ```
 
-{{< note >}}
 <!--
 Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service.
 -->
+{{< note >}}
 端口映射也是支持的，但为简单起见，在此示例中容器端口 80 直接暴露给服务。
 {{< /note >}}
 
@@ -139,34 +137,34 @@ Port mapping is also supported, but for simplicity in this example the container
 -->
 1. 检查所有节点是否健康：
 
-    ```bash
-    kubectl get nodes
-    ```
+   ```bash
+   kubectl get nodes
+   ```
 
 1. 部署服务并观察 pod 更新：
 
-    ```bash
-    kubectl apply -f win-webserver.yaml
-    kubectl get pods -o wide -w
-    ```
+   ```bash
+   kubectl apply -f win-webserver.yaml
+   kubectl get pods -o wide -w
+   ```
 
-    正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。
+   正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。
 
 1. 检查部署是否成功。验证：
 
-    * Windows 节点上每个 Pod 有两个容器，使用  `docker ps` 
-    * Linux 主机列出两个 Pod，使用  `kubectl get pods` 
-    * 跨网络的节点到 Pod 通信，从 Linux 主服务器 `curl` 您的 pod IPs 的端口80，以检查 Web 服务器响应
-    * Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 pod 之间（以及跨主机，如果您有多个 Windows 节点）进行 ping 操作
-    * 服务到 Pod 的通信，从 Linux 主服务器和各个 Pod 中 `curl` 虚拟服务 IP（在 `kubectl get services` 下可见）
-    * 服务发现，使用 Kubernetes `curl` 服务名称[默认 DNS 后缀](/docs/concepts/services-networking/dns-pod-service/#services)
-    * 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort
-    * 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP
+   * Windows 节点上每个 Pod 有两个容器，使用  `docker ps` 
+   * Linux 主机列出两个 Pod，使用  `kubectl get pods` 
+   * 跨网络的节点到 Pod 通信，从 Linux 主服务器 `curl` 您的 pod IPs 的端口80，以检查 Web 服务器响应
+   * Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 pod 之间（以及跨主机，如果您有多个 Windows 节点）进行 ping 操作
+   * 服务到 Pod 的通信，从 Linux 主服务器和各个 Pod 中 `curl` 虚拟服务 IP（在 `kubectl get services` 下可见）
+   * 服务发现，使用 Kubernetes `curl` 服务名称[默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services)
+   * 入站连接，从 Linux 主服务器或集群外部的计算机 `curl` NodePort
+   * 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP
 
-{{< note >}}
 <!--
 Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
 -->
+{{< note >}}
 由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。
 {{< /note >}}
 
@@ -177,7 +175,9 @@ Starting with Kubernetes v1.16, Windows containers can be configured to run thei
 -->
 ## 使用可配置的容器用户名
 
-从 Kubernetes v1.16 开始，可以为 Windows  容器配置与其镜像默认值不同的用户名来运行其入口点和进程。此能力的实现方式和 Linux 容器有些不同。在[此处](/docs/tasks/configure-pod-container/configure-runasusername/)可了解更多信息。
+从 Kubernetes v1.16 开始，可以为 Windows  容器配置与其镜像默认值不同的用户名来运行其入口点和进程。
+此能力的实现方式和 Linux 容器有些不同。
+在[此处](/zh/docs/tasks/configure-pod-container/configure-runasusername/)可了解更多信息。
 
 <!--
 ## Managing Workload Identity with Group Managed Service Accounts
@@ -186,7 +186,11 @@ Starting with Kubernetes v1.14, Windows container workloads can be configured to
 -->
 ## 使用组托管服务帐户管理工作负载身份
 
-从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理，简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。在[此处](/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
+从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。
+组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理，
+简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。
+配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。
+在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
 
 <!--
 ## Taints and Tolerations
@@ -196,7 +200,9 @@ Starting with Kubernetes v1.14, Windows container workloads can be configured to
 <!--
 Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
 -->
-目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，因而需要结合使用污点和节点选择算符。这可能仅给 Windows 用户造成不便。推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
+目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，
+因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。
+推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
 
 <!--
 ### Ensuring OS-specific workloads land on the appropriate container host
@@ -214,12 +220,18 @@ Users can ensure Windows containers can be scheduled on the appropriate host usi
 <!--
 If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
 -->
-如果 Pod 规范未指定诸如 `"kubernetes.io/os": windows` 之类的 nodeSelector，则该 Pod 可能会被调度到任何主机（Windows 或 Linux）上。这是有问题的，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。最佳实践是使用 nodeSelector。
+如果 Pod 规范未指定诸如 `"kubernetes.io/os": windows` 之类的 nodeSelector，则该 Pod 
+可能会被调度到任何主机（Windows 或 Linux）上。
+这是有问题的，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。
+最佳实践是使用 nodeSelector。
 
 <!--
 However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
 -->
-但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统，例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。
+但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统，
+例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。
+在这些情况下，您可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。
+由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。
 
 <!--
 For example:  `--register-with-taints='os=windows:NoSchedule'`
@@ -229,17 +241,19 @@ For example:  `--register-with-taints='os=windows:NoSchedule'`
 <!--
 By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
 -->
-向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows，也需要合适的匹配的容忍度设置。
+向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。
+为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 既需要 nodeSelector 选择 Windows，
+也需要合适的匹配的容忍度设置。
 
 ```yaml
 nodeSelector:
-    kubernetes.io/os: windows
-    node.kubernetes.io/windows-build: '10.0.17763'
+  kubernetes.io/os: windows
+  node.kubernetes.io/windows-build: '10.0.17763'
 tolerations:
-    - key: "os"
-      operator: "Equal"
-      value: "windows"
-      effect: "NoSchedule"
+  - key: "os"
+    operator: "Equal"
+    value: "windows"
+    effect: "NoSchedule"
 ```
 
 <!--
@@ -257,14 +271,15 @@ Server versions in the same cluster, then you should set additional node labels
 <!--
 Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
 -->
-Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。
+Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 
+如果您运行的是旧版本，则建议手动将此标签添加到 Windows 节点。
 
 <!--
 This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
 -->
 此标签反映了需要兼容的 Windows 主要、次要和内部版本号。以下是当前每个 Windows Server 版本使用的值。
 
-| 产品名称                              |   内部编号             |
+| 产品名称                             |   内部编号             |
 |--------------------------------------|------------------------|
 | Windows Server 2019                  | 10.0.17763             |
 | Windows Server version 1809          | 10.0.17763             |
@@ -279,38 +294,38 @@ This label reflects the Windows major, minor, and build number that need to matc
 <!--
 [RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
 -->
-[RuntimeClass] 可用于简化使用污点和容忍度的过程。集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。
-
+[RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 可用于简化使用污点和容忍度的过程。
+集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。
 
 <!--
 1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
 -->
 1. 将此文件保存到 `runtimeClasses.yml` 文件。它包括适用于 Windows 操作系统、体系结构和版本的 `nodeSelector`。
 
-```yaml
-apiVersion: node.k8s.io/v1beta1
-kind: RuntimeClass
-metadata:
-  name: windows-2019
-handler: 'docker'
-scheduling:
-  nodeSelector:
-    kubernetes.io/os: 'windows'
-    kubernetes.io/arch: 'amd64'
-    node.kubernetes.io/windows-build: '10.0.17763'
-  tolerations:
-  - effect: NoSchedule
-    key: os
-    operator: Equal
-    value: "windows"
-```
+   ```yaml
+   apiVersion: node.k8s.io/v1beta1
+   kind: RuntimeClass
+   metadata:
+     name: windows-2019
+   handler: 'docker'
+   scheduling:
+     nodeSelector:
+       kubernetes.io/os: 'windows'
+       kubernetes.io/arch: 'amd64'
+       node.kubernetes.io/windows-build: '10.0.17763'
+     tolerations:
+     - effect: NoSchedule
+       key: os
+       operator: Equal
+       value: "windows"
+   ```
 
 <!--
 1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
 1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
 -->
-1. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作
-1. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019`
+2. 集群管理员运行 `kubectl create -f runtimeClasses.yml` 操作
+3. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019`
 
 <!--
 For example:
@@ -361,8 +376,3 @@ spec:
   selector:
     app: iis-2019
 ```
-
-
-
-
-[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
diff --git a/content/zh/docs/setup/release/notes.md b/content/zh/docs/setup/release/notes.md
index 804e0c3670..2a4d377368 100644
--- a/content/zh/docs/setup/release/notes.md
+++ b/content/zh/docs/setup/release/notes.md
@@ -86,7 +86,7 @@ The `IngressClass` resource is used to describe a type of Ingress within a Kuber
 
 ### SIG CLI introduces kubectl debug
 
-SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable.  This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
+SIG CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](/zh/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the `kubectl debug` [command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable.  This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
 
 ### Introducing Windows CSI support alpha for Kubernetes
 
diff --git a/content/zh/docs/setup/release/version-skew-policy.md b/content/zh/docs/setup/release/version-skew-policy.md
index 0bc7b4e4e0..5ef5a44884 100644
--- a/content/zh/docs/setup/release/version-skew-policy.md
+++ b/content/zh/docs/setup/release/version-skew-policy.md
@@ -1,12 +1,5 @@
 ---
-reviewers:
-- sig-api-machinery
-- sig-architecture
-- sig-cli
-- sig-cluster-lifecycle
-- sig-node
-- sig-release
-title: Kubernetes 版本及版本倾斜支持策略
+title: Kubernetes 版本及版本偏差支持策略
 content_type: concept
 weight: 30
 ---
@@ -16,7 +9,7 @@ weight: 30
 This document describes the maximum version skew supported between various Kubernetes components.
 Specific cluster deployment tools may place additional restrictions on version skew.
 -->
-本文描述 Kubernetes 各组件之间版本倾斜支持策略。
+本文描述 Kubernetes 各组件之间版本偏差支持策略。
 特定的集群部署工具可能会有额外的限制。
 
 
@@ -33,41 +26,40 @@ where **x** is the major version, **y** is the minor version, and **z** is the p
 For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
 -->
 Kubernetes 版本号格式为 **x.y.z**，其中 **x** 为大版本号，**y** 为小版本号，**z** 为补丁版本号。
-版本号格式遵循 [Semantic Versioning](http://semver.org/) 规则。
-更多信息，请参阅 [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
+版本号格式遵循 [Semantic Versioning](https://semver.org/) 规则。
+更多信息，请参阅 [Kubernetes 发布版本](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
 
 <!--
-The Kubernetes project maintains release branches for the most recent three minor releases.
+The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).  Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
 -->
-Kubernetes 项目会维护最近的三个小版本分支。
+Kubernetes 项目会维护最近的三个小版本分支（{{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}）。
+Kubernetes 1.19 及更高的版本将获得大约1年的补丁支持。
+Kubernetes 1.18 及更早的版本获得大约9个月的补丁支持。
 
 <!--
 Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
-Patch releases are cut from those branches at a regular cadence, or as needed.
-This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing).
-The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team).
--->
-一些 bug 修复，包括安全修复，根据其安全性和可用性，有可能会回合到这些分支。
-补丁版本会定期或根据需要从这些分支中发布。
-最终是否发布是由[patch release team](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing)
-来决定的。Patch release team同时也是[release managers](https://github.com/kubernetes/sig-release/blob/master/release-managers.md). 如需了解更多信息，请查看 [Kubernetes Patch releases](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md).
+Patch releases are cut from those branches at a [regular cadence](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence), plus additional urgent releases, when required.
 
-<!--
-Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
+The [Release Managers](https://git.k8s.io/sig-release/release-managers.md) group owns this decision.
+
+For more information, see the Kubernetes [patch releases](https://git.k8s.io/sig-release/releases/patch-releases.md) page.
 -->
-小版本大约每3个月发布一个，所以每个小版本分支会维护9个月。
+一些 bug 修复，包括安全修复，取决于其严重性和可行性，有可能会反向合并到这三个发布分支。
+补丁版本会[定期](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)或根据需要从这些分支中发布。 
+最终是否发布是由[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)来决定的。
+如需了解更多信息，请查看 Kubernetes [补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
 
 <!--
 ## Supported version skew
 -->
-## 版本倾斜策略
+## 版本偏差策略
 
 ### kube-apiserver
 
 <!--
 In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
 -->
-在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
+在 [高可用（HA）集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
 多个 `kube-apiserver` 实例小版本号最多差1。
 
 <!--
@@ -76,11 +68,11 @@ Example:
 例如：
 
 <!--
-* newest `kube-apiserver` is at **1.13**
-* other `kube-apiserver` instances are supported at **1.13** and **1.12**
+* newest `kube-apiserver` is at **{{< skew latestVersion >}}**
+* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
 -->
-* 最新的 `kube-apiserver` 版本号如果是 **1.13**
-* 其他 `kube-apiserver` 版本号只能是 **1.13** 或 **1.12**
+* 最新的 `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
+* 则受支持的 `kube-apiserver` 版本号包括 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
 
 ### kubelet
 
@@ -92,30 +84,32 @@ Example:
 <!--
 Example:
 
-* `kube-apiserver` is at **1.13**
-* `kubelet` is supported at **1.13**, **1.12**, and **1.11**
+* `kube-apiserver` is at **{{< skew latestVersion >}}**
+* `kubelet` is supported at **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}**
 -->
 例如：
 
-* `kube-apiserver` 版本号如果是 **1.13**
-* `kubelet` 只能是 **1.13** 、 **1.12** 和 **1.11**
+* `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
+* 受支持的的 `kubelet` 版本将包括 **{{< skew latestVersion >}}**、**{{< skew prevMinorVersion >}}** 和 **{{< skew oldestMinorVersion >}}**
 
-{{< note >}}
 <!--
-If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.-->如果
-HA集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。
+If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
+-->
+{{< note >}}
+如果 HA 集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。
 {{</ note >}}
 
 <!--
 Example:
 
-* `kube-apiserver` instances are at **1.13** and **1.12**
-* `kubelet` is supported at **1.12**, and **1.11** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
+* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
+* `kubelet` is supported at **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
 -->
 例如：
 
-* 如果 `kube-apiserver` 的多个实例同时存在 **1.13** 和 **1.12**
-* `kubelet` 只能是 **1.12** 或 **1.11**（**1.13** 不再支持，因为它比**1.12**版本的 `kube-apiserver` 更新）
+* 如果 `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
+* `kubelet` 的受支持版本将是 **{{< skew prevMinorVersion >}}** 和 **{{< skew oldestMinorVersion >}}**
+（**{{< skew latestVersion >}}** 不再支持，因为它比 **{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新）
 
 <!--
 ### kube-controller-manager, kube-scheduler, and cloud-controller-manager
@@ -131,32 +125,35 @@ Example:
 <!--
 Example:
 
-* `kube-apiserver` is at **1.13**
-* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.13** and **1.12**
+* `kube-apiserver` is at **{{< skew latestVersion >}}**
+* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
 -->
 例如：
 
-* 如果 `kube-apiserver` 版本号为 **1.13**
-* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本支持 **1.13** 和 **1.12**
+* 如果 `kube-apiserver` 版本号为 **{{< skew latestVersion >}}**
+* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
 
-{{< note >}}
 <!--
-If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.-->如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
+If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
+-->
+{{< note >}}
+如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
 但 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本可用范围会相应的减小。
 {{< /note >}}
 
 <!--
 Example:
 
-* `kube-apiserver` instances are at **1.13** and **1.12**
+* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
 * `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance
-* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.12** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
+* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew prevMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
 -->
 例如：
 
-* `kube-apiserver` 实例同时存在 **1.13** 和 **1.12** 版本
+* `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
 * `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 可以通过 load balancer 与所有的 `kube-apiserver` 通信
-* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 可选版本为 **1.12**（**1.13** 不再支持，因为它比 **1.12** 版本的 `kube-apiserver` 更新）
+* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 可选版本为 **{{< skew prevMinorVersion >}}**
+（**{{< skew latestVersion >}}** 不再支持，因为它比 **{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新）
 
 ### kubectl
 
@@ -168,30 +165,31 @@ Example:
 <!--
 Example:
 
-* `kube-apiserver` is at **1.13**
-* `kubectl` is supported at **1.14**, **1.13**, and **1.12**
+* `kube-apiserver` is at **{{< skew latestVersion >}}**
+* `kubectl` is supported at **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}**, and **{{< skew prevMinorVersion >}}**
 -->
 例如：
 
-* 如果 `kube-apiserver` 当前是 **1.13** 版本
-* `kubectl` 则支持 **1.14** 、**1.13** 和 **1.12**
+* 如果 `kube-apiserver` 当前是 **{{< skew latestVersion >}}** 版本
+* `kubectl` 则支持 **{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
 
-{{< note >}}
 <!--
-If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.-->
+If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
+-->
+{{< note >}}
 如果 HA 集群中的多个 `kube-apiserver` 实例版本号不一致，相应的 `kubectl` 可用版本范围也会减小。
 {{< /note >}}
 
 <!--
 Example:
 
-* `kube-apiserver` instances are at **1.13** and **1.12**
-* `kubectl` is supported at **1.13** and **1.12** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
+* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
+* `kubectl` is supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
 -->
 例如：
 
-* `kube-apiserver` 多个实例同时存在 **1.13** 和 **1.12**
-* `kubectl` 可选的版本为 **1.13** 和 **1.12**（其他版本不再支持，因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本）
+* `kube-apiserver` 多个实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
+* `kubectl` 可选的版本为 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**（其他版本不再支持，因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本）
 
 <!--
 ## Supported component upgrade order
@@ -200,10 +198,10 @@ Example:
 
 <!--
 The supported version skew between components has implications on the order in which components must be upgraded.
-This section describes the order in which components must be upgraded to transition an existing cluster from version **1.n** to version **1.(n+1)**.
+This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
 -->
-组件之间支持的版本倾斜会影响组件升级的顺序。
-本节描述组件从版本 **1.n** 到 **1.(n+1)** 的升级次序。
+组件之间支持的版本偏差会影响组件升级的顺序。
+本节描述组件从版本 **{{< skew prevMinorVersion >}}** 到 **{{< skew latestVersion >}}** 的升级次序。
 
 ### kube-apiserver
 
@@ -213,32 +211,37 @@ Pre-requisites:
 前提条件：
 
 <!--
-* In a single-instance cluster, the existing `kube-apiserver` instance is **1.n**
-* In an HA cluster, all `kube-apiserver` instances are at **1.n** or **1.(n+1)** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
-* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **1.n** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
-* `kubelet` instances on all nodes are at version **1.n** or **1.(n-1)** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
+* In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew prevMinorVersion >}}**
+* In an HA cluster, all `kube-apiserver` instances are at **{{< skew prevMinorVersion >}}** or **{{< skew latestVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
+* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **{{< skew prevMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
+* `kubelet` instances on all nodes are at version **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
 * Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them:
-  * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **1.(n+1)** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+)
-  * The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **1.(n+1)**
+  * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **{{< skew latestVersion >}}** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+)
+  * The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **{{< skew latestVersion >}}**
 -->
-* 单实例集群时，`kube-apiserver` 实例版本号须是 **1.n**
-* HA 集群时，所有的 `kube-apiserver` 实例版本号必须是 **1.n** 或 **1.(n+1)**（确保满足最新和最旧的实例小版本号相差不大于1）
-* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本号必须为 **1.n**（确保不高于 API server 的版本，且版本号相差不大于1）
-* `kubelet` 实例版本号必须是 **1.n** 或 **1.(n-1)**（确保版本号不高于 API server，且版本号相差不大于2）
+* 单实例集群中，`kube-apiserver` 实例版本号须是 **{{< skew prevMinorVersion >}}**
+* 高可用（HA）集群中，所有的 `kube-apiserver` 实例版本号必须是 **{{< skew prevMinorVersion >}}** 或 **{{< skew latestVersion >}}**（确保满足最新和最旧的实例小版本号相差不大于1）
+* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本号必须为 **{{< skew prevMinorVersion >}}**（确保不高于 API server 的版本，且版本号相差不大于1）
+* `kubelet` 实例版本号必须是 **{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**（确保版本号不高于 API server，且版本号相差不大于2）
 * 注册的 admission 插件必须能够处理新的 `kube-apiserver` 实例发送过来的数据：
-  * `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理 **1.(n+1)** 版本新加的 REST 资源(或使用1.15版本提供的 [`matchPolicy: Equivalent` 选项](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy))
-  * 插件可以处理任何 **1.(n+1)** 版本新的 REST 资源数据和新加的字段
+  * `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理
+    **{{< skew latestVersion >}}** 版本新加的 REST 资源（或使用 1.15 版本提供的
+    [`matchPolicy: Equivalent` 选项](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)）
+  * 插件可以处理任何 **{{< skew latestVersion >}}** 版本新的 REST 资源数据和新加的字段
 
 <!--
-Upgrade `kube-apiserver` to **1.(n+1)**
+Upgrade `kube-apiserver` to **{{< skew latestVersion >}}**
 -->
-升级 `kube-apiserver` 到 **1.(n+1)**
+升级 `kube-apiserver` 到 **{{< skew latestVersion >}}**
 
 {{< note >}}
 <!--
 Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
-require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.-->跟据 [API deprecation](/docs/reference/using-api/deprecation-policy/) 和 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) 规则，
+require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
+-->
+根据 [API 弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 和
+[API 变更指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)，
 `kube-apiserver` 不能跨小版本号升级，即使是单实例集群也不可以。
 
 {{< /note >}}
@@ -246,46 +249,73 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing
 <!--
 ### kube-controller-manager, kube-scheduler, and cloud-controller-manager
 -->
-### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
+### kube-controller-manager、kube-scheduler 和 cloud-controller-manager
 
 <!--
 Pre-requisites:
 
-* The `kube-apiserver` instances these components communicate with are at **1.(n+1)** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
+* The `kube-apiserver` instances these components communicate with are at **{{< skew latestVersion >}}** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
 -->
 前提条件：
 
-* `kube-apiserver` 实例必须为 **1.(n+1)** （HA 集群中，所有的`kube-apiserver` 实例必须在组件升级前完成升级）
+* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** （HA 集群中，所有的`kube-apiserver` 实例必须在组件升级前完成升级）
 
 <!--
-Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **1.(n+1)**
+Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew latestVersion >}}**
 -->
-升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 到 **1.(n+1)**
+升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 到 **{{< skew latestVersion >}}**
 
 ### kubelet
 
 <!--
 Pre-requisites:
 
-* The `kube-apiserver` instances the `kubelet` communicates with are at **1.(n+1)**
+* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew latestVersion >}}**
 
-Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **1.n** or **1.(n-1)**)
+Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
 -->
 前提条件：
 
-* `kube-apiserver` 实例必须为 **1.(n+1)** 版本
+* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** 版本
 
-`kubelet` 可以升级到 **1.(n+1)**（或者停留在 **1.n** 或 **1.(n-1)**）
+`kubelet` 可以升级到 **{{< skew latestVersion >}}**（或者停留在 **{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**）
 
-{{< warning >}}
 <!--
 Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
--->集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
 
-<!--
 * they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
 * it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
 -->
-* 他们必须升级到与 `kube-apiserver` 相差不超过1个小版本，才可以升级其他控制面组件
-* 有可能使用低于3个在维护的小版本
+{{< warning >}}
+集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
+
+* 它们必须升级到与 `kube-apiserver` 相差不超过 1 个小版本，才可以升级其他控制面组件
+* 有可能使用低于 3 个在维护的小版本
 {{</ warning >}}
+
+<!-- ### kube-proxy -->
+### kube-proxy
+
+<!--  
+* `kube-proxy` must be the same minor version as `kubelet` on the node.
+* `kube-proxy` must not be newer than `kube-apiserver`.
+* `kube-proxy` must be at most two minor versions older than `kube-apiserver.`
+-->
+* `kube-proxy` 必须与节点上的 `kubelet` 的小版本相同
+* `kube-proxy` 一定不能比 `kube-apiserver` 小版本更新
+* `kube-proxy` 最多只能比 `kube-apiserver` 早两个小版本
+
+<!--  
+Example:
+
+If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
+
+* `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**.
+* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
+-->
+例如：
+
+如果 `kube-proxy` 的版本是 **{{< skew oldestMinorVersion >}}**：
+
+* `kubelet` 版本必须相同，也是 **{{< skew oldestMinorVersion >}}**
+* `kube-apiserver` 版本必须在 **{{< skew oldestMinorVersion >}}** 到 **{{< skew latestVersion >}}** 之间（闭区间）
\ No newline at end of file
diff --git a/content/zh/docs/sitemap.md b/content/zh/docs/sitemap.md
deleted file mode 100644
index 433569cab8..0000000000
--- a/content/zh/docs/sitemap.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
----
-<script language="JavaScript">
-var dropDownsPopulated = false;
-$( document ).ready(function() {
-  // When the document loads, get the metadata JSON, and kick off tbl render
-  $.get("/metadata.txt", function(data, status) {
-    metadata = $.parseJSON(data);
-    metadata.pages.sort(dynamicSort("t"));
-    mainLogic()
-    $(window).bind( 'hashchange', function(e) {
-      mainLogic();
-    });
-  });
-});
-function mainLogic()
-{
-  // If there's a tag filter, change the table/drop down output
-  if (!dropDownsPopulated) populateDropdowns();
-  var tag=window.location.hash.replace("#","");
-  if(tag) {
-    tag = $.trim(tag);
-    for (i=0;i<tagName.length;i++) {
-      querystringTag = tagName[i] + "=";
-      if (tag.indexOf(querystringTag) > -1)
-      {
-        console.log("in mainLog: querystringTag of " + querystringTag + " matches tag of " + tag);
-        tag = tag.replace(querystringTag,"");
-        selectDropDown(tagName[i],tag);
-        topicsFilter(tagName[i],tag,"output");
-      }
-    }
-  } else {
-    currentTopics = metadata.pages;
-  }
-  renderTable(currentTopics,"output");
-
-}
-function populateDropdowns()
-{
-  // Keeping mainLogic() brief by functionalizing the initialization of the
-  // drop-down filter boxes
-
-  for(i=0;i<metadata.pages.length;i++)
-  {
-    var metadataArrays = [metadata.pages[i].cr,metadata.pages[i].or,metadata.pages[i].mr];
-    for(j=0;j<metadataArrays.length;j++)
-    {
-      if (metadataArrays[j]) {
-        for (k=0;k<metadataArrays[j].length;k++) {
-          if (typeof storedTagsArrays[j] == 'undefined') storedTagsArrays[j] = new Array();
-          storedTagsArrays[j][metadataArrays[j][k][tagName[j]]] = true;
-          // ^ conceptList[metadata.pages[i].cr[k].concept] = true; (if rolling through concepts)
-          // ^ conceptList['container'] = true; (ultimate result)
-          // ^ objectList[metadata.pages[i].or[k].object] = true; (if rolling through objects)
-          // ^ objectList['restartPolicy'] = true; (ultimate result)
-        }
-      }
-    }
-  }
-  var output = new Array();
-  for(i=0;i<tagName.length;i++)
-  {
-    // Phew! All tags in conceptList, objectList, and commandList!
-    // Loop through them and populate those drop-downs through html() injection
-    output = [];
-    output.push("<select id='" + tagName[i] + "' onchange='dropFilter(this)'>");
-    output.push("<option>---</option>");
-    Object.keys(storedTagsArrays[i]).sort().forEach(function (key) {
-      output.push("<option>" + key + "</option>");
-    });
-    output.push("</select>")
-    $(dropDowns[i]).html(output.join(""));
-  }
-  dropDownsPopulated = true;
-}
-function dropFilter(srcobj)
-{
-  // process the change of a drop-down value
-  // the ID of the drop down is either command, object, or concept
-  // these exact values are what topicsFilter() expects, plus a filter val
-  // which we get from .text() of :selected
-  console.log("dropFilter:" + $(srcobj).attr('id') + ":" + $(srcobj).find(":selected").text());
-  topicsFilter($(srcobj).attr('id').replace("#",""),$(srcobj).find(":selected").text(),"output");
-  for(i=0;i<tagName.length;i++)
-  {
-    if($(srcobj).attr('id')!=tagName[i]) selectDropDown(tagName[i],"---");
-  }
-}
-function selectDropDown(type,tag)
-{
-  // change drop-down selection w/o filtering
-  $("#" + type).val(tag);
-}
-</script>
-<style>
-#filters select{
-  font-size: 14px;
-  border: 1px #000 solid;
-}
-#filters {
-  padding-top: 20px;
-}
-</style>
-
-<!-- Click tags or use the drop downs to filter. Click table headers to sort or reverse sort. -->
-单击"标记"或使用下拉列表进行筛选。单击"表标题"进行排序或反向排序。
-
-<p id="filters">
-Filter by Concept: <span id="conceptFilter" /><br/>
-Filter by Object: <span id="objectFilter" /><br/>
-Filter by Command: <span id="commandFilter" />
-</p>
-
-<div id="output" />
diff --git a/content/zh/docs/tasks/_index.md b/content/zh/docs/tasks/_index.md
index dff8e43aa2..4924d17d49 100644
--- a/content/zh/docs/tasks/_index.md
+++ b/content/zh/docs/tasks/_index.md
@@ -21,3 +21,10 @@ single thing, typically by giving a short sequence of steps.
 Kubernetes 文档这一部分包含的一些页面展示如何去完成单个任务。
 每个任务页面是一般通过给出若干步骤展示如何执行完成某事。
 
+<!--
+If you would like to write a task page, see
+[Creating a Documentation Pull Request](/docs/contribute/new-content/open-a-pr/).
+-->
+如果你希望编写一个任务页面，参考
+[创建一个文档拉取请求](/zh/docs/contribute/new-content/open-a-pr/)。
+
diff --git a/content/zh/docs/tasks/access-application-cluster/_index.md b/content/zh/docs/tasks/access-application-cluster/_index.md
index 3ed8c7e6c0..5fb03229b1 100644
--- a/content/zh/docs/tasks/access-application-cluster/_index.md
+++ b/content/zh/docs/tasks/access-application-cluster/_index.md
@@ -1,4 +1,5 @@
 ---
 title: 访问集群中的应用程序
 weight: 60
+description: 配置负载平衡、端口转发或设置防火墙或 DNS 配置，以访问集群中的应用程序。
 ---
diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md
index b7b4d18657..7708022f31 100644
--- a/content/zh/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md
@@ -42,7 +42,7 @@ Check the location and credentials that kubectl knows about with this command:
 
 当您第一次访问 Kubernetes API 的时候，我们建议您使用 Kubernetes CLI，`kubectl`。
 
-访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。
+访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/zh/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。
 
 通过以下命令检查 kubectl 是否知道集群地址及凭证：
 
@@ -71,7 +71,7 @@ curl or wget, or a browser, there are several ways to locate and authenticate:
     - Works with some types of client code that are confused by using a proxy.
     - Need to import a root cert into your browser to protect against MITM.
 -->
-有许多 [例子](/docs/user-guide/kubectl-cheatsheet) 介绍了如何使用 kubectl，可以在 [kubectl手册](/docs/user-guide/kubectl-overview) 中找到更完整的文档。
+有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，可以在 [kubectl手册](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。
 
 ## 直接访问 REST API
 Kubectl 处理 apiserver 的定位和身份验证。
@@ -197,7 +197,7 @@ with future high-availability support.
 -->
 上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器（这些安装在 `~/.kube` 目录中）。由于集群证书通常是自签名的，因此可能需要特殊配置才能让您的 http 客户端使用根证书。
 
-在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/docs/admin/accessing-the-api) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
+在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
 
 <!--
 ## Programmatic access to the API
@@ -224,7 +224,7 @@ Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客
 * 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 来查看目前支持哪些版本。
 * 基于这个 client-go 客户端库编写应用程序。 请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
 
-Go 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 来定位和验证 apiserver。可参阅 [示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
+Go 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver。可参阅 [示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
 
 如果应用程序以 Pod 的形式部署在集群中，那么请参阅 [下一章](#accessing-the-api-from-a-pod)。
 
@@ -245,11 +245,11 @@ See documentation for other libraries for how they authenticate.
 
 如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，请运行命令：`pip install kubernetes`。参阅 [Python Client Library page](https://github.com/kubernetes-client/python) 以获得更详细的安装参数。
 
-Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples)。
+Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples)。
 
 ### 其它语言
 
-目前有多个 [客户端库](/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。
+目前有多个 [客户端库](/zh/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。
 参阅其它库的相关文档以获取他们是如何验证的。
 
 <!--
@@ -274,7 +274,7 @@ at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
 
 在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc` 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
 
-向 apiserver 进行身份验证的推荐方法是使用 [服务帐户](/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
+向 apiserver 进行身份验证的推荐方法是使用 [服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
 通过 kube-system，pod 与服务帐户相关联，并且该服务帐户的凭证（token）被放置在该 pod 中每个容器的文件系统中，位于 `/var/run/secrets/kubernetes.io/serviceaccount/token`。
 
 <!--
@@ -322,7 +322,7 @@ such as your desktop machine.
 ## 访问集群中正在运行的服务  {#accessing-services-running-on-the-cluster}
 
 上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。
-在 Kubernetes 中，[节点](/docs/admin/node)，[pods](/docs/user-guide/pods) 和 [服务](/docs/user-guide/services) 都有自己的 IP。
+在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)，[pods](/zh/docs/concepts/workloads/pods/) 和 [服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。
 在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。
 
 <!--
@@ -361,7 +361,7 @@ You have several options for connecting to nodes, pods and services from outside
 
   - 通过公共 IP 访问服务。
     - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
-      请参阅 [服务](/docs/user-guide/services) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
+      请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
     - 取决于您的集群环境，该服务可能仅暴露给您的公司网络，或者也可能暴露给整个互联网。
       请考虑公开该服务是否安全。它是否进行自己的身份验证？
     - 在服务后端放置 pod。要从一组副本中访问一个特定的 pod，例如进行调试，请在 pod 上放置一个唯一的标签，然后创建一个选择此标签的新服务。
@@ -371,7 +371,7 @@ You have several options for connecting to nodes, pods and services from outside
       如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的访问权限，或者是为了 debug，那么请使用此选项。
     - 代理可能会给一些 web 应用带来问题。
     - 只适用于 HTTP/HTTPS。
-    - 更多详细信息在 [这里]。
+    - 更多详细信息在 [这里](#manually-constructing-apiserver-proxy-urls)。
   - 从集群中的 node 或者 pod 中访问。
     - 运行一个 pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) 来连接 pod 里的 shell。
       然后从 shell 中连接其它的节点、pod 和服务。
@@ -432,7 +432,7 @@ The supported formats for the name segment of the URL are:
 * `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
 * `https:<service_name>:<port_name>` - proxies to the specified port using https
 -->
-#### 手动构建 apiserver 代理 URL
+#### 手动构建 apiserver 代理 URL {#manually-constructing-apiserver-proxy-urls}
 
 如上所述，您可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
@@ -540,7 +540,7 @@ There are several different proxies you may encounter when using Kubernetes:
     - can be used to reach a Node, Pod, or Service
     - does load balancing when used to reach a Service
 -->
-1.  [apiserver 代理](#discovering-builtin-services)：
+2.  [apiserver 代理](#discovering-builtin-services)：
 
     - 内置于 apiserver 中
     - 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
@@ -559,7 +559,7 @@ There are several different proxies you may encounter when using Kubernetes:
     - provides load balancing
     - is just used to reach services
 -->
-1.  [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)：
+3.  [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
 
     - 运行在每个节点上
     - 代理 UDP 和 TCP
@@ -574,7 +574,7 @@ There are several different proxies you may encounter when using Kubernetes:
     - sits between all clients and one or more apiservers
     - acts as load balancer if there are several apiservers.
 -->
-1.  位于 apiserver 之前的 Proxy/Load-balancer：
+4.  位于 apiserver 之前的 Proxy/Load-balancer：
 
     - 存在和实现因集群而异（例如 nginx）
     - 位于所有客户和一个或多个 apiserver 之间
@@ -591,7 +591,7 @@ There are several different proxies you may encounter when using Kubernetes:
 Kubernetes users will typically not need to worry about anything other than the first two types.  The cluster admin
 will typically ensure that the latter types are setup correctly.
 -->
-1.  外部服务上的云负载均衡器：
+5.  外部服务上的云负载均衡器：
 
     - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
     - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
@@ -599,5 +599,3 @@ will typically ensure that the latter types are setup correctly.
     - 具体实现因云提供商而异。
 
 除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。集群管理员通常会确保后者的正确配置。
-
-
diff --git a/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index f1553da086..f8399bf098 100644
--- a/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -203,7 +203,7 @@ users:
 
 <!--
 The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders
-for the pathnames of the certificate files. You need change these to the actual pathnames
+for the pathnames of the certificate files. You need to change these to the actual pathnames
 of certificate files in your environment.
 
 Sometimes you may want to use Base64-encoded data embedded here instead of separate
diff --git a/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
deleted file mode 100644
index a6cee8c2d0..0000000000
--- a/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
+++ /dev/null
@@ -1,163 +0,0 @@
----
-reviewers:
-- bprashanth
-- davidopp
-title: 配置你的云平台防火墙
-content_type: task
-weight: 90
----
-
-<!-- overview -->
-
-<!--
-Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent
-exposure to the internet.  When exposing a service to the external world, you may need to open up
-one or more ports in these firewalls to serve traffic.  This document describes this process, as
-well as any provider specific details that may be necessary.
--->
-许多云服务提供商（比如 谷歌计算引擎）定义防火墙以防止服务无意间暴露到互联网上。
-当暴露服务给外网时，你可能需要在防火墙上开启一个或者更多的端口来支持服务。
-本文描述了这个过程，以及其他云服务商的具体信息。
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
-<!-- steps -->
-<!--
-## Restrict Access For LoadBalancer Service
--->
-## 负载均衡（LoadBalancer）服务的访问限制
-
-<!--
- When using a Service with `spec.type: LoadBalancer`, you can specify the IP ranges that are allowed to access the load balancer
- by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.
- This feature is currently supported on Google Compute Engine, Google Kubernetes Engine, AWS Elastic Kubernetes Service, and Azure Kubernetes Service. This field will be ignored if the cloud provider does not support the feature.
--->
-当以 `spec.type: LoadBalancer` 方式配置服务时，你可以使用 `spec.loadBalancerSourceRanges` 来指定允许访问负载均衡器的 ip 段。
-这个字段采用 CIDR 的 IP 段， kubernetes 使用该段配置防火墙。目前只有 谷歌计算引擎，谷歌云原生引擎，亚马逊弹性原生云服务 和 微软云原生平台支持此功能。
-如果云服务提供商不支持这个功能，这个字段将被忽略。
-
-<!--
- Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs.
- This will not allow clients from outside of your Kubernetes cluster to access the load balancer.
--->
-假设内部子网为假设10.0.0.0/8，在下面这个例子中，将创建一个仅能由群集内部IP访问的负载均衡器。此负载均衡器不允许来自 kubernetes 集群外部客户端的访问。
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: myapp
-spec:
-  ports:
-  - port: 8765
-    targetPort: 9376
-  selector:
-    app: example
-  type: LoadBalancer
-  loadBalancerSourceRanges:
-  - 10.0.0.0/8
-```
-<!--
- In the following example, a load balancer will be created that is only accessible to clients with IP addresses from 130.211.204.1 and 130.211.204.2.
--->
-在下面这个例子中，将创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: myapp
-spec:
-  ports:
-  - port: 8765
-    targetPort: 9376
-  selector:
-    app: example
-  type: LoadBalancer
-  loadBalancerSourceRanges:
-  - 130.211.204.1/32
-  - 130.211.204.2/32
-```
-<!--
-## Google Compute Engine
--->
-## 谷歌计算引擎 （Google Compute Engine）
-
-<!--
-When using a Service with `spec.type: LoadBalancer`, the firewall will be
-opened automatically.  When using `spec.type: NodePort`, however, the firewall
-is *not* opened by default.
--->
-当以 `spec.type: LoadBalancer` 方式配置服务时，该服务的防火墙将自动打开。
-当以 `spec.type: NodePort` 方式配置服务时，该服务的防火墙在默认情况下不会打开。
-
-<!--
-Google Compute Engine firewalls are documented [elsewhere](https://cloud.google.com/compute/docs/networking#firewalls_1).
--->
-谷歌计算引擎的防火墙会进行记录 [他处] (https://cloud.google.com/compute/docs/networking#firewalls_1)。
-
-<!--
-You can add a firewall with the `gcloud` command line tool:
--->
-你也可以使用 gcloud 命令行工具自行添加防火墙：
-
-```shell
-gcloud compute firewall-rules create my-rule --allow=tcp:<port>
-```
-
-{{< note >}}
-<!--
-GCE firewalls are defined per-vm, rather than per-ip address. This means that
-when you open a firewall for a service's ports, anything that serves on that
-port on that VM's host IP address may potentially serve traffic. Note that this
-is not a problem for other Kubernetes services, as they listen on IP addresses
-that are different than the host node's external IP address.
--->
-GCE 防火墙是按照虚拟机来定义的，而不是通过ip地址来定义的。
-这就意味着当你在防火墙上打开一个服务端口时，任何在那台虚拟机 IP 上的同一端口的服务
-都有被外部访问的潜在可能。需要注意的是，对于其他的 kubernetes 服务而言，这不是问题。
-因为他们监听的ip 地址与主机节点外部的 ip 地址并不相同。
-
-<!--
-Consider:
--->
-试想一下：
-
-<!--
-   * You create a Service with an external load balancer (IP Address 1.2.3.4)
-     and port 80
--->
-   * 你建立一个（ ip 地址为1.2.3.4）端口为80的外部负载均衡器
-
-<!--
-   * You open the firewall for port 80 for all nodes in your cluster, so that
-     the external Service actually can deliver packets to your Service
--->
-   * 因为在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
-     服务发送数据包。
-
-<!--
-   * You start an nginx server, running on port 80 on the host virtual machine
-     (IP Address 2.3.4.5).  This nginx is also exposed to the internet on
-     the VM's external IP address.
--->
-   * 最后你又虚拟机上的80端口启动 nginx 服务器（ip地址2.3.4.5）。
-     这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了互联网上。
-
-<!--
-Consequently, please be careful when opening firewalls in Google Compute Engine
-or Google Kubernetes Engine.  You may accidentally be exposing other services to
-the wilds of the internet.
--->
-因此请务必小心，在谷歌计算引擎或者谷歌云原生引擎中打开防火墙时，可能无意间把其他服务也暴露给了互联网。
-
-{{< /note >}}
-
-
diff --git a/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index f66cd77124..3fa7626c88 100644
--- a/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -228,10 +228,10 @@ so that you can change the configuration more easily.
 <!--
 ## Interact with the frontend Service
 
-Once you’ve created a Service of type LoadBalancer, you can use this
+Once you've created a Service of type LoadBalancer, you can use this
 command to find the external IP:
 -->
-### 与前端 Service 交互
+### 与前端 Service 交互   {#interact-with-the-frontend-service}
 
 一旦你创建了 LoadBalancer 类型的 Service，你可以使用这条命令查看外部 IP：
 
diff --git a/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md b/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md
index dab03002d3..4694ac5dbc 100644
--- a/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/zh/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -12,7 +12,7 @@ weight: 100
 <!-- overview -->
 
 <!--
-An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access 
+An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
 to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.
 
 This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
@@ -61,11 +61,11 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
 1. 为了启用 NGINIX Ingress 控制器，可以运行下面的命令：
 
 
-    ```shell
-    minikube addons enable ingress
-    ```
+   ```shell
+   minikube addons enable ingress
+   ```
 
-<!--      
+<!--
 1. Verify that the NGINX Ingress controller is running
 -->
 2. 检查验证 NGINX Ingress 控制器处于运行状态：
@@ -75,11 +75,13 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
    ```
 
    <!-- This can take up to a minute. -->
-   {{< note >}}这一操作可供需要近一分钟时间。{{< /note >}}
+   {{< note >}}
+   这一操作可能需要近一分钟时间。
+   {{< /note >}}
 
    输出：
 
-   ```shell
+   ```
    NAME                                        READY     STATUS    RESTARTS   AGE
    default-http-backend-59868b7dd6-xb8tq       1/1       Running   0          1m
    kube-addon-manager-minikube                 1/1       Running   0          3m
@@ -104,39 +106,39 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
 
    <!--Output:-->
    输出：
-    
+
    ```
    deployment.apps/web created
    ```
 
 <!--
-1. Expose the Deployment: 
+1. Expose the Deployment:
 -->
 2. 将 Deployment 暴露出来：
 
    ```shell
    kubectl expose deployment web --type=NodePort --port=8080
    ```
-    
+
    <!-- Output: -->
-   输出： 
-    
+   输出：
+
    ```
    service/web exposed
    ```
 
-<!--    
+<!--
 1. Verify the Service is created and is available on a node port:
 -->
 3. 验证 Service 已经创建，并且可能从节点端口访问：
 
    ```shell
    kubectl get service web
-   ``` 
-    
+   ```
+
    <!-- Output: -->
    输出：
-    
+
    ```shell
    NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
@@ -150,14 +152,14 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
    ```shell
    minikube service web --url
    ```
-    
+
    <!-- Output: -->
    输出：
-    
+
    ```shell
    http://172.17.0.15:31637
    ```
-    
+
    <!--
    Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.
    -->
@@ -166,18 +168,18 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
    然后点击 **Select port to view on Host 1**。
    输入节点和端口号（这里是`31637`），之后点击 **Display Port**。
    {{< /note >}}
-    
+
    <!-- Output: -->
    输出：
-    
+
    ```shell
    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    ```
-  
-   <!--  
-   You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access 
+
+   <!--
+   You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
    the app using the Ingress resource.
    -->
    你现在应该可以通过 Minikube 的 IP 地址和节点端口来访问示例应用了。
@@ -197,58 +199,45 @@ The following file is an Ingress resource that sends traffic to your Service via
 
 1. 根据下面的 YAML 创建文件 `example-ingress.yaml`：
 
-   ```yaml
-   apiVersion: networking.k8s.io/v1beta1
-   kind: Ingress
-   metadata:
-     name: example-ingress
-     annotations:
-       nginx.ingress.kubernetes.io/rewrite-target: /$1
-   spec:
-     rules:
-     - host: hello-world.info
-       http:
-         paths:
-         - path: /
-           backend:
-             serviceName: web
-             servicePort: 8080
-   ```
+   {{< codenew file="service/networking/example-ingress.yaml" >}}
 
 <!--
 1. Create the Ingress resource by running the following command:
 -->
 2. 通过运行下面的命令创建 Ingress 资源：
-    
+
    ```shell
-   kubectl apply -f example-ingress.yaml
+   kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
    ```
-    
+
    <!-- Output: -->
    输出：
-    
-   ```shell
+
+   ```
    ingress.networking.k8s.io/example-ingress created
    ```
+
 <!--
-1. Verify the IP address is set: 
+1. Verify the IP address is set:
 -->
 3. 验证 IP 地址已被设置：
 
-   ```shell 
+   ```shell
    kubectl get ingress
    ```
 
    <!-- This can take a couple of minutes. -->
-   {{< note >}}此操作可能需要几分钟时间。{{< /note >}}
+   {{< note >}}
+   此操作可能需要几分钟时间。
+   {{< /note >}}
 
-   ```shell
-   NAME              HOSTS              ADDRESS       PORTS     AGE
-   example-ingress   hello-world.info   172.17.0.15   80        38s
+   ```
+   NAME              CLASS    HOSTS              ADDRESS        PORTS   AGE
+   example-ingress   <none>   hello-world.info   172.17.0.15    80      38s
    ```
 
 <!--
-1. Add the following line to the bottom of the `/etc/hosts` file. 
+1. Add the following line to the bottom of the `/etc/hosts` file.
 -->
 4. 在 `/etc/hosts` 文件的末尾添加以下内容：
 
@@ -277,8 +266,8 @@ The following file is an Ingress resource that sends traffic to your Service via
 
    <!-- Output: -->
    输出：
-    
-   ```shell
+
+   ```
    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
@@ -305,12 +294,12 @@ The following file is an Ingress resource that sends traffic to your Service via
    ```
    <!-- Output: -->
    输出：
-    
-   ```shell
+
+   ```
    deployment.apps/web2 created
    ```
 
-<!--    
+<!--
 1. Expose the Deployment:
 -->
 2. 将 Deployment 暴露出来：
@@ -321,15 +310,15 @@ The following file is an Ingress resource that sends traffic to your Service via
 
    <!-- Output:  -->
    输出：
-    
-   ```shell
+
+   ```
    service/web2 exposed
    ```
 
-<!--    
+<!--
 ## Edit Ingress
 
-1. Edit the existing `example-ingress.yaml` and add the following lines:  
+1. Edit the existing `example-ingress.yaml` and add the following lines:
 -->
 ## 编辑 Ingress
 
@@ -337,10 +326,13 @@ The following file is an Ingress resource that sends traffic to your Service via
 
 
    ```yaml
-     - path: /v2
-       backend:
-         serviceName: web2
-         servicePort: 8080
+   - path: /v2
+     pathType: Prefix
+     backend:
+       service:
+         name: web2
+         port:
+           number: 8080
    ```
 
 <!--
@@ -353,9 +345,9 @@ The following file is an Ingress resource that sends traffic to your Service via
    ```
 
    <!-- Output: -->
-   输出： 
+   输出：
 
-   ```shell
+   ```
    ingress.networking/example-ingress configured
    ```
 
diff --git a/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index fd4904ca80..06791739d7 100644
--- a/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/content/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -5,27 +5,22 @@ weight: 40
 ---
 
 <!--
----
 title: Use Port Forwarding to Access Applications in a Cluster
 content_type: task
 weight: 40
----
 -->
 
 <!-- overview -->
-
 <!--
 This page shows how to use `kubectl port-forward` to connect to a Redis
 server running in a Kubernetes cluster. This type of connection can be useful
 for database debugging.
 -->
-本文展示如何使用 `kubectl port-forward` 连接到在 Kubernetes 集群中运行的 Redis 服务。这种类型的连接对数据库调试很有用。
-
-
+本文展示如何使用 `kubectl port-forward` 连接到在 Kubernetes 集群中
+运行的 Redis 服务。这种类型的连接对数据库调试很有用。
 
 ## {{% heading "prerequisites" %}}
 
-
 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 <!--
@@ -33,9 +28,6 @@ for database debugging.
 -->
 * 安装 [redis-cli](http://redis.io/topics/rediscli)。
 
-
-
-
 <!-- steps -->
 
 <!--
@@ -47,172 +39,206 @@ for database debugging.
 
 1. 创建一个 Redis deployment：
 
-        kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+   ```
 
-<!--
-    The output of a successful command verifies that the deployment was created:
--->
-    查看输出是否成功，以验证是否成功创建 deployment：
+   <!--
+   The output of a successful command verifies that the deployment was created:
+   -->
+   查看输出是否成功，以验证是否成功创建 deployment：
 
-        deployment.apps/redis-master created
-    
-<!--
-    View the pod status to check that it is ready:
--->
-    查看 pod 状态，检查其是否准备就绪：
+   ```
+   deployment.apps/redis-master created
+   ```
 
-        kubectl get pods
-    
-<!--
-    The output displays the pod created:
--->
-    输出显示创建的 pod：
+   <!--
+   View the pod status to check that it is ready:
+   -->
+   查看 pod 状态，检查其是否准备就绪：
 
-        NAME                            READY     STATUS    RESTARTS   AGE
-        redis-master-765d459796-258hz   1/1       Running   0          50s
+   ```shell
+   kubectl get pods
+   ```
 
-<!--
-    View the deployment status:
--->
-    查看 deployment 状态：
+   <!--
+   The output displays the pod created:
+   -->
+   输出显示创建的 pod：
 
-        kubectl get deployment
+   ```
+   NAME                            READY     STATUS    RESTARTS   AGE
+   redis-master-765d459796-258hz   1/1       Running   0          50s
+   ```
 
-<!--
-    The output displays that the deployment was created:
--->
-    输出显示创建的 deployment：
+   <!--
+   View the deployment status:
+   -->
+   查看 deployment 状态：
 
-        NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-        redis-master 1         1         1            1           55s
+   ```shell
+   kubectl get deployment
+   ```
 
-<!--
-    View the replicaset status using:
--->
-    查看 replicaset 状态：
+   <!--
+   The output displays that the deployment was created:
+   -->
+   输出显示创建的 deployment：
 
-        kubectl get rs
+   ```
+   NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+   redis-master 1         1         1            1           55s
+   ```
 
-<!--
-    The output displays that the replicaset was created:
--->
-    输出显示创建的 replicaset：
+   <!--
+   View the replicaset status using:
+   -->
+   查看 replicaset 状态：
 
-        NAME                      DESIRED   CURRENT   READY     AGE
-        redis-master-765d459796   1         1         1         1m
+   ```shell
+   kubectl get rs
+   ```
+
+   <!--
+   The output displays that the replicaset was created:
+   -->
+   输出显示创建的 replicaset：
+
+   ```
+   NAME                      DESIRED   CURRENT   READY     AGE
+   redis-master-765d459796   1         1         1         1m
+   ```
 
 <!--
 2. Create a Redis service:
 -->
 2. 创建一个 Redis 服务：
 
-       kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+   ```
 
-<!--
-    The output of a successful command verifies that the service was created:
--->
-    查看输出是否成功，以验证是否成功创建 service：
+   <!--
+   The output of a successful command verifies that the service was created:
+   -->
+   查看输出是否成功，以验证是否成功创建 service：
 
-        service/redis-master created
+   ```
+   service/redis-master created
+   ```
 
-<!--
-    Check the service created:
--->
-    检查 service 是否创建：
+   <!--
+   Check the service created:
+   -->
+   检查 service 是否创建：
 
-       kubectl get svc | grep redis
+   ```shell
+   kubectl get svc | grep redis
+   ```
 
- <!--   
-    The output displays the service created:
--->
-    输出显示创建的 service：
-        NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
-        redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s
+   <!--   
+   The output displays the service created:
+   -->
+   输出显示创建的 service：
+
+   ```
+   NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
+   redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s
+   ```
 
 <!--
 3. Verify that the Redis server is running in the pod and listening on port 6379:
 -->
 3. 验证 Redis 服务是否运行在 pod 中并且监听 6379 端口：
 
+   ```shell
+   kubectl get pods redis-master-765d459796-258hz \
+     --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
+   ```
+   <!--
+   The output displays the port:
+   -->
+   输出应该显示端口：
 
-       kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
-
-<!--
-    The output displays the port:
--->
-    输出应该显示端口：
-
-        6379
-
+   ```
+   6379
+   ```
 
 <!--
 ## Forward a local port to a port on the pod
 
-1.  `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to since Kubernetes v1.10.
+1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to since Kubernetes v1.10.
 -->
 ## 转发一个本地端口到 pod 端口
 
-1. 从 Kubernetes v1.10 开始，`kubectl port-forward` 允许使用资源名称（例如 pod 名称）来选择匹配的 pod 来进行端口转发。
+1. 从 Kubernetes v1.10 开始，`kubectl port-forward` 允许使用资源名称
+   （例如 pod 名称）来选择匹配的 pod 来进行端口转发。
 
-        kubectl port-forward redis-master-765d459796-258hz 7000:6379 
+   ```shell
+   kubectl port-forward redis-master-765d459796-258hz 7000:6379 
+   ```
+   <!--
+   which is the same as
+   -->
+   这相当于
+
+   ```shell
+   kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
+   ```
+
+   <!-- or -->
+   或者
+
+   ```shell
+   kubectl port-forward deployment/redis-master 7000:6379 
+   ```
+
+   <!-- or -->
+   或者
+
+   ```shell
+   kubectl port-forward rs/redis-master 7000:6379
+   ```
+
+   <!-- or -->
+   或者
+
+   ```
+   kubectl port-forward svc/redis-master 7000:redis
+   ```
+
+   <!--
+   Any of the above commands works. The output is similar to this:
+   -->
+   以上所有命令都应该有效。输出应该类似于：
+
+   ```
+   I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
+   I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
+   ```
 
 <!--
-    which is the same as
--->
-    这相当于
-
-        kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
-
-<!--
-    or
--->
-    或者
-
-        kubectl port-forward deployment/redis-master 7000:6379 
-
-<!--
-    or
--->
-    或者
-
-        kubectl port-forward rs/redis-master 7000:6379
-
-<!--
-    or
--->
-    或者
-
-        kubectl port-forward svc/redis-master 7000:6379
-
-<!--
-    Any of the above commands works. The output is similar to this:
--->
-    以上所有命令都应该有效。输出应该类似于：
-
-        I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
-        I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
-
-<!--
-2.  Start the Redis command line interface:
+2. Start the Redis command line interface:
 -->
 2. 启动 Redis 命令行接口：
 
-        redis-cli -p 7000
+   ```shell
+   redis-cli -p 7000
+   ```
 
 <!--
 3.  At the Redis command line prompt, enter the `ping` command:
 -->
 3. 在 Redis 命令行提示符下，输入 `ping` 命令：
 
-        127.0.0.1:7000>ping
-
-<!--
-    A successful ping request returns PONG.
--->
-    成功的 ping 请求应该返回 PONG。
-
-
+   ```
+   127.0.0.1:7000>ping
+   ```
 
+   <!--
+   A successful ping request returns PONG.
+   -->
+   成功的 ping 请求应该返回 PONG。
 
 <!-- discussion -->
 
@@ -223,30 +249,26 @@ Connections made to local port 7000 are forwarded to port 6379 of the pod that
 is running the Redis server. With this connection in place you can use your
 local workstation to debug the database that is running in the pod.
 -->
-## 讨论
+## 讨论  {#discussion}
 
-与本地 7000 端口建立的连接将转发到运行 Redis 服务器的 pod 的 6379 端口。通过此连接，您可以使用本地工作站来调试在 pod 中运行的数据库。
+与本地 7000 端口建立的连接将转发到运行 Redis 服务器的 pod 的 6379 端口。
+通过此连接，您可以使用本地工作站来调试在 pod 中运行的数据库。
 
-{{< warning >}}
 <!--
 Due to known limitations, port forward today only works for TCP protocol.
 The support to UDP protocol is being tracked in
 [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
 -->
-**警告：** 由于已知的限制，目前的端口转发仅适用于 TCP 协议。
-在 [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862) 中正在跟踪对 UDP 协议的支持。
+{{< warning >}}
+由于已知的限制，目前的端口转发仅适用于 TCP 协议。
+在 [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862)
+中正在跟踪对 UDP 协议的支持。
 {{< /warning >}}
 
-
-
-
 ## {{% heading "whatsnext" %}}
 
 <!--
 Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
 -->
-学习更多关于 [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)。
-
-
-
+进一步了解 [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)。
 
diff --git a/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 511ef95ee7..870a030f49 100644
--- a/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -96,9 +96,9 @@ kubectl proxy
 ```
 
 <!--
-Kubectl will make Dashboard available at http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.
+Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/).
 -->
-kubectl 会使得 Dashboard 可以通过 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 访问。
+kubectl 会使得 Dashboard 可以通过 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/) 访问。
 
 <!--
 The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.
@@ -187,13 +187,11 @@ The deploy wizard expects that you provide the following information:
   以保证集群中运行期望的 Pod 数量。
 
 <!--
-- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). For external Services, you may need to open up one or more ports to do so. Find more details [here](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
+- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service).
  -->
 - **服务**（可选）：对于部分应用（比如前端），你可能想对外暴露一个
   [Service](/zh/docs/concepts/services-networking/service/) ，这个 Service
   可能用的是集群之外的公网 IP 地址（外部 Service）。
-  对于外部 Service 的情况，需要开放一个或者多个端口来满足。
-  更多信息请参考 [这里](/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)。
 
   <!-- 
   For external Services, you may need to open up one or more ports to do so.
diff --git a/content/zh/docs/tasks/administer-cluster/_index.md b/content/zh/docs/tasks/administer-cluster/_index.md
index 90ff023cc4..1ef44bc080 100644
--- a/content/zh/docs/tasks/administer-cluster/_index.md
+++ b/content/zh/docs/tasks/administer-cluster/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "管理集群"
 weight: 20
+description: 了解管理集群的常见任务。
 ---
diff --git a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
index 1d2bed1a0a..30ab9330a5 100644
--- a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
@@ -225,14 +225,13 @@ certificate.
 <!--
 On some clusters, the API server does not require authentication; it may serve
 on localhost, or be protected by a firewall. There is not a standard
-for this. [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
-describes how a cluster admin can configure this. Such approaches may conflict
-with future high-availability support.
+for this. [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access)
+describes how you can configure this as a cluster administrator.
 -->
 在一些集群中，API 服务器不需要身份认证；它运行在本地，或由防火墙保护着。
 对此并没有一个标准。
-[配置对 API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)
-阐述了一个集群管理员如何对此进行配置。这种方法可能与未来的高可用性支持发生冲突。
+[配置对 API 的访问](/zh/docs/concepts/security/controlling-access/)
+讲解了作为集群管理员可如何对此进行配置。
 
 <!--
 ### Programmatic access to the API
@@ -277,11 +276,14 @@ Go 客户端可以使用与 kubectl 命令行工具相同的
 [例子](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)：
 
 ```golang
+package main
+
 import (
+   "context"
    "fmt"
-   "k8s.io/client-go/1.4/kubernetes"
-   "k8s.io/client-go/1.4/pkg/api/v1"
-   "k8s.io/client-go/1.4/tools/clientcmd"
+   "k8s.io/apimachinery/pkg/apis/meta/v1"
+   "k8s.io/client-go/kubernetes"
+   "k8s.io/client-go/tools/clientcmd"
 )
 
 func main() {
@@ -291,7 +293,7 @@ func main() {
   // creates the clientset
   clientset, _ := kubernetes.NewForConfig(config)
   // access the API to list pods
-  pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
+  pods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{})
   fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
 }
 ```
diff --git a/content/zh/docs/tasks/administer-cluster/access-cluster-services.md b/content/zh/docs/tasks/administer-cluster/access-cluster-services.md
index cb03264553..32912771ab 100644
--- a/content/zh/docs/tasks/administer-cluster/access-cluster-services.md
+++ b/content/zh/docs/tasks/administer-cluster/access-cluster-services.md
@@ -1,85 +1,192 @@
 ---
-
 title: 访问集群上运行的服务
 content_type: task
 ---
 
 <!-- overview -->
-
+<!--
+This page shows how to connect to services running on the Kubernetes cluster.
+-->
 本文展示了如何连接 Kubernetes 集群上运行的服务。
 
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
 <!-- steps -->
 
+<!--
+## Accessing services running on the cluster
+
+In Kubernetes, [nodes](/docs/concepts/architecture/nodes/),
+[pods](/docs/concepts/workloads/pods/) and [services](/docs/concepts/services-networking/service/) all have
+their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
+routable, so they will not be reachable from a machine outside the cluster,
+such as your desktop machine.
+-->
 ## 访问集群上运行的服务
 
 
-在 Kubernetes 里， [nodes](/docs/admin/node)、[pods](/docs/user-guide/pods) 和  [services](/docs/user-guide/services) 都有它们自己的 IP。许多情况下，集群上的 node IP、pod IP 和某些 service IP 路由不可达，所以不能从一个集群之外的节点访问它们，例如从你自己的台式机。
+在 Kubernetes 里，[Node](/zh/docs/concepts/architecture/nodes/)、
+[Pod](/zh/docs/concepts/workloads/pods/) 和
+[Service](/zh/docs/concepts/services-networking/services/) 都有自己的 IP。
+许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 是路由不可达的，
+所以不能从集群之外访问它们，例如从你自己的台式机。
 
+<!--
+### Ways to connect
 
-### 连接方式
+You have several options for connecting to nodes, pods and services from outside the cluster:
+-->
+### 连接方式   {#ways-to-connect}
 
+你有多种可选方式从集群外连接节点、Pod 和服务：
 
-你有多种从集群外连接 nodes、pods 和 services 的选项：
-
-
-  - 通过公共 IP 访问 services。
-    - 使用具有 `NodePort` 或 `LoadBalancer` 类型的 service，可以从外部访问它们。请查阅 [services](/docs/user-guide/services) 和 [kubectl expose](/docs/user-guide/kubectl/v1.6/#expose) 文档。
-    - 取决于你的集群环境，你可以仅把 service 暴露在你的企业网络环境中，也可以将其暴露在因特网上。需要考虑暴露的 service 是否安全，它是否有自己的用户认证？
-    - 将 pods 放置于 services 背后。如果要访问一个副本集合中特定的 pod，例如用于调试目的时，请给 pod 指定一个独特的标签并创建一个新 service 选择这个标签。
-    - 大部分情况下，都不需要应用开发者通过节点 IP 直接访问 nodes。
-  - 通过 Proxy Verb 访问  services、nodes 或者  pods。
-    - 在访问 Apiserver 远程服务之前是否经过认证和授权？如果你的服务暴露到因特网中不够安全，或者需要获取 node IP 之上的端口，又或者处于调试目的时，请使用这个特性。
-    - Proxies 可能给某些应用带来麻烦。
-    - 仅适用于 HTTP/HTTPS。
-    - 在[这里](#manually-constructing-apiserver-proxy-urls)描述
+<!--
+  - Access services through public IPs.
+    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
+      the cluster.  See the [services](/docs/concepts/services-networking/service/) and
+      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
+    - Depending on your cluster environment, this may just expose the service to your corporate network,
+      or it may expose it to the internet.  Think about whether the service being exposed is secure.
+      Does it do its own authentication?
+    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
+      place a unique label on the pod and create a new service which selects this label.
+    - In most cases, it should not be necessary for application developer to directly access
+      nodes via their nodeIPs.
+-->
+- 通过公网 IP 访问服务
+  - 使用类型为 `NodePort` 或 `LoadBalancer` 的服务，可以从外部访问它们。
+    请查阅[服务](/zh/docs/concepts/services-networking/services/) 和
+    [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
+  - 取决于你的集群环境，你可以仅把服务暴露在你的企业网络环境中，也可以将其暴露在
+    因特网上。需要考虑暴露的服务是否安全，它是否有自己的用户认证？
+  - 将 Pod 放置于服务背后。如果要访问一个副本集合中特定的 Pod，例如用于调试目的，
+    请给 Pod 指定一个独特的标签并创建一个新服务选择该标签。
+  - 大部分情况下，都不需要应用开发者通过节点 IP 直接访问节点。
+<!--
+  - Access services, nodes, or pods using the Proxy Verb.
+    - Does apiserver authentication and authorization prior to accessing the remote service.
+      Use this if the services are not secure enough to expose to the internet, or to gain
+      access to ports on the node IP, or for debugging.
+    - Proxies may cause problems for some web applications.
+    - Only works for HTTP/HTTPS.
+    - Described [here](#manually-constructing-apiserver-proxy-urls).
+-->
+- 通过 Proxy 动词访问服务、节点或者 Pod
+  - 在访问远程服务之前，利用 API 服务器执行身份认证和鉴权。
+    如果你的服务不够安全，无法暴露到因特网中，或者需要访问节点 IP 上的端口，
+    又或者出于调试目的，可使用这种方式。
+  - 代理可能给某些应用带来麻烦
+  - 此方式仅适用于 HTTP/HTTPS
+  - 进一步的描述在[这里](#manually-constructing-apiserver-proxy-urls)
   - 从集群中的 node 或者 pod 访问。
-    - 运行一个 pod，然后使用 [kubectl exec](/docs/user-guide/kubectl/v1.6/#exec) 连接到它的一个shell。从那个 shell 连接其他的 nodes、pods 和 services。
-    - 某些集群可能允许你 ssh 到集群中的节点。你可能可以从那儿访问集群服务。这是一个非标准的方式，可能在一些集群上能工作，但在另一些上却不能。浏览器和其他工具可能安装或可能不会安装。集群 DNS 可能不会正常工作。
+<!--
+  - Access from a node or pod in the cluster.
+    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
+      Connect to other nodes, pods, and services from that shell.
+    - Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
+      access cluster services. This is a non-standard method, and will work on some clusters but
+      not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.
+-->
+- 从集群中的一个节点或 Pod 访问
+  - 运行一个 Pod，然后使用
+    [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
+    连接到它的 Shell。从那个 Shell 连接其他的节点、Pod 和 服务
+  - 某些集群可能允许你 SSH 到集群中的节点。你可能可以从那儿访问集群服务。
+    这是一个非标准的方式，可能在一些集群上能工作，但在另一些上却不能。
+    浏览器和其他工具可能已经安装也可能没有安装。集群 DNS 可能不会正常工作。
 
+<!--
+### Discovering builtin services
 
-### 发现内置服务
+Typically, there are several services which are started on a cluster by kube-system. Get a list of these
+with the `kubectl cluster-info` command:
+-->
+### 发现内置服务   {#discovering-builtin-services}
 
-
-典型情况下，kube-system 会启动集群中的几个服务。使用 `kubectl cluster-info` 命令获取它们的列表：
+典型情况下，kube-system 名字空间中会启动集群的几个服务。
+使用 `kubectl cluster-info` 命令获取这些服务的列表：
 
 ```shell
-$ kubectl cluster-info
-
-  Kubernetes master is running at https://104.197.5.247
-  elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
-  kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
-  kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
-  grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
-  heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+kubectl cluster-info
 ```
 
-这显示了用于访问每个服务的 proxy-verb URL。例如，这个集群启用了（使用 Elasticsearch）集群层面的日志，如果提供合适的凭据可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 访问，或通过一个 kubectl 代理地址访问，如：`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。（请查看  [上文](#accessing-the-cluster-api) 关于如何传递凭据或者使用 kubectl 代理的说明。）
+<!--
+The output is similar to this:
+-->
+输出类似于：
 
+```
+Kubernetes master is running at https://104.197.5.247
+elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
+kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
+kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
+grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
+heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+```
 
-#### 手动构建 apiserver 代理 URLs
+<!--
+This shows the proxy-verb URL for accessing each service.
+For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
+at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example:
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
+-->
+这一输出显示了用 proxy 动词访问每个服务时可用的 URL。例如，此集群
+（使用 Elasticsearch）启用了集群层面的日志。如果提供合适的凭据，可以通过
+`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 访问，或通过一个 `kubectl proxy` 来访问：`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。
 
+<!--
+See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.
+-->
+{{< note >}}
+请参阅[使用 Kubernets API 访问集群](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api)了解如何传递凭据或如何使用 `kubectl proxy`。
+{{< /note >}}
 
-如同上面所提到的，你可以使用 `kubectl cluster-info` 命令取得 service 的代理 URL。为了创建包含 service endpoints、suffixes 和 parameters 的代理 URLs，你可以简单的在 service 的代理 URL中 添加：
+<!--
+#### Manually constructing apiserver proxy URLs
+
+As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you simply append to the service's proxy URL:
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
+
+If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
+-->
+#### 手动构建 API 服务器代理 URLs   {#manually-constructing-apiserver-proxy-urls}
+
+如前所述，你可以使用 `kubectl cluster-info` 命令取得服务的代理 URL。
+为了创建包含服务末端、后缀和参数的代理 URLs，你可以简单地在服务的代理 URL 中添加：
 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
 
-
 如果还没有为你的端口指定名称，你可以不用在 URL 中指定 *port_name*。
 
+<!--
+##### Examples
 
+* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:
+-->
 ##### 示例
 
+* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`，你可以使用： 
 
- * 你可以通过 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy` 访问 Elasticsearch service endpoint `_search?q=user:kimchy`。
- * 你可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true` 访问 Elasticsearch 集群健康信息 endpoint `_cluster/health?pretty=true`。
+  ```
+  http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
+  ```
 
-```json
+<!--
+* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:
+-->
+* 如要访问 Elasticsearch 集群健康信息`_cluster/health?pretty=true`，你会使用：
+
+  ```
+  https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true` 
+  ```
+
+  <!--
+  The health information is similar to this:
+  -->
+  健康信息与下面的例子类似：
+
+  ```json
   {
     "cluster_name" : "kubernetes_logging",
     "status" : "yellow",
@@ -92,18 +199,34 @@ $ kubectl cluster-info
     "initializing_shards" : 0,
     "unassigned_shards" : 5
   }
-```
+  ```
 
+<!--
+* To access the *https* Elasticsearch service health information `_cluster/health?pretty=true`, you would use:
+-->
+* 要访问 *https* Elasticsearch 服务健康信息 `_cluster/health?pretty=true`，你会使用：
 
-#### 通过 web 浏览器访问集群中运行的服务
+  ```
+  https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true
+  ```
 
+<!--
+#### Using web browsers to access services running on the cluster
 
-你或许能够将 apiserver 代理的 url 放入浏览器的地址栏，然而：
-
-
-  - Web 服务器不总是能够传递令牌，所以你可能需要使用基本（密码）认证。 Apiserver 可以配置为接受基本认证，但你的集群可能并没有这样配置。
-  - 某些 web 应用可能不能工作，特别是那些使用客户端侧 javascript 的应用，它们构造 url 的方式可能不能理解代理路径前缀。
-
+You may be able to put an apiserver proxy URL into the address bar of a browser. However:
+-->
+#### 通过 Web 浏览器访问集群中运行的服务
 
+你或许能够将 API 服务器代理的 URL 放入浏览器的地址栏，然而：
 
+<!--
+- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
+    but your cluster may not be configured to accept basic auth.
+- Some web apps may not work, particularly those with client side javascript that construct URLs in a
+    way that is unaware of the proxy path prefix.
+-->
+- Web 服务器通常不能传递令牌，所以你可能需要使用基本（密码）认证。 
+  API 服务器可以配置为接受基本认证，但你的集群可能并没有这样配置。
+- 某些 Web 应用可能无法工作，特别是那些使用客户端 Javascript 构造 URL 的
+  应用，所构造的 URL 可能并不支持代理路径前缀。
 
diff --git a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index a2b6d89e0c..d02b8d2435 100644
--- a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -2,86 +2,141 @@
 title: 更改 PersistentVolume 的回收策略
 content_type: task
 ---
-
-
 <!-- overview -->
-
+<!--
+This page shows how to change the reclaim policy of a Kubernetes
+PersistentVolume.
+-->
 本文展示了如何更改 Kubernetes PersistentVolume 的回收策略。
 
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
 <!-- steps -->
 
+<!--
+## Why change reclaim policy of a PersistentVolume
 
+PersistentVolumes can have various reclaim policies, including "Retain",
+"Recycle", and "Delete". For dynamically provisioned PersistentVolumes,
+the default reclaim policy is "Delete". This means that a dynamically provisioned
+volume is automatically deleted when a user deletes the corresponding
+PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume
+contains precious data. In that case, it is more appropriate to use the "Retain"
+policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim,
+the corresponding PersistentVolume is not be deleted. Instead, it is moved to the
+Released phase, where all of its data can be manually recovered.
+-->
 ## 为什么要更改 PersistentVolume 的回收策略
 
+PersistentVolumes 可以有多种回收策略，包括 "Retain"、"Recycle" 和  "Delete"。
+对于动态配置的 PersistentVolumes 来说，默认回收策略为 "Delete"。
+这表示当用户删除对应的 PersistentVolumeClaim 时，动态配置的 volume 将被自动删除。
+如果 volume 包含重要数据时，这种自动行为可能是不合适的。
+那种情况下，更适合使用 "Retain" 策略。
+使用 "Retain" 时，如果用户删除 PersistentVolumeClaim，对应的 PersistentVolume 不会被删除。
+相反，它将变为 Released 状态，表示所有的数据可以被手动恢复。
 
-PersistentVolumes 可以有多种回收策略，包括 "Retain"、"Recycle" 和  "Delete"。对于动态配置的 PersistentVolumes 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 PersistentVolumeClaim 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 "Retain" 策略。使用 "Retain" 时，如果用户删除 PersistentVolumeClaim，对应的 PersistentVolume 不会被删除。相反，它将变为 Released 状态，表示所有的数据可以被手动恢复。
-
-
+<!--
+## Changing the reclaim policy of a PersistentVolume
+-->
 ## 更改 PersistentVolume 的回收策略
 
-
+<!--
+1. List the PersistentVolumes in your cluster:
+-->
 1. 列出你集群中的 PersistentVolumes
 
-       kubectl get pv
+   ```shell
+   kubectl get pv
+   ```
 
-    输出类似于这样：
+   输出类似于这样：
 
-        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
-        pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1                   10s
-        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2                   6s
-        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3                   3s
-
-
-   这个列表同样包含了绑定到每个 volume 的 claims 名称，以便更容易的识别动态配置的 volumes。
+   ```
+   NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
+   pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1                   10s
+   pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2                   6s
+   pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3                   3s
+   ```
 
+   <!--
+   This list also includes the name of the claims that are bound to each volume
+   for easier identification of dynamically provisioned volumes.
+   -->
+   这个列表同样包含了绑定到每个卷的 claims 名称，以便更容易的识别动态配置的卷。
 
+<!--
+1. Choose one of your PersistentVolumes and change its reclaim policy:
+-->
 2. 选择你的 PersistentVolumes 中的一个并更改它的回收策略：
 
-    ```shell
-    kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
-    ```
+   ```shell
+   kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
+   ```
 
-    这里的 `<your-pv-name>` 是你选择的 PersistentVolume 的名字。
+   <!--
+   where `<your-pv-name>` is the name of your chosen PersistentVolume.
+   -->
+   这里的 `<your-pv-name>` 是你选择的 PersistentVolume 的名字。
 
+   <!--
+   On Windows, you must _double_ quote any JSONPath template that contains spaces
+   (not single quote as shown above for bash). This in turn means that you must
+   use a single quote or escaped double quote around any literals in the template. For example:
+   -->
+   {{< note >}}
+   在 Windows 系统上，你必须对包含空格的 JSONPath 模板加双引号（而不是像上面
+   一样为 Bash 环境使用的单引号）。这也意味着你必须使用单引号或者转义的双引号
+   来处理模板中的字面值。例如：
+
+   ```cmd
+   kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
+   ```
+   {{< /note >}}
+
+<!--
+1. Verify that your chosen PersistentVolume has the right policy:
+-->
 3. 验证你选择的 PersistentVolume 拥有正确的策略：
 
-    ```shell
-    kubectl get pv
-    ```
+   ```shell
+   kubectl get pv
+   ```
 
-    输出类似于这样：
-
-        NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
-        pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1                   40s
-        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2                   36s
-        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3                   33s
-
-
-    在前面的输出中，你可以看到绑定到 claim `default/claim3` 的 volume 拥有的回收策略为 `Retain`。当用户删除 claim `default/claim3` 时，它不会被自动删除。
+   <!--
+   The output is similar to this:
+   -->
+   输出类似于这样：
 
+   ```
+   NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                  REASON    AGE
+   pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1                   40s
+   pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2                   36s
+   pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3                   33s
+   ```
 
+   <!--
+   In the preceding output, you can see that the volume bound to claim
+   `default/claim3` has reclaim policy `Retain`. It will not be automatically
+   deleted when a user deletes claim `default/claim3`.
+   -->
+   在前面的输出中，你可以看到绑定到申领 `default/claim3` 的卷的回收策略为 `Retain`。
+   当用户删除申领 `default/claim3` 时，它不会被自动删除。
 
 ## {{% heading "whatsnext" %}}
 
-
-* 了解更多关于 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)的信息。
-* 了解更多关于 [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 的信息。
-
+<!--
+* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
+* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
+-->
+* 进一步了解 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
+* 进一步了解 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
 
 ### 参考
 
 * [PersistentVolume](/docs/api-reference/{{< param "version" >}}/#persistentvolume-v1-core)
 * [PersistentVolumeClaim](/docs/api-reference/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
-
-* 查阅  [PersistentVolumeSpec](/docs/api-reference/{{< param "version" >}}/#persistentvolumeclaim-v1-core) 的 `persistentVolumeReclaimPolicy` 字段。
-
-
+* 参阅 [PersistentVolumeSpec](/docs/api-reference/{{< param "version" >}}/#persistentvolumeclaim-v1-core) 的 `persistentVolumeReclaimPolicy` 字段
 
diff --git a/content/zh/docs/tasks/administer-cluster/cluster-management.md b/content/zh/docs/tasks/administer-cluster/cluster-management.md
deleted file mode 100644
index c70475e6bf..0000000000
--- a/content/zh/docs/tasks/administer-cluster/cluster-management.md
+++ /dev/null
@@ -1,452 +0,0 @@
----
-approvers:
-- lavalamp
-- thockin
-title: 集群管理
-content_type: task
----
-
-<!--
-This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
-upgrading your cluster's
-master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
-running cluster.
--->
-本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的主控节点和工作节点、
-执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。
-
-<!-- body -->
-
-<!--
-## Creating and configuring a Cluster
-
-To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/setup/) depending on your environment.
--->
-## 创建和配置集群
-
-要在一组机器上安装 Kubernetes，请根据你的环境，查阅现有的[入门指南](/zh/docs/setup/)
-
-
-<!--
-## Upgrading a cluster
-
-The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG/README.md), as well as the version specific upgrade notes prior to upgrading their clusters.
--->
-## 升级集群
-
-集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。
-推荐管理员在升级他们的集群前，同时查阅
-[发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。
-
-<!--
-### Upgrading an Azure Kubernetes Service (AKS) cluster
-
-Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
-currently user-initiated and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
--->
-### 升级 Azure Kubernetes Service（AKS）集群
-
-Azure Kubernetes Service 支持自服务式的控制面升级和集群节点升级。
-升级过程目前是由用户发起的，具体文档参见
-[Azure AKS 文档](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)。
-
-<!--
-### Upgrading Google Compute Engine clusters
-
-Google Compute Engine Open Source (GCE-OSS) support master upgrades by deleting and
-recreating the master, while maintaining the same Persistent Disk (PD) to ensure that data is retained across the
-upgrade.
--->
-### 升级 Google Compute Engine 集群
-
-Google Compute Engine Open Source（GCE-OSS）通过删除和重建主控节点来支持主控节点升级。
-通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。
-
-<!--
-Node upgrades for GCE use a [Managed Instance Group](https://cloud.google.com/compute/docs/instance-groups/), each node
-is sequentially destroyed and then recreated with new software.  Any Pods that are running on that node need to be
-controlled by a Replication Controller, or manually re-created after the roll out.
--->
-GCE 的 节点升级采用[受控实例组](https://cloud.google.com/compute/docs/instance-groups/)，
-每个节点将被顺序删除，然后使用新软件重建。
-任何运行在那个节点上的 Pod 需要用副本控制器控制，或者在扩容之后手动重建。
-
-<!--
-Upgrades on open source Google Compute Engine (GCE) clusters are controlled by the `cluster/gce/upgrade.sh` script.
-
-Get its usage by running `cluster/gce/upgrade.sh -h`.
-
-For example, to upgrade just your master to a specific version (v1.0.2):
--->
-开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。
-
-运行 `cluster/gce/upgrade.sh -h` 获取使用说明。
-
-例如，只将主控节点升级到一个指定的版本（v1.0.2）：
-
-```shell
-cluster/gce/upgrade.sh -M v1.0.2
-```
-
-<!--
-Alternatively, to upgrade your entire cluster to the latest stable release:
--->
-或者，将整个集群升级到最新的稳定版本：
-
-```shell
-cluster/gce/upgrade.sh release/stable
-```
-
-<!--
-### Upgrading Google Kubernetes Engine clusters
-
-Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.
--->
-### 升级 Google Kubernetes Engine 集群
-
-Google Kubernetes Engine 自动升级主控节点组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。
-它还负责主控节点运行的操作系统和其它组件的升级。
-
-<!--
-The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).
--->
-节点升级过程由用户发起，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)中有相关描述。
-
-<!--
-### Upgrading an Amazon EKS Cluster
-
-Amazon EKS cluster's master components can be upgraded by using eksctl, AWS Management Console, or AWS CLI. The process is user-initiated and is described in the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
--->
-### 升级 Amazon EKS 集群
-
-Amazon EKS 集群的主控组件可以使用 eksctl、AWS 管理控制台或者 AWS CLI 来升级。
-升级过程由用户发起，具体参看
-[Amazon EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)。
-
-<!--
-### Upgrading an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster
-
-Oracle creates and manages a set of master nodes in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these master nodes to new versions of Kubernetes with zero downtime. These actions are described in the [OKE documentation](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm). 
--->
-### 升级 Oracle Cloud Infrastructure 上的 Container Engine for Kubernetes (OKE) 集群
-
-Oracle 在 Oracle 控制面替你创建和管理一组主控节点（及相关的 Kubernetes 基础设施，
-如 etcd 节点）。你可以在不停机的情况下无缝升级这些主控节点到新的 Kubernetes 版本。
-相关的操作可参考
-[OKE 文档](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)。 
-
-<!--
-### Upgrading clusters on other platforms
-
-Different providers, and tools, will manage upgrades differently.  It is recommended that you consult their main documentation regarding upgrades.
--->
-### 在其他平台上升级集群
-
-不同的供应商和工具管理升级的过程各不相同。建议你查阅它们有关升级的主要文档。
-
-* [kops](https://github.com/kubernetes/kops)
-* [kubespray](https://github.com/kubernetes-incubator/kubespray)
-* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
-* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
-* ...
-
-<!--
-To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the
-[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
--->
-要在上面列表中没有提及的平台上升级集群时，请参阅
-[版本偏差](/zh/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
-页面所讨论的组件升级顺序。
-
-<!--
-## Resizing a cluster
-
-If your cluster runs short on resources you can easily add more machines to it if your cluster
-is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
-If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes.
-It can be accomplished by modifying number of instances on
-`Compute > Compute Engine > Instance groups > your group > Edit group`
-[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
--->
-## 调整集群大小
-
-如果集群资源短缺，且集群正运行在
-[节点自注册模式](/zh/docs/concepts/architecture/nodes/#self-registration-of-nodes)，
-你可以轻松地添加更多的机器。
-如果正在使用的是 GCE 或者 Google Kubernetes Engine，添加节点将通过调整管理节点的实例组的大小完成。
-在  [Google Cloud 控制台](https://console.developers.google.com) 页面
-的 `Compute > Compute Engine > Instance groups > your group > Edit group`
-下修改实例数量或使用 gcloud CLI 都可以完成这个任务。
-
-```shell
-gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE
-```
-
-<!--
-The Instance Group will take care of putting appropriate image on new machines and starting them,
-while the Kubelet will register its Node with the API server to make it available for scheduling.
-If you scale the instance group down, system will randomly choose Nodes to kill.
--->
-实例组将负责在新机器上放置恰当的镜像并启动它们。
-kubelet 将向 API 服务器注册它的节点以使其可以用于调度。
-如果你对实例组进行缩容，系统将会随机选取节点来终止。
-
-<!--
-In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.
--->
-在其他环境中，你可能需要手动配置机器并告诉 kubelet API 服务器在哪台机器上运行。
-
-<!--
-### Cluster autoscaling
-
-If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
-pod needs.
--->
-### 集群自动伸缩
-
-如果正在使用 GCE 或者 Google Kubernetes Engine，你可以配置你的集群，
-使其能够基于 Pod 需求自动重新调整大小。
-
-<!--
-As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/),
-users can reserve how much CPU and memory is allocated to pods.
-This information is used by the Kubernetes scheduler to find a place to run the pod. If there is
-no node that has enough free capacity (or doesn't match other pod requirements) then the pod has
-to wait until some pods are terminated or a new node is added.
--->
-如[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)所述，
-用户可以控制预留多少 CPU 和内存来分配给 Pod。
-这个信息被 Kubernetes 调度器用来寻找一个运行 Pod 的地方。
-如果没有一个节点有足够的空闲容量（或者不能满足 Pod 的其他需求），
-这个 Pod 就需要等待某些 Pod 结束，或者一个新的节点被添加。
-
-<!--
-Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar
-to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods.
--->
-集群 Autoscaler 查找不能被调度的 Pod 并检查添加一个新节点（和集群中其它节点类似的）
-是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 Pod。
-
-<!--
-Cluster autoscaler also scales down the cluster if it notices that one or more nodes are not needed anymore for
-an extended period of time (10min but it may change in the future).
--->
-如果发现在一段延时时间内（默认 10 分钟，将来有可能改变）某些节点不再需要，
-集群 Autoscaler 也会缩小集群。
-
-<!--
-Cluster autoscaler is configured per instance group (GCE) or node pool (Google Kubernetes Engine).
--->
-集群 Autoscaler 基于每个实例组（GCE）或节点池（Google Kubernetes Engine）来配置。
-
-<!--
-If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
-To configure cluster autoscaler you have to set three environment variables:
--->
-如果你使用 GCE，那么你可以在使用 kube-up.sh 脚本创建集群的时候启用集群自动扩缩。
-要想配置集群 Autoscaler，你需要设置三个环境变量：
-
-<!--
-* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true.
-* `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster.
-* `KUBE_AUTOSCALER_MAX_NODES` - maximum number of nodes in the cluster.
-
-Example:
--->
-* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - 如果设置为 true 将启用集群 Autoscaler。
-* `KUBE_AUTOSCALER_MIN_NODES` - 集群的最小节点数量。
-* `KUBE_AUTOSCALER_MAX_NODES` - 集群的最大节点数量。
-
-示例：
-
-```shell
-KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
-```
-
-<!--
-On Google Kubernetes Engine you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
-(which you want to be autoscaled) by passing flags `--enable-autoscaling` `--min-nodes` and `--max-nodes`
-to the corresponding `gcloud` commands.
-
-Examples:
--->
-在 Google Kubernetes Engine 上，你可以在创建、更新集群或创建一个特别的（你希望自动伸缩的）
-节点池时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling`、`--min-nodes` 和
-`--max-nodes` 来配置集群 Autoscaler。
-
-示例：
-
-```shell
-gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
-```
-
-```shell
-gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
-```
-
-
-<!--
-**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
-
-For more details about how the cluster autoscaler decides whether, when and how
-to scale a cluster, please refer to the [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
-documentation from the autoscaler project.
--->
-
-**集群 Autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因自行指定的属性
-可能不能被传递到相同节点组中的新节点上。**
-
-关于集群 Autoscaler 如何决定是否、合适以及怎样对集群进行缩放的细节，请参考 autoscaler 项目的
-[FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
-文档。
-
-
-<!--
-## Maintenance on a Node
-
-If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is
-brief, then when the Kubelet restarts, it will attempt to restart the pods scheduled to it.  If the reboot takes longer
-(the default time is 5 minutes, controlled by `-pod-eviction-timeout` on the controller-manager),
-then the node controller will terminate the pods that are bound to the unavailable node.  If there is a corresponding
-replica set (or replication controller), then a new copy of the pod will be started on a different node.  So, in the case where all
-pods are replicated, upgrades can be done without special coordination, assuming that not all nodes will go down at the same time.
--->
-## 维护节点
-
-如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，
-kubelet 重启后，将尝试重启调度到节点上的 Pod。如果重启花费较长时间（默认时间为 5 分钟，由
-控制器管理器的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 Pod。
-如果存在对应的 ReplicaSet（或者 ReplicationController），则将在另一个节点上启动  Pod 的新副本。
-所以，如果所有的 Pod 都是多副本的，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊
-调整情况下完成。
-
-<!--
-If you want more control over the upgrading process, you may use the following workflow:
-
-Use `kubectl drain` to gracefully terminate all pods on the node while marking the node as unschedulable:
--->
-如果你希望对升级过程有更多的控制，可以使用下面的工作流程：
-
-使用 `kubectl drain` 体面地结束节点上的所有 Pod 并同时标记节点为不可调度：
-
-```shell
-kubectl drain $NODENAME
-```
-
-<!--
-This keeps new pods from landing on the node while you are trying to get them off.
-
-For pods with a replica set, the pod will be replaced by a new pod which will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
--->
-在你试图使节点离线时，这样做将阻止新的 Pod 落到它们上面。
-
-对于有 ReplicaSet 的 Pod 来说，它们将会被新的 Pod 替换并且将被调度到一个新的节点。
-此外，如果 Pod 是一个 Service 的一部分，则客户端将被自动重定向到新的 Pod。
-
-<!--
-For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
-
-Perform maintenance work on the node.
-
-Make the node schedulable again:
--->
-对于没有 ReplicaSet 的 Pod，你需要手动启动 Pod 的新副本，并且
-如果它不是 Service 的一部分，你需要手动将客户端重定向到这个 Pod。
-
-在节点上执行维护工作。
-
-重新使节点可调度：
-
-```shell
-kubectl uncordon $NODENAME
-```
-
-<!--
-If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
-be created automatically (if you're using a cloud provider that supports
-node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
-See [Node](/docs/concepts/architecture/nodes/) for more details.
--->
-如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建
-（只在你使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，
-不包括在 Google Compute Engine 上使用  kube-register 的 CoreOS）。
-相关详细信息，请查阅[节点](/zh/docs/concepts/architecture/nodes/)。
-
-<!--
-## Advanced Topics
-
-### Upgrading to a different API version
-
-When a new API version is released, you may need to upgrade a cluster to support the new API version (e.g. switching from 'v1' to 'v2' when 'v2' is launched).
--->
-## 高级主题
-
-### 升级到不同的 API 版本
-
-当新的 API 版本发布时，你可能需要升级集群支持新的 API 版本
-（例如当 'v2' 发布时从  'v1' 切换到 'v2'）。
-
-<!--
-This is an infrequent event, but it requires careful management. There is a sequence of steps to upgrade to a new API version.
-
-   1. Turn on the new API version.
-   1. Upgrade the cluster's storage to use the new version.
-   1. Upgrade all config files. Identify users of the old API version endpoints.
-   1. Update existing objects in the storage to new version by running `cluster/update-storage-objects.sh`.
-   1. Turn off the old API version.
--->
-这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。
-
-1. 开启新 API 版本
-1. 升级集群存储来使用新版本
-1. 升级所有配置文件；识别使用旧 API 版本末端的用户
-1. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本
-1. 关闭旧 API 版本
-
-<!--
-### Turn on or off an API version for your cluster
-
-Specific API versions can be turned on or off by passing `-runtime-config=api/<version>` flag while bringing up the API server. For example: to turn off v1 API, pass `--runtime-config=api/v1=false`.
-runtime-config also supports 2 special keys: api/all and api/legacy to control all and legacy APIs respectively.
-For example, for turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`.
-For the purposes of these flags, _legacy_ APIs are those APIs which have been explicitly deprecated (e.g. `v1beta3`).
--->
-### 打开或关闭集群的 API 版本
-
-可以在启动 API 服务器时传递 `--runtime-config=api/<version>` 标志来打开或关闭特定的 API 版本。
-例如：要关闭 v1 API，请传递 `--runtime-config=api/v1=false`。
-`runtime-config` 还支持两个特殊键值：`api/all` 和 `api/legacy`，分别控制全部和遗留 API。
-例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。
-对于这些标志来说，_遗留（Legacy）_ API 指的是那些被显式废弃的 API（例如  `v1beta3`）。
-
-<!--
-### Switching your cluster's storage API version
-
-The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
-When the supported API changes, these objects may need to be rewritten in the newer API.  Failure to do this will eventually result in resources that are no longer decodable or usable
-by the Kubernetes API server.
--->
-### 切换集群存储的 API 版本
-
-存储于磁盘中、用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本表达。
-当所支持的 API 改变时，这些对象可能需要使用更新的 API 重写。
-重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。
-
-<!--
-### Switching your config files to a new API version
-
-You can use `kubectl convert` command to convert config files between different API versions.
--->
-### 切换配置文件到新 API 版本
-
-你可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。
-
-```shell
-kubectl convert -f pod.yaml --output-version v1
-```
-
-<!--
-For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
--->
-更多选项请参考 [`kubectl convert`](/docs/reference/generated/kubectl/kubectl-commands/#convert)  命令用法。
-
diff --git a/content/zh/docs/tasks/administer-cluster/cluster-upgrade.md b/content/zh/docs/tasks/administer-cluster/cluster-upgrade.md
new file mode 100644
index 0000000000..e9b9d0dec5
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/cluster-upgrade.md
@@ -0,0 +1,182 @@
+---
+title: 升级集群
+content_type: task
+---
+<!-- 
+---
+title: Upgrade A Cluster
+content_type: task
+---
+-->
+
+<!-- overview -->
+<!-- 
+This page provides an overview of the steps you should follow to upgrade a
+Kubernetes cluster.
+
+The way that you upgrade a cluster depends on how you initially deployed it
+and on any subsequent changes.
+
+At a high level, the steps you perform are:
+-->
+本页概述升级 Kubernetes 集群的步骤。
+
+升级集群的方式取决于你最初部署它的方式、以及后续更改它的方式。
+
+从高层规划的角度看，要执行的步骤是：
+
+<!-- 
+- Upgrade the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+- Upgrade the nodes in your cluster
+- Upgrade clients such as {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
+- Adjust manifests and other resources based on the API changes that accompany the
+  new Kubernetes version
+-->
+- 升级{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}
+- 升级集群中的节点
+- 升级 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 之类的客户端
+- 根据新 Kubernetes 版本带来的 API 变化，调整清单文件和其他资源
+
+## {{% heading "prerequisites" %}}
+
+<!-- 
+You must have an existing cluster. This page is about upgrading from Kubernetes
+{{< skew prevMinorVersion >}} to Kubernetes {{< skew latestVersion >}}. If your cluster
+is not currently running Kubernetes {{< skew prevMinorVersion >}} then please check
+the documentation for the version of Kubernetes that you plan to upgrade to.
+-->
+你必须有一个集群。
+本页内容涉及从 Kubernetes {{< skew prevMinorVersion >}} 
+升级到 Kubernetes {{< skew latestVersion >}}。
+如果你的集群未运行 Kubernetes {{< skew prevMinorVersion >}}，
+那请参考目标 Kubernetes 版本的文档。
+
+<!-- ## Upgrade approaches -->
+## 升级方法 {#upgrade-approaches}
+
+### kubeadm {#upgrade-kubeadm}
+
+<!-- 
+If your cluster was deployed using the `kubeadm` tool, refer to 
+[Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+for detailed information on how to upgrade the cluster.
+
+Once you have upgraded the cluster, remember to
+[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
+-->
+如果你的集群是使用 `kubeadm` 安装工具部署而来，
+那么升级群集的详细信息，请参阅
+[升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。
+
+升级集群之后，要记得
+[安装最新版本的 `kubectl`](/zh/docs/tasks/tools/install-kubectl/).
+
+<!-- ### Manual deployments -->
+### 手动部署 {#manual-deployments}
+
+<!-- 
+These steps do not account for third-party extensions such as network and storage
+plugins.
+
+You should manually update the control plane following this sequence:
+-->
+{{< caution >}}
+这些步骤不考虑第三方扩展，例如网络和存储插件。
+{{< /caution >}}
+
+你应该跟随下面操作顺序，手动更新控制平面：
+
+<!-- 
+- etcd (all instances)
+- kube-apiserver (all control plane hosts)
+- kube-controller-manager
+- kube-scheduler
+- cloud controller manager, if you use one
+-->
+- etcd (所有实例)
+- kube-apiserver (所有控制平面的宿主机)
+- kube-controller-manager
+- kube-scheduler
+- cloud controller manager, 在你用到时
+
+<!-- 
+At this point you should
+[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
+
+For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/)
+that node and then either replace it with a new node that uses the {{< skew latestVersion >}}
+kubelet, or upgrade the {{< skew latestVersion >}}
+kubelet on that node and bring the node back into service.
+-->
+现在，你应该
+[安装最新版本的 `kubectl`](/zh/docs/tasks/tools/install-kubectl/).
+
+对于群集中的每个节点，
+[排空](/zh/docs/tasks/administer-cluster/safely-drain-node/)
+节点，然后，或者用一个运行了 {{< skew latestVersion >}} kubelet 的新节点替换它；
+或者升级此节点的 kubelet，并使节点恢复服务。
+
+<!-- 
+### Other deployments {#upgrade-other}
+
+Refer to the documentation for your cluster deployment tool to learn the recommended set
+up steps for maintenance.
+
+## Post-upgrade tasks
+
+### Switch your cluster's storage API version
+-->
+### 其他部署方式 {#upgrade-other}
+
+参阅你的集群部署工具对应的文档，了解用于维护的推荐设置步骤。
+
+## 升级后的任务 {#post-upgrade-tasks}
+
+### 切换群集的存储 API 版本 {#switch-your-clusters-storage-api-version}
+
+<!-- 
+The objects that are serialized into etcd for a cluster's internal
+representation of the Kubernetes resources active in the cluster are
+written using a particular version of the API.
+
+When the supported API changes, these objects may need to be rewritten
+in the newer API. Failure to do this will eventually result in resources
+that are no longer decodable or usable by the Kubernetes API server.
+
+For each affected object, fetch it using the latest supported API and then
+write it back also using the latest supported API.
+-->
+对象序列化到 etcd，是为了提供集群中活动 Kubernetes 资源的内部表示法，
+这些对象都使用特定版本的 API 编写。
+
+当底层的 API 更改时，这些对象可能需要用新 API 重写。
+如果不能做到这一点，会导致再也不能用 Kubernetes API 服务器解码、使用该对象。
+
+对于每个受影响的对象，用最新支持的 API 获取它，然后再用最新支持的 API 写回来。
+
+<!-- 
+### Update manifests
+
+Upgrading to a new Kubernetes version can provide new APIs.
+
+You can use `kubectl convert` command to convert manifests between different API versions.
+For example:
+-->
+### 更新清单 {#update-manifests}
+
+升级到新版本 Kubernetes 就可以提供新的 API。
+
+你可以使用 `kubectl convert` 命令在不同 API 版本之间转换清单。
+例如：
+
+```shell
+kubectl convert -f pod.yaml --output-version v1
+```
+
+<!-- 
+The `kubectl` tool replaces the contents of `pod.yaml` with a manifest that sets `kind` to
+Pod (unchanged), but with a revised `apiVersion`.
+-->
+`kubectl` 替换了 `pod.yaml` 的内容，
+在新的清单文件中，`kind` 被设置为 Pod（未变），
+但 `apiVersion` 则被修订了。
diff --git a/content/zh/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/zh/docs/tasks/administer-cluster/configure-upgrade-etcd.md
index 9d88d93518..b17cb265ad 100644
--- a/content/zh/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/zh/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -16,11 +16,7 @@ content_type: task
 -->
 
 <!-- overview -->
-
-<!--
-{{< glossary_definition term_id="etcd" length="all" prepend="etcd is a ">}}
--->
-{{< glossary_definition term_id="etcd" length="all" prepend="etcd 是一个">}}
+{{< glossary_definition term_id="etcd" length="all" >}}
 
 
 
diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
index efe1942339..69454747d2 100644
--- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
@@ -21,6 +21,8 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do
 [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)
 声明网络策略去管理 Pod 之间的通信
 
+{{% thirdparty-content %}}
+
 ## {{% heading "prerequisites" %}}
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@@ -42,14 +44,6 @@ Make sure you've configured a network provider with network policy support. Ther
 * [Romana](/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
 * [Weave 网络](/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
 
-<!--
-The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
--->
-{{< note >}}
-以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。
-下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的
-{{< /note >}}
-
 <!-- steps -->
 
 <!--
@@ -74,7 +68,7 @@ Expose the Deployment through a Service called `nginx`.
 -->
 将此 Deployment 以名为 `nginx` 的 Service 暴露出来：
 
-```console
+```shell
 kubectl expose deployment nginx --port=80
 ```
 
@@ -89,7 +83,7 @@ The above commands create a Deployment with an nginx Pod and expose the Deployme
 Service 暴露出来。名为 `nginx` 的 Pod 和 Deployment 都位于 `default`
 名字空间内。
 
-```console
+```shell
 kubectl get svc,pod
 ```
 ```none
@@ -111,7 +105,7 @@ You should be able to access the new `nginx` service from other Pods. To access
 你应该可以从其它的 Pod 访问这个新的 `nginx` 服务。
 要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
 
-```console
+```shell
 kubectl run busybox --rm -ti --image=busybox /bin/sh
 ```
 
@@ -167,7 +161,7 @@ Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file:
 
 使用 kubectl 根据上面的 `nginx-policy.yaml` 文件创建一个 NetworkPolicy：
 
-```console
+```shell
 kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
 ```
 ```none
@@ -183,7 +177,7 @@ When you attempt to access the `nginx` Service from a Pod without the correct la
 
 如果你尝试从没有设定正确标签的 Pod 中去访问 `nginx` 服务，请求将会超时：
 
-```console
+```shell
 kubectl run busybox --rm -ti --image=busybox -- /bin/sh
 ```
 
@@ -210,7 +204,7 @@ You can create a Pod with the correct labels to see that the request is allowed:
 
 创建一个拥有正确标签的 Pod，你将看到请求是被允许的：
 
-```console
+```shell
 kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
 ```
 <!--
diff --git a/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
index 168d01d664..330416050c 100644
--- a/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -151,12 +151,11 @@ data:
         ready
         kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
-           upstream
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
         }
         prometheus :9153
-        proxy ./etc/resolv.conf
+        forward ./etc/resolv.conf
         cache 30
         loop
         reload
@@ -221,7 +220,7 @@ You can modify the default CoreDNS behavior by modifying the ConfigMap.
 
 CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/).
 -->
-### 使用 CoreDN 配置存根域和上游域名服务器
+### 使用 CoreDNS 配置存根域和上游域名服务器
 
 CoreDNS 能够使用 [forward 插件](https://coredns.io/plugins/forward/)配置存根域和上游域名服务器。
 
@@ -251,7 +250,7 @@ To explicitly force all non-cluster DNS lookups to go through a specific nameser
 指向该域名服务器，而不是 `/etc/resolv.conf`。
 
 ```
-proxy .  172.16.0.1
+forward .  172.16.0.1
 ``` 
 
 <!-- 
diff --git a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
index 423c8e5d8f..2603ecc49c 100644
--- a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
+++ b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -129,7 +129,7 @@ add-on or with associated Services:
 -->
 下列错误表示 CoreDNS （或 kube-dns）插件或者相关服务出现了问题：
 
-```
+```shell
 kubectl exec -i -t dnsutils -- nslookup kubernetes.default
 ```
 
@@ -156,7 +156,7 @@ nslookup: can't resolve 'kubernetes.default'
 
 Use the `kubectl get pods` command to verify that the DNS pod is running.
 -->
-### 检查 DNS Pod 是否运行
+### 检查 DNS Pod 是否运行   {#check-if-the-dns-pod-is-running}
 
 使用 `kubectl get pods` 命令来验证 DNS Pod 是否运行。
 
@@ -192,7 +192,7 @@ will have to deploy it manually.
 
 Use `kubectl logs` command to see logs for the DNS containers.
 -->
-### 检查 DNS Pod 里的错误
+### 检查 DNS Pod 里的错误    {#check-for-errors-in-the-dns-pod}
 
 使用 `kubectl logs` 命令来查看 DNS 容器的日志信息。
 
@@ -224,7 +224,7 @@ See if there are any suspicious or unexpected messages in the logs.
 
 Verify that the DNS service is up by using the `kubectl get service` command.
 -->
-### 检查是否启用了 DNS 服务
+### 检查是否启用了 DNS 服务   {#is-dns-service-up}
 
 使用 `kubectl get service` 命令来检查 DNS 服务是否已经启用。
 
@@ -263,13 +263,14 @@ more information.
 You can verify that DNS endpoints are exposed by using the `kubectl get endpoints`
 command.
 -->
-### DNS 的末端公开了吗？
+### DNS 的端点公开了吗？    {#are-dns-endpoints-exposed}
 
-你可以使用 `kubectl get endpoints` 命令来验证 DNS 的末端是否公开了。
+你可以使用 `kubectl get endpoints` 命令来验证 DNS 的端点是否公开了。
 
 ```shell
 kubectl get ep kube-dns --namespace=kube-system
 ```
+
 ```
 NAME       ENDPOINTS                       AGE
 kube-dns   10.180.3.17:53,10.180.3.17:53    1h
@@ -283,8 +284,8 @@ For additional Kubernetes DNS examples, see the
 [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
 in the Kubernetes GitHub repository.
 -->
-如果你没看到对应的末端，请阅读
-[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)的末端部分。
+如果你没看到对应的端点，请阅读
+[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)的端点部分。
 
 若需要了解更多的 Kubernetes DNS 例子，请在 Kubernetes GitHub 仓库里查看
 [cluster-dns 示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 
@@ -295,12 +296,12 @@ in the Kubernetes GitHub repository.
 You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile).
 The CoreDNS Corefile is held in a ConfigMap named `coredns`. To edit it, use the command ...
 -->
-### DNS 查询有被接收或者执行吗？
+### DNS 查询有被接收或者执行吗？   {#are-dns-queries-bing-received-processed}
 
 你可以通过给 CoreDNS 的配置文件（也叫 Corefile）添加 `log` 插件来检查查询是否被正确接收。
 CoreDNS 的 Corefile 被保存在一个叫 `coredns` 的 ConfigMap 里，使用下列命令来编辑它：
 
-```
+```shell
 kubectl -n kube-system edit configmap coredns
 ```
 
@@ -309,7 +310,7 @@ Then add `log` in the Corefile section per the example below.
 -->
 然后按下面的例子给 Corefile 添加 `log`。
 
-```
+```yaml
 apiVersion: v1
 kind: ConfigMap
 metadata:
diff --git a/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 048c49028c..b9face566f 100644
--- a/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -252,7 +252,7 @@ The idea is that when a cluster is using nodes that have many cores,
 cores, `nodesPerReplica` dominates.
 
 There are other supported scaling patterns. For details, see
-[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
+[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
 -->
 注意 `coresPerReplica` 和 `nodesPerReplica` 的值都是整数。
 
@@ -260,7 +260,7 @@ There are other supported scaling patterns. For details, see
 当一个集群使用具有较少核心的节点时，由 `nodesPerReplica` 来控制。
 
 其它的扩缩模式也是支持的，详情查看
-[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。
+[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)。
 
 <!--
 ## Disable DNS horizontal autoscaling
@@ -409,9 +409,9 @@ patterns: *linear* and *ladder*.
 <!--
 * Read about [Guaranteed Scheduling For Critical Add-On Pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
 * Learn more about the
-[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
+[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
 
 -->
 * 阅读[为关键插件 Pod 提供的调度保障](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)
-* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)
+* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)
 
diff --git a/content/zh/docs/tasks/administer-cluster/enable-disable-api.md b/content/zh/docs/tasks/administer-cluster/enable-disable-api.md
new file mode 100644
index 0000000000..5e2fc48059
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/enable-disable-api.md
@@ -0,0 +1,61 @@
+---
+title: 启用/禁用 Kubernetes API
+content_type: task
+---
+<!-- 
+---
+title: Enable Or Disable A Kubernetes API
+content_type: task
+---
+-->
+
+<!-- overview -->
+<!-- 
+This page shows how to enable or disable an API version from your cluster's
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+-->
+本页展示怎么用集群的
+{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}.
+启用/禁用 API 版本。
+
+<!-- steps -->
+
+
+<!-- 
+Specific API versions can be turned on or off by passing `--runtime-config=api/<version>` as a
+command line argument to the API server. The values for this argument are a comma-separated
+list of API versions. Later values override earlier values.
+
+The `runtime-config` command line argument also supports 2 special keys:
+-->
+通过 API 服务器的命令行参数 `--runtime-config=api/<version>` ，
+可以开启/关闭某个指定的 API 版本。
+此参数的值是一个逗号分隔的 API 版本列表。
+此列表中，后面的值可以覆盖前面的值。
+
+命令行参数 `runtime-config` 支持两个特殊的值（keys）：
+
+<!-- 
+- `api/all`, representing all known APIs
+- `api/legacy`, representing only legacy APIs. Legacy APIs are any APIs that have been
+   explicitly [deprecated](/zh/docs/reference/using-api/deprecation-policy/).
+
+For example, to turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`
+to the `kube-apiserver`.
+-->
+- `api/all`：指所有已知的 API
+- `api/legacy`：指过时的 API。过时的 API 就是明确地
+  [弃用](/zh/docs/reference/using-api/deprecation-policy/)
+  的 API。
+
+例如：为了停用除去 v1 版本之外的全部其他 API 版本，
+就用参数 `--runtime-config=api/all=false,api/v1=true` 启动 `kube-apiserver`。
+
+## {{% heading "whatsnext" %}}
+
+<!-- 
+Read the [full documentation](/docs/reference/command-line-tools-reference/kube-apiserver/)
+for the `kube-apiserver` component.
+-->
+阅读[完整的文档](/zh/docs/reference/command-line-tools-reference/kube-apiserver/),
+以了解 `kube-apiserver` 组件。
\ No newline at end of file
diff --git a/content/zh/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/zh/docs/tasks/administer-cluster/enabling-endpointslices.md
index 4e6bd67307..cf36557dd6 100644
--- a/content/zh/docs/tasks/administer-cluster/enabling-endpointslices.md
+++ b/content/zh/docs/tasks/administer-cluster/enabling-endpointslices.md
@@ -1,110 +1,130 @@
 ---
 reviewers:
-- bowei
-- freehan
-title: 启用端点切片
+title: 启用 EndpointSlices
 content_type: task
 ---
 
 <!--
----
 reviewers:
 - bowei
 - freehan
-title: Enabling Endpoint Slices
+title: Enabling EndpointSlices
 content_type: task
----
 -->
 
 <!-- overview -->
 
 <!--
-This page provides an overview of enabling Endpoint Slices in Kubernetes.
+This page provides an overview of enabling EndpointSlices in Kubernetes.
 -->
-本页提供启用 Kubernetes 端点切片的总览
-
-
-
+本页提供启用 Kubernetes EndpointSlice 的总览。
 
 ## {{% heading "prerequisites" %}}
 
-
-  {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 <!-- steps -->
 
 <!--
 ## Introduction
 
-Endpoint Slices provide a scalable and extensible alternative to Endpoints in
+EndpointSlices provide a scalable and extensible alternative to Endpoints in
 Kubernetes. They build on top of the base of functionality provided by Endpoints
 and extend that in a scalable way. When Services have a large number (>100) of
-network endpoints, they will be split into multiple smaller Endpoint Slice
+network endpoints, they will be split into multiple smaller EndpointSlice
 resources instead of a single large Endpoints resource.
 -->
 ## 介绍
 
-端点切片为 Kubernetes 端点提供了可伸缩和可扩展的替代方案。它们建立在端点提供的功能基础之上，并以可伸缩的方式进行扩展。当服务具有大量（>100）网络端点，
-它们将被分成多个较小的端点切片资源，而不是单个大型端点资源。
+EndpointSlice （端点切片）为 Kubernetes Endpoints 提供了可伸缩和可扩展的替代方案。
+它们建立在 Endpoints 提供的功能基础之上，并以可伸缩的方式进行扩展。
+当 Service 具有大量（>100）网络端点时，它们将被分成多个较小的 EndpointSlice 资源，
+而不是单个大型 Endpoints 资源。
 
 <!--
-## Enabling Endpoint Slices
+## Enabling EndpointSlices
 -->
-## 启用端点切片
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+## 启用 EndpointSlice
 
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 {{< note >}}
 <!--
-Although Endpoint Slices may eventually replace Endpoints, many Kubernetes
-components still rely on Endpoints. For now, enabling Endpoint Slices should be
+Although EndpointSlices may eventually replace Endpoints, many Kubernetes
+components still rely on Endpoints. For now, enabling EndpointSlices should be
 seen as an addition to Endpoints in a cluster, not a replacement for them.
 -->
-
-尽管端点切片最终可能会取代端点，但许多 Kubernetes 组件仍然依赖于端点。目前，启用端点切片应该被视为集群中端点的补充，而不是它们的替代。
-
+尽管 EndpointSlice 最终可能会取代 Endpoints，但许多 Kubernetes 组件仍然依赖于
+Endpoints。目前，启用 EndpointSlice 应该被视为集群中 Endpoints 的补充，而不是
+替代它们。
 {{< /note >}}
 
 <!--
-As an alpha feature, Endpoint Slices are not enabled by default in Kubernetes.
-Enabling Endpoint Slices requires as many as 3 changes to Kubernetes cluster
-configuration.
-
-To enable the Discovery API group that includes Endpoint Slices, use the runtime
- config flag (`--runtime-config=discovery.k8s.io/v1alpha1=true`).
-
-The logic responsible for watching services, pods, and nodes and creating or
-updating associated Endpoint Slices lives within the EndpointSlice controller.
-This is disabled by default but can be enabled with the controllers flag on
-kube-controller-manager (`--controllers=endpointslice`).
-
-For Kubernetes components like kube-proxy to actually start using Endpoint
-Slices, the EndpointSlice feature gate will need to be enabled
-(`--feature-gates=EndpointSlice=true`).
+EndpointSlice functionality in Kubernetes is made up of several different
+components, most are enabled by default:
 -->
+Kubernetes 中的 EndpointSlice 功能包含若干不同组件。它们中的大部分都是
+默认被启用的：
 
-作为 Alpha 功能，默认情况下，Kubernetes 中未启用端点切片。启用端点切片需要对 Kubernetes 集群进行多达 3 项配置修改。
+<!--
+* _The EndpointSlice API_: EndpointSlices are part of the
+  `discovery.k8s.io/v1beta1` API. This is beta and enabled by default since
+  Kubernetes 1.17. All components listed below are dependent on this API being
+  enabled.
+* _The EndpointSlice Controller_: This {{< glossary_tooltip text="controller"
+  term_id="controller" >}} maintains EndpointSlices for Services and the Pods
+  they reference. This is controlled by the `EndpointSlice` feature gate. It has
+  been enabled by default since Kubernetes 1.18.
+-->
+* _EndpointSlice API_：EndpointSlice 隶属于 `discovery.k8s.io/v1beta1` API。
+  此 API 处于 Beta 阶段，从 Kubernetes 1.17 开始默认被启用。
+  下面列举的所有组件都依赖于此 API 被启用。
+* _EndpointSlice 控制器_：此 {{< glossary_tooltip text="控制器" term_id="controller" >}}
+  为 Service  维护 EndpointSlice 及其引用的 Pods。
+  此控制器通过 `EndpointSlice` 特性门控控制。自从 Kubernetes 1.18 起，
+  该特性门控默认被启用。
 
-要启用包括端点切片的 Discovery API 组，请使用运行时配置标志（`--runtime-config=discovery.k8s.io/v1alpha1=true`）。
-
-该逻辑负责监视服务，pod 和节点以及创建或更新与之关联，在端点切片控制器内的端点切片。
-默认情况下，此功能处于禁用状态，但可以通过启用在 kube-controller-manager 控制器的标志（`--controllers=endpointslice`）来开启。
-
-对于像 kube-proxy 这样的 Kubernetes 组件真正开始使用端点切片，需要开启端点切片功能标志（`--feature-gates=EndpointSlice=true`）。
+<!--
+* _The EndpointSliceMirroring Controller_: This {{< glossary_tooltip
+  text="controller" term_id="controller" >}} mirrors custom Endpoints to
+  EndpointSlices. This is controlled by the `EndpointSlice` feature gate. It has
+  been enabled by default since Kubernetes 1.19.
+* _Kube-Proxy_: When {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy">}}
+  is configured to use EndpointSlices, it can support higher numbers of Service
+  endpoints. This is controlled by the `EndpointSliceProxying` feature gate on
+  Linux and `WindowsEndpointSliceProxying` on Windows. It has been enabled by
+  default on Linux since Kubernetes 1.19. It is not enabled by default for
+  Windows nodes. To configure kube-proxy to use EndpointSlices on Windows, you
+  can enable the `WindowsEndpointSliceProxying` [feature
+  gate](/docs/reference/command-line-tools-reference/feature-gates/) on
+  kube-proxy.
+-->
+* _EndpointSliceMirroring 控制器_：此 {{< glossary_tooltip text="控制器" term_id="controller" >}}
+  将自定义的 Endpoints 映射为 EndpointSlice。
+  控制器受 `EndpointSlice` 特性门控控制。该特性门控自 1.19 开始被默认启用。
+* _kube-proxy_：当 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy">}}
+  被配置为使用 EndpointSlice 时，它会支持更大数量的 Service 端点。
+  此功能在 Linux 上受 `EndpointSliceProxying` 特性门控控制；在 Windows 上受
+  `WindowsEndpointSliceProxying` 特性门控控制。
+  在 Linux 上，从 Kubernetes 1.19 版本起自动启用。目前尚未在 Windows 节点
+  上默认启用。
+  要在 Windows 节点上配置 kube-proxy 使用 EndpointSlice，你需要为 kube-proxy 启用
+  `WindowsEndpointSliceProxying`
+  [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
 
 <!--
 ## Using Endpoint Slices
 
-With Endpoint Slices fully enabled in your cluster, you should see corresponding
+With EndpointSlices fully enabled in your cluster, you should see corresponding
 EndpointSlice resources for each Endpoints resource. In addition to supporting
-existing Endpoints functionality, Endpoint Slices should include new bits of
-information such as topology. They will allow for greater scalability and
-extensibility of network endpoints in your cluster.
+existing Endpoints functionality, EndpointSlices include new bits of information
+such as topology. They will allow for greater scalability and extensibility of
+network endpoints in your cluster.
 -->
+## 使用 EndpointSlice
 
-## 使用端点切片
+在集群中完全启用 EndpointSlice 的情况下，你应该看到对应于每个
+Endpoints 资源的 EndpointSlice 资源。除了支持现有的 Endpoints 功能外，
+EndpointSlice 还引入了拓扑结构等新的信息。它们将使集群中网络端点具有更强的
+可伸缩性和可扩展性。
 
-在集群中完全启用端点切片的情况下，您应该看到对应的每个端点资源的端点切片资源。除了兼容现有的端点功能，端点切片应包括拓扑等新的信息。它们将使集群中网络端点具有更强的可伸缩性，可扩展性。
\ No newline at end of file
diff --git a/content/zh/docs/tasks/administer-cluster/enabling-service-topology.md b/content/zh/docs/tasks/administer-cluster/enabling-service-topology.md
new file mode 100644
index 0000000000..d97171de3e
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/enabling-service-topology.md
@@ -0,0 +1,76 @@
+---
+title: 开启服务拓扑
+content_type: task
+---
+
+<!-- overview -->
+<!--
+This page provides an overview of enabling Service Topology in Kubernetes.
+-->
+本页面提供了在 Kubernetes 中启用服务拓扑的概述。
+
+## {{% heading "prerequisites" %}}
+
+  {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+<!-- steps -->
+<!--
+## Introduction
+
+_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.
+-->
+## 介绍
+
+_服务拓扑（Service Topology）_ 使服务能够根据集群中的 Node 拓扑来路由流量。
+比如，服务可以指定将流量优先路由到与客户端位于同一节点或者同一可用区域的端点上。
+
+<!--
+## Prerequisites
+
+The following prerequisites are needed in order to enable topology aware service
+routing:
+
+   * Kubernetes 1.17 or later
+   * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}} running in iptables mode or IPVS mode
+   * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
+-->
+## 先决条件
+
+需要下面列的先决条件，才能启用拓扑感知的服务路由：
+
+   * Kubernetes 1.17 或更新版本
+   * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}} 以 iptables 或者 IPVS 模式运行
+   * 启用[端点切片](/zh/docs/concepts/services-networking/endpoint-slices/)
+
+<!--
+## Enable Service Topology
+
+{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+
+To enable service topology, enable the `ServiceTopology` and `EndpointSlice` feature gate for all Kubernetes components:
+-->
+## 启用服务拓扑
+
+{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+
+要启用服务拓扑功能，需要为所有 Kubernetes 组件启用 `ServiceTopology` 和 `EndpointSlice` 特性门控：
+
+```
+--feature-gates="ServiceTopology=true,EndpointSlice=true"
+```
+
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Read about the [Service Topology](/docs/concepts/services-networking/service-topology) concept
+* Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices)
+* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
+-->
+* 阅读[服务拓扑](/zh/docs/concepts/services-networking/service-topology)概念
+* 阅读[端点切片](/zh/docs/concepts/services-networking/endpoint-slices)
+* 阅读[通过服务来连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
\ No newline at end of file
diff --git a/content/zh/docs/tasks/administer-cluster/encrypt-data.md b/content/zh/docs/tasks/administer-cluster/encrypt-data.md
index 65e7689406..6a645eb2ec 100644
--- a/content/zh/docs/tasks/administer-cluster/encrypt-data.md
+++ b/content/zh/docs/tasks/administer-cluster/encrypt-data.md
@@ -206,7 +206,7 @@ To create a new secret perform the following steps:
 {{< caution >}}
 你的配置文件包含可以解密 etcd 内容的密钥，因此你必须正确限制主控节点的访问权限，
 以便只有能运行 kube-apiserver 的用户才能读取它。
-{{< caution >}}
+{{< /caution >}}
 
 <!--
 ## Verifying that data is encrypted
@@ -232,9 +232,8 @@ program to retrieve the contents of your secret.
 2. Using the etcdctl commandline, read that secret out of etcd:
 -->
 2. 使用 etcdctl 命令行，从 etcd 中读取 secret：
-
    ```shell
-   ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
+   ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
    ```
 
    <!--
diff --git a/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md b/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md
index e6c126ea1e..e4d8bc8297 100644
--- a/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md
+++ b/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md
@@ -26,7 +26,10 @@ This page shows how to configure and enable the ip-masq-agent.
 <!--
 The ip-masq-agent configures iptables rules to hide a pod's IP address behind the cluster node's IP address. This is typically done when sending traffic to destinations outside the cluster's pod [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) range.
 -->
-ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面的 pod 的 IP 地址。 这通常在将流量发送到集群的 pod [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1) 范围之外的目的地时使用。
+ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面的 Pod 的 IP 地址。
+这通常在将流量发送到集群的 Pod
+[CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1)
+范围之外的目的地时使用。
 
 <!--
 ### **Key Terms**
@@ -34,47 +37,56 @@ ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面
 ### **关键术语**
 
 <!--
-*   **NAT (Network Address Translation)**
-    Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header.  Typically performed by a device doing IP routing.
+* **NAT (Network Address Translation)**
+  Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header.  Typically performed by a device doing IP routing.
 -->
-*   **NAT (网络地址解析)**
-    是一种通过修改 IP 地址头中的源和/或目标地址信息将一个 IP 地址重新映射到另一个 IP 地址的方法。通常由执行 IP 路由的设备执行。
+* **NAT (网络地址转译)**
+  是一种通过修改 IP 地址头中的源和/或目标地址信息将一个 IP 地址重新映射
+  到另一个 IP 地址的方法。通常由执行 IP 路由的设备执行。
 
 <!--
-*   **Masquerading**
-    A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
+* **Masquerading**
+  A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
 -->    
-*   **伪装**
-    NAT 的一种形式，通常用于执行多对一地址转换，其中多个源 IP 地址被隐藏在单个地址后面，该地址通常是执行 IP 路由的设备。在 Kubernetes 中，这是节点的 IP 地址。
+* **伪装**
+  NAT 的一种形式，通常用于执行多对一地址转换，其中多个源 IP 地址被隐藏在
+  单个地址后面，该地址通常是执行 IP 路由的设备。在 Kubernetes 中，
+  这是节点的 IP 地址。
 
 <!--
-*   **CIDR (Classless Inter-Domain Routing)**
-    Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
+* **CIDR (Classless Inter-Domain Routing)**
+  Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
 -->
-*   **CIDR (无类别域间路由)**
-    基于可变长度子网掩码，允许指定任意长度的前缀。CIDR 引入了一种新的 IP 地址表示方法，现在通常称为**CIDR表示法**，其中地址或路由前缀后添加一个后缀，用来表示前缀的位数，例如 192.168.2.0/24。
+* **CIDR (无类别域间路由)**
+  基于可变长度子网掩码，允许指定任意长度的前缀。
+  CIDR 引入了一种新的 IP 地址表示方法，现在通常称为**CIDR表示法**，
+  其中地址或路由前缀后添加一个后缀，用来表示前缀的位数，例如 192.168.2.0/24。
 
 <!--
-*   **Link Local**
-    A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
+* **Link Local**
+  A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
 -->
-*   **本地链路**
-    本地链路是仅对网段或主机所连接的广播域内的通信有效的网络地址。IPv4的本地链路地址在 CIDR 表示法的地址块 169.254.0.0/16 中定义。
+* **本地链路**
+  本地链路是仅对网段或主机所连接的广播域内的通信有效的网络地址。
+  IPv4 的本地链路地址在 CIDR 表示法的地址块 169.254.0.0/16 中定义。
 
 <!--
 The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range.  This essentially hides pod IP addresses behind the cluster node's IP address.  In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP.  When containers are used, as in Google Kubernetes Engine, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).  These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default.  The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.
 -->
 ip-masq-agent 配置 iptables 规则，以便在将流量发送到集群节点的 IP 和集群 IP 范围之外的目标时
-处理伪装节点/Pod 的 IP 地址。这基本上隐藏了集群节点 IP 地址后面的 Pod IP 地址。
+处理伪装节点或 Pod 的 IP 地址。这本质上隐藏了集群节点 IP 地址后面的 Pod IP 地址。
 在某些环境中，去往“外部”地址的流量必须从已知的机器地址发出。
 例如，在 Google Cloud 中，任何到互联网的流量都必须来自 VM 的 IP。
 使用容器时，如 Google Kubernetes Engine，从 Pod IP 发出的流量将被拒绝出站。
 为了避免这种情况，我们必须将 Pod IP 隐藏在 VM 自己的 IP 地址后面 - 通常称为“伪装”。
-默认情况下，代理配置为将[RFC 1918](https://tools.ietf.org/html/rfc1918)指定的三个私有
-IP 范围视为非伪装 [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1)。
+默认情况下，代理配置为将
+[RFC 1918](https://tools.ietf.org/html/rfc1918)
+指定的三个私有 IP 范围视为非伪装
+[CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1)。
 这些范围是 10.0.0.0/8,172.16.0.0/12 和 192.168.0.0/16。
 默认情况下，代理还将链路本地地址（169.254.0.0/16）视为非伪装 CIDR。
-代理程序配置为每隔 60 秒从 */etc/config/ip-masq-agent* 重新加载其配置，这也是可修改的。
+代理程序配置为每隔 60 秒从 */etc/config/ip-masq-agent* 重新加载其配置，
+这也是可修改的。
 
 ![masq/non-masq example](/images/docs/ip-masq.png)
 
@@ -86,17 +98,21 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
 <!--
 *   **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
 -->
-*   **nonMasqueradeCIDRs:** [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1) 表示法中的字符串列表，用于指定不需伪装的地址范围。
+* **nonMasqueradeCIDRs:**
+  [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1)
+  表示法中的字符串列表，用于指定不需伪装的地址范围。
 
 <!--
 *   **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
 -->
-*   **masqLinkLocal:** 布尔值 (true / false)，表示是否将流量伪装到本地链路前缀 169.254.0.0/16。默认为 false。
+* **masqLinkLocal:** 布尔值 (true / false)，表示是否将流量伪装到
+  本地链路前缀 169.254.0.0/16。默认为 false。
 
 <!--
 *   **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
 -->
-*   **resyncInterval:** 代理尝试从磁盘重新加载配置的时间间隔。 例如 '30s'，其中 's' 是秒，'ms' 是毫秒等...
+* **resyncInterval:** 代理尝试从磁盘重新加载配置的时间间隔。
+  例如 '30s'，其中 's' 是秒，'ms' 是毫秒等...
 
 <!--
 Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded.  An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range.   Any other traffic will be masqueraded by default.  The below entries show the default set of rules that are applied by the ip-masq-agent:
@@ -106,7 +122,6 @@ Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masq
 Pod 访问本地目的地的例子，可以是其节点的 IP 地址、另一节点的地址或集群的 IP 地址范围内的一个 IP 地址。
 默认情况下，任何其他流量都将伪装。以下条目展示了 ip-masq-agent 的默认使用的规则：
 
-<!--
 ```
 iptables -t nat -L IP-MASQ-AGENT
 RETURN     all  --  anywhere             169.254.0.0/16       /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
@@ -115,16 +130,6 @@ RETURN     all  --  anywhere             172.16.0.0/12        /* ip-masq-agent:
 RETURN     all  --  anywhere             192.168.0.0/16       /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
 MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent: outbound traffic should be subject to MASQUERADE (this match must come after cluster-local CIDR matches) */ ADDRTYPE match dst-type !LOCAL
 
-```
--->
-```
-iptables -t nat -L IP-MASQ-AGENT
-RETURN     all  --  anywhere             169.254.0.0/16       /* ip-masq-agent: 集群本地流量不被 MASQUERADE 控制 */ ADDRTYPE match dst-type !LOCAL
-RETURN     all  --  anywhere             10.0.0.0/8           /* ip-masq-agent: 集群本地流量不被 MASQUERADE 控制 */ ADDRTYPE match dst-type !LOCAL
-RETURN     all  --  anywhere             172.16.0.0/12        /* ip-masq-agent: 集群本地流量不被 MASQUERADE 控制 */ ADDRTYPE match dst-type !LOCAL
-RETURN     all  --  anywhere             192.168.0.0/16       /* ip-masq-agent: 集群本地流量不被 MASQUERADE 控制 */ ADDRTYPE match dst-type !LOCAL
-MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent: 出站流量应受 MASQUERADE 控制 (此规则必须在集群本地 CIDR 规则之后) */ ADDRTYPE match dst-type !LOCAL
-
 ```
 
 <!--
@@ -143,25 +148,26 @@ By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7
 To create an ip-masq-agent, run the following kubectl command:
 -->
 ## 创建 ip-masq-agent
+
 通过运行以下 kubectl 指令创建 ip-masq-agent:
 
-`
-kubectl apply -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml
-`
+```shell
+kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/ip-masq-agent/master/ip-masq-agent.yaml
+```
 
 <!--
 You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
 -->
 你必须同时将适当的节点标签应用于集群中希望代理运行的任何节点。
 
-`
+```shell
 kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
-`
+```
 
 <!--
-More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)
+More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-sigs/ip-masq-agent)
 -->
-更多信息可以通过 ip-masq-agent 文档 [这里](https://github.com/kubernetes-incubator/ip-masq-agent) 找到
+更多信息可以通过 ip-masq-agent 文档 [这里](https://github.com/kubernetes-sigs/ip-masq-agent) 找到。
 
 <!--
 In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to customize the IP ranges that are affected.  For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) in a file called "config".
@@ -169,14 +175,15 @@ In most cases, the default set of rules should be sufficient; however, if this i
 在大多数情况下，默认的规则集应该足够；但是，如果你的群集不是这种情况，则可以创建并应用
 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
 来自定义受影响的 IP 范围。
-例如，要允许 ip-masq-agent 仅作用于 10.0.0.0/8，你可以一个名为 “config” 的文件中创建以下
+例如，要允许 ip-masq-agent 仅作用于 10.0.0.0/8，你可以在一个名为 “config” 的文件中创建以下
 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 。
 
 {{< note >}}
 <!--
 It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
 -->
-重要的是，该文件之所以被称为 config，因为默认情况下，该文件将被用作 ip-masq-agent 查找的关键：
+重要的是，该文件之所以被称为 config，因为默认情况下，该文件将被用作
+ip-masq-agent 查找的主键：
 
 ```
 nonMasqueradeCIDRs:
@@ -202,7 +209,6 @@ After the resync interval has expired, you should see the iptables rules reflect
 为周期定期检查并应用于集群节点。
 重新同步间隔到期后，你应该看到你的更改在 iptables 规则中体现：
 
-<!--
 ```
 iptables -t nat -L IP-MASQ-AGENT
 Chain IP-MASQ-AGENT (1 references)
@@ -211,20 +217,13 @@ RETURN     all  --  anywhere             169.254.0.0/16       /* ip-masq-agent:
 RETURN     all  --  anywhere             10.0.0.0/8           /* ip-masq-agent: cluster-local
 MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent: outbound traffic should be subject to MASQUERADE (this match must come after cluster-local CIDR matches) */ ADDRTYPE match dst-type !LOCAL
 ```
--->
-```
-iptables -t nat -L IP-MASQ-AGENT
-Chain IP-MASQ-AGENT (1 references)
-target     prot opt source               destination
-RETURN     all  --  anywhere             169.254.0.0/16       /* ip-masq-agent: 集群本地流量不被 MASQUERADE 控制 */ ADDRTYPE match dst-type !LOCAL
-RETURN     all  --  anywhere             10.0.0.0/8           /* ip-masq-agent: cluster-local
-MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent: 出站流量应受 MASQUERADE 控制 (此规则必须在集群本地 CIDR 规则之后) */ ADDRTYPE match dst-type !LOCAL
-```
 
 <!--
 By default, the link local range (169.254.0.0/16) is also handled by the ip-masq agent, which sets up the appropriate iptables rules.  To have the ip-masq-agent ignore link local, you can set *masqLinkLocal*  to true in the config map.
 -->
-默认情况下，本地链路范围 (169.254.0.0/16) 也由 ip-masq agent 处理，该代理设置适当的 iptables 规则。 要使 ip-masq-agent 忽略本地链路，可以在配置映射中将 *masqLinkLocal* 设置为true。
+默认情况下，本地链路范围 (169.254.0.0/16) 也由 ip-masq agent 处理，
+该代理设置适当的 iptables 规则。 要使 ip-masq-agent 忽略本地链路，
+可以在配置映射中将 *masqLinkLocal* 设置为 true。
 
 ```
 nonMasqueradeCIDRs:
diff --git a/content/zh/docs/tasks/administer-cluster/kms-provider.md b/content/zh/docs/tasks/administer-cluster/kms-provider.md
index f456f639f3..0c103543a0 100644
--- a/content/zh/docs/tasks/administer-cluster/kms-provider.md
+++ b/content/zh/docs/tasks/administer-cluster/kms-provider.md
@@ -1,284 +1,347 @@
 ---
-reviewers:
-- smarterclayton
-title: 使用 KMS 提供商进行数据加密
+title: 使用 KMS 驱动进行数据加密
 content_type: task
 ---
-<!-- ---
+<!--
 reviewers:
 - smarterclayton
 title: Using a KMS provider for data encryption
 content_type: task
---- -->
+-->
 <!-- overview -->
 <!-- This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption. -->
 
-本页展示了如何配置秘钥管理服务—— Key Management Service (KMS) 提供商和插件以启用数据加密。
-
-
+本页展示了如何配置秘钥管理服务—— Key Management Service (KMS) 驱动和插件以启用
+Secret 数据加密。
 
 ## {{% heading "prerequisites" %}}
 
-
 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 <!-- * Kubernetes version 1.10.0 or later is required -->
-
-* 需要 Kubernetes 1.10.0 或更新版本
-
 <!-- * etcd v3 or later is required -->
-
+* 需要 Kubernetes 1.10.0 或更新版本
 * 需要 etcd v3 或更新版本
 
 {{< feature-state for_k8s_version="v1.12" state="beta" >}}
 
-
-
 <!-- steps -->
 
-<!-- The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS 
-plugin. The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) as the Kubernetes master(s), is responsible for all communication with the remote KMS. -->
+<!--
+The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS 
+plugin. The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) as the Kubernetes master(s), is responsible for all communication with the remote KMS.
+-->
+KMS 加密驱动使用封套加密模型来加密 etcd 中的数据。
+数据使用数据加密秘钥（DEK）加密；每次加密都生成一个新的 DEK。
+这些 DEK 经一个秘钥加密秘钥（KEK）加密后在一个远端的 KMS 中存储和管理。
+KMS 驱动使用 gRPC 与一个特定的 KMS 插件通信。这个 KMS 插件作为一个 gRPC 
+服务器被部署在 Kubernetes 主服务器的同一个主机上，负责与远端 KMS 的通信。
 
-KMS 加密提供商使用封套加密模型来加密 etcd 中的数据。数据使用数据加密秘钥（DEK）加密；每次加密都生成一个新的 DEK。这些 DEK 经一个秘钥加密秘钥（KEK）加密后在一个远端的 KMS 中存储和管理。KMS 提供商使用 gRPC 与一个特定的 KMS 插件通信。这个 KMS 插件作为一个 gRPC 服务器被部署在 Kubernetes 主服务器的同一个主机上，负责与远端 KMS 的通信。
+<!--
+## Configuring the KMS provider
 
-<!-- ## Configuring the KMS provider -->
+To configure a KMS provider on the API server, include a provider of type ```kms``` in the providers array in the encryption configuration file and set the following properties:
+-->
+## 配置 KMS 驱动
 
-## 配置 KMS 提供商
+为了在 API 服务器上配置 KMS 驱动，在加密配置文件中的驱动数组中加入一个类型为 `kms`
+的驱动，并设置下列属性：
 
-<!-- To configure a KMS provider on the API server, include a provider of type ```kms``` in the providers array in the encryption configuration file and set the following properties: -->
+<!--
+* `name`: Display name of the KMS plugin.
+* `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
+* `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap.
+* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds).
+-->
 
-为了在 API 服务器上配置 KMS 提供商，在加密配置文件中的提供商数组中加入一个类型为 ```kms``` 的提供商，并设置下列属性：
-
-<!--   * `name`: Display name of the KMS plugin.
-  * `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket.
-  * `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap.
-  * `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds). -->
-
-  * `name`: KMS 插件的显示名称。
-  * `endpoint`: gRPC 服务器（KMS 插件）的监听地址。该端点是一个 UNIX 的套接字。
-  * `cachesize`: 以明文缓存的数据加密秘钥（DEKs）的数量。一旦被缓存，就可以直接使用 DEKs 而无需另外调用 KMS；而未被缓存的 DEKs 需要调用一次 KMS 才能解包。
-  * `timeout`: 在返回一个错误之前，kube-apiserver 等待 kms-plugin 响应的时间（默认是 3 秒）。
+* `name`: KMS 插件的显示名称。
+* `endpoint`: gRPC 服务器（KMS 插件）的监听地址。该端点是一个 UNIX 域套接字。
+* `cachesize`: 以明文缓存的数据加密秘钥（DEKs）的数量。一旦被缓存，
+  就可以直接使用 DEKs 而无需另外调用 KMS；而未被缓存的 DEKs 需要调用一次 KMS 才能解包。
+* `timeout`: 在返回一个错误之前，kube-apiserver 等待 kms-plugin 响应的时间（默认是 3 秒）。
 
 <!-- See [Understanding the encryption at rest configuration.](/docs/tasks/administer-cluster/encrypt-data) -->
+参见[理解静态数据加密配置](/zh/docs/tasks/administer-cluster/encrypt-data)
 
-参见 [理解静态数据加密配置](/docs/tasks/administer-cluster/encrypt-data)
-
-<!-- ## Implementing a KMS plugin -->
+<!--
+## Implementing a KMS plugin
 
+To implement a KMS plugin, you can develop a new plugin gRPC server or enable a KMS plugin already provided by your cloud provider. You then integrate the plugin with the remote KMS and deploy it on the Kubernetes master.
+-->
 ## 实现 KMS 插件
 
-<!-- To implement a KMS plugin, you can develop a new plugin gRPC server or enable a KMS plugin already provided by your cloud provider. You then integrate the plugin with the remote KMS and deploy it on the Kubernetes master. -->
+为实现一个 KMS 插件，你可以开发一个新的插件 gRPC 服务器或启用一个由你的云服务驱动提供的 KMS 插件。
+你可以将这个插件与远程 KMS 集成，并把它部署到 Kubernetes 的主服务器上。
 
-为实现一个 KMS 插件，您可以开发一个新的插件 gRPC 服务器或启用一个由您的云服务提供商提供的 KMS 插件。您可以将这个插件与远程 KMS 集成，并把它部署到 Kubernetes 的主服务器上。
+<!--
+### Enabling the KMS supported by your cloud provider 
+Refer to your cloud provider for instructions on enabling the cloud provider-specific KMS plugin.
+-->
+### 启用由云服务驱动支持的 KMS
 
-<!-- ### Enabling the KMS supported by your cloud provider 
-Refer to your cloud provider for instructions on enabling the cloud provider-specific KMS plugin. -->
+有关启用云服务驱动特定的 KMS 插件的说明，请咨询你的云服务驱动。
 
-### 启用由云服务提供商支持的 KMS
-有关启用云服务提供商特定的 KMS 插件的说明，请咨询您的云服务提供商。
-
-<!-- ### Developing a KMS plugin gRPC server
-You can develop a KMS plugin gRPC server using a stub file available for Go. For other languages, you use a proto file to create a stub file that you can use to develop the gRPC server code. -->
+<!--
+### Developing a KMS plugin gRPC server
 
+You can develop a KMS plugin gRPC server using a stub file available for Go. For other languages, you use a proto file to create a stub file that you can use to develop the gRPC server code.
+-->
 ### 开发 KMS 插件 gRPC 服务器
-您可以使用 Go 语言的存根文件开发 KMS 插件 gRPC 服务器。对于其他语言，您可以用 proto 文件创建可以用于开发 gRPC 服务器代码的存根文件。
 
-<!-- * Using Go: Use the functions and data structures in the stub file: [service.pb.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.pb.go) to develop the gRPC server code  -->
+你可以使用 Go 语言的存根文件开发 KMS 插件 gRPC 服务器。
+对于其他语言，你可以用 proto 文件创建可以用于开发 gRPC 服务器代码的存根文件。
 
-* 使用 Go：使用存根文件 [service.pb.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.pb.go) 中的函数和数据结构开发 gRPC 服务器代码。
+<!--
+* Using Go: Use the functions and data structures in the stub file:
+[service.pb.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.pb.go) to develop the gRPC server code
+-->
+* 使用 Go：使用存根文件 [service.pb.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.pb.go)
+  中的函数和数据结构开发 gRPC 服务器代码。
 
-<!-- * Using languages other than Go: Use the protoc compiler with the proto file: [service.proto](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto) to generate a stub file for the specific language -->
-
-* 使用 Go 以外的其他语言：用 protoc 编译器编译 proto 文件： [service.proto](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto) 为指定语言生成存根文件。
-
-<!-- Then use the functions and data structures in the stub file to develop the server code. -->
+<!--
+* Using languages other than Go: Use the protoc compiler with the proto file: [service.proto](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto) to generate a stub file for the specific language
+-->
+* 使用 Go 以外的其他语言：用 protoc 编译器编译 proto 文件：
+  [service.proto](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto)
+  为指定语言生成存根文件。
 
+<!--
+Then use the functions and data structures in the stub file to develop the server code.
+-->
 然后使用存根文件中的函数和数据结构开发服务器代码。
 
 <!-- **Notes:** -->
-
 **注意：**
 
-<!-- * kms plugin version: `v1beta1`
+<!--
+* kms plugin version: `v1beta1`
 
-In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version -->
+  In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version.
 
+* message version: `v1beta1`
+
+  All messages from KMS provider have the version field set to current version v1beta1.
+
+* protocol: UNIX domain socket (`unix`)
+
+  The gRPC server should listen at UNIX domain socket.
+-->
 * kms 插件版本：`v1beta1`
 
-作为对过程调用 Version 的响应，兼容的 KMS 插件应把 v1beta1 作为 VersionResponse.version 返回
-
-<!-- * message version: `v1beta1`
-
-All messages from KMS provider have the version field set to current version v1beta1 -->
+  作为对过程调用 Version 的响应，兼容的 KMS 插件应把 v1beta1 作为 VersionResponse.version 返回
 
 * 消息版本：`v1beta1`
 
-所有来自 KMS 提供商的消息都把 version 字段设置为当前版本 v1beta1
-
-<!-- * protocol: UNIX domain socket (`unix`)
-
-The gRPC server should listen at UNIX domain socket -->
+  所有来自 KMS 驱动的消息都把 version 字段设置为当前版本 v1beta1
 
 * 协议：UNIX 域套接字 (`unix`)
 
-gRPC 服务器应监听 UNIX 域套接字
+  gRPC 服务器应监听 UNIX 域套接字
+
+<!--
+### Integrating a KMS plugin with the remote KMS
 
-<!-- ### Integrating a KMS plugin with the remote KMS
 The KMS plugin can communicate with the remote KMS using any protocol supported by the KMS.
 All configuration data, including authentication credentials the KMS plugin uses to communicate with the remote KMS, 
-are stored and managed by the KMS plugin independently. The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption. -->
-
+are stored and managed by the KMS plugin independently. The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption.
+-->
 ### 将 KMS 插件与远程 KMS 整合
+
 KMS 插件可以用任何受 KMS 支持的协议与远程 KMS 通信。
-所有的配置数据，包括 KMS 插件用于与远程 KMS 通信的认证凭据，都由 KMS 插件独立地存储和管理。KMS 插件可以用额外的元数据对密文进行编码，这些元数据是在把它发往 KMS 进行解密之前可能要用到的。
+所有的配置数据，包括 KMS 插件用于与远程 KMS 通信的认证凭据，都由 KMS 插件独立地存储和管理。
+KMS 插件可以用额外的元数据对密文进行编码，这些元数据是在把它发往 KMS 进行解密之前可能要用到的。
 
-<!-- ### Deploying the KMS plugin 
-Ensure that the KMS plugin runs on the same host(s) as the Kubernetes master(s). -->
+<!--
+### Deploying the KMS plugin 
 
+Ensure that the KMS plugin runs on the same host(s) as the Kubernetes master(s).
+-->
 ### 部署 KMS 插件
+
 确保 KMS 插件与 Kubernetes 主服务器运行在同一主机上。
 
-<!-- ## Encrypting your data with the KMS provider -->
-## 使用 KMS 提供商加密数据
+<!--
+## Encrypting your data with the KMS provider
+
+To encrypt the data:
+-->
+## 使用 KMS 驱动加密数据
 
-<!-- To encrypt the data: -->
 为了加密数据：
 
-<!-- 1. Create a new encryption configuration file using the appropriate properties for the `kms` provider: -->
-1. 使用 `kms` 提供商的相应的属性创建一个新的加密配置文件：
+<!--
+1. Create a new encryption configuration file using the appropriate properties for the `kms` provider:
+-->
+1. 使用 `kms` 驱动的相应的属性创建一个新的加密配置文件：
 
-```yaml
-kind: EncryptionConfiguration
-apiVersion: apiserver.config.k8s.io/v1
-resources:
-  - resources:
-    - secrets
-    providers:
-    - kms:
-        name: myKmsPlugin
-        endpoint: unix:///tmp/socketfile.sock
-        cachesize: 100
-        timeout: 3s
-    - identity: {}
-```
+   ```yaml
+   kind: EncryptionConfiguration
+   apiVersion: apiserver.config.k8s.io/v1
+   resources:
+     - resources:
+       - secrets
+       providers:
+       - kms:
+           name: myKmsPlugin
+           endpoint: unix:///tmp/socketfile.sock
+           cachesize: 100
+           timeout: 3s
+       - identity: {}
+   ```
 
-<!-- 2. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. -->
+<!--
+2. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file.
+3. Restart your API server.
+-->
 2. 设置 kube-apiserver 的 `--encryption-provider-config` 参数指向配置文件的位置。
-<!-- 3. Restart your API server. -->
 3. 重启 API 服务器。
 
-<!-- Note:
-The alpha version of the encryption feature prior to 1.13 required a config file with
-`kind: EncryptionConfig` and `apiVersion: v1`, and used the `--experimental-encryption-provider-config` flag. -->
+<!--
+## Verifying that the data is encrypted
 
-注意：
-在 1.13 之前的加密功能的 alpha 版本需要一个带有 `kind: EncryptionConfig` 和 `apiVersion: v1` 的配置文件，并使用 `--experimental-encryption-provider-config` 标志。
+Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To verify, you can use the etcdctl command line program to retrieve the contents of your secret.
+-->
+## 验证数据已经加密
 
-<!-- ## Verifying that the data is encrypted
-Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To verify, you can use the etcdctl command line program to retrieve the contents of your secret. -->
+写入 etcd 时数据被加密。重启 kube-apiserver 后，任何新建或更新的 Secret 在存储时应该已被加密。
+要验证这点，你可以用 etcdctl 命令行程序获取 Secret 内容。 
 
-## 验证数据是否已加密
-写入 etcd 时数据被加密。重启 kube-apiserver 后，任何新建或更新的秘密信息在存储时应该已被加密。要验证这点，您可以用 etcdctl 命令行程序获取秘密信息内容。 
+<!--
+1. Create a new secret called secret1 in the default namespace:
+-->
+1. 在默认的命名空间里创建一个名为 secret1 的 Secret：
 
-<!-- 1. Create a new secret called secret1 in the default namespace: -->
-1. 在默认的命名空间里创建一个名为 secret1 的秘密信息：
-```
-kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
-```
-<!-- 2. Using the etcdctl command line, read that secret out of etcd: -->
-2. 用 etcdctl 命令行，从 etcd 读取出秘密信息：
-```
-ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
-```
- <!-- where `[...]` must be the additional arguments for connecting to the etcd server. -->
- 其中 `[...]` 是用于连接 etcd 服务器的额外参数。
-<!-- 3. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data. -->
-3. 验证保存的秘密信息是否是以 `k8s:enc:kms:v1:` 开头的，这表明 `kms` 提供商已经对结果数据加密。
-<!-- 4. Verify that the secret is correctly decrypted when retrieved via the API: -->
-4. 验证秘密信息在被 API 获取时已被正确解密：
-```
-kubectl describe secret secret1 -n default
-```
-应该符合 `mykey: mydata` 格式
+   ```
+   kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
+   ```
 
-<!-- ## Ensuring all secrets are encrypted
-Because secrets are encrypted on write, performing an update on a secret encrypts that content. -->
+<!--
+2. Using the etcdctl command line, read that secret out of etcd:
+-->
+2. 用 etcdctl 命令行，从 etcd 读取出 Secret：
 
-## 确保所有秘密信息都已被加密
-因为秘密信息是在写入时被加密的，所以在更新秘密信息时会加密该内容。
+   ```
+   ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
+   ```
 
-<!-- The following command reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. -->
+   <!--
+   where `[...]` must be the additional arguments for connecting to the etcd server.
+   -->
+   其中 `[...]` 是用于连接 etcd 服务器的额外参数。
 
-下列命令读取所有秘密信息并更新他们以便应用服务器端加密。如果因为写入冲突导致错误发生，请重试此命令。对较大的集群，您可能希望根据命名空间或脚本更新去细分秘密内容。
+<!--
+3. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data.
+-->
+3. 验证保存的 Secret 是否是以 `k8s:enc:kms:v1:` 开头的，这表明 `kms` 驱动已经对结果数据加密。
+
+<!--
+4. Verify that the secret is correctly decrypted when retrieved via the API:
+-->
+4. 验证 Secret 在被 API 获取时已被正确解密：
+
+   ```
+   kubectl describe secret secret1 -n default
+   ```
+
+   结果应该是 `mykey: mydata`。 
+
+<!--
+## Ensuring all secrets are encrypted
+
+Because secrets are encrypted on write, performing an update on a secret encrypts that content.
+-->
+## 确保所有 Secret 都已被加密
+
+因为 Secret 是在写入时被加密的，所以在更新 Secret 时也会加密该内容。
+
+<!--
+The following command reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command.
+For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
+-->
+下列命令读取所有 Secret 并更新它们以便应用服务器端加密。如果因为写入冲突导致错误发生，
+请重试此命令。对较大的集群，你可能希望根据命名空间或脚本更新去细分 Secret 内容。
 
 ```
 kubectl get secrets --all-namespaces -o json | kubectl replace -f -
 ```
 
-<!-- ## Switching from a local encryption provider to the KMS provider
-To switch from a local encryption provider to the `kms` provider and re-encrypt all of the secrets: -->
+<!--
+## Switching from a local encryption provider to the KMS provider
 
-## 从本地加密提供商切换到 KMS 提供商
-为了从本地加密提供商切换到 `kms` 提供商并重新加密所有秘密内容：
+To switch from a local encryption provider to the `kms` provider and re-encrypt all of the secrets:
+-->
+## 从本地加密驱动切换到 KMS 驱动
 
-<!-- 1. Add the `kms` provider as the first entry in the configuration file as shown in the following example. -->
-1. 在配置文件中加入 `kms` 提供商作为第一个条目，如下列样例所示
+为了从本地加密驱动切换到 `kms` 驱动并重新加密所有 Secret 内容：
 
-```yaml
-kind: EncryptionConfiguration
-apiVersion: apiserver.config.k8s.io/v1
-resources:
-  - resources:
-    - secrets
-    providers:
-    - kms:
-        name : myKmsPlugin
-        endpoint: unix:///tmp/socketfile.sock
-        cachesize: 100
-    - aescbc:
-         keys:
-         - name: key1
-           secret: <BASE 64 ENCODED SECRET>
-```
-<!-- 2. Restart all kube-apiserver processes. -->
+<!--
+1. Add the `kms` provider as the first entry in the configuration file as shown in the following example.
+-->
+1. 在配置文件中加入 `kms` 驱动作为第一个条目，如下列样例所示
+
+   ```yaml
+   kind: EncryptionConfiguration
+   apiVersion: apiserver.config.k8s.io/v1
+   resources:
+     - resources:
+       - secrets
+       providers:
+       - kms:
+           name : myKmsPlugin
+           endpoint: unix:///tmp/socketfile.sock
+           cachesize: 100
+       - aescbc:
+            keys:
+            - name: key1
+              secret: <BASE 64 ENCODED SECRET>
+   ```
+
+<!--
+2. Restart all kube-apiserver processes.
+3. Run the following command to force all secrets to be re-encrypted using the `kms` provider.
+-->
 2. 重启所有 kube-apiserver 进程。
-<!-- 3. Run the following command to force all secrets to be re-encrypted using the `kms` provider. -->
-3. 运行下列命令使用 `kms` 提供商强制重新加密所有秘密信息。
-```
-kubectl get secrets --all-namespaces -o json| kubectl replace -f -
-```
+3. 运行下列命令使用 `kms` 驱动强制重新加密所有 Secret。
 
-<!-- ## Disabling encryption at rest
-To disable encryption at rest: -->
+   ```
+   kubectl get secrets --all-namespaces -o json| kubectl replace -f -
+   ```
 
+<!--
+## Disabling encryption at rest
+To disable encryption at rest:
+-->
 ## 禁用静态数据加密
+
 要禁用静态数据加密：
 
-<!-- 1. Place the `identity` provider as the first entry in the configuration file:  -->
+<!--
+1. Place the `identity` provider as the first entry in the configuration file:
+-->
+1. 将 `identity` 驱动作为配置文件中的第一个条目： 
 
-1. 将 `identity` 提供商作为配置文件中的第一个条目： 
+   ```yaml
+   kind: EncryptionConfiguration
+   apiVersion: apiserver.config.k8s.io/v1
+   resources:
+     - resources:
+       - secrets
+       providers:
+       - identity: {}
+       - kms:
+           name : myKmsPlugin
+           endpoint: unix:///tmp/socketfile.sock
+           cachesize: 100
+   ```
 
-```yaml
-kind: EncryptionConfiguration
-apiVersion: apiserver.config.k8s.io/v1
-resources:
-  - resources:
-    - secrets
-    providers:
-    - identity: {}
-    - kms:
-        name : myKmsPlugin
-        endpoint: unix:///tmp/socketfile.sock
-        cachesize: 100
-```
-<!-- 2.  Restart all kube-apiserver processes.  -->
+<!--
+2.  Restart all kube-apiserver processes.
+3. Run the following command to force all secrets to be decrypted.
+-->
 2. 重启所有 kube-apiserver 进程。
-<!-- 3. Run the following command to force all secrets to be decrypted. -->
-3. 运行下列命令强制重新加密所有秘密信息。
-```
-kubectl get secrets --all-namespaces -o json | kubectl replace -f -
-```
-
-
+3. 运行下列命令强制重新加密所有 Secret。
 
+   ```
+   kubectl get secrets --all-namespaces -o json | kubectl replace -f -
+   ```
 
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
new file mode 100644
index 0000000000..5e9fc9690e
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -0,0 +1,341 @@
+---
+title: 添加 Windows 节点
+min-kubernetes-server-version: 1.17
+content_type: tutorial
+weight: 30
+---
+<!--
+reviewers:
+- michmike
+- patricklang
+title: Adding Windows nodes
+min-kubernetes-server-version: 1.17
+content_type: tutorial
+weight: 30
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+<!--
+You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
+-->
+你可以使用 Kubernetes 来混合运行 Linux 和 Windows 节点，这样你就可以
+混合使用运行于 Linux 上的 Pod 和运行于 Windows 上的 Pod。
+本页面展示如何将 Windows 节点注册到你的集群。
+
+## {{% heading "prerequisites" %}}
+
+{{< version-check >}}
+
+<!--
+* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
+(or higher) in order to configure the Windows node that hosts Windows containers.
+If you are using VXLAN/Overlay networking you must have also have [KB4489899](https://support.microsoft.com/help/4489899) installed.
+
+* A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)).
+-->
+* 获取 [Windows Server 2019 或更高版本的授权](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
+  以便配置托管 Windows 容器的 Windows 节点。
+  如果你在使用 VXLAN/覆盖（Overlay）联网设施，则你还必须安装 [KB4489899](https://support.microsoft.com/help/4489899)。
+
+* 一个利用 kubeadm 创建的基于 Linux 的 Kubernetes 集群；你能访问该集群的控制面
+  （参见[使用 kubeadm 创建一个单控制面的集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/))。
+
+## {{% heading "objectives" %}}
+
+<!--
+* Register a Windows node to the cluster
+* Configure networking so Pods and Services on Linux and Windows can communicate with each other
+-->
+* 将一个 Windows 节点注册到集群上
+* 配置网络，以便 Linux 和 Windows 上的 Pod 和 Service 之间能够相互通信。
+
+<!-- lessoncontent -->
+
+<!--
+## Getting Started: Adding a Windows Node to Your Cluster
+
+### Networking Configuration
+
+Once you have a Linux-based Kubernetes control-plane node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity.
+-->
+## 开始行动：向你的集群添加一个 Windows 节点
+
+### 联网配置   {#networking-configuration}
+
+一旦你有了一个基于 Linux 的 Kubernetes 控制面节点，你就可以为其选择联网方案。
+出于简单考虑，本指南展示如何使用 VXLAN 模式的 Flannel。
+
+<!--
+#### Configuring Flannel
+
+1. Prepare Kubernetes control plane for Flannel
+
+    Some minor preparation is recommended on the Kubernetes control plane in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. The following command must be run on all Linux nodes:
+
+    ```bash
+    sudo sysctl net.bridge.bridge-nf-call-iptables=1
+    ```
+-->
+#### 配置 Flannel  {#configuring-flannel}
+
+1. 为 Flannel 准备 Kubernetes 的控制面
+
+   在我们的集群中，建议对 Kubernetes 的控制面进行少许准备处理。
+   建议在使用 Flannel 时为 iptables 链启用桥接方式的 IPv4 流处理，
+   必须在所有 Linux 节点上执行如下命令：
+
+   ```bash
+   sudo sysctl net.bridge.bridge-nf-call-iptables=1
+   ```
+
+<!--
+1. Download & configure Flannel for Linux
+
+    Download the most recent Flannel manifest:
+
+    ```bash
+    wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
+    ```
+
+    Modify the `net-conf.json` section of the flannel manifest in order to set the VNI to 4096 and the Port to 4789. It should look as follows:
+
+    ```json
+    net-conf.json: |
+        {
+          "Network": "10.244.0.0/16",
+          "Backend": {
+            "Type": "vxlan",
+            "VNI" : 4096,
+            "Port": 4789
+          }
+        }
+    ```
+
+    The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
+    for an explanation of these fields.
+
+    To use L2Bridge/Host-gateway mode instead change the value of `Type` to `"host-gw"` and omit `VNI` and `Port`.
+-->
+2. 下载并配置 Linux 版本的 Flannel
+
+   下载最新的 Flannel 清单文件：
+
+   ```bash
+   wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
+   ```
+
+   修改 Flannel 清单中的 `net-conf.json` 部分，将 VNI 设置为 4096，并将 Port 设置为 4789。
+   结果看起来像下面这样：
+
+   ```json
+   net-conf.json: |
+       {
+         "Network": "10.244.0.0/16",
+         "Backend": {
+            "Type": "vxlan",
+            "VNI" : 4096,
+            "Port": 4789
+       }
+   }
+   ```
+
+   {{< note >}}
+   在 Linux 节点上 VNI 必须设置为 4096，端口必须设置为 4789，这样才能令其与 Windows 上的
+   Flannel 互操作。关于这些字段的详细说明，请参见
+   [VXLAN 文档](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)。
+   {{< /note >}}
+
+   {{< note >}}
+   如要使用 L2Bridge/Host-gateway 模式，则可将 `Type` 值设置为
+   `"host-gw"`，并忽略 `VNI` 和 `Port` 的设置。
+   {{< /note >}}
+
+<!--
+1. Apply the Flannel manifest and validate
+
+    Let's apply the Flannel configuration:
+
+    ```bash
+    kubectl apply -f kube-flannel.yml
+    ```
+
+    After a few minutes, you should see all the pods as running if the Flannel pod network was deployed.
+
+    ```bash
+    kubectl get pods -n kube-system
+    ```
+
+    The output should include the Linux flannel DaemonSet as running:
+
+    ```
+    NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE
+    ...
+    kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
+    ```
+-->
+3. 应用 Flannel 清单并验证
+
+   首先应用 Flannel 配置：
+
+   ```bash
+   kubectl apply -f kube-flannel.yml
+   ```
+
+   几分钟之后，如果 Flannel Pod 网络被正确部署，你应该会看到所有 Pods 都处于运行中状态。
+
+   ```bash
+   kubectl get pods -n kube-system
+   ```
+
+   输出中应该包含处于运行中状态的 Linux Flannel DaemonSet：
+
+   ```
+   NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE
+   ...
+   kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
+   ```
+
+<!--
+1. Add Windows Flannel and kube-proxy DaemonSets
+
+    Now you can add Windows-compatible versions of Flannel and kube-proxy. In order
+    to ensure that you get a compatible version of kube-proxy, you'll need to substitute
+    the tag of the image. The following example shows usage for Kubernetes {{< param "fullversion" >}},
+    but you should adjust the version for your own deployment.
+
+    ```bash
+    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
+    kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
+    ```
+
+    If you're using host-gateway use https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml instead
+
+If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line:
+
+```powershell
+wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
+```
+
+in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly.
+
+```bash
+# Example
+curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
+```
+-->    
+4. 添加 Windows Flannel 和 kube-proxy DaemonSet
+
+   现在你可以添加 Windows 兼容版本的 Flannel 和 kube-proxy。为了确保你能获得兼容
+   版本的 kube-proxy，你需要替换镜像中的标签。
+   下面的例子中展示的是针对 Kubernetes {{< param "fullversion" >}} 版本的用法，
+   不过你应该根据你自己的集群部署调整其中的版本号。
+
+   ```bash
+   curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
+   kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
+   ```
+
+   {{< note >}}
+   如果你在使用 host-gateway 模式，则应该使用
+   https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml
+   这一清单。
+   {{< /note >}}
+
+   {{< note >}}
+   如果你在 Windows 节点上使用的不是以太网（即，"Ethernet0 2"）接口，你需要
+   修改 `flannel-host-gw.yml` 或 `flannel-overlay.yml` 文件中的下面这行：
+
+   ```powershell
+   wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
+   ```
+
+   在其中根据情况设置要使用的网络接口。
+
+   ```bash
+   # Example
+   curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
+   ```
+   {{< /note >}}
+
+<!--
+### Joining a Windows worker node
+
+You must install the `Containers` feature and install Docker. Instructions
+to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
+
+All code snippets in Windows sections are to be run in a PowerShell environment
+with elevated permissions (Administrator) on the Windows worker node.
+-->
+### 加入 Windows 工作节点   {joiniing-a-windows-worker-node}
+
+你必须安装 `Containers` 功能特性并安装 Docker 工具。相关的指令可以在
+[Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)
+处找到。
+
+Windows 节的所有代码片段都需要在 PowerShell 环境中执行，并且要求在
+Windows 工作节点上具有提升的权限（Administrator）。
+
+<!--
+1. Install wins, kubelet, and kubeadm.
+-->
+1. 安装 wins、kubelet 和 kubeadm
+
+   ```PowerShell
+   curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+   .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
+   ```
+
+<!--
+1. Run `kubeadm` to join the node
+
+    Use the command that was given to you when you ran `kubeadm init` on a control plane host.
+    If you no longer have this command, or the token has expired, you can run `kubeadm token create -print-join-command`
+    (on a control plane host) to generate a new token and join command.
+-->
+2. 运行 `kubeadm` 添加节点
+
+   当你在控制面主机上运行 `kubeadm init` 时，输出了一个命令。现在运行这个命令。
+   如果你找不到这个命令，或者命令中对应的令牌已经过期，你可以（在一个控制面主机上）运行
+   `kubeadm token create --print-join-command` 来生成新的令牌和 join 命令。
+
+<!--
+#### Verifying your installation
+
+You should now be able to view the Windows node in your cluster by running:
+-->
+#### 检查你的安装   {#verifying-your-installation}
+
+你现在应该能够通过运行下面的命令来查看集群中的 Windows 节点了：
+
+```bash
+kubectl get nodes -o wide
+```
+
+<!--
+If your new node is in the `NotReady` state it is likely because the flannel image is still downloading.
+You can check the progress as before by checking on the flannel pods in the `kube-system` namespace:
+-->
+如果你的新节点处于 `NotReady` 状态，很可能的原因是系统仍在下载 Flannel 镜像。
+你可以像之前一样，通过检查 `kube-system` 名字空间中的 Flannel Pods 来了解
+安装进度。
+
+```shell
+kubectl -n kube-system get pods -l app=flannel
+```
+
+<!--
+Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads.
+-->
+一旦 Flannel Pod 运行起来，你的节点就应该能进入 `Ready` 状态并可
+用来处理负载。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
+-->
+- [升级 kubeadm 安装的 Windows 节点](/zh/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
+
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
index 664381d24b..fb66b92b9b 100644
--- a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@@ -1,16 +1,13 @@
 ---
-reviewers:
-- sig-cluster-lifecycle
 title: 使用 kubeadm 进行证书管理
 content_type: task
+weight: 10
 ---
 <!--
----
 reviewers:
 - sig-cluster-lifecycle
 title: Certificate Management with kubeadm
 content_type: task
----
 -->
 
 <!-- overview -->
@@ -18,253 +15,321 @@ content_type: task
 {{< feature-state for_k8s_version="v1.15" state="stable" >}}
 
 <!-- 
-Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. 
+Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. 
 -->
-
-由 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 生成的客户端证书在 1 年后到期。 本页说明如何使用 kubeadm 管理证书续订。
-
-
+由 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 生成的客户端证书在 1 年后到期。
+本页说明如何使用 kubeadm 管理证书续订。
 
 ## {{% heading "prerequisites" %}}
 
-
-<!-- 
-Be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/). 
--->
-
-熟悉 [Kubernetes 中的 PKI证书和要求](/docs/setup/certificates/)。
-
 <!--
 You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
 -->
-您应该熟悉[Kubernetes 中的 PKI 证书和要求](/docs/setup/best-practices/certificates/)。
-
-
+你应该熟悉 [Kubernetes 中的 PKI 证书和要求](/zh/docs/setup/best-practices/certificates/)。
 
 <!-- steps -->
 
+<!--
+### Using custom certificates {#custom-certificates}
+
+By default, kubeadm generates all the certificates needed for a cluster to run.
+You can override this behavior by providing your own certificates.
+-->
+### 使用自定义的证书 {#custom-certificates}
+
+默认情况下, kubeadm 会生成运行一个集群所需的全部证书。
+你可以通过提供你自己的证书来改变这个行为策略。
+
+<!--
+To do so, you must place them in whatever directory is specified by the
+`--cert-dir` flag or `CertificatesDir` configuration file key. By default this
+is `/etc/kubernetes/pki`.
+-->
+如果要这样做, 你必须将证书文件放置在通过 `--cert-dir` 命令行参数或者配置文件里的
+`CertificatesDir` 配置项指明的目录中。默认的值是 `/etc/kubernetes/pki`。
+
+<!--
+If a given certificate and private key pair exists before running `kubeadm init`,
+kubeadm will not overwrite them. This means you can, for example, copy an existing
+CA into `/etc/kubernetes/pki/ca.crt` and `/etc/kubernetes/pki/ca.key`,
+and kubeadm will use this CA for signing the rest of the certificates.
+-->
+如果在运行 `kubeadm init` 之前存在给定的证书和私钥对，kubeadm 将不会重写它们。
+例如，这意味着您可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.crt` 和
+`/etc/kubernetes/pki/ca.key` 中，而 kubeadm 将使用此 CA 对其余证书进行签名。
+
+<!--
+#### External CA mode {#external-ca-mode}
+
+It is also possible to provide just the `ca.crt` file and not the
+`ca.key` file (this is only available for the root CA file, not other cert pairs).
+If all other certificates and kubeconfig files are in place, kubeadm recognizes
+this condition and activates the "External CA" mode. kubeadm will proceed without the
+CA key on disk.
+-->
+#### 外部 CA 模式 {#external-ca-mode}
+
+只提供了 `ca.crt` 文件但是不提供 `ca.key` 文件也是可以的 (这只对 CA 根证书可用，其它证书不可用)。
+如果所有的其它证书和 kubeconfig 文件已就绪， kubeadm 检测到满足以上条件就会激活
+"外部 CA" 模式。kubeadm 将会在没有 CA 密钥文件的情况下继续执行。
+
+<!--
+Instead, run the controller-manager standalone with `--controllers=csrsigner` and
+point to the CA certificate and key.
+-->
+否则, kubeadm 将独立运行 controller-manager，附加一个 `--controllers=csrsigner`
+的参数，并且指明 CA 证书和密钥。
+
 <!-- 
 ## Check certificate expiration 
--->
 
+You can use the `check-expiration` subcommand to check certificate expiration. 
+-->
 ## 检查证书是否过期
 
-<!-- 
-`check-expiration` can be used to check certificate expiration. 
--->
+你可以使用 `check-expiration` 子命令来检查证书是否过期
 
-`check-expiration` 能被用来检查证书是否过期
-
-```
+```shell
 kubeadm alpha certs check-expiration
 ``` 
 
-<!-- 
-The output is similar to this: 
--->
-
+<!-- The output is similar to this: -->
 输出类似于以下内容：
 
 ```
-CERTIFICATE                EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
-admin.conf                 May 15, 2020 13:03 UTC   364d            false
-apiserver                  May 15, 2020 13:00 UTC   364d            false
-apiserver-etcd-client      May 15, 2020 13:00 UTC   364d            false
-apiserver-kubelet-client   May 15, 2020 13:00 UTC   364d            false
-controller-manager.conf    May 15, 2020 13:03 UTC   364d            false
-etcd-healthcheck-client    May 15, 2020 13:00 UTC   364d            false
-etcd-peer                  May 15, 2020 13:00 UTC   364d            false
-etcd-server                May 15, 2020 13:00 UTC   364d            false
-front-proxy-client         May 15, 2020 13:00 UTC   364d            false
-scheduler.conf             May 15, 2020 13:03 UTC   364d            false
+CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
+admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no
+apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no
+apiserver-etcd-client      Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
+apiserver-kubelet-client   Dec 30, 2020 23:36 UTC   364d            ca                      no
+controller-manager.conf    Dec 30, 2020 23:36 UTC   364d                                    no
+etcd-healthcheck-client    Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
+etcd-peer                  Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
+etcd-server                Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
+front-proxy-client         Dec 30, 2020 23:36 UTC   364d            front-proxy-ca          no
+scheduler.conf             Dec 30, 2020 23:36 UTC   364d                                    no
+
+CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
+ca                      Dec 28, 2029 23:36 UTC   9y              no
+etcd-ca                 Dec 28, 2029 23:36 UTC   9y              no
+front-proxy-ca          Dec 28, 2029 23:36 UTC   9y              no
 ```
 
 <!-- 
 The command shows expiration/residual time for the client certificates in the `/etc/kubernetes/pki` folder and for the client certificate embedded in the KUBECONFIG files used by kubeadm (`admin.conf`, `controller-manager.conf` and `scheduler.conf`). 
 -->
-
-该命令显示 `/etc/kubernetes/pki` 文件夹中的客户端证书以及 kubeadm 使用的 KUBECONFIG 文件中嵌入的客户端证书的到期时间/剩余时间。
+该命令显示 `/etc/kubernetes/pki` 文件夹中的客户端证书以及 kubeadm 使用的 KUBECONFIG
+文件中嵌入的客户端证书的到期时间/剩余时间。
 
 <!-- 
 Additionally, kubeadm informs the user if the certificate is externally managed; in this case, the user should take care of managing certificate renewal manually/using other tools. 
 -->
+另外， kubeadm 会通知用户证书是否由外部管理； 
+在这种情况下，用户应该小心的手动/使用其他工具来管理证书更新。
 
-另外， kubeadm 会通知用户证书是否由外部管理； 在这种情况下，用户应该小心的手动/使用其他工具来管理证书更新。
-
-{{< warning >}}
 <!--
 `kubeadm` cannot manage certificates signed by an external CA.
- -->`kubeadm` 不能管理由外部 CA 签名的证书
+ -->`
+{{< warning >}}
+kubeadm` 不能管理由外部 CA 签名的证书
 {{< /warning >}}
 
-{{< note >}}
 <!-- 
 `kubelet.conf` is not included in the list above because kubeadm configures kubelet for automatic certificate renewal.
--->上面的列表中没有包含 `kubelet.conf` 因为 kubeadm 将 kubelet 配置为自动更新证书。
-
+-->
+{{< note >}}
+上面的列表中没有包含 `kubelet.conf` 因为 kubeadm 将 kubelet 配置为自动更新证书。
 {{< /note >}}
 
+<!--
+On nodes created with `kubeadm init`, prior to kubeadm version 1.17, there is a
+[bug](https://github.com/kubernetes/kubeadm/issues/1753) where you manually have to modify the contents of `kubelet.conf`. After `kubeadm init` finishes, you should update `kubelet.conf` to point to the
+rotated kubelet client certificates, by replacing `client-certificate-data` and `client-key-data` with:
+-->
+{{< warning >}}
+在通过 `kubeadm init` 创建的节点上，在 kubeadm 1.17 版本之前有一个
+[缺陷](https://github.com/kubernetes/kubeadm/issues/1753)，该缺陷
+使得你必须手动修改 `kubelet.conf` 文件的内容。
+`kubeadm init` 操作结束之后，你必须更新 `kubelet.conf` 文件
+将 `client-certificate-data` 和 `client-key-data` 改为如下所示的内容
+以便使用轮换后的 kubelet 客户端证书：
+
+```yaml
+client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
+client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
+```
+{{< /warning >}}
+
 <!-- 
 ## Automatic certificate renewal
- -->
-## 自动更新证书
 
-<!-- 
 `kubeadm` renews all the certificates during control plane [upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/). 
 -->
-`kubeadm` 会在控制面板[升级](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)的时候更新所有证书
+## 自动更新证书
+
+`kubeadm` 会在控制面
+[升级](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+的时候更新所有证书。
 
 <!-- 
 This feature is designed for addressing the simplest use cases; 
 if you don't have specific requirements on certificate renewal and perform Kubernetes version upgrades regularly (less than 1 year in between each upgrade), kubeadm will take care of keeping your cluster up to date and reasonably secure. 
 -->
-这个功能旨在解决最简单的用例；如果您对此类证书的更新没有特殊要求，并且定期执行 Kubernetes 版本升级（每次升级之间的间隔时间少于 1 年），则 kubeadm 将确保您的集群保持最新状态并保持合理的安全性。
+这个功能旨在解决最简单的用例；如果你对此类证书的更新没有特殊要求，
+并且定期执行 Kubernetes 版本升级（每次升级之间的间隔时间少于 1 年），
+则 kubeadm 将确保你的集群保持最新状态并保持合理的安全性。
 
-{{< note >}}
 <!-- 
 It is a best practice to upgrade your cluster frequently in order to stay secure.
- -->最佳的做法是经常升级集群以确保安全。
+-->
+{{< note >}}
+最佳的做法是经常升级集群以确保安全。
 {{< /note >}}
 
 <!-- 
 If you have more complex requirements for certificate renewal, you can opt out from the default behavior by passing `--certificate-renewal=false` to `kubeadm upgrade apply` or to `kubeadm upgrade node`. 
 -->
+如果你对证书更新有更复杂的需求，则可通过将 `--certificate-renewal=false` 传递给
+`kubeadm upgrade apply` 或者 `kubeadm upgrade node`，从而选择不采用默认行为。
 
-如果您对证书更新有更复杂的需求，则可通过将 `--certificate-renewal=false` 传递给 `kubeadm upgrade apply` 或者 `kubeadm upgrade node` ，从而选择不采用默认行为。
+<!--
+Prior to kubeadm version 1.17 there is a [bug](https://github.com/kubernetes/kubeadm/issues/1818)
+where the default value for `--certificate-renewal` is `false` for the `kubeadm upgrade node`
+command. In that case, you should explicitly set `--certificate-renewal=true`.
+-->
+{{< warning >}}
+kubeadm 在 1.17 版本之前有一个[缺陷](https://github.com/kubernetes/kubeadm/issues/1818)，
+该缺陷导致 `kubeadm update node` 执行时 `--certificate-renewal` 的默认值被设置为 `false`。
+在这种情况下，你需要显式地设置 `--certificate-renewal=true`。
+{{< /warning >}}
 
 <!-- 
 ## Manual certificate renewal 
+
+You can renew your certificates manually at any time with the `kubeadm alpha certs renew` command. 
 -->
 ## 手动更新证书
 
-<!-- 
-You can renew your certificates manually at any time with the `kubeadm alpha certs renew` command. 
--->
-您能随时通过 `kubeadm alpha certs renew` 命令手动更新您的证书。
+你能随时通过 `kubeadm alpha certs renew` 命令手动更新你的证书。
 
 <!-- 
 This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. 
 -->
+此命令用 CA （或者 front-proxy-CA ）证书和存储在 `/etc/kubernetes/pki` 中的密钥执行更新。
 
-这个命令用 CA （或者 front-proxy-CA ）证书和存储在 `/etc/kubernetes/pki` 中的密钥执行更新。
-
-{{< warning >}}
 <!-- 
 If you are running an HA cluster, this command needs to be executed on all the control-plane nodes. 
--->如果您运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。
+-->
+{{< warning >}}
+如果你运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。
 {{< /warning >}}
 
-{{< note >}}
 <!-- `alpha certs renew` uses the existing certificates as the authoritative source for attributes (Common Name, Organization, SAN, etc.) instead of the kubeadm-config ConfigMap. It is strongly recommended to keep them both in sync. -->
-`alpha certs renew` 使用现有的证书作为属性 (Common Name、Organization、SAN 等) 的权威来源，而不是 kubeadm-config ConfigMap 。强烈建议使它们保持同步。
+{{< note >}}
+`alpha certs renew` 使用现有的证书作为属性 (Common Name、Organization、SAN 等) 的权威来源，
+而不是 kubeadm-config ConfigMap 。强烈建议使它们保持同步。
 {{< /note >}}
 
-<!-- 
-`kubeadm alpha certs renew` provides the following options:
- -->
-`kubeadm alpha certs renew` 提供下列选项 
-
 <!--
 The Kubernetes certificates normally reach their expiration date after one year.
 -->
 Kubernetes 证书通常在一年后到期。
 
 <!-- 
+`kubeadm alpha certs renew` provides the following options:
+
 - `--csr-only` can be used to renew certificats with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information. 
--->
-
-- `--csr-only` 可用于经过一个外部 CA 生成的证书签名请求来更新证书（无需实际替换更新证书）；更多信息请参见下一段。
-
-<!-- 
 - It's also possible to renew a single certificate instead of all.
  -->
-- 也可以更新单个证书而不是全部证书。
+`kubeadm alpha certs renew` 提供下列选项 
+
+- `--csr-only` 可用于经过一个外部 CA 生成的证书签名请求来更新证书（无需实际替换更新证书）；
+  更多信息请参见下节。
+- 可以更新单个证书而不是全部证书。
 
 <!--
 ## Renew certificates with the Kubernetes certificates API
+
+This section provide more details about how to execute manual certificate renewal using the Kubernetes certificates API.
 -->
 ## 用 Kubernetes 证书 API 更新证书
 
-<!-- 
-This section provide more details about how to execute manual certificate renewal using the Kubernetes certificates API.
--->
-
 本节提供有关如何使用 Kubernetes 证书 API 执行手动证书更新的更多详细信息。
 
-{{< caution >}}
 <!-- 
 These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead. 
 -->
-这些是针对需要将其组织的证书基础结构集成到 kubeadm 构建的集群中的用户的高级主题。如果默认的 kubeadm 配置满足了您的需求，则应让 kubeadm 管理证书。
+{{< caution >}}
+这些是针对需要将其组织的证书基础结构集成到 kubeadm 构建的集群中的用户的高级主题。
+如果默认的 kubeadm 配置满足了你的需求，则应让 kubeadm 管理证书。
 {{< /caution >}}
 
 <!--
 ### Set up a signer
--->
-### 设置一个签名者
 
-<!--
 The Kubernetes Certificate Authority does not work out of the box.
 You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
 The built-in signer is part of [`kube-controller-manager`][kcm].
 To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
 -->
+### 设置一个签名者（Signer）
+
 Kubernetes 证书颁发机构不是开箱即用。
-您可以配置外部签名者，例如 [cert-manager][cert-manager-issuer] ，也可以使用内置签名者。
-内置签名者是 [`kube-controller-manager`][kcm] 的一部分。
+你可以配置外部签名者，例如
+[cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html)，
+也可以使用内置签名者。
+内置签名者是
+[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
+的一部分。
 要激活内置签名者，请传递`--cluster-signing-cert-file` 和 `--cluster-signing-key-file`参数。
 
 <!--
 The built-in signer is part of [`kube-controller-manager`][kcm]. 
+To activate the build-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags.
 -->
 这个内置签名者是 [`kube-controller-manager`][kcm] 的一部分。
-
-<!-- To activate the build-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags. -->
 要激活内置签名者，必须传递 `--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数。
 
 <!-- 
 If you're creating a new cluster, you can use a kubeadm [configuration file][config]: 
 -->
-如果您正在正在创建一个新的集群，您可以使用 kubeadm 的 [配置文件](config) 
+如果你正在正在创建一个新的集群，你可以使用 kubeadm 的
+[配置文件](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)。
 
-  ```yaml
-  apiVersion: kubeadm.k8s.io/v1beta2
-  kind: ClusterConfiguration
-  controllerManager:
-    extraArgs:
-      cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
-      cluster-signing-key-file: /etc/kubernetes/pki/ca.key
-  ```
-
-[cert-manager-issuer]: https://cert-manager.readthedocs.io/en/latest/tutorials/ca/creating-ca-issuer.html
-[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
-[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+controllerManager:
+  extraArgs:
+    cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
+    cluster-signing-key-file: /etc/kubernetes/pki/ca.key
+```
 
 <!-- 
 ### Create certificate signing requests (CSR)
+
+You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`. 
 -->
 ### 创建证书签名请求 (CSR)
 
-<!-- 
-You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`. 
--->
-您能用  `kubeadm alpha certs renew --use-api` 为 Kubernetes 证书 API 创建一个证书签名请求。
+你可以用 `kubeadm alpha certs renew --use-api` 为 Kubernetes 证书 API 创建一个证书签名请求。
 
 <!--
 If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
 Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
 The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
 -->
-如果您设置例如 [cert-manager][cert-manager] 等外部签名者，则会自动批准证书签名请求（CSRs）。
-否者，您必须使用 [`kubectl certificate`][certs] 命令手动批准证书。
-以下 kubeadm 命令输出要批准的证书名称，然后缓慢等待批准发生：
+如果你设置例如 [cert-manager](https://github.com/jetstack/cert-manager)
+等外部签名者，证书签名请求（CSRs）会被自动批准。
+否则，你必须使用 [`kubectl certificate`](/zh/docs/setup/best-practices/certificates/) 
+命令手动批准证书。
+以下 kubeadm 命令输出要批准的证书名称，然后阻塞等待批准发生：
 
 ```shell
 sudo kubeadm alpha certs renew apiserver --use-api &
 ```
-<!-- 
-The output is similar to this:
- -->
+
+<!-- The output is similar to this: -->
 输出类似于以下内容：
 ```
 [1] 2890
@@ -273,41 +338,42 @@ The output is similar to this:
 
 <!-- 
 ### Approve certificate signing requests (CSR) 
+
+If you set up an external signer, certificate signing requests (CSRs) are automatically approved. 
+
+Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. e.g.
 -->
 ### 批准证书签名请求 (CSR)
 
-<!-- 
-If you set up an external signer, certificate signing requests (CSRs) are automatically approved. 
--->
-如果您设置了一个外部签名者， 证书签名请求 (CSRs) 会自动被批准。
+如果你设置了一个外部签名者， 证书签名请求 (CSRs) 会自动被批准。
 
-<!-- Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. e.g.  -->
-否则，您必须用 [`kubectl certificate`][certs] 命令手动批准证书，例如
+否则，你必须用 [`kubectl certificate`](/zh/docs/setup/best-practices/certificates/)
+命令手动批准证书，例如：
 
 ```shell
 kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
 ```
+
 <!-- 
-The output is similar to this: 
--->
+The output is similar to this: -->
 输出类似于以下内容：
-```shell
+
+```
 certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
 ```
 
 <!-- 
 You can view a list of pending certificates with `kubectl get csr`. 
 -->
-您可以使用 `kubectl get csr` 查看待处理证书列表。
+你可以使用 `kubectl get csr` 查看待处理证书列表。
 
 <!--
 ## Renew certificates with external CA
+
+This section provide more details about how to execute manual certificate renewal using an external CA.
 -->
 ## 通过外部 CA 更新证书
 
-<!-- 
-This section provide more details about how to execute manual certificate renewal using an external CA.
--->
 本节提供有关如何使用外部 CA 执行手动更新证书的更多详细信息。
 
 <!--
@@ -321,70 +387,65 @@ CSR 表示向 CA 请求客户的签名证书。
 
 <!-- 
 ### Create certificate signing requests (CSR) 
+
+You can create certificate signing requests with `kubeadm alpha certs renew --csr-only`.
+
+Both the CSR and the accompanying private key are given in the output.
+You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
+If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
 -->
 ### 创建证书签名请求 (CSR)
 
-<!--
-You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
-If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
-Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
--->
-您可以传入一个带有 `--csr-dir` 的目录，将 CRS 输出到指定位置。
+你可以通过 `kubeadm alpha certs renew --csr-only` 命令创建证书签名请求。
+
+CSR 和随附的私钥都在输出中给出。
+你可以传入一个带有 `--csr-dir` 的目录，将 CRS 输出到指定位置。
 如果未指定 `--csr-dir` ，则使用默认证书目录( `/etc/kubernetes/pki` )。
-CSR 和随附的私钥都在输出中给出。签署证书后，必须将证书和私钥复制到 PKI 目录（默认情况下为 `/etc/kubernetes/pki`）。
 
-<!-- 
-A CSR represents a request to a CA for a signed certificate for a client. 
--->
-CSR 代表对 CA 的请求，要求获得客户端的签名证书。
-
-<!-- 
-You can create certificate signing requests with `kubeadm alpha certs renew --csr-only`. 
--->
-您能用 `kubeadm alpha certs renew --csr-only` 创建一个证书签名请求。
-
-<!-- 
-Both the CSR and the accompanying private key are given in the output; you can pass in a directory with `--csr-dir` to output the CSRs to the specified location. 
--->
-输出中给出了 CSR 和随附的私钥；您可以输入目录名和 `--csr-dir` ，以将 CSR 输出到指定位置。
-
-<!-- 
+<!--
 Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
 As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
-To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`) 
 -->
-证书能用 `kubeadm alpha certs renew --csr-only` 更新。
+证书可以通过 `kubeadm alpha certs renew --csr-only` 来续订。
+和 `kubeadm init` 一样，可以使用 `--csr-dir` 标志指定一个输出目录。
 
-在 `kubeadm init` ,通过 `--csr-dir` 能指定输出文件夹。
+CSR 签署证书后，必须将证书和私钥复制到 PKI 目录（默认情况下为 `/etc/kubernetes/pki`）。
 
-要使用新证书，请将签名的证书和私钥复制到 PKI 目录（默认情况下为 `/etc/kubernetes/pki` ）
-
-<!-- 
-A CSR contains a certificate's name, domain(s), and IPs, but it does not specify usages. 
+<!--
+A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
+It is the responsibility of the CA to specify [the correct cert usages](/docs/setup/best-practices/certificates/#all-certificates)
+when issuing a certificate.
 -->
-一个 CSR 包含一个证书的名字，域和 IP， 但是未指定用法
-
-<!-- 
-It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate. 
--->
-颁发证书时， CA 有责任指定[正确的证书用法][cert-table] 。
+CSR 中包含一个证书的名字，域和 IP，但是未指定用法。
+颁发证书时，CA 有责任指定[正确的证书用法](/zh/docs/setup/best-practices/certificates/#all-certificates)
 
 <!-- 
 * In `openssl` this is done with the [`openssl ca` command][openssl-ca].
 * In `cfssl` you specify [usages in the config file][cfssl-usages] 
 -->
-* 在 `openssl` 中，这是通过 [`openssl ca` 命令][openssl-ca] 完成的。
-* 在 `cfssl` 中，这是通过 [在配置文件中指定用法][cfssl-usages] 来完成的。
+* 在 `openssl` 中，这是通过
+  [`openssl ca` 命令](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)
+  来完成的。
+* 在 `cfssl` 中，这是通过
+  [在配置文件中指定用法](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)
+  来完成的。
 
 <!-- 
 After a certificate is signed using your preferred method, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`). 
 -->
-使用首选方法对证书签名后，必须将证书和私钥复制到 PKI 目录（默认为  `/etc/kubernetes/pki` ）。
+使用首选方法对证书签名后，必须将证书和私钥复制到 PKI 目录（默认为 `/etc/kubernetes/pki` ）。
 
+<!--
+## Certificate authority (CA) rotation {#certificate-authority-rotation}
 
-[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
-[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
-[certs]: /docs/setup/best-practices/certificates/
-[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
-[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
+Kubeadm does not support rotation or replacement of CA certificates out of the box.
+
+For more information about manual rotation or replacement of CA, see [manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/).
+-->
+## 证书机构（CA）轮换     {#certificate-authority-rotation}
+
+kubeadm 并不直接支持对 CA 证书的轮换或者替换。
+
+关于手动轮换或者置换 CA 的更多信息，可参阅
+[手动轮换 CA 证书](/zh/docs/tasks/tls/manual-rotation-of-ca-certificates/)。
 
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
index e01404b95d..bfe410fe65 100644
--- a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@@ -2,7 +2,7 @@
 title: 升级 kubeadm 集群
 content_type: task
 weight: 20
-min-kubernetes-server-version: 1.18
+min-kubernetes-server-version: 1.19
 ---
 <!--
 reviewers:
@@ -17,10 +17,10 @@ min-kubernetes-server-version: 1.18
 
 <!--
 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
-1.17.x to version 1.18.x, and from version 1.18.x to 1.18.y (where `y > x`).
+1.18.x to version 1.19.x, and from version 1.19.x to 1.19.y (where `y > x`).
 -->
-本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 1.17.x 版本升级到 1.18.x 版本，
-或者从版本 1.18.x 升级到 1.18.y ，其中 `y > x`。
+本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 1.18.x 版本升级到 1.19.x 版本，
+或者从版本 1.19.x 升级到 1.19.y ，其中 `y > x`。
 
 <!--
 To see information about upgrading clusters created using older versions of kubeadm,
@@ -29,15 +29,17 @@ please refer to following pages instead:
 要查看 kubeadm 创建的有关旧版本集群升级的信息，请参考以下页面：
 
 <!--
+- [Upgrading kubeadm cluster from 1.17 to 1.18](https://v1-18.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [Upgrading kubeadm cluster from 1.16 to 1.17](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [Upgrading kubeadm cluster from 1.15 to 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [Upgrading kubeadm cluster from 1.14 to 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
 - [Upgrading kubeadm cluster from 1.13 to 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
 -->
-- [将 kubeadm 集群从 1.16 升级到 1.17](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
-- [将 kubeadm 集群从 1.15 升级到 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
-- [将 kubeadm 集群从 1.14 升级到 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
-- [将 kubeadm 集群从 1.13 升级到 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
+- [将 kubeadm 集群从 1.17 升级到 1.18](https://v1-18.docs.kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [将 kubeadm 集群从 1.16 升级到 1.17](https://v1-17.docs.kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [将 kubeadm 集群从 1.15 升级到 1.16](https://v1-16.docs.kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [将 kubeadm 集群从 1.14 升级到 1.15](https://v1-15.docs.kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
+- [将 kubeadm 集群从 1.13 升级到 1.14](https://v1-15.docs.kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
 
 <!--
 The upgrade workflow at high level is the following:
@@ -55,14 +57,14 @@ The upgrade workflow at high level is the following:
 ## {{% heading "prerequisites" %}}
 
 <!--
-- You need to have a kubeadm Kubernetes cluster running version 1.17.0 or later.
+- You need to have a kubeadm Kubernetes cluster running version 1.18.0 or later.
 - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
 - The cluster should use a static control plane and etcd pods or external etcd.
 - Make sure you read the [release notes]({{< latest-release-notes >}}) carefully.
 - Make sure to back up any important components, such as app-level state stored in a database.
   `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
 -->
-- 你需要有一个由 `kubeadm` 创建并运行着 1.17.0 或更高版本的 Kubernetes 集群。
+- 你需要有一个由 `kubeadm` 创建并运行着 1.18.0 或更高版本的 Kubernetes 集群。
 - [禁用交换分区](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。
 - 集群应使用静态的控制平面和 etcd Pod 或者 外部 etcd。
 - 务必仔细认真阅读[发行说明]({{< latest-release-notes >}})。
@@ -89,26 +91,26 @@ The upgrade workflow at high level is the following:
 <!--
 ## Determine which version to upgrade to
 
-Find the latest stable 1.18 version:
+Find the latest stable 1.19 version:
 -->
 ## 确定要升级到哪个版本
 
-找到最新的稳定版 1.18：
+找到最新的稳定版 1.19：
 
 {{< tabs name="k8s_install_versions" >}}
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
 ```
 apt update
 apt-cache policy kubeadm
-# 在列表中查找最新的 1.18 版本
-# 它看起来应该是 1.18.x-00 ，其中 x 是最新的补丁
+# 在列表中查找最新的 1.19 版本
+# 它看起来应该是 1.19.x-00 ，其中 x 是最新的补丁
 ```
 {{% /tab %}}
 {{% tab name="CentOS、RHEL 或 Fedora" %}}
 ```
 yum list --showduplicates kubeadm --disableexcludes=kubernetes
-# 在列表中查找最新的 1.18 版本
-# 它看起来应该是 1.18.x-0 ，其中 x 是最新的补丁版本
+# 在列表中查找最新的 1.19 版本
+# 它看起来应该是 1.19.x-0 ，其中 x 是最新的补丁版本
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -130,16 +132,20 @@ yum list --showduplicates kubeadm --disableexcludes=kubernetes
 {{< tabs name="k8s_install_kubeadm_first_cp" >}}
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
 ```shell
-# 用最新的修补程序版本替换 1.18.x-00 中的 x
+# 用最新的修补程序版本替换 1.19.x-00 中的 x
 apt-mark unhold kubeadm && \
-apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
+apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
 apt-mark hold kubeadm
+-
+# 从 apt-get 1.1 版本起，你也可以使用下面的方法
+apt-get update && \
+apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
 ```
 {{% /tab %}}
 {{% tab name="CentOS、RHEL 或 Fedora" %}}
 ```shell
-# 用最新的修补程序版本替换 1.18.x-0 中的 x
-yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+# 用最新的修补程序版本替换 1.19.x-0 中的 x
+yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -192,36 +198,48 @@ yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
   [preflight] Running pre-flight checks.
   [upgrade] Running cluster health checks
   [upgrade] Fetching available versions to upgrade to
-  [upgrade/versions] Cluster version: v1.17.3
-  [upgrade/versions] kubeadm version: v1.18.0
-  [upgrade/versions] Latest stable version: v1.18.0
-  [upgrade/versions] Latest version in the v1.17 series: v1.18.0
+  [upgrade/versions] Cluster version: v1.18.4
+  [upgrade/versions] kubeadm version: v1.19.0
+  [upgrade/versions] Latest stable version: v1.19.0
+  [upgrade/versions] Latest version in the v1.18 series: v1.18.4
 
   Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
   COMPONENT   CURRENT             AVAILABLE
-  Kubelet     1 x v1.17.3   v1.18.0
+  Kubelet     1 x v1.18.4         v1.19.0
 
-  Upgrade to the latest version in the v1.17 series:
+  Upgrade to the latest version in the v1.18 series:
 
   COMPONENT            CURRENT   AVAILABLE
-  API Server           v1.17.3   v1.18.0
-  Controller Manager   v1.17.3   v1.18.0
-  Scheduler            v1.17.3   v1.18.0
-  Kube Proxy           v1.17.3   v1.18.0
-  CoreDNS              1.6.5     1.6.7
-  Etcd                 3.4.3     3.4.3-0
+  API Server           v1.18.4   v1.19.0
+  Controller Manager   v1.18.4   v1.19.0
+  Scheduler            v1.18.4   v1.19.0
+  Kube Proxy           v1.18.4   v1.19.0
+  CoreDNS              1.6.7     1.7.0
+  Etcd                 3.4.3-0   3.4.7-0
 
   You can now apply the upgrade by executing the following command:
 
-      kubeadm upgrade apply v1.18.0
+      kubeadm upgrade apply v1.19.0
 
   _____________________________________________________________________
+
+    The table below shows the current state of component configs as understood by this version of kubeadm.
+    Configs that have a "yes" mark in the "MANUAL UPGRADE REQUIRED" column require manual config upgrade or
+    resetting to kubeadm defaults before a successful upgrade can be performed. The version to manually
+    upgrade to is denoted in the "PREFERRED VERSION" column.
+
+    API GROUP                 CURRENT VERSION   PREFERRED VERSION   MANUAL UPGRADE REQUIRED
+    kubeproxy.config.k8s.io   v1alpha1          v1alpha1            no
+    kubelet.config.k8s.io     v1beta1           v1beta1             no
+    _____________________________________________________________________
   ```
 
   <!--
   This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
+  It also shows a table with the component config version states.
   -->
   此命令检查你的集群是否可以升级，并可以获取到升级的版本。
+  其中也显示了组件配置版本状态的表格。
 
 <!--
 `kubeadm upgrade` also automatically renews the certificates that it manages on this node.
@@ -234,19 +252,30 @@ For more information see the [certificate management guide](/docs/tasks/administ
 关于更多细节信息，可参见[证书管理指南](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。
 {{</ note >}}
 
+{{< note >}}
+<!--
+If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide
+a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag.
+Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade.
+-->
+如果 `kubeadm upgrade plan` 显示有任何组件配置需要手动升级，则用户必须
+通过命令行参数 `--config` 给 `kubeadm upgrade apply` 操作
+提供带有替换配置的配置文件。
+{{</ note >}}
+
 <!--
 - Choose a version to upgrade to, and run the appropriate command. For example:
 
     ```shell
     # replace x with the patch version you picked for this upgrade
-    sudo kubeadm upgrade apply v1.18.x
+    sudo kubeadm upgrade apply v1.19.x
     ```
 -->
 - 选择要升级到的版本，然后运行相应的命令。例如:
 
   ```shell
   # 将 x 替换为你为此次升级所选的补丁版本号
-  sudo kubeadm upgrade apply v1.18.x
+  sudo kubeadm upgrade apply v1.19.x
   ```
 
   <!--
@@ -254,81 +283,84 @@ For more information see the [certificate management guide](/docs/tasks/administ
   -->
   你应该可以看见与下面类似的输出：
 
-  ```none
+  ```
   [upgrade/config] Making sure the configuration is correct:
   [upgrade/config] Reading configuration from the cluster...
   [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
   [preflight] Running pre-flight checks.
   [upgrade] Running cluster health checks
-  [upgrade/version] You have chosen to change the cluster version to "v1.18.0"
-  [upgrade/versions] Cluster version: v1.17.3
-  [upgrade/versions] kubeadm version: v1.18.0
+  [upgrade/version] You have chosen to change the cluster version to "v1.19.0"
+  [upgrade/versions] Cluster version: v1.18.4
+  [upgrade/versions] kubeadm version: v1.19.0
   [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
-  [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
-  [upgrade/prepull] Prepulling image for component etcd.
-  [upgrade/prepull] Prepulling image for component kube-apiserver.
-  [upgrade/prepull] Prepulling image for component kube-controller-manager.
-  [upgrade/prepull] Prepulling image for component kube-scheduler.
-  [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
-  [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
-  [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
-  [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
-  [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
-  [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
-  [upgrade/prepull] Prepulled image for component etcd.
-  [upgrade/prepull] Prepulled image for component kube-apiserver.
-  [upgrade/prepull] Prepulled image for component kube-controller-manager.
-  [upgrade/prepull] Prepulled image for component kube-scheduler.
-  [upgrade/prepull] Successfully prepulled the images for all the control plane components
-  [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"...
-  Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
-  Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
-  Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
+  [upgrade/prepull] Pulling images required for setting up a Kubernetes cluster
+  [upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection
+  [upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull'
+  [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.19.0"...
+  Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+  Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
+  Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
   [upgrade/etcd] Upgrading to TLS for etcd
-  [upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
-  [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012"
-  W0308 18:48:14.535122    3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
+  Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
+  [upgrade/staticpods] Preparing for "etcd" upgrade
+  [upgrade/staticpods] Renewing etcd-server certificate
+  [upgrade/staticpods] Renewing etcd-peer certificate
+  [upgrade/staticpods] Renewing etcd-healthcheck-client certificate
+  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/etcd.yaml"
+  [upgrade/staticpods] Waiting for the kubelet to restart the component
+  [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
+  Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
+  Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
+  Static pod: etcd-kind-control-plane hash: 59e40b2aab1cd7055e64450b5ee438f0
+  [apiclient] Found 1 Pods for label selector component=etcd
+  [upgrade/staticpods] Component "etcd" upgraded successfully!
+  [upgrade/etcd] Waiting for etcd to become available
+  [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests999800980"
   [upgrade/staticpods] Preparing for "kube-apiserver" upgrade
   [upgrade/staticpods] Renewing apiserver certificate
   [upgrade/staticpods] Renewing apiserver-kubelet-client certificate
   [upgrade/staticpods] Renewing front-proxy-client certificate
   [upgrade/staticpods] Renewing apiserver-etcd-client certificate
-  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml"
+  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-apiserver.yaml"
   [upgrade/staticpods] Waiting for the kubelet to restart the component
   [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-  Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
-  Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4
+  Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+  Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+  Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+  Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
+  Static pod: kube-apiserver-kind-control-plane hash: f717874150ba572f020dcd89db8480fc
   [apiclient] Found 1 Pods for label selector component=kube-apiserver
   [upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
   [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
   [upgrade/staticpods] Renewing controller-manager.conf certificate
-  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml"
+  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-controller-manager.yaml"
   [upgrade/staticpods] Waiting for the kubelet to restart the component
   [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-  Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
-  Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156
+  Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
+  Static pod: kube-controller-manager-kind-control-plane hash: b155b63c70e798b806e64a866e297dd0
   [apiclient] Found 1 Pods for label selector component=kube-controller-manager
   [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
   [upgrade/staticpods] Preparing for "kube-scheduler" upgrade
   [upgrade/staticpods] Renewing scheduler.conf certificate
-  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml"
+  [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-scheduler.yaml"
   [upgrade/staticpods] Waiting for the kubelet to restart the component
   [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-  Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
-  Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d
+  Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
+  Static pod: kube-scheduler-kind-control-plane hash: 260018ac854dbf1c9fe82493e88aec31
   [apiclient] Found 1 Pods for label selector component=kube-scheduler
   [upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
   [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
-  [kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
-  [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
+  [kubelet] Creating a ConfigMap "kubelet-config-1.19" in namespace kube-system with the configuration for the kubelets in the cluster
   [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
+  [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
   [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
   [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
   [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
+  W0713 16:26:14.074656    2986 dns.go:282] the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. The existing CoreDNS Corefile configuration and deployment has been retained.
   [addons] Applied essential addon: CoreDNS
   [addons] Applied essential addon: kube-proxy
 
-  [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy!
+  [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.19.0". Enjoy!
 
   [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
   ```
@@ -396,25 +428,23 @@ sudo kubeadm upgrade apply
 {{< tabs name="k8s_install_kubelet" >}}
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
 ```shell
-# 用最新的补丁版本替换 1.18.x-00 中的 x
+# 用最新的补丁版本替换 1.19.x-00 中的 x
 apt-mark unhold kubelet kubectl && \
-apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
+apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
 apt-mark hold kubelet kubectl
-```
 
-从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
+# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
 
-```shell
 apt-get update && \
-apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
 ```
 {{% /tab %}}
 {{% tab name="CentOS、RHEL 或 Fedora" %}}
 
-用最新的补丁版本替换 1.18.x-00 中的 x
+用最新的补丁版本替换 1.19.x-00 中的 x
 
 ```shell
-yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -437,7 +467,8 @@ without compromising the minimum required capacity for running your workloads.
 -->
 ## 升级工作节点
 
-工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，以不影响运行工作负载所需的最小容量。
+工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，
+以不影响运行工作负载所需的最小容量。
 
 <!--
 ### Upgrade kubeadm
@@ -453,33 +484,31 @@ without compromising the minimum required capacity for running your workloads.
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
 
 ```shell
-# 将 1.18.x-00 中的 x 替换为最新的补丁版本
+# 将 1.19.x-00 中的 x 替换为最新的补丁版本
 apt-mark unhold kubeadm && \
-apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
+apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
 apt-mark hold kubeadm
-```
 
-从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
+# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
 
-```shell
 apt-get update && \
-apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
+apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
 ```
 
 {{% /tab %}}
 {{% tab name="CentOS、RHEL 或 Fedora" %}}
 
 ```shell
-# 用最新的补丁版本替换 1.18.x-00 中的 x
-yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+# 用最新的补丁版本替换 1.19.x-00 中的 x
+yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
 ```
 {{% /tab %}}
 {{< /tabs >}}
 
 <!--
-### Cordon the node
+### Drain the node
 -->
-### 保护节点
+### 腾空节点
 
 <!--
 1.  Prepare the node for maintenance by marking it unschedulable and evicting the workloads. Run:
@@ -546,17 +575,15 @@ yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
 
 ```shell
-# 将 1.18.x-00 中的 x 替换为最新的补丁版本
+# 将 1.19.x-00 中的 x 替换为最新的补丁版本
 apt-mark unhold kubelet kubectl && \
-apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
+apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
 apt-mark hold kubelet kubectl
-```
 
-从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
+# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
 
-```
 apt-get update && \
-apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
 ```
 
 {{% /tab %}}
@@ -564,7 +591,7 @@ apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x
 
 ```shell
 # 将 1.18.x-00 中的 x 替换为最新的补丁版本
-yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
 ```
 
 {{% /tab %}}
@@ -680,6 +707,7 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
   - The control plane is healthy
 - Enforces the version skew policies.
 - Makes sure the control plane images are available or available to pull to the machine.
+- Generates replacements and/or uses user supplied overwrites if component configs require version upgrades.
 - Upgrades the control plane components or rollbacks if any of them fails to come up.
 - Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created.
 - Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days.
@@ -692,8 +720,9 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
   - API 服务器是可访问的
   - 所有节点处于 `Ready` 状态
   - 控制面是健康的
-- 强制执行版本 skew 策略。
+- 强制执行版本偏差策略。
 - 确保控制面的镜像是可用的或可拉取到服务器上。
+- 如果组件配置要求版本升级，则生成替代配置与/或使用用户提供的覆盖版本配置。
 - 升级控制面组件或回滚（如果其中任何一个组件无法启动）。
 - 应用新的 `kube-dns` 和 `kube-proxy` 清单，并强制创建所有必需的 RBAC 规则。
 - 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。
@@ -717,6 +746,8 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
 
 - Fetches the kubeadm `ClusterConfiguration` from the cluster.
 - Upgrades the kubelet configuration for this node.
+- Upgrades the static Pod manifests for the control plane components.
+- Upgrades the kubelet configuration for this node.
 -->
 `kubeadm upgrade node` 在工作节点上完成以下工作：
 
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/zh/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
new file mode 100644
index 0000000000..5570285f3b
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
@@ -0,0 +1,173 @@
+---
+title: 升级 Windows 节点
+min-kubernetes-server-version: 1.17
+content_type: task
+weight: 40
+---
+<!--
+title: Upgrading Windows nodes
+min-kubernetes-server-version: 1.17
+content_type: task
+weight: 40
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+<!--
+This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes).
+-->
+本页解释如何升级[用 kubeadm 创建的](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)
+Windows 节点。
+
+## {{% heading "prerequisites" %}}
+ 
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!--
+* Familiarize yourself with [the process for upgrading the rest of your kubeadm
+cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to
+upgrade the control plane nodes before upgrading your Windows nodes.
+-->
+* 熟悉[更新 kubeadm 集群中的其余组件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)。
+  在升级你的 Windows 节点之前你会想要升级控制面节点。
+
+<!-- steps -->
+<!--
+## Upgrading worker nodes
+
+### Upgrade kubeadm
+-->
+## 升级工作节点   {#upgrading-worker-nodes}
+
+### 升级 kubeadm    {#upgrade-kubeadm}
+
+<!--
+1.  From the Windows node, upgrade kubeadm:
+
+    ```powershell
+    # replace {{< param "fullversion" >}} with your desired version
+    curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
+    ```
+-->
+1. 在 Windows 节点上升级 kubeadm：
+
+   ```powershell
+   # 将 {{< param "fullversion" >}} 替换为你希望的版本
+   curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
+   ```
+
+<!--
+### Drain the node
+
+1.  From a machine with access to the Kubernetes API,
+    prepare the node for maintenance by marking it unschedulable and evicting the workloads:
+
+    ```shell
+    # replace <node-to-drain> with the name of your node you are draining
+    kubectl drain <node-to-drain> -ignore-daemonsets
+    ```
+
+    You should see output similar to this:
+
+    ```
+    node/ip-172-31-85-18 cordoned
+    node/ip-172-31-85-18 drained
+    ```
+-->
+### 腾空节点   {#drain-the-node}
+
+1. 在一个能访问到 Kubernetes API 的机器上，将 Windows 节点标记为不可调度并
+   驱逐其上的所有负载，以便准备节点维护操作：
+
+   ```shell
+   # 将 <要腾空的节点> 替换为你要腾空的节点的名称
+   kubectl drain <要腾空的节点> -ignore-daemonsets
+   ```
+
+   你应该会看到类似下面的输出：
+
+   ```
+   node/ip-172-31-85-18 cordoned
+   node/ip-172-31-85-18 drained
+   ```
+
+<!--
+### Upgrade the kubelet configuration
+
+1.  From the Windows node, call the following command to sync new kubelet configuration:
+
+    ```powershell
+    kubeadm upgrade node
+    ```
+-->
+### 升级 kubelet 配置   {#upgrade-the-kubelet-configuration}
+
+1. 在 Windows 节点上，执行下面的命令来同步新的 kubelet 配置：
+
+   ```powershell
+   kubeadm upgrade node
+   ```
+
+<!--
+### Upgrade kubelet
+
+1.  From the Windows node, upgrade and restart the kubelet:
+
+    ```powershell
+    stop-service kubelet
+    curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
+    restart-service kubelet
+    ```
+-->
+### 升级 kubelet   {#upgrade-kubelet}
+
+1. 在 Windows 节点上升级并重启 kubelet：
+
+   ```powershell
+   stop-service kubelet
+   curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
+   restart-service kubelet
+   ```
+
+<!--
+### Uncordon the node
+
+1.  From a machine with access to the Kubernetes API,
+bring the node back online by marking it schedulable:
+
+    ```shell
+    # replace <node-to-drain> with the name of your node
+    kubectl uncordon <node-to-drain>
+    ```
+-->
+### 对节点执行 uncordon 操作   {#uncordon-the-node}
+
+1. 从一台能够访问到 Kubernetes API 的机器上，通过将节点标记为可调度，使之
+   重新上线：
+
+   ```shell
+   # 将 <要腾空的节点> 替换为你的节点名称
+   kubectl uncordon <要腾空的节点>
+   ```
+
+<!--
+### Upgrade kube-proxy
+
+1. From a machine with access to the Kubernetes API, run the following,
+again replacing {{< param "fullversion" >}} with your desired version:
+
+    ```shell
+    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
+    ```
+-->
+### 升级 kube-proxy   {#upgrade-kube-proxy}
+
+1. 在一台可访问 Kubernetes API 的机器上和，将 {{< param "fullversion" >}} 替换成你
+   期望的版本后再次执行下面的命令：
+
+   ```shell
+   curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
+    ```
+
diff --git a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
index db84fcae80..7fbf132dcf 100644
--- a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -397,9 +397,7 @@ Production likes to run cattle, so let's create some cattle pods.
 生产环境需要以放牛的方式运维，让我们创建一些名为 `cattle` 的 Pod。
 
 ```shell
-kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname
-kubectl scale deployment cattle --replicas=5
-
+kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname --replicas=5
 kubectl get deployment
 ```
 
diff --git a/content/zh/docs/tasks/administer-cluster/namespaces.md b/content/zh/docs/tasks/administer-cluster/namespaces.md
index 9c5ce28310..fe82f0cbdc 100644
--- a/content/zh/docs/tasks/administer-cluster/namespaces.md
+++ b/content/zh/docs/tasks/administer-cluster/namespaces.md
@@ -1,44 +1,40 @@
 ---
-reviewers:
-- derekwaynecarr
-- janetkuo
-title: 通过命名空间共享集群
+title: 通过名字空间共享集群
 content_type: task
 ---
-<!-- ---
+<!--
 reviewers:
 - derekwaynecarr
 - janetkuo
 title: Share a Cluster with Namespaces
 content_type: task
---- -->
+-->
 
 <!-- overview -->
-<!-- This page shows how to view, work in, and delete {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. The page also shows how to use Kubernetes namespaces to subdivide your cluster. -->
-
-本页展示了如何查看、使用和删除{{< glossary_tooltip text="namespaces" term_id="namespace" >}}。本页同时展示了如何使用 Kubernetes 命名空间去细分集群。
-
-
+<!--
+This page shows how to view, work in, and delete {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. The page also shows how to use Kubernetes namespaces to subdivide your cluster.
+-->
+本页展示如何查看、使用和删除{{< glossary_tooltip text="名字空间" term_id="namespace" >}}。
+本页同时展示如何使用 Kubernetes 名字空间来划分集群。
 
 ## {{% heading "prerequisites" %}}
 
-<!-- * Have an [existing Kubernetes cluster](/docs/setup/).
-* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. -->
-
-* 您已拥有一个 [配置好的 Kubernetes 集群](/docs/setup/).
-* 您已对 Kubernetes 的 _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, 和 _[Deployments](/docs/concepts/workloads/controllers/deployment/)_ 有基本理解。
-
-
+<!--
+* Have an [existing Kubernetes cluster](/docs/setup/).
+* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+-->
+* 你已拥有一个[配置好的 Kubernetes 集群](/zh/docs/setup/).
+* 你已对 Kubernetes 的 _[Pods](/zh/docs/concepts/workloads/pods/)_, 
+  _[Services](/zh/docs/concepts/services-networking/service/)_, 和
+  _[Deployments](/zh/docs/concepts/workloads/controllers/deployment/)_ 有基本理解。
 
 <!-- steps -->
 
 <!-- ## Viewing namespaces -->
-
-## 查看命名空间
+## 查看名字空间
 
 <!-- 1. List the current namespaces in a cluster using: -->
-
-1. 列出集群中现有的命名空间：
+1. 列出集群中现有的名字空间：
 
 ```shell
 kubectl get namespaces
@@ -51,32 +47,31 @@ kube-public   Active    11d
 ```
 
 <!-- Kubernetes starts with three initial namespaces: -->
-
 初始状态下，Kubernetes 具有三个名字空间：
 
-<!--    * `default` The default namespace for objects with no other namespace
-   * `kube-system` The namespace for objects created by the Kubernetes system
-   * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. -->
+<!--
+* `default` The default namespace for objects with no other namespace
+* `kube-system` The namespace for objects created by the Kubernetes system
+* `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. -->
 
-   * `default` 无命名空间对象的默认命名空间
-   * `kube-system` 由 Kubernetes 系统创建的对象的命名空间
-   * `kube-public` 自动创建且被所有用户可读的命名空间（包括未经身份认证的）。此命名空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此命名空间的公共方面只是一个约定，而不是一个必要条件。
+* `default` 无名字空间对象的默认名字空间
+* `kube-system` 由 Kubernetes 系统创建的对象的名字空间
+* `kube-public` 自动创建且被所有用户可读的名字空间（包括未经身份认证的）。此名字空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此名字空间的公共方面只是一个约定，而不是一个必要条件。
 
 <!-- You can also get the summary of a specific namespace using: -->
-
-您还可以通过下列命令获取特定命名空间的摘要：
+你还可以通过下列命令获取特定名字空间的摘要：
 
 ```shell
 kubectl get namespaces <name>
 ```
 
 <!-- Or you can get detailed information with: -->
-
-或获取详细信息：
+或用下面的命令获取详细信息：
 
 ```shell
 kubectl describe namespaces <name>
 ```
+
 ```
 Name:           default
 Labels:         <none>
@@ -92,12 +87,10 @@ Resource Limits
 ```
 
 <!-- Note that these details show both resource quota (if present) as well as resource limit ranges. -->
-
 请注意，这些详情同时显示了资源配额（如果存在）以及资源限制区间。
 
 <!-- Resource quota tracks aggregate usage of resources in the *Namespace* and allows cluster operators
 to define *Hard* resource usage limits that a *Namespace* may consume. -->
-
 资源配额跟踪并聚合 *Namespace* 中资源的使用情况，并允许集群运营者定义 *Namespace* 可能消耗的 *Hard* 资源使用限制。
 
 <!-- A limit range defines min/max constraints on the amount of resources a single entity can consume in
@@ -109,428 +102,366 @@ See [Admission control: Limit Range](https://git.k8s.io/community/contributors/d
 
 参阅 [准入控制: 限制区间](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
 
-<!-- A namespace can be in one of two phases:
+<!--
+A namespace can be in one of two phases:
 
-   * `Active` the namespace is in use
-   * `Terminating` the namespace is being deleted, and can not be used for new objects
+* `Active` the namespace is in use
+* `Terminating` the namespace is being deleted, and can not be used for new objects
 
 See the [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) for more details. -->
 
-命名空间可以处于下列两个阶段中的一个:
+名字空间可以处于下列两个阶段中的一个:
 
-   * `Active` 命名空间使用中
-   * `Terminating` 命名空间正在被删除，且不能被用于新对象。
+* `Active` 名字空间正在被使用中
+* `Terminating` 名字空间正在被删除，且不能被用于新对象。
 
-参见 [设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) 查看更多细节。
+参见[设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) 查看更多细节。
 
 <!-- ## Creating a new namespace -->
-
-## 创建命名空间
+## 创建名字空间
 
 <!--
 Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
 -->
 {{< note >}}
-避免使用前缀 `kube-` 创建命名空间，因为它是为 Kubernetes 系统命名空间保留的。
+避免使用前缀 `kube-` 创建名字空间，因为它是为 Kubernetes 系统名字空间保留的。
 {{< /note >}}
 
 <!-- 1. Create a new YAML file called `my-namespace.yaml` with the contents: -->
-
 1. 新建一个名为 `my-namespace.yaml` 的 YAML 文件，并写入下列内容：
 
+   ```yaml
+   apiVersion: v1
+   kind: Namespace
+   metadata:
+     name: <insert-namespace-name-here>
+   ```
 
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
-  name: <insert-namespace-name-here>
-```
+   <!-- Then run: -->
+   然后运行：
 
-<!--
-Then run:
--->
-然后运行：
-
-```
-kubectl create -f ./my-namespace.yaml
-```
+   ```shell
+   kubectl create -f ./my-namespace.yaml
+   ```
 
 <!--
 2. Alternatively, you can create namespace using below command:
 -->
-2. 或者，你可以使用下面的命令创建命名空间：
+2. 或者，你可以使用下面的命令创建名字空间：
 
    ```
    kubectl create namespace <insert-namespace-name-here>
    ```
 
-<!-- Note that the name of your namespace must be a DNS compatible label. -->
+<!--
+The name of your namespace must be a valid
+[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).
+-->
+请注意，名字空间的名称必须是一个合法的
+[DNS 标签](/zh/docs/concepts/overview/working-with-objects/names#dns-label-names)。
 
-请注意，命名空间的名称必须是 DNS 兼容的标签。
+<!--
+There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
 
-<!-- There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
+More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers).
+-->
+可选字段 `finalizers` 允许观察者们在名字空间被删除时清除资源。记住如果指定了一个不存在的终结器，名字空间仍会被创建，但如果用户试图删除它，它将陷入 `Terminating` 状态。
 
-More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers). -->
-
-可选字段 `finalizers` 允许观察者们在命名空间被删除时清除资源。记住如果指定了一个不存在的终结器，命名空间仍会被创建，但如果用户试图删除它，它将陷入 `Terminating` 状态。
-
-更多有关 `finalizers` 的信息请查阅 [设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) 中命名空间部分。
+更多有关 `finalizers` 的信息请查阅 [设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) 中名字空间部分。
 
 <!-- ## Deleting a namespace -->
+## 删除名字空间
 
-## 删除命名空间
-
-<!-- 1. Delete a namespace with -->
-
-1. 删除命名空间使用命令
+<!--
+Delete a namespace with
+-->
+删除名字空间使用命令：
 
 ```shell
 kubectl delete namespaces <insert-some-namespace-name>
 ```
 
-{{< warning >}}
 <!-- This deletes _everything_ under the namespace! -->
-
-这会删除命名空间下的 _所有内容_ ！
-
+{{< warning >}}
+这会删除名字空间下的 _所有内容_ ！
 {{< /warning >}}
 
 <!-- This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state. -->
+删除是异步的，所以有一段时间你会看到名字空间处于 `Terminating` 状态。
 
-删除是异步的,所以有一段时间你会看到命名空间处于 `Terminating` 状态。
+<!--
+## Subdividing your cluster using Kubernetes namespaces
+-->
+## 使用 Kubernetes 名字空间细分你的集群
 
-<!-- ## Subdividing your cluster using Kubernetes namespaces -->
+<!--
+1. Understand the default namespace
 
-## 使用 Kubernetes 命名空间细分您的集群
+   By default, a Kubernetes cluster will instantiate a default namespace when provisioning
+   the cluster to hold the default set of Pods, Services, and Deployments used by the cluster.
+-->
 
-<!-- 1. Understand the default namespace
+1. 理解 default 名字空间
 
-By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods,
-Services, and Deployments used by the cluster. -->
+   默认情况下，Kubernetes 集群会在配置集群时实例化一个 default 名字空间，用以存放集群所使用的默认
+   Pods、Services 和 Deployments 集合。
 
-1. 理解默认命名空间
+   <!--
+   Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
+   -->
 
-默认情况下，Kubernetes 集群会在配置集群时实例化一个默认命名空间，用以存放集群所使用的默认 Pods、Services 和 Deployments 集合。
+   假设你有一个新的集群，你可以通过执行以下操作来内省可用的名字空间
 
-<!-- Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following: -->
+   ```shell
+   kubectl get namespaces
+   ```
+   ```
+   NAME      STATUS    AGE
+   default   Active    13m
+   ```
 
-假设您有一个新的集群，您可以通过执行以下操作来内省可用的命名空间
+<!--
+2. Create new namespaces
+-->
+2. 创建新的名字空间
 
-```shell
-kubectl get namespaces
-```
-```
-NAME      STATUS    AGE
-default   Active    13m
-```
+   <!--
+   For this exercise, we will create two additional Kubernetes namespaces to hold our content.
+   -->
+   在本练习中，我们将创建两个额外的 Kubernetes 名字空间来保存我们的内容。
 
-<!-- 2. Create new namespaces -->
+   <!--
+   In a scenario where an organization is using a shared Kubernetes cluster for development and
+   production use cases:
+   -->
+   在某组织使用共享的 Kubernetes 集群进行开发和生产的场景中：
 
-2. 创建新的命名空间
+   <!--
+   The development team would like to maintain a space in the cluster where they can
+   get a view on the list of Pods, Services, and Deployments
+   they use to build and run their application.  In this space, Kubernetes resources come
+   and go, and the restrictions on who can or cannot modify resources
+   are relaxed to enable agile development.
+   -->
+   开发团队希望在集群中维护一个空间，以便他们可以查看用于构建和运行其应用程序的 Pods、Services
+   和 Deployments 列表。在这个空间里，Kubernetes 资源被自由地加入或移除，
+   对谁能够或不能修改资源的限制被放宽，以实现敏捷开发。
+   
+   <!--
+   The operations team would like to maintain a space in the cluster where they can enforce
+   strict procedures on who can or cannot manipulate the set of
+   Pods, Services, and Deployments that run the production site.
+   -->
+   运维团队希望在集群中维护一个空间，以便他们可以强制实施一些严格的规程，
+   对谁可以或不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。
+   
+   <!--
+   One pattern this organization could follow is to partition the Kubernetes cluster into
+   two namespaces: `development` and `production`.
+   -->
+   该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间：development 和 production。
+   
+   <!-- Let's create two new namespaces to hold our work. -->
+   让我们创建两个新的名字空间来保存我们的工作。
+   
+   <!-- Create the `development` namespace using kubectl. -->
+   使用 kubectl 创建 `development` 名字空间。
+   
+   ```shell
+   kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
+   ```
 
-<!-- For this exercise, we will create two additional Kubernetes namespaces to hold our content. -->
+   <!-- And then let's create the `production` namespace using kubectl. -->
+   让我们使用 kubectl 创建 `production` 名字空间。
 
-在本练习中，我们将创建两个额外的 Kubernetes 命名空间来保存我们的内容。
+   ```shell
+   kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
+   ```
 
-<!-- In a scenario where an organization is using a shared Kubernetes cluster for development and production use cases: -->
+   <!-- To be sure things are right, list all of the namespaces in our cluster. -->
+   为了确保一切正常，列出集群中的所有名字空间。
 
-在某组织使用共享的 Kubernetes 集群进行开发和生产的场景中：
-
-<!-- The development team would like to maintain a space in the cluster where they can get a view on the list of Pods, Services, and Deployments
-they use to build and run their application.  In this space, Kubernetes resources come and go, and the restrictions on who can or cannot modify resources
-are relaxed to enable agile development. -->
-
-开发团队希望在集群中维护一个空间，以便他们可以查看用于构建和运行其应用程序的 Pods、Services 和 Deployments 列表。在这个空间里，Kubernetes 资源被自由地加入或移除，对谁能够或不能修改资源的限制被放宽，以实现敏捷开发。
-
-<!-- The operations team would like to maintain a space in the cluster where they can enforce strict procedures on who can or cannot manipulate the set of
-Pods, Services, and Deployments that run the production site. -->
-
-运维团队希望在集群中维护一个空间，以便他们可以强制实施一些严格的规程，对谁可以或不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。
-
-<!-- One pattern this organization could follow is to partition the Kubernetes cluster into two namespaces: `development` and `production`. -->
-
-该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个命名空间：development 和 production。
-
-<!-- Let's create two new namespaces to hold our work. -->
-
-让我们创建两个新的命名空间来保存我们的工作。
-
-<!-- Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a `development` namespace: -->
-
-文件 [`namespace-dev.json`](/examples/admin/namespace-dev.json) 描述了 development 命名空间:
-
-{{< codenew language="json" file="admin/namespace-dev.json" >}}
-
-<!-- Create the `development` namespace using kubectl. -->
-
-使用 kubectl 创建 `development` 命名空间。
-
-```shell
-kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
-```
-
-<!-- And then let's create the `production` namespace using kubectl. -->
-
-让我们使用 kubectl 创建 `production` 命名空间。
-
-```shell
-kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
-```
-
-<!-- To be sure things are right, list all of the namespaces in our cluster. -->
-
-为了确保一切正常，列出集群中的所有命名空间。
-
-```shell
-kubectl get namespaces --show-labels
-```
-```
-NAME          STATUS    AGE       LABELS
-default       Active    32m       <none>
-development   Active    29s       name=development
-production    Active    23s       name=production
-```
+   ```shell
+   kubectl get namespaces --show-labels
+   ```
+   ```
+   NAME          STATUS    AGE       LABELS
+   default       Active    32m       <none>
+   development   Active    29s       name=development
+   production    Active    23s       name=production
+   ```
 
 <!-- 3. Create pods in each namespace -->
+3. 在每个名字空间中创建 pod
 
-3. 在每个命名空间中创建 pod
+   <!--
+   A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
 
-<!-- A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
+   Users interacting with one namespace do not see the content in another namespace.
+   -->
+   Kubernetes 名字空间为集群中的 Pods、Services 和 Deployments 提供了作用域。
+   
+   与一个名字空间交互的用户不会看到另一个名字空间中的内容。
+   
+   <!-- To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace. -->
+   为了演示这一点，让我们在 `development` 名字空间中启动一个简单的 Deployment 和 Pod。
 
-Users interacting with one namespace do not see the content in another namespace. -->
+   ```shell
+   kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development
+   kubectl scale deployment snowflake --replicas=2 -n=development
+   ```
 
-Kubernetes 命名空间为集群中的 Pods、Services 和 Deployments 提供了作用域。
+   <!--
+   We have just created a deployment whose replica size is 2 that is running the pod
+   called `snowflake` with a basic container that just serves the hostname.
+   -->
+   我们刚刚创建了一个副本个数为 2 的 Deployment，运行名为 `snowflake` 的
+   Pod，其中包含一个仅负责提供主机名的基本容器。
 
-与一个命名空间交互的用户不会看到另一个命名空间中的内容。
+   ```shell
+   kubectl get deployment -n=development
+   ```
+   ```
+   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+   snowflake    2/2     2            2           2m
+   ```
+   ```shell
+   kubectl get pods -l app=snowflake -n=development
+   ```
+   ```
+   NAME                         READY     STATUS    RESTARTS   AGE
+   snowflake-3968820950-9dgr8   1/1       Running   0          2m
+   snowflake-3968820950-vgc4n   1/1       Running   0          2m
+   ```
 
-<!-- To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace. -->
+   <!--
+   And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the `production` namespace.
 
-为了演示这一点，让我们在 `development` 命名空间中启动一个简单的 Deployment 和 Pod。
+   Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
 
-<!-- We first check what is the current context: -->
+   The `production` namespace should be empty, and the following commands should return nothing.
+   -->
+   看起来还不错，开发人员能够做他们想做的事，而且他们不必担心会影响到
+   `production` 名字空间下面的内容。
 
-我们首先检查一下当前的上下文：
+   让我们切换到 `production` 名字空间，展示一下一个名字空间中的资源是如何对
+   另一个名字空间隐藏的。
 
-```shell
-kubectl config view
-```
-```yaml
-apiVersion: v1
-clusters:
-- cluster:
-    certificate-authority-data: REDACTED
-    server: https://130.211.122.180
-  name: lithe-cocoa-92103_kubernetes
-contexts:
-- context:
-    cluster: lithe-cocoa-92103_kubernetes
-    user: lithe-cocoa-92103_kubernetes
-  name: lithe-cocoa-92103_kubernetes
-current-context: lithe-cocoa-92103_kubernetes
-kind: Config
-preferences: {}
-users:
-- name: lithe-cocoa-92103_kubernetes
-  user:
-    client-certificate-data: REDACTED
-    client-key-data: REDACTED
-    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
-- name: lithe-cocoa-92103_kubernetes-basic-auth
-  user:
-    password: h5M0FtUUIflBSdI7
-    username: admin
-```
+   名字空间 `production` 应该是空的，下面的命令应该不会返回任何东西。
 
-```shell
-kubectl config current-context
-```
-```
-lithe-cocoa-92103_kubernetes
-```
+   ```shell
+   kubectl get deployment -n=production
+   kubectl get pods -n=production
+   ```
 
-<!-- The next step is to define a context for the kubectl client to work in each namespace. The values of "cluster" and "user" fields are copied from the current context. -->
+   <!--
+   Production likes to run cattle, so let's create some cattle pods.
+   -->
+   生产环境下一般以养牛的方式运行负载，所以让我们创建一些 Cattle（牛）Pod。
 
-下一步是为 kubectl 客户端定义一个上下文，以便在每个命名空间中工作。"cluster" 和 "user" 字段的值将从当前上下文中复制。
+   ```shell
+   kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
+   kubectl scale deployment cattle --replicas=5 -n=production
 
-```shell
-kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
-kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
-```
+   kubectl get deployment -n=production
+   ```
+   ```
+   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+   cattle       5/5     5            5           10s
+   ```
 
-<!-- The above commands provided two request contexts you can alternate against depending on what namespace you
-wish to work against. -->
-
-上述命令提供了两个可以替代的请求上下文，具体取决于您希望使用的命名空间。
-
-<!-- Let's switch to operate in the `development` namespace. -->
-
-让我们切换到 `development` 命名空间进行操作。
-
-```shell
-kubectl config use-context dev
-```
-
-<!-- You can verify your current context by doing the following: -->
-
-您可以使用下列命令验证当前上下文：
-
-```shell
-kubectl config current-context
-dev
-```
-
-<!-- At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the `development` namespace. -->
-
-此时，我们从命令行向 Kubernetes 集群发出的所有请求都限定在 `development` 命名空间中。
-
-<!-- Let's create some contents. -->
-
-让我们创建一些内容。
-
-```shell
-kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2
-```
-<!-- We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
-Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
-If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details. -->
-
-我们刚刚创建了一个副本大小为 2 的 deployment，该 deployment 运行名为 snowflake 的 pod，其中包含一个仅提供主机名服务的基本容器。请注意，`kubectl run` 仅在 Kubernetes 集群版本 >= v1.2 时创建 deployment。如果您运行在旧版本上，则会创建 replication controllers。如果期望执行旧版本的行为，请使用 `--generator=run/v1` 创建 replication controllers。 参见 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 获取更多细节。
-
-```shell
-kubectl get deployment
-```
-```
-NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-snowflake   2         2         2            2           2m
-```
-```shell
-kubectl get pods -l run=snowflake
-```
-```
-NAME                         READY     STATUS    RESTARTS   AGE
-snowflake-3968820950-9dgr8   1/1       Running   0          2m
-snowflake-3968820950-vgc4n   1/1       Running   0          2m
-```
-
-<!-- And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the `production` namespace. -->
-
-这很棒，开发人员可以做他们想要的事情，而不必担心影响 `production` 命名空间中的内容。
-
-<!-- Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other. -->
-
-让我们切换到 `production` 命名空间，展示一个命名空间中的资源如何对另一个命名空间不可见。
-
-```shell
-kubectl config use-context prod
-```
-
-<!-- The `production` namespace should be empty, and the following commands should return nothing. -->
-
-`production` 命名空间应该是空的，下列命令应该返回的内容为空。
-
-```shell
-kubectl get deployment
-kubectl get pods
-```
-
-<!-- Production likes to run cattle, so let's create some cattle pods. -->
-
-生产环境需要运行 cattle，让我们创建一些名为 cattle 的 pods。
-
-```shell
-kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5
-
-kubectl get deployment
-```
-```
-NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-cattle    5         5         5            5           10s
-```
-
-```shell
-kubectl get pods -l run=cattle
-```
-```
-NAME                      READY     STATUS    RESTARTS   AGE
-cattle-2263376956-41xy6   1/1       Running   0          34s
-cattle-2263376956-kw466   1/1       Running   0          34s
-cattle-2263376956-n4v97   1/1       Running   0          34s
-cattle-2263376956-p5p3i   1/1       Running   0          34s
-cattle-2263376956-sxpth   1/1       Running   0          34s
-```
-
-<!-- At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace. -->
-
-此时，应该很清楚的展示了用户在一个命名空间中创建的资源对另一个命名空间是隐藏的。
-
-<!-- As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
-authorization rules for each namespace. -->
-
-随着 Kubernetes 中的策略支持的发展，我们将扩展此场景，以展示如何为每个命名空间提供不同的授权规则。
+   ```shell
+   kubectl get pods -l app=cattle -n=production
+   ```
+   ```
+   NAME                      READY     STATUS    RESTARTS   AGE
+   cattle-2263376956-41xy6   1/1       Running   0          34s
+   cattle-2263376956-kw466   1/1       Running   0          34s
+   cattle-2263376956-n4v97   1/1       Running   0          34s
+   cattle-2263376956-p5p3i   1/1       Running   0          34s
+   cattle-2263376956-sxpth   1/1       Running   0          34s
+   ```
 
+<!--
+At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace.
+-->
+此时，应该很清楚的展示了用户在一个名字空间中创建的资源对另一个名字空间是隐藏的。
 
+<!--
+As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
+authorization rules for each namespace.
+-->
+随着 Kubernetes 中的策略支持的发展，我们将扩展此场景，以展示如何为每个名字空间提供不同的授权规则。
 
 <!-- discussion -->
 
-<!-- ## Understanding the motivation for using namespaces -->
-
-## 理解使用命名空间的动机
-
-<!-- A single cluster should be able to satisfy the needs of multiple users or groups of users (henceforth a 'user community'). -->
+<!--
+## Understanding the motivation for using namespaces
+-->
+## 理解使用名字空间的动机
 
+<!--
+A single cluster should be able to satisfy the needs of multiple users or groups of users (henceforth a 'user community').
+-->
 单个集群应该能满足多个用户及用户组的需求（以下称为 “用户社区”）。
 
 <!-- Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster. -->
+Kubernetes _名字空间_ 帮助不同的项目、团队或客户去共享 Kubernetes 集群。
 
-Kubernetes _命名空间_ 帮助不同的项目、团队或客户去共享 Kubernetes 集群。
-
-<!-- It does this by providing the following:
+<!--
+It does this by providing the following:
 
 1. A scope for [Names](/docs/concepts/overview/working-with-objects/names/).
-2. A mechanism to attach authorization and policy to a subsection of the cluster. -->
-
+2. A mechanism to attach authorization and policy to a subsection of the cluster.
+-->
 名字空间通过以下方式实现这点：
 
-1. 为[名字](/docs/concepts/overview/working-with-objects/names/)设置作用域.
+1. 为[名字](/zh/docs/concepts/overview/working-with-objects/names/)设置作用域.
 2. 为集群中的部分资源关联鉴权和策略的机制。
 
-<!-- Use of multiple namespaces is optional. -->
-
-使用多个命名空间是可选的。
-
-<!-- Each user community wants to be able to work in isolation from other communities. -->
+<!--
+Use of multiple namespaces is optional.
+-->
+使用多个名字空间是可选的。
 
+<!--
+Each user community wants to be able to work in isolation from other communities.
+-->
 每个用户社区都希望能够与其他社区隔离开展工作。
 
-<!-- Each user community has its own:
+<!--
+Each user community has its own:
 
 1. resources (pods, services, replication controllers, etc.)
 2. policies (who can or cannot perform actions in their community)
-3. constraints (this community is allowed this much quota, etc.) -->
+3. constraints (this community is allowed this much quota, etc.)
+-->
+每个用户社区都有自己的：
 
-每个用户社区都有:
-
-1. 资源（pods, services, replication controllers, 等等）
+1. 资源（pods、服务、 副本控制器等等）
 2. 策略（谁能或不能在他们的社区里执行操作）
 3. 约束（该社区允许多少配额，等等）
 
-<!-- A cluster operator may create a Namespace for each unique user community. -->
+<!--
+A cluster operator may create a Namespace for each unique user community.
+-->
+集群运营者可以为每个唯一用户社区创建名字空间。
 
-集群运营者可以为每个唯一用户社区创建命名空间。
-
-<!-- The Namespace provides a unique scope for:
+<!--
+The Namespace provides a unique scope for:
 
 1. named resources (to avoid basic naming collisions)
 2. delegated management authority to trusted users
-3. ability to limit community resource consumption -->
-
-命名空间为下列内容提供唯一的作用域：
+3. ability to limit community resource consumption
+-->
+名字空间为下列内容提供唯一的作用域：
 
 1. 命名资源（避免基本的命名冲突）
 2. 将管理权限委派给可信用户
 3. 限制社区资源消耗的能力
 
-<!-- Use cases include:
+<!--
+Use cases include:
 
 1.  As a cluster operator, I want to support multiple user communities on a single cluster.
 2.  As a cluster operator, I want to delegate authority to partitions of the cluster to trusted users
@@ -538,41 +469,44 @@ Kubernetes _命名空间_ 帮助不同的项目、团队或客户去共享 Kuber
 3.  As a cluster operator, I want to limit the amount of resources each community can consume in order
     to limit the impact to other communities using the cluster.
 4.  As a cluster user, I want to interact with resources that are pertinent to my user community in
-    isolation of what other user communities are doing on the cluster. -->
+    isolation of what other user communities are doing on the cluster.
+-->
 
 用例包括:
-
 1.  作为集群运营者, 我希望能在单个集群上支持多个用户社区。
 2.  作为集群运营者，我希望将集群分区的权限委派给这些社区中的受信任用户。
 3.  作为集群运营者，我希望能限定每个用户社区可使用的资源量，以限制对使用同一集群的其他用户社区的影响。
 4.  作为群集用户，我希望与我的用户社区相关的资源进行交互，而与其他用户社区在该集群上执行的操作无关。
 
-<!-- ## Understanding namespaces and DNS -->
+<!--
+## Understanding namespaces and DNS
+-->
+## 理解名字空间和 DNS
 
-## 理解命名空间和 DNS
-
-<!-- When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
+<!--
+When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
 This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
 that if a container just uses `<service-name>` it will resolve to the service which
 is local to a namespace.  This is useful for using the same configuration across
 multiple namespaces such as Development, Staging and Production.  If you want to reach
-across namespaces, you need to use the fully qualified domain name (FQDN). -->
-
-当您创建 [Service](/docs/concepts/services-networking/service/) 时，它会创建相应的 [DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。此条目的格式为 `<service-name>。<namespace-name> .svc.cluster.local`，这意味着如果容器只使用 `<service-name>`，它将解析为本地服务到命名空间。 这对于在多个命名空间（如开发，暂存和生产）中使用相同的配置非常有用。 如果要跨命名空间访问，则需要使用完全限定的域名（FQDN）。
-
-
+across namespaces, you need to use the fully qualified domain name (FQDN).
+-->
+当你创建[服务](/zh/docs/concepts/services-networking/service/)时，Kubernetes
+会创建相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。
+此条目的格式为 `<服务名称>.<名字空间名称>.svc.cluster.local`。
+这意味着如果容器只使用 `<服务名称>`，它将解析为名字空间本地的服务。
+这对于在多个名字空间（如开发、暂存和生产）中使用相同的配置非常有用。
+如果要跨名字空间访问，则需要使用完全限定的域名（FQDN）。
 
 ## {{% heading "whatsnext" %}}
 
-<!-- * Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
+<!--
+* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
 * Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
-* See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). -->
-
-
-* 了解更多 [设置命名空间首选项](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference) 的内容。
-* 了解更多 [设置请求的命名空间](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) 的内容。
-* 参见 [命名空间设计](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md)。
-
-
+* See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md).
+-->
 
+* 进一步了解[设置名字空间偏好](/zh/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference)
+* 进一步了解[设置请求的名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
+* 参阅[名字空间的设计文档](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md)
 
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index 5f2724bbad..8266031e0a 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -4,15 +4,24 @@ content_type: task
 weight: 20
 ---
 
+<!--
+reviewers:
+- danwent
+- aanm
+title: Use Cilium for NetworkPolicy
+content_type: task
+weight: 20
+-->
+
 <!-- overview -->
 <!--
 This page shows how to use Cilium for NetworkPolicy.
 
-For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro).
+For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.io/en/stable/intro).
 -->
 本页展示如何使用 Cilium 提供 NetworkPolicy。
 
-关于 Cilium 的背景知识，请阅读 [Cilium 介绍](https://cilium.readthedocs.io/en/latest/intro)。
+关于 Cilium 的背景知识，请阅读 [Cilium 介绍](https://docs.cilium.io/en/stable/intro)。
 
 ## {{% heading "prerequisites" %}}
 
@@ -86,7 +95,7 @@ deployment.apps/cilium-operator created
 The remainder of the Getting Started Guide explains how to enforce both L3/L4
 (i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
 policies using an example application.
- -->
+-->
 入门指南其余的部分用一个示例应用说明了如何强制执行 L3/L4（即 IP 地址+端口）的安全策略
 以及L7 （如 HTTP）的安全策略。
 
@@ -94,14 +103,14 @@ policies using an example application.
 ## Deploying Cilium for Production Use
 
 For detailed instructions around deploying Cilium for production, see:
-[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
+[Cilium Kubernetes Installation Guide](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)
 This documentation includes detailed requirements, instructions and example
 production DaemonSet files.
  -->
 ## 部署 Cilium 用于生产用途
 
 关于部署 Cilium 用于生产的详细说明，请见
-[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)，
+[Cilium Kubernetes 安装指南](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)
 此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。
 
 <!-- discussion -->
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
index ca64910989..50771fa68a 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -4,15 +4,27 @@ content_type: task
 weight: 40
 ---
 
+<!--
+reviewers:
+- chrismarino
+title: Romana for NetworkPolicy
+content_type: task
+weight: 40
+-->
+
 <!-- overview -->
 
-<!-- This page shows how to use Romana for NetworkPolicy. -->
+<!--
+This page shows how to use Romana for NetworkPolicy.
+-->
 本页展示如何使用 Romana 作为 NetworkPolicy。
 
 ## {{% heading "prerequisites" %}}
 
-<!-- Complete steps 1, 2, and 3 of  the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). -->
-完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)中的 1、2、3 步。
+<!--
+Complete steps 1, 2, and 3 of  the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
+-->
+完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)中的 1、2、3 步。
 
 <!-- steps -->
 <!--
@@ -30,14 +42,15 @@ To apply network policies use one of the following:
  -->
 ## 使用 kubeadm 安装 Romana
 
-按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)，使用 kubeadm 安装。
+按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)，
+使用 kubeadm 安装。
 
 ## 应用网络策略
 
 使用以下的一种方式应用网络策略：
 
 * [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
-    * [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
+  * [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
 * NetworkPolicy API
 
 ## {{% heading "whatsnext" %}}
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
index 251f28f7bf..02339cbc61 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -4,6 +4,14 @@ content_type: task
 weight: 50
 ---
 
+<!--
+reviewers:
+- bboreham
+title: Weave Net for NetworkPolicy
+content_type: task
+weight: 50
+-->
+
 <!-- overview -->
 
 <!--
@@ -14,10 +22,11 @@ This page shows how to use Weave Net for NetworkPolicy.
 ## {{% heading "prerequisites" %}}
 
 <!--
-You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
+You need to have a Kubernetes cluster. Follow the
+[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/) to bootstrap one.
  -->
 你需要拥有一个 Kubernetes 集群。按照
-[kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)
+[kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)
 来启动一个。
 
 
@@ -26,17 +35,20 @@ You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide
 <!--
 ## Install the Weave Net addon
 
-Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.
+Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) guide.
 
-The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
- -->
+The Weave Net addon for Kubernetes comes with a
+[Network Policy Controller](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)
+that automatically monitors Kubernetes for any NetworkPolicy annotations on all
+namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
+-->
 ## 安装 Weave Net 插件
 
-按照[通过插件集成 Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)
+按照[通过插件集成 Kubernetes](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)
 指南执行安装。
 
 Kubernetes 的 Weave Net 插件带有
-[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，
+[网络策略控制器](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)，
 可自动监控 Kubernetes 所有名字空间的 NetworkPolicy 注释，
 配置 `iptables` 规则以允许或阻止策略指示的流量。
 
diff --git a/content/zh/docs/tasks/administer-cluster/out-of-resource.md b/content/zh/docs/tasks/administer-cluster/out-of-resource.md
index 69dc7ae65b..f86beff12f 100644
--- a/content/zh/docs/tasks/administer-cluster/out-of-resource.md
+++ b/content/zh/docs/tasks/administer-cluster/out-of-resource.md
@@ -29,24 +29,6 @@ nodes become unstable.
 
 <!-- body -->
 
-<!--
-## Eviction Policy
-
-The `kubelet` can proactively monitor for and prevent total starvation of a
-compute resource. In those cases, the `kubelet` can reclaim the starved
-resource by proactively failing one or more Pods. When the `kubelet` fails
-a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
-
-If the evicted Pod is managed by a Deployment, the Deployment will create another Pod 
-to be scheduled by Kubernetes.
--->
-## 驱逐策略
-
-`kubelet` 能够主动监测和防止计算资源的全面短缺。
-在那种情况下，`kubelet` 可以主动地结束一个或多个 Pod 以回收短缺的资源。
-当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `PodPhase` 将变为 `Failed`。
-
-如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给 Kubernetes 来调度。
 
 <!--
 ### Eviction Signals
@@ -61,16 +43,16 @@ the `kubelet` summary API.
 每个信号的值在 description 列描述，基于 `kubelet` 摘要 API。
 
 <!--
-| Eviction Signal  | Description                                                                     |
-|----------------------------|-----------------------------------------------------------------------|
+| Eviction Signal            | Description                                                         |
+|----------------------------|---------------------------------------------------------------------|
 | `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
 | `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
 | `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
 | `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
 | `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
 -->
-| 驱逐信号  | 描述                                                                     |
-|----------------------------|-----------------------------------------------------------------------|
+| 驱逐信号                   | 描述                                                                |
+|----------------------------|---------------------------------------------------------------------|
 | `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
 | `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
 | `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
@@ -91,7 +73,7 @@ container, and if users use the [node
 allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
 are made local to the end user Pod part of the cgroup hierarchy as well as the
 root node. This
-[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
+[script](/examples/admin/resource/memory-available.sh)
 reproduces the same set of steps that the `kubelet` performs to calculate
 `memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
 file-backed memory on inactive LRU list) from its calculation as it assumes that
@@ -101,7 +83,7 @@ memory is reclaimable under pressure.
 这很重要，因为 `free -m` 不能在容器中工作，并且如果用户使用了
 [节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 特性，资源不足的判定将同时在本地 cgroup 层次结构的终端用户 Pod 部分和根节点做出。
-这个[脚本](/zh/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
+这个[脚本](/zh/examples/admin/resource/memory-available.sh)
 复现了与 `kubelet` 计算 `memory.available` 相同的步骤。
 `kubelet` 将 `inactive_file`（意即活动 LRU 列表上基于文件后端的内存字节数）从计算中排除，
 因为它假设内存在出现压力时将被回收。
@@ -131,7 +113,7 @@ support in favor of eviction in response to disk pressure.
 -->
 `imagefs` 可选。`kubelet` 使用 cAdvisor 自动发现这些文件系统。
 `kubelet` 不关心其它文件系统。当前不支持配置任何其它类型。
-例如，在专用 `filesytem` 中存储卷和日志是不可以的。
+例如，在专用 `filesytem` 中存储卷和日志是 _不可以_ 的。
 
 在将来的发布中，`kubelet`将废除当前存在的
 [垃圾回收](/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/)
diff --git a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
index 8e68d12845..104c845855 100644
--- a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
+++ b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -8,7 +8,6 @@ content_type: task
 min-kubernetes-server-version: 1.8
 ---
 <!--
----
 reviewers:
 - vishh
 - derekwaynecarr
@@ -16,7 +15,6 @@ reviewers:
 title: Reserve Compute Resources for System Daemons
 content_type: task
 min-kubernetes-server-version: 1.8
----
 -->
 
 <!-- overview -->
@@ -49,30 +47,15 @@ Your Kubernetes server must be at or later than version 1.17 to use
 the kubelet command line option `--reserved-cpus` to set an
 [explicitly reserved CPU list](#explicitly-reserved-cpu-list).
 -->
-您的 kubernetes 服务器版本必须至少是 1.17 版本，才能使用 kubelet 命令行选项 `--reserved-cpus` 来设置 [显式 CPU 保留列表](#explicitly-reserved-cpu-list)
+你的 kubernetes 服务器版本必须至少是 1.17 版本，才能使用 kubelet
+命令行选项 `--reserved-cpus` 设置
+[显式预留 CPU 列表](#explicitly-reserved-cpu-list)。
 
 <!-- steps -->
 
 <!--
 ## Node Allocatable
 
-```text
-      Node Capacity
----------------------------
-|     kube-reserved       |
-|-------------------------|
-|     system-reserved     |
-|-------------------------|
-|    eviction-threshold   |
-|-------------------------|
-|                         |
-|      allocatable        |
-|   (available for pods)  |
-|                         |
-|                         |
----------------------------
-```
-
 `Allocatable` on a Kubernetes node is defined as the amount of compute resources
 that are available for pods. The scheduler does not over-subscribe
 `Allocatable`. `CPU`, `memory` and `ephemeral-storage` are supported as of now.
@@ -82,29 +65,16 @@ of `kubectl describe node` in the CLI.
 
 Resources can be reserved for two categories of system daemons in the `kubelet`.
 -->
-## 可分配的节点
+## 节点可分配   {#node-allocatable}
 
-```text
-      Node Capacity
----------------------------
-|     kube-reserved       |
-|-------------------------|
-|     system-reserved     |
-|-------------------------|
-|    eviction-threshold   |
-|-------------------------|
-|                         |
-|      allocatable        |
-|   (available for pods)  |
-|                         |
-|                         |
----------------------------
-```
+![节点容量](/images/docs/node-capacity.svg)
 
-Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。调度器不会超额申请 `Allocatable`。
+Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。
+调度器不会超额申请 `Allocatable`。
 目前支持 `CPU`, `memory` 和 `ephemeral-storage` 这几个参数。
 
-可分配的节点暴露为 API 中 `v1.Node` 对象的一部分，也是 CLI 中 `kubectl describe node` 的一部分。
+可分配的节点暴露为 API 中 `v1.Node` 对象的一部分，也是 CLI 中
+`kubectl describe node` 的一部分。
 
 在 `kubelet` 中，可以为两类系统守护进程预留资源。
 
@@ -118,8 +88,9 @@ under a cgroup hierarchy managed by the `kubelet`.
 -->
 ### 启用 QoS 和 Pod 级别的 cgroups
 
-为了恰当的在节点范围实施 node allocatable，您必须通过 `--cgroups-per-qos` 标志启用新的 cgroup 层次结构。
-这个标志是默认启用的。启用后，`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 Pod。
+为了恰当的在节点范围实施节点可分配约束，你必须通过 `--cgroups-per-qos`
+标志启用新的 cgroup 层次结构。这个标志是默认启用的。
+启用后，`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 Pod。
 
 <!--
 ### Configuring a cgroup driver
@@ -143,15 +114,20 @@ be configured to use the `systemd` cgroup driver.
 -->
 ### 配置 cgroup 驱动
 
-`kubelet` 支持在主机上使用 cgroup 驱动操作 cgroup 层次结构。驱动通过 `--cgroup-driver` 标志配置。
+`kubelet` 支持在主机上使用 cgroup 驱动操作 cgroup 层次结构。
+驱动通过 `--cgroup-driver` 标志配置。
 
 支持的参数值如下：
 
-* `cgroupfs` 是默认的驱动，在主机上直接操作 cgroup 文件系统以对 cgroup 沙箱进行管理。
-* `systemd` 是可选的驱动，使用 init 系统支持的资源的瞬时切片管理 cgroup 沙箱。
+* `cgroupfs` 是默认的驱动，在主机上直接操作 cgroup 文件系统以对 cgroup
+  沙箱进行管理。
+* `systemd` 是可选的驱动，使用 init 系统支持的资源的瞬时切片管理
+  cgroup 沙箱。
 
-取决于相关容器运行时的配置，操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。
-例如如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时，必须配置 `kubelet` 使用 `systemd` cgroup 驱动。
+取决于相关容器运行时的配置，操作员可能需要选择一个特定的 cgroup 驱动
+来保证系统正常运行。
+例如，如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时，
+必须配置 `kubelet` 使用 `systemd` cgroup 驱动。
 
 <!--
 ### Kube Reserved
@@ -167,7 +143,21 @@ It is not meant to reserve resources for system daemons that are run as pods.
 In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
 specified to reserve the specified number of process IDs for
 kubernetes system daemons.
+-->
+### Kube 预留值  {#kube-reserved}
 
+- **Kubelet 标志**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
+- **Kubelet 标志**: `--kube-reserved-cgroup=`
+
+`kube-reserved` 用来给诸如 `kubelet`、容器运行时、节点问题监测器等
+kubernetes 系统守护进程记述其资源预留值。
+该配置并非用来给以 Pod 形式运行的系统守护进程保留资源。`kube-reserved`
+通常是节点上 `pod 密度` 的函数。
+
+除了 `cpu`，`内存` 和 `ephemeral-storage` 之外，`pid` 可用来指定为
+kubernetes 系统守护进程预留指定数量的进程 ID。
+
+<!--
 To optionally enforce `kube-reserved` on system daemons, specify the parent
 control group for kube daemons as the value for `--kube-reserved-cgroup` kubelet
 flag.
@@ -175,30 +165,24 @@ flag.
 It is recommended that the kubernetes system daemons are placed under a top
 level control group (`runtime.slice` on systemd machines for example). Each
 system daemon should ideally run within its own child control group. Refer to
-[this
-doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
+[this doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
 for more details on recommended control group hierarchy.
 
 Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
 exist. Kubelet will fail if an invalid cgroup is specified.
 -->
-### Kube 预留值
+要选择性地对系统守护进程上执行 `kube-reserved` 保护，需要把 kubelet 的
+`--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。
 
-- **Kubelet Flag**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
-- **Kubelet Flag**: `--kube-reserved-cgroup=`
-
-`kube-reserved` 是为了给诸如 `kubelet`、`container runtime`、`node problem detector` 等 kubernetes 系统守护进程争取资源预留。
-这并不代表要给以 pod 形式运行的系统守护进程保留资源。`kube-reserved` 通常是节点上的一个 `pod 密度` 功能。
-
-除了 `cpu`，`内存` 和 `ephemeral-storage` 之外，`pid` 可能是指定为 kubernetes 系统守护进程预留指定数量的进程 ID。
-
-要选择性的在系统守护进程上执行 `kube-reserved`，需要把 kubelet 的 `--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。
-
-推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的 `runtime.slice`）。
+推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的
+`runtime.slice`）。
 理想情况下每个系统守护进程都应该在其自己的子控制组中运行。
-请参考[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，获取更过关于推荐控制组层次结构的细节。
+请参考
+[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，
+进一步了解关于推荐控制组层次结构的细节。
 
-请注意，如果 `--kube-reserved-cgroup` 不存在，Kubelet 将**不会**创建它。如果指定了一个无效的 cgroup，Kubelet 将会失败。
+请注意，如果 `--kube-reserved-cgroup` 不存在，Kubelet 将 **不会** 创建它。
+如果指定了一个无效的 cgroup，Kubelet 将会失败。
 
 <!--
 ### System Reserved
@@ -216,7 +200,21 @@ systemd world).
 In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
 specified to reserve the specified number of process IDs for OS system
 daemons.
+-->
+### 系统预留值  {#system-reserved}
 
+- **Kubelet 标志**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
+- **Kubelet 标志**: `--system-reserved-cgroup=`
+
+`system-reserved` 用于为诸如 `sshd`、`udev` 等系统守护进程记述其资源预留值。
+`system-reserved` 也应该为 `kernel` 预留 `内存`，因为目前 `kernel`
+使用的内存并不记在 Kubernetes 的 Pod 上。
+同时还推荐为用户登录会话预留资源（systemd 体系中的 `user.slice`）。
+
+除了 `cpu`，`内存` 和 `ephemeral-storage` 之外，`pid` 可用来指定为
+kubernetes 系统守护进程预留指定数量的进程 ID。
+
+<!--
 To optionally enforce `system-reserved` on system daemons, specify the parent
 control group for OS system daemons as the value for `--system-reserved-cgroup`
 kubelet flag.
@@ -227,43 +225,41 @@ control group (`system.slice` on systemd machines for example).
 Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
 exist. Kubelet will fail if an invalid cgroup is specified.
 -->
-### 系统预留值
+要想为系统守护进程上可选地实施 `system-reserved` 约束，请指定 kubelet 的
+`--system-reserved-cgroup` 标志值为 OS 系统守护进程的父级控制组。
 
-- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
-- **Kubelet Flag**: `--system-reserved-cgroup=`
+推荐将 OS 系统守护进程放在一个顶级控制组之下（例如 systemd 机器上的
+`system.slice`）。
 
-`system-reserved` 用于为诸如 `sshd`、`udev` 等系统守护进程争取资源预留。
-`system-reserved` 也应该为 `kernel` 预留 `内存`，因为目前 `kernel` 使用的内存并不记在 Kubernetes 的 pod 上。
-同时还推荐为用户登录会话预留资源（systemd 体系中的 `user.slice`）。
-
-除了 `cpu`，`内存` 和 `ephemeral-storage` 之外，`pid` 可能是指定为 kubernetes 系统守护进程预留指定数量的进程 ID。
-
-要想在系统守护进程上可选地执行 `system-reserved`，请指定 `--system-reserved-cgroup` kubelet 标志的值为 OS 系统守护进程的父级控制组。
-
-推荐将 OS 系统守护进程放在一个顶级控制组之下（例如 systemd 机器上的 `system.slice`）。
-
-请注意，如果 `--system-reserved-cgroup` 不存在，Kubelet **不会**创建它。如果指定了无效的 cgroup，Kubelet 将会失败。
+请注意，如果 `--system-reserved-cgroup` 不存在，Kubelet **不会** 创建它。
+如果指定了无效的 cgroup，Kubelet 将会失败。
 
 <!--
 ### Explicitly Reserved CPU List
--->
-### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list}
-{{< feature-state for_k8s_version="v1.17" state="stable" >}}
 
 - **Kubelet Flag**: `--reserved-cpus=0-3`
+-->
+### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list}
+
+{{< feature-state for_k8s_version="v1.17" state="stable" >}}
+
+- **Kubelet 标志**: `--reserved-cpus=0-3`
 
 <!--
 `reserved-cpus` is meant to define an explicit CPU set for OS system daemons and
-kubernetes system daemons. This option is added in 1.17 release. `reserved-cpus`
-is for systems that do not intent to define separate top level cgroups for
-OS system daemons and kubernetes system daemons with regard to cpuset resource.
+kubernetes system daemons. `reserved-cpus` is for systems that do not intend to
+define separate top level cgroups for OS system daemons and kubernetes system daemons
+with regard to cpuset resource.
 If the Kubelet **does not** have `--system-reserved-cgroup` and `--kube-reserved-cgroup`,
 the explicit cpuset provided by `reserved-cpus` will take precedence over the CPUs
 defined by `--kube-reserved` and `--system-reserved` options.
 -->
-`reserved-cpus` 旨在为操作系统守护程序和 kubernetes 系统守护程序定义一个显式 cpuset。此选项在 kubernetes 1.17 版本中添加。
-`reserved-cpus` 适用于不打算针对 cpuset 资源为操作系统守护程序和 kubernetes 系统守护程序定义单独的顶级 cgroups 的系统。
-如果 Kubelet **没有** 指定参数 `--system-reserved-cgroup` 和 `--kube-reserved-cgroup`，则 `reserved-cpus` 提供的显式 cpuset 将优先于 `--kube-reserved` 和 `--system-reserved` 选项定义的 cpuset。
+`reserved-cpus` 旨在为操作系统守护程序和 kubernetes 系统守护程序定义一个显式 CPU
+集合。`reserved-cpus` 适用于不打算针对 cpuset 资源为操作系统守护程序和 kubernetes
+系统守护程序定义独立的顶级 cgroups 的系统。
+如果 Kubelet **没有** 指定参数 `--system-reserved-cgroup` 和 `--kube-reserved-cgroup`，
+则 `reserved-cpus` 提供的显式 cpuset 将优先于 `--kube-reserved` 和 `--system-reserved`
+选项定义的 cpuset。
 
 <!--
 This option is specifically designed for Telco/NFV use cases where uncontrolled
@@ -275,11 +271,13 @@ system daemon, kubernetes daemons and interrupts/timers to the explicit cpuset
 defined by this option, other mechanism outside Kubernetes should be used.
 For example: in Centos, you can do this using the tuned toolset.
 -->
-此选项是专门为 Telco 或 NFV 用例设计的，在这些用例中不受控制的中断或计时器可能会影响其工作负载性能。
-可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset，因此系统上的
-其余 CPU 可以专门用于工作负载，而不受不受控制的中断或计时器的影响较小。
-要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上，
-应使用 Kubernetes 之外的其他机制。
+此选项是专门为电信/NFV 用例设计的，在这些用例中不受控制的中断或计时器可能会
+影响其工作负载性能。
+你可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器显式定义 cpuset，
+这样系统上的其余 CPU 可以专门用于工作负载，因不受控制的中断或计时器的影响得以
+降低。
+要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式
+cpuset 上，应使用 Kubernetes 之外的其他机制。
 例如：在 Centos 系统中，可以使用 tuned 工具集来执行此操作。
 
 <!--
@@ -298,16 +296,19 @@ system daemons did not exist on a node, pods cannot use more than `capacity -
 eviction-hard`. For this reason, resources reserved for evictions are not
 available for pods.
 -->
-### 驱逐阈值
+### 驱逐阈值   {#eviction-Thresholds}
 
-- **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]`
+- **Kubelet 标志**: `--eviction-hard=[memory.available<500Mi]`
 
-节点级别的内存压力将导致系统内存不足，这将影响到整个节点及其上运行的所有 pod。节点可以暂时离线直到内存已经回收为止。
+节点级别的内存压力将导致系统内存不足，这将影响到整个节点及其上运行的所有 Pod。
+节点可以暂时离线直到内存已经回收为止。
 为了防止（或减少可能性）系统内存不足，kubelet 提供了
 [资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)管理。
 驱逐操作只支持 `memory` 和 `ephemeral-storage`。
-通过 `--eviction-hard` 标志预留一些内存后，当节点上的可用内存降至保留值以下时，`kubelet` 将尝试`驱逐` pod。
-假设，如果节点上不存在系统守护进程，pod 将不能使用超过 `capacity-eviction-hard` 的资源。因此，为驱逐而预留的资源对 pod 是不可用的。
+通过 `--eviction-hard` 标志预留一些内存后，当节点上的可用内存降至保留值以下时，
+`kubelet` 将尝试`驱逐` Pod。
+如果节点上不存在系统守护进程，Pod 将不能使用超过 `capacity-eviction-hard` 所
+指定的资源量。因此，为驱逐而预留的资源对 Pod 是不可用的。
 
 <!--
 ### Enforcing Node Allocatable
@@ -322,27 +323,28 @@ by evicting pods whenever the overall usage across all pods exceeds
 [here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
 specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
 
-
 Optionally, `kubelet` can be made to enforce `kube-reserved` and
 `system-reserved` by specifying `kube-reserved` & `system-reserved` values in
 the same flag. Note that to enforce `kube-reserved` or `system-reserved`,
 `--kube-reserved-cgroup` or `--system-reserved-cgroup` needs to be specified
 respectively.
 -->
-### 执行节点分配
+### 实施节点可分配约束   {#enforcing-node-allocatable}
 
-- **Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
+- **Kubelet 标志**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
 
-调度器将 `Allocatable` 按 pod 的可用 `capacity` 对待。
+调度器将 `Allocatable` 视为 Pod 可用的 `capacity`（资源容量）。
 
-`kubelet` 默认在 Pod 中执行 `Allocatable`。无论何时，如果所有 pod 的总用量超过了 `Allocatable`，
-驱逐 pod 的措施将被执行。有关驱逐策略的更多细节可以在
-[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy).找到。
-请通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
+`kubelet` 默认对 Pod 执行 `Allocatable` 约束。
+无论何时，如果所有 Pod 的总用量超过了 `Allocatable`，驱逐 Pod 的措施将被执行。
+有关驱逐策略的更多细节可以在
+[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)找到。
+可通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
 
-可选的，通过在相同标志中同时指定 `kube-reserved` 和 `system-reserved` 值能够使 `kubelet` 
-执行 `kube-reserved` 和 `system-reserved`。请注意，要想执行 `kube-reserved` 或者 `system-reserved` 时，
-需要分别指定 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`。
+可选地，通过在同一标志中同时指定 `kube-reserved` 和 `system-reserved` 值，
+可以使 `kubelet` 强制实施 `kube-reserved` 和 `system-reserved`约束。
+请注意，要想执行 `kube-reserved` 或者 `system-reserved` 约束，
+需要对应设置 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`。
 
 <!--
 ## General Guidelines
@@ -353,7 +355,17 @@ to be managed as part of kubernetes deployments. For example, `kubelet` should
 have its own control group and share `Kube-reserved` resources with the
 container runtime. However, Kubelet cannot burst and use up all available Node
 resources if `kube-reserved` is enforced.
+-->
+## 一般原则   {#general-guidelines}
 
+系统守护进程一般会被按照类似 `Guaranteed` Pod 一样对待。
+系统守护进程可以在与其对应的控制组中出现突发资源用量，这一行为要作为
+kubernetes 部署的一部分进行管理。
+例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。
+不过，如果执行了 `kube-reserved` 约束，则 kubelet 不可出现突发负载并用光
+节点的所有可用资源。
+
+<!--
 Be extra careful while enforcing `system-reserved` reservation since it can lead
 to critical system services being CPU starved, OOM killed, or unable
 to fork on the node. The
@@ -365,33 +377,28 @@ ability to recover if any process in that group is oom_killed.
 * Once adequate monitoring and alerting is in place to track kube system
   daemons, attempt to enforce `kube-reserved` based on usage heuristics.
 * If absolutely necessary, enforce `system-reserved` over time.
+-->
+在执行 `system-reserved` 预留策略时请加倍小心，因为它可能导致节点上的
+关键系统服务出现 CPU 资源短缺、因为内存不足而被终止或者无法在节点上创建进程。
+建议只有当用户详尽地描述了他们的节点以得出精确的估计值，
+并且对该组中进程因内存不足而被杀死时，有足够的信心将其恢复时，
+才可以强制执行 `system-reserved` 策略。
 
+* 作为起步，可以先针对 `pods` 上执行 `Allocatable` 约束。
+* 一旦用于追踪系统守护进程的监控和告警的机制到位，可尝试基于用量估计的
+  方式执行 `kube-reserved`策略。
+* 随着时间推进，在绝对必要的时候可以执行 `system-reserved` 策略。
+
+<!--
 The resource requirements of kube system daemons may grow over time as more and
 more features are added. Over time, kubernetes project will attempt to bring
 down utilization of node system daemons, but that is not a priority as of now.
 So expect a drop in `Allocatable` capacity in future releases.
 -->
-## 一般原则
-
-系统守护进程期望被按照类似 `Guaranteed` pod 一样对待。系统守护进程可以在其范围控制组中爆发式增长，
-您需要将这个行为作为 kubernetes 部署的一部分进行管理。
-例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。
-然而，如果执行了 `kube-reserved`，则 kubelet 不能突然爆发并耗尽节点的所有可用资源。
-
-在执行 `system-reserved` 预留操作时请加倍小心，因为它可能导致节点上的关键系统服务 CPU 资源短缺
-或因为内存不足而被终止。
-建议只有当用户详尽地描述了他们的节点以得出精确的估计时才强制执行 `system-reserved`，
-并且如果该组中的任何进程都是 oom_killed，则对他们恢复的能力充满信心。
-
-* 在 `pods` 上执行 `Allocatable` 作为开始。
-* 一旦足够用于追踪系统守护进程的监控和告警的机制到位，请尝试基于用量探索方式执行 `kube-reserved`。
-* 随着时间推进，如果绝对必要，可以执行 `system-reserved`。
-
-随着时间的增长以及越来越多特性的加入，kube 系统守护进程对资源的需求可能也会增加。
-以后 kubernetes 项目将尝试减少对节点系统守护进程的利用，但目前那并不是优先事项。
-所以，请期待在将来的发布中将 `Allocatable` 容量降低。
-
-
+随着时间推进和越来越多特性被加入，kube 系统守护进程对资源的需求可能也会增加。
+以后 kubernetes 项目将尝试减少对节点系统守护进程的利用，但目前这件事的优先级
+并不是最高。
+所以，将来的发布版本中 `Allocatable` 容量是有可能降低的。
 
 <!-- discussion -->
 
@@ -404,7 +411,17 @@ Here is an example to illustrate Node Allocatable computation:
 * `--kube-reserved` is set to `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
 * `--system-reserved` is set to `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
 * `--eviction-hard` is set to `memory.available<500Mi,nodefs.available<10%`
+-->
+## 示例场景   {#example-scenario}
 
+这是一个用于说明节点可分配（Node Allocatable）计算方式的示例：
+
+* 节点拥有 `32Gi` `memeory`，`16 CPU` 和 `100Gi` `Storage` 资源
+* `--kube-reserved` 被设置为 `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
+* `--system-reserved` 被设置为 `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
+* `--eviction-hard` 被设置为 `memory.available<500Mi,nodefs.available<10%`
+
+<!--
 Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
 `88Gi` of local storage.
 Scheduler ensures that the total memory `requests` across all pods on this node does
@@ -417,19 +434,15 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
 exceed their reservation, `kubelet` evicts pods whenever the overall node memory
 usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
 -->
-## 示例场景
-
-这是一个用于说明节点分配计算方式的示例：
-
-* 节点拥有 `32Gi 内存`，`16 核 CPU` 和 `100Gi 存储`
-* `--kube-reserved` 设置为 `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
-* `--system-reserved` 设置为 `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
-* `--eviction-hard` 设置为 `memory.available<500Mi,nodefs.available<10%`
-
 在这个场景下，`Allocatable` 将会是 `14.5 CPUs`、`28.5Gi` 内存以及 `88Gi` 本地存储。
-调度器保证这个节点上的所有 pod `请求`的内存总量不超过 `28.5Gi`，存储不超过 `88Gi`。
-当 pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，Kubelet 将会驱逐它们。
-如果节点上的所有进程都尽可能多的使用 CPU，则 pod 加起来不能使用超过 `14.5 CPUs` 的资源。
+调度器保证这个节点上的所有 Pod 的内存 `requests` 总量不超过 `28.5Gi`，
+存储不超过 `88Gi`。
+当 Pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，
+kubelet 将会驱逐它们。
+如果节点上的所有进程都尽可能多地使用 CPU，则 Pod 加起来不能使用超过
+`14.5 CPUs` 的资源。
+
+当没有执行 `kube-reserved` 和/或 `system-reserved` 策略且系统守护进程
+使用量超过其预留时，如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，
+kubelet 将会驱逐 Pod。
 
-当没有执行 `kube-reserved` 和/或 `system-reserved` 且系统守护进程使用量超过其预留时，
-如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，kubelet 将会驱逐 pod。
diff --git a/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md b/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
index bef6360559..5c4340be3b 100644
--- a/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -16,10 +16,10 @@ content_type: concept
 {{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
 <!--
-Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the {{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}} binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}` binary allows cloud vendors to evolve independently from the core Kubernetes code.
 -->
 由于云驱动的开发和发布的步调与 Kubernetes 项目不同，将服务提供商专用代码抽象到
-{{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}} 
+`{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}`
 二进制中有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
 
 <!--
diff --git a/content/zh/docs/tasks/administer-cluster/safely-drain-node.md b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md
new file mode 100644
index 0000000000..77bdc299fa
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/safely-drain-node.md
@@ -0,0 +1,277 @@
+---
+title: 确保 PodDisruptionBudget 的前提下安全地清空一个节点
+content_type: task
+---
+<!-- 
+reviewers:
+- davidopp
+- mml
+- foxish
+- kow3ns
+title: Safely Drain a Node while Respecting the PodDisruptionBudget
+content_type: task
+-->
+
+<!-- overview -->
+<!-- 
+This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined.
+ -->
+本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个{{< glossary_tooltip text="节点" term_id="node" >}}。
+
+## {{% heading "prerequisites" %}}
+
+{{% version-check %}}
+<!-- 
+This task assumes that you have met the following prerequisites:
+
+* You are using Kubernetes release >= 1.5.
+* Either:
+  1. You do not require your applications to be highly available during the
+     node drain, or
+  1. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/)
+     and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
+     applications that need them.
+-->
+此任务假设您已经满足以下先决条件：
+
+* 使用的 Kubernetes 版本 >= 1.5。
+* 以下两项，具备其一：
+  1. 在节点清空期间，不要求应用程序具有高可用性
+  1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。
+
+<!-- steps -->
+
+<!-- 
+## Use `kubectl drain` to remove a node from service
+
+You can use `kubectl drain` to safely evict all of your pods from a
+node before you perform maintenance on the node (e.g. kernel upgrade,
+hardware maintenance, etc.). Safe evictions allow the pod's containers
+to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
+and will respect the `PodDisruptionBudgets` you have specified.
+-->
+## 使用 `kubectl drain` 从服务中删除一个节点 {#use-kubectl-drain-to-remove-a-node-from-service}
+
+在对节点执行维护（例如内核升级、硬件维护等）之前，
+可以使用 `kubectl drain` 从节点安全地逐出所有 Pods。
+安全的驱逐过程允许 Pod 的容器
+[体面地终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，
+并确保满足指定的 PodDisruptionBudgets。
+
+<!-- 
+By default `kubectl drain` will ignore certain system pods on the node
+that cannot be killed; see
+the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
+documentation for more details.
+-->
+{{< note >}}
+默认情况下， `kubectl drain` 将忽略节点上不能杀死的特定系统 Pod；
+有关更多细节，请参阅
+[kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) 文档。
+{{< /note >}}
+
+<!-- 
+When `kubectl drain` returns successfully, that indicates that all of
+the pods (except the ones excluded as described in the previous paragraph)
+have been safely evicted (respecting the desired graceful termination period,
+and respecting the PodDisruptionBudget you have defined). It is then safe to
+bring down the node by powering down its physical machine or, if running on a
+cloud platform, deleting its virtual machine.
+
+First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with
+-->
+`kubectl drain` 的成功返回，表明所有的 Pods（除了上一段中描述的被排除的那些），
+已经被安全地逐出（考虑到期望的终止宽限期和你定义的 PodDisruptionBudget）。
+然后就可以安全地关闭节点，
+比如关闭物理机器的电源，如果它运行在云平台上，则删除它的虚拟机。
+
+```shell
+kubectl get nodes
+```
+
+<!-- 
+Next, tell Kubernetes to drain the node:
+-->
+接下来，告诉 Kubernetes 清空节点：
+
+```shell
+kubectl drain <node name>
+```
+
+<!-- 
+Once it returns (without giving an error), you can power down the node
+(or equivalently, if on a cloud platform, delete the virtual machine backing the node).
+If you leave the node in the cluster during the maintenance operation, you need to run
+-->
+一旦它返回（没有报错），
+你就可以下电此节点（或者等价地，如果在云平台上，删除支持该节点的虚拟机）。
+如果要在维护操作期间将节点留在集群中，则需要运行：
+
+```shell
+kubectl uncordon <node name>
+```
+<!-- 
+afterwards to tell Kubernetes that it can resume scheduling new pods onto the node.
+-->
+然后告诉 Kubernetes，它可以继续在此节点上调度新的 Pods。
+
+<!-- 
+## Draining multiple nodes in parallel
+
+The `kubectl drain` command should only be issued to a single node at a
+time. However, you can run multiple `kubectl drain` commands for
+different nodes in parallel, in different terminals or in the
+background. Multiple drain commands running concurrently will still
+respect the `PodDisruptionBudget` you specify.
+-->
+## 并行清空多个节点  {#draining-multiple-nodes-in-parallel}
+
+ `kubectl drain` 命令一次只能发送给一个节点。
+ 但是，你可以在不同的终端或后台为不同的节点并行地运行多个 `kubectl drain` 命令。
+ 同时运行的多个 drain 命令仍然遵循你指定的 PodDisruptionBudget 。
+
+<!-- 
+For example, if you have a StatefulSet with three replicas and have
+set a PodDisruptionBudget for that set specifying `minAvailable: 2`,
+`kubectl drain` only evicts a pod from the StatefulSet if all three
+replicas pods are ready; if then you issue multiple drain commands in
+parallel, Kubernetes respects the PodDisruptionBudget and ensure
+that only 1 (calculated as `replicas - minAvailable`) Pod is unavailable
+at any given time. Any drains that would cause the number of ready
+replicas to fall below the specified budget are blocked.
+-->
+例如，如果你有一个三副本的 StatefulSet，
+并设置了一个 `PodDisruptionBudget`，指定 `minAvailable: 2`。
+如果所有的三个 Pod 均就绪，并且你并行地发出多个 drain 命令，
+那么 `kubectl drain` 只会从 StatefulSet 中逐出一个 Pod，
+因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用（最多不可用 Pod 个数的计算方法：`replicas - minAvailable`）。
+任何会导致就绪副本数量低于指定预算的清空操作都将被阻止。
+
+<!-- 
+## The Eviction API
+
+If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as
+to avoid calling to an external command, or to get finer control over the pod
+eviction process), you can also programmatically cause evictions using the eviction API.
+-->
+## 驱逐 API {#the-eviction-api}
+如果你不喜欢使用
+[kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain)
+（比如避免调用外部命令，或者更细化地控制 pod 驱逐过程），
+你也可以用驱逐 API 通过编程的方式达到驱逐的效果。
+
+<!-- 
+You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api).
+
+The eviction subresource of a
+pod can be thought of as a kind of policy-controlled DELETE operation on the pod
+itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
+*create* an eviction), you POST an attempted operation. Here's an example:
+-->
+首先应该熟悉使用 
+[Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。
+
+Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。
+要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子：
+
+```json
+{
+  "apiVersion": "policy/v1beta1",
+  "kind": "Eviction",
+  "metadata": {
+    "name": "quux",
+    "namespace": "default"
+  }
+}
+```
+
+<!-- 
+You can attempt an eviction using `curl`:
+-->
+你可以使用 `curl` 尝试驱逐：
+
+```bash
+curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
+```
+
+<!-- 
+The API can respond in one of three ways:
+
+- If the eviction is granted, then the pod is deleted just as if you had sent
+  a `DELETE` request to the pod's URL and you get back `200 OK`.
+- If the current state of affairs wouldn't allow an eviction by the rules set
+  forth in the budget, you get back `429 Too Many Requests`. This is
+  typically used for generic rate limiting of *any* requests, but here we mean
+  that this request isn't allowed *right now* but it may be allowed later.
+  Currently, callers do not get any `Retry-After` advice, but they may in
+  future versions.
+- If there is some kind of misconfiguration, like multiple budgets pointing at
+  the same pod, you will get `500 Internal Server Error`.
+-->
+API可以通过以下三种方式之一进行响应：
+
+- 如果驱逐被授权，那么 Pod 将被删掉，并且你会收到 `200 OK`，
+  就像你向 Pod 的 URL 发送了 `DELETE` 请求一样。
+- 如果按照预算中规定，目前的情况不允许的驱逐，你会收到 `429 Too Many Requests`。
+  这通常用于对 *一些* 请求进行通用速率限制，
+  但这里我们的意思是：此请求 *现在* 不允许，但以后可能会允许。
+  目前，调用者不会得到任何 `Retry-After` 的提示，但在将来的版本中可能会得到。
+- 如果有一些错误的配置，比如多个预算指向同一个 Pod，你将得到 `500 Internal Server Error`。
+
+<!-- 
+For a given eviction request, there are two cases:
+
+- There is no budget that matches this pod. In this case, the server always
+  returns `200 OK`.
+- There is at least one budget. In this case, any of the three above responses may
+ apply.
+-->
+对于一个给定的驱逐请求，有两种情况：
+
+- 没有匹配这个 Pod 的预算。这种情况，服务器总是返回 `200 OK`。
+- 至少匹配一个预算。在这种情况下，上述三种回答中的任何一种都可能适用。
+
+<!-- 
+## Stuck evictions
+
+In some cases, an application may reach a broken state, one where unless you intervene the
+eviction API will never return anything other than 429 or 500.
+
+For example: this can happen if ReplicaSet is creating Pods for your application but
+the replacement Pods do not become `Ready`. You can also see similar symptoms if the
+last Pod evicted has a very long termination grace period.
+
+In this case, there are two potential solutions:
+
+- Abort or pause the automated operation. Investigate the reason for the stuck application,
+  and restart the automation.
+- After a suitably long wait, `DELETE` the Pod from your cluster's control plane, instead
+  of using the eviction API.
+
+Kubernetes does not specify what the behavior should be in this case; it is up to the
+application owners and cluster owners to establish an agreement on behavior in these cases.
+-->
+## 驱逐阻塞
+
+在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。
+例如 ReplicaSet 创建的替换 Pod 没有变成就绪状态，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。
+
+在这种情况下，有两种可能的解决方案：
+
+- 中止或暂停自动操作。调查应用程序卡住的原因，并重新启动自动化。
+- 经过适当的长时间等待后， 从集群中删除 Pod 而不是使用驱逐 API。
+
+Kubernetes 并没有具体说明在这种情况下应该采取什么行为，
+这应该由应用程序所有者和集群所有者紧密沟通，并达成对行动一致意见。
+
+## {{% heading "whatsnext" %}}
+
+
+<!-- 
+* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
+* Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
+-->
+* 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。
+* 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。
+
+
diff --git a/content/zh/docs/tasks/administer-cluster/topology-manager.md b/content/zh/docs/tasks/administer-cluster/topology-manager.md
index c0eb000957..d197f5dcf7 100644
--- a/content/zh/docs/tasks/administer-cluster/topology-manager.md
+++ b/content/zh/docs/tasks/administer-cluster/topology-manager.md
@@ -1,29 +1,23 @@
 ---
 title: 控制节点上的拓扑管理策略
-reviewers:
-- ConnorDoyle
-- klueska
-- lmdaly
-- nolancon
-
 content_type: task
+min-kubernetes-server-version: v1.18
 ---
 <!--
----
 title: Control Topology Management Policies on a node
 reviewers:
 - ConnorDoyle
 - klueska
 - lmdaly
 - nolancon
-
+- bg-chun
 content_type: task
----
+min-kubernetes-server-version: v1.18
 -->
 
 <!-- overview -->
 
-{{< feature-state state="alpha" >}}
+{{< feature-state state="beta" for_k8s_version="v1.18" >}}
 
 <!--
 An increasing number of systems leverage a combination of CPUs and hardware accelerators to support latency-critical execution and high-throughput parallel computation. These include workloads in fields such as telecommunications, scientific computing, machine learning, financial services and data analytics. Such hybrid systems comprise a high performance environment.
@@ -41,17 +35,12 @@ In order to extract the best performance, optimizations related to CPU isolation
 <!--
 _Topology Manager_ is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations.
 -->
-_拓扑管理器（Topology Manager）_ 是一个 Kubelet 的一部分，旨在协调负责这些优化的一组组件。
-
-
+_拓扑管理器（Topology Manager）_ 是一个 kubelet 的一部分，旨在协调负责这些优化的一组组件。
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
 <!-- steps -->
 
 <!--
@@ -91,42 +80,59 @@ The hint is then stored in the Topology Manager for use by the *Hint Providers*
 取决于所配置的策略，所选建议可用来决定节点接受或拒绝 Pod 。
 之后，建议会被存储在拓扑管理器中，供 *建议提供者* 进行资源分配决策时使用。
 
+<!--
+### Enable the Topology Manager feature
+
+Support for the Topology Manager requires `TopologyManager` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.18.
+-->
+### 启用拓扑管理器功能特性
+
+对拓扑管理器的支持要求启用 `TopologyManager`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+从 Kubernetes 1.18 版本开始，这一特性默认是启用的。
+
 <!--
 ### Topology Manager Policies
+
+The Topology Manager currently:
+
+ - Aligns Pods of all QoS classes.
+ - Aligns the requested resources that Hint Provider provides topology hints for.
 -->
 ### 拓扑管理器策略
 
-<!--
-The Topology Manager currently:
--->
-当前拓扑管理器：
+拓扑管理器目前：
 
-<!--
- - Works on Nodes with the `static` CPU Manager Policy enabled. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/)
- - Works on Pods making CPU requests or Device requests via extended resources
--->
-- 在启用了 `static` CPU 管理器策略的节点上起作用。 请参阅[控制 CPU 管理策略](/docs/tasks/administer-cluster/cpu-management-policies/)
-- 适用于通过扩展资源发出 CPU 请求或设备请求的 Pod
+- 对所有 QoS 类的 Pod 执行对齐操作
+- 针对建议提供者所提供的拓扑建议，对请求的资源进行对齐
 
 <!--
 If these conditions are met, Topology Manager will align the requested resources.
 -->
-如果满足这些条件，则拓扑管理器将调整请求的资源。
+如果满足这些条件，则拓扑管理器将对齐请求的资源。
+
+<!--
+To align CPU resources with other requested resources in a Pod Spec, the CPU Manager should be enabled and proper CPU Manager policy should be configured on a Node. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
+-->
+{{< note >}}
+为了将 Pod 规约中的 CPU 资源与其他请求资源对齐，CPU 管理器需要被启用并且
+节点上应配置了适当的 CPU 管理器策略。
+参看[控制 CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/).
+{{< /note >}}
 
 <!--
 Topology Manager supports four allocation policies. You can set a policy via a Kubelet flag, `--topology-manager-policy`.
 There are four supported policies:
--->
-拓扑管理器支持四种分配策略。
-您可以通过 Kubelet 标志 `--topology-manager-policy` 设置策略。
-所支持的策略有四种：
 
-<!--
 * `none` (default)
 * `best-effort`
 * `restricted`
 * `single-numa-node`
 -->
+拓扑管理器支持四种分配策略。
+你可以通过 Kubelet 标志 `--topology-manager-policy` 设置策略。
+所支持的策略有四种：
+
 * `none` (默认)
 * `best-effort`
 * `restricted`
@@ -134,27 +140,26 @@ There are four supported policies:
 
 <!--
 ### none policy {#policy-none}
+
+This is the default policy and does not perform any topology alignment.
 -->
 ### none 策略 {#policy-none}
 
-<!--
-This is the default policy and does not perform any topology alignment.
--->
 这是默认策略，不执行任何拓扑对齐。
 
 <!--
 ### best-effort policy {#policy-best-effort}
--->
-### best-effort 策略 {#policy-best-effort}
 
-<!--
 For each container in a Guaranteed Pod, kubelet, with `best-effort` topology 
 management policy, calls each Hint Provider to discover their resource availability.
 Using this information, the Topology Manager stores the 
 preferred NUMA Node affinity for that container. If the affinity is not preferred, 
 Topology Manager will store this and admit the pod to the node anyway.
 -->
-对于 Guaranteed 类的 Pod 中的每个容器，具有 `best-effort` 拓扑管理策略的 kubelet 将调用每个建议提供者以确定资源可用性。
+### best-effort 策略 {#policy-best-effort}
+
+对于 Guaranteed 类的 Pod 中的每个容器，具有 `best-effort` 拓扑管理策略的
+kubelet 将调用每个建议提供者以确定资源可用性。
 使用此信息，拓扑管理器存储该容器的首选 NUMA 节点亲和性。
 如果亲和性不是首选，则拓扑管理器将存储该亲和性，并且无论如何都将  pod 接纳到该节点。
 
@@ -166,17 +171,17 @@ resource allocation decision.
 
 <!--
 ### restricted policy {#policy-restricted}
--->
-### restricted 策略 {#policy-restricted}
 
-<!--
 For each container in a Guaranteed Pod, kubelet, with `restricted` topology 
 management policy, calls each Hint Provider to discover their resource availability.
 Using this information, the Topology Manager stores the 
 preferred NUMA Node affinity for that container. If the affinity is not preferred, 
 Topology Manager will reject this pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.
 -->
-对于 Guaranteed 类 Pod 中的每个容器， 配置了 `restricted` 拓扑管理策略的 kubelet 调用每个建议提供者以确定其资源可用性。。
+### restricted 策略 {#policy-restricted}
+
+对于 Guaranteed 类 Pod 中的每个容器， 配置了 `restricted` 拓扑管理策略的 kubelet
+调用每个建议提供者以确定其资源可用性。。
 使用此信息，拓扑管理器存储该容器的首选 NUMA 节点亲和性。
 如果亲和性不是首选，则拓扑管理器将从节点中拒绝此 Pod 。
 这将导致 Pod 处于 `Terminated` 状态，且 Pod 无法被节点接纳。
@@ -185,21 +190,19 @@ Topology Manager will reject this pod from the node. This will result in a pod i
 Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended to use a ReplicaSet or Deployment to trigger a redeploy of the pod.
 An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.
 -->
-一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
+一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。
+建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
 还可以通过实现外部控制环，以启动对具有 `Topology Affinity` 错误的 Pod 的重新部署。
 
 <!--
 If the pod is admitted, the *Hint Providers* can then use this information when making the 
 resource allocation decision.
 -->
-如果 Pod 被允许运行在该节点，则 *建议提供者* 可以在做出资源分配决定时使用此信息。
+如果 Pod 被允许运行在某节点，则 *建议提供者* 可以在做出资源分配决定时使用此信息。
 
 <!--
 ### single-numa-node policy {#policy-single-numa-node}
--->
-### single-numa-node 策略 {#policy-single-numa-node}
 
-<!--
 For each container in a Guaranteed Pod, kubelet, with `single-numa-node` topology 
 management policy, calls each Hint Provider to discover their resource availability.
 Using this information, the Topology Manager determines if a single NUMA Node affinity is possible.
@@ -207,7 +210,10 @@ If it is, Topology Manager will store this and the *Hint Providers* can then use
 resource allocation decision.
 If, however, this is not possible then the Topology Manager will reject the pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.
 -->
-对于 Guaranteed 类 Pod 中的每个容器， 配置了 `single-numa-nodde` 拓扑管理策略的 kubelet 调用每个建议提供者以确定其资源可用性。
+### single-numa-node 策略 {#policy-single-numa-node}
+
+对于 Guaranteed 类 Pod 中的每个容器， 配置了 `single-numa-nodde` 拓扑管理策略的
+kubelet 调用每个建议提供者以确定其资源可用性。
 使用此信息，拓扑管理器确定单 NUMA 节点亲和性是否可能。
 如果是这样，则拓扑管理器将存储此信息，然后 *建议提供者* 可以在做出资源分配决定时使用此信息。
 如果不可能，则拓扑管理器将拒绝 Pod 运行于该节点。
@@ -217,17 +223,17 @@ If, however, this is not possible then the Topology Manager will reject the pod
 Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended to use a Deployment with replicas to trigger a redeploy of the Pod.
 An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.
 -->
-一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
+一旦 Pod 处于 `Terminated` 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。
+建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
 还可以通过实现外部控制环，以触发具有 `Topology Affinity` 错误的 Pod 的重新部署。
 
 <!--
 ### Pod Interactions with Topology Manager Policies
+
+Consider the containers in the following pod specs:
 -->
 ### Pod 与拓扑管理器策略的交互
 
-<!--
-Consider the containers in the following pod specs:
--->
 考虑以下 pod 规范中的容器：
 
 ```yaml
@@ -241,7 +247,7 @@ spec:
 This pod runs in the `BestEffort` QoS class because no resource `requests` or
 `limits` are specified.
 -->
-该 Pod 在 `BestEffort` QoS 类中运行，因为没有指定资源 `requests` 或 `limits` 。
+该 Pod 以 `BestEffort` QoS 类运行，因为没有指定资源 `requests` 或 `limits`。
 
 ```yaml
 spec:
@@ -261,11 +267,12 @@ This pod runs in the `Burstable` QoS class because requests are less than limits
 由于 requests 数少于 limits，因此该 Pod 以 `Burstable` QoS 类运行。
 
 <!--
-If the selected policy is anything other than `none` , Topology Manager would not consider either of these Pod
-specifications. 
+If the selected policy is anything other than `none`, Topology Manager would consider these Pod specifications. The Topology Manager would consult the Hint Providers to get topology hints. In the case of the `static`, the CPU Manager policy would return default topology hint, because these Pods do not have explicity request CPU resources.
 -->
-如果选择的策略是 `none` 以外的任何其他策略，拓扑管理器不会考虑这些 Pod 中的任何一个规范。
-
+如果选择的策略是 `none` 以外的任何其他策略，拓扑管理器都会评估这些 Pod 的规范。
+拓扑管理器会咨询建议提供者，获得拓扑建议。
+若策略为 `static`，则 CPU 管理器策略会返回默认的拓扑建议，因为这些 Pod
+并没有显式地请求 CPU 资源。
 
 ```yaml
 spec:
@@ -284,10 +291,10 @@ spec:
 ```
 
 <!--
-This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
+This pod with integer CPU request runs in the `Guaranteed` QoS class because
+`requests` are equal to `limits`.
 -->
-此 Pod 在 `Guaranteed` QoS 类中运行，因为其 `requests` 值等于 `limits` 值。
-
+此 Pod 以 `Guaranteed` QoS 类运行，因为其 `requests` 值等于 `limits` 值。
 
 ```yaml
 spec:
@@ -302,48 +309,59 @@ spec:
         example.com/deviceA: "1"
         example.com/deviceB: "1"
 ```
+
 <!--
 This pod runs in the `BestEffort` QoS class because there are no CPU and memory requests.
 -->
-由于没有 CPU 和内存请求，因此该 Pod 在 `BestEffort` QoS 类中运行。
+因为未指定 CPU 和内存请求，所以 Pod 以 `BestEffort` QoS 类运行。
 
 <!--
 The Topology Manager would consider both of the above pods. The Topology Manager would consult the Hint Providers, which are CPU and Device Manager to get topology hints for the pods. 
-In the case of the `Guaranteed` pod the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
+
+In the case of the `Guaranteed` pod with integer request, the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
 -->
-拓扑管理器将考虑以上两个 Pod。拓扑管理器将咨询 CPU 和设备管理器，以获取 Pod 的拓扑提示。
-对于 `Guaranteed` Pod，`static` CPU 管理器策略将返回与 CPU 请求有关的提示，而设备管理器将返回有关所请求设备的提示。
+拓扑管理器将考虑以上两个 Pod。拓扑管理器将咨询建议提供者即 CPU 和设备管理器，以获取 Pod 的拓扑提示。
+对于 `Guaranteed` 类的 CPU 请求数为整数的 Pod，`static` CPU 管理器策略将返回与 CPU 请求有关的提示，
+而设备管理器将返回有关所请求设备的提示。
 
 <!--
-In the case of the `BestEffort` pod the CPU Manager would send back the default hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
+In the case of the `Guaranteed` pod with sharing CPU request, the `static` CPU Manager policy would return default topology hint as there is no exclusive CPU request and the Device Manager would send back hints for the requested device.
+
+In the above two cases of the `Guaranteed` pod, the `none` CPU Manager policy would return default topology hint.
 -->
-对于 `BestEffort` Pod，由于没有 CPU 请求，CPU 管理器将发送默认提示，而设备管理器将为每个请求的设备发送提示。
+对于 `Guaranteed` 类的 CPU 请求可共享的 Pod，`static` CPU
+管理器策略将返回默认的拓扑提示，因为没有排他性的 CPU 请求；而设备管理器
+则针对所请求的设备返回有关提示。
+
+在上述两种 `Guaranteed` Pod 的情况中，`none` CPU 管理器策略会返回默认的拓扑提示。
+
+<!--
+In the case of the `BestEffort` pod, the `static` CPU Manager policy would send back the default topology hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
+-->
+对于 `BestEffort` Pod，由于没有 CPU 请求，`static` CPU 管理器策略将发送默认提示，
+而设备管理器将为每个请求的设备发送提示。
 
 <!--
 Using this information the Topology Manager calculates the optimal hint for the pod and stores this information, which will be used by the Hint Providers when they are making their resource assignments.
 -->
-使用此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供提示提供程序在进行资源分配时使用。
+基于此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供
+提示提供程序在进行资源分配时使用。
 
 <!--
 ### Known Limitations
+
+1. The maximum number of NUMA nodes that Topology Manager allows is 8. With more than 8 NUMA nodes there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
+
+2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager.
+
+3. The Device Manager and the CPU Manager are the only components to adopt the Topology Manager's HintProvider interface. This means that NUMA alignment can only be achieved for resources managed by the CPU Manager and the Device Manager. Memory or Hugepages are not considered by the Topology Manager for NUMA alignment.
 -->
 ### 已知的局限性
-<!--
-1. As of K8s 1.16 the Topology Manager is currently only guaranteed to work if a *single* container in the pod spec requires aligned resources. This is due to the hint generation being based on current resource allocations, and all containers in a pod generate hints before any resource allocation has been made. This results in unreliable hints for all but the first container in a pod.
-*Due to this limitation if multiple pods/containers are considered by Kubelet in quick succession they may not respect the Topology Manager policy.
--->
-1. 从 K8s 1.16 开始，当前只能在保证 Pod 规范中的 *单个* 容器需要相匹配的资源时，拓扑管理器才能正常工作。这是由于生成的提示信息是基于当前资源分配的，并且 pod 中的所有容器都会在进行任何资源分配之前生成提示信息。这样会导致除 Pod 中的第一个容器以外的所有容器生成不可靠的提示信息。
-* 由于此限制，如果 kubelet 快速连续考虑多个 Pod/容器，它们可能不遵守拓扑管理器策略。
-
-<!--
-2. The maximum number of NUMA nodes that Topology Manager will allow is 8, past this there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
--->
-2. 拓扑管理器允许的最大 NUMA 节点数为 8，并且在尝试枚举可能的 NUMA 关联并生成其提示信息时，将出现状态问题。
-
-<!--
-3. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager.
--->
-3. 调度器不支持拓扑功能，因此可能会由于拓扑管理器的原因而在节点上进行调度，然后在该节点上调度失败。
-
 
+1. 拓扑管理器所能处理的最大 NUMA 节点个数是 8。若 NUMA 节点数超过 8，
+   枚举可能的 NUMA 亲和性并为之生成提示时会发生状态爆炸。
+2. 调度器不支持拓扑功能，因此可能会由于拓扑管理器的原因而在节点上进行调度，然后在该节点上调度失败。
+3. 设备管理器和 CPU 管理器时能够采纳拓扑管理器 HintProvider 接口的唯一两个组件。
+   这意味着 NUMA 对齐只能针对 CPU 管理器和设备管理器所管理的资源实现。
+   内存和大页面在拓扑管理器决定 NUMA 对齐时都还不会被考虑在内。
 
diff --git a/content/zh/docs/tasks/configmap-secret/_index.md b/content/zh/docs/tasks/configmap-secret/_index.md
new file mode 100644
index 0000000000..3761ba9655
--- /dev/null
+++ b/content/zh/docs/tasks/configmap-secret/_index.md
@@ -0,0 +1,5 @@
+---
+title: "管理 Secrets"
+weight: 28
+description: 使用 Secrets 管理机密配置数据。
+---
\ No newline at end of file
diff --git a/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md
new file mode 100644
index 0000000000..1c140cee4c
--- /dev/null
+++ b/content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md
@@ -0,0 +1,268 @@
+---
+title: 使用配置文件管理 Secret
+content_type: task
+weight: 20
+description: 使用资源配置文件创建 Secret 对象。
+---
+<!--  
+title: Managing Secret using Configuration File
+content_type: task
+weight: 20
+description: Creating Secret objects using resource configuration file.
+-->
+
+<!-- overview -->
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+<!-- ## Create the Config file -->
+## 创建配置文件    {#create-the-config-file}
+
+<!-- 
+You can create a Secret in a file first, in JSON or YAML format, and then
+create that object.  The
+[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+resource contains two maps: `data` and `stringData`.
+The `data` field is used to store arbitrary data, encoded using base64. The
+`stringData` field is provided for convenience, and it allows you to provide
+Secret data as unencoded strings.
+The keys of `data` and `stringData` must consist of alphanumeric characters,
+`-`, `_` or `.`. 
+-->
+你可以先用 JSON 或 YAML 格式在文件中创建 Secret，然后创建该对象。
+[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+资源包含2个键值对： `data` 和 `stringData`。
+`data` 字段用来存储 base64 编码的任意数据。
+提供 `stringData` 字段是为了方便，它允许 Secret 使用未编码的字符串。
+`data` 和 `stringData` 的键必须由字母、数字、`-`，`_` 或 `.` 组成。
+
+<!--  
+For example, to store two strings in a Secret using the `data` field, convert
+the strings to base64 as follows:
+-->
+例如，要使用 Secret 的 `data` 字段存储两个字符串，请将字符串转换为 base64 ，如下所示：
+
+```shell
+echo -n 'admin' | base64
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+YWRtaW4=
+```
+
+```shell
+echo -n '1f2d1e2e67df' | base64
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+MWYyZDFlMmU2N2Rm
+```
+
+<!-- Write a Secret config file that looks like this: -->
+编写一个 Secret 配置文件，如下所示：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret
+type: Opaque
+data:
+  username: YWRtaW4=
+  password: MWYyZDFlMmU2N2Rm
+```
+
+<!-- 
+Note that the name of a Secret object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). 
+-->
+注意，Secret 对象的名称必须是有效的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). 
+
+{{< note >}}
+<!--  
+The serialized JSON and YAML values of Secret data are encoded as base64
+strings. Newlines are not valid within these strings and must be omitted. When
+using the `base64` utility on Darwin/macOS, users should avoid using the `-b`
+option to split long lines. Conversely, Linux users *should* add the option
+`-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if the `-w`
+option is not available.
+-->
+Secret 数据的 JSON 和 YAML 序列化结果是以 base64 编码的。
+换行符在这些字符串中无效，必须省略。
+在 Darwin/macOS 上使用 `base64` 工具时，用户不应该使用 `-b` 选项分割长行。
+相反地，Linux 用户 *应该* 在 `base64` 地命令中添加 `-w 0` 选项，
+或者在 `-w` 选项不可用的情况下，输入 `base64 | tr -d '\n'`。
+{{< /note >}}
+
+<!-- 
+For certain scenarios, you may wish to use the `stringData` field instead. This
+field allows you to put a non-base64 encoded string directly into the Secret,
+and the string will be encoded for you when the Secret is created or updated.
+-->
+对于某些场景，你可能希望使用 `stringData` 字段。
+这字段可以将一个非 base64 编码的字符串直接放入 Secret 中，
+当创建或更新该 Secret 时，此字段将被编码。
+
+<!--  
+A practical example of this might be where you are deploying an application
+that uses a Secret to store a configuration file, and you want to populate
+parts of that configuration file during your deployment process.
+-->
+上述用例的实际场景可能是这样：当你部署应用时，使用 Secret 存储配置文件，
+你希望在部署过程中，填入部分内容到该配置文件。
+
+<!-- For example, if your application uses the following configuration file: -->
+例如，如果你的应用程序使用以下配置文件:
+
+```yaml
+apiUrl: "https://my.api.com/api/v1"
+username: "<user>"
+password: "<password>"
+```
+
+<!-- You could store this in a Secret using the following definition: -->
+你可以使用以下定义将其存储在 Secret 中:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret
+type: Opaque
+stringData:
+  config.yaml: |
+    apiUrl: "https://my.api.com/api/v1"
+    username: <user>
+    password: <password>
+```
+
+<!-- ## Create the Secret object -->
+## 创建 Secret 对象    {#create-the-secret-object}
+
+<!-- Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply): -->
+现在使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret：
+
+```shell
+kubectl apply -f ./secret.yaml
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+secret/mysecret created
+```
+
+<!-- ## Check the Secret -->
+## 检查 Secret   {#check-the-secret}
+
+<!--  
+The `stringData` field is a write-only convenience field. It is never output when
+retrieving Secrets. For example, if you run the following command:
+-->
+`stringData` 字段是只写的。获取 Secret 时，此字段永远不会输出。
+例如，如果你运行以下命令：
+
+
+```shell
+kubectl get secret mysecret -o yaml
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  creationTimestamp: 2018-11-15T20:40:59Z
+  name: mysecret
+  namespace: default
+  resourceVersion: "7225"
+  uid: c280ad2e-e916-11e8-98f2-025000000001
+type: Opaque
+data:
+  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
+```
+
+<!--  
+The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
+default. This is to protect the `Secret` from being exposed accidentally to an onlooker,
+or from being stored in a terminal log.
+To check the actual content of the encoded data, please refer to
+[decoding secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret).
+-->
+命令 `kubectl get` 和 `kubectl describe` 默认不显示 `Secret` 的内容。
+这是为了防止 `Secret` 意外地暴露给旁观者或者保存在终端日志中。
+检查编码数据的实际内容，请参考[解码 secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret).
+
+<!-- 
+If a field, such as `username`, is specified in both `data` and `stringData`,
+the value from `stringData` is used. For example, the following Secret definition: 
+-->
+如果在 `data` 和 `stringData` 中都指定了一个字段，比如 `username`，字段值来自 `stringData`。
+例如，下面的 Secret 定义:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret
+type: Opaque
+data:
+  username: YWRtaW4=
+stringData:
+  username: administrator
+```
+
+<!-- Results in the following Secret: -->
+结果有以下 Secret：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  creationTimestamp: 2018-11-15T20:46:46Z
+  name: mysecret
+  namespace: default
+  resourceVersion: "7579"
+  uid: 91460ecb-e917-11e8-98f2-025000000001
+type: Opaque
+data:
+  username: YWRtaW5pc3RyYXRvcg==
+```
+
+<!-- Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`. -->
+其中 `YWRtaW5pc3RyYXRvcg==` 解码成 `administrator`。
+
+<!-- ## Clean Up -->
+## 清理    {#clean-up}
+
+<!-- To delete the Secret you have just created: -->
+删除你刚才创建的 Secret：
+
+```shell
+kubectl delete secret db-user-pass
+```
+
+## {{% heading "whatsnext" %}}
+
+<!-- 
+- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
+- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- Learn how to [manage Secret using kustomizae](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+-->
+- 进一步阅读 [Secret 概念](/zh/docs/concepts/configuration/secret/)
+- 了解如何[使用 `kubectl` 命令管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- 了解如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+
diff --git a/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
new file mode 100644
index 0000000000..5105500f0e
--- /dev/null
+++ b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
@@ -0,0 +1,211 @@
+---
+title: 使用 kubectl 管理 Secret
+content_type: task
+weight: 10
+description: 使用 kubectl 命令行创建 Secret 对象。
+---
+<!--
+title: Managing Secret using kubectl
+content_type: task
+weight: 10
+description: Creating Secret objects using kubectl command line.
+-->
+
+<!-- overview -->
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+<!-- ## Create a Secret -->
+## 创建 Secret    {#create-a-secret}
+
+<!--
+A `Secret` can contain user credentials required by Pods to access a database.
+For example, a database connection string consists of a username and password.
+You can store the username in a file `./username.txt` and the password in a
+file `./password.txt` on your local machine.
+ -->
+一个 `Secret` 可以包含 Pod 访问数据库所需的用户凭证。
+例如，由用户名和密码组成的数据库连接字符串。
+你可以在本地计算机上，将用户名存储在文件 `./username.txt` 中，将密码存储在文件 `./password.txt` 中。
+
+```shell
+echo -n 'admin' > ./username.txt
+echo -n '1f2d1e2e67df' > ./password.txt
+```
+
+<!--
+The `-n` flag in the above two commands ensures that the generated files will
+not contain an extra newline character at the end of the text. This is
+important because when `kubectl` reads a file and encode the content into
+base64 string, the extra newline character gets encoded too.
+-->
+上面两个命令中的 `-n` 标志确保生成的文件在文本末尾不包含额外的换行符。
+这一点很重要，因为当 `kubectl` 读取文件并将内容编码为 base64 字符串时，多余的换行符也会被编码。
+
+<!--
+The `kubectl create secret` command packages these files into a Secret and creates
+the object on the API server.
+-->
+`kubectl create secret` 命令将这些文件打包成一个 Secret 并在 API 服务器上创建对象。
+
+```shell
+kubectl create secret generic db-user-pass \
+  --from-file=./username.txt \
+  --from-file=./password.txt
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+secret/db-user-pass created
+```
+
+<!--
+Default key name is the filename. You may optionally set the key name using
+`--from-file=[key=]source`. For example:
+-->
+默认密钥名称是文件名。 你可以选择使用 `--from-file=[key=]source` 来设置密钥名称。例如：
+
+```shell
+kubectl create secret generic db-user-pass \
+  --from-file=username=./username.txt \
+  --from-file=password=./password.txt
+```
+
+<!--
+You do not need to escape special characters in passwords from files
+().
+-->
+你无需转义文件（`--from-file`）中的密码的特殊字符。
+
+<!--
+You can also provide Secret data using the `--from-literal=<key>=<value>` tag.
+This tag can be specified more than once to provide multiple key-value pairs.
+Note that special characters such as `$`, `\`, `*`, `=`, and `!` will be
+interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing))
+and require escaping.
+In most shells, the easiest way to escape the password is to surround it with
+single quotes (`'`).  For example, if your actual password is `S!B\*d$zDsb=`,
+you should execute the command this way:
+-->
+你还可以使用 `--from-literal=<key>=<value>` 标签提供 Secret 数据。
+可以多次使用此标签，提供多个键值对。
+请注意，特殊字符（例如：`$`，`\`，`*`，`=` 和 `!`）由你的 [shell](https://en.wikipedia.org/wiki/Shell_(computing)) 解释执行，而且需要转义。
+
+```shell
+kubectl create secret generic dev-db-secret \
+  --from-literal=username=devuser \
+  --from-literal=password='S!B\*d$zDsb='
+```
+
+<!-- ## Verify the Secret -->
+## 验证 Secret    {#verify-the-secret}
+
+<!-- You can check that the secret was created: -->
+你可以检查 secret 是否已创建：
+
+```shell
+kubectl get secrets
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+NAME                  TYPE                                  DATA      AGE
+db-user-pass          Opaque                                2         51s
+```
+
+<!-- You can view a description of the `Secret`: -->
+你可以查看 `Secret` 的描述：
+
+```shell
+kubectl describe secrets/db-user-pass
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+Name:            db-user-pass
+Namespace:       default
+Labels:          <none>
+Annotations:     <none>
+
+Type:            Opaque
+
+Data
+====
+password.txt:    12 bytes
+username.txt:    5 bytes
+```
+
+<!--
+The commands `kubectl get` and `kubectl describe` avoid showing the contents
+of a `Secret` by default. This is to protect the `Secret` from being exposed
+accidentally to an onlooker, or from being stored in a terminal log.
+-->
+`kubectl get` 和 `kubectl describe` 命令默认不显示 `Secret` 的内容。
+这是为了防止 `Secret` 被意外暴露给旁观者或存储在终端日志中。
+
+<!-- ## Decoding the Secret  {#decoding-secret} -->
+## 解码 Secret  {#decoding-secret}
+
+<!--
+To view the contents of the Secret we just created, you can run the following
+command:
+-->
+要查看我们刚刚创建的 Secret 的内容，可以运行以下命令：
+
+```shell
+kubectl get secret db-user-pass -o jsonpath='{.data}'
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```json
+{"password.txt":"MWYyZDFlMmU2N2Rm","username.txt":"YWRtaW4="}
+```
+
+<!-- Now you can decode the `password.txt` data: -->
+现在你可以解码 `password.txt` 的数据：
+
+```shell
+echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+1f2d1e2e67df
+```
+
+<!-- ## Clean Up -->
+## 清理    {#clean-up}
+
+<!-- To delete the Secret you have just created: -->
+删除刚刚创建的 Secret：
+
+```shell
+kubectl delete secret db-user-pass
+```
+
+<!-- discussion -->
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
+- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+-->
+- 进一步阅读 [Secret 概念](/zh/docs/concepts/configuration/secret/)
+- 了解如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- 了解如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
diff --git a/content/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize.md
new file mode 100644
index 0000000000..65d73bb3f7
--- /dev/null
+++ b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize.md
@@ -0,0 +1,173 @@
+---
+title: 使用 Kustomize 管理 Secret
+content_type: task
+weight: 30
+description: 使用 kustomization.yaml 文件创建 Secret 对象。
+---
+<!-- 
+title: Managing Secret using Kustomize
+content_type: task
+weight: 30
+description: Creating Secret objects using kustomization.yaml file.
+-->
+
+<!-- overview -->
+
+<!--  
+Since Kubernetes v1.14, `kubectl` supports
+[managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/).
+Kustomize provides resource Generators to create Secrets and ConfigMaps. The
+Kustomize generators should be specified in a `kustomization.yaml` file inside
+a directory. After generating the Secret, you can create the Secret on the API
+server with `kubectl apply`.
+-->
+从 kubernetes v1.14 开始，`kubectl` 支持[使用 Kustomize 管理对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)。
+Kustomize 提供了资源生成器（Generators）来创建 Secret 和 ConfigMap。
+Kustomize 生成器应该在某个目录的 `kustomization.yaml` 文件中指定。
+生成 Secret 后，你可以使用 `kubectl apply` 在 API 服务器上创建该 Secret。
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+
+<!-- ## Create the Kustomization file -->
+## 创建 Kustomization 文件    {#create-the-kustomization-file}
+
+<!--  
+You can generate a Secret by defining a `secretGenerator` in a
+`kustomization.yaml` file that references other existing files.
+For example, the following kustomization file references the
+`./username.txt` and the `./password.txt` files:
+-->
+你可以在 `kustomization.yaml` 中定义 `secreteGenerator`，并在定义中引用其他现成的文件，生成 Secret。
+例如：下面的 kustomization 文件 引用了 `./username.txt` 和 `./password.txt` 文件：
+
+```yaml
+secretGenerator:
+- name: db-user-pass
+  files:
+  - username.txt
+  - password.txt
+```
+
+<!--  
+You can also define the `secretGenerator` in the `kustomization.yaml`
+file by providing some literals.
+For example, the following `kustomization.yaml` file contains two literals
+for `username` and `password` respectively:
+-->
+你也可以在 `kustomization.yaml` 文件中指定一些字面量定义 `secretGenerator`。
+例如：下面的 `kustomization.yaml` 文件中包含了 `username` 和 `password` 两个字面量：
+
+```yaml
+secretGenerator:
+- name: db-user-pass
+  literals:
+  - username=admin
+  - password=1f2d1e2e67df
+```
+
+<!-- Note that in both cases, you don't need to base64 encode the values. -->
+注意，上面两种情况，你都不需要使用 base64 编码。
+
+<!-- ## Create the Secret -->
+## 创建 Secret    {#create-the-secret}
+
+<!-- Apply the directory containing the `kustomization.yaml` to create the Secret. -->
+使用 `kubectl apply` 命令应用包含 `kustomization.yaml` 文件的目录创建 Secret。
+
+```shell
+kubectl apply -k .
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+secret/db-user-pass-96mffmfh4k created
+```
+
+<!-- 
+Note that when a Secret is generated, the Secret name is created by hashing
+the Secret data and appending the hash value to the name. This ensures that
+a new Secret is generated each time the data is modified. 
+-->
+请注意，生成 Secret 时，Secret 的名称最终是由 `name` 字段和数据的哈希值拼接而成。
+
+<!-- ## Check the Secret created -->
+## 检查创建的 Secret    {#check-the-secret-created}
+
+<!-- You can check that the secret was created: -->
+你可以检查刚才创建的 Secret：
+
+```shell
+kubectl get secrets
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+NAME                             TYPE                                  DATA      AGE
+db-user-pass-96mffmfh4k          Opaque                                2         51s
+```
+
+<!-- You can view a description of the secret: -->
+你可以看到 Secret 的描述：
+
+```shell
+kubectl describe secrets/db-user-pass-96mffmfh4k
+```
+
+<!-- The output is similar to: -->
+输出类似于：
+
+```
+Name:            db-user-pass
+Namespace:       default
+Labels:          <none>
+Annotations:     <none>
+
+Type:            Opaque
+
+Data
+====
+password.txt:    12 bytes
+username.txt:    5 bytes
+```
+
+<!-- 
+The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
+default. This is to protect the `Secret` from being exposed accidentally to an onlooker,
+or from being stored in a terminal log.
+To check the actual content of the encoded data, please refer to
+[decoding secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret). 
+-->
+`kubectl get` 和 `kubectl describe` 命令默认不显示 `Secret` 的内容。
+这是为了防止 `Secret` 被意外暴露给旁观者或存储在终端日志中。
+检查编码后的实际内容，请参考[解码 secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)。 
+-->
+
+
+<!-- ## Clean Up -->
+## 清理    {#clean-up}
+
+<!-- To delete the Secret you have just created: -->
+删除你刚才创建的 Secret：
+
+```shell
+kubectl delete secret db-user-pass-96mffmfh4k
+```
+
+<!-- Optional section; add links to information related to this topic. -->
+## {{% heading "whatsnext" %}}
+
+<!-- 
+- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
+- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) 
+-->
+- 进一步阅读 [Secret 概念](/zh/docs/concepts/configuration/secret/)
+- 了解如何[使用 `kubectl` 命令管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- 了解如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
diff --git a/content/zh/docs/tasks/configure-pod-container/_index.md b/content/zh/docs/tasks/configure-pod-container/_index.md
index 7a5b336076..4c71a44d89 100644
--- a/content/zh/docs/tasks/configure-pod-container/_index.md
+++ b/content/zh/docs/tasks/configure-pod-container/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "配置 Pods 和容器"
 weight: 20
+description: 对 Pod 和容器执行常见的配置任务。
 ---
diff --git a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 19a48d27fb..1f41db117a 100644
--- a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -30,7 +30,7 @@ allocated as much CPU as it requests.
 Each node in your cluster must have at least 1 CPU.
 
 A few of the steps on this page require you to run the
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
 service in your cluster. If you have the metrics-server
 running, you can skip those steps.
 
@@ -39,7 +39,8 @@ following command to enable metrics-server:
 -->
 集群中的每个节点必须至少有 1 个 CPU 可用才能运行本任务中的示例。
 
-本页的一些步骤要求你在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
+本页的一些步骤要求你在集群中运行
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
 服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。
 
 如果你正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
@@ -354,6 +355,20 @@ to specify a default value for the CPU limit.
   [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
   指定 CPU 限制的默认值。
 
+<!--
+## If you specify a CPU limit but do not specify a CPU request
+
+If you specify a CPU limit for a Container but do not specify a CPU request, Kubernetes automatically
+assigns a CPU request that matches the limit. Similarly, if a Container specifies its own memory limit,
+but does not specify a memory request, Kubernetes automatically assigns a memory request that matches
+the limit.
+-->
+## 如果你设置了 CPU 限制但未设置 CPU 请求
+
+如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其
+设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置
+内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。
+
 <!-- 
 ## Motivation for CPU requests and limits
 
diff --git a/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md
index c869ab0e9f..501090706b 100644
--- a/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md
+++ b/content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -5,11 +5,9 @@ weight: 10
 ---
 
 <!--
----
 title: Assign Memory Resources to Containers and Pods
 content_type: task
 weight: 10
----
 -->
 
 <!-- overview -->
@@ -19,34 +17,33 @@ This page shows how to assign a memory *request* and a memory *limit* to a
 Container. A Container is guaranteed to have as much memory as it requests,
 but is not allowed to use more memory than its limit.
 -->
-此页面显示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
-
-
-
+此页面展示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。
+我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 <!--
 Each node in your cluster must have at least 300 MiB of memory.
 -->
-您集群中的每个节点必须拥有至少 300 MiB 的内存。
+你集群中的每个节点必须拥有至少 300 MiB 的内存。
 
 <!--
 A few of the steps on this page require you to run the
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
 service in your cluster. If you have the metrics-server
 running, you can skip those steps.
 -->
-该页面上的一些步骤要求您在集群中运行 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 服务。如果您已经有在运行中的 metrics-server，则可以跳过这些步骤。
+该页面上的一些步骤要求你在集群中运行
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 服务。
+如果你已经有在运行中的 metrics-server，则可以跳过这些步骤。
 
 <!--
 If you are running Minikube, run the following command to enable the
 metrics-server:
 -->
-如果您运行的是 Minikube，可以运行下面的命令启用 metrics-server：
+如果你运行的是 Minikube，可以运行下面的命令启用 metrics-server：
 
 ```shell
 minikube addons enable metrics-server
@@ -68,13 +65,11 @@ reference to `metrics.k8s.io`.
 -->
 如果资源指标 API 可用，则输出结果将包含对 `metrics.k8s.io` 的引用信息。
 
-```shell
+```
 NAME
 v1beta1.metrics.k8s.io
 ```
 
-
-
 <!-- steps -->
 
 <!--
@@ -106,7 +101,7 @@ for the Pod:
 要为容器指定内存请求，请在容器资源清单中包含 `resources：requests` 字段。
 同理，要指定内存限制，请包含 `resources：limits`。
 
-在本练习中，您将创建一个拥有一个容器的 Pod。
+在本练习中，你将创建一个拥有一个容器的 Pod。
 容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。
 这是 Pod 的配置文件：
 
@@ -203,8 +198,10 @@ restarted, the kubelet restarts it, as with any other type of runtime failure.
 -->
 ## 超过容器限制的内存
 
-当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。
-如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超出其限制的内存，则终止容器。
+当节点拥有足够的可用内存时，容器可以使用其请求的内存。
+但是，容器不允许使用超过其限制的内存。
+如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。
+如果容器继续消耗超出其限制的内存，则终止容器。
 如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。
 
 <!--
@@ -212,7 +209,7 @@ In this exercise, you create a Pod that attempts to allocate more memory than it
 Here is the configuration file for a Pod that has one Container with a
 memory request of 50 MiB and a memory limit of 100 MiB:
 -->
-在本练习中，您将创建一个 Pod，尝试分配超出其限制的内存。
+在本练习中，你将创建一个 Pod，尝试分配超出其限制的内存。
 这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB：
 
 {{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
@@ -223,7 +220,7 @@ will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limi
 
 Create the Pod:
 -->
-在配置文件的 `args` 部分中，您可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
+在配置文件的 `args` 部分中，你可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
 
 创建 Pod：
 
@@ -277,7 +274,8 @@ lastState:
 The Container in this exercise can be restarted, so the kubelet restarts it. Repeat
 this command several times to see that the Container is repeatedly killed and restarted:
 -->
-本练习中的容器可以被重启，所以 kubelet 会重启它。多次运行下面的命令，可以看到容器在反复的被杀死和重启：
+本练习中的容器可以被重启，所以 kubelet 会重启它。
+多次运行下面的命令，可以看到容器在反复的被杀死和重启：
 
 ```shell
 kubectl get pod memory-demo-2 --namespace=mem-example
@@ -371,8 +369,8 @@ of any Node in your cluster.
 -->
 Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。
 
-在本练习中，你将创建一个 Pod，其内存请求超过了您集群中的任意一个节点所拥有的内存。
-这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了您集群中任何节点的容量。
+在本练习中，你将创建一个 Pod，其内存请求超过了你集群中的任意一个节点所拥有的内存。
+这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了你集群中任何节点的容量。
 
 {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
 
@@ -397,7 +395,8 @@ kubectl get pod memory-demo-3 --namespace=mem-example
 <!--
 The output shows that the Pod status is PENDING. That is, the Pod is not scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
 -->
-输出结果显示：Pod 处于 PENDING 状态。这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
+输出结果显示：Pod 处于 PENDING 状态。
+这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
 
 ```
 kubectl get pod memory-demo-3 --namespace=mem-example
@@ -436,7 +435,9 @@ For example, the following represent approximately the same value:
 -->
 ## 内存单位
 
-内存资源的基本单位是字节（byte）。您可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值：
+内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为
+纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。
+例如，下面是一些近似相同的值：
 
 ```shell
 128974848, 129e6, 129M , 123Mi
@@ -469,12 +470,13 @@ Container is automatically assigned the default limit. Cluster administrators ca
 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
 to specify a default value for the memory limit.
 -->
-* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。
-此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
+* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，
+  进而可能导致该节点调用 OOM Killer。
+  此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
 
 * 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。
-集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
-来指定默认的内存限制。
+  集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
+  来指定默认的内存限制。
 
 <!--
 ## Motivation for memory requests and limits
@@ -486,7 +488,9 @@ scheduled. By having a memory limit that is greater than the memory request, you
 -->
 ## 内存请求和限制的目的
 
-通过为集群中运行的容器配置内存请求和限制，您可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，您可以更好地安排 Pod 调度。通过让内存限制大于内存请求，您可以完成两件事：
+通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。
+通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。
+通过让内存限制大于内存请求，你可以完成两件事：
 
 <!--
 * The Pod can have bursts of activity where it makes use of memory that happens to be available.
@@ -508,34 +512,46 @@ Delete your namespace. This deletes all the Pods that you created for this task:
 kubectl delete namespace mem-example
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
+<!--
+### For app developers
 
+* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+
+* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
+-->
 ### 应用开发者扩展阅读
 
 * [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
 
 * [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
 
+
+<!--
+### For cluster administrators
+
+* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+
+* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+
+* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+
+* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+
+* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+
+* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
+-->
 ### 集群管理员扩展阅读
 
 * [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
-
 * [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
-
 * [配置命名空间的最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
-
 * [配置命名空间的最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
-
 * [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
-
 * [配置命名空间下 Pod 总数](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
-
 * [配置 API 对象配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
 
-
-
-
-
diff --git a/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
new file mode 100644
index 0000000000..159468a06b
--- /dev/null
+++ b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
@@ -0,0 +1,186 @@
+---
+title: 用节点亲和性把 Pods 分配到节点
+min-kubernetes-server-version: v1.10
+content_type: task
+weight: 120
+---
+<!--
+title: Assign Pods to Nodes using Node Affinity
+min-kubernetes-server-version: v1.10
+content_type: task
+weight: 120
+-->
+
+<!-- overview -->
+<!--
+This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a
+Kubernetes cluster.
+-->
+本页展示在 Kubernetes 集群中，如何使用节点亲和性把 Kubernetes Pod 分配到特定节点。
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+<!-- steps -->
+
+<!--
+## Add a label to a node
+
+1. List the nodes in your cluster, along with their labels:
+-->
+## 给节点添加标签
+
+1. 列出集群中的节点及其标签：
+
+    ```shell
+    kubectl get nodes --show-labels
+    ```
+    <!--
+    The output is similar to this:
+    -->
+    输出类似于此：
+
+    ```
+    NAME      STATUS    ROLES    AGE     VERSION        LABELS
+    worker0   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker0
+    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
+    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
+    ```
+    <!--
+    1. Chose one of your nodes, and add a label to it:
+    -->
+1. 选择一个节点，给它添加一个标签：
+
+    ```shell
+    kubectl label nodes <your-node-name> disktype=ssd
+    ```
+    <!--
+        where `<your-node-name>` is the name of your chosen node.
+
+    1. Verify that your chosen node has a `disktype=ssd` label:
+    -->
+
+    其中 `<your-node-name>` 是你所选节点的名称。
+
+2. 验证你所选节点具有 `disktype=ssd` 标签：
+
+    ```shell
+    kubectl get nodes --show-labels
+    ```
+
+    <!--
+    The output is similar to this:
+    -->
+    输出类似于此：
+
+    ```
+    NAME      STATUS    ROLES    AGE     VERSION        LABELS
+    worker0   Ready     <none>   1d      v1.13.0        ...,disktype=ssd,kubernetes.io/hostname=worker0
+    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
+    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
+    ```
+
+    <!--
+        In the preceding output, you can see that the `worker0` node has a
+        `disktype=ssd` label.
+    -->
+    在前面的输出中，可以看到 `worker0` 节点有一个 `disktype=ssd` 标签。
+
+<!--
+## Schedule a Pod using required node affinity
+
+This manifest describes a Pod that has a `requiredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. 
+This means that the pod will get scheduled only on a node that has a `disktype=ssd` label. 
+-->
+## 依据强制的节点亲和性调度 Pod  {#schedule-a-Pod-using-required-node-affinity}
+
+下面清单描述了一个 Pod，它有一个节点亲和性配置 `requiredDuringSchedulingIgnoredDuringExecution`，`disktype=ssd`。
+这意味着 pod 只会被调度到具有 `disktype=ssd` 标签的节点上。
+
+{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}}
+
+<!--
+1. Apply the manifest to create a Pod that is scheduled onto your
+   chosen node:
+-->
+1. 执行（Apply）此清单来创建一个调度到所选节点上的 Pod：
+
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml
+    ```
+
+    <!--
+    1. Verify that the pod is running on your chosen node:
+    -->
+1. 验证 pod 已经在所选节点上运行：
+
+    ```shell
+    kubectl get pods --output=wide
+    ```
+
+    <!--
+    The output is similar to this:
+    -->
+    输出类似于此：
+
+    ```
+    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+    ```
+    
+<!--    
+## Schedule a Pod using preferred node affinity
+
+This manifest describes a Pod that has a `preferredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. 
+This means that the pod will prefer a node that has a `disktype=ssd` label. 
+-->
+## 使用首选的节点亲和性调度 Pod {#schedule-a-Pod-using-preferred-node-affinity}
+
+本清单描述了一个Pod，它有一个节点亲和性设置 `preferredDuringSchedulingIgnoredDuringExecution`，`disktype: ssd`。
+这意味着 pod 将首选具有 `disktype=ssd` 标签的节点。
+
+{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}}
+
+<!--
+1. Apply the manifest to create a Pod that is scheduled onto your
+   chosen node:
+-->
+1. 执行此清单创建一个会调度到所选节点上的 Pod：
+    
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml
+    ```
+
+    <!--
+    1. Verify that the pod is running on your chosen node:
+    -->
+1. 验证 pod 是否在所选节点上运行：
+   
+    ```shell
+    kubectl get pods --output=wide
+    ```
+
+    <!--
+    The output is similar to this:
+    -->
+    输出类似于此：
+    
+    ```
+    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+    ```
+
+
+
+## {{% heading "whatsnext" %}}
+
+<!--
+Learn more about
+[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
+-->
+进一步了解
+[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md b/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md
new file mode 100644
index 0000000000..3a5221a1b0
--- /dev/null
+++ b/content/zh/docs/tasks/configure-pod-container/configure-gmsa.md
@@ -0,0 +1,494 @@
+---
+title: 为 Windows Pod 和容器配置 GMSA
+content_type: task
+weight: 20
+---
+<!--
+title: Configure GMSA for Windows Pods and containers
+content_type: task
+weight: 20
+-->
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+<!--
+This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.
+-->
+本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置
+[组管理的服务账号（Group Managed Service Accounts，GMSA）](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)。
+组管理的服务账号是活动目录（Active Directory）的一种特殊类型，提供自动化的
+密码管理、简化的服务主体名称（Service Principal Name，SPN）管理以及跨多个
+服务器将管理操作委派给其他管理员等能力。
+
+<!--
+In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads.
+-->
+在 Kubernetes 环境中，GMSA 凭据规约配置为 Kubernetes 集群范围的自定义资源
+（Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为
+使用 GMSA 来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便
+与其他 Windows 服务相交互。自 Kubernetes 1.16 版本起，Docker 运行时为
+Windows 负载支持 GMSA。
+
+## {{% heading "prerequisites" %}}
+
+<!--
+You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster:
+-->
+你需要一个 Kubernetes 集群，以及 `kubectl` 命令行工具，且工具必须已配置
+为能够与你的集群通信。集群预期包含 Windows 工作节点。
+本节讨论需要为每个集群执行一次的初始操作。
+
+<!--
+### Install the GMSACredentialSpec CRD
+
+A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
+Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
+-->
+### 安装 GMSACredentialSpec CRD
+
+你需要在集群上配置一个用于 GMSA 凭据规约资源的
+[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)，
+以便定义类型为 `GMSACredentialSpec` 的自定义资源。
+首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)
+并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml`
+安装 CRD。
+
+<!--
+### Install webhooks to validate GMSA users
+Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level:
+
+1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec.
+
+1. A validating webhook ensures all references to GMSAs are authorized to be used by the Pod service account.
+-->
+### 安装 Webhook 来验证 GMSA 用户
+
+你需要为 Kubernetes 集群配置两个 Webhook，在 Pod 或容器级别填充和检查
+GMSA 凭据规约引用。
+
+1. 一个修改模式（Mutating）的 Webhook，将对 GMSA 的引用（在 Pod 规约中体现为名字）
+   展开为完整凭据规约的 JSON 形式，并保存回 Pod 规约中。
+
+1. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权
+   给 Pod 的服务账号使用的。
+
+<!--
+Installing the above webhooks and associated objects require the steps below:
+
+1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster)
+
+1. Install a secret with the certificate from above.
+
+1. Create a deployment for the core webhook logic. 
+
+1. Create the validating and mutating webhook configurations referring to the deployment. 
+-->
+安装以上 Webhook 及其相关联的对象需要执行以下步骤：
+
+1. 创建一个证书密钥对（用于允许 Webhook 容器与集群通信）
+
+1. 安装一个包含如上证书的 Secret
+
+1. 创建一个包含核心 Webhook 逻辑的 Deployment
+
+1. 创建引用该 Deployment 的 Validating Webhook 和 Mutating Webhook 配置
+
+<!--
+A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a `-dry-run=server` option to allow you to review the changes that would be made to your cluster.
+
+The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters)
+-->
+你可以使用[这个脚本](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh)
+来部署和配置上述 GMSA Webhook 及相关联的对象。你还可以在运行脚本时设置 `--dry-run=server`
+选项以便审查脚本将会对集群做出的变更。
+
+脚本所使用的[YAML 模板](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)
+也可用于手动部署 Webhook 及相关联的对象，不过需要对其中的参数作适当替换。
+
+<!-- steps -->
+
+<!--
+## Configure GMSAs and Windows nodes in Active Directory
+
+Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)
+-->
+## 在活动目录中配置 GMSA 和 Windows 节点
+
+在配置 Kubernetes 中的 Pod 以使用 GMSA 之前，需要按
+[Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)
+中描述的那样先在活动目录中准备好期望的 GMSA。
+Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便
+访问与期望的 GSMA 相关联的秘密凭据数据。这一操作的描述位于
+[Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)
+中。
+
+<!--
+## Create GMSA credential spec resources
+With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). 
+-->
+## 创建 GMSA 凭据规约资源
+
+当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA 凭据
+规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。
+其中包含的信息主要用于容器运行时，便于后者向 Windows 描述容器所期望的 GMSA。
+GMSA 凭据规约可以使用
+[PowerShell 脚本](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1)
+以 YAML 格式生成。
+
+<!--
+Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it:
+
+1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1`
+
+1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`
+
+1. Use `Get-CredentialSpec` to show the path of the JSON file. 
+
+1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. 
+-->
+下面是手动以 JSON 格式生成 GMSA 凭据规约并对其进行 YAML 转换的步骤：
+
+1. 导入 CredentialSpec [模块](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1`
+
+1. 使用 `New-CredentialSpec` 来创建一个 JSON 格式的凭据规约。
+   要创建名为 `WebApp1` 的 GMSA 凭据规约，调用
+   `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`。
+
+1. 使用 `Get-CredentialSpec` 来显示 JSON 文件的路径。
+
+1. 将凭据规约从 JSON 格式转换为 YAML 格式，并添加必要的头部字段
+   `apiVersion`、`kind`、`metadata` 和 `credspec`，使其成为一个可以在
+   Kubernetes 中配置的 GMSACredentialSpec 自定义资源。
+
+<!--
+The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`:
+
+```yaml
+apiVersion: windows.k8s.io/v1alpha1
+kind: GMSACredentialSpec
+metadata:
+  name: gmsa-WebApp1  #This is an arbitrary name but it will be used as a reference
+credspec:
+  ActiveDirectoryConfig:
+    GroupManagedServiceAccounts:
+    - Name: WebApp1   #Username of the GMSA account
+      Scope: CONTOSO  #NETBIOS Domain Name
+    - Name: WebApp1   #Username of the GMSA account
+      Scope: contoso.com #DNS Domain Name
+  CmsPlugins:
+  - ActiveDirectory
+  DomainJoinConfig:
+    DnsName: contoso.com  #DNS Domain Name
+    DnsTreeName: contoso.com #DNS Domain Name Root
+    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID
+    MachineAccountName: WebApp1 #Username of the GMSA account
+    NetBiosName: CONTOSO  #NETBIOS Domain Name
+    Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA
+```
+-->
+下面的 YAML 配置描述的是一个名为 `gmsa-WebApp1` 的 GMSA 凭据规约：
+
+```yaml
+apiVersion: windows.k8s.io/v1alpha1
+kind: GMSACredentialSpec
+metadata:
+  name: gmsa-WebApp1  # 这是随意起的一个名字，将用作引用
+credspec:
+  ActiveDirectoryConfig:
+    GroupManagedServiceAccounts:
+    - Name: WebApp1   # GMSA 账号的用户名
+      Scope: CONTOSO  # NETBIOS 域名
+    - Name: WebApp1   # GMSA 账号的用户名
+      Scope: contoso.com # DNS 域名
+  CmsPlugins:
+  - ActiveDirectory
+  DomainJoinConfig:
+    DnsName: contoso.com  # DNS 域名
+    DnsTreeName: contoso.com # DNS 域名根
+    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # GUID
+    MachineAccountName: WebApp1 # GMSA 账号的用户名
+    NetBiosName: CONTOSO  # NETBIOS 域名
+    Sid: S-1-5-21-2126449477-2524075714-3094792973 # GMSA 的 SID
+```
+
+<!--
+The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml`
+-->
+上面的凭据规约资源可以保存为 `gmsa-Webapp1-credspec.yaml`，之后使用
+`kubectl apply -f gmsa-Webapp1-credspec.yml` 应用到集群上。
+
+<!--
+## Configure cluster role to enable RBAC on specific GMSA credential specs
+
+A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml`
+-->
+## 配置集群角色以启用对特定 GMSA 凭据规约的 RBAC
+
+你需要为每个 GMSA 凭据规约资源定义集群角色。
+该集群角色授权某主体（通常是一个服务账号）对特定的 GMSA 资源执行 `use` 动作。
+下面的示例显示的是一个集群角色，对前文创建的凭据规约 `gmsa-WebApp1` 执行鉴权。
+将此文件保存为 `gmsa-webapp1-role.yaml` 并执行 `kubectl apply -f gmsa-webapp1-role.yaml`。
+
+<!--
+```yaml
+#Create the Role to read the credspec
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: webapp1-role
+rules:
+- apiGroups: ["windows.k8s.io"]
+  resources: ["gmsacredentialspecs"]
+  verbs: ["use"]
+  resourceNames: ["gmsa-WebApp1"]
+```
+-->
+```yaml
+# 创建集群角色读取凭据规约
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: webapp1-role
+rules:
+- apiGroups: ["windows.k8s.io"]
+  resources: ["gmsacredentialspecs"]
+  verbs: ["use"]
+  resourceNames: ["gmsa-WebApp1"]
+```
+
+<!--
+## Assign role to service accounts to use specific GMSA credspecs
+A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above.
+-->
+## 将角色指派给要使用特定 GMSA 凭据规约的服务账号
+
+你需要将某个服务账号（Pod 配置所对应的那个）绑定到前文创建的集群角色上。
+这一绑定操作实际上授予该服务账号使用所指定的 GMSA 凭据规约资源的访问权限。
+下面显示的是一个绑定到集群角色 `webapp1-role` 上的 default 服务账号，使之
+能够使用前面所创建的 `gmsa-WebApp1` 凭据规约资源。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: allow-default-svc-account-read-on-gmsa-WebApp1
+  namespace: default
+subjects:
+- kind: ServiceAccount
+  name: default
+  namespace: default
+roleRef:
+  kind: ClusterRole
+  name: webapp1-role
+  apiGroup: rbac.authorization.k8s.io
+```
+
+<!--
+## Configure GMSA credential spec reference in Pod spec
+The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`:
+-->
+## 在 Pod 规约中配置 GMSA 凭据规约引用
+
+Pod 规约字段 `securityContext.windowsOptions.gmsaCredentialSpecName` 可用来
+设置对指定 GMSA 凭据规约自定义资源的引用。
+设置此引用将会配置 Pod 中的所有容器使用所给的 GMSA。
+下面是一个 Pod 规约示例，其中包含了对 `gmsa-WebApp1` 凭据规约的引用：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    run: with-creds
+  name: with-creds
+  namespace: default
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      run: with-creds
+  template:
+    metadata:
+      labels:
+        run: with-creds
+    spec:
+      securityContext:
+        windowsOptions:
+          gmsaCredentialSpecName: gmsa-webapp1
+      containers:
+      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
+        imagePullPolicy: Always
+        name: iis
+      nodeSelector:
+        kubernetes.io/os: windows
+```
+
+<!--
+Individual containers in a Pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example:
+-->
+Pod 中的各个容器也可以使用对应容器的 `securityContext.windowsOptions.gmsaCredentialSpecName`
+字段来设置期望使用的 GMSA 凭据规约。
+例如：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    run: with-creds
+  name: with-creds
+  namespace: default
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      run: with-creds
+  template:
+    metadata:
+      labels:
+        run: with-creds
+    spec:
+      containers:
+      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
+        imagePullPolicy: Always
+        name: iis
+        securityContext:
+          windowsOptions:
+            gmsaCredentialSpecName: gmsa-Webapp1
+      nodeSelector:
+        kubernetes.io/os: windows
+```
+
+<!--
+As Pod specs with GMSA fields populated (as described above) are applied in a cluster, the following sequence of events take place:
+
+1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec.
+
+1. The validating webhook ensures the service account associated with the Pod is authorized for the `use` verb on the specified GMSA credential spec.
+
+1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.
+-->
+当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次
+发生以下事件：
+
+1. Mutating Webhook 解析对 GMSA 凭据规约资源的引用，并将其全部展开，
+   得到 GMSA 凭据规约的实际内容。
+
+1. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约
+   上执行 `use` 动作。
+
+1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以
+   活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。
+
+<!--
+## Troubleshooting
+
+If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take.
+-->
+## 故障排查
+
+如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能
+的故障。
+
+<!--
+First, make sure the credspec has been passed to the Pod.  To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.  In the example below the Pod did not get the credspec correctly:
+-->
+首先，确保凭据规约已经被传递到 Pod。要实现这点，你需要先通过 `exec` 进入到
+你的 Pod 之一，检查 `nltest.exe /parentdomain` 命令的输出。
+在下面的例子中，Pod 未能正确地获得凭据规约：
+
+```shell
+kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
+
+Windows PowerShell
+Copyright (C) Microsoft Corporation. All rights reserved.
+
+PS C:\> nltest.exe /parentdomain
+Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
+PS C:\>
+```
+
+<!--
+If your Pod did get the credspec correctly, then next check communication with the domain.  First, from inside of your Pod, quickly do an nslookup to find the root of your domain.
+
+This will tell us 3 things:
+
+1. The Pod can reach the DC
+1. The DC can reach the Pod
+1. DNS is working correctly.
+-->
+如果 Pod 未能正确获得凭据规约，则下一步就要检查与域之间的通信。
+首先，从 Pod 内部快速执行一个 nslookup 操作，找到域根。
+
+这一操作会告诉我们三件事情：
+
+1. Pod 能否访问域控制器（DC）
+1. DC 能否访问 Pod
+1. DNS 是否正常工作
+
+<!--
+If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain.  To do this, again, `exec` into your Pod and run the `nltest.exe /query` command.
+-->
+如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了
+安全通信通道。要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中
+并执行 `nltest.exe /query` 命令。
+
+```shell
+PS C:\> nltest.exe /query
+I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
+```
+
+<!--
+This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec.  You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command.
+-->
+这一输出告诉我们，由于某些原因，Pod 无法使用凭据规约中的账号登录到域。
+你可以通过运行 `nltest.exe /sc_reset:domain.example` 命令尝试修复安全通道。
+
+```shell
+PS C:\> nltest /sc_reset:domain.example
+Flags: 30 HAS_IP  HAS_TIMESERV
+Trusted DC Name \\dc10.domain.example
+Trusted DC Connection Status Status = 0 0x0 NERR_Success
+The command completed successfully
+PS C:\>
+```
+
+<!--
+If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec.  If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete.
+-->
+如果上述命令修复了错误，你就可以通过向你的 Pod 规约添加生命周期回调来将此操作
+自动化。如果上述命令未能奏效，你就需要再次检查凭据规约，以确保其数据时正确的
+而且是完整的。
+
+```yaml
+        image: registry.domain.example/iis-auth:1809v1
+        lifecycle:
+          postStart:
+            exec:
+              command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
+        imagePullPolicy: IfNotPresent
+```
+
+<!--
+If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
+-->
+如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod 会自动执行所
+列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query`
+命令返回时没有错误信息。
+
+<!--
+## GMSA limitations
+When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44).
+-->
+## GMSA 的局限
+
+在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd)
+时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。
+容器会收到身份标识且 `nltest.exe /query` 调用也能正常工作。
+当需要访问网络共享资源时，建议使用
+[Docker EE 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee)。
+Windows Server 团队正在 Windows 内核中解决这一问题，并在将来发布解决此问题的补丁。
+你可以在 [Microsoft Windows Containers 问题跟踪列表](https://github.com/microsoft/Windows-Containers/issues/44)
+中查找这类更新。
+
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index f8ceb4f6d9..a2aa986464 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -284,7 +284,7 @@ affect the HTTP liveness probe.
 A third type of liveness probe uses a TCP Socket. With this configuration, the
 kubelet will attempt to open a socket to your container on the specified port.
 If it can establish a connection, the container is considered healthy, if it
-can’t it is considered a failure.
+can't it is considered a failure.
 -->
 ## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe}
 
@@ -419,7 +419,7 @@ Sometimes, applications are temporarily unable to serve traffic.
 For example, an application might need to load large data or configuration
 files during startup, or depend on external services after startup.
 In such cases, you don't want to kill the application,
-but you don’t want to send it requests either. Kubernetes provides
+but you don't want to send it requests either. Kubernetes provides
 readiness probes to detect and mitigate these situations. A pod with containers
 reporting that they are not ready does not receive traffic through Kubernetes
 Services.
@@ -534,7 +534,7 @@ in the range 1 to 65535.
 
 <!--
 For an HTTP probe, the kubelet sends an HTTP request to the specified path and
-port to perform the check. The kubelet sends the probe to the pod’s IP address,
+port to perform the check. The kubelet sends the probe to the pod's IP address,
 unless the address is overridden by the optional `host` field in `httpGet`. If
 `scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the
 certificate verification. In most scenarios, you do not want to set the `host` field.
@@ -565,7 +565,7 @@ to resolve it.
 * Learn more about
 [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
 -->
-* 进一步了解[容器探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
 
 <!--
 ### Reference
@@ -580,4 +580,3 @@ to resolve it.
 * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
 * [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
 
-
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
index 874700d19a..fc0b6f9583 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
@@ -5,58 +5,57 @@ weight: 60
 ---
 
 <!--
----
 title: Configure a Pod to Use a PersistentVolume for Storage
 content_type: task
 weight: 60
----
 -->
 
 <!-- overview -->
 
 <!--
-This page shows how to configure a Pod to use a PersistentVolumeClaim for storage.
+This page shows how to configure a Pod to use a
+{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
+for storage.
 Here is a summary of the process:
 
-1. A cluster administrator creates a PersistentVolume that is backed by physical
-storage. The administrator does not associate the volume with any Pod.
+1. You, as cluster administrator, create a PersistentVolume backed by physical
+storage. You do not associate the volume with any Pod.
 
-1. A cluster user creates a PersistentVolumeClaim, which gets automatically
-bound to a suitable PersistentVolume.
+1. You, now taking the role of a developer / cluster user, create a
+PersistentVolumeClaim that is automatically bound to a suitable
+PersistentVolume.
 
-1. The user creates a Pod that uses the PersistentVolumeClaim as storage.
+1. You create a Pod that uses the above PersistentVolumeClaim for storage.
 -->
-
-本文介绍如何配置 Pod 使用 PersistentVolumeClaim 作为存储。
+本文介绍如何配置 Pod 使用 
+{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
+作为存储。
 以下是该过程的总结：
 
-1. 集群管理员创建由物理存储支持的 PersistentVolume。管理员不将卷与任何 Pod 关联。
-
-1. 群集用户创建一个 PersistentVolumeClaim，它将自动绑定到合适的 PersistentVolume。
-
-1. 用户创建一个使用 PersistentVolumeClaim 作为存储的 Pod。
+1. 你作为集群管理员创建由物理存储支持的 PersistentVolume。你不会将卷与任何 Pod 关联。
 
+1. 你现在以开发人员或者集群用户的角色创建一个 PersistentVolumeClaim，
+   它将自动绑定到合适的 PersistentVolume。
 
+1. 你创建一个使用 PersistentVolumeClaim 作为存储的 Pod。
 
 ## {{% heading "prerequisites" %}}
 
-
 <!--
 * You need to have a Kubernetes cluster that has only one Node, and the kubectl
 command-line tool must be configured to communicate with your cluster. If you
 do not already have a single-node cluster, you can create one by using
-[Minikube](/docs/getting-started-guides/minikube).
+[Minikube](https://minikube.sigs.k8s.io/docs/).
 
 * Familiarize yourself with the material in
 [Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
 -->
 
-* 您需要一个包含单个节点的 Kubernetes 集群，并且必须配置 kubectl 命令行工具以便与集群交互。
-如果还没有单节点集群，可以使用 [Minikube](/docs/getting-started-guides/minikube) 创建一个。
-
-* 熟悉[持久卷](/docs/concepts/storage/persistent-volumes/)中的材料。
-
-
+* 你需要一个包含单个节点的 Kubernetes 集群，并且必须配置 kubectl 命令行工具以便与集群交互。
+  如果还没有单节点集群，可以使用
+  [Minikube](https://minikube.sigs.k8s.io/docs/) 创建一个。
+.
+* 熟悉[持久卷](/zh/docs/concepts/storage/persistent-volumes/)中的材料。
 
 <!-- steps -->
 
@@ -69,24 +68,67 @@ shell to your Node by entering `minikube ssh`.
 
 In your shell, create a `/mnt/data` directory:
 -->
-
 ## 在你的节点上创建一个 index.html 文件
 
-打开集群中节点的一个 shell。
-如何打开 shell 取决于集群的设置。
-例如，如果您正在使用 Minikube，那么可以通过输入 `minikube ssh` 来打开节点的 shell。
+打开集群中节点的一个 Shell。
+如何打开 Shell 取决于集群的设置。
+例如，如果你正在使用 Minikube，那么可以通过输入 `minikube ssh` 来打开节点的 Shell。
 
-在 shell 中，创建一个 `/mnt/data` 目录：
+在 Shell 中，创建一个 `/mnt/data` 目录：
 
-    mkdir /mnt/data
+<!--
+# This assumes that your Node uses "sudo" to run commands
+# as the superuser
+-->
+```shell
+# 这里假定你的节点使用 "sudo" 来以超级用户角色执行命令
+sudo mkdir /mnt/data
+```
 
 <!--
 In the `/mnt/data` directory, create an `index.html` file:
 -->
-
 在 `/mnt/data` 目录中创建一个 index.html 文件：
 
-    echo 'Hello from Kubernetes storage' > /mnt/data/index.html
+<!--
+# This again assumes that your Node uses "sudo" to run commands
+# as the superuser
+-->
+```
+# 这里再次假定你的节点使用 "sudo" 来以超级用户角色执行命令
+echo 'Hello from Kubernetes storage' > /mnt/data/index.html
+```
+
+<!--
+If your Node uses a tool for superuser access other than `sudo`, you can
+usually make this work if you replace `sudo` with the name of the other tool.
+-->
+{{< note >}}
+如果你的节点使用某工具而不是 `sudo` 来完成超级用户访问，你可以将上述命令
+中的 `sudo` 替换为该工具的名称。
+{{< /note >}}
+
+<!--
+Test that the `index.html` file exists:
+-->
+测试 `index.html` 文件确实存在：
+
+```shell
+cat /mnt/data/index.html
+```
+<!-- 
+The output should be:
+-->
+输出应该是：
+
+```
+Hello from Kubernetes storage
+```
+
+<!--
+You can now close the shell to your Node.
+-->
+现在你可以关闭节点的 Shell 了。
 
 <!--
 ## Create a PersistentVolume
@@ -95,12 +137,11 @@ In this exercise, you create a *hostPath* PersistentVolume. Kubernetes supports
 hostPath for development and testing on a single-node cluster. A hostPath
 PersistentVolume uses a file or directory on the Node to emulate network-attached storage.
 -->
-
 ## 创建 PersistentVolume
 
-在本练习中，您将创建一个 *hostPath* 类型的 PersistentVolume。
+在本练习中，你将创建一个 *hostPath* 类型的 PersistentVolume。
 Kubernetes 支持用于在单节点集群上开发和测试的 hostPath 类型的 PersistentVolume。
-hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟附带网络的存储。
+hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟网络附加存储。
 
 <!--
 In a production cluster, you would not use hostPath. Instead a cluster administrator
@@ -112,8 +153,8 @@ to set up
 
 Here is the configuration file for the hostPath PersistentVolume:
 -->
-
-在生产集群中，您不会使用 hostPath。集群管理员会提供网络存储资源，比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。
+在生产集群中，你不会使用 hostPath。
+集群管理员会提供网络存储资源，比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。
 集群管理员还可以使用 [StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage) 来设置[动态提供存储](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes)。
 
 下面是 hostPath PersistentVolume 的配置文件：
@@ -121,37 +162,27 @@ Here is the configuration file for the hostPath PersistentVolume:
 {{< codenew file="pods/storage/pv-volume.yaml" >}}
 
 <!--
-The configuration file specifies that the volume is at `/mnt/data` on the
-cluster's Node. The configuration also specifies a size of 10 gibibytes and
-an access mode of `ReadWriteOnce`, which means the volume can be mounted as
-read-write by a single Node. It defines the [StorageClass name](/docs/concepts/storage/persistent-volumes/#class)
-`manual` for the PersistentVolume, which will be used to bind
-PersistentVolumeClaim requests to this PersistentVolume.
-
 Create the PersistentVolume:
 -->
-
-配置文件指定了该卷位于集群节点上的 `/mnt/data` 目录。
-该配置还指定了 10 吉比特的卷大小和 `ReadWriteOnce` 的访问模式，这意味着该卷可以在单个节点上以读写方式挂载。
-它为 PersistentVolume 定义了 [StorageClass 名称](/docs/concepts/storage/persistent-volumes/#class) 为 `manual`，StorageClass 名称用来将 PersistentVolumeClaim 请求绑定到该 PersistentVolume。
-
 创建 PersistentVolume：
 
-    kubectl create -f https://k8s.io/examples/pods/storage/pv-volume.yaml
+```shell
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
+```
 
 <!--
 View information about the PersistentVolume:
 -->
-
 查看 PersistentVolume 的信息：
 
-    kubectl get pv task-pv-volume
+```shell
+kubectl get pv task-pv-volume
+```
 
 <!--
 The output shows that the PersistentVolume has a `STATUS` of `Available`. This
 means it has not yet been bound to a PersistentVolumeClaim.
 -->
-
 输出结果显示该 PersistentVolume 的`状态（STATUS）` 为 `Available`。
 这意味着它还没有被绑定给 PersistentVolumeClaim。
 
@@ -168,12 +199,12 @@ access for at least one Node.
 
 Here is the configuration file for the PersistentVolumeClaim:
 -->
-
 ## 创建 PersistentVolumeClaim
 
 下一步是创建一个 PersistentVolumeClaim。
 Pod 使用 PersistentVolumeClaim 来请求物理存储。
-在本练习中，您将创建一个 PersistentVolumeClaim，它请求至少 3 吉比特容量的卷，该卷至少可以为一个节点提供读写访问。
+在本练习中，你将创建一个 PersistentVolumeClaim，它请求至少 3 GB 容量的卷，
+该卷至少可以为一个节点提供读写访问。
 
 下面是 PersistentVolumeClaim 的配置文件：
 
@@ -182,10 +213,11 @@ Pod 使用 PersistentVolumeClaim 来请求物理存储。
 <!--
 Create the PersistentVolumeClaim:
 -->
-
 创建 PersistentVolumeClaim：
 
-    kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml
+```shell
+kubectl create -f https://k8s.io/examples/pods/storage/pv-claim.yaml
+```
 
 <!--
 After you create the PersistentVolumeClaim, the Kubernetes control plane looks
@@ -195,38 +227,45 @@ claim to the volume.
 
 Look again at the PersistentVolume:
 -->
-
 创建 PersistentVolumeClaim 之后，Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。
-如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume，则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。
+如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume，
+则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。
 
 再次查看 PersistentVolume 信息：
 
-    kubectl get pv task-pv-volume
+```shell
+kubectl get pv task-pv-volume
+```
 
 <!--
 Now the output shows a `STATUS` of `Bound`.
 -->
 现在输出的 `STATUS` 为 `Bound`。
 
-    NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
-    task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m
+```
+NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
+task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m
+```
 
 <!--
 Look at the PersistentVolumeClaim:
 -->
 查看 PersistentVolumeClaim：
 
-    kubectl get pvc task-pv-claim
+```
+kubectl get pvc task-pv-claim
+```
 
 <!--
 The output shows that the PersistentVolumeClaim is bound to your PersistentVolume,
 `task-pv-volume`.
 -->
-
 输出结果表明该 PersistentVolumeClaim 绑定了你的 PersistentVolume `task-pv-volume`。
 
-    NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
-    task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s
+```
+NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
+task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s
+```
 
 <!--
 ## Create a Pod
@@ -235,7 +274,6 @@ The next step is to create a Pod that uses your PersistentVolumeClaim as a volum
 
 Here is the configuration file for the Pod:
 -->
-
 ## 创建 Pod
 
 下一步是创建一个 Pod， 该 Pod 使用你的 PersistentVolumeClaim 作为存储卷。
@@ -251,51 +289,103 @@ is a volume.
 
 Create the Pod:
 -->
-
-注意 Pod 的配置文件指定了 PersistentVolumeClaim，但没有指定 PersistentVolume。对 Pod 而言，PersistentVolumeClaim 就是一个存储卷。
+注意 Pod 的配置文件指定了 PersistentVolumeClaim，但没有指定 PersistentVolume。
+对 Pod 而言，PersistentVolumeClaim 就是一个存储卷。
 
 创建 Pod：
 
-    kubectl create -f https://k8s.io/examples/pods/storage/pv-pod.yaml
+```shell
+kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml
+```
 
 <!--
 Verify that the Container in the Pod is running;
 -->
-
 检查 Pod 中的容器是否运行正常：
 
-    kubectl get pod task-pv-pod
+```shell
+kubectl get pod task-pv-pod
+```
 
 <!--
 Get a shell to the Container running in your Pod:
 -->
+打开一个 Shell 访问 Pod 中的容器：
 
-打开一个 shell 访问 Pod 中的容器：
-
-    kubectl exec -it task-pv-pod -- /bin/bash
+```shell
+kubectl exec -it task-pv-pod -- /bin/bash
+```
 
 <!--
 In your shell, verify that nginx is serving the `index.html` file from the
 hostPath volume:
 -->
+在 Shell 中，验证 nginx 是否正在从 hostPath 卷提供 `index.html` 文件：
 
-在 shell 中，验证 nginx 是否正在从 hostPath 卷提供 `index.html` 文件：
-
-    root@task-pv-pod:/# apt-get update
-    root@task-pv-pod:/# apt-get install curl
-    root@task-pv-pod:/# curl localhost
+<!--
+# Be sure to run these 3 commands inside the root shell that comes from
+# running "kubectl exec" in the previous step
+-->
+```
+# 一定要在上一步 "kubectl exec" 所返回的 Shell 中执行下面三个命令
+root@task-pv-pod:/# apt-get update
+root@task-pv-pod:/# apt-get install curl
+root@task-pv-pod:/# curl localhost
+```
 
 <!--
 The output shows the text that you wrote to the `index.html` file on the
 hostPath volume:
 -->
-
 输出结果是你之前写到 hostPath 卷中的 `index.html` 文件中的内容：
 
-    Hello from Kubernetes storage
+```
+Hello from Kubernetes storage
+```
+
+<!--
+If you see that message, you have successfully configured a Pod to
+use storage from a PersistentVolumeClaim.
+-->
+如果你看到此消息，则证明你已经成功地配置了 Pod 使用 PersistentVolumeClaim
+的存储。
+
+<!--
+## Clean up
+
+Delete the Pod,  the PersistentVolumeClaim and the PersistentVolume:
+-->
+## 清理    {#clean-up}
+
+删除 Pod、PersistentVolumeClaim 和 PersistentVolume 对象：
+
+```shell
+kubectl delete pod task-pv-pod
+kubectl delete pvc task-pv-claim
+kubectl delete pv task-pv-volume
+```
+
+<!--
+If you don't already have a shell open to the Node in your cluster,
+open a new shell the same way that you did earlier.
+
+In the shell on your Node, remove the file and directory that you created:
+-->
+如果你还没有连接到集群中节点的 Shell，可以按之前所做操作，打开一个新的 Shell。
+
+在节点的 Shell 上，删除你所创建的目录和文件：
 
 
+```shell
+# 这里假定你使用 "sudo" 来以超级用户的角色执行命令
+sudo rm /mnt/data/index.html
+sudo rmdir /mnt/data
+```
 
+<!--
+You can now close the shell to your Node.
+-->
+你现在可以关闭连接到节点的 Shell。
 
 <!-- discussion -->
 
@@ -310,13 +400,12 @@ PersistentVolume.
 
 Use the `pv.beta.kubernetes.io/gid` annotation as follows:
 -->
+## 访问控制  {#access-control}
 
-## 访问控制
-
-使用 group ID（GID）配置的存储仅允许 Pod 使用相同的 GID 进行写入。
-GID 不匹配或缺少将会导致许可被拒绝的错误。
-为了减少与用户的协调，管理员可以使用 GID 对 PersistentVolume 进行注解。
-这样 GID 就能自动的添加到使用 PersistentVolume 的任何 Pod 中。
+使用组 ID（GID）配置的存储仅允许 Pod 使用相同的 GID 进行写入。
+GID 不匹配或缺失将会导致无权访问错误。
+为了减少与用户的协调，管理员可以对 PersistentVolume 添加 GID 注解。
+这样 GID 就能自动添加到使用 PersistentVolume 的任何 Pod 中。
 
 使用 `pv.beta.kubernetes.io/gid` 注解的方法如下所示：
 
@@ -332,40 +421,36 @@ metadata:
 <!--
 When a Pod consumes a PersistentVolume that has a GID annotation, the annotated GID
 is applied to all Containers in the Pod in the same way that GIDs specified in the
-Pod’s security context are. Every GID, whether it originates from a PersistentVolume
-annotation or the Pod’s specification, is applied to the first process run in
+Pod's security context are. Every GID, whether it originates from a PersistentVolume
+annotation or the Pod's specification, is applied to the first process run in
 each Container.
 -->
+当 Pod 使用带有 GID 注解的 PersistentVolume 时，注解的 GID 会被应用于 Pod 中的所有容器，
+应用的方法与 Pod 的安全上下文中指定的 GID 相同。
+每个 GID，无论是来自 PersistentVolume 注解还是来自 Pod 规约，都会被应用于每个容器中
+运行的第一个进程。
 
-当 Pod 使用带有 GID 注解的 PersistentVolume 时，注解的 GID 会被应用于 Pod 中的所有容器，应用的方法与 Pod 的安全上下文中指定的 GID 相同。
-每个 GID，无论是来自 PersistentVolume 注解还是来自 Pod 的规范，都应用于每个容器中运行的第一个进程。
-
-{{< note >}}
 <!--
 When a Pod consumes a PersistentVolume, the GIDs associated with the
 PersistentVolume are not present on the Pod resource itself.
 -->
-当 Pod 使用 PersistentVolume 时，与 PersistentVolume 关联的 GID 不会在 Pod 本身的资源对象上出现。
+{{< note >}}
+当 Pod 使用 PersistentVolume 时，与 PersistentVolume 关联的 GID 不会在 Pod
+资源本身的对象上出现。
 {{< /note >}}
 
-
-
-
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
 * Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
 -->
-
-* 进一步了解 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
-* 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)。
+* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
+* 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)
 
 <!--
 ### Reference
 -->
-
 ### 参考
 
 * [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
@@ -374,4 +459,3 @@ PersistentVolume are not present on the Pod resource itself.
 * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
 
 
-
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
index bdf8695bbc..4e8a745908 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
@@ -850,7 +850,7 @@ As explained in [Create ConfigMaps from files](#create-configmaps-from-files), w
 -->
 ## 将 ConfigMap 数据添加到一个卷中
 
-如基于文件创建 ConfigMap](#create-configmaps-from-files) 中所述，当你使用 
+如基于文件创建 [ConfigMap](#create-configmaps-from-files) 中所述，当你使用 
 `--from-file` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的键，
 文件内容成为键对应的值。
 
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
index 1807a22fee..90cf168b75 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
@@ -55,7 +55,7 @@ Init 容器将共享卷挂载到了 `/work-dir` 目录，应用容器将共享
 Init 容器执行完下面的命令就终止：
 
 ```shell
-wget -O /work-dir/index.html http://kubernetes.io
+wget -O /work-dir/index.html http://info.cern.ch
 ```
 
 <!--
@@ -118,16 +118,13 @@ The output shows that nginx is serving the web page that was written by the init
 结果表明 nginx 正在为 Init 容器编写的 web 页面服务：
 
 ```
-<!Doctype html>
-<html id="home">
+<html><head></head><body><header>
+<title>http://info.cern.ch</title>
+</header>
 
-<head>
-...
-"url": "http://kubernetes.io/"}</script>
-</head>
-<body>
+<h1>http://info.cern.ch - home of the first website</h1>
   ...
-  <p>Kubernetes is open source giving you the freedom to take advantage ...</p>
+<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
   ...
 ```
 
diff --git a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
index 9808a3b9cb..d2ae4a6b2f 100644
--- a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -59,8 +59,8 @@ kubectl create namespace qos-example
 
 For a Pod to be given a QoS class of Guaranteed:
 
-* Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
-* Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.
 
 Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
 memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
@@ -69,8 +69,8 @@ memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU r
 
 对于 QoS 类为 Guaranteed 的 Pod：
 
-* Pod 中的每个容器必须指定内存请求和内存限制，并且两者要相等。
-* Pod 中的每个容器必须指定 CPU 请求和 CPU 限制，并且两者要相等。
+* Pod 中的每个容器，包含初始化容器，必须指定内存请求和内存限制，并且两者要相等。
+* Pod 中的每个容器，包含初始化容器，必须指定 CPU 请求和 CPU 限制，并且两者要相等。
 
 下面是包含一个容器的 Pod 配置文件。
 容器设置了内存请求和内存限制，值都是 200 MiB。
diff --git a/content/zh/docs/tasks/configure-pod-container/security-context.md b/content/zh/docs/tasks/configure-pod-container/security-context.md
new file mode 100644
index 0000000000..07ab6961e4
--- /dev/null
+++ b/content/zh/docs/tasks/configure-pod-container/security-context.md
@@ -0,0 +1,743 @@
+---
+title: 为 Pod 或容器配置安全性上下文
+content_type: task
+weight: 80
+---
+<!--
+reviewers:
+- erictune
+- mikedanese
+- thockin
+title: Configure a Security Context for a Pod or Container
+content_type: task
+weight: 80
+-->
+
+<!-- overview -->
+
+<!--
+A security context defines privilege and access control settings for
+a Pod or Container. Security context settings include, but are not limited to:
+
+* Discretionary Access Control: Permission to access an object, like a file, is based on
+  [user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).
+* [Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux): Objects are assigned security labels.
+* Running as privileged or unprivileged.
+* [Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/): 
+  Give a process some privileges, but not all the privileges of the root user.
+-->
+安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。
+安全上下文包括但不限于：
+
+* 自主访问控制（Discretionary Access Control）：基于
+  [用户 ID（UID）和组 ID（GID）](https://wiki.archlinux.org/index.php/users_and_groups).
+  来判定对对象（例如文件）的访问权限。
+* [安全性增强的 Linux（SELinux）](https://zh.wikipedia.org/wiki/%E5%AE%89%E5%85%A8%E5%A2%9E%E5%BC%BA%E5%BC%8FLinux)：
+  为对象赋予安全性标签。
+* 以特权模式或者非特权模式运行。
+* [Linux 权能](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/): 
+  为进程赋予 root 用户的部分特权而非全部特权。
+<!--
+* [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs.
+* [Seccomp](https://en.wikipedia.org/wiki/Seccomp): Filter a process's system calls.
+* AllowPrivilegeEscalation: Controls whether a process can gain more
+  privileges than its parent process. This bool directly controls whether the
+  [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
+  flag gets set on the container process. AllowPrivilegeEscalation is true
+  always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`.
+* readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
+-->
+* [AppArmor](/zh/docs/tutorials/clusters/apparmor/)：使用程序框架来限制个别程序的权能。
+* [Seccomp](https://en.wikipedia.org/wiki/Seccomp)：过滤进程的系统调用。
+* AllowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。
+  此布尔值直接控制是否为容器进程设置
+  [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)标志。
+  当容器以特权模式运行或者具有 `CAP_SYS_ADMIN` 权能时，AllowPrivilegeEscalation 总是为 true。
+* readOnlyRootFilesystem：以只读方式加载容器的根文件系统。
+
+<!--
+The above bullets are not a complete set of security context settings - please see
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
+for a comprehensive list.
+
+For more information about security mechanisms in Linux, see
+[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
+-->
+以上条目不是安全上下文设置的完整列表 -- 请参阅
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
+了解其完整列表。
+
+关于在 Linux 系统中的安全机制的更多信息，可参阅
+[Linux 内核安全性能力概述](https://www.linux.com/learn/overview-linux-kernel-security-features)。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+<!--
+## Set the security context for a Pod
+
+To specify security settings for a Pod, include the `securityContext` field
+in the Pod specification. The `securityContext` field is a
+[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) object.
+The security settings that you specify for a Pod apply to all Containers in the Pod.
+Here is a configuration file for a Pod that has a `securityContext` and an `emptyDir` volume:
+-->
+## 为 Pod 设置安全性上下文   {#set-the-security-context-for-a-pod}
+
+要为 Pod 设置安全性设置，可在 Pod 规约中包含 `securityContext` 字段。`securityContext` 字段值是一个
+[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
+对象。你为 Pod 所设置的安全性配置会应用到 Pod 中所有 Container 上。
+下面是一个 Pod 的配置文件，该 Pod 定义了 `securityContext` 和一个 `emptyDir` 卷：
+
+{{< codenew file="pods/security/security-context.yaml" >}}
+
+<!--
+In the configuration file, the `runAsUser` field specifies that for any Containers in
+the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for
+all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers
+will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified.
+Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000.
+The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000.
+
+Create the Pod:
+-->
+在配置文件中，`runAsUser` 字段指定 Pod 中的所有容器内的进程都使用用户 ID 1000
+来运行。`runAsGroup` 字段指定所有容器中的进程都以主组 ID 3000 来运行。
+如果忽略此字段，则容器的主组 ID 将是 root（0）。
+当 `runAsGroup` 被设置时，所有创建的文件也会划归用户 1000 和组 3000。
+由于 `fsGroup` 被设置，容器中所有进程也会是附组 ID 2000 的一部分。
+卷 `/data/demo` 及在该卷中创建的任何文件的属主都会是组 ID 2000。
+
+创建该 Pod：
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml
+```
+
+<!--
+Verify that the Pod's Container is running:
+-->
+检查 Pod 的容器处于运行状态：
+
+```shell
+kubectl get pod security-context-demo
+```
+
+<!--
+Get a shell to the running Container:
+-->
+开启一个 Shell 进入到运行中的容器：
+
+```shell
+kubectl exec -it security-context-demo -- sh
+```
+
+<!--
+In your shell, list the running processes:
+-->
+在你的 Shell 中，列举运行中的进程：
+
+```shell
+ps
+```
+
+<!--
+The output shows that the processes are running as user 1000, which is the value of `runAsUser`:
+-->
+输出显示进程以用户 1000 运行，即 `runAsUser` 所设置的值：
+
+```shell
+PID   USER     TIME  COMMAND
+    1 1000      0:00 sleep 1h
+    6 1000      0:00 sh
+...
+```
+
+<!--
+In your shell, navigate to `/data`, and list the one directory:
+-->
+在你的 Shell 中，进入 `/data` 目录列举其内容：
+
+```shell
+cd /data
+ls -l
+```
+
+<!--
+The output shows that the `/data/demo` directory has group ID 2000, which is
+the value of `fsGroup`.
+-->
+输出显示 `/data/demo` 目录的组 ID 为 2000，即 `fsGroup` 的设置值：
+
+```shell
+drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo
+```
+
+<!--
+In your shell, navigate to `/data/demo`, and create a file:
+-->
+在你的 Shell 中，进入到 `/data/demo` 目录下创建一个文件：
+
+```shell
+cd demo
+echo hello > testfile
+```
+
+<!--
+List the file in the `/data/demo` directory:
+-->
+列举 `/data/demo` 目录下的文件：
+
+```shell
+ls -l
+```
+
+<!--
+The output shows that `testfile` has group ID 2000, which is the value of `fsGroup`.
+-->
+输出显示 `testfile` 的组 ID 为 2000，也就是 `fsGroup` 所设置的值：
+
+```shell
+-rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile
+```
+
+<!--
+Run the following command:
+-->
+运行下面的命令：
+
+```shell
+id
+```
+
+输出为：
+```
+uid=1000 gid=3000 groups=2000
+```
+
+<!--
+You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was omitted the gid would
+remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
+the required group permissions for root(0) group.
+
+Exit your shell:
+-->
+你会看到 `gid` 值为 3000，也就是 `runAsGroup` 字段的值。
+如果 `runAsGroup` 被忽略，则 `gid` 会取值 0（root），而进程就能够与 root
+用户组所拥有以及要求 root 用户组访问权限的文件交互。
+
+退出你的 Shell：
+
+```shell
+exit
+```
+
+<!--
+## Configure volume permission and ownership change policy for Pods
+-->
+## 为 Pod 配置卷访问权限和属主变更策略
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+<!--
+By default, Kubernetes recursively changes ownership and permissions for the contents of each
+volume to match the `fsGroup` specified in a Pod's `securityContext` when that volume is
+mounted.
+For large volumes, checking and changing ownership and permissions can take a lot of time,
+slowing Pod startup. You can use the `fsGroupChangePolicy` field inside a `securityContext`
+to control the way that Kubernetes checks and manages ownership and permissions
+for a volume.
+-->
+默认情况下，Kubernetes 在挂载一个卷时，会递归地更改每个卷中的内容的属主和访问权限，使之与 Pod
+的 `securityContext` 中指定的 `fsGroup` 匹配。
+对于较大的数据卷，检查和变更属主与访问权限可能会花费很长时间，降低 Pod 启动速度。
+你可以在 `securityContext` 中使用 `fsGroupChangePolicy` 字段来控制 Kubernetes
+检查和管理卷属主和访问权限的方式。
+
+<!--
+**fsGroupChangePolicy** -  `fsGroupChangePolicy` defines behavior for changing ownership and permission of the volume
+before being exposed inside a Pod. This field only applies to volume types that support
+`fsGroup` controlled ownership and permissions. This field has two possible values:
+
+* _OnRootMismatch_: Only change permissions and ownership if permission and ownership of root directory does not match with expected permissions of the volume. This could help shorten the time it takes to change ownership and permission of a volume.
+* _Always_: Always change permission and ownership of the volume when volume is mounted.
+
+For example:
+-->
+**fsGroupChangePolicy** - `fsGroupChangePolicy` 定义在卷被暴露给 Pod 内部之前对其
+内容的属主和访问许可进行变更的行为。此字段仅适用于那些支持使用 `fsGroup` 来
+控制属主与访问权限的卷类型。此字段的取值可以是：
+
+* `OnRootMismatch`：只有根目录的属主与访问权限与卷所期望的权限不一致时，
+  才改变其中内容的属主和访问权限。这一设置有助于缩短更改卷的属主与访问
+  权限所需要的时间。
+* `Always`：在挂载卷时总是更改卷中内容的属主和访问权限。
+
+例如：
+
+```yaml
+securityContext:
+  runAsUser: 1000
+  runAsGroup: 3000
+  fsGroup: 2000
+  fsGroupChangePolicy: "OnRootMismatch"
+```
+
+<!--
+This is an alpha feature. To use it, enable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ConfigurableFSGroupPolicy` for the kube-api-server, the kube-controller-manager, and for the kubelet.
+-->
+这是一个 Alpha 阶段的功能特性。要使用此特性，需要在 `kube-apiserver`、`kube-controller-manager`
+和 `kubelet` 上启用 `ConfigurableFSGroupPolicy`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+
+<!--
+This field has no effect on ephemeral volume types such as
+[`secret`](/docs/concepts/storage/volumes/#secret),
+[`configMap`](/docs/concepts/storage/volumes/#configmap),
+and [`emptydir`](/docs/concepts/storage/volumes/#emptydir).
+-->
+{{< note >}}
+此字段对于[`secret`](/zh/docs/concepts/storage/volumes/#secret)、
+[`configMap`](/zh/docs/concepts/storage/volumes/#configmap)
+和 [`emptydir`](/zh/docs/concepts/storage/volumes/#emptydir)
+这类临时性存储无效。
+{{< /note >}}
+
+<!--
+## Set the security context for a Container
+
+To specify security settings for a Container, include the `securityContext` field
+in the Container manifest. The `securityContext` field is a
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) object.
+Security settings that you specify for a Container apply only to
+the individual Container, and they override settings made at the Pod level when
+there is overlap. Container settings do not affect the Pod's Volumes.
+
+Here is the configuration file for a Pod that has one Container. Both the Pod
+and the Container have a `securityContext` field:
+-->
+## 为 Container 设置安全性上下文  {#set-the-security-context-for-a-container}
+
+若要为 Container 设置安全性配置，可以在 Container 清单中包含 `securityContext` 
+字段。`securityContext` 字段的取值是一个
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
+对象。你为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置
+在与 Pod 层面设置的内容发生重叠时，会重载后者。Container 层面的设置不会影响
+到 Pod 的卷。
+
+下面是一个 Pod 的配置文件，其中包含一个 Container。Pod 和 Container 都有
+`securityContext` 字段：
+
+{{< codenew file="pods/security/security-context-2.yaml" >}}
+
+<!--
+Create the Pod:
+-->
+创建该 Pod：
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml
+```
+
+<!--
+Verify that the Pod's Container is running:
+-->
+验证 Pod 中的容器处于运行状态：
+
+```shell
+kubectl get pod security-context-demo-2
+```
+
+<!--
+Get a shell into the running Container:
+-->
+启动一个 Shell 进入到运行中的容器内：
+
+```shell
+kubectl exec -it security-context-demo-2 -- sh
+```
+
+<!--
+In your shell, list the running processes:
+-->
+在你的 Shell 中，列举运行中的进程：
+
+```shell
+ps aux
+```
+
+<!--
+The output shows that the processes are running as user 2000. This is the value
+of `runAsUser` specified for the Container. It overrides the value 1000 that is
+specified for the Pod.
+-->
+输出显示进程以用户 2000 账号运行。该值是在 Container 的 `runAsUser` 中设置的。
+该设置值重载了 Pod 层面所设置的值 1000。
+
+```
+USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
+2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
+2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js
+...
+```
+
+<!--
+Exit your shell:
+-->
+退出你的 Shell：
+
+```shell
+exit
+```
+
+<!--
+## Set capabilities for a Container
+
+With [Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html),
+you can grant certain privileges to a process without granting all the privileges
+of the root user. To add or remove Linux capabilities for a Container, include the
+`capabilities` field in the `securityContext` section of the Container manifest.
+
+First, see what happens when you don't include a `capabilities` field.
+Here is configuration file that does not add or remove any Container capabilities:
+-->
+## 为 Container 设置权能   {#set-capabilities-for-a-container}
+
+使用 [Linux 权能](https://man7.org/linux/man-pages/man7/capabilities.7.html)，你可以
+赋予进程 root 用户所拥有的某些特权，但不必赋予其全部特权。
+要为 Container 添加或移除 Linux 权能，可以在 Container 清单的 `securityContext` 节
+包含 `capabilities` 字段。
+
+首先，查看不包含 `capabilities` 字段时候会发生什么。
+下面是一个配置文件，其中没有添加或移除容器的权能：
+
+{{< codenew file="pods/security/security-context-3.yaml" >}}
+
+<!--
+Create the Pod:
+-->
+创建该 Pod：
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml
+```
+
+<!--
+Verify that the Pod's Container is running:
+-->
+验证 Pod 的容器处于运行状态：
+
+```shell
+kubectl get pod security-context-demo-3
+```
+
+<!--
+Get a shell into the running Container:
+-->
+启动一个 Shell 进入到运行中的容器：
+
+```shell
+kubectl exec -it security-context-demo-3 -- sh
+```
+
+<!--
+In your shell, list the running processes:
+-->
+在你的 Shell 中，列举运行中的进程：
+
+```shell
+ps aux
+```
+
+<!--
+The output shows the process IDs (PIDs) for the Container:
+-->
+输出显示容器中进程 ID（PIDs）：
+
+```shell
+USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
+root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
+root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js
+```
+
+<!--
+In your shell, view the status for process 1:
+-->
+在你的 Shell 中，查看进程 1 的状态：
+
+```shell
+cd /proc/1
+cat status
+```
+
+<!--
+The output shows the capabilities bitmap for the process:
+-->
+输出显示进程的权能位图：
+
+```
+...
+CapPrm:	00000000a80425fb
+CapEff:	00000000a80425fb
+...
+```
+
+<!--
+Make a note of the capabilities bitmap, and then exit your shell:
+-->
+记下进程权能位图，之后退出你的 Shell：
+
+```shell
+exit
+```
+
+<!--
+Next, run a Container that is the same as the preceding container, except
+that it has additional capabilities set.
+
+Here is the configuration file for a Pod that runs one Container. The configuration
+adds the `CAP_NET_ADMIN` and `CAP_SYS_TIME` capabilities:
+-->
+接下来运行一个与前例中容器相同的容器，只是这个容器有一些额外的权能设置。
+
+下面是一个 Pod 的配置，其中运行一个容器。配置为容器添加 `CAP_NET_ADMIN` 和
+`CAP_SYS_TIME` 权能：
+
+{{< codenew file="pods/security/security-context-4.yaml" >}}
+
+<!--
+Create the Pod:
+-->
+创建 Pod：
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml
+```
+
+<!--
+Get a shell into the running Container:
+-->
+启动一个 Shell，进入到运行中的容器：
+
+```shell
+kubectl exec -it security-context-demo-4 -- sh
+```
+
+<!--
+In your shell, view the capabilities for process 1:
+-->
+在你的 Shell 中，查看进程 1 的权能：
+
+```shell
+cd /proc/1
+cat status
+```
+
+<!--
+The output shows capabilities bitmap for the process:
+-->
+输出显示的是进程的权能位图：
+
+```shell
+...
+CapPrm:	00000000aa0435fb
+CapEff:	00000000aa0435fb
+...
+```
+
+<!--
+Compare the capabilities of the two Containers:
+-->
+比较两个容器的权能位图：
+
+```
+00000000a80425fb
+00000000aa0435fb
+```
+
+<!--
+In the capability bitmap of the first container, bits 12 and 25 are clear. In the second container,
+bits 12 and 25 are set. Bit 12 is `CAP_NET_ADMIN`, and bit 25 is `CAP_SYS_TIME`.
+See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h)
+for definitions of the capability constants.
+-->
+在第一个容器的权能位图中，位 12 和 25 是没有设置的。在第二个容器中，位 12
+和 25 是设置了的。位 12 是 `CAP_NET_ADMIN` 而位 25 则是 `CAP_SYS_TIME`。
+参见 [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h)
+了解权能常数的定义。
+
+<!--
+Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
+-->
+{{< note >}}
+Linux 权能常数定义的形式为 `CAP_XXX`。但是你在 Container 清单中列举权能时，
+要将权能名称中的 `CAP_` 部分去掉。例如，要添加 `CAP_SYS_TIME`，可在权能
+列表中添加 `SYS_TIME`。
+{{< /note >}}
+
+<!--
+## Set the Seccomp Profile for a Container
+
+To set the Seccomp profile for a Container, include the `seccompProfile` field
+in the `securityContext` section of your Pod or Container manifest. The
+`seccompProfile` field is a
+[SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version"
+>}}/#seccompprofile-v1-core) object consisting of `type` and `localhostProfile`.
+Valid options for `type` include `RuntimeDefault`, `Unconfined`, and
+`Localhost`. `localhostProfile` must only be set set if `type: Localhost`. It
+indicates the path of the pre-configured profile on the node, relative to the
+kubelet's configured Seccomp profile location (configured with the `-root-dir`
+flag).
+
+Here is an example that sets the Seccomp profile to the node's container runtime
+default profile:
+-->
+## 为容器设置 Seccomp 样板
+
+若要为容器设置 Seccomp 样板（Profile），可在你的 Pod 或 Container 清单的
+`securityContext` 节中包含 `seccompProfile` 字段。该字段是一个 
+[SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#seccompprofile-v1-core)
+对象，包含 `type` 和 `localhostProfile` 属性。
+`type` 的合法选项包括 `RuntimeDefault`、`Unconfined` 和 `Localhost`。
+`localhostProfile` 只能在 `type: Localhost` 配置下才需要设置。
+该字段标明节点上预先配置的样板的路径，路径是相对于 kubelet 所配置的
+Seccomp 样板路径（使用 `--root-dir` 配置）而言的。
+
+下面是一个例子，设置容器使用节点上容器运行时的默认样板作为 Seccomp 样板：
+
+```yaml
+...
+securityContext:
+  seccompProfile:
+    type: RuntimeDefault
+```
+
+<!--
+Here is an example that sets the Seccomp profile to a pre-configured file at
+`<kubelet-root-dir>/seccomp/my-profiles/profile-allow.json`:
+-->
+下面是另一个例子，将 Seccomp 的样板设置为位于
+`<kubelet-根目录>/seccomp/my-profiles/profile-allow.json`
+的一个预先配置的文件。
+
+```yaml
+...
+securityContext:
+  seccompProfile:
+    type: Localhost
+    localhostProfile: my-profiles/profile-allow.json
+```
+
+<!--
+## Assign SELinux labels to a Container
+
+To assign SELinux labels to a Container, include the `seLinuxOptions` field in
+the `securityContext` section of your Pod or Container manifest. The
+`seLinuxOptions` field is an
+[SELinuxOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#selinuxoptions-v1-core)
+object. Here's an example that applies an SELinux level:
+-->
+## 为 Container 赋予 SELinux 标签
+
+若要给 Container 设置 SELinux 标签，可以在 Pod 或 Container 清单的
+`securityContext` 节包含 `seLinuxOptions` 字段。
+`seLinuxOptions` 字段的取值是一个
+[SELinuxOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#selinuxoptions-v1-core)
+对象。下面是一个应用 SELinux 标签的例子：
+
+```yaml
+...
+securityContext:
+  seLinuxOptions:
+    level: "s0:c123,c456"
+```
+
+<!--
+To assign SELinux labels, the SELinux security module must be loaded on the host operating system.
+-->
+{{< note >}}
+要指定 SELinux，需要在宿主操作系统中装载 SELinux 安全性模块。
+{{< /note >}}
+
+<!--
+## Discussion
+
+The security context for a Pod applies to the Pod's Containers and also to
+the Pod's Volumes when applicable. Specifically `fsGroup` and `seLinuxOptions` are
+applied to Volumes as follows:
+-->
+## 讨论   {#discussion}
+
+Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的卷（如果有的话）。
+尤其是，`fsGroup` 和 `seLinuxOptions` 按下面的方式应用到挂载卷上：
+
+<!--
+* `fsGroup`: Volumes that support ownership management are modified to be owned
+and writable by the GID specified in `fsGroup`. See the
+[Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
+for more details.
+
+* `seLinuxOptions`: Volumes that support SELinux labeling are relabeled to be accessible
+by the label specified under `seLinuxOptions`. Usually you only
+need to set the `level` section. This sets the
+[Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)
+label given to all Containers in the Pod as well as the Volumes.
+-->
+* `fsGroup`：支持属主管理的卷会被修改，将其属主变更为 `fsGroup` 所指定的 GID，
+  并且对该 GID 可写。进一步的细节可参阅
+  [属主变更设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)。
+
+* `seLinuxOptions`：支持 SELinux 标签的卷会被重新打标签，以便可被 `seLinuxOptions`
+  下所设置的标签访问。通常你只需要设置 `level` 部分。
+  该部分设置的是赋予 Pod 中所有容器及卷的
+  [多类别安全性（Multi-Category Security，MCS)](https://selinuxproject.org/page/NB_MLS)标签。
+
+  <!--
+  After you specify an MCS label for a Pod, all Pods with the same label can
+  access the Volume. If you need inter-Pod protection, you must assign a unique
+  MCS label to each Pod.
+  -->
+  {{< warning >}}
+  在为 Pod 设置 MCS 标签之后，所有带有相同标签的 Pod 可以访问该卷。
+  如果你需要跨 Pod 的保护，你必须为每个 Pod 赋予独特的 MCS 标签。
+  {{< /warning >}}
+
+<!--
+## Clean up
+
+Delete the Pod:
+-->
+## 清理
+
+删除之前创建的所有 Pod：
+
+```shell
+kubectl delete pod security-context-demo
+kubectl delete pod security-context-demo-2
+kubectl delete pod security-context-demo-3
+kubectl delete pod security-context-demo-4
+```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
+* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
+* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
+* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
+* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
+* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
+* [AllowPrivilegeEscalation design
+  document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
+-->
+* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) API 定义
+* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) API 定义
+* [使用最新的安全性增强来调优 Docker](https://opensource.com/business/15/3/docker-security-tuning)
+* [安全性上下文的设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
+* [属主管理的设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
+* [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)
+* [AllowPrivilegeEscalation 的设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
+
diff --git a/content/zh/docs/tasks/configure-pod-container/static-pod.md b/content/zh/docs/tasks/configure-pod-container/static-pod.md
index 573bdd8d2d..8ed0c78338 100644
--- a/content/zh/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/zh/docs/tasks/configure-pod-container/static-pod.md
@@ -39,7 +39,7 @@ instead.
 
 kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个
 {{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
-这意味着节点上运行的静态 Pod 对 API 服务来说是不可见的，但是不能通过 API 服务器来控制。
+这意味着节点上运行的静态 Pod 对 API 服务来说是可见的，但是不能通过 API 服务器来控制。
 
 {{< note >}}
 如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod，
@@ -201,7 +201,7 @@ JSON/YAML 格式的 Pod 定义文件。
 <!--
 1. Create a YAML file and store it on a web server so that you can pass the URL of that file to the kubelet.
 -->
-1. 创建一个 YAML 文件，并保存在保存在 web 服务上，为 kubelet 生成一个 URL。
+1. 创建一个 YAML 文件，并保存在 web 服务上，为 kubelet 生成一个 URL。
 
    ```yaml
    apiVersion: v1
diff --git a/content/zh/docs/tasks/debug-application-cluster/_index.md b/content/zh/docs/tasks/debug-application-cluster/_index.md
index 9fb280225f..15912bf00c 100644
--- a/content/zh/docs/tasks/debug-application-cluster/_index.md
+++ b/content/zh/docs/tasks/debug-application-cluster/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "监控、日志和排错"
 weight: 80
+description: 设置监视和日志记录以对集群进行故障排除或调试容器化应用。
 ---
diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md
index 274bee2ed4..a5f0271128 100644
--- a/content/zh/docs/tasks/debug-application-cluster/audit.md
+++ b/content/zh/docs/tasks/debug-application-cluster/audit.md
@@ -44,16 +44,19 @@ Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录
 <!-- body -->
 
 <!--
-[Kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
-performs auditing. Each request on each stage
-of its execution generates an event, which is then pre-processed according to
+Audit records begin their lifecycle inside the
+[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+component. Each request on each stage
+of its execution generates an audit event, which is then pre-processed according to
 a certain policy and written to a backend. The policy determines what's recorded
 and the backends persist the records. The current backend implementations
 include logs files and webhooks.
 -->
+审计记录最初产生于
 [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
-执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。
-该策略确定要记录的内容和用来存储记录的后端。当前的后端支持日志文件和 webhook。
+内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略
+被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。
+当前的后端支持日志文件和 webhook。
 
 <!--
 Each request can be recorded with an associated "stage". The known stages are:
@@ -162,7 +165,7 @@ script, which generates the audit policy file. You can see most of the audit pol
 ## Audit backends
 
 Audit backends persist audit events to an external storage.
-[Kube-apiserver][kube-apiserver] out of the box provides two backends:
+Out of the box, the kube-apiserver provides two backends:
 
 - Log backend, which writes events to a disk
 - Webhook backend, which sends events to an external API
@@ -173,7 +176,7 @@ In both cases, audit events structure is defined by the API in the
 -->
 ## 审计后端   {#audit-backends}
 
-审计后端实现将审计事件导出到外部存储。 `Kube-apiserver` 提供两个后端：
+审计后端实现将审计事件导出到外部存储。`Kube-apiserver` 默认提供两个后端：
 
 - Log 后端，将事件写入到磁盘
 - Webhook 后端，将事件发送到外部 API
@@ -407,7 +410,7 @@ audit policies.
 
 ### Use fluentd to collect and distribute audit events from log file
 
-[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer.
+[Fluentd](https://www.fluentd.org/) is an open source data collector for unified logging layer.
 In this example, we will use fluentd to split audit events by different namespaces.
 -->
 ## 日志收集器示例
@@ -570,10 +573,10 @@ different users into different files.
    ```
 
 <!--
-1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
+1. create a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) for kube-apiserver webhook audit backend
 -->
 4. 为 kube-apiserver webhook 审计后端创建一个
-   [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+   [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)：
 
   ```bash
   cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
@@ -618,10 +621,8 @@ plugin which supports full-text search and analytics.
 ## {{% heading "whatsnext" %}}
 
 <!--
-Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco).
-
 Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
 -->
 
-* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)
+了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/crictl.md b/content/zh/docs/tasks/debug-application-cluster/crictl.md
index 7e51054053..0ccbba1828 100644
--- a/content/zh/docs/tasks/debug-application-cluster/crictl.md
+++ b/content/zh/docs/tasks/debug-application-cluster/crictl.md
@@ -8,14 +8,12 @@ content_type: task
 ---
 
 <!--
----
 reviewers:
 - Random-Liu
 - feiskyer
 - mrunalp
 title: Debugging Kubernetes nodes with crictl
 content_type: task
----
 -->
 
 
@@ -27,54 +25,46 @@ content_type: task
 `crictl` is a command-line interface for CRI-compatible container runtimes.
 You can use it to inspect and debug container runtimes and applications on a
 Kubernetes node. `crictl` and its source are hosted in the
-[cri-tools](https://github.com/kubernetes-incubator/cri-tools) repository.
+[cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository.
 -->
 
 `crictl` 是 CRI 兼容的容器运行时命令行接口。
-您可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。
-`crictl`和它的源代码在 [cri-tools](https://github.com/kubernetes-incubator/cri-tools) 代码库。
-
-
+你可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。
+`crictl` 和它的源代码在
+[cri-tools](https://github.com/kubernetes-sigs/cri-tools) 代码库。
 
 ## {{% heading "prerequisites" %}}
 
-
 <!--
 `crictl` requires a Linux operating system with a CRI runtime.
 -->
-
 `crictl` 需要带有 CRI 运行时的 Linux 操作系统。
 
-
-
 <!-- steps -->
 
 <!--
 ## Installing crictl
 
 You can download a compressed archive `crictl` from the cri-tools [release
-page](https://github.com/kubernetes-incubator/cri-tools/releases), for several
+page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
 different architectures. Download the version that corresponds to your version
 of Kubernetes. Extract it and move it to a location on your system path, such as
 `/usr/local/bin/`.
 -->
-
 ## 安装 crictl
 
-您可以从 cri-tools [发布页面](https://github.com/kubernetes-incubator/cri-tools/releases)下载一个压缩的 `crictl` 归档文件，用于几种不同的架构。
-下载与您的 kubernetes 版本相对应的版本。
+你可以从 cri-tools [发布页面](https://github.com/kubernetes-sigs/cri-tools/releases)
+下载一个压缩的 `crictl` 归档文件，用于几种不同的架构。
+下载与你的 kubernetes 版本相对应的版本。
 提取它并将其移动到系统路径上的某个位置，例如`/usr/local/bin/`。
 
 <!--
 ## General usage
--->
 
-## 一般用法
-
-<!--
 The `crictl` command has several subcommands and runtime flags. Use
 `crictl help` or `crictl <subcommand> help` for more details.
 -->
+## 一般用法
 
 `crictl` 命令有几个子命令和运行时参数。
 有关详细信息，请使用 `crictl help` 或 `crictl <subcommand> help` 获取帮助信息。
@@ -83,38 +73,36 @@ The `crictl` command has several subcommands and runtime flags. Use
 `crictl` connects to `unix:///var/run/dockershim.sock` by default. For other
 runtimes, you can set the endpoint in multiple different ways:
 -->
-
 `crictl` 默认连接到 `unix:///var/run/dockershim.sock`。
-对于其他的运行时，您可以用多种不同的方法设置端点：
+对于其他的运行时，你可以用多种不同的方法设置端点：
 
 <!--
 - By setting flags `--runtime-endpoint` and `--image-endpoint`
 - By setting environment variables `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT`
 - By setting the endpoint in the config file `--config=/etc/crictl.yaml`
 -->
-
 - 通过设置参数 `--runtime-endpoint` 和 `--image-endpoint`
 - 通过设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`
 - 通过在配置文件中设置端点 `--config=/etc/crictl.yaml`
 
-
 <!--
 You can also specify timeout values when connecting to the server and enable or
 disable debugging, by specifying `timeout` or `debug` values in the configuration
 file or using the `--timeout` and `--debug` command-line flags.
 -->
-
-您还可以在连接到服务器并启用或禁用调试时指定超时值，方法是在配置文件中指定 `timeout` 或 `debug` 值，或者使用 `--timeout` 和 `--debug` 命令行参数。
+你还可以在连接到服务器并启用或禁用调试时指定超时值，方法是在配置文件中指定
+`timeout` 或 `debug` 值，或者使用 `--timeout` 和 `--debug` 命令行参数。
 
 <!--
 To view or edit the current configuration, view or edit the contents of
 `/etc/crictl.yaml`.
 -->
-
 要查看或编辑当前配置，请查看或编辑 `/etc/crictl.yaml` 的内容。
 
-```sh
+```shell
 cat /etc/crictl.yaml
+```
+```
 runtime-endpoint: unix:///var/run/dockershim.sock
 image-endpoint: unix:///var/run/dockershim.sock
 timeout: 10
@@ -126,18 +114,17 @@ debug: true
 
 The following examples show some `crictl` commands and example output.
 -->
-
 ## crictl 命令示例
 
 {{< warning >}}
-
-<!--If you use `crictl` to create pod sandboxes or containers on a running
+<!--
+If you use `crictl` to create pod sandboxes or containers on a running
 Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
-general purpose workflow tool, but a tool that is useful for debugging.-->
-
-如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器，kubelet 最终将删除它们。
-`crictl`不是一个通用的工作流工具，而是一个对调试有用的工具。
-
+general purpose workflow tool, but a tool that is useful for debugging.
+-->
+如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器，
+kubelet 最终将删除它们。
+`crictl` 不是一个通用的工作流工具，而是一个对调试有用的工具。
 {{< /warning >}}
 
 <!--
@@ -145,14 +132,14 @@ general purpose workflow tool, but a tool that is useful for debugging.-->
 
 List all pods:
 -->
-
 ### 打印 Pod 清单
 
 打印所有 Pod 的清单：
 
-```bash
+```shell
 crictl pods
 ```
+
 ```none
 POD ID              CREATED              STATE               NAME                         NAMESPACE           ATTEMPT
 926f1b5a1d33a       About a minute ago   Ready               sh-84d7dcf559-4r2gq          default             0
@@ -164,12 +151,12 @@ a86316e96fa89       17 hours ago         Ready               kube-proxy-gblk4
 <!--
 List pods by name:
 -->
-
 根据名称打印 Pod 清单：
 
-```bash
+```shell
 crictl pods --name nginx-65899c769f-wv2gp
 ```
+
 ```none
 POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
 4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0
@@ -178,10 +165,9 @@ POD ID              CREATED             STATE               NAME
 <!--
 List pods by label:
 -->
-
 根据标签打印 Pod 清单：
 
-```bash
+```shell
 crictl pods --label run=nginx
 ```
 ```none
@@ -194,12 +180,11 @@ POD ID              CREATED             STATE               NAME
 
 List all images:
 -->
-
 ### 打印镜像清单
 
 打印所有镜像清单：
 
-```bash
+```shell
 crictl images
 ```
 ```none
@@ -213,10 +198,9 @@ nginx                                     latest              cd5239a0906a6
 <!--
 List images by repository:
 -->
-
 根据仓库打印镜像清单：
 
-```bash
+```shell
 crictl images nginx
 ```
 ```none
@@ -227,10 +211,9 @@ nginx               latest              cd5239a0906a6       109MB
 <!--
 Only list image IDs:
 -->
-
 只打印镜像 ID：
 
-```bash
+```shell
 crictl images -q
 ```
 ```none
@@ -245,12 +228,11 @@ sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569
 
 List all containers:
 -->
-
 ### 打印容器清单
 
 打印所有容器清单：
 
-```bash
+```shell
 crictl ps -a
 ```
 ```none
@@ -264,10 +246,9 @@ CONTAINER ID        IMAGE
 <!--
 List running containers:
 -->
-
 打印正在运行的容器清单：
 
-```bash
+```shell
 crictl ps
 ```
 ```none
@@ -280,10 +261,9 @@ CONTAINER ID        IMAGE
 <!--
 ### Execute a command in a running container
 -->
-
 ### 在正在运行的容器上执行命令
 
-```bash
+```shell
 crictl exec -i -t 1f73f2d81bf98 ls
 ```
 ```none
@@ -295,12 +275,11 @@ bin   dev   etc   home  proc  root  sys   tmp   usr   var
 
 Get all container logs:
 -->
-
 ### 获取容器日志
 
 获取容器的所有日志：
 
-```bash
+```shell
 crictl logs 87d3992f84f74
 ```
 ```none
@@ -312,10 +291,9 @@ crictl logs 87d3992f84f74
 <!--
 Get only the latest `N` lines of logs:
 -->
-
 获取最近的 `N` 行日志：
 
-```bash
+```shell
 crictl logs --tail=1 87d3992f84f74
 ```
 ```none
@@ -329,38 +307,37 @@ Using `crictl` to run a pod sandbox is useful for debugging container runtimes.
 On a running Kubernetes cluster, the sandbox will eventually be stopped and
 deleted by the Kubelet.
 -->
-
 ### 运行 Pod 沙盒
 
 用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。
 在运行的 Kubernetes 集群中，沙盒会随机地被 kubelet 停止和删除。
 
-1.  <!--Create a JSON file like the following:-->
-    编写下面的 JSON 文件：
+1. <!--Create a JSON file like the following:-->
+   编写下面的 JSON 文件：
 
-      ```json
-      {
-          "metadata": {
-              "name": "nginx-sandbox",
-              "namespace": "default",
-              "attempt": 1,
-              "uid": "hdishd83djaidwnduwk28bcsb"
-          },
-          "logDirectory": "/tmp",
-          "linux": {
-          }
-      }
-      ```
+   ```json
+   {
+       "metadata": {
+           "name": "nginx-sandbox",
+           "namespace": "default",
+           "attempt": 1,
+           "uid": "hdishd83djaidwnduwk28bcsb"
+       },
+       "logDirectory": "/tmp",
+       "linux": {
+       }
+   }
+   ```
 
-2.  <!--Use the `crictl runp` command to apply the JSON and run the sandbox.-->
-    使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
+2. <!--Use the `crictl runp` command to apply the JSON and run the sandbox.-->
+   使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
 
-      ```bash
-      crictl runp pod-config.json
-      ```
+   ```shell
+   crictl runp pod-config.json
+   ```
 
-      <!--The ID of the sandbox is returned.-->
-      返回了沙盒的 ID。
+   <!--The ID of the sandbox is returned.-->
+   返回了沙盒的 ID。
 
 <!--
 ### Create a container
@@ -369,91 +346,88 @@ Using `crictl` to create a container is useful for debugging container runtimes.
 On a running Kubernetes cluster, the sandbox will eventually be stopped and
 deleted by the Kubelet.
 -->
-
 ### 创建容器
 
 用 `crictl` 创建容器对容器运行时排错很有帮助。
 在运行的 Kubernetes 集群中，沙盒会随机的被 kubelet 停止和删除。
 
+1. <!--Pull a busybox image-->
+   拉取 busybox 镜像
 
-1.  <!--Pull a busybox image-->
-    拉取 busybox 镜像
+   ```bash
+   crictl pull busybox
+   Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
+   ```
 
-      ```bash
-      crictl pull busybox
-      Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
-      ```
+2. <!--Create configs for the pod and the container:-->
+   创建 Pod 和容器的配置：
 
-2.  <!--Create configs for the pod and the container:-->
-    创建 Pod 和容器的配置：
+   <!--**Pod config**:-->
+   **Pod 配置**：
+   ```yaml
+   {
+       "metadata": {
+           "name": "nginx-sandbox",
+           "namespace": "default",
+           "attempt": 1,
+           "uid": "hdishd83djaidwnduwk28bcsb"
+       },
+       "log_directory": "/tmp",
+       "linux": {
+       }
+   }
+   ```
 
-      <!--**Pod config**:-->
-      **Pod 配置**：
-      ```yaml
-      {
-          "metadata": {
-              "name": "nginx-sandbox",
-              "namespace": "default",
-              "attempt": 1,
-              "uid": "hdishd83djaidwnduwk28bcsb"
-          },
-          "log_directory": "/tmp",
-          "linux": {
-          }
-      }
-      ```
+   <!--**Container config**:-->
+   **容器配置**：
+   ```yaml
+   {
+     "metadata": {
+         "name": "busybox"
+     },
+     "image":{
+         "image": "busybox"
+     },
+     "command": [
+         "top"
+     ],
+     "log_path":"busybox.log",
+     "linux": {
+     }
+   }
+   ```
 
-      <!--**Container config**:-->
-      **容器配置**：
-      ```yaml
-      {
-        "metadata": {
-            "name": "busybox"
-        },
-        "image":{
-            "image": "busybox"
-        },
-        "command": [
-            "top"
-        ],
-        "log_path":"busybox.log",
-        "linux": {
-        }
-      }
-      ```
+3. <!--Create the container, passing the ID of the previously-created pod, the
+   container config file, and the pod config file. The ID of the container is
+   returned.-->
+   创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
 
-3.  <!--Create the container, passing the ID of the previously-created pod, the
-    container config file, and the pod config file. The ID of the container is
-    returned.-->
-    创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
+   ```bash
+   crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
+   ```
 
-      ```bash
-      crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
-      ```
+4. <!--List all containers and verify that the newly-created container has its
+   state set to `Created`.-->
+   查询所有容器并确认新创建的容器状态为 `Created`。
 
-4.  <!--List all containers and verify that the newly-created container has its
-    state set to `Created`.-->
-    查询所有容器并确认新创建的容器状态为 `Created`。
-
-      ```bash
-      crictl ps -a
-      ```
-      ```none
-      CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT
-      3e025dd50a72d       busybox             32 seconds ago      Created             busybox             0
-      ```
+   ```bash
+   crictl ps -a
+   ```
+   ```none
+   CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT
+   3e025dd50a72d       busybox             32 seconds ago      Created             busybox             0
+   ```
 
 <!--
 ### Start a container
 
 To start a container, pass its ID to `crictl start`:
 -->
-
 ### 启动容器
 
 要启动容器，要将容器 ID 传给 `crictl start`：
 
-```bash
+```shell
 crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
 ```
 ```none
@@ -463,27 +437,20 @@ crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
 <!--
 Check the container has its state set to `Running`.
 -->
-
 确认容器的状态为 `Running`。
 
-```bash
+```shell
 crictl ps
 ```
 ```none
 CONTAINER ID        IMAGE               CREATED              STATE               NAME                ATTEMPT
 3e025dd50a72d       busybox             About a minute ago   Running             busybox             0
 ```
-
-
-
-
 <!-- discussion -->
 
 <!--
-See [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)
+See [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)
 for more information.
 -->
-
-更多信息请参考 [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools)。
-
+更多信息请参考 [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)。
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application.md b/content/zh/docs/tasks/debug-application-cluster/debug-application.md
index 8e7b751951..57863d4146 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-application.md
@@ -125,7 +125,7 @@ Once your pod has been scheduled, the methods described in [Debug Running Pods](
 
 一旦 Pod 被调度，就可以采用
 [调试运行中的 Pod](/zh/docs/concepts/configuration/manage-resources-containers/)
-中小鞥在的方法来进一步调试。
+中的方法来进一步调试。
 
 <!--
 #### My pod is running but not doing what I told it to do
@@ -315,4 +315,3 @@ You may also visit [troubleshooting document](/docs/troubleshooting/) for more i
 DNS 服务已配置并正常工作，iptables 规则也以安装并且 `kube-proxy` 也没有异常行为。
 
 你也可以访问[故障排查文档](/zh/docs/tasks/debug-application-cluster/troubleshooting/ )来获取更多信息。
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
index 0735ed6bd6..4a39565ee4 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
@@ -15,10 +15,11 @@ content_type: concept
 This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
 problem you are experiencing. See
 the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
-You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
+You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
 -->
 本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。
-对于应用的调试，请参阅[应用故障排查指南](/zh/docs/tasks/debug-application-cluster/debug-application/)。
+对于应用的调试，请参阅
+[应用故障排查指南](/zh/docs/tasks/debug-application-cluster/debug-application/)。
 你也可以访问[故障排查](/zh/docs/tasks/debug-application-cluster/troubleshooting/)
 来获取更多的信息。
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
index 8e35642baf..c859455873 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -21,8 +21,8 @@ content_type: task
 <!--
 This page shows how to investigate problems related to the execution of
 Init Containers. The example command lines below refer to the Pod as
-  `<pod-name>` and the Init Containers as `<init-container-1>` and
-  `<init-container-2>`.
+`<pod-name>` and the Init Containers as `<init-container-1>` and
+`<init-container-2>`.
 -->
 此页显示如何核查与 Init 容器执行相关的问题。
 下面的示例命令行将 Pod 称为 `<pod-name>`，而 Init 容器称为 `<init-container-1>` 和
@@ -34,7 +34,7 @@ Init Containers. The example command lines below refer to the Pod as
 
 <!--
 * You should be familiar with the basics of
-  [Init Containers](/docs/concepts/abstractions/init-containers/).
+  [Init Containers](/docs/concepts/workloads/pods/init-containers/).
 * You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
 -->
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 8f2721eb7a..4610d254e5 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -77,9 +77,9 @@ can not schedule your pod. Reasons include:
 You may have exhausted the supply of CPU or Memory in your cluster. In this
 case you can try several things:
 
-* [Add more nodes](/docs/admin/cluster-management/#resizing-a-cluster) to the cluster.
+* Add more nodes to the cluster.
 
-* [Terminate unneeded pods](/docs/user-guide/pods/single-container/#deleting_a_pod)
+* [Terminate unneeded pods](/docs/concepts/workloads/pods/#pod-termination)
   to make room for pending pods.
 
 * Check that the pod is not larger than your nodes. For example, if all
@@ -94,7 +94,7 @@ case you can try several things:
 
 你可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情：
 
-* [添加更多节点](/zh/docs/tasks/administer-cluster/cluster-management/) 到集群。
+* 向集群中添加节点。
 
 * [终止不需要的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
   为 Pending 状态的 Pod 提供空间。
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
new file mode 100644
index 0000000000..358ee111c3
--- /dev/null
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
@@ -0,0 +1,292 @@
+---
+title: 调试运行中的 Pod
+content_type: task
+---
+
+<!-- overview -->
+<!--
+This page explains how to debug Pods running (or crashing) on a Node.
+-->
+本页解释如何在节点上调试运行中（或崩溃）的 Pod。
+
+## {{% heading "prerequisites" %}}
+
+<!--
+* Your {{< glossary_tooltip text="Pod" term_id="pod" >}} should already be
+  scheduled and running. If your Pod is not yet running, start with [Troubleshoot
+  Applications](/docs/tasks/debug-application-cluster/debug-application/).
+* For some of the advanced debugging steps you need to know on which Node the
+  Pod is running and have shell access to run commands on that Node. You don't
+  need that access to run the standard debug steps that use `kubectl`.
+-->
+* 你的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 应该已经被调度并正在运行中，
+如果你的 Pod 还没有运行，请参阅[应用问题排查](/docs/tasks/debug-application-cluster/debug-application/)。
+
+* 对于一些高级调试步骤，你应该知道 Pod 具体运行在哪个节点上，在该节点上有权限去运行一些命令。
+  你不需要任何访问权限就可以使用 `kubectl` 去运行一些标准调试步骤。
+
+<!-- steps -->
+
+<!--
+## Examining pod logs {#examine-pod-logs}
+
+First, look at the logs of the affected container:
+
+```shell
+kubectl logs ${POD_NAME} ${CONTAINER_NAME}
+```
+
+If your container has previously crashed, you can access the previous container's crash log with:
+
+```shell
+kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
+```
+-->
+## 检查 Pod 的日志 {#examine-pod-logs}
+
+首先，查看受到影响的容器的日志：
+
+```shell
+kubectl logs ${POD_NAME} ${CONTAINER_NAME}
+```
+
+如果你的容器之前崩溃过，你可以通过下面命令访问之前容器的崩溃日志：
+
+```shell
+kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
+```
+
+<!--
+## Debugging with container exec {#container-exec}
+
+```shell
+kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
+```
+
+As an example, to look at the logs from a running Cassandra pod, you might run
+
+```shell
+kubectl exec cassandra -- cat /var/log/cassandra/system.log
+```
+
+You can run a shell that's connected to your terminal using the `-i` and `-t`
+arguments to `kubectl exec`, for example:
+
+```shell
+kubectl exec -it cassandra -- sh
+```
+
+For more details, see [Get a Shell to a Running Container](
+/docs/tasks/debug-application-cluster/get-shell-running-container/).
+-->
+## 使用容器 exec 进行调试 {#container-exec}
+
+如果 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 包含调试程序，
+比如从 Linux 和 Windows 操作系统基础镜像构建的镜像，你可以使用 `kubectl exec` 命令
+在特定的容器中运行一些命令：
+
+```shell
+kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
+```
+{{< note >}}
+`-c ${CONTAINER_NAME}` 是可选择的。如果Pod中仅包含一个容器，就可以忽略它。
+{{< /note >}}
+
+例如，要查看正在运行的 Cassandra pod中的日志，可以运行：
+
+```shell
+kubectl exec cassandra -- cat /var/log/cassandra/system.log
+```
+
+你可以在 `kubectl exec` 命令后面加上 `-i` 和 `-t` 来运行一个连接到你的终端的 Shell，比如：
+
+```shell
+kubectl exec -it cassandra -- sh
+```
+
+若要了解更多内容，可查看[获取正在运行容器的 Shell](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)。
+
+<!--
+## Debugging with an ephemeral debug container {#ephemeral-container}
+
+{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
+
+{{< glossary_tooltip text="Ephemeral containers" term_id="ephemeral-container" >}}
+are useful for interactive troubleshooting when `kubectl exec` is insufficient
+because a container has crashed or a container image doesn't include debugging
+utilities, such as with [distroless images](
+https://github.com/GoogleContainerTools/distroless). `kubectl` has an alpha
+command that can create ephemeral containers for debugging beginning with version
+`v1.18`.
+-->
+## 使用临时调试容器来进行调试 {#ephemeral-container}
+
+{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
+
+当由于容器崩溃或容器镜像不包含调试程序（例如[无发行版镜像](https://github.com/GoogleContainerTools/distroless)等）
+而导致 `kubectl exec` 无法运行时，{{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}}对于排除交互式故障很有用。
+
+<!--
+### Example debugging using ephemeral containers {#ephemeral-container-example}
+
+The examples in this section require the `EphemeralContainers` [feature gate](
+/docs/reference/command-line-tools-reference/feature-gates/) enabled in your
+cluster and `kubectl` version v1.18 or later.
+
+You can use the `kubectl alpha debug` command to add ephemeral containers to a
+running Pod. First, create a pod for the example:
+
+```shell
+kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
+```
+
+This section use the `pause` container image in examples because it does not
+contain userland debugging utilities, but this method works with all container
+images.
+-->
+## 使用临时容器来调试的例子 {#ephemeral-container-example}
+
+{{< note >}}
+本示例需要你的集群已经开启 `EphemeralContainers` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+`kubectl` 版本为 v1.18 或者更高。
+{{< /note >}}
+
+你可以使用 `kubectl alpha debug` 命令来给正在运行中的 Pod 增加一个临时容器。
+首先，像示例一样创建一个 pod：
+
+```shell
+kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
+```
+
+{{< note >}}
+本节示例中使用 `pause` 容器镜像，因为它不包含任何用户级调试程序，但是这个方法适用于所有容器镜像。
+{{< /note >}}
+
+<!--
+If you attempt to use `kubectl exec` to create a shell you will see an error
+because there is no shell in this container image.
+
+```shell
+kubectl exec -it ephemeral-demo -- sh
+```
+
+```
+OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
+```
+
+You can instead add a debugging container using `kubectl alpha debug`. If you
+specify the `-i`/`--interactive` argument, `kubectl` will automatically attach
+to the console of the Ephemeral Container.
+
+```shell
+kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
+```
+
+```
+Defaulting debug container name to debugger-8xzrl.
+If you don't see a command prompt, try pressing enter.
+/ #
+```
+-->
+如果你尝试使用 `kubectl exec` 来创建一个 shell，你将会看到一个错误，因为这个容器镜像中没有 shell。
+
+```shell
+kubectl exec -it ephemeral-demo -- sh
+```
+
+```
+OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
+```
+
+你可以改为使用 `kubectl alpha debug` 添加调试容器。
+如果你指定 `-i` 或者 `--interactive` 参数，`kubectl` 将自动挂接到临时容器的控制台。
+
+```shell
+kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
+```
+
+```
+Defaulting debug container name to debugger-8xzrl.
+If you don't see a command prompt, try pressing enter.
+/ #
+```
+
+<!--
+This command adds a new busybox container and attaches to it. The `--target`
+parameter targets the process namespace of another container. It's necessary
+here because `kubectl run` does not enable [process namespace sharing](
+/docs/tasks/configure-pod-container/share-process-namespace/) in the pod it
+creates.
+
+The `--target` parameter must be supported by the {{< glossary_tooltip
+text="Container Runtime" term_id="container-runtime" >}}. When not supported,
+the Ephemeral Container may not be started, or it may be started with an
+isolated process namespace.
+
+You can view the state of the newly created ephemeral container using `kubectl describe`:
+-->
+此命令添加一个新的 busybox 容器并将其挂接到该容器。`--target` 参数指定另一个容器的进程命名空间。
+这是必需的，因为 `kubectl run` 不能在它创建的pod中启用
+[共享进程命名空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
+
+{{< note >}}
+{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持`--target`参数。
+如果不支持，则临时容器可能不会启动，或者可能使用隔离的进程命名空间启动。
+{{< /note >}}
+
+你可以使用 `kubectl describe` 查看新创建的临时容器的状态：
+
+```shell
+kubectl describe pod ephemeral-demo
+```
+
+```
+...
+Ephemeral Containers:
+  debugger-8xzrl:
+    Container ID:   docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb
+    Image:          busybox
+    Image ID:       docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084
+    Port:           <none>
+    Host Port:      <none>
+    State:          Running
+      Started:      Wed, 12 Feb 2020 14:25:42 +0100
+    Ready:          False
+    Restart Count:  0
+    Environment:    <none>
+    Mounts:         <none>
+...
+```
+
+<!--
+Use `kubectl delete` to remove the Pod when you're finished:
+-->
+使用 `kubectl delete` 来移除已经结束掉的 Pod：
+
+```shell
+kubectl delete pod ephemeral-demo
+```
+
+<!--
+Planned future sections include:
+
+* Debugging with a copy of the pod
+
+See https://git.k8s.io/enhancements/keps/sig-cli/20190805-kubectl-debug.md
+-->
+
+<!--
+## Debugging via a shell on the node {#node-shell-session}
+
+If none of these approaches work, you can find the host machine that the pod is
+running on and SSH into that host, but this should generally not be necessary
+given tools in the Kubernetes API. Therefore, if you find yourself needing to
+ssh into a machine, please file a feature request on GitHub describing your use
+case and why these tools are insufficient.
+-->
+## 在节点上通过 shell 来调试 {#node-shell-session}
+
+如果这些方法都不起作用，你可以找到运行 Pod 的主机并通过 SSH 进入该主机，
+但是如果使用 Kubernetes API 中的工具，则通常不需要这样做。
+因此，如果你发现自己需要使用 ssh 进入主机，请在GitHub 上提交功能请求，
+以描述你的用例以及这些工具不足的原因。
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-service.md b/content/zh/docs/tasks/debug-application-cluster/debug-service.md
index 426020b47d..1bd0c26cb1 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-service.md
@@ -1,19 +1,14 @@
 ---
-reviewers:
-- thockin
-- bowei
 content_type: concept
 title: 调试 Service
 ---
 
 <!--
----
 reviewers:
 - thockin
 - bowei
 content_type: concept
 title: Debug Services
----
 -->
 
 <!-- overview -->
@@ -24,9 +19,9 @@ Deployment (or other workload controller) and created a Service, but you
 get no response when you try to access it.  This document will hopefully help
 you to figure out what's going wrong.
 -->
-对于新安装的 Kubernetes，经常出现的问题是 Service 无法正常运行。 您已经通过
+对于新安装的 Kubernetes，经常出现的问题是 Service 无法正常运行。 你已经通过
 Deployment（或其他工作负载控制器）运行了 Pod，并创建 Service ，但是
-当您尝试访问它时，没有任何响应。此文档有望对您有所帮助并找出问题所在。
+当你尝试访问它时，没有任何响应。此文档有望对你有所帮助并找出问题所在。
 
 
 <!-- body -->
@@ -36,33 +31,26 @@ Deployment（或其他工作负载控制器）运行了 Pod，并创建 Service
 For many steps here you will want to see what a Pod running in the cluster
 sees.  The simplest way to do this is to run an interactive alpine Pod:
 -->
-## 在 pod 中运行命令
+## 在 Pod 中运行命令
 
-对于这里的许多步骤，您可能希望知道运行在集群中的 Pod 看起来是什么样的。最简单的方法是运行一个交互式的 alpine Pod：
+对于这里的许多步骤，你可能希望知道运行在集群中的 Pod 看起来是什么样的。
+最简单的方法是运行一个交互式的 alpine Pod：
 
 ```none
 $ kubectl run -it --rm --restart=Never alpine --image=alpine sh
 If you don't see a command prompt, try pressing enter.
 ```
-<!--
-{{< note >}}
-If you don't see a command prompt, try pressing enter.
-{{< /note >}}
 
+<!--
 If you already have a running Pod that you prefer to use, you can run a
 command in it using:
 -->
-{{< note >}}
-如果你没有看到命令提示符，请尝试按 Enter 键。
-{{< /note >}}
-
-如果您已经有了您想使用的正在运行的 Pod，则可以运行以下命令去进入：
+如果你已经有了你想使用的正在运行的 Pod，则可以运行以下命令去进入：
 
 ```shell
 kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
 ```
 
-
 <!--
 ## Setup
 
@@ -70,13 +58,16 @@ For the purposes of this walk-through, let's run some Pods.  Since you're
 probably debugging your own Service you can substitute your own details, or you
 can follow along and get a second data point.
 -->
-## 设置
+## 设置  {#setup}
 
-为了完成本次实践的任务，我们先运行几个 Pod。由于您可能正在调试自己的 Service，所以，您可以使用自己的信息进行替换，或者，您也可以跟随并开始下面的步骤来获得第二个数据点。
+为了完成本次实践的任务，我们先运行几个 Pod。
+由于你可能正在调试自己的 Service，所以，你可以使用自己的信息进行替换，
+或者你也可以跟着教程并开始下面的步骤来获得第二个数据点。
 
 ```shell
-$ kubectl  create deployment hostnames --image=k8s.gcr.io/serve_hostname 
+kubectl  create deployment hostnames --image=k8s.gcr.io/serve_hostname 
 ```
+
 ```none
 deployment.apps/hostnames created
 ```
@@ -88,9 +79,11 @@ Let's scale the deployment to 3 replicas.
 -->
 `kubectl` 命令将打印创建或变更的资源的类型和名称，它们可以在后续命令中使用。
 让我们将这个 deployment 的副本数扩至 3。
+
 ```shell
 kubectl scale deployment hostnames --replicas=3
 ```
+
 ```none
 deployment.apps/hostnames scaled
 ```
@@ -98,7 +91,7 @@ deployment.apps/hostnames scaled
 <!--
 Note that this is the same as if you had the Deployment with the following YAML:
 -->
-请注意这与您使用以下 YAML 方式启动 Deployment 类似：
+请注意这与你使用以下 YAML 方式启动 Deployment 类似：
 
 ```yaml
 apiVersion: apps/v1
@@ -127,14 +120,14 @@ The label "app" is automatically set by `kubectl create deployment` to the name
 
 You can confirm your Pods are running:
 -->
-
 "app" 标签是 `kubectl create deployment` 根据 Deployment 名称自动设置的。
 
-确认您的 Pods 是运行状态:
+确认你的 Pods 是运行状态:
 
 ```shell
 kubectl get pods -l app=hostnames
 ```
+
 ```none
 NAME                        READY     STATUS    RESTARTS   AGE
 hostnames-632524106-bbpiw   1/1       Running   0          2m
@@ -146,19 +139,19 @@ hostnames-632524106-tlaok   1/1       Running   0          2m
 You can also confirm that your Pods are serving.  You can get the list of
 Pod IP addresses and test them directly.
 -->
-您还可以确认您的 Pod 是否正在运行。您可以获取 Pod IP 地址列表并直接对其进行测试。
+你还可以确认你的 Pod 是否正在提供服务。你可以获取 Pod IP 地址列表并直接对其进行测试。
 
 ```shell
 kubectl get pods -l app=hostnames \
     -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
 ```
+
 ```none
 10.244.0.5
 10.244.0.6
 10.244.0.7
 ```
 
-
 <!--
 The example container used for this walk-through simply serves its own hostname
 via HTTP on port 9376, but if you are debugging your own app, you'll want to
@@ -166,15 +159,17 @@ use whatever port number your Pods are listening on.
 
 From within a pod:
 -->
-用于本教程的示例容器仅通过 HTTP 在端口 9376 上提供其自己的主机名，但是如果要调试自己的应用程序，则需要使用您的 Pod 正在侦听的端口号。
+用于本教程的示例容器仅通过 HTTP 在端口 9376 上提供其自己的主机名，
+但是如果要调试自己的应用程序，则需要使用你的 Pod 正在侦听的端口号。
 
-在 pod 内运行：
+在 Pod 内运行：
 
 ```shell
 for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
     wget -qO- $ep
 done
 ```
+
 <!--
 This should produce something like:
 -->
@@ -196,10 +191,11 @@ there.
 Assuming everything has gone to plan so far, you can start to investigate why
 your Service doesn't work.
 -->
-如果此时您没有收到期望的响应，则您的 Pod 状态可能不健康，或者可能没有在您认为正确的端口上进行监听。
-您可能会发现 `kubectl logs` 命令对于查看正在发生的事情很有用，或者您可能需要通过`kubectl exec` 直接进入 Pod 中并从那里进行调试。
+如果此时你没有收到期望的响应，则你的 Pod 状态可能不健康，或者可能没有在你认为正确的端口上进行监听。
+你可能会发现 `kubectl logs` 命令对于查看正在发生的事情很有用，
+或者你可能需要通过`kubectl exec` 直接进入 Pod 中并从那里进行调试。
 
-假设到目前为止一切都已按计划进行，那么您可以开始调查为何您的 Service 无法正常工作。
+假设到目前为止一切都已按计划进行，那么你可以开始调查为何你的 Service 无法正常工作。
 
 <!--
 ## Does the Service exist?
@@ -216,15 +212,17 @@ something like:
 
 细心的读者会注意到我们实际上尚未创建 Service -这是有意而为之。 这一步有时会被遗忘，这是首先要检查的步骤。
 
-那么，如果我尝试访问不存在的 Service 会怎样？ 假设您有另一个 Pod 通过名称匹配到 Service ，您将得到类似结果：
+那么，如果我尝试访问不存在的 Service 会怎样？ 假设你有另一个 Pod 通过名称匹配到 Service ，你将得到类似结果：
 
 ```shell
 wget -O- hostnames
 ```
+
 ```none
 Resolving hostnames (hostnames)... failed: Name or service not known.
 wget: unable to resolve host address 'hostnames'
 ```
+
 <!--
 The first thing to check is whether that Service actually exists:
 -->
@@ -233,6 +231,7 @@ The first thing to check is whether that Service actually exists:
 ```shell
 kubectl get svc hostnames
 ```
+
 ```none
 No resources found.
 Error from server (NotFound): services "hostnames" not found
@@ -242,10 +241,12 @@ Error from server (NotFound): services "hostnames" not found
 Let's create the Service.  As before, this is for the walk-through - you can
 use your own Service's details here.
 -->
-让我们创建 Service。 和以前一样，在这次实践中 - 您可以在此处使用自己的 Service 的内容。
+让我们创建 Service。 和以前一样，在这次实践中 - 你可以在此处使用自己的 Service 的内容。
+
 ```shell
 kubectl expose deployment hostnames --port=80 --target-port=9376
 ```
+
 ```none
 service/hostnames exposed
 ```
@@ -258,6 +259,7 @@ And read it back, just to be sure:
 ```shell
 kubectl get svc hostnames
 ```
+
 ```none
 NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
 hostnames   ClusterIP   10.0.1.175   <none>        80/TCP    5s
@@ -268,9 +270,9 @@ Now you know that the Service exists.
 
 As before, this is the same as if you had started the `Service` with YAML:
 -->
-现在您知道了 Service 确实存在。
+现在你知道了 Service 确实存在。
 
-就像之前通过 YAML 方式启动 'Service' 一样：
+同前，此步骤效果与通过 YAML 方式启动 'Service' 一样：
 
 ```yaml
 apiVersion: v1
@@ -286,13 +288,14 @@ spec:
     port: 80
     targetPort: 9376
 ```
+
 <!--
 In order to highlight the full range of configuration, the Service you created
 here uses a different port number than the Pods.  For many real-world
 Services, these values might be the same.
 -->
-为了突出配置范围的完整性，您在此处创建的 Service 使用的端口号与 Pods 不同。对于许多真实的 Service，这些值可以是相同的。
-
+为了突出配置范围的完整性，你在此处创建的 Service 使用的端口号与 Pods 不同。
+对于许多真实的 Service，这些值可以是相同的。
 
 <!--
 ## Does the Service work by DNS name?
@@ -307,24 +310,29 @@ From a Pod in the same Namespace:
 通常客户端通过 DNS 名称来匹配到 Service。
 
 从相同命名空间下的 Pod 中运行以下命令：
+
 ```shell
 nslookup hostnames
 ```
+
 ```none
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
 
 Name:      hostnames
 Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
 ```
+
 <!--
 If this fails, perhaps your Pod and Service are in different
 Namespaces, try a namespace-qualified name (again, from within a Pod):
 -->
-如果失败，那么您的 Pod 和 Service 可能位于不同的命名空间中，请尝试使用限定命名空间的名称（同样在 Pod 内运行）：
+如果失败，那么你的 Pod 和 Service 可能位于不同的命名空间中，
+请尝试使用限定命名空间的名称（同样在 Pod 内运行）：
 
 ```shell
 nslookup hostnames.default
 ```
+
 ```none
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
 
@@ -337,11 +345,13 @@ If this works, you'll need to adjust your app to use a cross-namespace name, or
 run your app and Service in the same Namespace.  If this still fails, try a
 fully-qualified name:
 -->
-如果成功，那么需要调整您的应用，使用跨命名空间的名称去访问它，或者，在相同的命名空间中运行应用和 Service。如果仍然失败，请尝试一个完全限定的名称：
+如果成功，那么需要调整你的应用，使用跨命名空间的名称去访问它，
+或者在相同的命名空间中运行应用和 Service。如果仍然失败，请尝试一个完全限定的名称：
 
 ```shell
 nslookup hostnames.default.svc.cluster.local
 ```
+
 ```none
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
 
@@ -361,17 +371,19 @@ You can also try this from a `Node` in the cluster:
 10.0.0.10 is the cluster's DNS Service IP, yours might be different.
 {{< /note >}}
 -->
-注意这里的后缀："default.svc.cluster.local"。"default" 是我们正在操作的命名空间。"svc" 表示这是一个 Service。"cluster.local" 是您的集群域，在您自己的集群中可能会有所不同。
+注意这里的后缀："default.svc.cluster.local"。"default" 是我们正在操作的命名空间。
+"svc" 表示这是一个 Service。"cluster.local" 是你的集群域，在你自己的集群中可能会有所不同。
 
-您也可以在集群中的节点上尝试此操作：
+你也可以在集群中的节点上尝试此操作：
 
 {{< note >}}
-10.0.0.10 是我的 DNS 服务 IP，您的可能有所不同。
+10.0.0.10 是集群的 DNS 服务 IP，你的可能有所不同。
 {{< /note >}}
 
 ```shell
 nslookup hostnames.default.svc.cluster.local 10.0.0.10
 ```
+
 ```none
 Server:         10.0.0.10
 Address:        10.0.0.10#53
@@ -385,15 +397,17 @@ If you are able to do a fully-qualified name lookup but not a relative one, you
 need to check that your `/etc/resolv.conf` file in your Pod is correct.  From
 within a Pod:
 -->
-如果您能够使用完全限定的名称查找，但不能使用相对名称，则需要检查您 Pod 中的 `/etc/resolv.conf` 文件是否正确。在 Pod 中运行以下命令：
+如果你能够使用完全限定的名称查找，但不能使用相对名称，则需要检查你 Pod 中的
+`/etc/resolv.conf` 文件是否正确。在 Pod 中运行以下命令：
 
 ```shell
 cat /etc/resolv.conf
 ```
+
 <!--
 You should see something like:
 -->
-您应该可以看到类似这样的输出：
+你应该可以看到类似这样的输出：
 
 ```
 nameserver 10.0.0.10
@@ -420,12 +434,19 @@ The `options` line must set `ndots` high enough that your DNS client library
 considers search paths at all.  Kubernetes sets this to 5 by default, which is
 high enough to cover all of the DNS names it generates.
 -->
-`nameserver` 行必须指示您的集群的 DNS Service，它通过 `--cluster-dns` 标志传递到 kubelet。
+`nameserver` 行必须指示你的集群的 DNS Service，
+它是通过 `--cluster-dns` 标志传递到 kubelet 的。
 
-`search` 行必须包含一个适当的后缀，以便查找 Service 名称。在本例中，它在本地命名空间（`default.svc.cluster.local`）、所有命名空间中的 `Service`（`svc.cluster.local`）最后是集群（`cluster.local`）中查找 Service 的名称。根据您自己的安装情况，可能会有额外的记录（最多 6 条）。
-集群后缀通过 `--cluster-domain` 标志传递给 `kubelet`。 本文档中，我们假定后缀是 “cluster.local”。您的集群配置可能不同，这种情况下，您应该在上面的所有命令中更改它。
+`search` 行必须包含一个适当的后缀，以便查找 Service 名称。
+在本例中，它查找本地命名空间（`default.svc.cluster.local`）中的服务和
+所有命名空间（`svc.cluster.local`）中的服务，最后在集群（`cluster.local`）中查找
+服务的名称。根据你自己的安装情况，可能会有额外的记录（最多 6 条）。
+集群后缀是通过 `--cluster-domain` 标志传递给 `kubelet` 的。 
+本文中，我们假定后缀是 “cluster.local”。
+你的集群配置可能不同，这种情况下，你应该在上面的所有命令中更改它。
 
-`options` 行必须设置足够高的 `ndots`，以便 DNS 客户端库考虑搜索路径。在默认情况下，Kubernetes 将这个值设置为 5，这个值足够高，足以覆盖它生成的所有 DNS 名称。
+`options` 行必须设置足够高的 `ndots`，以便 DNS 客户端库考虑搜索路径。
+在默认情况下，Kubernetes 将这个值设置为 5，这个值足够高，足以覆盖它生成的所有 DNS 名称。
 
 <!--
 ### Does any Service work by DNS name? {#does-any-service-exist-in-dns}
@@ -436,7 +457,9 @@ Service should always work.  From within a Pod:
 -->
 ### 是否存在 Service 能通过 DNS 名称访问？{#does-any-service-exist-in-dns}
 
-如果上面的方式仍然失败，DNS 查找不到您需要的 Service ，您可以后退一步，看看还有什么其它东西没有正常工作。Kubernetes 主 Service 应该一直是工作的。在 Pod 中运行如下命令：
+如果上面的方式仍然失败，DNS 查找不到你需要的 Service ，你可以后退一步，
+看看还有什么其它东西没有正常工作。
+Kubernetes 主 Service 应该一直是工作的。在 Pod 中运行如下命令：
 
 ```shell
 nslookup kubernetes.default
@@ -453,18 +476,21 @@ Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
 If this fails, please see the [kube-proxy](#is-the-kube-proxy-working) section
 of this document, or even go back to the top of this document and start over,
 but instead of debugging your own Service, debug the DNS Service.
+-->
+如果失败，你可能需要转到本文的 [kube-proxy](#is-the-kube-proxy-working) 节，
+或者甚至回到文档的顶部重新开始，但不是调试你自己的 Service ，而是调试 DNS Service。
 
+<!--
 ## Does the Service work by IP?
 
 Assuming you have confirmed that DNS works, the next thing to test is whether your
 Service works by its IP address.  From a Pod in your cluster, access the
 Service's IP (from `kubectl get` above).
 -->
-如果失败，您可能需要转到这个文档的 [kube-proxy](#is-the-kube-proxy-working) 部分，或者甚至回到文档的顶部重新开始，但不是调试您自己的 Service ，而是调试 DNS Service。
-
 ### Service 能够通过 IP 访问么？
 
-假设您已经确认 DNS 工作正常，那么接下来要测试的是您的 Service 能否通过它的 IP 正常访问。从集群中的一个 Pod，尝试访问 Service 的 IP（从上面的 `kubectl get` 命令获取）。
+假设你已经确认 DNS 工作正常，那么接下来要测试的是你的 Service 能否通过它的 IP 正常访问。
+从集群中的一个 Pod，尝试访问 Service 的 IP（从上面的 `kubectl get` 命令获取）。
 
 ```shell
 for i in $(seq 1 3); do 
@@ -487,7 +513,7 @@ hostnames-632524106-tlaok
 If your Service is working, you should get correct responses.  If not, there
 are a number of things that could be going wrong.  Read on.
 -->
-如果 Service 状态是正常的，您应该得到正确的响应。如果没有，有很多可能出错的地方，请继续阅读。
+如果 Service 状态是正常的，你应该得到正确的响应。如果没有，有很多可能出错的地方，请继续阅读。
 
 <!--
 ## Is the Service defined correctly?
@@ -498,11 +524,13 @@ and verify it:
 -->
 ## Service 的配置是否正确？
 
-这听起来可能很愚蠢，但您应该两次甚至三次检查您的 Service 配置是否正确，并且与您的 Pod 匹配。查看您的 Service 配置并验证它：
+这听起来可能很愚蠢，但你应该两次甚至三次检查你的 Service 配置是否正确，并且与你的 Pod 匹配。
+查看你的 Service 配置并验证它：
 
 ```shell
 kubectl get service hostnames -o json
 ```
+
 ```json
 {
     "kind": "Service",
@@ -546,10 +574,10 @@ kubectl get service hostnames -o json
 * If you meant to use a named port, do your Pods expose a port with the same name?
 * Is the port's `protocol` correct for your Pods?
 -->
-* 您想要访问的 Service 端口是否在 `spec.ports[]` 中列出？
-* `targetPort` 对您的 Pod 来说正确吗（许多 Pod 使用与 Service 不同的端口）？
-* 如果您想使用数值型端口，那么它的类型是一个数值（9376）还是字符串 “9376”？
-* 如果您想使用名称型端口，那么您的 Pod 是否暴露了一个同名端口？
+* 你想要访问的 Service 端口是否在 `spec.ports[]` 中列出？
+* `targetPort` 对你的 Pod 来说正确吗（许多 Pod 使用与 Service 不同的端口）？
+* 如果你想使用数值型端口，那么它的类型是一个数值（9376）还是字符串 “9376”？
+* 如果你想使用名称型端口，那么你的 Pod 是否暴露了一个同名端口？
 * 端口的 `protocol` 和 Pod 的是否对应？
 
 <!--
@@ -561,9 +589,10 @@ actually being selected by the Service.
 
 Earlier you saw that the Pods were running.  You can re-check that:
 -->
-## Service 有 Endpoint 吗？
+## Service 有 Endpoints 吗？
 
-如果您已经走到了这一步，您已经确认您的 Service 被正确定义，并能通过 DNS 解析。现在，让我们检查一下，您运行的 Pod 确实是由 Service 选择的。
+如果你已经走到了这一步，你已经确认你的 Service 被正确定义，并能通过 DNS 解析。
+现在，让我们检查一下，你运行的 Pod 确实是被 Service 选中的。
 
 早些时候，我们已经看到 Pod 是运行状态。我们可以再检查一下：
 
@@ -590,17 +619,20 @@ If the restart count is high, read more about how to [debug pods](/docs/tasks/de
 Inside the Kubernetes system is a control loop which evaluates the selector of
 every Service and saves the results into a corresponding Endpoints object.
 -->
-`-l app=hostnames` 参数是一个标签选择器 - 和我们 Service 中的一样。
+`-l app=hostnames` 参数是一个标签选择算符 - 和我们 Service 中定义的一样。
 
-"AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而不是崩溃。
+"AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而未崩溃。
 
-"RESTARTS" 列表明 Pod 没有经常崩溃或重启。经常性崩溃可能导致间歇性连接问题。如果重启数过大，通过[调试 pod](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#debugging-pods)了解更多。
+"RESTARTS" 列表明 Pod 没有经常崩溃或重启。经常性崩溃可能导致间歇性连接问题。
+如果重启次数过大，通过[调试 pod](/zh/docs/tasks/debug-application-cluster/debug-application/#debugging-pods)
+了解相关技术。
 
-在 Kubernetes 系统中有一个控制循环，它评估每个 Service 的选择器，并将结果保存到 Endpoints 对象中。
+在 Kubernetes 系统中有一个控制回路，它评估每个 Service 的选择算符，并将结果保存到 Endpoints 对象中。
 
 ```shell
 kubectl get endpoints hostnames
-
+```
+```
 NAME        ENDPOINTS
 hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
 ```
@@ -614,7 +646,12 @@ other error, such as the Service selecting for `app=hostnames`, but the
 Deployment specifying `run=hostnames`, as in versions previous to 1.18, where
 the `kubectl run` command could have been also used to create a Deployment.
 -->
-这证实 endpoint 控制器已经为您的 Service 找到了正确的 Pods。如果 `Endpoint` 列的值为 `<none>`，则应检查 Service 的 `spec.selector` 字段，以及您实际想选择的 Pod 的 `metadata.labels` 的值。常见的错误是输入错误或其他错误，例如 Service 想选择 `app=hostnames`，但是 Deployment 指定的是 `run=hostnames`。在 1.18之前的版本中 `kubectl run` 也可以被用来创建 Deployment。
+这证实 Endpoints 控制器已经为你的 Service 找到了正确的 Pods。
+如果 `ENDPOINTS` 列的值为 `<none>`，则应检查 Service 的 `spec.selector` 字段，
+以及你实际想选择的 Pod 的 `metadata.labels` 的值。
+常见的错误是输入错误或其他错误，例如 Service 想选择 `app=hostnames`，但是
+Deployment 指定的是 `run=hostnames`。在 1.18之前的版本中 `kubectl run`
+也可以被用来创建 Deployment。
 
 <!--
 ## Are the Pods working?
@@ -633,8 +670,8 @@ From within a Pod:
 -->
 ## Pod 正常工作吗？
 
-至此，您知道您的 Service 已存在，并且已匹配到您的Pod。在本实践的开始，您验证了 Pod 本身。
-让我们再次检查 Pod 是否确实在工作-您可以绕过 Service 机制并直接转到 Pod，如上面的 Endpoint 所示。
+至此，你知道你的 Service 已存在，并且已匹配到你的Pod。在本实验的开始，你已经检查了 Pod 本身。
+让我们再次检查 Pod 是否确实在工作 - 你可以绕过 Service 机制并直接转到 Pod，如上面的 Endpoint 所示。
 
 {{< note >}}
 这些命令使用的是 Pod 端口（9376），而不是 Service 端口（80）。
@@ -652,6 +689,7 @@ done
 This should produce something like:
 -->
 输出应该类似这样：
+
 ```
 hostnames-632524106-bbpiw
 hostnames-632524106-ly40y
@@ -663,7 +701,8 @@ You expect each Pod in the Endpoints list to return its own hostname.  If
 this is not what happens (or whatever the correct behavior is for your own
 Pods), you should investigate what's happening there.
 -->
-您希望 Endpoint 列表中的每个 Pod 都返回自己的主机名。 如果这不是发生的情况（或您自己的 Pod 的正确行为是什么），您应调查那里发生了什么。
+你希望 Endpoint 列表中的每个 Pod 都返回自己的主机名。 
+如果情况并非如此（或你自己的 Pod 的正确行为是什么），你应调查发生了什么事情。
 
 <!--
 ## Is the kube-proxy working?
@@ -680,9 +719,12 @@ will have to investigate whatever implementation of Services you are using.
 -->
 ## kube-proxy 正常工作吗？
 
-如果您到达这里，则说明您的 Service 正在运行，拥有 Endpoint ，Pod 真正在运行。 此时此刻，整个 Service 代理机制是可疑的。 让我们一步一步地确认它没问题。
+如果你到达这里，则说明你的 Service 正在运行，拥有 Endpoints，Pod 真正在提供服务。
+此时，整个 Service 代理机制是可疑的。让我们一步一步地确认它没问题。
 
- Service 的默认实现（在大多数集群上应用的）是 kube-proxy。这是一个在每个节点上运行的程序，并配置一小组用于提供 Service 抽象的机制之一。如果您的集群不使用 kube-proxy，则以下各节将不适用，您将必须检查您正在使用的 Service 的实现方式。
+Service 的默认实现（在大多数集群上应用的）是 kube-proxy。
+这是一个在每个节点上运行的程序，负责配置用于提供 Service 抽象的机制之一。
+如果你的集群不使用 kube-proxy，则以下各节将不适用，你将必须检查你正在使用的 Service 的实现方式。
 
 <!--
 ## Is the kube-proxy working?
@@ -692,7 +734,7 @@ Node, you should get something like the below:
 -->
 ### kube-proxy 正常运行吗？
 
-确认 `kube-proxy` 正在节点上运行。 在节点上直接运行，您将会得到类似以下的输出：
+确认 `kube-proxy` 正在节点上运行。 在节点上直接运行，你将会得到类似以下的输出：
 
 ```shell
 ps auxw | grep kube-proxy
@@ -708,7 +750,10 @@ depends on your Node OS.  On some OSes it is a file, such as
 /var/log/kube-proxy.log, while other OSes use `journalctl` to access logs.  You
 should see something like:
 -->
-下一步，确认它并没有出现明显的失败，比如连接主节点失败。要做到这一点，您必须查看日志。访问日志取决于您节点的操作系统。在某些操作系统是一个文件，如 /var/log/messages kube-proxy.log，而其他操作系统使用 `journalctl` 访问日志。您应该看到类似的输出：
+下一步，确认它并没有出现明显的失败，比如连接主节点失败。要做到这一点，你必须查看日志。
+访问日志的方式取决于你节点的操作系统。
+在某些操作系统上日志是一个文件，如 /var/log/messages kube-proxy.log，
+而其他操作系统使用 `journalctl` 访问日志。你应该看到输出类似于：
 
 ```none
 I1027 22:14:53.995134    5063 server.go:200] Running in resource-only container "/kube-proxy"
@@ -734,9 +779,12 @@ installing Kubernetes from scratch. If this is the case, you need to manually
 install the `conntrack` package (e.g. `sudo apt install conntrack` on Ubuntu)
 and then retry.
 -->
-如果您看到有关无法连接主节点的错误消息，则应再次检查节点配置和安装步骤。
+如果你看到有关无法连接主节点的错误消息，则应再次检查节点配置和安装步骤。
 
-`kube-proxy` 无法正确运行的可能原因之一是找不到所需的 `conntrack` 二进制文件。在一些 Linux 系统上，这也是可能发生的，这取决于您如何安装集群，例如，您正在从头开始安装 Kubernetes。如果是这样的话，您需要手动安装 `conntrack` 包（例如，在 Ubuntu 上使用 `sudo apt install conntrack`），然后重试。
+`kube-proxy` 无法正确运行的可能原因之一是找不到所需的 `conntrack` 二进制文件。
+在一些 Linux 系统上，这也是可能发生的，这取决于你如何安装集群，
+例如，你是手动开始一步步安装 Kubernetes。如果是这样的话，你需要手动安装
+`conntrack` 包（例如，在 Ubuntu 上使用 `sudo apt install conntrack`），然后重试。
 
 <!--
 Kube-proxy can run in one of a few modes.  In the log listed above, the
@@ -744,20 +792,24 @@ line `Using iptables Proxier` indicates that kube-proxy is running in
 "iptables" mode.  The most common other mode is "ipvs".  The older "userspace"
 mode has largely been replaced by these.
 
+-->
+Kube-proxy 可以以若干模式之一运行。在上述日志中，`Using iptables Proxier`
+行表示 kube-proxy 在 "iptables" 模式下运行。
+最常见的另一种模式是 "ipvs"。先前的 "userspace" 模式已经被这些所代替。
+
+<!--
 #### Iptables mode
 
 In "iptables" mode, you should see something like the following on a Node:
 -->
-Kube-proxy 可以在这些模式之一中运行。在上述日志中，`Using iptables Proxier` 行表示 kube-proxy 在 "iptables" 模式下运行。最常见的另一种模式是 "ipvs"。先前的 "userspace"
-模式已经被这些所代替。
-
 #### Iptables 模式
 
-在 "iptables" 模式中, 您应该可以在节点上看到如下输出:
+在 "iptables" 模式中, 你应该可以在节点上看到如下输出:
 
 ```shell
 iptables-save | grep hostnames
 ```
+
 ```none
 -A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
 -A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376
@@ -777,25 +829,25 @@ one `KUBE-SVC-<hash>` chain.  For each Pod endpoint, there should be a small
 number of rules in that `KUBE-SVC-<hash>` and one `KUBE-SEP-<hash>` chain with
 a small number of rules in it.  The exact rules will vary based on your exact
 config (including node-ports and load-balancers).
+-->
+对于每个 Service 的每个端口，应有 1 条 `KUBE-SERVICES` 规则、一个 `KUBE-SVC-<hash>` 链。
+对于每个 Pod 末端，在那个 `KUBE-SVC-<hash>` 链中应该有一些规则与之对应，还应该
+有一个 `KUBE-SEP-<hash>` 链与之对应，其中包含为数不多的几条规则。
+实际的规则数量可能会根据你实际的配置（包括 NodePort 和 LoadBalancer 服务）有所不同。
 
+<!--
 #### IPVS mode
 
 In "ipvs" mode, you should see something like the following on a Node:
 -->
-对于每个 Service 的所有端口，应有 1 条规则、一个链。对于每个 Pod endpoint，在那个XX应该有一些规则，也应该包含小数目的规则。实际的规则数量可能会根据您实际的配置（包括节点端口和负载均衡）有所不同。
-For each port of each Service, there should be 1 rule in `KUBE-SERVICES` and
-one `KUBE-SVC-<hash>` chain.  For each Pod endpoint, there should be a small
-number of rules in that `KUBE-SVC-<hash>` and one `KUBE-SEP-<hash>` chain with
-a small number of rules in it.  The exact rules will vary based on your exact
-config (including node-ports and load-balancers).
-
 #### IPVS 模式
 
-在 "ipvs" 模式中, 您应该在节点下看到如下输出：
+在 "ipvs" 模式中, 你应该在节点下看到如下输出：
 
 ```shell
 ipvsadm -ln
 ```
+
 ```none
 Prot LocalAddress:Port Scheduler Flags
   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
@@ -813,22 +865,26 @@ load-balancer IPs, kube-proxy will create a virtual server.  For each Pod
 endpoint, it will create corresponding real servers. In this example, service
 hostnames(`10.0.1.175:80`) has 3 endpoints(`10.244.0.5:9376`,
 `10.244.0.6:9376`, `10.244.0.7:9376`).
+-->
+对于每个 Service 的每个端口，还有 NodePort，External IP 和 LoadBalancer 类型服务
+的 IP，kube-proxy 将创建一个虚拟服务器。
+对于每个 Pod 末端，它将创建相应的真实服务器。
+在此示例中，服务主机名（`10.0.1.175:80`）拥有 3 个末端（`10.244.0.5:9376`、
+`10.244.0.6:9376` 和 `10.244.0.7:9376`）。
 
+<!--
 #### Userspace mode
 
 In rare cases, you may be using "userspace" mode.  From your Node:
 -->
-对于每个 Service 的每个端口，还有 NodePort，外部 IP 和
-负载平衡器 IP，kube-proxy 将创建一个虚拟服务器。 对于每个 Pod  Endpoint ，它将创建相应的真实服务器。 在此示例中，服务主机名(`10.0.1.175:80`)拥有 3 个 endpoint（`10.244.0.5:9376`,
-`10.244.0.6:9376`, `10.244.0.7:9376`)。
-
 #### Userspace 模式
 
-在少数情况下，您可能会用到 "userspace" 模式，在您的节点上运行：
+在极少数情况下，你可能会用到 "userspace" 模式。在你的节点上运行：
 
 ```shell
 iptables-save | grep hostnames
 ```
+
 ```none
 -A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577
 -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
@@ -840,23 +896,26 @@ example) - a "KUBE-PORTALS-CONTAINER" and a "KUBE-PORTALS-HOST".
 
 Almost nobody should be using the "userspace" mode any more, so you won't spend
 more time on it here.
+-->
+对于 Service （本例中只有一个）的每个端口，应当有 2 条规则：
+一条 "KUBE-PORTALS-CONTAINER" 和一条 "KUBE-PORTALS-HOST" 规则。
 
+几乎没有人应该再使用 "userspace" 模式，因此你在这里不会花更多的时间。
+
+<!--
 ### Is kube-proxy proxying?
 
 Assuming you do see one the above cases, try again to access your Service by
 IP from one of your Nodes:
 -->
-对于 Service （本例中只有一个）的每个端口，应当有 2 条规则： 一个 "KUBE-PORTALS-CONTAINER" 和一个 "KUBE-PORTALS-HOST"。
-
-几乎没有人应该再使用 "userspace" 模式，因此您在这里不会花更多的时间。
-
 ### kube-proxy 是否在运行?
 
-假设您确实遇到上述情况之一，请重试从节点上通过 IP 访问您的 Service ：
+假设你确实遇到上述情况之一，请重试从节点上通过 IP 访问你的 Service ：
 
 ```shell
 curl 10.0.1.175:80
 ```
+
 ```none
 hostnames-632524106-bbpiw
 ```
@@ -869,13 +928,16 @@ Look back at the `iptables-save` output above, and extract the
 port number that `kube-proxy` is using for your Service.  In the above
 examples it is "48577".  Now connect to that:
 -->
-如果失败，并且您正在使用用户空间代理，则可以尝试直接访问代理。 如果您使用的是 iptables 代理，请跳过本节。
+如果失败，并且你正在使用用户空间代理，则可以尝试直接访问代理。
+如果你使用的是 iptables 代理，请跳过本节。
 
-回顾上面的 `iptables-save` 输出，并提取 `kube-proxy` 用于您的 Service 的端口号。在上面的例子中，它是 “48577”。现在试着连接它：
+回顾上面的 `iptables-save` 输出，并提取 `kube-proxy` 为你的 Service 所使用的端口号。
+在上面的例子中，端口号是 “48577”。现在试着连接它：
 
 ```shell
 curl localhost:48577
 ```
+
 ```none
 hostnames-632524106-tlaok
 ```
@@ -883,7 +945,7 @@ hostnames-632524106-tlaok
 <!--
 If this still fails, look at the `kube-proxy` logs for specific lines like:
 -->
-如果仍然失败，请查看 `kube-proxy` 日志中的特定行，如：
+如果这步操作仍然失败，请查看 `kube-proxy` 日志中的特定行，如：
 
 ```none
 Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376]
@@ -892,7 +954,10 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
 <!--
 If you don't see those, try restarting `kube-proxy` with the `-v` flag set to 4, and
 then look at the logs again.
+-->
+如果你没有看到这些，请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`，然后再查看日志。
 
+<!--
 ### Edge case: A Pod fails to reach itself via the Service IP {#a-pod-fails-to-reach-itself-via-the-service-ip}
 
 This might sound unlikely, but it does happen and it is supposed to work.
@@ -900,38 +965,41 @@ This might sound unlikely, but it does happen and it is supposed to work.
 This can happen when the network is not properly configured for "hairpin"
 traffic, usually when `kube-proxy` is running in `iptables` mode and Pods
 are connected with bridge network. The `Kubelet` exposes a `hairpin-mode`
-[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance
+[flag](/docs/reference/command-line-tools-reference/kubelet/) that allows endpoints of a Service to loadbalance
 back to themselves if they try to access their own Service VIP. The
 `hairpin-mode` flag must either be set to `hairpin-veth` or
 `promiscuous-bridge`.
 
+-->
+### 边缘案例: Pod 无法通过 Service IP 连接到它本身       {#a-pod-fails-to-reach-itself-via-the-service-ip}
+
+这听起来似乎不太可能，但是确实可能发生，并且应该可行。
+
+如果网络没有为“发夹模式（Hairpin）”流量生成正确配置，
+通常当 `kube-proxy` 以 `iptables` 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。
+`kubelet` 提供了 `hairpin-mode`
+[标志](/zh/docs/reference/command-line-tools-reference/kubelet/)。
+如果 Service 的末端尝试访问自己的 Service VIP，则该端点可以把流量负载均衡回来到它们自身。
+`hairpin-mode` 标志必须被设置为 `hairpin-veth` 或者 `promiscuous-bridge`。
+
+<!--
 The common steps to trouble shoot this are as follows:
 
 * Confirm `hairpin-mode` is set to `hairpin-veth` or `promiscuous-bridge`.
 You should see something like the below. `hairpin-mode` is set to
 `promiscuous-bridge` in the following example.
 -->
-如果您没有看到这些，请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`，然后再查看日志。
+诊断此类问题的常见步骤如下：
 
-### 边缘案例: 一个 Pod 无法通过 Service  IP 连接到它本身{#a-pod-fails-to-reach-itself-via-the-service-ip}。
+* 确认 `hairpin-mode` 被设置为 `hairpin-veth` 或 `promiscuous-bridge`。
+  你应该可以看到下面这样。本例中 `hairpin-mode` 被设置为 `promiscuous-bridge`。
 
-这听起来似乎不太可能，但是确实发生了，并且应该可行。
-
-如果网络没有为“发夹模式”流量生成正确配置，通常当 `kube-proxy` 以 `iptables` 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。`Kubelet`暴露了 `hairpin-mode`[标志](/docs/admin/kubelet/)，如果 Service 的 endpoint 尝试访问自己的 Service VIP，则该端点可以把流量负载均衡回来到它们自身。
-`hairpin-mode` 标志必须被设置为 `hairpin-veth` 或者`promiscuous-bridge`。
-
-解决此问题的常见步骤如下：
-
-* 确认 `hairpin-mode` 被设置为 `hairpin-veth` 或 `promiscuous-bridge`.
-您应该可以看到下面这样。本例中 `hairpin-mode` 被设置为
-`promiscuous-bridge` 。
-
-```shell
-ps auxw | grep kubelet
-```
-```none
-root      3392  1.1  0.8 186804 65208 ?        Sl   00:51  11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
-```
+  ```shell
+  ps auxw | grep kubelet
+  ```
+  ```none
+  root      3392  1.1  0.8 186804 65208 ?        Sl   00:51  11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
+  ```
 
 <!--
 * Confirm the effective `hairpin-mode`. To do this, you'll have to look at
@@ -942,48 +1010,56 @@ match `--hairpin-mode` flag due to compatibility. Check if there is any log
 lines with key word `hairpin` in kubelet.log. There should be log lines
 indicating the effective hairpin mode, like something below.
 -->
+* 确认有效的 `hairpin-mode`。要做到这一点，你必须查看 kubelet 日志。
+  访问日志取决于节点的操作系统。在一些操作系统上，它是一个文件，如 /var/log/kubelet.log，
+  而其他操作系统则使用 `journalctl` 访问日志。请注意，由于兼容性，
+  有效的 `hairpin-mode` 可能不匹配 `--hairpin-mode` 标志。在 kubelet.log
+  中检查是否有带有关键字 `hairpin` 的日志行。应该有日志行指示有效的
+  `hairpin-mode`，就像下面这样。
 
-
-* 确认有效的 `hairpin-mode`。要做到这一点，您必须查看 kubelet 日志。访问日志取决于节点的操作系统。在一些操作系统上，它是一个文件，如 /var/log/kubelet.log，而其他操作系统则使用 `journalctl` 访问日志。请注意，由于兼容性，有效的 `hairpin-mode` 可能不匹配 `--hairpin-mode` 标志。在 kubelet.log 中检查是否有带有关键字 `hairpin` 的日志行。应该有日志行指示有效的 `hairpin-mode`，就像下面这样。
-
-```none
-I0629 00:51:43.648698    3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
-```
+  ```none
+  I0629 00:51:43.648698    3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
+  ```
 
 <!--
 * If the effective hairpin mode is `hairpin-veth`, ensure the `Kubelet` has
 the permission to operate in `/sys` on node. If everything works properly,
 you should see something like:
 -->
-* 如果有效的发卡模式是 `hairpin-veth`, 保证 `Kubelet` 有操作节点上  `/sys` 的权限。如果一切正常，您将会看到如下输出:
+* 如果有效的发夹模式是 `hairpin-veth`, 要保证 `Kubelet` 有操作节点上 `/sys` 的权限。
+  如果一切正常，你将会看到如下输出:
 
-```shell
-for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
-```
-```none
-1
-1
-1
-1
-```
+  ```shell
+  for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
+  ```
+  ```none
+  1
+  1
+  1
+  1
+  ```
 
 <!--
 * If the effective hairpin mode is `promiscuous-bridge`, ensure `Kubelet`
 has the permission to manipulate linux bridge on node. If `cbr0` bridge is
 used and configured properly, you should see:
 -->
-* 如果有效的发卡模式是 `promiscuous-bridge`, 保证 `Kubelet` 有操作节点上 linux bridge 的权限。如果 `cbr0` 桥正在被使用且被正确设置，您将会看到如下输出:
+* 如果有效的发卡模式是 `promiscuous-bridge`, 要保证 `Kubelet` 有操作节点上
+  Linux 网桥的权限。如果 `cbr0` 桥正在被使用且被正确设置，你将会看到如下输出:
 
-```shell
-ifconfig cbr0 |grep PROMISC
-```
-```none
-UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
-```
+  ```shell
+  ifconfig cbr0 |grep PROMISC
+  ```
+  ```none
+  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
+  ```
 
 <!--
 * Seek help if none of above works out.
+-->
+* 如果以上步骤都不能解决问题，请寻求帮助。
 
+<!--
 ## Seek help
 
 If you get this far, something very strange is happening.  Your Service is
@@ -993,31 +1069,27 @@ Service is not working.  Please let us know what is going on, so we can help
 investigate!
 
 Contact us on
-[Slack](/docs/troubleshooting/#slack) or
+[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack) or
 [Forum](https://discuss.kubernetes.io) or
 [GitHub](https://github.com/kubernetes/kubernetes).
-
-
-## {{% heading "whatsnext" %}}
-
-
-Visit [troubleshooting document](/docs/troubleshooting/) for more information.
 -->
-* 如果以上步骤都不能解决问题，请寻求帮助。
-
 ## 寻求帮助
 
-如果您走到这一步，那么就真的是奇怪的事情发生了。您的  Service  正在运行，有 Endpoint ，您的 Pods 也确实在服务中。您的 DNS 正常，`iptables` 规则已经安装，`kube-proxy` 看起来也正常。然而 Service 还是没有正常工作。这种情况下，请告诉我们，这样我们可以帮助调查！
+如果你走到这一步，那么就真的是奇怪的事情发生了。你的 Service 正在运行，有 Endpoints 存在，
+你的 Pods 也确实在提供服务。你的 DNS 正常，`iptables` 规则已经安装，`kube-proxy` 看起来也正常。
+然而 Service 还是没有正常工作。这种情况下，请告诉我们，以便我们可以帮助调查！
 
 通过
-[Slack](/docs/troubleshooting/#slack) 或者
+[Slack](/zh/docs/tasks/debug-application-cluster/troubleshooting/#slack) 或者
 [Forum](https://discuss.kubernetes.io) 或者
 [GitHub](https://github.com/kubernetes/kubernetes) 
 联系我们。
 
-
-
 ## {{% heading "whatsnext" %}}
 
+<!--
+Visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)
+for more information.
+-->
+访问[故障排查文档](/zh/docs/tasks/debug-application-cluster/troubleshooting/) 获取更多信息。
 
-访问 [故障排查文档](/docs/troubleshooting/) 获取更多信息。
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
index 7131a23a52..761ceb44d7 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
@@ -37,13 +37,13 @@ kubectl get pods -l app=myapp
 
 <!--
 If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,
-refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for
+refer to the [Deleting StatefulSet Pods](/docs/tasks/run-application/delete-stateful-set/) task for
 instructions on how to deal with them.
 You can debug individual Pods in a StatefulSet using the
 [Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
 -->
 如果你发现列出的任何 Pod 长时间处于 `Unknown` 或 `Terminating` 状态，请参阅
-[删除 StatefulSet Pods](/zh/docs/tasks/manage-stateful-set/delete-pods/)
+[删除 StatefulSet Pods](/zh/docs/tasks/run-application/delete-stateful-set/)
 了解如何处理它们的说明。
 你可以参考[调试 Pods](/zh/docs/tasks/debug-application-cluster/debug-application/)
 来调试 StatefulSet 中的各个 Pod。
diff --git a/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md
index 885a2347e8..f87b7ce205 100644
--- a/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md
+++ b/content/zh/docs/tasks/debug-application-cluster/get-shell-running-container.md
@@ -1,7 +1,4 @@
 ---
-reviewers:
-- caesarxuchao
-- mikedanese
 title: 获取正在运行容器的 Shell
 content_type: task
 ---
@@ -88,7 +85,7 @@ kubectl exec -it shell-demo -- /bin/bash
 The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments.
 -->
 双破折号 "--" 用于将要传递给命令的参数与 kubectl 的参数分开。
-note >}}
+{{< /note >}}
 
 <!--
 In your shell, list the root directory:
@@ -140,7 +137,7 @@ In your shell, create an `index.html` file in the `/usr/share/nginx/html`
 directory:
 -->
 
-在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html 文件：
+在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html` 文件：
 
 ```shell
 root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index b2532f8a1f..a667fa7f1b 100644
--- a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -20,14 +20,14 @@ in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
 -->
 在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是
 [Stackdriver Logging](https://cloud.google.com/logging/)，
-在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
+在[使用 Stackdriver Logging 管理日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
 中详细描述了这一点。
 
 <!--
 This article describes how to set up a cluster to ingest logs into
 [Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
 them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
-Stackdriver Logging when running on GCE. 
+Stackdriver Logging when running on GCE.
 -->
 本文介绍了如何设置一个集群，将日志导入
 [Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用
@@ -192,4 +192,3 @@ ideas on how to dig into it, check out [Kibana's documentation](https://www.elas
 -->
 Kibana 为浏览你的日志提供了各种强大的选项！有关如何深入研究它的一些想法，
 请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md
new file mode 100644
index 0000000000..0623406b08
--- /dev/null
+++ b/content/zh/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -0,0 +1,619 @@
+---
+title: 使用 Stackdriver 生成日志
+content_type: concept
+---
+
+<!--
+reviewers:
+- piosz
+- x13n
+title: Logging Using Stackdriver
+content_type: concept
+-->
+
+<!-- overview -->
+
+<!--
+Before reading this page, it's highly recommended to familiarize yourself
+with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
+-->
+在阅读这篇文档之前，强烈建议你先熟悉一下 [Kubernetes 日志概况](/zh/docs/concepts/cluster-administration/logging)
+
+<!--
+By default, Stackdriver logging collects only your container's standard output and
+standard error streams. To collect any logs your application writes to a file (for example),
+see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
+in the Kubernetes logging overview.
+-->
+
+{{< note >}}
+默认情况下，Stackdriver 日志机制仅收集容器的标准输出和标准错误流。
+如果要收集你的应用程序写入一个文件（例如）的任何日志，请参见 Kubernetes 日志概述中的 [sidecar 方式](/zh/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
+{{< /note >}}
+
+<!-- body -->
+
+<!--
+## Deploying
+-->
+
+## 部署  {#deploying}
+
+<!--
+To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster.
+The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap`
+and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the
+`ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup.
+-->
+为了接收日志，你必须将 Stackdriver 日志代理部署到集群中的每个节点。
+此代理是一个已配置的 `fluentd`，其配置存在一个 `ConfigMap` 中，且实例使用 Kubernetes 的 `DaemonSet` 进行管理。
+`ConfigMap` 和 `DaemonSet` 的实际部署，取决你的集群设置。
+
+<!--
+### Deploying to a new cluster
+-->
+
+### 部署到一个新的集群
+
+#### Google Kubernetes Engine
+
+<!--
+Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine.
+Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out.
+-->
+对于部署在 Google Kubernetes Engine 上的集群，Stackdriver 是默认的日志解决方案。
+Stackdriver 日志机制会默认部署到你的新集群上，除非你明确地不选择。
+
+<!--
+#### Other platforms
+-->
+
+#### 其他平台
+
+<!--
+To deploy Stackdriver Logging on a *new* cluster that you're
+creating using `kube-up.sh`, do the following:
+-->
+为了将 Stackdriver 日志机制部署到你正在使用 `kube-up.sh` 创建的*新*集群上，执行如下操作：
+
+<!--
+1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`.
+1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true`
+in the `KUBE_NODE_LABELS` variable.
+-->
+1. 设置环境变量 `KUBE_LOGGING_DESTINATION` 为 `gcp`。
+1. **如果不是跑在 GCE 上**，在 `KUBE_NODE_LABELS` 变量中包含 `beta.kubernetes.io/fluentd-ds-ready=true`。
+
+<!--
+Once your cluster has started, each node should be running the Stackdriver Logging agent.
+The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`,
+consider starting a cluster without a pre-configured logging solution and then deploying
+Stackdriver Logging agents to the running cluster.
+-->
+
+集群启动后，每个节点都应该运行 Stackdriver 日志代理。
+`DaemonSet` 和 `ConfigMap` 作为附加组件进行配置。
+如果你不是使用 `kube-up.sh`，可以考虑不使用预先配置的日志方案启动集群，然后部署 Stackdriver 日志代理到正在运行的集群。
+
+<!--
+The Stackdriver logging daemon has known issues on platforms other
+than Google Kubernetes Engine. Proceed at your own risk.
+-->
+
+{{< warning >}}
+除了 Google Kubernetes Engine，Stackdriver 日志守护进程在其他的平台有已知的问题。
+请自行承担风险。
+{{< /warning >}}
+
+<!--
+### Deploying to an existing cluster
+-->
+### 部署到一个已知集群
+
+<!--
+1. Apply a label on each node, if not already present.
+-->
+1. 在每个节点上打标签（如果尚未存在）
+   <!--
+   The Stackdriver Logging agent deployment uses node labels to determine to which nodes
+   it should be allocated. These labels were introduced to distinguish nodes with the
+   Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging
+   configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node
+   cannot have more than one instance of fluentd, therefore only apply labels to the nodes
+   that don't have fluentd pod allocated already. You can ensure that your node is labelled
+   properly by running `kubectl describe` as follows:
+   -->
+
+   Stackdriver 日志代理部署使用节点标签来确定应该将其分配到给哪些节点。
+   引入这些标签是为了区分 Kubernetes 1.6 或更高版本的节点。
+   如果集群是在配置了 Stackdriver 日志机制的情况下创建的，并且节点的版本为 1.5.X 或更低版本，则它将使用 fluentd 用作静态容器。
+   节点最多只能有一个 fluentd 实例，因此只能将标签打在未分配过 fluentd pod 的节点上。
+   你可以通过运行 `kubectl describe` 来确保你的节点被正确标记，如下所示：
+
+   ```
+   kubectl describe node $NODE_NAME
+   ```
+   <!--
+   The output should be similar to this:
+   -->
+   输出应类似于如下内容：
+
+   ```
+   Name:           NODE_NAME
+   Role:
+   Labels:         beta.kubernetes.io/fluentd-ds-ready=true
+   ...
+   ```
+   <!--
+   Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it
+   is not present, you can add it using the `kubectl label` command as follows:
+   -->
+   确保输出内容包含 `beta.kubernetes.io/fluentd-ds-ready=true` 标签。
+   如果不存在，则可以使用 `kubectl label` 命令添加，如下所示：
+
+   ```
+   kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
+   ```
+   <!--
+   If a node fails and has to be recreated, you must re-apply the label to
+   the recreated node. To make this easier, you can use Kubelet's command-line parameter
+   for applying node labels in your node startup script.
+   -->
+
+   {{< note >}}
+   如果节点发生故障并且必须重新创建，则必须将标签重新打在重新创建了的节点。
+   为了让此操作更便捷，你可以在节点启动脚本中使用 Kubelet 的命令行参数给节点添加标签。
+   {{< /note >}}
+
+<!--
+1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
+-->
+2. 通过运行以下命令，部署一个带有日志代理配置的 `ConfigMap`：
+
+   ```
+   kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
+   ```
+   <!--
+   The command creates the `ConfigMap` in the `default` namespace. You can download the file
+   manually and change it before creating the `ConfigMap` object.
+   -->
+   该命令在 `default` 命名空间中创建 `ConfigMap`。你可以在创建 `ConfigMap` 对象之前手动下载文件并进行更改。
+
+<!--
+1. Deploy the logging agent `DaemonSet` by running the following command:
+-->
+3. 通过运行以下命令，部署日志代理的 `DaemonSet`：
+
+   ```
+   kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
+   ```
+   <!--
+   You can download and edit this file before using it as well.
+   -->
+   你也可以在使用前下载和编辑此文件。
+
+<!--
+## Verifying your Logging Agent Deployment
+-->
+## 验证日志代理部署
+
+<!--
+After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status
+by running the following command:
+-->
+部署 Stackdriver `DaemonSet` 之后，你可以通过运行以下命令来查看日志代理的部署状态：
+
+```shell
+kubectl get ds --all-namespaces
+```
+
+<!--
+If you have 3 nodes in the cluster, the output should looks similar to this:
+-->
+如果你的集群中有 3 个节点，则输出应类似于如下：
+
+```
+NAMESPACE     NAME               DESIRED   CURRENT   READY     NODE-SELECTOR                              AGE
+...
+default       fluentd-gcp-v2.0   3         3         3         beta.kubernetes.io/fluentd-ds-ready=true   5m
+...
+```
+
+<!--
+To understand how logging with Stackdriver works, consider the following
+synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml):
+-->
+要了解使用 Stackdriver 进行日志记录的工作方式，请考虑以下具有日志生成的 pod 定义 [counter-pod.yaml](/examples/debug/counter-pod.yaml)：
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+<!--
+This pod specification has one container that runs a bash script
+that writes out the value of a counter and the datetime once per
+second, and runs indefinitely. Let's create this pod in the default namespace.
+-->
+这个 pod 定义里有一个容器，该容器运行一个 bash 脚本，脚本每秒写一次计数器的值和日期时间，并无限期地运行。
+让我们在默认命名空间中创建此 pod。
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+
+<!--
+You can observe the running pod:
+-->
+你可以观察到正在运行的 pod：
+
+```shell
+kubectl get pods
+```
+```
+NAME                                           READY     STATUS    RESTARTS   AGE
+counter                                        1/1       Running   0          5m
+```
+
+<!--
+For a short period of time you can observe the 'Pending' pod status, because the kubelet
+has to download the container image first. When the pod status changes to `Running`
+you can use the `kubectl logs` command to view the output of this counter pod.
+-->
+在短时间内，你可以观察到 "pending" 的 pod 的状态，因为 kubelet 必须先下载容器镜像。
+当 pod 状态变为 `Running` 时，你可以使用 `kubectl logs` 命令查看此 counter pod 的输出。
+
+```shell
+kubectl logs counter
+```
+```
+0: Mon Jan  1 00:00:00 UTC 2001
+1: Mon Jan  1 00:00:01 UTC 2001
+2: Mon Jan  1 00:00:02 UTC 2001
+...
+```
+
+<!--
+As described in the logging overview, this command fetches log entries
+from the container log file. If the container is killed and then restarted by
+Kubernetes, you can still access logs from the previous container. However,
+if the pod is evicted from the node, log files are lost. Let's demonstrate this
+by deleting the currently running counter container:
+-->
+正如日志概览所述，此命令从容器日志文件中获取日志项。
+如果该容器被 Kubernetes 杀死然后重新启动，你仍然可以访问前一个容器的日志。
+但是，如果将 Pod 从节点中驱逐，则日志文件会丢失。让我们通过删除当前运行的 counter 容器来演示这一点：
+
+```shell
+kubectl delete pod counter
+```
+```
+pod "counter" deleted
+```
+
+<!--
+and then recreating it:
+-->
+然后重建它：
+
+```shell
+kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+```
+pod/counter created
+```
+
+<!--
+After some time, you can access logs from the counter pod again:
+-->
+一段时间后，你可以再次从 counter pod 访问日志：
+
+```shell
+kubectl logs counter
+```
+```
+0: Mon Jan  1 00:01:00 UTC 2001
+1: Mon Jan  1 00:01:01 UTC 2001
+2: Mon Jan  1 00:01:02 UTC 2001
+...
+```
+
+<!--
+As expected, only recent log lines are present. However, for a real-world
+application you will likely want to be able to access logs from all containers,
+especially for the debug purposes. This is exactly when the previously enabled
+Stackdriver Logging can help.
+-->
+如预期的那样，日志中仅出现最近的日志记录。
+但是，对于实际应用程序，你可能希望能够访问所有容器的日志，特别是出于调试的目的。
+这就是先前启用的 Stackdriver 日志机制可以提供帮助的地方。
+
+<!--
+## Viewing logs
+-->
+## 查看日志
+
+<!--
+Stackdriver Logging agent attaches metadata to each log entry, for you to use later
+in queries to select only the messages you're interested in: for example,
+the messages from a particular pod.
+-->
+Stackdriver 日志代理为每个日志项关联元数据，供你在后续的查询中只选择感兴趣的消息：
+例如，来自某个特定 Pod 的消息。
+
+<!--
+The most important pieces of metadata are the resource type and log name.
+The resource type of a container log is `container`, which is named
+`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine).
+The log name is the name of the container, so that if you have a pod with
+two containers, named `container_1` and `container_2` in the spec, their logs
+will have log names `container_1` and `container_2` respectively.
+-->
+元数据最重要的部分是资源类型和日志名称。
+容器日志的资源类型为 `container`，在用户界面中名为 `GKE Containers`（即使 Kubernetes 集群不在 Google Kubernetes Engine 上）。
+日志名称是容器的名称，因此，如果你有一个包含两个容器的 pod，在 spec 中名称定义为 `container_1` 和 `container_2`，则它们的日志的名称分别为 `container_1` 和 `container_2`。
+
+<!--
+System components have resource type `compute`, which is named
+`GCE VM Instance` in the interface. Log names for system components are fixed.
+For a Google Kubernetes Engine node, every log entry from a system component has one of the following
+log names:
+-->
+系统组件的资源类型为 `compute`，在接口中名为 `GCE VM Instance`。
+系统组件的日志名称是固定的。
+对于 Google Kubernetes Engine 节点，系统组件中的每个日志项都具有以下日志名称之一：
+
+* docker
+* kubelet
+* kube-proxy
+
+<!--
+You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
+-->
+你可以在[专用 Stackdriver 页面](https://cloud.google.com/logging/docs/view/overview)上了解有关查看日志的更多信息。
+
+<!--
+One of the possible ways to view logs is using the
+[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
+command line interface from the [Google Cloud SDK].
+It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
+to query specific logs. For example, you can run the following command:
+-->
+查看日志的一种可能方法是使用 [Google Cloud SDK]((https://cloud.google.com/sdk/)) 中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) 命令行接口。
+它使用 Stackdriver 日志机制的[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。
+例如，你可以运行以下命令：
+
+```none
+gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
+```
+```
+...
+"2: Mon Jan  1 00:01:02 UTC 2001\n"
+"1: Mon Jan  1 00:01:01 UTC 2001\n"
+"0: Mon Jan  1 00:01:00 UTC 2001\n"
+...
+"2: Mon Jan  1 00:00:02 UTC 2001\n"
+"1: Mon Jan  1 00:00:01 UTC 2001\n"
+"0: Mon Jan  1 00:00:00 UTC 2001\n"
+```
+
+<!--
+As you can see, it outputs messages for the count container from both
+the first and second runs, despite the fact that the kubelet already deleted
+the logs for the first container.
+-->
+如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter 容器第一次和第二次运行时输出的消息。
+
+<!--
+### Exporting logs
+-->
+### 导出日志
+
+<!--
+You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
+or to [BigQuery](https://cloud.google.com/bigquery/) to run further
+analysis. Stackdriver Logging offers the concept of sinks, where you can
+specify the destination of log entries. More information is available on
+the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
+-->
+你可以将日志导出到 [Google Cloud Storage](https://cloud.google.com/storage/) 或
+[BigQuery](https://cloud.google.com/bigquery/) 进行进一步的分析。
+Stackdriver 日志机制提供了接收器（Sink）的概念，你可以在其中指定日志项的存放地。
+可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2)上获得更多信息。
+
+<!--
+## Configuring Stackdriver Logging Agents
+-->
+## 配置 Stackdriver 日志代理
+
+<!--
+Sometimes the default installation of Stackdriver Logging may not suit your needs, for example:
+-->
+有时默认的 Stackdriver 日志机制安装可能无法满足你的需求，例如：
+
+<!--
+* You may want to add more resources because default performance doesn't suit your needs.
+* You may want to introduce additional parsing to extract more metadata from your log messages,
+like severity or source code reference.
+* You may want to send logs not only to Stackdriver or send it to Stackdriver only partially.
+-->
+* 你可能需要添加更多资源，因为默认的行为表现无法满足你的需求。
+* 你可能需要引入额外的解析机制以便从日志消息中提取更多元数据，例如严重性或源代码引用。
+* 你可能想要将日志不仅仅发送到 Stackdriver 或仅将部分日志发送到 Stackdriver。
+
+<!--
+In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`.
+-->
+在这种情况下，你需要更改 `DaemonSet` 和 `ConfigMap` 的参数。
+
+<!--
+### Prerequisites
+-->
+### 先决条件
+
+<!--
+If you're using GKE and Stackdriver Logging is enabled in your cluster, you
+cannot change its configuration, because it's managed and supported by GKE.
+However, you can disable the default integration and deploy your own.
+-->
+如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置，因为它是由 GKE 管理和支持的。
+但是，你可以禁用默认集成的日志机制并部署自己的。
+
+<!--
+You will have to support and maintain a newly deployed configuration
+yourself: update the image and configuration, adjust the resources and so on.
+-->
+
+{{< note >}}
+你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。
+{{< /note >}}
+
+<!--
+To disable the default logging integration, use the following command:
+-->
+若要禁用默认的日志记录集成，请使用以下命令：
+
+```
+gcloud beta container clusters update --logging-service=none CLUSTER
+```
+
+<!--
+You can find notes on how to then install Stackdriver Logging agents into
+a running cluster in the [Deploying section](#deploying).
+-->
+你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到正在运行的集群中的说明​​。
+
+<!--
+### Changing `DaemonSet` parameters
+-->
+### 更改 `DaemonSet` 参数    {#changing-daemonset-parameters}
+
+<!--
+When you have the Stackdriver Logging `DaemonSet` in your cluster, you can just modify the
+`template` field in its spec, daemonset controller will update the pods for you. For example,
+let's assume you've just installed the Stackdriver Logging as described above. Now you want to
+change the memory limit to give fluentd more memory to safely process more logs.
+-->
+当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 `template` 字段，daemonset 控制器将为你更新 pod。
+例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。
+现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。
+
+<!--
+Get the spec of `DaemonSet` running in your cluster:
+-->
+获取集群中运行的 `DaemonSet` 的 spec：
+
+```shell
+kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
+```
+
+<!--
+Then edit resource requirements in the spec file and update the `DaemonSet` object
+in the apiserver using the following command:
+-->
+然后在 spec 文件中编辑资源需求，并使用以下命令更新 apiserver 中的 `DaemonSet` 对象：
+
+```shell
+kubectl replace -f fluentd-gcp-ds.yaml
+```
+
+<!--
+After some time, Stackdriver Logging agent pods will be restarted with the new configuration.
+-->
+一段时间后，Stackdriver 日志代理的 pod 将使用新配置重新启动。
+
+<!--
+### Changing fluentd parameters
+-->
+### 更改 fluentd 参数
+
+<!--
+Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
+files that are merged together. You can learn about fluentd configuration on the
+[official site](https://docs.fluentd.org).
+-->
+Fluentd 的配置存在 `ConfigMap` 对象中。
+它实际上是一组合并在一起的配置文件。
+你可以在[官方网站](https://docs.fluentd.org)上了解 fluentd 的配置。
+
+<!--
+Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
+default Python logging format. An appropriate fluentd filter looks similar to this:
+-->
+假设你要向配置添加新的解析逻辑，以便 fluentd 可以理解默认的 Python 日志记录格式。
+一个合适的 fluentd 过滤器类似如下：
+
+```
+<filter reform.**>
+  type parser
+  format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/
+  reserve_data true
+  suppress_parse_error_log true
+  key_name log
+</filter>
+```
+
+<!--
+Now you have to put it in the configuration and make Stackdriver Logging agents pick it up.
+Get the current version of the Stackdriver Logging `ConfigMap` in your cluster
+by running the following command:
+-->
+现在，你需要将其放入配置中，并使 Stackdriver 日志代理感知它。
+通过运行以下命令，获取集群中当前版本的 Stackdriver 日志机制的 `ConfigMap`：
+
+```shell
+kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
+```
+
+<!--
+Then in the value of the key `containers.input.conf` insert a new filter right after
+the `source` section.
+-->
+然后在 `containers.input.conf` 键的值中，在 `source` 部分之后插入一个新的过滤器。
+
+<!--
+Order is important.
+-->
+
+{{< note >}}
+顺序很重要。
+{{< /note >}}
+
+<!--
+Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
+to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
+create `ConfigMap` with a new name and then change `DaemonSet` to point to it
+using [guide above](#changing-daemonset-parameters).
+-->
+在 apiserver 中更新 `ConfigMap` 比更新 `DaemonSet` 更复杂。
+最好考虑 `ConfigMap` 是不可变的。
+如果是这样，要更新配置，你应该使用新名称创建 `ConfigMap`，然后使用
+[上面的指南](#changing-daemonset-parameters)将 `DaemonSet` 更改为指向它。
+
+<!--
+### Adding fluentd plugins
+-->
+### 添加 fluentd 插件
+
+<!--
+Fluentd is written in Ruby and allows to extend its capabilities using
+[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
+in the default Stackdriver Logging container image, you have to build a custom image. Imagine
+you want to add Kafka sink for messages from a particular container for additional processing.
+You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
+with minor changes:
+-->
+Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plugins) 扩展其功能。
+如果要使用默认的 Stackdriver 日志机制容器镜像中未包含的插件，则必须构建自定义镜像。
+假设你要为来自特定容器添加 Kafka 信息接收器，以进行其他处理。
+你可以复用默认的[容器镜像源](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)，并仅添加少量更改：
+
+<!--
+* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
+* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.
+-->
+* 将 Makefile 更改为指向你的容器仓库，例如 `PREFIX=gcr.io/<your-project-id>`。
+* 将你的依赖项添加到 Gemfile 中，例如 `gem 'fluent-plugin-kafka'`。
+
+<!--
+Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
+new image, you can use the plugin you installed in the fluentd configuration.
+-->
+然后在该目录运行 `make build push`。在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。
diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index fb878af5de..91cfe11c46 100644
--- a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -14,28 +14,29 @@ content_type: concept
 
 <!--
 Resource usage metrics, such as container CPU and memory usage,
-are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
-by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
+are available in Kubernetes through the Metrics API. These metrics can be accessed either directly
+by the user with the `kubectl top` command, or by a controller in the cluster, for example
 Horizontal Pod Autoscaler, to make decisions.
 -->
 资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。
-这些指标可以直接被用户访问，比如使用 `kubectl top` 命令行，或者这些指标由集群中的控制器使用，
-例如，Horizontal Pod Autoscaler，使用这些指标来做决策。
+这些指标可以直接被用户访问，比如使用 `kubectl top` 命令行，或者被集群中的控制器
+（例如 Horizontal Pod Autoscalers) 使用来做决策。
 
 <!-- body -->
 
 <!--
 ## The Metrics API
 
-Through the Metrics API you can get the amount of resource currently used
+Through the Metrics API, you can get the amount of resource currently used
 by a given node or a given pod. This API doesn't store the metric values,
-so it's not possible for example to get the amount of resources used by a
+so it's not possible, for example, to get the amount of resources used by a
 given node 10 minutes ago.
 -->
 ## Metrics API   {#the-metrics-api}
 
 通过 Metrics API，你可以获得指定节点或 Pod 当前使用的资源量。
-此 API 不存储指标值，因此想要获取某个指定节点 10 分钟前的资源使用量是不可能的。
+此 API 不存储指标值，因此想要获取某个指定节点 10 分钟前的
+资源使用量是不可能的。
 
 <!--
 The API is no different from any other API:
@@ -43,12 +44,12 @@ The API is no different from any other API:
 此 API 与其他 API 没有区别：
 
 <!--
-- it is discoverable through the same endpoint as the other Kubernetes APIs under `/apis/metrics.k8s.io/` path
-- it offers the same security, scalability and reliability guarantees
+- it is discoverable through the same endpoint as the other Kubernetes APIs under the path: `/apis/metrics.k8s.io/`
+- it offers the same security, scalability, and reliability guarantees
 -->
-- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下，是可发现的，
+- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下且可发现，
   路径为 `/apis/metrics.k8s.io/` 
-- 它提供相同的安全性、可扩展性和可靠性保证
+- 它具有相同的安全性、可扩展性和可靠性保证
 
 <!--
 The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
@@ -69,7 +70,11 @@ Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
 
 ### CPU
 
-CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window  for the rate calculation.
+CPU is reported as the average usage, in
+[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu),
+over a period of time. This value is derived by taking a rate over a cumulative CPU counter
+provided by the kernel (in both Linux and Windows kernels).
+The kubelet chooses the window for the rate calculation.
 -->
 ## 度量资源用量   {#measuring-resource-usage}
 
@@ -80,6 +85,15 @@ CPU 用量按其一段时间内的平均值统计，单位为
 此度量值通过在内核（包括 Linux 和 Windows）提供的累积 CPU 计数器乘以一个系数得到。
 `kubelet` 组件负责选择计算系数所使用的窗口大小。
 
+<!--
+### Memory
+
+Memory is reported as the working set, in bytes, at the instant the metric was collected.
+In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
+However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
+It includes all anonymous (non-file-backed) memory since Kubernetes does not support swap.
+The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
+-->
 ### 内存  {#memory}
 
 内存用量按工作集（Working Set）的大小字节数统计，其数值为收集度量值的那一刻的内存用量。
@@ -94,37 +108,35 @@ CPU 用量按其一段时间内的平均值统计，单位为
 <!--
 ## Metrics Server
 
-[Metrics Server](https://github.com/kubernetes-incubator/metrics-server) is a cluster-wide aggregator of resource usage data.
-Starting from Kubernetes 1.8 it's deployed by default in clusters created by `kube-up.sh` script
+[Metrics Server](https://github.com/kubernetes-sigs/metrics-server) is a cluster-wide aggregator of resource usage data.
+By default, it is deployed in clusters created by `kube-up.sh` script
 as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
-[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy).
-It's supported in Kubernetes 1.7+ (see details below).
+[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
 -->
 ## Metrics 服务器    {#metrics-server}
 
-[Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server)是集群范围资源使用数据的聚合器。
-在由 `kube-up.sh` 脚本创建的集群中默认会以 Deployment 的形式被部署。
+[Metrics 服务器](https://github.com/kubernetes-sings/metrics-server)
+是集群范围资源用量数据的聚合器。
+默认情况下，在由 `kube-up.sh` 脚本创建的集群中会以 Deployment 的形式被部署。
 如果你使用其他 Kubernetes 安装方法，则可以使用提供的
-[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)
+[部署组件 components.yaml](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)
 来部署。
 
 <!--
-Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
+Metric server collects metrics from the Summary API, exposed by
+[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node, and is registered with the main API server via
+[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
 -->
-Metric server 从每个节点上的 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+Metric 服务器从每个节点上的 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
 公开的 Summary API 中采集指标信息。
+该 API 通过
+[Kubernetes 聚合器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+注册到主 API 服务器上。
 
 <!--
-Metrics Server registered in the main API server through
-[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/),
-which was introduced in Kubernetes 1.7.
+Learn more about the metrics server in
+[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
 -->
-Metrics 服务器通过
-[Kubernetes 聚合器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 
-注册到主 API 服务器。
-
-<!--
-Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
--->
-在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)中可以了解到有关 Metrics 服务器的更多信息。
+在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)
+中可以了解到有关 Metrics 服务器的更多信息。
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index 9ed63ffa71..86345a09a8 100644
--- a/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -15,7 +15,8 @@ title: Tools for Monitoring Resources
 To scale an application and provide a reliable service, you need to
 understand how the application behaves when it is deployed. You can examine
 application performance in a Kubernetes cluster by examining the containers,
-[pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and
+[pods](/docs/concepts/workloads/pods/),
+[services](/docs/concepts/services-networking/service/), and
 the characteristics of the overall cluster. Kubernetes provides detailed
 information about an application's resource usage at each of these levels.
 This information allows you to evaluate your application's performance and
@@ -23,7 +24,8 @@ where bottlenecks can be removed to improve overall performance.
 -->
 要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。
 你可以通过检测容器检查 Kubernetes 集群中的应用程序性能，
-[Pods](/zh/docs/concepts/workloads/pods), [服务](/zh/docs/concepts/services-networking/service/)
+[Pods](/zh/docs/concepts/workloads/pods), 
+[服务](/zh/docs/concepts/services-networking/service/)
 和整个集群的特征。
 Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
 此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
@@ -31,7 +33,9 @@ Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细
 <!-- body -->
 
 <!--
-In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
+In Kubernetes, application monitoring does not depend on a single monitoring solution.
+On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or
+[full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
 -->
 在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。
 在新集群上，你可以使用[资源度量](#resource-metrics-pipeline)或
@@ -41,24 +45,26 @@ In Kubernetes, application monitoring does not depend on a single monitoring sol
 ## Resource metrics pipeline
 
 The resource metrics pipeline provides a limited set of metrics related to
-cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
+cluster components such as the
+[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale)
+controller, as well as the `kubectl top` utility.
 These  metrics are collected by the lightweight, short-term, in-memory 
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server) and
  are exposed via the `metrics.k8s.io` API. 
 -->
 ## 资源度量管道  {#resource-metrics-pipeline}
 
 资源指标管道提供了一组与集群组件，例如
-[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)控制器，
-以及 `kubectl top` 实用程序相关的有限度量。
+[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+控制器以及 `kubectl top` 实用程序相关的有限度量。
 这些指标是由轻量级的、短期、内存存储的
-[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的，
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 收集的，
 通过 `metrics.k8s.io` 公开。
 
 <!--
 metrics-server discovers all nodes on the cluster and 
 queries each node's 
-[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and 
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/) for CPU and 
 memory usage. The kubelet acts as a bridge between the Kubernetes master and 
 the nodes, managing the pods and containers running on a machine. The kubelet 
 translates each pod into its constituent containers and fetches individual 
@@ -70,12 +76,14 @@ This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated
 read-only ports. 
 -->
 度量服务器发现集群中的所有节点，并且查询每个节点的
-[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
+[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+以获取 CPU 和内存使用情况。
 Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
-kubelet 将每个 pod 转换为其组成的容器，并在容器运行时通过容器运行时界面获取各个容器使用情况统计信息。
+kubelet 将每个 Pod 转换为其组成的容器，并在容器运行时通过容器运行时接口
+获取各个容器使用情况统计信息。
 kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
 然后，它通过 metrics-server Resource Metrics API 公开聚合的 pod 资源使用情况统计信息。
-该 API 在 kubelet 的经过身份验证和只读的端口上的`/metrics/resource/v1beta1`中提供。
+该 API 在 kubelet 的经过身份验证和只读的端口上的 `/metrics/resource/v1beta1` 中提供。
 
 <!--
 ## Full metrics pipeline
@@ -90,7 +98,8 @@ then exposes them to Kubernetes via an adapter by implementing either the
 ## 完整度量管道  {#full-metrics-pipeline}
 
 一个完整度量管道可以让你访问更丰富的度量。
-Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，通过自动调用扩展或调整集群来响应这些度量。
+Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，
+通过自动调用扩展或调整集群来响应这些度量。
 监控管道从 kubelet 获取度量值，然后通过适配器将它们公开给 Kubernetes，
 方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
 
@@ -98,7 +107,7 @@ Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩
 [Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
 Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.  
 -->
-[Prometheus](https://prometheus.io) 是一个 CNCF 项目，可以原生监控 Kubernetes、节点和 
-Prometheus 本身。
+[Prometheus](https://prometheus.io) 是一个 CNCF 项目，可以原生监控 Kubernetes、
+节点和 Prometheus 本身。
 完整度量管道项目不属于 CNCF 的一部分，不在 Kubernetes 文档的范围之内。
 
diff --git a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
index 4b7ff235ff..09e7a862b8 100644
--- a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
+++ b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
@@ -3,7 +3,7 @@ reviewers:
 - brendandburns
 - davidopp
 content_type: concept
-title: 排错
+title: 故障诊断
 ---
 
 <!--
@@ -26,9 +26,10 @@ two sections:
    * [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful for users who are deploying code into Kubernetes and wondering why it is not working.
    * [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy.
 -->
-
-* [应用排错](/zh/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。
-* [集群排错](/zh/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。
+* [应用排错](/zh/docs/tasks/debug-application-cluster/debug-application/) -
+  针对部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。
+* [集群排错](/zh/docs/tasks/debug-application-cluster/debug-cluster/) -
+  针对集群管理员以及 Kubernetes 集群表现异常的用户。
 
 <!--
 You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
@@ -61,7 +62,7 @@ development scenarios. The [Reference](/docs/reference/) section provides
 detailed documentation on the [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl-overview/).
 -->
-### 提问
+### 问题  {#questions}
 
 本网站上的文档针对回答各类问题进行了结构化组织和分类。
 [概念](/zh/docs/concepts/)部分解释 Kubernetes 体系结构以及每个组件的工作方式，
@@ -72,18 +73,10 @@ and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl
 [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档
 和命令行 (CLI) 接口的文档，例如[`kubectl`](/zh/docs/reference/kubectl/overview/)。
 
-<!--
-You may also find the Stack Overflow topics relevant:
--->
-你还在 StackOverflow 上查找相关主题：
-
-* [Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes)
-* [Google Kubernetes Engine](https://stackoverflow.com/questions/tagged/google-container-engine)
-
 <!--
 ## Help! My question isn't covered!  I need help now!
 -->
-## 求救！我的问题还没有解决！我需要立即得到帮助！
+## 求救！我的问题还没有解决！我现在需要帮助！
 
 <!--
 ### Stack Overflow
@@ -94,7 +87,7 @@ be able to help with your problem. The Kubernetes team will also monitor
 If there aren't any existing questions that help, please
 [ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)!
 -->
-### StackOverflow    {#stack-overflow}
+### Stack Overflow    {#stack-overflow}
 
 社区中的其他人可能已经问过和你类似的问题，也可能能够帮助解决你的问题。
 Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](https://stackoverflow.com/questions/tagged/kubernetes)。
@@ -103,28 +96,32 @@ Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](https://stackov
 <!--
 ### Slack
 
-The Kubernetes team hangs out on Slack in the `#kubernetes-users` channel. You
-can participate in discussion with the Kubernetes team [here](https://kubernetes.slack.com).
-Slack requires registration, but the Kubernetes team is open invitation to
-anyone to register [here](https://slack.kubernetes.io). Feel free to come and ask
-any and all questions.
+Many people from the Kubernetes community hang out on Kubernetes Slack in the `#kubernetes-users` channel.
+Slack requires registration; you can [request an invitation](https://slack.kubernetes.io),
+and registration is open to everyone). Feel free to come and ask any and all questions.
+Once registered, access the [Kubernetes organisation in Slack](https://kubernetes.slack.com)
+via your web browser or via Slack's own dedicated app.
 -->
 ### Slack
 
-Kubernetes 团队在 Slack 中建有 `#kubernetes-users` 频道。
-你可以[在这里](https://kubernetes.slack.com)参与 Kubernetes 团队的讨论。
-Slack 需要注册，但 Kubernetes 团队公开邀请任何人[在这里](https://slack.kubernetes.io)注册。
-欢迎你随时来问任何问题。
+Kubernetes 社区中有很多人在 `#kubernetes-users` 这一 Slack 频道聚集。
+Slack 需要注册；你可以[请求一份邀请](https://slack.kubernetes.io)，
+并且注册是对所有人开放的。欢迎你随时来问任何问题。
+一旦注册了，就可以访问通过 Web 浏览器或者 Slack 专用的应用访问
+[Slack 上的 Kubernetes 组织](https://kubernetes.slack.com)。
 
 <!--
-Once registered, browse the growing list of channels for various subjects of
+Once you are registered, browse the growing list of channels for various subjects of
 interest. For example, people new to Kubernetes may also want to join the
-`#kubernetes-novice` channel. As another example, developers should join the
-`#kubernetes-dev` channel.
+[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) channel. As another example, developers should join the
+[`#kubernetes-dev`](https://kubernetes.slack.com/messages/kubernetes-dev) channel.
 -->
-一旦注册完成，你就可以浏览各种感兴趣的频道列表。
-例如，Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。
-又比如，开发人员应该加入 `#kubernetes-dev` 频道。
+一旦你完成了注册，就可以浏览各种感兴趣主题的频道列表（一直在增长）。
+例如，Kubernetes 新人可能还想加入
+[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice)
+频道。又比如，开发人员应该加入
+[`#kubernetes-dev`](https://kubernetes.slack.com/messages/kubernetes-dev)
+频道。
 
 <!--
 There are also many country specific/local language channels. Feel free to join
@@ -132,44 +129,55 @@ these channels for localized support and info:
 -->
 还有许多国家/地区语言频道。请随时加入这些频道以获得本地化支持和信息：
 
+{{< table caption="Country / language specific Slack channels" >}}
 <!--
-- China: `#cn-users`, `#cn-events`
-- France: `#fr-users`, `#fr-events`
-- Germany: `#de-users`, `#de-events`
-- India: `#in-users`, `#in-events`
-- Italy: `#it-users`, `#it-events`
-- Japan: `#jp-users`, `#jp-events`
-- Korea: `#kr-users`
-- Netherlands: `#nl-users`
-- Norway: `#norw-users`
-- Poland: `#pl-users`
-- Russia: `#ru-users`
-- Spain: `#es-users`
-- Turkey: `#tr-users`, `#tr-events`
+Country | Channels
+:---------|:------------
+China | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events)
+Finland | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users)
+France | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events)
+Germany | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events)
+India | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events)
+Italy | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events)
+Japan | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events)
+Korea | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users)
+Netherlands | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users)
+Norway | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users)
+Poland | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users)
+Russia | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users)
+Spain | [`#es-users`](https://kubernetes.slack.com/messages/es-users)
+Sweden | [`#se-users`](https://kubernetes.slack.com/messages/se-users)
+Turkey | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events)
 -->
-- 中国： `#cn-users`, `#cn-events`
-- 法国： `#fr-users`, `#fr-events`
-- 德国： `#de-users`, `#de-events`
-- 印度： `#in-users`, `#in-events`
-- 意大利： `#it-users`, `#it-events`
-- 日本： `#jp-users`, `#jp-events`
-- 韩国： `#kr-users`
-- 荷兰： `#nl-users`
-- 挪威： `#norw-users`
-- 波兰： `#pl-users`
-- 俄罗斯： `#ru-users`
-- 西班牙： `#es-users`
-- 土耳其： `#tr-users`, `#tr-events`
+国家   | 频道
+:------|:------------
+中国   | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events)
+芬兰   | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users)
+法国   | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events)
+德国   | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events)
+印度   | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events)
+意大利 | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events)
+日本   | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events)
+韩国   | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users)
+荷兰   | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users)
+挪威   | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users)
+波兰   | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users)
+俄罗斯 | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users)
+西班牙 | [`#es-users`](https://kubernetes.slack.com/messages/es-users)
+瑞典   | [`#se-users`](https://kubernetes.slack.com/messages/se-users)
+土耳其 | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events)
 
+{{< /table >}}
 
 <!--
 ### Forum
 
-The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io)
+You're welcome to join the official Kubernetes Forum: [discuss.kubernetes.io](https://discuss.kubernetes.io).
 -->
 ### 论坛  {#forum}
 
-Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io)
+欢迎你加入 Kubernetes 官方论坛
+[discuss.kubernetes.io](https://discuss.kubernetes.io)。
 
 <!--
 ### Bugs and Feature requests
@@ -177,7 +185,7 @@ Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io)
 If you have what looks like a bug, or you would like to make a feature request,
 please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues).
 -->
-### Bugs 和功能请求（Feature Request）
+### Bugs 和功能请求   {#bugs-and-feature-requests}
 
 如果你发现一个看起来像 Bug 的问题，或者你想提出一个功能请求，请使用
 [Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。
@@ -189,7 +197,7 @@ already covered.
 If filing a bug, please include detailed information about how to reproduce the
 problem, such as:
 -->
-在提交问题之前，请搜索现有问题以查看是否其中已涵盖你的问题。
+在提交问题之前，请搜索现有问题列表以查看是否其中已涵盖你的问题。
 
 如果提交 Bug，请提供如何重现问题的详细信息，例如：
 
@@ -198,8 +206,7 @@ problem, such as:
 * Cloud provider, OS distro, network configuration, and Docker version
 * Steps to reproduce the problem
 -->
-* Kubernetes 版本：获取版本的命令为 `kubectl version`
-* 云提供商、OS 发行版、网络配置和 Docker 版本
+* Kubernetes 版本：`kubectl version`
+* 云平台、OS 发行版、网络配置和 Docker 版本
 * 重现问题的步骤
 
-
diff --git a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
index bba139ae1d..6734a0d0d5 100644
--- a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -1,6 +1,6 @@
 ---
 title: 用插件扩展 kubectl
-description: 通过创建和安装 kubectl 插件扩展 kubectl
+description: 通过创建和安装 kubectl 插件扩展 kubectl。
 content_type: task
 ---
 
@@ -243,14 +243,14 @@ An older kubectl plugin mechanism provided environment variables such as `KUBECT
 kubectl plugins must parse and validate all of the arguments passed to them.
 See [using the command line runtime package](#using-the-command-line-runtime-package) for details of a Go library aimed at plugin authors.
 
-Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.
 -->
-kubeclt 插件必须解析并检查传递给它们的所有参数。
+kubectl 插件必须解析并检查传递给它们的所有参数。
 参阅[使用命令行运行时包](#using-the-command-line-runtime-package)了解针对
 插件开发人员的 Go 库的细节。
 
 <!--
-Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the `kubectl-foo-bar-baz` plugin from the scenario above.
 -->
 这里是一些用户调用你的插件的时候提供额外标志和参数的场景。
 这些场景时基于上述案例中的 `kubectl-foo-bar-baz` 插件的。
@@ -261,7 +261,7 @@ would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, kubectl then
 Upon having found a plugin with this name, kubectl then invokes that plugin, passing all args and flags after the plugin's name as arguments to the plugin process.
 -->
 
-如果你运行 `kubectl foo bar baz arg1 --flag=value arg2`，kubeclt 的插件机制将首先尝试找到
+如果你运行 `kubectl foo bar baz arg1 --flag=value arg2`，kubectl 的插件机制将首先尝试找到
 最长可能名称的插件，在本例中是 `kubectl-foo-bar-baz-arg1`。
 当没有找到这个插件时，kubectl 就会将最后一个以破折号分隔的值视为参数（在本例中为 `arg1`），
 并尝试找到下一个最长的名称 `kubectl-foo-bar-baz`。
@@ -313,7 +313,7 @@ command containing dashes in its commandline invocation by using underscores (`_
 #### 带有破折号和下划线的名称
 
 虽然 `kubectl` 插件机制在插件文件名中使用破折号（`-`）分隔插件处理的子命令序列，
-但是仍然可以通过在文件名中使用下划线（`-`）来创建命令行中包含破折号的插件命令。
+但是仍然可以通过在文件名中使用下划线（`_`）来创建命令行中包含破折号的插件命令。
 
 <!-- Example: -->
 例子：
@@ -338,7 +338,7 @@ Note that the introduction of underscores to a plugin filename does not prevent
 The command from the above example, can be invoked using either a dash (`-`) or an underscore (`_`):
 -->
 请注意，在插件文件名中引入下划线并不会阻止我们使用 `kubectl foo_bar` 之类的命令。
-可以使用破折号（`-`）或下划线（`-`）调用上面示例中的命令:
+可以使用破折号（`-`）或下划线（`_`）调用上面示例中的命令:
 
 ```shell
 # 我们的插件也可以用破折号来调用
diff --git a/content/zh/docs/tasks/extend-kubernetes/_index.md b/content/zh/docs/tasks/extend-kubernetes/_index.md
index 2bf9ad2537..3de1e50de6 100644
--- a/content/zh/docs/tasks/extend-kubernetes/_index.md
+++ b/content/zh/docs/tasks/extend-kubernetes/_index.md
@@ -1,5 +1,5 @@
 ---
 title: "扩展 Kubernetes"
-description: 了解针对工作环境需要来调整 Kubernetes 集群的进阶方法
+description: 了解针对工作环境需要来调整 Kubernetes 集群的进阶方法。
 weight: 90
 ---
diff --git a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
index a37263f949..0db27194c6 100644
--- a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
+++ b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
@@ -16,7 +16,7 @@ weight: 10
 <!-- overview -->
 
 <!--
-Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. 
+Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
 -->
 配置 [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 允许
 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。
@@ -26,7 +26,7 @@ Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernete
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 <!--
-There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. 
+There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
 -->
 {{< note >}}
 要使聚合层在您的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
@@ -165,7 +165,7 @@ note:
 3.Kube Apiserver 使用任何配置的鉴权方法（例如 RBAC）对请求的 URL 鉴权
 
 kube-apiserver / aggregator -> 聚合的 apiserver:
-   
+
 note:
 4.aggregator 使用`--proxy-client-cert-file`，`--proxy-client-key-file`客户端证书/密钥打开与聚合 Apiserver 的连接以保护通道
 
@@ -217,7 +217,7 @@ The Kubernetes apiserver now is prepared to send the request to the extension ap
 
 用户与 Kubernetes apiserver 通信，请求访问 path 。Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定 path 的鉴权。
 
-有关对 Kubernetes 集群认证的概述，请参见 [对集群认证](/docs/reference/access-authn-authz/authentication/)。有关对Kubernetes群集资源的访问鉴权的概述，请参见 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
+有关对 Kubernetes 集群认证的概述，请参见 [对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。有关对Kubernetes群集资源的访问鉴权的概述，请参见 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
 
 到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。
 
@@ -283,7 +283,7 @@ When started with these options, the Kubernetes apiserver will:
 1. Use them to authenticate to the extension apiserver.
 2. Create a configmap in the `kube-system` namespace called `extension-apiserver-authentication`, in which it will place the CA certificate and the allowed CNs. These in turn can be retrieved by extension apiservers to validate requests.
 
-Note that the same client certificate is used by the Kubernetes apiserver to authenticate against _all_ extension apiservers. It does not create a client certificate per extension apiserver, but rather a single one to authenticate as the Kubernetes apiserver. This same one is reused for all extension apiserver requests. 
+Note that the same client certificate is used by the Kubernetes apiserver to authenticate against _all_ extension apiservers. It does not create a client certificate per extension apiserver, but rather a single one to authenticate as the Kubernetes apiserver. This same one is reused for all extension apiserver requests.
 -->
 使用这些选项启动时，Kubernetes apiserver 将：
 
@@ -309,7 +309,7 @@ These header names are also placed in the `extension-apiserver-authentication` c
 当 Kubernetes apiserver 将请求代理到扩展 apiserver 时，它将向扩展 apiserver 通知原始请求已成功通过其验证的用户名和组。它在其代理请求的 http 标头中提供这些。您必须将要使用的标头名称告知 Kubernetes apiserver。
 
 * 通过`--requestheader-username-headers` 标明用来保存用户名的头部
-* 通过`--requestheader-group-headers` 标明用来保存 group 的头部 
+* 通过`--requestheader-group-headers` 标明用来保存 group 的头部
 * 通过`--requestheader-extra-headers-prefix` 标明用来保存拓展信息前缀的头部
 
 这些标头名称也放置在`extension-apiserver-authentication` 的 configmap 中，因此扩展 apiserver 可以检索和使用它们。
@@ -323,7 +323,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
     * Client CA certificate
     * List of allowed names (CNs)
     * Header names for username, group and extra info
-    
+
 2. Check that the TLS connection was authenticated using a client certificate which:
     * Was signed by the CA whose certificate matches the retrieved CA certificate.
     * Has a CN in the list of allowed CNs, unless the list is blank, in which case all CNs are allowed.
@@ -337,7 +337,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
     * 客户端 CA 证书
     * 允许名称（CN）列表
     * 用户名，组和其他信息的头部
-    
+
 2.使用以下证书检查 TLS 连接是否已通过认证：
     * 由其证书与检索到的 CA 证书匹配的 CA 签名。
     * 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
@@ -359,7 +359,7 @@ In order to have permission to retrieve the configmap, an extension apiserver re
 <!--
 ### Extension Apiserver Authorizes the Request
 
-The extension apiserver now can validate that the user/group retrieved from the headers are authorized to execute the given request. It does so by sending a standard [SubjectAccessReview](/docs/reference/access-authn-authz/authorization/) request to the Kubernetes apiserver. 
+The extension apiserver now can validate that the user/group retrieved from the headers are authorized to execute the given request. It does so by sending a standard [SubjectAccessReview](/docs/reference/access-authn-authz/authorization/) request to the Kubernetes apiserver.
 
 In order for the extension apiserver to be authorized itself to submit the `SubjectAccessReview` request to the Kubernetes apiserver, it needs the correct permissions. Kubernetes includes a default `ClusterRole` named `system:auth-delegator` that has the appropriate permissions. It can be granted to the extension apiserver's service account.
 -->
@@ -504,7 +504,7 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa
 path 配置是可选的，默认为`/`。
 
 下面是为可在端口 `1234` 上调用的扩展 apiserver 的配置示例
-服务位于子路径 `/my-path` 下，并针对 ServerName `my-service-name.my-service-namespace.svc` 
+服务位于子路径 `/my-path` 下，并针对 ServerName `my-service-name.my-service-namespace.svc`
 使用自定义的 CA 包来验证 TLS 连接
 使用自定义 CA 捆绑包的`my-service-name.my-service-namespace.svc`。
 
@@ -533,5 +533,3 @@ spec:
 * 使用聚合层[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)。
 * 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
 * 了解如何 [使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
-
-
diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
new file mode 100644
index 0000000000..aac5085ce7
--- /dev/null
+++ b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
@@ -0,0 +1,1840 @@
+---
+title: 使用 CustomResourceDefinition 扩展 Kubernetes API
+content_type: task
+min-kubernetes-server-version: 1.16
+weight: 20
+---
+<!--
+title: Extend the Kubernetes API with CustomResourceDefinitions
+reviewers:
+- deads2k
+- jpbetz
+- liggitt
+- roycaihw
+- sttts
+content_type: task
+min-kubernetes-server-version: 1.16
+weight: 20
+-->
+
+<!-- overview -->
+<!--
+This page shows how to install a
+[custom resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+into the Kubernetes API by creating a
+[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io).
+-->
+本页展示如何使用
+[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io)
+将
+[定制资源（Custom Resource）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+安装到 Kubernetes API 上。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!--
+If you are using an older version of Kubernetes that is still supported, switch to
+the documentation for that version to see advice that is relevant for your cluster.
+-->
+如果你在使用较老的、仍处于被支持范围的 Kubernetes 版本，请切换到该版本的
+文档查看对于的集群而言有用的建议。
+
+<!-- steps -->
+
+<!--
+## Create a CustomResourceDefinition
+
+When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server
+creates a new RESTful resource path for each version you specify. The CRD can be
+either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As
+with existing built-in objects, deleting a namespace deletes all custom objects
+in that namespace. CustomResourceDefinitions themselves are non-namespaced and
+are available to all namespaces.
+
+For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:
+-->
+## 创建 CustomResourceDefinition  {#create-a-customresourcedefinition}
+
+当你创建新的 CustomResourceDefinition（CRD）时，Kubernetes API 服务器会为你所
+指定的每一个版本生成一个 RESTful 的 资源路径。CRD 可以是名字空间作用域的，也可以
+是集群作用域的，取决于 CRD 的 `scope` 字段设置。和其他现有的内置对象一样，删除
+一个名字空间时，该名字空间下的所有定制对象也会被删除。CustomResourceDefinition
+本身是不受名字空间限制的，对所有名字空间可用。
+
+例如，如果你将下面的 CustomResourceDefinition 保存到 `resourcedefinition.yaml`
+文件：
+
+<!--
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  # name must match the spec fields below, and be in the form: <plural>.<group>
+  name: crontabs.stable.example.com
+spec:
+  # group name to use for REST API: /apis/<group>/<version>
+  group: stable.example.com
+  # list of versions supported by this CustomResourceDefinition
+  versions:
+    - name: v1
+      # Each version can be enabled/disabled by Served flag.
+      served: true
+      # One and only one version must be marked as the storage version.
+      storage: true
+      schema:
+        openAPIV3Schema:
+          type: object
+          properties:
+            spec:
+              type: object
+              properties:
+                cronSpec:
+                  type: string
+                image:
+                  type: string
+                replicas:
+                  type: integer
+  # either Namespaced or Cluster
+  scope: Namespaced
+  names:
+    # plural name to be used in the URL: /apis/<group>/<version>/<plural>
+    plural: crontabs
+    # singular name to be used as an alias on the CLI and for display
+    singular: crontab
+    # kind is normally the CamelCased singular type. Your resource manifests use this.
+    kind: CronTab
+    # shortNames allow shorter string to match your resource on the CLI
+    shortNames:
+    - ct
+```
+-->
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  # 名字必需与下面的 spec 字段匹配，并且格式为 '<名称的复数形式>.<组名>'
+  name: crontabs.stable.example.com
+spec:
+  # 组名称，用于 REST API: /apis/<组>/<版本>
+  group: stable.example.com
+  # 列举此 CustomResourceDefinition 所支持的版本
+  versions:
+    - name: v1
+      # 每个版本都可以通过 served 标志来独立启用或禁止
+      served: true
+      # 其中一个且只有一个版本必需被标记为存储版本
+      storage: true
+      schema:
+        openAPIV3Schema:
+          type: object
+          properties:
+            spec:
+              type: object
+              properties:
+                cronSpec:
+                  type: string
+                image:
+                  type: string
+                replicas:
+                  type: integer
+  # 可以是 Namespaced 或 Cluster
+  scope: Namespaced
+  names:
+    # 名称的复数形式，用于 URL：/apis/<组>/<版本>/<名称的复数形式>
+    plural: crontabs
+    # 名称的单数形式，作为命令行使用时和显示时的别名
+    singular: crontab
+    # kind 通常是单数形式的驼峰编码（CamelCased）形式。你的资源清单会使用这一形式。
+    kind: CronTab
+    # shortNames 允许你在命令行使用较短的字符串来匹配资源
+    shortNames:
+    - ct
+```
+
+<!--
+and create it:
+-->
+之后创建它：
+
+```shell
+kubectl apply -f resourcedefinition.yaml
+```
+
+<!--
+Then a new namespaced RESTful API endpoint is created at:
+-->
+这样一个新的受名字空间约束的 RESTful API 端点会被创建在：
+
+```
+/apis/stable.example.com/v1/namespaces/*/crontabs/...
+```
+
+<!--
+This endpoint URL can then be used to create and manage custom objects.
+The `kind` of these objects will be `CronTab` from the spec of the
+CustomResourceDefinition object you created above.
+
+It might take a few seconds for the endpoint to be created.
+You can watch the `Established` condition of your CustomResourceDefinition
+to be true or watch the discovery information of the API server for your
+resource to show up.
+-->
+此端点 URL 自此可以用来创建和管理定制对象。对象的 `kind` 将是来自你上面创建时
+所用的 spec 中指定的 `CronTab`。
+
+创建端点的操作可能需要几秒钟。你可以监测你的 CustomResourceDefinition 的
+`Established` 状况变为 true，或者监测 API 服务器的发现信息等待你的资源出现在
+那里。
+
+<!--
+## Create custom objects
+
+After the CustomResourceDefinition object has been created, you can create
+custom objects. Custom objects can contain custom fields. These fields can
+contain arbitrary JSON.
+In the following example, the `cronSpec` and `image` custom fields are set in a
+custom object of kind `CronTab`.  The kind `CronTab` comes from the spec of the
+CustomResourceDefinition object you created above.
+
+If you save the following YAML to `my-crontab.yaml`:
+-->
+## 创建定制对象   {#create-custom-objects}
+
+在创建了 CustomResourceDefinition 对象之后，你可以创建定制对象（Custom
+Objects）。定制对象可以包含定制字段。这些字段可以包含任意的 JSON 数据。
+在下面的例子中，在类别为 `CrontTab` 的定制对象中，设置了`cronSpec` 和 `image`
+定制字段。类别 `CronTab` 来自你在上面所创建的 CRD 的规约。
+
+如果你将下面的 YAML 保存到 `my-crontab.yaml`：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "* * * * */5"
+  image: my-awesome-cron-image
+```
+
+<!--
+and create it:
+-->
+并执行创建命令：
+
+```shell
+kubectl apply -f my-crontab.yaml
+```
+
+<!--
+You can then manage your CronTab objects using kubectl. For example:
+-->
+你就可以使用 kubectl 来管理你的 CronTab 对象了。例如：
+
+```shell
+kubectl get crontab
+```
+
+<!--
+Should print a list like this:
+-->
+应该会输出如下列表：
+
+```none
+NAME                 AGE
+my-new-cron-object   6s
+```
+
+<!--
+Resource names are not case-sensitive when using kubectl, and you can use either
+the singular or plural forms defined in the CRD, as well as any short names.
+
+You can also view the raw YAML data:
+-->
+使用 kubectl 时，资源名称是大小写不敏感的，而且你既可以使用 CRD 中所定义的单数
+形式或复数形式，也可以使用其短名称：
+
+```shell
+kubectl get ct -o yaml
+```
+
+<!--
+You should see that it contains the custom `cronSpec` and `image` fields
+from the YAML you used to create it:
+-->
+你可以看到输出中包含了你创建定制对象时在 YAML 文件中指定的定制字段 `cronSpec`
+和 `image`：
+
+```yaml
+apiVersion: v1
+kind: List
+items:
+- apiVersion: stable.example.com/v1
+  kind: CronTab
+  metadata:
+    creationTimestamp: 2017-05-31T12:56:35Z
+    generation: 1
+    name: my-new-cron-object
+    namespace: default
+    resourceVersion: "285"
+    uid: 9423255b-4600-11e7-af6a-28d2447dc82b
+  spec:
+    cronSpec: '* * * * */5'
+    image: my-awesome-cron-image
+metadata:
+  resourceVersion: ""
+```
+
+<!--
+## Delete a CustomResourceDefinition
+
+When you delete a CustomResourceDefinition, the server will uninstall the RESTful API endpoint
+and delete all custom objects stored in it.
+-->
+## 删除 CustomResourceDefinition    {#delete-a-customresourcedefinition}
+
+当你删除某 CustomResourceDefinition 时，服务器会卸载其 RESTful API
+端点，并删除服务器上存储的所有定制对象。
+
+```shell
+kubectl delete -f resourcedefinition.yaml
+kubectl get crontabs
+```
+
+```none
+Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com)
+```
+
+<!--
+If you later recreate the same CustomResourceDefinition, it will start out empty.
+-->
+如果你在以后创建相同的 CustomResourceDefinition 时，该 CRD 会一个空的结构。
+
+<!--
+## Specifying a structural schema
+
+CustomResources store structured data in custom fiels (alongside the built-in
+fields `apiVersion`, `kind` and `metadata`, which the API server validates
+implicitly). With [OpenAPI v3.0 validation](#validation) a schema can be
+specified, which is validated during creation and updates, compare below for
+details and limits of such a schema.
+
+With `apiextensions.k8s.io/v1` the definition of a structural schema is
+mandatory for CustomResourceDefinitions. In the beta version of
+CustomResourceDefinition, structural schemas were optional.
+-->
+## 设置结构化的模式   {#specifying-a-structural-schema}
+
+CustomResource 对象在定制字段中保存结构化的数据，这些字段和内置的字段
+`apiVersion`、`kind` 和 `metadata` 等一起存储，不过内置的字段都会被 API
+服务器隐式完成合法性检查。有了 [OpenAPI v3.0 检查](#validation)
+能力之后，你可以设置一个模式（Schema），在创建和更新定制对象时，这一模式会被用来
+对对象内容进行合法性检查。参阅下文了解这类模式的细节和局限性。
+
+在 `apiextensions.k8s.io/v1` 版本中，CustomResourceDefinition 的这一结构化模式
+定义是必需的。
+在 CustomResourceDefinition 的 beta 版本中，结构化模式定义是可选的。
+
+<!--
+A structural schema is an [OpenAPI v3.0 validation schema](#validation) which:
+
+1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of:
+   * a node with `x-kubernetes-int-or-string: true`
+   * a node with `x-kubernetes-preserve-unknown-fields: true`
+2. for each field in an object and each item in an array which is specified within any of `allOf`, `anyOf`, `oneOf` or `not`, the schema also specifies the field/item outside of those logical junctors (compare example 1 and 2).
+3. does not set `description`, `type`, `default`, `additionalProperties`, `nullable` within an `allOf`, `anyOf`, `oneOf` or `not`, with the exception of the two pattern for `x-kubernetes-int-or-string: true` (see below).
+4. if `metadata` is specified, then only restrictions on `metadata.name` and `metadata.generateName` are allowed.
+-->
+结构化模式本身是一个 [OpenAPI v3.0 验证模式](#validation)，其中：
+
+1. 为对象根（root）设置一个非空的 type 值（藉由 OpenAPI 中的 `type`），对每个
+   object 节点的每个字段（藉由 OpenAPI 中的 `properties` 或 `additionalProperties`）以及
+   array 节点的每个条目（藉由 OpenAPI 中的 `items`）也要设置非空的 type 值，
+   除非：
+   * 节点包含属性 `x-kubernetes-int-or-string: true`
+   * 节点包含属性 `x-kubernetes-preserve-unknown-fields: true`
+2. 对于 object 的每个字段或 array 中的每个条目，如果其定义中包含 `allOf`、`anyOf`、`oneOf`
+   或 `not`，则模式也要指定这些逻辑组合之外的字段或条目（试比较例 1 和例 2)。
+3. 在 `allOf`、`anyOf`、`oneOf` 或 `not` 上下文内不设置 `description`、`type`、`default`、
+   `additionalProperties` 或者 `nullable`。此规则的例外是
+   `x-kubernetes-int-or-string` 的两种模式（见下文）。
+4. 如果 `metadata` 被设置，则只允许对 `metadata.name` 和 `metadata.generateName` 设置约束。
+
+<!--
+Non-structural example 1:
+-->
+非结构化的例 1:
+
+```yaml
+allOf:
+- properties:
+    foo:
+      ...
+```
+
+<!--
+conflicts with rule 2. The following would be correct:
+-->
+违反了第 2 条规则。下面的是正确的：
+
+```yaml
+properties:
+  foo:
+    ...
+allOf:
+- properties:
+    foo:
+      ...
+```
+
+<!--
+Non-structural example 2:
+-->
+非结构化的例 2：
+
+```yaml
+allOf:
+- items:
+    properties:
+      foo:
+        ...
+```
+
+<!--
+conflicts with rule 2. The following would be correct:
+-->
+违反了第 2 条规则。下面的是正确的：
+
+```yaml
+items:
+  properties:
+    foo:
+      ...
+allOf:
+- items:
+    properties:
+      foo:
+        ...
+```
+
+<!--
+Non-structural example 3:
+-->
+非结构化的例 3：
+
+```yaml
+properties:
+  foo:
+    pattern: "abc"
+  metadata:
+    type: object
+    properties:
+      name:
+        type: string
+        pattern: "^a"
+      finalizers:
+        type: array
+        items:
+          type: string
+          pattern: "my-finalizer"
+anyOf:
+- properties:
+    bar:
+      type: integer
+      minimum: 42
+  required: ["bar"]
+  description: "foo bar object"
+```
+
+<!--
+is not a structural schema because of the following violations:
+
+* the type at the root is missing (rule 1).
+* the type of `foo` is missing (rule 1).
+* `bar` inside of `anyOf` is not specified outside (rule 2).
+* `bar`'s `type` is within `anyOf` (rule 3).
+* the description is set within `anyOf` (rule 3).
+* `metadata.finalizers` might not be restricted (rule 4).
+-->
+不是一个结构化的模式，因为其中存在以下违例：
+
+* 根节点缺失 type 设置（规则 1）
+* `foo` 的 type 缺失（规则 1）
+* `anyOf` 中的 `bar` 未在外部指定（规则 2）
+* `bar` 的 `type` 位于 `anyOf` 中（规则 3）
+* `anyOf` 中设置了 `description` （规则 3）
+* `metadata.finalizers` 不可以被限制 (规则 4）
+
+<!--
+In contrast, the following, corresponding schema is structural:
+-->
+作为对比，下面的 YAML 所对应的模式则是结构化的：
+
+```yaml
+type: object
+description: "foo bar object"
+properties:
+  foo:
+    type: string
+    pattern: "abc"
+  bar:
+    type: integer
+  metadata:
+    type: object
+    properties:
+      name:
+        type: string
+        pattern: "^a"
+anyOf:
+- properties:
+    bar:
+      minimum: 42
+  required: ["bar"]
+```
+
+<!--
+Violations of the structural schema rules are reported in the `NonStructural` condition in the CustomResourceDefinition.
+-->
+如果违反了结构化模式规则，CustomResourceDefinition 的 `NonStructural` 状况中
+会包含报告信息。
+
+<!--
+### Field pruning
+
+CustomResourceDefinitions store validated resource data in the cluster's persistence store, {{< glossary_tooltip term_id="etcd" text="etcd">}}. As with native Kubernetes resources such as {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, if you specify a field that the API server does not recognize, the unknown field  is _pruned_ (removed) before being persisted.
+-->
+### 字段剪裁     {#field-pruning}
+
+CustomResourceDefinition 在集群的持久性存储
+{{< glossary_tooltip term_id="etcd" text="etcd">}}
+中保存经过合法性检查的资源数据。
+就像原生的 Kubernetes 资源，例如 {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}，
+如果你指定了 API 服务器所无法识别的字段，则该未知字段会在保存资源之前
+被 _剪裁（Pruned）_ 掉（删除）。
+
+<!--
+CRDs converted from `apiextensions.k8s.io/v1beta1` to
+`apiextensions.k8s.io/v1` might lack structural schemas, and
+`spec.preserveUnknownFields` might be `true`.
+
+For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is
+set, pruning is _not_ enabled and you can store arbitrary data. For best
+compatibility, you should update your custom resources to meet an OpenAPI schema,
+and you should set `spec.preserveUnknownFields` true for the
+CustomResourceDefinition itself.
+-->
+{{< note >}}
+从 `apiextensions.k8s.io/v1beta1` 转换到 `apiextensions.k8s.io/v1` 的 CRD
+可能没有结构化的模式定义，因此其 `spec.preserveUnknownFields` 可能为 `true`。
+
+对于迁移而来的 CustomResourceDefinition，如果其 `spec.preserveUnknownFields`
+被设置为 `true`，则 Kubernetes _不会_ 执行剪裁操作，你可以存储任意数据。
+要实现最佳的兼容性，你应该更新定制资源以满足某 OpenAPI 模式定义，并且你
+应该将 CustomResourceDefinition 自身的 `spec.preserveUnknownFields` 设置为
+`true`。
+{{< /note >}}
+
+<!--
+If you save the following YAML to `my-crontab.yaml`:
+-->
+如果你将下面的 YAML 保存到 `my-crontab.yaml` 文件：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "* * * * */5"
+  image: my-awesome-cron-image
+  someRandomField: 42
+```
+
+<!--
+and create it:
+-->
+并创建之：
+
+```shell
+kubectl create --validate=false -f my-crontab.yaml -o yaml
+```
+
+<!--
+your output is similar to:
+-->
+输出类似于：
+
+```console
+apiVersion: stable.example.com/v1
+kind: CronTab
+metadata:
+  creationTimestamp: 2017-05-31T12:56:35Z
+  generation: 1
+  name: my-new-cron-object
+  namespace: default
+  resourceVersion: "285"
+  uid: 9423255b-4600-11e7-af6a-28d2447dc82b
+spec:
+  cronSpec: '* * * * */5'
+  image: my-awesome-cron-image
+```
+
+<!--
+Notice that the field `someRandomField` was pruned.
+-->
+注意其中的字段 `someRandomField` 已经被剪裁掉。
+
+<!--
+This example turned off client-side validation to demonstrate the API server's behavior, by adding the `--validate=false` command line option.
+Because the [OpenAPI validation schemas are also published](#publish-validation-schema-in-openapi-v2)
+to clients, `kubectl` also checks for unknown fields and rejects those objects well before they would be sent to the API server.
+-->
+本例中通过 `--validate=false` 命令行选项 关闭了客户端的合法性检查以展示 API 服务器的行为，
+因为 [OpenAPI 合法性检查模式也会发布到](#publish-validation-schema-in-openapi-v2)
+客户端，`kubectl` 也会检查未知的字段并在对象被发送到 API
+服务器之前就拒绝它们。
+
+<!--
+#### Controlling pruning
+
+By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to opt-out of that for specifc sub-trees fof fields by adding `x-kubernetes-preserve-unknown-fields: true` in the [structural OpenAPI v3 validation schema](#specifying-a-structural-schema).
+For example:
+-->
+#### 控制剪裁   {#controlling-pruning}
+
+默认情况下，定制资源的所有版本中的所有未规定的字段都会被剪裁掉。
+通过在结构化的 OpenAPI v3 [检查模式定义](#specifying-a-structural-schema)
+中为特定字段的子树添加 `x-kubernetes-preserve-unknown-fields: true` 属性，可以
+选择不对其执行剪裁操作。
+例如：
+
+```yaml
+type: object
+properties:
+  json:
+    x-kubernetes-preserve-unknown-fields: true
+```
+
+<!--
+The field `json` can store any JSON value, without anything being pruned.
+
+You can also partially specify the permitted JSON; for example:
+-->
+字段 `json` 可以保存任何 JSON 值，其中内容不会被剪裁掉。
+
+你也可以部分地指定允许的 JSON 数据格式；例如：
+
+```yaml
+type: object
+properties:
+  json:
+    x-kubernetes-preserve-unknown-fields: true
+    type: object
+    description: this is arbitrary JSON
+```
+
+<!--
+With this, only `object` type values are allowed.
+
+Pruning is enabled again for each specified property (or `additionalProperties`):
+-->
+通过这样设置，JSON 中只能设置 `object` 类型的值。
+
+对于所指定的每个属性（或 `additionalProperties`），剪裁会再次被启用。
+
+```yaml
+type: object
+properties:
+  json:
+    x-kubernetes-preserve-unknown-fields: true
+    type: object
+    properties:
+      spec:
+        type: object
+        properties:
+          foo:
+            type: string
+          bar:
+            type: string
+```
+
+<!--
+With this, the value:
+-->
+对于上述定义，如果提供的数值如下：
+
+```yaml
+json:
+  spec:
+    foo: abc
+    bar: def
+    something: x
+  status:
+    something: x
+```
+
+<!--
+is pruned to:
+-->
+则该值会被剪裁为：
+
+```yaml
+json:
+  spec:
+    foo: abc
+    bar: def
+  status:
+    something: x
+```
+
+<!--
+This means that the `something` field in the specified `spec` object is pruned, but everything outside is not.
+-->
+这意味着所指定的 `spec` 对象中的 `something` 字段被剪裁掉，而其外部的内容都被保留。
+
+<!--
+### IntOrString
+
+Nodes in a schema with `x-kubernetes-int-or-string: true` are excluded from rule 1, such that the following is structural:
+-->
+### IntOrString
+
+模式定义中标记了 `x-kubernetes-int-or-string: true` 的节点不受前述规则 1
+约束，因此下面的定义是结构化的模式：
+
+```yaml
+type: object
+properties:
+  foo:
+    x-kubernetes-int-or-string: true
+```
+
+<!--
+Also those nodes are partially excluded from rule 3 in the sense that the
+following two patterns are allowed (exactly those, without variations in order
+to additional fields):
+-->
+此外，所有这类节点也不再受规则 3 约束，也就是说，下面两种模式是被允许的
+（注意，仅限于这两种模式，不支持添加新字段的任何其他变种）：
+
+```yaml
+x-kubernetes-int-or-string: true
+anyOf:
+- type: integer
+- type: string
+...
+```
+
+和
+
+```yaml
+x-kubernetes-int-or-string: true
+allOf:
+- anyOf:
+  - type: integer
+  - type: string
+- ... # zero or more
+...
+```
+
+<!--
+With one of those specification, both an integer and a string validate.
+
+In [Validation Schema Publishing](#publish-validation-schema-in-openapi-v2),
+`x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
+-->
+在以上两种规约中，整数值和字符串值都会被认为是合法的。
+
+在[合法性检查模式定义的发布时](#publish-validation-schema-in-openapi-v2)，
+`x-kubernetes-int-or-string: true` 会被展开为上述两种模式之一。
+
+### RawExtension
+
+<!--
+RawExtensions (as in `runtime.RawExtension` defined in
+[k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94))
+holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.
+
+It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example:
+-->
+RawExtensions（就像在
+[k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)
+项目中 `runtime.RawExtension` 所定义的那样）
+可以保存完整的 Kubernetes 对象，也就是，其中会包含 `apiVersion` 和 `kind`
+字段。
+
+通过 `x-kubernetes-embedded-resource: true` 来设定这些嵌套对象的规约（无论是
+完全无限制还是部分指定都可以）是可能的。例如：
+
+```yaml
+type: object
+properties:
+  foo:
+    x-kubernetes-embedded-resource: true
+    x-kubernetes-preserve-unknown-fields: true
+```
+
+<!--
+Here, the field `foo` holds a complete object, e.g.:
+-->
+这里，字段 `foo` 包含一个完整的对象，例如：
+
+```yaml
+foo:
+  apiVersion: v1
+  kind: Pod
+  spec:
+    ...
+```
+
+<!--
+Because `x-kubernetes-preserve-unknown-fields: true` is specified alongside,
+nothing is pruned. The use of `x-kubernetes-preserve-unknown-fields: true` is
+optional though.
+
+With `x-kubernetes-embedded-resource: true`, the `apiVersion`, `kind` and `metadata` are implicitly specified and validated.
+-->
+由于字段上设置了 `x-kubernetes-preserve-unknown-fields: true`，其中的内容不会
+被剪裁。不过，在这个语境中，`x-kubernetes-preserve-unknown-fields: true` 的
+使用是可选的。
+
+设置了 `x-kubernetes-embedded-resource: true` 之后，`apiVersion`、`kind` 和
+`metadata` 都是隐式设定并隐式完成合法性验证。
+
+<!--
+## Serving multiple versions of a CRD
+
+See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
+for more information about serving multiple versions of your
+CustomResourceDefinition and migrating your objects from one version to another.
+-->
+## 提供 CRD 的多个版本   {#serving-multiple-versions-of-a-crd}
+
+关于如何为你的 CustomResourceDefinition 提供多个版本的支持，以及如何将你的对象
+从一个版本迁移到另一个版本， 详细信息可参阅
+[定制资源定义的版本](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。
+
+<!-- discussion -->
+
+<!--
+## Advanced topics
+
+### Finalizers
+-->
+## 高级主题     {#advanced-topics}
+
+### Finalizers
+
+<!--
+*Finalizers* allow controllers to implement asynchronous pre-delete hooks.
+Custom objects support finalizers just like built-in objects.
+
+You can add a finalizer to a custom object like this:
+-->
+*Finalizer* 能够让控制器实现异步的删除前（Pre-delete）回调。
+定制对象和内置对象一样支持 Finalizer。
+
+你可以像下面一样为定制对象添加 Finalizer：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  finalizers:
+  - stable.example.com/finalizer
+```
+
+<!--
+Identifiers of custom finalizers consist of a domain name, a forward slash and the name of
+the finalizer. Any controller can add a finalizer to any object's list of finalizers.
+
+The first delete request on an object with finalizers sets a value for the
+`metadata.deletionTimestamp` field but does not delete it. Once this value is set,
+entries in the `finalizers` list can only be removed. While any finalizers remain it is also
+impossible to force the deletion of an object.
+
+When the `metadata.deletionTimestamp` field is set, controllers watching the object execute any
+finalizers they handle and remove the finalizer from the list after they are done. It is the
+responsibility of each controller to remove its finalizer from the list.
+-->
+自定义 Finalizer 的标识符包含一个域名、一个正向斜线和 finalizer 的名称。
+任何控制器都可以在任何对象的 finalizer 列表中添加新的 finalizer。
+
+对带有 Finalizer 的对象的第一个删除请求会为其 `metadata.deletionTimestamp`
+设置一个值，但不会真的删除对象。一旦此值被设置，`finalizers` 列表中的表项
+只能被移除。在列表中仍然包含 finalizer 时，无法强制删除对应的对象。
+
+当 `metadata.deletionTimestamp` 字段被设置时，监视该对象的各个控制器会
+执行它们所能处理的 finalizer，并在完成处理之后将其从列表中移除。
+每个控制器负责将其 finalizer 从列表中删除。
+
+<!--
+The value of `metadata.deletionGracePeriodSeconds` controls the interval between polling updates.
+
+Once the list of finalizers is empty, meaning all finalizers have been executed, the resource is
+deleted by Kubernetes.
+-->
+`metadata.deletionGracePeriodSeconds` 的取值控制对更新的轮询周期。
+
+一旦 finalizers 列表为空时，就意味着所有 finalizer 都被执行过，
+Kubernetes 会最终删除该资源，
+
+<!--
+### Validation
+
+Custom resources are validated via
+[OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject)
+and you can add additional validation using
+[admission webhooks](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook).
+-->
+### 合法性检查    {#validation}
+
+定制资源是通过
+[OpenAPI v3 模式定义](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject)
+来执行合法性检查的，
+你可以通过使用[准入控制 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
+来添加额外的合法性检查逻辑。
+
+<!--
+Additionally, the following restrictions are applied to the schema:
+
+- These fields cannot be set:
+  - `definitions`,
+  - `dependencies`,
+  - `deprecated`,
+  - `discriminator`,
+  - `id`,
+  - `patternProperties`,
+  - `readOnly`,
+  - `writeOnly`,
+  - `xml`,
+  - `$ref`.
+- The field `uniqueItems` cannot be set to `true`.
+- The field `additionalProperties` cannot be set to `false`.
+- The field `additionalProperties` is mutually exclusive with `properties`.
+-->
+此外，对模式定义存在以下限制：
+
+- 以下字段不可设置：
+  - `definitions`
+  - `dependencies`
+  - `deprecated`
+  - `discriminator`
+  - `id`
+  - `patternProperties`
+  - `readOnly`
+  - `writeOnly`
+  - `xml`
+  - `$ref`
+- 字段 `uniqueItems` 不可设置为 `true`
+- 字段 `additionalProperties` 不可设置为 `false`
+- 字段 `additionalProperties` 与 `properties` 互斥，不可同时使用
+
+<!--
+The `default` field can be set when the [Defaulting feature](#defaulting) is enabled,
+which is the case with `apiextensions.k8s.io/v1` CustomResourceDefinitions. 
+Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+enabled, which is the case automatically for many clusters for beta features).
+-->
+
+当[设置默认值特性](#defaulting)被启用时，可以设置字段 `default`。
+就 `apiextensions.k8s.io/v1` 组的 CustomResourceDefinitions，这一条件是满足的。
+设置默认值的功能特性从 1.17 开始正式发布。该特性在 1.16 版本中处于
+Beta 状态，要求 `CustomResourceDefaulting`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+被启用。对于大多数集群而言，Beta 状态的特性门控默认都是自动启用的。
+
+<!--
+Refer to the [structural schemas](#specifying-a-structural-schema) section for other
+restrictions and CustomResourceDefinition features.
+-->
+关于对某些 CustomResourceDefinition 特性所必需的限制，可参见
+[结构化的模式定义](#specifying-a-structural-schema)小节。
+
+<!--
+The schema is defined in the CustomResourceDefinition. In the following example, the
+CustomResourceDefinition applies the following validations on the custom object:
+
+- `spec.cronSpec` must be a string and must be of the form described by the regular expression.
+- `spec.replicas` must be an integer and must have a minimum value of 1 and a maximum value of 10.
+
+Save the CustomResourceDefinition to `resourcedefinition.yaml`:
+-->
+模式定义是在 CustomResourceDefinition 中设置的。在下面的例子中，
+CustomResourceDefinition 对定制对象执行以下合法性检查：
+
+- `spec.cronSpec` 必须是一个字符串，必须是正则表达式所描述的形式；
+- `spec.replicas` 必须是一个整数，且其最小值为 1、最大值为 10。
+
+将此 CustomResourceDefinition 保存到 `resourcedefinition.yaml` 文件中：
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: crontabs.stable.example.com
+spec:
+  group: stable.example.com
+  versions:
+    - name: v1
+      served: true
+      storage: true
+      schema:
+        # openAPIV3Schema is the schema for validating custom objects.
+        openAPIV3Schema:
+          type: object
+          properties:
+            spec:
+              type: object
+              properties:
+                cronSpec:
+                  type: string
+                  pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
+                image:
+                  type: string
+                replicas:
+                  type: integer
+                  minimum: 1
+                  maximum: 10
+  scope: Namespaced
+  names:
+    plural: crontabs
+    singular: crontab
+    kind: CronTab
+    shortNames:
+    - ct
+```
+
+<!--
+and create it:
+-->
+并创建 CustomResourceDefinition：
+
+```shell
+kubectl apply -f resourcedefinition.yaml
+```
+
+<!--
+A request to create a custom object of kind CronTab is rejected if there are invalid values in its fields.
+In the following example, the custom object contains fields with invalid values:
+
+- `spec.cronSpec` does not match the regular expression.
+- `spec.replicas` is greater than 10.
+
+If you save the following YAML to `my-crontab.yaml`:
+-->
+对于一个创建 CronTab 类别对象的定制对象的请求而言，如果其字段中包含非法值，则
+该请求会被拒绝。
+在下面的例子中，定制对象中包含带非法值的字段：
+
+- `spec.cronSpec` 与正则表达式不匹配
+- `spec.replicas` 数值大于 10。
+
+如果你将下面的 YAML 保存到 `my-crontab.yaml`：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "* * * *"
+  image: my-awesome-cron-image
+  replicas: 15
+```
+
+<!--
+and attempt to create it:
+-->
+并尝试创建定制对象：
+
+```shell
+kubectl apply -f my-crontab.yaml
+```
+
+<!--
+then you get an error:
+-->
+你会看到下面的错误信息：
+
+```console
+The CronTab "my-new-cron-object" is invalid: []: Invalid value: map[string]interface {}{"apiVersion":"stable.example.com/v1", "kind":"CronTab", "metadata":map[string]interface {}{"name":"my-new-cron-object", "namespace":"default", "deletionTimestamp":interface {}(nil), "deletionGracePeriodSeconds":(*int64)(nil), "creationTimestamp":"2017-09-05T05:20:07Z", "uid":"e14d79e7-91f9-11e7-a598-f0761cb232d1", "clusterName":""}, "spec":map[string]interface {}{"cronSpec":"* * * *", "image":"my-awesome-cron-image", "replicas":15}}:
+validation failure list:
+spec.cronSpec in body should match '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
+spec.replicas in body should be less than or equal to 10
+```
+
+<!--
+If the fields contain valid values, the object creation request is accepted.
+
+Save the following YAML to `my-crontab.yaml`:
+-->
+如果所有字段都包含合法值，则对象创建的请求会被接受。
+
+将下面的 YAML 保存到 `my-crontab.yaml` 文件：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "* * * * */5"
+  image: my-awesome-cron-image
+  replicas: 5
+```
+
+<!--
+And create it:
+-->
+并创建定制对象：
+
+```shell
+kubectl apply -f my-crontab.yaml
+crontab "my-new-cron-object" created
+```
+
+<!--
+### Defaulting
+-->
+### 设置默认值   {#efaulting}
+
+<!--
+To use defaulting, your CustomResourceDefinition must use API version `apiextensions.k8s.io/v1`.
+-->
+{{< note >}}
+要使用设置默认值功能，你的 CustomResourceDefinition 必须使用 API 版本 `apiextensions.k8s.io/v1`。
+{{< /note >}}
+
+<!--
+Defaulting allows to specify default values in the [OpenAPI v3 validation schema](#validation):
+-->
+设置默认值的功能允许在 [OpenAPI v3 合法性检查模式定义](#validation)中设置默认值：
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: crontabs.stable.example.com
+spec:
+  group: stable.example.com
+  versions:
+    - name: v1
+      served: true
+      storage: true
+      schema:
+        # openAPIV3Schema 是用来检查定制对象的模式定义
+        openAPIV3Schema:
+          type: object
+          properties:
+            spec:
+              type: object
+              properties:
+                cronSpec:
+                  type: string
+                  pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
+                  default: "5 0 * * *"
+                image:
+                  type: string
+                replicas:
+                  type: integer
+                  minimum: 1
+                  maximum: 10
+                  default: 1
+  scope: Namespaced
+  names:
+    plural: crontabs
+    singular: crontab
+    kind: CronTab
+    shortNames:
+    - ct
+```
+
+<!--
+With this both `cronSpec` and `replicas` are defaulted:
+-->
+使用此 CRD 定义时，`cronSpec` 和 `replicas` 都会被设置默认值：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  image: my-awesome-cron-image
+```
+
+<!--
+leads to
+-->
+会生成：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "5 0 * * *"
+  image: my-awesome-cron-image
+  replicas: 1
+```
+
+<!--
+Defaulting happens on the object
+
+* in the request to the API server using the request version defaults,
+* when reading from etcd using the storage version defaults,
+* after mutating admission plugins with non-empty patches using the admission webhook object version defaults.
+
+Defaults applied when reading data from etcd are not automatically written back to etcd. An update request via the API is required to persist those defaults back into etcd.
+-->
+默认值设定的行为发生在定制对象上：
+
+* 在向 API 服务器发送的请求中，基于请求版本的设定设置默认值；
+* 在从 etcd 读取对象时，使用存储版本来设置默认值；
+* 在 Mutating 准入控制插件执行非空的补丁操作时，基于准入 Webhook 对象
+  版本设置默认值。
+
+从 etcd 中读取数据时所应用的默认值设置不会被写回到 etcd 中。
+需要通过 API 执行更新请求才能将这种方式设置的默认值写回到 etcd。
+
+<!--
+Default values must be pruned (with the exception of defaults for `metadata` fields) and must validate against a provided schema.
+
+Default values for `metadata` fields of `x-kubernetes-embedded-resources: true` nodes (or parts of a default value covering `metadata`) are not pruned during CustomResourceDefinition creation, but through the pruning step during handling of requests.
+-->
+默认值一定会被剪裁（除了 `metadata` 字段的默认值设置），且必须通过所提供
+的模式定义的检查。
+
+针对 `x-kubernetes-embedded-resource: true` 节点（或者包含 `metadata` 字段的结构的默认值）
+的 `metadata` 字段的默认值设置不会在 CustomResourceDefinition 创建时被剪裁，
+而是在处理请求的字段剪裁阶段被删除。
+
+<!--
+### Publish Validation Schema in OpenAPI v2
+
+CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server.
+
+The [kubectl](/docs/reference/kubectl/overview) command-line tool consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation.
+-->
+### 以 OpenAPI v2 形式发布合法性检查模式      {#publish-validation-schema-in-openapi-v2}
+
+CustomResourceDefinition 的[结构化的](#specifying-a-structural-schema)、
+[启用了剪裁的](#preserving-unknown-fields) [OpenAPI v3 合法性检查模式](#validation)
+会在 Kubernetes API 服务器上作为
+[OpenAPI v2 规约](/zh/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions)
+的一部分发布出来。
+
+[kubectl](/zh/docs/reference/kubectl/overview) 命令行工具会基于所发布的模式定义来执行
+客户端的合法性检查（`kubectl create` 和 `kubectl apply`），为定制资源的模式定义
+提供解释（`kubectl explain`）。
+所发布的模式还可被用于其他目的，例如生成客户端或者生成文档。
+
+<!--
+The OpenAPI v3 validation schema is converted to OpenAPI v2 schema, and
+show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions).
+
+The following modifications are applied during the conversion to keep backwards compatibility with
+kubectl in previous 1.13 version. These modifications prevent kubectl from being over-strict and rejecting
+valid OpenAPI schemas that it doesn't understand. The conversion won't modify the validation schema defined in CRD,
+and therefore won't affect [validation](#validation) in the API server.
+-->
+OpenAPI v3 合法性检查模式定义会被转换为 OpenAPI v2 模式定义，并出现在
+[OpenAPI v2 规范](/zh/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions)
+的 `definitions` 和 `paths` 字段中。
+
+在转换过程中会发生以下修改，目的是保持与 1.13 版本以前的 kubectl 工具兼容。
+这些修改可以避免 kubectl 过于严格，以至于拒绝它无法理解的 OpenAPI 模式定义。
+转换过程不会更改 CRD 中定义的合法性检查模式定义，因此不会影响到 API 服务器中
+的[合法性检查](#validation)。
+
+<!--
+1. The following fields are removed as they aren't supported by OpenAPI v2 (in future versions OpenAPI v3 will be used without these restrictions)
+   - The fields `allOf`, `anyOf`, `oneOf` and `not` are removed
+2. If `nullable: true` is set, we drop `type`, `nullable`, `items` and `properties` because OpenAPI v2 is not able to express nullable. To avoid kubectl to reject good objects, this is necessary.
+-->
+1. 以下字段会被移除，因为它们在 OpenAPI v2 中不支持（在将来版本中将使用 OpenAPI v3，
+   因而不会有这些限制）
+   - 字段 `allOf`、`anyOf`、`oneOf` 和 `not` 会被删除
+2. 如果设置了 `nullable: true`，我们会丢弃 `type`、`nullable`、`items` 和 `properties`
+   OpenAPI v2 无法表达 Nullable。为了避免 kubectl 拒绝正常的对象，这一转换是必要的。
+
+<!--
+### Additional printer columns
+
+The kubectl tool relies on server-side output formatting. Your cluster's API server decides which
+columns are shown by the `kubectl get` command. You can customize these columns for a
+CustomResourceDefinition. The following example adds the `Spec`, `Replicas`, and `Age`
+columns.
+
+Save the CustomResourceDefinition to `resourcedefinition.yaml`:
+-->
+### 额外的打印列    {#additional-printer-columns}
+
+`kubectl` 工具依赖服务器端的输出格式化。你的集群的 API 服务器决定 `kubectl
+get` 命令要显示的列有哪些。
+你可以为 CustomResourceDefinition 定制这些要打印的列。
+下面的例子添加了 `Spec`、`Replicas` 和 `Age` 列：
+
+将此 CustomResourceDefinition 保存到 `resourcedefinition.yaml` 文件：
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: crontabs.stable.example.com
+spec:
+  group: stable.example.com
+  scope: Namespaced
+  names:
+    plural: crontabs
+    singular: crontab
+    kind: CronTab
+    shortNames:
+    - ct
+  versions:
+  - name: v1
+    served: true
+    storage: true
+    schema:
+      openAPIV3Schema:
+        type: object
+        properties:
+          spec:
+            type: object
+            properties:
+              cronSpec:
+                type: string
+              image:
+                type: string
+              replicas:
+                type: integer
+    additionalPrinterColumns:
+    - name: Spec
+      type: string
+      description: The cron spec defining the interval a CronJob is run
+      jsonPath: .spec.cronSpec
+    - name: Replicas
+      type: integer
+      description: The number of jobs launched by the CronJob
+      jsonPath: .spec.replicas
+    - name: Age
+      type: date
+      jsonPath: .metadata.creationTimestamp
+```
+
+<!--
+Create the CustomResourceDefinition:
+-->
+创建 CustomResourceDefinition：
+
+```shell
+kubectl apply -f resourcedefinition.yaml
+```
+
+<!--
+Create an instance using the `my-crontab.yaml` from the previous section.
+-->
+使用前文中的 `my-crontab.yaml` 创建一个实例。
+
+<!--
+Invoke the server-side printing:
+-->
+启用服务器端打印输出：
+
+```shell
+kubectl get crontab my-new-cron-object
+```
+
+<!--
+Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output:
+-->
+注意输出中的 `NAME`、`SPEC`、`REPLICAS` 和 `AGE` 列：
+
+```
+NAME                 SPEC        REPLICAS   AGE
+my-new-cron-object   * * * * *   1          7s
+```
+
+<!--
+The `NAME` column is implicit and does not need to be defined in the CustomResourceDefinition.
+-->
+{{< note >}}
+`NAME` 列是隐含的，不需要在 CustomResourceDefinition 中定义。
+{{< /note >}}
+
+<!--
+#### Priority
+
+Each column includes a `priority` field. Currently, the priority
+differentiates between columns shown in standard view or wide view (using the `-o wide` flag).
+
+- Columns with priority `0` are shown in standard view.
+- Columns with priority greater than `0` are shown only in wide view.
+-->
+#### 优先级    {#priority}
+
+每个列都包含一个 `priority`（优先级）字段。当前，优先级用来区分标准视图（Standard
+View）和宽视图（Wide View）（使用 `-o wide` 标志）中显示的列：
+
+- 优先级为 `0` 的列会在标准视图中显示。
+- 优先级大于 `0` 的列只会在宽视图中显示。
+
+<!--
+#### Type
+
+A column's `type` field can be any of the following (compare [OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)):
+
+- `integer` – non-floating-point numbers
+- `number` – floating point numbers
+- `string` – strings
+- `boolean` – `true` or `false`
+- `date` – rendered differentially as time since this timestamp.
+-->
+#### 类型    {#type}
+
+列的 `type` 字段可以是以下值之一
+（比较 [OpenAPI v3 数据类型](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)）：
+
+- `integer` – 非浮点数字
+- `number` – 浮点数字
+- `string` – 字符串
+- `boolean` – `true` 或 `false`
+- `date` – 显示为以自此时间戳以来经过的时长
+
+<!--
+If the value inside a CustomResource does not match the type specified for the column,
+the value is omitted. Use CustomResource validation to ensure that the value
+types are correct.
+-->
+如果定制资源中的值与列中指定的类型不匹配，该值会被忽略。
+你可以通过定制资源的合法性检查来确保取值类型是正确的。
+
+<!--
+#### Format
+
+A column's `format` field can be any of the following:
+-->
+#### 格式    {#format}
+
+列的 `format` 字段可以是以下值之一：
+
+- `int32`
+- `int64`
+- `float`
+- `double`
+- `byte`
+- `date`
+- `date-time`
+- `password`
+
+<!--
+The column's `format` controls the style used when `kubectl` prints the value.
+-->
+列的 `format` 字段控制 `kubectl` 打印对应取值时采用的风格。
+
+<!--
+### Subresources
+
+Custom resources support `/status` and `/scale` subresources.
+
+The status and scale subresources can be optionally enabled by
+defining them in the CustomResourceDefinition.
+-->
+### 子资源     {#subresources}
+
+定制资源支持 `/status` 和 `/scale` 子资源。
+
+通过在 CustomResourceDefinition 中定义 `status` 和 `scale`，
+可以有选择地启用这些子资源。
+
+<!--
+#### Status subresource
+
+When the status subresource is enabled, the `/status` subresource for the custom resource is exposed.
+
+- The status and the spec stanzas are represented by the `.status` and `.spec` JSONPaths respectively inside of a custom resource.
+- `PUT` requests to the `/status` subresource take a custom resource object and ignore changes to anything except the status stanza.
+- `PUT` requests to the `/status` subresource only validate the status stanza of the custom resource.
+- `PUT`/`POST`/`PATCH` requests to the custom resource ignore changes to the status stanza.
+- The `.metadata.generation` value is incremented for all changes, except for changes to `.metadata` or `.status`.
+-->
+#### Status 子资源  {#status-subresource}
+
+当启用了 status 子资源时，对应定制资源的 `/status` 子资源会被暴露出来。
+
+- status 和 spec 内容分别用定制资源内的 `.status` 和 `.spec` JSON 路径来表达；
+- 对 `/status` 子资源的 `PUT` 请求要求使用定制资源对象作为其输入，但会忽略
+  status 之外的所有内容。
+- 对 `/status` 子资源的 `PUT` 请求仅对定制资源的 status 内容进行合法性检查。
+- 对定制资源的 `PUT`、`POST`、`PATCH` 请求会忽略 status 内容的改变。
+- 对所有变更请求，除非改变是针对 `.metadata` 或 `.status`，`.metadata.generation`
+  的取值都会增加。
+<!--
+- Only the following constructs are allowed at the root of the CRD OpenAPI validation schema:
+-->
+- 在 CRD OpenAPI 合法性检查模式定义的根节点，只允许存在以下结构：
+
+  - `description`
+  - `example`
+  - `exclusiveMaximum`
+  - `exclusiveMinimum`
+  - `externalDocs`
+  - `format`
+  - `items`
+  - `maximum`
+  - `maxItems`
+  - `maxLength`
+  - `minimum`
+  - `minItems`
+  - `minLength`
+  - `multipleOf`
+  - `pattern`
+  - `properties`
+  - `required`
+  - `title`
+  - `type`
+  - `uniqueItems`
+
+<!--
+#### Scale subresource
+
+When the scale subresource is enabled, the `/scale` subresource for the custom resource is exposed.
+The `autoscaling/v1.Scale` object is sent as the payload for `/scale`.
+
+To enable the scale subresource, the following fields are defined in the CustomResourceDefinition.
+-->
+#### Scale 子资源   {#scale-subresource}
+
+当启用了 scale 子资源时，定制资源的 `/scale` 子资源就被暴露出来。
+针对 `/scale` 所发送的对象是 `autoscaling/v1.Scale`。
+
+为了启用 scale 子资源，CustomResourceDefinition 定义了以下字段：
+
+<!--
+- `specReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `scale.spec.replicas`.
+
+  - It is a required value.
+  - Only JSONPaths under `.spec` and with the dot notation are allowed.
+  - If there is no value under the `specReplicasPath` in the custom resource,
+the `/scale` subresource will return an error on GET.
+-->
+- `specReplicasPath` 指定定制资源内与 `scale.spec.replicas` 对应的 JSON 路径。
+
+  - 此字段为必需值。
+  - 只可以使用 `.spec` 下的 JSON 路径，只可使用带句点的路径。
+  - 如果定制资源的 `specReplicasPath` 下没有取值，则针对 `/scale` 子资源执行 GET
+    操作时会返回错误。
+
+<!--
+- `statusReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `scale.status.replicas`.
+
+  - It is a required value.
+  - Only JSONPaths under `.status` and with the dot notation are allowed.
+  - If there is no value under the `statusReplicasPath` in the custom resource,
+the status replica value in the `/scale` subresource will default to 0.
+-->
+- `statusReplicasPath` 指定定制资源内与 `scale.status.replicas` 对应的 JSON 路径。
+
+  - 此字段为必需值。
+  - 只可以使用 `.status` 下的 JSON 路径，只可使用带句点的路径。
+  - 如果定制资源的 `statusReplicasPath` 下没有取值，则针对 `/scale` 子资源的
+    副本个数状态值默认为 0。
+
+<!--
+- `labelSelectorPath` defines the JSONPath inside of a custom resource that corresponds to `scale.status.selector`.
+
+  - It is an optional value.
+  - It must be set to work with HPA.
+  - Only JSONPaths under `.status` or `.spec` and with the dot notation are allowed.
+  - If there is no value under the `labelSelectorPath` in the custom resource,
+the status selector value in the `/scale` subresource will default to the empty string.
+  - The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form.
+-->
+- `labelSelectorPath` 指定定制资源内与 `scale.status.selector` 对应的 JSON 路径。
+
+  - 此字段为可选值。
+  - 此字段必须设置才能使用 HPA。
+  - 只可以使用 `.status` 或 `.spec` 下的 JSON 路径，只可使用带句点的路径。
+  - 如果定制资源的 `labelSelectorPath` 下没有取值，则针对 `/scale` 子资源的
+    选择算符状态值默认为空字符串。
+  - 此 JSON 路径所指向的字段必须是一个字符串字段（而不是复合的选择算符结构），
+    其中包含标签选择算符串行化的字符串形式。
+
+<!--
+In the following example, both status and scale subresources are enabled.
+
+Save the CustomResourceDefinition to `resourcedefinition.yaml`:
+-->
+在下面的例子中，`status` 和 `scale` 子资源都被启用。
+
+将此 CustomResourceDefinition 保存到 `resourcedefinition.yaml` 文件：
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: crontabs.stable.example.com
+spec:
+  group: stable.example.com
+  versions:
+    - name: v1
+      served: true
+      storage: true
+      schema:
+        openAPIV3Schema:
+          type: object
+          properties:
+            spec:
+              type: object
+              properties:
+                cronSpec:
+                  type: string
+                image:
+                  type: string
+                replicas:
+                  type: integer
+            status:
+              type: object
+              properties:
+                replicas:
+                  type: integer
+                labelSelector:
+                  type: string
+      # subresources 描述定制资源的子资源
+      subresources:
+        # status 启用 status 子资源
+        status: {}
+        # scale 启用 scale 子资源
+        scale:
+          # specReplicasPath 定义定制资源中对应 scale.spec.replicas 的 JSON 路径
+          specReplicasPath: .spec.replicas
+          # statusReplicasPath 定义定制资源中对应 scale.status.replicas 的 JSON 路径 
+          statusReplicasPath: .status.replicas
+          # labelSelectorPath  定义定制资源中对应 scale.status.selector 的 JSON 路径 
+          labelSelectorPath: .status.labelSelector
+  scope: Namespaced
+  names:
+    plural: crontabs
+    singular: crontab
+    kind: CronTab
+    shortNames:
+    - ct
+```
+
+<!--
+And create it:
+-->
+之后创建此 CustomResourceDefinition：
+
+```shell
+kubectl apply -f resourcedefinition.yaml
+```
+
+<!--
+After the CustomResourceDefinition object has been created, you can create custom objects.
+
+If you save the following YAML to `my-crontab.yaml`:
+-->
+CustomResourceDefinition 对象创建完毕之后，你可以创建定制对象，。
+
+如果你将下面的 YAML 保存到 `my-crontab.yaml` 文件：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "* * * * */5"
+  image: my-awesome-cron-image
+  replicas: 3
+```
+
+<!--
+and create it:
+-->
+并创建定制对象：
+
+```shell
+kubectl apply -f my-crontab.yaml
+```
+
+<!--
+Then new namespaced RESTful API endpoints are created at:
+-->
+那么会创建新的、命名空间作用域的 RESTful  API 端点：
+
+```
+/apis/stable.example.com/v1/namespaces/*/crontabs/status
+```
+
+<!-- and -->
+和
+
+```
+/apis/stable.example.com/v1/namespaces/*/crontabs/scale
+```
+
+<!--
+A custom resource can be scaled using the `kubectl scale` command.
+For example, the following command sets `.spec.replicas` of the
+custom resource created above to 5:
+-->
+定制资源可以使用 `kubectl scale` 命令来扩缩其规模。
+例如下面的命令将前面创建的定制资源的 `.spec.replicas` 设置为 5：
+
+```shell
+kubectl scale --replicas=5 crontabs/my-new-cron-object
+```
+```
+crontabs "my-new-cron-object" scaled
+```
+```shell
+kubectl get crontabs my-new-cron-object -o jsonpath='{.spec.replicas}'
+```
+```
+5
+```
+
+<!--
+You can use a [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) to protect custom
+resources that have the scale subresource enabled.
+-->
+你可以使用 [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)
+来保护启用了 scale 子资源的定制资源。
+
+<!--
+### Categories
+-->
+### 分类   {#categories}
+
+{{< feature-state state="beta" for_k8s_version="v1.10" >}}
+
+<!--
+Categories is a list of grouped resources the custom resource belongs to (eg. `all`).
+You can use `kubectl get <category-name>` to list the resources belonging to the category.
+
+The following example adds `all` in the list of categories in the CustomResourceDefinition
+and illustrates how to output the custom resource using `kubectl get all`.
+
+Save the following CustomResourceDefinition to `resourcedefinition.yaml`:
+-->
+分类（Categories）是定制资源所归属的分组资源列表（例如，`all`）。
+你可以使用 `kubectl get <分类名称>` 来列举属于某分类的所有资源。
+
+下面的示例在 CustomResourceDefinition 中将 `all` 添加到分类列表中，
+并展示了如何使用 `kubectl get all` 来输出定制资源：
+
+将下面的 CustomResourceDefinition 保存到 `resourcedefinition.yaml` 文件中：
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: crontabs.stable.example.com
+spec:
+  group: stable.example.com
+  versions:
+    - name: v1
+      served: true
+      storage: true
+      schema:
+        openAPIV3Schema:
+          type: object
+          properties:
+            spec:
+              type: object
+              properties:
+                cronSpec:
+                  type: string
+                image:
+                  type: string
+                replicas:
+                  type: integer
+  scope: Namespaced
+  names:
+    plural: crontabs
+    singular: crontab
+    kind: CronTab
+    shortNames:
+    - ct
+    # categories 是定制资源所归属的分类资源列表
+    categories:
+    - all
+```
+
+<!--
+and create it:
+-->
+之后创建此 CRD：
+
+```shell
+kubectl apply -f resourcedefinition.yaml
+```
+
+<!--
+After the CustomResourceDefinition object has been created, you can create custom objects.
+
+Save the following YAML to `my-crontab.yaml`:
+-->
+创建了 CustomResourceDefinition 对象之后，你可以创建定制对象。
+
+将下面的 YAML 保存到 `my-crontab.yaml` 中：
+
+```yaml
+apiVersion: "stable.example.com/v1"
+kind: CronTab
+metadata:
+  name: my-new-cron-object
+spec:
+  cronSpec: "* * * * */5"
+  image: my-awesome-cron-image
+```
+
+<!--
+and create it:
+-->
+并创建定制对象：
+
+```shell
+kubectl apply -f my-crontab.yaml
+```
+
+<!--
+You can specify the category when using `kubectl get`:
+-->
+你可以在使用 `kubectl get` 时指定分类：
+
+```shell
+kubectl get all
+```
+
+<!--
+The output will include the custom resources of kind `CronTab`:
+-->
+输出中会包含类别为 `CronTab` 的定制资源：
+
+```console
+NAME                          AGE
+crontabs/my-new-cron-object   3s
+```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Read about [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
+
+* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io).
+
+* Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a
+  CustomResourceDefinition.
+-->
+* 阅读了解[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 参阅 [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io)
+* 参阅支持 CustomResourceDefinition 的[多个版本](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
+
diff --git a/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md
new file mode 100644
index 0000000000..ded4526eb6
--- /dev/null
+++ b/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md
@@ -0,0 +1,124 @@
+---
+title: 设置 Konnectivity 服务
+content_type: task
+weight: 70
+---
+
+<!-- overview -->
+<!--
+The Konnectivity service provides a TCP level proxy for the control plane to cluster
+communication.
+-->
+Konnectivity 服务为控制平面提供集群通信的 TCP 级别代理。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- steps -->
+<!--
+## Configure the Konnectivity service
+
+The following steps require an egress configuration, for example:
+-->
+## 配置 Konnectivity 服务
+
+接下来的步骤需要出口配置，比如：
+
+{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
+
+<!--
+You need to configure the API Server to use the Konnectivity service
+and direct the network traffic to the cluster nodes:
+
+1. Make sure that
+the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is enabled. You can enable
+[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
+by providing the following flags to the kube-apiserver:
+   ```
+   --service-account-issuer=api
+   --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
+   --api-audiences=system:konnectivity-server
+   ```
+-->
+你需要配置 API 服务器来使用 Konnectivity 服务，并将网络流量定向到集群节点：
+
+1. 确保 `ServiceAccountTokenVolumeProjection`
+   [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+   被启用。你可以通过为 kube-apiserver 提供以下标志启用
+   [服务账号令牌卷保护](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)：
+
+   ```
+   --service-account-issuer=api
+   --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
+   --api-audiences=system:konnectivity-server
+   ```
+
+<!--
+1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
+1. Set the `--egress-selector-config-file` flag of the API Server to the path of
+your API Server egress configuration file.
+-->
+{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
+2. 创建一个出口配置文件比如 `admin/konnectivity/egress-selector-configuration.yaml`。
+3. 将 API 服务器的 `--egress-selector-config-file` 参数设置为你的 API 服务器的
+   离站流量配置文件路径。
+
+<!--
+Generate or obtain a certificate and kubeconfig for konnectivity-server.  
+For example, you can use the OpenSSL command line tool to issue a X.509 certificate,
+using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-plane host.
+-->
+为 konnectivity-server 生成或者取得证书和 kubeconfig 文件。
+例如，你可以使用 OpenSSL 命令行工具，基于存放在某控制面主机上
+`/etc/kubernetes/pki/ca.crt` 文件中的集群 CA 证书来
+发放一个 X.509 证书，
+
+```bash
+openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr
+openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
+SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
+kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
+rm -f konnectivity.crt konnectivity.key konnectivity.csr
+```
+
+<!--
+Next, you need to deploy the Konnectivity server and agents.
+[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
+is a reference implementation.
+
+Deploy the Konnectivity server on your control plane node. The provided
+`konnectivity-server.yaml` manifest assumes
+that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod"
+term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity
+server as a DaemonSet.
+-->
+接下来，你需要部署 Konnectivity 服务器和代理。
+[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
+是一个参考实现。
+
+在控制面节点上部署 Konnectivity 服务。
+下面提供的 `konnectivity-server.yaml` 配置清单假定在你的集群中
+Kubernetes 组件都是部署为{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}} 的。
+如果不是，你可以将 Konnectivity 服务部署为 DaemonSet。
+
+{{< codenew file="admin/konnectivity/konnectivity-server.yaml" >}}
+
+<!--
+Then deploy the Konnectivity agents in your cluster:
+-->
+在你的集群中部署 Konnectivity 代理：
+
+{{< codenew file="admin/konnectivity/konnectivity-agent.yaml" >}}
+
+<!--
+Last, if RBAC is enabled in your cluster, create the relevant RBAC rules:
+-->
+最后，如果你的集群启用了 RBAC，请创建相关的 RBAC 规则：
+
+{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}}
+
diff --git a/content/zh/docs/tasks/inject-data-application/_index.md b/content/zh/docs/tasks/inject-data-application/_index.md
index d95dfdfb35..8a23b60fc1 100644
--- a/content/zh/docs/tasks/inject-data-application/_index.md
+++ b/content/zh/docs/tasks/inject-data-application/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "给应用注入数据"
 weight: 30
+description: 给你的工作负载 Pod 指定配置和其他数据。
 ---
diff --git a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
index 05a207a236..de9f1e8a53 100644
--- a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -76,21 +76,12 @@ Pod:
     ```
 
 <!--
-1. Get a shell to the container running in your Pod:
+1. List the Pod's container environment variables:
 -->
-1. 进入该 Pod 下的容器并打开一个命令终端：
+1. 列出 Pod 容器的环境变量：
     
     ```shell
-    kubectl exec -it envar-demo -- /bin/bash
-    ```
-
-<!--
-1. In your shell, run the `printenv` command to list the environment variables.
--->
-1. 在命令终端中通过执行 `printenv` 打印出环境变量。
-
-    ```shell
-    root@envar-demo:/# printenv
+    kubectl exec envar-demo -- printenv
     ```
     
     <!--
@@ -107,11 +98,6 @@ Pod:
     DEMO_FAREWELL=Such a sweet sorrow
     ```
 
-<!--
-1. To exit the shell, enter `exit`.
--->
-1. 通过键入 `exit` 退出命令终端。
-
 <!--
 {{< note >}}
 The environment variables set using the `env` or `envFrom` field
diff --git a/content/zh/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/zh/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
new file mode 100644
index 0000000000..12c5032b49
--- /dev/null
+++ b/content/zh/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
@@ -0,0 +1,115 @@
+---
+title: 定义相互依赖的环境变量
+content_type: task
+weight: 20
+---
+<!-- 
+title: Define Dependent Environment Variables
+-->
+
+<!-- overview -->
+
+<!-- 
+This page shows how to define dependent environment variables for a container
+in a Kubernetes Pod.
+-->
+本页展示了如何为 Kubernetes Pod 中的容器定义相互依赖的环境变量。
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+<!-- steps -->
+
+<!-- 
+## Define an environment dependent variable for a container
+
+When you create a Pod, you can set dependent environment variables for the containers that run in the Pod. To set dependent environment variables, you can use $(VAR_NAME) in the `value` of `env` in the configuration file.
+
+In this exercise, you create a Pod that runs one container. The configuration
+file for the Pod defines an dependent environment variable with common usage defined. Here is the configuration manifest for the
+Pod:
+-->
+## 为容器定义相互依赖的环境变量   {#define-an-environment-dependent-variable-for-a-container}
+
+当创建一个 Pod 时，你可以为运行在 Pod 中的容器设置相互依赖的环境变量。 
+设置相互依赖的环境变量，你就可以在配置清单文件的 `env` 的 `value` 中使用 $(VAR_NAME)。
+
+在本练习中，你会创建一个单容器的 Pod。
+此 Pod 的配置文件定义了一个已定义常用用法的相互依赖的环境变量。
+下面是 Pod 的配置清单：
+
+{{< codenew file="pods/inject/dependent-envars.yaml" >}}
+
+<!-- 1. Create a Pod based on that manifest: -->
+1. 依据清单创建 Pod：
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
+    ```
+    ```
+    pod/dependent-envars-demo created
+    ```
+    <!-- 2. List the running Pods: -->
+2. 列出运行的 Pod：
+
+    ```shell
+    kubectl get pods dependent-envars-demo
+    ```
+    ```
+    NAME                      READY     STATUS    RESTARTS   AGE
+    dependent-envars-demo     1/1       Running   0          9s
+    ```
+
+    <!-- 3. Check the logs for the container running in your Pod: -->
+3. 检查 Pod 中运行容器的日志：
+
+    ```shell
+    kubectl logs pod/dependent-envars-demo
+    ```
+    ```
+
+    UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+    SERVICE_ADDRESS=https://172.17.0.1:80
+    ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+    ```
+
+<!-- 
+As shown above, you have defined the correct dependency reference of `SERVICE_ADDRESS`, bad dependency reference of `UNCHANGED_REFERENCE` and skip dependent references of `ESCAPED_REFERENCE`.
+
+When an environment variable is already defined when being referenced,
+the reference can be correctly resolved, such as in the `SERVICE_ADDRESS` case.
+-->
+如上所示，你已经定义了 `SERVICE_ADDRESS` 的正确依赖引用，
+`UNCHANGED_REFERENCE` 的错误依赖引用，
+并跳过了 `ESCAPED_REFERENCE` 的依赖引用。
+
+如果环境变量被引用时已事先定义，则引用可以正确解析，
+比如 `SERVICE_ADDRESS` 的例子。
+
+<!-- 
+When the environment variable is undefined or only includes some variables, the undefined environment variable is treated as a normal string, such as `UNCHANGED_REFERENCE`. Note that incorrectly parsed environment variables, in general, will not block the container from starting.
+
+The `$(VAR_NAME)` syntax can be escaped with a double `$`, ie: `$$(VAR_NAME)`.
+Escaped references are never expanded, regardless of whether the referenced variable
+is defined or not. This can be seen from the `ESCAPED_REFERENCE` case above.
+-->
+当环境变量未定义或仅包含部分变量时，未定义的变量会被当做普通字符串对待，
+比如 `UNCHANGED_REFERENCE` 的例子。
+注意，解析不正确的环境变量通常不会阻止容器启动。
+
+`$(VAR_NAME)` 这样的语法可以用两个 `$` 转义，既：`$$(VAR_NAME)`。
+无论引用的变量是否定义，转义的引用永远不会展开。
+这一点可以从上面 `ESCAPED_REFERENCE` 的例子得到印证。
+
+## {{% heading "whatsnext" %}}
+
+
+<!--
+* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
+-->
+* 进一步了解[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
+* 参阅 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
+
diff --git a/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
index 6683178d1d..5d271d71dd 100644
--- a/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
+++ b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -329,7 +329,7 @@ This functionality is available in Kubernetes v1.6 and later.
    ```
 
 <!--
-*  Use envFrom to define all of the Secret’s data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
+*  Use envFrom to define all of the Secret's data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
 -->
 *  使用 `envFrom` 来将 Secret 中的所有数据定义为环境变量。
    Secret 中的键名成为容器中的环境变量名：
diff --git a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
index bdb38da4bd..0bc46e4c07 100644
--- a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+++ b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
@@ -291,11 +291,11 @@ The following information is available to containers through environment
 variables and `downwardAPI` volumes:
 
 * Information available via `fieldRef`:
-  * `metadata.name` - the pod’s name
-  * `metadata.namespace` - the pod’s namespace
-  * `metadata.uid` - the pod’s UID, available since v1.8.0-alpha.2
-  * `metadata.labels['<KEY>']` - the value of the pod’s label `<KEY>` (for example, `metadata.labels['mylabel']`); available in Kubernetes 1.9+
-  * `metadata.annotations['<KEY>']` - the value of the pod’s annotation `<KEY>` (for example, `metadata.annotations['myannotation']`); available in Kubernetes 1.9+
+  * `metadata.name` - the pod's name
+  * `metadata.namespace` - the pod's namespace
+  * `metadata.uid` - the pod's UID, available since v1.8.0-alpha.2
+  * `metadata.labels['<KEY>']` - the value of the pod's label `<KEY>` (for example, `metadata.labels['mylabel']`); available in Kubernetes 1.9+
+  * `metadata.annotations['<KEY>']` - the value of the pod's annotation `<KEY>` (for example, `metadata.annotations['myannotation']`); available in Kubernetes 1.9+
 -->
 下面这些信息可以通过环境变量和 `downwardAPI` 卷提供给容器：
 
@@ -309,12 +309,12 @@ variables and `downwardAPI` volumes:
 
 <!--
 * Information available via `resourceFieldRef`:
-  * A Container’s CPU limit
-  * A Container’s CPU request
-  * A Container’s memory limit
-  * A Container’s memory request
-  * A Container’s ephemeral-storage limit, available since v1.8.0-beta.0
-  * A Container’s ephemeral-storage request, available since v1.8.0-beta.0
+  * A Container's CPU limit
+  * A Container's CPU request
+  * A Container's memory limit
+  * A Container's memory request
+  * A Container's ephemeral-storage limit, available since v1.8.0-beta.0
+  * A Container's ephemeral-storage request, available since v1.8.0-beta.0
 -->
 * 能通过 `resourceFieldRef` 获得的：
   * 容器的 CPU 约束值
diff --git a/content/zh/docs/tasks/inject-data-application/podpreset.md b/content/zh/docs/tasks/inject-data-application/podpreset.md
index 2765869e40..78237967e1 100644
--- a/content/zh/docs/tasks/inject-data-application/podpreset.md
+++ b/content/zh/docs/tasks/inject-data-application/podpreset.md
@@ -26,13 +26,13 @@ This page shows how to use PodPreset objects to inject information like {{< glos
 ## {{% heading "prerequisites" %}}
 
 <!--
-You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](/docs/setup/learning-environment/minikube/).
+You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/).
 Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
 -->
 你需要一个运行的 Kubernetes 集群以及配置好与集群通信的 kubectl 命令行工具。
-如果你还没有集群，可以使用 [Minikube](/zh/docs/setup/learning-environment/minikube/)
+如果你还没有集群，可以使用 [Minikube](https://minikube.sigs.k8s.io/docs/)
 安装一个。
-确保你已经在集群中[启用了 PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset)。
+确保你已经在集群中[启用了 PodPreset](/zh/docs/concepts/workloads/pods/podpreset/#enable-pod-preset)。
 
 <!--
 ## Use Pod presets to inject environment variables and volumes
diff --git a/content/zh/docs/tasks/job/_index.md b/content/zh/docs/tasks/job/_index.md
index 498d5013f9..3f2ac22fe8 100644
--- a/content/zh/docs/tasks/job/_index.md
+++ b/content/zh/docs/tasks/job/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "运行 Jobs"
 weight: 50
+description: 使用并行处理运行 Jobs。
 ---
diff --git a/content/zh/docs/tasks/job/parallel-processing-expansion.md b/content/zh/docs/tasks/job/parallel-processing-expansion.md
index b010ae6848..b4b4cc255b 100644
--- a/content/zh/docs/tasks/job/parallel-processing-expansion.md
+++ b/content/zh/docs/tasks/job/parallel-processing-expansion.md
@@ -1,341 +1,474 @@
----
-title: 使用扩展进行并行处理
-content_type: concept
-min-kubernetes-server-version: v1.8
-weight: 20
----
-
-<!--
----
-title: Parallel Processing using Expansions
-content_type: concept
-min-kubernetes-server-version: v1.8
-weight: 20
----
--->
-
-<!-- overview -->
-
-<!--
-In this example, we will run multiple Kubernetes Jobs created from
-a common template.  You may want to be familiar with the basic,
-non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) first.
--->
-在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes Job。您可能需要先熟悉 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本概念、非并行以及如何使用它。
-
-
-
-
-<!-- body -->
-
-<!--
-## Basic Template Expansion
--->
-
-## 基本模板扩展
-
-<!--
-First, download the following template of a job to a file called `job-tmpl.yaml`
--->
-首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。
-
-{{< codenew file="application/job/job-tmpl.yaml" >}}
-
-<!--
-Unlike a *pod template*, our *job template* is not a Kubernetes API type.  It is just
-a yaml representation of a Job object that has some placeholders that need to be filled
-in before it can be used.  The `$ITEM` syntax is not meaningful to Kubernetes.
--->
-与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是 Job 对象的 yaml 表示，
-YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。
-
-<!--
-In this example, the only processing the container does is to `echo` a string and sleep for a bit.
-In a real use case, the processing would be some substantial computation, such as rendering a frame
-of a movie, or processing a range of rows in a database.  The `$ITEM` parameter would specify for
-example, the frame number or the row range.
--->
-在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并睡眠一段时间。
-在真实的用例中，处理将是一些重要的计算，例如渲染电影的一帧，或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。
-
-<!--
-This Job and its Pod template have a label: `jobgroup=jobexample`.  There is nothing special
-to the system about this label.  This label
-makes it convenient to operate on all the jobs in this group at once.
-We also put the same label on the pod template so that we can check on all Pods of these Jobs
-with a single command.
-After the job is created, the system will add more labels that distinguish one Job's pods
-from another Job's pods.
-Note that the label key `jobgroup` is not special to Kubernetes. You can pick your own label scheme.
--->
-这个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。
-这个标签使得我们可以方便地同时操作组中的所有作业。
-我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些 Job 的所有 pod。
-创建作业之后，系统将添加更多的标签来区分一个 Job 的 pod 和另一个 Job 的 pod。
-注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。
-
-<!--
-Next, expand the template into multiple files, one for each item to be processed.
--->
-下一步，将模板展开到多个文件中，每个文件对应要处理的项。
-
-```shell
-# 下载 job-templ.yaml
-curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
-
-# 创建临时目录，并且在目录中创建 job yaml 文件
-mkdir ./jobs
-for i in apple banana cherry
-do
-  cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
-done
-```
-
-<!--
-Check if it worked:
--->
-检查是否工作正常：
-
-```shell
-ls jobs/
-```
-
-<!--
-The output is similar to this:
--->
-输出类似以下内容：
-
-```
-job-apple.yaml
-job-banana.yaml
-job-cherry.yaml
-```
-
-<!--
-Here, we used `sed` to replace the string `$ITEM` with the loop variable.
-You could use any type of template language (jinja2, erb) or write a program
-to generate the Job objects.
--->
-在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。
-您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成 Job 对象。
-
-<!--
-Next, create all the jobs with one kubectl command:
--->
-接下来，使用 kubectl 命令创建所有作业：
-
-```shell
-kubectl create -f ./jobs
-```
-
-<!--
-The output is similar to this:
--->
-输出类似以下内容：
-
-```
-job.batch/process-item-apple created
-job.batch/process-item-banana created
-job.batch/process-item-cherry created
-```
-
-<!--
-Now, check on the jobs:
--->
-现在，检查这些作业：
-
-```shell
-kubectl get jobs -l jobgroup=jobexample
-```
-
-<!--
-The output is similar to this:
--->
-输出类似以下内容：
-
-```
-NAME                  COMPLETIONS   DURATION   AGE
-process-item-apple    1/1           14s        20s
-process-item-banana   1/1           12s        20s
-process-item-cherry   1/1           12s        20s
-```
-
-<!--
-Here we use the `-l` option to select all jobs that are part of this
-group of jobs.  (There might be other unrelated jobs in the system that we
-do not care to see.)
--->
-在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。)
-
-<!--
-We can check on the pods as well using the same label selector:
--->
-使用同样的标签选择器，我们还可以检查 pods：
-
-```shell
-kubectl get pods -l jobgroup=jobexample
-```
-
-<!--
-The output is similar to this:
--->
-输出类似以下内容：
-
-```
-NAME                        READY     STATUS      RESTARTS   AGE
-process-item-apple-kixwv    0/1       Completed   0          4m
-process-item-banana-wrsf7   0/1       Completed   0          4m
-process-item-cherry-dnfu9   0/1       Completed   0          4m
-```
-
-<!--
-We can use this single command to check on the output of all jobs at once:
--->
-我们可以使用以下操作命令一次性地检查所有作业的输出：
-
-```shell
-kubectl logs -f -l jobgroup=jobexample
-```
-
-<!--
-The output is:
--->
-输出内容为：
-
-```
-Processing item apple
-Processing item banana
-Processing item cherry
-```
-
-<!--
-## Multiple Template Parameters
--->
-
-## 多个模板参数
-
-<!--
-In the first example, each instance of the template had one parameter, and that parameter was also
-used as a label.  However label keys are limited in [what characters they can
-contain](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
--->
-在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。
-但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。
-
-<!--
-This slightly more complex example uses the jinja2 template language to generate our objects.
-We will use a one-line python script to convert the template to a file.
--->
-这个稍微复杂一点的示例使用 jinja2 模板语言来生成我们的对象。
-我们将使用一行 python 脚本将模板转换为文件。
-
-<!--
-First, copy and paste the following template of a Job object, into a file called `job.yaml.jinja2`:
--->
-首先，粘贴 Job 对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中：
-
-```liquid
-{%- set params = [{ "name": "apple", "url": "https://www.orangepippin.com/varieties/apples", },
-                  { "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", },
-                  { "name": "raspberry", "url": "https://www.raspberrypi.org/" }]
-%}
-{%- for p in params %}
-{%- set name = p["name"] %}
-{%- set url = p["url"] %}
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: jobexample-{{ name }}
-  labels:
-    jobgroup: jobexample
-spec:
-  template:
-    metadata:
-      name: jobexample
-      labels:
-        jobgroup: jobexample
-    spec:
-      containers:
-      - name: c
-        image: busybox
-        command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
-      restartPolicy: Never
----
-{%- endfor %}
-
-```
-
-<!--
-The above template defines parameters for each job object using a list of
-python dicts (lines 1-4).  Then a for loop emits one job yaml object
-for each set of parameters (remaining lines).
-We take advantage of the fact that multiple yaml documents can be concatenated
-with the `---` separator (second to last line).
-.)  We can pipe the output directly to kubectl to
-create the objects.
--->
-上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。
-然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。
-我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。
-我们可以将输出直接传递给 kubectl 来创建对象。
-
-<!--
-You will need the jinja2 package if you do not already have it: `pip install --user jinja2`.
-Now, use this one-line python program to expand the template:
--->
-如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。
-现在，使用这个一行 python 程序来展开模板:
-
-```shell
-alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
-```
-
-
-<!--
-The output can be saved to a file, like this:
--->
-输出可以保存到一个文件，像这样：
-
-```shell
-cat job.yaml.jinja2 | render_template > jobs.yaml
-```
-
-<!--
-Or sent directly to kubectl, like this:
--->
-或直接发送到 kubectl，如下所示：
-
-```shell
-cat job.yaml.jinja2 | render_template | kubectl apply -f -
-```
-
-<!--
-## Alternatives
--->
-## 替代方案
-
-<!--
-If you have a large number of job objects, you may find that:
--->
-如果您有大量作业对象，您可能会发现：
-
-<!--
-- Even using labels, managing so many Job objects is cumbersome.
-- You exceed resource quota when creating all the Jobs at once,
-  and do not want to wait to create them incrementally.
-- Very large numbers of jobs created at once overload the
-  Kubernetes apiserver, controller, or scheduler.
--->
-
-- 即使使用标签，管理这么多 Job 对象也很麻烦。
-- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建 Job 并等待其完成。
-- 同时创建大量作业会使 Kubernetes apiserver、控制器或者调度器负压过大。
-  
-
-<!--
-In this case, you can consider one of the
-other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
--->
-在这种情况下，您可以考虑其他的[作业模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。
-
-
+---
+title: 使用展开的方式进行并行处理
+content_type: concept
+min-kubernetes-server-version: v1.8
+weight: 20
+---
+
+<!--
+title: Parallel Processing using Expansions
+content_type: concept
+min-kubernetes-server-version: v1.8
+weight: 20
+-->
+
+<!-- overview -->
+
+<!--
+This task demonstrates running multiple {{< glossary_tooltip text="Jobs" term_id="job" >}}
+based on a common template. You can use this approach to process batches of work in
+parallel.
+
+For this example there are only three items: _apple_, _banana_, and _cherry_.
+The sample Jobs process each item simply by printing a string then pausing.
+
+See [using Jobs in real workloads](#using-jobs-in-real-workloads) to learn about how
+this pattern fits more realistic use cases.
+-->
+本任务展示基于一个公共的模板运行多个{{< glossary_tooltip text="Jobs" term_id="job" >}}。
+你可以用这种方法来并行执行批处理任务。
+
+在本任务示例中，只有三个工作条目：_apple_、_banana_ 和 _cherry_。
+示例任务处理每个条目时仅仅是打印一个字符串之后结束。
+参考[在真实负载中使用 Job](#using-jobs-in-real-workloads)了解更适用于真实使用场景的模式。
+
+## {{% heading "prerequisites" %}}
+
+<!--
+You should be familiar with the basic,
+non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
+-->
+你应先熟悉基本的、非并行的 [Job](/zh/docs/concepts/workloads/controllers/job/)
+的用法。
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!--
+For basic templating you need the command-line utility `sed`.
+
+To follow the advanced templating example, you need a working installation of
+[Python](https://www.python.org/), and the Jinja2 template
+library for Python.
+
+Once you have Python set up, you can install Jinja2 by running:
+-->
+任务中的基本模板示例要求安装命令行工具 `sed`。
+要使用较高级的模板示例，你需要安装 [Python](https://www.python.org/)，
+并且要安装 Jinja2 模板库。
+
+一旦 Python 已经安装好，你可以运行下面的命令安装 Jinja2：
+
+```shell
+pip install --user jinja2
+```
+
+<!-- steps -->
+
+<!--
+## Create Jobs based on a template
+-->
+
+## 基于模板创建 Job  {#create-jobs-based-on-a-template}
+
+<!--
+First, download the following template of a job to a file called `job-tmpl.yaml`
+-->
+首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。
+
+{{< codenew file="application/job/job-tmpl.yaml" >}}
+
+```shell
+# 使用 curl 下载 job-tmpl.yaml
+curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
+```
+
+<!--
+The file you downloaded is not yet a valid Kubernetes
+{{< glossary_tooltip text="manifest" term_id="manifest" >}}.
+Instead that template is a YAML representation of a Job object with some placeholders
+that need to be filled in before it can be used.  The `$ITEM` syntax is not meaningful to Kubernetes.
+-->
+你所下载的文件不是一个合法的 Kubernetes {{< glossary_tooltip text="清单" term_id="manifest" >}}。
+这里的模板只是 Job 对象的 yaml 表示，其中包含一些占位符，在使用它之前需要被填充。
+`$ITEM` 语法对 Kubernetes 没有意义。
+
+<!--
+### Create manifests from the template
+
+The following shell snippet uses `sed` to replace the string `$ITEM` with the loop
+variable, writing into a temporary directory named `jobs`. Run this now:
+-->
+### 基于模板创建清单
+
+下面的 Shell 代码片段使用 `sed` 将字符串 `$ITEM` 替换为循环变量，并将结果
+写入到一个名为 `jobs` 的临时目录。
+
+```shell
+# 展开模板文件到多个文件中，每个文件对应一个要处理的条目
+mkdir ./jobs
+for i in apple banana cherry
+do
+  cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
+done
+```
+
+<!--
+Check if it worked:
+-->
+检查上述脚本的输出：
+
+```shell
+ls jobs/
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+job-apple.yaml
+job-banana.yaml
+job-cherry.yaml
+```
+
+<!--
+You could use any type of template language (for example: Jinja2; ERB), or
+write a program to generate the Job manifests.
+-->
+你可以使用任何一种模板语言（例如：Jinja2、ERB），或者编写一个程序来
+生成 Job 清单。
+
+<!--
+### Create Jobs from the manifests
+
+Next, create all the Jobs with one kubectl command:
+-->
+### 基于清单创建 Job
+
+接下来用一个 kubectl 命令创建所有的 Job：
+
+```shell
+kubectl create -f ./jobs
+```
+
+<!--
+The output is similar to this:
+-->
+
+输出类似于：
+
+```
+job.batch/process-item-apple created
+job.batch/process-item-banana created
+job.batch/process-item-cherry created
+```
+
+<!--
+Now, check on the jobs:
+-->
+现在检查 Job：
+
+```shell
+kubectl get jobs -l jobgroup=jobexample
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+NAME                  COMPLETIONS   DURATION   AGE
+process-item-apple    1/1           14s        22s
+process-item-banana   1/1           12s        21s
+process-item-cherry   1/1           12s        20s
+```
+
+<!--
+Using the `-l` option to kubectl selects only the Jobs that are part
+of this group of jobs (there might be other unrelated jobs in the system).
+
+You can check on the Pods as well using the same
+{{< glossary_tooltip text="label selector" term_id="selector" >}}:
+-->
+使用 kubectl 的 `-l` 选项可以仅选择属于当前 Job 组的对象
+（系统中可能存在其他不相关的 Job）。
+
+你可以使用相同的 {{< glossary_tooltip text="标签选择算符" term_id="selector" >}}
+来过滤 Pods：
+
+```shell
+kubectl get pods -l jobgroup=jobexample
+```
+
+<!--
+The output is similar to:
+-->
+输出类似于：
+
+```
+NAME                        READY     STATUS      RESTARTS   AGE
+process-item-apple-kixwv    0/1       Completed   0          4m
+process-item-banana-wrsf7   0/1       Completed   0          4m
+process-item-cherry-dnfu9   0/1       Completed   0          4m
+```
+
+<!--
+We can use this single command to check on the output of all jobs at once:
+-->
+我们可以用下面的命令查看所有 Job 的输出：
+
+```shell
+kubectl logs -f -l jobgroup=jobexample
+```
+
+<!--
+The output should be:
+-->
+输出类似于：
+
+```
+Processing item apple
+Processing item banana
+Processing item cherry
+```
+
+<!--
+### Clean up {#cleanup-1}
+-->
+### 清理 {#cleanup-1}
+
+```shell
+# 删除所创建的 Job
+# 集群会自动清理 Job 对应的 Pod
+kubectl delete job -l jobgroup=jobexample
+```
+
+<!--
+## Use advanced template parameters
+
+In the [first example](#create-jobs-based-on-a-template), each instance of the template had one
+parameter, and that parameter was also used in the Job's name. However,
+[names](/docs/concepts/overview/working-with-objects/names/#names) are restricted
+to contain only certain characters.
+-->
+## 使用高级模板参数
+
+在[第一个例子](#create-jobs-based-on-a-template)中，模板的每个示例都有一个参数
+而该参数也用在 Job 名称中。不过，对象
+[名称](/zh/docs/concepts/overview/working-with-objects/names/#names)
+被限制只能使用某些字符。
+
+<!--
+This slightly more complex example uses the
+[Jinja template language](https://palletsprojects.com/p/jinja/) to generate manifests
+and then objects from those manifests, with a multiple parameters for each Job.
+
+For this part of the task, you are going to use a one-line Python script to
+convert the template to a set of manifests.
+
+First, copy and paste the following template of a Job object, into a file called `job.yaml.jinja2`:
+-->
+这里的略微复杂的例子使用 [Jinja 模板语言](https://palletsprojects.com/p/jinja/)
+来生成清单，并基于清单来生成对象，每个 Job 都有多个参数。
+
+在本任务中，你将会使用一个一行的 Python 脚本，将模板转换为一组清单文件。
+
+首先，复制下面的 Job 对象模板到一个名为 `job.yaml.jinja2` 的文件。
+
+```liquid
+{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
+                  { "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
+                  { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
+%}
+{%- for p in params %}
+{%- set name = p["name"] %}
+{%- set url = p["url"] %}
+---
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: jobexample-{{ name }}
+  labels:
+    jobgroup: jobexample
+spec:
+  template:
+    metadata:
+      name: jobexample
+      labels:
+        jobgroup: jobexample
+    spec:
+      containers:
+      - name: c
+        image: busybox
+        command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
+      restartPolicy: Never
+{%- endfor %}
+```
+
+<!--
+The above template defines two parameters for each Job object using a list of
+python dicts (lines 1-4). A `for` loop emits one Job manifest for each
+set of parameters (remaining lines).
+
+This example relies on a feature of YAML. One YAML file can contain multiple
+documents (Kubernetes manifests, in this case), separated by `---` on a line
+by itself.
+You can pipe the output directly to `kubectl` to create the Jobs.
+
+Next, use this one-line Python program to expand the template:
+-->
+上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。
+然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。
+我们利用了多个 YAML 文档（这里的 Kubernetes 清单）可以用 `---` 分隔符连接的事实。
+我们可以将输出直接传递给 kubectl 来创建对象。
+
+接下来我们用单行的 Python 程序将模板展开。
+
+```shell
+alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"'
+```
+
+<!--
+Use `render_template` to convert the parameters and template into a single
+YAML file containing Kubernetes manifests:
+-->
+使用 `render_template` 将参数和模板转换成一个 YAML 文件，其中包含 Kubernetes
+资源清单：
+
+```shell
+# 此命令需要之前定义的别名
+cat job.yaml.jinja2 | render_template > jobs.yaml
+```
+
+<!--
+You can view `jobs.yaml` to verify that the `render_template` script worked
+correctly.
+
+Once you are happy that `render_template` is working how you intend,
+you can pipe its output into `kubectl`:
+-->
+你可以查看 `jobs.yaml` 以验证 `render_template` 脚本是否正常工作。
+
+当你对输出结果比较满意时，可以用管道将其输出发送给 kubectl，如下所示：
+
+```shell
+cat job.yaml.jinja2 | render_template | kubectl apply -f -
+```
+
+<!--
+Kubernetes accepts and runs the Jobs you created.
+-->
+Kubernets 接收清单文件并执行你所创建的 Job。
+
+<!-- discussion -->
+
+<!--
+## Using Jobs in real workloads
+
+In a real use case, each Job performs some substantial computation, such as rendering a frame
+of a movie, or processing a range of rows in a database. If you were rendering a movie
+you would set `$ITEM` to the frame number. If you were processing rows from a database
+table, you would set `$ITEM` to represent the range of database rows to process.
+
+In the task, you ran a command to collect the output from Pods by fetching
+their logs. In a real use case, each Pod for a Job writes its output to
+durable storage before completing. You can use a PersistentVolume for each Job,
+or an external storage service. For example, if you are rendering frames for a movie,
+use HTTP to `PUT` the rendered frame data to a URL, using a different URL for each
+frame.
+-->
+## 在真实负载中使用 Job
+
+在真实的负载中，每个 Job 都会执行一些重要的计算，例如渲染电影的一帧，
+或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。
+
+在此任务中，你运行一个命令通过取回 Pod 的日志来收集其输出。
+在真实应用场景中，Job 的每个 Pod 都会在结束之前将其输出写入到某持久性存储中。
+你可以为每个 Job 指定 PersistentVolume 卷，或者使用其他外部存储服务。
+例如，如果你在渲染视频帧，你可能会使用 HTTP 协议将渲染完的帧数据
+用 'PUT' 请求发送到某 URL，每个帧使用不同的 URl。
+
+<!--
+## Labels on Jobs and Pods
+
+After you create a Job, Kubernetes automatically adds additional
+{{< glossary_tooltip text="labels" term_id="label" >}} that
+distinguish one Job's pods from another Job's pods.
+
+In this example, each Job and its Pod template have a label:
+`jobgroup=jobexample`.
+
+Kubernetes itself pays no attention to labels named `jobgroup`. Setting a label
+for all the Jobs you create from a template makes it convenient to operate on all
+those Jobs at once.
+In the [first example](#create-jobs-based-on-a-template) you used a template to
+create several Jobs. The template ensures that each Pod also gets the same label, so
+you can check on all Pods for these templated Jobs with a single command.
+-->
+## Job 和 Pod 上的标签
+
+你创建了 Job 之后，Kubernetes 自动为 Job 的 Pod 添加
+{{< glossary_tooltip text="标签" term_id="label" >}}，以便能够将一个 Job
+的 Pod 与另一个 Job 的 Pod 区分开来。
+
+在本例中，每个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。
+
+Kubernetes 自身对标签名 `jobgroup` 没有什么要求。
+为创建自同一模板的所有 Job 使用同一标签使得我们可以方便地同时操作组中的所有作业。
+在[第一个例子](#create-jobs-based-on-a-template)中，你使用模板来创建了若干 Job。
+模板确保每个 Pod 都能够获得相同的标签，这样你可以用一条命令检查这些模板化
+Job 所生成的全部 Pod。
+
+<!--
+The label key `jobgroup` is not special or reserved.
+You can pick your own labelling scheme.
+There are [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels)
+that you can use if you wish.
+-->
+{{< note >}}
+标签键 `jobgroup` 没什么特殊的，也不是保留字。 你可以选择你自己的标签方案。
+如果愿意，有一些[建议的标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)
+可供使用。
+{{< /note >}}
+
+<!--
+## Alternatives
+
+If you plan to create a large number of Job objects, you may find that:
+-->
+## 替代方案
+
+如果你有计划创建大量 Job 对象，你可能会发现：
+
+<!--
+- Even using labels, managing so many Job objects is cumbersome.
+- If you create many Jobs in a batch, you might place high load
+  on the Kubernetes control plane. Alternatively, the Kubernetes API
+  server could rate limit you, temporarily rejecting your requests with a 429 status.
+- You are limited by a {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}}
+  on Jobs: the API server permanently rejects some of your requests
+  when you create a great deal of work in one batch.
+-->
+- 即使使用标签，管理这么多 Job 对象也很麻烦。
+- 如果你一次性创建很多 Job，很可能会给 Kubernetes 控制面带来很大压力。
+  一种替代方案是，Kubernetes API 可能对请求施加速率限制，通过 429 返回
+  状态值临时拒绝你的请求。
+- 你可能会受到 Job 相关的{{< glossary_tooltip text="资源配额" term_id="resource-quota" >}}
+  限制：如果你在一个批量请求中触发了太多的任务，API 服务器会永久性地拒绝你的某些请求。
+
+<!--
+There are other [job patterns](/docs/concepts/workloads/controllers/job/#job-patterns)
+that you can use to process large amounts of work without creating very many Job
+objects.
+
+You could also consider writing your own [controller](/docs/concepts/architecture/controller/)
+to manage Job objects automatically.
+-->
+还有一些其他[作业模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns)
+可供选择，这些模式都能用来处理大量任务而又不会创建过多的 Job 对象。
+
+你也可以考虑编写自己的[控制器](/zh/docs/concepts/architecture/controller/)
+来自动管理 Job 对象。
+
diff --git a/content/zh/docs/tasks/manage-daemon/_index.md b/content/zh/docs/tasks/manage-daemon/_index.md
index 60765b5da7..fbe5bca836 100644
--- a/content/zh/docs/tasks/manage-daemon/_index.md
+++ b/content/zh/docs/tasks/manage-daemon/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "管理集群守护进程"
 weight: 130
+description: 执行 DaemonSet 管理的常见任务，例如执行滚动更新。
 ---
diff --git a/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
index f2045e78ca..8986b2a6e6 100644
--- a/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
+++ b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
@@ -1,7 +1,7 @@
 ---
 content_type: concept
 title: 调度 GPUs
-description: 配置和调度 GPU 成一类资源以供集群中节点使用
+description: 配置和调度 GPU 成一类资源以供集群中节点使用。
 ---
 <!--
 reviewers:
diff --git a/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
index 9bb6292242..805a055868 100644
--- a/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
+++ b/content/zh/docs/tasks/manage-hugepages/scheduling-hugepages.md
@@ -3,6 +3,7 @@ reviewers:
 - derekwaynecarr
 title: 管理巨页（HugePages）
 content_type: task
+description: 将大页配置和管理为集群中的可调度资源。
 ---
 <!--
 ---
@@ -18,10 +19,9 @@ content_type: task
 
 <!--
 Kubernetes supports the allocation and consumption of pre-allocated huge pages
-by applications in a Pod as a **GA** feature. This page describes how users
-can consume huge pages and the current limitations.
+by applications in a Pod. This page describes how users can consume huge pages.
 --->
-作为 **GA** 特性，Kubernetes 支持在 Pod 应用中使用预先分配的巨页。本文描述了用户如何使用巨页，以及当前的限制。
+Kubernetes 支持在 Pod 应用中使用预先分配的巨页。本文描述了用户如何使用巨页，以及当前的限制。
 
 
 
@@ -48,29 +48,70 @@ schedulable resource.
 
 <!--
 Huge pages can be consumed via container level resource requirements using the
-resource name `hugepages-<size>`, where size is the most compact binary notation
-using integer values supported on a particular node. For example, if a node
-supports 2048KiB page sizes, it will expose a schedulable resource
-`hugepages-2Mi`. Unlike CPU or memory, huge pages do not support overcommit. Note
-that when requesting hugepage resources, either memory or CPU resources must
-be requested as well.
+resource name `hugepages-<size>`, where `<size>` is the most compact binary
+notation using integer values supported on a particular node. For example, if a
+node supports 2048KiB and 1048576KiB page sizes, it will expose a schedulable
+resources `hugepages-2Mi` and `hugepages-1Gi`. Unlike CPU or memory, huge pages
+do not support overcommit. Note that when requesting hugepage resources, either
+memory or CPU resources must be requested as well.
+
+A pod may consume multiple huge page sizes in a single pod spec. In this case it
+must use `medium: HugePages-<hugepagesize>` notation for all volume mounts.
 --->
 
-用户可以通过在容器级别的资源需求中使用资源名称 `hugepages-<size>` 来使用巨页，其中的 size 是特定节点上支持的以整数值表示的最小二进制单位。 例如，如果节点支持 2048KiB 的页面规格， 它将暴露可供调度的资源 `hugepages-2Mi`。 与 CPU 或内存不同，巨页不支持过量使用（overcommit）。
-注意，在请求巨页资源时，还必须请求内存或 CPU 资源。
+用户可以通过在容器级别的资源需求中使用资源名称 `hugepages-<size>` 来使用巨页，其中的 size 是特定节点上支持的以整数值表示的最小二进制单位。 例如，如果一个节点支持 2048KiB 和 1048576KiB 页面大小，它将公开可调度的资源 `hugepages-2Mi` 和 `hugepages-1Gi`。与 CPU 或内存不同，巨页不支持过量使用（overcommit）。注意，在请求巨页资源时，还必须请求内存或 CPU 资源。
+
+同一 Pod 的 spec 中可能会消耗不同尺寸的巨页。在这种情况下，它必须对所有挂载卷使用 `medium: HugePages-<hugepagesize>` 标识。
 
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
-  generateName: hugepages-volume-
+  name: huge-pages-example
 spec:
   containers:
-  - image: fedora:latest
+  - name: example
+    image: fedora:latest
+    command:
+    - sleep
+    - inf
+    volumeMounts:
+    - mountPath: /hugepages-2Mi
+      name: hugepage-2mi
+    - mountPath: /hugepages-1Gi
+      name: hugepage-1gi
+    resources:
+      limits:
+        hugepages-2Mi: 100Mi
+        hugepages-1Gi: 2Gi
+        memory: 100Mi
+      requests:
+        memory: 100Mi
+  volumes:
+  - name: hugepage-2mi
+    emptyDir:
+      medium: HugePages-2Mi
+  - name: hugepage-1gi
+    emptyDir:
+      medium: HugePages-1Gi
+```
+<!--
+A pod may use `medium: HugePages` only if it requests huge pages of one size.
+-->
+Pod 只有在请求同一大小的巨页时才使用 `medium：HugePages`。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: huge-pages-example
+spec:
+  containers:
+  - name: example
+    image: fedora:latest
     command:
     - sleep
     - inf
-    name: example
     volumeMounts:
     - mountPath: /hugepages
       name: hugepage
@@ -89,8 +130,7 @@ spec:
 <!--
 - Huge page requests must equal the limits. This is the default if limits are
   specified, but requests are not.
-- Huge pages are isolated at a pod scope, container isolation is planned in a
-  future iteration.
+- Huge pages are isolated at a container scope, so each container has own limit on their cgroup sandbox as requested in a container spec.
 - EmptyDir volumes backed by huge pages may not consume more huge page memory
   than the pod request.
 - Applications that consume huge pages via `shmget()` with `SHM_HUGETLB` must
@@ -98,30 +138,25 @@ spec:
 - Huge page usage in a namespace is controllable via ResourceQuota similar
 to other compute resources like `cpu` or `memory` using the `hugepages-<size>`
 token.
+- Support of multiple sizes huge pages is feature gated. It can be
+  enabled with the `HugePageStorageMediumSize` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/) on the {{<
+glossary_tooltip text="kubelet" term_id="kubelet" >}} and {{<
+glossary_tooltip text="kube-apiserver"
+term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`).
 --->
 
 - 巨页的资源请求值必须等于其限制值。该条件在指定了资源限制，而没有指定请求的情况下默认成立。
-- 巨页是被隔离在 pod 作用域的，计划在将来的迭代中实现容器级别的隔离。
+- 巨页是被隔离在 pod 作用域的，因此每个容器在 spec 中都对 cgroup 沙盒有自己的限制。
 - 巨页可用于 EmptyDir 卷，不过 EmptyDir 卷所使用的巨页数量不能够超出 Pod 请求的巨页数量。
 - 通过带有 `SHM_HUGETLB` 的 `shmget()` 使用巨页的应用，必须运行在一个与
    `proc/sys/vm/hugetlb_shm_group` 匹配的补充组下。
 - 通过 ResourceQuota 资源，可以使用 `hugepages-<size>` 标记控制每个命名空间下的巨页使用量，
   类似于使用 `cpu` 或 `memory` 来控制其他计算资源。
-
-<!--
-## Future
-
-- Support container isolation of huge pages in addition to pod isolation.
-- NUMA locality guarantees as a feature of quality of service.
-- LimitRange support.
---->
-
-## 待实现的特性
-
-- 在 pod 级别隔离的基础上，支持巨页在容器级别的隔离。
-- 作为服务质量特性，保证巨页的 NUMA 局部性。
-- 支持 LimitRange 。
-
+- 多种尺寸的巨页的支持需要特性门控配置。它可以通过 `HugePageStorageMediumSize` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)在  {{<
+glossary_tooltip text="kubelet" term_id="kubelet" >}} 和 {{<
+glossary_tooltip text="kube-apiserver"
+term_id="kube-apiserver" >}} 中开启（`--feature-gates=HugePageStorageMediumSize=true`）。
 
 
 
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/_index.md b/content/zh/docs/tasks/manage-kubernetes-objects/_index.md
index 626a0ae5c8..88059fb9cd 100644
--- a/content/zh/docs/tasks/manage-kubernetes-objects/_index.md
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "管理 Kubernetes 对象"
 weight: 25
+description: 用声明式和命令式范型与 Kubernetes API 交互。
 ---
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md
new file mode 100644
index 0000000000..3ed8d41713
--- /dev/null
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -0,0 +1,1553 @@
+---
+title: 使用配置文件对 Kubernetes 对象进行声明式管理
+content_type: task
+weight: 10
+---
+<!--
+title: Declarative Management of Kubernetes Objects Using Configuration Files
+content_type: task
+weight: 10
+-->
+<!-- overview -->
+
+<!--
+Kubernetes objects can be created, updated, and deleted by storing multiple
+object configuration files in a directory and using `kubectl apply` to
+recursively create and update those objects as needed. This method
+retains writes made to live objects without merging the changes
+back into the object configuration files. `kubectl diff` also gives you a
+preview of what changes `apply` will make.
+-->
+你可以通过在一个目录中存储多个对象配置文件、并使用 `kubectl apply`
+来递归地创建和更新对象来创建、更新和删除 Kubernetes 对象。
+这种方法会保留对现有对象已作出的修改，而不会将这些更改写回到对象配置文件中。
+`kubectl diff` 也会给你呈现 `apply` 将作出的变更的预览。
+
+## {{% heading "prerequisites" %}}
+
+<!--
+Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+-->
+安装 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/)。
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+<!--
+## Trade-offs
+
+The `kubectl` tool supports three kinds of object management:
+
+* Imperative commands
+* Imperative object configuration
+* Declarative object configuration
+
+See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
+for a discussion of the advantages and disadvantage of each kind of object management.
+-->
+## 权衡取舍   {#trade-offs}
+
+`kubectl` 工具能够支持三种对象管理方式：
+
+* 指令式命令
+* 指令式对象配置
+* 声明式对象配置
+
+关于每种对象管理的优缺点的讨论，可参见
+[Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
+
+<!--
+## Overview
+
+Declarative object configuration requires a firm understanding of
+the Kubernetes object definitions and configuration. Read and complete
+the following documents if you have not already:
+
+* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+-->
+## 概览  {#overview}
+
+声明式对象管理需要用户对 Kubernetes 对象定义和配置有比较深刻的理解。
+如果你还没有这方面的知识储备，请先阅读下面的文档：
+
+* [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [使用配置文件对 Kubernetes 对象进行指令式管理](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
+
+<!--
+Following are definitions for terms used in this document:
+
+- *object configuration file / configuration file*: A file that defines the
+  configuration for a Kubernetes object. This topic shows how to pass configuration
+  files to `kubectl apply`. Configuration files are typically stored in source control, such as Git.
+- *live object configuration / live configuration*: The live configuration
+  values of an object, as observed by the Kubernetes cluster. These are kept in the Kubernetes
+  cluster storage, typically etcd.
+- *declarative configuration writer /  declarative writer*: A person or software component
+  that makes updates to a live object. The live writers referred to in this topic make changes
+  to object configuration files and run `kubectl apply` to write the changes.
+-->
+以下是本文档中使用的术语的定义：
+
+- *对象配置文件/配置文件*：一个定义 Kubernetes 对象的配置的文件。
+  本主题展示如何将配置文件传递给 `kubectl apply`。
+  配置文件通常存储于类似 Git 这种源码控制系统中。  
+- *现时对象配置/现时配置*：由 Kubernetes 集群所观测到的对象的现时配置值。
+  这些配置保存在 Kubernetes 集群存储（通常是 etcd）中。
+- *声明式配置写者/声明式写者*：负责更新现时对象的人或者软件组件。
+  本主题中的声明式写者负责改变对象配置文件并执行 `kubectl apply` 命令
+  以写入变更。
+
+<!--
+## How to create objects
+
+Use `kubectl apply` to create all objects, except those that already exist,
+defined by configuration files in a specified directory:
+
+```shell
+kubectl apply -f <directory>/
+```
+
+This sets the `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
+annotation on each object. The annotation contains the contents of the object
+configuration file that was used to create the object.
+-->
+## 如何创建对象 {#how-to-create-objects}
+
+使用 `kubectl apply` 来创建指定目录中配置文件所定义的所有对象，除非对应对象已经存在：
+
+```shell
+kubectl apply -f <目录>/
+```
+
+此操作会在每个对象上设置 `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
+注解。注解值中包含了用来创建对象的配置文件的内容。
+
+<!--
+Add the `-R` flag to recursively process directories.
+-->
+{{< note >}}
+添加 `-R` 标志可以递归地处理目录。
+{{< /note >}}
+
+<!--
+Here's an example of an object configuration file:
+-->
+下面是一个对象配置文件示例：
+
+{{< codenew file="application/simple_deployment.yaml" >}}
+
+<!--
+Run `kubectl diff` to print the object that will be created:
+-->
+执行 `kubectl diff` 可以打印出将被创建的对象：
+
+```shell
+kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+<!--
+`diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run),
+which needs to be enabled on `kube-apiserver`.
+
+Since `diff` performs a server-side apply request in dry-run mode,
+it requires granting `PATCH`, `CREATE`, and `UPDATE` permissions.
+See [Dry-Run Authorization](/docs/reference/using-api/api-concepts#dry-run-authorization)
+for details.
+-->
+{{< note >}}
+`diff` 使用[服务器端试运行（Server-side Dry-run）](/zh/docs/reference/using-api/api-concepts/#dry-run)
+功能特性；而该功能特性需要在 `kube-apiserver` 上启用。
+
+由于 `diff` 操作会使用试运行模式执行服务器端 apply 请求，因此需要为
+用户配置 `PATCH`、`CREATE` 和 `UPDATE` 操作权限。
+参阅[试运行授权](/zh/docs/reference/using-api/api-concepts#dry-run-authorization)
+了解详情。
+{{< /note >}}
+
+<!--
+Create the object using `kubectl apply`:
+-->
+使用 `kubectl apply` 来创建对象：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+<!--
+Print the live configuration using `kubectl get`:
+-->
+使用 `kubectl get` 打印其现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
+```
+
+<!--
+The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
+was written to the live configuration, and it matches the configuration file:
+-->
+输出显示注解 `kubectl.kubernetes.io/last-applied-configuration` 被写入到
+现时配置中，并且其内容与配置文件相同：
+
+```yaml
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # This is the json representation of simple_deployment.yaml
+    # It was written by kubectl apply when the object was created
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+  # ...
+spec:
+  # ...
+  minReadySeconds: 5
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.14.2
+        # ...
+        name: nginx
+        ports:
+        - containerPort: 80
+        # ...
+      # ...
+    # ...
+  # ...
+```
+
+<!--
+## How to update objects
+
+You can also use `kubectl apply` to update all objects defined in a directory, even
+if those objects already exist. This approach accomplishes the following:
+
+1. Sets fields that appear in the configuration file in the live configuration.
+2. Clears fields removed from the configuration file in the live configuration.
+
+```shell
+kubectl diff -f <directory>/
+kubectl apply -f <directory>/
+```
+-->
+## 如何更新对象   {#how-to-update-objects}
+
+你也可以使用 `kubectl apply` 来更新某个目录中定义的所有对象，即使那些对象已经存在。
+这一操作会隐含以下行为：
+
+1. 在现时配置中设置配置文件中出现的字段；
+2. 在现时配置中清除配置文件中已删除的字段。
+
+```shell
+kubectl diff -f <目录>/
+kubectl apply -f <目录>/
+```
+
+<!--
+Add the `-R` flag to recursively process directories.
+-->
+{{< note >}}
+使用 `-R` 标志递归处理目录。
+{{< /note >}}
+
+<!--
+Here's an example configuration file:
+-->
+下面是一个配置文件示例：
+
+{{< codenew file="application/simple_deployment.yaml" >}}
+
+<!--
+Create the object using `kubectl apply`:
+-->
+使用 `kubectl apply` 来创建对象：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+<!--
+For purposes of illustration, the preceding command refers to a single
+configuration file instead of a directory.
+-->
+{{< note >}}
+出于演示的目的，上面的命令引用的是单个文件而不是整个目录。
+{{< /note >}}
+
+<!--
+Print the live configuration using `kubectl get`:
+-->
+使用 `kubectl get` 打印现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
+```
+
+<!--
+The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
+was written to the live configuration, and it matches the configuration file:
+-->
+输出显示，注解 `kubectl.kubernetes.io/last-applied-configuration` 被写入到
+现时配置中，并且其取值与配置文件内容相同。
+
+```yaml
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # 此为 simple_deployment.yaml 的 JSON 表示
+    # 在对象创建时由 kubectl apply 命令写入
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+  # ...
+spec:
+  # ...
+  minReadySeconds: 5
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.14.2
+        # ...
+        name: nginx
+        ports:
+        - containerPort: 80
+        # ...
+      # ...
+    # ...
+  # ...
+```
+
+<!--
+Directly update the `replicas` field in the live configuration by using `kubectl scale`.
+This does not use `kubectl apply`:
+-->
+通过 `kubeclt scale` 命令直接更新现时配置中的 `replicas` 字段。
+这一命令没有使用 `kubectl apply`：
+
+```shell
+kubectl scale deployment/nginx-deployment --replicas=2
+```
+
+<!--
+Print the live configuration using `kubectl get`:
+-->
+使用 `kubectl get` 来打印现时配置：
+
+```shell
+kubectl get deployment nginx-deployment -o yaml
+```
+
+<!--
+The output shows that the `replicas` field has been set to 2, and the `last-applied-configuration`
+annotation does not contain a `replicas` field:
+-->
+输出显示，`replicas` 字段已经被设置为 2，而 `last-applied-configuration` 注解中
+并不包含 `replicas` 字段。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # 注意注解中并不包含 replicas
+    # 这是因为更新并不是通过 kubectl apply 来执行的
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+  # ...
+spec:
+  replicas: 2 # written by scale
+  # ...
+  minReadySeconds: 5
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.14.2
+        # ...
+        name: nginx
+        ports:
+        - containerPort: 80
+      # ...
+```
+
+<!--
+Update the `simple_deployment.yaml` configuration file to change the image from
+`nginx:1.14.2` to `nginx:1.16.1`, and delete the `minReadySeconds` field:
+-->
+现在更新 `simple_deployment.yaml` 配置文件，将镜像文件从
+`nginx:1.14.2` 更改为 `nginx:1.16.1`，同时删除`minReadySeconds` 字段：
+
+{{< codenew file="application/update_deployment.yaml" >}}
+
+<!--
+Apply the changes made to the configuration file:
+-->
+应用对配置文件所作更改：
+
+```shell
+kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml
+kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml
+```
+
+<!--
+Print the live configuration using `kubectl get`:
+-->
+使用 `kubectl get` 打印现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/update_deployment.yaml -o yaml
+```
+
+<!--
+The output shows the following changes to the live configuration:
+
+* The `replicas` field retains the value of 2 set by `kubectl scale`.
+  This is possible because it is omitted from the configuration file.
+* The `image` field has been updated to `nginx:1.16.1` from `nginx:1.14.2`.
+* The `last-applied-configuration` annotation has been updated with the new image.
+* The `minReadySeconds` field has been cleared.
+* The `last-applied-configuration` annotation no longer contains the `minReadySeconds` field.
+-->
+输出显示现时配置中发生了以下更改：
+
+* 字段 `replicas` 保留了 `kubectl scale` 命令所设置的值：2；
+  之所以该字段被保留是因为配置文件中并没有设置 `replicas`。
+* 字段 `image` 的内容已经从 `nginx:1.14.2` 更改为 `nginx:1.16.1`。
+* 注解 `last-applied-configuration` 内容被更改为新的镜像名称。
+* 字段 `minReadySeconds` 被移除。
+* 注解 `last-applied-configuration` 中不再包含 `minReadySeconds` 字段。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # 注解中包含更新后的镜像 nginx 1.16.1
+    # 但是其中并不包含更改后的 replicas 值 2
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+    # ...
+spec:
+  replicas: 2 # 由 `kubectl scale` 设置，被 `kubectl apply` 命令忽略
+  # minReadySeconds 被 `kubectl apply` 清除
+  # ...
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.16.1 # 由 `kubectl apply` 设置
+        # ...
+        name: nginx
+        ports:
+        - containerPort: 80
+        # ...
+      # ...
+    # ...
+  # ...
+```
+
+<!--
+Mixing `kubectl apply` with the imperative object configuration commands
+`create` and `replace` is not supported. This is because `create`
+and `replace` do not retain the `kubectl.kubernetes.io/last-applied-configuration`
+that `kubectl apply` uses to compute updates.
+-->
+{{< warning >}}
+将 `kubectl apply` 与指令式对象配置命令 `kubectl create` 或 `kubectl replace`
+混合使用是不受支持的。这是因为 `create` 和 `replace` 命令都不会保留
+`kubectl apply` 用来计算更新内容所使用的
+ `kubectl.kubernetes.io/last-applied-configuration` 注解值。
+{{< /warning >}}
+
+<!--
+## How to delete objects
+
+There are two approaches to delete objects managed by `kubectl apply`.
+
+### Recommended: `kubectl delete -f <filename>`
+
+Manually deleting objects using the imperative command is the recommended
+approach, as it is more explicit about what is being deleted, and less likely
+to result in the user deleting something unintentionally:
+
+```shell
+kubectl delete -f <filename>
+```
+-->
+## 如何删除对象  {#how-to-delete-objects}
+
+有两种方法来删除 `kubectl apply` 管理的对象。
+
+### 建议操作：`kubectl delete -f <文件名>`
+
+使用指令式命令来手动删除对象是建议的方法，因为这种方法更为明确地给出了
+要删除的内容是什么，且不容易造成用户不小心删除了其他对象的情况。
+
+```shell
+kubectl delete -f <文件名>
+```
+
+<!--
+### Alternative: `kubectl apply -f <directory/> -prune -l your=label`
+
+Only use this if you know what you are doing.
+-->
+### 替代方式：`kubectl apply -f <目录名称/> --prune -l your=label`
+
+只有在充分理解此命令背后含义的情况下才建议这样操作。
+
+<!--
+`kubectl apply -prune` is in alpha, and backwards incompatible
+changes might be introduced in subsequent releases.
+-->
+{{< warning >}}
+`kubectl apply --prune` 命令本身仍处于 Alpha 状态，在后续发布版本中可能会
+引入一些向后不兼容的变化。
+{{< /warning >}}
+
+{{< warning >}}
+在使用此命令时必须小心，这样才不会无意中删除不想删除的对象。
+{{< /warning >}}
+
+<!--
+As an alternative to `kubectl delete`, you can use `kubectl apply` to identify objects to be deleted after their
+configuration files have been removed from the directory. Apply with `-prune`
+queries the API server for all objects matching a set of labels, and attempts
+to match the returned live object configurations against the object
+configuration files. If an object matches the query, and it does not have a
+configuration file in the directory, and it has a `last-applied-configuration` annotation,
+it is deleted.
+-->
+作为 `kubectl delete` 操作的替代方式，你可以在目录中对象配置文件被删除之后，
+使用 `kubectl apply` 来辩识要删除的对象。
+带 `--prune` 标志的 `apply` 命令会首先查询 API 服务器，获得与某组标签相匹配
+的对象列表，之后将返回的现时对象配置与目录中的对象配置文件相比较。
+如果某对象在查询中被匹配到，但在目录中没有文件与其相对应，并且其中还包含
+`last-applied-configuration` 注解，则该对象会被删除。 
+
+```shell
+kubectl apply -f <directory/> --prune -l <labels>
+```
+
+<!--
+Apply with prune should only be run against the root directory
+containing the object configuration files. Running against sub-directories
+can cause objects to be unintentionally deleted if they are returned
+by the label selector query specified with `-l <labels>` and
+do not appear in the subdirectory.
+-->
+{{< warning >}}
+带剪裁（prune）行为的 `apply` 操作应在包含对象配置文件的目录的根目录运行。
+如果在其子目录中运行，可能导致对象被不小心删除。
+因为某些对象可能与 `-l <标签>` 的标签选择算符匹配，但其配置文件不在当前
+子目录下。
+{{< /warning >}}
+
+<!--
+## How to view an object
+
+You can use `kubectl get` with `-o yaml` to view the configuration of a live object:
+
+```shell
+kubectl get -f <filename|url> -o yaml
+```
+-->
+## 如何查看对象  {#how-to-view-an-object}
+
+你可以使用 `kubectl get` 并指定 `-o yaml` 选项来查看现时对象的配置：
+
+```shell
+kubectl get -f <文件名 | URL> -o yaml
+```
+
+<!--
+## How apply calculates differences and merges changes
+
+A *patch* is an update operation that is scoped to specific fields of an object
+instead of the entire object. This enables updating only a specific set of fields
+on an object without reading the object first.
+-->
+## apply 操作是如何计算配置差异并合并变更的？
+
+{{< caution >}}
+*patch* 是一种更新操作，其作用域为对象的一些特定字段而不是整个对象。
+这使得你可以更新对象的特定字段集合而不必先要读回对象。
+{{< /caution >}}
+
+<!--
+When `kubectl apply` updates the live configuration for an object,
+it does so by sending a patch request to the API server. The
+patch defines updates scoped to specific fields of the live object
+configuration. The `kubectl apply` command calculates this patch request
+using the configuration file, the live configuration, and the
+`last-applied-configuration` annotation stored in the live configuration.
+-->
+`kubectl apply` 更新对象的现时配置，它是通过向 API 服务器发送一个 patch 请求
+来执行更新动作的。
+所提交的补丁中定义了对现时对象配置中特定字段的更新。
+`kubectl apply` 命令会使用当前的配置文件、现时配置以及现时配置中保存的
+`last-applied-configuration` 注解内容来计算补丁更新内容。
+
+<!--
+### Merge patch calculation
+
+The `kubectl apply` command writes the contents of the configuration file to the
+`kubectl.kubernetes.io/last-applied-configuration` annotation. This
+is used to identify fields that have been removed from the configuration
+file and need to be cleared from the live configuration. Here are the steps used
+to calculate which fields should be deleted or set:
+-->
+### 合并补丁计算  {#merge-patch-calculation}
+
+`kubectl apply` 命令将配置文件的内容写入到
+`kubectl.kubernetes.io/last-applied-configuration` 注解中。
+这些内容用来识别配置文件中已经移除的、因而也需要从现时配置中删除的字段。
+用来计算要删除或设置哪些字段的步骤如下：
+
+<!--
+1. Calculate the fields to delete. These are the fields present in `last-applied-configuration` and missing from the configuration file.
+2. Calculate the fields to add or set. These are the fields present in the configuration file whose values don't match the live configuration.
+
+Here's an example. Suppose this is the configuration file for a Deployment object:
+-->
+1. 计算要删除的字段，即在 `last-applied-configuration` 中存在但在
+   配置文件中不再存在的字段。
+2. 计算要添加或设置的字段，即在配置文件中存在但其取值与现时配置不同的字段。
+
+下面是一个例子。假定此文件是某 Deployment 对象的配置文件：
+
+{{< codenew file="application/update_deployment.yaml" >}}
+
+<!--
+Also, suppose this is the live configuration for the same Deployment object:
+-->
+同时假定同一 Deployment 对象的现时配置如下：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+  # ...
+spec:
+  replicas: 2
+  # ...
+  minReadySeconds: 5
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.14.2
+        # ...
+        name: nginx
+        ports:
+        - containerPort: 80
+      # ...
+```
+
+<!--
+Here are the merge calculations that would be performed by `kubectl apply`:
+
+1. Calculate the fields to delete by reading values from
+   `last-applied-configuration` and comparing them to values in the
+   configuration file.
+   Clear fields explicitly set to null in the local object configuration file
+   regardless of whether they appear in the `last-applied-configuration`.
+   In this example, `minReadySeconds` appears in the
+   `last-applied-configuration` annotation, but does not appear in the configuration file.
+    **Action:** Clear `minReadySeconds` from the live configuration.
+2. Calculate the fields to set by reading values from the configuration
+   file and comparing them to values in the live configuration. In this example,
+   the value of `image` in the configuration file does not match
+    the value in the live configuration. **Action:** Set the value of `image` in the live configuration.
+3. Set the `last-applied-configuration` annotation to match the value
+   of the configuration file.
+4. Merge the results from 1, 2, 3 into a single patch request to the API server.
+
+Here is the live configuration that is the result of the merge:
+-->
+下面是 `kubectl apply` 将执行的合并计算：
+
+1. 通过读取 `last-applied-configuration` 并将其与配置文件中的值相比较，
+   计算要删除的字段。
+   对于本地对象配置文件中显式设置为空的字段，清除其在现时配置中的设置，
+   无论这些字段是否出现在 `last-applied-configuration` 中。
+   在此例中，`minReadySeconds` 出现在 `last-applied-configuration` 注解中，但
+   并不存在于配置文件中。
+   **动作：** 从现时配置中删除 `minReadySeconds` 字段。
+2. 通过读取配置文件中的值并将其与现时配置相比较，计算要设置的字段。
+   在这个例子中，配置文件中的 `image` 值与现时配置中的 `image` 不匹配。
+   **动作**：设置现时配置中的 `image` 值。
+3. 设置 `last-applied-configuration` 注解的内容，使之与配置文件匹配。
+4. 将第 1、2、3 步骤得出的结果合并，构成向 API 服务器发送的补丁请求内容。
+
+下面是此合并操作之后形成的现时配置：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # 注解中包含更新后的 image，nginx 1.11.9,
+    # 但不包含更新后的 replicas
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+    # ...
+spec:
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  replicas: 2
+  # minReadySeconds  此字段被清除
+  # ...
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.16.1
+        # ...
+        name: nginx
+        ports:
+        - containerPort: 80
+        # ...
+      # ...
+    # ...
+  # ...
+```
+
+<!--
+### How different types of fields are merged
+
+How a particular field in a configuration file is merged with
+the live configuration depends on the
+type of the field. There are several types of fields:
+-->
+### 不同类型字段的合并方式
+
+配置文件中的特定字段与现时配置合并时，合并方式取决于字段类型。
+字段类型有几种：
+
+<!--
+- *primitive*: A field of type string, integer, or boolean.
+  For example, `image` and `replicas` are primitive fields. **Action:** Replace.
+
+- *map*, also called *object*: A field of type map or a complex type that contains subfields. For example, `labels`,
+  `annotations`,`spec` and `metadata` are all maps. **Action:** Merge elements or subfields.
+
+- *list*: A field containing a list of items that can be either primitive types or maps.
+  For example, `containers`, `ports`, and `args` are lists. **Action:** Varies.
+-->
+- *基本类型*：字段类型为 `string`、`integer` 或 `boolean` 之一。
+  例如：`image` 和 `replicas` 字段都是基本类型字段。
+
+  **动作：** 替换。
+
+- *map*：也称作 *object*。类型为 `map` 或包含子域的复杂结构。例如，`labels`、
+  `annotations`、`spec` 和 `metadata` 都是 map。
+
+  **动作：** 合并元素或子字段。
+
+- *list*：包含元素列表的字段，其中每个元素可以是基本类型或 map。
+  例如，`containers`、`ports` 和 `args` 都是 list。
+
+  **动作：** 不一定。
+
+<!--
+When `kubectl apply` updates a map or list field, it typically does
+not replace the entire field, but instead updates the individual subelements.
+For instance, when merging the `spec` on a Deployment, the entire `spec` is
+not replaced. Instead the subfields of `spec`, such as `replicas`, are compared
+and merged.
+-->
+当 `kubectl apply` 更新某个 map 或 list 字段时，它通常不会替换整个字段，而是会
+更新其中的各个子元素。例如，当合并 Deployment 的 `spec` 时，`kubectl` 并不会
+将其整个替换掉。相反，实际操作会是对 `replicas` 这类 `spec`
+的子字段来执行比较和更新。
+
+<!--
+### Merging changes to primitive fields
+
+Primitive fields are replaced or cleared.
+-->
+### 合并对基本类型字段的更新
+
+基本类型字段会被替换或清除。
+
+<!--
+`-` is used for "not applicable" because the value is not used.
+-->
+{{< note >}}
+`-` 表示的是“不适用”，因为指定数值未被使用。
+{{< /note >}}
+
+| 字段在对象配置文件中  | 字段在现时对象配置中 | 字段在 `last-applied-configuration` 中 | 动作 |
+|-----------------------|----------------------|----------------------------------------|------|
+| 是 | 是 | -  | 将配置文件中值设置到现时配置上。 |
+| 是 | 否 | -  | 将配置文件中值设置到现时配置上。 |
+| 否 | -  | 是 | 从现时配置中移除。 |
+| 否 | -  | 否 | 什么也不做。保持现时值。 |
+
+<!--
+### Merging changes to map fields
+
+Fields that represent maps are merged by comparing each of the subfields or elements of the map:
+-->
+### 合并对 map 字段的变更
+
+用来表示映射的字段在合并时会逐个子字段或元素地比较：
+
+<!--
+`-` is used for "not applicable" because the value is not used.
+-->
+{{< note >}}
+`-` 表示的是“不适用”，因为指定数值未被使用。
+{{< /note >}}
+
+| 键存在于对象配置文件中 | 键存在于现时对象配置中 | 键存在于 `last-applied-configuration` 中 | 动作 |
+|------------------------|------------------------|------------------------------------------|------|
+| 是 | 是 | -  | 比较子域取值。 |
+| 是 | 否 | -  | 将现时配置设置为本地配置值。 |
+| 否 | -  | 是 | 从现时配置中删除键。 |
+| 否 | -  | 否 | 什么也不做，保留现时值。 |
+
+<!--
+### Merging changes for fields of type list
+
+Merging changes to a list uses one of three strategies:
+
+* Replace the list if all its elements are primitives.
+* Merge individual elements in a list of complex elements.
+* Merge a list of primitive elements.
+
+The choice of strategy is made on a per-field basis.
+-->
+### 合并 list 类型字段的变更
+
+对 list 类型字段的变更合并会使用以下三种策略之一：
+
+* 如果 list 所有元素都是基本类型则替换整个 list。
+* 如果 list 中元素是复合结构则逐个元素执行合并操作。
+* 合并基本类型元素构成的 list。
+
+策略的选择是基于各个字段做出的。
+
+<!--
+#### Replace the list if all its elements are primitives
+
+Treat the list the same as a primitive field. Replace or delete the
+entire list. This preserves ordering.
+-->
+#### 如果 list 中元素都是基本类型则替换整个 list
+
+将整个 list 视为一个基本类型字段。或者整个替换或者整个删除。
+此操作会保持 list 中元素顺序不变
+
+<!--
+**Example:** Use `kubectl apply` to update the `args` field of a Container in a Pod. This sets
+the value of `args` in the live configuration to the value in the configuration file.
+Any `args` elements that had previously been added to the live configuration are lost.
+The order of the `args` elements defined in the configuration file is
+retained in the live configuration.
+-->
+**示例：** 使用 `kubectl apply` 来更新 Pod 中 Container 的 `args` 字段。此操作会
+将现时配置中的 `args` 值设为配置文件中的值。
+所有之前添加到现时配置中的 `args` 元素都会丢失。
+配置文件中的 `args` 元素的顺序在被添加到现时配置中时保持不变。
+
+<!--
+```yaml
+# last-applied-configuration value
+    args: ["a", "b"]
+
+# configuration file value
+    args: ["a", "c"]
+
+# live configuration
+    args: ["a", "b", "d"]
+
+# result after merge
+    args: ["a", "c"]
+```
+-->
+```yaml
+# last-applied-configuration 值
+    args: ["a", "b"]
+
+# 配置文件值
+    args: ["a", "c"]
+
+# 现时配置
+    args: ["a", "b", "d"]
+
+# 合并结果
+    args: ["a", "c"]
+```
+
+<!--
+**Explanation:** The merge used the configuration file value as the new list value.
+-->
+**解释：** 合并操作将配置文件中的值当做新的 list 值。
+
+<!--
+#### Merge individual elements of a list of complex elements:
+
+Treat the list as a map, and treat a specific field of each element as a key.
+Add, delete, or update individual elements. This does not preserve ordering.
+-->
+#### 如果 list 中元素为复合类型则逐个执行合并
+
+此操作将 list 视为 map，并将每个元素中的特定字段当做其主键。
+逐个元素地执行添加、删除或更新操作。结果顺序无法得到保证。
+
+<!--
+This merge strategy uses a special tag on each field called a `patchMergeKey`. The
+`patchMergeKey` is defined for each field in the Kubernetes source code:
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747)
+When merging a list of maps, the field specified as the `patchMergeKey` for a given element
+is used like a map key for that element.
+
+**Example:** Use `kubectl apply` to update the `containers` field of a PodSpec.
+This merges the list as though it was a map where each element is keyed
+by `name`.
+-->
+此合并策略会使用每个字段上的一个名为 `patchMergeKey` 的特殊标签。
+Kubernetes 源代码中为每个字段定义了 `patchMergeKey`：
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747)
+当合并由 map 组成的 list 时，给定元素中被设置为 `patchMergeKey` 的字段会被
+当做该元素的 map 键值来使用。
+
+**例如：** 使用 `kubectl apply` 来更新 Pod 规约中的 `containers` 字段。
+此操作会将 `containers` 列表视作一个映射来执行合并，每个元素的主键为 `name`。
+
+<!--
+```yaml
+# last-applied-configuration value
+    containers:
+    - name: nginx
+      image: nginx:1.16
+    - name: nginx-helper-a # key: nginx-helper-a; will be deleted in result
+      image: helper:1.3
+    - name: nginx-helper-b # key: nginx-helper-b; will be retained
+      image: helper:1.3
+
+# configuration file value
+    containers:
+    - name: nginx
+      image: nginx:1.16
+    - name: nginx-helper-b
+      image: helper:1.3
+    - name: nginx-helper-c # key: nginx-helper-c; will be added in result
+      image: helper:1.3
+
+# live configuration
+    containers:
+    - name: nginx
+      image: nginx:1.16
+    - name: nginx-helper-a
+      image: helper:1.3
+    - name: nginx-helper-b
+      image: helper:1.3
+      args: ["run"] # Field will be retained
+    - name: nginx-helper-d # key: nginx-helper-d; will be retained
+      image: helper:1.3
+
+# result after merge
+    containers:
+    - name: nginx
+      image: nginx:1.16
+      # Element nginx-helper-a was deleted
+    - name: nginx-helper-b
+      image: helper:1.3
+      args: ["run"] # Field was retained
+    - name: nginx-helper-c # Element was added
+      image: helper:1.3
+    - name: nginx-helper-d # Element was ignored
+      image: helper:1.3
+```
+-->
+```yaml
+# last-applied-configuration 值
+    containers:
+    - name: nginx
+      image: nginx:1.16
+    - name: nginx-helper-a # 键 nginx-helper-a 会被删除
+      image: helper:1.3
+    - name: nginx-helper-b # 键 nginx-helper-b 会被保留
+      image: helper:1.3
+
+# 配置文件值
+    containers:
+    - name: nginx
+      image: nginx:1.16
+    - name: nginx-helper-b
+      image: helper:1.3
+    - name: nginx-helper-c # 键 nginx-helper-c 会被添加
+      image: helper:1.3
+
+# 现时配置
+    containers:
+    - name: nginx
+      image: nginx:1.16
+    - name: nginx-helper-a
+      image: helper:1.3
+    - name: nginx-helper-b
+      image: helper:1.3
+      args: ["run"]        # 字段会被保留
+    - name: nginx-helper-d # 键 nginx-helper-d 会被保留
+      image: helper:1.3
+
+# 合并结果
+    containers:
+    - name: nginx
+      image: nginx:1.16
+      # 元素 nginx-helper-a 被删除
+    - name: nginx-helper-b
+      image: helper:1.3
+      args: ["run"]        # 字段被保留
+    - name: nginx-helper-c # 新增元素
+      image: helper:1.3
+    - name: nginx-helper-d # 此元素被忽略（保留）
+      image: helper:1.3
+```
+
+<!--
+**Explanation:**
+
+- The container named "nginx-helper-a" was deleted because no container
+  named "nginx-helper-a" appeared in the configuration file.
+- The container named "nginx-helper-b" retained the changes to `args`
+  in the live configuration. `kubectl apply` was able to identify
+  that "nginx-helper-b" in the live configuration was the same
+  "nginx-helper-b" as in the configuration file, even though their fields
+  had different values (no `args` in the configuration file). This is
+  because the `patchMergeKey` field value (name) was identical in both.
+- The container named "nginx-helper-c" was added because no container
+  with that name appeared in the live configuration, but one with
+  that name appeared in the configuration file.
+- The container named "nginx-helper-d" was retained because
+  no element with that name appeared in the last-applied-configuration.
+-->
+**解释：**
+
+- 名为 "nginx-helper-a" 的容器被删除，因为配置文件中不存在同名的容器。
+- 名为 "nginx-helper-b" 的容器的现时配置中的 `args` 被保留。
+  `kubectl apply` 能够辩识出现时配置中的容器 "nginx-helper-b" 与配置文件
+  中的容器 "nginx-helper-b" 相同，即使它们的字段值有些不同（配置文件中未给定
+  `args` 值）。这是因为 `patchMergeKey` 字段（name）的值在两个版本中都一样。
+- 名为 "nginx-helper-c" 的容器是新增的，因为在配置文件中的这个容器尚不存在
+  于现时配置中。
+- 名为 "nginx-helper-d" 的容器被保留下来，因为在 last-applied-configuration
+  中没有与之同名的元素。
+
+<!--
+#### Merge a list of primitive elements
+
+As of Kubernetes 1.5, merging lists of primitive elements is not supported.
+-->
+#### 合并基本类型元素 list
+
+在 Kubernetes 1.5 中，尚不支持对由基本类型元素构成的 list 进行合并。
+
+<!--
+Which of the above strategies is chosen for a given field is controlled by
+the `patchStrategy` tag in [types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)
+If no `patchStrategy` is specified for a field of type list, then
+the list is replaced.
+-->
+{{< note >}}
+选择上述哪种策略是由源码中给定字段的 `patchStrategy` 标记来控制的： 
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)
+如果 list 类型字段未设置 `patchStrategy`，则整个 list 会被替换掉。
+{{< /note >}}
+
+{{< comment >}}
+TODO(pwittrock): Uncomment this for 1.6
+
+- Treat the list as a set of primitives.  Replace or delete individual
+  elements.  Does not preserve ordering.  Does not preserve duplicates.
+
+**Example:** Using apply to update the `finalizers` field of ObjectMeta
+keeps elements added to the live configuration.  Ordering of finalizers
+is lost.
+{{< /comment >}}
+
+<!--
+## Default field values
+
+The API server sets certain fields to default values in the live configuration if they are
+not specified when the object is created.
+
+Here's a configuration file for a Deployment. The file does not specify `strategy`:
+-->
+## 默认字段值  {#default-field-values}
+
+API 服务器会在对象创建时其中某些字段未设置的情况下在现时配置中为其设置默认值。
+
+下面是一个 Deployment 的配置文件。文件未设置 `strategy`：
+
+{{< codenew file="application/simple_deployment.yaml" >}}
+
+<!--
+Create the object using `kubectl apply`:
+-->
+使用 `kubectl apply` 创建对象：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
+```
+
+<!--
+Print the live configuration using `kubectl get`:
+-->
+使用 `kubectl get` 打印现时配置：
+
+```shell
+kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
+```
+
+<!--
+The output shows that the API server set several fields to default values in the live
+configuration. These fields were not specified in the configuration file.
+-->
+输出显示 API 在现时配置中为某些字段设置了默认值。
+这些字段在配置文件中并未设置。
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+# ...
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  minReadySeconds: 5
+  replicas: 1           # API 服务器所设默认值
+  strategy:
+    rollingUpdate:      # API 服务器基于 strategy.type 所设默认值
+      maxSurge: 1
+      maxUnavailable: 1
+    type: RollingUpdate # API 服务器所设默认值
+  template:
+    metadata:
+      creationTimestamp: null
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.14.2
+        imagePullPolicy: IfNotPresent    # API 服务器所设默认值
+        name: nginx
+        ports:
+        - containerPort: 80
+          protocol: TCP       # API 服务器所设默认值
+        resources: {}         # API 服务器所设默认值
+        terminationMessagePath: /dev/termination-log    # API 服务器所设默认值
+      dnsPolicy: ClusterFirst       # API 服务器所设默认值
+      restartPolicy: Always         # API 服务器所设默认值
+      securityContext: {}           # API 服务器所设默认值
+      terminationGracePeriodSeconds: 30        # API 服务器所设默认值
+# ...
+```
+
+<!--
+In a patch request, defaulted fields are not re-defaulted unless they are explicitly cleared
+as part of a patch request. This can cause unexpected behavior for
+fields that are defaulted based
+on the values of other fields. When the other fields are later changed,
+the values defaulted from them will not be updated unless they are
+explicitly cleared.
+-->
+在补丁请求中，已经设置了默认值的字段不会被重新设回其默认值，除非
+在补丁请求中显式地要求清除。对于默认值取决于其他字段的某些字段而言，
+这可能会引发一些意想不到的行为。当所依赖的其他字段后来发生改变时，
+基于它们所设置的默认值只能在显式执行清除操作时才会被更新。
+
+<!--
+For this reason, it is recommended that certain fields defaulted
+by the server are explicitly defined in the configuration file, even
+if the desired values match the server defaults. This makes it
+easier to recognize conflicting values that will not be re-defaulted
+by the server.
+
+**Example:**
+-->
+为此，建议在配置文件中为服务器设置默认值的字段显式提供定义，即使所
+给的定义与服务器端默认值设定相同。这样可以使得辩识无法被服务器重新
+基于默认值来设置的冲突字段变得容易。
+
+**示例：**
+
+```yaml
+# last-applied-configuration
+spec:
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+
+# 配置文件
+spec:
+  strategy:
+    type: Recreate   # 更新的值
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+
+# 现时配置
+spec:
+  strategy:
+    type: RollingUpdate    # 默认设置的值
+    rollingUpdate:         # 基于 type 设置的默认值
+      maxSurge : 1
+      maxUnavailable: 1
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+
+# 合并后的结果 - 出错！
+spec:
+  strategy:
+    type: Recreate     # 更新的值：与 rollingUpdate 不兼容
+    rollingUpdate:     # 默认设置的值：与 "type: Recreate" 冲突
+      maxSurge : 1
+      maxUnavailable: 1
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+```
+
+<!--
+**Explanation:**
+
+1. The user creates a Deployment without defining `strategy.type`.
+2. The server defaults `strategy.type` to `RollingUpdate` and defaults the
+   `strategy.rollingUpdate` values.
+3. The user changes `strategy.type` to `Recreate`. The `strategy.rollingUpdate`
+   values remain at their defaulted values, though the server expects them to be cleared.
+   If the `strategy.rollingUpdate` values had been defined initially in the configuration file,
+   it would have been more clear that they needed to be deleted.
+4. Apply fails because `strategy.rollingUpdate` is not cleared. The `strategy.rollingupdate`
+   field cannot be defined with a `strategy.type` of `Recreate`.
+-->
+**解释：**
+
+1. 用户创建 Deployment，未设置 `strategy.type`。
+2. 服务器为 `strategy.type` 设置默认值 `RollingUpdate`，并为 `strategy.rollingUpdate`
+   设置默认值。
+3. 用户改变 `strategy.type` 为 `Recreate`。字段 `strategy.rollingUpdate` 仍会取其
+   默认设置值，尽管服务器期望该字段被清除。
+   如果 `strategy.rollingUpdate` 值最初于配置文件中定义，则它们需要被清除
+   这一点就更明确一些。
+4. `apply` 操作失败，因为 `strategy.rollingUpdate` 未被清除。
+   `strategy.rollingupdate` 在 `strategy.type` 为 `Recreate` 不可被设定。
+
+<!--
+Recommendation: These fields should be explicitly defined in the object configuration file:
+
+- Selectors and PodTemplate labels on workloads, such as Deployment, StatefulSet, Job, DaemonSet,
+  ReplicaSet, and ReplicationController
+- Deployment rollout strategy
+-->
+建议：以下字段应该在对象配置文件中显式定义：
+
+- 如 Deployment、StatefulSet、Job、DaemonSet、ReplicaSet 和 ReplicationController
+  这类负载的选择算符和 `PodTemplate` 标签
+- Deployment 的上线策略
+
+<!--
+### How to clear server-defaulted fields or fields set by other writers
+
+Fields that do not appear in the configuration file can be cleared by
+setting their values to `null` and then applying the configuration file.
+For fields defaulted by the server, this triggers re-defaulting
+the values.
+-->
+### 如何清除服务器端按默认值设置的字段或者被其他写者设置的字段
+
+没有出现在配置文件中的字段可以通过将其值设置为 `null` 并应用配置文件来清除。
+对于由服务器按默认值设置的字段，清除操作会触发重新为字段设置新的默认值。
+
+<!--
+## How to change ownership of a field between the configuration file and direct imperative writers
+
+These are the only methods you should use to change an individual object field:
+
+- Use `kubectl apply`.
+- Write directly to the live configuration without modifying the configuration file:
+for example, use `kubectl scale`.
+-->
+## 如何将字段的属主在配置文件和直接指令式写者之间切换
+
+更改某个对象字段时，应该采用下面的方法：
+
+- 使用 `kubectl apply`.
+- 直接写入到现时配置，但不更改配置文件本身，例如使用 `kubectl scale`。
+
+<!--
+### Changing the owner from a direct imperative writer to a configuration file
+
+Add the field to the configuration file. For the field, discontinue direct updates to
+the live configuration that do not go through `kubectl apply`.
+-->
+### 将属主从直接指令式写者更改为配置文件
+
+将字段添加到配置文件。针对该字段，不再直接执行对现时配置的修改。
+修改均通过 `kubectl apply` 来执行。
+
+<!--
+### Changing the owner from a configuration file to a direct imperative writer
+
+As of Kubernetes 1.5, changing ownership of a field from a configuration file to
+an imperative writer requires manual steps:
+
+- Remove the field from the configuration file.
+- Remove the field from the `kubectl.kubernetes.io/last-applied-configuration` annotation on the live object.
+-->
+### 将属主从配置文件改为直接指令式写者
+
+在 Kubernetes 1.5 中，将字段的属主从配置文件切换到某指令式写者需要手动
+执行以下步骤：
+
+- 从配置文件中删除该字段；
+- 将字段从现时对象的 `kubectl.kubernetes.io/last-applied-configuration` 注解
+  中删除。
+
+<!--
+## Changing management methods
+
+Kubernetes objects should be managed using only one method at a time.
+Switching from one method to another is possible, but is a manual process.
+-->
+## 更改管理方法  {#changing-management-methods} 
+
+Kubernetes 对象在同一时刻应该只用一种方法来管理。
+从一种方法切换到另一种方法是可能的，但这一切换是一个手动过程。
+
+<!--
+It is OK to use imperative deletion with declarative management.
+-->
+{{< note >}}
+在声明式管理方法中使用指令式命令来删除对象是可以的。
+{{< /note >}}
+
+<!--
+### Migrating from imperative command management to declarative object configuration
+
+Migrating from imperative command management to declarative object
+configuration involves several manual steps:
+-->
+### 从指令式命令管理切换到声明式对象配置
+
+从指令式命令管理切换到声明式对象配置管理的切换包含以下几个手动步骤：
+<!--
+1. Export the live object to a local configuration file:
+
+     ```shell
+     kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
+     ```
+
+1. Manually remove the `status` field from the configuration file.
+
+    {{< note >}}
+    This step is optional, as `kubectl apply` does not update the status field
+    even if it is present in the configuration file.
+    {{< /note >}}
+
+1. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
+
+    ```shell
+    kubectl replace -save-config -f <kind>_<name>.yaml
+    ```
+
+1. Change processes to use `kubectl apply` for managing the object exclusively.
+-->
+1. 将现时对象导出到本地配置文件：
+
+   ```shell
+   kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
+   ```
+
+1. 手动移除配置文件中的 `status` 字段。
+
+   <!--
+   This step is optional, as `kubectl apply` does not update the status field
+   even if it is present in the configuration file.
+   -->
+   {{< note >}}
+   这一步骤是可选的，因为 `kubectl apply` 并不会更新 status 字段，即便
+   配置文件中包含 status 字段。
+   {{< /note >}}
+
+1. 设置对象上的 `kubectl.kubernetes.io/last-applied-configuration` 注解：
+
+   ```shell
+   kubectl replace --save-config -f <kind>_<name>.yaml
+   ```
+
+<!--
+### Migrating from imperative object configuration to declarative object configuration
+
+1. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
+
+    ```shell
+    kubectl replace -save-config -f <kind>_<name>.yaml
+    ```
+
+1. Change processes to use `kubectl apply` for managing the object exclusively.
+-->
+### 从指令式对象配置切换到声明式对象配置
+
+1. 在对象上设置 `kubectl.kubernetes.io/last-applied-configuration` 注解： 
+
+    ```shell
+    kubectl replace -save-config -f <kind>_<name>.yaml
+    ```
+
+1. 自此排他性地使用 `kubectl apply` 来管理对象。
+
+<!--
+## Defining controller selectors and PodTemplate labels
+-->
+## 定义控制器选择算符和 PodTemplate 标签
+
+<!--
+Updating selectors on controllers is strongly discouraged.
+-->
+{{< warning >}}
+强烈不建议更改控制器上的选择算符。
+{{< /warning >}}
+
+<!--
+The recommended approach is to define a single, immutable PodTemplate label
+used only by the controller selector with no other semantic meaning.
+
+**Example:**
+-->
+建议的方法是定义一个不可变更的 PodTemplate 标签，仅用于控制器选择算符且
+不包含其他语义性的含义。
+
+**示例：**
+
+```yaml
+selector:
+  matchLabels:
+      controller-selector: "apps/v1/deployment/nginx"
+template:
+  metadata:
+    labels:
+      controller-selector: "apps/v1/deployment/nginx"
+```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+-->
+* [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [使用配置文件对 Kubernetes 对象执行指令式管理](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/zh/docs/tasks/manage-kubernetes-objects/imperative-command.md
new file mode 100644
index 0000000000..5396621680
--- /dev/null
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -0,0 +1,294 @@
+---
+title: 使用指令式命令管理 Kubernetes 对象
+content_type: task
+weight: 30
+---
+<!--
+title: Managing Kubernetes Objects Using Imperative Commands
+content_type: task
+weight: 30
+-->
+<!-- overview -->
+
+<!--
+Kubernetes objects can quickly be created, updated, and deleted directly using
+imperative commands built into the `kubectl` command-line tool. This document
+explains how those commands are organized and how to use them to manage live objects.
+-->
+使用构建在 `kubectl` 命令行工具中的指令式命令可以直接快速创建、更新和删除
+Kubernetes 对象。本文档解释这些命令的组织方式以及如何使用它们来管理现时对象。
+
+## {{% heading "prerequisites" %}}
+
+<!--
+Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+-->
+安装[`kubectl`](/zh/docs/tasks/tools/install-kubectl/)。
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+<!--
+## Trade-offs
+
+The `kubectl` tool supports three kinds of object management:
+
+* Imperative commands
+* Imperative object configuration
+* Declarative object configuration
+
+See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
+for a discussion of the advantages and disadvantage of each kind of object management.
+-->
+## 权衡取舍   {#trade-offs}
+
+`kubectl` 工具能够支持三种对象管理方式：
+
+* 指令式命令
+* 指令式对象配置
+* 声明式对象配置
+
+关于每种对象管理的优缺点的讨论，可参见
+[Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
+
+<!--
+## How to create objects
+
+The `kubectl` tool supports verb-driven commands for creating some of the most common
+object types. The commands are named to be recognizable to users unfamiliar with
+the Kubernetes object types.
+
+- `run`: Create a new Pod to run a Container.
+- `expose`: Create a new Service object to load balance traffic across Pods.
+- `autoscale`: Create a new Autoscaler object to automatically horizontally scale a controller, such as a Deployment.
+-->
+## 如何创建对象  {#how-to-create-objects}
+
+`kubectl` 工具支持动词驱动的命令，用来创建一些最常见的对象类别。
+命令的名称设计使得不熟悉 Kubernetes 对象类型的用户也能做出判断。
+
+- `run`：创建一个新的 Pod 来运行一个容器。
+- `expose`：创建一个新的 Service 对象为若干 Pod 提供流量负载均衡。
+- `autoscale`：创建一个新的 Autoscaler 对象来自动对某控制器（如 Deployment）
+  执行水平扩缩。
+
+<!--
+The `kubectl` tool also supports creation commands driven by object type.
+These commands support more object types and are more explicit about
+their intent, but require users to know the type of objects they intend
+to create.
+
+- `create <objecttype> [<subtype>] <instancename>`
+-->
+`kubectl` 命令也支持一些对象类型驱动的创建命令。
+这些命令可以支持更多的对象类别，并且在其动机上体现得更为明显，不过要求
+用户了解它们所要创建的对象的类别。
+
+- `create <对象类别> [<子类别>] <实例名称>`
+
+<!--
+Some objects types have subtypes that you can specify in the `create` command.
+For example, the Service object has several subtypes including ClusterIP,
+LoadBalancer, and NodePort. Here's an example that creates a Service with
+subtype NodePort:
+
+```shell
+kubectl create service nodeport <myservicename>
+```
+-->
+某些对象类别拥有自己的子类别，可以在 `create` 命令中设置。
+例如，Service 对象有 ClusterIP、LoadBalancer 和 NodePort 三种子类别。
+下面是一个创建 NodePort 子类别的 Service 的示例：
+
+```shell
+kubectl create service nodeport <服务名称>
+```
+
+<!--
+In the preceding example, the `create service nodeport` command is called
+a subcommand of the `create service` command.
+
+You can use the `-h` flag to find the arguments and flags supported by
+a subcommand:
+-->
+在前述示例中，`create service nodeport` 命令也称作 `create service`
+命令的子命令：
+
+```shell
+kubectl create service nodeport -h
+```
+
+<!--
+## How to update objects
+
+The `kubectl` command supports verb-driven commands for some common update operations.
+These commands are named to enable users unfamiliar with Kubernetes
+objects to perform updates without knowing the specific fields
+that must be set:
+
+- `scale`: Horizontally scale a controller to add or remove Pods by updating the replica count of the controller.
+- `annotate`: Add or remove an annotation from an object.
+- `label`: Add or remove a label from an object.
+-->
+## 如何更新对象  {#how-to-update-objects}
+
+`kubectl` 命令也支持一些动词驱动的命令，用来执行一些常见的更新操作。
+这些命令的设计是为了让一些不了解 Kubernetes 对象的用户也能执行更新操作，
+但不需要了解哪些字段必须设置：
+
+- `scale`：对某控制器进行水平扩缩以便通过更新控制器的副本个数来添加或删除 Pod。
+- `annotate`：为对象添加或删除注解。
+- `label`：为对象添加或删除标签。
+
+<!--
+The `kubectl` command also supports update commands driven by an aspect of the object.
+Setting this aspect may set different fields for different object types:
+
+- `set` `<field>`: Set an aspect of an object.
+-->
+`kubectl` 命令也支持由对象的某一方面来驱动的更新命令。
+设置对象的这一方面可能对不同类别的对象意味着不同的字段：
+
+- `set <字段>`：设置对象的某一方面。
+
+<!--
+In Kubernetes version 1.5, not every verb-driven command has an associated aspect-driven command.
+-->
+{{< note >}}
+在 Kubernetes 1.5 版本中，并非所有动词驱动的命令都有对应的方面驱动的命令。
+{{< /note >}}
+
+<!--
+The `kubectl` tool supports these additional ways to update a live object directly,
+however they require a better understanding of the Kubernetes object schema.
+
+- `edit`: Directly edit the raw configuration of a live object by opening its configuration in an editor.
+- `patch`: Directly modify specific fields of a live object by using a patch string.
+For more details on patch strings, see the patch section in
+[API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#patch-operations).
+-->
+`kubectl` 工具支持以下额外的方式用来直接更新现时对象，不过这些操作要求
+用户对 Kubernetes 对象的模式定义有很好的了解：
+
+- `edit`：通过在编辑器中打开现时对象的配置，直接编辑其原始配置。
+- `patch`：通过使用补丁字符串（Patch String）直接更改某现时对象的的特定字段。
+  关于补丁字符串的更详细信息，参见
+  [API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#patch-operations)
+  的 patch 节。
+
+<!--
+## How to delete objects
+
+You can use the `delete` command to delete an object from a cluster:
+
+- `delete <type>/<name>`
+-->
+## 如何删除对象  {#how-to-delete-objects}
+
+你可以使用 `delete` 命令从集群中删除一个对象：
+
+- `delete <类别>/<名称>`
+
+<!--
+You can use `kubectl delete` for both imperative commands and imperative object
+configuration. The difference is in the arguments passed to the command. To use
+`kubectl delete` as an imperative command, pass the object to be deleted as
+an argument. Here's an example that passes a Deployment object named nginx:
+-->
+你可以使用 `kubectl delete` 来执行指令式命令或者指令式对象配置。不同之处在于
+传递给命令的参数。要将 `kubectl delete` 作为指令式命令使用，将要删除的对象作为
+参数传递给它。下面是一个删除名为 `nginx` 的 Deployment 对象的命令：
+
+```shell
+kubectl delete deployment/nginx
+```
+
+<!--
+## How to view an object
+
+{{< comment >}}
+TODO(pwittrock): Uncomment this when implemented.
+
+You can use `kubectl view` to print specific fields of an object.
+
+- `view`: Prints the value of a specific field of an object.
+
+{{< /comment >}}
+-->
+## 如何查看对象  {#how-to-view-an-object}
+
+用来打印对象信息的命令有好几个：
+
+- `get`：打印匹配到的对象的基本信息。使用 `get -h` 可以查看选项列表。
+- `describe`：打印匹配到的对象的详细信息的汇集版本。
+- `logs`：打印 Pod 中运行的容器的 stdout 和 stderr 输出。
+
+<!--
+## Using `set` commands to modify objects before creation
+
+There are some object fields that don't have a flag you can use
+in a `create` command. In some of those cases, you can use a combination of
+`set` and `create` to specify a value for the field before object
+creation. This is done by piping the output of the `create` command to the
+`set` command, and then back to the `create` command. Here's an example:
+-->
+## 使用 `set` 命令在创建对象之前修改对象
+
+有些对象字段在 `create` 命令中没有对应的标志。在这些场景中，
+你可以使用 `set` 和 `create` 命令的组合来在对象创建之前设置字段值。
+这是通过将 `create` 命令的输出用管道方式传递给 `set` 命令来实现的，
+最后执行 `create` 命令来创建对象。下面是一个例子：
+
+```sh
+kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
+```
+
+<!--
+1. The `kubectl create service -o yaml --dry-run=client` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server.
+1. The `kubectl set selector --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
+1. The `kubectl create -f -` command creates the object using the configuration provided via stdin.
+-->
+1. 命令 `kubectl create service -o yaml --dry-run=client` 创建 Service 的配置，但
+   将其以 YAML 格式在标准输出上打印而不是发送给 API 服务器。
+1. 命令 `kubectl set selector --local -f - -o yaml` 从标准输入读入配置，并将更新后的
+   配置以 YAML 格式输出到标准输出。
+1. 命令 `kubectl create -f -` 使用标准输入上获得的配置创建对象。
+
+<!--
+## Using `--edit` to modify objects before creation
+
+You can use `kubectl create --edit` to make arbitrary changes to an object
+before it is created. Here's an example:
+-->
+## 在创建之前使用 `--edit` 更改对象
+
+你可以用 `kubectl create --edit` 来在对象被创建之前执行任意的变更。
+下面是一个例子：
+
+```sh
+kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client > /tmp/srv.yaml
+kubectl create --edit -f /tmp/srv.yaml
+```
+
+<!--
+1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`.
+1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object.
+-->
+1. 命令 `kubectl create service` 创建 Service 的配置并将其保存到
+   `/tmp/srv.yaml` 文件。
+1. 命令 `kubectl create --edit` 在创建 Service 对象打开其配置文件进行编辑。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+-->
+* [使用指令式对象配置管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [使用声明式对象配置管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
index d270a85df4..89ac905101 100644
--- a/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -108,6 +108,28 @@ configuration file.
 
 * `kubectl delete -f <filename|url>`
 
+<!-- note
+If configuration file has specified the `generateName` field in the `metadata`
+section instead of the `name` field, you cannot delete the object using
+`kubectl delete -f <filename|url>`.
+You will have to use other flags for deleting the object. For example:
+
+```shell
+kubectl delete <type> <name>
+kubectl delete <type> -l <label>
+```
+-->
+{{< note >}}
+如果配置文件在 `metadata` 节中设置了 `generateName` 字段而非 `name` 字段，
+你无法使用 `kubectl delete -f <filename|url>` 来删除该对象。
+你必须使用其他标志才能删除对象。例如：
+
+```shell
+kubectl delete <type> <name>
+kubectl delete <type> -l <label>
+```
+{{< /note >}}
+
 <!--
 ## How to view an object
 
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md
new file mode 100644
index 0000000000..d6af5bf34b
--- /dev/null
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -0,0 +1,1068 @@
+---
+title: 使用 Kustomize 对 Kubernetes 对象进行声明式管理
+content_type: task
+weight: 20
+---
+<!--
+title: Declarative Management of Kubernetes Objects Using Kustomize
+content_type: task
+weight: 20
+-->
+<!-- overview -->
+
+<!--
+[Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool
+to customize Kubernetes objects
+through a [kustomization file](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization).
+-->
+[Kustomize](https://github.com/kubernetes-sigs/kustomize) 是一个独立的工具，用来通过
+[kustomization 文件](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)
+定制 Kubernetes 对象。
+
+<!--
+Since 1.14, Kubectl also
+supports the management of Kubernetes objects using a kustomization file.
+To view Resources found in a directory containing a kustomization file, run the following command:
+-->
+从 1.14 版本开始，`kubectl` 也开始支持使用 kustomization 文件来管理 Kubernetes 对象。
+要查看包含 kustomization 文件的目录中的资源，执行下面的命令：
+
+```shell
+kubectl kustomize <kustomization_directory>
+```
+
+<!--
+To apply those Resources, run `kubectl apply` with `- -kustomize` or `-k` flag:
+-->
+要应用这些资源，使用参数 `--kustomize` 或 `-k` 标志来执行 `kubectl apply`：
+
+```shell
+kubectl apply -k <kustomization_directory>
+```
+
+## {{% heading "prerequisites" %}}
+
+<!--
+Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
+-->
+安装 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/).
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+<!--
+## Overview of Kustomize
+
+Kustomize is a tool for customizing Kubernetes configurations. It has the following features to manage application configuration files:
+
+* generating resources from other sources
+* setting cross-cutting fields for resources
+* composing and customizing collections of resources
+-->
+## Kustomize 概述    {#overview-of-kustomize}
+
+Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理
+应用配置文件：
+
+* 从其他来源生成资源
+* 为资源设置贯穿性（Cross-Cutting）字段
+* 组织和定制资源集合
+
+<!--
+### Generating Resources
+
+ConfigMaps and Secrets hold configuration or sensitive data that are used by other Kubernetes objects, such as Pods. The source of truth of ConfigMaps or Secrets are usually external to a cluster, such as a `.properties` file or an SSH keyfile.
+Kustomize has `secretGenerator` and `configMapGenerator`, which generate Secret and ConfigMap from files or literals.
+-->
+### 生成资源   {#generating-resources}
+
+ConfigMap 和 Secret 包含其他 Kubernetes 对象（如 Pod）所需要的配置或敏感数据。
+ConfigMap 或 Secret 中数据的来源往往是集群外部，例如某个 `.properties`
+文件或者 SSH 密钥文件。
+Kustomize 提供 `secretGenerator` 和 `configMapGenerator`，可以基于文件或字面
+值来生成 Secret 和 ConfigMap。
+
+<!--
+#### configMapGenerator
+
+To generate a ConfigMap from a file, add an entry to the `files` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.properties` file:
+-->
+#### configMapGenerator
+
+要基于文件来生成 ConfigMap，可以在 `configMapGenerator` 的 `files`
+列表中添加表项。
+下面是一个根据 `.properties` 文件中的数据条目来生成 ConfigMap 的示例：
+
+```shell
+# 生成一个  application.properties 文件
+cat <<EOF >application.properties
+FOO=Bar
+EOF
+
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: example-configmap-1
+  files:
+  - application.properties
+EOF
+```
+
+<!--
+The generated ConfigMap can be examined with the following command:
+-->
+所生成的 ConfigMap 可以使用下面的命令来检查：
+
+```shell
+kubectl kustomize ./
+```
+
+<!--
+The generated ConfigMap is:
+-->
+所生成的 ConfigMap 为：
+
+```yaml
+apiVersion: v1
+data:
+  application.properties: |
+    FOO=Bar
+kind: ConfigMap
+metadata:
+  name: example-configmap-1-8mbdf7882g
+```
+
+<!--
+ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair:
+-->
+ConfigMap 也可基于字面的键值偶对来生成。要基于键值偶对来生成 ConfigMap，
+在 `configMapGenerator` 的 `literals` 列表中添加表项。下面是一个例子，展示
+如何使用键值偶对中的数据条目来生成 ConfigMap 对象：
+
+```shell
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: example-configmap-2
+  literals:
+  - FOO=Bar
+EOF
+```
+
+<!--
+The generated ConfigMap can be checked by the following command:
+-->
+可以用下面的命令检查所生成的 ConfigMap：
+
+```shell
+kubectl kustomize ./
+```
+
+<!--
+The generated ConfigMap is:
+-->
+所生成的 ConfigMap 为：
+
+```yaml
+apiVersion: v1
+data:
+  FOO: Bar
+kind: ConfigMap
+metadata:
+  name: example-configmap-2-g2hdhfc6tk
+```
+
+#### secretGenerator
+
+<!--
+You can generate Secrets from files or literal key-value pairs. To generate a Secret from a file, add an entry to the `files` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a file:
+-->
+你可以基于文件或者键值偶对来生成 Secret。要使用文件内容来生成 Secret，
+在 `secretGenerator` 下面的 `files` 列表中添加表项。
+下面是一个根据文件中数据来生成 Secret 对象的示例：
+
+```shell
+# 创建一个 password.txt 文件
+cat <<EOF >./password.txt
+username=admin
+password=secret
+EOF
+
+cat <<EOF >./kustomization.yaml
+secretGenerator:
+- name: example-secret-1
+  files:
+  - password.txt
+EOF
+```
+
+<!--
+The generated Secret is as follows:
+-->
+所生成的 Secret 如下：
+
+```yaml
+apiVersion: v1
+data:
+  password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg==
+kind: Secret
+metadata:
+  name: example-secret-1-t2kt65hgtb
+type: Opaque
+```
+
+<!--
+To generate a Secret from a literal key-value pair, add an entry to `literals` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a key-value pair:
+-->
+要基于键值偶对字面值生成 Secret，先要在 `secretGenerator` 的 `literals`
+列表中添加表项。下面是基于键值偶对中数据条目来生成 Secret 的示例：
+
+```shell
+cat <<EOF >./kustomization.yaml
+secretGenerator:
+- name: example-secret-2
+  literals:
+  - username=admin
+  - password=secret
+EOF
+```
+
+<!--
+The generated Secret is as follows:
+-->
+所生成的 Secret 如下：
+
+```yaml
+apiVersion: v1
+data:
+  password: c2VjcmV0
+  username: YWRtaW4=
+kind: Secret
+metadata:
+  name: example-secret-2-t52t6g96d8
+type: Opaque
+```
+
+#### generatorOptions
+
+<!--
+The generated ConfigMaps and Secrets have a content hash suffix appended. This ensures that a new ConfigMap or Secret is generated when the contents are changed. To disable the behavior of appending a suffix, one can use `generatorOptions`. Besides that, it is also possible to specify cross-cutting options for generated ConfigMaps and Secrets.
+-->
+所生成的 ConfigMap 和 Secret 都会包含内容哈希值后缀。
+这是为了确保内容发生变化时，所生成的是新的 ConfigMap 或 Secret。
+要禁止自动添加后缀的行为，用户可以使用 `generatorOptions`。
+除此以外，为生成的 ConfigMap 和 Secret 指定贯穿性选项也是可以的。
+
+```shell
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: example-configmap-3
+  literals:
+  - FOO=Bar
+generatorOptions:
+  disableNameSuffixHash: true
+  labels:
+    type: generated
+  annotations:
+    note: generated
+EOF
+```
+
+<!--
+Run`kubectl kustomize ./` to view the generated ConfigMap:
+-->
+运行 `kubectl kustomize ./` 来查看所生成的 ConfigMap：
+
+```yaml
+apiVersion: v1
+data:
+  FOO: Bar
+kind: ConfigMap
+metadata:
+  annotations:
+    note: generated
+  labels:
+    type: generated
+  name: example-configmap-3
+```
+
+<!--
+### Setting cross-cutting fields
+
+It is quite common to set cross-cutting fields for all Kubernetes resources in a project.
+Some use cases for setting cross-cutting fields:
+
+* setting the same namespace for all Resources
+* adding the same name prefix or suffix
+* adding the same set of labels
+* adding the same set of annotations
+
+Here is an example:
+-->
+### 设置贯穿性字段  {#setting-cross-cutting-fields}
+
+在项目中为所有 Kubernetes 对象设置贯穿性字段是一种常见操作。
+贯穿性字段的一些使用场景如下：
+
+* 为所有资源设置相同的名字空间
+* 为所有对象添加相同的前缀或后缀
+* 为对象添加相同的标签集合
+* 为对象添加相同的注解集合
+
+下面是一个例子：
+
+```shell
+# 创建一个 deployment.yaml
+cat <<EOF >./deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  labels:
+    app: nginx
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+EOF
+
+cat <<EOF >./kustomization.yaml
+namespace: my-namespace
+namePrefix: dev-
+nameSuffix: "-001"
+commonLabels:
+  app: bingo
+commonAnnotations:
+  oncallPager: 800-555-1212
+resources:
+- deployment.yaml
+EOF
+```
+
+<!--
+Run `kubectl kustomize ./` to view those fields are all set in the Deployment Resource:
+-->
+执行 `kubectl kustomize ./` 查看这些字段都被设置到 Deployment 资源上：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    oncallPager: 800-555-1212
+  labels:
+    app: bingo
+  name: dev-nginx-deployment-001
+  namespace: my-namespace
+spec:
+  selector:
+    matchLabels:
+      app: bingo
+  template:
+    metadata:
+      annotations:
+        oncallPager: 800-555-1212
+      labels:
+        app: bingo
+    spec:
+      containers:
+      - image: nginx
+        name: nginx
+```
+
+<!--
+### Composing and Customizing Resources
+
+It is common to compose a set of Resources in a project and manage them inside
+the same file or directory.
+Kustomize offers composing Resources from different files and applying patches or other customization to them.
+-->
+### 组织和定制资源    {#composing-and-customizing-resources}
+
+一种常见的做法是在项目中构造资源集合并将其放到同一个文件或目录中管理。
+Kustomize 提供基于不同文件来组织资源并向其应用补丁或者其他定制的能力。
+
+<!--
+#### Composing
+
+Kustomize supports composition of different resources. The `resources` field, in the `kustomization.yaml` file, defines the list of resources to include in a configuration. Set the path to a resource's configuration file in the `resources` list.
+Here is an example of an NGINX application comprised of a Deployment and a Service:
+-->
+#### 组织    {#composing}
+
+Kustomize 支持组合不同的资源。`kustomization.yaml` 文件的 `resources` 字段
+定义配置中要包含的资源列表。你可以将 `resources` 列表中的路径设置为资源配置文件
+的路径。下面是由 Deployment 和 Service 构成的 NGINX 应用的示例：
+
+
+```shell
+# 创建 deployment.yaml 文件
+cat <<EOF > deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+EOF
+
+# 创建 service.yaml 文件
+cat <<EOF > service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx
+  labels:
+    run: my-nginx
+spec:
+  ports:
+  - port: 80
+    protocol: TCP
+  selector:
+    run: my-nginx
+EOF
+
+# 创建 kustomization.yaml 来组织以上两个资源
+cat <<EOF >./kustomization.yaml
+resources:
+- deployment.yaml
+- service.yaml
+EOF
+```
+
+<!--
+The Resources from `kubectl kustomize ./` contain both the Deployment and the Service objects.
+-->
+`kubectl kustomize ./` 所得到的资源中既包含 Deployment 也包含 Service 对象。
+
+<!--
+#### Customizing
+
+Patches can be used to apply different customizations to Resources. Kustomize supports different patching
+mechanisms through `patchesStrategicMerge` and `patchesJson6902`. `patchesStrategicMerge` is a list of file paths. Each file should be resolved to a [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). The names inside the patches must match Resource names that are already loaded. Small patches that do one thing are recommended. For example, create one patch for increasing the deployment replica number and another patch for setting the memory limit.
+-->
+#### 定制   {#customizing}
+
+补丁文件（Patches）可以用来对资源执行不同的定制。
+Kustomize 通过 `patchesStrategicMerge` 和 `patchesJson6902` 支持不同的打补丁
+机制。`patchesStrategicMerge` 的内容是一个文件路径的列表，其中每个文件都应可解析为
+[策略性合并补丁（Strategic Merge Patch）](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)。
+补丁文件中的名称必须与已经加载的资源的名称匹配。
+建议构造规模较小的、仅做一件事情的补丁。
+例如，构造一个补丁来增加 Deployment
+的副本个数；构造另外一个补丁来设置内存限制。
+
+```shell
+# 创建 deployment.yaml 文件
+cat <<EOF > deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+EOF
+
+# 生成一个补丁 increase_replicas.yaml
+cat <<EOF > increase_replicas.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  replicas: 3
+EOF
+
+# 生成另一个补丁 set_memory.yaml
+cat <<EOF > set_memory.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  template:
+    spec:
+      containers:
+      - name: my-nginx
+        resources:
+        limits:
+          memory: 512Mi
+EOF
+
+cat <<EOF >./kustomization.yaml
+resources:
+- deployment.yaml
+patchesStrategicMerge:
+- increase_replicas.yaml
+- set_memory.yaml
+EOF
+```
+
+<!--
+Run `kubectl kustomize ./` to view the Deployment:
+-->
+执行 `kubectl kustomize ./` 来查看 Deployment：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      run: my-nginx
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - image: nginx
+        limits:
+          memory: 512Mi
+        name: my-nginx
+        ports:
+        - containerPort: 80
+```
+
+<!--
+Not all Resources or fields support strategic merge patches. To support modifying arbitrary fields in arbitrary Resources,
+Kustomize offers applying [JSON patch](https://tools.ietf.org/html/rfc6902) through `patchesJson6902`.
+To find the correct Resource for a Json patch, the group, version, kind and name of that Resource need to be
+specified in `kustomization.yaml`. For example, increasing the replica number of a Deployment object can also be done
+through `patchesJson6902`.
+-->
+并非所有资源或者字段都支持策略性合并补丁。为了支持对任何资源的任何字段进行修改，
+Kustomize 提供通过 `patchesJson6902` 来应用 [JSON 补丁](https://tools.ietf.org/html/rfc6902)
+的能力。为了给 JSON 补丁找到正确的资源，需要在 `kustomization.yaml` 文件中指定资源的
+组（group）、版本（version）、类别（kind）和名称（name）。
+例如，为某 Deployment 对象增加副本个数的操作也可以通过 `patchesJson6902`
+来完成：
+
+```shell
+# 创建一个 deployment.yaml 文件
+cat <<EOF > deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+EOF
+
+# 创建一个 JSON 补丁文件
+cat <<EOF > patch.yaml
+- op: replace
+  path: /spec/replicas
+  value: 3
+EOF
+
+# 创建一个 kustomization.yaml
+cat <<EOF >./kustomization.yaml
+resources:
+- deployment.yaml
+
+patchesJson6902:
+- target:
+    group: apps
+    version: v1
+    kind: Deployment
+    name: my-nginx
+  path: patch.yaml
+EOF
+```
+
+<!--
+Run `kubectl kustomize ./` to see the `replicas` field is updated:
+-->
+执行 `kubectl kustomize ./` 以查看 `replicas` 字段被更新：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      run: my-nginx
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - image: nginx
+        name: my-nginx
+        ports:
+        - containerPort: 80
+```
+
+<!--
+In addition to patches, Kustomize also offers customizing container images or injecting field values from other objects into containers
+without creating patches. For example, you can change the image used inside containers by specifying the new image in `images` field in `kustomization.yaml`.
+-->
+除了补丁之外，Kustomize 还提供定制容器镜像或者将其他对象的字段值注入到容器
+中的能力，并且不需要创建补丁。
+例如，你可以通过在 `kustomization.yaml` 文件的 `images` 字段设置新的镜像来
+更改容器中使用的镜像。
+
+```shell
+cat <<EOF > deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+EOF
+
+cat <<EOF >./kustomization.yaml
+resources:
+- deployment.yaml
+images:
+- name: nginx
+  newName: my.image.registry/nginx
+  newTag: 1.4.0
+EOF
+```
+
+<!--
+Run `kubectl kustomize ./` to see that the image being used is updated:
+-->
+执行 `kubectl kustomize ./` 以查看所使用的镜像已被更新：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      run: my-nginx
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - image: my.image.registry/nginx:1.4.0
+        name: my-nginx
+        ports:
+        - containerPort: 80
+```
+
+<!--
+Sometimes, the application running in a Pod may need to use configuration values from other objects. For example,
+a Pod from a Deployment object need to read the corresponding Service name from Env or as a command argument.
+Since the Service name may change as `namePrefix` or `nameSuffix` is added in the `kustomization.yaml` file. It is
+not recommended to hard code the Service name in the command argument. For this usage, Kustomize can inject the Service name into containers through `vars`.
+-->
+有些时候，Pod 中运行的应用可能需要使用来自其他对象的配置值。
+例如，某 Deployment 对象的 Pod 需要从环境变量或命令行参数中读取读取
+Service 的名称。
+由于在 `kustomization.yaml` 文件中添加 `namePrefix` 或 `nameSuffix` 时
+Service 名称可能发生变化，建议不要在命令参数中硬编码 Service 名称。
+对于这种使用场景，Kustomize 可以通过 `vars` 将 Service 名称注入到容器中。
+
+```shell
+# 创建一个 deployment.yaml 文件
+cat <<EOF > deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        command: ["start", "--host", "\$(MY_SERVICE_NAME)"]
+EOF
+
+# 创建一个 service.yaml 文件
+cat <<EOF > service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx
+  labels:
+    run: my-nginx
+spec:
+  ports:
+  - port: 80
+    protocol: TCP
+  selector:
+    run: my-nginx
+EOF
+
+cat <<EOF >./kustomization.yaml
+namePrefix: dev-
+nameSuffix: "-001"
+
+resources:
+- deployment.yaml
+- service.yaml
+
+vars:
+- name: MY_SERVICE_NAME
+  objref:
+    kind: Service
+    name: my-nginx
+    apiVersion: v1
+EOF
+```
+
+<!--
+Run `kubectl kustomize ./` to see that the Service name injected into containers is `dev-my-nginx-001`:
+-->
+执行 `kubectl kustomize ./` 以查看注入到容器中的 Service 名称是 `dev-my-nginx-001`：
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: dev-my-nginx-001
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      run: my-nginx
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - command:
+        - start
+        - --host
+        - dev-my-nginx-001
+        image: nginx
+        name: my-nginx
+```
+
+<!--
+## Bases and Overlays
+
+Kustomize has the concepts of **bases** and **overlays**. A **base** is a directory with a `kustomization.yaml`, which contains a
+set of resources and associated customization. A base could be either a local directory or a directory from a remote repo,
+as long as a `kustomization.yaml` is present inside. An **overlay** is a directory with a `kustomization.yaml` that refers to other
+kustomization directories as its `bases`. A **base** has no knowledge of an overlay and can be used in multiple overlays.
+An overlay may have multiple bases and it composes all resources
+from bases and may also have customization on top of them.
+
+Here is an example of a base:
+-->
+## 基准（Bases）与覆盖（Overlays）
+
+Kustomize 中有 **基准（bases）** 和 **覆盖（overlays）** 的概念区分。
+**基准** 是包含 `kustomization.yaml` 文件的一个目录，其中包含一组资源及其相关的定制。
+基准可以是本地目录或者来自远程仓库的目录，只要其中存在 `kustomization.yaml` 文件即可。
+**覆盖** 也是一个目录，其中包含将其他 kustomization 目录当做 `bases` 来引用的
+`kustomization.yaml` 文件。
+**基准**不了解覆盖的存在，且可被多个覆盖所使用。
+覆盖则可以有多个基准，且可针对所有基准中的资源执行组织操作，还可以在其上执行定制。
+
+```shell
+# 创建一个包含基准的目录 
+mkdir base
+# 创建 base/deployment.yaml
+cat <<EOF > base/deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+EOF
+
+# 创建 base/service.yaml 文件
+cat <<EOF > base/service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx
+  labels:
+    run: my-nginx
+spec:
+  ports:
+  - port: 80
+    protocol: TCP
+  selector:
+    run: my-nginx
+EOF
+
+# 创建 base/kustomization.yaml
+cat <<EOF > base/kustomization.yaml
+resources:
+- deployment.yaml
+- service.yaml
+EOF
+```
+
+<!--
+This base can be used in multiple overlays. You can add different `namePrefix` or other cross-cutting fields
+in different overlays. Here are two overlays using the same base.
+-->
+此基准可在多个覆盖中使用。你可以在不同的覆盖中添加不同的 `namePrefix` 或
+其他贯穿性字段。下面是两个使用同一基准的覆盖：
+
+```shell
+mkdir dev
+cat <<EOF > dev/kustomization.yaml
+bases:
+- ../base
+namePrefix: dev-
+EOF
+
+mkdir prod
+cat <<EOF > prod/kustomization.yaml
+bases:
+- ../base
+namePrefix: prod-
+EOF
+```
+
+<!--
+## How to apply/view/delete objects using Kustomize
+
+Use `-kustomize` or `-k` in `kubectl` commands to recognize Resources managed by `kustomization.yaml`.
+Note that `-k` should point to a kustomization directory, such as
+-->
+## 如何使用 Kustomize 来应用、查看和删除对象
+
+在 `kubectl` 命令中使用 `--kustomize` 或 `-k` 参数来识别被 `kustomization.yaml` 所管理的资源。
+注意 `-k` 要指向一个 kustomization 目录。例如：
+
+```shell
+kubectl apply -k <kustomization 目录>/
+```
+
+<!--
+Given the following `kustomization.yaml`,
+-->
+假定使用下面的 `kustomization.yaml`，
+
+```shell
+# 创建 deployment.yaml 文件
+cat <<EOF > deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  selector:
+    matchLabels:
+      run: my-nginx
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+EOF
+
+# 创建 kustomization.yaml
+cat <<EOF >./kustomization.yaml
+namePrefix: dev-
+commonLabels:
+  app: my-nginx
+resources:
+- deployment.yaml
+EOF
+```
+
+<!--
+Run the following command to apply the Deployment object `dev-my-nginx`:
+-->
+执行下面的命令来应用 Deployment 对象 `dev-my-nginx`：
+
+```shell
+kubectl apply -k ./
+```
+```
+deployment.apps/dev-my-nginx created
+```
+
+<!--
+Run one of the following commands to view the Deployment object `dev-my-nginx`:
+-->
+运行下面的命令之一来查看 Deployment 对象 `dev-my-nginx`：
+
+```shell
+kubectl get -k ./
+```
+
+```shell
+kubectl describe -k ./
+```
+
+<!--
+Run the following command to compare the Deployment object `dev-my-nginx` against the state that the cluster would be in if the manifest was applied:
+-->
+执行下面的命令来比较 Deployment 对象 `dev-my-nginx` 与清单被应用之后
+集群将处于的状态：
+
+```shell
+kubectl diff -k ./
+```
+
+<!--
+Run the following command to delete the Deployment object `dev-my-nginx`:
+-->
+执行下面的命令删除 Deployment 对象 `dev-my-nginx`：
+
+```shell
+kubectl delete -k ./
+```
+```
+deployment.apps "dev-my-nginx" deleted
+```
+
+<!--
+## Kustomize Feature List
+-->
+## Kustomize 功能特性列表
+
+<!--
+| Field                 | Type                                                                                                         | Explanation                                                                        |
+|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
+| namespace             | string                                                                                                       | add namespace to all resources                                                     |
+| namePrefix            | string                                                                                                       | value of this field is prepended to the names of all resources                     |
+| nameSuffix            | string                                                                                                       | value of this field is appended to the names of all resources                      |
+| commonLabels          | map[string]string                                                                                            | labels to add to all resources and selectors                                       |
+| commonAnnotations     | map[string]string                                                                                            | annotations to add to all resources                                                |
+| resources             | []string                                                                                                     | each entry in this list must resolve to an existing resource configuration file    |
+| configmapGenerator    | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99)  | Each entry in this list generates a ConfigMap                                      |
+| secretGenerator       | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106)     | Each entry in this list generates a Secret                                         |
+| generatorOptions      | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | Modify behaviors of all ConfigMap and Secret generator                             |
+| bases                 | []string                                                                                                     | Each entry in this list should resolve to a directory containing a kustomization.yaml file |
+| patchesStrategicMerge | []string                                                                                                     | Each entry in this list should resolve a strategic merge patch of a Kubernetes object |
+| patchesJson6902       | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8)             | Each entry in this list should resolve to a Kubernetes object and a Json Patch     |
+| vars                  | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31)                       | Each entry is to capture text from one resource's field                            |
+| images                | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23)                   | Each entry is to modify the name, tags and/or digest for one image without creating patches |
+| configurations        | []string                                                                                                     | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) |
+| crds                  | []string                                                                                                     | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types |
+-->
+
+| 字段                  | 类型                                                                                                         | 解释                                                                               |
+|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
+| namespace             | string                                                                                                       | 为所有资源添加名字空间                                                     |
+| namePrefix            | string                                                                                                       | 此字段的值将被添加到所有资源名称前面                     |
+| nameSuffix            | string                                                                                                       | 此字段的值将被添加到所有资源名称后面                      |
+| commonLabels          | map[string]string                                                                                            | 要添加到所有资源和选择算符的标签                                       |
+| commonAnnotations     | map[string]string                                                                                            | 要添加到所有资源的注解                                                |
+| resources             | []string                                                                                                     | 列表中的每个条目都必须能够解析为现有的资源配置文件    |
+| configmapGenerator    | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99)  | 列表中的每个条目都会生成一个 ConfigMap                                      |
+| secretGenerator       | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106)     | 列表中的每个条目都会生成一个 Secret                                         |
+| generatorOptions      | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | 更改所有 ConfigMap 和 Secret 生成器的行为 |
+| bases                 | []string                                                                                                     | 列表中每个条目都应能解析为一个包含 kustomization.yaml 文件的目录 |
+| patchesStrategicMerge | []string                                                                                                     | 列表中每个条目都能解析为某 Kubernetes 对象的策略性合并补丁 |
+| patchesJson6902       | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8)             | 列表中每个条目都能解析为一个 Kubernetes 对象和一个 JSON 补丁 |
+| vars                  | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31)                       | 每个条目用来从某资源的字段来析取文字                            |
+| images                | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23)                   | 每个条目都用来更改镜像的名称、标记与/或摘要，不必生成补丁 |
+| configurations        | []string                                                                                                     | 列表中每个条目都应能解析为一个包含 [Kustomize 转换器配置](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) 的文件 |
+| crds                  | []string                                                                                                     | 列表中每个条目都赢能够解析为 Kubernetes 类别的 OpenAPI 定义文件 |
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
+* [Kubectl Book](https://kubectl.docs.kubernetes.io)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+-->
+* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
+* [Kubectl Book](https://kubectl.docs.kubernetes.io)
+* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
+* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+
diff --git a/content/zh/docs/tasks/run-application/update-api-object-kubectl-patch.md b/content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
similarity index 54%
rename from content/zh/docs/tasks/run-application/update-api-object-kubectl-patch.md
rename to content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
index 68c99d6881..1958924fdb 100644
--- a/content/zh/docs/tasks/run-application/update-api-object-kubectl-patch.md
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
@@ -2,16 +2,14 @@
 title: 使用 kubectl patch 更新 API 对象
 description: 使用 kubectl patch 更新 Kubernetes API 对象。做一个策略性的合并 patch 或 JSON 合并 patch。
 content_type: task
-weight: 40
+weight: 50
 ---
 
 <!--
----
 title: Update API Objects in Place Using kubectl patch
 description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.
 content_type: task
 weight: 40
----
 -->
 
 <!-- overview -->
@@ -20,31 +18,23 @@ weight: 40
 This task shows how to use `kubectl patch` to update an API object in place. The exercises
 in this task demonstrate a strategic merge patch and a JSON merge patch.
 -->
-
-这个任务展示了如何使用 `kubectl patch` 就地更新 API 对象。这个任务中的练习演示了一个策略性合并 patch 和一个 JSON 合并 patch。
-
+这个任务展示如何使用 `kubectl patch` 就地更新 API 对象。
+这个任务中的练习演示了一个策略性合并 patch 和一个 JSON 合并 patch。
 
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
-
 <!-- steps -->
 
 <!--
 ## Use a strategic merge patch to update a Deployment
--->
 
-## 使用策略合并 patch 更新 Deployment
-
-<!--
 Here's the configuration file for a Deployment that has two replicas. Each replica
 is a Pod that has one container:
 -->
+## 使用策略合并 patch 更新 Deployment
 
 下面是具有两个副本的 Deployment 的配置文件。每个副本是一个 Pod，有一个容器：
 
@@ -53,7 +43,6 @@ is a Pod that has one container:
 <!--
 Create the Deployment:
 -->
-
 创建 Deployment：
 
 ```shell
@@ -85,13 +74,13 @@ patch-demo-28633765-j5qs3   1/1       Running   0          23s
 Make a note of the names of the running Pods. Later, you will see that these Pods
 get terminated and replaced by new ones.
 -->
-把运行的 Pod 的名字记下来。稍后，您将看到这些 Pod 被终止并被新的 Pod 替换。
+把运行的 Pod 的名字记下来。稍后，你将看到这些 Pod 被终止并被新的 Pod 替换。
 
 <!--
 At this point, each Pod has one Container that runs the nginx image. Now suppose
 you want each Pod to have two containers: one that runs nginx and one that runs redis.
 -->
-此时，每个 Pod 都有一个运行 nginx 镜像的容器。现在假设您希望每个 Pod 有两个容器：一个运行 nginx，另一个运行 redis。
+此时，每个 Pod 都有一个运行 nginx 镜像的容器。现在假设你希望每个 Pod 有两个容器：一个运行 nginx，另一个运行 redis。
 
 <!--
 Create a file named `patch-file-containers.yaml` that has this content:
@@ -110,7 +99,7 @@ spec:
 <!--
 Patch your Deployment:
 -->
-修补您的 Deployment：
+修补你的 Deployment：
 
 ```shell
 kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
@@ -129,7 +118,7 @@ The output shows that the PodSpec in the Deployment has two Containers:
 -->
 输出显示 Deployment 中的 PodSpec 有两个容器:
 
-```shell
+```yaml
 containers:
 - image: redis
   imagePullPolicy: Always
@@ -189,20 +178,18 @@ containers:
 
 <!--
 ### Notes on the strategic merge patch
--->
 
-### 策略性合并类的 patch
-
-<!--
 The patch you did in the preceding exercise is called a *strategic merge patch*.
 Notice that the patch did not replace the `containers` list. Instead it added a new
 Container to the list. In other words, the list in the patch was merged with the
 existing list. This is not always what happens when you use a strategic merge patch on a list.
 In some cases, the list is replaced, not merged.
 -->
-您在前面的练习中所做的 patch 称为`策略性合并 patch`。
-请注意，patch 没有替换`容器`列表。相反，它向列表中添加了一个新容器。换句话说，
-patch 中的列表与现有列表合并。当您在列表中使用策略性合并 patch 时，并不总是这样。
+### 策略性合并类的 patch 的说明
+
+你在前面的练习中所做的 patch 称为`策略性合并 patch（Strategic Merge Patch)`。
+请注意，patch 没有替换`containers` 列表。相反，它向列表中添加了一个新 Container。换句话说，
+patch 中的列表与现有列表合并。当你在列表中使用策略性合并 patch 时，并不总是这样。
 在某些情况下，列表是替换的，而不是合并的。
 
 <!--
@@ -211,8 +198,9 @@ patch strategy. The patch strategy is specified by the value of the `patchStrate
 in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec`
 struct has a `patchStrategy` of `merge`:
 -->
-对于策略性合并 patch，列表可以根据其 patch 策略进行替换或合并。patch 策略由 Kubernetes 源代码中字段标记中的 `patchStrategy` 键的值指定。
-例如，`PodSpec` 结构体的 `Containers` 字段有 `merge` 的 `patchStrategy`：
+对于策略性合并 patch，列表可以根据其 patch 策略进行替换或合并。
+patch 策略由 Kubernetes 源代码中字段标记中的 `patchStrategy` 键的值指定。
+例如，`PodSpec` 结构体的 `Containers` 字段的 `patchStrategy` 为 `merge`：
 
 ```go
 type PodSpec struct {
@@ -224,8 +212,7 @@ type PodSpec struct {
 You can also see the patch strategy in the
 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
 -->
-
-您还可以在 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json)
+你还可以在 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json)
 规范中看到 patch 策略：
 
 ```json
@@ -243,8 +230,8 @@ You can also see the patch strategy in the
 And you can see the patch strategy in the
 [Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 -->
-您可以在 [Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
-中看到 patch 策略
+你可以在 [Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+中看到 patch 策略。
 
 <!--
 Create a file named `patch-file-tolerations.yaml` that has this content:
@@ -264,22 +251,16 @@ spec:
 <!--
 Patch your Deployment:
 -->
-patch Deployment：
+对 Deployment 执行 patch 操作：
 
-
-{{< tabs name="kubectl_patch_example" >}}
-{{{< tab name="Bash" codelang="bash" >}}
+```
 kubectl patch deployment patch-demo --patch "$(cat patch-file-containers.yaml)"
-{{< /tab >}}
-{{< tab name="PowerShell" codelang="posh" >}}
-kubectl patch deployment patch-demo --patch $(cat patch-file-containers.yaml)
-{{< /tab >}}}
-{{< /tabs >}}
+```
 
 <!--
 View the patched Deployment:
 -->
-查看 patch Deployment：
+查看修补后的 Deployment：
 
 ```shell
 kubectl get deployment patch-demo --output yaml
@@ -288,7 +269,7 @@ kubectl get deployment patch-demo --output yaml
 <!--
 The output shows that the PodSpec in the Deployment has only one Toleration:
 -->
-输出结果显示部署中的 PodSpec 只有一个默认：
+输出结果显示 Deployment 中的 PodSpec 只有一个容忍度设置：
 
 ```shell
 
@@ -316,8 +297,8 @@ Notice that the `tolerations` list in the PodSpec was replaced, not merged. This
 the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the
 strategic merge patch uses the default patch strategy, which is `replace`.
 -->
-请注意，PodSpec 中的 `tolerations` 列表被替换，而不是合并。这是因为 PodSpec 的 tolerance 字段的字段标签中没有
-`patchStrategy` 键。所以策略合并 patch 使用默认的 patch 策略，也就是 `replace`。
+请注意，PodSpec 中的 `tolerations` 列表被替换，而不是合并。这是因为 PodSpec 的 `tolerations` 
+的字段标签中没有 `patchStrategy` 键。所以策略合并 patch 操作使用默认的 patch 策略，也就是 `replace`。
 
 ```go
 type PodSpec struct {
@@ -327,36 +308,38 @@ type PodSpec struct {
 
 <!--
 ## Use a JSON merge patch to update a Deployment
--->
-## 使用 JSON 合并 patch 更新部署
 
-<!--
 A strategic merge patch is different from a
 [JSON merge patch](https://tools.ietf.org/html/rfc7386).
 With a JSON merge patch, if you
 want to update a list, you have to specify the entire new list. And the new list completely
 replaces the existing list.
 -->
+## 使用 JSON 合并 patch 更新 Deployment
+
 策略性合并 patch 不同于 [JSON 合并 patch](https://tools.ietf.org/html/rfc7386)。
-使用 JSON 合并 patch，如果您想更新列表，您必须指定整个新列表。新的列表完全取代了现有的列表。
+使用 JSON 合并 patch，如果你想更新列表，你必须指定整个新列表。新的列表完全取代现有的列表。
 
 <!--
 The `kubectl patch` command has a `type` parameter that you can set to one of these values:
 -->
-`kubectl patch` 命令有一个 `type` 参数，您可以将其设置为以下值之一:
+`kubectl patch` 命令有一个 `type` 参数，你可以将其设置为以下值之一:
 
 <table>
-  <tr><th>Parameter value</th><th>Merge type</th></tr>
+  <!-- tr><th>Parameter value</th><th>Merge type</th></tr -->
+  <tr><th>参数值</th><th>合并类型</th></tr>
   <tr><td>json</td><td><a href="https://tools.ietf.org/html/rfc6902">JSON Patch, RFC 6902</a></td></tr>
   <tr><td>merge</td><td><a href="https://tools.ietf.org/html/rfc7386">JSON Merge Patch, RFC 7386</a></td></tr>
-  <tr><td>strategic</td><td>Strategic merge patch</td></tr>
+  <!-- tr><td>strategic</td><td>Strategic merge patch</td></tr -->
+  <tr><td>strategic</td><td>策略合并 patch</td></tr>
 </table>
 
 <!--
 For a comparison of JSON patch and JSON merge patch, see
-[JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/).
+[JSON Patch and JSON Merge Patch](https://erosb.github.io/post/json-patch-vs-merge-patch/).
 -->
-有关 JSON patch 和 JSON 合并 patch 的比较，查看[ JSON patch 和 JSON 合并 patch](http://erosb.github.io/post/json-patch-vs-merge-patch/)。
+有关 JSON patch 和 JSON 合并 patch 的比较，查看
+[JSON patch 和 JSON 合并 patch](https://erosb.github.io/post/json-patch-vs-merge-patch/)。
 
 <!--
 The default value for the `type` parameter is `strategic`. So in the preceding exercise, you
@@ -368,7 +351,7 @@ did a strategic merge patch.
 Next, do a JSON merge patch on your same Deployment. Create a file named `patch-file-2.yaml`
 that has this content:
 -->
-下一步，在相同的部署上执行 JSON 合并 patch。创建一个名为 `patch-file-2` 的文件。内容如下:
+下一步，在相同的 Deployment 上执行 JSON 合并 patch。创建一个名为 `patch-file-2` 的文件。内容如下:
 
 ```yaml
 spec:
@@ -391,7 +374,7 @@ kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yam
 <!--
 View the patched Deployment:
 -->
-查看 patch 部署：
+查看修补后的 Deployment：
 
 ```shell
 kubectl get deployment patch-demo --output yaml
@@ -401,10 +384,10 @@ kubectl get deployment patch-demo --output yaml
 The `containers` list that you specified in the patch has only one Container.
 The output shows that your list of one Container replaced the existing `containers` list.
 -->
-patch 中指定的`容器`列表只有一个容器。
-输出显示您的一个容器列表替换了现有的`容器`列表。
+patch 中指定的`containers`列表只有一个 Container。
+输出显示你所给出的 Contaier 列表替换了现有的 `containers` 列表。
 
-```shell
+```yaml
 spec:
   containers:
   - image: gcr.io/google-samples/node-hello:1.0
@@ -425,7 +408,7 @@ kubectl get pods
 In the output, you can see that the existing Pods were terminated, and new Pods
 were created. The `1/1` indicates that each new Pod is running only one Container.
 -->
-在输出中，您可以看到已经终止了现有的 Pod，并创建了新的 Pod。`1/1` 表示每个新 Pod只运行一个容器。
+在输出中，你可以看到已经终止了现有的 Pod，并创建了新的 Pod。`1/1` 表示每个新 Pod只运行一个容器。
 
 ```shell
 NAME                          READY     STATUS    RESTARTS   AGE
@@ -434,16 +417,185 @@ patch-demo-1307768864-c86dc   1/1       Running   0          1m
 ```
 
 <!--
-## Alternate forms of the kubectl patch command
--->
+## Use strategic merge patch to update a Deployment using the retainKeys strategy
 
-## kubectl patch 命令的其他形式
+Here's the configuration file for a Deployment that uses the `RollingUpdate` strategy:
+-->
+## 使用带 retainKeys 策略的策略合并 patch 更新 Deployment
+
+{{< codenew file="application/deployment-retainkeys.yaml" >}}
+
+<!-- Create the deployment: -->
+创建 Deployment：
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml
+```
 
 <!--
+At this point, the deployment is created and is using the `RollingUpdate` strategy.
+
+Create a file named `patch-file-no-retainkeys.yaml` that has this content:
+-->
+这时，Deployment 被创建，并使用 `RollingUpdate` 策略。
+
+创建一个名为 `patch-file-no-retainkeys.yaml` 的文件，内容如下：
+
+```yaml
+spec:
+  strategy:
+    type: Recreate
+```
+
+<!-- Patch your Deployment: -->
+修补你的 Deployment:
+
+{{< tabs name="kubectl_retainkeys_example" >}}
+{{{< tab name="Bash" codelang="bash" >}}
+kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)"
+{{< /tab >}}
+{{< tab name="PowerShell" codelang="posh" >}}
+kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw)
+{{< /tab >}}}
+{{< /tabs >}}
+
+<!--
+In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`:
+-->
+在输出中，你可以看到，当 `spec.strategy.rollingUpdate` 已经拥有取值定义时，
+将其 `type` 设置为 `Recreate` 是不可能的。
+
+```shell
+The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
+```
+
+<!--
+The way to remove the value for `spec.strategy.rollingUpdate` when updating the value for `type` is to use the `retainKeys` strategy for the strategic merge.
+
+Create another file named `patch-file-retainkeys.yaml` that has this content:
+-->
+更新 `type` 取值的同时移除 `spec.strategy.rollingUpdate` 现有值的方法是
+为策略性合并操作设置 `retainKeys` 策略：
+
+创建另一个名为 `patch-file-retainkeys.yaml` 的文件，内容如下：
+
+```yaml
+spec:
+  strategy:
+    $retainKeys:
+    - type
+    type: Recreate
+```
+
+<!--
+With this patch, we indicate that we want to retain only the `type` key of the `strategy` object. Thus, the `rollingUpdate` will be removed during the patch operation.
+
+Patch your Deployment again with this new patch:
+-->
+使用此 patch，我们表达了希望只保留 `strategy` 对象的 `type` 键。
+这样，在 patch 操作期间 `rollingUpdate` 会被删除。
+
+使用新的 patch 重新修补 Deployment：
+
+{{< tabs name="kubectl_retainkeys2_example" >}}
+{{{< tab name="Bash" codelang="bash" >}}
+kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)"
+{{< /tab >}}
+{{< tab name="PowerShell" codelang="posh" >}}
+kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw)
+{{< /tab >}}}
+{{< /tabs >}}
+
+<!-- Examine the content of the Deployment: -->
+检查 Deployment 的内容：
+
+```shell
+kubectl get deployment retainkeys-demo --output yaml
+```
+
+<!--
+The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore:
+-->
+输出显示 Deployment 中的 `strategy` 对象不再包含 `rollingUpdate` 键：
+
+```shell
+spec:
+  strategy:
+    type: Recreate
+  template:
+```
+
+<!--
+### Notes on the strategic merge patch using the retainKeys strategy
+
+The patch you did in the preceding exercise is called a *strategic merge patch with retainKeys strategy*. This method introduces a new directive `$retainKeys` that has the following strategies:
+
+- It contains a list of strings.
+- All fields needing to be preserved must be present in the `$retainKeys` list.
+- The fields that are present will be merged with live object.
+- All of the missing fields will be cleared when patching.
+- All fields in the `$retainKeys` list must be a superset or the same as the fields present in the patch.
+-->
+### 关于使用 retainKeys 策略的策略合并 patch 操作的说明
+
+在前文练习中所执行的称作 *带 `retainKeys` 策略的策略合并 patch（Strategic Merge
+Patch with retainKeys Strategy）*。
+这种方法引入了一种新的 `$retainKey` 指令，具有如下策略： 
+
+- 其中包含一个字符串列表；
+- 所有需要被保留的字段必须在 `$retainKeys` 列表中给出；
+- 对于已有的字段，会和对象上对应的内容合并；
+- 在修补操作期间，未找到的字段都会被清除；
+- 列表 `$retainKeys` 中的所有字段必须 patch 操作所给字段的超集，或者与之完全一致。
+
+<!--
+The `retainKeys` strategy does not work for all objects. It only works when the value of the `patchStrategy` key in a field tag in the Kubernetes source code contains `retainKeys`. For example, the `Strategy` field of the `DeploymentSpec` struct has a `patchStrategy` of `retainKeys`:
+-->
+策略 `retainKeys` 并不能对所有对象都起作用。它仅对那些 Kubernetes 源码中
+`patchStrategy` 字段标志值包含 `retainKeys` 的字段有用。
+例如 `DeploymentSpec` 结构的 `Strategy` 字段就包含了 `patchStrategy` 为
+`retainKeys` 的标志。 
+
+```go
+type DeploymentSpec struct {
+  ...
+  // +patchStrategy=retainKeys
+  Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...`
+```
+
+<!--
+You can also see the `retainKeys` strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
+-->
+你也可以查看 [OpenAPI 规范](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json)中的 `retainKeys` 策略：
+
+```json
+"io.k8s.api.apps.v1.DeploymentSpec": {
+   ...
+  "strategy": {
+    "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
+    "description": "The deployment strategy to use to replace existing pods with new ones.",
+    "x-kubernetes-patch-strategy": "retainKeys"
+  },
+```
+
+<!--
+And you can see the `retainKeys` strategy in the
+[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
+-->
+而且你也可以在
+[Kubernetes API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
+中看到 `retainKey` 策略。
+
+<!--
+## Alternate forms of the kubectl patch command
+
 The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
 directly on the command line.
 -->
- `kubectl patch` 命令使用 YAML 或 JSON。它可以将 patch 作为文件，也可以直接在命令行中使用。
+## kubectl patch 命令的其他形式
+
+`kubectl patch` 命令使用 YAML 或 JSON。它可以接受以文件形式提供的补丁，也可以
+接受直接在命令行中给出的补丁。
 
 <!--
 Create a file named `patch-file.json` that has this content:
@@ -470,7 +622,7 @@ Create a file named `patch-file.json` that has this content:
 <!--
 The following commands are equivalent:
 -->
-以下命令是相同的：
+以下命令是等价的：
 
 ```shell
 kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"
@@ -482,11 +634,7 @@ kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"co
 
 <!--
 ## Summary
--->
 
-## 总结
-
-<!--
 In this exercise, you used `kubectl patch` to change the live configuration
 of a Deployment object. You did not change the configuration file that you originally used to
 create the Deployment object. Other commands for updating API objects include
@@ -497,32 +645,30 @@ create the Deployment object. Other commands for updating API objects include
 and
 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply).
 -->
-在本练习中，您使用 `kubectl patch` 更改部署对象的实时配置。您没有更改最初用于创建部署对象的配置文件。
+## 总结
+
+在本练习中，你使用 `kubectl patch` 更改了 Deployment 对象的当前配置。
+你没有更改最初用于创建 Deployment 对象的配置文件。
 用于更新 API 对象的其他命令包括
-[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)，
-[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit)，
-[kubectl replace](/docs/reference/generated/kubectl/kubectl-commands/#replace)，
-[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)，
+[`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate)，
+[`kubectl edit`](/docs/reference/generated/kubectl/kubectl-commands/#edit)，
+[`kubectl replace`](/docs/reference/generated/kubectl/kubectl-commands/#replace)，
+[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)，
 和
-[kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply)。
-
-
-
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)。
 
 ## {{% heading "whatsnext" %}}
 
-
 <!--
-* [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)
-* [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/imperative-config/)
-* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+* [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
+* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
 -->
-
-* [Kubernetes 对象管理器](/docs/concepts/overview/object-management-kubectl/overview/)
-* [使用命令管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-command/)
-* [使用配置文件强制管理 Kubernetes 对象](/docs/concepts/overview/object-management-kubectl/imperative-config/)
-* [使用配置文件对 Kubernetes 对象进行声明式管理](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+* [Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)
+* [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [使用配置文件执行 Kubernetes 对象的指令式管理](/zh/docs/tasks/manage-kubernetes-objects/imperative-config)
+* [使用配置文件对 Kubernetes 对象进行声明式管理](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
 
 
 
diff --git a/content/zh/docs/tasks/network/_index.md b/content/zh/docs/tasks/network/_index.md
index 022ce0d2d2..408f2a3f2a 100644
--- a/content/zh/docs/tasks/network/_index.md
+++ b/content/zh/docs/tasks/network/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "网络"
 weight: 160
+description: 了解如何为你的集群配置网络。
 ---
diff --git a/content/zh/docs/tasks/network/validate-dual-stack.md b/content/zh/docs/tasks/network/validate-dual-stack.md
index 2f67abbf70..14a4594e44 100644
--- a/content/zh/docs/tasks/network/validate-dual-stack.md
+++ b/content/zh/docs/tasks/network/validate-dual-stack.md
@@ -1,7 +1,4 @@
 ---
-reviewers:
-- lachie83
-- khenidak
 title: 验证 IPv4/IPv6 双协议栈
 content_type: task
 ---
@@ -17,7 +14,7 @@ content_type: task
 <!--
 This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clusters.
 -->
-这篇文章分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
+本文分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
 
 ## {{% heading "prerequisites" %}}
 
@@ -25,14 +22,14 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
 * Kubernetes 1.16 or later
 * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
 * Kubenet network plugin
-* Kube-proxy running in mode IPVS
 * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster
 -->
 * Kubernetes 1.16 或更高版本
-* 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口)
-* 一个能够支持双协议栈的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
+* 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 Kubernetes 节点
+  提供可路由的 IPv4/IPv6 网络接口)
+* 一个能够支持双协议栈的
+  [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
   （如 kubenet 或 Calico）。 
-* Kube-proxy 在 IPVS 模式下运行
 * [启用双协议栈](/zh/docs/concepts/services-networking/dual-stack/) 集群
 
 <!-- steps -->
@@ -89,7 +86,8 @@ Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name
 -->
 ### 验证 Pod 寻址
 
-验证 Pod 已分配了 IPv4 和 IPv6 地址。（用集群中的有效 Pod 替换 Pod 名称。在此示例中， Pod 名称为 pod01）
+验证 Pod 已分配了 IPv4 和 IPv6 地址。（用集群中的有效 Pod 替换 Pod 名称。
+在此示例中， Pod 名称为 pod01）
 
 ```shell
 kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}'
@@ -103,20 +101,22 @@ a00:100::4
 <!--
 You can also validate Pod IPs using the Downward API via the `status.podIPs` fieldPath. The following snippet demonstrates how you can expose the Pod IPs via an environment variable called `MY_POD_IPS` within a container.
 -->
-您也可以通过 `status.podIPs` 使用 Downward API 验证 Pod IP。以下代码段演示了如何通过容器内称为 `MY_POD_IPS` 的环境变量公开 Pod 的 IP 地址。
+你也可以通过 `status.podIPs` 使用 Downward API 验证 Pod IP。
+以下代码段演示了如何通过容器内称为 `MY_POD_IPS` 的环境变量公开 Pod 的 IP 地址。
 
-```
-        env:
-        - name: MY_POD_IPS
-          valueFrom:
-            fieldRef:
-              fieldPath: status.podIPs
+```yaml
+env:
+- name: MY_POD_IPS
+  valueFrom:
+    fieldRef:
+      fieldPath: status.podIPs
 ```
 
 <!--
 The following command prints the value of the `MY_POD_IPS` environment variable from within a container. The value is a comma separated list that corresponds to the Pod's IPv4 and IPv6 addresses.
 -->
-使用以下命令打印出容器内部 `MY_POD_IPS` 环境变量的值。该值是一个逗号分隔的列表，与 Pod 的 IPv4 和 IPv6 地址相对应。
+使用以下命令打印出容器内部 `MY_POD_IPS` 环境变量的值。
+该值是一个逗号分隔的列表，与 Pod 的 IPv4 和 IPv6 地址相对应。
 
 ```shell
 kubectl exec -it pod01 -- set | grep MY_POD_IPS
@@ -129,7 +129,9 @@ MY_POD_IPS=10.244.1.4,a00:100::4
 <!--
 The Pod's IP addresses will also be written to `/etc/hosts` within a container. The following command executes a cat on `/etc/hosts` on a dual stack Pod. From the output you can verify both the IPv4 and IPv6 IP address for the Pod.
 -->
-Pod 的 IP 地址也将被写入容器内的 `/etc/hosts` 文件中。在双栈 Pod 上执行 cat `/etc/hosts` 命令操作。从输出结果中，您可以验证 Pod 的 IPv4 和 IPv6 地址。
+Pod 的 IP 地址也将被写入容器内的 `/etc/hosts` 文件中。
+在双栈 Pod 上执行 cat `/etc/hosts` 命令操作。
+从输出结果中，你可以验证 Pod 的 IPv4 和 IPv6 地址。
 
 ```shell
 kubectl exec -it pod01 -- cat /etc/hosts
@@ -155,15 +157,17 @@ Create the following Service without the `ipFamily` field set. When this field i
 ## 验证服务
 
 在不设置 `ipFamily` 字段的情况下创建以下服务。
-如果未设置此字段，则服务会通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志从第一个配置的范围中获取 IP。
+如果未设置此字段，则服务会通过 kube-controller-manager 上的
+`--service-cluster-ip-range` 标志从第一个配置的范围中获取 IP。
 
 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
 
 <!--
 By viewing the YAML for the Service you can observe that the Service has the `ipFamily` field has set to reflect the address family of the first configured range set via `--service-cluster-ip-range` flag on kube-controller-manager.
 -->
-通过查看该服务的 YAML ，您可以观察到该服务的 `ipFamily` 字段已设置为反映通过
-kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置的第一个配置范围的地址族。
+通过查看该服务的 YAML ，你可以观察到该服务的 `ipFamily` 字段已被设置。
+其取值反映的是通过 kube-controller-manager 的 `--service-cluster-ip-range`
+标志所设置的第一个地址范围的地址族。
 
 ```shell
 kubectl get svc my-service -o yaml
@@ -207,9 +211,12 @@ Create the following Service with the `ipFamily` field set to `IPv6`.
 Validate that the Service gets a cluster IP address from the IPv6 address block. You may then validate access to the service via the IP and port.
 -->
 验证服务是否是 IPv6 地址块获取集群 IP 地址。
-然后，您可以通过 IP 和端口验证对服务的访问。
+然后，你可以通过 IP 和端口验证对服务的访问。
+
+```shell
+kubectl get svc -l app=MyApp
+```
 ```
- kubectl get svc -l app=MyApp
 NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
 my-service   ClusterIP   fe80:20d::d06b   <none>        80/TCP    9s
 ```
@@ -221,7 +228,8 @@ If the cloud provider supports the provisioning of IPv6 enabled external load ba
 -->
 ### 创建双协议栈负载均衡服务
 
-如果云提供商支持配置启用 IPv6 的外部负载均衡器，则将 `ipFamily` 字段设置为 `IPv6` 并将 `type` 字段设置为 `LoadBalancer`的方式创建以下服务
+如果云提供商支持配置启用 IPv6 的外部负载均衡器，则将 `ipFamily` 字段设置为
+`IPv6` 并将 `type` 字段设置为 `LoadBalancer` 的方式创建以下服务：
 
 {{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
 
@@ -229,9 +237,12 @@ If the cloud provider supports the provisioning of IPv6 enabled external load ba
 Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. 
 -->
 验证服务是否从 IPv6 地址块中接收到 `CLUSTER-IP` 地址以及 `EXTERNAL-IP`。
-然后，您可以通过 IP 和端口验证对服务的访问。
+然后，你可以通过 IP 和端口验证对服务的访问。
+
+```shell
+kubectl get svc -l app=MyApp
+```
 ```
- kubectl get svc -l app=MyApp
 NAME         TYPE        CLUSTER-IP       EXTERNAL-IP                     PORT(S)        AGE
 my-service   ClusterIP   fe80:20d::d06b   2001:db8:f100:4002::9d37:c0d7   80:31868/TCP   30s
 ```
diff --git a/content/zh/docs/tasks/run-application/_index.md b/content/zh/docs/tasks/run-application/_index.md
index 7bb1acba33..d4846746ae 100644
--- a/content/zh/docs/tasks/run-application/_index.md
+++ b/content/zh/docs/tasks/run-application/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "运行应用"
 weight: 40
+description: 运行和管理无状态和有状态的应用程序。
 ---
diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 1dd802ae11..1d94fd247a 100644
--- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -19,48 +19,56 @@ weight: 100
 
 <!--
 Horizontal Pod Autoscaler automatically scales the number of pods
-in a replication controller, deployment or replica set based on observed CPU utilization
+in a replication controller, deployment or replica set or statefulset based on observed CPU utilization
 (or, with beta support, on some other, application-provided metrics).
 -->
-Horizontal Pod Autoscaler 可以根据 CPU 利用率自动扩缩 ReplicationController、Deployment 或者 ReplicaSet 中的 Pod 数量
+Horizontal Pod Autoscaler 可以根据 CPU 利用率自动扩缩 ReplicationController、
+Deployment、ReplicaSet 或 StatefulSet 中的 Pod 数量
 （也可以基于其他应用程序提供的度量指标，目前这一功能处于 beta 版本）。
 
 <!--
-This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.  For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
+This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.
+For more information on how Horizontal Pod Autoscaler behaves, see the
+[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
 -->
 本文将引领你了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。
-更多 Horizontal Pod Autoscaler 的信息请参阅
+与 Horizontal Pod Autoscaler 相关的更多信息请参阅
 [Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)。
 
 ## {{% heading "prerequisites" %}}
 
 <!--
 This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
-to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
-metrics-server monitoring will be turned-on by default.
+[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed
+in the cluster to provide metrics through the [Metrics API](https://github.com/kubernetes/metrics).
+Horizontal Pod Autoscaler uses this API to collect metrics. To learn how to deploy the metrics-server,
+see the [metrics-server documentation](https://github.com/kubernetes-sigs/metrics-server#deployment).
 -->
-本文示例需要一个运行中的 Kubernetes 集群以及 kubectl，集群中还要部署 1.2 或更高
-版本的 [Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server/)。
-Metrics 服务器可以通过资源度量值 API 对外提供度量数据，Horizontal Pod Autoscaler
-正是根据此 API 来获取度量数据。
-部署方法请参考 [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 。
-如果你正在使用 GCE，按照 [GCE 指南中的入门说明](/zh/docs/setup/production-environment/turnkey/gce/) 操作，metrics-server 会默认启动。
+本文示例需要一个运行中的 Kubernetes 集群以及 kubectl，版本为 1.2 或更高。
+[Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server/)
+需要被部署到集群中，以便通过 [Metrics API](https://github.com/kubernetes/metrics)
+提供度量数据。
+Horizontal Pod Autoscaler 根据此 API 来获取度量数据。
+要了解如何部署 metrics-server，请参考
+[metrics-server 文档](https://github.com/kubernetes-incubator/metrics-server/) 。
 
 <!--
-To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
-and kubectl at version 1.6 or later.  Furthermore, in order to make use of custom metrics, your cluster
-must be able to communicate with the API server providing the custom metrics API. Finally, to use metrics
-not related to any Kubernetes object you must have a Kubernetes cluster at version 1.10 or later, and
-you must be able to communicate with the API server that provides the external metrics API.
+To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a
+Kubernetes cluster and kubectl at version 1.6 or later. To make use of custom metrics, your cluster
+must be able to communicate with the API server providing the custom metrics API.
+Finally, to use metrics not related to any Kubernetes object you must have a
+Kubernetes cluster at version 1.10 or later, and you must be able to communicate with
+the API server that provides the external metrics API.
 See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
 -->
-如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，你的 Kubernetes 集群以及 kubectl 至少需要达到 1.6 版本。 
+如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，你的 Kubernetes
+集群以及 kubectl 至少需要达到 1.6 版本。 
 此外，如果要使用自定义度量指标，你的 Kubernetes 集群还必须能够与提供这些自定义指标
 的 API 服务器通信。
 最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要
 达到 1.10 版本，同样，需要保证集群能够与提供这些外部指标的 API 服务器通信。
-更多详细信息，请参阅[Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。
+更多详细信息，请参阅
+[Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。
 
 <!-- steps -->
 
@@ -73,7 +81,8 @@ See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horiz
 To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
 The Dockerfile has the following content:
 -->
-为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。 Dockerfile 内容如下： 
+为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的
+定制 Docker 镜像。Dockerfile 内容如下： 
 
 ```
 FROM php:5-apache
@@ -97,17 +106,25 @@ It defines an index.php page which performs some CPU intensive computations:
 ```
 
 <!--
-First, we will start a deployment running the image and expose it as a service:
+First, we will start a deployment running the image and expose it as a service
+using the following configuration:
 -->
-首先，我们先启动一个 Deployment 来运行这个镜像并暴露一个服务：
+首先，我们使用下面的配置启动一个 Deployment 来运行这个镜像并暴露一个服务：
+
+{{< codenew file="application/php-apache.yaml" >}}
+
+<!--
+Run the following command:
+-->
+运行下面的命令：
 
 ```shell
-kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
+kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
 ```
 
 ```
-service/php-apache created
 deployment.apps/php-apache created
+service/php-apache created
 ```
 
 <!--
@@ -119,19 +136,20 @@ The following command will create a Horizontal Pod Autoscaler that maintains bet
 controlled by the php-apache deployment we created in the first step of these instructions.
 Roughly speaking, HPA will increase and decrease the number of replicas
 (via the deployment) to maintain an average CPU utilization across all Pods of 50%
-(since each pod requests 200 milli-cores by [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md), this means average CPU usage of 100 milli-cores).
+(since each pod requests 200 milli-cores by `kubectl run`), this means average CPU usage of 100 milli-cores).
 See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) for more details on the algorithm.
 -->
-## 创建 Horizontal Pod Autoscaler
+## 创建 Horizontal Pod Autoscaler  {#create-horizontal-pod-autoscaler}
 
 现在，php-apache 服务器已经运行，我们将通过
 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)
 命令创建 Horizontal Pod Autoscaler。 
 以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的
 Deployment，使 Pod 的副本数量维持在 1 到 10 之间。
-大致来说，HPA 将通过增加或者减少 Pod 副本的数量（通过 Deployment）以保持所有 Pod 的平均 CPU 利用率在 50% 以内（由于每个 Pod 通过 `kubectl run` 请求 200 毫核的 CPU）
-，这意味着平均 CPU 利用率为 100 毫核）。
-相关算法的详情请参阅[文档](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)。
+大致来说，HPA 将（通过 Deployment）增加或者减少 Pod 副本的数量以保持所有 Pod
+的平均 CPU 利用率在 50% 左右（由于每个 Pod 请求 200 毫核的 CPU，这意味着平均
+CPU 用量为 100 毫核）。
+算法的详情请参阅[相关文档](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)。
 
 ```shell
 kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
@@ -169,17 +187,14 @@ Please note that the current CPU consumption is 0% as we are not sending any req
 Now, we will see how the autoscaler reacts to increased load.
 We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
 -->
-## 增加负载
+## 增加负载  {#increase-load}
 
 现在，我们将看到 Autoscaler 如何对增加负载作出反应。 
-我们将启动一个容器，并通过一个循环向 php-apache 服务器发送无限的查询请求（请在另一个终端中运行以下命令）：
+我们将启动一个容器，并通过一个循环向 php-apache 服务器发送无限的查询请求
+（请在另一个终端中运行以下命令）：
 
 ```shell
-kubectl run -i --tty load-generator --image=busybox /bin/sh
-
-Hit enter for command prompt
-
-while true; do wget -q -O- http://php-apache; done
+kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
 ```
 
 <!--
@@ -190,25 +205,26 @@ Within a minute or so, we should see the higher CPU load by executing:
 ```shell
 kubectl get hpa
 ```
-```
-NAME         REFERENCE                     TARGET      CURRENT   MINPODS   MAXPODS   REPLICAS   AGE
-php-apache   Deployment/php-apache/scale   305% / 50%  305%      1         10        1          3m
 
+```
+NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
+php-apache   Deployment/php-apache/scale   305% / 50%  1         10        1          3m
 ```
 
 <!--
 Here, CPU consumption has increased to 305% of the request.
 As a result, the deployment was resized to 7 replicas:
 -->
-这时，由于请求增多，CPU 利用率已经升至 305%。
+这时，由于请求增多，CPU 利用率已经升至请求值的 305%。
 可以看到，Deployment 的副本数量已经增长到了 7：
 
 ```shell
 kubectl get deployment php-apache
 ```
+
 ```
-NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-php-apache   7         7         7            7           19m
+NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+php-apache   7/7      7           7           19m
 ```
 
 <!--
@@ -217,7 +233,8 @@ of load is not controlled in any way it may happen that the final number of repl
 will differ from this example.
 -->
 {{< note >}}
-有时最终副本的数量可能需要几分钟才能稳定下来。由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。
+有时最终副本的数量可能需要几分钟才能稳定下来。由于环境的差异，
+不同环境中最终的副本数量可能与本示例中的数量不同。
 {{< /note >}}
 
 <!--
@@ -236,11 +253,12 @@ Then we will verify the result state (after a minute or so):
 
 在我们创建 busybox 容器的终端中，输入`<Ctrl> + C` 来终止负载的产生。
 
-然后我们可以再次查看负载状态（等待几分钟时间）：
+然后我们可以再次检查负载状态（等待几分钟时间）：
 
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m
@@ -249,9 +267,10 @@ php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1
 ```shell
 kubectl get deployment php-apache
 ```
+
 ```
-NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
-php-apache   1         1         1            1           27m
+NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+php-apache   1/1     1            1           27m
 ```
 
 <!--
@@ -274,9 +293,10 @@ Autoscaling the replicas may take a few minutes.
 You can introduce additional metrics to use when autoscaling the `php-apache` Deployment
 by making use of the `autoscaling/v2beta2` API version.
 -->
-## 基于多项度量指标和自定义度量指标自动扩缩
+## 基于多项度量指标和自定义度量指标自动扩缩 {#autoscaling-on-multiple-metrics-and-custom-metrics}
 
-利用 `autoscaling/v2beta2` API 版本，你可以在自动扩缩 php-apache 这个 Deployment 时使用其他度量指标。
+利用 `autoscaling/v2beta2` API 版本，你可以在自动扩缩 php-apache 这个
+Deployment 时使用其他度量指标。
 
 <!--
 First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
@@ -339,11 +359,12 @@ CPU 利用率这个度量指标是一个 *resource metric*（资源度量指标
 
 <!--
 You can also specify resource metrics in terms of direct values, instead of as percentages of the
-requested value, by using a `target` type of `AverageValue` instead of `AverageUtilization`, and
+requested value, by using a `target.type` of `AverageValue` instead of `Utilization`, and
 setting the corresponding `target.averageValue` field instead of the `target.averageUtilization`.
 -->
-你还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将 `target` 类型 `AverageUtilization` 替换成 `AverageValue`，同时
-将 `target.averageUtilization` 替换成 `target.averageValue` 并设定相应的值。
+你还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将 `target.type` 从
+`Utilization` 替换成 `AverageValue`，同时设置 `target.averageValue`
+而非 `target.averageUtilization` 的值。
 
 <!--
 There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
@@ -351,7 +372,7 @@ object metrics.  These metrics may have names which are cluster specific, and re
 advanced cluster monitoring setup.
 -->
 还有两种其他类型的度量指标，他们被认为是 *custom metrics*（自定义度量指标）：
-即 pod 度量指标和 object 度量指标。
+即 Pod 度量指标和 Object 度量指标。
 这些度量指标可能具有特定于集群的名称，并且需要更高级的集群监控设置。
 
 <!--
@@ -359,8 +380,9 @@ The first of these alternative metric types is *pod metrics*.  These metrics des
 are averaged together across pods and compared with a target value to determine the replica count.
 They work much like resource metrics, except that they *only* support a `target` type of `AverageValue`.
 -->
-第一种可选的度量指标类型是 pod 度量指标。这些指标从某一方面描述了Pod，在不同 Pod 之间进行平均，并通过与一个目标值比对来确定副本的数量。
-它们的工作方式与资源度量指标非常相像，差别是它们仅支持 `target` 类型为 `AverageValue`。
+第一种可选的度量指标类型是 Pod 度量指标。这些指标从某一方面描述了 Pod，
+在不同 Pod 之间进行平均，并通过与一个目标值比对来确定副本的数量。
+它们的工作方式与资源度量指标非常相像，只是它们仅支持 `target` 类型为 `AverageValue`。
 
 <!--
 Pod metrics are specified using a metric block like this:
@@ -386,10 +408,13 @@ metric from the API. With `AverageValue`, the value returned from the custom met
 by the number of pods before being compared to the target. The following example is the YAML
 representation of the `requests-per-second` metric.
 -->
-第二种可选的度量指标类型是对象（object）度量指标。相对于描述 Pod，这些度量指标用于描述一个在相同名字空间中的其他对象。
-请注意这些度量指标用于描述这些对象，并非从对象中获取指标。
-对象度量指标支持的 `target` 类型包括 `Value` 和 `AverageValue`。如果是 `Value` 类型，`target` 值将直接与 API 返回的度量指标比较，
-而对于 `AverageValue` 类型，API 返回的度量值将按照 Pod 数量拆分，然后再与 `target` 值比较。
+第二种可选的度量指标类型是对象（Object）度量指标。这些度量指标用于描述
+在相同名字空间中的别的对象，而非 Pods。
+请注意这些度量指标不一定来自某对象，它们仅用于描述这些对象。
+对象度量指标支持的 `target` 类型包括 `Value` 和 `AverageValue`。
+如果是 `Value` 类型，`target` 值将直接与 API 返回的度量指标比较，
+而对于 `AverageValue` 类型，API 返回的度量值将按照 Pod 数量拆分，
+然后再与 `target` 值比较。
 下面的 YAML 文件展示了一个表示 `requests-per-second` 的度量指标。
 
 ```yaml
@@ -398,7 +423,7 @@ object:
   metric:
     name: requests-per-second
   describedObject:
-    apiVersion: networking.k8s.io/v1beta1
+    apiVersion: networking.k8s.io/v1
     kind: Ingress
     name: main-route
   target:
@@ -444,7 +469,9 @@ spec:
     pods:
       metric:
         name: packets-per-second
-      targetAverageValue: 1k
+      target:
+        type: AverageValue
+        averageValue: 1k
   - type: Object
     object:
       metric:
@@ -498,10 +525,10 @@ described below), you can specify an additional label selector which is passed t
 pipeline. For instance, if you collect a metric `http_requests` with the `verb`
 label, you can specify the following metric block to scale only on GET requests:
 -->
-### 基于更确定的度量值来扩缩
+### 基于更特别的度量值来扩缩   {#autoscaing-on-more-specific-metrics}
 
-许多度量流水线允许你通过名称或附加的_标签_来描述度量指标。
-对于所有非资源类型度量指标（pod、object 和后面将介绍的 external），
+许多度量流水线允许你通过名称或附加的 _标签_ 来描述度量指标。
+对于所有非资源类型度量指标（Pod、Object 和后面将介绍的 External），
 可以额外指定一个标签选择算符。例如，如果你希望收集包含 `verb` 标签的
 `http_requests` 度量指标，可以按如下所示设置度量指标块，使得扩缩操作仅针对
 GET 请求执行：
@@ -536,7 +563,8 @@ with *external metrics*.
 -->
 ### 基于与 Kubernetes 对象无关的度量指标执行扩缩
 
-运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动扩缩，
+运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象
+没有明显关系的度量指标进行自动扩缩，
 例如那些描述与任何 Kubernetes 名字空间中的服务都无直接关联的度量指标。
 在 Kubernetes 1.10 及之后版本中，你可以使用外部度量指标（external metrics）。
 
@@ -602,7 +630,7 @@ Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（Status Condition
 The conditions appear in the `status.conditions` field.  To see the conditions affecting a HorizontalPodAutoscaler,
 we can use `kubectl describe hpa`:
 -->
-`status.conditions`字段展示了这些状态条件。
+`status.conditions` 字段展示了这些状态条件。
 可以通过 `kubectl describe hpa` 命令查看当前影响 HorizontalPodAutoscaler
 的各种状态条件信息：
 
@@ -653,16 +681,18 @@ HorizontalPodAutoscaler.
 ## Appendix: Quantities
 
 All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
-a special whole-number notation known in Kubernetes as a *quantity*.  For example,
+a special whole-number notation known in Kubernetes as a
+{{< glossary_tooltip term_id="quantity" text="quantity">}}.  For example,
 the quantity `10500m` would be written as `10.5` in decimal notation.  The metrics APIs
 will return whole numbers without a suffix when possible, and will generally return
 quantities in milli-units otherwise.  This means you might see your metric value fluctuate
-between `1` and `1500m`, or `1` and `1.5` when written in decimal notation.  See the
-[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
+between `1` and `1500m`, or `1` and `1.5` when written in decimal notation.
 -->
-## 附录：量纲
+## 附录：量纲    {#appendix-quantities}
 
-HorizontalPodAutoscaler 和 度量指标 API 中的所有的度量指标使用 Kubernetes 中称为 *quantity* （量纲）的特殊整数表示。
+HorizontalPodAutoscaler 和 度量指标 API 中的所有的度量指标使用 Kubernetes 中称为
+{{< glossary_tooltip term_id="quantity" text="量纲（Quantity）">}}
+的特殊整数表示。
 例如，数量 `10500m` 用十进制表示为 `10.5`。
 如果可能的话，度量指标 API 将返回没有后缀的整数，否则返回以千分单位的数量。
 这意味着你可能会看到你的度量指标在 `1` 和 `1500m` （也就是在十进制记数法中的 `1` 和 `1.5`）之间波动。
@@ -673,9 +703,9 @@ HorizontalPodAutoscaler 和 度量指标 API 中的所有的度量指标使用 K
 
 ### Creating the autoscaler declaratively
 -->
-## 附录：其他可能的情况
+## 附录：其他可能的情况   {#appendix-other-possible-scenarios}
 
-### 使用 YAML 文件以声明式方式创建 Autoscaler
+### 以声明式方式创建 Autoscaler     {#creating-the-autoscaler-declaratively}
 
 <!--
 Instead of using `kubectl autoscale` command to create a HorizontalPodAutoscaler imperatively we
@@ -698,4 +728,3 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
 horizontalpodautoscaler.autoscaling/php-apache created
 ```
 
-
diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
index 717640bb86..65cdbc1841 100644
--- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -3,7 +3,7 @@ title: Pod 水平自动扩缩
 feature:
   title: 水平扩缩 
   description: >
-    使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩。
+    使用一个简单的命令、一个 UI 或基于 CPU 使用情况自动对应用程序进行扩缩。
 
 content_type: concept
 weight: 90
@@ -12,14 +12,14 @@ weight: 90
 <!-- overview -->
 
 <!--
-The Horizontal Pod Autoscaler automatically scales the number of pods
-in a replication controller, deployment or replica set based on observed CPU utilization (or, with
+The Horizontal Pod Autoscaler automatically scales the number of Pods
+in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with
 [custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
 support, on some other application-provided metrics). Note that Horizontal
 Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSets.
 -->
 Pod 水平自动扩缩（Horizontal Pod Autoscaler）
-可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。
+可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。
 除了 CPU 利用率，也可以基于其他应程序提供的[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
 来执行自动扩缩。
 Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。
@@ -61,12 +61,12 @@ or the custom metrics API (for all other metrics).
 
 <!--
 * For per-pod resource metrics (like CPU), the controller fetches the metrics
-  from the resource metrics API for each pod targeted by the HorizontalPodAutoscaler.
+  from the resource metrics API for each Pod targeted by the HorizontalPodAutoscaler.
   Then, if a target utilization value is set, the controller calculates the utilization
   value as a percentage of the equivalent resource request on the containers in
-  each pod.  If a target raw value is set, the raw metric values are used directly.
+  each Pod.  If a target raw value is set, the raw metric values are used directly.
   The controller then takes the mean of the utilization or the raw value (depending on the type
-  of target specified) across all targeted pods, and produces a ratio used to scale
+  of target specified) across all targeted Pods, and produces a ratio used to scale
   the number of desired replicas.
 -->
 * 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
@@ -76,8 +76,8 @@ or the custom metrics API (for all other metrics).
   接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
 
   <!--
-  Please note that if some of the pod's containers do not have the relevant resource request set,
-  CPU utilization for the pod will not be defined and the autoscaler will
+  Please note that if some of the Pod's containers do not have the relevant resource request set,
+  CPU utilization for the Pod will not be defined and the autoscaler will
   not take any action for that metric. See the [algorithm
   details](#algorithm-details) section below for more information about
   how the autoscaling algorithm works.
@@ -96,12 +96,12 @@ or the custom metrics API (for all other metrics).
 * For object metrics and external metrics, a single metric is fetched, which describes
   the object in question. This metric is compared to the target
   value, to produce a ratio as above. In the `autoscaling/v2beta2` API
-  version, this value can optionally be divided by the number of pods before the
+  version, this value can optionally be divided by the number of Pods before the
   comparison is made.
 -->
-* 如果pod 使用对象指标和外部指标（每个指标描述一个对象信息）。
-  这个指标将直接跟据目标设定值相比较，并生成一个上面提到的扩缩比例。
-  在 `autoscaling/v2beta2` 版本API中，这个指标也可以根据 Pod 数量平分后再计算。
+* 如果 Pod 使用对象指标和外部指标（每个指标描述一个对象信息）。
+  这个指标将直接根据目标设定值相比较，并生成一个上面提到的扩缩比例。
+  在 `autoscaling/v2beta2` 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。
 
 <!--
 The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
@@ -136,7 +136,7 @@ each of their current states. More details on scale sub-resource can be found
 [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
 -->
 自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、
-Deployments 和 ReplicaSet）。
+Deployment 和 ReplicaSet）。
 `scale` 是一个可以动态设定副本数量和检查当前状态的接口。
 关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
 
@@ -149,7 +149,7 @@ value:
 -->
 ### 算法细节   {#algorithm-details}
 
-从最基本的角度来看，Pod 水平自动扩缩控制器跟据当前指标和期望指标来计算扩缩比例。
+从最基本的角度来看，Pod 水平自动扩缩控制器根据当前指标和期望指标来计算扩缩比例。
 
 <!--
 ```
@@ -172,7 +172,7 @@ the `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1).
 副本数量将会翻倍。
 如果当前指标为 `50m`，副本数量将会减半，因为`50.0/100.0 == 0.5`。
 如果计算出的扩缩比例接近 1.0
-（跟据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1），
+（根据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1），
 将会放弃本次扩缩。
 
 <!--
@@ -182,7 +182,7 @@ metric across all Pods in the HorizontalPodAutoscaler's scale target.
 Before checking the tolerance and deciding on the final values, we take
 pod readiness and missing metrics into consideration, however.
 -->
-如果 HorizontalPodAutoscaler 指定的是`targetAverageValue` 或 `targetAverageUtilization`，
+如果 HorizontalPodAutoscaler 指定的是 `targetAverageValue` 或 `targetAverageUtilization`，
 那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
 然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。
 
@@ -193,7 +193,7 @@ shut down) and all failed Pods are discarded.
 If a particular Pod is missing metrics, it is set aside for later; Pods
 with missing metrics will be used to adjust the final scaling amount.
 -->
-所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和 失败的 Pod 都会被忽略。
+所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和失败的 Pod 都会被忽略。
 
 如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。
 
@@ -229,7 +229,7 @@ default is 5 minutes.
 The `currentMetricValue / desiredMetricValue` base scale ratio is then
 calculated using the remaining pods not set aside or discarded from above.
 -->
-在排除掉被搁置的 Pod 后，扩缩比例就会跟据`currentMetricValue/desiredMetricValue`
+在排除掉被搁置的 Pod 后，扩缩比例就会根据 `currentMetricValue/desiredMetricValue`
 计算出来。
 
 <!--
@@ -250,7 +250,7 @@ conservatively assume the not-yet-ready pods are consuming 0% of the
 desired metric, further dampening the magnitude of a scale up.
 -->
 此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
-我们保守地假设尚未就绪的 Pod 消耗了试题指标的 0%，从而进一步降低了扩缩的幅度。
+我们保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
 
 <!--
 After factoring in the not-yet-ready pods and missing metrics, we
@@ -274,20 +274,23 @@ used.
 <!--
 If multiple metrics are specified in a HorizontalPodAutoscaler, this
 calculation is done for each metric, and then the largest of the desired
-replica counts is chosen.  If any of those metrics cannot be converted
+replica counts is chosen. If any of these metrics cannot be converted
 into a desired replica count (e.g. due to an error fetching the metrics
-from the metrics APIs), scaling is skipped.
+from the metrics APIs) and a scale down is suggested by the metrics which
+can be fetched, scaling is skipped. This means that the HPA is still capable
+of scaling up if one or more metrics give a `desiredReplicas` greater than
+the current value.
 -->
 如果创建 HorizontalPodAutoscaler 时指定了多个指标，
-那么会按照每个指标分别计算扩缩副本数，取最大的进行扩缩。
-如果任何一个指标无法顺利的计算出扩缩副本数（比如，通过 API 获取指标时出错），
-那么本次扩缩会被跳过。
+那么会按照每个指标分别计算扩缩副本数，取最大值进行扩缩。
+如果任何一个指标无法顺利地计算出扩缩副本数（比如，通过 API 获取指标时出错），
+并且可获取的指标建议缩容，那么本次扩缩会被跳过。
+这表示，如果一个或多个指标给出的 `desiredReplicas` 值大于当前值，HPA 仍然能实现扩容。
 
 <!--
 Finally, just before HPA scales the target, the scale recommendation is recorded.  The
 controller considers all recommendations within a configurable window choosing the
-highest recommendation from within that window. 
-This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
+highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
 This means that scaledowns will occur gradually, smoothing out the impact of rapidly
 fluctuating metric values.
 -->
@@ -321,13 +324,13 @@ API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义
 <!--
 When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-
 More details about the API object can be found at
-[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling).
 -->
 创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的
 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
-有关 API 对象的更多信息，请查阅[HorizontalPodAutoscaler 对象设计文档](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。
+有关 API 对象的更多信息，请查阅
+[HorizontalPodAutoscaler 对象设计文档](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。
 
 <!--
 ## Support for Horizontal Pod Autoscaler in kubectl
@@ -360,13 +363,12 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe
 <!--
 ## Autoscaling during rolling update
 
-Currently in Kubernetes, it is possible to perform a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) 
-by managing replication controllers directly,
-or by using the deployment object, which manages the underlying replica sets for you.
+Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object, 
+which manages the underlying replica sets for you.
 Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
 it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
 -->
-## 滚动升级时扩缩   {#autoscaling-during-roling-update}
+## 滚动升级时扩缩   {#autoscaling-during-rolling-update}
 
 目前在 Kubernetes 中，可以针对 ReplicationController 或 Deployment 执行
 滚动更新，它们会为你管理底层副本数。
@@ -375,13 +377,12 @@ HPA 设置副本数量时，Deployment 会设置底层副本数。
 
 <!--
 Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
-i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update (e.g. using `kubectl rolling-update`).
+i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
 The reason this doesn't work is that when rolling update creates a new replication controller,
 the Horizontal Pod Autoscaler will not be bound to the new replication controller.
 -->
 通过直接操控副本控制器执行滚动升级时，HPA 不能工作，
-也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级
-（例如使用 `kubectl rolling-update` 命令）。
+也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级。
 HPA 不能工作的原因是它无法绑定到滚动更新时所新创建的副本控制器。
 
 <!--
@@ -445,7 +446,7 @@ proposed scales will be used as the new scale.
 
 Kubernetes 1.6 开始支持基于多个度量值进行扩缩。
 你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。
-Horizontal Pod Autoscaler 会跟据每个指标计算，并生成一个扩缩建议。
+Horizontal Pod Autoscaler 会根据每个指标计算，并生成一个扩缩建议。
 幅度最大的扩缩建议会被采纳。
 
 <!--
@@ -492,25 +493,35 @@ APIs, cluster administrators must ensure that:
 集群管理员需要确保下述条件，以保证 HPA 控制器能够访问这些 API：
 
 <!--
-* The [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) is enabled.
+* The [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) is enabled.
+
 * The corresponding APIs are registered:
-   * For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-incubator/metrics-server).
+
+   * For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server).
      It can be launched as a cluster addon.
+
    * For custom metrics, this is the `custom.metrics.k8s.io` API.  It's provided by "adapter" API servers provided by metrics solution vendors.
      Check with your metrics pipeline, or the [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
-     If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) to get started.
+     If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started.
+
    * For external metrics, this is the `external.metrics.k8s.io` API.  It may be provided by the custom metrics adapters provided above.
+
 * The `--horizontal-pod-autoscaler-use-rest-clients` is `true` or unset.  Setting this to false switches to Heapster-based autoscaling, which is deprecated.
 -->
 * 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
+
 * 相应的 API 已注册：
 
    * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
      它可以做为集群插件启动。
-  * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
+    
+   * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
     它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
     确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。
+    如果你想自己编写，请从 [boilerplate](https://github.com/kubernetes-sigs/custommetrics-apiserver)开始。
+   
    * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
+
 * `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。 
   如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。
 
@@ -533,6 +544,251 @@ and [the walkthrough for using external metrics](/docs/tasks/run-application/hor
 [使用自定义指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
 和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
 
+<!--  
+## Support for configurable scaling behavior
+
+Starting from
+[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
+the `v2beta2` API allows scaling behavior to be configured through the HPA
+`behavior` field. Behaviors are specified separately for scaling up and down in
+`scaleUp` or `scaleDown` section under the `behavior` field. A stabilization
+window can be specified for both directions which prevents the flapping of the
+number of the replicas in the scaling target. Similarly specifying scaling
+policies controls the rate of change of replicas while scaling.
+-->
+## 支持可配置的扩缩 {#support-for-configurable-scaling-behaviour}
+
+从 [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
+开始，`v2beta2` API 允许通过 HPA 的 `behavior` 字段配置扩缩行为。
+在 `behavior` 字段中的 `scaleUp` 和 `scaleDown` 分别指定扩容和缩容行为。
+可以两个方向指定一个稳定窗口，以防止扩缩目标中副本数量的波动。
+类似地，指定扩缩策略可以控制扩缩时副本数的变化率。
+
+<!--  
+### Scaling Policies
+
+One or more scaling policies can be specified in the `behavior` section of the spec.
+When multiple policies are specified the policy which allows the highest amount of
+change is the policy which is selected by default. The following example shows this behavior
+while scaling down:
+-->
+### 扩缩策略 {#scaling-policies}
+在 spec 字段的 `behavior` 部分可以指定一个或多个扩缩策略。
+当指定多个策略时，默认选择允许更改最多的策略。
+下面的例子展示了缩容时的行为:
+
+```yaml
+behavior:
+  scaleDown:
+    policies:
+    - type: Pods
+      value: 4
+      periodSeconds: 60
+    - type: Percent
+      value: 10
+      periodSeconds: 60
+```
+
+<!--  
+When the number of pods is more than 40 the second policy will be used for scaling down.
+For instance if there are 80 replicas and the target has to be scaled down to 10 replicas
+then during the first step 8 replicas will be reduced. In the next iteration when the number
+of replicas is 72, 10% of the pods is 7.2 but the number is rounded up to 8. On each loop of
+the autoscaler controller the number of pods to be change is re-calculated based on the number
+of current replicas. When the number of replicas falls below 40 the first policy _(Pods)_ is applied
+and 4 replicas will be reduced at a time.
+-->
+当 Pod 数量超过 40 个时，第二个策略将用于缩容。
+例如，如果有 80 个副本，并且目标必须缩小到 10 个副本，那么在第一步中将减少 8 个副本。
+在下一轮迭代中，当副本的数量为 72 时，10% 的 Pod 数为 7.2，但是这个数字向上取整为 8。
+在 autoscaler 控制器的每个循环中，将根据当前副本的数量重新计算要更改的 Pod 数量。
+当副本数量低于 40 时，应用第一个策略 _（Pods）_ ，一次减少 4 个副本。
+
+<!-- 
+`periodSeconds` indicates the length of time in the past for which the policy must hold true.
+The first policy allows at most 4 replicas to be scaled down in one minute. The second policy
+allows at most 10% of the current replicas to be scaled down in one minute.
+-->
+`periodSeconds` 表示策略的时间长度必须保证有效。
+第一个策略允许在一分钟内最多缩小 4 个副本。
+第二个策略最多允许在一分钟内缩小当前副本的 10%。
+
+<!--  
+The policy selection can be changed by specifying the `selectPolicy` field for a scaling
+direction. By setting the value to `Min` which would select the policy which allows the
+smallest change in the replica count. Setting the value to `Disabled` completely disables
+scaling in that direction.
+-->
+可以指定扩缩方向的 `selectPolicy` 字段来更改策略选择。
+通过设置 `Min` 的值，它将选择副本数变化最小的策略。
+将该值设置为 `Disabled` 将完全禁用该方向的缩放。
+
+<!--  
+### Stabilization Window
+
+The stabilization window is used to restrict the flapping of replicas when the metrics
+used for scaling keep fluctuating. The stabilization window is used by the autoscaling
+algorithm to consider the computed desired state from the past to prevent scaling. In
+the following example the stabilization window is specified for `scaleDown`.
+-->
+### 稳定窗口 {#stabilization-window}
+
+当用于扩缩的指标持续抖动时，使用稳定窗口来限制副本数上下振动。
+自动扩缩算法使用稳定窗口来考虑过去计算的期望状态，以防止扩缩。
+在下面的例子中，稳定化窗口被指定为 `scaleDown`。
+
+```yaml
+scaleDown:
+  stabilizationWindowSeconds: 300
+```
+
+<!--  
+When the metrics indicate that the target should be scaled down the algorithm looks
+into previously computed desired states and uses the highest value from the specified
+interval. In above example all desired states from the past 5 minutes will be considered.
+-->
+当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。
+在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。
+
+<!--  
+### Default Behavior
+
+To use the custom scaling not all fields have to be specified. Only values which need to be
+customized can be specified. These custom values are merged with default values. The default values
+match the existing behavior in the HPA algorithm.
+-->
+### 默认行为 {#default-behavior}
+
+要使用自定义扩缩，不必指定所有字段。
+只有需要自定义的字段才需要指定。
+这些自定义值与默认值合并。
+默认值与 HPA 算法中的现有行为匹配。
+
+```yaml
+behavior:
+  scaleDown:
+    stabilizationWindowSeconds: 300
+    policies:
+    - type: Percent
+      value: 100
+      periodSeconds: 15
+  scaleUp:
+    stabilizationWindowSeconds: 0
+    policies:
+    - type: Percent
+      value: 100
+      periodSeconds: 15
+    - type: Pods
+      value: 4
+      periodSeconds: 15
+    selectPolicy: Max
+```
+
+<!--  
+For scaling down the stabilization window is _300_ seconds(or the value of the
+`--horizontal-pod-autoscaler-downscale-stabilization` flag if provided). There is only a single policy
+for scaling down which allows a 100% of the currently running replicas to be removed which
+means the scaling target can be scaled down to the minimum allowed replicas.
+For scaling up there is no stabilization window. When the metrics indicate that the target should be
+scaled up the target is scaled up immediately. There are 2 policies where 4 pods or a 100% of the currently
+running replicas will be added every 15 seconds till the HPA reaches its steady state.
+-->
+用于缩小稳定窗口的时间为 _300_  秒(或是 `--horizontal-pod-autoscaler-downscale-stabilization` 参数设定值)。
+只有一种缩容的策略，允许 100% 删除当前运行的副本，这意味着扩缩目标可以缩小到允许的最小副本数。
+对于扩容，没有稳定窗口。当指标显示目标应该扩容时，目标会立即扩容。
+这里有两种策略，每 15 秒添加 4 个 Pod 或 100% 当前运行的副本数，直到 HPA 达到稳定状态。
+
+<!--  
+### Example: change downscale stabilization window
+
+To provide a custom downscale stabilization window of 1 minute, the following
+behavior would be added to the HPA:
+--> 
+### 示例：更改缩容稳定窗口
+
+将下面的 behavior 配置添加到 HPA 中，可提供一个 1 分钟的自定义缩容稳定窗口：
+
+```yaml
+behavior:
+  scaleDown:
+    stabilizationWindowSeconds: 60
+```
+
+<!--  
+### Example: limit scale down rate
+
+To limit the rate at which pods are removed by the HPA to 10% per minute, the
+following behavior would be added to the HPA:
+-->
+### 示例：限制缩容速率
+
+将下面的 behavior 配置添加到 HPA 中，可限制 Pod 被 HPA 删除速率为每分钟 10%：
+
+```yaml
+behavior:
+  scaleDown:
+    policies:
+    - type: Percent
+      value: 10
+      periodSeconds: 60
+```
+
+<!--  
+To ensure that no more than 5 Pods are removed per minute, you can add a second scale-down
+policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means
+that the autoscaler chooses the policy that affects the smallest number of Pods:
+-->
+为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，并将 `selectPolicy` 设置为最小值。
+将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略:
+
+```yaml
+behavior:
+  scaleDown:
+    policies:
+    - type: Percent
+      value: 10
+      periodSeconds: 60
+    - type: Pods
+      value: 5
+      periodSeconds: 60
+    selectPolicy: Min
+```
+
+<!--  
+### Example: disable scale down
+
+The `selectPolicy` value of `Disabled` turns off scaling the given direction.
+So to prevent downscaling the following policy would be used:
+-->
+
+### 示例：禁用缩容
+
+`selectPolicy` 的值 `Disabled` 会关闭对给定方向的缩容。
+因此使用以下策略，将会阻止缩容：
+
+```yaml
+behavior:
+  scaleDown:
+    selectPolicy: Disabled
+```
+
+<!--
+## Implicit maintenance-mode deactivation
+
+You can implicitly deactivate the HPA for a target without the
+need to change the HPA configuration itself. If the target's desired replica count
+is set to 0, and the HPA's minimum replica count is greater than 0, the HPA 
+stops adjusting the target (and sets the `ScalingActive` Condition on itself
+to `false`) until you reactivate it by manually adjusting the target's desired
+replica count or HPA's minimum replica count.
+-->
+## 隐式维护状态禁用
+
+你可以在不必更改 HPA 配置的情况下隐式地为某个目标禁用 HPA。
+如果此目标的期望副本个数被设置为 0，而 HPA 的最小副本个数大于 0，
+则 HPA 会停止调整目标（并将其自身的 `ScalingActive` 状况设置为 `false`），
+直到你通过手动调整目标的期望副本个数或 HPA 的最小副本个数来重新激活。
+
 ## {{% heading "whatsnext" %}}
 
 <!--
@@ -541,6 +797,6 @@ and [the walkthrough for using external metrics](/docs/tasks/run-application/hor
 * Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
 -->
 * 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md)
-* `kubectl autoscale` 命令： [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
+* `kubectl autoscale` 命令：[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
 * 使用示例：[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
 
diff --git a/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md b/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md
index 368f7e0486..d41f51a32c 100644
--- a/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md
+++ b/content/zh/docs/tasks/run-application/run-replicated-stateful-application.md
@@ -3,7 +3,7 @@ title: 运行一个有状态的应用程序
 content_type: tutorial
 weight: 30
 ---
-<!-- ---
+<!--
 reviewers:
 - enisoc
 - erictune
@@ -14,75 +14,84 @@ reviewers:
 title: Run a Replicated Stateful Application
 content_type: tutorial
 weight: 30
---- -->
+-->
 
 <!-- overview -->
 
-<!-- This page shows how to run a replicated stateful application using a
+<!--
+This page shows how to run a replicated stateful application using a
 [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller.
 The example is a MySQL single-master topology with multiple slaves running
-asynchronous replication. -->
-该页面显示如何使用[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) 控制器去运行一个有状态的应用程序。此例是一主多从的 MySQL 集群。
+asynchronous replication.
+-->
+本页展示如何使用 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)
+控制器运行一个有状态的应用程序。此例是一主多从、异步复制的 MySQL 集群。
 
-<!-- Note that **this is not a production configuration**.
+<!--
+**this is not a production configuration**.
 In particular, MySQL settings remain on insecure defaults to keep the focus
-on general patterns for running stateful applications in Kubernetes. -->
-请注意 **这不是生产配置**。
-重点是， MySQL 设置保留在不安全的默认值上，使重点放在 Kubernetes 中运行有状态应用程序的常规模式。
-
-
+on general patterns for running stateful applications in Kubernetes.
+-->
+{{< note >}}
+**这不是生产环境下配置**。
+尤其注意，MySQL 设置都使用的是不安全的默认值，这是因为我们想把重点放在 Kubernetes
+中运行有状态应用程序的一般模式上。
+{{< /note >}}
 
 ## {{% heading "prerequisites" %}}
 
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "default-storage-class-prereqs.md" >}}
 
 <!--
 * This tutorial assumes you are familiar with
   [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
   and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
-  as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
+  as well as other core concepts like [Pods](/docs/concepts/workloads/pods/),
   [Services](/docs/concepts/services-networking/service/), and
   [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
 * Some familiarity with MySQL helps, but this tutorial aims to present
-  general patterns that should be useful for other systems. -->
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* {{< include "default-storage-class-prereqs.md" >}}
-* 本教程假定您熟悉
-  [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
-  与 [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
-  以及其他核心概念，例如[Pods](/docs/concepts/workloads/pods/pod/),
-  [Services](/docs/concepts/services-networking/service/), 与
-  [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+  general patterns that should be useful for other systems.
+-->
+* 本教程假定你熟悉
+  [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
+  与 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/),
+  以及其他核心概念，例如 [Pod](/zh/docs/concepts/workloads/pods/)、
+  [服务](/zh/docs/concepts/services-networking/service/) 与
+  [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/).
 * 熟悉 MySQL 会有所帮助，但是本教程旨在介绍对其他系统应该有用的常规模式。
 
-
-
 ## {{% heading "objectives" %}}
 
-
-<!-- * Deploy a replicated MySQL topology with a StatefulSet controller.
+<!--
+* Deploy a replicated MySQL topology with a StatefulSet controller.
 * Send MySQL client traffic.
 * Observe resistance to downtime.
-* Scale the StatefulSet up and down. -->
-* 使用 StatefulSet 控制器部署复制的 MySQL 拓扑。
-* 发送 MySQL 客户端流量。
-* 观察对宕机的抵抗力。
-* 缩放 StatefulSet 的大小。
-
-
+* Scale the StatefulSet up and down.
+-->
+* 使用 StatefulSet 控制器部署多副本 MySQL 拓扑架构。
+* 发送 MySQL 客户端请求
+* 观察对宕机的抵抗力
+* 扩缩 StatefulSet 的规模
 
 <!-- lessoncontent -->
 
-<!-- ## Deploy MySQL -->
-## 部署 MySQL
+<!--
+## Deploy MySQL
 
-<!-- The example MySQL deployment consists of a ConfigMap, two Services,
-and a StatefulSet. -->
-部署 MySQL 示例，包含一个 ConfigMap，两个 Services，与一个 StatefulSet。
+The example MySQL deployment consists of a ConfigMap, two Services,
+and a StatefulSet.
+-->
+## 部署 MySQL  {#deploy-mysql}
+
+MySQL 示例部署包含一个 ConfigMap、两个 Service 与一个 StatefulSet。
 
 ### ConfigMap
 
-<!-- Create the ConfigMap from the following YAML configuration file: -->
-从以下的 YAML 配置文件创建 ConfigMap ：
+<!--
+Create the ConfigMap from the following YAML configuration file:
+-->
+使用以下的 YAML 配置文件创建 ConfigMap ：
 
 {{< codenew file="application/mysql/mysql-configmap.yaml" >}}
 
@@ -90,25 +99,33 @@ and a StatefulSet. -->
 kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
 ```
 
-<!-- This ConfigMap provides `my.cnf` overrides that let you independently control
+<!--
+This ConfigMap provides `my.cnf` overrides that let you independently control
 configuration on the MySQL master and slaves.
 In this case, you want the master to be able to serve replication logs to slaves
-and you want slaves to reject any writes that don't come via replication. -->
-这个 ConfigMap 提供 `my.cnf` 覆盖，使您可以独立控制 MySQL 主服务器和从服务器的配置。
-在这种情况下，您希望主服务器能够将复制日志提供给从服务器，并且希望从服务器拒绝任何不是通过复制进行的写操作。
+and you want slaves to reject any writes that don't come via replication. 
+-->
+这个 ConfigMap 提供 `my.cnf` 覆盖设置，使你可以独立控制 MySQL 主服务器和从服务器的配置。
+在这里，你希望主服务器能够将复制日志提供给从服务器，并且希望从服务器拒绝任何不是通过
+复制进行的写操作。
 
-<!-- There's nothing special about the ConfigMap itself that causes different
+<!--
+There's nothing special about the ConfigMap itself that causes different
 portions to apply to different Pods.
 Each Pod decides which portion to look at as it's initializing,
-based on information provided by the StatefulSet controller. -->
-ConfigMap 本身没有什么特别之处，它可以使不同部分应用于不同的 Pod。
-每个 Pod 都会决定在初始化时要看基于 StatefulSet 控制器提供的信息。
+based on information provided by the StatefulSet controller. 
+-->
+ConfigMap 本身没有什么特别之处，因而也不会出现不同部分应用于不同的 Pod 的情况。
+每个 Pod 都会在初始化时基于 StatefulSet 控制器提供的信息决定要查看的部分。
 
-<!-- ### Services -->
-### Services
+<!--
+### Services 
 
-<!-- Create the Services from the following YAML configuration file: -->
-从以下 YAML 配置文件创建服务：
+Create the Services from the following YAML configuration file: 
+-->
+### 服务  {#services}
+
+使用以下 YAML 配置文件创建服务：
 
 {{< codenew file="application/mysql/mysql-services.yaml" >}}
 
@@ -116,29 +133,43 @@ ConfigMap 本身没有什么特别之处，它可以使不同部分应用于不
 kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
 ```
 
-<!-- The Headless Service provides a home for the DNS entries that the StatefulSet
+<!--
+The Headless Service provides a home for the DNS entries that the StatefulSet
 controller creates for each Pod that's part of the set.
 Because the Headless Service is named `mysql`, the Pods are accessible by
 resolving `<pod-name>.mysql` from within any other Pod in the same Kubernetes
-cluster and namespace. -->
-Headless Service 给 StatefulSet 控制器为集合中每个 Pod 创建的 DNS 条目提供了一个宿主。因为 Headless Service 名为 `mysql`，所以可以通过在同一 Kubernetes 集群和 namespace 中的任何其他 Pod 内解析 `<pod-name>.mysql` 来访问 Pod。
+cluster and namespace. 
+-->
+这个无头服务给 StatefulSet 控制器为集合中每个 Pod 创建的 DNS 条目提供了一个宿主。
+因为服务名为 `mysql`，所以可以通过在同一 Kubernetes 集群和名字中的任何其他 Pod
+内解析 `<Pod 名称>.mysql` 来访问 Pod。
 
-<!-- The Client Service, called `mysql-read`, is a normal Service with its own
+<!--
+The Client Service, called `mysql-read`, is a normal Service with its own
 cluster IP that distributes connections across all MySQL Pods that report
 being Ready. The set of potential endpoints includes the MySQL master and all
-slaves. -->
-客户端 Service 称为 `mysql-read`，是一种常规 Service，具有其自己的群集 IP，该群集 IP 在报告为就绪的所有MySQL Pod 中分配连接。可能端点的集合包括 MySQL 主节点和所有从节点。
+slaves. 
+-->
+客户端服务称为 `mysql-read`，是一种常规服务，具有其自己的集群 IP。
+该集群 IP 在报告就绪的所有MySQL Pod 之间分配连接。
+可能的端点集合包括 MySQL 主节点和所有从节点。
 
-<!-- Note that only read queries can use the load-balanced Client Service.
+<!--
+Note that only read queries can use the load-balanced Client Service.
 Because there is only one MySQL master, clients should connect directly to the
 MySQL master Pod (through its DNS entry within the Headless Service) to execute
-writes. -->
-请注意，只有读取查询才能使用负载平衡的客户端 Service。因为只有一个 MySQL 主服务器，所以客户端应直接连接到 MySQL 主服务器 Pod (通过其在 Headless Service 中的 DNS 条目)以执行写入操作。
+writes. 
+-->
+请注意，只有读查询才能使用负载平衡的客户端服务。
+因为只有一个 MySQL 主服务器，所以客户端应直接连接到 MySQL 主服务器 Pod
+（通过其在无头服务中的 DNS 条目）以执行写入操作。
 
 ### StatefulSet
 
-<!-- Finally, create the StatefulSet from the following YAML configuration file: -->
-最后，从以下 YAML 配置文件创建 StatefulSet：
+<!--
+Finally, create the StatefulSet from the following YAML configuration file: 
+-->
+最后，使用以下 YAML 配置文件创建 StatefulSet：
 
 {{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
 
@@ -146,15 +177,19 @@ writes. -->
 kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
 ```
 
-<!-- You can watch the startup progress by running: -->
-您可以通过运行以下命令查看启动进度：
+<!--
+You can watch the startup progress by running: 
+-->
+你可以通过运行以下命令查看启动进度：
 
 ```shell
 kubectl get pods -l app=mysql --watch
 ```
 
-<!-- After a while, you should see all 3 Pods become Running: -->
-一段时间后，您应该看到所有3个 Pod 都开始运行：
+<!--
+After a while, you should see all 3 Pods become Running: 
+-->
+一段时间后，你应该看到所有 3 个 Pod 进入 Running 状态：
 
 ```
 NAME      READY     STATUS    RESTARTS   AGE
@@ -163,134 +198,205 @@ mysql-1   2/2       Running   0          1m
 mysql-2   2/2       Running   0          1m
 ```
 
-<!-- Press **Ctrl+C** to cancel the watch.
+<!--
+Press **Ctrl+C** to cancel the watch.
 If you don't see any progress, make sure you have a dynamic PersistentVolume
-provisioner enabled as mentioned in the [prerequisites](#before-you-begin). -->
-输入**Ctrl+C**取消观察。
-如果您看不到任何进度，确保已启用[前提条件](#before-you-begin)中提到的动态 PersistentVolume 预配器。
+provisioner enabled as mentioned in the [prerequisites](#before-you-begin). 
+-->
+输入 **Ctrl+C** 结束 watch 操作。
+如果你看不到任何进度，确保已启用[前提条件](#before-you-begin)
+中提到的动态 PersistentVolume 预配器。
 
-
-<!-- This manifest uses a variety of techniques for managing stateful Pods as part of
+<!--
+This manifest uses a variety of techniques for managing stateful Pods as part of
 a StatefulSet. The next section highlights some of these techniques to explain
-what happens as the StatefulSet creates Pods. -->
-该清单使用多种技术来管理作为 StatefulSet 一部分的有状态 Pod。下一节重点介绍其中一些技巧，以解释 StatefulSet 创建 Pod 时发生的状况。
+what happens as the StatefulSet creates Pods. 
+-->
+此清单使用多种技术来管理作为 StatefulSet 的一部分的有状态 Pod。
+下一节重点介绍其中的一些技巧，以解释 StatefulSet 创建 Pod 时发生的状况。
 
-<!-- ## Understanding stateful Pod initialization -->
+<!--
+## Understanding stateful Pod initialization 
+
+The StatefulSet controller starts Pods one at a time, in order by their
+ordinal index.
+It waits until each Pod reports being Ready before starting the next one. 
+-->
 ## 了解有状态的 Pod 初始化
 
-<!-- The StatefulSet controller starts Pods one at a time, in order by their
-ordinal index.
-It waits until each Pod reports being Ready before starting the next one. -->
-StatefulSet 控制器一次按顺序启动 Pod 序数索引。它一直等到每个 Pod 报告就绪为止，然后再开始下一个 Pod。
+StatefulSet 控制器按序数索引顺序地每次启动一个 Pod。
+它一直等到每个 Pod 报告就绪才再启动下一个 Pod。
 
-<!-- In addition, the controller assigns each Pod a unique, stable name of the form
+<!--
+In addition, the controller assigns each Pod a unique, stable name of the form
 `<statefulset-name>-<ordinal-index>`, which results in Pods named `mysql-0`,
-`mysql-1`, and `mysql-2`. -->
-此外，控制器为每个 Pod 分配一个唯一，稳定的表单名称 `<statefulset-name>-<ordinal-index>` 其结果是 Pods 名为 mysql-0，mysql-1 和 mysql-2。
+`mysql-1`, and `mysql-2`. 
+-->
+此外，控制器为每个 Pod 分配一个唯一、稳定的名称，形如 `<statefulset 名称>-<序数索引>`，
+其结果是 Pods 名为 `mysql-0`、`mysql-1` 和 `mysql-2`。
 
-<!-- The Pod template in the above StatefulSet manifest takes advantage of these
-properties to perform orderly startup of MySQL replication. -->
-上述 StatefulSet 清单中的 Pod 模板利用这些属性来执行 MySQL 复制的有序启动。
+<!--
+The Pod template in the above StatefulSet manifest takes advantage of these
+properties to perform orderly startup of MySQL replication. 
+-->
+上述 StatefulSet 清单中的 Pod 模板利用这些属性来执行 MySQL 副本的有序启动。
 
-<!-- ### Generating configuration -->
+<!--
+### Generating configuration 
+
+Before starting any of the containers in the Pod spec, the Pod first runs any
+[Init Containers](/docs/concepts/workloads/pods/init-containers/)
+in the order defined. 
+-->
 ### 生成配置
 
-<!-- Before starting any of the containers in the Pod spec, the Pod first runs any
-[Init Containers](/docs/concepts/workloads/pods/init-containers/)
-in the order defined. -->
-在启动 Pod 规范中的任何容器之前， Pod 首先运行任何[初始容器](/docs/concepts/workloads/pods/init-containers/)按照定义的顺序。
+在启动 Pod 规约中的任何容器之前，Pod 首先按顺序运行所有的
+[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
 
-<!-- The first Init Container, named `init-mysql`, generates special MySQL config
-files based on the ordinal index. -->
-第一个名为 `init-mysql` 的初始化容器，根据序号索引生成特殊的 MySQL 配置文件。
+<!--
+The first Init Container, named `init-mysql`, generates special MySQL config
+files based on the ordinal index. 
+-->
+第一个名为 `init-mysql` 的 Init 容器根据序号索引生成特殊的 MySQL 配置文件。
 
-<!-- The script determines its own ordinal index by extracting it from the end of
+<!--
+The script determines its own ordinal index by extracting it from the end of
 the Pod name, which is returned by the `hostname` command.
 Then it saves the ordinal (with a numeric offset to avoid reserved values)
 into a file called `server-id.cnf` in the MySQL `conf.d` directory.
 This translates the unique, stable identity provided by the StatefulSet
 controller into the domain of MySQL server IDs, which require the same
-properties. -->
-该脚本通过从 Pod 名称的末尾提取索引来确定自己的序号索引，该名称由 `hostname` 命令返回。
-然后将序数(带有数字偏移量以避免保留值)保存到 MySQL conf.d 目录中的文件 server-id.cnf 中。
-这将转换 StatefulSet 提供的唯一，稳定的身份控制器进入需要相同属性的 MySQL 服务器 ID 的范围。
+properties. 
+-->
+该脚本通过从 Pod 名称的末尾提取索引来确定自己的序号索引，而 Pod 名称由 `hostname` 命令返回。
+然后将序数（带有数字偏移量以避免保留值）保存到 MySQL conf.d 目录中的文件 server-id.cnf。
+这一操作将 StatefulSet 所提供的唯一、稳定的标识转换为 MySQL 服务器的 ID，
+而这些 ID 也是需要唯一性、稳定性保证的。
 
-<!-- The script in the `init-mysql` container also applies either `master.cnf` or
+<!--
+The script in the `init-mysql` container also applies either `master.cnf` or
 `slave.cnf` from the ConfigMap by copying the contents into `conf.d`.
 Because the example topology consists of a single MySQL master and any number of
 slaves, the script simply assigns ordinal `0` to be the master, and everyone
-else to be slaves. -->
-通过将内容复制到 conf.d 中，init-mysql 容器中的脚本也可以应用 ConfigMap 中的 master.cnf 或 slave.cnf。由于示例拓扑由单个 MySQL 主节点和任意数量的从节点组成，因此脚本仅将序数 `0` 指定为主节点，而将其他所有人指定为从节点。与 StatefulSet 控制器的[部署顺序保证](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/),这样可以确保 MySQL 主服务器在创建从服务器之前已准备就绪，以便它们可以开始复制。
+else to be slaves. 
 
-<!-- ### Cloning existing data -->
+Combined with the StatefulSet controller's
+[deployment order guarantee](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/),
+this ensures the MySQL master is Ready before creating slaves, so they can begin
+replicating.
+
+-->
+通过将内容复制到 conf.d 中，`init-mysql` 容器中的脚本也可以应用 ConfigMap 中的
+`master.cnf` 或 `slave.cnf`。
+由于示例部署结构由单个 MySQL 主节点和任意数量的从节点组成，因此脚本仅将序数
+`0` 指定为主节点，而将其他所有节点指定为从节点。
+
+与 StatefulSet 控制器的
+[部署顺序保证](/zh/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/)
+相结合，
+可以确保 MySQL 主服务器在创建从服务器之前已准备就绪，以便它们可以开始复制。
+
+<!--
+### Cloning existing data 
+
+In general, when a new Pod joins the set as a slave, it must assume the MySQL
+master might already have data on it. It also must assume that the replication
+logs might not go all the way back to the beginning of time. 
+-->
 ### 克隆现有数据
 
-<!-- In general, when a new Pod joins the set as a slave, it must assume the MySQL
-master might already have data on it. It also must assume that the replication
-logs might not go all the way back to the beginning of time. -->
-通常，当新的 Pod 作为从节点加入集合时，必须假定 MySQL 主节点可能已经有数据。还必须假设复制日志可能不会一直追溯到时间的开始。
-<!-- These conservative assumptions are the key to allow a running StatefulSet
-to scale up and down over time, rather than being fixed at its initial size. -->
-这些保守假设的关键是允许正在运行的 StatefulSet 随时间扩大和缩小而不是固定在其初始大小。
+通常，当新 Pod 作为从节点加入集合时，必须假定 MySQL 主节点可能已经有数据。
+还必须假设复制日志可能不会一直追溯到时间的开始。
 
-<!-- The second Init Container, named `clone-mysql`, performs a clone operation on
+<!--
+These conservative assumptions are the key to allow a running StatefulSet
+to scale up and down over time, rather than being fixed at its initial size. 
+-->
+这些保守的假设是允许正在运行的 StatefulSet 随时间扩大和缩小而不是固定在其初始大小的关键。
+
+<!--
+The second Init Container, named `clone-mysql`, performs a clone operation on
 a slave Pod the first time it starts up on an empty PersistentVolume.
 That means it copies all existing data from another running Pod,
-so its local state is consistent enough to begin replicating from the master. -->
-第二个名为 `clone-mysql` 的初始化容器，第一次在从属 Pod 上以空 PersistentVolume 启动时，会对从属 Pod 执行克隆操作。这意味着它将从另一个运行的 Pod 复制所有现有数据，因此其本地状态足够一致，可以开始主从服务器复制。
+so its local state is consistent enough to begin replicating from the master. 
+-->
+第二个名为 `clone-mysql` 的 Init 容器，第一次在带有空 PersistentVolume 的从属 Pod
+上启动时，会在从属 Pod 上执行克隆操作。
+这意味着它将从另一个运行中的 Pod 复制所有现有数据，使此其本地状态足够一致，
+从而可以开始从主服务器复制。
 
-<!-- MySQL itself does not provide a mechanism to do this, so the example uses a
+<!--
+MySQL itself does not provide a mechanism to do this, so the example uses a
 popular open-source tool called Percona XtraBackup.
 During the clone, the source MySQL server might suffer reduced performance.
 To minimize impact on the MySQL master, the script instructs each Pod to clone
 from the Pod whose ordinal index is one lower.
 This works because the StatefulSet controller always ensures Pod `N` is
-Ready before starting Pod `N+1`. -->
-MySQL 本身不提供执行此操作的机制，因此该示例使用了一种流行的开源工具 Percona XtraBackup。
-在克隆期间，源 MySQL 服务器可能会降低性能。
-为了最大程度地减少对 MySQL 主机的影响，该脚本指示每个 Pod 从序号较低的 Pod 中克隆。
+Ready before starting Pod `N+1`. 
+-->
+MySQL 本身不提供执行此操作的机制，因此本示例使用了一种流行的开源工具 Percona XtraBackup。
+在克隆期间，源 MySQL 服务器性能可能会受到影响。
+为了最大程度地减少对 MySQL 主节点的影响，该脚本指示每个 Pod 从序号较低的 Pod 中克隆。
 可以这样做的原因是 StatefulSet 控制器始终确保在启动 Pod N + 1 之前 Pod N 已准备就绪。
 
-<!-- ### Starting replication -->
-### 开始复制
+<!--
+### Starting replication 
 
-<!-- After the Init Containers complete successfully, the regular containers run.
+After the Init Containers complete successfully, the regular containers run.
 The MySQL Pods consist of a `mysql` container that runs the actual `mysqld`
 server, and an `xtrabackup` container that acts as a
-[sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). -->
-初始化容器成功完成后，常规容器将运行。
-MySQL Pods 由运行实际 `mysqld` 服务器的 `mysql` 容器和充当[辅助工具](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)的 xtrabackup 容器组成。
+[sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). 
+-->
+### 开始复制
 
-<!-- The `xtrabackup` sidecar looks at the cloned data files and determines if
+Init 容器成功完成后，应用容器将运行。
+MySQL Pod 由运行实际 `mysqld` 服务的 `mysql` 容器和充当
+[辅助工具](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
+的 xtrabackup 容器组成。
+
+<!--
+The `xtrabackup` sidecar looks at the cloned data files and determines if
 it's necessary to initialize MySQL replication on the slave.
 If so, it waits for `mysqld` to be ready and then executes the
 `CHANGE MASTER TO` and `START SLAVE` commands with replication parameters
-extracted from the XtraBackup clone files. -->
-`xtrabackup` 辅助工具查看克隆的数据文件，并确定是否有必要在从属服务器上初始化 MySQL 复制。
-如果是这样，它将等待 `mysqld` 准备就绪，然后执行带有从 XtraBackup 克隆文件中提取的复制参数 `CHANGE MASTER TO` 和 `START SLAVE` 命令。
+extracted from the XtraBackup clone files. 
+-->
+`xtrabackup` sidecar 容器查看克隆的数据文件，并确定是否有必要在从服务器上初始化 MySQL 复制。
+如果是这样，它将等待 `mysqld` 准备就绪，然后使用从 XtraBackup 克隆文件中提取的复制参数
+执行  `CHANGE MASTER TO` 和 `START SLAVE` 命令。
 
-<!-- Once a slave begins replication, it remembers its MySQL master and
+<!--
+Once a slave begins replication, it remembers its MySQL master and
 reconnects automatically if the server restarts or the connection dies.
 Also, because slaves look for the master at its stable DNS name
 (`mysql-0.mysql`), they automatically find the master even if it gets a new
-Pod IP due to being rescheduled. -->
-一旦从服务器开始复制后，它会记住其 MySQL 主服务器。并且如果服务器重新启动或连接中断，则会自动重新连接。
-另外，因为从服务器会以其稳定的 DNS 名称查找主服务器(`mysql-0.mysql`)，即使由于重新安排而获得新的 Pod IP，他们也会自动找到主服务器。
+Pod IP due to being rescheduled. 
+-->
+一旦从服务器开始复制后，它会记住其 MySQL 主服务器，并且如果服务器重新启动或连接中断也会自动重新连接。
+另外，因为从服务器会以其稳定的 DNS 名称查找主服务器（`mysql-0.mysql`），
+即使由于重新调度而获得新的 Pod IP，他们也会自动找到主服务器。
 
-<!-- Lastly, after starting replication, the `xtrabackup` container listens for
+<!--
+Lastly, after starting replication, the `xtrabackup` container listens for
 connections from other Pods requesting a data clone.
 This server remains up indefinitely in case the StatefulSet scales up, or in
-case the next Pod loses its PersistentVolumeClaim and needs to redo the clone. -->
-最后，开始复制后，`xtrabackup` 容器监听来自其他 Pod 的连接数据克隆请求。
-如果 StatefulSet 扩大规模，或者下一个 Pod 失去其 PersistentVolumeClaim 并需要重新克隆，则此服务器将无限期保持运行。
+case the next Pod loses its PersistentVolumeClaim and needs to redo the clone. 
+-->
+最后，开始复制后，`xtrabackup` 容器监听来自其他 Pod 的连接，处理其数据克隆请求。
+如果 StatefulSet 扩大规模，或者下一个 Pod 失去其 PersistentVolumeClaim 并需要重新克隆，
+则此服务器将无限期保持运行。
 
-<!-- ## Sending client traffic -->
-## 发送客户端流量
+<!--
+## Sending client traffic 
 
-<!-- You can send test queries to the MySQL master (hostname `mysql-0.mysql`)
+You can send test queries to the MySQL master (hostname `mysql-0.mysql`)
 by running a temporary container with the `mysql:5.7` image and running the
-`mysql` client binary. -->
-您可以通过运行带有 `mysql:5.7` 镜像的临时容器并运行 `mysql` 客户端二进制文件，将测试查询发送到 MySQL 主服务器(主机名 `mysql-0.mysql` )。
+`mysql` client binary. 
+-->
+## 发送客户端请求
+
+你可以通过运行带有 `mysql:5.7` 镜像的临时容器并运行 `mysql` 客户端二进制文件，
+将测试查询发送到 MySQL 主服务器（主机名 `mysql-0.mysql`）。
 
 ```shell
 kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
@@ -301,8 +407,10 @@ INSERT INTO test.messages VALUES ('hello');
 EOF
 ```
 
-<!-- Use the hostname `mysql-read` to send test queries to any server that reports
-being Ready: -->
+<!--
+Use the hostname `mysql-read` to send test queries to any server that reports
+being Ready: 
+-->
 使用主机名 `mysql-read` 将测试查询发送到任何报告为就绪的服务器：
 
 ```shell
@@ -310,8 +418,10 @@ kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
   mysql -h mysql-read -e "SELECT * FROM test.messages"
 ```
 
-<!-- You should get output like this: -->
-您应该获得如下输出：
+<!--
+You should get output like this: 
+-->
+你应该获得如下输出：
 
 ```
 Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
@@ -323,18 +433,22 @@ Waiting for pod default/mysql-client to be running, status is Pending, pod ready
 pod "mysql-client" deleted
 ```
 
-<!-- To demonstrate that the `mysql-read` Service distributes connections across
-servers, you can run `SELECT @@server_id` in a loop: -->
-为了演示 `mysql-read` 服务在服务器之间分配连接，您可以在循环中运行 `SELECT @@server_id`：
+<!--
+To demonstrate that the `mysql-read` Service distributes connections across
+servers, you can run `SELECT @@server_id` in a loop: 
+-->
+为了演示 `mysql-read` 服务在服务器之间分配连接，你可以在循环中运行 `SELECT @@server_id`：
 
 ```shell
 kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
   bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"
 ```
 
-<!-- You should see the reported `@@server_id` change randomly, because a different
-endpoint might be selected upon each connection attempt: -->
-您应该看到报告的 `@@server_id` 发生随机变化，因为每次尝试连接时都可能选择了不同的端点：
+<!--
+You should see the reported `@@server_id` change randomly, because a different
+endpoint might be selected upon each connection attempt: 
+-->
+你应该看到报告的 `@@server_id` 发生随机变化，因为每次尝试连接时都可能选择了不同的端点：
 
 ```
 +-------------+---------------------+
@@ -354,102 +468,140 @@ endpoint might be selected upon each connection attempt: -->
 +-------------+---------------------+
 ```
 
-<!-- You can press **Ctrl+C** when you want to stop the loop, but it's useful to keep
-it running in another window so you can see the effects of the following steps. -->
-要停止循环时可以按 **Ctrl+C** ，但是让它在另一个窗口中运行非常有用，这样您就可以看到以下步骤的效果。
+<!--
+You can press **Ctrl+C** when you want to stop the loop, but it's useful to keep
+it running in another window so you can see the effects of the following steps. 
+-->
+要停止循环时可以按 **Ctrl+C** ，但是让它在另一个窗口中运行非常有用，
+这样你就可以看到以下步骤的效果。
 
-<!-- ## Simulating Pod and Node downtime -->
+<!--
+## Simulating Pod and Node downtime 
+
+To demonstrate the increased availability of reading from the pool of slaves
+instead of a single server, keep the `SELECT @@server_id` loop from above
+running while you force a Pod out of the Ready state. 
+-->
 ## 模拟 Pod 和 Node 的宕机时间
 
-<!-- To demonstrate the increased availability of reading from the pool of slaves
-instead of a single server, keep the `SELECT @@server_id` loop from above
-running while you force a Pod out of the Ready state. -->
-为了证明从从节点缓存而不是单个服务器读取数据的可用性提高，请在使 Pod 退出 Ready 状态时，保持 `SELECT @@server_id` 循环从上面运行。
+为了证明从从节点缓存而不是单个服务器读取数据的可用性提高，请在使 Pod 退出 Ready
+状态时，保持上述 `SELECT @@server_id` 循环一直运行。
 
-<!-- ### Break the Readiness Probe -->
-### 退出 Readiness Probe
+<!--
+### Break the Readiness Probe 
 
-<!-- The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
+The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
 for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
-to make sure the server is up and able to execute queries. -->
-`mysql` 容器的[readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)运行命令 `mysql -h 127.0.0.1 -e 'SELECT 1'`，以确保服务器已启动并能够执行查询。
+to make sure the server is up and able to execute queries. 
+-->
+### 破坏就绪态探测
 
-<!-- One way to force this readiness probe to fail is to break that command: -->
-迫使 readiness probe 失败的一种方法就是执行该命令：
+`mysql` 容器的
+[就绪态探测](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
+运行命令 `mysql -h 127.0.0.1 -e 'SELECT 1'`，以确保服务器已启动并能够执行查询。
+
+<!--
+One way to force this readiness probe to fail is to break that command: 
+-->
+迫使就绪态探测失败的一种方法就是中止该命令：
 
 ```shell
 kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off
 ```
 
-<!-- This reaches into the actual container's filesystem for Pod `mysql-2` and
+<!--
+This reaches into the actual container's filesystem for Pod `mysql-2` and
 renames the `mysql` command so the readiness probe can't find it.
 After a few seconds, the Pod should report one of its containers as not Ready,
-which you can check by running: -->
-这进入 Pod `mysql-2` 的实际容器文件系统，并重命名 `mysql` 命令，以便 readiness probe 无法找到它。
-几秒钟后， Pod 会将其中一个容器报告为未就绪，您可以通过运行以下命令进行检查：
+which you can check by running: 
+-->
+此命令会进入 Pod `mysql-2` 的实际容器文件系统，重命名 `mysql` 命令，导致就绪态探测无法找到它。
+几秒钟后， Pod 会报告其中一个容器未就绪。你可以通过运行以下命令进行检查：
 
 ```shell
 kubectl get pod mysql-2
 ```
 
-<!-- Look for `1/2` in the `READY` column: -->
-在 `就绪` 列中查找 ` 1/2` ：
+<!--
+Look for `1/2` in the `READY` column: 
+-->
+在 `READY` 列中查找 ` 1/2` ：
 
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 mysql-2   1/2       Running   0          3m
 ```
 
-<!-- At this point, you should see your `SELECT @@server_id` loop continue to run,
+<!--
+At this point, you should see your `SELECT @@server_id` loop continue to run,
 although it never reports `102` anymore.
 Recall that the `init-mysql` script defined `server-id` as `100 + $ordinal`,
-so server ID `102` corresponds to Pod `mysql-2`. -->
-此时，您应该会看到 `SELECT @@server_id` 循环继续运行，尽管它不再报告 `102` 。
-回想一下，`init-mysql` 脚本将 `server-id` 定义为 `100 + $ordinal` ，因此服务器 ID `102` 对应于 Pod `mysql-2`。
+so server ID `102` corresponds to Pod `mysql-2`. 
+-->
+此时，你应该会看到 `SELECT @@server_id` 循环继续运行，尽管它不再报告 `102`。
+回想一下，`init-mysql` 脚本将 `server-id` 定义为 `100 + $ordinal`，
+因此服务器 ID `102` 对应于 Pod `mysql-2`。
 
-<!-- Now repair the Pod and it should reappear in the loop output
-after a few seconds: -->
+<!--
+Now repair the Pod and it should reappear in the loop output
+after a few seconds: 
+-->
 现在修复 Pod，几秒钟后它应该重新出现在循环输出中：
 
 ```shell
 kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql
 ```
 
-<!-- ### Delete Pods -->
+<!--
+### Delete Pods 
+
+The StatefulSet also recreates Pods if they're deleted, similar to what a
+ReplicaSet does for stateless Pods. 
+-->
 ### 删除 Pods
 
-<!-- The StatefulSet also recreates Pods if they're deleted, similar to what a
-ReplicaSet does for stateless Pods. -->
 如果删除了 Pod，则 StatefulSet 还会重新创建 Pod，类似于 ReplicaSet 对无状态 Pod 所做的操作。
 
 ```shell
 kubectl delete pod mysql-2
 ```
 
-<!-- The StatefulSet controller notices that no `mysql-2` Pod exists anymore,
+<!--
+The StatefulSet controller notices that no `mysql-2` Pod exists anymore,
 and creates a new one with the same name and linked to the same
 PersistentVolumeClaim.
 You should see server ID `102` disappear from the loop output for a while
-and then return on its own. -->
-StatefulSet 控制器注意到不再存在 `mysql-2` Pod，并创建了一个具有相同名称并链接到相同    PersistentVolumeClaim 的新 Pod。
-您应该看到服务器 ID `102` 从循环输出中消失了一段时间，然后自行返回。
+and then return on its own. 
+-->
+StatefulSet 控制器注意到不再存在 `mysql-2` Pod，于是创建一个具有相同名称并链接到相同
+PersistentVolumeClaim 的新 Pod。
+你应该看到服务器 ID `102` 从循环输出中消失了一段时间，然后又自行出现。
 
-<!-- ### Drain a Node -->
-### 排除 Node
+<!--
+### Drain a Node 
 
-<!-- If your Kubernetes cluster has multiple Nodes, you can simulate Node downtime
+If your Kubernetes cluster has multiple Nodes, you can simulate Node downtime
 (such as when Nodes are upgraded) by issuing a
-[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain). -->
-如果您的 Kubernetes 集群具有多个节点，则可以通过发出以下命令[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)来模拟节点停机时间(例如升级节点时)。
+[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain). 
+-->
+### 腾空节点   {#drain-a-node}
 
-<!-- First determine which Node one of the MySQL Pods is on: -->
-首先确定 MySQL Pods 之一在哪个节点上：
+如果你的 Kubernetes 集群具有多个节点，则可以通过发出以下
+[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
+命令来模拟节点停机（就好像节点在被升级）。
+
+<!--
+First determine which Node one of the MySQL Pods is on: 
+-->
+首先确定 MySQL Pod 之一在哪个节点上：
 
 ```shell
 kubectl get pod mysql-2 -o wide
 ```
 
-<!-- The Node name should show up in the last column: -->
+<!--
+The Node name should show up in the last column: 
+-->
 节点名称应显示在最后一列中：
 
 ```
@@ -457,30 +609,41 @@ NAME      READY     STATUS    RESTARTS   AGE       IP            NODE
 mysql-2   2/2       Running   0          15m       10.244.5.27   kubernetes-node-9l2t
 ```
 
-<!-- Then drain the Node by running the following command, which cordons it so
+<!--
+Then drain the Node by running the following command, which cordons it so
 no new Pods may schedule there, and then evicts any existing Pods.
-Replace `<node-name>` with the name of the Node you found in the last step. -->
-然后通过运行以下命令耗尽节点，该命令将其封锁，以使新的 Pod 不能在那里调度，然后驱逐任何现有的 Pod。
-将 `<node-name>` 替换为在上一步中找到的 Node 的名称。
+Replace `<node-name>` with the name of the Node you found in the last step. 
+-->
+然后通过运行以下命令腾空节点，该命令将其保护起来，以使新的 Pod 不能调度到该节点，
+然后逐出所有现有的 Pod。将 `<节点名称>` 替换为在上一步中找到的节点名称。
 
 
-<!-- This might impact other applications on the Node, so it's best to
-**only do this in a test cluster**. -->
-这可能会影响节点上的其他应用程序，因此最好
-**仅在测试集群中执行此操作**。
+<!--
+This might impact other applications on the Node, so it's best to
+**only do this in a test cluster**. 
 
 ```shell
 kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
 ```
+-->
+这可能会影响节点上的其他应用程序，因此最好 **仅在测试集群中执行此操作**。
 
-<!-- Now you can watch as the Pod reschedules on a different Node: -->
-现在，您可以观察 Pod 在其他节点上的重新安排：
+```shell
+kubectl drain <节点名称> --force --delete-local-data --ignore-daemonsets
+```
+
+<!--
+Now you can watch as the Pod reschedules on a different Node: 
+-->
+现在，你可以看到 Pod 被重新调度到其他节点上：
 
 ```shell
 kubectl get pod mysql-2 -o wide --watch
 ```
 
-<!-- It should look something like this: -->
+<!--
+It should look something like this: 
+-->
 它看起来应该像这样：
 
 ```
@@ -495,44 +658,60 @@ mysql-2   1/2     Running         0          22s       10.244.5.32   kubernetes-
 mysql-2   2/2     Running         0          30s       10.244.5.32   kubernetes-node-fjlm
 ```
 
-<!-- And again, you should see server ID `102` disappear from the
-`SELECT @@server_id` loop output for a while and then return. -->
-再次，您应该看到服务器 ID `102` 从 `SELECT @@server_id` 循环输出一段时间，然后返回。
+<!--
+And again, you should see server ID `102` disappear from the
+`SELECT @@server_id` loop output for a while and then return. 
+-->
+再次，你应该看到服务器 ID `102` 从 `SELECT @@server_id` 循环输出
+中消失一段时间，然后自行出现。
 
-<!-- Now uncordon the Node to return it to a normal state: -->
-现在 uncordon 节点,使其恢复为正常模式:
+<!--
+Now uncordon the Node to return it to a normal state: 
 
 ```shell
 kubectl uncordon <node-name>
 ```
-
-<!-- ## Scaling the number of slaves -->
-## 扩展从节点数量
-
-<!-- With MySQL replication, you can scale your read query capacity by adding slaves.
-With StatefulSet, you can do this with a single command: -->
-使用 MySQL 复制，您可以通过添加从节点来扩展读取查询的能力。
-使用 StatefulSet，您可以使用单个命令执行此操作：
+-->
+现在去掉节点保护（Uncordon），使其恢复为正常模式:
 
 ```shell
-kubectl scale statefulset mysql  --replicas=5
+kubectl uncordon <节点名称>
 ```
 
-<!-- Watch the new Pods come up by running: -->
+<!--
+## Scaling the number of slaves 
+
+With MySQL replication, you can scale your read query capacity by adding slaves.
+With StatefulSet, you can do this with a single command: 
+-->
+## 扩展从节点数量
+
+使用 MySQL 复制，你可以通过添加从节点来扩展读取查询的能力。
+使用 StatefulSet，你可以使用单个命令执行此操作：
+
+```shell
+kubectl scale statefulset mysql --replicas=5
+```
+
+<!--
+Watch the new Pods come up by running: 
+-->
 查看新的 Pod 的运行情况：
 
 ```shell
 kubectl get pods -l app=mysql --watch
 ```
 
-<!-- Once they're up, you should see server IDs `103` and `104` start appearing in
+<!--
+Once they're up, you should see server IDs `103` and `104` start appearing in
 the `SELECT @@server_id` loop output.
 
 You can also verify that these new servers have the data you added before they
-existed: -->
-一旦 Pod 启动，您应该看到服务器 IDs `103` 和 `104` 开始出现在 `SELECT @@server_id` 循环输出中。
+existed: 
+-->
+一旦 Pod 启动，你应该看到服务器 IDs `103` 和 `104` 开始出现在 `SELECT @@server_id` 循环输出中。
 
-您还可以验证这些新服务器在存在之前已添加了数据：
+你还可以验证这些新服务器在存在之前已添加了数据：
 
 ```shell
 kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
@@ -549,29 +728,37 @@ Waiting for pod default/mysql-client to be running, status is Pending, pod ready
 pod "mysql-client" deleted
 ```
 
-<!-- Scaling back down is also seamless: -->
-向下缩放也是不停顿的：
+<!--
+Scaling back down is also seamless: 
+-->
+向下缩容操作也是很平滑的：
 
 ```shell
 kubectl scale statefulset mysql --replicas=3
 ```
 
-<!-- Note, however, that while scaling up creates new PersistentVolumeClaims
+<!--
+Note, however, that while scaling up creates new PersistentVolumeClaims
 automatically, scaling down does not automatically delete these PVCs.
 This gives you the choice to keep those initialized PVCs around to make
-scaling back up quicker, or to extract data before deleting them. -->
-但是请注意，按比例放大会自动创建新的 PersistentVolumeClaims，而按比例缩小不会自动删除这些 PVC。
-这使您可以选择保留那些初始化的 PVC，以更快地进行缩放，或者在删除它们之前提取数据。
+scaling back up quicker, or to extract data before deleting them. 
+-->
+但是请注意，按比例扩大会自动创建新的 PersistentVolumeClaims，而按比例缩小不会自动删除这些 PVC。
+这使你可以选择保留那些初始化的 PVC，以更快地进行缩放，或者在删除它们之前提取数据。
 
-<!-- You can see this by running: -->
-您可以通过运行以下命令查看此信息：
+<!--
+You can see this by running: 
+-->
+你可以通过运行以下命令查看此信息：
 
 ```shell
 kubectl get pvc -l app=mysql
 ```
 
-<!-- Which shows that all 5 PVCs still exist, despite having scaled the
-StatefulSet down to 3: -->
+<!--
+Which shows that all 5 PVCs still exist, despite having scaled the
+StatefulSet down to 3: 
+-->
 这表明，尽管将 StatefulSet 缩小为3，所有5个 PVC 仍然存在：
 
 ```
@@ -583,77 +770,89 @@ data-mysql-3   Bound     pvc-50043c45-b1c5-11e6-93fa-42010a800002   10Gi       R
 data-mysql-4   Bound     pvc-500a9957-b1c5-11e6-93fa-42010a800002   10Gi       RWO           2m
 ```
 
-<!-- If you don't intend to reuse the extra PVCs, you can delete them: -->
-如果您不打算重复使用多余的 PVC，则可以删除它们：
+<!--
+If you don't intend to reuse the extra PVCs, you can delete them: 
+-->
+如果你不打算重复使用多余的 PVC，则可以删除它们：
 
 ```shell
 kubectl delete pvc data-mysql-3
 kubectl delete pvc data-mysql-4
 ```
 
-
-
 ## {{% heading "cleanup" %}}
 
 
-<!-- 1. Cancel the `SELECT @@server_id` loop by pressing **Ctrl+C** in its terminal,
-   or running the following from another terminal: -->
+<!--
+1. Cancel the `SELECT @@server_id` loop by pressing **Ctrl+C** in its terminal,
+   or running the following from another terminal: 
+-->
 1. 通过在终端上按 **Ctrl+C** 取消 `SELECT @@server_id` 循环，或从另一个终端运行以下命令：
 
    ```shell
    kubectl delete pod mysql-client-loop --now
    ```
 
-<!-- 1. Delete the StatefulSet. This also begins terminating the Pods. -->
-1. 删除 StatefulSet。这也开始终止 Pod。
+<!--
+1. Delete the StatefulSet. This also begins terminating the Pods. 
+-->
+2. 删除 StatefulSet。这也会开始终止 Pod。
 
    ```shell
    kubectl delete statefulset mysql
    ```
 
-<!-- 1. Verify that the Pods disappear.
-   They might take some time to finish terminating. -->
-1. 验证 Pod 消失。
-   他们可能需要一些时间才能完成终止。
+<!--
+1. Verify that the Pods disappear.
+   They might take some time to finish terminating. 
+-->
+3. 验证 Pod 消失。他们可能需要一些时间才能完成终止。
 
    ```shell
    kubectl get pods -l app=mysql
    ```
 
    <!-- You'll know the Pods have terminated when the above returns: -->
-   当以上内容返回时，您将知道 Pod 已终止：
+   当上述命令返回如下内容时，你就知道 Pod 已终止：
 
    ```
    No resources found.
    ```
 
-<!-- 1. Delete the ConfigMap, Services, and PersistentVolumeClaims. -->
-1. 删除 ConfigMap，Services 和 PersistentVolumeClaims。
+<!--
+1. Delete the ConfigMap, Services, and PersistentVolumeClaims. 
+-->
+4. 删除 ConfigMap、Services 和 PersistentVolumeClaims。
 
    ```shell
    kubectl delete configmap,service,pvc -l app=mysql
    ```
 
-<!-- 1. If you manually provisioned PersistentVolumes, you also need to manually
+<!--
+1. If you manually provisioned PersistentVolumes, you also need to manually
    delete them, as well as release the underlying resources.
    If you used a dynamic provisioner, it automatically deletes the
    PersistentVolumes when it sees that you deleted the PersistentVolumeClaims.
    Some dynamic provisioners (such as those for EBS and PD) also release the
-   underlying resources upon deleting the PersistentVolumes. -->
-1. 如果您手动设置 PersistentVolume，则还需要手动删除它们，并释放基础资源。
-   如果您使用了动态预配器，当得知您删除 PersistentVolumeClaims 时，它将自动删除 PersistentVolumes。
-   一些动态预配器(例如用于 EBS 和 PD 的预配器)也会在删除 PersistentVolumes 时释放基础资源。
-
-
+   underlying resources upon deleting the PersistentVolumes. 
+-->
+5. 如果你手动供应 PersistentVolume，则还需要手动删除它们，并释放下层资源。
+   如果你使用了动态预配器，当得知你删除 PersistentVolumeClaims 时，它将自动删除 PersistentVolumes。
+   一些动态预配器（例如用于 EBS 和 PD 的预配器）也会在删除 PersistentVolumes 时释放下层资源。
 
 ## {{% heading "whatsnext" %}}
 
-
-<!-- * Look in the [Helm Charts repository](https://github.com/kubernetes/charts)
-  for other stateful application examples. -->
-* 在[Helm Charts 存储库](https://github.com/kubernetes/charts)中查找其他有状态的应用程序示例。
-
-
-
-
+<!--
+* Learn more about [scaling a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
+* Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
+* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
+* Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+* Look in the [Helm Charts repository](https://github.com/kubernetes/charts)
+  for other stateful application examples.
+-->
+* 进一步了解[为 StatefulSet 扩缩容](/zh/docs/tasks/run-application/scale-stateful-set/).
+* 进一步了解[调试 StatefulSet](/zh/docs/tasks/debug-application-cluster/debug-stateful-set/).
+* 进一步了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/).
+* 进一步了解[强制删除 StatefulSet Pods](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/).
+* 在[Helm Charts 仓库](https://github.com/kubernetes/charts)中查找其他有状态的应用程序示例。
 
diff --git a/content/zh/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/zh/docs/tasks/run-application/run-single-instance-stateful-application.md
index 5bd417375a..f2cd9de27c 100644
--- a/content/zh/docs/tasks/run-application/run-single-instance-stateful-application.md
+++ b/content/zh/docs/tasks/run-application/run-single-instance-stateful-application.md
@@ -1,123 +1,174 @@
 ---
 title: 运行一个单实例有状态应用
 content_type: tutorial
+weight: 20
 ---
 
 <!-- overview -->
 
-本文介绍在 Kubernetes 中使用 PersistentVolume 和 Deployment 如何运行一个单实例有状态应用. 该应用是 MySQL.
-
-
-
+<!--
+This page shows you how to run a single-instance stateful application
+in Kubernetes using a PersistentVolume and a Deployment. The
+application is MySQL.
+-->
+本文介绍在 Kubernetes 中如何使用 PersistentVolume 和 Deployment 运行一个单实例有状态应用。该应用是 MySQL.
 
 ## {{% heading "objectives" %}}
 
-
-* 在环境中通过磁盘创建一个PersistentVolume.
-* 创建一个MySQL Deployment.
-* 在集群内以一个已知的 DNS 名将 MySQL 暴露给其他 pods.
-
-
-
+<!--
+* Create a PersistentVolume referencing a disk in your environment.
+* Create a MySQL Deployment.
+* Expose MySQL to other pods in the cluster at a known DNS name.
+-->
+* 在你的环境中创建一个引用磁盘的 PersistentVolume
+* 创建一个 MySQL Deployment.
+* 在集群内以一个已知的 DNS 名称将 MySQL 暴露给其他 Pod
 
 ## {{% heading "prerequisites" %}}
 
-
 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
 * {{< include "default-storage-class-prereqs.md" >}}
 
-
-
 <!-- lessoncontent -->
 
-## 部署MySQL
+## 部署 MySQL   {#deploy-mysql}
 
-注意: 在配置的 yaml 文件中定义密码的做法是不安全的. 具体安全解决方案请参考
-[Kubernetes Secrets](/docs/concepts/configuration/secret/).
+<!--
+You can run a stateful application by creating a Kubernetes Deployment
+and connecting it to an existing PersistentVolume using a
+PersistentVolumeClaim.  For example, this YAML file describes a
+Deployment that runs MySQL and references the PersistentVolumeClaim. The file
+defines a volume mount for /var/lib/mysql, and then creates a
+PersistentVolumeClaim that looks for a 20G volume. This claim is
+satisfied by any existing volume that meets the requirements,
+or by a dynamic provisioner.
+-->
+你可以通过创建一个 Kubernetes Deployment 并使用 PersistentVolumeClaim 将其连接到
+某已有的 PV 卷来运行一个有状态的应用。
+例如，这里的 YAML 描述的是一个运行 MySQL 的 Deployment，其中引用了 PVC 申领。
+文件为 /var/lib/mysql 定义了加载卷，并创建了一个 PVC 申领，寻找一个 20G 大小的卷。
+该申领可以通过现有的满足需求的卷来满足，也可以通过动态供应卷的机制来满足。
+
+<!--
+Note: The password is defined in the config yaml, and this is insecure. See
+[Kubernetes Secrets](/docs/concepts/configuration/secret/)
+for a secure solution.
+-->
+注意：在配置的 YAML 文件中定义密码的做法是不安全的。具体安全解决方案请参考
+[Kubernetes Secrets](/zh/docs/concepts/configuration/secret/).
 
 {{< codenew file="application/mysql/mysql-deployment.yaml" >}}
 {{< codenew file="application/mysql/mysql-pv.yaml" >}}
 
-1. 部署 YAML 文件中定义的 PV 和 PVC：
+1. <!--Deploy the PV and PVC of the YAML file-->
+   部署 YAML 文件中定义的 PV 和 PVC：
 
-        kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
+   ```
 
-1. 部署 YAML 文件中定义的 Deployment：
+1. <!-- Deploy the contents of the YAML file -->
+   部署 YAML 文件中定义的 Deployment：
 
-        kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
+   ```
 
-1. 展示 Deployment 相关信息:
+1. <!-- Display information about the Deployment -->
+   展示 Deployment 相关信息:
 
-        kubectl describe deployment mysql
+   ```shell
+   kubectl describe deployment mysql
+   ```
 
-        Name:                 mysql
-        Namespace:            default
-        CreationTimestamp:    Tue, 01 Nov 2016 11:18:45 -0700
-        Labels:               app=mysql
-        Annotations:          deployment.kubernetes.io/revision=1
-        Selector:             app=mysql
-        Replicas:             1 desired | 1 updated | 1 total | 0 available | 1 unavailable
-        StrategyType:         Recreate
-        MinReadySeconds:      0
-        Pod Template:
-          Labels:       app=mysql
-          Containers:
-           mysql:
-            Image:      mysql:5.6
-            Port:       3306/TCP
-            Environment:
-              MYSQL_ROOT_PASSWORD:      password
-            Mounts:
-              /var/lib/mysql from mysql-persistent-storage (rw)
-          Volumes:
-           mysql-persistent-storage:
-            Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
-            ClaimName:  mysql-pv-claim
-            ReadOnly:   false
-            Conditions:
-              Type          Status  Reason
-              ----          ------  ------
-              Available     False   MinimumReplicasUnavailable
-              Progressing   True    ReplicaSetUpdated
-              OldReplicaSets:       <none>
-              NewReplicaSet:        mysql-63082529 (1/1 replicas created)
-              Events:
-                FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
-                ---------    --------    -----    ----                -------------    --------    ------            -------
-                33s          33s         1        {deployment-controller }             Normal      ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
+   ```
+   Name:                 mysql
+   Namespace:            default
+   CreationTimestamp:    Tue, 01 Nov 2016 11:18:45 -0700
+   Labels:               app=mysql
+   Annotations:          deployment.kubernetes.io/revision=1
+   Selector:             app=mysql
+   Replicas:             1 desired | 1 updated | 1 total | 0 available | 1 unavailable
+   StrategyType:         Recreate
+   MinReadySeconds:      0
+   Pod Template:
+     Labels:       app=mysql
+     Containers:
+      mysql:
+       Image:      mysql:5.6
+       Port:       3306/TCP
+       Environment:
+         MYSQL_ROOT_PASSWORD:      password
+       Mounts:
+         /var/lib/mysql from mysql-persistent-storage (rw)
+     Volumes:
+      mysql-persistent-storage:
+       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
+       ClaimName:  mysql-pv-claim
+       ReadOnly:   false
+       Conditions:
+         Type          Status  Reason
+         ----          ------  ------
+         Available     False   MinimumReplicasUnavailable
+         Progressing   True    ReplicaSetUpdated
+         OldReplicaSets:       <none>
+         NewReplicaSet:        mysql-63082529 (1/1 replicas created)
+         Events:
+           FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
+           ---------    --------    -----    ----                -------------    --------    ------            -------
+           33s          33s         1        {deployment-controller }             Normal      ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
+   ```
+
+1. <!-- List the pods created by the Deployment -->
+   列举出 Deployment 创建的 pods:
+
+   ```shell
+   kubectl get pods -l app=mysql
+   ```
+
+   ```
+   NAME                   READY     STATUS    RESTARTS   AGE
+   mysql-63082529-2z3ki   1/1       Running   0          3m
+   ```
+
+1. <!-- Inspect the PersistentVolumeClaim -->
+   查看 PersistentVolumeClaim：
+
+   ```shell
+   kubectl describe pvc mysql-pv-claim
+   ```
+
+   ```
+   Name:         mysql-pv-claim
+   Namespace:    default
+   StorageClass:
+   Status:       Bound
+   Volume:       mysql-pv-volume
+   Labels:       <none>
+   Annotations:    pv.kubernetes.io/bind-completed=yes
+                   pv.kubernetes.io/bound-by-controller=yes
+   Capacity:     20Gi
+   Access Modes: RWO
+   Events:       <none>
+   ```
+
+<!--
+## Accessing the MySQL instance
+
+The preceding YAML file creates a service that
+allows other Pods in the cluster to access the database. The Service option
+`clusterIP: None` lets the Service DNS name resolve directly to the
+Pod's IP address. This is optimal when you have only one Pod
+behind a Service and you don't intend to increase the number of Pods.
+
+Run a MySQL client to connect to the server:
+-->
+## 访问 MySQL 实例   {#accessing-the-mysql-instance}
 
 
-1. 列举出 Deployment 创建的 pods:
-
-        kubectl get pods -l app=mysql
-
-        NAME                   READY     STATUS    RESTARTS   AGE
-        mysql-63082529-2z3ki   1/1       Running   0          3m
-
-1. 查看 PersistentVolumeClaim:
-
-        kubectl describe pvc mysql-pv-claim
-
-        Name:         mysql-pv-claim
-        Namespace:    default
-        StorageClass:
-        Status:       Bound
-        Volume:       mysql-pv-volume
-        Labels:       <none>
-        Annotations:    pv.kubernetes.io/bind-completed=yes
-                        pv.kubernetes.io/bound-by-controller=yes
-        Capacity:     20Gi
-        Access Modes: RWO
-        Events:       <none>
-
-## 访问 MySQL 实例
-
-
-前面 YAML 文件中创建了一个允许集群内其他 pods 访问数据库的服务. 该服务中选项
-`clusterIP: None` 让服务 DNS 名称直接解析为 Pod 的 IP 地址. 当在一个服务下只有一个 pod
-并且不打算增加 pods 的数量这是最好的.
-
+前面 YAML 文件中创建了一个允许集群内其他 Pod 访问的数据库服务。该服务中选项
+`clusterIP: None` 让服务 DNS 名称直接解析为 Pod 的 IP 地址。
+当在一个服务下只有一个 Pod 并且不打算增加 Pod 的数量这是最好的.
 
 运行 MySQL 客户端以连接到服务器:
 
@@ -125,7 +176,13 @@ content_type: tutorial
 kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
 ```
 
-此命令在集群内创建一个新的 Pod 并运行 MySQL 客户端,并通过 Service 将其连接到服务器.如果连接成功,你就知道有状态的 MySQL 数据库正处于运行状态.
+<!--
+This command creates a new Pod in the cluster running a MySQL client
+and connects it to the server through the Service. If it connects, you
+know your stateful MySQL database is up and running.
+-->
+此命令在集群内创建一个新的 Pod 并运行 MySQL 客户端，并通过 Service 连接到服务器。
+如果连接成功，你就知道有状态的 MySQL 数据库正处于运行状态。
 
 ```
 Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
@@ -134,20 +191,43 @@ If you don't see a command prompt, try pressing enter.
 mysql>
 ```
 
-## 更新
+<!--
+## Updating
 
+The image or any other part of the Deployment can be updated as usual
+with the `kubectl apply` command. Here are some precautions that are
+specific to stateful apps:
+-->
+## 更新   {#updating}
 
-Deployment 中镜像或其他部分同往常一样可以通过 `kubectl apply` 命令更新. 以下是
-特定于有状态应用的一些注意事项:
+Deployment 中镜像或其他部分同往常一样可以通过 `kubectl apply` 命令更新。
+以下是特定于有状态应用的一些注意事项:
 
-* 不要弹性伸缩. 弹性伸缩仅适用于单实例应用. 下层的 PersistentVolume 仅只能挂载一个 pod. 对于集群级有状态应用, 请参考 StatefulSet 文档
+<!--
+* Don't scale the app. This setup is for single-instance apps
+  only. The underlying PersistentVolume can only be mounted to one
+  Pod. For clustered stateful apps, see the
   [StatefulSet documentation](/docs/concepts/workloads/controllers/statefulset/).
-* 在 Deployment 的 YAML 文件中使用 `strategy:` `type: Recreate` . 该选项指示 Kubernetes 不使用滚动升级. 滚动升级将无法工作, 由于一次不能运行多个 pod. 在更新配置文件
-创建一个新的 pod 前 `Recreate` 策略将先停止第一个 pod.
+* Use `strategy:` `type: Recreate` in the Deployment configuration
+  YAML file. This instructs Kubernetes to _not_ use rolling
+  updates. Rolling updates will not work, as you cannot have more than
+  one Pod running at a time. The `Recreate` strategy will stop the
+  first pod before creating a new one with the updated configuration.
+-->
+* 不要对应用进行规模扩缩。这里的设置仅适用于单实例应用。下层的 PersistentVolume
+  仅只能挂载到一个 Pod 上。对于集群级有状态应用，请参考
+  [StatefulSet 文档](/zh/docs/concepts/workloads/controllers/statefulset/).
+* 在 Deployment 的 YAML 文件中使用 `strategy:` `type: Recreate`。
+  该选项指示 Kubernetes _不_ 使用滚动升级。滚动升级无法工作，因为这里一次不能
+  运行多个 Pod。在使用更新的配置文件创建新的 Pod 前，`Recreate` 策略将
+  保证先停止第一个 Pod。
 
+<!--
+## Deleting a deployment
 
-## 删除 Deployment
-
+Delete the deployed objects by name:
+-->
+## 删除 Deployment    {#deleting-a-deployment}
 
 通过名称删除部署的对象:
 
@@ -157,23 +237,35 @@ kubectl delete pvc mysql-pv-claim
 kubectl delete pv mysql-pv-volume
 ```
 
-如果通过手动的方式分配 PersistentVolume, 那么也需要手动的删除它，以及释放下层资源.
-如果是用过动态分配 PersistentVolume 的方式，在删除 PersistentVolumeClaim 后 PersistentVolume 将被自动的删除. 一些存储服务(比如 EBS 和 PD)也会在 PersistentVolume 被删除时自动回收下层资源.
-
-
-
+<!--
+If you manually provisioned a PersistentVolume, you also need to manually
+delete it, as well as release the underlying resource.
+If you used a dynamic provisioner, it automatically deletes the
+PersistentVolume when it sees that you deleted the PersistentVolumeClaim.
+Some dynamic provisioners (such as those for EBS and PD) also release the
+underlying resource upon deleting the PersistentVolume.
+-->
+如果通过手动的方式供应 PersistentVolume, 那么也需要手动删除它以释放下层资源。
+如果是用动态供应方式创建的 PersistentVolume，在删除 PersistentVolumeClaim 后
+PersistentVolume 将被自动删除。
+一些存储服务（比如 EBS 和 PD）也会在 PersistentVolume 被删除时自动回收下层资源。
 
 ## {{% heading "whatsnext" %}}
 
+<!--
+* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
 
-* 了解更多 Deployment 对象请参考 [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
+* Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/)
 
-* 了解更多 Deployment 应用请参考 [Deploying applications](/docs/user-guide/deploying-applications/)
-
-* kubectl run 文档请参考[kubectl run documentation](/docs/reference/generated/kubectl/kubectl-commands/#run)
-
-* 卷和持久卷请参考 [Volumes](/docs/concepts/storage/volumes/) 和 [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
+* [kubectl run documentation](/docs/reference/generated/kubectl/kubectl-commands/#run)
 
+* [Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
+-->
+* 欲进一步了解 Deployment 对象，请参考 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)
+* 进一步了解[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
 
+* 参阅 [kubectl run 文档](/docs/reference/generated/kubectl/kubectl-commands/#run)
+
+* 参阅[卷](/zh/docs/concepts/storage/volumes/)和[持久卷](/zh/docs/concepts/storage/persistent-volumes/)
 
 
diff --git a/content/zh/docs/tasks/run-application/run-stateless-application-deployment.md b/content/zh/docs/tasks/run-application/run-stateless-application-deployment.md
index a925a0d919..8ecb0810a2 100644
--- a/content/zh/docs/tasks/run-application/run-stateless-application-deployment.md
+++ b/content/zh/docs/tasks/run-application/run-stateless-application-deployment.md
@@ -5,143 +5,237 @@ content_type: tutorial
 
 <!-- overview -->
 
+<!--
+This page shows how to run an application using a Kubernetes Deployment object.
+-->
 本文介绍通过Kubernetes Deployment对象如何去运行一个应用.
 
-
-
-
 ## {{% heading "objectives" %}}
 
-
-* 创建一个nginx deployment.
-* 使用kubectl列举关于deployment信息.
-* 更新deployment.
-
-
-
+<!--
+* Create an nginx deployment.
+* Use kubectl to list information about the deployment.
+* Update the deployment.
+-->
+* 创建一个 nginx Deployment.
+* 使用 kubectl 列举关于 Deployment 的信息.
+* 更新 Deployment。
 
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
-
 <!-- lessoncontent -->
 
-## 创建和探究一个nginx deployment
+<!--
+## Creating and exploring an nginx deployment
 
-你可以通过创建一个Kubernetes Deployment对象来运行一个应用, 可以在一个YAML文件中描述Deployment. 例如, 下面这个YAML文件描述了一个运行nginx:1.7.9 Docker镜像的Deployment:
+You can run an application by creating a Kubernetes Deployment object, and you
+can describe a Deployment in a YAML file. For example, this YAML file describes
+a Deployment that runs the nginx:1.14.2 Docker image:
+-->
+## 创建并了解一个 nginx Deployment
+
+你可以通过创建一个 Kubernetes Deployment 对象来运行一个应用, 且你可以在一个
+YAML 文件中描述 Deployment。例如, 下面这个 YAML 文件描述了一个运行 nginx:1.7.9
+Docker 镜像的 Deployment：
 
 {{< codenew file="application/deployment.yaml" >}}
 
+<!--
+1. Create a Deployment based on the YAML file:
+-->
+1. 通过 YAML 文件创建一个 Deployment：
 
-1. 通过YAML文件创建一个Deployment:
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/deployment.yaml
+   ```
 
-        kubectl apply -f https://k8s.io/examples/application/deployment.yaml
+<!--
+1. Display information about the Deployment:
+-->
+2. 显示 Deployment 相关信息：
 
-1. 展示Deployment相关信息:
+   ```shell
+   kubectl describe deployment nginx-deployment
+   ```
 
-       kubectl describe deployment nginx-deployment
+   <!-- 
+   The output is similar to this:
+   -->
+   输出类似于这样：
 
-        user@computer:~/website$ kubectl describe deployment nginx-deployment
-        Name:     nginx-deployment
-        Namespace:    default
-        CreationTimestamp:  Tue, 30 Aug 2016 18:11:37 -0700
-        Labels:     app=nginx
-        Annotations:    deployment.kubernetes.io/revision=1
-        Selector:   app=nginx
-        Replicas:   2 desired | 2 updated | 2 total | 2 available | 0 unavailable
-        StrategyType:   RollingUpdate
-        MinReadySeconds:  0
-        RollingUpdateStrategy:  1 max unavailable, 1 max surge
-        Pod Template:
-          Labels:       app=nginx
-          Containers:
-           nginx:
-            Image:              nginx:1.7.9
-            Port:               80/TCP
-            Environment:        <none>
-            Mounts:             <none>
-          Volumes:              <none>
-        Conditions:
-          Type          Status  Reason
-          ----          ------  ------
-          Available     True    MinimumReplicasAvailable
-          Progressing   True    NewReplicaSetAvailable
-        OldReplicaSets:   <none>
-        NewReplicaSet:    nginx-deployment-1771418926 (2/2 replicas created)
-        No events.
+   ```
+   Name:     nginx-deployment
+   Namespace:    default
+   CreationTimestamp:  Tue, 30 Aug 2016 18:11:37 -0700
+   Labels:     app=nginx
+   Annotations:    deployment.kubernetes.io/revision=1
+   Selector:   app=nginx
+   Replicas:   2 desired | 2 updated | 2 total | 2 available | 0 unavailable
+   StrategyType:   RollingUpdate
+   MinReadySeconds:  0
+   RollingUpdateStrategy:  1 max unavailable, 1 max surge
+   Pod Template:
+     Labels:       app=nginx
+     Containers:
+      nginx:
+       Image:              nginx:1.7.9
+       Port:               80/TCP
+       Environment:        <none>
+       Mounts:             <none>
+     Volumes:              <none>
+   Conditions:
+     Type          Status  Reason
+     ----          ------  ------
+     Available     True    MinimumReplicasAvailable
+     Progressing   True    NewReplicaSetAvailable
+   OldReplicaSets:   <none>
+   NewReplicaSet:    nginx-deployment-1771418926 (2/2 replicas created)
+   No events.
+   ```
 
-1. 列出deployment创建的pods:
+<!--
+1. List the Pods created by the deployment:
+-->
+3. 列出 Deployment 创建的 Pods：
 
-       kubectl get pods -l app=nginx
+   ```shell
+   kubectl get pods -l app=nginx
+   ```
 
-        NAME                                READY     STATUS    RESTARTS   AGE
-        nginx-deployment-1771418926-7o5ns   1/1       Running   0          16h
-        nginx-deployment-1771418926-r18az   1/1       Running   0          16h
+   <!--
+   The output is similar to this:
+   -->
+   输出类似于这样：
 
-1. 展示某一个pod信息:
+   ```
+   NAME                                READY     STATUS    RESTARTS   AGE
+   nginx-deployment-1771418926-7o5ns   1/1       Running   0          16h
+   nginx-deployment-1771418926-r18az   1/1       Running   0          16h
+   ```
 
-       kubectl describe pod <pod-name>
+<!--
+1. Display information about a Pod:
+-->
+4. 展示某一个 Pod 信息：
 
-    该处 `<pod-name>` 指某一pod的名称.
+   ```shell
+   kubectl describe pod <pod-name>
+   ```
 
-## 更新deployment
+   <!--
+   where `<pod-name>` is the name of one of your Pods.
+   -->
+   这里的 `<pod-name>` 是某一 Pod 的名称。
 
-你可以通过更新一个新的YAML文件来更新deployment. 下面的YAML文件指定该deployment镜像更新为nginx 1.8.
+<!--
+## Updating the deployment
+
+You can update the deployment by applying a new YAML file. This YAML file
+specifies that the deployment should be updated to use nginx 1.16.1.
+-->
+## 更新 Deployment
+
+你可以通过更新一个新的 YAML 文件来更新 Deployment。下面的 YAML 文件指定该
+Deployment 镜像更新为 nginx 1.16.1。
 
 {{< codenew file="application/deployment-update.yaml" >}}
 
-1. 应用新的YAML:
+<!--
+1. Apply the new YAML file:
+-->
+1. 应用新的 YAML：
 
-         kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
+   ```
 
-1. 查看该deployment创建的pods以新的名称同时删除旧的pods:
+<!--
+1. Watch the deployment create pods with new names and delete the old pods:
+-->
+2. 查看该 Deployment 以新的名称创建 Pods 同时删除旧的 Pods：
 
-         kubectl get pods -l app=nginx
+   ```shell
+   kubectl get pods -l app=nginx
+   ```
+<!--
+## Scaling the application by increasing the replica count
 
-## 通过增加副本数来弹缩应用
+You can increase the number of Pods in your Deployment by applying a new YAML
+file. This YAML file sets `replicas` to 4, which specifies that the Deployment
+should have four Pods:
+-->
+## 通过增加副本数来扩缩应用
 
-你可以通过应用新的YAML文件来增加Deployment中pods的数量. 该YAML文件将`replicas`设置为4, 指定该Deployment应有4个pods:
+你可以通过应用新的 YAML 文件来增加 Deployment 中 Pods 的数量。
+下面的 YAML 文件将 `replicas` 设置为 4，指定该 Deployment 应有 4 个 Pods：
 
 {{< codenew file="application/deployment-scale.yaml" >}}
 
-1. 应用新的YAML文件:
+<!--
+1. Apply the new YAML file:
+-->
+1. 应用新的 YAML 文件：
 
-        kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
+   ```shell
+   kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
+   ```
 
-1. 验证Deployment有4个pods:
+<!--
+1. Verify that the Deployment has four Pods:
+-->
+2. 验证 Deployment 有 4 个 Pods：
 
-        kubectl get pods -l app=nginx
+   ```shell
+   kubectl get pods -l app=nginx
+   ```
 
-    输出的结果类似于:
+   <!--
+   The output is similar to this:
+   -->
+   输出的结果类似于:
 
-        NAME                               READY     STATUS    RESTARTS   AGE
-        nginx-deployment-148880595-4zdqq   1/1       Running   0          25s
-        nginx-deployment-148880595-6zgi1   1/1       Running   0          25s
-        nginx-deployment-148880595-fxcez   1/1       Running   0          2m
-        nginx-deployment-148880595-rwovn   1/1       Running   0          2m
+   ```
+   NAME                               READY     STATUS    RESTARTS   AGE
+   nginx-deployment-148880595-4zdqq   1/1       Running   0          25s
+   nginx-deployment-148880595-6zgi1   1/1       Running   0          25s
+   nginx-deployment-148880595-fxcez   1/1       Running   0          2m
+   nginx-deployment-148880595-rwovn   1/1       Running   0          2m
+   ```
 
-## 删除deployment
+<!--
+## Deleting a deployment
 
-通过名称删除deployment:
+Delete the deployment by name:
+-->
+## 删除 Deployment
 
-    kubectl delete deployment nginx-deployment
+通过名称删除 Deployment：
 
+```shell
+kubectl delete deployment nginx-deployment
+```
+
+<!--
+## ReplicationControllers -- the Old Way
+
+The preferred way to create a replicated application is to use a Deployment,
+which in turn uses a ReplicaSet. Before the Deployment and ReplicaSet were
+added to Kubernetes, replicated applications were configured using a
+[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+-->
 ## ReplicationControllers -- 旧的方式
 
-创建一个多副本应用首选方法是使用Deployment,反过来使用ReplicaSet. 在Deployment和ReplicaSet加入到Kubernetes之前, 多副本应用通过[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)来配置.
-
-
-
+创建一个多副本应用首选方法是使用 Deployment，Deployment 内部使用 ReplicaSet。
+在 Deployment 和 ReplicaSet 被引入到 Kubernetes 之前，多副本应用通过
+[ReplicationController](/zh/docs/concepts/workloads/controllers/replicationcontroller/)
+来配置。
 
 ## {{% heading "whatsnext" %}}
 
-
-* 了解更多 [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
-
-
-
+<!--
+* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
+-->
+* 进一步了解 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)。
 
diff --git a/content/zh/docs/tasks/service-catalog/_index.md b/content/zh/docs/tasks/service-catalog/_index.md
index 3677ab2db0..1d12ab1465 100644
--- a/content/zh/docs/tasks/service-catalog/_index.md
+++ b/content/zh/docs/tasks/service-catalog/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "安装服务目录"
 weight: 150
+description: 安装服务目录扩展 API。
 ---
diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 5e102f790c..ecc001e62d 100644
--- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -32,7 +32,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
     * Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md).
     * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
 -->
-* 理解[服务目录](/zh/docs/concepts/service-catalog/) 的关键概念。
+* 理解[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) 的关键概念。
 * Service Catalog 需要 Kubernetes 集群版本在 1.7 或更高版本。
 * 你必须启用 Kubernetes 集群的 DNS 功能。
     * 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}}，则可能已经启用了集群 DNS。
@@ -156,4 +156,3 @@ helm install svc-cat/catalog --name catalog --namespace catalog
 -->
 * 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。
 * 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
-
diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
index 3139539017..e2092df9bf 100644
--- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -39,10 +39,12 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
 * 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。
 * 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。
 * 服务目录需要 Kubernetes 1.7+ 版本。
-* [安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/)，以便将其配置为连接到 Kubernetes v1.7+ 集群。
-* 要安装服务目录，kubectl 用户必须绑定到 *cluster-admin* 角色。为了确保这是正确的，请运行以下命令：
+* [安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/)，
+  以便将其配置为连接到 Kubernetes v1.7+ 集群。
+* 要安装服务目录，kubectl 用户必须绑定到 *cluster-admin* 角色。
+  为了确保这是正确的，请运行以下命令：
 
-  ```
+  ```shell
   kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
   ```
 
@@ -113,9 +115,9 @@ sc uninstall
 
 <!--
 * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
+* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
 -->
-* 查看 [服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。
-* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
+* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。
+* 探索 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目。
 
 
diff --git a/content/zh/docs/tasks/tls/_index.md b/content/zh/docs/tasks/tls/_index.md
index 3bf0ceffca..a25b7c5cbe 100644
--- a/content/zh/docs/tasks/tls/_index.md
+++ b/content/zh/docs/tasks/tls/_index.md
@@ -1,4 +1,5 @@
 ---
 title: "TLS"
 weight: 100
+description: 了解如何使用传输层安全性（ TLS ）保护集群中的流量。
 ---
diff --git a/content/zh/docs/tasks/tls/certificate-rotation.md b/content/zh/docs/tasks/tls/certificate-rotation.md
index 681a6f3a18..176bab6170 100644
--- a/content/zh/docs/tasks/tls/certificate-rotation.md
+++ b/content/zh/docs/tasks/tls/certificate-rotation.md
@@ -16,7 +16,7 @@ This page shows how to enable and configure certificate rotation for the kubelet
 -->
 本文展示如何在 kubelet 中启用并配置证书轮换。
 
-{{< feature-state for_k8s_version="v1.8" state="beta" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
 
 ## {{% heading "prerequisites" %}}
 
@@ -58,23 +58,21 @@ Kubernetes API 间的连接认证。
 
 The `kubelet` process accepts an argument `--rotate-certificates` that controls
 if the kubelet will automatically request a new certificate as the expiration of
-the certificate currently in use approaches.  Since certificate rotation is a
-beta feature, the feature flag must also be enabled with
-`--feature-gates=RotateKubeletClientCertificate=true`.
+the certificate currently in use approaches.
 -->
 ## 启用客户端证书轮换
 
- `kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的证书即将到期时，
-是否会自动申请新的证书。 由于证书轮换是 beta 特性，必须通过参数
-`--feature-gates=RotateKubeletClientCertificate=true` 进行启用。
+ `kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的
+证书即将到期时，是否会自动申请新的证书。
 
 <!--
 The `kube-controller-manager` process accepts an argument
-`--experimental-cluster-signing-duration` that controls how long certificates
-will be issued for.
+`--cluster-signing-duration`  (`--experimental-cluster-signing-duration` prior to 1.19)
+that controls how long certificates will be issued for.
 -->
-`kube-controller-manager` 进程接收
-`--experimental-cluster-signing-duration` 参数，该参数控制证书签发的有效期限。
+`kube-controller-manager` 进程接收 `--cluster-signing-duration` 参数
+（在 1.19 版本之前为 `--experimental-cluster-signing-duration`），用来
+控制签发证书的有效期限。
 
 <!--
 ## Understanding the certificate rotation configuration
@@ -86,10 +84,11 @@ status of certificate signing requests using:
 -->
 ## 理解证书轮换配置
 
-当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet 会使用其初始证书连接到
-Kubernetes API ，并发送证书签名的请求。 可以通过以下方式查看证书签名请求的状态：
+当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet
+会使用其初始证书连接到 Kubernetes API ，并发送证书签名的请求。
+可以通过以下方式查看证书签名请求的状态：
 
-```sh
+```shell
 kubectl get csr
 ```
 
@@ -99,19 +98,20 @@ status of `Pending`. If the certificate signing requests meets specific
 criteria, it will be auto approved by the controller manager, then it will have
 a status of `Approved`. Next, the controller manager will sign a certificate,
 issued for the duration specified by the
-`--experimental-cluster-signing-duration` parameter, and the signed certificate
+`--cluster-signing-duration` parameter, and the signed certificate
 will be attached to the certificate signing requests.
 -->
 最初，来自节点上 kubelet 的证书签名请求处于 `Pending` 状态。 如果证书签名请求满足特定条件，
 控制器管理器会自动批准，此时请求会处于 `Approved` 状态。 接下来，控制器管理器会签署证书，
-证书的有效期限由 `--experimental-cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。
+证书的有效期限由 `--cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。
 
 <!--
 The kubelet will retrieve the signed certificate from the Kubernetes API and
 write that to disk, in the location specified by `--cert-dir`. Then the kubelet
 will use the new certificate to connect to the Kubernetes API.
 -->
-Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir` 参数指定。
+Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir`
+参数指定。
 然后 kubelet 会使用新的证书连接到 Kubernetes API。
 
 <!--
diff --git a/content/zh/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/zh/docs/tasks/tls/managing-tls-in-a-cluster.md
index a5184367d1..726319fd7c 100644
--- a/content/zh/docs/tasks/tls/managing-tls-in-a-cluster.md
+++ b/content/zh/docs/tasks/tls/managing-tls-in-a-cluster.md
@@ -1,25 +1,18 @@
 ---
 title: 管理集群中的 TLS 认证
 content_type: task
-reviewers:
-- mikedanese
-- beacham
-- liggit
 ---
 <!--
----
 title: Manage TLS Certificates in a Cluster
 content_type: task
 reviewers:
 - mikedanese
 - beacham
 - liggit
----
 -->
 
 <!-- overview -->
 <!--
-
 Kubernetes provides a `certificates.k8s.io` API, which lets you provision TLS
 certificates signed by a Certificate Authority (CA) that you control. These CA
 and certificates can be used by your workloads to establish trust.
@@ -27,12 +20,11 @@ and certificates can be used by your workloads to establish trust.
 `certificates.k8s.io` API uses a protocol that is similar to the [ACME
 draft](https://github.com/ietf-wg-acme/acme/).
 -->
+Kubernetes 提供 `certificates.k8s.io` API，可让你配置由你控制的证书颁发机构（CA）
+签名的 TLS 证书。 你的工作负载可以使用这些 CA 和证书来建立信任。
 
-Kubernetes提供一个 `certificates.k8s.io` API，可让您配置
-由您控制的证书颁发机构（CA）签名的TLS证书。 您的工作负载可以使用这些CA和证书来建立信任。
-
-`certificates.k8s.io` API使用的协议类似于[ACME
-草稿](https://github.com/ietf-wg-acme/acme/)。
+`certificates.k8s.io` API使用的协议类似于
+[ACME 草案](https://github.com/ietf-wg-acme/acme/)。
 
 {{< note >}}
 <!--
@@ -41,46 +33,42 @@ dedicated CA. It is possible to configure your cluster to use the cluster root
 CA for this purpose, but you should never rely on this. Do not assume that
 these certificates will validate against the cluster root CA.
 -->
-
-使用`certificates.k8s.io` API创建的证书由
-指定 CA 颁发。 将集群配置为使用集群根目录
-CA 可以达到这个目的，但是您永远不要依赖它。不要以为
+使用 `certificates.k8s.io` API 创建的证书由指定 CA 颁发。将集群配置为使用集群根目录
+CA 可以达到这个目的，但是你永远不要依赖这一假定。不要以为
 这些证书将针对群根目录 CA 进行验证。
 {{< /note >}}
 
-
-
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-
-
 <!-- steps -->
 
 <!--
 ## Trusting TLS in a Cluster
 
+Trusting the custom CA from an application running as a pod usually requires
+some extra application configuration. You will need to add the CA certificate
+bundle to the list of CA certificates that the TLS client or server trusts. For
+example, you would do this with a golang TLS config by parsing the certificate
+chain and adding the parsed certificates to the `RootCAs` field in the
+[`tls.Config`](https://godoc.org/crypto/tls#Config) struct.
 
-Trusting the cluster root CA from an application running as a pod usually
-requires some extra application configuration. You will need to add the CA
-certificate bundle to the list of CA certificates that the TLS client or server
-trusts. For example, you would do this with a golang TLS config by parsing the
-certificate chain and adding the parsed certificates to the `RootCAs` field
-in the [`tls.Config`](https://godoc.org/crypto/tls#Config) struct.
-
-The CA certificate bundle is automatically mounted into pods using the default
-service account at the path `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`.
-If you are not using the default service account, ask a cluster administrator to
-build a configmap containing the certificate bundle that you have access to use.
+You can distribute the CA certificate as a
+[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your
+pods have access to use.
 -->
 ## 集群中的 TLS 信任
 
-让 Pod 中运行的应用程序信任集群根 CA 通常需要一些额外的应用程序配置。您将需要将 CA 证书包添加到 TLS 客户端或服务器信任的 CA 证书列表中。例如，您可以使用 golang TLS 配置通过解析证书链并将解析的证书添加到 [`tls.Config`](https://godoc.org/crypto/tls#Config) 结构中的 `RootCAs` 字段中。
+信任 Pod 中运行的应用程序所提供的 CA 通常需要一些额外的应用程序配置。
+你需要将 CA 证书包添加到 TLS 客户端或服务器信任的 CA 证书列表中。
+例如，你可以使用 Golang TLS 配置通过解析证书链并将解析的证书添加到
+[`tls.Config`](https://godoc.org/crypto/tls#Config) 结构中的 `RootCAs`
+字段中。
 
-CA 证书捆绑包将使用默认服务账户自动加载到 pod 中，路径为 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`。如果您没有使用默认服务账户，请请求集群管理员构建包含您有权访问使用的证书包的 configmap。
+你可以用你的应用能够访问到的
+[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap)
+的形式来发布 CA 证书。
 
 <!--
 ## Requesting a Certificate
@@ -92,12 +80,13 @@ Kubernetes service accessed through DNS.
 This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
 {{< /note >}}
 -->
-## 请求认证
+## 请求证书
 
 以下部分演示如何为通过 DNS 访问的 Kubernetes 服务创建 TLS 证书。
 
 {{< note >}}
-本教程使用 CFSSL：Cloudflare's PKI 和 TLS 工具包[点击此处](https://blog.cloudflare.com/introducing-cfssl/)了解更多信息。
+本教程使用 CFSSL：Cloudflare's PKI 和 TLS 工具包
+[点击此处](https://blog.cloudflare.com/introducing-cfssl/)了解更多信息。
 {{< /note >}}
 
 <!--
@@ -115,41 +104,6 @@ The cfssl tools used in this example can be downloaded at
 
 Generate a private key and certificate signing request (or CSR) by running
 the following command:
-
-```shell
-cat <<EOF | cfssl genkey - | cfssljson -bare server
-{
-  "hosts": [
-    "my-svc.my-namespace.svc.cluster.local",
-    "my-pod.my-namespace.pod.cluster.local",
-    "172.168.0.24",
-    "10.0.34.2"
-  ],
-  "CN": "my-pod.my-namespace.pod.cluster.local",
-  "key": {
-    "algo": "ecdsa",
-    "size": 256
-  }
-}
-EOF
-```
-
-Where `172.168.0.24` is the service's cluster IP,
-`my-svc.my-namespace.svc.cluster.local` is the service's DNS name,
-`10.0.34.2` is the pod's IP and `my-pod.my-namespace.pod.cluster.local`
-is the pod's DNS name. You should see the following output:
-
-```
-2017/03/21 06:48:17 [INFO] generate received request
-2017/03/21 06:48:17 [INFO] received CSR
-2017/03/21 06:48:17 [INFO] generating key: ecdsa-256
-2017/03/21 06:48:17 [INFO] encoded CSR
-```
-
-This command generates two files; it generates `server.csr` containing the PEM
-encoded [pkcs#10](https://tools.ietf.org/html/rfc2986) certification request,
-and `server-key.pem` containing the PEM encoded key to the certificate that
-is still to be created.
 -->
 ## 创建证书签名请求
 
@@ -161,19 +115,33 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
   "hosts": [
     "my-svc.my-namespace.svc.cluster.local",
     "my-pod.my-namespace.pod.cluster.local",
-    "172.168.0.24",
+    "192.0.2.24",
     "10.0.34.2"
   ],
-  "CN": "my-pod.my-namespace.pod.cluster.local",
+  "CN": "system:node:my-pod.my-namespace.pod.cluster.local",
   "key": {
     "algo": "ecdsa",
     "size": 256
-  }
+  },
+  "names": [
+    {
+      "O": "system:nodes"
+    }
+  ]
 }
 EOF
 ```
 
-其中 `172.168.0.24` 是服务的集群 IP，`my-svc.my-namespace.svc.cluster.local` 是服务的 DNS 名称，`10.0.34.2` 是 pod 的 IP 和 `my-pod.my-namespace.pod.cluster.local` 是 pod 的 DNS 名称。您能看到以下的输出：
+<!--
+Where `192.0.2.24` is the service's cluster IP,
+`my-svc.my-namespace.svc.cluster.local` is the service's DNS name,
+`10.0.34.2` is the pod's IP and `my-pod.my-namespace.pod.cluster.local`
+is the pod's DNS name. You should see the following output:
+-->
+其中 `192.0.2.24` 是服务的集群 IP，`my-svc.my-namespace.svc.cluster.local`
+是服务的 DNS 名称，`10.0.34.2` 是 Pod 的 IP，而
+`my-pod.my-namespace.pod.cluster.local` 是 Pod 的 DNS 名称。
+你能看到以下的输出：
 
 ```
 2017/03/21 06:48:17 [INFO] generate received request
@@ -182,77 +150,35 @@ EOF
 2017/03/21 06:48:17 [INFO] encoded CSR
 ```
 
-该命令生成两个文件；它生成包含 PEM 编码 [pkcs#10](https://tools.ietf.org/html/rfc2986) 认证请求的 `server.csr`，以及包含证书的 PEM 编码密钥的 `server-key.pem` 还有待生成。
+<!--
+This command generates two files; it generates `server.csr` containing the PEM
+encoded [pkcs#10](https://tools.ietf.org/html/rfc2986) certification request,
+and `server-key.pem` containing the PEM encoded key to the certificate that
+is still to be created.
+-->
+此命令生成两个文件；它生成包含 PEM 编码
+[pkcs#10](https://tools.ietf.org/html/rfc2986) 证书请求的 `server.csr`，
+以及 PEM 编码密钥的 `server-key.pem`，用于待生成的证书。
 
 <!--
 ## Create a Certificate Signing Request object to send to the Kubernetes API
 
 Generate a CSR yaml blob and send it to the apiserver by running the following
 command:
-
-```shell
-cat <<EOF | kubectl apply -f -
-apiVersion: certificates.k8s.io/v1beta1
-kind: CertificateSigningRequest
-metadata:
-  name: my-svc.my-namespace
-spec:
-  groups:
-  - system:authenticated
-  request: $(cat server.csr | base64 | tr -d '\n')
-  usages:
-  - digital signature
-  - key encipherment
-  - server auth
-EOF
-```
-
-Notice that the `server.csr` file created in step 1 is base64 encoded
-and stashed in the `.spec.request` field. We are also requesting a
-certificate with the "digital signature", "key encipherment", and "server
-auth" key usages. We support all key usages and extended key usages listed
-[here](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)
-so you can request client certificates and other certificates using this
-same API.
-
-The CSR should now be visible from the API in a Pending state. You can see
-it by running:
-
-```shell
-kubectl describe csr my-svc.my-namespace
-```
-
-```none
-Name:                   my-svc.my-namespace
-Labels:                 <none>
-Annotations:            <none>
-CreationTimestamp:      Tue, 21 Mar 2017 07:03:51 -0700
-Requesting User:        yourname@example.com
-Status:                 Pending
-Subject:
-        Common Name:    my-svc.my-namespace.svc.cluster.local
-        Serial Number:
-Subject Alternative Names:
-        DNS Names:      my-svc.my-namespace.svc.cluster.local
-        IP Addresses:   172.168.0.24
-                        10.0.34.2
-Events: <none>
-```
 -->
 ## 创建证书签名请求对象发送到 Kubernetes API
 
-使用以下命令创建 CSR yaml 文件，并发送到 API server：
+使用以下命令创建 CSR YAML 文件，并发送到 API 服务器：
 
 ```shell
 cat <<EOF | kubectl apply -f -
-apiVersion: certificates.k8s.io/v1beta1
+apiVersion: certificates.k8s.io/v1
 kind: CertificateSigningRequest
 metadata:
   name: my-svc.my-namespace
 spec:
-  groups:
-  - system:authenticated
   request: $(cat server.csr | base64 | tr -d '\n')
+  signerName: kubernetes.io/kubelet-serving
   usages:
   - digital signature
   - key encipherment
@@ -260,9 +186,26 @@ spec:
 EOF
 ```
 
-请注意，在步骤1中创建的 `server.csr` 文件是 base64 编码并存储在 `.spec.request` 字段中的，我们还要求提供 “数字签名”，“密钥加密” 和 “服务器身份验证” 密钥用途的证书。我们[这里](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)支持列出的所有关键用途和扩展的关键用途，以便您可以使用相同的 API 请求客户端证书和其他证书。
+<!--
+Notice that the `server.csr` file created in step 1 is base64 encoded
+and stashed in the `.spec.request` field. We are also requesting a
+certificate with the "digital signature", "key encipherment", and "server
+auth" key usages, signed by the `kubernetes.io/kubelet-serving` signer.
+A specific `signerName` must be requested.
+View documentation for [supported signer names](/docs/reference/access-authn-authz/certificate-signing-requests/#signers)
+for more information.
 
-在 API server 中可以看到这些 CSR 处于 pending 状态。执行下面的命令您将可以看到：
+The CSR should now be visible from the API in a Pending state. You can see
+it by running:
+-->
+请注意，在步骤 1 中创建的 `server.csr` 文件是 base64 编码并存储在
+`.spec.request` 字段中的。我们还要求提供 “digital signature（数字签名）”，
+“密钥加密（key encipherment）” 和 “服务器身份验证（server auth）” 密钥用途，
+由 `kubernetes.io/kubelet-serving` 签名程序签名的证书。
+你也可以要求使用特定的 `signerName`。更多信息可参阅
+[支持的签署者名称](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signers)。
+
+在 API server 中可以看到这些 CSR 处于 Pending 状态。执行下面的命令你将可以看到：
 
 ```shell
 kubectl describe csr my-svc.my-namespace
@@ -280,7 +223,7 @@ Subject:
         Serial Number:
 Subject Alternative Names:
         DNS Names:      my-svc.my-namespace.svc.cluster.local
-        IP Addresses:   172.168.0.24
+        IP Addresses:   192.0.2.24
                         10.0.34.2
 Events: <none>
 ```
@@ -292,38 +235,19 @@ Approving the certificate signing request is either done by an automated
 approval process or on a one off basis by a cluster administrator. More
 information on what this involves is covered below.
 -->
-## 获取批准的证书签名请求
+## 批准证书签名请求
 
-批准证书签名请求是通过自动批准过程完成的，或由集群管理员一次性完成。有关这方面涉及的更多信息，请参见下文。
+批准证书签名请求是通过自动批准过程完成的，或由集群管理员一次性完成。
+有关这方面涉及的更多信息，请参见下文。
 
 <!--
 ## Download the Certificate and Use It
 
 Once the CSR is signed and approved you should see the following:
-
-```shell
-kubectl get csr
-```
-
-```none
-NAME                  AGE       REQUESTOR               CONDITION
-my-svc.my-namespace   10m       yourname@example.com    Approved,Issued
-```
-
-You can download the issued certificate and save it to a `server.crt` file
-by running the following:
-
-```shell
-kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
-    | base64 --decode > server.crt
-```
-
-Now you can use `server.crt` and `server-key.pem` as the keypair to start
-your HTTPS server.
 -->
 ## 下载证书并使用它
 
-CSR 被签署并获得批准后，您应该看到以下内容：
+CSR 被签署并获得批准后，你应该看到以下内容：
 
 ```shell
 kubectl get csr
@@ -334,14 +258,22 @@ NAME                  AGE       REQUESTOR               CONDITION
 my-svc.my-namespace   10m       yourname@example.com    Approved,Issued
 ```
 
-您可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中：
+<!--
+You can download the issued certificate and save it to a `server.crt` file
+by running the following:
+-->
+你可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中：
 
 ```shell
 kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
     | base64 --decode > server.crt
 ```
 
-现在您可以将 `server.crt` 和 `server-key.pem` 作为键值对来启动 HTTPS 服务器。
+<!--
+Now you can use `server.crt` and `server-key.pem` as the keypair to start
+your HTTPS server.
+-->
+现在你可以将 `server.crt` 和 `server-key.pem` 作为键值对来启动 HTTPS 服务器。
 
 <!--
 ## Approving Certificate Signing Requests
@@ -351,10 +283,20 @@ A Kubernetes administrator (with appropriate permissions) can manually approve
 approve` and `kubectl certificate deny` commands. However if you intend
 to make heavy usage of this API, you might consider writing an automated
 certificates controller.
+-->
+## 批准证书签名请求
 
+Kubernetes 管理员（具有适当权限）可以使用 `kubectl certificate approve` 和
+`kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求。
+但是，如果你打算大量使用此 API，则可以考虑编写自动化的证书控制器。
+
+<!--
 Whether a machine or a human using kubectl as above, the role of the approver is
 to verify that the CSR satisfies two requirements:
+-->
+无论上述机器或人使用 kubectl，批准者的作用是验证 CSR 满足如下两个要求：
 
+<!--
 1. The subject of the CSR controls the private key used to sign the CSR. This
    addresses the threat of a third party masquerading as an authorized subject.
    In the above example, this step would be to verify that the pod controls the
@@ -363,37 +305,33 @@ to verify that the CSR satisfies two requirements:
    addresses the threat of an undesired subject joining the cluster. In the
    above example, this step would be to verify that the pod is allowed to
    participate in the requested service.
+-->
+1. CSR 的 subject 控制用于签署 CSR 的私钥。这解决了伪装成授权主体的第三方的威胁。
+   在上述示例中，此步骤将验证该 Pod 控制了用于生成 CSR 的私钥。
+2. CSR 的 subject 被授权在请求的上下文中执行。
+   这点用于处理不期望的主体被加入集群的威胁。
+   在上述示例中，此步骤将是验证该 Pod 是否被允许加入到所请求的服务中。
 
+<!--
 If and only if these two requirements are met, the approver should approve
 the CSR and otherwise should deny the CSR.
 -->
-## 批准证书签名请求
-
-Kubernetes 管理员（具有适当权限）可以使用 `kubectl certificate approve` 和 `kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求。但是，如果您打算大量使用此 API，则可以考虑编写自动化的证书控制器。
-
-无论上述机器或人使用 kubectl，批准者的作用是验证 CSR 满足如下两个要求：
-
- 1. CSR 的主体控制用于签署 CSR 的私钥。这解决了伪装成授权主体的第三方的威胁。在上述示例中，此步骤将验证该 pod 控制了用于生成 CSR 的私钥。
- 2. CSR 的主体被授权在请求的上下文中执行。这解决了我们加入群集的我们不期望的主体的威胁。在上述示例中，此步骤将是验证该 pod 是否被允许加入到所请求的服务中。
-
 当且仅当满足这两个要求时，审批者应该批准 CSR，否则拒绝 CSR。
 
 <!--
 ## A Word of Warning on the Approval Permission
 
-
 The ability to approve CSRs decides who trusts who within the cluster. This
 includes who the Kubernetes API trusts. The ability to approve CSRs should
 not be granted broadly or lightly. The requirements of the challenge
 noted in the previous section and the repercussions of issuing a specific
-certificate should be fully understood before granting this permission. See
-[here](/docs/reference/access-authn-authz/authentication/#x509-client-certs) for information on how
-certificates interact with authentication.
+certificate should be fully understood before granting this permission.
 -->
-## 关于批准许可的警告
-
-批准 CSR 的能力决定谁信任群集中的谁。这包括 Kubernetes API 信任的人。批准 CSR 的能力不能过于广泛和轻率。在给予本许可之前，应充分了解上一节中提到的挑战和发布特定证书的后果。有关证书与认证交互的信息，请参阅[此处](/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
+## 关于批准权限的警告
 
+批准 CSR 的能力决定了群集中的信任关系。这也包括 Kubernetes API 所信任的人。
+批准 CSR 的能力不能过于广泛和轻率。
+在给予本许可之前，应充分了解上一节中提到的挑战和发布特定证书的后果。
 
 <!--
 ## A Note to Cluster Administrators
@@ -403,10 +341,11 @@ Kubernetes controller manager provides a default implementation of a signer. To
 enable it, pass the `--cluster-signing-cert-file` and
 `--cluster-signing-key-file` parameters to the controller manager with paths to
 your Certificate Authority's keypair.
-
 -->
 ## 给集群管理员的一个建议
 
-本教程假设将签名者设置为服务证书 API。Kubernetes controller manager 提供了一个签名者的默认实现。 要启用它，请将`--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数传递给 controller manager，并配置具有证书颁发机构的密钥对的路径。
-
+本教程假设已经为 certificates API 配置了签名者。Kubernetes 控制器管理器
+提供了一个签名者的默认实现。要启用它，请为控制器管理器设置
+`--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数，
+使之取值为你的证书机构的密钥对的路径。
 
diff --git a/content/zh/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/zh/docs/tasks/tls/manual-rotation-of-ca-certificates.md
new file mode 100644
index 0000000000..6816bdd6fc
--- /dev/null
+++ b/content/zh/docs/tasks/tls/manual-rotation-of-ca-certificates.md
@@ -0,0 +1,278 @@
+---
+title: 手动轮换 CA 证书
+min-kubernetes-server-version: v1.13
+content_type: task
+---
+<!--
+title: Manual Rotation of CA Certificates
+min-kubernetes-server-version: v1.13
+content_type: task
+-->
+<!-- overview -->
+
+<!--
+This page shows how to manually rotate the certificate authority (CA) certificates.
+-->
+本页展示如何手动轮换证书机构（CA）证书。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!--
+- For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication).
+- For more information about best practices for CA certificates, see [Single root CA](/docs/setup/best-practices/certificates/#single-root-ca).
+-->
+- 要了解 Kubernetes 中用户认证的更多信息，参阅
+  [认证](/zh/docs/reference/access-authn-authz/authentication)；
+- 要了解与 CA 证书最佳实践有关的更多信息，参阅[单根 CA](/zh/docs/setup/best-practices/certificates/#single-root-ca)。
+
+<!-- steps -->
+
+<!--
+## Rotate the CA certificates manually
+-->
+## 手动轮换 CA 证书  {#rotate-the-ca-certificates-manually}
+
+<!--
+Make sure to back up your certificate directory along with configuration files and any other necessary files.
+
+This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers.
+Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.
+
+Configurations with a single API server will experience unavailability while the API server is being restarted.
+-->
+{{< caution >}}
+确保备份你的证书目录、配置文件以及其他必要文件。
+
+这里的方法假定 Kubernetes 的控制面通过运行多个 API 服务器以高可用配置模式运行。
+另一假定是 API 服务器可体面地终止，因而客户端可以彻底地与一个 API 服务器断开
+连接并连接到另一个 API 服务器。
+
+如果集群中只有一个 API 服务器，则在 API 服务器重启期间会经历服务中断期。
+{{< /caution >}}
+
+<!--
+1. Distribute the new CA certificates and private keys
+   (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`)
+   to all your control plane nodes in the Kubernetes certificates directory.
+-->
+1. 将新的 CA 证书和私钥（例如：`ca.crt`、`ca.key`、`front-proxy-ca.crt` 和
+   `front-proxy-client.key`）分发到所有控制面节点，放在其 Kubernetes 证书目录下。
+
+<!--
+1. Update *Kubernetes controller manager's* `-root-ca-file` to include both old and new CA and restart controller manager.
+
+   Any service account created after this point will get secrets that include both old and new CAs.
+
+   Remove the flag `-client-ca-file` from the *Kubernetes controller manager* configuration.
+   You can also replace the existing client CA file or change this configuration item to reference a new, updated CA.
+   [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle.
+-->
+2. 更新控制器管理器的 `--root-ca-file` 标志，使之同时包含老的和新的 CA，之后重启控制器管理器。
+
+   自此刻起，所创建的所有服务账号都会获得同时包含老的 CA 和新的 CA 的 Secret。
+
+   {{< note >}}
+   去掉控制器管理器的 `-client-ca-file` 标志。
+   你也可以替换客户端 CA 文件或者将此配置条目指向新的、更新过的 CA。
+   [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) 用来跟踪
+   控制器管理器无法接受 CA 包的问题。
+   {{< /note >}}
+
+<!--
+1. Update all service account tokens to include both old and new CA certificates.
+
+   If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.
+-->
+3. 更新所有服务账号令牌，使之同时包含老的和新的 CA 证书。
+
+   如果在 API 服务器使用新的 CA 之前启动了新的 Pod，这些 Pod
+   也会获得此更新并且同时信任老的和新的 CA 证书。
+
+   ```shell
+   base64_encoded_ca="$(base64 <path to file containing both old and new CAs>)"
+
+   for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
+       for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
+           kubectl get $token --namespace "$namespace" -o yaml | \
+             /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \
+             kubectl apply -f -
+       done
+   done
+   ```
+<!--
+1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets.
+
+   * Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.
+
+1. Append the both old and new CA to the file against `-client-ca-file` and `-kubelet-certificate-authority` flag in the `kube-apiserver` configuration.
+
+1. Append the both old and new CA to the file against `-client-ca-file` flag in the `kube-scheduler` configuration.
+-->
+4. 重启所有使用集群内配置的 Pods（例如：`kube-proxy`、`coredns` 等），以便这些 Pod 能够使用
+   来自服务账号 Secret 中的、已更新的证书机构数据。
+
+   * 确保 `coredns`、`kube-proxy` 和其他使用集群内配置的 Pod 都正按预期方式工作。
+
+5. 将老的和新的 CA 都追加到 `kube-apiserver` 配置的 `--client-ca-file` 和 `--kubelet-certificate-authority` 标志所指的文件。
+
+6. 将老的和新的 CA 都追加到 `kube-scheduler` 配置的 `--client-ca-file` 标志所指的文件。
+
+<!--
+1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively.
+
+   For information about creating certificates for individual user accounts, see
+   [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).
+
+   Additionally, update the `certificate-authority-data` section in the kubeconfig files,
+   respectively with Base64-encoded old and new certificate authority data
+-->
+7. 通过替换 `client-certificate-data` 和 `client-key-data`
+   中的内容，更新用户账号的证书。
+
+   有关为独立用户账号创建证书的更多信息，可参阅
+   [为用户帐号配置证书](/zh/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts)。
+
+   另外，还要更新 kubeconfig 文件中的 `certificate-authority-data`
+   节，使之包含 Base64 编码的老的和新的证书机构数据。
+<!--
+1. Follow below steps in a rolling fashion.
+
+   1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)*
+      or *webhook handlers* to trust the new CA certificates.
+
+   1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and
+      `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.
+
+      If your kubelet is not using client certificate rotation update `client-certificate-data` and
+      `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file
+      usually found in `/var/lib/kubelet/pki`.
+-->
+8. 遵循下列步骤执行滚动更新
+
+   1. 重新启动所有其他[被聚合的 API 服务器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+      或者 *Webhook 处理程序*，使之信任新的 CA 证书。
+
+   2. 在所有节点上更新 kubelet 配置中的 `clientCAFile` 所指文件以及 kubelet.conf 中的
+      `certificate-authority-data` 并重启 kubelet 以同时使用老的和新的 CA 证书。
+
+      如果你的 kubelet 并未使用客户端证书轮换，则在所有节点上更新 kubelet.conf 中
+      `client-certificate-data` 和 `client-key-data` 以及 kubelet
+      客户端证书文件（通常位于 `/var/lib/kubelet/pki` 目录下）
+
+   <!--
+   1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and
+      `front-proxy-client.crt`) signed by new CA.
+      You can use the existing private keys or new private keys.
+      If you changed the private keys then update these in the Kubernetes certificates directory as well.
+   -->
+   3. 使用用新的 CA 签名的证书
+     （`apiserver.crt`、`apiserver-kubelet-client.crt` 和 `front-proxy-client.crt`）
+      来重启 API 服务器。
+      你可以使用现有的私钥，也可以使用新的私钥。
+      如果你改变了私钥，则要将更新的私钥也放到 Kubernetes 证书目录下。
+
+      由于 Pod 既信任老的 CA 也信任新的 CA，Pod 中的客户端会经历短暂的连接断开状态，
+      之后再连接到使用新的 CA 所签名的证书的新的 API 服务器。
+
+      <!--
+      * Restart Scheduler to use the new CAs.
+      * Make sure control plane components logs no TLS errors.
+      -->
+      * 重启调度器以使用新的 CA 证书。
+      * 确保控制面组件的日志中没有 TLS 相关的错误信息。
+
+      <!--
+      To generate certificates and private keys for your cluster using the `openssl`
+      command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl).
+      You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl).
+      -->
+      {{< note >}}
+      要使用 `openssl` 命令行为集群生成新的证书和私钥，可参阅
+      [证书（`openssl`）](/zh/docs/concepts/cluster-administration/certificates/#openssl)。
+      你也可以使用[`cfssl`](/zh/docs/concepts/cluster-administration/certificates/#cfssl).
+      {{< /note >}}
+
+   <!--
+   1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
+
+      Example:
+   -->
+   4. 为 Daemonset 和 Deployment 添加注解，从而触发较安全的滚动更新，替换 Pod。
+
+      示例：
+
+      ```shell
+      for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
+          for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
+              kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
+          done
+          for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
+              kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
+          done
+      done
+      ```
+
+      <!--
+      To limit the number of concurrent disruptions that your application experiences,
+      see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/).
+      -->
+      {{< note >}}
+      要限制应用可能受到的并发干扰数量，可以参阅
+      [配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/).
+      {{< /note >}}
+<!--
+1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA.
+-->
+9. 如果你的集群使用启动引导令牌来添加节点，则需要更新 `kube-public` 名字空间下的
+   ConfigMap `cluster-info`，使之包含新的 CA 证书。
+
+   ```shell
+   base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)"
+
+   kubectl get cm/cluster-info --namespace kube-public -o yaml | \
+       /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \
+       kubectl apply -f -
+   ```
+<!--
+1. Verify the cluster functionality.
+
+   1. Validate the logs from control plane components, along with the kubelet and the
+      kube-proxy are not throwing any tls errors, see
+      [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
+
+   1. Validate logs from any aggregated api servers and pods using in-cluster config.
+-->
+10. 验证集群的功能正常
+
+    1. 验证控制面组件的日志，以及 `kubelet` 和 `kube-proxy` 的日志，确保其中没有
+       抛出 TLS 错误，参阅
+       [查看日志](/zh/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
+
+    2. 验证被聚合的 API 服务器的日志，以及所有使用集群内配置的 Pod 的日志。
+
+<!--
+1. Once the cluster functionality is successfully verified:
+
+   1. Update all service account tokens to include new CA certificate only.
+
+      * All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.
+
+   1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
+
+   1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.
+-->
+11. 完成集群功能的检查之后：
+
+    1. 更新所有的服务账号令牌，使之仅包含新的 CA 证书。
+
+       * 使用集群内 kubeconfig 的 Pod 最终也需要被重启，以获得新的服务账号 Secret
+         数据，进而不再信任老的 CA 证书。
+
+    1. 从 kubeconfig 文件和 `--client-ca-file` 以及 `--root-ca-file` 标志所指向的文件
+       中去除老的 CA 数据，之后重启控制面组件。
+
+    1. 重启 kubelet，移除 `clientCAFile` 标志所指向的文件以及 kubelet kubeconfig 文件中
+       的老的 CA 数据。
+
diff --git a/content/zh/docs/tasks/tools/_index.md b/content/zh/docs/tasks/tools/_index.md
index cf1443b625..c124583287 100644
--- a/content/zh/docs/tasks/tools/_index.md
+++ b/content/zh/docs/tasks/tools/_index.md
@@ -1,4 +1,131 @@
 ---
 title: "安装工具"
 weight: 10
+description: 在你的计算机上设置 Kubernetes 工具。
+no_list: true
 ---
+
+<!--
+title: "Install Tools"
+description: Set up Kubernetes tools on your computer.
+weight: 10
+no_list: true
+-->
+
+<!--
+## kubectl
+
+The Kubernetes command-line tool, `kubectl`, allows you to run commands against
+Kubernetes clusters. You can use `kubectl` to deploy applications, inspect and
+manage cluster resources, and view logs.
+
+See [Install and Set Up `kubectl`](/docs/tasks/tools/install-kubectl/) for
+information about how to download and install `kubectl` and set it up for
+accessing your cluster.
+-->
+## kubectl
+
+Kubernetes 命令行工具，`kubectl`，使得你可以对 Kubernetes 集群运行命令。
+你可以使用 `kubectl` 来部署应用、监测和管理集群资源以及查看日志。
+
+关于如何下载和安装 `kubectl` 并配置其访问你的集群，可参阅
+[安装和配置 `kubectl`](/zh/docs/tasks/tools/install-kubectl/)。
+
+<!--
+a class="btn btn-primary" href="/docs/tasks/tools/install-kubectl/" role="button" aria-label="View kubectl Install and Set Up Guide">View kubectl Install and Set Up Guide</a>
+
+You can also read the
+[`kubectl` reference documentation](/docs/reference/kubectl/).
+-->
+<a class="btn btn-primary" href="/zh/docs/tasks/tools/install-kubectl/"
+  role="button" aria-label="查看 kubectl 安装和配置指南">
+查看 kubectl 安装和配置指南
+</a>
+
+你也可以阅读 [`kubectl` 参考文档](/zh/docs/reference/kubectl/).
+
+<!--
+## kind
+
+[`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
+your local computer. This tool requires that you have
+[Docker](https://docs.docker.com/get-docker/) installed and configured.
+
+The kind [Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) page
+shows you what you need to do to get up and running with `kind`.
+
+<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/" role="button" aria-label="View kind Quick Start Guide">View kind Quick Start Guide</a>
+-->
+## kind
+
+[`kind`](https://kind.sigs.k8s.io/docs/) 让你能够在本地计算机上运行 Kubernetes。
+`kind` 要求你安装并配置好 [Docker](https://docs.docker.com/get-docker/)。
+
+kind [快速入门](https://kind.sigs.k8s.io/docs/user/quick-start/)页面展示了
+开始使用 `kind` 所需要完成的操作。
+
+<a class="btn btn-primary" href="https://kind.sigs.k8s.io/docs/user/quick-start/"
+  role="button" aria-label="查看 kind 的快速入门指南">
+查看 kind 的快速入门指南
+</a>
+
+<!--
+## minikube
+
+Like `kind`, [`minikube`](https://minikube.sigs.k8s.io/) is a tool that lets you run Kubernetes
+locally. `minikube` runs a single-node Kubernetes cluster on your personal
+computer (including Windows, macOS and Linux PCs) so that you can try out
+Kubernetes, or for daily development work.
+
+You can follow the official
+[Get Started!](https://minikube.sigs.k8s.io/docs/start/) guide if your focus is
+on getting the tool installed.
+-->
+## minikube
+
+与 `kind` 类似，[`minikube`](https://minikube.sigs.k8s.io/) 是一个工具，
+能让你在本地运行 Kubernetes。
+`minikube` 在你本地的个人计算机（包括 Windows、macOS 和 Linux PC）运行一个单节点的
+Kubernetes 集群，以便你来尝试 Kubernetes 或者开展每天的开发工作。
+
+如果你关注如何安装此工具，可以按官方的
+[Get Started!](https://minikube.sigs.k8s.io/docs/start/)指南操作。
+
+<!--
+a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/" role="button" aria-label="View minikube Get Started! Guide">View minikube Get Started! Guide</a>
+
+Once you have `minikube` working, you can use it to
+[run a sample application](/docs/tutorials/hello-minikube/).
+-->
+<a class="btn btn-primary" href="https://minikube.sigs.k8s.io/docs/start/"
+  role="button" aria-label="查看 minikube 快速入门指南">
+查看 minikube 快速入门指南
+</a>
+
+当你拥有了可工作的 `minikube` 时，就可以用它来
+[运行示例应用](/zh/docs/tutorials/hello-minikube/)了。
+
+## kubeadm
+
+<!--
+You can use the {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} tool to create and manage Kubernetes clusters.
+It performs the actions necessary to get a minimum viable, secure cluster up and running in a user friendly way.
+-->
+你可以使用 {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} 工具来
+创建和管理 Kubernetes 集群。
+该工具能够执行必要的动作并用一种用户友好的方式启动一个可用的、安全的集群。
+
+<!--
+[Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) shows you how to install kubeadm.
+Once installed, you can use it to [create a cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/).
+-->
+[安装 kubeadm](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
+展示了如何安装 kubeadm 的过程。
+一旦安装了 kubeadm，你就可以使用它来
+[创建一个集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)。
+
+<!-- a class="btn btn-primary" href="/docs/setup/production-environment/tools/kubeadm/install-kubeadm/" role="button" aria-label="View kubeadm Install Guide">View kubeadm Install Guide</a-->
+
+<a class="btn btn-primary" href="/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/"
+  role="button" aria-label="查看 kubeadm 安装指南">查看 kubeadm 安装指南</a>
+
diff --git a/content/zh/docs/tasks/tools/install-kubectl.md b/content/zh/docs/tasks/tools/install-kubectl.md
index 577e48d40f..589b89b336 100644
--- a/content/zh/docs/tasks/tools/install-kubectl.md
+++ b/content/zh/docs/tasks/tools/install-kubectl.md
@@ -21,66 +21,105 @@ card:
 
 <!-- overview -->
 <!--
- Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; look at your new cluster; and bring up example apps.
+The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
+you to run commands against Kubernetes clusters.
+You can use kubectl to deploy applications, inspect and manage cluster resources,
+and view logs. For a complete list of kubectl operations, see
+[Overview of kubectl](/docs/reference/kubectl/overview/).
  -->
- 在 Kubernetes 上使用 Kubernetes 命令行工具 [kubectl](/docs/user-guide/kubectl/) 部署和管理应用程序。使用 kubectl，您可以检查集群资源；创建、删除和更新组件；查看您的新集群；并启动实例应用程序。
-
+使用 Kubernetes 命令行工具 [kubectl](/zh/docs/reference/kubectl/kubectl/)，
+你可以在 Kubernetes 上运行命令。
+使用 kubectl，你可以部署应用、检查和管理集群资源、查看日志。
+要了解 kubectl 操作的完整列表，请参阅
+[kubectl 概览](/zh/docs/reference/kubectl/overview/)。
 
 ## {{% heading "prerequisites" %}}
 
 <!--
-You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
+You must use a kubectl version that is within one minor version difference of your cluster.
+For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
+Using the latest version of kubectl helps avoid unforeseen issues.
 -->
-您必须使用与集群小版本号差别为一的 kubectl 版本。例如，1.2版本的客户端应该与1.1版本、1.2版本和1.3版本的主节点一起使用。使用最新版本的 kubectl 有助于避免无法预料的问题。
-
-
+你必须使用与集群小版本号差别为一的 kubectl 版本。
+例如，1.2 版本的客户端应该与 1.1 版本、1.2 版本和 1.3 版本的主节点一起使用。
+使用最新版本的 kubectl 有助于避免无法预料的问题。
 
 <!-- steps -->
 
 <!--
-## Install kubectl
+## Install kubectl on Linux
 
-Here are a few methods to install kubectl.
+### Install kubectl binary with curl on Linux
 -->
-## 安装 kubectl
+## 在 Linux 上安装 kubectl  {#install-kubectl-on-linux}
 
-以下是一些安装 kubectl 的方法。
+### 在 Linux 上使用 curl 安装 kubectl 可执行文件
 
 <!--
-## Install kubectl binary using native package management
-
-{{< tabs name="kubectl_install" >}}
-{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https
-curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
-echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
-sudo apt-get update
-sudo apt-get install -y kubectl
-{{< /tab >}}
-{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
-[kubernetes]
-name=Kubernetes
-baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
-enabled=1
-gpgcheck=1
-repo_gpgcheck=1
-gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
-EOF
-yum install -y kubectl
-{{< /tab >}}
-{{< /tabs >}}
+1. Download the latest release with the command:
 -->
-## 使用本地软件包管理软件安装 kubectl 二进制文件
+1. 使用下面命令下载最新的发行版本：
+
+   ```
+   curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
+   ```
+
+   <!--
+   To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
+
+   For example, to download version {{< param "fullversion" >}} on Linux, type:
+   -->
+   要下载特定版本， `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`
+   部分替换为指定版本。
+
+   例如，要下载 Linux 上的版本 {{< param "fullversion" >}}，输入：
+    
+   ```
+   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
+   ```
+
+<!--
+2. Make the kubectl binary executable.
+-->
+2. 标记 kubectl 文件为可执行：
+
+   ```
+   chmod +x ./kubectl
+   ```
+
+<!--
+3. Move the binary in to your PATH.
+-->
+3. 将文件放到 PATH 路径下：
+
+   ```
+   sudo mv ./kubectl /usr/local/bin/kubectl
+   ```
+
+<!--
+4. Test to ensure the version you installed is up-to-date:
+-->
+4. 测试你所安装的版本是最新的：
+
+   ```
+   kubectl version --client
+   ```
+
+<!--
+### Install using native package management
+-->
+### 使用原生包管理器安装    {#install-using-native-package-management}
 
 {{< tabs name="kubectl_install" >}}
-{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https
+{{< tab name="Ubuntu、Debian 或 HypriotOS" codelang="bash" >}}
+sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
 echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
 sudo apt-get update
 sudo apt-get install -y kubectl
 {{< /tab >}}
-{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
+{{< tab name="CentOS、RHEL 或 Fedora" codelang="bash" >}}
+cat <<EOF > /etc/yum.repos.d/kubernetes.repo
 [kubernetes]
 name=Kubernetes
 baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
@@ -93,616 +132,774 @@ yum install -y kubectl
 {{< /tab >}}
 {{< /tabs >}}
 
-
 <!--
-## Install with snap on Ubuntu
-
-If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
-
-1. Switch to the snap user and run the installation command:
-
-    ```
-    sudo snap install kubectl --classic
-    ```
-
-2. Test to ensure the version you installed is sufficiently up-to-date:
-
-    ```
-    kubectl version --client
-    ```
+### Install using other package management
 -->
-## 在 Ubuntu 上使用 snap 安装 kubectl
+### 使用其他包管理器安装 {#install-using-other-package-management}
 
-如果您使用的是 Ubuntu 或其他支持 [snap](https://snapcraft.io/docs/core/install) 软件包管理器的Linux发行版，kubectl 可以作为一个 [snap](https://snapcraft.io/) 应用程序使用。
+{{< tabs name="other_kubectl_install" >}}
+{{% tab name="Snap" %}}
+<!--
+If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
+-->
+如果你使用 Ubuntu 或者其他支持 [snap](https://snapcraft.io/docs/core/install)
+包管理器的 Linux 发行版，kubeclt 可以作为 [Snap](https://snapcraft.io)
+应用来安装：
 
-1. 切换到 snap 用户并运行安装命令：
+```shell
+snap install kubectl --classic
 
-    ```
-    sudo snap install kubectl --classic
-    ```
+kubectl version --client
+```
 
-2. 测试以确保您安装的版本是最新的：
+{{% /tab %}}
 
-    ```
-    kubectl version --client
-    ```
+{{% tab name="Homebrew" %}}
+<!--
+If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
+-->
+如果你在使用 Linux 且使用 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 包管理器，
+kubectl 也可以用这种方式[安装](https://docs.brew.sh/Homebrew-on-Linux#install)。
+
+```shell
+brew install kubectl
+
+kubectl version --client
+```
+
+{{% /tab %}}
+
+{{< /tabs >}}
 
 <!--
-## Install with Homebrew on macOS
+## Install kubectl on macOS
+
+### Install kubectl binary with curl on macOS
+-->
+## 在 macOS 上安装 kubectl
+
+### 在 macOS 上使用 curl 安装 kubectl 可执行文件
+
+<!--
+1. Download the latest release:
+-->
+1. 下载最新发行版本：
+
+   ```bash
+   curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
+   ```
+
+   <!--
+   To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
+
+   For example, to download version {{< param "fullversion" >}} on macOS, type:
+   -->
+   要下载特定版本，可将上面命令中的`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`
+   部分替换成你想要的版本。
+
+   例如，要在 macOS 上安装版本 {{< param "fullversion" >}}，输入：
+
+   ```bash
+   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
+   ```
+
+   <!-- Make the kubectl binary executable. -->
+   将二进制文件标记为可执行：
+
+   ```bash
+   chmod +x ./kubectl
+   ```
+<!--
+3. Move the binary in to your PATH.
+-->
+3. 将二进制文件放入 PATH 目录下：
+
+   ```bash
+   sudo mv ./kubectl /usr/local/bin/kubectl
+   ```
+
+<!--
+4. Test to ensure the version you installed is up-to-date:
+-->
+4. 测试以确保所安装的版本是最新的：
+
+   ```bash
+   kubectl version --client
+   ```
+
+<!--
+### Install with Homebrew on macOS
 
 If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
-
-1. Run the installation command:
-
-    ```
-    brew install kubernetes-cli
-    ```
-
-2. Test to ensure the version you installed is sufficiently up-to-date:
-
-    ```
-    kubectl version --client
-    ```
 -->
-## <span id = "jump"> 在 macOS 上用 Homebrew 安装 kubectl </span>
+### 在 macOS 上使用 Homebrew 安装    {#install-with-homebrew-on-macos}
 
-如果您使用的是 macOS 系统并使用 [Homebrew](https://brew.sh/) 包管理器，您可以通过 Homebrew 安装 kubectl。
+如果你在 macOS 上且使用 [Homebrew](https://brew.sh/) 包管理器，
+你可以使用 Homebrew 来安装 kubectl。
 
+<!--
+1. Run the installation command:
+-->
 1. 运行安装命令：
-   
-    ```
-    brew install kubernetes-cli
-    ```
 
-2. 测试以确保您安装的版本是最新的：
-   
+   ```
+   brew install kubernetes-cli
+   ```
+
+<!--
+2. Test to ensure the version you installed is sufficiently up-to-date:
+-->
+2. 测试以确保你安装的版本是最新的：
+
     ```
     kubectl version --client
     ```
-    
 
 <!--
 ## Install with Macports on macOS
 
 If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
-
-1. Run the installation command:
-
-    ```
-    port install kubectl
-    ```
-
-2. Test to ensure the version you installed is sufficiently up-to-date:
-
-    ```
-    kubectl version --client
-    ```
 -->
-
 ## 在 macOS 上用 Macports 安装 kubectl
 
-如果您使用的是 macOS 系统并使用 [Macports](https://macports.org/) 包管理器，您可以通过 Macports 安装 kubectl。
+如果你使用的是 macOS 系统并使用 [Macports](https://macports.org/) 包管理器，你可以通过 Macports 安装 kubectl。
 
+<!--
+1. Run the installation command:
+-->
 1. 运行安装命令：
-   
-    ```
-    port install kubectl
-    ```
 
-2. 测试以确保您安装的版本是最新的：
+   ```
+   port install kubectl
+   ```
 
-     ```
-    kubectl version --client
-    ```
+<!--
+2. Test to ensure the version you installed is sufficiently up-to-date:
+-->
+2. 测试以确保你安装的版本是最新的：
+
+   ```
+   kubectl version --client
+   ```
+
+<!--
+## Install kubectl on Windows
+
+### Install kubectl binary with curl on Windows
+-->
+## 在 Windows 上安装 kubectl   {#install-kubectl-on-windows}
+
+### 在 Windows 上使用 curl 安装 kubectl 二进制文件
+
+<!--
+1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
+
+   Or if you have `curl` installed, use this command:
+-->
+1. 从[此链接](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)
+   下载最新发型版本。
+
+   或者如何你安装了 `curl`，使用下面的命令：
+
+   ```bash
+   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
+   ```
+
+   <!--
+   To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
+   -->
+   要了解最新的稳定版本（例如，出于脚本编写目的），可查看
+   [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)。
+
+<!--
+2. Add the binary in to your PATH.
+-->
+2. 将可执行文件放到 PATH 目录下。
+
+<!--
+3. Test to ensure the version of `kubectl` is the same as downloaded:
+-->
+3. 测试以确定所下载的 `kubectl` 版本是正确的的：
+
+   ```bash
+   kubectl version --client
+   ```
+
+<!--
+[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH.
+If you have installed Docker Desktop before, you may need to place your PATH entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
+-->
+{{< note >}}
+[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)
+会在 PATH 中添加自己的 `kubectl` 程序。
+如果你之前安装过 Docker Desktop，你可能需要将新安装的 PATH 项放到 Docker Desktop
+安装程序所添加的目录之前，或者干脆删除 Docker Desktop 所安装的 `kubectl`。
+{{< /note >}}
 
 <!--
 ## Install with Powershell from PSGallery
 
 If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell.
-
-1. Run the installation commands (making sure to specify a `DownloadLocation`):
-
-    ```
-    Install-Script -Name install-kubectl -Scope CurrentUser -Force
-    install-kubectl.ps1 [-DownloadLocation <path>]
-    ```
-
-    {{< note >}}
-    If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
-    {{< /note >}}
-
-    The installer creates `$HOME/.kube` and instructs it to create a config file
-
-2. Test to ensure the version you installed is sufficiently up-to-date:
-
-    ```
-    kubectl version --client
-    ```
-
-    {{< note >}}
-    Updating the installation is performed by rerunning the two commands listed in step 1.
-    {{< /note >}}
 -->
-## 从 PSGallery 通过 Powershell 安装 kubectl
+## 使用 PowerShell 从 PSGallery 安装 kubectl
 
-如果您使用的是 Windows 系统并使用 [Powershell Gallery](https://www.powershellgallery.com/) 软件包管理器，您可以使用 Powershell 安装和更新 kubectl。
-
-1. 运行安装命令（确保指定 `DownloadLocation`）：
-
-    ```
-    Install-Script -Name install-kubectl -Scope CurrentUser -Force
-    install-kubectl.ps1 [-DownloadLocation <path>]
-    ```
-
-    {{< note >}}
-    如果你没有指定 `DownloadLocation`，那么 `kubectl` 将安装在用户的临时目录中。
-    {{< /note >}}
-
-    安装程序创建 `$ HOME/.kube` 并指示它创建配置文件
-
-2. 测试以确保您安装的版本是最新的：
-    ```
-    kubectl version --client
-    ```
-
-    {{< note >}}
-    通过重新运行步骤1中列出的两个命令来执行更新安装。
-    {{< /note >}}
+如果你使用的是 Windows 系统并使用 [Powershell Gallery](https://www.powershellgallery.com/)
+软件包管理器，你可以使用 Powershell 安装和更新 kubectl。
 
 <!--
-## Install with Chocolatey on Windows
-
-If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install kubectl with Chocolatey.
-
-1. Run the installation command:
-
-    ```
-    choco install kubernetes-cli
-    ```
-
-2. Test to ensure the version you installed is sufficiently up-to-date:
-
-    ```
-    kubectl version --client
-    ```
-3. Change to your %HOME% directory:
-
-    For example: `cd C:\users\yourusername`
-
-4. Create the .kube directory:
-
-    ```
-    mkdir .kube
-    ```
-
-5. Change to the .kube directory you just created:
-
-    ```
-    cd .kube
-    ```
-
-6. Configure kubectl to use a remote Kubernetes cluster:
-
-    ```
-    New-Item config -type file
-    ```
-
-    {{< note >}}
-    Edit the config file with a text editor of your choice, such as Notepad.
-    {{< /note >}}
+1. Run the installation commands (making sure to specify a `DownloadLocation`):
 -->
-## 在 Windows 上用 Chocolatey 安装 kubectl
+1. 运行安装命令（确保指定 `DownloadLocation`）：
 
-如果您使用的是 Windows 系统并使用 [Chocolatey](https://chocolatey.org) 包管理器，您可以使用 Chocolatey 安装 kubectl。
+   ```
+   Install-Script -Name install-kubectl -Scope CurrentUser -Force
+   install-kubectl.ps1 [-DownloadLocation <path>]
+   ```
 
-1. 运行安装命令：
+   <!--
+   If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
+   -->
+   {{< note >}}
+   如果你没有指定 `DownloadLocation`，那么 `kubectl` 将安装在用户的临时目录中。
+   {{< /note >}}
 
-    ```
-    choco install kubernetes-cli
-    ```
+   <!--
+   The installer creates `$HOME/.kube` and instructs it to create a config file
+   -->
+   安装程序创建 `$ HOME/.kube` 目录，并指示它创建配置文件
 
-2. 测试以确保您安装的版本是最新的：
+<!--
+2. Test to ensure the version you installed is sufficiently up-to-date:
+-->
+2. 测试以确保你安装的版本是最新的：
 
-    ```
-    kubectl version --client
-    ```
-3. 切换到 %HOME% 目录：
+   ```
+   kubectl version --client
+   ```
 
-    例如：`cd C:\users\yourusername`
+<!--
+Updating the installation is performed by rerunning the two commands listed in step 1.
+-->
+{{< note >}}
+通过重新运行步骤 1 中列出的两个命令可以更新安装。
+{{< /note >}}
 
-4. 创建 .kube 目录：
+<!--
+### Install with Chocolatey on Windows
 
-    ```
-    mkdir .kube
-    ```
+1. To install kubectl on Windows you can use either [Chocolatey] package manager or [Scoop](https://scoop.sh) command-line installer.
+-->
+1. 要在 Windows 上用 [Chocolatey](https://chocolatey.org) 或者
+   [Scoop](https://scoop.sh) 命令行安装程序安装 kubectl：
 
-5. 切换到刚刚创建的 .kube 目录：
+   {{< tabs name="kubectl_win_install" >}}
+   {{% tab name="choco" %}}
+   ```powershell
+   choco install kubernetes-cli
+   ```
+   {{% /tab %}}
+   {{% tab name="scoop" %}}
+   ```powershell
+   scoop install kubectl
+   ```
+   {{% /tab %}}
+   {{< /tabs >}}
 
-    ```
-    cd .kube
-    ```
+<!--
+2. Test to ensure the version you installed is up-to-date:
+-->
+2. 测试以确保你安装的版本是最新的：
 
+   ```
+   kubectl version --client
+   ```
+
+<!--
+3. Navigate to your home directory:
+-->
+3. 切换到你的 HOME 目录：
+
+   ```powershell
+   # 如果你在使用 cmd.exe，运行 cd %USERPROFILE%
+   cd ~
+   ```
+
+<!--
+4. Create the `.kube` directory:
+-->
+4. 创建 `.kube` 目录：
+
+   ```powerhsell
+   mkdir .kube
+   ```
+
+<!--
+5. Change to the .kube directory you just created:
+-->
+5. 进入到刚刚创建的 `.kube` 目录：
+
+   ```powershell
+   cd .kube
+   ```
+
+<!--
+6. Configure kubectl to use a remote Kubernetes cluster:
+-->
 6. 配置 kubectl 以使用远程 Kubernetes 集群：
 
-    ```
-    New-Item config -type file
-    ```
+   ```powershell
+   New-Item config -type file
+   ```
+
+<!--
+Edit the config file with a text editor of your choice, such as Notepad.
+-->
+{{< note >}}
+使用你喜欢的文本编辑器，例如 Notepad，编辑此配置文件。
+{{< /note >}}
 
-    {{< note >}}
-    使用您偏爱的编辑器编辑配置文件，例如 Notepad。
-    {{< /note >}}
 
 <!--
 ## Download as part of the Google Cloud SDK
 
 You can install kubectl as part of the Google Cloud SDK.
-
-1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
-2. Run the `kubectl` installation command:
-
-    ```
-    gcloud components install kubectl
-    ```
-
-3. Test to ensure the version you installed is sufficiently up-to-date:
-
-    ```
-    kubectl version --client
-    ```
 -->
 ## 将 kubectl 作为 Google Cloud SDK 的一部分下载
 
 kubectl 可以作为 Google Cloud SDK 的一部分进行安装。
 
-1. 安装 [Google Cloud SDK](https://cloud.google.com/sdk/).
+<!--
+1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
+2. Run the `kubectl` installation command:
+-->
+1. 安装 [Google Cloud SDK](https://cloud.google.com/sdk/)。
 2. 运行以下命令安装 `kubectl`：
 
-    ```
-    gcloud components install kubectl
-    ```
-
-3. 测试以确保您安装的版本是最新的：
-
-    ```
-    kubectl version --client
-    ```
+   ```
+   gcloud components install kubectl
+   ```
 
 <!--
-## Install kubectl binary using curl
-
-{{< tabs name="kubectl_install_curl" >}}
-{{% tab name="macOS" %}}
-1. Download the latest release:
-
-    ```		 
-    	curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
-    ```
-
-    To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
-
-    For example, to download version {{< param "fullversion" >}} on macOS, type:
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
-    ```
-
-2. Make the kubectl binary executable.
-
-    ```
-    chmod +x ./kubectl
-    ```
-
-3. Move the binary in to your PATH.
-
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
-{{% /tab %}}
-{{% tab name="Linux" %}}
-
-1. Download the latest release with the command:
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
-    ```
-
-    To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
-
-    For example, to download version {{< param "fullversion" >}} on Linux, type:
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
-    ```
-
-2. Make the kubectl binary executable.
-
-    ```
-    chmod +x ./kubectl
-    ```
-
-3. Move the binary in to your PATH.
-
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
-{{% /tab %}}
-{{% tab name="Windows" %}}
-1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
-
-    Or if you have `curl` installed, use this command:
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
-    ```
-
-    To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
-
-2. Add the binary in to your PATH.
-{{% /tab %}}
-{{< /tabs >}}
+3. Test to ensure the version you installed is sufficiently up-to-date:
 -->
-## 通过 curl 命令安装 kubectl 可执行文件
-
-{{< tabs name="kubectl_install_curl" >}}
-{{% tab name="macOS" %}}
-1. 通过以下命令下载 kubectl 的最新版本：
-
-    ```		 
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
-    ```
-
-    若需要下载特定版本的 kubectl，请将上述命令中的 `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 部分替换成为需要下载的 kubectl 的具体版本即可。
-
-     例如，如果需要下载 {{< param "fullversion" >}} 版本在 macOS 系统上,需要使用如下命令：
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
-    ```
-
-2. 修改所下载的 kubectl 二进制文件为可执行模式。
-
-    ```
-    chmod +x ./kubectl
-    ```
-
-3. 将 kubectl 可执行文件放置到你的 PATH 目录下。
-
-
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
-{{% /tab %}}
-{{% tab name="Linux" %}}
-
-1. 通过以下命令下载 kubectl 的最新版本：
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
-    ```
-
-    若需要下载特定版本的 kubectl，请将上述命令中的 `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 部分替换成为需要下载的 kubectl 的具体版本即可。
-
-    例如，如果需要下载用于 Linux 的 {{< param "fullversion" >}} 版本，需要使用如下命令：
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
-    ```
-
-2. 修改所下载的 kubectl 二进制文件为可执行模式。
-
-    ```
-    chmod +x ./kubectl
-    ```
-
-3. 将 kubectl 可执行文件放置到你的 PATH 目录下。
-
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
-{{% /tab %}}
-{{% tab name="Windows" %}}
-1. 从[本链接](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)下载 kubectl 的最新版 {{< param "fullversion" >}}。
-
-    或者如果您已经在系统中安装了 `curl` 工具，也可以通过以下命令下载：
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
-    ```
-
-若要查找最新的稳定版本（例如脚本等），请查看 [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
-
-2. 将 kubectl 可执行文件添加到你的 PATH 目录。
-{{% /tab %}}
-{{< /tabs >}}
-
+3. 测试以确保你安装的版本是最新的：
 
+   ```
+   kubectl version --client
+   ```
 
 <!--
-## Configure kubectl
+## Verifying kubectl configuration
 
-In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using kube-up.sh or successfully deploy a Minikube cluster. See the [getting started guides](/docs/setup/) for more about creating clusters. If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+In order for kubectl to find and access a Kubernetes cluster, it needs a
+[kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/),
+which is created automatically when you create a cluster using
+[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
+or successfully deploy a Minikube cluster.
 By default, kubectl configuration is located at `~/.kube/config`.
 -->
-## 配置 kubectl 
+## 验证 kubectl 配置   {#verifying-kubectl-configuration}
 
-kubectl 需要一个 [kubeconfig 配置文件](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)使其找到并访问 Kubernetes 集群。当您使用 kube-up.sh 脚本创建 Kubernetes 集群或者部署 Minikube 集群时，会自动生成 kubeconfig 配置文件。请参阅[入门指南](/docs/setup/)以了解更多创建集群相关的信息。如果您需要访问一个并非由您创建的集群，请参阅[如何共享集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。默认情况下，kubectl 配置文件位于 `~/.kube/config`。
+kubectl 需要一个
+[kubeconfig 配置文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+使其找到并访问 Kubernetes 集群。当你使用
+[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)
+创建 Kubernetes 集群或者使用已经部署好的 Minikube 集群时，
+会自动生成 kubeconfig 配置文件。
+默认情况下，kubectl 的配置文件位于 `~/.kube/config`。
 
 <!--
-## Check the kubectl configuration
 Check that kubectl is properly configured by getting the cluster state:
-
-```shell
-kubectl cluster-info
-```
-If you see a URL response, kubectl is correctly configured to access your cluster.
-
-If you see a message similar to the following, kubectl is not correctly configured or not able to connect to a Kubernetes cluster.
-
-```shell
-The connection to the server <server-name:port> was refused - did you specify the right host or port?
-```
-
-For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
-
-If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
-
-```shell
-kubectl cluster-info dump
-```
 -->
-## 检查 kubectl 的配置
 通过获取集群状态检查 kubectl 是否被正确配置：
 
 ```shell
 kubectl cluster-info
 ```
-如果您看到一个 URL 被返回，那么 kubectl 已经被正确配置，能够正常访问您的 Kubernetes 集群。
 
-如果您看到类似以下的信息被返回，那么 kubectl 没有被正确配置，无法正常访问您的 Kubernetes 集群。
+<!--
+If you see a URL response, kubectl is correctly configured to access your cluster.
+
+If you see a message similar to the following, kubectl is not correctly configured or not able to connect to a Kubernetes cluster.
+-->
+如果你看到一个 URL 被返回，那么 kubectl 已经被正确配置，能够正常访问你的 Kubernetes 集群。
+
+如果你看到类似以下的信息被返回，那么 kubectl 没有被正确配置，无法正常访问你的 Kubernetes 集群。
 
 ```shell
 The connection to the server <server-name:port> was refused - did you specify the right host or port?
 ```
 
-例如，如果您打算在笔记本电脑（本地）上运行 Kubernetes 集群，则需要首先安装 minikube 等工具，然后重新运行上述命令。
+<!--
+For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
 
-如果 kubectl cluster-info 能够返回 url 响应，但您无法访问您的集群，可以使用下面的命令检查配置是否正确：
+If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
+-->
+例如，如果你打算在笔记本电脑（本地）上运行 Kubernetes 集群，则需要首先安装 minikube 等工具，然后重新运行上述命令。
+
+如果 kubectl cluster-info 能够返回 URL 响应，但你无法访问你的集群，可以使用下面的命令检查配置是否正确：
 
 ```shell
 kubectl cluster-info dump
 ```
 
 <!--
+## Optional kubectl configurations
+
 ## Enabling shell autocompletion
 
-kubectl includes autocompletion support, which can save a lot of typing!
+kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
 
-The completion script itself is generated by kubectl, so you typically just need to invoke it from your profile.
-
-Common examples are provided here. For more details, consult `kubectl completion -h`.
+Below are the procedures to set up autocompletion for Bash (including the difference between Linux and macOS) and Zsh.
 -->
-## 启用 shell 自动补全功能
+## 可选的 kubectl 配置
 
-kubectl 支持自动补全功能，可以节省大量输入！
+### 启用 shell 自动补全功能
 
-自动补全脚本由 kubectl 产生，您仅需要在您的 shell 配置文件中调用即可。
+kubectl 为 Bash 和 Zsh 支持自动补全功能，可以节省大量输入！
 
-以下仅提供了使用命令补全的常用示例，更多详细信息，请查阅 `kubectl completion -h` 帮助命令的输出。
+下面是设置 Bash 与 Zsh 下自动补齐的过程（包括 Linux 与 macOS 的差异）。
+
+{{< tabs name="kubectl_autocompletion" >}}
+
+{{% tab name="Linux 上的 Bash" %}}
 
 <!--
-### On Linux, using bash
-On CentOS Linux, you may need to install the bash-completion package which is not installed by default.
+### Introduction
 
-```shell
-yum install bash-completion -y
-```
+The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion.
 
-To add kubectl autocompletion to your current shell, run `source <(kubectl completion bash)`.
-
-To add kubectl autocompletion to your profile, so it is automatically loaded in future shells run:
-
-```shell
-echo "source <(kubectl completion bash)" >> ~/.bashrc
-```
+However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
 -->
-### Linux 系统，使用 bash
-在 CentOS Linux系统上，您可能需要安装默认情况下未安装的 bash-completion 软件包。
+#### 介绍
 
-```shell
-yum install bash-completion -y
+用于 Bash 的 kubectl 自动补齐脚本可以用 `kubectl completion bash` 命令生成。
+在 Shell 环境中引用自动补齐脚本就可以启用 kubectl 自动补齐。
+
+不过，补齐脚本依赖于 [**bash-completion**](https://github.com/scop/bash-completion) 软件包，
+这意味着你必须先安装 bash-completion（你可以通过运行 `type _init_completion`）来测试是否
+你已经安装了这个软件）。
+
+<!--
+### Install bash-completion
+
+bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
+
+The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file.
+
+To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
+-->
+### 安装 bash-completion
+
+很多包管理器都提供 bash-completion（参见[这里](https://github.com/scop/bash-completion#installation)）。
+你可以通过 `apt-get install bash-completion` 或 `yum install bash-completion` 来安装。
+
+上述命令会创建 `/usr/share/bash-completion/bash_completion`，也就是 bash-completion 的主脚本。
+取决于所用的包管理器，你可能必须在你的 `~/.bashrc` 中通过 `source` 源引此文件。
+
+要搞清楚这一点，可以重新加载你的 Shell 并运行 `type _init_completion`。
+如果命令成功，一切就绪；否则你就需要将下面的内容添加到你的 `~/.bashrc`
+文件中：
+
+```bash
+source /usr/share/bash-completion/bash_completion
 ```
 
-执行 `source <(kubectl completion bash)` 命令在您目前正在运行的 shell 中开启 kubectl 自动补全功能。
+之后，重新加载你的 Shell 并运行 `type _init_completion` 来检查 bash-completion 是否已
+正确安装。
 
-可以将上述命令添加到 shell 配置文件中，这样在今后运行的 shell 中将自动开启 kubectl 自动补全：
+<!--
+### Enable kubectl autocompletion
 
-```shell
-echo "source <(kubectl completion bash)" >> ~/.bashrc
+You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
+-->
+### 启用 kubectl 自动补齐
+
+你现在需要确定在你的所有 Shell 会话中都源引了 kubectl 自动补齐脚本。
+实现这点有两种方式：
+
+<!--
+- Source the completion script in your `~/.bashrc` file:
+-->
+- 在 `~/.bashrc` 文件中源引自动补齐脚本
+
+  ```bash
+  echo 'source <(kubectl completion bash)' >>~/.bashrc
+  ```
+
+<!--
+- Add the completion script to the `/etc/bash_completion.d` directory:
+-->
+- 将自动补齐脚本添加到目录 `/etc/bash_completion.d`：
+
+  ```bash
+  kubectl completion bash >/etc/bash_completion.d/kubectl
+  ```
+
+<!--
+If you have an alias for kubectl, you can extend shell completion to work with that alias:
+-->
+如果你为 kubectl 命令设置了别名（alias），你可以扩展 Shell 补齐，使之能够与别名一起使用：
+
+```bash
+echo 'alias k=kubectl' >>~/.bashrc
+echo 'complete -F __start_kubectl k' >>~/.bashrc
 ```
 
 <!--
-### On macOS, using bash
-On macOS, you will need to install bash-completion support via [Homebrew](https://brew.sh/) first:
+- Source the completion script in your `~/.bashrc` file:
+-->
 
-```shell
-## If running Bash 3.2 included with macOS
-brew install bash-completion
-## or, if running Bash 4.1+
+<!--
+bash-completion sources all completion scripts in `/etc/bash_completion.d`.
+-->
+{{< note >}}
+bash-completion 会自动源引 `/etc/bash_completion.d` 下的所有自动补齐脚本。
+{{< /note >}}
+
+<!--
+Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
+-->
+两种方法是等价的。重新加载 Shell 之后，kubectl 的自动补齐应该能够使用了。
+
+{{% /tab %}}
+
+{{% tab name="macOS 上的 Bash" %}}
+
+<!--
+### Introduction
+
+The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion.
+
+However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
+-->
+### 介绍
+
+用于 Bash 的 kubectl 自动补齐脚本可以用 `kubectl completion bash` 命令生成。
+在 Shell 环境中引用自动补齐脚本就可以启用 kubectl 自动补齐。
+不过，补齐脚本依赖于 [**bash-completion**](https://github.com/scop/bash-completion) 软件包，
+你必须预先安装。
+
+<!--
+There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2
+(which is the default on macOS), and v2 is for Bash 4.1+. The kubectl
+completion script **doesn't work** correctly with bash-completion v1 and Bash
+3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to
+correctly use kubectl completion on macOS, you have to install and use Bash
+4.1+
+([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)).
+The following instructions assume that you use Bash 4.1+ (that is, any Bash
+version of 4.1 or newer).
+-->
+{{< warning>}}
+`bash-completion` 有两个版本，v1 和 v2。
+v1 是用于 Bash 3.2 版本的（macOS 上的默认配置），v2 是用于 Bash 4.1 以上版本的。
+`kubectl` 补齐脚本 *无法* 在 v1 版本的 bash-completion 和 Bash 3.2 上使用，
+需要 **bash-completion v2** 和 **Bash 4.1 以上版本**。
+因此，为了在 macOS 上正常使用 kubectl 自动补齐，你需要安装并使用 Bash 4.1+
+版本（[*相关指南*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)）。
+下面的指令假定你在使用 Bash 4.1+（也就是说 Bash 4.1 及以上版本）。
+{{< /warning >}}
+
+<!--
+### Upgrade Bash
+
+The instructions here assume you use Bash 4.1+. You can check your Bash's version by running:
+-->
+### 升级 Bash  {#upgrade-bash}
+
+这里的命令假定你使用的是 Bash 4.1+。你可以通过下面的命令来检查 Bash 版本：
+
+```bash
+echo $BASH_VERSION
+```
+
+<!--
+If it is too old, you can install/upgrade it using Homebrew:
+-->
+如果版本很老，你可以使用 Homebrew 来安装或升级：
+
+```bash
+brew install bash
+```
+
+<!--
+Reload your shell and verify that the desired version is being used:
+-->
+重新加载 Shell 并验证你使用的版本是期望的版本：
+
+```bash
+echo $BASH_VERSION $SHELL
+```
+
+<!--
+Homebrew usually installs it at `/usr/local/bin/bash`.
+-->
+Homebrew 通常安装 Bash 到 `/usr/local/bin/bash`。
+
+<!--
+### Install bash-completion
+
+{{< note >}}
+As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
+{{< /note >}}
+
+You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
+-->
+### 安装 bash-completion
+
+{{< note >}}
+如前所述，这里的指令假定你使用的是 Bash 4.1+，这意味着你会安装 bash-completion
+的 v2 版本（与此相对，在 Bash 3.2 版本中的 bash-completion v1 是 kubectl
+无法使用的。
+{{< /note >}}
+
+你可以通过输入 `type _init_completion` 来测试是否 bash-completion v2 已经安装。
+如果没有，可以用 Homebrew 来安装：
+
+```bash
 brew install bash-completion@2
 ```
 
-Follow the "caveats" section of brew's output to add the appropriate bash completion path to your local .bashrc.
-
-If you installed kubectl using the [Homebrew instructions](#install-with-homebrew-on-macos) then kubectl completion should start working immediately.
-
-If you have installed kubectl manually, you need to add kubectl autocompletion to the bash-completion:
-
-```shell
-kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl
-```
-
-The Homebrew project is independent from Kubernetes, so the bash-completion packages are not guaranteed to work.
+<!--
+As stated in the output of this command, add the following to your `~/.bash_profile` file:
 -->
-### macOS 系统，使用 bash
-macOS 系统需要先通过 [Homebrew](https://brew.sh/) 安装 bash-completion：
+就像命令的输出所提示的，你应该将下面的内容添加到 `~/.bash_profile` 文件中：
 
-```shell
-## 如果您运行的是 macOS 自带的 Bash 3.2，请运行：
-brew install bash-completion
-## 如果您使用的是 Bash 4.1+，请运行：
-brew install bash-completion@2
+```bash
+export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
+[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
 ```
 
-请根据 Homebrew 输出的”注意事项（caveats）”部分的内容将 bash-completion 的路径添加到本地 .bashrc 文件中。
-
-如果您是按照 [Homebrew 指示](#jump)中的步骤安装的 kubectl，那么无需其他配置，kubectl 的自动补全功能已经被启用。
-
-如果您是手工下载并安装的 kubectl，那么您需要将 kubectl 自动补全添加到 bash-completion：
-
-```shell
-kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl
-```
-
-由于 Homebrew 项目与 Kubernetes 无关，所以并不能保证 bash-completion 总能够支持 kubectl 的自动补全功能。
-
 <!--
-### Using Zsh
-If you are using zsh edit the ~/.zshrc file and add the following code to enable kubectl autocompletion:
-
-```shell
-if [ $commands[kubectl] ]; then
-  source <(kubectl completion zsh)
-fi
-```
-
-Or when using [Oh-My-Zsh](http://ohmyz.sh/), edit the ~/.zshrc file and update the `plugins=` line to include the kubectl plugin.
-
-```shell
-plugins=(kubectl)
-```
+Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`.
 -->
-### 使用 Zsh
-如果您使用的是 zsh,请编辑 ~/.zshrc 文件并添加以下代码以启用 kubectl 自动补全功能。
+重新加载你的 Shell 并运行 `type _init_completion`，验证 bash-completion v2
+被正确安装。
 
+<!--
+### Enable kubectl autocompletion
+
+You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
+-->
+### 启用 kubectl 自动补齐
+
+你现在需要确保在你的所有 Shell 会话中都源引了 kubectl 自动补齐脚本。
+实现这点有两种方式：
+
+<!--
+- Source the completion script in your `~/.bashrc` file:
+-->
+- 在 `~/.bash_profile` 文件中源引自动补齐脚本
+
+  ```bash
+  echo 'source <(kubectl completion bash)' >>~/.bash_profile
+  ```
+
+<!--
+- Add the completion script to the `/etc/bash_completion.d` directory:
+-->
+- 将自动补齐脚本添加到目录 `/usr/local/etc/bash_completion.d`：
+
+  ```bash
+  kubectl completion bash >//usr/local/etc/bash_completion.d/kubectl
+  ```
+
+<!--
+If you have an alias for kubectl, you can extend shell completion to work with that alias:
+-->
+- 如果你为 kubectl 命令设置了别名（alias），你可以扩展 Shell 补齐，使之能够与别名一起使用：
+
+  ```bash
+  echo 'alias k=kubectl' >>~/.bash_profile
+  echo 'complete -F __start_kubectl k' >>~/.bash_profile
+  ```
+
+<!--
+- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
+
+  The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
+
+In any case, after reloading your shell, kubectl completion should be working.
+-->
+- 如果你是所有 Homebrew 来安装 kubectl（如[前文](#install-with-homebrew-on-macos)所述）, 
+  kubectl 补齐脚本应该已经位于 `/usr/local/etc/bash_completion.d/kubectl` 目录下。
+  在这种情况下，你就不用做任何操作了。
+
+<!--
+The Homebrew installation of bash-completion v2 sources all the files in the
+`BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
+-->
+{{< note >}}
+Homebrew 安装 bash-completion v2 时会源引 `BASH_COMPLETION_COMPAT_DIR` 目录下的所有
+文件，这是为什么后面两种方法也可行的原因。
+{{< /note >}}
+
+<!--
+In any case, after reloading your shell, kubectl completion should be working.
+-->
+在任何一种情况下，重新加载 Shell 之后，kubectl 的自动补齐应该可以工作了。
+
+{{% /tab %}}
+
+{{% tab name="Zsh" %}}
+
+<!--
+The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion.
+
+To do so in all your shell sessions, add the following to your `~/.zshrc` file:
+-->
+Zsh 的 kubectl 补齐脚本可通过 `kubectl completion zsh` 命令来生成。
+在 Shell 环境中引用自动补齐脚本就可以启用 kubectl 自动补齐。
 
 ```shell
-if [ $commands[kubectl] ]; then
-  source <(kubectl completion zsh)
-fi
+source <(kubectl completion zsh)
 ```
 
-如果您使用的是 [Oh-My-Zsh](http://ohmyz.sh/)，请编辑 ~/.zshrc 文件并更新 `plugins=` 行以包含 kubectl 插件。
+<!--
+If you have an alias for kubectl, you can extend shell completion to work with that alias:
+-->
+如果你为 kubectl 命令设置了别名（alias），你可以扩展 Shell 补齐，使之能够与别名一起使用：
 
 ```shell
-plugins=(kubectl)
+echo 'alias k=kubectl' >>~/.zshrc
+echo 'complete -F __start_kubectl k' >>~/.zshrc
 ```
 
+<!--
+After reloading your shell, kubectl autocompletion should be working.
+-->
+重新加载 Shell 之后，kubectl 的自动补齐应该可以工作了。
+
+<!--
+If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
+-->
+如果你看到类似 `complete:13: command not found: compdef` 这种错误信息，
+可以将下面的命令添加到你的 `~/.zshrc` 文件的文件头：
+
+```zsh
+autoload -Uz compinit
+compinit
+```
+
+{{% /tab %}}
+
+{{< /tabs >}}
 
 ## {{% heading "whatsnext" %}}
 
 <!--
-[Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* [Install Minikube](https://minikube.sigs.k8s.io/docs/start/)
+* See the [getting started guides](/docs/setup/) for more about creating clusters.
+* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* If you need access to a cluster you didn't create, see the
+  [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
 -->
-[了解如何启动并对外暴露您的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster/)
-
+* [安装 Minikube](https://minikube.sigs.k8s.io/docs/start/)
+* 参阅[入门指南](/zh/docs/setup/)，了解创建集群相关的信息
+* 了解如何[启动和暴露你的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* 如果你需要访问别人创建的集群，参考
+  [共享集群访问文档](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* 阅读 [kubectl 参考文档](/zh/docs/reference/kubectl/kubectl/)
 
diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md
deleted file mode 100644
index 270524f109..0000000000
--- a/content/zh/docs/tasks/tools/install-minikube.md
+++ /dev/null
@@ -1,446 +0,0 @@
----
-title: 安装 Minikube
-content_type: task
-weight: 20
-card:
-  name: tasks
-  weight: 10
----
-
-<!--
-title: Install Minikube
-content_type: task
-weight: 20
-card:
-  name: tasks
-  weight: 10
--->
-
-<!-- overview -->
-
-<!--
-This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
--->
-本页面讲述如何安装 [Minikube](/zh/docs/tutorials/hello-minikube)，该工具用于在你电脑中的虚拟机上运行一个单节点的 Kubernetes 集群。
-
-## {{% heading "prerequisites" %}}
-
-{{< tabs name="minikube_before_you_begin" >}}
-{{% tab name="Linux" %}}
-
-<!--
-To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
--->
-
-若要检查你的 Linux 是否支持虚拟化技术，请运行下面的命令并验证输出结果是否不为空：
-
-```
-grep -E --color 'vmx|svm' /proc/cpuinfo
-```
-
-{{% /tab %}}
-
-{{% tab name="macOS" %}}
-
-<!--
-To check if virtualization is supported on macOS, run the following command on your terminal.
--->
-若要检查你的 macOS 是否支持虚拟化技术，请运行下面的命令：
-
-```
-sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
-```
-
-<!--
-If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
--->
-如果你在输出结果中看到了 `VMX` （应该会高亮显示）的字眼，说明你的电脑已启用 VT-x 特性。
-
-{{% /tab %}}
-
-{{% tab name="Windows" %}}
-<!--
-To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
--->
-若要检查你的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令：
-
-```
-systeminfo
-```
-<!--
-If you see the following output, virtualization is supported on Windows.
--->
-如果你看到下面的输出，则表示该 Windows 支持虚拟化技术。
-
-```
-Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
-                          Virtualization Enabled In Firmware: Yes
-                          Second Level Address Translation: Yes
-                          Data Execution Prevention Available: Yes
-```
-
-<!--
-If you see the following output, your system already has a Hypervisor installed and you can skip the next step.
--->
-如果你看到下面的输出，则表示你的操作系统已经安装了 Hypervisor，你可以跳过安装 Hypervisor 的步骤。
-```
-Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-<!-- steps -->
-
-<!--
-# Installing minikube
--->
-## 安装 minikube
-
-{{< tabs name="tab_with_md" >}}
-{{% tab name="Linux" %}}
-
-<!--
-### Install kubectl
-
-Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
--->
-### 安装 kubectl
-
-请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)
-的说明来安装 kubectl。
-
-<!--
-### Install a Hypervisor
-
-If you do not already have a hypervisor installed, install one of these now:
--->
-
-### 安装 Hypervisor
-
-如果还没有装过 hypervisor，请选择以下方式之一进行安装：
-
-<!--
-• [KVM](https://www.linux-kvm.org/), which also uses QEMU
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
--->
-
-- [KVM](https://www.linux-kvm.org/)，KVM 也使用了 QEMU
-- [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-<!--
-Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM.
-Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
-
-If you're using the `none` driver in Debian or a derivative, use the `.deb` packages for
-Docker rather than the snap package, which does not work with Minikube.
-You can download `.deb` packages from [Docker](https://www.docker.com/products/docker-desktop).
--->
-Minikube 还支持使用一个 `--vm-driver=none` 选项，让 Kubernetes 组件运行在主机上，而不是在 VM 中。
-使用这种驱动方式需要 [Docker](https://www.docker.com/products/docker-desktop) 和 Linux 环境，但不需要 hypervisor。
-
-如果你在 Debian 系的 OS 中使用了 `none` 这种驱动方式，请使用 `.deb` 包安装 Docker，不要使用 snap 包的方式，Minikube 不支持这种方式。
-你可以从 [Docker](https://www.docker.com/products/docker-desktop) 下载 `.deb` 包。
-
-<!--
-The `none` VM driver can result in security and data loss issues.
-Before using `--vm-driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
--->
-{{< caution >}}
-`none` VM 驱动方式存在导致安全和数据丢失的问题。
-使用 `--vm-driver=none` 之前，请参考[这个文档](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)获取详细信息。
-{{< /caution >}}
-
-<!--
-Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
--->
-Minikube 还支持另外一个类似于 Docker 驱动的方式 `vm-driver=podman`。
-使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用
-你的操作系统上的所有特性。
-
-<!--
-The `podman` driver requires running the containers as root because regular user accounts don’t have full access to all operating system features that their containers might need to run.
--->
-{{< caution >}}
-`Podman` 驱动需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限
-使用容器运行可能需要的操作系统上的所有特性。
-{{< /caution >}}
-
-<!--
-### Install Minikube using a package
-
-There are *experimental* packages for Minikube available; you can find Linux (AMD64) packages
-from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page on GitHub.
-
-Use your Linux's distribution's package tool to install a suitable package.
--->
-### 使用包安装 Minikube
-
-Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的[发行版本](https://github.com/kubernetes/minikube/releases) 找到 Linux (AMD64) 的包。
-
-根据你的 Linux 发行版选择安装合适的包。
-
-<!--
-### Install Minikube via direct download
-
-If you're not installing via a package, you can download a stand-alone
-binary and use that.
--->
-### 直接下载并安装 Minikube
-
-如果你不想通过包安装，你也可以下载并使用一个单节点二进制文件。
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
-  && chmod +x minikube
-```
-
-<!--
-Here's an easy way to add the Minikube executable to your path:
--->
-将 Minikube 可执行文件添加至 PATH：
-
-```shell
-sudo mkdir -p /usr/local/bin/
-sudo install minikube /usr/local/bin/
-```
-
-<!--
-### Install Minikube using Homebrew
-
-As yet another alternative, you can install Minikube using Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux):
--->
-### 使用 Homebrew 安装 Minikube
-
-你还可以使用 Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 安装 Minikube：
-
-```shell
-brew install minikube
-```
-
-{{% /tab %}}
-
-{{% tab name="macOS" %}}
-
-<!--
-### Install kubectl
-
-Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
--->
-### 安装 kubectl
-
-请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)
-的说明来安装 kubectl。
-
-<!--
-### Install a Hypervisor
-
-If you do not already have a hypervisor installed, install one of these now:
--->
-### 安装 Hypervisor
-
-如果你还没有安装 hypervisor，请选择以下方式之一进行安装：
-
-• [HyperKit](https://github.com/moby/hyperkit)
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-• [VMware Fusion](https://www.vmware.com/products/fusion)
-
-<!--
-### Install Minikube
-The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh):
--->
-### 安装 Minikube
-
-macOS 安装 Minikube 最简单的方法是使用 [Homebrew](https://brew.sh)：
-
-```shell
-brew install minikube
-```
-
-<!--
-You can also install it on macOS by downloading a stand-alone binary:
--->
-你也可以通过下载独立的可执行文件进行安装：
-
-```shell
-curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
-  && chmod +x minikube
-```
-
-<!--
-Here's an easy way to add the Minikube executable to your path:
--->
-下面是一个简单的将 Minikube 可执行文件添加至 PATH 的方法：
-
-```shell
-sudo mv minikube /usr/local/bin
-```
-
-{{% /tab %}}
-{{% tab name="Windows" %}}
-
-<!--
-### Install kubectl
-
-Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
--->
-### 安装 kubectl
-
-请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)
-的说明来安装 kubectl。
-
-<!--
-### Install a Hypervisor
-
-If you do not already have a hypervisor installed, install one of these now:
--->
-### 安装 Hypervisor
-
-如果你还没有安装 hypervisor，请选择以下方式之一进行安装：
-
-• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
-<!--
-Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
--->
-{{< note >}}
-Hyper-V 可以运行在三个版本的 Windows 10 上：企业版、专业版和教育版（Enterprise, Professional, Education）。
-{{< /note >}}
-
-<!--
-### Install Minikube using Chocolatey
-
-The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
--->
-### 使用 Chocolatey 安装 Minikube
-
-Windows 安装 Minikube 最简单的方法是使用 [Chocolatey](https://chocolatey.org/) （以管理员身份运行）：
-
-```shell
-choco install minikube
-```
-
-<!--
-After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
--->
-完成 Minikube 的安装后，关闭当前 CLI 界面再重新打开。
-Minikube 应该已经自动添加至 path 中。
-
-<!--
-### Install Minikube using an installer executable
-
-To install Minikube manually on Windows using [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), download [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) and execute the installer.
--->
-
-### 使用安装程序安装 Minikube
-
-在 Windows 上使用 [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal) 手动安装 Minikube，下载并运行 [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) 即可。
-
-<!--
-### Install Minikube via direct download
-
-To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path.
--->
-### 直接下载并安装 Minikube
-
-想在 Windows 上手动安装 Minikube，下载 [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest) 并将其重命名为 `minikube.exe`，然后将其添加至 path 即可。
-
-{{% /tab %}}
-{{< /tabs >}}
-
-<!--
-## Confirm Installation
-
-To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster:
--->
-## 安装确认
-
-要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群：
-
-<!--
-For setting the `--vm-driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--vm-driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
--->
-{{< note >}}
-若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<驱动名称>` 的地方，
-用小写字母输入你安装的 hypervisor 的名称。
-[指定 VM 驱动程序](/zh/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)
-列举了 `--vm-driver` 值的完整列表。
-{{< /note >}}
-
-{{< note >}}
-由于国内无法直接连接 k8s.gcr.io，推荐使用阿里云镜像仓库，在 `minikube start` 中添加 `--image-repository` 参数。
-{{< /note >}}
-
-```shell
-minikube start --vm-driver=<驱动名称>
-# 或者在需要时
-minikube start --vm-driver=<驱动名称> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
-```
-
-<!--
-Once `minikube start` finishes, run the command below to check the status of the cluster:
--->
-一旦 `minikube start` 完成，你可以运行下面的命令来检查集群的状态：
-
-```shell
-minikube status
-```
-
-<!--
-If your cluster is running, the output from `minikube status` should be similar to:
--->
-如果你的集群正在运行，`minikube status` 的输出结果应该类似于这样：
-
-```
-host: Running
-kubelet: Running
-apiserver: Running
-kubeconfig: Configured
-```
-
-<!--
-After you have confirmed whether Minikube is working with your chosen hypervisor, you can continue to use Minikube or you can stop your cluster. To stop your cluster, run:
--->
-在确认 Minikube 与 hypervisor 均正常工作后，你可以继续使用 Minikube 或停止集群。要停止集群，请运行：
-
-```shell
-minikube stop
-```
-
-<!--
-## Clean up local state {#cleanup-local-state}
-
-If you have previously installed Minikube, and run:
--->
-## 清理本地状态          {#cleanup-local-state}
-
-如果你之前安装过 Minikube，并运行了：
-
-```shell
-minikube start
-```
-
-<!-- and `minikube start` returned an error: -->
-并且 `minikube start` 返回了一个错误：
-
-```
-machine does not exist
-```
-
-<!-- then you need to clear minikube's local state: -->
-那么，你需要清理 minikube 的本地状态：
-
-```shell
-minikube delete
-```
-
-## {{% heading "whatsnext" %}}
-
-<!--
-* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
--->
-
-* [使用 Minikube 在本地运行 Kubernetes](/zh/docs/setup/learning-environment/minikube/)
-
diff --git a/content/zh/docs/templates/feature-state-alpha.txt b/content/zh/docs/templates/feature-state-alpha.txt
deleted file mode 100644
index 37b3ef9753..0000000000
--- a/content/zh/docs/templates/feature-state-alpha.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-该功能目前处于 *alpha* 状态，意味着：
-
-* 版本名称包含 alpha（例如 v1alpha1）。
-* 可能存在问题，启用该功能可能会暴露 bug。默认情况下被禁用。
-* 对该功能的支持可能在任何时候被取消，而不另行通知。
-* API 可能会在以后的软件版本中以不兼容的方式被更改，而不另行通知。
-* 建议仅在短期测试集群中使用该功能，这是因为使用该功能会增加出现 bug 的风险，而且缺乏长期支持。
\ No newline at end of file
diff --git a/content/zh/docs/templates/feature-state-beta.txt b/content/zh/docs/templates/feature-state-beta.txt
deleted file mode 100644
index 34765b6e8e..0000000000
--- a/content/zh/docs/templates/feature-state-beta.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-该功能目前处于 *beta* 状态，意味着：
-
-* 版本名称包含 beta （例如 v2beta3）。
-* 代码经过了充分测试，启用该功能被认为是安全的。默认情况下被启用。
-* 对整体功能的支持在未来不会被移除，尽管细节上可能会做更改。
-* 在后续的 beta 或稳定版本中，对象的模式、语义可能以不兼容的方式发生变化。当这种情况发生时，我们将提供迁移到下一个版本的说明。这可能需要删除、编辑和重建 API 对象，编辑过程可能需要一些思考。这可能导致依赖该功能的应用程序停机一段时间。
-* 建议仅在非业务关键场景使用该功能，因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的集群，那么您可能可以放松这个限制。
-* **请尝试使用我们的 beta 版功能，并给出反馈！在它们退出 beta 测试阶段之后，我们将很难去做更多的更改。**
\ No newline at end of file
diff --git a/content/zh/docs/templates/feature-state-deprecated.txt b/content/zh/docs/templates/feature-state-deprecated.txt
deleted file mode 100644
index 06a0a43660..0000000000
--- a/content/zh/docs/templates/feature-state-deprecated.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-
-该功能已被*弃用*。有关此状态的更多信息，请参见[Kubernetes 弃用策略](/docs/reference/deprecation-policy/)。
diff --git a/content/zh/docs/templates/feature-state-stable.txt b/content/zh/docs/templates/feature-state-stable.txt
deleted file mode 100644
index aa422b9f1a..0000000000
--- a/content/zh/docs/templates/feature-state-stable.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-
-该功能是“稳定的”，意味着：
-
-* 版本名是 vX，其中 X 是整数。
-* 该功能将出现在多个后续释出的软件稳定版中。
diff --git a/content/zh/docs/templates/index.md b/content/zh/docs/templates/index.md
deleted file mode 100644
index cddc5576cc..0000000000
--- a/content/zh/docs/templates/index.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-headless: true
-
-resources:
-- src: "*alpha*"
-  title: "alpha"
-- src: "*beta*"
-  title: "beta"
-- src: "*deprecated*"
-  title: "废弃"
-- src: "*stable*"
-  title: "稳定"
----
-
-<!--
----
-headless: true
-
-resources:
-- src: "*alpha*"
-  title: "alpha"
-- src: "*beta*"
-  title: "beta"
-- src: "*deprecated*"
-  title: "deprecated"
-- src: "*stable*"
-  title: "stable"
----
--->
diff --git a/content/zh/docs/test.md b/content/zh/docs/test.md
new file mode 100644
index 0000000000..d873d6cb6d
--- /dev/null
+++ b/content/zh/docs/test.md
@@ -0,0 +1,898 @@
+---
+title: 测试页面（中文版）
+main_menu: false
+---
+<!--
+title: Docs smoke test page
+main_menu: false
+-->
+
+<!--
+This page serves two purposes:
+
+- Demonstrate how the Kubernetes documentation uses Markdown
+- Provide a "smoke test" document we can use to test HTML, CSS, and template
+  changes that affect the overall documentation.
+-->
+本页面服务于两个目的：
+
+- 展示 Kubernetes 中文版文档中应如何使用 Markdown
+- 提供一个测试用文档，用来测试可能影响所有文档的 HTML、CSS 和模板变更
+
+<!--
+## Heading levels
+
+The above heading is an H2. The page title renders as an H1. The following
+sections show H3-H6.
+
+### H3
+
+This is in an H3 section.
+
+#### H4
+
+This is in an H4 section.
+
+##### H5
+
+This is in an H5 section.
+
+###### H6
+
+This is in an H6 section.
+-->
+## 标题级别
+
+上面的标题是 H2 级别。页面标题（Title）会渲染为 H1。以下各节分别展示 H3-H6
+的渲染结果。
+
+### H3
+
+此处为 H3 节内容。
+
+#### H4
+
+此处为 H4 节内容。
+
+##### H5
+
+此处为 H5 节内容。
+
+###### H6
+
+此处为 H6 节内容。
+
+<!--
+## Inline elements
+
+Inline elements show up within the text of paragraph, list item, admonition, or
+other block-level element.
+-->
+## 内联元素（Inline elements）
+
+内联元素显示在段落文字、列表条目、提醒信息或者块级别元素之内。
+
+Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
+incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
+nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
+Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu
+fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
+culpa qui officia deserunt mollit anim id est laborum.
+
+### 内联文本风格
+
+<!--
+- **bold**
+- _italic_
+- ***bold italic***
+- ~~strikethrough~~
+- <u>underline</u>
+- _<u>underline italic</u>_
+- **<u>underline bold</u>**
+- ***<u>underline bold italic</u>***
+- `monospace text`
+- **`monospace bold`**
+-->
+- **粗体字**
+- _斜体字_
+- ***粗斜体字***
+- ~~删除线~~
+- <u>下划线</u>
+- _<u>带下划线的斜体</u>_
+- ***<u>带下划线的粗斜体</u>***
+- `monospace text`  <- 等宽字体
+- **`monospace bold`**    <- 粗等宽字体
+
+## 列表
+
+<!--
+Markdown doesn't have strict rules about how to process lists. When we moved
+from Jekyll to Hugo, we broke some lists. To fix them, keep the following in
+mind:
+
+- Make sure you indent sub-list items **4 spaces** rather than the 2 that you
+  may be used to. Counter-intuitively, you need to indent block-level content
+  within a list item an extra 4 spaces too.
+
+- To end a list and start another, you need a HTML comment block on a new line
+  between the lists, flush with the left-hand border. The first list won't end
+  otherwise, no matter how many blank lines you put between it and the second.
+-->
+Markdown 在如何处理列表方面没有严格的规则。在我们从 Jekyll 迁移到 Hugo 时，
+我们遇到了一些问题。为了处理这些问题，请注意以下几点：
+
+- 确保你将子列表的条目缩进**四个空格**而不是你可能熟悉的两个空格。
+  有一点是不那么直观的，你需要将列表中的块级别内容多缩进四个空格。
+
+- 要结束一个列表并开始一个新的列表，你需要在两个列表之间添加加一个 HTML 注释块，
+  并将其置于独立的一行，左边顶边对齐。否则前一个列表不会结束，无论你在它与
+  第二个列表之间放多少个空行。
+
+<!--
+### Bullet lists
+
+- This is a list item
+* This is another list item in the same list
+- You can mix `-` and `*`
+    - To make a sub-item, indent two tabstops (4 spaces). **This is different
+      from Jekyll and Kramdown.**
+        - This is a sub-sub-item. Indent two more tabstops (4 more spaces).
+    - Another sub-item.
+-->
+### 项目符号列表
+
+- 此为列表条目
+* 此为另一列表条目，位于同一列表中
+- 你可以将 `-` 和 `*` 混合使用
+  - 要开始子列表，缩进两个 TAB （四个空格）。**Jekyll 和 Markdown
+    在这点上有所不同**。
+    - 这是另一个子子条目。进一步多缩进两个空格。
+  - 另一个子条目
+
+<!-- separate lists -->
+
+<!--
+- This is a new list.  With Hugo, you need to use a HTML comment to separate two
+  consecutive lists. **The HTML comment needs to be at the left margin.**
+- Bullet lists can have paragraphs or block elements within them.
+
+      Indent the content to be one tab stop beyond the text of the bullet
+      point. **This paragraph and the code block line up with the second `l` in
+      `Bullet` above.**
+
+      ```bash
+      ls -l
+      ```
+
+      - And a sub-list after some block-level content
+-->
+- 这是一个新的列表。使用 Hugo 时，你需要用一行 HTML 注释将两个紧挨着的列表分开。
+  **这里的 HTML 注释需要按左侧顶边对齐。**
+- 项目符号列表可以中包含文字段落或块元素。
+
+  段落内容与第一行文字左侧对齐。
+  **此段文字和下面的代码段都与前一行中的“项”字对齐。**
+
+  ```bash
+  ls -l
+  ```
+
+  - 在块级内容之后还可以有子列表内容。
+
+<!--
+- A bullet list item can contain a numbered list.
+    1.  Numbered sub-list item 1
+    2.  Numbered sub-list item 2
+-->
+- 项目符号列表条目中还可以包含编号列表。
+    1.  编号子列表条目一
+    1.  编号子列表条目二
+
+- 项目符号列表条目中包含编号列表的另一种形式（推荐形式）。让子列表的编号数字
+  与项目符号列表文字左对齐。
+
+  1. 编号子列表条目一，左侧编号与前一行的“项”字左对齐。
+  1.  编号子列表条目二，条目文字与数字之间多了一个空格。
+
+<!--
+### Numbered lists
+
+1.  This is a list item
+2.  This is another list item in the same list. The number you use in Markdown
+    does not necessarily correlate to the number in the final output. By
+    convention, we keep them in sync.
+3.  {{<note>}}
+    For single-digit numbered lists, using two spaces after the period makes
+    interior block-level content line up better along tab-stops.
+    {{</note>}}
+-->
+### 编号列表
+
+1.  此为列表条目
+1.  此为列表中的第二个条目。在 Markdown 源码中所给的编号数字与最终输出的数字
+    可能不同。建议在紧凑列表中编号都使用 1。如果条目之间有其他内容（比如注释
+    掉的英文）存在，则需要显式给出编号。
+2.  {{<note>}}
+    对于单个数字的编号列表，在句点（`.`）后面加两个空格。这样有助于将列表的
+    内容更好地对齐。
+    {{</note>}}
+
+
+<!-- separate lists -->
+
+<!--
+1.  This is a new list. With Hugo, you need to use a HTML comment to separate
+    two consecutive lists. **The HTML comment needs to be at the left margin.**
+2.  Numbered lists can have paragraphs or block elements within them.
+
+      Just indent the content to be one tab stop beyond the text of the bullet
+      point. **This paragraph and the code block line up with the `m` in
+      `Numbered` above.**
+
+      ```bash
+      ls -l
+      ```
+
+    - And a sub-list after some block-level content. This is at the same
+      "level" as the paragraph and code block above, despite being indented
+      more.
+-->
+1.  这是一个新的列表。 使用 Hugo 时，你需要用 HTML 注释将两个紧挨着的列表分开。
+    **HTML 注释需要按左边顶边对齐。**
+2.  编号列表条目中也可以包含额外的段落或者块元素。
+
+    后续段落应该按编号列表文字的第一行左侧对齐。
+    **此段落及下面的代码段都与本条目中的第一个字“编”对齐。**
+
+    ```bash
+    ls -l
+    ```
+
+    - 编号列表条目中可以在块级内容之后有子列表。子列表的符号项要与上层列表条目
+      文字左侧对齐。
+
+### 中文译文的编号列表格式 1
+
+<!--
+1. English item 1
+-->
+1. 译文条目一
+
+<!--
+1. English item 2
+-->
+2. 译文条目二，由于前述原因，条目 2 与 1 之间存在注释行，如果此条目不显式给出
+   起始编号，会被 Hugo 当做两个独立的列表。
+
+### 中文译文的编号列表格式 2
+
+<!--
+1. English item 1
+-->
+1. 译文条目一
+
+   <!-- trunk of english text -->
+   中文译文段落。
+
+   <!--
+   ```shell
+   # list services
+   kubectl get svc
+   ```
+   -->
+   带注释的代码段（**注意以上英文注释 `<!--` 和 `-->` 的缩进空格数**）。
+
+   ```shell
+   # 列举服务
+   kubectl get svc
+   ```
+
+<!--
+1. English item 2
+-->
+2. 译文条目二，由于前述原因，条目 2 与 1 之间存在注释行，如果此条目不显式给出
+   起始编号，会被 Hugo 当做两个独立的列表。
+
+<!--
+### Tab lists
+
+Tab lists can be used to conditionally display content, e.g., when multiple
+options must be documented that require distinct instructions or context.
+-->
+### 标签列表
+
+标签列表可以用来有条件地显式内容，例如，当有多种选项可供选择时，每个选项
+可能需要完全不同的指令或者上下文。
+
+<!--
+{{</* tabs name="tab_lists_example" */>}}
+{{%/* tab name="Choose one..." */%}}
+请注意这里对英文原文短代码的处理。目的是确保其中的 tabs 短代码失效。
+由于 Hugo 的局限性，如果不作类似处理，这里的 tabs 尽管已经被包含在
+HTML 注释块中，仍然会生效！
+
+Please select an option.
+{{%/* /tab */%}}
+-->
+{{< tabs name="tab_lists_example" >}}
+{{% tab name="请选择..." %}}
+请选择一个选项。
+{{% /tab %}}
+
+<!--
+{{%/* tab name="Formatting tab lists" */%}}
+-->
+{{% tab name="在标签页中格式化列表" %}}
+
+<!--
+Tabs may also nest formatting styles.
+
+1. Ordered
+1. (Or unordered)
+1. Lists
+
+```bash
+echo 'Tab lists may contain code blocks!'
+```
+-->
+标签页中也可以包含嵌套的排版风格，其中的英文注释处理也同正文中
+的处理基本一致。
+
+1. 编号列表
+1. （或者没有编号的）
+1. 列表
+
+```bash
+echo '标签页里面也可以有代码段!'
+```
+
+{{% /tab %}}
+<!--
+{{%/* tab name="Nested headers" */%}}
+-->
+{{% tab name="嵌套的子标题" %}}
+
+<!--
+### Headers in Tab list
+
+Nested header tags may also be included.
+-->
+### 在标签页中的子标题
+
+标签页中也可以包含嵌套的子标题。
+
+<!--
+{{</* warning */>}}
+Headers within tab lists will not appear in the Table of Contents.
+{{</* /warning */>}}
+-->
+{{< warning >}}
+标签页中的子标题不会在目录中出现。
+{{< /warning >}}
+
+{{% /tab %}}
+{{< /tabs >}}
+
+<!--
+### Checklists
+
+Checklists are technically bullet lists, but the bullets are suppressed by CSS.
+
+- [ ] This is a checklist item
+- [x] This is a selected checklist item
+-->
+### 检查项列表  （Checklists）
+
+检查项列表本质上也是一种项目符号列表，只是这里的项目符号部分被 CSS 压制了。
+
+- [ ] 此为第一个检查项
+- [x] 此为被选中的检查项
+
+<!--
+## Code blocks
+
+You can create code blocks two different ways by surrounding the code block with
+three back-tick characters on lines before and after the code block. **Only use
+back-ticks (code fences) for code blocks.** This allows you to specify the
+language of the enclosed code, which enables syntax highlighting. It is also more
+predictable than using indentation.
+-->
+## 代码段
+
+你可以用两种方式来创建代码块。一种方式是将在代码块之前和之后分别加上包含三个
+反引号的独立行。**反引号应该仅用于代码段。**
+用这种方式标记代码段时，你还可以指定所包含的代码的编程语言，从而启用语法加亮。
+这种方式也比使用空格缩进的方式可预测性更好。
+
+<!--
+```
+this is a code block created by back-ticks
+```
+-->
+```
+这是用反引号创建的代码段
+```
+
+<!--
+The back-tick method has some advantages.
+
+- It works nearly every time
+- It is more compact when viewing the source code.
+- It allows you to specify what language the code block is in, for syntax
+  highlighting.
+- It has a definite ending. Sometimes, the indentation method breaks with
+  languages where spacing is significant, like Python or YAML.
+-->
+反引号标记代码段的方式有以下优点：
+
+- 这种方式几乎总是能正确工作
+- 在查看源代码时，内容相对紧凑
+- 允许你指定代码块的编程语言，以便启用语法加亮
+- 代码段的结束位置有明确标记。有时候，采用缩进空格的方式会使得一些对空格
+  很敏感的语言（如 Python、YAML）很难处理。
+
+<!--
+To specify the language for the code block, put it directly after the first
+grouping of back-ticks:
+-->
+要为代码段指定编程语言，可以在第一组反引号之后加上编程语言名称：
+
+```bash
+ls -l
+```
+
+<!--
+Common languages used in Kubernetes documentation code blocks include:
+
+- `bash` / `shell` (both work the same)
+- `go`
+- `json`
+- `yaml`
+- `xml`
+- `none` (disables syntax highlighting for the block)
+-->
+Kubernetes 文档中代码块常用语言包括：
+
+- `bash` / `shell` （二者几乎完全相同）
+- `go`
+- `json`
+- `yaml`
+- `xml`
+- `none` （禁止对代码块执行语法加亮）
+
+<!--
+### Code blocks containing Hugo shortcodes
+
+To show raw Hugo shortcodes as in the above example and prevent Hugo
+from interpreting them, use C-style comments directly after the `<` and before
+the `>` characters. The following example illustrates this (view the Markdown
+source for this page).
+-->
+### 包含 Hugo 短代码的代码块
+
+如果要像上面的例子一样显示 Hugo 短代码（Shortcode），不希望 Hugo 将其当做短代码来处理，
+可以在 `<` 和 `>` 之间使用 C 语言风格的注释。
+下面的示例展示如何实现这点（查看本页的 Markdown 源码）：
+
+```none
+{{</* codenew file="pods/storage/gce-volume.yaml" */>}}
+```
+
+<!--
+## Links
+
+To format a link, put the link text inside square brackets, followed by the
+link target in parentheses. [Link to Kubernetes.io](https://kubernetes.io/) or
+[Relative link to Kubernetes.io](/)
+
+You can also use HTML, but it is not preferred.
+<a href="https://kubernetes.io/">Link to Kubernetes.io</a>
+-->
+## 链接
+
+要格式化链接，将链接显示文本放在方括号中，后接用圆括号括起来的链接目标。
+[指向 Kubernetes.io 的连接](https://kubernetes.io/) 或
+[到 Kubernetes.io 的相对链接](/)。
+
+你也可以使用 HTML，但这种方式不是推荐的方式。
+<a href="https://kubernetes.io/">到 Kubernetes.io 的链接</a>。
+
+### 中文链接
+
+中文版本文档中的链接要注意以下两点：
+
+- 指向 Kubernetes 文档的站内链接，需要在英文链接之前添加前缀 `/zh`。
+  例如，原链接目标为 `/docs/foo/bar` 时，译文中的链接目标应为
+  `/zh/docs/foo/bar`。例如：
+
+  - 英文版本链接 [Kubernetes Components](/docs/concepts/overview/components/)
+  - 对应中文链接 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
+
+- 英文页面子标题会生成对应锚点（Anchor），例如子标题 `## Using object` 会生成
+  对应标签 `#using-objects`。在翻译为中文之后，对应锚点可能会失效。对此，有
+  两种方法处理。假定译文中存在以下子标题：
+
+  ```
+  <!--
+  ## Clean up
+
+  You can do this ...
+  -->
+  ## 清理现场
+
+  你可以这样 ...
+  ```
+
+  并且在本页或其他页面有指向 `#clean-up` 的链接如下：
+
+  ```
+  ..., please refer to the [clean up](#clean-up) section.
+  ```
+
+  第一种处理方法是将链接改为中文锚点，即将引用该子标题的文字全部改为中文锚点。
+  例如：
+    
+  ```
+  ..., 请参考[清理工作](#清理现场)一节。
+  ```
+
+  第二种方式（也是推荐的方式）是将原来可能生成的锚点（尽管在英文原文中未明确
+  给出）显式标记在译文的子标题上。
+
+  ```
+  <!--
+  ## Clean up
+
+  You can do this ...
+  -->
+  ## 清理现场  {#clean-up}
+
+  你可以这样 ...
+  ```
+
+  之所以优选第二种方式是因为可以避免文档站点中其他引用此子标题的链接失效。
+   
+<!--
+## Images
+
+To format an image, use similar syntax to [links](#links), but add a leading `!`
+character. The square brackets contain the image's alt text. Try to always use
+alt text so that people using screen readers can get some benefit from the
+image.
+-->
+## 图片
+
+要显示图片，可以使用与链接类似的语法（`[links](#links)`），不过要在整个链接
+之前添加一个感叹号（`!`）。方括号中给出的是图片的替代文本。
+请坚持为图片设定替代文本，这样使用屏幕阅读器的人也能够了解图片中包含的是什么。
+
+![pencil icon](/images/pencil.png)
+
+<!--
+To specify extended attributes, such as width, title, caption, etc, use the
+<a href="https://gohugo.io/content-management/shortcodes/#figure">figure shortcode</a>,
+which is preferred to using a HTML `<img>` tag. Also, if you need the image to
+also be a hyperlink, use the `link` attribute, rather than wrapping the whole
+figure in Markdown link syntax as shown below.
+-->
+要设置扩展的属性，例如 width、title、caption 等等，可以使用
+<a href="https://gohugo.io/content-management/shortcodes/#figure">figure</a>
+短代码，而不是使用 HTML 的 `<img>` 标签。
+此外，如果你需要让图片本身变成超链接，可以使用短代码的 `link` 属性，而不是
+将整个图片放到 Markdown 的链接语法之内。下面是一个例子：
+
+<!--
+{{</* figure src="/static/images/pencil.png" title="Pencil icon" caption="Image used to illustrate the figure shortcode" width="200px" */>}}
+-->
+{{< figure src="/images/pencil.png" title="铅笔图标" caption="用来展示 figure 短代码的图片" width="200px" >}}
+
+<!--
+Even if you choose not to use the figure shortcode, an image can also be a link. This
+time the pencil icon links to the Kubernetes website. Outer square brackets enclose
+the entire image tag, and the link target is in the parentheses at the end.
+
+[![pencil icon](/images/pencil.png)](https://kubernetes.io)
+
+You can also use HTML for images, but it is not preferred.
+
+<img src="/images/pencil.png" alt="pencil icon" />
+-->
+即使你不想使用 figure 短代码，图片也可以展示为链接。这里，铅笔图标指向
+Kubernetes 网站。外层的方括号将整个 image 标签封装起来，链接目标在
+末尾的圆括号之间给出。
+
+[![pencil icon](/images/pencil.png)](https://kubernetes.io)
+
+你也可以使用 HTML 来嵌入图片，不过这种方式是不推荐的。
+
+<img src="/images/pencil.png" alt="铅笔图标" />
+
+<!--
+## Tables
+
+Simple tables have one row per line, and columns are separated by `|`
+characters. The header is separated from the body by cells containing nothing
+but at least three `-` characters. For ease of maintenance, try to keep all the
+cell separators even, even if you heed to use extra space.
+-->
+## 表格
+
+简单的表格可能每行只有一个独立的数据行，各个列之间用 `|` 隔开。
+表格的标题行与表格内容之间用独立的一行隔开，在这一行中每个单元格的内容
+只有 `-` 字符，且至少三个。出于方便维护考虑，请尝试将各个单元格间的
+分割线对齐，尽管这样意味着你需要多输入几个空格。
+
+<!--
+| Heading cell 1 | Heading cell 2 |
+|----------------|----------------|
+| Body cell 1    | Body cell 2    |
+-->
+| 标题单元格 1   | 标题单元格 2   |
+|----------------|----------------|
+| 内容单元格 1   | 内容单元格 2   |
+
+
+<!--
+The header is optional. Any text separated by `|` will render as a table.
+-->
+标题行是可选的。所有用 `|` 隔开的内容都会被渲染成表格。
+
+<!--
+Markdown tables have a hard time with block-level elements within cells, such as
+list items, code blocks, or multiple paragraphs. For complex or very wide
+tables, use HTML instead.
+-->
+Markdown 表格在处理块级元素方面还很笨拙。例如在单元格中嵌入列表条目、代码段、
+或者在其中划分多个段落方面的能力都比较差。对于复杂的或者很宽的表格，可以使用
+HTML。
+
+<table>
+<thead>
+  <tr>
+    <!-- th>Heading cell 1</th -->
+    <th>标题单元格 1</th>
+    <!-- th>Heading cell 2</th -->
+    <th>标题单元格 2</th>
+  </tr>
+</thead>
+<tbody>
+  <tr>
+    <!-- td>Body cell 1</td -->
+    <td>内容单元格 1</td>
+    <!-- td>Body cell 2</td -->
+    <td>内容单元格 2</td>
+  </tr>
+</tbody>
+</table>
+
+<!--
+## Visualizations with Mermaid
+
+You can use [Mermaid JS](https://mermaidjs.github.io) visualizations.
+The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html)
+-->
+## 使用 Mermaid 来可视化
+
+你可以使用 [Mermaid JS](https://mermaidjs.github.io) 来进行可视化展示。
+Mermaid JS 版本在 [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html)
+中设置。
+
+<!--
+{{</* mermaid */>}}
+graph TD;
+  A->B;
+  A->C;
+  B->D;
+  C->D;
+{{</* mermaid */>}}
+-->
+
+```
+{{</* mermaid */>}}
+graph TD;
+  甲-->乙;
+  甲-->丙;
+  乙-->丁;
+  丙-->丁;
+{{</*/ mermaid */>}}
+```
+
+<!--
+Produces: 
+-->
+会产生：
+
+<!--
+{{</* mermaid */>}}
+graph TD;
+  A->B;
+  A->C;
+  B->D;
+  C->D;
+{{</*/ mermaid */>}}
+-->
+
+{{< mermaid >}}
+graph TD;
+  甲-->乙;
+  甲-->丙;
+  乙-->丁;
+  丙-->丁;
+{{</ mermaid >}}
+
+
+<!--
+```
+{{</* mermaid */>}}
+sequenceDiagram
+    Alice ->> Bob: Hello Bob, how are you?
+    Bob->>John: How about you John?
+    Bob-x Alice: I am good thanks!
+    Bob-x John: I am good thanks!
+    Note right of John: Bob thinks a long<br/>long time, so long<br/>that the text does<br/>not fit on a row.
+
+    Bob->Alice: Checking with John...
+    Alice->John: Yes... John, how are you?
+{{</*/ mermaid */>}}
+```
+-->
+
+```
+{{</* mermaid */>}}
+sequenceDiagram
+    张三 ->> 李四: 李四，锄禾日当午？
+    李四-->>王五: 王五，锄禾日当午？
+    李四--x 张三: 汗滴禾下土！
+    李四-x 王五: 汗滴禾下土！
+    Note right of 王五: 李四想啊想啊<br/>一直想啊想，太阳<br/>都下山了，他还没想出来<br/>，文本框都放不下了。
+
+    李四-->张三: 跑去问王五...
+    张三->王五: 好吧... 王五，白日依山尽？
+{{</*/ mermaid */>}}
+```
+
+<!--
+Produces: 
+-->
+产生：
+
+<!--
+{{< mermaid >}}
+sequenceDiagram
+    Alice ->> Bob: Hello Bob, how are you?
+    Bob->>John: How about you John?
+    Bob-x Alice: I am good thanks!
+    Bob-x John: I am good thanks!
+    Note right of John: Bob thinks a long<br/>long time, so long<br/>that the text does<br/>not fit on a row.
+
+    Bob->Alice: Checking with John...
+    Alice->John: Yes... John, how are you?
+{{</ mermaid >}}
+-->
+
+{{< mermaid >}}
+sequenceDiagram
+    张三 ->> 李四: 李四，锄禾日当午？
+    李四-->>王五: 王五，锄禾日当午？
+    李四--x 张三: 汗滴禾下土！
+    李四-x 王五: 汗滴禾下土！
+    Note right of 王五: 李四想啊想啊一直想，<br/>想到太阳都下山了，<br/>他还没想出来，<br/>文本框都放不下了。
+
+    李四-->张三: 跑去问王五...
+    张三->王五: 好吧... 王五，白日依山尽？
+{{</ mermaid >}}
+
+<!--
+<br>More [examples](https://mermaid-js.github.io/mermaid/#/examples) from the offical docs.
+-->
+<br>在官方网站上有更多的[示例](https://mermaid-js.github.io/mermaid/#/examples)。
+
+<!--
+## Sidebars and Admonitions
+
+Sidebars and admonitions provide ways to add visual importance to text. Use
+them sparingly.
+-->
+## 侧边栏和提醒框
+
+侧边栏和提醒框可以为文本提供直观的重要性强调效果，可以偶尔一用。
+
+<!--
+### Sidebars
+
+A sidebar offsets text visually, but without the visual prominence of
+[admonitions](#admonitions).
+-->
+### 侧边栏（Sidebar）
+
+侧边栏可以将文字横向平移，只是其显示效果可能不像[提醒](#admonitions)那么明显。
+
+<!--
+> This is a sidebar.
+>
+> You can have paragraphs and block-level elements within a sidebar.
+>
+> You can even have code blocks.
+>
+> ```bash
+> sudo dmesg
+> ```
+-->
+
+> 此为侧边栏。
+>
+> 你可以在侧边栏内排版段落和块级元素。
+>
+> 你甚至可以在其中包含代码块。
+>
+> ```bash
+> sudo dmesg
+> ```
+<!--
+### Admonitions
+
+Admonitions (notes, warnings, etc) use Hugo shortcodes.
+-->
+### 提醒框   {#admonitions}
+
+提醒框（说明、警告等等）都是用 Hugo 短代码的形式展现。
+
+<!--
+{{< note >}}
+Notes catch the reader's attention without a sense of urgency.
+
+You can have multiple paragraphs and block-level elements inside an admonition.
+
+| Or | a | table |
+{{< /note >}}
+-->
+{{< note >}}
+说明信息用来引起读者的注意，但不过分强调其紧迫性。
+
+你可以在提醒框内包含多个段落和块级元素。
+
+| 甚至 | 包含 | 表格 |
+{{< /note >}}
+
+<!--
+{{< caution >}}
+The reader should proceed with caution.
+{{< /caution >}}
+-->
+{{< caution >}}
+读者继续此操作时要格外小心。
+{{< /caution >}}
+
+<!--
+{{< warning >}}
+Warnings point out something that could cause harm if ignored.
+{{< /warning >}}
+-->
+{{< warning >}}
+警告信息试图为读者指出一些不应忽略的、可能引发问题的事情。
+{{< /warning >}}
+
+注意，在较老的 Hugo 版本中，直接将 `note`、`warning` 或 `caution` 短代码
+括入 HTML 注释当中是有问题的。这些短代码仍然会起作用。目前，在 0.70.0 
+以上版本中似乎已经修复了这一问题。
+
+<!--
+## Includes
+
+To add shortcodes to includes.
+-->
+## 包含其他页面
+
+要包含其他页面，可使用短代码。
+
+{{< note >}}
+{{< include "task-tutorial-prereqs.md" >}}
+{{< /note >}}
+
+<!--
+## Katacoda Embedded Live Environment
+-->
+## 嵌入的 Katacoda 环境
+
+{{< kat-button >}}
+
diff --git a/content/zh/docs/tutorials/_index.md b/content/zh/docs/tutorials/_index.md
index 0125b0e9ca..f283d60ea6 100644
--- a/content/zh/docs/tutorials/_index.md
+++ b/content/zh/docs/tutorials/_index.md
@@ -1,25 +1,20 @@
 ---
 title: 教程
 main_menu: true
+no_list: true
 weight: 60
 content_type: concept
 ---
 
 <!--
----
 title: Tutorials
 main_menu: true
+no_list: true
 weight: 60
 content_type: concept
----
 -->
 
 <!-- overview -->
-
-Kubernetes 文档的这一部分包含教程。一个教程展示了如何完成一个比单个[任务](/zh/docs/tasks/)更大的目标。
-通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，
-您可能希望将[标准化术语表](/zh/docs/reference/glossary/)页面添加到书签，供以后参考。
-
 <!--
 This section of the Kubernetes documentation contains tutorials.
 A tutorial shows how to accomplish a goal that is larger than a single
@@ -28,133 +23,100 @@ each of which has a sequence of steps.
 Before walking through each tutorial, you may want to bookmark the
 [Standardized Glossary](/docs/reference/glossary/) page for later references.
 -->
-
+Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成一个比单个
+[任务](/zh/docs/tasks/)更大的目标。
+通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，
+您可能希望将[标准化术语表](/zh/docs/reference/glossary/)页面添加到书签，供以后参考。
 
 
 <!-- body -->
-
-## 基础知识
-
 <!--
 ## Basics
--->
 
-* [Kubernetes 基础知识](/zh/docs/tutorials/Kubernetes-Basics/)是一个深入的交互式教程，帮助您理解 Kubernetes 系统，并尝试一些基本的 Kubernetes 特性。
-
-<!--
 * [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
--->
 
-* [使用 Kubernetes (Udacity) 的可伸缩微服务](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
+* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
 
-<!--
-* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
+* [Hello Minikube](/docs/tutorials/hello-minikube/)
 -->
+## 基础知识
+
+* [Kubernetes 基础知识](/zh/docs/tutorials/Kubernetes-Basics/)是一个深入的
+  交互式教程，帮助您理解 Kubernetes 系统，并尝试一些基本的 Kubernetes 特性。
 
 * [介绍 Kubernetes (edx)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
 
-<!--
-* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
--->
-
 * [你好 Minikube](/zh/docs/tutorials/hello-minikube/)
 
-<!--
-* [Hello Minikube]/docs/tutorials/hello-minikube/)
--->
-
-## 配置
-
 <!--
 ## Configuration
+
+* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
 -->
+## 配置
 
 * [使用一个 ConfigMap 配置 Redis](/zh/docs/tutorials/configuration/configure-redis-using-configmap/)
 
-<!--
-* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
--->
-
-## 无状态应用程序
-
 <!--
 ## Stateless Applications
+
+* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
+
+* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
 -->
+## 无状态应用程序
 
 * [公开外部 IP 地址访问集群中的应用程序](/zh/docs/tutorials/stateless-application/expose-external-ip-address/)
 
-<!--
-* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
--->
-
 * [示例：使用 Redis 部署 PHP 留言板应用程序](/zh/docs/tutorials/stateless-application/guestbook/)
 
-<!--
-* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
--->
-
-## 有状态应用程序
 
 <!--
 ## Stateful Applications
+
+* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/)
+
+* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
+
+* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/)
+
+* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
 -->
+## 有状态应用程序
 
 * [StatefulSet 基础](/zh/docs/tutorials/stateful-application/basic-stateful-set/)
 
-<!--
-* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/)
--->
-
 * [示例：WordPress 和 MySQL 使用持久卷](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
 
-<!--
-* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
--->
-
 * [示例：使用有状态集部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)
 
-<!--
-* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/)
--->
-
 * [运行 ZooKeeper，CP 分布式系统](/zh/docs/tutorials/stateful-application/zookeeper/)
 
-<!--
-* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
--->
-
-## 集群
-
-* [AppArmor](/zh/docs/tutorials/clusters/apparmor/)
-
 <!--
 ## Clusters
 
 * [AppArmor](/docs/tutorials/clusters/apparmor/)
 -->
+## 集群
 
-## 服务
-
-* [使用源 IP](/zh/docs/tutorials/services/source-ip/)
+* [AppArmor](/zh/docs/tutorials/clusters/apparmor/)
 
 <!--
 ## Services
 
 * [Using Source IP](/docs/tutorials/services/source-ip/)
 -->
+## 服务
 
-
+* [使用源 IP](/zh/docs/tutorials/services/source-ip/)
 
 ## {{% heading "whatsnext" %}}
 
-
-如果您想编写教程，请参阅[使用页面模板](/zh/docs/home/contribute/page-templates/)
-以获取有关教程页面类型和教程模板的信息。
 <!--
 If you would like to write a tutorial, see
-[Using Page Templates](/docs/home/contribute/page-templates/)
-for information about the tutorial page type and the tutorial template.
+[Content Page Types](/docs/contribute/style/page-content-types/)
+for information about the tutorial page.
 -->
-
-
+如果您想编写教程，请参阅[内容页面类型](/zh/docs/contribute/style/page-content-types/)
+以获取有关教程页面类型的信息。
 
diff --git a/content/zh/docs/tutorials/clusters/seccomp.md b/content/zh/docs/tutorials/clusters/seccomp.md
new file mode 100644
index 0000000000..9dea407d2e
--- /dev/null
+++ b/content/zh/docs/tutorials/clusters/seccomp.md
@@ -0,0 +1,527 @@
+---
+title: 使用 Seccomp 限制容器的系统调用
+content_type: tutorial
+weight: 20
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
+
+<!--
+Seccomp stands for secure computing mode and has been a feature of the Linux
+kernel since version 2.6.12.  It can be used to sandbox the privileges of a
+process, restricting the calls it is able to make from userspace into the
+kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto a
+Node to your Pods and containers.
+
+Identifying the privileges required for your workloads can be difficult. In this
+tutorial, you will go through how to load seccomp profiles into a local
+Kubernetes cluster, how to apply them to a Pod, and how you can begin to craft
+profiles that give only the necessary privileges to your container processes.
+-->
+Seccomp 代表安全计算模式，自 2.6.12 版本以来一直是 Linux 内核的功能。
+它可以用来对进程的特权进行沙盒处理，从而限制了它可以从用户空间向内核进行的调用。
+Kubernetes 允许你将加载到节点上的 seccomp 配置文件自动应用于 Pod 和容器。
+
+确定工作负载所需的特权可能很困难。在本教程中，你将了解如何将 seccomp 配置文件
+加载到本地 Kubernetes 集群中，如何将它们应用到 Pod，以及如何开始制作仅向容器
+进程提供必要特权的配置文件。
+
+## {{% heading "objectives" %}}
+
+<!--
+* Learn how to load seccomp profiles on a node
+* Learn how to apply a seccomp profile to a container
+* Observe auditing of syscalls made by a container process
+* Observe behavior when a missing profile is specified
+* Observe a violation of a seccomp profile
+* Learn how to create fine-grained seccomp profiles
+* Learn how to apply a container runtime default seccomp profile
+-->
+* 了解如何在节点上加载 seccomp 配置文件
+* 了解如何将 seccomp 配置文件应用于容器
+* 观察由容器进程进行的系统调用的审核
+* 观察当指定了一个不存在的配置文件时的行为
+* 观察违反 seccomp 配置的情况
+* 了解如何创建精确的 seccomp 配置文件
+* 了解如何应用容器运行时默认 seccomp 配置文件
+
+## {{% heading "prerequisites" %}}
+
+<!--
+In order to complete all steps in this tutorial, you must install
+[kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and
+[kubectl](/doc/tasks/tools/install-kubectl/). This tutorial will show examples
+with both alpha (pre-v1.19) and generally available seccomp functionality, so
+make sure that your cluster is [configured
+correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
+for the version you are using.
+-->
+为了完成本教程中的所有步骤，你必须安装 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) 
+和 [kubectl](/zh/doc/tasks/tools/install-kubectl/)。本教程将显示同时具有 alpha（v1.19 之前的版本）
+和通常可用的 seccomp 功能的示例，因此请确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。
+
+<!-- steps -->
+<!--
+## Create Seccomp Profiles
+
+The contents of these profiles will be explored later on, but for now go ahead
+and download them into a directory named `profiles/` so that they can be loaded
+into the cluster.
+-->
+## 创建 Seccomp 文件
+
+这些配置文件的内容将在以后进行探讨，但现在继续进行，并将其下载到名为 `profiles/` 的目录中，以便可以将其加载到集群中。
+
+{{< tabs name="tab_with_code" >}}
+{{{< tab name="audit.json" >}}
+{{< codenew file="pods/security/seccomp/profiles/audit.json" >}}
+{{< /tab >}}
+{{< tab name="violation.json" >}}
+{{< codenew file="pods/security/seccomp/profiles/violation.json" >}}
+{{< /tab >}}}
+{{< tab name="fine-grained.json" >}}
+{{< codenew file="pods/security/seccomp/profiles/fine-grained.json" >}}
+{{< /tab >}}}
+{{< /tabs >}}
+
+<!--
+## Create a Local Kubernetes Cluster with Kind
+
+For simplicity, [kind](https://kind.sigs.k8s.io/) can be used to create a single
+node cluster with the seccomp profiles loaded. Kind runs Kubernetes in Docker,
+so each node of the cluster is actually just a container. This allows for files
+to be mounted in the filesystem of each container just as one might load files
+onto a node.
+
+Download the example above, and save it to a file named `kind.yaml`. Then create
+the cluster with the configuration.
+-->
+## 使用 Kind 创建一个本地 Kubernetes 集群
+
+为简单起见，可以使用 [kind](https://kind.sigs.k8s.io/) 创建一个已经加载 seccomp 配置文件的单节点集群。
+Kind 在 Docker 中运行 Kubernetes，因此集群的每个节点实际上只是一个容器。这允许将文件挂载到每个容器的文件系统中，
+就像将文件挂载到节点上一样。
+
+{{< codenew file="pods/security/seccomp/kind.yaml" >}}
+<br>
+
+下载上面的这个示例，并将其保存为 `kind.yaml`。然后使用这个配置创建集群。
+
+```
+kind create cluster --config=kind.yaml
+```
+
+<!--
+Once the cluster is ready, identify the container running as the single node
+cluster:
+-->
+一旦这个集群已经就绪，找到作为单节点集群运行的容器：
+
+```
+docker ps
+```
+
+<!--
+You should see output indicating that a container is running with name
+`kind-control-plane`.
+-->
+你应该看到输出显示正在运行的容器名称为 `kind-control-plane`。
+
+```
+CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                       NAMES
+6a96207fed4b        kindest/node:v1.18.2   "/usr/local/bin/entr…"   27 seconds ago      Up 24 seconds       127.0.0.1:42223->6443/tcp   kind-control-plane
+```
+
+<!--
+If observing the filesystem of that container, one should see that the
+`profiles/` directory has been successfully loaded into the default seccomp path
+of the kubelet. Use `docker exec` to run a command in the Pod:
+-->
+如果观察该容器的文件系统，则应该看到 `profiles/` 目录已成功加载到 kubelet 的默认 seccomp 路径中。
+使用 `docker exec` 在 Pod 中运行命令：
+
+```
+docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles
+```
+
+```
+audit.json  fine-grained.json  violation.json
+```
+
+<!--
+## Create a Pod with a Seccomp profile for syscall auditing
+
+To start off, apply the `audit.json` profile, which will log all syscalls of the
+process, to a new Pod.
+
+Download the correct manifest for your Kubernetes version:
+-->
+## 使用 Seccomp 配置文件创建 Pod 以进行系统调用审核
+
+首先，将 `audit.json` 配置文件应用到新的 Pod 中，该配置文件将记录该进程的所有系统调用。
+
+为你的 Kubernetes 版本下载正确的清单：
+
+{{< tabs name="audit_pods" >}}
+{{< tab name="v1.19 或更新版本（GA）" >}}
+{{< codenew file="pods/security/seccomp/ga/audit-pod.yaml" >}}
+{{< /tab >}}}
+{{{< tab name="v1.19之前版本（alpha）" >}}
+{{< codenew file="pods/security/seccomp/alpha/audit-pod.yaml" >}}
+{{< /tab >}}
+{{< /tabs >}}
+<br>
+
+<!--
+Create the Pod in the cluster:
+-->
+在集群中创建 Pod：
+
+```
+kubectl apply -f audit-pod.yaml
+```
+
+<!--
+This profile does not restrict any syscalls, so the Pod should start
+successfully.
+-->
+这个配置文件并不限制任何系统调用，所以这个 Pod 应该会成功启动。
+
+```
+kubectl get pod/audit-pod
+```
+
+```
+NAME        READY   STATUS    RESTARTS   AGE
+audit-pod   1/1     Running   0          30s
+```
+
+<!--
+In order to be able to interact with this endpoint exposed by this
+container,create a NodePort Service that allows access to the endpoint from
+inside the kind control plane container.
+-->
+为了能够与该容器公开的端点进行交互，请创建一个 NodePort 服务，
+该服务允许从 kind 控制平面容器内部访问该端点。
+
+```
+kubectl expose pod/audit-pod --type NodePort --port 5678
+```
+
+<!--
+Check what port the Service has been assigned on the node.
+-->
+检查这个服务在这个节点上被分配了什么端口。
+
+```
+kubectl get svc/audit-pod
+```
+
+```
+NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+audit-pod   NodePort   10.111.36.142   <none>        5678:32373/TCP   72s
+```
+
+<!--
+Now you can `curl` the endpoint from inside the kind control plane container at
+the port exposed by this Service. Use `docker exec` to run a command in the Pod:
+-->
+现在你可以使用 `curl` 命令从 kind 控制平面容器内部通过该服务暴露出来的端口来访问这个端点。
+
+```
+docker exec -it 6a96207fed4b curl localhost:32373
+```
+
+```
+just made some syscalls!
+```
+
+<!--
+You can see that the process is running, but what syscalls did it actually make?
+Because this Pod is running in a local cluster, you should be able to see those
+in `/var/log/syslog`. Open up a new terminal window and `tail` the output for
+calls from `http-echo`:
+
+```
+tail -f /var/log/syslog | grep 'http-echo'
+```
+
+You should already see some logs of syscalls made by `http-echo`, and if you
+`curl` the endpoint in the control plane container you will see more written.
+-->
+你可以看到该进程正在运行，但是实际上执行了哪些系统调用？因为该 Pod 是在本地集群中运行的，
+你应该可以在 `/var/log/syslog` 日志中看到这些。打开一个新的终端窗口，使用 `tail` 命令来
+查看来自 `http-echo` 的调用输出：
+
+```
+tail -f /var/log/syslog | grep 'http-echo'
+```
+
+你应该已经可以看到 `http-echo` 发出的一些系统调用日志，
+如果你在控制面板容器内 `curl` 了这个端点，你会看到更多的日志。
+
+```
+Jul  6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000
+Jul  6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000
+Jul  6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
+Jul  6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000
+Jul  6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000
+Jul  6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
+Jul  6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
+Jul  6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
+```
+
+<!--
+You can begin to understand the syscalls required by the `http-echo` process by
+looking at the `syscall=` entry on each line. While these are unlikely to
+encompass all syscalls it uses, it can serve as a basis for a seccomp profile
+for this container.
+
+Clean up that Pod and Service before moving to the next section:
+
+```
+kubectl delete pod/audit-pod
+kubectl delete svc/audit-pod
+```
+-->
+通过查看每一行上的 `syscall=` 条目，你可以开始了解 `http-echo` 进程所需的系统调用。
+尽管这些不太可能包含它使用的所有系统调用，但它可以作为该容器的 seccomp 配置文件的基础。
+
+开始下一节之前，请清理该 Pod 和 Service：
+
+```
+kubectl delete pod/audit-pod
+kubectl delete svc/audit-pod
+```
+
+<!--
+## Create Pod with Seccomp Profile that Causes Violation
+
+For demonstration, apply a profile to the Pod that does not allow for any
+syscalls.
+
+Download the correct manifest for your Kubernetes version:
+-->
+## 使用导致违规的 Seccomp 配置文件创建 Pod
+
+为了进行演示，请将不允许任何系统调用的配置文件应用于 Pod。
+
+为你的 Kubernetes 版本下载正确的清单：
+
+{{< tabs name="violation_pods" >}}
+{{< tab name="v1.19 或更新版本（GA）" >}}
+{{< codenew file="pods/security/seccomp/ga/violation-pod.yaml" >}}
+{{< /tab >}}}
+{{{< tab name="v1.19 之前版本（alpha）" >}}
+{{< codenew file="pods/security/seccomp/alpha/violation-pod.yaml" >}}
+{{< /tab >}}
+{{< /tabs >}}
+<br>
+
+<!--
+Create the Pod in the cluster:
+-->
+在集群中创建 Pod：
+
+```
+kubectl apply -f violation-pod.yaml
+```
+
+<!--
+If you check the status of the Pod, you should see that it failed to start.
+-->
+如果你检查 Pod 的状态，你将会看到该 Pod 启动失败。
+
+```
+kubectl get pod/violation-pod
+```
+
+```
+NAME            READY   STATUS             RESTARTS   AGE
+violation-pod   0/1     CrashLoopBackOff   1          6s
+```
+
+<!--
+As seen in the previous example, the `http-echo` process requires quite a few
+syscalls. Here seccomp has been instructed to error on any syscall by setting
+`"defaultAction": "SCMP_ACT_ERRNO"`. This is extremely secure, but removes the
+ability to do anything meaningful. What you really want is to give workloads
+only the privileges they need.
+
+Clean up that Pod and Service before moving to the next section:
+-->
+如上例所示，`http-echo` 进程需要大量的系统调用。通过设置 `"defaultAction": "SCMP_ACT_ERRNO"`，
+来指示 seccomp 在任何系统调用上均出错。这是非常安全的，但是会删除执行有意义的操作的能力。
+你真正想要的只是给工作负载所需的特权。
+
+开始下一节之前，请清理该 Pod 和 Service：
+
+```
+kubectl delete pod/violation-pod
+kubectl delete svc/violation-pod
+```
+
+<!--
+## Create Pod with Seccomp Profile that Only Allows Necessary Syscalls
+
+If you take a look at the `fine-pod.json`, you will notice some of the syscalls
+seen in the first example where the profile set `"defaultAction":
+"SCMP_ACT_LOG"`. Now the profile is setting `"defaultAction": "SCMP_ACT_ERRNO"`,
+but explicitly allowing a set of syscalls in the `"action": "SCMP_ACT_ALLOW"`
+block. Ideally, the container will run successfully and you will see no messages
+sent to `syslog`.
+
+Download the correct manifest for your Kubernetes version:
+-->
+## 使用设置仅允许需要的系统调用的配置文件来创建 Pod
+
+如果你看一下 `fine-pod.json` 文件，你会注意到在第一个示例中配置文件设置为 `"defaultAction": "SCMP_ACT_LOG"` 的一些系统调用。
+现在，配置文件设置为 `"defaultAction": "SCMP_ACT_ERRNO"`，但是在 `"action": "SCMP_ACT_ALLOW"` 块中明确允许一组系统调用。
+理想情况下，容器将成功运行，并且你将不会看到任何发送到 `syslog` 的消息。
+
+为你的 Kubernetes 版本下载正确的清单：
+
+{{< tabs name="fine_pods" >}}
+{{< tab name="v1.19 或更新版本（GA）" >}}
+{{< codenew file="pods/security/seccomp/ga/fine-pod.yaml" >}}
+{{< /tab >}}}
+{{{< tab name="v1.19 之前版本（alpha）" >}}
+{{< codenew file="pods/security/seccomp/alpha/fine-pod.yaml" >}}
+{{< /tab >}}
+{{< /tabs >}}
+<br>
+
+<!--
+Create the Pod in your cluster:
+-->
+在你的集群上创建Pod：
+
+```
+kubectl apply -f fine-pod.yaml
+```
+
+<!--
+The Pod should start successfully.
+-->
+Pod 应该被成功启动。
+
+```
+kubectl get pod/fine-pod
+```
+
+```
+NAME        READY   STATUS    RESTARTS   AGE
+fine-pod   1/1     Running   0          30s
+```
+
+<!--
+Open up a new terminal window and `tail` the output for calls from `http-echo`:
+-->
+打开一个新的终端窗口，使用 `tail` 命令查看来自 `http-echo` 的调用的输出：
+
+```
+tail -f /var/log/syslog | grep 'http-echo'
+```
+
+<!--
+Expose the Pod with a NodePort Service:
+-->
+使用 NodePort 服务为该 Pod 开一个端口：
+
+```
+kubectl expose pod/fine-pod --type NodePort --port 5678
+```
+
+<!--
+Check what port the Service has been assigned on the node:
+-->
+检查服务在该节点被分配了什么端口：
+
+```
+kubectl get svc/fine-pod
+```
+
+```
+NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+fine-pod    NodePort   10.111.36.142   <none>        5678:32373/TCP   72s
+```
+
+<!--
+`curl` the endpoint from inside the kind control plane container:
+-->
+使用 `curl` 命令从 kind 控制面板容器内部请求这个端点：
+
+```
+docker exec -it 6a96207fed4b curl localhost:32373
+```
+
+```
+just made some syscalls!
+```
+
+<!--
+You should see no output in the `syslog` because the profile allowed all
+necessary syscalls and specified that an error should occur if one outside of
+the list is invoked. This is an ideal situation from a security perspective, but
+required some effort in analyzing the program. It would be nice if there was a
+simple way to get closer to this security without requiring as much effort.
+
+Clean up that Pod and Service before moving to the next section:
+-->
+你会看到 `syslog` 中没有任何输出，因为这个配置文件允许了所有需要的系统调用，
+并指定如果有发生列表之外的系统调用将发生错误。从安全角度来看，这是理想的情况，
+但是在分析程序时需要多付出一些努力。如果有一种简单的方法无需花费太多精力就能更接近此安全性，那就太好了。
+
+开始下一节之前，请清理该 Pod 和 Service：
+
+```
+kubectl delete pod/fine-pod
+kubectl delete svc/fine-pod
+```
+
+<!--
+## Create Pod that uses the Container Runtime Default Seccomp Profile
+
+Most container runtimes provide a sane set of default syscalls that are allowed
+or not. The defaults can easily be applied in Kubernetes by using the
+`runtime/default` annotation or setting the seccomp type in the security context
+of a pod or container to `RuntimeDefault`.
+
+Download the correct manifest for your Kubernetes version:
+-->
+## 使用容器运行时默认的 Seccomp 配置文件创建 Pod
+
+大多数容器运行时都提供一组允许或不允许的默认系统调用。通过使用 `runtime/default` 注释
+或将 Pod 或容器的安全上下文中的 seccomp 类型设置为 `RuntimeDefault`，可以轻松地在 Kubernetes 中应用默认值。
+
+为你的 Kubernetes 版本下载正确的清单：
+
+{{< tabs name="default_pods" >}}
+{{< tab name="v1.19 或更新版本（GA）" >}}
+{{< codenew file="pods/security/seccomp/ga/default-pod.yaml" >}}
+{{< /tab >}}}
+{{{< tab name="v1.19 之前版本（alpha）" >}}
+{{< codenew file="pods/security/seccomp/alpha/default-pod.yaml" >}}
+{{< /tab >}}
+{{< /tabs >}}
+<br>
+
+<!--
+The default seccomp profile should provide adequate access for most workloads.
+-->
+默认的 seccomp 配置文件应该为大多数工作负载提供足够的权限。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+Additional resources:
+
+* [A Seccomp Overview](https://lwn.net/Articles/656307/)
+* [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/)
+-->
+额外的资源：
+
+* [Seccomp 概要](https://lwn.net/Articles/656307/)
+* [Seccomp 在 Docker 中的安全配置](https://docs.docker.com/engine/security/seccomp/)
\ No newline at end of file
diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/_index.md b/content/zh/docs/tutorials/configuration/configure-java-microservice/_index.md
new file mode 100755
index 0000000000..b94fbbb97f
--- /dev/null
+++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/_index.md
@@ -0,0 +1,10 @@
+---
+title: "示例：配置 java 微服务"
+weight: 10
+---
+<!-- 
+---
+title: "Example: Configuring a Java Microservice"
+weight: 10
+---
+-->
\ No newline at end of file
diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
new file mode 100644
index 0000000000..f453fc75cb
--- /dev/null
+++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
@@ -0,0 +1,37 @@
+---
+title: "互动教程 - 配置 java 微服务"
+weight: 20
+---
+<!-- 
+---
+title: "Interactive Tutorial - Configuring a Java Microservice"
+weight: 20
+---
+-->
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                <!-- To interact with the Terminal, please use the desktop/tablet version -->
+                如需要与终端交互，请使用台式机/平板电脑版
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/9" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+        </div>
+    </main>
+
+</div>
+
+</body>
+</html>
diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
new file mode 100644
index 0000000000..b6357ed284
--- /dev/null
+++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
@@ -0,0 +1,93 @@
+---
+title: "使用 MicroProfile、ConfigMaps、Secrets 实现外部化应用配置"
+content_type: tutorial
+weight: 10
+---
+<!-- 
+---
+title: "Externalizing config using MicroProfile, ConfigMaps and Secrets"
+content_type: tutorial
+weight: 10
+---
+-->
+
+<!-- overview -->
+
+<!-- 
+In this tutorial you will learn how and why to externalize your microservice’s configuration.  Specifically, you will learn how to use Kubernetes ConfigMaps and Secrets to set environment variables and then consume them using MicroProfile Config.
+-->
+在本教程中，你会学到如何以及为什么要实现外部化微服务应用配置。
+具体来说，你将学习如何使用 Kubernetes ConfigMaps 和 Secrets 设置环境变量，
+然后在 MicroProfile config 中使用它们。
+
+## {{% heading "prerequisites" %}}
+
+<!-- 
+### Creating Kubernetes ConfigMaps & Secrets
+There are several ways to set environment variables for a Docker container in Kubernetes, including: Dockerfile, kubernetes.yml, Kubernetes ConfigMaps, and Kubernetes Secrets.  In the tutorial, you will learn how to use the latter two for setting your environment variables whose values will be injected into your microservices.  One of the benefits for using ConfigMaps and Secrets is that they can be re-used across multiple containers, including being assigned to different environment variables for the different containers.
+-->
+### 创建 Kubernetes ConfigMaps 和 Secrets  {#creating-kubernetes-configmaps-secrets}
+在 Kubernetes 中，为 docker 容器设置环境变量有几种不同的方式，比如：
+Dockerfile、kubernetes.yml、Kubernetes ConfigMaps、和 Kubernetes Secrets。
+在本教程中，你将学到怎么用后两个方式去设置你的环境变量，而环境变量的值将注入到你的微服务里。
+使用 ConfigMaps 和 Secrets 的一个好处是他们能在多个容器间复用，
+比如赋值给不同的容器中的不同环境变量。
+
+<!-- 
+ConfigMaps are API Objects that store non-confidential key-value pairs.  In the Interactive Tutorial you will learn how to use a ConfigMap to store the application's name.  For more information regarding ConfigMaps, you can find the documentation [here].
+
+Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that they're intended for confidential/sensitive information and are stored using Base64 encoding.  This makes secrets the appropriate choice for storing such things as credentials, keys, and tokens, the former of which you'll do in the Interactive Tutorial.  For more information on Secrets, you can find the documentation [here](/docs/concepts/configuration/secret/).
+-->
+ConfigMaps 是存储非机密键值对的 API 对象。
+在互动教程中，你会学到如何用 ConfigMap 来保存应用名字。
+ConfigMap 的更多信息，你可以在[这里](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)找到文档。
+
+Secrets 尽管也用来存储键值对，但区别于 ConfigMaps 的是：它针对机密/敏感数据，且存储格式为 Base64 编码。
+secrets 的这种特性使得它适合于存储证书、密钥、令牌，上述内容你将在交互教程中实现。
+Secrets 的更多信息，你可以在[这里](/zh/docs/concepts/configuration/secret/)找到文档。
+
+
+<!-- 
+### Externalizing Config from Code
+Externalized application configuration is useful because configuration usually changes depending on your environment.  In order to accomplish this, we'll use Java's Contexts and Dependency Injection (CDI) and MicroProfile Config. MicroProfile Config is a feature of MicroProfile, a set of open Java technologies for developing and deploying cloud-native microservices.
+-->
+### 从代码外部化配置
+外部化应用配置之所以有用处，是因为配置常常根据环境的不同而变化。
+为了实现此功能，我们用到了 Java 上下文和依赖注入（Contexts and Dependency Injection, CDI）、MicroProfile 配置。
+MicroProfile config 是 MicroProfile 的功能特性，
+是一组开放 Java 技术，用于开发、部署云原生微服务。
+
+<!-- 
+CDI provides a standard dependency injection capability enabling an application to be assembled from collaborating, loosely-coupled beans.  MicroProfile Config provides apps and microservices a standard way to obtain config properties from various sources, including the application, runtime, and environment.  Based on the source's defined priority, the properties are automatically combined into a single set of properties that the application can access via an API.  Together, CDI & MicroProfile will be used in the Interactive Tutorial to retrieve the externally provided properties from the Kubernetes ConfigMaps and Secrets and get injected into your application code.
+
+Many open source frameworks and runtimes implement and support MicroProfile Config.  Throughout the interactive tutorial, you'll be using Open Liberty, a flexible open-source Java runtime for building and running cloud-native apps and microservices.  However, any MicroProfile compatible runtime could be used instead. 
+-->
+CDI 提供一套标准的依赖注入能力，使得应用程序可以由相互协作的、松耦合的 beans 组装而成。
+MicroProfile Config 为 app 和微服务提供从各种来源，比如应用、运行时、环境，获取配置参数的标准方法。
+基于来源定义的优先级，属性可以自动的合并到单独一组应用可以通过 API 访问到的属性。
+CDI & MicroProfile 都会被用在互动教程中，
+用来从 Kubernetes ConfigMaps 和 Secrets 获得外部提供的属性，并注入应用程序代码中。
+
+很多开源框架、运行时支持 MicroProfile Config。
+对于整个互动教程，你都可以使用开放的库、灵活的开源 Java 运行时，去构建并运行云原生的 apps 和微服务。
+然而，任何 MicroProfile 兼容的运行时都可以用来做替代品。
+
+
+## {{% heading "objectives" %}}
+
+<!-- 
+* Create a Kubernetes ConfigMap and Secret
+* Inject microservice configuration using MicroProfile Config
+-->
+* 创建 Kubernetes ConfigMap 和 Secret
+* 使用 MicroProfile Config 注入微服务配置
+
+  
+<!-- lessoncontent -->
+
+<!-- 
+## Example: Externalizing config using MicroProfile, ConfigMaps and Secrets
+### [Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) 
+-->
+## 示例：使用 MicroProfile、ConfigMaps、Secrets 实现外部化应用配置
+### [启动互动教程](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) 
diff --git a/content/zh/docs/tutorials/hello-minikube.md b/content/zh/docs/tutorials/hello-minikube.md
index b889324fc5..834ccec67b 100644
--- a/content/zh/docs/tutorials/hello-minikube.md
+++ b/content/zh/docs/tutorials/hello-minikube.md
@@ -1,5 +1,5 @@
 ---
-title: 你好 Minikube
+title: 你好，Minikube
 content_type: tutorial
 weight: 5
 menu:
@@ -7,13 +7,12 @@ menu:
     title: "Get Started"
     weight: 10
     post: >
-      <p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
+      <p>准备好动手操作了么？构建一个简单的 Kubernetes 集群来运行示例应用。</p>
 card:
   name: tutorials
   weight: 10
 ---
 <!--
----
 title: Hello Minikube
 content_type: tutorial
 weight: 5
@@ -22,64 +21,48 @@ menu:
     title: "Get Started"
     weight: 10
     post: >
-      <p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
+      <p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs a sample app.</p>
 card:
   name: tutorials
   weight: 10
----
 -->
 
 <!-- overview -->
 
 <!--
-This tutorial shows you how to run a simple Hello World Node.js app
+This tutorial shows you how to run a sample app
 on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda.
 Katacoda provides a free, in-browser Kubernetes environment.
 -->
-本教程向您展示如何使用 [Minikube](/zh/docs/setup/learning-environment/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。
+本教程向你展示如何使用 [Minikube](/zh/docs/setup/learning-environment/minikube) 和 Katacoda
+在 Kubernetes 上运行一个应用示例。Katacoda 提供免费的浏览器内 Kubernetes 环境。
 
-{{< note >}}
 <!--
 You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/).
 -->
-如果您已在本地安装 [Minikube](/zh/docs/tasks/tools/install-minikube/)，也可以按照本教程操作。
-
+{{< note >}}
+如果你已在本地安装 [Minikube](https://minikube.sigs.k8s.io/docs/start/)，也可以按照本教程操作。
 {{< /note >}}
 
 
-
 ## {{% heading "objectives" %}}
 
-
 <!--
-* Deploy a hello world application to Minikube.
+* Deploy a sample application to Minikube.
 * Run the app.
 * View application logs.
 -->
-* 将 "Hello World" 应用程序部署到 Minikube。
+* 将一个示例应用部署到 Minikube。
 * 运行应用程序。
 * 查看应用日志
 
-
-
 ## {{% heading "prerequisites" %}}
 
 
 <!--
-This tutorial provides a container image built from the following files:
+This tutorial provides a container image that uses NGINX to echo back all the requests.
 -->
-本教程提供了从以下文件构建的容器镜像：
-
-{{< codenew language="js" file="minikube/server.js" >}}
-
-{{< codenew language="conf" file="minikube/Dockerfile" >}}
-
-<!--
-For more information on the `docker build` command, read the [Docker documentation](https://docs.docker.com/engine/reference/commandline/build/).
--->
-有关 `docker build` 命令的更多信息，请参阅 [Docker 文档](https://docs.docker.com/engine/reference/commandline/build/)。
-
-
+本教程提供了容器镜像，使用 NGINX 来对所有请求做出回应：
 
 <!-- lessoncontent -->
 
@@ -92,25 +75,27 @@ For more information on the `docker build` command, read the [Docker documentati
 
 1. 点击 **启动终端**
 
-    {{< kat-button >}}
+   {{< kat-button >}}
 
-    {{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}}
+   <!-- If you installed Minikube locally, run `minikube start`.-->
+   {{< note >}}
+   如果你在本地安装了 Minikube，运行 `minikube start`。 
+   {{< /note >}}
 
 <!--
 2. Open the Kubernetes dashboard in a browser:
 -->
-2. 在浏览器中打开 Kubernetes dashboard：
+2. 在浏览器中打开 Kubernetes 仪表板（Dashboard）：
 
-    ```shell
-    minikube dashboard
-    ```
+   ```shell
+   minikube dashboard
+   ```
 
 <!--
 3. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click **Select port to view on Host 1**.
 
 4. Katacoda environment only: Type `30000`, and then click **Display Port**.
 -->
-
 3. 仅限 Katacoda 环境：在终端窗口的顶部，单击加号，然后单击 **选择要在主机 1 上查看的端口**。
 
 4. 仅限 Katacoda 环境：输入“30000”，然后单击 **显示端口**。
@@ -129,18 +114,22 @@ recommended way to manage the creation and scaling of Pods.
 
 ## 创建 Deployment
 
-Kubernetes [*Pod*](/zh/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/zh/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。
+Kubernetes [*Pod*](/zh/docs/concepts/workloads/pods/pod/) 是由一个或多个
+为了管理和联网而绑定在一起的容器构成的组。 本教程中的 Pod 只有一个容器。
+Kubernetes [*Deployment*](/zh/docs/concepts/workloads/controllers/deployment/)
+检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。
+Deployment 是管理 Pod 创建和扩展的推荐方法。
 
 <!--
 1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
 Pod runs a Container based on the provided Docker image.
 -->
+1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker
+   镜像运行 Container。
 
-1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker 镜像运行 Container。
-
-    ```shell
-    kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
-    ```
+   ```shell
+   kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
+   ```
 
 <!--
 2. View the Deployment:
@@ -148,66 +137,66 @@ Pod runs a Container based on the provided Docker image.
 
 2. 查看 Deployment：
 
-    ```shell
-    kubectl get deployments
-    ```
+   ```shell
+   kubectl get deployments
+   ```
 
-<!--
-    The output is similar to:
--->
+   <!--
+   The output is similar to:
+   -->
 
-    输出结果类似于这样：
+   输出结果类似于这样：
 
-    ```
-    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
-    hello-node   1/1     1            1           1m
-    ```
+   ```
+   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+   hello-node   1/1     1            1           1m
+   ```
 
 <!--
 3. View the Pod:
 -->
-
 3. 查看 Pod：
 
-    ```shell
-    kubectl get pods
-    ```
+   ```shell
+   kubectl get pods
+   ```
 
-<!--
-    The output is similar to:
--->
+   <!--
+   The output is similar to:
+   -->
 
-    输出结果类似于这样：
+   输出结果类似于这样：
 
-    ```
-    NAME                          READY     STATUS    RESTARTS   AGE
-    hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
-    ```
+   ```
+   NAME                          READY     STATUS    RESTARTS   AGE
+   hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
+   ```
 
 <!--
 4. View cluster events:
 -->
-
 4. 查看集群事件：
 
-    ```shell
-    kubectl get events
-    ```
+   ```shell
+   kubectl get events
+   ```
 
 <!--
 5. View the `kubectl` configuration:
 -->
-
 5. 查看 `kubectl` 配置：
 
-    ```shell
-    kubectl config view
-    ```
+   ```shell
+   kubectl config view
+   ```
 
 <!--
-    {{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
+For more information about `kubectl`commands, see the
+[kubectl overview](/docs/user-guide/kubectl-overview/).
 -->
-   {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/user-guide/kubectl-overview/)。{{< /note >}}
+{{< note >}}
+有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/user-guide/kubectl-overview/)。
+{{< /note >}}
 
 <!--
 ## Create a Service
@@ -217,62 +206,65 @@ Kubernetes cluster. To make the `hello-node` Container accessible from outside t
 Kubernetes virtual network, you have to expose the Pod as a
 Kubernetes [*Service*](/docs/concepts/services-networking/service/).
 -->
-
 ## 创建 Service
 
-默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。要使得 `hello-node` 容器可以从 Kubernetes 虚拟网络的外部访问，您必须将 Pod 暴露为 Kubernetes [*Service*](/zh/docs/concepts/services-networking/service/)。
+默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。
+要使得 `hello-node` 容器可以从 Kubernetes 虚拟网络的外部访问，你必须将 Pod
+暴露为 Kubernetes [*Service*](/zh/docs/concepts/services-networking/service/)。
 
 <!--
 1. Expose the Pod to the public internet using the `kubectl expose` command:
 -->
-
 1. 使用 `kubectl expose` 命令将 Pod 暴露给公网：
 
-    ```shell
-    kubectl expose deployment hello-node --type=LoadBalancer --port=8080
-    ```
+   ```shell
+   kubectl expose deployment hello-node --type=LoadBalancer --port=8080
+   ```
 
-    The `--type=LoadBalancer` flag indicates that you want to expose your Service
-    outside of the cluster.
+   <!--
+   The `-type=LoadBalancer` flag indicates that you want to expose your Service
+   outside of the cluster.
+   -->
+   这里的 `--type=LoadBalancer` 标志表明你希望将你的 Service 暴露到集群外部。
 
 <!--
 2. View the Service you just created:
 -->
+2. 查看你刚刚创建的 Service：
 
-2. 查看您刚刚创建的服务:
+   ```shell
+   kubectl get services
+   ```
 
-    ```shell
-    kubectl get services
-    ```
+   <!--
+   The output is similar to:
+   -->
 
-<!--
-    The output is similar to:
--->
+   输出结果类似于这样:
 
-    输出结果类似于这样:
+   ```
+   NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+   hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
+   kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
+   ```
 
-    ```
-    NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
-    hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
-    kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
-    ```
-
-<!--
-    On cloud providers that support load balancers,
-    an external IP address would be provisioned to access the Service. On Minikube,
-    the `LoadBalancer` type makes the Service accessible through the `minikube service`
-    command.
--->
-   在支持负载均衡器的云服务提供商上，将提供一个外部 IP 来访问该服务。在 Minikube 上，`LoadBalancer` 使得服务可以通过命令 `minikube service` 访问。
+   <!--
+   On cloud providers that support load balancers,
+   an external IP address would be provisioned to access the Service. On Minikube,
+   the `LoadBalancer` type makes the Service accessible through the `minikube service`
+   command.
+   -->
+   对于支持负载均衡器的云服务平台而言，平台将提供一个外部 IP 来访问该服务。
+   在 Minikube 上，`LoadBalancer` 使得服务可以通过命令 `minikube service` 访问。
 
 <!--
 3. Run the following command:
 -->
 3. 运行下面的命令：
 
-    ```shell
-    minikube service hello-node
-    ```
+   ```shell
+   minikube service hello-node
+   ```
 
 <!--
 4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**.
@@ -282,11 +274,14 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
 <!--
 5. Katacoda environment only: Note the 5 digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`.
 
-    This opens up a browser window that serves your app and shows the "Hello World" message.
+    This opens up a browser window that serves your app and shows the app's response.
 -->
-5. 仅限 Katacoda 环境：请注意在 service 输出中与 `8080` 对应的长度为 5 位的端口号。此端口号是随机生成的，可能与您不同。在端口号文本框中输入您自己的端口号，然后单击显示端口。如果是上面那个例子，就需要输入 `30369`。
+5. 仅限 Katacoda 环境：请注意在 service 输出中与 `8080` 对应的长度为 5 位的端口号。
+   此端口号是随机生成的，可能与你的不同。
+   在端口号文本框中输入你自己的端口号，然后单击显示端口。
+   对应于上面的例子，需要输入 `30369`。
 
-    这将打开一个浏览器窗口，为您的应用程序提供服务并显示 “Hello World” 消息。
+   这将打开一个浏览器窗口，为你的应用程序提供服务并显示应用的响应。
 
 <!--
 ## Enable addons
@@ -297,127 +292,122 @@ Minikube has a set of built-in {{< glossary_tooltip text="addons" term_id="addon
 -->
 ## 启用插件
 
-Minikube 有一组内置的 {{< glossary_tooltip text="插件" term_id="addons" >}}，可以在本地 Kubernetes 环境中启用、禁用和打开。
+Minikube 有一组内置的 {{< glossary_tooltip text="插件" term_id="addons" >}}，
+可以在本地 Kubernetes 环境中启用、禁用和打开。
 
 1. 列出当前支持的插件：
 
-    ```shell
-    minikube addons list
-    ```
+   ```shell
+   minikube addons list
+   ```
 
-<!--
-    The output is similar to:
--->
+   <!--
+   The output is similar to:
+   -->
+   输出结果类似于这样：
 
-    输出结果类似于这样：
-
-    ```
-    addon-manager: enabled
-    dashboard: enabled
-    default-storageclass: enabled
-    efk: disabled
-    freshpod: disabled
-    gvisor: disabled
-    helm-tiller: disabled
-    ingress: disabled
-    ingress-dns: disabled
-    logviewer: disabled
-    metrics-server: disabled
-    nvidia-driver-installer: disabled
-    nvidia-gpu-device-plugin: disabled
-    registry: disabled
-    registry-creds: disabled
-    storage-provisioner: enabled
-    storage-provisioner-gluster: disabled
-    ```
+   ```
+   addon-manager: enabled
+   dashboard: enabled
+   default-storageclass: enabled
+   efk: disabled
+   freshpod: disabled
+   gvisor: disabled
+   helm-tiller: disabled
+   ingress: disabled
+   ingress-dns: disabled
+   logviewer: disabled
+   metrics-server: disabled
+   nvidia-driver-installer: disabled
+   nvidia-gpu-device-plugin: disabled
+   registry: disabled
+   registry-creds: disabled
+   storage-provisioner: enabled
+   storage-provisioner-gluster: disabled
+   ```
 
 <!--
 2. Enable an addon, for example, `metrics-server`:
 -->
-
 2. 启用插件，例如 `metrics-server`：
 
-    ```shell
-    minikube addons enable metrics-server
-    ```
+   ```shell
+   minikube addons enable metrics-server
+   ```
 
-<!--
-    The output is similar to:
--->
+   <!--
+   The output is similar to:
+   -->
 
-    输出结果类似于这样：
+   输出结果类似于这样：
 
-    ```
-    metrics-server was successfully enabled
-    ```
+   ```
+   metrics-server was successfully enabled
+   ```
 
 <!--
 3. View the Pod and Service you just created:
 -->
-
 3. 查看刚才创建的 Pod 和 Service：
 
-    ```shell
-    kubectl get pod,svc -n kube-system
-    ```
+   ```shell
+   kubectl get pod,svc -n kube-system
+   ```
 
-<!--
-    The output is similar to:
--->
+   <!--
+   The output is similar to:
+   -->
 
-    输出结果类似于这样：
+   输出结果类似于这样：
 
-    ```
-    NAME                                        READY     STATUS    RESTARTS   AGE
-    pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
-    pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
-    pod/metrics-server-67fb648c5                1/1       Running   0          26s
-    pod/etcd-minikube                           1/1       Running   0          34m
-    pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
-    pod/kube-addon-manager-minikube             1/1       Running   0          34m
-    pod/kube-apiserver-minikube                 1/1       Running   0          34m
-    pod/kube-controller-manager-minikube        1/1       Running   0          34m
-    pod/kube-proxy-rnlps                        1/1       Running   0          34m
-    pod/kube-scheduler-minikube                 1/1       Running   0          34m
-    pod/storage-provisioner                     1/1       Running   0          34m
+   ```
+   NAME                                        READY     STATUS    RESTARTS   AGE
+   pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
+   pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
+   pod/metrics-server-67fb648c5                1/1       Running   0          26s
+   pod/etcd-minikube                           1/1       Running   0          34m
+   pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
+   pod/kube-addon-manager-minikube             1/1       Running   0          34m
+   pod/kube-apiserver-minikube                 1/1       Running   0          34m
+   pod/kube-controller-manager-minikube        1/1       Running   0          34m
+   pod/kube-proxy-rnlps                        1/1       Running   0          34m
+   pod/kube-scheduler-minikube                 1/1       Running   0          34m
+   pod/storage-provisioner                     1/1       Running   0          34m
 
-    NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-    service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
-    service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
-    service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
-    service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
-    ```
+   NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
+   service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
+   service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
+   service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
+   service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
+   ```
 
 <!--
 4. Disable `metrics-server`:
 -->
-
 4. 禁用 `metrics-server`：
 
+   ```shell
+   minikube addons disable metrics-server
+   ```
 
-    ```shell
-    minikube addons disable metrics-server
-    ```
+   <!--
+   The output is similar to:
+   -->
 
-<!--
-    The output is similar to:
--->
+   输出结果类似于这样：
 
-    输出结果类似于这样：
-
-    ```
-    metrics-server was successfully disabled
-    ```
+   ```
+   metrics-server was successfully disabled
+   ```
 
 <!--
 ## Clean up
 
 Now you can clean up the resources you created in your cluster:
 -->
-
 ## 清理
 
-现在可以清理您在集群中创建的资源：
+现在可以清理你在集群中创建的资源：
 
 ```shell
 kubectl delete service hello-node
@@ -427,8 +417,7 @@ kubectl delete deployment hello-node
 <!--
 Optionally, stop the Minikube virtual machine (VM):
 -->
-
-可选的，停止 Minikube 虚拟机（VM）：
+可选地，停止 Minikube 虚拟机（VM）：
 
 ```shell
 minikube stop
@@ -437,25 +426,20 @@ minikube stop
 <!--
 Optionally, delete the Minikube VM:
 -->
-
-可选的，删除 Minikube 虚拟机（VM）：
+可选地，删除 Minikube 虚拟机（VM）：
 
 ```shell
 minikube delete
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
 * Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/).
 * Learn more about [Service objects](/docs/concepts/services-networking/service/).
 -->
 * 进一步了解 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)。
-* 学习更多关于 [部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
-* 学习更多关于 [Service 对象](/zh/docs/concepts/services-networking/service/)。
-
+* 进一步了解[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
+* 进一步了解 [Service 对象](/zh/docs/concepts/services-networking/service/)。
 
diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index 01dea341b8..2231587445 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -33,7 +33,7 @@ weight: 20
                 要与终端交互，请使用桌面/平板
             
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
         </div>
         <div class="row">
             <div class="col-md-12">
diff --git a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
index 43b0c79331..7147587d51 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
@@ -29,7 +29,7 @@ weight: 10
             <div class="col-md-8">
                 <h3> Kubernetes 集群</h3>
                 <p>
-                <b> Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。</b> Kubernetes 中的抽象允许您将容器化的应用部署到群集，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。<b> Kubernetes 以更高效的方式跨群集自动分发和调度应用容器。</b> Kubernetes 是一个开源平台，并且可应用于生产环境。
+                <b> Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。</b> Kubernetes 中的抽象允许您将容器化的应用部署到集群，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。<b> Kubernetes 以更高效的方式跨集群自动分发和调度应用容器。</b> Kubernetes 是一个开源平台，并且可应用于生产环境。
                 </p>
                 <p>一个 Kubernetes 集群包含两种类型的资源:
                     <ul>
@@ -84,9 +84,9 @@ weight: 10
 
         <div class="row">
             <div class="col-md-8">
-                <p>在 Kubernetes 上部署应用时，您告诉 Master 启动应用容器。 Master 就编排容器在群集的 Node 上运行。<b> Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。</b>终端用户也可以使用 Kubernetes API 与集群交互。</p>
+                <p>在 Kubernetes 上部署应用时，您告诉 Master 启动应用容器。 Master 就编排容器在集群的 Node 上运行。<b> Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。</b>终端用户也可以使用 Kubernetes API 与集群交互。</p>
 
-                <p> Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。您可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux ， macOS 和 Windows 系统。Minikube CLI 提供了用于引导群集工作的多种操作，包括启动、停止、查看状态和删除。在本教程里，您可以使用预装有 Minikube 的在线终端进行体验。</p>
+                <p> Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。您可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux ， macOS 和 Windows 系统。Minikube CLI 提供了用于引导集群工作的多种操作，包括启动、停止、查看状态和删除。在本教程里，您可以使用预装有 Minikube 的在线终端进行体验。</p>
 
                 <p>既然您已经知道 Kubernetes 是什么，让我们转到在线教程并启动我们的第一个 Kubernetes 集群！</p>
 
diff --git a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 4adb6a44a2..8b6693beae 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -26,7 +26,7 @@ weight: 20
                 要与终端进行交互，请使用桌面/平板电脑版本
             </div>
 
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
 
         </div>
diff --git a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
index d846c9b40d..550ccb488d 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
@@ -91,7 +91,7 @@ weight: 10
             <div class="col-md-8">
 
                 <!-- <p>You can create and manage a Deployment by using the Kubernetes command line interface, <b>Kubectl</b>. Kubectl uses the Kubernetes API to interact with the cluster. In this module, you'll learn the most common Kubectl commands needed to create Deployments that run your applications on a Kubernetes cluster.</p> -->
-                <p>您可以使用 Kubernetes 命令行界面创建和管理 Deployment，<b>Kubectl</b>.Kubectl 使用 Kubernetes API 与集群进行交互。在本单元中，您将学习创建在 Kubernetes 集群上运行应用程序的 Deployment 所需的最常见的 Kubectl 命令。</p>
+                <p>您可以使用 Kubernetes 命令行界面 <b>Kubectl</b> 创建和管理 Deployment。Kubectl 使用 Kubernetes API 与集群进行交互。在本单元中，您将学习创建在 Kubernetes 集群上运行应用程序的 Deployment 所需的最常见的 Kubectl 命令。</p>
 
                 <!-- <p>When you create a Deployment, you'll need to specify the container image for your application and the number of replicas that you want to run. You can change that information later by updating your Deployment; Modules <a href="/docs/tutorials/kubernetes-basics/scale-intro/">5</a> and <a href="/docs/tutorials/kubernetes-basics/update-intro/">6</a> of the bootcamp discuss how you can scale and update your Deployments.</p> -->
                 <p>创建 Deployment 时，您需要指定应用程序的容器映像以及要运行的副本数。您可以稍后通过更新 Deployment 来更改该信息; 模块 <a href="/zh/docs/tutorials/kubernetes-basics/scale-intro/">5</a> 和 <a href="/zh/docs/tutorials/kubernetes-basics/update-intro/">6</a> 讨论了如何扩展和更新 Deployments。</p>
@@ -133,4 +133,4 @@ weight: 10
 </div>
 
 </body>
-</html>
\ No newline at end of file
+</html>
diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
index 32f52502b4..3d94bda16f 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
@@ -37,7 +37,7 @@ weight: 20
                 要与终端交互，请使用桌面/平板 版本
             </div>
             
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html
index eca0105bbe..d07d155926 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html
@@ -41,9 +41,9 @@ weight: 10
 -->
         <h2>Kubernetes Pods</h2>
 <!--
-        <p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
+        <p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources for those containers. Those resources include:</p>
 -->
-        <p>在模块 <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>创建 Deployment 时, Kubernetes 添加了一个 <b>Pod</b> 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker 或 rkt ），以及这些容器的一些共享资源。这些资源包括:</p>
+        <p>在模块 <a href="/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>创建 Deployment 时, Kubernetes 添加了一个 <b>Pod</b> 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。这些资源包括:</p>
 <!--
         <ul>
           <li>Shared storage, as Volumes</li>
@@ -84,11 +84,11 @@ weight: 10
         <div class="content__box content__box_fill">
 <!--
           <p><i>
-              A Pod is a group of one or more application containers (such as Docker or rkt) and includes shared storage (volumes), IP address and information about how to run them.
+              A Pod is a group of one or more application containers (such as Docker) and includes shared storage (volumes), IP address and information about how to run them.
             </i></p>
 -->
           <p><i>
-              Pod 是一组一个或多个应用程序容器（例如 Docker 或 rkt ），包括共享存储（卷), IP 地址和有关如何运行它们的信息。
+              Pod 是一组一个或多个应用程序容器（例如 Docker），包括共享存储（卷), IP 地址和有关如何运行它们的信息。
             </i></p>
         </div>
       </div>
@@ -120,7 +120,7 @@ weight: 10
         <p>Every Kubernetes Node runs at least:</p>
         <ul>
           <li>Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.</li>
-          <li>A container runtime (like Docker, rkt) responsible for pulling the container image from a registry, unpacking the container, and running the application.</li>
+          <li>A container runtime (like Docker) responsible for pulling the container image from a registry, unpacking the container, and running the application.</li>
         </ul>
 -->
         <h2>工作节点</h2>
@@ -129,7 +129,7 @@ weight: 10
         <p>每个 Kubernetes 工作节点至少运行:</p>
         <ul>
           <li>Kubelet，负责 Kubernetes 主节点和工作节点之间通信的过程; 它管理 Pod 和机器上运行的容器。</li>
-          <li>容器运行时（如 Docker ，rkt ）负责从仓库中提取容器镜像，解压缩容器以及运行应用程序。</li>
+          <li>容器运行时（如 Docker）负责从仓库中提取容器镜像，解压缩容器以及运行应用程序。</li>
         </ul>
       </div>
       <div class="col-md-4">
@@ -169,7 +169,7 @@ weight: 10
 <!--
         <p>In Module <a href="/docs/tutorials/kubernetes-basics/deploy/deploy-intro/">2</a>, you used Kubectl command-line interface. You'll continue to use it in Module 3 to get information about deployed applications and their environments. The most common operations can be done with the following kubectl commands:</p>
 -->
-        <p>在模块 <a href="/docs/tutorials/kubernetes-basics/deploy/deploy-intro/">2</a>,您使用了 Kubectl 命令行界面。 您将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：</p>
+        <p>在模块 <a href="/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>,您使用了 Kubectl 命令行界面。 您将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：</p>
 <!--
         <ul>
           <li><b>kubectl get</b> - list resources</li>
diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
index 55297633a7..bf20a9e4f3 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
@@ -33,7 +33,7 @@ weight: 20
                 要与终端交互，请使用台式机/平板电脑
                 
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index 3806ef7f69..307260631e 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -35,7 +35,7 @@ weight: 10
         <h3>Kubernetes Service 总览</h3>
 
 <!--        <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>-->
-        <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/pod-overview/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p>
+        <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p>
 
 <!--        <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>-->
         <p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么您可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p>
diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
index d612cdfce4..9f29959853 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
@@ -29,7 +29,7 @@ weight: 20
                 -->
                 与终端交互，请使用桌面/平板电脑版本
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
index 73151bdcb8..ff6094eada 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
@@ -33,7 +33,7 @@ weight: 10
 						<!-- <p>In the previous modules we created a <a href="/docs/concepts/workloads/controllers/deployment/"> Deployment</a>,
 							and then exposed it publicly via a <a href="/docs/concepts/services-networking/service/">Service</a>.
 							The Deployment created only one Pod for running our application.  When traffic increases, we will need to scale the application to keep up with  user demand.</p> -->
-						<p>在之前的模块中，我们创建了一个 <a href="/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="/docs/user-guide/services/">Service</a>让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。</p>
+						<p>在之前的模块中，我们创建了一个 <a href="/zh/docs/concepts/workloads/controllers/deployment/"> Deployment</a>，然后通过 <a href="/zh/docs/concepts/services-networking/service/">Service</a>让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。</p>
 
 						<!-- <p><b>Scaling</b> is accomplished by changing the number of replicas in a Deployment</p> -->
 						<p><b>扩缩</b> 是通过改变 Deployment 中的副本数量来实现的。</p>
@@ -99,7 +99,7 @@ weight: 10
 
                 <!-- <p>Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling in will reduce the number of Pods to the new desired state. Kubernetes also supports
 									<a href="/docs/user-guide/horizontal-pod-autoscaling/">autoscaling</a> of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.</p> -->
-								<p>扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的<a href="/docs/user-guide/horizontal-pod-autoscaling/">自动缩放</a>，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。</p>
+								<p>扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的<a href="/zh/docs/tasks/run-application/horizontal-pod-autoscale/">自动缩放</a>，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。</p>
 
 								<!-- <p>Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment.
 									Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.</p> -->
diff --git a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html
index 0f9ea050c3..777d7515ad 100644
--- a/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html
+++ b/content/zh/docs/tutorials/kubernetes-basics/update/update-interactive.html
@@ -27,7 +27,7 @@ weight: 20
             <div class="katacoda__alert">
                 要与终端交互，请使用桌面/平板电脑版本
             </div>
-            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
             </div>
         </div>
         <div class="row">
diff --git a/content/zh/docs/tutorials/online-training/_index.md b/content/zh/docs/tutorials/online-training/_index.md
deleted file mode 100644
index 924cc1366a..0000000000
--- a/content/zh/docs/tutorials/online-training/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
-title: "在线培训课程"
-weight: 20
----
diff --git a/content/zh/docs/tutorials/online-training/overview.md b/content/zh/docs/tutorials/online-training/overview.md
deleted file mode 100644
index 055bd6d1c3..0000000000
--- a/content/zh/docs/tutorials/online-training/overview.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-title: Kubernetes 在线培训概述
-content_type: concept
----
-<!--
----
-title: Overview of Kubernetes Online Training
-content_type: concept
----
--->
-
-<!-- overview -->
-
-<!--
-Here are some of the sites that offer online training for Kubernetes:
--->
-以下是提供 Kubernetes 在线培训的一些网站:
-
-
-
-<!-- body -->
-
-<!--
-* [AIOps Essentials (Autoscaling Kubernetes with Prometheus Metrics) with Hands-On Labs (Linux Academy)](https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
--->
-* [AIOps Essentials (使用 Prometheus 度量标准自动缩放 Kubernetes) 和动手实验室 (Linux 学院)]
- (https://linuxacademy.com/devops/training/course/name/using-machine-learning-to-scale-kubernetes-clusters)
-
-<!--
-* [Amazon EKS Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
--->
-* [带有动手实验室的 Amazon EKS 深入研究(Linux 学院)] (https://linuxacademy.com/amazon-web-services/training/course/name/amazon-eks-deep-dive)
-
-<!--
-* [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
--->
-* [具有动手实验和实践考试的 Cloud Native 认证 Kubernetes 管理员 (CKA)(Linux 学院)]
-(https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka)
-
-<!--
-* [Certified Kubernetes Administrator Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
--->
-* [带有实践测试的认证 Kubernetes 管理员准备课程 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests)
-
-<!--
-* [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
--->
-* [经过实践实验室和实践考试认证的 Kubernetes 应用程序开发人员(CKAD) (Linux 学院)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/)
-
-<!--
-* [Certified Kubernetes Application Developer Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
--->
-* [经过认证的带有实践测试的 Kubernetes 应用程序开发人员准备课程 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course)
-
-<!--
-*[Getting Started with Google Kubernetes Engine (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
--->
-* [Google Kubernetes 引擎入门(Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
-
-<!--
-* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
--->
-* [Kubernetes 入门 (Pluralsight)]
-(https://www.pluralsight.com/courses/getting-started-kubernetes)
-
-<!--
-* [Getting Started with Kubernetes Clusters on OCI Oracle Kubernetes Engine (OKE) (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
--->
-* [OCI Oracle Kubernetes 引擎(OKE)上的 Kubernetes集群入门 (学习库)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256)
-
-<!--
-* [Google Kubernetes Engine Deep Dive (Linux Academy)] (https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
--->
-* [Google Kubernetes 引擎深度学习 (Linux 学院)]
-(https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive)
-
-<!--
-* [Helm Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
--->
-* [通过动手实验室进行深度学习(Linux 学院)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1)
-
-<!--
-* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
--->
-* [Kubernetes 的动手入门 (Instruqt)]
-(https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
-
-<!--
-* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
--->
-* [IBM Cloud: 使用 Kubernetes 部署微服务 (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
-
-<!--
-* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
--->
-* [Kubernetes (edX) 简介](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
-
-<!--
-* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
--->
-* [带动手实验室的 Kubernetes Essentials (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)
-
-<!--
-* [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
--->
-* [通过动手实验室为绝对初学者提供 Kubernetes (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
-
-<!--
-* [Kubernetes Fundamentals (LFS258) (The Linux Foundation)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
--->
-* [Kubernetes 基础 (LFS258) (Linux 基金会)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
-
-<!--
-* [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
--->
-* [Kubernetes 动手实验室快速入门 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
-
-<!--
-* [Kubernetes the Hard Way with Hands-On Labs (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
--->
-* [Kubernetes 通过动手实验室解决难题 (Linux 学院)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
-
-<!--
-* [Kubernetes Security with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
--->
-* [通过动手实验室实现 Kubernetes 安全性(Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-security)
-
-<!--
-* [Launch Your First OpenShift Operator with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
--->
-* [通过动手实验室启动您的第一个 OpenShift 操作 (Linux 学院)] (https://linuxacademy.com/containers/training/course/name/red-hat-open-shift)
-
-<!--
-* [Learn Kubernetes by Doing - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
--->
-* [边干边学 Kubernetes  - 100% 动手体验 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing)
-
-<!--
-* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
--->
-* [使用交互式动手场景学习 Kubernetes (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
-
-<!--
-* [Microservice Applications in Kubernetes - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
--->
-* [Kubernetes中的微服务应用程序 - 100% 动手体验 (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing)
-
-<!--
-* [Monitoring Kubernetes With Prometheus with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
--->
-* [通过动手实验室使用 Prometheus 监控 Kubernetes (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus)
-
-<!--
-* [Service Mesh with Istio with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
--->
-* [带动手实验室的 Istio 服务网络 (Linux 学院)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1)
-
-<!--
-* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
--->
-* [使用 Kubernetes 的可扩展微服务(Udacity)]
-(https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-
-<!--
-* [Self-paced Kubernetes online course (Learnk8s Academy)](https://learnk8s.io/academy)
--->
-* [自定进度的 Kubernetes 在线课程 (Learnk8s 学院)]
-(https://learnk8s.io/academy)
-
-
diff --git a/content/zh/docs/tutorials/stateful-application/zookeeper.md b/content/zh/docs/tutorials/stateful-application/zookeeper.md
index 25218ecd84..4d95d69a52 100644
--- a/content/zh/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/zh/docs/tutorials/stateful-application/zookeeper.md
@@ -14,96 +14,159 @@ content_type: tutorial
 
 <!-- overview -->
 
-本教程展示了在 Kubernetes 上使用 [PodDisruptionBudgets](/zh/docs/admin/disruptions/#specifying-a-poddisruptionbudget) 和 [PodAntiAffinity](/zh/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 特性运行 [Apache Zookeeper](https://zookeeper.apache.org)。
+<!--
+This tutorial demonstrates running [Apache Zookeeper](https://zookeeper.apache.org) on
+Kubernetes using [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
+[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget),
+and [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).
+-->
 
+本教程展示了在 Kubernetes 上使用 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)，[PodDisruptionBudgets](/zh/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget) 和 [PodAntiAffinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#亲和与反亲和) 特性运行 [Apache Zookeeper](https://zookeeper.apache.org)。
 
 ## {{% heading "prerequisites" %}}
 
+<!--
+Before starting this tutorial, you should be familiar with the following
+Kubernetes concepts.
+-->
 
 在开始本教程前，你应该熟悉以下 Kubernetes 概念。
 
-* [Pods](/zh/docs/user-guide/pods/single-container/)
-* [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/)
-* [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services)
-* [PersistentVolumes](/zh/docs/concepts/storage/volumes/)
-* [PersistentVolume Provisioning](http://releases.k8s.io/{{< param "githubbranch" >}}/examples/persistent-volume-provisioning/)
-* [ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
-* [StatefulSets](/zh/docs/concepts/abstractions/controllers/statefulsets/)
-* [PodDisruptionBudgets](/zh/docs/admin/disruptions/#specifying-a-poddisruptionbudget)
-* [PodAntiAffinity](/zh/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
-* [kubectl CLI](/zh/docs/user-guide/kubectl)
+-   [Pods](/zh/docs/concepts/workloads/pods/)
+-   [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/)
+-   [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services)
+-   [PersistentVolumes](/zh/docs/concepts/storage/volumes/)
+-   [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+-   [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)
+-   [PodDisruptionBudgets](/zh/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
+-   [PodAntiAffinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#亲和与反亲和)
+-   [kubectl CLI](/zh/docs/reference/kubectl/kubectl/)
 
+<!--
+You will require a cluster with at least four nodes, and each node requires at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and drain the cluster's nodes. **This means that the cluster will terminate and evict all Pods on its nodes, and the nodes will temporarily become unschedulable.** You should use a dedicated cluster for this tutorial, or you should ensure that the disruption you cause will not interfere with other tenants.
 
+This tutorial assumes that you have configured your cluster to dynamically provision
+PersistentVolumes. If your cluster is not configured to do so, you
+will have to manually provision three 20 GiB volumes before starting this
+tutorial.
+-->
 
 你需要一个至少包含四个节点的集群，每个节点至少 2 CPUs 和  4 GiB 内存。在本教程中你将会 cordon 和 drain 集群的节点。**这意味着集群节点上所有的 Pods 将会被终止并移除**。**这些节点也会暂时变为不可调度**。在本教程中你应该使用一个独占的集群，或者保证你造成的干扰不会影响其它租户。
 
-
 本教程假设你的集群配置为动态的提供 PersistentVolumes。如果你的集群没有配置成这样，在开始本教程前，你需要手动准备三个 20 GiB 的卷。
 
 
 ## {{% heading "objectives" %}}
 
+<!--
+After this tutorial, you will know the following.
+
+-   How to deploy a ZooKeeper ensemble using StatefulSet.
+-   How to consistently configure the ensemble.
+-   How to spread the deployment of ZooKeeper servers in the ensemble.
+-   How to use PodDisruptionBudgets to ensure service availability during planned maintenance.
+-->
 
 在学习本教程后，你将熟悉下列内容。
 
 * 如何使用 StatefulSet 部署一个 ZooKeeper ensemble。
-* 如何使用 ConfigMaps 一致性配置 ensemble。
-* 如何在 ensemble 中 分布 ZooKeeper 服务的部署。
+* 如何一致性配置 ensemble。
+* 如何在 ensemble 中 分布 ZooKeeper 服务器的部署。
 * 如何在计划维护中使用 PodDisruptionBudgets 确保服务可用性。
 
 
 <!-- lessoncontent -->
 
+<!-- 
+### ZooKeeper Basics
+
+[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) is a
+distributed, open-source coordination service for distributed applications.
+ZooKeeper allows you to read, write, and observe updates to data. Data are
+organized in a file system like hierarchy and replicated to all ZooKeeper
+servers in the ensemble (a set of ZooKeeper servers). All operations on data
+are atomic and sequentially consistent. ZooKeeper ensures this by using the
+[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf)
+consensus protocol to replicate a state machine across all servers in the ensemble.
+
+The ensemble uses the Zab protocol to elect a leader, and the ensemble cannot write data until that election is complete. Once complete, the ensemble uses Zab to ensure that it replicates all writes to a quorum before it acknowledges and makes them visible to clients. Without respect to weighted quorums, a quorum is a majority component of the ensemble containing the current leader. For instance, if the ensemble has three servers, a component that contains the leader and one other server constitutes a quorum. If the ensemble can not achieve a quorum, the ensemble cannot write data.
+
+ZooKeeper servers keep their entire state machine in memory, and write every mutation to a durable WAL (Write Ahead Log) on storage media. When a server crashes, it can recover its previous state by replaying the WAL. To prevent the WAL from growing without bound, ZooKeeper servers will periodically snapshot them in memory state to storage media. These snapshots can be loaded directly into memory, and all WAL entries that preceded the snapshot may be discarded.
+-->
 
 ### ZooKeeper 基础
 
+[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) 是一个分布式的开源协调服务，用于分布式系统。ZooKeeper 允许你读取、写入数据和发现数据更新。数据按层次结构组织在文件系统中，并复制到 ensemble（一个 ZooKeeper 服务器的集合） 中所有的 ZooKeeper 服务器。对数据的所有操作都是原子的和顺序一致的。ZooKeeper 通过 [Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) 一致性协议在 ensemble 的所有服务器之间复制一个状态机来确保这个特性。
 
-[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) 是一个分布式的开源协调服务，用于分布式系统。ZooKeeper 允许你读取、写入数据和发现数据更新。数据按层次结构组织在文件系统中，并复制到 ensemble（一个 ZooKeeper 服务的集合） 中所有的 ZooKeeper 服务。对数据的所有操作都是原子的和顺序一致的。ZooKeeper 通过 [Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) 一致性协议在 ensemble 的所有服务之间复制一个状态机来确保这个特性。
+ensemble 使用 Zab 协议选举一个 leader，在选举出 leader 前不能写入数据。一旦选举出了 leader，ensemble 使用 Zab 保证所有写入被复制到一个 quorum，然后这些写入操作才会被确认并对客户端可用。如果没有遵照加权 quorums，一个 quorum 表示包含当前 leader 的 ensemble 的多数成员。例如，如果 ensemble 有3个服务器，一个包含 leader 的成员和另一个服务器就组成了一个 quorum。如果 ensemble 不能达成一个 quorum，数据将不能被写入。
 
+ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被写入一个在存储介质上的持久 WAL（Write Ahead Log）。当一个服务器故障时，它能够通过回放 WAL 恢复之前的状态。为了防止 WAL 无限制的增长，ZooKeeper 服务器会定期的将内存状态快照保存到存储介质。这些快照能够直接加载到内存中，所有在这个快照之前的 WAL 条目都可以被安全的丢弃。
 
-ensemble 使用 Zab 协议选举一个 leader，在选举出 leader 前不能写入数据。一旦选举出了 leader，ensemble 使用 Zab 保证所有写入被复制到一个 quorum，然后这些写入操作才会被确认并对客户端可用。如果没有遵照加权 quorums，一个 quorum 表示包含当前 leader 的 ensemble 的多数成员。例如，如果 ensemble 有3个服务，一个包含 leader 的成员和另一个服务就组成了一个 quorum。如果 ensemble 不能达成一个 quorum，数据将不能被写入。
-
-
-ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被写入一个在存储介质上的持久 WAL（Write Ahead Log）。当一个服务故障时，它能够通过回放 WAL 恢复之前的状态。为了防止 WAL 无限制的增长，ZooKeeper 服务会定期的将内存状态快照保存到存储介质。这些快照能够直接加载到内存中，所有在这个快照之前的 WAL 条目都可以被安全的丢弃。
+<!--
+## Creating a ZooKeeper Ensemble
 
+The manifest below contains a
+[Headless Service](/docs/concepts/services-networking/service/#headless-services),
+a [Service](/docs/concepts/services-networking/service/),
+a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets),
+and a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
+-->
 
 ## 创建一个 ZooKeeper Ensemble
 
-
 下面的清单包含一个
 [Headless Service](/zh/docs/concepts/services-networking/service/#headless-services)，
 一个 [Service](/zh/docs/concepts/services-networking/service/)，
-一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget)，
+一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)，
 和一个 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。
 
 {{< codenew file="application/zookeeper/zookeeper.yaml" >}}
 
-打开一个命令行终端，使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands/#apply)
+<!--
+Open a terminal, and use the
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) command to create the
+manifest.
+-->
+
+打开一个命令行终端，使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)
 创建这个清单。
 
 ```shell
 kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
 ```
 
+<!--
+This creates the `zk-hs` Headless Service, the `zk-cs` Service,
+the `zk-pdb` PodDisruptionBudget, and the `zk` StatefulSet.
+-->
+
 这个操作创建了 `zk-hs` Headless Service、`zk-cs` Service、`zk-pdb` PodDisruptionBudget 和 `zk` StatefulSet。
 
-```shell
+```
 service/zk-hs created
 service/zk-cs created
 poddisruptionbudget.policy/zk-pdb created
 statefulset.apps/zk created
 ```
 
-使用 [`kubectl get`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#get) 查看 StatefulSet 控制器创建的 Pods。
+<!--
+Use [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the
+StatefulSet controller create the StatefulSet's Pods.
+-->
+
+使用 [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) 查看 StatefulSet 控制器创建的 Pods。
 
 ```shell
 kubectl get pods -w -l app=zk
 ```
 
+<!--
+Once the `zk-2` Pod is Running and Ready, use `CTRL-C` to terminate kubectl.
+-->
 
 一旦  `zk-2` Pod 变成 Running 和 Ready 状态，使用 `CRTL-C` 结束 kubectl。
 
-```shell
+```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      0/1       Pending   0          0s
 zk-0      0/1       Pending   0         0s
@@ -122,45 +185,66 @@ zk-2      0/1       Running   0         19s
 zk-2      1/1       Running   0         40s
 ```
 
+<!--
+The StatefulSet controller creates three Pods, and each Pod has a container with
+a [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) server.
+-->
 
-StatefulSet 控制器创建了3个 Pods，每个 Pod 包含一个 [ZooKeeper 3.4.9](http://www-us.apache.org/dist/zookeeper/zookeeper-3.4.9/) 服务。
+StatefulSet 控制器创建了3个 Pods，每个 Pod 包含一个 [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 服务器。
 
+<!--
+### Facilitating Leader Election
+
+Because there is no terminating algorithm for electing a leader in an anonymous network, Zab requires explicit membership configuration to perform leader election. Each server in the ensemble needs to have a unique identifier, all servers need to know the global set of identifiers, and each identifier needs to be associated with a network address.
+
+Use [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to get the hostnames
+of the Pods in the `zk` StatefulSet.
+-->
 
 ### 促成 Leader 选举
 
+由于在匿名网络中没有用于选举 leader 的终止算法，Zab 要求显式的进行成员关系配置，以执行 leader 选举。Ensemble 中的每个服务器都需要具有一个独一无二的标识符，所有的服务器均需要知道标识符的全集，并且每个标识符都需要和一个网络地址相关联。
 
-由于在匿名网络中没有用于选举 leader 的终止算法，Zab 要求显式的进行成员关系配置，以执行 leader 选举。Ensemble 中的每个服务都需要具有一个独一无二的标识符，所有的服务均需要知道标识符的全集，并且每个标志都需要和一个网络地址相关联。
-
-
-使用 [`kubectl exec`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#exec) 获取 `zk` StatefulSet 中 Pods 的主机名。
+使用 [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) 获取 `zk` StatefulSet 中 Pods 的主机名。
 
 ```shell
 for i in 0 1 2; do kubectl exec zk-$i -- hostname; done
 ```
 
+<!--
+The StatefulSet controller provides each Pod with a unique hostname based on its ordinal index. The hostnames take the form of `<statefulset name>-<ordinal index>`. Because the `replicas` field of the `zk` StatefulSet is set to `3`, the Set's controller creates three Pods with their hostnames set to `zk-0`, `zk-1`, and
+`zk-2`.
+-->
 
 StatefulSet 控制器基于每个 Pod 的序号索引为它们各自提供一个唯一的主机名。主机名采用 `<statefulset name>-<ordinal index>` 的形式。由于 `zk` StatefulSet 的 `replicas` 字段设置为3，这个 Set 的控制器将创建3个 Pods，主机名为：`zk-0`、`zk-1` 和 `zk-2`。
 
-```shell
+```
 zk-0
 zk-1
 zk-2
 ```
 
+<!--
+The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and store each server's identifier in a file called `myid` in the server's data directory.
 
-ZooKeeper ensemble 中的服务使用自然数作为唯一标识符，每个服务的标识符都保存在服务的数据目录中一个名为 `myid` 的文件里。
+To examine the contents of the `myid` file for each server use the following command.
+-->
 
+ZooKeeper ensemble 中的服务器使用自然数作为唯一标识符，每个服务器的标识符都保存在服务器的数据目录中一个名为 `myid` 的文件里。
 
-检查每个服务的 `myid` 文件的内容。
+检查每个服务器的 `myid` 文件的内容。
 
 ```shell
 for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done
 ```
 
+<!--
+Because the identifiers are natural numbers and the ordinal indices are non-negative integers, you can generate an identifier by adding 1 to the ordinal.
+-->
 
 由于标识符为自然数并且序号索引是非负整数，你可以在序号上加 1 来生成一个标识符。
 
-```shell
+```
 myid zk-0
 1
 myid zk-1
@@ -169,6 +253,9 @@ myid zk-2
 3
 ```
 
+<!--
+To get the Fully Qualified Domain Name (FQDN) of each Pod in the `zk` StatefulSet use the following command.
+-->
 
 获取 `zk` StatefulSet 中每个 Pod 的 FQDN (Fully Qualified Domain Name，正式域名)。
 
@@ -176,29 +263,43 @@ myid zk-2
 for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done
 ```
 
+<!--
+The `zk-hs` Service creates a domain for all of the Pods,
+`zk-hs.default.svc.cluster.local`.
+-->
 
-`zk-headless` Service 为所有 Pods 创建了一个 domain：`zk-headless.default.svc.cluster.local`。
+`zk-hs` Service 为所有 Pods 创建了一个 domain：`zk-hs.default.svc.cluster.local`。
 
-```shell
-zk-0.zk-headless.default.svc.cluster.local
-zk-1.zk-headless.default.svc.cluster.local
-zk-2.zk-headless.default.svc.cluster.local
+```
+zk-0.zk-hs.default.svc.cluster.local
+zk-1.zk-hs.default.svc.cluster.local
+zk-2.zk-hs.default.svc.cluster.local
 ```
 
+<!--
+The A records in [Kubernetes DNS](/docs/concepts/services-networking/dns-pod-service/) resolve the FQDNs to the Pods' IP addresses. If Kubernetes reschedules the Pods, it will update the A records with the Pods' new IP addresses, but the A records names will not change.
+
+ZooKeeper stores its application configuration in a file named `zoo.cfg`. Use `kubectl exec` to view the contents of the `zoo.cfg` file in the `zk-0` Pod.
+-->
 
 [Kubernetes DNS](/zh/docs/concepts/services-networking/dns-pod-service/) 中的 A 记录将 FQDNs 解析成为 Pods 的 IP 地址。如果 Pods 被调度，这个 A 记录将会使用 Pods 的新 IP 地址更新，但 A 记录的名称不会改变。
 
-
 ZooKeeper 在一个名为 `zoo.cfg` 的文件中保存它的应用配置。使用 `kubectl exec` 在  `zk-0` Pod 中查看 `zoo.cfg` 文件的内容。
 
-```
+```shell
 kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg
 ```
 
+<!--
+In the `server.1`, `server.2`, and `server.3` properties at the bottom of
+the file, the `1`, `2`, and `3` correspond to the identifiers in the
+ZooKeeper servers' `myid` files. They are set to the FQDNs for the Pods in
+the `zk` StatefulSet.
+-->
 
-文件底部为 `server.1`、`server.2` 和 `server.3`，其中的 `1`、`2`和`3`分别对应 ZooKeeper 服务的 `myid` 文件中的标识符。它们被设置为  `zk` StatefulSet 中的 Pods 的 FQDNs。
+文件底部为 `server.1`、`server.2` 和 `server.3`，其中的 `1`、`2`和`3`分别对应 ZooKeeper 服务器的 `myid` 文件中的标识符。它们被设置为  `zk` StatefulSet 中的 Pods 的 FQDNs。
 
-```shell
+```
 clientPort=2181
 dataDir=/var/lib/zookeeper/data
 dataLogDir=/var/lib/zookeeper/log
@@ -210,21 +311,26 @@ minSessionTimeout= 4000
 maxSessionTimeout= 40000
 autopurge.snapRetainCount=3
 autopurge.purgeInterval=0
-server.1=zk-0.zk-headless.default.svc.cluster.local:2888:3888
-server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888
-server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888
+server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
+server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
+server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
 ```
 
+<!--
+### Achieving Consensus
+
+Consensus protocols require that the identifiers of each participant be unique. No two participants in the Zab protocol should claim the same unique identifier. This is necessary to allow the processes in the system to agree on which processes have committed which data. If two Pods are launched with the same ordinal, two ZooKeeper servers would both identify themselves as the same server.
+-->
 
 ### 达成一致
 
+ 一致性协议要求每个参与者的标识符唯一。在 Zab 协议里任何两个参与者都不应该声明相同的唯一标识符。对于让系统中的进程协商哪些进程已经提交了哪些数据而言，这是必须的。如果有两个 Pods 使用相同的序号启动，这两个 ZooKeeper 服务器会将自己识别为相同的服务器。
 
- 一致性协议要求每个参与者的标识符唯一。在 Zab 协议里任何两个参与者都不应该声明相同的唯一标识符。对于让系统中的进程协商哪些进程已经提交了哪些数据而言，这是必须的。如果有两个 Pods 使用相同的序号启动，这两个 ZooKeeper 服务会将自己识别为相同的服务。
-
-
-当你创建 `zk` StatefulSet 时，StatefulSet 控制器按照 Pods 的序号索引顺序的创建每个 Pod。在创建下一个 Pod 前会等待每个 Pod 变成 Running 和 Ready 状态。
 ```shell
 kubectl get pods -w -l app=zk
+```
+
+```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      0/1       Pending   0          0s
 zk-0      0/1       Pending   0         0s
@@ -243,50 +349,68 @@ zk-2      0/1       Running   0         19s
 zk-2      1/1       Running   0         40s
 ```
 
+<!--
+The A records for each Pod are entered when the Pod becomes Ready. Therefore,
+the FQDNs of the ZooKeeper servers will resolve to a single endpoint, and that
+endpoint will be the unique ZooKeeper server claiming the identity configured
+in its `myid` file.
+-->
 
-每个 Pod 的 A 记录仅在 Pod 变成 Ready状态时被录入。因此，ZooKeeper 服务的 FQDNs 只会解析到一个 endpoint，而那个 endpoint 将会是一个唯一的 ZooKeeper 服务，这个服务声明了配置在它的 `myid` 文件中的标识符。
+每个 Pod 的 A 记录仅在 Pod 变成 Ready状态时被录入。因此，ZooKeeper 服务器的 FQDNs 只会解析到一个 endpoint，而那个 endpoint 将会是一个唯一的 ZooKeeper 服务器，这个服务器声明了配置在它的 `myid` 文件中的标识符。
 
-```shell
-zk-0.zk-headless.default.svc.cluster.local
-zk-1.zk-headless.default.svc.cluster.local
-zk-2.zk-headless.default.svc.cluster.local
+```
+zk-0.zk-hs.default.svc.cluster.local
+zk-1.zk-hs.default.svc.cluster.local
+zk-2.zk-hs.default.svc.cluster.local
 ```
 
+<!--
+This ensures that the `servers` properties in the ZooKeepers' `zoo.cfg` files
+represents a correctly configured ensemble.
+-->
 
 这保证了 ZooKeepers 的 `zoo.cfg` 文件中的 `servers` 属性代表了一个正确配置的 ensemble。
 
-```shell
-server.1=zk-0.zk-headless.default.svc.cluster.local:2888:3888
-server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888
-server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888
+```
+server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
+server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
+server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
 ```
 
+<!--
+When the servers use the Zab protocol to attempt to commit a value, they will either achieve consensus and commit the value (if leader election has succeeded and at least two of the Pods are Running and Ready), or they will fail to do so (if either of the conditions are not met). No state will arise where one server acknowledges a write on behalf of another.
+-->
 
-当服务使用 Zab 协议尝试提交一个值的时候，它们会达成一致并成功提交这个值（如果 leader 选举成功并且至少有两个 Pods 处于 Running 和 Ready状态），或者将会失败（如果没有满足上述条件中的任意一条）。当一个服务承认另一个服务的代写时不会有状态产生。
+当服务器使用 Zab 协议尝试提交一个值的时候，它们会达成一致并成功提交这个值（如果 leader 选举成功并且至少有两个 Pods 处于 Running 和 Ready状态），或者将会失败（如果没有满足上述条件中的任意一条）。当一个服务器承认另一个服务器的代写时不会有状态产生。
 
+<!--
+### Sanity Testing the Ensemble
+
+The most basic sanity test is to write data to one ZooKeeper server and
+to read the data from another.
+
+The command below executes the `zkCli.sh` script to write `world` to the path `/hello` on the `zk-0` Pod in the ensemble.
+-->
 
 ### Ensemble 健康检查
 
-
-最基本的健康检查是向一个 ZooKeeper 服务写入一些数据，然后从另一个服务读取这些数据。
-
+最基本的健康检查是向一个 ZooKeeper 服务器写入一些数据，然后从另一个服务器读取这些数据。
 
 使用 `zkCli.sh` 脚本在 `zk-0` Pod 上写入 `world` 到路径 `/hello`。
 
 ```shell
 kubectl exec zk-0 zkCli.sh create /hello world
 ```
-
-
-这将会把 `world` 写入 ensemble 的 `/hello` 路径。
-
-```shell
+```
 WATCHER::
 
 WatchedEvent state:SyncConnected type:None path:null
 Created /hello
 ```
 
+<!--
+To get the data from the `zk-1` Pod use the following command.
+-->
 
 从 `zk-1` Pod 获取数据。
 
@@ -294,10 +418,14 @@ Created /hello
 kubectl exec zk-1 zkCli.sh get /hello
 ```
 
+<!--
+The data that you created on `zk-0` is available on all the servers in the
+ensemble.
+-->
 
-你在 `zk-0` 创建的数据在 ensemble 中所有的服务上都是可用的。
+你在 `zk-0` 创建的数据在 ensemble 中所有的服务器上都是可用的。
 
-```shell
+```
 WATCHER::
 
 WatchedEvent state:SyncConnected type:None path:null
@@ -315,31 +443,50 @@ dataLength = 5
 numChildren = 0
 ```
 
+<!--
+### Providing Durable Storage
+
+As mentioned in the [ZooKeeper Basics](#zookeeper-basics) section,
+ZooKeeper commits all entries to a durable WAL, and periodically writes snapshots
+in memory state, to storage media. Using WALs to provide durability is a common
+technique for applications that use consensus protocols to achieve a replicated
+state machine.
+
+Use the [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) command to delete the
+`zk` StatefulSet.
+-->
 
 ### 准备持久存储
 
+如同在 [ZooKeeper 基础](#zookeeper-基础) 一节所提到的，ZooKeeper 提交所有的条目到一个持久 WAL，并周期性的将内存快照写入存储介质。对于使用一致性协议实现一个复制状态机的应用来说，使用 WALs 提供持久化是一种常用的技术，对于普通的存储应用也是如此。
 
-如同在 [ZooKeeper 基础](#zookeeper-basics) 一节所提到的，ZooKeeper 提交所有的条目到一个持久 WAL，并周期性的将内存快照写入存储介质。对于使用一致性协议实现一个复制状态机的应用来说，使用 WALs 提供持久化是一种常用的技术，对于普通的存储应用也是如此。
-
-
-使用 [`kubectl delete`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#delete) 删除 `zk` StatefulSet。
+使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 `zk` StatefulSet。
 
 ```shell
 kubectl delete statefulset zk
-statefulset "zk" deleted
 ```
 
+```
+statefulset.apps "zk" deleted
+```
+
+<!--
+Watch the termination of the Pods in the StatefulSet.
+-->
 
 观察 StatefulSet 中的 Pods 变为终止状态。
 
 ```shell
-get pods -w -l app=zk
+kubectl get pods -w -l app=zk
 ```
 
+<!--
+When `zk-0` if fully terminated, use `CTRL-C` to terminate kubectl.
+-->
 
 当 `zk-0` 完全终止时，使用 `CRTL-C` 结束 kubectl。
 
-```shell
+```
 zk-2      1/1       Terminating   0         9m
 zk-0      1/1       Terminating   0         11m
 zk-1      1/1       Terminating   0         10m
@@ -354,33 +501,37 @@ zk-0      0/1       Terminating   0         11m
 zk-0      0/1       Terminating   0         11m
 ```
 
+<!--
+Reapply the manifest in `zookeeper.yaml`.
+-->
+
 重新应用 `zookeeper.yaml` 中的代码清单。
 
 ```shell
-kubectl apply -f https://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml
+kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
 ```
 
+<!--
+This creates the `zk` StatefulSet object, but the other API objects in the manifest are not modified because they already exist.
+
+Watch the StatefulSet controller recreate the StatefulSet's Pods.
+-->
 
 `zk` StatefulSet 将会被创建。由于清单中的其他 API 对象已经存在，所以它们不会被修改。
 
-```shell
-statefulset "zk" created
-Error from server (AlreadyExists): error when creating "zookeeper.yaml": services "zk-headless" already exists
-Error from server (AlreadyExists): error when creating "zookeeper.yaml": configmaps "zk-config" already exists
-Error from server (AlreadyExists): error when creating "zookeeper.yaml": poddisruptionbudgets.policy "zk-budget" already exists
-```
-
-
 观察 StatefulSet 控制器重建 StatefulSet 的 Pods。
 
 ```shell
 kubectl get pods -w -l app=zk
 ```
 
+<!--
+Once the `zk-2` Pod is Running and Ready, use `CTRL-C` to terminate kubectl.
+-->
 
 一旦 `zk-2` Pod 处于 Running 和 Ready 状态，使用 `CRTL-C` 停止 kubectl命令。
 
-```shell
+```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      0/1       Pending   0          0s
 zk-0      0/1       Pending   0         0s
@@ -399,17 +550,24 @@ zk-2      0/1       Running   0         19s
 zk-2      1/1       Running   0         40s
 ```
 
+<!--
+Use the command below to get the value you entered during the [sanity test](#sanity-testing-the-ensemble),
+from the `zk-2` Pod.
+-->
 
-从 `zk-2` Pod 中获取你在[健康检查](#sanity-testing-the-ensemble)中输入的值。
+从 `zk-2` Pod 中获取你在[健康检查](#Ensemble-健康检查)中输入的值。
 
 ```shell
 kubectl exec zk-2 zkCli.sh get /hello
 ```
 
+<!--
+Even though you terminated and recreated all of the Pods in the `zk` StatefulSet, the ensemble still serves the original value.
+-->
 
 尽管 `zk` StatefulSet 中所有的 Pods 都已经被终止并重建过，ensemble 仍然使用原来的数值提供服务。
 
-```shell
+```
 WATCHER::
 
 WatchedEvent state:SyncConnected type:None path:null
@@ -427,6 +585,9 @@ dataLength = 5
 numChildren = 0
 ```
 
+<!--
+The `volumeClaimTemplates` field of the `zk` StatefulSet's `spec` specifies a PersistentVolume provisioned for each Pod.
+-->
 
 `zk` StatefulSet 的 `spec` 中的 `volumeClaimTemplates` 字段标识了将要为每个 Pod 准备的 PersistentVolume。
 
@@ -443,29 +604,39 @@ volumeClaimTemplates:
           storage: 20Gi
 ```
 
+<!--
+The `StatefulSet` controller generates a `PersistentVolumeClaim` for each Pod in
+the `StatefulSet`.
 
+Use the following command to get the `StatefulSet`'s `PersistentVolumeClaims`.
+-->
 
 StatefulSet 控制器为 StatefulSet 中的每个 Pod 生成一个 PersistentVolumeClaim。
 
-
 获取 StatefulSet 的 PersistentVolumeClaims。
 
 ```shell
 kubectl get pvc -l app=zk
 ```
 
+<!--
+When the `StatefulSet` recreated its Pods, it remounts the Pods' PersistentVolumes.
+-->
 
 当 StatefulSet 重新创建它的 Pods时，Pods 的 PersistentVolumes 会被重新挂载。
 
-```shell
+```
 NAME           STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
 datadir-zk-0   Bound     pvc-bed742cd-bcb1-11e6-994f-42010a800002   20Gi       RWO           1h
 datadir-zk-1   Bound     pvc-bedd27d2-bcb1-11e6-994f-42010a800002   20Gi       RWO           1h
 datadir-zk-2   Bound     pvc-bee0817e-bcb1-11e6-994f-42010a800002   20Gi       RWO           1h
 ```
 
+<!--
+The `volumeMounts` section of the `StatefulSet`'s container `template` mounts the PersistentVolumes in the ZooKeeper servers' data directories.
+-->
 
-StatefulSet 的容器 `template` 中的 `volumeMounts` 一节使得 PersistentVolumes 被挂载到 ZooKeeper 服务的数据目录。
+StatefulSet 的容器 `template` 中的 `volumeMounts` 一节使得 PersistentVolumes 被挂载到 ZooKeeper 服务器的数据目录。
 
 ```shell
 volumeMounts:
@@ -473,163 +644,98 @@ volumeMounts:
           mountPath: /var/lib/zookeeper
 ```
 
-当 `zk` StatefulSet 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，挂载到 ZooKeeper 服务的数据目录。即使在 Pods 被重新调度时，所有对 ZooKeeper 服务的 WALs 的写入和它们的全部快照都仍然是持久的。
+<!--
+When a Pod in the `zk` `StatefulSet` is (re)scheduled, it will always have the
+same `PersistentVolume` mounted to the ZooKeeper server's data directory.
+Even when the Pods are rescheduled, all the writes made to the ZooKeeper
+servers' WALs, and all their snapshots, remain durable.
+-->
 
+当 `zk` StatefulSet 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，挂载到 ZooKeeper 服务器的数据目录。即使在 Pods 被重新调度时，所有对 ZooKeeper 服务器的 WALs 的写入和它们的全部快照都仍然是持久的。
+
+<!--
+## Ensuring Consistent Configuration
+
+As noted in the [Facilitating Leader Election](#facilitating-leader-election) and
+[Achieving Consensus](#achieving-consensus) sections, the servers in a
+ZooKeeper ensemble require consistent configuration to elect a leader
+and form a quorum. They also require consistent configuration of the Zab protocol
+in order for the protocol to work correctly over a network. In our example we
+achieve consistent configuration by embedding the configuration directly into
+the manifest.
+
+Get the `zk` StatefulSet.
+-->
 
 ## 确保一致性配置
 
+如同在 [促成 leader 选举](#促成-Leader-选举) 和 [达成一致](#达成一致) 小节中提到的，ZooKeeper ensemble 中的服务器需要一致性的配置来选举一个 leader 并形成一个 quorum。它们还需要 Zab 协议的一致性配置来保证这个协议在网络中正确的工作。在这次的样例中，我们通过直接将配置写入代码清单中来达到该目的。
 
-如同在 [促成 leader 选举](#facilitating-leader-election) 和 [达成一致](#achieving-consensus) 小节中提到的，ZooKeeper ensemble 中的服务需要一致性的配置来选举一个 leader 并形成一个 quorum。它们还需要 Zab 协议的一致性配置来保证这个协议在网络中正确的工作。你可以使用 ConfigMaps 达到目的。
-
-
-获取 `zk-config` 的 ConfigMap。
+获取 `zk` StatefulSet。
 
 ```shell
- kubectl get cm zk-config -o yaml
-apiVersion: v1
-data:
-  client.cnxns: "60"
-  ensemble: zk-0;zk-1;zk-2
-  init: "10"
-  jvm.heap: 2G
-  purge.interval: "0"
-  snap.retain: "3"
-  sync: "5"
-  tick: "2000"
+kubectl get sts zk -o yaml
+```
+```
+…
+command:
+      - sh
+      - -c
+      - "start-zookeeper \
+        --servers=3 \
+        --data_dir=/var/lib/zookeeper/data \
+        --data_log_dir=/var/lib/zookeeper/data/log \
+        --conf_dir=/opt/zookeeper/conf \
+        --client_port=2181 \
+        --election_port=3888 \
+        --server_port=2888 \
+        --tick_time=2000 \
+        --init_limit=10 \
+        --sync_limit=5 \
+        --heap=512M \
+        --max_client_cnxns=60 \
+        --snap_retain_count=3 \
+        --purge_interval=12 \
+        --max_session_timeout=40000 \
+        --min_session_timeout=4000 \
+        --log_level=INFO"
+…
 ```
 
+<!--
+The command used to start the ZooKeeper servers passed the configuration as command line parameter. You can also use environment variables to pass configuration to the ensemble.
+-->
 
-`zk` StatefulSet 的 `template` 中的 `env` 字段读取 ConfigMap 到环境变量中。这些变量将被注入到容器的运行环境里。
+用于启动 ZooKeeper 服务器的命令将这些配置作为命令行参数传给了 ensemble。你也可以通过环境变量来传入这些配置。
 
-```yaml
-env:
-        - name : ZK_ENSEMBLE
-          valueFrom:
-            configMapKeyRef:
-              name: zk-config
-              key: ensemble
-        - name : ZK_HEAP_SIZE
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: jvm.heap
-        - name : ZK_TICK_TIME
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: tick
-        - name : ZK_INIT_LIMIT
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: init
-        - name : ZK_SYNC_LIMIT
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: tick
-        - name : ZK_MAX_CLIENT_CNXNS
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: client.cnxns
-        - name: ZK_SNAP_RETAIN_COUNT
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: snap.retain
-        - name: ZK_PURGE_INTERVAL
-          valueFrom:
-            configMapKeyRef:
-                name: zk-config
-                key: purge.interval
-```
+<!--
+### Configuring Logging
 
+One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging.
+ZooKeeper uses [Log4j](https://logging.apache.org/log4j/2.x/), and, by default,
+it uses a time and size based rolling file appender for its logging configuration.
 
-在启动 ZooKeeper 服务进程前，容器的入口点调用了一个 bash 脚本：`zkGenConfig.sh`。这个 bash 脚本从提供的环境变量中生成了 ZooKeeper 的配置文件。
-
-```yaml
- command:
-        - sh
-        - -c
-        - zkGenConfig.sh && zkServer.sh start-foreground
-```
-
-
-检查 `zk` StatefulSet 中所有 Pods 的环境变量。
-
-```shell
-for i in 0 1 2; do kubectl exec zk-$i env | grep ZK_*;echo""; done
-```
-
-
-所有从 `zk-config` 取得的参数都包含完全相同的值。这将允许 `zkGenConfig.sh` 脚本为 ensemble 中所有的 ZooKeeper 服务创建一致性的配置。
-
-```shell
-ZK_ENSEMBLE=zk-0;zk-1;zk-2
-ZK_HEAP_SIZE=2G
-ZK_TICK_TIME=2000
-ZK_INIT_LIMIT=10
-ZK_SYNC_LIMIT=2000
-ZK_MAX_CLIENT_CNXNS=60
-ZK_SNAP_RETAIN_COUNT=3
-ZK_PURGE_INTERVAL=0
-ZK_CLIENT_PORT=2181
-ZK_SERVER_PORT=2888
-ZK_ELECTION_PORT=3888
-ZK_USER=zookeeper
-ZK_DATA_DIR=/var/lib/zookeeper/data
-ZK_DATA_LOG_DIR=/var/lib/zookeeper/log
-ZK_LOG_DIR=/var/log/zookeeper
-
-ZK_ENSEMBLE=zk-0;zk-1;zk-2
-ZK_HEAP_SIZE=2G
-ZK_TICK_TIME=2000
-ZK_INIT_LIMIT=10
-ZK_SYNC_LIMIT=2000
-ZK_MAX_CLIENT_CNXNS=60
-ZK_SNAP_RETAIN_COUNT=3
-ZK_PURGE_INTERVAL=0
-ZK_CLIENT_PORT=2181
-ZK_SERVER_PORT=2888
-ZK_ELECTION_PORT=3888
-ZK_USER=zookeeper
-ZK_DATA_DIR=/var/lib/zookeeper/data
-ZK_DATA_LOG_DIR=/var/lib/zookeeper/log
-ZK_LOG_DIR=/var/log/zookeeper
-
-ZK_ENSEMBLE=zk-0;zk-1;zk-2
-ZK_HEAP_SIZE=2G
-ZK_TICK_TIME=2000
-ZK_INIT_LIMIT=10
-ZK_SYNC_LIMIT=2000
-ZK_MAX_CLIENT_CNXNS=60
-ZK_SNAP_RETAIN_COUNT=3
-ZK_PURGE_INTERVAL=0
-ZK_CLIENT_PORT=2181
-ZK_SERVER_PORT=2888
-ZK_ELECTION_PORT=3888
-ZK_USER=zookeeper
-ZK_DATA_DIR=/var/lib/zookeeper/data
-ZK_DATA_LOG_DIR=/var/lib/zookeeper/log
-ZK_LOG_DIR=/var/log/zookeeper
-```
-
+Use the command below to get the logging configuration from one of Pods in the `zk` `StatefulSet`.
+-->
 
 ### 配置日志
 
-
 `zkGenConfig.sh` 脚本产生的一个文件控制了 ZooKeeper 的日志行为。ZooKeeper 使用了 [Log4j](http://logging.apache.org/log4j/2.x/) 并默认使用基于文件大小和时间的滚动文件追加器作为日志配置。
-从 `zk` StatefulSet 的一个 Pods 中获取日志配置。
+
+从 `zk` StatefulSet 的一个 Pod 中获取日志配置。
 
 ```shell
 kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties
 ```
 
+<!--
+The logging configuration below will cause the ZooKeeper process to write all
+of its logs to the standard output file stream.
+-->
 
 下面的日志配置会使 ZooKeeper 进程将其所有的日志写入标志输出文件流中。
 
-```shell
+```
 zookeeper.root.logger=CONSOLE
 zookeeper.console.threshold=INFO
 log4j.rootLogger=${zookeeper.root.logger}
@@ -639,20 +745,31 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
 log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
 ```
 
+<!--
+This is the simplest possible way to safely log inside the container.
+Because the applications write logs to standard out, Kubernetes will handle log rotation for you.
+Kubernetes also implements a sane retention policy that ensures application logs written to
+standard out and standard error do not exhaust local storage media.
+
+Use [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) to retrieve the last 20 log lines from one of the Pods.
+-->
 
 这是在容器里安全记录日志的最简单的方法。由于应用的日志被写入标准输出，Kubernetes 将会为你处理日志轮转。Kubernetes 还实现了一个智能保存策略，保证写入标准输出和标准错误流的应用日志不会耗尽本地存储媒介。
 
 
-使用 [`kubectl logs`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#logs) 从一个 Pod 中取回最后几行日志。
+使用 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) 从一个 Pod 中取回最后几行日志。
 
 ```shell
 kubectl logs zk-0 --tail 20
 ```
 
+<!--
+You can view application logs written to standard out or standard error using `kubectl logs` and from the Kubernetes Dashboard.
+-->
 
 使用 `kubectl logs` 或者从 Kubernetes Dashboard 可以查看写入到标准输出和标准错误流中的应用日志。
 
-```shell
+```
 2016-12-06 19:34:16,236 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740
 2016-12-06 19:34:16,237 [myid:1] - INFO  [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client)
 2016-12-06 19:34:26,155 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749
@@ -675,16 +792,34 @@ kubectl logs zk-0 --tail 20
 2016-12-06 19:34:46,230 [myid:1] - INFO  [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)
 ```
 
+<!--
+Kubernetes supports more powerful, but more complex, logging integrations
+with [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
+and [Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/).
+For cluster level log shipping and aggregation, consider deploying a [sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
+container to rotate and ship your logs.
+-->
 
+Kubernetes 支持与 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/) 和  [Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/) 的整合以获得复杂但更为强大的日志功能。
+对于集群级别的日志输出与整合，可以考虑部署一个 [sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 容器。
 
+<!--
+### Configuring a Non-Privileged User
+
+The best practices to allow an application to run as a privileged
+user inside of a container are a matter of debate. If your organization requires
+that applications run as a non-privileged user you can use a
+[SecurityContext](/docs/tasks/configure-pod-container/security-context/) to control the user that
+the entry point runs as.
+
+The `zk` `StatefulSet`'s Pod `template` contains a `SecurityContext`.
+-->
 
 ### 配置非特权用户
 
-
 在容器中允许应用以特权用户运行这条最佳实践是值得商讨的。如果你的组织要求应用以非特权用户运行，你可以使用 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 控制运行容器入口点的用户。
 
-
-`zk` StatefulSet 的 Pod 的 `template` 包含了一个 SecurityContext。
+`zk` StatefulSet 的 Pod 的 `template` 包含了一个 `SecurityContext`。
 
 ```yaml
 securityContext:
@@ -692,9 +827,14 @@ securityContext:
   fsGroup: 1000
 ```
 
+<!--
+In the Pods' containers, UID 1000 corresponds to the zookeeper user and GID 1000
+corresponds to the zookeeper group.
 
-在 Pods 容器内部，UID 1000 对应用户 zookeeper，GID 1000对应用户组 zookeeper。
+Get the ZooKeeper process information from the `zk-0` Pod.
+-->
 
+在 Pods 的容器内部，UID 1000 对应用户 zookeeper，GID 1000对应用户组 zookeeper。
 
 从 `zk-0` Pod 获取 ZooKeeper 进程信息。
 
@@ -702,18 +842,26 @@ securityContext:
 kubectl exec zk-0 -- ps -elf
 ```
 
+<!--
+As the `runAsUser` field of the `securityContext` object is set to 1000,
+instead of running as root, the ZooKeeper process runs as the zookeeper user.
+-->
 
-由于 `securityContext` 对象的 `runAsUser` 字段被设置为1000而不是 root，ZooKeeper进程将以 zookeeper 用户运行。
+由于 `securityContext` 对象的 `runAsUser` 字段被设置为1000而不是 root，ZooKeeper 进程将以 zookeeper 用户运行。
 
-```shell
+```
 F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
 4 S zookeep+     1     0  0  80   0 -  1127 -      20:46 ?        00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
 0 S zookeep+    27     1  0  80   0 - 1155556 -    20:46 ?        00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
 ```
 
+<!--
+By default, when the Pod's PersistentVolumes is mounted to the ZooKeeper server's data directory, it is only accessible by the root user. This configuration prevents the ZooKeeper process from writing to its WAL and storing its snapshots.
 
-默认情况下，当 Pod 的 PersistentVolume 被挂载到 ZooKeeper 服务的数据目录时，它只能被 root 用户访问。这个配置将阻止 ZooKeeper 进程写入它的 WAL 及保存快照。
+Use the command below to get the file permissions of the ZooKeeper data directory on the `zk-0` Pod.
+-->
 
+默认情况下，当 Pod 的 PersistentVolume 被挂载到 ZooKeeper 服务器的数据目录时，它只能被 root 用户访问。这个配置将阻止 ZooKeeper 进程写入它的 WAL 及保存快照。
 
 在 `zk-0` Pod 上获取 ZooKeeper 数据目录的文件权限。
 
@@ -721,35 +869,138 @@ F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
 kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data
 ```
 
+<!--
+Because the `fsGroup` field of the `securityContext` object is set to 1000, the ownership of the Pods' PersistentVolumes is set to the zookeeper group, and the ZooKeeper process is able to read and write its data.
+-->
 
 由于 `securityContext` 对象的 `fsGroup` 字段设置为1000，Pods 的 PersistentVolumes 的所有权属于 zookeeper 用户组，因而 ZooKeeper 进程能够成功的读写数据。
 
-```shell
+```
 drwxr-sr-x 3 zookeeper zookeeper 4096 Dec  5 20:45 /var/lib/zookeeper/data
 ```
 
+<!--
+## Managing the ZooKeeper Process
+
+The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision)
+mentions that "You will want to have a supervisory process that
+manages each of your ZooKeeper server processes (JVM)." Utilizing a watchdog
+(supervisory process) to restart failed processes in a distributed system is a
+common pattern. When deploying an application in Kubernetes, rather than using
+an external utility as a supervisory process, you should use Kubernetes as the
+watchdog for your application.
+-->
 
 ## 管理 ZooKeeper 进程
 
-
 [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision) 文档指出“你将需要一个监管程序用于管理每个 ZooKeeper 服务进程（JVM）”。在分布式系统中，使用一个看门狗（监管程序）来重启故障进程是一种常用的模式。
 
+<!--
+### Updating the Ensemble
+
+The `zk` `StatefulSet` is configured to use the `RollingUpdate` update strategy.
+
+You can use `kubectl patch` to update the number of `cpus` allocated to the servers.
+-->
+
+### 更新 Ensemble
+
+`zk` `StatefulSet` 的更新策略被设置为了 `RollingUpdate`。
+
+你可以使用 `kubectl patch` 更新分配给每个服务器的 `cpus` 的数量。
+
+```shell
+kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
+```
+```
+statefulset.apps/zk patched
+```
+
+<!--
+Use `kubectl rollout status` to watch the status of the update.
+-->
+
+使用 `kubectl rollout status` 观测更新状态。
+
+```shell
+kubectl rollout status sts/zk
+```
+```
+waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+waiting for statefulset rolling update to complete 1 pods at revision zk-5db4499664...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+waiting for statefulset rolling update to complete 2 pods at revision zk-5db4499664...
+Waiting for 1 pods to be ready...
+Waiting for 1 pods to be ready...
+statefulset rolling update complete 3 pods at revision zk-5db4499664...
+```
+
+<!--
+This terminates the Pods, one at a time, in reverse ordinal order, and recreates them with the new configuration. This ensures that quorum is maintained during a rolling update.
+
+Use the `kubectl rollout history` command to view a history or previous configurations.
+-->
+
+这项操作会逆序地依次终止每一个 Pod，并用新的配置重新创建。这样做确保了在滚动更新的过程中 quorum 依旧保持工作。
+
+使用 `kubectl rollout history` 命令查看历史或先前的配置。
+
+```shell
+kubectl rollout history sts/zk
+```
+
+```
+statefulsets "zk"
+REVISION
+1
+2
+```
+
+<!--
+Use the `kubectl rollout undo` command to roll back the modification.
+-->
+
+使用 `kubectl rollout undo` 命令撤销这次的改动。
+
+```shell
+kubectl rollout undo sts/zk
+```
+
+```
+statefulset.apps/zk rolled back
+```
+
+<!--
+### Handling Process Failure
+
+[Restart Policies](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) control how
+Kubernetes handles process failures for the entry point of the container in a Pod.
+For Pods in a `StatefulSet`, the only appropriate `RestartPolicy` is Always, and this
+is the default value. For stateful applications you should **never** override
+the default policy.
+
+Use the following command to examine the process tree for the ZooKeeper server running in the `zk-0` Pod.
+-->
 
 ### 处理进程故障
 
+[Restart Policies](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。对于 StatefulSet 中的 Pods 来说，Always 是唯一合适的 RestartPolicy，这也是默认值。你应该**绝不**覆盖 stateful 应用的默认策略。
 
-[Restart Policies](/zh/docs/user-guide/pod-states/#restartpolicy) 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。对于 StatefulSet 中的 Pods 来说，Always 是唯一合适的 RestartPolicy，这也是默认值。你应该**绝不**覆盖 stateful 应用的默认策略。
-
-
-检查 `zk-0` Pod 中运行的 ZooKeeper 服务的进程树。
+检查 `zk-0` Pod 中运行的 ZooKeeper 服务器的进程树。
 
 ```shell
 kubectl exec zk-0 -- ps -ef
 ```
 
+<!--
+The command used as the container's entry point has PID 1, and
+the ZooKeeper process, a child of the entry point, has PID 27.
+-->
 
-作为容器入口点的命令的 PID 为 1，Zookeeper 进程是入口点的子进程，PID 为23。
-
+作为容器入口点的命令的 PID 为 1，Zookeeper 进程是入口点的子进程，PID 为27。
 
 ```
 UID        PID  PPID  C STIME TTY          TIME CMD
@@ -757,6 +1008,9 @@ zookeep+     1     0  0 15:03 ?        00:00:00 sh -c zkGenConfig.sh && zkServer
 zookeep+    27     1  0 15:03 ?        00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
 ```
 
+<!--
+In another terminal watch the Pods in the `zk` `StatefulSet` with the following command.
+-->
 
 在一个终端观察 `zk` StatefulSet 中的 Pods。
 
@@ -764,6 +1018,9 @@ zookeep+    27     1  0 15:03 ?        00:00:03 /usr/lib/jvm/java-8-openjdk-amd6
 kubectl get pod -w -l app=zk
 ```
 
+<!--
+In another terminal, terminate the ZooKeeper process in Pod `zk-0` with the following command.
+-->
 
 在另一个终端杀掉 Pod `zk-0` 中的 ZooKeeper 进程。
 
@@ -771,12 +1028,13 @@ kubectl get pod -w -l app=zk
  kubectl exec zk-0 -- pkill java
 ```
 
-
+<!--
+The termination of the ZooKeeper process caused its parent process to terminate. Because the `RestartPolicy` of the container is Always, it restarted the parent process.
+-->
 
 ZooKeeper 进程的终结导致了它父进程的终止。由于容器的 RestartPolicy 是 Always，父进程被重启。
 
-
-```shell
+```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   0          21m
 zk-1      1/1       Running   0          20m
@@ -787,36 +1045,53 @@ zk-0      0/1       Running   1         29m
 zk-0      1/1       Running   1         29m
 ```
 
+<!--
+If your application uses a script (such as `zkServer.sh`) to launch the process
+that implements the application's business logic, the script must terminate with the
+child process. This ensures that Kubernetes will restart the application's
+container when the process implementing the application's business logic fails.
+-->
 
 如果你的应用使用一个脚本（例如 zkServer.sh）来启动一个实现了应用业务逻辑的进程，这个脚本必须和子进程一起结束。这保证了当实现应用业务逻辑的进程故障时，Kubernetes 会重启这个应用的容器。
 
+<!--
+### Testing for Liveness
 
+Configuring your application to restart failed processes is not enough to
+keep a distributed system healthy. There are scenarios where
+a system's processes can be both alive and unresponsive, or otherwise
+unhealthy. You should use liveness probes to notify Kubernetes
+that your application's processes are unhealthy and it should restart them.
 
+The Pod `template` for the `zk` `StatefulSet` specifies a liveness probe.
+-->
 
+### 存活性测试
 
 你的应用配置为自动重启故障进程，但这对于保持一个分布式系统的健康来说是不够的。许多场景下，一个系统进程可以是活动状态但不响应请求，或者是不健康状态。你应该使用 liveness probes 来通知 Kubernetes 你的应用进程处于不健康状态，需要被重启。
 
-
-
-`zk` StatefulSet 的 Pod 的 `template` 一节指定了一个 liveness probe。
-
+`zk` StatefulSet 的 Pod 的 `template` 一节指定了一个存活探针。
 
 ```yaml
  livenessProbe:
           exec:
             command:
-            - "zkOk.sh"
+            - sh
+            - -c
+            - "zookeeper-ready 2181"
           initialDelaySeconds: 15
           timeoutSeconds: 5
 ```
 
+<!--
+The probe calls a bash script that uses the ZooKeeper `ruok` four letter
+word to test the server's health.
+-->
 
-这个探针调用一个简单的 bash 脚本，使用 ZooKeeper 的四字缩写 `ruok` 来测试服务的健康状态。
+这个探针调用一个简单的 bash 脚本，使用 ZooKeeper 的四字缩写 `ruok` 来测试服务器的健康状态。
 
-
-```bash
-ZK_CLIENT_PORT=${ZK_CLIENT_PORT:-2181}
-OK=$(echo ruok | nc 127.0.0.1 $ZK_CLIENT_PORT)
+```
+OK=$(echo ruok | nc 127.0.0.1 $1)
 if [ "$OK" == "imok" ]; then
     exit 0
 else
@@ -824,28 +1099,39 @@ else
 fi
 ```
 
+<!--
+In one terminal window, use the following command to watch the Pods in the `zk` StatefulSet.
+-->
 
 在一个终端窗口观察 `zk` StatefulSet 中的 Pods。
 
+```shell
+kubectl get pod -w -l app=zk
+```
+
+<!--
+In another window, using the following command to delete the `zookeeper-ready` script from the file system of Pod `zk-0`.
+-->
+
+在另一个窗口中，从 Pod `zk-0` 的文件系统中删除 `zookeeper-ready` 脚本。
+
+```shell
+kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
+```
+
+<!--
+When the liveness probe for the ZooKeeper process fails, Kubernetes will
+automatically restart the process for you, ensuring that unhealthy processes in
+the ensemble are restarted.
+-->
+
+当 ZooKeeper 进程的存活探针探测失败时，Kubernetes 将会为你自动重启这个进程，从而保证 ensemble 中不健康状态的进程都被重启。
 
 ```shell
 kubectl get pod -w -l app=zk
 ```
 
-
-在另一个窗口中，从 Pod `zk-0` 的文件系统中删除 `zkOk.sh` 脚本。
-
-
-```shell
-kubectl exec zk-0 -- rm /opt/zookeeper/bin/zkOk.sh
 ```
-
-
-当 ZooKeeper 进程的 liveness probe 失败时，Kubernetes 将会为你自动重启这个进程，从而保证 ensemble 中不健康状态的进程都被重启。
-
-
-```shell
-kubectl get pod -w -l app=zk
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   0          1h
 zk-1      1/1       Running   0          1h
@@ -856,46 +1142,79 @@ zk-0      0/1       Running   1         1h
 zk-0      1/1       Running   1         1h
 ```
 
+<!--
+### Testing for Readiness
 
-### 可读性测试
+Readiness is not the same as liveness. If a process is alive, it is scheduled
+and healthy. If a process is ready, it is able to process input. Liveness is
+a necessary, but not sufficient, condition for readiness. There are cases,
+particularly during initialization and termination, when a process can be
+alive but not ready.
 
+If you specify a readiness probe, Kubernetes will ensure that your application's
+processes will not receive network traffic until their readiness checks pass.
 
+For a ZooKeeper server, liveness implies readiness.  Therefore, the readiness
+probe from the `zookeeper.yaml` manifest is identical to the liveness probe.
+-->
 
-可读性不同于存活性。如果一个进程是存活的，它是可调度和健康的。如果一个进程是就绪的，它应该能够处理输入。存活性是可读性的必要非充分条件。在许多场景下，特别是初始化和终止过程中，一个进程可以是存活但没有就绪。
+### 就绪性测试
 
+就绪不同于存活。如果一个进程是存活的，它是可调度和健康的。如果一个进程是就绪的，它应该能够处理输入。存活是就绪的必要非充分条件。在许多场景下，特别是初始化和终止过程中，一个进程可以是存活但没有就绪的。
 
-如果你指定了一个可读性探针，Kubernetes将保证在可读性检查通过之前，你的应用不会接收到网络流量。
-
-
-对于一个 ZooKeeper 服务来说，存活性实现了可读性。因此 `zookeeper.yaml` 清单中的可读性探针和存活性探针完全相同。
+如果你指定了一个就绪探针，Kubernetes将保证在就绪检查通过之前，你的应用不会接收到网络流量。
 
+对于一个 ZooKeeper 服务器来说，存活即就绪。因此 `zookeeper.yaml` 清单中的就绪探针和存活探针完全相同。
 
 ```yaml
- readinessProbe:
-          exec:
-            command:
-            - "zkOk.sh"
-          initialDelaySeconds: 15
-          timeoutSeconds: 5
+  readinessProbe:
+    exec:
+      command:
+      - sh
+      - -c
+      - "zookeeper-ready 2181"
+    initialDelaySeconds: 15
+    timeoutSeconds: 5
 ```
 
+<!--
+Even though the liveness and readiness probes are identical, it is important
+to specify both. This ensures that only healthy servers in the ZooKeeper
+ensemble receive network traffic.
+-->
 
+虽然存活探针和就绪探针是相同的，但同时指定它们两者仍然重要。这保证了 ZooKeeper ensemble 中只有健康的服务器能接收网络流量。
 
-虽然存活性探针和可读性探针是相同的，但同时指定它们两者仍然重要。这保证了 ZooKeeper ensemble 中唯一健康的服务能够接收网络流量。
+<!--
+## Tolerating Node Failure
 
+ZooKeeper needs a quorum of servers to successfully commit mutations
+to data. For a three server ensemble, two servers must be healthy for
+writes to succeed. In quorum based systems, members are deployed across failure
+domains to ensure availability. To avoid an outage, due to the loss of an
+individual machine, best practices preclude co-locating multiple instances of the
+application on the same machine.
 
+By default, Kubernetes may co-locate Pods in a `StatefulSet` on the same node.
+For the three server ensemble you created, if two servers are on the same node, and that node fails,
+the clients of your ZooKeeper service will experience an outage until at least one of the Pods can be rescheduled.
+
+You should always provision additional capacity to allow the processes of critical
+systems to be rescheduled in the event of node failures. If you do so, then the
+outage will only last until the Kubernetes scheduler reschedules one of the ZooKeeper
+servers. However, if you want your service to tolerate node failures with no downtime,
+you should set `podAntiAffinity`.
+
+Use the command below to get the nodes for Pods in the `zk` `StatefulSet`.
+-->
 
 ## 容忍节点故障
 
+ZooKeeper 需要一个 quorum 来提交数据变动。对于一个拥有 3 个服务器的 ensemble来说，必须有两个服务器是健康的，写入才能成功。在基于 quorum 的系统里，成员被部署在故障域之间以保证可用性。为了防止由于某台机器断连引起服务中断，最佳实践是防止应用的多个示例在相同的机器上共存。
 
-ZooKeeper 需要一个服务的 quorum 来成功的提交数据变动。对于一个 3 个服务的 ensemble，必须有两个是健康的写入才能成功。在基于 quorum 的系统里，成员被部署在故障域之间以保证可用性。为了防止由于某台机器断连引起服务中断，最佳实践是防止应用的多个示例在相同的机器上共存。
-
-
-默认情况下，Kubernetes 可以把 StatefulSet 的 Pods 部署在相同节点上。对于你创建的 3 个服务的 ensemble 来说，如果有两个服务并存于相同的节点上并且该节点发生故障时，你的 ZooKeeper 服务客户端将不能使用服务，至少一个 Pods 被重新调度后才能恢复。
-
-
-你应该总是提供额外的容量以允许关键系统进程在节点故障时能够被重新调度。如果你这样做了，服务故障就只会持续到 Kubernetes 调度器重新调度 ZooKeeper 服务之前。但是，如果希望你的服务在容忍节点故障时无停服时间，你应该设置 `podAntiAffinity`。
+默认情况下，Kubernetes 可以把 StatefulSet 的 Pods 部署在相同节点上。对于你创建的 3 个服务器的 ensemble 来说，如果有两个服务器并存于相同的节点上并且该节点发生故障时，ZooKeeper 服务将中断，直至至少一个 Pods 被重新调度。
 
+你应该总是提供额外的容量以允许关键系统进程在节点故障时能够被重新调度。如果你这样做了，服务故障就只会持续到 Kubernetes 调度器重新调度某个 ZooKeeper 服务器为止。但是，如果希望你的服务在容忍节点故障时无停服时间，你应该设置 `podAntiAffinity`。
 
 获取 `zk` Stateful Set 中的 Pods 的节点。
 
@@ -903,17 +1222,23 @@ ZooKeeper 需要一个服务的 quorum 来成功的提交数据变动。对于
 for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
 ```
 
+<!--
+All of the Pods in the `zk` `StatefulSet` are deployed on different nodes.
+-->
 
 `zk` StatefulSe 中所有的 Pods 都被部署在不同的节点。
 
-```shell
-kubernetes-minion-group-cxpk
-kubernetes-minion-group-a5aq
-kubernetes-minion-group-2g2d
+```
+kubernetes-node-cxpk
+kubernetes-node-a5aq
+kubernetes-node-2g2d
 ```
 
+<!--
+This is because the Pods in the `zk` `StatefulSet` have a `PodAntiAffinity` specified.
+-->
 
-这是因为 `zk` StatefulSet 中的  Pods 指定了 PodAntiAffinity。
+这是因为 `zk` StatefulSet 中的 Pods 指定了 `PodAntiAffinity`。
 
 ```yaml
       affinity:
@@ -928,19 +1253,36 @@ kubernetes-minion-group-2g2d
               topologyKey: "kubernetes.io/hostname"
 ```
 
+<!--
+The `requiredDuringSchedulingIgnoredDuringExecution` field tells the
+Kubernetes Scheduler that it should never co-locate two Pods which have `app` label
+as `zk` in the domain defined by the `topologyKey`. The `topologyKey`
+`kubernetes.io/hostname` indicates that the domain is an individual node. Using
+different rules, labels, and selectors, you can extend this technique to spread
+your ensemble across physical, network, and power failure domains.
+-->
 
-`requiredDuringSchedulingRequiredDuringExecution` 告诉 Kubernetes 调度器，在以 `topologyKey` 指定的域中，绝对不要把带有键为 `app`，值为 `zk` 的标签的两个 Pods 调度到相同的节点。`topologyKey`
-`kubernetes.io/hostname` 表示这个域是一个单独的节点。使用不同的 rules、labels 和 selectors，你能够通过这种技术把你的 ensemble 在物理、网络和电力故障域之间分布。
+`requiredDuringSchedulingIgnoredDuringExecution` 告诉 Kubernetes 调度器，在以 `topologyKey` 指定的域中，绝对不要把带有键为 `app`，值为 `zk` 的标签的两个 Pods 调度到相同的节点。`topologyKey`
+`kubernetes.io/hostname` 表示这个域是一个单独的节点。使用不同的 rules、labels 和 selectors，你能够通过这种技术把你的 ensemble 分布在不同的物理、网络和电力故障域之间。
 
+<!--
+## Surviving Maintenance
+
+**In this section you will cordon and drain nodes. If you are using this tutorial
+on a shared cluster, be sure that this will not adversely affect other tenants.**
+
+The previous section showed you how to spread your Pods across nodes to survive
+unplanned node failures, but you also need to plan for temporary node failures
+that occur due to planned maintenance.
+
+Use this command to get the nodes in your cluster.
+-->
 
 ## 存活管理
 
-
 **在本节中你将会 cordon 和 drain 节点。如果你是在一个共享的集群里使用本教程，请保证不会影响到其他租户**
 
-
-上一小节展示了如何在节点之间分散 Pods 以在计划外的节点故障时存活。但是你也需要为计划内维护引起的临时节点故障做准备。
-
+上一小节展示了如何在节点之间分散 Pods 以在计划外的节点故障时保证服务存活。但是你也需要为计划内维护引起的临时节点故障做准备。
 
 获取你集群中的节点。
 
@@ -948,58 +1290,88 @@ kubernetes-minion-group-2g2d
 kubectl get nodes
 ```
 
+<!--
+Use [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) to
+cordon all but four of the nodes in your cluster.
+-->
 
-使用 [`kubectl cordon`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#cordon) cordon 你的集群中除4个节点以外的所有节点。
+使用 [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) cordon 你的集群中除4个节点以外的所有节点。
 
 ```shell
 kubectl cordon < node name >
 ```
 
+<!--
+Use this command to get the `zk-pdb` `PodDisruptionBudget`.
+-->
 
-获取 `zk-budget` PodDisruptionBudget。
+获取 `zk-pdb` `PodDisruptionBudget`。
 
 ```shell
-kubectl get poddisruptionbudget zk-budget
+kubectl get pdb zk-pdb
 ```
 
+<!--
+The `max-unavailable` field indicates to Kubernetes that at most one Pod from
+`zk` `StatefulSet` can be unavailable at any time.
+-->
 
-`min-available` 字段指示 Kubernetes 在任何时候，`zk` StatefulSet 至少有两个 Pods 必须是可用的。
-
-```yaml
-NAME        MIN-AVAILABLE   ALLOWED-DISRUPTIONS   AGE
-zk-budget   2               1                     1h
+`max-unavailable` 字段指示 Kubernetes 在任何时候，`zk` `StatefulSet` 至多有一个 Pod 是不可用的。
 
+```
+NAME      MIN-AVAILABLE   MAX-UNAVAILABLE   ALLOWED-DISRUPTIONS   AGE
+zk-pdb    N/A             1                 1
 ```
 
+<!--
+In one terminal, use this command to watch the Pods in the `zk` `StatefulSet`.
+-->
 
-在一个终端观察 `zk` StatefulSet 中的 Pods。
+在一个终端观察 `zk` `StatefulSet` 中的 Pods。
 
 ```shell
 kubectl get pods -w -l app=zk
 ```
 
+<!--
+In another terminal, use this command to get the nodes that the Pods are currently scheduled on.
+-->
 
 在另一个终端获取 Pods 当前调度的节点。
 
 ```shell
 for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
-kubernetes-minion-group-pb41
-kubernetes-minion-group-ixsl
-kubernetes-minion-group-i4c4
-
 ```
 
-使用 [`kubectl drain`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#drain) 来 cordon 和 drain `zk-0` Pod 调度的节点。
+```
+kubernetes-node-pb41
+kubernetes-node-ixsl
+kubernetes-node-i4c4
+```
+
+<!--
+Use [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain) to cordon and
+drain the node on which the `zk-0` Pod is scheduled.
+-->
+
+使用 [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain) 来 cordon 和 drain `zk-0` Pod 调度的节点。
 
 ```shell
 kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
-node "kubernetes-minion-group-pb41" cordoned
-WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-pb41, kube-proxy-kubernetes-minion-group-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz
-pod "zk-0" deleted
-node "kubernetes-minion-group-pb41" drained
-
 ```
 
+```
+node "kubernetes-node-pb41" cordoned
+
+WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz
+pod "zk-0" deleted
+node "kubernetes-node-pb41" drained
+```
+
+<!--
+As there are four nodes in your cluster, `kubectl drain`, succeeds and the
+`zk-0` is rescheduled to another node.
+-->
 
 由于你的集群中有4个节点, `kubectl drain` 执行成功，`zk-0 被调度到其它节点。
 
@@ -1020,22 +1392,35 @@ zk-0      0/1       Running   0         51s
 zk-0      1/1       Running   0         1m
 ```
 
+<!--
+Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node on which
+`zk-1` is scheduled.
+-->
 
 在第一个终端持续观察 StatefulSet 的 Pods并 drain `zk-1` 调度的节点。
 
 ```shell
-kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-minion-group-ixsl" cordoned
-WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-ixsl, kube-proxy-kubernetes-minion-group-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
-pod "zk-1" deleted
-node "kubernetes-minion-group-ixsl" drained
-
+kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
 ```
 
+```
+WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
+pod "zk-1" deleted
+node "kubernetes-node-ixsl" drained
+```
+
+<!--
+The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing
+co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
+-->
 
 `zk-1` Pod 不能被调度。由于 `zk` StatefulSet 包含了一个防止 Pods 共存的 PodAntiAffinity 规则，而且只有两个节点可用于调度，这个 Pod 将保持在 Pending 状态。
 
 ```shell
 kubectl get pods -w -l app=zk
+```
+
+```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   2          1h
 zk-1      1/1       Running   0          1h
@@ -1058,23 +1443,35 @@ zk-1      0/1       Pending   0         0s
 zk-1      0/1       Pending   0         0s
 ```
 
+<!--
+Continue to watch the Pods of the stateful set, and drain the node on which
+`zk-2` is scheduled.
+-->
 
 继续观察 stateful set 的 Pods 并 drain `zk-2` 调度的节点。
 
 ```shell
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
-node "kubernetes-minion-group-i4c4" cordoned
-WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-i4c4, kube-proxy-kubernetes-minion-group-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
-WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-i4c4, kube-proxy-kubernetes-minion-group-i4c4
+```
+```
+node "kubernetes-node-i4c4" cordoned
+
+WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
+WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4
 There are pending pods when an error occurred: Cannot evict pod as it would violate the pod's disruption budget.
 pod/zk-2
-
 ```
 
+<!--
+Use `CTRL-C` to terminate to kubectl.
+
+You cannot drain the third node because evicting `zk-2` would violate `zk-budget`. However, the node will remain cordoned.
+
+Use `zkCli.sh` to retrieve the value you entered during the sanity test from `zk-0`.
+-->
 
 使用 `CRTL-C` 终止 kubectl。
 
-
 你不能 drain 第三个节点，因为删除 `zk-2` 将和 `zk-budget` 冲突。然而这个节点仍然保持 cordoned。
 
 
@@ -1084,6 +1481,9 @@ pod/zk-2
 kubectl exec zk-0 zkCli.sh get /hello
 ```
 
+<!--
+The service is still available because its `PodDisruptionBudget` is respected.
+-->
 
 由于遵守了 PodDisruptionBudget，服务仍然可用。
 
@@ -1103,19 +1503,29 @@ dataLength = 5
 numChildren = 0
 ```
 
+<!--
+Use [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#uncordon) to uncordon the first node.
+-->
 
-使用 [`kubectl uncordon`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#uncordon) 来取消对第一个节点的隔离。
+使用 [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#uncordon) 来取消对第一个节点的隔离。
 
 ```shell
-kubectl uncordon kubernetes-minion-group-pb41
-node "kubernetes-minion-group-pb41" uncordoned
+kubectl uncordon kubernetes-node-pb41
+```
+```
+node "kubernetes-node-pb41" uncordoned
 ```
 
+<!--
+`zk-1` is rescheduled on this node. Wait until `zk-1` is Running and Ready.
+-->
 
 `zk-1` 被重新调度到了这个节点。等待 `zk-1` 变为 Running 和 Ready 状态。
 
 ```shell
 kubectl get pods -w -l app=zk
+```
+```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   2          1h
 zk-1      1/1       Running   0          1h
@@ -1142,39 +1552,67 @@ zk-1      0/1       Running   0         13m
 zk-1      1/1       Running   0         13m
 ```
 
+<!--
+Attempt to drain the node on which `zk-2` is scheduled.
+-->
 
 尝试 drain  `zk-2` 调度的节点。
 
 ```shell
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
-node "kubernetes-minion-group-i4c4" already cordoned
-WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-i4c4, kube-proxy-kubernetes-minion-group-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
-pod "heapster-v1.2.0-2604621511-wht1r" deleted
-pod "zk-2" deleted
-node "kubernetes-minion-group-i4c4" drained
-
 ```
 
+<!--
+The output:
+-->
+
+输出：
+
+```
+node "kubernetes-node-i4c4" already cordoned
+WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
+pod "heapster-v1.2.0-2604621511-wht1r" deleted
+pod "zk-2" deleted
+node "kubernetes-node-i4c4" drained
+```
+
+<!--
+This time `kubectl drain` succeeds.
+
+Uncordon the second node to allow `zk-2` to be rescheduled.
+-->
 
 这次 `kubectl drain` 执行成功。
 
-
 Uncordon 第二个节点以允许 `zk-2` 被重新调度。
 
 ```shell
-kubectl uncordon kubernetes-minion-group-ixsl
-node "kubernetes-minion-group-ixsl" uncordoned
+kubectl uncordon kubernetes-node-ixsl
 ```
 
+```
+node "kubernetes-node-ixsl" uncordoned
+```
 
-你可以同时使用 `kubectl drain` 和 PodDisruptionBudgets 来保证你的服务在维护过程中仍然可用。如果使用 drain 来隔离节点并在此之前删除 pods 使节点进入离线维护状态，如果服务表达了 disruption budget，这个 budget 将被遵守。你应该总是为关键服务分配额外容量，这样它们的 Pods 就能够迅速的重新调度。
-
+<!--
+You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance.
+If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance,
+services that express a disruption budget will have that budget respected.
+You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled.
+-->
 
+你可以同时使用 `kubectl drain` 和 `PodDisruptionBudgets` 来保证你的服务在维护过程中仍然可用。如果使用了 drain 来隔离节点并在节点离线之前排出了 pods，那么表达了 disruption budget 的服务将会遵守该 budget。你应该总是为关键服务分配额外容量，这样它们的 Pods 就能够迅速的重新调度。
 
 ## {{% heading "cleanup" %}}
 
 
+<!--
+- Use `kubectl uncordon` to uncordon all the nodes in your cluster.
+- You will need to delete the persistent storage media for the PersistentVolumes
+  used in this tutorial. Follow the necessary steps, based on your environment,
+  storage configuration, and provisioning method, to ensure that all storage is
+  reclaimed.
+-->
+
 * 使用 `kubectl uncordon` 解除你集群中所有节点的隔离。
 * 你需要删除在本教程中使用的 PersistentVolumes 的持久存储媒介。请遵循必须的步骤，基于你的环境、存储配置和准备方法，保证回收所有的存储。
-
-
diff --git a/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md
index 4a4d7779e2..25cb862660 100644
--- a/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -3,13 +3,10 @@ title: 公开外部 IP 地址以访问集群中应用程序
 content_type: tutorial
 weight: 10
 ---
-
 <!--
----
 title: Exposing an External IP Address to Access an Application in a Cluster
 content_type: tutorial
 weight: 10
----
 -->
 
 <!-- overview -->
@@ -20,12 +17,8 @@ external IP address.
 -->
 此页面显示如何创建公开外部 IP 地址的 Kubernetes 服务对象。
 
-
-
-
 ## {{% heading "prerequisites" %}}
 
-
 <!--
  * Install [kubectl](/docs/tasks/tools/install-kubectl/).
 
@@ -40,30 +33,23 @@ external IP address.
 
  * 安装 [kubectl](/zh/docs/tasks/tools/install-kubectl/).
 
- * 使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 群集。
- 本教程创建了一个[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，需要云供应商。
+ * 使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 集群。
+   本教程创建了一个[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，
+   需要云供应商。
 
  * 配置 `kubectl` 与 Kubernetes API 服务器通信。有关说明，请参阅云供应商文档。
 
-
-
-
 ## {{% heading "objectives" %}}
 
-
 <!--
 * Run five instances of a Hello World application.
 * Create a Service object that exposes an external IP address.
 * Use the Service object to access the running application.
 -->
-
 * 运行 Hello World 应用程序的五个实例。
 * 创建一个公开外部 IP 地址的 Service 对象。
 * 使用 Service 对象访问正在运行的应用程序。
 
-
-
-
 <!-- lessoncontent -->
 
 <!--
@@ -77,118 +63,130 @@ external IP address.
 -->
 1. 在集群中运行 Hello World 应用程序：
 
-{{< codenew file="service/load-balancer-example.yaml" >}}
+   {{< codenew file="service/load-balancer-example.yaml" >}}
 
-```shell
-kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
-```
+   ```shell
+   kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
+   ```
 
-<!--
-    The preceding command creates a
-    [Deployment](/docs/concepts/workloads/controllers/deployment/)
-    object and an associated
-    [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-    object. The ReplicaSet has five
-    [Pods](/docs/concepts/workloads/pods/pod/),
-    each of which runs the Hello World application.
--->
-   前面的命令创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)
-   对象和一个关联的 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)对象。
-   ReplicaSet 有五个 [Pod](/zh/docs/concepts/workloads/pods/pod/)，每个都运行 Hello World 应用程序。
+   <!--
+   The preceding command creates a
+   {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+   and an associated
+   {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
+   The ReplicaSet has five
+   {{< glossary_tooltip text="Pods" term_id="pod" >}}
+   each of which runs the Hello World application.
+   -->
+   前面的命令创建一个
+   {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+   对象和一个关联的
+   {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} 对象。
+   ReplicaSet 有五个 {{< glossary_tooltip text="Pods" term_id="pod" >}}，
+   每个都运行 Hello World 应用程序。
 
 <!--
 1. Display information about the Deployment:
 -->
 2. 显示有关 Deployment 的信息：
 
-        kubectl get deployments hello-world
-        kubectl describe deployments hello-world
+   ```shell
+   kubectl get deployments hello-world
+   kubectl describe deployments hello-world
+   ```
 
 <!--
 1. Display information about your ReplicaSet objects:
 -->
 3. 显示有关 ReplicaSet 对象的信息：
 
-        kubectl get replicasets
-        kubectl describe replicasets
+   ```shell
+   kubectl get replicasets
+   kubectl describe replicasets
+   ```
 
 <!--
 1. Create a Service object that exposes the deployment:
 -->
-4. 创建公开 deployment 的 Service 对象：
+4. 创建公开 Deployment 的 Service 对象：
 
-        kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
+   ```shell
+   kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
+   ```
 
 <!--
 1. Display information about the Service:
 -->
 5. 显示有关 Service 的信息：
 
-        kubectl get services my-service
+   ```shell
+   kubectl get services my-service
+   ```
 
-<!--
+   <!--
    The output is similar to this:
--->
+   -->
    输出类似于：
 
-        NAME         TYPE        CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
-        my-service   ClusterIP   10.3.245.137   104.198.205.71   8080/TCP   54s
+   ```
+   NAME         TYPE        CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
+   my-service   ClusterIP   10.3.245.137   104.198.205.71   8080/TCP   54s
+   ```
 
-<!--
-{{< note >}}
+   <!--
+   {{< note >}}
+   The `type=LoadBalancer` service is backed by external cloud providers, which is not covered in this example, please refer to [this page](/docs/concepts/services-networking/service/#loadbalancer) for the details.
+   {{< /note >}}
+   -->
+   提示：`type=LoadBalancer` 服务由外部云服务提供商提供支持，本例中不包含此部分，
+   详细信息请参考[此页](/docs/concepts/services-networking/service/#loadbalancer)
 
-The `type=LoadBalancer` service is backed by external cloud providers, which is not covered in this example, please refer to [this page](/docs/concepts/services-networking/service/#loadbalancer) for the details.
-
-{{< /note >}}
--->
-   注意：`type=LoadBalancer` 服务由外部云服务提供商提供支持，本例中不包含此部分，详细信息请参考[此页](/docs/concepts/services-networking/service/#loadbalancer)
-
-<!--
-{{< note >}}
-
-If the external IP address is shown as \<pending\>, wait for a minute and enter the same command again.
-
-{{< /note >}}
--->
-   注意：如果外部 IP 地址显示为 \<pending\>，请等待一分钟再次输入相同的命令。
+   <!--
+   {{< note >}}
+   If the external IP address is shown as \<pending\>, wait for a minute and enter the same command again.
+   {{< /note >}}
+   -->
+   提示：如果外部 IP 地址显示为 \<pending\>，请等待一分钟再次输入相同的命令。
 
 <!--
 1. Display detailed information about the Service:
 -->
 6. 显示有关 Service 的详细信息：
 
-        kubectl describe services my-service
+   ```shell
+   kubectl describe services my-service
+   ```
 
-<!--
+   <!--
    The output is similar to this:
--->
+   -->
    输出类似于：
 
-        Name:           my-service
-        Namespace:      default
-        Labels:         run=load-balancer-example
-        Annotations:    <none>
-        Selector:       run=load-balancer-example
-        Type:           LoadBalancer
-        IP:             10.3.245.137
-        LoadBalancer Ingress:   104.198.205.71
-        Port:           <unset> 8080/TCP
-        NodePort:       <unset> 32377/TCP
-        Endpoints:      10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
-        Session Affinity:   None
-        Events:         <none>
-
-<!--
+   ```
+   Name:           my-service
+   Namespace:      default
+   Labels:         run=load-balancer-example
+   Annotations:    <none>
+   Selector:       run=load-balancer-example
+   Type:           LoadBalancer
+   IP:             10.3.245.137
+   LoadBalancer Ingress:   104.198.205.71
+   Port:           <unset> 8080/TCP
+   NodePort:       <unset> 32377/TCP
+   Endpoints:      10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
+   Session Affinity:   None
+   Events:         <none>
+   ```
+   <!--
    Make a note of the external IP address (`LoadBalancer Ingress`) exposed by
    your service. In this example, the external IP address is 104.198.205.71.
    Also note the value of `Port` and `NodePort`. In this example, the `Port`
    is 8080 and the `NodePort` is 32377.
--->
+   -->
    记下服务公开的外部 IP 地址（`LoadBalancer Ingress`)。
    在本例中，外部 IP 地址是 104.198.205.71。还要注意 `Port` 和 `NodePort` 的值。
    在本例中，`Port` 是 8080，`NodePort` 是32377。
 
-
 <!--
 1. In the preceding output, you can see that the service has several endpoints:
    10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more. These are internal
@@ -200,58 +198,63 @@ If the external IP address is shown as \<pending\>, wait for a minute and enter
    这些都是正在运行 Hello World 应用程序的 pod 的内部地址。
    要验证这些是 pod 地址，请输入以下命令：
 
-        kubectl get pods --output=wide
+   ```shell
+   kubectl get pods --output=wide
+   ```
 
-<!--
+   <!--
    The output is similar to this:
--->
+   -->
    输出类似于：
 
-        NAME                         ...  IP         NODE
-        hello-world-2895499144-1jaz9 ...  10.0.1.6   gke-cluster-1-default-pool-e0b8d269-1afc
-        hello-world-2895499144-2e5uh ...  10.0.1.8   gke-cluster-1-default-pool-e0b8d269-1afc
-        hello-world-2895499144-9m4h1 ...  10.0.0.6   gke-cluster-1-default-pool-e0b8d269-5v7a
-        hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc
-        hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc
-
+   ```
+   NAME                         ...  IP         NODE
+   hello-world-2895499144-1jaz9 ...  10.0.1.6   gke-cluster-1-default-pool-e0b8d269-1afc
+   hello-world-2895499144-2e5uh ...  10.0.1.8   gke-cluster-1-default-pool-e0b8d269-1afc
+   hello-world-2895499144-9m4h1 ...  10.0.0.6   gke-cluster-1-default-pool-e0b8d269-5v7a
+   hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc
+   hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc
+   ```
 <!--
 1. Use the external IP address (`LoadBalancer Ingress`) to access the Hello
    World application:
 -->
 8. 使用外部 IP 地址（`LoadBalancer Ingress`）访问 Hello World 应用程序:
 
-        curl http://<external-ip>:<port>
+   ```shell
+   curl http://<external-ip>:<port>
+   ```
 
-<!--
+   <!--
    where `<external-ip>` is the external IP address (`LoadBalancer Ingress`)
    of your Service, and `<port>` is the value of `Port` in your Service
    description.
    If you are using minikube, typing `minikube service my-service` will
    automatically open the Hello World application in a browser.
--->
+   -->
    其中 `<external-ip>` 是您的服务的外部 IP 地址（`LoadBalancer Ingress`），
    `<port>` 是您的服务描述中的 `port` 的值。
    如果您正在使用 minikube，输入 `minikube service my-service` 将在浏览器中自动打开 Hello World 应用程序。
 
-<!--
+   <!--
    The response to a successful request is a hello message:
--->
+   -->
    成功请求的响应是一条问候消息：
 
-        Hello Kubernetes!
-
-
-
+   ```
+   Hello Kubernetes!
+   ```
 
 ## {{% heading "cleanup" %}}
 
-
 <!--
 To delete the Service, enter this command:
 -->
 要删除服务，请输入以下命令：
 
-        kubectl delete services my-service
+```shell
+kubectl delete services my-service
+```
 
 <!--
 To delete the Deployment, the ReplicaSet, and the Pods that are running
@@ -259,19 +262,15 @@ the Hello World application, enter this command:
 -->
 要删除正在运行 Hello World 应用程序的 Deployment，ReplicaSet 和 Pod，请输入以下命令：
 
-        kubectl delete deployment hello-world
-
-
-
+```shell
+kubectl delete deployment hello-world
+```
 
 ## {{% heading "whatsnext" %}}
 
-
 <!--
 Learn more about
 [connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
 -->
-
-了解更多关于[将应用程序与服务连接](/zh/docs/concepts/services-networking/connect-applications-service/)。
-
+进一步了解[将应用程序与服务连接](/zh/docs/concepts/services-networking/connect-applications-service/)。
 
diff --git a/content/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
new file mode 100644
index 0000000000..d1f888475e
--- /dev/null
+++ b/content/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
@@ -0,0 +1,722 @@
+---
+title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例"
+content_type: tutorial
+weight: 21
+card:
+  name: tutorials
+  weight: 31
+  title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例"
+---
+<!-- 
+title: "Example: Add logging and metrics to the PHP / Redis Guestbook example"
+reviewers:
+- sftim
+content_type: tutorial
+weight: 21
+card:
+  name: tutorials
+  weight: 31
+  title: "Example: Add logging and metrics to the PHP / Redis Guestbook example"
+-->
+
+<!-- overview -->
+<!-- 
+This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. Lightweight log, metric, and network data open source shippers, or *Beats*, from Elastic are deployed in the same Kubernetes cluster as the guestbook. The Beats collect, parse, and index the data into Elasticsearch so that you can view and analyze the resulting operational information in Kibana. This example consists of the following components:
+
+* A running instance of the [PHP Guestbook with Redis tutorial](/docs/tutorials/stateless-application/guestbook)
+* Elasticsearch and Kibana
+* Filebeat
+* Metricbeat
+* Packetbeat
+-->
+本教程建立在
+[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 教程之上。
+*Beats*，是 Elastic 出品的开源的轻量级日志、指标和网络数据采集器，
+将和 Guestbook 一同部署在 Kubernetes 集群中。
+Beats 收集、分析、索引数据到 Elasticsearch，使你可以用 Kibana 查看并分析得到的运营信息。
+本示例由以下内容组成：
+
+* Elasticsearch 和 Kibana
+* Filebeat
+* Metricbeat
+* Packetbeat
+
+## {{% heading "objectives" %}}
+
+<!-- 
+* Start up the PHP Guestbook with Redis.
+* Install kube-state-metrics.
+* Create a Kubernetes Secret.
+* Deploy the Beats.
+* View dashboards of your logs and metrics.
+-->
+* 启动用 Redis 部署的 PHP Guestbook。
+* 安装 kube-state-metrics。
+* 创建 Kubernetes secret。
+* 部署 Beats。
+* 用仪表板查看日志和指标。
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+{{< version-check >}}
+
+<!-- 
+Additionally you need:
+
+* A running deployment of the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.
+
+* A running Elasticsearch and Kibana deployment.  You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co), 
+  run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) 
+  on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
+-->
+此外，你还需要:
+
+* 依照教程[使用 Redis 的 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook)得到的一套运行中的部署环境。
+* 一套运行中的 Elasticsearch 和 Kibana 部署环境。你可以使用 [Elastic 云中的Elasticsearch 服务](https://cloud.elastic.co)、在工作站或者服务器上运行此[下载文件](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)、或运行 [Elastic Helm Charts](https://github.com/elastic/helm-charts)。
+
+<!-- lessoncontent -->
+
+<!-- 
+## Start up the  PHP Guestbook with Redis
+
+This tutorial builds on the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.  If you have the guestbook application running, then you can monitor that.  If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps.  Come back to this page when you have the guestbook running.
+-->
+## 启动用 Redis 部署的 PHP Guestbook {#start-up-the-php-guestbook-with-redis}
+
+本教程建立在
+[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 之上。
+如果你已经有一个运行的 Guestbook 应用程序，那就监控它。
+如果还没有，那就按照说明先部署 Guestbook ，但不要执行**清理**的步骤。
+当 Guestbook 运行起来后，再返回本页。
+
+<!-- 
+## Add a Cluster role binding
+
+Create a [cluster level role binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) so that you can deploy kube-state-metrics and the Beats at the cluster level (in kube-system).
+-->
+## 添加一个集群角色绑定 {#add-a-cluster-role-binding}
+
+创建一个[集群范围的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#rolebinding-和-clusterrolebinding)，
+以便你可以在集群范围（在 kube-system 中）部署 kube-state-metrics 和 Beats。
+
+```shell
+kubectl create clusterrolebinding cluster-admin-binding \
+ --clusterrole=cluster-admin --user=<your email associated with the k8s provider account>
+```
+
+<!-- 
+## Install kube-state-metrics
+
+Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics) is a simple service that listens to the Kubernetes API server and generates metrics about the state of the objects.  Metricbeat reports these metrics.  Add kube-state-metrics to the Kubernetes cluster that the guestbook is running in.
+--> 
+### 安装 kube-state-metrics {#install-kube-state-metrics}
+
+Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)
+是一个简单的服务，它侦听 Kubernetes API 服务器并生成对象状态的指标。
+Metricbeat 报告这些指标。
+添加 kube-state-metrics 到运行 Guestbook 的 Kubernetes 集群。
+
+```shell
+git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
+kubectl apply -f kube-state-metrics/examples/standard
+```
+
+<!-- 
+### Check to see if kube-state-metrics is running
+-->
+### 检查 kube-state-metrics 是否正在运行 {#check-to-see-if-kube-state-metrics-is-running}
+
+```shell
+kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
+```
+
+<!-- 
+Output:
+-->
+输出：
+
+```
+NAME                                 READY   STATUS    RESTARTS   AGE
+kube-state-metrics-89d656bf8-vdthm   1/1     Running     0          21s
+```
+
+<!-- 
+## Clone the Elastic examples GitHub repo
+-->
+## 从 GitHub 克隆 Elastic examples  库 {#clone-the-elastic-examples-github-repo}
+
+```shell
+git clone https://github.com/elastic/examples.git
+```
+
+<!-- 
+The rest of the commands will reference files in the `examples/beats-k8s-send-anywhere` directory, so change dir there:
+-->
+后续命令将引用目录 `examples/beats-k8s-send-anywhere` 中的文件，
+所以把目录切换过去。
+
+```shell
+cd examples/beats-k8s-send-anywhere
+```
+
+<!-- 
+## Create a Kubernetes Secret
+A Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}} is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image; putting it in a Secret object allows for more control over how it is used, and reduces the risk of accidental exposure.
+
+There are two sets of steps here, one for *self managed* Elasticsearch and Kibana (running on your servers or using the Elastic Helm Charts), and a second separate set for the *managed service* Elasticsearch Service in Elastic Cloud.  Only create the secret for the type of Elasticsearch and Kibana system that you will use for this tutorial.
+-->
+## 创建 Kubernetes Secret {#create-a-kubernetes-secret}
+
+Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}}
+是包含少量敏感数据（类似密码、令牌、秘钥等）的对象。
+这类信息也可以放在 Pod 规格定义或者镜像中；
+但放在 Secret 对象中，能更好的控制它的使用方式，也能减少意外泄露的风险。
+
+{{< note >}}
+这里有两套步骤，一套用于*自管理*的 Elasticsearch 和 Kibana（运行在你的服务器上或使用 Helm Charts），
+另一套用于在 Elastic 云服务中 *Managed service* 的 Elasticsearch 服务。
+在本教程中，只需要为 Elasticsearch 和 Kibana 系统创建 secret。
+{{< /note >}}
+
+{{< tabs name="tab_with_md" >}}
+{{% tab name="自管理" %}}
+
+<!-- 
+### Self managed
+Switch to the **Managed service** tab if you are connecting to Elasticsearch Service in Elastic Cloud.
+
+### Set the credentials
+There are four files to edit to create a k8s secret when you are connecting to self managed Elasticsearch and Kibana (self managed is effectively anything other than the managed Elasticsearch Service in Elastic Cloud).  The files are:
+-->
+### 自管理系统 {#self-managed}
+
+如果你使用 Elastic 云中的 Elasticsearch 服务，切换到 **Managed service** 标签页。
+
+### 设置凭据 {#set-the-credentials}
+
+当你使用自管理的 Elasticsearch 和 Kibana （对比托管于 Elastic 云中的 Elasticsearch 服务，自管理更有效率），
+创建 k8s secret 需要准备四个文件。这些文件是：
+
+1. `ELASTICSEARCH_HOSTS`
+1. `ELASTICSEARCH_PASSWORD`
+1. `ELASTICSEARCH_USERNAME`
+1. `KIBANA_HOST`
+
+<!-- 
+Set these with the information for your Elasticsearch cluster and your Kibana host.  Here are some examples (also see [*this configuration*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897))
+-->
+为你的 Elasticsearch 集群和 Kibana 主机设置这些信息。这里是一些例子
+（另见[*此配置*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)）
+
+#### `ELASTICSEARCH_HOSTS` {#elasticsearch-hosts}
+
+<!-- 
+1. A nodeGroup from the Elastic Elasticsearch Helm Chart:
+-->
+1. 来自于 Elastic Elasticsearch Helm Chart 的节点组：
+
+    ```
+    ["http://elasticsearch-master.default.svc.cluster.local:9200"]
+    ```
+
+   <!-- 
+   1. A single Elasticsearch node running on a Mac where your Beats are running in Docker for Mac:
+   -->
+1. Mac 上的单节点的 Elasticsearch，Beats 运行在 Mac 的容器中：
+
+    ```
+    ["http://host.docker.internal:9200"]
+    ```
+
+    <!--  
+    1. Two Elasticsearch nodes running in VMs or on physical hardware:
+    -->
+1. 运行在虚拟机或物理机上的两个 Elasticsearch 节点
+
+    ```
+    ["http://host1.example.com:9200", "http://host2.example.com:9200"]
+    ```
+
+<!-- 
+Edit `ELASTICSEARCH_HOSTS`
+-->
+编辑 `ELASTICSEARCH_HOSTS`
+```shell
+vi ELASTICSEARCH_HOSTS
+```
+
+#### `ELASTICSEARCH_PASSWORD` {#elasticsearch-password}
+
+<!-- 
+Just the password; no whitespace, quotes, or <>:
+-->
+只有密码；没有空格、引号、< 和 >：
+
+```
+<yoursecretpassword>
+```
+
+<!-- 
+Edit `ELASTICSEARCH_PASSWORD`
+-->
+编辑 `ELASTICSEARCH_PASSWORD`：
+
+```shell
+vi ELASTICSEARCH_PASSWORD
+```
+
+#### `ELASTICSEARCH_USERNAME` {#elasticsearch-username}
+
+<!-- 
+Just the username; no whitespace, quotes, or <>:
+-->
+只有用名；没有空格、引号、< 和 >：
+
+<!-- 
+your ingest username for Elasticsearch
+-->
+```
+<为 Elasticsearch 注入的用户名>
+```
+
+<!-- 
+Edit `ELASTICSEARCH_USERNAME`
+-->
+编辑 `ELASTICSEARCH_USERNAME`：
+
+```shell
+vi ELASTICSEARCH_USERNAME
+```
+
+#### `KIBANA_HOST` {#kibana-host}
+
+<!-- 
+1. The Kibana instance from the Elastic Kibana Helm Chart.  The subdomain `default` refers to the default namespace.  If you have deployed the Helm Chart using a different namespace, then your subdomain will be different:
+-->
+1. 从 Elastic Kibana Helm Chart 安装的 Kibana 实例。子域 `default` 指默认的命名空间。如果你把 Helm Chart 指定部署到不同的命名空间，那子域会不同： 
+
+    ```
+    "kibana-kibana.default.svc.cluster.local:5601"
+    ```
+
+    <!-- 
+    1. A Kibana instance running on a Mac where your Beats are running in Docker for Mac:
+    -->
+1. Mac 上的 Kibana 实例，Beats 运行于 Mac 的容器：
+
+    ```
+    "host.docker.internal:5601"
+    ```
+    
+    <!-- 
+      1. Two Elasticsearch nodes running in VMs or on physical hardware:
+    -->
+1. 运行于虚拟机或物理机上的两个 Elasticsearch 节点：
+
+    ```
+    "host1.example.com:5601"
+    ```
+
+<!-- 
+Edit `KIBANA_HOST`
+-->
+编辑 `KIBANA_HOST`：
+
+```shell
+vi KIBANA_HOST
+```
+
+<!-- 
+### Create a Kubernetes secret
+This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
+-->
+### 创建 Kubernetes secret {#create-a-kubernetes-secret}
+
+在上面编辑完的文件的基础上，本命令在 Kubernetes 系统范围的命名空间（kube-system）创建一个 secret。
+
+```
+    kubectl create secret generic dynamic-logging \
+      --from-file=./ELASTICSEARCH_HOSTS \
+      --from-file=./ELASTICSEARCH_PASSWORD \
+      --from-file=./ELASTICSEARCH_USERNAME \
+      --from-file=./KIBANA_HOST \
+      --namespace=kube-system
+```
+
+{{% /tab %}}
+{{% tab name="Managed service" %}}
+
+<!-- 
+## Managed service
+This tab is for Elasticsearch Service in Elastic Cloud only, if you have already created a secret for a self managed Elasticsearch and Kibana deployment, then continue with [Deploy the Beats](#deploy-the-beats).
+### Set the credentials
+There are two files to edit to create a k8s secret when you are connecting to the managed Elasticsearch Service in Elastic Cloud.  The files are:
+-->
+## Managed service {#managed-service}
+
+本标签页只用于 Elastic 云 的 Elasticsearch 服务，如果你已经为自管理的 Elasticsearch 和 Kibana 创建了secret，请继续[部署 Beats](#deploy-the-beats)并继续。
+
+### 设置凭据 {#set-the-credentials}
+
+在 Elastic 云中的托管 Elasticsearch 服务中，为了创建 k8s secret，你需要先编辑两个文件。它们是：
+
+1. `ELASTIC_CLOUD_AUTH`
+1. `ELASTIC_CLOUD_ID`
+
+<!-- 
+Set these with the information provided to you from the Elasticsearch Service console when you created the deployment.  Here are some examples:
+-->
+当你完成部署的时候，Elasticsearch 服务控制台会提供给你一些信息，用这些信息完成设置。
+这里是一些示例：
+
+#### ELASTIC_CLOUD_ID {#elastic-cloud-id}
+
+```
+devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
+```
+
+#### ELASTIC_CLOUD_AUTH {#elastic-cloud-auth}
+
+<!-- 
+Just the username, a colon (`:`), and the password, no whitespace or quotes:
+-->
+只要用户名；没有空格、引号、< 和 >：
+
+```
+elastic:VFxJJf9Tjwer90wnfTghsn8w
+```
+
+<!-- 
+### Edit the required files:
+-->
+### 编辑要求的文件 {#edit-the-required-files}
+```shell
+vi ELASTIC_CLOUD_ID
+vi ELASTIC_CLOUD_AUTH
+```
+
+<!-- 
+### Create a Kubernetes secret
+This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
+-->
+### 创建 Kubernetes secret {#create-a-kubernetes-secret}
+
+基于上面刚编辑过的文件，在 Kubernetes 系统范围命名空间（kube-system）中，用下面命令创建一个的secret：
+
+    kubectl create secret generic dynamic-logging \
+      --from-file=./ELASTIC_CLOUD_ID \
+      --from-file=./ELASTIC_CLOUD_AUTH \
+      --namespace=kube-system
+
+  {{% /tab %}}
+{{< /tabs >}}
+
+<!-- 
+## Deploy the Beats
+Manifest files are provided for each Beat.  These manifest files use the secret created earlier to configure the Beats to connect to your Elasticsearch and Kibana servers.
+
+### About Filebeat
+Filebeat will collect logs from the Kubernetes nodes and the containers running in each pod running on those nodes.  Filebeat is deployed as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.  Filebeat can autodiscover applications running in your Kubernetes cluster. At startup Filebeat scans existing containers and launches the proper configurations for them, then it will watch for new start/stop events.
+
+Here is the autodiscover configuration that enables Filebeat to locate and parse Redis logs from the Redis containers deployed with the guestbook application.  This configuration is in the file `filebeat-kubernetes.yaml`:
+-->
+## 部署 Beats {#deploy-the-beats}
+
+为每一个 Beat 提供 清单文件。清单文件使用已创建的 secret 接入 Elasticsearch 和 Kibana 服务器。
+
+### 关于 Filebeat {#about-filebeat}
+
+Filebeat 收集日志，日志来源于 Kubernetes 节点以及这些节点上每一个 Pod 中的容器。Filebeat 部署为
+{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。
+Filebeat 支持自动发现 Kubernetes 集群中的应用。
+在启动时，Filebeat 扫描存量的容器，并为它们提供适当的配置，
+然后开始监听新的启动/中止信号。
+
+下面是一个自动发现的配置，它支持 Filebeat 定位并分析来自于 Guestbook 应用部署的 Redis 容器的日志文件。
+下面的配置片段来自文件 `filebeat-kubernetes.yaml`：
+
+```yaml
+- condition.contains:
+    kubernetes.labels.app: redis
+  config:
+    - module: redis
+      log:
+        input:
+          type: docker
+          containers.ids:
+            - ${data.kubernetes.container.id}
+      slowlog:
+        enabled: true
+        var.hosts: ["${data.host}:${data.port}"]
+```
+
+<!-- 
+This configures Filebeat to apply the Filebeat module `redis` when a container is detected with a label `app` containing the string `redis`.  The redis module has the ability to collect the `log` stream from the container by using the docker input type (reading the file on the Kubernetes node associated with the STDOUT stream from this Redis container).  Additionally, the module has the ability to collect Redis `slowlog` entries by connecting to the proper pod host and port, which is provided in the container metadata.
+
+### Deploy Filebeat:
+-->
+
+这样配置 Filebeat，当探测到容器拥有 `app` 标签，且值为 `redis`，那就启用 Filebeat 的 `redis` 模块。
+`redis` 模块可以根据 docker 的输入类型（在 Kubernetes 节点上读取和 Redis 容器的标准输出流关联的文件） ，从容器收集 `log` 流。
+另外，此模块还可以使用容器元数据中提供的配置信息，连到 Pod 适当的主机和端口，收集 Redis 的 `slowlog` 。
+
+### 部署 Filebeat {#deploy-filebeat}
+
+```shell
+kubectl create -f filebeat-kubernetes.yaml
+```
+
+<!-- 
+#### Verify
+-->
+#### 验证 {#verify}
+
+```shell
+kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
+```
+
+<!-- 
+### About Metricbeat
+Metricbeat autodiscover is configured in the same way as Filebeat.  Here is the Metricbeat autodiscover configuration for the Redis containers.  This configuration is in the file `metricbeat-kubernetes.yaml`:
+-->
+### 关于 Metricbeat {#about-metricbeat}
+
+Metricbeat 自动发现的配置方式与 Filebeat 完全相同。
+这里是针对 Redis 容器的 Metricbeat 自动发现配置。
+此配置片段来自于文件 `metricbeat-kubernetes.yaml`：
+
+```yaml
+- condition.equals:
+    kubernetes.labels.tier: backend
+  config:
+    - module: redis
+      metricsets: ["info", "keyspace"]
+      period: 10s
+
+      # Redis hosts
+      hosts: ["${data.host}:${data.port}"]
+```
+<!-- 
+This configures Metricbeat to apply the Metricbeat module `redis` when a container is detected with a label `tier` equal to the string `backend`.  The `redis` module has the ability to collect the `info` and `keyspace` metrics from the container by connecting to the proper pod host and port, which is provided in the container metadata.
+
+### Deploy Metricbeat
+-->
+配置 Metricbeat，在探测到标签 `tier` 的值等于 `backend` 时，应用 Metricbeat 模块 `redis`。
+`redis` 模块可以获取容器元数据，连接到 Pod 适当的主机和端口，从 Pod 中收集指标 `info` 和 `keyspace`。
+
+### 部署 Metricbeat {#deploy-metricbeat}
+
+```shell
+kubectl create -f metricbeat-kubernetes.yaml
+```
+
+<!-- 
+#### Verify
+-->
+#### 验证 {#verify2}
+
+```shell
+kubectl get pods -n kube-system -l k8s-app=metricbeat
+```
+
+<!-- 
+### About Packetbeat
+Packetbeat configuration is different than Filebeat and Metricbeat.  Rather than specify patterns to match against container labels the configuration is based on the protocols and port numbers involved.  Shown below is a subset of the port numbers.
+
+If you are running a service on a non-standard port add that port number to the appropriate type in `filebeat.yaml` and delete / create the Packetbeat DaemonSet.
+-->
+### 关于 Packetbeat {#about-packetbeat}
+
+Packetbeat 的配置方式不同于 Filebeat 和 Metricbeat。
+相比于匹配容器标签的模式，它的配置基于相关协议和端口号。
+下面展示的是端口号的一个子集：
+
+{{< note >}}
+如果你的服务运行在非标准的端口上，那就打开文件 `filebeat.yaml`，把这个端口号添加到合适的类型中，然后删除/启动 Packetbeat 的守护进程。
+{{< /note >}}
+
+```yaml
+packetbeat.interfaces.device: any
+
+packetbeat.protocols:
+- type: dns
+  ports: [53]
+  include_authorities: true
+  include_additionals: true
+
+- type: http
+  ports: [80, 8000, 8080, 9200]
+
+- type: mysql
+  ports: [3306]
+
+- type: redis
+  ports: [6379]
+
+packetbeat.flows:
+  timeout: 30s
+  period: 10s
+```
+
+<!-- 
+#### Deploy Packetbeat
+-->
+### 部署 Packetbeat {#deploy-packetbeat}
+
+```shell
+kubectl create -f packetbeat-kubernetes.yaml
+```
+
+<!-- 
+#### Verify
+-->
+#### 验证 {#verify3}
+
+```shell
+kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
+```
+
+<!-- 
+## View in Kibana
+
+Open Kibana in your browser and then open the **Dashboard** application.  In the search bar type Kubernetes and click on the Metricbeat dashboard for Kubernetes.  This dashboard reports on the state of your Nodes, deployments, etc.
+
+Search for Packetbeat on the Dashboard page, and view the Packetbeat overview.
+
+Similarly, view dashboards for Apache and Redis.  You will see dashboards for logs and metrics for each.  The Apache Metricbeat dashboard will be blank.  Look at the Apache Filebeat dashboard and scroll to the bottom to view the Apache error logs.  This will tell you why there are no metrics available for Apache.
+
+To enable Metricbeat to retrieve the Apache metrics, enable server-status by adding a ConfigMap including a mod-status configuration file and re-deploy the guestbook.
+
+
+## Scale your deployments and see new pods being monitored
+List the existing deployments:
+-->
+## 在 kibana 中浏览 {#view-in-kibana}
+
+在浏览器中打开 kibana，再打开 **Dashboard**。
+在搜索栏中键入 Kubernetes，再点击 Metricbeat 的 Kubernetes Dashboard。
+此 Dashboard 展示节点状态、应用部署等。
+
+在 Dashboard 页面，搜索 Packetbeat，并浏览 Packetbeat 概览信息。
+
+同样地，浏览 Apache 和 Redis 的 Dashboard。
+可以看到日志和指标各自独立 Dashboard。
+Apache Metricbeat Dashboard 是空的。
+找到 Apache Filebeat Dashboard，拉到最下面，查看 Apache 的错误日志。
+日志会揭示出没有 Apache 指标的原因。
+
+要让 metricbeat 得到 Apache 的指标，需要添加一个包含模块状态配置文件的 ConfigMap，并重新部署 Guestbook。
+
+## 缩放部署规模，查看新 Pod 已被监控 {#scale-your-deployments-and-see-new-pods-being-monitored}
+
+列出现有的 deployments：
+
+```shell
+kubectl get deployments
+```
+
+<!-- 
+The output:
+-->
+输出：
+
+```
+NAME            READY   UP-TO-DATE   AVAILABLE   AGE
+frontend        3/3     3            3           3h27m
+redis-master    1/1     1            1           3h27m
+redis-slave     2/2     2            2           3h27m
+```
+
+<!-- 
+Scale the frontend down to two pods:
+-->
+缩放前端到两个 Pod：
+
+```shell
+kubectl scale --replicas=2 deployment/frontend
+```
+
+<!-- 
+The output:
+ -->
+输出：
+
+```
+deployment.extensions/frontend scaled
+```
+
+<!-- 
+Scale the frontend back up to three pods:
+-->
+将前端应用缩放回三个 Pod：
+
+```shell
+kubectl scale --replicas=3 deployment/frontend
+```
+
+<!-- 
+## View the changes in Kibana
+See the screenshot, add the indicated filters and then add the columns to the view.  You can see the ScalingReplicaSet entry that is marked, following from there to the top of the list of events shows the image being pulled, the volumes mounted, the pod starting, etc.
+![Kibana Discover](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png)
+-->
+## 在 Kibana 中查看变化 {#view-the-chagnes-in-kibana}
+
+参见屏幕截图，添加指定的过滤器，然后将列添加到视图。
+你可以看到，ScalingReplicaSet 被做了标记，从标记的点开始，到消息列表的顶部，展示了拉取的镜像、挂载的卷、启动的 Pod 等。
+![Kibana 发现](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png)
+
+## {{% heading "cleanup" %}}
+
+<!-- 
+Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command.
+
+1. Run the following commands to delete all Pods, Deployments, and Services.
+-->
+删除 Deployments 和 Services， 删除运行的 Pod。
+用标签功能在一个命令中删除多个资源。
+
+1. 执行下列命令，删除所有的 Pod、Deployment 和 Services。
+
+      ```shell
+      kubectl delete deployment -l app=redis
+      kubectl delete service -l app=redis
+      kubectl delete deployment -l app=guestbook
+      kubectl delete service -l app=guestbook
+      kubectl delete -f filebeat-kubernetes.yaml
+      kubectl delete -f metricbeat-kubernetes.yaml
+      kubectl delete -f packetbeat-kubernetes.yaml
+      kubectl delete secret dynamic-logging -n kube-system
+      ```
+   <!--   
+   1. Query the list of Pods to verify that no Pods are running:
+   -->
+2. 查询 Pod，以核实没有 Pod 还在运行：
+
+      ```shell
+      kubectl get pods
+      ```
+
+      <!--
+      The response should be this:
+      -->
+      响应应该是这样：
+
+      ```
+      No resources found.
+      ```
+
+
+## {{% heading "whatsnext" %}}
+
+<!-- 
+* Learn about [tools for monitoring resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+* Read more about [logging architecture](/docs/concepts/cluster-administration/logging/)
+* Read more about [application introspection and debugging](/docs/tasks/debug-application-cluster/)
+* Read more about [troubleshoot applications](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+-->
+* 了解[监控资源的工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+* 进一步阅读[日志体系架构](/zh/docs/concepts/cluster-administration/logging/)
+* 进一步阅读[应用内省和调试](/zh/docs/tasks/debug-application-cluster/)
+* 进一步阅读[应用程序的故障排除](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
\ No newline at end of file
diff --git a/content/zh/examples/access/certificate-signing-request/clusterrole-approve.yaml b/content/zh/examples/access/certificate-signing-request/clusterrole-approve.yaml
new file mode 100644
index 0000000000..e5bcfdc44e
--- /dev/null
+++ b/content/zh/examples/access/certificate-signing-request/clusterrole-approve.yaml
@@ -0,0 +1,28 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: csr-approver
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests/approval
+  verbs:
+  - update
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - signers
+  resourceNames:
+  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
+  verbs:
+  - approve
+
diff --git a/content/zh/examples/access/certificate-signing-request/clusterrole-create.yaml b/content/zh/examples/access/certificate-signing-request/clusterrole-create.yaml
new file mode 100644
index 0000000000..def1b879d8
--- /dev/null
+++ b/content/zh/examples/access/certificate-signing-request/clusterrole-create.yaml
@@ -0,0 +1,14 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: csr-creator
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests
+  verbs:
+  - create
+  - get
+  - list
+  - watch
diff --git a/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml b/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml
new file mode 100644
index 0000000000..29bbc6a9cd
--- /dev/null
+++ b/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml
@@ -0,0 +1,27 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: csr-signer
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - certificatesigningrequests/status
+  verbs:
+  - update
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - signers
+  resourceName:
+  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
+  verbs:
+  - sign
diff --git a/content/zh/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/zh/examples/admin/konnectivity/egress-selector-configuration.yaml
new file mode 100644
index 0000000000..6659ff3fbb
--- /dev/null
+++ b/content/zh/examples/admin/konnectivity/egress-selector-configuration.yaml
@@ -0,0 +1,21 @@
+apiVersion: apiserver.k8s.io/v1beta1
+kind: EgressSelectorConfiguration
+egressSelections:
+# Since we want to control the egress traffic to the cluster, we use the
+# "cluster" as the name. Other supported values are "etcd", and "master".
+- name: cluster
+  connection:
+    # This controls the protocol between the API Server and the Konnectivity
+    # server. Supported values are "GRPC" and "HTTPConnect". There is no
+    # end user visible difference between the two modes. You need to set the
+    # Konnectivity server to work in the same mode.
+    proxyProtocol: GRPC
+    transport:
+      # This controls what transport the API Server uses to communicate with the
+      # Konnectivity server. UDS is recommended if the Konnectivity server
+      # locates on the same machine as the API Server. You need to configure the
+      # Konnectivity server to listen on the same UDS socket.
+      # The other supported transport is "tcp". You will need to set up TLS 
+      # config to secure the TCP transport.
+      uds:
+        udsName: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket
diff --git a/content/zh/examples/admin/konnectivity/konnectivity-agent.yaml b/content/zh/examples/admin/konnectivity/konnectivity-agent.yaml
new file mode 100644
index 0000000000..c3dc71040b
--- /dev/null
+++ b/content/zh/examples/admin/konnectivity/konnectivity-agent.yaml
@@ -0,0 +1,53 @@
+apiVersion: apps/v1
+# Alternatively, you can deploy the agents as Deployments. It is not necessary
+# to have an agent on each node.
+kind: DaemonSet
+metadata:
+  labels:
+    addonmanager.kubernetes.io/mode: Reconcile
+    k8s-app: konnectivity-agent
+  namespace: kube-system
+  name: konnectivity-agent
+spec:
+  selector:
+    matchLabels:
+      k8s-app: konnectivity-agent
+  template:
+    metadata:
+      labels:
+        k8s-app: konnectivity-agent
+    spec:
+      priorityClassName: system-cluster-critical
+      tolerations:
+        - key: "CriticalAddonsOnly"
+          operator: "Exists"
+      containers:
+        - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.8
+          name: konnectivity-agent
+          command: ["/proxy-agent"]
+          args: [
+                  "--logtostderr=true",
+                  "--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
+                  # Since the konnectivity server runs with hostNetwork=true,
+                  # this is the IP address of the master machine.
+                  "--proxy-server-host=35.225.206.7",
+                  "--proxy-server-port=8132",
+                  "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
+                  ]
+          volumeMounts:
+            - mountPath: /var/run/secrets/tokens
+              name: konnectivity-agent-token
+          livenessProbe:
+            httpGet:
+              port: 8093
+              path: /healthz
+            initialDelaySeconds: 15
+            timeoutSeconds: 15
+      serviceAccountName: konnectivity-agent
+      volumes:
+        - name: konnectivity-agent-token
+          projected:
+            sources:
+              - serviceAccountToken:
+                  path: konnectivity-agent-token
+                  audience: system:konnectivity-server
diff --git a/content/zh/examples/admin/konnectivity/konnectivity-rbac.yaml b/content/zh/examples/admin/konnectivity/konnectivity-rbac.yaml
new file mode 100644
index 0000000000..7687f49b77
--- /dev/null
+++ b/content/zh/examples/admin/konnectivity/konnectivity-rbac.yaml
@@ -0,0 +1,24 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: system:konnectivity-server
+  labels:
+    kubernetes.io/cluster-service: "true"
+    addonmanager.kubernetes.io/mode: Reconcile
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: system:auth-delegator
+subjects:
+  - apiGroup: rbac.authorization.k8s.io
+    kind: User
+    name: system:konnectivity-server
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: konnectivity-agent
+  namespace: kube-system
+  labels:
+    kubernetes.io/cluster-service: "true"
+    addonmanager.kubernetes.io/mode: Reconcile
diff --git a/content/zh/examples/admin/konnectivity/konnectivity-server.yaml b/content/zh/examples/admin/konnectivity/konnectivity-server.yaml
new file mode 100644
index 0000000000..730c26c66a
--- /dev/null
+++ b/content/zh/examples/admin/konnectivity/konnectivity-server.yaml
@@ -0,0 +1,70 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: konnectivity-server
+  namespace: kube-system
+spec:
+  priorityClassName: system-cluster-critical
+  hostNetwork: true
+  containers:
+  - name: konnectivity-server-container
+    image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.8
+    command: ["/proxy-server"]
+    args: [
+            "--log-file=/var/log/konnectivity-server.log",
+            "--logtostderr=false",
+            "--log-file-max-size=0",
+            # This needs to be consistent with the value set in egressSelectorConfiguration.
+            "--uds-name=/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket",
+            # The following two lines assume the Konnectivity server is
+            # deployed on the same machine as the apiserver, and the certs and
+            # key of the API Server are at the specified location.
+            "--cluster-cert=/etc/srv/kubernetes/pki/apiserver.crt",
+            "--cluster-key=/etc/srv/kubernetes/pki/apiserver.key",
+            # This needs to be consistent with the value set in egressSelectorConfiguration.
+            "--mode=grpc",
+            "--server-port=0",
+            "--agent-port=8132",
+            "--admin-port=8133",
+            "--agent-namespace=kube-system",
+            "--agent-service-account=konnectivity-agent",
+            "--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig",
+            "--authentication-audience=system:konnectivity-server"
+            ]
+    livenessProbe:
+      httpGet:
+        scheme: HTTP
+        host: 127.0.0.1
+        port: 8133
+        path: /healthz
+      initialDelaySeconds: 30
+      timeoutSeconds: 60
+    ports:
+    - name: agentport
+      containerPort: 8132
+      hostPort: 8132
+    - name: adminport
+      containerPort: 8133
+      hostPort: 8133
+    volumeMounts:
+    - name: varlogkonnectivityserver
+      mountPath: /var/log/konnectivity-server.log
+      readOnly: false
+    - name: pki
+      mountPath: /etc/srv/kubernetes/pki
+      readOnly: true
+    - name: konnectivity-uds
+      mountPath: /etc/srv/kubernetes/konnectivity-server
+      readOnly: false
+  volumes:
+  - name: varlogkonnectivityserver
+    hostPath:
+      path: /var/log/konnectivity-server.log
+      type: FileOrCreate
+  - name: pki
+    hostPath:
+      path: /etc/srv/kubernetes/pki
+  - name: konnectivity-uds
+    hostPath:
+      path: /etc/srv/kubernetes/konnectivity-server
+      type: DirectoryOrCreate
diff --git a/content/zh/docs/tasks/administer-cluster/memory-available.sh b/content/zh/examples/admin/resource/memory-available.sh
similarity index 100%
rename from content/zh/docs/tasks/administer-cluster/memory-available.sh
rename to content/zh/examples/admin/resource/memory-available.sh
diff --git a/content/zh/examples/application/ssa/nginx-deployment-no-replicas.yaml b/content/zh/examples/application/ssa/nginx-deployment-no-replicas.yaml
new file mode 100644
index 0000000000..c18bdd35c0
--- /dev/null
+++ b/content/zh/examples/application/ssa/nginx-deployment-no-replicas.yaml
@@ -0,0 +1,18 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  labels:
+    app: nginx
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
diff --git a/content/zh/examples/application/ssa/nginx-deployment-replicas-only.yaml b/content/zh/examples/application/ssa/nginx-deployment-replicas-only.yaml
new file mode 100644
index 0000000000..0848ba0e21
--- /dev/null
+++ b/content/zh/examples/application/ssa/nginx-deployment-replicas-only.yaml
@@ -0,0 +1,6 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  replicas: 3
diff --git a/content/zh/examples/application/ssa/nginx-deployment.yaml b/content/zh/examples/application/ssa/nginx-deployment.yaml
new file mode 100644
index 0000000000..7797b13d9a
--- /dev/null
+++ b/content/zh/examples/application/ssa/nginx-deployment.yaml
@@ -0,0 +1,19 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  labels:
+    app: nginx
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
diff --git a/content/zh/examples/federation/policy-engine-deployment.yaml b/content/zh/examples/federation/policy-engine-deployment.yaml
deleted file mode 100644
index 168af7ba4c..0000000000
--- a/content/zh/examples/federation/policy-engine-deployment.yaml
+++ /dev/null
@@ -1,37 +0,0 @@
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    app: opa
-  name: opa
-  namespace: federation-system
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: opa
-  template:
-    metadata:
-      labels:
-        app: opa
-      name: opa
-    spec:
-      containers:
-        - name: opa
-          image: openpolicyagent/opa:0.4.10
-          args:
-          - "run"
-          - "--server"
-        - name: kube-mgmt
-          image: openpolicyagent/kube-mgmt:0.2
-          args:
-          - "-kubeconfig=/srv/kubernetes/kubeconfig"
-          - "-cluster=federation/v1beta1/clusters"
-          volumeMounts:
-           - name: federation-kubeconfig
-             mountPath: /srv/kubernetes
-             readOnly: true
-      volumes:
-      - name: federation-kubeconfig
-        secret:
-          secretName: federation-controller-manager-kubeconfig
diff --git a/content/zh/examples/federation/policy-engine-service.yaml b/content/zh/examples/federation/policy-engine-service.yaml
deleted file mode 100644
index 287a972d64..0000000000
--- a/content/zh/examples/federation/policy-engine-service.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-kind: Service
-apiVersion: v1
-metadata:
-  name: opa
-  namespace: federation-system
-spec:
-  selector:
-    app: opa
-  ports:
-  - name: http
-    protocol: TCP
-    port: 8181
-    targetPort: 8181
\ No newline at end of file
diff --git a/content/zh/examples/federation/replicaset-example-policy.yaml b/content/zh/examples/federation/replicaset-example-policy.yaml
deleted file mode 100644
index 43dc83b18b..0000000000
--- a/content/zh/examples/federation/replicaset-example-policy.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
-  labels:
-    app: nginx-pci
-  name: nginx-pci
-  annotations:
-    requires-pci: "true"
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      app: nginx-pci
-  template:
-    metadata:
-      labels:
-        app: nginx-pci
-    spec:
-      containers:
-      - image: nginx
-        name: nginx-pci
diff --git a/content/zh/examples/federation/scheduling-policy-admission.yaml b/content/zh/examples/federation/scheduling-policy-admission.yaml
deleted file mode 100644
index a164722425..0000000000
--- a/content/zh/examples/federation/scheduling-policy-admission.yaml
+++ /dev/null
@@ -1,29 +0,0 @@
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: admission
-  namespace: federation-system
-data:
-  config.yml: |
-    apiVersion: apiserver.k8s.io/v1alpha1
-    kind: AdmissionConfiguration
-    plugins:
-    - name: SchedulingPolicy
-      path: /etc/kubernetes/admission/scheduling-policy-config.yml
-  scheduling-policy-config.yml: |
-    kubeconfig: /etc/kubernetes/admission/opa-kubeconfig
-  opa-kubeconfig: |
-    clusters:
-      - name: opa-api
-        cluster:
-          server: http://opa.federation-system.svc.cluster.local:8181/v0/data/kubernetes/placement
-    users:
-      - name: scheduling-policy
-        user:
-          token: deadbeefsecret
-    contexts:
-      - name: default
-        context:
-          cluster: opa-api
-          user: scheduling-policy
-    current-context: default
diff --git a/content/zh/examples/minikube/Dockerfile b/content/zh/examples/minikube/Dockerfile
deleted file mode 100644
index dd58cb7e75..0000000000
--- a/content/zh/examples/minikube/Dockerfile
+++ /dev/null
@@ -1,4 +0,0 @@
-FROM node:6.14.2
-EXPOSE 8080
-COPY server.js .
-CMD [ "node", "server.js" ]
diff --git a/content/zh/examples/minikube/server.js b/content/zh/examples/minikube/server.js
deleted file mode 100644
index 76345a17d8..0000000000
--- a/content/zh/examples/minikube/server.js
+++ /dev/null
@@ -1,9 +0,0 @@
-var http = require('http');
-
-var handleRequest = function(request, response) {
-  console.log('Received request for URL: ' + request.url);
-  response.writeHead(200);
-  response.end('Hello World!');
-};
-var www = http.createServer(handleRequest);
-www.listen(8080);
diff --git a/content/zh/examples/pods/inject/dependent-envars.yaml b/content/zh/examples/pods/inject/dependent-envars.yaml
new file mode 100644
index 0000000000..2509c6f47b
--- /dev/null
+++ b/content/zh/examples/pods/inject/dependent-envars.yaml
@@ -0,0 +1,26 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: dependent-envars-demo
+spec:
+  containers:
+    - name: dependent-envars-demo
+      args:
+        - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
+      command:
+        - sh
+        - -c
+      image: busybox
+      env:
+        - name: SERVICE_PORT
+          value: "80"
+        - name: SERVICE_IP
+          value: "172.17.0.1"
+        - name: UNCHANGED_REFERENCE
+          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
+        - name: PROTOCOL
+          value: "https"
+        - name: SERVICE_ADDRESS
+          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
+        - name: ESCAPED_REFERENCE
+          value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
diff --git a/content/zh/examples/pods/pod-with-pod-affinity.yaml b/content/zh/examples/pods/pod-with-pod-affinity.yaml
index 35e645ef1f..6d075e0860 100644
--- a/content/zh/examples/pods/pod-with-pod-affinity.yaml
+++ b/content/zh/examples/pods/pod-with-pod-affinity.yaml
@@ -12,7 +12,7 @@ spec:
             operator: In
             values:
             - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
     podAntiAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 100
@@ -23,7 +23,7 @@ spec:
               operator: In
               values:
               - S2
-          topologyKey: failure-domain.beta.kubernetes.io/zone
+          topologyKey: topology.kubernetes.io/zone
   containers:
   - name: with-pod-affinity
     image: k8s.gcr.io/pause:2.0
diff --git a/content/zh/examples/pods/security/seccomp/alpha/audit-pod.yaml b/content/zh/examples/pods/security/seccomp/alpha/audit-pod.yaml
new file mode 100644
index 0000000000..d2d93d7fba
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/alpha/audit-pod.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: audit-pod
+  labels:
+    app: audit-pod
+  annotations:
+    seccomp.security.alpha.kubernetes.io/pod: localhost/profiles/audit.json
+spec:
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/alpha/default-pod.yaml b/content/zh/examples/pods/security/seccomp/alpha/default-pod.yaml
new file mode 100644
index 0000000000..ebb7344418
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/alpha/default-pod.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: default-pod
+  labels:
+    app: default-pod
+  annotations:
+    seccomp.security.alpha.kubernetes.io/pod: runtime/default
+spec:
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/alpha/fine-pod.yaml b/content/zh/examples/pods/security/seccomp/alpha/fine-pod.yaml
new file mode 100644
index 0000000000..abd5358547
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/alpha/fine-pod.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: fine-pod
+  labels:
+    app: fine-pod
+  annotations:
+    seccomp.security.alpha.kubernetes.io/pod: localhost/profiles/fine-grained.json
+spec:
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/alpha/violation-pod.yaml b/content/zh/examples/pods/security/seccomp/alpha/violation-pod.yaml
new file mode 100644
index 0000000000..177f56af8f
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/alpha/violation-pod.yaml
@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: violation-pod
+  labels:
+    app: violation-pod
+  annotations:
+    seccomp.security.alpha.kubernetes.io/pod: localhost/profiles/violation.json
+spec:
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/ga/audit-pod.yaml b/content/zh/examples/pods/security/seccomp/ga/audit-pod.yaml
new file mode 100644
index 0000000000..409d4b923c
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/ga/audit-pod.yaml
@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: audit-pod
+  labels:
+    app: audit-pod
+spec:
+  securityContext:
+    seccompProfile:
+      type: Localhost
+      localhostProfile: profiles/audit.json
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/ga/default-pod.yaml b/content/zh/examples/pods/security/seccomp/ga/default-pod.yaml
new file mode 100644
index 0000000000..fbeec4c167
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/ga/default-pod.yaml
@@ -0,0 +1,17 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: audit-pod
+  labels:
+    app: audit-pod
+spec:
+  securityContext:
+    seccompProfile:
+      type: RuntimeDefault
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/ga/fine-pod.yaml b/content/zh/examples/pods/security/seccomp/ga/fine-pod.yaml
new file mode 100644
index 0000000000..692b828151
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/ga/fine-pod.yaml
@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: fine-pod
+  labels:
+    app: fine-pod
+spec:
+  securityContext:
+    seccompProfile:
+      type: Localhost
+      localhostProfile: profiles/fine-grained.json
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/ga/violation-pod.yaml b/content/zh/examples/pods/security/seccomp/ga/violation-pod.yaml
new file mode 100644
index 0000000000..70deadf4b2
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/ga/violation-pod.yaml
@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: violation-pod
+  labels:
+    app: violation-pod
+spec:
+  securityContext:
+    seccompProfile:
+      type: Localhost
+      localhostProfile: profiles/violation.json
+  containers:
+  - name: test-container
+    image: hashicorp/http-echo:0.2.3
+    args:
+    - "-text=just made some syscalls!"
+    securityContext:
+      allowPrivilegeEscalation: false
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/kind.yaml b/content/zh/examples/pods/security/seccomp/kind.yaml
new file mode 100644
index 0000000000..4418359661
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/kind.yaml
@@ -0,0 +1,7 @@
+apiVersion: kind.x-k8s.io/v1alpha4
+kind: Cluster
+nodes:
+- role: control-plane
+  extraMounts:
+  - hostPath: "./profiles"
+    containerPath: "/var/lib/kubelet/seccomp/profiles"
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/profiles/audit.json b/content/zh/examples/pods/security/seccomp/profiles/audit.json
new file mode 100644
index 0000000000..1f2d5df6a4
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/profiles/audit.json
@@ -0,0 +1,3 @@
+{
+    "defaultAction": "SCMP_ACT_LOG"
+}
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/profiles/fine-grained.json b/content/zh/examples/pods/security/seccomp/profiles/fine-grained.json
new file mode 100644
index 0000000000..2eeaf9133e
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/profiles/fine-grained.json
@@ -0,0 +1,65 @@
+{
+    "defaultAction": "SCMP_ACT_ERRNO",
+    "architectures": [
+        "SCMP_ARCH_X86_64",
+        "SCMP_ARCH_X86",
+        "SCMP_ARCH_X32"
+    ],
+    "syscalls": [
+        {
+            "names": [
+                "accept4",
+                "epoll_wait",
+                "pselect6",
+                "futex",
+                "madvise",
+                "epoll_ctl",
+                "getsockname",
+                "setsockopt",
+                "vfork",
+                "mmap",
+                "read",
+                "write",
+                "close",
+                "arch_prctl",
+                "sched_getaffinity",
+                "munmap",
+                "brk",
+                "rt_sigaction",
+                "rt_sigprocmask",
+                "sigaltstack",
+                "gettid",
+                "clone",
+                "bind",
+                "socket",
+                "openat",
+                "readlinkat",
+                "exit_group",
+                "epoll_create1",
+                "listen",
+                "rt_sigreturn",
+                "sched_yield",
+                "clock_gettime",
+                "connect",
+                "dup2",
+                "epoll_pwait",
+                "execve",
+                "exit",
+                "fcntl",
+                "getpid",
+                "getuid",
+                "ioctl",
+                "mprotect",
+                "nanosleep",
+                "open",
+                "poll",
+                "recvfrom",
+                "sendto",
+                "set_tid_address",
+                "setitimer",
+                "writev"
+            ],
+            "action": "SCMP_ACT_ALLOW"
+        }
+    ]
+}
\ No newline at end of file
diff --git a/content/zh/examples/pods/security/seccomp/profiles/violation.json b/content/zh/examples/pods/security/seccomp/profiles/violation.json
new file mode 100644
index 0000000000..7ce0faa8b0
--- /dev/null
+++ b/content/zh/examples/pods/security/seccomp/profiles/violation.json
@@ -0,0 +1,3 @@
+{
+    "defaultAction": "SCMP_ACT_ERRNO"
+}
\ No newline at end of file
diff --git a/content/zh/examples/priority-and-fairness/health-for-strangers.yaml b/content/zh/examples/priority-and-fairness/health-for-strangers.yaml
new file mode 100644
index 0000000000..79ee80ab17
--- /dev/null
+++ b/content/zh/examples/priority-and-fairness/health-for-strangers.yaml
@@ -0,0 +1,20 @@
+apiVersion: flowcontrol.apiserver.k8s.io/v1alpha1
+kind: FlowSchema
+metadata:
+  name: health-for-strangers
+spec:
+  matchingPrecedence: 1000
+  priorityLevelConfiguration:
+    name: exempt
+  rules:
+  - nonResourceRules:
+    - nonResourceURLs:
+      - "/healthz"
+      - "/livez"
+      - "/readyz"
+      verbs:
+      - "*"
+    subjects:
+    - kind: Group
+      group:
+        name: system:unauthenticated
diff --git a/content/zh/examples/service/networking/example-ingress.yaml b/content/zh/examples/service/networking/example-ingress.yaml
new file mode 100644
index 0000000000..b309d13275
--- /dev/null
+++ b/content/zh/examples/service/networking/example-ingress.yaml
@@ -0,0 +1,18 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: example-ingress
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /$1
+spec:
+  rules:
+    - host: hello-world.info
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: web
+                port:
+                  number: 8080
\ No newline at end of file
diff --git a/content/zh/examples/service/networking/external-lb.yaml b/content/zh/examples/service/networking/external-lb.yaml
new file mode 100644
index 0000000000..adcf7a2fd0
--- /dev/null
+++ b/content/zh/examples/service/networking/external-lb.yaml
@@ -0,0 +1,10 @@
+apiVersion: networking.k8s.io/v1
+kind: IngressClass
+metadata:
+  name: external-lb
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    apiGroup: k8s.example.com
+    kind: IngressParameters
+    name: external-lb
diff --git a/content/zh/examples/service/networking/ingress-resource-backend.yaml b/content/zh/examples/service/networking/ingress-resource-backend.yaml
new file mode 100644
index 0000000000..87b6bbd0f3
--- /dev/null
+++ b/content/zh/examples/service/networking/ingress-resource-backend.yaml
@@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: ingress-resource-backend
+spec:
+  defaultBackend:
+    resource:
+      apiGroup: k8s.example.com
+      kind: StorageBucket
+      name: static-assets
+  rules:
+    - http:
+        paths:
+          - path: /icons
+            pathType: ImplementationSpecific
+            backend:
+              resource:
+                apiGroup: k8s.example.com
+                kind: StorageBucket
+                name: icon-assets
diff --git a/content/zh/examples/service/networking/ingress-wildcard-host.yaml b/content/zh/examples/service/networking/ingress-wildcard-host.yaml
new file mode 100644
index 0000000000..2be7016706
--- /dev/null
+++ b/content/zh/examples/service/networking/ingress-wildcard-host.yaml
@@ -0,0 +1,26 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: ingress-wildcard-host
+spec:
+  rules:
+  - host: "foo.bar.com"
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/bar"
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
+  - host: "*.foo.com"
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/foo"
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
diff --git a/content/zh/examples/service/networking/ingress.yaml b/content/zh/examples/service/networking/ingress.yaml
deleted file mode 100644
index 56a0d5138f..0000000000
--- a/content/zh/examples/service/networking/ingress.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-spec:
-  backend:
-    serviceName: testsvc
-    servicePort: 80
-
diff --git a/content/zh/examples/service/networking/minimal-ingress.yaml b/content/zh/examples/service/networking/minimal-ingress.yaml
new file mode 100644
index 0000000000..76640b9447
--- /dev/null
+++ b/content/zh/examples/service/networking/minimal-ingress.yaml
@@ -0,0 +1,17 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: minimal-ingress
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /testpath
+        pathType: Prefix
+        backend:
+          service:
+            name: test
+            port:
+              number: 80
diff --git a/content/zh/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml b/content/zh/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml
new file mode 100644
index 0000000000..16a560b1ff
--- /dev/null
+++ b/content/zh/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml
@@ -0,0 +1,35 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress-no-third-host
+spec:
+  rules:
+  - host: first.bar.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
+  - host: second.bar.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
+  - http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service3
+            port:
+              number: 80
diff --git a/content/zh/examples/service/networking/name-virtual-host-ingress.yaml b/content/zh/examples/service/networking/name-virtual-host-ingress.yaml
new file mode 100644
index 0000000000..213a73d261
--- /dev/null
+++ b/content/zh/examples/service/networking/name-virtual-host-ingress.yaml
@@ -0,0 +1,26 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
+  - host: bar.foo.com
+    http:
+      paths:
+      - pathType: Prefix
+        path: "/"
+        backend:
+          service:
+            name: service2
+            port:
+              number: 80
diff --git a/content/zh/examples/service/networking/simple-fanout-example.yaml b/content/zh/examples/service/networking/simple-fanout-example.yaml
new file mode 100644
index 0000000000..19fef9455b
--- /dev/null
+++ b/content/zh/examples/service/networking/simple-fanout-example.yaml
@@ -0,0 +1,23 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: simple-fanout-example
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - path: /foo
+        pathType: Prefix
+        backend:
+          service:
+            name: service1
+            port:
+              number: 4200
+      - path: /bar
+        pathType: Prefix
+        backend:
+          service:
+            name: service2
+            port:
+              number: 8080
diff --git a/content/zh/examples/service/networking/test-ingress.yaml b/content/zh/examples/service/networking/test-ingress.yaml
new file mode 100644
index 0000000000..acd384ab56
--- /dev/null
+++ b/content/zh/examples/service/networking/test-ingress.yaml
@@ -0,0 +1,10 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: test-ingress
+spec:
+  defaultBackend:
+    service:
+      name: test
+      port:
+        number: 80
diff --git a/content/zh/examples/service/networking/tls-example-ingress.yaml b/content/zh/examples/service/networking/tls-example-ingress.yaml
new file mode 100644
index 0000000000..fe5d52a0cb
--- /dev/null
+++ b/content/zh/examples/service/networking/tls-example-ingress.yaml
@@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: tls-example-ingress
+spec:
+  tls:
+  - hosts:
+      - https-example.foo.com
+    secretName: testsecret-tls
+  rules:
+  - host: https-example.foo.com
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: service1
+            port:
+              number: 80
diff --git a/content/zh/includes/federated-task-tutorial-prereqs.md b/content/zh/includes/federated-task-tutorial-prereqs.md
deleted file mode 100644
index 565b2f73d0..0000000000
--- a/content/zh/includes/federated-task-tutorial-prereqs.md
+++ /dev/null
@@ -1,16 +0,0 @@
-<!--
-This guide assumes that you have a running Kubernetes Cluster
-Federation installation. If not, then head over to the
-[federation admin guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) to learn how to
-bring up a cluster federation (or have your cluster administrator do
-this for you).
-Other tutorials, such as Kelsey Hightower's 
-[Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation),
-might also help you create a Federated Kubernetes cluster.
--->
-
-本指南假设您已安装有一个正在运行的 Kubernetes 集群联邦。如果没有，那么请转到
-[联邦管理指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)，了解如何启动联邦集群(或者让集群管理员为您执行此操作)。
-其他教程，例如 Kelsey Hightower 的[联邦 Kubernetes 教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)，
-也可能帮助您创建联邦 Kubernetes 集群。
-
diff --git a/content/zh/includes/partner-script.js b/content/zh/includes/partner-script.js
deleted file mode 100644
index 499dc3f2e3..0000000000
--- a/content/zh/includes/partner-script.js
+++ /dev/null
@@ -1,1609 +0,0 @@
-;(function () {
-	var partners = [
-		{
-			type: 0,
-			name: 'Sysdig',
-			logo: 'sys_dig',
-			link: 'https://sysdig.com/blog/monitoring-kubernetes-with-sysdig-cloud/',
-			blurb: 'Sysdig is the container intelligence company. Sysdig has created the only unified platform to deliver monitoring, security, and troubleshooting in a microservices-friendly architecture.'
-		},
-		{
-			type: 0,
-			name: 'Puppet',
-			logo: 'puppet',
-			link: 'https://puppet.com/blog/announcing-kream-and-new-kubernetes-helm-and-docker-modules',
-			blurb: 'We\'ve developed tools and products to make your adoption of Kubernetes as efficient as possible, covering your full workflow cycle from development to production. And now Puppet Pipelines for Containers is your complete DevOps dashboard for Kubernetes.'
-		},
-		{
-			type: 0,
-			name: 'Citrix',
-			logo: 'citrix',
-			link: 'https://www.citrix.com/networking/microservices.html',
-			blurb: 'Netscaler CPX gives app developers all the features they need to load balance their microservices and containerized apps with Kubernetes.'
-		},
-		{
-			type: 0,
-			name: 'Cockroach Labs',
-			logo: 'cockroach_labs',
-			link: 'https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/',
-			blurb: 'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.'
-		},
-		{
-			type: 2,
-			name: 'Weaveworks',
-			logo: 'weave_works',
-			link: ' https://weave.works/kubernetes',
-			blurb: 'Weaveworks enables Developers and Dev/Ops teams to easily connect, deploy, secure, manage, and troubleshoot microservices in Kubernetes.'
-		},
-		{
-			type: 0,
-			name: 'Intel',
-			logo: 'intel',
-			link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html',
-			blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.'
-		},
-		{
-			type: 3,
-			name: 'Platform9',
-			logo: 'platform9',
-			link: 'https://platform9.com/products/kubernetes/',
-			blurb: 'Platform9 is the open source-as-a-service company that takes all of the goodness of Kubernetes and delivers it as a managed service.'
-		},
-		{
-			type: 0,
-			name: 'Datadog',
-			logo: 'datadog',
-			link: 'http://docs.datadoghq.com/integrations/kubernetes/',
-			blurb: 'Full-stack observability for dynamic infrastructure & applications. Includes precision alerting, analytics and deep Kubernetes integrations. '
-		},
-		{
-			type: 0,
-			name: 'AppFormix',
-			logo: 'appformix',
-			link: 'http://www.appformix.com/solutions/appformix-for-kubernetes/',
-			blurb: 'AppFormix is a cloud infrastructure performance optimization service helping enterprise operators streamline their cloud operations on any Kubernetes cloud. '
-		},
-		{
-			type: 0,
-			name: 'Crunchy',
-			logo: 'crunchy',
-			link: 'http://info.crunchydata.com/blog/advanced-crunchy-containers-for-postgresql',
-			blurb: 'Crunchy PostgreSQL Container Suite is a set of containers for managing PostgreSQL with DBA microservices leveraging Kubernetes and Helm.'
-		},
-		{
-			type: 0,
-			name: 'Aqua',
-			logo: 'aqua',
-			link: 'http://blog.aquasec.com/security-best-practices-for-kubernetes-deployment',
-			blurb: 'Deep, automated security for your containers running on Kubernetes.'
-		},
-		{
-			type: 0,
-			name: 'Distelli',
-			logo: 'distelli',
-			link: 'https://www.distelli.com/',
-			blurb: 'Pipelines from your source repositories to your Kubernetes Clusters on any cloud.'
-		},
-		{
-			type: 0,
-			name: 'Nuage networks',
-			logo: 'nuagenetworks',
-			link: 'https://github.com/nuagenetworks/nuage-kubernetes',
-			blurb: 'The Nuage SDN platform provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.'
-		},
-		{
-			type: 0,
-			name: 'Sematext',
-			logo: 'sematext',
-			link: 'https://sematext.com/kubernetes/',
-			blurb: 'Logging & Monitoring: Automatic collection and processing of Metrics, Events and Logs for auto-discovered pods and Kubernetes nodes.'
-		},
-		{
-			type: 0,
-			name: 'Diamanti',
-			logo: 'diamanti',
-			link: 'https://www.diamanti.com/products/',
-			blurb: 'Diamanti deploys containers with guaranteed performance using Kubernetes in the first hyperconverged appliance purpose built for containerized applications.'
-				},
-		{
-			type: 0,
-			name: 'Aporeto',
-			logo: 'aporeto',
-			link: 'https://aporeto.com/trireme',
-			blurb: 'Aporeto makes cloud-native applications secure by default without impacting developer velocity and works at any scale, on any cloud.'
-				},
-		{
-  		type: 2,
- 			name: 'Giant Swarm',
- 			logo: 'giantswarm',
- 			link: 'https://giantswarm.io',
- 			blurb: 'Giant Swarm enables you to simply and rapidly create and use Kubernetes clusters on-demand either on-premises or in the cloud. Contact Giant Swarm to learn about the best way to run cloud native applications anywhere.'
- 				},
-		{
-		 	type: 3,
-		 	name: 'Giant Swarm',
-		 	logo: 'giantswarm',
-		 	link: 'https://giantswarm.io/product/',
-		 	blurb: 'Giant Swarm enables you to simply and rapidly create and use Kubernetes clusters on-demand either on-premises or in the cloud. Contact Giant Swarm to learn about the best way to run cloud native applications anywhere.'
-		 		},
-		{
-		 	type: 3,
-			name: 'Hasura',
-			logo: 'hasura',
-			link: 'https://hasura.io',
-			blurb: 'Hasura is a Kubernetes-based PaaS and a Postgres-based BaaS that accelerates app development with ready-to-use components.'
-				},
-		{
- 			type: 3,
- 			name: 'Mirantis',
- 			logo: 'mirantis',
- 			link: 'https://www.mirantis.com/software/kubernetes/',
- 			blurb: 'Mirantis - Mirantis Cloud Platform'
- 				},
-		{
-		 	type: 2,
-		 	name: 'Mirantis',
-		 	logo: 'mirantis',
-		 	link: 'https://content.mirantis.com/Containerizing-OpenStack-on-Kubernetes-Video-Landing-Page.html',
-		 	blurb: 'Mirantis builds and manages private clouds with open source software such as OpenStack, deployed as containers orchestrated by Kubernetes.'
-		 		},
-		{
- 			type: 0,
- 			name: 'Kubernetic',
- 			logo: 'kubernetic',
- 			link: 'https://kubernetic.com/',
- 			blurb: 'Kubernetic is a Kubernetes Desktop client that simplifies and democratizes cluster management for DevOps.'
- 				},
-		{
-			type: 1,
-			name: 'Reactive Ops',
-			logo: 'reactive_ops',
-			link: 'https://www.reactiveops.com/the-kubernetes-experts/',
-			blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.'
-		},
-		{
-			type: 2,
-			name: 'Livewyer',
-			logo: 'livewyer',
-			link: 'https://livewyer.io/services/kubernetes-experts/',
-			blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.'
-		},
-		{
-			type: 2,
-			name: 'Samsung SDS',
-			logo: 'samsung_sds',
-			link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes',
-			blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.'
-		},
-		{
-			type: 2,
-			name: 'Container Solutions',
-			logo: 'container_solutions',
-			link: 'http://container-solutions.com/resources/kubernetes/',
-			blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.'
-		},
-		{
-			type: 4,
-			name: 'Container Solutions',
-			logo: 'container_solutions',
-			link: 'http://container-solutions.com/resources/kubernetes/',
-			blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.'
-		},
-		{
-			type: 2,
-			name: 'Jetstack',
-			logo: 'jetstack',
-			link: 'https://www.jetstack.io/',
-			blurb: 'Jetstack is an organisation focused entirely on Kubernetes. They will help you to get the most out of Kubernetes through expert professional services and open source tooling. Get in touch, and accelerate your project.'
-		},
-		{
-			type: 0,
-			name: 'Tigera',
-			logo: 'tigera',
-			link: 'http://docs.projectcalico.org/latest/getting-started/kubernetes/',
-			blurb: 'Tigera builds high performance, policy driven, cloud native networking solutions for Kubernetes.'
-		},
-		{
- 			type: 1,
- 			name: 'Harbur',
- 			logo: 'harbur',
- 			link: 'https://harbur.io/',
- 			blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies'
-  		},
-		{
- 			type: 0,
- 			name: 'Spotinst',
- 			logo: 'spotinst',
- 			link: 'http://blog.spotinst.com/2016/08/04/elastigroup-kubernetes-minions-steroids/',
- 			blurb: 'Your Kubernetes For 80% Less. Run K8s workloads on Spot Instances with 100% availability to save 80% + autoscale your Kubernetes with maximum efficiency in heterogenous environments.'
-  		},
-		{
- 			type: 2,
- 			name: 'InwinSTACK',
- 			logo: 'inwinstack',
- 			link: 'http://www.inwinstack.com/index.php/en/solutions-en/',
- 			blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.'
-  		},
-	{
-			type: 4,
-			name: 'InwinSTACK',
-			logo: 'inwinstack',
-			link: 'http://www.inwinstack.com/index.php/en/solutions-en/',
-			blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.'
-			},
-		{
-	 		type: 3,
-	 		name: 'InwinSTACK',
-	 		logo: 'inwinstack',
-	 		link: 'https://github.com/inwinstack/kube-ansible',
-	 		blurb: 'inwinSTACK - kube-ansible'
-	  	},
-		{
- 			type: 1,
- 			name: 'Semantix',
- 			logo: 'semantix',
- 			link: 'http://www.semantix.com.br/',
- 			blurb: 'Semantix is a company that works with data analytics and distributed systems. Kubernetes is used to orchestrate services for our customers.'
-  		},
-		{
- 			type: 0,
- 			name: 'ASM Technologies Limited',
- 			logo: 'asm',
- 			link: 'http://www.asmtech.com/',
- 			blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.'
-  		},
-		{
- 			type: 1,
- 			name: 'InfraCloud Technologies',
- 			logo: 'infracloud',
- 			link: 'http://blog.infracloud.io/state-of-kubernetes/',
- 			blurb: 'InfraCloud Technologies is software consultancy which provides services in Containers, Cloud and DevOps.'
-  		},
-		{
- 			type: 0,
- 			name: 'SignalFx',
- 			logo: 'signalfx',
- 			link: 'https://github.com/signalfx/integrations/tree/master/kubernetes',
- 			blurb: 'Gain real-time visibility across metrics & the most intelligent alerts for todays architectures, including deep integration with Kubernetes'
-  		},
-		{
- 			type: 0,
- 			name: 'NATS',
- 			logo: 'nats',
- 			link: 'https://github.com/pires/kubernetes-nats-cluster',
- 			blurb: 'NATS is a simple, secure, and scalable cloud native messaging system.'
-  		},
-		{
- 			type: 2,
- 			name: 'RX-M',
- 			logo: 'rxm',
- 			link: 'http://rx-m.com/training/kubernetes-training/',
- 			blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services.'
-  		},
-		{
-	 		type: 4,
-	 		name: 'RX-M',
-	 		logo: 'rxm',
-	 		link: 'http://rx-m.com/training/kubernetes-training/',
-	 		blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services.'
-	  	},
-		{
- 			type: 1,
- 			name: 'Emerging Technology Advisors',
- 			logo: 'eta',
- 			link: 'https://www.emergingtechnologyadvisors.com/services/kubernetes.html',
- 			blurb: 'ETA helps companies architect, implement, and manage scalable applications using Kubernetes on public or private cloud.'
-  		},
-		{
- 			type: 0,
- 			name: 'CloudPlex.io',
- 			logo: 'cloudplex',
- 			link: 'http://www.cloudplex.io',
- 			blurb: 'CloudPlex enables operations teams to visually deploy, orchestrate, manage, and monitor infrastructure, applications, and services in public or private cloud.'
-  		},
-		{
- 			type: 2,
- 			name: 'Kumina',
- 			logo: 'kumina',
- 			link: 'https://www.kumina.nl/managed_kubernetes',
- 			blurb: 'Kumina combines the power of Kubernetes with 10+ years of experience in IT operations. We create, build and support fully managed Kubernetes solutions on your choice of infrastructure. We also provide consulting and training.'
-  		},
-		{
- 			type: 0,
- 			name: 'CA Technologies',
- 			logo: 'ca',
- 			link: 'https://docops.ca.com/ca-continuous-delivery-director/integrations/en/plug-ins/kubernetes-plug-in',
- 			blurb: 'The CA Continuous Delivery Director Kubernetes plugin orchestrates deployment of containerized applications within an end-to-end release pipeline.'
-  		},
-		{
- 			type: 0,
- 			name: 'CoScale',
- 			logo: 'coscale',
- 			link: 'http://www.coscale.com/blog/how-to-monitor-your-kubernetes-cluster',
- 			blurb: 'Full stack monitoring of containers and microservices orchestrated by Kubernetes. Powered by anomaly detection to find problems faster.'
-  		},
-		{
- 			type: 2,
- 			name: 'Supergiant.io',
- 			logo: 'supergiant',
- 			link: 'https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money',
- 			blurb: 'Supergiant autoscales hardware for Kubernetes. Open-source, it makes HA, distributed, stateful apps easy to deploy, manage, and scale.'
-  		},
-		{
- 			type: 0,
- 			name: 'Avi Networks',
- 			logo: 'avinetworks',
- 			link: 'https://kb.avinetworks.com/avi-vantage-openshift-installation-guide/',
- 			blurb: 'Avis elastic application services fabric provides scalable, feature rich & integrated L4-7 networking for K8S environments.'
-  		},
-		{
- 			type: 1,
- 			name: 'Codecrux web technologies pvt ltd',
- 			logo: 'codecrux',
- 			link: 'http://codecrux.com/kubernetes/',
- 			blurb: 'At CodeCrux we help your organization get the most out of Containers and Kubernetes, regardless of where you are in your journey'
-  		},
-		{
- 			type: 0,
- 			name: 'Greenqloud',
- 			logo: 'qstack',
- 			link: 'https://www.qstack.com/application-orchestration/',
- 			blurb: 'Qstack provides self-serviceable on-site Kubernetes clusters with an intuitive User Interface for Infrastructure and Kubernetes management.'
-  		},
-		{
- 			type: 1,
- 			name: 'StackOverdrive.io',
- 			logo: 'stackoverdrive',
- 			link: 'http://www.stackoverdrive.net/kubernetes-consulting/',
- 			blurb: 'StackOverdrive helps organizations of all sizes leverage Kubernetes for container based orchestration and management.'
-  		},
-		{
- 			type: 0,
- 			name: 'StackIQ, Inc.',
- 			logo: 'stackiq',
- 			link: 'https://www.stackiq.com/kubernetes/',
- 			blurb: 'With Stacki and the Stacki Pallet for Kubernetes, you can go from bare metal to containers in one step very quickly and easily.'
-  		},
-		{
- 			type: 0,
- 			name: 'Cobe',
- 			logo: 'cobe',
- 			link: 'https://cobe.io/product-page/',
- 			blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.'
-  		},
-		{
- 			type: 0,
- 			name: 'Datawire',
- 			logo: 'datawire',
- 			link: 'http://www.datawire.io',
- 			blurb: 'Datawires open source tools let your microservices developers be awesomely productive on Kubernetes, while letting ops sleep at night.'
-  		},
-		{
- 			type: 0,
- 			name: 'Mashape, Inc.',
- 			logo: 'kong',
- 			link: 'https://getkong.org/install/kubernetes/',
- 			blurb: 'Kong is a scalable open source API layer that runs in front of any RESTful API and can be provisioned to a Kubernetes cluster.'
-  		},
-		{
- 			type: 0,
- 			name: 'F5 Networks',
- 			logo: 'f5networks',
- 			link: 'http://github.com/f5networks',
- 			blurb: 'We have a LB integration into Kubernetes.'
-  		},
-		{
- 			type: 1,
- 			name: 'Lovable Tech',
- 			logo: 'lovable',
- 			link: 'http://lovable.tech/',
- 			blurb: 'World class engineers, designers, and strategic consultants helping you ship Lovable web & mobile technology.'
-  		},
-		{
- 			type: 0,
- 			name: 'StackState',
- 			logo: 'stackstate',
- 			link: 'http://stackstate.com/platform/container-monitoring',
- 			blurb: 'Operational Analytics across teams and tools. Includes topology visualization, root cause analysis and anomaly detection for Kubernetes.'
-  		},
-		{
- 			type: 1,
- 			name: 'INEXCCO INC',
- 			logo: 'inexcco',
- 			link: 'https://www.inexcco.com/',
- 			blurb: 'Strong DevOps and Cloud talent working with couple clients on kubernetes and helm implementations. '
-  		},
-		{
- 			type: 2,
- 			name: 'Bitnami',
- 			logo: 'bitnami',
- 			link: 'http://bitnami.com/kubernetes',
- 			blurb: 'Bitnami brings a catalog of trusted, up to date, and easy to use applications and application building blocks to Kubernetes.'
-  		},
-		{
- 			type: 1,
- 			name: 'Nebulaworks',
- 			logo: 'nebulaworks',
- 			link: 'http://www.nebulaworks.com/container-platforms',
- 			blurb: 'Nebulaworks provides services to help the enterprise adopt modern container platforms and optimized processes to enable innovation at scale.'
-  		},
-		{
- 			type: 1,
- 			name: 'EASYNUBE',
- 			logo: 'easynube',
- 			link: 'http://easynube.co.uk/devopsnube/',
- 			blurb: 'EasyNube provide architecture, implementation, and manage scalable applications using Kubernetes and Openshift.'
-  		},
-		{
- 			type: 1,
- 			name: 'Opcito Technologies',
- 			logo: 'opcito',
- 			link: 'http://www.opcito.com/kubernetes/',
- 			blurb: 'Opcito is a software consultancy that uses Kubernetes to help organisations build, architect & deploy highly scalable applications.'
-  		},
-		{
- 			type: 0,
- 			name: 'code by Dell EMC',
- 			logo: 'codedellemc',
- 			link: 'https://blog.codedellemc.com',
- 			blurb: 'Respected as a thought leader in storage persistence for containerized applications. Contributed significant work to K8 and Ecosystem'
-			},
-		{
-	 		type: 0,
-		 	name: 'Instana',
-		 	logo: 'instana',
-		 	link: 'https://www.instana.com/supported-technologies/',
-		 	blurb: 'Instana monitors performance of the applications, infrastructure, containers and services deployed on a Kubernetes cluster.'
-			},
-		{
-		 	type: 0,
-			name: 'Netsil',
-			logo: 'netsil',
-			link: 'https://netsil.com/kubernetes/',
-			blurb: 'Generate a real-time, auto-discovered application topology map! Monitor Kubernetes pods and namespaces without any code instrumentation.'
-			},
-		{
-			type: 2,
-			name: 'Treasure Data',
-			logo: 'treasuredata',
-			link: 'https://fluentd.treasuredata.com/kubernetes-logging/',
-			blurb: 'Fluentd Enterprise brings smart, secure logging to Kubernetes, and brings integrations with backends such as Splunk, Kafka, or AWS S3.'
-			},
-		{
-			type: 2,
-			name: 'Kenzan',
-			logo: 'Kenzan',
-			link: 'http://kenzan.com/?ref=kubernetes',
-			blurb: 'We provide custom consulting services leveraging Kubernetes as our foundation. This involves the platform development, delivery pipelines, and the application development within Kubernetes.'
-			},
-		{
-			type: 2,
-			name: 'New Context',
-			logo: 'newcontext',
-			link: 'https://www.newcontext.com/devsecops-infrastructure-automation-orchestration/',
-			blurb: 'New Context builds and uplifts secure Kubernetes implementations and migrations, from initial design to infrastructure automation and management.'
-			},
-		{
-			type: 2,
-			name: 'Banzai',
-			logo: 'banzai',
-			link: 'https://banzaicloud.com/platform/',
-			blurb: 'Banzai Cloud brings cloud native to the enterprise and simplifies the transition to microservices on Kubernetes.'
-			},
-		{
-			type: 3,
-			name: 'Kublr',
-			logo: 'kublr',
-			link: 'http://kublr.com',
-			blurb: 'Kublr - Accelerate and control the deployment, scaling, monitoring and management of your containerized applications.'
-			},
-		{
-			type: 1,
-			name: 'ControlPlane',
-			logo: 'controlplane',
-			link: 'https://control-plane.io',
-			blurb: 'We are a London-based Kubernetes consultancy with a focus on security and continuous delivery. We offer consulting & training.'
-			},
-		{
-			type: 3,
-			name: 'Nirmata',
-			logo: 'nirmata',
-			link: 'https://www.nirmata.com/',
-			blurb: 'Nirmata - Nirmata Managed Kubernetes'
-				},
-		{
-			type: 2,
-			name: 'Nirmata',
-			logo: 'nirmata',
-			link: 'https://www.nirmata.com/',
-			blurb: 'Nirmata is a software platform that helps DevOps teams deliver enterprise-grade and cloud-provider agnostic Kubernetes based container management solutions.'
-				},
-		{
-			type: 3,
-			name: 'TenxCloud',
-			logo: 'tenxcloud',
-			link: 'https://tenxcloud.com',
-			blurb: 'TenxCloud - TenxCloud Container Engine (TCE)'
-				},
-		{
-			type: 2,
-			name: 'TenxCloud',
-			logo: 'tenxcloud',
-			link: 'https://www.tenxcloud.com/',
-			blurb: 'Founded in October 2014, TenxCloud is a leading enterprise container cloud computing service provider in China, covering the areas such as container PaaS cloud platform, micro-service management, DevOps, development test, AIOps and so on. Provide private cloud PaaS products and solutions for financial, energy, operator, manufacturing, education and other industry customers.'
-				},
-		{
-			type: 0,
-			name: 'Twistlock',
-			logo: 'twistlock',
-			link: 'https://www.twistlock.com/',
-			blurb: 'Security at Kubernetes Scale: Twistlock allows you to deploy fearlessly with assurance that your images and containers are free of vulnerabilities and protected at runtime.'
-				},
-		{
-			type: 0,
-			name: 'Endocode AG',
-			logo: 'endocode',
-			link: 'https://endocode.com/kubernetes/',
- 			blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
-			},
-		{
-			type: 2,
-			name: 'Accenture',
-			logo: 'accenture',
-			link: 'https://www.accenture.com/us-en/service-application-containers',
-	 		blurb: 'Architecture, implementation and operation of world-class Kubernetes solutions for cloud-native clients.'
-			},
-		{
-			type: 1,
-			name: 'Biarca',
-			logo: 'biarca',
-			link: 'http://biarca.io/',
-		 	blurb: 'Biarca is a cloud services provider and key focus areas Key areas of focus for Biarca include Cloud Adoption Services, Infrastructure Services, DevOps Services and Application Services. Biarca leverages Kubernetes to deliver containerized solutions.'
-			},
-		{
-			type: 2,
-			name: 'Claranet',
-			logo: 'claranet',
-			link: 'http://www.claranet.co.uk/hosting/google-cloud-platform-consulting-managed-services',
-			blurb: 'Claranet helps people migrate to the cloud and take full advantage of the new world it offers. We consult, design, build and proactively manage the right infrastructure and automation tooling for clients to achieve this.'
-			},
-		{
-			type: 1,
-			name: 'CloudKite',
-			logo: 'cloudkite',
-			link: 'https://cloudkite.io/',
-			blurb: 'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.'
-			},
-		{
-			type: 2,
-			name: 'CloudOps',
-			logo: 'CloudOps',
-			link: 'https://www.cloudops.com/services/docker-and-kubernetes-workshops/',
-			blurb: 'CloudOps gets you hands-on with the K8s ecosystem via workshop/lab. Get prod ready K8s in cloud(s) of your choice with our managed services.'
-			},
-		{
-			type: 2,
-			name: 'Ghostcloud',
-			logo: 'ghostcloud',
-			link: 'https://www.ghostcloud.cn/ecos-kubernetes',
-			blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.'
-			},
-		{
-			type: 3,
-			name: 'Ghostcloud',
-			logo: 'ghostcloud',
-			link: 'https://www.ghostcloud.cn/ecos-kubernetes',
-			blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.'
-			},
-		{
-			type: 2,
-			name: 'Contino',
-			logo: 'contino',
-			link: 'https://www.contino.io/',
-			blurb: 'We help enterprise organizations adopt DevOps, containers and cloud computing. Contino is a global consultancy that enables regulated organizations to accelerate innovation through the adoption of modern approaches to software delivery.'
-			},
-		{
-			type: 2,
-			name: 'Booz Allen Hamilton',
-			logo: 'boozallenhamilton',
-			link: 'https://www.boozallen.com/',
-			blurb: 'Booz Allen partners with public and private sector clients to solve their most difficult challenges through a combination of consulting, analytics, mission operations, technology, systems delivery, cybersecurity, engineering, and innovation expertise.'
-			},
-		{
-			type: 1,
-			name: 'BigBinary',
-			logo: 'bigbinary',
-			link: 'http://blog.bigbinary.com/categories/Kubernetes',
-			blurb: 'Provider of Digital Solutions for federal and commercial clients, to include DevSecOps, cloud platforms, transformation strategy, cognitive solutions, and UX.'
-				},
-		{
-			type: 0,
-			name: 'CloudPerceptions',
-			logo: 'cloudperceptions',
-			link: 'https://www.meetup.com/Triangle-Kubernetes-Meetup/files/',
-			blurb: 'Container security solution for small-to-medium size enterprises who plan to run Kubernetes on shared infrastructure.'
-				},
-		{
-			type: 2,
-			name: 'Creationline, Inc.',
-			logo: 'creationline',
-			link: 'https://www.creationline.com/ci',
-			blurb: 'Total solution for container based IT resource management.'
-				},
-		{
-			type: 0,
-			name: 'DataCore Software',
-			logo: 'datacore',
-			link: 'https://www.datacore.com/solutions/virtualization/containerization',
-			blurb: 'DataCore provides highly-available, high-performance universal block storage for Kubernetes, radically improving the speed of deployment.'
-				},
-		{
-			type: 0,
-			name: 'Elastifile',
-			logo: 'elastifile',
-			link: 'https://www.elastifile.com/stateful-containers',
-			blurb: 'Elastifile’s cross-cloud data fabric delivers elastically scalable, high performance, software-defined persistent storage for Kubernetes.'
-				},
-		{
-			type: 0,
-			name: 'GitLab',
-			logo: 'gitlab',
-			link: 'https://about.gitlab.com/2016/11/14/idea-to-production/',
-			blurb: 'With GitLab and Kubernetes, you can deploy a complete CI/CD pipeline with multiple environments, automatic deployments, and automatic monitoring.'
-				},
-		{
-			type: 0,
-			name: 'Gravitational, Inc.',
-			logo: 'gravitational',
-			link: 'https://gravitational.com/telekube/',
-			blurb: 'Telekube combines Kubernetes with Teleport, our modern SSH server, so operators can remotely manage a multitude of K8s application deployments.'
-				},
-		{
-			type: 0,
-			name: 'Hitachi Data Systems',
-			logo: 'hitachi',
-			link: 'https://www.hds.com/en-us/products-solutions/application-solutions/unified-compute-platform-with-kubernetes-orchestration.html',
-			blurb: 'Build the Applications You Need to Drive Your Business - DEVELOP AND DEPLOY APPLICATIONS FASTER AND MORE RELIABLY.'
-				},
-		{
-			type: 1,
-			name: 'Infosys Technologies',
-			logo: 'infosys',
-			link: 'https://www.infosys.com',
-			blurb: 'Monolithic to microservices on openshift is a offering that we are building as part of open source practice.'
-				},
-		{
-			type: 0,
-			name: 'JFrog',
-			logo: 'jfrog',
-			link: 'https://www.jfrog.com/use-cases/12584/',
-			blurb: 'You can use Artifactory to store and manage all of your application’s container images and deploy to Kubernetes and setup a build, test, deploy pipeline using Jenkins and Artifactory. Once an image is ready to be rolled out, Artifactory can trigger a rolling-update deployment into a Kubernetes cluster without downtime – automatically!'
-				},
-		{
-			type: 0,
-			name: 'Navops by Univa',
-			logo: 'navops',
-			link: 'https://www.navops.io',
-			blurb: 'Navops is a suite of products that enables enterprises to take full advantage of Kubernetes and provides the ability to quickly and efficiently run containers at scale.'
-				},
-		{
-			type: 0,
-			name: 'NeuVector',
-			logo: 'neuvector',
-			link: 'http://neuvector.com/solutions-for-kubernetes-security/',
-			blurb: 'NeuVector delivers an application and network intelligent container network security solution integrated with and optimized for Kubernetes.'
-				},
-		{
-			type: 1,
-			name: 'OpsZero',
-			logo: 'opszero',
-			link: 'https://www.opszero.com/kubernetes.html',
-			blurb: 'opsZero provides DevOps for Startups. We build and service your Kubernetes and Cloud Infrastructure to accelerate your release cycle.'
-				},
-		{
-			type: 1,
-			name: 'Shiwaforce.com Ltd.',
-			logo: 'shiwaforce',
-			link: 'https://www.shiwaforce.com/en/',
-			blurb: 'Shiwaforce.com is the Agile Partner in Digital Transformation. Our solutions follow business changes quickly, easily and cost-effectively.'
-				},
-		{
-			type: 1,
-			name: 'SoftServe',
-			logo: 'softserve',
-			link: 'https://www.softserveinc.com/en-us/blogs/kubernetes-travis-ci/',
-			blurb: 'SoftServe allows its clients to adopt modern application design patterns and benefit from fully integrated, highly available, cost effective Kubernetes clusters at any scale.'
-				},
-		{
-			type: 1,
-			name: 'Solinea',
-			logo: 'solinea',
-			link: 'https://www.solinea.com/cloud-consulting-services/container-microservices-offerings',
-			blurb: 'Solinea is a digital transformation consultancy that enables businesses to build innovative solutions by adopting cloud native computing.'
-				},
-		{
-			type: 1,
-			name: 'Sphere Software, LLC',
-			logo: 'spheresoftware',
-			link: 'https://sphereinc.com/kubernetes/',
-			blurb: 'The Sphere Software team of experts allows customers to architect and implement scalable applications using Kubernetes in Google Cloud, AWS, and Azure.'
-				},
-		{
-			type: 1,
-			name: 'Altoros',
-			logo: 'altoros',
-			link: 'https://www.altoros.com/container-orchestration-tools-enablement.html',
-			blurb: 'Deployment and configuration of Kubernetes, Optimization of existing solutions, training for developers on using Kubernetes, support.'
-				},
-		{
-			type: 0,
-			name: 'Cloudbase Solutions',
-			logo: 'cloudbase',
-			link: 'https://cloudbase.it/kubernetes',
-			blurb: 'Cloudbase Solutions provides Kubernetes cross-cloud interoperability for Windows and Linux deployments based on open source technologies.'
-				},
-		{
-			type: 0,
-			name: 'Codefresh',
-			logo: 'codefresh',
-			link: 'https://codefresh.io/kubernetes-deploy/',
-			blurb: 'Codefresh is a complete DevOps platform built for containers and Kubernetes. With CI/CD pipelines, image management, and deep integrations into Kubernetes and Helm.'
-				},
-		{
-			type: 0,
-			name: 'NetApp',
-			logo: 'netapp',
-			link: 'http://netapp.io/2016/12/23/introducing-trident-dynamic-persistent-volume-provisioner-kubernetes/',
-			blurb: 'Dynamic provisioning and persistent storage support.'
-				},
-		{
-			type: 0,
-			name: 'OpenEBS',
-			logo: 'OpenEBS',
-			link: 'https://openebs.io/',
- 			blurb: 'OpenEBS is containerized storage for containers integrated tightly into Kubernetes and based on distributed block storage and containerization of storage control. OpenEBS derives intent from K8s and other YAML or JSON such as per container QoS SLAs, tiering and replica policies, and more. OpenEBS is EBS API compliant.'
-				},
-		{
-			type: 3,
-			name: 'Google Kubernetes Engine',
-			logo: 'google',
-			link: 'https://cloud.google.com/kubernetes-engine/',
-			blurb: 'Google - Google Kubernetes Engine'
-				},
-		{
-			type: 1,
-			name: 'Superorbital',
-			logo: 'superorbital',
-			link: 'https://superorbit.al/workshops/kubernetes/',
-			blurb: 'Helping companies navigate the Cloud Native waters through Kubernetes consulting and training.'
-				},
-		{
-			type: 3,
-			name: 'Apprenda',
-			logo: 'apprenda',
-			link: 'https://apprenda.com/kismatic/',
-			blurb: 'Apprenda - Kismatic Enterprise Toolkit (KET)'
-				},
-		{
-			type: 3,
-			name: 'Red Hat',
-			logo: 'redhat',
-			link: 'https://www.openshift.com',
-			blurb: 'Red Hat - OpenShift Online and OpenShift Container Platform'
-				},
-		{
-			type: 3,
-			name: 'Rancher',
-			logo: 'rancher',
-			link: 'http://rancher.com/kubernetes/',
-			blurb: 'Rancher Inc. - Rancher Kubernetes'
-				},
-		{
-			type: 3,
-			name: 'Canonical',
-			logo: 'canonical',
-			link: 'https://www.ubuntu.com/kubernetes',
-			blurb: 'The Canonical Distribution of Kubernetes enables you to operate Kubernetes clusters on demand on any major public cloud and private infrastructure.'
-				},
-		{
-			type: 2,
-			name: 'Canonical',
-			logo: 'canonical',
-			link: 'https://www.ubuntu.com/kubernetes',
-			blurb: 'Canonical Ltd. - Canonical Distribution of Kubernetes'
-				},
-		{
-			type: 3,
-			name: 'Cisco',
-			logo: 'cisco',
-			link: 'https://www.cisco.com',
-			blurb: 'Cisco Systems - Cisco Container Platform'
-				},
-		{
-			type: 3,
-			name: 'Cloud Foundry',
-			logo: 'cff',
-			link: 'https://www.cloudfoundry.org/container-runtime/',
-			blurb: 'Cloud Foundry - Cloud Foundry Container Runtime'
-				},
-		{
-			type: 3,
-			name: 'IBM',
-			logo: 'ibm',
-			link: 'https://www.ibm.com/cloud/container-service',
-			blurb: 'IBM - IBM Cloud Kubernetes Service'
-				},
-		{
-			type: 2,
-			name: 'IBM',
-			logo: 'ibm',
-			link: 'https://www.ibm.com/cloud-computing/bluemix/containers',
-			blurb: 'The IBM Bluemix Container Service combines Docker and Kubernetes to deliver powerful tools, an intuitive user experiences, and built-in security and isolation to enable rapid delivery of applications all while leveraging Cloud Services including cognitive capabilities from Watson.'
-				},
-		{
-			type: 3,
-			name: 'Samsung',
-			logo: 'samsung_sds',
-			link: 'https://github.com/samsung-cnct/kraken',
-			blurb: 'Samsung SDS - Kraken'
-				},
-		{
-			type: 3,
-			name: 'IBM',
-			logo: 'ibm',
-			link: 'https://www.ibm.com/cloud-computing/products/ibm-cloud-private/',
-			blurb: 'IBM - IBM Cloud Private'
-				},
-		{
-			type: 3,
-			name: 'Kinvolk',
-			logo: 'kinvolk',
-			link: 'https://github.com/kinvolk/kube-spawn',
-			blurb: 'Kinvolk - kube-spawn'
-				},
-		{
-			type: 3,
-			name: 'Heptio',
-			logo: 'heptio',
-			link: 'https://aws.amazon.com/quickstart/architecture/heptio-kubernetes',
-			blurb: 'Heptio - AWS-Quickstart'
-				},
-		{
-			type: 2,
-			name: 'Heptio',
-			logo: 'heptio',
-			link: 'http://heptio.com',
-			blurb: 'Heptio helps businesses of all sizes get closer to the vibrant Kubernetes community.'
-				},
-		{
-			type: 3,
-			name: 'StackPointCloud',
-			logo: 'stackpoint',
-			link: 'https://stackpoint.io',
-			blurb: 'StackPointCloud - StackPointCloud'
-				},
-		{
-			type: 2,
-			name: 'StackPointCloud',
-			logo: 'stackpoint',
-			link: 'https://stackpoint.io',
-			blurb: 'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.'
-				},
-		{
-			type: 3,
-			name: 'Caicloud',
-			logo: 'caicloud',
-			link: 'https://caicloud.io/products/compass',
-			blurb: 'Caicloud - Compass'
-				},
-		{
-			type: 2,
-			name: 'Caicloud',
-			logo: 'caicloud',
-			link: 'https://caicloud.io/',
-			blurb: 'Founded by ex-Googlers,and early Kubernetes contributors, Caicloud leverages Kubernetes to provide container products which have successfully served Fortune 500 enterprises, and  further utilizes Kubernetes as a vehicle to deliver ultra-speed deep learning experience.'
-				},
-		{
-			type: 3,
-			name: 'Alibaba',
-			logo: 'alibaba',
-			link: 'https://www.aliyun.com/product/containerservice?spm=5176.8142029.388261.219.3836dbccRpJ5e9',
-			blurb: 'Alibaba Cloud - Alibaba Cloud Container Service'
-				},
-		{
-			type: 3,
-			name: 'Tencent',
-			logo: 'tencent',
-			link: 'https://cloud.tencent.com/product/ccs?lang=en',
-			blurb: 'Tencent Cloud - Tencent Cloud Container Service'
-				},
-		{
-			type: 3,
-			name: 'Huawei',
-			logo: 'huawei',
-			link: 'http://www.huaweicloud.com/product/cce.html',
-			blurb: 'Huawei - Huawei Cloud Container Engine'
-				},
-		{
-			type: 2,
-			name: 'Huawei',
-			logo: 'huawei',
-			link: 'http://developer.huawei.com/ict/en/site-paas',
-			blurb: 'FusionStage is an enterprise-grade Platform as a Service product, the core of which is based on mainstream open source container technology including Kubernetes and Docker.'
-				},
-		{
-			type: 3,
-			name: 'Google',
-			logo: 'google',
-			link: 'https://github.com/kubernetes/kubernetes/tree/master/cluster',
-			blurb: 'Google - kube-up.sh on Google Compute Engine'
-				},
-		{
-			type: 3,
-			name: 'Poseidon',
-			logo: 'poseidon',
-			link: 'https://typhoon.psdn.io/',
-			blurb: 'Poseidon - Typhoon'
-				},
-		{
-			type: 3,
-			name: 'Netease',
-			logo: 'netease',
-			link: 'https://www.163yun.com/product/container-service-dedicated',
-			blurb: 'Netease - Netease Container Service Dedicated'
-				},
-		{
-			type: 2,
-			name: 'Loodse',
-			logo: 'loodse',
-			link: 'https://loodse.com',
-			blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.'
-				},
-		{
-			type: 4,
-			name: 'Loodse',
-			logo: 'loodse',
-			link: 'https://loodse.com',
-			blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.'
-				},
-		{
-			type: 4,
-			name: 'LF Training',
-			logo: 'lf-training',
-			link: 'https://training.linuxfoundation.org/',
-			blurb: 'The Linux Foundation’s training program combines the broad, foundational knowledge with the networking opportunities that attendees need to thrive in their careers today.'
-				},
-		{
-			type: 3,
-			name: 'Loodse',
-			logo: 'loodse',
-			link: 'https://loodse.com',
-			blurb: 'Loodse - Kubermatic Container Engine'
-				},
-		{
-			type: 1,
-			name: 'LTI',
-			logo: 'lti',
-			link: 'https://www.lntinfotech.com/',
-			blurb: 'LTI helps enterprises architect, develop and support scalable cloud native apps using Docker and Kubernetes for private or public cloud.'
-				},
-		{
-			type: 3,
-			name: 'Microsoft',
-			logo: 'microsoft',
-			link: 'https://github.com/Azure/acs-engine',
-			blurb: 'Microsoft - Azure acs-engine'
-				},
-		{
-			type: 3,
-			name: 'Microsoft',
-			logo: 'microsoft',
-			link: 'https://docs.microsoft.com/en-us/azure/aks/',
-			blurb: 'Microsoft - Azure Container Service AKS'
-			  },
-		{
-			type: 3,
-			name: 'Oracle',
-			logo: 'oracle',
-			link: 'http://www.wercker.com/product',
-			blurb: 'Oracle - Oracle Container Engine'
-				},
-		{
-			type: 3,
-			name: 'Oracle',
-			logo: 'oracle',
-			link: 'https://github.com/oracle/terraform-kubernetes-installer',
-			blurb: 'Oracle -  Oracle Terraform Kubernetes Installer'
-				},
-		{
-			type: 3,
-			name: 'Mesosphere',
-			logo: 'mesosphere',
-			link: 'https://mesosphere.com/kubernetes/',
-			blurb: 'Mesosphere -  Kubernetes on DC/OS'
-				},
-		{
-			type: 3,
-			name: 'Appscode',
-			logo: 'appscode',
-			link: 'https://appscode.com/products/cloud-deployment/',
-			blurb: 'Appscode - Pharmer'
-				},
-		{
-			type: 3,
-			name: 'SAP',
-			logo: 'sap',
-			link: 'https://cloudplatform.sap.com/index.html',
-			blurb: 'SAP - Cloud Platform - Gardener (not yet released)'
-				},
-		{
-			type: 3,
-			name: 'Oracle',
-			logo: 'oracle',
-			link: 'https://www.oracle.com/linux/index.html',
-			blurb: 'Oracle - Oracle Linux Container Services for use with Kubernetes'
-				},
-		{
-			type: 3,
-			name: 'CoreOS',
-			logo: 'coreos',
-			link: 'https://github.com/kubernetes-incubator/bootkube',
-			blurb: 'CoreOS - bootkube'
-				},
-		{
-			type: 2,
-			name: 'CoreOS',
-			logo: 'coreos',
-			link: 'https://coreos.com/',
-			blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.'
-				},
-		{
-			type: 3,
-			name: 'Weaveworks',
-			logo: 'weave_works',
-			link: '/docs/setup/independent/create-cluster-kubeadm/',
-			blurb: 'Weaveworks - kubeadm'
-				},
-		{
-			type: 3,
-			name: 'Joyent',
-			logo: 'joyent',
-			link: 'https://github.com/joyent/triton-kubernetes',
-			blurb: 'Joyent - Triton Kubernetes'
-				},
-		{
-			type: 3,
-			name: 'Wise2c',
-			logo: 'wise2c',
-			link: 'http://www.wise2c.com/solution',
-			blurb: 'Wise2C Technology - WiseCloud'
-				},
-		{
-			type: 2,
-			name: 'Wise2c',
-			logo: 'wise2c',
-			link: 'http://www.wise2c.com',
-			blurb: 'Using Kubernetes to providing IT continuous delivery and Enterprise grade container management solution to Financial Industry.'
-				},
-		{
-			type: 3,
-			name: 'Docker',
-			logo: 'docker',
-			link: 'https://www.docker.com/enterprise-edition',
-			blurb: 'Docker - Docker Enterprise Edition'
-				},
-		{
-			type: 3,
-			name: 'Daocloud',
-			logo: 'daocloud',
-			link: 'http://www.daocloud.io/dce',
-			blurb: 'DaoCloud - DaoCloud Enterprise'
-				},
-		{
-			type: 2,
-			name: 'Daocloud',
-			logo: 'daocloud',
-			link: 'http://www.daocloud.io/dce',
-			blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.'
-				},
-		{
-			type: 4,
-			name: 'Daocloud',
-			logo: 'daocloud',
-			link: 'http://www.daocloud.io/dce',
-			blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.'
-				},
-		{
-			type: 3,
-			name: 'SUSE',
-			logo: 'suse',
-			link: 'https://www.suse.com/products/caas-platform/',
-			blurb: 'SUSE - SUSE CaaS (Container as a Service) Platform'
-				},
-		{
-			type: 3,
-			name: 'Pivotal',
-			logo: 'pivotal',
-			link: 'https://cloud.vmware.com/pivotal-container-service',
-			blurb: 'Pivotal/VMware - Pivotal Container Service (PKS)'
-				},
-		{
-			type: 3,
-			name: 'VMware',
-			logo: 'vmware',
-			link: 'https://cloud.vmware.com/pivotal-container-service',
-			blurb: 'Pivotal/VMware - Pivotal Container Service (PKS)'
-				},
-		{
-			type: 3,
-			name: 'Alauda',
-			logo: 'alauda',
-			link: 'http://www.alauda.cn/product/detail/id/68.html',
-			blurb: 'Alauda - Alauda EE'
-				},
-		{
-			type: 4,
-			name: 'Alauda',
-			logo: 'alauda',
-			link: 'http://www.alauda.cn/product/detail/id/68.html',
-			blurb: 'Alauda provides Kubernetes-Centric Enterprise Platform-as-a-Service offerings with a razor focus on delivering Cloud Native capabilities and DevOps best practices to enterprise customers across industries in China.'
-				},
-		{
-			type: 2,
-			name: 'Alauda',
-			logo: 'alauda',
-			link: 'www.alauda.io',
-			blurb: 'Alauda provides Kubernetes-Centric Enterprise Platform-as-a-Service offerings with a razor focus on delivering Cloud Native capabilities and DevOps best practices to enterprise customers across industries in China.'
-				},
-		{
-			type: 3,
-			name: 'EasyStack',
-			logo: 'easystack',
-			link: 'https://easystack.cn/eks/',
-			blurb: 'EasyStack - EasyStack Kubernetes Service (EKS)'
-				},
-		{
-			type: 3,
-			name: 'CoreOS',
-			logo: 'coreos',
-			link: 'https://coreos.com/tectonic/',
-			blurb: 'CoreOS - Tectonic'
-				},
-		{
-			type: 0,
-			name: 'GoPaddle',
-			logo: 'gopaddle',
-			link: 'https://gopaddle.io',
-			blurb: 'goPaddle is a DevOps platform for Kubernetes developers. It simplifies the Kubernetes Service creation and maintenance through source to image conversion, build & version management, team management, access controls and audit logs, single click provision of Kubernetes Clusters across multiple clouds from a single console.'
-				},
-		{
-			type: 0,
-			name: 'Vexxhost',
-			logo: 'vexxhost',
-			link: 'https://vexxhost.com/public-cloud/container-services/kubernetes/',
-			blurb: 'VEXXHOST offers a high-performance container management service powered by Kubernetes and OpenStack Magnum.'
-				},
-		{
-			type: 1,
-			name: 'Component Soft',
-			logo: 'componentsoft',
-			link: 'https://www.componentsoft.eu/?p=3925',
-			blurb: 'Component Soft offers training, consultation and support around open cloud technologies like Kubernetes, Docker, Openstack and Ceph.'
-				},
-		{
-			type: 0,
-			name: 'Datera',
-			logo: 'datera',
-			link: 'http://www.datera.io/kubernetes/',
-			blurb: 'Datera delivers high performance, self-managing elastic block storage with self-service provisioning for deploying Kubernetes at scale.'
-				},
-		{
-			type: 0,
-			name: 'Containership',
-			logo: 'containership',
-			link: 'https://containership.io/',
-			blurb: 'Containership is a cloud agnostic managed kubernetes offering that supports automatic provisioning on over 14 cloud providers.'
-				},
-		{
-			type: 0,
-			name: 'Pure Storage',
-			logo: 'pure_storage',
-			link: 'https://hub.docker.com/r/purestorage/k8s/',
-			blurb: 'Our flexvol driver and dynamic provisioner allow FlashArray/Flashblade storage devices to be consumed as first class persistent storage from within Kubernetes.'
-				},
-		{
-			type: 0,
-			name: 'Elastisys',
-			logo: 'elastisys',
-			link: 'https://elastisys.com/kubernetes/',
-			blurb: 'Predictive autoscaling - detects recurring workload variations, irregular traffic spikes, and everything in between. Runs K8s in any public or private cloud.'
-				},
-		{
-			type: 0,
-			name: 'Portworx',
-			logo: 'portworx',
-			link: 'https://portworx.com/use-case/kubernetes-storage/',
-			blurb: 'With Portworx, you can manage any database or stateful service on any infrastructure using Kubernetes. You get a single data management layer for all of your stateful services, no matter where they run.'
-				},
-		{
-			type: 1,
-			name: 'Object Computing, Inc.',
-			logo: 'objectcomputing',
-			link: 'https://objectcomputing.com/services/software-engineering/devops/kubernetes-services',
-			blurb: 'Our portfolio of DevOps consulting services includes Kubernetes support, development, and training.'
-				},
-		{
-			type: 1,
-			name: 'Isotoma',
-			logo: 'isotoma',
-			link: 'https://www.isotoma.com/blog/2017/10/24/containerisation-tips-for-using-kubernetes-with-aws/',
-			blurb: 'Based in the North of England, Amazon partners who are delivering Kubernetes solutions on AWS for replatforming and native development.'
-				},
-		{
-			type: 1,
-			name: 'Servian',
-			logo: 'servian',
-			link: 'https://www.servian.com/cloud-and-technology/',
-			blurb: 'Based in Australia, Servian provides advisory, consulting and managed services to support both application and data centric kubernetes use cases.'
-				},
-		{
-			type: 1,
-			name: 'Redzara',
-			logo: 'redzara',
-			link: 'http://redzara.com/cloud-service',
-			blurb: 'Redzara has wide and in-depth experience in Cloud automation, now taking one giant step by providing container service offering and services to our customers.'
-				},
-		{
-			type: 0,
-			name: 'Dataspine',
-			logo: 'dataspine',
-			link: 'http://dataspine.xyz/',
-			blurb: 'Dataspine is building a secure, elastic and serverless deployment platform for production ML/AI workloads on top of k8s.'
-				},
-		{
-			type: 1,
-			name: 'CloudBourne',
-			logo: 'cloudbourne',
-			link: 'https://cloudbourne.com/kubernetes-enterprise-hybrid-cloud/',
-			blurb: 'Want to achieve maximum build, deploy and monitoring automation using Kubernetes? We can help.'
-				},
-		{
-			type: 0,
-			name: 'CloudBourne',
-			logo: 'cloudbourne',
-			link: 'https://cloudbourne.com/',
-			blurb: 'Our AppZ Hybrid Cloud Platform can help you achieve your digital transformation goals using the powerful Kubernetes.'
-				},
-		{
-			type: 3,
-			name: 'BoCloud',
-			logo: 'bocloud',
-			link: 'http://www.bocloud.com.cn/en/index.html',
-			blurb: 'BoCloud - BeyondcentContainer'
-				},
-		{
-			type: 2,
-			name: 'Naitways',
-			logo: 'naitways',
-			link: 'https://www.naitways.com/',
-			blurb: 'Naitways is an Operator (AS57119), Integrator and Cloud Services Provider (our own !). We aim to provide value-added services through our mastering of the whole value chain (Infrastructure, Network, Human skills). Private and Public Cloud is available through Kubernetes managed or unmanaged.'
-				},
-		{
-			type: 2,
-			name: 'Kinvolk',
-			logo: 'kinvolk',
-			link: 'https://kinvolk.io/kubernetes/',
-			blurb: 'Kinvolk offers Kubernetes engineering & operations support from cluster to kernel. Leading cloud-native organizations turn to Kinvolk for deep-stack Linux expertise.'
-				},
-		{
-			type: 1,
-			name: 'Cascadeo Corporation',
-			logo: 'cascadeo',
-			link: 'http://www.cascadeo.com/',
-			blurb: 'Cascadeo designs, implements, and manages containerized workloads with Kubernetes, for both existing applications and greenfield development projects.'
-				},
-		{
-			type: 1,
-			name: 'Elastisys AB',
-			logo: 'elastisys',
-			link: 'https://elastisys.com/services/#kubernetes',
-			blurb: 'We design, build, and operate Kubernetes clusters. We are experts in highly available and self-optimizing Kubernetes infrastructures'
-				},
-		{
-			type: 1,
-			name: 'Greenfield Guild',
-			logo: 'greenfield',
-			link: 'http://greenfieldguild.com/',
-			blurb: 'The Greenfield Guild builds quality open source solutions on, and offers training and support for, Kubernetes in any environment.'
-				},
-		{
-			type: 1,
-			name: 'PolarSeven',
-			logo: 'polarseven',
-			link: 'https://polarseven.com/what-we-do/kubernetes/',
-			blurb: 'To get started up and running with Kubernetes (K8s) our PolarSeven consultants can help you with creating a fully functional dockerized environment to run and deploy your applications.'
-				},
-		{
-			type: 1,
-			name: 'Kloia',
-			logo: 'kloia',
-			link: 'https://kloia.com/kubernetes/',
-			blurb: 'Kloia is DevOps and Microservices Consultancy company that helps its customers to migrate their environment to cloud platforms for enabling more scalable and secure environments. We use Kubernetes to provide our customers all-in-one solutions in an cloud-agnostic way.'
-				},
-		{
-			type: 0,
-			name: 'Bluefyre',
-			logo: 'bluefyre',
-			link: 'https://www.bluefyre.io',
-			blurb: 'Bluefyre offers a developer-first security platform that is native to Kubernetes. Bluefyre helps your development team ship secure code on Kubernetes faster!'
-				},
-		{
-			type: 0,
-			name: 'Harness',
-			logo: 'harness',
-			link: 'https://harness.io/harness-continuous-delivery/secret-sauce/smart-automation/',
-			blurb: 'Harness offers Continuous Delivery As-A-Service will full support for containerized apps and Kubernetes clusters.'
-				},
-		{
-			type: 0,
-			name: 'VMware - Wavefront',
-			logo: 'wavefront',
-			link: 'https://www.wavefront.com/solutions/container-monitoring/',
-			blurb: 'The Wavefront platform provides metrics-driven analytics and monitoring for  Kubernetes and container dashboards for DevOps and developer teams delivering visibility into high-level services as well as granular container metrics.'
-				},
-		{
-			type: 0,
-			name: 'Bloombase, Inc.',
-			logo: 'bloombase',
-			link: 'https://www.bloombase.com/go/kubernetes',
-			blurb: 'Bloombase provides high bandwidth, defense-in-depth data-at-rest encryption to lock down Kubernetes crown-jewels at scale.'
-				},
-		{
-			type: 0,
-			name: 'Kasten',
-			logo: 'kasten',
-			link: 'https://kasten.io/product/',
-			blurb: 'Kasten provides enterprise solutions specifically built to address the operational complexity of data management in cloud-native environments.'
-				},
-		{
-			type: 0,
-			name: 'Humio',
-			logo: 'humio',
-			link: 'https://humio.com',
-			blurb: 'Humio is a log aggregation database. We offer a Kubernetes integration that will give you insights to your logs across apps and instances.'
-				},
-		{
-			type: 0,
-			name: 'Outcold Solutions LLC',
-			logo: 'outcold',
-			link: 'https://www.outcoldsolutions.com/#monitoring-kubernetes',
-			blurb: 'Powerful Certified Splunk applications for Monitoring OpenShift, Kubernetes and Docker.'
-				},
-		{
-			type: 0,
-			name: 'SysEleven GmbH',
-			logo: 'syseleven',
-			link: 'http://www.syseleven.de/',
-			blurb: 'Enterprise Customers who are in need of bulletproof operations (High Performance E-Commerce and Enterprise Portals)'
-				},
-		{
-			type: 0,
-			name: 'Landoop',
-			logo: 'landoop',
-			link: 'http://lenses.stream',
-			blurb: 'Lenses for Apache Kafka, to deploy, manage and operate with confidence data streaming pipelines and topologies at scale with confidence and native Kubernetes integration.'
-				},
-		{
-			type: 0,
-			name: 'Redis Labs',
-			logo: 'redis',
-			link: 'https://redislabs.com/blog/getting-started-with-kubernetes-and-redis-using-redis-enterprise/',
-			blurb: 'Redis Enterprise extends open source Redis and delivers stable high performance and linear scaling required for building microservices on the Kubernetes platform.'
-				},
-		{
-			type: 3,
-			name: 'Diamanti',
-			logo: 'diamanti',
-			link: 'https://diamanti.com/',
-			blurb: 'Diamanti - Diamanti-D10'
-				},
-		{
-			type: 3,
-			name: 'Eking',
-			logo: 'eking',
-			link: 'http://www.eking-tech.com/',
-			blurb: 'Hainan eKing Technology Co. - eKing Cloud Container Platform'
-				},
-		{
-			type: 3,
-			name: 'Harmony Cloud',
-			logo: 'harmony',
-			link: 'http://harmonycloud.cn/products/rongqiyun/',
-			blurb: 'Harmonycloud - Harmonycloud Container Platform'
-				},
-		{
-			type: 3,
-			name: 'Woqutech',
-			logo: 'woqutech',
-			link: 'http://woqutech.com/product_qfusion.html',
-			blurb: 'Woqutech - QFusion'
-				},
-		{
-			type: 3,
-			name: 'Baidu',
-			logo: 'baidu',
-			link: 'https://cloud.baidu.com/product/cce.html',
-			blurb: 'Baidu Cloud - Baidu Cloud Container Engine'
-				},
-		{
-			type: 3,
-			name: 'ZTE',
-			logo: 'zte',
-			link: 'https://sdnfv.zte.com.cn/en/home',
-			blurb: 'ZTE - TECS OpenPalette'
-				},
-		{
-			type: 1,
-			name: 'Automatic Server AG',
-			logo: 'asag',
-			link: 'http://www.automatic-server.com/paas.html',
-			blurb: 'We install and operate Kubernetes in big enterprises, create deployment workflows and help to migrate.'
-				},
-		{
-			type: 1,
-			name: 'Circulo Siete',
-			logo: 'circulo',
-			link: 'https://circulosiete.com/consultoria/kubernetes/',
-			blurb: 'We are a Mexico based company offering training, consulting and support to migrate your workloads to Kubernetes, Cloud Native Microservices & Devops.'
-				},
-		{
-			type: 1,
-			name: 'DevOpsGuru',
-			logo: 'devopsguru',
-			link: 'http://devopsguru.ca/workshop',
-			blurb: 'DevOpsGuru work with small business to transform from physical to virtual to containerization.'
-				},
-		{
-			type: 1,
-			name: 'EIN Intelligence Co., Ltd',
-			logo: 'ein',
-			link: 'https://ein.io',
-			blurb: 'Startups and agile enterprises in South Korea.'
-				},
-		{
-			type: 0,
-			name: 'GuardiCore',
-			logo: 'guardicore',
-			link: 'https://www.guardicore.com/',
-			blurb: 'GuardiCore provided process level visibility and network policy enforcement on containerized assets on the Kubernetes platform.'
-				},
-		{
-			type: 0,
-			name: 'Hedvig',
-			logo: 'hedvig',
-			link: 'https://www.hedviginc.com/blog/provisioning-hedvig-storage-with-kubernetes',
-			blurb: 'Hedvig is software-defined storage that uses NFS or iSCSI for persistent volumes for provisioning shared storage for pods and containers.'
-				},
-		{
-			type: 0,
-			name: 'Hewlett Packard Enterprise',
-			logo: 'hpe',
-			link: ' https://www.hpe.com/us/en/storage/containers.html',
-			blurb: 'Persistent Storage that makes data as easy to manage as containers: dynamic provisioning, policy-based performance & protection, QoS, & more.'
-				},
-		{
-			type: 0,
-			name: 'JetBrains',
-			logo: 'jetbrains',
-			link: 'https://blog.jetbrains.com/teamcity/2017/10/teamcity-kubernetes-support-plugin/',
-			blurb: 'Run TeamCity cloud build agents in a Kubernetes cluster. Provides Helm support as a build step.'
-				},
-		{
-			type: 2,
-			name: 'Opensense',
-			logo: 'opensense',
-			link: 'http://www.opensense.fr/en/kubernetes-en/',
-			blurb: 'We provide Kubernetes services (integration, operation, training) as well as development of banking microservices based on our extended experience with cloud of containers, microservices, data management and financial sector.'
-				},
-		{
-			type: 2,
-			name: 'SAP SE',
-			logo: 'sap',
-			link: 'https://cloudplatform.sap.com',
-			blurb: 'The SAP Cloud Platform provides in-memory capabilities and unique business services for building and extending applications. With open sourced Project Gardener, SAP utilizes the power of Kubernetes to enable an open, robust, multi-cloud experience for our customers. You can use simple, modern cloud native design principles and leverage skills your organization already has to deliver agile and transformative applications, while integrating with the latest SAP Leonardo business features.'
-				},
-		{
-			type: 1,
-			name: 'Mobilise Cloud Services Limited',
-			logo: 'mobilise',
-			link: 'https://www.mobilise.cloud/en/services/serverless-application-delivery/',
-			blurb: 'Mobilise helps organisations adopt Kubernetes and integrate with their CI/CD tooling.'
-				},
-		{
-			type: 3,
-			name: 'AWS',
-			logo: 'aws',
-			link: 'https://aws.amazon.com/eks/',
-			blurb: 'Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a managed service that makes it easy for you to run Kubernetes on AWS without needing to install and operate your own Kubernetes clusters.'
-				},
-		{
-			type: 3,
-			name: 'Kontena',
-			logo: 'kontena',
-			link: 'https://pharos.sh',
-			blurb: 'Kontena Pharos - The simple, solid, certified Kubernetes distribution that just works.'
-					},
-		{
-			type: 2,
-			name: 'NTTData',
-			logo: 'nttdata',
-			link: 'http://de.nttdata.com/altemista-cloud',
-			blurb: 'NTT DATA, a member of the NTT Group, brings the power of the worlds leading infrastructure provider in the global K8s community.'
-					},
-		{
-			type: 2,
-			name: 'OCTO',
-			logo: 'octo',
-			link: 'https://www.octo.academy/fr/formation/275-kubernetes-utiliser-architecturer-et-administrer-une-plateforme-de-conteneurs',
-			blurb: 'OCTO technology provides training, architecture, technical consulting and delivery services including containers and Kubernetes.'
-					},
-		{
-			type: 0,
-			name: 'Logdna',
-			logo: 'logdna',
-			link: 'https://logdna.com/kubernetes',
-			blurb: 'Pinpoint production issues instantly with LogDNA, the best logging platform you will ever use. Get started with only 2 kubectl commands.'
-				}
-	]
-
-	var kcspContainer = document.getElementById('kcspContainer')
-	var distContainer = document.getElementById('distContainer')
-	var ktpContainer = document.getElementById('ktpContainer')
-	var isvContainer = document.getElementById('isvContainer')
-	var servContainer = document.getElementById('servContainer')
-
-	var sorted = partners.sort(function (a, b) {
-		if (a.name > b.name) return 1
-		if (a.name < b.name) return -1
-		return 0
-	})
-
-	sorted.forEach(function (obj) {
-		var box = document.createElement('div')
-		box.className = 'partner-box'
-
-		var img = document.createElement('img')
-		img.src = '/images/square-logos/' + obj.logo + '.png'
-
-		var div = document.createElement('div')
-
-		var p = document.createElement('p')
-		p.textContent = obj.blurb
-
-		var link = document.createElement('a')
-		link.href = obj.link
-		link.target = '_blank'
-		link.textContent = 'Learn more'
-
-		div.appendChild(p)
-		div.appendChild(link)
-
-		box.appendChild(img)
-		box.appendChild(div)
-
-		var container;
-    if (obj.type === 0) {
-      container = isvContainer;
-    } else if (obj.type === 1) {
-      container = servContainer;
-    } else if (obj.type === 2) {
-      container = kcspContainer;
-		} else if (obj.type === 3) {
-			container = distContainer;
-		} else if (obj.type === 4) {
-			container = ktpContainer;
-		}
-
-		container.appendChild(box)
-	})
-})();
diff --git a/content/zh/includes/partner-style.css b/content/zh/includes/partner-style.css
index 7aeb255dd5..dc120872e0 100644
--- a/content/zh/includes/partner-style.css
+++ b/content/zh/includes/partner-style.css
@@ -82,7 +82,6 @@
 .button{
   max-width: 100%;
 	box-sizing: border-box;
-	font-family: "Roboto", sans-serif;
 	margin: 0;
 	display: inline-block;
 	border-radius: 6px;
diff --git a/content/zh/includes/task-tutorial-prereqs.md b/content/zh/includes/task-tutorial-prereqs.md
index acd083bde5..88e2f9fcf5 100644
--- a/content/zh/includes/task-tutorial-prereqs.md
+++ b/content/zh/includes/task-tutorial-prereqs.md
@@ -10,4 +10,4 @@ or you can use one of these Kubernetes playgrounds:
 -->
 
 * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
-* [Play with Kubernetes](http://labs.play-with-k8s.com/)
+* [玩转 Kubernetes](http://labs.play-with-k8s.com/)
diff --git a/content/zh/partners/_index.html b/content/zh/partners/_index.html
index 2dc39fee0e..3bbe08cdf4 100644
--- a/content/zh/partners/_index.html
+++ b/content/zh/partners/_index.html
@@ -7,13 +7,11 @@ cid: partners
 ---
 
 <!--
----
 title: Partners
 bigheader: Kubernetes Partners
 abstract: Growing the Kubernetes ecosystem.
 class: gridPage
 cid: partners
----
 -->
 
 <section id="users">
@@ -109,6 +107,3 @@ cid: partners
     {{< include "partner-style.css" >}}
 </style>
 
-<script>
-    {{< include "partner-script.js" >}}
-</script>
diff --git a/content/zh/docs/search.md b/content/zh/search.md
similarity index 100%
rename from content/zh/docs/search.md
rename to content/zh/search.md
diff --git a/content/zh/training/_index.html b/content/zh/training/_index.html
index ba3a2df60f..b70f1c9cb3 100644
--- a/content/zh/training/_index.html
+++ b/content/zh/training/_index.html
@@ -145,7 +145,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
   </div>
 </div>
diff --git a/i18n/en.toml b/i18n/en.toml
index c59107c7c8..899ffdd4bf 100644
--- a/i18n/en.toml
+++ b/i18n/en.toml
@@ -54,6 +54,18 @@ other = "I AM..."
 [docs_label_users]
 other = "Users"
 
+[docs_version_current]
+other = "(this documentation)"
+
+[docs_version_latest_heading]
+other = "Latest version"
+
+[docs_version_other_heading]
+other = "Older versions"
+
+[error_404_were_you_looking_for]
+other = "Were you looking for:"
+
 [examples_heading]
 other = "Examples"
 
@@ -141,12 +153,6 @@ other = """The Linux Foundation &reg;. All rights reserved. The Linux Foundation
 [main_documentation_license]
 other = """The Kubernetes Authors | Documentation Distributed under <a href="https://git.k8s.io/website/LICENSE" class="light-text">CC BY 4.0</a>"""
 
-[main_edit_this_page]
-other = "Edit This Page"
-
-[main_github_create_an_issue]
-other = "Create an Issue"
-
 [main_github_invite]
 other = "Interested in hacking on the core Kubernetes code base?"
 
@@ -186,6 +192,9 @@ other = "Objectives"
 [options_heading]
 other = "Options"
 
+[post_create_issue]
+other = "Create an issue"
+
 [prerequisites_heading]
 other = "Before you begin"
 
@@ -198,6 +207,9 @@ other = "Subscribe"
 [synopsis_heading]
 other = "Synopsis"
 
+[thirdparty_message]
+other = """This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects. This page follows <a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">CNCF website guidelines</a> by listing projects alphabetically. To add a project to this list, read the <a href="/docs/contribute/style/content-guide/#third-party-content">content guide</a> before submitting a change."""
+
 [ui_search_placeholder]
 other = "Search"
 
diff --git a/i18n/fr.toml b/i18n/fr.toml
index bd71ec1c6b..4cfc419cb7 100644
--- a/i18n/fr.toml
+++ b/i18n/fr.toml
@@ -118,7 +118,8 @@ other = "Utilisateurs"
 [docs_label_i_am]
 other = "JE SUIS..."
 
-
+[examples_heading]
+other = "Exemples"
 
 # Community links
 [community_twitter_name]
@@ -139,4 +140,4 @@ other = "Calendrier"
 other = "Recherche"
 
 [input_placeholder_email_address]
-other = "adresse email"
\ No newline at end of file
+other = "adresse email"
diff --git a/i18n/id.toml b/i18n/id.toml
index aa196a6758..101ea071ff 100644
--- a/i18n/id.toml
+++ b/i18n/id.toml
@@ -1,4 +1,35 @@
-# i18n strings for the Indonesian (main) site.
+# i18n strings for the Indonesian version of the site (https://kubernetes.io/id/)
+# NOTE: Please keep the entries in alphabetical order when editing
+
+[caution]
+other = "Perhatian:"
+
+[cleanup_heading]
+other = "Bersihkan"
+
+[community_events_calendar]
+other = "Kalender Acara"
+
+[community_forum_name]
+other = "Forum"
+
+[community_github_name]
+other = "GitHub"
+
+[community_slack_name]
+other = "Slack"
+
+[community_stack_overflow_name]
+other = "Stack Overflow"
+
+[community_twitter_name]
+other = "Twitter"
+
+[community_youtube_name]
+other = "YouTube"
+
+[deprecation_title]
+other = "Kamu sedang menampilkan dokumentasi untuk Kubernetes versi:"
 
 [deprecation_warning]
 other = " dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat "
@@ -6,77 +37,128 @@ other = " dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyal
 [deprecation_file_warning]
 other = "Sudah usang"
 
-[objectives_heading]
-other = "Tujuan"
+[docs_label_browse]
+other = "Telusuri Dokumentasi"
 
-[cleanup_heading]
-other = "Bersihkan"
+[docs_label_contributors]
+other = "Kontributor"
 
-[prerequisites_heading]
-other = "Sebelum mulai"
+[docs_label_i_am]
+other = "AKU..."
 
-[whatsnext_heading]
-other = "Selanjutnya"
+[docs_label_users]
+other = "Pengguna"
+
+[docs_version_current]
+other = "(dokumentasi ini)"
+
+[docs_version_latest_heading]
+other = "Versi terbaru"
+
+[docs_version_other_heading]
+other = "Versi lama"
+
+[error_404_were_you_looking_for]
+other = "Apakah kamu sedang mencari:"
+
+[examples_heading]
+other = "Contoh"
 
 [feedback_heading]
 other = "Masukan"
 
+[feedback_no]
+other = "Tidak"
+
 [feedback_question]
-other = "Apakah halaman ini berguna?"
+other = "Apakah halaman ini membantu?"
 
 [feedback_yes]
 other = "Ya"
 
-[feedback_no]
-other = "Tidak"
+[input_placeholder_email_address]
+other = "alamat email"
 
 [latest_version]
-other = "versi terkini."
+other = "versi terbaru."
 
-[version_check_mustbe]
-other = "Kubernetes servermu harus ada di versi "
+[layouts_blog_pager_prev]
+other = "<< Sebelumnya"
 
-[version_check_mustbeorlater]
-other = "Kubernetes servermu harus ada di versi yang sama atau lebih baru "
+[layouts_blog_pager_next]
+other = "Selanjutnya >>"
 
-[version_check_tocheck]
-other = "Untuk melihat versi, tekan "
+[layouts_case_studies_list_tell]
+other = "Ceritakan kisahmu"
 
-[caution]
-other = "Perhatian:"
+[layouts_docs_glossary_aka]
+other = "Dikenal juga sebagai"
 
-[note]
-other = "Catatan:"
+[layouts_docs_glossary_description]
+other = "Glosarium ini dimaksudkan sebagai daftar terminologi Kubernetes yang komprehensif dan terstandardisasi. Glosarium ini mencakup istilah-istilah teknis yang spesifik digunakan di Kubernetes, serta beberapa istilah umum untuk membantu memberikan konteks."
 
-[warning]
-other = "Peringatan:"
+[layouts_docs_glossary_deselect_all]
+other = "Hapus semua pilihan"
 
-[main_read_about]
-other = "Baca tentang"
+[layouts_docs_glossary_click_details_after]
+other = "indikator di bawah ini untuk mendapatkan penjelasan yang lebih lengkap untuk istilah tertentu."
 
-[main_read_more]
-other = "Baca lebih lanjut"
+[layouts_docs_glossary_click_details_before]
+other = "Klik pada"
 
-[main_github_invite]
-other = "Tertarik untuk ulik kode dari Kubernetes?"
+[layouts_docs_glossary_filter]
+other = "Filter istilah sesuai dengan penandanya"
 
-[main_github_view_on]
-other = "Lihat di GitHub"
+[layouts_docs_glossary_select_all]
+other = "Pilih semua"
 
-[main_github_create_an_issue]
-other = "Buat isu"
+[layouts_docs_partials_feedback_improvement]
+other = "beri saran perbaikan"
 
-[main_community_explore]
-other = "Jelajahi komunitasnya"
+[layouts_docs_partials_feedback_issue]
+other = "Buat isu di repositori GitHub jika kamu ingin "
 
-[main_kubernetes_features]
-other = "Fitur kubernetes"
+[layouts_docs_partials_feedback_or]
+other = "atau"
+
+[layouts_docs_partials_feedback_problem]
+other = "laporkan problem"
+
+[layouts_docs_partials_feedback_thanks]
+other = "Terima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di "
+
+[layouts_docs_search_fetching]
+other = "Mengambil hasil..."
+
+[main_by]
+other = "oleh"
 
 [main_cncf_project]
 other = """Kami merupakan proyek yang lulus dari <a href="https://cncf.io/">CNCF</a></p>"""
 
+[main_community_explore]
+other = "Jelajahi komunitas"
+
+[main_contribute]
+other = "Bantu"
+
+[main_copyright_notice]
+other = """Linux Foundation &reg;. Hak cipta dilindungi. Linux Foundation telah mendaftarkan merek dagang dan pengunaannya. Perinciannya bisa dilihat pada <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">halaman penggunaan merek dagang</a>"""
+
+[main_documentation_license]
+other = """Para Pencipta Kubernetes | Dokumentasi didistribusikan di bawah <a href="https://git.k8s.io/website/LICENSE" class="light-text">CC BY 4.0</a>"""
+
+[main_github_invite]
+other = "Tertarik untuk mengulik kode dari Kubernetes?"
+
+[main_github_view_on]
+other = "Lihat di GitHub"
+
+[main_kubernetes_features]
+other = "Fitur Kubernetes"
+
 [main_kubeweekly_baseline]
-other = "Tertarik untuk dapatkan info terkini tentang Kubernetes? Daftarkan dirimu di buletin KubeWeekly."
+other = "Tertarik untuk mendapatkan info terbaru tentang Kubernetes? Daftarkan dirimu ke KubeWeekly."
 
 [main_kubernetes_past_link]
 other = "Lihat buletin edisi sebelumnya"
@@ -84,59 +166,62 @@ other = "Lihat buletin edisi sebelumnya"
 [main_kubeweekly_signup]
 other = "Langganan"
 
-[main_contribute]
-other = "Kontribusi"
-
-[main_edit_this_page]
-other = "Ubah halaman ini"
-
 [main_page_history]
-other ="Riwayat halaman"
+other ="Riwayat laman"
 
 [main_page_last_modified_on]
 other = "Halaman diubah terakhir kali pada"
 
-[main_by]
-other = "oleh"
+[main_read_about]
+other = "Baca tentang"
 
-[main_documentation_license]
-other = """Para Pencipta Kubernetes | Dokumentasi didistribusikan melalui <a href="https://git.k8s.io/website/LICENSE" class="light-text">CC BY 4.0</a>"""
+[main_read_more]
+other = "Baca lebih lanjut"
 
-[main_copyright_notice]
-other = """Linux Foundation &reg;. Hak cipta dilindungi. Linux Foundation telah mendaftarkan merek dagang dan pengunaannya. Perinciannya bisa dilihat pada <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">halaman penggunaan merek dagang</a>"""
+[note]
+other = "Catatan:"
 
-# Labels for the docs portal home page.
-[docs_label_browse]
-other = "Lihat-lihat dokumentasi"
+[objectives_heading]
+other = "Tujuan"
 
-[docs_label_contributors]
-other = "Para kontributor"
+[options_heading]
+other = "Opsi"
 
-[docs_label_users]
-other = "Para pengguna"
+[post_create_issue]
+other = "Buat isu"
 
-[docs_label_i_am]
-other = "AKU ADALAH..."
+[prerequisites_heading]
+other = "Sebelum kamu memulai"
 
+[seealso_heading]
+other = "Lihat juga"
 
+[subscribe_button]
+other = "Langganan"
 
-# Community links
-[community_twitter_name]
-other = "Twitter"
-[community_github_name]
-other = "GitHub"
-[community_slack_name]
-other = "Slack"
-[community_stack_overflow_name]
-other = "Stack Overflow"
-[community_forum_name]
-other = "Forum"
-[community_events_calendar]
-other = "Kalender acara"
+[synopsis_heading]
+other = "Sinopsis"
+
+[thirdparty_message]
+other = """Bagian ini tertaut ke proyek-proyek pihak ketiga yang menyediakan fungsionalitas yang dibutuhkan oleh Kubernetes. Pencipta proyek Kubernetes tidak bertanggung jawab atas proyek-proyek tersebut. Laman ini mengikuti <a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">pedoman website CNCF</a> dengan membuat daftar proyek menurut abjad. Untuk menambakan proyek ke dalam daftar ini, bacalah <a href="/docs/contribute/style/content-guide/#third-party-content">panduan</a> sebelum mengirimkan perubahan."""
 
-# UI elements
 [ui_search_placeholder]
 other = "Cari"
 
-[input_placeholder_email_address]
-other = "Alamat email"
+[version_check_mustbe]
+other = "Kubernetes servermu harus dalam versi "
+
+[version_check_mustbeorlater]
+other = "Kubernetes servermu harus dalam versi yang sama atau lebih baru dari "
+
+[version_check_tocheck]
+other = "Untuk melihat versi, tekan "
+
+[version_menu]
+other = "Versi"
+
+[warning]
+other = "Peringatan:"
+
+[whatsnext_heading]
+other = "Selanjutnya"
diff --git a/i18n/ja.toml b/i18n/ja.toml
index 460e68b3f7..a7a103f435 100644
--- a/i18n/ja.toml
+++ b/i18n/ja.toml
@@ -28,12 +28,15 @@ other = "Twitter"
 [community_youtube_name]
 other = "YouTube"
 
-[deprecation_warning]
-other = " のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: "
-
 [deprecation_file_warning]
 other = "廃止予定"
 
+[deprecation_title]
+other = "現在表示しているのは、次のバージョン向けのドキュメントです。Kubernetesバージョン:"
+
+[deprecation_warning]
+other = " のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: "
+
 [docs_label_browse]
 other = "ドキュメントの参照"
 
diff --git a/i18n/pt.toml b/i18n/pt.toml
index 709011aa37..808c82679d 100644
--- a/i18n/pt.toml
+++ b/i18n/pt.toml
@@ -28,6 +28,9 @@ other = "Twitter"
 [deprecation_file_warning]
 other = "Descontinuado"
 
+[deprecation_title]
+other = "Você está vendo a documentação do Kubernetes versão:"
+
 [deprecation_warning]
 other = " a documentação não é mais mantida ativamente. A versão que você está visualizando no momento é uma captura instantânea estática. Para obter documentação atualizada, consulte "
 
@@ -43,6 +46,21 @@ other = "Eu sou..."
 [docs_label_users]
 other = "Usuários"
 
+[docs_version_current]
+other = "(esta documentação)"
+
+[docs_version_latest_heading]
+other = "Versão mais recente"
+
+[docs_version_other_heading]
+other = "Versões mais antigas"
+
+[error_404_were_you_looking_for]
+other = "Talvez você estivesse procurando por:"
+
+[examples_heading]
+other = "Exemplos"
+
 [feedback_heading]
 other = "Comentários"
 
@@ -173,12 +191,21 @@ other = "Nota:"
 [objectives_heading]
 other = "Objetivos"
 
+[options_heading]
+other = "Opções"
+
+[post_create_issue]
+other = "Abra um bug"
+
 [prerequisites_heading]
 other = "Antes de você começar"
 
 [subscribe_button]
 other = "Se inscrever"
 
+[thirdparty_message]
+other = """Esta seção tem links para projetos de terceiros que fornecem a funcionalidade exigida pelo Kubernetes. Os autores do projeto Kubernetes não são responsáveis por esses projetos. Esta página obedece as <a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">diretrizes de conteúdo do site CNCF</a>, listando os itens em ordem alfabética. Para adicionar um projeto a esta lista, leia o <a href="/docs/contribute/style/content-guide/#third-party-content">guia de conteúdo</a> antes de enviar sua alteração."""
+
 [ui_search_placeholder]
 other = "Procurar"
 
diff --git a/i18n/vi.toml b/i18n/vi.toml
index e2e2c5ee04..d65c07a720 100644
--- a/i18n/vi.toml
+++ b/i18n/vi.toml
@@ -174,6 +174,9 @@ other = "Mục tiêu"
 [prerequisites_heading]
 other = "Trước khi bắt đầu"
 
+[subscribe_button]
+other = "Đăng ký"
+
 [ui_search_placeholder]
 other = "Tìm kiếm"
 
diff --git a/i18n/zh.toml b/i18n/zh.toml
index 7446f8589a..4980f8d7fa 100644
--- a/i18n/zh.toml
+++ b/i18n/zh.toml
@@ -181,6 +181,9 @@ other = "教程目标"
 [options_heading]
 other = "选项"
 
+[post_create_child_page]
+other = "创建子页面"
+
 [prerequisites_heading]
 other = "准备开始"
 
@@ -193,6 +196,9 @@ other = "订阅"
 [synopsis_heading]
 other = "简介"
 
+[thirdparty_message]
+other = """本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循<a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">CNCF 网站指南</a>，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读<a href="/docs/contribute/style/content-guide/#third-party-content">内容指南</a>。"""
+
 [ui_search_placeholder]
 other = "搜索"
 
diff --git a/layouts/404.html b/layouts/404.html
index 5b18c48491..beef5c7999 100644
--- a/layouts/404.html
+++ b/layouts/404.html
@@ -1,29 +1,14 @@
 {{ define "main" }}
 {{ partial "handle-version-switch-404.html" . }}
-<div class="container-404">
-    <h4>
-        Perhaps you were looking for:
-    </h4>
-
-    <br />
-    <br />
-
-    <ul>
-        <li>
-            <a href="/docs">
-                The Kubernetes documentation
-            </a>
-        </li>
-        <li>
-            <a href="/blog">
-                The Kubernetes blog
-            </a>
-        </li>
-        <li>
-            <a href="/community">
-                The Kubernetes community
-            </a>
-        </li>
+<section id="error-404" class="error-details">
+    <p>
+    {{ T "error_404_were_you_looking_for" }}
+    </p>
+    <ul id="error-sections">
+        {{ $sections := slice "docs" "blog" "training" "partners" "community" "case-studies" }}
+        {{ range $sections }}
+        {{ with site.GetPage "section" . }}<li><a href="{{ .RelPermalink }}">{{ .Title }}</a></li>{{ end }}
+        {{ end }}
     </ul>
-</div>
+</section>
 {{ end }}
diff --git a/layouts/_default/search.html b/layouts/_default/search.html
new file mode 100644
index 0000000000..32c93338cf
--- /dev/null
+++ b/layouts/_default/search.html
@@ -0,0 +1,56 @@
+<!doctype html>
+<html lang="{{ .Site.Language.Lang }}" class="{{.Params.class}} no-js">
+  <head>
+    {{ partial "head.html" . }}
+  </head>
+  <body class="td-{{ .Kind }}{{- if ne .Params.cid "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">
+    <header>
+      {{ partial "navbar.html" . }}
+    </header>
+    {{ block "announcement" . }}
+      {{ if .IsHome }}
+        {{ partial "frontpage-announcement.html" . }}
+      {{ else }}
+        {{ partial "announcement.html" . }}
+      {{ end }}
+    {{ end }}
+    <div class="td-outer">
+      <main role="main" class="td-main">
+		<section class="row td-search-result">
+	      <div class="col-12 col-md-4 offset-md-2">
+		    <form class="td-sidebar__search d-flex align-items-center">
+		    {{ partial "search-input.html" . }}
+		    <button class="btn btn-link td-sidebar__toggle d-md-none p-0 ml-3 fas fa-bars" type="button" data-toggle="collapse" data-target="#td-section-nav" aria-controls="td-docs-nav" aria-expanded="false" aria-label="Toggle section navigation">
+		    </button>
+			</form>
+		  </div>
+		  <div class="col-12 col-md-8 offset-md-2">
+	        <h2 class="ml-4">{{ .Title }}</h2>
+			{{ if .Site.Params.gcs_engine_id }}
+			<script>
+		    (function() {
+		    var cx = '{{ . }}';
+		    var gcse = document.createElement('script');
+		    gcse.type = 'text/javascript';
+		    gcse.async = true;
+		    gcse.src = 'https://cse.google.com/cse.js?cx=' + cx;
+		    var s = document.getElementsByTagName('script')[0];
+		    s.parentNode.insertBefore(gcse, s);
+		    })();
+	        </script>
+	        <gcse:searchresults-only></gcse:searchresults-only>
+	        {{ else if .Site.Params.k8s_search }}
+		    <script src="{{ "js/search.js" | relURL }}"></script>
+		    <gcse:searchresults-only linktarget="_parent">
+		    <div id="bing-results-container">{{ T "layouts_docs_search_fetching" }}</div>
+		    <div id="bing-pagination-container"></div>
+		    </gcse:searchresults-only>
+	        {{ end }}
+		  </div>
+		</section>
+      </main>
+    {{ partial "footer.html" . }}
+    </div>
+    {{ partialCached "scripts.html" . }}
+  </body>
+</html>
diff --git a/layouts/blog/baseof.html b/layouts/blog/baseof.html
index 0e03cce7d5..d801da9d8a 100644
--- a/layouts/blog/baseof.html
+++ b/layouts/blog/baseof.html
@@ -4,8 +4,9 @@
     {{ partial "head.html" . }}
     <title>{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{ . }} | {{ end }}{{ .Site.Title }}{{ end }}</title>
     <script defer src="https://use.fontawesome.com/releases/v5.0.6/js/all.js"></script>
-    <!-- Disabled as Docsy is primarily handling styles for this template now -->
-    <!-- <link rel="stylesheet" type="text/css" href="{{ "css/blog.css" | relURL }}"> -->
+    {{ with .Params.canonicalUrl }}
+    <link rel="canonical" href="{{ . }}">
+    {{ end }}
   </head>
   <body class="td-{{ .Kind }} td-blog">
     <header>
@@ -39,7 +40,6 @@
           </main>
           <div class="d-none d-xl-block col-xl-2 td-toc d-print-none">
             {{ partial "blog-meta-links.html" . }}
-            {{ partial "toc.html" . }}
           </div>
         </div>
       </div>
diff --git a/layouts/case-studies/single-baseof.html b/layouts/case-studies/single-baseof.html
index 23b0894543..35d172626c 100644
--- a/layouts/case-studies/single-baseof.html
+++ b/layouts/case-studies/single-baseof.html
@@ -8,8 +8,6 @@
 		{{ partial "deprecation-warning.html" . }}
 		{{ block "main" . }}{{ end }}
 		{{ partialCached "footer.html" . }}
-		<!-- Disabling this as elements queries do not appear to exist on case studies -->
-		<!-- {{ partialCached "footer-scripts.html" . }} -->
     {{ partialCached "scripts.html" . }}
 
 	</body>
diff --git a/layouts/case-studies/single.html b/layouts/case-studies/single.html
index 2d8bbdad98..ad0335685a 100644
--- a/layouts/case-studies/single.html
+++ b/layouts/case-studies/single.html
@@ -2,6 +2,33 @@
 {{ with .Params.content_url }}
 <meta http-equiv="refresh" content="0; URL='{{ . }}'" />
 {{ else }}
-	{{ .Content }}
+	{{ if .Params.new_case_study_styles }}
+		<!-- Heading -->
+		<div class="banner {{ if .Params.use_gradient_overlay }}overlay{{ end }}" {{ if isset .Params "heading_background" }}style="background-image: url({{ .Params.heading_background }})"{{ end }}>
+			<h1>
+				<span class="heading">{{ .Params.title_prefix | default "CASE STUDY:" }}</span>
+				{{- if isset .Params "heading_title_logo" -}}
+					<img class="heading-logo" src="{{ .Params.heading_title_logo}}" />
+				{{- else if isset .Params "heading_title_text" -}}
+					{{- .Params.heading_title_text -}}
+				{{- end -}}
+				<span class="subheading">{{ .Params.subheading }}</span>
+			</h1>
+		</div>
+		<!-- Details -->
+		<div class="details">
+			{{ range $detail := .Params.case_study_details }}
+				{{ range $key, $value := $detail }}
+					<span class="item">{{ $key }} <strong>{{ $value }}</strong></span>
+				{{ end }}
+			{{ end }}
+		</div>
+		<!-- Content -->
+		<div class="content">
+			{{ .Content }}
+		</div>
+	{{ else }}
+		{{ .Content }}
+	{{ end }}
 {{ end }}
 {{ end }}
diff --git a/layouts/docs/baseof.html b/layouts/docs/baseof.html
index 04ca30871b..ec0b4d575a 100644
--- a/layouts/docs/baseof.html
+++ b/layouts/docs/baseof.html
@@ -25,7 +25,7 @@
             {{ if (and (not .Params.hide_feedback) (.Site.Params.ui.feedback.enable) (.Site.GoogleAnalytics)) }}
               {{ partial "feedback.html" .Site.Params.ui.feedback }}
             {{ end }}
-            {{ partial "git-info.html" . }}
+            <div class="text-muted mt-5 pt-3 border-top">{{ partial "page-meta-lastmod.html" . }}</div>
             {{ if (.Site.DisqusShortname) }}
               <br />
               {{ partial "disqus-comment.html" . }}
diff --git a/layouts/docs/search.html b/layouts/docs/search.html
deleted file mode 100644
index aeb918566e..0000000000
--- a/layouts/docs/search.html
+++ /dev/null
@@ -1,27 +0,0 @@
-{{ define "main" }}
-<section class="row td-search-result">
-<div class="col-12 col-md-8 offset-md-2">
-<h2 class="ml-4">{{ .Title }}</h2>
-{{ if .Site.Params.gcs_engine_id }}
-	<script>
-		(function() {
-		var cx = '{{ . }}';
-		var gcse = document.createElement('script');
-		gcse.type = 'text/javascript';
-		gcse.async = true;
-		gcse.src = 'https://cse.google.com/cse.js?cx=' + cx;
-		var s = document.getElementsByTagName('script')[0];
-		s.parentNode.insertBefore(gcse, s);
-		})();
-	</script>
-	<gcse:searchresults-only></gcse:searchresults-only>
-{{ else if .Site.Params.k8s_search }}
-<script src="{{ "js/search.js" | relURL }}"></script>
-	<gcse:searchresults-only linktarget="_parent">
-		<div id="bing-results-container">{{ T "layouts_docs_search_fetching" }}</div>
-		<div id="bing-pagination-container"></div>
-	</gcse:searchresults-only>
-{{ end }}
-</div>
-</section>
-{{ end }}
\ No newline at end of file
diff --git a/layouts/docs/supported-versions.html b/layouts/docs/supported-versions.html
new file mode 100644
index 0000000000..a1c2702741
--- /dev/null
+++ b/layouts/docs/supported-versions.html
@@ -0,0 +1,39 @@
+{{ define "main" }}
+    <div class="td-content">
+    {{ partial "docs/content-page" (dict "ctx" . "page" .) }}
+    {{ $versions := .Page.Param "versions" }}
+    {{ $thisPageRelUri := .Page.RelPermalink }}
+    {{ $thisVersionArray := split (.Page.Param "version") "." }}
+    {{ $.Scratch.Set "version-class" (slice "placeholder") }}
+    {{/* "placeholder" is also used later to check whether we opened the <ul> */}}
+    {{ range $index, $version := $versions }}
+    {{ $.Scratch.Set "version-class" (slice "") }}
+    {{ $versionArray := split .version "." }}
+
+    {{ if eq $index 0 }}
+    <h2 id="version-latest">{{ T "docs_version_latest_heading" }}</h2>
+    <ul>
+    {{ $.Scratch.Set "version-class" ($.Scratch.Get "version-class" | append "version-latest" ) }}
+    {{ end }}
+    {{ if eq $index 1 }}
+    </ul>
+    <h2 id="versions-older">{{ T "docs_version_other_heading" }}</h2>
+    <ul>
+    {{ end }}
+
+    {{ if eq .version ( delimit $thisVersionArray "." ) }}
+    {{ $.Scratch.Set "version-class" ($.Scratch.Get "version-class" | append "version-current" ) }}
+    {{ end }}
+
+    <li class="{{ delimit ( $.Scratch.Get "version-class") " " }}">
+        <a href="{{ .url }}{{ $thisPageRelUri }}">{{ .version }}</a>
+        {{ if eq .version ( delimit $thisVersionArray "." ) }}
+        {{ T "docs_version_current" }}
+        {{ end }}
+    </li>
+    {{ end }}
+    {{ if ne (index ($.Scratch.Get "version-class") 0) "placeholder" }}
+    </ul>
+    {{ end }}
+
+{{ end }}
\ No newline at end of file
diff --git a/layouts/partials/css.html b/layouts/partials/css.html
index c28d682e1f..7abfb21e72 100644
--- a/layouts/partials/css.html
+++ b/layouts/partials/css.html
@@ -2,8 +2,6 @@
 
 {{ $inServerMode := site.IsServer }}
 
-<link rel="stylesheet" href="/css/base_fonts.css">
-
 {{- if .Params.case_study_styles }}
   {{ $cssOutput := "css/case-studies.css" }}
   {{ $caseStudiesCSS := resources.Get "scss/_case-studies.scss" | resources.ToCSS }}
@@ -15,9 +13,8 @@
   {{ end }}
 {{- end }}
 
-<link rel="stylesheet" href="{{ "css/jquery-ui.min.css" | relURL }}">
-<link rel="stylesheet" href="{{ "css/callouts.css" | relURL }}">
-<link rel="stylesheet" href="{{ "css/custom-jekyll/tags.css" | relURL }}">
+<link rel="stylesheet" href="{{ "css/feature-states.css" | relURL }}">
+
 {{- if .Site.Params.announcement }}
 <link rel="stylesheet" href="{{ "css/announcement.css" | relURL }}">
 {{- end }}
@@ -30,6 +27,10 @@
   <link rel="stylesheet" href="{{ "css/training.css" | relURL }}">
 {{- end }}
 
+{{- if .Params.new_case_study_styles }}
+  <link rel="stylesheet" href="{{ "css/new-case-studies.css" | relURL }}">
+{{- end}}
+
 {{- with .Params.css }}
   {{- $extraCss := split . "," }}
   {{- range $extraCss }}
diff --git a/layouts/partials/docs/content-page.html b/layouts/partials/docs/content-page.html
index 38a1f205cb..02430aa9d3 100644
--- a/layouts/partials/docs/content-page.html
+++ b/layouts/partials/docs/content-page.html
@@ -1,12 +1,3 @@
-{{ if not (.Site.Param "deprecated") }}
-{{- $filepath := .page.File.Path }}
-{{- $editLink := printf "https://github.com/kubernetes/website/edit/master/content/%s/%s" .page.Language.Lang $filepath }}
-<p>
-  <a href="{{ $editLink }}" id="editPageButton" target="_blank" data-proofer-ignore>
-    Edit This Page
-  </a>
-</p>
-{{- end -}}
 {{ if not .page.Params.notitle }}
   <h1>{{ .page.Title }}</h1>
   {{ $desc := .page.Description }}
diff --git a/layouts/partials/docs/top-menu.html b/layouts/partials/docs/top-menu.html
deleted file mode 100644
index c1654dbcd1..0000000000
--- a/layouts/partials/docs/top-menu.html
+++ /dev/null
@@ -1,21 +0,0 @@
-{{ $p := . }}
-{{ $home := site.Home }}
-{{ $docs := site.GetPage "section" "docs" }}
-{{ $menuSections := (where $docs.Sections ".Params.main_menu" true) }}
-{{ range $menuSections }}
-{{ if $p.IsDescendant . }}
-<h1>{{ if not (strings.Contains .Path "home")}}{{ .Params.bigheader | default .Title }}{{ end }}</h1>
-<h5>{{ .Params.abstract }}</h5>
-{{ end }}
-{{ end }}
-<div id="vendorStrip" class="light-text">
-	<ul>
-		{{ range $menuSections }}
-		{{ $yah := $p.IsDescendant . }}
-		<li><a href="{{ .RelPermalink }}"{{ if $yah }} class="YAH"{{ end }} data-proofer-ignore>{{ .LinkTitle | upper }}</a></li>
-		{{ end }}
-	</ul>
-	<form id="searchBox" action="/docs/search/" role="search">
-		<input type="text" id="search" name="q" placeholder="{{ T "ui_search_placeholder" }}" aria-label="Search">
-	</form>
-</div>
\ No newline at end of file
diff --git a/layouts/partials/footer-scripts.html b/layouts/partials/footer-scripts.html
deleted file mode 100644
index 5a9f825169..0000000000
--- a/layouts/partials/footer-scripts.html
+++ /dev/null
@@ -1,35 +0,0 @@
-<button class="flyout-button" onclick="kub.toggleToc()" aria-label="Toggle table of contents visibility"></button>
-
-<script>
-// hide docs nav area if no nav is present, or if nav only contains a link to the current page
-(function () {
-    window.addEventListener('DOMContentLoaded', init)
-
-        // play nice with our neighbors
-        function init() {
-            window.removeEventListener('DOMContentLoaded', init)
-                hideNav()
-        }
-
-    function hideNav(toc){
-        if (!toc) toc = document.querySelector('#docsToc')
-        if (!toc) return
-            var container = toc.querySelector('.container')
-
-                // container is built dynamically, so it may not be present on the first runloop
-                if (container) {
-                    if (container.childElementCount === 0 || toc.querySelectorAll('a.item').length === 1) {
-                        toc.style.display = 'none'
-                            document.getElementById('docsContent').style.width = '100%'
-                    }
-                } else {
-                    requestAnimationFrame(function () {
-                        hideNav(toc)
-                    })
-                }
-    }
-})();
-</script>
-
-<!-- Commenting out AnswerDash for now; we need to work on our list of questions/answers/design first
-    <!-- Start of AnswerDash script <script>var AnswerDash;!function(e,t,n,s,a){if(!t.getElementById(s)){var i,r=t.createElement(n),c=t.getElementsByTagName(n)[0];e[a]||(i=e[a]=function(){i.__oninit.push(arguments)},i.__oninit=[]),r.type="text/javascript",r.async=!0,r.src="https://p1.answerdash.com/answerdash.min.js?siteid=756",r.setAttribute("id",s),c.parentNode.insertBefore(r,c)}}(window,document,"script","answerdash-script","AnswerDash");</script> <!-- End of AnswerDash script -->
diff --git a/layouts/partials/git-info.html b/layouts/partials/git-info.html
deleted file mode 100644
index 3b7b5ed396..0000000000
--- a/layouts/partials/git-info.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<div id="pre-footer">
-  <!-- This is at the bottom of every topic underneath the TOC and content -->
-  <hr/>
-
-  <div class="issue-button-container">
-    {{ if and (ne .Kind "404") (not (strings.Contains .Path "search")) }}
-      {{ if not .Params.no_issue }}
-        <script type="text/javascript">
-          PDRTJS_settings_8345992 = {
-            "id": "8345992",
-            "unique_id": "{{ .RelPermalink }}",
-            "title": "{{ .Title }}",
-            "permalink": "{{ .Permalink }}"
-          };
-          (function (d, c, j) {
-            if (!document.getElementById(j)) {
-              var pd = d.createElement(c),
-                s;
-              pd.id = j;
-              pd.src = ("https:" == document.location.protocol)
-                ? "https://polldaddy.com/js/rating/rating.js"
-                : "http://i0.poll.fm/js/rating/rating.js";
-              s = document.getElementsByTagName(c)[0];
-              s.parentNode.insertBefore(pd, s);
-            }
-          }(document, "script", "pd-rating-js"));
-        </script>
-        <a class="btn btn-primary mb-4 issue" href="" onclick="window.open('https://github.com/kubernetes/website/issues/new?template=bug-report.md&title=Issue%20with%20' +
-              'k8s.io'+window.location.pathname)">{{ T "main_github_create_an_issue" }}</a>
-      {{ end }}
-    {{ end }}
-    {{ if not .Params.noedit }}
-      {{ if .File }}
-        <a class="btn btn-primary mb-4 issue" href="https://github.com/kubernetes/website/edit/master/content/{{ site.Language.Lang }}/{{ .File.Path }}">{{ T "main_edit_this_page" }}</a>
-      {{ end }}
-    {{ end }}
-  </div>
-  {{ if and (not .Params.showcommit) $.GitInfo }}
-
-    <div class="lastedit issue-button-container" id="lastedit">
-      {{ T "main_page_last_modified_on" }}
-      {{ .GitInfo.AuthorDate.Format "January 02, 2006 at 3:04 PM PST" }}
-      {{ T "main_by" }}
-      <a href="https://github.com/kubernetes/website/commit/{{ .GitInfo.Hash }}/">{{ .GitInfo.Subject }}</a>
-      (<a href="https://github.com/kubernetes/website/commits/master/content/en/{{ .File.Path }}">{{ T "main_page_history" }}</a>)
-    </div>
-  {{ end }}
-</div>
diff --git a/layouts/partials/head.html b/layouts/partials/head.html
index 47f6e92daf..0fc1445b65 100644
--- a/layouts/partials/head.html
+++ b/layouts/partials/head.html
@@ -58,7 +58,7 @@
 {{- if not .Site.Params.deprecated }}
     "potentialAction": {
       "@type": "SearchAction",
-      "target": {{ printf "%s%s" ("/docs/search/" | absURL) "?q={search_term_string}" }},
+      "target": {{ printf "%s%s" ("search/" | absURL) "?q={search_term_string}" }},
       "query-input": "required name=search_term_string"
     }
 {{ end }}
@@ -85,8 +85,6 @@
 <meta property="og:image" content="{{ "/images/kubernetes-horizontal-color.png" | relURL }}">
 {{ end }}
 <meta property="og:type" content="{{ $ogType }}">
-<script src="{{ "js/jquery-ui-1.12.1.min.js" | relURL }}"></script>
-<script src="{{ "js/sweetalert-2.1.2.min.js" | relURL }}"></script>
 
 {{ if .HasShortcode "mermaid" }}
 <!-- Copied from https://unpkg.com/mermaid@8.5.0/dist/mermaid.min.js -->
diff --git a/layouts/partials/header.html b/layouts/partials/header.html
deleted file mode 100644
index e9ac8b7f66..0000000000
--- a/layouts/partials/header.html
+++ /dev/null
@@ -1,73 +0,0 @@
-<div id="cellophane" onclick="kub.toggleMenu()"></div>
-
-<header>
-    <a href="{{ site.Home.RelPermalink }}" class="logo" title="{{ site.Home.Title }} - {{ site.Params.title }}" aria-label="Kubernetes website" data-proofer-ignore></a>
-
-    <div class="nav-buttons" data-auto-burger="primary">
-        <ul class="global-nav">
-            {{ $sections := slice "docs" "blog" "training" "partners" "community" "case-studies" }}
-            {{ range $sections }}
-            {{ with site.GetPage "section" . }}<li><a href="{{ .RelPermalink }}"{{ if eq .Section $.Section }} class="active"{{ end}} data-proofer-ignore>{{ .Title }}</a></li>{{ end }}
-            {{ end }}
-            {{/* Link directly to documentation etc., if possible. */}}
-            {{ $langPage := cond (gt (len .Translations) 0) . site.Home }}
-             <li>
-                <a href="#" data-proofer-ignore>
-                    {{ $langPage.Language.LanguageName }} <span class="ui-icon ui-icon-carat-1-s"></span>
-                </a>
-                <ul>
-                {{ range $langPage.Translations }}
-                    <li><a href="{{ .RelPermalink }}" data-proofer-ignore>{{ .Language.LanguageName }}</a></li>
-                {{ end }}
-                </ul>
-            </li>
-
-            <li>
-                <a href="#" data-proofer-ignore>
-                    {{ site.Params.version }} <span class="ui-icon ui-icon-carat-1-s"></span>
-                </a>
-                <ul>
-                {{ range site.Params.versions }}
-                    <li><a href="{{ .url }}{{ $.RelPermalink }}" data-proofer-ignore>{{ .version }}</a></li>
-                {{ end }}
-                </ul>
-            </li>
-        </ul>
-        {{ with site.GetPage "section" "docs/tutorials/kubernetes-basics" }}
-        <a href="{{ .RelPermalink }}" class="button" id="tryKubernetes" data-auto-burger-exclude data-proofer-ignore>{{ .LinkTitle }}</a>
-        {{ end }}
-
-        <button id="hamburger" onclick="kub.toggleMenu()" data-auto-burger-exclude><div></div></button>
-    </div>
-
-    <nav id="mainNav">
-        <div class="main-section" data-auto-burger="primary">
-         {{ range site.Menus.main }}
-           <div class="nav-box">
-            <h3><a href="{{ .URL }}" data-proofer-ignore>{{ .Title }}</a></h3>
-           {{ .Post }}
-            </div>
-         {{ end }}
-        </div>
-        <div class="main-section" data-auto-burger="primary">
-            <div class="left">
-                <h5 class="github-invite">{{ T "main_github_invite" }}</h5>
-                <a href="https://github.com/kubernetes/kubernetes" class="button" data-auto-burger-exclude>{{ T "main_github_view_on" }}</a>
-            </div>
-
-            <div class="right">
-                <h5 class="github-invite">{{ T "main_community_explore" }}</h5>
-                <div class="social">
-                    <a href="https://twitter.com/kubernetesio" class="twitter"><span>{{ T "community_twitter_name" }}</span></a>
-                    <a href="https://github.com/kubernetes/kubernetes" class="github"><span>{{ T "community_github_name" }}</span></a>
-                    <a href="http://slack.k8s.io/" class="slack"><span>{{ T "community_slack_name" }}</span></a>
-                    <a href="https://stackoverflow.com/questions/tagged/kubernetes" class="stack-overflow"><span>{{ T "community_stack_overflow_name" }}</span></a>
-                    <a href="https://www.youtube.com/kubernetescommunity" class="youtube"><span>{{ T "community_youtube_name" }}</span></a>
-                    <a href="https://discuss.kubernetes.io" class="mailing-list"><span>{{ T "community_forum_name" }}</span></a>
-                    <a href="https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com" class="calendar"><span>{{ T "community_events_calendar" }}</span></a>
-                </div>
-            </div>
-            <div class="clear" style="clear: both"></div>
-        </div>
-    </nav>
-</header>
\ No newline at end of file
diff --git a/layouts/partials/hooks/body-end.html b/layouts/partials/hooks/body-end.html
new file mode 100644
index 0000000000..36e65f7791
--- /dev/null
+++ b/layouts/partials/hooks/body-end.html
@@ -0,0 +1,44 @@
+{{ with .Site.Params.algolia_docsearch }}
+<!-- scripts for algolia docsearch -->
+{{ end }}
+{{/* copy-and-paste helper for codenew shortcode */}}
+{{- if .HasShortcode "codenew" -}}
+<script async src="{{ "js/sweetalert-2.1.2.min.js" | relURL }}"></script>
+<script type="text/javascript">
+function copyCode(elem){
+  if (document.getElementById(elem)) {
+    // create hidden text element, if it doesn't already exist
+    var targetId = "_hiddenCopyText_";
+    // must use a temporary form element for the selection and copy
+    target = document.getElementById(targetId);
+    if (!target) {
+      var target = document.createElement("textarea");
+      target.style.position = "absolute";
+      target.style.left = "-9999px";
+      target.style.top = "0";
+      target.id = targetId;
+      document.body.appendChild(target);
+    }
+    target.value = document.getElementById(elem).innerText;
+    // select the content
+    target.select();
+
+    // copy the selection
+    var succeed;
+    try {
+        succeed = document.execCommand("copy");
+    } catch(e) {
+        swal("Oh, no…","Sorry, your browser doesn't support copying this example to your clipboard.");
+        succeed = false;
+    }
+    if (succeed) {
+      swal("Copied to clipboard: ",elem);
+      return succeed;
+    } else {
+      swal("Oops!", elem + " not found when trying to copy code");
+      return false;
+    }
+  }
+}
+</script>
+{{- end -}}
diff --git a/layouts/partials/toc.html b/layouts/partials/toc.html
new file mode 100644
index 0000000000..a57cad567b
--- /dev/null
+++ b/layouts/partials/toc.html
@@ -0,0 +1,8 @@
+{{ partial "page-meta-links.html" . }}
+{{ if not .Params.notoc }}
+{{ with .TableOfContents }}
+{{ if ge (len .) 100 }}
+{{ . }}
+{{ end }}
+{{ end }}
+{{ end }}
\ No newline at end of file
diff --git a/layouts/shortcodes/case-studies/lead.html b/layouts/shortcodes/case-studies/lead.html
new file mode 100644
index 0000000000..362224c151
--- /dev/null
+++ b/layouts/shortcodes/case-studies/lead.html
@@ -0,0 +1 @@
+<div class="lead">{{ .Inner }}</div>
diff --git a/layouts/shortcodes/case-studies/quote.html b/layouts/shortcodes/case-studies/quote.html
new file mode 100644
index 0000000000..f59cdd9260
--- /dev/null
+++ b/layouts/shortcodes/case-studies/quote.html
@@ -0,0 +1,12 @@
+{{ if .Get "image" }}
+<div class="quote banner {{ if $.Page.Params.use_gradient_overlay }}overlay{{ end }}" style="background-image: url({{ .Get "image" }})">
+{{ else }}
+<div class="quote banner">
+{{ end }}
+  <div class="quote-text">
+    {{ .Inner | markdownify }}
+    {{ if .Get "author" }}
+      <span class="quote-author">&mdash; {{ .Get "author" }}</span>
+    {{ end }}
+  </div>
+</div>
diff --git a/layouts/shortcodes/caution.html b/layouts/shortcodes/caution.html
index 2d14447142..82563d8c2c 100644
--- a/layouts/shortcodes/caution.html
+++ b/layouts/shortcodes/caution.html
@@ -1,3 +1,3 @@
-<blockquote class="caution">
+<blockquote class="caution callout">
   <div><strong>{{ T "caution" }}</strong> {{ trim .Inner " \n" | markdownify }}</div>
 </blockquote>
diff --git a/layouts/shortcodes/cncf-landscape.html b/layouts/shortcodes/cncf-landscape.html
new file mode 100644
index 0000000000..a97d4f9f8a
--- /dev/null
+++ b/layouts/shortcodes/cncf-landscape.html
@@ -0,0 +1,67 @@
+{{ $helpers := .Get "helpers" }}
+{{ if not (or (eq $helpers true) (eq $helpers false)) }}
+  {{ errorf "must set helpers to a boolean" }}
+{{ else }}
+<!-- CNCF Landscape helpers -->
+
+{{ if $helpers }}
+<script>
+function updateLandscapeSource(button,shouldUpdateFragment) {
+  console.log({button: button,shouldUpdateFragment: shouldUpdateFragment});
+  try {
+    if(shouldUpdateFragment) {
+      window.location.hash = "#"+button.id;
+      // hash change handler will call us again with shouldUpdateFragment set false
+    } else {
+      var landscapeElements = document.querySelectorAll("#landscape");
+      let categories=button.dataset.landscapeTypes;
+      let link = "https://landscape.cncf.io/category="+encodeURIComponent(categories)+"&format=card-mode&grouping=category&embed=yes";
+      landscapeElements[0].src = link;
+    }
+  }
+  catch(err) {
+    console.log({message: "error handling Landscape switch", error: err})
+  }
+}
+
+// Automatically load the correct iframe based on the URL fragment
+document.addEventListener("DOMContentLoaded", function () {
+  let hashChangeHandler = () => {
+    if (window.location.hash) {
+      let selectedTriggerElements = document.querySelectorAll(".landscape-trigger"+window.location.hash);
+      if (selectedTriggerElements.length == 1) {
+        landscapeSource = selectedTriggerElements[0];
+        console.log("Updating Landscape source based on fragment:", window
+          .location
+          .hash
+          .substring(1));
+        updateLandscapeSource(landscapeSource,false);
+      }
+    }
+  }
+  var landscapeTriggerElements = document.querySelectorAll(".landscape-trigger");
+  landscapeTriggerElements.forEach(element => {
+    element.onclick = function() {
+        updateLandscapeSource(element,true);
+    };
+  });
+  var landscapeDefaultElements = document.querySelectorAll(".landscape-trigger.landscape-default");
+  if (landscapeDefaultElements.length == 1) {
+    let defaultLandscapeSource = landscapeDefaultElements[0];
+    updateLandscapeSource(defaultLandscapeSource,false);
+  }
+  window.addEventListener("hashchange", hashChangeHandler, false);
+  /* handle initially-set fragment */
+  hashChangeHandler();
+});
+</script>
+{{- end -}}
+<div id="frameHolder">
+  {{ if ( .Get "category" ) }}
+  <iframe frameborder="0" id="landscape" scrolling="no" src="https://landscape.cncf.io/category={{ .Get "category" }}&format=card-mode&grouping=category&embed=yes" style="width: 1px; min-width: 100%"></iframe>
+  {{ else }}
+  <iframe frameborder="0" id="landscape" scrolling="no" src="https://landscape.cncf.io/format=card-mode;embed=yes" style="width: 1px; min-width: 100%" title="CNCF Landscape"></iframe>
+  {{ end }}
+  <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+</div>
+{{- end -}}
diff --git a/layouts/shortcodes/codenew.html b/layouts/shortcodes/codenew.html
index e8c6aa9656..e13e7b9ead 100644
--- a/layouts/shortcodes/codenew.html
+++ b/layouts/shortcodes/codenew.html
@@ -19,11 +19,14 @@
 {{ end }}
 {{ with $.Scratch.Get "content" }}
 <div class="highlight">
-    <div class="includecode" style="text-align: right" id="{{- $file | anchorize -}}">
-        {{- with $ghlink -}}<a href="{{ . }}" download="{{ $file }}">{{- end -}}
-            <code>{{ $file }}</code>
-        {{ if $ghlink }}</a>{{ end }}<img src="{{ "images/copycode.svg" | relURL }}" style="max-height:24px; cursor: pointer" onclick="copyCode('{{ $file | anchorize }}')" title="Copy {{ $file }} to clipboard">
+    <div class="copy-code-icon" style="text-align:right">
+    {{ with $ghlink }}<a href="{{ . }}" download="{{ $file }}">{{ end }}<code>{{ $file }}</code>
+    {{ if $ghlink }}</a>{{ end }}
+    <img src="{{ "images/copycode.svg" | relURL }}" style="max-height:24px; cursor: pointer" onclick="copyCode('{{ $file | anchorize }}')" title="Copy {{ $file }} to clipboard">
+    </img>
+    </div>
+    <div class="includecode" id="{{ $file | anchorize }}">
+    {{ highlight . $codelang "" }}
     </div>
-{{ highlight . $codelang "" }}
 </div>
-{{- end -}}
+{{ end }}
diff --git a/layouts/shortcodes/deprecationfilewarning.html b/layouts/shortcodes/deprecationfilewarning.html
index 48e2f43c98..71583c4c96 100644
--- a/layouts/shortcodes/deprecationfilewarning.html
+++ b/layouts/shortcodes/deprecationfilewarning.html
@@ -1,3 +1,3 @@
-<blockquote class="deprecation_file_warning">
+<blockquote class="deprecation_file_warning callout">
   <div><h4>{{ T "deprecation_file_warning" }}</h4> {{ .Inner | markdownify }}</div>
 </blockquote>
diff --git a/layouts/shortcodes/glossary_tooltip.html b/layouts/shortcodes/glossary_tooltip.html
index a0bed81597..400bcf7c84 100644
--- a/layouts/shortcodes/glossary_tooltip.html
+++ b/layouts/shortcodes/glossary_tooltip.html
@@ -14,13 +14,11 @@
 {{- $glossary_home := "docs/reference/glossary/?all=true" | relLangURL -}}
 {{- $external_link := $term_info.Params.full_link | default (printf "%s#term-%s" $glossary_home $id | safeURL  ) -}}
 {{- $tooltip :=  $term_info.Params.short_description | markdownify -}}
-{{- $tooltip := $tooltip | replaceRE "(?s)<a class='glossary-tooltip'.*?>(.*?)<span class='tooltip-text'>.*</a>" "$1" | plainify -}}
+
+{{- $tooltip := $tooltip | replaceRE "(?s)<a class='glossary-tooltip'.*?>(.*?).*</a>" "$1" | plainify -}}
 {{- $tooltip := trim $tooltip " \n" -}}
-<a class='glossary-tooltip' href='{{ $external_link }}' target='_blank'>
-	{{- $text -}}
-	<span class='tooltip-text'>
-  {{- $tooltip | safeHTML -}}
-	</span>
+<a class='glossary-tooltip' title='{{- $tooltip | safeHTML -}}' data-toggle='tooltip' data-placement='top' href='{{ $external_link }}' target='_blank' aria-label='{{ $text }}'>
+{{- $text -}}
 </a>
 {{- end -}}
 {{- end -}}
diff --git a/layouts/shortcodes/note.html b/layouts/shortcodes/note.html
index 1161c2366c..eba93f8b7e 100644
--- a/layouts/shortcodes/note.html
+++ b/layouts/shortcodes/note.html
@@ -1,3 +1,3 @@
-<blockquote class="note">
+<blockquote class="note callout">
   <div><strong>{{ T "note" }}</strong> {{ trim .Inner " \n" | markdownify }}</div>
 </blockquote>
\ No newline at end of file
diff --git a/layouts/shortcodes/tabs.html b/layouts/shortcodes/tabs.html
index 7abe6c14e8..aeb9582b28 100644
--- a/layouts/shortcodes/tabs.html
+++ b/layouts/shortcodes/tabs.html
@@ -2,16 +2,25 @@
 {{- $tab_set_id := .Get "name" | default (printf "tabset-%s-%d" (.Page.RelPermalink) (.Page.Scratch.Get "tabset-counter") ) | anchorize -}}
 {{- $tabs := .Scratch.Get "tabs" -}}
 {{- if .Inner -}}{{- /* We don't use the inner content, but Hugo will complain if we don't reference it. */ -}}{{- end -}}
-<div id="{{ $tab_set_id }}">
-<ul>
+<ul class="nav nav-tabs" id="{{ $tab_set_id }}" role="tablist">
 	{{- range $i, $e := $tabs -}}
 	  {{- $id := printf "%s-%d" $tab_set_id $i -}}
-<li><a href="#{{ $id }}">{{- trim .name " " -}}</a></li>
+	  {{- if (eq $i 0) -}}
+		<li class="nav-item"><a data-toggle="tab" class="nav-link active" href="#{{ $id }}" role="tab" aria-controls="{{ $id }}" aria-selected="true">{{- trim .name " " -}}</a></li>
+	  {{ else }}
+		<li class="nav-item"><a data-toggle="tab" class="nav-link" href="#{{ $id }}" role="tab" aria-controls="{{ $id }}">{{- trim .name " " -}}</a></li>
+	  {{- end -}}
 {{- end -}}
 </ul>
+<div class="tab-content" id="{{ $tab_set_id }}">
 {{- range $i, $e := $tabs -}}
 {{- $id := printf "%s-%d" $tab_set_id $i -}}
-<div id="{{ $id }}">
+{{- if (eq $i 0) -}}
+  <div id="{{ $id }}" class="tab-pane show active" role="tabpanel" aria-labelledby="{{ $id }}">
+{{ else }}
+  <div id="{{ $id }}" class="tab-pane" role="tabpanel" aria-labelledby="{{ $id }}">
+{{ end }}
+<p>
 	{{- with .content -}}
 		{{- . -}}
 	{{- else -}}
@@ -39,5 +48,3 @@
 </div>
 {{- end -}}
 </div>
-{{- $elem :=  $tab_set_id | safeJS -}}
-<script>$(function(){$("#{{ $elem }}").tabs();});</script>
\ No newline at end of file
diff --git a/layouts/shortcodes/thirdparty-content.html b/layouts/shortcodes/thirdparty-content.html
new file mode 100644
index 0000000000..5a98081e49
--- /dev/null
+++ b/layouts/shortcodes/thirdparty-content.html
@@ -0,0 +1,4 @@
+<blockquote class="callout caution" role="alert">
+  <strong>{{ T "caution" | safeHTML }}</strong>
+  {{ T "thirdparty_message" | safeHTML }}
+</blockquote>
diff --git a/layouts/shortcodes/versions-other.html b/layouts/shortcodes/versions-other.html
index 4f5e3854f2..2b2b2655dd 100644
--- a/layouts/shortcodes/versions-other.html
+++ b/layouts/shortcodes/versions-other.html
@@ -1,3 +1,4 @@
+{{/* this shortcode is DEPRECATED */}}
 {{ $versions := .Page.Param "versions" }}
 {{ $thisVersion :=  .Page.Param "version" }}
 <ul>
diff --git a/layouts/shortcodes/warning.html b/layouts/shortcodes/warning.html
index ddd5ff197f..a6a5f67abd 100644
--- a/layouts/shortcodes/warning.html
+++ b/layouts/shortcodes/warning.html
@@ -1,3 +1,3 @@
-<blockquote class="warning">
+<blockquote class="warning callout">
   <div><strong>{{ T "warning" }}</strong> {{ trim .Inner " \n" | markdownify }}</div>
 </blockquote>
diff --git a/scripts/lsync.sh b/scripts/lsync.sh
new file mode 100755
index 0000000000..934e3b91ef
--- /dev/null
+++ b/scripts/lsync.sh
@@ -0,0 +1,60 @@
+#!/bin/bash
+#
+# This script checks if the English version of a page has changed since a localized
+# page has been committed.
+
+if [ "$#" -ne 1 ] ; then
+  echo -e "\nThis script checks if the English version of a page has changed since a " >&2
+  echo -e "localized page has been committed.\n" >&2
+  echo -e "Usage:\n\t$0 <PATH>\n" >&2
+  echo -e "Example:\n\t$0 content/zh/docs/concepts/_index.md\n" >&2
+  exit 1
+fi
+
+# Check if path exists, and whether it is a directory or a file
+if [ ! -e "$1" ] ; then
+  echo "Path not found: '$1'" >&2
+  exit 2
+fi
+
+if [ -d "$1" ] ; then
+  SYNCED=1
+  for f in `find $1 -name "*.md"` ; do
+    EN_VERSION=`echo $f | sed "s/content\/..\//content\/en\//g"`
+    if [ ! -e $EN_VERSION ]; then
+      echo -e "**removed**\t$EN_VERSION"
+      SYNCED=0
+      continue
+    fi
+
+    LASTCOMMIT=`git log -n 1 --pretty=format:%h -- $f`
+    git diff --exit-code --numstat $LASTCOMMIT...HEAD $EN_VERSION
+    if [ $? -ne 0 ] ; then
+      SYNCED=0
+    fi
+  done
+  if [ $SYNCED -eq 1 ]; then
+    echo "$1 is still in sync"
+    exit 0
+  fi
+  exit 1
+fi
+
+LOCALIZED="$1"
+
+# Try get the English version
+EN_VERSION=`echo $LOCALIZED | sed "s/content\/..\//content\/en\//g"`
+if [ ! -e $EN_VERSION ]; then
+  echo "$EN_VERSION has been removed."
+  exit 3
+fi
+
+# Last commit for the localized path
+LASTCOMMIT=`git log -n 1 --pretty=format:%h -- $LOCALIZED`
+
+git diff --exit-code $LASTCOMMIT...HEAD $EN_VERSION
+
+if [ "$?" -eq 0 ]; then
+  echo "$LOCALIZED is still in sync"
+  exit 0
+fi
diff --git a/static/_redirects b/static/_redirects
index dc58a78c72..97f6a8b80f 100644
--- a/static/_redirects
+++ b/static/_redirects
@@ -20,6 +20,7 @@
 /vi/docs/     /vi/docs/home/ 301!
 /zh/docs/     /zh/docs/home/ 301!
 /blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/     /blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/     301!
+/blog/2020/08/25/kubernetes-release-1.19-accentuate-the-paw-sitive/     /blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive/     301!
 /docs/admin/     /docs/concepts/cluster-administration/ 301
 /docs/admin/add-ons/     /docs/concepts/cluster-administration/addons/ 301
 /docs/admin/addons/     /docs/concepts/cluster-administration/addons/ 301
@@ -27,7 +28,7 @@
 /docs/admin/audit/     /docs/tasks/debug-application-cluster/audit/ 301
 /docs/admin/authorization/rbac.md     /docs/admin/authorization/rbac/ 301
 /docs/admin/cluster-components/     /docs/concepts/overview/components/ 301
-/docs/admin/cluster-management/     /docs/tasks/administer-cluster/cluster-management/ 301
+/docs/admin/cluster-management/     /docs/tasks/administer-cluster/ 302
 /docs/admin/cluster-troubleshooting/     /docs/tasks/debug-application-cluster/debug-cluster/ 301
 /docs/admin/daemons/     /docs/concepts/workloads/controllers/daemonset/ 301
 /docs/admin/disruptions/     /docs/concepts/workloads/pods/disruptions/ 301
@@ -67,6 +68,8 @@
 /docs/api/     /docs/concepts/overview/kubernetes-api/ 301
 
 /docs/api-reference/labels-annotations-taints/     /docs/reference/labels-annotations-taints/ 301
+/docs/reference/using-api/api-overview/     /docs/reference/using-api/ 301
+/docs/reference/access-authn-authz/controlling-access/   /docs/concepts/security/controlling-access/ 301
 
 /docs/concepts/abstractions/controllers/garbage-collection/     /docs/concepts/workloads/controllers/garbage-collection/ 301
 /docs/concepts/abstractions/controllers/statefulsets/     /docs/concepts/workloads/controllers/statefulset/ 301
@@ -80,7 +83,7 @@
 /docs/concepts/cluster-administration/access-cluster/     /docs/tasks/access-application-cluster/access-cluster/ 301
 /docs/concepts/cluster-administration/audit/     /docs/tasks/debug-application-cluster/audit/ 301
 /docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig   /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301
-/docs/concepts/cluster-administration/cluster-management/     /docs/tasks/administer-cluster/cluster-management/ 301
+/docs/concepts/cluster-administration/cluster-management/     /docs/tasks/administer-cluster/ 302
 /docs/concepts/cluster-administration/configure-etcd/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
 /docs/concepts/cluster-administration/device-plugins/     /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ 301
 /docs/concepts/cluster-administration/etcd-upgrade/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
@@ -98,6 +101,7 @@
 /docs/concepts/configuration/container-command-arg/     /docs/tasks/inject-data-application/define-command-argument-container/ 301
 /docs/concepts/configuration/container-command-args/     /docs/tasks/inject-data-application/define-command-argument-container/     301
 /docs/concepts/configuration/manage-compute-resources-container/ /docs/concepts/configuration/manage-resources-containers/ 301
+/docs/concepts/configuration/resource-bin-packing/      /docs/concepts/scheduling-eviction/resource-bin-packing/ 301
 /docs/concepts/configuration/scheduler-perf-tuning/      /docs/concepts/scheduling-eviction/scheduler-perf-tuning/    301
 /docs/concepts/configuration/scheduling-framework/     /docs/concepts/scheduling-eviction/scheduling-framework/    301
 /docs/concepts/configuration/taint-and-toleration/     /docs/concepts/scheduling-eviction/taint-and-toleration/ 301
@@ -192,11 +196,10 @@
 /docs/reference/kubectl/kubectl/kubectl_*.md    /docs/reference/generated/kubectl/kubectl-commands#:splat 301
 /docs/reference/scheduling/profiles/    /docs/reference/scheduling/config/#profiles 301
 
-/docs/reference/generated/kubernetes-api/v1.14/    https://v1-14.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/  301
 /docs/reference/generated/kubernetes-api/v1.15/    https://v1-15.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/  301
 /docs/reference/generated/kubernetes-api/v1.16/    https://v1-16.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/  301
 /docs/reference/generated/kubernetes-api/v1.17/    https://v1-17.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/  301
-
+/docs/reference/generated/kubernetes-api/v1.18/    https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/  301
 
 /docs/reporting-security-issues/     /security/ 301
 
@@ -284,7 +287,7 @@
 /docs/templatedemos/*     /docs/home/contribute/page-templates/ 301
 /docs/tools/     /docs/reference/tools/ 301
 /docs/tools/kompose/user-guide/     /docs/tasks/configure-pod-container/translate-compose-kubernetes/ 301
-/docs/tools/kompose/     /docs/tools/kompose/user-guide/ 301
+/docs/tools/kompose/     /docs/tasks/configure-pod-container/translate-compose-kubernetes/ 301
 /docs/troubleshooting/     /docs/tasks/debug-application-cluster/troubleshooting/ 301
 
 /docs/tutorials/clusters/multiple-schedulers/     /docs/tasks/administer-cluster/configure-multiple-schedulers/ 301
@@ -363,13 +366,9 @@
 /docs/user-guide/kubeconfig-file/     /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301
 /docs/user-guide/kubectl-overview/     /docs/reference/kubectl/overview/
 /docs/user-guide/kubectl/     /docs/reference/generated/kubectl/kubectl-options/
-#/docs/user-guide/kubectl/v1.8/*     https://v1-8.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301
-#/docs/user-guide/kubectl/v1.9/*     https://v1-9.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301
-#/docs/user-guide/kubectl/v1.10/*     /docs/reference/generated/kubectl/kubectl-commands/:splat 301
 /docs/user-guide/kubectl-conventions/     /docs/reference/kubectl/conventions/
 /docs/user-guide/kubectl-cheatsheet/     /docs/reference/kubectl/cheatsheet/
 /docs/user-guide/kubectl/kubectl_*/     /docs/reference/generated/kubectl/kubectl-commands#:splat 301
-#/docs/user-guide/kubectl/v1.6/node_modules/*     https://v1-6.docs.kubernetes.io/docs/user-guide/kubectl/v1.6/ 301
 /docs/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301
 /docs/user-guide/liveness/     /docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 301
 /docs/user-guide/load-balancer/     /docs/tasks/access-application-cluster/create-external-load-balancer/ 301
@@ -451,7 +450,8 @@
 /editdocs/     /docs/contribute/     301
 /docs/home/editdocs/  /docs/contribute/ 301
 
-/docs/admin/accessing-the-api/     /docs/reference/access-authn-authz/controlling-access/ 301
+
+/docs/admin/accessing-the-api/     /docs/concepts/overview/kubernetes-api/ 301
 /docs/admin/admission-controllers/     /docs/reference/access-authn-authz/admission-controllers/ 301
 /docs/admin/authentication/     /docs/reference/access-authn-authz/authentication/ 301
 /docs/admin/bootstrap-tokens/     /docs/reference/access-authn-authz/bootstrap-tokens/ 301
@@ -468,7 +468,10 @@
 
 /docs/setup/version-skew-policy/     /docs/setup/release/version-skew-policy/   301
 
-/docs/setup/minikube/     /docs/setup/learning-environment/minikube/   301
+/docs/setup/minikube/     /docs/tasks/tools/ 302
+/docs/setup/learning-environment/     /docs/tasks/tools/  302!
+/docs/setup/learning-environment/kind/  /docs/tasks/tools/  302
+/docs/setup/learning-environment/minikube/  /docs/tasks/tools/ 302
 /docs/setup/cri/     /docs/setup/production-environment/container-runtimes/   301
 /docs/setup/independent/install-kubeadm/     /docs/setup/production-environment/tools/kubeadm/install-kubeadm/   301
 /ja/docs/setup/independent/install-kubeadm/     /ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/   301
@@ -484,11 +487,6 @@
 /docs/setup/independent/kubelet-integration/     /docs/setup/production-environment/tools/kubeadm/kubelet-integration/   301
 /docs/setup/custom-cloud/kops/     /docs/setup/production-environment/tools/kops/   301
 /docs/setup/custom-cloud/kubespray/     /docs/setup/production-environment/tools/kubespray/   301
-/docs/setup/turnkey/aws/     /docs/setup/production-environment/turnkey/aws/   301
-/docs/setup/turnkey/alibaba-cloud/     /docs/setup/production-environment/turnkey/alibaba-cloud/   301
-/docs/setup/turnkey/azure/     /docs/setup/production-environment/turnkey/azure/   301
-/docs/setup/turnkey/gce/     /docs/setup/production-environment/turnkey/gce/   301
-/docs/setup/turnkey/icp/     /docs/setup/production-environment/turnkey/icp/   301
 /docs/setup/on-premises-vm/cloudstack/     /docs/setup/production-environment/on-premises-vm/cloudstack/   301
 /docs/setup/on-premises-vm/dcos/     /docs/setup/production-environment/on-premises-vm/dcos/   301
 /docs/setup/on-premises-vm/ovirt/     /docs/setup/production-environment/on-premises-vm/ovirt/   301
@@ -500,3 +498,7 @@
 /docs/setup/cluster-large/     /docs/setup/best-practices/cluster-large/   301
 /docs/setup/node-conformance/     /docs/setup/best-practices/node-conformance/   301
 /docs/setup/certificates/     /docs/setup/best-practices/certificates/   301
+
+/docs/tasks/tools/install-minikube/     https://minikube.sigs.k8s.io/docs/start/     302
+
+/docs/concepts/configuration/pod-overhead/     /docs/concepts/scheduling-eviction/pod-overhead/   301
diff --git a/static/css/announcement.css b/static/css/announcement.css
index 9b15f9407a..816d7c1fc0 100644
--- a/static/css/announcement.css
+++ b/static/css/announcement.css
@@ -1,3 +1,10 @@
+@media print {
+  /* Do not print announcements */
+  #announcement, section#announcement, #fp-announcement, section#fp-announcement {
+    display: none;
+  }
+}
+
 .announcement.content {
   margin-bottom: 0px;
 }
diff --git a/static/css/base_fonts.css b/static/css/base_fonts.css
deleted file mode 100644
index c83893cb37..0000000000
--- a/static/css/base_fonts.css
+++ /dev/null
@@ -1,169 +0,0 @@
-/* roboto-mono-regular - latin */
-@font-face {
-    font-family: 'Roboto Mono';
-    font-style: normal;
-    font-weight: 400;
-    src: url('../fonts/roboto-mono-v5-latin-regular.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Mono'), local('RobotoMono-Regular'),
-         url('../fonts/roboto-mono-v5-latin-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-mono-v5-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-mono-v5-latin-regular.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-mono-v5-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-mono-v5-latin-regular.svg#RobotoMono') format('svg'); /* Legacy iOS */
-  }
-/* roboto-100 - latin */
-@font-face {
-    font-family: 'Roboto';
-    font-style: normal;
-    font-weight: 100;
-    src: url('../fonts/roboto-v18-latin-100.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Thin'), local('Roboto-Thin'),
-         url('../fonts/roboto-v18-latin-100.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-100.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-100.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-100.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-100.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-100italic - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: italic;
-    font-weight: 100;
-    src: url('../fonts/roboto-v18-latin-100italic.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Thin Italic'), local('Roboto-ThinItalic'),
-         url('../fonts/roboto-v18-latin-100italic.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-100italic.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-100italic.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-100italic.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-100italic.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-300 - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: normal;
-    font-weight: 300;
-    src: url('../fonts/roboto-v18-latin-300.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Light'), local('Roboto-Light'),
-         url('../fonts/roboto-v18-latin-300.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-300.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-300.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-300.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-300.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-300italic - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: italic;
-    font-weight: 300;
-    src: url('../fonts/roboto-v18-latin-300italic.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Light Italic'), local('Roboto-LightItalic'),
-         url('../fonts/roboto-v18-latin-300italic.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-300italic.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-300italic.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-300italic.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-300italic.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-regular - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: normal;
-    font-weight: 400;
-    src: url('../fonts/roboto-v18-latin-regular.eot'); /* IE9 Compat Modes */
-    src: local('Roboto'), local('Roboto-Regular'),
-         url('../fonts/roboto-v18-latin-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-regular.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-regular.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-italic - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: italic;
-    font-weight: 400;
-    src: url('../fonts/roboto-v18-latin-italic.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Italic'), local('Roboto-Italic'),
-         url('../fonts/roboto-v18-latin-italic.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-italic.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-italic.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-italic.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-italic.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-500 - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: normal;
-    font-weight: 500;
-    src: url('../fonts/roboto-v18-latin-500.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Medium'), local('Roboto-Medium'),
-         url('../fonts/roboto-v18-latin-500.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-500.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-500.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-500.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-500.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-500italic - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: italic;
-    font-weight: 500;
-    src: url('../fonts/roboto-v18-latin-500italic.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Medium Italic'), local('Roboto-MediumItalic'),
-         url('../fonts/roboto-v18-latin-500italic.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-500italic.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-500italic.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-500italic.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-500italic.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-700 - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: normal;
-    font-weight: 700;
-    src: url('../fonts/roboto-v18-latin-700.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Bold'), local('Roboto-Bold'),
-         url('../fonts/roboto-v18-latin-700.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-700.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-700.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-700.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-700.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-700italic - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: italic;
-    font-weight: 700;
-    src: url('../fonts/roboto-v18-latin-700italic.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Bold Italic'), local('Roboto-BoldItalic'),
-         url('../fonts/roboto-v18-latin-700italic.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-700italic.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-700italic.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-700italic.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-700italic.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-900 - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: normal;
-    font-weight: 900;
-    src: url('../fonts/roboto-v18-latin-900.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Black'), local('Roboto-Black'),
-         url('../fonts/roboto-v18-latin-900.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-900.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-900.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-900.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-900.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
-  /* roboto-900italic - latin */
-  @font-face {
-    font-family: 'Roboto';
-    font-style: italic;
-    font-weight: 900;
-    src: url('../fonts/roboto-v18-latin-900italic.eot'); /* IE9 Compat Modes */
-    src: local('Roboto Black Italic'), local('Roboto-BlackItalic'),
-         url('../fonts/roboto-v18-latin-900italic.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
-         url('../fonts/roboto-v18-latin-900italic.woff2') format('woff2'), /* Super Modern Browsers */
-         url('../fonts/roboto-v18-latin-900italic.woff') format('woff'), /* Modern Browsers */
-         url('../fonts/roboto-v18-latin-900italic.ttf') format('truetype'), /* Safari, Android, iOS */
-         url('../fonts/roboto-v18-latin-900italic.svg#Roboto') format('svg'); /* Legacy iOS */
-  }
\ No newline at end of file
diff --git a/static/css/blog.css b/static/css/blog.css
deleted file mode 100644
index 834795084b..0000000000
--- a/static/css/blog.css
+++ /dev/null
@@ -1,510 +0,0 @@
-/* Overall I tried to maintain as much of the look of the old site as */
-/* possible.  When I made changes they were generally to accommodate jekyll */
-/* or to conform with the styling on the rest of k8s.io */
-
-
-/* Content
------------------------------------------------ */
-body {
-  font: normal normal 16px 'Trebuchet MS', Trebuchet, Verdana, sans-serif;
-  color: #666666;
-  background: #ffffff none repeat scroll top left;
-  padding: 0 0 0 0;
-}
-html body .region-inner {
-  min-width: 0;
-  max-width: 100%;
-  width: auto;
-}
-
-div a:link {
-color: #326DE6;
-}
-
-div a.widget-link {
-color: #326DE6;
-}
-
-/* Header
------------------------------------------------ */
-
-.header-outer {
-  background: transparent none repeat-x scroll 0 -400px;
-  _background-image: none;
-}
-.Header h1 {
-  font: normal normal 40px 'Trebuchet MS',Trebuchet,Verdana,sans-serif;
-  color: #000000;
-  text-shadow: 0 0 0 rgba(0, 0, 0, .2);
-}
-
-.Header h1 a {
-  color: #000000;
-}
-.Header .description {
-  font-size: 18px;
-  color: #000000;
-}
-.header-inner .Header .titlewrapper {
-  padding: 22px 0;
-}
-.header-inner .Header .descriptionwrapper {
-  padding: 0 0;
-}
-
-#blog-hero {
-  background-image: url('../images/texture.png');
-  background-color: #303030;
-  padding-left: 50px;
-}
-
-
-header#topHeader {
-  position: absolute;
-  top: 0;
-  left: 0;
-  width: 100%;
-  height: 160px;
-  background-color: #333;
-  background-image: url(http://kub.unitedcreations.xyz/images/texture.png);
-  background-position: center center;
-}
-#headerWrapper {
-  position: relative;
-  width: 1408px;
-  margin: 0px auto;
-  overflow: hidden;
-}
-div.header-title {
-  position: relative;
-  float: left;
-  width: 980px;
-  margin: 0 auto;
-  padding: 40px 0 0 20px;
-  border: true;
-}
-div.header-title h6 {
-  margin: 0;
-  padding-left: 108px;
-  font-weight: normal;
-  font-size: 18px;
-  color: white;
-}
-div.header-try {
-  width: 384px;
-  float: right;
-  color: white;
-  padding-top: 70px;
-}
-div.header-try h6 {
-  font-size: 16px;
-  margin: 0 0 20px;
-  color: transparent;
-}
-div.header-try a {
-  display: inline-block;
-  font-size: 16px;
-  padding: 10px 40px;
-  background: none;
-  border: 0;
-  background-color:  #326DE6;
-  border-radius: 6px;
-  color: white;
-  outline: none;
-  cursor: pointer;
-}
-
-/* Tabs
------------------------------------------------ */
-.blog-title {
-  clear: left
-}
-
-.tabs-inner .section:first-child {
-  border-top: 0 solid #dddddd;
-}
-.tabs-inner .section:first-child ul {
-  margin-top: -1px;
-  border-top: 1px solid #dddddd;
-  border-left: 1px solid #dddddd;
-  border-right: 1px solid #dddddd;
-}
-
-
-/* Pagination Links */
-@media (max-width: 449px) {
-  div.pagination {
-  position: relative;
-  left: 30%;
-  }
-}
-
-@media (min-width: 450px) {
-  h4.pagination {
-  position: relative;
-  left: 30%;
-  }
-}
-
-/* Columns
------------------------------------------------ */
-.main-outer {
-  border-top: 0 solid transparent;
-}
-@media (min-width: 992px) {
-  .blog-content {
-    padding-left: 50px;
-  }
-}
-
-@media (max-width: 991px) {
-  .blog-content {
-    padding-left: 20px;
-  }
-}
-.fauxcolumn-left-outer .fauxcolumn-inner {
-  border-right: 1px solid transparent;
-}
-.fauxcolumn-right-outer .fauxcolumn-inner {
-  border-left: 1px solid transparent;
-}
-
-/* Headings
------------------------------------------------ */
-div.widget > h2,
-div.widget h2.title {
-  margin: 0 0 1em 0;
-  font: normal bold 11px 'Roboto', sans-serif;
-  color: #000000;
-}
-
-/* Posts
------------------------------------------------ */
-h2.date-header {
-  font: normal bold 11px 'Roboto', Tahoma, Helvetica, FreeSans, sans-serif;
-}
-.date-header span {
-  background-color: #bbbbbb;
-  color: #ffffff;
-  padding: 0.4em;
-  letter-spacing: 3px;
-  margin: inherit;
-}
-.main-inner {
-  padding-top: 35px;
-  padding-bottom: 65px;
-}
-.main-inner .column-center-inner {
-  padding: 0 0;
-}
-.main-inner .column-center-inner .section {
-  margin: 0 1em;
-}
-.post {
-  margin: 0 0 15px 0;
-}
-h3.post-title{
-  font: normal normal 22px 'Trebuchet MS',Trebuchet,Verdana,sans-serif;
-  margin: .75em 0 0;
-}
-.post-body {
-  font-size: 110%;
-  line-height: 1.4;
-  position: relative;
-}
-.post-body img, .post-body .tr-caption-container, .Profile img, .Image img,
-.BlogList .item-thumbnail img {
-  padding: 2px;
-  background: #ffffff;
-  border: 1px solid #eeeeee;
-  -moz-box-shadow: 1px 1px 5px rgba(0, 0, 0, .1);
-  -webkit-box-shadow: 1px 1px 5px rgba(0, 0, 0, .1);
-  box-shadow: 1px 1px 5px rgba(0, 0, 0, .1);
-  width: inherit;
-}
-.post-body img, .post-body .tr-caption-container {
-  padding: 5px;
-  width: inherit;
-}
-.post-body .tr-caption-container {
-  color: #666666;
-}
-.post-body .tr-caption-container img {
-  padding: 0;
-  background: transparent;
-  border: none;
-  -moz-box-shadow: 0 0 0 rgba(0, 0, 0, .1);
-  -webkit-box-shadow: 0 0 0 rgba(0, 0, 0, .1);
-  box-shadow: 0 0 0 rgba(0, 0, 0, .1);
-}
-.post-header {
-  margin: 0 0 1.5em;
-  line-height: 1.6;
-  font-size: 90%;
-}
-.post-footer {
-  margin: 20px -2px 0;
-  padding: 5px 10px;
-  color: #666666;
-  background-color: #eeeeee;
-  border-bottom: 1px solid #eeeeee;
-  line-height: 1.6;
-  font-size: 90%;
-}
-
-/* Mobile
------------------------------------------------ */
-.main-inner .column-right-outer {
-  width: 320px;
-  margin-right: -320px;
-}
-.sidebar .widget a.widget-link:link,
-.sidebar .widget a.widget-link:visited,
-.sidebar .widget a.widget-link:hover,
-.sidebar .widget a.widget-link:active {
-  color: #326DE6;
-  font-size: 22px;
-}
-.widget-link {
-  position: relative;
-  display: block;
-  box-sizing: border-box;
-  padding: 0 0 0 15px;
-  margin: 10px 0;
-  line-height: 50px;
-  white-space: nowrap;
-  font-family: Roboto, sans-serif;
-}
-.widget-link .fa {
-  position: absolute;
-  left: 0; top: 0;
-  width: 40px; height: 40px;
-  color: white;
-  background-color: #326DE6;
-  border-radius: 6px;
-  font-size: 30px;
-  text-align: center;
-  line-height: 40px;
-}
-h2.date-header {
-  font-family: Roboto-Bold;
-  font-weight: bold;
-  font-style: normal;
-  font-size: 16px;
-}
-h2.date-header span {
-  background: none;
-  color: #222;
-}
-h3.post-title {
-  font-size: 30px;
-  color: #326DE6;
-}
-
-div.post-footer {
-  display: none;
-}
-.post-body {
-  font-family: Roboto-Light;
-  font-size: 16px;
-  line-height: 1.5;
-}
-
-body {
-  width: 100%;
-}
-.content-outer, .content-fauxcolumn-outer, .region-inner {
-  width: 100%;
-  max-width: 1200px;
-  padding-left: 15px;
-}
-.main-inner .columns {
-  padding-left: 0px;
-  padding-right: 310px;
-}
-
-.main-inner .fauxcolumn-center-outer {
-  left: 0px;
-  right: 310px;
-  /* IE6 does not respect left and right together */
-  _width: expression(this.parentNode.offsetWidth -
-  parseInt("0px") -
-  parseInt("310px") + 'px');
-  }
-
-  .main-inner .fauxcolumn-left-outer {
-    width: 0px;
-  }
-  .main-inner .fauxcolumn-right-outer {
-    width: 310px;
-  }
-  .main-inner .column-left-outer {
-    width: 0px;
-    right: 100%;
-    margin-left: -0px;
-  }
-  .main-inner .column-right-outer {
-    width: 310px;
-    margin-right: -310px;
-  }
-  #layout {
-    min-width: 0;
-  }
-  #layout .content-outer {
-    min-width: 0;
-    width: 800px;
-  }
-  #layout .region-inner {
-    min-width: 0;
-    width: auto;
-  }
-  /* overwrite blog styles with specific rules to conform with site */
-  .blog-content ul , .blog-content li {
-    list-style:initial;
-    margin-left: 1em;
-  }
-
-  .blog-content .PageNavigation > ul.navigation, .blog-content .PageNavigation > ul.navigation > li {
-    margin-left: auto;
-  }
-
-  /* .blog-content .pagination {
-    width: inherit;
-  } */
-
-  .button {
-    border-radius: 6px;
-    padding: 0 20px;
-    line-height: 40px;
-    background-color: #3371e3;
-    text-decoration: none;
-  }
-
-div a.button {
-  font-size: 16px;
-}
-
-
- a:link.button {
-    color: #ffffff;
-  }
-
- a:visited.button{
-    color: #ffffff;
-  }
-
-/* Nested List Indentations for Release Notes & Community Meeting Notes -- in HTML */
-
-ul {
-  padding: 1em;
-}
-
-/* Sidebar Icon Styles */
-.widget-link svg {
-  font-size: 40px;
-  color:#326DE6;
-  vertical-align: middle;
-  width: 40px !important;
-}
-
-.widget-link div {
-  display: flex;
-}
-
-.widget-link .widget-link-text {
-  margin-left: 6px;
-}
-
-
-/* SideNavigation Styles */
-.heading-year-toggle-checkbox,
-.heading-month-toggle-checkbox{
-  display: none;
-}
-
-.collapsible-year-header,
-.collapsible-month-header {
-  -webkit-box-flex: 1;
-  -ms-flex: 1;
-  flex: 1;
-}
-
-.collapsible-year-heading-label,
-.collapsible-month-heading-label {
-  display: -webkit-box;
-  display: -ms-flexbox;
-  display: flex;
-  -webkit-box-align: center;
-  -ms-flex-align: center;
-  align-items: center;
-}
-
-.collapsible-year-body-caret,
-.collapsible-posts-list-caret {
-  display: inline-block;
-  font-size: 11px;
-  margin-right: 8px;
-  -webkit-box-flex: none;
-  -ms-flex: none;
-  flex: none;
-}
-
-.collapsible-year-body,
-.collapsible-posts-list{
-  display: none;
-}
-
-.heading-year-toggle-checkbox:checked + .collapsible-year-heading-label > .collapsible-year-body-caret,
-.heading-month-toggle-checkbox:checked + .collapsible-month-heading-label > .collapsible-posts-list-caret {
-  -webkit-transform: rotate(90deg);
-   -moz-transform: rotate(90deg);
-   -o-transform: rotate(90deg);
-   -ms-transform: rotate(90deg);
-   transform: rotate(90deg);
-}
-
-.heading-year-toggle-checkbox:checked + .collapsible-year-heading-label + .collapsible-year-body,
-.heading-month-toggle-checkbox:checked + .collapsible-month-heading-label + .collapsible-posts-list{
-  display: block;
-}
-
-/* blog post specific styling */
-table.post-table ,.post-table tr, .post-table td, .post-table th {
-  font-size: 20px;
-  border: solid;
-  border-color: black;
-  border-width: .5px;
-  padding: 5px;
-}
-
-.yaml-scale code {
-  font-size: small;
-}
-
-.inline-link a{
-  text-decoration: none;
-}
-
-img.big-img {
-  width: 100%;
-}
-
-.blog-content img {
-  max-width: 100%;
-}
-
-.blog-content .content {
-  overflow-x: scroll;
-}
-
-.flyout-button {
-  display: none;
-}
-
-.global-nav {
-  padding: 0;
-}
-
-/* .content img {
-max-width: 100%;
-} */
diff --git a/static/css/case-studies-gradient.css b/static/css/case-studies-gradient.css
index d33439d91f..274c0502e8 100644
--- a/static/css/case-studies-gradient.css
+++ b/static/css/case-studies-gradient.css
@@ -9,8 +9,6 @@
   display: inline-block;
   vertical-align: top;
   position: relative;
-  color:white;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:10%;
@@ -55,11 +53,9 @@ padding-top:5% !important;
 
 #caseStudyTitle {
     margin-top: 1em !important;
-    font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding-bottom:1%;
   padding-top:1%;
   font-weight:300;
@@ -68,7 +64,6 @@ p {
 }
 
 section {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:1.4em;
   letter-spacing:0.03em;
@@ -91,7 +86,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -111,7 +105,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -122,7 +115,6 @@ h1 {
 }
 
 .greybanner {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -137,7 +129,6 @@ h1 {
 }
 
 .quotetext {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:0%;
@@ -153,7 +144,6 @@ h1 {
 }
 
 .greyquotetext {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -162,7 +152,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:1.4em;
@@ -172,7 +161,6 @@ h2 {
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:1.4em;
@@ -182,7 +170,6 @@ h4 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -190,7 +177,6 @@ h4 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:1.2em !important;
   color:#3366ff;
@@ -210,14 +196,12 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   color:#606060;
   letter-spacing:0.03em;
   width:100%;
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#606060;
   letter-spacing:0.03em;
@@ -230,7 +214,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#606060;
   letter-spacing:0.03em;
@@ -244,7 +227,6 @@ hr {
   margin-left:10%;
   margin-top:2%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
 }
 
 .video {
@@ -278,7 +260,6 @@ hr {
   }
 
   h1 {
-    font-family: "Roboto", sans-serif;
     font-weight: bold;
     line-height: 36px;
     letter-spacing: 0.03em;
@@ -305,7 +286,6 @@ hr {
   }
 
   .details {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     font-size: 1em !important;
     color: #3366ff;
@@ -324,7 +304,6 @@ hr {
   .col1 {
     width: 90%;
     margin-left:5%;
-    font-family: "Roboto", sans-serif;
     color: #606060;
     letter-spacing: 0.03em;
   }
@@ -333,7 +312,6 @@ hr {
     width: 95%;
     padding-top: 2%;
     padding-bottom: 5%;
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     line-height: 20px;
     color: #606060;
@@ -364,8 +342,6 @@ hr {
     display: inline-block;
     vertical-align: top;
     position: relative;
-    color:white;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:20%;
@@ -401,7 +377,6 @@ hr {
   }
 
   p {
-    font-family:"Roboto", sans-serif;
     padding-bottom:2%;
     padding-top:2%;
     font-size:1em;
@@ -411,7 +386,6 @@ hr {
   }
 
   section {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     line-height:1.4em;
     letter-spacing:0.03em;
diff --git a/static/css/custom-jekyll/tags.css b/static/css/custom-jekyll/tags.css
deleted file mode 100644
index 1ff6d12e85..0000000000
--- a/static/css/custom-jekyll/tags.css
+++ /dev/null
@@ -1,59 +0,0 @@
-.no-underline {
-  text-decoration: none !important;
-}
-
-.hide {
-  display: none !important;
-}
-
-/* Tooltip container */
-.glossary-tooltip {
-    position: relative;
-    display: inline-block;
-    border-bottom: 1px dotted black; /* If you want dots under the hoverable text */
-    color: black;
-    text-decoration: none !important;
-}
-
-/* Tooltip text */
-.glossary-tooltip .tooltip-text {
-    visibility: hidden;
-    width: 300px;
-    background-color: #555;
-    color: #fff;
-    text-align: center;
-    padding: 5px 8px;
-    border-radius: 6px;
-
-    /* Position the tooltip text */
-    position: absolute;
-    z-index: 10;
-    bottom: 125%;
-    left: 50%;
-    margin-left: -150px;
-
-    /* Fade in tooltip */
-    opacity: 0;
-    transition: opacity 0.3s;
-}
-
-/* Tooltip arrow */
-.glossary-tooltip .tooltip-text::after {
-    content: "";
-    position: absolute;
-    top: 100%;
-    left: 50%;
-    margin-left: -5px;
-    border-width: 5px;
-    border-style: solid;
-    border-color: #555 transparent transparent transparent;
-}
-
-/* Show the tooltip text when you mouse over the tooltip container */
-.glossary-tooltip:hover .tooltip-text {
-    visibility: visible;
-    opacity: 1;
-    font-size: 1rem;
-    font-weight: 400;
-}
-
diff --git a/static/css/callouts.css b/static/css/feature-states.css
similarity index 67%
rename from static/css/callouts.css
rename to static/css/feature-states.css
index ffc61ed4a5..725cf9e0fc 100644
--- a/static/css/callouts.css
+++ b/static/css/feature-states.css
@@ -1,24 +1,3 @@
-/* Callouts */
-.caution, .note, .warning {
-    padding: 20px;
-    margin: 20px 0;
-    border: 1px solid #eee;
-    border-left-width: 5px;
-    border-radius: 3px;
-}
-
-.caution {
-    border-left-color: #f0ad4e;
-}
-
-.note {
-    border-left-color: #428bca;
-}
-
-.warning {
-    border-left-color: #d9534f;
-}
-
 /* Feature States */
 
 .beta, .stable, .alpha, .deprecated {
diff --git a/static/css/gridpage.css b/static/css/gridpage.css
index 542eadea8f..7da7f1973d 100644
--- a/static/css/gridpage.css
+++ b/static/css/gridpage.css
@@ -89,7 +89,6 @@
 }
 
 .gridPage #mainContent .content .case-study p {
-    font-family: "Roboto", sans-serif;
     font-size: 16px;
     padding: 0;
 }
diff --git a/static/css/jquery-ui.min.css b/static/css/jquery-ui.min.css
deleted file mode 100644
index dbd7235360..0000000000
--- a/static/css/jquery-ui.min.css
+++ /dev/null
@@ -1,7 +0,0 @@
-/*! jQuery UI - v1.12.1 - 2016-09-14
-* http://jqueryui.com
-* Includes: core.css, accordion.css, autocomplete.css, menu.css, button.css, controlgroup.css, checkboxradio.css, datepicker.css, dialog.css, draggable.css, resizable.css, progressbar.css, selectable.css, selectmenu.css, slider.css, sortable.css, spinner.css, tabs.css, tooltip.css, theme.css
-* To view and modify this theme, visit http://jqueryui.com/themeroller/?ffDefault=Verdana%2CArial%2Csans-serif&fwDefault=normal&fsDefault=1.1em&cornerRadius=4px&bgColorHeader=cccccc&bgTextureHeader=highlight_soft&bgImgOpacityHeader=75&borderColorHeader=aaaaaa&fcHeader=222222&iconColorHeader=222222&bgColorContent=ffffff&bgTextureContent=flat&bgImgOpacityContent=75&borderColorContent=aaaaaa&fcContent=222222&iconColorContent=222222&bgColorDefault=e6e6e6&bgTextureDefault=glass&bgImgOpacityDefault=75&borderColorDefault=d3d3d3&fcDefault=555555&iconColorDefault=888888&bgColorHover=dadada&bgTextureHover=glass&bgImgOpacityHover=75&borderColorHover=999999&fcHover=212121&iconColorHover=454545&bgColorActive=ffffff&bgTextureActive=glass&bgImgOpacityActive=65&borderColorActive=aaaaaa&fcActive=212121&iconColorActive=454545&bgColorHighlight=fbf9ee&bgTextureHighlight=glass&bgImgOpacityHighlight=55&borderColorHighlight=fcefa1&fcHighlight=363636&iconColorHighlight=2e83ff&bgColorError=fef1ec&bgTextureError=glass&bgImgOpacityError=95&borderColorError=cd0a0a&fcError=cd0a0a&iconColorError=cd0a0a&bgColorOverlay=aaaaaa&bgTextureOverlay=flat&bgImgOpacityOverlay=0&opacityOverlay=30&bgColorShadow=aaaaaa&bgTextureShadow=flat&bgImgOpacityShadow=0&opacityShadow=30&thicknessShadow=8px&offsetTopShadow=-8px&offsetLeftShadow=-8px&cornerRadiusShadow=8px
-* Copyright jQuery Foundation and other contributors; Licensed MIT */
-
-.ui-helper-hidden{display:none}.ui-helper-hidden-accessible{border:0;clip:rect(0 0 0 0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}.ui-helper-reset{margin:0;padding:0;border:0;outline:0;line-height:1.3;text-decoration:none;font-size:100%;list-style:none}.ui-helper-clearfix:before,.ui-helper-clearfix:after{content:"";display:table;border-collapse:collapse}.ui-helper-clearfix:after{clear:both}.ui-helper-zfix{width:100%;height:100%;top:0;left:0;position:absolute;opacity:0;filter:Alpha(Opacity=0)}.ui-front{z-index:100}.ui-state-disabled{cursor:default!important;pointer-events:none}.ui-icon{display:inline-block;vertical-align:middle;margin-top:-.25em;position:relative;text-indent:-99999px;overflow:hidden;background-repeat:no-repeat}.ui-widget-icon-block{left:50%;margin-left:-8px;display:block}.ui-widget-overlay{position:fixed;top:0;left:0;width:100%;height:100%}.ui-accordion .ui-accordion-header{display:block;cursor:pointer;position:relative;margin:2px 0 0 0;padding:.5em .5em .5em .7em;font-size:100%}.ui-accordion .ui-accordion-content{padding:1em 2.2em;border-top:0;overflow:auto}.ui-autocomplete{position:absolute;top:0;left:0;cursor:default}.ui-menu{list-style:none;padding:0;margin:0;display:block;outline:0}.ui-menu .ui-menu{position:absolute}.ui-menu .ui-menu-item{margin:0;cursor:pointer;list-style-image:url("data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7")}.ui-menu .ui-menu-item-wrapper{position:relative;padding:3px 1em 3px .4em}.ui-menu .ui-menu-divider{margin:5px 0;height:0;font-size:0;line-height:0;border-width:1px 0 0 0}.ui-menu .ui-state-focus,.ui-menu .ui-state-active{margin:-1px}.ui-menu-icons{position:relative}.ui-menu-icons .ui-menu-item-wrapper{padding-left:2em}.ui-menu .ui-icon{position:absolute;top:0;bottom:0;left:.2em;margin:auto 0}.ui-menu .ui-menu-icon{left:auto;right:0}.ui-button{padding:.4em 1em;display:inline-block;position:relative;line-height:normal;margin-right:.1em;cursor:pointer;vertical-align:middle;text-align:center;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none;overflow:visible}.ui-button,.ui-button:link,.ui-button:visited,.ui-button:hover,.ui-button:active{text-decoration:none}.ui-button-icon-only{width:2em;box-sizing:border-box;text-indent:-9999px;white-space:nowrap}input.ui-button.ui-button-icon-only{text-indent:0}.ui-button-icon-only .ui-icon{position:absolute;top:50%;left:50%;margin-top:-8px;margin-left:-8px}.ui-button.ui-icon-notext .ui-icon{padding:0;width:2.1em;height:2.1em;text-indent:-9999px;white-space:nowrap}input.ui-button.ui-icon-notext .ui-icon{width:auto;height:auto;text-indent:0;white-space:normal;padding:.4em 1em}input.ui-button::-moz-focus-inner,button.ui-button::-moz-focus-inner{border:0;padding:0}.ui-controlgroup{vertical-align:middle;display:inline-block}.ui-controlgroup > .ui-controlgroup-item{float:left;margin-left:0;margin-right:0}.ui-controlgroup > .ui-controlgroup-item:focus,.ui-controlgroup > .ui-controlgroup-item.ui-visual-focus{z-index:9999}.ui-controlgroup-vertical > .ui-controlgroup-item{display:block;float:none;width:100%;margin-top:0;margin-bottom:0;text-align:left}.ui-controlgroup-vertical .ui-controlgroup-item{box-sizing:border-box}.ui-controlgroup .ui-controlgroup-label{padding:.4em 1em}.ui-controlgroup .ui-controlgroup-label span{font-size:80%}.ui-controlgroup-horizontal .ui-controlgroup-label + .ui-controlgroup-item{border-left:none}.ui-controlgroup-vertical .ui-controlgroup-label + .ui-controlgroup-item{border-top:none}.ui-controlgroup-horizontal .ui-controlgroup-label.ui-widget-content{border-right:none}.ui-controlgroup-vertical .ui-controlgroup-label.ui-widget-content{border-bottom:none}.ui-controlgroup-vertical .ui-spinner-input{width:75%;width:calc( 100% - 2.4em )}.ui-controlgroup-vertical .ui-spinner .ui-spinner-up{border-top-style:solid}.ui-checkboxradio-label .ui-icon-background{box-shadow:inset 1px 1px 1px #ccc;border-radius:.12em;border:none}.ui-checkboxradio-radio-label .ui-icon-background{width:16px;height:16px;border-radius:1em;overflow:visible;border:none}.ui-checkboxradio-radio-label.ui-checkboxradio-checked .ui-icon,.ui-checkboxradio-radio-label.ui-checkboxradio-checked:hover .ui-icon{background-image:none;width:8px;height:8px;border-width:4px;border-style:solid}.ui-checkboxradio-disabled{pointer-events:none}.ui-datepicker{width:17em;padding:.2em .2em 0;display:none}.ui-datepicker .ui-datepicker-header{position:relative;padding:.2em 0}.ui-datepicker .ui-datepicker-prev,.ui-datepicker .ui-datepicker-next{position:absolute;top:2px;width:1.8em;height:1.8em}.ui-datepicker .ui-datepicker-prev-hover,.ui-datepicker .ui-datepicker-next-hover{top:1px}.ui-datepicker .ui-datepicker-prev{left:2px}.ui-datepicker .ui-datepicker-next{right:2px}.ui-datepicker .ui-datepicker-prev-hover{left:1px}.ui-datepicker .ui-datepicker-next-hover{right:1px}.ui-datepicker .ui-datepicker-prev span,.ui-datepicker .ui-datepicker-next span{display:block;position:absolute;left:50%;margin-left:-8px;top:50%;margin-top:-8px}.ui-datepicker .ui-datepicker-title{margin:0 2.3em;line-height:1.8em;text-align:center}.ui-datepicker .ui-datepicker-title select{font-size:1em;margin:1px 0}.ui-datepicker select.ui-datepicker-month,.ui-datepicker select.ui-datepicker-year{width:45%}.ui-datepicker table{width:100%;font-size:.9em;border-collapse:collapse;margin:0 0 .4em}.ui-datepicker th{padding:.7em .3em;text-align:center;font-weight:bold;border:0}.ui-datepicker td{border:0;padding:1px}.ui-datepicker td span,.ui-datepicker td a{display:block;padding:.2em;text-align:right;text-decoration:none}.ui-datepicker .ui-datepicker-buttonpane{background-image:none;margin:.7em 0 0 0;padding:0 .2em;border-left:0;border-right:0;border-bottom:0}.ui-datepicker .ui-datepicker-buttonpane button{float:right;margin:.5em .2em .4em;cursor:pointer;padding:.2em .6em .3em .6em;width:auto;overflow:visible}.ui-datepicker .ui-datepicker-buttonpane button.ui-datepicker-current{float:left}.ui-datepicker.ui-datepicker-multi{width:auto}.ui-datepicker-multi .ui-datepicker-group{float:left}.ui-datepicker-multi .ui-datepicker-group table{width:95%;margin:0 auto .4em}.ui-datepicker-multi-2 .ui-datepicker-group{width:50%}.ui-datepicker-multi-3 .ui-datepicker-group{width:33.3%}.ui-datepicker-multi-4 .ui-datepicker-group{width:25%}.ui-datepicker-multi .ui-datepicker-group-last .ui-datepicker-header,.ui-datepicker-multi .ui-datepicker-group-middle .ui-datepicker-header{border-left-width:0}.ui-datepicker-multi .ui-datepicker-buttonpane{clear:left}.ui-datepicker-row-break{clear:both;width:100%;font-size:0}.ui-datepicker-rtl{direction:rtl}.ui-datepicker-rtl .ui-datepicker-prev{right:2px;left:auto}.ui-datepicker-rtl .ui-datepicker-next{left:2px;right:auto}.ui-datepicker-rtl .ui-datepicker-prev:hover{right:1px;left:auto}.ui-datepicker-rtl .ui-datepicker-next:hover{left:1px;right:auto}.ui-datepicker-rtl .ui-datepicker-buttonpane{clear:right}.ui-datepicker-rtl .ui-datepicker-buttonpane button{float:left}.ui-datepicker-rtl .ui-datepicker-buttonpane button.ui-datepicker-current,.ui-datepicker-rtl .ui-datepicker-group{float:right}.ui-datepicker-rtl .ui-datepicker-group-last .ui-datepicker-header,.ui-datepicker-rtl .ui-datepicker-group-middle .ui-datepicker-header{border-right-width:0;border-left-width:1px}.ui-datepicker .ui-icon{display:block;text-indent:-99999px;overflow:hidden;background-repeat:no-repeat;left:.5em;top:.3em}.ui-dialog{position:absolute;top:0;left:0;padding:.2em;outline:0}.ui-dialog .ui-dialog-titlebar{padding:.4em 1em;position:relative}.ui-dialog .ui-dialog-title{float:left;margin:.1em 0;white-space:nowrap;width:90%;overflow:hidden;text-overflow:ellipsis}.ui-dialog .ui-dialog-titlebar-close{position:absolute;right:.3em;top:50%;width:20px;margin:-10px 0 0 0;padding:1px;height:20px}.ui-dialog .ui-dialog-content{position:relative;border:0;padding:.5em 1em;background:none;overflow:auto}.ui-dialog .ui-dialog-buttonpane{text-align:left;border-width:1px 0 0 0;background-image:none;margin-top:.5em;padding:.3em 1em .5em .4em}.ui-dialog .ui-dialog-buttonpane .ui-dialog-buttonset{float:right}.ui-dialog .ui-dialog-buttonpane button{margin:.5em .4em .5em 0;cursor:pointer}.ui-dialog .ui-resizable-n{height:2px;top:0}.ui-dialog .ui-resizable-e{width:2px;right:0}.ui-dialog .ui-resizable-s{height:2px;bottom:0}.ui-dialog .ui-resizable-w{width:2px;left:0}.ui-dialog .ui-resizable-se,.ui-dialog .ui-resizable-sw,.ui-dialog .ui-resizable-ne,.ui-dialog .ui-resizable-nw{width:7px;height:7px}.ui-dialog .ui-resizable-se{right:0;bottom:0}.ui-dialog .ui-resizable-sw{left:0;bottom:0}.ui-dialog .ui-resizable-ne{right:0;top:0}.ui-dialog .ui-resizable-nw{left:0;top:0}.ui-draggable .ui-dialog-titlebar{cursor:move}.ui-draggable-handle{-ms-touch-action:none;touch-action:none}.ui-resizable{position:relative}.ui-resizable-handle{position:absolute;font-size:0.1px;display:block;-ms-touch-action:none;touch-action:none}.ui-resizable-disabled .ui-resizable-handle,.ui-resizable-autohide .ui-resizable-handle{display:none}.ui-resizable-n{cursor:n-resize;height:7px;width:100%;top:-5px;left:0}.ui-resizable-s{cursor:s-resize;height:7px;width:100%;bottom:-5px;left:0}.ui-resizable-e{cursor:e-resize;width:7px;right:-5px;top:0;height:100%}.ui-resizable-w{cursor:w-resize;width:7px;left:-5px;top:0;height:100%}.ui-resizable-se{cursor:se-resize;width:12px;height:12px;right:1px;bottom:1px}.ui-resizable-sw{cursor:sw-resize;width:9px;height:9px;left:-5px;bottom:-5px}.ui-resizable-nw{cursor:nw-resize;width:9px;height:9px;left:-5px;top:-5px}.ui-resizable-ne{cursor:ne-resize;width:9px;height:9px;right:-5px;top:-5px}.ui-progressbar{height:2em;text-align:left;overflow:hidden}.ui-progressbar .ui-progressbar-value{margin:-1px;height:100%}.ui-progressbar .ui-progressbar-overlay{background:url("data:image/gif;base64,R0lGODlhKAAoAIABAAAAAP///yH/C05FVFNDQVBFMi4wAwEAAAAh+QQJAQABACwAAAAAKAAoAAACkYwNqXrdC52DS06a7MFZI+4FHBCKoDeWKXqymPqGqxvJrXZbMx7Ttc+w9XgU2FB3lOyQRWET2IFGiU9m1frDVpxZZc6bfHwv4c1YXP6k1Vdy292Fb6UkuvFtXpvWSzA+HycXJHUXiGYIiMg2R6W459gnWGfHNdjIqDWVqemH2ekpObkpOlppWUqZiqr6edqqWQAAIfkECQEAAQAsAAAAACgAKAAAApSMgZnGfaqcg1E2uuzDmmHUBR8Qil95hiPKqWn3aqtLsS18y7G1SzNeowWBENtQd+T1JktP05nzPTdJZlR6vUxNWWjV+vUWhWNkWFwxl9VpZRedYcflIOLafaa28XdsH/ynlcc1uPVDZxQIR0K25+cICCmoqCe5mGhZOfeYSUh5yJcJyrkZWWpaR8doJ2o4NYq62lAAACH5BAkBAAEALAAAAAAoACgAAAKVDI4Yy22ZnINRNqosw0Bv7i1gyHUkFj7oSaWlu3ovC8GxNso5fluz3qLVhBVeT/Lz7ZTHyxL5dDalQWPVOsQWtRnuwXaFTj9jVVh8pma9JjZ4zYSj5ZOyma7uuolffh+IR5aW97cHuBUXKGKXlKjn+DiHWMcYJah4N0lYCMlJOXipGRr5qdgoSTrqWSq6WFl2ypoaUAAAIfkECQEAAQAsAAAAACgAKAAAApaEb6HLgd/iO7FNWtcFWe+ufODGjRfoiJ2akShbueb0wtI50zm02pbvwfWEMWBQ1zKGlLIhskiEPm9R6vRXxV4ZzWT2yHOGpWMyorblKlNp8HmHEb/lCXjcW7bmtXP8Xt229OVWR1fod2eWqNfHuMjXCPkIGNileOiImVmCOEmoSfn3yXlJWmoHGhqp6ilYuWYpmTqKUgAAIfkECQEAAQAsAAAAACgAKAAAApiEH6kb58biQ3FNWtMFWW3eNVcojuFGfqnZqSebuS06w5V80/X02pKe8zFwP6EFWOT1lDFk8rGERh1TTNOocQ61Hm4Xm2VexUHpzjymViHrFbiELsefVrn6XKfnt2Q9G/+Xdie499XHd2g4h7ioOGhXGJboGAnXSBnoBwKYyfioubZJ2Hn0RuRZaflZOil56Zp6iioKSXpUAAAh+QQJAQABACwAAAAAKAAoAAACkoQRqRvnxuI7kU1a1UU5bd5tnSeOZXhmn5lWK3qNTWvRdQxP8qvaC+/yaYQzXO7BMvaUEmJRd3TsiMAgswmNYrSgZdYrTX6tSHGZO73ezuAw2uxuQ+BbeZfMxsexY35+/Qe4J1inV0g4x3WHuMhIl2jXOKT2Q+VU5fgoSUI52VfZyfkJGkha6jmY+aaYdirq+lQAACH5BAkBAAEALAAAAAAoACgAAAKWBIKpYe0L3YNKToqswUlvznigd4wiR4KhZrKt9Upqip61i9E3vMvxRdHlbEFiEXfk9YARYxOZZD6VQ2pUunBmtRXo1Lf8hMVVcNl8JafV38aM2/Fu5V16Bn63r6xt97j09+MXSFi4BniGFae3hzbH9+hYBzkpuUh5aZmHuanZOZgIuvbGiNeomCnaxxap2upaCZsq+1kAACH5BAkBAAEALAAAAAAoACgAAAKXjI8By5zf4kOxTVrXNVlv1X0d8IGZGKLnNpYtm8Lr9cqVeuOSvfOW79D9aDHizNhDJidFZhNydEahOaDH6nomtJjp1tutKoNWkvA6JqfRVLHU/QUfau9l2x7G54d1fl995xcIGAdXqMfBNadoYrhH+Mg2KBlpVpbluCiXmMnZ2Sh4GBqJ+ckIOqqJ6LmKSllZmsoq6wpQAAAh+QQJAQABACwAAAAAKAAoAAAClYx/oLvoxuJDkU1a1YUZbJ59nSd2ZXhWqbRa2/gF8Gu2DY3iqs7yrq+xBYEkYvFSM8aSSObE+ZgRl1BHFZNr7pRCavZ5BW2142hY3AN/zWtsmf12p9XxxFl2lpLn1rseztfXZjdIWIf2s5dItwjYKBgo9yg5pHgzJXTEeGlZuenpyPmpGQoKOWkYmSpaSnqKileI2FAAACH5BAkBAAEALAAAAAAoACgAAAKVjB+gu+jG4kORTVrVhRlsnn2dJ3ZleFaptFrb+CXmO9OozeL5VfP99HvAWhpiUdcwkpBH3825AwYdU8xTqlLGhtCosArKMpvfa1mMRae9VvWZfeB2XfPkeLmm18lUcBj+p5dnN8jXZ3YIGEhYuOUn45aoCDkp16hl5IjYJvjWKcnoGQpqyPlpOhr3aElaqrq56Bq7VAAAOw==");height:100%;filter:alpha(opacity=25);opacity:0.25}.ui-progressbar-indeterminate .ui-progressbar-value{background-image:none}.ui-selectable{-ms-touch-action:none;touch-action:none}.ui-selectable-helper{position:absolute;z-index:100;border:1px dotted black}.ui-selectmenu-menu{padding:0;margin:0;position:absolute;top:0;left:0;display:none}.ui-selectmenu-menu .ui-menu{overflow:auto;overflow-x:hidden;padding-bottom:1px}.ui-selectmenu-menu .ui-menu .ui-selectmenu-optgroup{font-size:1em;font-weight:bold;line-height:1.5;padding:2px 0.4em;margin:0.5em 0 0 0;height:auto;border:0}.ui-selectmenu-open{display:block}.ui-selectmenu-text{display:block;margin-right:20px;overflow:hidden;text-overflow:ellipsis}.ui-selectmenu-button.ui-button{text-align:left;white-space:nowrap;width:14em}.ui-selectmenu-icon.ui-icon{float:right;margin-top:0}.ui-slider{position:relative;text-align:left}.ui-slider .ui-slider-handle{position:absolute;z-index:2;width:1.2em;height:1.2em;cursor:default;-ms-touch-action:none;touch-action:none}.ui-slider .ui-slider-range{position:absolute;z-index:1;font-size:.7em;display:block;border:0;background-position:0 0}.ui-slider.ui-state-disabled .ui-slider-handle,.ui-slider.ui-state-disabled .ui-slider-range{filter:inherit}.ui-slider-horizontal{height:.8em}.ui-slider-horizontal .ui-slider-handle{top:-.3em;margin-left:-.6em}.ui-slider-horizontal .ui-slider-range{top:0;height:100%}.ui-slider-horizontal .ui-slider-range-min{left:0}.ui-slider-horizontal .ui-slider-range-max{right:0}.ui-slider-vertical{width:.8em;height:100px}.ui-slider-vertical .ui-slider-handle{left:-.3em;margin-left:0;margin-bottom:-.6em}.ui-slider-vertical .ui-slider-range{left:0;width:100%}.ui-slider-vertical .ui-slider-range-min{bottom:0}.ui-slider-vertical .ui-slider-range-max{top:0}.ui-sortable-handle{-ms-touch-action:none;touch-action:none}.ui-spinner{position:relative;display:inline-block;overflow:hidden;padding:0;vertical-align:middle}.ui-spinner-input{border:none;background:none;color:inherit;padding:.222em 0;margin:.2em 0;vertical-align:middle;margin-left:.4em;margin-right:2em}.ui-spinner-button{width:1.6em;height:50%;font-size:.5em;padding:0;margin:0;text-align:center;position:absolute;cursor:default;display:block;overflow:hidden;right:0}.ui-spinner a.ui-spinner-button{border-top-style:none;border-bottom-style:none;border-right-style:none}.ui-spinner-up{top:0}.ui-spinner-down{bottom:0}.ui-tabs{position:relative;padding:.2em}.ui-tabs .ui-tabs-nav{margin:0;padding:.2em .2em 0}.ui-tabs .ui-tabs-nav li{list-style:none;float:left;position:relative;top:0;margin:1px .2em 0 0;border-bottom-width:0;padding:0;white-space:nowrap}.ui-tabs .ui-tabs-nav .ui-tabs-anchor{float:left;padding:.5em 1em;text-decoration:none}.ui-tabs .ui-tabs-nav li.ui-tabs-active{margin-bottom:-1px;padding-bottom:1px}.ui-tabs .ui-tabs-nav li.ui-tabs-active .ui-tabs-anchor,.ui-tabs .ui-tabs-nav li.ui-state-disabled .ui-tabs-anchor,.ui-tabs .ui-tabs-nav li.ui-tabs-loading .ui-tabs-anchor{cursor:text}.ui-tabs-collapsible .ui-tabs-nav li.ui-tabs-active .ui-tabs-anchor{cursor:pointer}.ui-tabs .ui-tabs-panel{display:block;border-width:0;padding:1em 1.4em;background:none}.ui-tooltip{padding:8px;position:absolute;z-index:9999;max-width:300px}body .ui-tooltip{border-width:2px}.ui-widget{font-family:Verdana,Arial,sans-serif;font-size:1.1em}.ui-widget .ui-widget{font-size:1em}.ui-widget input,.ui-widget select,.ui-widget textarea,.ui-widget button{font-family:Verdana,Arial,sans-serif;font-size:1em}.ui-widget.ui-widget-content{border:1px solid #d3d3d3}.ui-widget-content{border:1px solid #aaa;background:#fff;color:#222}.ui-widget-content a{color:#222}.ui-widget-header{border:1px solid #aaa;background:#ccc url("images/ui-bg_highlight-soft_75_cccccc_1x100.png") 50% 50% repeat-x;color:#222;font-weight:bold}.ui-widget-header a{color:#222}.ui-state-default,.ui-widget-content .ui-state-default,.ui-widget-header .ui-state-default,.ui-button,html .ui-button.ui-state-disabled:hover,html .ui-button.ui-state-disabled:active{border:1px solid #d3d3d3;background:#e6e6e6 url("images/ui-bg_glass_75_e6e6e6_1x400.png") 50% 50% repeat-x;font-weight:normal;color:#555}.ui-state-default a,.ui-state-default a:link,.ui-state-default a:visited,a.ui-button,a:link.ui-button,a:visited.ui-button,.ui-button{color:#555;text-decoration:none}.ui-state-hover,.ui-widget-content .ui-state-hover,.ui-widget-header .ui-state-hover,.ui-state-focus,.ui-widget-content .ui-state-focus,.ui-widget-header .ui-state-focus,.ui-button:hover,.ui-button:focus{border:1px solid #999;background:#dadada url("images/ui-bg_glass_75_dadada_1x400.png") 50% 50% repeat-x;font-weight:normal;color:#212121}.ui-state-hover a,.ui-state-hover a:hover,.ui-state-hover a:link,.ui-state-hover a:visited,.ui-state-focus a,.ui-state-focus a:hover,.ui-state-focus a:link,.ui-state-focus a:visited,a.ui-button:hover,a.ui-button:focus{color:#212121;text-decoration:none}.ui-visual-focus{box-shadow:0 0 3px 1px rgb(94,158,214)}.ui-state-active,.ui-widget-content .ui-state-active,.ui-widget-header .ui-state-active,a.ui-button:active,.ui-button:active,.ui-button.ui-state-active:hover{border:1px solid #aaa;background:#fff url("images/ui-bg_glass_65_ffffff_1x400.png") 50% 50% repeat-x;font-weight:normal;color:#212121}.ui-icon-background,.ui-state-active .ui-icon-background{border:#aaa;background-color:#212121}.ui-state-active a,.ui-state-active a:link,.ui-state-active a:visited{color:#212121;text-decoration:none}.ui-state-highlight,.ui-widget-content .ui-state-highlight,.ui-widget-header .ui-state-highlight{border:1px solid #fcefa1;background:#fbf9ee url("images/ui-bg_glass_55_fbf9ee_1x400.png") 50% 50% repeat-x;color:#363636}.ui-state-checked{border:1px solid #fcefa1;background:#fbf9ee}.ui-state-highlight a,.ui-widget-content .ui-state-highlight a,.ui-widget-header .ui-state-highlight a{color:#363636}.ui-state-error,.ui-widget-content .ui-state-error,.ui-widget-header .ui-state-error{border:1px solid #cd0a0a;background:#fef1ec url("images/ui-bg_glass_95_fef1ec_1x400.png") 50% 50% repeat-x;color:#cd0a0a}.ui-state-error a,.ui-widget-content .ui-state-error a,.ui-widget-header .ui-state-error a{color:#cd0a0a}.ui-state-error-text,.ui-widget-content .ui-state-error-text,.ui-widget-header .ui-state-error-text{color:#cd0a0a}.ui-priority-primary,.ui-widget-content .ui-priority-primary,.ui-widget-header .ui-priority-primary{font-weight:bold}.ui-priority-secondary,.ui-widget-content .ui-priority-secondary,.ui-widget-header .ui-priority-secondary{opacity:.7;filter:Alpha(Opacity=70);font-weight:normal}.ui-state-disabled,.ui-widget-content .ui-state-disabled,.ui-widget-header .ui-state-disabled{opacity:.35;filter:Alpha(Opacity=35);background-image:none}.ui-state-disabled .ui-icon{filter:Alpha(Opacity=35)}.ui-icon{width:16px;height:16px}.ui-icon,.ui-widget-content .ui-icon{background-image:url("images/ui-icons_222222_256x240.png")}.ui-widget-header .ui-icon{background-image:url("images/ui-icons_222222_256x240.png")}.ui-state-hover .ui-icon,.ui-state-focus .ui-icon,.ui-button:hover .ui-icon,.ui-button:focus .ui-icon{background-image:url("images/ui-icons_454545_256x240.png")}.ui-state-active .ui-icon,.ui-button:active .ui-icon{background-image:url("images/ui-icons_454545_256x240.png")}.ui-state-highlight .ui-icon,.ui-button .ui-state-highlight.ui-icon{background-image:url("images/ui-icons_2e83ff_256x240.png")}.ui-state-error .ui-icon,.ui-state-error-text .ui-icon{background-image:url("images/ui-icons_cd0a0a_256x240.png")}.ui-button .ui-icon{background-image:url("images/ui-icons_888888_256x240.png")}.ui-icon-blank{background-position:16px 16px}.ui-icon-caret-1-n{background-position:0 0}.ui-icon-caret-1-ne{background-position:-16px 0}.ui-icon-caret-1-e{background-position:-32px 0}.ui-icon-caret-1-se{background-position:-48px 0}.ui-icon-caret-1-s{background-position:-65px 0}.ui-icon-caret-1-sw{background-position:-80px 0}.ui-icon-caret-1-w{background-position:-96px 0}.ui-icon-caret-1-nw{background-position:-112px 0}.ui-icon-caret-2-n-s{background-position:-128px 0}.ui-icon-caret-2-e-w{background-position:-144px 0}.ui-icon-triangle-1-n{background-position:0 -16px}.ui-icon-triangle-1-ne{background-position:-16px -16px}.ui-icon-triangle-1-e{background-position:-32px -16px}.ui-icon-triangle-1-se{background-position:-48px -16px}.ui-icon-triangle-1-s{background-position:-65px -16px}.ui-icon-triangle-1-sw{background-position:-80px -16px}.ui-icon-triangle-1-w{background-position:-96px -16px}.ui-icon-triangle-1-nw{background-position:-112px -16px}.ui-icon-triangle-2-n-s{background-position:-128px -16px}.ui-icon-triangle-2-e-w{background-position:-144px -16px}.ui-icon-arrow-1-n{background-position:0 -32px}.ui-icon-arrow-1-ne{background-position:-16px -32px}.ui-icon-arrow-1-e{background-position:-32px -32px}.ui-icon-arrow-1-se{background-position:-48px -32px}.ui-icon-arrow-1-s{background-position:-65px -32px}.ui-icon-arrow-1-sw{background-position:-80px -32px}.ui-icon-arrow-1-w{background-position:-96px -32px}.ui-icon-arrow-1-nw{background-position:-112px -32px}.ui-icon-arrow-2-n-s{background-position:-128px -32px}.ui-icon-arrow-2-ne-sw{background-position:-144px -32px}.ui-icon-arrow-2-e-w{background-position:-160px -32px}.ui-icon-arrow-2-se-nw{background-position:-176px -32px}.ui-icon-arrowstop-1-n{background-position:-192px -32px}.ui-icon-arrowstop-1-e{background-position:-208px -32px}.ui-icon-arrowstop-1-s{background-position:-224px -32px}.ui-icon-arrowstop-1-w{background-position:-240px -32px}.ui-icon-arrowthick-1-n{background-position:1px -48px}.ui-icon-arrowthick-1-ne{background-position:-16px -48px}.ui-icon-arrowthick-1-e{background-position:-32px -48px}.ui-icon-arrowthick-1-se{background-position:-48px -48px}.ui-icon-arrowthick-1-s{background-position:-64px -48px}.ui-icon-arrowthick-1-sw{background-position:-80px -48px}.ui-icon-arrowthick-1-w{background-position:-96px -48px}.ui-icon-arrowthick-1-nw{background-position:-112px -48px}.ui-icon-arrowthick-2-n-s{background-position:-128px -48px}.ui-icon-arrowthick-2-ne-sw{background-position:-144px -48px}.ui-icon-arrowthick-2-e-w{background-position:-160px -48px}.ui-icon-arrowthick-2-se-nw{background-position:-176px -48px}.ui-icon-arrowthickstop-1-n{background-position:-192px -48px}.ui-icon-arrowthickstop-1-e{background-position:-208px -48px}.ui-icon-arrowthickstop-1-s{background-position:-224px -48px}.ui-icon-arrowthickstop-1-w{background-position:-240px -48px}.ui-icon-arrowreturnthick-1-w{background-position:0 -64px}.ui-icon-arrowreturnthick-1-n{background-position:-16px -64px}.ui-icon-arrowreturnthick-1-e{background-position:-32px -64px}.ui-icon-arrowreturnthick-1-s{background-position:-48px -64px}.ui-icon-arrowreturn-1-w{background-position:-64px -64px}.ui-icon-arrowreturn-1-n{background-position:-80px -64px}.ui-icon-arrowreturn-1-e{background-position:-96px -64px}.ui-icon-arrowreturn-1-s{background-position:-112px -64px}.ui-icon-arrowrefresh-1-w{background-position:-128px -64px}.ui-icon-arrowrefresh-1-n{background-position:-144px -64px}.ui-icon-arrowrefresh-1-e{background-position:-160px -64px}.ui-icon-arrowrefresh-1-s{background-position:-176px -64px}.ui-icon-arrow-4{background-position:0 -80px}.ui-icon-arrow-4-diag{background-position:-16px -80px}.ui-icon-extlink{background-position:-32px -80px}.ui-icon-newwin{background-position:-48px -80px}.ui-icon-refresh{background-position:-64px -80px}.ui-icon-shuffle{background-position:-80px -80px}.ui-icon-transfer-e-w{background-position:-96px -80px}.ui-icon-transferthick-e-w{background-position:-112px -80px}.ui-icon-folder-collapsed{background-position:0 -96px}.ui-icon-folder-open{background-position:-16px -96px}.ui-icon-document{background-position:-32px -96px}.ui-icon-document-b{background-position:-48px -96px}.ui-icon-note{background-position:-64px -96px}.ui-icon-mail-closed{background-position:-80px -96px}.ui-icon-mail-open{background-position:-96px -96px}.ui-icon-suitcase{background-position:-112px -96px}.ui-icon-comment{background-position:-128px -96px}.ui-icon-person{background-position:-144px -96px}.ui-icon-print{background-position:-160px -96px}.ui-icon-trash{background-position:-176px -96px}.ui-icon-locked{background-position:-192px -96px}.ui-icon-unlocked{background-position:-208px -96px}.ui-icon-bookmark{background-position:-224px -96px}.ui-icon-tag{background-position:-240px -96px}.ui-icon-home{background-position:0 -112px}.ui-icon-flag{background-position:-16px -112px}.ui-icon-calendar{background-position:-32px -112px}.ui-icon-cart{background-position:-48px -112px}.ui-icon-pencil{background-position:-64px -112px}.ui-icon-clock{background-position:-80px -112px}.ui-icon-disk{background-position:-96px -112px}.ui-icon-calculator{background-position:-112px -112px}.ui-icon-zoomin{background-position:-128px -112px}.ui-icon-zoomout{background-position:-144px -112px}.ui-icon-search{background-position:-160px -112px}.ui-icon-wrench{background-position:-176px -112px}.ui-icon-gear{background-position:-192px -112px}.ui-icon-heart{background-position:-208px -112px}.ui-icon-star{background-position:-224px -112px}.ui-icon-link{background-position:-240px -112px}.ui-icon-cancel{background-position:0 -128px}.ui-icon-plus{background-position:-16px -128px}.ui-icon-plusthick{background-position:-32px -128px}.ui-icon-minus{background-position:-48px -128px}.ui-icon-minusthick{background-position:-64px -128px}.ui-icon-close{background-position:-80px -128px}.ui-icon-closethick{background-position:-96px -128px}.ui-icon-key{background-position:-112px -128px}.ui-icon-lightbulb{background-position:-128px -128px}.ui-icon-scissors{background-position:-144px -128px}.ui-icon-clipboard{background-position:-160px -128px}.ui-icon-copy{background-position:-176px -128px}.ui-icon-contact{background-position:-192px -128px}.ui-icon-image{background-position:-208px -128px}.ui-icon-video{background-position:-224px -128px}.ui-icon-script{background-position:-240px -128px}.ui-icon-alert{background-position:0 -144px}.ui-icon-info{background-position:-16px -144px}.ui-icon-notice{background-position:-32px -144px}.ui-icon-help{background-position:-48px -144px}.ui-icon-check{background-position:-64px -144px}.ui-icon-bullet{background-position:-80px -144px}.ui-icon-radio-on{background-position:-96px -144px}.ui-icon-radio-off{background-position:-112px -144px}.ui-icon-pin-w{background-position:-128px -144px}.ui-icon-pin-s{background-position:-144px -144px}.ui-icon-play{background-position:0 -160px}.ui-icon-pause{background-position:-16px -160px}.ui-icon-seek-next{background-position:-32px -160px}.ui-icon-seek-prev{background-position:-48px -160px}.ui-icon-seek-end{background-position:-64px -160px}.ui-icon-seek-start{background-position:-80px -160px}.ui-icon-seek-first{background-position:-80px -160px}.ui-icon-stop{background-position:-96px -160px}.ui-icon-eject{background-position:-112px -160px}.ui-icon-volume-off{background-position:-128px -160px}.ui-icon-volume-on{background-position:-144px -160px}.ui-icon-power{background-position:0 -176px}.ui-icon-signal-diag{background-position:-16px -176px}.ui-icon-signal{background-position:-32px -176px}.ui-icon-battery-0{background-position:-48px -176px}.ui-icon-battery-1{background-position:-64px -176px}.ui-icon-battery-2{background-position:-80px -176px}.ui-icon-battery-3{background-position:-96px -176px}.ui-icon-circle-plus{background-position:0 -192px}.ui-icon-circle-minus{background-position:-16px -192px}.ui-icon-circle-close{background-position:-32px -192px}.ui-icon-circle-triangle-e{background-position:-48px -192px}.ui-icon-circle-triangle-s{background-position:-64px -192px}.ui-icon-circle-triangle-w{background-position:-80px -192px}.ui-icon-circle-triangle-n{background-position:-96px -192px}.ui-icon-circle-arrow-e{background-position:-112px -192px}.ui-icon-circle-arrow-s{background-position:-128px -192px}.ui-icon-circle-arrow-w{background-position:-144px -192px}.ui-icon-circle-arrow-n{background-position:-160px -192px}.ui-icon-circle-zoomin{background-position:-176px -192px}.ui-icon-circle-zoomout{background-position:-192px -192px}.ui-icon-circle-check{background-position:-208px -192px}.ui-icon-circlesmall-plus{background-position:0 -208px}.ui-icon-circlesmall-minus{background-position:-16px -208px}.ui-icon-circlesmall-close{background-position:-32px -208px}.ui-icon-squaresmall-plus{background-position:-48px -208px}.ui-icon-squaresmall-minus{background-position:-64px -208px}.ui-icon-squaresmall-close{background-position:-80px -208px}.ui-icon-grip-dotted-vertical{background-position:0 -224px}.ui-icon-grip-dotted-horizontal{background-position:-16px -224px}.ui-icon-grip-solid-vertical{background-position:-32px -224px}.ui-icon-grip-solid-horizontal{background-position:-48px -224px}.ui-icon-gripsmall-diagonal-se{background-position:-64px -224px}.ui-icon-grip-diagonal-se{background-position:-80px -224px}.ui-corner-all,.ui-corner-top,.ui-corner-left,.ui-corner-tl{border-top-left-radius:4px}.ui-corner-all,.ui-corner-top,.ui-corner-right,.ui-corner-tr{border-top-right-radius:4px}.ui-corner-all,.ui-corner-bottom,.ui-corner-left,.ui-corner-bl{border-bottom-left-radius:4px}.ui-corner-all,.ui-corner-bottom,.ui-corner-right,.ui-corner-br{border-bottom-right-radius:4px}.ui-widget-overlay{background:#aaa;opacity:.3;filter:Alpha(Opacity=30)}.ui-widget-shadow{-webkit-box-shadow:-8px -8px 8px #aaa;box-shadow:-8px -8px 8px #aaa}
\ No newline at end of file
diff --git a/static/css/jquery-ui.structure.min.css b/static/css/jquery-ui.structure.min.css
deleted file mode 100644
index 92f0049af2..0000000000
--- a/static/css/jquery-ui.structure.min.css
+++ /dev/null
@@ -1,5 +0,0 @@
-/*! jQuery UI - v1.11.4 - 2016-03-13
-* http://jqueryui.com
-* Copyright jQuery Foundation and other contributors; Licensed MIT */
-
-.ui-helper-hidden{display:none}.ui-helper-hidden-accessible{border:0;clip:rect(0 0 0 0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}.ui-helper-reset{margin:0;padding:0;border:0;outline:0;line-height:1.3;text-decoration:none;font-size:100%;list-style:none}.ui-helper-clearfix:before,.ui-helper-clearfix:after{content:"";display:table;border-collapse:collapse}.ui-helper-clearfix:after{clear:both}.ui-helper-clearfix{min-height:0}.ui-helper-zfix{width:100%;height:100%;top:0;left:0;position:absolute;opacity:0;filter:Alpha(Opacity=0)}.ui-front{z-index:100}.ui-state-disabled{cursor:default!important}.ui-icon{display:block;text-indent:-99999px;overflow:hidden;background-repeat:no-repeat}.ui-widget-overlay{position:fixed;top:0;left:0;width:100%;height:100%}.ui-draggable-handle{-ms-touch-action:none;touch-action:none}.ui-resizable{position:relative}.ui-resizable-handle{position:absolute;font-size:0.1px;display:block;-ms-touch-action:none;touch-action:none}.ui-resizable-disabled .ui-resizable-handle,.ui-resizable-autohide .ui-resizable-handle{display:none}.ui-resizable-n{cursor:n-resize;height:7px;width:100%;top:-5px;left:0}.ui-resizable-s{cursor:s-resize;height:7px;width:100%;bottom:-5px;left:0}.ui-resizable-e{cursor:e-resize;width:7px;right:-5px;top:0;height:100%}.ui-resizable-w{cursor:w-resize;width:7px;left:-5px;top:0;height:100%}.ui-resizable-se{cursor:se-resize;width:12px;height:12px;right:1px;bottom:1px}.ui-resizable-sw{cursor:sw-resize;width:9px;height:9px;left:-5px;bottom:-5px}.ui-resizable-nw{cursor:nw-resize;width:9px;height:9px;left:-5px;top:-5px}.ui-resizable-ne{cursor:ne-resize;width:9px;height:9px;right:-5px;top:-5px}.ui-selectable{-ms-touch-action:none;touch-action:none}.ui-selectable-helper{position:absolute;z-index:100;border:1px dotted black}.ui-sortable-handle{-ms-touch-action:none;touch-action:none}.ui-accordion .ui-accordion-header{display:block;cursor:pointer;position:relative;margin:2px 0 0 0;padding:.5em .5em .5em .7em;min-height:0;font-size:100%}.ui-accordion .ui-accordion-icons{padding-left:2.2em}.ui-accordion .ui-accordion-icons .ui-accordion-icons{padding-left:2.2em}.ui-accordion .ui-accordion-header .ui-accordion-header-icon{position:absolute;left:.5em;top:50%;margin-top:-8px}.ui-accordion .ui-accordion-content{padding:1em 2.2em;border-top:0;overflow:auto}.ui-autocomplete{position:absolute;top:0;left:0;cursor:default}.ui-button{display:inline-block;position:relative;padding:0;line-height:normal;margin-right:.1em;cursor:pointer;vertical-align:middle;text-align:center;overflow:visible}.ui-button,.ui-button:link,.ui-button:visited,.ui-button:hover,.ui-button:active{text-decoration:none}.ui-button-icon-only{width:2.2em}button.ui-button-icon-only{width:2.4em}.ui-button-icons-only{width:3.4em}button.ui-button-icons-only{width:3.7em}.ui-button .ui-button-text{display:block;line-height:normal}.ui-button-text-only .ui-button-text{padding:.4em 1em}.ui-button-icon-only .ui-button-text,.ui-button-icons-only .ui-button-text{padding:.4em;text-indent:-9999999px}.ui-button-text-icon-primary .ui-button-text,.ui-button-text-icons .ui-button-text{padding:.4em 1em .4em 2.1em}.ui-button-text-icon-secondary .ui-button-text,.ui-button-text-icons .ui-button-text{padding:.4em 2.1em .4em 1em}.ui-button-text-icons .ui-button-text{padding-left:2.1em;padding-right:2.1em}input.ui-button{padding:.4em 1em}.ui-button-icon-only .ui-icon,.ui-button-text-icon-primary .ui-icon,.ui-button-text-icon-secondary .ui-icon,.ui-button-text-icons .ui-icon,.ui-button-icons-only .ui-icon{position:absolute;top:50%;margin-top:-8px}.ui-button-icon-only .ui-icon{left:50%;margin-left:-8px}.ui-button-text-icon-primary .ui-button-icon-primary,.ui-button-text-icons .ui-button-icon-primary,.ui-button-icons-only .ui-button-icon-primary{left:.5em}.ui-button-text-icon-secondary .ui-button-icon-secondary,.ui-button-text-icons .ui-button-icon-secondary,.ui-button-icons-only .ui-button-icon-secondary{right:.5em}.ui-buttonset{margin-right:7px}.ui-buttonset .ui-button{margin-left:0;margin-right:-.3em}input.ui-button::-moz-focus-inner,button.ui-button::-moz-focus-inner{border:0;padding:0}.ui-datepicker{width:17em;padding:.2em .2em 0;display:none}.ui-datepicker .ui-datepicker-header{position:relative;padding:.2em 0}.ui-datepicker .ui-datepicker-prev,.ui-datepicker .ui-datepicker-next{position:absolute;top:2px;width:1.8em;height:1.8em}.ui-datepicker .ui-datepicker-prev-hover,.ui-datepicker .ui-datepicker-next-hover{top:1px}.ui-datepicker .ui-datepicker-prev{left:2px}.ui-datepicker .ui-datepicker-next{right:2px}.ui-datepicker .ui-datepicker-prev-hover{left:1px}.ui-datepicker .ui-datepicker-next-hover{right:1px}.ui-datepicker .ui-datepicker-prev span,.ui-datepicker .ui-datepicker-next span{display:block;position:absolute;left:50%;margin-left:-8px;top:50%;margin-top:-8px}.ui-datepicker .ui-datepicker-title{margin:0 2.3em;line-height:1.8em;text-align:center}.ui-datepicker .ui-datepicker-title select{font-size:1em;margin:1px 0}.ui-datepicker select.ui-datepicker-month,.ui-datepicker select.ui-datepicker-year{width:45%}.ui-datepicker table{width:100%;font-size:.9em;border-collapse:collapse;margin:0 0 .4em}.ui-datepicker th{padding:.7em .3em;text-align:center;font-weight:bold;border:0}.ui-datepicker td{border:0;padding:1px}.ui-datepicker td span,.ui-datepicker td a{display:block;padding:.2em;text-align:right;text-decoration:none}.ui-datepicker .ui-datepicker-buttonpane{background-image:none;margin:.7em 0 0 0;padding:0 .2em;border-left:0;border-right:0;border-bottom:0}.ui-datepicker .ui-datepicker-buttonpane button{float:right;margin:.5em .2em .4em;cursor:pointer;padding:.2em .6em .3em .6em;width:auto;overflow:visible}.ui-datepicker .ui-datepicker-buttonpane button.ui-datepicker-current{float:left}.ui-datepicker.ui-datepicker-multi{width:auto}.ui-datepicker-multi .ui-datepicker-group{float:left}.ui-datepicker-multi .ui-datepicker-group table{width:95%;margin:0 auto .4em}.ui-datepicker-multi-2 .ui-datepicker-group{width:50%}.ui-datepicker-multi-3 .ui-datepicker-group{width:33.3%}.ui-datepicker-multi-4 .ui-datepicker-group{width:25%}.ui-datepicker-multi .ui-datepicker-group-last .ui-datepicker-header,.ui-datepicker-multi .ui-datepicker-group-middle .ui-datepicker-header{border-left-width:0}.ui-datepicker-multi .ui-datepicker-buttonpane{clear:left}.ui-datepicker-row-break{clear:both;width:100%;font-size:0}.ui-datepicker-rtl{direction:rtl}.ui-datepicker-rtl .ui-datepicker-prev{right:2px;left:auto}.ui-datepicker-rtl .ui-datepicker-next{left:2px;right:auto}.ui-datepicker-rtl .ui-datepicker-prev:hover{right:1px;left:auto}.ui-datepicker-rtl .ui-datepicker-next:hover{left:1px;right:auto}.ui-datepicker-rtl .ui-datepicker-buttonpane{clear:right}.ui-datepicker-rtl .ui-datepicker-buttonpane button{float:left}.ui-datepicker-rtl .ui-datepicker-buttonpane button.ui-datepicker-current,.ui-datepicker-rtl .ui-datepicker-group{float:right}.ui-datepicker-rtl .ui-datepicker-group-last .ui-datepicker-header,.ui-datepicker-rtl .ui-datepicker-group-middle .ui-datepicker-header{border-right-width:0;border-left-width:1px}.ui-dialog{overflow:hidden;position:absolute;top:0;left:0;padding:.2em;outline:0}.ui-dialog .ui-dialog-titlebar{padding:.4em 1em;position:relative}.ui-dialog .ui-dialog-title{float:left;margin:.1em 0;white-space:nowrap;width:90%;overflow:hidden;text-overflow:ellipsis}.ui-dialog .ui-dialog-titlebar-close{position:absolute;right:.3em;top:50%;width:20px;margin:-10px 0 0 0;padding:1px;height:20px}.ui-dialog .ui-dialog-content{position:relative;border:0;padding:.5em 1em;background:none;overflow:auto}.ui-dialog .ui-dialog-buttonpane{text-align:left;border-width:1px 0 0 0;background-image:none;margin-top:.5em;padding:.3em 1em .5em .4em}.ui-dialog .ui-dialog-buttonpane .ui-dialog-buttonset{float:right}.ui-dialog .ui-dialog-buttonpane button{margin:.5em .4em .5em 0;cursor:pointer}.ui-dialog .ui-resizable-se{width:12px;height:12px;right:-5px;bottom:-5px;background-position:16px 16px}.ui-draggable .ui-dialog-titlebar{cursor:move}.ui-menu{list-style:none;padding:0;margin:0;display:block;outline:none}.ui-menu .ui-menu{position:absolute}.ui-menu .ui-menu-item{position:relative;margin:0;padding:3px 1em 3px .4em;cursor:pointer;min-height:0;list-style-image:url("data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7")}.ui-menu .ui-menu-divider{margin:5px 0;height:0;font-size:0;line-height:0;border-width:1px 0 0 0}.ui-menu .ui-state-focus,.ui-menu .ui-state-active{margin:-1px}.ui-menu-icons{position:relative}.ui-menu-icons .ui-menu-item{padding-left:2em}.ui-menu .ui-icon{position:absolute;top:0;bottom:0;left:.2em;margin:auto 0}.ui-menu .ui-menu-icon{left:auto;right:0}.ui-progressbar{height:2em;text-align:left;overflow:hidden}.ui-progressbar .ui-progressbar-value{margin:-1px;height:100%}.ui-progressbar .ui-progressbar-overlay{background:url("data:image/gif;base64,R0lGODlhKAAoAIABAAAAAP///yH/C05FVFNDQVBFMi4wAwEAAAAh+QQJAQABACwAAAAAKAAoAAACkYwNqXrdC52DS06a7MFZI+4FHBCKoDeWKXqymPqGqxvJrXZbMx7Ttc+w9XgU2FB3lOyQRWET2IFGiU9m1frDVpxZZc6bfHwv4c1YXP6k1Vdy292Fb6UkuvFtXpvWSzA+HycXJHUXiGYIiMg2R6W459gnWGfHNdjIqDWVqemH2ekpObkpOlppWUqZiqr6edqqWQAAIfkECQEAAQAsAAAAACgAKAAAApSMgZnGfaqcg1E2uuzDmmHUBR8Qil95hiPKqWn3aqtLsS18y7G1SzNeowWBENtQd+T1JktP05nzPTdJZlR6vUxNWWjV+vUWhWNkWFwxl9VpZRedYcflIOLafaa28XdsH/ynlcc1uPVDZxQIR0K25+cICCmoqCe5mGhZOfeYSUh5yJcJyrkZWWpaR8doJ2o4NYq62lAAACH5BAkBAAEALAAAAAAoACgAAAKVDI4Yy22ZnINRNqosw0Bv7i1gyHUkFj7oSaWlu3ovC8GxNso5fluz3qLVhBVeT/Lz7ZTHyxL5dDalQWPVOsQWtRnuwXaFTj9jVVh8pma9JjZ4zYSj5ZOyma7uuolffh+IR5aW97cHuBUXKGKXlKjn+DiHWMcYJah4N0lYCMlJOXipGRr5qdgoSTrqWSq6WFl2ypoaUAAAIfkECQEAAQAsAAAAACgAKAAAApaEb6HLgd/iO7FNWtcFWe+ufODGjRfoiJ2akShbueb0wtI50zm02pbvwfWEMWBQ1zKGlLIhskiEPm9R6vRXxV4ZzWT2yHOGpWMyorblKlNp8HmHEb/lCXjcW7bmtXP8Xt229OVWR1fod2eWqNfHuMjXCPkIGNileOiImVmCOEmoSfn3yXlJWmoHGhqp6ilYuWYpmTqKUgAAIfkECQEAAQAsAAAAACgAKAAAApiEH6kb58biQ3FNWtMFWW3eNVcojuFGfqnZqSebuS06w5V80/X02pKe8zFwP6EFWOT1lDFk8rGERh1TTNOocQ61Hm4Xm2VexUHpzjymViHrFbiELsefVrn6XKfnt2Q9G/+Xdie499XHd2g4h7ioOGhXGJboGAnXSBnoBwKYyfioubZJ2Hn0RuRZaflZOil56Zp6iioKSXpUAAAh+QQJAQABACwAAAAAKAAoAAACkoQRqRvnxuI7kU1a1UU5bd5tnSeOZXhmn5lWK3qNTWvRdQxP8qvaC+/yaYQzXO7BMvaUEmJRd3TsiMAgswmNYrSgZdYrTX6tSHGZO73ezuAw2uxuQ+BbeZfMxsexY35+/Qe4J1inV0g4x3WHuMhIl2jXOKT2Q+VU5fgoSUI52VfZyfkJGkha6jmY+aaYdirq+lQAACH5BAkBAAEALAAAAAAoACgAAAKWBIKpYe0L3YNKToqswUlvznigd4wiR4KhZrKt9Upqip61i9E3vMvxRdHlbEFiEXfk9YARYxOZZD6VQ2pUunBmtRXo1Lf8hMVVcNl8JafV38aM2/Fu5V16Bn63r6xt97j09+MXSFi4BniGFae3hzbH9+hYBzkpuUh5aZmHuanZOZgIuvbGiNeomCnaxxap2upaCZsq+1kAACH5BAkBAAEALAAAAAAoACgAAAKXjI8By5zf4kOxTVrXNVlv1X0d8IGZGKLnNpYtm8Lr9cqVeuOSvfOW79D9aDHizNhDJidFZhNydEahOaDH6nomtJjp1tutKoNWkvA6JqfRVLHU/QUfau9l2x7G54d1fl995xcIGAdXqMfBNadoYrhH+Mg2KBlpVpbluCiXmMnZ2Sh4GBqJ+ckIOqqJ6LmKSllZmsoq6wpQAAAh+QQJAQABACwAAAAAKAAoAAAClYx/oLvoxuJDkU1a1YUZbJ59nSd2ZXhWqbRa2/gF8Gu2DY3iqs7yrq+xBYEkYvFSM8aSSObE+ZgRl1BHFZNr7pRCavZ5BW2142hY3AN/zWtsmf12p9XxxFl2lpLn1rseztfXZjdIWIf2s5dItwjYKBgo9yg5pHgzJXTEeGlZuenpyPmpGQoKOWkYmSpaSnqKileI2FAAACH5BAkBAAEALAAAAAAoACgAAAKVjB+gu+jG4kORTVrVhRlsnn2dJ3ZleFaptFrb+CXmO9OozeL5VfP99HvAWhpiUdcwkpBH3825AwYdU8xTqlLGhtCosArKMpvfa1mMRae9VvWZfeB2XfPkeLmm18lUcBj+p5dnN8jXZ3YIGEhYuOUn45aoCDkp16hl5IjYJvjWKcnoGQpqyPlpOhr3aElaqrq56Bq7VAAAOw==");height:100%;filter:alpha(opacity=25);opacity:0.25}.ui-progressbar-indeterminate .ui-progressbar-value{background-image:none}.ui-selectmenu-menu{padding:0;margin:0;position:absolute;top:0;left:0;display:none}.ui-selectmenu-menu .ui-menu{overflow:auto;overflow-x:hidden;padding-bottom:1px}.ui-selectmenu-menu .ui-menu .ui-selectmenu-optgroup{font-size:1em;font-weight:bold;line-height:1.5;padding:2px 0.4em;margin:0.5em 0 0 0;height:auto;border:0}.ui-selectmenu-open{display:block}.ui-selectmenu-button{display:inline-block;overflow:hidden;position:relative;text-decoration:none;cursor:pointer}.ui-selectmenu-button span.ui-icon{right:0.5em;left:auto;margin-top:-8px;position:absolute;top:50%}.ui-selectmenu-button span.ui-selectmenu-text{text-align:left;padding:0.4em 2.1em 0.4em 1em;display:block;line-height:1.4;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}.ui-slider{position:relative;text-align:left}.ui-slider .ui-slider-handle{position:absolute;z-index:2;width:1.2em;height:1.2em;cursor:default;-ms-touch-action:none;touch-action:none}.ui-slider .ui-slider-range{position:absolute;z-index:1;font-size:.7em;display:block;border:0;background-position:0 0}.ui-slider.ui-state-disabled .ui-slider-handle,.ui-slider.ui-state-disabled .ui-slider-range{filter:inherit}.ui-slider-horizontal{height:.8em}.ui-slider-horizontal .ui-slider-handle{top:-.3em;margin-left:-.6em}.ui-slider-horizontal .ui-slider-range{top:0;height:100%}.ui-slider-horizontal .ui-slider-range-min{left:0}.ui-slider-horizontal .ui-slider-range-max{right:0}.ui-slider-vertical{width:.8em;height:100px}.ui-slider-vertical .ui-slider-handle{left:-.3em;margin-left:0;margin-bottom:-.6em}.ui-slider-vertical .ui-slider-range{left:0;width:100%}.ui-slider-vertical .ui-slider-range-min{bottom:0}.ui-slider-vertical .ui-slider-range-max{top:0}.ui-spinner{position:relative;display:inline-block;overflow:hidden;padding:0;vertical-align:middle}.ui-spinner-input{border:none;background:none;color:inherit;padding:0;margin:.2em 0;vertical-align:middle;margin-left:.4em;margin-right:22px}.ui-spinner-button{width:16px;height:50%;font-size:.5em;padding:0;margin:0;text-align:center;position:absolute;cursor:default;display:block;overflow:hidden;right:0}.ui-spinner a.ui-spinner-button{border-top:none;border-bottom:none;border-right:none}.ui-spinner .ui-icon{position:absolute;margin-top:-8px;top:50%;left:0}.ui-spinner-up{top:0}.ui-spinner-down{bottom:0}.ui-spinner .ui-icon-triangle-1-s{background-position:-65px -16px}.ui-tabs{position:relative;padding:.2em}.ui-tabs .ui-tabs-nav{margin:0;padding:.2em .2em 0}.ui-tabs .ui-tabs-nav li{list-style:none;float:left;position:relative;top:0;margin:1px .2em 0 0;border-bottom-width:0;padding:0;white-space:nowrap}.ui-tabs .ui-tabs-nav .ui-tabs-anchor{float:left;padding:.5em 1em;text-decoration:none}.ui-tabs .ui-tabs-nav li.ui-tabs-active{margin-bottom:-1px;padding-bottom:1px}.ui-tabs .ui-tabs-nav li.ui-tabs-active .ui-tabs-anchor,.ui-tabs .ui-tabs-nav li.ui-state-disabled .ui-tabs-anchor,.ui-tabs .ui-tabs-nav li.ui-tabs-loading .ui-tabs-anchor{cursor:text}.ui-tabs-collapsible .ui-tabs-nav li.ui-tabs-active .ui-tabs-anchor{cursor:pointer}.ui-tabs .ui-tabs-panel{display:block;border-width:0;padding:1em 1.4em;background:none}.ui-tooltip{padding:8px;position:absolute;z-index:9999;max-width:300px;-webkit-box-shadow:0 0 5px #aaa;box-shadow:0 0 5px #aaa}body .ui-tooltip{border-width:2px}
\ No newline at end of file
diff --git a/static/css/jquery-ui.theme.min.css b/static/css/jquery-ui.theme.min.css
deleted file mode 100644
index a7e0b94f99..0000000000
--- a/static/css/jquery-ui.theme.min.css
+++ /dev/null
@@ -1,5 +0,0 @@
-/*! jQuery UI - v1.11.4 - 2016-03-15
-* http://jqueryui.com
-* Copyright jQuery Foundation and other contributors; Licensed MIT */
-
-.ui-widget{font-family:Arial,Helvetica,sans-serif;font-size:1em}.ui-widget .ui-widget{font-size:1em}.ui-widget input,.ui-widget select,.ui-widget textarea,.ui-widget button{font-family:Arial,Helvetica,sans-serif;font-size:1em}.ui-widget-content{border:1px solid #ddd;background:#fff;color:#333}.ui-widget-content a{color:#333}.ui-widget-header{border:1px solid #ddd;background:#e9e9e9;color:#333;font-weight:bold}.ui-widget-header a{color:#333}.ui-state-default,.ui-widget-content .ui-state-default,.ui-widget-header .ui-state-default{border:1px solid #c5c5c5;background:#f6f6f6;font-weight:normal;color:#454545}.ui-state-default a,.ui-state-default a:link,.ui-state-default a:visited{color:#454545;text-decoration:none}.ui-state-hover,.ui-widget-content .ui-state-hover,.ui-widget-header .ui-state-hover,.ui-state-focus,.ui-widget-content .ui-state-focus,.ui-widget-header .ui-state-focus{border:1px solid #ccc;background:#ededed;font-weight:normal;color:#2b2b2b}.ui-state-hover a,.ui-state-hover a:hover,.ui-state-hover a:link,.ui-state-hover a:visited,.ui-state-focus a,.ui-state-focus a:hover,.ui-state-focus a:link,.ui-state-focus a:visited{color:#2b2b2b;text-decoration:none}.ui-state-active,.ui-widget-content .ui-state-active,.ui-widget-header .ui-state-active{border:1px solid #003eff;background:#007fff;font-weight:normal;color:#fff}.ui-state-active a,.ui-state-active a:link,.ui-state-active a:visited{color:#fff;text-decoration:none}.ui-state-highlight,.ui-widget-content .ui-state-highlight,.ui-widget-header .ui-state-highlight{border:1px solid #dad55e;background:#fffa90;color:#777620}.ui-state-highlight a,.ui-widget-content .ui-state-highlight a,.ui-widget-header .ui-state-highlight a{color:#777620}.ui-state-error,.ui-widget-content .ui-state-error,.ui-widget-header .ui-state-error{border:1px solid #f1a899;background:#fddfdf;color:#5f3f3f}.ui-state-error a,.ui-widget-content .ui-state-error a,.ui-widget-header .ui-state-error a{color:#5f3f3f}.ui-state-error-text,.ui-widget-content .ui-state-error-text,.ui-widget-header .ui-state-error-text{color:#5f3f3f}.ui-priority-primary,.ui-widget-content .ui-priority-primary,.ui-widget-header .ui-priority-primary{font-weight:bold}.ui-priority-secondary,.ui-widget-content .ui-priority-secondary,.ui-widget-header .ui-priority-secondary{opacity:.7;filter:Alpha(Opacity=70);font-weight:normal}.ui-state-disabled,.ui-widget-content .ui-state-disabled,.ui-widget-header .ui-state-disabled{opacity:.35;filter:Alpha(Opacity=35);background-image:none}.ui-state-disabled .ui-icon{filter:Alpha(Opacity=35)}.ui-icon{width:16px;height:16px}.ui-icon,.ui-widget-content .ui-icon{background-image:url("/images/jquery-ui/ui-icons_444444_256x240.png")}.ui-widget-header .ui-icon{background-image:url("/images/jquery-ui/ui-icons_444444_256x240.png")}.ui-state-default .ui-icon{background-image:url("/images/jquery-ui/ui-icons_777777_256x240.png")}.ui-state-hover .ui-icon,.ui-state-focus .ui-icon{background-image:url("/images/jquery-ui/ui-icons_555555_256x240.png")}.ui-state-active .ui-icon{background-image:url("/images/jquery-ui/ui-icons_ffffff_256x240.png")}.ui-state-highlight .ui-icon{background-image:url("/images/jquery-ui/ui-icons_777620_256x240.png")}.ui-state-error .ui-icon,.ui-state-error-text .ui-icon{background-image:url("/images/jquery-ui/ui-icons_cc0000_256x240.png")}.ui-icon-blank{background-position:16px 16px}.ui-icon-carat-1-n{background-position:0 0}.ui-icon-carat-1-ne{background-position:-16px 0}.ui-icon-carat-1-e{background-position:-32px 0}.ui-icon-carat-1-se{background-position:-48px 0}.ui-icon-carat-1-s{background-position:-64px 0}.ui-icon-carat-1-sw{background-position:-80px 0}.ui-icon-carat-1-w{background-position:-96px 0}.ui-icon-carat-1-nw{background-position:-112px 0}.ui-icon-carat-2-n-s{background-position:-128px 0}.ui-icon-carat-2-e-w{background-position:-144px 0}.ui-icon-triangle-1-n{background-position:0 -16px}.ui-icon-triangle-1-ne{background-position:-16px -16px}.ui-icon-triangle-1-e{background-position:-32px -16px}.ui-icon-triangle-1-se{background-position:-48px -16px}.ui-icon-triangle-1-s{background-position:-64px -16px}.ui-icon-triangle-1-sw{background-position:-80px -16px}.ui-icon-triangle-1-w{background-position:-96px -16px}.ui-icon-triangle-1-nw{background-position:-112px -16px}.ui-icon-triangle-2-n-s{background-position:-128px -16px}.ui-icon-triangle-2-e-w{background-position:-144px -16px}.ui-icon-arrow-1-n{background-position:0 -32px}.ui-icon-arrow-1-ne{background-position:-16px -32px}.ui-icon-arrow-1-e{background-position:-32px -32px}.ui-icon-arrow-1-se{background-position:-48px -32px}.ui-icon-arrow-1-s{background-position:-64px -32px}.ui-icon-arrow-1-sw{background-position:-80px -32px}.ui-icon-arrow-1-w{background-position:-96px -32px}.ui-icon-arrow-1-nw{background-position:-112px -32px}.ui-icon-arrow-2-n-s{background-position:-128px -32px}.ui-icon-arrow-2-ne-sw{background-position:-144px -32px}.ui-icon-arrow-2-e-w{background-position:-160px -32px}.ui-icon-arrow-2-se-nw{background-position:-176px -32px}.ui-icon-arrowstop-1-n{background-position:-192px -32px}.ui-icon-arrowstop-1-e{background-position:-208px -32px}.ui-icon-arrowstop-1-s{background-position:-224px -32px}.ui-icon-arrowstop-1-w{background-position:-240px -32px}.ui-icon-arrowthick-1-n{background-position:0 -48px}.ui-icon-arrowthick-1-ne{background-position:-16px -48px}.ui-icon-arrowthick-1-e{background-position:-32px -48px}.ui-icon-arrowthick-1-se{background-position:-48px -48px}.ui-icon-arrowthick-1-s{background-position:-64px -48px}.ui-icon-arrowthick-1-sw{background-position:-80px -48px}.ui-icon-arrowthick-1-w{background-position:-96px -48px}.ui-icon-arrowthick-1-nw{background-position:-112px -48px}.ui-icon-arrowthick-2-n-s{background-position:-128px -48px}.ui-icon-arrowthick-2-ne-sw{background-position:-144px -48px}.ui-icon-arrowthick-2-e-w{background-position:-160px -48px}.ui-icon-arrowthick-2-se-nw{background-position:-176px -48px}.ui-icon-arrowthickstop-1-n{background-position:-192px -48px}.ui-icon-arrowthickstop-1-e{background-position:-208px -48px}.ui-icon-arrowthickstop-1-s{background-position:-224px -48px}.ui-icon-arrowthickstop-1-w{background-position:-240px -48px}.ui-icon-arrowreturnthick-1-w{background-position:0 -64px}.ui-icon-arrowreturnthick-1-n{background-position:-16px -64px}.ui-icon-arrowreturnthick-1-e{background-position:-32px -64px}.ui-icon-arrowreturnthick-1-s{background-position:-48px -64px}.ui-icon-arrowreturn-1-w{background-position:-64px -64px}.ui-icon-arrowreturn-1-n{background-position:-80px -64px}.ui-icon-arrowreturn-1-e{background-position:-96px -64px}.ui-icon-arrowreturn-1-s{background-position:-112px -64px}.ui-icon-arrowrefresh-1-w{background-position:-128px -64px}.ui-icon-arrowrefresh-1-n{background-position:-144px -64px}.ui-icon-arrowrefresh-1-e{background-position:-160px -64px}.ui-icon-arrowrefresh-1-s{background-position:-176px -64px}.ui-icon-arrow-4{background-position:0 -80px}.ui-icon-arrow-4-diag{background-position:-16px -80px}.ui-icon-extlink{background-position:-32px -80px}.ui-icon-newwin{background-position:-48px -80px}.ui-icon-refresh{background-position:-64px -80px}.ui-icon-shuffle{background-position:-80px -80px}.ui-icon-transfer-e-w{background-position:-96px -80px}.ui-icon-transferthick-e-w{background-position:-112px -80px}.ui-icon-folder-collapsed{background-position:0 -96px}.ui-icon-folder-open{background-position:-16px -96px}.ui-icon-document{background-position:-32px -96px}.ui-icon-document-b{background-position:-48px -96px}.ui-icon-note{background-position:-64px -96px}.ui-icon-mail-closed{background-position:-80px -96px}.ui-icon-mail-open{background-position:-96px -96px}.ui-icon-suitcase{background-position:-112px -96px}.ui-icon-comment{background-position:-128px -96px}.ui-icon-person{background-position:-144px -96px}.ui-icon-print{background-position:-160px -96px}.ui-icon-trash{background-position:-176px -96px}.ui-icon-locked{background-position:-192px -96px}.ui-icon-unlocked{background-position:-208px -96px}.ui-icon-bookmark{background-position:-224px -96px}.ui-icon-tag{background-position:-240px -96px}.ui-icon-home{background-position:0 -112px}.ui-icon-flag{background-position:-16px -112px}.ui-icon-calendar{background-position:-32px -112px}.ui-icon-cart{background-position:-48px -112px}.ui-icon-pencil{background-position:-64px -112px}.ui-icon-clock{background-position:-80px -112px}.ui-icon-disk{background-position:-96px -112px}.ui-icon-calculator{background-position:-112px -112px}.ui-icon-zoomin{background-position:-128px -112px}.ui-icon-zoomout{background-position:-144px -112px}.ui-icon-search{background-position:-160px -112px}.ui-icon-wrench{background-position:-176px -112px}.ui-icon-gear{background-position:-192px -112px}.ui-icon-heart{background-position:-208px -112px}.ui-icon-star{background-position:-224px -112px}.ui-icon-link{background-position:-240px -112px}.ui-icon-cancel{background-position:0 -128px}.ui-icon-plus{background-position:-16px -128px}.ui-icon-plusthick{background-position:-32px -128px}.ui-icon-minus{background-position:-48px -128px}.ui-icon-minusthick{background-position:-64px -128px}.ui-icon-close{background-position:-80px -128px}.ui-icon-closethick{background-position:-96px -128px}.ui-icon-key{background-position:-112px -128px}.ui-icon-lightbulb{background-position:-128px -128px}.ui-icon-scissors{background-position:-144px -128px}.ui-icon-clipboard{background-position:-160px -128px}.ui-icon-copy{background-position:-176px -128px}.ui-icon-contact{background-position:-192px -128px}.ui-icon-image{background-position:-208px -128px}.ui-icon-video{background-position:-224px -128px}.ui-icon-script{background-position:-240px -128px}.ui-icon-alert{background-position:0 -144px}.ui-icon-info{background-position:-16px -144px}.ui-icon-notice{background-position:-32px -144px}.ui-icon-help{background-position:-48px -144px}.ui-icon-check{background-position:-64px -144px}.ui-icon-bullet{background-position:-80px -144px}.ui-icon-radio-on{background-position:-96px -144px}.ui-icon-radio-off{background-position:-112px -144px}.ui-icon-pin-w{background-position:-128px -144px}.ui-icon-pin-s{background-position:-144px -144px}.ui-icon-play{background-position:0 -160px}.ui-icon-pause{background-position:-16px -160px}.ui-icon-seek-next{background-position:-32px -160px}.ui-icon-seek-prev{background-position:-48px -160px}.ui-icon-seek-end{background-position:-64px -160px}.ui-icon-seek-start{background-position:-80px -160px}.ui-icon-seek-first{background-position:-80px -160px}.ui-icon-stop{background-position:-96px -160px}.ui-icon-eject{background-position:-112px -160px}.ui-icon-volume-off{background-position:-128px -160px}.ui-icon-volume-on{background-position:-144px -160px}.ui-icon-power{background-position:0 -176px}.ui-icon-signal-diag{background-position:-16px -176px}.ui-icon-signal{background-position:-32px -176px}.ui-icon-battery-0{background-position:-48px -176px}.ui-icon-battery-1{background-position:-64px -176px}.ui-icon-battery-2{background-position:-80px -176px}.ui-icon-battery-3{background-position:-96px -176px}.ui-icon-circle-plus{background-position:0 -192px}.ui-icon-circle-minus{background-position:-16px -192px}.ui-icon-circle-close{background-position:-32px -192px}.ui-icon-circle-triangle-e{background-position:-48px -192px}.ui-icon-circle-triangle-s{background-position:-64px -192px}.ui-icon-circle-triangle-w{background-position:-80px -192px}.ui-icon-circle-triangle-n{background-position:-96px -192px}.ui-icon-circle-arrow-e{background-position:-112px -192px}.ui-icon-circle-arrow-s{background-position:-128px -192px}.ui-icon-circle-arrow-w{background-position:-144px -192px}.ui-icon-circle-arrow-n{background-position:-160px -192px}.ui-icon-circle-zoomin{background-position:-176px -192px}.ui-icon-circle-zoomout{background-position:-192px -192px}.ui-icon-circle-check{background-position:-208px -192px}.ui-icon-circlesmall-plus{background-position:0 -208px}.ui-icon-circlesmall-minus{background-position:-16px -208px}.ui-icon-circlesmall-close{background-position:-32px -208px}.ui-icon-squaresmall-plus{background-position:-48px -208px}.ui-icon-squaresmall-minus{background-position:-64px -208px}.ui-icon-squaresmall-close{background-position:-80px -208px}.ui-icon-grip-dotted-vertical{background-position:0 -224px}.ui-icon-grip-dotted-horizontal{background-position:-16px -224px}.ui-icon-grip-solid-vertical{background-position:-32px -224px}.ui-icon-grip-solid-horizontal{background-position:-48px -224px}.ui-icon-gripsmall-diagonal-se{background-position:-64px -224px}.ui-icon-grip-diagonal-se{background-position:-80px -224px}.ui-corner-all,.ui-corner-top,.ui-corner-left,.ui-corner-tl{border-top-left-radius:3px}.ui-corner-all,.ui-corner-top,.ui-corner-right,.ui-corner-tr{border-top-right-radius:3px}.ui-corner-all,.ui-corner-bottom,.ui-corner-left,.ui-corner-bl{border-bottom-left-radius:3px}.ui-corner-all,.ui-corner-bottom,.ui-corner-right,.ui-corner-br{border-bottom-right-radius:3px}.ui-widget-overlay{background:#aaa;opacity:.3;filter:Alpha(Opacity=30)}.ui-widget-shadow{margin:0 0 0 0;padding:5px;background:#666;opacity:.3;filter:Alpha(Opacity=30);border-radius:8px}
\ No newline at end of file
diff --git a/static/css/new-case-studies.css b/static/css/new-case-studies.css
new file mode 100644
index 0000000000..fbc6edb143
--- /dev/null
+++ b/static/css/new-case-studies.css
@@ -0,0 +1,182 @@
+h1 {
+  font-weight: bold;
+  letter-spacing: 0.025em;
+  font-size: 42px;
+  padding-bottom: 2%;
+  margin-top: 10%;
+  margin-bottom: 0;
+}
+
+h2 {
+  font-size: 24px;
+  font-weight: 300;
+  color: #3366ff;
+  margin-top: 3rem;
+  margin-bottom: 1rem;
+}
+
+h1[id]:before, 
+h2[id]:before, 
+h4[id]:before {
+  display: none;
+}
+
+.content p, .content li {
+  font-size: 14px;
+  font-weight: 300;
+  color: #606060;
+}
+
+.quote + h2, 
+.quote + .lead {
+  margin-top: 0;
+}
+
+.content {
+  width: 76.2%;
+  margin: 0 auto;
+  margin-top: 2%;
+  margin-bottom: 4%;
+}
+
+.heading {
+  margin-right: 0.5em;
+}
+
+.heading-logo {
+  max-height: 1em;
+}
+
+.subheading {
+  display: block;
+  font-size: 26px;
+  font-weight: 300;
+  line-height: 1.4em;
+  margin-top: 0.75em;
+  padding-bottom: 0.5em;
+  letter-spacing: 0.02em;
+}
+
+.banner {
+  width: 100%;
+  position: relative;
+  font-weight: 300;
+  color: #fff;
+  padding-top: 5%;
+  padding-left: 11.9%;
+  padding-right: 11.9%;
+  font-size: 1.2em;
+  background-size: 100% auto;
+  background-color: #666;
+  background-repeat: no-repeat;
+}
+
+.banner * {
+  position: relative;
+}
+
+.overlay:before{
+  position: absolute;
+  content: "";
+  top: 0;
+  left: 0;
+  width: 100%;
+  height: 100%;
+  display: block;
+  z-index: 0;
+  background: linear-gradient(to right, #2635e4, #c72f6c);
+  opacity: 0.6;
+}
+
+.details {
+  font-weight: 300;
+  color: #3366ff;
+  letter-spacing: 0.03em;
+  padding-bottom: 2% !important;
+  padding-top: 2%;
+  margin-left: 0;
+  padding-left: 11.9%;
+  border-bottom: 1px solid #ddd;
+}
+
+.details .item {
+  margin-right: 2em;
+  white-space: nowrap;
+}
+
+.quote {
+  width: 100vw;
+  position: relative;
+  left: 50%;
+  right: 50%;
+  margin-top: 3rem;
+  margin-bottom: 3rem;
+  margin-left: -50vw;
+  margin-right: -50vw;
+}
+
+.content .quote-text {
+  color: #fff;
+  padding-bottom: 5%;
+  width: 74%;
+  font-size: 1.3em;
+  line-height: 1.4em;
+  letter-spacing: 0.03em;
+  text-align: center;
+  margin: 0 auto;
+}
+
+.content .quote-text p {
+  color: #fff;
+  font-size: 100%;
+  line-height: 1.4em;
+  margin-bottom: 0;
+}
+
+.quote-author {
+  display: block;
+  margin-top: 3em;
+  font-size: 14px;
+  text-transform: uppercase;
+  letter-spacing: 2px;
+  line-height: 1.2em;
+}
+
+.lead {
+  font-size: 1.35rem;
+  font-weight: 300;
+  color: #3366ff;
+  margin-top: 3rem;
+  margin-bottom: 3rem;
+  letter-spacing: 0.03em;
+}
+
+.youtube-quote-sm {
+  display: inline-block;
+  width: 380px;
+  height: 215px;
+}
+
+.youtube-quote-sm iframe {
+  width: 100%;
+  height: 100%;
+  border: 0;
+}
+
+@media screen and (max-width: 910px) {
+  h1 {
+    font-size: 32px;
+  }
+
+  .details {
+    font-size: 1em !important;
+  }
+
+  .quote-text {
+    font-size: 1em;
+  }
+
+  .quote-author {
+    font-size: 12px;
+  }
+}
diff --git a/static/css/newcommunity.css b/static/css/newcommunity.css
index 39ea374747..993cd89e1a 100644
--- a/static/css/newcommunity.css
+++ b/static/css/newcommunity.css
@@ -81,7 +81,6 @@ p {
 
 body {
   line-height: 1.5em;
-  /* font-family:'roboto'; */
   margin-top: 1%;
   font-weight: 300;
   /* letter-spacing:0.03em; */
@@ -106,7 +105,6 @@ body {
   text-align: left;
   line-height: 1.6em;
   margin-bottom: 2%;
-  font-family: 'roboto';
   margin-top: 3%;
   font-weight: 300;
   letter-spacing: 0.04em;
@@ -117,7 +115,6 @@ body {
   text-align: center;
   padding-top: 2%;
   padding-bottom: 2%;
-  font-family: 'roboto';
   word-spacing: 3%;
   text-decoration: none;
   text-transform: uppercase;
@@ -179,7 +176,6 @@ a {
   padding-top: 1%;
   padding-bottom: 8%;
   text-align: center;
-  font-family: 'roboto';
   float: left;
   margin: 1%;
 }
@@ -220,7 +216,6 @@ a {
   width: 37%;
   margin-left: 5%;
   text-align: left;
-  font-family: 'roboto';
 }
 
 .meetuptext {
@@ -246,14 +241,13 @@ a {
 }
 
 .fullbutton {
-  display: block;
+  display: inline-block;
   margin: auto;
   margin-top: 2rem;
-  width: 156px;
   background-color: #0662EE;
   color: white;
   font-size: 18px;
-  padding: 2%;
+  padding: 2% 2.5%;
   letter-spacing: 0.07em;
   font-weight: bold;
 
@@ -262,7 +256,6 @@ a {
 
 .newcommunitywrapper h1 {
   font-size: 42px;
-  font-family: 'roboto';
   font-weight: 300;
   margin-top: 4%;
   line-height: 1.1em;
@@ -300,7 +293,6 @@ a {
   margin-top: 3%;
   text-align: center;
   padding-top: 4%;
-  font-family: 'roboto';
 
 }
 
@@ -309,7 +301,6 @@ a {
   padding: 3%;
   color: #0662EE;
   text-transform: uppercase;
-  font-family: 'roboto';
   font-weight: bold;
   letter-spacing: 0.05em;
   line-height: 1.3em;
@@ -323,7 +314,6 @@ a {
   margin-top;
   5%;
   margin-bottom: 3%;
-  font-family: 'roboto';
   float: left;
 }
 
@@ -345,7 +335,6 @@ a {
   height: 100%;
   vertical-align: middle;
   text-transform: uppercase;
-  font-family: 'roboto';
   font-weight: bold;
   line-height: 1.3em;
   letter-spacing: 0.05em;
@@ -395,7 +384,6 @@ a {
   padding-top: 3%;
   padding-bottom: 3%;
   text-align: center;
-  font-family: 'roboto';
   font-weight: 300;
 }
 
@@ -405,14 +393,12 @@ a {
   margin-bottom: 3%;
   margin-left: 15%;
   text-align: center;
-  font-family: 'roboto';
   font-weight: 300;
 }
 
 
 h2 {
   overflow: hidden;
-  font-family: 'roboto';
   font-weight: 200;
   margin-top: 5%;
   text-align: center;
@@ -448,14 +434,12 @@ h2:after {
   padding-bottom: 3%;
   margin-left: 10%;
   text-align: center;
-  font-family: 'roboto';
 
 }
 
 .newscol {
   float: left;
   width: 30%;
-  font-family: 'roboto';
   font-weight: 300;
 }
 
@@ -535,11 +519,9 @@ h2:after {
     border: 1px solid grey;
     padding: 1%;
     font-size: 1.4em;
-    ;
     color: #0662EE;
     vertical-align: middle;
     text-transform: uppercase;
-    font-family: 'roboto';
     font-weight: bold;
     min-height: 375px;
     letter-spacing: 0.01em;
@@ -562,7 +544,6 @@ h2:after {
     color: #0662EE;
     vertical-align: middle;
     text-transform: uppercase;
-    font-family: 'roboto';
     font-weight: bold;
     min-height: 280px;
     letter-spacing: 0.01em;
@@ -584,11 +565,9 @@ h2:after {
     border: 1px solid grey;
     padding: 1%;
     font-size: 1.1em;
-    ;
     color: #0662EE;
     vertical-align: middle;
     text-transform: uppercase;
-    font-family: 'roboto';
     font-weight: bold;
     height: 100% !important;
     letter-spacing: 0.01em;
@@ -621,7 +600,6 @@ h2:after {
     text-align: center;
     line-height: 1.6em;
     margin-bottom: 1%;
-    font-family: 'roboto';
     margin-top: 7%;
     margin-bottom: 7%;
     letter-spacing: 0.04em;
@@ -659,7 +637,6 @@ h2:after {
   body {
     overflow-x: hidden;
     line-height: 1.5em;
-    /* font-family: 'roboto'; */
     margin-top: 1%;
     letter-spacing: 0.03em;
     /* font-size: 13px; */
@@ -694,7 +671,6 @@ h2:after {
     padding-top: 1%;
     padding-bottom: 1%;
     color: white;
-    font-family: 'roboto';
     text-align: center;
     float: left;
     margin: 1%;
@@ -717,7 +693,6 @@ h2:after {
     width: 90%;
     margin-left: 5%;
     text-align: center;
-    font-family: 'roboto';
   }
 
   .meetuptext {
@@ -769,7 +744,6 @@ h2:after {
     text-align: center;
     padding-top: 4%;
     padding-bottom: 2%;
-    font-family: 'roboto';
 
   }
 
@@ -780,7 +754,6 @@ h2:after {
     line-height: 1.3em;
     color: #0662EE;
     text-transform: uppercase;
-    font-family: 'roboto';
     font-weight: bold;
     padding-bottom: 8%;
     font-size: 1em;
@@ -792,7 +765,6 @@ h2:after {
     margin-top;
     8%;
     margin-bottom: 8%;
-    font-family: 'roboto';
     float: left;
   }
 
@@ -835,7 +807,6 @@ h2:after {
     padding-top: 3%;
     padding-bottom: 3%;
     text-align: center;
-    font-family: 'roboto';
     margin-bottom: 12%;
   }
 
@@ -845,7 +816,6 @@ h2:after {
     margin-left: 10%;
     margin-bottom: 2%;
     text-align: center;
-    font-family: 'roboto';
   }
 
   .fullbutton {
diff --git a/static/css/style_amadeus.css b/static/css/style_amadeus.css
index 709ecb078d..54d8129e6c 100644
--- a/static/css/style_amadeus.css
+++ b/static/css/style_amadeus.css
@@ -1,17 +1,15 @@
 #caseStudyTitle {
     margin-top: 1em !important;
-    font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
 .header_logo {
 
   width:23%;
-  margin-bottom:-0.6%;
+  margin-bottom: 1%;
   margin-left:10px;
 }
 
@@ -26,7 +24,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -43,7 +40,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -56,7 +52,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -72,7 +67,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -87,7 +81,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -100,7 +93,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -114,7 +106,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -123,7 +114,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -132,7 +122,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -141,7 +130,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -151,7 +139,6 @@ h1 {
 
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -159,7 +146,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -167,7 +153,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -187,7 +172,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -197,7 +181,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -212,7 +195,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -225,12 +207,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -240,7 +220,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -262,7 +241,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -281,7 +259,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -293,7 +270,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -303,7 +279,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -315,7 +290,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -330,7 +304,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -344,7 +317,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -358,7 +330,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -373,7 +344,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -386,7 +356,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -397,7 +366,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -408,7 +376,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
diff --git a/static/css/style_ancestry.css b/static/css/style_ancestry.css
index 9f93d22bb9..9ac57f7776 100644
--- a/static/css/style_ancestry.css
+++ b/static/css/style_ancestry.css
@@ -1,10 +1,8 @@
 #caseStudyTitle {
     margin-top: 1em !important;
-    font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -19,7 +17,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -36,7 +33,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -49,7 +45,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -64,7 +59,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -79,7 +73,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -92,7 +85,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -106,7 +98,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -115,7 +106,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -124,7 +114,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -133,7 +122,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -143,7 +131,6 @@ h1 {
 
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -151,7 +138,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -159,7 +145,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -179,7 +164,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -189,7 +173,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -204,7 +187,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:6%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -217,12 +199,10 @@ hr {
   margin-left:6.5%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -233,7 +213,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -249,7 +228,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -269,7 +247,6 @@ h4 {
     padding-left:5%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -282,7 +259,6 @@ h4 {
     padding-left:5%;
     padding-top:5%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -292,7 +268,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -304,7 +279,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -320,7 +294,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -334,7 +307,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -348,7 +320,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -363,7 +334,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -374,7 +344,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -385,7 +354,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -396,7 +364,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
diff --git a/static/css/style_blablacar.css b/static/css/style_blablacar.css
index ffa005ee71..0942a356af 100644
--- a/static/css/style_blablacar.css
+++ b/static/css/style_blablacar.css
@@ -1,16 +1,14 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
 .header_logo {
   width:24%;
-  margin-bottom:-0.5%;
+  margin-bottom:1%;
   margin-left:10px;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -53,7 +49,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding: 1%;
@@ -68,7 +63,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -83,7 +77,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -96,7 +89,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -110,7 +102,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -121,7 +112,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -130,7 +120,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -139,7 +128,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -148,7 +136,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -156,7 +143,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -164,7 +150,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -183,7 +168,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -192,7 +176,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -206,7 +189,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -219,12 +201,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -234,7 +214,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -256,7 +235,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -275,7 +253,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -287,7 +264,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -297,7 +273,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -309,7 +284,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -324,7 +298,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -338,7 +311,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -352,7 +324,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -367,7 +338,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -380,7 +350,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -391,7 +360,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -402,7 +370,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
diff --git a/static/css/style_blackrock.css b/static/css/style_blackrock.css
index 61d997ba41..25b1b9f482 100644
--- a/static/css/style_blackrock.css
+++ b/static/css/style_blackrock.css
@@ -1,16 +1,14 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
 .header_logo {
   width:15%;
-  margin-bottom:0%;
+  margin-bottom: 0%;
   margin-left:10px;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -53,7 +49,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -68,7 +63,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -83,7 +77,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -96,7 +89,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -110,7 +102,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -119,7 +110,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -128,7 +118,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -137,7 +126,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -146,7 +134,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -154,7 +141,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -162,7 +148,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -181,7 +166,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -190,7 +174,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -204,7 +187,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -217,12 +199,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -232,7 +212,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -254,7 +233,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -273,7 +251,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -285,7 +262,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -295,7 +271,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -307,7 +282,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -322,7 +296,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -336,7 +309,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -350,7 +322,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -365,7 +336,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -378,7 +348,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -389,7 +358,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -400,7 +368,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
diff --git a/static/css/style_box.css b/static/css/style_box.css
index 9ca316ed1e..f39c02394c 100644
--- a/static/css/style_box.css
+++ b/static/css/style_box.css
@@ -1,6 +1,5 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 body {
@@ -8,7 +7,6 @@ body {
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -22,7 +20,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -37,7 +34,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -50,7 +46,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -64,7 +59,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -77,7 +71,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -90,7 +83,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -104,7 +96,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -113,7 +104,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:55%;
@@ -122,7 +112,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:55%;
@@ -131,7 +120,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -140,7 +128,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -148,7 +135,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -156,7 +142,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -175,7 +160,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -184,7 +168,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -198,7 +181,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:6%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -211,12 +193,10 @@ hr {
   margin-left:6%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -226,7 +206,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -242,7 +221,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -262,7 +240,6 @@ h4 {
     padding-left:5%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -275,7 +252,6 @@ h4 {
     padding-left:5%;
     padding-top:5%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -285,7 +261,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -297,7 +272,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -313,7 +287,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -327,7 +300,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -341,7 +313,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -357,7 +328,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -368,7 +338,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -377,7 +346,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -386,7 +354,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
diff --git a/static/css/style_buffer.css b/static/css/style_buffer.css
index 299a1aea21..48d7373cc9 100644
--- a/static/css/style_buffer.css
+++ b/static/css/style_buffer.css
@@ -3,7 +3,6 @@
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -22,7 +21,6 @@ background-color:#ffffff !important;
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -38,7 +36,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -51,7 +48,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -65,7 +61,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -80,7 +75,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -93,7 +87,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -107,7 +100,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -116,7 +108,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -125,7 +116,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:55%;
@@ -134,7 +124,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -143,7 +132,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -151,7 +139,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -159,7 +146,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -178,7 +164,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -187,7 +172,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -201,7 +185,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:6%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -214,12 +197,10 @@ hr {
   margin-left:6%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -229,7 +210,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -245,7 +225,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -265,7 +244,6 @@ h4 {
     padding-left:5%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -278,7 +256,6 @@ h4 {
     padding-left:5%;
     padding-top:5%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -288,7 +265,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -300,7 +276,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -316,7 +291,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -332,7 +306,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -346,7 +319,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -362,7 +334,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -373,7 +344,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -385,7 +355,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -394,7 +363,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
diff --git a/static/css/style_case_studies.css b/static/css/style_case_studies.css
index ce4d372f9f..a7beefe523 100644
--- a/static/css/style_case_studies.css
+++ b/static/css/style_case_studies.css
@@ -1,10 +1,8 @@
 #caseStudyTitle {
     margin-top: 1em !important;
-    font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -51,7 +47,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -66,7 +61,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -80,7 +74,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -92,7 +85,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -107,7 +99,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -116,7 +107,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -125,7 +115,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -134,7 +123,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -143,7 +131,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -151,7 +138,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -159,7 +145,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -178,7 +163,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -187,7 +171,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -201,7 +184,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -214,12 +196,10 @@ hr {
   margin-left:8.5%;
   margin-top:3%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -234,7 +214,6 @@ h4 {
 @media screen and (max-width: 910px) {
 
   h1 {
-    font-family: "Roboto", sans-serif;
     font-weight: bold;
     line-height: 36px;
     letter-spacing: 0.03em;
@@ -256,7 +235,6 @@ h4 {
   }
 
   .details {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     font-size: 16px;
     color: #3366ff;
@@ -273,7 +251,6 @@ h4 {
 
   .col1 {
     width: 95%;
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #606060;
     line-height: 20px;
@@ -285,7 +262,6 @@ h4 {
     width: 95%;
     padding-top: 2%;
     padding-bottom: 5%;
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     line-height: 20px;
     color: #606060;
@@ -294,7 +270,6 @@ h4 {
   }
 
   .banner1 {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     padding-top: 15%;
@@ -305,7 +280,6 @@ h4 {
   }
 
   .banner2 {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     padding-top: 4%;
@@ -319,7 +293,6 @@ h4 {
   }
 
   .banner3 {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     padding-top: 5%;
@@ -331,7 +304,6 @@ h4 {
   }
 
   .banner4 {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     padding-top: 4%;
@@ -343,7 +315,6 @@ h4 {
   }
 
   .banner5 {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     padding-top: 4%;
@@ -357,7 +328,6 @@ h4 {
   }
 
   .banner2text {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     width: 90%;
@@ -369,7 +339,6 @@ h4 {
   }
 
   .banner3text {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     width: 90%;
@@ -380,7 +349,6 @@ h4 {
   }
 
   .banner4text {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     width: 90%;
@@ -391,7 +359,6 @@ h4 {
   }
 
   .banner5text {
-    font-family: "Roboto", sans-serif;
     font-weight: 300;
     color: #ffffff;
     width: 90%;
diff --git a/static/css/style_crowdfire.css b/static/css/style_crowdfire.css
index 3e153e1006..568f8934f1 100644
--- a/static/css/style_crowdfire.css
+++ b/static/css/style_crowdfire.css
@@ -1,16 +1,14 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
 .header_logo {
   width:24%;
-  margin-bottom:-1%;
+  margin-bottom: 1%;
   margin-left:10px;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -53,7 +49,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -68,7 +63,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -83,7 +77,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -96,7 +89,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -110,7 +102,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -119,7 +110,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -128,7 +118,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -137,7 +126,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -146,7 +134,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -154,7 +141,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -162,7 +148,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -181,7 +166,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -190,7 +174,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -204,7 +187,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -217,12 +199,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -232,7 +212,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -254,7 +233,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -273,7 +251,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -285,7 +262,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -295,7 +271,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -307,7 +282,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -322,7 +296,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -336,7 +309,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -350,7 +322,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -365,7 +336,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -378,7 +348,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -389,7 +358,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -401,7 +369,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
diff --git a/static/css/style_golfnow.css b/static/css/style_golfnow.css
index abd875080d..12ee20b393 100644
--- a/static/css/style_golfnow.css
+++ b/static/css/style_golfnow.css
@@ -3,7 +3,6 @@
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -22,7 +21,6 @@ footer {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -37,7 +35,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -50,7 +47,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -64,7 +60,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -79,7 +74,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -92,7 +86,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -106,7 +99,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -115,7 +107,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -124,7 +115,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:55%;
@@ -133,7 +123,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -142,7 +131,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -150,7 +138,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -158,7 +145,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -177,7 +163,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -186,7 +171,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -200,7 +184,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:6%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -213,12 +196,10 @@ hr {
   margin-left:6%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -228,7 +209,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -244,7 +224,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -264,7 +243,6 @@ h4 {
     padding-left:5%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -277,7 +255,6 @@ h4 {
     padding-left:5%;
     padding-top:5%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -287,7 +264,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -299,7 +275,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -315,7 +290,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -331,7 +305,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -345,7 +318,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -361,9 +333,7 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
-    color:#ffffff;
     width:80%;
     padding-left:10%;
     float:left;
@@ -372,7 +342,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -384,7 +353,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -393,9 +361,7 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
-    color:#ffffff;
     width:80%;
     padding-left:10%;
     float:left;
diff --git a/static/css/style_haufegroup.css b/static/css/style_haufegroup.css
index b8cee6ca6e..fec90302f8 100644
--- a/static/css/style_haufegroup.css
+++ b/static/css/style_haufegroup.css
@@ -1,16 +1,14 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
 .header_logo {
   width:32%;
-  margin-bottom:-1%;
+  margin-bottom: -0.3%;
   margin-left:10px;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -53,7 +49,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -68,7 +63,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -83,7 +77,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -96,7 +89,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -110,7 +102,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -119,7 +110,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -128,7 +118,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -137,7 +126,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -146,7 +134,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -154,7 +141,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -162,7 +148,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -181,7 +166,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -190,7 +174,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -204,7 +187,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -217,12 +199,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -232,7 +212,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -254,7 +233,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -273,7 +251,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -285,7 +262,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -295,7 +271,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -307,7 +282,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -322,7 +296,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -336,7 +309,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -350,7 +322,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -365,7 +336,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -378,7 +348,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -389,7 +358,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -400,7 +368,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
diff --git a/static/css/style_huawei.css b/static/css/style_huawei.css
index a1d449e621..a0a7ffcf32 100644
--- a/static/css/style_huawei.css
+++ b/static/css/style_huawei.css
@@ -1,16 +1,14 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
 .header_logo {
   width:10%;
-  margin-bottom:-0.6%;
+  margin-top: -1%;
   margin-left:10px;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -53,7 +49,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -68,7 +63,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -83,7 +77,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -96,7 +89,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -110,7 +102,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -119,7 +110,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -128,7 +118,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -137,7 +126,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -146,7 +134,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -154,7 +141,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -162,7 +148,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -181,7 +166,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -190,7 +174,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -204,7 +187,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -217,12 +199,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -232,7 +212,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -254,7 +233,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -273,7 +251,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -285,7 +262,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -295,7 +271,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -307,7 +282,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -322,7 +296,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -336,7 +309,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -350,7 +322,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -365,7 +336,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -378,7 +348,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -389,7 +358,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -400,7 +368,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
diff --git a/static/css/style_peardeck.css b/static/css/style_peardeck.css
index 0ec3a55bef..c74863776d 100644
--- a/static/css/style_peardeck.css
+++ b/static/css/style_peardeck.css
@@ -3,7 +3,6 @@
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -22,7 +21,6 @@ footer {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -37,7 +35,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -50,7 +47,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -64,7 +60,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -79,7 +74,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -92,7 +86,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -106,7 +99,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -115,7 +107,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -124,7 +115,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:55%;
@@ -133,7 +123,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -142,7 +131,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -150,7 +138,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -158,7 +145,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -177,7 +163,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -186,7 +171,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -200,7 +184,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:6%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -213,12 +196,10 @@ hr {
   margin-left:6%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -228,7 +209,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -244,7 +224,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -264,7 +243,6 @@ h4 {
     padding-left:5%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -277,7 +255,6 @@ h4 {
     padding-left:5%;
     padding-top:5%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -287,7 +264,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -299,7 +275,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -315,7 +290,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -331,7 +305,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -345,7 +318,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -361,7 +333,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -372,7 +343,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -384,7 +354,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -393,7 +362,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
diff --git a/static/css/style_wink.css b/static/css/style_wink.css
index 9dce4c391d..a1784d313c 100644
--- a/static/css/style_wink.css
+++ b/static/css/style_wink.css
@@ -1,10 +1,8 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -18,7 +16,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -33,7 +30,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -46,7 +42,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -60,7 +55,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -75,7 +69,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -88,7 +81,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -102,7 +94,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:62%;
@@ -111,7 +102,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -120,7 +110,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:60%;
@@ -129,7 +118,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -138,7 +126,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -146,7 +133,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -154,7 +140,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -173,7 +158,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -182,7 +166,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -196,7 +179,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:6%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -209,12 +191,10 @@ hr {
   margin-left:6.2%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -224,7 +204,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -240,7 +219,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -260,7 +238,6 @@ h4 {
     padding-left:5%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -273,7 +250,6 @@ h4 {
     padding-left:5%;
     padding-top:5%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -283,7 +259,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -295,7 +270,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -311,7 +285,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -327,7 +300,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -341,7 +313,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -357,7 +328,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -368,7 +338,6 @@ h4 {
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -380,7 +349,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
@@ -389,7 +357,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:80%;
diff --git a/static/css/style_zalando.css b/static/css/style_zalando.css
index a7e9cd4397..f356f28fc5 100644
--- a/static/css/style_zalando.css
+++ b/static/css/style_zalando.css
@@ -1,10 +1,8 @@
 #caseStudyTitle {
   margin-top: 1em !important;
-  font-family:"Roboto", sans-serif;
 }
 
 p {
-  font-family:"Roboto", sans-serif;
   padding:5%;
 }
 
@@ -24,7 +22,6 @@ body {
 }
 
 h1 {
-  font-family:"Roboto", sans-serif;
   font-weight:bold;
   letter-spacing:0.025em;
   font-size:42px;
@@ -40,7 +37,6 @@ h1 {
 }
 
 .banner1 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:12%;
@@ -53,7 +49,6 @@ h1 {
 }
 
 .banner2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:4%;
@@ -68,7 +63,6 @@ h1 {
 }
 
 .banner3 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-left:5%;
@@ -83,7 +77,6 @@ h1 {
 }
 
 .banner4 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:5%;
@@ -96,7 +89,6 @@ h1 {
 }
 
 .banner5 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   padding-top:3%;
@@ -110,7 +102,6 @@ h1 {
 }
 
 .banner2text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:70%;
@@ -119,7 +110,6 @@ h1 {
 }
 
 .banner3text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:75%;
@@ -128,7 +118,6 @@ h1 {
 }
 
 .banner4text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:65%;
@@ -137,7 +126,6 @@ h1 {
 }
 
 .banner5text {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   color:#ffffff;
   width:68%;
@@ -146,7 +134,6 @@ h1 {
 }
 
 h2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:24px;
   line-height:34px;
@@ -154,7 +141,6 @@ h2 {
 }
 
 .quote {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:22px;
   line-height:32px;
@@ -162,7 +148,6 @@ h2 {
 }
 
 .details {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   font-size:18px;
   color:#3366ff;
@@ -181,7 +166,6 @@ hr {
 }
 
 .col1 {
-  font-family:"Roboto", sans-serif;
   font-weight:100;
   color:#606060;
   line-height:20px;
@@ -190,7 +174,6 @@ hr {
 }
 
 .col2 {
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:20px;
   color:#606060;
@@ -204,7 +187,6 @@ hr {
   margin-right:10%;
   margin-top:4%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
   line-height:22px;
   color:#606060;
@@ -217,12 +199,10 @@ hr {
   margin-left:10%;
   margin-top:1%;
   margin-bottom:4%;
-  font-family:"Roboto", sans-serif;
   font-weight:300;
 }
 
 h4 {
-  font-family:"Roboto", sans-serif;
   font-weight:400;
   letter-spacing:0.9;
   font-size:20px;
@@ -232,7 +212,6 @@ h4 {
 @media screen and (max-width: 910px){
 
   h1 {
-    font-family:"Roboto", sans-serif;
     font-weight:bold;
     line-height:36px;
     letter-spacing:0.03em;
@@ -254,7 +233,6 @@ h4 {
   }
 
   .details {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     font-size:16px;
     color:#3366ff;
@@ -273,7 +251,6 @@ h4 {
     width: 95%;
     padding-right:8%;
     float:left;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#606060;
     line-height:20px;
@@ -285,7 +262,6 @@ h4 {
     width: 95%;
     padding-top:2%;
     padding-bottom:5%;
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     float:left;
     line-height:20px;
@@ -295,7 +271,6 @@ h4 {
   }
 
   .banner1 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:15%;
@@ -307,7 +282,6 @@ h4 {
   }
 
   .banner2 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -322,7 +296,6 @@ h4 {
   }
 
   .banner3 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:5%;
@@ -336,7 +309,6 @@ h4 {
   }
 
   .banner4 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -350,7 +322,6 @@ h4 {
   }
 
   .banner5 {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     padding-top:4%;
@@ -365,7 +336,6 @@ h4 {
   }
 
   .banner2text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -374,11 +344,9 @@ h4 {
     padding-top:1%;
     float:left;
     text-align:center;
-    color:#ffffff;
   }
 
   .banner3text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -389,7 +357,6 @@ h4 {
   }
 
   .banner4text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
@@ -400,7 +367,6 @@ h4 {
   }
 
   .banner5text {
-    font-family:"Roboto", sans-serif;
     font-weight:300;
     color:#ffffff;
     width:90%;
diff --git a/static/css/training.css b/static/css/training.css
index 2d7d866481..489bd1e0b2 100644
--- a/static/css/training.css
+++ b/static/css/training.css
@@ -1,29 +1,28 @@
-#hero {
+body.cid-training body.cid-training #hero {
   text-align: left;
   padding-bottom: 20px;
 }
 
-.section {
+body.cid-training body.cid-training .section {
   clear: both;
   padding: 0px;
   margin-bottom: 2em;
   width: 100%;
 }
 
-section.call-to-action {
+body.cid-training section.call-to-action {
   color: #ffffff;
   background-color: #3371e3;
 }
 
-section.call-to-action .main-section {
+body.cid-training section.call-to-action .main-section {
     max-width: initial;
 }
 
-section.call-to-action .main-section > div.call-to-action {
+body.cid-training section.call-to-action .main-section > div.call-to-action {
   display: flex;
   flex-direction: row;
   flex-wrap: wrap;
-  flex-basis: auto;
   justify-content: center;
   align-items: center;
   margin: initial;
@@ -31,54 +30,57 @@ section.call-to-action .main-section > div.call-to-action {
   padding-bottom: 5rem;
 }
 
-section.call-to-action .main-section > div.call-to-action > div {
-  order: 1;
+body.cid-training section.call-to-action .main-section > div.call-to-action > div {
   padding: 20px;
 }
 
-section.call-to-action .main-section .cta-text {
-  text-align: center;
-  flex: 1 1 auto;
-  max-width: 50vw;
+body.cid-training section.call-to-action .main-section .cta-text {
+  width: 100%;
+  flex-basis: 100%;
 }
 
-/* if max() and min() are available, use them */
-section.call-to-action .main-section .cta-text {
+body.cid-training section.call-to-action .main-section .cta-text > * {
+  margin-left: auto;
+  margin-right: auto;
+  text-align: center;
+  /* if max() and min() are available, use them */
   min-width: min(20em, 50vw);
   max-width: min(1000px, 50vw);
 }
 
-section.call-to-action .main-section .cta-image.cta-image-before {
-  order: 0
+body.cid-training section.call-to-action .main-section .cta-image {
+  max-width: max(20vw,150px);
+  flex-basis: auto;
 }
-
-section.call-to-action .main-section .cta-image.cta-image-after {
-  order: 2
-}
-
-section.call-to-action .main-section .cta-image > img {
+body.cid-training section.call-to-action .main-section .cta-image > img {
   display: block;
   width: 150px;
   margin: auto;
 }
 
-.col {
+body.cid-training #logo-cks {
+  order: 2; /* central */
+}
+
+
+
+body.cid-training .col {
   display: flex;
   flex-direction: row;
   float: left;
   margin: 1% 0 1% 1.6%;
 }
 
-.col:first-child { margin-left: 0; }
+body.cid-training .col:first-child { margin-left: 0; }
 
-.col-container {
+body.cid-training .col-container {
   display: flex; /* Make the container element behave like a table */
   flex-direction: row;
   width: 100%; /* Set full-width to expand the whole page */
   padding-bottom: 30px;
 }
 
-.col-nav {
+body.cid-training .col-nav {
   display: flex;
   flex-grow: 1;
   width: 18%;
@@ -87,47 +89,64 @@ section.call-to-action .main-section .cta-image > img {
   border: 5px solid white;
 }
 
+body.cid-training #get-certified .col-nav {
+  flex-flow: column nowrap;
+  justify-content: space-between;
+}
+
+body.cid-training #get-certified .col-nav > * {
+  flex-grow: 0;
+  flex-shrink: 0;
+  flex-basis: auto;
+}
+
+body.cid-training #get-certified .col-nav > br {
+  flex-grow: 1;
+  display: block;
+  min-height: 2em;
+}
+
+body.cid-training #get-certified .col-nav a.button {
+  flex: initial;
+  width: auto;
+  margin-left: auto;
+  margin-right: auto;
+}
+
 
 @media only screen and (max-width: 840px) {
-  section.call-to-action .main-section .cta-image.cta-image-before, section.call-to-action .main-section .cta-image.cta-image-after {
-    order: 0;
-  }
-  section.call-to-action .main-section .cta-image > img {
+  body.cid-training   section.call-to-action .main-section .cta-image > img {
     margin: 0;
   }
-  section.call-to-action .main-section .cta-image > img {
+  body.cid-training   section.call-to-action .main-section .cta-image > img {
     width: 7rem;
   }
-  section.call-to-action .main-section > div.call-to-action > div {
+  body.cid-training section.call-to-action .main-section > div.call-to-action > div {
     padding: 0 2rem 0 2rem;
   }
-  section.call-to-action .main-section .cta-text {
-    flex: 2 0 75vw;
-    max-width: initial;
-    padding: 5vw 0 0 0;
-  }
 }
 
 
+
 /*  GO FULL WIDTH AT LESS THAN 480 PIXELS */
 
 @media only screen and (max-width: 480px) {
-  .col { margin: 1% 0 1% 0%;}
-  .col-container { flex-direction: column; }
+  body.cid-training .col { margin: 1% 0 1% 0%;}
+  body.cid-training .col-container { flex-direction: column; }
+  body.cid-training #logo-cks { order: initial; }
 }
 
 @media only screen and (max-width: 650px) {
-  .col-nav {
+  body.cid-training .col-nav {
     display: block;
     width: 100%;
   }
-  .col-container { flex-direction: column; }
+  body.cid-training .col-container { flex-direction: column; }
 }
 
-.button{
+body.cid-training .button {
   max-width: 100%;
   box-sizing: border-box;
-  font-family: "Roboto", sans-serif;
   margin: 1em 0;
   display: inline-block;
   border-radius: 6px;
@@ -137,47 +156,48 @@ section.call-to-action .main-section .cta-image > img {
   font-size: 16px;
   background-color: #3371e3;
   text-decoration: none;
+  text-align: center;
 }
 
-h5 {
+body.cid-training h5 {
   font-size: 16px;
   font-weight: 500;
   line-height: 1.5em;
   margin-bottom: 2em;
 }
 
-.white-text {
+body.cid-training .white-text {
   color: #fff;
 }
 
-.padded {
+body.cid-training .padded {
   padding-top: 100px;
   padding-bottom: 100px;
 }
 
-.blue-bg {
+body.cid-training .blue-bg {
   background-color: #3371e3;
 }
 
-.lighter-gray-bg {
+body.cid-training .lighter-gray-bg {
   background-color: #f4f4f4;
 }
 
-.two-thirds-centered {
+body.cid-training .two-thirds-centered {
   width: 66%;
   max-width: 950px;
   margin-left: auto;
   margin-right: auto;
 }
 
-.landscape-section {
+body.cid-training .landscape-section {
   margin-left: auto;
   margin-right: auto;
   max-width: 1200px;
   width: 100%;
 }
 
-#landscape {
+body.cid-training #landscape {
   opacity: 1;
   visibility: visible;
   overflow: hidden;
diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/index.html b/static/docs/reference/generated/kubernetes-api/v1.18/index.html
deleted file mode 100644
index 9186045c54..0000000000
--- a/static/docs/reference/generated/kubernetes-api/v1.18/index.html
+++ /dev/null
@@ -1,47953 +0,0 @@
-<!DOCTYPE html>
-<HTML>
-<HEAD>
-<META charset="UTF-8">
-<TITLE>Kubernetes API Reference Docs</TITLE>
-<LINK rel="shortcut icon" href="favicon.ico" type="image/vnd.microsoft.icon">
-<LINK rel="stylesheet" href="/css/bootstrap-4.3.1.min.css">
-<LINK rel="stylesheet" href="/css/fontawesome-4.7.0.min.css" type="text/css">
-<LINK rel="stylesheet" href="/css/style_apiref.css" type="text/css">
-</HEAD>
-<BODY>
-<DIV id="wrapper" class="container-fluid">
-<DIV class="row">
-<DIV id="sidebar-wrapper" class="col-xs-4 col-sm-3 col-md-2 side-nav side-bar-nav">
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-api-overview-strong-" class="nav-item"><STRONG>Overview</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-workloads-apis-strong-" class="nav-item"><STRONG>WORKLOADS APIS</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#container-v1-core" class="nav-item">Container v1 core</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#cronjob-v1beta1-batch" class="nav-item">CronJob v1beta1 batch</A></LI>
- <UL id="cronjob-v1beta1-batch-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-cronjob-v1beta1-batch-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-cronjob-v1beta1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-cronjob-v1beta1-batch" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-cronjob-v1beta1-batch" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-cronjob-v1beta1-batch" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-cronjob-v1beta1-batch" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-cronjob-v1beta1-batch" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-cronjob-v1beta1-batch-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-cronjob-v1beta1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-cronjob-v1beta1-batch" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-cronjob-v1beta1-batch" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-cronjob-v1beta1-batch" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-cronjob-v1beta1-batch" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-cronjob-v1beta1-batch" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-cronjob-v1beta1-batch" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-cronjob-v1beta1-batch-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-cronjob-v1beta1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-cronjob-v1beta1-batch" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-cronjob-v1beta1-batch" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-cronjob-v1beta1-batch" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#daemonset-v1-apps" class="nav-item">DaemonSet v1 apps</A></LI>
- <UL id="daemonset-v1-apps-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-daemonset-v1-apps-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-daemonset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-daemonset-v1-apps" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-daemonset-v1-apps" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-daemonset-v1-apps" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-daemonset-v1-apps" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-daemonset-v1-apps" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-daemonset-v1-apps-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-daemonset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-daemonset-v1-apps" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-daemonset-v1-apps" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-daemonset-v1-apps" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-daemonset-v1-apps" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-daemonset-v1-apps" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-daemonset-v1-apps" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-daemonset-v1-apps-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-daemonset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-daemonset-v1-apps" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-daemonset-v1-apps" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-daemonset-v1-apps" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#deployment-v1-apps" class="nav-item">Deployment v1 apps</A></LI>
- <UL id="deployment-v1-apps-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-deployment-v1-apps-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-deployment-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-deployment-v1-apps" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-deployment-v1-apps" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-deployment-v1-apps" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-deployment-v1-apps" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-deployment-v1-apps" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-deployment-v1-apps-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-deployment-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-deployment-v1-apps" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-deployment-v1-apps" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-deployment-v1-apps" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-deployment-v1-apps" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-deployment-v1-apps" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-deployment-v1-apps" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-deployment-v1-apps-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-deployment-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-deployment-v1-apps" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-deployment-v1-apps" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-deployment-v1-apps" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-misc-operations-deployment-v1-apps-strong-" class="nav-item"><STRONG>Misc Operations</STRONG></A></LI>
-   <UL id="-strong-misc-operations-deployment-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-scale-deployment-v1-apps" class="nav-item">Read Scale</A></LI>
-    <LI class="nav-level-2"><A href="#replace-scale-deployment-v1-apps" class="nav-item">Replace Scale</A></LI>
-    <LI class="nav-level-2"><A href="#patch-scale-deployment-v1-apps" class="nav-item">Patch Scale</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#job-v1-batch" class="nav-item">Job v1 batch</A></LI>
- <UL id="job-v1-batch-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-job-v1-batch-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-job-v1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-job-v1-batch" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-job-v1-batch" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-job-v1-batch" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-job-v1-batch" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-job-v1-batch" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-job-v1-batch-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-job-v1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-job-v1-batch" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-job-v1-batch" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-job-v1-batch" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-job-v1-batch" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-job-v1-batch" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-job-v1-batch" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-job-v1-batch-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-job-v1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-job-v1-batch" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-job-v1-batch" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-job-v1-batch" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#pod-v1-core" class="nav-item">Pod v1 core</A></LI>
- <UL id="pod-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-pod-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-pod-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-pod-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#create-eviction-pod-v1-core" class="nav-item">Create Eviction</A></LI>
-    <LI class="nav-level-2"><A href="#patch-pod-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-pod-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-pod-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-pod-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-pod-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-pod-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-pod-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-pod-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-pod-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-pod-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-pod-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-pod-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-pod-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-pod-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-pod-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-pod-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-pod-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-proxy-operations-pod-v1-core-strong-" class="nav-item"><STRONG>Proxy Operations</STRONG></A></LI>
-   <UL id="-strong-proxy-operations-pod-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-connect-portforward-pod-v1-core" class="nav-item">Create Connect Portforward</A></LI>
-    <LI class="nav-level-2"><A href="#create-connect-proxy-pod-v1-core" class="nav-item">Create Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#create-connect-proxy-path-pod-v1-core" class="nav-item">Create Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#delete-connect-proxy-pod-v1-core" class="nav-item">Delete Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#delete-connect-proxy-path-pod-v1-core" class="nav-item">Delete Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-portforward-pod-v1-core" class="nav-item">Get Connect Portforward</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-proxy-pod-v1-core" class="nav-item">Get Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-proxy-path-pod-v1-core" class="nav-item">Get Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#head-connect-proxy-pod-v1-core" class="nav-item">Head Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#head-connect-proxy-path-pod-v1-core" class="nav-item">Head Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#replace-connect-proxy-pod-v1-core" class="nav-item">Replace Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#replace-connect-proxy-path-pod-v1-core" class="nav-item">Replace Connect Proxy Path</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-misc-operations-pod-v1-core-strong-" class="nav-item"><STRONG>Misc Operations</STRONG></A></LI>
-   <UL id="-strong-misc-operations-pod-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-log-pod-v1-core" class="nav-item">Read Log</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#replicaset-v1-apps" class="nav-item">ReplicaSet v1 apps</A></LI>
- <UL id="replicaset-v1-apps-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-replicaset-v1-apps-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-replicaset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-replicaset-v1-apps" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-replicaset-v1-apps" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-replicaset-v1-apps" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-replicaset-v1-apps" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-replicaset-v1-apps" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-replicaset-v1-apps-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-replicaset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-replicaset-v1-apps" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-replicaset-v1-apps" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-replicaset-v1-apps" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-replicaset-v1-apps" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-replicaset-v1-apps" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-replicaset-v1-apps" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-replicaset-v1-apps-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-replicaset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-replicaset-v1-apps" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-replicaset-v1-apps" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-replicaset-v1-apps" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-misc-operations-replicaset-v1-apps-strong-" class="nav-item"><STRONG>Misc Operations</STRONG></A></LI>
-   <UL id="-strong-misc-operations-replicaset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-scale-replicaset-v1-apps" class="nav-item">Read Scale</A></LI>
-    <LI class="nav-level-2"><A href="#replace-scale-replicaset-v1-apps" class="nav-item">Replace Scale</A></LI>
-    <LI class="nav-level-2"><A href="#patch-scale-replicaset-v1-apps" class="nav-item">Patch Scale</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#replicationcontroller-v1-core" class="nav-item">ReplicationController v1 core</A></LI>
- <UL id="replicationcontroller-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-replicationcontroller-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-replicationcontroller-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-replicationcontroller-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-replicationcontroller-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-replicationcontroller-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-replicationcontroller-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-replicationcontroller-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-replicationcontroller-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-replicationcontroller-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-replicationcontroller-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-replicationcontroller-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-replicationcontroller-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-replicationcontroller-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-replicationcontroller-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-replicationcontroller-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-replicationcontroller-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-replicationcontroller-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-replicationcontroller-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-replicationcontroller-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-replicationcontroller-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-misc-operations-replicationcontroller-v1-core-strong-" class="nav-item"><STRONG>Misc Operations</STRONG></A></LI>
-   <UL id="-strong-misc-operations-replicationcontroller-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-scale-replicationcontroller-v1-core" class="nav-item">Read Scale</A></LI>
-    <LI class="nav-level-2"><A href="#replace-scale-replicationcontroller-v1-core" class="nav-item">Replace Scale</A></LI>
-    <LI class="nav-level-2"><A href="#patch-scale-replicationcontroller-v1-core" class="nav-item">Patch Scale</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#statefulset-v1-apps" class="nav-item">StatefulSet v1 apps</A></LI>
- <UL id="statefulset-v1-apps-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-statefulset-v1-apps-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-statefulset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-statefulset-v1-apps" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-statefulset-v1-apps" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-statefulset-v1-apps" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-statefulset-v1-apps" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-statefulset-v1-apps" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-statefulset-v1-apps-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-statefulset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-statefulset-v1-apps" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-statefulset-v1-apps" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-statefulset-v1-apps" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-statefulset-v1-apps" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-statefulset-v1-apps" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-statefulset-v1-apps" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-statefulset-v1-apps-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-statefulset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-statefulset-v1-apps" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-statefulset-v1-apps" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-statefulset-v1-apps" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-misc-operations-statefulset-v1-apps-strong-" class="nav-item"><STRONG>Misc Operations</STRONG></A></LI>
-   <UL id="-strong-misc-operations-statefulset-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-scale-statefulset-v1-apps" class="nav-item">Read Scale</A></LI>
-    <LI class="nav-level-2"><A href="#replace-scale-statefulset-v1-apps" class="nav-item">Replace Scale</A></LI>
-    <LI class="nav-level-2"><A href="#patch-scale-statefulset-v1-apps" class="nav-item">Patch Scale</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-service-apis-strong-" class="nav-item"><STRONG>SERVICE APIS</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#endpoints-v1-core" class="nav-item">Endpoints v1 core</A></LI>
- <UL id="endpoints-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-endpoints-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-endpoints-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-endpoints-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-endpoints-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-endpoints-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-endpoints-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-endpoints-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-endpoints-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-endpoints-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-endpoints-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-endpoints-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-endpoints-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-endpoints-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-endpoints-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-endpoints-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#endpointslice-v1beta1-discovery-k8s-io" class="nav-item">EndpointSlice v1beta1 discovery.k8s.io</A></LI>
- <UL id="endpointslice-v1beta1-discovery-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#ingress-v1beta1-networking-k8s-io" class="nav-item">Ingress v1beta1 networking.k8s.io</A></LI>
- <UL id="ingress-v1beta1-networking-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-ingress-v1beta1-networking-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-ingress-v1beta1-networking-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-ingress-v1beta1-networking-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-ingress-v1beta1-networking-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-ingress-v1beta1-networking-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-ingress-v1beta1-networking-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-ingress-v1beta1-networking-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-ingress-v1beta1-networking-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-ingress-v1beta1-networking-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-ingress-v1beta1-networking-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-ingress-v1beta1-networking-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-ingress-v1beta1-networking-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-ingress-v1beta1-networking-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#ingressclass-v1beta1-networking-k8s-io" class="nav-item">IngressClass v1beta1 networking.k8s.io</A></LI>
- <UL id="ingressclass-v1beta1-networking-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-ingressclass-v1beta1-networking-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-ingressclass-v1beta1-networking-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#service-v1-core" class="nav-item">Service v1 core</A></LI>
- <UL id="service-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-service-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-service-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-service-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-service-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-service-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-service-v1-core" class="nav-item">Delete</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-service-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-service-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-service-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-service-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-service-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-service-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-service-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-service-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-service-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-service-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-service-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-service-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-service-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-proxy-operations-service-v1-core-strong-" class="nav-item"><STRONG>Proxy Operations</STRONG></A></LI>
-   <UL id="-strong-proxy-operations-service-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-connect-proxy-service-v1-core" class="nav-item">Create Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#create-connect-proxy-path-service-v1-core" class="nav-item">Create Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#delete-connect-proxy-service-v1-core" class="nav-item">Delete Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#delete-connect-proxy-path-service-v1-core" class="nav-item">Delete Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-proxy-service-v1-core" class="nav-item">Get Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-proxy-path-service-v1-core" class="nav-item">Get Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#head-connect-proxy-service-v1-core" class="nav-item">Head Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#head-connect-proxy-path-service-v1-core" class="nav-item">Head Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#replace-connect-proxy-service-v1-core" class="nav-item">Replace Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#replace-connect-proxy-path-service-v1-core" class="nav-item">Replace Connect Proxy Path</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-config-and-storage-apis-strong-" class="nav-item"><STRONG>CONFIG AND STORAGE APIS</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#configmap-v1-core" class="nav-item">ConfigMap v1 core</A></LI>
- <UL id="configmap-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-configmap-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-configmap-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-configmap-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-configmap-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-configmap-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-configmap-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-configmap-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-configmap-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-configmap-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-configmap-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-configmap-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-configmap-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-configmap-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-configmap-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-configmap-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#csidriver-v1-storage-k8s-io" class="nav-item">CSIDriver v1 storage.k8s.io</A></LI>
- <UL id="csidriver-v1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-csidriver-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-csidriver-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-csidriver-v1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-csidriver-v1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-csidriver-v1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-csidriver-v1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-csidriver-v1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-csidriver-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-csidriver-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-csidriver-v1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-csidriver-v1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-csidriver-v1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-csidriver-v1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#csinode-v1-storage-k8s-io" class="nav-item">CSINode v1 storage.k8s.io</A></LI>
- <UL id="csinode-v1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-csinode-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-csinode-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-csinode-v1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-csinode-v1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-csinode-v1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-csinode-v1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-csinode-v1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-csinode-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-csinode-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-csinode-v1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-csinode-v1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-csinode-v1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-csinode-v1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#secret-v1-core" class="nav-item">Secret v1 core</A></LI>
- <UL id="secret-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-secret-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-secret-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-secret-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-secret-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-secret-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-secret-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-secret-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-secret-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-secret-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-secret-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-secret-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-secret-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-secret-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-secret-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-secret-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#persistentvolumeclaim-v1-core" class="nav-item">PersistentVolumeClaim v1 core</A></LI>
- <UL id="persistentvolumeclaim-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-persistentvolumeclaim-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-persistentvolumeclaim-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-persistentvolumeclaim-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-persistentvolumeclaim-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-persistentvolumeclaim-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-persistentvolumeclaim-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-persistentvolumeclaim-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-persistentvolumeclaim-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-persistentvolumeclaim-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-persistentvolumeclaim-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-persistentvolumeclaim-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-persistentvolumeclaim-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-persistentvolumeclaim-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-persistentvolumeclaim-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-persistentvolumeclaim-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-persistentvolumeclaim-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-persistentvolumeclaim-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-persistentvolumeclaim-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-persistentvolumeclaim-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-persistentvolumeclaim-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#storageclass-v1-storage-k8s-io" class="nav-item">StorageClass v1 storage.k8s.io</A></LI>
- <UL id="storageclass-v1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-storageclass-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-storageclass-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-storageclass-v1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-storageclass-v1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-storageclass-v1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-storageclass-v1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-storageclass-v1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-storageclass-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-storageclass-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-storageclass-v1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-storageclass-v1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-storageclass-v1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-storageclass-v1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volume-v1-core" class="nav-item">Volume v1 core</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeattachment-v1-storage-k8s-io" class="nav-item">VolumeAttachment v1 storage.k8s.io</A></LI>
- <UL id="volumeattachment-v1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-volumeattachment-v1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-volumeattachment-v1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-volumeattachment-v1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-volumeattachment-v1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-volumeattachment-v1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-volumeattachment-v1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-volumeattachment-v1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-volumeattachment-v1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-volumeattachment-v1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-volumeattachment-v1-storage-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-volumeattachment-v1-storage-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-volumeattachment-v1-storage-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-metadata-apis-strong-" class="nav-item"><STRONG>METADATA APIS</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#controllerrevision-v1-apps" class="nav-item">ControllerRevision v1 apps</A></LI>
- <UL id="controllerrevision-v1-apps-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-controllerrevision-v1-apps-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-controllerrevision-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-controllerrevision-v1-apps" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-controllerrevision-v1-apps" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-controllerrevision-v1-apps" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-controllerrevision-v1-apps" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-controllerrevision-v1-apps" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-controllerrevision-v1-apps-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-controllerrevision-v1-apps-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-controllerrevision-v1-apps" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-controllerrevision-v1-apps" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-controllerrevision-v1-apps" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-controllerrevision-v1-apps" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-controllerrevision-v1-apps" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-controllerrevision-v1-apps" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinition v1 apiextensions.k8s.io</A></LI>
- <UL id="customresourcedefinition-v1-apiextensions-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-customresourcedefinition-v1-apiextensions-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#event-v1-core" class="nav-item">Event v1 core</A></LI>
- <UL id="event-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-event-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-event-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-event-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-event-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-event-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-event-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-event-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-event-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-event-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-event-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-event-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-event-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-event-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-event-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-event-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#limitrange-v1-core" class="nav-item">LimitRange v1 core</A></LI>
- <UL id="limitrange-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-limitrange-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-limitrange-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-limitrange-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-limitrange-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-limitrange-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-limitrange-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-limitrange-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-limitrange-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-limitrange-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-limitrange-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-limitrange-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-limitrange-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-limitrange-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-limitrange-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-limitrange-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#horizontalpodautoscaler-v1-autoscaling" class="nav-item">HorizontalPodAutoscaler v1 autoscaling</A></LI>
- <UL id="horizontalpodautoscaler-v1-autoscaling-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-horizontalpodautoscaler-v1-autoscaling" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-horizontalpodautoscaler-v1-autoscaling" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-horizontalpodautoscaler-v1-autoscaling" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">MutatingWebhookConfiguration v1 admissionregistration.k8s.io</A></LI>
- <UL id="mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">ValidatingWebhookConfiguration v1 admissionregistration.k8s.io</A></LI>
- <UL id="validatingwebhookconfiguration-v1-admissionregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#podtemplate-v1-core" class="nav-item">PodTemplate v1 core</A></LI>
- <UL id="podtemplate-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-podtemplate-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-podtemplate-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-podtemplate-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-podtemplate-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-podtemplate-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-podtemplate-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-podtemplate-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-podtemplate-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-podtemplate-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-podtemplate-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-podtemplate-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-podtemplate-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-podtemplate-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-podtemplate-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-podtemplate-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#poddisruptionbudget-v1beta1-policy" class="nav-item">PodDisruptionBudget v1beta1 policy</A></LI>
- <UL id="poddisruptionbudget-v1beta1-policy-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-poddisruptionbudget-v1beta1-policy" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-poddisruptionbudget-v1beta1-policy" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-poddisruptionbudget-v1beta1-policy" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-poddisruptionbudget-v1beta1-policy" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-poddisruptionbudget-v1beta1-policy" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-poddisruptionbudget-v1beta1-policy" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-poddisruptionbudget-v1beta1-policy" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-poddisruptionbudget-v1beta1-policy" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-poddisruptionbudget-v1beta1-policy" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-poddisruptionbudget-v1beta1-policy" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-poddisruptionbudget-v1beta1-policy" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-poddisruptionbudget-v1beta1-policy" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-poddisruptionbudget-v1beta1-policy" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#priorityclass-v1-scheduling-k8s-io" class="nav-item">PriorityClass v1 scheduling.k8s.io</A></LI>
- <UL id="priorityclass-v1-scheduling-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-priorityclass-v1-scheduling-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-priorityclass-v1-scheduling-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-priorityclass-v1-scheduling-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-priorityclass-v1-scheduling-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-priorityclass-v1-scheduling-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-priorityclass-v1-scheduling-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-priorityclass-v1-scheduling-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-priorityclass-v1-scheduling-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-priorityclass-v1-scheduling-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#podpreset-v1alpha1-settings-k8s-io" class="nav-item">PodPreset v1alpha1 settings.k8s.io</A></LI>
- <UL id="podpreset-v1alpha1-settings-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-podpreset-v1alpha1-settings-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-podpreset-v1alpha1-settings-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#podsecuritypolicy-v1beta1-policy" class="nav-item">PodSecurityPolicy v1beta1 policy</A></LI>
- <UL id="podsecuritypolicy-v1beta1-policy-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-podsecuritypolicy-v1beta1-policy" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-podsecuritypolicy-v1beta1-policy" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-podsecuritypolicy-v1beta1-policy" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-podsecuritypolicy-v1beta1-policy" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-podsecuritypolicy-v1beta1-policy" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-podsecuritypolicy-v1beta1-policy" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-podsecuritypolicy-v1beta1-policy" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-podsecuritypolicy-v1beta1-policy" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-podsecuritypolicy-v1beta1-policy" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-cluster-apis-strong-" class="nav-item"><STRONG>CLUSTER APIS</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#apiservice-v1-apiregistration-k8s-io" class="nav-item">APIService v1 apiregistration.k8s.io</A></LI>
- <UL id="apiservice-v1-apiregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-apiservice-v1-apiregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-apiservice-v1-apiregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-apiservice-v1-apiregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-apiservice-v1-apiregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-apiservice-v1-apiregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-apiservice-v1-apiregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-apiservice-v1-apiregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-apiservice-v1-apiregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-apiservice-v1-apiregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-apiservice-v1-apiregistration-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-apiservice-v1-apiregistration-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-apiservice-v1-apiregistration-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">AuditSink v1alpha1 auditregistration.k8s.io</A></LI>
- <UL id="auditsink-v1alpha1-auditregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-auditsink-v1alpha1-auditregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#binding-v1-core" class="nav-item">Binding v1 core</A></LI>
- <UL id="binding-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-binding-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-binding-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-binding-v1-core" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">CertificateSigningRequest v1beta1 certificates.k8s.io</A></LI>
- <UL id="certificatesigningrequest-v1beta1-certificates-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">ClusterRole v1 rbac.authorization.k8s.io</A></LI>
- <UL id="clusterrole-v1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-clusterrole-v1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">ClusterRoleBinding v1 rbac.authorization.k8s.io</A></LI>
- <UL id="clusterrolebinding-v1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#componentstatus-v1-core" class="nav-item">ComponentStatus v1 core</A></LI>
- <UL id="componentstatus-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-componentstatus-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-componentstatus-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-componentstatus-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-componentstatus-v1-core" class="nav-item">List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">FlowSchema v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- <UL id="flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#lease-v1-coordination-k8s-io" class="nav-item">Lease v1 coordination.k8s.io</A></LI>
- <UL id="lease-v1-coordination-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-lease-v1-coordination-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-lease-v1-coordination-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-lease-v1-coordination-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-lease-v1-coordination-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-lease-v1-coordination-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-lease-v1-coordination-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-lease-v1-coordination-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-lease-v1-coordination-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-lease-v1-coordination-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-lease-v1-coordination-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-lease-v1-coordination-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-lease-v1-coordination-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-lease-v1-coordination-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-lease-v1-coordination-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-lease-v1-coordination-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#localsubjectaccessreview-v1-authorization-k8s-io" class="nav-item">LocalSubjectAccessReview v1 authorization.k8s.io</A></LI>
- <UL id="localsubjectaccessreview-v1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-localsubjectaccessreview-v1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#namespace-v1-core" class="nav-item">Namespace v1 core</A></LI>
- <UL id="namespace-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-namespace-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-namespace-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-namespace-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-namespace-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-namespace-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-namespace-v1-core" class="nav-item">Delete</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-namespace-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-namespace-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-namespace-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-namespace-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-namespace-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-namespace-v1-core" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-namespace-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-namespace-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-namespace-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-namespace-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-namespace-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#node-v1-core" class="nav-item">Node v1 core</A></LI>
- <UL id="node-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-node-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-node-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-node-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-node-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-node-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-node-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-node-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-node-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-node-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-node-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-node-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-node-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-node-v1-core" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-node-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-node-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-node-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-node-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-node-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-proxy-operations-node-v1-core-strong-" class="nav-item"><STRONG>Proxy Operations</STRONG></A></LI>
-   <UL id="-strong-proxy-operations-node-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-connect-proxy-node-v1-core" class="nav-item">Create Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#create-connect-proxy-path-node-v1-core" class="nav-item">Create Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#delete-connect-proxy-node-v1-core" class="nav-item">Delete Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#delete-connect-proxy-path-node-v1-core" class="nav-item">Delete Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-proxy-node-v1-core" class="nav-item">Get Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#get-connect-proxy-path-node-v1-core" class="nav-item">Get Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#head-connect-proxy-node-v1-core" class="nav-item">Head Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#head-connect-proxy-path-node-v1-core" class="nav-item">Head Connect Proxy Path</A></LI>
-    <LI class="nav-level-2"><A href="#replace-connect-proxy-node-v1-core" class="nav-item">Replace Connect Proxy</A></LI>
-    <LI class="nav-level-2"><A href="#replace-connect-proxy-path-node-v1-core" class="nav-item">Replace Connect Proxy Path</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#persistentvolume-v1-core" class="nav-item">PersistentVolume v1 core</A></LI>
- <UL id="persistentvolume-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-persistentvolume-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-persistentvolume-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-persistentvolume-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-persistentvolume-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-persistentvolume-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-persistentvolume-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-persistentvolume-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-persistentvolume-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-persistentvolume-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-persistentvolume-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-persistentvolume-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-persistentvolume-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-persistentvolume-v1-core" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-persistentvolume-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-persistentvolume-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-persistentvolume-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-persistentvolume-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-persistentvolume-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">PriorityLevelConfiguration v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- <UL id="prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#resourcequota-v1-core" class="nav-item">ResourceQuota v1 core</A></LI>
- <UL id="resourcequota-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-resourcequota-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-resourcequota-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-resourcequota-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-resourcequota-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-resourcequota-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-resourcequota-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-resourcequota-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-resourcequota-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-resourcequota-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-resourcequota-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-resourcequota-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-resourcequota-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-resourcequota-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-resourcequota-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-resourcequota-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-resourcequota-v1-core-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-resourcequota-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-resourcequota-v1-core" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-resourcequota-v1-core" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-resourcequota-v1-core" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#role-v1-rbac-authorization-k8s-io" class="nav-item">Role v1 rbac.authorization.k8s.io</A></LI>
- <UL id="role-v1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-role-v1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-role-v1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-role-v1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-role-v1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-role-v1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-role-v1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-role-v1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-role-v1-rbac-authorization-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-role-v1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-role-v1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">RoleBinding v1 rbac.authorization.k8s.io</A></LI>
- <UL id="rolebinding-v1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#runtimeclass-v1beta1-node-k8s-io" class="nav-item">RuntimeClass v1beta1 node.k8s.io</A></LI>
- <UL id="runtimeclass-v1beta1-node-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-runtimeclass-v1beta1-node-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-runtimeclass-v1beta1-node-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#selfsubjectaccessreview-v1-authorization-k8s-io" class="nav-item">SelfSubjectAccessReview v1 authorization.k8s.io</A></LI>
- <UL id="selfsubjectaccessreview-v1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-selfsubjectaccessreview-v1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#selfsubjectrulesreview-v1-authorization-k8s-io" class="nav-item">SelfSubjectRulesReview v1 authorization.k8s.io</A></LI>
- <UL id="selfsubjectrulesreview-v1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-selfsubjectrulesreview-v1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#serviceaccount-v1-core" class="nav-item">ServiceAccount v1 core</A></LI>
- <UL id="serviceaccount-v1-core-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-serviceaccount-v1-core-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-serviceaccount-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-serviceaccount-v1-core" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-serviceaccount-v1-core" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-serviceaccount-v1-core" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-serviceaccount-v1-core" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-serviceaccount-v1-core" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-serviceaccount-v1-core-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-serviceaccount-v1-core-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-serviceaccount-v1-core" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-serviceaccount-v1-core" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-serviceaccount-v1-core" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-serviceaccount-v1-core" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-serviceaccount-v1-core" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-serviceaccount-v1-core" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#subjectaccessreview-v1-authorization-k8s-io" class="nav-item">SubjectAccessReview v1 authorization.k8s.io</A></LI>
- <UL id="subjectaccessreview-v1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-subjectaccessreview-v1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#tokenrequest-v1-authentication-k8s-io" class="nav-item">TokenRequest v1 authentication.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#tokenreview-v1-authentication-k8s-io" class="nav-item">TokenReview v1 authentication.k8s.io</A></LI>
- <UL id="tokenreview-v1-authentication-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-tokenreview-v1-authentication-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#networkpolicy-v1-networking-k8s-io" class="nav-item">NetworkPolicy v1 networking.k8s.io</A></LI>
- <UL id="networkpolicy-v1-networking-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-networkpolicy-v1-networking-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-networkpolicy-v1-networking-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-networkpolicy-v1-networking-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-networkpolicy-v1-networking-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-networkpolicy-v1-networking-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-networkpolicy-v1-networking-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-networkpolicy-v1-networking-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-networkpolicy-v1-networking-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-networkpolicy-v1-networking-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-networkpolicy-v1-networking-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-definitions-strong-" class="nav-item"><STRONG>DEFINITIONS</STRONG></A></LI>
-</UL>
- <UL id="-strong-definitions-strong--nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2"><A href="#apigroup-v1-meta" class="nav-item">APIGroup v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#apiresource-v1-meta" class="nav-item">APIResource v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#apiservicecondition-v1-apiregistration-k8s-io" class="nav-item">APIServiceCondition v1 apiregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#apiversions-v1-meta" class="nav-item">APIVersions v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#awselasticblockstorevolumesource-v1-core" class="nav-item">AWSElasticBlockStoreVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#affinity-v1-core" class="nav-item">Affinity v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#aggregationrule-v1-rbac-authorization-k8s-io" class="nav-item">AggregationRule v1 rbac.authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#allowedcsidriver-v1beta1-policy" class="nav-item">AllowedCSIDriver v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#allowedflexvolume-v1beta1-policy" class="nav-item">AllowedFlexVolume v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#allowedhostpath-v1beta1-policy" class="nav-item">AllowedHostPath v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#attachedvolume-v1-core" class="nav-item">AttachedVolume v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#azurediskvolumesource-v1-core" class="nav-item">AzureDiskVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#azurefilepersistentvolumesource-v1-core" class="nav-item">AzureFilePersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#azurefilevolumesource-v1-core" class="nav-item">AzureFileVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#boundobjectreference-v1-authentication-k8s-io" class="nav-item">BoundObjectReference v1 authentication.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#csinodedriver-v1-storage-k8s-io" class="nav-item">CSINodeDriver v1 storage.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#csipersistentvolumesource-v1-core" class="nav-item">CSIPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#csivolumesource-v1-core" class="nav-item">CSIVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#capabilities-v1-core" class="nav-item">Capabilities v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#cephfspersistentvolumesource-v1-core" class="nav-item">CephFSPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#cephfsvolumesource-v1-core" class="nav-item">CephFSVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#certificatesigningrequestcondition-v1beta1-certificates-k8s-io" class="nav-item">CertificateSigningRequestCondition v1beta1 certificates.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#cinderpersistentvolumesource-v1-core" class="nav-item">CinderPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#cindervolumesource-v1-core" class="nav-item">CinderVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#clientipconfig-v1-core" class="nav-item">ClientIPConfig v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#componentcondition-v1-core" class="nav-item">ComponentCondition v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#configmapenvsource-v1-core" class="nav-item">ConfigMapEnvSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#configmapkeyselector-v1-core" class="nav-item">ConfigMapKeySelector v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#configmapnodeconfigsource-v1-core" class="nav-item">ConfigMapNodeConfigSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#configmapprojection-v1-core" class="nav-item">ConfigMapProjection v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#configmapvolumesource-v1-core" class="nav-item">ConfigMapVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#containerimage-v1-core" class="nav-item">ContainerImage v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#containerport-v1-core" class="nav-item">ContainerPort v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#containerstate-v1-core" class="nav-item">ContainerState v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#containerstaterunning-v1-core" class="nav-item">ContainerStateRunning v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#containerstateterminated-v1-core" class="nav-item">ContainerStateTerminated v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#containerstatewaiting-v1-core" class="nav-item">ContainerStateWaiting v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#crossversionobjectreference-v1-autoscaling" class="nav-item">CrossVersionObjectReference v1 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcecolumndefinition-v1-apiextensions-k8s-io" class="nav-item">CustomResourceColumnDefinition v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourceconversion-v1-apiextensions-k8s-io" class="nav-item">CustomResourceConversion v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcedefinitioncondition-v1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinitionCondition v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcedefinitionnames-v1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinitionNames v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcedefinitionversion-v1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinitionVersion v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcesubresourcescale-v1-apiextensions-k8s-io" class="nav-item">CustomResourceSubresourceScale v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcesubresourcestatus-v1-apiextensions-k8s-io" class="nav-item">CustomResourceSubresourceStatus v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcesubresources-v1-apiextensions-k8s-io" class="nav-item">CustomResourceSubresources v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#customresourcevalidation-v1-apiextensions-k8s-io" class="nav-item">CustomResourceValidation v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#daemonendpoint-v1-core" class="nav-item">DaemonEndpoint v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#daemonsetcondition-v1-apps" class="nav-item">DaemonSetCondition v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#daemonsetupdatestrategy-v1-apps" class="nav-item">DaemonSetUpdateStrategy v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#deleteoptions-v1-meta" class="nav-item">DeleteOptions v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#deploymentcondition-v1-apps" class="nav-item">DeploymentCondition v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#downwardapiprojection-v1-core" class="nav-item">DownwardAPIProjection v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#downwardapivolumefile-v1-core" class="nav-item">DownwardAPIVolumeFile v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#downwardapivolumesource-v1-core" class="nav-item">DownwardAPIVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#emptydirvolumesource-v1-core" class="nav-item">EmptyDirVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#endpoint-v1beta1-discovery-k8s-io" class="nav-item">Endpoint v1beta1 discovery.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#endpointaddress-v1-core" class="nav-item">EndpointAddress v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#endpointconditions-v1beta1-discovery-k8s-io" class="nav-item">EndpointConditions v1beta1 discovery.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#endpointport-v1-core" class="nav-item">EndpointPort v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#endpointsubset-v1-core" class="nav-item">EndpointSubset v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#envfromsource-v1-core" class="nav-item">EnvFromSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#envvar-v1-core" class="nav-item">EnvVar v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#envvarsource-v1-core" class="nav-item">EnvVarSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#ephemeralcontainer-v1-core" class="nav-item">EphemeralContainer v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#eventseries-v1-core" class="nav-item">EventSeries v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#eventsource-v1-core" class="nav-item">EventSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#eviction-v1beta1-policy" class="nav-item">Eviction v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#execaction-v1-core" class="nav-item">ExecAction v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#externaldocumentation-v1-apiextensions-k8s-io" class="nav-item">ExternalDocumentation v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#externalmetricsource-v2beta2-autoscaling" class="nav-item">ExternalMetricSource v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#externalmetricstatus-v2beta2-autoscaling" class="nav-item">ExternalMetricStatus v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#fcvolumesource-v1-core" class="nav-item">FCVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#fsgroupstrategyoptions-v1beta1-policy" class="nav-item">FSGroupStrategyOptions v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#fieldsv1-v1-meta" class="nav-item">FieldsV1 v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#flexpersistentvolumesource-v1-core" class="nav-item">FlexPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#flexvolumesource-v1-core" class="nav-item">FlexVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#flockervolumesource-v1-core" class="nav-item">FlockerVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">FlowDistinguisherMethod v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">FlowSchemaCondition v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#gcepersistentdiskvolumesource-v1-core" class="nav-item">GCEPersistentDiskVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#gitrepovolumesource-v1-core" class="nav-item">GitRepoVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#glusterfspersistentvolumesource-v1-core" class="nav-item">GlusterfsPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#glusterfsvolumesource-v1-core" class="nav-item">GlusterfsVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">GroupSubject v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#groupversionfordiscovery-v1-meta" class="nav-item">GroupVersionForDiscovery v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#hpascalingpolicy-v2beta2-autoscaling" class="nav-item">HPAScalingPolicy v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#hpascalingrules-v2beta2-autoscaling" class="nav-item">HPAScalingRules v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#httpgetaction-v1-core" class="nav-item">HTTPGetAction v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#httpheader-v1-core" class="nav-item">HTTPHeader v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#httpingresspath-v1beta1-networking-k8s-io" class="nav-item">HTTPIngressPath v1beta1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#httpingressrulevalue-v1beta1-networking-k8s-io" class="nav-item">HTTPIngressRuleValue v1beta1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#handler-v1-core" class="nav-item">Handler v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#horizontalpodautoscalerbehavior-v2beta2-autoscaling" class="nav-item">HorizontalPodAutoscalerBehavior v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#horizontalpodautoscalercondition-v2beta2-autoscaling" class="nav-item">HorizontalPodAutoscalerCondition v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#hostalias-v1-core" class="nav-item">HostAlias v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#hostpathvolumesource-v1-core" class="nav-item">HostPathVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#hostportrange-v1beta1-policy" class="nav-item">HostPortRange v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#idrange-v1beta1-policy" class="nav-item">IDRange v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#ipblock-v1-networking-k8s-io" class="nav-item">IPBlock v1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#iscsipersistentvolumesource-v1-core" class="nav-item">ISCSIPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#iscsivolumesource-v1-core" class="nav-item">ISCSIVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#ingressbackend-v1beta1-networking-k8s-io" class="nav-item">IngressBackend v1beta1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#ingressrule-v1beta1-networking-k8s-io" class="nav-item">IngressRule v1beta1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#ingresstls-v1beta1-networking-k8s-io" class="nav-item">IngressTLS v1beta1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#json-v1-apiextensions-k8s-io" class="nav-item">JSON v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#jsonschemaprops-v1-apiextensions-k8s-io" class="nav-item">JSONSchemaProps v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#jsonschemapropsorarray-v1-apiextensions-k8s-io" class="nav-item">JSONSchemaPropsOrArray v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#jsonschemapropsorbool-v1-apiextensions-k8s-io" class="nav-item">JSONSchemaPropsOrBool v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#jobcondition-v1-batch" class="nav-item">JobCondition v1 batch</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#jobtemplatespec-v1beta1-batch" class="nav-item">JobTemplateSpec v1beta1 batch</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#keytopath-v1-core" class="nav-item">KeyToPath v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#labelselector-v1-meta" class="nav-item">LabelSelector v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#labelselectorrequirement-v1-meta" class="nav-item">LabelSelectorRequirement v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#lifecycle-v1-core" class="nav-item">Lifecycle v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#limitrangeitem-v1-core" class="nav-item">LimitRangeItem v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">LimitResponse v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">LimitedPriorityLevelConfiguration v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#listmeta-v1-meta" class="nav-item">ListMeta v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#loadbalanceringress-v1-core" class="nav-item">LoadBalancerIngress v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#loadbalancerstatus-v1-core" class="nav-item">LoadBalancerStatus v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#localobjectreference-v1-core" class="nav-item">LocalObjectReference v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#localvolumesource-v1-core" class="nav-item">LocalVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#managedfieldsentry-v1-meta" class="nav-item">ManagedFieldsEntry v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#metricidentifier-v2beta2-autoscaling" class="nav-item">MetricIdentifier v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#metricspec-v2beta2-autoscaling" class="nav-item">MetricSpec v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#metricstatus-v2beta2-autoscaling" class="nav-item">MetricStatus v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#metrictarget-v2beta2-autoscaling" class="nav-item">MetricTarget v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#metricvaluestatus-v2beta2-autoscaling" class="nav-item">MetricValueStatus v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#microtime-v1-meta" class="nav-item">MicroTime v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#mutatingwebhook-v1-admissionregistration-k8s-io" class="nav-item">MutatingWebhook v1 admissionregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nfsvolumesource-v1-core" class="nav-item">NFSVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#namespacecondition-v1-core" class="nav-item">NamespaceCondition v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#networkpolicyegressrule-v1-networking-k8s-io" class="nav-item">NetworkPolicyEgressRule v1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#networkpolicyingressrule-v1-networking-k8s-io" class="nav-item">NetworkPolicyIngressRule v1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#networkpolicypeer-v1-networking-k8s-io" class="nav-item">NetworkPolicyPeer v1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#networkpolicyport-v1-networking-k8s-io" class="nav-item">NetworkPolicyPort v1 networking.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeaddress-v1-core" class="nav-item">NodeAddress v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeaffinity-v1-core" class="nav-item">NodeAffinity v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodecondition-v1-core" class="nav-item">NodeCondition v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeconfigsource-v1-core" class="nav-item">NodeConfigSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeconfigstatus-v1-core" class="nav-item">NodeConfigStatus v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodedaemonendpoints-v1-core" class="nav-item">NodeDaemonEndpoints v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeselector-v1-core" class="nav-item">NodeSelector v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeselectorrequirement-v1-core" class="nav-item">NodeSelectorRequirement v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodeselectorterm-v1-core" class="nav-item">NodeSelectorTerm v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nodesysteminfo-v1-core" class="nav-item">NodeSystemInfo v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nonresourceattributes-v1-authorization-k8s-io" class="nav-item">NonResourceAttributes v1 authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">NonResourcePolicyRule v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#nonresourcerule-v1-authorization-k8s-io" class="nav-item">NonResourceRule v1 authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#objectfieldselector-v1-core" class="nav-item">ObjectFieldSelector v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#objectmeta-v1-meta" class="nav-item">ObjectMeta v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#objectmetricsource-v2beta2-autoscaling" class="nav-item">ObjectMetricSource v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#objectmetricstatus-v2beta2-autoscaling" class="nav-item">ObjectMetricStatus v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#objectreference-v1-core" class="nav-item">ObjectReference v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#overhead-v1beta1-node-k8s-io" class="nav-item">Overhead v1beta1 node.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#ownerreference-v1-meta" class="nav-item">OwnerReference v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#patch-v1-meta" class="nav-item">Patch v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#persistentvolumeclaimcondition-v1-core" class="nav-item">PersistentVolumeClaimCondition v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#persistentvolumeclaimvolumesource-v1-core" class="nav-item">PersistentVolumeClaimVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#photonpersistentdiskvolumesource-v1-core" class="nav-item">PhotonPersistentDiskVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podaffinity-v1-core" class="nav-item">PodAffinity v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podaffinityterm-v1-core" class="nav-item">PodAffinityTerm v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podantiaffinity-v1-core" class="nav-item">PodAntiAffinity v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podcondition-v1-core" class="nav-item">PodCondition v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#poddnsconfig-v1-core" class="nav-item">PodDNSConfig v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#poddnsconfigoption-v1-core" class="nav-item">PodDNSConfigOption v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podip-v1-core" class="nav-item">PodIP v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podreadinessgate-v1-core" class="nav-item">PodReadinessGate v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podsecuritycontext-v1-core" class="nav-item">PodSecurityContext v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podsmetricsource-v2beta2-autoscaling" class="nav-item">PodsMetricSource v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#podsmetricstatus-v2beta2-autoscaling" class="nav-item">PodsMetricStatus v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#policy-v1alpha1-auditregistration-k8s-io" class="nav-item">Policy v1alpha1 auditregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#policyrule-v1-rbac-authorization-k8s-io" class="nav-item">PolicyRule v1 rbac.authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">PolicyRulesWithSubjects v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#portworxvolumesource-v1-core" class="nav-item">PortworxVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#preconditions-v1-meta" class="nav-item">Preconditions v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#preferredschedulingterm-v1-core" class="nav-item">PreferredSchedulingTerm v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">PriorityLevelConfigurationCondition v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">PriorityLevelConfigurationReference v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#probe-v1-core" class="nav-item">Probe v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#projectedvolumesource-v1-core" class="nav-item">ProjectedVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#quantity-resource-core" class="nav-item">Quantity resource core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">QueuingConfiguration v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#quobytevolumesource-v1-core" class="nav-item">QuobyteVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#rbdpersistentvolumesource-v1-core" class="nav-item">RBDPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#rbdvolumesource-v1-core" class="nav-item">RBDVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#replicasetcondition-v1-apps" class="nav-item">ReplicaSetCondition v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#replicationcontrollercondition-v1-core" class="nav-item">ReplicationControllerCondition v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourceattributes-v1-authorization-k8s-io" class="nav-item">ResourceAttributes v1 authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourcefieldselector-v1-core" class="nav-item">ResourceFieldSelector v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourcemetricsource-v2beta2-autoscaling" class="nav-item">ResourceMetricSource v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourcemetricstatus-v2beta2-autoscaling" class="nav-item">ResourceMetricStatus v2beta2 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">ResourcePolicyRule v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourcerequirements-v1-core" class="nav-item">ResourceRequirements v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#resourcerule-v1-authorization-k8s-io" class="nav-item">ResourceRule v1 authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#roleref-v1-rbac-authorization-k8s-io" class="nav-item">RoleRef v1 rbac.authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#rollingupdatestatefulsetstrategy-v1-apps" class="nav-item">RollingUpdateStatefulSetStrategy v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#rulewithoperations-v1-admissionregistration-k8s-io" class="nav-item">RuleWithOperations v1 admissionregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#runasgroupstrategyoptions-v1beta1-policy" class="nav-item">RunAsGroupStrategyOptions v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#runasuserstrategyoptions-v1beta1-policy" class="nav-item">RunAsUserStrategyOptions v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#runtimeclassstrategyoptions-v1beta1-policy" class="nav-item">RuntimeClassStrategyOptions v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#selinuxoptions-v1-core" class="nav-item">SELinuxOptions v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#selinuxstrategyoptions-v1beta1-policy" class="nav-item">SELinuxStrategyOptions v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#scale-v1-autoscaling" class="nav-item">Scale v1 autoscaling</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#scaleiopersistentvolumesource-v1-core" class="nav-item">ScaleIOPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#scaleiovolumesource-v1-core" class="nav-item">ScaleIOVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#scheduling-v1beta1-node-k8s-io" class="nav-item">Scheduling v1beta1 node.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#scopeselector-v1-core" class="nav-item">ScopeSelector v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#scopedresourceselectorrequirement-v1-core" class="nav-item">ScopedResourceSelectorRequirement v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#secretenvsource-v1-core" class="nav-item">SecretEnvSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#secretkeyselector-v1-core" class="nav-item">SecretKeySelector v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#secretprojection-v1-core" class="nav-item">SecretProjection v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#secretreference-v1-core" class="nav-item">SecretReference v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#secretvolumesource-v1-core" class="nav-item">SecretVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#securitycontext-v1-core" class="nav-item">SecurityContext v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#serveraddressbyclientcidr-v1-meta" class="nav-item">ServerAddressByClientCIDR v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">ServiceAccountSubject v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#serviceaccounttokenprojection-v1-core" class="nav-item">ServiceAccountTokenProjection v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#serviceport-v1-core" class="nav-item">ServicePort v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#servicereference-v1-admissionregistration-k8s-io" class="nav-item">ServiceReference v1 admissionregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#sessionaffinityconfig-v1-core" class="nav-item">SessionAffinityConfig v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#statefulsetcondition-v1-apps" class="nav-item">StatefulSetCondition v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#statefulsetupdatestrategy-v1-apps" class="nav-item">StatefulSetUpdateStrategy v1 apps</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#status-v1-meta" class="nav-item">Status v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#statuscause-v1-meta" class="nav-item">StatusCause v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#statusdetails-v1-meta" class="nav-item">StatusDetails v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#storageospersistentvolumesource-v1-core" class="nav-item">StorageOSPersistentVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#storageosvolumesource-v1-core" class="nav-item">StorageOSVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">Subject v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#subjectrulesreviewstatus-v1-authorization-k8s-io" class="nav-item">SubjectRulesReviewStatus v1 authorization.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#supplementalgroupsstrategyoptions-v1beta1-policy" class="nav-item">SupplementalGroupsStrategyOptions v1beta1 policy</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#sysctl-v1-core" class="nav-item">Sysctl v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#tcpsocketaction-v1-core" class="nav-item">TCPSocketAction v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#taint-v1-core" class="nav-item">Taint v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#time-v1-meta" class="nav-item">Time v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#toleration-v1-core" class="nav-item">Toleration v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#topologyselectorlabelrequirement-v1-core" class="nav-item">TopologySelectorLabelRequirement v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#topologyselectorterm-v1-core" class="nav-item">TopologySelectorTerm v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#topologyspreadconstraint-v1-core" class="nav-item">TopologySpreadConstraint v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#typedlocalobjectreference-v1-core" class="nav-item">TypedLocalObjectReference v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#userinfo-v1-authentication-k8s-io" class="nav-item">UserInfo v1 authentication.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#usersubject-v1alpha1-flowcontrol-apiserver-k8s-io" class="nav-item">UserSubject v1alpha1 flowcontrol.apiserver.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#validatingwebhook-v1-admissionregistration-k8s-io" class="nav-item">ValidatingWebhook v1 admissionregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumeattachmentsource-v1-storage-k8s-io" class="nav-item">VolumeAttachmentSource v1 storage.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumedevice-v1-core" class="nav-item">VolumeDevice v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumeerror-v1-storage-k8s-io" class="nav-item">VolumeError v1 storage.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumemount-v1-core" class="nav-item">VolumeMount v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumenodeaffinity-v1-core" class="nav-item">VolumeNodeAffinity v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumenoderesources-v1-storage-k8s-io" class="nav-item">VolumeNodeResources v1 storage.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#volumeprojection-v1-core" class="nav-item">VolumeProjection v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#vspherevirtualdiskvolumesource-v1-core" class="nav-item">VsphereVirtualDiskVolumeSource v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#watchevent-v1-meta" class="nav-item">WatchEvent v1 meta</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#webhook-v1alpha1-auditregistration-k8s-io" class="nav-item">Webhook v1alpha1 auditregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#webhookclientconfig-v1-admissionregistration-k8s-io" class="nav-item">WebhookClientConfig v1 admissionregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#webhookconversion-v1-apiextensions-k8s-io" class="nav-item">WebhookConversion v1 apiextensions.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#webhookthrottleconfig-v1alpha1-auditregistration-k8s-io" class="nav-item">WebhookThrottleConfig v1alpha1 auditregistration.k8s.io</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#weightedpodaffinityterm-v1-core" class="nav-item">WeightedPodAffinityTerm v1 core</A></LI>
- </UL>
-  <UL>
-   <LI class="nav-level-2"><A href="#windowssecuritycontextoptions-v1-core" class="nav-item">WindowsSecurityContextOptions v1 core</A></LI>
- </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1 strong-nav"><A href="#-strong-old-api-versions-strong-" class="nav-item"><STRONG>OLD API VERSIONS</STRONG></A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">APIService v1beta1 apiregistration.k8s.io</A></LI>
- <UL id="apiservice-v1beta1-apiregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-apiservice-v1beta1-apiregistration-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#apiservicecondition-v1beta1-apiregistration-k8s-io" class="nav-item">APIServiceCondition v1beta1 apiregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#aggregationrule-v1beta1-rbac-authorization-k8s-io" class="nav-item">AggregationRule v1beta1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#aggregationrule-v1alpha1-rbac-authorization-k8s-io" class="nav-item">AggregationRule v1alpha1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#csidriver-v1beta1-storage-k8s-io" class="nav-item">CSIDriver v1beta1 storage.k8s.io</A></LI>
- <UL id="csidriver-v1beta1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-csidriver-v1beta1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-csidriver-v1beta1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-csidriver-v1beta1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-csidriver-v1beta1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-csidriver-v1beta1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-csidriver-v1beta1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-csidriver-v1beta1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-csidriver-v1beta1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-csidriver-v1beta1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#csinode-v1beta1-storage-k8s-io" class="nav-item">CSINode v1beta1 storage.k8s.io</A></LI>
- <UL id="csinode-v1beta1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-csinode-v1beta1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-csinode-v1beta1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-csinode-v1beta1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-csinode-v1beta1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-csinode-v1beta1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-csinode-v1beta1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-csinode-v1beta1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-csinode-v1beta1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-csinode-v1beta1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#csinodedriver-v1beta1-storage-k8s-io" class="nav-item">CSINodeDriver v1beta1 storage.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">ClusterRole v1beta1 rbac.authorization.k8s.io</A></LI>
- <UL id="clusterrole-v1beta1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">ClusterRole v1alpha1 rbac.authorization.k8s.io</A></LI>
- <UL id="clusterrole-v1alpha1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">ClusterRoleBinding v1beta1 rbac.authorization.k8s.io</A></LI>
- <UL id="clusterrolebinding-v1beta1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">ClusterRoleBinding v1alpha1 rbac.authorization.k8s.io</A></LI>
- <UL id="clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#cronjob-v2alpha1-batch" class="nav-item">CronJob v2alpha1 batch</A></LI>
- <UL id="cronjob-v2alpha1-batch-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-cronjob-v2alpha1-batch-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-cronjob-v2alpha1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-cronjob-v2alpha1-batch" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-cronjob-v2alpha1-batch" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-cronjob-v2alpha1-batch" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-cronjob-v2alpha1-batch" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-cronjob-v2alpha1-batch" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-cronjob-v2alpha1-batch-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-cronjob-v2alpha1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-cronjob-v2alpha1-batch" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-cronjob-v2alpha1-batch" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-cronjob-v2alpha1-batch" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-cronjob-v2alpha1-batch" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-cronjob-v2alpha1-batch" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-cronjob-v2alpha1-batch" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-cronjob-v2alpha1-batch-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-cronjob-v2alpha1-batch-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-cronjob-v2alpha1-batch" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-cronjob-v2alpha1-batch" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-cronjob-v2alpha1-batch" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#crossversionobjectreference-v2beta2-autoscaling" class="nav-item">CrossVersionObjectReference v2beta2 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#crossversionobjectreference-v2beta1-autoscaling" class="nav-item">CrossVersionObjectReference v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcecolumndefinition-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceColumnDefinition v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourceconversion-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceConversion v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinition v1beta1 apiextensions.k8s.io</A></LI>
- <UL id="customresourcedefinition-v1beta1-apiextensions-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinitionCondition v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcedefinitionnames-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinitionNames v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcedefinitionversion-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceDefinitionVersion v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcesubresourcescale-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceSubresourceScale v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceSubresourceStatus v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcesubresources-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceSubresources v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#customresourcevalidation-v1beta1-apiextensions-k8s-io" class="nav-item">CustomResourceValidation v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#endpointport-v1beta1-discovery-k8s-io" class="nav-item">EndpointPort v1beta1 discovery.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#event-v1beta1-events-k8s-io" class="nav-item">Event v1beta1 events.k8s.io</A></LI>
- <UL id="event-v1beta1-events-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-event-v1beta1-events-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-event-v1beta1-events-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-event-v1beta1-events-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-event-v1beta1-events-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-event-v1beta1-events-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-event-v1beta1-events-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-event-v1beta1-events-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-event-v1beta1-events-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-event-v1beta1-events-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-event-v1beta1-events-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-event-v1beta1-events-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-event-v1beta1-events-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-event-v1beta1-events-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-event-v1beta1-events-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-event-v1beta1-events-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#eventseries-v1beta1-events-k8s-io" class="nav-item">EventSeries v1beta1 events.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#externaldocumentation-v1beta1-apiextensions-k8s-io" class="nav-item">ExternalDocumentation v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#externalmetricsource-v2beta1-autoscaling" class="nav-item">ExternalMetricSource v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#externalmetricstatus-v2beta1-autoscaling" class="nav-item">ExternalMetricStatus v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#httpingresspath-v1beta1-extensions" class="nav-item">HTTPIngressPath v1beta1 extensions</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#httpingressrulevalue-v1beta1-extensions" class="nav-item">HTTPIngressRuleValue v1beta1 extensions</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">HorizontalPodAutoscaler v2beta2 autoscaling</A></LI>
- <UL id="horizontalpodautoscaler-v2beta2-autoscaling-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-horizontalpodautoscaler-v2beta2-autoscaling" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">HorizontalPodAutoscaler v2beta1 autoscaling</A></LI>
- <UL id="horizontalpodautoscaler-v2beta1-autoscaling-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-horizontalpodautoscaler-v2beta1-autoscaling" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#horizontalpodautoscalercondition-v2beta1-autoscaling" class="nav-item">HorizontalPodAutoscalerCondition v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#ingress-v1beta1-extensions" class="nav-item">Ingress v1beta1 extensions</A></LI>
- <UL id="ingress-v1beta1-extensions-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-ingress-v1beta1-extensions-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-ingress-v1beta1-extensions-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-ingress-v1beta1-extensions" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-ingress-v1beta1-extensions" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-ingress-v1beta1-extensions" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-ingress-v1beta1-extensions" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-ingress-v1beta1-extensions" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-ingress-v1beta1-extensions-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-ingress-v1beta1-extensions-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-ingress-v1beta1-extensions" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-ingress-v1beta1-extensions" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-ingress-v1beta1-extensions" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-ingress-v1beta1-extensions" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-ingress-v1beta1-extensions" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-ingress-v1beta1-extensions" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-status-operations-ingress-v1beta1-extensions-strong-" class="nav-item"><STRONG>Status Operations</STRONG></A></LI>
-   <UL id="-strong-status-operations-ingress-v1beta1-extensions-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#patch-status-ingress-v1beta1-extensions" class="nav-item">Patch Status</A></LI>
-    <LI class="nav-level-2"><A href="#read-status-ingress-v1beta1-extensions" class="nav-item">Read Status</A></LI>
-    <LI class="nav-level-2"><A href="#replace-status-ingress-v1beta1-extensions" class="nav-item">Replace Status</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#ingressbackend-v1beta1-extensions" class="nav-item">IngressBackend v1beta1 extensions</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#ingressrule-v1beta1-extensions" class="nav-item">IngressRule v1beta1 extensions</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#ingresstls-v1beta1-extensions" class="nav-item">IngressTLS v1beta1 extensions</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#json-v1beta1-apiextensions-k8s-io" class="nav-item">JSON v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#jsonschemaprops-v1beta1-apiextensions-k8s-io" class="nav-item">JSONSchemaProps v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#jsonschemapropsorarray-v1beta1-apiextensions-k8s-io" class="nav-item">JSONSchemaPropsOrArray v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#jsonschemapropsorbool-v1beta1-apiextensions-k8s-io" class="nav-item">JSONSchemaPropsOrBool v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#jobtemplatespec-v2alpha1-batch" class="nav-item">JobTemplateSpec v2alpha1 batch</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#lease-v1beta1-coordination-k8s-io" class="nav-item">Lease v1beta1 coordination.k8s.io</A></LI>
- <UL id="lease-v1beta1-coordination-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-lease-v1beta1-coordination-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-lease-v1beta1-coordination-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-lease-v1beta1-coordination-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-lease-v1beta1-coordination-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-lease-v1beta1-coordination-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-lease-v1beta1-coordination-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-lease-v1beta1-coordination-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-lease-v1beta1-coordination-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-lease-v1beta1-coordination-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-lease-v1beta1-coordination-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#localsubjectaccessreview-v1beta1-authorization-k8s-io" class="nav-item">LocalSubjectAccessReview v1beta1 authorization.k8s.io</A></LI>
- <UL id="localsubjectaccessreview-v1beta1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-localsubjectaccessreview-v1beta1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#metricspec-v2beta1-autoscaling" class="nav-item">MetricSpec v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#metricstatus-v2beta1-autoscaling" class="nav-item">MetricStatus v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#mutatingwebhook-v1beta1-admissionregistration-k8s-io" class="nav-item">MutatingWebhook v1beta1 admissionregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">MutatingWebhookConfiguration v1beta1 admissionregistration.k8s.io</A></LI>
- <UL id="mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#nonresourceattributes-v1beta1-authorization-k8s-io" class="nav-item">NonResourceAttributes v1beta1 authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#nonresourcerule-v1beta1-authorization-k8s-io" class="nav-item">NonResourceRule v1beta1 authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#objectmetricsource-v2beta1-autoscaling" class="nav-item">ObjectMetricSource v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#objectmetricstatus-v2beta1-autoscaling" class="nav-item">ObjectMetricStatus v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#overhead-v1alpha1-node-k8s-io" class="nav-item">Overhead v1alpha1 node.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#podsmetricsource-v2beta1-autoscaling" class="nav-item">PodsMetricSource v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#podsmetricstatus-v2beta1-autoscaling" class="nav-item">PodsMetricStatus v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#policyrule-v1beta1-rbac-authorization-k8s-io" class="nav-item">PolicyRule v1beta1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#policyrule-v1alpha1-rbac-authorization-k8s-io" class="nav-item">PolicyRule v1alpha1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">PriorityClass v1beta1 scheduling.k8s.io</A></LI>
- <UL id="priorityclass-v1beta1-scheduling-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-priorityclass-v1beta1-scheduling-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">PriorityClass v1alpha1 scheduling.k8s.io</A></LI>
- <UL id="priorityclass-v1alpha1-scheduling-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-priorityclass-v1alpha1-scheduling-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#resourceattributes-v1beta1-authorization-k8s-io" class="nav-item">ResourceAttributes v1beta1 authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#resourcemetricsource-v2beta1-autoscaling" class="nav-item">ResourceMetricSource v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#resourcemetricstatus-v2beta1-autoscaling" class="nav-item">ResourceMetricStatus v2beta1 autoscaling</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#resourcerule-v1beta1-authorization-k8s-io" class="nav-item">ResourceRule v1beta1 authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Role v1beta1 rbac.authorization.k8s.io</A></LI>
- <UL id="role-v1beta1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Role v1alpha1 rbac.authorization.k8s.io</A></LI>
- <UL id="role-v1alpha1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">RoleBinding v1beta1 rbac.authorization.k8s.io</A></LI>
- <UL id="rolebinding-v1beta1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">RoleBinding v1alpha1 rbac.authorization.k8s.io</A></LI>
- <UL id="rolebinding-v1alpha1-rbac-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">List All Namespaces</A></LI>
-    <LI class="nav-level-2"><A href="#watch-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Watch List All Namespaces</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#roleref-v1beta1-rbac-authorization-k8s-io" class="nav-item">RoleRef v1beta1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#roleref-v1alpha1-rbac-authorization-k8s-io" class="nav-item">RoleRef v1alpha1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#rulewithoperations-v1beta1-admissionregistration-k8s-io" class="nav-item">RuleWithOperations v1beta1 admissionregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#runtimeclass-v1alpha1-node-k8s-io" class="nav-item">RuntimeClass v1alpha1 node.k8s.io</A></LI>
- <UL id="runtimeclass-v1alpha1-node-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-runtimeclass-v1alpha1-node-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#scheduling-v1alpha1-node-k8s-io" class="nav-item">Scheduling v1alpha1 node.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io" class="nav-item">SelfSubjectAccessReview v1beta1 authorization.k8s.io</A></LI>
- <UL id="selfsubjectaccessreview-v1beta1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-selfsubjectaccessreview-v1beta1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io" class="nav-item">SelfSubjectRulesReview v1beta1 authorization.k8s.io</A></LI>
- <UL id="selfsubjectrulesreview-v1beta1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-selfsubjectrulesreview-v1beta1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#servicereference-v1-apiextensions-k8s-io" class="nav-item">ServiceReference v1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#servicereference-v1-apiregistration-k8s-io" class="nav-item">ServiceReference v1 apiregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#servicereference-v1beta1-admissionregistration-k8s-io" class="nav-item">ServiceReference v1beta1 admissionregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#servicereference-v1beta1-apiextensions-k8s-io" class="nav-item">ServiceReference v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#servicereference-v1beta1-apiregistration-k8s-io" class="nav-item">ServiceReference v1beta1 apiregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#servicereference-v1alpha1-auditregistration-k8s-io" class="nav-item">ServiceReference v1alpha1 auditregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#storageclass-v1beta1-storage-k8s-io" class="nav-item">StorageClass v1beta1 storage.k8s.io</A></LI>
- <UL id="storageclass-v1beta1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-storageclass-v1beta1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-storageclass-v1beta1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-storageclass-v1beta1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-storageclass-v1beta1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-storageclass-v1beta1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-storageclass-v1beta1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-storageclass-v1beta1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-storageclass-v1beta1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-storageclass-v1beta1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#subject-v1-rbac-authorization-k8s-io" class="nav-item">Subject v1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#subject-v1beta1-rbac-authorization-k8s-io" class="nav-item">Subject v1beta1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#subject-v1alpha1-rbac-authorization-k8s-io" class="nav-item">Subject v1alpha1 rbac.authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#subjectaccessreview-v1beta1-authorization-k8s-io" class="nav-item">SubjectAccessReview v1beta1 authorization.k8s.io</A></LI>
- <UL id="subjectaccessreview-v1beta1-authorization-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-subjectaccessreview-v1beta1-authorization-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#subjectrulesreviewstatus-v1beta1-authorization-k8s-io" class="nav-item">SubjectRulesReviewStatus v1beta1 authorization.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#tokenreview-v1beta1-authentication-k8s-io" class="nav-item">TokenReview v1beta1 authentication.k8s.io</A></LI>
- <UL id="tokenreview-v1beta1-authentication-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-tokenreview-v1beta1-authentication-k8s-io" class="nav-item">Create</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#userinfo-v1beta1-authentication-k8s-io" class="nav-item">UserInfo v1beta1 authentication.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#validatingwebhook-v1beta1-admissionregistration-k8s-io" class="nav-item">ValidatingWebhook v1beta1 admissionregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">ValidatingWebhookConfiguration v1beta1 admissionregistration.k8s.io</A></LI>
- <UL id="validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeattachment-v1beta1-storage-k8s-io" class="nav-item">VolumeAttachment v1beta1 storage.k8s.io</A></LI>
- <UL id="volumeattachment-v1beta1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-volumeattachment-v1beta1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">VolumeAttachment v1alpha1 storage.k8s.io</A></LI>
- <UL id="volumeattachment-v1alpha1-storage-k8s-io-nav" style="display: none;">
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-" class="nav-item"><STRONG>Write Operations</STRONG></A></LI>
-   <UL id="-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#create-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Create</A></LI>
-    <LI class="nav-level-2"><A href="#patch-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Patch</A></LI>
-    <LI class="nav-level-2"><A href="#replace-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Replace</A></LI>
-    <LI class="nav-level-2"><A href="#delete-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Delete</A></LI>
-    <LI class="nav-level-2"><A href="#delete-collection-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Delete Collection</A></LI>
-   </UL>
-  </UL>
-  <UL>
-   <LI class="nav-level-2 strong-nav"><A href="#-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-" class="nav-item"><STRONG>Read Operations</STRONG></A></LI>
-   <UL id="-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong--nav" style="display: none;">
-    <LI class="nav-level-2"><A href="#read-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Read</A></LI>
-    <LI class="nav-level-2"><A href="#list-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">List</A></LI>
-    <LI class="nav-level-2"><A href="#watch-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Watch</A></LI>
-    <LI class="nav-level-2"><A href="#watch-list-volumeattachment-v1alpha1-storage-k8s-io" class="nav-item">Watch List</A></LI>
-   </UL>
-  </UL>
- </UL>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeattachmentsource-v1beta1-storage-k8s-io" class="nav-item">VolumeAttachmentSource v1beta1 storage.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeattachmentsource-v1alpha1-storage-k8s-io" class="nav-item">VolumeAttachmentSource v1alpha1 storage.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeerror-v1beta1-storage-k8s-io" class="nav-item">VolumeError v1beta1 storage.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumeerror-v1alpha1-storage-k8s-io" class="nav-item">VolumeError v1alpha1 storage.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#volumenoderesources-v1beta1-storage-k8s-io" class="nav-item">VolumeNodeResources v1beta1 storage.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#webhookclientconfig-v1-apiextensions-k8s-io" class="nav-item">WebhookClientConfig v1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io" class="nav-item">WebhookClientConfig v1beta1 admissionregistration.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#webhookclientconfig-v1beta1-apiextensions-k8s-io" class="nav-item">WebhookClientConfig v1beta1 apiextensions.k8s.io</A></LI>
-</UL>
-<UL>
- <LI class="nav-level-1"><A href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io" class="nav-item">WebhookClientConfig v1alpha1 auditregistration.k8s.io</A></LI>
-</UL>
-</DIV>
-<DIV id="page-content-wrapper" class="col-xs-8 offset-xs-4 col-sm-9 offset-sm-3 col-md-10 offset-md-2 body-content">
-<DIV class="row">
-  <DIV class="col-md-6 copyright">
- <a href="https://github.com/kubernetes/kubernetes">Copyright 2016-2020 The Kubernetes Authors.</a>
-  </DIV>
-  <DIV class="col-md-6 text-right">
-    <DIV>Generated at: 2020-04-13 17:38:34 (EDT)</DIV>
-    <DIV>API Version: <a href="https://github.com/kubernetes/kubernetes/blob/release-1.18/api/openapi-spec/swagger.json">v1.18.0</a></DIV>
-  </DIV>
-</DIV><H1 id="-strong-api-overview-strong-"><STRONG>API OVERVIEW</STRONG></H1>
-
-<P>Welcome to the Kubernetes API.  You can use the Kubernetes API to read
-and write Kubernetes resource objects via a Kubernetes API endpoint.</P>
-
-<H2 id="resource-categories">Resource Categories</H2>
-
-<P>This is a high-level overview of the basic types of resources provide by the Kubernetes API and their primary functions.</P>
-<P><B>Workloads</B> are objects you use to manage and run your containers on the cluster.</P>
-<P><B>Discovery &amp; LB</B> resources are objects you use to "stitch" your workloads together into an externally accessible, load-balanced Service.</P>
-<P><B>Config &amp; Storage</B> resources are objects you use to inject initialization data into your applications, and to persist data that is external to your container.</P>
-<P><B>Cluster</B> resources objects define how the cluster itself is configured; these are typically used only by cluster operators.</P>
-<P><B>Metadata</B> resources are objects you use to configure the behavior of other resources within the cluster, such as <code>HorizontalPodAutoscaler</code> for scaling workloads.</P>
-
-<HR />
-
-<H2 id="resource-objects">Resource Objects</H2>
-
-<P>Resource objects typically have 3 components:</P>
-<UL>
-<LI><B>Resource ObjectMeta</B>: This is metadata about the resource, such as its name, type, api version, annotations, and labels.  This contains
-fields that maybe updated both by the end user and the system (e.g. annotations).</LI>
-<LI><B>ResourceSpec</B>: This is defined by the user and describes the desired state of system.  Fill this in when creating or updating an object.</LI>
-<LI><B>ResourceStatus</B>: This is filled in by the server and reports the current state of the system.  In most cases, users don't need to change this.</LI>
-</UL>
-
-<HR />
-
-<H2 id="resource-operations">Resource Operations</H2>
-
-<P>Most resources provide the following Operations:</P>
-
-<H4 id="resource-operations-create">Create</H4>
-
-<P>Create operations will create the resource in the storage backend.  After a resource is create the system will apply
-the desired state.</P>
-
-<H4 id="resource-operations-update">Update</H4>
-
-<P>Updates come in 2 forms: <B>Replace</B> and <B>Patch</B>:
-
-<UL>
-<LI><B>Replace</B>:
-Replacing a resource object will update the resource by replacing the existing spec with the provided one.  For
-read-then-write operations this is safe because an optimistic lock failure will occur if the resource was modified
-between the read and write. <I>Note</I>: The <I>ResourceStatus</I> will be ignored by the system and will not be updated.
-To update the status, one must invoke the specific status update operation.<BR />
-
-Note: Replacing a resource object may not result immediately in changes being propagated to downstream objects.  For instance
-replacing a <CODE>ConfigMap</CODE> or <CODE>Secret</CODE> resource will not result in all <I>Pod</I>s seeing the changes unless the <I>Pod</I>s are
-restarted out of band.</P></LI>
-
-<LI><B>Patch</B>:
-Patch will apply a change to a specific field.  How the change is merged is defined per field.  Lists may either be
-replaced or merged.  Merging lists will not preserve ordering.<BR />
-
-<B>Patches will never cause optimistic locking failures, and the last write will win.</B>  Patches are recommended
-when the full state is not read before an update, or when failing on optimistic locking is undesirable. <I>When patching
-complex types, arrays and maps, how the patch is applied is defined on a per-field basis and may either replace
-the field's current value, or merge the contents into the current value.</I></LI>
-</UL>
-
-<H4 id="resource-operations-read">Read</H4>
-
-<P>Reads come in 3 forms: <B>Get</B>, <B>List</B> and <B>Watch</B>:<P>
-
-<UL>
-<LI><B>Get</B>: Get will retrieve a specific resource object by name.</LI>
-<LI><B>List</B>: List will retrieve all resource objects of a specific type within a namespace, and the results can be restricted to resources matching a selector query.<BR />
-<B>List All Namespaces</B>: Like <B>List</B> but retrieves resources across all namespaces.</LI>
-<LI><B>Watch</B>: Watch will stream results for an object(s) as it is updated.  Similar to a callback, watch is used to respond to resource changes.</LI>
-</UL>
-
-<H4 id="resource-operations-read">Delete</H4>
-
-<P>Delete will delete a resource.  Depending on the specific resource, child objects may or may not be garbage collected by the server.  See
-notes on specific resource objects for details.</P>
-
-<H4 id="resource-operations-additional">Additional Operations</H4>
-
-<P>Resources may define additional operations specific to that resource type.</P>
-
-<UL>
-	<LI><B>Rollback</B>: Rollback a PodTemplate to a previous version.  Only available for some resource types.</LI>
-	<LI><B>Read / Write Scale</B>: Read or Update the number of replicas for the given resource.  Only available for some resource types.</LI>
-	<LI><B>Read / Write Status</B>: Read or Update the Status for a resource object.  The Status can only changed through these update operations.</LI>
-</UL>
-<HR />
-<H1 id="-strong-workloads-apis-strong-"><STRONG>WORKLOADS</STRONG></H1>
-
-<P>Workloads resources are responsible for managing and running your containers on the cluster. <A href="#container-v1-core">Containers</A> are created
-by Controllers through <A href="#pod-v1-core">Pods</A>. Pods run Containers and provide environmental dependencies such as shared or
-persistent storage <A href="#volume-v1-core">Volumes</A> and <A href="#configmap-v1-core">Configuration</A> or <A href="#secret-v1-core">Secret</A>
-data injected into the container.</P>
-
-<P>The most common Controllers are:</P>
-<UL>
-<LI><A href="#deployment-v1-apps">Deployments</A> for stateless persistent apps (e.g. HTTP servers).</LI>
-<LI><A href="#statefulset-v1-apps">StatefulSets</A> for stateful persistent apps (e.g. databases).</LI>
-<LI><A href="#job-v1-batch">Jobs</A> for run-to-completion apps (e.g. batch Jobs).</LI>
-</UL>
-
-<HR />
-<H1 id="container-v1-core">Container v1 core</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-container-v1-core" aria-controls="example-container-v1-core"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-container-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Container Config to run nginx (must be embedded in a PodSpec to run).</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-name: nginx
-# Run the nginx:1.14 image
-image: nginx:1.14
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Container</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-warning col-md-8"><P><I class="fa fa-warning"></I> <B>Warning:</B></P><P>Containers are only ever created within the context of a <a href="#pod-v1-core">Pod</a>.  This is usually done using a Controller.  See Controllers: <a href="#deployment-v1-apps">Deployment</a>, <a href="#job-v1-batch">Job</a>, or <a href="#statefulset-v1-apps">StatefulSet</a></P></DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>args</CODE><BR /><I>string array</I></TD><TD>Arguments to the entrypoint. The docker image&#39;s CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container&#39;s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell</TD></TR>
-<TR><TD><CODE>command</CODE><BR /><I>string array</I></TD><TD>Entrypoint array. Not executed within a shell. The docker image&#39;s ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container&#39;s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell</TD></TR>
-<TR><TD><CODE>env</CODE><BR /><I><a href="#envvar-v1-core">EnvVar</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>List of environment variables to set in the container. Cannot be updated.</TD></TR>
-<TR><TD><CODE>envFrom</CODE><BR /><I><a href="#envfromsource-v1-core">EnvFromSource</a> array</I></TD><TD>List of sources to populate environment variables in the container. The keys defined within a source must be a C_IDENTIFIER. All invalid keys will be reported as an event when the container is starting. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated.</TD></TR>
-<TR><TD><CODE>image</CODE><BR /><I>string</I></TD><TD>Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images This field is optional to allow higher level config management to default or override container images in workload controllers like Deployments and StatefulSets.</TD></TR>
-<TR><TD><CODE>imagePullPolicy</CODE><BR /><I>string</I></TD><TD>Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images</TD></TR>
-<TR><TD><CODE>lifecycle</CODE><BR /><I><a href="#lifecycle-v1-core">Lifecycle</a></I></TD><TD>Actions that the management system should take in response to container lifecycle events. Cannot be updated.</TD></TR>
-<TR><TD><CODE>livenessProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the container specified as a DNS_LABEL. Each container in a pod must have a unique name (DNS_LABEL). Cannot be updated.</TD></TR>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#containerport-v1-core">ContainerPort</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>containerPort</I></TD><TD>List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default &#34;0.0.0.0&#34; address inside a container will be accessible from the network. Cannot be updated.</TD></TR>
-<TR><TD><CODE>readinessProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I><a href="#resourcerequirements-v1-core">ResourceRequirements</a></I></TD><TD>Compute Resources required by this container. Cannot be updated. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/</TD></TR>
-<TR><TD><CODE>securityContext</CODE><BR /><I><a href="#securitycontext-v1-core">SecurityContext</a></I></TD><TD>Security options the pod should run with. More info: https://kubernetes.io/docs/concepts/policy/security-context/ More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/</TD></TR>
-<TR><TD><CODE>startupProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod&#39;s lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. This is a beta feature enabled by the StartupProbe feature flag. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
-<TR><TD><CODE>stdin</CODE><BR /><I>boolean</I></TD><TD>Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false.</TD></TR>
-<TR><TD><CODE>stdinOnce</CODE><BR /><I>boolean</I></TD><TD>Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false</TD></TR>
-<TR><TD><CODE>terminationMessagePath</CODE><BR /><I>string</I></TD><TD>Optional: Path at which the file to which the container&#39;s termination message will be written is mounted into the container&#39;s filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated.</TD></TR>
-<TR><TD><CODE>terminationMessagePolicy</CODE><BR /><I>string</I></TD><TD>Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated.</TD></TR>
-<TR><TD><CODE>tty</CODE><BR /><I>boolean</I></TD><TD>Whether this container should allocate a TTY for itself, also requires &#39;stdin&#39; to be true. Default is false.</TD></TR>
-<TR><TD><CODE>volumeDevices</CODE><BR /><I><a href="#volumedevice-v1-core">VolumeDevice</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>devicePath</I></TD><TD>volumeDevices is the list of block devices to be used by the container.</TD></TR>
-<TR><TD><CODE>volumeMounts</CODE><BR /><I><a href="#volumemount-v1-core">VolumeMount</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>mountPath</I></TD><TD>Pod volumes to mount into the container&#39;s filesystem. Cannot be updated.</TD></TR>
-<TR><TD><CODE>workingDir</CODE><BR /><I>string</I></TD><TD>Container&#39;s working directory. If not specified, the container runtime&#39;s default will be used, which might be configured in the container image. Cannot be updated.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="containerstatus-v1-core">ContainerStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podstatus-v1-core">PodStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>containerID</CODE><BR /><I>string</I></TD><TD>Container&#39;s ID in the format &#39;docker://&lt;container_id&gt;&#39;.</TD></TR>
-<TR><TD><CODE>image</CODE><BR /><I>string</I></TD><TD>The image the container is running. More info: https://kubernetes.io/docs/concepts/containers/images</TD></TR>
-<TR><TD><CODE>imageID</CODE><BR /><I>string</I></TD><TD>ImageID of the container&#39;s image.</TD></TR>
-<TR><TD><CODE>lastState</CODE><BR /><I><a href="#containerstate-v1-core">ContainerState</a></I></TD><TD>Details about the container&#39;s last termination condition.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>This must be a DNS_LABEL. Each container in a pod must have a unique name. Cannot be updated.</TD></TR>
-<TR><TD><CODE>ready</CODE><BR /><I>boolean</I></TD><TD>Specifies whether the container has passed its readiness probe.</TD></TR>
-<TR><TD><CODE>restartCount</CODE><BR /><I>integer</I></TD><TD>The number of times the container has been restarted, currently based on the number of dead containers that have not yet been removed. Note that this is calculated from dead containers. But those containers are subject to garbage collection. This value will get capped at 5 by GC.</TD></TR>
-<TR><TD><CODE>started</CODE><BR /><I>boolean</I></TD><TD>Specifies whether the container has passed its startup probe. Initialized as false, becomes true after startupProbe is considered successful. Resets to false when the container is restarted, or if kubelet loses state temporarily. Is always true when no startupProbe is defined.</TD></TR>
-<TR><TD><CODE>state</CODE><BR /><I><a href="#containerstate-v1-core">ContainerState</a></I></TD><TD>Details about the container&#39;s current condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="cronjob-v1beta1-batch">CronJob v1beta1 batch</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>batch</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CronJob</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#cronjob-v2alpha1-batch">v2alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjoblist-v1beta1-batch">CronJobList [batch/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#cronjobspec-v1beta1-batch">CronJobSpec</a></I></TD><TD>Specification of the desired behavior of a cron job, including the schedule. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#cronjobstatus-v1beta1-batch">CronJobStatus</a></I></TD><TD>Current status of a cron job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="cronjobspec-v1beta1-batch">CronJobSpec v1beta1 batch</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjob-v1beta1-batch">CronJob [batch/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>concurrencyPolicy</CODE><BR /><I>string</I></TD><TD>Specifies how to treat concurrent executions of a Job. Valid values are: - &#34;Allow&#34; (default): allows CronJobs to run concurrently; - &#34;Forbid&#34;: forbids concurrent runs, skipping next run if previous run hasn&#39;t finished yet; - &#34;Replace&#34;: cancels currently running job and replaces it with a new one</TD></TR>
-<TR><TD><CODE>failedJobsHistoryLimit</CODE><BR /><I>integer</I></TD><TD>The number of failed finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1.</TD></TR>
-<TR><TD><CODE>jobTemplate</CODE><BR /><I><a href="#jobtemplatespec-v1beta1-batch">JobTemplateSpec</a></I></TD><TD>Specifies the job that will be created when executing a CronJob.</TD></TR>
-<TR><TD><CODE>schedule</CODE><BR /><I>string</I></TD><TD>The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.</TD></TR>
-<TR><TD><CODE>startingDeadlineSeconds</CODE><BR /><I>integer</I></TD><TD>Optional deadline in seconds for starting the job if it misses scheduled time for any reason.  Missed jobs executions will be counted as failed ones.</TD></TR>
-<TR><TD><CODE>successfulJobsHistoryLimit</CODE><BR /><I>integer</I></TD><TD>The number of successful finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified. Defaults to 3.</TD></TR>
-<TR><TD><CODE>suspend</CODE><BR /><I>boolean</I></TD><TD>This flag tells the controller to suspend subsequent executions, it does not apply to already started executions.  Defaults to false.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="cronjobstatus-v1beta1-batch">CronJobStatus v1beta1 batch</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjob-v1beta1-batch">CronJob [batch/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>active</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a> array</I></TD><TD>A list of pointers to currently running jobs.</TD></TR>
-<TR><TD><CODE>lastScheduleTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Information when was the last time the job was successfully scheduled.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="cronjoblist-v1beta1-batch">CronJobList v1beta1 batch</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#cronjob-v1beta1-batch">CronJob</a> array</I></TD><TD>items is the list of CronJobs.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-cronjob-v1beta1-batch-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-cronjob-v1beta1-batch">Create</H2>
-<P>create a CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-cronjob-v1beta1-batch">Patch</H2>
-<P>partially update the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-cronjob-v1beta1-batch">Replace</H2>
-<P>replace the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-cronjob-v1beta1-batch">Delete</H2>
-<P>delete a CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-cronjob-v1beta1-batch">Delete Collection</H2>
-<P>delete collection of CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/batch/v1beta1/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-cronjob-v1beta1-batch-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-cronjob-v1beta1-batch">Read</H2>
-<P>read the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-cronjob-v1beta1-batch">List</H2>
-<P>list or watch objects of kind CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjoblist-v1beta1-batch">CronJobList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-cronjob-v1beta1-batch">List All Namespaces</H2>
-<P>list or watch objects of kind CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/cronjobs</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjoblist-v1beta1-batch">CronJobList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-cronjob-v1beta1-batch">Watch</H2>
-<P>watch changes to an object of kind CronJob. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/watch/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-cronjob-v1beta1-batch">Watch List</H2>
-<P>watch individual changes to a list of CronJob. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/watch/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-cronjob-v1beta1-batch">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of CronJob. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/watch/cronjobs</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-cronjob-v1beta1-batch-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-cronjob-v1beta1-batch">Patch Status</H2>
-<P>partially update status of the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-cronjob-v1beta1-batch">Read Status</H2>
-<P>read status of the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-cronjob-v1beta1-batch">Replace Status</H2>
-<P>replace status of the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#cronjob-v1beta1-batch">CronJob</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="daemonset-v1-apps">DaemonSet v1 apps</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-daemonset-v1-apps" aria-controls="example-daemonset-v1-apps"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">DaemonSet Config to print the `hostname` on each Node in the cluster every 10 seconds.</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  # Unique key of the DaemonSet instance
-  name: daemonset-example
-spec:
-  selector:
-    matchLabels:
-      app: daemonset-example
-  template:
-    metadata:
-      labels:
-        app: daemonset-example
-    spec:
-      containers:
-      # This container is run once on each Node in the cluster
-      - name: daemonset-example
-        image: ubuntu:trusty
-        command:
-        - /bin/sh
-        args:
-        - -c
-        # This script is run through `sh -c &lt;script&gt;`
-        - &gt;-
-          while [ true ]; do
-          echo &#34;DaemonSet running on $(hostname)&#34; ;
-          sleep 10 ;
-          done
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DaemonSet</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonsetlist-v1-apps">DaemonSetList [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#daemonsetspec-v1-apps">DaemonSetSpec</a></I></TD><TD>The desired behavior of this daemon set. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#daemonsetstatus-v1-apps">DaemonSetStatus</a></I></TD><TD>The current status of this daemon set. This data may be out of date by some window of time. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="daemonsetspec-v1-apps">DaemonSetSpec v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonset-v1-apps">DaemonSet [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>minReadySeconds</CODE><BR /><I>integer</I></TD><TD>The minimum number of seconds for which a newly created DaemonSet pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready).</TD></TR>
-<TR><TD><CODE>revisionHistoryLimit</CODE><BR /><I>integer</I></TD><TD>The number of old history to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>A label query over pods that are managed by the daemon set. Must match in order to be controlled. It must match the pod template&#39;s labels. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>An object that describes the pod that will be created. The DaemonSet will create exactly one copy of this pod on every node that matches the template&#39;s node selector (or on every node if no node selector is specified). More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template</TD></TR>
-<TR><TD><CODE>updateStrategy</CODE><BR /><I><a href="#daemonsetupdatestrategy-v1-apps">DaemonSetUpdateStrategy</a></I></TD><TD>An update strategy to replace existing DaemonSet pods with new pods.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="daemonsetstatus-v1-apps">DaemonSetStatus v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonset-v1-apps">DaemonSet [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>collisionCount</CODE><BR /><I>integer</I></TD><TD>Count of hash collisions for the DaemonSet. The DaemonSet controller uses this field as a collision avoidance mechanism when it needs to create the name for the newest ControllerRevision.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#daemonsetcondition-v1-apps">DaemonSetCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Represents the latest available observations of a DaemonSet&#39;s current state.</TD></TR>
-<TR><TD><CODE>currentNumberScheduled</CODE><BR /><I>integer</I></TD><TD>The number of nodes that are running at least 1 daemon pod and are supposed to run the daemon pod. More info: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/</TD></TR>
-<TR><TD><CODE>desiredNumberScheduled</CODE><BR /><I>integer</I></TD><TD>The total number of nodes that should be running the daemon pod (including nodes correctly running the daemon pod). More info: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/</TD></TR>
-<TR><TD><CODE>numberAvailable</CODE><BR /><I>integer</I></TD><TD>The number of nodes that should be running the daemon pod and have one or more of the daemon pod running and available (ready for at least spec.minReadySeconds)</TD></TR>
-<TR><TD><CODE>numberMisscheduled</CODE><BR /><I>integer</I></TD><TD>The number of nodes that are running the daemon pod, but are not supposed to run the daemon pod. More info: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/</TD></TR>
-<TR><TD><CODE>numberReady</CODE><BR /><I>integer</I></TD><TD>The number of nodes that should be running the daemon pod and have one or more of the daemon pod running and ready.</TD></TR>
-<TR><TD><CODE>numberUnavailable</CODE><BR /><I>integer</I></TD><TD>The number of nodes that should be running the daemon pod and have none of the daemon pod running and available (ready for at least spec.minReadySeconds)</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>The most recent generation observed by the daemon set controller.</TD></TR>
-<TR><TD><CODE>updatedNumberScheduled</CODE><BR /><I>integer</I></TD><TD>The total number of nodes that are running updated daemon pod</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="daemonsetlist-v1-apps">DaemonSetList v1 apps</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#daemonset-v1-apps">DaemonSet</a> array</I></TD><TD>A list of daemon sets.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rollingupdatedaemonset-v1-apps">RollingUpdateDaemonSet v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonsetupdatestrategy-v1-apps">DaemonSetUpdateStrategy [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>maxUnavailable</CODE></TD><TD>The maximum number of DaemonSet pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of total number of DaemonSet pods at the start of the update (ex: 10%). Absolute number is calculated from percentage by rounding up. This cannot be 0. Default value is 1. Example: when this is set to 30%, at most 30% of the total number of nodes that should be running the daemon pod (i.e. status.desiredNumberScheduled) can have their pods stopped for an update at any given time. The update starts by stopping at most 30% of those DaemonSet pods and then brings up new DaemonSet pods in their place. Once the new pods are available, it then proceeds onto other DaemonSet pods, thus ensuring that at least 70% of original number of DaemonSet pods are available at all times during the update.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-daemonset-v1-apps-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-daemonset-v1-apps">Create</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-create-daemonset-v1-apps" aria-controls="req-kubectl-create-daemonset-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-create-daemonset-v1-apps" aria-controls="req-curl-create-daemonset-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-create-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ echo 'apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  name: daemonset-example
-spec:
-  selector:
-    matchLabels:
-      app: daemonset-example
-  template:
-    metadata:
-      labels:
-        app: daemonset-example
-    spec:
-      containers:
-      - name: daemonset-example
-        image: ubuntu:trusty
-        command:
-        - /bin/sh
-        args:
-        - -c
-        - >-
-          while [ true ]; do
-          echo "DaemonSet running on $(hostname)" ;
-          sleep 10 ;
-          done
-' | kubectl create -f -
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-create-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X POST -H 'Content-Type: application/yaml' --data '
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  name: daemonset-example
-spec:
-  selector:
-    matchLabels:
-      app: daemonset-example
-  template:
-    metadata:
-      labels:
-        app: daemonset-example
-    spec:
-      containers:
-      - name: daemonset-example
-        image: ubuntu:trusty
-        command:
-        - /bin/sh
-        args:
-        - -c
-        - >-
-          while [ true ]; do
-          echo "DaemonSet running on $(hostname)" ;
-          sleep 10 ;
-          done
-' http://127.0.0.1:8001/apis/apps/v1/namespaces/default/daemonsets
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-create-daemonset-v1-apps" aria-controls="res-kubectl-create-daemonset-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-create-daemonset-v1-apps" aria-controls="res-curl-create-daemonset-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-create-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-daemonset "daemonset-example" created
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-create-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "DaemonSet",
-  "apiVersion": "apps/v1",
-  "metadata": {
-    "name": "daemonset-example",
-    "namespace": "default",
-    "selfLink": "/apis/apps/v1/namespaces/default/daemonsets/daemonset-example",
-    "uid": "65552ced-b0e2-11e6-aef0-42010af00229",
-    "resourceVersion": "3558",
-    "generation": 1,
-    "creationTimestamp": "2016-11-22T18:35:09Z",
-    "labels": {
-      "app": "daemonset-example"
-    }
-  },
-  "spec": {
-    "selector": {
-      "matchLabels": {
-        "app": "daemonset-example"
-      }
-    },
-    "template": {
-      "metadata": {
-        "creationTimestamp": null,
-        "labels": {
-          "app": "daemonset-example"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "daemonset-example",
-            "image": "ubuntu:trusty",
-            "command": [
-              "/bin/sh"
-            ],
-            "args": [
-              "-c",
-              "while [ true ]; do echo \"DaemonSet running on $(hostname)\" ; sleep 10 ; done"
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "IfNotPresent"
-          }
-        ],
-        "restartPolicy": "Always",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    }
-  },
-  "status": {
-    "currentNumberScheduled": 0,
-    "numberMisscheduled": 0,
-    "desiredNumberScheduled": 0
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>create a DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apps/v1/namespaces/{namespace}/daemonsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-daemonset-v1-apps">Patch</H2>
-<P>partially update the specified DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-daemonset-v1-apps">Replace</H2>
-<P>replace the specified DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-daemonset-v1-apps">Delete</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-delete-daemonset-v1-apps" aria-controls="req-kubectl-delete-daemonset-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-delete-daemonset-v1-apps" aria-controls="req-curl-delete-daemonset-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-delete-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl delete daemonset daemonset-example
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-delete-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X DELETE -H 'Content-Type: application/yaml' --data '
-gracePeriodSeconds: 0
-orphanDependents: false
-' 'http://127.0.0.1:8001/apis/apps/v1/namespaces/default/daemonsets/daemonset-example'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-delete-daemonset-v1-apps" aria-controls="res-kubectl-delete-daemonset-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-delete-daemonset-v1-apps" aria-controls="res-curl-delete-daemonset-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-delete-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-daemonset "daemonset-example" deleted
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-delete-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Status",
-  "apiVersion": "v1",
-  "metadata": {},
-  "status": "Success",
-  "code": 200
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>delete a DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-daemonset-v1-apps">Delete Collection</H2>
-<P>delete collection of DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/daemonsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-daemonset-v1-apps-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-daemonset-v1-apps">Read</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-read-daemonset-v1-apps" aria-controls="req-kubectl-read-daemonset-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-read-daemonset-v1-apps" aria-controls="req-curl-read-daemonset-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-read-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get daemonset daemonset-example -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-read-daemonset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET http://127.0.0.1:8001/apis/apps/v1/namespaces/default/daemonsets/daemonset-example
-</CODE></PRE></DIV></DIV></DIV>
-<P>read the specified DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-daemonset-v1-apps">List</H2>
-<P>list or watch objects of kind DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/daemonsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonsetlist-v1-apps">DaemonSetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-daemonset-v1-apps">List All Namespaces</H2>
-<P>list or watch objects of kind DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/daemonsets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonsetlist-v1-apps">DaemonSetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-daemonset-v1-apps">Watch</H2>
-<P>watch changes to an object of kind DaemonSet. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/daemonsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-daemonset-v1-apps">Watch List</H2>
-<P>watch individual changes to a list of DaemonSet. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/daemonsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-daemonset-v1-apps">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of DaemonSet. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/daemonsets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-daemonset-v1-apps-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-daemonset-v1-apps">Patch Status</H2>
-<P>partially update status of the specified DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-daemonset-v1-apps">Read Status</H2>
-<P>read status of the specified DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-daemonset-v1-apps">Replace Status</H2>
-<P>replace status of the specified DaemonSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the DaemonSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#daemonset-v1-apps">DaemonSet</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="deployment-v1-apps">Deployment v1 apps</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-deployment-v1-apps" aria-controls="example-deployment-v1-apps"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Deployment Config to run 3 nginx instances (max rollback set to 10 revisions).</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  # Unique key of the Deployment instance
-  name: deployment-example
-spec:
-  # 3 Pods should exist at all times.
-  replicas: 3
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        # Apply this label to pods and default
-        # the Deployment label selector to this value
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        # Run this image
-        image: nginx:1.14
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Deployment</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deploymentlist-v1-apps">DeploymentList [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata.</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#deploymentspec-v1-apps">DeploymentSpec</a></I></TD><TD>Specification of the desired behavior of the Deployment.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#deploymentstatus-v1-apps">DeploymentStatus</a></I></TD><TD>Most recently observed status of the Deployment.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="deploymentspec-v1-apps">DeploymentSpec v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deployment-v1-apps">Deployment [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>minReadySeconds</CODE><BR /><I>integer</I></TD><TD>Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)</TD></TR>
-<TR><TD><CODE>paused</CODE><BR /><I>boolean</I></TD><TD>Indicates that the deployment is paused.</TD></TR>
-<TR><TD><CODE>progressDeadlineSeconds</CODE><BR /><I>integer</I></TD><TD>The maximum time in seconds for a deployment to make progress before it is considered to be failed. The deployment controller will continue to process failed deployments and a condition with a ProgressDeadlineExceeded reason will be surfaced in the deployment status. Note that progress will not be estimated during the time a deployment is paused. Defaults to 600s.</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>Number of desired pods. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1.</TD></TR>
-<TR><TD><CODE>revisionHistoryLimit</CODE><BR /><I>integer</I></TD><TD>The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>Label selector for pods. Existing ReplicaSets whose pods are selected by this will be the ones affected by this deployment. It must match the pod template&#39;s labels.</TD></TR>
-<TR><TD><CODE>strategy</CODE><BR /><I><a href="#deploymentstrategy-v1-apps">DeploymentStrategy</a></I><BR /><B>patch strategy</B>: <I>retainKeys</I></TD><TD>The deployment strategy to use to replace existing pods with new ones.</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>Template describes the pods that will be created.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="deploymentstatus-v1-apps">DeploymentStatus v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deployment-v1-apps">Deployment [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>availableReplicas</CODE><BR /><I>integer</I></TD><TD>Total number of available pods (ready for at least minReadySeconds) targeted by this deployment.</TD></TR>
-<TR><TD><CODE>collisionCount</CODE><BR /><I>integer</I></TD><TD>Count of hash collisions for the Deployment. The Deployment controller uses this field as a collision avoidance mechanism when it needs to create the name for the newest ReplicaSet.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#deploymentcondition-v1-apps">DeploymentCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Represents the latest available observations of a deployment&#39;s current state.</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>The generation observed by the deployment controller.</TD></TR>
-<TR><TD><CODE>readyReplicas</CODE><BR /><I>integer</I></TD><TD>Total number of ready pods targeted by this deployment.</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>Total number of non-terminated pods targeted by this deployment (their labels match the selector).</TD></TR>
-<TR><TD><CODE>unavailableReplicas</CODE><BR /><I>integer</I></TD><TD>Total number of unavailable pods targeted by this deployment. This is the total number of pods that are still required for the deployment to have 100% available capacity. They may either be pods that are running but not yet available or pods that still have not been created.</TD></TR>
-<TR><TD><CODE>updatedReplicas</CODE><BR /><I>integer</I></TD><TD>Total number of non-terminated pods targeted by this deployment that have the desired template spec.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="deploymentlist-v1-apps">DeploymentList v1 apps</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#deployment-v1-apps">Deployment</a> array</I></TD><TD>Items is the list of Deployments.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="deploymentstrategy-v1-apps">DeploymentStrategy v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deploymentspec-v1-apps">DeploymentSpec [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rollingUpdate</CODE><BR /><I><a href="#rollingupdatedeployment-v1-apps">RollingUpdateDeployment</a></I></TD><TD>Rolling update config params. Present only if DeploymentStrategyType = RollingUpdate.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of deployment. Can be &#34;Recreate&#34; or &#34;RollingUpdate&#34;. Default is RollingUpdate.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rollingupdatedeployment-v1-apps">RollingUpdateDeployment v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deploymentstrategy-v1-apps">DeploymentStrategy [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>maxSurge</CODE></TD><TD>The maximum number of pods that can be scheduled above the desired number of pods. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up. Defaults to 25%. Example: when this is set to 30%, the new ReplicaSet can be scaled up immediately when the rolling update starts, such that the total number of old and new pods do not exceed 130% of desired pods. Once old pods have been killed, new ReplicaSet can be scaled up further, ensuring that total number of pods running at any time during the update is at most 130% of desired pods.</TD></TR>
-<TR><TD><CODE>maxUnavailable</CODE></TD><TD>The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set to 30%, the old ReplicaSet can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old ReplicaSet can be scaled down further, followed by scaling up the new ReplicaSet, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-deployment-v1-apps-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-deployment-v1-apps">Create</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-create-deployment-v1-apps" aria-controls="req-kubectl-create-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-create-deployment-v1-apps" aria-controls="req-curl-create-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-create-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ echo 'apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: deployment-example
-spec:
-  replicas: 3
-  revisionHistoryLimit: 10
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx:1.14
-        ports:
-        - containerPort: 80
-' | kubectl create -f -
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-create-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X POST -H 'Content-Type: application/yaml' --data '
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: deployment-example
-spec:
-  replicas: 3
-  revisionHistoryLimit: 10
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx:1.14
-        ports:
-        - containerPort: 80
-' http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-create-deployment-v1-apps" aria-controls="res-kubectl-create-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-create-deployment-v1-apps" aria-controls="res-curl-create-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-create-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-deployment "deployment-example" created
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-create-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Deployment",
-  "apiVersion": "apps/v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-    "uid": "4ccca349-9cb1-11e6-9c54-42010a800148",
-    "resourceVersion": "2118306",
-    "generation": 1,
-    "creationTimestamp": "2016-10-28T01:53:19Z",
-    "labels": {
-      "app": "nginx"
-    }
-  },
-  "spec": {
-    "replicas": 3,
-    "selector": {
-      "matchLabels": {
-        "app": "nginx"
-      }
-    },
-    "template": {
-      "metadata": {
-        "creationTimestamp": null,
-        "labels": {
-          "app": "nginx"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "nginx",
-            "image": "nginx:1.14",
-            "ports": [
-              {
-                "containerPort": 80,
-                "protocol": "TCP"
-              }
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "IfNotPresent"
-          }
-        ],
-        "restartPolicy": "Always",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    },
-    "strategy": {
-      "type": "RollingUpdate",
-      "rollingUpdate": {
-        "maxUnavailable": 1,
-        "maxSurge": 1
-      }
-    },
-    "revisionHistoryLimit": 10
-  },
-  "status": {}
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>create a Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apps/v1/namespaces/{namespace}/deployments</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-deployment-v1-apps">Patch</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-patch-deployment-v1-apps" aria-controls="req-kubectl-patch-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-patch-deployment-v1-apps" aria-controls="req-curl-patch-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-patch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl patch deployment deployment-example -p \
-	'{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.16"}]}}}}'
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-patch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X PATCH -H 'Content-Type: application/strategic-merge-patch+json' --data '
-{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.16"}]}}}}' \
-	'http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments/deployment-example'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-patch-deployment-v1-apps" aria-controls="res-kubectl-patch-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-patch-deployment-v1-apps" aria-controls="res-curl-patch-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-patch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-"deployment-example" patched
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-patch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Deployment",
-  "apiVersion": "apps/v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-    "uid": "5dc3a8e6-b0ee-11e6-aef0-42010af00229",
-    "resourceVersion": "164489",
-    "generation": 11,
-    "creationTimestamp": "2016-11-22T20:00:50Z",
-    "labels": {
-      "app": "nginx"
-    },
-    "annotations": {
-      "deployment.kubernetes.io/revision": "5"
-    }
-  },
-  "spec": {
-    "replicas": 3,
-    "selector": {
-      "matchLabels": {
-        "app": "nginx"
-      }
-    },
-    "template": {
-      "metadata": {
-        "creationTimestamp": null,
-        "labels": {
-          "app": "nginx"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "nginx",
-            "image": "nginx:1.16",
-            "ports": [
-              {
-                "containerPort": 80,
-                "protocol": "TCP"
-              }
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "IfNotPresent"
-          }
-        ],
-        "restartPolicy": "Always",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    },
-    "strategy": {
-      "type": "RollingUpdate",
-      "rollingUpdate": {
-        "maxUnavailable": 1,
-        "maxSurge": 1
-      }
-    },
-    "revisionHistoryLimit": 10
-  },
-  "status": {
-    "observedGeneration": 10,
-    "replicas": 3,
-    "updatedReplicas": 3,
-    "availableReplicas": 3
-  }
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>partially update the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-deployment-v1-apps">Replace</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-replace-deployment-v1-apps" aria-controls="req-kubectl-replace-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-replace-deployment-v1-apps" aria-controls="req-curl-replace-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-replace-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ echo 'apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: deployment-example
-spec:
-  replicas: 3
-  revisionHistoryLimit: 10
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx:1.16
-        ports:
-        - containerPort: 80
-' | kubectl replace -f -
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-replace-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X PUT -H 'Content-Type: application/yaml' --data '
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: deployment-example
-spec:
-  replicas: 3
-  revisionHistoryLimit: 10
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx:1.16
-        ports:
-        - containerPort: 80
-' http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments/deployment-example
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-replace-deployment-v1-apps" aria-controls="res-kubectl-replace-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-replace-deployment-v1-apps" aria-controls="res-curl-replace-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-replace-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-deployment "deployment-example" replaced
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-replace-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Deployment",
-  "apiVersion": "apps/v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-    "uid": "4ccca349-9cb1-11e6-9c54-42010a800148",
-    "resourceVersion": "2119082",
-    "generation": 5,
-    "creationTimestamp": "2016-10-28T01:53:19Z",
-    "labels": {
-      "app": "nginx"
-    }
-  },
-  "spec": {
-    "replicas": 3,
-    "selector": {
-      "matchLabels": {
-        "app": "nginx"
-      }
-    },
-    "template": {
-      "metadata": {
-        "creationTimestamp": null,
-        "labels": {
-          "app": "nginx"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "nginx",
-            "image": "nginx:1.16",
-            "ports": [
-              {
-                "containerPort": 80,
-                "protocol": "TCP"
-              }
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "IfNotPresent"
-          }
-        ],
-        "restartPolicy": "Always",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    },
-    "strategy": {
-      "type": "RollingUpdate",
-      "rollingUpdate": {
-        "maxUnavailable": 1,
-        "maxSurge": 1
-      }
-    },
-    "revisionHistoryLimit": 10
-  },
-  "status": {
-    "observedGeneration": 4,
-    "replicas": 3,
-    "updatedReplicas": 3,
-    "availableReplicas": 3
-  }
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>replace the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-deployment-v1-apps">Delete</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-delete-deployment-v1-apps" aria-controls="req-kubectl-delete-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-delete-deployment-v1-apps" aria-controls="req-curl-delete-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-delete-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl delete deployment deployment-example
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-delete-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X DELETE -H 'Content-Type: application/yaml' --data '
-gracePeriodSeconds: 0
-orphanDependents: false
-' 'http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments/deployment-example'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-delete-deployment-v1-apps" aria-controls="res-kubectl-delete-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-delete-deployment-v1-apps" aria-controls="res-curl-delete-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-delete-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-deployment "deployment-example" deleted
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-delete-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Status",
-  "apiVersion": "v1",
-  "metadata": {},
-  "status": "Success",
-  "code": 200
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>delete a Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/deployments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-deployment-v1-apps">Delete Collection</H2>
-<P>delete collection of Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/deployments</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-deployment-v1-apps-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-deployment-v1-apps">Read</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-read-deployment-v1-apps" aria-controls="req-kubectl-read-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-read-deployment-v1-apps" aria-controls="req-curl-read-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-read-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get deployment deployment-example -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-read-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments/deployment-example
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-read-deployment-v1-apps" aria-controls="res-kubectl-read-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-read-deployment-v1-apps" aria-controls="res-curl-read-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-read-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-  "kind": "Deployment",
-  "apiVersion": "apps/v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-    "uid": "1b33145a-9c63-11e6-9c54-42010a800148",
-    "resourceVersion": "2064726",
-    "generation": 4,
-    "creationTimestamp": "2016-10-27T16:33:35Z",
-    "labels": {
-      "app": "nginx"
-    },
-    "annotations": {
-      "deployment.kubernetes.io/revision": "1"
-    }
-  },
-  "spec": {
-    "replicas": 3,
-    "selector": {
-      "matchLabels": {
-        "app": "nginx"
-      }
-    },
-    "template": {
-      "metadata": {
-        "creationTimestamp": null,
-        "labels": {
-          "app": "nginx"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "nginx",
-            "image": "nginx:1.14",
-            "ports": [
-              {
-                "containerPort": 80,
-                "protocol": "TCP"
-              }
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "IfNotPresent"
-          }
-        ],
-        "restartPolicy": "Always",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    },
-    "strategy": {
-      "type": "RollingUpdate",
-      "rollingUpdate": {
-        "maxUnavailable": 1,
-        "maxSurge": 1
-      }
-    }
-  },
-  "status": {
-    "observedGeneration": 4,
-    "replicas": 3,
-    "updatedReplicas": 3,
-    "availableReplicas": 3
-  }
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-read-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Deployment",
-  "apiVersion": "apps/v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-    "uid": "1b33145a-9c63-11e6-9c54-42010a800148",
-    "resourceVersion": "2064726",
-    "generation": 4,
-    "creationTimestamp": "2016-10-27T16:33:35Z",
-    "labels": {
-      "app": "nginx"
-    },
-    "annotations": {
-      "deployment.kubernetes.io/revision": "1"
-    }
-  },
-  "spec": {
-    "replicas": 3,
-    "selector": {
-      "matchLabels": {
-        "app": "nginx"
-      }
-    },
-    "template": {
-      "metadata": {
-        "creationTimestamp": null,
-        "labels": {
-          "app": "nginx"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "nginx",
-            "image": "nginx:1.14",
-            "ports": [
-              {
-                "containerPort": 80,
-                "protocol": "TCP"
-              }
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "IfNotPresent"
-          }
-        ],
-        "restartPolicy": "Always",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    },
-    "strategy": {
-      "type": "RollingUpdate",
-      "rollingUpdate": {
-        "maxUnavailable": 1,
-        "maxSurge": 1
-      }
-    }
-  },
-  "status": {
-    "observedGeneration": 4,
-    "replicas": 3,
-    "updatedReplicas": 3,
-    "availableReplicas": 3
-  }
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>read the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-deployment-v1-apps">List</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-list-deployment-v1-apps" aria-controls="req-kubectl-list-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-list-deployment-v1-apps" aria-controls="req-curl-list-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-list-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get deployment -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-list-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET 'http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-list-deployment-v1-apps" aria-controls="res-kubectl-list-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-list-deployment-v1-apps" aria-controls="res-curl-list-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-list-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-  "kind": "List",
-  "apiVersion": "v1",
-  "metadata": {},
-  "items": [
-    {
-      "kind": "Deployment",
-      "apiVersion": "app/v1beta1",
-      "metadata": {
-        "name": "docs",
-        "namespace": "default",
-        "selfLink": "/apis/app/v1beta1/namespaces/default/deployments/docs",
-        "uid": "ef49e1d2-915e-11e6-be81-42010a80003f",
-        "resourceVersion": "1924126",
-        "generation": 21,
-        "creationTimestamp": "2016-10-13T16:06:00Z",
-        "labels": {
-          "run": "docs"
-        },
-        "annotations": {
-          "deployment.kubernetes.io/revision": "10",
-          "replicatingperfection.net/push-image": "true"
-        }
-      },
-      "spec": {
-        "replicas": 1,
-        "selector": {
-          "matchLabels": {
-            "run": "docs"
-          }
-        },
-        "template": {
-          "metadata": {
-            "creationTimestamp": null,
-            "labels": {
-              "auto-pushed-image-pwittrock/api-docs": "1477496453",
-              "run": "docs"
-            }
-          },
-          "spec": {
-            "containers": [
-              {
-                "name": "docs",
-                "image": "pwittrock/api-docs:v9",
-                "resources": {},
-                "terminationMessagePath": "/dev/termination-log",
-                "imagePullPolicy": "Always"
-              }
-            ],
-            "restartPolicy": "Always",
-            "terminationGracePeriodSeconds": 30,
-            "dnsPolicy": "ClusterFirst",
-            "securityContext": {}
-          }
-        },
-        "strategy": {
-          "type": "RollingUpdate",
-          "rollingUpdate": {
-            "maxUnavailable": 1,
-            "maxSurge": 1
-          }
-        }
-      },
-      "status": {
-        "observedGeneration": 21,
-        "replicas": 1,
-        "updatedReplicas": 1,
-        "availableReplicas": 1
-      }
-    },
-    {
-      "kind": "Deployment",
-      "apiVersion": "app/v1beta1",
-      "metadata": {
-        "name": "deployment-example",
-        "namespace": "default",
-        "selfLink": "/apis/app/v1beta1/namespaces/default/deployments/deployment-example",
-        "uid": "1b33145a-9c63-11e6-9c54-42010a800148",
-        "resourceVersion": "2064726",
-        "generation": 4,
-        "creationTimestamp": "2016-10-27T16:33:35Z",
-        "labels": {
-          "app": "nginx"
-        },
-        "annotations": {
-          "deployment.kubernetes.io/revision": "1"
-        }
-      },
-      "spec": {
-        "replicas": 3,
-        "selector": {
-          "matchLabels": {
-            "app": "nginx"
-          }
-        },
-        "template": {
-          "metadata": {
-            "creationTimestamp": null,
-            "labels": {
-              "app": "nginx"
-            }
-          },
-          "spec": {
-            "containers": [
-              {
-                "name": "nginx",
-                "image": "nginx:1.14",
-                "ports": [
-                  {
-                    "containerPort": 80,
-                    "protocol": "TCP"
-                  }
-                ],
-                "resources": {},
-                "terminationMessagePath": "/dev/termination-log",
-                "imagePullPolicy": "IfNotPresent"
-              }
-            ],
-            "restartPolicy": "Always",
-            "terminationGracePeriodSeconds": 30,
-            "dnsPolicy": "ClusterFirst",
-            "securityContext": {}
-          }
-        },
-        "strategy": {
-          "type": "RollingUpdate",
-          "rollingUpdate": {
-            "maxUnavailable": 1,
-            "maxSurge": 1
-          }
-        }
-      },
-      "status": {
-        "observedGeneration": 4,
-        "replicas": 3,
-        "updatedReplicas": 3,
-        "availableReplicas": 3
-      }
-    }
-  ]
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-list-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "List",
-  "apiVersion": "v1",
-  "metadata": {},
-  "items": [
-    {
-      "kind": "Deployment",
-      "apiVersion": "app/v1beta1",
-      "metadata": {
-        "name": "docs",
-        "namespace": "default",
-        "selfLink": "/apis/app/v1beta1/namespaces/default/deployments/docs",
-        "uid": "ef49e1d2-915e-11e6-be81-42010a80003f",
-        "resourceVersion": "1924126",
-        "generation": 21,
-        "creationTimestamp": "2016-10-13T16:06:00Z",
-        "labels": {
-          "run": "docs"
-        },
-        "annotations": {
-          "deployment.kubernetes.io/revision": "10",
-          "replicatingperfection.net/push-image": "true"
-        }
-      },
-      "spec": {
-        "replicas": 1,
-        "selector": {
-          "matchLabels": {
-            "run": "docs"
-          }
-        },
-        "template": {
-          "metadata": {
-            "creationTimestamp": null,
-            "labels": {
-              "auto-pushed-image-pwittrock/api-docs": "1477496453",
-              "run": "docs"
-            }
-          },
-          "spec": {
-            "containers": [
-              {
-                "name": "docs",
-                "image": "pwittrock/api-docs:v9",
-                "resources": {},
-                "terminationMessagePath": "/dev/termination-log",
-                "imagePullPolicy": "Always"
-              }
-            ],
-            "restartPolicy": "Always",
-            "terminationGracePeriodSeconds": 30,
-            "dnsPolicy": "ClusterFirst",
-            "securityContext": {}
-          }
-        },
-        "strategy": {
-          "type": "RollingUpdate",
-          "rollingUpdate": {
-            "maxUnavailable": 1,
-            "maxSurge": 1
-          }
-        }
-      },
-      "status": {
-        "observedGeneration": 21,
-        "replicas": 1,
-        "updatedReplicas": 1,
-        "availableReplicas": 1
-      }
-    },
-    {
-      "kind": "Deployment",
-      "apiVersion": "app/v1beta1",
-      "metadata": {
-        "name": "deployment-example",
-        "namespace": "default",
-        "selfLink": "/apis/app/v1beta1/namespaces/default/deployments/deployment-example",
-        "uid": "1b33145a-9c63-11e6-9c54-42010a800148",
-        "resourceVersion": "2064726",
-        "generation": 4,
-        "creationTimestamp": "2016-10-27T16:33:35Z",
-        "labels": {
-          "app": "nginx"
-        },
-        "annotations": {
-          "deployment.kubernetes.io/revision": "1"
-        }
-      },
-      "spec": {
-        "replicas": 3,
-        "selector": {
-          "matchLabels": {
-            "app": "nginx"
-          }
-        },
-        "template": {
-          "metadata": {
-            "creationTimestamp": null,
-            "labels": {
-              "app": "nginx"
-            }
-          },
-          "spec": {
-            "containers": [
-              {
-                "name": "nginx",
-                "image": "nginx:1.14",
-                "ports": [
-                  {
-                    "containerPort": 80,
-                    "protocol": "TCP"
-                  }
-                ],
-                "resources": {},
-                "terminationMessagePath": "/dev/termination-log",
-                "imagePullPolicy": "IfNotPresent"
-              }
-            ],
-            "restartPolicy": "Always",
-            "terminationGracePeriodSeconds": 30,
-            "dnsPolicy": "ClusterFirst",
-            "securityContext": {}
-          }
-        },
-        "strategy": {
-          "type": "RollingUpdate",
-          "rollingUpdate": {
-            "maxUnavailable": 1,
-            "maxSurge": 1
-          }
-        }
-      },
-      "status": {
-        "observedGeneration": 4,
-        "replicas": 3,
-        "updatedReplicas": 3,
-        "availableReplicas": 3
-      }
-    }
-  ]
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>list or watch objects of kind Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/deployments</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deploymentlist-v1-apps">DeploymentList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-deployment-v1-apps">List All Namespaces</H2>
-<P>list or watch objects of kind Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/deployments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deploymentlist-v1-apps">DeploymentList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-deployment-v1-apps">Watch</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-watch-deployment-v1-apps" aria-controls="req-kubectl-watch-deployment-v1-apps"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-watch-deployment-v1-apps" aria-controls="req-curl-watch-deployment-v1-apps"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-watch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get deployment deployment-example --watch -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-watch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET 'http://127.0.0.1:8001/apis/apps/v1/watch/namespaces/default/deployments/deployment-example'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-watch-deployment-v1-apps" aria-controls="res-kubectl-watch-deployment-v1-apps"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-watch-deployment-v1-apps" aria-controls="res-curl-watch-deployment-v1-apps"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-watch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-	"type": "ADDED",
-	"object": {
-		"kind": "Deployment",
-		"apiVersion": "apps/v1",
-		"metadata": {
-			"name": "deployment-example",
-			"namespace": "default",
-			"selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-			"uid": "64c12290-9cbf-11e6-9c54-42010a800148",
-			"resourceVersion": "2128095",
-			"generation": 2,
-			"creationTimestamp": "2016-10-28T03:34:12Z",
-			"labels": {
-				"app": "nginx"
-			},
-			"annotations": {
-				"deployment.kubernetes.io/revision": "3"
-			}
-		},
-		"spec": {
-			"replicas": 3,
-			"selector": {
-				"matchLabels": {
-					"app": "nginx"
-				}
-			},
-			"template": {
-				"metadata": {
-					"creationTimestamp": null,
-					"labels": {
-						"app": "nginx"
-					}
-				},
-				"spec": {
-					"containers": [
-						{
-							"name": "nginx",
-							"image": "nginx:1.14",
-							"ports": [
-								{
-									"containerPort": 80,
-									"protocol": "TCP"
-								}
-							],
-							"resources": {
-							},
-							"terminationMessagePath": "/dev/termination-log",
-							"imagePullPolicy": "IfNotPresent"
-						}
-					],
-					"restartPolicy": "Always",
-					"terminationGracePeriodSeconds": 30,
-					"dnsPolicy": "ClusterFirst",
-					"securityContext": {
-					}
-				}
-			},
-			"strategy": {
-				"type": "RollingUpdate",
-				"rollingUpdate": {
-					"maxUnavailable": 1,
-					"maxSurge": 1
-				}
-			}
-		},
-		"status": {
-			"observedGeneration": 2,
-			"replicas": 3,
-			"updatedReplicas": 3,
-			"availableReplicas": 3
-		}
-	}
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-watch-deployment-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-	"type": "ADDED",
-	"object": {
-		"kind": "Deployment",
-		"apiVersion": "apps/v1",
-		"metadata": {
-			"name": "deployment-example",
-			"namespace": "default",
-			"selfLink": "/apis/apps/v1/namespaces/default/deployments/deployment-example",
-			"uid": "64c12290-9cbf-11e6-9c54-42010a800148",
-			"resourceVersion": "2128095",
-			"generation": 2,
-			"creationTimestamp": "2016-10-28T03:34:12Z",
-			"labels": {
-				"app": "nginx"
-			},
-			"annotations": {
-				"deployment.kubernetes.io/revision": "3"
-			}
-		},
-		"spec": {
-			"replicas": 3,
-			"selector": {
-				"matchLabels": {
-					"app": "nginx"
-				}
-			},
-			"template": {
-				"metadata": {
-					"creationTimestamp": null,
-					"labels": {
-						"app": "nginx"
-					}
-				},
-				"spec": {
-					"containers": [
-						{
-							"name": "nginx",
-							"image": "nginx:1.14",
-							"ports": [
-								{
-									"containerPort": 80,
-									"protocol": "TCP"
-								}
-							],
-							"resources": {
-							},
-							"terminationMessagePath": "/dev/termination-log",
-							"imagePullPolicy": "IfNotPresent"
-						}
-					],
-					"restartPolicy": "Always",
-					"terminationGracePeriodSeconds": 30,
-					"dnsPolicy": "ClusterFirst",
-					"securityContext": {
-					}
-				}
-			},
-			"strategy": {
-				"type": "RollingUpdate",
-				"rollingUpdate": {
-					"maxUnavailable": 1,
-					"maxSurge": 1
-				}
-			}
-		},
-		"status": {
-			"observedGeneration": 2,
-			"replicas": 3,
-			"updatedReplicas": 3,
-			"availableReplicas": 3
-		}
-	}
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>watch changes to an object of kind Deployment. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-deployment-v1-apps">Watch List</H2>
-<P>watch individual changes to a list of Deployment. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/deployments</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-deployment-v1-apps">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Deployment. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/deployments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-deployment-v1-apps-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-deployment-v1-apps">Patch Status</H2>
-<P>partially update status of the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-deployment-v1-apps">Read Status</H2>
-<P>read status of the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-deployment-v1-apps">Replace Status</H2>
-<P>replace status of the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Deployment</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#deployment-v1-apps">Deployment</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-misc-operations-deployment-v1-apps-strong-"><STRONG>Misc Operations</STRONG></H2>
-<H2 id="read-scale-deployment-v1-apps">Read Scale</H2>
-<P>read scale of the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-scale-deployment-v1-apps">Replace Scale</H2>
-<P>replace scale of the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-scale-deployment-v1-apps">Patch Scale</H2>
-<P>partially update scale of the specified Deployment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="job-v1-batch">Job v1 batch</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-job-v1-batch" aria-controls="example-job-v1-batch"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Job Config to print pi up to 2000 digits (then exit).</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-apiVersion: batch/v1
-kind: Job
-metadata:
-  # Unique key of the Job instance
-  name: example-job
-spec:
-  template:
-    metadata:
-      name: example-job
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: [&#34;perl&#34;]
-        args: [&#34;-Mbignum=bpi&#34;, &#34;-wle&#34;, &#34;print bpi(2000)&#34;]
-      # Do not restart containers after they exit
-      restartPolicy: Never
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>batch</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Job</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#joblist-v1-batch">JobList [batch/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#jobspec-v1-batch">JobSpec</a></I></TD><TD>Specification of the desired behavior of a job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#jobstatus-v1-batch">JobStatus</a></I></TD><TD>Current status of a job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="jobspec-v1-batch">JobSpec v1 batch</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#job-v1-batch">Job [batch/v1]</a></LI>
-  <LI><a href="#jobtemplatespec-v1beta1-batch">JobTemplateSpec [batch/v1beta1]</a></LI>
-  <LI><a href="#jobtemplatespec-v2alpha1-batch">JobTemplateSpec [batch/v2alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>activeDeadlineSeconds</CODE><BR /><I>integer</I></TD><TD>Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer</TD></TR>
-<TR><TD><CODE>backoffLimit</CODE><BR /><I>integer</I></TD><TD>Specifies the number of retries before marking this job failed. Defaults to 6</TD></TR>
-<TR><TD><CODE>completions</CODE><BR /><I>integer</I></TD><TD>Specifies the desired number of successfully finished pods the job should be run with.  Setting to nil means that the success of any pod signals the success of all pods, and allows parallelism to have any positive value.  Setting to 1 means that parallelism is limited to 1 and the success of that pod signals the success of the job. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/</TD></TR>
-<TR><TD><CODE>manualSelector</CODE><BR /><I>boolean</I></TD><TD>manualSelector controls generation of pod labels and pod selectors. Leave `manualSelector` unset unless you are certain what you are doing. When false or unset, the system pick labels unique to this job and appends those labels to the pod template.  When true, the user is responsible for picking unique labels and specifying the selector.  Failure to pick a unique label may cause this and other jobs to not function correctly.  However, You may see `manualSelector=true` in jobs that were created with the old `extensions/v1beta1` API. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector</TD></TR>
-<TR><TD><CODE>parallelism</CODE><BR /><I>integer</I></TD><TD>Specifies the maximum desired number of pods the job should run at any given time. The actual number of pods running in steady state will be less than this number when ((.spec.completions - .status.successful) &lt; .spec.parallelism), i.e. when the work left to do is less than max parallelism. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>A label query over pods that should match the pod count. Normally, the system sets this field for you. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>Describes the pod that will be created when executing a job. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/</TD></TR>
-<TR><TD><CODE>ttlSecondsAfterFinished</CODE><BR /><I>integer</I></TD><TD>ttlSecondsAfterFinished limits the lifetime of a Job that has finished execution (either Complete or Failed). If this field is set, ttlSecondsAfterFinished after the Job finishes, it is eligible to be automatically deleted. When the Job is being deleted, its lifecycle guarantees (e.g. finalizers) will be honored. If this field is unset, the Job won&#39;t be automatically deleted. If this field is set to zero, the Job becomes eligible to be deleted immediately after it finishes. This field is alpha-level and is only honored by servers that enable the TTLAfterFinished feature.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="jobstatus-v1-batch">JobStatus v1 batch</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#job-v1-batch">Job [batch/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>active</CODE><BR /><I>integer</I></TD><TD>The number of actively running pods.</TD></TR>
-<TR><TD><CODE>completionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Represents time when the job was completed. It is not guaranteed to be set in happens-before order across separate operations. It is represented in RFC3339 form and is in UTC.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#jobcondition-v1-batch">JobCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>The latest available observations of an object&#39;s current state. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/</TD></TR>
-<TR><TD><CODE>failed</CODE><BR /><I>integer</I></TD><TD>The number of pods which reached phase Failed.</TD></TR>
-<TR><TD><CODE>startTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Represents time when the job was acknowledged by the job controller. It is not guaranteed to be set in happens-before order across separate operations. It is represented in RFC3339 form and is in UTC.</TD></TR>
-<TR><TD><CODE>succeeded</CODE><BR /><I>integer</I></TD><TD>The number of pods which reached phase Succeeded.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="joblist-v1-batch">JobList v1 batch</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#job-v1-batch">Job</a> array</I></TD><TD>items is the list of Jobs.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-job-v1-batch-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-job-v1-batch">Create</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-create-job-v1-batch" aria-controls="req-kubectl-create-job-v1-batch"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-create-job-v1-batch" aria-controls="req-curl-create-job-v1-batch"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-create-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ echo 'apiVersion: batch/v1
-kind: Job
-metadata:
-  name: example-job
-spec:
-  template:
-    metadata:
-      name: example-job
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-' | kubectl create -f -
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-create-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X POST -H 'Content-Type: application/yaml' --data '
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: example-job
-spec:
-  template:
-    metadata:
-      name: example-job
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-' http://127.0.0.1:8001/apis/batch/v1/namespaces/default/jobs
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-create-job-v1-batch" aria-controls="res-kubectl-create-job-v1-batch"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-create-job-v1-batch" aria-controls="res-curl-create-job-v1-batch"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-create-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-job "example-job" created
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-create-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Job",
-  "apiVersion": "batch/v1",
-  "metadata": {
-    "name": "example-job",
-    "namespace": "default",
-    "selfLink": "/apis/batch/v1/namespaces/default/jobs/example-job",
-    "uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-    "resourceVersion": "7479",
-    "creationTimestamp": "2016-11-04T18:45:25Z"
-  },
-  "spec": {
-    "parallelism": 1,
-    "completions": 1,
-    "selector": {
-      "matchLabels": {
-        "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-      }
-    },
-    "template": {
-      "metadata": {
-        "name": "example-job",
-        "creationTimestamp": null,
-        "labels": {
-          "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-          "job-name": "example-job"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "pi",
-            "image": "perl",
-            "command": [
-              "perl",
-              "-Mbignum=bpi",
-              "-wle",
-              "print bpi(2000)"
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "Always"
-          }
-        ],
-        "restartPolicy": "Never",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    }
-  },
-  "status": {}
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>create a Job</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/batch/v1/namespaces/{namespace}/jobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#job-v1-batch">Job</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-job-v1-batch">Patch</H2>
-<P>partially update the specified Job</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-job-v1-batch">Replace</H2>
-<P>replace the specified Job</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#job-v1-batch">Job</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-job-v1-batch">Delete</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-delete-job-v1-batch" aria-controls="req-kubectl-delete-job-v1-batch"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-delete-job-v1-batch" aria-controls="req-curl-delete-job-v1-batch"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-delete-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl delete job example-job
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-delete-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X DELETE -H 'Content-Type: application/yaml' --data '
-gracePeriodSeconds: 0
-orphanDependents: false
-' 'http://127.0.0.1:8001/apis/batch/v1/namespaces/default/jobs/example-job'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-delete-job-v1-batch" aria-controls="res-kubectl-delete-job-v1-batch"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-delete-job-v1-batch" aria-controls="res-curl-delete-job-v1-batch"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-delete-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-job "example-job" deleted
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-delete-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Status",
-  "apiVersion": "v1",
-  "metadata": {},
-  "status": "Success",
-  "code": 200
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>delete a Job</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/batch/v1/namespaces/{namespace}/jobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-job-v1-batch">Delete Collection</H2>
-<P>delete collection of Job</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/batch/v1/namespaces/{namespace}/jobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-job-v1-batch-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-job-v1-batch">Read</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-read-job-v1-batch" aria-controls="req-kubectl-read-job-v1-batch"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-read-job-v1-batch" aria-controls="req-curl-read-job-v1-batch"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-read-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get job example-job -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-read-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET http://127.0.0.1:8001/apis/batch/v1/namespaces/default/jobs/example-job
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-read-job-v1-batch" aria-controls="res-kubectl-read-job-v1-batch"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-read-job-v1-batch" aria-controls="res-curl-read-job-v1-batch"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-read-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-  "kind": "Job",
-  "apiVersion": "batch/v1",
-  "metadata": {
-    "name": "example-job",
-    "namespace": "default",
-    "selfLink": "/apis/batch/v1/namespaces/default/jobs/example-job",
-    "uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-    "resourceVersion": "7482",
-    "creationTimestamp": "2016-11-04T18:45:25Z"
-  },
-  "spec": {
-    "parallelism": 1,
-    "completions": 1,
-    "selector": {
-      "matchLabels": {
-        "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-      }
-    },
-    "template": {
-      "metadata": {
-        "name": "example-job",
-        "creationTimestamp": null,
-        "labels": {
-          "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-          "job-name": "example-job"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "pi",
-            "image": "perl",
-            "command": [
-              "perl",
-              "-Mbignum=bpi",
-              "-wle",
-              "print bpi(2000)"
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "Always"
-          }
-        ],
-        "restartPolicy": "Never",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    }
-  },
-  "status": {
-    "startTime": "2016-11-04T18:45:25Z",
-    "active": 1
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-read-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Job",
-  "apiVersion": "batch/v1",
-  "metadata": {
-    "name": "example-job",
-    "namespace": "default",
-    "selfLink": "/apis/batch/v1/namespaces/default/jobs/example-job",
-    "uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-    "resourceVersion": "7482",
-    "creationTimestamp": "2016-11-04T18:45:25Z"
-  },
-  "spec": {
-    "parallelism": 1,
-    "completions": 1,
-    "selector": {
-      "matchLabels": {
-        "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-      }
-    },
-    "template": {
-      "metadata": {
-        "name": "example-job",
-        "creationTimestamp": null,
-        "labels": {
-          "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-          "job-name": "example-job"
-        }
-      },
-      "spec": {
-        "containers": [
-          {
-            "name": "pi",
-            "image": "perl",
-            "command": [
-              "perl",
-              "-Mbignum=bpi",
-              "-wle",
-              "print bpi(2000)"
-            ],
-            "resources": {},
-            "terminationMessagePath": "/dev/termination-log",
-            "imagePullPolicy": "Always"
-          }
-        ],
-        "restartPolicy": "Never",
-        "terminationGracePeriodSeconds": 30,
-        "dnsPolicy": "ClusterFirst",
-        "securityContext": {}
-      }
-    }
-  },
-  "status": {
-    "startTime": "2016-11-04T18:45:25Z",
-    "active": 1
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>read the specified Job</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-job-v1-batch">List</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-list-job-v1-batch" aria-controls="req-kubectl-list-job-v1-batch"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-list-job-v1-batch" aria-controls="req-curl-list-job-v1-batch"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-list-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get job -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-list-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET 'http://127.0.0.1:8001/apis/batch/v1/namespaces/default/jobs'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-list-job-v1-batch" aria-controls="res-kubectl-list-job-v1-batch"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-list-job-v1-batch" aria-controls="res-curl-list-job-v1-batch"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-list-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-  "kind": "JobList",
-  "apiVersion": "batch/v1",
-  "metadata": {
-    "selfLink": "/apis/batch/v1/namespaces/default/jobs",
-    "resourceVersion": "7589"
-  },
-  "items": [
-    {
-      "metadata": {
-        "name": "",
-        "namespace": "default",
-        "selfLink": "/apis/batch/v1/namespaces/default/jobs/",
-        "uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-        "resourceVersion": "7482",
-        "creationTimestamp": "2016-11-04T18:45:25Z"
-      },
-      "spec": {
-        "parallelism": 1,
-        "completions": 1,
-        "selector": {
-          "matchLabels": {
-            "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-          }
-        },
-        "template": {
-          "metadata": {
-            "name": "",
-            "creationTimestamp": null,
-            "labels": {
-              "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-              "job-name": ""
-            }
-          },
-          "spec": {
-            "containers": [
-              {
-                "name": "pi",
-                "image": "perl",
-                "command": [
-                  "perl",
-                  "-Mbignum=bpi",
-                  "-wle",
-                  "print bpi(2000)"
-                ],
-                "resources": {},
-                "terminationMessagePath": "/dev/termination-log",
-                "imagePullPolicy": "Always"
-              }
-            ],
-            "restartPolicy": "Never",
-            "terminationGracePeriodSeconds": 30,
-            "dnsPolicy": "ClusterFirst",
-            "securityContext": {}
-          }
-        }
-      },
-      "status": {
-        "startTime": "2016-11-04T18:45:25Z",
-        "active": 1
-      }
-    }
-  ]
-}
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-list-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "JobList",
-  "apiVersion": "batch/v1",
-  "metadata": {
-    "selfLink": "/apis/batch/v1/namespaces/default/jobs",
-    "resourceVersion": "7589"
-  },
-  "items": [
-    {
-      "metadata": {
-        "name": "",
-        "namespace": "default",
-        "selfLink": "/apis/batch/v1/namespaces/default/jobs/",
-        "uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-        "resourceVersion": "7482",
-        "creationTimestamp": "2016-11-04T18:45:25Z"
-      },
-      "spec": {
-        "parallelism": 1,
-        "completions": 1,
-        "selector": {
-          "matchLabels": {
-            "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-          }
-        },
-        "template": {
-          "metadata": {
-            "name": "",
-            "creationTimestamp": null,
-            "labels": {
-              "controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-              "job-name": ""
-            }
-          },
-          "spec": {
-            "containers": [
-              {
-                "name": "pi",
-                "image": "perl",
-                "command": [
-                  "perl",
-                  "-Mbignum=bpi",
-                  "-wle",
-                  "print bpi(2000)"
-                ],
-                "resources": {},
-                "terminationMessagePath": "/dev/termination-log",
-                "imagePullPolicy": "Always"
-              }
-            ],
-            "restartPolicy": "Never",
-            "terminationGracePeriodSeconds": 30,
-            "dnsPolicy": "ClusterFirst",
-            "securityContext": {}
-          }
-        }
-      },
-      "status": {
-        "startTime": "2016-11-04T18:45:25Z",
-        "active": 1
-      }
-    }
-  ]
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>list or watch objects of kind Job</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/namespaces/{namespace}/jobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#joblist-v1-batch">JobList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-job-v1-batch">List All Namespaces</H2>
-<P>list or watch objects of kind Job</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/jobs</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#joblist-v1-batch">JobList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-job-v1-batch">Watch</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-watch-job-v1-batch" aria-controls="req-kubectl-watch-job-v1-batch"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-watch-job-v1-batch" aria-controls="req-curl-watch-job-v1-batch"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-watch-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get job example-job --watch -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-watch-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET 'http://127.0.0.1:8001/apis/batch/v1/watch/namespaces/default/jobs/example-job'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-watch-job-v1-batch" aria-controls="res-kubectl-watch-job-v1-batch"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-watch-job-v1-batch" aria-controls="res-curl-watch-job-v1-batch"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-watch-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-	"type": "ADDED",
-	"object": {
-		"kind": "Job",
-		"apiVersion": "batch/v1",
-		"metadata": {
-			"name": "example-job",
-			"namespace": "default",
-			"selfLink": "/apis/batch/v1/namespaces/default/jobs/example-job",
-			"uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-			"resourceVersion": "7482",
-			"creationTimestamp": "2016-11-04T18:45:25Z"
-		},
-		"spec": {
-			"parallelism": 1,
-			"completions": 1,
-			"selector": {
-				"matchLabels": {
-					"controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-				}
-			},
-			"template": {
-				"metadata": {
-					"name": "example-job",
-					"creationTimestamp": null,
-					"labels": {
-						"controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-						"job-name": "example-job"
-					}
-				},
-				"spec": {
-					"containers": [
-						{
-							"name": "pi",
-							"image": "perl",
-							"command": [
-								"perl",
-								"-Mbignum=bpi",
-								"-wle",
-								"print bpi(2000)"
-							],
-							"resources": {
-							},
-							"terminationMessagePath": "/dev/termination-log",
-							"imagePullPolicy": "Always"
-						}
-					],
-					"restartPolicy": "Never",
-					"terminationGracePeriodSeconds": 30,
-					"dnsPolicy": "ClusterFirst",
-					"securityContext": {
-					}
-				}
-			}
-		},
-		"status": {
-			"startTime": "2016-11-04T18:45:25Z",
-			"active": 1
-		}
-	}
-}
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-watch-job-v1-batch">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-	"type": "ADDED",
-	"object": {
-		"kind": "Job",
-		"apiVersion": "batch/v1",
-		"metadata": {
-			"name": "example-job",
-			"namespace": "default",
-			"selfLink": "/apis/batch/v1/namespaces/default/jobs/example-job",
-			"uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-			"resourceVersion": "7482",
-			"creationTimestamp": "2016-11-04T18:45:25Z"
-		},
-		"spec": {
-			"parallelism": 1,
-			"completions": 1,
-			"selector": {
-				"matchLabels": {
-					"controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7"
-				}
-			},
-			"template": {
-				"metadata": {
-					"name": "example-job",
-					"creationTimestamp": null,
-					"labels": {
-						"controller-uid": "d93a3569-a2be-11e6-a008-fa043d458cc7",
-						"job-name": "example-job"
-					}
-				},
-				"spec": {
-					"containers": [
-						{
-							"name": "pi",
-							"image": "perl",
-							"command": [
-								"perl",
-								"-Mbignum=bpi",
-								"-wle",
-								"print bpi(2000)"
-							],
-							"resources": {
-							},
-							"terminationMessagePath": "/dev/termination-log",
-							"imagePullPolicy": "Always"
-						}
-					],
-					"restartPolicy": "Never",
-					"terminationGracePeriodSeconds": 30,
-					"dnsPolicy": "ClusterFirst",
-					"securityContext": {
-					}
-				}
-			}
-		},
-		"status": {
-			"startTime": "2016-11-04T18:45:25Z",
-			"active": 1
-		}
-	}
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>watch changes to an object of kind Job. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/watch/namespaces/{namespace}/jobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-job-v1-batch">Watch List</H2>
-<P>watch individual changes to a list of Job. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/watch/namespaces/{namespace}/jobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-job-v1-batch">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Job. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/watch/jobs</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-job-v1-batch-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-job-v1-batch">Patch Status</H2>
-<P>partially update status of the specified Job</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-job-v1-batch">Read Status</H2>
-<P>read status of the specified Job</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-job-v1-batch">Replace Status</H2>
-<P>replace status of the specified Job</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Job</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#job-v1-batch">Job</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#job-v1-batch">Job</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="pod-v1-core">Pod v1 core</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-pod-v1-core" aria-controls="example-pod-v1-core"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-pod-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Pod Config to print "Hello World".</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-apiVersion: v1
-kind: Pod
-metadata:
-  name: pod-example
-spec:
-  containers:
-  - name: ubuntu
-    image: ubuntu:trusty
-    command: [&#34;echo&#34;]
-    args: [&#34;Hello World&#34;]
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Pod</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-warning col-md-8"><P><I class="fa fa-warning"></I> <B>Warning:</B></P><P>It is recommended that users create Pods only through a Controller, and not directly.  See Controllers: <a href="#deployment-v1-apps">Deployment</a>, <a href="#job-v1-batch">Job</a>, or <a href="#statefulset-v1-apps">StatefulSet</a>.</P></DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podlist-v1-core">PodList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#podspec-v1-core">PodSpec</a></I></TD><TD>Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#podstatus-v1-core">PodStatus</a></I></TD><TD>Most recently observed status of the pod. This data may not be up to date. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podspec-v1-core">PodSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#pod-v1-core">Pod [core/v1]</a></LI>
-  <LI><a href="#podtemplatespec-v1-core">PodTemplateSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>activeDeadlineSeconds</CODE><BR /><I>integer</I></TD><TD>Optional duration in seconds the pod may be active on the node relative to StartTime before the system will actively try to mark it failed and kill associated containers. Value must be a positive integer.</TD></TR>
-<TR><TD><CODE>affinity</CODE><BR /><I><a href="#affinity-v1-core">Affinity</a></I></TD><TD>If specified, the pod&#39;s scheduling constraints</TD></TR>
-<TR><TD><CODE>automountServiceAccountToken</CODE><BR /><I>boolean</I></TD><TD>AutomountServiceAccountToken indicates whether a service account token should be automatically mounted.</TD></TR>
-<TR><TD><CODE>containers</CODE><BR /><I><a href="#container-v1-core">Container</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>List of containers belonging to the pod. Containers cannot currently be added or removed. There must be at least one container in a Pod. Cannot be updated.</TD></TR>
-<TR><TD><CODE>dnsConfig</CODE><BR /><I><a href="#poddnsconfig-v1-core">PodDNSConfig</a></I></TD><TD>Specifies the DNS parameters of a pod. Parameters specified here will be merged to the generated DNS configuration based on DNSPolicy.</TD></TR>
-<TR><TD><CODE>dnsPolicy</CODE><BR /><I>string</I></TD><TD>Set DNS policy for the pod. Defaults to &#34;ClusterFirst&#34;. Valid values are &#39;ClusterFirstWithHostNet&#39;, &#39;ClusterFirst&#39;, &#39;Default&#39; or &#39;None&#39;. DNS parameters given in DNSConfig will be merged with the policy selected with DNSPolicy. To have DNS options set along with hostNetwork, you have to specify DNS policy explicitly to &#39;ClusterFirstWithHostNet&#39;.</TD></TR>
-<TR><TD><CODE>enableServiceLinks</CODE><BR /><I>boolean</I></TD><TD>EnableServiceLinks indicates whether information about services should be injected into pod&#39;s environment variables, matching the syntax of Docker links. Optional: Defaults to true.</TD></TR>
-<TR><TD><CODE>ephemeralContainers</CODE><BR /><I><a href="#ephemeralcontainer-v1-core">EphemeralContainer</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod&#39;s ephemeralcontainers subresource. This field is alpha-level and is only honored by servers that enable the EphemeralContainers feature.</TD></TR>
-<TR><TD><CODE>hostAliases</CODE><BR /><I><a href="#hostalias-v1-core">HostAlias</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>ip</I></TD><TD>HostAliases is an optional list of hosts and IPs that will be injected into the pod&#39;s hosts file if specified. This is only valid for non-hostNetwork pods.</TD></TR>
-<TR><TD><CODE>hostIPC</CODE><BR /><I>boolean</I></TD><TD>Use the host&#39;s ipc namespace. Optional: Default to false.</TD></TR>
-<TR><TD><CODE>hostNetwork</CODE><BR /><I>boolean</I></TD><TD>Host networking requested for this pod. Use the host&#39;s network namespace. If this option is set, the ports that will be used must be specified. Default to false.</TD></TR>
-<TR><TD><CODE>hostPID</CODE><BR /><I>boolean</I></TD><TD>Use the host&#39;s pid namespace. Optional: Default to false.</TD></TR>
-<TR><TD><CODE>hostname</CODE><BR /><I>string</I></TD><TD>Specifies the hostname of the Pod If not specified, the pod&#39;s hostname will be set to a system-defined value.</TD></TR>
-<TR><TD><CODE>imagePullSecrets</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>ImagePullSecrets is an optional list of references to secrets in the same namespace to use for pulling any of the images used by this PodSpec. If specified, these secrets will be passed to individual puller implementations for them to use. For example, in the case of docker, only DockerConfig type secrets are honored. More info: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod</TD></TR>
-<TR><TD><CODE>initContainers</CODE><BR /><I><a href="#container-v1-core">Container</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>List of initialization containers belonging to the pod. Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, Liveness probes, or Startup probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion. Init containers cannot currently be added or removed. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/</TD></TR>
-<TR><TD><CODE>nodeName</CODE><BR /><I>string</I></TD><TD>NodeName is a request to schedule this pod onto a specific node. If it is non-empty, the scheduler simply schedules this pod onto that node, assuming that it fits resource requirements.</TD></TR>
-<TR><TD><CODE>nodeSelector</CODE><BR /><I>object</I></TD><TD>NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node&#39;s labels for the pod to be scheduled on that node. More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/</TD></TR>
-<TR><TD><CODE>overhead</CODE><BR /><I>object</I></TD><TD>Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/20190226-pod-overhead.md This field is alpha-level as of Kubernetes v1.16, and is only honored by servers that enable the PodOverhead feature.</TD></TR>
-<TR><TD><CODE>preemptionPolicy</CODE><BR /><I>string</I></TD><TD>PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is alpha-level and is only honored by servers that enable the NonPreemptingPriority feature.</TD></TR>
-<TR><TD><CODE>priority</CODE><BR /><I>integer</I></TD><TD>The priority value. Various system components use this field to find the priority of the pod. When Priority Admission Controller is enabled, it prevents users from setting this field. The admission controller populates this field from PriorityClassName. The higher the value, the higher the priority.</TD></TR>
-<TR><TD><CODE>priorityClassName</CODE><BR /><I>string</I></TD><TD>If specified, indicates the pod&#39;s priority. &#34;system-node-critical&#34; and &#34;system-cluster-critical&#34; are two special keywords which indicate the highest priorities with the former being the highest priority. Any other name must be defined by creating a PriorityClass object with that name. If not specified, the pod priority will be default or zero if there is no default.</TD></TR>
-<TR><TD><CODE>readinessGates</CODE><BR /><I><a href="#podreadinessgate-v1-core">PodReadinessGate</a> array</I></TD><TD>If specified, all readiness gates will be evaluated for pod readiness. A pod is ready when all its containers are ready AND all conditions specified in the readiness gates have status equal to &#34;True&#34; More info: https://git.k8s.io/enhancements/keps/sig-network/0007-pod-ready%2B%2B.md</TD></TR>
-<TR><TD><CODE>restartPolicy</CODE><BR /><I>string</I></TD><TD>Restart policy for all containers within the pod. One of Always, OnFailure, Never. Default to Always. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy</TD></TR>
-<TR><TD><CODE>runtimeClassName</CODE><BR /><I>string</I></TD><TD>RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used to run this pod.  If no RuntimeClass resource matches the named class, the pod will not be run. If unset or empty, the &#34;legacy&#34; RuntimeClass will be used, which is an implicit class with an empty definition that uses the default runtime handler. More info: https://git.k8s.io/enhancements/keps/sig-node/runtime-class.md This is a beta feature as of Kubernetes v1.14.</TD></TR>
-<TR><TD><CODE>schedulerName</CODE><BR /><I>string</I></TD><TD>If specified, the pod will be dispatched by specified scheduler. If not specified, the pod will be dispatched by default scheduler.</TD></TR>
-<TR><TD><CODE>securityContext</CODE><BR /><I><a href="#podsecuritycontext-v1-core">PodSecurityContext</a></I></TD><TD>SecurityContext holds pod-level security attributes and common container settings. Optional: Defaults to empty.  See type description for default values of each field.</TD></TR>
-<TR><TD><CODE>serviceAccount</CODE><BR /><I>string</I></TD><TD>DeprecatedServiceAccount is a depreciated alias for ServiceAccountName. Deprecated: Use serviceAccountName instead.</TD></TR>
-<TR><TD><CODE>serviceAccountName</CODE><BR /><I>string</I></TD><TD>ServiceAccountName is the name of the ServiceAccount to use to run this pod. More info: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/</TD></TR>
-<TR><TD><CODE>shareProcessNamespace</CODE><BR /><I>boolean</I></TD><TD>Share a single process namespace between all of the containers in a pod. When this is set containers will be able to view and signal processes from other containers in the same pod, and the first process in each container will not be assigned PID 1. HostPID and ShareProcessNamespace cannot both be set. Optional: Default to false.</TD></TR>
-<TR><TD><CODE>subdomain</CODE><BR /><I>string</I></TD><TD>If specified, the fully qualified Pod hostname will be &#34;&lt;hostname&gt;.&lt;subdomain&gt;.&lt;pod namespace&gt;.svc.&lt;cluster domain&gt;&#34;. If not specified, the pod will not have a domainname at all.</TD></TR>
-<TR><TD><CODE>terminationGracePeriodSeconds</CODE><BR /><I>integer</I></TD><TD>Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period will be used instead. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. Defaults to 30 seconds.</TD></TR>
-<TR><TD><CODE>tolerations</CODE><BR /><I><a href="#toleration-v1-core">Toleration</a> array</I></TD><TD>If specified, the pod&#39;s tolerations.</TD></TR>
-<TR><TD><CODE>topologySpreadConstraints</CODE><BR /><I><a href="#topologyspreadconstraint-v1-core">TopologySpreadConstraint</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>topologyKey</I></TD><TD>TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. This field is only honored by clusters that enable the EvenPodsSpread feature. All topologySpreadConstraints are ANDed.</TD></TR>
-<TR><TD><CODE>volumes</CODE><BR /><I><a href="#volume-v1-core">Volume</a> array</I><BR /><B>patch strategy</B>: <I>merge,retainKeys</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>List of volumes that can be mounted by containers belonging to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podstatus-v1-core">PodStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#pod-v1-core">Pod [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#podcondition-v1-core">PodCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Current service state of pod. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions</TD></TR>
-<TR><TD><CODE>containerStatuses</CODE><BR /><I><a href="#containerstatus-v1-core">ContainerStatus</a> array</I></TD><TD>The list has one entry per container in the manifest. Each entry is currently the output of `docker inspect`. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status</TD></TR>
-<TR><TD><CODE>ephemeralContainerStatuses</CODE><BR /><I><a href="#containerstatus-v1-core">ContainerStatus</a> array</I></TD><TD>Status for any ephemeral containers that have run in this pod. This field is alpha-level and is only populated by servers that enable the EphemeralContainers feature.</TD></TR>
-<TR><TD><CODE>hostIP</CODE><BR /><I>string</I></TD><TD>IP address of the host to which the pod is assigned. Empty if not yet scheduled.</TD></TR>
-<TR><TD><CODE>initContainerStatuses</CODE><BR /><I><a href="#containerstatus-v1-core">ContainerStatus</a> array</I></TD><TD>The list has one entry per init container in the manifest. The most recent successful init container will have ready = true, the most recently started container will have startTime set. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human readable message indicating details about why the pod is in this condition.</TD></TR>
-<TR><TD><CODE>nominatedNodeName</CODE><BR /><I>string</I></TD><TD>nominatedNodeName is set only when this pod preempts other pods on the node, but it cannot be scheduled right away as preemption victims receive their graceful termination periods. This field does not guarantee that the pod will be scheduled on this node. Scheduler may decide to place the pod elsewhere if other nodes become available sooner. Scheduler may also decide to give the resources on this node to a higher priority pod that is created after preemption. As a result, this field may be different than PodSpec.nodeName when the pod is scheduled.</TD></TR>
-<TR><TD><CODE>phase</CODE><BR /><I>string</I></TD><TD>The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The conditions array, the reason and message fields, and the individual container status arrays contain more detail about the pod&#39;s status. There are five possible phase values:  Pending: The pod has been accepted by the Kubernetes system, but one or more of the container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. Running: The pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. Succeeded: All containers in the pod have terminated in success, and will not be restarted. Failed: All containers in the pod have terminated, and at least one container has terminated in failure. The container either exited with non-zero status or was terminated by the system. Unknown: For some reason the state of the pod could not be obtained, typically due to an error in communicating with the host of the pod.  More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-phase</TD></TR>
-<TR><TD><CODE>podIP</CODE><BR /><I>string</I></TD><TD>IP address allocated to the pod. Routable at least within the cluster. Empty if not yet allocated.</TD></TR>
-<TR><TD><CODE>podIPs</CODE><BR /><I><a href="#podip-v1-core">PodIP</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>ip</I></TD><TD>podIPs holds the IP addresses allocated to the pod. If this field is specified, the 0th entry must match the podIP field. Pods may be allocated at most 1 value for each of IPv4 and IPv6. This list is empty if no IPs have been allocated yet.</TD></TR>
-<TR><TD><CODE>qosClass</CODE><BR /><I>string</I></TD><TD>The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>A brief CamelCase message indicating details about why the pod is in this state. e.g. &#39;Evicted&#39;</TD></TR>
-<TR><TD><CODE>startTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>RFC 3339 date and time at which the object was acknowledged by the Kubelet. This is before the Kubelet pulled the container image(s) for the pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podlist-v1-core">PodList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#pod-v1-core">Pod</a> array</I></TD><TD>List of pods. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-pod-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-pod-v1-core">Create</H2>
-<P>create a Pod</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/pods</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="create-eviction-pod-v1-core">Create Eviction</H2>
-<P>create eviction of a Pod</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/pods/{name}/eviction</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Eviction</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#eviction-v1beta1-policy">Eviction</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#eviction-v1beta1-policy">Eviction</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#eviction-v1beta1-policy">Eviction</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#eviction-v1beta1-policy">Eviction</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-pod-v1-core">Patch</H2>
-<P>partially update the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/pods/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-pod-v1-core">Replace</H2>
-<P>replace the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/pods/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-pod-v1-core">Delete</H2>
-<P>delete a Pod</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/pods/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-pod-v1-core">Delete Collection</H2>
-<P>delete collection of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/pods</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-pod-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-pod-v1-core">Read</H2>
-<P>read the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-pod-v1-core">List</H2>
-<P>list or watch objects of kind Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podlist-v1-core">PodList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-pod-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/pods</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podlist-v1-core">PodList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-pod-v1-core">Watch</H2>
-<P>watch changes to an object of kind Pod. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/pods/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-pod-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Pod. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/pods</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-pod-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Pod. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/pods</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-pod-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-pod-v1-core">Patch Status</H2>
-<P>partially update status of the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/pods/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-pod-v1-core">Read Status</H2>
-<P>read status of the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-pod-v1-core">Replace Status</H2>
-<P>replace status of the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/pods/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#pod-v1-core">Pod</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-proxy-operations-pod-v1-core-strong-"><STRONG>Proxy Operations</STRONG></H2>
-<H2 id="create-connect-portforward-pod-v1-core">Create Connect Portforward</H2>
-<P>connect POST requests to portforward of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/pods/{name}/portforward</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPortForwardOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ports</CODE></TD><TD>List of ports to forward Required when using WebSockets</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="create-connect-proxy-pod-v1-core">Create Connect Proxy</H2>
-<P>connect POST requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/pods/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="create-connect-proxy-path-pod-v1-core">Create Connect Proxy Path</H2>
-<P>connect POST requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-connect-proxy-pod-v1-core">Delete Connect Proxy</H2>
-<P>connect DELETE requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/pods/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-connect-proxy-path-pod-v1-core">Delete Connect Proxy Path</H2>
-<P>connect DELETE requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-portforward-pod-v1-core">Get Connect Portforward</H2>
-<P>connect GET requests to portforward of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods/{name}/portforward</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPortForwardOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ports</CODE></TD><TD>List of ports to forward Required when using WebSockets</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-proxy-pod-v1-core">Get Connect Proxy</H2>
-<P>connect GET requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-proxy-path-pod-v1-core">Get Connect Proxy Path</H2>
-<P>connect GET requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="head-connect-proxy-pod-v1-core">Head Connect Proxy</H2>
-<P>connect HEAD requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>HEAD /api/v1/namespaces/{namespace}/pods/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="head-connect-proxy-path-pod-v1-core">Head Connect Proxy Path</H2>
-<P>connect HEAD requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>HEAD /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-connect-proxy-pod-v1-core">Replace Connect Proxy</H2>
-<P>connect PUT requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/pods/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-connect-proxy-path-pod-v1-core">Replace Connect Proxy Path</H2>
-<P>connect PUT requests to proxy of Pod</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-misc-operations-pod-v1-core-strong-"><STRONG>Misc Operations</STRONG></H2>
-<H2 id="read-log-pod-v1-core">Read Log</H2>
-<P>read log of the specified Pod</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/pods/{name}/log</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Pod</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>container</CODE></TD><TD>The container for which to stream logs. Defaults to only container if there is one container in the pod.</TD></TR>
-<TR><TD><CODE>follow</CODE></TD><TD>Follow the log stream of the pod. Defaults to false.</TD></TR>
-<TR><TD><CODE>insecureSkipTLSVerifyBackend</CODE></TD><TD>insecureSkipTLSVerifyBackend indicates that the apiserver should not confirm the validity of the serving certificate of the backend it is connecting to.  This will make the HTTPS connection between the apiserver and the backend insecure. This means the apiserver cannot verify the log data it is receiving came from the real kubelet.  If the kubelet is configured to verify the apiserver's TLS credentials, it does not mean the connection to the real kubelet is vulnerable to a man in the middle attack (e.g. an attacker could not intercept the actual log data coming from the real kubelet).</TD></TR>
-<TR><TD><CODE>limitBytes</CODE></TD><TD>If set, the number of bytes to read from the server before terminating the log output. This may not display a complete final line of logging, and may return slightly more or slightly less than the specified limit.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>previous</CODE></TD><TD>Return previous terminated container logs. Defaults to false.</TD></TR>
-<TR><TD><CODE>sinceSeconds</CODE></TD><TD>A relative time in seconds before the current time from which to show logs. If this value precedes the time a pod was started, only logs since the pod start will be returned. If this value is in the future, no logs will be returned. Only one of sinceSeconds or sinceTime may be specified.</TD></TR>
-<TR><TD><CODE>tailLines</CODE></TD><TD>If set, the number of lines from the end of the logs to show. If not specified, logs are shown from the creation of the container or sinceSeconds or sinceTime</TD></TR>
-<TR><TD><CODE>timestamps</CODE></TD><TD>If true, add an RFC3339 or RFC3339Nano timestamp at the beginning of every line of log output. Defaults to false.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="replicaset-v1-apps">ReplicaSet v1 apps</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-replicaset-v1-apps" aria-controls="example-replicaset-v1-apps"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-replicaset-v1-apps">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">ReplicaSet Config to run 3 nginx instances.</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
-  # Unique key of the ReplicaSet instance
-  name: replicaset-example
-spec:
-  # 3 Pods should exist at all times.
-  replicas: 3
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      # Run the nginx image
-      - name: nginx
-        image: nginx:1.14
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ReplicaSet</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-warning col-md-8"><P><I class="fa fa-warning"></I> <B>Warning:</B></P><P>In many cases it is recommended to create a <a href="#deployment-v1-apps">Deployment</a> instead of ReplicaSet.</P></DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicasetlist-v1-apps">ReplicaSetList [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>If the Labels of a ReplicaSet are empty, they are defaulted to be the same as the Pod(s) that the ReplicaSet manages. Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#replicasetspec-v1-apps">ReplicaSetSpec</a></I></TD><TD>Spec defines the specification of the desired behavior of the ReplicaSet. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#replicasetstatus-v1-apps">ReplicaSetStatus</a></I></TD><TD>Status is the most recently observed status of the ReplicaSet. This data may be out of date by some window of time. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="replicasetspec-v1-apps">ReplicaSetSpec v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicaset-v1-apps">ReplicaSet [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>minReadySeconds</CODE><BR /><I>integer</I></TD><TD>Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>Selector is a label query over pods that should match the replica count. Label keys and values that must match in order to be controlled by this replica set. It must match the pod template&#39;s labels. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>Template is the object that describes the pod that will be created if insufficient replicas are detected. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="replicasetstatus-v1-apps">ReplicaSetStatus v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicaset-v1-apps">ReplicaSet [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>availableReplicas</CODE><BR /><I>integer</I></TD><TD>The number of available replicas (ready for at least minReadySeconds) for this replica set.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#replicasetcondition-v1-apps">ReplicaSetCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Represents the latest available observations of a replica set&#39;s current state.</TD></TR>
-<TR><TD><CODE>fullyLabeledReplicas</CODE><BR /><I>integer</I></TD><TD>The number of pods that have labels matching the labels of the pod template of the replicaset.</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>ObservedGeneration reflects the generation of the most recently observed ReplicaSet.</TD></TR>
-<TR><TD><CODE>readyReplicas</CODE><BR /><I>integer</I></TD><TD>The number of ready replicas for this replica set.</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>Replicas is the most recently oberved number of replicas. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="replicasetlist-v1-apps">ReplicaSetList v1 apps</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#replicaset-v1-apps">ReplicaSet</a> array</I></TD><TD>List of ReplicaSets. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-replicaset-v1-apps-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-replicaset-v1-apps">Create</H2>
-<P>create a ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apps/v1/namespaces/{namespace}/replicasets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-replicaset-v1-apps">Patch</H2>
-<P>partially update the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-replicaset-v1-apps">Replace</H2>
-<P>replace the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-replicaset-v1-apps">Delete</H2>
-<P>delete a ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/replicasets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-replicaset-v1-apps">Delete Collection</H2>
-<P>delete collection of ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/replicasets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-replicaset-v1-apps-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-replicaset-v1-apps">Read</H2>
-<P>read the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-replicaset-v1-apps">List</H2>
-<P>list or watch objects of kind ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/replicasets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicasetlist-v1-apps">ReplicaSetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-replicaset-v1-apps">List All Namespaces</H2>
-<P>list or watch objects of kind ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/replicasets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicasetlist-v1-apps">ReplicaSetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-replicaset-v1-apps">Watch</H2>
-<P>watch changes to an object of kind ReplicaSet. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/replicasets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-replicaset-v1-apps">Watch List</H2>
-<P>watch individual changes to a list of ReplicaSet. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/replicasets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-replicaset-v1-apps">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of ReplicaSet. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/replicasets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-replicaset-v1-apps-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-replicaset-v1-apps">Patch Status</H2>
-<P>partially update status of the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-replicaset-v1-apps">Read Status</H2>
-<P>read status of the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-replicaset-v1-apps">Replace Status</H2>
-<P>replace status of the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicaSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#replicaset-v1-apps">ReplicaSet</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-misc-operations-replicaset-v1-apps-strong-"><STRONG>Misc Operations</STRONG></H2>
-<H2 id="read-scale-replicaset-v1-apps">Read Scale</H2>
-<P>read scale of the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-scale-replicaset-v1-apps">Replace Scale</H2>
-<P>replace scale of the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-scale-replicaset-v1-apps">Patch Scale</H2>
-<P>partially update scale of the specified ReplicaSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="replicationcontroller-v1-core">ReplicationController v1 core</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-replicationcontroller-v1-core" aria-controls="example-replicationcontroller-v1-core"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-replicationcontroller-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">ReplicationController Config to run 3 nginx instances.</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-apiVersion: v1
-kind: ReplicationController
-metadata:
-  # Unique key of the ReplicationController instance
-  name: replicationcontroller-example
-spec:
-  # 3 Pods should exist at all times.
-  replicas: 3
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      # Run the nginx image
-      - name: nginx
-        image: nginx:1.14
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ReplicationController</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-warning col-md-8"><P><I class="fa fa-warning"></I> <B>Warning:</B></P><P>In many cases it is recommended to create a <a href="#deployment-v1-apps">Deployment</a> instead of a ReplicationController.</P></DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicationcontrollerlist-v1-core">ReplicationControllerList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>If the Labels of a ReplicationController are empty, they are defaulted to be the same as the Pod(s) that the replication controller manages. Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#replicationcontrollerspec-v1-core">ReplicationControllerSpec</a></I></TD><TD>Spec defines the specification of the desired behavior of the replication controller. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#replicationcontrollerstatus-v1-core">ReplicationControllerStatus</a></I></TD><TD>Status is the most recently observed status of the replication controller. This data may be out of date by some window of time. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="replicationcontrollerspec-v1-core">ReplicationControllerSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicationcontroller-v1-core">ReplicationController [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>minReadySeconds</CODE><BR /><I>integer</I></TD><TD>Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I>object</I></TD><TD>Selector is a label query over pods that should match the Replicas count. If Selector is empty, it is defaulted to the labels present on the Pod template. Label keys and values that must match in order to be controlled by this replication controller, if empty defaulted to labels on Pod template. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>Template is the object that describes the pod that will be created if insufficient replicas are detected. This takes precedence over a TemplateRef. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="replicationcontrollerstatus-v1-core">ReplicationControllerStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicationcontroller-v1-core">ReplicationController [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>availableReplicas</CODE><BR /><I>integer</I></TD><TD>The number of available replicas (ready for at least minReadySeconds) for this replication controller.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#replicationcontrollercondition-v1-core">ReplicationControllerCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Represents the latest available observations of a replication controller&#39;s current state.</TD></TR>
-<TR><TD><CODE>fullyLabeledReplicas</CODE><BR /><I>integer</I></TD><TD>The number of pods that have labels matching the labels of the pod template of the replication controller.</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>ObservedGeneration reflects the generation of the most recently observed replication controller.</TD></TR>
-<TR><TD><CODE>readyReplicas</CODE><BR /><I>integer</I></TD><TD>The number of ready replicas for this replication controller.</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>Replicas is the most recently oberved number of replicas. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="replicationcontrollerlist-v1-core">ReplicationControllerList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#replicationcontroller-v1-core">ReplicationController</a> array</I></TD><TD>List of replication controllers. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-replicationcontroller-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-replicationcontroller-v1-core">Create</H2>
-<P>create a ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/replicationcontrollers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-replicationcontroller-v1-core">Patch</H2>
-<P>partially update the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-replicationcontroller-v1-core">Replace</H2>
-<P>replace the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-replicationcontroller-v1-core">Delete</H2>
-<P>delete a ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/replicationcontrollers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-replicationcontroller-v1-core">Delete Collection</H2>
-<P>delete collection of ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/replicationcontrollers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-replicationcontroller-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-replicationcontroller-v1-core">Read</H2>
-<P>read the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-replicationcontroller-v1-core">List</H2>
-<P>list or watch objects of kind ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/replicationcontrollers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontrollerlist-v1-core">ReplicationControllerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-replicationcontroller-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/replicationcontrollers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontrollerlist-v1-core">ReplicationControllerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-replicationcontroller-v1-core">Watch</H2>
-<P>watch changes to an object of kind ReplicationController. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/replicationcontrollers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-replicationcontroller-v1-core">Watch List</H2>
-<P>watch individual changes to a list of ReplicationController. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/replicationcontrollers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-replicationcontroller-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of ReplicationController. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/replicationcontrollers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-replicationcontroller-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-replicationcontroller-v1-core">Patch Status</H2>
-<P>partially update status of the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-replicationcontroller-v1-core">Read Status</H2>
-<P>read status of the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-replicationcontroller-v1-core">Replace Status</H2>
-<P>replace status of the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ReplicationController</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#replicationcontroller-v1-core">ReplicationController</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-misc-operations-replicationcontroller-v1-core-strong-"><STRONG>Misc Operations</STRONG></H2>
-<H2 id="read-scale-replicationcontroller-v1-core">Read Scale</H2>
-<P>read scale of the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-scale-replicationcontroller-v1-core">Replace Scale</H2>
-<P>replace scale of the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-scale-replicationcontroller-v1-core">Patch Scale</H2>
-<P>partially update scale of the specified ReplicationController</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="statefulset-v1-apps">StatefulSet v1 apps</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StatefulSet</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statefulsetlist-v1-apps">StatefulSetList [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#statefulsetspec-v1-apps">StatefulSetSpec</a></I></TD><TD>Spec defines the desired identities of pods in this set.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#statefulsetstatus-v1-apps">StatefulSetStatus</a></I></TD><TD>Status is the current status of Pods in this StatefulSet. This data may be out of date by some window of time.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="statefulsetspec-v1-apps">StatefulSetSpec v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statefulset-v1-apps">StatefulSet [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>podManagementPolicy</CODE><BR /><I>string</I></TD><TD>podManagementPolicy controls how pods are created during initial scale up, when replacing pods on nodes, or when scaling down. The default policy is `OrderedReady`, where pods are created in increasing order (pod-0, then pod-1, etc) and the controller will wait until each pod is ready before continuing. When scaling down, the pods are removed in the opposite order. The alternative policy is `Parallel` which will create pods in parallel to match the desired scale without waiting, and on scale down will delete all pods at once.</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>replicas is the desired number of replicas of the given Template. These are replicas in the sense that they are instantiations of the same Template, but individual replicas also have a consistent identity. If unspecified, defaults to 1.</TD></TR>
-<TR><TD><CODE>revisionHistoryLimit</CODE><BR /><I>integer</I></TD><TD>revisionHistoryLimit is the maximum number of revisions that will be maintained in the StatefulSet&#39;s revision history. The revision history consists of all revisions not represented by a currently applied StatefulSetSpec version. The default value is 10.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>selector is a label query over pods that should match the replica count. It must match the pod template&#39;s labels. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors</TD></TR>
-<TR><TD><CODE>serviceName</CODE><BR /><I>string</I></TD><TD>serviceName is the name of the service that governs this StatefulSet. This service must exist before the StatefulSet, and is responsible for the network identity of the set. Pods get DNS/hostnames that follow the pattern: pod-specific-string.serviceName.default.svc.cluster.local where &#34;pod-specific-string&#34; is managed by the StatefulSet controller.</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>template is the object that describes the pod that will be created if insufficient replicas are detected. Each pod stamped out by the StatefulSet will fulfill this Template, but have a unique identity from the rest of the StatefulSet.</TD></TR>
-<TR><TD><CODE>updateStrategy</CODE><BR /><I><a href="#statefulsetupdatestrategy-v1-apps">StatefulSetUpdateStrategy</a></I></TD><TD>updateStrategy indicates the StatefulSetUpdateStrategy that will be employed to update Pods in the StatefulSet when a revision is made to Template.</TD></TR>
-<TR><TD><CODE>volumeClaimTemplates</CODE><BR /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a> array</I></TD><TD>volumeClaimTemplates is a list of claims that pods are allowed to reference. The StatefulSet controller is responsible for mapping network identities to claims in a way that maintains the identity of a pod. Every claim in this list must have at least one matching (by name) volumeMount in one container in the template. A claim in this list takes precedence over any volumes in the template, with the same name.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="statefulsetstatus-v1-apps">StatefulSetStatus v1 apps</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statefulset-v1-apps">StatefulSet [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>collisionCount</CODE><BR /><I>integer</I></TD><TD>collisionCount is the count of hash collisions for the StatefulSet. The StatefulSet controller uses this field as a collision avoidance mechanism when it needs to create the name for the newest ControllerRevision.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#statefulsetcondition-v1-apps">StatefulSetCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Represents the latest available observations of a statefulset&#39;s current state.</TD></TR>
-<TR><TD><CODE>currentReplicas</CODE><BR /><I>integer</I></TD><TD>currentReplicas is the number of Pods created by the StatefulSet controller from the StatefulSet version indicated by currentRevision.</TD></TR>
-<TR><TD><CODE>currentRevision</CODE><BR /><I>string</I></TD><TD>currentRevision, if not empty, indicates the version of the StatefulSet used to generate Pods in the sequence [0,currentReplicas).</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>observedGeneration is the most recent generation observed for this StatefulSet. It corresponds to the StatefulSet&#39;s generation, which is updated on mutation by the API Server.</TD></TR>
-<TR><TD><CODE>readyReplicas</CODE><BR /><I>integer</I></TD><TD>readyReplicas is the number of Pods created by the StatefulSet controller that have a Ready Condition.</TD></TR>
-<TR><TD><CODE>replicas</CODE><BR /><I>integer</I></TD><TD>replicas is the number of Pods created by the StatefulSet controller.</TD></TR>
-<TR><TD><CODE>updateRevision</CODE><BR /><I>string</I></TD><TD>updateRevision, if not empty, indicates the version of the StatefulSet used to generate Pods in the sequence [replicas-updatedReplicas,replicas)</TD></TR>
-<TR><TD><CODE>updatedReplicas</CODE><BR /><I>integer</I></TD><TD>updatedReplicas is the number of Pods created by the StatefulSet controller from the StatefulSet version indicated by updateRevision.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="statefulsetlist-v1-apps">StatefulSetList v1 apps</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#statefulset-v1-apps">StatefulSet</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-statefulset-v1-apps-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-statefulset-v1-apps">Create</H2>
-<P>create a StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apps/v1/namespaces/{namespace}/statefulsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-statefulset-v1-apps">Patch</H2>
-<P>partially update the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-statefulset-v1-apps">Replace</H2>
-<P>replace the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-statefulset-v1-apps">Delete</H2>
-<P>delete a StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-statefulset-v1-apps">Delete Collection</H2>
-<P>delete collection of StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/statefulsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-statefulset-v1-apps-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-statefulset-v1-apps">Read</H2>
-<P>read the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-statefulset-v1-apps">List</H2>
-<P>list or watch objects of kind StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/statefulsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulsetlist-v1-apps">StatefulSetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-statefulset-v1-apps">List All Namespaces</H2>
-<P>list or watch objects of kind StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/statefulsets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulsetlist-v1-apps">StatefulSetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-statefulset-v1-apps">Watch</H2>
-<P>watch changes to an object of kind StatefulSet. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/statefulsets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-statefulset-v1-apps">Watch List</H2>
-<P>watch individual changes to a list of StatefulSet. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/statefulsets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-statefulset-v1-apps">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of StatefulSet. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/statefulsets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-statefulset-v1-apps-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-statefulset-v1-apps">Patch Status</H2>
-<P>partially update status of the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-statefulset-v1-apps">Read Status</H2>
-<P>read status of the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-statefulset-v1-apps">Replace Status</H2>
-<P>replace status of the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StatefulSet</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#statefulset-v1-apps">StatefulSet</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-misc-operations-statefulset-v1-apps-strong-"><STRONG>Misc Operations</STRONG></H2>
-<H2 id="read-scale-statefulset-v1-apps">Read Scale</H2>
-<P>read scale of the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-scale-statefulset-v1-apps">Replace Scale</H2>
-<P>replace scale of the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-scale-statefulset-v1-apps">Patch Scale</H2>
-<P>partially update scale of the specified StatefulSet</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Scale</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#scale-v1-autoscaling">Scale</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="-strong-service-apis-strong-"><STRONG>SERVICE APIs</STRONG></H1>
-
-<P>Service API resources are responsible for stitching your workloads together into an accessible Loadbalanced Service.  By default,
-<A href="#-strong-workloads-strong">Workloads</A> are only accessible within the cluster, and they must be exposed externally using a either
-a *LoadBalancer* or *NodePort* <A href="#service-v1-core">Service</A>.  For development, internally accessible
-Workloads can be accessed via proxy through the api master using the <code>kubectl proxy</code> command.</P>
-
-<P>Common resource types:</P>
-
-<UL>
-	<LI><A href="#service-v1-core">Services</A> for providing a single ip endpoint loadbalanced across multiple Workload replicas.</LI>
-	<LI><A href="#ingress-v1beta1-extensions">Ingress</A> for providing a https(s) endpoint http(s) routed to one or more *Services*.</LI>
-</UL>
-<HR />
-<H1 id="endpoints-v1-core">Endpoints v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Endpoints</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpointslist-v1-core">EndpointsList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>subsets</CODE><BR /><I><a href="#endpointsubset-v1-core">EndpointSubset</a> array</I></TD><TD>The set of all endpoints is the union of all subsets. Addresses are placed into subsets according to the IPs they share. A single address with multiple ports, some of which are ready and some of which are not (because they come from different containers) will result in the address being displayed in different subsets for the different ports. No address will appear in both Addresses and NotReadyAddresses in the same subset. Sets of addresses and ports that comprise a service.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="endpointslist-v1-core">EndpointsList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#endpoints-v1-core">Endpoints</a> array</I></TD><TD>List of endpoints.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-endpoints-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-endpoints-v1-core">Create</H2>
-<P>create Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/endpoints</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-endpoints-v1-core">Patch</H2>
-<P>partially update the specified Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/endpoints/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Endpoints</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-endpoints-v1-core">Replace</H2>
-<P>replace the specified Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/endpoints/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Endpoints</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-endpoints-v1-core">Delete</H2>
-<P>delete Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/endpoints/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Endpoints</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-endpoints-v1-core">Delete Collection</H2>
-<P>delete collection of Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/endpoints</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-endpoints-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-endpoints-v1-core">Read</H2>
-<P>read the specified Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/endpoints/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Endpoints</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpoints-v1-core">Endpoints</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-endpoints-v1-core">List</H2>
-<P>list or watch objects of kind Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/endpoints</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslist-v1-core">EndpointsList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-endpoints-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind Endpoints</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/endpoints</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslist-v1-core">EndpointsList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-endpoints-v1-core">Watch</H2>
-<P>watch changes to an object of kind Endpoints. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/endpoints/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Endpoints</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-endpoints-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Endpoints. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/endpoints</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-endpoints-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Endpoints. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/endpoints</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="endpointslice-v1beta1-discovery-k8s-io">EndpointSlice v1beta1 discovery.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>discovery.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>EndpointSlice</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpointslicelist-v1beta1-discovery-k8s-io">EndpointSliceList [discovery/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>addressType</CODE><BR /><I>string</I></TD><TD>addressType specifies the type of address carried by this EndpointSlice. All addresses in this slice must be the same type. This field is immutable after creation. The following address types are currently supported: * IPv4: Represents an IPv4 Address. * IPv6: Represents an IPv6 Address. * FQDN: Represents a Fully Qualified Domain Name.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>endpoints</CODE><BR /><I><a href="#endpoint-v1beta1-discovery-k8s-io">Endpoint</a> array</I></TD><TD>endpoints is a list of unique endpoints in this slice. Each slice may include a maximum of 1000 endpoints.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#endpointport-v1beta1-discovery-k8s-io">EndpointPort</a> array</I></TD><TD>ports specifies the list of network ports exposed by each endpoint in this slice. Each port must have a unique name. When ports is empty, it indicates that there are no defined ports. When a port is defined with a nil port value, it indicates &#34;all ports&#34;. Each slice may include a maximum of 100 ports.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="endpointslicelist-v1beta1-discovery-k8s-io">EndpointSliceList v1beta1 discovery</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a> array</I></TD><TD>List of endpoint slices</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-endpointslice-v1beta1-discovery-k8s-io">Create</H2>
-<P>create an EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-endpointslice-v1beta1-discovery-k8s-io">Patch</H2>
-<P>partially update the specified EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the EndpointSlice</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-endpointslice-v1beta1-discovery-k8s-io">Replace</H2>
-<P>replace the specified EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the EndpointSlice</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-endpointslice-v1beta1-discovery-k8s-io">Delete</H2>
-<P>delete an EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the EndpointSlice</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-endpointslice-v1beta1-discovery-k8s-io">Delete Collection</H2>
-<P>delete collection of EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-endpointslice-v1beta1-discovery-k8s-io">Read</H2>
-<P>read the specified EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the EndpointSlice</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-endpointslice-v1beta1-discovery-k8s-io">List</H2>
-<P>list or watch objects of kind EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslicelist-v1beta1-discovery-k8s-io">EndpointSliceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind EndpointSlice</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/discovery.k8s.io/v1beta1/endpointslices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#endpointslicelist-v1beta1-discovery-k8s-io">EndpointSliceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-endpointslice-v1beta1-discovery-k8s-io">Watch</H2>
-<P>watch changes to an object of kind EndpointSlice. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/discovery.k8s.io/v1beta1/watch/namespaces/{namespace}/endpointslices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the EndpointSlice</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-endpointslice-v1beta1-discovery-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of EndpointSlice. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/discovery.k8s.io/v1beta1/watch/namespaces/{namespace}/endpointslices</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of EndpointSlice. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/discovery.k8s.io/v1beta1/watch/endpointslices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="ingress-v1beta1-networking-k8s-io">Ingress v1beta1 networking.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Ingress</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingresslist-v1beta1-networking-k8s-io">IngressList [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#ingressspec-v1beta1-networking-k8s-io">IngressSpec</a></I></TD><TD>Spec is the desired state of the Ingress. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#ingressstatus-v1beta1-networking-k8s-io">IngressStatus</a></I></TD><TD>Status is the current state of the Ingress. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingressspec-v1beta1-networking-k8s-io">IngressSpec v1beta1 networking</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingress-v1beta1-networking-k8s-io">Ingress [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>backend</CODE><BR /><I><a href="#ingressbackend-v1beta1-networking-k8s-io">IngressBackend</a></I></TD><TD>A default backend capable of servicing requests that don&#39;t match any rule. At least one of &#39;backend&#39; or &#39;rules&#39; must be specified. This field is optional to allow the loadbalancer controller or defaulting logic to specify a global default.</TD></TR>
-<TR><TD><CODE>ingressClassName</CODE><BR /><I>string</I></TD><TD>IngressClassName is the name of the IngressClass cluster resource. The associated IngressClass defines which controller will implement the resource. This replaces the deprecated `kubernetes.io/ingress.class` annotation. For backwards compatibility, when that annotation is set, it must be given precedence over this field. The controller may emit a warning if the field and annotation have different values. Implementations of this API should ignore Ingresses without a class specified. An IngressClass resource may be marked as default, which can be used to set a default value for this field. For more information, refer to the IngressClass documentation.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#ingressrule-v1beta1-networking-k8s-io">IngressRule</a> array</I></TD><TD>A list of host rules used to configure the Ingress. If unspecified, or no rule matches, all traffic is sent to the default backend.</TD></TR>
-<TR><TD><CODE>tls</CODE><BR /><I><a href="#ingresstls-v1beta1-networking-k8s-io">IngressTLS</a> array</I></TD><TD>TLS configuration. Currently the Ingress only supports a single TLS port, 443. If multiple members of this list specify different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension, if the ingress controller fulfilling the ingress supports SNI.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingressstatus-v1beta1-networking-k8s-io">IngressStatus v1beta1 networking</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingress-v1beta1-networking-k8s-io">Ingress [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>loadBalancer</CODE><BR /><I><a href="#loadbalancerstatus-v1-core">LoadBalancerStatus</a></I></TD><TD>LoadBalancer contains the current status of the load-balancer.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingresslist-v1beta1-networking-k8s-io">IngressList v1beta1 networking</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a> array</I></TD><TD>Items is the list of Ingress.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-ingress-v1beta1-networking-k8s-io">Create</H2>
-<P>create an Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-ingress-v1beta1-networking-k8s-io">Patch</H2>
-<P>partially update the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-ingress-v1beta1-networking-k8s-io">Replace</H2>
-<P>replace the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-ingress-v1beta1-networking-k8s-io">Delete</H2>
-<P>delete an Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-ingress-v1beta1-networking-k8s-io">Delete Collection</H2>
-<P>delete collection of Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-ingress-v1beta1-networking-k8s-io">Read</H2>
-<P>read the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-ingress-v1beta1-networking-k8s-io">List</H2>
-<P>list or watch objects of kind Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingresslist-v1beta1-networking-k8s-io">IngressList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-ingress-v1beta1-networking-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/ingresses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingresslist-v1beta1-networking-k8s-io">IngressList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-ingress-v1beta1-networking-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Ingress. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/watch/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-ingress-v1beta1-networking-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Ingress. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/watch/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Ingress. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/watch/ingresses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-ingress-v1beta1-networking-k8s-io">Patch Status</H2>
-<P>partially update status of the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-ingress-v1beta1-networking-k8s-io">Read Status</H2>
-<P>read status of the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-ingress-v1beta1-networking-k8s-io">Replace Status</H2>
-<P>replace status of the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingress-v1beta1-networking-k8s-io">Ingress</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="ingressclass-v1beta1-networking-k8s-io">IngressClass v1beta1 networking.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressclasslist-v1beta1-networking-k8s-io">IngressClassList [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#ingressclassspec-v1beta1-networking-k8s-io">IngressClassSpec</a></I></TD><TD>Spec is the desired state of the IngressClass. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingressclassspec-v1beta1-networking-k8s-io">IngressClassSpec v1beta1 networking</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>controller</CODE><BR /><I>string</I></TD><TD>Controller refers to the name of the controller that should handle this class. This allows for different &#34;flavors&#34; that are controlled by the same controller. For example, you may have different Parameters for the same implementing controller. This should be specified as a domain-prefixed path no more than 250 characters in length, e.g. &#34;acme.io/ingress-controller&#34;. This field is immutable.</TD></TR>
-<TR><TD><CODE>parameters</CODE><BR /><I><a href="#typedlocalobjectreference-v1-core">TypedLocalObjectReference</a></I></TD><TD>Parameters is a link to a custom resource containing additional configuration for the controller. This is optional if the controller does not require extra parameters.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingressclasslist-v1beta1-networking-k8s-io">IngressClassList v1beta1 networking</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a> array</I></TD><TD>Items is the list of IngressClasses.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-ingressclass-v1beta1-networking-k8s-io">Create</H2>
-<P>create an IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/networking.k8s.io/v1beta1/ingressclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-ingressclass-v1beta1-networking-k8s-io">Patch</H2>
-<P>partially update the specified IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/networking.k8s.io/v1beta1/ingressclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the IngressClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-ingressclass-v1beta1-networking-k8s-io">Replace</H2>
-<P>replace the specified IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/networking.k8s.io/v1beta1/ingressclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the IngressClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-ingressclass-v1beta1-networking-k8s-io">Delete</H2>
-<P>delete an IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/networking.k8s.io/v1beta1/ingressclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the IngressClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-ingressclass-v1beta1-networking-k8s-io">Delete Collection</H2>
-<P>delete collection of IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/networking.k8s.io/v1beta1/ingressclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-ingressclass-v1beta1-networking-k8s-io">Read</H2>
-<P>read the specified IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/ingressclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the IngressClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-ingressclass-v1beta1-networking-k8s-io">List</H2>
-<P>list or watch objects of kind IngressClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/ingressclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingressclasslist-v1beta1-networking-k8s-io">IngressClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-ingressclass-v1beta1-networking-k8s-io">Watch</H2>
-<P>watch changes to an object of kind IngressClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/watch/ingressclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the IngressClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-ingressclass-v1beta1-networking-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of IngressClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1beta1/watch/ingressclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="service-v1-core">Service v1 core</H1>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#example-service-v1-core" aria-controls="example-service-v1-core"
-  aria-expanded="false">example</BUTTON>
-<DIV class="collapse" id="example-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Service Config to load balance traffic across all Pods with the app=nginx label.  Receives on and sends to port 80.  Exposes an externally accessible endpoint.</DIV>
-  <DIV class="panel-body">
-<PRE class="example"><CODE class="lang-yaml">
-kind: Service
-apiVersion: v1
-metadata:
-  # Unique key of the Service instance
-  name: service-example
-spec:
-  ports:
-    # Accept traffic sent to port 80
-    - name: http
-      port: 80
-      targetPort: 80
-  selector:
-    # Loadbalance traffic across Pods matching
-    # this label selector
-    app: nginx
-  # Create an HA proxy in the cloud provider
-  # with an External IP address - *Only supported
-  # by some cloud providers*
-  type: LoadBalancer
-
-</CODE></PRE></DIV></DIV></DIV>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Service</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#servicelist-v1-core">ServiceList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#servicespec-v1-core">ServiceSpec</a></I></TD><TD>Spec defines the behavior of a service. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#servicestatus-v1-core">ServiceStatus</a></I></TD><TD>Most recently observed status of the service. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="servicespec-v1-core">ServiceSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#service-v1-core">Service [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clusterIP</CODE><BR /><I>string</I></TD><TD>clusterIP is the IP address of the service and is usually assigned randomly by the master. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise, creation of the service will fail. This field can not be changed through updates. Valid values are &#34;None&#34;, empty string (&#34;&#34;), or a valid IP address. &#34;None&#34; can be specified for headless services when proxying is not required. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies</TD></TR>
-<TR><TD><CODE>externalIPs</CODE><BR /><I>string array</I></TD><TD>externalIPs is a list of IP addresses for which nodes in the cluster will also accept traffic for this service.  These IPs are not managed by Kubernetes.  The user is responsible for ensuring that traffic arrives at a node with this IP.  A common example is external load-balancers that are not part of the Kubernetes system.</TD></TR>
-<TR><TD><CODE>externalName</CODE><BR /><I>string</I></TD><TD>externalName is the external reference that kubedns or equivalent will return as a CNAME record for this service. No proxying will be involved. Must be a valid RFC-1123 hostname (https://tools.ietf.org/html/rfc1123) and requires Type to be ExternalName.</TD></TR>
-<TR><TD><CODE>externalTrafficPolicy</CODE><BR /><I>string</I></TD><TD>externalTrafficPolicy denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. &#34;Local&#34; preserves the client source IP and avoids a second hop for LoadBalancer and Nodeport type services, but risks potentially imbalanced traffic spreading. &#34;Cluster&#34; obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading.</TD></TR>
-<TR><TD><CODE>healthCheckNodePort</CODE><BR /><I>integer</I></TD><TD>healthCheckNodePort specifies the healthcheck nodePort for the service. If not specified, HealthCheckNodePort is created by the service api backend with the allocated nodePort. Will use user-specified nodePort value if specified by the client. Only effects when Type is set to LoadBalancer and ExternalTrafficPolicy is set to Local.</TD></TR>
-<TR><TD><CODE>ipFamily</CODE><BR /><I>string</I></TD><TD>ipFamily specifies whether this Service has a preference for a particular IP family (e.g. IPv4 vs. IPv6).  If a specific IP family is requested, the clusterIP field will be allocated from that family, if it is available in the cluster.  If no IP family is requested, the cluster&#39;s primary IP family will be used. Other IP fields (loadBalancerIP, loadBalancerSourceRanges, externalIPs) and controllers which allocate external load-balancers should use the same IP family.  Endpoints for this Service will be of this family.  This field is immutable after creation. Assigning a ServiceIPFamily not available in the cluster (e.g. IPv6 in IPv4 only cluster) is an error condition and will fail during clusterIP assignment.</TD></TR>
-<TR><TD><CODE>loadBalancerIP</CODE><BR /><I>string</I></TD><TD>Only applies to Service Type: LoadBalancer LoadBalancer will get created with the IP specified in this field. This feature depends on whether the underlying cloud-provider supports specifying the loadBalancerIP when a load balancer is created. This field will be ignored if the cloud-provider does not support the feature.</TD></TR>
-<TR><TD><CODE>loadBalancerSourceRanges</CODE><BR /><I>string array</I></TD><TD>If specified and supported by the platform, this will restrict traffic through the cloud-provider load-balancer will be restricted to the specified client IPs. This field will be ignored if the cloud-provider does not support the feature.&#34; More info: https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/</TD></TR>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#serviceport-v1-core">ServicePort</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>port</I></TD><TD>The list of ports that are exposed by this service. More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies</TD></TR>
-<TR><TD><CODE>publishNotReadyAddresses</CODE><BR /><I>boolean</I></TD><TD>publishNotReadyAddresses, when set to true, indicates that DNS implementations must publish the notReadyAddresses of subsets for the Endpoints associated with the Service. The default value is false. The primary use case for setting this field is to use a StatefulSet&#39;s Headless Service to propagate SRV records for its Pods without respect to their readiness for purpose of peer discovery.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I>object</I></TD><TD>Route service traffic to pods with label keys and values matching this selector. If empty or not present, the service is assumed to have an external process managing its endpoints, which Kubernetes will not modify. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: https://kubernetes.io/docs/concepts/services-networking/service/</TD></TR>
-<TR><TD><CODE>sessionAffinity</CODE><BR /><I>string</I></TD><TD>Supports &#34;ClientIP&#34; and &#34;None&#34;. Used to maintain session affinity. Enable client IP based session affinity. Must be ClientIP or None. Defaults to None. More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies</TD></TR>
-<TR><TD><CODE>sessionAffinityConfig</CODE><BR /><I><a href="#sessionaffinityconfig-v1-core">SessionAffinityConfig</a></I></TD><TD>sessionAffinityConfig contains the configurations of session affinity.</TD></TR>
-<TR><TD><CODE>topologyKeys</CODE><BR /><I>string array</I></TD><TD>topologyKeys is a preference-order list of topology keys which implementations of services should use to preferentially sort endpoints when accessing this Service, it can not be used at the same time as externalTrafficPolicy=Local. Topology keys must be valid label keys and at most 16 keys may be specified. 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 &#34;*&#34; may be used to mean &#34;any topology&#34;. This catch-all value, if used, only makes sense as the last value in the list. If this is not specified or empty, no topology constraints will be applied.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer. &#34;ExternalName&#34; maps to the specified externalName. &#34;ClusterIP&#34; allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object. If clusterIP is &#34;None&#34;, no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a stable IP. &#34;NodePort&#34; builds on ClusterIP and allocates a port on every node which routes to the clusterIP. &#34;LoadBalancer&#34; builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the clusterIP. More info: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="servicestatus-v1-core">ServiceStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#service-v1-core">Service [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>loadBalancer</CODE><BR /><I><a href="#loadbalancerstatus-v1-core">LoadBalancerStatus</a></I></TD><TD>LoadBalancer contains the current status of the load-balancer, if one is present.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="servicelist-v1-core">ServiceList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#service-v1-core">Service</a> array</I></TD><TD>List of services</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-service-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-service-v1-core">Create</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-create-service-v1-core" aria-controls="req-kubectl-create-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-create-service-v1-core" aria-controls="req-curl-create-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-create-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ echo 'kind: Service
-apiVersion: v1
-metadata:
-  name: service-example
-spec:
-  ports:
-    - name: http
-      port: 80
-      targetPort: 80
-  selector:
-      app: nginx
-  type: LoadBalancer
-' | kubectl create -f -
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-create-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X POST -H 'Content-Type: application/yaml' --data '
-kind: Service
-apiVersion: v1
-metadata:
-  name: service-example
-spec:
-  ports:
-    - name: http
-      port: 80
-      targetPort: 80
-  selector:
-      app: nginx
-  type: LoadBalancer
-' http://127.0.0.1:8001/api/v1/namespaces/default/services
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-create-service-v1-core" aria-controls="res-kubectl-create-service-v1-core"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-create-service-v1-core" aria-controls="res-curl-create-service-v1-core"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-create-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-service "service-example" created
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-create-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Service",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "service-example",
-    "namespace": "default",
-    "selfLink": "/api/v1/namespaces/default/services/service-example",
-    "uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-    "resourceVersion": "2205767",
-    "creationTimestamp": "2016-10-28T17:04:24Z"
-  },
-  "spec": {
-    "ports": [
-      {
-        "name": "http",
-        "protocol": "TCP",
-        "port": 80,
-        "targetPort": 80,
-        "nodePort": 32417
-      }
-    ],
-    "selector": {
-      "app": "nginx"
-    },
-    "clusterIP": "10.183.250.161",
-    "type": "LoadBalancer",
-    "sessionAffinity": "None"
-  },
-  "status": {
-    "loadBalancer": {}
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>create a Service</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/services</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#service-v1-core">Service</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-service-v1-core">Patch</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-patch-service-v1-core" aria-controls="req-kubectl-patch-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-patch-service-v1-core" aria-controls="req-curl-patch-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-patch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl patch service  -p \
-	'{"spec":{"ports":[{"name":"http","port":80,"targetPort":8080}]}}'
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-patch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X PATCH -H 'Content-Type: application/strategic-merge-patch+json' --data '
-{"spec":{"ports":[{"name":"http","port":80,"targetPort":8080}]}}' \
-	'http://127.0.0.1:8001/api/v1/namespaces/default/services/'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-patch-service-v1-core" aria-controls="res-kubectl-patch-service-v1-core"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-patch-service-v1-core" aria-controls="res-curl-patch-service-v1-core"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-patch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-"" patched
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-patch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Service",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/api/v1/namespaces/default/services/deployment-example",
-    "uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-    "resourceVersion": "2205995",
-    "creationTimestamp": "2016-10-28T17:04:24Z"
-  },
-  "spec": {
-    "ports": [
-      {
-        "name": "http",
-        "protocol": "TCP",
-        "port": 80,
-        "targetPort": 8080,
-        "nodePort": 32417
-      }
-    ],
-    "selector": {
-      "app": "nginx"
-    },
-    "clusterIP": "10.183.250.161",
-    "type": "LoadBalancer",
-    "sessionAffinity": "None"
-  },
-  "status": {
-    "loadBalancer": {
-      "ingress": [
-        {
-          "ip": "104.198.186.106"
-        }
-      ]
-    }
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>partially update the specified Service</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/services/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-service-v1-core">Replace</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-replace-service-v1-core" aria-controls="req-kubectl-replace-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-replace-service-v1-core" aria-controls="req-curl-replace-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-replace-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ echo 'apiVersion: v1
-kind: Service
-metadata:
-  name: deployment-example
-  resourceVersion: "2205995"
-spec:
-  clusterIP: 10.183.250.161
-  ports:
-  - name: http
-    nodePort: 32417
-    port: 80
-    protocol: TCP
-    targetPort: 8080
-  selector:
-    app: nginx
-  sessionAffinity: None
-  type: LoadBalancer
-' | kubectl replace -f -
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-replace-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X PUT -H 'Content-Type: application/yaml' --data '
-apiVersion: v1
-kind: Service
-metadata:
-  name: deployment-example
-  resourceVersion: "2205995"
-spec:
-  clusterIP: 10.183.250.161
-  ports:
-  - name: http
-    nodePort: 32417
-    port: 80
-    protocol: TCP
-    targetPort: 8080
-  selector:
-    app: nginx
-  sessionAffinity: None
-  type: LoadBalancer
-' http://127.0.0.1:8001/api/v1/namespaces/default/services/deployment-example
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-replace-service-v1-core" aria-controls="res-kubectl-replace-service-v1-core"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-replace-service-v1-core" aria-controls="res-curl-replace-service-v1-core"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-replace-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-service "deployment-example" replaced
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-replace-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Service",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/api/v1/namespaces/default/services/deployment-example",
-    "uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-    "resourceVersion": "2208672",
-    "creationTimestamp": "2016-10-28T17:04:24Z"
-  },
-  "spec": {
-    "ports": [
-      {
-        "name": "http",
-        "protocol": "TCP",
-        "port": 80,
-        "targetPort": 8080,
-        "nodePort": 32417
-      }
-    ],
-    "selector": {
-      "app": "nginx"
-    },
-    "clusterIP": "10.183.250.161",
-    "type": "LoadBalancer",
-    "sessionAffinity": "None"
-  },
-  "status": {
-    "loadBalancer": {
-      "ingress": [
-        {
-          "ip": "104.198.186.106"
-        }
-      ]
-    }
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>replace the specified Service</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/services/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#service-v1-core">Service</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-service-v1-core">Delete</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-delete-service-v1-core" aria-controls="req-kubectl-delete-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-delete-service-v1-core" aria-controls="req-curl-delete-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-delete-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl delete service deployment-example
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-delete-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X DELETE -H 'Content-Type: application/yaml' --data '
-gracePeriodSeconds: 0
-orphanDependents: false
-' 'http://127.0.0.1:8001/api/v1/namespaces/default/services/deployment-example'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-delete-service-v1-core" aria-controls="res-kubectl-delete-service-v1-core"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-delete-service-v1-core" aria-controls="res-curl-delete-service-v1-core"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-delete-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-service "deployment-example" deleted
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-delete-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Status",
-  "apiVersion": "v1",
-  "metadata": {},
-  "status": "Success",
-  "code": 200
-}
-
-</CODE></PRE></DIV></DIV></DIV>
-<P>delete a Service</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/services/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-service-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-service-v1-core">Read</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-read-service-v1-core" aria-controls="req-kubectl-read-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-read-service-v1-core" aria-controls="req-curl-read-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-read-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get service deployment-example -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-read-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET http://127.0.0.1:8001/api/v1/namespaces/default/services/deployment-example
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-read-service-v1-core" aria-controls="res-kubectl-read-service-v1-core"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-read-service-v1-core" aria-controls="res-curl-read-service-v1-core"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-read-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-  "kind": "Service",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/api/v1/namespaces/default/services/deployment-example",
-    "uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-    "resourceVersion": "2205995",
-    "creationTimestamp": "2016-10-28T17:04:24Z"
-  },
-  "spec": {
-    "ports": [
-      {
-        "name": "http",
-        "protocol": "TCP",
-        "port": 80,
-        "targetPort": 8080,
-        "nodePort": 32417
-      }
-    ],
-    "selector": {
-      "app": "nginx"
-    },
-    "clusterIP": "10.183.250.161",
-    "type": "LoadBalancer",
-    "sessionAffinity": "None"
-  },
-  "status": {
-    "loadBalancer": {
-      "ingress": [
-        {
-          "ip": "104.198.186.106"
-        }
-      ]
-    }
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-read-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-  "kind": "Service",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "deployment-example",
-    "namespace": "default",
-    "selfLink": "/api/v1/namespaces/default/services/deployment-example",
-    "uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-    "resourceVersion": "2205995",
-    "creationTimestamp": "2016-10-28T17:04:24Z"
-  },
-  "spec": {
-    "ports": [
-      {
-        "name": "http",
-        "protocol": "TCP",
-        "port": 80,
-        "targetPort": 8080,
-        "nodePort": 32417
-      }
-    ],
-    "selector": {
-      "app": "nginx"
-    },
-    "clusterIP": "10.183.250.161",
-    "type": "LoadBalancer",
-    "sessionAffinity": "None"
-  },
-  "status": {
-    "loadBalancer": {
-      "ingress": [
-        {
-          "ip": "104.198.186.106"
-        }
-      ]
-    }
-  }
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>read the specified Service</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/services/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-service-v1-core">List</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-list-service-v1-core" aria-controls="req-kubectl-list-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-list-service-v1-core" aria-controls="req-curl-list-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-list-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get service -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-list-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET 'http://127.0.0.1:8001/api/v1/namespaces/default/services'
-</CODE></PRE></DIV></DIV></DIV>
-<P>list or watch objects of kind Service</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/services</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#servicelist-v1-core">ServiceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-service-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind Service</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/services</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#servicelist-v1-core">ServiceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-service-v1-core">Watch</H2>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-kubectl-watch-service-v1-core" aria-controls="req-kubectl-watch-service-v1-core"
-  aria-expanded="false">kubectl request example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#req-curl-watch-service-v1-core" aria-controls="req-curl-watch-service-v1-core"
-  aria-expanded="false">curl request example</BUTTON>
-<DIV class="collapse" id="req-kubectl-watch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>kubectl</CODE> command</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-shell">
-$ kubectl get service deployment-example --watch -o json
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="req-curl-watch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading"><CODE>curl</CODE> command (<I>requires <code>kubectl proxy</code> to be running</I>)</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-shell">
-$ kubectl proxy
-$ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/deployment-example'
-</CODE></PRE></DIV></DIV></DIV>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-kubectl-watch-service-v1-core" aria-controls="res-kubectl-watch-service-v1-core"
-  aria-expanded="false">kubectl response example</BUTTON>
-<BUTTON class="btn btn-info" type="button" data-toggle="collapse"
-  data-target="#res-curl-watch-service-v1-core" aria-controls="res-curl-watch-service-v1-core"
-  aria-expanded="false">curl response example</BUTTON>
-<DIV class="collapse" id="res-kubectl-watch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Output</DIV>
-  <DIV class="panel-body">
-<PRE class="kubectl"><CODE class="lang-json">
-{
-	"type": "ADDED",
-	"object": {
-		"kind": "Service",
-		"apiVersion": "v1",
-		"metadata": {
-			"name": "deployment-example",
-			"namespace": "default",
-			"selfLink": "/api/v1/namespaces/default/services/deployment-example",
-			"uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-			"resourceVersion": "2205995",
-			"creationTimestamp": "2016-10-28T17:04:24Z"
-		},
-		"spec": {
-			"ports": [
-				{
-					"name": "http",
-					"protocol": "TCP",
-					"port": 80,
-					"targetPort": 8080,
-					"nodePort": 32417
-				}
-			],
-			"selector": {
-				"app": "nginx"
-			},
-			"clusterIP": "10.183.250.161",
-			"type": "LoadBalancer",
-			"sessionAffinity": "None"
-		},
-		"status": {
-			"loadBalancer": {
-				"ingress": [
-					{
-						"ip": "104.198.186.106"
-					}
-				]
-			}
-		}
-	}
-}
-</CODE></PRE></DIV></DIV></DIV>
-<DIV class="collapse" id="res-curl-watch-service-v1-core">
-  <DIV class="panel panel-default">
-<DIV class="panel-heading">Response Body</DIV>
-  <DIV class="panel-body">
-<PRE class="curl"><CODE class="lang-json">
-{
-	"type": "ADDED",
-	"object": {
-		"kind": "Service",
-		"apiVersion": "v1",
-		"metadata": {
-			"name": "deployment-example",
-			"namespace": "default",
-			"selfLink": "/api/v1/namespaces/default/services/deployment-example",
-			"uid": "93e5c731-9d30-11e6-9c54-42010a800148",
-			"resourceVersion": "2205995",
-			"creationTimestamp": "2016-10-28T17:04:24Z"
-		},
-		"spec": {
-			"ports": [
-				{
-					"name": "http",
-					"protocol": "TCP",
-					"port": 80,
-					"targetPort": 8080,
-					"nodePort": 32417
-				}
-			],
-			"selector": {
-				"app": "nginx"
-			},
-			"clusterIP": "10.183.250.161",
-			"type": "LoadBalancer",
-			"sessionAffinity": "None"
-		},
-		"status": {
-			"loadBalancer": {
-				"ingress": [
-					{
-						"ip": "104.198.186.106"
-					}
-				]
-			}
-		}
-	}
-}
-</CODE></PRE></DIV></DIV></DIV>
-<P>watch changes to an object of kind Service. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/services/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-service-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Service. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/services</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-service-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Service. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/services</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-service-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-service-v1-core">Patch Status</H2>
-<P>partially update status of the specified Service</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/services/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-service-v1-core">Read Status</H2>
-<P>read status of the specified Service</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/services/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-service-v1-core">Replace Status</H2>
-<P>replace status of the specified Service</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/services/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Service</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#service-v1-core">Service</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#service-v1-core">Service</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-proxy-operations-service-v1-core-strong-"><STRONG>Proxy Operations</STRONG></H2>
-<H2 id="create-connect-proxy-service-v1-core">Create Connect Proxy</H2>
-<P>connect POST requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/services/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="create-connect-proxy-path-service-v1-core">Create Connect Proxy Path</H2>
-<P>connect POST requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/services/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-connect-proxy-service-v1-core">Delete Connect Proxy</H2>
-<P>connect DELETE requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/services/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-connect-proxy-path-service-v1-core">Delete Connect Proxy Path</H2>
-<P>connect DELETE requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/services/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-proxy-service-v1-core">Get Connect Proxy</H2>
-<P>connect GET requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/services/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-proxy-path-service-v1-core">Get Connect Proxy Path</H2>
-<P>connect GET requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/services/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="head-connect-proxy-service-v1-core">Head Connect Proxy</H2>
-<P>connect HEAD requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>HEAD /api/v1/namespaces/{namespace}/services/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="head-connect-proxy-path-service-v1-core">Head Connect Proxy Path</H2>
-<P>connect HEAD requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>HEAD /api/v1/namespaces/{namespace}/services/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-connect-proxy-service-v1-core">Replace Connect Proxy</H2>
-<P>connect PUT requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/services/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-connect-proxy-path-service-v1-core">Replace Connect Proxy Path</H2>
-<P>connect PUT requests to proxy of Service</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/services/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceProxyOptions</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the part of URLs that include service endpoints, suffixes, and parameters to use for the current proxy request to service. For example, the whole request URL is http://localhost/api/v1/namespaces/kube-system/services/elasticsearch-logging/_search?q=user:kimchy. Path is _search?q=user:kimchy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="-strong-config-and-storage-apis-strong-"><STRONG>CONFIG & STORAGE</STRONG></H1>
-
-<P>Config and Storage resources are responsible for injecting data into your applications and persisting data externally to your container.</P>
-
-<P>Common resource types:</P>
-<UL>
-<LI><A href="#configmap-v1-core">ConfigMaps</A>for providing text key value pairs injected into the application through environment variables, command line arguments, or files</LI>
-<LI><A href="#secret-v1-core">Secrets</A> for providing binary data injected into the application through files</LI>
-<LI><A href="#volume-v1-core">Volumes</A> for providing a filesystem external to the Container.  Maybe shared across Containers within the same Pod and have a lifetime persisting beyond a Container or Pod.</LI>
-</UL>
-<HR />
-<H1 id="configmap-v1-core">ConfigMap v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ConfigMap</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#configmaplist-v1-core">ConfigMapList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>binaryData</CODE><BR /><I>object</I></TD><TD>BinaryData contains the binary data. Each key must consist of alphanumeric characters, &#39;-&#39;, &#39;_&#39; or &#39;.&#39;. BinaryData can contain byte sequences that are not in the UTF-8 range. The keys stored in BinaryData must not overlap with the ones in the Data field, this is enforced during validation process. Using this field will require 1.10+ apiserver and kubelet.</TD></TR>
-<TR><TD><CODE>data</CODE><BR /><I>object</I></TD><TD>Data contains the configuration data. Each key must consist of alphanumeric characters, &#39;-&#39;, &#39;_&#39; or &#39;.&#39;. Values with non-UTF-8 byte sequences must use the BinaryData field. The keys stored in Data must not overlap with the keys in the BinaryData field, this is enforced during validation process.</TD></TR>
-<TR><TD><CODE>immutable</CODE><BR /><I>boolean</I></TD><TD>Immutable, if set to true, ensures that data stored in the ConfigMap cannot be updated (only object metadata can be modified). If not set to true, the field can be modified at any time. Defaulted to nil. This is an alpha field enabled by ImmutableEphemeralVolumes feature gate.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="configmaplist-v1-core">ConfigMapList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#configmap-v1-core">ConfigMap</a> array</I></TD><TD>Items is the list of ConfigMaps.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-configmap-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-configmap-v1-core">Create</H2>
-<P>create a ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/configmaps</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-configmap-v1-core">Patch</H2>
-<P>partially update the specified ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/configmaps/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ConfigMap</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-configmap-v1-core">Replace</H2>
-<P>replace the specified ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/configmaps/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ConfigMap</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-configmap-v1-core">Delete</H2>
-<P>delete a ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/configmaps/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ConfigMap</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-configmap-v1-core">Delete Collection</H2>
-<P>delete collection of ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/configmaps</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-configmap-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-configmap-v1-core">Read</H2>
-<P>read the specified ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/configmaps/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ConfigMap</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#configmap-v1-core">ConfigMap</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-configmap-v1-core">List</H2>
-<P>list or watch objects of kind ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/configmaps</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#configmaplist-v1-core">ConfigMapList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-configmap-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind ConfigMap</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/configmaps</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#configmaplist-v1-core">ConfigMapList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-configmap-v1-core">Watch</H2>
-<P>watch changes to an object of kind ConfigMap. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/configmaps/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ConfigMap</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-configmap-v1-core">Watch List</H2>
-<P>watch individual changes to a list of ConfigMap. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/configmaps</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-configmap-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of ConfigMap. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/configmaps</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="csidriver-v1-storage-k8s-io">CSIDriver v1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CSIDriver</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#csidriver-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csidriverlist-v1-storage-k8s-io">CSIDriverList [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata. metadata.Name indicates the name of the CSI driver that this object refers to; it MUST be the same name returned by the CSI GetPluginName() call for that driver. The driver name must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), dots (.), and alphanumerics between. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#csidriverspec-v1-storage-k8s-io">CSIDriverSpec</a></I></TD><TD>Specification of the CSI Driver.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csidriverspec-v1-storage-k8s-io">CSIDriverSpec v1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csidriver-v1-storage-k8s-io">CSIDriver [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attachRequired</CODE><BR /><I>boolean</I></TD><TD>attachRequired indicates this CSI volume driver requires an attach operation (because it implements the CSI ControllerPublishVolume() method), and that the Kubernetes attach detach controller should call the attach volume interface which checks the volumeattachment status and waits until the volume is attached before proceeding to mounting. The CSI external-attacher coordinates with CSI volume driver and updates the volumeattachment status when the attach operation is complete. If the CSIDriverRegistry feature gate is enabled and the value is specified to false, the attach operation will be skipped. Otherwise the attach operation will be called.</TD></TR>
-<TR><TD><CODE>podInfoOnMount</CODE><BR /><I>boolean</I></TD><TD>If set to true, podInfoOnMount indicates this CSI volume driver requires additional pod information (like podName, podUID, etc.) during mount operations. If set to false, pod information will not be passed on mount. Default is false. The CSI driver specifies podInfoOnMount as part of driver deployment. If true, Kubelet will pass pod information as VolumeContext in the CSI NodePublishVolume() calls. The CSI driver is responsible for parsing and validating the information passed in as VolumeContext. The following VolumeConext will be passed if podInfoOnMount is set to true. This list might grow, but the prefix will be used. &#34;csi.storage.k8s.io/pod.name&#34;: pod.Name &#34;csi.storage.k8s.io/pod.namespace&#34;: pod.Namespace &#34;csi.storage.k8s.io/pod.uid&#34;: string(pod.UID) &#34;csi.storage.k8s.io/ephemeral&#34;: &#34;true&#34; iff the volume is an ephemeral inline volume                                 defined by a CSIVolumeSource, otherwise &#34;false&#34;  &#34;csi.storage.k8s.io/ephemeral&#34; is a new feature in Kubernetes 1.16. It is only required for drivers which support both the &#34;Persistent&#34; and &#34;Ephemeral&#34; VolumeLifecycleMode. Other drivers can leave pod info disabled and/or ignore this field. As Kubernetes 1.15 doesn&#39;t support this field, drivers can only support one mode when deployed on such a cluster and the deployment determines which mode that is, for example via a command line parameter of the driver.</TD></TR>
-<TR><TD><CODE>volumeLifecycleModes</CODE><BR /><I>string array</I></TD><TD>volumeLifecycleModes defines what kind of volumes this CSI volume driver supports. The default if the list is empty is &#34;Persistent&#34;, which is the usage defined by the CSI specification and implemented in Kubernetes via the usual PV/PVC mechanism. The other mode is &#34;Ephemeral&#34;. In this mode, volumes are defined inline inside the pod spec with CSIVolumeSource and their lifecycle is tied to the lifecycle of that pod. A driver has to be aware of this because it is only going to get a NodePublishVolume call for such a volume. For more information about implementing this mode, see https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html A driver can support one or more of these modes and more modes may be added in the future. This field is beta.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csidriverlist-v1-storage-k8s-io">CSIDriverList v1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a> array</I></TD><TD>items is the list of CSIDriver</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-csidriver-v1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-csidriver-v1-storage-k8s-io">Create</H2>
-<P>create a CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-csidriver-v1-storage-k8s-io">Patch</H2>
-<P>partially update the specified CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-csidriver-v1-storage-k8s-io">Replace</H2>
-<P>replace the specified CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-csidriver-v1-storage-k8s-io">Delete</H2>
-<P>delete a CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-csidriver-v1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-csidriver-v1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-csidriver-v1-storage-k8s-io">Read</H2>
-<P>read the specified CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-csidriver-v1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriverlist-v1-storage-k8s-io">CSIDriverList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-csidriver-v1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CSIDriver. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-csidriver-v1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CSIDriver. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="csinode-v1-storage-k8s-io">CSINode v1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CSINode</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#csinode-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinodelist-v1-storage-k8s-io">CSINodeList [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>metadata.name must be the Kubernetes node name.</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#csinodespec-v1-storage-k8s-io">CSINodeSpec</a></I></TD><TD>spec is the specification of CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csinodespec-v1-storage-k8s-io">CSINodeSpec v1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinode-v1-storage-k8s-io">CSINode [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>drivers</CODE><BR /><I><a href="#csinodedriver-v1-storage-k8s-io">CSINodeDriver</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>drivers is a list of information of all CSI Drivers existing on a node. If all drivers in the list are uninstalled, this can become empty.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csinodelist-v1-storage-k8s-io">CSINodeList v1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a> array</I></TD><TD>items is the list of CSINode</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-csinode-v1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-csinode-v1-storage-k8s-io">Create</H2>
-<P>create a CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-csinode-v1-storage-k8s-io">Patch</H2>
-<P>partially update the specified CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-csinode-v1-storage-k8s-io">Replace</H2>
-<P>replace the specified CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-csinode-v1-storage-k8s-io">Delete</H2>
-<P>delete a CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-csinode-v1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-csinode-v1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-csinode-v1-storage-k8s-io">Read</H2>
-<P>read the specified CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-csinode-v1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinodelist-v1-storage-k8s-io">CSINodeList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-csinode-v1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CSINode. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-csinode-v1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CSINode. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="secret-v1-core">Secret v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Secret</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#secretlist-v1-core">SecretList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>data</CODE><BR /><I>object</I></TD><TD>Data contains the secret data. Each key must consist of alphanumeric characters, &#39;-&#39;, &#39;_&#39; or &#39;.&#39;. The serialized form of the secret data is a base64 encoded string, representing the arbitrary (possibly non-string) data value here. Described in https://tools.ietf.org/html/rfc4648#section-4</TD></TR>
-<TR><TD><CODE>immutable</CODE><BR /><I>boolean</I></TD><TD>Immutable, if set to true, ensures that data stored in the Secret cannot be updated (only object metadata can be modified). If not set to true, the field can be modified at any time. Defaulted to nil. This is an alpha field enabled by ImmutableEphemeralVolumes feature gate.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>stringData</CODE><BR /><I>object</I></TD><TD>stringData allows specifying non-binary secret data in string form. It is provided as a write-only convenience method. All keys and values are merged into the data field on write, overwriting any existing values. It is never output when reading from the API.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Used to facilitate programmatic handling of secret data.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="secretlist-v1-core">SecretList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#secret-v1-core">Secret</a> array</I></TD><TD>Items is a list of secret objects. More info: https://kubernetes.io/docs/concepts/configuration/secret</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-secret-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-secret-v1-core">Create</H2>
-<P>create a Secret</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/secrets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-secret-v1-core">Patch</H2>
-<P>partially update the specified Secret</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/secrets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Secret</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-secret-v1-core">Replace</H2>
-<P>replace the specified Secret</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/secrets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Secret</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-secret-v1-core">Delete</H2>
-<P>delete a Secret</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/secrets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Secret</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-secret-v1-core">Delete Collection</H2>
-<P>delete collection of Secret</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/secrets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-secret-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-secret-v1-core">Read</H2>
-<P>read the specified Secret</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/secrets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Secret</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#secret-v1-core">Secret</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-secret-v1-core">List</H2>
-<P>list or watch objects of kind Secret</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/secrets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#secretlist-v1-core">SecretList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-secret-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind Secret</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/secrets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#secretlist-v1-core">SecretList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-secret-v1-core">Watch</H2>
-<P>watch changes to an object of kind Secret. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/secrets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Secret</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-secret-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Secret. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/secrets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-secret-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Secret. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/secrets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="persistentvolumeclaim-v1-core">PersistentVolumeClaim v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PersistentVolumeClaim</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-bullhorn"></I> A <a href="#persistentvolume-v1-core">PersistentVolume</a> must be allocated in the cluster to use this.</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumeclaimlist-v1-core">PersistentVolumeClaimList [core/v1]</a></LI>
-  <LI><a href="#statefulsetspec-v1-apps">StatefulSetSpec [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#persistentvolumeclaimspec-v1-core">PersistentVolumeClaimSpec</a></I></TD><TD>Spec defines the desired characteristics of a volume requested by a pod author. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#persistentvolumeclaimstatus-v1-core">PersistentVolumeClaimStatus</a></I></TD><TD>Status represents the current information/status of a persistent volume claim. Read-only. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="persistentvolumeclaimspec-v1-core">PersistentVolumeClaimSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>accessModes</CODE><BR /><I>string array</I></TD><TD>AccessModes contains the desired access modes the volume should have. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1</TD></TR>
-<TR><TD><CODE>dataSource</CODE><BR /><I><a href="#typedlocalobjectreference-v1-core">TypedLocalObjectReference</a></I></TD><TD>This field can be used to specify either: * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot - Beta) * An existing PVC (PersistentVolumeClaim) * An existing custom resource/object that implements data population (Alpha) In order to use VolumeSnapshot object types, the appropriate feature gate must be enabled (VolumeSnapshotDataSource or AnyVolumeDataSource) If the provisioner or an external controller can support the specified data source, it will create a new volume based on the contents of the specified data source. If the specified data source is not supported, the volume will not be created and the failure will be reported as an event. In the future, we plan to support more data source types and the behavior of the provisioner may change.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I><a href="#resourcerequirements-v1-core">ResourceRequirements</a></I></TD><TD>Resources represents the minimum resources the volume should have. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>A label query over volumes to consider for binding.</TD></TR>
-<TR><TD><CODE>storageClassName</CODE><BR /><I>string</I></TD><TD>Name of the StorageClass required by the claim. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#class-1</TD></TR>
-<TR><TD><CODE>volumeMode</CODE><BR /><I>string</I></TD><TD>volumeMode defines what type of volume is required by the claim. Value of Filesystem is implied when not included in claim spec.</TD></TR>
-<TR><TD><CODE>volumeName</CODE><BR /><I>string</I></TD><TD>VolumeName is the binding reference to the PersistentVolume backing this claim.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="persistentvolumeclaimstatus-v1-core">PersistentVolumeClaimStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>accessModes</CODE><BR /><I>string array</I></TD><TD>AccessModes contains the actual access modes the volume backing the PVC has. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1</TD></TR>
-<TR><TD><CODE>capacity</CODE><BR /><I>object</I></TD><TD>Represents the actual resources of the underlying volume.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#persistentvolumeclaimcondition-v1-core">PersistentVolumeClaimCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Current Condition of persistent volume claim. If underlying persistent volume is being resized then the Condition will be set to &#39;ResizeStarted&#39;.</TD></TR>
-<TR><TD><CODE>phase</CODE><BR /><I>string</I></TD><TD>Phase represents the current phase of PersistentVolumeClaim.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="persistentvolumeclaimlist-v1-core">PersistentVolumeClaimList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a> array</I></TD><TD>A list of persistent volume claims. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-persistentvolumeclaim-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-persistentvolumeclaim-v1-core">Create</H2>
-<P>create a PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/persistentvolumeclaims</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-persistentvolumeclaim-v1-core">Patch</H2>
-<P>partially update the specified PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-persistentvolumeclaim-v1-core">Replace</H2>
-<P>replace the specified PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-persistentvolumeclaim-v1-core">Delete</H2>
-<P>delete a PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-persistentvolumeclaim-v1-core">Delete Collection</H2>
-<P>delete collection of PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-persistentvolumeclaim-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-persistentvolumeclaim-v1-core">Read</H2>
-<P>read the specified PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-persistentvolumeclaim-v1-core">List</H2>
-<P>list or watch objects of kind PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/persistentvolumeclaims</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaimlist-v1-core">PersistentVolumeClaimList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-persistentvolumeclaim-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/persistentvolumeclaims</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaimlist-v1-core">PersistentVolumeClaimList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-persistentvolumeclaim-v1-core">Watch</H2>
-<P>watch changes to an object of kind PersistentVolumeClaim. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/persistentvolumeclaims/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-persistentvolumeclaim-v1-core">Watch List</H2>
-<P>watch individual changes to a list of PersistentVolumeClaim. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/persistentvolumeclaims</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-persistentvolumeclaim-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of PersistentVolumeClaim. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/persistentvolumeclaims</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-persistentvolumeclaim-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-persistentvolumeclaim-v1-core">Patch Status</H2>
-<P>partially update status of the specified PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-persistentvolumeclaim-v1-core">Read Status</H2>
-<P>read status of the specified PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-persistentvolumeclaim-v1-core">Replace Status</H2>
-<P>replace status of the specified PersistentVolumeClaim</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolumeClaim</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="storageclass-v1-storage-k8s-io">StorageClass v1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StorageClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#storageclass-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#storageclasslist-v1-storage-k8s-io">StorageClassList [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowVolumeExpansion</CODE><BR /><I>boolean</I></TD><TD>AllowVolumeExpansion shows whether the storage class allow volume expand</TD></TR>
-<TR><TD><CODE>allowedTopologies</CODE><BR /><I><a href="#topologyselectorterm-v1-core">TopologySelectorTerm</a> array</I></TD><TD>Restrict the node topologies where volumes can be dynamically provisioned. Each volume plugin defines its own supported topology specifications. An empty TopologySelectorTerm list means there is no topology restriction. This field is only honored by servers that enable the VolumeScheduling feature.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>mountOptions</CODE><BR /><I>string array</I></TD><TD>Dynamically provisioned PersistentVolumes of this storage class are created with these mountOptions, e.g. [&#34;ro&#34;, &#34;soft&#34;]. Not validated - mount of the PVs will simply fail if one is invalid.</TD></TR>
-<TR><TD><CODE>parameters</CODE><BR /><I>object</I></TD><TD>Parameters holds the parameters for the provisioner that should create volumes of this storage class.</TD></TR>
-<TR><TD><CODE>provisioner</CODE><BR /><I>string</I></TD><TD>Provisioner indicates the type of the provisioner.</TD></TR>
-<TR><TD><CODE>reclaimPolicy</CODE><BR /><I>string</I></TD><TD>Dynamically provisioned PersistentVolumes of this storage class are created with this reclaimPolicy. Defaults to Delete.</TD></TR>
-<TR><TD><CODE>volumeBindingMode</CODE><BR /><I>string</I></TD><TD>VolumeBindingMode indicates how PersistentVolumeClaims should be provisioned and bound.  When unset, VolumeBindingImmediate is used. This field is only honored by servers that enable the VolumeScheduling feature.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="storageclasslist-v1-storage-k8s-io">StorageClassList v1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a> array</I></TD><TD>Items is the list of StorageClasses</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-storageclass-v1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-storageclass-v1-storage-k8s-io">Create</H2>
-<P>create a StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-storageclass-v1-storage-k8s-io">Patch</H2>
-<P>partially update the specified StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-storageclass-v1-storage-k8s-io">Replace</H2>
-<P>replace the specified StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-storageclass-v1-storage-k8s-io">Delete</H2>
-<P>delete a StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-storageclass-v1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-storageclass-v1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-storageclass-v1-storage-k8s-io">Read</H2>
-<P>read the specified StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-storageclass-v1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclasslist-v1-storage-k8s-io">StorageClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-storageclass-v1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind StorageClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-storageclass-v1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of StorageClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volume-v1-core">Volume v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Volume</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec [settings/v1alpha1]</a></LI>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>awsElasticBlockStore</CODE><BR /><I><a href="#awselasticblockstorevolumesource-v1-core">AWSElasticBlockStoreVolumeSource</a></I></TD><TD>AWSElasticBlockStore represents an AWS Disk resource that is attached to a kubelet&#39;s host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore</TD></TR>
-<TR><TD><CODE>azureDisk</CODE><BR /><I><a href="#azurediskvolumesource-v1-core">AzureDiskVolumeSource</a></I></TD><TD>AzureDisk represents an Azure Data Disk mount on the host and bind mount to the pod.</TD></TR>
-<TR><TD><CODE>azureFile</CODE><BR /><I><a href="#azurefilevolumesource-v1-core">AzureFileVolumeSource</a></I></TD><TD>AzureFile represents an Azure File Service mount on the host and bind mount to the pod.</TD></TR>
-<TR><TD><CODE>cephfs</CODE><BR /><I><a href="#cephfsvolumesource-v1-core">CephFSVolumeSource</a></I></TD><TD>CephFS represents a Ceph FS mount on the host that shares a pod&#39;s lifetime</TD></TR>
-<TR><TD><CODE>cinder</CODE><BR /><I><a href="#cindervolumesource-v1-core">CinderVolumeSource</a></I></TD><TD>Cinder represents a cinder volume attached and mounted on kubelets host machine. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-<TR><TD><CODE>configMap</CODE><BR /><I><a href="#configmapvolumesource-v1-core">ConfigMapVolumeSource</a></I></TD><TD>ConfigMap represents a configMap that should populate this volume</TD></TR>
-<TR><TD><CODE>csi</CODE><BR /><I><a href="#csivolumesource-v1-core">CSIVolumeSource</a></I></TD><TD>CSI (Container Storage Interface) represents storage that is handled by an external CSI driver (Alpha feature).</TD></TR>
-<TR><TD><CODE>downwardAPI</CODE><BR /><I><a href="#downwardapivolumesource-v1-core">DownwardAPIVolumeSource</a></I></TD><TD>DownwardAPI represents downward API about the pod that should populate this volume</TD></TR>
-<TR><TD><CODE>emptyDir</CODE><BR /><I><a href="#emptydirvolumesource-v1-core">EmptyDirVolumeSource</a></I></TD><TD>EmptyDir represents a temporary directory that shares a pod&#39;s lifetime. More info: https://kubernetes.io/docs/concepts/storage/volumes#emptydir</TD></TR>
-<TR><TD><CODE>fc</CODE><BR /><I><a href="#fcvolumesource-v1-core">FCVolumeSource</a></I></TD><TD>FC represents a Fibre Channel resource that is attached to a kubelet&#39;s host machine and then exposed to the pod.</TD></TR>
-<TR><TD><CODE>flexVolume</CODE><BR /><I><a href="#flexvolumesource-v1-core">FlexVolumeSource</a></I></TD><TD>FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin.</TD></TR>
-<TR><TD><CODE>flocker</CODE><BR /><I><a href="#flockervolumesource-v1-core">FlockerVolumeSource</a></I></TD><TD>Flocker represents a Flocker volume attached to a kubelet&#39;s host machine. This depends on the Flocker control service being running</TD></TR>
-<TR><TD><CODE>gcePersistentDisk</CODE><BR /><I><a href="#gcepersistentdiskvolumesource-v1-core">GCEPersistentDiskVolumeSource</a></I></TD><TD>GCEPersistentDisk represents a GCE Disk resource that is attached to a kubelet&#39;s host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk</TD></TR>
-<TR><TD><CODE>gitRepo</CODE><BR /><I><a href="#gitrepovolumesource-v1-core">GitRepoVolumeSource</a></I></TD><TD>GitRepo represents a git repository at a particular revision. DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mount an EmptyDir into an InitContainer that clones the repo using git, then mount the EmptyDir into the Pod&#39;s container.</TD></TR>
-<TR><TD><CODE>glusterfs</CODE><BR /><I><a href="#glusterfsvolumesource-v1-core">GlusterfsVolumeSource</a></I></TD><TD>Glusterfs represents a Glusterfs mount on the host that shares a pod&#39;s lifetime. More info: https://examples.k8s.io/volumes/glusterfs/README.md</TD></TR>
-<TR><TD><CODE>hostPath</CODE><BR /><I><a href="#hostpathvolumesource-v1-core">HostPathVolumeSource</a></I></TD><TD>HostPath represents a pre-existing file or directory on the host machine that is directly exposed to the container. This is generally used for system agents or other privileged things that are allowed to see the host machine. Most containers will NOT need this. More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath</TD></TR>
-<TR><TD><CODE>iscsi</CODE><BR /><I><a href="#iscsivolumesource-v1-core">ISCSIVolumeSource</a></I></TD><TD>ISCSI represents an ISCSI Disk resource that is attached to a kubelet&#39;s host machine and then exposed to the pod. More info: https://examples.k8s.io/volumes/iscsi/README.md</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Volume&#39;s name. Must be a DNS_LABEL and unique within the pod. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>nfs</CODE><BR /><I><a href="#nfsvolumesource-v1-core">NFSVolumeSource</a></I></TD><TD>NFS represents an NFS mount on the host that shares a pod&#39;s lifetime More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs</TD></TR>
-<TR><TD><CODE>persistentVolumeClaim</CODE><BR /><I><a href="#persistentvolumeclaimvolumesource-v1-core">PersistentVolumeClaimVolumeSource</a></I></TD><TD>PersistentVolumeClaimVolumeSource represents a reference to a PersistentVolumeClaim in the same namespace. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims</TD></TR>
-<TR><TD><CODE>photonPersistentDisk</CODE><BR /><I><a href="#photonpersistentdiskvolumesource-v1-core">PhotonPersistentDiskVolumeSource</a></I></TD><TD>PhotonPersistentDisk represents a PhotonController persistent disk attached and mounted on kubelets host machine</TD></TR>
-<TR><TD><CODE>portworxVolume</CODE><BR /><I><a href="#portworxvolumesource-v1-core">PortworxVolumeSource</a></I></TD><TD>PortworxVolume represents a portworx volume attached and mounted on kubelets host machine</TD></TR>
-<TR><TD><CODE>projected</CODE><BR /><I><a href="#projectedvolumesource-v1-core">ProjectedVolumeSource</a></I></TD><TD>Items for all in one resources secrets, configmaps, and downward API</TD></TR>
-<TR><TD><CODE>quobyte</CODE><BR /><I><a href="#quobytevolumesource-v1-core">QuobyteVolumeSource</a></I></TD><TD>Quobyte represents a Quobyte mount on the host that shares a pod&#39;s lifetime</TD></TR>
-<TR><TD><CODE>rbd</CODE><BR /><I><a href="#rbdvolumesource-v1-core">RBDVolumeSource</a></I></TD><TD>RBD represents a Rados Block Device mount on the host that shares a pod&#39;s lifetime. More info: https://examples.k8s.io/volumes/rbd/README.md</TD></TR>
-<TR><TD><CODE>scaleIO</CODE><BR /><I><a href="#scaleiovolumesource-v1-core">ScaleIOVolumeSource</a></I></TD><TD>ScaleIO represents a ScaleIO persistent volume attached and mounted on Kubernetes nodes.</TD></TR>
-<TR><TD><CODE>secret</CODE><BR /><I><a href="#secretvolumesource-v1-core">SecretVolumeSource</a></I></TD><TD>Secret represents a secret that should populate this volume. More info: https://kubernetes.io/docs/concepts/storage/volumes#secret</TD></TR>
-<TR><TD><CODE>storageos</CODE><BR /><I><a href="#storageosvolumesource-v1-core">StorageOSVolumeSource</a></I></TD><TD>StorageOS represents a StorageOS volume attached and mounted on Kubernetes nodes.</TD></TR>
-<TR><TD><CODE>vsphereVolume</CODE><BR /><I><a href="#vspherevirtualdiskvolumesource-v1-core">VsphereVirtualDiskVolumeSource</a></I></TD><TD>VsphereVolume represents a vSphere volume attached and mounted on kubelets host machine</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeattachment-v1-storage-k8s-io">VolumeAttachment v1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeAttachment</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeattachment-v1beta1-storage-k8s-io">v1beta1</a>
-<a href="#volumeattachment-v1alpha1-storage-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentlist-v1-storage-k8s-io">VolumeAttachmentList [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#volumeattachmentspec-v1-storage-k8s-io">VolumeAttachmentSpec</a></I></TD><TD>Specification of the desired attach/detach volume behavior. Populated by the Kubernetes system.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#volumeattachmentstatus-v1-storage-k8s-io">VolumeAttachmentStatus</a></I></TD><TD>Status of the VolumeAttachment request. Populated by the entity completing the attach or detach operation, i.e. the external-attacher.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentspec-v1-storage-k8s-io">VolumeAttachmentSpec v1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attacher</CODE><BR /><I>string</I></TD><TD>Attacher indicates the name of the volume driver that MUST handle this request. This is the name returned by GetPluginName().</TD></TR>
-<TR><TD><CODE>nodeName</CODE><BR /><I>string</I></TD><TD>The node that the volume should be attached to.</TD></TR>
-<TR><TD><CODE>source</CODE><BR /><I><a href="#volumeattachmentsource-v1-storage-k8s-io">VolumeAttachmentSource</a></I></TD><TD>Source represents the volume that should be attached.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentstatus-v1-storage-k8s-io">VolumeAttachmentStatus v1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attachError</CODE><BR /><I><a href="#volumeerror-v1-storage-k8s-io">VolumeError</a></I></TD><TD>The last error encountered during attach operation, if any. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>attached</CODE><BR /><I>boolean</I></TD><TD>Indicates the volume is successfully attached. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>attachmentMetadata</CODE><BR /><I>object</I></TD><TD>Upon successful attach, this field is populated with any information returned by the attach operation that must be passed into subsequent WaitForAttach or Mount calls. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>detachError</CODE><BR /><I><a href="#volumeerror-v1-storage-k8s-io">VolumeError</a></I></TD><TD>The last error encountered during detach operation, if any. This field must only be set by the entity completing the detach operation, i.e. the external-attacher.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentlist-v1-storage-k8s-io">VolumeAttachmentList v1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a> array</I></TD><TD>Items is the list of VolumeAttachments</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-volumeattachment-v1-storage-k8s-io">Create</H2>
-<P>create a VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-volumeattachment-v1-storage-k8s-io">Patch</H2>
-<P>partially update the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-volumeattachment-v1-storage-k8s-io">Replace</H2>
-<P>replace the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-volumeattachment-v1-storage-k8s-io">Delete</H2>
-<P>delete a VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-volumeattachment-v1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-volumeattachment-v1-storage-k8s-io">Read</H2>
-<P>read the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-volumeattachment-v1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachmentlist-v1-storage-k8s-io">VolumeAttachmentList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-volumeattachment-v1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind VolumeAttachment. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-volumeattachment-v1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of VolumeAttachment. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/watch/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-volumeattachment-v1-storage-k8s-io">Patch Status</H2>
-<P>partially update status of the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-volumeattachment-v1-storage-k8s-io">Read Status</H2>
-<P>read status of the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1/volumeattachments/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-volumeattachment-v1-storage-k8s-io">Replace Status</H2>
-<P>replace status of the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1/volumeattachments/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="-strong-metadata-apis-strong-"><STRONG>METADATA</STRONG></H1>
-
-<P>Metadata resources are responsible for configuring behavior of your other Resources within the Cluster.</P>
-
-<P>Common resource types:</P>
-<UL>
-<LI><A href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</A> (HPA) for automatically scaling the replicacount of your workloads in response to load.</LI>
-<LI><A href="#poddisruptionbudget-v1alpha1">PodDisruptionBudget</A> for configuring how many replicas in a given workload maybe made concurrently unavailable when performing maintenance.</LI>
-<LI><A href="#event-v1-core">Event</A> for notification of resource lifecycle events in the cluster.</LI>
-</UL>
-<HR />
-<H1 id="controllerrevision-v1-apps">ControllerRevision v1 apps</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ControllerRevision</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#controllerrevisionlist-v1-apps">ControllerRevisionList [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>data</CODE></TD><TD>Data is the serialized representation of the state.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>revision</CODE><BR /><I>integer</I></TD><TD>Revision indicates the revision of the state represented by Data.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="controllerrevisionlist-v1-apps">ControllerRevisionList v1 apps</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a> array</I></TD><TD>Items is the list of ControllerRevisions</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-controllerrevision-v1-apps-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-controllerrevision-v1-apps">Create</H2>
-<P>create a ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apps/v1/namespaces/{namespace}/controllerrevisions</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-controllerrevision-v1-apps">Patch</H2>
-<P>partially update the specified ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ControllerRevision</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-controllerrevision-v1-apps">Replace</H2>
-<P>replace the specified ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ControllerRevision</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-controllerrevision-v1-apps">Delete</H2>
-<P>delete a ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ControllerRevision</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-controllerrevision-v1-apps">Delete Collection</H2>
-<P>delete collection of ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apps/v1/namespaces/{namespace}/controllerrevisions</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-controllerrevision-v1-apps-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-controllerrevision-v1-apps">Read</H2>
-<P>read the specified ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ControllerRevision</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#controllerrevision-v1-apps">ControllerRevision</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-controllerrevision-v1-apps">List</H2>
-<P>list or watch objects of kind ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/namespaces/{namespace}/controllerrevisions</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#controllerrevisionlist-v1-apps">ControllerRevisionList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-controllerrevision-v1-apps">List All Namespaces</H2>
-<P>list or watch objects of kind ControllerRevision</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/controllerrevisions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#controllerrevisionlist-v1-apps">ControllerRevisionList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-controllerrevision-v1-apps">Watch</H2>
-<P>watch changes to an object of kind ControllerRevision. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/controllerrevisions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ControllerRevision</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-controllerrevision-v1-apps">Watch List</H2>
-<P>watch individual changes to a list of ControllerRevision. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/namespaces/{namespace}/controllerrevisions</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-controllerrevision-v1-apps">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of ControllerRevision. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apps/v1/watch/controllerrevisions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition v1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceDefinition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionlist-v1-apiextensions-k8s-io">CustomResourceDefinitionList [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#customresourcedefinitionspec-v1-apiextensions-k8s-io">CustomResourceDefinitionSpec</a></I></TD><TD>spec describes how the user wants the resources to appear</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#customresourcedefinitionstatus-v1-apiextensions-k8s-io">CustomResourceDefinitionStatus</a></I></TD><TD>status indicates the actual state of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="customresourcedefinitionspec-v1-apiextensions-k8s-io">CustomResourceDefinitionSpec v1 apiextensions</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conversion</CODE><BR /><I><a href="#customresourceconversion-v1-apiextensions-k8s-io">CustomResourceConversion</a></I></TD><TD>conversion defines conversion settings for the CRD.</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>group is the API group of the defined custom resource. The custom resources are served under `/apis/&lt;group&gt;/...`. Must match the name of the CustomResourceDefinition (in the form `&lt;names.plural&gt;.&lt;group&gt;`).</TD></TR>
-<TR><TD><CODE>names</CODE><BR /><I><a href="#customresourcedefinitionnames-v1-apiextensions-k8s-io">CustomResourceDefinitionNames</a></I></TD><TD>names specify the resource and kind names for the custom resource.</TD></TR>
-<TR><TD><CODE>preserveUnknownFields</CODE><BR /><I>boolean</I></TD><TD>preserveUnknownFields indicates that object fields which are not specified in the OpenAPI schema should be preserved when persisting to storage. apiVersion, kind, metadata and known fields inside metadata are always preserved. This field is deprecated in favor of setting `x-preserve-unknown-fields` to true in `spec.versions[*].schema.openAPIV3Schema`. See https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#pruning-versus-preserving-unknown-fields for details.</TD></TR>
-<TR><TD><CODE>scope</CODE><BR /><I>string</I></TD><TD>scope indicates whether the defined custom resource is cluster- or namespace-scoped. Allowed values are `Cluster` and `Namespaced`.</TD></TR>
-<TR><TD><CODE>versions</CODE><BR /><I><a href="#customresourcedefinitionversion-v1-apiextensions-k8s-io">CustomResourceDefinitionVersion</a> array</I></TD><TD>versions is the list of all API versions of the defined custom resource. Version names are used to compute the order in which served versions are listed in API discovery. If the version string is &#34;kube-like&#34;, it will sort above non &#34;kube-like&#34; version strings, which are ordered lexicographically. &#34;Kube-like&#34; versions start with a &#34;v&#34;, then are followed by a number (the major version), then optionally the string &#34;alpha&#34; or &#34;beta&#34; and another number (the minor version). These are sorted first by GA &gt; beta &gt; alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="customresourcedefinitionstatus-v1-apiextensions-k8s-io">CustomResourceDefinitionStatus v1 apiextensions</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>acceptedNames</CODE><BR /><I><a href="#customresourcedefinitionnames-v1-apiextensions-k8s-io">CustomResourceDefinitionNames</a></I></TD><TD>acceptedNames are the names that are actually being used to serve discovery. They may be different than the names in spec.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#customresourcedefinitioncondition-v1-apiextensions-k8s-io">CustomResourceDefinitionCondition</a> array</I></TD><TD>conditions indicate state for particular aspects of a CustomResourceDefinition</TD></TR>
-<TR><TD><CODE>storedVersions</CODE><BR /><I>string array</I></TD><TD>storedVersions lists all versions of CustomResources that were ever persisted. Tracking these versions allows a migration path for stored versions in etcd. The field is mutable so a migration controller can finish a migration to another version (ensuring no old objects are left in storage), and then remove the rest of the versions from this list. Versions may not be removed from `spec.versions` while they exist in this list.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="customresourcedefinitionlist-v1-apiextensions-k8s-io">CustomResourceDefinitionList v1 apiextensions</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a> array</I></TD><TD>items list individual CustomResourceDefinition objects</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-customresourcedefinition-v1-apiextensions-k8s-io">Create</H2>
-<P>create a CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apiextensions.k8s.io/v1/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-customresourcedefinition-v1-apiextensions-k8s-io">Patch</H2>
-<P>partially update the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-customresourcedefinition-v1-apiextensions-k8s-io">Replace</H2>
-<P>replace the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-customresourcedefinition-v1-apiextensions-k8s-io">Delete</H2>
-<P>delete a CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-customresourcedefinition-v1-apiextensions-k8s-io">Delete Collection</H2>
-<P>delete collection of CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiextensions.k8s.io/v1/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-customresourcedefinition-v1-apiextensions-k8s-io">Read</H2>
-<P>read the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-customresourcedefinition-v1-apiextensions-k8s-io">List</H2>
-<P>list or watch objects of kind CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinitionlist-v1-apiextensions-k8s-io">CustomResourceDefinitionList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-customresourcedefinition-v1-apiextensions-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CustomResourceDefinition. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1/watch/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-customresourcedefinition-v1-apiextensions-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CustomResourceDefinition. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1/watch/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-customresourcedefinition-v1-apiextensions-k8s-io">Patch Status</H2>
-<P>partially update status of the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-customresourcedefinition-v1-apiextensions-k8s-io">Read Status</H2>
-<P>read status of the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-customresourcedefinition-v1-apiextensions-k8s-io">Replace Status</H2>
-<P>replace status of the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="event-v1-core">Event v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Event</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#event-v1beta1-events-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#eventlist-v1-core">EventList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>action</CODE><BR /><I>string</I></TD><TD>What action was taken/failed regarding to the Regarding object.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>count</CODE><BR /><I>integer</I></TD><TD>The number of times this event has occurred.</TD></TR>
-<TR><TD><CODE>eventTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>Time when this Event was first observed.</TD></TR>
-<TR><TD><CODE>firstTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>The time at which the event was first recorded. (Time of server receipt is in TypeMeta.)</TD></TR>
-<TR><TD><CODE>involvedObject</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>The object that this event is about.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>lastTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>The time at which the most recent occurrence of this event was recorded.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human-readable description of the status of this operation.</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>This should be a short, machine understandable string that gives the reason for the transition into the object&#39;s current status.</TD></TR>
-<TR><TD><CODE>related</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>Optional secondary object for more complex actions.</TD></TR>
-<TR><TD><CODE>reportingComponent</CODE><BR /><I>string</I></TD><TD>Name of the controller that emitted this Event, e.g. `kubernetes.io/kubelet`.</TD></TR>
-<TR><TD><CODE>reportingInstance</CODE><BR /><I>string</I></TD><TD>ID of the controller instance, e.g. `kubelet-xyzf`.</TD></TR>
-<TR><TD><CODE>series</CODE><BR /><I><a href="#eventseries-v1-core">EventSeries</a></I></TD><TD>Data about the Event series this event represents or nil if it&#39;s a singleton Event.</TD></TR>
-<TR><TD><CODE>source</CODE><BR /><I><a href="#eventsource-v1-core">EventSource</a></I></TD><TD>The component reporting this event. Should be a short machine understandable string.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of this event (Normal, Warning), new types could be added in the future</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="eventlist-v1-core">EventList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#event-v1-core">Event</a> array</I></TD><TD>List of events</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-event-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-event-v1-core">Create</H2>
-<P>create an Event</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#event-v1-core">Event</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-event-v1-core">Patch</H2>
-<P>partially update the specified Event</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-event-v1-core">Replace</H2>
-<P>replace the specified Event</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#event-v1-core">Event</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-event-v1-core">Delete</H2>
-<P>delete an Event</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-event-v1-core">Delete Collection</H2>
-<P>delete collection of Event</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-event-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-event-v1-core">Read</H2>
-<P>read the specified Event</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1-core">Event</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-event-v1-core">List</H2>
-<P>list or watch objects of kind Event</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#eventlist-v1-core">EventList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-event-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind Event</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/events</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#eventlist-v1-core">EventList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-event-v1-core">Watch</H2>
-<P>watch changes to an object of kind Event. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-event-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Event. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-event-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Event. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/events</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="limitrange-v1-core">LimitRange v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LimitRange</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#limitrangelist-v1-core">LimitRangeList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#limitrangespec-v1-core">LimitRangeSpec</a></I></TD><TD>Spec defines the limits enforced. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="limitrangespec-v1-core">LimitRangeSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#limitrange-v1-core">LimitRange [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>limits</CODE><BR /><I><a href="#limitrangeitem-v1-core">LimitRangeItem</a> array</I></TD><TD>Limits is the list of LimitRangeItem objects that are enforced.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="limitrangelist-v1-core">LimitRangeList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#limitrange-v1-core">LimitRange</a> array</I></TD><TD>Items is a list of LimitRange objects. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-limitrange-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-limitrange-v1-core">Create</H2>
-<P>create a LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/limitranges</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-limitrange-v1-core">Patch</H2>
-<P>partially update the specified LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/limitranges/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the LimitRange</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-limitrange-v1-core">Replace</H2>
-<P>replace the specified LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/limitranges/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the LimitRange</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-limitrange-v1-core">Delete</H2>
-<P>delete a LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/limitranges/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the LimitRange</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-limitrange-v1-core">Delete Collection</H2>
-<P>delete collection of LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/limitranges</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-limitrange-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-limitrange-v1-core">Read</H2>
-<P>read the specified LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/limitranges/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the LimitRange</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#limitrange-v1-core">LimitRange</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-limitrange-v1-core">List</H2>
-<P>list or watch objects of kind LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/limitranges</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#limitrangelist-v1-core">LimitRangeList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-limitrange-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind LimitRange</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/limitranges</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#limitrangelist-v1-core">LimitRangeList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-limitrange-v1-core">Watch</H2>
-<P>watch changes to an object of kind LimitRange. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/limitranges/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the LimitRange</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-limitrange-v1-core">Watch List</H2>
-<P>watch individual changes to a list of LimitRange. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/limitranges</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-limitrange-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of LimitRange. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/limitranges</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler v1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>HorizontalPodAutoscaler</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#horizontalpodautoscaler-v2beta2-autoscaling">v2beta2</a>
-<a href="#horizontalpodautoscaler-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerlist-v1-autoscaling">HorizontalPodAutoscalerList [autoscaling/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#horizontalpodautoscalerspec-v1-autoscaling">HorizontalPodAutoscalerSpec</a></I></TD><TD>behaviour of autoscaler. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#horizontalpodautoscalerstatus-v1-autoscaling">HorizontalPodAutoscalerStatus</a></I></TD><TD>current information about the autoscaler.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerspec-v1-autoscaling">HorizontalPodAutoscalerSpec v1 autoscaling</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler [autoscaling/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>maxReplicas</CODE><BR /><I>integer</I></TD><TD>upper limit for the number of pods that can be set by the autoscaler; cannot be smaller than MinReplicas.</TD></TR>
-<TR><TD><CODE>minReplicas</CODE><BR /><I>integer</I></TD><TD>minReplicas is the lower limit for the number of replicas to which the autoscaler can scale down.  It defaults to 1 pod.  minReplicas is allowed to be 0 if the alpha feature gate HPAScaleToZero is enabled and at least one Object or External metric is configured.  Scaling is active as long as at least one metric value is available.</TD></TR>
-<TR><TD><CODE>scaleTargetRef</CODE><BR /><I><a href="#crossversionobjectreference-v1-autoscaling">CrossVersionObjectReference</a></I></TD><TD>reference to scaled resource; horizontal pod autoscaler will learn the current resource consumption and will set the desired number of pods by using its Scale subresource.</TD></TR>
-<TR><TD><CODE>targetCPUUtilizationPercentage</CODE><BR /><I>integer</I></TD><TD>target average CPU utilization (represented as a percentage of requested CPU) over all the pods; if not specified the default autoscaling policy will be used.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerstatus-v1-autoscaling">HorizontalPodAutoscalerStatus v1 autoscaling</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler [autoscaling/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>currentCPUUtilizationPercentage</CODE><BR /><I>integer</I></TD><TD>current average CPU utilization over all pods, represented as a percentage of requested CPU, e.g. 70 means that an average pod is using now 70% of its requested CPU.</TD></TR>
-<TR><TD><CODE>currentReplicas</CODE><BR /><I>integer</I></TD><TD>current number of replicas of pods managed by this autoscaler.</TD></TR>
-<TR><TD><CODE>desiredReplicas</CODE><BR /><I>integer</I></TD><TD>desired number of replicas of pods managed by this autoscaler.</TD></TR>
-<TR><TD><CODE>lastScaleTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>last time the HorizontalPodAutoscaler scaled the number of pods; used by the autoscaler to control how often the number of pods is changed.</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>most recent generation observed by this autoscaler.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerlist-v1-autoscaling">HorizontalPodAutoscalerList v1 autoscaling</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a> array</I></TD><TD>list of horizontal pod autoscaler objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-horizontalpodautoscaler-v1-autoscaling">Create</H2>
-<P>create a HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-horizontalpodautoscaler-v1-autoscaling">Patch</H2>
-<P>partially update the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-horizontalpodautoscaler-v1-autoscaling">Replace</H2>
-<P>replace the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-horizontalpodautoscaler-v1-autoscaling">Delete</H2>
-<P>delete a HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-horizontalpodautoscaler-v1-autoscaling">Delete Collection</H2>
-<P>delete collection of HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-horizontalpodautoscaler-v1-autoscaling">Read</H2>
-<P>read the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-horizontalpodautoscaler-v1-autoscaling">List</H2>
-<P>list or watch objects of kind HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscalerlist-v1-autoscaling">HorizontalPodAutoscalerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-horizontalpodautoscaler-v1-autoscaling">List All Namespaces</H2>
-<P>list or watch objects of kind HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/horizontalpodautoscalers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscalerlist-v1-autoscaling">HorizontalPodAutoscalerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-horizontalpodautoscaler-v1-autoscaling">Watch</H2>
-<P>watch changes to an object of kind HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/watch/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-horizontalpodautoscaler-v1-autoscaling">Watch List</H2>
-<P>watch individual changes to a list of HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/watch/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/watch/horizontalpodautoscalers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-horizontalpodautoscaler-v1-autoscaling">Patch Status</H2>
-<P>partially update status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-horizontalpodautoscaler-v1-autoscaling">Read Status</H2>
-<P>read status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-horizontalpodautoscaler-v1-autoscaling">Replace Status</H2>
-<P>replace status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration v1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>MutatingWebhookConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">MutatingWebhookConfigurationList [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.</TD></TR>
-<TR><TD><CODE>webhooks</CODE><BR /><I><a href="#mutatingwebhook-v1-admissionregistration-k8s-io">MutatingWebhook</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>Webhooks is a list of webhooks and the affected resources and operations.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="mutatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">MutatingWebhookConfigurationList v1 admissionregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a> array</I></TD><TD>List of MutatingWebhookConfiguration.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Create</H2>
-<P>create a MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Patch</H2>
-<P>partially update the specified MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Replace</H2>
-<P>replace the specified MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Delete</H2>
-<P>delete a MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Read</H2>
-<P>read the specified MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">List</H2>
-<P>list or watch objects of kind MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">MutatingWebhookConfigurationList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind MutatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/watch/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of MutatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/watch/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration v1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ValidatingWebhookConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#validatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.</TD></TR>
-<TR><TD><CODE>webhooks</CODE><BR /><I><a href="#validatingwebhook-v1-admissionregistration-k8s-io">ValidatingWebhook</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>Webhooks is a list of webhooks and the affected resources and operations.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="validatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList v1 admissionregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a> array</I></TD><TD>List of ValidatingWebhookConfiguration.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Create</H2>
-<P>create a ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Patch</H2>
-<P>partially update the specified ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Replace</H2>
-<P>replace the specified ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Delete</H2>
-<P>delete a ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Read</H2>
-<P>read the specified ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">List</H2>
-<P>list or watch objects of kind ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ValidatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/watch/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ValidatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1/watch/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="podtemplate-v1-core">PodTemplate v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodTemplate</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podtemplatelist-v1-core">PodTemplateList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>template</CODE><BR /><I><a href="#podtemplatespec-v1-core">PodTemplateSpec</a></I></TD><TD>Template defines the pods that will be created from this pod template. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podtemplatespec-v1-core">PodTemplateSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonsetspec-v1-apps">DaemonSetSpec [apps/v1]</a></LI>
-  <LI><a href="#deploymentspec-v1-apps">DeploymentSpec [apps/v1]</a></LI>
-  <LI><a href="#jobspec-v1-batch">JobSpec [batch/v1]</a></LI>
-  <LI><a href="#podtemplate-v1-core">PodTemplate [core/v1]</a></LI>
-  <LI><a href="#replicasetspec-v1-apps">ReplicaSetSpec [apps/v1]</a></LI>
-  <LI><a href="#replicationcontrollerspec-v1-core">ReplicationControllerSpec [core/v1]</a></LI>
-  <LI><a href="#statefulsetspec-v1-apps">StatefulSetSpec [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#podspec-v1-core">PodSpec</a></I></TD><TD>Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podtemplatelist-v1-core">PodTemplateList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#podtemplate-v1-core">PodTemplate</a> array</I></TD><TD>List of pod templates</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-podtemplate-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-podtemplate-v1-core">Create</H2>
-<P>create a PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/podtemplates</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-podtemplate-v1-core">Patch</H2>
-<P>partially update the specified PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/podtemplates/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodTemplate</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-podtemplate-v1-core">Replace</H2>
-<P>replace the specified PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/podtemplates/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodTemplate</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-podtemplate-v1-core">Delete</H2>
-<P>delete a PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/podtemplates/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodTemplate</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-podtemplate-v1-core">Delete Collection</H2>
-<P>delete collection of PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/podtemplates</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-podtemplate-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-podtemplate-v1-core">Read</H2>
-<P>read the specified PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/podtemplates/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodTemplate</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplate-v1-core">PodTemplate</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-podtemplate-v1-core">List</H2>
-<P>list or watch objects of kind PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/podtemplates</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplatelist-v1-core">PodTemplateList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-podtemplate-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind PodTemplate</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/podtemplates</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podtemplatelist-v1-core">PodTemplateList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-podtemplate-v1-core">Watch</H2>
-<P>watch changes to an object of kind PodTemplate. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/podtemplates/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodTemplate</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-podtemplate-v1-core">Watch List</H2>
-<P>watch individual changes to a list of PodTemplate. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/podtemplates</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-podtemplate-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of PodTemplate. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/podtemplates</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="poddisruptionbudget-v1beta1-policy">PodDisruptionBudget v1beta1 policy</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>PodDisruptionBudget</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#poddisruptionbudgetlist-v1beta1-policy">PodDisruptionBudgetList [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#poddisruptionbudgetspec-v1beta1-policy">PodDisruptionBudgetSpec</a></I></TD><TD>Specification of the desired behavior of the PodDisruptionBudget.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#poddisruptionbudgetstatus-v1beta1-policy">PodDisruptionBudgetStatus</a></I></TD><TD>Most recently observed status of the PodDisruptionBudget.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="poddisruptionbudgetspec-v1beta1-policy">PodDisruptionBudgetSpec v1beta1 policy</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>maxUnavailable</CODE></TD><TD>An eviction is allowed if at most &#34;maxUnavailable&#34; pods selected by &#34;selector&#34; are unavailable after the eviction, i.e. even in absence of the evicted pod. For example, one can prevent all voluntary evictions by specifying 0. This is a mutually exclusive setting with &#34;minAvailable&#34;.</TD></TR>
-<TR><TD><CODE>minAvailable</CODE></TD><TD>An eviction is allowed if at least &#34;minAvailable&#34; pods selected by &#34;selector&#34; will still be available after the eviction, i.e. even in the absence of the evicted pod.  So for example you can prevent all voluntary evictions by specifying &#34;100%&#34;.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>Label query over pods whose evictions are managed by the disruption budget.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="poddisruptionbudgetstatus-v1beta1-policy">PodDisruptionBudgetStatus v1beta1 policy</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>currentHealthy</CODE><BR /><I>integer</I></TD><TD>current number of healthy pods</TD></TR>
-<TR><TD><CODE>desiredHealthy</CODE><BR /><I>integer</I></TD><TD>minimum desired number of healthy pods</TD></TR>
-<TR><TD><CODE>disruptedPods</CODE><BR /><I>object</I></TD><TD>DisruptedPods contains information about pods whose eviction was processed by the API server eviction subresource handler but has not yet been observed by the PodDisruptionBudget controller. A pod will be in this map from the time when the API server processed the eviction request to the time when the pod is seen by PDB controller as having been marked for deletion (or after a timeout). The key in the map is the name of the pod and the value is the time when the API server processed the eviction request. If the deletion didn&#39;t occur and a pod is still there it will be removed from the list automatically by PodDisruptionBudget controller after some time. If everything goes smooth this map should be empty for the most of the time. Large number of entries in the map may indicate problems with pod deletions.</TD></TR>
-<TR><TD><CODE>disruptionsAllowed</CODE><BR /><I>integer</I></TD><TD>Number of pod disruptions that are currently allowed.</TD></TR>
-<TR><TD><CODE>expectedPods</CODE><BR /><I>integer</I></TD><TD>total number of pods counted by this disruption budget</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>Most recent generation observed when updating this PDB status. DisruptionsAllowed and other status information is valid only if observedGeneration equals to PDB&#39;s object generation.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="poddisruptionbudgetlist-v1beta1-policy">PodDisruptionBudgetList v1beta1 policy</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-poddisruptionbudget-v1beta1-policy">Create</H2>
-<P>create a PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-poddisruptionbudget-v1beta1-policy">Patch</H2>
-<P>partially update the specified PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-poddisruptionbudget-v1beta1-policy">Replace</H2>
-<P>replace the specified PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-poddisruptionbudget-v1beta1-policy">Delete</H2>
-<P>delete a PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-poddisruptionbudget-v1beta1-policy">Delete Collection</H2>
-<P>delete collection of PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-poddisruptionbudget-v1beta1-policy">Read</H2>
-<P>read the specified PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-poddisruptionbudget-v1beta1-policy">List</H2>
-<P>list or watch objects of kind PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudgetlist-v1beta1-policy">PodDisruptionBudgetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-poddisruptionbudget-v1beta1-policy">List All Namespaces</H2>
-<P>list or watch objects of kind PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/poddisruptionbudgets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudgetlist-v1beta1-policy">PodDisruptionBudgetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-poddisruptionbudget-v1beta1-policy">Watch</H2>
-<P>watch changes to an object of kind PodDisruptionBudget. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/watch/namespaces/{namespace}/poddisruptionbudgets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-poddisruptionbudget-v1beta1-policy">Watch List</H2>
-<P>watch individual changes to a list of PodDisruptionBudget. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/watch/namespaces/{namespace}/poddisruptionbudgets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of PodDisruptionBudget. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/watch/poddisruptionbudgets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-poddisruptionbudget-v1beta1-policy">Patch Status</H2>
-<P>partially update status of the specified PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-poddisruptionbudget-v1beta1-policy">Read Status</H2>
-<P>read status of the specified PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-poddisruptionbudget-v1beta1-policy">Replace Status</H2>
-<P>replace status of the specified PodDisruptionBudget</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodDisruptionBudget</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="priorityclass-v1-scheduling-k8s-io">PriorityClass v1 scheduling.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>scheduling.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PriorityClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#priorityclass-v1beta1-scheduling-k8s-io">v1beta1</a>
-<a href="#priorityclass-v1alpha1-scheduling-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#priorityclasslist-v1-scheduling-k8s-io">PriorityClassList [scheduling/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD>description is an arbitrary string that usually provides guidelines on when this priority class should be used.</TD></TR>
-<TR><TD><CODE>globalDefault</CODE><BR /><I>boolean</I></TD><TD>globalDefault specifies whether this PriorityClass should be considered as the default priority for pods that do not have any priority class. Only one PriorityClass can be marked as `globalDefault`. However, if more than one PriorityClasses exists with their `globalDefault` field set to true, the smallest value of such global default PriorityClasses will be used as the default priority.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>preemptionPolicy</CODE><BR /><I>string</I></TD><TD>PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is alpha-level and is only honored by servers that enable the NonPreemptingPriority feature.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>integer</I></TD><TD>The value of this priority class. This is the actual priority that pods receive when they have the name of this class in their pod spec.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="priorityclasslist-v1-scheduling-k8s-io">PriorityClassList v1 scheduling</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a> array</I></TD><TD>items is the list of PriorityClasses</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-priorityclass-v1-scheduling-k8s-io">Create</H2>
-<P>create a PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/scheduling.k8s.io/v1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-priorityclass-v1-scheduling-k8s-io">Patch</H2>
-<P>partially update the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/scheduling.k8s.io/v1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-priorityclass-v1-scheduling-k8s-io">Replace</H2>
-<P>replace the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/scheduling.k8s.io/v1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-priorityclass-v1-scheduling-k8s-io">Delete</H2>
-<P>delete a PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/scheduling.k8s.io/v1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-priorityclass-v1-scheduling-k8s-io">Delete Collection</H2>
-<P>delete collection of PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/scheduling.k8s.io/v1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-priorityclass-v1-scheduling-k8s-io">Read</H2>
-<P>read the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-priorityclass-v1-scheduling-k8s-io">List</H2>
-<P>list or watch objects of kind PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclasslist-v1-scheduling-k8s-io">PriorityClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-priorityclass-v1-scheduling-k8s-io">Watch</H2>
-<P>watch changes to an object of kind PriorityClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1/watch/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-priorityclass-v1-scheduling-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of PriorityClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1/watch/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="podpreset-v1alpha1-settings-k8s-io">PodPreset v1alpha1 settings.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>settings.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PodPreset</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-warning col-md-8"><P><I class="fa fa-warning"></I> <B>Warning:</B></P><P>Alpha objects should not be used in production and may not be compatible with future versions of the resource type.</P></DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podpresetlist-v1alpha1-settings-k8s-io">PodPresetList [settings/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec v1alpha1 settings</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset [settings/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>env</CODE><BR /><I><a href="#envvar-v1-core">EnvVar</a> array</I></TD><TD>Env defines the collection of EnvVar to inject into containers.</TD></TR>
-<TR><TD><CODE>envFrom</CODE><BR /><I><a href="#envfromsource-v1-core">EnvFromSource</a> array</I></TD><TD>EnvFrom defines the collection of EnvFromSource to inject into containers.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>Selector is a label query over a set of resources, in this case pods. Required.</TD></TR>
-<TR><TD><CODE>volumeMounts</CODE><BR /><I><a href="#volumemount-v1-core">VolumeMount</a> array</I></TD><TD>VolumeMounts defines the collection of VolumeMount to inject into containers.</TD></TR>
-<TR><TD><CODE>volumes</CODE><BR /><I><a href="#volume-v1-core">Volume</a> array</I></TD><TD>Volumes defines the collection of Volume to inject into the pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podpresetlist-v1alpha1-settings-k8s-io">PodPresetList v1alpha1 settings</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-podpreset-v1alpha1-settings-k8s-io">Create</H2>
-<P>create a PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-podpreset-v1alpha1-settings-k8s-io">Patch</H2>
-<P>partially update the specified PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPreset</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-podpreset-v1alpha1-settings-k8s-io">Replace</H2>
-<P>replace the specified PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPreset</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-podpreset-v1alpha1-settings-k8s-io">Delete</H2>
-<P>delete a PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPreset</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-podpreset-v1alpha1-settings-k8s-io">Delete Collection</H2>
-<P>delete collection of PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-podpreset-v1alpha1-settings-k8s-io">Read</H2>
-<P>read the specified PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPreset</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-podpreset-v1alpha1-settings-k8s-io">List</H2>
-<P>list or watch objects of kind PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/settings.k8s.io/v1alpha1/namespaces/{namespace}/podpresets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podpresetlist-v1alpha1-settings-k8s-io">PodPresetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-podpreset-v1alpha1-settings-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind PodPreset</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/settings.k8s.io/v1alpha1/podpresets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podpresetlist-v1alpha1-settings-k8s-io">PodPresetList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-podpreset-v1alpha1-settings-k8s-io">Watch</H2>
-<P>watch changes to an object of kind PodPreset. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/settings.k8s.io/v1alpha1/watch/namespaces/{namespace}/podpresets/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodPreset</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-podpreset-v1alpha1-settings-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of PodPreset. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/settings.k8s.io/v1alpha1/watch/namespaces/{namespace}/podpresets</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of PodPreset. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/settings.k8s.io/v1alpha1/watch/podpresets</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="podsecuritypolicy-v1beta1-policy">PodSecurityPolicy v1beta1 policy</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>PodSecurityPolicy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicylist-v1beta1-policy">PodSecurityPolicyList [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec</a></I></TD><TD>spec defines the policy enforced.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec v1beta1 policy</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowPrivilegeEscalation</CODE><BR /><I>boolean</I></TD><TD>allowPrivilegeEscalation determines if a pod can request to allow privilege escalation. If unspecified, defaults to true.</TD></TR>
-<TR><TD><CODE>allowedCSIDrivers</CODE><BR /><I><a href="#allowedcsidriver-v1beta1-policy">AllowedCSIDriver</a> array</I></TD><TD>AllowedCSIDrivers is a whitelist of inline CSI drivers that must be explicitly set to be embedded within a pod spec. An empty value indicates that any CSI driver can be used for inline ephemeral volumes. This is an alpha field, and is only honored if the API server enables the CSIInlineVolume feature gate.</TD></TR>
-<TR><TD><CODE>allowedCapabilities</CODE><BR /><I>string array</I></TD><TD>allowedCapabilities is a list of capabilities that can be requested to add to the container. Capabilities in this field may be added at the pod author&#39;s discretion. You must not list a capability in both allowedCapabilities and requiredDropCapabilities.</TD></TR>
-<TR><TD><CODE>allowedFlexVolumes</CODE><BR /><I><a href="#allowedflexvolume-v1beta1-policy">AllowedFlexVolume</a> array</I></TD><TD>allowedFlexVolumes is a whitelist of allowed Flexvolumes.  Empty or nil indicates that all Flexvolumes may be used.  This parameter is effective only when the usage of the Flexvolumes is allowed in the &#34;volumes&#34; field.</TD></TR>
-<TR><TD><CODE>allowedHostPaths</CODE><BR /><I><a href="#allowedhostpath-v1beta1-policy">AllowedHostPath</a> array</I></TD><TD>allowedHostPaths is a white list of allowed host paths. Empty indicates that all host paths may be used.</TD></TR>
-<TR><TD><CODE>allowedProcMountTypes</CODE><BR /><I>string array</I></TD><TD>AllowedProcMountTypes is a whitelist of allowed ProcMountTypes. Empty or nil indicates that only the DefaultProcMountType may be used. This requires the ProcMountType feature flag to be enabled.</TD></TR>
-<TR><TD><CODE>allowedUnsafeSysctls</CODE><BR /><I>string array</I></TD><TD>allowedUnsafeSysctls is a list of explicitly allowed unsafe sysctls, defaults to none. Each entry is either a plain sysctl name or ends in &#34;*&#34; in which case it is considered as a prefix of allowed sysctls. Single * means all unsafe sysctls are allowed. Kubelet has to whitelist all allowed unsafe sysctls explicitly to avoid rejection.  Examples: e.g. &#34;foo/*&#34; allows &#34;foo/bar&#34;, &#34;foo/baz&#34;, etc. e.g. &#34;foo.*&#34; allows &#34;foo.bar&#34;, &#34;foo.baz&#34;, etc.</TD></TR>
-<TR><TD><CODE>defaultAddCapabilities</CODE><BR /><I>string array</I></TD><TD>defaultAddCapabilities is the default set of capabilities that will be added to the container unless the pod spec specifically drops the capability.  You may not list a capability in both defaultAddCapabilities and requiredDropCapabilities. Capabilities added here are implicitly allowed, and need not be included in the allowedCapabilities list.</TD></TR>
-<TR><TD><CODE>defaultAllowPrivilegeEscalation</CODE><BR /><I>boolean</I></TD><TD>defaultAllowPrivilegeEscalation controls the default setting for whether a process can gain more privileges than its parent process.</TD></TR>
-<TR><TD><CODE>forbiddenSysctls</CODE><BR /><I>string array</I></TD><TD>forbiddenSysctls is a list of explicitly forbidden sysctls, defaults to none. Each entry is either a plain sysctl name or ends in &#34;*&#34; in which case it is considered as a prefix of forbidden sysctls. Single * means all sysctls are forbidden.  Examples: e.g. &#34;foo/*&#34; forbids &#34;foo/bar&#34;, &#34;foo/baz&#34;, etc. e.g. &#34;foo.*&#34; forbids &#34;foo.bar&#34;, &#34;foo.baz&#34;, etc.</TD></TR>
-<TR><TD><CODE>fsGroup</CODE><BR /><I><a href="#fsgroupstrategyoptions-v1beta1-policy">FSGroupStrategyOptions</a></I></TD><TD>fsGroup is the strategy that will dictate what fs group is used by the SecurityContext.</TD></TR>
-<TR><TD><CODE>hostIPC</CODE><BR /><I>boolean</I></TD><TD>hostIPC determines if the policy allows the use of HostIPC in the pod spec.</TD></TR>
-<TR><TD><CODE>hostNetwork</CODE><BR /><I>boolean</I></TD><TD>hostNetwork determines if the policy allows the use of HostNetwork in the pod spec.</TD></TR>
-<TR><TD><CODE>hostPID</CODE><BR /><I>boolean</I></TD><TD>hostPID determines if the policy allows the use of HostPID in the pod spec.</TD></TR>
-<TR><TD><CODE>hostPorts</CODE><BR /><I><a href="#hostportrange-v1beta1-policy">HostPortRange</a> array</I></TD><TD>hostPorts determines which host port ranges are allowed to be exposed.</TD></TR>
-<TR><TD><CODE>privileged</CODE><BR /><I>boolean</I></TD><TD>privileged determines if a pod can request to be run as privileged.</TD></TR>
-<TR><TD><CODE>readOnlyRootFilesystem</CODE><BR /><I>boolean</I></TD><TD>readOnlyRootFilesystem when set to true will force containers to run with a read only root file system.  If the container specifically requests to run with a non-read only root file system the PSP should deny the pod. If set to false the container may run with a read only root file system if it wishes but it will not be forced to.</TD></TR>
-<TR><TD><CODE>requiredDropCapabilities</CODE><BR /><I>string array</I></TD><TD>requiredDropCapabilities are the capabilities that will be dropped from the container.  These are required to be dropped and cannot be added.</TD></TR>
-<TR><TD><CODE>runAsGroup</CODE><BR /><I><a href="#runasgroupstrategyoptions-v1beta1-policy">RunAsGroupStrategyOptions</a></I></TD><TD>RunAsGroup is the strategy that will dictate the allowable RunAsGroup values that may be set. If this field is omitted, the pod&#39;s RunAsGroup can take any value. This field requires the RunAsGroup feature gate to be enabled.</TD></TR>
-<TR><TD><CODE>runAsUser</CODE><BR /><I><a href="#runasuserstrategyoptions-v1beta1-policy">RunAsUserStrategyOptions</a></I></TD><TD>runAsUser is the strategy that will dictate the allowable RunAsUser values that may be set.</TD></TR>
-<TR><TD><CODE>runtimeClass</CODE><BR /><I><a href="#runtimeclassstrategyoptions-v1beta1-policy">RuntimeClassStrategyOptions</a></I></TD><TD>runtimeClass is the strategy that will dictate the allowable RuntimeClasses for a pod. If this field is omitted, the pod&#39;s runtimeClassName field is unrestricted. Enforcement of this field depends on the RuntimeClass feature gate being enabled.</TD></TR>
-<TR><TD><CODE>seLinux</CODE><BR /><I><a href="#selinuxstrategyoptions-v1beta1-policy">SELinuxStrategyOptions</a></I></TD><TD>seLinux is the strategy that will dictate the allowable labels that may be set.</TD></TR>
-<TR><TD><CODE>supplementalGroups</CODE><BR /><I><a href="#supplementalgroupsstrategyoptions-v1beta1-policy">SupplementalGroupsStrategyOptions</a></I></TD><TD>supplementalGroups is the strategy that will dictate what supplemental groups are used by the SecurityContext.</TD></TR>
-<TR><TD><CODE>volumes</CODE><BR /><I>string array</I></TD><TD>volumes is a white list of allowed volume plugins. Empty indicates that no volumes may be used. To allow all volumes you may use &#39;\*&#39;.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="podsecuritypolicylist-v1beta1-policy">PodSecurityPolicyList v1beta1 policy</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a> array</I></TD><TD>items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-podsecuritypolicy-v1beta1-policy">Create</H2>
-<P>create a PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/policy/v1beta1/podsecuritypolicies</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-podsecuritypolicy-v1beta1-policy">Patch</H2>
-<P>partially update the specified PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/policy/v1beta1/podsecuritypolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodSecurityPolicy</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-podsecuritypolicy-v1beta1-policy">Replace</H2>
-<P>replace the specified PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/policy/v1beta1/podsecuritypolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodSecurityPolicy</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-podsecuritypolicy-v1beta1-policy">Delete</H2>
-<P>delete a PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/policy/v1beta1/podsecuritypolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodSecurityPolicy</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-podsecuritypolicy-v1beta1-policy">Delete Collection</H2>
-<P>delete collection of PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/policy/v1beta1/podsecuritypolicies</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-podsecuritypolicy-v1beta1-policy">Read</H2>
-<P>read the specified PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/podsecuritypolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodSecurityPolicy</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-podsecuritypolicy-v1beta1-policy">List</H2>
-<P>list or watch objects of kind PodSecurityPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/podsecuritypolicies</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#podsecuritypolicylist-v1beta1-policy">PodSecurityPolicyList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-podsecuritypolicy-v1beta1-policy">Watch</H2>
-<P>watch changes to an object of kind PodSecurityPolicy. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/watch/podsecuritypolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PodSecurityPolicy</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-podsecuritypolicy-v1beta1-policy">Watch List</H2>
-<P>watch individual changes to a list of PodSecurityPolicy. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/policy/v1beta1/watch/podsecuritypolicies</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="-strong-cluster-apis-strong-"><strong>CLUSTER</strong></H1>
-
-<P>Cluster resources are responsible for defining configuration of the cluster itself, and are generally only used by cluster operators.</P>
-
-<HR />
-<H1 id="apiservice-v1-apiregistration-k8s-io">APIService v1 apiregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>APIService</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#apiservice-v1beta1-apiregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicelist-v1-apiregistration-k8s-io">APIServiceList [apiregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#apiservicespec-v1-apiregistration-k8s-io">APIServiceSpec</a></I></TD><TD>Spec contains information for locating and communicating with a server</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#apiservicestatus-v1-apiregistration-k8s-io">APIServiceStatus</a></I></TD><TD>Status contains derived information about an API server</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="apiservicespec-v1-apiregistration-k8s-io">APIServiceSpec v1 apiregistration</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservice-v1-apiregistration-k8s-io">APIService [apiregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>CABundle is a PEM encoded CA bundle which will be used to validate an API server&#39;s serving certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>Group is the API group name this server hosts</TD></TR>
-<TR><TD><CODE>groupPriorityMinimum</CODE><BR /><I>integer</I></TD><TD>GroupPriorityMininum is the priority this group should have at least. Higher priority means that the group is preferred by clients over lower priority ones. Note that other versions of this group might specify even higher GroupPriorityMininum values such that the whole group gets a higher priority. The primary sort is based on GroupPriorityMinimum, ordered highest number to lowest (20 before 10). The secondary sort is based on the alphabetical comparison of the name of the object.  (v1.bar before v1.foo) We&#39;d recommend something like: *.k8s.io (except extensions) at 18000 and PaaSes (OpenShift, Deis) are recommended to be in the 2000s</TD></TR>
-<TR><TD><CODE>insecureSkipTLSVerify</CODE><BR /><I>boolean</I></TD><TD>InsecureSkipTLSVerify disables TLS certificate verification when communicating with this server. This is strongly discouraged.  You should use the CABundle instead.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1-apiregistration-k8s-io">ServiceReference</a></I></TD><TD>Service is a reference to the service for this API server.  It must communicate on port 443 If the Service is nil, that means the handling for the API groupversion is handled locally on this server. The call will simply delegate to the normal handler chain to be fulfilled.</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>Version is the API version this server hosts.  For example, &#34;v1&#34;</TD></TR>
-<TR><TD><CODE>versionPriority</CODE><BR /><I>integer</I></TD><TD>VersionPriority controls the ordering of this API version inside of its group.  Must be greater than zero. The primary sort is based on VersionPriority, ordered highest to lowest (20 before 10). Since it&#39;s inside of a group, the number can be small, probably in the 10s. In case of equal version priorities, the version string will be used to compute the order inside a group. If the version string is &#34;kube-like&#34;, it will sort above non &#34;kube-like&#34; version strings, which are ordered lexicographically. &#34;Kube-like&#34; versions start with a &#34;v&#34;, then are followed by a number (the major version), then optionally the string &#34;alpha&#34; or &#34;beta&#34; and another number (the minor version). These are sorted first by GA &gt; beta &gt; alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="apiservicestatus-v1-apiregistration-k8s-io">APIServiceStatus v1 apiregistration</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservice-v1-apiregistration-k8s-io">APIService [apiregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#apiservicecondition-v1-apiregistration-k8s-io">APIServiceCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Current service state of apiService.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="apiservicelist-v1-apiregistration-k8s-io">APIServiceList v1 apiregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-apiservice-v1-apiregistration-k8s-io">Create</H2>
-<P>create an APIService</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apiregistration.k8s.io/v1/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-apiservice-v1-apiregistration-k8s-io">Patch</H2>
-<P>partially update the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-apiservice-v1-apiregistration-k8s-io">Replace</H2>
-<P>replace the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-apiservice-v1-apiregistration-k8s-io">Delete</H2>
-<P>delete an APIService</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiregistration.k8s.io/v1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-apiservice-v1-apiregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of APIService</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiregistration.k8s.io/v1/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-apiservice-v1-apiregistration-k8s-io">Read</H2>
-<P>read the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-apiservice-v1-apiregistration-k8s-io">List</H2>
-<P>list or watch objects of kind APIService</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservicelist-v1-apiregistration-k8s-io">APIServiceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-apiservice-v1-apiregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind APIService. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1/watch/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-apiservice-v1-apiregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of APIService. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1/watch/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-apiservice-v1-apiregistration-k8s-io">Patch Status</H2>
-<P>partially update status of the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-apiservice-v1-apiregistration-k8s-io">Read Status</H2>
-<P>read status of the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1/apiservices/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-apiservice-v1-apiregistration-k8s-io">Replace Status</H2>
-<P>replace status of the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#apiservice-v1-apiregistration-k8s-io">APIService</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="auditsink-v1alpha1-auditregistration-k8s-io">AuditSink v1alpha1 auditregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>auditregistration.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>AuditSink</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#auditsinklist-v1alpha1-auditregistration-k8s-io">AuditSinkList [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#auditsinkspec-v1alpha1-auditregistration-k8s-io">AuditSinkSpec</a></I></TD><TD>Spec defines the audit configuration spec</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="auditsinkspec-v1alpha1-auditregistration-k8s-io">AuditSinkSpec v1alpha1 auditregistration</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE><BR /><I><a href="#policy-v1alpha1-auditregistration-k8s-io">Policy</a></I></TD><TD>Policy defines the policy for selecting which events should be sent to the webhook required</TD></TR>
-<TR><TD><CODE>webhook</CODE><BR /><I><a href="#webhook-v1alpha1-auditregistration-k8s-io">Webhook</a></I></TD><TD>Webhook to send events required</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="auditsinklist-v1alpha1-auditregistration-k8s-io">AuditSinkList v1alpha1 auditregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a> array</I></TD><TD>List of audit configurations.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-auditsink-v1alpha1-auditregistration-k8s-io">Create</H2>
-<P>create an AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/auditregistration.k8s.io/v1alpha1/auditsinks</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-auditsink-v1alpha1-auditregistration-k8s-io">Patch</H2>
-<P>partially update the specified AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/auditregistration.k8s.io/v1alpha1/auditsinks/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the AuditSink</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-auditsink-v1alpha1-auditregistration-k8s-io">Replace</H2>
-<P>replace the specified AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/auditregistration.k8s.io/v1alpha1/auditsinks/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the AuditSink</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-auditsink-v1alpha1-auditregistration-k8s-io">Delete</H2>
-<P>delete an AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/auditregistration.k8s.io/v1alpha1/auditsinks/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the AuditSink</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-auditsink-v1alpha1-auditregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/auditregistration.k8s.io/v1alpha1/auditsinks</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-auditsink-v1alpha1-auditregistration-k8s-io">Read</H2>
-<P>read the specified AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/auditregistration.k8s.io/v1alpha1/auditsinks/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the AuditSink</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-auditsink-v1alpha1-auditregistration-k8s-io">List</H2>
-<P>list or watch objects of kind AuditSink</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/auditregistration.k8s.io/v1alpha1/auditsinks</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#auditsinklist-v1alpha1-auditregistration-k8s-io">AuditSinkList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-auditsink-v1alpha1-auditregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind AuditSink. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/auditregistration.k8s.io/v1alpha1/watch/auditsinks/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the AuditSink</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-auditsink-v1alpha1-auditregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of AuditSink. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/auditregistration.k8s.io/v1alpha1/watch/auditsinks</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="binding-v1-core">Binding v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Binding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>The target object that you want to bind to the standard object.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-binding-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-binding-v1-core">Create</H2>
-<P>create a Binding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/bindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#binding-v1-core">Binding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#binding-v1-core">Binding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#binding-v1-core">Binding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#binding-v1-core">Binding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest v1beta1 certificates.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>certificates.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CertificateSigningRequest</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#certificatesigningrequestlist-v1beta1-certificates-k8s-io">CertificateSigningRequestList [certificates/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#certificatesigningrequestspec-v1beta1-certificates-k8s-io">CertificateSigningRequestSpec</a></I></TD><TD>The certificate request itself and any additional information.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#certificatesigningrequeststatus-v1beta1-certificates-k8s-io">CertificateSigningRequestStatus</a></I></TD><TD>Derived information about the request.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="certificatesigningrequestspec-v1beta1-certificates-k8s-io">CertificateSigningRequestSpec v1beta1 certificates</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest [certificates/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extra</CODE><BR /><I>object</I></TD><TD>Extra information about the requesting user. See user.Info interface for details.</TD></TR>
-<TR><TD><CODE>groups</CODE><BR /><I>string array</I></TD><TD>Group information about the requesting user. See user.Info interface for details.</TD></TR>
-<TR><TD><CODE>request</CODE><BR /><I>string</I></TD><TD>Base64-encoded PKCS#10 CSR data</TD></TR>
-<TR><TD><CODE>signerName</CODE><BR /><I>string</I></TD><TD>Requested signer for the request. It is a qualified name in the form: `scope-hostname.io/name`. If empty, it will be defaulted:  1. If it&#39;s a kubelet client certificate, it is assigned     &#34;kubernetes.io/kube-apiserver-client-kubelet&#34;.  2. If it&#39;s a kubelet serving certificate, it is assigned     &#34;kubernetes.io/kubelet-serving&#34;.  3. Otherwise, it is assigned &#34;kubernetes.io/legacy-unknown&#34;. Distribution of trust for signers happens out of band. You can select on this field using `spec.signerName`.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID information about the requesting user. See user.Info interface for details.</TD></TR>
-<TR><TD><CODE>usages</CODE><BR /><I>string array</I></TD><TD>allowedUsages specifies a set of usage contexts the key will be valid for. See: https://tools.ietf.org/html/rfc5280#section-4.2.1.3      https://tools.ietf.org/html/rfc5280#section-4.2.1.12</TD></TR>
-<TR><TD><CODE>username</CODE><BR /><I>string</I></TD><TD>Information about the requesting user. See user.Info interface for details.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="certificatesigningrequeststatus-v1beta1-certificates-k8s-io">CertificateSigningRequestStatus v1beta1 certificates</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest [certificates/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>certificate</CODE><BR /><I>string</I></TD><TD>If request was approved, the controller will place the issued certificate here.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#certificatesigningrequestcondition-v1beta1-certificates-k8s-io">CertificateSigningRequestCondition</a> array</I></TD><TD>Conditions applied to the request, such as approval or denial.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="certificatesigningrequestlist-v1beta1-certificates-k8s-io">CertificateSigningRequestList v1beta1 certificates</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-certificatesigningrequest-v1beta1-certificates-k8s-io">Create</H2>
-<P>create a CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/certificates.k8s.io/v1beta1/certificatesigningrequests</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-certificatesigningrequest-v1beta1-certificates-k8s-io">Patch</H2>
-<P>partially update the specified CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-certificatesigningrequest-v1beta1-certificates-k8s-io">Replace</H2>
-<P>replace the specified CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-certificatesigningrequest-v1beta1-certificates-k8s-io">Delete</H2>
-<P>delete a CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io">Delete Collection</H2>
-<P>delete collection of CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/certificates.k8s.io/v1beta1/certificatesigningrequests</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-certificatesigningrequest-v1beta1-certificates-k8s-io">Read</H2>
-<P>read the specified CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-certificatesigningrequest-v1beta1-certificates-k8s-io">List</H2>
-<P>list or watch objects of kind CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/certificates.k8s.io/v1beta1/certificatesigningrequests</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequestlist-v1beta1-certificates-k8s-io">CertificateSigningRequestList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-certificatesigningrequest-v1beta1-certificates-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CertificateSigningRequest. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/certificates.k8s.io/v1beta1/watch/certificatesigningrequests/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CertificateSigningRequest. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/certificates.k8s.io/v1beta1/watch/certificatesigningrequests</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io">Patch Status</H2>
-<P>partially update status of the specified CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-certificatesigningrequest-v1beta1-certificates-k8s-io">Read Status</H2>
-<P>read status of the specified CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io">Replace Status</H2>
-<P>replace status of the specified CertificateSigningRequest</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/certificates.k8s.io/v1beta1/certificatesigningrequests/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CertificateSigningRequest</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="clusterrole-v1-rbac-authorization-k8s-io">ClusterRole v1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ClusterRole</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolelist-v1-rbac-authorization-k8s-io">ClusterRoleList [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>aggregationRule</CODE><BR /><I><a href="#aggregationrule-v1-rbac-authorization-k8s-io">AggregationRule</a></I></TD><TD>AggregationRule is an optional field that describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be stomped by the controller.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyrule-v1-rbac-authorization-k8s-io">PolicyRule</a> array</I></TD><TD>Rules holds all the PolicyRules for this ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="clusterrolelist-v1-rbac-authorization-k8s-io">ClusterRoleList v1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a> array</I></TD><TD>Items is a list of ClusterRoles</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-clusterrole-v1-rbac-authorization-k8s-io">Create</H2>
-<P>create a ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-clusterrole-v1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-clusterrole-v1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-clusterrole-v1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-clusterrole-v1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-clusterrole-v1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-clusterrole-v1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolelist-v1-rbac-authorization-k8s-io">ClusterRoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-clusterrole-v1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ClusterRole. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-clusterrole-v1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ClusterRole. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding v1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ClusterRoleBinding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebindinglist-v1-rbac-authorization-k8s-io">ClusterRoleBindingList [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>roleRef</CODE><BR /><I><a href="#roleref-v1-rbac-authorization-k8s-io">RoleRef</a></I></TD><TD>RoleRef can only reference a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1-rbac-authorization-k8s-io">Subject</a> array</I></TD><TD>Subjects holds references to the objects the role applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="clusterrolebindinglist-v1-rbac-authorization-k8s-io">ClusterRoleBindingList v1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a> array</I></TD><TD>Items is a list of ClusterRoleBindings</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-clusterrolebinding-v1-rbac-authorization-k8s-io">Create</H2>
-<P>create a ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-clusterrolebinding-v1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-clusterrolebinding-v1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-clusterrolebinding-v1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-clusterrolebinding-v1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-clusterrolebinding-v1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebindinglist-v1-rbac-authorization-k8s-io">ClusterRoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-clusterrolebinding-v1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ClusterRoleBinding. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ClusterRoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="componentstatus-v1-core">ComponentStatus v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ComponentStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#componentstatuslist-v1-core">ComponentStatusList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#componentcondition-v1-core">ComponentCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>List of component conditions observed</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="componentstatuslist-v1-core">ComponentStatusList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#componentstatus-v1-core">ComponentStatus</a> array</I></TD><TD>List of ComponentStatus objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-componentstatus-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-componentstatus-v1-core">Read</H2>
-<P>read the specified ComponentStatus</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/componentstatuses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ComponentStatus</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#componentstatus-v1-core">ComponentStatus</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-componentstatus-v1-core">List</H2>
-<P>list objects of kind ComponentStatus</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/componentstatuses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#componentstatuslist-v1-core">ComponentStatusList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema v1alpha1 flowcontrol.apiserver.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>FlowSchema</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschemalist-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaList [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>`metadata` is the standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#flowschemaspec-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaSpec</a></I></TD><TD>`spec` is the specification of the desired behavior of a FlowSchema. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#flowschemastatus-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaStatus</a></I></TD><TD>`status` is the current status of a FlowSchema. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="flowschemaspec-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaSpec v1alpha1 flowcontrol</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>distinguisherMethod</CODE><BR /><I><a href="#flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io">FlowDistinguisherMethod</a></I></TD><TD>`distinguisherMethod` defines how to compute the flow distinguisher for requests that match this schema. `nil` specifies that the distinguisher is disabled and thus will always be the empty string.</TD></TR>
-<TR><TD><CODE>matchingPrecedence</CODE><BR /><I>integer</I></TD><TD>`matchingPrecedence` is used to choose among the FlowSchemas that match a given request. The chosen FlowSchema is among those with the numerically lowest (which we take to be logically highest) MatchingPrecedence.  Each MatchingPrecedence value must be ranged in [1,10000]. Note that if the precedence is not specified, it will be set to 1000 as default.</TD></TR>
-<TR><TD><CODE>priorityLevelConfiguration</CODE><BR /><I><a href="#prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationReference</a></I></TD><TD>`priorityLevelConfiguration` should reference a PriorityLevelConfiguration in the cluster. If the reference cannot be resolved, the FlowSchema will be ignored and marked as invalid in its status. Required.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io">PolicyRulesWithSubjects</a> array</I></TD><TD>`rules` describes which requests will match this flow schema. This FlowSchema matches a request if and only if at least one member of rules matches the request. if it is an empty slice, there will be no requests matching the FlowSchema.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="flowschemastatus-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaStatus v1alpha1 flowcontrol</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaCondition</a> array</I></TD><TD>`conditions` is a list of the current states of FlowSchema.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="flowschemalist-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaList v1alpha1 flowcontrol</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a> array</I></TD><TD>`items` is a list of FlowSchemas.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>`metadata` is the standard list metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Create</H2>
-<P>create a FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Patch</H2>
-<P>partially update the specified FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Replace</H2>
-<P>replace the specified FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Delete</H2>
-<P>delete a FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Delete Collection</H2>
-<P>delete collection of FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Read</H2>
-<P>read the specified FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">List</H2>
-<P>list or watch objects of kind FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschemalist-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Watch</H2>
-<P>watch changes to an object of kind FlowSchema. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/watch/flowschemas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of FlowSchema. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/watch/flowschemas</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Patch Status</H2>
-<P>partially update status of the specified FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Read Status</H2>
-<P>read status of the specified FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">Replace Status</H2>
-<P>replace status of the specified FlowSchema</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/flowcontrol.apiserver.k8s.io/v1alpha1/flowschemas/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the FlowSchema</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="lease-v1-coordination-k8s-io">Lease v1 coordination.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>coordination.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Lease</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#lease-v1beta1-coordination-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#leaselist-v1-coordination-k8s-io">LeaseList [coordination/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#leasespec-v1-coordination-k8s-io">LeaseSpec</a></I></TD><TD>Specification of the Lease. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="leasespec-v1-coordination-k8s-io">LeaseSpec v1 coordination</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#lease-v1-coordination-k8s-io">Lease [coordination/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>acquireTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>acquireTime is a time when the current lease was acquired.</TD></TR>
-<TR><TD><CODE>holderIdentity</CODE><BR /><I>string</I></TD><TD>holderIdentity contains the identity of the holder of a current lease.</TD></TR>
-<TR><TD><CODE>leaseDurationSeconds</CODE><BR /><I>integer</I></TD><TD>leaseDurationSeconds is a duration that candidates for a lease need to wait to force acquire it. This is measure against time of last observed RenewTime.</TD></TR>
-<TR><TD><CODE>leaseTransitions</CODE><BR /><I>integer</I></TD><TD>leaseTransitions is the number of transitions of a lease between holders.</TD></TR>
-<TR><TD><CODE>renewTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>renewTime is a time when the current holder of a lease has last updated the lease.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="leaselist-v1-coordination-k8s-io">LeaseList v1 coordination</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#lease-v1-coordination-k8s-io">Lease</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-lease-v1-coordination-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-lease-v1-coordination-k8s-io">Create</H2>
-<P>create a Lease</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-lease-v1-coordination-k8s-io">Patch</H2>
-<P>partially update the specified Lease</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-lease-v1-coordination-k8s-io">Replace</H2>
-<P>replace the specified Lease</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-lease-v1-coordination-k8s-io">Delete</H2>
-<P>delete a Lease</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-lease-v1-coordination-k8s-io">Delete Collection</H2>
-<P>delete collection of Lease</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-lease-v1-coordination-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-lease-v1-coordination-k8s-io">Read</H2>
-<P>read the specified Lease</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-lease-v1-coordination-k8s-io">List</H2>
-<P>list or watch objects of kind Lease</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#leaselist-v1-coordination-k8s-io">LeaseList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-lease-v1-coordination-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Lease</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1/leases</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#leaselist-v1-coordination-k8s-io">LeaseList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-lease-v1-coordination-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Lease. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1/watch/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-lease-v1-coordination-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Lease. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1/watch/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-lease-v1-coordination-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Lease. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1/watch/leases</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview v1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LocalSubjectAccessReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#subjectaccessreviewspec-v1-authorization-k8s-io">SubjectAccessReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated.  spec.namespace must be equal to the namespace you made the request against.  If empty, it is defaulted.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectaccessreviewstatus-v1-authorization-k8s-io">SubjectAccessReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request is allowed or not</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-localsubjectaccessreview-v1-authorization-k8s-io">Create</H2>
-<P>create a LocalSubjectAccessReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessreviews</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="namespace-v1-core">Namespace v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Namespace</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#namespacelist-v1-core">NamespaceList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#namespacespec-v1-core">NamespaceSpec</a></I></TD><TD>Spec defines the behavior of the Namespace. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#namespacestatus-v1-core">NamespaceStatus</a></I></TD><TD>Status describes the current status of a Namespace. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="namespacespec-v1-core">NamespaceSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#namespace-v1-core">Namespace [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>finalizers</CODE><BR /><I>string array</I></TD><TD>Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="namespacestatus-v1-core">NamespaceStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#namespace-v1-core">Namespace [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#namespacecondition-v1-core">NamespaceCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Represents the latest available observations of a namespace&#39;s current state.</TD></TR>
-<TR><TD><CODE>phase</CODE><BR /><I>string</I></TD><TD>Phase is the current lifecycle phase of the namespace. More info: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="namespacelist-v1-core">NamespaceList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#namespace-v1-core">Namespace</a> array</I></TD><TD>Items is the list of Namespace objects in the list. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-namespace-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-namespace-v1-core">Create</H2>
-<P>create a Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-namespace-v1-core">Patch</H2>
-<P>partially update the specified Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-namespace-v1-core">Replace</H2>
-<P>replace the specified Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-namespace-v1-core">Delete</H2>
-<P>delete a Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-namespace-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-namespace-v1-core">Read</H2>
-<P>read the specified Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-namespace-v1-core">List</H2>
-<P>list or watch objects of kind Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespacelist-v1-core">NamespaceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-namespace-v1-core">Watch</H2>
-<P>watch changes to an object of kind Namespace. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-namespace-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Namespace. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-namespace-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-namespace-v1-core">Patch Status</H2>
-<P>partially update status of the specified Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-namespace-v1-core">Read Status</H2>
-<P>read status of the specified Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-namespace-v1-core">Replace Status</H2>
-<P>replace status of the specified Namespace</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#namespace-v1-core">Namespace</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="node-v1-core">Node v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Node</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodelist-v1-core">NodeList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#nodespec-v1-core">NodeSpec</a></I></TD><TD>Spec defines the behavior of a node. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#nodestatus-v1-core">NodeStatus</a></I></TD><TD>Most recently observed status of the node. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="nodespec-v1-core">NodeSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#node-v1-core">Node [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>configSource</CODE><BR /><I><a href="#nodeconfigsource-v1-core">NodeConfigSource</a></I></TD><TD>If specified, the source to get node configuration from The DynamicKubeletConfig feature gate must be enabled for the Kubelet to use this field</TD></TR>
-<TR><TD><CODE>externalID</CODE><BR /><I>string</I></TD><TD>Deprecated. Not all kubelets will set this field. Remove field after 1.13. see: https://issues.k8s.io/61966</TD></TR>
-<TR><TD><CODE>podCIDR</CODE><BR /><I>string</I></TD><TD>PodCIDR represents the pod IP range assigned to the node.</TD></TR>
-<TR><TD><CODE>podCIDRs</CODE><BR /><I>string array</I><BR /><B>patch strategy</B>: <I>merge</I></TD><TD>podCIDRs represents the IP ranges assigned to the node for usage by Pods on that node. If this field is specified, the 0th entry must match the podCIDR field. It may contain at most 1 value for each of IPv4 and IPv6.</TD></TR>
-<TR><TD><CODE>providerID</CODE><BR /><I>string</I></TD><TD>ID of the node assigned by the cloud provider in the format: &lt;ProviderName&gt;://&lt;ProviderSpecificNodeID&gt;</TD></TR>
-<TR><TD><CODE>taints</CODE><BR /><I><a href="#taint-v1-core">Taint</a> array</I></TD><TD>If specified, the node&#39;s taints.</TD></TR>
-<TR><TD><CODE>unschedulable</CODE><BR /><I>boolean</I></TD><TD>Unschedulable controls node schedulability of new pods. By default, node is schedulable. More info: https://kubernetes.io/docs/concepts/nodes/node/#manual-node-administration</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="nodestatus-v1-core">NodeStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#node-v1-core">Node [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>addresses</CODE><BR /><I><a href="#nodeaddress-v1-core">NodeAddress</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>List of addresses reachable to the node. Queried from cloud provider, if available. More info: https://kubernetes.io/docs/concepts/nodes/node/#addresses Note: This field is declared as mergeable, but the merge key is not sufficiently unique, which can cause data corruption when it is merged. Callers should instead use a full-replacement patch. See http://pr.k8s.io/79391 for an example.</TD></TR>
-<TR><TD><CODE>allocatable</CODE><BR /><I>object</I></TD><TD>Allocatable represents the resources of a node that are available for scheduling. Defaults to Capacity.</TD></TR>
-<TR><TD><CODE>capacity</CODE><BR /><I>object</I></TD><TD>Capacity represents the total resources of a node. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#capacity</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#nodecondition-v1-core">NodeCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Conditions is an array of current observed node conditions. More info: https://kubernetes.io/docs/concepts/nodes/node/#condition</TD></TR>
-<TR><TD><CODE>config</CODE><BR /><I><a href="#nodeconfigstatus-v1-core">NodeConfigStatus</a></I></TD><TD>Status of the config assigned to the node via the dynamic Kubelet config feature.</TD></TR>
-<TR><TD><CODE>daemonEndpoints</CODE><BR /><I><a href="#nodedaemonendpoints-v1-core">NodeDaemonEndpoints</a></I></TD><TD>Endpoints of daemons running on the Node.</TD></TR>
-<TR><TD><CODE>images</CODE><BR /><I><a href="#containerimage-v1-core">ContainerImage</a> array</I></TD><TD>List of container images on this node</TD></TR>
-<TR><TD><CODE>nodeInfo</CODE><BR /><I><a href="#nodesysteminfo-v1-core">NodeSystemInfo</a></I></TD><TD>Set of ids/uuids to uniquely identify the node. More info: https://kubernetes.io/docs/concepts/nodes/node/#info</TD></TR>
-<TR><TD><CODE>phase</CODE><BR /><I>string</I></TD><TD>NodePhase is the recently observed lifecycle phase of the node. More info: https://kubernetes.io/docs/concepts/nodes/node/#phase The field is never populated, and now is deprecated.</TD></TR>
-<TR><TD><CODE>volumesAttached</CODE><BR /><I><a href="#attachedvolume-v1-core">AttachedVolume</a> array</I></TD><TD>List of volumes that are attached to the node.</TD></TR>
-<TR><TD><CODE>volumesInUse</CODE><BR /><I>string array</I></TD><TD>List of attachable volumes in use (mounted) by the node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="nodelist-v1-core">NodeList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#node-v1-core">Node</a> array</I></TD><TD>List of nodes</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-node-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-node-v1-core">Create</H2>
-<P>create a Node</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/nodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#node-v1-core">Node</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-node-v1-core">Patch</H2>
-<P>partially update the specified Node</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/nodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-node-v1-core">Replace</H2>
-<P>replace the specified Node</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/nodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#node-v1-core">Node</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-node-v1-core">Delete</H2>
-<P>delete a Node</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/nodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-node-v1-core">Delete Collection</H2>
-<P>delete collection of Node</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/nodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-node-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-node-v1-core">Read</H2>
-<P>read the specified Node</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/nodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-node-v1-core">List</H2>
-<P>list or watch objects of kind Node</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/nodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#nodelist-v1-core">NodeList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-node-v1-core">Watch</H2>
-<P>watch changes to an object of kind Node. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/nodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-node-v1-core">Watch List</H2>
-<P>watch individual changes to a list of Node. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/nodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-node-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-node-v1-core">Patch Status</H2>
-<P>partially update status of the specified Node</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/nodes/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-node-v1-core">Read Status</H2>
-<P>read status of the specified Node</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/nodes/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-node-v1-core">Replace Status</H2>
-<P>replace status of the specified Node</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/nodes/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Node</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#node-v1-core">Node</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#node-v1-core">Node</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-proxy-operations-node-v1-core-strong-"><STRONG>Proxy Operations</STRONG></H2>
-<H2 id="create-connect-proxy-node-v1-core">Create Connect Proxy</H2>
-<P>connect POST requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/nodes/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="create-connect-proxy-path-node-v1-core">Create Connect Proxy Path</H2>
-<P>connect POST requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/nodes/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-connect-proxy-node-v1-core">Delete Connect Proxy</H2>
-<P>connect DELETE requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/nodes/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-connect-proxy-path-node-v1-core">Delete Connect Proxy Path</H2>
-<P>connect DELETE requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/nodes/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-proxy-node-v1-core">Get Connect Proxy</H2>
-<P>connect GET requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/nodes/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="get-connect-proxy-path-node-v1-core">Get Connect Proxy Path</H2>
-<P>connect GET requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/nodes/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="head-connect-proxy-node-v1-core">Head Connect Proxy</H2>
-<P>connect HEAD requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>HEAD /api/v1/nodes/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="head-connect-proxy-path-node-v1-core">Head Connect Proxy Path</H2>
-<P>connect HEAD requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>HEAD /api/v1/nodes/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-connect-proxy-node-v1-core">Replace Connect Proxy</H2>
-<P>connect PUT requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/nodes/{name}/proxy</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-connect-proxy-path-node-v1-core">Replace Connect Proxy Path</H2>
-<P>connect PUT requests to proxy of Node</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/nodes/{name}/proxy/{path}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NodeProxyOptions</TD></TR>
-<TR><TD><CODE>path</CODE></TD><TD>path to the resource</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE></TD><TD>Path is the URL path to use for the current proxy request to node.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I>string</I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="persistentvolume-v1-core">PersistentVolume v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PersistentVolume</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-bullhorn"></I> These are assigned to <a href="#pod-v1-core">Pods</a> using <a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaims</a>.</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumelist-v1-core">PersistentVolumeList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec</a></I></TD><TD>Spec defines a specification of a persistent volume owned by the cluster. Provisioned by an administrator. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistent-volumes</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#persistentvolumestatus-v1-core">PersistentVolumeStatus</a></I></TD><TD>Status represents the current information/status for the persistent volume. Populated by the system. Read-only. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistent-volumes</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="persistentvolumespec-v1-core">PersistentVolumeSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolume-v1-core">PersistentVolume [core/v1]</a></LI>
-  <LI><a href="#volumeattachmentsource-v1-storage-k8s-io">VolumeAttachmentSource [storage/v1]</a></LI>
-  <LI><a href="#volumeattachmentsource-v1beta1-storage-k8s-io">VolumeAttachmentSource [storage/v1beta1]</a></LI>
-  <LI><a href="#volumeattachmentsource-v1alpha1-storage-k8s-io">VolumeAttachmentSource [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>accessModes</CODE><BR /><I>string array</I></TD><TD>AccessModes contains all ways the volume can be mounted. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes</TD></TR>
-<TR><TD><CODE>awsElasticBlockStore</CODE><BR /><I><a href="#awselasticblockstorevolumesource-v1-core">AWSElasticBlockStoreVolumeSource</a></I></TD><TD>AWSElasticBlockStore represents an AWS Disk resource that is attached to a kubelet&#39;s host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore</TD></TR>
-<TR><TD><CODE>azureDisk</CODE><BR /><I><a href="#azurediskvolumesource-v1-core">AzureDiskVolumeSource</a></I></TD><TD>AzureDisk represents an Azure Data Disk mount on the host and bind mount to the pod.</TD></TR>
-<TR><TD><CODE>azureFile</CODE><BR /><I><a href="#azurefilepersistentvolumesource-v1-core">AzureFilePersistentVolumeSource</a></I></TD><TD>AzureFile represents an Azure File Service mount on the host and bind mount to the pod.</TD></TR>
-<TR><TD><CODE>capacity</CODE><BR /><I>object</I></TD><TD>A description of the persistent volume&#39;s resources and capacity. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#capacity</TD></TR>
-<TR><TD><CODE>cephfs</CODE><BR /><I><a href="#cephfspersistentvolumesource-v1-core">CephFSPersistentVolumeSource</a></I></TD><TD>CephFS represents a Ceph FS mount on the host that shares a pod&#39;s lifetime</TD></TR>
-<TR><TD><CODE>cinder</CODE><BR /><I><a href="#cinderpersistentvolumesource-v1-core">CinderPersistentVolumeSource</a></I></TD><TD>Cinder represents a cinder volume attached and mounted on kubelets host machine. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-<TR><TD><CODE>claimRef</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>ClaimRef is part of a bi-directional binding between PersistentVolume and PersistentVolumeClaim. Expected to be non-nil when bound. claim.VolumeName is the authoritative bind between PV and PVC. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#binding</TD></TR>
-<TR><TD><CODE>csi</CODE><BR /><I><a href="#csipersistentvolumesource-v1-core">CSIPersistentVolumeSource</a></I></TD><TD>CSI represents storage that is handled by an external CSI driver (Beta feature).</TD></TR>
-<TR><TD><CODE>fc</CODE><BR /><I><a href="#fcvolumesource-v1-core">FCVolumeSource</a></I></TD><TD>FC represents a Fibre Channel resource that is attached to a kubelet&#39;s host machine and then exposed to the pod.</TD></TR>
-<TR><TD><CODE>flexVolume</CODE><BR /><I><a href="#flexpersistentvolumesource-v1-core">FlexPersistentVolumeSource</a></I></TD><TD>FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin.</TD></TR>
-<TR><TD><CODE>flocker</CODE><BR /><I><a href="#flockervolumesource-v1-core">FlockerVolumeSource</a></I></TD><TD>Flocker represents a Flocker volume attached to a kubelet&#39;s host machine and exposed to the pod for its usage. This depends on the Flocker control service being running</TD></TR>
-<TR><TD><CODE>gcePersistentDisk</CODE><BR /><I><a href="#gcepersistentdiskvolumesource-v1-core">GCEPersistentDiskVolumeSource</a></I></TD><TD>GCEPersistentDisk represents a GCE Disk resource that is attached to a kubelet&#39;s host machine and then exposed to the pod. Provisioned by an admin. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk</TD></TR>
-<TR><TD><CODE>glusterfs</CODE><BR /><I><a href="#glusterfspersistentvolumesource-v1-core">GlusterfsPersistentVolumeSource</a></I></TD><TD>Glusterfs represents a Glusterfs volume that is attached to a host and exposed to the pod. Provisioned by an admin. More info: https://examples.k8s.io/volumes/glusterfs/README.md</TD></TR>
-<TR><TD><CODE>hostPath</CODE><BR /><I><a href="#hostpathvolumesource-v1-core">HostPathVolumeSource</a></I></TD><TD>HostPath represents a directory on the host. Provisioned by a developer or tester. This is useful for single-node development and testing only! On-host storage is not supported in any way and WILL NOT WORK in a multi-node cluster. More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath</TD></TR>
-<TR><TD><CODE>iscsi</CODE><BR /><I><a href="#iscsipersistentvolumesource-v1-core">ISCSIPersistentVolumeSource</a></I></TD><TD>ISCSI represents an ISCSI Disk resource that is attached to a kubelet&#39;s host machine and then exposed to the pod. Provisioned by an admin.</TD></TR>
-<TR><TD><CODE>local</CODE><BR /><I><a href="#localvolumesource-v1-core">LocalVolumeSource</a></I></TD><TD>Local represents directly-attached storage with node affinity</TD></TR>
-<TR><TD><CODE>mountOptions</CODE><BR /><I>string array</I></TD><TD>A list of mount options, e.g. [&#34;ro&#34;, &#34;soft&#34;]. Not validated - mount will simply fail if one is invalid. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options</TD></TR>
-<TR><TD><CODE>nfs</CODE><BR /><I><a href="#nfsvolumesource-v1-core">NFSVolumeSource</a></I></TD><TD>NFS represents an NFS mount on the host. Provisioned by an admin. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs</TD></TR>
-<TR><TD><CODE>nodeAffinity</CODE><BR /><I><a href="#volumenodeaffinity-v1-core">VolumeNodeAffinity</a></I></TD><TD>NodeAffinity defines constraints that limit what nodes this volume can be accessed from. This field influences the scheduling of pods that use this volume.</TD></TR>
-<TR><TD><CODE>persistentVolumeReclaimPolicy</CODE><BR /><I>string</I></TD><TD>What happens to a persistent volume when released from its claim. Valid options are Retain (default for manually created PersistentVolumes), Delete (default for dynamically provisioned PersistentVolumes), and Recycle (deprecated). Recycle must be supported by the volume plugin underlying this PersistentVolume. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#reclaiming</TD></TR>
-<TR><TD><CODE>photonPersistentDisk</CODE><BR /><I><a href="#photonpersistentdiskvolumesource-v1-core">PhotonPersistentDiskVolumeSource</a></I></TD><TD>PhotonPersistentDisk represents a PhotonController persistent disk attached and mounted on kubelets host machine</TD></TR>
-<TR><TD><CODE>portworxVolume</CODE><BR /><I><a href="#portworxvolumesource-v1-core">PortworxVolumeSource</a></I></TD><TD>PortworxVolume represents a portworx volume attached and mounted on kubelets host machine</TD></TR>
-<TR><TD><CODE>quobyte</CODE><BR /><I><a href="#quobytevolumesource-v1-core">QuobyteVolumeSource</a></I></TD><TD>Quobyte represents a Quobyte mount on the host that shares a pod&#39;s lifetime</TD></TR>
-<TR><TD><CODE>rbd</CODE><BR /><I><a href="#rbdpersistentvolumesource-v1-core">RBDPersistentVolumeSource</a></I></TD><TD>RBD represents a Rados Block Device mount on the host that shares a pod&#39;s lifetime. More info: https://examples.k8s.io/volumes/rbd/README.md</TD></TR>
-<TR><TD><CODE>scaleIO</CODE><BR /><I><a href="#scaleiopersistentvolumesource-v1-core">ScaleIOPersistentVolumeSource</a></I></TD><TD>ScaleIO represents a ScaleIO persistent volume attached and mounted on Kubernetes nodes.</TD></TR>
-<TR><TD><CODE>storageClassName</CODE><BR /><I>string</I></TD><TD>Name of StorageClass to which this persistent volume belongs. Empty value means that this volume does not belong to any StorageClass.</TD></TR>
-<TR><TD><CODE>storageos</CODE><BR /><I><a href="#storageospersistentvolumesource-v1-core">StorageOSPersistentVolumeSource</a></I></TD><TD>StorageOS represents a StorageOS volume that is attached to the kubelet&#39;s host machine and mounted into the pod More info: https://examples.k8s.io/volumes/storageos/README.md</TD></TR>
-<TR><TD><CODE>volumeMode</CODE><BR /><I>string</I></TD><TD>volumeMode defines if a volume is intended to be used with a formatted filesystem or to remain in raw block state. Value of Filesystem is implied when not included in spec.</TD></TR>
-<TR><TD><CODE>vsphereVolume</CODE><BR /><I><a href="#vspherevirtualdiskvolumesource-v1-core">VsphereVirtualDiskVolumeSource</a></I></TD><TD>VsphereVolume represents a vSphere volume attached and mounted on kubelets host machine</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="persistentvolumestatus-v1-core">PersistentVolumeStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolume-v1-core">PersistentVolume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human-readable message indicating details about why the volume is in this state.</TD></TR>
-<TR><TD><CODE>phase</CODE><BR /><I>string</I></TD><TD>Phase indicates if a volume is available, bound to a claim, or released by a claim. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#phase</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Reason is a brief CamelCase string that describes any failure and is meant for machine parsing and tidy display in the CLI.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="persistentvolumelist-v1-core">PersistentVolumeList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#persistentvolume-v1-core">PersistentVolume</a> array</I></TD><TD>List of persistent volumes. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-persistentvolume-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-persistentvolume-v1-core">Create</H2>
-<P>create a PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/persistentvolumes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-persistentvolume-v1-core">Patch</H2>
-<P>partially update the specified PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/persistentvolumes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-persistentvolume-v1-core">Replace</H2>
-<P>replace the specified PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/persistentvolumes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-persistentvolume-v1-core">Delete</H2>
-<P>delete a PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/persistentvolumes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-persistentvolume-v1-core">Delete Collection</H2>
-<P>delete collection of PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/persistentvolumes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-persistentvolume-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-persistentvolume-v1-core">Read</H2>
-<P>read the specified PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/persistentvolumes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-persistentvolume-v1-core">List</H2>
-<P>list or watch objects of kind PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/persistentvolumes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolumelist-v1-core">PersistentVolumeList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-persistentvolume-v1-core">Watch</H2>
-<P>watch changes to an object of kind PersistentVolume. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/persistentvolumes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-persistentvolume-v1-core">Watch List</H2>
-<P>watch individual changes to a list of PersistentVolume. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/persistentvolumes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-persistentvolume-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-persistentvolume-v1-core">Patch Status</H2>
-<P>partially update status of the specified PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/persistentvolumes/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-persistentvolume-v1-core">Read Status</H2>
-<P>read status of the specified PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/persistentvolumes/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-persistentvolume-v1-core">Replace Status</H2>
-<P>replace status of the specified PersistentVolume</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/persistentvolumes/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PersistentVolume</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#persistentvolume-v1-core">PersistentVolume</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration v1alpha1 flowcontrol.apiserver.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PriorityLevelConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#prioritylevelconfigurationlist-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationList [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>`metadata` is the standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#prioritylevelconfigurationspec-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationSpec</a></I></TD><TD>`spec` is the specification of the desired behavior of a &#34;request-priority&#34;. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#prioritylevelconfigurationstatus-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationStatus</a></I></TD><TD>`status` is the current status of a &#34;request-priority&#34;. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="prioritylevelconfigurationspec-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationSpec v1alpha1 flowcontrol</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>limited</CODE><BR /><I><a href="#limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">LimitedPriorityLevelConfiguration</a></I></TD><TD>`limited` specifies how requests are handled for a Limited priority level. This field must be non-empty if and only if `type` is `&#34;Limited&#34;`.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>`type` indicates whether this priority level is subject to limitation on request execution.  A value of `&#34;Exempt&#34;` means that requests of this priority level are not subject to a limit (and thus are never queued) and do not detract from the capacity made available to other priority levels.  A value of `&#34;Limited&#34;` means that (a) requests of this priority level _are_ subject to limits and (b) some of the server&#39;s limited capacity is made available exclusively to this priority level. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="prioritylevelconfigurationstatus-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationStatus v1alpha1 flowcontrol</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationCondition</a> array</I></TD><TD>`conditions` is the current state of &#34;request-priority&#34;.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="prioritylevelconfigurationlist-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationList v1alpha1 flowcontrol</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a> array</I></TD><TD>`items` is a list of request-priorities.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>`metadata` is the standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Create</H2>
-<P>create a PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Patch</H2>
-<P>partially update the specified PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Replace</H2>
-<P>replace the specified PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Delete</H2>
-<P>delete a PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Delete Collection</H2>
-<P>delete collection of PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Read</H2>
-<P>read the specified PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">List</H2>
-<P>list or watch objects of kind PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfigurationlist-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Watch</H2>
-<P>watch changes to an object of kind PriorityLevelConfiguration. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/watch/prioritylevelconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of PriorityLevelConfiguration. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/watch/prioritylevelconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Patch Status</H2>
-<P>partially update status of the specified PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Read Status</H2>
-<P>read status of the specified PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">Replace Status</H2>
-<P>replace status of the specified PriorityLevelConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/flowcontrol.apiserver.k8s.io/v1alpha1/prioritylevelconfigurations/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityLevelConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="resourcequota-v1-core">ResourceQuota v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ResourceQuota</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#resourcequotalist-v1-core">ResourceQuotaList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#resourcequotaspec-v1-core">ResourceQuotaSpec</a></I></TD><TD>Spec defines the desired quota. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#resourcequotastatus-v1-core">ResourceQuotaStatus</a></I></TD><TD>Status defines the actual enforced quota and its current usage. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="resourcequotaspec-v1-core">ResourceQuotaSpec v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#resourcequota-v1-core">ResourceQuota [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hard</CODE><BR /><I>object</I></TD><TD>hard is the set of desired hard limits for each named resource. More info: https://kubernetes.io/docs/concepts/policy/resource-quotas/</TD></TR>
-<TR><TD><CODE>scopeSelector</CODE><BR /><I><a href="#scopeselector-v1-core">ScopeSelector</a></I></TD><TD>scopeSelector is also a collection of filters like scopes that must match each object tracked by a quota but expressed using ScopeSelectorOperator in combination with possible values. For a resource to match, both scopes AND scopeSelector (if specified in spec), must be matched.</TD></TR>
-<TR><TD><CODE>scopes</CODE><BR /><I>string array</I></TD><TD>A collection of filters that must match each object tracked by a quota. If not specified, the quota matches all objects.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="resourcequotastatus-v1-core">ResourceQuotaStatus v1 core</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#resourcequota-v1-core">ResourceQuota [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hard</CODE><BR /><I>object</I></TD><TD>Hard is the set of enforced hard limits for each named resource. More info: https://kubernetes.io/docs/concepts/policy/resource-quotas/</TD></TR>
-<TR><TD><CODE>used</CODE><BR /><I>object</I></TD><TD>Used is the current observed total usage of the resource in the namespace.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="resourcequotalist-v1-core">ResourceQuotaList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#resourcequota-v1-core">ResourceQuota</a> array</I></TD><TD>Items is a list of ResourceQuota objects. More info: https://kubernetes.io/docs/concepts/policy/resource-quotas/</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-resourcequota-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-resourcequota-v1-core">Create</H2>
-<P>create a ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/resourcequotas</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-resourcequota-v1-core">Patch</H2>
-<P>partially update the specified ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-resourcequota-v1-core">Replace</H2>
-<P>replace the specified ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/resourcequotas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-resourcequota-v1-core">Delete</H2>
-<P>delete a ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/resourcequotas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-resourcequota-v1-core">Delete Collection</H2>
-<P>delete collection of ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/resourcequotas</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-resourcequota-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-resourcequota-v1-core">Read</H2>
-<P>read the specified ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/resourcequotas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-resourcequota-v1-core">List</H2>
-<P>list or watch objects of kind ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/resourcequotas</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequotalist-v1-core">ResourceQuotaList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-resourcequota-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/resourcequotas</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequotalist-v1-core">ResourceQuotaList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-resourcequota-v1-core">Watch</H2>
-<P>watch changes to an object of kind ResourceQuota. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/resourcequotas/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-resourcequota-v1-core">Watch List</H2>
-<P>watch individual changes to a list of ResourceQuota. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/resourcequotas</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-resourcequota-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of ResourceQuota. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/resourcequotas</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-resourcequota-v1-core-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-resourcequota-v1-core">Patch Status</H2>
-<P>partially update status of the specified ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-resourcequota-v1-core">Read Status</H2>
-<P>read status of the specified ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/resourcequotas/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-resourcequota-v1-core">Replace Status</H2>
-<P>replace status of the specified ResourceQuota</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/resourcequotas/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ResourceQuota</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#resourcequota-v1-core">ResourceQuota</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="role-v1-rbac-authorization-k8s-io">Role v1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Role</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#role-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#role-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#rolelist-v1-rbac-authorization-k8s-io">RoleList [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyrule-v1-rbac-authorization-k8s-io">PolicyRule</a> array</I></TD><TD>Rules holds all the PolicyRules for this Role</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rolelist-v1-rbac-authorization-k8s-io">RoleList v1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a> array</I></TD><TD>Items is a list of Roles</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-role-v1-rbac-authorization-k8s-io">Create</H2>
-<P>create a Role</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-role-v1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-role-v1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-role-v1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a Role</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-role-v1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of Role</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-role-v1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-role-v1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolelist-v1-rbac-authorization-k8s-io">RoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-role-v1-rbac-authorization-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/roles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolelist-v1-rbac-authorization-k8s-io">RoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-role-v1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Role. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-role-v1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Role. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Role. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/roles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="rolebinding-v1-rbac-authorization-k8s-io">RoleBinding v1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>RoleBinding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#rolebindinglist-v1-rbac-authorization-k8s-io">RoleBindingList [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>roleRef</CODE><BR /><I><a href="#roleref-v1-rbac-authorization-k8s-io">RoleRef</a></I></TD><TD>RoleRef can reference a Role in the current namespace or a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1-rbac-authorization-k8s-io">Subject</a> array</I></TD><TD>Subjects holds references to the objects the role applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rolebindinglist-v1-rbac-authorization-k8s-io">RoleBindingList v1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a> array</I></TD><TD>Items is a list of RoleBindings</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-rolebinding-v1-rbac-authorization-k8s-io">Create</H2>
-<P>create a RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-rolebinding-v1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-rolebinding-v1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-rolebinding-v1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-rolebinding-v1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-rolebinding-v1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-rolebinding-v1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebindinglist-v1-rbac-authorization-k8s-io">RoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/rolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebindinglist-v1-rbac-authorization-k8s-io">RoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-rolebinding-v1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind RoleBinding. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-rolebinding-v1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of RoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of RoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1/watch/rolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="runtimeclass-v1beta1-node-k8s-io">RuntimeClass v1beta1 node.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RuntimeClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#runtimeclass-v1alpha1-node-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclasslist-v1beta1-node-k8s-io">RuntimeClassList [node/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>handler</CODE><BR /><I>string</I></TD><TD>Handler specifies the underlying runtime and configuration that the CRI implementation will use to handle pods of this class. The possible values are specific to the node &amp; CRI configuration.  It is assumed that all handlers are available on every node, and handlers of the same name are equivalent on every node. For example, a handler called &#34;runc&#34; might specify that the runc OCI runtime (using native Linux containers) will be used to run the containers in a pod. The Handler must conform to the DNS Label (RFC 1123) requirements, and is immutable.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>overhead</CODE><BR /><I><a href="#overhead-v1beta1-node-k8s-io">Overhead</a></I></TD><TD>Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. For more details, see https://git.k8s.io/enhancements/keps/sig-node/20190226-pod-overhead.md This field is alpha-level as of Kubernetes v1.15, and is only honored by servers that enable the PodOverhead feature.</TD></TR>
-<TR><TD><CODE>scheduling</CODE><BR /><I><a href="#scheduling-v1beta1-node-k8s-io">Scheduling</a></I></TD><TD>Scheduling holds the scheduling constraints to ensure that pods running with this RuntimeClass are scheduled to nodes that support it. If scheduling is nil, this RuntimeClass is assumed to be supported by all nodes.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="runtimeclasslist-v1beta1-node-k8s-io">RuntimeClassList v1beta1 node</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-runtimeclass-v1beta1-node-k8s-io">Create</H2>
-<P>create a RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/node.k8s.io/v1beta1/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-runtimeclass-v1beta1-node-k8s-io">Patch</H2>
-<P>partially update the specified RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/node.k8s.io/v1beta1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-runtimeclass-v1beta1-node-k8s-io">Replace</H2>
-<P>replace the specified RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/node.k8s.io/v1beta1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-runtimeclass-v1beta1-node-k8s-io">Delete</H2>
-<P>delete a RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/node.k8s.io/v1beta1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-runtimeclass-v1beta1-node-k8s-io">Delete Collection</H2>
-<P>delete collection of RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/node.k8s.io/v1beta1/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-runtimeclass-v1beta1-node-k8s-io">Read</H2>
-<P>read the specified RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1beta1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-runtimeclass-v1beta1-node-k8s-io">List</H2>
-<P>list or watch objects of kind RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1beta1/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclasslist-v1beta1-node-k8s-io">RuntimeClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-runtimeclass-v1beta1-node-k8s-io">Watch</H2>
-<P>watch changes to an object of kind RuntimeClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1beta1/watch/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-runtimeclass-v1beta1-node-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of RuntimeClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1beta1/watch/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview v1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SelfSubjectAccessReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#selfsubjectaccessreviewspec-v1-authorization-k8s-io">SelfSubjectAccessReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated.  user and groups must be empty</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectaccessreviewstatus-v1-authorization-k8s-io">SubjectAccessReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request is allowed or not</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="selfsubjectaccessreviewspec-v1-authorization-k8s-io">SelfSubjectAccessReviewSpec v1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nonResourceAttributes</CODE><BR /><I><a href="#nonresourceattributes-v1-authorization-k8s-io">NonResourceAttributes</a></I></TD><TD>NonResourceAttributes describes information for a non-resource access request</TD></TR>
-<TR><TD><CODE>resourceAttributes</CODE><BR /><I><a href="#resourceattributes-v1-authorization-k8s-io">ResourceAttributes</a></I></TD><TD>ResourceAuthorizationAttributes describes information for a resource access request</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-selfsubjectaccessreview-v1-authorization-k8s-io">Create</H2>
-<P>create a SelfSubjectAccessReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1/selfsubjectaccessreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview v1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SelfSubjectRulesReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#selfsubjectrulesreviewspec-v1-authorization-k8s-io">SelfSubjectRulesReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectrulesreviewstatus-v1-authorization-k8s-io">SubjectRulesReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates the set of actions a user can perform.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="selfsubjectrulesreviewspec-v1-authorization-k8s-io">SelfSubjectRulesReviewSpec v1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace to evaluate rules for. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-selfsubjectrulesreview-v1-authorization-k8s-io">Create</H2>
-<P>create a SelfSubjectRulesReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1/selfsubjectrulesreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="serviceaccount-v1-core">ServiceAccount v1 core</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServiceAccount</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#serviceaccountlist-v1-core">ServiceAccountList [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>automountServiceAccountToken</CODE><BR /><I>boolean</I></TD><TD>AutomountServiceAccountToken indicates whether pods running as this service account should have an API token automatically mounted. Can be overridden at the pod level.</TD></TR>
-<TR><TD><CODE>imagePullSecrets</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a> array</I></TD><TD>ImagePullSecrets is a list of references to secrets in the same namespace to use for pulling any images in pods that reference this ServiceAccount. ImagePullSecrets are distinct from Secrets because Secrets can be mounted in the pod, but ImagePullSecrets are only accessed by the kubelet. More info: https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>secrets</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>Secrets is the list of secrets allowed to be used by pods running using this ServiceAccount. More info: https://kubernetes.io/docs/concepts/configuration/secret</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="serviceaccountlist-v1-core">ServiceAccountList v1 core</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#serviceaccount-v1-core">ServiceAccount</a> array</I></TD><TD>List of ServiceAccounts. More info: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-serviceaccount-v1-core-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-serviceaccount-v1-core">Create</H2>
-<P>create a ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>POST /api/v1/namespaces/{namespace}/serviceaccounts</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-serviceaccount-v1-core">Patch</H2>
-<P>partially update the specified ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /api/v1/namespaces/{namespace}/serviceaccounts/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceAccount</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-serviceaccount-v1-core">Replace</H2>
-<P>replace the specified ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /api/v1/namespaces/{namespace}/serviceaccounts/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceAccount</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-serviceaccount-v1-core">Delete</H2>
-<P>delete a ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/serviceaccounts/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceAccount</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-serviceaccount-v1-core">Delete Collection</H2>
-<P>delete collection of ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /api/v1/namespaces/{namespace}/serviceaccounts</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-serviceaccount-v1-core-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-serviceaccount-v1-core">Read</H2>
-<P>read the specified ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/serviceaccounts/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceAccount</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccount-v1-core">ServiceAccount</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-serviceaccount-v1-core">List</H2>
-<P>list or watch objects of kind ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/namespaces/{namespace}/serviceaccounts</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccountlist-v1-core">ServiceAccountList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-serviceaccount-v1-core">List All Namespaces</H2>
-<P>list or watch objects of kind ServiceAccount</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/serviceaccounts</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#serviceaccountlist-v1-core">ServiceAccountList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-serviceaccount-v1-core">Watch</H2>
-<P>watch changes to an object of kind ServiceAccount. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/serviceaccounts/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ServiceAccount</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-serviceaccount-v1-core">Watch List</H2>
-<P>watch individual changes to a list of ServiceAccount. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/namespaces/{namespace}/serviceaccounts</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-serviceaccount-v1-core">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of ServiceAccount. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /api/v1/watch/serviceaccounts</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview v1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SubjectAccessReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subjectaccessreview-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#subjectaccessreviewspec-v1-authorization-k8s-io">SubjectAccessReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectaccessreviewstatus-v1-authorization-k8s-io">SubjectAccessReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request is allowed or not</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="subjectaccessreviewspec-v1-authorization-k8s-io">SubjectAccessReviewSpec v1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview [authorization/v1]</a></LI>
-  <LI><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extra</CODE><BR /><I>object</I></TD><TD>Extra corresponds to the user.Info.GetExtra() method from the authenticator.  Since that is input to the authorizer it needs a reflection here.</TD></TR>
-<TR><TD><CODE>groups</CODE><BR /><I>string array</I></TD><TD>Groups is the groups you&#39;re testing for.</TD></TR>
-<TR><TD><CODE>nonResourceAttributes</CODE><BR /><I><a href="#nonresourceattributes-v1-authorization-k8s-io">NonResourceAttributes</a></I></TD><TD>NonResourceAttributes describes information for a non-resource access request</TD></TR>
-<TR><TD><CODE>resourceAttributes</CODE><BR /><I><a href="#resourceattributes-v1-authorization-k8s-io">ResourceAttributes</a></I></TD><TD>ResourceAuthorizationAttributes describes information for a resource access request</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID information about the requesting user.</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>User is the user you&#39;re testing for. If you specify &#34;User&#34; but not &#34;Groups&#34;, then is it interpreted as &#34;What if User were not a member of any groups</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="subjectaccessreviewstatus-v1-authorization-k8s-io">SubjectAccessReviewStatus v1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview [authorization/v1]</a></LI>
-  <LI><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview [authorization/v1]</a></LI>
-  <LI><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowed</CODE><BR /><I>boolean</I></TD><TD>Allowed is required. True if the action would be allowed, false otherwise.</TD></TR>
-<TR><TD><CODE>denied</CODE><BR /><I>boolean</I></TD><TD>Denied is optional. True if the action would be denied, otherwise false. If both allowed is false and denied is false, then the authorizer has no opinion on whether to authorize the action. Denied may not be true if Allowed is true.</TD></TR>
-<TR><TD><CODE>evaluationError</CODE><BR /><I>string</I></TD><TD>EvaluationError is an indication that some error occurred during the authorization check. It is entirely possible to get an error and be able to continue determine authorization status in spite of it. For instance, RBAC can be missing a role, but enough roles are still present and bound to reason about the request.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Reason is optional.  It indicates why a request was allowed or denied.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-subjectaccessreview-v1-authorization-k8s-io">Create</H2>
-<P>create a SubjectAccessReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1/subjectaccessreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="tokenrequest-v1-authentication-k8s-io">TokenRequest v1 authentication.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TokenRequest</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#tokenrequestspec-v1-authentication-k8s-io">TokenRequestSpec</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#tokenrequeststatus-v1-authentication-k8s-io">TokenRequestStatus</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="tokenrequestspec-v1-authentication-k8s-io">TokenRequestSpec v1 authentication</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenrequest-v1-authentication-k8s-io">TokenRequest [authentication/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>audiences</CODE><BR /><I>string array</I></TD><TD>Audiences are the intendend audiences of the token. A recipient of a token must identitfy themself with an identifier in the list of audiences of the token, and otherwise should reject the token. A token issued for multiple audiences may be used to authenticate against any of the audiences listed but implies a high degree of trust between the target audiences.</TD></TR>
-<TR><TD><CODE>boundObjectRef</CODE><BR /><I><a href="#boundobjectreference-v1-authentication-k8s-io">BoundObjectReference</a></I></TD><TD>BoundObjectRef is a reference to an object that the token will be bound to. The token will only be valid for as long as the bound object exists. NOTE: The API server&#39;s TokenReview endpoint will validate the BoundObjectRef, but other audiences may not. Keep ExpirationSeconds small if you want prompt revocation.</TD></TR>
-<TR><TD><CODE>expirationSeconds</CODE><BR /><I>integer</I></TD><TD>ExpirationSeconds is the requested duration of validity of the request. The token issuer may return a token with a different validity duration so a client needs to check the &#39;expiration&#39; field in a response.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="tokenrequeststatus-v1-authentication-k8s-io">TokenRequestStatus v1 authentication</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenrequest-v1-authentication-k8s-io">TokenRequest [authentication/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>expirationTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>ExpirationTimestamp is the time of expiration of the returned token.</TD></TR>
-<TR><TD><CODE>token</CODE><BR /><I>string</I></TD><TD>Token is the opaque bearer token.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="tokenreview-v1-authentication-k8s-io">TokenReview v1 authentication.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TokenReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#tokenreview-v1beta1-authentication-k8s-io">v1beta1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#tokenreviewspec-v1-authentication-k8s-io">TokenReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#tokenreviewstatus-v1-authentication-k8s-io">TokenReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request can be authenticated.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="tokenreviewspec-v1-authentication-k8s-io">TokenReviewSpec v1 authentication</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenreview-v1-authentication-k8s-io">TokenReview [authentication/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>audiences</CODE><BR /><I>string array</I></TD><TD>Audiences is a list of the identifiers that the resource server presented with the token identifies as. Audience-aware token authenticators will verify that the token was intended for at least one of the audiences in this list. If no audiences are provided, the audience will default to the audience of the Kubernetes apiserver.</TD></TR>
-<TR><TD><CODE>token</CODE><BR /><I>string</I></TD><TD>Token is the opaque bearer token.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="tokenreviewstatus-v1-authentication-k8s-io">TokenReviewStatus v1 authentication</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenreview-v1-authentication-k8s-io">TokenReview [authentication/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>audiences</CODE><BR /><I>string array</I></TD><TD>Audiences are audience identifiers chosen by the authenticator that are compatible with both the TokenReview and token. An identifier is any identifier in the intersection of the TokenReviewSpec audiences and the token&#39;s audiences. A client of the TokenReview API that sets the spec.audiences field should validate that a compatible audience identifier is returned in the status.audiences field to ensure that the TokenReview server is audience aware. If a TokenReview returns an empty status.audience field where status.authenticated is &#34;true&#34;, the token is valid against the audience of the Kubernetes API server.</TD></TR>
-<TR><TD><CODE>authenticated</CODE><BR /><I>boolean</I></TD><TD>Authenticated indicates that the token was associated with a known user.</TD></TR>
-<TR><TD><CODE>error</CODE><BR /><I>string</I></TD><TD>Error indicates that the token couldn&#39;t be checked</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I><a href="#userinfo-v1-authentication-k8s-io">UserInfo</a></I></TD><TD>User is the UserInfo associated with the provided token.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-tokenreview-v1-authentication-k8s-io">Create</H2>
-<P>create a TokenReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authentication.k8s.io/v1/tokenreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#tokenreview-v1-authentication-k8s-io">TokenReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#tokenreview-v1-authentication-k8s-io">TokenReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#tokenreview-v1-authentication-k8s-io">TokenReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#tokenreview-v1-authentication-k8s-io">TokenReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="networkpolicy-v1-networking-k8s-io">NetworkPolicy v1 networking.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NetworkPolicy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicylist-v1-networking-k8s-io">NetworkPolicyList [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#networkpolicyspec-v1-networking-k8s-io">NetworkPolicySpec</a></I></TD><TD>Specification of the desired behavior for this NetworkPolicy.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="networkpolicyspec-v1-networking-k8s-io">NetworkPolicySpec v1 networking</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>egress</CODE><BR /><I><a href="#networkpolicyegressrule-v1-networking-k8s-io">NetworkPolicyEgressRule</a> array</I></TD><TD>List of egress rules to be applied to the selected pods. Outgoing traffic is allowed if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic matches at least one egress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this field is empty then this NetworkPolicy limits all outgoing traffic (and serves solely to ensure that the pods it selects are isolated by default). This field is beta-level in 1.8</TD></TR>
-<TR><TD><CODE>ingress</CODE><BR /><I><a href="#networkpolicyingressrule-v1-networking-k8s-io">NetworkPolicyIngressRule</a> array</I></TD><TD>List of ingress rules to be applied to the selected pods. Traffic is allowed to a pod if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic source is the pod&#39;s local node, OR if the traffic matches at least one ingress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this field is empty then this NetworkPolicy does not allow any traffic (and serves solely to ensure that the pods it selects are isolated by default)</TD></TR>
-<TR><TD><CODE>podSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>Selects the pods to which this NetworkPolicy object applies. The array of ingress rules is applied to any pods selected by this field. Multiple network policies can select the same set of pods. In this case, the ingress rules for each are combined additively. This field is NOT optional and follows standard label selector semantics. An empty podSelector matches all pods in this namespace.</TD></TR>
-<TR><TD><CODE>policyTypes</CODE><BR /><I>string array</I></TD><TD>List of rule types that the NetworkPolicy relates to. Valid options are &#34;Ingress&#34;, &#34;Egress&#34;, or &#34;Ingress,Egress&#34;. If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ &#34;Egress&#34; ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include &#34;Egress&#34; (since such a policy would not include an Egress section and would otherwise default to just [ &#34;Ingress&#34; ]). This field is beta-level in 1.8</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="networkpolicylist-v1-networking-k8s-io">NetworkPolicyList v1 networking</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-networkpolicy-v1-networking-k8s-io">Create</H2>
-<P>create a NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-networkpolicy-v1-networking-k8s-io">Patch</H2>
-<P>partially update the specified NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NetworkPolicy</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-networkpolicy-v1-networking-k8s-io">Replace</H2>
-<P>replace the specified NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NetworkPolicy</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-networkpolicy-v1-networking-k8s-io">Delete</H2>
-<P>delete a NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NetworkPolicy</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-networkpolicy-v1-networking-k8s-io">Delete Collection</H2>
-<P>delete collection of NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-networkpolicy-v1-networking-k8s-io">Read</H2>
-<P>read the specified NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NetworkPolicy</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-networkpolicy-v1-networking-k8s-io">List</H2>
-<P>list or watch objects of kind NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#networkpolicylist-v1-networking-k8s-io">NetworkPolicyList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-networkpolicy-v1-networking-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind NetworkPolicy</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1/networkpolicies</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#networkpolicylist-v1-networking-k8s-io">NetworkPolicyList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-networkpolicy-v1-networking-k8s-io">Watch</H2>
-<P>watch changes to an object of kind NetworkPolicy. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1/watch/namespaces/{namespace}/networkpolicies/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the NetworkPolicy</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-networkpolicy-v1-networking-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of NetworkPolicy. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1/watch/namespaces/{namespace}/networkpolicies</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of NetworkPolicy. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/networking.k8s.io/v1/watch/networkpolicies</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="-strong-definitions-strong-"><STRONG>DEFINITIONS</STRONG></H1>
-
-<P>This section contains definitions for objects used in the Kubernetes APIs.</P>
-<H2 id="apigroup-v1-meta">APIGroup v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>APIGroup</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>APIGroup contains the name, the supported versions, and the preferred version of a group.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apigrouplist-v1-meta">APIGroupList [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the group.</TD></TR>
-<TR><TD><CODE>preferredVersion</CODE><BR /><I><a href="#groupversionfordiscovery-v1-meta">GroupVersionForDiscovery</a></I></TD><TD>preferredVersion is the version preferred by the API server, which probably is the storage version.</TD></TR>
-<TR><TD><CODE>serverAddressByClientCIDRs</CODE><BR /><I><a href="#serveraddressbyclientcidr-v1-meta">ServerAddressByClientCIDR</a> array</I></TD><TD>a map of client CIDR to server address that is serving this group. This is to help clients reach servers in the most network-efficient way possible. Clients can use the appropriate server address as per the CIDR that they match. In case of multiple matches, clients should use the longest matching CIDR. The server returns only those CIDRs that it thinks that the client can match. For example: the master will return an internal IP CIDR only, if the client reaches the server using an internal IP. Server looks at X-Forwarded-For header or X-Real-Ip header or request.RemoteAddr (in that order) to get the client IP.</TD></TR>
-<TR><TD><CODE>versions</CODE><BR /><I><a href="#groupversionfordiscovery-v1-meta">GroupVersionForDiscovery</a> array</I></TD><TD>versions are the versions supported in this group.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="apiresource-v1-meta">APIResource v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>APIResource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>APIResource specifies the name of a resource and whether it is namespaced.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiresourcelist-v1-meta">APIResourceList [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>categories</CODE><BR /><I>string array</I></TD><TD>categories is a list of the grouped resources this resource belongs to (e.g. &#39;all&#39;)</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>group is the preferred group of the resource.  Empty implies the group of the containing resource list. For subresources, this may have a different value, for example: Scale&#34;.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>kind is the kind for the resource (e.g. &#39;Foo&#39; is the kind for a resource &#39;foo&#39;)</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the plural name of the resource.</TD></TR>
-<TR><TD><CODE>namespaced</CODE><BR /><I>boolean</I></TD><TD>namespaced indicates if a resource is namespaced or not.</TD></TR>
-<TR><TD><CODE>shortNames</CODE><BR /><I>string array</I></TD><TD>shortNames is a list of suggested short names of the resource.</TD></TR>
-<TR><TD><CODE>singularName</CODE><BR /><I>string</I></TD><TD>singularName is the singular name of the resource.  This allows clients to handle plural and singular opaquely. The singularName is more correct for reporting status on a single item and both singular and plural are allowed from the kubectl CLI interface.</TD></TR>
-<TR><TD><CODE>storageVersionHash</CODE><BR /><I>string</I></TD><TD>The hash value of the storage version, the version this resource is converted to when written to the data store. Value must be treated as opaque by clients. Only equality comparison on the value is valid. This is an alpha feature and may change or be removed in the future. The field is populated by the apiserver only if the StorageVersionHash feature gate is enabled. This field will remain optional even if it graduates.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>verbs is a list of supported kube verbs (this includes get, list, watch, create, update, patch, delete, deletecollection, and proxy)</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>version is the preferred version of the resource.  Empty implies the version of the containing resource list For subresources, this may have a different value, for example: v1 (while inside a v1beta1 version of the core resource&#39;s group)&#34;.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="apiservicecondition-v1-apiregistration-k8s-io">APIServiceCondition v1 apiregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>APIServiceCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>APIServiceCondition describes the state of an APIService at a particular point</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#apiservicecondition-v1beta1-apiregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicestatus-v1-apiregistration-k8s-io">APIServiceStatus [apiregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status is the status of the condition. Can be True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type is the type of the condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="apiversions-v1-meta">APIVersions v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>APIVersions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>APIVersions lists the versions that are available, to allow clients to discover the API at /api, which is the root path of the legacy v1 API.</P>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>serverAddressByClientCIDRs</CODE><BR /><I><a href="#serveraddressbyclientcidr-v1-meta">ServerAddressByClientCIDR</a> array</I></TD><TD>a map of client CIDR to server address that is serving this group. This is to help clients reach servers in the most network-efficient way possible. Clients can use the appropriate server address as per the CIDR that they match. In case of multiple matches, clients should use the longest matching CIDR. The server returns only those CIDRs that it thinks that the client can match. For example: the master will return an internal IP CIDR only, if the client reaches the server using an internal IP. Server looks at X-Forwarded-For header or X-Real-Ip header or request.RemoteAddr (in that order) to get the client IP.</TD></TR>
-<TR><TD><CODE>versions</CODE><BR /><I>string array</I></TD><TD>versions are the api versions that are available.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="awselasticblockstorevolumesource-v1-core">AWSElasticBlockStoreVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>AWSElasticBlockStoreVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Persistent Disk resource in AWS.
-
-An AWS EBS disk must exist before mounting to a container. The disk must also be in the same AWS zone as the kubelet. An AWS EBS disk can only be mounted as read/write once. AWS EBS volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore</TD></TR>
-<TR><TD><CODE>partition</CODE><BR /><I>integer</I></TD><TD>The partition in the volume that you want to mount. If omitted, the default is to mount by volume name. Examples: For volume /dev/sda1, you specify the partition as &#34;1&#34;. Similarly, the volume partition for /dev/sda is &#34;0&#34; (or you can leave the property empty).</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Specify &#34;true&#34; to force and set the ReadOnly property in VolumeMounts to &#34;true&#34;. If omitted, the default is &#34;false&#34;. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore</TD></TR>
-<TR><TD><CODE>volumeID</CODE><BR /><I>string</I></TD><TD>Unique ID of the persistent disk resource in AWS (Amazon EBS volume). More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="affinity-v1-core">Affinity v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Affinity</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Affinity is a group of affinity scheduling rules.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nodeAffinity</CODE><BR /><I><a href="#nodeaffinity-v1-core">NodeAffinity</a></I></TD><TD>Describes node affinity scheduling rules for the pod.</TD></TR>
-<TR><TD><CODE>podAffinity</CODE><BR /><I><a href="#podaffinity-v1-core">PodAffinity</a></I></TD><TD>Describes pod affinity scheduling rules (e.g. co-locate this pod in the same node, zone, etc. as some other pod(s)).</TD></TR>
-<TR><TD><CODE>podAntiAffinity</CODE><BR /><I><a href="#podantiaffinity-v1-core">PodAntiAffinity</a></I></TD><TD>Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod in the same node, zone, etc. as some other pod(s)).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="aggregationrule-v1-rbac-authorization-k8s-io">AggregationRule v1 rbac.authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>AggregationRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AggregationRule describes how to locate ClusterRoles to aggregate into the ClusterRole</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#aggregationrule-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#aggregationrule-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clusterRoleSelectors</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a> array</I></TD><TD>ClusterRoleSelectors holds a list of selectors which will be used to find ClusterRoles and create the rules. If any of the selectors match, then the ClusterRole&#39;s permissions will be added</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="allowedcsidriver-v1beta1-policy">AllowedCSIDriver v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>AllowedCSIDriver</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AllowedCSIDriver represents a single inline CSI Driver that is allowed to be used.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the registered name of the CSI driver</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="allowedflexvolume-v1beta1-policy">AllowedFlexVolume v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>AllowedFlexVolume</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AllowedFlexVolume represents a single Flexvolume that is allowed to be used.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>driver</CODE><BR /><I>string</I></TD><TD>driver is the name of the Flexvolume driver.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="allowedhostpath-v1beta1-policy">AllowedHostPath v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>AllowedHostPath</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AllowedHostPath defines the host volume conditions that will be enabled by a policy for pods to use. It requires the path prefix to be defined.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pathPrefix</CODE><BR /><I>string</I></TD><TD>pathPrefix is the path prefix that the host volume must match. It does not support `*`. Trailing slashes are trimmed when validating the path prefix with a host path.  Examples: `/foo` would allow `/foo`, `/foo/` and `/foo/bar` `/foo` would not allow `/food` or `/etc/foo`</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>when set to true, will allow host volumes matching the pathPrefix only if all volume mounts are readOnly.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="attachedvolume-v1-core">AttachedVolume v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>AttachedVolume</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AttachedVolume describes a volume attached to a node</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>devicePath</CODE><BR /><I>string</I></TD><TD>DevicePath represents the device path where the volume should be available</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the attached volume</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="azurediskvolumesource-v1-core">AzureDiskVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>AzureDiskVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AzureDisk represents an Azure Data Disk mount on the host and bind mount to the pod.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>cachingMode</CODE><BR /><I>string</I></TD><TD>Host Caching mode: None, Read Only, Read Write.</TD></TR>
-<TR><TD><CODE>diskName</CODE><BR /><I>string</I></TD><TD>The Name of the data disk in the blob storage</TD></TR>
-<TR><TD><CODE>diskURI</CODE><BR /><I>string</I></TD><TD>The URI the data disk in the blob storage</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Expected values Shared: multiple blob disks per storage account  Dedicated: single blob disk per storage account  Managed: azure managed data disk (only in managed availability set). defaults to shared</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="azurefilepersistentvolumesource-v1-core">AzureFilePersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>AzureFilePersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AzureFile represents an Azure File Service mount on the host and bind mount to the pod.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretName</CODE><BR /><I>string</I></TD><TD>the name of secret that contains Azure Storage Account Name and Key</TD></TR>
-<TR><TD><CODE>secretNamespace</CODE><BR /><I>string</I></TD><TD>the namespace of the secret that contains Azure Storage Account Name and Key default is the same as the Pod</TD></TR>
-<TR><TD><CODE>shareName</CODE><BR /><I>string</I></TD><TD>Share Name</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="azurefilevolumesource-v1-core">AzureFileVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>AzureFileVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>AzureFile represents an Azure File Service mount on the host and bind mount to the pod.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretName</CODE><BR /><I>string</I></TD><TD>the name of secret that contains Azure Storage Account Name and Key</TD></TR>
-<TR><TD><CODE>shareName</CODE><BR /><I>string</I></TD><TD>Share Name</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="boundobjectreference-v1-authentication-k8s-io">BoundObjectReference v1 authentication.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>BoundObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>BoundObjectReference is a reference to an object that a token is bound to.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenrequestspec-v1-authentication-k8s-io">TokenRequestSpec [authentication/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>API version of the referent.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of the referent. Valid kinds are &#39;Pod&#39; and &#39;Secret&#39;.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID of the referent.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="csinodedriver-v1-storage-k8s-io">CSINodeDriver v1 storage.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CSINodeDriver</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CSINodeDriver holds information about the specification of one CSI driver installed on a node</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#csinodedriver-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinodespec-v1-storage-k8s-io">CSINodeSpec [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allocatable</CODE><BR /><I><a href="#volumenoderesources-v1-storage-k8s-io">VolumeNodeResources</a></I></TD><TD>allocatable represents the volume resources of a node that are available for scheduling. This field is beta.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>This is the name of the CSI driver that this object refers to. This MUST be the same name returned by the CSI GetPluginName() call for that driver.</TD></TR>
-<TR><TD><CODE>nodeID</CODE><BR /><I>string</I></TD><TD>nodeID of the node from the driver point of view. This field enables Kubernetes to communicate with storage systems that do not share the same nomenclature for nodes. For example, Kubernetes may refer to a given node as &#34;node1&#34;, but the storage system may refer to the same node as &#34;nodeA&#34;. When Kubernetes issues a command to the storage system to attach a volume to a specific node, it can use this field to refer to the node name using the ID that the storage system will understand, e.g. &#34;nodeA&#34; instead of &#34;node1&#34;. This field is required.</TD></TR>
-<TR><TD><CODE>topologyKeys</CODE><BR /><I>string array</I></TD><TD>topologyKeys is the list of keys supported by the driver. When a driver is initialized on a cluster, it provides a set of topology keys that it understands (e.g. &#34;company.com/zone&#34;, &#34;company.com/region&#34;). When a driver is initialized on a node, it provides the same topology keys along with values. Kubelet will expose these topology keys as labels on its own node object. When Kubernetes does topology aware provisioning, it can use this list to determine which labels it should retrieve from the node object and pass back to the driver. It is possible for different nodes to use different topology keys. This can be empty if driver does not support topology.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="csipersistentvolumesource-v1-core">CSIPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CSIPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents storage that is managed by an external CSI volume driver (Beta feature)</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>controllerExpandSecretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>ControllerExpandSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerExpandVolume call. This is an alpha field and requires enabling ExpandCSIVolumes feature gate. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed.</TD></TR>
-<TR><TD><CODE>controllerPublishSecretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>ControllerPublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerPublishVolume and ControllerUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed.</TD></TR>
-<TR><TD><CODE>driver</CODE><BR /><I>string</I></TD><TD>Driver is the name of the driver to use for this volume. Required.</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;.</TD></TR>
-<TR><TD><CODE>nodePublishSecretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>NodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed.</TD></TR>
-<TR><TD><CODE>nodeStageSecretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>NodeStageSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodeStageVolume and NodeStageVolume and NodeUnstageVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: The value to pass to ControllerPublishVolumeRequest. Defaults to false (read/write).</TD></TR>
-<TR><TD><CODE>volumeAttributes</CODE><BR /><I>object</I></TD><TD>Attributes of the volume to publish.</TD></TR>
-<TR><TD><CODE>volumeHandle</CODE><BR /><I>string</I></TD><TD>VolumeHandle is the unique volume name returned by the CSI volume plugin’s CreateVolume to refer to the volume on all subsequent calls. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="csivolumesource-v1-core">CSIVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CSIVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a source location of a volume to mount, managed by an external CSI driver</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>driver</CODE><BR /><I>string</I></TD><TD>Driver is the name of the CSI driver that handles this volume. Consult with your admin for the correct name as registered in the cluster.</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. If not provided, the empty value is passed to the associated CSI driver which will determine the default filesystem to apply.</TD></TR>
-<TR><TD><CODE>nodePublishSecretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>NodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and  may be empty if no secret is required. If the secret object contains more than one secret, all secret references are passed.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Specifies a read-only configuration for the volume. Defaults to false (read/write).</TD></TR>
-<TR><TD><CODE>volumeAttributes</CODE><BR /><I>object</I></TD><TD>VolumeAttributes stores driver-specific properties that are passed to the CSI driver. Consult your driver&#39;s documentation for supported values.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="capabilities-v1-core">Capabilities v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Capabilities</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Adds and removes POSIX capabilities from running containers.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#securitycontext-v1-core">SecurityContext [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>add</CODE><BR /><I>string array</I></TD><TD>Added capabilities</TD></TR>
-<TR><TD><CODE>drop</CODE><BR /><I>string array</I></TD><TD>Removed capabilities</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="cephfspersistentvolumesource-v1-core">CephFSPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CephFSPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Ceph Filesystem mount that lasts the lifetime of a pod Cephfs volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>monitors</CODE><BR /><I>string array</I></TD><TD>Required: Monitors is a collection of Ceph monitors More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Optional: Used as the mounted root, rather than the full Ceph tree, default is /</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts. More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>secretFile</CODE><BR /><I>string</I></TD><TD>Optional: SecretFile is the path to key ring for User, default is /etc/ceph/user.secret More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>Optional: SecretRef is reference to the authentication secret for User, default is empty. More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>Optional: User is the rados user name, default is admin More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="cephfsvolumesource-v1-core">CephFSVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CephFSVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Ceph Filesystem mount that lasts the lifetime of a pod Cephfs volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>monitors</CODE><BR /><I>string array</I></TD><TD>Required: Monitors is a collection of Ceph monitors More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Optional: Used as the mounted root, rather than the full Ceph tree, default is /</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts. More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>secretFile</CODE><BR /><I>string</I></TD><TD>Optional: SecretFile is the path to key ring for User, default is /etc/ceph/user.secret More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>Optional: SecretRef is reference to the authentication secret for User, default is empty. More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>Optional: User is the rados user name, default is admin More info: https://examples.k8s.io/volumes/cephfs/README.md#how-to-use-it</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="certificatesigningrequestcondition-v1beta1-certificates-k8s-io">CertificateSigningRequestCondition v1beta1 certificates.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>certificates.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CertificateSigningRequestCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P></P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#certificatesigningrequeststatus-v1beta1-certificates-k8s-io">CertificateSigningRequestStatus [certificates/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastUpdateTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>timestamp for the last update to this condition</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>human readable message with details about the request state</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>brief reason for the request state</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>request approval state, currently Approved or Denied.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="cinderpersistentvolumesource-v1-core">CinderPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CinderPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a cinder volume resource in Openstack. A Cinder volume must exist before mounting to a container. The volume must also be in the same region as the kubelet. Cinder volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>Optional: points to a secret object containing parameters used to connect to OpenStack.</TD></TR>
-<TR><TD><CODE>volumeID</CODE><BR /><I>string</I></TD><TD>volume id used to identify the volume in cinder. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="cindervolumesource-v1-core">CinderVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CinderVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a cinder volume resource in Openstack. A Cinder volume must exist before mounting to a container. The volume must also be in the same region as the kubelet. Cinder volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>Optional: points to a secret object containing parameters used to connect to OpenStack.</TD></TR>
-<TR><TD><CODE>volumeID</CODE><BR /><I>string</I></TD><TD>volume id used to identify the volume in cinder. More info: https://examples.k8s.io/mysql-cinder-pd/README.md</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="clientipconfig-v1-core">ClientIPConfig v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ClientIPConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ClientIPConfig represents the configurations of Client IP based session affinity.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#sessionaffinityconfig-v1-core">SessionAffinityConfig [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>timeoutSeconds</CODE><BR /><I>integer</I></TD><TD>timeoutSeconds specifies the seconds of ClientIP type session sticky time. The value must be &gt;0 &amp;&amp; &lt;=86400(for 1 day) if ServiceAffinity == &#34;ClientIP&#34;. Default value is 10800(for 3 hours).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="componentcondition-v1-core">ComponentCondition v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ComponentCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Information about the condition of a component.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#componentstatus-v1-core">ComponentStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>error</CODE><BR /><I>string</I></TD><TD>Condition error code for a component. For example, a health check error code.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Message about the condition for a component. For example, information about a health check.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition for a component. Valid values for &#34;Healthy&#34;: &#34;True&#34;, &#34;False&#34;, or &#34;Unknown&#34;.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of condition for a component. Valid value: &#34;Healthy&#34;</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="configmapenvsource-v1-core">ConfigMapEnvSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ConfigMapEnvSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ConfigMapEnvSource selects a ConfigMap to populate the environment variables with.
-
-The contents of the target ConfigMap&#39;s Data field will represent the key-value pairs as environment variables.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#envfromsource-v1-core">EnvFromSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the ConfigMap must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="configmapkeyselector-v1-core">ConfigMapKeySelector v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ConfigMapKeySelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Selects a key from a ConfigMap.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#envvarsource-v1-core">EnvVarSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>The key to select.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the ConfigMap or its key must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="configmapnodeconfigsource-v1-core">ConfigMapNodeConfigSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ConfigMapNodeConfigSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodeconfigsource-v1-core">NodeConfigSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>kubeletConfigKey</CODE><BR /><I>string</I></TD><TD>KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the metadata.name of the referenced ConfigMap. This field is required in all cases.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE><BR /><I>string</I></TD><TD>ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="configmapprojection-v1-core">ConfigMapProjection v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ConfigMapProjection</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Adapts a ConfigMap into a projected volume.
-
-The contents of the target ConfigMap&#39;s Data field will be presented in a projected volume as files using the keys in the Data field as the file names, unless the items element is populated with specific mappings of keys to paths. Note that this is identical to a configmap volume source without the default mode.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeprojection-v1-core">VolumeProjection [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#keytopath-v1-core">KeyToPath</a> array</I></TD><TD>If unspecified, each key-value pair in the Data field of the referenced ConfigMap will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the ConfigMap, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the &#39;..&#39; path or start with &#39;..&#39;.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the ConfigMap or its keys must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="configmapvolumesource-v1-core">ConfigMapVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ConfigMapVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Adapts a ConfigMap into a volume.
-
-The contents of the target ConfigMap&#39;s Data field will be presented in a volume as files using the keys in the Data field as the file names, unless the items element is populated with specific mappings of keys to paths. ConfigMap volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>defaultMode</CODE><BR /><I>integer</I></TD><TD>Optional: mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#keytopath-v1-core">KeyToPath</a> array</I></TD><TD>If unspecified, each key-value pair in the Data field of the referenced ConfigMap will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the ConfigMap, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the &#39;..&#39; path or start with &#39;..&#39;.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the ConfigMap or its keys must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="containerimage-v1-core">ContainerImage v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ContainerImage</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Describe a container image</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>names</CODE><BR /><I>string array</I></TD><TD>Names by which this image is known. e.g. [&#34;k8s.gcr.io/hyperkube:v1.0.7&#34;, &#34;dockerhub.io/google_containers/hyperkube:v1.0.7&#34;]</TD></TR>
-<TR><TD><CODE>sizeBytes</CODE><BR /><I>integer</I></TD><TD>The size of the image in bytes.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="containerport-v1-core">ContainerPort v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ContainerPort</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ContainerPort represents a network port in a single container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>containerPort</CODE><BR /><I>integer</I></TD><TD>Number of port to expose on the pod&#39;s IP address. This must be a valid port number, 0 &lt; x &lt; 65536.</TD></TR>
-<TR><TD><CODE>hostIP</CODE><BR /><I>string</I></TD><TD>What host IP to bind the external port to.</TD></TR>
-<TR><TD><CODE>hostPort</CODE><BR /><I>integer</I></TD><TD>Number of port to expose on the host. If specified, this must be a valid port number, 0 &lt; x &lt; 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services.</TD></TR>
-<TR><TD><CODE>protocol</CODE><BR /><I>string</I></TD><TD>Protocol for port. Must be UDP, TCP, or SCTP. Defaults to &#34;TCP&#34;.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="containerstate-v1-core">ContainerState v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ContainerState</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#containerstatus-v1-core">ContainerStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>running</CODE><BR /><I><a href="#containerstaterunning-v1-core">ContainerStateRunning</a></I></TD><TD>Details about a running container</TD></TR>
-<TR><TD><CODE>terminated</CODE><BR /><I><a href="#containerstateterminated-v1-core">ContainerStateTerminated</a></I></TD><TD>Details about a terminated container</TD></TR>
-<TR><TD><CODE>waiting</CODE><BR /><I><a href="#containerstatewaiting-v1-core">ContainerStateWaiting</a></I></TD><TD>Details about a waiting container</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="containerstaterunning-v1-core">ContainerStateRunning v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ContainerStateRunning</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ContainerStateRunning is a running state of a container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#containerstate-v1-core">ContainerState [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>startedAt</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time at which the container was last (re-)started</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="containerstateterminated-v1-core">ContainerStateTerminated v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ContainerStateTerminated</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ContainerStateTerminated is a terminated state of a container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#containerstate-v1-core">ContainerState [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>containerID</CODE><BR /><I>string</I></TD><TD>Container&#39;s ID in the format &#39;docker://&lt;container_id&gt;&#39;</TD></TR>
-<TR><TD><CODE>exitCode</CODE><BR /><I>integer</I></TD><TD>Exit status from the last termination of the container</TD></TR>
-<TR><TD><CODE>finishedAt</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time at which the container last terminated</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Message regarding the last termination of the container</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>(brief) reason from the last termination of the container</TD></TR>
-<TR><TD><CODE>signal</CODE><BR /><I>integer</I></TD><TD>Signal from the last termination of the container</TD></TR>
-<TR><TD><CODE>startedAt</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time at which previous execution of the container started</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="containerstatewaiting-v1-core">ContainerStateWaiting v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ContainerStateWaiting</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ContainerStateWaiting is a waiting state of a container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#containerstate-v1-core">ContainerState [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Message regarding why the container is not yet running.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>(brief) reason the container is not yet running.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="crossversionobjectreference-v1-autoscaling">CrossVersionObjectReference v1 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CrossVersionObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CrossVersionObjectReference contains enough information to let you identify the referred resource.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#crossversionobjectreference-v2beta2-autoscaling">v2beta2</a>
-<a href="#crossversionobjectreference-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerspec-v1-autoscaling">HorizontalPodAutoscalerSpec [autoscaling/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>API version of the referent</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcecolumndefinition-v1-apiextensions-k8s-io">CustomResourceColumnDefinition v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceColumnDefinition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceColumnDefinition specifies a column for server side printing.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcecolumndefinition-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionversion-v1-apiextensions-k8s-io">CustomResourceDefinitionVersion [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD>description is a human readable description of this column.</TD></TR>
-<TR><TD><CODE>format</CODE><BR /><I>string</I></TD><TD>format is an optional OpenAPI type definition for this column. The &#39;name&#39; format is applied to the primary identifier column to assist in clients identifying column is the resource name. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details.</TD></TR>
-<TR><TD><CODE>jsonPath</CODE><BR /><I>string</I></TD><TD>jsonPath is a simple JSON path (i.e. with array notation) which is evaluated against each custom resource to produce the value for this column.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is a human readable name for the column.</TD></TR>
-<TR><TD><CODE>priority</CODE><BR /><I>integer</I></TD><TD>priority is an integer defining the relative importance of this column compared to others. Lower numbers are considered higher priority. Columns that may be omitted in limited space scenarios should be given a priority greater than 0.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is an OpenAPI type definition for this column. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourceconversion-v1-apiextensions-k8s-io">CustomResourceConversion v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceConversion</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceConversion describes how to convert different versions of a CR.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourceconversion-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>strategy</CODE><BR /><I>string</I></TD><TD>strategy specifies how custom resources are converted between versions. Allowed values are: - `None`: The converter only change the apiVersion and would not touch any other field in the custom resource. - `Webhook`: API Server will call to an external webhook to do the conversion. Additional information   is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhook to be set.</TD></TR>
-<TR><TD><CODE>webhook</CODE><BR /><I><a href="#webhookconversion-v1-apiextensions-k8s-io">WebhookConversion</a></I></TD><TD>webhook describes how to call the conversion webhook. Required when `strategy` is set to `Webhook`.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcedefinitioncondition-v1-apiextensions-k8s-io">CustomResourceDefinitionCondition v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceDefinitionCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceDefinitionCondition contains details for the current condition of this pod.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionstatus-v1-apiextensions-k8s-io">CustomResourceDefinitionStatus [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>lastTransitionTime last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>message is a human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>reason is a unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>status is the status of the condition. Can be True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is the type of the condition. Types include Established, NamesAccepted and Terminating.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcedefinitionnames-v1-apiextensions-k8s-io">CustomResourceDefinitionNames v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceDefinitionNames</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceDefinitionNames indicates the names to serve this CustomResourceDefinition</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinitionnames-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1]</a></LI>
-  <LI><a href="#customresourcedefinitionstatus-v1-apiextensions-k8s-io">CustomResourceDefinitionStatus [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>categories</CODE><BR /><I>string array</I></TD><TD>categories is a list of grouped resources this custom resource belongs to (e.g. &#39;all&#39;). This is published in API discovery documents, and used by clients to support invocations like `kubectl get all`.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>kind is the serialized kind of the resource. It is normally CamelCase and singular. Custom resource instances will use this value as the `kind` attribute in API calls.</TD></TR>
-<TR><TD><CODE>listKind</CODE><BR /><I>string</I></TD><TD>listKind is the serialized kind of the list for this resource. Defaults to &#34;`kind`List&#34;.</TD></TR>
-<TR><TD><CODE>plural</CODE><BR /><I>string</I></TD><TD>plural is the plural name of the resource to serve. The custom resources are served under `/apis/&lt;group&gt;/&lt;version&gt;/.../&lt;plural&gt;`. Must match the name of the CustomResourceDefinition (in the form `&lt;names.plural&gt;.&lt;group&gt;`). Must be all lowercase.</TD></TR>
-<TR><TD><CODE>shortNames</CODE><BR /><I>string array</I></TD><TD>shortNames are short names for the resource, exposed in API discovery documents, and used by clients to support invocations like `kubectl get &lt;shortname&gt;`. It must be all lowercase.</TD></TR>
-<TR><TD><CODE>singular</CODE><BR /><I>string</I></TD><TD>singular is the singular name of the resource. It must be all lowercase. Defaults to lowercased `kind`.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcedefinitionversion-v1-apiextensions-k8s-io">CustomResourceDefinitionVersion v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceDefinitionVersion</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceDefinitionVersion describes a version for CRD.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinitionversion-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>additionalPrinterColumns</CODE><BR /><I><a href="#customresourcecolumndefinition-v1-apiextensions-k8s-io">CustomResourceColumnDefinition</a> array</I></TD><TD>additionalPrinterColumns specifies additional columns returned in Table output. See https://kubernetes.io/docs/reference/using-api/api-concepts/#receiving-resources-as-tables for details. If no columns are specified, a single column displaying the age of the custom resource is used.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the version name, e.g. “v1”, “v2beta1”, etc. The custom resources are served under this version at `/apis/&lt;group&gt;/&lt;version&gt;/...` if `served` is true.</TD></TR>
-<TR><TD><CODE>schema</CODE><BR /><I><a href="#customresourcevalidation-v1-apiextensions-k8s-io">CustomResourceValidation</a></I></TD><TD>schema describes the schema used for validation, pruning, and defaulting of this version of the custom resource.</TD></TR>
-<TR><TD><CODE>served</CODE><BR /><I>boolean</I></TD><TD>served is a flag enabling/disabling this version from being served via REST APIs</TD></TR>
-<TR><TD><CODE>storage</CODE><BR /><I>boolean</I></TD><TD>storage indicates this version should be used when persisting custom resources to storage. There must be exactly one version with storage=true.</TD></TR>
-<TR><TD><CODE>subresources</CODE><BR /><I><a href="#customresourcesubresources-v1-apiextensions-k8s-io">CustomResourceSubresources</a></I></TD><TD>subresources specify what subresources this version of the defined custom resource have.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcesubresourcescale-v1-apiextensions-k8s-io">CustomResourceSubresourceScale v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceSubresourceScale</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceSubresourceScale defines how to serve the scale subresource for CustomResources.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcesubresourcescale-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcesubresources-v1-apiextensions-k8s-io">CustomResourceSubresources [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>labelSelectorPath</CODE><BR /><I>string</I></TD><TD>labelSelectorPath defines the JSON path inside of a custom resource that corresponds to Scale `status.selector`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status` or `.spec`. Must be set to work with HorizontalPodAutoscaler. The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form. More info: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource If there is no value under the given path in the custom resource, the `status.selector` value in the `/scale` subresource will default to the empty string.</TD></TR>
-<TR><TD><CODE>specReplicasPath</CODE><BR /><I>string</I></TD><TD>specReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `spec.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.spec`. If there is no value under the given path in the custom resource, the `/scale` subresource will return an error on GET.</TD></TR>
-<TR><TD><CODE>statusReplicasPath</CODE><BR /><I>string</I></TD><TD>statusReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `status.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status`. If there is no value under the given path in the custom resource, the `status.replicas` value in the `/scale` subresource will default to 0.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcesubresourcestatus-v1-apiextensions-k8s-io">CustomResourceSubresourceStatus v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceSubresourceStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceSubresourceStatus defines how to serve the status subresource for CustomResources. Status is represented by the `.status` JSON path inside of a CustomResource. When set, * exposes a /status subresource for the custom resource * PUT requests to the /status subresource take a custom resource object, and ignore changes to anything except the status stanza * PUT/POST/PATCH requests to the custom resource ignore changes to the status stanza</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcesubresources-v1-apiextensions-k8s-io">CustomResourceSubresources [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="customresourcesubresources-v1-apiextensions-k8s-io">CustomResourceSubresources v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceSubresources</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceSubresources defines the status and scale subresources for CustomResources.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcesubresources-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionversion-v1-apiextensions-k8s-io">CustomResourceDefinitionVersion [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>scale</CODE><BR /><I><a href="#customresourcesubresourcescale-v1-apiextensions-k8s-io">CustomResourceSubresourceScale</a></I></TD><TD>scale indicates the custom resource should serve a `/scale` subresource that returns an `autoscaling/v1` Scale object.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#customresourcesubresourcestatus-v1-apiextensions-k8s-io">CustomResourceSubresourceStatus</a></I></TD><TD>status indicates the custom resource should serve a `/status` subresource. When enabled: 1. requests to the custom resource primary endpoint ignore changes to the `status` stanza of the object. 2. requests to the custom resource `/status` subresource ignore changes to anything other than the `status` stanza of the object.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="customresourcevalidation-v1-apiextensions-k8s-io">CustomResourceValidation v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>CustomResourceValidation</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>CustomResourceValidation is a list of validation methods for CustomResources.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcevalidation-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionversion-v1-apiextensions-k8s-io">CustomResourceDefinitionVersion [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>openAPIV3Schema</CODE><BR /><I><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps</a></I></TD><TD>openAPIV3Schema is the OpenAPI v3 schema to use for validation and pruning.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="daemonendpoint-v1-core">DaemonEndpoint v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DaemonEndpoint</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DaemonEndpoint contains information about a single Daemon endpoint.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodedaemonendpoints-v1-core">NodeDaemonEndpoints [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>Port</CODE><BR /><I>integer</I></TD><TD>Port number of the given endpoint.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="daemonsetcondition-v1-apps">DaemonSetCondition v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DaemonSetCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DaemonSetCondition describes the state of a DaemonSet at a certain point.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonsetstatus-v1-apps">DaemonSetStatus [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human readable message indicating details about the transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>The reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of DaemonSet condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="daemonsetupdatestrategy-v1-apps">DaemonSetUpdateStrategy v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DaemonSetUpdateStrategy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DaemonSetUpdateStrategy is a struct used to control the update strategy for a DaemonSet.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#daemonsetspec-v1-apps">DaemonSetSpec [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rollingUpdate</CODE><BR /><I><a href="#rollingupdatedaemonset-v1-apps">RollingUpdateDaemonSet</a></I></TD><TD>Rolling update config params. Present only if type = &#34;RollingUpdate&#34;.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of daemon set update. Can be &#34;RollingUpdate&#34; or &#34;OnDelete&#34;. Default is RollingUpdate.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="deleteoptions-v1-meta">DeleteOptions v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DeleteOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DeleteOptions may be provided when deleting an API object.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#eviction-v1beta1-policy">Eviction [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>dryRun</CODE><BR /><I>string array</I></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE><BR /><I>integer</I></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE><BR /><I>boolean</I></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the &#34;orphan&#34; finalizer will be added to/removed from the object&#39;s finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>preconditions</CODE><BR /><I><a href="#preconditions-v1-meta">Preconditions</a></I></TD><TD>Must be fulfilled before a deletion is carried out. If not possible, a 409 Conflict status will be returned.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE><BR /><I>string</I></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: &#39;Orphan&#39; - orphan the dependents; &#39;Background&#39; - allow the garbage collector to delete the dependents in the background; &#39;Foreground&#39; - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="deploymentcondition-v1-apps">DeploymentCondition v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DeploymentCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DeploymentCondition describes the state of a deployment at a certain point.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deploymentstatus-v1-apps">DeploymentStatus [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>lastUpdateTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>The last time this condition was updated.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human readable message indicating details about the transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>The reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of deployment condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="downwardapiprojection-v1-core">DownwardAPIProjection v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DownwardAPIProjection</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents downward API info for projecting into a projected volume. Note that this is identical to a downwardAPI volume source without the default mode.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeprojection-v1-core">VolumeProjection [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#downwardapivolumefile-v1-core">DownwardAPIVolumeFile</a> array</I></TD><TD>Items is a list of DownwardAPIVolume file</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="downwardapivolumefile-v1-core">DownwardAPIVolumeFile v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DownwardAPIVolumeFile</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DownwardAPIVolumeFile represents information to create the file containing the pod field</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#downwardapiprojection-v1-core">DownwardAPIProjection [core/v1]</a></LI>
-  <LI><a href="#downwardapivolumesource-v1-core">DownwardAPIVolumeSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fieldRef</CODE><BR /><I><a href="#objectfieldselector-v1-core">ObjectFieldSelector</a></I></TD><TD>Required: Selects a field of the pod: only annotations, labels, name and namespace are supported.</TD></TR>
-<TR><TD><CODE>mode</CODE><BR /><I>integer</I></TD><TD>Optional: mode bits to use on this file, must be a value between 0 and 0777. If not specified, the volume defaultMode will be used. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Required: Path is  the relative path name of the file to be created. Must not be absolute or contain the &#39;..&#39; path. Must be utf-8 encoded. The first item of the relative path must not start with &#39;..&#39;</TD></TR>
-<TR><TD><CODE>resourceFieldRef</CODE><BR /><I><a href="#resourcefieldselector-v1-core">ResourceFieldSelector</a></I></TD><TD>Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, requests.cpu and requests.memory) are currently supported.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="downwardapivolumesource-v1-core">DownwardAPIVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>DownwardAPIVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>DownwardAPIVolumeSource represents a volume containing downward API info. Downward API volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>defaultMode</CODE><BR /><I>integer</I></TD><TD>Optional: mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#downwardapivolumefile-v1-core">DownwardAPIVolumeFile</a> array</I></TD><TD>Items is a list of downward API volume file</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="emptydirvolumesource-v1-core">EmptyDirVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EmptyDirVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents an empty directory for a pod. Empty directory volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>medium</CODE><BR /><I>string</I></TD><TD>What type of storage medium should back this directory. The default is &#34;&#34; which means to use the node&#39;s default medium. Must be an empty string (default) or Memory. More info: https://kubernetes.io/docs/concepts/storage/volumes#emptydir</TD></TR>
-<TR><TD><CODE>sizeLimit</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>Total amount of local storage required for this EmptyDir volume. The size limit is also applicable for memory medium. The maximum usage on memory medium EmptyDir would be the minimum value between the SizeLimit specified here and the sum of memory limits of all containers in a pod. The default is nil which means that the limit is undefined. More info: http://kubernetes.io/docs/user-guide/volumes#emptydir</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="endpoint-v1beta1-discovery-k8s-io">Endpoint v1beta1 discovery.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>discovery.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Endpoint</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Endpoint represents a single logical &#34;backend&#34; implementing a service.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice [discovery/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>addresses</CODE><BR /><I>string array</I></TD><TD>addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#endpointconditions-v1beta1-discovery-k8s-io">EndpointConditions</a></I></TD><TD>conditions contains information about the current status of the endpoint.</TD></TR>
-<TR><TD><CODE>hostname</CODE><BR /><I>string</I></TD><TD>hostname of this endpoint. This field may be used by consumers of endpoints to distinguish endpoints from each other (e.g. in DNS names). Multiple endpoints which use the same hostname should be considered fungible (e.g. multiple A values in DNS). Must pass DNS Label (RFC 1123) validation.</TD></TR>
-<TR><TD><CODE>targetRef</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>targetRef is a reference to a Kubernetes object that represents this endpoint.</TD></TR>
-<TR><TD><CODE>topology</CODE><BR /><I>object</I></TD><TD>topology contains arbitrary topology information associated with the endpoint. These key/value pairs must conform with the label format. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels Topology may include a maximum of 16 key/value pairs. This includes, but is not limited to the following well known keys: * kubernetes.io/hostname: the value indicates the hostname of the node   where the endpoint is located. This should match the corresponding   node label. * topology.kubernetes.io/zone: the value indicates the zone where the   endpoint is located. This should match the corresponding node label. * topology.kubernetes.io/region: the value indicates the region where the   endpoint is located. This should match the corresponding node label.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="endpointaddress-v1-core">EndpointAddress v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EndpointAddress</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EndpointAddress is a tuple that describes single IP address.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpointsubset-v1-core">EndpointSubset [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hostname</CODE><BR /><I>string</I></TD><TD>The Hostname of this endpoint</TD></TR>
-<TR><TD><CODE>ip</CODE><BR /><I>string</I></TD><TD>The IP of this endpoint. May not be loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast ((224.0.0.0/24). IPv6 is also accepted but not fully supported on all platforms. Also, certain kubernetes components, like kube-proxy, are not IPv6 ready.</TD></TR>
-<TR><TD><CODE>nodeName</CODE><BR /><I>string</I></TD><TD>Optional: Node hosting this endpoint. This can be used to determine endpoints local to a node.</TD></TR>
-<TR><TD><CODE>targetRef</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>Reference to object providing the endpoint.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="endpointconditions-v1beta1-discovery-k8s-io">EndpointConditions v1beta1 discovery.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>discovery.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>EndpointConditions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EndpointConditions represents the current condition of an endpoint.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpoint-v1beta1-discovery-k8s-io">Endpoint [discovery/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ready</CODE><BR /><I>boolean</I></TD><TD>ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="endpointport-v1-core">EndpointPort v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EndpointPort</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EndpointPort is a tuple that describes a single port.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#endpointport-v1beta1-discovery-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpointsubset-v1-core">EndpointSubset [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>appProtocol</CODE><BR /><I>string</I></TD><TD>The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol. Field can be enabled with ServiceAppProtocol feature gate.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of this port.  This must match the &#39;name&#39; field in the corresponding ServicePort. Must be a DNS_LABEL. Optional only if one port is defined.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>The port number of the endpoint.</TD></TR>
-<TR><TD><CODE>protocol</CODE><BR /><I>string</I></TD><TD>The IP protocol for this port. Must be UDP, TCP, or SCTP. Default is TCP.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="endpointsubset-v1-core">EndpointSubset v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EndpointSubset</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EndpointSubset is a group of addresses with a common set of ports. The expanded set of endpoints is the Cartesian product of Addresses x Ports. For example, given:
-  {
-    Addresses: [{&#34;ip&#34;: &#34;10.10.1.1&#34;}, {&#34;ip&#34;: &#34;10.10.2.2&#34;}],
-    Ports:     [{&#34;name&#34;: &#34;a&#34;, &#34;port&#34;: 8675}, {&#34;name&#34;: &#34;b&#34;, &#34;port&#34;: 309}]
-  }
-The resulting set of endpoints can be viewed as:
-    a: [ 10.10.1.1:8675, 10.10.2.2:8675 ],
-    b: [ 10.10.1.1:309, 10.10.2.2:309 ]</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpoints-v1-core">Endpoints [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>addresses</CODE><BR /><I><a href="#endpointaddress-v1-core">EndpointAddress</a> array</I></TD><TD>IP addresses which offer the related ports that are marked as ready. These endpoints should be considered safe for load balancers and clients to utilize.</TD></TR>
-<TR><TD><CODE>notReadyAddresses</CODE><BR /><I><a href="#endpointaddress-v1-core">EndpointAddress</a> array</I></TD><TD>IP addresses which offer the related ports but are not currently marked as ready because they have not yet finished starting, have recently failed a readiness check, or have recently failed a liveness check.</TD></TR>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#endpointport-v1-core">EndpointPort</a> array</I></TD><TD>Port numbers available on the related IP addresses.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="envfromsource-v1-core">EnvFromSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EnvFromSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EnvFromSource represents the source of a set of ConfigMaps</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
-  <LI><a href="#podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec [settings/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>configMapRef</CODE><BR /><I><a href="#configmapenvsource-v1-core">ConfigMapEnvSource</a></I></TD><TD>The ConfigMap to select from</TD></TR>
-<TR><TD><CODE>prefix</CODE><BR /><I>string</I></TD><TD>An optional identifier to prepend to each key in the ConfigMap. Must be a C_IDENTIFIER.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretenvsource-v1-core">SecretEnvSource</a></I></TD><TD>The Secret to select from</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="envvar-v1-core">EnvVar v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EnvVar</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EnvVar represents an environment variable present in a Container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
-  <LI><a href="#podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec [settings/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the environment variable. Must be a C_IDENTIFIER.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>string</I></TD><TD>Variable references $(VAR_NAME) are expanded using the previous defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to &#34;&#34;.</TD></TR>
-<TR><TD><CODE>valueFrom</CODE><BR /><I><a href="#envvarsource-v1-core">EnvVarSource</a></I></TD><TD>Source for the environment variable&#39;s value. Cannot be used if value is not empty.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="envvarsource-v1-core">EnvVarSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EnvVarSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EnvVarSource represents a source for the value of an EnvVar.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#envvar-v1-core">EnvVar [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>configMapKeyRef</CODE><BR /><I><a href="#configmapkeyselector-v1-core">ConfigMapKeySelector</a></I></TD><TD>Selects a key of a ConfigMap.</TD></TR>
-<TR><TD><CODE>fieldRef</CODE><BR /><I><a href="#objectfieldselector-v1-core">ObjectFieldSelector</a></I></TD><TD>Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.</TD></TR>
-<TR><TD><CODE>resourceFieldRef</CODE><BR /><I><a href="#resourcefieldselector-v1-core">ResourceFieldSelector</a></I></TD><TD>Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.</TD></TR>
-<TR><TD><CODE>secretKeyRef</CODE><BR /><I><a href="#secretkeyselector-v1-core">SecretKeySelector</a></I></TD><TD>Selects a key of a secret in the pod&#39;s namespace</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="ephemeralcontainer-v1-core">EphemeralContainer v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EphemeralContainer</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>An EphemeralContainer is a container that may be added temporarily to an existing pod for user-initiated activities such as debugging. Ephemeral containers have no resource or scheduling guarantees, and they will not be restarted when they exit or when a pod is removed or restarted. If an ephemeral container causes a pod to exceed its resource allocation, the pod may be evicted. Ephemeral containers may not be added by directly updating the pod spec. They must be added via the pod&#39;s ephemeralcontainers subresource, and they will appear in the pod spec once added. This is an alpha feature enabled by the EphemeralContainers feature flag.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>args</CODE><BR /><I>string array</I></TD><TD>Arguments to the entrypoint. The docker image&#39;s CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container&#39;s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell</TD></TR>
-<TR><TD><CODE>command</CODE><BR /><I>string array</I></TD><TD>Entrypoint array. Not executed within a shell. The docker image&#39;s ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container&#39;s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell</TD></TR>
-<TR><TD><CODE>env</CODE><BR /><I><a href="#envvar-v1-core">EnvVar</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>List of environment variables to set in the container. Cannot be updated.</TD></TR>
-<TR><TD><CODE>envFrom</CODE><BR /><I><a href="#envfromsource-v1-core">EnvFromSource</a> array</I></TD><TD>List of sources to populate environment variables in the container. The keys defined within a source must be a C_IDENTIFIER. All invalid keys will be reported as an event when the container is starting. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated.</TD></TR>
-<TR><TD><CODE>image</CODE><BR /><I>string</I></TD><TD>Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images</TD></TR>
-<TR><TD><CODE>imagePullPolicy</CODE><BR /><I>string</I></TD><TD>Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images</TD></TR>
-<TR><TD><CODE>lifecycle</CODE><BR /><I><a href="#lifecycle-v1-core">Lifecycle</a></I></TD><TD>Lifecycle is not allowed for ephemeral containers.</TD></TR>
-<TR><TD><CODE>livenessProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>Probes are not allowed for ephemeral containers.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the ephemeral container specified as a DNS_LABEL. This name must be unique among all containers, init containers and ephemeral containers.</TD></TR>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#containerport-v1-core">ContainerPort</a> array</I></TD><TD>Ports are not allowed for ephemeral containers.</TD></TR>
-<TR><TD><CODE>readinessProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>Probes are not allowed for ephemeral containers.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I><a href="#resourcerequirements-v1-core">ResourceRequirements</a></I></TD><TD>Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod.</TD></TR>
-<TR><TD><CODE>securityContext</CODE><BR /><I><a href="#securitycontext-v1-core">SecurityContext</a></I></TD><TD>SecurityContext is not allowed for ephemeral containers.</TD></TR>
-<TR><TD><CODE>startupProbe</CODE><BR /><I><a href="#probe-v1-core">Probe</a></I></TD><TD>Probes are not allowed for ephemeral containers.</TD></TR>
-<TR><TD><CODE>stdin</CODE><BR /><I>boolean</I></TD><TD>Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false.</TD></TR>
-<TR><TD><CODE>stdinOnce</CODE><BR /><I>boolean</I></TD><TD>Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false</TD></TR>
-<TR><TD><CODE>targetContainerName</CODE><BR /><I>string</I></TD><TD>If set, the name of the container from PodSpec that this ephemeral container targets. The ephemeral container will be run in the namespaces (IPC, PID, etc) of this container. If not set then the ephemeral container is run in whatever namespaces are shared for the pod. Note that the container runtime must support this feature.</TD></TR>
-<TR><TD><CODE>terminationMessagePath</CODE><BR /><I>string</I></TD><TD>Optional: Path at which the file to which the container&#39;s termination message will be written is mounted into the container&#39;s filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated.</TD></TR>
-<TR><TD><CODE>terminationMessagePolicy</CODE><BR /><I>string</I></TD><TD>Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated.</TD></TR>
-<TR><TD><CODE>tty</CODE><BR /><I>boolean</I></TD><TD>Whether this container should allocate a TTY for itself, also requires &#39;stdin&#39; to be true. Default is false.</TD></TR>
-<TR><TD><CODE>volumeDevices</CODE><BR /><I><a href="#volumedevice-v1-core">VolumeDevice</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>devicePath</I></TD><TD>volumeDevices is the list of block devices to be used by the container.</TD></TR>
-<TR><TD><CODE>volumeMounts</CODE><BR /><I><a href="#volumemount-v1-core">VolumeMount</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>mountPath</I></TD><TD>Pod volumes to mount into the container&#39;s filesystem. Cannot be updated.</TD></TR>
-<TR><TD><CODE>workingDir</CODE><BR /><I>string</I></TD><TD>Container&#39;s working directory. If not specified, the container runtime&#39;s default will be used, which might be configured in the container image. Cannot be updated.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="eventseries-v1-core">EventSeries v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EventSeries</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EventSeries contain information on series of events, i.e. thing that was/is happening continuously for some time.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#eventseries-v1beta1-events-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#event-v1-core">Event [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>count</CODE><BR /><I>integer</I></TD><TD>Number of occurrences in this series up to the last heartbeat time</TD></TR>
-<TR><TD><CODE>lastObservedTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>Time of the last occurrence observed</TD></TR>
-<TR><TD><CODE>state</CODE><BR /><I>string</I></TD><TD>State of this Series: Ongoing or Finished Deprecated. Planned removal for 1.18</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="eventsource-v1-core">EventSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>EventSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>EventSource contains information for an event.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#event-v1-core">Event [core/v1]</a></LI>
-  <LI><a href="#event-v1beta1-events-k8s-io">Event [events/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>component</CODE><BR /><I>string</I></TD><TD>Component from which the event is generated.</TD></TR>
-<TR><TD><CODE>host</CODE><BR /><I>string</I></TD><TD>Node name on which the event is generated.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="eviction-v1beta1-policy">Eviction v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Eviction</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Eviction evicts a pod from its node subject to certain policies and safety constraints. This is a subresource of Pod.  A request to cause such an eviction is created by POSTing to .../pods/&lt;pod name&gt;/evictions.</P>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>deleteOptions</CODE><BR /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD>DeleteOptions may be provided</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>ObjectMeta describes the pod that is being evicted.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="execaction-v1-core">ExecAction v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ExecAction</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ExecAction describes a &#34;run in container&#34; action.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#handler-v1-core">Handler [core/v1]</a></LI>
-  <LI><a href="#probe-v1-core">Probe [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>command</CODE><BR /><I>string array</I></TD><TD>Command is the command line to execute inside the container, the working directory for the command  is root (&#39;/&#39;) in the container&#39;s filesystem. The command is simply exec&#39;d, it is not run inside a shell, so traditional shell instructions (&#39;|&#39;, etc) won&#39;t work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="externaldocumentation-v1-apiextensions-k8s-io">ExternalDocumentation v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ExternalDocumentation</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ExternalDocumentation allows referencing an external resource for extended documentation.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#externaldocumentation-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="externalmetricsource-v2beta2-autoscaling">ExternalMetricSource v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>ExternalMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ExternalMetricSource indicates how to scale on a metric not associated with any Kubernetes object (for example length of queue in cloud messaging service, or QPS from loadbalancer running outside of cluster).</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#externalmetricsource-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta2-autoscaling">MetricSpec [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metric</CODE><BR /><I><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier</a></I></TD><TD>metric identifies the target metric by name and selector</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#metrictarget-v2beta2-autoscaling">MetricTarget</a></I></TD><TD>target specifies the target value for the given metric</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="externalmetricstatus-v2beta2-autoscaling">ExternalMetricStatus v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>ExternalMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ExternalMetricStatus indicates the current value of a global metric not associated with any Kubernetes object.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#externalmetricstatus-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta2-autoscaling">MetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>current</CODE><BR /><I><a href="#metricvaluestatus-v2beta2-autoscaling">MetricValueStatus</a></I></TD><TD>current contains the current value for the given metric</TD></TR>
-<TR><TD><CODE>metric</CODE><BR /><I><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier</a></I></TD><TD>metric identifies the target metric by name and selector</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="fcvolumesource-v1-core">FCVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>FCVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Fibre Channel volume. Fibre Channel volumes can only be mounted as read/write once. Fibre Channel volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>lun</CODE><BR /><I>integer</I></TD><TD>Optional: FC target lun number</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>targetWWNs</CODE><BR /><I>string array</I></TD><TD>Optional: FC target worldwide names (WWNs)</TD></TR>
-<TR><TD><CODE>wwids</CODE><BR /><I>string array</I></TD><TD>Optional: FC volume world wide identifiers (wwids) Either wwids or combination of targetWWNs and lun must be set, but not both simultaneously.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="fsgroupstrategyoptions-v1beta1-policy">FSGroupStrategyOptions v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>FSGroupStrategyOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>FSGroupStrategyOptions defines the strategy type and options used to create the strategy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ranges</CODE><BR /><I><a href="#idrange-v1beta1-policy">IDRange</a> array</I></TD><TD>ranges are the allowed ranges of fs groups.  If you would like to force a single fs group then supply a single range with the same start and end. Required for MustRunAs.</TD></TR>
-<TR><TD><CODE>rule</CODE><BR /><I>string</I></TD><TD>rule is the strategy that will dictate what FSGroup is used in the SecurityContext.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="fieldsv1-v1-meta">FieldsV1 v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>FieldsV1</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>FieldsV1 stores a set of fields in a data structure like a Trie, in JSON format.
-
-Each key is either a &#39;.&#39; representing the field itself, and will always map to an empty set, or a string representing a sub-field or item. The string will follow one of these four formats: &#39;f:&lt;name&gt;&#39;, where &lt;name&gt; is the name of a field in a struct, or key in a map &#39;v:&lt;value&gt;&#39;, where &lt;value&gt; is the exact json formatted value of a list item &#39;i:&lt;index&gt;&#39;, where &lt;index&gt; is position of a item in a list &#39;k:&lt;keys&gt;&#39;, where &lt;keys&gt; is a map of  a list item&#39;s key fields to their unique values If a key maps to an empty Fields value, the field that key represents is part of the set.
-
-The exact format is defined in sigs.k8s.io/structured-merge-diff</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#managedfieldsentry-v1-meta">ManagedFieldsEntry [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="flexpersistentvolumesource-v1-core">FlexPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>FlexPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>FlexPersistentVolumeSource represents a generic persistent volume resource that is provisioned/attached using an exec based plugin.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>driver</CODE><BR /><I>string</I></TD><TD>Driver is the name of the driver to use for this volume.</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. The default filesystem depends on FlexVolume script.</TD></TR>
-<TR><TD><CODE>options</CODE><BR /><I>object</I></TD><TD>Optional: Extra command options if any.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>Optional: SecretRef is reference to the secret object containing sensitive information to pass to the plugin scripts. This may be empty if no secret object is specified. If the secret object contains more than one secret, all secrets are passed to the plugin scripts.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="flexvolumesource-v1-core">FlexVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>FlexVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>driver</CODE><BR /><I>string</I></TD><TD>Driver is the name of the driver to use for this volume.</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. The default filesystem depends on FlexVolume script.</TD></TR>
-<TR><TD><CODE>options</CODE><BR /><I>object</I></TD><TD>Optional: Extra command options if any.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Optional: Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>Optional: SecretRef is reference to the secret object containing sensitive information to pass to the plugin scripts. This may be empty if no secret object is specified. If the secret object contains more than one secret, all secrets are passed to the plugin scripts.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="flockervolumesource-v1-core">FlockerVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>FlockerVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Flocker volume mounted by the Flocker agent. One and only one of datasetName and datasetUUID should be set. Flocker volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>datasetName</CODE><BR /><I>string</I></TD><TD>Name of the dataset stored as metadata -&gt; name on the dataset for Flocker should be considered as deprecated</TD></TR>
-<TR><TD><CODE>datasetUUID</CODE><BR /><I>string</I></TD><TD>UUID of the dataset. This is unique identifier of a Flocker dataset</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io">FlowDistinguisherMethod v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>FlowDistinguisherMethod</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>FlowDistinguisherMethod specifies the method of a flow distinguisher.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschemaspec-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaSpec [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>`type` is the type of flow distinguisher method The supported types are &#34;ByUser&#34; and &#34;ByNamespace&#34;. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaCondition v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>FlowSchemaCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>FlowSchemaCondition describes conditions for a FlowSchema.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschemastatus-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaStatus [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>`lastTransitionTime` is the last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>`message` is a human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>`reason` is a unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>`status` is the status of the condition. Can be True, False, Unknown. Required.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>`type` is the type of the condition. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="gcepersistentdiskvolumesource-v1-core">GCEPersistentDiskVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>GCEPersistentDiskVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Persistent Disk resource in Google Compute Engine.
-
-A GCE PD must exist before mounting to a container. The disk must also be in the same GCE project and zone as the kubelet. A GCE PD can only be mounted as read/write once or read-only many times. GCE PDs support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk</TD></TR>
-<TR><TD><CODE>partition</CODE><BR /><I>integer</I></TD><TD>The partition in the volume that you want to mount. If omitted, the default is to mount by volume name. Examples: For volume /dev/sda1, you specify the partition as &#34;1&#34;. Similarly, the volume partition for /dev/sda is &#34;0&#34; (or you can leave the property empty). More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk</TD></TR>
-<TR><TD><CODE>pdName</CODE><BR /><I>string</I></TD><TD>Unique name of the PD resource in GCE. Used to identify the disk in GCE. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="gitrepovolumesource-v1-core">GitRepoVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>GitRepoVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a volume that is populated with the contents of a git repository. Git repo volumes do not support ownership management. Git repo volumes support SELinux relabeling.
-
-DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mount an EmptyDir into an InitContainer that clones the repo using git, then mount the EmptyDir into the Pod&#39;s container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>directory</CODE><BR /><I>string</I></TD><TD>Target directory name. Must not contain or start with &#39;..&#39;.  If &#39;.&#39; is supplied, the volume directory will be the git repository.  Otherwise, if specified, the volume will contain the git repository in the subdirectory with the given name.</TD></TR>
-<TR><TD><CODE>repository</CODE><BR /><I>string</I></TD><TD>Repository URL</TD></TR>
-<TR><TD><CODE>revision</CODE><BR /><I>string</I></TD><TD>Commit hash for the specified revision.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="glusterfspersistentvolumesource-v1-core">GlusterfsPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>GlusterfsPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Glusterfs mount that lasts the lifetime of a pod. Glusterfs volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>endpoints</CODE><BR /><I>string</I></TD><TD>EndpointsName is the endpoint name that details Glusterfs topology. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-<TR><TD><CODE>endpointsNamespace</CODE><BR /><I>string</I></TD><TD>EndpointsNamespace is the namespace that contains Glusterfs endpoint. If this field is empty, the EndpointNamespace defaults to the same namespace as the bound PVC. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is the Glusterfs volume path. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the Glusterfs volume to be mounted with read-only permissions. Defaults to false. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="glusterfsvolumesource-v1-core">GlusterfsVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>GlusterfsVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Glusterfs mount that lasts the lifetime of a pod. Glusterfs volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>endpoints</CODE><BR /><I>string</I></TD><TD>EndpointsName is the endpoint name that details Glusterfs topology. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is the Glusterfs volume path. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the Glusterfs volume to be mounted with read-only permissions. Defaults to false. More info: https://examples.k8s.io/volumes/glusterfs/README.md#create-a-pod</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io">GroupSubject v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>GroupSubject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>GroupSubject holds detailed information for group-kind subject.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io">Subject [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the user group that matches, or &#34;*&#34; to match all user groups. See https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/user/user.go for some well-known group names. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="groupversionfordiscovery-v1-meta">GroupVersionForDiscovery v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>GroupVersionForDiscovery</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>GroupVersion contains the &#34;group/version&#34; and &#34;version&#34; string of a version. It is made a struct to keep extensibility.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apigroup-v1-meta">APIGroup [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>groupVersion</CODE><BR /><I>string</I></TD><TD>groupVersion specifies the API group and version in the form &#34;group/version&#34;</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>version specifies the version in the form of &#34;version&#34;. This is to save the clients the trouble of splitting the GroupVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="hpascalingpolicy-v2beta2-autoscaling">HPAScalingPolicy v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>HPAScalingPolicy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HPAScalingPolicy is a single policy which must hold true for a specified past interval.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#hpascalingrules-v2beta2-autoscaling">HPAScalingRules [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>periodSeconds</CODE><BR /><I>integer</I></TD><TD>PeriodSeconds specifies the window of time for which the policy should hold true. PeriodSeconds must be greater than zero and less than or equal to 1800 (30 min).</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type is used to specify the scaling policy.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>integer</I></TD><TD>Value contains the amount of change which is permitted by the policy. It must be greater than zero</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="hpascalingrules-v2beta2-autoscaling">HPAScalingRules v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>HPAScalingRules</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HPAScalingRules configures the scaling behavior for one direction. These Rules are applied after calculating DesiredReplicas from metrics for the HPA. They can limit the scaling velocity by specifying scaling policies. They can prevent flapping by specifying the stabilization window, so that the number of replicas is not set instantly, instead, the safest value from the stabilization window is chosen.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerbehavior-v2beta2-autoscaling">HorizontalPodAutoscalerBehavior [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policies</CODE><BR /><I><a href="#hpascalingpolicy-v2beta2-autoscaling">HPAScalingPolicy</a> array</I></TD><TD>policies is a list of potential scaling polices which can be used during scaling. At least one policy must be specified, otherwise the HPAScalingRules will be discarded as invalid</TD></TR>
-<TR><TD><CODE>selectPolicy</CODE><BR /><I>string</I></TD><TD>selectPolicy is used to specify which policy should be used. If not set, the default value MaxPolicySelect is used.</TD></TR>
-<TR><TD><CODE>stabilizationWindowSeconds</CODE><BR /><I>integer</I></TD><TD>StabilizationWindowSeconds is the number of seconds for which past recommendations should be considered while scaling up or scaling down. StabilizationWindowSeconds must be greater than or equal to zero and less than or equal to 3600 (one hour). If not set, use the default values: - For scale up: 0 (i.e. no stabilization is done). - For scale down: 300 (i.e. the stabilization window is 300 seconds long).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="httpgetaction-v1-core">HTTPGetAction v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>HTTPGetAction</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HTTPGetAction describes an action based on HTTP Get requests.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#handler-v1-core">Handler [core/v1]</a></LI>
-  <LI><a href="#probe-v1-core">Probe [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>host</CODE><BR /><I>string</I></TD><TD>Host name to connect to, defaults to the pod IP. You probably want to set &#34;Host&#34; in httpHeaders instead.</TD></TR>
-<TR><TD><CODE>httpHeaders</CODE><BR /><I><a href="#httpheader-v1-core">HTTPHeader</a> array</I></TD><TD>Custom headers to set in the request. HTTP allows repeated headers.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path to access on the HTTP server.</TD></TR>
-<TR><TD><CODE>port</CODE></TD><TD>Name or number of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.</TD></TR>
-<TR><TD><CODE>scheme</CODE><BR /><I>string</I></TD><TD>Scheme to use for connecting to the host. Defaults to HTTP.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="httpheader-v1-core">HTTPHeader v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>HTTPHeader</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HTTPHeader describes a custom header to be used in HTTP probes</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#httpgetaction-v1-core">HTTPGetAction [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The header field name</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>string</I></TD><TD>The header field value</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="httpingresspath-v1beta1-networking-k8s-io">HTTPIngressPath v1beta1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>HTTPIngressPath</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HTTPIngressPath associates a path with a backend. Incoming urls matching the path are forwarded to the backend.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#httpingressrulevalue-v1beta1-networking-k8s-io">HTTPIngressRuleValue [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>backend</CODE><BR /><I><a href="#ingressbackend-v1beta1-networking-k8s-io">IngressBackend</a></I></TD><TD>Backend defines the referenced service endpoint to which the traffic will be forwarded to.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional &#34;path&#34; part of a URL as defined by RFC 3986. Paths must begin with a &#39;/&#39;. When unspecified, all paths from incoming requests are matched.</TD></TR>
-<TR><TD><CODE>pathType</CODE><BR /><I>string</I></TD><TD>PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by &#39;/&#39;. Matching is   done on a path element by element basis. A path element refers is the   list of labels in the path split by the &#39;/&#39; separator. A request is a   match for path p if every p is an element-wise prefix of p of the   request path. Note that if the last element of the path is a substring   of the last element in request path, it is not a match (e.g. /foo/bar   matches /foo/bar/baz, but does not match /foo/barbaz). * ImplementationSpecific: Interpretation of the Path matching is up to   the IngressClass. Implementations can treat this as a separate PathType   or treat it identically to Prefix or Exact path types. Implementations are required to support all path types. Defaults to ImplementationSpecific.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="httpingressrulevalue-v1beta1-networking-k8s-io">HTTPIngressRuleValue v1beta1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>HTTPIngressRuleValue</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HTTPIngressRuleValue is a list of http selectors pointing to backends. In the example: http://&lt;host&gt;/&lt;path&gt;?&lt;searchpart&gt; -&gt; backend where where parts of the url correspond to RFC 3986, this resource will be used to match against everything after the last &#39;/&#39; and before the first &#39;?&#39; or &#39;#&#39;.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressrule-v1beta1-networking-k8s-io">IngressRule [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>paths</CODE><BR /><I><a href="#httpingresspath-v1beta1-networking-k8s-io">HTTPIngressPath</a> array</I></TD><TD>A collection of paths that map requests to backends.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="handler-v1-core">Handler v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Handler</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Handler defines a specific action that should be taken</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#lifecycle-v1-core">Lifecycle [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>exec</CODE><BR /><I><a href="#execaction-v1-core">ExecAction</a></I></TD><TD>One and only one of the following should be specified. Exec specifies the action to take.</TD></TR>
-<TR><TD><CODE>httpGet</CODE><BR /><I><a href="#httpgetaction-v1-core">HTTPGetAction</a></I></TD><TD>HTTPGet specifies the http request to perform.</TD></TR>
-<TR><TD><CODE>tcpSocket</CODE><BR /><I><a href="#tcpsocketaction-v1-core">TCPSocketAction</a></I></TD><TD>TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="horizontalpodautoscalerbehavior-v2beta2-autoscaling">HorizontalPodAutoscalerBehavior v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>HorizontalPodAutoscalerBehavior</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HorizontalPodAutoscalerBehavior configures the scaling behavior of the target in both Up and Down directions (scaleUp and scaleDown fields respectively).</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerspec-v2beta2-autoscaling">HorizontalPodAutoscalerSpec [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>scaleDown</CODE><BR /><I><a href="#hpascalingrules-v2beta2-autoscaling">HPAScalingRules</a></I></TD><TD>scaleDown is scaling policy for scaling Down. If not set, the default value is to allow to scale down to minReplicas pods, with a 300 second stabilization window (i.e., the highest recommendation for the last 300sec is used).</TD></TR>
-<TR><TD><CODE>scaleUp</CODE><BR /><I><a href="#hpascalingrules-v2beta2-autoscaling">HPAScalingRules</a></I></TD><TD>scaleUp is scaling policy for scaling Up. If not set, the default value is the higher of:   * increase no more than 4 pods per 60 seconds   * double the number of pods per 60 seconds No stabilization is used.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="horizontalpodautoscalercondition-v2beta2-autoscaling">HorizontalPodAutoscalerCondition v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>HorizontalPodAutoscalerCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HorizontalPodAutoscalerCondition describes the state of a HorizontalPodAutoscaler at a certain point.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#horizontalpodautoscalercondition-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerstatus-v2beta2-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>lastTransitionTime is the last time the condition transitioned from one status to another</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>message is a human-readable explanation containing details about the transition</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>reason is the reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>status is the status of the condition (True, False, Unknown)</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type describes the current condition</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="hostalias-v1-core">HostAlias v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>HostAlias</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HostAlias holds the mapping between IP and hostnames that will be injected as an entry in the pod&#39;s hosts file.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hostnames</CODE><BR /><I>string array</I></TD><TD>Hostnames for the above IP address.</TD></TR>
-<TR><TD><CODE>ip</CODE><BR /><I>string</I></TD><TD>IP address of the host file entry.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="hostpathvolumesource-v1-core">HostPathVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>HostPathVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a host path mapped into a pod. Host path volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path of the directory on the host. If the path is a symlink, it will follow the link to the real path. More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type for HostPath Volume Defaults to &#34;&#34; More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="hostportrange-v1beta1-policy">HostPortRange v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>HostPortRange</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>HostPortRange defines a range of host ports that will be enabled by a policy for pods to use.  It requires both the start and end to be defined.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>max</CODE><BR /><I>integer</I></TD><TD>max is the end of the range, inclusive.</TD></TR>
-<TR><TD><CODE>min</CODE><BR /><I>integer</I></TD><TD>min is the start of the range, inclusive.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="idrange-v1beta1-policy">IDRange v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IDRange</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>IDRange provides a min/max of an allowed range of IDs.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#fsgroupstrategyoptions-v1beta1-policy">FSGroupStrategyOptions [policy/v1beta1]</a></LI>
-  <LI><a href="#runasgroupstrategyoptions-v1beta1-policy">RunAsGroupStrategyOptions [policy/v1beta1]</a></LI>
-  <LI><a href="#runasuserstrategyoptions-v1beta1-policy">RunAsUserStrategyOptions [policy/v1beta1]</a></LI>
-  <LI><a href="#supplementalgroupsstrategyoptions-v1beta1-policy">SupplementalGroupsStrategyOptions [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>max</CODE><BR /><I>integer</I></TD><TD>max is the end of the range, inclusive.</TD></TR>
-<TR><TD><CODE>min</CODE><BR /><I>integer</I></TD><TD>min is the start of the range, inclusive.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="ipblock-v1-networking-k8s-io">IPBlock v1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>IPBlock</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>IPBlock describes a particular CIDR (Ex. &#34;192.168.1.1/24&#34;,&#34;2001:db9::/64&#34;) that is allowed to the pods matched by a NetworkPolicySpec&#39;s podSelector. The except entry describes CIDRs that should not be included within this rule.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicypeer-v1-networking-k8s-io">NetworkPolicyPeer [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>cidr</CODE><BR /><I>string</I></TD><TD>CIDR is a string representing the IP Block Valid examples are &#34;192.168.1.1/24&#34; or &#34;2001:db9::/64&#34;</TD></TR>
-<TR><TD><CODE>except</CODE><BR /><I>string array</I></TD><TD>Except is a slice of CIDRs that should not be included within an IP Block Valid examples are &#34;192.168.1.1/24&#34; or &#34;2001:db9::/64&#34; Except values will be rejected if they are outside the CIDR range</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="iscsipersistentvolumesource-v1-core">ISCSIPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ISCSIPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ISCSIPersistentVolumeSource represents an ISCSI disk. ISCSI volumes can only be mounted as read/write once. ISCSI volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>chapAuthDiscovery</CODE><BR /><I>boolean</I></TD><TD>whether support iSCSI Discovery CHAP authentication</TD></TR>
-<TR><TD><CODE>chapAuthSession</CODE><BR /><I>boolean</I></TD><TD>whether support iSCSI Session CHAP authentication</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#iscsi</TD></TR>
-<TR><TD><CODE>initiatorName</CODE><BR /><I>string</I></TD><TD>Custom iSCSI Initiator Name. If initiatorName is specified with iscsiInterface simultaneously, new iSCSI interface &lt;target portal&gt;:&lt;volume name&gt; will be created for the connection.</TD></TR>
-<TR><TD><CODE>iqn</CODE><BR /><I>string</I></TD><TD>Target iSCSI Qualified Name.</TD></TR>
-<TR><TD><CODE>iscsiInterface</CODE><BR /><I>string</I></TD><TD>iSCSI Interface Name that uses an iSCSI transport. Defaults to &#39;default&#39; (tcp).</TD></TR>
-<TR><TD><CODE>lun</CODE><BR /><I>integer</I></TD><TD>iSCSI Target Lun number.</TD></TR>
-<TR><TD><CODE>portals</CODE><BR /><I>string array</I></TD><TD>iSCSI Target Portal List. The Portal is either an IP or ip_addr:port if the port is other than default (typically TCP ports 860 and 3260).</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>CHAP Secret for iSCSI target and initiator authentication</TD></TR>
-<TR><TD><CODE>targetPortal</CODE><BR /><I>string</I></TD><TD>iSCSI Target Portal. The Portal is either an IP or ip_addr:port if the port is other than default (typically TCP ports 860 and 3260).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="iscsivolumesource-v1-core">ISCSIVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ISCSIVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents an ISCSI disk. ISCSI volumes can only be mounted as read/write once. ISCSI volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>chapAuthDiscovery</CODE><BR /><I>boolean</I></TD><TD>whether support iSCSI Discovery CHAP authentication</TD></TR>
-<TR><TD><CODE>chapAuthSession</CODE><BR /><I>boolean</I></TD><TD>whether support iSCSI Session CHAP authentication</TD></TR>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#iscsi</TD></TR>
-<TR><TD><CODE>initiatorName</CODE><BR /><I>string</I></TD><TD>Custom iSCSI Initiator Name. If initiatorName is specified with iscsiInterface simultaneously, new iSCSI interface &lt;target portal&gt;:&lt;volume name&gt; will be created for the connection.</TD></TR>
-<TR><TD><CODE>iqn</CODE><BR /><I>string</I></TD><TD>Target iSCSI Qualified Name.</TD></TR>
-<TR><TD><CODE>iscsiInterface</CODE><BR /><I>string</I></TD><TD>iSCSI Interface Name that uses an iSCSI transport. Defaults to &#39;default&#39; (tcp).</TD></TR>
-<TR><TD><CODE>lun</CODE><BR /><I>integer</I></TD><TD>iSCSI Target Lun number.</TD></TR>
-<TR><TD><CODE>portals</CODE><BR /><I>string array</I></TD><TD>iSCSI Target Portal List. The portal is either an IP or ip_addr:port if the port is other than default (typically TCP ports 860 and 3260).</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>CHAP Secret for iSCSI target and initiator authentication</TD></TR>
-<TR><TD><CODE>targetPortal</CODE><BR /><I>string</I></TD><TD>iSCSI Target Portal. The Portal is either an IP or ip_addr:port if the port is other than default (typically TCP ports 860 and 3260).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="ingressbackend-v1beta1-networking-k8s-io">IngressBackend v1beta1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressBackend</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>IngressBackend describes all endpoints for a given service and port.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#httpingresspath-v1beta1-networking-k8s-io">HTTPIngressPath [networking/v1beta1]</a></LI>
-  <LI><a href="#ingressspec-v1beta1-networking-k8s-io">IngressSpec [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>resource</CODE><BR /><I><a href="#typedlocalobjectreference-v1-core">TypedLocalObjectReference</a></I></TD><TD>Resource is an ObjectRef to another Kubernetes resource in the namespace of the Ingress object. If resource is specified, serviceName and servicePort must not be specified.</TD></TR>
-<TR><TD><CODE>serviceName</CODE><BR /><I>string</I></TD><TD>Specifies the name of the referenced service.</TD></TR>
-<TR><TD><CODE>servicePort</CODE></TD><TD>Specifies the port of the referenced service.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="ingressrule-v1beta1-networking-k8s-io">IngressRule v1beta1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>IngressRule represents the rules mapping the paths under a specified host to the related backend services. Incoming requests are first evaluated for a host match, then routed to the backend associated with the matching IngressRuleValue.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressspec-v1beta1-networking-k8s-io">IngressSpec [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>host</CODE><BR /><I>string</I></TD><TD>Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the &#34;host&#34; part of the URI as defined in RFC 3986: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to    the IP in the Spec of the parent Ingress. 2. The `:` delimiter is not respected because ports are not allowed. 	  Currently the port of an Ingress is implicitly :80 for http and 	  :443 for https. Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.  Host can be &#34;precise&#34; which is a domain name without the terminating dot of a network host (e.g. &#34;foo.bar.com&#34;) or &#34;wildcard&#34;, which is a domain name prefixed with a single wildcard label (e.g. &#34;*.foo.com&#34;). The wildcard character &#39;\*&#39; must appear by itself as the first DNS label and matches only a single label. You cannot have a wildcard label by itself (e.g. Host == &#34;*&#34;). Requests will be matched against the Host field in the following way: 1. If Host is precise, the request matches this rule if the http host header is equal to Host. 2. If Host is a wildcard, then the request matches this rule if the http host header is to equal to the suffix (removing the first label) of the wildcard rule.</TD></TR>
-<TR><TD><CODE>http</CODE><BR /><I><a href="#httpingressrulevalue-v1beta1-networking-k8s-io">HTTPIngressRuleValue</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="ingresstls-v1beta1-networking-k8s-io">IngressTLS v1beta1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressTLS</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>IngressTLS describes the transport layer security associated with an Ingress.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressspec-v1beta1-networking-k8s-io">IngressSpec [networking/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hosts</CODE><BR /><I>string array</I></TD><TD>Hosts are a list of hosts included in the TLS certificate. The values in this list must match the name/s used in the tlsSecret. Defaults to the wildcard host setting for the loadbalancer controller fulfilling this Ingress, if left unspecified.</TD></TR>
-<TR><TD><CODE>secretName</CODE><BR /><I>string</I></TD><TD>SecretName is the name of the secret used to terminate TLS traffic on port 443. Field is left optional to allow TLS routing based on SNI hostname alone. If the SNI host in a listener conflicts with the &#34;Host&#34; header field used by an IngressRule, the SNI host is used for termination and value of the Host header is used for routing.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="json-v1-apiextensions-k8s-io">JSON v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>JSON</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#json-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>JSONSchemaProps</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>JSONSchemaProps is a JSON-Schema following Specification Draft 4 (http://json-schema.org/).</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcevalidation-v1-apiextensions-k8s-io">CustomResourceValidation [apiextensions/v1]</a></LI>
-  <LI><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>$ref</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>$schema</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>additionalItems</CODE><BR /><I><a href="#jsonschemapropsorbool-v1-apiextensions-k8s-io">JSONSchemaPropsOrBool</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>additionalProperties</CODE><BR /><I><a href="#jsonschemapropsorbool-v1-apiextensions-k8s-io">JSONSchemaPropsOrBool</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>allOf</CODE><BR /><I><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>anyOf</CODE><BR /><I><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>default</CODE><BR /><I><a href="#json-v1-apiextensions-k8s-io">JSON</a></I></TD><TD>default is a default value for undefined object fields. Defaulting is a beta feature under the CustomResourceDefaulting feature gate. Defaulting requires spec.preserveUnknownFields to be false.</TD></TR>
-<TR><TD><CODE>definitions</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>dependencies</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>enum</CODE><BR /><I><a href="#json-v1-apiextensions-k8s-io">JSON</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>example</CODE><BR /><I><a href="#json-v1-apiextensions-k8s-io">JSON</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>exclusiveMaximum</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>exclusiveMinimum</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>externalDocs</CODE><BR /><I><a href="#externaldocumentation-v1-apiextensions-k8s-io">ExternalDocumentation</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>format</CODE><BR /><I>string</I></TD><TD>format is an OpenAPI v3 format string. Unknown formats are ignored. The following formats are validated:  - bsonobjectid: a bson object ID, i.e. a 24 characters hex string - uri: an URI as parsed by Golang net/url.ParseRequestURI - email: an email address as parsed by Golang net/mail.ParseAddress - hostname: a valid representation for an Internet host name, as defined by RFC 1034, section 3.1 [RFC1034]. - ipv4: an IPv4 IP as parsed by Golang net.ParseIP - ipv6: an IPv6 IP as parsed by Golang net.ParseIP - cidr: a CIDR as parsed by Golang net.ParseCIDR - mac: a MAC address as parsed by Golang net.ParseMAC - uuid: an UUID that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid3: an UUID3 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid4: an UUID4 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - uuid5: an UUID5 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - isbn: an ISBN10 or ISBN13 number string like &#34;0321751043&#34; or &#34;978-0321751041&#34; - isbn10: an ISBN10 number string like &#34;0321751043&#34; - isbn13: an ISBN13 number string like &#34;978-0321751041&#34; - creditcard: a credit card number defined by the regex ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$ with any non digit characters mixed in - ssn: a U.S. social security number following the regex ^\d{3}[- ]?\d{2}[- ]?\d{4}$ - hexcolor: an hexadecimal color code like &#34;#FFFFFF: following the regex ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$ - rgbcolor: an RGB color code like rgb like &#34;rgb(255,255,2559&#34; - byte: base64 encoded binary data - password: any kind of string - date: a date string like &#34;2006-01-02&#34; as defined by full-date in RFC3339 - duration: a duration string like &#34;22 ns&#34; as parsed by Golang time.ParseDuration or compatible with Scala duration format - datetime: a date time string like &#34;2014-12-15T19:30:20.000Z&#34; as defined by date-time in RFC3339.</TD></TR>
-<TR><TD><CODE>id</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#jsonschemapropsorarray-v1-apiextensions-k8s-io">JSONSchemaPropsOrArray</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>maxItems</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>maxLength</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>maxProperties</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>maximum</CODE><BR /><I>number</I></TD><TD></TD></TR>
-<TR><TD><CODE>minItems</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>minLength</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>minProperties</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>minimum</CODE><BR /><I>number</I></TD><TD></TD></TR>
-<TR><TD><CODE>multipleOf</CODE><BR /><I>number</I></TD><TD></TD></TR>
-<TR><TD><CODE>not</CODE><BR /><I><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>nullable</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>oneOf</CODE><BR /><I><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>pattern</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>patternProperties</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>properties</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>required</CODE><BR /><I>string array</I></TD><TD></TD></TR>
-<TR><TD><CODE>title</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>uniqueItems</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>x-kubernetes-embedded-resource</CODE><BR /><I>boolean</I></TD><TD>x-kubernetes-embedded-resource defines that the value is an embedded Kubernetes runtime.Object, with TypeMeta and ObjectMeta. The type must be object. It is allowed to further restrict the embedded object. kind, apiVersion and metadata are validated automatically. x-kubernetes-preserve-unknown-fields is allowed to be true, but does not have to be if the object is fully specified (up to kind, apiVersion, metadata).</TD></TR>
-<TR><TD><CODE>x-kubernetes-int-or-string</CODE><BR /><I>boolean</I></TD><TD>x-kubernetes-int-or-string specifies that this value is either an integer or a string. If this is true, an empty type is allowed and type as child of anyOf is permitted if following one of the following patterns:  1) anyOf:    - type: integer    - type: string 2) allOf:    - anyOf:      - type: integer      - type: string    - ... zero or more</TD></TR>
-<TR><TD><CODE>x-kubernetes-list-map-keys</CODE><BR /><I>string array</I></TD><TD>x-kubernetes-list-map-keys annotates an array with the x-kubernetes-list-type `map` by specifying the keys used as the index of the map.  This tag MUST only be used on lists that have the &#34;x-kubernetes-list-type&#34; extension set to &#34;map&#34;. Also, the values specified for this attribute must be a scalar typed field of the child structure (no nesting is supported).  The properties specified must either be required or have a default value, to ensure those properties are present for all list items.</TD></TR>
-<TR><TD><CODE>x-kubernetes-list-type</CODE><BR /><I>string</I></TD><TD>x-kubernetes-list-type annotates an array to further describe its topology. This extension must only be used on lists and may have 3 possible values:  1) `atomic`: the list is treated as a single entity, like a scalar.      Atomic lists will be entirely replaced when updated. This extension      may be used on any type of list (struct, scalar, ...). 2) `set`:      Sets are lists that must not have multiple items with the same value. Each      value must be a scalar, an object with x-kubernetes-map-type `atomic` or an      array with x-kubernetes-list-type `atomic`. 3) `map`:      These lists are like maps in that their elements have a non-index key      used to identify them. Order is preserved upon merge. The map tag      must only be used on a list with elements of type object. Defaults to atomic for arrays.</TD></TR>
-<TR><TD><CODE>x-kubernetes-map-type</CODE><BR /><I>string</I></TD><TD>x-kubernetes-map-type annotates an object to further describe its topology. This extension must only be used when type is object and may have 2 possible values:  1) `granular`:      These maps are actual maps (key-value pairs) and each fields are independent      from each other (they can each be manipulated by separate actors). This is      the default behaviour for all maps. 2) `atomic`: the list is treated as a single entity, like a scalar.      Atomic maps will be entirely replaced when updated.</TD></TR>
-<TR><TD><CODE>x-kubernetes-preserve-unknown-fields</CODE><BR /><I>boolean</I></TD><TD>x-kubernetes-preserve-unknown-fields stops the API server decoding step from pruning fields which are not specified in the validation schema. This affects fields recursively, but switches back to normal pruning behaviour if nested properties or additionalProperties are specified in the schema. This can either be true or undefined. False is forbidden.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="jsonschemapropsorarray-v1-apiextensions-k8s-io">JSONSchemaPropsOrArray v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>JSONSchemaPropsOrArray</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>JSONSchemaPropsOrArray represents a value that can either be a JSONSchemaProps or an array of JSONSchemaProps. Mainly here for serialization purposes.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jsonschemapropsorarray-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="jsonschemapropsorbool-v1-apiextensions-k8s-io">JSONSchemaPropsOrBool v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>JSONSchemaPropsOrBool</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>JSONSchemaPropsOrBool represents JSONSchemaProps or a boolean value. Defaults to true for the boolean property.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jsonschemapropsorbool-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="jobcondition-v1-batch">JobCondition v1 batch</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>batch</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>JobCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>JobCondition describes current state of a job.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jobstatus-v1-batch">JobStatus [batch/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastProbeTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition was checked.</TD></TR>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transit from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Human readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>(brief) reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of job condition, Complete or Failed.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="jobtemplatespec-v1beta1-batch">JobTemplateSpec v1beta1 batch</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>batch</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>JobTemplateSpec</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>JobTemplateSpec describes the data a Job should have when created from a template</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jobtemplatespec-v2alpha1-batch">v2alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjobspec-v1beta1-batch">CronJobSpec [batch/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata of the jobs created from this template. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#jobspec-v1-batch">JobSpec</a></I></TD><TD>Specification of the desired behavior of the job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="keytopath-v1-core">KeyToPath v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>KeyToPath</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Maps a string key to a path within a volume.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#configmapprojection-v1-core">ConfigMapProjection [core/v1]</a></LI>
-  <LI><a href="#configmapvolumesource-v1-core">ConfigMapVolumeSource [core/v1]</a></LI>
-  <LI><a href="#secretprojection-v1-core">SecretProjection [core/v1]</a></LI>
-  <LI><a href="#secretvolumesource-v1-core">SecretVolumeSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>The key to project.</TD></TR>
-<TR><TD><CODE>mode</CODE><BR /><I>integer</I></TD><TD>Optional: mode bits to use on this file, must be a value between 0 and 0777. If not specified, the volume defaultMode will be used. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>The relative path of the file to map the key to. May not be an absolute path. May not contain the path element &#39;..&#39;. May not start with the string &#39;..&#39;.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="labelselector-v1-meta">LabelSelector v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LabelSelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#aggregationrule-v1-rbac-authorization-k8s-io">AggregationRule [rbac/v1]</a></LI>
-  <LI><a href="#aggregationrule-v1beta1-rbac-authorization-k8s-io">AggregationRule [rbac/v1beta1]</a></LI>
-  <LI><a href="#aggregationrule-v1alpha1-rbac-authorization-k8s-io">AggregationRule [rbac/v1alpha1]</a></LI>
-  <LI><a href="#daemonsetspec-v1-apps">DaemonSetSpec [apps/v1]</a></LI>
-  <LI><a href="#deploymentspec-v1-apps">DeploymentSpec [apps/v1]</a></LI>
-  <LI><a href="#externalmetricsource-v2beta1-autoscaling">ExternalMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#externalmetricstatus-v2beta1-autoscaling">ExternalMetricStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#jobspec-v1-batch">JobSpec [batch/v1]</a></LI>
-  <LI><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#mutatingwebhook-v1-admissionregistration-k8s-io">MutatingWebhook [admissionregistration/v1]</a></LI>
-  <LI><a href="#mutatingwebhook-v1beta1-admissionregistration-k8s-io">MutatingWebhook [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#networkpolicypeer-v1-networking-k8s-io">NetworkPolicyPeer [networking/v1]</a></LI>
-  <LI><a href="#networkpolicyspec-v1-networking-k8s-io">NetworkPolicySpec [networking/v1]</a></LI>
-  <LI><a href="#objectmetricsource-v2beta1-autoscaling">ObjectMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#objectmetricstatus-v2beta1-autoscaling">ObjectMetricStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#persistentvolumeclaimspec-v1-core">PersistentVolumeClaimSpec [core/v1]</a></LI>
-  <LI><a href="#podaffinityterm-v1-core">PodAffinityTerm [core/v1]</a></LI>
-  <LI><a href="#poddisruptionbudgetspec-v1beta1-policy">PodDisruptionBudgetSpec [policy/v1beta1]</a></LI>
-  <LI><a href="#podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec [settings/v1alpha1]</a></LI>
-  <LI><a href="#podsmetricsource-v2beta1-autoscaling">PodsMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#podsmetricstatus-v2beta1-autoscaling">PodsMetricStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#replicasetspec-v1-apps">ReplicaSetSpec [apps/v1]</a></LI>
-  <LI><a href="#statefulsetspec-v1-apps">StatefulSetSpec [apps/v1]</a></LI>
-  <LI><a href="#topologyspreadconstraint-v1-core">TopologySpreadConstraint [core/v1]</a></LI>
-  <LI><a href="#validatingwebhook-v1-admissionregistration-k8s-io">ValidatingWebhook [admissionregistration/v1]</a></LI>
-  <LI><a href="#validatingwebhook-v1beta1-admissionregistration-k8s-io">ValidatingWebhook [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>matchExpressions</CODE><BR /><I><a href="#labelselectorrequirement-v1-meta">LabelSelectorRequirement</a> array</I></TD><TD>matchExpressions is a list of label selector requirements. The requirements are ANDed.</TD></TR>
-<TR><TD><CODE>matchLabels</CODE><BR /><I>object</I></TD><TD>matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is &#34;key&#34;, the operator is &#34;In&#34;, and the values array contains only &#34;value&#34;. The requirements are ANDed.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="labelselectorrequirement-v1-meta">LabelSelectorRequirement v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LabelSelectorRequirement</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#labelselector-v1-meta">LabelSelector [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>key</CODE><BR /><I>string</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>key</I></TD><TD>key is the label key that the selector applies to.</TD></TR>
-<TR><TD><CODE>operator</CODE><BR /><I>string</I></TD><TD>operator represents a key&#39;s relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.</TD></TR>
-<TR><TD><CODE>values</CODE><BR /><I>string array</I></TD><TD>values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="lifecycle-v1-core">Lifecycle v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Lifecycle</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>postStart</CODE><BR /><I><a href="#handler-v1-core">Handler</a></I></TD><TD>PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks</TD></TR>
-<TR><TD><CODE>preStop</CODE><BR /><I><a href="#handler-v1-core">Handler</a></I></TD><TD>PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod&#39;s termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod&#39;s termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="limitrangeitem-v1-core">LimitRangeItem v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LimitRangeItem</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>LimitRangeItem defines a min/max usage limit for any resource that matches on kind.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#limitrangespec-v1-core">LimitRangeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>default</CODE><BR /><I>object</I></TD><TD>Default resource requirement limit value by resource name if resource limit is omitted.</TD></TR>
-<TR><TD><CODE>defaultRequest</CODE><BR /><I>object</I></TD><TD>DefaultRequest is the default resource requirement request value by resource name if resource request is omitted.</TD></TR>
-<TR><TD><CODE>max</CODE><BR /><I>object</I></TD><TD>Max usage constraints on this kind by resource name.</TD></TR>
-<TR><TD><CODE>maxLimitRequestRatio</CODE><BR /><I>object</I></TD><TD>MaxLimitRequestRatio if specified, the named resource must have a request and limit that are both non-zero where limit divided by request is less than or equal to the enumerated value; this represents the max burst for the named resource.</TD></TR>
-<TR><TD><CODE>min</CODE><BR /><I>object</I></TD><TD>Min usage constraints on this kind by resource name.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of resource that this limit applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io">LimitResponse v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>LimitResponse</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>LimitResponse defines how to handle requests that can not be executed right now.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">LimitedPriorityLevelConfiguration [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>queuing</CODE><BR /><I><a href="#queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">QueuingConfiguration</a></I></TD><TD>`queuing` holds the configuration parameters for queuing. This field may be non-empty only if `type` is `&#34;Queue&#34;`.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>`type` is &#34;Queue&#34; or &#34;Reject&#34;. &#34;Queue&#34; means that requests that can not be executed upon arrival are held in a queue until they can be executed or a queuing limit is reached. &#34;Reject&#34; means that requests that can not be executed upon arrival are rejected. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">LimitedPriorityLevelConfiguration v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>LimitedPriorityLevelConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>LimitedPriorityLevelConfiguration specifies how to handle requests that are subject to limits. It addresses two issues:
- * How are requests for this priority level limited?
- * What should be done with requests that exceed the limit?</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#prioritylevelconfigurationspec-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationSpec [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>assuredConcurrencyShares</CODE><BR /><I>integer</I></TD><TD>`assuredConcurrencyShares` (ACS) configures the execution limit, which is a limit on the number of requests of this priority level that may be exeucting at a given time.  ACS must be a positive number. The server&#39;s concurrency limit (SCL) is divided among the concurrency-controlled priority levels in proportion to their assured concurrency shares. This produces the assured concurrency value (ACV) --- the number of requests that may be executing at a time --- for each such priority level:              ACV(l) = ceil( SCL * ACS(l) / ( sum[priority levels k] ACS(k) ) )  bigger numbers of ACS mean more reserved concurrent requests (at the expense of every other PL). This field has a default value of 30.</TD></TR>
-<TR><TD><CODE>limitResponse</CODE><BR /><I><a href="#limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io">LimitResponse</a></I></TD><TD>`limitResponse` indicates what to do with requests that can not be executed right now</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="listmeta-v1-meta">ListMeta v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ListMeta</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ListMeta describes metadata that synthetic resources must have, including lists and various status objects. A resource may have only one of {ObjectMeta, ListMeta}.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicelist-v1-apiregistration-k8s-io">APIServiceList [apiregistration/v1]</a></LI>
-  <LI><a href="#apiservicelist-v1beta1-apiregistration-k8s-io">APIServiceList [apiregistration/v1beta1]</a></LI>
-  <LI><a href="#auditsinklist-v1alpha1-auditregistration-k8s-io">AuditSinkList [auditregistration/v1alpha1]</a></LI>
-  <LI><a href="#csidriverlist-v1-storage-k8s-io">CSIDriverList [storage/v1]</a></LI>
-  <LI><a href="#csidriverlist-v1beta1-storage-k8s-io">CSIDriverList [storage/v1beta1]</a></LI>
-  <LI><a href="#csinodelist-v1-storage-k8s-io">CSINodeList [storage/v1]</a></LI>
-  <LI><a href="#csinodelist-v1beta1-storage-k8s-io">CSINodeList [storage/v1beta1]</a></LI>
-  <LI><a href="#certificatesigningrequestlist-v1beta1-certificates-k8s-io">CertificateSigningRequestList [certificates/v1beta1]</a></LI>
-  <LI><a href="#clusterrolebindinglist-v1-rbac-authorization-k8s-io">ClusterRoleBindingList [rbac/v1]</a></LI>
-  <LI><a href="#clusterrolebindinglist-v1beta1-rbac-authorization-k8s-io">ClusterRoleBindingList [rbac/v1beta1]</a></LI>
-  <LI><a href="#clusterrolebindinglist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBindingList [rbac/v1alpha1]</a></LI>
-  <LI><a href="#clusterrolelist-v1-rbac-authorization-k8s-io">ClusterRoleList [rbac/v1]</a></LI>
-  <LI><a href="#clusterrolelist-v1beta1-rbac-authorization-k8s-io">ClusterRoleList [rbac/v1beta1]</a></LI>
-  <LI><a href="#clusterrolelist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleList [rbac/v1alpha1]</a></LI>
-  <LI><a href="#componentstatuslist-v1-core">ComponentStatusList [core/v1]</a></LI>
-  <LI><a href="#configmaplist-v1-core">ConfigMapList [core/v1]</a></LI>
-  <LI><a href="#controllerrevisionlist-v1-apps">ControllerRevisionList [apps/v1]</a></LI>
-  <LI><a href="#cronjoblist-v1beta1-batch">CronJobList [batch/v1beta1]</a></LI>
-  <LI><a href="#cronjoblist-v2alpha1-batch">CronJobList [batch/v2alpha1]</a></LI>
-  <LI><a href="#customresourcedefinitionlist-v1-apiextensions-k8s-io">CustomResourceDefinitionList [apiextensions/v1]</a></LI>
-  <LI><a href="#customresourcedefinitionlist-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionList [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#daemonsetlist-v1-apps">DaemonSetList [apps/v1]</a></LI>
-  <LI><a href="#deploymentlist-v1-apps">DeploymentList [apps/v1]</a></LI>
-  <LI><a href="#endpointslicelist-v1beta1-discovery-k8s-io">EndpointSliceList [discovery/v1beta1]</a></LI>
-  <LI><a href="#endpointslist-v1-core">EndpointsList [core/v1]</a></LI>
-  <LI><a href="#eventlist-v1-core">EventList [core/v1]</a></LI>
-  <LI><a href="#eventlist-v1beta1-events-k8s-io">EventList [events/v1beta1]</a></LI>
-  <LI><a href="#flowschemalist-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaList [flowcontrol/v1alpha1]</a></LI>
-  <LI><a href="#horizontalpodautoscalerlist-v1-autoscaling">HorizontalPodAutoscalerList [autoscaling/v1]</a></LI>
-  <LI><a href="#horizontalpodautoscalerlist-v2beta2-autoscaling">HorizontalPodAutoscalerList [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#horizontalpodautoscalerlist-v2beta1-autoscaling">HorizontalPodAutoscalerList [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#ingressclasslist-v1beta1-networking-k8s-io">IngressClassList [networking/v1beta1]</a></LI>
-  <LI><a href="#ingresslist-v1beta1-extensions">IngressList [extensions/v1beta1]</a></LI>
-  <LI><a href="#ingresslist-v1beta1-networking-k8s-io">IngressList [networking/v1beta1]</a></LI>
-  <LI><a href="#joblist-v1-batch">JobList [batch/v1]</a></LI>
-  <LI><a href="#leaselist-v1-coordination-k8s-io">LeaseList [coordination/v1]</a></LI>
-  <LI><a href="#leaselist-v1beta1-coordination-k8s-io">LeaseList [coordination/v1beta1]</a></LI>
-  <LI><a href="#limitrangelist-v1-core">LimitRangeList [core/v1]</a></LI>
-  <LI><a href="#mutatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">MutatingWebhookConfigurationList [admissionregistration/v1]</a></LI>
-  <LI><a href="#mutatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfigurationList [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#namespacelist-v1-core">NamespaceList [core/v1]</a></LI>
-  <LI><a href="#networkpolicylist-v1-networking-k8s-io">NetworkPolicyList [networking/v1]</a></LI>
-  <LI><a href="#nodelist-v1-core">NodeList [core/v1]</a></LI>
-  <LI><a href="#persistentvolumeclaimlist-v1-core">PersistentVolumeClaimList [core/v1]</a></LI>
-  <LI><a href="#persistentvolumelist-v1-core">PersistentVolumeList [core/v1]</a></LI>
-  <LI><a href="#poddisruptionbudgetlist-v1beta1-policy">PodDisruptionBudgetList [policy/v1beta1]</a></LI>
-  <LI><a href="#podlist-v1-core">PodList [core/v1]</a></LI>
-  <LI><a href="#podpresetlist-v1alpha1-settings-k8s-io">PodPresetList [settings/v1alpha1]</a></LI>
-  <LI><a href="#podsecuritypolicylist-v1beta1-policy">PodSecurityPolicyList [policy/v1beta1]</a></LI>
-  <LI><a href="#podtemplatelist-v1-core">PodTemplateList [core/v1]</a></LI>
-  <LI><a href="#priorityclasslist-v1-scheduling-k8s-io">PriorityClassList [scheduling/v1]</a></LI>
-  <LI><a href="#priorityclasslist-v1beta1-scheduling-k8s-io">PriorityClassList [scheduling/v1beta1]</a></LI>
-  <LI><a href="#priorityclasslist-v1alpha1-scheduling-k8s-io">PriorityClassList [scheduling/v1alpha1]</a></LI>
-  <LI><a href="#prioritylevelconfigurationlist-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationList [flowcontrol/v1alpha1]</a></LI>
-  <LI><a href="#replicasetlist-v1-apps">ReplicaSetList [apps/v1]</a></LI>
-  <LI><a href="#replicationcontrollerlist-v1-core">ReplicationControllerList [core/v1]</a></LI>
-  <LI><a href="#resourcequotalist-v1-core">ResourceQuotaList [core/v1]</a></LI>
-  <LI><a href="#rolebindinglist-v1-rbac-authorization-k8s-io">RoleBindingList [rbac/v1]</a></LI>
-  <LI><a href="#rolebindinglist-v1beta1-rbac-authorization-k8s-io">RoleBindingList [rbac/v1beta1]</a></LI>
-  <LI><a href="#rolebindinglist-v1alpha1-rbac-authorization-k8s-io">RoleBindingList [rbac/v1alpha1]</a></LI>
-  <LI><a href="#rolelist-v1-rbac-authorization-k8s-io">RoleList [rbac/v1]</a></LI>
-  <LI><a href="#rolelist-v1beta1-rbac-authorization-k8s-io">RoleList [rbac/v1beta1]</a></LI>
-  <LI><a href="#rolelist-v1alpha1-rbac-authorization-k8s-io">RoleList [rbac/v1alpha1]</a></LI>
-  <LI><a href="#runtimeclasslist-v1beta1-node-k8s-io">RuntimeClassList [node/v1beta1]</a></LI>
-  <LI><a href="#runtimeclasslist-v1alpha1-node-k8s-io">RuntimeClassList [node/v1alpha1]</a></LI>
-  <LI><a href="#secretlist-v1-core">SecretList [core/v1]</a></LI>
-  <LI><a href="#serviceaccountlist-v1-core">ServiceAccountList [core/v1]</a></LI>
-  <LI><a href="#servicelist-v1-core">ServiceList [core/v1]</a></LI>
-  <LI><a href="#statefulsetlist-v1-apps">StatefulSetList [apps/v1]</a></LI>
-  <LI><a href="#status-v1-meta">Status [meta/v1]</a></LI>
-  <LI><a href="#storageclasslist-v1-storage-k8s-io">StorageClassList [storage/v1]</a></LI>
-  <LI><a href="#storageclasslist-v1beta1-storage-k8s-io">StorageClassList [storage/v1beta1]</a></LI>
-  <LI><a href="#validatingwebhookconfigurationlist-v1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList [admissionregistration/v1]</a></LI>
-  <LI><a href="#validatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#volumeattachmentlist-v1-storage-k8s-io">VolumeAttachmentList [storage/v1]</a></LI>
-  <LI><a href="#volumeattachmentlist-v1beta1-storage-k8s-io">VolumeAttachmentList [storage/v1beta1]</a></LI>
-  <LI><a href="#volumeattachmentlist-v1alpha1-storage-k8s-io">VolumeAttachmentList [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>continue</CODE><BR /><I>string</I></TD><TD>continue may be set if the user set a limit on the number of items returned, and indicates that the server has more data available. The value is opaque and may be used to issue another request to the endpoint that served this list to retrieve the next set of available objects. Continuing a consistent list may not be possible if the server configuration has changed or more than a few minutes have passed. The resourceVersion field returned when using this continue value will be identical to the value in the first response, unless you have received this token from an error message.</TD></TR>
-<TR><TD><CODE>remainingItemCount</CODE><BR /><I>integer</I></TD><TD>remainingItemCount is the number of subsequent items in the list which are not included in this list response. If the list request contained label or field selectors, then the number of remaining items is unknown and the field will be left unset and omitted during serialization. If the list is complete (either because it is not chunking or because this is the last chunk), then there are no more remaining items and this field will be left unset and omitted during serialization. Servers older than v1.15 do not set this field. The intended use of the remainingItemCount is *estimating* the size of a collection. Clients should not rely on the remainingItemCount to be set or to be exact.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE><BR /><I>string</I></TD><TD>String that identifies the server&#39;s internal version of this object that can be used by clients to determine when objects have changed. Value must be treated as opaque by clients and passed unmodified back to the server. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency</TD></TR>
-<TR><TD><CODE>selfLink</CODE><BR /><I>string</I></TD><TD>selfLink is a URL representing this object. Populated by the system. Read-only.  DEPRECATED Kubernetes will stop propagating this field in 1.20 release and the field is planned to be removed in 1.21 release.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="loadbalanceringress-v1-core">LoadBalancerIngress v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LoadBalancerIngress</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>LoadBalancerIngress represents the status of a load-balancer ingress point: traffic intended for the service should be sent to an ingress point.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#loadbalancerstatus-v1-core">LoadBalancerStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hostname</CODE><BR /><I>string</I></TD><TD>Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers)</TD></TR>
-<TR><TD><CODE>ip</CODE><BR /><I>string</I></TD><TD>IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers)</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="loadbalancerstatus-v1-core">LoadBalancerStatus v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LoadBalancerStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>LoadBalancerStatus represents the status of a load-balancer.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressstatus-v1beta1-extensions">IngressStatus [extensions/v1beta1]</a></LI>
-  <LI><a href="#ingressstatus-v1beta1-networking-k8s-io">IngressStatus [networking/v1beta1]</a></LI>
-  <LI><a href="#servicestatus-v1-core">ServiceStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ingress</CODE><BR /><I><a href="#loadbalanceringress-v1-core">LoadBalancerIngress</a> array</I></TD><TD>Ingress is a list containing ingress points for the load-balancer. Traffic intended for the service should be sent to these ingress points.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="localobjectreference-v1-core">LocalObjectReference v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LocalObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>LocalObjectReference contains enough information to let you locate the referenced object inside the same namespace.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csivolumesource-v1-core">CSIVolumeSource [core/v1]</a></LI>
-  <LI><a href="#cephfsvolumesource-v1-core">CephFSVolumeSource [core/v1]</a></LI>
-  <LI><a href="#cindervolumesource-v1-core">CinderVolumeSource [core/v1]</a></LI>
-  <LI><a href="#flexvolumesource-v1-core">FlexVolumeSource [core/v1]</a></LI>
-  <LI><a href="#iscsivolumesource-v1-core">ISCSIVolumeSource [core/v1]</a></LI>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
-  <LI><a href="#rbdvolumesource-v1-core">RBDVolumeSource [core/v1]</a></LI>
-  <LI><a href="#scaleiovolumesource-v1-core">ScaleIOVolumeSource [core/v1]</a></LI>
-  <LI><a href="#serviceaccount-v1-core">ServiceAccount [core/v1]</a></LI>
-  <LI><a href="#storageosvolumesource-v1-core">StorageOSVolumeSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="localvolumesource-v1-core">LocalVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>LocalVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Local represents directly-attached storage with node affinity (Beta feature)</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. It applies only when the Path is a block device. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. The default value is to auto-select a fileystem if unspecified.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>The full path to the volume on the node. It can be either a directory or block device (disk, partition, ...).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="managedfieldsentry-v1-meta">ManagedFieldsEntry v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ManagedFieldsEntry</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ManagedFieldsEntry is a workflow-id, a FieldSet and the group version of the resource that the fieldset applies to.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#objectmeta-v1-meta">ObjectMeta [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the version of this resource that this field set applies to. The format is &#34;group/version&#34; just like the top-level APIVersion field. It is necessary to track the version of a field set because it cannot be automatically converted.</TD></TR>
-<TR><TD><CODE>fieldsType</CODE><BR /><I>string</I></TD><TD>FieldsType is the discriminator for the different fields format and version. There is currently only one possible value: &#34;FieldsV1&#34;</TD></TR>
-<TR><TD><CODE>fieldsV1</CODE><BR /><I><a href="#fieldsv1-v1-meta">FieldsV1</a></I></TD><TD>FieldsV1 holds the first JSON version format as described in the &#34;FieldsV1&#34; type.</TD></TR>
-<TR><TD><CODE>manager</CODE><BR /><I>string</I></TD><TD>Manager is an identifier of the workflow managing these fields.</TD></TR>
-<TR><TD><CODE>operation</CODE><BR /><I>string</I></TD><TD>Operation is the type of operation which lead to this ManagedFieldsEntry being created. The only valid values for this field are &#39;Apply&#39; and &#39;Update&#39;.</TD></TR>
-<TR><TD><CODE>time</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time is timestamp of when these fields were set. It should always be empty if Operation is &#39;Apply&#39;</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="metricidentifier-v2beta2-autoscaling">MetricIdentifier v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>MetricIdentifier</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MetricIdentifier defines the name and optionally selector for a metric</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#externalmetricsource-v2beta2-autoscaling">ExternalMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#externalmetricstatus-v2beta2-autoscaling">ExternalMetricStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricsource-v2beta2-autoscaling">ObjectMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricstatus-v2beta2-autoscaling">ObjectMetricStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#podsmetricsource-v2beta2-autoscaling">PodsMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#podsmetricstatus-v2beta2-autoscaling">PodsMetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the given metric</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="metricspec-v2beta2-autoscaling">MetricSpec v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>MetricSpec</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MetricSpec specifies how to scale based on a single metric (only `type` and one other matching field should be set at once).</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#metricspec-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerspec-v2beta2-autoscaling">HorizontalPodAutoscalerSpec [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>external</CODE><BR /><I><a href="#externalmetricsource-v2beta2-autoscaling">ExternalMetricSource</a></I></TD><TD>external refers to a global metric that is not associated with any Kubernetes object. It allows autoscaling based on information coming from components running outside of cluster (for example length of queue in cloud messaging service, or QPS from loadbalancer running outside of cluster).</TD></TR>
-<TR><TD><CODE>object</CODE><BR /><I><a href="#objectmetricsource-v2beta2-autoscaling">ObjectMetricSource</a></I></TD><TD>object refers to a metric describing a single kubernetes object (for example, hits-per-second on an Ingress object).</TD></TR>
-<TR><TD><CODE>pods</CODE><BR /><I><a href="#podsmetricsource-v2beta2-autoscaling">PodsMetricSource</a></I></TD><TD>pods refers to a metric describing each pod in the current scale target (for example, transactions-processed-per-second).  The values will be averaged together before being compared to the target value.</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I><a href="#resourcemetricsource-v2beta2-autoscaling">ResourceMetricSource</a></I></TD><TD>resource refers to a resource metric (such as those specified in requests and limits) known to Kubernetes describing each pod in the current scale target (e.g. CPU or memory). Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the &#34;pods&#34; source.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is the type of metric source.  It should be one of &#34;Object&#34;, &#34;Pods&#34; or &#34;Resource&#34;, each mapping to a matching field in the object.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="metricstatus-v2beta2-autoscaling">MetricStatus v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>MetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MetricStatus describes the last-read state of a single metric.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#metricstatus-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerstatus-v2beta2-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>external</CODE><BR /><I><a href="#externalmetricstatus-v2beta2-autoscaling">ExternalMetricStatus</a></I></TD><TD>external refers to a global metric that is not associated with any Kubernetes object. It allows autoscaling based on information coming from components running outside of cluster (for example length of queue in cloud messaging service, or QPS from loadbalancer running outside of cluster).</TD></TR>
-<TR><TD><CODE>object</CODE><BR /><I><a href="#objectmetricstatus-v2beta2-autoscaling">ObjectMetricStatus</a></I></TD><TD>object refers to a metric describing a single kubernetes object (for example, hits-per-second on an Ingress object).</TD></TR>
-<TR><TD><CODE>pods</CODE><BR /><I><a href="#podsmetricstatus-v2beta2-autoscaling">PodsMetricStatus</a></I></TD><TD>pods refers to a metric describing each pod in the current scale target (for example, transactions-processed-per-second).  The values will be averaged together before being compared to the target value.</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I><a href="#resourcemetricstatus-v2beta2-autoscaling">ResourceMetricStatus</a></I></TD><TD>resource refers to a resource metric (such as those specified in requests and limits) known to Kubernetes describing each pod in the current scale target (e.g. CPU or memory). Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the &#34;pods&#34; source.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is the type of metric source.  It will be one of &#34;Object&#34;, &#34;Pods&#34; or &#34;Resource&#34;, each corresponds to a matching field in the object.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="metrictarget-v2beta2-autoscaling">MetricTarget v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>MetricTarget</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MetricTarget defines the target value, average value, or average utilization of a specific metric</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#externalmetricsource-v2beta2-autoscaling">ExternalMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricsource-v2beta2-autoscaling">ObjectMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#podsmetricsource-v2beta2-autoscaling">PodsMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#resourcemetricsource-v2beta2-autoscaling">ResourceMetricSource [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>averageUtilization</CODE><BR /><I>integer</I></TD><TD>averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type</TD></TR>
-<TR><TD><CODE>averageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>averageValue is the target value of the average of the metric across all relevant pods (as a quantity)</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type represents whether the metric type is Utilization, Value, or AverageValue</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>value is the target value of the metric (as a quantity).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="metricvaluestatus-v2beta2-autoscaling">MetricValueStatus v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>MetricValueStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MetricValueStatus holds the current value for a metric</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#externalmetricstatus-v2beta2-autoscaling">ExternalMetricStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricstatus-v2beta2-autoscaling">ObjectMetricStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#podsmetricstatus-v2beta2-autoscaling">PodsMetricStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#resourcemetricstatus-v2beta2-autoscaling">ResourceMetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>averageUtilization</CODE><BR /><I>integer</I></TD><TD>currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.</TD></TR>
-<TR><TD><CODE>averageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>averageValue is the current value of the average of the metric across all relevant pods (as a quantity)</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>value is the current value of the metric (as a quantity).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="microtime-v1-meta">MicroTime v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>MicroTime</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MicroTime is version of Time with microsecond level precision.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#event-v1-core">Event [core/v1]</a></LI>
-  <LI><a href="#event-v1beta1-events-k8s-io">Event [events/v1beta1]</a></LI>
-  <LI><a href="#eventseries-v1-core">EventSeries [core/v1]</a></LI>
-  <LI><a href="#eventseries-v1beta1-events-k8s-io">EventSeries [events/v1beta1]</a></LI>
-  <LI><a href="#leasespec-v1-coordination-k8s-io">LeaseSpec [coordination/v1]</a></LI>
-  <LI><a href="#leasespec-v1beta1-coordination-k8s-io">LeaseSpec [coordination/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="mutatingwebhook-v1-admissionregistration-k8s-io">MutatingWebhook v1 admissionregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>MutatingWebhook</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>MutatingWebhook describes an admission webhook and the resources and operations it applies to.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#mutatingwebhook-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionReviewVersions</CODE><BR /><I>string array</I></TD><TD>AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy.</TD></TR>
-<TR><TD><CODE>clientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1-admissionregistration-k8s-io">WebhookClientConfig</a></I></TD><TD>ClientConfig defines how to communicate with the hook. Required</TD></TR>
-<TR><TD><CODE>failurePolicy</CODE><BR /><I>string</I></TD><TD>FailurePolicy defines how unrecognized errors from the admission endpoint are handled - allowed values are Ignore or Fail. Defaults to Fail.</TD></TR>
-<TR><TD><CODE>matchPolicy</CODE><BR /><I>string</I></TD><TD>matchPolicy defines how the &#34;rules&#34; list is used to match incoming requests. Allowed values are &#34;Exact&#34; or &#34;Equivalent&#34;.  - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook.  - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook.  Defaults to &#34;Equivalent&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where &#34;imagepolicy&#34; is the name of the webhook, and kubernetes.io is the name of the organization. Required.</TD></TR>
-<TR><TD><CODE>namespaceSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook.  For example, to run the webhook on any objects whose namespace is not associated with &#34;runlevel&#34; of &#34;0&#34; or &#34;1&#34;;  you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;runlevel&#34;,       &#34;operator&#34;: &#34;NotIn&#34;,       &#34;values&#34;: [         &#34;0&#34;,         &#34;1&#34;       ]     }   ] }  If instead you want to only run the webhook on any objects whose namespace is associated with the &#34;environment&#34; of &#34;prod&#34; or &#34;staging&#34;; you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;environment&#34;,       &#34;operator&#34;: &#34;In&#34;,       &#34;values&#34;: [         &#34;prod&#34;,         &#34;staging&#34;       ]     }   ] }  See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ for more examples of label selectors.  Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>objectSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>reinvocationPolicy</CODE><BR /><I>string</I></TD><TD>reinvocationPolicy indicates whether this webhook should be called multiple times as part of a single admission evaluation. Allowed values are &#34;Never&#34; and &#34;IfNeeded&#34;.  Never: the webhook will not be called more than once in a single admission evaluation.  IfNeeded: the webhook will be called at least one additional time as part of the admission evaluation if the object being admitted is modified by other admission plugins after the initial webhook call. Webhooks that specify this option *must* be idempotent, able to process objects they previously admitted. Note: * the number of additional invocations is not guaranteed to be exactly one. * if additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again. * webhooks that use this option may be reordered to minimize the number of additional invocations. * to validate an object after all mutations are guaranteed complete, use a validating admission webhook instead.  Defaults to &#34;Never&#34;.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#rulewithoperations-v1-admissionregistration-k8s-io">RuleWithOperations</a> array</I></TD><TD>Rules describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.</TD></TR>
-<TR><TD><CODE>sideEffects</CODE><BR /><I>string</I></TD><TD>SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE><BR /><I>integer</I></TD><TD>TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 10 seconds.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nfsvolumesource-v1-core">NFSVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NFSVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents an NFS mount that lasts the lifetime of a pod. NFS volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path that is exported by the NFS server. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the NFS export to be mounted with read-only permissions. Defaults to false. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs</TD></TR>
-<TR><TD><CODE>server</CODE><BR /><I>string</I></TD><TD>Server is the hostname or IP address of the NFS server. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="namespacecondition-v1-core">NamespaceCondition v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NamespaceCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NamespaceCondition contains details about state of namespace.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#namespacestatus-v1-core">NamespaceStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of namespace controller condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="networkpolicyegressrule-v1-networking-k8s-io">NetworkPolicyEgressRule v1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NetworkPolicyEgressRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NetworkPolicyEgressRule describes a particular set of traffic that is allowed out of pods matched by a NetworkPolicySpec&#39;s podSelector. The traffic must match both ports and to. This type is beta-level in 1.8</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicyspec-v1-networking-k8s-io">NetworkPolicySpec [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#networkpolicyport-v1-networking-k8s-io">NetworkPolicyPort</a> array</I></TD><TD>List of destination ports for outgoing traffic. Each item in this list is combined using a logical OR. If this field is empty or missing, this rule matches all ports (traffic not restricted by port). If this field is present and contains at least one item, then this rule allows traffic only if the traffic matches at least one port in the list.</TD></TR>
-<TR><TD><CODE>to</CODE><BR /><I><a href="#networkpolicypeer-v1-networking-k8s-io">NetworkPolicyPeer</a> array</I></TD><TD>List of destinations for outgoing traffic of pods selected for this rule. Items in this list are combined using a logical OR operation. If this field is empty or missing, this rule matches all destinations (traffic not restricted by destination). If this field is present and contains at least one item, this rule allows traffic only if the traffic matches at least one item in the to list.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="networkpolicyingressrule-v1-networking-k8s-io">NetworkPolicyIngressRule v1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NetworkPolicyIngressRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NetworkPolicyIngressRule describes a particular set of traffic that is allowed to the pods matched by a NetworkPolicySpec&#39;s podSelector. The traffic must match both ports and from.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicyspec-v1-networking-k8s-io">NetworkPolicySpec [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>from</CODE><BR /><I><a href="#networkpolicypeer-v1-networking-k8s-io">NetworkPolicyPeer</a> array</I></TD><TD>List of sources which should be able to access the pods selected for this rule. Items in this list are combined using a logical OR operation. If this field is empty or missing, this rule matches all sources (traffic not restricted by source). If this field is present and contains at least one item, this rule allows traffic only if the traffic matches at least one item in the from list.</TD></TR>
-<TR><TD><CODE>ports</CODE><BR /><I><a href="#networkpolicyport-v1-networking-k8s-io">NetworkPolicyPort</a> array</I></TD><TD>List of ports which should be made accessible on the pods selected for this rule. Each item in this list is combined using a logical OR. If this field is empty or missing, this rule matches all ports (traffic not restricted by port). If this field is present and contains at least one item, then this rule allows traffic only if the traffic matches at least one port in the list.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="networkpolicypeer-v1-networking-k8s-io">NetworkPolicyPeer v1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NetworkPolicyPeer</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NetworkPolicyPeer describes a peer to allow traffic from. Only certain combinations of fields are allowed</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicyegressrule-v1-networking-k8s-io">NetworkPolicyEgressRule [networking/v1]</a></LI>
-  <LI><a href="#networkpolicyingressrule-v1-networking-k8s-io">NetworkPolicyIngressRule [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ipBlock</CODE><BR /><I><a href="#ipblock-v1-networking-k8s-io">IPBlock</a></I></TD><TD>IPBlock defines policy on a particular IPBlock. If this field is set then neither of the other fields can be.</TD></TR>
-<TR><TD><CODE>namespaceSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>Selects Namespaces using cluster-scoped labels. This field follows standard label selector semantics; if present but empty, it selects all namespaces.  If PodSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects all Pods in the Namespaces selected by NamespaceSelector.</TD></TR>
-<TR><TD><CODE>podSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods.  If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy&#39;s own Namespace.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="networkpolicyport-v1-networking-k8s-io">NetworkPolicyPort v1 networking.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NetworkPolicyPort</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NetworkPolicyPort describes a port to allow traffic on</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#networkpolicyegressrule-v1-networking-k8s-io">NetworkPolicyEgressRule [networking/v1]</a></LI>
-  <LI><a href="#networkpolicyingressrule-v1-networking-k8s-io">NetworkPolicyIngressRule [networking/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>port</CODE></TD><TD>The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers.</TD></TR>
-<TR><TD><CODE>protocol</CODE><BR /><I>string</I></TD><TD>The protocol (TCP, UDP, or SCTP) which traffic must match. If not specified, this field defaults to TCP.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeaddress-v1-core">NodeAddress v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeAddress</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NodeAddress contains information for the node&#39;s address.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>address</CODE><BR /><I>string</I></TD><TD>The node address.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Node address type, one of Hostname, ExternalIP or InternalIP.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeaffinity-v1-core">NodeAffinity v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeAffinity</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Node affinity is a group of node affinity scheduling rules.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#affinity-v1-core">Affinity [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>preferredDuringSchedulingIgnoredDuringExecution</CODE><BR /><I><a href="#preferredschedulingterm-v1-core">PreferredSchedulingTerm</a> array</I></TD><TD>The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding &#34;weight&#34; to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred.</TD></TR>
-<TR><TD><CODE>requiredDuringSchedulingIgnoredDuringExecution</CODE><BR /><I><a href="#nodeselector-v1-core">NodeSelector</a></I></TD><TD>If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodecondition-v1-core">NodeCondition v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NodeCondition contains condition information for a node.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastHeartbeatTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time we got an update on a given condition.</TD></TR>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transit from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Human readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>(brief) reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of node condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeconfigsource-v1-core">NodeConfigSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeConfigSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodeconfigstatus-v1-core">NodeConfigStatus [core/v1]</a></LI>
-  <LI><a href="#nodespec-v1-core">NodeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>configMap</CODE><BR /><I><a href="#configmapnodeconfigsource-v1-core">ConfigMapNodeConfigSource</a></I></TD><TD>ConfigMap is a reference to a Node&#39;s ConfigMap</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeconfigstatus-v1-core">NodeConfigStatus v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeConfigStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NodeConfigStatus describes the status of the config assigned by Node.Spec.ConfigSource.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>active</CODE><BR /><I><a href="#nodeconfigsource-v1-core">NodeConfigSource</a></I></TD><TD>Active reports the checkpointed config the node is actively using. Active will represent either the current version of the Assigned config, or the current LastKnownGood config, depending on whether attempting to use the Assigned config results in an error.</TD></TR>
-<TR><TD><CODE>assigned</CODE><BR /><I><a href="#nodeconfigsource-v1-core">NodeConfigSource</a></I></TD><TD>Assigned reports the checkpointed config the node will try to use. When Node.Spec.ConfigSource is updated, the node checkpoints the associated config payload to local disk, along with a record indicating intended config. The node refers to this record to choose its config checkpoint, and reports this record in Assigned. Assigned only updates in the status after the record has been checkpointed to disk. When the Kubelet is restarted, it tries to make the Assigned config the Active config by loading and validating the checkpointed payload identified by Assigned.</TD></TR>
-<TR><TD><CODE>error</CODE><BR /><I>string</I></TD><TD>Error describes any problems reconciling the Spec.ConfigSource to the Active config. Errors may occur, for example, attempting to checkpoint Spec.ConfigSource to the local Assigned record, attempting to checkpoint the payload associated with Spec.ConfigSource, attempting to load or validate the Assigned config, etc. Errors may occur at different points while syncing config. Earlier errors (e.g. download or checkpointing errors) will not result in a rollback to LastKnownGood, and may resolve across Kubelet retries. Later errors (e.g. loading or validating a checkpointed config) will result in a rollback to LastKnownGood. In the latter case, it is usually possible to resolve the error by fixing the config assigned in Spec.ConfigSource. You can find additional information for debugging by searching the error message in the Kubelet log. Error is a human-readable description of the error state; machines can check whether or not Error is empty, but should not rely on the stability of the Error text across Kubelet versions.</TD></TR>
-<TR><TD><CODE>lastKnownGood</CODE><BR /><I><a href="#nodeconfigsource-v1-core">NodeConfigSource</a></I></TD><TD>LastKnownGood reports the checkpointed config the node will fall back to when it encounters an error attempting to use the Assigned config. The Assigned config becomes the LastKnownGood config when the node determines that the Assigned config is stable and correct. This is currently implemented as a 10-minute soak period starting when the local record of Assigned config is updated. If the Assigned config is Active at the end of this period, it becomes the LastKnownGood. Note that if Spec.ConfigSource is reset to nil (use local defaults), the LastKnownGood is also immediately reset to nil, because the local default config is always assumed good. You should not make assumptions about the node&#39;s method of determining config stability and correctness, as this may change or become configurable in the future.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodedaemonendpoints-v1-core">NodeDaemonEndpoints v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeDaemonEndpoints</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NodeDaemonEndpoints lists ports opened by daemons running on the Node.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>kubeletEndpoint</CODE><BR /><I><a href="#daemonendpoint-v1-core">DaemonEndpoint</a></I></TD><TD>Endpoint on which Kubelet is listening.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeselector-v1-core">NodeSelector v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeSelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A node selector represents the union of the results of one or more label queries over a set of nodes; that is, it represents the OR of the selectors represented by the node selector terms.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodeaffinity-v1-core">NodeAffinity [core/v1]</a></LI>
-  <LI><a href="#volumenodeaffinity-v1-core">VolumeNodeAffinity [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nodeSelectorTerms</CODE><BR /><I><a href="#nodeselectorterm-v1-core">NodeSelectorTerm</a> array</I></TD><TD>Required. A list of node selector terms. The terms are ORed.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeselectorrequirement-v1-core">NodeSelectorRequirement v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeSelectorRequirement</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodeselectorterm-v1-core">NodeSelectorTerm [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>The label key that the selector applies to.</TD></TR>
-<TR><TD><CODE>operator</CODE><BR /><I>string</I></TD><TD>Represents a key&#39;s relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.</TD></TR>
-<TR><TD><CODE>values</CODE><BR /><I>string array</I></TD><TD>An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodeselectorterm-v1-core">NodeSelectorTerm v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeSelectorTerm</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodeselector-v1-core">NodeSelector [core/v1]</a></LI>
-  <LI><a href="#preferredschedulingterm-v1-core">PreferredSchedulingTerm [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>matchExpressions</CODE><BR /><I><a href="#nodeselectorrequirement-v1-core">NodeSelectorRequirement</a> array</I></TD><TD>A list of node selector requirements by node&#39;s labels.</TD></TR>
-<TR><TD><CODE>matchFields</CODE><BR /><I><a href="#nodeselectorrequirement-v1-core">NodeSelectorRequirement</a> array</I></TD><TD>A list of node selector requirements by node&#39;s fields.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nodesysteminfo-v1-core">NodeSystemInfo v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NodeSystemInfo</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NodeSystemInfo is a set of ids/uuids to uniquely identify the node.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodestatus-v1-core">NodeStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>architecture</CODE><BR /><I>string</I></TD><TD>The Architecture reported by the node</TD></TR>
-<TR><TD><CODE>bootID</CODE><BR /><I>string</I></TD><TD>Boot ID reported by the node.</TD></TR>
-<TR><TD><CODE>containerRuntimeVersion</CODE><BR /><I>string</I></TD><TD>ContainerRuntime Version reported by the node through runtime remote API (e.g. docker://1.5.0).</TD></TR>
-<TR><TD><CODE>kernelVersion</CODE><BR /><I>string</I></TD><TD>Kernel Version reported by the node from &#39;uname -r&#39; (e.g. 3.16.0-0.bpo.4-amd64).</TD></TR>
-<TR><TD><CODE>kubeProxyVersion</CODE><BR /><I>string</I></TD><TD>KubeProxy Version reported by the node.</TD></TR>
-<TR><TD><CODE>kubeletVersion</CODE><BR /><I>string</I></TD><TD>Kubelet Version reported by the node.</TD></TR>
-<TR><TD><CODE>machineID</CODE><BR /><I>string</I></TD><TD>MachineID reported by the node. For unique machine identification in the cluster this field is preferred. Learn more from man(5) machine-id: http://man7.org/linux/man-pages/man5/machine-id.5.html</TD></TR>
-<TR><TD><CODE>operatingSystem</CODE><BR /><I>string</I></TD><TD>The Operating System reported by the node</TD></TR>
-<TR><TD><CODE>osImage</CODE><BR /><I>string</I></TD><TD>OS Image reported by the node from /etc/os-release (e.g. Debian GNU/Linux 7 (wheezy)).</TD></TR>
-<TR><TD><CODE>systemUUID</CODE><BR /><I>string</I></TD><TD>SystemUUID reported by the node. For unique machine identification MachineID is preferred. This field is specific to Red Hat hosts https://access.redhat.com/documentation/en-US/Red_Hat_Subscription_Management/1/html/RHSM/getting-system-uuid.html</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nonresourceattributes-v1-authorization-k8s-io">NonResourceAttributes v1 authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NonResourceAttributes</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NonResourceAttributes includes the authorization attributes available for non-resource requests to the Authorizer interface</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#nonresourceattributes-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectaccessreviewspec-v1-authorization-k8s-io">SelfSubjectAccessReviewSpec [authorization/v1]</a></LI>
-  <LI><a href="#subjectaccessreviewspec-v1-authorization-k8s-io">SubjectAccessReviewSpec [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is the URL path of the request</TD></TR>
-<TR><TD><CODE>verb</CODE><BR /><I>string</I></TD><TD>Verb is the standard HTTP verb</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io">NonResourcePolicyRule v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>NonResourcePolicyRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NonResourcePolicyRule is a predicate that matches non-resource requests according to their verb and the target non-resource URL. A NonResourcePolicyRule matches a request if and only if both (a) at least one member of verbs matches the request and (b) at least one member of nonResourceURLs matches the request.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io">PolicyRulesWithSubjects [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nonResourceURLs</CODE><BR /><I>string array</I></TD><TD>`nonResourceURLs` is a set of url prefixes that a user should have access to and may not be empty. For example:   - &#34;/healthz&#34; is legal   - &#34;/hea*&#34; is illegal   - &#34;/hea&#34; is legal but matches nothing   - &#34;/hea/*&#34; also matches nothing   - &#34;/healthz/*&#34; matches all per-component health checks. &#34;*&#34; matches all non-resource urls. if it is present, it must be the only entry. Required.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>`verbs` is a list of matching verbs and may not be empty. &#34;*&#34; matches all verbs. If it is present, it must be the only entry. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="nonresourcerule-v1-authorization-k8s-io">NonResourceRule v1 authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>NonResourceRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>NonResourceRule holds information that describes a rule for the non-resource</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#nonresourcerule-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subjectrulesreviewstatus-v1-authorization-k8s-io">SubjectRulesReviewStatus [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nonResourceURLs</CODE><BR /><I>string array</I></TD><TD>NonResourceURLs is a set of partial urls that a user should have access to.  *s are allowed, but only as the full, final step in the path.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verb is a list of kubernetes non-resource API verbs, like: get, post, put, delete, patch, head, options.  &#34;*&#34; means all.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="objectfieldselector-v1-core">ObjectFieldSelector v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ObjectFieldSelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ObjectFieldSelector selects an APIVersioned field of an object.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#downwardapivolumefile-v1-core">DownwardAPIVolumeFile [core/v1]</a></LI>
-  <LI><a href="#envvarsource-v1-core">EnvVarSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>Version of the schema the FieldPath is written in terms of, defaults to &#34;v1&#34;.</TD></TR>
-<TR><TD><CODE>fieldPath</CODE><BR /><I>string</I></TD><TD>Path of the field to select in the specified API version.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="objectmeta-v1-meta">ObjectMeta v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ObjectMeta</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservice-v1-apiregistration-k8s-io">APIService [apiregistration/v1]</a></LI>
-  <LI><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService [apiregistration/v1beta1]</a></LI>
-  <LI><a href="#auditsink-v1alpha1-auditregistration-k8s-io">AuditSink [auditregistration/v1alpha1]</a></LI>
-  <LI><a href="#binding-v1-core">Binding [core/v1]</a></LI>
-  <LI><a href="#csidriver-v1-storage-k8s-io">CSIDriver [storage/v1]</a></LI>
-  <LI><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver [storage/v1beta1]</a></LI>
-  <LI><a href="#csinode-v1-storage-k8s-io">CSINode [storage/v1]</a></LI>
-  <LI><a href="#csinode-v1beta1-storage-k8s-io">CSINode [storage/v1beta1]</a></LI>
-  <LI><a href="#certificatesigningrequest-v1beta1-certificates-k8s-io">CertificateSigningRequest [certificates/v1beta1]</a></LI>
-  <LI><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole [rbac/v1]</a></LI>
-  <LI><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole [rbac/v1beta1]</a></LI>
-  <LI><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole [rbac/v1alpha1]</a></LI>
-  <LI><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1]</a></LI>
-  <LI><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1beta1]</a></LI>
-  <LI><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1alpha1]</a></LI>
-  <LI><a href="#componentstatus-v1-core">ComponentStatus [core/v1]</a></LI>
-  <LI><a href="#configmap-v1-core">ConfigMap [core/v1]</a></LI>
-  <LI><a href="#controllerrevision-v1-apps">ControllerRevision [apps/v1]</a></LI>
-  <LI><a href="#cronjob-v1beta1-batch">CronJob [batch/v1beta1]</a></LI>
-  <LI><a href="#cronjob-v2alpha1-batch">CronJob [batch/v2alpha1]</a></LI>
-  <LI><a href="#customresourcedefinition-v1-apiextensions-k8s-io">CustomResourceDefinition [apiextensions/v1]</a></LI>
-  <LI><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#daemonset-v1-apps">DaemonSet [apps/v1]</a></LI>
-  <LI><a href="#deployment-v1-apps">Deployment [apps/v1]</a></LI>
-  <LI><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice [discovery/v1beta1]</a></LI>
-  <LI><a href="#endpoints-v1-core">Endpoints [core/v1]</a></LI>
-  <LI><a href="#event-v1-core">Event [core/v1]</a></LI>
-  <LI><a href="#event-v1beta1-events-k8s-io">Event [events/v1beta1]</a></LI>
-  <LI><a href="#eviction-v1beta1-policy">Eviction [policy/v1beta1]</a></LI>
-  <LI><a href="#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchema [flowcontrol/v1alpha1]</a></LI>
-  <LI><a href="#horizontalpodautoscaler-v1-autoscaling">HorizontalPodAutoscaler [autoscaling/v1]</a></LI>
-  <LI><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#ingress-v1beta1-extensions">Ingress [extensions/v1beta1]</a></LI>
-  <LI><a href="#ingress-v1beta1-networking-k8s-io">Ingress [networking/v1beta1]</a></LI>
-  <LI><a href="#ingressclass-v1beta1-networking-k8s-io">IngressClass [networking/v1beta1]</a></LI>
-  <LI><a href="#job-v1-batch">Job [batch/v1]</a></LI>
-  <LI><a href="#jobtemplatespec-v1beta1-batch">JobTemplateSpec [batch/v1beta1]</a></LI>
-  <LI><a href="#jobtemplatespec-v2alpha1-batch">JobTemplateSpec [batch/v2alpha1]</a></LI>
-  <LI><a href="#lease-v1-coordination-k8s-io">Lease [coordination/v1]</a></LI>
-  <LI><a href="#lease-v1beta1-coordination-k8s-io">Lease [coordination/v1beta1]</a></LI>
-  <LI><a href="#limitrange-v1-core">LimitRange [core/v1]</a></LI>
-  <LI><a href="#localsubjectaccessreview-v1-authorization-k8s-io">LocalSubjectAccessReview [authorization/v1]</a></LI>
-  <LI><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">MutatingWebhookConfiguration [admissionregistration/v1]</a></LI>
-  <LI><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#namespace-v1-core">Namespace [core/v1]</a></LI>
-  <LI><a href="#networkpolicy-v1-networking-k8s-io">NetworkPolicy [networking/v1]</a></LI>
-  <LI><a href="#node-v1-core">Node [core/v1]</a></LI>
-  <LI><a href="#persistentvolume-v1-core">PersistentVolume [core/v1]</a></LI>
-  <LI><a href="#persistentvolumeclaim-v1-core">PersistentVolumeClaim [core/v1]</a></LI>
-  <LI><a href="#pod-v1-core">Pod [core/v1]</a></LI>
-  <LI><a href="#poddisruptionbudget-v1beta1-policy">PodDisruptionBudget [policy/v1beta1]</a></LI>
-  <LI><a href="#podpreset-v1alpha1-settings-k8s-io">PodPreset [settings/v1alpha1]</a></LI>
-  <LI><a href="#podsecuritypolicy-v1beta1-policy">PodSecurityPolicy [policy/v1beta1]</a></LI>
-  <LI><a href="#podtemplate-v1-core">PodTemplate [core/v1]</a></LI>
-  <LI><a href="#podtemplatespec-v1-core">PodTemplateSpec [core/v1]</a></LI>
-  <LI><a href="#priorityclass-v1-scheduling-k8s-io">PriorityClass [scheduling/v1]</a></LI>
-  <LI><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass [scheduling/v1beta1]</a></LI>
-  <LI><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass [scheduling/v1alpha1]</a></LI>
-  <LI><a href="#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfiguration [flowcontrol/v1alpha1]</a></LI>
-  <LI><a href="#replicaset-v1-apps">ReplicaSet [apps/v1]</a></LI>
-  <LI><a href="#replicationcontroller-v1-core">ReplicationController [core/v1]</a></LI>
-  <LI><a href="#resourcequota-v1-core">ResourceQuota [core/v1]</a></LI>
-  <LI><a href="#role-v1-rbac-authorization-k8s-io">Role [rbac/v1]</a></LI>
-  <LI><a href="#role-v1beta1-rbac-authorization-k8s-io">Role [rbac/v1beta1]</a></LI>
-  <LI><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role [rbac/v1alpha1]</a></LI>
-  <LI><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding [rbac/v1]</a></LI>
-  <LI><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding [rbac/v1beta1]</a></LI>
-  <LI><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding [rbac/v1alpha1]</a></LI>
-  <LI><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass [node/v1beta1]</a></LI>
-  <LI><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass [node/v1alpha1]</a></LI>
-  <LI><a href="#scale-v1-autoscaling">Scale [autoscaling/v1]</a></LI>
-  <LI><a href="#secret-v1-core">Secret [core/v1]</a></LI>
-  <LI><a href="#selfsubjectaccessreview-v1-authorization-k8s-io">SelfSubjectAccessReview [authorization/v1]</a></LI>
-  <LI><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview [authorization/v1]</a></LI>
-  <LI><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#service-v1-core">Service [core/v1]</a></LI>
-  <LI><a href="#serviceaccount-v1-core">ServiceAccount [core/v1]</a></LI>
-  <LI><a href="#statefulset-v1-apps">StatefulSet [apps/v1]</a></LI>
-  <LI><a href="#storageclass-v1-storage-k8s-io">StorageClass [storage/v1]</a></LI>
-  <LI><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass [storage/v1beta1]</a></LI>
-  <LI><a href="#subjectaccessreview-v1-authorization-k8s-io">SubjectAccessReview [authorization/v1]</a></LI>
-  <LI><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#tokenrequest-v1-authentication-k8s-io">TokenRequest [authentication/v1]</a></LI>
-  <LI><a href="#tokenreview-v1-authentication-k8s-io">TokenReview [authentication/v1]</a></LI>
-  <LI><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview [authentication/v1beta1]</a></LI>
-  <LI><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration [admissionregistration/v1]</a></LI>
-  <LI><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#volumeattachment-v1-storage-k8s-io">VolumeAttachment [storage/v1]</a></LI>
-  <LI><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment [storage/v1beta1]</a></LI>
-  <LI><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>annotations</CODE><BR /><I>object</I></TD><TD>Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: http://kubernetes.io/docs/user-guide/annotations</TD></TR>
-<TR><TD><CODE>clusterName</CODE><BR /><I>string</I></TD><TD>The name of the cluster which the object belongs to. This is used to distinguish resources with same name and namespace in different clusters. This field is not set anywhere right now and apiserver is going to ignore it if set in create or update request.</TD></TR>
-<TR><TD><CODE>creationTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC.  Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>deletionGracePeriodSeconds</CODE><BR /><I>integer</I></TD><TD>Number of seconds allowed for this object to gracefully terminate before it will be removed from the system. Only set when deletionTimestamp is also set. May only be shortened. Read-only.</TD></TR>
-<TR><TD><CODE>deletionTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>DeletionTimestamp is RFC 3339 date and time at which this resource will be deleted. This field is set by the server when a graceful deletion is requested by the user, and is not directly settable by a client. The resource is expected to be deleted (no longer visible from resource lists, and not reachable by name) after the time in this field, once the finalizers list is empty. As long as the finalizers list contains items, deletion is blocked. Once the deletionTimestamp is set, this value may not be unset or be set further into the future, although it may be shortened or the resource may be deleted prior to this time. For example, a user may request that a pod is deleted in 30 seconds. The Kubelet will react by sending a graceful termination signal to the containers in the pod. After that 30 seconds, the Kubelet will send a hard termination signal (SIGKILL) to the container and after cleanup, remove the pod from the API. In the presence of network partitions, this object may still exist after this timestamp, until an administrator or automated process can determine the resource is fully terminated. If not set, graceful deletion of the object has not been requested.  Populated by the system when a graceful deletion is requested. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>finalizers</CODE><BR /><I>string array</I><BR /><B>patch strategy</B>: <I>merge</I></TD><TD>Must be empty before the object is deleted from the registry. Each entry is an identifier for the responsible component that will remove the entry from the list. If the deletionTimestamp of the object is non-nil, entries in this list can only be removed. Finalizers may be processed and removed in any order.  Order is NOT enforced because it introduces significant risk of stuck finalizers. finalizers is a shared field, any actor with permission can reorder it. If the finalizer list is processed in order, then this can lead to a situation in which the component responsible for the first finalizer in the list is waiting for a signal (field value, external system, or other) produced by a component responsible for a finalizer later in the list, resulting in a deadlock. Without enforced ordering finalizers are free to order amongst themselves and are not vulnerable to ordering changes in the list.</TD></TR>
-<TR><TD><CODE>generateName</CODE><BR /><I>string</I></TD><TD>GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.  If this field is specified and the generated name exists, the server will NOT return a 409 - instead, it will either return 201 Created or 500 with Reason ServerTimeout indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header).  Applied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency</TD></TR>
-<TR><TD><CODE>generation</CODE><BR /><I>integer</I></TD><TD>A sequence number representing a specific generation of the desired state. Populated by the system. Read-only.</TD></TR>
-<TR><TD><CODE>labels</CODE><BR /><I>object</I></TD><TD>Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: http://kubernetes.io/docs/user-guide/labels</TD></TR>
-<TR><TD><CODE>managedFields</CODE><BR /><I><a href="#managedfieldsentry-v1-meta">ManagedFieldsEntry</a> array</I></TD><TD>ManagedFields maps workflow-id and version to the set of fields that are managed by that workflow. This is mostly for internal housekeeping, and users typically shouldn&#39;t need to set or understand this field. A workflow can be the user&#39;s name, a controller&#39;s name, or the name of a specific apply path like &#34;ci-cd&#34;. The set of fields is always in the version that the workflow used when modifying the object.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace defines the space within each name must be unique. An empty namespace is equivalent to the &#34;default&#34; namespace, but &#34;default&#34; is the canonical representation. Not all objects are required to be scoped to a namespace - the value of this field for those objects will be empty.  Must be a DNS_LABEL. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/namespaces</TD></TR>
-<TR><TD><CODE>ownerReferences</CODE><BR /><I><a href="#ownerreference-v1-meta">OwnerReference</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>uid</I></TD><TD>List of objects depended by this object. If ALL objects in the list have been deleted, this object will be garbage collected. If this object is managed by a controller, then an entry in this list will point to this controller, with the controller field set to true. There cannot be more than one managing controller.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE><BR /><I>string</I></TD><TD>An opaque value that represents the internal version of this object that can be used by clients to determine when objects have changed. May be used for optimistic concurrency, change detection, and the watch operation on a resource or set of resources. Clients must treat these values as opaque and passed unmodified back to the server. They may only be valid for a particular resource or set of resources.  Populated by the system. Read-only. Value must be treated as opaque by clients and . More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency</TD></TR>
-<TR><TD><CODE>selfLink</CODE><BR /><I>string</I></TD><TD>SelfLink is a URL representing this object. Populated by the system. Read-only.  DEPRECATED Kubernetes will stop propagating this field in 1.20 release and the field is planned to be removed in 1.21 release.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID is the unique in time and space value for this object. It is typically generated by the server on successful creation of a resource and is not allowed to change on PUT operations.  Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-guide/identifiers#uids</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="objectmetricsource-v2beta2-autoscaling">ObjectMetricSource v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>ObjectMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ObjectMetricSource indicates how to scale on a metric describing a kubernetes object (for example, hits-per-second on an Ingress object).</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#objectmetricsource-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta2-autoscaling">MetricSpec [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>describedObject</CODE><BR /><I><a href="#crossversionobjectreference-v2beta2-autoscaling">CrossVersionObjectReference</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>metric</CODE><BR /><I><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier</a></I></TD><TD>metric identifies the target metric by name and selector</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#metrictarget-v2beta2-autoscaling">MetricTarget</a></I></TD><TD>target specifies the target value for the given metric</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="objectmetricstatus-v2beta2-autoscaling">ObjectMetricStatus v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>ObjectMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ObjectMetricStatus indicates the current value of a metric describing a kubernetes object (for example, hits-per-second on an Ingress object).</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#objectmetricstatus-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta2-autoscaling">MetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>current</CODE><BR /><I><a href="#metricvaluestatus-v2beta2-autoscaling">MetricValueStatus</a></I></TD><TD>current contains the current value for the given metric</TD></TR>
-<TR><TD><CODE>describedObject</CODE><BR /><I><a href="#crossversionobjectreference-v2beta2-autoscaling">CrossVersionObjectReference</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>metric</CODE><BR /><I><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier</a></I></TD><TD>metric identifies the target metric by name and selector</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="objectreference-v1-core">ObjectReference v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ObjectReference contains enough information to let you inspect or modify the referred object.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#binding-v1-core">Binding [core/v1]</a></LI>
-  <LI><a href="#cronjobstatus-v1beta1-batch">CronJobStatus [batch/v1beta1]</a></LI>
-  <LI><a href="#cronjobstatus-v2alpha1-batch">CronJobStatus [batch/v2alpha1]</a></LI>
-  <LI><a href="#endpoint-v1beta1-discovery-k8s-io">Endpoint [discovery/v1beta1]</a></LI>
-  <LI><a href="#endpointaddress-v1-core">EndpointAddress [core/v1]</a></LI>
-  <LI><a href="#event-v1-core">Event [core/v1]</a></LI>
-  <LI><a href="#event-v1beta1-events-k8s-io">Event [events/v1beta1]</a></LI>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#serviceaccount-v1-core">ServiceAccount [core/v1]</a></LI>
-  <LI><a href="#storageospersistentvolumesource-v1-core">StorageOSPersistentVolumeSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>API version of the referent.</TD></TR>
-<TR><TD><CODE>fieldPath</CODE><BR /><I>string</I></TD><TD>If referring to a piece of an object instead of an entire object, this string should contain a valid JSON/Go field access statement, such as desiredState.manifest.containers[2]. For example, if the object reference is to a container within a pod, this would take on a value like: &#34;spec.containers{name}&#34; (where &#34;name&#34; refers to the name of the container that triggered the event) or if no container name is specified &#34;spec.containers[2]&#34; (container with index 2 in this pod). This syntax is chosen only to have some well-defined way of referencing a part of an object.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE><BR /><I>string</I></TD><TD>Specific resourceVersion to which this reference is made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="overhead-v1beta1-node-k8s-io">Overhead v1beta1 node.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Overhead</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Overhead structure represents the resource overhead associated with running a pod.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#overhead-v1alpha1-node-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass [node/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>podFixed</CODE><BR /><I>object</I></TD><TD>PodFixed represents the fixed resource overhead associated with running a pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="ownerreference-v1-meta">OwnerReference v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>OwnerReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>OwnerReference contains enough information to let you identify an owning object. An owning object must be in the same namespace as the dependent, or be cluster-scoped, so there is no namespace field.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#objectmeta-v1-meta">ObjectMeta [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>API version of the referent.</TD></TR>
-<TR><TD><CODE>blockOwnerDeletion</CODE><BR /><I>boolean</I></TD><TD>If true, AND if the owner has the &#34;foregroundDeletion&#34; finalizer, then the owner cannot be deleted from the key-value store until this reference is removed. Defaults to false. To set this field, a user needs &#34;delete&#34; permission of the owner, otherwise 422 (Unprocessable Entity) will be returned.</TD></TR>
-<TR><TD><CODE>controller</CODE><BR /><I>boolean</I></TD><TD>If true, this reference points to the managing controller.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#names</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#uids</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-v1-meta">Patch v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Patch</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Patch is provided to give a concrete name and type to the Kubernetes PATCH request body.</P>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="persistentvolumeclaimcondition-v1-core">PersistentVolumeClaimCondition v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PersistentVolumeClaimCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PersistentVolumeClaimCondition contails details about state of pvc</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumeclaimstatus-v1-core">PersistentVolumeClaimStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastProbeTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time we probed the condition.</TD></TR>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Unique, this should be a short, machine understandable string that gives the reason for condition&#39;s last transition. If it reports &#34;ResizeStarted&#34; that means the underlying persistent volume is being resized.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="persistentvolumeclaimvolumesource-v1-core">PersistentVolumeClaimVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PersistentVolumeClaimVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PersistentVolumeClaimVolumeSource references the user&#39;s PVC in the same namespace. This volume finds the bound PV and mounts that volume for the pod. A PersistentVolumeClaimVolumeSource is, essentially, a wrapper around another type of volume that is owned by someone else (the system).</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>claimName</CODE><BR /><I>string</I></TD><TD>ClaimName is the name of a PersistentVolumeClaim in the same namespace as the pod using this volume. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Will force the ReadOnly setting in VolumeMounts. Default false.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="photonpersistentdiskvolumesource-v1-core">PhotonPersistentDiskVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PhotonPersistentDiskVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Photon Controller persistent disk resource.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>pdID</CODE><BR /><I>string</I></TD><TD>ID that identifies Photon Controller persistent disk</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podaffinity-v1-core">PodAffinity v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodAffinity</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Pod affinity is a group of inter pod affinity scheduling rules.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#affinity-v1-core">Affinity [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>preferredDuringSchedulingIgnoredDuringExecution</CODE><BR /><I><a href="#weightedpodaffinityterm-v1-core">WeightedPodAffinityTerm</a> array</I></TD><TD>The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding &#34;weight&#34; to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.</TD></TR>
-<TR><TD><CODE>requiredDuringSchedulingIgnoredDuringExecution</CODE><BR /><I><a href="#podaffinityterm-v1-core">PodAffinityTerm</a> array</I></TD><TD>If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podaffinityterm-v1-core">PodAffinityTerm v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodAffinityTerm</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key &lt;topologyKey&gt; matches that of any node on which a pod of the set of pods is running</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podaffinity-v1-core">PodAffinity [core/v1]</a></LI>
-  <LI><a href="#podantiaffinity-v1-core">PodAntiAffinity [core/v1]</a></LI>
-  <LI><a href="#weightedpodaffinityterm-v1-core">WeightedPodAffinityTerm [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>labelSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>A label query over a set of resources, in this case pods.</TD></TR>
-<TR><TD><CODE>namespaces</CODE><BR /><I>string array</I></TD><TD>namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means &#34;this pod&#39;s namespace&#34;</TD></TR>
-<TR><TD><CODE>topologyKey</CODE><BR /><I>string</I></TD><TD>This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podantiaffinity-v1-core">PodAntiAffinity v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodAntiAffinity</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Pod anti affinity is a group of inter pod anti affinity scheduling rules.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#affinity-v1-core">Affinity [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>preferredDuringSchedulingIgnoredDuringExecution</CODE><BR /><I><a href="#weightedpodaffinityterm-v1-core">WeightedPodAffinityTerm</a> array</I></TD><TD>The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding &#34;weight&#34; to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred.</TD></TR>
-<TR><TD><CODE>requiredDuringSchedulingIgnoredDuringExecution</CODE><BR /><I><a href="#podaffinityterm-v1-core">PodAffinityTerm</a> array</I></TD><TD>If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podcondition-v1-core">PodCondition v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodCondition contains details for the current condition of this pod.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podstatus-v1-core">PodStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastProbeTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time we probed the condition.</TD></TR>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status is the status of the condition. Can be True, False, Unknown. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type is the type of the condition. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-conditions</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="poddnsconfig-v1-core">PodDNSConfig v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodDNSConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodDNSConfig defines the DNS parameters of a pod in addition to those generated from DNSPolicy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nameservers</CODE><BR /><I>string array</I></TD><TD>A list of DNS name server IP addresses. This will be appended to the base nameservers generated from DNSPolicy. Duplicated nameservers will be removed.</TD></TR>
-<TR><TD><CODE>options</CODE><BR /><I><a href="#poddnsconfigoption-v1-core">PodDNSConfigOption</a> array</I></TD><TD>A list of DNS resolver options. This will be merged with the base options generated from DNSPolicy. Duplicated entries will be removed. Resolution options given in Options will override those that appear in the base DNSPolicy.</TD></TR>
-<TR><TD><CODE>searches</CODE><BR /><I>string array</I></TD><TD>A list of DNS search domains for host-name lookup. This will be appended to the base search paths generated from DNSPolicy. Duplicated search paths will be removed.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="poddnsconfigoption-v1-core">PodDNSConfigOption v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodDNSConfigOption</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodDNSConfigOption defines DNS resolver options of a pod.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#poddnsconfig-v1-core">PodDNSConfig [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Required.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>string</I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podip-v1-core">PodIP v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodIP</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>IP address information for entries in the (plural) PodIPs field. Each entry includes:
-   IP: An IP address allocated to the pod. Routable at least within the cluster.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podstatus-v1-core">PodStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ip</CODE><BR /><I>string</I></TD><TD>ip is an IP address (IPv4 or IPv6) assigned to the pod</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podreadinessgate-v1-core">PodReadinessGate v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodReadinessGate</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodReadinessGate contains the reference to a pod condition</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditionType</CODE><BR /><I>string</I></TD><TD>ConditionType refers to a condition in the pod&#39;s condition list with matching type.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podsecuritycontext-v1-core">PodSecurityContext v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PodSecurityContext</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodSecurityContext holds pod-level security attributes and common container settings. Some fields are also present in container.securityContext.  Field values of container.securityContext take precedence over field values of PodSecurityContext.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsGroup</CODE><BR /><I>integer</I></TD><TD>A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod:  1. The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR&#39;d with rw-rw----  If unset, the Kubelet will not modify the ownership and permissions of any volume.</TD></TR>
-<TR><TD><CODE>fsGroupChangePolicy</CODE><BR /><I>string</I></TD><TD>fsGroupChangePolicy defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are &#34;OnRootMismatch&#34; and &#34;Always&#34;. If not specified defaults to &#34;Always&#34;.</TD></TR>
-<TR><TD><CODE>runAsGroup</CODE><BR /><I>integer</I></TD><TD>The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in SecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.</TD></TR>
-<TR><TD><CODE>runAsNonRoot</CODE><BR /><I>boolean</I></TD><TD>Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-<TR><TD><CODE>runAsUser</CODE><BR /><I>integer</I></TD><TD>The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in SecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.</TD></TR>
-<TR><TD><CODE>seLinuxOptions</CODE><BR /><I><a href="#selinuxoptions-v1-core">SELinuxOptions</a></I></TD><TD>The SELinux context to be applied to all containers. If unspecified, the container runtime will allocate a random SELinux context for each container.  May also be set in SecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container.</TD></TR>
-<TR><TD><CODE>supplementalGroups</CODE><BR /><I>integer array</I></TD><TD>A list of groups applied to the first process run in each container, in addition to the container&#39;s primary GID.  If unspecified, no groups will be added to any container.</TD></TR>
-<TR><TD><CODE>sysctls</CODE><BR /><I><a href="#sysctl-v1-core">Sysctl</a> array</I></TD><TD>Sysctls hold a list of namespaced sysctls used for the pod. Pods with unsupported sysctls (by the container runtime) might fail to launch.</TD></TR>
-<TR><TD><CODE>windowsOptions</CODE><BR /><I><a href="#windowssecuritycontextoptions-v1-core">WindowsSecurityContextOptions</a></I></TD><TD>The Windows specific settings applied to all containers. If unspecified, the options within a container&#39;s SecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podsmetricsource-v2beta2-autoscaling">PodsMetricSource v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>PodsMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodsMetricSource indicates how to scale on a metric describing each pod in the current scale target (for example, transactions-processed-per-second). The values will be averaged together before being compared to the target value.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#podsmetricsource-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta2-autoscaling">MetricSpec [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metric</CODE><BR /><I><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier</a></I></TD><TD>metric identifies the target metric by name and selector</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#metrictarget-v2beta2-autoscaling">MetricTarget</a></I></TD><TD>target specifies the target value for the given metric</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="podsmetricstatus-v2beta2-autoscaling">PodsMetricStatus v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>PodsMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PodsMetricStatus indicates the current value of a metric describing each pod in the current scale target (for example, transactions-processed-per-second).</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#podsmetricstatus-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta2-autoscaling">MetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>current</CODE><BR /><I><a href="#metricvaluestatus-v2beta2-autoscaling">MetricValueStatus</a></I></TD><TD>current contains the current value for the given metric</TD></TR>
-<TR><TD><CODE>metric</CODE><BR /><I><a href="#metricidentifier-v2beta2-autoscaling">MetricIdentifier</a></I></TD><TD>metric identifies the target metric by name and selector</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="policy-v1alpha1-auditregistration-k8s-io">Policy v1alpha1 auditregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>auditregistration.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Policy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Policy defines the configuration of how audit events are logged</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#auditsinkspec-v1alpha1-auditregistration-k8s-io">AuditSinkSpec [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>level</CODE><BR /><I>string</I></TD><TD>The Level that all requests are recorded at. available options: None, Metadata, Request, RequestResponse required</TD></TR>
-<TR><TD><CODE>stages</CODE><BR /><I>string array</I></TD><TD>Stages is a list of stages for which events are created.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="policyrule-v1-rbac-authorization-k8s-io">PolicyRule v1 rbac.authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PolicyRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PolicyRule holds information that describes a policy rule, but does not contain information about who the rule applies to or which namespace the rule applies to.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#policyrule-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#policyrule-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrole-v1-rbac-authorization-k8s-io">ClusterRole [rbac/v1]</a></LI>
-  <LI><a href="#role-v1-rbac-authorization-k8s-io">Role [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the name of the APIGroup that contains the resources.  If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed.</TD></TR>
-<TR><TD><CODE>nonResourceURLs</CODE><BR /><I>string array</I></TD><TD>NonResourceURLs is a set of partial urls that a user should have access to.  *s are allowed, but only as the full, final step in the path Since non-resource URLs are not namespaced, this field is only applicable for ClusterRoles referenced from a ClusterRoleBinding. Rules can either apply to API resources (such as &#34;pods&#34; or &#34;secrets&#34;) or non-resource URL paths (such as &#34;/api&#34;),  but not both.</TD></TR>
-<TR><TD><CODE>resourceNames</CODE><BR /><I>string array</I></TD><TD>ResourceNames is an optional white list of names that the rule applies to.  An empty set means that everything is allowed.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  ResourceAll represents all resources.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule.  VerbAll represents all kinds.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io">PolicyRulesWithSubjects v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PolicyRulesWithSubjects</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PolicyRulesWithSubjects prescribes a test that applies to a request to an apiserver. The test considers the subject making the request, the verb being requested, and the resource to be acted upon. This PolicyRulesWithSubjects matches a request if and only if both (a) at least one member of subjects matches the request and (b) at least one member of resourceRules or nonResourceRules matches the request.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschemaspec-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaSpec [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nonResourceRules</CODE><BR /><I><a href="#nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io">NonResourcePolicyRule</a> array</I></TD><TD>`nonResourceRules` is a list of NonResourcePolicyRules that identify matching requests according to their verb and the target non-resource URL.</TD></TR>
-<TR><TD><CODE>resourceRules</CODE><BR /><I><a href="#resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io">ResourcePolicyRule</a> array</I></TD><TD>`resourceRules` is a slice of ResourcePolicyRules that identify matching requests according to their verb and the target resource. At least one of `resourceRules` and `nonResourceRules` has to be non-empty.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io">Subject</a> array</I></TD><TD>subjects is the list of normal user, serviceaccount, or group that this rule cares about. There must be at least one member in this slice. A slice that includes both the system:authenticated and system:unauthenticated user groups matches every request. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="portworxvolumesource-v1-core">PortworxVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PortworxVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PortworxVolumeSource represents a Portworx volume resource.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>FSType represents the filesystem type to mount Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>volumeID</CODE><BR /><I>string</I></TD><TD>VolumeID uniquely identifies a Portworx volume</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="preconditions-v1-meta">Preconditions v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Preconditions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Preconditions must be fulfilled before an operation (update, delete, etc.) is carried out.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#deleteoptions-v1-meta">DeleteOptions [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>resourceVersion</CODE><BR /><I>string</I></TD><TD>Specifies the target ResourceVersion</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>Specifies the target UID.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="preferredschedulingterm-v1-core">PreferredSchedulingTerm v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>PreferredSchedulingTerm</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it&#39;s a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodeaffinity-v1-core">NodeAffinity [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>preference</CODE><BR /><I><a href="#nodeselectorterm-v1-core">NodeSelectorTerm</a></I></TD><TD>A node selector term, associated with the corresponding weight.</TD></TR>
-<TR><TD><CODE>weight</CODE><BR /><I>integer</I></TD><TD>Weight associated with matching the corresponding nodeSelectorTerm, in the range 1-100.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationCondition v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PriorityLevelConfigurationCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PriorityLevelConfigurationCondition defines the condition of priority level.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#prioritylevelconfigurationstatus-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationStatus [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>`lastTransitionTime` is the last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>`message` is a human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>`reason` is a unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>`status` is the status of the condition. Can be True, False, Unknown. Required.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>`type` is the type of the condition. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationReference v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PriorityLevelConfigurationReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>PriorityLevelConfigurationReference contains information that points to the &#34;request-priority&#34; being used.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#flowschemaspec-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaSpec [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>`name` is the name of the priority level configuration being referenced Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="probe-v1-core">Probe v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Probe</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>exec</CODE><BR /><I><a href="#execaction-v1-core">ExecAction</a></I></TD><TD>One and only one of the following should be specified. Exec specifies the action to take.</TD></TR>
-<TR><TD><CODE>failureThreshold</CODE><BR /><I>integer</I></TD><TD>Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1.</TD></TR>
-<TR><TD><CODE>httpGet</CODE><BR /><I><a href="#httpgetaction-v1-core">HTTPGetAction</a></I></TD><TD>HTTPGet specifies the http request to perform.</TD></TR>
-<TR><TD><CODE>initialDelaySeconds</CODE><BR /><I>integer</I></TD><TD>Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
-<TR><TD><CODE>periodSeconds</CODE><BR /><I>integer</I></TD><TD>How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1.</TD></TR>
-<TR><TD><CODE>successThreshold</CODE><BR /><I>integer</I></TD><TD>Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1.</TD></TR>
-<TR><TD><CODE>tcpSocket</CODE><BR /><I><a href="#tcpsocketaction-v1-core">TCPSocketAction</a></I></TD><TD>TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE><BR /><I>integer</I></TD><TD>Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="projectedvolumesource-v1-core">ProjectedVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ProjectedVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a projected volume source</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>defaultMode</CODE><BR /><I>integer</I></TD><TD>Mode bits to use on created files by default. Must be a value between 0 and 0777. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.</TD></TR>
-<TR><TD><CODE>sources</CODE><BR /><I><a href="#volumeprojection-v1-core">VolumeProjection</a> array</I></TD><TD>list of volume projections</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="quantity-resource-core">Quantity resource core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>resource</CODE></TD><TD><CODE>Quantity</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Quantity is a fixed-point representation of a number. It provides convenient marshaling/unmarshaling in JSON and YAML, in addition to String() and AsInt64() accessors.
-
-The serialization format is:
-
-&lt;quantity&gt;        ::= &lt;signedNumber&gt;&lt;suffix&gt;
-  (Note that &lt;suffix&gt; may be empty, from the &#34;&#34; case in &lt;decimalSI&gt;.)
-&lt;digit&gt;           ::= 0 | 1 | ... | 9 &lt;digits&gt;          ::= &lt;digit&gt; | &lt;digit&gt;&lt;digits&gt; &lt;number&gt;          ::= &lt;digits&gt; | &lt;digits&gt;.&lt;digits&gt; | &lt;digits&gt;. | .&lt;digits&gt; &lt;sign&gt;            ::= &#34;+&#34; | &#34;-&#34; &lt;signedNumber&gt;    ::= &lt;number&gt; | &lt;sign&gt;&lt;number&gt; &lt;suffix&gt;          ::= &lt;binarySI&gt; | &lt;decimalExponent&gt; | &lt;decimalSI&gt; &lt;binarySI&gt;        ::= Ki | Mi | Gi | Ti | Pi | Ei
-  (International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)
-&lt;decimalSI&gt;       ::= m | &#34;&#34; | k | M | G | T | P | E
-  (Note that 1024 = 1Ki but 1000 = 1k; I didn&#39;t choose the capitalization.)
-&lt;decimalExponent&gt; ::= &#34;e&#34; &lt;signedNumber&gt; | &#34;E&#34; &lt;signedNumber&gt;
-
-No matter which of the three exponent forms is used, no quantity may represent a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal places. Numbers larger or more precise will be capped or rounded up. (E.g.: 0.1m will rounded up to 1m.) This may be extended in the future if we require larger or smaller quantities.
-
-When a Quantity is parsed from a string, it will remember the type of suffix it had, and will use the same type again when it is serialized.
-
-Before serializing, Quantity will be put in &#34;canonical form&#34;. This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that:
-  a. No precision is lost
-  b. No fractional digits will be emitted
-  c. The exponent (or suffix) is as large as possible.
-The sign will be omitted unless the number is negative.
-
-Examples:
-  1.5 will be serialized as &#34;1500m&#34;
-  1.5Gi will be serialized as &#34;1536Mi&#34;
-
-Note that the quantity will NEVER be internally represented by a floating point number. That is the whole point of this exercise.
-
-Non-canonical values will still parse as long as they are well formed, but will be re-emitted in their canonical form. (So always use canonical form, or don&#39;t diff.)
-
-This format is intended to make it difficult to use these numbers without writing some sort of special handling code in the hopes that that will cause implementors to also use a fixed point implementation.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#emptydirvolumesource-v1-core">EmptyDirVolumeSource [core/v1]</a></LI>
-  <LI><a href="#externalmetricsource-v2beta1-autoscaling">ExternalMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#externalmetricstatus-v2beta1-autoscaling">ExternalMetricStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#metrictarget-v2beta2-autoscaling">MetricTarget [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#metricvaluestatus-v2beta2-autoscaling">MetricValueStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricsource-v2beta1-autoscaling">ObjectMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#objectmetricstatus-v2beta1-autoscaling">ObjectMetricStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#podsmetricsource-v2beta1-autoscaling">PodsMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#podsmetricstatus-v2beta1-autoscaling">PodsMetricStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#resourcefieldselector-v1-core">ResourceFieldSelector [core/v1]</a></LI>
-  <LI><a href="#resourcemetricsource-v2beta1-autoscaling">ResourceMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#resourcemetricstatus-v2beta1-autoscaling">ResourceMetricStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io">QueuingConfiguration v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>QueuingConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>QueuingConfiguration holds the configuration parameters for queuing</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io">LimitResponse [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>handSize</CODE><BR /><I>integer</I></TD><TD>`handSize` is a small positive number that configures the shuffle sharding of requests into queues.  When enqueuing a request at this priority level the request&#39;s flow identifier (a string pair) is hashed and the hash value is used to shuffle the list of queues and deal a hand of the size specified here.  The request is put into one of the shortest queues in that hand. `handSize` must be no larger than `queues`, and should be significantly smaller (so that a few heavy flows do not saturate most of the queues).  See the user-facing documentation for more extensive guidance on setting this field.  This field has a default value of 8.</TD></TR>
-<TR><TD><CODE>queueLengthLimit</CODE><BR /><I>integer</I></TD><TD>`queueLengthLimit` is the maximum number of requests allowed to be waiting in a given queue of this priority level at a time; excess requests are rejected.  This value must be positive.  If not specified, it will be defaulted to 50.</TD></TR>
-<TR><TD><CODE>queues</CODE><BR /><I>integer</I></TD><TD>`queues` is the number of queues for this priority level. The queues exist independently at each apiserver. The value must be positive.  Setting it to 1 effectively precludes shufflesharding and thus makes the distinguisher method of associated flow schemas irrelevant.  This field has a default value of 64.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="quobytevolumesource-v1-core">QuobyteVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>QuobyteVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Quobyte mount that lasts the lifetime of a pod. Quobyte volumes do not support ownership management or SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>Group to map volume access to Default is no group</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the Quobyte volume to be mounted with read-only permissions. Defaults to false.</TD></TR>
-<TR><TD><CODE>registry</CODE><BR /><I>string</I></TD><TD>Registry represents a single or multiple Quobyte Registry services specified as a string as host:port pair (multiple entries are separated with commas) which acts as the central registry for volumes</TD></TR>
-<TR><TD><CODE>tenant</CODE><BR /><I>string</I></TD><TD>Tenant owning the given Quobyte volume in the Backend Used with dynamically provisioned Quobyte volumes, value is set by the plugin</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>User to map volume access to Defaults to serivceaccount user</TD></TR>
-<TR><TD><CODE>volume</CODE><BR /><I>string</I></TD><TD>Volume is a string that references an already created Quobyte volume by name.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="rbdpersistentvolumesource-v1-core">RBDPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>RBDPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Rados Block Device mount that lasts the lifetime of a pod. RBD volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#rbd</TD></TR>
-<TR><TD><CODE>image</CODE><BR /><I>string</I></TD><TD>The rados image name. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>keyring</CODE><BR /><I>string</I></TD><TD>Keyring is the path to key ring for RBDUser. Default is /etc/ceph/keyring. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>monitors</CODE><BR /><I>string array</I></TD><TD>A collection of Ceph monitors. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>pool</CODE><BR /><I>string</I></TD><TD>The rados pool name. Default is rbd. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>SecretRef is name of the authentication secret for RBDUser. If provided overrides keyring. Default is nil. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>The rados user name. Default is admin. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="rbdvolumesource-v1-core">RBDVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>RBDVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a Rados Block Device mount that lasts the lifetime of a pod. RBD volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#rbd</TD></TR>
-<TR><TD><CODE>image</CODE><BR /><I>string</I></TD><TD>The rados image name. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>keyring</CODE><BR /><I>string</I></TD><TD>Keyring is the path to key ring for RBDUser. Default is /etc/ceph/keyring. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>monitors</CODE><BR /><I>string array</I></TD><TD>A collection of Ceph monitors. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>pool</CODE><BR /><I>string</I></TD><TD>The rados pool name. Default is rbd. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>SecretRef is name of the authentication secret for RBDUser. If provided overrides keyring. Default is nil. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>The rados user name. Default is admin. More info: https://examples.k8s.io/volumes/rbd/README.md#how-to-use-it</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replicasetcondition-v1-apps">ReplicaSetCondition v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ReplicaSetCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ReplicaSetCondition describes the state of a replica set at a certain point.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicasetstatus-v1-apps">ReplicaSetStatus [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>The last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human readable message indicating details about the transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>The reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of replica set condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replicationcontrollercondition-v1-core">ReplicationControllerCondition v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ReplicationControllerCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ReplicationControllerCondition describes the state of a replication controller at a certain point.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#replicationcontrollerstatus-v1-core">ReplicationControllerStatus [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>The last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human readable message indicating details about the transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>The reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of replication controller condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourceattributes-v1-authorization-k8s-io">ResourceAttributes v1 authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ResourceAttributes</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourceAttributes includes the authorization attributes available for resource requests to the Authorizer interface</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourceattributes-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectaccessreviewspec-v1-authorization-k8s-io">SelfSubjectAccessReviewSpec [authorization/v1]</a></LI>
-  <LI><a href="#subjectaccessreviewspec-v1-authorization-k8s-io">SubjectAccessReviewSpec [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>Group is the API Group of the Resource.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of the resource being requested for a &#34;get&#34; or deleted for a &#34;delete&#34;. &#34;&#34; (empty) means all.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace is the namespace of the action being requested.  Currently, there is no distinction between no namespace and all namespaces &#34;&#34; (empty) is defaulted for LocalSubjectAccessReviews &#34;&#34; (empty) is empty for cluster-scoped resources &#34;&#34; (empty) means &#34;all&#34; for namespace scoped resources from a SubjectAccessReview or SelfSubjectAccessReview</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I>string</I></TD><TD>Resource is one of the existing resource types.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>subresource</CODE><BR /><I>string</I></TD><TD>Subresource is one of the existing resource types.  &#34;&#34; means none.</TD></TR>
-<TR><TD><CODE>verb</CODE><BR /><I>string</I></TD><TD>Verb is a kubernetes resource API verb, like: get, list, watch, create, update, delete, proxy.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>Version is the API Version of the Resource.  &#34;*&#34; means all.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourcefieldselector-v1-core">ResourceFieldSelector v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ResourceFieldSelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourceFieldSelector represents container resources (cpu, memory) and their output format</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#downwardapivolumefile-v1-core">DownwardAPIVolumeFile [core/v1]</a></LI>
-  <LI><a href="#envvarsource-v1-core">EnvVarSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>containerName</CODE><BR /><I>string</I></TD><TD>Container name: required for volumes, optional for env vars</TD></TR>
-<TR><TD><CODE>divisor</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>Specifies the output format of the exposed resources, defaults to &#34;1&#34;</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I>string</I></TD><TD>Required: resource to select</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourcemetricsource-v2beta2-autoscaling">ResourceMetricSource v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>ResourceMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourceMetricSource indicates how to scale on a resource metric known to Kubernetes, as specified in requests and limits, describing each pod in the current scale target (e.g. CPU or memory).  The values will be averaged together before being compared to the target.  Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the &#34;pods&#34; source.  Only one &#34;target&#34; type should be set.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourcemetricsource-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta2-autoscaling">MetricSpec [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the resource in question.</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#metrictarget-v2beta2-autoscaling">MetricTarget</a></I></TD><TD>target specifies the target value for the given metric</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourcemetricstatus-v2beta2-autoscaling">ResourceMetricStatus v2beta2 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>ResourceMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourceMetricStatus indicates the current value of a resource metric known to Kubernetes, as specified in requests and limits, describing each pod in the current scale target (e.g. CPU or memory).  Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the &#34;pods&#34; source.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourcemetricstatus-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta2-autoscaling">MetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>current</CODE><BR /><I><a href="#metricvaluestatus-v2beta2-autoscaling">MetricValueStatus</a></I></TD><TD>current contains the current value for the given metric</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of the resource in question.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io">ResourcePolicyRule v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>ResourcePolicyRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourcePolicyRule is a predicate that matches some resource requests, testing the request&#39;s verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) least one member of namespaces matches the request.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io">PolicyRulesWithSubjects [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>`apiGroups` is a list of matching API groups and may not be empty. &#34;*&#34; matches all API groups and, if present, must be the only entry. Required.</TD></TR>
-<TR><TD><CODE>clusterScope</CODE><BR /><I>boolean</I></TD><TD>`clusterScope` indicates whether to match requests that do not specify a namespace (which happens either because the resource is not namespaced or the request targets all namespaces). If this field is omitted or false then the `namespaces` field must contain a non-empty list.</TD></TR>
-<TR><TD><CODE>namespaces</CODE><BR /><I>string array</I></TD><TD>`namespaces` is a list of target namespaces that restricts matches.  A request that specifies a target namespace matches only if either (a) this list contains that target namespace or (b) this list contains &#34;*&#34;.  Note that &#34;*&#34; matches any specified namespace but does not match a request that _does not specify_ a namespace (see the `clusterScope` field for that). This list may be empty, but only if `clusterScope` is true.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>`resources` is a list of matching resources (i.e., lowercase and plural) with, if desired, subresource.  For example, [ &#34;services&#34;, &#34;nodes/status&#34; ].  This list may not be empty. &#34;*&#34; matches all resources and, if present, must be the only entry. Required.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>`verbs` is a list of matching verbs and may not be empty. &#34;*&#34; matches all verbs and, if present, must be the only entry. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourcerequirements-v1-core">ResourceRequirements v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ResourceRequirements</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourceRequirements describes the compute resource requirements.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
-  <LI><a href="#persistentvolumeclaimspec-v1-core">PersistentVolumeClaimSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>limits</CODE><BR /><I>object</I></TD><TD>Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/</TD></TR>
-<TR><TD><CODE>requests</CODE><BR /><I>object</I></TD><TD>Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="resourcerule-v1-authorization-k8s-io">ResourceRule v1 authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ResourceRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ResourceRule is the list of actions the subject is allowed to perform on resources. The list ordering isn&#39;t significant, may contain duplicates, and possibly be incomplete.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourcerule-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subjectrulesreviewstatus-v1-authorization-k8s-io">SubjectRulesReviewStatus [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the name of the APIGroup that contains the resources.  If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>resourceNames</CODE><BR /><I>string array</I></TD><TD>ResourceNames is an optional white list of names that the rule applies to.  An empty set means that everything is allowed.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  &#34;*&#34; means all in the specified apiGroups.  &#34;*/foo&#34; represents the subresource &#39;foo&#39; for all resources in the specified apiGroups.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verb is a list of kubernetes resource API verbs, like: get, list, watch, create, update, delete, proxy.  &#34;*&#34; means all.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="roleref-v1-rbac-authorization-k8s-io">RoleRef v1 rbac.authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>RoleRef</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>RoleRef contains information that points to the role being used</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#roleref-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#roleref-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1]</a></LI>
-  <LI><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroup</CODE><BR /><I>string</I></TD><TD>APIGroup is the group for the resource being referenced</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is the type of resource being referenced</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of resource being referenced</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="rollingupdatestatefulsetstrategy-v1-apps">RollingUpdateStatefulSetStrategy v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>RollingUpdateStatefulSetStrategy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>RollingUpdateStatefulSetStrategy is used to communicate parameter for RollingUpdateStatefulSetStrategyType.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statefulsetupdatestrategy-v1-apps">StatefulSetUpdateStrategy [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>partition</CODE><BR /><I>integer</I></TD><TD>Partition indicates the ordinal at which the StatefulSet should be partitioned. Default value is 0.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="rulewithoperations-v1-admissionregistration-k8s-io">RuleWithOperations v1 admissionregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>RuleWithOperations</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>RuleWithOperations is a tuple of Operations and Resources. It is recommended to make sure that all the tuple expansions are valid.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#rulewithoperations-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhook-v1-admissionregistration-k8s-io">MutatingWebhook [admissionregistration/v1]</a></LI>
-  <LI><a href="#validatingwebhook-v1-admissionregistration-k8s-io">ValidatingWebhook [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the API groups the resources belong to. &#39;\*&#39; is all groups. If &#39;\*&#39; is present, the length of the slice must be one. Required.</TD></TR>
-<TR><TD><CODE>apiVersions</CODE><BR /><I>string array</I></TD><TD>APIVersions is the API versions the resources belong to. &#39;\*&#39; is all versions. If &#39;\*&#39; is present, the length of the slice must be one. Required.</TD></TR>
-<TR><TD><CODE>operations</CODE><BR /><I>string array</I></TD><TD>Operations is the operations the admission hook cares about - CREATE, UPDATE, or * for all operations. If &#39;\*&#39; is present, the length of the slice must be one. Required.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  For example: &#39;pods&#39; means pods. &#39;pods/log&#39; means the log subresource of pods. &#39;\*&#39; means all resources, but not subresources. &#39;pods/\*&#39; means all subresources of pods. &#39;\*/scale&#39; means all scale subresources. &#39;\*/\*&#39; means all resources and their subresources.  If wildcard is present, the validation rule will ensure resources do not overlap with each other.  Depending on the enclosing object, subresources might not be allowed. Required.</TD></TR>
-<TR><TD><CODE>scope</CODE><BR /><I>string</I></TD><TD>scope specifies the scope of this rule. Valid values are &#34;Cluster&#34;, &#34;Namespaced&#34;, and &#34;*&#34; &#34;Cluster&#34; means that only cluster-scoped resources will match this rule. Namespace API objects are cluster-scoped. &#34;Namespaced&#34; means that only namespaced resources will match this rule. &#34;*&#34; means that there are no scope restrictions. Subresources match the scope of their parent resource. Default is &#34;*&#34;.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="runasgroupstrategyoptions-v1beta1-policy">RunAsGroupStrategyOptions v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RunAsGroupStrategyOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>RunAsGroupStrategyOptions defines the strategy type and any options used to create the strategy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ranges</CODE><BR /><I><a href="#idrange-v1beta1-policy">IDRange</a> array</I></TD><TD>ranges are the allowed ranges of gids that may be used. If you would like to force a single gid then supply a single range with the same start and end. Required for MustRunAs.</TD></TR>
-<TR><TD><CODE>rule</CODE><BR /><I>string</I></TD><TD>rule is the strategy that will dictate the allowable RunAsGroup values that may be set.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="runasuserstrategyoptions-v1beta1-policy">RunAsUserStrategyOptions v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RunAsUserStrategyOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>RunAsUserStrategyOptions defines the strategy type and any options used to create the strategy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ranges</CODE><BR /><I><a href="#idrange-v1beta1-policy">IDRange</a> array</I></TD><TD>ranges are the allowed ranges of uids that may be used. If you would like to force a single uid then supply a single range with the same start and end. Required for MustRunAs.</TD></TR>
-<TR><TD><CODE>rule</CODE><BR /><I>string</I></TD><TD>rule is the strategy that will dictate the allowable RunAsUser values that may be set.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="runtimeclassstrategyoptions-v1beta1-policy">RuntimeClassStrategyOptions v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RuntimeClassStrategyOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>RuntimeClassStrategyOptions define the strategy that will dictate the allowable RuntimeClasses for a pod.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowedRuntimeClassNames</CODE><BR /><I>string array</I></TD><TD>allowedRuntimeClassNames is a whitelist of RuntimeClass names that may be specified on a pod. A value of &#34;*&#34; means that any RuntimeClass name is allowed, and must be the only item in the list. An empty list requires the RuntimeClassName field to be unset.</TD></TR>
-<TR><TD><CODE>defaultRuntimeClassName</CODE><BR /><I>string</I></TD><TD>defaultRuntimeClassName is the default RuntimeClassName to set on the pod. The default MUST be allowed by the allowedRuntimeClassNames list. A value of nil does not mutate the Pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="selinuxoptions-v1-core">SELinuxOptions v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SELinuxOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SELinuxOptions are the labels to be applied to the container</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritycontext-v1-core">PodSecurityContext [core/v1]</a></LI>
-  <LI><a href="#selinuxstrategyoptions-v1beta1-policy">SELinuxStrategyOptions [policy/v1beta1]</a></LI>
-  <LI><a href="#securitycontext-v1-core">SecurityContext [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>level</CODE><BR /><I>string</I></TD><TD>Level is SELinux level label that applies to the container.</TD></TR>
-<TR><TD><CODE>role</CODE><BR /><I>string</I></TD><TD>Role is a SELinux role label that applies to the container.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type is a SELinux type label that applies to the container.</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>User is a SELinux user label that applies to the container.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="selinuxstrategyoptions-v1beta1-policy">SELinuxStrategyOptions v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>SELinuxStrategyOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SELinuxStrategyOptions defines the strategy type and any options used to create the strategy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rule</CODE><BR /><I>string</I></TD><TD>rule is the strategy that will dictate the allowable labels that may be set.</TD></TR>
-<TR><TD><CODE>seLinuxOptions</CODE><BR /><I><a href="#selinuxoptions-v1-core">SELinuxOptions</a></I></TD><TD>seLinuxOptions required to run as; required for MustRunAs More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="scale-v1-autoscaling">Scale v1 autoscaling</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Scale</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Scale represents a scaling request for a resource.</P>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#scalespec-v1-autoscaling">ScaleSpec</a></I></TD><TD>defines the behavior of the scale. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#scalestatus-v1-autoscaling">ScaleStatus</a></I></TD><TD>current status of the scale. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status. Read-only.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="scaleiopersistentvolumesource-v1-core">ScaleIOPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ScaleIOPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ScaleIOPersistentVolumeSource represents a persistent ScaleIO volume</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Default is &#34;xfs&#34;</TD></TR>
-<TR><TD><CODE>gateway</CODE><BR /><I>string</I></TD><TD>The host address of the ScaleIO API Gateway.</TD></TR>
-<TR><TD><CODE>protectionDomain</CODE><BR /><I>string</I></TD><TD>The name of the ScaleIO Protection Domain for the configured storage.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#secretreference-v1-core">SecretReference</a></I></TD><TD>SecretRef references to the secret for ScaleIO user and other sensitive information. If this is not provided, Login operation will fail.</TD></TR>
-<TR><TD><CODE>sslEnabled</CODE><BR /><I>boolean</I></TD><TD>Flag to enable/disable SSL communication with Gateway, default false</TD></TR>
-<TR><TD><CODE>storageMode</CODE><BR /><I>string</I></TD><TD>Indicates whether the storage for a volume should be ThickProvisioned or ThinProvisioned. Default is ThinProvisioned.</TD></TR>
-<TR><TD><CODE>storagePool</CODE><BR /><I>string</I></TD><TD>The ScaleIO Storage Pool associated with the protection domain.</TD></TR>
-<TR><TD><CODE>system</CODE><BR /><I>string</I></TD><TD>The name of the storage system as configured in ScaleIO.</TD></TR>
-<TR><TD><CODE>volumeName</CODE><BR /><I>string</I></TD><TD>The name of a volume already created in the ScaleIO system that is associated with this volume source.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="scaleiovolumesource-v1-core">ScaleIOVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ScaleIOVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ScaleIOVolumeSource represents a persistent ScaleIO volume</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Default is &#34;xfs&#34;.</TD></TR>
-<TR><TD><CODE>gateway</CODE><BR /><I>string</I></TD><TD>The host address of the ScaleIO API Gateway.</TD></TR>
-<TR><TD><CODE>protectionDomain</CODE><BR /><I>string</I></TD><TD>The name of the ScaleIO Protection Domain for the configured storage.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>SecretRef references to the secret for ScaleIO user and other sensitive information. If this is not provided, Login operation will fail.</TD></TR>
-<TR><TD><CODE>sslEnabled</CODE><BR /><I>boolean</I></TD><TD>Flag to enable/disable SSL communication with Gateway, default false</TD></TR>
-<TR><TD><CODE>storageMode</CODE><BR /><I>string</I></TD><TD>Indicates whether the storage for a volume should be ThickProvisioned or ThinProvisioned. Default is ThinProvisioned.</TD></TR>
-<TR><TD><CODE>storagePool</CODE><BR /><I>string</I></TD><TD>The ScaleIO Storage Pool associated with the protection domain.</TD></TR>
-<TR><TD><CODE>system</CODE><BR /><I>string</I></TD><TD>The name of the storage system as configured in ScaleIO.</TD></TR>
-<TR><TD><CODE>volumeName</CODE><BR /><I>string</I></TD><TD>The name of a volume already created in the ScaleIO system that is associated with this volume source.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="scheduling-v1beta1-node-k8s-io">Scheduling v1beta1 node.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Scheduling</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Scheduling specifies the scheduling constraints for nodes supporting a RuntimeClass.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#scheduling-v1alpha1-node-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclass-v1beta1-node-k8s-io">RuntimeClass [node/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nodeSelector</CODE><BR /><I>object</I></TD><TD>nodeSelector lists labels that must be present on nodes that support this RuntimeClass. Pods using this RuntimeClass can only be scheduled to a node matched by this selector. The RuntimeClass nodeSelector is merged with a pod&#39;s existing nodeSelector. Any conflicts will cause the pod to be rejected in admission.</TD></TR>
-<TR><TD><CODE>tolerations</CODE><BR /><I><a href="#toleration-v1-core">Toleration</a> array</I></TD><TD>tolerations are appended (excluding duplicates) to pods running with this RuntimeClass during admission, effectively unioning the set of nodes tolerated by the pod and the RuntimeClass.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="scopeselector-v1-core">ScopeSelector v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ScopeSelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A scope selector represents the AND of the selectors represented by the scoped-resource selector requirements.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#resourcequotaspec-v1-core">ResourceQuotaSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>matchExpressions</CODE><BR /><I><a href="#scopedresourceselectorrequirement-v1-core">ScopedResourceSelectorRequirement</a> array</I></TD><TD>A list of scope selector requirements by scope of the resources.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="scopedresourceselectorrequirement-v1-core">ScopedResourceSelectorRequirement v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ScopedResourceSelectorRequirement</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A scoped-resource selector requirement is a selector that contains values, a scope name, and an operator that relates the scope name and values.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#scopeselector-v1-core">ScopeSelector [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>operator</CODE><BR /><I>string</I></TD><TD>Represents a scope&#39;s relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist.</TD></TR>
-<TR><TD><CODE>scopeName</CODE><BR /><I>string</I></TD><TD>The name of the scope that the selector applies to.</TD></TR>
-<TR><TD><CODE>values</CODE><BR /><I>string array</I></TD><TD>An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="secretenvsource-v1-core">SecretEnvSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SecretEnvSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SecretEnvSource selects a Secret to populate the environment variables with.
-
-The contents of the target Secret&#39;s Data field will represent the key-value pairs as environment variables.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#envfromsource-v1-core">EnvFromSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the Secret must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="secretkeyselector-v1-core">SecretKeySelector v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SecretKeySelector</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SecretKeySelector selects a key of a Secret.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#envvarsource-v1-core">EnvVarSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>The key of the secret to select from.  Must be a valid secret key.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the Secret or its key must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="secretprojection-v1-core">SecretProjection v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SecretProjection</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Adapts a secret into a projected volume.
-
-The contents of the target Secret&#39;s Data field will be presented in a projected volume as files using the keys in the Data field as the file names. Note that this is identical to a secret volume source without the default mode.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeprojection-v1-core">VolumeProjection [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#keytopath-v1-core">KeyToPath</a> array</I></TD><TD>If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the &#39;..&#39; path or start with &#39;..&#39;.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the Secret or its key must be defined</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="secretreference-v1-core">SecretReference v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SecretReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csipersistentvolumesource-v1-core">CSIPersistentVolumeSource [core/v1]</a></LI>
-  <LI><a href="#cephfspersistentvolumesource-v1-core">CephFSPersistentVolumeSource [core/v1]</a></LI>
-  <LI><a href="#cinderpersistentvolumesource-v1-core">CinderPersistentVolumeSource [core/v1]</a></LI>
-  <LI><a href="#flexpersistentvolumesource-v1-core">FlexPersistentVolumeSource [core/v1]</a></LI>
-  <LI><a href="#iscsipersistentvolumesource-v1-core">ISCSIPersistentVolumeSource [core/v1]</a></LI>
-  <LI><a href="#rbdpersistentvolumesource-v1-core">RBDPersistentVolumeSource [core/v1]</a></LI>
-  <LI><a href="#scaleiopersistentvolumesource-v1-core">ScaleIOPersistentVolumeSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is unique within a namespace to reference a secret resource.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace defines the space within which the secret name must be unique.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="secretvolumesource-v1-core">SecretVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SecretVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Adapts a Secret into a volume.
-
-The contents of the target Secret&#39;s Data field will be presented in a volume as files using the keys in the Data field as the file names. Secret volumes support ownership management and SELinux relabeling.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>defaultMode</CODE><BR /><I>integer</I></TD><TD>Optional: mode bits to use on created files by default. Must be a value between 0 and 0777. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#keytopath-v1-core">KeyToPath</a> array</I></TD><TD>If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the &#39;..&#39; path or start with &#39;..&#39;.</TD></TR>
-<TR><TD><CODE>optional</CODE><BR /><I>boolean</I></TD><TD>Specify whether the Secret or its keys must be defined</TD></TR>
-<TR><TD><CODE>secretName</CODE><BR /><I>string</I></TD><TD>Name of the secret in the pod&#39;s namespace to use. More info: https://kubernetes.io/docs/concepts/storage/volumes#secret</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="securitycontext-v1-core">SecurityContext v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SecurityContext</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SecurityContext holds security configuration that will be applied to a container. Some fields are present in both SecurityContext and PodSecurityContext.  When both are set, the values in SecurityContext take precedence.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowPrivilegeEscalation</CODE><BR /><I>boolean</I></TD><TD>AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN</TD></TR>
-<TR><TD><CODE>capabilities</CODE><BR /><I><a href="#capabilities-v1-core">Capabilities</a></I></TD><TD>The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime.</TD></TR>
-<TR><TD><CODE>privileged</CODE><BR /><I>boolean</I></TD><TD>Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.</TD></TR>
-<TR><TD><CODE>procMount</CODE><BR /><I>string</I></TD><TD>procMount denotes the type of proc mount to use for the containers. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. This requires the ProcMountType feature flag to be enabled.</TD></TR>
-<TR><TD><CODE>readOnlyRootFilesystem</CODE><BR /><I>boolean</I></TD><TD>Whether this container has a read-only root filesystem. Default is false.</TD></TR>
-<TR><TD><CODE>runAsGroup</CODE><BR /><I>integer</I></TD><TD>The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-<TR><TD><CODE>runAsNonRoot</CODE><BR /><I>boolean</I></TD><TD>Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-<TR><TD><CODE>runAsUser</CODE><BR /><I>integer</I></TD><TD>The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-<TR><TD><CODE>seLinuxOptions</CODE><BR /><I><a href="#selinuxoptions-v1-core">SELinuxOptions</a></I></TD><TD>The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container.  May also be set in PodSecurityContext.  If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-<TR><TD><CODE>windowsOptions</CODE><BR /><I><a href="#windowssecuritycontextoptions-v1-core">WindowsSecurityContextOptions</a></I></TD><TD>The Windows specific settings applied to all containers. If unspecified, the options from the PodSecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="serveraddressbyclientcidr-v1-meta">ServerAddressByClientCIDR v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServerAddressByClientCIDR</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ServerAddressByClientCIDR helps the client to determine the server address that they should use, depending on the clientCIDR that they match.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apigroup-v1-meta">APIGroup [meta/v1]</a></LI>
-  <LI><a href="#apiversions-v1-meta">APIVersions [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clientCIDR</CODE><BR /><I>string</I></TD><TD>The CIDR with which clients can match their IP to figure out the server address that they should use.</TD></TR>
-<TR><TD><CODE>serverAddress</CODE><BR /><I>string</I></TD><TD>Address of this server, suitable for a client that matches the above CIDR. This can be a hostname, hostname:port, IP or IP:port.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io">ServiceAccountSubject v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>ServiceAccountSubject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ServiceAccountSubject holds detailed information for service-account-kind subject.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io">Subject [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>`name` is the name of matching ServiceAccount objects, or &#34;*&#34; to match regardless of name. Required.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>`namespace` is the namespace of matching ServiceAccount objects. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="serviceaccounttokenprojection-v1-core">ServiceAccountTokenProjection v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServiceAccountTokenProjection</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ServiceAccountTokenProjection represents a projected service account token volume. This projection can be used to insert a service account token into the pods runtime filesystem for use against APIs (Kubernetes API Server or otherwise).</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeprojection-v1-core">VolumeProjection [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>audience</CODE><BR /><I>string</I></TD><TD>Audience is the intended audience of the token. A recipient of a token must identify itself with an identifier specified in the audience of the token, and otherwise should reject the token. The audience defaults to the identifier of the apiserver.</TD></TR>
-<TR><TD><CODE>expirationSeconds</CODE><BR /><I>integer</I></TD><TD>ExpirationSeconds is the requested duration of validity of the service account token. As the token approaches expiration, the kubelet volume plugin will proactively rotate the service account token. The kubelet will start trying to rotate the token if the token is older than 80 percent of its time to live or if the token is older than 24 hours.Defaults to 1 hour and must be at least 10 minutes.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is the path relative to the mount point of the file to project the token into.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="serviceport-v1-core">ServicePort v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServicePort</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ServicePort contains information on service&#39;s port.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#servicespec-v1-core">ServiceSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>appProtocol</CODE><BR /><I>string</I></TD><TD>The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol. Field can be enabled with ServiceAppProtocol feature gate.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of this port within the service. This must be a DNS_LABEL. All ports within a ServiceSpec must have unique names. When considering the endpoints for a Service, this must match the &#39;name&#39; field in the EndpointPort. Optional if only one ServicePort is defined on this service.</TD></TR>
-<TR><TD><CODE>nodePort</CODE><BR /><I>integer</I></TD><TD>The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>The port that will be exposed by this service.</TD></TR>
-<TR><TD><CODE>protocol</CODE><BR /><I>string</I></TD><TD>The IP protocol for this port. Supports &#34;TCP&#34;, &#34;UDP&#34;, and &#34;SCTP&#34;. Default is TCP.</TD></TR>
-<TR><TD><CODE>targetPort</CODE></TD><TD>Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod&#39;s container ports. If this is not specified, the value of the &#39;port&#39; field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the &#39;port&#39; field. More info: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="servicereference-v1-admissionregistration-k8s-io">ServiceReference v1 admissionregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ServiceReference holds a reference to Service.legacy.k8s.io</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1beta1-apiextensions-k8s-io">v1beta1</a>
-<a href="#servicereference-v1beta1-apiregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhookclientconfig-v1-admissionregistration-k8s-io">WebhookClientConfig [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>`name` is the name of the service. Required</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>`namespace` is the namespace of the service. Required</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>`path` is an optional URL path which will be sent in any request to this service.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="sessionaffinityconfig-v1-core">SessionAffinityConfig v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SessionAffinityConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SessionAffinityConfig represents the configurations of session affinity.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#servicespec-v1-core">ServiceSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clientIP</CODE><BR /><I><a href="#clientipconfig-v1-core">ClientIPConfig</a></I></TD><TD>clientIP contains the configurations of Client IP based session affinity.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="statefulsetcondition-v1-apps">StatefulSetCondition v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StatefulSetCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>StatefulSetCondition describes the state of a statefulset at a certain point.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statefulsetstatus-v1-apps">StatefulSetStatus [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human readable message indicating details about the transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>The reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the condition, one of True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of statefulset condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="statefulsetupdatestrategy-v1-apps">StatefulSetUpdateStrategy v1 apps</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StatefulSetUpdateStrategy</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>StatefulSetUpdateStrategy indicates the strategy that the StatefulSet controller will use to perform updates. It includes any additional parameters necessary to perform the update for the indicated strategy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statefulsetspec-v1-apps">StatefulSetSpec [apps/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rollingUpdate</CODE><BR /><I><a href="#rollingupdatestatefulsetstrategy-v1-apps">RollingUpdateStatefulSetStrategy</a></I></TD><TD>RollingUpdate is used to communicate parameters when Type is RollingUpdateStatefulSetStrategyType.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type indicates the type of the StatefulSetUpdateStrategy. Default is RollingUpdate.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="status-v1-meta">Status v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Status</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Status is a return value for calls that don&#39;t return other objects.</P>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>code</CODE><BR /><I>integer</I></TD><TD>Suggested HTTP return code for this status, 0 if not set.</TD></TR>
-<TR><TD><CODE>details</CODE><BR /><I><a href="#statusdetails-v1-meta">StatusDetails</a></I></TD><TD>Extended data associated with the reason.  Each reason may define its own extended details. This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human-readable description of the status of this operation.</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>A machine-readable description of why this operation is in the &#34;Failure&#34; status. If this value is empty there is no information available. A Reason clarifies an HTTP status code but does not override it.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status of the operation. One of: &#34;Success&#34; or &#34;Failure&#34;. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="statuscause-v1-meta">StatusCause v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StatusCause</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>StatusCause provides more information about an api.Status failure, including cases when multiple errors are encountered.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#statusdetails-v1-meta">StatusDetails [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>field</CODE><BR /><I>string</I></TD><TD>The field of the resource that has caused this error, as named by its JSON serialization. May include dot and postfix notation for nested attributes. Arrays are zero-indexed.  Fields may appear more than once in an array of causes due to fields having multiple errors. Optional.  Examples:   &#34;name&#34; - the field &#34;name&#34; on the current resource   &#34;items[0].name&#34; - the field &#34;name&#34; on the first array entry in &#34;items&#34;</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>A human-readable description of the cause of the error.  This field may be presented as-is to a reader.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>A machine-readable description of the cause of the error. If this value is empty there is no information available.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="statusdetails-v1-meta">StatusDetails v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StatusDetails</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>StatusDetails is a set of additional properties that MAY be set by the server to provide additional information about a response. The Reason field of a Status object defines what attributes will be set. Clients must ignore fields that do not match the defined type of each attribute, and should assume that any attribute may be empty, invalid, or under defined.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#status-v1-meta">Status [meta/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>causes</CODE><BR /><I><a href="#statuscause-v1-meta">StatusCause</a> array</I></TD><TD>The Causes array includes more details associated with the StatusReason failure. Not all StatusReasons may provide detailed causes.</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>The group attribute of the resource associated with the status StatusReason.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>The kind attribute of the resource associated with the status StatusReason. On some operations may differ from the requested resource Kind. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name attribute of the resource associated with the status StatusReason (when there is a single name which can be described).</TD></TR>
-<TR><TD><CODE>retryAfterSeconds</CODE><BR /><I>integer</I></TD><TD>If specified, the time in seconds before the operation should be retried. Some errors may indicate the client must take an alternate action - for those errors this field may indicate how long to wait before taking the alternate action.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID of the resource. (when there is a single resource which can be described). More info: http://kubernetes.io/docs/user-guide/identifiers#uids</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="storageospersistentvolumesource-v1-core">StorageOSPersistentVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StorageOSPersistentVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a StorageOS persistent volume resource.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>SecretRef specifies the secret to use for obtaining the StorageOS API credentials.  If not specified, default values will be attempted.</TD></TR>
-<TR><TD><CODE>volumeName</CODE><BR /><I>string</I></TD><TD>VolumeName is the human-readable name of the StorageOS volume.  Volume names are only unique within a namespace.</TD></TR>
-<TR><TD><CODE>volumeNamespace</CODE><BR /><I>string</I></TD><TD>VolumeNamespace specifies the scope of the volume within StorageOS.  If no namespace is specified then the Pod&#39;s namespace will be used.  This allows the Kubernetes name scoping to be mirrored within StorageOS for tighter integration. Set VolumeName to any name to override the default behaviour. Set to &#34;default&#34; if you are not using namespaces within StorageOS. Namespaces that do not pre-exist within StorageOS will be created.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="storageosvolumesource-v1-core">StorageOSVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>StorageOSVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a StorageOS persistent volume resource.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Defaults to false (read/write). ReadOnly here will force the ReadOnly setting in VolumeMounts.</TD></TR>
-<TR><TD><CODE>secretRef</CODE><BR /><I><a href="#localobjectreference-v1-core">LocalObjectReference</a></I></TD><TD>SecretRef specifies the secret to use for obtaining the StorageOS API credentials.  If not specified, default values will be attempted.</TD></TR>
-<TR><TD><CODE>volumeName</CODE><BR /><I>string</I></TD><TD>VolumeName is the human-readable name of the StorageOS volume.  Volume names are only unique within a namespace.</TD></TR>
-<TR><TD><CODE>volumeNamespace</CODE><BR /><I>string</I></TD><TD>VolumeNamespace specifies the scope of the volume within StorageOS.  If no namespace is specified then the Pod&#39;s namespace will be used.  This allows the Kubernetes name scoping to be mirrored within StorageOS for tighter integration. Set VolumeName to any name to override the default behaviour. Set to &#34;default&#34; if you are not using namespaces within StorageOS. Namespaces that do not pre-exist within StorageOS will be created.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="subject-v1alpha1-flowcontrol-apiserver-k8s-io">Subject v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Subject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Subject matches the originator of a request, as identified by the request authentication system. There are three ways of matching an originator; by user, group, or service account.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subject-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#subject-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io">PolicyRulesWithSubjects [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>group</CODE><BR /><I><a href="#groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io">GroupSubject</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Required</TD></TR>
-<TR><TD><CODE>serviceAccount</CODE><BR /><I><a href="#serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io">ServiceAccountSubject</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I><a href="#usersubject-v1alpha1-flowcontrol-apiserver-k8s-io">UserSubject</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="subjectrulesreviewstatus-v1-authorization-k8s-io">SubjectRulesReviewStatus v1 authorization.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>SubjectRulesReviewStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SubjectRulesReviewStatus contains the result of a rules check. This check can be incomplete depending on the set of authorizers the server is configured with and any errors experienced during evaluation. Because authorization rules are additive, if a rule appears in a list it&#39;s safe to assume the subject has that permission, even if that list is incomplete.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subjectrulesreviewstatus-v1beta1-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectrulesreview-v1-authorization-k8s-io">SelfSubjectRulesReview [authorization/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>evaluationError</CODE><BR /><I>string</I></TD><TD>EvaluationError can appear in combination with Rules. It indicates an error occurred during rule evaluation, such as an authorizer that doesn&#39;t support rule evaluation, and that ResourceRules and/or NonResourceRules may be incomplete.</TD></TR>
-<TR><TD><CODE>incomplete</CODE><BR /><I>boolean</I></TD><TD>Incomplete is true when the rules returned by this call are incomplete. This is most commonly encountered when an authorizer, such as an external authorizer, doesn&#39;t support rules evaluation.</TD></TR>
-<TR><TD><CODE>nonResourceRules</CODE><BR /><I><a href="#nonresourcerule-v1-authorization-k8s-io">NonResourceRule</a> array</I></TD><TD>NonResourceRules is the list of actions the subject is allowed to perform on non-resources. The list ordering isn&#39;t significant, may contain duplicates, and possibly be incomplete.</TD></TR>
-<TR><TD><CODE>resourceRules</CODE><BR /><I><a href="#resourcerule-v1-authorization-k8s-io">ResourceRule</a> array</I></TD><TD>ResourceRules is the list of actions the subject is allowed to perform on resources. The list ordering isn&#39;t significant, may contain duplicates, and possibly be incomplete.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="supplementalgroupsstrategyoptions-v1beta1-policy">SupplementalGroupsStrategyOptions v1beta1 policy</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>SupplementalGroupsStrategyOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>SupplementalGroupsStrategyOptions defines the strategy type and options used to create the strategy.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritypolicyspec-v1beta1-policy">PodSecurityPolicySpec [policy/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>ranges</CODE><BR /><I><a href="#idrange-v1beta1-policy">IDRange</a> array</I></TD><TD>ranges are the allowed ranges of supplemental groups.  If you would like to force a single supplemental group then supply a single range with the same start and end. Required for MustRunAs.</TD></TR>
-<TR><TD><CODE>rule</CODE><BR /><I>string</I></TD><TD>rule is the strategy that will dictate what supplemental groups is used in the SecurityContext.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="sysctl-v1-core">Sysctl v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Sysctl</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Sysctl defines a kernel parameter to be set</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritycontext-v1-core">PodSecurityContext [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of a property to set</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>string</I></TD><TD>Value of a property to set</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="tcpsocketaction-v1-core">TCPSocketAction v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TCPSocketAction</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>TCPSocketAction describes an action based on opening a socket</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#handler-v1-core">Handler [core/v1]</a></LI>
-  <LI><a href="#probe-v1-core">Probe [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>host</CODE><BR /><I>string</I></TD><TD>Optional: Host name to connect to, defaults to the pod IP.</TD></TR>
-<TR><TD><CODE>port</CODE></TD><TD>Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="taint-v1-core">Taint v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Taint</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>The node this Taint is attached to has the &#34;effect&#34; on any pod that does not tolerate the Taint.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#nodespec-v1-core">NodeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>effect</CODE><BR /><I>string</I></TD><TD>Required. The effect of the taint on pods that do not tolerate the taint. Valid effects are NoSchedule, PreferNoSchedule and NoExecute.</TD></TR>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>Required. The taint key to be applied to a node.</TD></TR>
-<TR><TD><CODE>timeAdded</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>TimeAdded represents the time at which the taint was added. It is only written for NoExecute taints.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>string</I></TD><TD>The taint value corresponding to the taint key.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="time-v1-meta">Time v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Time</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON.  Wrappers are provided for many of the factory methods that the time package offers.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicecondition-v1-apiregistration-k8s-io">APIServiceCondition [apiregistration/v1]</a></LI>
-  <LI><a href="#apiservicecondition-v1beta1-apiregistration-k8s-io">APIServiceCondition [apiregistration/v1beta1]</a></LI>
-  <LI><a href="#certificatesigningrequestcondition-v1beta1-certificates-k8s-io">CertificateSigningRequestCondition [certificates/v1beta1]</a></LI>
-  <LI><a href="#containerstaterunning-v1-core">ContainerStateRunning [core/v1]</a></LI>
-  <LI><a href="#containerstateterminated-v1-core">ContainerStateTerminated [core/v1]</a></LI>
-  <LI><a href="#cronjobstatus-v1beta1-batch">CronJobStatus [batch/v1beta1]</a></LI>
-  <LI><a href="#cronjobstatus-v2alpha1-batch">CronJobStatus [batch/v2alpha1]</a></LI>
-  <LI><a href="#customresourcedefinitioncondition-v1-apiextensions-k8s-io">CustomResourceDefinitionCondition [apiextensions/v1]</a></LI>
-  <LI><a href="#customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionCondition [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#daemonsetcondition-v1-apps">DaemonSetCondition [apps/v1]</a></LI>
-  <LI><a href="#deploymentcondition-v1-apps">DeploymentCondition [apps/v1]</a></LI>
-  <LI><a href="#event-v1-core">Event [core/v1]</a></LI>
-  <LI><a href="#event-v1beta1-events-k8s-io">Event [events/v1beta1]</a></LI>
-  <LI><a href="#flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io">FlowSchemaCondition [flowcontrol/v1alpha1]</a></LI>
-  <LI><a href="#horizontalpodautoscalercondition-v2beta2-autoscaling">HorizontalPodAutoscalerCondition [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#horizontalpodautoscalercondition-v2beta1-autoscaling">HorizontalPodAutoscalerCondition [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#horizontalpodautoscalerstatus-v1-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v1]</a></LI>
-  <LI><a href="#horizontalpodautoscalerstatus-v2beta2-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#horizontalpodautoscalerstatus-v2beta1-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#jobcondition-v1-batch">JobCondition [batch/v1]</a></LI>
-  <LI><a href="#jobstatus-v1-batch">JobStatus [batch/v1]</a></LI>
-  <LI><a href="#managedfieldsentry-v1-meta">ManagedFieldsEntry [meta/v1]</a></LI>
-  <LI><a href="#namespacecondition-v1-core">NamespaceCondition [core/v1]</a></LI>
-  <LI><a href="#nodecondition-v1-core">NodeCondition [core/v1]</a></LI>
-  <LI><a href="#objectmeta-v1-meta">ObjectMeta [meta/v1]</a></LI>
-  <LI><a href="#persistentvolumeclaimcondition-v1-core">PersistentVolumeClaimCondition [core/v1]</a></LI>
-  <LI><a href="#podcondition-v1-core">PodCondition [core/v1]</a></LI>
-  <LI><a href="#podstatus-v1-core">PodStatus [core/v1]</a></LI>
-  <LI><a href="#prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io">PriorityLevelConfigurationCondition [flowcontrol/v1alpha1]</a></LI>
-  <LI><a href="#replicasetcondition-v1-apps">ReplicaSetCondition [apps/v1]</a></LI>
-  <LI><a href="#replicationcontrollercondition-v1-core">ReplicationControllerCondition [core/v1]</a></LI>
-  <LI><a href="#statefulsetcondition-v1-apps">StatefulSetCondition [apps/v1]</a></LI>
-  <LI><a href="#taint-v1-core">Taint [core/v1]</a></LI>
-  <LI><a href="#tokenrequeststatus-v1-authentication-k8s-io">TokenRequestStatus [authentication/v1]</a></LI>
-  <LI><a href="#volumeerror-v1-storage-k8s-io">VolumeError [storage/v1]</a></LI>
-  <LI><a href="#volumeerror-v1beta1-storage-k8s-io">VolumeError [storage/v1beta1]</a></LI>
-  <LI><a href="#volumeerror-v1alpha1-storage-k8s-io">VolumeError [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H2 id="toleration-v1-core">Toleration v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Toleration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>The pod this Toleration is attached to tolerates any taint that matches the triple &lt;key,value,effect&gt; using the matching operator &lt;operator&gt;.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
-  <LI><a href="#scheduling-v1beta1-node-k8s-io">Scheduling [node/v1beta1]</a></LI>
-  <LI><a href="#scheduling-v1alpha1-node-k8s-io">Scheduling [node/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>effect</CODE><BR /><I>string</I></TD><TD>Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.</TD></TR>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys.</TD></TR>
-<TR><TD><CODE>operator</CODE><BR /><I>string</I></TD><TD>Operator represents a key&#39;s relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.</TD></TR>
-<TR><TD><CODE>tolerationSeconds</CODE><BR /><I>integer</I></TD><TD>TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>string</I></TD><TD>Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="topologyselectorlabelrequirement-v1-core">TopologySelectorLabelRequirement v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TopologySelectorLabelRequirement</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A topology selector requirement is a selector that matches given label. This is an alpha feature and may change in the future.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#topologyselectorterm-v1-core">TopologySelectorTerm [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>key</CODE><BR /><I>string</I></TD><TD>The label key that the selector applies to.</TD></TR>
-<TR><TD><CODE>values</CODE><BR /><I>string array</I></TD><TD>An array of string values. One value must match the label to be selected. Each entry in Values is ORed.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="topologyselectorterm-v1-core">TopologySelectorTerm v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TopologySelectorTerm</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>A topology selector term represents the result of label queries. A null or empty topology selector term matches no objects. The requirements of them are ANDed. It provides a subset of functionality as NodeSelectorTerm. This is an alpha feature and may change in the future.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#storageclass-v1-storage-k8s-io">StorageClass [storage/v1]</a></LI>
-  <LI><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>matchLabelExpressions</CODE><BR /><I><a href="#topologyselectorlabelrequirement-v1-core">TopologySelectorLabelRequirement</a> array</I></TD><TD>A list of topology selector requirements by labels.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="topologyspreadconstraint-v1-core">TopologySpreadConstraint v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TopologySpreadConstraint</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>TopologySpreadConstraint specifies how to spread matching pods among the given topology.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podspec-v1-core">PodSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>labelSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>LabelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.</TD></TR>
-<TR><TD><CODE>maxSkew</CODE><BR /><I>integer</I></TD><TD>MaxSkew describes the degree to which pods may be unevenly distributed. It&#39;s the maximum permitted difference between the number of matching pods in any two topology domains of a given topology type. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 1/1/0: | zone1 | zone2 | zone3 | |   P   |   P   |       | - if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 1/1/1; scheduling it onto zone1(zone2) would make the ActualSkew(2-0) on zone1(zone2) violate MaxSkew(1). - if MaxSkew is 2, incoming pod can be scheduled onto any zone. It&#39;s a required field. Default value is 1 and 0 is not allowed.</TD></TR>
-<TR><TD><CODE>topologyKey</CODE><BR /><I>string</I></TD><TD>TopologyKey is the key of node labels. Nodes that have a label with this key and identical values are considered to be in the same topology. We consider each &lt;key, value&gt; as a &#34;bucket&#34;, and try to put balanced number of pods into each bucket. It&#39;s a required field.</TD></TR>
-<TR><TD><CODE>whenUnsatisfiable</CODE><BR /><I>string</I></TD><TD>WhenUnsatisfiable indicates how to deal with a pod if it doesn&#39;t satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it - ScheduleAnyway tells the scheduler to still schedule it It&#39;s considered as &#34;Unsatisfiable&#34; if and only if placing incoming pod on any topology violates &#34;MaxSkew&#34;. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: | zone1 | zone2 | zone3 | | P P P |   P   |   P   | If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won&#39;t make it *more* imbalanced. It&#39;s a required field.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="typedlocalobjectreference-v1-core">TypedLocalObjectReference v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>TypedLocalObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>TypedLocalObjectReference contains enough information to let you locate the typed referenced object inside the same namespace.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressbackend-v1beta1-extensions">IngressBackend [extensions/v1beta1]</a></LI>
-  <LI><a href="#ingressbackend-v1beta1-networking-k8s-io">IngressBackend [networking/v1beta1]</a></LI>
-  <LI><a href="#ingressclassspec-v1beta1-networking-k8s-io">IngressClassSpec [networking/v1beta1]</a></LI>
-  <LI><a href="#persistentvolumeclaimspec-v1-core">PersistentVolumeClaimSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroup</CODE><BR /><I>string</I></TD><TD>APIGroup is the group for the resource being referenced. If APIGroup is not specified, the specified Kind must be in the core API group. For any other third-party types, APIGroup is required.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is the type of resource being referenced</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of resource being referenced</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="userinfo-v1-authentication-k8s-io">UserInfo v1 authentication.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>UserInfo</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>UserInfo holds the information about the user needed to implement the user.Info interface.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#userinfo-v1beta1-authentication-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenreviewstatus-v1-authentication-k8s-io">TokenReviewStatus [authentication/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extra</CODE><BR /><I>object</I></TD><TD>Any additional information provided by the authenticator.</TD></TR>
-<TR><TD><CODE>groups</CODE><BR /><I>string array</I></TD><TD>The names of groups this user is a part of.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>A unique value that identifies this user across time. If this user is deleted and another user by the same name is added, they will have different UIDs.</TD></TR>
-<TR><TD><CODE>username</CODE><BR /><I>string</I></TD><TD>The name that uniquely identifies this user among all active users.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="usersubject-v1alpha1-flowcontrol-apiserver-k8s-io">UserSubject v1alpha1 flowcontrol.apiserver.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>UserSubject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>UserSubject holds detailed information for user-kind subject.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io">Subject [flowcontrol/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>`name` is the username that matches, or &#34;*&#34; to match all usernames. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="validatingwebhook-v1-admissionregistration-k8s-io">ValidatingWebhook v1 admissionregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ValidatingWebhook</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>ValidatingWebhook describes an admission webhook and the resources and operations it applies to.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#validatingwebhook-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">ValidatingWebhookConfiguration [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionReviewVersions</CODE><BR /><I>string array</I></TD><TD>AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy.</TD></TR>
-<TR><TD><CODE>clientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1-admissionregistration-k8s-io">WebhookClientConfig</a></I></TD><TD>ClientConfig defines how to communicate with the hook. Required</TD></TR>
-<TR><TD><CODE>failurePolicy</CODE><BR /><I>string</I></TD><TD>FailurePolicy defines how unrecognized errors from the admission endpoint are handled - allowed values are Ignore or Fail. Defaults to Fail.</TD></TR>
-<TR><TD><CODE>matchPolicy</CODE><BR /><I>string</I></TD><TD>matchPolicy defines how the &#34;rules&#34; list is used to match incoming requests. Allowed values are &#34;Exact&#34; or &#34;Equivalent&#34;.  - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook.  - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook.  Defaults to &#34;Equivalent&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where &#34;imagepolicy&#34; is the name of the webhook, and kubernetes.io is the name of the organization. Required.</TD></TR>
-<TR><TD><CODE>namespaceSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook.  For example, to run the webhook on any objects whose namespace is not associated with &#34;runlevel&#34; of &#34;0&#34; or &#34;1&#34;;  you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;runlevel&#34;,       &#34;operator&#34;: &#34;NotIn&#34;,       &#34;values&#34;: [         &#34;0&#34;,         &#34;1&#34;       ]     }   ] }  If instead you want to only run the webhook on any objects whose namespace is associated with the &#34;environment&#34; of &#34;prod&#34; or &#34;staging&#34;; you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;environment&#34;,       &#34;operator&#34;: &#34;In&#34;,       &#34;values&#34;: [         &#34;prod&#34;,         &#34;staging&#34;       ]     }   ] }  See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.  Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>objectSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#rulewithoperations-v1-admissionregistration-k8s-io">RuleWithOperations</a> array</I></TD><TD>Rules describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.</TD></TR>
-<TR><TD><CODE>sideEffects</CODE><BR /><I>string</I></TD><TD>SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE><BR /><I>integer</I></TD><TD>TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 10 seconds.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumeattachmentsource-v1-storage-k8s-io">VolumeAttachmentSource v1 storage.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeAttachmentSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>VolumeAttachmentSource represents a volume that should be attached. Right now only PersistenVolumes can be attached via external attacher, in future we may allow also inline volumes in pods. Exactly one member can be set.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeattachmentsource-v1beta1-storage-k8s-io">v1beta1</a>
-<a href="#volumeattachmentsource-v1alpha1-storage-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentspec-v1-storage-k8s-io">VolumeAttachmentSpec [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>inlineVolumeSpec</CODE><BR /><I><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec</a></I></TD><TD>inlineVolumeSpec contains all the information necessary to attach a persistent volume defined by a pod&#39;s inline VolumeSource. This field is populated only for the CSIMigration feature. It contains translated fields from a pod&#39;s inline VolumeSource to a PersistentVolumeSpec. This field is alpha-level and is only honored by servers that enabled the CSIMigration feature.</TD></TR>
-<TR><TD><CODE>persistentVolumeName</CODE><BR /><I>string</I></TD><TD>Name of the persistent volume to attach.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumedevice-v1-core">VolumeDevice v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeDevice</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>volumeDevice describes a mapping of a raw block device within a container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>devicePath</CODE><BR /><I>string</I></TD><TD>devicePath is the path inside of the container that the device will be mapped to.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name must match the name of a persistentVolumeClaim in the pod</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumeerror-v1-storage-k8s-io">VolumeError v1 storage.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeError</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>VolumeError captures an error encountered during a volume operation.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeerror-v1beta1-storage-k8s-io">v1beta1</a>
-<a href="#volumeerror-v1alpha1-storage-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentstatus-v1-storage-k8s-io">VolumeAttachmentStatus [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>String detailing the error encountered during Attach or Detach operation. This string may be logged, so it should not contain sensitive information.</TD></TR>
-<TR><TD><CODE>time</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time the error was encountered.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumemount-v1-core">VolumeMount v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeMount</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>VolumeMount describes a mounting of a Volume within a container.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#container-v1-core">Container [core/v1]</a></LI>
-  <LI><a href="#ephemeralcontainer-v1-core">EphemeralContainer [core/v1]</a></LI>
-  <LI><a href="#podpresetspec-v1alpha1-settings-k8s-io">PodPresetSpec [settings/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>mountPath</CODE><BR /><I>string</I></TD><TD>Path within the container at which the volume should be mounted.  Must not contain &#39;:&#39;.</TD></TR>
-<TR><TD><CODE>mountPropagation</CODE><BR /><I>string</I></TD><TD>mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>This must match the Name of a Volume.</TD></TR>
-<TR><TD><CODE>readOnly</CODE><BR /><I>boolean</I></TD><TD>Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.</TD></TR>
-<TR><TD><CODE>subPath</CODE><BR /><I>string</I></TD><TD>Path within the volume from which the container&#39;s volume should be mounted. Defaults to &#34;&#34; (volume&#39;s root).</TD></TR>
-<TR><TD><CODE>subPathExpr</CODE><BR /><I>string</I></TD><TD>Expanded path within the volume from which the container&#39;s volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container&#39;s environment. Defaults to &#34;&#34; (volume&#39;s root). SubPathExpr and SubPath are mutually exclusive.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumenodeaffinity-v1-core">VolumeNodeAffinity v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeNodeAffinity</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>VolumeNodeAffinity defines constraints that limit what nodes this volume can be accessed from.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>required</CODE><BR /><I><a href="#nodeselector-v1-core">NodeSelector</a></I></TD><TD>Required specifies hard node constraints that must be met.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumenoderesources-v1-storage-k8s-io">VolumeNodeResources v1 storage.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeNodeResources</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>VolumeNodeResources is a set of resource limits for scheduling of volumes.</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumenoderesources-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinodedriver-v1-storage-k8s-io">CSINodeDriver [storage/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>count</CODE><BR /><I>integer</I></TD><TD>Maximum number of unique volumes managed by the CSI driver that can be used on a node. A volume that is both attached and mounted on a node is considered to be used once, not twice. The same rule applies for a unique volume that is shared among multiple pods on the same node. If this field is not specified, then the supported number of volumes on this node is unbounded.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="volumeprojection-v1-core">VolumeProjection v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VolumeProjection</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Projection that may be projected along with other supported volume types</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#projectedvolumesource-v1-core">ProjectedVolumeSource [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>configMap</CODE><BR /><I><a href="#configmapprojection-v1-core">ConfigMapProjection</a></I></TD><TD>information about the configMap data to project</TD></TR>
-<TR><TD><CODE>downwardAPI</CODE><BR /><I><a href="#downwardapiprojection-v1-core">DownwardAPIProjection</a></I></TD><TD>information about the downwardAPI data to project</TD></TR>
-<TR><TD><CODE>secret</CODE><BR /><I><a href="#secretprojection-v1-core">SecretProjection</a></I></TD><TD>information about the secret data to project</TD></TR>
-<TR><TD><CODE>serviceAccountToken</CODE><BR /><I><a href="#serviceaccounttokenprojection-v1-core">ServiceAccountTokenProjection</a></I></TD><TD>information about the serviceAccountToken data to project</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="vspherevirtualdiskvolumesource-v1-core">VsphereVirtualDiskVolumeSource v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>VsphereVirtualDiskVolumeSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Represents a vSphere volume resource.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec [core/v1]</a></LI>
-  <LI><a href="#volume-v1-core">Volume [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>fsType</CODE><BR /><I>string</I></TD><TD>Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. &#34;ext4&#34;, &#34;xfs&#34;, &#34;ntfs&#34;. Implicitly inferred to be &#34;ext4&#34; if unspecified.</TD></TR>
-<TR><TD><CODE>storagePolicyID</CODE><BR /><I>string</I></TD><TD>Storage Policy Based Management (SPBM) profile ID associated with the StoragePolicyName.</TD></TR>
-<TR><TD><CODE>storagePolicyName</CODE><BR /><I>string</I></TD><TD>Storage Policy Based Management (SPBM) profile name.</TD></TR>
-<TR><TD><CODE>volumePath</CODE><BR /><I>string</I></TD><TD>Path that identifies vSphere volume vmdk</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watchevent-v1-meta">WatchEvent v1 meta</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>meta</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>WatchEvent</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Event represents a single event to a watched resource.</P>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>object</CODE></TD><TD>Object is:  * If Type is Added or Modified: the new state of the object.  * If Type is Deleted: the state of the object immediately before deletion.  * If Type is Error: *Status is recommended; other types may make sense    depending on context.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="webhook-v1alpha1-auditregistration-k8s-io">Webhook v1alpha1 auditregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>auditregistration.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Webhook</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>Webhook holds the configuration of the webhook</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#auditsinkspec-v1alpha1-auditregistration-k8s-io">AuditSinkSpec [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io">WebhookClientConfig</a></I></TD><TD>ClientConfig holds the connection parameters for the webhook required</TD></TR>
-<TR><TD><CODE>throttle</CODE><BR /><I><a href="#webhookthrottleconfig-v1alpha1-auditregistration-k8s-io">WebhookThrottleConfig</a></I></TD><TD>Throttle holds the options for throttling the webhook</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="webhookclientconfig-v1-admissionregistration-k8s-io">WebhookClientConfig v1 admissionregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>WebhookClientConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>WebhookClientConfig contains the information to make a TLS connection with the webhook</P>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#webhookclientconfig-v1beta1-apiextensions-k8s-io">v1beta1</a>
-<a href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhook-v1-admissionregistration-k8s-io">MutatingWebhook [admissionregistration/v1]</a></LI>
-  <LI><a href="#validatingwebhook-v1-admissionregistration-k8s-io">ValidatingWebhook [admissionregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>`caBundle` is a PEM encoded CA bundle which will be used to validate the webhook&#39;s server certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1-admissionregistration-k8s-io">ServiceReference</a></I></TD><TD>`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.  If the webhook is running within the cluster, then you should use `service`.</TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD>`url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.  The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.  Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.  The scheme must be &#34;https&#34;; the URL must begin with &#34;https://&#34;.  A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.  Attempting to use a user or basic auth e.g. &#34;user:password@&#34; is not allowed. Fragments (&#34;#...&#34;) and query parameters (&#34;?...&#34;) are not allowed, either.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="webhookconversion-v1-apiextensions-k8s-io">WebhookConversion v1 apiextensions.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>WebhookConversion</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>WebhookConversion describes how to call a conversion webhook</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourceconversion-v1-apiextensions-k8s-io">CustomResourceConversion [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1-apiextensions-k8s-io">WebhookClientConfig</a></I></TD><TD>clientConfig is the instructions for how to call the webhook if strategy is `Webhook`.</TD></TR>
-<TR><TD><CODE>conversionReviewVersions</CODE><BR /><I>string array</I></TD><TD>conversionReviewVersions is an ordered list of preferred `ConversionReview` versions the Webhook expects. The API server will use the first version in the list which it supports. If none of the versions specified in this list are supported by API server, conversion will fail for the custom resource. If a persisted Webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="webhookthrottleconfig-v1alpha1-auditregistration-k8s-io">WebhookThrottleConfig v1alpha1 auditregistration.k8s.io</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>auditregistration.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>WebhookThrottleConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>WebhookThrottleConfig holds the configuration for throttling events</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhook-v1alpha1-auditregistration-k8s-io">Webhook [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>burst</CODE><BR /><I>integer</I></TD><TD>ThrottleBurst is the maximum number of events sent at the same moment default 15 QPS</TD></TR>
-<TR><TD><CODE>qps</CODE><BR /><I>integer</I></TD><TD>ThrottleQPS maximum number of batches per second default 10 QPS</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="weightedpodaffinityterm-v1-core">WeightedPodAffinityTerm v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>WeightedPodAffinityTerm</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>The weights of all of the matched WeightedPodAffinityTerm fields are added per-node to find the most preferred node(s)</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podaffinity-v1-core">PodAffinity [core/v1]</a></LI>
-  <LI><a href="#podantiaffinity-v1-core">PodAntiAffinity [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>podAffinityTerm</CODE><BR /><I><a href="#podaffinityterm-v1-core">PodAffinityTerm</a></I></TD><TD>Required. A pod affinity term, associated with the corresponding weight.</TD></TR>
-<TR><TD><CODE>weight</CODE><BR /><I>integer</I></TD><TD>weight associated with matching the corresponding podAffinityTerm, in the range 1-100.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="windowssecuritycontextoptions-v1-core">WindowsSecurityContextOptions v1 core</H2>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>WindowsSecurityContextOptions</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<P>WindowsSecurityContextOptions contain Windows-specific options and credentials.</P>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#podsecuritycontext-v1-core">PodSecurityContext [core/v1]</a></LI>
-  <LI><a href="#securitycontext-v1-core">SecurityContext [core/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>gmsaCredentialSpec</CODE><BR /><I>string</I></TD><TD>GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field.</TD></TR>
-<TR><TD><CODE>gmsaCredentialSpecName</CODE><BR /><I>string</I></TD><TD>GMSACredentialSpecName is the name of the GMSA credential spec to use.</TD></TR>
-<TR><TD><CODE>runAsUserName</CODE><BR /><I>string</I></TD><TD>The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="-strong-old-api-versions-strong-"><STRONG>OLD API VERSIONS</STRONG></H1>
-
-<P>This section contains older versions of resources shown above.</P>
-<H1 id="apiservice-v1beta1-apiregistration-k8s-io">APIService v1beta1 apiregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>APIService</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#apiservice-v1-apiregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicelist-v1beta1-apiregistration-k8s-io">APIServiceList [apiregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#apiservicespec-v1beta1-apiregistration-k8s-io">APIServiceSpec</a></I></TD><TD>Spec contains information for locating and communicating with a server</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#apiservicestatus-v1beta1-apiregistration-k8s-io">APIServiceStatus</a></I></TD><TD>Status contains derived information about an API server</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="apiservicespec-v1beta1-apiregistration-k8s-io">APIServiceSpec v1beta1 apiregistration</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService [apiregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>CABundle is a PEM encoded CA bundle which will be used to validate an API server&#39;s serving certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>Group is the API group name this server hosts</TD></TR>
-<TR><TD><CODE>groupPriorityMinimum</CODE><BR /><I>integer</I></TD><TD>GroupPriorityMininum is the priority this group should have at least. Higher priority means that the group is preferred by clients over lower priority ones. Note that other versions of this group might specify even higher GroupPriorityMininum values such that the whole group gets a higher priority. The primary sort is based on GroupPriorityMinimum, ordered highest number to lowest (20 before 10). The secondary sort is based on the alphabetical comparison of the name of the object.  (v1.bar before v1.foo) We&#39;d recommend something like: *.k8s.io (except extensions) at 18000 and PaaSes (OpenShift, Deis) are recommended to be in the 2000s</TD></TR>
-<TR><TD><CODE>insecureSkipTLSVerify</CODE><BR /><I>boolean</I></TD><TD>InsecureSkipTLSVerify disables TLS certificate verification when communicating with this server. This is strongly discouraged.  You should use the CABundle instead.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1beta1-apiregistration-k8s-io">ServiceReference</a></I></TD><TD>Service is a reference to the service for this API server.  It must communicate on port 443 If the Service is nil, that means the handling for the API groupversion is handled locally on this server. The call will simply delegate to the normal handler chain to be fulfilled.</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>Version is the API version this server hosts.  For example, &#34;v1&#34;</TD></TR>
-<TR><TD><CODE>versionPriority</CODE><BR /><I>integer</I></TD><TD>VersionPriority controls the ordering of this API version inside of its group.  Must be greater than zero. The primary sort is based on VersionPriority, ordered highest to lowest (20 before 10). Since it&#39;s inside of a group, the number can be small, probably in the 10s. In case of equal version priorities, the version string will be used to compute the order inside a group. If the version string is &#34;kube-like&#34;, it will sort above non &#34;kube-like&#34; version strings, which are ordered lexicographically. &#34;Kube-like&#34; versions start with a &#34;v&#34;, then are followed by a number (the major version), then optionally the string &#34;alpha&#34; or &#34;beta&#34; and another number (the minor version). These are sorted first by GA &gt; beta &gt; alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="apiservicestatus-v1beta1-apiregistration-k8s-io">APIServiceStatus v1beta1 apiregistration</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService [apiregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#apiservicecondition-v1beta1-apiregistration-k8s-io">APIServiceCondition</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>type</I></TD><TD>Current service state of apiService.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="apiservicelist-v1beta1-apiregistration-k8s-io">APIServiceList v1beta1 apiregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-apiservice-v1beta1-apiregistration-k8s-io">Create</H2>
-<P>create an APIService</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apiregistration.k8s.io/v1beta1/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-apiservice-v1beta1-apiregistration-k8s-io">Patch</H2>
-<P>partially update the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-apiservice-v1beta1-apiregistration-k8s-io">Replace</H2>
-<P>replace the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-apiservice-v1beta1-apiregistration-k8s-io">Delete</H2>
-<P>delete an APIService</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-apiservice-v1beta1-apiregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of APIService</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiregistration.k8s.io/v1beta1/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-apiservice-v1beta1-apiregistration-k8s-io">Read</H2>
-<P>read the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-apiservice-v1beta1-apiregistration-k8s-io">List</H2>
-<P>list or watch objects of kind APIService</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1beta1/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservicelist-v1beta1-apiregistration-k8s-io">APIServiceList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-apiservice-v1beta1-apiregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind APIService. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1beta1/watch/apiservices/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-apiservice-v1beta1-apiregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of APIService. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1beta1/watch/apiservices</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-apiservice-v1beta1-apiregistration-k8s-io">Patch Status</H2>
-<P>partially update status of the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-apiservice-v1beta1-apiregistration-k8s-io">Read Status</H2>
-<P>read status of the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-apiservice-v1beta1-apiregistration-k8s-io">Replace Status</H2>
-<P>replace status of the specified APIService</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the APIService</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#apiservice-v1beta1-apiregistration-k8s-io">APIService</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="apiservicecondition-v1beta1-apiregistration-k8s-io">APIServiceCondition v1beta1 apiregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>APIServiceCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#apiservicecondition-v1-apiregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicestatus-v1beta1-apiregistration-k8s-io">APIServiceStatus [apiregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>Human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>Status is the status of the condition. Can be True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type is the type of the condition.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="aggregationrule-v1beta1-rbac-authorization-k8s-io">AggregationRule v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>AggregationRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#aggregationrule-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#aggregationrule-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clusterRoleSelectors</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a> array</I></TD><TD>ClusterRoleSelectors holds a list of selectors which will be used to find ClusterRoles and create the rules. If any of the selectors match, then the ClusterRole&#39;s permissions will be added</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="aggregationrule-v1alpha1-rbac-authorization-k8s-io">AggregationRule v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>AggregationRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#aggregationrule-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#aggregationrule-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>clusterRoleSelectors</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a> array</I></TD><TD>ClusterRoleSelectors holds a list of selectors which will be used to find ClusterRoles and create the rules. If any of the selectors match, then the ClusterRole&#39;s permissions will be added</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="csidriver-v1beta1-storage-k8s-io">CSIDriver v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CSIDriver</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#csidriver-v1-storage-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csidriverlist-v1beta1-storage-k8s-io">CSIDriverList [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata. metadata.Name indicates the name of the CSI driver that this object refers to; it MUST be the same name returned by the CSI GetPluginName() call for that driver. The driver name must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), dots (.), and alphanumerics between. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#csidriverspec-v1beta1-storage-k8s-io">CSIDriverSpec</a></I></TD><TD>Specification of the CSI Driver.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csidriverspec-v1beta1-storage-k8s-io">CSIDriverSpec v1beta1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attachRequired</CODE><BR /><I>boolean</I></TD><TD>attachRequired indicates this CSI volume driver requires an attach operation (because it implements the CSI ControllerPublishVolume() method), and that the Kubernetes attach detach controller should call the attach volume interface which checks the volumeattachment status and waits until the volume is attached before proceeding to mounting. The CSI external-attacher coordinates with CSI volume driver and updates the volumeattachment status when the attach operation is complete. If the CSIDriverRegistry feature gate is enabled and the value is specified to false, the attach operation will be skipped. Otherwise the attach operation will be called.</TD></TR>
-<TR><TD><CODE>podInfoOnMount</CODE><BR /><I>boolean</I></TD><TD>If set to true, podInfoOnMount indicates this CSI volume driver requires additional pod information (like podName, podUID, etc.) during mount operations. If set to false, pod information will not be passed on mount. Default is false. The CSI driver specifies podInfoOnMount as part of driver deployment. If true, Kubelet will pass pod information as VolumeContext in the CSI NodePublishVolume() calls. The CSI driver is responsible for parsing and validating the information passed in as VolumeContext. The following VolumeConext will be passed if podInfoOnMount is set to true. This list might grow, but the prefix will be used. &#34;csi.storage.k8s.io/pod.name&#34;: pod.Name &#34;csi.storage.k8s.io/pod.namespace&#34;: pod.Namespace &#34;csi.storage.k8s.io/pod.uid&#34;: string(pod.UID) &#34;csi.storage.k8s.io/ephemeral&#34;: &#34;true&#34; iff the volume is an ephemeral inline volume                                 defined by a CSIVolumeSource, otherwise &#34;false&#34;  &#34;csi.storage.k8s.io/ephemeral&#34; is a new feature in Kubernetes 1.16. It is only required for drivers which support both the &#34;Persistent&#34; and &#34;Ephemeral&#34; VolumeLifecycleMode. Other drivers can leave pod info disabled and/or ignore this field. As Kubernetes 1.15 doesn&#39;t support this field, drivers can only support one mode when deployed on such a cluster and the deployment determines which mode that is, for example via a command line parameter of the driver.</TD></TR>
-<TR><TD><CODE>volumeLifecycleModes</CODE><BR /><I>string array</I></TD><TD>VolumeLifecycleModes defines what kind of volumes this CSI volume driver supports. The default if the list is empty is &#34;Persistent&#34;, which is the usage defined by the CSI specification and implemented in Kubernetes via the usual PV/PVC mechanism. The other mode is &#34;Ephemeral&#34;. In this mode, volumes are defined inline inside the pod spec with CSIVolumeSource and their lifecycle is tied to the lifecycle of that pod. A driver has to be aware of this because it is only going to get a NodePublishVolume call for such a volume. For more information about implementing this mode, see https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html A driver can support one or more of these modes and more modes may be added in the future.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csidriverlist-v1beta1-storage-k8s-io">CSIDriverList v1beta1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a> array</I></TD><TD>items is the list of CSIDriver</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-csidriver-v1beta1-storage-k8s-io">Create</H2>
-<P>create a CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1beta1/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-csidriver-v1beta1-storage-k8s-io">Patch</H2>
-<P>partially update the specified CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1beta1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-csidriver-v1beta1-storage-k8s-io">Replace</H2>
-<P>replace the specified CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1beta1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-csidriver-v1beta1-storage-k8s-io">Delete</H2>
-<P>delete a CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-csidriver-v1beta1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-csidriver-v1beta1-storage-k8s-io">Read</H2>
-<P>read the specified CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriver-v1beta1-storage-k8s-io">CSIDriver</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-csidriver-v1beta1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind CSIDriver</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csidriverlist-v1beta1-storage-k8s-io">CSIDriverList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-csidriver-v1beta1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CSIDriver. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/csidrivers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSIDriver</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-csidriver-v1beta1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CSIDriver. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/csidrivers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="csinode-v1beta1-storage-k8s-io">CSINode v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CSINode</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#csinode-v1-storage-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinodelist-v1beta1-storage-k8s-io">CSINodeList [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>metadata.name must be the Kubernetes node name.</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#csinodespec-v1beta1-storage-k8s-io">CSINodeSpec</a></I></TD><TD>spec is the specification of CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csinodespec-v1beta1-storage-k8s-io">CSINodeSpec v1beta1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinode-v1beta1-storage-k8s-io">CSINode [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>drivers</CODE><BR /><I><a href="#csinodedriver-v1beta1-storage-k8s-io">CSINodeDriver</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>drivers is a list of information of all CSI Drivers existing on a node. If all drivers in the list are uninstalled, this can become empty.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="csinodelist-v1beta1-storage-k8s-io">CSINodeList v1beta1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a> array</I></TD><TD>items is the list of CSINode</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-csinode-v1beta1-storage-k8s-io">Create</H2>
-<P>create a CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1beta1/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-csinode-v1beta1-storage-k8s-io">Patch</H2>
-<P>partially update the specified CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1beta1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-csinode-v1beta1-storage-k8s-io">Replace</H2>
-<P>replace the specified CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1beta1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-csinode-v1beta1-storage-k8s-io">Delete</H2>
-<P>delete a CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-csinode-v1beta1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-csinode-v1beta1-storage-k8s-io">Read</H2>
-<P>read the specified CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinode-v1beta1-storage-k8s-io">CSINode</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-csinode-v1beta1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind CSINode</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#csinodelist-v1beta1-storage-k8s-io">CSINodeList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-csinode-v1beta1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CSINode. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/csinodes/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CSINode</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-csinode-v1beta1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CSINode. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/csinodes</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="csinodedriver-v1beta1-storage-k8s-io">CSINodeDriver v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CSINodeDriver</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#csinodedriver-v1-storage-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinodespec-v1beta1-storage-k8s-io">CSINodeSpec [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allocatable</CODE><BR /><I><a href="#volumenoderesources-v1beta1-storage-k8s-io">VolumeNodeResources</a></I></TD><TD>allocatable represents the volume resources of a node that are available for scheduling.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>This is the name of the CSI driver that this object refers to. This MUST be the same name returned by the CSI GetPluginName() call for that driver.</TD></TR>
-<TR><TD><CODE>nodeID</CODE><BR /><I>string</I></TD><TD>nodeID of the node from the driver point of view. This field enables Kubernetes to communicate with storage systems that do not share the same nomenclature for nodes. For example, Kubernetes may refer to a given node as &#34;node1&#34;, but the storage system may refer to the same node as &#34;nodeA&#34;. When Kubernetes issues a command to the storage system to attach a volume to a specific node, it can use this field to refer to the node name using the ID that the storage system will understand, e.g. &#34;nodeA&#34; instead of &#34;node1&#34;. This field is required.</TD></TR>
-<TR><TD><CODE>topologyKeys</CODE><BR /><I>string array</I></TD><TD>topologyKeys is the list of keys supported by the driver. When a driver is initialized on a cluster, it provides a set of topology keys that it understands (e.g. &#34;company.com/zone&#34;, &#34;company.com/region&#34;). When a driver is initialized on a node, it provides the same topology keys along with values. Kubelet will expose these topology keys as labels on its own node object. When Kubernetes does topology aware provisioning, it can use this list to determine which labels it should retrieve from the node object and pass back to the driver. It is possible for different nodes to use different topology keys. This can be empty if driver does not support topology.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ClusterRole</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#clusterrole-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolelist-v1beta1-rbac-authorization-k8s-io">ClusterRoleList [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>aggregationRule</CODE><BR /><I><a href="#aggregationrule-v1beta1-rbac-authorization-k8s-io">AggregationRule</a></I></TD><TD>AggregationRule is an optional field that describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be stomped by the controller.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyrule-v1beta1-rbac-authorization-k8s-io">PolicyRule</a> array</I></TD><TD>Rules holds all the PolicyRules for this ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="clusterrolelist-v1beta1-rbac-authorization-k8s-io">ClusterRoleList v1beta1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a> array</I></TD><TD>Items is a list of ClusterRoles</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-clusterrole-v1beta1-rbac-authorization-k8s-io">Create</H2>
-<P>create a ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1beta1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-clusterrole-v1beta1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-clusterrole-v1beta1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-clusterrole-v1beta1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-clusterrole-v1beta1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-clusterrole-v1beta1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolelist-v1beta1-rbac-authorization-k8s-io">ClusterRoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-clusterrole-v1beta1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ClusterRole. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ClusterRole. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>ClusterRole</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#clusterrole-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolelist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleList [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>aggregationRule</CODE><BR /><I><a href="#aggregationrule-v1alpha1-rbac-authorization-k8s-io">AggregationRule</a></I></TD><TD>AggregationRule is an optional field that describes how to build the Rules for this ClusterRole. If AggregationRule is set, then the Rules are controller managed and direct changes to Rules will be stomped by the controller.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyrule-v1alpha1-rbac-authorization-k8s-io">PolicyRule</a> array</I></TD><TD>Rules holds all the PolicyRules for this ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="clusterrolelist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleList v1alpha1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a> array</I></TD><TD>Items is a list of ClusterRoles</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-clusterrole-v1alpha1-rbac-authorization-k8s-io">Create</H2>
-<P>create a ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-clusterrole-v1alpha1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-clusterrole-v1alpha1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-clusterrole-v1alpha1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-clusterrole-v1alpha1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-clusterrole-v1alpha1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind ClusterRole</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolelist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-clusterrole-v1alpha1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ClusterRole. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterroles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRole</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ClusterRole. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterroles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ClusterRoleBinding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebindinglist-v1beta1-rbac-authorization-k8s-io">ClusterRoleBindingList [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>roleRef</CODE><BR /><I><a href="#roleref-v1beta1-rbac-authorization-k8s-io">RoleRef</a></I></TD><TD>RoleRef can only reference a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1beta1-rbac-authorization-k8s-io">Subject</a> array</I></TD><TD>Subjects holds references to the objects the role applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="clusterrolebindinglist-v1beta1-rbac-authorization-k8s-io">ClusterRoleBindingList v1beta1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a> array</I></TD><TD>Items is a list of ClusterRoleBindings</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Create</H2>
-<P>create a ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebindinglist-v1beta1-rbac-authorization-k8s-io">ClusterRoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ClusterRoleBinding. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ClusterRoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>ClusterRoleBinding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebindinglist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBindingList [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>roleRef</CODE><BR /><I><a href="#roleref-v1alpha1-rbac-authorization-k8s-io">RoleRef</a></I></TD><TD>RoleRef can only reference a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1alpha1-rbac-authorization-k8s-io">Subject</a> array</I></TD><TD>Subjects holds references to the objects the role applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="clusterrolebindinglist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBindingList v1alpha1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a> array</I></TD><TD>Items is a list of ClusterRoleBindings</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Create</H2>
-<P>create a ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind ClusterRoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#clusterrolebindinglist-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ClusterRoleBinding. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterrolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ClusterRoleBinding</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ClusterRoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterrolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="cronjob-v2alpha1-batch">CronJob v2alpha1 batch</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>batch</CODE></TD><TD><CODE>v2alpha1</CODE></TD><TD><CODE>CronJob</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#cronjob-v1beta1-batch">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjoblist-v2alpha1-batch">CronJobList [batch/v2alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#cronjobspec-v2alpha1-batch">CronJobSpec</a></I></TD><TD>Specification of the desired behavior of a cron job, including the schedule. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#cronjobstatus-v2alpha1-batch">CronJobStatus</a></I></TD><TD>Current status of a cron job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="cronjobspec-v2alpha1-batch">CronJobSpec v2alpha1 batch</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjob-v2alpha1-batch">CronJob [batch/v2alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>concurrencyPolicy</CODE><BR /><I>string</I></TD><TD>Specifies how to treat concurrent executions of a Job. Valid values are: - &#34;Allow&#34; (default): allows CronJobs to run concurrently; - &#34;Forbid&#34;: forbids concurrent runs, skipping next run if previous run hasn&#39;t finished yet; - &#34;Replace&#34;: cancels currently running job and replaces it with a new one</TD></TR>
-<TR><TD><CODE>failedJobsHistoryLimit</CODE><BR /><I>integer</I></TD><TD>The number of failed finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified.</TD></TR>
-<TR><TD><CODE>jobTemplate</CODE><BR /><I><a href="#jobtemplatespec-v2alpha1-batch">JobTemplateSpec</a></I></TD><TD>Specifies the job that will be created when executing a CronJob.</TD></TR>
-<TR><TD><CODE>schedule</CODE><BR /><I>string</I></TD><TD>The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.</TD></TR>
-<TR><TD><CODE>startingDeadlineSeconds</CODE><BR /><I>integer</I></TD><TD>Optional deadline in seconds for starting the job if it misses scheduled time for any reason.  Missed jobs executions will be counted as failed ones.</TD></TR>
-<TR><TD><CODE>successfulJobsHistoryLimit</CODE><BR /><I>integer</I></TD><TD>The number of successful finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified.</TD></TR>
-<TR><TD><CODE>suspend</CODE><BR /><I>boolean</I></TD><TD>This flag tells the controller to suspend subsequent executions, it does not apply to already started executions.  Defaults to false.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="cronjobstatus-v2alpha1-batch">CronJobStatus v2alpha1 batch</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjob-v2alpha1-batch">CronJob [batch/v2alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>active</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a> array</I></TD><TD>A list of pointers to currently running jobs.</TD></TR>
-<TR><TD><CODE>lastScheduleTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Information when was the last time the job was successfully scheduled.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="cronjoblist-v2alpha1-batch">CronJobList v2alpha1 batch</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#cronjob-v2alpha1-batch">CronJob</a> array</I></TD><TD>items is the list of CronJobs.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-cronjob-v2alpha1-batch-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-cronjob-v2alpha1-batch">Create</H2>
-<P>create a CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-cronjob-v2alpha1-batch">Patch</H2>
-<P>partially update the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-cronjob-v2alpha1-batch">Replace</H2>
-<P>replace the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-cronjob-v2alpha1-batch">Delete</H2>
-<P>delete a CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-cronjob-v2alpha1-batch">Delete Collection</H2>
-<P>delete collection of CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-cronjob-v2alpha1-batch-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-cronjob-v2alpha1-batch">Read</H2>
-<P>read the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-cronjob-v2alpha1-batch">List</H2>
-<P>list or watch objects of kind CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjoblist-v2alpha1-batch">CronJobList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-cronjob-v2alpha1-batch">List All Namespaces</H2>
-<P>list or watch objects of kind CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/cronjobs</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjoblist-v2alpha1-batch">CronJobList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-cronjob-v2alpha1-batch">Watch</H2>
-<P>watch changes to an object of kind CronJob. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/watch/namespaces/{namespace}/cronjobs/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-cronjob-v2alpha1-batch">Watch List</H2>
-<P>watch individual changes to a list of CronJob. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/watch/namespaces/{namespace}/cronjobs</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-cronjob-v2alpha1-batch">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of CronJob. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/watch/cronjobs</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-cronjob-v2alpha1-batch-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-cronjob-v2alpha1-batch">Patch Status</H2>
-<P>partially update status of the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-cronjob-v2alpha1-batch">Read Status</H2>
-<P>read status of the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-cronjob-v2alpha1-batch">Replace Status</H2>
-<P>replace status of the specified CronJob</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CronJob</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#cronjob-v2alpha1-batch">CronJob</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="crossversionobjectreference-v2beta2-autoscaling">CrossVersionObjectReference v2beta2 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>CrossVersionObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#crossversionobjectreference-v1-autoscaling">v1</a>
-<a href="#crossversionobjectreference-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerspec-v2beta2-autoscaling">HorizontalPodAutoscalerSpec [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricsource-v2beta2-autoscaling">ObjectMetricSource [autoscaling/v2beta2]</a></LI>
-  <LI><a href="#objectmetricstatus-v2beta2-autoscaling">ObjectMetricStatus [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>API version of the referent</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="crossversionobjectreference-v2beta1-autoscaling">CrossVersionObjectReference v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>CrossVersionObjectReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#crossversionobjectreference-v1-autoscaling">v1</a>
-<a href="#crossversionobjectreference-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerspec-v2beta1-autoscaling">HorizontalPodAutoscalerSpec [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#objectmetricsource-v2beta1-autoscaling">ObjectMetricSource [autoscaling/v2beta1]</a></LI>
-  <LI><a href="#objectmetricstatus-v2beta1-autoscaling">ObjectMetricStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>API version of the referent</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcecolumndefinition-v1beta1-apiextensions-k8s-io">CustomResourceColumnDefinition v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceColumnDefinition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcecolumndefinition-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#customresourcedefinitionversion-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionVersion [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>JSONPath</CODE><BR /><I>string</I></TD><TD>JSONPath is a simple JSON path (i.e. with array notation) which is evaluated against each custom resource to produce the value for this column.</TD></TR>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD>description is a human readable description of this column.</TD></TR>
-<TR><TD><CODE>format</CODE><BR /><I>string</I></TD><TD>format is an optional OpenAPI type definition for this column. The &#39;name&#39; format is applied to the primary identifier column to assist in clients identifying column is the resource name. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is a human readable name for the column.</TD></TR>
-<TR><TD><CODE>priority</CODE><BR /><I>integer</I></TD><TD>priority is an integer defining the relative importance of this column compared to others. Lower numbers are considered higher priority. Columns that may be omitted in limited space scenarios should be given a priority greater than 0.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is an OpenAPI type definition for this column. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourceconversion-v1beta1-apiextensions-k8s-io">CustomResourceConversion v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceConversion</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourceconversion-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conversionReviewVersions</CODE><BR /><I>string array</I></TD><TD>conversionReviewVersions is an ordered list of preferred `ConversionReview` versions the Webhook expects. The API server will use the first version in the list which it supports. If none of the versions specified in this list are supported by API server, conversion will fail for the custom resource. If a persisted Webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail. Defaults to `[&#34;v1beta1&#34;]`.</TD></TR>
-<TR><TD><CODE>strategy</CODE><BR /><I>string</I></TD><TD>strategy specifies how custom resources are converted between versions. Allowed values are: - `None`: The converter only change the apiVersion and would not touch any other field in the custom resource. - `Webhook`: API Server will call to an external webhook to do the conversion. Additional information   is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhookClientConfig to be set.</TD></TR>
-<TR><TD><CODE>webhookClientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1beta1-apiextensions-k8s-io">WebhookClientConfig</a></I></TD><TD>webhookClientConfig is the instructions for how to call the webhook if strategy is `Webhook`. Required when `strategy` is set to `Webhook`.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceDefinition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinition-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionlist-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionList [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec</a></I></TD><TD>spec describes how the user wants the resources to appear</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#customresourcedefinitionstatus-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionStatus</a></I></TD><TD>status indicates the actual state of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec v1beta1 apiextensions</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>additionalPrinterColumns</CODE><BR /><I><a href="#customresourcecolumndefinition-v1beta1-apiextensions-k8s-io">CustomResourceColumnDefinition</a> array</I></TD><TD>additionalPrinterColumns specifies additional columns returned in Table output. See https://kubernetes.io/docs/reference/using-api/api-concepts/#receiving-resources-as-tables for details. If present, this field configures columns for all versions. Top-level and per-version columns are mutually exclusive. If no top-level or per-version columns are specified, a single column displaying the age of the custom resource is used.</TD></TR>
-<TR><TD><CODE>conversion</CODE><BR /><I><a href="#customresourceconversion-v1beta1-apiextensions-k8s-io">CustomResourceConversion</a></I></TD><TD>conversion defines conversion settings for the CRD.</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>group is the API group of the defined custom resource. The custom resources are served under `/apis/&lt;group&gt;/...`. Must match the name of the CustomResourceDefinition (in the form `&lt;names.plural&gt;.&lt;group&gt;`).</TD></TR>
-<TR><TD><CODE>names</CODE><BR /><I><a href="#customresourcedefinitionnames-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionNames</a></I></TD><TD>names specify the resource and kind names for the custom resource.</TD></TR>
-<TR><TD><CODE>preserveUnknownFields</CODE><BR /><I>boolean</I></TD><TD>preserveUnknownFields indicates that object fields which are not specified in the OpenAPI schema should be preserved when persisting to storage. apiVersion, kind, metadata and known fields inside metadata are always preserved. If false, schemas must be defined for all versions. Defaults to true in v1beta for backwards compatibility. Deprecated: will be required to be false in v1. Preservation of unknown fields can be specified in the validation schema using the `x-kubernetes-preserve-unknown-fields: true` extension. See https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#pruning-versus-preserving-unknown-fields for details.</TD></TR>
-<TR><TD><CODE>scope</CODE><BR /><I>string</I></TD><TD>scope indicates whether the defined custom resource is cluster- or namespace-scoped. Allowed values are `Cluster` and `Namespaced`. Default is `Namespaced`.</TD></TR>
-<TR><TD><CODE>subresources</CODE><BR /><I><a href="#customresourcesubresources-v1beta1-apiextensions-k8s-io">CustomResourceSubresources</a></I></TD><TD>subresources specify what subresources the defined custom resource has. If present, this field configures subresources for all versions. Top-level and per-version subresources are mutually exclusive.</TD></TR>
-<TR><TD><CODE>validation</CODE><BR /><I><a href="#customresourcevalidation-v1beta1-apiextensions-k8s-io">CustomResourceValidation</a></I></TD><TD>validation describes the schema used for validation and pruning of the custom resource. If present, this validation schema is used to validate all versions. Top-level and per-version schemas are mutually exclusive.</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>version is the API version of the defined custom resource. The custom resources are served under `/apis/&lt;group&gt;/&lt;version&gt;/...`. Must match the name of the first item in the `versions` list if `version` and `versions` are both specified. Optional if `versions` is specified. Deprecated: use `versions` instead.</TD></TR>
-<TR><TD><CODE>versions</CODE><BR /><I><a href="#customresourcedefinitionversion-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionVersion</a> array</I></TD><TD>versions is the list of all API versions of the defined custom resource. Optional if `version` is specified. The name of the first item in the `versions` list must match the `version` field if `version` and `versions` are both specified. Version names are used to compute the order in which served versions are listed in API discovery. If the version string is &#34;kube-like&#34;, it will sort above non &#34;kube-like&#34; version strings, which are ordered lexicographically. &#34;Kube-like&#34; versions start with a &#34;v&#34;, then are followed by a number (the major version), then optionally the string &#34;alpha&#34; or &#34;beta&#34; and another number (the minor version). These are sorted first by GA &gt; beta &gt; alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="customresourcedefinitionstatus-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionStatus v1beta1 apiextensions</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>acceptedNames</CODE><BR /><I><a href="#customresourcedefinitionnames-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionNames</a></I></TD><TD>acceptedNames are the names that are actually being used to serve discovery. They may be different than the names in spec.</TD></TR>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionCondition</a> array</I></TD><TD>conditions indicate state for particular aspects of a CustomResourceDefinition</TD></TR>
-<TR><TD><CODE>storedVersions</CODE><BR /><I>string array</I></TD><TD>storedVersions lists all versions of CustomResources that were ever persisted. Tracking these versions allows a migration path for stored versions in etcd. The field is mutable so a migration controller can finish a migration to another version (ensuring no old objects are left in storage), and then remove the rest of the versions from this list. Versions may not be removed from `spec.versions` while they exist in this list.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="customresourcedefinitionlist-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionList v1beta1 apiextensions</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a> array</I></TD><TD>items list individual CustomResourceDefinition objects</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-customresourcedefinition-v1beta1-apiextensions-k8s-io">Create</H2>
-<P>create a CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-customresourcedefinition-v1beta1-apiextensions-k8s-io">Patch</H2>
-<P>partially update the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-customresourcedefinition-v1beta1-apiextensions-k8s-io">Replace</H2>
-<P>replace the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-customresourcedefinition-v1beta1-apiextensions-k8s-io">Delete</H2>
-<P>delete a CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io">Delete Collection</H2>
-<P>delete collection of CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-customresourcedefinition-v1beta1-apiextensions-k8s-io">Read</H2>
-<P>read the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-customresourcedefinition-v1beta1-apiextensions-k8s-io">List</H2>
-<P>list or watch objects of kind CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinitionlist-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-customresourcedefinition-v1beta1-apiextensions-k8s-io">Watch</H2>
-<P>watch changes to an object of kind CustomResourceDefinition. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1beta1/watch/customresourcedefinitions/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of CustomResourceDefinition. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1beta1/watch/customresourcedefinitions</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io">Patch Status</H2>
-<P>partially update status of the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io">Read Status</H2>
-<P>read status of the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io">Replace Status</H2>
-<P>replace status of the specified CustomResourceDefinition</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the CustomResourceDefinition</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#customresourcedefinition-v1beta1-apiextensions-k8s-io">CustomResourceDefinition</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionCondition v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceDefinitionCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinitioncondition-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionstatus-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionStatus [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>lastTransitionTime last time the condition transitioned from one status to another.</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>message is a human-readable message indicating details about last transition.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>reason is a unique, one-word, CamelCase reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>status is the status of the condition. Can be True, False, Unknown.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is the type of the condition. Types include Established, NamesAccepted and Terminating.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcedefinitionnames-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionNames v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceDefinitionNames</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinitionnames-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#customresourcedefinitionstatus-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionStatus [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>categories</CODE><BR /><I>string array</I></TD><TD>categories is a list of grouped resources this custom resource belongs to (e.g. &#39;all&#39;). This is published in API discovery documents, and used by clients to support invocations like `kubectl get all`.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>kind is the serialized kind of the resource. It is normally CamelCase and singular. Custom resource instances will use this value as the `kind` attribute in API calls.</TD></TR>
-<TR><TD><CODE>listKind</CODE><BR /><I>string</I></TD><TD>listKind is the serialized kind of the list for this resource. Defaults to &#34;`kind`List&#34;.</TD></TR>
-<TR><TD><CODE>plural</CODE><BR /><I>string</I></TD><TD>plural is the plural name of the resource to serve. The custom resources are served under `/apis/&lt;group&gt;/&lt;version&gt;/.../&lt;plural&gt;`. Must match the name of the CustomResourceDefinition (in the form `&lt;names.plural&gt;.&lt;group&gt;`). Must be all lowercase.</TD></TR>
-<TR><TD><CODE>shortNames</CODE><BR /><I>string array</I></TD><TD>shortNames are short names for the resource, exposed in API discovery documents, and used by clients to support invocations like `kubectl get &lt;shortname&gt;`. It must be all lowercase.</TD></TR>
-<TR><TD><CODE>singular</CODE><BR /><I>string</I></TD><TD>singular is the singular name of the resource. It must be all lowercase. Defaults to lowercased `kind`.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcedefinitionversion-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionVersion v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceDefinitionVersion</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcedefinitionversion-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>additionalPrinterColumns</CODE><BR /><I><a href="#customresourcecolumndefinition-v1beta1-apiextensions-k8s-io">CustomResourceColumnDefinition</a> array</I></TD><TD>additionalPrinterColumns specifies additional columns returned in Table output. See https://kubernetes.io/docs/reference/using-api/api-concepts/#receiving-resources-as-tables for details. Top-level and per-version columns are mutually exclusive. Per-version columns must not all be set to identical values (top-level columns should be used instead). If no top-level or per-version columns are specified, a single column displaying the age of the custom resource is used.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the version name, e.g. “v1”, “v2beta1”, etc. The custom resources are served under this version at `/apis/&lt;group&gt;/&lt;version&gt;/...` if `served` is true.</TD></TR>
-<TR><TD><CODE>schema</CODE><BR /><I><a href="#customresourcevalidation-v1beta1-apiextensions-k8s-io">CustomResourceValidation</a></I></TD><TD>schema describes the schema used for validation and pruning of this version of the custom resource. Top-level and per-version schemas are mutually exclusive. Per-version schemas must not all be set to identical values (top-level validation schema should be used instead).</TD></TR>
-<TR><TD><CODE>served</CODE><BR /><I>boolean</I></TD><TD>served is a flag enabling/disabling this version from being served via REST APIs</TD></TR>
-<TR><TD><CODE>storage</CODE><BR /><I>boolean</I></TD><TD>storage indicates this version should be used when persisting custom resources to storage. There must be exactly one version with storage=true.</TD></TR>
-<TR><TD><CODE>subresources</CODE><BR /><I><a href="#customresourcesubresources-v1beta1-apiextensions-k8s-io">CustomResourceSubresources</a></I></TD><TD>subresources specify what subresources this version of the defined custom resource have. Top-level and per-version subresources are mutually exclusive. Per-version subresources must not all be set to identical values (top-level subresources should be used instead).</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcesubresourcescale-v1beta1-apiextensions-k8s-io">CustomResourceSubresourceScale v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceSubresourceScale</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcesubresourcescale-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcesubresources-v1beta1-apiextensions-k8s-io">CustomResourceSubresources [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>labelSelectorPath</CODE><BR /><I>string</I></TD><TD>labelSelectorPath defines the JSON path inside of a custom resource that corresponds to Scale `status.selector`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status` or `.spec`. Must be set to work with HorizontalPodAutoscaler. The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form. More info: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource If there is no value under the given path in the custom resource, the `status.selector` value in the `/scale` subresource will default to the empty string.</TD></TR>
-<TR><TD><CODE>specReplicasPath</CODE><BR /><I>string</I></TD><TD>specReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `spec.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.spec`. If there is no value under the given path in the custom resource, the `/scale` subresource will return an error on GET.</TD></TR>
-<TR><TD><CODE>statusReplicasPath</CODE><BR /><I>string</I></TD><TD>statusReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `status.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status`. If there is no value under the given path in the custom resource, the `status.replicas` value in the `/scale` subresource will default to 0.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io">CustomResourceSubresourceStatus v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceSubresourceStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcesubresourcestatus-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcesubresources-v1beta1-apiextensions-k8s-io">CustomResourceSubresources [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H1 id="customresourcesubresources-v1beta1-apiextensions-k8s-io">CustomResourceSubresources v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceSubresources</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcesubresources-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#customresourcedefinitionversion-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionVersion [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>scale</CODE><BR /><I><a href="#customresourcesubresourcescale-v1beta1-apiextensions-k8s-io">CustomResourceSubresourceScale</a></I></TD><TD>scale indicates the custom resource should serve a `/scale` subresource that returns an `autoscaling/v1` Scale object.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io">CustomResourceSubresourceStatus</a></I></TD><TD>status indicates the custom resource should serve a `/status` subresource. When enabled: 1. requests to the custom resource primary endpoint ignore changes to the `status` stanza of the object. 2. requests to the custom resource `/status` subresource ignore changes to anything other than the `status` stanza of the object.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="customresourcevalidation-v1beta1-apiextensions-k8s-io">CustomResourceValidation v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>CustomResourceValidation</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#customresourcevalidation-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcedefinitionspec-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionSpec [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#customresourcedefinitionversion-v1beta1-apiextensions-k8s-io">CustomResourceDefinitionVersion [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>openAPIV3Schema</CODE><BR /><I><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps</a></I></TD><TD>openAPIV3Schema is the OpenAPI v3 schema to use for validation and pruning.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="endpointport-v1beta1-discovery-k8s-io">EndpointPort v1beta1 discovery.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>discovery.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>EndpointPort</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#endpointport-v1-core">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#endpointslice-v1beta1-discovery-k8s-io">EndpointSlice [discovery/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>appProtocol</CODE><BR /><I>string</I></TD><TD>The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of this port. All ports in an EndpointSlice must have a unique name. If the EndpointSlice is dervied from a Kubernetes service, this corresponds to the Service.ports[].name. Name must either be an empty string or pass DNS_LABEL validation: * must be no more than 63 characters long. * must consist of lower case alphanumeric characters or &#39;-&#39;. * must start and end with an alphanumeric character. Default is empty string.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>The port number of the endpoint. If this is not specified, ports are not restricted and must be interpreted in the context of the specific consumer.</TD></TR>
-<TR><TD><CODE>protocol</CODE><BR /><I>string</I></TD><TD>The IP protocol for this port. Must be UDP, TCP, or SCTP. Default is TCP.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="event-v1beta1-events-k8s-io">Event v1beta1 events.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>events.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Event</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#event-v1-core">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#eventlist-v1beta1-events-k8s-io">EventList [events/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>action</CODE><BR /><I>string</I></TD><TD>What action was taken/failed regarding to the regarding object.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>deprecatedCount</CODE><BR /><I>integer</I></TD><TD>Deprecated field assuring backward compatibility with core.v1 Event type</TD></TR>
-<TR><TD><CODE>deprecatedFirstTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Deprecated field assuring backward compatibility with core.v1 Event type</TD></TR>
-<TR><TD><CODE>deprecatedLastTimestamp</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Deprecated field assuring backward compatibility with core.v1 Event type</TD></TR>
-<TR><TD><CODE>deprecatedSource</CODE><BR /><I><a href="#eventsource-v1-core">EventSource</a></I></TD><TD>Deprecated field assuring backward compatibility with core.v1 Event type</TD></TR>
-<TR><TD><CODE>eventTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>Required. Time when this Event was first observed.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>note</CODE><BR /><I>string</I></TD><TD>Optional. A human-readable description of the status of this operation. Maximal length of the note is 1kB, but libraries should be prepared to handle values up to 64kB.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Why the action was taken.</TD></TR>
-<TR><TD><CODE>regarding</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>The object this Event is about. In most cases it&#39;s an Object reporting controller implements. E.g. ReplicaSetController implements ReplicaSets and this event is emitted because it acts on some changes in a ReplicaSet object.</TD></TR>
-<TR><TD><CODE>related</CODE><BR /><I><a href="#objectreference-v1-core">ObjectReference</a></I></TD><TD>Optional secondary object for more complex actions. E.g. when regarding object triggers a creation or deletion of related object.</TD></TR>
-<TR><TD><CODE>reportingController</CODE><BR /><I>string</I></TD><TD>Name of the controller that emitted this Event, e.g. `kubernetes.io/kubelet`.</TD></TR>
-<TR><TD><CODE>reportingInstance</CODE><BR /><I>string</I></TD><TD>ID of the controller instance, e.g. `kubelet-xyzf`.</TD></TR>
-<TR><TD><CODE>series</CODE><BR /><I><a href="#eventseries-v1beta1-events-k8s-io">EventSeries</a></I></TD><TD>Data about the Event series this event represents or nil if it&#39;s a singleton Event.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>Type of this event (Normal, Warning), new types could be added in the future.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="eventlist-v1beta1-events-k8s-io">EventList v1beta1 events</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#event-v1beta1-events-k8s-io">Event</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-event-v1beta1-events-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-event-v1beta1-events-k8s-io">Create</H2>
-<P>create an Event</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-event-v1beta1-events-k8s-io">Patch</H2>
-<P>partially update the specified Event</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-event-v1beta1-events-k8s-io">Replace</H2>
-<P>replace the specified Event</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-event-v1beta1-events-k8s-io">Delete</H2>
-<P>delete an Event</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-event-v1beta1-events-k8s-io">Delete Collection</H2>
-<P>delete collection of Event</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-event-v1beta1-events-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-event-v1beta1-events-k8s-io">Read</H2>
-<P>read the specified Event</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#event-v1beta1-events-k8s-io">Event</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-event-v1beta1-events-k8s-io">List</H2>
-<P>list or watch objects of kind Event</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/events.k8s.io/v1beta1/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#eventlist-v1beta1-events-k8s-io">EventList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-event-v1beta1-events-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Event</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/events.k8s.io/v1beta1/events</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#eventlist-v1beta1-events-k8s-io">EventList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-event-v1beta1-events-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Event. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/events.k8s.io/v1beta1/watch/namespaces/{namespace}/events/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Event</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-event-v1beta1-events-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Event. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/events.k8s.io/v1beta1/watch/namespaces/{namespace}/events</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-event-v1beta1-events-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Event. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/events.k8s.io/v1beta1/watch/events</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="eventseries-v1beta1-events-k8s-io">EventSeries v1beta1 events.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>events.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>EventSeries</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#eventseries-v1-core">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#event-v1beta1-events-k8s-io">Event [events/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>count</CODE><BR /><I>integer</I></TD><TD>Number of occurrences in this series up to the last heartbeat time</TD></TR>
-<TR><TD><CODE>lastObservedTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>Time when last Event from the series was seen before last heartbeat.</TD></TR>
-<TR><TD><CODE>state</CODE><BR /><I>string</I></TD><TD>Information whether this series is ongoing or finished. Deprecated. Planned removal for 1.18</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="externaldocumentation-v1beta1-apiextensions-k8s-io">ExternalDocumentation v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ExternalDocumentation</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#externaldocumentation-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="externalmetricsource-v2beta1-autoscaling">ExternalMetricSource v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>ExternalMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#externalmetricsource-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta1-autoscaling">MetricSpec [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metricName</CODE><BR /><I>string</I></TD><TD>metricName is the name of the metric in question.</TD></TR>
-<TR><TD><CODE>metricSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>metricSelector is used to identify a specific time series within a given metric.</TD></TR>
-<TR><TD><CODE>targetAverageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>targetAverageValue is the target per-pod value of global metric (as a quantity). Mutually exclusive with TargetValue.</TD></TR>
-<TR><TD><CODE>targetValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>targetValue is the target value of the metric (as a quantity). Mutually exclusive with TargetAverageValue.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="externalmetricstatus-v2beta1-autoscaling">ExternalMetricStatus v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>ExternalMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#externalmetricstatus-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta1-autoscaling">MetricStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>currentAverageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>currentAverageValue is the current value of metric averaged over autoscaled pods.</TD></TR>
-<TR><TD><CODE>currentValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>currentValue is the current value of the metric (as a quantity)</TD></TR>
-<TR><TD><CODE>metricName</CODE><BR /><I>string</I></TD><TD>metricName is the name of a metric used for autoscaling in metric system.</TD></TR>
-<TR><TD><CODE>metricSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>metricSelector is used to identify a specific time series within a given metric.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="httpingresspath-v1beta1-extensions">HTTPIngressPath v1beta1 extensions</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>HTTPIngressPath</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#httpingressrulevalue-v1beta1-extensions">HTTPIngressRuleValue [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>backend</CODE><BR /><I><a href="#ingressbackend-v1beta1-extensions">IngressBackend</a></I></TD><TD>Backend defines the referenced service endpoint to which the traffic will be forwarded to.</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional &#34;path&#34; part of a URL as defined by RFC 3986. Paths must begin with a &#39;/&#39;. When unspecified, all paths from incoming requests are matched.</TD></TR>
-<TR><TD><CODE>pathType</CODE><BR /><I>string</I></TD><TD>PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by &#39;/&#39;. Matching is   done on a path element by element basis. A path element refers is the   list of labels in the path split by the &#39;/&#39; separator. A request is a   match for path p if every p is an element-wise prefix of p of the   request path. Note that if the last element of the path is a substring   of the last element in request path, it is not a match (e.g. /foo/bar   matches /foo/bar/baz, but does not match /foo/barbaz). * ImplementationSpecific: Interpretation of the Path matching is up to   the IngressClass. Implementations can treat this as a separate PathType   or treat it identically to Prefix or Exact path types. Implementations are required to support all path types. Defaults to ImplementationSpecific.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="httpingressrulevalue-v1beta1-extensions">HTTPIngressRuleValue v1beta1 extensions</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>HTTPIngressRuleValue</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressrule-v1beta1-extensions">IngressRule [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>paths</CODE><BR /><I><a href="#httpingresspath-v1beta1-extensions">HTTPIngressPath</a> array</I></TD><TD>A collection of paths that map requests to backends.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler v2beta2 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta2</CODE></TD><TD><CODE>HorizontalPodAutoscaler</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#horizontalpodautoscaler-v1-autoscaling">v1</a>
-<a href="#horizontalpodautoscaler-v2beta1-autoscaling">v2beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerlist-v2beta2-autoscaling">HorizontalPodAutoscalerList [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>metadata is the standard object metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#horizontalpodautoscalerspec-v2beta2-autoscaling">HorizontalPodAutoscalerSpec</a></I></TD><TD>spec is the specification for the behaviour of the autoscaler. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#horizontalpodautoscalerstatus-v2beta2-autoscaling">HorizontalPodAutoscalerStatus</a></I></TD><TD>status is the current information about the autoscaler.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerspec-v2beta2-autoscaling">HorizontalPodAutoscalerSpec v2beta2 autoscaling</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>behavior</CODE><BR /><I><a href="#horizontalpodautoscalerbehavior-v2beta2-autoscaling">HorizontalPodAutoscalerBehavior</a></I></TD><TD>behavior configures the scaling behavior of the target in both Up and Down directions (scaleUp and scaleDown fields respectively). If not set, the default HPAScalingRules for scale up and scale down are used.</TD></TR>
-<TR><TD><CODE>maxReplicas</CODE><BR /><I>integer</I></TD><TD>maxReplicas is the upper limit for the number of replicas to which the autoscaler can scale up. It cannot be less that minReplicas.</TD></TR>
-<TR><TD><CODE>metrics</CODE><BR /><I><a href="#metricspec-v2beta2-autoscaling">MetricSpec</a> array</I></TD><TD>metrics contains the specifications for which to use to calculate the desired replica count (the maximum replica count across all metrics will be used).  The desired replica count is calculated multiplying the ratio between the target value and the current value by the current number of pods.  Ergo, metrics used must decrease as the pod count is increased, and vice-versa.  See the individual metric source types for more information about how each type of metric must respond. If not set, the default metric will be set to 80% average CPU utilization.</TD></TR>
-<TR><TD><CODE>minReplicas</CODE><BR /><I>integer</I></TD><TD>minReplicas is the lower limit for the number of replicas to which the autoscaler can scale down.  It defaults to 1 pod.  minReplicas is allowed to be 0 if the alpha feature gate HPAScaleToZero is enabled and at least one Object or External metric is configured.  Scaling is active as long as at least one metric value is available.</TD></TR>
-<TR><TD><CODE>scaleTargetRef</CODE><BR /><I><a href="#crossversionobjectreference-v2beta2-autoscaling">CrossVersionObjectReference</a></I></TD><TD>scaleTargetRef points to the target resource to scale, and is used to the pods for which metrics should be collected, as well as to actually change the replica count.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerstatus-v2beta2-autoscaling">HorizontalPodAutoscalerStatus v2beta2 autoscaling</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler [autoscaling/v2beta2]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#horizontalpodautoscalercondition-v2beta2-autoscaling">HorizontalPodAutoscalerCondition</a> array</I></TD><TD>conditions is the set of conditions required for this autoscaler to scale its target, and indicates whether or not those conditions are met.</TD></TR>
-<TR><TD><CODE>currentMetrics</CODE><BR /><I><a href="#metricstatus-v2beta2-autoscaling">MetricStatus</a> array</I></TD><TD>currentMetrics is the last read state of the metrics used by this autoscaler.</TD></TR>
-<TR><TD><CODE>currentReplicas</CODE><BR /><I>integer</I></TD><TD>currentReplicas is current number of replicas of pods managed by this autoscaler, as last seen by the autoscaler.</TD></TR>
-<TR><TD><CODE>desiredReplicas</CODE><BR /><I>integer</I></TD><TD>desiredReplicas is the desired number of replicas of pods managed by this autoscaler, as last calculated by the autoscaler.</TD></TR>
-<TR><TD><CODE>lastScaleTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>lastScaleTime is the last time the HorizontalPodAutoscaler scaled the number of pods, used by the autoscaler to control how often the number of pods is changed.</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>observedGeneration is the most recent generation observed by this autoscaler.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerlist-v2beta2-autoscaling">HorizontalPodAutoscalerList v2beta2 autoscaling</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a> array</I></TD><TD>items is the list of horizontal pod autoscaler objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>metadata is the standard list metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-horizontalpodautoscaler-v2beta2-autoscaling">Create</H2>
-<P>create a HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-horizontalpodautoscaler-v2beta2-autoscaling">Patch</H2>
-<P>partially update the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-horizontalpodautoscaler-v2beta2-autoscaling">Replace</H2>
-<P>replace the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-horizontalpodautoscaler-v2beta2-autoscaling">Delete</H2>
-<P>delete a HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-horizontalpodautoscaler-v2beta2-autoscaling">Delete Collection</H2>
-<P>delete collection of HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-horizontalpodautoscaler-v2beta2-autoscaling">Read</H2>
-<P>read the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-horizontalpodautoscaler-v2beta2-autoscaling">List</H2>
-<P>list or watch objects of kind HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscalerlist-v2beta2-autoscaling">HorizontalPodAutoscalerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling">List All Namespaces</H2>
-<P>list or watch objects of kind HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/horizontalpodautoscalers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscalerlist-v2beta2-autoscaling">HorizontalPodAutoscalerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-horizontalpodautoscaler-v2beta2-autoscaling">Watch</H2>
-<P>watch changes to an object of kind HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/watch/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-horizontalpodautoscaler-v2beta2-autoscaling">Watch List</H2>
-<P>watch individual changes to a list of HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/watch/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/watch/horizontalpodautoscalers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-horizontalpodautoscaler-v2beta2-autoscaling">Patch Status</H2>
-<P>partially update status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-horizontalpodautoscaler-v2beta2-autoscaling">Read Status</H2>
-<P>read status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-horizontalpodautoscaler-v2beta2-autoscaling">Replace Status</H2>
-<P>replace status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v2beta2-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>HorizontalPodAutoscaler</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#horizontalpodautoscaler-v1-autoscaling">v1</a>
-<a href="#horizontalpodautoscaler-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerlist-v2beta1-autoscaling">HorizontalPodAutoscalerList [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>metadata is the standard object metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#horizontalpodautoscalerspec-v2beta1-autoscaling">HorizontalPodAutoscalerSpec</a></I></TD><TD>spec is the specification for the behaviour of the autoscaler. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#horizontalpodautoscalerstatus-v2beta1-autoscaling">HorizontalPodAutoscalerStatus</a></I></TD><TD>status is the current information about the autoscaler.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerspec-v2beta1-autoscaling">HorizontalPodAutoscalerSpec v2beta1 autoscaling</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>maxReplicas</CODE><BR /><I>integer</I></TD><TD>maxReplicas is the upper limit for the number of replicas to which the autoscaler can scale up. It cannot be less that minReplicas.</TD></TR>
-<TR><TD><CODE>metrics</CODE><BR /><I><a href="#metricspec-v2beta1-autoscaling">MetricSpec</a> array</I></TD><TD>metrics contains the specifications for which to use to calculate the desired replica count (the maximum replica count across all metrics will be used).  The desired replica count is calculated multiplying the ratio between the target value and the current value by the current number of pods.  Ergo, metrics used must decrease as the pod count is increased, and vice-versa.  See the individual metric source types for more information about how each type of metric must respond.</TD></TR>
-<TR><TD><CODE>minReplicas</CODE><BR /><I>integer</I></TD><TD>minReplicas is the lower limit for the number of replicas to which the autoscaler can scale down.  It defaults to 1 pod.  minReplicas is allowed to be 0 if the alpha feature gate HPAScaleToZero is enabled and at least one Object or External metric is configured.  Scaling is active as long as at least one metric value is available.</TD></TR>
-<TR><TD><CODE>scaleTargetRef</CODE><BR /><I><a href="#crossversionobjectreference-v2beta1-autoscaling">CrossVersionObjectReference</a></I></TD><TD>scaleTargetRef points to the target resource to scale, and is used to the pods for which metrics should be collected, as well as to actually change the replica count.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerstatus-v2beta1-autoscaling">HorizontalPodAutoscalerStatus v2beta1 autoscaling</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>conditions</CODE><BR /><I><a href="#horizontalpodautoscalercondition-v2beta1-autoscaling">HorizontalPodAutoscalerCondition</a> array</I></TD><TD>conditions is the set of conditions required for this autoscaler to scale its target, and indicates whether or not those conditions are met.</TD></TR>
-<TR><TD><CODE>currentMetrics</CODE><BR /><I><a href="#metricstatus-v2beta1-autoscaling">MetricStatus</a> array</I></TD><TD>currentMetrics is the last read state of the metrics used by this autoscaler.</TD></TR>
-<TR><TD><CODE>currentReplicas</CODE><BR /><I>integer</I></TD><TD>currentReplicas is current number of replicas of pods managed by this autoscaler, as last seen by the autoscaler.</TD></TR>
-<TR><TD><CODE>desiredReplicas</CODE><BR /><I>integer</I></TD><TD>desiredReplicas is the desired number of replicas of pods managed by this autoscaler, as last calculated by the autoscaler.</TD></TR>
-<TR><TD><CODE>lastScaleTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>lastScaleTime is the last time the HorizontalPodAutoscaler scaled the number of pods, used by the autoscaler to control how often the number of pods is changed.</TD></TR>
-<TR><TD><CODE>observedGeneration</CODE><BR /><I>integer</I></TD><TD>observedGeneration is the most recent generation observed by this autoscaler.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="horizontalpodautoscalerlist-v2beta1-autoscaling">HorizontalPodAutoscalerList v2beta1 autoscaling</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a> array</I></TD><TD>items is the list of horizontal pod autoscaler objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>metadata is the standard list metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-horizontalpodautoscaler-v2beta1-autoscaling">Create</H2>
-<P>create a HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-horizontalpodautoscaler-v2beta1-autoscaling">Patch</H2>
-<P>partially update the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-horizontalpodautoscaler-v2beta1-autoscaling">Replace</H2>
-<P>replace the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-horizontalpodautoscaler-v2beta1-autoscaling">Delete</H2>
-<P>delete a HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-horizontalpodautoscaler-v2beta1-autoscaling">Delete Collection</H2>
-<P>delete collection of HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-horizontalpodautoscaler-v2beta1-autoscaling">Read</H2>
-<P>read the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-horizontalpodautoscaler-v2beta1-autoscaling">List</H2>
-<P>list or watch objects of kind HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscalerlist-v2beta1-autoscaling">HorizontalPodAutoscalerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling">List All Namespaces</H2>
-<P>list or watch objects of kind HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/horizontalpodautoscalers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscalerlist-v2beta1-autoscaling">HorizontalPodAutoscalerList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-horizontalpodautoscaler-v2beta1-autoscaling">Watch</H2>
-<P>watch changes to an object of kind HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/watch/namespaces/{namespace}/horizontalpodautoscalers/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-horizontalpodautoscaler-v2beta1-autoscaling">Watch List</H2>
-<P>watch individual changes to a list of HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/watch/namespaces/{namespace}/horizontalpodautoscalers</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of HorizontalPodAutoscaler. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/watch/horizontalpodautoscalers</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-horizontalpodautoscaler-v2beta1-autoscaling">Patch Status</H2>
-<P>partially update status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-horizontalpodautoscaler-v2beta1-autoscaling">Read Status</H2>
-<P>read status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-horizontalpodautoscaler-v2beta1-autoscaling">Replace Status</H2>
-<P>replace status of the specified HorizontalPodAutoscaler</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/autoscaling/v2beta1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the HorizontalPodAutoscaler</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#horizontalpodautoscaler-v2beta1-autoscaling">HorizontalPodAutoscaler</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="horizontalpodautoscalercondition-v2beta1-autoscaling">HorizontalPodAutoscalerCondition v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>HorizontalPodAutoscalerCondition</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#horizontalpodautoscalercondition-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerstatus-v2beta1-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>lastTransitionTime</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>lastTransitionTime is the last time the condition transitioned from one status to another</TD></TR>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>message is a human-readable explanation containing details about the transition</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>reason is the reason for the condition&#39;s last transition.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I>string</I></TD><TD>status is the status of the condition (True, False, Unknown)</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type describes the current condition</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="ingress-v1beta1-extensions">Ingress v1beta1 extensions</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Ingress</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingresslist-v1beta1-extensions">IngressList [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#ingressspec-v1beta1-extensions">IngressSpec</a></I></TD><TD>Spec is the desired state of the Ingress. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#ingressstatus-v1beta1-extensions">IngressStatus</a></I></TD><TD>Status is the current state of the Ingress. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingressspec-v1beta1-extensions">IngressSpec v1beta1 extensions</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingress-v1beta1-extensions">Ingress [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>backend</CODE><BR /><I><a href="#ingressbackend-v1beta1-extensions">IngressBackend</a></I></TD><TD>A default backend capable of servicing requests that don&#39;t match any rule. At least one of &#39;backend&#39; or &#39;rules&#39; must be specified. This field is optional to allow the loadbalancer controller or defaulting logic to specify a global default.</TD></TR>
-<TR><TD><CODE>ingressClassName</CODE><BR /><I>string</I></TD><TD>IngressClassName is the name of the IngressClass cluster resource. The associated IngressClass defines which controller will implement the resource. This replaces the deprecated `kubernetes.io/ingress.class` annotation. For backwards compatibility, when that annotation is set, it must be given precedence over this field. The controller may emit a warning if the field and annotation have different values. Implementations of this API should ignore Ingresses without a class specified. An IngressClass resource may be marked as default, which can be used to set a default value for this field. For more information, refer to the IngressClass documentation.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#ingressrule-v1beta1-extensions">IngressRule</a> array</I></TD><TD>A list of host rules used to configure the Ingress. If unspecified, or no rule matches, all traffic is sent to the default backend.</TD></TR>
-<TR><TD><CODE>tls</CODE><BR /><I><a href="#ingresstls-v1beta1-extensions">IngressTLS</a> array</I></TD><TD>TLS configuration. Currently the Ingress only supports a single TLS port, 443. If multiple members of this list specify different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension, if the ingress controller fulfilling the ingress supports SNI.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingressstatus-v1beta1-extensions">IngressStatus v1beta1 extensions</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingress-v1beta1-extensions">Ingress [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>loadBalancer</CODE><BR /><I><a href="#loadbalancerstatus-v1-core">LoadBalancerStatus</a></I></TD><TD>LoadBalancer contains the current status of the load-balancer.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="ingresslist-v1beta1-extensions">IngressList v1beta1 extensions</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#ingress-v1beta1-extensions">Ingress</a> array</I></TD><TD>Items is the list of Ingress.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-ingress-v1beta1-extensions-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-ingress-v1beta1-extensions">Create</H2>
-<P>create an Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/extensions/v1beta1/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-ingress-v1beta1-extensions">Patch</H2>
-<P>partially update the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-ingress-v1beta1-extensions">Replace</H2>
-<P>replace the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-ingress-v1beta1-extensions">Delete</H2>
-<P>delete an Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-ingress-v1beta1-extensions">Delete Collection</H2>
-<P>delete collection of Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/extensions/v1beta1/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-ingress-v1beta1-extensions-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-ingress-v1beta1-extensions">Read</H2>
-<P>read the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-ingress-v1beta1-extensions">List</H2>
-<P>list or watch objects of kind Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingresslist-v1beta1-extensions">IngressList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-ingress-v1beta1-extensions">List All Namespaces</H2>
-<P>list or watch objects of kind Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/ingresses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingresslist-v1beta1-extensions">IngressList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-ingress-v1beta1-extensions">Watch</H2>
-<P>watch changes to an object of kind Ingress. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/watch/namespaces/{namespace}/ingresses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-ingress-v1beta1-extensions">Watch List</H2>
-<P>watch individual changes to a list of Ingress. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/watch/namespaces/{namespace}/ingresses</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-ingress-v1beta1-extensions">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Ingress. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/watch/ingresses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-status-operations-ingress-v1beta1-extensions-strong-"><STRONG>Status Operations</STRONG></H2>
-<H2 id="patch-status-ingress-v1beta1-extensions">Patch Status</H2>
-<P>partially update status of the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="read-status-ingress-v1beta1-extensions">Read Status</H2>
-<P>read status of the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-status-ingress-v1beta1-extensions">Replace Status</H2>
-<P>replace status of the specified Ingress</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}/status</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Ingress</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#ingress-v1beta1-extensions">Ingress</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="ingressbackend-v1beta1-extensions">IngressBackend v1beta1 extensions</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressBackend</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#httpingresspath-v1beta1-extensions">HTTPIngressPath [extensions/v1beta1]</a></LI>
-  <LI><a href="#ingressspec-v1beta1-extensions">IngressSpec [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>resource</CODE><BR /><I><a href="#typedlocalobjectreference-v1-core">TypedLocalObjectReference</a></I></TD><TD>Resource is an ObjectRef to another Kubernetes resource in the namespace of the Ingress object. If resource is specified, serviceName and servicePort must not be specified.</TD></TR>
-<TR><TD><CODE>serviceName</CODE><BR /><I>string</I></TD><TD>Specifies the name of the referenced service.</TD></TR>
-<TR><TD><CODE>servicePort</CODE></TD><TD>Specifies the port of the referenced service.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="ingressrule-v1beta1-extensions">IngressRule v1beta1 extensions</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressspec-v1beta1-extensions">IngressSpec [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>host</CODE><BR /><I>string</I></TD><TD>Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the &#34;host&#34; part of the URI as defined in RFC 3986: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to    the IP in the Spec of the parent Ingress. 2. The `:` delimiter is not respected because ports are not allowed. 	  Currently the port of an Ingress is implicitly :80 for http and 	  :443 for https. Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.  Host can be &#34;precise&#34; which is a domain name without the terminating dot of a network host (e.g. &#34;foo.bar.com&#34;) or &#34;wildcard&#34;, which is a domain name prefixed with a single wildcard label (e.g. &#34;*.foo.com&#34;). The wildcard character &#39;\*&#39; must appear by itself as the first DNS label and matches only a single label. You cannot have a wildcard label by itself (e.g. Host == &#34;*&#34;). Requests will be matched against the Host field in the following way: 1. If Host is precise, the request matches this rule if the http host header is equal to Host. 2. If Host is a wildcard, then the request matches this rule if the http host header is to equal to the suffix (removing the first label) of the wildcard rule.</TD></TR>
-<TR><TD><CODE>http</CODE><BR /><I><a href="#httpingressrulevalue-v1beta1-extensions">HTTPIngressRuleValue</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="ingresstls-v1beta1-extensions">IngressTLS v1beta1 extensions</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>IngressTLS</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#ingressspec-v1beta1-extensions">IngressSpec [extensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>hosts</CODE><BR /><I>string array</I></TD><TD>Hosts are a list of hosts included in the TLS certificate. The values in this list must match the name/s used in the tlsSecret. Defaults to the wildcard host setting for the loadbalancer controller fulfilling this Ingress, if left unspecified.</TD></TR>
-<TR><TD><CODE>secretName</CODE><BR /><I>string</I></TD><TD>SecretName is the name of the secret used to terminate SSL traffic on 443. Field is left optional to allow SSL routing based on SNI hostname alone. If the SNI host in a listener conflicts with the &#34;Host&#34; header field used by an IngressRule, the SNI host is used for termination and value of the Host header is used for routing.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="json-v1beta1-apiextensions-k8s-io">JSON v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>JSON</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#json-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H1 id="jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>JSONSchemaProps</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jsonschemaprops-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourcevalidation-v1beta1-apiextensions-k8s-io">CustomResourceValidation [apiextensions/v1beta1]</a></LI>
-  <LI><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>$ref</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>$schema</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>additionalItems</CODE><BR /><I><a href="#jsonschemapropsorbool-v1beta1-apiextensions-k8s-io">JSONSchemaPropsOrBool</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>additionalProperties</CODE><BR /><I><a href="#jsonschemapropsorbool-v1beta1-apiextensions-k8s-io">JSONSchemaPropsOrBool</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>allOf</CODE><BR /><I><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>anyOf</CODE><BR /><I><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>default</CODE><BR /><I><a href="#json-v1beta1-apiextensions-k8s-io">JSON</a></I></TD><TD>default is a default value for undefined object fields. Defaulting is a beta feature under the CustomResourceDefaulting feature gate. CustomResourceDefinitions with defaults must be created using the v1 (or newer) CustomResourceDefinition API.</TD></TR>
-<TR><TD><CODE>definitions</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>dependencies</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>enum</CODE><BR /><I><a href="#json-v1beta1-apiextensions-k8s-io">JSON</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>example</CODE><BR /><I><a href="#json-v1beta1-apiextensions-k8s-io">JSON</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>exclusiveMaximum</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>exclusiveMinimum</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>externalDocs</CODE><BR /><I><a href="#externaldocumentation-v1beta1-apiextensions-k8s-io">ExternalDocumentation</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>format</CODE><BR /><I>string</I></TD><TD>format is an OpenAPI v3 format string. Unknown formats are ignored. The following formats are validated:  - bsonobjectid: a bson object ID, i.e. a 24 characters hex string - uri: an URI as parsed by Golang net/url.ParseRequestURI - email: an email address as parsed by Golang net/mail.ParseAddress - hostname: a valid representation for an Internet host name, as defined by RFC 1034, section 3.1 [RFC1034]. - ipv4: an IPv4 IP as parsed by Golang net.ParseIP - ipv6: an IPv6 IP as parsed by Golang net.ParseIP - cidr: a CIDR as parsed by Golang net.ParseCIDR - mac: a MAC address as parsed by Golang net.ParseMAC - uuid: an UUID that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid3: an UUID3 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid4: an UUID4 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - uuid5: an UUID5 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - isbn: an ISBN10 or ISBN13 number string like &#34;0321751043&#34; or &#34;978-0321751041&#34; - isbn10: an ISBN10 number string like &#34;0321751043&#34; - isbn13: an ISBN13 number string like &#34;978-0321751041&#34; - creditcard: a credit card number defined by the regex ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$ with any non digit characters mixed in - ssn: a U.S. social security number following the regex ^\d{3}[- ]?\d{2}[- ]?\d{4}$ - hexcolor: an hexadecimal color code like &#34;#FFFFFF: following the regex ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$ - rgbcolor: an RGB color code like rgb like &#34;rgb(255,255,2559&#34; - byte: base64 encoded binary data - password: any kind of string - date: a date string like &#34;2006-01-02&#34; as defined by full-date in RFC3339 - duration: a duration string like &#34;22 ns&#34; as parsed by Golang time.ParseDuration or compatible with Scala duration format - datetime: a date time string like &#34;2014-12-15T19:30:20.000Z&#34; as defined by date-time in RFC3339.</TD></TR>
-<TR><TD><CODE>id</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#jsonschemapropsorarray-v1beta1-apiextensions-k8s-io">JSONSchemaPropsOrArray</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>maxItems</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>maxLength</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>maxProperties</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>maximum</CODE><BR /><I>number</I></TD><TD></TD></TR>
-<TR><TD><CODE>minItems</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>minLength</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>minProperties</CODE><BR /><I>integer</I></TD><TD></TD></TR>
-<TR><TD><CODE>minimum</CODE><BR /><I>number</I></TD><TD></TD></TR>
-<TR><TD><CODE>multipleOf</CODE><BR /><I>number</I></TD><TD></TD></TR>
-<TR><TD><CODE>not</CODE><BR /><I><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>nullable</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>oneOf</CODE><BR /><I><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps</a> array</I></TD><TD></TD></TR>
-<TR><TD><CODE>pattern</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>patternProperties</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>properties</CODE><BR /><I>object</I></TD><TD></TD></TR>
-<TR><TD><CODE>required</CODE><BR /><I>string array</I></TD><TD></TD></TR>
-<TR><TD><CODE>title</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD></TD></TR>
-<TR><TD><CODE>uniqueItems</CODE><BR /><I>boolean</I></TD><TD></TD></TR>
-<TR><TD><CODE>x-kubernetes-embedded-resource</CODE><BR /><I>boolean</I></TD><TD>x-kubernetes-embedded-resource defines that the value is an embedded Kubernetes runtime.Object, with TypeMeta and ObjectMeta. The type must be object. It is allowed to further restrict the embedded object. kind, apiVersion and metadata are validated automatically. x-kubernetes-preserve-unknown-fields is allowed to be true, but does not have to be if the object is fully specified (up to kind, apiVersion, metadata).</TD></TR>
-<TR><TD><CODE>x-kubernetes-int-or-string</CODE><BR /><I>boolean</I></TD><TD>x-kubernetes-int-or-string specifies that this value is either an integer or a string. If this is true, an empty type is allowed and type as child of anyOf is permitted if following one of the following patterns:  1) anyOf:    - type: integer    - type: string 2) allOf:    - anyOf:      - type: integer      - type: string    - ... zero or more</TD></TR>
-<TR><TD><CODE>x-kubernetes-list-map-keys</CODE><BR /><I>string array</I></TD><TD>x-kubernetes-list-map-keys annotates an array with the x-kubernetes-list-type `map` by specifying the keys used as the index of the map.  This tag MUST only be used on lists that have the &#34;x-kubernetes-list-type&#34; extension set to &#34;map&#34;. Also, the values specified for this attribute must be a scalar typed field of the child structure (no nesting is supported).  The properties specified must either be required or have a default value, to ensure those properties are present for all list items.</TD></TR>
-<TR><TD><CODE>x-kubernetes-list-type</CODE><BR /><I>string</I></TD><TD>x-kubernetes-list-type annotates an array to further describe its topology. This extension must only be used on lists and may have 3 possible values:  1) `atomic`: the list is treated as a single entity, like a scalar.      Atomic lists will be entirely replaced when updated. This extension      may be used on any type of list (struct, scalar, ...). 2) `set`:      Sets are lists that must not have multiple items with the same value. Each      value must be a scalar, an object with x-kubernetes-map-type `atomic` or an      array with x-kubernetes-list-type `atomic`. 3) `map`:      These lists are like maps in that their elements have a non-index key      used to identify them. Order is preserved upon merge. The map tag      must only be used on a list with elements of type object. Defaults to atomic for arrays.</TD></TR>
-<TR><TD><CODE>x-kubernetes-map-type</CODE><BR /><I>string</I></TD><TD>x-kubernetes-map-type annotates an object to further describe its topology. This extension must only be used when type is object and may have 2 possible values:  1) `granular`:      These maps are actual maps (key-value pairs) and each fields are independent      from each other (they can each be manipulated by separate actors). This is      the default behaviour for all maps. 2) `atomic`: the list is treated as a single entity, like a scalar.      Atomic maps will be entirely replaced when updated.</TD></TR>
-<TR><TD><CODE>x-kubernetes-preserve-unknown-fields</CODE><BR /><I>boolean</I></TD><TD>x-kubernetes-preserve-unknown-fields stops the API server decoding step from pruning fields which are not specified in the validation schema. This affects fields recursively, but switches back to normal pruning behaviour if nested properties or additionalProperties are specified in the schema. This can either be true or undefined. False is forbidden.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="jsonschemapropsorarray-v1beta1-apiextensions-k8s-io">JSONSchemaPropsOrArray v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>JSONSchemaPropsOrArray</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jsonschemapropsorarray-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H1 id="jsonschemapropsorbool-v1beta1-apiextensions-k8s-io">JSONSchemaPropsOrBool v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>JSONSchemaPropsOrBool</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jsonschemapropsorbool-v1-apiextensions-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#jsonschemaprops-v1beta1-apiextensions-k8s-io">JSONSchemaProps [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-</TBODY>
-</TABLE>
-<H1 id="jobtemplatespec-v2alpha1-batch">JobTemplateSpec v2alpha1 batch</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>batch</CODE></TD><TD><CODE>v2alpha1</CODE></TD><TD><CODE>JobTemplateSpec</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#jobtemplatespec-v1beta1-batch">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#cronjobspec-v2alpha1-batch">CronJobSpec [batch/v2alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata of the jobs created from this template. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#jobspec-v1-batch">JobSpec</a></I></TD><TD>Specification of the desired behavior of the job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="lease-v1beta1-coordination-k8s-io">Lease v1beta1 coordination.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>coordination.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Lease</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#lease-v1-coordination-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#leaselist-v1beta1-coordination-k8s-io">LeaseList [coordination/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#leasespec-v1beta1-coordination-k8s-io">LeaseSpec</a></I></TD><TD>Specification of the Lease. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="leasespec-v1beta1-coordination-k8s-io">LeaseSpec v1beta1 coordination</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#lease-v1beta1-coordination-k8s-io">Lease [coordination/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>acquireTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>acquireTime is a time when the current lease was acquired.</TD></TR>
-<TR><TD><CODE>holderIdentity</CODE><BR /><I>string</I></TD><TD>holderIdentity contains the identity of the holder of a current lease.</TD></TR>
-<TR><TD><CODE>leaseDurationSeconds</CODE><BR /><I>integer</I></TD><TD>leaseDurationSeconds is a duration that candidates for a lease need to wait to force acquire it. This is measure against time of last observed RenewTime.</TD></TR>
-<TR><TD><CODE>leaseTransitions</CODE><BR /><I>integer</I></TD><TD>leaseTransitions is the number of transitions of a lease between holders.</TD></TR>
-<TR><TD><CODE>renewTime</CODE><BR /><I><a href="#microtime-v1-meta">MicroTime</a></I></TD><TD>renewTime is a time when the current holder of a lease has last updated the lease.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="leaselist-v1beta1-coordination-k8s-io">LeaseList v1beta1 coordination</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-lease-v1beta1-coordination-k8s-io">Create</H2>
-<P>create a Lease</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-lease-v1beta1-coordination-k8s-io">Patch</H2>
-<P>partially update the specified Lease</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-lease-v1beta1-coordination-k8s-io">Replace</H2>
-<P>replace the specified Lease</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-lease-v1beta1-coordination-k8s-io">Delete</H2>
-<P>delete a Lease</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-lease-v1beta1-coordination-k8s-io">Delete Collection</H2>
-<P>delete collection of Lease</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-lease-v1beta1-coordination-k8s-io">Read</H2>
-<P>read the specified Lease</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#lease-v1beta1-coordination-k8s-io">Lease</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-lease-v1beta1-coordination-k8s-io">List</H2>
-<P>list or watch objects of kind Lease</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1beta1/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#leaselist-v1beta1-coordination-k8s-io">LeaseList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-lease-v1beta1-coordination-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Lease</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1beta1/leases</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#leaselist-v1beta1-coordination-k8s-io">LeaseList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-lease-v1beta1-coordination-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Lease. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1beta1/watch/namespaces/{namespace}/leases/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Lease</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-lease-v1beta1-coordination-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Lease. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1beta1/watch/namespaces/{namespace}/leases</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Lease. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/coordination.k8s.io/v1beta1/watch/leases</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>LocalSubjectAccessReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#localsubjectaccessreview-v1-authorization-k8s-io">v1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#subjectaccessreviewspec-v1beta1-authorization-k8s-io">SubjectAccessReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated.  spec.namespace must be equal to the namespace you made the request against.  If empty, it is defaulted.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectaccessreviewstatus-v1beta1-authorization-k8s-io">SubjectAccessReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request is allowed or not</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-localsubjectaccessreview-v1beta1-authorization-k8s-io">Create</H2>
-<P>create a LocalSubjectAccessReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1beta1/namespaces/{namespace}/localsubjectaccessreviews</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="metricspec-v2beta1-autoscaling">MetricSpec v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>MetricSpec</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#metricspec-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerspec-v2beta1-autoscaling">HorizontalPodAutoscalerSpec [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>external</CODE><BR /><I><a href="#externalmetricsource-v2beta1-autoscaling">ExternalMetricSource</a></I></TD><TD>external refers to a global metric that is not associated with any Kubernetes object. It allows autoscaling based on information coming from components running outside of cluster (for example length of queue in cloud messaging service, or QPS from loadbalancer running outside of cluster).</TD></TR>
-<TR><TD><CODE>object</CODE><BR /><I><a href="#objectmetricsource-v2beta1-autoscaling">ObjectMetricSource</a></I></TD><TD>object refers to a metric describing a single kubernetes object (for example, hits-per-second on an Ingress object).</TD></TR>
-<TR><TD><CODE>pods</CODE><BR /><I><a href="#podsmetricsource-v2beta1-autoscaling">PodsMetricSource</a></I></TD><TD>pods refers to a metric describing each pod in the current scale target (for example, transactions-processed-per-second).  The values will be averaged together before being compared to the target value.</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I><a href="#resourcemetricsource-v2beta1-autoscaling">ResourceMetricSource</a></I></TD><TD>resource refers to a resource metric (such as those specified in requests and limits) known to Kubernetes describing each pod in the current scale target (e.g. CPU or memory). Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the &#34;pods&#34; source.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is the type of metric source.  It should be one of &#34;Object&#34;, &#34;Pods&#34; or &#34;Resource&#34;, each mapping to a matching field in the object.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="metricstatus-v2beta1-autoscaling">MetricStatus v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>MetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#metricstatus-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#horizontalpodautoscalerstatus-v2beta1-autoscaling">HorizontalPodAutoscalerStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>external</CODE><BR /><I><a href="#externalmetricstatus-v2beta1-autoscaling">ExternalMetricStatus</a></I></TD><TD>external refers to a global metric that is not associated with any Kubernetes object. It allows autoscaling based on information coming from components running outside of cluster (for example length of queue in cloud messaging service, or QPS from loadbalancer running outside of cluster).</TD></TR>
-<TR><TD><CODE>object</CODE><BR /><I><a href="#objectmetricstatus-v2beta1-autoscaling">ObjectMetricStatus</a></I></TD><TD>object refers to a metric describing a single kubernetes object (for example, hits-per-second on an Ingress object).</TD></TR>
-<TR><TD><CODE>pods</CODE><BR /><I><a href="#podsmetricstatus-v2beta1-autoscaling">PodsMetricStatus</a></I></TD><TD>pods refers to a metric describing each pod in the current scale target (for example, transactions-processed-per-second).  The values will be averaged together before being compared to the target value.</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I><a href="#resourcemetricstatus-v2beta1-autoscaling">ResourceMetricStatus</a></I></TD><TD>resource refers to a resource metric (such as those specified in requests and limits) known to Kubernetes describing each pod in the current scale target (e.g. CPU or memory). Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the &#34;pods&#34; source.</TD></TR>
-<TR><TD><CODE>type</CODE><BR /><I>string</I></TD><TD>type is the type of metric source.  It will be one of &#34;Object&#34;, &#34;Pods&#34; or &#34;Resource&#34;, each corresponds to a matching field in the object.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="mutatingwebhook-v1beta1-admissionregistration-k8s-io">MutatingWebhook v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>MutatingWebhook</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#mutatingwebhook-v1-admissionregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionReviewVersions</CODE><BR /><I>string array</I></TD><TD>AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy. Default to `[&#39;v1beta1&#39;]`.</TD></TR>
-<TR><TD><CODE>clientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io">WebhookClientConfig</a></I></TD><TD>ClientConfig defines how to communicate with the hook. Required</TD></TR>
-<TR><TD><CODE>failurePolicy</CODE><BR /><I>string</I></TD><TD>FailurePolicy defines how unrecognized errors from the admission endpoint are handled - allowed values are Ignore or Fail. Defaults to Ignore.</TD></TR>
-<TR><TD><CODE>matchPolicy</CODE><BR /><I>string</I></TD><TD>matchPolicy defines how the &#34;rules&#34; list is used to match incoming requests. Allowed values are &#34;Exact&#34; or &#34;Equivalent&#34;.  - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook.  - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook.  Defaults to &#34;Exact&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where &#34;imagepolicy&#34; is the name of the webhook, and kubernetes.io is the name of the organization. Required.</TD></TR>
-<TR><TD><CODE>namespaceSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook.  For example, to run the webhook on any objects whose namespace is not associated with &#34;runlevel&#34; of &#34;0&#34; or &#34;1&#34;;  you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;runlevel&#34;,       &#34;operator&#34;: &#34;NotIn&#34;,       &#34;values&#34;: [         &#34;0&#34;,         &#34;1&#34;       ]     }   ] }  If instead you want to only run the webhook on any objects whose namespace is associated with the &#34;environment&#34; of &#34;prod&#34; or &#34;staging&#34;; you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;environment&#34;,       &#34;operator&#34;: &#34;In&#34;,       &#34;values&#34;: [         &#34;prod&#34;,         &#34;staging&#34;       ]     }   ] }  See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ for more examples of label selectors.  Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>objectSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>reinvocationPolicy</CODE><BR /><I>string</I></TD><TD>reinvocationPolicy indicates whether this webhook should be called multiple times as part of a single admission evaluation. Allowed values are &#34;Never&#34; and &#34;IfNeeded&#34;.  Never: the webhook will not be called more than once in a single admission evaluation.  IfNeeded: the webhook will be called at least one additional time as part of the admission evaluation if the object being admitted is modified by other admission plugins after the initial webhook call. Webhooks that specify this option *must* be idempotent, able to process objects they previously admitted. Note: * the number of additional invocations is not guaranteed to be exactly one. * if additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again. * webhooks that use this option may be reordered to minimize the number of additional invocations. * to validate an object after all mutations are guaranteed complete, use a validating admission webhook instead.  Defaults to &#34;Never&#34;.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#rulewithoperations-v1beta1-admissionregistration-k8s-io">RuleWithOperations</a> array</I></TD><TD>Rules describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.</TD></TR>
-<TR><TD><CODE>sideEffects</CODE><BR /><I>string</I></TD><TD>SideEffects states whether this webhook has side effects. Acceptable values are: Unknown, None, Some, NoneOnDryRun Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some. Defaults to Unknown.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE><BR /><I>integer</I></TD><TD>TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 30 seconds.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>MutatingWebhookConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfigurationList [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.</TD></TR>
-<TR><TD><CODE>webhooks</CODE><BR /><I><a href="#mutatingwebhook-v1beta1-admissionregistration-k8s-io">MutatingWebhook</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>Webhooks is a list of webhooks and the affected resources and operations.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="mutatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfigurationList v1beta1 admissionregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a> array</I></TD><TD>List of MutatingWebhookConfiguration.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Create</H2>
-<P>create a MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Patch</H2>
-<P>partially update the specified MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Replace</H2>
-<P>replace the specified MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Delete</H2>
-<P>delete a MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Read</H2>
-<P>read the specified MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">List</H2>
-<P>list or watch objects of kind MutatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#mutatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">MutatingWebhookConfigurationList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind MutatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/watch/mutatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the MutatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of MutatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/watch/mutatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="nonresourceattributes-v1beta1-authorization-k8s-io">NonResourceAttributes v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>NonResourceAttributes</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#nonresourceattributes-v1-authorization-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectaccessreviewspec-v1beta1-authorization-k8s-io">SelfSubjectAccessReviewSpec [authorization/v1beta1]</a></LI>
-  <LI><a href="#subjectaccessreviewspec-v1beta1-authorization-k8s-io">SubjectAccessReviewSpec [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>Path is the URL path of the request</TD></TR>
-<TR><TD><CODE>verb</CODE><BR /><I>string</I></TD><TD>Verb is the standard HTTP verb</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="nonresourcerule-v1beta1-authorization-k8s-io">NonResourceRule v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>NonResourceRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#nonresourcerule-v1-authorization-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subjectrulesreviewstatus-v1beta1-authorization-k8s-io">SubjectRulesReviewStatus [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nonResourceURLs</CODE><BR /><I>string array</I></TD><TD>NonResourceURLs is a set of partial urls that a user should have access to.  *s are allowed, but only as the full, final step in the path.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verb is a list of kubernetes non-resource API verbs, like: get, post, put, delete, patch, head, options.  &#34;*&#34; means all.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="objectmetricsource-v2beta1-autoscaling">ObjectMetricSource v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>ObjectMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#objectmetricsource-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta1-autoscaling">MetricSpec [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>averageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>averageValue is the target value of the average of the metric across all relevant pods (as a quantity)</TD></TR>
-<TR><TD><CODE>metricName</CODE><BR /><I>string</I></TD><TD>metricName is the name of the metric in question.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping When unset, just the metricName will be used to gather metrics.</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#crossversionobjectreference-v2beta1-autoscaling">CrossVersionObjectReference</a></I></TD><TD>target is the described Kubernetes object.</TD></TR>
-<TR><TD><CODE>targetValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>targetValue is the target value of the metric (as a quantity).</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="objectmetricstatus-v2beta1-autoscaling">ObjectMetricStatus v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>ObjectMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#objectmetricstatus-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta1-autoscaling">MetricStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>averageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>averageValue is the current value of the average of the metric across all relevant pods (as a quantity)</TD></TR>
-<TR><TD><CODE>currentValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>currentValue is the current value of the metric (as a quantity).</TD></TR>
-<TR><TD><CODE>metricName</CODE><BR /><I>string</I></TD><TD>metricName is the name of the metric in question.</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>selector is the string-encoded form of a standard kubernetes label selector for the given metric When set in the ObjectMetricSource, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics.</TD></TR>
-<TR><TD><CODE>target</CODE><BR /><I><a href="#crossversionobjectreference-v2beta1-autoscaling">CrossVersionObjectReference</a></I></TD><TD>target is the described Kubernetes object.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="overhead-v1alpha1-node-k8s-io">Overhead v1alpha1 node.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Overhead</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#overhead-v1beta1-node-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclassspec-v1alpha1-node-k8s-io">RuntimeClassSpec [node/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>podFixed</CODE><BR /><I>object</I></TD><TD>PodFixed represents the fixed resource overhead associated with running a pod.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="podsmetricsource-v2beta1-autoscaling">PodsMetricSource v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>PodsMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#podsmetricsource-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta1-autoscaling">MetricSpec [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>metricName</CODE><BR /><I>string</I></TD><TD>metricName is the name of the metric in question</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping When unset, just the metricName will be used to gather metrics.</TD></TR>
-<TR><TD><CODE>targetAverageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>targetAverageValue is the target value of the average of the metric across all relevant pods (as a quantity)</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="podsmetricstatus-v2beta1-autoscaling">PodsMetricStatus v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>PodsMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#podsmetricstatus-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta1-autoscaling">MetricStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>currentAverageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>currentAverageValue is the current value of the average of the metric across all relevant pods (as a quantity)</TD></TR>
-<TR><TD><CODE>metricName</CODE><BR /><I>string</I></TD><TD>metricName is the name of the metric in question</TD></TR>
-<TR><TD><CODE>selector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>selector is the string-encoded form of a standard kubernetes label selector for the given metric When set in the PodsMetricSource, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="policyrule-v1beta1-rbac-authorization-k8s-io">PolicyRule v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>PolicyRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#policyrule-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#policyrule-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrole-v1beta1-rbac-authorization-k8s-io">ClusterRole [rbac/v1beta1]</a></LI>
-  <LI><a href="#role-v1beta1-rbac-authorization-k8s-io">Role [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the name of the APIGroup that contains the resources.  If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed.</TD></TR>
-<TR><TD><CODE>nonResourceURLs</CODE><BR /><I>string array</I></TD><TD>NonResourceURLs is a set of partial urls that a user should have access to.  *s are allowed, but only as the full, final step in the path Since non-resource URLs are not namespaced, this field is only applicable for ClusterRoles referenced from a ClusterRoleBinding. Rules can either apply to API resources (such as &#34;pods&#34; or &#34;secrets&#34;) or non-resource URL paths (such as &#34;/api&#34;),  but not both.</TD></TR>
-<TR><TD><CODE>resourceNames</CODE><BR /><I>string array</I></TD><TD>ResourceNames is an optional white list of names that the rule applies to.  An empty set means that everything is allowed.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  &#39;\*&#39; represents all resources in the specified apiGroups. &#39;\*/foo&#39; represents the subresource &#39;foo&#39; for all resources in the specified apiGroups.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule.  VerbAll represents all kinds.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="policyrule-v1alpha1-rbac-authorization-k8s-io">PolicyRule v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PolicyRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#policyrule-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#policyrule-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrole-v1alpha1-rbac-authorization-k8s-io">ClusterRole [rbac/v1alpha1]</a></LI>
-  <LI><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the name of the APIGroup that contains the resources.  If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed.</TD></TR>
-<TR><TD><CODE>nonResourceURLs</CODE><BR /><I>string array</I></TD><TD>NonResourceURLs is a set of partial urls that a user should have access to.  *s are allowed, but only as the full, final step in the path Since non-resource URLs are not namespaced, this field is only applicable for ClusterRoles referenced from a ClusterRoleBinding. Rules can either apply to API resources (such as &#34;pods&#34; or &#34;secrets&#34;) or non-resource URL paths (such as &#34;/api&#34;),  but not both.</TD></TR>
-<TR><TD><CODE>resourceNames</CODE><BR /><I>string array</I></TD><TD>ResourceNames is an optional white list of names that the rule applies to.  An empty set means that everything is allowed.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  ResourceAll represents all resources.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule.  VerbAll represents all kinds.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="priorityclass-v1beta1-scheduling-k8s-io">PriorityClass v1beta1 scheduling.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>scheduling.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>PriorityClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#priorityclass-v1-scheduling-k8s-io">v1</a>
-<a href="#priorityclass-v1alpha1-scheduling-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#priorityclasslist-v1beta1-scheduling-k8s-io">PriorityClassList [scheduling/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD>description is an arbitrary string that usually provides guidelines on when this priority class should be used.</TD></TR>
-<TR><TD><CODE>globalDefault</CODE><BR /><I>boolean</I></TD><TD>globalDefault specifies whether this PriorityClass should be considered as the default priority for pods that do not have any priority class. Only one PriorityClass can be marked as `globalDefault`. However, if more than one PriorityClasses exists with their `globalDefault` field set to true, the smallest value of such global default PriorityClasses will be used as the default priority.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>preemptionPolicy</CODE><BR /><I>string</I></TD><TD>PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is alpha-level and is only honored by servers that enable the NonPreemptingPriority feature.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>integer</I></TD><TD>The value of this priority class. This is the actual priority that pods receive when they have the name of this class in their pod spec.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="priorityclasslist-v1beta1-scheduling-k8s-io">PriorityClassList v1beta1 scheduling</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a> array</I></TD><TD>items is the list of PriorityClasses</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-priorityclass-v1beta1-scheduling-k8s-io">Create</H2>
-<P>create a PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/scheduling.k8s.io/v1beta1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-priorityclass-v1beta1-scheduling-k8s-io">Patch</H2>
-<P>partially update the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/scheduling.k8s.io/v1beta1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-priorityclass-v1beta1-scheduling-k8s-io">Replace</H2>
-<P>replace the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/scheduling.k8s.io/v1beta1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-priorityclass-v1beta1-scheduling-k8s-io">Delete</H2>
-<P>delete a PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/scheduling.k8s.io/v1beta1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-priorityclass-v1beta1-scheduling-k8s-io">Delete Collection</H2>
-<P>delete collection of PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/scheduling.k8s.io/v1beta1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-priorityclass-v1beta1-scheduling-k8s-io">Read</H2>
-<P>read the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1beta1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1beta1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-priorityclass-v1beta1-scheduling-k8s-io">List</H2>
-<P>list or watch objects of kind PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1beta1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclasslist-v1beta1-scheduling-k8s-io">PriorityClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-priorityclass-v1beta1-scheduling-k8s-io">Watch</H2>
-<P>watch changes to an object of kind PriorityClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1beta1/watch/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-priorityclass-v1beta1-scheduling-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of PriorityClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1beta1/watch/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass v1alpha1 scheduling.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>scheduling.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>PriorityClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#priorityclass-v1-scheduling-k8s-io">v1</a>
-<a href="#priorityclass-v1beta1-scheduling-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#priorityclasslist-v1alpha1-scheduling-k8s-io">PriorityClassList [scheduling/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>description</CODE><BR /><I>string</I></TD><TD>description is an arbitrary string that usually provides guidelines on when this priority class should be used.</TD></TR>
-<TR><TD><CODE>globalDefault</CODE><BR /><I>boolean</I></TD><TD>globalDefault specifies whether this PriorityClass should be considered as the default priority for pods that do not have any priority class. Only one PriorityClass can be marked as `globalDefault`. However, if more than one PriorityClasses exists with their `globalDefault` field set to true, the smallest value of such global default PriorityClasses will be used as the default priority.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>preemptionPolicy</CODE><BR /><I>string</I></TD><TD>PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is alpha-level and is only honored by servers that enable the NonPreemptingPriority feature.</TD></TR>
-<TR><TD><CODE>value</CODE><BR /><I>integer</I></TD><TD>The value of this priority class. This is the actual priority that pods receive when they have the name of this class in their pod spec.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="priorityclasslist-v1alpha1-scheduling-k8s-io">PriorityClassList v1alpha1 scheduling</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a> array</I></TD><TD>items is the list of PriorityClasses</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-priorityclass-v1alpha1-scheduling-k8s-io">Create</H2>
-<P>create a PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/scheduling.k8s.io/v1alpha1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-priorityclass-v1alpha1-scheduling-k8s-io">Patch</H2>
-<P>partially update the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/scheduling.k8s.io/v1alpha1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-priorityclass-v1alpha1-scheduling-k8s-io">Replace</H2>
-<P>replace the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/scheduling.k8s.io/v1alpha1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-priorityclass-v1alpha1-scheduling-k8s-io">Delete</H2>
-<P>delete a PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/scheduling.k8s.io/v1alpha1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-priorityclass-v1alpha1-scheduling-k8s-io">Delete Collection</H2>
-<P>delete collection of PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/scheduling.k8s.io/v1alpha1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-priorityclass-v1alpha1-scheduling-k8s-io">Read</H2>
-<P>read the specified PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1alpha1/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclass-v1alpha1-scheduling-k8s-io">PriorityClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-priorityclass-v1alpha1-scheduling-k8s-io">List</H2>
-<P>list or watch objects of kind PriorityClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1alpha1/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#priorityclasslist-v1alpha1-scheduling-k8s-io">PriorityClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-priorityclass-v1alpha1-scheduling-k8s-io">Watch</H2>
-<P>watch changes to an object of kind PriorityClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1alpha1/watch/priorityclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the PriorityClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-priorityclass-v1alpha1-scheduling-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of PriorityClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/scheduling.k8s.io/v1alpha1/watch/priorityclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="resourceattributes-v1beta1-authorization-k8s-io">ResourceAttributes v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ResourceAttributes</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourceattributes-v1-authorization-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectaccessreviewspec-v1beta1-authorization-k8s-io">SelfSubjectAccessReviewSpec [authorization/v1beta1]</a></LI>
-  <LI><a href="#subjectaccessreviewspec-v1beta1-authorization-k8s-io">SubjectAccessReviewSpec [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>group</CODE><BR /><I>string</I></TD><TD>Group is the API Group of the Resource.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of the resource being requested for a &#34;get&#34; or deleted for a &#34;delete&#34;. &#34;&#34; (empty) means all.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace is the namespace of the action being requested.  Currently, there is no distinction between no namespace and all namespaces &#34;&#34; (empty) is defaulted for LocalSubjectAccessReviews &#34;&#34; (empty) is empty for cluster-scoped resources &#34;&#34; (empty) means &#34;all&#34; for namespace scoped resources from a SubjectAccessReview or SelfSubjectAccessReview</TD></TR>
-<TR><TD><CODE>resource</CODE><BR /><I>string</I></TD><TD>Resource is one of the existing resource types.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>subresource</CODE><BR /><I>string</I></TD><TD>Subresource is one of the existing resource types.  &#34;&#34; means none.</TD></TR>
-<TR><TD><CODE>verb</CODE><BR /><I>string</I></TD><TD>Verb is a kubernetes resource API verb, like: get, list, watch, create, update, delete, proxy.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>version</CODE><BR /><I>string</I></TD><TD>Version is the API Version of the Resource.  &#34;*&#34; means all.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="resourcemetricsource-v2beta1-autoscaling">ResourceMetricSource v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>ResourceMetricSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourcemetricsource-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricspec-v2beta1-autoscaling">MetricSpec [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the resource in question.</TD></TR>
-<TR><TD><CODE>targetAverageUtilization</CODE><BR /><I>integer</I></TD><TD>targetAverageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.</TD></TR>
-<TR><TD><CODE>targetAverageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>targetAverageValue is the target value of the average of the resource metric across all relevant pods, as a raw value (instead of as a percentage of the request), similar to the &#34;pods&#34; metric source type.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="resourcemetricstatus-v2beta1-autoscaling">ResourceMetricStatus v2beta1 autoscaling</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v2beta1</CODE></TD><TD><CODE>ResourceMetricStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourcemetricstatus-v2beta2-autoscaling">v2beta2</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#metricstatus-v2beta1-autoscaling">MetricStatus [autoscaling/v2beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>currentAverageUtilization</CODE><BR /><I>integer</I></TD><TD>currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.  It will only be present if `targetAverageValue` was set in the corresponding metric specification.</TD></TR>
-<TR><TD><CODE>currentAverageValue</CODE><BR /><I><a href="#quantity-resource-core">Quantity</a></I></TD><TD>currentAverageValue is the current value of the average of the resource metric across all relevant pods, as a raw value (instead of as a percentage of the request), similar to the &#34;pods&#34; metric source type. It will always be set, regardless of the corresponding metric specification.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the resource in question.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="resourcerule-v1beta1-authorization-k8s-io">ResourceRule v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ResourceRule</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#resourcerule-v1-authorization-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#subjectrulesreviewstatus-v1beta1-authorization-k8s-io">SubjectRulesReviewStatus [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the name of the APIGroup that contains the resources.  If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>resourceNames</CODE><BR /><I>string array</I></TD><TD>ResourceNames is an optional white list of names that the rule applies to.  An empty set means that everything is allowed.  &#34;*&#34; means all.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  &#34;*&#34; means all in the specified apiGroups.  &#34;*/foo&#34; represents the subresource &#39;foo&#39; for all resources in the specified apiGroups.</TD></TR>
-<TR><TD><CODE>verbs</CODE><BR /><I>string array</I></TD><TD>Verb is a list of kubernetes resource API verbs, like: get, list, watch, create, update, delete, proxy.  &#34;*&#34; means all.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="role-v1beta1-rbac-authorization-k8s-io">Role v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Role</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#role-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#role-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#rolelist-v1beta1-rbac-authorization-k8s-io">RoleList [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyrule-v1beta1-rbac-authorization-k8s-io">PolicyRule</a> array</I></TD><TD>Rules holds all the PolicyRules for this Role</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rolelist-v1beta1-rbac-authorization-k8s-io">RoleList v1beta1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a> array</I></TD><TD>Items is a list of Roles</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-role-v1beta1-rbac-authorization-k8s-io">Create</H2>
-<P>create a Role</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-role-v1beta1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-role-v1beta1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-role-v1beta1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a Role</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-role-v1beta1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of Role</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-role-v1beta1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1beta1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-role-v1beta1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolelist-v1beta1-rbac-authorization-k8s-io">RoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/roles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolelist-v1beta1-rbac-authorization-k8s-io">RoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-role-v1beta1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Role. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-role-v1beta1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Role. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Role. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/roles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="role-v1alpha1-rbac-authorization-k8s-io">Role v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Role</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#role-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#role-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#rolelist-v1alpha1-rbac-authorization-k8s-io">RoleList [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#policyrule-v1alpha1-rbac-authorization-k8s-io">PolicyRule</a> array</I></TD><TD>Rules holds all the PolicyRules for this Role</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rolelist-v1alpha1-rbac-authorization-k8s-io">RoleList v1alpha1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a> array</I></TD><TD>Items is a list of Roles</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-role-v1alpha1-rbac-authorization-k8s-io">Create</H2>
-<P>create a Role</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-role-v1alpha1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-role-v1alpha1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-role-v1alpha1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a Role</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-role-v1alpha1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of Role</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-role-v1alpha1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#role-v1alpha1-rbac-authorization-k8s-io">Role</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-role-v1alpha1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolelist-v1alpha1-rbac-authorization-k8s-io">RoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind Role</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/roles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolelist-v1alpha1-rbac-authorization-k8s-io">RoleList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-role-v1alpha1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind Role. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/roles/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the Role</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-role-v1alpha1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of Role. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/roles</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of Role. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/roles</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RoleBinding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#rolebinding-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#rolebindinglist-v1beta1-rbac-authorization-k8s-io">RoleBindingList [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>roleRef</CODE><BR /><I><a href="#roleref-v1beta1-rbac-authorization-k8s-io">RoleRef</a></I></TD><TD>RoleRef can reference a Role in the current namespace or a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1beta1-rbac-authorization-k8s-io">Subject</a> array</I></TD><TD>Subjects holds references to the objects the role applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rolebindinglist-v1beta1-rbac-authorization-k8s-io">RoleBindingList v1beta1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a> array</I></TD><TD>Items is a list of RoleBindings</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-rolebinding-v1beta1-rbac-authorization-k8s-io">Create</H2>
-<P>create a RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-rolebinding-v1beta1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-rolebinding-v1beta1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-rolebinding-v1beta1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-rolebinding-v1beta1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-rolebinding-v1beta1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebindinglist-v1beta1-rbac-authorization-k8s-io">RoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/rolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebindinglist-v1beta1-rbac-authorization-k8s-io">RoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-rolebinding-v1beta1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind RoleBinding. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of RoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of RoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1beta1/watch/rolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>RoleBinding</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#rolebinding-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#rolebindinglist-v1alpha1-rbac-authorization-k8s-io">RoleBindingList [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-<TR><TD><CODE>roleRef</CODE><BR /><I><a href="#roleref-v1alpha1-rbac-authorization-k8s-io">RoleRef</a></I></TD><TD>RoleRef can reference a Role in the current namespace or a ClusterRole in the global namespace. If the RoleRef cannot be resolved, the Authorizer must return an error.</TD></TR>
-<TR><TD><CODE>subjects</CODE><BR /><I><a href="#subject-v1alpha1-rbac-authorization-k8s-io">Subject</a> array</I></TD><TD>Subjects holds references to the objects the role applies to.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="rolebindinglist-v1alpha1-rbac-authorization-k8s-io">RoleBindingList v1alpha1 rbac</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a> array</I></TD><TD>Items is a list of RoleBindings</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard object&#39;s metadata.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-rolebinding-v1alpha1-rbac-authorization-k8s-io">Create</H2>
-<P>create a RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-rolebinding-v1alpha1-rbac-authorization-k8s-io">Patch</H2>
-<P>partially update the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-rolebinding-v1alpha1-rbac-authorization-k8s-io">Replace</H2>
-<P>replace the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-rolebinding-v1alpha1-rbac-authorization-k8s-io">Delete</H2>
-<P>delete a RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io">Delete Collection</H2>
-<P>delete collection of RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-rolebinding-v1alpha1-rbac-authorization-k8s-io">Read</H2>
-<P>read the specified RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-rolebinding-v1alpha1-rbac-authorization-k8s-io">List</H2>
-<P>list or watch objects of kind RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebindinglist-v1alpha1-rbac-authorization-k8s-io">RoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io">List All Namespaces</H2>
-<P>list or watch objects of kind RoleBinding</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/rolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#rolebindinglist-v1alpha1-rbac-authorization-k8s-io">RoleBindingList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-rolebinding-v1alpha1-rbac-authorization-k8s-io">Watch</H2>
-<P>watch changes to an object of kind RoleBinding. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/rolebindings/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RoleBinding</TD></TR>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of RoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/rolebindings</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE></TD><TD>object name and auth scope, such as for teams and projects</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io">Watch List All Namespaces</H2>
-<P>watch individual changes to a list of RoleBinding. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/rolebindings</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="roleref-v1beta1-rbac-authorization-k8s-io">RoleRef v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RoleRef</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#roleref-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#roleref-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1beta1]</a></LI>
-  <LI><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroup</CODE><BR /><I>string</I></TD><TD>APIGroup is the group for the resource being referenced</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is the type of resource being referenced</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of resource being referenced</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="roleref-v1alpha1-rbac-authorization-k8s-io">RoleRef v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>RoleRef</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#roleref-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#roleref-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1alpha1]</a></LI>
-  <LI><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroup</CODE><BR /><I>string</I></TD><TD>APIGroup is the group for the resource being referenced</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is the type of resource being referenced</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of resource being referenced</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="rulewithoperations-v1beta1-admissionregistration-k8s-io">RuleWithOperations v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>RuleWithOperations</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#rulewithoperations-v1-admissionregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhook-v1beta1-admissionregistration-k8s-io">MutatingWebhook [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#validatingwebhook-v1beta1-admissionregistration-k8s-io">ValidatingWebhook [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroups</CODE><BR /><I>string array</I></TD><TD>APIGroups is the API groups the resources belong to. &#39;\*&#39; is all groups. If &#39;\*&#39; is present, the length of the slice must be one. Required.</TD></TR>
-<TR><TD><CODE>apiVersions</CODE><BR /><I>string array</I></TD><TD>APIVersions is the API versions the resources belong to. &#39;\*&#39; is all versions. If &#39;\*&#39; is present, the length of the slice must be one. Required.</TD></TR>
-<TR><TD><CODE>operations</CODE><BR /><I>string array</I></TD><TD>Operations is the operations the admission hook cares about - CREATE, UPDATE, or * for all operations. If &#39;\*&#39; is present, the length of the slice must be one. Required.</TD></TR>
-<TR><TD><CODE>resources</CODE><BR /><I>string array</I></TD><TD>Resources is a list of resources this rule applies to.  For example: &#39;pods&#39; means pods. &#39;pods/log&#39; means the log subresource of pods. &#39;\*&#39; means all resources, but not subresources. &#39;pods/\*&#39; means all subresources of pods. &#39;\*/scale&#39; means all scale subresources. &#39;\*/\*&#39; means all resources and their subresources.  If wildcard is present, the validation rule will ensure resources do not overlap with each other.  Depending on the enclosing object, subresources might not be allowed. Required.</TD></TR>
-<TR><TD><CODE>scope</CODE><BR /><I>string</I></TD><TD>scope specifies the scope of this rule. Valid values are &#34;Cluster&#34;, &#34;Namespaced&#34;, and &#34;*&#34; &#34;Cluster&#34; means that only cluster-scoped resources will match this rule. Namespace API objects are cluster-scoped. &#34;Namespaced&#34; means that only namespaced resources will match this rule. &#34;*&#34; means that there are no scope restrictions. Subresources match the scope of their parent resource. Default is &#34;*&#34;.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="runtimeclass-v1alpha1-node-k8s-io">RuntimeClass v1alpha1 node.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>RuntimeClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#runtimeclass-v1beta1-node-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclasslist-v1alpha1-node-k8s-io">RuntimeClassList [node/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#runtimeclassspec-v1alpha1-node-k8s-io">RuntimeClassSpec</a></I></TD><TD>Specification of the RuntimeClass More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="runtimeclassspec-v1alpha1-node-k8s-io">RuntimeClassSpec v1alpha1 node</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass [node/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>overhead</CODE><BR /><I><a href="#overhead-v1alpha1-node-k8s-io">Overhead</a></I></TD><TD>Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. For more details, see https://git.k8s.io/enhancements/keps/sig-node/20190226-pod-overhead.md This field is alpha-level as of Kubernetes v1.15, and is only honored by servers that enable the PodOverhead feature.</TD></TR>
-<TR><TD><CODE>runtimeHandler</CODE><BR /><I>string</I></TD><TD>RuntimeHandler specifies the underlying runtime and configuration that the CRI implementation will use to handle pods of this class. The possible values are specific to the node &amp; CRI configuration.  It is assumed that all handlers are available on every node, and handlers of the same name are equivalent on every node. For example, a handler called &#34;runc&#34; might specify that the runc OCI runtime (using native Linux containers) will be used to run the containers in a pod. The RuntimeHandler must conform to the DNS Label (RFC 1123) requirements and is immutable.</TD></TR>
-<TR><TD><CODE>scheduling</CODE><BR /><I><a href="#scheduling-v1alpha1-node-k8s-io">Scheduling</a></I></TD><TD>Scheduling holds the scheduling constraints to ensure that pods running with this RuntimeClass are scheduled to nodes that support it. If scheduling is nil, this RuntimeClass is assumed to be supported by all nodes.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="runtimeclasslist-v1alpha1-node-k8s-io">RuntimeClassList v1alpha1 node</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a> array</I></TD><TD>Items is a list of schema objects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-runtimeclass-v1alpha1-node-k8s-io">Create</H2>
-<P>create a RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/node.k8s.io/v1alpha1/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-runtimeclass-v1alpha1-node-k8s-io">Patch</H2>
-<P>partially update the specified RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/node.k8s.io/v1alpha1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-runtimeclass-v1alpha1-node-k8s-io">Replace</H2>
-<P>replace the specified RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/node.k8s.io/v1alpha1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-runtimeclass-v1alpha1-node-k8s-io">Delete</H2>
-<P>delete a RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/node.k8s.io/v1alpha1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-runtimeclass-v1alpha1-node-k8s-io">Delete Collection</H2>
-<P>delete collection of RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/node.k8s.io/v1alpha1/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-runtimeclass-v1alpha1-node-k8s-io">Read</H2>
-<P>read the specified RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1alpha1/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclass-v1alpha1-node-k8s-io">RuntimeClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-runtimeclass-v1alpha1-node-k8s-io">List</H2>
-<P>list or watch objects of kind RuntimeClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1alpha1/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#runtimeclasslist-v1alpha1-node-k8s-io">RuntimeClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-runtimeclass-v1alpha1-node-k8s-io">Watch</H2>
-<P>watch changes to an object of kind RuntimeClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1alpha1/watch/runtimeclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the RuntimeClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-runtimeclass-v1alpha1-node-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of RuntimeClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/node.k8s.io/v1alpha1/watch/runtimeclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="scheduling-v1alpha1-node-k8s-io">Scheduling v1alpha1 node.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Scheduling</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#scheduling-v1beta1-node-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#runtimeclassspec-v1alpha1-node-k8s-io">RuntimeClassSpec [node/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nodeSelector</CODE><BR /><I>object</I></TD><TD>nodeSelector lists labels that must be present on nodes that support this RuntimeClass. Pods using this RuntimeClass can only be scheduled to a node matched by this selector. The RuntimeClass nodeSelector is merged with a pod&#39;s existing nodeSelector. Any conflicts will cause the pod to be rejected in admission.</TD></TR>
-<TR><TD><CODE>tolerations</CODE><BR /><I><a href="#toleration-v1-core">Toleration</a> array</I></TD><TD>tolerations are appended (excluding duplicates) to pods running with this RuntimeClass during admission, effectively unioning the set of nodes tolerated by the pod and the RuntimeClass.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>SelfSubjectAccessReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#selfsubjectaccessreview-v1-authorization-k8s-io">v1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#selfsubjectaccessreviewspec-v1beta1-authorization-k8s-io">SelfSubjectAccessReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated.  user and groups must be empty</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectaccessreviewstatus-v1beta1-authorization-k8s-io">SubjectAccessReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request is allowed or not</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="selfsubjectaccessreviewspec-v1beta1-authorization-k8s-io">SelfSubjectAccessReviewSpec v1beta1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>nonResourceAttributes</CODE><BR /><I><a href="#nonresourceattributes-v1beta1-authorization-k8s-io">NonResourceAttributes</a></I></TD><TD>NonResourceAttributes describes information for a non-resource access request</TD></TR>
-<TR><TD><CODE>resourceAttributes</CODE><BR /><I><a href="#resourceattributes-v1beta1-authorization-k8s-io">ResourceAttributes</a></I></TD><TD>ResourceAuthorizationAttributes describes information for a resource access request</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-selfsubjectaccessreview-v1beta1-authorization-k8s-io">Create</H2>
-<P>create a SelfSubjectAccessReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1beta1/selfsubjectaccessreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>SelfSubjectRulesReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#selfsubjectrulesreview-v1-authorization-k8s-io">v1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#selfsubjectrulesreviewspec-v1beta1-authorization-k8s-io">SelfSubjectRulesReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectrulesreviewstatus-v1beta1-authorization-k8s-io">SubjectRulesReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates the set of actions a user can perform.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="selfsubjectrulesreviewspec-v1beta1-authorization-k8s-io">SelfSubjectRulesReviewSpec v1beta1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace to evaluate rules for. Required.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-selfsubjectrulesreview-v1beta1-authorization-k8s-io">Create</H2>
-<P>create a SelfSubjectRulesReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1beta1/selfsubjectrulesreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="servicereference-v1-apiextensions-k8s-io">ServiceReference v1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1beta1-apiextensions-k8s-io">v1beta1</a>
-<a href="#servicereference-v1beta1-apiregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhookclientconfig-v1-apiextensions-k8s-io">WebhookClientConfig [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the service. Required</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>namespace is the namespace of the service. Required</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>path is an optional URL path at which the webhook will be contacted.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>port is an optional service port at which the webhook will be contacted. `port` should be a valid port number (1-65535, inclusive). Defaults to 443 for backward compatibility.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="servicereference-v1-apiregistration-k8s-io">ServiceReference v1 apiregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1beta1-apiextensions-k8s-io">v1beta1</a>
-<a href="#servicereference-v1beta1-apiregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicespec-v1-apiregistration-k8s-io">APIServiceSpec [apiregistration/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of the service</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace is the namespace of the service</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="servicereference-v1beta1-admissionregistration-k8s-io">ServiceReference v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1-admissionregistration-k8s-io">v1</a>
-<a href="#servicereference-v1-apiextensions-k8s-io">v1</a>
-<a href="#servicereference-v1-apiregistration-k8s-io">v1</a>
-<a href="#servicereference-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io">WebhookClientConfig [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>`name` is the name of the service. Required</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>`namespace` is the namespace of the service. Required</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>`path` is an optional URL path which will be sent in any request to this service.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="servicereference-v1beta1-apiextensions-k8s-io">ServiceReference v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1-admissionregistration-k8s-io">v1</a>
-<a href="#servicereference-v1-apiextensions-k8s-io">v1</a>
-<a href="#servicereference-v1-apiregistration-k8s-io">v1</a>
-<a href="#servicereference-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhookclientconfig-v1beta1-apiextensions-k8s-io">WebhookClientConfig [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>name is the name of the service. Required</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>namespace is the namespace of the service. Required</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>path is an optional URL path at which the webhook will be contacted.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>port is an optional service port at which the webhook will be contacted. `port` should be a valid port number (1-65535, inclusive). Defaults to 443 for backward compatibility.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="servicereference-v1beta1-apiregistration-k8s-io">ServiceReference v1beta1 apiregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1-admissionregistration-k8s-io">v1</a>
-<a href="#servicereference-v1-apiextensions-k8s-io">v1</a>
-<a href="#servicereference-v1-apiregistration-k8s-io">v1</a>
-<a href="#servicereference-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#apiservicespec-v1beta1-apiregistration-k8s-io">APIServiceSpec [apiregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name is the name of the service</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace is the namespace of the service</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="servicereference-v1alpha1-auditregistration-k8s-io">ServiceReference v1alpha1 auditregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>auditregistration.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>ServiceReference</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#servicereference-v1-admissionregistration-k8s-io">v1</a>
-<a href="#servicereference-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#servicereference-v1-apiextensions-k8s-io">v1</a>
-<a href="#servicereference-v1beta1-apiextensions-k8s-io">v1beta1</a>
-<a href="#servicereference-v1-apiregistration-k8s-io">v1</a>
-<a href="#servicereference-v1beta1-apiregistration-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io">WebhookClientConfig [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>`name` is the name of the service. Required</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>`namespace` is the namespace of the service. Required</TD></TR>
-<TR><TD><CODE>path</CODE><BR /><I>string</I></TD><TD>`path` is an optional URL path which will be sent in any request to this service.</TD></TR>
-<TR><TD><CODE>port</CODE><BR /><I>integer</I></TD><TD>If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive).</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="storageclass-v1beta1-storage-k8s-io">StorageClass v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>StorageClass</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#storageclass-v1-storage-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#storageclasslist-v1beta1-storage-k8s-io">StorageClassList [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowVolumeExpansion</CODE><BR /><I>boolean</I></TD><TD>AllowVolumeExpansion shows whether the storage class allow volume expand</TD></TR>
-<TR><TD><CODE>allowedTopologies</CODE><BR /><I><a href="#topologyselectorterm-v1-core">TopologySelectorTerm</a> array</I></TD><TD>Restrict the node topologies where volumes can be dynamically provisioned. Each volume plugin defines its own supported topology specifications. An empty TopologySelectorTerm list means there is no topology restriction. This field is only honored by servers that enable the VolumeScheduling feature.</TD></TR>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object&#39;s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>mountOptions</CODE><BR /><I>string array</I></TD><TD>Dynamically provisioned PersistentVolumes of this storage class are created with these mountOptions, e.g. [&#34;ro&#34;, &#34;soft&#34;]. Not validated - mount of the PVs will simply fail if one is invalid.</TD></TR>
-<TR><TD><CODE>parameters</CODE><BR /><I>object</I></TD><TD>Parameters holds the parameters for the provisioner that should create volumes of this storage class.</TD></TR>
-<TR><TD><CODE>provisioner</CODE><BR /><I>string</I></TD><TD>Provisioner indicates the type of the provisioner.</TD></TR>
-<TR><TD><CODE>reclaimPolicy</CODE><BR /><I>string</I></TD><TD>Dynamically provisioned PersistentVolumes of this storage class are created with this reclaimPolicy. Defaults to Delete.</TD></TR>
-<TR><TD><CODE>volumeBindingMode</CODE><BR /><I>string</I></TD><TD>VolumeBindingMode indicates how PersistentVolumeClaims should be provisioned and bound.  When unset, VolumeBindingImmediate is used. This field is only honored by servers that enable the VolumeScheduling feature.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="storageclasslist-v1beta1-storage-k8s-io">StorageClassList v1beta1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a> array</I></TD><TD>Items is the list of StorageClasses</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-storageclass-v1beta1-storage-k8s-io">Create</H2>
-<P>create a StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1beta1/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-storageclass-v1beta1-storage-k8s-io">Patch</H2>
-<P>partially update the specified StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1beta1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-storageclass-v1beta1-storage-k8s-io">Replace</H2>
-<P>replace the specified StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1beta1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-storageclass-v1beta1-storage-k8s-io">Delete</H2>
-<P>delete a StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-storageclass-v1beta1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-storageclass-v1beta1-storage-k8s-io">Read</H2>
-<P>read the specified StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclass-v1beta1-storage-k8s-io">StorageClass</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-storageclass-v1beta1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind StorageClass</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#storageclasslist-v1beta1-storage-k8s-io">StorageClassList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-storageclass-v1beta1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind StorageClass. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/storageclasses/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the StorageClass</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-storageclass-v1beta1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of StorageClass. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/storageclasses</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="subject-v1-rbac-authorization-k8s-io">Subject v1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>Subject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io">v1alpha1</a>
-<a href="#subject-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-<a href="#subject-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebinding-v1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1]</a></LI>
-  <LI><a href="#rolebinding-v1-rbac-authorization-k8s-io">RoleBinding [rbac/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroup</CODE><BR /><I>string</I></TD><TD>APIGroup holds the API group of the referenced subject. Defaults to &#34;&#34; for ServiceAccount subjects. Defaults to &#34;rbac.authorization.k8s.io&#34; for User and Group subjects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of object being referenced. Values defined by this API group are &#34;User&#34;, &#34;Group&#34;, and &#34;ServiceAccount&#34;. If the Authorizer does not recognized the kind value, the Authorizer should report an error.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the object being referenced.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace of the referenced object.  If the object kind is non-namespace, such as &#34;User&#34; or &#34;Group&#34;, and this value is not empty the Authorizer should report an error.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="subject-v1beta1-rbac-authorization-k8s-io">Subject v1beta1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>Subject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subject-v1alpha1-flowcontrol-apiserver-k8s-io">v1alpha1</a>
-<a href="#subject-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#subject-v1alpha1-rbac-authorization-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebinding-v1beta1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1beta1]</a></LI>
-  <LI><a href="#rolebinding-v1beta1-rbac-authorization-k8s-io">RoleBinding [rbac/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiGroup</CODE><BR /><I>string</I></TD><TD>APIGroup holds the API group of the referenced subject. Defaults to &#34;&#34; for ServiceAccount subjects. Defaults to &#34;rbac.authorization.k8s.io&#34; for User and Group subjects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of object being referenced. Values defined by this API group are &#34;User&#34;, &#34;Group&#34;, and &#34;ServiceAccount&#34;. If the Authorizer does not recognized the kind value, the Authorizer should report an error.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the object being referenced.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace of the referenced object.  If the object kind is non-namespace, such as &#34;User&#34; or &#34;Group&#34;, and this value is not empty the Authorizer should report an error.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="subject-v1alpha1-rbac-authorization-k8s-io">Subject v1alpha1 rbac.authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>Subject</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subject-v1-rbac-authorization-k8s-io">v1</a>
-<a href="#subject-v1beta1-rbac-authorization-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#clusterrolebinding-v1alpha1-rbac-authorization-k8s-io">ClusterRoleBinding [rbac/v1alpha1]</a></LI>
-  <LI><a href="#rolebinding-v1alpha1-rbac-authorization-k8s-io">RoleBinding [rbac/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion holds the API group and version of the referenced subject. Defaults to &#34;v1&#34; for ServiceAccount subjects. Defaults to &#34;rbac.authorization.k8s.io/v1alpha1&#34; for User and Group subjects.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind of object being referenced. Values defined by this API group are &#34;User&#34;, &#34;Group&#34;, and &#34;ServiceAccount&#34;. If the Authorizer does not recognized the kind value, the Authorizer should report an error.</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>Name of the object being referenced.</TD></TR>
-<TR><TD><CODE>namespace</CODE><BR /><I>string</I></TD><TD>Namespace of the referenced object.  If the object kind is non-namespace, such as &#34;User&#34; or &#34;Group&#34;, and this value is not empty the Authorizer should report an error.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>SubjectAccessReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subjectaccessreview-v1-authorization-k8s-io">v1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#subjectaccessreviewspec-v1beta1-authorization-k8s-io">SubjectAccessReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#subjectaccessreviewstatus-v1beta1-authorization-k8s-io">SubjectAccessReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request is allowed or not</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="subjectaccessreviewspec-v1beta1-authorization-k8s-io">SubjectAccessReviewSpec v1beta1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extra</CODE><BR /><I>object</I></TD><TD>Extra corresponds to the user.Info.GetExtra() method from the authenticator.  Since that is input to the authorizer it needs a reflection here.</TD></TR>
-<TR><TD><CODE>group</CODE><BR /><I>string array</I></TD><TD>Groups is the groups you&#39;re testing for.</TD></TR>
-<TR><TD><CODE>nonResourceAttributes</CODE><BR /><I><a href="#nonresourceattributes-v1beta1-authorization-k8s-io">NonResourceAttributes</a></I></TD><TD>NonResourceAttributes describes information for a non-resource access request</TD></TR>
-<TR><TD><CODE>resourceAttributes</CODE><BR /><I><a href="#resourceattributes-v1beta1-authorization-k8s-io">ResourceAttributes</a></I></TD><TD>ResourceAuthorizationAttributes describes information for a resource access request</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>UID information about the requesting user.</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I>string</I></TD><TD>User is the user you&#39;re testing for. If you specify &#34;User&#34; but not &#34;Group&#34;, then is it interpreted as &#34;What if User were not a member of any groups</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="subjectaccessreviewstatus-v1beta1-authorization-k8s-io">SubjectAccessReviewStatus v1beta1 authorization</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#localsubjectaccessreview-v1beta1-authorization-k8s-io">LocalSubjectAccessReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#selfsubjectaccessreview-v1beta1-authorization-k8s-io">SelfSubjectAccessReview [authorization/v1beta1]</a></LI>
-  <LI><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowed</CODE><BR /><I>boolean</I></TD><TD>Allowed is required. True if the action would be allowed, false otherwise.</TD></TR>
-<TR><TD><CODE>denied</CODE><BR /><I>boolean</I></TD><TD>Denied is optional. True if the action would be denied, otherwise false. If both allowed is false and denied is false, then the authorizer has no opinion on whether to authorize the action. Denied may not be true if Allowed is true.</TD></TR>
-<TR><TD><CODE>evaluationError</CODE><BR /><I>string</I></TD><TD>EvaluationError is an indication that some error occurred during the authorization check. It is entirely possible to get an error and be able to continue determine authorization status in spite of it. For instance, RBAC can be missing a role, but enough roles are still present and bound to reason about the request.</TD></TR>
-<TR><TD><CODE>reason</CODE><BR /><I>string</I></TD><TD>Reason is optional.  It indicates why a request was allowed or denied.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-subjectaccessreview-v1beta1-authorization-k8s-io">Create</H2>
-<P>create a SubjectAccessReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authorization.k8s.io/v1beta1/subjectaccessreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#subjectaccessreview-v1beta1-authorization-k8s-io">SubjectAccessReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="subjectrulesreviewstatus-v1beta1-authorization-k8s-io">SubjectRulesReviewStatus v1beta1 authorization.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>SubjectRulesReviewStatus</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#subjectrulesreviewstatus-v1-authorization-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#selfsubjectrulesreview-v1beta1-authorization-k8s-io">SelfSubjectRulesReview [authorization/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>evaluationError</CODE><BR /><I>string</I></TD><TD>EvaluationError can appear in combination with Rules. It indicates an error occurred during rule evaluation, such as an authorizer that doesn&#39;t support rule evaluation, and that ResourceRules and/or NonResourceRules may be incomplete.</TD></TR>
-<TR><TD><CODE>incomplete</CODE><BR /><I>boolean</I></TD><TD>Incomplete is true when the rules returned by this call are incomplete. This is most commonly encountered when an authorizer, such as an external authorizer, doesn&#39;t support rules evaluation.</TD></TR>
-<TR><TD><CODE>nonResourceRules</CODE><BR /><I><a href="#nonresourcerule-v1beta1-authorization-k8s-io">NonResourceRule</a> array</I></TD><TD>NonResourceRules is the list of actions the subject is allowed to perform on non-resources. The list ordering isn&#39;t significant, may contain duplicates, and possibly be incomplete.</TD></TR>
-<TR><TD><CODE>resourceRules</CODE><BR /><I><a href="#resourcerule-v1beta1-authorization-k8s-io">ResourceRule</a> array</I></TD><TD>ResourceRules is the list of actions the subject is allowed to perform on resources. The list ordering isn&#39;t significant, may contain duplicates, and possibly be incomplete.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="tokenreview-v1beta1-authentication-k8s-io">TokenReview v1beta1 authentication.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>TokenReview</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#tokenreview-v1-authentication-k8s-io">v1</a>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD></TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#tokenreviewspec-v1beta1-authentication-k8s-io">TokenReviewSpec</a></I></TD><TD>Spec holds information about the request being evaluated</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#tokenreviewstatus-v1beta1-authentication-k8s-io">TokenReviewStatus</a></I></TD><TD>Status is filled in by the server and indicates whether the request can be authenticated.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="tokenreviewspec-v1beta1-authentication-k8s-io">TokenReviewSpec v1beta1 authentication</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview [authentication/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>audiences</CODE><BR /><I>string array</I></TD><TD>Audiences is a list of the identifiers that the resource server presented with the token identifies as. Audience-aware token authenticators will verify that the token was intended for at least one of the audiences in this list. If no audiences are provided, the audience will default to the audience of the Kubernetes apiserver.</TD></TR>
-<TR><TD><CODE>token</CODE><BR /><I>string</I></TD><TD>Token is the opaque bearer token.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="tokenreviewstatus-v1beta1-authentication-k8s-io">TokenReviewStatus v1beta1 authentication</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview [authentication/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>audiences</CODE><BR /><I>string array</I></TD><TD>Audiences are audience identifiers chosen by the authenticator that are compatible with both the TokenReview and token. An identifier is any identifier in the intersection of the TokenReviewSpec audiences and the token&#39;s audiences. A client of the TokenReview API that sets the spec.audiences field should validate that a compatible audience identifier is returned in the status.audiences field to ensure that the TokenReview server is audience aware. If a TokenReview returns an empty status.audience field where status.authenticated is &#34;true&#34;, the token is valid against the audience of the Kubernetes API server.</TD></TR>
-<TR><TD><CODE>authenticated</CODE><BR /><I>boolean</I></TD><TD>Authenticated indicates that the token was associated with a known user.</TD></TR>
-<TR><TD><CODE>error</CODE><BR /><I>string</I></TD><TD>Error indicates that the token couldn&#39;t be checked</TD></TR>
-<TR><TD><CODE>user</CODE><BR /><I><a href="#userinfo-v1beta1-authentication-k8s-io">UserInfo</a></I></TD><TD>User is the UserInfo associated with the provided token.</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-tokenreview-v1beta1-authentication-k8s-io">Create</H2>
-<P>create a TokenReview</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/authentication.k8s.io/v1beta1/tokenreviews</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#tokenreview-v1beta1-authentication-k8s-io">TokenReview</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="userinfo-v1beta1-authentication-k8s-io">UserInfo v1beta1 authentication.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>UserInfo</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#userinfo-v1-authentication-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#tokenreviewstatus-v1beta1-authentication-k8s-io">TokenReviewStatus [authentication/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>extra</CODE><BR /><I>object</I></TD><TD>Any additional information provided by the authenticator.</TD></TR>
-<TR><TD><CODE>groups</CODE><BR /><I>string array</I></TD><TD>The names of groups this user is a part of.</TD></TR>
-<TR><TD><CODE>uid</CODE><BR /><I>string</I></TD><TD>A unique value that identifies this user across time. If this user is deleted and another user by the same name is added, they will have different UIDs.</TD></TR>
-<TR><TD><CODE>username</CODE><BR /><I>string</I></TD><TD>The name that uniquely identifies this user among all active users.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="validatingwebhook-v1beta1-admissionregistration-k8s-io">ValidatingWebhook v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ValidatingWebhook</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#validatingwebhook-v1-admissionregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionReviewVersions</CODE><BR /><I>string array</I></TD><TD>AdmissionReviewVersions is an ordered list of preferred `AdmissionReview` versions the Webhook expects. API server will try to use first version in the list which it supports. If none of the versions specified in this list supported by API server, validation will fail for this object. If a persisted webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail and be subject to the failure policy. Default to `[&#39;v1beta1&#39;]`.</TD></TR>
-<TR><TD><CODE>clientConfig</CODE><BR /><I><a href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io">WebhookClientConfig</a></I></TD><TD>ClientConfig defines how to communicate with the hook. Required</TD></TR>
-<TR><TD><CODE>failurePolicy</CODE><BR /><I>string</I></TD><TD>FailurePolicy defines how unrecognized errors from the admission endpoint are handled - allowed values are Ignore or Fail. Defaults to Ignore.</TD></TR>
-<TR><TD><CODE>matchPolicy</CODE><BR /><I>string</I></TD><TD>matchPolicy defines how the &#34;rules&#34; list is used to match incoming requests. Allowed values are &#34;Exact&#34; or &#34;Equivalent&#34;.  - Exact: match a request only if it exactly matches a specified rule. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, but &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would not be sent to the webhook.  - Equivalent: match a request if modifies a resource listed in rules, even via another API group or version. For example, if deployments can be modified via apps/v1, apps/v1beta1, and extensions/v1beta1, and &#34;rules&#34; only included `apiGroups:[&#34;apps&#34;], apiVersions:[&#34;v1&#34;], resources: [&#34;deployments&#34;]`, a request to apps/v1beta1 or extensions/v1beta1 would be converted to apps/v1 and sent to the webhook.  Defaults to &#34;Exact&#34;</TD></TR>
-<TR><TD><CODE>name</CODE><BR /><I>string</I></TD><TD>The name of the admission webhook. Name should be fully qualified, e.g., imagepolicy.kubernetes.io, where &#34;imagepolicy&#34; is the name of the webhook, and kubernetes.io is the name of the organization. Required.</TD></TR>
-<TR><TD><CODE>namespaceSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>NamespaceSelector decides whether to run the webhook on an object based on whether the namespace for that object matches the selector. If the object itself is a namespace, the matching is performed on object.metadata.labels. If the object is another cluster scoped resource, it never skips the webhook.  For example, to run the webhook on any objects whose namespace is not associated with &#34;runlevel&#34; of &#34;0&#34; or &#34;1&#34;;  you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;runlevel&#34;,       &#34;operator&#34;: &#34;NotIn&#34;,       &#34;values&#34;: [         &#34;0&#34;,         &#34;1&#34;       ]     }   ] }  If instead you want to only run the webhook on any objects whose namespace is associated with the &#34;environment&#34; of &#34;prod&#34; or &#34;staging&#34;; you will set the selector as follows: &#34;namespaceSelector&#34;: {   &#34;matchExpressions&#34;: [     {       &#34;key&#34;: &#34;environment&#34;,       &#34;operator&#34;: &#34;In&#34;,       &#34;values&#34;: [         &#34;prod&#34;,         &#34;staging&#34;       ]     }   ] }  See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.  Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>objectSelector</CODE><BR /><I><a href="#labelselector-v1-meta">LabelSelector</a></I></TD><TD>ObjectSelector decides whether to run the webhook based on if the object has matching labels. objectSelector is evaluated against both the oldObject and newObject that would be sent to the webhook, and is considered to match if either object matches the selector. A null object (oldObject in the case of create, or newObject in the case of delete) or an object that cannot have labels (like a DeploymentRollback or a PodProxyOptions object) is not considered to match. Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels. Default to the empty LabelSelector, which matches everything.</TD></TR>
-<TR><TD><CODE>rules</CODE><BR /><I><a href="#rulewithoperations-v1beta1-admissionregistration-k8s-io">RuleWithOperations</a> array</I></TD><TD>Rules describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.</TD></TR>
-<TR><TD><CODE>sideEffects</CODE><BR /><I>string</I></TD><TD>SideEffects states whether this webhook has side effects. Acceptable values are: Unknown, None, Some, NoneOnDryRun Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some. Defaults to Unknown.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE><BR /><I>integer</I></TD><TD>TimeoutSeconds specifies the timeout for this webhook. After the timeout passes, the webhook call will be ignored or the API call will fail based on the failure policy. The timeout value must be between 1 and 30 seconds. Default to 30 seconds.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>ValidatingWebhookConfiguration</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#validatingwebhookconfiguration-v1-admissionregistration-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#validatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.</TD></TR>
-<TR><TD><CODE>webhooks</CODE><BR /><I><a href="#validatingwebhook-v1beta1-admissionregistration-k8s-io">ValidatingWebhook</a> array</I><BR /><B>patch strategy</B>: <I>merge</I><BR /><B>patch merge key</B>: <I>name</I></TD><TD>Webhooks is a list of webhooks and the affected resources and operations.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="validatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList v1beta1 admissionregistration</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a> array</I></TD><TD>List of ValidatingWebhookConfiguration.</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Create</H2>
-<P>create a ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Patch</H2>
-<P>partially update the specified ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Replace</H2>
-<P>replace the specified ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Delete</H2>
-<P>delete a ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Delete Collection</H2>
-<P>delete collection of ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Read</H2>
-<P>read the specified ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfiguration</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">List</H2>
-<P>list or watch objects of kind ValidatingWebhookConfiguration</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#validatingwebhookconfigurationlist-v1beta1-admissionregistration-k8s-io">ValidatingWebhookConfigurationList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Watch</H2>
-<P>watch changes to an object of kind ValidatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/watch/validatingwebhookconfigurations/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the ValidatingWebhookConfiguration</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of ValidatingWebhookConfiguration. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/admissionregistration.k8s.io/v1beta1/watch/validatingwebhookconfigurations</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>VolumeAttachment</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeattachment-v1-storage-k8s-io">v1</a>
-<a href="#volumeattachment-v1alpha1-storage-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentlist-v1beta1-storage-k8s-io">VolumeAttachmentList [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#volumeattachmentspec-v1beta1-storage-k8s-io">VolumeAttachmentSpec</a></I></TD><TD>Specification of the desired attach/detach volume behavior. Populated by the Kubernetes system.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#volumeattachmentstatus-v1beta1-storage-k8s-io">VolumeAttachmentStatus</a></I></TD><TD>Status of the VolumeAttachment request. Populated by the entity completing the attach or detach operation, i.e. the external-attacher.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentspec-v1beta1-storage-k8s-io">VolumeAttachmentSpec v1beta1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attacher</CODE><BR /><I>string</I></TD><TD>Attacher indicates the name of the volume driver that MUST handle this request. This is the name returned by GetPluginName().</TD></TR>
-<TR><TD><CODE>nodeName</CODE><BR /><I>string</I></TD><TD>The node that the volume should be attached to.</TD></TR>
-<TR><TD><CODE>source</CODE><BR /><I><a href="#volumeattachmentsource-v1beta1-storage-k8s-io">VolumeAttachmentSource</a></I></TD><TD>Source represents the volume that should be attached.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentstatus-v1beta1-storage-k8s-io">VolumeAttachmentStatus v1beta1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attachError</CODE><BR /><I><a href="#volumeerror-v1beta1-storage-k8s-io">VolumeError</a></I></TD><TD>The last error encountered during attach operation, if any. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>attached</CODE><BR /><I>boolean</I></TD><TD>Indicates the volume is successfully attached. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>attachmentMetadata</CODE><BR /><I>object</I></TD><TD>Upon successful attach, this field is populated with any information returned by the attach operation that must be passed into subsequent WaitForAttach or Mount calls. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>detachError</CODE><BR /><I><a href="#volumeerror-v1beta1-storage-k8s-io">VolumeError</a></I></TD><TD>The last error encountered during detach operation, if any. This field must only be set by the entity completing the detach operation, i.e. the external-attacher.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentlist-v1beta1-storage-k8s-io">VolumeAttachmentList v1beta1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a> array</I></TD><TD>Items is the list of VolumeAttachments</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-volumeattachment-v1beta1-storage-k8s-io">Create</H2>
-<P>create a VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1beta1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-volumeattachment-v1beta1-storage-k8s-io">Patch</H2>
-<P>partially update the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1beta1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-volumeattachment-v1beta1-storage-k8s-io">Replace</H2>
-<P>replace the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1beta1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-volumeattachment-v1beta1-storage-k8s-io">Delete</H2>
-<P>delete a VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-volumeattachment-v1beta1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1beta1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-volumeattachment-v1beta1-storage-k8s-io">Read</H2>
-<P>read the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1beta1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-volumeattachment-v1beta1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachmentlist-v1beta1-storage-k8s-io">VolumeAttachmentList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-volumeattachment-v1beta1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind VolumeAttachment. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-volumeattachment-v1beta1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of VolumeAttachment. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1beta1/watch/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment v1alpha1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>VolumeAttachment</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeattachment-v1-storage-k8s-io">v1</a>
-<a href="#volumeattachment-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentlist-v1alpha1-storage-k8s-io">VolumeAttachmentList [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#objectmeta-v1-meta">ObjectMeta</a></I></TD><TD>Standard object metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-<TR><TD><CODE>spec</CODE><BR /><I><a href="#volumeattachmentspec-v1alpha1-storage-k8s-io">VolumeAttachmentSpec</a></I></TD><TD>Specification of the desired attach/detach volume behavior. Populated by the Kubernetes system.</TD></TR>
-<TR><TD><CODE>status</CODE><BR /><I><a href="#volumeattachmentstatus-v1alpha1-storage-k8s-io">VolumeAttachmentStatus</a></I></TD><TD>Status of the VolumeAttachment request. Populated by the entity completing the attach or detach operation, i.e. the external-attacher.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentspec-v1alpha1-storage-k8s-io">VolumeAttachmentSpec v1alpha1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attacher</CODE><BR /><I>string</I></TD><TD>Attacher indicates the name of the volume driver that MUST handle this request. This is the name returned by GetPluginName().</TD></TR>
-<TR><TD><CODE>nodeName</CODE><BR /><I>string</I></TD><TD>The node that the volume should be attached to.</TD></TR>
-<TR><TD><CODE>source</CODE><BR /><I><a href="#volumeattachmentsource-v1alpha1-storage-k8s-io">VolumeAttachmentSource</a></I></TD><TD>Source represents the volume that should be attached.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentstatus-v1alpha1-storage-k8s-io">VolumeAttachmentStatus v1alpha1 storage</H3>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>attachError</CODE><BR /><I><a href="#volumeerror-v1alpha1-storage-k8s-io">VolumeError</a></I></TD><TD>The last error encountered during attach operation, if any. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>attached</CODE><BR /><I>boolean</I></TD><TD>Indicates the volume is successfully attached. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>attachmentMetadata</CODE><BR /><I>object</I></TD><TD>Upon successful attach, this field is populated with any information returned by the attach operation that must be passed into subsequent WaitForAttach or Mount calls. This field must only be set by the entity completing the attach operation, i.e. the external-attacher.</TD></TR>
-<TR><TD><CODE>detachError</CODE><BR /><I><a href="#volumeerror-v1alpha1-storage-k8s-io">VolumeError</a></I></TD><TD>The last error encountered during detach operation, if any. This field must only be set by the entity completing the detach operation, i.e. the external-attacher.</TD></TR>
-</TBODY>
-</TABLE>
-<H3 id="volumeattachmentlist-v1alpha1-storage-k8s-io">VolumeAttachmentList v1alpha1 storage</H3>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiVersion</CODE><BR /><I>string</I></TD><TD>APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources</TD></TR>
-<TR><TD><CODE>items</CODE><BR /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a> array</I></TD><TD>Items is the list of VolumeAttachments</TD></TR>
-<TR><TD><CODE>kind</CODE><BR /><I>string</I></TD><TD>Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds</TD></TR>
-<TR><TD><CODE>metadata</CODE><BR /><I><a href="#listmeta-v1-meta">ListMeta</a></I></TD><TD>Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-"><STRONG>Write Operations</STRONG></H2>
-<H2 id="create-volumeattachment-v1alpha1-storage-k8s-io">Create</H2>
-<P>create a VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>POST /apis/storage.k8s.io/v1alpha1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-<TR><TD>202<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="patch-volumeattachment-v1alpha1-storage-k8s-io">Patch</H2>
-<P>partially update the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PATCH /apis/storage.k8s.io/v1alpha1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint. This field is required for apply requests (application/apply-patch) but optional for non-apply patch types (JsonPatch, MergePatch, StrategicMergePatch).</TD></TR>
-<TR><TD><CODE>force</CODE></TD><TD>Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#patch-v1-meta">Patch</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="replace-volumeattachment-v1alpha1-storage-k8s-io">Replace</H2>
-<P>replace the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>PUT /apis/storage.k8s.io/v1alpha1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldManager</CODE></TD><TD>fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>201<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Created</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-volumeattachment-v1alpha1-storage-k8s-io">Delete</H2>
-<P>delete a VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1alpha1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-<TR><TD>202<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>Accepted</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="delete-collection-volumeattachment-v1alpha1-storage-k8s-io">Delete Collection</H2>
-<P>delete collection of VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>DELETE /apis/storage.k8s.io/v1alpha1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>dryRun</CODE></TD><TD>When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>gracePeriodSeconds</CODE></TD><TD>The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>orphanDependents</CODE></TD><TD>Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object's finalizers list. Either this field or PropagationPolicy may be set, but not both.</TD></TR>
-<TR><TD><CODE>propagationPolicy</CODE></TD><TD>Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Body Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>body</CODE><br /><I><a href="#deleteoptions-v1-meta">DeleteOptions</a></I></TD><TD></TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#status-v1-meta">Status</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-"><STRONG>Read Operations</STRONG></H2>
-<H2 id="read-volumeattachment-v1alpha1-storage-k8s-io">Read</H2>
-<P>read the specified VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1alpha1/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>exact</CODE></TD><TD>Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'. Deprecated. Planned for removal in 1.18.</TD></TR>
-<TR><TD><CODE>export</CODE></TD><TD>Should this value be exported.  Export strips fields that a user can not specify. Deprecated. Planned for removal in 1.18.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachment-v1alpha1-storage-k8s-io">VolumeAttachment</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="list-volumeattachment-v1alpha1-storage-k8s-io">List</H2>
-<P>list or watch objects of kind VolumeAttachment</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1alpha1/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#volumeattachmentlist-v1alpha1-storage-k8s-io">VolumeAttachmentList</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-volumeattachment-v1alpha1-storage-k8s-io">Watch</H2>
-<P>watch changes to an object of kind VolumeAttachment. deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1alpha1/watch/volumeattachments/{name}</CODE>
-<H3>Path Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>name</CODE></TD><TD>name of the VolumeAttachment</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H2 id="watch-list-volumeattachment-v1alpha1-storage-k8s-io">Watch List</H2>
-<P>watch individual changes to a list of VolumeAttachment. deprecated: use the 'watch' parameter with a list operation instead.</P>
-<H3>HTTP Request</H3>
-<CODE>GET /apis/storage.k8s.io/v1alpha1/watch/volumeattachments</CODE>
-<H3>Query Parameters</H3>
-<TABLE>
-<THEAD><TR><TH>Parameter</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>allowWatchBookmarks</CODE></TD><TD>allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored.</TD></TR>
-<TR><TD><CODE>continue</CODE></TD><TD>The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".  This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.</TD></TR>
-<TR><TD><CODE>fieldSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their fields. Defaults to everything.</TD></TR>
-<TR><TD><CODE>labelSelector</CODE></TD><TD>A selector to restrict the list of returned objects by their labels. Defaults to everything.</TD></TR>
-<TR><TD><CODE>limit</CODE></TD><TD>limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.  The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.</TD></TR>
-<TR><TD><CODE>pretty</CODE></TD><TD>If 'true', then the output is pretty printed.</TD></TR>
-<TR><TD><CODE>resourceVersion</CODE></TD><TD>When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.</TD></TR>
-<TR><TD><CODE>timeoutSeconds</CODE></TD><TD>Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.</TD></TR>
-<TR><TD><CODE>watch</CODE></TD><TD>Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.</TD></TR>
-</TBODY>
-</TABLE>
-<H3>Response</H3>
-<TABLE>
-<THEAD><TR><TH>Code</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD>200<br /><I><a href="#watchevent-v1-meta">WatchEvent</a></I></TD><TD>OK</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeattachmentsource-v1beta1-storage-k8s-io">VolumeAttachmentSource v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>VolumeAttachmentSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeattachmentsource-v1-storage-k8s-io">v1</a>
-<a href="#volumeattachmentsource-v1alpha1-storage-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentspec-v1beta1-storage-k8s-io">VolumeAttachmentSpec [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>inlineVolumeSpec</CODE><BR /><I><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec</a></I></TD><TD>inlineVolumeSpec contains all the information necessary to attach a persistent volume defined by a pod&#39;s inline VolumeSource. This field is populated only for the CSIMigration feature. It contains translated fields from a pod&#39;s inline VolumeSource to a PersistentVolumeSpec. This field is alpha-level and is only honored by servers that enabled the CSIMigration feature.</TD></TR>
-<TR><TD><CODE>persistentVolumeName</CODE><BR /><I>string</I></TD><TD>Name of the persistent volume to attach.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeattachmentsource-v1alpha1-storage-k8s-io">VolumeAttachmentSource v1alpha1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>VolumeAttachmentSource</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeattachmentsource-v1-storage-k8s-io">v1</a>
-<a href="#volumeattachmentsource-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentspec-v1alpha1-storage-k8s-io">VolumeAttachmentSpec [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>inlineVolumeSpec</CODE><BR /><I><a href="#persistentvolumespec-v1-core">PersistentVolumeSpec</a></I></TD><TD>inlineVolumeSpec contains all the information necessary to attach a persistent volume defined by a pod&#39;s inline VolumeSource. This field is populated only for the CSIMigration feature. It contains translated fields from a pod&#39;s inline VolumeSource to a PersistentVolumeSpec. This field is alpha-level and is only honored by servers that enabled the CSIMigration feature.</TD></TR>
-<TR><TD><CODE>persistentVolumeName</CODE><BR /><I>string</I></TD><TD>Name of the persistent volume to attach.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeerror-v1beta1-storage-k8s-io">VolumeError v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>VolumeError</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeerror-v1-storage-k8s-io">v1</a>
-<a href="#volumeerror-v1alpha1-storage-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentstatus-v1beta1-storage-k8s-io">VolumeAttachmentStatus [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>String detailing the error encountered during Attach or Detach operation. This string may be logged, so it should not contain sensitive information.</TD></TR>
-<TR><TD><CODE>time</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time the error was encountered.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumeerror-v1alpha1-storage-k8s-io">VolumeError v1alpha1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>VolumeError</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumeerror-v1-storage-k8s-io">v1</a>
-<a href="#volumeerror-v1beta1-storage-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#volumeattachmentstatus-v1alpha1-storage-k8s-io">VolumeAttachmentStatus [storage/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>message</CODE><BR /><I>string</I></TD><TD>String detailing the error encountered during Attach or Detach operation. This string maybe logged, so it should not contain sensitive information.</TD></TR>
-<TR><TD><CODE>time</CODE><BR /><I><a href="#time-v1-meta">Time</a></I></TD><TD>Time the error was encountered.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="volumenoderesources-v1beta1-storage-k8s-io">VolumeNodeResources v1beta1 storage.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>VolumeNodeResources</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#volumenoderesources-v1-storage-k8s-io">v1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#csinodedriver-v1beta1-storage-k8s-io">CSINodeDriver [storage/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>count</CODE><BR /><I>integer</I></TD><TD>Maximum number of unique volumes managed by the CSI driver that can be used on a node. A volume that is both attached and mounted on a node is considered to be used once, not twice. The same rule applies for a unique volume that is shared among multiple pods on the same node. If this field is nil, then the supported number of volumes on this node is unbounded.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="webhookclientconfig-v1-apiextensions-k8s-io">WebhookClientConfig v1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1</CODE></TD><TD><CODE>WebhookClientConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#webhookclientconfig-v1beta1-apiextensions-k8s-io">v1beta1</a>
-<a href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhookconversion-v1-apiextensions-k8s-io">WebhookConversion [apiextensions/v1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>caBundle is a PEM encoded CA bundle which will be used to validate the webhook&#39;s server certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1-apiextensions-k8s-io">ServiceReference</a></I></TD><TD>service is a reference to the service for this webhook. Either service or url must be specified.  If the webhook is running within the cluster, then you should use `service`.</TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD>url gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.  The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.  Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.  The scheme must be &#34;https&#34;; the URL must begin with &#34;https://&#34;.  A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.  Attempting to use a user or basic auth e.g. &#34;user:password@&#34; is not allowed. Fragments (&#34;#...&#34;) and query parameters (&#34;?...&#34;) are not allowed, either.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="webhookclientconfig-v1beta1-admissionregistration-k8s-io">WebhookClientConfig v1beta1 admissionregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>WebhookClientConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#webhookclientconfig-v1-admissionregistration-k8s-io">v1</a>
-<a href="#webhookclientconfig-v1-apiextensions-k8s-io">v1</a>
-<a href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#mutatingwebhook-v1beta1-admissionregistration-k8s-io">MutatingWebhook [admissionregistration/v1beta1]</a></LI>
-  <LI><a href="#validatingwebhook-v1beta1-admissionregistration-k8s-io">ValidatingWebhook [admissionregistration/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>`caBundle` is a PEM encoded CA bundle which will be used to validate the webhook&#39;s server certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1beta1-admissionregistration-k8s-io">ServiceReference</a></I></TD><TD>`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.  If the webhook is running within the cluster, then you should use `service`.</TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD>`url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.  The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.  Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.  The scheme must be &#34;https&#34;; the URL must begin with &#34;https://&#34;.  A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.  Attempting to use a user or basic auth e.g. &#34;user:password@&#34; is not allowed. Fragments (&#34;#...&#34;) and query parameters (&#34;?...&#34;) are not allowed, either.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="webhookclientconfig-v1beta1-apiextensions-k8s-io">WebhookClientConfig v1beta1 apiextensions.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD><TD><CODE>WebhookClientConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#webhookclientconfig-v1-admissionregistration-k8s-io">v1</a>
-<a href="#webhookclientconfig-v1-apiextensions-k8s-io">v1</a>
-<a href="#webhookclientconfig-v1alpha1-auditregistration-k8s-io">v1alpha1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#customresourceconversion-v1beta1-apiextensions-k8s-io">CustomResourceConversion [apiextensions/v1beta1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>caBundle is a PEM encoded CA bundle which will be used to validate the webhook&#39;s server certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1beta1-apiextensions-k8s-io">ServiceReference</a></I></TD><TD>service is a reference to the service for this webhook. Either service or url must be specified.  If the webhook is running within the cluster, then you should use `service`.</TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD>url gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.  The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.  Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.  The scheme must be &#34;https&#34;; the URL must begin with &#34;https://&#34;.  A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.  Attempting to use a user or basic auth e.g. &#34;user:password@&#34; is not allowed. Fragments (&#34;#...&#34;) and query parameters (&#34;?...&#34;) are not allowed, either.</TD></TR>
-</TBODY>
-</TABLE>
-<H1 id="webhookclientconfig-v1alpha1-auditregistration-k8s-io">WebhookClientConfig v1alpha1 auditregistration.k8s.io</H1>
-<TABLE class="col-md-8">
-<THEAD><TR><TH>Group</TH><TH>Version</TH><TH>Kind</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>auditregistration.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD><TD><CODE>WebhookClientConfig</CODE></TD></TR>
-</TBODY>
-</TABLE>
-<DIV class="alert alert-success col-md-8"><I class="fa fa-toggle-right"></I> Other API versions of this object exist:
-<a href="#webhookclientconfig-v1-admissionregistration-k8s-io">v1</a>
-<a href="#webhookclientconfig-v1beta1-admissionregistration-k8s-io">v1beta1</a>
-<a href="#webhookclientconfig-v1-apiextensions-k8s-io">v1</a>
-<a href="#webhookclientconfig-v1beta1-apiextensions-k8s-io">v1beta1</a>
-</DIV>
-<DIV class="alert alert-info col-md-8"><I class="fa fa-info-circle"></I> Appears In:
- <UL>
-  <LI><a href="#webhook-v1alpha1-auditregistration-k8s-io">Webhook [auditregistration/v1alpha1]</a></LI>
- </UL>
-</DIV>
-<TABLE>
-<THEAD><TR><TH>Field</TH><TH>Description</TH></TR></THEAD>
-<TBODY>
-<TR><TD><CODE>caBundle</CODE><BR /><I>string</I></TD><TD>`caBundle` is a PEM encoded CA bundle which will be used to validate the webhook&#39;s server certificate. If unspecified, system trust roots on the apiserver are used.</TD></TR>
-<TR><TD><CODE>service</CODE><BR /><I><a href="#servicereference-v1alpha1-auditregistration-k8s-io">ServiceReference</a></I></TD><TD>`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.  If the webhook is running within the cluster, then you should use `service`.</TD></TR>
-<TR><TD><CODE>url</CODE><BR /><I>string</I></TD><TD>`url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.  The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.  Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.  The scheme must be &#34;https&#34;; the URL must begin with &#34;https://&#34;.  A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.  Attempting to use a user or basic auth e.g. &#34;user:password@&#34; is not allowed. Fragments (&#34;#...&#34;) and query parameters (&#34;?...&#34;) are not allowed, either.</TD></TR>
-</TBODY>
-</TABLE>
-
-</DIV>
-</DIV>
-</DIV>
-<SCRIPT src="/js/jquery-3.3.1.min.js"></SCRIPT>
-<SCRIPT src="/js/jquery.scrollTo-2.1.2.min.js"></SCRIPT>
-<SCRIPT src="/js/bootstrap-4.3.1.min.js"></SCRIPT>
-<SCRIPT src="js/navData.js"></SCRIPT>
-<SCRIPT src="/js/scroll-apiref.js"></SCRIPT>
-</BODY>
-</HTML>
diff --git a/static/docs/reference/generated/kubernetes-api/v1.18/js/navData.js b/static/docs/reference/generated/kubernetes-api/v1.18/js/navData.js
deleted file mode 100644
index e6c419c3d6..0000000000
--- a/static/docs/reference/generated/kubernetes-api/v1.18/js/navData.js
+++ /dev/null
@@ -1 +0,0 @@
-(function(){navData={"toc":[{"section":"webhookclientconfig-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1-apiextensions-k8s-io","subsections":[]},{"section":"volumenoderesources-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeerror-v1alpha1-storage-k8s-io","subsections":[]},{"section":"volumeerror-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeattachmentsource-v1alpha1-storage-k8s-io","subsections":[]},{"section":"volumeattachmentsource-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeattachment-v1alpha1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]}]}]},{"section":"volumeattachment-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"validatingwebhook-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"userinfo-v1beta1-authentication-k8s-io","subsections":[]},{"section":"tokenreview-v1beta1-authentication-k8s-io","subsections":[{"section":"-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-","subsections":[{"section":"create-tokenreview-v1beta1-authentication-k8s-io","subsections":[]}]}]},{"section":"subjectrulesreviewstatus-v1beta1-authorization-k8s-io","subsections":[]},{"section":"subjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-subjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"subject-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"subject-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"subject-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"storageclass-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-storageclass-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-storageclass-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"servicereference-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"servicereference-v1-apiregistration-k8s-io","subsections":[]},{"section":"servicereference-v1-apiextensions-k8s-io","subsections":[]},{"section":"selfsubjectrulesreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectrulesreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"selfsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"scheduling-v1alpha1-node-k8s-io","subsections":[]},{"section":"runtimeclass-v1alpha1-node-k8s-io","subsections":[{"section":"-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","subsections":[{"section":"watch-list-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"watch-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"list-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"read-runtimeclass-v1alpha1-node-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","subsections":[{"section":"delete-collection-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"delete-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"replace-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"patch-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"create-runtimeclass-v1alpha1-node-k8s-io","subsections":[]}]}]},{"section":"rulewithoperations-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"roleref-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"roleref-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"resourcerule-v1beta1-authorization-k8s-io","subsections":[]},{"section":"resourcemetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"resourcemetricsource-v2beta1-autoscaling","subsections":[]},{"section":"resourceattributes-v1beta1-authorization-k8s-io","subsections":[]},{"section":"priorityclass-v1alpha1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]}]}]},{"section":"priorityclass-v1beta1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]}]}]},{"section":"policyrule-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"policyrule-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"podsmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"podsmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"overhead-v1alpha1-node-k8s-io","subsections":[]},{"section":"objectmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"objectmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"nonresourcerule-v1beta1-authorization-k8s-io","subsections":[]},{"section":"nonresourceattributes-v1beta1-authorization-k8s-io","subsections":[]},{"section":"mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"mutatingwebhook-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"metricstatus-v2beta1-autoscaling","subsections":[]},{"section":"metricspec-v2beta1-autoscaling","subsections":[]},{"section":"localsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-localsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"lease-v1beta1-coordination-k8s-io","subsections":[{"section":"-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"watch-list-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"watch-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"list-all-namespaces-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"list-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"read-lease-v1beta1-coordination-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-","subsections":[{"section":"delete-collection-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"delete-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"replace-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"patch-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"create-lease-v1beta1-coordination-k8s-io","subsections":[]}]}]},{"section":"jobtemplatespec-v2alpha1-batch","subsections":[]},{"section":"jsonschemapropsorbool-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemapropsorarray-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemaprops-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"json-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"ingresstls-v1beta1-extensions","subsections":[]},{"section":"ingressrule-v1beta1-extensions","subsections":[]},{"section":"ingressbackend-v1beta1-extensions","subsections":[]},{"section":"ingress-v1beta1-extensions","subsections":[{"section":"-strong-status-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"replace-status-ingress-v1beta1-extensions","subsections":[]},{"section":"read-status-ingress-v1beta1-extensions","subsections":[]},{"section":"patch-status-ingress-v1beta1-extensions","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1beta1-extensions","subsections":[]},{"section":"watch-list-ingress-v1beta1-extensions","subsections":[]},{"section":"watch-ingress-v1beta1-extensions","subsections":[]},{"section":"list-all-namespaces-ingress-v1beta1-extensions","subsections":[]},{"section":"list-ingress-v1beta1-extensions","subsections":[]},{"section":"read-ingress-v1beta1-extensions","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"delete-collection-ingress-v1beta1-extensions","subsections":[]},{"section":"delete-ingress-v1beta1-extensions","subsections":[]},{"section":"replace-ingress-v1beta1-extensions","subsections":[]},{"section":"patch-ingress-v1beta1-extensions","subsections":[]},{"section":"create-ingress-v1beta1-extensions","subsections":[]}]}]},{"section":"horizontalpodautoscalercondition-v2beta1-autoscaling","subsections":[]},{"section":"horizontalpodautoscaler-v2beta1-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]}]},{"section":"horizontalpodautoscaler-v2beta2-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]}]},{"section":"httpingressrulevalue-v1beta1-extensions","subsections":[]},{"section":"httpingresspath-v1beta1-extensions","subsections":[]},{"section":"externalmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"externalmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"externaldocumentation-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"eventseries-v1beta1-events-k8s-io","subsections":[]},{"section":"event-v1beta1-events-k8s-io","subsections":[{"section":"-strong-read-operations-event-v1beta1-events-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1beta1-events-k8s-io","subsections":[]},{"section":"watch-list-event-v1beta1-events-k8s-io","subsections":[]},{"section":"watch-event-v1beta1-events-k8s-io","subsections":[]},{"section":"list-all-namespaces-event-v1beta1-events-k8s-io","subsections":[]},{"section":"list-event-v1beta1-events-k8s-io","subsections":[]},{"section":"read-event-v1beta1-events-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-event-v1beta1-events-k8s-io-strong-","subsections":[{"section":"delete-collection-event-v1beta1-events-k8s-io","subsections":[]},{"section":"delete-event-v1beta1-events-k8s-io","subsections":[]},{"section":"replace-event-v1beta1-events-k8s-io","subsections":[]},{"section":"patch-event-v1beta1-events-k8s-io","subsections":[]},{"section":"create-event-v1beta1-events-k8s-io","subsections":[]}]}]},{"section":"endpointport-v1beta1-discovery-k8s-io","subsections":[]},{"section":"customresourcevalidation-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresources-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcescale-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionversion-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionnames-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[{"section":"-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"watch-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"list-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"read-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"delete-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"replace-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"patch-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"create-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]}]},{"section":"customresourceconversion-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcecolumndefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"crossversionobjectreference-v2beta1-autoscaling","subsections":[]},{"section":"crossversionobjectreference-v2beta2-autoscaling","subsections":[]},{"section":"cronjob-v2alpha1-batch","subsections":[{"section":"-strong-status-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"replace-status-cronjob-v2alpha1-batch","subsections":[]},{"section":"read-status-cronjob-v2alpha1-batch","subsections":[]},{"section":"patch-status-cronjob-v2alpha1-batch","subsections":[]}]},{"section":"-strong-read-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-cronjob-v2alpha1-batch","subsections":[]},{"section":"watch-list-cronjob-v2alpha1-batch","subsections":[]},{"section":"watch-cronjob-v2alpha1-batch","subsections":[]},{"section":"list-all-namespaces-cronjob-v2alpha1-batch","subsections":[]},{"section":"list-cronjob-v2alpha1-batch","subsections":[]},{"section":"read-cronjob-v2alpha1-batch","subsections":[]}]},{"section":"-strong-write-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"delete-collection-cronjob-v2alpha1-batch","subsections":[]},{"section":"delete-cronjob-v2alpha1-batch","subsections":[]},{"section":"replace-cronjob-v2alpha1-batch","subsections":[]},{"section":"patch-cronjob-v2alpha1-batch","subsections":[]},{"section":"create-cronjob-v2alpha1-batch","subsections":[]}]}]},{"section":"clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"csinodedriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"csinode-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-csinode-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-csinode-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"csidriver-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-csidriver-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-csidriver-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"aggregationrule-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"aggregationrule-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"apiservicecondition-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"apiservice-v1beta1-apiregistration-k8s-io","subsections":[{"section":"-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"replace-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"read-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"patch-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"watch-list-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"watch-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"list-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"read-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"delete-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"replace-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"patch-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"create-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]}]},{"section":"-strong-old-api-versions-strong-","subsections":[]},{"section":"windowssecuritycontextoptions-v1-core","subsections":[]},{"section":"weightedpodaffinityterm-v1-core","subsections":[]},{"section":"webhookthrottleconfig-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"webhookconversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1-admissionregistration-k8s-io","subsections":[]},{"section":"webhook-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"watchevent-v1-meta","subsections":[]},{"section":"vspherevirtualdiskvolumesource-v1-core","subsections":[]},{"section":"volumeprojection-v1-core","subsections":[]},{"section":"volumenoderesources-v1-storage-k8s-io","subsections":[]},{"section":"volumenodeaffinity-v1-core","subsections":[]},{"section":"volumemount-v1-core","subsections":[]},{"section":"volumeerror-v1-storage-k8s-io","subsections":[]},{"section":"volumedevice-v1-core","subsections":[]},{"section":"volumeattachmentsource-v1-storage-k8s-io","subsections":[]},{"section":"validatingwebhook-v1-admissionregistration-k8s-io","subsections":[]},{"section":"usersubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"userinfo-v1-authentication-k8s-io","subsections":[]},{"section":"typedlocalobjectreference-v1-core","subsections":[]},{"section":"topologyspreadconstraint-v1-core","subsections":[]},{"section":"topologyselectorterm-v1-core","subsections":[]},{"section":"topologyselectorlabelrequirement-v1-core","subsections":[]},{"section":"toleration-v1-core","subsections":[]},{"section":"time-v1-meta","subsections":[]},{"section":"taint-v1-core","subsections":[]},{"section":"tcpsocketaction-v1-core","subsections":[]},{"section":"sysctl-v1-core","subsections":[]},{"section":"supplementalgroupsstrategyoptions-v1beta1-policy","subsections":[]},{"section":"subjectrulesreviewstatus-v1-authorization-k8s-io","subsections":[]},{"section":"subject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"storageosvolumesource-v1-core","subsections":[]},{"section":"storageospersistentvolumesource-v1-core","subsections":[]},{"section":"statusdetails-v1-meta","subsections":[]},{"section":"statuscause-v1-meta","subsections":[]},{"section":"status-v1-meta","subsections":[]},{"section":"statefulsetupdatestrategy-v1-apps","subsections":[]},{"section":"statefulsetcondition-v1-apps","subsections":[]},{"section":"sessionaffinityconfig-v1-core","subsections":[]},{"section":"servicereference-v1-admissionregistration-k8s-io","subsections":[]},{"section":"serviceport-v1-core","subsections":[]},{"section":"serviceaccounttokenprojection-v1-core","subsections":[]},{"section":"serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"serveraddressbyclientcidr-v1-meta","subsections":[]},{"section":"securitycontext-v1-core","subsections":[]},{"section":"secretvolumesource-v1-core","subsections":[]},{"section":"secretreference-v1-core","subsections":[]},{"section":"secretprojection-v1-core","subsections":[]},{"section":"secretkeyselector-v1-core","subsections":[]},{"section":"secretenvsource-v1-core","subsections":[]},{"section":"scopedresourceselectorrequirement-v1-core","subsections":[]},{"section":"scopeselector-v1-core","subsections":[]},{"section":"scheduling-v1beta1-node-k8s-io","subsections":[]},{"section":"scaleiovolumesource-v1-core","subsections":[]},{"section":"scaleiopersistentvolumesource-v1-core","subsections":[]},{"section":"scale-v1-autoscaling","subsections":[]},{"section":"selinuxstrategyoptions-v1beta1-policy","subsections":[]},{"section":"selinuxoptions-v1-core","subsections":[]},{"section":"runtimeclassstrategyoptions-v1beta1-policy","subsections":[]},{"section":"runasuserstrategyoptions-v1beta1-policy","subsections":[]},{"section":"runasgroupstrategyoptions-v1beta1-policy","subsections":[]},{"section":"rulewithoperations-v1-admissionregistration-k8s-io","subsections":[]},{"section":"rollingupdatestatefulsetstrategy-v1-apps","subsections":[]},{"section":"roleref-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"resourcerule-v1-authorization-k8s-io","subsections":[]},{"section":"resourcerequirements-v1-core","subsections":[]},{"section":"resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"resourcemetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"resourcemetricsource-v2beta2-autoscaling","subsections":[]},{"section":"resourcefieldselector-v1-core","subsections":[]},{"section":"resourceattributes-v1-authorization-k8s-io","subsections":[]},{"section":"replicationcontrollercondition-v1-core","subsections":[]},{"section":"replicasetcondition-v1-apps","subsections":[]},{"section":"rbdvolumesource-v1-core","subsections":[]},{"section":"rbdpersistentvolumesource-v1-core","subsections":[]},{"section":"quobytevolumesource-v1-core","subsections":[]},{"section":"queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"quantity-resource-core","subsections":[]},{"section":"projectedvolumesource-v1-core","subsections":[]},{"section":"probe-v1-core","subsections":[]},{"section":"prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"preferredschedulingterm-v1-core","subsections":[]},{"section":"preconditions-v1-meta","subsections":[]},{"section":"portworxvolumesource-v1-core","subsections":[]},{"section":"policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"policyrule-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"policy-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"podsmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"podsmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"podsecuritycontext-v1-core","subsections":[]},{"section":"podreadinessgate-v1-core","subsections":[]},{"section":"podip-v1-core","subsections":[]},{"section":"poddnsconfigoption-v1-core","subsections":[]},{"section":"poddnsconfig-v1-core","subsections":[]},{"section":"podcondition-v1-core","subsections":[]},{"section":"podantiaffinity-v1-core","subsections":[]},{"section":"podaffinityterm-v1-core","subsections":[]},{"section":"podaffinity-v1-core","subsections":[]},{"section":"photonpersistentdiskvolumesource-v1-core","subsections":[]},{"section":"persistentvolumeclaimvolumesource-v1-core","subsections":[]},{"section":"persistentvolumeclaimcondition-v1-core","subsections":[]},{"section":"patch-v1-meta","subsections":[]},{"section":"ownerreference-v1-meta","subsections":[]},{"section":"overhead-v1beta1-node-k8s-io","subsections":[]},{"section":"objectreference-v1-core","subsections":[]},{"section":"objectmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"objectmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"objectmeta-v1-meta","subsections":[]},{"section":"objectfieldselector-v1-core","subsections":[]},{"section":"nonresourcerule-v1-authorization-k8s-io","subsections":[]},{"section":"nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"nonresourceattributes-v1-authorization-k8s-io","subsections":[]},{"section":"nodesysteminfo-v1-core","subsections":[]},{"section":"nodeselectorterm-v1-core","subsections":[]},{"section":"nodeselectorrequirement-v1-core","subsections":[]},{"section":"nodeselector-v1-core","subsections":[]},{"section":"nodedaemonendpoints-v1-core","subsections":[]},{"section":"nodeconfigstatus-v1-core","subsections":[]},{"section":"nodeconfigsource-v1-core","subsections":[]},{"section":"nodecondition-v1-core","subsections":[]},{"section":"nodeaffinity-v1-core","subsections":[]},{"section":"nodeaddress-v1-core","subsections":[]},{"section":"networkpolicyport-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicypeer-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicyingressrule-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicyegressrule-v1-networking-k8s-io","subsections":[]},{"section":"namespacecondition-v1-core","subsections":[]},{"section":"nfsvolumesource-v1-core","subsections":[]},{"section":"mutatingwebhook-v1-admissionregistration-k8s-io","subsections":[]},{"section":"microtime-v1-meta","subsections":[]},{"section":"metricvaluestatus-v2beta2-autoscaling","subsections":[]},{"section":"metrictarget-v2beta2-autoscaling","subsections":[]},{"section":"metricstatus-v2beta2-autoscaling","subsections":[]},{"section":"metricspec-v2beta2-autoscaling","subsections":[]},{"section":"metricidentifier-v2beta2-autoscaling","subsections":[]},{"section":"managedfieldsentry-v1-meta","subsections":[]},{"section":"localvolumesource-v1-core","subsections":[]},{"section":"localobjectreference-v1-core","subsections":[]},{"section":"loadbalancerstatus-v1-core","subsections":[]},{"section":"loadbalanceringress-v1-core","subsections":[]},{"section":"listmeta-v1-meta","subsections":[]},{"section":"limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"limitrangeitem-v1-core","subsections":[]},{"section":"lifecycle-v1-core","subsections":[]},{"section":"labelselectorrequirement-v1-meta","subsections":[]},{"section":"labelselector-v1-meta","subsections":[]},{"section":"keytopath-v1-core","subsections":[]},{"section":"jobtemplatespec-v1beta1-batch","subsections":[]},{"section":"jobcondition-v1-batch","subsections":[]},{"section":"jsonschemapropsorbool-v1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemapropsorarray-v1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemaprops-v1-apiextensions-k8s-io","subsections":[]},{"section":"json-v1-apiextensions-k8s-io","subsections":[]},{"section":"ingresstls-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingressrule-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingressbackend-v1beta1-networking-k8s-io","subsections":[]},{"section":"iscsivolumesource-v1-core","subsections":[]},{"section":"iscsipersistentvolumesource-v1-core","subsections":[]},{"section":"ipblock-v1-networking-k8s-io","subsections":[]},{"section":"idrange-v1beta1-policy","subsections":[]},{"section":"hostportrange-v1beta1-policy","subsections":[]},{"section":"hostpathvolumesource-v1-core","subsections":[]},{"section":"hostalias-v1-core","subsections":[]},{"section":"horizontalpodautoscalercondition-v2beta2-autoscaling","subsections":[]},{"section":"horizontalpodautoscalerbehavior-v2beta2-autoscaling","subsections":[]},{"section":"handler-v1-core","subsections":[]},{"section":"httpingressrulevalue-v1beta1-networking-k8s-io","subsections":[]},{"section":"httpingresspath-v1beta1-networking-k8s-io","subsections":[]},{"section":"httpheader-v1-core","subsections":[]},{"section":"httpgetaction-v1-core","subsections":[]},{"section":"hpascalingrules-v2beta2-autoscaling","subsections":[]},{"section":"hpascalingpolicy-v2beta2-autoscaling","subsections":[]},{"section":"groupversionfordiscovery-v1-meta","subsections":[]},{"section":"groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"glusterfsvolumesource-v1-core","subsections":[]},{"section":"glusterfspersistentvolumesource-v1-core","subsections":[]},{"section":"gitrepovolumesource-v1-core","subsections":[]},{"section":"gcepersistentdiskvolumesource-v1-core","subsections":[]},{"section":"flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"flockervolumesource-v1-core","subsections":[]},{"section":"flexvolumesource-v1-core","subsections":[]},{"section":"flexpersistentvolumesource-v1-core","subsections":[]},{"section":"fieldsv1-v1-meta","subsections":[]},{"section":"fsgroupstrategyoptions-v1beta1-policy","subsections":[]},{"section":"fcvolumesource-v1-core","subsections":[]},{"section":"externalmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"externalmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"externaldocumentation-v1-apiextensions-k8s-io","subsections":[]},{"section":"execaction-v1-core","subsections":[]},{"section":"eviction-v1beta1-policy","subsections":[]},{"section":"eventsource-v1-core","subsections":[]},{"section":"eventseries-v1-core","subsections":[]},{"section":"ephemeralcontainer-v1-core","subsections":[]},{"section":"envvarsource-v1-core","subsections":[]},{"section":"envvar-v1-core","subsections":[]},{"section":"envfromsource-v1-core","subsections":[]},{"section":"endpointsubset-v1-core","subsections":[]},{"section":"endpointport-v1-core","subsections":[]},{"section":"endpointconditions-v1beta1-discovery-k8s-io","subsections":[]},{"section":"endpointaddress-v1-core","subsections":[]},{"section":"endpoint-v1beta1-discovery-k8s-io","subsections":[]},{"section":"emptydirvolumesource-v1-core","subsections":[]},{"section":"downwardapivolumesource-v1-core","subsections":[]},{"section":"downwardapivolumefile-v1-core","subsections":[]},{"section":"downwardapiprojection-v1-core","subsections":[]},{"section":"deploymentcondition-v1-apps","subsections":[]},{"section":"deleteoptions-v1-meta","subsections":[]},{"section":"daemonsetupdatestrategy-v1-apps","subsections":[]},{"section":"daemonsetcondition-v1-apps","subsections":[]},{"section":"daemonendpoint-v1-core","subsections":[]},{"section":"customresourcevalidation-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresources-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcestatus-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcescale-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionnames-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitioncondition-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourceconversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcecolumndefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"crossversionobjectreference-v1-autoscaling","subsections":[]},{"section":"containerstatewaiting-v1-core","subsections":[]},{"section":"containerstateterminated-v1-core","subsections":[]},{"section":"containerstaterunning-v1-core","subsections":[]},{"section":"containerstate-v1-core","subsections":[]},{"section":"containerport-v1-core","subsections":[]},{"section":"containerimage-v1-core","subsections":[]},{"section":"configmapvolumesource-v1-core","subsections":[]},{"section":"configmapprojection-v1-core","subsections":[]},{"section":"configmapnodeconfigsource-v1-core","subsections":[]},{"section":"configmapkeyselector-v1-core","subsections":[]},{"section":"configmapenvsource-v1-core","subsections":[]},{"section":"componentcondition-v1-core","subsections":[]},{"section":"clientipconfig-v1-core","subsections":[]},{"section":"cindervolumesource-v1-core","subsections":[]},{"section":"cinderpersistentvolumesource-v1-core","subsections":[]},{"section":"certificatesigningrequestcondition-v1beta1-certificates-k8s-io","subsections":[]},{"section":"cephfsvolumesource-v1-core","subsections":[]},{"section":"cephfspersistentvolumesource-v1-core","subsections":[]},{"section":"capabilities-v1-core","subsections":[]},{"section":"csivolumesource-v1-core","subsections":[]},{"section":"csipersistentvolumesource-v1-core","subsections":[]},{"section":"csinodedriver-v1-storage-k8s-io","subsections":[]},{"section":"boundobjectreference-v1-authentication-k8s-io","subsections":[]},{"section":"azurefilevolumesource-v1-core","subsections":[]},{"section":"azurefilepersistentvolumesource-v1-core","subsections":[]},{"section":"azurediskvolumesource-v1-core","subsections":[]},{"section":"attachedvolume-v1-core","subsections":[]},{"section":"allowedhostpath-v1beta1-policy","subsections":[]},{"section":"allowedflexvolume-v1beta1-policy","subsections":[]},{"section":"allowedcsidriver-v1beta1-policy","subsections":[]},{"section":"aggregationrule-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"affinity-v1-core","subsections":[]},{"section":"awselasticblockstorevolumesource-v1-core","subsections":[]},{"section":"apiversions-v1-meta","subsections":[]},{"section":"apiservicecondition-v1-apiregistration-k8s-io","subsections":[]},{"section":"apiresource-v1-meta","subsections":[]},{"section":"apigroup-v1-meta","subsections":[]},{"section":"-strong-definitions-strong-","subsections":[]},{"section":"networkpolicy-v1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"watch-list-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"watch-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"list-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"read-networkpolicy-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"delete-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"replace-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"patch-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"create-networkpolicy-v1-networking-k8s-io","subsections":[]}]}]},{"section":"tokenreview-v1-authentication-k8s-io","subsections":[{"section":"-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-","subsections":[{"section":"create-tokenreview-v1-authentication-k8s-io","subsections":[]}]}]},{"section":"tokenrequest-v1-authentication-k8s-io","subsections":[]},{"section":"subjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-subjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"serviceaccount-v1-core","subsections":[{"section":"-strong-read-operations-serviceaccount-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-serviceaccount-v1-core","subsections":[]},{"section":"watch-list-serviceaccount-v1-core","subsections":[]},{"section":"watch-serviceaccount-v1-core","subsections":[]},{"section":"list-all-namespaces-serviceaccount-v1-core","subsections":[]},{"section":"list-serviceaccount-v1-core","subsections":[]},{"section":"read-serviceaccount-v1-core","subsections":[]}]},{"section":"-strong-write-operations-serviceaccount-v1-core-strong-","subsections":[{"section":"delete-collection-serviceaccount-v1-core","subsections":[]},{"section":"delete-serviceaccount-v1-core","subsections":[]},{"section":"replace-serviceaccount-v1-core","subsections":[]},{"section":"patch-serviceaccount-v1-core","subsections":[]},{"section":"create-serviceaccount-v1-core","subsections":[]}]}]},{"section":"selfsubjectrulesreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectrulesreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"selfsubjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"runtimeclass-v1beta1-node-k8s-io","subsections":[{"section":"-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-","subsections":[{"section":"watch-list-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"watch-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"list-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"read-runtimeclass-v1beta1-node-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-","subsections":[{"section":"delete-collection-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"delete-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"replace-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"patch-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"create-runtimeclass-v1beta1-node-k8s-io","subsections":[]}]}]},{"section":"rolebinding-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"resourcequota-v1-core","subsections":[{"section":"-strong-status-operations-resourcequota-v1-core-strong-","subsections":[{"section":"replace-status-resourcequota-v1-core","subsections":[]},{"section":"read-status-resourcequota-v1-core","subsections":[]},{"section":"patch-status-resourcequota-v1-core","subsections":[]}]},{"section":"-strong-read-operations-resourcequota-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-resourcequota-v1-core","subsections":[]},{"section":"watch-list-resourcequota-v1-core","subsections":[]},{"section":"watch-resourcequota-v1-core","subsections":[]},{"section":"list-all-namespaces-resourcequota-v1-core","subsections":[]},{"section":"list-resourcequota-v1-core","subsections":[]},{"section":"read-resourcequota-v1-core","subsections":[]}]},{"section":"-strong-write-operations-resourcequota-v1-core-strong-","subsections":[{"section":"delete-collection-resourcequota-v1-core","subsections":[]},{"section":"delete-resourcequota-v1-core","subsections":[]},{"section":"replace-resourcequota-v1-core","subsections":[]},{"section":"patch-resourcequota-v1-core","subsections":[]},{"section":"create-resourcequota-v1-core","subsections":[]}]}]},{"section":"prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[{"section":"-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]}]},{"section":"persistentvolume-v1-core","subsections":[{"section":"-strong-status-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"replace-status-persistentvolume-v1-core","subsections":[]},{"section":"read-status-persistentvolume-v1-core","subsections":[]},{"section":"patch-status-persistentvolume-v1-core","subsections":[]}]},{"section":"-strong-read-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"watch-list-persistentvolume-v1-core","subsections":[]},{"section":"watch-persistentvolume-v1-core","subsections":[]},{"section":"list-persistentvolume-v1-core","subsections":[]},{"section":"read-persistentvolume-v1-core","subsections":[]}]},{"section":"-strong-write-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"delete-collection-persistentvolume-v1-core","subsections":[]},{"section":"delete-persistentvolume-v1-core","subsections":[]},{"section":"replace-persistentvolume-v1-core","subsections":[]},{"section":"patch-persistentvolume-v1-core","subsections":[]},{"section":"create-persistentvolume-v1-core","subsections":[]}]}]},{"section":"node-v1-core","subsections":[{"section":"-strong-proxy-operations-node-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-node-v1-core","subsections":[]},{"section":"replace-connect-proxy-node-v1-core","subsections":[]},{"section":"head-connect-proxy-path-node-v1-core","subsections":[]},{"section":"head-connect-proxy-node-v1-core","subsections":[]},{"section":"get-connect-proxy-path-node-v1-core","subsections":[]},{"section":"get-connect-proxy-node-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-node-v1-core","subsections":[]},{"section":"delete-connect-proxy-node-v1-core","subsections":[]},{"section":"create-connect-proxy-path-node-v1-core","subsections":[]},{"section":"create-connect-proxy-node-v1-core","subsections":[]}]},{"section":"-strong-status-operations-node-v1-core-strong-","subsections":[{"section":"replace-status-node-v1-core","subsections":[]},{"section":"read-status-node-v1-core","subsections":[]},{"section":"patch-status-node-v1-core","subsections":[]}]},{"section":"-strong-read-operations-node-v1-core-strong-","subsections":[{"section":"watch-list-node-v1-core","subsections":[]},{"section":"watch-node-v1-core","subsections":[]},{"section":"list-node-v1-core","subsections":[]},{"section":"read-node-v1-core","subsections":[]}]},{"section":"-strong-write-operations-node-v1-core-strong-","subsections":[{"section":"delete-collection-node-v1-core","subsections":[]},{"section":"delete-node-v1-core","subsections":[]},{"section":"replace-node-v1-core","subsections":[]},{"section":"patch-node-v1-core","subsections":[]},{"section":"create-node-v1-core","subsections":[]}]}]},{"section":"namespace-v1-core","subsections":[{"section":"-strong-status-operations-namespace-v1-core-strong-","subsections":[{"section":"replace-status-namespace-v1-core","subsections":[]},{"section":"read-status-namespace-v1-core","subsections":[]},{"section":"patch-status-namespace-v1-core","subsections":[]}]},{"section":"-strong-read-operations-namespace-v1-core-strong-","subsections":[{"section":"watch-list-namespace-v1-core","subsections":[]},{"section":"watch-namespace-v1-core","subsections":[]},{"section":"list-namespace-v1-core","subsections":[]},{"section":"read-namespace-v1-core","subsections":[]}]},{"section":"-strong-write-operations-namespace-v1-core-strong-","subsections":[{"section":"delete-namespace-v1-core","subsections":[]},{"section":"replace-namespace-v1-core","subsections":[]},{"section":"patch-namespace-v1-core","subsections":[]},{"section":"create-namespace-v1-core","subsections":[]}]}]},{"section":"localsubjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-localsubjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"lease-v1-coordination-k8s-io","subsections":[{"section":"-strong-read-operations-lease-v1-coordination-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-lease-v1-coordination-k8s-io","subsections":[]},{"section":"watch-list-lease-v1-coordination-k8s-io","subsections":[]},{"section":"watch-lease-v1-coordination-k8s-io","subsections":[]},{"section":"list-all-namespaces-lease-v1-coordination-k8s-io","subsections":[]},{"section":"list-lease-v1-coordination-k8s-io","subsections":[]},{"section":"read-lease-v1-coordination-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-lease-v1-coordination-k8s-io-strong-","subsections":[{"section":"delete-collection-lease-v1-coordination-k8s-io","subsections":[]},{"section":"delete-lease-v1-coordination-k8s-io","subsections":[]},{"section":"replace-lease-v1-coordination-k8s-io","subsections":[]},{"section":"patch-lease-v1-coordination-k8s-io","subsections":[]},{"section":"create-lease-v1-coordination-k8s-io","subsections":[]}]}]},{"section":"flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[{"section":"-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]}]},{"section":"componentstatus-v1-core","subsections":[{"section":"-strong-read-operations-componentstatus-v1-core-strong-","subsections":[{"section":"list-componentstatus-v1-core","subsections":[]},{"section":"read-componentstatus-v1-core","subsections":[]}]}]},{"section":"clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[{"section":"-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"read-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"watch-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"list-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"read-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"delete-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"replace-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"patch-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"create-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]}]},{"section":"binding-v1-core","subsections":[{"section":"-strong-write-operations-binding-v1-core-strong-","subsections":[{"section":"create-binding-v1-core","subsections":[]}]}]},{"section":"auditsink-v1alpha1-auditregistration-k8s-io","subsections":[{"section":"-strong-read-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-","subsections":[{"section":"watch-list-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"watch-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"list-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"read-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"delete-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"replace-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"patch-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]},{"section":"create-auditsink-v1alpha1-auditregistration-k8s-io","subsections":[]}]}]},{"section":"apiservice-v1-apiregistration-k8s-io","subsections":[{"section":"-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"replace-status-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"read-status-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"patch-status-apiservice-v1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"watch-list-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"watch-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"list-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"read-apiservice-v1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"delete-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"replace-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"patch-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"create-apiservice-v1-apiregistration-k8s-io","subsections":[]}]}]},{"section":"-strong-cluster-apis-strong-","subsections":[]},{"section":"podsecuritypolicy-v1beta1-policy","subsections":[{"section":"-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-","subsections":[{"section":"watch-list-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"watch-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"list-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"read-podsecuritypolicy-v1beta1-policy","subsections":[]}]},{"section":"-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-","subsections":[{"section":"delete-collection-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"delete-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"replace-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"patch-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"create-podsecuritypolicy-v1beta1-policy","subsections":[]}]}]},{"section":"podpreset-v1alpha1-settings-k8s-io","subsections":[{"section":"-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"watch-list-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"watch-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"list-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"read-podpreset-v1alpha1-settings-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-","subsections":[{"section":"delete-collection-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"delete-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"replace-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"patch-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"create-podpreset-v1alpha1-settings-k8s-io","subsections":[]}]}]},{"section":"priorityclass-v1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1-scheduling-k8s-io","subsections":[]}]}]},{"section":"poddisruptionbudget-v1beta1-policy","subsections":[{"section":"-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"replace-status-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"read-status-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"patch-status-poddisruptionbudget-v1beta1-policy","subsections":[]}]},{"section":"-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"watch-list-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"watch-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"list-all-namespaces-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"list-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"read-poddisruptionbudget-v1beta1-policy","subsections":[]}]},{"section":"-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"delete-collection-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"delete-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"replace-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"patch-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"create-poddisruptionbudget-v1beta1-policy","subsections":[]}]}]},{"section":"podtemplate-v1-core","subsections":[{"section":"-strong-read-operations-podtemplate-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-podtemplate-v1-core","subsections":[]},{"section":"watch-list-podtemplate-v1-core","subsections":[]},{"section":"watch-podtemplate-v1-core","subsections":[]},{"section":"list-all-namespaces-podtemplate-v1-core","subsections":[]},{"section":"list-podtemplate-v1-core","subsections":[]},{"section":"read-podtemplate-v1-core","subsections":[]}]},{"section":"-strong-write-operations-podtemplate-v1-core-strong-","subsections":[{"section":"delete-collection-podtemplate-v1-core","subsections":[]},{"section":"delete-podtemplate-v1-core","subsections":[]},{"section":"replace-podtemplate-v1-core","subsections":[]},{"section":"patch-podtemplate-v1-core","subsections":[]},{"section":"create-podtemplate-v1-core","subsections":[]}]}]},{"section":"validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"horizontalpodautoscaler-v1-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]}]},{"section":"limitrange-v1-core","subsections":[{"section":"-strong-read-operations-limitrange-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-limitrange-v1-core","subsections":[]},{"section":"watch-list-limitrange-v1-core","subsections":[]},{"section":"watch-limitrange-v1-core","subsections":[]},{"section":"list-all-namespaces-limitrange-v1-core","subsections":[]},{"section":"list-limitrange-v1-core","subsections":[]},{"section":"read-limitrange-v1-core","subsections":[]}]},{"section":"-strong-write-operations-limitrange-v1-core-strong-","subsections":[{"section":"delete-collection-limitrange-v1-core","subsections":[]},{"section":"delete-limitrange-v1-core","subsections":[]},{"section":"replace-limitrange-v1-core","subsections":[]},{"section":"patch-limitrange-v1-core","subsections":[]},{"section":"create-limitrange-v1-core","subsections":[]}]}]},{"section":"event-v1-core","subsections":[{"section":"-strong-read-operations-event-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1-core","subsections":[]},{"section":"watch-list-event-v1-core","subsections":[]},{"section":"watch-event-v1-core","subsections":[]},{"section":"list-all-namespaces-event-v1-core","subsections":[]},{"section":"list-event-v1-core","subsections":[]},{"section":"read-event-v1-core","subsections":[]}]},{"section":"-strong-write-operations-event-v1-core-strong-","subsections":[{"section":"delete-collection-event-v1-core","subsections":[]},{"section":"delete-event-v1-core","subsections":[]},{"section":"replace-event-v1-core","subsections":[]},{"section":"patch-event-v1-core","subsections":[]},{"section":"create-event-v1-core","subsections":[]}]}]},{"section":"customresourcedefinition-v1-apiextensions-k8s-io","subsections":[{"section":"-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"replace-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"read-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"patch-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"watch-list-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"watch-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"list-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"read-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"delete-collection-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"delete-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"replace-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"patch-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"create-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]}]},{"section":"controllerrevision-v1-apps","subsections":[{"section":"-strong-read-operations-controllerrevision-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-controllerrevision-v1-apps","subsections":[]},{"section":"watch-list-controllerrevision-v1-apps","subsections":[]},{"section":"watch-controllerrevision-v1-apps","subsections":[]},{"section":"list-all-namespaces-controllerrevision-v1-apps","subsections":[]},{"section":"list-controllerrevision-v1-apps","subsections":[]},{"section":"read-controllerrevision-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-controllerrevision-v1-apps-strong-","subsections":[{"section":"delete-collection-controllerrevision-v1-apps","subsections":[]},{"section":"delete-controllerrevision-v1-apps","subsections":[]},{"section":"replace-controllerrevision-v1-apps","subsections":[]},{"section":"patch-controllerrevision-v1-apps","subsections":[]},{"section":"create-controllerrevision-v1-apps","subsections":[]}]}]},{"section":"-strong-metadata-apis-strong-","subsections":[]},{"section":"volumeattachment-v1-storage-k8s-io","subsections":[{"section":"-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"replace-status-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"read-status-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"patch-status-volumeattachment-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1-storage-k8s-io","subsections":[]}]}]},{"section":"volume-v1-core","subsections":[]},{"section":"storageclass-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-storageclass-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"watch-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"list-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"read-storageclass-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-storageclass-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"delete-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"replace-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"patch-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"create-storageclass-v1-storage-k8s-io","subsections":[]}]}]},{"section":"persistentvolumeclaim-v1-core","subsections":[{"section":"-strong-status-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"replace-status-persistentvolumeclaim-v1-core","subsections":[]},{"section":"read-status-persistentvolumeclaim-v1-core","subsections":[]},{"section":"patch-status-persistentvolumeclaim-v1-core","subsections":[]}]},{"section":"-strong-read-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-persistentvolumeclaim-v1-core","subsections":[]},{"section":"watch-list-persistentvolumeclaim-v1-core","subsections":[]},{"section":"watch-persistentvolumeclaim-v1-core","subsections":[]},{"section":"list-all-namespaces-persistentvolumeclaim-v1-core","subsections":[]},{"section":"list-persistentvolumeclaim-v1-core","subsections":[]},{"section":"read-persistentvolumeclaim-v1-core","subsections":[]}]},{"section":"-strong-write-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"delete-collection-persistentvolumeclaim-v1-core","subsections":[]},{"section":"delete-persistentvolumeclaim-v1-core","subsections":[]},{"section":"replace-persistentvolumeclaim-v1-core","subsections":[]},{"section":"patch-persistentvolumeclaim-v1-core","subsections":[]},{"section":"create-persistentvolumeclaim-v1-core","subsections":[]}]}]},{"section":"secret-v1-core","subsections":[{"section":"-strong-read-operations-secret-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-secret-v1-core","subsections":[]},{"section":"watch-list-secret-v1-core","subsections":[]},{"section":"watch-secret-v1-core","subsections":[]},{"section":"list-all-namespaces-secret-v1-core","subsections":[]},{"section":"list-secret-v1-core","subsections":[]},{"section":"read-secret-v1-core","subsections":[]}]},{"section":"-strong-write-operations-secret-v1-core-strong-","subsections":[{"section":"delete-collection-secret-v1-core","subsections":[]},{"section":"delete-secret-v1-core","subsections":[]},{"section":"replace-secret-v1-core","subsections":[]},{"section":"patch-secret-v1-core","subsections":[]},{"section":"create-secret-v1-core","subsections":[]}]}]},{"section":"csinode-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csinode-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csinode-v1-storage-k8s-io","subsections":[]},{"section":"watch-csinode-v1-storage-k8s-io","subsections":[]},{"section":"list-csinode-v1-storage-k8s-io","subsections":[]},{"section":"read-csinode-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csinode-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csinode-v1-storage-k8s-io","subsections":[]},{"section":"delete-csinode-v1-storage-k8s-io","subsections":[]},{"section":"replace-csinode-v1-storage-k8s-io","subsections":[]},{"section":"patch-csinode-v1-storage-k8s-io","subsections":[]},{"section":"create-csinode-v1-storage-k8s-io","subsections":[]}]}]},{"section":"csidriver-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csidriver-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"watch-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"list-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"read-csidriver-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csidriver-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"delete-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"replace-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"patch-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"create-csidriver-v1-storage-k8s-io","subsections":[]}]}]},{"section":"configmap-v1-core","subsections":[{"section":"-strong-read-operations-configmap-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-configmap-v1-core","subsections":[]},{"section":"watch-list-configmap-v1-core","subsections":[]},{"section":"watch-configmap-v1-core","subsections":[]},{"section":"list-all-namespaces-configmap-v1-core","subsections":[]},{"section":"list-configmap-v1-core","subsections":[]},{"section":"read-configmap-v1-core","subsections":[]}]},{"section":"-strong-write-operations-configmap-v1-core-strong-","subsections":[{"section":"delete-collection-configmap-v1-core","subsections":[]},{"section":"delete-configmap-v1-core","subsections":[]},{"section":"replace-configmap-v1-core","subsections":[]},{"section":"patch-configmap-v1-core","subsections":[]},{"section":"create-configmap-v1-core","subsections":[]}]}]},{"section":"-strong-config-and-storage-apis-strong-","subsections":[]},{"section":"service-v1-core","subsections":[{"section":"-strong-proxy-operations-service-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-service-v1-core","subsections":[]},{"section":"replace-connect-proxy-service-v1-core","subsections":[]},{"section":"head-connect-proxy-path-service-v1-core","subsections":[]},{"section":"head-connect-proxy-service-v1-core","subsections":[]},{"section":"get-connect-proxy-path-service-v1-core","subsections":[]},{"section":"get-connect-proxy-service-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-service-v1-core","subsections":[]},{"section":"delete-connect-proxy-service-v1-core","subsections":[]},{"section":"create-connect-proxy-path-service-v1-core","subsections":[]},{"section":"create-connect-proxy-service-v1-core","subsections":[]}]},{"section":"-strong-status-operations-service-v1-core-strong-","subsections":[{"section":"replace-status-service-v1-core","subsections":[]},{"section":"read-status-service-v1-core","subsections":[]},{"section":"patch-status-service-v1-core","subsections":[]}]},{"section":"-strong-read-operations-service-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-service-v1-core","subsections":[]},{"section":"watch-list-service-v1-core","subsections":[]},{"section":"watch-service-v1-core","subsections":[]},{"section":"list-all-namespaces-service-v1-core","subsections":[]},{"section":"list-service-v1-core","subsections":[]},{"section":"read-service-v1-core","subsections":[]}]},{"section":"-strong-write-operations-service-v1-core-strong-","subsections":[{"section":"delete-service-v1-core","subsections":[]},{"section":"replace-service-v1-core","subsections":[]},{"section":"patch-service-v1-core","subsections":[]},{"section":"create-service-v1-core","subsections":[]}]}]},{"section":"ingressclass-v1beta1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-ingressclass-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"delete-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"replace-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"create-ingressclass-v1beta1-networking-k8s-io","subsections":[]}]}]},{"section":"ingress-v1beta1-networking-k8s-io","subsections":[{"section":"-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"replace-status-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-status-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-status-ingress-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-list-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-ingress-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"delete-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"replace-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"create-ingress-v1beta1-networking-k8s-io","subsections":[]}]}]},{"section":"endpointslice-v1beta1-discovery-k8s-io","subsections":[{"section":"-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"watch-list-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"watch-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"list-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"read-endpointslice-v1beta1-discovery-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","subsections":[{"section":"delete-collection-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"delete-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"replace-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"patch-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"create-endpointslice-v1beta1-discovery-k8s-io","subsections":[]}]}]},{"section":"endpoints-v1-core","subsections":[{"section":"-strong-read-operations-endpoints-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-endpoints-v1-core","subsections":[]},{"section":"watch-list-endpoints-v1-core","subsections":[]},{"section":"watch-endpoints-v1-core","subsections":[]},{"section":"list-all-namespaces-endpoints-v1-core","subsections":[]},{"section":"list-endpoints-v1-core","subsections":[]},{"section":"read-endpoints-v1-core","subsections":[]}]},{"section":"-strong-write-operations-endpoints-v1-core-strong-","subsections":[{"section":"delete-collection-endpoints-v1-core","subsections":[]},{"section":"delete-endpoints-v1-core","subsections":[]},{"section":"replace-endpoints-v1-core","subsections":[]},{"section":"patch-endpoints-v1-core","subsections":[]},{"section":"create-endpoints-v1-core","subsections":[]}]}]},{"section":"-strong-service-apis-strong-","subsections":[]},{"section":"statefulset-v1-apps","subsections":[{"section":"-strong-misc-operations-statefulset-v1-apps-strong-","subsections":[{"section":"patch-scale-statefulset-v1-apps","subsections":[]},{"section":"replace-scale-statefulset-v1-apps","subsections":[]},{"section":"read-scale-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-statefulset-v1-apps-strong-","subsections":[{"section":"replace-status-statefulset-v1-apps","subsections":[]},{"section":"read-status-statefulset-v1-apps","subsections":[]},{"section":"patch-status-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-statefulset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-statefulset-v1-apps","subsections":[]},{"section":"watch-list-statefulset-v1-apps","subsections":[]},{"section":"watch-statefulset-v1-apps","subsections":[]},{"section":"list-all-namespaces-statefulset-v1-apps","subsections":[]},{"section":"list-statefulset-v1-apps","subsections":[]},{"section":"read-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-statefulset-v1-apps-strong-","subsections":[{"section":"delete-collection-statefulset-v1-apps","subsections":[]},{"section":"delete-statefulset-v1-apps","subsections":[]},{"section":"replace-statefulset-v1-apps","subsections":[]},{"section":"patch-statefulset-v1-apps","subsections":[]},{"section":"create-statefulset-v1-apps","subsections":[]}]}]},{"section":"replicationcontroller-v1-core","subsections":[{"section":"-strong-misc-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"patch-scale-replicationcontroller-v1-core","subsections":[]},{"section":"replace-scale-replicationcontroller-v1-core","subsections":[]},{"section":"read-scale-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-status-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"replace-status-replicationcontroller-v1-core","subsections":[]},{"section":"read-status-replicationcontroller-v1-core","subsections":[]},{"section":"patch-status-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-read-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-replicationcontroller-v1-core","subsections":[]},{"section":"watch-list-replicationcontroller-v1-core","subsections":[]},{"section":"watch-replicationcontroller-v1-core","subsections":[]},{"section":"list-all-namespaces-replicationcontroller-v1-core","subsections":[]},{"section":"list-replicationcontroller-v1-core","subsections":[]},{"section":"read-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-write-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"delete-collection-replicationcontroller-v1-core","subsections":[]},{"section":"delete-replicationcontroller-v1-core","subsections":[]},{"section":"replace-replicationcontroller-v1-core","subsections":[]},{"section":"patch-replicationcontroller-v1-core","subsections":[]},{"section":"create-replicationcontroller-v1-core","subsections":[]}]}]},{"section":"replicaset-v1-apps","subsections":[{"section":"-strong-misc-operations-replicaset-v1-apps-strong-","subsections":[{"section":"patch-scale-replicaset-v1-apps","subsections":[]},{"section":"replace-scale-replicaset-v1-apps","subsections":[]},{"section":"read-scale-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-replicaset-v1-apps-strong-","subsections":[{"section":"replace-status-replicaset-v1-apps","subsections":[]},{"section":"read-status-replicaset-v1-apps","subsections":[]},{"section":"patch-status-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-replicaset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-replicaset-v1-apps","subsections":[]},{"section":"watch-list-replicaset-v1-apps","subsections":[]},{"section":"watch-replicaset-v1-apps","subsections":[]},{"section":"list-all-namespaces-replicaset-v1-apps","subsections":[]},{"section":"list-replicaset-v1-apps","subsections":[]},{"section":"read-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-replicaset-v1-apps-strong-","subsections":[{"section":"delete-collection-replicaset-v1-apps","subsections":[]},{"section":"delete-replicaset-v1-apps","subsections":[]},{"section":"replace-replicaset-v1-apps","subsections":[]},{"section":"patch-replicaset-v1-apps","subsections":[]},{"section":"create-replicaset-v1-apps","subsections":[]}]}]},{"section":"pod-v1-core","subsections":[{"section":"-strong-misc-operations-pod-v1-core-strong-","subsections":[{"section":"read-log-pod-v1-core","subsections":[]}]},{"section":"-strong-proxy-operations-pod-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"replace-connect-proxy-pod-v1-core","subsections":[]},{"section":"head-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"head-connect-proxy-pod-v1-core","subsections":[]},{"section":"get-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"get-connect-proxy-pod-v1-core","subsections":[]},{"section":"get-connect-portforward-pod-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"delete-connect-proxy-pod-v1-core","subsections":[]},{"section":"create-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"create-connect-proxy-pod-v1-core","subsections":[]},{"section":"create-connect-portforward-pod-v1-core","subsections":[]}]},{"section":"-strong-status-operations-pod-v1-core-strong-","subsections":[{"section":"replace-status-pod-v1-core","subsections":[]},{"section":"read-status-pod-v1-core","subsections":[]},{"section":"patch-status-pod-v1-core","subsections":[]}]},{"section":"-strong-read-operations-pod-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-pod-v1-core","subsections":[]},{"section":"watch-list-pod-v1-core","subsections":[]},{"section":"watch-pod-v1-core","subsections":[]},{"section":"list-all-namespaces-pod-v1-core","subsections":[]},{"section":"list-pod-v1-core","subsections":[]},{"section":"read-pod-v1-core","subsections":[]}]},{"section":"-strong-write-operations-pod-v1-core-strong-","subsections":[{"section":"delete-collection-pod-v1-core","subsections":[]},{"section":"delete-pod-v1-core","subsections":[]},{"section":"replace-pod-v1-core","subsections":[]},{"section":"patch-pod-v1-core","subsections":[]},{"section":"create-eviction-pod-v1-core","subsections":[]},{"section":"create-pod-v1-core","subsections":[]}]}]},{"section":"job-v1-batch","subsections":[{"section":"-strong-status-operations-job-v1-batch-strong-","subsections":[{"section":"replace-status-job-v1-batch","subsections":[]},{"section":"read-status-job-v1-batch","subsections":[]},{"section":"patch-status-job-v1-batch","subsections":[]}]},{"section":"-strong-read-operations-job-v1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-job-v1-batch","subsections":[]},{"section":"watch-list-job-v1-batch","subsections":[]},{"section":"watch-job-v1-batch","subsections":[]},{"section":"list-all-namespaces-job-v1-batch","subsections":[]},{"section":"list-job-v1-batch","subsections":[]},{"section":"read-job-v1-batch","subsections":[]}]},{"section":"-strong-write-operations-job-v1-batch-strong-","subsections":[{"section":"delete-collection-job-v1-batch","subsections":[]},{"section":"delete-job-v1-batch","subsections":[]},{"section":"replace-job-v1-batch","subsections":[]},{"section":"patch-job-v1-batch","subsections":[]},{"section":"create-job-v1-batch","subsections":[]}]}]},{"section":"deployment-v1-apps","subsections":[{"section":"-strong-misc-operations-deployment-v1-apps-strong-","subsections":[{"section":"patch-scale-deployment-v1-apps","subsections":[]},{"section":"replace-scale-deployment-v1-apps","subsections":[]},{"section":"read-scale-deployment-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-deployment-v1-apps-strong-","subsections":[{"section":"replace-status-deployment-v1-apps","subsections":[]},{"section":"read-status-deployment-v1-apps","subsections":[]},{"section":"patch-status-deployment-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-deployment-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-deployment-v1-apps","subsections":[]},{"section":"watch-list-deployment-v1-apps","subsections":[]},{"section":"watch-deployment-v1-apps","subsections":[]},{"section":"list-all-namespaces-deployment-v1-apps","subsections":[]},{"section":"list-deployment-v1-apps","subsections":[]},{"section":"read-deployment-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-deployment-v1-apps-strong-","subsections":[{"section":"delete-collection-deployment-v1-apps","subsections":[]},{"section":"delete-deployment-v1-apps","subsections":[]},{"section":"replace-deployment-v1-apps","subsections":[]},{"section":"patch-deployment-v1-apps","subsections":[]},{"section":"create-deployment-v1-apps","subsections":[]}]}]},{"section":"daemonset-v1-apps","subsections":[{"section":"-strong-status-operations-daemonset-v1-apps-strong-","subsections":[{"section":"replace-status-daemonset-v1-apps","subsections":[]},{"section":"read-status-daemonset-v1-apps","subsections":[]},{"section":"patch-status-daemonset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-daemonset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-daemonset-v1-apps","subsections":[]},{"section":"watch-list-daemonset-v1-apps","subsections":[]},{"section":"watch-daemonset-v1-apps","subsections":[]},{"section":"list-all-namespaces-daemonset-v1-apps","subsections":[]},{"section":"list-daemonset-v1-apps","subsections":[]},{"section":"read-daemonset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-daemonset-v1-apps-strong-","subsections":[{"section":"delete-collection-daemonset-v1-apps","subsections":[]},{"section":"delete-daemonset-v1-apps","subsections":[]},{"section":"replace-daemonset-v1-apps","subsections":[]},{"section":"patch-daemonset-v1-apps","subsections":[]},{"section":"create-daemonset-v1-apps","subsections":[]}]}]},{"section":"cronjob-v1beta1-batch","subsections":[{"section":"-strong-status-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"replace-status-cronjob-v1beta1-batch","subsections":[]},{"section":"read-status-cronjob-v1beta1-batch","subsections":[]},{"section":"patch-status-cronjob-v1beta1-batch","subsections":[]}]},{"section":"-strong-read-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-cronjob-v1beta1-batch","subsections":[]},{"section":"watch-list-cronjob-v1beta1-batch","subsections":[]},{"section":"watch-cronjob-v1beta1-batch","subsections":[]},{"section":"list-all-namespaces-cronjob-v1beta1-batch","subsections":[]},{"section":"list-cronjob-v1beta1-batch","subsections":[]},{"section":"read-cronjob-v1beta1-batch","subsections":[]}]},{"section":"-strong-write-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"delete-collection-cronjob-v1beta1-batch","subsections":[]},{"section":"delete-cronjob-v1beta1-batch","subsections":[]},{"section":"replace-cronjob-v1beta1-batch","subsections":[]},{"section":"patch-cronjob-v1beta1-batch","subsections":[]},{"section":"create-cronjob-v1beta1-batch","subsections":[]}]}]},{"section":"container-v1-core","subsections":[]},{"section":"-strong-workloads-apis-strong-","subsections":[]},{"section":"-strong-api-overview-strong-","subsections":[]}],"flatToc":["webhookclientconfig-v1alpha1-auditregistration-k8s-io","webhookclientconfig-v1beta1-apiextensions-k8s-io","webhookclientconfig-v1beta1-admissionregistration-k8s-io","webhookclientconfig-v1-apiextensions-k8s-io","volumenoderesources-v1beta1-storage-k8s-io","volumeerror-v1alpha1-storage-k8s-io","volumeerror-v1beta1-storage-k8s-io","volumeattachmentsource-v1alpha1-storage-k8s-io","volumeattachmentsource-v1beta1-storage-k8s-io","watch-list-volumeattachment-v1alpha1-storage-k8s-io","watch-volumeattachment-v1alpha1-storage-k8s-io","list-volumeattachment-v1alpha1-storage-k8s-io","read-volumeattachment-v1alpha1-storage-k8s-io","-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1alpha1-storage-k8s-io","delete-volumeattachment-v1alpha1-storage-k8s-io","replace-volumeattachment-v1alpha1-storage-k8s-io","patch-volumeattachment-v1alpha1-storage-k8s-io","create-volumeattachment-v1alpha1-storage-k8s-io","-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","volumeattachment-v1alpha1-storage-k8s-io","watch-list-volumeattachment-v1beta1-storage-k8s-io","watch-volumeattachment-v1beta1-storage-k8s-io","list-volumeattachment-v1beta1-storage-k8s-io","read-volumeattachment-v1beta1-storage-k8s-io","-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1beta1-storage-k8s-io","delete-volumeattachment-v1beta1-storage-k8s-io","replace-volumeattachment-v1beta1-storage-k8s-io","patch-volumeattachment-v1beta1-storage-k8s-io","create-volumeattachment-v1beta1-storage-k8s-io","-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","volumeattachment-v1beta1-storage-k8s-io","watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","validatingwebhook-v1beta1-admissionregistration-k8s-io","userinfo-v1beta1-authentication-k8s-io","create-tokenreview-v1beta1-authentication-k8s-io","-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-","tokenreview-v1beta1-authentication-k8s-io","subjectrulesreviewstatus-v1beta1-authorization-k8s-io","create-subjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-","subjectaccessreview-v1beta1-authorization-k8s-io","subject-v1alpha1-rbac-authorization-k8s-io","subject-v1beta1-rbac-authorization-k8s-io","subject-v1-rbac-authorization-k8s-io","watch-list-storageclass-v1beta1-storage-k8s-io","watch-storageclass-v1beta1-storage-k8s-io","list-storageclass-v1beta1-storage-k8s-io","read-storageclass-v1beta1-storage-k8s-io","-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-","delete-collection-storageclass-v1beta1-storage-k8s-io","delete-storageclass-v1beta1-storage-k8s-io","replace-storageclass-v1beta1-storage-k8s-io","patch-storageclass-v1beta1-storage-k8s-io","create-storageclass-v1beta1-storage-k8s-io","-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-","storageclass-v1beta1-storage-k8s-io","servicereference-v1alpha1-auditregistration-k8s-io","servicereference-v1beta1-apiregistration-k8s-io","servicereference-v1beta1-apiextensions-k8s-io","servicereference-v1beta1-admissionregistration-k8s-io","servicereference-v1-apiregistration-k8s-io","servicereference-v1-apiextensions-k8s-io","create-selfsubjectrulesreview-v1beta1-authorization-k8s-io","-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-","selfsubjectrulesreview-v1beta1-authorization-k8s-io","create-selfsubjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","selfsubjectaccessreview-v1beta1-authorization-k8s-io","scheduling-v1alpha1-node-k8s-io","watch-list-runtimeclass-v1alpha1-node-k8s-io","watch-runtimeclass-v1alpha1-node-k8s-io","list-runtimeclass-v1alpha1-node-k8s-io","read-runtimeclass-v1alpha1-node-k8s-io","-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","delete-collection-runtimeclass-v1alpha1-node-k8s-io","delete-runtimeclass-v1alpha1-node-k8s-io","replace-runtimeclass-v1alpha1-node-k8s-io","patch-runtimeclass-v1alpha1-node-k8s-io","create-runtimeclass-v1alpha1-node-k8s-io","-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","runtimeclass-v1alpha1-node-k8s-io","rulewithoperations-v1beta1-admissionregistration-k8s-io","roleref-v1alpha1-rbac-authorization-k8s-io","roleref-v1beta1-rbac-authorization-k8s-io","watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-rolebinding-v1alpha1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","list-rolebinding-v1alpha1-rbac-authorization-k8s-io","read-rolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io","delete-rolebinding-v1alpha1-rbac-authorization-k8s-io","replace-rolebinding-v1alpha1-rbac-authorization-k8s-io","patch-rolebinding-v1alpha1-rbac-authorization-k8s-io","create-rolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io","watch-rolebinding-v1beta1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","list-rolebinding-v1beta1-rbac-authorization-k8s-io","read-rolebinding-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io","delete-rolebinding-v1beta1-rbac-authorization-k8s-io","replace-rolebinding-v1beta1-rbac-authorization-k8s-io","patch-rolebinding-v1beta1-rbac-authorization-k8s-io","create-rolebinding-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","rolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","watch-list-role-v1alpha1-rbac-authorization-k8s-io","watch-role-v1alpha1-rbac-authorization-k8s-io","list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","list-role-v1alpha1-rbac-authorization-k8s-io","read-role-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1alpha1-rbac-authorization-k8s-io","delete-role-v1alpha1-rbac-authorization-k8s-io","replace-role-v1alpha1-rbac-authorization-k8s-io","patch-role-v1alpha1-rbac-authorization-k8s-io","create-role-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","role-v1alpha1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","watch-list-role-v1beta1-rbac-authorization-k8s-io","watch-role-v1beta1-rbac-authorization-k8s-io","list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","list-role-v1beta1-rbac-authorization-k8s-io","read-role-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1beta1-rbac-authorization-k8s-io","delete-role-v1beta1-rbac-authorization-k8s-io","replace-role-v1beta1-rbac-authorization-k8s-io","patch-role-v1beta1-rbac-authorization-k8s-io","create-role-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","role-v1beta1-rbac-authorization-k8s-io","resourcerule-v1beta1-authorization-k8s-io","resourcemetricstatus-v2beta1-autoscaling","resourcemetricsource-v2beta1-autoscaling","resourceattributes-v1beta1-authorization-k8s-io","watch-list-priorityclass-v1alpha1-scheduling-k8s-io","watch-priorityclass-v1alpha1-scheduling-k8s-io","list-priorityclass-v1alpha1-scheduling-k8s-io","read-priorityclass-v1alpha1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1alpha1-scheduling-k8s-io","delete-priorityclass-v1alpha1-scheduling-k8s-io","replace-priorityclass-v1alpha1-scheduling-k8s-io","patch-priorityclass-v1alpha1-scheduling-k8s-io","create-priorityclass-v1alpha1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","priorityclass-v1alpha1-scheduling-k8s-io","watch-list-priorityclass-v1beta1-scheduling-k8s-io","watch-priorityclass-v1beta1-scheduling-k8s-io","list-priorityclass-v1beta1-scheduling-k8s-io","read-priorityclass-v1beta1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1beta1-scheduling-k8s-io","delete-priorityclass-v1beta1-scheduling-k8s-io","replace-priorityclass-v1beta1-scheduling-k8s-io","patch-priorityclass-v1beta1-scheduling-k8s-io","create-priorityclass-v1beta1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","priorityclass-v1beta1-scheduling-k8s-io","policyrule-v1alpha1-rbac-authorization-k8s-io","policyrule-v1beta1-rbac-authorization-k8s-io","podsmetricstatus-v2beta1-autoscaling","podsmetricsource-v2beta1-autoscaling","overhead-v1alpha1-node-k8s-io","objectmetricstatus-v2beta1-autoscaling","objectmetricsource-v2beta1-autoscaling","nonresourcerule-v1beta1-authorization-k8s-io","nonresourceattributes-v1beta1-authorization-k8s-io","watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","mutatingwebhook-v1beta1-admissionregistration-k8s-io","metricstatus-v2beta1-autoscaling","metricspec-v2beta1-autoscaling","create-localsubjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","localsubjectaccessreview-v1beta1-authorization-k8s-io","watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io","watch-list-lease-v1beta1-coordination-k8s-io","watch-lease-v1beta1-coordination-k8s-io","list-all-namespaces-lease-v1beta1-coordination-k8s-io","list-lease-v1beta1-coordination-k8s-io","read-lease-v1beta1-coordination-k8s-io","-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-","delete-collection-lease-v1beta1-coordination-k8s-io","delete-lease-v1beta1-coordination-k8s-io","replace-lease-v1beta1-coordination-k8s-io","patch-lease-v1beta1-coordination-k8s-io","create-lease-v1beta1-coordination-k8s-io","-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-","lease-v1beta1-coordination-k8s-io","jobtemplatespec-v2alpha1-batch","jsonschemapropsorbool-v1beta1-apiextensions-k8s-io","jsonschemapropsorarray-v1beta1-apiextensions-k8s-io","jsonschemaprops-v1beta1-apiextensions-k8s-io","json-v1beta1-apiextensions-k8s-io","ingresstls-v1beta1-extensions","ingressrule-v1beta1-extensions","ingressbackend-v1beta1-extensions","replace-status-ingress-v1beta1-extensions","read-status-ingress-v1beta1-extensions","patch-status-ingress-v1beta1-extensions","-strong-status-operations-ingress-v1beta1-extensions-strong-","watch-list-all-namespaces-ingress-v1beta1-extensions","watch-list-ingress-v1beta1-extensions","watch-ingress-v1beta1-extensions","list-all-namespaces-ingress-v1beta1-extensions","list-ingress-v1beta1-extensions","read-ingress-v1beta1-extensions","-strong-read-operations-ingress-v1beta1-extensions-strong-","delete-collection-ingress-v1beta1-extensions","delete-ingress-v1beta1-extensions","replace-ingress-v1beta1-extensions","patch-ingress-v1beta1-extensions","create-ingress-v1beta1-extensions","-strong-write-operations-ingress-v1beta1-extensions-strong-","ingress-v1beta1-extensions","horizontalpodautoscalercondition-v2beta1-autoscaling","replace-status-horizontalpodautoscaler-v2beta1-autoscaling","read-status-horizontalpodautoscaler-v2beta1-autoscaling","patch-status-horizontalpodautoscaler-v2beta1-autoscaling","-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","watch-list-horizontalpodautoscaler-v2beta1-autoscaling","watch-horizontalpodautoscaler-v2beta1-autoscaling","list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","list-horizontalpodautoscaler-v2beta1-autoscaling","read-horizontalpodautoscaler-v2beta1-autoscaling","-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v2beta1-autoscaling","delete-horizontalpodautoscaler-v2beta1-autoscaling","replace-horizontalpodautoscaler-v2beta1-autoscaling","patch-horizontalpodautoscaler-v2beta1-autoscaling","create-horizontalpodautoscaler-v2beta1-autoscaling","-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","horizontalpodautoscaler-v2beta1-autoscaling","replace-status-horizontalpodautoscaler-v2beta2-autoscaling","read-status-horizontalpodautoscaler-v2beta2-autoscaling","patch-status-horizontalpodautoscaler-v2beta2-autoscaling","-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","watch-list-horizontalpodautoscaler-v2beta2-autoscaling","watch-horizontalpodautoscaler-v2beta2-autoscaling","list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","list-horizontalpodautoscaler-v2beta2-autoscaling","read-horizontalpodautoscaler-v2beta2-autoscaling","-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v2beta2-autoscaling","delete-horizontalpodautoscaler-v2beta2-autoscaling","replace-horizontalpodautoscaler-v2beta2-autoscaling","patch-horizontalpodautoscaler-v2beta2-autoscaling","create-horizontalpodautoscaler-v2beta2-autoscaling","-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","horizontalpodautoscaler-v2beta2-autoscaling","httpingressrulevalue-v1beta1-extensions","httpingresspath-v1beta1-extensions","externalmetricstatus-v2beta1-autoscaling","externalmetricsource-v2beta1-autoscaling","externaldocumentation-v1beta1-apiextensions-k8s-io","eventseries-v1beta1-events-k8s-io","watch-list-all-namespaces-event-v1beta1-events-k8s-io","watch-list-event-v1beta1-events-k8s-io","watch-event-v1beta1-events-k8s-io","list-all-namespaces-event-v1beta1-events-k8s-io","list-event-v1beta1-events-k8s-io","read-event-v1beta1-events-k8s-io","-strong-read-operations-event-v1beta1-events-k8s-io-strong-","delete-collection-event-v1beta1-events-k8s-io","delete-event-v1beta1-events-k8s-io","replace-event-v1beta1-events-k8s-io","patch-event-v1beta1-events-k8s-io","create-event-v1beta1-events-k8s-io","-strong-write-operations-event-v1beta1-events-k8s-io-strong-","event-v1beta1-events-k8s-io","endpointport-v1beta1-discovery-k8s-io","customresourcevalidation-v1beta1-apiextensions-k8s-io","customresourcesubresources-v1beta1-apiextensions-k8s-io","customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io","customresourcesubresourcescale-v1beta1-apiextensions-k8s-io","customresourcedefinitionversion-v1beta1-apiextensions-k8s-io","customresourcedefinitionnames-v1beta1-apiextensions-k8s-io","customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io","replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io","watch-customresourcedefinition-v1beta1-apiextensions-k8s-io","list-customresourcedefinition-v1beta1-apiextensions-k8s-io","read-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io","delete-customresourcedefinition-v1beta1-apiextensions-k8s-io","replace-customresourcedefinition-v1beta1-apiextensions-k8s-io","patch-customresourcedefinition-v1beta1-apiextensions-k8s-io","create-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","customresourcedefinition-v1beta1-apiextensions-k8s-io","customresourceconversion-v1beta1-apiextensions-k8s-io","customresourcecolumndefinition-v1beta1-apiextensions-k8s-io","crossversionobjectreference-v2beta1-autoscaling","crossversionobjectreference-v2beta2-autoscaling","replace-status-cronjob-v2alpha1-batch","read-status-cronjob-v2alpha1-batch","patch-status-cronjob-v2alpha1-batch","-strong-status-operations-cronjob-v2alpha1-batch-strong-","watch-list-all-namespaces-cronjob-v2alpha1-batch","watch-list-cronjob-v2alpha1-batch","watch-cronjob-v2alpha1-batch","list-all-namespaces-cronjob-v2alpha1-batch","list-cronjob-v2alpha1-batch","read-cronjob-v2alpha1-batch","-strong-read-operations-cronjob-v2alpha1-batch-strong-","delete-collection-cronjob-v2alpha1-batch","delete-cronjob-v2alpha1-batch","replace-cronjob-v2alpha1-batch","patch-cronjob-v2alpha1-batch","create-cronjob-v2alpha1-batch","-strong-write-operations-cronjob-v2alpha1-batch-strong-","cronjob-v2alpha1-batch","watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io","watch-clusterrole-v1alpha1-rbac-authorization-k8s-io","list-clusterrole-v1alpha1-rbac-authorization-k8s-io","read-clusterrole-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io","delete-clusterrole-v1alpha1-rbac-authorization-k8s-io","replace-clusterrole-v1alpha1-rbac-authorization-k8s-io","patch-clusterrole-v1alpha1-rbac-authorization-k8s-io","create-clusterrole-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","clusterrole-v1alpha1-rbac-authorization-k8s-io","watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io","watch-clusterrole-v1beta1-rbac-authorization-k8s-io","list-clusterrole-v1beta1-rbac-authorization-k8s-io","read-clusterrole-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io","delete-clusterrole-v1beta1-rbac-authorization-k8s-io","replace-clusterrole-v1beta1-rbac-authorization-k8s-io","patch-clusterrole-v1beta1-rbac-authorization-k8s-io","create-clusterrole-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","clusterrole-v1beta1-rbac-authorization-k8s-io","csinodedriver-v1beta1-storage-k8s-io","watch-list-csinode-v1beta1-storage-k8s-io","watch-csinode-v1beta1-storage-k8s-io","list-csinode-v1beta1-storage-k8s-io","read-csinode-v1beta1-storage-k8s-io","-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-","delete-collection-csinode-v1beta1-storage-k8s-io","delete-csinode-v1beta1-storage-k8s-io","replace-csinode-v1beta1-storage-k8s-io","patch-csinode-v1beta1-storage-k8s-io","create-csinode-v1beta1-storage-k8s-io","-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-","csinode-v1beta1-storage-k8s-io","watch-list-csidriver-v1beta1-storage-k8s-io","watch-csidriver-v1beta1-storage-k8s-io","list-csidriver-v1beta1-storage-k8s-io","read-csidriver-v1beta1-storage-k8s-io","-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-","delete-collection-csidriver-v1beta1-storage-k8s-io","delete-csidriver-v1beta1-storage-k8s-io","replace-csidriver-v1beta1-storage-k8s-io","patch-csidriver-v1beta1-storage-k8s-io","create-csidriver-v1beta1-storage-k8s-io","-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-","csidriver-v1beta1-storage-k8s-io","aggregationrule-v1alpha1-rbac-authorization-k8s-io","aggregationrule-v1beta1-rbac-authorization-k8s-io","apiservicecondition-v1beta1-apiregistration-k8s-io","replace-status-apiservice-v1beta1-apiregistration-k8s-io","read-status-apiservice-v1beta1-apiregistration-k8s-io","patch-status-apiservice-v1beta1-apiregistration-k8s-io","-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","watch-list-apiservice-v1beta1-apiregistration-k8s-io","watch-apiservice-v1beta1-apiregistration-k8s-io","list-apiservice-v1beta1-apiregistration-k8s-io","read-apiservice-v1beta1-apiregistration-k8s-io","-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","delete-collection-apiservice-v1beta1-apiregistration-k8s-io","delete-apiservice-v1beta1-apiregistration-k8s-io","replace-apiservice-v1beta1-apiregistration-k8s-io","patch-apiservice-v1beta1-apiregistration-k8s-io","create-apiservice-v1beta1-apiregistration-k8s-io","-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","apiservice-v1beta1-apiregistration-k8s-io","-strong-old-api-versions-strong-","windowssecuritycontextoptions-v1-core","weightedpodaffinityterm-v1-core","webhookthrottleconfig-v1alpha1-auditregistration-k8s-io","webhookconversion-v1-apiextensions-k8s-io","webhookclientconfig-v1-admissionregistration-k8s-io","webhook-v1alpha1-auditregistration-k8s-io","watchevent-v1-meta","vspherevirtualdiskvolumesource-v1-core","volumeprojection-v1-core","volumenoderesources-v1-storage-k8s-io","volumenodeaffinity-v1-core","volumemount-v1-core","volumeerror-v1-storage-k8s-io","volumedevice-v1-core","volumeattachmentsource-v1-storage-k8s-io","validatingwebhook-v1-admissionregistration-k8s-io","usersubject-v1alpha1-flowcontrol-apiserver-k8s-io","userinfo-v1-authentication-k8s-io","typedlocalobjectreference-v1-core","topologyspreadconstraint-v1-core","topologyselectorterm-v1-core","topologyselectorlabelrequirement-v1-core","toleration-v1-core","time-v1-meta","taint-v1-core","tcpsocketaction-v1-core","sysctl-v1-core","supplementalgroupsstrategyoptions-v1beta1-policy","subjectrulesreviewstatus-v1-authorization-k8s-io","subject-v1alpha1-flowcontrol-apiserver-k8s-io","storageosvolumesource-v1-core","storageospersistentvolumesource-v1-core","statusdetails-v1-meta","statuscause-v1-meta","status-v1-meta","statefulsetupdatestrategy-v1-apps","statefulsetcondition-v1-apps","sessionaffinityconfig-v1-core","servicereference-v1-admissionregistration-k8s-io","serviceport-v1-core","serviceaccounttokenprojection-v1-core","serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io","serveraddressbyclientcidr-v1-meta","securitycontext-v1-core","secretvolumesource-v1-core","secretreference-v1-core","secretprojection-v1-core","secretkeyselector-v1-core","secretenvsource-v1-core","scopedresourceselectorrequirement-v1-core","scopeselector-v1-core","scheduling-v1beta1-node-k8s-io","scaleiovolumesource-v1-core","scaleiopersistentvolumesource-v1-core","scale-v1-autoscaling","selinuxstrategyoptions-v1beta1-policy","selinuxoptions-v1-core","runtimeclassstrategyoptions-v1beta1-policy","runasuserstrategyoptions-v1beta1-policy","runasgroupstrategyoptions-v1beta1-policy","rulewithoperations-v1-admissionregistration-k8s-io","rollingupdatestatefulsetstrategy-v1-apps","roleref-v1-rbac-authorization-k8s-io","resourcerule-v1-authorization-k8s-io","resourcerequirements-v1-core","resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","resourcemetricstatus-v2beta2-autoscaling","resourcemetricsource-v2beta2-autoscaling","resourcefieldselector-v1-core","resourceattributes-v1-authorization-k8s-io","replicationcontrollercondition-v1-core","replicasetcondition-v1-apps","rbdvolumesource-v1-core","rbdpersistentvolumesource-v1-core","quobytevolumesource-v1-core","queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","quantity-resource-core","projectedvolumesource-v1-core","probe-v1-core","prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io","prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io","preferredschedulingterm-v1-core","preconditions-v1-meta","portworxvolumesource-v1-core","policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io","policyrule-v1-rbac-authorization-k8s-io","policy-v1alpha1-auditregistration-k8s-io","podsmetricstatus-v2beta2-autoscaling","podsmetricsource-v2beta2-autoscaling","podsecuritycontext-v1-core","podreadinessgate-v1-core","podip-v1-core","poddnsconfigoption-v1-core","poddnsconfig-v1-core","podcondition-v1-core","podantiaffinity-v1-core","podaffinityterm-v1-core","podaffinity-v1-core","photonpersistentdiskvolumesource-v1-core","persistentvolumeclaimvolumesource-v1-core","persistentvolumeclaimcondition-v1-core","patch-v1-meta","ownerreference-v1-meta","overhead-v1beta1-node-k8s-io","objectreference-v1-core","objectmetricstatus-v2beta2-autoscaling","objectmetricsource-v2beta2-autoscaling","objectmeta-v1-meta","objectfieldselector-v1-core","nonresourcerule-v1-authorization-k8s-io","nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","nonresourceattributes-v1-authorization-k8s-io","nodesysteminfo-v1-core","nodeselectorterm-v1-core","nodeselectorrequirement-v1-core","nodeselector-v1-core","nodedaemonendpoints-v1-core","nodeconfigstatus-v1-core","nodeconfigsource-v1-core","nodecondition-v1-core","nodeaffinity-v1-core","nodeaddress-v1-core","networkpolicyport-v1-networking-k8s-io","networkpolicypeer-v1-networking-k8s-io","networkpolicyingressrule-v1-networking-k8s-io","networkpolicyegressrule-v1-networking-k8s-io","namespacecondition-v1-core","nfsvolumesource-v1-core","mutatingwebhook-v1-admissionregistration-k8s-io","microtime-v1-meta","metricvaluestatus-v2beta2-autoscaling","metrictarget-v2beta2-autoscaling","metricstatus-v2beta2-autoscaling","metricspec-v2beta2-autoscaling","metricidentifier-v2beta2-autoscaling","managedfieldsentry-v1-meta","localvolumesource-v1-core","localobjectreference-v1-core","loadbalancerstatus-v1-core","loadbalanceringress-v1-core","listmeta-v1-meta","limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io","limitrangeitem-v1-core","lifecycle-v1-core","labelselectorrequirement-v1-meta","labelselector-v1-meta","keytopath-v1-core","jobtemplatespec-v1beta1-batch","jobcondition-v1-batch","jsonschemapropsorbool-v1-apiextensions-k8s-io","jsonschemapropsorarray-v1-apiextensions-k8s-io","jsonschemaprops-v1-apiextensions-k8s-io","json-v1-apiextensions-k8s-io","ingresstls-v1beta1-networking-k8s-io","ingressrule-v1beta1-networking-k8s-io","ingressbackend-v1beta1-networking-k8s-io","iscsivolumesource-v1-core","iscsipersistentvolumesource-v1-core","ipblock-v1-networking-k8s-io","idrange-v1beta1-policy","hostportrange-v1beta1-policy","hostpathvolumesource-v1-core","hostalias-v1-core","horizontalpodautoscalercondition-v2beta2-autoscaling","horizontalpodautoscalerbehavior-v2beta2-autoscaling","handler-v1-core","httpingressrulevalue-v1beta1-networking-k8s-io","httpingresspath-v1beta1-networking-k8s-io","httpheader-v1-core","httpgetaction-v1-core","hpascalingrules-v2beta2-autoscaling","hpascalingpolicy-v2beta2-autoscaling","groupversionfordiscovery-v1-meta","groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io","glusterfsvolumesource-v1-core","glusterfspersistentvolumesource-v1-core","gitrepovolumesource-v1-core","gcepersistentdiskvolumesource-v1-core","flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io","flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io","flockervolumesource-v1-core","flexvolumesource-v1-core","flexpersistentvolumesource-v1-core","fieldsv1-v1-meta","fsgroupstrategyoptions-v1beta1-policy","fcvolumesource-v1-core","externalmetricstatus-v2beta2-autoscaling","externalmetricsource-v2beta2-autoscaling","externaldocumentation-v1-apiextensions-k8s-io","execaction-v1-core","eviction-v1beta1-policy","eventsource-v1-core","eventseries-v1-core","ephemeralcontainer-v1-core","envvarsource-v1-core","envvar-v1-core","envfromsource-v1-core","endpointsubset-v1-core","endpointport-v1-core","endpointconditions-v1beta1-discovery-k8s-io","endpointaddress-v1-core","endpoint-v1beta1-discovery-k8s-io","emptydirvolumesource-v1-core","downwardapivolumesource-v1-core","downwardapivolumefile-v1-core","downwardapiprojection-v1-core","deploymentcondition-v1-apps","deleteoptions-v1-meta","daemonsetupdatestrategy-v1-apps","daemonsetcondition-v1-apps","daemonendpoint-v1-core","customresourcevalidation-v1-apiextensions-k8s-io","customresourcesubresources-v1-apiextensions-k8s-io","customresourcesubresourcestatus-v1-apiextensions-k8s-io","customresourcesubresourcescale-v1-apiextensions-k8s-io","customresourcedefinitionversion-v1-apiextensions-k8s-io","customresourcedefinitionnames-v1-apiextensions-k8s-io","customresourcedefinitioncondition-v1-apiextensions-k8s-io","customresourceconversion-v1-apiextensions-k8s-io","customresourcecolumndefinition-v1-apiextensions-k8s-io","crossversionobjectreference-v1-autoscaling","containerstatewaiting-v1-core","containerstateterminated-v1-core","containerstaterunning-v1-core","containerstate-v1-core","containerport-v1-core","containerimage-v1-core","configmapvolumesource-v1-core","configmapprojection-v1-core","configmapnodeconfigsource-v1-core","configmapkeyselector-v1-core","configmapenvsource-v1-core","componentcondition-v1-core","clientipconfig-v1-core","cindervolumesource-v1-core","cinderpersistentvolumesource-v1-core","certificatesigningrequestcondition-v1beta1-certificates-k8s-io","cephfsvolumesource-v1-core","cephfspersistentvolumesource-v1-core","capabilities-v1-core","csivolumesource-v1-core","csipersistentvolumesource-v1-core","csinodedriver-v1-storage-k8s-io","boundobjectreference-v1-authentication-k8s-io","azurefilevolumesource-v1-core","azurefilepersistentvolumesource-v1-core","azurediskvolumesource-v1-core","attachedvolume-v1-core","allowedhostpath-v1beta1-policy","allowedflexvolume-v1beta1-policy","allowedcsidriver-v1beta1-policy","aggregationrule-v1-rbac-authorization-k8s-io","affinity-v1-core","awselasticblockstorevolumesource-v1-core","apiversions-v1-meta","apiservicecondition-v1-apiregistration-k8s-io","apiresource-v1-meta","apigroup-v1-meta","-strong-definitions-strong-","watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io","watch-list-networkpolicy-v1-networking-k8s-io","watch-networkpolicy-v1-networking-k8s-io","list-all-namespaces-networkpolicy-v1-networking-k8s-io","list-networkpolicy-v1-networking-k8s-io","read-networkpolicy-v1-networking-k8s-io","-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-","delete-collection-networkpolicy-v1-networking-k8s-io","delete-networkpolicy-v1-networking-k8s-io","replace-networkpolicy-v1-networking-k8s-io","patch-networkpolicy-v1-networking-k8s-io","create-networkpolicy-v1-networking-k8s-io","-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-","networkpolicy-v1-networking-k8s-io","create-tokenreview-v1-authentication-k8s-io","-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-","tokenreview-v1-authentication-k8s-io","tokenrequest-v1-authentication-k8s-io","create-subjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-","subjectaccessreview-v1-authorization-k8s-io","watch-list-all-namespaces-serviceaccount-v1-core","watch-list-serviceaccount-v1-core","watch-serviceaccount-v1-core","list-all-namespaces-serviceaccount-v1-core","list-serviceaccount-v1-core","read-serviceaccount-v1-core","-strong-read-operations-serviceaccount-v1-core-strong-","delete-collection-serviceaccount-v1-core","delete-serviceaccount-v1-core","replace-serviceaccount-v1-core","patch-serviceaccount-v1-core","create-serviceaccount-v1-core","-strong-write-operations-serviceaccount-v1-core-strong-","serviceaccount-v1-core","create-selfsubjectrulesreview-v1-authorization-k8s-io","-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-","selfsubjectrulesreview-v1-authorization-k8s-io","create-selfsubjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-","selfsubjectaccessreview-v1-authorization-k8s-io","watch-list-runtimeclass-v1beta1-node-k8s-io","watch-runtimeclass-v1beta1-node-k8s-io","list-runtimeclass-v1beta1-node-k8s-io","read-runtimeclass-v1beta1-node-k8s-io","-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-","delete-collection-runtimeclass-v1beta1-node-k8s-io","delete-runtimeclass-v1beta1-node-k8s-io","replace-runtimeclass-v1beta1-node-k8s-io","patch-runtimeclass-v1beta1-node-k8s-io","create-runtimeclass-v1beta1-node-k8s-io","-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-","runtimeclass-v1beta1-node-k8s-io","watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","watch-list-rolebinding-v1-rbac-authorization-k8s-io","watch-rolebinding-v1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","list-rolebinding-v1-rbac-authorization-k8s-io","read-rolebinding-v1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1-rbac-authorization-k8s-io","delete-rolebinding-v1-rbac-authorization-k8s-io","replace-rolebinding-v1-rbac-authorization-k8s-io","patch-rolebinding-v1-rbac-authorization-k8s-io","create-rolebinding-v1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","rolebinding-v1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io","watch-list-role-v1-rbac-authorization-k8s-io","watch-role-v1-rbac-authorization-k8s-io","list-all-namespaces-role-v1-rbac-authorization-k8s-io","list-role-v1-rbac-authorization-k8s-io","read-role-v1-rbac-authorization-k8s-io","-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1-rbac-authorization-k8s-io","delete-role-v1-rbac-authorization-k8s-io","replace-role-v1-rbac-authorization-k8s-io","patch-role-v1-rbac-authorization-k8s-io","create-role-v1-rbac-authorization-k8s-io","-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-","role-v1-rbac-authorization-k8s-io","replace-status-resourcequota-v1-core","read-status-resourcequota-v1-core","patch-status-resourcequota-v1-core","-strong-status-operations-resourcequota-v1-core-strong-","watch-list-all-namespaces-resourcequota-v1-core","watch-list-resourcequota-v1-core","watch-resourcequota-v1-core","list-all-namespaces-resourcequota-v1-core","list-resourcequota-v1-core","read-resourcequota-v1-core","-strong-read-operations-resourcequota-v1-core-strong-","delete-collection-resourcequota-v1-core","delete-resourcequota-v1-core","replace-resourcequota-v1-core","patch-resourcequota-v1-core","create-resourcequota-v1-core","-strong-write-operations-resourcequota-v1-core-strong-","resourcequota-v1-core","replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","replace-status-persistentvolume-v1-core","read-status-persistentvolume-v1-core","patch-status-persistentvolume-v1-core","-strong-status-operations-persistentvolume-v1-core-strong-","watch-list-persistentvolume-v1-core","watch-persistentvolume-v1-core","list-persistentvolume-v1-core","read-persistentvolume-v1-core","-strong-read-operations-persistentvolume-v1-core-strong-","delete-collection-persistentvolume-v1-core","delete-persistentvolume-v1-core","replace-persistentvolume-v1-core","patch-persistentvolume-v1-core","create-persistentvolume-v1-core","-strong-write-operations-persistentvolume-v1-core-strong-","persistentvolume-v1-core","replace-connect-proxy-path-node-v1-core","replace-connect-proxy-node-v1-core","head-connect-proxy-path-node-v1-core","head-connect-proxy-node-v1-core","get-connect-proxy-path-node-v1-core","get-connect-proxy-node-v1-core","delete-connect-proxy-path-node-v1-core","delete-connect-proxy-node-v1-core","create-connect-proxy-path-node-v1-core","create-connect-proxy-node-v1-core","-strong-proxy-operations-node-v1-core-strong-","replace-status-node-v1-core","read-status-node-v1-core","patch-status-node-v1-core","-strong-status-operations-node-v1-core-strong-","watch-list-node-v1-core","watch-node-v1-core","list-node-v1-core","read-node-v1-core","-strong-read-operations-node-v1-core-strong-","delete-collection-node-v1-core","delete-node-v1-core","replace-node-v1-core","patch-node-v1-core","create-node-v1-core","-strong-write-operations-node-v1-core-strong-","node-v1-core","replace-status-namespace-v1-core","read-status-namespace-v1-core","patch-status-namespace-v1-core","-strong-status-operations-namespace-v1-core-strong-","watch-list-namespace-v1-core","watch-namespace-v1-core","list-namespace-v1-core","read-namespace-v1-core","-strong-read-operations-namespace-v1-core-strong-","delete-namespace-v1-core","replace-namespace-v1-core","patch-namespace-v1-core","create-namespace-v1-core","-strong-write-operations-namespace-v1-core-strong-","namespace-v1-core","create-localsubjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-","localsubjectaccessreview-v1-authorization-k8s-io","watch-list-all-namespaces-lease-v1-coordination-k8s-io","watch-list-lease-v1-coordination-k8s-io","watch-lease-v1-coordination-k8s-io","list-all-namespaces-lease-v1-coordination-k8s-io","list-lease-v1-coordination-k8s-io","read-lease-v1-coordination-k8s-io","-strong-read-operations-lease-v1-coordination-k8s-io-strong-","delete-collection-lease-v1-coordination-k8s-io","delete-lease-v1-coordination-k8s-io","replace-lease-v1-coordination-k8s-io","patch-lease-v1-coordination-k8s-io","create-lease-v1-coordination-k8s-io","-strong-write-operations-lease-v1-coordination-k8s-io-strong-","lease-v1-coordination-k8s-io","replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","list-componentstatus-v1-core","read-componentstatus-v1-core","-strong-read-operations-componentstatus-v1-core-strong-","componentstatus-v1-core","watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1-rbac-authorization-k8s-io","list-clusterrolebinding-v1-rbac-authorization-k8s-io","read-clusterrolebinding-v1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1-rbac-authorization-k8s-io","create-clusterrolebinding-v1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1-rbac-authorization-k8s-io","watch-list-clusterrole-v1-rbac-authorization-k8s-io","watch-clusterrole-v1-rbac-authorization-k8s-io","list-clusterrole-v1-rbac-authorization-k8s-io","read-clusterrole-v1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1-rbac-authorization-k8s-io","delete-clusterrole-v1-rbac-authorization-k8s-io","replace-clusterrole-v1-rbac-authorization-k8s-io","patch-clusterrole-v1-rbac-authorization-k8s-io","create-clusterrole-v1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","clusterrole-v1-rbac-authorization-k8s-io","replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io","read-status-certificatesigningrequest-v1beta1-certificates-k8s-io","patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io","watch-certificatesigningrequest-v1beta1-certificates-k8s-io","list-certificatesigningrequest-v1beta1-certificates-k8s-io","read-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io","delete-certificatesigningrequest-v1beta1-certificates-k8s-io","replace-certificatesigningrequest-v1beta1-certificates-k8s-io","patch-certificatesigningrequest-v1beta1-certificates-k8s-io","create-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","certificatesigningrequest-v1beta1-certificates-k8s-io","create-binding-v1-core","-strong-write-operations-binding-v1-core-strong-","binding-v1-core","watch-list-auditsink-v1alpha1-auditregistration-k8s-io","watch-auditsink-v1alpha1-auditregistration-k8s-io","list-auditsink-v1alpha1-auditregistration-k8s-io","read-auditsink-v1alpha1-auditregistration-k8s-io","-strong-read-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-","delete-collection-auditsink-v1alpha1-auditregistration-k8s-io","delete-auditsink-v1alpha1-auditregistration-k8s-io","replace-auditsink-v1alpha1-auditregistration-k8s-io","patch-auditsink-v1alpha1-auditregistration-k8s-io","create-auditsink-v1alpha1-auditregistration-k8s-io","-strong-write-operations-auditsink-v1alpha1-auditregistration-k8s-io-strong-","auditsink-v1alpha1-auditregistration-k8s-io","replace-status-apiservice-v1-apiregistration-k8s-io","read-status-apiservice-v1-apiregistration-k8s-io","patch-status-apiservice-v1-apiregistration-k8s-io","-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-","watch-list-apiservice-v1-apiregistration-k8s-io","watch-apiservice-v1-apiregistration-k8s-io","list-apiservice-v1-apiregistration-k8s-io","read-apiservice-v1-apiregistration-k8s-io","-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-","delete-collection-apiservice-v1-apiregistration-k8s-io","delete-apiservice-v1-apiregistration-k8s-io","replace-apiservice-v1-apiregistration-k8s-io","patch-apiservice-v1-apiregistration-k8s-io","create-apiservice-v1-apiregistration-k8s-io","-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-","apiservice-v1-apiregistration-k8s-io","-strong-cluster-apis-strong-","watch-list-podsecuritypolicy-v1beta1-policy","watch-podsecuritypolicy-v1beta1-policy","list-podsecuritypolicy-v1beta1-policy","read-podsecuritypolicy-v1beta1-policy","-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-","delete-collection-podsecuritypolicy-v1beta1-policy","delete-podsecuritypolicy-v1beta1-policy","replace-podsecuritypolicy-v1beta1-policy","patch-podsecuritypolicy-v1beta1-policy","create-podsecuritypolicy-v1beta1-policy","-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-","podsecuritypolicy-v1beta1-policy","watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","watch-list-podpreset-v1alpha1-settings-k8s-io","watch-podpreset-v1alpha1-settings-k8s-io","list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","list-podpreset-v1alpha1-settings-k8s-io","read-podpreset-v1alpha1-settings-k8s-io","-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-","delete-collection-podpreset-v1alpha1-settings-k8s-io","delete-podpreset-v1alpha1-settings-k8s-io","replace-podpreset-v1alpha1-settings-k8s-io","patch-podpreset-v1alpha1-settings-k8s-io","create-podpreset-v1alpha1-settings-k8s-io","-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-","podpreset-v1alpha1-settings-k8s-io","watch-list-priorityclass-v1-scheduling-k8s-io","watch-priorityclass-v1-scheduling-k8s-io","list-priorityclass-v1-scheduling-k8s-io","read-priorityclass-v1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1-scheduling-k8s-io","delete-priorityclass-v1-scheduling-k8s-io","replace-priorityclass-v1-scheduling-k8s-io","patch-priorityclass-v1-scheduling-k8s-io","create-priorityclass-v1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-","priorityclass-v1-scheduling-k8s-io","replace-status-poddisruptionbudget-v1beta1-policy","read-status-poddisruptionbudget-v1beta1-policy","patch-status-poddisruptionbudget-v1beta1-policy","-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-","watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy","watch-list-poddisruptionbudget-v1beta1-policy","watch-poddisruptionbudget-v1beta1-policy","list-all-namespaces-poddisruptionbudget-v1beta1-policy","list-poddisruptionbudget-v1beta1-policy","read-poddisruptionbudget-v1beta1-policy","-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-","delete-collection-poddisruptionbudget-v1beta1-policy","delete-poddisruptionbudget-v1beta1-policy","replace-poddisruptionbudget-v1beta1-policy","patch-poddisruptionbudget-v1beta1-policy","create-poddisruptionbudget-v1beta1-policy","-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-","poddisruptionbudget-v1beta1-policy","watch-list-all-namespaces-podtemplate-v1-core","watch-list-podtemplate-v1-core","watch-podtemplate-v1-core","list-all-namespaces-podtemplate-v1-core","list-podtemplate-v1-core","read-podtemplate-v1-core","-strong-read-operations-podtemplate-v1-core-strong-","delete-collection-podtemplate-v1-core","delete-podtemplate-v1-core","replace-podtemplate-v1-core","patch-podtemplate-v1-core","create-podtemplate-v1-core","-strong-write-operations-podtemplate-v1-core-strong-","podtemplate-v1-core","watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","validatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-status-horizontalpodautoscaler-v1-autoscaling","read-status-horizontalpodautoscaler-v1-autoscaling","patch-status-horizontalpodautoscaler-v1-autoscaling","-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","watch-list-horizontalpodautoscaler-v1-autoscaling","watch-horizontalpodautoscaler-v1-autoscaling","list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","list-horizontalpodautoscaler-v1-autoscaling","read-horizontalpodautoscaler-v1-autoscaling","-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v1-autoscaling","delete-horizontalpodautoscaler-v1-autoscaling","replace-horizontalpodautoscaler-v1-autoscaling","patch-horizontalpodautoscaler-v1-autoscaling","create-horizontalpodautoscaler-v1-autoscaling","-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-","horizontalpodautoscaler-v1-autoscaling","watch-list-all-namespaces-limitrange-v1-core","watch-list-limitrange-v1-core","watch-limitrange-v1-core","list-all-namespaces-limitrange-v1-core","list-limitrange-v1-core","read-limitrange-v1-core","-strong-read-operations-limitrange-v1-core-strong-","delete-collection-limitrange-v1-core","delete-limitrange-v1-core","replace-limitrange-v1-core","patch-limitrange-v1-core","create-limitrange-v1-core","-strong-write-operations-limitrange-v1-core-strong-","limitrange-v1-core","watch-list-all-namespaces-event-v1-core","watch-list-event-v1-core","watch-event-v1-core","list-all-namespaces-event-v1-core","list-event-v1-core","read-event-v1-core","-strong-read-operations-event-v1-core-strong-","delete-collection-event-v1-core","delete-event-v1-core","replace-event-v1-core","patch-event-v1-core","create-event-v1-core","-strong-write-operations-event-v1-core-strong-","event-v1-core","replace-status-customresourcedefinition-v1-apiextensions-k8s-io","read-status-customresourcedefinition-v1-apiextensions-k8s-io","patch-status-customresourcedefinition-v1-apiextensions-k8s-io","-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","watch-list-customresourcedefinition-v1-apiextensions-k8s-io","watch-customresourcedefinition-v1-apiextensions-k8s-io","list-customresourcedefinition-v1-apiextensions-k8s-io","read-customresourcedefinition-v1-apiextensions-k8s-io","-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","delete-collection-customresourcedefinition-v1-apiextensions-k8s-io","delete-customresourcedefinition-v1-apiextensions-k8s-io","replace-customresourcedefinition-v1-apiextensions-k8s-io","patch-customresourcedefinition-v1-apiextensions-k8s-io","create-customresourcedefinition-v1-apiextensions-k8s-io","-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","customresourcedefinition-v1-apiextensions-k8s-io","watch-list-all-namespaces-controllerrevision-v1-apps","watch-list-controllerrevision-v1-apps","watch-controllerrevision-v1-apps","list-all-namespaces-controllerrevision-v1-apps","list-controllerrevision-v1-apps","read-controllerrevision-v1-apps","-strong-read-operations-controllerrevision-v1-apps-strong-","delete-collection-controllerrevision-v1-apps","delete-controllerrevision-v1-apps","replace-controllerrevision-v1-apps","patch-controllerrevision-v1-apps","create-controllerrevision-v1-apps","-strong-write-operations-controllerrevision-v1-apps-strong-","controllerrevision-v1-apps","-strong-metadata-apis-strong-","replace-status-volumeattachment-v1-storage-k8s-io","read-status-volumeattachment-v1-storage-k8s-io","patch-status-volumeattachment-v1-storage-k8s-io","-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-","watch-list-volumeattachment-v1-storage-k8s-io","watch-volumeattachment-v1-storage-k8s-io","list-volumeattachment-v1-storage-k8s-io","read-volumeattachment-v1-storage-k8s-io","-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1-storage-k8s-io","delete-volumeattachment-v1-storage-k8s-io","replace-volumeattachment-v1-storage-k8s-io","patch-volumeattachment-v1-storage-k8s-io","create-volumeattachment-v1-storage-k8s-io","-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-","volumeattachment-v1-storage-k8s-io","volume-v1-core","watch-list-storageclass-v1-storage-k8s-io","watch-storageclass-v1-storage-k8s-io","list-storageclass-v1-storage-k8s-io","read-storageclass-v1-storage-k8s-io","-strong-read-operations-storageclass-v1-storage-k8s-io-strong-","delete-collection-storageclass-v1-storage-k8s-io","delete-storageclass-v1-storage-k8s-io","replace-storageclass-v1-storage-k8s-io","patch-storageclass-v1-storage-k8s-io","create-storageclass-v1-storage-k8s-io","-strong-write-operations-storageclass-v1-storage-k8s-io-strong-","storageclass-v1-storage-k8s-io","replace-status-persistentvolumeclaim-v1-core","read-status-persistentvolumeclaim-v1-core","patch-status-persistentvolumeclaim-v1-core","-strong-status-operations-persistentvolumeclaim-v1-core-strong-","watch-list-all-namespaces-persistentvolumeclaim-v1-core","watch-list-persistentvolumeclaim-v1-core","watch-persistentvolumeclaim-v1-core","list-all-namespaces-persistentvolumeclaim-v1-core","list-persistentvolumeclaim-v1-core","read-persistentvolumeclaim-v1-core","-strong-read-operations-persistentvolumeclaim-v1-core-strong-","delete-collection-persistentvolumeclaim-v1-core","delete-persistentvolumeclaim-v1-core","replace-persistentvolumeclaim-v1-core","patch-persistentvolumeclaim-v1-core","create-persistentvolumeclaim-v1-core","-strong-write-operations-persistentvolumeclaim-v1-core-strong-","persistentvolumeclaim-v1-core","watch-list-all-namespaces-secret-v1-core","watch-list-secret-v1-core","watch-secret-v1-core","list-all-namespaces-secret-v1-core","list-secret-v1-core","read-secret-v1-core","-strong-read-operations-secret-v1-core-strong-","delete-collection-secret-v1-core","delete-secret-v1-core","replace-secret-v1-core","patch-secret-v1-core","create-secret-v1-core","-strong-write-operations-secret-v1-core-strong-","secret-v1-core","watch-list-csinode-v1-storage-k8s-io","watch-csinode-v1-storage-k8s-io","list-csinode-v1-storage-k8s-io","read-csinode-v1-storage-k8s-io","-strong-read-operations-csinode-v1-storage-k8s-io-strong-","delete-collection-csinode-v1-storage-k8s-io","delete-csinode-v1-storage-k8s-io","replace-csinode-v1-storage-k8s-io","patch-csinode-v1-storage-k8s-io","create-csinode-v1-storage-k8s-io","-strong-write-operations-csinode-v1-storage-k8s-io-strong-","csinode-v1-storage-k8s-io","watch-list-csidriver-v1-storage-k8s-io","watch-csidriver-v1-storage-k8s-io","list-csidriver-v1-storage-k8s-io","read-csidriver-v1-storage-k8s-io","-strong-read-operations-csidriver-v1-storage-k8s-io-strong-","delete-collection-csidriver-v1-storage-k8s-io","delete-csidriver-v1-storage-k8s-io","replace-csidriver-v1-storage-k8s-io","patch-csidriver-v1-storage-k8s-io","create-csidriver-v1-storage-k8s-io","-strong-write-operations-csidriver-v1-storage-k8s-io-strong-","csidriver-v1-storage-k8s-io","watch-list-all-namespaces-configmap-v1-core","watch-list-configmap-v1-core","watch-configmap-v1-core","list-all-namespaces-configmap-v1-core","list-configmap-v1-core","read-configmap-v1-core","-strong-read-operations-configmap-v1-core-strong-","delete-collection-configmap-v1-core","delete-configmap-v1-core","replace-configmap-v1-core","patch-configmap-v1-core","create-configmap-v1-core","-strong-write-operations-configmap-v1-core-strong-","configmap-v1-core","-strong-config-and-storage-apis-strong-","replace-connect-proxy-path-service-v1-core","replace-connect-proxy-service-v1-core","head-connect-proxy-path-service-v1-core","head-connect-proxy-service-v1-core","get-connect-proxy-path-service-v1-core","get-connect-proxy-service-v1-core","delete-connect-proxy-path-service-v1-core","delete-connect-proxy-service-v1-core","create-connect-proxy-path-service-v1-core","create-connect-proxy-service-v1-core","-strong-proxy-operations-service-v1-core-strong-","replace-status-service-v1-core","read-status-service-v1-core","patch-status-service-v1-core","-strong-status-operations-service-v1-core-strong-","watch-list-all-namespaces-service-v1-core","watch-list-service-v1-core","watch-service-v1-core","list-all-namespaces-service-v1-core","list-service-v1-core","read-service-v1-core","-strong-read-operations-service-v1-core-strong-","delete-service-v1-core","replace-service-v1-core","patch-service-v1-core","create-service-v1-core","-strong-write-operations-service-v1-core-strong-","service-v1-core","watch-list-ingressclass-v1beta1-networking-k8s-io","watch-ingressclass-v1beta1-networking-k8s-io","list-ingressclass-v1beta1-networking-k8s-io","read-ingressclass-v1beta1-networking-k8s-io","-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-","delete-collection-ingressclass-v1beta1-networking-k8s-io","delete-ingressclass-v1beta1-networking-k8s-io","replace-ingressclass-v1beta1-networking-k8s-io","patch-ingressclass-v1beta1-networking-k8s-io","create-ingressclass-v1beta1-networking-k8s-io","-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-","ingressclass-v1beta1-networking-k8s-io","replace-status-ingress-v1beta1-networking-k8s-io","read-status-ingress-v1beta1-networking-k8s-io","patch-status-ingress-v1beta1-networking-k8s-io","-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-","watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io","watch-list-ingress-v1beta1-networking-k8s-io","watch-ingress-v1beta1-networking-k8s-io","list-all-namespaces-ingress-v1beta1-networking-k8s-io","list-ingress-v1beta1-networking-k8s-io","read-ingress-v1beta1-networking-k8s-io","-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-","delete-collection-ingress-v1beta1-networking-k8s-io","delete-ingress-v1beta1-networking-k8s-io","replace-ingress-v1beta1-networking-k8s-io","patch-ingress-v1beta1-networking-k8s-io","create-ingress-v1beta1-networking-k8s-io","-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-","ingress-v1beta1-networking-k8s-io","watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","watch-list-endpointslice-v1beta1-discovery-k8s-io","watch-endpointslice-v1beta1-discovery-k8s-io","list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","list-endpointslice-v1beta1-discovery-k8s-io","read-endpointslice-v1beta1-discovery-k8s-io","-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","delete-collection-endpointslice-v1beta1-discovery-k8s-io","delete-endpointslice-v1beta1-discovery-k8s-io","replace-endpointslice-v1beta1-discovery-k8s-io","patch-endpointslice-v1beta1-discovery-k8s-io","create-endpointslice-v1beta1-discovery-k8s-io","-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","endpointslice-v1beta1-discovery-k8s-io","watch-list-all-namespaces-endpoints-v1-core","watch-list-endpoints-v1-core","watch-endpoints-v1-core","list-all-namespaces-endpoints-v1-core","list-endpoints-v1-core","read-endpoints-v1-core","-strong-read-operations-endpoints-v1-core-strong-","delete-collection-endpoints-v1-core","delete-endpoints-v1-core","replace-endpoints-v1-core","patch-endpoints-v1-core","create-endpoints-v1-core","-strong-write-operations-endpoints-v1-core-strong-","endpoints-v1-core","-strong-service-apis-strong-","patch-scale-statefulset-v1-apps","replace-scale-statefulset-v1-apps","read-scale-statefulset-v1-apps","-strong-misc-operations-statefulset-v1-apps-strong-","replace-status-statefulset-v1-apps","read-status-statefulset-v1-apps","patch-status-statefulset-v1-apps","-strong-status-operations-statefulset-v1-apps-strong-","watch-list-all-namespaces-statefulset-v1-apps","watch-list-statefulset-v1-apps","watch-statefulset-v1-apps","list-all-namespaces-statefulset-v1-apps","list-statefulset-v1-apps","read-statefulset-v1-apps","-strong-read-operations-statefulset-v1-apps-strong-","delete-collection-statefulset-v1-apps","delete-statefulset-v1-apps","replace-statefulset-v1-apps","patch-statefulset-v1-apps","create-statefulset-v1-apps","-strong-write-operations-statefulset-v1-apps-strong-","statefulset-v1-apps","patch-scale-replicationcontroller-v1-core","replace-scale-replicationcontroller-v1-core","read-scale-replicationcontroller-v1-core","-strong-misc-operations-replicationcontroller-v1-core-strong-","replace-status-replicationcontroller-v1-core","read-status-replicationcontroller-v1-core","patch-status-replicationcontroller-v1-core","-strong-status-operations-replicationcontroller-v1-core-strong-","watch-list-all-namespaces-replicationcontroller-v1-core","watch-list-replicationcontroller-v1-core","watch-replicationcontroller-v1-core","list-all-namespaces-replicationcontroller-v1-core","list-replicationcontroller-v1-core","read-replicationcontroller-v1-core","-strong-read-operations-replicationcontroller-v1-core-strong-","delete-collection-replicationcontroller-v1-core","delete-replicationcontroller-v1-core","replace-replicationcontroller-v1-core","patch-replicationcontroller-v1-core","create-replicationcontroller-v1-core","-strong-write-operations-replicationcontroller-v1-core-strong-","replicationcontroller-v1-core","patch-scale-replicaset-v1-apps","replace-scale-replicaset-v1-apps","read-scale-replicaset-v1-apps","-strong-misc-operations-replicaset-v1-apps-strong-","replace-status-replicaset-v1-apps","read-status-replicaset-v1-apps","patch-status-replicaset-v1-apps","-strong-status-operations-replicaset-v1-apps-strong-","watch-list-all-namespaces-replicaset-v1-apps","watch-list-replicaset-v1-apps","watch-replicaset-v1-apps","list-all-namespaces-replicaset-v1-apps","list-replicaset-v1-apps","read-replicaset-v1-apps","-strong-read-operations-replicaset-v1-apps-strong-","delete-collection-replicaset-v1-apps","delete-replicaset-v1-apps","replace-replicaset-v1-apps","patch-replicaset-v1-apps","create-replicaset-v1-apps","-strong-write-operations-replicaset-v1-apps-strong-","replicaset-v1-apps","read-log-pod-v1-core","-strong-misc-operations-pod-v1-core-strong-","replace-connect-proxy-path-pod-v1-core","replace-connect-proxy-pod-v1-core","head-connect-proxy-path-pod-v1-core","head-connect-proxy-pod-v1-core","get-connect-proxy-path-pod-v1-core","get-connect-proxy-pod-v1-core","get-connect-portforward-pod-v1-core","delete-connect-proxy-path-pod-v1-core","delete-connect-proxy-pod-v1-core","create-connect-proxy-path-pod-v1-core","create-connect-proxy-pod-v1-core","create-connect-portforward-pod-v1-core","-strong-proxy-operations-pod-v1-core-strong-","replace-status-pod-v1-core","read-status-pod-v1-core","patch-status-pod-v1-core","-strong-status-operations-pod-v1-core-strong-","watch-list-all-namespaces-pod-v1-core","watch-list-pod-v1-core","watch-pod-v1-core","list-all-namespaces-pod-v1-core","list-pod-v1-core","read-pod-v1-core","-strong-read-operations-pod-v1-core-strong-","delete-collection-pod-v1-core","delete-pod-v1-core","replace-pod-v1-core","patch-pod-v1-core","create-eviction-pod-v1-core","create-pod-v1-core","-strong-write-operations-pod-v1-core-strong-","pod-v1-core","replace-status-job-v1-batch","read-status-job-v1-batch","patch-status-job-v1-batch","-strong-status-operations-job-v1-batch-strong-","watch-list-all-namespaces-job-v1-batch","watch-list-job-v1-batch","watch-job-v1-batch","list-all-namespaces-job-v1-batch","list-job-v1-batch","read-job-v1-batch","-strong-read-operations-job-v1-batch-strong-","delete-collection-job-v1-batch","delete-job-v1-batch","replace-job-v1-batch","patch-job-v1-batch","create-job-v1-batch","-strong-write-operations-job-v1-batch-strong-","job-v1-batch","patch-scale-deployment-v1-apps","replace-scale-deployment-v1-apps","read-scale-deployment-v1-apps","-strong-misc-operations-deployment-v1-apps-strong-","replace-status-deployment-v1-apps","read-status-deployment-v1-apps","patch-status-deployment-v1-apps","-strong-status-operations-deployment-v1-apps-strong-","watch-list-all-namespaces-deployment-v1-apps","watch-list-deployment-v1-apps","watch-deployment-v1-apps","list-all-namespaces-deployment-v1-apps","list-deployment-v1-apps","read-deployment-v1-apps","-strong-read-operations-deployment-v1-apps-strong-","delete-collection-deployment-v1-apps","delete-deployment-v1-apps","replace-deployment-v1-apps","patch-deployment-v1-apps","create-deployment-v1-apps","-strong-write-operations-deployment-v1-apps-strong-","deployment-v1-apps","replace-status-daemonset-v1-apps","read-status-daemonset-v1-apps","patch-status-daemonset-v1-apps","-strong-status-operations-daemonset-v1-apps-strong-","watch-list-all-namespaces-daemonset-v1-apps","watch-list-daemonset-v1-apps","watch-daemonset-v1-apps","list-all-namespaces-daemonset-v1-apps","list-daemonset-v1-apps","read-daemonset-v1-apps","-strong-read-operations-daemonset-v1-apps-strong-","delete-collection-daemonset-v1-apps","delete-daemonset-v1-apps","replace-daemonset-v1-apps","patch-daemonset-v1-apps","create-daemonset-v1-apps","-strong-write-operations-daemonset-v1-apps-strong-","daemonset-v1-apps","replace-status-cronjob-v1beta1-batch","read-status-cronjob-v1beta1-batch","patch-status-cronjob-v1beta1-batch","-strong-status-operations-cronjob-v1beta1-batch-strong-","watch-list-all-namespaces-cronjob-v1beta1-batch","watch-list-cronjob-v1beta1-batch","watch-cronjob-v1beta1-batch","list-all-namespaces-cronjob-v1beta1-batch","list-cronjob-v1beta1-batch","read-cronjob-v1beta1-batch","-strong-read-operations-cronjob-v1beta1-batch-strong-","delete-collection-cronjob-v1beta1-batch","delete-cronjob-v1beta1-batch","replace-cronjob-v1beta1-batch","patch-cronjob-v1beta1-batch","create-cronjob-v1beta1-batch","-strong-write-operations-cronjob-v1beta1-batch-strong-","cronjob-v1beta1-batch","container-v1-core","-strong-workloads-apis-strong-","-strong-api-overview-strong-"]};})();
\ No newline at end of file
diff --git a/static/docs/reference/generated/kubernetes-api/v1.19/index.html b/static/docs/reference/generated/kubernetes-api/v1.19/index.html
index d346aa4250..1f88835146 100644
--- a/static/docs/reference/generated/kubernetes-api/v1.19/index.html
+++ b/static/docs/reference/generated/kubernetes-api/v1.19/index.html
@@ -15,6 +15,9 @@
 <UL>
  <LI class="nav-level-1 strong-nav"><A href="#-strong-api-overview-strong-" class="nav-item"><STRONG>Overview</STRONG></A></LI>
 </UL>
+<UL>
+ <LI class="nav-level-1 strong-nav"><A href="#-strong-api-groups-strong-" class="nav-item"><STRONG>API Groups</STRONG></A></LI>
+</UL>
 <UL>
  <LI class="nav-level-1 strong-nav"><A href="#-strong-workloads-apis-strong-" class="nav-item"><STRONG>WORKLOADS APIS</STRONG></A></LI>
 </UL>
@@ -3486,7 +3489,7 @@
  <a href="https://github.com/kubernetes/kubernetes">Copyright 2016-2020 The Kubernetes Authors.</a>
   </DIV>
   <DIV class="col-md-6 text-right">
-    <DIV>Generated at: 2020-08-13 16:44:39 (EDT)</DIV>
+    <DIV>Generated at: 2020-10-19 15:00:27 (CST)</DIV>
     <DIV>API Version: <a href="https://github.com/kubernetes/kubernetes/blob/release-1.19/api/openapi-spec/swagger.json">v1.19.0</a></DIV>
   </DIV>
 </DIV><H1 id="-strong-api-overview-strong-"><STRONG>API OVERVIEW</STRONG></H1>
@@ -3577,6 +3580,34 @@ notes on specific resource objects for details.</P>
 	<LI><B>Read / Write Status</B>: Read or Update the Status for a resource object.  The Status can only changed through these update operations.</LI>
 </UL>
 <HR />
+<H1 id="-strong-api-groups-strong-"><STRONG>API Groups</STRONG></H1>
+<P>The API Groups and their versions are summarized in the following table.</P><TABLE class="col-md-8">
+<THEAD><TR><TH>Group</TH><TH>Version</TH></TR></THEAD>
+<TBODY>
+<TR><TD><CODE>admissionregistration.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>apiextensions.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>apiregistration.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>apps</CODE></TD><TD><CODE>v1</CODE></TD></TR>
+<TR><TD><CODE>authentication.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>authorization.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>autoscaling</CODE></TD><TD><CODE>v1, v2beta2, v2beta1</CODE></TD></TR>
+<TR><TD><CODE>batch</CODE></TD><TD><CODE>v1, v1beta1, v2alpha1</CODE></TD></TR>
+<TR><TD><CODE>certificates.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>coordination.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>core</CODE></TD><TD><CODE>v1</CODE></TD></TR>
+<TR><TD><CODE>discovery.k8s.io</CODE></TD><TD><CODE>v1beta1</CODE></TD></TR>
+<TR><TD><CODE>events.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>extensions</CODE></TD><TD><CODE>v1beta1</CODE></TD></TR>
+<TR><TD><CODE>flowcontrol.apiserver.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD></TR>
+<TR><TD><CODE>networking.k8s.io</CODE></TD><TD><CODE>v1, v1beta1</CODE></TD></TR>
+<TR><TD><CODE>node.k8s.io</CODE></TD><TD><CODE>v1beta1, v1alpha1</CODE></TD></TR>
+<TR><TD><CODE>policy</CODE></TD><TD><CODE>v1beta1</CODE></TD></TR>
+<TR><TD><CODE>rbac.authorization.k8s.io</CODE></TD><TD><CODE>v1, v1beta1, v1alpha1</CODE></TD></TR>
+<TR><TD><CODE>scheduling.k8s.io</CODE></TD><TD><CODE>v1, v1beta1, v1alpha1</CODE></TD></TR>
+<TR><TD><CODE>settings.k8s.io</CODE></TD><TD><CODE>v1alpha1</CODE></TD></TR>
+<TR><TD><CODE>storage.k8s.io</CODE></TD><TD><CODE>v1, v1beta1, v1alpha1</CODE></TD></TR>
+</TBODY>
+</TABLE>
 <H1 id="-strong-workloads-apis-strong-"><STRONG>WORKLOADS</STRONG></H1>
 
 <P>Workloads resources are responsible for managing and running your containers on the cluster. <A href="#container-v1-core">Containers</A> are created
diff --git a/static/docs/reference/generated/kubernetes-api/v1.19/js/navData.js b/static/docs/reference/generated/kubernetes-api/v1.19/js/navData.js
index 4cb71c6075..50416e0793 100644
--- a/static/docs/reference/generated/kubernetes-api/v1.19/js/navData.js
+++ b/static/docs/reference/generated/kubernetes-api/v1.19/js/navData.js
@@ -1 +1 @@
-(function(){navData={"toc":[{"section":"webhookclientconfig-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1-apiextensions-k8s-io","subsections":[]},{"section":"volumenoderesources-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeerror-v1alpha1-storage-k8s-io","subsections":[]},{"section":"volumeerror-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeattachmentsource-v1alpha1-storage-k8s-io","subsections":[]},{"section":"volumeattachmentsource-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeattachment-v1alpha1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]}]}]},{"section":"volumeattachment-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"validatingwebhook-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"userinfo-v1beta1-authentication-k8s-io","subsections":[]},{"section":"tokenreview-v1beta1-authentication-k8s-io","subsections":[{"section":"-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-","subsections":[{"section":"create-tokenreview-v1beta1-authentication-k8s-io","subsections":[]}]}]},{"section":"subjectrulesreviewstatus-v1beta1-authorization-k8s-io","subsections":[]},{"section":"subjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-subjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"subject-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"subject-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"subject-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"storageclass-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-storageclass-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-storageclass-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"servicereference-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"servicereference-v1-apiregistration-k8s-io","subsections":[]},{"section":"servicereference-v1-apiextensions-k8s-io","subsections":[]},{"section":"selfsubjectrulesreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectrulesreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"selfsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"scheduling-v1alpha1-node-k8s-io","subsections":[]},{"section":"runtimeclass-v1alpha1-node-k8s-io","subsections":[{"section":"-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","subsections":[{"section":"watch-list-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"watch-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"list-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"read-runtimeclass-v1alpha1-node-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","subsections":[{"section":"delete-collection-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"delete-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"replace-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"patch-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"create-runtimeclass-v1alpha1-node-k8s-io","subsections":[]}]}]},{"section":"rulewithoperations-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"roleref-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"roleref-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"resourcerule-v1beta1-authorization-k8s-io","subsections":[]},{"section":"resourcemetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"resourcemetricsource-v2beta1-autoscaling","subsections":[]},{"section":"resourceattributes-v1beta1-authorization-k8s-io","subsections":[]},{"section":"priorityclass-v1alpha1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]}]}]},{"section":"priorityclass-v1beta1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]}]}]},{"section":"policyrule-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"policyrule-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"podsmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"podsmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"overhead-v1alpha1-node-k8s-io","subsections":[]},{"section":"objectmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"objectmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"nonresourcerule-v1beta1-authorization-k8s-io","subsections":[]},{"section":"nonresourceattributes-v1beta1-authorization-k8s-io","subsections":[]},{"section":"mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"mutatingwebhook-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"metricstatus-v2beta1-autoscaling","subsections":[]},{"section":"metricspec-v2beta1-autoscaling","subsections":[]},{"section":"localsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-localsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"lease-v1beta1-coordination-k8s-io","subsections":[{"section":"-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"watch-list-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"watch-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"list-all-namespaces-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"list-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"read-lease-v1beta1-coordination-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-","subsections":[{"section":"delete-collection-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"delete-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"replace-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"patch-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"create-lease-v1beta1-coordination-k8s-io","subsections":[]}]}]},{"section":"jobtemplatespec-v2alpha1-batch","subsections":[]},{"section":"jsonschemapropsorbool-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemapropsorarray-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemaprops-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"json-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"ingresstls-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingresstls-v1beta1-extensions","subsections":[]},{"section":"ingressrule-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingressrule-v1beta1-extensions","subsections":[]},{"section":"ingressclass-v1beta1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-ingressclass-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"delete-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"replace-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"create-ingressclass-v1beta1-networking-k8s-io","subsections":[]}]}]},{"section":"ingressbackend-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingressbackend-v1beta1-extensions","subsections":[]},{"section":"ingress-v1beta1-networking-k8s-io","subsections":[{"section":"-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"replace-status-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-status-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-status-ingress-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-list-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-ingress-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"delete-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"replace-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"create-ingress-v1beta1-networking-k8s-io","subsections":[]}]}]},{"section":"ingress-v1beta1-extensions","subsections":[{"section":"-strong-status-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"replace-status-ingress-v1beta1-extensions","subsections":[]},{"section":"read-status-ingress-v1beta1-extensions","subsections":[]},{"section":"patch-status-ingress-v1beta1-extensions","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1beta1-extensions","subsections":[]},{"section":"watch-list-ingress-v1beta1-extensions","subsections":[]},{"section":"watch-ingress-v1beta1-extensions","subsections":[]},{"section":"list-all-namespaces-ingress-v1beta1-extensions","subsections":[]},{"section":"list-ingress-v1beta1-extensions","subsections":[]},{"section":"read-ingress-v1beta1-extensions","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"delete-collection-ingress-v1beta1-extensions","subsections":[]},{"section":"delete-ingress-v1beta1-extensions","subsections":[]},{"section":"replace-ingress-v1beta1-extensions","subsections":[]},{"section":"patch-ingress-v1beta1-extensions","subsections":[]},{"section":"create-ingress-v1beta1-extensions","subsections":[]}]}]},{"section":"horizontalpodautoscalercondition-v2beta1-autoscaling","subsections":[]},{"section":"horizontalpodautoscaler-v2beta1-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]}]},{"section":"horizontalpodautoscaler-v2beta2-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]}]},{"section":"httpingressrulevalue-v1beta1-networking-k8s-io","subsections":[]},{"section":"httpingressrulevalue-v1beta1-extensions","subsections":[]},{"section":"httpingresspath-v1beta1-networking-k8s-io","subsections":[]},{"section":"httpingresspath-v1beta1-extensions","subsections":[]},{"section":"externalmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"externalmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"externaldocumentation-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"eventseries-v1beta1-events-k8s-io","subsections":[]},{"section":"eventseries-v1-events-k8s-io","subsections":[]},{"section":"event-v1beta1-events-k8s-io","subsections":[{"section":"-strong-read-operations-event-v1beta1-events-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1beta1-events-k8s-io","subsections":[]},{"section":"watch-list-event-v1beta1-events-k8s-io","subsections":[]},{"section":"watch-event-v1beta1-events-k8s-io","subsections":[]},{"section":"list-all-namespaces-event-v1beta1-events-k8s-io","subsections":[]},{"section":"list-event-v1beta1-events-k8s-io","subsections":[]},{"section":"read-event-v1beta1-events-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-event-v1beta1-events-k8s-io-strong-","subsections":[{"section":"delete-collection-event-v1beta1-events-k8s-io","subsections":[]},{"section":"delete-event-v1beta1-events-k8s-io","subsections":[]},{"section":"replace-event-v1beta1-events-k8s-io","subsections":[]},{"section":"patch-event-v1beta1-events-k8s-io","subsections":[]},{"section":"create-event-v1beta1-events-k8s-io","subsections":[]}]}]},{"section":"event-v1-events-k8s-io","subsections":[{"section":"-strong-read-operations-event-v1-events-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1-events-k8s-io","subsections":[]},{"section":"watch-list-event-v1-events-k8s-io","subsections":[]},{"section":"watch-event-v1-events-k8s-io","subsections":[]},{"section":"list-all-namespaces-event-v1-events-k8s-io","subsections":[]},{"section":"list-event-v1-events-k8s-io","subsections":[]},{"section":"read-event-v1-events-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-event-v1-events-k8s-io-strong-","subsections":[{"section":"delete-collection-event-v1-events-k8s-io","subsections":[]},{"section":"delete-event-v1-events-k8s-io","subsections":[]},{"section":"replace-event-v1-events-k8s-io","subsections":[]},{"section":"patch-event-v1-events-k8s-io","subsections":[]},{"section":"create-event-v1-events-k8s-io","subsections":[]}]}]},{"section":"endpointport-v1beta1-discovery-k8s-io","subsections":[]},{"section":"customresourcevalidation-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresources-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcescale-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionversion-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionnames-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[{"section":"-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"watch-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"list-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"read-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"delete-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"replace-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"patch-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"create-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]}]},{"section":"customresourceconversion-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcecolumndefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"crossversionobjectreference-v2beta1-autoscaling","subsections":[]},{"section":"crossversionobjectreference-v2beta2-autoscaling","subsections":[]},{"section":"cronjob-v2alpha1-batch","subsections":[{"section":"-strong-status-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"replace-status-cronjob-v2alpha1-batch","subsections":[]},{"section":"read-status-cronjob-v2alpha1-batch","subsections":[]},{"section":"patch-status-cronjob-v2alpha1-batch","subsections":[]}]},{"section":"-strong-read-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-cronjob-v2alpha1-batch","subsections":[]},{"section":"watch-list-cronjob-v2alpha1-batch","subsections":[]},{"section":"watch-cronjob-v2alpha1-batch","subsections":[]},{"section":"list-all-namespaces-cronjob-v2alpha1-batch","subsections":[]},{"section":"list-cronjob-v2alpha1-batch","subsections":[]},{"section":"read-cronjob-v2alpha1-batch","subsections":[]}]},{"section":"-strong-write-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"delete-collection-cronjob-v2alpha1-batch","subsections":[]},{"section":"delete-cronjob-v2alpha1-batch","subsections":[]},{"section":"replace-cronjob-v2alpha1-batch","subsections":[]},{"section":"patch-cronjob-v2alpha1-batch","subsections":[]},{"section":"create-cronjob-v2alpha1-batch","subsections":[]}]}]},{"section":"clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"certificatesigningrequestcondition-v1beta1-certificates-k8s-io","subsections":[]},{"section":"certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[{"section":"-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"read-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"watch-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"list-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"read-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"delete-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"replace-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"patch-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"create-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]}]},{"section":"csinodedriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"csinode-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-csinode-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-csinode-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"csidriver-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-csidriver-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-csidriver-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"aggregationrule-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"aggregationrule-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"apiservicecondition-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"apiservice-v1beta1-apiregistration-k8s-io","subsections":[{"section":"-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"replace-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"read-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"patch-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"watch-list-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"watch-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"list-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"read-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"delete-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"replace-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"patch-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"create-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]}]},{"section":"-strong-old-api-versions-strong-","subsections":[]},{"section":"windowssecuritycontextoptions-v1-core","subsections":[]},{"section":"weightedpodaffinityterm-v1-core","subsections":[]},{"section":"webhookconversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watchevent-v1-meta","subsections":[]},{"section":"vspherevirtualdiskvolumesource-v1-core","subsections":[]},{"section":"volumeprojection-v1-core","subsections":[]},{"section":"volumenoderesources-v1-storage-k8s-io","subsections":[]},{"section":"volumenodeaffinity-v1-core","subsections":[]},{"section":"volumemount-v1-core","subsections":[]},{"section":"volumeerror-v1-storage-k8s-io","subsections":[]},{"section":"volumedevice-v1-core","subsections":[]},{"section":"volumeattachmentsource-v1-storage-k8s-io","subsections":[]},{"section":"validatingwebhook-v1-admissionregistration-k8s-io","subsections":[]},{"section":"usersubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"userinfo-v1-authentication-k8s-io","subsections":[]},{"section":"typedlocalobjectreference-v1-core","subsections":[]},{"section":"topologyspreadconstraint-v1-core","subsections":[]},{"section":"topologyselectorterm-v1-core","subsections":[]},{"section":"topologyselectorlabelrequirement-v1-core","subsections":[]},{"section":"toleration-v1-core","subsections":[]},{"section":"time-v1-meta","subsections":[]},{"section":"taint-v1-core","subsections":[]},{"section":"tcpsocketaction-v1-core","subsections":[]},{"section":"sysctl-v1-core","subsections":[]},{"section":"supplementalgroupsstrategyoptions-v1beta1-policy","subsections":[]},{"section":"subjectrulesreviewstatus-v1-authorization-k8s-io","subsections":[]},{"section":"subject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"storageosvolumesource-v1-core","subsections":[]},{"section":"storageospersistentvolumesource-v1-core","subsections":[]},{"section":"statusdetails-v1-meta","subsections":[]},{"section":"statuscause-v1-meta","subsections":[]},{"section":"status-v1-meta","subsections":[]},{"section":"statefulsetupdatestrategy-v1-apps","subsections":[]},{"section":"statefulsetcondition-v1-apps","subsections":[]},{"section":"sessionaffinityconfig-v1-core","subsections":[]},{"section":"servicereference-v1-admissionregistration-k8s-io","subsections":[]},{"section":"serviceport-v1-core","subsections":[]},{"section":"servicebackendport-v1-networking-k8s-io","subsections":[]},{"section":"serviceaccounttokenprojection-v1-core","subsections":[]},{"section":"serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"serveraddressbyclientcidr-v1-meta","subsections":[]},{"section":"securitycontext-v1-core","subsections":[]},{"section":"secretvolumesource-v1-core","subsections":[]},{"section":"secretreference-v1-core","subsections":[]},{"section":"secretprojection-v1-core","subsections":[]},{"section":"secretkeyselector-v1-core","subsections":[]},{"section":"secretenvsource-v1-core","subsections":[]},{"section":"seccompprofile-v1-core","subsections":[]},{"section":"scopedresourceselectorrequirement-v1-core","subsections":[]},{"section":"scopeselector-v1-core","subsections":[]},{"section":"scheduling-v1beta1-node-k8s-io","subsections":[]},{"section":"scaleiovolumesource-v1-core","subsections":[]},{"section":"scaleiopersistentvolumesource-v1-core","subsections":[]},{"section":"scale-v1-autoscaling","subsections":[]},{"section":"selinuxstrategyoptions-v1beta1-policy","subsections":[]},{"section":"selinuxoptions-v1-core","subsections":[]},{"section":"runtimeclassstrategyoptions-v1beta1-policy","subsections":[]},{"section":"runasuserstrategyoptions-v1beta1-policy","subsections":[]},{"section":"runasgroupstrategyoptions-v1beta1-policy","subsections":[]},{"section":"rulewithoperations-v1-admissionregistration-k8s-io","subsections":[]},{"section":"rollingupdatestatefulsetstrategy-v1-apps","subsections":[]},{"section":"roleref-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"resourcerule-v1-authorization-k8s-io","subsections":[]},{"section":"resourcerequirements-v1-core","subsections":[]},{"section":"resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"resourcemetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"resourcemetricsource-v2beta2-autoscaling","subsections":[]},{"section":"resourcefieldselector-v1-core","subsections":[]},{"section":"resourceattributes-v1-authorization-k8s-io","subsections":[]},{"section":"replicationcontrollercondition-v1-core","subsections":[]},{"section":"replicasetcondition-v1-apps","subsections":[]},{"section":"rbdvolumesource-v1-core","subsections":[]},{"section":"rbdpersistentvolumesource-v1-core","subsections":[]},{"section":"quobytevolumesource-v1-core","subsections":[]},{"section":"queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"quantity-resource-core","subsections":[]},{"section":"projectedvolumesource-v1-core","subsections":[]},{"section":"probe-v1-core","subsections":[]},{"section":"prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"preferredschedulingterm-v1-core","subsections":[]},{"section":"preconditions-v1-meta","subsections":[]},{"section":"portworxvolumesource-v1-core","subsections":[]},{"section":"policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"policyrule-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"podsmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"podsmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"podsecuritycontext-v1-core","subsections":[]},{"section":"podreadinessgate-v1-core","subsections":[]},{"section":"podip-v1-core","subsections":[]},{"section":"poddnsconfigoption-v1-core","subsections":[]},{"section":"poddnsconfig-v1-core","subsections":[]},{"section":"podcondition-v1-core","subsections":[]},{"section":"podantiaffinity-v1-core","subsections":[]},{"section":"podaffinityterm-v1-core","subsections":[]},{"section":"podaffinity-v1-core","subsections":[]},{"section":"photonpersistentdiskvolumesource-v1-core","subsections":[]},{"section":"persistentvolumeclaimvolumesource-v1-core","subsections":[]},{"section":"persistentvolumeclaimtemplate-v1-core","subsections":[]},{"section":"persistentvolumeclaimcondition-v1-core","subsections":[]},{"section":"patch-v1-meta","subsections":[]},{"section":"ownerreference-v1-meta","subsections":[]},{"section":"overhead-v1beta1-node-k8s-io","subsections":[]},{"section":"objectreference-v1-core","subsections":[]},{"section":"objectmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"objectmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"objectmeta-v1-meta","subsections":[]},{"section":"objectfieldselector-v1-core","subsections":[]},{"section":"nonresourcerule-v1-authorization-k8s-io","subsections":[]},{"section":"nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"nonresourceattributes-v1-authorization-k8s-io","subsections":[]},{"section":"nodesysteminfo-v1-core","subsections":[]},{"section":"nodeselectorterm-v1-core","subsections":[]},{"section":"nodeselectorrequirement-v1-core","subsections":[]},{"section":"nodeselector-v1-core","subsections":[]},{"section":"nodedaemonendpoints-v1-core","subsections":[]},{"section":"nodeconfigstatus-v1-core","subsections":[]},{"section":"nodeconfigsource-v1-core","subsections":[]},{"section":"nodecondition-v1-core","subsections":[]},{"section":"nodeaffinity-v1-core","subsections":[]},{"section":"nodeaddress-v1-core","subsections":[]},{"section":"networkpolicyport-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicypeer-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicyingressrule-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicyegressrule-v1-networking-k8s-io","subsections":[]},{"section":"namespacecondition-v1-core","subsections":[]},{"section":"nfsvolumesource-v1-core","subsections":[]},{"section":"mutatingwebhook-v1-admissionregistration-k8s-io","subsections":[]},{"section":"microtime-v1-meta","subsections":[]},{"section":"metricvaluestatus-v2beta2-autoscaling","subsections":[]},{"section":"metrictarget-v2beta2-autoscaling","subsections":[]},{"section":"metricstatus-v2beta2-autoscaling","subsections":[]},{"section":"metricspec-v2beta2-autoscaling","subsections":[]},{"section":"metricidentifier-v2beta2-autoscaling","subsections":[]},{"section":"managedfieldsentry-v1-meta","subsections":[]},{"section":"localvolumesource-v1-core","subsections":[]},{"section":"localobjectreference-v1-core","subsections":[]},{"section":"loadbalancerstatus-v1-core","subsections":[]},{"section":"loadbalanceringress-v1-core","subsections":[]},{"section":"listmeta-v1-meta","subsections":[]},{"section":"limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"limitrangeitem-v1-core","subsections":[]},{"section":"lifecycle-v1-core","subsections":[]},{"section":"labelselectorrequirement-v1-meta","subsections":[]},{"section":"labelselector-v1-meta","subsections":[]},{"section":"keytopath-v1-core","subsections":[]},{"section":"jobtemplatespec-v1beta1-batch","subsections":[]},{"section":"jobcondition-v1-batch","subsections":[]},{"section":"jsonschemapropsorbool-v1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemapropsorarray-v1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemaprops-v1-apiextensions-k8s-io","subsections":[]},{"section":"json-v1-apiextensions-k8s-io","subsections":[]},{"section":"ingresstls-v1-networking-k8s-io","subsections":[]},{"section":"ingressservicebackend-v1-networking-k8s-io","subsections":[]},{"section":"ingressrule-v1-networking-k8s-io","subsections":[]},{"section":"ingressbackend-v1-networking-k8s-io","subsections":[]},{"section":"iscsivolumesource-v1-core","subsections":[]},{"section":"iscsipersistentvolumesource-v1-core","subsections":[]},{"section":"ipblock-v1-networking-k8s-io","subsections":[]},{"section":"idrange-v1beta1-policy","subsections":[]},{"section":"hostportrange-v1beta1-policy","subsections":[]},{"section":"hostpathvolumesource-v1-core","subsections":[]},{"section":"hostalias-v1-core","subsections":[]},{"section":"horizontalpodautoscalercondition-v2beta2-autoscaling","subsections":[]},{"section":"horizontalpodautoscalerbehavior-v2beta2-autoscaling","subsections":[]},{"section":"handler-v1-core","subsections":[]},{"section":"httpingressrulevalue-v1-networking-k8s-io","subsections":[]},{"section":"httpingresspath-v1-networking-k8s-io","subsections":[]},{"section":"httpheader-v1-core","subsections":[]},{"section":"httpgetaction-v1-core","subsections":[]},{"section":"hpascalingrules-v2beta2-autoscaling","subsections":[]},{"section":"hpascalingpolicy-v2beta2-autoscaling","subsections":[]},{"section":"groupversionfordiscovery-v1-meta","subsections":[]},{"section":"groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"glusterfsvolumesource-v1-core","subsections":[]},{"section":"glusterfspersistentvolumesource-v1-core","subsections":[]},{"section":"gitrepovolumesource-v1-core","subsections":[]},{"section":"gcepersistentdiskvolumesource-v1-core","subsections":[]},{"section":"flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"flockervolumesource-v1-core","subsections":[]},{"section":"flexvolumesource-v1-core","subsections":[]},{"section":"flexpersistentvolumesource-v1-core","subsections":[]},{"section":"fieldsv1-v1-meta","subsections":[]},{"section":"fsgroupstrategyoptions-v1beta1-policy","subsections":[]},{"section":"fcvolumesource-v1-core","subsections":[]},{"section":"externalmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"externalmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"externaldocumentation-v1-apiextensions-k8s-io","subsections":[]},{"section":"execaction-v1-core","subsections":[]},{"section":"eviction-v1beta1-policy","subsections":[]},{"section":"eventsource-v1-core","subsections":[]},{"section":"eventseries-v1-core","subsections":[]},{"section":"ephemeralvolumesource-v1-core","subsections":[]},{"section":"ephemeralcontainer-v1-core","subsections":[]},{"section":"envvarsource-v1-core","subsections":[]},{"section":"envvar-v1-core","subsections":[]},{"section":"envfromsource-v1-core","subsections":[]},{"section":"endpointsubset-v1-core","subsections":[]},{"section":"endpointport-v1-core","subsections":[]},{"section":"endpointconditions-v1beta1-discovery-k8s-io","subsections":[]},{"section":"endpointaddress-v1-core","subsections":[]},{"section":"endpoint-v1beta1-discovery-k8s-io","subsections":[]},{"section":"emptydirvolumesource-v1-core","subsections":[]},{"section":"downwardapivolumesource-v1-core","subsections":[]},{"section":"downwardapivolumefile-v1-core","subsections":[]},{"section":"downwardapiprojection-v1-core","subsections":[]},{"section":"deploymentcondition-v1-apps","subsections":[]},{"section":"deleteoptions-v1-meta","subsections":[]},{"section":"daemonsetupdatestrategy-v1-apps","subsections":[]},{"section":"daemonsetcondition-v1-apps","subsections":[]},{"section":"daemonendpoint-v1-core","subsections":[]},{"section":"customresourcevalidation-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresources-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcestatus-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcescale-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionnames-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitioncondition-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourceconversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcecolumndefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"crossversionobjectreference-v1-autoscaling","subsections":[]},{"section":"containerstatewaiting-v1-core","subsections":[]},{"section":"containerstateterminated-v1-core","subsections":[]},{"section":"containerstaterunning-v1-core","subsections":[]},{"section":"containerstate-v1-core","subsections":[]},{"section":"containerport-v1-core","subsections":[]},{"section":"containerimage-v1-core","subsections":[]},{"section":"configmapvolumesource-v1-core","subsections":[]},{"section":"configmapprojection-v1-core","subsections":[]},{"section":"configmapnodeconfigsource-v1-core","subsections":[]},{"section":"configmapkeyselector-v1-core","subsections":[]},{"section":"configmapenvsource-v1-core","subsections":[]},{"section":"componentcondition-v1-core","subsections":[]},{"section":"clientipconfig-v1-core","subsections":[]},{"section":"cindervolumesource-v1-core","subsections":[]},{"section":"cinderpersistentvolumesource-v1-core","subsections":[]},{"section":"certificatesigningrequestcondition-v1-certificates-k8s-io","subsections":[]},{"section":"cephfsvolumesource-v1-core","subsections":[]},{"section":"cephfspersistentvolumesource-v1-core","subsections":[]},{"section":"capabilities-v1-core","subsections":[]},{"section":"csivolumesource-v1-core","subsections":[]},{"section":"csipersistentvolumesource-v1-core","subsections":[]},{"section":"csinodedriver-v1-storage-k8s-io","subsections":[]},{"section":"boundobjectreference-v1-authentication-k8s-io","subsections":[]},{"section":"azurefilevolumesource-v1-core","subsections":[]},{"section":"azurefilepersistentvolumesource-v1-core","subsections":[]},{"section":"azurediskvolumesource-v1-core","subsections":[]},{"section":"attachedvolume-v1-core","subsections":[]},{"section":"allowedhostpath-v1beta1-policy","subsections":[]},{"section":"allowedflexvolume-v1beta1-policy","subsections":[]},{"section":"allowedcsidriver-v1beta1-policy","subsections":[]},{"section":"aggregationrule-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"affinity-v1-core","subsections":[]},{"section":"awselasticblockstorevolumesource-v1-core","subsections":[]},{"section":"apiversions-v1-meta","subsections":[]},{"section":"apiservicecondition-v1-apiregistration-k8s-io","subsections":[]},{"section":"apiresource-v1-meta","subsections":[]},{"section":"apigroup-v1-meta","subsections":[]},{"section":"-strong-definitions-strong-","subsections":[]},{"section":"networkpolicy-v1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"watch-list-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"watch-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"list-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"read-networkpolicy-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"delete-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"replace-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"patch-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"create-networkpolicy-v1-networking-k8s-io","subsections":[]}]}]},{"section":"tokenreview-v1-authentication-k8s-io","subsections":[{"section":"-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-","subsections":[{"section":"create-tokenreview-v1-authentication-k8s-io","subsections":[]}]}]},{"section":"tokenrequest-v1-authentication-k8s-io","subsections":[]},{"section":"subjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-subjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"serviceaccount-v1-core","subsections":[{"section":"-strong-read-operations-serviceaccount-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-serviceaccount-v1-core","subsections":[]},{"section":"watch-list-serviceaccount-v1-core","subsections":[]},{"section":"watch-serviceaccount-v1-core","subsections":[]},{"section":"list-all-namespaces-serviceaccount-v1-core","subsections":[]},{"section":"list-serviceaccount-v1-core","subsections":[]},{"section":"read-serviceaccount-v1-core","subsections":[]}]},{"section":"-strong-write-operations-serviceaccount-v1-core-strong-","subsections":[{"section":"delete-collection-serviceaccount-v1-core","subsections":[]},{"section":"delete-serviceaccount-v1-core","subsections":[]},{"section":"replace-serviceaccount-v1-core","subsections":[]},{"section":"patch-serviceaccount-v1-core","subsections":[]},{"section":"create-serviceaccount-v1-core","subsections":[]}]}]},{"section":"selfsubjectrulesreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectrulesreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"selfsubjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"runtimeclass-v1beta1-node-k8s-io","subsections":[{"section":"-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-","subsections":[{"section":"watch-list-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"watch-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"list-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"read-runtimeclass-v1beta1-node-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-","subsections":[{"section":"delete-collection-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"delete-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"replace-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"patch-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"create-runtimeclass-v1beta1-node-k8s-io","subsections":[]}]}]},{"section":"rolebinding-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"resourcequota-v1-core","subsections":[{"section":"-strong-status-operations-resourcequota-v1-core-strong-","subsections":[{"section":"replace-status-resourcequota-v1-core","subsections":[]},{"section":"read-status-resourcequota-v1-core","subsections":[]},{"section":"patch-status-resourcequota-v1-core","subsections":[]}]},{"section":"-strong-read-operations-resourcequota-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-resourcequota-v1-core","subsections":[]},{"section":"watch-list-resourcequota-v1-core","subsections":[]},{"section":"watch-resourcequota-v1-core","subsections":[]},{"section":"list-all-namespaces-resourcequota-v1-core","subsections":[]},{"section":"list-resourcequota-v1-core","subsections":[]},{"section":"read-resourcequota-v1-core","subsections":[]}]},{"section":"-strong-write-operations-resourcequota-v1-core-strong-","subsections":[{"section":"delete-collection-resourcequota-v1-core","subsections":[]},{"section":"delete-resourcequota-v1-core","subsections":[]},{"section":"replace-resourcequota-v1-core","subsections":[]},{"section":"patch-resourcequota-v1-core","subsections":[]},{"section":"create-resourcequota-v1-core","subsections":[]}]}]},{"section":"prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[{"section":"-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]}]},{"section":"persistentvolume-v1-core","subsections":[{"section":"-strong-status-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"replace-status-persistentvolume-v1-core","subsections":[]},{"section":"read-status-persistentvolume-v1-core","subsections":[]},{"section":"patch-status-persistentvolume-v1-core","subsections":[]}]},{"section":"-strong-read-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"watch-list-persistentvolume-v1-core","subsections":[]},{"section":"watch-persistentvolume-v1-core","subsections":[]},{"section":"list-persistentvolume-v1-core","subsections":[]},{"section":"read-persistentvolume-v1-core","subsections":[]}]},{"section":"-strong-write-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"delete-collection-persistentvolume-v1-core","subsections":[]},{"section":"delete-persistentvolume-v1-core","subsections":[]},{"section":"replace-persistentvolume-v1-core","subsections":[]},{"section":"patch-persistentvolume-v1-core","subsections":[]},{"section":"create-persistentvolume-v1-core","subsections":[]}]}]},{"section":"node-v1-core","subsections":[{"section":"-strong-proxy-operations-node-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-node-v1-core","subsections":[]},{"section":"replace-connect-proxy-node-v1-core","subsections":[]},{"section":"head-connect-proxy-path-node-v1-core","subsections":[]},{"section":"head-connect-proxy-node-v1-core","subsections":[]},{"section":"get-connect-proxy-path-node-v1-core","subsections":[]},{"section":"get-connect-proxy-node-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-node-v1-core","subsections":[]},{"section":"delete-connect-proxy-node-v1-core","subsections":[]},{"section":"create-connect-proxy-path-node-v1-core","subsections":[]},{"section":"create-connect-proxy-node-v1-core","subsections":[]}]},{"section":"-strong-status-operations-node-v1-core-strong-","subsections":[{"section":"replace-status-node-v1-core","subsections":[]},{"section":"read-status-node-v1-core","subsections":[]},{"section":"patch-status-node-v1-core","subsections":[]}]},{"section":"-strong-read-operations-node-v1-core-strong-","subsections":[{"section":"watch-list-node-v1-core","subsections":[]},{"section":"watch-node-v1-core","subsections":[]},{"section":"list-node-v1-core","subsections":[]},{"section":"read-node-v1-core","subsections":[]}]},{"section":"-strong-write-operations-node-v1-core-strong-","subsections":[{"section":"delete-collection-node-v1-core","subsections":[]},{"section":"delete-node-v1-core","subsections":[]},{"section":"replace-node-v1-core","subsections":[]},{"section":"patch-node-v1-core","subsections":[]},{"section":"create-node-v1-core","subsections":[]}]}]},{"section":"namespace-v1-core","subsections":[{"section":"-strong-status-operations-namespace-v1-core-strong-","subsections":[{"section":"replace-status-namespace-v1-core","subsections":[]},{"section":"read-status-namespace-v1-core","subsections":[]},{"section":"patch-status-namespace-v1-core","subsections":[]}]},{"section":"-strong-read-operations-namespace-v1-core-strong-","subsections":[{"section":"watch-list-namespace-v1-core","subsections":[]},{"section":"watch-namespace-v1-core","subsections":[]},{"section":"list-namespace-v1-core","subsections":[]},{"section":"read-namespace-v1-core","subsections":[]}]},{"section":"-strong-write-operations-namespace-v1-core-strong-","subsections":[{"section":"delete-namespace-v1-core","subsections":[]},{"section":"replace-namespace-v1-core","subsections":[]},{"section":"patch-namespace-v1-core","subsections":[]},{"section":"create-namespace-v1-core","subsections":[]}]}]},{"section":"localsubjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-localsubjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"lease-v1-coordination-k8s-io","subsections":[{"section":"-strong-read-operations-lease-v1-coordination-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-lease-v1-coordination-k8s-io","subsections":[]},{"section":"watch-list-lease-v1-coordination-k8s-io","subsections":[]},{"section":"watch-lease-v1-coordination-k8s-io","subsections":[]},{"section":"list-all-namespaces-lease-v1-coordination-k8s-io","subsections":[]},{"section":"list-lease-v1-coordination-k8s-io","subsections":[]},{"section":"read-lease-v1-coordination-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-lease-v1-coordination-k8s-io-strong-","subsections":[{"section":"delete-collection-lease-v1-coordination-k8s-io","subsections":[]},{"section":"delete-lease-v1-coordination-k8s-io","subsections":[]},{"section":"replace-lease-v1-coordination-k8s-io","subsections":[]},{"section":"patch-lease-v1-coordination-k8s-io","subsections":[]},{"section":"create-lease-v1-coordination-k8s-io","subsections":[]}]}]},{"section":"flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[{"section":"-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]}]},{"section":"componentstatus-v1-core","subsections":[{"section":"-strong-read-operations-componentstatus-v1-core-strong-","subsections":[{"section":"list-componentstatus-v1-core","subsections":[]},{"section":"read-componentstatus-v1-core","subsections":[]}]}]},{"section":"clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"certificatesigningrequest-v1-certificates-k8s-io","subsections":[{"section":"-strong-status-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","subsections":[{"section":"replace-status-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"read-status-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"patch-status-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","subsections":[{"section":"watch-list-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"watch-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"list-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"read-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","subsections":[{"section":"delete-collection-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"delete-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"replace-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"patch-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"create-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]}]}]},{"section":"binding-v1-core","subsections":[{"section":"-strong-write-operations-binding-v1-core-strong-","subsections":[{"section":"create-binding-v1-core","subsections":[]}]}]},{"section":"apiservice-v1-apiregistration-k8s-io","subsections":[{"section":"-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"replace-status-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"read-status-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"patch-status-apiservice-v1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"watch-list-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"watch-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"list-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"read-apiservice-v1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"delete-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"replace-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"patch-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"create-apiservice-v1-apiregistration-k8s-io","subsections":[]}]}]},{"section":"-strong-cluster-apis-strong-","subsections":[]},{"section":"podsecuritypolicy-v1beta1-policy","subsections":[{"section":"-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-","subsections":[{"section":"watch-list-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"watch-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"list-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"read-podsecuritypolicy-v1beta1-policy","subsections":[]}]},{"section":"-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-","subsections":[{"section":"delete-collection-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"delete-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"replace-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"patch-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"create-podsecuritypolicy-v1beta1-policy","subsections":[]}]}]},{"section":"podpreset-v1alpha1-settings-k8s-io","subsections":[{"section":"-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"watch-list-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"watch-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"list-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"read-podpreset-v1alpha1-settings-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-","subsections":[{"section":"delete-collection-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"delete-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"replace-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"patch-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"create-podpreset-v1alpha1-settings-k8s-io","subsections":[]}]}]},{"section":"priorityclass-v1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1-scheduling-k8s-io","subsections":[]}]}]},{"section":"poddisruptionbudget-v1beta1-policy","subsections":[{"section":"-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"replace-status-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"read-status-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"patch-status-poddisruptionbudget-v1beta1-policy","subsections":[]}]},{"section":"-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"watch-list-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"watch-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"list-all-namespaces-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"list-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"read-poddisruptionbudget-v1beta1-policy","subsections":[]}]},{"section":"-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"delete-collection-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"delete-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"replace-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"patch-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"create-poddisruptionbudget-v1beta1-policy","subsections":[]}]}]},{"section":"podtemplate-v1-core","subsections":[{"section":"-strong-read-operations-podtemplate-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-podtemplate-v1-core","subsections":[]},{"section":"watch-list-podtemplate-v1-core","subsections":[]},{"section":"watch-podtemplate-v1-core","subsections":[]},{"section":"list-all-namespaces-podtemplate-v1-core","subsections":[]},{"section":"list-podtemplate-v1-core","subsections":[]},{"section":"read-podtemplate-v1-core","subsections":[]}]},{"section":"-strong-write-operations-podtemplate-v1-core-strong-","subsections":[{"section":"delete-collection-podtemplate-v1-core","subsections":[]},{"section":"delete-podtemplate-v1-core","subsections":[]},{"section":"replace-podtemplate-v1-core","subsections":[]},{"section":"patch-podtemplate-v1-core","subsections":[]},{"section":"create-podtemplate-v1-core","subsections":[]}]}]},{"section":"validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"horizontalpodautoscaler-v1-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]}]},{"section":"limitrange-v1-core","subsections":[{"section":"-strong-read-operations-limitrange-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-limitrange-v1-core","subsections":[]},{"section":"watch-list-limitrange-v1-core","subsections":[]},{"section":"watch-limitrange-v1-core","subsections":[]},{"section":"list-all-namespaces-limitrange-v1-core","subsections":[]},{"section":"list-limitrange-v1-core","subsections":[]},{"section":"read-limitrange-v1-core","subsections":[]}]},{"section":"-strong-write-operations-limitrange-v1-core-strong-","subsections":[{"section":"delete-collection-limitrange-v1-core","subsections":[]},{"section":"delete-limitrange-v1-core","subsections":[]},{"section":"replace-limitrange-v1-core","subsections":[]},{"section":"patch-limitrange-v1-core","subsections":[]},{"section":"create-limitrange-v1-core","subsections":[]}]}]},{"section":"event-v1-core","subsections":[{"section":"-strong-read-operations-event-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1-core","subsections":[]},{"section":"watch-list-event-v1-core","subsections":[]},{"section":"watch-event-v1-core","subsections":[]},{"section":"list-all-namespaces-event-v1-core","subsections":[]},{"section":"list-event-v1-core","subsections":[]},{"section":"read-event-v1-core","subsections":[]}]},{"section":"-strong-write-operations-event-v1-core-strong-","subsections":[{"section":"delete-collection-event-v1-core","subsections":[]},{"section":"delete-event-v1-core","subsections":[]},{"section":"replace-event-v1-core","subsections":[]},{"section":"patch-event-v1-core","subsections":[]},{"section":"create-event-v1-core","subsections":[]}]}]},{"section":"customresourcedefinition-v1-apiextensions-k8s-io","subsections":[{"section":"-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"replace-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"read-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"patch-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"watch-list-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"watch-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"list-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"read-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"delete-collection-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"delete-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"replace-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"patch-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"create-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]}]},{"section":"controllerrevision-v1-apps","subsections":[{"section":"-strong-read-operations-controllerrevision-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-controllerrevision-v1-apps","subsections":[]},{"section":"watch-list-controllerrevision-v1-apps","subsections":[]},{"section":"watch-controllerrevision-v1-apps","subsections":[]},{"section":"list-all-namespaces-controllerrevision-v1-apps","subsections":[]},{"section":"list-controllerrevision-v1-apps","subsections":[]},{"section":"read-controllerrevision-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-controllerrevision-v1-apps-strong-","subsections":[{"section":"delete-collection-controllerrevision-v1-apps","subsections":[]},{"section":"delete-controllerrevision-v1-apps","subsections":[]},{"section":"replace-controllerrevision-v1-apps","subsections":[]},{"section":"patch-controllerrevision-v1-apps","subsections":[]},{"section":"create-controllerrevision-v1-apps","subsections":[]}]}]},{"section":"-strong-metadata-apis-strong-","subsections":[]},{"section":"volumeattachment-v1-storage-k8s-io","subsections":[{"section":"-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"replace-status-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"read-status-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"patch-status-volumeattachment-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1-storage-k8s-io","subsections":[]}]}]},{"section":"volume-v1-core","subsections":[]},{"section":"storageclass-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-storageclass-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"watch-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"list-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"read-storageclass-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-storageclass-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"delete-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"replace-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"patch-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"create-storageclass-v1-storage-k8s-io","subsections":[]}]}]},{"section":"persistentvolumeclaim-v1-core","subsections":[{"section":"-strong-status-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"replace-status-persistentvolumeclaim-v1-core","subsections":[]},{"section":"read-status-persistentvolumeclaim-v1-core","subsections":[]},{"section":"patch-status-persistentvolumeclaim-v1-core","subsections":[]}]},{"section":"-strong-read-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-persistentvolumeclaim-v1-core","subsections":[]},{"section":"watch-list-persistentvolumeclaim-v1-core","subsections":[]},{"section":"watch-persistentvolumeclaim-v1-core","subsections":[]},{"section":"list-all-namespaces-persistentvolumeclaim-v1-core","subsections":[]},{"section":"list-persistentvolumeclaim-v1-core","subsections":[]},{"section":"read-persistentvolumeclaim-v1-core","subsections":[]}]},{"section":"-strong-write-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"delete-collection-persistentvolumeclaim-v1-core","subsections":[]},{"section":"delete-persistentvolumeclaim-v1-core","subsections":[]},{"section":"replace-persistentvolumeclaim-v1-core","subsections":[]},{"section":"patch-persistentvolumeclaim-v1-core","subsections":[]},{"section":"create-persistentvolumeclaim-v1-core","subsections":[]}]}]},{"section":"secret-v1-core","subsections":[{"section":"-strong-read-operations-secret-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-secret-v1-core","subsections":[]},{"section":"watch-list-secret-v1-core","subsections":[]},{"section":"watch-secret-v1-core","subsections":[]},{"section":"list-all-namespaces-secret-v1-core","subsections":[]},{"section":"list-secret-v1-core","subsections":[]},{"section":"read-secret-v1-core","subsections":[]}]},{"section":"-strong-write-operations-secret-v1-core-strong-","subsections":[{"section":"delete-collection-secret-v1-core","subsections":[]},{"section":"delete-secret-v1-core","subsections":[]},{"section":"replace-secret-v1-core","subsections":[]},{"section":"patch-secret-v1-core","subsections":[]},{"section":"create-secret-v1-core","subsections":[]}]}]},{"section":"csinode-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csinode-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csinode-v1-storage-k8s-io","subsections":[]},{"section":"watch-csinode-v1-storage-k8s-io","subsections":[]},{"section":"list-csinode-v1-storage-k8s-io","subsections":[]},{"section":"read-csinode-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csinode-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csinode-v1-storage-k8s-io","subsections":[]},{"section":"delete-csinode-v1-storage-k8s-io","subsections":[]},{"section":"replace-csinode-v1-storage-k8s-io","subsections":[]},{"section":"patch-csinode-v1-storage-k8s-io","subsections":[]},{"section":"create-csinode-v1-storage-k8s-io","subsections":[]}]}]},{"section":"csidriver-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csidriver-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"watch-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"list-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"read-csidriver-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csidriver-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"delete-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"replace-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"patch-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"create-csidriver-v1-storage-k8s-io","subsections":[]}]}]},{"section":"configmap-v1-core","subsections":[{"section":"-strong-read-operations-configmap-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-configmap-v1-core","subsections":[]},{"section":"watch-list-configmap-v1-core","subsections":[]},{"section":"watch-configmap-v1-core","subsections":[]},{"section":"list-all-namespaces-configmap-v1-core","subsections":[]},{"section":"list-configmap-v1-core","subsections":[]},{"section":"read-configmap-v1-core","subsections":[]}]},{"section":"-strong-write-operations-configmap-v1-core-strong-","subsections":[{"section":"delete-collection-configmap-v1-core","subsections":[]},{"section":"delete-configmap-v1-core","subsections":[]},{"section":"replace-configmap-v1-core","subsections":[]},{"section":"patch-configmap-v1-core","subsections":[]},{"section":"create-configmap-v1-core","subsections":[]}]}]},{"section":"-strong-config-and-storage-apis-strong-","subsections":[]},{"section":"service-v1-core","subsections":[{"section":"-strong-proxy-operations-service-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-service-v1-core","subsections":[]},{"section":"replace-connect-proxy-service-v1-core","subsections":[]},{"section":"head-connect-proxy-path-service-v1-core","subsections":[]},{"section":"head-connect-proxy-service-v1-core","subsections":[]},{"section":"get-connect-proxy-path-service-v1-core","subsections":[]},{"section":"get-connect-proxy-service-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-service-v1-core","subsections":[]},{"section":"delete-connect-proxy-service-v1-core","subsections":[]},{"section":"create-connect-proxy-path-service-v1-core","subsections":[]},{"section":"create-connect-proxy-service-v1-core","subsections":[]}]},{"section":"-strong-status-operations-service-v1-core-strong-","subsections":[{"section":"replace-status-service-v1-core","subsections":[]},{"section":"read-status-service-v1-core","subsections":[]},{"section":"patch-status-service-v1-core","subsections":[]}]},{"section":"-strong-read-operations-service-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-service-v1-core","subsections":[]},{"section":"watch-list-service-v1-core","subsections":[]},{"section":"watch-service-v1-core","subsections":[]},{"section":"list-all-namespaces-service-v1-core","subsections":[]},{"section":"list-service-v1-core","subsections":[]},{"section":"read-service-v1-core","subsections":[]}]},{"section":"-strong-write-operations-service-v1-core-strong-","subsections":[{"section":"delete-service-v1-core","subsections":[]},{"section":"replace-service-v1-core","subsections":[]},{"section":"patch-service-v1-core","subsections":[]},{"section":"create-service-v1-core","subsections":[]}]}]},{"section":"ingressclass-v1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-ingressclass-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"watch-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"list-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"read-ingressclass-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingressclass-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"delete-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"replace-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"patch-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"create-ingressclass-v1-networking-k8s-io","subsections":[]}]}]},{"section":"ingress-v1-networking-k8s-io","subsections":[{"section":"-strong-status-operations-ingress-v1-networking-k8s-io-strong-","subsections":[{"section":"replace-status-ingress-v1-networking-k8s-io","subsections":[]},{"section":"read-status-ingress-v1-networking-k8s-io","subsections":[]},{"section":"patch-status-ingress-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1-networking-k8s-io","subsections":[]},{"section":"watch-list-ingress-v1-networking-k8s-io","subsections":[]},{"section":"watch-ingress-v1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-ingress-v1-networking-k8s-io","subsections":[]},{"section":"list-ingress-v1-networking-k8s-io","subsections":[]},{"section":"read-ingress-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingress-v1-networking-k8s-io","subsections":[]},{"section":"delete-ingress-v1-networking-k8s-io","subsections":[]},{"section":"replace-ingress-v1-networking-k8s-io","subsections":[]},{"section":"patch-ingress-v1-networking-k8s-io","subsections":[]},{"section":"create-ingress-v1-networking-k8s-io","subsections":[]}]}]},{"section":"endpointslice-v1beta1-discovery-k8s-io","subsections":[{"section":"-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"watch-list-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"watch-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"list-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"read-endpointslice-v1beta1-discovery-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","subsections":[{"section":"delete-collection-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"delete-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"replace-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"patch-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"create-endpointslice-v1beta1-discovery-k8s-io","subsections":[]}]}]},{"section":"endpoints-v1-core","subsections":[{"section":"-strong-read-operations-endpoints-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-endpoints-v1-core","subsections":[]},{"section":"watch-list-endpoints-v1-core","subsections":[]},{"section":"watch-endpoints-v1-core","subsections":[]},{"section":"list-all-namespaces-endpoints-v1-core","subsections":[]},{"section":"list-endpoints-v1-core","subsections":[]},{"section":"read-endpoints-v1-core","subsections":[]}]},{"section":"-strong-write-operations-endpoints-v1-core-strong-","subsections":[{"section":"delete-collection-endpoints-v1-core","subsections":[]},{"section":"delete-endpoints-v1-core","subsections":[]},{"section":"replace-endpoints-v1-core","subsections":[]},{"section":"patch-endpoints-v1-core","subsections":[]},{"section":"create-endpoints-v1-core","subsections":[]}]}]},{"section":"-strong-service-apis-strong-","subsections":[]},{"section":"statefulset-v1-apps","subsections":[{"section":"-strong-misc-operations-statefulset-v1-apps-strong-","subsections":[{"section":"patch-scale-statefulset-v1-apps","subsections":[]},{"section":"replace-scale-statefulset-v1-apps","subsections":[]},{"section":"read-scale-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-statefulset-v1-apps-strong-","subsections":[{"section":"replace-status-statefulset-v1-apps","subsections":[]},{"section":"read-status-statefulset-v1-apps","subsections":[]},{"section":"patch-status-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-statefulset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-statefulset-v1-apps","subsections":[]},{"section":"watch-list-statefulset-v1-apps","subsections":[]},{"section":"watch-statefulset-v1-apps","subsections":[]},{"section":"list-all-namespaces-statefulset-v1-apps","subsections":[]},{"section":"list-statefulset-v1-apps","subsections":[]},{"section":"read-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-statefulset-v1-apps-strong-","subsections":[{"section":"delete-collection-statefulset-v1-apps","subsections":[]},{"section":"delete-statefulset-v1-apps","subsections":[]},{"section":"replace-statefulset-v1-apps","subsections":[]},{"section":"patch-statefulset-v1-apps","subsections":[]},{"section":"create-statefulset-v1-apps","subsections":[]}]}]},{"section":"replicationcontroller-v1-core","subsections":[{"section":"-strong-misc-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"patch-scale-replicationcontroller-v1-core","subsections":[]},{"section":"replace-scale-replicationcontroller-v1-core","subsections":[]},{"section":"read-scale-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-status-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"replace-status-replicationcontroller-v1-core","subsections":[]},{"section":"read-status-replicationcontroller-v1-core","subsections":[]},{"section":"patch-status-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-read-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-replicationcontroller-v1-core","subsections":[]},{"section":"watch-list-replicationcontroller-v1-core","subsections":[]},{"section":"watch-replicationcontroller-v1-core","subsections":[]},{"section":"list-all-namespaces-replicationcontroller-v1-core","subsections":[]},{"section":"list-replicationcontroller-v1-core","subsections":[]},{"section":"read-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-write-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"delete-collection-replicationcontroller-v1-core","subsections":[]},{"section":"delete-replicationcontroller-v1-core","subsections":[]},{"section":"replace-replicationcontroller-v1-core","subsections":[]},{"section":"patch-replicationcontroller-v1-core","subsections":[]},{"section":"create-replicationcontroller-v1-core","subsections":[]}]}]},{"section":"replicaset-v1-apps","subsections":[{"section":"-strong-misc-operations-replicaset-v1-apps-strong-","subsections":[{"section":"patch-scale-replicaset-v1-apps","subsections":[]},{"section":"replace-scale-replicaset-v1-apps","subsections":[]},{"section":"read-scale-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-replicaset-v1-apps-strong-","subsections":[{"section":"replace-status-replicaset-v1-apps","subsections":[]},{"section":"read-status-replicaset-v1-apps","subsections":[]},{"section":"patch-status-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-replicaset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-replicaset-v1-apps","subsections":[]},{"section":"watch-list-replicaset-v1-apps","subsections":[]},{"section":"watch-replicaset-v1-apps","subsections":[]},{"section":"list-all-namespaces-replicaset-v1-apps","subsections":[]},{"section":"list-replicaset-v1-apps","subsections":[]},{"section":"read-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-replicaset-v1-apps-strong-","subsections":[{"section":"delete-collection-replicaset-v1-apps","subsections":[]},{"section":"delete-replicaset-v1-apps","subsections":[]},{"section":"replace-replicaset-v1-apps","subsections":[]},{"section":"patch-replicaset-v1-apps","subsections":[]},{"section":"create-replicaset-v1-apps","subsections":[]}]}]},{"section":"pod-v1-core","subsections":[{"section":"-strong-misc-operations-pod-v1-core-strong-","subsections":[{"section":"read-log-pod-v1-core","subsections":[]}]},{"section":"-strong-proxy-operations-pod-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"replace-connect-proxy-pod-v1-core","subsections":[]},{"section":"head-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"head-connect-proxy-pod-v1-core","subsections":[]},{"section":"get-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"get-connect-proxy-pod-v1-core","subsections":[]},{"section":"get-connect-portforward-pod-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"delete-connect-proxy-pod-v1-core","subsections":[]},{"section":"create-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"create-connect-proxy-pod-v1-core","subsections":[]},{"section":"create-connect-portforward-pod-v1-core","subsections":[]}]},{"section":"-strong-status-operations-pod-v1-core-strong-","subsections":[{"section":"replace-status-pod-v1-core","subsections":[]},{"section":"read-status-pod-v1-core","subsections":[]},{"section":"patch-status-pod-v1-core","subsections":[]}]},{"section":"-strong-read-operations-pod-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-pod-v1-core","subsections":[]},{"section":"watch-list-pod-v1-core","subsections":[]},{"section":"watch-pod-v1-core","subsections":[]},{"section":"list-all-namespaces-pod-v1-core","subsections":[]},{"section":"list-pod-v1-core","subsections":[]},{"section":"read-pod-v1-core","subsections":[]}]},{"section":"-strong-write-operations-pod-v1-core-strong-","subsections":[{"section":"delete-collection-pod-v1-core","subsections":[]},{"section":"delete-pod-v1-core","subsections":[]},{"section":"replace-pod-v1-core","subsections":[]},{"section":"patch-pod-v1-core","subsections":[]},{"section":"create-eviction-pod-v1-core","subsections":[]},{"section":"create-pod-v1-core","subsections":[]}]}]},{"section":"job-v1-batch","subsections":[{"section":"-strong-status-operations-job-v1-batch-strong-","subsections":[{"section":"replace-status-job-v1-batch","subsections":[]},{"section":"read-status-job-v1-batch","subsections":[]},{"section":"patch-status-job-v1-batch","subsections":[]}]},{"section":"-strong-read-operations-job-v1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-job-v1-batch","subsections":[]},{"section":"watch-list-job-v1-batch","subsections":[]},{"section":"watch-job-v1-batch","subsections":[]},{"section":"list-all-namespaces-job-v1-batch","subsections":[]},{"section":"list-job-v1-batch","subsections":[]},{"section":"read-job-v1-batch","subsections":[]}]},{"section":"-strong-write-operations-job-v1-batch-strong-","subsections":[{"section":"delete-collection-job-v1-batch","subsections":[]},{"section":"delete-job-v1-batch","subsections":[]},{"section":"replace-job-v1-batch","subsections":[]},{"section":"patch-job-v1-batch","subsections":[]},{"section":"create-job-v1-batch","subsections":[]}]}]},{"section":"deployment-v1-apps","subsections":[{"section":"-strong-misc-operations-deployment-v1-apps-strong-","subsections":[{"section":"patch-scale-deployment-v1-apps","subsections":[]},{"section":"replace-scale-deployment-v1-apps","subsections":[]},{"section":"read-scale-deployment-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-deployment-v1-apps-strong-","subsections":[{"section":"replace-status-deployment-v1-apps","subsections":[]},{"section":"read-status-deployment-v1-apps","subsections":[]},{"section":"patch-status-deployment-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-deployment-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-deployment-v1-apps","subsections":[]},{"section":"watch-list-deployment-v1-apps","subsections":[]},{"section":"watch-deployment-v1-apps","subsections":[]},{"section":"list-all-namespaces-deployment-v1-apps","subsections":[]},{"section":"list-deployment-v1-apps","subsections":[]},{"section":"read-deployment-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-deployment-v1-apps-strong-","subsections":[{"section":"delete-collection-deployment-v1-apps","subsections":[]},{"section":"delete-deployment-v1-apps","subsections":[]},{"section":"replace-deployment-v1-apps","subsections":[]},{"section":"patch-deployment-v1-apps","subsections":[]},{"section":"create-deployment-v1-apps","subsections":[]}]}]},{"section":"daemonset-v1-apps","subsections":[{"section":"-strong-status-operations-daemonset-v1-apps-strong-","subsections":[{"section":"replace-status-daemonset-v1-apps","subsections":[]},{"section":"read-status-daemonset-v1-apps","subsections":[]},{"section":"patch-status-daemonset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-daemonset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-daemonset-v1-apps","subsections":[]},{"section":"watch-list-daemonset-v1-apps","subsections":[]},{"section":"watch-daemonset-v1-apps","subsections":[]},{"section":"list-all-namespaces-daemonset-v1-apps","subsections":[]},{"section":"list-daemonset-v1-apps","subsections":[]},{"section":"read-daemonset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-daemonset-v1-apps-strong-","subsections":[{"section":"delete-collection-daemonset-v1-apps","subsections":[]},{"section":"delete-daemonset-v1-apps","subsections":[]},{"section":"replace-daemonset-v1-apps","subsections":[]},{"section":"patch-daemonset-v1-apps","subsections":[]},{"section":"create-daemonset-v1-apps","subsections":[]}]}]},{"section":"cronjob-v1beta1-batch","subsections":[{"section":"-strong-status-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"replace-status-cronjob-v1beta1-batch","subsections":[]},{"section":"read-status-cronjob-v1beta1-batch","subsections":[]},{"section":"patch-status-cronjob-v1beta1-batch","subsections":[]}]},{"section":"-strong-read-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-cronjob-v1beta1-batch","subsections":[]},{"section":"watch-list-cronjob-v1beta1-batch","subsections":[]},{"section":"watch-cronjob-v1beta1-batch","subsections":[]},{"section":"list-all-namespaces-cronjob-v1beta1-batch","subsections":[]},{"section":"list-cronjob-v1beta1-batch","subsections":[]},{"section":"read-cronjob-v1beta1-batch","subsections":[]}]},{"section":"-strong-write-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"delete-collection-cronjob-v1beta1-batch","subsections":[]},{"section":"delete-cronjob-v1beta1-batch","subsections":[]},{"section":"replace-cronjob-v1beta1-batch","subsections":[]},{"section":"patch-cronjob-v1beta1-batch","subsections":[]},{"section":"create-cronjob-v1beta1-batch","subsections":[]}]}]},{"section":"container-v1-core","subsections":[]},{"section":"-strong-workloads-apis-strong-","subsections":[]},{"section":"-strong-api-overview-strong-","subsections":[]}],"flatToc":["webhookclientconfig-v1beta1-apiextensions-k8s-io","webhookclientconfig-v1beta1-admissionregistration-k8s-io","webhookclientconfig-v1-apiextensions-k8s-io","volumenoderesources-v1beta1-storage-k8s-io","volumeerror-v1alpha1-storage-k8s-io","volumeerror-v1beta1-storage-k8s-io","volumeattachmentsource-v1alpha1-storage-k8s-io","volumeattachmentsource-v1beta1-storage-k8s-io","watch-list-volumeattachment-v1alpha1-storage-k8s-io","watch-volumeattachment-v1alpha1-storage-k8s-io","list-volumeattachment-v1alpha1-storage-k8s-io","read-volumeattachment-v1alpha1-storage-k8s-io","-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1alpha1-storage-k8s-io","delete-volumeattachment-v1alpha1-storage-k8s-io","replace-volumeattachment-v1alpha1-storage-k8s-io","patch-volumeattachment-v1alpha1-storage-k8s-io","create-volumeattachment-v1alpha1-storage-k8s-io","-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","volumeattachment-v1alpha1-storage-k8s-io","watch-list-volumeattachment-v1beta1-storage-k8s-io","watch-volumeattachment-v1beta1-storage-k8s-io","list-volumeattachment-v1beta1-storage-k8s-io","read-volumeattachment-v1beta1-storage-k8s-io","-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1beta1-storage-k8s-io","delete-volumeattachment-v1beta1-storage-k8s-io","replace-volumeattachment-v1beta1-storage-k8s-io","patch-volumeattachment-v1beta1-storage-k8s-io","create-volumeattachment-v1beta1-storage-k8s-io","-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","volumeattachment-v1beta1-storage-k8s-io","watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","validatingwebhook-v1beta1-admissionregistration-k8s-io","userinfo-v1beta1-authentication-k8s-io","create-tokenreview-v1beta1-authentication-k8s-io","-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-","tokenreview-v1beta1-authentication-k8s-io","subjectrulesreviewstatus-v1beta1-authorization-k8s-io","create-subjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-","subjectaccessreview-v1beta1-authorization-k8s-io","subject-v1alpha1-rbac-authorization-k8s-io","subject-v1beta1-rbac-authorization-k8s-io","subject-v1-rbac-authorization-k8s-io","watch-list-storageclass-v1beta1-storage-k8s-io","watch-storageclass-v1beta1-storage-k8s-io","list-storageclass-v1beta1-storage-k8s-io","read-storageclass-v1beta1-storage-k8s-io","-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-","delete-collection-storageclass-v1beta1-storage-k8s-io","delete-storageclass-v1beta1-storage-k8s-io","replace-storageclass-v1beta1-storage-k8s-io","patch-storageclass-v1beta1-storage-k8s-io","create-storageclass-v1beta1-storage-k8s-io","-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-","storageclass-v1beta1-storage-k8s-io","servicereference-v1beta1-apiregistration-k8s-io","servicereference-v1beta1-apiextensions-k8s-io","servicereference-v1beta1-admissionregistration-k8s-io","servicereference-v1-apiregistration-k8s-io","servicereference-v1-apiextensions-k8s-io","create-selfsubjectrulesreview-v1beta1-authorization-k8s-io","-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-","selfsubjectrulesreview-v1beta1-authorization-k8s-io","create-selfsubjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","selfsubjectaccessreview-v1beta1-authorization-k8s-io","scheduling-v1alpha1-node-k8s-io","watch-list-runtimeclass-v1alpha1-node-k8s-io","watch-runtimeclass-v1alpha1-node-k8s-io","list-runtimeclass-v1alpha1-node-k8s-io","read-runtimeclass-v1alpha1-node-k8s-io","-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","delete-collection-runtimeclass-v1alpha1-node-k8s-io","delete-runtimeclass-v1alpha1-node-k8s-io","replace-runtimeclass-v1alpha1-node-k8s-io","patch-runtimeclass-v1alpha1-node-k8s-io","create-runtimeclass-v1alpha1-node-k8s-io","-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","runtimeclass-v1alpha1-node-k8s-io","rulewithoperations-v1beta1-admissionregistration-k8s-io","roleref-v1alpha1-rbac-authorization-k8s-io","roleref-v1beta1-rbac-authorization-k8s-io","watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-rolebinding-v1alpha1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","list-rolebinding-v1alpha1-rbac-authorization-k8s-io","read-rolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io","delete-rolebinding-v1alpha1-rbac-authorization-k8s-io","replace-rolebinding-v1alpha1-rbac-authorization-k8s-io","patch-rolebinding-v1alpha1-rbac-authorization-k8s-io","create-rolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io","watch-rolebinding-v1beta1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","list-rolebinding-v1beta1-rbac-authorization-k8s-io","read-rolebinding-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io","delete-rolebinding-v1beta1-rbac-authorization-k8s-io","replace-rolebinding-v1beta1-rbac-authorization-k8s-io","patch-rolebinding-v1beta1-rbac-authorization-k8s-io","create-rolebinding-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","rolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","watch-list-role-v1alpha1-rbac-authorization-k8s-io","watch-role-v1alpha1-rbac-authorization-k8s-io","list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","list-role-v1alpha1-rbac-authorization-k8s-io","read-role-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1alpha1-rbac-authorization-k8s-io","delete-role-v1alpha1-rbac-authorization-k8s-io","replace-role-v1alpha1-rbac-authorization-k8s-io","patch-role-v1alpha1-rbac-authorization-k8s-io","create-role-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","role-v1alpha1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","watch-list-role-v1beta1-rbac-authorization-k8s-io","watch-role-v1beta1-rbac-authorization-k8s-io","list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","list-role-v1beta1-rbac-authorization-k8s-io","read-role-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1beta1-rbac-authorization-k8s-io","delete-role-v1beta1-rbac-authorization-k8s-io","replace-role-v1beta1-rbac-authorization-k8s-io","patch-role-v1beta1-rbac-authorization-k8s-io","create-role-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","role-v1beta1-rbac-authorization-k8s-io","resourcerule-v1beta1-authorization-k8s-io","resourcemetricstatus-v2beta1-autoscaling","resourcemetricsource-v2beta1-autoscaling","resourceattributes-v1beta1-authorization-k8s-io","watch-list-priorityclass-v1alpha1-scheduling-k8s-io","watch-priorityclass-v1alpha1-scheduling-k8s-io","list-priorityclass-v1alpha1-scheduling-k8s-io","read-priorityclass-v1alpha1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1alpha1-scheduling-k8s-io","delete-priorityclass-v1alpha1-scheduling-k8s-io","replace-priorityclass-v1alpha1-scheduling-k8s-io","patch-priorityclass-v1alpha1-scheduling-k8s-io","create-priorityclass-v1alpha1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","priorityclass-v1alpha1-scheduling-k8s-io","watch-list-priorityclass-v1beta1-scheduling-k8s-io","watch-priorityclass-v1beta1-scheduling-k8s-io","list-priorityclass-v1beta1-scheduling-k8s-io","read-priorityclass-v1beta1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1beta1-scheduling-k8s-io","delete-priorityclass-v1beta1-scheduling-k8s-io","replace-priorityclass-v1beta1-scheduling-k8s-io","patch-priorityclass-v1beta1-scheduling-k8s-io","create-priorityclass-v1beta1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","priorityclass-v1beta1-scheduling-k8s-io","policyrule-v1alpha1-rbac-authorization-k8s-io","policyrule-v1beta1-rbac-authorization-k8s-io","podsmetricstatus-v2beta1-autoscaling","podsmetricsource-v2beta1-autoscaling","overhead-v1alpha1-node-k8s-io","objectmetricstatus-v2beta1-autoscaling","objectmetricsource-v2beta1-autoscaling","nonresourcerule-v1beta1-authorization-k8s-io","nonresourceattributes-v1beta1-authorization-k8s-io","watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","mutatingwebhook-v1beta1-admissionregistration-k8s-io","metricstatus-v2beta1-autoscaling","metricspec-v2beta1-autoscaling","create-localsubjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","localsubjectaccessreview-v1beta1-authorization-k8s-io","watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io","watch-list-lease-v1beta1-coordination-k8s-io","watch-lease-v1beta1-coordination-k8s-io","list-all-namespaces-lease-v1beta1-coordination-k8s-io","list-lease-v1beta1-coordination-k8s-io","read-lease-v1beta1-coordination-k8s-io","-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-","delete-collection-lease-v1beta1-coordination-k8s-io","delete-lease-v1beta1-coordination-k8s-io","replace-lease-v1beta1-coordination-k8s-io","patch-lease-v1beta1-coordination-k8s-io","create-lease-v1beta1-coordination-k8s-io","-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-","lease-v1beta1-coordination-k8s-io","jobtemplatespec-v2alpha1-batch","jsonschemapropsorbool-v1beta1-apiextensions-k8s-io","jsonschemapropsorarray-v1beta1-apiextensions-k8s-io","jsonschemaprops-v1beta1-apiextensions-k8s-io","json-v1beta1-apiextensions-k8s-io","ingresstls-v1beta1-networking-k8s-io","ingresstls-v1beta1-extensions","ingressrule-v1beta1-networking-k8s-io","ingressrule-v1beta1-extensions","watch-list-ingressclass-v1beta1-networking-k8s-io","watch-ingressclass-v1beta1-networking-k8s-io","list-ingressclass-v1beta1-networking-k8s-io","read-ingressclass-v1beta1-networking-k8s-io","-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-","delete-collection-ingressclass-v1beta1-networking-k8s-io","delete-ingressclass-v1beta1-networking-k8s-io","replace-ingressclass-v1beta1-networking-k8s-io","patch-ingressclass-v1beta1-networking-k8s-io","create-ingressclass-v1beta1-networking-k8s-io","-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-","ingressclass-v1beta1-networking-k8s-io","ingressbackend-v1beta1-networking-k8s-io","ingressbackend-v1beta1-extensions","replace-status-ingress-v1beta1-networking-k8s-io","read-status-ingress-v1beta1-networking-k8s-io","patch-status-ingress-v1beta1-networking-k8s-io","-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-","watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io","watch-list-ingress-v1beta1-networking-k8s-io","watch-ingress-v1beta1-networking-k8s-io","list-all-namespaces-ingress-v1beta1-networking-k8s-io","list-ingress-v1beta1-networking-k8s-io","read-ingress-v1beta1-networking-k8s-io","-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-","delete-collection-ingress-v1beta1-networking-k8s-io","delete-ingress-v1beta1-networking-k8s-io","replace-ingress-v1beta1-networking-k8s-io","patch-ingress-v1beta1-networking-k8s-io","create-ingress-v1beta1-networking-k8s-io","-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-","ingress-v1beta1-networking-k8s-io","replace-status-ingress-v1beta1-extensions","read-status-ingress-v1beta1-extensions","patch-status-ingress-v1beta1-extensions","-strong-status-operations-ingress-v1beta1-extensions-strong-","watch-list-all-namespaces-ingress-v1beta1-extensions","watch-list-ingress-v1beta1-extensions","watch-ingress-v1beta1-extensions","list-all-namespaces-ingress-v1beta1-extensions","list-ingress-v1beta1-extensions","read-ingress-v1beta1-extensions","-strong-read-operations-ingress-v1beta1-extensions-strong-","delete-collection-ingress-v1beta1-extensions","delete-ingress-v1beta1-extensions","replace-ingress-v1beta1-extensions","patch-ingress-v1beta1-extensions","create-ingress-v1beta1-extensions","-strong-write-operations-ingress-v1beta1-extensions-strong-","ingress-v1beta1-extensions","horizontalpodautoscalercondition-v2beta1-autoscaling","replace-status-horizontalpodautoscaler-v2beta1-autoscaling","read-status-horizontalpodautoscaler-v2beta1-autoscaling","patch-status-horizontalpodautoscaler-v2beta1-autoscaling","-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","watch-list-horizontalpodautoscaler-v2beta1-autoscaling","watch-horizontalpodautoscaler-v2beta1-autoscaling","list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","list-horizontalpodautoscaler-v2beta1-autoscaling","read-horizontalpodautoscaler-v2beta1-autoscaling","-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v2beta1-autoscaling","delete-horizontalpodautoscaler-v2beta1-autoscaling","replace-horizontalpodautoscaler-v2beta1-autoscaling","patch-horizontalpodautoscaler-v2beta1-autoscaling","create-horizontalpodautoscaler-v2beta1-autoscaling","-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","horizontalpodautoscaler-v2beta1-autoscaling","replace-status-horizontalpodautoscaler-v2beta2-autoscaling","read-status-horizontalpodautoscaler-v2beta2-autoscaling","patch-status-horizontalpodautoscaler-v2beta2-autoscaling","-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","watch-list-horizontalpodautoscaler-v2beta2-autoscaling","watch-horizontalpodautoscaler-v2beta2-autoscaling","list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","list-horizontalpodautoscaler-v2beta2-autoscaling","read-horizontalpodautoscaler-v2beta2-autoscaling","-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v2beta2-autoscaling","delete-horizontalpodautoscaler-v2beta2-autoscaling","replace-horizontalpodautoscaler-v2beta2-autoscaling","patch-horizontalpodautoscaler-v2beta2-autoscaling","create-horizontalpodautoscaler-v2beta2-autoscaling","-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","horizontalpodautoscaler-v2beta2-autoscaling","httpingressrulevalue-v1beta1-networking-k8s-io","httpingressrulevalue-v1beta1-extensions","httpingresspath-v1beta1-networking-k8s-io","httpingresspath-v1beta1-extensions","externalmetricstatus-v2beta1-autoscaling","externalmetricsource-v2beta1-autoscaling","externaldocumentation-v1beta1-apiextensions-k8s-io","eventseries-v1beta1-events-k8s-io","eventseries-v1-events-k8s-io","watch-list-all-namespaces-event-v1beta1-events-k8s-io","watch-list-event-v1beta1-events-k8s-io","watch-event-v1beta1-events-k8s-io","list-all-namespaces-event-v1beta1-events-k8s-io","list-event-v1beta1-events-k8s-io","read-event-v1beta1-events-k8s-io","-strong-read-operations-event-v1beta1-events-k8s-io-strong-","delete-collection-event-v1beta1-events-k8s-io","delete-event-v1beta1-events-k8s-io","replace-event-v1beta1-events-k8s-io","patch-event-v1beta1-events-k8s-io","create-event-v1beta1-events-k8s-io","-strong-write-operations-event-v1beta1-events-k8s-io-strong-","event-v1beta1-events-k8s-io","watch-list-all-namespaces-event-v1-events-k8s-io","watch-list-event-v1-events-k8s-io","watch-event-v1-events-k8s-io","list-all-namespaces-event-v1-events-k8s-io","list-event-v1-events-k8s-io","read-event-v1-events-k8s-io","-strong-read-operations-event-v1-events-k8s-io-strong-","delete-collection-event-v1-events-k8s-io","delete-event-v1-events-k8s-io","replace-event-v1-events-k8s-io","patch-event-v1-events-k8s-io","create-event-v1-events-k8s-io","-strong-write-operations-event-v1-events-k8s-io-strong-","event-v1-events-k8s-io","endpointport-v1beta1-discovery-k8s-io","customresourcevalidation-v1beta1-apiextensions-k8s-io","customresourcesubresources-v1beta1-apiextensions-k8s-io","customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io","customresourcesubresourcescale-v1beta1-apiextensions-k8s-io","customresourcedefinitionversion-v1beta1-apiextensions-k8s-io","customresourcedefinitionnames-v1beta1-apiextensions-k8s-io","customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io","replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io","watch-customresourcedefinition-v1beta1-apiextensions-k8s-io","list-customresourcedefinition-v1beta1-apiextensions-k8s-io","read-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io","delete-customresourcedefinition-v1beta1-apiextensions-k8s-io","replace-customresourcedefinition-v1beta1-apiextensions-k8s-io","patch-customresourcedefinition-v1beta1-apiextensions-k8s-io","create-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","customresourcedefinition-v1beta1-apiextensions-k8s-io","customresourceconversion-v1beta1-apiextensions-k8s-io","customresourcecolumndefinition-v1beta1-apiextensions-k8s-io","crossversionobjectreference-v2beta1-autoscaling","crossversionobjectreference-v2beta2-autoscaling","replace-status-cronjob-v2alpha1-batch","read-status-cronjob-v2alpha1-batch","patch-status-cronjob-v2alpha1-batch","-strong-status-operations-cronjob-v2alpha1-batch-strong-","watch-list-all-namespaces-cronjob-v2alpha1-batch","watch-list-cronjob-v2alpha1-batch","watch-cronjob-v2alpha1-batch","list-all-namespaces-cronjob-v2alpha1-batch","list-cronjob-v2alpha1-batch","read-cronjob-v2alpha1-batch","-strong-read-operations-cronjob-v2alpha1-batch-strong-","delete-collection-cronjob-v2alpha1-batch","delete-cronjob-v2alpha1-batch","replace-cronjob-v2alpha1-batch","patch-cronjob-v2alpha1-batch","create-cronjob-v2alpha1-batch","-strong-write-operations-cronjob-v2alpha1-batch-strong-","cronjob-v2alpha1-batch","watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io","watch-clusterrole-v1alpha1-rbac-authorization-k8s-io","list-clusterrole-v1alpha1-rbac-authorization-k8s-io","read-clusterrole-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io","delete-clusterrole-v1alpha1-rbac-authorization-k8s-io","replace-clusterrole-v1alpha1-rbac-authorization-k8s-io","patch-clusterrole-v1alpha1-rbac-authorization-k8s-io","create-clusterrole-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","clusterrole-v1alpha1-rbac-authorization-k8s-io","watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io","watch-clusterrole-v1beta1-rbac-authorization-k8s-io","list-clusterrole-v1beta1-rbac-authorization-k8s-io","read-clusterrole-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io","delete-clusterrole-v1beta1-rbac-authorization-k8s-io","replace-clusterrole-v1beta1-rbac-authorization-k8s-io","patch-clusterrole-v1beta1-rbac-authorization-k8s-io","create-clusterrole-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","clusterrole-v1beta1-rbac-authorization-k8s-io","certificatesigningrequestcondition-v1beta1-certificates-k8s-io","replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io","read-status-certificatesigningrequest-v1beta1-certificates-k8s-io","patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io","watch-certificatesigningrequest-v1beta1-certificates-k8s-io","list-certificatesigningrequest-v1beta1-certificates-k8s-io","read-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io","delete-certificatesigningrequest-v1beta1-certificates-k8s-io","replace-certificatesigningrequest-v1beta1-certificates-k8s-io","patch-certificatesigningrequest-v1beta1-certificates-k8s-io","create-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","certificatesigningrequest-v1beta1-certificates-k8s-io","csinodedriver-v1beta1-storage-k8s-io","watch-list-csinode-v1beta1-storage-k8s-io","watch-csinode-v1beta1-storage-k8s-io","list-csinode-v1beta1-storage-k8s-io","read-csinode-v1beta1-storage-k8s-io","-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-","delete-collection-csinode-v1beta1-storage-k8s-io","delete-csinode-v1beta1-storage-k8s-io","replace-csinode-v1beta1-storage-k8s-io","patch-csinode-v1beta1-storage-k8s-io","create-csinode-v1beta1-storage-k8s-io","-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-","csinode-v1beta1-storage-k8s-io","watch-list-csidriver-v1beta1-storage-k8s-io","watch-csidriver-v1beta1-storage-k8s-io","list-csidriver-v1beta1-storage-k8s-io","read-csidriver-v1beta1-storage-k8s-io","-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-","delete-collection-csidriver-v1beta1-storage-k8s-io","delete-csidriver-v1beta1-storage-k8s-io","replace-csidriver-v1beta1-storage-k8s-io","patch-csidriver-v1beta1-storage-k8s-io","create-csidriver-v1beta1-storage-k8s-io","-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-","csidriver-v1beta1-storage-k8s-io","aggregationrule-v1alpha1-rbac-authorization-k8s-io","aggregationrule-v1beta1-rbac-authorization-k8s-io","apiservicecondition-v1beta1-apiregistration-k8s-io","replace-status-apiservice-v1beta1-apiregistration-k8s-io","read-status-apiservice-v1beta1-apiregistration-k8s-io","patch-status-apiservice-v1beta1-apiregistration-k8s-io","-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","watch-list-apiservice-v1beta1-apiregistration-k8s-io","watch-apiservice-v1beta1-apiregistration-k8s-io","list-apiservice-v1beta1-apiregistration-k8s-io","read-apiservice-v1beta1-apiregistration-k8s-io","-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","delete-collection-apiservice-v1beta1-apiregistration-k8s-io","delete-apiservice-v1beta1-apiregistration-k8s-io","replace-apiservice-v1beta1-apiregistration-k8s-io","patch-apiservice-v1beta1-apiregistration-k8s-io","create-apiservice-v1beta1-apiregistration-k8s-io","-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","apiservice-v1beta1-apiregistration-k8s-io","-strong-old-api-versions-strong-","windowssecuritycontextoptions-v1-core","weightedpodaffinityterm-v1-core","webhookconversion-v1-apiextensions-k8s-io","webhookclientconfig-v1-admissionregistration-k8s-io","watchevent-v1-meta","vspherevirtualdiskvolumesource-v1-core","volumeprojection-v1-core","volumenoderesources-v1-storage-k8s-io","volumenodeaffinity-v1-core","volumemount-v1-core","volumeerror-v1-storage-k8s-io","volumedevice-v1-core","volumeattachmentsource-v1-storage-k8s-io","validatingwebhook-v1-admissionregistration-k8s-io","usersubject-v1alpha1-flowcontrol-apiserver-k8s-io","userinfo-v1-authentication-k8s-io","typedlocalobjectreference-v1-core","topologyspreadconstraint-v1-core","topologyselectorterm-v1-core","topologyselectorlabelrequirement-v1-core","toleration-v1-core","time-v1-meta","taint-v1-core","tcpsocketaction-v1-core","sysctl-v1-core","supplementalgroupsstrategyoptions-v1beta1-policy","subjectrulesreviewstatus-v1-authorization-k8s-io","subject-v1alpha1-flowcontrol-apiserver-k8s-io","storageosvolumesource-v1-core","storageospersistentvolumesource-v1-core","statusdetails-v1-meta","statuscause-v1-meta","status-v1-meta","statefulsetupdatestrategy-v1-apps","statefulsetcondition-v1-apps","sessionaffinityconfig-v1-core","servicereference-v1-admissionregistration-k8s-io","serviceport-v1-core","servicebackendport-v1-networking-k8s-io","serviceaccounttokenprojection-v1-core","serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io","serveraddressbyclientcidr-v1-meta","securitycontext-v1-core","secretvolumesource-v1-core","secretreference-v1-core","secretprojection-v1-core","secretkeyselector-v1-core","secretenvsource-v1-core","seccompprofile-v1-core","scopedresourceselectorrequirement-v1-core","scopeselector-v1-core","scheduling-v1beta1-node-k8s-io","scaleiovolumesource-v1-core","scaleiopersistentvolumesource-v1-core","scale-v1-autoscaling","selinuxstrategyoptions-v1beta1-policy","selinuxoptions-v1-core","runtimeclassstrategyoptions-v1beta1-policy","runasuserstrategyoptions-v1beta1-policy","runasgroupstrategyoptions-v1beta1-policy","rulewithoperations-v1-admissionregistration-k8s-io","rollingupdatestatefulsetstrategy-v1-apps","roleref-v1-rbac-authorization-k8s-io","resourcerule-v1-authorization-k8s-io","resourcerequirements-v1-core","resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","resourcemetricstatus-v2beta2-autoscaling","resourcemetricsource-v2beta2-autoscaling","resourcefieldselector-v1-core","resourceattributes-v1-authorization-k8s-io","replicationcontrollercondition-v1-core","replicasetcondition-v1-apps","rbdvolumesource-v1-core","rbdpersistentvolumesource-v1-core","quobytevolumesource-v1-core","queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","quantity-resource-core","projectedvolumesource-v1-core","probe-v1-core","prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io","prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io","preferredschedulingterm-v1-core","preconditions-v1-meta","portworxvolumesource-v1-core","policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io","policyrule-v1-rbac-authorization-k8s-io","podsmetricstatus-v2beta2-autoscaling","podsmetricsource-v2beta2-autoscaling","podsecuritycontext-v1-core","podreadinessgate-v1-core","podip-v1-core","poddnsconfigoption-v1-core","poddnsconfig-v1-core","podcondition-v1-core","podantiaffinity-v1-core","podaffinityterm-v1-core","podaffinity-v1-core","photonpersistentdiskvolumesource-v1-core","persistentvolumeclaimvolumesource-v1-core","persistentvolumeclaimtemplate-v1-core","persistentvolumeclaimcondition-v1-core","patch-v1-meta","ownerreference-v1-meta","overhead-v1beta1-node-k8s-io","objectreference-v1-core","objectmetricstatus-v2beta2-autoscaling","objectmetricsource-v2beta2-autoscaling","objectmeta-v1-meta","objectfieldselector-v1-core","nonresourcerule-v1-authorization-k8s-io","nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","nonresourceattributes-v1-authorization-k8s-io","nodesysteminfo-v1-core","nodeselectorterm-v1-core","nodeselectorrequirement-v1-core","nodeselector-v1-core","nodedaemonendpoints-v1-core","nodeconfigstatus-v1-core","nodeconfigsource-v1-core","nodecondition-v1-core","nodeaffinity-v1-core","nodeaddress-v1-core","networkpolicyport-v1-networking-k8s-io","networkpolicypeer-v1-networking-k8s-io","networkpolicyingressrule-v1-networking-k8s-io","networkpolicyegressrule-v1-networking-k8s-io","namespacecondition-v1-core","nfsvolumesource-v1-core","mutatingwebhook-v1-admissionregistration-k8s-io","microtime-v1-meta","metricvaluestatus-v2beta2-autoscaling","metrictarget-v2beta2-autoscaling","metricstatus-v2beta2-autoscaling","metricspec-v2beta2-autoscaling","metricidentifier-v2beta2-autoscaling","managedfieldsentry-v1-meta","localvolumesource-v1-core","localobjectreference-v1-core","loadbalancerstatus-v1-core","loadbalanceringress-v1-core","listmeta-v1-meta","limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io","limitrangeitem-v1-core","lifecycle-v1-core","labelselectorrequirement-v1-meta","labelselector-v1-meta","keytopath-v1-core","jobtemplatespec-v1beta1-batch","jobcondition-v1-batch","jsonschemapropsorbool-v1-apiextensions-k8s-io","jsonschemapropsorarray-v1-apiextensions-k8s-io","jsonschemaprops-v1-apiextensions-k8s-io","json-v1-apiextensions-k8s-io","ingresstls-v1-networking-k8s-io","ingressservicebackend-v1-networking-k8s-io","ingressrule-v1-networking-k8s-io","ingressbackend-v1-networking-k8s-io","iscsivolumesource-v1-core","iscsipersistentvolumesource-v1-core","ipblock-v1-networking-k8s-io","idrange-v1beta1-policy","hostportrange-v1beta1-policy","hostpathvolumesource-v1-core","hostalias-v1-core","horizontalpodautoscalercondition-v2beta2-autoscaling","horizontalpodautoscalerbehavior-v2beta2-autoscaling","handler-v1-core","httpingressrulevalue-v1-networking-k8s-io","httpingresspath-v1-networking-k8s-io","httpheader-v1-core","httpgetaction-v1-core","hpascalingrules-v2beta2-autoscaling","hpascalingpolicy-v2beta2-autoscaling","groupversionfordiscovery-v1-meta","groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io","glusterfsvolumesource-v1-core","glusterfspersistentvolumesource-v1-core","gitrepovolumesource-v1-core","gcepersistentdiskvolumesource-v1-core","flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io","flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io","flockervolumesource-v1-core","flexvolumesource-v1-core","flexpersistentvolumesource-v1-core","fieldsv1-v1-meta","fsgroupstrategyoptions-v1beta1-policy","fcvolumesource-v1-core","externalmetricstatus-v2beta2-autoscaling","externalmetricsource-v2beta2-autoscaling","externaldocumentation-v1-apiextensions-k8s-io","execaction-v1-core","eviction-v1beta1-policy","eventsource-v1-core","eventseries-v1-core","ephemeralvolumesource-v1-core","ephemeralcontainer-v1-core","envvarsource-v1-core","envvar-v1-core","envfromsource-v1-core","endpointsubset-v1-core","endpointport-v1-core","endpointconditions-v1beta1-discovery-k8s-io","endpointaddress-v1-core","endpoint-v1beta1-discovery-k8s-io","emptydirvolumesource-v1-core","downwardapivolumesource-v1-core","downwardapivolumefile-v1-core","downwardapiprojection-v1-core","deploymentcondition-v1-apps","deleteoptions-v1-meta","daemonsetupdatestrategy-v1-apps","daemonsetcondition-v1-apps","daemonendpoint-v1-core","customresourcevalidation-v1-apiextensions-k8s-io","customresourcesubresources-v1-apiextensions-k8s-io","customresourcesubresourcestatus-v1-apiextensions-k8s-io","customresourcesubresourcescale-v1-apiextensions-k8s-io","customresourcedefinitionversion-v1-apiextensions-k8s-io","customresourcedefinitionnames-v1-apiextensions-k8s-io","customresourcedefinitioncondition-v1-apiextensions-k8s-io","customresourceconversion-v1-apiextensions-k8s-io","customresourcecolumndefinition-v1-apiextensions-k8s-io","crossversionobjectreference-v1-autoscaling","containerstatewaiting-v1-core","containerstateterminated-v1-core","containerstaterunning-v1-core","containerstate-v1-core","containerport-v1-core","containerimage-v1-core","configmapvolumesource-v1-core","configmapprojection-v1-core","configmapnodeconfigsource-v1-core","configmapkeyselector-v1-core","configmapenvsource-v1-core","componentcondition-v1-core","clientipconfig-v1-core","cindervolumesource-v1-core","cinderpersistentvolumesource-v1-core","certificatesigningrequestcondition-v1-certificates-k8s-io","cephfsvolumesource-v1-core","cephfspersistentvolumesource-v1-core","capabilities-v1-core","csivolumesource-v1-core","csipersistentvolumesource-v1-core","csinodedriver-v1-storage-k8s-io","boundobjectreference-v1-authentication-k8s-io","azurefilevolumesource-v1-core","azurefilepersistentvolumesource-v1-core","azurediskvolumesource-v1-core","attachedvolume-v1-core","allowedhostpath-v1beta1-policy","allowedflexvolume-v1beta1-policy","allowedcsidriver-v1beta1-policy","aggregationrule-v1-rbac-authorization-k8s-io","affinity-v1-core","awselasticblockstorevolumesource-v1-core","apiversions-v1-meta","apiservicecondition-v1-apiregistration-k8s-io","apiresource-v1-meta","apigroup-v1-meta","-strong-definitions-strong-","watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io","watch-list-networkpolicy-v1-networking-k8s-io","watch-networkpolicy-v1-networking-k8s-io","list-all-namespaces-networkpolicy-v1-networking-k8s-io","list-networkpolicy-v1-networking-k8s-io","read-networkpolicy-v1-networking-k8s-io","-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-","delete-collection-networkpolicy-v1-networking-k8s-io","delete-networkpolicy-v1-networking-k8s-io","replace-networkpolicy-v1-networking-k8s-io","patch-networkpolicy-v1-networking-k8s-io","create-networkpolicy-v1-networking-k8s-io","-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-","networkpolicy-v1-networking-k8s-io","create-tokenreview-v1-authentication-k8s-io","-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-","tokenreview-v1-authentication-k8s-io","tokenrequest-v1-authentication-k8s-io","create-subjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-","subjectaccessreview-v1-authorization-k8s-io","watch-list-all-namespaces-serviceaccount-v1-core","watch-list-serviceaccount-v1-core","watch-serviceaccount-v1-core","list-all-namespaces-serviceaccount-v1-core","list-serviceaccount-v1-core","read-serviceaccount-v1-core","-strong-read-operations-serviceaccount-v1-core-strong-","delete-collection-serviceaccount-v1-core","delete-serviceaccount-v1-core","replace-serviceaccount-v1-core","patch-serviceaccount-v1-core","create-serviceaccount-v1-core","-strong-write-operations-serviceaccount-v1-core-strong-","serviceaccount-v1-core","create-selfsubjectrulesreview-v1-authorization-k8s-io","-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-","selfsubjectrulesreview-v1-authorization-k8s-io","create-selfsubjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-","selfsubjectaccessreview-v1-authorization-k8s-io","watch-list-runtimeclass-v1beta1-node-k8s-io","watch-runtimeclass-v1beta1-node-k8s-io","list-runtimeclass-v1beta1-node-k8s-io","read-runtimeclass-v1beta1-node-k8s-io","-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-","delete-collection-runtimeclass-v1beta1-node-k8s-io","delete-runtimeclass-v1beta1-node-k8s-io","replace-runtimeclass-v1beta1-node-k8s-io","patch-runtimeclass-v1beta1-node-k8s-io","create-runtimeclass-v1beta1-node-k8s-io","-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-","runtimeclass-v1beta1-node-k8s-io","watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","watch-list-rolebinding-v1-rbac-authorization-k8s-io","watch-rolebinding-v1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","list-rolebinding-v1-rbac-authorization-k8s-io","read-rolebinding-v1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1-rbac-authorization-k8s-io","delete-rolebinding-v1-rbac-authorization-k8s-io","replace-rolebinding-v1-rbac-authorization-k8s-io","patch-rolebinding-v1-rbac-authorization-k8s-io","create-rolebinding-v1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","rolebinding-v1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io","watch-list-role-v1-rbac-authorization-k8s-io","watch-role-v1-rbac-authorization-k8s-io","list-all-namespaces-role-v1-rbac-authorization-k8s-io","list-role-v1-rbac-authorization-k8s-io","read-role-v1-rbac-authorization-k8s-io","-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1-rbac-authorization-k8s-io","delete-role-v1-rbac-authorization-k8s-io","replace-role-v1-rbac-authorization-k8s-io","patch-role-v1-rbac-authorization-k8s-io","create-role-v1-rbac-authorization-k8s-io","-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-","role-v1-rbac-authorization-k8s-io","replace-status-resourcequota-v1-core","read-status-resourcequota-v1-core","patch-status-resourcequota-v1-core","-strong-status-operations-resourcequota-v1-core-strong-","watch-list-all-namespaces-resourcequota-v1-core","watch-list-resourcequota-v1-core","watch-resourcequota-v1-core","list-all-namespaces-resourcequota-v1-core","list-resourcequota-v1-core","read-resourcequota-v1-core","-strong-read-operations-resourcequota-v1-core-strong-","delete-collection-resourcequota-v1-core","delete-resourcequota-v1-core","replace-resourcequota-v1-core","patch-resourcequota-v1-core","create-resourcequota-v1-core","-strong-write-operations-resourcequota-v1-core-strong-","resourcequota-v1-core","replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","replace-status-persistentvolume-v1-core","read-status-persistentvolume-v1-core","patch-status-persistentvolume-v1-core","-strong-status-operations-persistentvolume-v1-core-strong-","watch-list-persistentvolume-v1-core","watch-persistentvolume-v1-core","list-persistentvolume-v1-core","read-persistentvolume-v1-core","-strong-read-operations-persistentvolume-v1-core-strong-","delete-collection-persistentvolume-v1-core","delete-persistentvolume-v1-core","replace-persistentvolume-v1-core","patch-persistentvolume-v1-core","create-persistentvolume-v1-core","-strong-write-operations-persistentvolume-v1-core-strong-","persistentvolume-v1-core","replace-connect-proxy-path-node-v1-core","replace-connect-proxy-node-v1-core","head-connect-proxy-path-node-v1-core","head-connect-proxy-node-v1-core","get-connect-proxy-path-node-v1-core","get-connect-proxy-node-v1-core","delete-connect-proxy-path-node-v1-core","delete-connect-proxy-node-v1-core","create-connect-proxy-path-node-v1-core","create-connect-proxy-node-v1-core","-strong-proxy-operations-node-v1-core-strong-","replace-status-node-v1-core","read-status-node-v1-core","patch-status-node-v1-core","-strong-status-operations-node-v1-core-strong-","watch-list-node-v1-core","watch-node-v1-core","list-node-v1-core","read-node-v1-core","-strong-read-operations-node-v1-core-strong-","delete-collection-node-v1-core","delete-node-v1-core","replace-node-v1-core","patch-node-v1-core","create-node-v1-core","-strong-write-operations-node-v1-core-strong-","node-v1-core","replace-status-namespace-v1-core","read-status-namespace-v1-core","patch-status-namespace-v1-core","-strong-status-operations-namespace-v1-core-strong-","watch-list-namespace-v1-core","watch-namespace-v1-core","list-namespace-v1-core","read-namespace-v1-core","-strong-read-operations-namespace-v1-core-strong-","delete-namespace-v1-core","replace-namespace-v1-core","patch-namespace-v1-core","create-namespace-v1-core","-strong-write-operations-namespace-v1-core-strong-","namespace-v1-core","create-localsubjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-","localsubjectaccessreview-v1-authorization-k8s-io","watch-list-all-namespaces-lease-v1-coordination-k8s-io","watch-list-lease-v1-coordination-k8s-io","watch-lease-v1-coordination-k8s-io","list-all-namespaces-lease-v1-coordination-k8s-io","list-lease-v1-coordination-k8s-io","read-lease-v1-coordination-k8s-io","-strong-read-operations-lease-v1-coordination-k8s-io-strong-","delete-collection-lease-v1-coordination-k8s-io","delete-lease-v1-coordination-k8s-io","replace-lease-v1-coordination-k8s-io","patch-lease-v1-coordination-k8s-io","create-lease-v1-coordination-k8s-io","-strong-write-operations-lease-v1-coordination-k8s-io-strong-","lease-v1-coordination-k8s-io","replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","list-componentstatus-v1-core","read-componentstatus-v1-core","-strong-read-operations-componentstatus-v1-core-strong-","componentstatus-v1-core","watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1-rbac-authorization-k8s-io","list-clusterrolebinding-v1-rbac-authorization-k8s-io","read-clusterrolebinding-v1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1-rbac-authorization-k8s-io","create-clusterrolebinding-v1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1-rbac-authorization-k8s-io","watch-list-clusterrole-v1-rbac-authorization-k8s-io","watch-clusterrole-v1-rbac-authorization-k8s-io","list-clusterrole-v1-rbac-authorization-k8s-io","read-clusterrole-v1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1-rbac-authorization-k8s-io","delete-clusterrole-v1-rbac-authorization-k8s-io","replace-clusterrole-v1-rbac-authorization-k8s-io","patch-clusterrole-v1-rbac-authorization-k8s-io","create-clusterrole-v1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","clusterrole-v1-rbac-authorization-k8s-io","replace-status-certificatesigningrequest-v1-certificates-k8s-io","read-status-certificatesigningrequest-v1-certificates-k8s-io","patch-status-certificatesigningrequest-v1-certificates-k8s-io","-strong-status-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","watch-list-certificatesigningrequest-v1-certificates-k8s-io","watch-certificatesigningrequest-v1-certificates-k8s-io","list-certificatesigningrequest-v1-certificates-k8s-io","read-certificatesigningrequest-v1-certificates-k8s-io","-strong-read-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","delete-collection-certificatesigningrequest-v1-certificates-k8s-io","delete-certificatesigningrequest-v1-certificates-k8s-io","replace-certificatesigningrequest-v1-certificates-k8s-io","patch-certificatesigningrequest-v1-certificates-k8s-io","create-certificatesigningrequest-v1-certificates-k8s-io","-strong-write-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","certificatesigningrequest-v1-certificates-k8s-io","create-binding-v1-core","-strong-write-operations-binding-v1-core-strong-","binding-v1-core","replace-status-apiservice-v1-apiregistration-k8s-io","read-status-apiservice-v1-apiregistration-k8s-io","patch-status-apiservice-v1-apiregistration-k8s-io","-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-","watch-list-apiservice-v1-apiregistration-k8s-io","watch-apiservice-v1-apiregistration-k8s-io","list-apiservice-v1-apiregistration-k8s-io","read-apiservice-v1-apiregistration-k8s-io","-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-","delete-collection-apiservice-v1-apiregistration-k8s-io","delete-apiservice-v1-apiregistration-k8s-io","replace-apiservice-v1-apiregistration-k8s-io","patch-apiservice-v1-apiregistration-k8s-io","create-apiservice-v1-apiregistration-k8s-io","-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-","apiservice-v1-apiregistration-k8s-io","-strong-cluster-apis-strong-","watch-list-podsecuritypolicy-v1beta1-policy","watch-podsecuritypolicy-v1beta1-policy","list-podsecuritypolicy-v1beta1-policy","read-podsecuritypolicy-v1beta1-policy","-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-","delete-collection-podsecuritypolicy-v1beta1-policy","delete-podsecuritypolicy-v1beta1-policy","replace-podsecuritypolicy-v1beta1-policy","patch-podsecuritypolicy-v1beta1-policy","create-podsecuritypolicy-v1beta1-policy","-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-","podsecuritypolicy-v1beta1-policy","watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","watch-list-podpreset-v1alpha1-settings-k8s-io","watch-podpreset-v1alpha1-settings-k8s-io","list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","list-podpreset-v1alpha1-settings-k8s-io","read-podpreset-v1alpha1-settings-k8s-io","-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-","delete-collection-podpreset-v1alpha1-settings-k8s-io","delete-podpreset-v1alpha1-settings-k8s-io","replace-podpreset-v1alpha1-settings-k8s-io","patch-podpreset-v1alpha1-settings-k8s-io","create-podpreset-v1alpha1-settings-k8s-io","-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-","podpreset-v1alpha1-settings-k8s-io","watch-list-priorityclass-v1-scheduling-k8s-io","watch-priorityclass-v1-scheduling-k8s-io","list-priorityclass-v1-scheduling-k8s-io","read-priorityclass-v1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1-scheduling-k8s-io","delete-priorityclass-v1-scheduling-k8s-io","replace-priorityclass-v1-scheduling-k8s-io","patch-priorityclass-v1-scheduling-k8s-io","create-priorityclass-v1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-","priorityclass-v1-scheduling-k8s-io","replace-status-poddisruptionbudget-v1beta1-policy","read-status-poddisruptionbudget-v1beta1-policy","patch-status-poddisruptionbudget-v1beta1-policy","-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-","watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy","watch-list-poddisruptionbudget-v1beta1-policy","watch-poddisruptionbudget-v1beta1-policy","list-all-namespaces-poddisruptionbudget-v1beta1-policy","list-poddisruptionbudget-v1beta1-policy","read-poddisruptionbudget-v1beta1-policy","-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-","delete-collection-poddisruptionbudget-v1beta1-policy","delete-poddisruptionbudget-v1beta1-policy","replace-poddisruptionbudget-v1beta1-policy","patch-poddisruptionbudget-v1beta1-policy","create-poddisruptionbudget-v1beta1-policy","-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-","poddisruptionbudget-v1beta1-policy","watch-list-all-namespaces-podtemplate-v1-core","watch-list-podtemplate-v1-core","watch-podtemplate-v1-core","list-all-namespaces-podtemplate-v1-core","list-podtemplate-v1-core","read-podtemplate-v1-core","-strong-read-operations-podtemplate-v1-core-strong-","delete-collection-podtemplate-v1-core","delete-podtemplate-v1-core","replace-podtemplate-v1-core","patch-podtemplate-v1-core","create-podtemplate-v1-core","-strong-write-operations-podtemplate-v1-core-strong-","podtemplate-v1-core","watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","validatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-status-horizontalpodautoscaler-v1-autoscaling","read-status-horizontalpodautoscaler-v1-autoscaling","patch-status-horizontalpodautoscaler-v1-autoscaling","-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","watch-list-horizontalpodautoscaler-v1-autoscaling","watch-horizontalpodautoscaler-v1-autoscaling","list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","list-horizontalpodautoscaler-v1-autoscaling","read-horizontalpodautoscaler-v1-autoscaling","-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v1-autoscaling","delete-horizontalpodautoscaler-v1-autoscaling","replace-horizontalpodautoscaler-v1-autoscaling","patch-horizontalpodautoscaler-v1-autoscaling","create-horizontalpodautoscaler-v1-autoscaling","-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-","horizontalpodautoscaler-v1-autoscaling","watch-list-all-namespaces-limitrange-v1-core","watch-list-limitrange-v1-core","watch-limitrange-v1-core","list-all-namespaces-limitrange-v1-core","list-limitrange-v1-core","read-limitrange-v1-core","-strong-read-operations-limitrange-v1-core-strong-","delete-collection-limitrange-v1-core","delete-limitrange-v1-core","replace-limitrange-v1-core","patch-limitrange-v1-core","create-limitrange-v1-core","-strong-write-operations-limitrange-v1-core-strong-","limitrange-v1-core","watch-list-all-namespaces-event-v1-core","watch-list-event-v1-core","watch-event-v1-core","list-all-namespaces-event-v1-core","list-event-v1-core","read-event-v1-core","-strong-read-operations-event-v1-core-strong-","delete-collection-event-v1-core","delete-event-v1-core","replace-event-v1-core","patch-event-v1-core","create-event-v1-core","-strong-write-operations-event-v1-core-strong-","event-v1-core","replace-status-customresourcedefinition-v1-apiextensions-k8s-io","read-status-customresourcedefinition-v1-apiextensions-k8s-io","patch-status-customresourcedefinition-v1-apiextensions-k8s-io","-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","watch-list-customresourcedefinition-v1-apiextensions-k8s-io","watch-customresourcedefinition-v1-apiextensions-k8s-io","list-customresourcedefinition-v1-apiextensions-k8s-io","read-customresourcedefinition-v1-apiextensions-k8s-io","-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","delete-collection-customresourcedefinition-v1-apiextensions-k8s-io","delete-customresourcedefinition-v1-apiextensions-k8s-io","replace-customresourcedefinition-v1-apiextensions-k8s-io","patch-customresourcedefinition-v1-apiextensions-k8s-io","create-customresourcedefinition-v1-apiextensions-k8s-io","-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","customresourcedefinition-v1-apiextensions-k8s-io","watch-list-all-namespaces-controllerrevision-v1-apps","watch-list-controllerrevision-v1-apps","watch-controllerrevision-v1-apps","list-all-namespaces-controllerrevision-v1-apps","list-controllerrevision-v1-apps","read-controllerrevision-v1-apps","-strong-read-operations-controllerrevision-v1-apps-strong-","delete-collection-controllerrevision-v1-apps","delete-controllerrevision-v1-apps","replace-controllerrevision-v1-apps","patch-controllerrevision-v1-apps","create-controllerrevision-v1-apps","-strong-write-operations-controllerrevision-v1-apps-strong-","controllerrevision-v1-apps","-strong-metadata-apis-strong-","replace-status-volumeattachment-v1-storage-k8s-io","read-status-volumeattachment-v1-storage-k8s-io","patch-status-volumeattachment-v1-storage-k8s-io","-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-","watch-list-volumeattachment-v1-storage-k8s-io","watch-volumeattachment-v1-storage-k8s-io","list-volumeattachment-v1-storage-k8s-io","read-volumeattachment-v1-storage-k8s-io","-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1-storage-k8s-io","delete-volumeattachment-v1-storage-k8s-io","replace-volumeattachment-v1-storage-k8s-io","patch-volumeattachment-v1-storage-k8s-io","create-volumeattachment-v1-storage-k8s-io","-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-","volumeattachment-v1-storage-k8s-io","volume-v1-core","watch-list-storageclass-v1-storage-k8s-io","watch-storageclass-v1-storage-k8s-io","list-storageclass-v1-storage-k8s-io","read-storageclass-v1-storage-k8s-io","-strong-read-operations-storageclass-v1-storage-k8s-io-strong-","delete-collection-storageclass-v1-storage-k8s-io","delete-storageclass-v1-storage-k8s-io","replace-storageclass-v1-storage-k8s-io","patch-storageclass-v1-storage-k8s-io","create-storageclass-v1-storage-k8s-io","-strong-write-operations-storageclass-v1-storage-k8s-io-strong-","storageclass-v1-storage-k8s-io","replace-status-persistentvolumeclaim-v1-core","read-status-persistentvolumeclaim-v1-core","patch-status-persistentvolumeclaim-v1-core","-strong-status-operations-persistentvolumeclaim-v1-core-strong-","watch-list-all-namespaces-persistentvolumeclaim-v1-core","watch-list-persistentvolumeclaim-v1-core","watch-persistentvolumeclaim-v1-core","list-all-namespaces-persistentvolumeclaim-v1-core","list-persistentvolumeclaim-v1-core","read-persistentvolumeclaim-v1-core","-strong-read-operations-persistentvolumeclaim-v1-core-strong-","delete-collection-persistentvolumeclaim-v1-core","delete-persistentvolumeclaim-v1-core","replace-persistentvolumeclaim-v1-core","patch-persistentvolumeclaim-v1-core","create-persistentvolumeclaim-v1-core","-strong-write-operations-persistentvolumeclaim-v1-core-strong-","persistentvolumeclaim-v1-core","watch-list-all-namespaces-secret-v1-core","watch-list-secret-v1-core","watch-secret-v1-core","list-all-namespaces-secret-v1-core","list-secret-v1-core","read-secret-v1-core","-strong-read-operations-secret-v1-core-strong-","delete-collection-secret-v1-core","delete-secret-v1-core","replace-secret-v1-core","patch-secret-v1-core","create-secret-v1-core","-strong-write-operations-secret-v1-core-strong-","secret-v1-core","watch-list-csinode-v1-storage-k8s-io","watch-csinode-v1-storage-k8s-io","list-csinode-v1-storage-k8s-io","read-csinode-v1-storage-k8s-io","-strong-read-operations-csinode-v1-storage-k8s-io-strong-","delete-collection-csinode-v1-storage-k8s-io","delete-csinode-v1-storage-k8s-io","replace-csinode-v1-storage-k8s-io","patch-csinode-v1-storage-k8s-io","create-csinode-v1-storage-k8s-io","-strong-write-operations-csinode-v1-storage-k8s-io-strong-","csinode-v1-storage-k8s-io","watch-list-csidriver-v1-storage-k8s-io","watch-csidriver-v1-storage-k8s-io","list-csidriver-v1-storage-k8s-io","read-csidriver-v1-storage-k8s-io","-strong-read-operations-csidriver-v1-storage-k8s-io-strong-","delete-collection-csidriver-v1-storage-k8s-io","delete-csidriver-v1-storage-k8s-io","replace-csidriver-v1-storage-k8s-io","patch-csidriver-v1-storage-k8s-io","create-csidriver-v1-storage-k8s-io","-strong-write-operations-csidriver-v1-storage-k8s-io-strong-","csidriver-v1-storage-k8s-io","watch-list-all-namespaces-configmap-v1-core","watch-list-configmap-v1-core","watch-configmap-v1-core","list-all-namespaces-configmap-v1-core","list-configmap-v1-core","read-configmap-v1-core","-strong-read-operations-configmap-v1-core-strong-","delete-collection-configmap-v1-core","delete-configmap-v1-core","replace-configmap-v1-core","patch-configmap-v1-core","create-configmap-v1-core","-strong-write-operations-configmap-v1-core-strong-","configmap-v1-core","-strong-config-and-storage-apis-strong-","replace-connect-proxy-path-service-v1-core","replace-connect-proxy-service-v1-core","head-connect-proxy-path-service-v1-core","head-connect-proxy-service-v1-core","get-connect-proxy-path-service-v1-core","get-connect-proxy-service-v1-core","delete-connect-proxy-path-service-v1-core","delete-connect-proxy-service-v1-core","create-connect-proxy-path-service-v1-core","create-connect-proxy-service-v1-core","-strong-proxy-operations-service-v1-core-strong-","replace-status-service-v1-core","read-status-service-v1-core","patch-status-service-v1-core","-strong-status-operations-service-v1-core-strong-","watch-list-all-namespaces-service-v1-core","watch-list-service-v1-core","watch-service-v1-core","list-all-namespaces-service-v1-core","list-service-v1-core","read-service-v1-core","-strong-read-operations-service-v1-core-strong-","delete-service-v1-core","replace-service-v1-core","patch-service-v1-core","create-service-v1-core","-strong-write-operations-service-v1-core-strong-","service-v1-core","watch-list-ingressclass-v1-networking-k8s-io","watch-ingressclass-v1-networking-k8s-io","list-ingressclass-v1-networking-k8s-io","read-ingressclass-v1-networking-k8s-io","-strong-read-operations-ingressclass-v1-networking-k8s-io-strong-","delete-collection-ingressclass-v1-networking-k8s-io","delete-ingressclass-v1-networking-k8s-io","replace-ingressclass-v1-networking-k8s-io","patch-ingressclass-v1-networking-k8s-io","create-ingressclass-v1-networking-k8s-io","-strong-write-operations-ingressclass-v1-networking-k8s-io-strong-","ingressclass-v1-networking-k8s-io","replace-status-ingress-v1-networking-k8s-io","read-status-ingress-v1-networking-k8s-io","patch-status-ingress-v1-networking-k8s-io","-strong-status-operations-ingress-v1-networking-k8s-io-strong-","watch-list-all-namespaces-ingress-v1-networking-k8s-io","watch-list-ingress-v1-networking-k8s-io","watch-ingress-v1-networking-k8s-io","list-all-namespaces-ingress-v1-networking-k8s-io","list-ingress-v1-networking-k8s-io","read-ingress-v1-networking-k8s-io","-strong-read-operations-ingress-v1-networking-k8s-io-strong-","delete-collection-ingress-v1-networking-k8s-io","delete-ingress-v1-networking-k8s-io","replace-ingress-v1-networking-k8s-io","patch-ingress-v1-networking-k8s-io","create-ingress-v1-networking-k8s-io","-strong-write-operations-ingress-v1-networking-k8s-io-strong-","ingress-v1-networking-k8s-io","watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","watch-list-endpointslice-v1beta1-discovery-k8s-io","watch-endpointslice-v1beta1-discovery-k8s-io","list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","list-endpointslice-v1beta1-discovery-k8s-io","read-endpointslice-v1beta1-discovery-k8s-io","-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","delete-collection-endpointslice-v1beta1-discovery-k8s-io","delete-endpointslice-v1beta1-discovery-k8s-io","replace-endpointslice-v1beta1-discovery-k8s-io","patch-endpointslice-v1beta1-discovery-k8s-io","create-endpointslice-v1beta1-discovery-k8s-io","-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","endpointslice-v1beta1-discovery-k8s-io","watch-list-all-namespaces-endpoints-v1-core","watch-list-endpoints-v1-core","watch-endpoints-v1-core","list-all-namespaces-endpoints-v1-core","list-endpoints-v1-core","read-endpoints-v1-core","-strong-read-operations-endpoints-v1-core-strong-","delete-collection-endpoints-v1-core","delete-endpoints-v1-core","replace-endpoints-v1-core","patch-endpoints-v1-core","create-endpoints-v1-core","-strong-write-operations-endpoints-v1-core-strong-","endpoints-v1-core","-strong-service-apis-strong-","patch-scale-statefulset-v1-apps","replace-scale-statefulset-v1-apps","read-scale-statefulset-v1-apps","-strong-misc-operations-statefulset-v1-apps-strong-","replace-status-statefulset-v1-apps","read-status-statefulset-v1-apps","patch-status-statefulset-v1-apps","-strong-status-operations-statefulset-v1-apps-strong-","watch-list-all-namespaces-statefulset-v1-apps","watch-list-statefulset-v1-apps","watch-statefulset-v1-apps","list-all-namespaces-statefulset-v1-apps","list-statefulset-v1-apps","read-statefulset-v1-apps","-strong-read-operations-statefulset-v1-apps-strong-","delete-collection-statefulset-v1-apps","delete-statefulset-v1-apps","replace-statefulset-v1-apps","patch-statefulset-v1-apps","create-statefulset-v1-apps","-strong-write-operations-statefulset-v1-apps-strong-","statefulset-v1-apps","patch-scale-replicationcontroller-v1-core","replace-scale-replicationcontroller-v1-core","read-scale-replicationcontroller-v1-core","-strong-misc-operations-replicationcontroller-v1-core-strong-","replace-status-replicationcontroller-v1-core","read-status-replicationcontroller-v1-core","patch-status-replicationcontroller-v1-core","-strong-status-operations-replicationcontroller-v1-core-strong-","watch-list-all-namespaces-replicationcontroller-v1-core","watch-list-replicationcontroller-v1-core","watch-replicationcontroller-v1-core","list-all-namespaces-replicationcontroller-v1-core","list-replicationcontroller-v1-core","read-replicationcontroller-v1-core","-strong-read-operations-replicationcontroller-v1-core-strong-","delete-collection-replicationcontroller-v1-core","delete-replicationcontroller-v1-core","replace-replicationcontroller-v1-core","patch-replicationcontroller-v1-core","create-replicationcontroller-v1-core","-strong-write-operations-replicationcontroller-v1-core-strong-","replicationcontroller-v1-core","patch-scale-replicaset-v1-apps","replace-scale-replicaset-v1-apps","read-scale-replicaset-v1-apps","-strong-misc-operations-replicaset-v1-apps-strong-","replace-status-replicaset-v1-apps","read-status-replicaset-v1-apps","patch-status-replicaset-v1-apps","-strong-status-operations-replicaset-v1-apps-strong-","watch-list-all-namespaces-replicaset-v1-apps","watch-list-replicaset-v1-apps","watch-replicaset-v1-apps","list-all-namespaces-replicaset-v1-apps","list-replicaset-v1-apps","read-replicaset-v1-apps","-strong-read-operations-replicaset-v1-apps-strong-","delete-collection-replicaset-v1-apps","delete-replicaset-v1-apps","replace-replicaset-v1-apps","patch-replicaset-v1-apps","create-replicaset-v1-apps","-strong-write-operations-replicaset-v1-apps-strong-","replicaset-v1-apps","read-log-pod-v1-core","-strong-misc-operations-pod-v1-core-strong-","replace-connect-proxy-path-pod-v1-core","replace-connect-proxy-pod-v1-core","head-connect-proxy-path-pod-v1-core","head-connect-proxy-pod-v1-core","get-connect-proxy-path-pod-v1-core","get-connect-proxy-pod-v1-core","get-connect-portforward-pod-v1-core","delete-connect-proxy-path-pod-v1-core","delete-connect-proxy-pod-v1-core","create-connect-proxy-path-pod-v1-core","create-connect-proxy-pod-v1-core","create-connect-portforward-pod-v1-core","-strong-proxy-operations-pod-v1-core-strong-","replace-status-pod-v1-core","read-status-pod-v1-core","patch-status-pod-v1-core","-strong-status-operations-pod-v1-core-strong-","watch-list-all-namespaces-pod-v1-core","watch-list-pod-v1-core","watch-pod-v1-core","list-all-namespaces-pod-v1-core","list-pod-v1-core","read-pod-v1-core","-strong-read-operations-pod-v1-core-strong-","delete-collection-pod-v1-core","delete-pod-v1-core","replace-pod-v1-core","patch-pod-v1-core","create-eviction-pod-v1-core","create-pod-v1-core","-strong-write-operations-pod-v1-core-strong-","pod-v1-core","replace-status-job-v1-batch","read-status-job-v1-batch","patch-status-job-v1-batch","-strong-status-operations-job-v1-batch-strong-","watch-list-all-namespaces-job-v1-batch","watch-list-job-v1-batch","watch-job-v1-batch","list-all-namespaces-job-v1-batch","list-job-v1-batch","read-job-v1-batch","-strong-read-operations-job-v1-batch-strong-","delete-collection-job-v1-batch","delete-job-v1-batch","replace-job-v1-batch","patch-job-v1-batch","create-job-v1-batch","-strong-write-operations-job-v1-batch-strong-","job-v1-batch","patch-scale-deployment-v1-apps","replace-scale-deployment-v1-apps","read-scale-deployment-v1-apps","-strong-misc-operations-deployment-v1-apps-strong-","replace-status-deployment-v1-apps","read-status-deployment-v1-apps","patch-status-deployment-v1-apps","-strong-status-operations-deployment-v1-apps-strong-","watch-list-all-namespaces-deployment-v1-apps","watch-list-deployment-v1-apps","watch-deployment-v1-apps","list-all-namespaces-deployment-v1-apps","list-deployment-v1-apps","read-deployment-v1-apps","-strong-read-operations-deployment-v1-apps-strong-","delete-collection-deployment-v1-apps","delete-deployment-v1-apps","replace-deployment-v1-apps","patch-deployment-v1-apps","create-deployment-v1-apps","-strong-write-operations-deployment-v1-apps-strong-","deployment-v1-apps","replace-status-daemonset-v1-apps","read-status-daemonset-v1-apps","patch-status-daemonset-v1-apps","-strong-status-operations-daemonset-v1-apps-strong-","watch-list-all-namespaces-daemonset-v1-apps","watch-list-daemonset-v1-apps","watch-daemonset-v1-apps","list-all-namespaces-daemonset-v1-apps","list-daemonset-v1-apps","read-daemonset-v1-apps","-strong-read-operations-daemonset-v1-apps-strong-","delete-collection-daemonset-v1-apps","delete-daemonset-v1-apps","replace-daemonset-v1-apps","patch-daemonset-v1-apps","create-daemonset-v1-apps","-strong-write-operations-daemonset-v1-apps-strong-","daemonset-v1-apps","replace-status-cronjob-v1beta1-batch","read-status-cronjob-v1beta1-batch","patch-status-cronjob-v1beta1-batch","-strong-status-operations-cronjob-v1beta1-batch-strong-","watch-list-all-namespaces-cronjob-v1beta1-batch","watch-list-cronjob-v1beta1-batch","watch-cronjob-v1beta1-batch","list-all-namespaces-cronjob-v1beta1-batch","list-cronjob-v1beta1-batch","read-cronjob-v1beta1-batch","-strong-read-operations-cronjob-v1beta1-batch-strong-","delete-collection-cronjob-v1beta1-batch","delete-cronjob-v1beta1-batch","replace-cronjob-v1beta1-batch","patch-cronjob-v1beta1-batch","create-cronjob-v1beta1-batch","-strong-write-operations-cronjob-v1beta1-batch-strong-","cronjob-v1beta1-batch","container-v1-core","-strong-workloads-apis-strong-","-strong-api-overview-strong-"]};})();
\ No newline at end of file
+(function(){navData={"toc":[{"section":"webhookclientconfig-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1-apiextensions-k8s-io","subsections":[]},{"section":"volumenoderesources-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeerror-v1alpha1-storage-k8s-io","subsections":[]},{"section":"volumeerror-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeattachmentsource-v1alpha1-storage-k8s-io","subsections":[]},{"section":"volumeattachmentsource-v1beta1-storage-k8s-io","subsections":[]},{"section":"volumeattachment-v1alpha1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1alpha1-storage-k8s-io","subsections":[]}]}]},{"section":"volumeattachment-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"validatingwebhook-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"userinfo-v1beta1-authentication-k8s-io","subsections":[]},{"section":"tokenreview-v1beta1-authentication-k8s-io","subsections":[{"section":"-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-","subsections":[{"section":"create-tokenreview-v1beta1-authentication-k8s-io","subsections":[]}]}]},{"section":"subjectrulesreviewstatus-v1beta1-authorization-k8s-io","subsections":[]},{"section":"subjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-subjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"subject-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"subject-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"subject-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"storageclass-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-storageclass-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-storageclass-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-storageclass-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"servicereference-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"servicereference-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"servicereference-v1-apiregistration-k8s-io","subsections":[]},{"section":"servicereference-v1-apiextensions-k8s-io","subsections":[]},{"section":"selfsubjectrulesreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectrulesreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"selfsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"scheduling-v1alpha1-node-k8s-io","subsections":[]},{"section":"runtimeclass-v1alpha1-node-k8s-io","subsections":[{"section":"-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","subsections":[{"section":"watch-list-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"watch-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"list-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"read-runtimeclass-v1alpha1-node-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","subsections":[{"section":"delete-collection-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"delete-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"replace-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"patch-runtimeclass-v1alpha1-node-k8s-io","subsections":[]},{"section":"create-runtimeclass-v1alpha1-node-k8s-io","subsections":[]}]}]},{"section":"rulewithoperations-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"roleref-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"roleref-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"resourcerule-v1beta1-authorization-k8s-io","subsections":[]},{"section":"resourcemetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"resourcemetricsource-v2beta1-autoscaling","subsections":[]},{"section":"resourceattributes-v1beta1-authorization-k8s-io","subsections":[]},{"section":"priorityclass-v1alpha1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1alpha1-scheduling-k8s-io","subsections":[]}]}]},{"section":"priorityclass-v1beta1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1beta1-scheduling-k8s-io","subsections":[]}]}]},{"section":"policyrule-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"policyrule-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"podsmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"podsmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"overhead-v1alpha1-node-k8s-io","subsections":[]},{"section":"objectmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"objectmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"nonresourcerule-v1beta1-authorization-k8s-io","subsections":[]},{"section":"nonresourceattributes-v1beta1-authorization-k8s-io","subsections":[]},{"section":"mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"mutatingwebhook-v1beta1-admissionregistration-k8s-io","subsections":[]},{"section":"metricstatus-v2beta1-autoscaling","subsections":[]},{"section":"metricspec-v2beta1-autoscaling","subsections":[]},{"section":"localsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","subsections":[{"section":"create-localsubjectaccessreview-v1beta1-authorization-k8s-io","subsections":[]}]}]},{"section":"lease-v1beta1-coordination-k8s-io","subsections":[{"section":"-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"watch-list-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"watch-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"list-all-namespaces-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"list-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"read-lease-v1beta1-coordination-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-","subsections":[{"section":"delete-collection-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"delete-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"replace-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"patch-lease-v1beta1-coordination-k8s-io","subsections":[]},{"section":"create-lease-v1beta1-coordination-k8s-io","subsections":[]}]}]},{"section":"jobtemplatespec-v2alpha1-batch","subsections":[]},{"section":"jsonschemapropsorbool-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemapropsorarray-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemaprops-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"json-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"ingresstls-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingresstls-v1beta1-extensions","subsections":[]},{"section":"ingressrule-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingressrule-v1beta1-extensions","subsections":[]},{"section":"ingressclass-v1beta1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-ingressclass-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"delete-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"replace-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-ingressclass-v1beta1-networking-k8s-io","subsections":[]},{"section":"create-ingressclass-v1beta1-networking-k8s-io","subsections":[]}]}]},{"section":"ingressbackend-v1beta1-networking-k8s-io","subsections":[]},{"section":"ingressbackend-v1beta1-extensions","subsections":[]},{"section":"ingress-v1beta1-networking-k8s-io","subsections":[{"section":"-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"replace-status-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-status-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-status-ingress-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-list-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"watch-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"list-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"read-ingress-v1beta1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"delete-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"replace-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"patch-ingress-v1beta1-networking-k8s-io","subsections":[]},{"section":"create-ingress-v1beta1-networking-k8s-io","subsections":[]}]}]},{"section":"ingress-v1beta1-extensions","subsections":[{"section":"-strong-status-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"replace-status-ingress-v1beta1-extensions","subsections":[]},{"section":"read-status-ingress-v1beta1-extensions","subsections":[]},{"section":"patch-status-ingress-v1beta1-extensions","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1beta1-extensions","subsections":[]},{"section":"watch-list-ingress-v1beta1-extensions","subsections":[]},{"section":"watch-ingress-v1beta1-extensions","subsections":[]},{"section":"list-all-namespaces-ingress-v1beta1-extensions","subsections":[]},{"section":"list-ingress-v1beta1-extensions","subsections":[]},{"section":"read-ingress-v1beta1-extensions","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1beta1-extensions-strong-","subsections":[{"section":"delete-collection-ingress-v1beta1-extensions","subsections":[]},{"section":"delete-ingress-v1beta1-extensions","subsections":[]},{"section":"replace-ingress-v1beta1-extensions","subsections":[]},{"section":"patch-ingress-v1beta1-extensions","subsections":[]},{"section":"create-ingress-v1beta1-extensions","subsections":[]}]}]},{"section":"horizontalpodautoscalercondition-v2beta1-autoscaling","subsections":[]},{"section":"horizontalpodautoscaler-v2beta1-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v2beta1-autoscaling","subsections":[]}]}]},{"section":"horizontalpodautoscaler-v2beta2-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v2beta2-autoscaling","subsections":[]}]}]},{"section":"httpingressrulevalue-v1beta1-networking-k8s-io","subsections":[]},{"section":"httpingressrulevalue-v1beta1-extensions","subsections":[]},{"section":"httpingresspath-v1beta1-networking-k8s-io","subsections":[]},{"section":"httpingresspath-v1beta1-extensions","subsections":[]},{"section":"externalmetricstatus-v2beta1-autoscaling","subsections":[]},{"section":"externalmetricsource-v2beta1-autoscaling","subsections":[]},{"section":"externaldocumentation-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"eventseries-v1beta1-events-k8s-io","subsections":[]},{"section":"eventseries-v1-events-k8s-io","subsections":[]},{"section":"event-v1beta1-events-k8s-io","subsections":[{"section":"-strong-read-operations-event-v1beta1-events-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1beta1-events-k8s-io","subsections":[]},{"section":"watch-list-event-v1beta1-events-k8s-io","subsections":[]},{"section":"watch-event-v1beta1-events-k8s-io","subsections":[]},{"section":"list-all-namespaces-event-v1beta1-events-k8s-io","subsections":[]},{"section":"list-event-v1beta1-events-k8s-io","subsections":[]},{"section":"read-event-v1beta1-events-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-event-v1beta1-events-k8s-io-strong-","subsections":[{"section":"delete-collection-event-v1beta1-events-k8s-io","subsections":[]},{"section":"delete-event-v1beta1-events-k8s-io","subsections":[]},{"section":"replace-event-v1beta1-events-k8s-io","subsections":[]},{"section":"patch-event-v1beta1-events-k8s-io","subsections":[]},{"section":"create-event-v1beta1-events-k8s-io","subsections":[]}]}]},{"section":"event-v1-events-k8s-io","subsections":[{"section":"-strong-read-operations-event-v1-events-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1-events-k8s-io","subsections":[]},{"section":"watch-list-event-v1-events-k8s-io","subsections":[]},{"section":"watch-event-v1-events-k8s-io","subsections":[]},{"section":"list-all-namespaces-event-v1-events-k8s-io","subsections":[]},{"section":"list-event-v1-events-k8s-io","subsections":[]},{"section":"read-event-v1-events-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-event-v1-events-k8s-io-strong-","subsections":[{"section":"delete-collection-event-v1-events-k8s-io","subsections":[]},{"section":"delete-event-v1-events-k8s-io","subsections":[]},{"section":"replace-event-v1-events-k8s-io","subsections":[]},{"section":"patch-event-v1-events-k8s-io","subsections":[]},{"section":"create-event-v1-events-k8s-io","subsections":[]}]}]},{"section":"endpointport-v1beta1-discovery-k8s-io","subsections":[]},{"section":"customresourcevalidation-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresources-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcescale-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionversion-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionnames-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[{"section":"-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"watch-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"list-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"read-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","subsections":[{"section":"delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"delete-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"replace-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"patch-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"create-customresourcedefinition-v1beta1-apiextensions-k8s-io","subsections":[]}]}]},{"section":"customresourceconversion-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcecolumndefinition-v1beta1-apiextensions-k8s-io","subsections":[]},{"section":"crossversionobjectreference-v2beta1-autoscaling","subsections":[]},{"section":"crossversionobjectreference-v2beta2-autoscaling","subsections":[]},{"section":"cronjob-v2alpha1-batch","subsections":[{"section":"-strong-status-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"replace-status-cronjob-v2alpha1-batch","subsections":[]},{"section":"read-status-cronjob-v2alpha1-batch","subsections":[]},{"section":"patch-status-cronjob-v2alpha1-batch","subsections":[]}]},{"section":"-strong-read-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-cronjob-v2alpha1-batch","subsections":[]},{"section":"watch-list-cronjob-v2alpha1-batch","subsections":[]},{"section":"watch-cronjob-v2alpha1-batch","subsections":[]},{"section":"list-all-namespaces-cronjob-v2alpha1-batch","subsections":[]},{"section":"list-cronjob-v2alpha1-batch","subsections":[]},{"section":"read-cronjob-v2alpha1-batch","subsections":[]}]},{"section":"-strong-write-operations-cronjob-v2alpha1-batch-strong-","subsections":[{"section":"delete-collection-cronjob-v2alpha1-batch","subsections":[]},{"section":"delete-cronjob-v2alpha1-batch","subsections":[]},{"section":"replace-cronjob-v2alpha1-batch","subsections":[]},{"section":"patch-cronjob-v2alpha1-batch","subsections":[]},{"section":"create-cronjob-v2alpha1-batch","subsections":[]}]}]},{"section":"clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1alpha1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1beta1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"certificatesigningrequestcondition-v1beta1-certificates-k8s-io","subsections":[]},{"section":"certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[{"section":"-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"read-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"watch-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"list-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"read-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","subsections":[{"section":"delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"delete-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"replace-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"patch-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]},{"section":"create-certificatesigningrequest-v1beta1-certificates-k8s-io","subsections":[]}]}]},{"section":"csinodedriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"csinode-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-csinode-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-csinode-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-csinode-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"csidriver-v1beta1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"watch-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"list-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"read-csidriver-v1beta1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"delete-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"replace-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"patch-csidriver-v1beta1-storage-k8s-io","subsections":[]},{"section":"create-csidriver-v1beta1-storage-k8s-io","subsections":[]}]}]},{"section":"aggregationrule-v1alpha1-rbac-authorization-k8s-io","subsections":[]},{"section":"aggregationrule-v1beta1-rbac-authorization-k8s-io","subsections":[]},{"section":"apiservicecondition-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"apiservice-v1beta1-apiregistration-k8s-io","subsections":[{"section":"-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"replace-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"read-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"patch-status-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"watch-list-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"watch-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"list-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"read-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"delete-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"replace-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"patch-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]},{"section":"create-apiservice-v1beta1-apiregistration-k8s-io","subsections":[]}]}]},{"section":"-strong-old-api-versions-strong-","subsections":[]},{"section":"windowssecuritycontextoptions-v1-core","subsections":[]},{"section":"weightedpodaffinityterm-v1-core","subsections":[]},{"section":"webhookconversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"webhookclientconfig-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watchevent-v1-meta","subsections":[]},{"section":"vspherevirtualdiskvolumesource-v1-core","subsections":[]},{"section":"volumeprojection-v1-core","subsections":[]},{"section":"volumenoderesources-v1-storage-k8s-io","subsections":[]},{"section":"volumenodeaffinity-v1-core","subsections":[]},{"section":"volumemount-v1-core","subsections":[]},{"section":"volumeerror-v1-storage-k8s-io","subsections":[]},{"section":"volumedevice-v1-core","subsections":[]},{"section":"volumeattachmentsource-v1-storage-k8s-io","subsections":[]},{"section":"validatingwebhook-v1-admissionregistration-k8s-io","subsections":[]},{"section":"usersubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"userinfo-v1-authentication-k8s-io","subsections":[]},{"section":"typedlocalobjectreference-v1-core","subsections":[]},{"section":"topologyspreadconstraint-v1-core","subsections":[]},{"section":"topologyselectorterm-v1-core","subsections":[]},{"section":"topologyselectorlabelrequirement-v1-core","subsections":[]},{"section":"toleration-v1-core","subsections":[]},{"section":"time-v1-meta","subsections":[]},{"section":"taint-v1-core","subsections":[]},{"section":"tcpsocketaction-v1-core","subsections":[]},{"section":"sysctl-v1-core","subsections":[]},{"section":"supplementalgroupsstrategyoptions-v1beta1-policy","subsections":[]},{"section":"subjectrulesreviewstatus-v1-authorization-k8s-io","subsections":[]},{"section":"subject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"storageosvolumesource-v1-core","subsections":[]},{"section":"storageospersistentvolumesource-v1-core","subsections":[]},{"section":"statusdetails-v1-meta","subsections":[]},{"section":"statuscause-v1-meta","subsections":[]},{"section":"status-v1-meta","subsections":[]},{"section":"statefulsetupdatestrategy-v1-apps","subsections":[]},{"section":"statefulsetcondition-v1-apps","subsections":[]},{"section":"sessionaffinityconfig-v1-core","subsections":[]},{"section":"servicereference-v1-admissionregistration-k8s-io","subsections":[]},{"section":"serviceport-v1-core","subsections":[]},{"section":"servicebackendport-v1-networking-k8s-io","subsections":[]},{"section":"serviceaccounttokenprojection-v1-core","subsections":[]},{"section":"serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"serveraddressbyclientcidr-v1-meta","subsections":[]},{"section":"securitycontext-v1-core","subsections":[]},{"section":"secretvolumesource-v1-core","subsections":[]},{"section":"secretreference-v1-core","subsections":[]},{"section":"secretprojection-v1-core","subsections":[]},{"section":"secretkeyselector-v1-core","subsections":[]},{"section":"secretenvsource-v1-core","subsections":[]},{"section":"seccompprofile-v1-core","subsections":[]},{"section":"scopedresourceselectorrequirement-v1-core","subsections":[]},{"section":"scopeselector-v1-core","subsections":[]},{"section":"scheduling-v1beta1-node-k8s-io","subsections":[]},{"section":"scaleiovolumesource-v1-core","subsections":[]},{"section":"scaleiopersistentvolumesource-v1-core","subsections":[]},{"section":"scale-v1-autoscaling","subsections":[]},{"section":"selinuxstrategyoptions-v1beta1-policy","subsections":[]},{"section":"selinuxoptions-v1-core","subsections":[]},{"section":"runtimeclassstrategyoptions-v1beta1-policy","subsections":[]},{"section":"runasuserstrategyoptions-v1beta1-policy","subsections":[]},{"section":"runasgroupstrategyoptions-v1beta1-policy","subsections":[]},{"section":"rulewithoperations-v1-admissionregistration-k8s-io","subsections":[]},{"section":"rollingupdatestatefulsetstrategy-v1-apps","subsections":[]},{"section":"roleref-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"resourcerule-v1-authorization-k8s-io","subsections":[]},{"section":"resourcerequirements-v1-core","subsections":[]},{"section":"resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"resourcemetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"resourcemetricsource-v2beta2-autoscaling","subsections":[]},{"section":"resourcefieldselector-v1-core","subsections":[]},{"section":"resourceattributes-v1-authorization-k8s-io","subsections":[]},{"section":"replicationcontrollercondition-v1-core","subsections":[]},{"section":"replicasetcondition-v1-apps","subsections":[]},{"section":"rbdvolumesource-v1-core","subsections":[]},{"section":"rbdpersistentvolumesource-v1-core","subsections":[]},{"section":"quobytevolumesource-v1-core","subsections":[]},{"section":"queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"quantity-resource-core","subsections":[]},{"section":"projectedvolumesource-v1-core","subsections":[]},{"section":"probe-v1-core","subsections":[]},{"section":"prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"preferredschedulingterm-v1-core","subsections":[]},{"section":"preconditions-v1-meta","subsections":[]},{"section":"portworxvolumesource-v1-core","subsections":[]},{"section":"policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"policyrule-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"podsmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"podsmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"podsecuritycontext-v1-core","subsections":[]},{"section":"podreadinessgate-v1-core","subsections":[]},{"section":"podip-v1-core","subsections":[]},{"section":"poddnsconfigoption-v1-core","subsections":[]},{"section":"poddnsconfig-v1-core","subsections":[]},{"section":"podcondition-v1-core","subsections":[]},{"section":"podantiaffinity-v1-core","subsections":[]},{"section":"podaffinityterm-v1-core","subsections":[]},{"section":"podaffinity-v1-core","subsections":[]},{"section":"photonpersistentdiskvolumesource-v1-core","subsections":[]},{"section":"persistentvolumeclaimvolumesource-v1-core","subsections":[]},{"section":"persistentvolumeclaimtemplate-v1-core","subsections":[]},{"section":"persistentvolumeclaimcondition-v1-core","subsections":[]},{"section":"patch-v1-meta","subsections":[]},{"section":"ownerreference-v1-meta","subsections":[]},{"section":"overhead-v1beta1-node-k8s-io","subsections":[]},{"section":"objectreference-v1-core","subsections":[]},{"section":"objectmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"objectmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"objectmeta-v1-meta","subsections":[]},{"section":"objectfieldselector-v1-core","subsections":[]},{"section":"nonresourcerule-v1-authorization-k8s-io","subsections":[]},{"section":"nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"nonresourceattributes-v1-authorization-k8s-io","subsections":[]},{"section":"nodesysteminfo-v1-core","subsections":[]},{"section":"nodeselectorterm-v1-core","subsections":[]},{"section":"nodeselectorrequirement-v1-core","subsections":[]},{"section":"nodeselector-v1-core","subsections":[]},{"section":"nodedaemonendpoints-v1-core","subsections":[]},{"section":"nodeconfigstatus-v1-core","subsections":[]},{"section":"nodeconfigsource-v1-core","subsections":[]},{"section":"nodecondition-v1-core","subsections":[]},{"section":"nodeaffinity-v1-core","subsections":[]},{"section":"nodeaddress-v1-core","subsections":[]},{"section":"networkpolicyport-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicypeer-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicyingressrule-v1-networking-k8s-io","subsections":[]},{"section":"networkpolicyegressrule-v1-networking-k8s-io","subsections":[]},{"section":"namespacecondition-v1-core","subsections":[]},{"section":"nfsvolumesource-v1-core","subsections":[]},{"section":"mutatingwebhook-v1-admissionregistration-k8s-io","subsections":[]},{"section":"microtime-v1-meta","subsections":[]},{"section":"metricvaluestatus-v2beta2-autoscaling","subsections":[]},{"section":"metrictarget-v2beta2-autoscaling","subsections":[]},{"section":"metricstatus-v2beta2-autoscaling","subsections":[]},{"section":"metricspec-v2beta2-autoscaling","subsections":[]},{"section":"metricidentifier-v2beta2-autoscaling","subsections":[]},{"section":"managedfieldsentry-v1-meta","subsections":[]},{"section":"localvolumesource-v1-core","subsections":[]},{"section":"localobjectreference-v1-core","subsections":[]},{"section":"loadbalancerstatus-v1-core","subsections":[]},{"section":"loadbalanceringress-v1-core","subsections":[]},{"section":"listmeta-v1-meta","subsections":[]},{"section":"limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"limitrangeitem-v1-core","subsections":[]},{"section":"lifecycle-v1-core","subsections":[]},{"section":"labelselectorrequirement-v1-meta","subsections":[]},{"section":"labelselector-v1-meta","subsections":[]},{"section":"keytopath-v1-core","subsections":[]},{"section":"jobtemplatespec-v1beta1-batch","subsections":[]},{"section":"jobcondition-v1-batch","subsections":[]},{"section":"jsonschemapropsorbool-v1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemapropsorarray-v1-apiextensions-k8s-io","subsections":[]},{"section":"jsonschemaprops-v1-apiextensions-k8s-io","subsections":[]},{"section":"json-v1-apiextensions-k8s-io","subsections":[]},{"section":"ingresstls-v1-networking-k8s-io","subsections":[]},{"section":"ingressservicebackend-v1-networking-k8s-io","subsections":[]},{"section":"ingressrule-v1-networking-k8s-io","subsections":[]},{"section":"ingressbackend-v1-networking-k8s-io","subsections":[]},{"section":"iscsivolumesource-v1-core","subsections":[]},{"section":"iscsipersistentvolumesource-v1-core","subsections":[]},{"section":"ipblock-v1-networking-k8s-io","subsections":[]},{"section":"idrange-v1beta1-policy","subsections":[]},{"section":"hostportrange-v1beta1-policy","subsections":[]},{"section":"hostpathvolumesource-v1-core","subsections":[]},{"section":"hostalias-v1-core","subsections":[]},{"section":"horizontalpodautoscalercondition-v2beta2-autoscaling","subsections":[]},{"section":"horizontalpodautoscalerbehavior-v2beta2-autoscaling","subsections":[]},{"section":"handler-v1-core","subsections":[]},{"section":"httpingressrulevalue-v1-networking-k8s-io","subsections":[]},{"section":"httpingresspath-v1-networking-k8s-io","subsections":[]},{"section":"httpheader-v1-core","subsections":[]},{"section":"httpgetaction-v1-core","subsections":[]},{"section":"hpascalingrules-v2beta2-autoscaling","subsections":[]},{"section":"hpascalingpolicy-v2beta2-autoscaling","subsections":[]},{"section":"groupversionfordiscovery-v1-meta","subsections":[]},{"section":"groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"glusterfsvolumesource-v1-core","subsections":[]},{"section":"glusterfspersistentvolumesource-v1-core","subsections":[]},{"section":"gitrepovolumesource-v1-core","subsections":[]},{"section":"gcepersistentdiskvolumesource-v1-core","subsections":[]},{"section":"flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"flockervolumesource-v1-core","subsections":[]},{"section":"flexvolumesource-v1-core","subsections":[]},{"section":"flexpersistentvolumesource-v1-core","subsections":[]},{"section":"fieldsv1-v1-meta","subsections":[]},{"section":"fsgroupstrategyoptions-v1beta1-policy","subsections":[]},{"section":"fcvolumesource-v1-core","subsections":[]},{"section":"externalmetricstatus-v2beta2-autoscaling","subsections":[]},{"section":"externalmetricsource-v2beta2-autoscaling","subsections":[]},{"section":"externaldocumentation-v1-apiextensions-k8s-io","subsections":[]},{"section":"execaction-v1-core","subsections":[]},{"section":"eviction-v1beta1-policy","subsections":[]},{"section":"eventsource-v1-core","subsections":[]},{"section":"eventseries-v1-core","subsections":[]},{"section":"ephemeralvolumesource-v1-core","subsections":[]},{"section":"ephemeralcontainer-v1-core","subsections":[]},{"section":"envvarsource-v1-core","subsections":[]},{"section":"envvar-v1-core","subsections":[]},{"section":"envfromsource-v1-core","subsections":[]},{"section":"endpointsubset-v1-core","subsections":[]},{"section":"endpointport-v1-core","subsections":[]},{"section":"endpointconditions-v1beta1-discovery-k8s-io","subsections":[]},{"section":"endpointaddress-v1-core","subsections":[]},{"section":"endpoint-v1beta1-discovery-k8s-io","subsections":[]},{"section":"emptydirvolumesource-v1-core","subsections":[]},{"section":"downwardapivolumesource-v1-core","subsections":[]},{"section":"downwardapivolumefile-v1-core","subsections":[]},{"section":"downwardapiprojection-v1-core","subsections":[]},{"section":"deploymentcondition-v1-apps","subsections":[]},{"section":"deleteoptions-v1-meta","subsections":[]},{"section":"daemonsetupdatestrategy-v1-apps","subsections":[]},{"section":"daemonsetcondition-v1-apps","subsections":[]},{"section":"daemonendpoint-v1-core","subsections":[]},{"section":"customresourcevalidation-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresources-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcestatus-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcesubresourcescale-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitionnames-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcedefinitioncondition-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourceconversion-v1-apiextensions-k8s-io","subsections":[]},{"section":"customresourcecolumndefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"crossversionobjectreference-v1-autoscaling","subsections":[]},{"section":"containerstatewaiting-v1-core","subsections":[]},{"section":"containerstateterminated-v1-core","subsections":[]},{"section":"containerstaterunning-v1-core","subsections":[]},{"section":"containerstate-v1-core","subsections":[]},{"section":"containerport-v1-core","subsections":[]},{"section":"containerimage-v1-core","subsections":[]},{"section":"configmapvolumesource-v1-core","subsections":[]},{"section":"configmapprojection-v1-core","subsections":[]},{"section":"configmapnodeconfigsource-v1-core","subsections":[]},{"section":"configmapkeyselector-v1-core","subsections":[]},{"section":"configmapenvsource-v1-core","subsections":[]},{"section":"componentcondition-v1-core","subsections":[]},{"section":"clientipconfig-v1-core","subsections":[]},{"section":"cindervolumesource-v1-core","subsections":[]},{"section":"cinderpersistentvolumesource-v1-core","subsections":[]},{"section":"certificatesigningrequestcondition-v1-certificates-k8s-io","subsections":[]},{"section":"cephfsvolumesource-v1-core","subsections":[]},{"section":"cephfspersistentvolumesource-v1-core","subsections":[]},{"section":"capabilities-v1-core","subsections":[]},{"section":"csivolumesource-v1-core","subsections":[]},{"section":"csipersistentvolumesource-v1-core","subsections":[]},{"section":"csinodedriver-v1-storage-k8s-io","subsections":[]},{"section":"boundobjectreference-v1-authentication-k8s-io","subsections":[]},{"section":"azurefilevolumesource-v1-core","subsections":[]},{"section":"azurefilepersistentvolumesource-v1-core","subsections":[]},{"section":"azurediskvolumesource-v1-core","subsections":[]},{"section":"attachedvolume-v1-core","subsections":[]},{"section":"allowedhostpath-v1beta1-policy","subsections":[]},{"section":"allowedflexvolume-v1beta1-policy","subsections":[]},{"section":"allowedcsidriver-v1beta1-policy","subsections":[]},{"section":"aggregationrule-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"affinity-v1-core","subsections":[]},{"section":"awselasticblockstorevolumesource-v1-core","subsections":[]},{"section":"apiversions-v1-meta","subsections":[]},{"section":"apiservicecondition-v1-apiregistration-k8s-io","subsections":[]},{"section":"apiresource-v1-meta","subsections":[]},{"section":"apigroup-v1-meta","subsections":[]},{"section":"-strong-definitions-strong-","subsections":[]},{"section":"networkpolicy-v1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"watch-list-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"watch-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"list-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"read-networkpolicy-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"delete-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"replace-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"patch-networkpolicy-v1-networking-k8s-io","subsections":[]},{"section":"create-networkpolicy-v1-networking-k8s-io","subsections":[]}]}]},{"section":"tokenreview-v1-authentication-k8s-io","subsections":[{"section":"-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-","subsections":[{"section":"create-tokenreview-v1-authentication-k8s-io","subsections":[]}]}]},{"section":"tokenrequest-v1-authentication-k8s-io","subsections":[]},{"section":"subjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-subjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"serviceaccount-v1-core","subsections":[{"section":"-strong-read-operations-serviceaccount-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-serviceaccount-v1-core","subsections":[]},{"section":"watch-list-serviceaccount-v1-core","subsections":[]},{"section":"watch-serviceaccount-v1-core","subsections":[]},{"section":"list-all-namespaces-serviceaccount-v1-core","subsections":[]},{"section":"list-serviceaccount-v1-core","subsections":[]},{"section":"read-serviceaccount-v1-core","subsections":[]}]},{"section":"-strong-write-operations-serviceaccount-v1-core-strong-","subsections":[{"section":"delete-collection-serviceaccount-v1-core","subsections":[]},{"section":"delete-serviceaccount-v1-core","subsections":[]},{"section":"replace-serviceaccount-v1-core","subsections":[]},{"section":"patch-serviceaccount-v1-core","subsections":[]},{"section":"create-serviceaccount-v1-core","subsections":[]}]}]},{"section":"selfsubjectrulesreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectrulesreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"selfsubjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-selfsubjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"runtimeclass-v1beta1-node-k8s-io","subsections":[{"section":"-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-","subsections":[{"section":"watch-list-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"watch-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"list-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"read-runtimeclass-v1beta1-node-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-","subsections":[{"section":"delete-collection-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"delete-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"replace-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"patch-runtimeclass-v1beta1-node-k8s-io","subsections":[]},{"section":"create-runtimeclass-v1beta1-node-k8s-io","subsections":[]}]}]},{"section":"rolebinding-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-rolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"role-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-list-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-all-namespaces-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-role-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-role-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-role-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"resourcequota-v1-core","subsections":[{"section":"-strong-status-operations-resourcequota-v1-core-strong-","subsections":[{"section":"replace-status-resourcequota-v1-core","subsections":[]},{"section":"read-status-resourcequota-v1-core","subsections":[]},{"section":"patch-status-resourcequota-v1-core","subsections":[]}]},{"section":"-strong-read-operations-resourcequota-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-resourcequota-v1-core","subsections":[]},{"section":"watch-list-resourcequota-v1-core","subsections":[]},{"section":"watch-resourcequota-v1-core","subsections":[]},{"section":"list-all-namespaces-resourcequota-v1-core","subsections":[]},{"section":"list-resourcequota-v1-core","subsections":[]},{"section":"read-resourcequota-v1-core","subsections":[]}]},{"section":"-strong-write-operations-resourcequota-v1-core-strong-","subsections":[{"section":"delete-collection-resourcequota-v1-core","subsections":[]},{"section":"delete-resourcequota-v1-core","subsections":[]},{"section":"replace-resourcequota-v1-core","subsections":[]},{"section":"patch-resourcequota-v1-core","subsections":[]},{"section":"create-resourcequota-v1-core","subsections":[]}]}]},{"section":"prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[{"section":"-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]}]},{"section":"persistentvolume-v1-core","subsections":[{"section":"-strong-status-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"replace-status-persistentvolume-v1-core","subsections":[]},{"section":"read-status-persistentvolume-v1-core","subsections":[]},{"section":"patch-status-persistentvolume-v1-core","subsections":[]}]},{"section":"-strong-read-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"watch-list-persistentvolume-v1-core","subsections":[]},{"section":"watch-persistentvolume-v1-core","subsections":[]},{"section":"list-persistentvolume-v1-core","subsections":[]},{"section":"read-persistentvolume-v1-core","subsections":[]}]},{"section":"-strong-write-operations-persistentvolume-v1-core-strong-","subsections":[{"section":"delete-collection-persistentvolume-v1-core","subsections":[]},{"section":"delete-persistentvolume-v1-core","subsections":[]},{"section":"replace-persistentvolume-v1-core","subsections":[]},{"section":"patch-persistentvolume-v1-core","subsections":[]},{"section":"create-persistentvolume-v1-core","subsections":[]}]}]},{"section":"node-v1-core","subsections":[{"section":"-strong-proxy-operations-node-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-node-v1-core","subsections":[]},{"section":"replace-connect-proxy-node-v1-core","subsections":[]},{"section":"head-connect-proxy-path-node-v1-core","subsections":[]},{"section":"head-connect-proxy-node-v1-core","subsections":[]},{"section":"get-connect-proxy-path-node-v1-core","subsections":[]},{"section":"get-connect-proxy-node-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-node-v1-core","subsections":[]},{"section":"delete-connect-proxy-node-v1-core","subsections":[]},{"section":"create-connect-proxy-path-node-v1-core","subsections":[]},{"section":"create-connect-proxy-node-v1-core","subsections":[]}]},{"section":"-strong-status-operations-node-v1-core-strong-","subsections":[{"section":"replace-status-node-v1-core","subsections":[]},{"section":"read-status-node-v1-core","subsections":[]},{"section":"patch-status-node-v1-core","subsections":[]}]},{"section":"-strong-read-operations-node-v1-core-strong-","subsections":[{"section":"watch-list-node-v1-core","subsections":[]},{"section":"watch-node-v1-core","subsections":[]},{"section":"list-node-v1-core","subsections":[]},{"section":"read-node-v1-core","subsections":[]}]},{"section":"-strong-write-operations-node-v1-core-strong-","subsections":[{"section":"delete-collection-node-v1-core","subsections":[]},{"section":"delete-node-v1-core","subsections":[]},{"section":"replace-node-v1-core","subsections":[]},{"section":"patch-node-v1-core","subsections":[]},{"section":"create-node-v1-core","subsections":[]}]}]},{"section":"namespace-v1-core","subsections":[{"section":"-strong-status-operations-namespace-v1-core-strong-","subsections":[{"section":"replace-status-namespace-v1-core","subsections":[]},{"section":"read-status-namespace-v1-core","subsections":[]},{"section":"patch-status-namespace-v1-core","subsections":[]}]},{"section":"-strong-read-operations-namespace-v1-core-strong-","subsections":[{"section":"watch-list-namespace-v1-core","subsections":[]},{"section":"watch-namespace-v1-core","subsections":[]},{"section":"list-namespace-v1-core","subsections":[]},{"section":"read-namespace-v1-core","subsections":[]}]},{"section":"-strong-write-operations-namespace-v1-core-strong-","subsections":[{"section":"delete-namespace-v1-core","subsections":[]},{"section":"replace-namespace-v1-core","subsections":[]},{"section":"patch-namespace-v1-core","subsections":[]},{"section":"create-namespace-v1-core","subsections":[]}]}]},{"section":"localsubjectaccessreview-v1-authorization-k8s-io","subsections":[{"section":"-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-","subsections":[{"section":"create-localsubjectaccessreview-v1-authorization-k8s-io","subsections":[]}]}]},{"section":"lease-v1-coordination-k8s-io","subsections":[{"section":"-strong-read-operations-lease-v1-coordination-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-lease-v1-coordination-k8s-io","subsections":[]},{"section":"watch-list-lease-v1-coordination-k8s-io","subsections":[]},{"section":"watch-lease-v1-coordination-k8s-io","subsections":[]},{"section":"list-all-namespaces-lease-v1-coordination-k8s-io","subsections":[]},{"section":"list-lease-v1-coordination-k8s-io","subsections":[]},{"section":"read-lease-v1-coordination-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-lease-v1-coordination-k8s-io-strong-","subsections":[{"section":"delete-collection-lease-v1-coordination-k8s-io","subsections":[]},{"section":"delete-lease-v1-coordination-k8s-io","subsections":[]},{"section":"replace-lease-v1-coordination-k8s-io","subsections":[]},{"section":"patch-lease-v1-coordination-k8s-io","subsections":[]},{"section":"create-lease-v1-coordination-k8s-io","subsections":[]}]}]},{"section":"flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[{"section":"-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","subsections":[{"section":"delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]},{"section":"create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","subsections":[]}]}]},{"section":"componentstatus-v1-core","subsections":[{"section":"-strong-read-operations-componentstatus-v1-core-strong-","subsections":[{"section":"list-componentstatus-v1-core","subsections":[]},{"section":"read-componentstatus-v1-core","subsections":[]}]}]},{"section":"clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrolebinding-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"clusterrole-v1-rbac-authorization-k8s-io","subsections":[{"section":"-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"watch-list-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"watch-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"list-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"read-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","subsections":[{"section":"delete-collection-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"delete-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"replace-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"patch-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]},{"section":"create-clusterrole-v1-rbac-authorization-k8s-io","subsections":[]}]}]},{"section":"certificatesigningrequest-v1-certificates-k8s-io","subsections":[{"section":"-strong-status-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","subsections":[{"section":"replace-status-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"read-status-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"patch-status-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","subsections":[{"section":"watch-list-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"watch-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"list-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"read-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","subsections":[{"section":"delete-collection-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"delete-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"replace-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"patch-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]},{"section":"create-certificatesigningrequest-v1-certificates-k8s-io","subsections":[]}]}]},{"section":"binding-v1-core","subsections":[{"section":"-strong-write-operations-binding-v1-core-strong-","subsections":[{"section":"create-binding-v1-core","subsections":[]}]}]},{"section":"apiservice-v1-apiregistration-k8s-io","subsections":[{"section":"-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"replace-status-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"read-status-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"patch-status-apiservice-v1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"watch-list-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"watch-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"list-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"read-apiservice-v1-apiregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"delete-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"replace-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"patch-apiservice-v1-apiregistration-k8s-io","subsections":[]},{"section":"create-apiservice-v1-apiregistration-k8s-io","subsections":[]}]}]},{"section":"-strong-cluster-apis-strong-","subsections":[]},{"section":"podsecuritypolicy-v1beta1-policy","subsections":[{"section":"-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-","subsections":[{"section":"watch-list-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"watch-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"list-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"read-podsecuritypolicy-v1beta1-policy","subsections":[]}]},{"section":"-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-","subsections":[{"section":"delete-collection-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"delete-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"replace-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"patch-podsecuritypolicy-v1beta1-policy","subsections":[]},{"section":"create-podsecuritypolicy-v1beta1-policy","subsections":[]}]}]},{"section":"podpreset-v1alpha1-settings-k8s-io","subsections":[{"section":"-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"watch-list-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"watch-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"list-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"read-podpreset-v1alpha1-settings-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-","subsections":[{"section":"delete-collection-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"delete-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"replace-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"patch-podpreset-v1alpha1-settings-k8s-io","subsections":[]},{"section":"create-podpreset-v1alpha1-settings-k8s-io","subsections":[]}]}]},{"section":"priorityclass-v1-scheduling-k8s-io","subsections":[{"section":"-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-","subsections":[{"section":"watch-list-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"watch-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"list-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"read-priorityclass-v1-scheduling-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-","subsections":[{"section":"delete-collection-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"delete-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"replace-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"patch-priorityclass-v1-scheduling-k8s-io","subsections":[]},{"section":"create-priorityclass-v1-scheduling-k8s-io","subsections":[]}]}]},{"section":"poddisruptionbudget-v1beta1-policy","subsections":[{"section":"-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"replace-status-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"read-status-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"patch-status-poddisruptionbudget-v1beta1-policy","subsections":[]}]},{"section":"-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"watch-list-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"watch-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"list-all-namespaces-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"list-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"read-poddisruptionbudget-v1beta1-policy","subsections":[]}]},{"section":"-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-","subsections":[{"section":"delete-collection-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"delete-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"replace-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"patch-poddisruptionbudget-v1beta1-policy","subsections":[]},{"section":"create-poddisruptionbudget-v1beta1-policy","subsections":[]}]}]},{"section":"podtemplate-v1-core","subsections":[{"section":"-strong-read-operations-podtemplate-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-podtemplate-v1-core","subsections":[]},{"section":"watch-list-podtemplate-v1-core","subsections":[]},{"section":"watch-podtemplate-v1-core","subsections":[]},{"section":"list-all-namespaces-podtemplate-v1-core","subsections":[]},{"section":"list-podtemplate-v1-core","subsections":[]},{"section":"read-podtemplate-v1-core","subsections":[]}]},{"section":"-strong-write-operations-podtemplate-v1-core-strong-","subsections":[{"section":"delete-collection-podtemplate-v1-core","subsections":[]},{"section":"delete-podtemplate-v1-core","subsections":[]},{"section":"replace-podtemplate-v1-core","subsections":[]},{"section":"patch-podtemplate-v1-core","subsections":[]},{"section":"create-podtemplate-v1-core","subsections":[]}]}]},{"section":"validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[{"section":"-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","subsections":[{"section":"delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]},{"section":"create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","subsections":[]}]}]},{"section":"horizontalpodautoscaler-v1-autoscaling","subsections":[{"section":"-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"replace-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"read-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"patch-status-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]},{"section":"-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"watch-list-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"watch-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"list-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"read-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]},{"section":"-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-","subsections":[{"section":"delete-collection-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"delete-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"replace-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"patch-horizontalpodautoscaler-v1-autoscaling","subsections":[]},{"section":"create-horizontalpodautoscaler-v1-autoscaling","subsections":[]}]}]},{"section":"limitrange-v1-core","subsections":[{"section":"-strong-read-operations-limitrange-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-limitrange-v1-core","subsections":[]},{"section":"watch-list-limitrange-v1-core","subsections":[]},{"section":"watch-limitrange-v1-core","subsections":[]},{"section":"list-all-namespaces-limitrange-v1-core","subsections":[]},{"section":"list-limitrange-v1-core","subsections":[]},{"section":"read-limitrange-v1-core","subsections":[]}]},{"section":"-strong-write-operations-limitrange-v1-core-strong-","subsections":[{"section":"delete-collection-limitrange-v1-core","subsections":[]},{"section":"delete-limitrange-v1-core","subsections":[]},{"section":"replace-limitrange-v1-core","subsections":[]},{"section":"patch-limitrange-v1-core","subsections":[]},{"section":"create-limitrange-v1-core","subsections":[]}]}]},{"section":"event-v1-core","subsections":[{"section":"-strong-read-operations-event-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-event-v1-core","subsections":[]},{"section":"watch-list-event-v1-core","subsections":[]},{"section":"watch-event-v1-core","subsections":[]},{"section":"list-all-namespaces-event-v1-core","subsections":[]},{"section":"list-event-v1-core","subsections":[]},{"section":"read-event-v1-core","subsections":[]}]},{"section":"-strong-write-operations-event-v1-core-strong-","subsections":[{"section":"delete-collection-event-v1-core","subsections":[]},{"section":"delete-event-v1-core","subsections":[]},{"section":"replace-event-v1-core","subsections":[]},{"section":"patch-event-v1-core","subsections":[]},{"section":"create-event-v1-core","subsections":[]}]}]},{"section":"customresourcedefinition-v1-apiextensions-k8s-io","subsections":[{"section":"-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"replace-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"read-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"patch-status-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"watch-list-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"watch-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"list-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"read-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","subsections":[{"section":"delete-collection-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"delete-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"replace-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"patch-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]},{"section":"create-customresourcedefinition-v1-apiextensions-k8s-io","subsections":[]}]}]},{"section":"controllerrevision-v1-apps","subsections":[{"section":"-strong-read-operations-controllerrevision-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-controllerrevision-v1-apps","subsections":[]},{"section":"watch-list-controllerrevision-v1-apps","subsections":[]},{"section":"watch-controllerrevision-v1-apps","subsections":[]},{"section":"list-all-namespaces-controllerrevision-v1-apps","subsections":[]},{"section":"list-controllerrevision-v1-apps","subsections":[]},{"section":"read-controllerrevision-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-controllerrevision-v1-apps-strong-","subsections":[{"section":"delete-collection-controllerrevision-v1-apps","subsections":[]},{"section":"delete-controllerrevision-v1-apps","subsections":[]},{"section":"replace-controllerrevision-v1-apps","subsections":[]},{"section":"patch-controllerrevision-v1-apps","subsections":[]},{"section":"create-controllerrevision-v1-apps","subsections":[]}]}]},{"section":"-strong-metadata-apis-strong-","subsections":[]},{"section":"volumeattachment-v1-storage-k8s-io","subsections":[{"section":"-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"replace-status-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"read-status-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"patch-status-volumeattachment-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"watch-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"list-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"read-volumeattachment-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"delete-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"replace-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"patch-volumeattachment-v1-storage-k8s-io","subsections":[]},{"section":"create-volumeattachment-v1-storage-k8s-io","subsections":[]}]}]},{"section":"volume-v1-core","subsections":[]},{"section":"storageclass-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-storageclass-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"watch-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"list-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"read-storageclass-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-storageclass-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"delete-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"replace-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"patch-storageclass-v1-storage-k8s-io","subsections":[]},{"section":"create-storageclass-v1-storage-k8s-io","subsections":[]}]}]},{"section":"persistentvolumeclaim-v1-core","subsections":[{"section":"-strong-status-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"replace-status-persistentvolumeclaim-v1-core","subsections":[]},{"section":"read-status-persistentvolumeclaim-v1-core","subsections":[]},{"section":"patch-status-persistentvolumeclaim-v1-core","subsections":[]}]},{"section":"-strong-read-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-persistentvolumeclaim-v1-core","subsections":[]},{"section":"watch-list-persistentvolumeclaim-v1-core","subsections":[]},{"section":"watch-persistentvolumeclaim-v1-core","subsections":[]},{"section":"list-all-namespaces-persistentvolumeclaim-v1-core","subsections":[]},{"section":"list-persistentvolumeclaim-v1-core","subsections":[]},{"section":"read-persistentvolumeclaim-v1-core","subsections":[]}]},{"section":"-strong-write-operations-persistentvolumeclaim-v1-core-strong-","subsections":[{"section":"delete-collection-persistentvolumeclaim-v1-core","subsections":[]},{"section":"delete-persistentvolumeclaim-v1-core","subsections":[]},{"section":"replace-persistentvolumeclaim-v1-core","subsections":[]},{"section":"patch-persistentvolumeclaim-v1-core","subsections":[]},{"section":"create-persistentvolumeclaim-v1-core","subsections":[]}]}]},{"section":"secret-v1-core","subsections":[{"section":"-strong-read-operations-secret-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-secret-v1-core","subsections":[]},{"section":"watch-list-secret-v1-core","subsections":[]},{"section":"watch-secret-v1-core","subsections":[]},{"section":"list-all-namespaces-secret-v1-core","subsections":[]},{"section":"list-secret-v1-core","subsections":[]},{"section":"read-secret-v1-core","subsections":[]}]},{"section":"-strong-write-operations-secret-v1-core-strong-","subsections":[{"section":"delete-collection-secret-v1-core","subsections":[]},{"section":"delete-secret-v1-core","subsections":[]},{"section":"replace-secret-v1-core","subsections":[]},{"section":"patch-secret-v1-core","subsections":[]},{"section":"create-secret-v1-core","subsections":[]}]}]},{"section":"csinode-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csinode-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csinode-v1-storage-k8s-io","subsections":[]},{"section":"watch-csinode-v1-storage-k8s-io","subsections":[]},{"section":"list-csinode-v1-storage-k8s-io","subsections":[]},{"section":"read-csinode-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csinode-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csinode-v1-storage-k8s-io","subsections":[]},{"section":"delete-csinode-v1-storage-k8s-io","subsections":[]},{"section":"replace-csinode-v1-storage-k8s-io","subsections":[]},{"section":"patch-csinode-v1-storage-k8s-io","subsections":[]},{"section":"create-csinode-v1-storage-k8s-io","subsections":[]}]}]},{"section":"csidriver-v1-storage-k8s-io","subsections":[{"section":"-strong-read-operations-csidriver-v1-storage-k8s-io-strong-","subsections":[{"section":"watch-list-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"watch-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"list-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"read-csidriver-v1-storage-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-csidriver-v1-storage-k8s-io-strong-","subsections":[{"section":"delete-collection-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"delete-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"replace-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"patch-csidriver-v1-storage-k8s-io","subsections":[]},{"section":"create-csidriver-v1-storage-k8s-io","subsections":[]}]}]},{"section":"configmap-v1-core","subsections":[{"section":"-strong-read-operations-configmap-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-configmap-v1-core","subsections":[]},{"section":"watch-list-configmap-v1-core","subsections":[]},{"section":"watch-configmap-v1-core","subsections":[]},{"section":"list-all-namespaces-configmap-v1-core","subsections":[]},{"section":"list-configmap-v1-core","subsections":[]},{"section":"read-configmap-v1-core","subsections":[]}]},{"section":"-strong-write-operations-configmap-v1-core-strong-","subsections":[{"section":"delete-collection-configmap-v1-core","subsections":[]},{"section":"delete-configmap-v1-core","subsections":[]},{"section":"replace-configmap-v1-core","subsections":[]},{"section":"patch-configmap-v1-core","subsections":[]},{"section":"create-configmap-v1-core","subsections":[]}]}]},{"section":"-strong-config-and-storage-apis-strong-","subsections":[]},{"section":"service-v1-core","subsections":[{"section":"-strong-proxy-operations-service-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-service-v1-core","subsections":[]},{"section":"replace-connect-proxy-service-v1-core","subsections":[]},{"section":"head-connect-proxy-path-service-v1-core","subsections":[]},{"section":"head-connect-proxy-service-v1-core","subsections":[]},{"section":"get-connect-proxy-path-service-v1-core","subsections":[]},{"section":"get-connect-proxy-service-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-service-v1-core","subsections":[]},{"section":"delete-connect-proxy-service-v1-core","subsections":[]},{"section":"create-connect-proxy-path-service-v1-core","subsections":[]},{"section":"create-connect-proxy-service-v1-core","subsections":[]}]},{"section":"-strong-status-operations-service-v1-core-strong-","subsections":[{"section":"replace-status-service-v1-core","subsections":[]},{"section":"read-status-service-v1-core","subsections":[]},{"section":"patch-status-service-v1-core","subsections":[]}]},{"section":"-strong-read-operations-service-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-service-v1-core","subsections":[]},{"section":"watch-list-service-v1-core","subsections":[]},{"section":"watch-service-v1-core","subsections":[]},{"section":"list-all-namespaces-service-v1-core","subsections":[]},{"section":"list-service-v1-core","subsections":[]},{"section":"read-service-v1-core","subsections":[]}]},{"section":"-strong-write-operations-service-v1-core-strong-","subsections":[{"section":"delete-service-v1-core","subsections":[]},{"section":"replace-service-v1-core","subsections":[]},{"section":"patch-service-v1-core","subsections":[]},{"section":"create-service-v1-core","subsections":[]}]}]},{"section":"ingressclass-v1-networking-k8s-io","subsections":[{"section":"-strong-read-operations-ingressclass-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"watch-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"list-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"read-ingressclass-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingressclass-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"delete-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"replace-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"patch-ingressclass-v1-networking-k8s-io","subsections":[]},{"section":"create-ingressclass-v1-networking-k8s-io","subsections":[]}]}]},{"section":"ingress-v1-networking-k8s-io","subsections":[{"section":"-strong-status-operations-ingress-v1-networking-k8s-io-strong-","subsections":[{"section":"replace-status-ingress-v1-networking-k8s-io","subsections":[]},{"section":"read-status-ingress-v1-networking-k8s-io","subsections":[]},{"section":"patch-status-ingress-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-read-operations-ingress-v1-networking-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-ingress-v1-networking-k8s-io","subsections":[]},{"section":"watch-list-ingress-v1-networking-k8s-io","subsections":[]},{"section":"watch-ingress-v1-networking-k8s-io","subsections":[]},{"section":"list-all-namespaces-ingress-v1-networking-k8s-io","subsections":[]},{"section":"list-ingress-v1-networking-k8s-io","subsections":[]},{"section":"read-ingress-v1-networking-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-ingress-v1-networking-k8s-io-strong-","subsections":[{"section":"delete-collection-ingress-v1-networking-k8s-io","subsections":[]},{"section":"delete-ingress-v1-networking-k8s-io","subsections":[]},{"section":"replace-ingress-v1-networking-k8s-io","subsections":[]},{"section":"patch-ingress-v1-networking-k8s-io","subsections":[]},{"section":"create-ingress-v1-networking-k8s-io","subsections":[]}]}]},{"section":"endpointslice-v1beta1-discovery-k8s-io","subsections":[{"section":"-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","subsections":[{"section":"watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"watch-list-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"watch-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"list-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"read-endpointslice-v1beta1-discovery-k8s-io","subsections":[]}]},{"section":"-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","subsections":[{"section":"delete-collection-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"delete-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"replace-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"patch-endpointslice-v1beta1-discovery-k8s-io","subsections":[]},{"section":"create-endpointslice-v1beta1-discovery-k8s-io","subsections":[]}]}]},{"section":"endpoints-v1-core","subsections":[{"section":"-strong-read-operations-endpoints-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-endpoints-v1-core","subsections":[]},{"section":"watch-list-endpoints-v1-core","subsections":[]},{"section":"watch-endpoints-v1-core","subsections":[]},{"section":"list-all-namespaces-endpoints-v1-core","subsections":[]},{"section":"list-endpoints-v1-core","subsections":[]},{"section":"read-endpoints-v1-core","subsections":[]}]},{"section":"-strong-write-operations-endpoints-v1-core-strong-","subsections":[{"section":"delete-collection-endpoints-v1-core","subsections":[]},{"section":"delete-endpoints-v1-core","subsections":[]},{"section":"replace-endpoints-v1-core","subsections":[]},{"section":"patch-endpoints-v1-core","subsections":[]},{"section":"create-endpoints-v1-core","subsections":[]}]}]},{"section":"-strong-service-apis-strong-","subsections":[]},{"section":"statefulset-v1-apps","subsections":[{"section":"-strong-misc-operations-statefulset-v1-apps-strong-","subsections":[{"section":"patch-scale-statefulset-v1-apps","subsections":[]},{"section":"replace-scale-statefulset-v1-apps","subsections":[]},{"section":"read-scale-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-statefulset-v1-apps-strong-","subsections":[{"section":"replace-status-statefulset-v1-apps","subsections":[]},{"section":"read-status-statefulset-v1-apps","subsections":[]},{"section":"patch-status-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-statefulset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-statefulset-v1-apps","subsections":[]},{"section":"watch-list-statefulset-v1-apps","subsections":[]},{"section":"watch-statefulset-v1-apps","subsections":[]},{"section":"list-all-namespaces-statefulset-v1-apps","subsections":[]},{"section":"list-statefulset-v1-apps","subsections":[]},{"section":"read-statefulset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-statefulset-v1-apps-strong-","subsections":[{"section":"delete-collection-statefulset-v1-apps","subsections":[]},{"section":"delete-statefulset-v1-apps","subsections":[]},{"section":"replace-statefulset-v1-apps","subsections":[]},{"section":"patch-statefulset-v1-apps","subsections":[]},{"section":"create-statefulset-v1-apps","subsections":[]}]}]},{"section":"replicationcontroller-v1-core","subsections":[{"section":"-strong-misc-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"patch-scale-replicationcontroller-v1-core","subsections":[]},{"section":"replace-scale-replicationcontroller-v1-core","subsections":[]},{"section":"read-scale-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-status-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"replace-status-replicationcontroller-v1-core","subsections":[]},{"section":"read-status-replicationcontroller-v1-core","subsections":[]},{"section":"patch-status-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-read-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-replicationcontroller-v1-core","subsections":[]},{"section":"watch-list-replicationcontroller-v1-core","subsections":[]},{"section":"watch-replicationcontroller-v1-core","subsections":[]},{"section":"list-all-namespaces-replicationcontroller-v1-core","subsections":[]},{"section":"list-replicationcontroller-v1-core","subsections":[]},{"section":"read-replicationcontroller-v1-core","subsections":[]}]},{"section":"-strong-write-operations-replicationcontroller-v1-core-strong-","subsections":[{"section":"delete-collection-replicationcontroller-v1-core","subsections":[]},{"section":"delete-replicationcontroller-v1-core","subsections":[]},{"section":"replace-replicationcontroller-v1-core","subsections":[]},{"section":"patch-replicationcontroller-v1-core","subsections":[]},{"section":"create-replicationcontroller-v1-core","subsections":[]}]}]},{"section":"replicaset-v1-apps","subsections":[{"section":"-strong-misc-operations-replicaset-v1-apps-strong-","subsections":[{"section":"patch-scale-replicaset-v1-apps","subsections":[]},{"section":"replace-scale-replicaset-v1-apps","subsections":[]},{"section":"read-scale-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-replicaset-v1-apps-strong-","subsections":[{"section":"replace-status-replicaset-v1-apps","subsections":[]},{"section":"read-status-replicaset-v1-apps","subsections":[]},{"section":"patch-status-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-replicaset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-replicaset-v1-apps","subsections":[]},{"section":"watch-list-replicaset-v1-apps","subsections":[]},{"section":"watch-replicaset-v1-apps","subsections":[]},{"section":"list-all-namespaces-replicaset-v1-apps","subsections":[]},{"section":"list-replicaset-v1-apps","subsections":[]},{"section":"read-replicaset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-replicaset-v1-apps-strong-","subsections":[{"section":"delete-collection-replicaset-v1-apps","subsections":[]},{"section":"delete-replicaset-v1-apps","subsections":[]},{"section":"replace-replicaset-v1-apps","subsections":[]},{"section":"patch-replicaset-v1-apps","subsections":[]},{"section":"create-replicaset-v1-apps","subsections":[]}]}]},{"section":"pod-v1-core","subsections":[{"section":"-strong-misc-operations-pod-v1-core-strong-","subsections":[{"section":"read-log-pod-v1-core","subsections":[]}]},{"section":"-strong-proxy-operations-pod-v1-core-strong-","subsections":[{"section":"replace-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"replace-connect-proxy-pod-v1-core","subsections":[]},{"section":"head-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"head-connect-proxy-pod-v1-core","subsections":[]},{"section":"get-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"get-connect-proxy-pod-v1-core","subsections":[]},{"section":"get-connect-portforward-pod-v1-core","subsections":[]},{"section":"delete-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"delete-connect-proxy-pod-v1-core","subsections":[]},{"section":"create-connect-proxy-path-pod-v1-core","subsections":[]},{"section":"create-connect-proxy-pod-v1-core","subsections":[]},{"section":"create-connect-portforward-pod-v1-core","subsections":[]}]},{"section":"-strong-status-operations-pod-v1-core-strong-","subsections":[{"section":"replace-status-pod-v1-core","subsections":[]},{"section":"read-status-pod-v1-core","subsections":[]},{"section":"patch-status-pod-v1-core","subsections":[]}]},{"section":"-strong-read-operations-pod-v1-core-strong-","subsections":[{"section":"watch-list-all-namespaces-pod-v1-core","subsections":[]},{"section":"watch-list-pod-v1-core","subsections":[]},{"section":"watch-pod-v1-core","subsections":[]},{"section":"list-all-namespaces-pod-v1-core","subsections":[]},{"section":"list-pod-v1-core","subsections":[]},{"section":"read-pod-v1-core","subsections":[]}]},{"section":"-strong-write-operations-pod-v1-core-strong-","subsections":[{"section":"delete-collection-pod-v1-core","subsections":[]},{"section":"delete-pod-v1-core","subsections":[]},{"section":"replace-pod-v1-core","subsections":[]},{"section":"patch-pod-v1-core","subsections":[]},{"section":"create-eviction-pod-v1-core","subsections":[]},{"section":"create-pod-v1-core","subsections":[]}]}]},{"section":"job-v1-batch","subsections":[{"section":"-strong-status-operations-job-v1-batch-strong-","subsections":[{"section":"replace-status-job-v1-batch","subsections":[]},{"section":"read-status-job-v1-batch","subsections":[]},{"section":"patch-status-job-v1-batch","subsections":[]}]},{"section":"-strong-read-operations-job-v1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-job-v1-batch","subsections":[]},{"section":"watch-list-job-v1-batch","subsections":[]},{"section":"watch-job-v1-batch","subsections":[]},{"section":"list-all-namespaces-job-v1-batch","subsections":[]},{"section":"list-job-v1-batch","subsections":[]},{"section":"read-job-v1-batch","subsections":[]}]},{"section":"-strong-write-operations-job-v1-batch-strong-","subsections":[{"section":"delete-collection-job-v1-batch","subsections":[]},{"section":"delete-job-v1-batch","subsections":[]},{"section":"replace-job-v1-batch","subsections":[]},{"section":"patch-job-v1-batch","subsections":[]},{"section":"create-job-v1-batch","subsections":[]}]}]},{"section":"deployment-v1-apps","subsections":[{"section":"-strong-misc-operations-deployment-v1-apps-strong-","subsections":[{"section":"patch-scale-deployment-v1-apps","subsections":[]},{"section":"replace-scale-deployment-v1-apps","subsections":[]},{"section":"read-scale-deployment-v1-apps","subsections":[]}]},{"section":"-strong-status-operations-deployment-v1-apps-strong-","subsections":[{"section":"replace-status-deployment-v1-apps","subsections":[]},{"section":"read-status-deployment-v1-apps","subsections":[]},{"section":"patch-status-deployment-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-deployment-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-deployment-v1-apps","subsections":[]},{"section":"watch-list-deployment-v1-apps","subsections":[]},{"section":"watch-deployment-v1-apps","subsections":[]},{"section":"list-all-namespaces-deployment-v1-apps","subsections":[]},{"section":"list-deployment-v1-apps","subsections":[]},{"section":"read-deployment-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-deployment-v1-apps-strong-","subsections":[{"section":"delete-collection-deployment-v1-apps","subsections":[]},{"section":"delete-deployment-v1-apps","subsections":[]},{"section":"replace-deployment-v1-apps","subsections":[]},{"section":"patch-deployment-v1-apps","subsections":[]},{"section":"create-deployment-v1-apps","subsections":[]}]}]},{"section":"daemonset-v1-apps","subsections":[{"section":"-strong-status-operations-daemonset-v1-apps-strong-","subsections":[{"section":"replace-status-daemonset-v1-apps","subsections":[]},{"section":"read-status-daemonset-v1-apps","subsections":[]},{"section":"patch-status-daemonset-v1-apps","subsections":[]}]},{"section":"-strong-read-operations-daemonset-v1-apps-strong-","subsections":[{"section":"watch-list-all-namespaces-daemonset-v1-apps","subsections":[]},{"section":"watch-list-daemonset-v1-apps","subsections":[]},{"section":"watch-daemonset-v1-apps","subsections":[]},{"section":"list-all-namespaces-daemonset-v1-apps","subsections":[]},{"section":"list-daemonset-v1-apps","subsections":[]},{"section":"read-daemonset-v1-apps","subsections":[]}]},{"section":"-strong-write-operations-daemonset-v1-apps-strong-","subsections":[{"section":"delete-collection-daemonset-v1-apps","subsections":[]},{"section":"delete-daemonset-v1-apps","subsections":[]},{"section":"replace-daemonset-v1-apps","subsections":[]},{"section":"patch-daemonset-v1-apps","subsections":[]},{"section":"create-daemonset-v1-apps","subsections":[]}]}]},{"section":"cronjob-v1beta1-batch","subsections":[{"section":"-strong-status-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"replace-status-cronjob-v1beta1-batch","subsections":[]},{"section":"read-status-cronjob-v1beta1-batch","subsections":[]},{"section":"patch-status-cronjob-v1beta1-batch","subsections":[]}]},{"section":"-strong-read-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"watch-list-all-namespaces-cronjob-v1beta1-batch","subsections":[]},{"section":"watch-list-cronjob-v1beta1-batch","subsections":[]},{"section":"watch-cronjob-v1beta1-batch","subsections":[]},{"section":"list-all-namespaces-cronjob-v1beta1-batch","subsections":[]},{"section":"list-cronjob-v1beta1-batch","subsections":[]},{"section":"read-cronjob-v1beta1-batch","subsections":[]}]},{"section":"-strong-write-operations-cronjob-v1beta1-batch-strong-","subsections":[{"section":"delete-collection-cronjob-v1beta1-batch","subsections":[]},{"section":"delete-cronjob-v1beta1-batch","subsections":[]},{"section":"replace-cronjob-v1beta1-batch","subsections":[]},{"section":"patch-cronjob-v1beta1-batch","subsections":[]},{"section":"create-cronjob-v1beta1-batch","subsections":[]}]}]},{"section":"container-v1-core","subsections":[]},{"section":"-strong-workloads-apis-strong-","subsections":[]},{"section":"-strong-api-groups-strong-","subsections":[]},{"section":"-strong-api-overview-strong-","subsections":[]}],"flatToc":["webhookclientconfig-v1beta1-apiextensions-k8s-io","webhookclientconfig-v1beta1-admissionregistration-k8s-io","webhookclientconfig-v1-apiextensions-k8s-io","volumenoderesources-v1beta1-storage-k8s-io","volumeerror-v1alpha1-storage-k8s-io","volumeerror-v1beta1-storage-k8s-io","volumeattachmentsource-v1alpha1-storage-k8s-io","volumeattachmentsource-v1beta1-storage-k8s-io","watch-list-volumeattachment-v1alpha1-storage-k8s-io","watch-volumeattachment-v1alpha1-storage-k8s-io","list-volumeattachment-v1alpha1-storage-k8s-io","read-volumeattachment-v1alpha1-storage-k8s-io","-strong-read-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1alpha1-storage-k8s-io","delete-volumeattachment-v1alpha1-storage-k8s-io","replace-volumeattachment-v1alpha1-storage-k8s-io","patch-volumeattachment-v1alpha1-storage-k8s-io","create-volumeattachment-v1alpha1-storage-k8s-io","-strong-write-operations-volumeattachment-v1alpha1-storage-k8s-io-strong-","volumeattachment-v1alpha1-storage-k8s-io","watch-list-volumeattachment-v1beta1-storage-k8s-io","watch-volumeattachment-v1beta1-storage-k8s-io","list-volumeattachment-v1beta1-storage-k8s-io","read-volumeattachment-v1beta1-storage-k8s-io","-strong-read-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1beta1-storage-k8s-io","delete-volumeattachment-v1beta1-storage-k8s-io","replace-volumeattachment-v1beta1-storage-k8s-io","patch-volumeattachment-v1beta1-storage-k8s-io","create-volumeattachment-v1beta1-storage-k8s-io","-strong-write-operations-volumeattachment-v1beta1-storage-k8s-io-strong-","volumeattachment-v1beta1-storage-k8s-io","watch-list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","watch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","list-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","read-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-read-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","delete-collection-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","delete-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","replace-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","patch-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","create-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-write-operations-validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","validatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","validatingwebhook-v1beta1-admissionregistration-k8s-io","userinfo-v1beta1-authentication-k8s-io","create-tokenreview-v1beta1-authentication-k8s-io","-strong-write-operations-tokenreview-v1beta1-authentication-k8s-io-strong-","tokenreview-v1beta1-authentication-k8s-io","subjectrulesreviewstatus-v1beta1-authorization-k8s-io","create-subjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-subjectaccessreview-v1beta1-authorization-k8s-io-strong-","subjectaccessreview-v1beta1-authorization-k8s-io","subject-v1alpha1-rbac-authorization-k8s-io","subject-v1beta1-rbac-authorization-k8s-io","subject-v1-rbac-authorization-k8s-io","watch-list-storageclass-v1beta1-storage-k8s-io","watch-storageclass-v1beta1-storage-k8s-io","list-storageclass-v1beta1-storage-k8s-io","read-storageclass-v1beta1-storage-k8s-io","-strong-read-operations-storageclass-v1beta1-storage-k8s-io-strong-","delete-collection-storageclass-v1beta1-storage-k8s-io","delete-storageclass-v1beta1-storage-k8s-io","replace-storageclass-v1beta1-storage-k8s-io","patch-storageclass-v1beta1-storage-k8s-io","create-storageclass-v1beta1-storage-k8s-io","-strong-write-operations-storageclass-v1beta1-storage-k8s-io-strong-","storageclass-v1beta1-storage-k8s-io","servicereference-v1beta1-apiregistration-k8s-io","servicereference-v1beta1-apiextensions-k8s-io","servicereference-v1beta1-admissionregistration-k8s-io","servicereference-v1-apiregistration-k8s-io","servicereference-v1-apiextensions-k8s-io","create-selfsubjectrulesreview-v1beta1-authorization-k8s-io","-strong-write-operations-selfsubjectrulesreview-v1beta1-authorization-k8s-io-strong-","selfsubjectrulesreview-v1beta1-authorization-k8s-io","create-selfsubjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-selfsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","selfsubjectaccessreview-v1beta1-authorization-k8s-io","scheduling-v1alpha1-node-k8s-io","watch-list-runtimeclass-v1alpha1-node-k8s-io","watch-runtimeclass-v1alpha1-node-k8s-io","list-runtimeclass-v1alpha1-node-k8s-io","read-runtimeclass-v1alpha1-node-k8s-io","-strong-read-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","delete-collection-runtimeclass-v1alpha1-node-k8s-io","delete-runtimeclass-v1alpha1-node-k8s-io","replace-runtimeclass-v1alpha1-node-k8s-io","patch-runtimeclass-v1alpha1-node-k8s-io","create-runtimeclass-v1alpha1-node-k8s-io","-strong-write-operations-runtimeclass-v1alpha1-node-k8s-io-strong-","runtimeclass-v1alpha1-node-k8s-io","rulewithoperations-v1beta1-admissionregistration-k8s-io","roleref-v1alpha1-rbac-authorization-k8s-io","roleref-v1beta1-rbac-authorization-k8s-io","watch-list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-rolebinding-v1alpha1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1alpha1-rbac-authorization-k8s-io","list-rolebinding-v1alpha1-rbac-authorization-k8s-io","read-rolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1alpha1-rbac-authorization-k8s-io","delete-rolebinding-v1alpha1-rbac-authorization-k8s-io","replace-rolebinding-v1alpha1-rbac-authorization-k8s-io","patch-rolebinding-v1alpha1-rbac-authorization-k8s-io","create-rolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","rolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-rolebinding-v1beta1-rbac-authorization-k8s-io","watch-rolebinding-v1beta1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1beta1-rbac-authorization-k8s-io","list-rolebinding-v1beta1-rbac-authorization-k8s-io","read-rolebinding-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1beta1-rbac-authorization-k8s-io","delete-rolebinding-v1beta1-rbac-authorization-k8s-io","replace-rolebinding-v1beta1-rbac-authorization-k8s-io","patch-rolebinding-v1beta1-rbac-authorization-k8s-io","create-rolebinding-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1beta1-rbac-authorization-k8s-io-strong-","rolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","watch-list-role-v1alpha1-rbac-authorization-k8s-io","watch-role-v1alpha1-rbac-authorization-k8s-io","list-all-namespaces-role-v1alpha1-rbac-authorization-k8s-io","list-role-v1alpha1-rbac-authorization-k8s-io","read-role-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1alpha1-rbac-authorization-k8s-io","delete-role-v1alpha1-rbac-authorization-k8s-io","replace-role-v1alpha1-rbac-authorization-k8s-io","patch-role-v1alpha1-rbac-authorization-k8s-io","create-role-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-role-v1alpha1-rbac-authorization-k8s-io-strong-","role-v1alpha1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","watch-list-role-v1beta1-rbac-authorization-k8s-io","watch-role-v1beta1-rbac-authorization-k8s-io","list-all-namespaces-role-v1beta1-rbac-authorization-k8s-io","list-role-v1beta1-rbac-authorization-k8s-io","read-role-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1beta1-rbac-authorization-k8s-io","delete-role-v1beta1-rbac-authorization-k8s-io","replace-role-v1beta1-rbac-authorization-k8s-io","patch-role-v1beta1-rbac-authorization-k8s-io","create-role-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-role-v1beta1-rbac-authorization-k8s-io-strong-","role-v1beta1-rbac-authorization-k8s-io","resourcerule-v1beta1-authorization-k8s-io","resourcemetricstatus-v2beta1-autoscaling","resourcemetricsource-v2beta1-autoscaling","resourceattributes-v1beta1-authorization-k8s-io","watch-list-priorityclass-v1alpha1-scheduling-k8s-io","watch-priorityclass-v1alpha1-scheduling-k8s-io","list-priorityclass-v1alpha1-scheduling-k8s-io","read-priorityclass-v1alpha1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1alpha1-scheduling-k8s-io","delete-priorityclass-v1alpha1-scheduling-k8s-io","replace-priorityclass-v1alpha1-scheduling-k8s-io","patch-priorityclass-v1alpha1-scheduling-k8s-io","create-priorityclass-v1alpha1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1alpha1-scheduling-k8s-io-strong-","priorityclass-v1alpha1-scheduling-k8s-io","watch-list-priorityclass-v1beta1-scheduling-k8s-io","watch-priorityclass-v1beta1-scheduling-k8s-io","list-priorityclass-v1beta1-scheduling-k8s-io","read-priorityclass-v1beta1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1beta1-scheduling-k8s-io","delete-priorityclass-v1beta1-scheduling-k8s-io","replace-priorityclass-v1beta1-scheduling-k8s-io","patch-priorityclass-v1beta1-scheduling-k8s-io","create-priorityclass-v1beta1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1beta1-scheduling-k8s-io-strong-","priorityclass-v1beta1-scheduling-k8s-io","policyrule-v1alpha1-rbac-authorization-k8s-io","policyrule-v1beta1-rbac-authorization-k8s-io","podsmetricstatus-v2beta1-autoscaling","podsmetricsource-v2beta1-autoscaling","overhead-v1alpha1-node-k8s-io","objectmetricstatus-v2beta1-autoscaling","objectmetricsource-v2beta1-autoscaling","nonresourcerule-v1beta1-authorization-k8s-io","nonresourceattributes-v1beta1-authorization-k8s-io","watch-list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","watch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","list-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","read-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-read-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","delete-collection-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","delete-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","replace-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","patch-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","create-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","-strong-write-operations-mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io-strong-","mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io","mutatingwebhook-v1beta1-admissionregistration-k8s-io","metricstatus-v2beta1-autoscaling","metricspec-v2beta1-autoscaling","create-localsubjectaccessreview-v1beta1-authorization-k8s-io","-strong-write-operations-localsubjectaccessreview-v1beta1-authorization-k8s-io-strong-","localsubjectaccessreview-v1beta1-authorization-k8s-io","watch-list-all-namespaces-lease-v1beta1-coordination-k8s-io","watch-list-lease-v1beta1-coordination-k8s-io","watch-lease-v1beta1-coordination-k8s-io","list-all-namespaces-lease-v1beta1-coordination-k8s-io","list-lease-v1beta1-coordination-k8s-io","read-lease-v1beta1-coordination-k8s-io","-strong-read-operations-lease-v1beta1-coordination-k8s-io-strong-","delete-collection-lease-v1beta1-coordination-k8s-io","delete-lease-v1beta1-coordination-k8s-io","replace-lease-v1beta1-coordination-k8s-io","patch-lease-v1beta1-coordination-k8s-io","create-lease-v1beta1-coordination-k8s-io","-strong-write-operations-lease-v1beta1-coordination-k8s-io-strong-","lease-v1beta1-coordination-k8s-io","jobtemplatespec-v2alpha1-batch","jsonschemapropsorbool-v1beta1-apiextensions-k8s-io","jsonschemapropsorarray-v1beta1-apiextensions-k8s-io","jsonschemaprops-v1beta1-apiextensions-k8s-io","json-v1beta1-apiextensions-k8s-io","ingresstls-v1beta1-networking-k8s-io","ingresstls-v1beta1-extensions","ingressrule-v1beta1-networking-k8s-io","ingressrule-v1beta1-extensions","watch-list-ingressclass-v1beta1-networking-k8s-io","watch-ingressclass-v1beta1-networking-k8s-io","list-ingressclass-v1beta1-networking-k8s-io","read-ingressclass-v1beta1-networking-k8s-io","-strong-read-operations-ingressclass-v1beta1-networking-k8s-io-strong-","delete-collection-ingressclass-v1beta1-networking-k8s-io","delete-ingressclass-v1beta1-networking-k8s-io","replace-ingressclass-v1beta1-networking-k8s-io","patch-ingressclass-v1beta1-networking-k8s-io","create-ingressclass-v1beta1-networking-k8s-io","-strong-write-operations-ingressclass-v1beta1-networking-k8s-io-strong-","ingressclass-v1beta1-networking-k8s-io","ingressbackend-v1beta1-networking-k8s-io","ingressbackend-v1beta1-extensions","replace-status-ingress-v1beta1-networking-k8s-io","read-status-ingress-v1beta1-networking-k8s-io","patch-status-ingress-v1beta1-networking-k8s-io","-strong-status-operations-ingress-v1beta1-networking-k8s-io-strong-","watch-list-all-namespaces-ingress-v1beta1-networking-k8s-io","watch-list-ingress-v1beta1-networking-k8s-io","watch-ingress-v1beta1-networking-k8s-io","list-all-namespaces-ingress-v1beta1-networking-k8s-io","list-ingress-v1beta1-networking-k8s-io","read-ingress-v1beta1-networking-k8s-io","-strong-read-operations-ingress-v1beta1-networking-k8s-io-strong-","delete-collection-ingress-v1beta1-networking-k8s-io","delete-ingress-v1beta1-networking-k8s-io","replace-ingress-v1beta1-networking-k8s-io","patch-ingress-v1beta1-networking-k8s-io","create-ingress-v1beta1-networking-k8s-io","-strong-write-operations-ingress-v1beta1-networking-k8s-io-strong-","ingress-v1beta1-networking-k8s-io","replace-status-ingress-v1beta1-extensions","read-status-ingress-v1beta1-extensions","patch-status-ingress-v1beta1-extensions","-strong-status-operations-ingress-v1beta1-extensions-strong-","watch-list-all-namespaces-ingress-v1beta1-extensions","watch-list-ingress-v1beta1-extensions","watch-ingress-v1beta1-extensions","list-all-namespaces-ingress-v1beta1-extensions","list-ingress-v1beta1-extensions","read-ingress-v1beta1-extensions","-strong-read-operations-ingress-v1beta1-extensions-strong-","delete-collection-ingress-v1beta1-extensions","delete-ingress-v1beta1-extensions","replace-ingress-v1beta1-extensions","patch-ingress-v1beta1-extensions","create-ingress-v1beta1-extensions","-strong-write-operations-ingress-v1beta1-extensions-strong-","ingress-v1beta1-extensions","horizontalpodautoscalercondition-v2beta1-autoscaling","replace-status-horizontalpodautoscaler-v2beta1-autoscaling","read-status-horizontalpodautoscaler-v2beta1-autoscaling","patch-status-horizontalpodautoscaler-v2beta1-autoscaling","-strong-status-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","watch-list-horizontalpodautoscaler-v2beta1-autoscaling","watch-horizontalpodautoscaler-v2beta1-autoscaling","list-all-namespaces-horizontalpodautoscaler-v2beta1-autoscaling","list-horizontalpodautoscaler-v2beta1-autoscaling","read-horizontalpodautoscaler-v2beta1-autoscaling","-strong-read-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v2beta1-autoscaling","delete-horizontalpodautoscaler-v2beta1-autoscaling","replace-horizontalpodautoscaler-v2beta1-autoscaling","patch-horizontalpodautoscaler-v2beta1-autoscaling","create-horizontalpodautoscaler-v2beta1-autoscaling","-strong-write-operations-horizontalpodautoscaler-v2beta1-autoscaling-strong-","horizontalpodautoscaler-v2beta1-autoscaling","replace-status-horizontalpodautoscaler-v2beta2-autoscaling","read-status-horizontalpodautoscaler-v2beta2-autoscaling","patch-status-horizontalpodautoscaler-v2beta2-autoscaling","-strong-status-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","watch-list-horizontalpodautoscaler-v2beta2-autoscaling","watch-horizontalpodautoscaler-v2beta2-autoscaling","list-all-namespaces-horizontalpodautoscaler-v2beta2-autoscaling","list-horizontalpodautoscaler-v2beta2-autoscaling","read-horizontalpodautoscaler-v2beta2-autoscaling","-strong-read-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v2beta2-autoscaling","delete-horizontalpodautoscaler-v2beta2-autoscaling","replace-horizontalpodautoscaler-v2beta2-autoscaling","patch-horizontalpodautoscaler-v2beta2-autoscaling","create-horizontalpodautoscaler-v2beta2-autoscaling","-strong-write-operations-horizontalpodautoscaler-v2beta2-autoscaling-strong-","horizontalpodautoscaler-v2beta2-autoscaling","httpingressrulevalue-v1beta1-networking-k8s-io","httpingressrulevalue-v1beta1-extensions","httpingresspath-v1beta1-networking-k8s-io","httpingresspath-v1beta1-extensions","externalmetricstatus-v2beta1-autoscaling","externalmetricsource-v2beta1-autoscaling","externaldocumentation-v1beta1-apiextensions-k8s-io","eventseries-v1beta1-events-k8s-io","eventseries-v1-events-k8s-io","watch-list-all-namespaces-event-v1beta1-events-k8s-io","watch-list-event-v1beta1-events-k8s-io","watch-event-v1beta1-events-k8s-io","list-all-namespaces-event-v1beta1-events-k8s-io","list-event-v1beta1-events-k8s-io","read-event-v1beta1-events-k8s-io","-strong-read-operations-event-v1beta1-events-k8s-io-strong-","delete-collection-event-v1beta1-events-k8s-io","delete-event-v1beta1-events-k8s-io","replace-event-v1beta1-events-k8s-io","patch-event-v1beta1-events-k8s-io","create-event-v1beta1-events-k8s-io","-strong-write-operations-event-v1beta1-events-k8s-io-strong-","event-v1beta1-events-k8s-io","watch-list-all-namespaces-event-v1-events-k8s-io","watch-list-event-v1-events-k8s-io","watch-event-v1-events-k8s-io","list-all-namespaces-event-v1-events-k8s-io","list-event-v1-events-k8s-io","read-event-v1-events-k8s-io","-strong-read-operations-event-v1-events-k8s-io-strong-","delete-collection-event-v1-events-k8s-io","delete-event-v1-events-k8s-io","replace-event-v1-events-k8s-io","patch-event-v1-events-k8s-io","create-event-v1-events-k8s-io","-strong-write-operations-event-v1-events-k8s-io-strong-","event-v1-events-k8s-io","endpointport-v1beta1-discovery-k8s-io","customresourcevalidation-v1beta1-apiextensions-k8s-io","customresourcesubresources-v1beta1-apiextensions-k8s-io","customresourcesubresourcestatus-v1beta1-apiextensions-k8s-io","customresourcesubresourcescale-v1beta1-apiextensions-k8s-io","customresourcedefinitionversion-v1beta1-apiextensions-k8s-io","customresourcedefinitionnames-v1beta1-apiextensions-k8s-io","customresourcedefinitioncondition-v1beta1-apiextensions-k8s-io","replace-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","read-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","patch-status-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-status-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","watch-list-customresourcedefinition-v1beta1-apiextensions-k8s-io","watch-customresourcedefinition-v1beta1-apiextensions-k8s-io","list-customresourcedefinition-v1beta1-apiextensions-k8s-io","read-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-read-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","delete-collection-customresourcedefinition-v1beta1-apiextensions-k8s-io","delete-customresourcedefinition-v1beta1-apiextensions-k8s-io","replace-customresourcedefinition-v1beta1-apiextensions-k8s-io","patch-customresourcedefinition-v1beta1-apiextensions-k8s-io","create-customresourcedefinition-v1beta1-apiextensions-k8s-io","-strong-write-operations-customresourcedefinition-v1beta1-apiextensions-k8s-io-strong-","customresourcedefinition-v1beta1-apiextensions-k8s-io","customresourceconversion-v1beta1-apiextensions-k8s-io","customresourcecolumndefinition-v1beta1-apiextensions-k8s-io","crossversionobjectreference-v2beta1-autoscaling","crossversionobjectreference-v2beta2-autoscaling","replace-status-cronjob-v2alpha1-batch","read-status-cronjob-v2alpha1-batch","patch-status-cronjob-v2alpha1-batch","-strong-status-operations-cronjob-v2alpha1-batch-strong-","watch-list-all-namespaces-cronjob-v2alpha1-batch","watch-list-cronjob-v2alpha1-batch","watch-cronjob-v2alpha1-batch","list-all-namespaces-cronjob-v2alpha1-batch","list-cronjob-v2alpha1-batch","read-cronjob-v2alpha1-batch","-strong-read-operations-cronjob-v2alpha1-batch-strong-","delete-collection-cronjob-v2alpha1-batch","delete-cronjob-v2alpha1-batch","replace-cronjob-v2alpha1-batch","patch-cronjob-v2alpha1-batch","create-cronjob-v2alpha1-batch","-strong-write-operations-cronjob-v2alpha1-batch-strong-","cronjob-v2alpha1-batch","watch-list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","list-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","read-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","create-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1alpha1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1alpha1-rbac-authorization-k8s-io","watch-list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","list-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","read-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","create-clusterrolebinding-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1beta1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1beta1-rbac-authorization-k8s-io","watch-list-clusterrole-v1alpha1-rbac-authorization-k8s-io","watch-clusterrole-v1alpha1-rbac-authorization-k8s-io","list-clusterrole-v1alpha1-rbac-authorization-k8s-io","read-clusterrole-v1alpha1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1alpha1-rbac-authorization-k8s-io","delete-clusterrole-v1alpha1-rbac-authorization-k8s-io","replace-clusterrole-v1alpha1-rbac-authorization-k8s-io","patch-clusterrole-v1alpha1-rbac-authorization-k8s-io","create-clusterrole-v1alpha1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1alpha1-rbac-authorization-k8s-io-strong-","clusterrole-v1alpha1-rbac-authorization-k8s-io","watch-list-clusterrole-v1beta1-rbac-authorization-k8s-io","watch-clusterrole-v1beta1-rbac-authorization-k8s-io","list-clusterrole-v1beta1-rbac-authorization-k8s-io","read-clusterrole-v1beta1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1beta1-rbac-authorization-k8s-io","delete-clusterrole-v1beta1-rbac-authorization-k8s-io","replace-clusterrole-v1beta1-rbac-authorization-k8s-io","patch-clusterrole-v1beta1-rbac-authorization-k8s-io","create-clusterrole-v1beta1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1beta1-rbac-authorization-k8s-io-strong-","clusterrole-v1beta1-rbac-authorization-k8s-io","certificatesigningrequestcondition-v1beta1-certificates-k8s-io","replace-status-certificatesigningrequest-v1beta1-certificates-k8s-io","read-status-certificatesigningrequest-v1beta1-certificates-k8s-io","patch-status-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-status-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","watch-list-certificatesigningrequest-v1beta1-certificates-k8s-io","watch-certificatesigningrequest-v1beta1-certificates-k8s-io","list-certificatesigningrequest-v1beta1-certificates-k8s-io","read-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-read-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","delete-collection-certificatesigningrequest-v1beta1-certificates-k8s-io","delete-certificatesigningrequest-v1beta1-certificates-k8s-io","replace-certificatesigningrequest-v1beta1-certificates-k8s-io","patch-certificatesigningrequest-v1beta1-certificates-k8s-io","create-certificatesigningrequest-v1beta1-certificates-k8s-io","-strong-write-operations-certificatesigningrequest-v1beta1-certificates-k8s-io-strong-","certificatesigningrequest-v1beta1-certificates-k8s-io","csinodedriver-v1beta1-storage-k8s-io","watch-list-csinode-v1beta1-storage-k8s-io","watch-csinode-v1beta1-storage-k8s-io","list-csinode-v1beta1-storage-k8s-io","read-csinode-v1beta1-storage-k8s-io","-strong-read-operations-csinode-v1beta1-storage-k8s-io-strong-","delete-collection-csinode-v1beta1-storage-k8s-io","delete-csinode-v1beta1-storage-k8s-io","replace-csinode-v1beta1-storage-k8s-io","patch-csinode-v1beta1-storage-k8s-io","create-csinode-v1beta1-storage-k8s-io","-strong-write-operations-csinode-v1beta1-storage-k8s-io-strong-","csinode-v1beta1-storage-k8s-io","watch-list-csidriver-v1beta1-storage-k8s-io","watch-csidriver-v1beta1-storage-k8s-io","list-csidriver-v1beta1-storage-k8s-io","read-csidriver-v1beta1-storage-k8s-io","-strong-read-operations-csidriver-v1beta1-storage-k8s-io-strong-","delete-collection-csidriver-v1beta1-storage-k8s-io","delete-csidriver-v1beta1-storage-k8s-io","replace-csidriver-v1beta1-storage-k8s-io","patch-csidriver-v1beta1-storage-k8s-io","create-csidriver-v1beta1-storage-k8s-io","-strong-write-operations-csidriver-v1beta1-storage-k8s-io-strong-","csidriver-v1beta1-storage-k8s-io","aggregationrule-v1alpha1-rbac-authorization-k8s-io","aggregationrule-v1beta1-rbac-authorization-k8s-io","apiservicecondition-v1beta1-apiregistration-k8s-io","replace-status-apiservice-v1beta1-apiregistration-k8s-io","read-status-apiservice-v1beta1-apiregistration-k8s-io","patch-status-apiservice-v1beta1-apiregistration-k8s-io","-strong-status-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","watch-list-apiservice-v1beta1-apiregistration-k8s-io","watch-apiservice-v1beta1-apiregistration-k8s-io","list-apiservice-v1beta1-apiregistration-k8s-io","read-apiservice-v1beta1-apiregistration-k8s-io","-strong-read-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","delete-collection-apiservice-v1beta1-apiregistration-k8s-io","delete-apiservice-v1beta1-apiregistration-k8s-io","replace-apiservice-v1beta1-apiregistration-k8s-io","patch-apiservice-v1beta1-apiregistration-k8s-io","create-apiservice-v1beta1-apiregistration-k8s-io","-strong-write-operations-apiservice-v1beta1-apiregistration-k8s-io-strong-","apiservice-v1beta1-apiregistration-k8s-io","-strong-old-api-versions-strong-","windowssecuritycontextoptions-v1-core","weightedpodaffinityterm-v1-core","webhookconversion-v1-apiextensions-k8s-io","webhookclientconfig-v1-admissionregistration-k8s-io","watchevent-v1-meta","vspherevirtualdiskvolumesource-v1-core","volumeprojection-v1-core","volumenoderesources-v1-storage-k8s-io","volumenodeaffinity-v1-core","volumemount-v1-core","volumeerror-v1-storage-k8s-io","volumedevice-v1-core","volumeattachmentsource-v1-storage-k8s-io","validatingwebhook-v1-admissionregistration-k8s-io","usersubject-v1alpha1-flowcontrol-apiserver-k8s-io","userinfo-v1-authentication-k8s-io","typedlocalobjectreference-v1-core","topologyspreadconstraint-v1-core","topologyselectorterm-v1-core","topologyselectorlabelrequirement-v1-core","toleration-v1-core","time-v1-meta","taint-v1-core","tcpsocketaction-v1-core","sysctl-v1-core","supplementalgroupsstrategyoptions-v1beta1-policy","subjectrulesreviewstatus-v1-authorization-k8s-io","subject-v1alpha1-flowcontrol-apiserver-k8s-io","storageosvolumesource-v1-core","storageospersistentvolumesource-v1-core","statusdetails-v1-meta","statuscause-v1-meta","status-v1-meta","statefulsetupdatestrategy-v1-apps","statefulsetcondition-v1-apps","sessionaffinityconfig-v1-core","servicereference-v1-admissionregistration-k8s-io","serviceport-v1-core","servicebackendport-v1-networking-k8s-io","serviceaccounttokenprojection-v1-core","serviceaccountsubject-v1alpha1-flowcontrol-apiserver-k8s-io","serveraddressbyclientcidr-v1-meta","securitycontext-v1-core","secretvolumesource-v1-core","secretreference-v1-core","secretprojection-v1-core","secretkeyselector-v1-core","secretenvsource-v1-core","seccompprofile-v1-core","scopedresourceselectorrequirement-v1-core","scopeselector-v1-core","scheduling-v1beta1-node-k8s-io","scaleiovolumesource-v1-core","scaleiopersistentvolumesource-v1-core","scale-v1-autoscaling","selinuxstrategyoptions-v1beta1-policy","selinuxoptions-v1-core","runtimeclassstrategyoptions-v1beta1-policy","runasuserstrategyoptions-v1beta1-policy","runasgroupstrategyoptions-v1beta1-policy","rulewithoperations-v1-admissionregistration-k8s-io","rollingupdatestatefulsetstrategy-v1-apps","roleref-v1-rbac-authorization-k8s-io","resourcerule-v1-authorization-k8s-io","resourcerequirements-v1-core","resourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","resourcemetricstatus-v2beta2-autoscaling","resourcemetricsource-v2beta2-autoscaling","resourcefieldselector-v1-core","resourceattributes-v1-authorization-k8s-io","replicationcontrollercondition-v1-core","replicasetcondition-v1-apps","rbdvolumesource-v1-core","rbdpersistentvolumesource-v1-core","quobytevolumesource-v1-core","queuingconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","quantity-resource-core","projectedvolumesource-v1-core","probe-v1-core","prioritylevelconfigurationreference-v1alpha1-flowcontrol-apiserver-k8s-io","prioritylevelconfigurationcondition-v1alpha1-flowcontrol-apiserver-k8s-io","preferredschedulingterm-v1-core","preconditions-v1-meta","portworxvolumesource-v1-core","policyruleswithsubjects-v1alpha1-flowcontrol-apiserver-k8s-io","policyrule-v1-rbac-authorization-k8s-io","podsmetricstatus-v2beta2-autoscaling","podsmetricsource-v2beta2-autoscaling","podsecuritycontext-v1-core","podreadinessgate-v1-core","podip-v1-core","poddnsconfigoption-v1-core","poddnsconfig-v1-core","podcondition-v1-core","podantiaffinity-v1-core","podaffinityterm-v1-core","podaffinity-v1-core","photonpersistentdiskvolumesource-v1-core","persistentvolumeclaimvolumesource-v1-core","persistentvolumeclaimtemplate-v1-core","persistentvolumeclaimcondition-v1-core","patch-v1-meta","ownerreference-v1-meta","overhead-v1beta1-node-k8s-io","objectreference-v1-core","objectmetricstatus-v2beta2-autoscaling","objectmetricsource-v2beta2-autoscaling","objectmeta-v1-meta","objectfieldselector-v1-core","nonresourcerule-v1-authorization-k8s-io","nonresourcepolicyrule-v1alpha1-flowcontrol-apiserver-k8s-io","nonresourceattributes-v1-authorization-k8s-io","nodesysteminfo-v1-core","nodeselectorterm-v1-core","nodeselectorrequirement-v1-core","nodeselector-v1-core","nodedaemonendpoints-v1-core","nodeconfigstatus-v1-core","nodeconfigsource-v1-core","nodecondition-v1-core","nodeaffinity-v1-core","nodeaddress-v1-core","networkpolicyport-v1-networking-k8s-io","networkpolicypeer-v1-networking-k8s-io","networkpolicyingressrule-v1-networking-k8s-io","networkpolicyegressrule-v1-networking-k8s-io","namespacecondition-v1-core","nfsvolumesource-v1-core","mutatingwebhook-v1-admissionregistration-k8s-io","microtime-v1-meta","metricvaluestatus-v2beta2-autoscaling","metrictarget-v2beta2-autoscaling","metricstatus-v2beta2-autoscaling","metricspec-v2beta2-autoscaling","metricidentifier-v2beta2-autoscaling","managedfieldsentry-v1-meta","localvolumesource-v1-core","localobjectreference-v1-core","loadbalancerstatus-v1-core","loadbalanceringress-v1-core","listmeta-v1-meta","limitedprioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","limitresponse-v1alpha1-flowcontrol-apiserver-k8s-io","limitrangeitem-v1-core","lifecycle-v1-core","labelselectorrequirement-v1-meta","labelselector-v1-meta","keytopath-v1-core","jobtemplatespec-v1beta1-batch","jobcondition-v1-batch","jsonschemapropsorbool-v1-apiextensions-k8s-io","jsonschemapropsorarray-v1-apiextensions-k8s-io","jsonschemaprops-v1-apiextensions-k8s-io","json-v1-apiextensions-k8s-io","ingresstls-v1-networking-k8s-io","ingressservicebackend-v1-networking-k8s-io","ingressrule-v1-networking-k8s-io","ingressbackend-v1-networking-k8s-io","iscsivolumesource-v1-core","iscsipersistentvolumesource-v1-core","ipblock-v1-networking-k8s-io","idrange-v1beta1-policy","hostportrange-v1beta1-policy","hostpathvolumesource-v1-core","hostalias-v1-core","horizontalpodautoscalercondition-v2beta2-autoscaling","horizontalpodautoscalerbehavior-v2beta2-autoscaling","handler-v1-core","httpingressrulevalue-v1-networking-k8s-io","httpingresspath-v1-networking-k8s-io","httpheader-v1-core","httpgetaction-v1-core","hpascalingrules-v2beta2-autoscaling","hpascalingpolicy-v2beta2-autoscaling","groupversionfordiscovery-v1-meta","groupsubject-v1alpha1-flowcontrol-apiserver-k8s-io","glusterfsvolumesource-v1-core","glusterfspersistentvolumesource-v1-core","gitrepovolumesource-v1-core","gcepersistentdiskvolumesource-v1-core","flowschemacondition-v1alpha1-flowcontrol-apiserver-k8s-io","flowdistinguishermethod-v1alpha1-flowcontrol-apiserver-k8s-io","flockervolumesource-v1-core","flexvolumesource-v1-core","flexpersistentvolumesource-v1-core","fieldsv1-v1-meta","fsgroupstrategyoptions-v1beta1-policy","fcvolumesource-v1-core","externalmetricstatus-v2beta2-autoscaling","externalmetricsource-v2beta2-autoscaling","externaldocumentation-v1-apiextensions-k8s-io","execaction-v1-core","eviction-v1beta1-policy","eventsource-v1-core","eventseries-v1-core","ephemeralvolumesource-v1-core","ephemeralcontainer-v1-core","envvarsource-v1-core","envvar-v1-core","envfromsource-v1-core","endpointsubset-v1-core","endpointport-v1-core","endpointconditions-v1beta1-discovery-k8s-io","endpointaddress-v1-core","endpoint-v1beta1-discovery-k8s-io","emptydirvolumesource-v1-core","downwardapivolumesource-v1-core","downwardapivolumefile-v1-core","downwardapiprojection-v1-core","deploymentcondition-v1-apps","deleteoptions-v1-meta","daemonsetupdatestrategy-v1-apps","daemonsetcondition-v1-apps","daemonendpoint-v1-core","customresourcevalidation-v1-apiextensions-k8s-io","customresourcesubresources-v1-apiextensions-k8s-io","customresourcesubresourcestatus-v1-apiextensions-k8s-io","customresourcesubresourcescale-v1-apiextensions-k8s-io","customresourcedefinitionversion-v1-apiextensions-k8s-io","customresourcedefinitionnames-v1-apiextensions-k8s-io","customresourcedefinitioncondition-v1-apiextensions-k8s-io","customresourceconversion-v1-apiextensions-k8s-io","customresourcecolumndefinition-v1-apiextensions-k8s-io","crossversionobjectreference-v1-autoscaling","containerstatewaiting-v1-core","containerstateterminated-v1-core","containerstaterunning-v1-core","containerstate-v1-core","containerport-v1-core","containerimage-v1-core","configmapvolumesource-v1-core","configmapprojection-v1-core","configmapnodeconfigsource-v1-core","configmapkeyselector-v1-core","configmapenvsource-v1-core","componentcondition-v1-core","clientipconfig-v1-core","cindervolumesource-v1-core","cinderpersistentvolumesource-v1-core","certificatesigningrequestcondition-v1-certificates-k8s-io","cephfsvolumesource-v1-core","cephfspersistentvolumesource-v1-core","capabilities-v1-core","csivolumesource-v1-core","csipersistentvolumesource-v1-core","csinodedriver-v1-storage-k8s-io","boundobjectreference-v1-authentication-k8s-io","azurefilevolumesource-v1-core","azurefilepersistentvolumesource-v1-core","azurediskvolumesource-v1-core","attachedvolume-v1-core","allowedhostpath-v1beta1-policy","allowedflexvolume-v1beta1-policy","allowedcsidriver-v1beta1-policy","aggregationrule-v1-rbac-authorization-k8s-io","affinity-v1-core","awselasticblockstorevolumesource-v1-core","apiversions-v1-meta","apiservicecondition-v1-apiregistration-k8s-io","apiresource-v1-meta","apigroup-v1-meta","-strong-definitions-strong-","watch-list-all-namespaces-networkpolicy-v1-networking-k8s-io","watch-list-networkpolicy-v1-networking-k8s-io","watch-networkpolicy-v1-networking-k8s-io","list-all-namespaces-networkpolicy-v1-networking-k8s-io","list-networkpolicy-v1-networking-k8s-io","read-networkpolicy-v1-networking-k8s-io","-strong-read-operations-networkpolicy-v1-networking-k8s-io-strong-","delete-collection-networkpolicy-v1-networking-k8s-io","delete-networkpolicy-v1-networking-k8s-io","replace-networkpolicy-v1-networking-k8s-io","patch-networkpolicy-v1-networking-k8s-io","create-networkpolicy-v1-networking-k8s-io","-strong-write-operations-networkpolicy-v1-networking-k8s-io-strong-","networkpolicy-v1-networking-k8s-io","create-tokenreview-v1-authentication-k8s-io","-strong-write-operations-tokenreview-v1-authentication-k8s-io-strong-","tokenreview-v1-authentication-k8s-io","tokenrequest-v1-authentication-k8s-io","create-subjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-subjectaccessreview-v1-authorization-k8s-io-strong-","subjectaccessreview-v1-authorization-k8s-io","watch-list-all-namespaces-serviceaccount-v1-core","watch-list-serviceaccount-v1-core","watch-serviceaccount-v1-core","list-all-namespaces-serviceaccount-v1-core","list-serviceaccount-v1-core","read-serviceaccount-v1-core","-strong-read-operations-serviceaccount-v1-core-strong-","delete-collection-serviceaccount-v1-core","delete-serviceaccount-v1-core","replace-serviceaccount-v1-core","patch-serviceaccount-v1-core","create-serviceaccount-v1-core","-strong-write-operations-serviceaccount-v1-core-strong-","serviceaccount-v1-core","create-selfsubjectrulesreview-v1-authorization-k8s-io","-strong-write-operations-selfsubjectrulesreview-v1-authorization-k8s-io-strong-","selfsubjectrulesreview-v1-authorization-k8s-io","create-selfsubjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-selfsubjectaccessreview-v1-authorization-k8s-io-strong-","selfsubjectaccessreview-v1-authorization-k8s-io","watch-list-runtimeclass-v1beta1-node-k8s-io","watch-runtimeclass-v1beta1-node-k8s-io","list-runtimeclass-v1beta1-node-k8s-io","read-runtimeclass-v1beta1-node-k8s-io","-strong-read-operations-runtimeclass-v1beta1-node-k8s-io-strong-","delete-collection-runtimeclass-v1beta1-node-k8s-io","delete-runtimeclass-v1beta1-node-k8s-io","replace-runtimeclass-v1beta1-node-k8s-io","patch-runtimeclass-v1beta1-node-k8s-io","create-runtimeclass-v1beta1-node-k8s-io","-strong-write-operations-runtimeclass-v1beta1-node-k8s-io-strong-","runtimeclass-v1beta1-node-k8s-io","watch-list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","watch-list-rolebinding-v1-rbac-authorization-k8s-io","watch-rolebinding-v1-rbac-authorization-k8s-io","list-all-namespaces-rolebinding-v1-rbac-authorization-k8s-io","list-rolebinding-v1-rbac-authorization-k8s-io","read-rolebinding-v1-rbac-authorization-k8s-io","-strong-read-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","delete-collection-rolebinding-v1-rbac-authorization-k8s-io","delete-rolebinding-v1-rbac-authorization-k8s-io","replace-rolebinding-v1-rbac-authorization-k8s-io","patch-rolebinding-v1-rbac-authorization-k8s-io","create-rolebinding-v1-rbac-authorization-k8s-io","-strong-write-operations-rolebinding-v1-rbac-authorization-k8s-io-strong-","rolebinding-v1-rbac-authorization-k8s-io","watch-list-all-namespaces-role-v1-rbac-authorization-k8s-io","watch-list-role-v1-rbac-authorization-k8s-io","watch-role-v1-rbac-authorization-k8s-io","list-all-namespaces-role-v1-rbac-authorization-k8s-io","list-role-v1-rbac-authorization-k8s-io","read-role-v1-rbac-authorization-k8s-io","-strong-read-operations-role-v1-rbac-authorization-k8s-io-strong-","delete-collection-role-v1-rbac-authorization-k8s-io","delete-role-v1-rbac-authorization-k8s-io","replace-role-v1-rbac-authorization-k8s-io","patch-role-v1-rbac-authorization-k8s-io","create-role-v1-rbac-authorization-k8s-io","-strong-write-operations-role-v1-rbac-authorization-k8s-io-strong-","role-v1-rbac-authorization-k8s-io","replace-status-resourcequota-v1-core","read-status-resourcequota-v1-core","patch-status-resourcequota-v1-core","-strong-status-operations-resourcequota-v1-core-strong-","watch-list-all-namespaces-resourcequota-v1-core","watch-list-resourcequota-v1-core","watch-resourcequota-v1-core","list-all-namespaces-resourcequota-v1-core","list-resourcequota-v1-core","read-resourcequota-v1-core","-strong-read-operations-resourcequota-v1-core-strong-","delete-collection-resourcequota-v1-core","delete-resourcequota-v1-core","replace-resourcequota-v1-core","patch-resourcequota-v1-core","create-resourcequota-v1-core","-strong-write-operations-resourcequota-v1-core-strong-","resourcequota-v1-core","replace-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","read-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","patch-status-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-status-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","watch-list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","watch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","list-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","read-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-read-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","delete-collection-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","delete-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","replace-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","patch-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","create-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-write-operations-prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io","replace-status-persistentvolume-v1-core","read-status-persistentvolume-v1-core","patch-status-persistentvolume-v1-core","-strong-status-operations-persistentvolume-v1-core-strong-","watch-list-persistentvolume-v1-core","watch-persistentvolume-v1-core","list-persistentvolume-v1-core","read-persistentvolume-v1-core","-strong-read-operations-persistentvolume-v1-core-strong-","delete-collection-persistentvolume-v1-core","delete-persistentvolume-v1-core","replace-persistentvolume-v1-core","patch-persistentvolume-v1-core","create-persistentvolume-v1-core","-strong-write-operations-persistentvolume-v1-core-strong-","persistentvolume-v1-core","replace-connect-proxy-path-node-v1-core","replace-connect-proxy-node-v1-core","head-connect-proxy-path-node-v1-core","head-connect-proxy-node-v1-core","get-connect-proxy-path-node-v1-core","get-connect-proxy-node-v1-core","delete-connect-proxy-path-node-v1-core","delete-connect-proxy-node-v1-core","create-connect-proxy-path-node-v1-core","create-connect-proxy-node-v1-core","-strong-proxy-operations-node-v1-core-strong-","replace-status-node-v1-core","read-status-node-v1-core","patch-status-node-v1-core","-strong-status-operations-node-v1-core-strong-","watch-list-node-v1-core","watch-node-v1-core","list-node-v1-core","read-node-v1-core","-strong-read-operations-node-v1-core-strong-","delete-collection-node-v1-core","delete-node-v1-core","replace-node-v1-core","patch-node-v1-core","create-node-v1-core","-strong-write-operations-node-v1-core-strong-","node-v1-core","replace-status-namespace-v1-core","read-status-namespace-v1-core","patch-status-namespace-v1-core","-strong-status-operations-namespace-v1-core-strong-","watch-list-namespace-v1-core","watch-namespace-v1-core","list-namespace-v1-core","read-namespace-v1-core","-strong-read-operations-namespace-v1-core-strong-","delete-namespace-v1-core","replace-namespace-v1-core","patch-namespace-v1-core","create-namespace-v1-core","-strong-write-operations-namespace-v1-core-strong-","namespace-v1-core","create-localsubjectaccessreview-v1-authorization-k8s-io","-strong-write-operations-localsubjectaccessreview-v1-authorization-k8s-io-strong-","localsubjectaccessreview-v1-authorization-k8s-io","watch-list-all-namespaces-lease-v1-coordination-k8s-io","watch-list-lease-v1-coordination-k8s-io","watch-lease-v1-coordination-k8s-io","list-all-namespaces-lease-v1-coordination-k8s-io","list-lease-v1-coordination-k8s-io","read-lease-v1-coordination-k8s-io","-strong-read-operations-lease-v1-coordination-k8s-io-strong-","delete-collection-lease-v1-coordination-k8s-io","delete-lease-v1-coordination-k8s-io","replace-lease-v1-coordination-k8s-io","patch-lease-v1-coordination-k8s-io","create-lease-v1-coordination-k8s-io","-strong-write-operations-lease-v1-coordination-k8s-io-strong-","lease-v1-coordination-k8s-io","replace-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","read-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","patch-status-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-status-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","watch-list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","watch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","list-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","read-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-read-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","delete-collection-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","delete-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","replace-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","patch-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","create-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","-strong-write-operations-flowschema-v1alpha1-flowcontrol-apiserver-k8s-io-strong-","flowschema-v1alpha1-flowcontrol-apiserver-k8s-io","list-componentstatus-v1-core","read-componentstatus-v1-core","-strong-read-operations-componentstatus-v1-core-strong-","componentstatus-v1-core","watch-list-clusterrolebinding-v1-rbac-authorization-k8s-io","watch-clusterrolebinding-v1-rbac-authorization-k8s-io","list-clusterrolebinding-v1-rbac-authorization-k8s-io","read-clusterrolebinding-v1-rbac-authorization-k8s-io","-strong-read-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrolebinding-v1-rbac-authorization-k8s-io","delete-clusterrolebinding-v1-rbac-authorization-k8s-io","replace-clusterrolebinding-v1-rbac-authorization-k8s-io","patch-clusterrolebinding-v1-rbac-authorization-k8s-io","create-clusterrolebinding-v1-rbac-authorization-k8s-io","-strong-write-operations-clusterrolebinding-v1-rbac-authorization-k8s-io-strong-","clusterrolebinding-v1-rbac-authorization-k8s-io","watch-list-clusterrole-v1-rbac-authorization-k8s-io","watch-clusterrole-v1-rbac-authorization-k8s-io","list-clusterrole-v1-rbac-authorization-k8s-io","read-clusterrole-v1-rbac-authorization-k8s-io","-strong-read-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","delete-collection-clusterrole-v1-rbac-authorization-k8s-io","delete-clusterrole-v1-rbac-authorization-k8s-io","replace-clusterrole-v1-rbac-authorization-k8s-io","patch-clusterrole-v1-rbac-authorization-k8s-io","create-clusterrole-v1-rbac-authorization-k8s-io","-strong-write-operations-clusterrole-v1-rbac-authorization-k8s-io-strong-","clusterrole-v1-rbac-authorization-k8s-io","replace-status-certificatesigningrequest-v1-certificates-k8s-io","read-status-certificatesigningrequest-v1-certificates-k8s-io","patch-status-certificatesigningrequest-v1-certificates-k8s-io","-strong-status-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","watch-list-certificatesigningrequest-v1-certificates-k8s-io","watch-certificatesigningrequest-v1-certificates-k8s-io","list-certificatesigningrequest-v1-certificates-k8s-io","read-certificatesigningrequest-v1-certificates-k8s-io","-strong-read-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","delete-collection-certificatesigningrequest-v1-certificates-k8s-io","delete-certificatesigningrequest-v1-certificates-k8s-io","replace-certificatesigningrequest-v1-certificates-k8s-io","patch-certificatesigningrequest-v1-certificates-k8s-io","create-certificatesigningrequest-v1-certificates-k8s-io","-strong-write-operations-certificatesigningrequest-v1-certificates-k8s-io-strong-","certificatesigningrequest-v1-certificates-k8s-io","create-binding-v1-core","-strong-write-operations-binding-v1-core-strong-","binding-v1-core","replace-status-apiservice-v1-apiregistration-k8s-io","read-status-apiservice-v1-apiregistration-k8s-io","patch-status-apiservice-v1-apiregistration-k8s-io","-strong-status-operations-apiservice-v1-apiregistration-k8s-io-strong-","watch-list-apiservice-v1-apiregistration-k8s-io","watch-apiservice-v1-apiregistration-k8s-io","list-apiservice-v1-apiregistration-k8s-io","read-apiservice-v1-apiregistration-k8s-io","-strong-read-operations-apiservice-v1-apiregistration-k8s-io-strong-","delete-collection-apiservice-v1-apiregistration-k8s-io","delete-apiservice-v1-apiregistration-k8s-io","replace-apiservice-v1-apiregistration-k8s-io","patch-apiservice-v1-apiregistration-k8s-io","create-apiservice-v1-apiregistration-k8s-io","-strong-write-operations-apiservice-v1-apiregistration-k8s-io-strong-","apiservice-v1-apiregistration-k8s-io","-strong-cluster-apis-strong-","watch-list-podsecuritypolicy-v1beta1-policy","watch-podsecuritypolicy-v1beta1-policy","list-podsecuritypolicy-v1beta1-policy","read-podsecuritypolicy-v1beta1-policy","-strong-read-operations-podsecuritypolicy-v1beta1-policy-strong-","delete-collection-podsecuritypolicy-v1beta1-policy","delete-podsecuritypolicy-v1beta1-policy","replace-podsecuritypolicy-v1beta1-policy","patch-podsecuritypolicy-v1beta1-policy","create-podsecuritypolicy-v1beta1-policy","-strong-write-operations-podsecuritypolicy-v1beta1-policy-strong-","podsecuritypolicy-v1beta1-policy","watch-list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","watch-list-podpreset-v1alpha1-settings-k8s-io","watch-podpreset-v1alpha1-settings-k8s-io","list-all-namespaces-podpreset-v1alpha1-settings-k8s-io","list-podpreset-v1alpha1-settings-k8s-io","read-podpreset-v1alpha1-settings-k8s-io","-strong-read-operations-podpreset-v1alpha1-settings-k8s-io-strong-","delete-collection-podpreset-v1alpha1-settings-k8s-io","delete-podpreset-v1alpha1-settings-k8s-io","replace-podpreset-v1alpha1-settings-k8s-io","patch-podpreset-v1alpha1-settings-k8s-io","create-podpreset-v1alpha1-settings-k8s-io","-strong-write-operations-podpreset-v1alpha1-settings-k8s-io-strong-","podpreset-v1alpha1-settings-k8s-io","watch-list-priorityclass-v1-scheduling-k8s-io","watch-priorityclass-v1-scheduling-k8s-io","list-priorityclass-v1-scheduling-k8s-io","read-priorityclass-v1-scheduling-k8s-io","-strong-read-operations-priorityclass-v1-scheduling-k8s-io-strong-","delete-collection-priorityclass-v1-scheduling-k8s-io","delete-priorityclass-v1-scheduling-k8s-io","replace-priorityclass-v1-scheduling-k8s-io","patch-priorityclass-v1-scheduling-k8s-io","create-priorityclass-v1-scheduling-k8s-io","-strong-write-operations-priorityclass-v1-scheduling-k8s-io-strong-","priorityclass-v1-scheduling-k8s-io","replace-status-poddisruptionbudget-v1beta1-policy","read-status-poddisruptionbudget-v1beta1-policy","patch-status-poddisruptionbudget-v1beta1-policy","-strong-status-operations-poddisruptionbudget-v1beta1-policy-strong-","watch-list-all-namespaces-poddisruptionbudget-v1beta1-policy","watch-list-poddisruptionbudget-v1beta1-policy","watch-poddisruptionbudget-v1beta1-policy","list-all-namespaces-poddisruptionbudget-v1beta1-policy","list-poddisruptionbudget-v1beta1-policy","read-poddisruptionbudget-v1beta1-policy","-strong-read-operations-poddisruptionbudget-v1beta1-policy-strong-","delete-collection-poddisruptionbudget-v1beta1-policy","delete-poddisruptionbudget-v1beta1-policy","replace-poddisruptionbudget-v1beta1-policy","patch-poddisruptionbudget-v1beta1-policy","create-poddisruptionbudget-v1beta1-policy","-strong-write-operations-poddisruptionbudget-v1beta1-policy-strong-","poddisruptionbudget-v1beta1-policy","watch-list-all-namespaces-podtemplate-v1-core","watch-list-podtemplate-v1-core","watch-podtemplate-v1-core","list-all-namespaces-podtemplate-v1-core","list-podtemplate-v1-core","read-podtemplate-v1-core","-strong-read-operations-podtemplate-v1-core-strong-","delete-collection-podtemplate-v1-core","delete-podtemplate-v1-core","replace-podtemplate-v1-core","patch-podtemplate-v1-core","create-podtemplate-v1-core","-strong-write-operations-podtemplate-v1-core-strong-","podtemplate-v1-core","watch-list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","list-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","read-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-read-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","delete-collection-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","delete-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","patch-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","create-validatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-write-operations-validatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","validatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","watch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","list-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","read-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-read-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","delete-collection-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","delete-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","patch-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","create-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","-strong-write-operations-mutatingwebhookconfiguration-v1-admissionregistration-k8s-io-strong-","mutatingwebhookconfiguration-v1-admissionregistration-k8s-io","replace-status-horizontalpodautoscaler-v1-autoscaling","read-status-horizontalpodautoscaler-v1-autoscaling","patch-status-horizontalpodautoscaler-v1-autoscaling","-strong-status-operations-horizontalpodautoscaler-v1-autoscaling-strong-","watch-list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","watch-list-horizontalpodautoscaler-v1-autoscaling","watch-horizontalpodautoscaler-v1-autoscaling","list-all-namespaces-horizontalpodautoscaler-v1-autoscaling","list-horizontalpodautoscaler-v1-autoscaling","read-horizontalpodautoscaler-v1-autoscaling","-strong-read-operations-horizontalpodautoscaler-v1-autoscaling-strong-","delete-collection-horizontalpodautoscaler-v1-autoscaling","delete-horizontalpodautoscaler-v1-autoscaling","replace-horizontalpodautoscaler-v1-autoscaling","patch-horizontalpodautoscaler-v1-autoscaling","create-horizontalpodautoscaler-v1-autoscaling","-strong-write-operations-horizontalpodautoscaler-v1-autoscaling-strong-","horizontalpodautoscaler-v1-autoscaling","watch-list-all-namespaces-limitrange-v1-core","watch-list-limitrange-v1-core","watch-limitrange-v1-core","list-all-namespaces-limitrange-v1-core","list-limitrange-v1-core","read-limitrange-v1-core","-strong-read-operations-limitrange-v1-core-strong-","delete-collection-limitrange-v1-core","delete-limitrange-v1-core","replace-limitrange-v1-core","patch-limitrange-v1-core","create-limitrange-v1-core","-strong-write-operations-limitrange-v1-core-strong-","limitrange-v1-core","watch-list-all-namespaces-event-v1-core","watch-list-event-v1-core","watch-event-v1-core","list-all-namespaces-event-v1-core","list-event-v1-core","read-event-v1-core","-strong-read-operations-event-v1-core-strong-","delete-collection-event-v1-core","delete-event-v1-core","replace-event-v1-core","patch-event-v1-core","create-event-v1-core","-strong-write-operations-event-v1-core-strong-","event-v1-core","replace-status-customresourcedefinition-v1-apiextensions-k8s-io","read-status-customresourcedefinition-v1-apiextensions-k8s-io","patch-status-customresourcedefinition-v1-apiextensions-k8s-io","-strong-status-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","watch-list-customresourcedefinition-v1-apiextensions-k8s-io","watch-customresourcedefinition-v1-apiextensions-k8s-io","list-customresourcedefinition-v1-apiextensions-k8s-io","read-customresourcedefinition-v1-apiextensions-k8s-io","-strong-read-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","delete-collection-customresourcedefinition-v1-apiextensions-k8s-io","delete-customresourcedefinition-v1-apiextensions-k8s-io","replace-customresourcedefinition-v1-apiextensions-k8s-io","patch-customresourcedefinition-v1-apiextensions-k8s-io","create-customresourcedefinition-v1-apiextensions-k8s-io","-strong-write-operations-customresourcedefinition-v1-apiextensions-k8s-io-strong-","customresourcedefinition-v1-apiextensions-k8s-io","watch-list-all-namespaces-controllerrevision-v1-apps","watch-list-controllerrevision-v1-apps","watch-controllerrevision-v1-apps","list-all-namespaces-controllerrevision-v1-apps","list-controllerrevision-v1-apps","read-controllerrevision-v1-apps","-strong-read-operations-controllerrevision-v1-apps-strong-","delete-collection-controllerrevision-v1-apps","delete-controllerrevision-v1-apps","replace-controllerrevision-v1-apps","patch-controllerrevision-v1-apps","create-controllerrevision-v1-apps","-strong-write-operations-controllerrevision-v1-apps-strong-","controllerrevision-v1-apps","-strong-metadata-apis-strong-","replace-status-volumeattachment-v1-storage-k8s-io","read-status-volumeattachment-v1-storage-k8s-io","patch-status-volumeattachment-v1-storage-k8s-io","-strong-status-operations-volumeattachment-v1-storage-k8s-io-strong-","watch-list-volumeattachment-v1-storage-k8s-io","watch-volumeattachment-v1-storage-k8s-io","list-volumeattachment-v1-storage-k8s-io","read-volumeattachment-v1-storage-k8s-io","-strong-read-operations-volumeattachment-v1-storage-k8s-io-strong-","delete-collection-volumeattachment-v1-storage-k8s-io","delete-volumeattachment-v1-storage-k8s-io","replace-volumeattachment-v1-storage-k8s-io","patch-volumeattachment-v1-storage-k8s-io","create-volumeattachment-v1-storage-k8s-io","-strong-write-operations-volumeattachment-v1-storage-k8s-io-strong-","volumeattachment-v1-storage-k8s-io","volume-v1-core","watch-list-storageclass-v1-storage-k8s-io","watch-storageclass-v1-storage-k8s-io","list-storageclass-v1-storage-k8s-io","read-storageclass-v1-storage-k8s-io","-strong-read-operations-storageclass-v1-storage-k8s-io-strong-","delete-collection-storageclass-v1-storage-k8s-io","delete-storageclass-v1-storage-k8s-io","replace-storageclass-v1-storage-k8s-io","patch-storageclass-v1-storage-k8s-io","create-storageclass-v1-storage-k8s-io","-strong-write-operations-storageclass-v1-storage-k8s-io-strong-","storageclass-v1-storage-k8s-io","replace-status-persistentvolumeclaim-v1-core","read-status-persistentvolumeclaim-v1-core","patch-status-persistentvolumeclaim-v1-core","-strong-status-operations-persistentvolumeclaim-v1-core-strong-","watch-list-all-namespaces-persistentvolumeclaim-v1-core","watch-list-persistentvolumeclaim-v1-core","watch-persistentvolumeclaim-v1-core","list-all-namespaces-persistentvolumeclaim-v1-core","list-persistentvolumeclaim-v1-core","read-persistentvolumeclaim-v1-core","-strong-read-operations-persistentvolumeclaim-v1-core-strong-","delete-collection-persistentvolumeclaim-v1-core","delete-persistentvolumeclaim-v1-core","replace-persistentvolumeclaim-v1-core","patch-persistentvolumeclaim-v1-core","create-persistentvolumeclaim-v1-core","-strong-write-operations-persistentvolumeclaim-v1-core-strong-","persistentvolumeclaim-v1-core","watch-list-all-namespaces-secret-v1-core","watch-list-secret-v1-core","watch-secret-v1-core","list-all-namespaces-secret-v1-core","list-secret-v1-core","read-secret-v1-core","-strong-read-operations-secret-v1-core-strong-","delete-collection-secret-v1-core","delete-secret-v1-core","replace-secret-v1-core","patch-secret-v1-core","create-secret-v1-core","-strong-write-operations-secret-v1-core-strong-","secret-v1-core","watch-list-csinode-v1-storage-k8s-io","watch-csinode-v1-storage-k8s-io","list-csinode-v1-storage-k8s-io","read-csinode-v1-storage-k8s-io","-strong-read-operations-csinode-v1-storage-k8s-io-strong-","delete-collection-csinode-v1-storage-k8s-io","delete-csinode-v1-storage-k8s-io","replace-csinode-v1-storage-k8s-io","patch-csinode-v1-storage-k8s-io","create-csinode-v1-storage-k8s-io","-strong-write-operations-csinode-v1-storage-k8s-io-strong-","csinode-v1-storage-k8s-io","watch-list-csidriver-v1-storage-k8s-io","watch-csidriver-v1-storage-k8s-io","list-csidriver-v1-storage-k8s-io","read-csidriver-v1-storage-k8s-io","-strong-read-operations-csidriver-v1-storage-k8s-io-strong-","delete-collection-csidriver-v1-storage-k8s-io","delete-csidriver-v1-storage-k8s-io","replace-csidriver-v1-storage-k8s-io","patch-csidriver-v1-storage-k8s-io","create-csidriver-v1-storage-k8s-io","-strong-write-operations-csidriver-v1-storage-k8s-io-strong-","csidriver-v1-storage-k8s-io","watch-list-all-namespaces-configmap-v1-core","watch-list-configmap-v1-core","watch-configmap-v1-core","list-all-namespaces-configmap-v1-core","list-configmap-v1-core","read-configmap-v1-core","-strong-read-operations-configmap-v1-core-strong-","delete-collection-configmap-v1-core","delete-configmap-v1-core","replace-configmap-v1-core","patch-configmap-v1-core","create-configmap-v1-core","-strong-write-operations-configmap-v1-core-strong-","configmap-v1-core","-strong-config-and-storage-apis-strong-","replace-connect-proxy-path-service-v1-core","replace-connect-proxy-service-v1-core","head-connect-proxy-path-service-v1-core","head-connect-proxy-service-v1-core","get-connect-proxy-path-service-v1-core","get-connect-proxy-service-v1-core","delete-connect-proxy-path-service-v1-core","delete-connect-proxy-service-v1-core","create-connect-proxy-path-service-v1-core","create-connect-proxy-service-v1-core","-strong-proxy-operations-service-v1-core-strong-","replace-status-service-v1-core","read-status-service-v1-core","patch-status-service-v1-core","-strong-status-operations-service-v1-core-strong-","watch-list-all-namespaces-service-v1-core","watch-list-service-v1-core","watch-service-v1-core","list-all-namespaces-service-v1-core","list-service-v1-core","read-service-v1-core","-strong-read-operations-service-v1-core-strong-","delete-service-v1-core","replace-service-v1-core","patch-service-v1-core","create-service-v1-core","-strong-write-operations-service-v1-core-strong-","service-v1-core","watch-list-ingressclass-v1-networking-k8s-io","watch-ingressclass-v1-networking-k8s-io","list-ingressclass-v1-networking-k8s-io","read-ingressclass-v1-networking-k8s-io","-strong-read-operations-ingressclass-v1-networking-k8s-io-strong-","delete-collection-ingressclass-v1-networking-k8s-io","delete-ingressclass-v1-networking-k8s-io","replace-ingressclass-v1-networking-k8s-io","patch-ingressclass-v1-networking-k8s-io","create-ingressclass-v1-networking-k8s-io","-strong-write-operations-ingressclass-v1-networking-k8s-io-strong-","ingressclass-v1-networking-k8s-io","replace-status-ingress-v1-networking-k8s-io","read-status-ingress-v1-networking-k8s-io","patch-status-ingress-v1-networking-k8s-io","-strong-status-operations-ingress-v1-networking-k8s-io-strong-","watch-list-all-namespaces-ingress-v1-networking-k8s-io","watch-list-ingress-v1-networking-k8s-io","watch-ingress-v1-networking-k8s-io","list-all-namespaces-ingress-v1-networking-k8s-io","list-ingress-v1-networking-k8s-io","read-ingress-v1-networking-k8s-io","-strong-read-operations-ingress-v1-networking-k8s-io-strong-","delete-collection-ingress-v1-networking-k8s-io","delete-ingress-v1-networking-k8s-io","replace-ingress-v1-networking-k8s-io","patch-ingress-v1-networking-k8s-io","create-ingress-v1-networking-k8s-io","-strong-write-operations-ingress-v1-networking-k8s-io-strong-","ingress-v1-networking-k8s-io","watch-list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","watch-list-endpointslice-v1beta1-discovery-k8s-io","watch-endpointslice-v1beta1-discovery-k8s-io","list-all-namespaces-endpointslice-v1beta1-discovery-k8s-io","list-endpointslice-v1beta1-discovery-k8s-io","read-endpointslice-v1beta1-discovery-k8s-io","-strong-read-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","delete-collection-endpointslice-v1beta1-discovery-k8s-io","delete-endpointslice-v1beta1-discovery-k8s-io","replace-endpointslice-v1beta1-discovery-k8s-io","patch-endpointslice-v1beta1-discovery-k8s-io","create-endpointslice-v1beta1-discovery-k8s-io","-strong-write-operations-endpointslice-v1beta1-discovery-k8s-io-strong-","endpointslice-v1beta1-discovery-k8s-io","watch-list-all-namespaces-endpoints-v1-core","watch-list-endpoints-v1-core","watch-endpoints-v1-core","list-all-namespaces-endpoints-v1-core","list-endpoints-v1-core","read-endpoints-v1-core","-strong-read-operations-endpoints-v1-core-strong-","delete-collection-endpoints-v1-core","delete-endpoints-v1-core","replace-endpoints-v1-core","patch-endpoints-v1-core","create-endpoints-v1-core","-strong-write-operations-endpoints-v1-core-strong-","endpoints-v1-core","-strong-service-apis-strong-","patch-scale-statefulset-v1-apps","replace-scale-statefulset-v1-apps","read-scale-statefulset-v1-apps","-strong-misc-operations-statefulset-v1-apps-strong-","replace-status-statefulset-v1-apps","read-status-statefulset-v1-apps","patch-status-statefulset-v1-apps","-strong-status-operations-statefulset-v1-apps-strong-","watch-list-all-namespaces-statefulset-v1-apps","watch-list-statefulset-v1-apps","watch-statefulset-v1-apps","list-all-namespaces-statefulset-v1-apps","list-statefulset-v1-apps","read-statefulset-v1-apps","-strong-read-operations-statefulset-v1-apps-strong-","delete-collection-statefulset-v1-apps","delete-statefulset-v1-apps","replace-statefulset-v1-apps","patch-statefulset-v1-apps","create-statefulset-v1-apps","-strong-write-operations-statefulset-v1-apps-strong-","statefulset-v1-apps","patch-scale-replicationcontroller-v1-core","replace-scale-replicationcontroller-v1-core","read-scale-replicationcontroller-v1-core","-strong-misc-operations-replicationcontroller-v1-core-strong-","replace-status-replicationcontroller-v1-core","read-status-replicationcontroller-v1-core","patch-status-replicationcontroller-v1-core","-strong-status-operations-replicationcontroller-v1-core-strong-","watch-list-all-namespaces-replicationcontroller-v1-core","watch-list-replicationcontroller-v1-core","watch-replicationcontroller-v1-core","list-all-namespaces-replicationcontroller-v1-core","list-replicationcontroller-v1-core","read-replicationcontroller-v1-core","-strong-read-operations-replicationcontroller-v1-core-strong-","delete-collection-replicationcontroller-v1-core","delete-replicationcontroller-v1-core","replace-replicationcontroller-v1-core","patch-replicationcontroller-v1-core","create-replicationcontroller-v1-core","-strong-write-operations-replicationcontroller-v1-core-strong-","replicationcontroller-v1-core","patch-scale-replicaset-v1-apps","replace-scale-replicaset-v1-apps","read-scale-replicaset-v1-apps","-strong-misc-operations-replicaset-v1-apps-strong-","replace-status-replicaset-v1-apps","read-status-replicaset-v1-apps","patch-status-replicaset-v1-apps","-strong-status-operations-replicaset-v1-apps-strong-","watch-list-all-namespaces-replicaset-v1-apps","watch-list-replicaset-v1-apps","watch-replicaset-v1-apps","list-all-namespaces-replicaset-v1-apps","list-replicaset-v1-apps","read-replicaset-v1-apps","-strong-read-operations-replicaset-v1-apps-strong-","delete-collection-replicaset-v1-apps","delete-replicaset-v1-apps","replace-replicaset-v1-apps","patch-replicaset-v1-apps","create-replicaset-v1-apps","-strong-write-operations-replicaset-v1-apps-strong-","replicaset-v1-apps","read-log-pod-v1-core","-strong-misc-operations-pod-v1-core-strong-","replace-connect-proxy-path-pod-v1-core","replace-connect-proxy-pod-v1-core","head-connect-proxy-path-pod-v1-core","head-connect-proxy-pod-v1-core","get-connect-proxy-path-pod-v1-core","get-connect-proxy-pod-v1-core","get-connect-portforward-pod-v1-core","delete-connect-proxy-path-pod-v1-core","delete-connect-proxy-pod-v1-core","create-connect-proxy-path-pod-v1-core","create-connect-proxy-pod-v1-core","create-connect-portforward-pod-v1-core","-strong-proxy-operations-pod-v1-core-strong-","replace-status-pod-v1-core","read-status-pod-v1-core","patch-status-pod-v1-core","-strong-status-operations-pod-v1-core-strong-","watch-list-all-namespaces-pod-v1-core","watch-list-pod-v1-core","watch-pod-v1-core","list-all-namespaces-pod-v1-core","list-pod-v1-core","read-pod-v1-core","-strong-read-operations-pod-v1-core-strong-","delete-collection-pod-v1-core","delete-pod-v1-core","replace-pod-v1-core","patch-pod-v1-core","create-eviction-pod-v1-core","create-pod-v1-core","-strong-write-operations-pod-v1-core-strong-","pod-v1-core","replace-status-job-v1-batch","read-status-job-v1-batch","patch-status-job-v1-batch","-strong-status-operations-job-v1-batch-strong-","watch-list-all-namespaces-job-v1-batch","watch-list-job-v1-batch","watch-job-v1-batch","list-all-namespaces-job-v1-batch","list-job-v1-batch","read-job-v1-batch","-strong-read-operations-job-v1-batch-strong-","delete-collection-job-v1-batch","delete-job-v1-batch","replace-job-v1-batch","patch-job-v1-batch","create-job-v1-batch","-strong-write-operations-job-v1-batch-strong-","job-v1-batch","patch-scale-deployment-v1-apps","replace-scale-deployment-v1-apps","read-scale-deployment-v1-apps","-strong-misc-operations-deployment-v1-apps-strong-","replace-status-deployment-v1-apps","read-status-deployment-v1-apps","patch-status-deployment-v1-apps","-strong-status-operations-deployment-v1-apps-strong-","watch-list-all-namespaces-deployment-v1-apps","watch-list-deployment-v1-apps","watch-deployment-v1-apps","list-all-namespaces-deployment-v1-apps","list-deployment-v1-apps","read-deployment-v1-apps","-strong-read-operations-deployment-v1-apps-strong-","delete-collection-deployment-v1-apps","delete-deployment-v1-apps","replace-deployment-v1-apps","patch-deployment-v1-apps","create-deployment-v1-apps","-strong-write-operations-deployment-v1-apps-strong-","deployment-v1-apps","replace-status-daemonset-v1-apps","read-status-daemonset-v1-apps","patch-status-daemonset-v1-apps","-strong-status-operations-daemonset-v1-apps-strong-","watch-list-all-namespaces-daemonset-v1-apps","watch-list-daemonset-v1-apps","watch-daemonset-v1-apps","list-all-namespaces-daemonset-v1-apps","list-daemonset-v1-apps","read-daemonset-v1-apps","-strong-read-operations-daemonset-v1-apps-strong-","delete-collection-daemonset-v1-apps","delete-daemonset-v1-apps","replace-daemonset-v1-apps","patch-daemonset-v1-apps","create-daemonset-v1-apps","-strong-write-operations-daemonset-v1-apps-strong-","daemonset-v1-apps","replace-status-cronjob-v1beta1-batch","read-status-cronjob-v1beta1-batch","patch-status-cronjob-v1beta1-batch","-strong-status-operations-cronjob-v1beta1-batch-strong-","watch-list-all-namespaces-cronjob-v1beta1-batch","watch-list-cronjob-v1beta1-batch","watch-cronjob-v1beta1-batch","list-all-namespaces-cronjob-v1beta1-batch","list-cronjob-v1beta1-batch","read-cronjob-v1beta1-batch","-strong-read-operations-cronjob-v1beta1-batch-strong-","delete-collection-cronjob-v1beta1-batch","delete-cronjob-v1beta1-batch","replace-cronjob-v1beta1-batch","patch-cronjob-v1beta1-batch","create-cronjob-v1beta1-batch","-strong-write-operations-cronjob-v1beta1-batch-strong-","cronjob-v1beta1-batch","container-v1-core","-strong-workloads-apis-strong-","-strong-api-groups-strong-","-strong-api-overview-strong-"]};})();
\ No newline at end of file
diff --git a/static/fonts/roboto-mono-v5-latin-regular.eot b/static/fonts/roboto-mono-v5-latin-regular.eot
deleted file mode 100644
index 550df22a6d..0000000000
Binary files a/static/fonts/roboto-mono-v5-latin-regular.eot and /dev/null differ
diff --git a/static/fonts/roboto-mono-v5-latin-regular.svg b/static/fonts/roboto-mono-v5-latin-regular.svg
deleted file mode 100644
index f384d9cea2..0000000000
--- a/static/fonts/roboto-mono-v5-latin-regular.svg
+++ /dev/null
@@ -1,390 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="RobotoMono" horiz-adv-x="1230" ><font-face
-    font-family="Roboto Mono"
-    units-per-em="2048"
-    panose-1="0 0 0 0 0 0 0 0 0 0"
-    ascent="2146"
-    descent="-555"
-    alphabetic="0" />
-<glyph unicode=" " glyph-name="space" horiz-adv-x="1229" />
-<glyph unicode="!" glyph-name="exclam" horiz-adv-x="1229" d="M690 471H504V1456H690V471ZM486 97Q486 145 514 177T600 209Q657 209 686 177T716 97Q716 51 687 20T600 -11Q543 -11 515 20T486 97Z" />
-<glyph unicode="&quot;" glyph-name="quotedbl" horiz-adv-x="1229" d="M505 1427L484 1057H354L355 1411V1536H505V1427ZM862 1427L841 1057H712L713 1411V1536H863L862 1427Z" />
-<glyph unicode="#" glyph-name="numbersign" horiz-adv-x="1229" d="M707 410H443L363 0H220L300 410H61V547H326L395 901H137V1040H422L504 1456H647L565 1040H829L911 1456H1054L972 1040H1177V901H945L876 547H1102V410H850L770 0H627L707 410ZM469 547H733L802
-901H538L469 547Z" />
-<glyph unicode="$" glyph-name="dollar" horiz-adv-x="1229" d="M907 375Q908 466 841 531T626 644Q533 673 458 711T330 801T247 922T218 1079Q218 1163 243 1231T315 1349T428 1431T576 1472V1692H725V1472Q893 1449 986 1331T1080 1008H896Q896 1075 880 1131T832
-1228T754 1292T649 1315Q528 1315 466 1252T403 1082Q403 1032 419 993T469 922T558 863T690 809Q784 778 859 740T986 651T1065 533T1093 377Q1093 290 1066 221T988 103T867 23T708 -16V-208H559V-17Q481 -9 410 19T283 100T195 235T162 429H347Q347 345 372
-290T436 201T526 154T627 140Q692 140 744 156T832 202T887 276T907 375Z" />
-<glyph unicode="%" glyph-name="percent" horiz-adv-x="1229" d="M44 1194Q44 1251 61 1302T112 1393T196 1454T311 1477Q377 1477 427 1455T511 1393T562 1303T580 1194V1117Q580 1060 563 1009T512 920T428 859T313 836Q248 836 198 858T113 919T62 1009T44
-1117V1194ZM182 1117Q182 1086 189 1058T212 1007T252 971T313 957Q348 957 372 970T412 1006T434 1057T442 1117V1194Q442 1225 435 1254T412 1306T372 1342T311 1356Q276 1356 252 1343T212 1307T189 1255T182 1194V1117ZM645 338Q645 395 662 446T714 536T798
-597T913 620Q979 620 1029 598T1113 536T1164 446T1182 338V260Q1182 203 1165 152T1113 63T1030 2T915 -21Q849 -21 799 1T714 62T663 152T645 260V338ZM783 260Q783 229 790 200T813 149T854 113T915 99Q950 99 974 112T1014 148T1036 200T1043 260V338Q1043
-369 1036 398T1014 449T973 485T913 499Q877 499 853 486T813 450T790 398T783 338V260ZM398 188L287 250L854 1287L965 1225L398 188Z" />
-<glyph unicode="&amp;" glyph-name="ampersand" horiz-adv-x="1229" d="M107 373Q107 440 127 497T183 603T269 697T380 785Q313 876 274 957T234 1126Q234 1211 259 1276T332 1386T445 1454T593 1477Q664 1477 722 1452T820 1385T883 1286T905 1168Q905 1115
-890 1072T847 990T781 918T699 851L605 771L912 368Q947 432 967 508T988 672H1155Q1155 544 1119 435T1012 237L1193 0H972L889 110Q815 47 726 14T539 -20Q440 -20 360 9T224 90T138 214T107 373ZM539 130Q610 130 676 156T799 230L476 661L448 637Q398 596 367
-557T320 484T298 421T292 373Q292 322 308 278T355 201T432 149T539 130ZM420 1128Q420 1072 445 1014T515 890L632 983Q663 1004 683 1027T714 1073T729 1121T734 1168Q734 1198 725 1226T697 1276T652 1311T593 1325Q550 1325 518 1309T464 1266T431 1204T420
-1128Z" />
-<glyph unicode="&apos;" glyph-name="quotesingle" horiz-adv-x="1229" d="M653 1425L632 1057H494L495 1409V1536H653V1425Z" />
-<glyph unicode="(" glyph-name="parenleft" horiz-adv-x="1229" d="M357 591Q357 734 379 860T440 1093T527 1290T631 1448T741 1566T846 1643L885 1521Q823 1474 762 1393T652 1197T573 931T542 593V579Q542 392 572 241T651 -26T761 -224T885 -357L846 -470Q796
--442 741 -394T631 -276T527 -118T440 78T380 312T357 581V591Z" />
-<glyph unicode=")" glyph-name="parenright" horiz-adv-x="1229" d="M849 581Q849 438 827 312T766 79T679 -117T575 -275T465 -393T359 -470L320 -357Q382 -311 443 -229T553 -29T632 240T663 579V593Q663 780 631 932T549 1202T438 1402T320 1530L359 1643Q409
-1615 464 1566T574 1448T678 1290T766 1094T826 860T849 591V581Z" />
-<glyph unicode="*" glyph-name="asterisk" horiz-adv-x="1229" d="M537 683L160 779L214 954L579 803L554 1224H732L703 797L1066 947L1120 769L738 675L994 351L848 241L634 604L422 250L276 356L537 683Z" />
-<glyph unicode="+" glyph-name="plus" horiz-adv-x="1229" d="M710 781H1117V597H710V146H525V597H119V781H525V1206H710V781Z" />
-<glyph unicode="," glyph-name="comma" horiz-adv-x="1229" d="M643 43Q643 -4 632 -55T598 -157T543 -254T469 -336L354 -273Q402 -203 422 -124T442 40V219H643V43Z" />
-<glyph unicode="-" glyph-name="hyphen" d="M983 561H218V713H983V561Z" />
-<glyph unicode="." glyph-name="period" horiz-adv-x="1229" d="M496 120Q496 150 505 176T533 221T578 252T641 263Q677 263 704 252T750 222T778 176T788 120Q788 91 779 66T751 21T705 -8T641 -19Q605 -19 578 -9T533 21T506 65T496 120Z" />
-<glyph unicode="/" glyph-name="slash" horiz-adv-x="1229" d="M418 -125H252L860 1456H1025L418 -125Z" />
-<glyph unicode="0" glyph-name="zero" horiz-adv-x="1229" d="M1088 557Q1088 418 1056 311T964 130T817 18T618 -20Q507 -20 420 18T271 129T178 310T145 557V898Q145 1037 177 1144T269 1326T417 1438T616 1477Q728 1477 815 1439T963 1326T1056 1145T1088 898V557ZM331
-594L898 1029Q882 1174 814 1249T616 1325Q470 1325 401 1227T331 939V594ZM902 852L336 419Q353 278 423 204T618 130Q765 130 833 230T902 518V852Z" />
-<glyph unicode="1" glyph-name="one" horiz-adv-x="1229" d="M774 0H589V1220L208 1075V1244L759 1456H774V0Z" />
-<glyph unicode="2" glyph-name="two" horiz-adv-x="1229" d="M1067 0H113V133L590 663Q654 734 697 789T766 890T803 978T814 1064Q814 1118 797 1165T746 1248T665 1303T557 1324Q484 1324 431 1303T342 1244T289 1150T271 1027H85Q85 1119 117 1200T209 1343T357
-1440T557 1476Q660 1476 742 1446T882 1361T969 1233T1000 1072Q1000 1007 978 944T919 818T832 696T727 575L336 151H1067V0Z" />
-<glyph unicode="3" glyph-name="three" horiz-adv-x="1229" d="M390 817H522Q592 817 645 836T735 888T791 967T810 1068Q810 1195 745 1259T555 1324Q496 1324 448 1307T365 1256T311 1177T292 1074H106Q106 1157 138 1230T230 1358T371 1444T555 1476Q653 1476
-734 1450T873 1371T963 1242T995 1064Q995 1022 982 977T942 890T873 810T771 747Q842 724 889 687T965 604T1005 507T1017 406Q1017 304 982 225T885 92T739 9T556 -20Q460 -20 376 7T229 86T131 213T94 384H279Q279 327 298 280T354 200T441 149T556 131Q619
-131 670 147T757 198T812 282T832 402Q832 470 810 519T747 602T649 651T522 667H390V817Z" />
-<glyph unicode="4" glyph-name="four" horiz-adv-x="1229" d="M924 489H1127V338H924V0H739V338H75V447L727 1456H924V489ZM280 489H739V1210L709 1154L280 489Z" />
-<glyph unicode="5" glyph-name="five" horiz-adv-x="1229" d="M240 730L313 1456H1060V1276H469L428 888Q471 913 531 932T670 951Q771 951 851 916T987 818T1073 664T1103 464Q1103 360 1075 271T991 118T848 17T646 -20Q557 -20 478 5T338 80T237 206T187 383H363Q380
-259 454 195T646 131Q712 131 763 154T848 221T900 326T918 462Q918 530 899 589T842 691T751 760T627 785Q581 785 548 779T487 760T437 731T388 692L240 730Z" />
-<glyph unicode="6" glyph-name="six" horiz-adv-x="1229" d="M856 1457V1291H840Q748 1291 676 1272T548 1220T454 1142T388 1042T348 929T330 809Q356 840 390 866T463 912T548 943T644 955Q753 955 832 914T962 804T1037 650T1061 475Q1061 373 1033 283T947
-126T806 19T610 -20Q531 -20 466 3T348 65T257 159T193 275T154 404T141 538V625Q141 725 153 825T196 1018T277 1190T405 1330T590 1423T840 1457H856ZM614 801Q567 801 523 786T441 744T374 679T328 595V533Q328 437 351 363T413 237T503 160T610 133Q675 133
-725 158T809 227T861 332T879 466Q879 530 863 590T814 698T731 773T614 801Z" />
-<glyph unicode="7" glyph-name="seven" horiz-adv-x="1229" d="M1096 1352L493 0H299L900 1294H112V1456H1096V1352Z" />
-<glyph unicode="8" glyph-name="eight" horiz-adv-x="1229" d="M1070 1076Q1069 967 1011 882T856 749Q912 725 957 690T1035 608T1085 508T1103 393Q1103 294 1067 217T968 88T821 8T641 -20Q543 -20 459 7T312 86T213 216T177 393Q177 454 194 508T243 608T320
-690T421 750Q373 774 334 807T268 882T226 973T211 1076Q211 1171 243 1245T331 1371T466 1449T638 1476Q730 1476 809 1449T946 1371T1037 1246T1070 1076ZM918 397Q918 458 898 509T840 596T752 653T639 673Q576 673 525 653T438 597T383 509T363 397Q363 334
-382 285T438 201T525 149T641 131Q702 131 753 149T840 201T897 284T918 397ZM884 1073Q884 1128 866 1174T815 1253T737 1305T638 1324Q584 1324 540 1307T464 1256T415 1177T397 1073Q397 1016 414 971T464 893T541 843T640 825Q693 825 738 842T815 892T866
-971T884 1073Z" />
-<glyph unicode="9" glyph-name="nine" horiz-adv-x="1229" d="M373 164Q472 164 547 181T677 231T770 306T830 402T865 513T879 633Q855 603 824 577T754 530T668 499T564 487Q456 487 378 529T248 641T173 797T149 972Q149 1075 177 1166T262 1326T403 1435T600
-1476Q684 1476 751 1453T870 1388T959 1290T1019 1168T1054 1031T1065 887V820Q1065 727 1056 630T1021 441T946 270T821 129T634 34T373 -1H354V164H373ZM594 640Q641 640 685 655T767 699T834 766T881 852V912Q881 1009 859 1085T798 1213T709 1294T601 1322Q536
-1322 486 1296T402 1225T349 1117T331 982Q331 918 347 857T395 747T477 670T594 640Z" />
-<glyph unicode=":" glyph-name="colon" horiz-adv-x="1229" d="M546 120Q546 150 555 176T583 221T628 252T691 263Q727 263 754 252T800 222T828 176T838 120Q838 91 829 66T801 21T755 -8T691 -19Q655 -19 628 -9T583 21T556 65T546 120ZM546 996Q546 1026 555
-1052T583 1097T628 1128T691 1139Q727 1139 754 1128T800 1098T828 1052T838 996Q838 967 829 942T801 897T755 868T691 857Q655 857 628 867T583 897T556 941T546 996Z" />
-<glyph unicode=";" glyph-name="semicolon" horiz-adv-x="1229" d="M537 996Q537 1026 546 1052T574 1097T619 1128T682 1139Q718 1139 745 1128T791 1098T819 1052T829 996Q829 967 820 942T792 897T746 868T682 857Q646 857 619 867T574 897T547 941T537 996ZM775
-43Q775 -4 764 -55T730 -157T675 -254T601 -336L486 -273Q534 -203 554 -124T574 40V219H775V43Z" />
-<glyph unicode="&lt;" glyph-name="less" horiz-adv-x="1229" d="M406 663L353 646L406 628L1018 392V196L170 575V721L1018 1099V903L406 663Z" />
-<glyph unicode="=" glyph-name="equal" horiz-adv-x="1229" d="M1066 780H173V941H1066V780ZM1066 365H173V525H1066V365Z" />
-<glyph unicode="&gt;" glyph-name="greater" horiz-adv-x="1229" d="M178 909V1100L1061 722V576L178 197V389L825 633L885 650L825 669L178 909Z" />
-<glyph unicode="?" glyph-name="question" horiz-adv-x="1229" d="M511 410Q512 482 517 528T538 611T584 681T664 761Q698 796 733 833T798 910T847 996T866 1091Q866 1200 803 1257T623 1315Q576 1315 532 1304T453 1268T397 1206T376 1116H191Q192 1200 226
-1267T317 1380T453 1451T623 1476Q724 1476 803 1451T938 1376T1022 1257T1051 1097Q1051 1025 1026 962T962 842T875 736T779 645Q749 616 733 590T708 537T698 480T696 410H511ZM490 97Q490 145 518 177T604 209Q661 209 690 177T720 97Q720 51 691 20T604 -11Q547
--11 519 20T490 97Z" />
-<glyph unicode="@" glyph-name="at" horiz-adv-x="1229" d="M1159 789Q1156 709 1140 626T1092 474T1008 363T883 320Q822 320 782 352T724 441Q689 385 638 353T524 320Q475 320 439 346T381 419T350 531T347 674Q356 785 384 874T456 1026T560 1122T690 1156Q757
-1156 801 1130T871 1067L827 563Q824 522 829 497T843 457T867 437T897 432Q934 432 962 460T1010 537T1039 651T1050 789Q1054 916 1029 1017T953 1188T826 1295T655 1332Q554 1332 471 1285T326 1152T230 949T191 691Q186 555 210 449T287 270T422 158T617 119Q647
-119 678 123T739 136T796 157T845 184L877 67Q852 48 820 34T753 11T682 -3T614 -8Q467 -8 362 43T190 188T94 409T69 691Q73 794 94 891T151 1074T239 1229T355 1351T495 1430T658 1458Q780 1458 875 1411T1034 1275T1131 1064T1159 789ZM470 674Q465 572 487
-515T557 458Q606 458 646 485T716 575L755 1020Q727 1033 697 1033Q644 1033 605 1008T538 936T495 823T470 674Z" />
-<glyph unicode="A" glyph-name="A" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538Z" />
-<glyph unicode="B" glyph-name="B" horiz-adv-x="1229" d="M172 0V1456H605Q695 1455 781 1433T934 1363T1041 1243T1080 1068Q1079 1011 1062 964T1014 880T942 814T855 766Q913 749 961 718T1045 642T1099 541T1119 420Q1120 318 1080 240T973 110T819 29T638
-0H172ZM358 681V157H643Q701 158 753 176T845 228T908 309T932 418Q933 480 912 528T852 609T763 661T653 681H358ZM358 835H616Q668 836 718 851T807 896T870 969T894 1069Q894 1130 871 1173T808 1243T717 1284T611 1298H358V835Z" />
-<glyph unicode="C" glyph-name="C" horiz-adv-x="1229" d="M1117 438Q1104 337 1065 253T964 108T816 14T625 -20Q535 -20 462 5T331 76T232 182T163 315T122 466T107 626V829Q108 910 121 989T162 1140T231 1273T330 1380T461 1450T625 1476Q734 1476 820 1443T968
-1348T1067 1200T1117 1010H932Q923 1076 901 1133T842 1233T752 1300T625 1325Q559 1325 509 1304T422 1245T361 1159T321 1055T300 943T293 831V626Q293 572 299 515T321 402T360 297T421 211T508 152T625 130Q698 130 751 153T842 217T901 315T932 438H1117Z"
-/>
-<glyph unicode="D" glyph-name="D" horiz-adv-x="1229" d="M155 0V1456H492Q644 1454 763 1405T965 1267T1091 1055T1136 781V674Q1135 524 1092 401T966 189T764 51T492 0H155ZM343 1304V151H492Q610 152 696 192T838 303T922 468T951 674V783Q950 894 922 988T838
-1152T696 1262T492 1304H343Z" />
-<glyph unicode="E" glyph-name="E" horiz-adv-x="1229" d="M975 673H367V157H1076V0H182V1456H1067V1298H367V830H975V673Z" />
-<glyph unicode="F" glyph-name="F" horiz-adv-x="1229" d="M984 643H378V0H191V1456H1085V1298H378V800H984V643Z" />
-<glyph unicode="G" glyph-name="G" horiz-adv-x="1229" d="M1116 191Q1024 83 905 31T644 -20Q554 -19 479 7T343 80T238 190T163 326T117 480T100 643V812Q101 893 114 973T156 1128T226 1265T326 1375T459 1449T625 1476Q727 1476 813 1445T963 1355T1066 1214T1114
-1029H931Q920 1092 897 1145T837 1237T747 1296T626 1318Q560 1318 509 1296T420 1235T357 1147T316 1040T293 926T286 814V643Q287 588 295 530T322 415T368 309T435 221T527 161T645 137Q683 136 724 140T805 156T878 188T935 242L937 569H641V725H1113L1116
-191Z" />
-<glyph unicode="H" glyph-name="H" horiz-adv-x="1229" d="M1087 0H912V673H315V0H141V1456H315V830H912V1456H1087V0Z" />
-<glyph unicode="I" glyph-name="I" horiz-adv-x="1229" d="M174 1456H1054V1295H705V160H1054V0H174V160H515V1295H174V1456Z" />
-<glyph unicode="J" glyph-name="J" horiz-adv-x="1229" d="M857 1456H1046V443Q1044 342 1008 257T908 111T760 15T573 -20Q471 -20 388 11T243 99T144 238T98 421H286Q289 360 310 308T369 218T457 158T573 137Q639 137 691 161T779 228T835 325T857 443V1456Z" />
-<glyph unicode="K" glyph-name="K" horiz-adv-x="1229" d="M523 676L361 492V0H172V1456H361V745L502 921L929 1456H1154L645 819L1188 0H963L523 676Z" />
-<glyph unicode="L" glyph-name="L" horiz-adv-x="1229" d="M383 157H1095V0H198V1456H383V157Z" />
-<glyph unicode="M" glyph-name="M" horiz-adv-x="1229" d="M377 1456L614 728L870 1456H1100V0H920V581L935 1189L666 405H560L313 1168L328 581V0H148V1456H377Z" />
-<glyph unicode="N" glyph-name="N" horiz-adv-x="1229" d="M1086 0H898L333 1088L330 0H143V1456H331L896 370L899 1456H1086V0Z" />
-<glyph unicode="O" glyph-name="O" horiz-adv-x="1229" d="M1121 644Q1120 566 1108 487T1069 333T1003 195T906 83T778 8T615 -20Q525 -20 453 7T324 83T227 195T160 334T120 487T106 644V810Q107 888 119 967T158 1121T225 1259T322 1372T450 1448T613 1476Q703
-1476 776 1449T905 1373T1001 1261T1068 1122T1107 968T1121 810V644ZM938 812Q937 864 931 920T911 1032T872 1138T812 1227T727 1288T613 1311Q549 1311 500 1288T415 1227T355 1138T317 1032T296 920T288 812V644Q289 593 295 536T317 424T356 317T416 228T501
-166T615 143Q680 143 729 166T814 227T873 316T911 422T931 535T938 644V812Z" />
-<glyph unicode="P" glyph-name="P" horiz-adv-x="1229" d="M376 584V0H191V1456H663Q761 1454 848 1425T1002 1341T1106 1205T1145 1019Q1145 914 1107 834T1002 698T849 614T663 584H376ZM376 736H663Q727 737 781 756T875 812T937 899T960 1017Q960 1083 938
-1136T876 1226T782 1283T663 1304H376V736Z" />
-<glyph unicode="Q" glyph-name="Q" horiz-adv-x="1229" d="M1134 663Q1133 582 1120 500T1081 342T1013 200T913 84L1164 -125L1037 -246L749 -2Q687 -20 615 -20Q522 -20 448 8T317 86T217 201T148 344T108 501T94 663V791Q95 871 108 953T148 1111T216 1253T314
-1369T446 1447T614 1476Q707 1476 781 1448T913 1370T1012 1255T1080 1112T1120 954T1134 791V663ZM950 793Q949 848 944 907T924 1024T885 1134T823 1225T735 1288T614 1311Q546 1311 495 1288T407 1225T346 1133T306 1024T285 907T278 793V663Q278 609 284 550T306
-432T345 322T407 230T495 167T615 143Q684 143 735 166T824 229T885 321T923 431T943 548T950 663V793Z" />
-<glyph unicode="R" glyph-name="R" horiz-adv-x="1229" d="M656 594H365V0H181V1456H608Q710 1454 800 1427T957 1346T1063 1211T1102 1019Q1102 948 1082 889T1025 782T939 697T829 634L1138 12L1137 0H942L656 594ZM365 746H613Q675 747 730 765T826 819T892
-904T916 1021Q916 1091 893 1143T829 1231T732 1285T608 1304H365V746Z" />
-<glyph unicode="S" glyph-name="S" horiz-adv-x="1229" d="M936 368Q936 435 906 481T827 558T722 611T611 649Q534 674 455 709T310 795T203 915T161 1079Q161 1173 202 1247T311 1372T463 1449T634 1476Q729 1476 817 1445T973 1356T1082 1218T1125 1037H935Q927
-1100 904 1151T843 1240T753 1297T634 1318Q581 1318 531 1303T441 1258T378 1184T354 1082Q355 1019 386 976T464 902T567 852T672 817Q726 800 781 779T887 729T982 666T1059 587T1110 489T1129 370Q1129 272 1086 199T973 78T817 5T643 -20Q546 -20 453 10T287
-96T167 234T118 420H307Q316 352 344 300T416 211T517 156T643 137Q697 137 749 150T843 192T910 264T936 368Z" />
-<glyph unicode="T" glyph-name="T" horiz-adv-x="1229" d="M1156 1298H706V0H526V1298H76V1456H1156V1298Z" />
-<glyph unicode="U" glyph-name="U" horiz-adv-x="1229" d="M1088 1456L1090 470Q1088 368 1053 279T955 124T805 19T614 -20Q508 -20 421 18T272 122T175 278T139 470L141 1456H317L321 470Q322 405 341 345T397 239T488 165T614 137Q685 137 739 164T829 238T885
-345T906 470L909 1456H1088Z" />
-<glyph unicode="V" glyph-name="V" horiz-adv-x="1229" d="M610 298L954 1456H1151L692 0H531L71 1456H269L610 298Z" />
-<glyph unicode="W" glyph-name="W" horiz-adv-x="1229" d="M896 394L1007 1456H1182L1005 0H816L629 1097L440 0H250L73 1456H249L360 394L547 1456H708L896 394Z" />
-<glyph unicode="X" glyph-name="X" horiz-adv-x="1229" d="M625 885L939 1456H1157L734 734L1167 0H951L629 582L306 0H87L521 734L98 1456H315L625 885Z" />
-<glyph unicode="Y" glyph-name="Y" horiz-adv-x="1229" d="M603 725L935 1456H1145L692 543L689 0H517L514 543L61 1456H272L603 725Z" />
-<glyph unicode="Z" glyph-name="Z" horiz-adv-x="1229" d="M325 157H1079V0H116L114 144L839 1298H127V1456H1050L1052 1315L325 157Z" />
-<glyph unicode="[" glyph-name="bracketleft" horiz-adv-x="1229" d="M822 1512H601V-160H822V-312H426V1664H822V1512Z" />
-<glyph unicode="\" glyph-name="backslash" horiz-adv-x="1229" d="M231 1456H398L1006 -125H839L231 1456Z" />
-<glyph unicode="]" glyph-name="bracketright" horiz-adv-x="1229" d="M405 1664H802V-312H405V-160H627V1512H405V1664Z" />
-<glyph unicode="^" glyph-name="asciicircum" horiz-adv-x="1229" d="M403 677H231L551 1456H678L997 677H826L628 1163L613 1231L598 1163L403 677Z" />
-<glyph unicode="_" glyph-name="underscore" horiz-adv-x="1229" d="M1072 -151H155V0H1072V-151Z" />
-<glyph unicode="`" glyph-name="grave" horiz-adv-x="1229" d="M813 1215H663L415 1481H638L813 1215Z" />
-<glyph unicode="a" glyph-name="a" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786 895T706 938T599
-953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521 525 431
-477T341 326Q341 286 354 252T395 194T463 155T558 141Z" />
-<glyph unicode="b" glyph-name="b" horiz-adv-x="1229" d="M1091 529Q1091 413 1063 313T981 138T848 22T665 -20Q561 -20 485 17T354 123L345 0H175V1536H360V966Q413 1032 488 1067T663 1102Q767 1102 847 1061T981 947T1063 773T1091 550V529ZM906 550Q906
-629 891 700T841 826T752 913T617 945Q569 945 529 933T458 898T402 845T360 778V305Q378 269 402 239T459 185T531 150T619 137Q695 137 749 168T838 254T889 379T906 529V550Z" />
-<glyph unicode="c" glyph-name="c" horiz-adv-x="1229" d="M635 130Q685 130 732 146T817 190T876 257T900 341H1075Q1074 269 1038 204T940 89T800 10T635 -20Q512 -20 420 24T267 142T174 314T143 520V562Q143 669 174 767T266 939T420 1058T635 1102Q731 1102
-811 1072T950 989T1042 864T1075 710H900Q899 759 879 802T823 879T740 931T635 950Q549 950 491 916T396 826T345 701T329 562V520Q329 449 344 380T395 255T489 165T635 130Z" />
-<glyph unicode="d" glyph-name="d" horiz-adv-x="1229" d="M139 550Q139 671 169 772T256 947T393 1061T572 1102Q669 1102 741 1070T867 975V1536H1052V0H882L874 114Q820 48 745 14T570 -20Q472 -20 393 22T257 138T170 312T139 529V550ZM324 529Q324 450 341
-379T393 254T484 169T616 137Q663 137 701 148T770 179T825 228T867 292V794Q831 860 770 902T618 945Q540 945 485 913T394 827T341 701T324 550V529Z" />
-<glyph unicode="e" glyph-name="e" horiz-adv-x="1229" d="M652 -20Q538 -20 443 19T279 128T173 294T135 503V545Q135 676 177 779T288 954T446 1064T628 1102Q745 1102 832 1062T978 950T1064 781T1093 571V488H320Q323 414 348 349T418 236T525 159T662 131Q761
-131 838 171T966 277L1079 189Q1052 148 1012 111T918 44T798 -2T652 -20ZM628 950Q572 950 522 930T432 870T365 773T326 640H908V654Q905 708 888 761T836 856T751 924T628 950Z" />
-<glyph unicode="f" glyph-name="f" d="M450 0V939H152V1082H450V1158Q450 1262 480 1340T566 1472T700 1552T874 1579Q940 1579 1002 1568T1131 1540L1109 1387Q1068 1401 1014 1411T897 1422Q767 1421 702 1356T636 1158V1082H1053V939H636V0H450Z" />
-<glyph unicode="g" glyph-name="g" horiz-adv-x="1229" d="M140 550Q140 671 169 772T255 947T391 1061T572 1102Q672 1102 747 1067T876 964L885 1082H1053V23Q1053 -84 1020 -167T926 -308T781 -396T595 -426Q553 -426 499 -417T390 -386T283 -328T194 -239L290
--128Q324 -169 360 -197T433 -243T507 -267T581 -275Q647 -275 700 -256T790 -201T848 -110T868 14V107Q814 45 741 13T570 -20Q471 -20 391 22T256 138T170 312T140 529V550ZM325 529Q325 450 341 379T393 254T484 169T616 137Q664 137 702 148T771 181T826 231T868
-295V791Q850 825 826 853T771 901T702 933T618 945Q540 945 485 913T394 827T342 701T325 550V529Z" />
-<glyph unicode="h" glyph-name="h" horiz-adv-x="1229" d="M359 921Q417 1006 502 1053T693 1102Q778 1102 847 1078T966 1001T1041 870T1068 681V0H883V683Q883 816 820 881T638 945Q549 945 477 902T359 786V0H174V1536H359V921Z" />
-<glyph unicode="i" glyph-name="i" horiz-adv-x="1229" d="M203 1082H756V160H1109V0H203V160H571V921H203V1082ZM547 1366Q547 1412 574 1443T658 1475Q713 1475 741 1444T769 1366Q769 1321 741 1291T658 1261Q602 1261 575 1291T547 1366Z" />
-<glyph unicode="j" glyph-name="j" horiz-adv-x="1229" d="M299 1082H845V-7Q845 -111 817 -191T734 -325T601 -408T422 -437Q365 -437 316 -434T211 -420L224 -268Q241 -271 267 -273T319 -277T370 -279T409 -280Q461 -280 507 -267T587 -221T640 -137T660 -7V921H299V1082ZM634
-1367Q634 1412 661 1443T744 1475Q800 1475 828 1444T856 1367Q856 1322 828 1292T744 1261Q688 1261 661 1291T634 1367Z" />
-<glyph unicode="k" glyph-name="k" horiz-adv-x="1229" d="M498 505L362 374V0H176V1536H362V596L483 726L838 1082H1063L625 631L1130 0H895L498 505Z" />
-<glyph unicode="l" glyph-name="l" horiz-adv-x="1229" d="M203 1536H756V160H1109V0H203V160H571V1375H203V1536Z" />
-<glyph unicode="m" glyph-name="m" horiz-adv-x="1229" d="M259 1082L264 980Q297 1037 350 1069T480 1102Q629 1102 679 986Q711 1038 763 1069T891 1102Q1010 1102 1074 1029T1138 808V0H962V810Q962 946 837 945Q804 945 780 936T740 912T715 876T703 833V0H527V811Q527
-876 498 911T406 945Q348 945 316 922T269 861V0H93V1082H259Z" />
-<glyph unicode="n" glyph-name="n" horiz-adv-x="1229" d="M340 1082L353 922Q412 1006 498 1053T690 1102Q775 1102 844 1078T963 1003T1038 874T1065 687V0H880V683Q880 755 864 805T817 886T740 931T635 945Q542 945 472 899T359 776V0H174V1082H340Z" />
-<glyph unicode="o" glyph-name="o" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q728 1102 819 1060T974 943T1072 769T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q500 -20 409 22T254 138T156 312T122 529V551ZM307
-529Q307 449 326 377T383 249T480 162T615 130Q691 130 748 162T844 249T902 376T921 529V551Q921 630 902 702T844 830T748 917T613 950Q536 950 479 918T384 830T326 703T307 551V529Z" />
-<glyph unicode="p" glyph-name="p" horiz-adv-x="1229" d="M1087 529Q1087 413 1059 313T977 138T844 22T662 -20Q563 -20 488 12T358 104V-416H173V1082H342L351 964Q405 1031 481 1066T659 1102Q763 1102 843 1061T977 947T1059 773T1087 550V529ZM902 550Q902
-629 885 700T831 826T738 913T604 945Q515 945 455 904T358 797V276Q394 212 454 172T606 131Q683 131 739 163T831 251T884 378T902 529V550Z" />
-<glyph unicode="q" glyph-name="q" horiz-adv-x="1229" d="M140 550Q140 671 169 772T254 947T391 1061T577 1102Q673 1102 746 1070T874 975L882 1082H1052V-416H867V98Q813 41 741 11T575 -20Q472 -20 392 22T255 138T170 312T140 529V550ZM325 529Q325 450
-342 378T396 251T487 164T620 131Q709 131 769 171T867 275V809Q848 840 824 865T769 910T702 939T622 950Q545 950 489 917T397 829T343 701T325 550V529Z" />
-<glyph unicode="r" glyph-name="r" horiz-adv-x="1229" d="M883 1102Q909 1102 937 1101T990 1096T1037 1087T1073 1076L1048 895Q994 907 946 912T844 918Q714 918 634 859T515 694V0H329V1082H505L514 910Q580 999 672 1050T883 1102Z" />
-<glyph unicode="s" glyph-name="s" horiz-adv-x="1229" d="M893 287Q893 320 880 346T836 395T754 435T627 469Q534 488 458 515T327 579T242 667T212 785Q212 851 243 908T330 1009T463 1077T634 1102Q734 1102 814 1076T950 1004T1036 897T1067 764H882Q882
-799 864 832T814 892T737 934T634 950Q575 950 531 937T457 902T412 851T397 791Q397 759 409 734T450 689T529 653T655 622Q755 601 834 574T967 508T1049 418T1078 300Q1078 228 1046 169T955 68T816 3T639 -20Q529 -20 443 9T298 87T207 200T175 333H360Q364
-276 390 237T456 174T544 140T639 130Q756 130 824 173T893 287Z" />
-<glyph unicode="t" glyph-name="t" horiz-adv-x="1229" d="M612 1344V1082H1024V939H612V351Q612 288 628 247T672 182T736 147T814 137Q844 137 876 140T938 149T995 159T1039 169L1065 38Q1042 24 1009 14T937 -4T855 -16T768 -20Q696 -20 634 0T525 65T453
-180T426 351V939H142V1082H426V1344H612Z" />
-<glyph unicode="u" glyph-name="u" horiz-adv-x="1229" d="M876 149Q822 69 741 25T554 -20Q469 -20 400 6T282 89T207 231T180 439V1082H365V437Q365 349 379 291T421 199T489 150T583 136Q696 136 765 182T869 306V1082H1055V0H887L876 149Z" />
-<glyph unicode="v" glyph-name="v" horiz-adv-x="1229" d="M598 266L615 199L633 266L936 1082H1125L684 0H543L98 1082H288L598 266Z" />
-<glyph unicode="w" glyph-name="w" horiz-adv-x="1229" d="M338 392L360 237L387 392L560 1082H679L851 392L880 222L907 392L1027 1082H1191L961 0H815L646 663L618 831L591 663L424 0H278L48 1082H212L338 392Z" />
-<glyph unicode="x" glyph-name="x" horiz-adv-x="1229" d="M621 681L910 1082H1127L724 547L1138 0H924L625 412L326 0H110L524 547L121 1082H335L621 681Z" />
-<glyph unicode="y" glyph-name="y" horiz-adv-x="1229" d="M572 384L620 253L950 1082H1157L608 -167Q589 -209 560 -256T488 -343T390 -410T261 -437Q248 -437 232 -436T200 -432T170 -426T147 -421L177 -270Q184 -270 196 -271T221 -273T246 -274T265 -275Q303
--275 334 -254T390 -204T432 -144T460 -93L534 51L68 1082H275L572 384Z" />
-<glyph unicode="z" glyph-name="z" horiz-adv-x="1229" d="M396 151H1085V0H160V136L806 929H169V1082H1049V951L396 151Z" />
-<glyph unicode="{" glyph-name="braceleft" horiz-adv-x="1229" d="M978 -366Q913 -364 860 -344T765 -290T693 -211T642 -115T611 -9T601 99V268Q601 412 533 477T323 543V688Q464 688 532 752T601 962V1132Q601 1185 610 1239T638 1345T686 1442T758 1521T854
-1575T978 1597L999 1482Q927 1480 885 1448T821 1367T793 1255T787 1132V962Q786 842 731 752T560 614Q676 568 731 478T787 268V99Q787 37 797 -24T831 -135T896 -217T999 -251L978 -366Z" />
-<glyph unicode="|" glyph-name="bar" horiz-adv-x="1229" d="M689 -398H540V1456H689V-398Z" />
-<glyph unicode="}" glyph-name="braceright" horiz-adv-x="1229" d="M323 -251Q384 -249 425 -217T490 -136T525 -25T536 99V268Q536 387 591 477T762 614Q646 661 591 751T536 962V1132Q536 1193 530 1255T502 1366T438 1448T324 1482L344 1597Q413 1595 467
-1575T564 1521T635 1442T684 1346T712 1240T721 1132V962Q721 817 790 753T999 688V543Q859 542 790 477T721 268V99Q721 19 699 -62T631 -211T513 -321T344 -366L323 -251Z" />
-<glyph unicode="~" glyph-name="asciitilde" horiz-adv-x="1229" d="M1180 740Q1180 674 1158 613T1096 505T1001 430T879 402Q832 402 792 411T713 438T637 482T559 542Q504 587 454 613T348 639Q313 639 283 625T230 586T195 528T182 456L48 473Q48 539 70 599T131
-704T226 775T348 802Q394 802 435 793T516 765T592 721T669 663Q726 615 774 590T879 565Q914 565 944 581T997 623T1033 685T1046 758L1180 740Z" />
-<glyph unicode="&#xa1;" glyph-name="exclamdown" horiz-adv-x="1229" d="M522 611H707V-372H522V611ZM728 990Q728 944 699 913T613 881Q556 881 527 912T498 990Q498 1038 527 1070T613 1103Q669 1103 698 1071T728 990Z" />
-<glyph unicode="&#xa2;" glyph-name="cent" horiz-adv-x="1229" d="M639 130Q689 130 736 146T821 190T880 257T904 341H1079Q1078 277 1049 219T971 113T857 32T718 -13V-245H533V-10Q437 8 365 57T244 178T172 337T147 520V562Q147 657 171 744T244 903T364
-1024T533 1092V1318H718V1096Q798 1084 864 1050T978 964T1052 848T1079 710H904Q903 759 883 802T827 879T744 931T639 950Q553 950 495 916T400 826T349 701T333 562V520Q333 449 348 380T399 255T493 165T639 130Z" />
-<glyph unicode="&#xa3;" glyph-name="sterling" horiz-adv-x="1229" d="M463 626L471 400Q471 331 457 265T410 151H1148L1147 0H117V151H192Q219 158 237 186T267 250T282 327T286 400L278 626H113V778H273L264 1039Q264 1141 297 1222T390 1359T531 1446T709
-1476Q805 1476 881 1448T1009 1369T1090 1247T1118 1089H932Q932 1152 913 1196T860 1269T783 1311T691 1325Q640 1325 596 1306T519 1250T469 1160T450 1039L458 778H778V626H463Z" />
-<glyph unicode="&#xa4;" glyph-name="currency" horiz-adv-x="1229" d="M931 84Q869 34 794 7T634 -20Q549 -20 475 7T338 82L234 -26L103 109L215 224Q177 287 157 360T137 515Q137 601 159 678T223 820L103 944L234 1079L351 957Q411 1001 482 1025T634 1049Q714
-1049 786 1025T918 955L1038 1080L1170 944L1046 816Q1086 752 1108 676T1130 515Q1130 435 1110 363T1054 228L1170 109L1038 -27L931 84ZM309 515Q309 441 334 375T402 260T505 181T634 151Q703 151 762 180T864 259T932 375T957 515Q957 589 933 655T865 770T762
-849T634 878Q565 878 506 849T403 771T334 655T309 515Z" />
-<glyph unicode="&#xa5;" glyph-name="yen" horiz-adv-x="1229" d="M614 779L983 1456H1195L774 736H1092V615H704L703 613V446H1092V326H703V0H518V326H138V446H518V615H138V736H454L33 1456H245L614 779Z" />
-<glyph unicode="&#xa6;" glyph-name="brokenbar" horiz-adv-x="1229" d="M511 -270V521H696V-270H511ZM696 698H511V1456H696V698Z" />
-<glyph unicode="&#xa7;" glyph-name="section" horiz-adv-x="1229" d="M1140 431Q1140 334 1091 265T954 156Q1023 108 1059 40T1096 -128Q1096 -216 1061 -284T961 -399T807 -470T608 -495Q510 -495 417 -473T250 -400T132 -267T87 -64L272 -62Q272 -140 302
--193T380 -280T488 -328T608 -343Q678 -343 734 -327T829 -283T890 -216T911 -130Q911 -82 892 -47T831 16T723 71T560 126Q454 155 368 189T220 273T126 389T93 551Q93 645 141 714T275 825Q209 874 174 942T138 1110Q138 1194 173 1261T273 1377T427 1450T626
-1476Q740 1476 831 1448T985 1365T1083 1230T1118 1045H933Q933 1103 913 1154T853 1243T757 1303T626 1325Q551 1325 495 1309T400 1264T342 1196T323 1112Q323 1060 340 1024T397 960T505 907T672 854Q780 824 866 789T1014 706T1107 592T1140 431ZM598 691Q553
-703 513 715T435 742Q357 724 318 674T278 553Q278 500 296 463T355 397T464 342T632 289Q676 276 716 264T793 238Q869 258 912 307T956 428Q956 476 936 512T873 579T762 635T598 691Z" />
-<glyph unicode="&#xa8;" glyph-name="dieresis" horiz-adv-x="1229" d="M287 1371Q287 1416 314 1446T396 1477Q450 1477 478 1447T506 1371Q506 1326 478 1296T396 1266Q342 1266 315 1296T287 1371ZM717 1369Q717 1414 744 1445T826 1476Q880 1476 908 1445T936
-1369Q936 1325 908 1295T826 1264Q772 1264 745 1294T717 1369Z" />
-<glyph unicode="&#xa9;" glyph-name="copyright" horiz-adv-x="1229" d="M862 443Q862 327 797 268T613 208Q551 208 503 230T422 290T371 382T353 498V585Q353 647 371 700T422 793T503 854T613 876Q731 876 797 816T863 641H753Q752 712 719 745T613 778Q575
-778 547 763T499 723T471 662T462 586V498Q462 457 471 422T499 361T546 320T613 305Q685 305 718 338T752 443H862ZM177 542Q177 444 211 358T305 207T446 105T623 68Q717 68 798 105T940 207T1034 358T1068 542Q1068 639 1034 724T940 874T799 974T623 1011Q528
-1011 447 975T305 874T211 725T177 542ZM90 542Q90 620 108 691T161 825T243 939T351 1026T479 1082T623 1102Q736 1102 833 1058T1001 939T1114 761T1155 542Q1155 425 1114 323T1002 144T833 23T623 -21Q510 -21 413 23T244 143T131 322T90 542Z" />
-<glyph unicode="&#xaa;" glyph-name="ordfeminine" horiz-adv-x="1229" d="M780 705Q765 749 759 802Q729 759 673 726T533 691Q415 691 350 752T284 918Q284 1030 370 1089T615 1149H756V1201Q755 1266 724 1301T630 1336Q563 1336 523 1310T481 1231L320 1243Q321
-1294 343 1337T406 1411T504 1459T630 1476Q695 1476 748 1459T839 1407T898 1320T919 1200V886Q919 838 925 794T945 705H780ZM572 828Q599 828 628 836T683 859T728 892T756 928V1037H616Q537 1037 492 1004T446 922Q446 877 478 853T572 828Z" />
-<glyph unicode="&#xab;" glyph-name="guillemotleft" horiz-adv-x="1229" d="M390 515L648 118H507L212 506V525L507 914H648L390 515ZM725 515L983 118H842L547 506V525L842 914H983L725 515Z" />
-<glyph unicode="&#xac;" glyph-name="logicalnot" horiz-adv-x="1229" d="M1019 375H834V639H189V800H1019V375Z" />
-<glyph unicode="&#xad;" glyph-name="uni00AD" d="M983 561H218V713H983V561Z" />
-<glyph unicode="&#xae;" glyph-name="registered" horiz-adv-x="1229" d="M87 540Q87 657 128 759T240 938T409 1057T620 1101Q733 1101 830 1058T998 938T1111 760T1152 540Q1152 423 1111 321T999 143T830 23T620 -21Q507 -21 410 23T241 142T128 320T87 540ZM174
-540Q174 442 208 357T302 207T443 106T620 69Q714 69 795 106T937 207T1031 356T1065 540Q1065 638 1031 724T937 873T796 973T620 1010Q525 1010 444 974T302 874T208 724T174 540ZM508 485V232H401V867H612Q667 867 711 855T786 819T835 759T852 675Q852 619
-817 580T716 519L863 232H753L633 485H508ZM508 582H627Q675 583 710 606T745 671Q745 726 715 748T612 770H508V582Z" />
-<glyph unicode="&#xaf;" glyph-name="overscore" horiz-adv-x="1229" d="M971 1313H257V1456H971V1313Z" />
-<glyph unicode="&#xb0;" glyph-name="degree" horiz-adv-x="1229" d="M361 1216Q361 1269 381 1316T436 1399T517 1455T616 1476Q667 1476 712 1456T792 1400T846 1317T866 1216Q866 1163 846 1116T792 1035T713 980T616 960Q564 960 518 980T437 1034T382 1115T361
-1216ZM485 1216Q485 1189 495 1166T523 1125T565 1098T616 1088Q643 1088 666 1097T706 1124T733 1165T743 1216Q743 1244 734 1268T707 1311T666 1339T616 1349Q589 1349 565 1339T524 1311T496 1269T485 1216Z" />
-<glyph unicode="&#xb1;" glyph-name="plusminus" horiz-adv-x="1229" d="M709 855H1072V703H709V289H541V703H156V855H541V1267H709V855ZM1030 1H195V152H1030V1Z" />
-<glyph unicode="&#xb2;" glyph-name="twosuperior" horiz-adv-x="1229" d="M934 667H335V775L623 1046Q688 1106 716 1149T744 1228Q744 1277 711 1307T620 1338Q546 1338 511 1301T474 1205H316Q316 1259 337 1307T397 1390T491 1446T616 1467Q682 1467 735 1451T825
-1403T882 1329T902 1230Q902 1190 889 1155T850 1085T789 1015T710 940L535 795H934V667Z" />
-<glyph unicode="&#xb3;" glyph-name="threesuperior" horiz-adv-x="1229" d="M526 1125H610Q680 1125 718 1154T756 1234Q756 1279 723 1308T623 1337Q566 1337 529 1313T491 1245H334Q334 1296 356 1337T417 1406T508 1450T620 1466Q684 1466 738 1452T831 1409T891
-1338T913 1241Q913 1185 878 1140T777 1070Q927 1028 927 886Q927 830 904 787T839 715T741 671T621 655Q564 655 511 668T416 710T349 783T323 888H481Q482 842 521 813T626 783Q694 783 732 813T769 894Q769 957 726 983T610 1009H526V1125Z" />
-<glyph unicode="&#xb4;" glyph-name="acute" horiz-adv-x="1229" d="M594 1481H818L550 1215H410L594 1481Z" />
-<glyph unicode="&#xb5;" glyph-name="mu" horiz-adv-x="1229" d="M373 1082V460Q373 360 389 296T434 195T504 144T593 130Q700 130 762 171T854 283V1082H1040V0H873L864 116Q820 51 756 16T601 -20Q455 -20 373 53V-416H188V1082H373Z" />
-<glyph unicode="&#xb6;" glyph-name="paragraph" horiz-adv-x="1229" d="M790 0V520H703Q585 520 494 555T339 652T244 800T211 988Q211 1089 243 1174T339 1322T493 1420T703 1456H976V0H790Z" />
-<glyph unicode="&#xb7;" glyph-name="middot" horiz-adv-x="1229" d="M504 729Q504 777 533 809T619 841Q675 841 704 809T734 729Q734 682 705 651T619 619Q562 619 533 650T504 729Z" />
-<glyph unicode="&#xb8;" glyph-name="cedilla" horiz-adv-x="1229" d="M630 0L618 -52Q647 -57 674 -69T723 -101T758 -151T771 -225Q771 -322 692 -378T468 -435L461 -328Q495 -328 525 -323T577 -305T613 -275T627 -229Q627 -204 617 -187T587 -160T536 -143T466
--134L497 0H630Z" />
-<glyph unicode="&#xb9;" glyph-name="onesuperior" horiz-adv-x="1229" d="M758 665H601V1266L386 1209V1337L740 1454H758V665Z" />
-<glyph unicode="&#xba;" glyph-name="ordmasculine" horiz-adv-x="1229" d="M272 1141Q272 1214 296 1275T364 1381T472 1451T614 1476Q693 1476 756 1451T864 1382T932 1276T956 1141V1024Q956 952 933 891T865 785T758 715T616 690Q536 690 473 715T365 784T296
-890T272 1024V1141ZM435 1024Q435 982 446 947T479 885T536 844T616 829Q660 829 693 844T749 885T782 946T794 1024V1141Q794 1182 783 1217T749 1279T693 1321T614 1336Q569 1336 536 1321T480 1280T446 1218T435 1141V1024Z" />
-<glyph unicode="&#xbb;" glyph-name="guillemotright" horiz-adv-x="1229" d="M383 949L677 560V541L383 152H241L499 550L241 949H383ZM728 949L1022 560V541L728 152H586L844 550L586 949H728Z" />
-<glyph unicode="&#xbc;" glyph-name="onequarter" horiz-adv-x="1229" d="M383 751H242V1292L48 1241V1356L367 1461H383V751ZM658 221L545 287L1058 1241L1172 1175L658 221ZM1068 269H1164V152H1068V0H927V152H589L584 244L923 710H1068V269ZM726 269H927V529L912
-504L726 269Z" />
-<glyph unicode="&#xbd;" glyph-name="onehalf" horiz-adv-x="1229" d="M598 221L485 287L998 1241L1112 1175L598 221ZM371 747H230V1288L36 1237V1352L355 1457H371V747ZM1174 0H635V97L894 341Q952 395 977 434T1003 505Q1003 549 973 576T891 604Q825 604 793
-570T760 484H618Q618 533 636 576T690 651T776 701T888 720Q947 720 994 705T1075 663T1127 596T1145 507Q1145 471 1133 439T1098 376T1043 313T972 246L815 115H1174V0Z" />
-<glyph unicode="&#xbe;" glyph-name="threequarters" horiz-adv-x="1229" d="M469 220L356 286L869 1240L983 1174L469 220ZM1101 269H1197V152H1101V0H960V152H622L617 244L956 710H1101V269ZM759 269H960V529L945 504L759 269ZM221 1157H296Q359 1157 393 1183T428
-1255Q428 1296 398 1322T308 1348Q257 1348 224 1327T189 1265H48Q48 1311 68 1348T123 1410T204 1450T305 1464Q363 1464 411 1451T495 1413T549 1349T569 1262Q569 1211 537 1171T446 1108Q581 1070 581 942Q581 892 560 853T502 788T414 748T306 734Q255 734
-207 746T121 784T61 849T38 944H180Q181 902 216 876T311 849Q372 849 406 876T439 949Q439 1006 400 1029T296 1053H221V1157Z" />
-<glyph unicode="&#xbf;" glyph-name="questiondown" horiz-adv-x="1229" d="M724 673Q723 602 719 556T699 474T655 405T576 326Q545 291 512 254T452 175T407 89T389 -7Q389 -116 447 -173T614 -231Q657 -231 697 -220T769 -184T820 -122T839 -32H1024Q1023 -116
-992 -183T905 -296T776 -367T614 -392Q517 -392 441 -367T312 -292T232 -173T204 -13Q204 59 227 123T287 243T369 349T460 442Q489 471 505 496T528 547T537 604T539 673H724ZM509 988Q509 1036 538 1068T624 1101Q681 1101 710 1069T739 988Q739 942 710 911T624
-879Q567 879 538 910T509 988Z" />
-<glyph unicode="&#xc0;" glyph-name="Agrave" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538ZM710 1561H560L312 1827H535L710 1561Z" />
-<glyph unicode="&#xc1;" glyph-name="Aacute" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538ZM727 1824H951L683 1558H543L727 1824Z" />
-<glyph unicode="&#xc2;" glyph-name="Acircumflex" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538ZM933 1624V1599H779L629 1750L480 1599H328V1625L573 1864H685L933 1624Z" />
-<glyph unicode="&#xc3;" glyph-name="Atilde" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538ZM973 1844Q973 1799 958 1758T915 1687T850 1638T767 1620Q734 1620 708 1627T661 1644T620 1667T582
-1690T540 1708T491 1715Q447 1715 419 1683T389 1604L285 1628Q285 1673 300 1714T343 1787T407 1838T491 1857Q533 1857 566 1842T631 1810T695 1777T767 1762Q788 1762 807 1771T839 1795T861 1830T870 1874L973 1844Z" />
-<glyph unicode="&#xc4;" glyph-name="Adieresis" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538ZM302 1718Q302 1763 329 1793T411 1824Q465 1824 493 1794T521 1718Q521 1673 493 1643T411 1613Q357
-1613 330 1643T302 1718ZM732 1716Q732 1761 759 1792T841 1823Q895 1823 923 1792T951 1716Q951 1672 923 1642T841 1611Q787 1611 760 1641T732 1716Z" />
-<glyph unicode="&#xc5;" glyph-name="Aring" horiz-adv-x="1229" d="M869 377H383L266 0H81L551 1456H706L1168 0H984L869 377ZM433 538H820L628 1170L433 538ZM424 1732Q424 1775 440 1811T484 1874T549 1916T629 1931Q671 1931 707 1916T771 1875T815 1812T831
-1732Q831 1689 815 1653T772 1592T708 1552T629 1538Q587 1538 550 1552T485 1591T441 1653T424 1732ZM523 1732Q523 1710 531 1691T554 1658T588 1635T629 1627Q651 1627 669 1635T702 1657T724 1690T732 1732Q732 1780 703 1810T629 1841Q585 1841 554 1811T523
-1732Z" />
-<glyph unicode="&#xc6;" glyph-name="AE" horiz-adv-x="1229" d="M1195 0H664L663 353H353L230 0H32L592 1456H1172V1304H835L837 833H1139V682H837L838 151H1195V0ZM414 527H663L661 1233L414 527Z" />
-<glyph unicode="&#xc7;" glyph-name="Ccedilla" horiz-adv-x="1229" d="M1117 438Q1104 337 1065 253T964 108T816 14T625 -20Q535 -20 462 5T331 76T232 182T163 315T122 466T107 626V829Q108 910 121 989T162 1140T231 1273T330 1380T461 1450T625 1476Q734
-1476 820 1443T968 1348T1067 1200T1117 1010H932Q923 1076 901 1133T842 1233T752 1300T625 1325Q559 1325 509 1304T422 1245T361 1159T321 1055T300 943T293 831V626Q293 572 299 515T321 402T360 297T421 211T508 152T625 130Q698 130 751 153T842 217T901
-315T932 438H1117ZM684 0L672 -52Q701 -57 728 -69T777 -101T812 -151T825 -225Q825 -322 746 -378T522 -435L515 -328Q549 -328 579 -323T631 -305T667 -275T681 -229Q681 -204 671 -187T641 -160T590 -143T520 -134L551 0H684Z" />
-<glyph unicode="&#xc8;" glyph-name="Egrave" horiz-adv-x="1229" d="M975 673H367V157H1076V0H182V1456H1067V1298H367V830H975V673ZM700 1561H550L302 1827H525L700 1561Z" />
-<glyph unicode="&#xc9;" glyph-name="Eacute" horiz-adv-x="1229" d="M975 673H367V157H1076V0H182V1456H1067V1298H367V830H975V673ZM717 1824H941L673 1558H533L717 1824Z" />
-<glyph unicode="&#xca;" glyph-name="Ecircumflex" horiz-adv-x="1229" d="M975 673H367V157H1076V0H182V1456H1067V1298H367V830H975V673ZM923 1624V1599H769L619 1750L470 1599H318V1625L563 1864H675L923 1624Z" />
-<glyph unicode="&#xcb;" glyph-name="Edieresis" horiz-adv-x="1229" d="M975 673H367V157H1076V0H182V1456H1067V1298H367V830H975V673ZM292 1718Q292 1763 319 1793T401 1824Q455 1824 483 1794T511 1718Q511 1673 483 1643T401 1613Q347 1613 320 1643T292
-1718ZM722 1716Q722 1761 749 1792T831 1823Q885 1823 913 1792T941 1716Q941 1672 913 1642T831 1611Q777 1611 750 1641T722 1716Z" />
-<glyph unicode="&#xcc;" glyph-name="Igrave" horiz-adv-x="1229" d="M174 1456H1054V1295H705V160H1054V0H174V160H515V1295H174V1456ZM648 1561H498L250 1827H473L648 1561Z" />
-<glyph unicode="&#xcd;" glyph-name="Iacute" horiz-adv-x="1229" d="M174 1456H1054V1295H705V160H1054V0H174V160H515V1295H174V1456ZM665 1824H889L621 1558H481L665 1824Z" />
-<glyph unicode="&#xce;" glyph-name="Icircumflex" horiz-adv-x="1229" d="M174 1456H1054V1295H705V160H1054V0H174V160H515V1295H174V1456ZM871 1624V1599H717L567 1750L418 1599H266V1625L511 1864H623L871 1624Z" />
-<glyph unicode="&#xcf;" glyph-name="Idieresis" horiz-adv-x="1229" d="M174 1456H1054V1295H705V160H1054V0H174V160H515V1295H174V1456ZM241 1718Q241 1763 268 1793T350 1824Q404 1824 432 1794T460 1718Q460 1673 432 1643T350 1613Q296 1613 269 1643T241
-1718ZM671 1716Q671 1761 698 1792T780 1823Q834 1823 862 1792T890 1716Q890 1672 862 1642T780 1611Q726 1611 699 1641T671 1716Z" />
-<glyph unicode="&#xd0;" glyph-name="Eth" horiz-adv-x="1259" d="M185 0V666H-44V817H185V1456H522Q674 1454 793 1405T995 1267T1121 1055T1166 781V674Q1165 524 1122 401T996 189T794 51T522 0H185ZM593 666H373V151H522Q640 152 726 192T868 303T952 468T981
-674V783Q980 894 952 988T868 1152T726 1262T522 1304H373V817H593V666Z" />
-<glyph unicode="&#xd1;" glyph-name="Ntilde" horiz-adv-x="1229" d="M1086 0H898L333 1088L330 0H143V1456H331L896 370L899 1456H1086V0ZM934 1844Q934 1799 919 1758T876 1687T811 1638T728 1620Q695 1620 669 1627T622 1644T581 1667T543 1690T501 1708T452
-1715Q408 1715 380 1683T350 1604L246 1628Q246 1673 261 1714T304 1787T368 1838T452 1857Q494 1857 527 1842T592 1810T656 1777T728 1762Q749 1762 768 1771T800 1795T822 1830T831 1874L934 1844Z" />
-<glyph unicode="&#xd2;" glyph-name="Ograve" horiz-adv-x="1229" d="M1121 644Q1120 566 1108 487T1069 333T1003 195T906 83T778 8T615 -20Q525 -20 453 7T324 83T227 195T160 334T120 487T106 644V810Q107 888 119 967T158 1121T225 1259T322 1372T450 1448T613
-1476Q703 1476 776 1449T905 1373T1001 1261T1068 1122T1107 968T1121 810V644ZM938 812Q937 864 931 920T911 1032T872 1138T812 1227T727 1288T613 1311Q549 1311 500 1288T415 1227T355 1138T317 1032T296 920T288 812V644Q289 593 295 536T317 424T356 317T416
-228T501 166T615 143Q680 143 729 166T814 227T873 316T911 422T931 535T938 644V812ZM714 1582H564L316 1848H539L714 1582Z" />
-<glyph unicode="&#xd3;" glyph-name="Oacute" horiz-adv-x="1229" d="M1121 644Q1120 566 1108 487T1069 333T1003 195T906 83T778 8T615 -20Q525 -20 453 7T324 83T227 195T160 334T120 487T106 644V810Q107 888 119 967T158 1121T225 1259T322 1372T450 1448T613
-1476Q703 1476 776 1449T905 1373T1001 1261T1068 1122T1107 968T1121 810V644ZM938 812Q937 864 931 920T911 1032T872 1138T812 1227T727 1288T613 1311Q549 1311 500 1288T415 1227T355 1138T317 1032T296 920T288 812V644Q289 593 295 536T317 424T356 317T416
-228T501 166T615 143Q680 143 729 166T814 227T873 316T911 422T931 535T938 644V812ZM731 1845H955L687 1579H547L731 1845Z" />
-<glyph unicode="&#xd4;" glyph-name="Ocircumflex" horiz-adv-x="1229" d="M1121 644Q1120 566 1108 487T1069 333T1003 195T906 83T778 8T615 -20Q525 -20 453 7T324 83T227 195T160 334T120 487T106 644V810Q107 888 119 967T158 1121T225 1259T322 1372T450
-1448T613 1476Q703 1476 776 1449T905 1373T1001 1261T1068 1122T1107 968T1121 810V644ZM938 812Q937 864 931 920T911 1032T872 1138T812 1227T727 1288T613 1311Q549 1311 500 1288T415 1227T355 1138T317 1032T296 920T288 812V644Q289 593 295 536T317 424T356
-317T416 228T501 166T615 143Q680 143 729 166T814 227T873 316T911 422T931 535T938 644V812ZM937 1645V1620H783L633 1771L484 1620H332V1646L577 1885H689L937 1645Z" />
-<glyph unicode="&#xd5;" glyph-name="Otilde" horiz-adv-x="1229" d="M1121 644Q1120 566 1108 487T1069 333T1003 195T906 83T778 8T615 -20Q525 -20 453 7T324 83T227 195T160 334T120 487T106 644V810Q107 888 119 967T158 1121T225 1259T322 1372T450 1448T613
-1476Q703 1476 776 1449T905 1373T1001 1261T1068 1122T1107 968T1121 810V644ZM938 812Q937 864 931 920T911 1032T872 1138T812 1227T727 1288T613 1311Q549 1311 500 1288T415 1227T355 1138T317 1032T296 920T288 812V644Q289 593 295 536T317 424T356 317T416
-228T501 166T615 143Q680 143 729 166T814 227T873 316T911 422T931 535T938 644V812ZM977 1865Q977 1820 962 1779T919 1708T854 1659T771 1641Q738 1641 712 1648T665 1665T624 1688T586 1711T544 1729T495 1736Q451 1736 423 1704T393 1625L289 1649Q289 1694
-304 1735T347 1808T411 1859T495 1878Q537 1878 570 1863T635 1831T699 1798T771 1783Q792 1783 811 1792T843 1816T865 1851T874 1895L977 1865Z" />
-<glyph unicode="&#xd6;" glyph-name="Odieresis" horiz-adv-x="1229" d="M1121 644Q1120 566 1108 487T1069 333T1003 195T906 83T778 8T615 -20Q525 -20 453 7T324 83T227 195T160 334T120 487T106 644V810Q107 888 119 967T158 1121T225 1259T322 1372T450 1448T613
-1476Q703 1476 776 1449T905 1373T1001 1261T1068 1122T1107 968T1121 810V644ZM938 812Q937 864 931 920T911 1032T872 1138T812 1227T727 1288T613 1311Q549 1311 500 1288T415 1227T355 1138T317 1032T296 920T288 812V644Q289 593 295 536T317 424T356 317T416
-228T501 166T615 143Q680 143 729 166T814 227T873 316T911 422T931 535T938 644V812ZM306 1739Q306 1784 333 1814T415 1845Q469 1845 497 1815T525 1739Q525 1694 497 1664T415 1634Q361 1634 334 1664T306 1739ZM736 1737Q736 1782 763 1813T845 1844Q899 1844
-927 1813T955 1737Q955 1693 927 1663T845 1632Q791 1632 764 1662T736 1737Z" />
-<glyph unicode="&#xd7;" glyph-name="multiply" horiz-adv-x="1229" d="M181 329L511 666L184 1000L303 1123L631 788L960 1123L1079 1000L751 666L1082 329L963 206L631 543L300 206L181 329Z" />
-<glyph unicode="&#xd8;" glyph-name="Oslash" horiz-adv-x="1229" d="M1113 644Q1112 566 1100 487T1061 333T995 195T898 83T770 8T607 -20Q516 -20 445 7T317 83L213 -93H71L231 177Q197 226 172 282T131 398T106 520T98 644V810Q99 888 111 967T150 1121T217
-1259T314 1372T442 1448T605 1476Q707 1476 785 1442T923 1348L1022 1516H1164L1003 1244Q1031 1197 1051 1145T1085 1037T1105 924T1113 810V644ZM280 644Q281 575 292 498T333 350L831 1193Q794 1246 739 1278T605 1311Q541 1311 492 1288T407 1227T347 1138T309
-1032T288 920T280 812V644ZM930 812Q929 870 922 934T895 1061L404 231Q441 190 491 167T607 143Q672 143 721 166T806 227T865 316T903 422T923 535T930 644V812Z" />
-<glyph unicode="&#xd9;" glyph-name="Ugrave" horiz-adv-x="1229" d="M1088 1456L1090 470Q1088 368 1053 279T955 124T805 19T614 -20Q508 -20 421 18T272 122T175 278T139 470L141 1456H317L321 470Q322 405 341 345T397 239T488 165T614 137Q685 137 739 164T829
-238T885 345T906 470L909 1456H1088ZM740 1549H590L342 1815H565L740 1549Z" />
-<glyph unicode="&#xda;" glyph-name="Uacute" horiz-adv-x="1229" d="M1088 1456L1090 470Q1088 368 1053 279T955 124T805 19T614 -20Q508 -20 421 18T272 122T175 278T139 470L141 1456H317L321 470Q322 405 341 345T397 239T488 165T614 137Q685 137 739 164T829
-238T885 345T906 470L909 1456H1088ZM757 1812H981L713 1546H573L757 1812Z" />
-<glyph unicode="&#xdb;" glyph-name="Ucircumflex" horiz-adv-x="1229" d="M1088 1456L1090 470Q1088 368 1053 279T955 124T805 19T614 -20Q508 -20 421 18T272 122T175 278T139 470L141 1456H317L321 470Q322 405 341 345T397 239T488 165T614 137Q685 137 739
-164T829 238T885 345T906 470L909 1456H1088ZM963 1612V1587H809L659 1738L510 1587H358V1613L603 1852H715L963 1612Z" />
-<glyph unicode="&#xdc;" glyph-name="Udieresis" horiz-adv-x="1229" d="M1088 1456L1090 470Q1088 368 1053 279T955 124T805 19T614 -20Q508 -20 421 18T272 122T175 278T139 470L141 1456H317L321 470Q322 405 341 345T397 239T488 165T614 137Q685 137 739
-164T829 238T885 345T906 470L909 1456H1088ZM332 1706Q332 1751 359 1781T441 1812Q495 1812 523 1782T551 1706Q551 1661 523 1631T441 1601Q387 1601 360 1631T332 1706ZM762 1704Q762 1749 789 1780T871 1811Q925 1811 953 1780T981 1704Q981 1660 953 1630T871
-1599Q817 1599 790 1629T762 1704Z" />
-<glyph unicode="&#xdd;" glyph-name="Yacute" horiz-adv-x="1229" d="M603 725L935 1456H1145L692 543L689 0H517L514 543L61 1456H272L603 725ZM707 1823H931L663 1557H523L707 1823Z" />
-<glyph unicode="&#xde;" glyph-name="Thorn" horiz-adv-x="1229" d="M353 1456V1163H630Q747 1163 837 1132T990 1044T1085 909T1118 738Q1118 645 1086 567T991 433T838 345T630 313H353V0H168V1456H353ZM353 1011V465H630Q708 465 765 487T859 547T915 634T933
-736Q933 790 915 839T860 927T766 988T630 1011H353Z" />
-<glyph unicode="&#xdf;" glyph-name="germandbls" horiz-adv-x="1229" d="M353 0H169V1087Q169 1199 198 1287T280 1435T405 1526T562 1558Q637 1558 702 1538T816 1475T893 1370T921 1220Q921 1141 901 1088T857 992T814 912T794 823Q794 777 816 740T873 668T947
-598T1021 522T1077 431T1100 316Q1100 231 1075 168T1003 63T894 0T754 -21Q713 -21 669 -16T585 -1T510 22T456 51L498 206Q516 195 542 182T600 157T666 138T735 130Q782 130 816 143T872 181T904 237T915 307Q915 354 893 392T836 465T762 535T688 612T631 705T608
-825Q608 864 618 897T643 959T677 1016T710 1073T736 1134T746 1204Q746 1254 731 1291T692 1354T636 1393T572 1406Q473 1406 414 1324T353 1087V0Z" />
-<glyph unicode="&#xe0;" glyph-name="agrave" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786 895T706
-938T599 953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521
-525 431 477T341 326Q341 286 354 252T395 194T463 155T558 141ZM962 1239H812L564 1505H787L962 1239Z" />
-<glyph unicode="&#xe1;" glyph-name="aacute" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786 895T706
-938T599 953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521
-525 431 477T341 326Q341 286 354 252T395 194T463 155T558 141ZM723 1502H947L679 1236H539L723 1502Z" />
-<glyph unicode="&#xe2;" glyph-name="acircumflex" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786
-895T706 938T599 953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521
-525 431 477T341 326Q341 286 354 252T395 194T463 155T558 141ZM929 1302V1277H775L625 1428L476 1277H324V1303L569 1542H681L929 1302Z" />
-<glyph unicode="&#xe3;" glyph-name="atilde" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786 895T706
-938T599 953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521
-525 431 477T341 326Q341 286 354 252T395 194T463 155T558 141ZM969 1522Q969 1477 954 1436T911 1365T846 1316T763 1298Q730 1298 704 1305T657 1322T616 1345T578 1368T536 1386T487 1393Q443 1393 415 1361T385 1282L281 1306Q281 1351 296 1392T339 1465T403
-1516T487 1535Q529 1535 562 1520T627 1488T691 1455T763 1440Q784 1440 803 1449T835 1473T857 1508T866 1552L969 1522Z" />
-<glyph unicode="&#xe4;" glyph-name="adieresis" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786 895T706
-938T599 953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521
-525 431 477T341 326Q341 286 354 252T395 194T463 155T558 141ZM298 1396Q298 1441 325 1471T407 1502Q461 1502 489 1472T517 1396Q517 1351 489 1321T407 1291Q353 1291 326 1321T298 1396ZM728 1394Q728 1439 755 1470T837 1501Q891 1501 919 1470T947 1394Q947
-1350 919 1320T837 1289Q783 1289 756 1319T728 1394Z" />
-<glyph unicode="&#xe5;" glyph-name="aring" horiz-adv-x="1229" d="M885 0Q874 21 868 52T858 118Q830 90 796 65T720 21T631 -9T531 -20Q445 -20 376 5T258 72T183 173T156 300Q156 389 191 456T292 567T448 634T653 656H855V741Q855 790 837 829T786 895T706
-938T599 953Q544 953 501 939T427 902T381 848T364 782H178Q179 841 208 898T293 1000T428 1074T609 1102Q701 1102 780 1080T916 1012T1007 898T1040 739V236Q1040 182 1050 122T1078 16V0H885ZM558 141Q612 141 659 155T744 192T811 244T855 306V525H683Q521
-525 431 477T341 326Q341 286 354 252T395 194T463 155T558 141ZM420 1410Q420 1453 436 1489T480 1552T545 1594T625 1609Q667 1609 703 1594T767 1553T811 1490T827 1410Q827 1367 811 1331T768 1270T704 1230T625 1216Q583 1216 546 1230T481 1269T437 1331T420
-1410ZM519 1410Q519 1388 527 1369T550 1336T584 1313T625 1305Q647 1305 665 1313T698 1335T720 1368T728 1410Q728 1458 699 1488T625 1519Q581 1519 550 1489T519 1410Z" />
-<glyph unicode="&#xe6;" glyph-name="ae" horiz-adv-x="1229" d="M896 -20Q793 -20 719 17T599 126Q580 97 555 71T496 24T423 -8T335 -20Q264 -20 210 2T119 63T63 159T43 285Q43 451 147 543T448 635H511V783Q511 859 480 904T381 950Q318 950 279 909T240 792L61
-800Q61 869 83 924T147 1019T248 1080T379 1102Q462 1102 524 1075T626 995Q669 1046 728 1074T862 1102Q943 1102 1004 1076T1108 1001T1171 884T1193 731V497H688V411Q688 345 701 293T744 205T820 150T932 130Q970 130 999 137T1052 154T1095 177T1130 200L1176
-64Q1163 54 1140 40T1083 12T1002 -10T896 -20ZM862 950Q817 950 785 931T731 878T700 801T688 709V640H1017V768Q1017 803 1007 835T977 893T928 934T862 950ZM371 130Q408 130 446 151T512 202L511 495H450Q397 495 355 478T284 431T240 363T224 281Q224 250
-233 223T261 175T307 142T371 130Z" />
-<glyph unicode="&#xe7;" glyph-name="ccedilla" horiz-adv-x="1229" d="M635 130Q685 130 732 146T817 190T876 257T900 341H1075Q1074 269 1038 204T940 89T800 10T635 -20Q512 -20 420 24T267 142T174 314T143 520V562Q143 669 174 767T266 939T420 1058T635
-1102Q731 1102 811 1072T950 989T1042 864T1075 710H900Q899 759 879 802T823 879T740 931T635 950Q549 950 491 916T396 826T345 701T329 562V520Q329 449 344 380T395 255T489 165T635 130ZM705 0L693 -52Q722 -57 749 -69T798 -101T833 -151T846 -225Q846 -322
-767 -378T543 -435L536 -328Q570 -328 600 -323T652 -305T688 -275T702 -229Q702 -204 692 -187T662 -160T611 -143T541 -134L572 0H705Z" />
-<glyph unicode="&#xe8;" glyph-name="egrave" horiz-adv-x="1229" d="M652 -20Q538 -20 443 19T279 128T173 294T135 503V545Q135 676 177 779T288 954T446 1064T628 1102Q745 1102 832 1062T978 950T1064 781T1093 571V488H320Q323 414 348 349T418 236T525 159T662
-131Q761 131 838 171T966 277L1079 189Q1052 148 1012 111T918 44T798 -2T652 -20ZM628 950Q572 950 522 930T432 870T365 773T326 640H908V654Q905 708 888 761T836 856T751 924T628 950ZM957 1240H807L559 1506H782L957 1240Z" />
-<glyph unicode="&#xe9;" glyph-name="eacute" horiz-adv-x="1229" d="M652 -20Q538 -20 443 19T279 128T173 294T135 503V545Q135 676 177 779T288 954T446 1064T628 1102Q745 1102 832 1062T978 950T1064 781T1093 571V488H320Q323 414 348 349T418 236T525 159T662
-131Q761 131 838 171T966 277L1079 189Q1052 148 1012 111T918 44T798 -2T652 -20ZM628 950Q572 950 522 930T432 870T365 773T326 640H908V654Q905 708 888 761T836 856T751 924T628 950ZM718 1503H942L674 1237H534L718 1503Z" />
-<glyph unicode="&#xea;" glyph-name="ecircumflex" horiz-adv-x="1229" d="M652 -20Q538 -20 443 19T279 128T173 294T135 503V545Q135 676 177 779T288 954T446 1064T628 1102Q745 1102 832 1062T978 950T1064 781T1093 571V488H320Q323 414 348 349T418 236T525
-159T662 131Q761 131 838 171T966 277L1079 189Q1052 148 1012 111T918 44T798 -2T652 -20ZM628 950Q572 950 522 930T432 870T365 773T326 640H908V654Q905 708 888 761T836 856T751 924T628 950ZM924 1303V1278H770L620 1429L471 1278H319V1304L564 1543H676L924
-1303Z" />
-<glyph unicode="&#xeb;" glyph-name="edieresis" horiz-adv-x="1229" d="M652 -20Q538 -20 443 19T279 128T173 294T135 503V545Q135 676 177 779T288 954T446 1064T628 1102Q745 1102 832 1062T978 950T1064 781T1093 571V488H320Q323 414 348 349T418 236T525
-159T662 131Q761 131 838 171T966 277L1079 189Q1052 148 1012 111T918 44T798 -2T652 -20ZM628 950Q572 950 522 930T432 870T365 773T326 640H908V654Q905 708 888 761T836 856T751 924T628 950ZM293 1397Q293 1442 320 1472T402 1503Q456 1503 484 1473T512
-1397Q512 1352 484 1322T402 1292Q348 1292 321 1322T293 1397ZM723 1395Q723 1440 750 1471T832 1502Q886 1502 914 1471T942 1395Q942 1351 914 1321T832 1290Q778 1290 751 1320T723 1395Z" />
-<glyph unicode="&#xec;" glyph-name="igrave" horiz-adv-x="1229" d="M203 1082H756V160H1109V0H203V160H571V921H203V1082ZM1003 1218H853L605 1484H828L1003 1218Z" />
-<glyph unicode="&#xed;" glyph-name="iacute" horiz-adv-x="1229" d="M203 1082H756V160H1109V0H203V160H571V921H203V1082ZM764 1481H988L720 1215H580L764 1481Z" />
-<glyph unicode="&#xee;" glyph-name="icircumflex" horiz-adv-x="1229" d="M203 1082H756V160H1109V0H203V160H571V921H203V1082ZM970 1281V1256H816L666 1407L517 1256H365V1282L610 1521H722L970 1281Z" />
-<glyph unicode="&#xef;" glyph-name="idieresis" horiz-adv-x="1229" d="M203 1082H756V160H1109V0H203V160H571V921H203V1082ZM339 1375Q339 1420 366 1450T448 1481Q502 1481 530 1451T558 1375Q558 1330 530 1300T448 1270Q394 1270 367 1300T339 1375ZM769
-1373Q769 1418 796 1449T878 1480Q932 1480 960 1449T988 1373Q988 1329 960 1299T878 1268Q824 1268 797 1298T769 1373Z" />
-<glyph unicode="&#xf0;" glyph-name="eth" horiz-adv-x="1229" d="M845 1286Q949 1168 1007 1004T1066 633V571Q1066 433 1029 324T924 138T766 21T565 -20Q457 -20 367 17T211 121T109 276T73 467Q73 582 109 676T211 837T366 940T561 977Q649 977 725 943T859
-853Q836 963 791 1047T684 1194L418 1042L345 1141L584 1278Q543 1305 500 1325T410 1362L467 1521Q547 1499 618 1463T753 1375L983 1507L1056 1407L845 1286ZM881 635Q881 648 881 660T880 685Q863 712 835 737T766 782T675 813T561 825Q492 825 436 797T341
-719T280 605T259 467Q259 405 280 345T340 237T437 160T569 130Q641 130 698 162T796 251T859 390T881 571V635Z" />
-<glyph unicode="&#xf1;" glyph-name="ntilde" horiz-adv-x="1229" d="M340 1082L353 922Q412 1006 498 1053T690 1102Q775 1102 844 1078T963 1003T1038 874T1065 687V0H880V683Q880 755 864 805T817 886T740 931T635 945Q542 945 472 899T359 776V0H174V1082H340ZM949
-1522Q949 1477 934 1436T891 1365T826 1316T743 1298Q710 1298 684 1305T637 1322T596 1345T558 1368T516 1386T467 1393Q423 1393 395 1361T365 1282L261 1306Q261 1351 276 1392T319 1465T383 1516T467 1535Q509 1535 542 1520T607 1488T671 1455T743 1440Q764
-1440 783 1449T815 1473T837 1508T846 1552L949 1522Z" />
-<glyph unicode="&#xf2;" glyph-name="ograve" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q728 1102 819 1060T974 943T1072 769T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q500 -20 409 22T254 138T156 312T122
-529V551ZM307 529Q307 449 326 377T383 249T480 162T615 130Q691 130 748 162T844 249T902 376T921 529V551Q921 630 902 702T844 830T748 917T613 950Q536 950 479 918T384 830T326 703T307 551V529ZM951 1239H801L553 1505H776L951 1239Z" />
-<glyph unicode="&#xf3;" glyph-name="oacute" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q728 1102 819 1060T974 943T1072 769T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q500 -20 409 22T254 138T156 312T122
-529V551ZM307 529Q307 449 326 377T383 249T480 162T615 130Q691 130 748 162T844 249T902 376T921 529V551Q921 630 902 702T844 830T748 917T613 950Q536 950 479 918T384 830T326 703T307 551V529ZM712 1502H936L668 1236H528L712 1502Z" />
-<glyph unicode="&#xf4;" glyph-name="ocircumflex" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q728 1102 819 1060T974 943T1072 769T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q500 -20 409 22T254 138T156 312T122
-529V551ZM307 529Q307 449 326 377T383 249T480 162T615 130Q691 130 748 162T844 249T902 376T921 529V551Q921 630 902 702T844 830T748 917T613 950Q536 950 479 918T384 830T326 703T307 551V529ZM918 1302V1277H764L614 1428L465 1277H313V1303L558 1542H670L918
-1302Z" />
-<glyph unicode="&#xf5;" glyph-name="otilde" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q728 1102 819 1060T974 943T1072 769T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q500 -20 409 22T254 138T156 312T122
-529V551ZM307 529Q307 449 326 377T383 249T480 162T615 130Q691 130 748 162T844 249T902 376T921 529V551Q921 630 902 702T844 830T748 917T613 950Q536 950 479 918T384 830T326 703T307 551V529ZM958 1522Q958 1477 943 1436T900 1365T835 1316T752 1298Q719
-1298 693 1305T646 1322T605 1345T567 1368T525 1386T476 1393Q432 1393 404 1361T374 1282L270 1306Q270 1351 285 1392T328 1465T392 1516T476 1535Q518 1535 551 1520T616 1488T680 1455T752 1440Q773 1440 792 1449T824 1473T846 1508T855 1552L958 1522Z"
-/>
-<glyph unicode="&#xf6;" glyph-name="odieresis" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q728 1102 819 1060T974 943T1072 769T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q500 -20 409 22T254 138T156 312T122
-529V551ZM307 529Q307 449 326 377T383 249T480 162T615 130Q691 130 748 162T844 249T902 376T921 529V551Q921 630 902 702T844 830T748 917T613 950Q536 950 479 918T384 830T326 703T307 551V529ZM287 1396Q287 1441 314 1471T396 1502Q450 1502 478 1472T506
-1396Q506 1351 478 1321T396 1291Q342 1291 315 1321T287 1396ZM717 1394Q717 1439 744 1470T826 1501Q880 1501 908 1470T936 1394Q936 1350 908 1320T826 1289Q772 1289 745 1319T717 1394Z" />
-<glyph unicode="&#xf7;" glyph-name="divide" horiz-adv-x="1229" d="M1113 600H115V784H1113V600ZM507 1097Q507 1142 534 1173T616 1204Q670 1204 698 1173T726 1097Q726 1052 698 1022T616 992Q562 992 535 1022T507 1097ZM505 282Q505 327 532 358T614 389Q668
-389 696 358T724 282Q724 238 696 208T614 177Q560 177 533 207T505 282Z" />
-<glyph unicode="&#xf8;" glyph-name="oslash" horiz-adv-x="1229" d="M122 551Q122 668 156 768T253 943T408 1059T613 1102Q670 1102 720 1092T816 1061L889 1209H1012L911 1004Q1005 929 1055 812T1106 551V529Q1106 412 1072 312T975 138T820 22T615 -20Q561
--20 514 -11T423 16L349 -135H226L327 70Q228 143 175 262T122 529V551ZM307 529Q307 438 331 360T403 224L745 918Q716 933 684 941T613 950Q536 950 479 918T384 830T326 703T307 551V529ZM921 551Q921 636 899 712T832 845L492 156Q547 130 615 130Q691 130
-748 162T844 249T902 376T921 529V551Z" />
-<glyph unicode="&#xf9;" glyph-name="ugrave" horiz-adv-x="1229" d="M876 149Q822 69 741 25T554 -20Q469 -20 400 6T282 89T207 231T180 439V1082H365V437Q365 349 379 291T421 199T489 150T583 136Q696 136 765 182T869 306V1082H1055V0H887L876 149ZM950 1219H800L552
-1485H775L950 1219Z" />
-<glyph unicode="&#xfa;" glyph-name="uacute" horiz-adv-x="1229" d="M876 149Q822 69 741 25T554 -20Q469 -20 400 6T282 89T207 231T180 439V1082H365V437Q365 349 379 291T421 199T489 150T583 136Q696 136 765 182T869 306V1082H1055V0H887L876 149ZM711 1482H935L667
-1216H527L711 1482Z" />
-<glyph unicode="&#xfb;" glyph-name="ucircumflex" horiz-adv-x="1229" d="M876 149Q822 69 741 25T554 -20Q469 -20 400 6T282 89T207 231T180 439V1082H365V437Q365 349 379 291T421 199T489 150T583 136Q696 136 765 182T869 306V1082H1055V0H887L876 149ZM917
-1282V1257H763L613 1408L464 1257H312V1283L557 1522H669L917 1282Z" />
-<glyph unicode="&#xfc;" glyph-name="udieresis" horiz-adv-x="1229" d="M876 149Q822 69 741 25T554 -20Q469 -20 400 6T282 89T207 231T180 439V1082H365V437Q365 349 379 291T421 199T489 150T583 136Q696 136 765 182T869 306V1082H1055V0H887L876 149ZM287
-1376Q287 1421 314 1451T396 1482Q450 1482 478 1452T506 1376Q506 1331 478 1301T396 1271Q342 1271 315 1301T287 1376ZM717 1374Q717 1419 744 1450T826 1481Q880 1481 908 1450T936 1374Q936 1330 908 1300T826 1269Q772 1269 745 1299T717 1374Z" />
-<glyph unicode="&#xfd;" glyph-name="yacute" horiz-adv-x="1229" d="M572 384L620 253L950 1082H1157L608 -167Q589 -209 560 -256T488 -343T390 -410T261 -437Q248 -437 232 -436T200 -432T170 -426T147 -421L177 -270Q184 -270 196 -271T221 -273T246 -274T265
--275Q303 -275 334 -254T390 -204T432 -144T460 -93L534 51L68 1082H275L572 384ZM731 1482H955L687 1216H547L731 1482Z" />
-<glyph unicode="&#xfe;" glyph-name="thorn" horiz-adv-x="1229" d="M1087 529Q1087 413 1060 313T980 138T848 22T668 -20Q568 -20 491 12T358 107V-416H173V1558H358V970Q413 1034 489 1068T665 1102Q769 1102 848 1061T980 947T1060 773T1087 550V529ZM902
-550Q902 629 885 700T833 826T742 913T610 945Q519 945 457 904T358 796V278Q396 213 457 172T612 131Q688 131 743 163T833 251T885 378T902 529V550Z" />
-<glyph unicode="&#xff;" glyph-name="ydieresis" horiz-adv-x="1229" d="M572 384L620 253L950 1082H1157L608 -167Q589 -209 560 -256T488 -343T390 -410T261 -437Q248 -437 232 -436T200 -432T170 -426T147 -421L177 -270Q184 -270 196 -271T221 -273T246 -274T265
--275Q303 -275 334 -254T390 -204T432 -144T460 -93L534 51L68 1082H275L572 384ZM306 1376Q306 1421 333 1451T415 1482Q469 1482 497 1452T525 1376Q525 1331 497 1301T415 1271Q361 1271 334 1301T306 1376ZM736 1374Q736 1419 763 1450T845 1481Q899 1481 927
-1450T955 1374Q955 1330 927 1300T845 1269Q791 1269 764 1299T736 1374Z" />
-<glyph unicode="&#x2013;" glyph-name="endash" horiz-adv-x="1229" d="M1159 651H74V802H1159V651Z" />
-<glyph unicode="&#x2014;" glyph-name="emdash" horiz-adv-x="1229" d="M1164 651H79V802H1164V651Z" />
-<glyph unicode="&#x2018;" glyph-name="quoteleft" horiz-adv-x="1229" d="M492 1185Q492 1232 503 1284T537 1386T592 1483T666 1565L767 1493Q720 1422 697 1348T673 1188V1039H492V1185Z" />
-<glyph unicode="&#x2019;" glyph-name="quoteright" horiz-adv-x="1229" d="M736 1411Q736 1364 725 1312T691 1210T636 1113T562 1031L461 1103Q508 1174 531 1248T555 1408V1558H736V1411Z" />
-<glyph unicode="&#x201a;" glyph-name="quotesinglbase" horiz-adv-x="1229" d="M723 76Q723 29 712 -22T678 -124T623 -220T549 -303L444 -230Q491 -160 514 -86T538 74V225H723V76Z" />
-<glyph unicode="&#x201c;" glyph-name="quotedblleft" horiz-adv-x="1229" d="M329 1185Q329 1232 340 1284T374 1386T429 1483T503 1565L604 1493Q557 1422 534 1348T510 1188V1039H329V1185ZM654 1185Q654 1232 665 1284T699 1386T754 1483T828 1565L929 1493Q882
-1422 859 1348T835 1188V1039H654V1185Z" />
-<glyph unicode="&#x201d;" glyph-name="quotedblright" horiz-adv-x="1229" d="M576 1411Q576 1364 565 1312T531 1210T476 1113T402 1031L301 1103Q348 1174 371 1248T395 1408V1558H576V1411ZM908 1411Q908 1364 897 1312T863 1210T808 1113T734 1031L633 1103Q680
-1174 703 1248T727 1408V1558H908V1411Z" />
-<glyph unicode="&#x201e;" glyph-name="quotedblbase" horiz-adv-x="1229" d="M582 75Q582 28 571 -24T537 -126T482 -222T408 -305L303 -232Q350 -162 373 -88T397 72V223H582V75ZM872 75Q872 28 861 -24T827 -126T772 -222T698 -305L593 -232Q640 -162 663 -88T687
-72V223H872V75Z" />
-<glyph unicode="&#x2022;" glyph-name="bullet" horiz-adv-x="1229" d="M410 790Q410 833 424 869T465 932T528 973T613 988Q660 988 698 973T762 932T803 870T817 790V732Q817 689 803 653T763 591T699 550T614 535Q567 535 530 549T466 590T425 653T410 732V790Z" />
-<glyph unicode="&#x2039;" glyph-name="guilsinglleft" horiz-adv-x="1229" d="M574 550L832 153H691L396 541V560L691 949H832L574 550Z" />
-<glyph unicode="&#x203a;" glyph-name="guilsinglright" horiz-adv-x="1229" d="M538 949L832 560V541L538 152H396L654 550L396 949H538Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-mono-v5-latin-regular.ttf b/static/fonts/roboto-mono-v5-latin-regular.ttf
deleted file mode 100644
index 27363d17d0..0000000000
Binary files a/static/fonts/roboto-mono-v5-latin-regular.ttf and /dev/null differ
diff --git a/static/fonts/roboto-mono-v5-latin-regular.woff b/static/fonts/roboto-mono-v5-latin-regular.woff
deleted file mode 100644
index 0ea5db896b..0000000000
Binary files a/static/fonts/roboto-mono-v5-latin-regular.woff and /dev/null differ
diff --git a/static/fonts/roboto-mono-v5-latin-regular.woff2 b/static/fonts/roboto-mono-v5-latin-regular.woff2
deleted file mode 100644
index 6163de7b0a..0000000000
Binary files a/static/fonts/roboto-mono-v5-latin-regular.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100.eot b/static/fonts/roboto-v18-latin-100.eot
deleted file mode 100644
index 2187a1385f..0000000000
Binary files a/static/fonts/roboto-v18-latin-100.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100.svg b/static/fonts/roboto-v18-latin-100.svg
deleted file mode 100644
index e8c8fc835f..0000000000
--- a/static/fonts/roboto-v18-latin-100.svg
+++ /dev/null
@@ -1,313 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1113" ><font-face
-    font-family="Roboto Thin"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="490" />
-<glyph unicode="!" horiz-adv-x="397" d="M221 401H167V1456H221V401ZM147 49Q147 72 163 88T202 105T241 89T258 49T242 10T202 -6T163 10T147 49Z" />
-<glyph unicode="&quot;" horiz-adv-x="521" d="M210 1393L200 1122H150Q155 1390 155 1536H210V1393ZM411 1393L401 1122H351L357 1390V1536H411V1393Z" />
-<glyph unicode="#" horiz-adv-x="1121" d="M742 410H378L304 0H248L322 410H51V462H332L427 986H127V1040H437L512 1456H568L492 1040H857L933 1456H989L913 1040H1167V986H903L807 462H1092V410H798L723 0H667L742 410ZM388 462H751L847 986H482L388 462Z" />
-<glyph unicode="$" horiz-adv-x="1121" d="M947 344Q947 435 913 494T796 604T554 709T317 817T205 940T168 1110Q168 1273 275 1371T554 1476V1663H609V1476Q793 1466 893 1354T993 1047H939Q939 1217 843 1320T579 1424Q417 1424 320 1337T222 1112Q222 1014
-254 957T362 854T575 760T785 677T906 592T977 485T1001 346Q1001 187 898 89T620 -20V-208H565V-21Q353 -13 237 99T121 409H175Q175 232 285 132T586 32Q743 32 845 122T947 344Z" />
-<glyph unicode="%" horiz-adv-x="1527" d="M114 1176Q114 1305 192 1391T386 1477Q503 1477 580 1391T657 1171V1099Q657 972 581 886T388 800Q271 800 193 885T114 1105V1176ZM169 1099Q169 995 228 925T388 855Q484 855 543 924T602 1104V1176Q602 1284 543
-1353T386 1422Q291 1422 230 1353T169 1169V1099ZM870 357Q870 486 947 571T1141 657Q1258 657 1335 572T1413 350V279Q1413 150 1336 65T1143 -21Q1027 -21 949 64T870 284V357ZM925 279Q925 172 984 103T1143 34Q1241 34 1299 103T1358 284V357Q1358 470 1300
-536T1141 602Q1042 602 984 535T925 353V279ZM422 131L377 162L1088 1300L1133 1269L422 131Z" />
-<glyph unicode="&amp;" horiz-adv-x="1247" d="M422 802Q334 910 296 996T257 1167Q257 1308 341 1392T562 1477Q687 1477 762 1404T838 1213Q838 1077 650 921L494 797L969 258Q1084 418 1084 632H1139Q1139 395 1006 216L1196 0H1129L972 176Q776 -20 549 -20Q348
--20 232 80T115 352Q115 450 171 545T371 762L422 802ZM549 34Q660 34 760 81T937 217L454 764L402 723Q284 621 227 532T169 352Q169 210 272 122T549 34ZM312 1169Q312 1011 462 834L637 973Q782 1094 782 1213Q782 1305 721 1364T562 1423Q449 1423 381 1353T312
-1169Z" />
-<glyph unicode="&apos;" horiz-adv-x="340" d="M200 1367L186 1122H136L145 1365V1536H200V1367Z" />
-<glyph unicode="(" horiz-adv-x="607" d="M148 586Q148 802 201 1011T351 1386T562 1623L581 1580Q483 1515 396 1363T257 1011T202 616V564Q202 366 252 163T391 -200T581 -427L562 -470Q446 -397 351 -239T202 130T148 586Z" />
-<glyph unicode=")" horiz-adv-x="623" d="M461 566Q461 341 408 131T259 -238T47 -470L28 -427Q132 -357 221 -195T358 167T407 590Q407 792 356 995T217 1356T28 1580L47 1623Q160 1552 257 1386T408 1011T461 566Z" />
-<glyph unicode="*" horiz-adv-x="856" d="M393 1017L30 1141L48 1195L410 1062L411 1456H467L460 1061L812 1204L832 1151L472 1014L721 697L674 664L432 986L204 661L159 693L393 1017Z" />
-<glyph unicode="+" horiz-adv-x="1151" d="M590 702H1071V649H590V146H535V649H73V702H535V1206H590V702Z" />
-<glyph unicode="," horiz-adv-x="383" d="M129 -255L92 -223Q173 -119 180 -8L181 159H235V13Q231 -146 129 -255Z" />
-<glyph unicode="-" horiz-adv-x="607" d="M531 639H61V693H531V639Z" />
-<glyph unicode="." horiz-adv-x="439" d="M147 49Q147 72 163 88T202 105T241 89T258 49T242 10T202 -6T163 10T147 49Z" />
-<glyph unicode="/" horiz-adv-x="782" d="M101 -125H42L650 1456H709L101 -125Z" />
-<glyph unicode="0" horiz-adv-x="1121" d="M996 594Q996 301 882 141T562 -20Q357 -20 241 142T125 598V862Q125 1152 239 1314T560 1477Q767 1477 881 1315T996 858V594ZM942 862Q942 1127 843 1275T560 1423Q376 1423 278 1275T179 857V596Q179 332 280 183T562
-34Q744 34 843 183T942 601V862Z" />
-<glyph unicode="1" horiz-adv-x="1121" d="M659 0H605V1388L187 1231V1290L648 1460H659V0Z" />
-<glyph unicode="2" horiz-adv-x="1121" d="M1024 0H153V54L650 627Q772 770 831 881T891 1085Q891 1245 798 1333T536 1422Q434 1422 350 1373T219 1238T171 1045H117Q117 1162 171 1262T321 1419T536 1476Q730 1476 838 1373T946 1085Q946 915 755 678L664 567L224
-54H1024V0Z" />
-<glyph unicode="3" horiz-adv-x="1121" d="M417 770H539Q710 773 815 861T921 1085Q921 1240 827 1331T564 1422Q400 1422 294 1326T188 1074H134Q134 1190 190 1282T345 1425T564 1476Q753 1476 864 1370T975 1081Q975 965 902 874T703 745Q846 712 926 621T1007
-386Q1007 200 888 90T573 -20Q441 -20 329 37T160 188T103 405H157Q157 245 275 140T573 34Q752 34 852 126T953 382Q953 543 846 628T531 714H417V770Z" />
-<glyph unicode="4" horiz-adv-x="1121" d="M842 451H1094V397H842V0H788V397H82V427L777 1456H842V451ZM166 451H788V1391L704 1253L166 451Z" />
-<glyph unicode="5" horiz-adv-x="1121" d="M231 762L299 1456H1009V1403H348L289 819Q341 862 426 889T594 916Q790 916 907 792T1024 464Q1024 227 918 104T614 -20Q427 -20 312 87T182 383H237Q253 212 349 123T614 34Q794 34 881 142T969 462Q969 644 868 753T595
-862Q490 862 412 834T272 746L231 762Z" />
-<glyph unicode="6" horiz-adv-x="1121" d="M840 1476V1422Q534 1422 365 1241T183 733Q241 836 351 896T592 957Q784 957 898 826T1013 480Q1013 341 961 226T814 46T602 -20Q468 -20 360 42T191 219T128 481V660Q128 1048 311 1262T840 1476ZM585 903Q445 903
-329 823T182 621V493Q182 287 299 160T602 33Q757 33 858 162T959 480Q959 674 859 788T585 903Z" />
-<glyph unicode="7" horiz-adv-x="1121" d="M1007 1422L366 0H311L945 1402H77V1456H1007V1422Z" />
-<glyph unicode="8" horiz-adv-x="1121" d="M986 1086Q986 964 911 873T715 745Q858 707 943 607T1028 379Q1028 194 902 87T565 -20Q351 -20 226 87T100 379Q100 508 182 607T408 745Q288 781 215 872T141 1086Q141 1266 256 1371T561 1476Q751 1476 868 1369T986
-1086ZM973 374Q973 524 858 621T563 718Q382 718 268 622T154 374Q154 220 265 127T565 34Q749 34 861 127T973 374ZM932 1091Q932 1233 825 1327T561 1422Q400 1422 298 1331T195 1091Q195 949 297 861T563 772Q725 772 828 861T932 1091Z" />
-<glyph unicode="9" horiz-adv-x="1121" d="M939 724Q886 609 775 539T523 468Q403 468 307 532T157 710T103 958Q103 1101 158 1220T312 1408T531 1476Q756 1476 874 1330T993 907V740Q993 371 829 178T346 -20H298L300 34H343Q635 37 787 212T939 724ZM523 522Q671
-522 785 609T939 840V902Q939 1155 835 1288T535 1422Q428 1422 341 1359T206 1188T157 958Q157 839 204 738T334 579T523 522Z" />
-<glyph unicode=":" horiz-adv-x="364" d="M376 49Q376 72 392 88T431 105T470 89T487 49T471 10T431 -6T392 10T376 49ZM125 1011Q125 1034 141 1050T180 1067T219 1051T236 1011T220 972T180 956T141 972T125 1011Z" />
-<glyph unicode=";" horiz-adv-x="364" d="M126 1011Q126 1034 142 1050T181 1067T220 1051T237 1011T221 972T181 956T142 972T126 1011ZM374 -255L337 -223Q418 -119 425 -8L426 159H480V13Q476 -146 374 -255Z" />
-<glyph unicode="&lt;" horiz-adv-x="1053" d="M155 666L919 321V262L82 641V691L919 1069V1011L155 666Z" />
-<glyph unicode="=" horiz-adv-x="1142" d="M981 843H147V897H981V843ZM981 436H147V490H981V436Z" />
-<glyph unicode="&gt;" horiz-adv-x="1053" d="M872 668L114 1013V1072L950 694V644L114 265V324L872 668Z" />
-<glyph unicode="?" horiz-adv-x="893" d="M395 400Q397 512 429 583T552 739T678 874T730 980T747 1112Q747 1257 670 1340T458 1423Q314 1423 232 1337T147 1116H93Q95 1278 198 1377T458 1476T708 1377T801 1110Q801 995 756 906T581 698Q449 595 449 400H395ZM371
-49Q371 72 387 88T426 105T465 89T482 49T466 10T426 -6T387 10T371 49Z" />
-<glyph unicode="@" horiz-adv-x="1902" d="M1770 523Q1765 369 1715 240T1584 46T1400 -20Q1300 -20 1238 41T1165 210Q1055 -20 832 -20Q696 -20 630 104T581 436Q605 687 726 837T1018 988Q1133 988 1216 922L1268 878L1219 293Q1208 170 1256 103T1403 35Q1537
-35 1619 164T1713 523Q1735 934 1553 1144T1000 1354Q776 1354 593 1242T305 930T187 478Q175 223 259 24T513 -287T913 -398Q1003 -398 1091 -377T1243 -318L1267 -364Q1203 -406 1102 -429T909 -453Q659 -453 479 -341T210 -17T132 478Q144 758 255 970T560 1296T1004
-1411Q1396 1411 1592 1182T1770 523ZM634 279Q645 163 696 99T830 34Q955 34 1036 111T1168 344L1211 851Q1142 933 1015 933T792 833T655 557Q621 405 634 279Z" />
-<glyph unicode="A" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489Z" />
-<glyph unicode="B" horiz-adv-x="1235" d="M200 0V1456H583Q818 1456 938 1361T1059 1083Q1059 951 992 864T803 753Q941 735 1033 634T1125 401Q1125 215 1005 108T669 0H200ZM254 719V54H675Q860 54 965 145T1071 399Q1071 537 969 626T696 719H254ZM254 773H603Q802
-773 903 849T1004 1087Q1004 1397 595 1402H254V773Z" />
-<glyph unicode="C" horiz-adv-x="1327" d="M1190 446Q1169 221 1035 101T671 -20Q516 -20 397 58T211 281T144 612V837Q144 1023 209 1169T394 1396T671 1476Q899 1476 1034 1356T1190 1012H1136Q1113 1213 996 1317T671 1422Q459 1422 329 1262T198 833V619Q198
-447 256 315T422 108T671 34Q880 34 997 137T1136 446H1190Z" />
-<glyph unicode="D" horiz-adv-x="1340" d="M200 0V1456H603Q772 1456 909 1376T1124 1152T1204 828V639Q1204 457 1128 311T914 83T608 0H200ZM254 1402V54H603Q756 54 881 128T1078 336T1150 633V820Q1150 983 1081 1116T887 1324T611 1402H254Z" />
-<glyph unicode="E" horiz-adv-x="1166" d="M984 722H254V54H1086V0H200V1456H1086V1402H254V776H984V722Z" />
-<glyph unicode="F" horiz-adv-x="1172" d="M1000 716H254V0H200V1456H1102V1402H254V772H1000V716Z" />
-<glyph unicode="G" horiz-adv-x="1406" d="M1226 156Q1171 80 1033 30T729 -20Q567 -20 440 59T242 282T168 608V858Q168 1037 237 1179T431 1398T712 1476Q929 1476 1065 1365T1224 1062H1170Q1143 1236 1025 1329T712 1422Q492 1422 357 1265T222 852V620Q222
-449 285 315T464 108T729 34Q875 34 1000 77T1172 181V605H727V660H1226V156Z" />
-<glyph unicode="H" horiz-adv-x="1438" d="M1238 0H1184V722H254V0H200V1456H254V776H1184V1456H1238V0Z" />
-<glyph unicode="I" horiz-adv-x="534" d="M294 0H240V1456H294V0Z" />
-<glyph unicode="J" horiz-adv-x="1125" d="M876 1456H930V442Q930 231 815 106T510 -20Q306 -20 198 89T90 401H144Q144 223 235 129T510 34Q670 34 771 141T876 432V1456Z" />
-<glyph unicode="K" horiz-adv-x="1300" d="M487 766L254 551V0H200V1456H254V614L494 849L1098 1456H1176L527 803L1226 0H1156L487 766Z" />
-<glyph unicode="L" horiz-adv-x="1057" d="M255 54H1002V0H200V1456H255V54Z" />
-<glyph unicode="M" horiz-adv-x="1756" d="M277 1456L876 79L1477 1456H1556V0H1502V1376L898 0H855L254 1369V0H200V1456H277Z" />
-<glyph unicode="N" horiz-adv-x="1449" d="M1249 0H1195L255 1364V0H200V1456H255L1195 95V1456H1249V0Z" />
-<glyph unicode="O" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103 1043 1262T681 1422Q456 1422 322
-1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839Z" />
-<glyph unicode="P" horiz-adv-x="1230" d="M254 615V0H200V1456H655Q878 1456 1001 1344T1125 1031Q1125 833 1005 725T662 615H254ZM254 669H655Q852 669 961 764T1071 1029Q1071 1205 962 1303T655 1402H254V669Z" />
-<glyph unicode="Q" horiz-adv-x="1364" d="M1231 619Q1231 415 1152 261T924 33L1191 -228L1152 -263L868 10Q778 -20 683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103
-1043 1262T681 1422Q456 1422 322 1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839Z" />
-<glyph unicode="R" horiz-adv-x="1340" d="M754 623H249V0H195V1456H659Q878 1456 1007 1343T1137 1036Q1137 887 1045 776T809 637L1198 14V0H1141L754 623ZM249 677H708Q876 677 979 779T1083 1036Q1083 1206 969 1304T655 1402H249V677Z" />
-<glyph unicode="S" horiz-adv-x="1211" d="M1072 349Q1072 442 1029 506T892 620T609 722T326 827T187 950T143 1120Q143 1279 277 1377T626 1476Q766 1476 877 1422T1050 1269T1111 1046H1057Q1057 1209 937 1315T626 1422Q434 1422 316 1337T197 1122Q197 991
-300 911T640 770T987 627Q1127 524 1127 351Q1127 241 1065 157T889 26T633 -20Q475 -20 349 32T160 182T96 411H150Q150 232 284 133T633 34Q824 34 948 121T1072 349Z" />
-<glyph unicode="T" horiz-adv-x="1224" d="M1169 1402H639V0H585V1402H55V1456H1169V1402Z" />
-<glyph unicode="U" horiz-adv-x="1365" d="M1180 1456V470Q1180 239 1046 110T683 -20T320 109T185 466V1456H239V472Q239 270 360 152T683 34T1005 152T1126 473V1456H1180Z" />
-<glyph unicode="V" horiz-adv-x="1223" d="M583 142L612 54L641 142L1130 1456H1189L645 0H579L35 1456H94L583 142Z" />
-<glyph unicode="W" horiz-adv-x="1855" d="M489 90L555 330L899 1456H959L1301 330L1366 90L1434 330L1734 1456H1793L1401 0H1340L979 1214L928 1368L879 1214L515 0H454L61 1456H121L423 330L489 90Z" />
-<glyph unicode="X" horiz-adv-x="1223" d="M611 785L1081 1456H1149L645 743L1168 0H1101L611 701L119 0H54L577 743L73 1456H141L611 785Z" />
-<glyph unicode="Y" horiz-adv-x="1223" d="M609 602L1119 1456H1185L636 553V0H582V553L33 1456H105L609 602Z" />
-<glyph unicode="Z" horiz-adv-x="1224" d="M168 54H1130V0H94V44L1023 1403H134V1456H1098V1418L168 54Z" />
-<glyph unicode="[" horiz-adv-x="439" d="M464 1610H235V-258H464V-312H181V1664H464V1610Z" />
-<glyph unicode="\" horiz-adv-x="774" d="M57 1456H115L723 -125H665L57 1456Z" />
-<glyph unicode="]" horiz-adv-x="439" d="M-8 1664H275V-312H-8V-258H220V1610H-8V1664Z" />
-<glyph unicode="^" horiz-adv-x="849" d="M416 1382L150 729H91L390 1456H442L741 729H680L416 1382Z" />
-<glyph unicode="_" horiz-adv-x="845" d="M845 -54H-1V0H845V-54Z" />
-<glyph unicode="`" horiz-adv-x="537" d="M403 1270H344L149 1536H215L403 1270Z" />
-<glyph unicode="a" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33Z" />
-<glyph unicode="b" horiz-adv-x="1121" d="M999 531Q999 278 890 129T593 -20Q471 -20 375 30T224 171V0H170V1536H224V885Q281 992 374 1047T591 1102Q781 1102 890 957T999 548V531ZM943 552Q943 785 851 916T592 1048Q456 1048 362 978T224 770V274Q267 159
-361 97T594 34Q761 34 852 167T943 552Z" />
-<glyph unicode="c" horiz-adv-x="1039" d="M539 34Q686 34 781 112T886 328H940Q932 171 819 76T539 -20Q336 -20 217 127T97 526V562Q97 808 216 955T537 1102Q709 1102 821 999T940 725H886Q879 871 784 959T537 1048Q356 1048 254 918T151 555V520Q151 293
-254 164T539 34Z" />
-<glyph unicode="d" horiz-adv-x="1121" d="M122 552Q122 811 231 956T530 1102Q652 1102 745 1047T897 883V1536H951V0H897V173Q842 81 746 31T528 -20Q340 -20 231 129T122 538V552ZM178 531Q178 301 269 168T527 34Q661 34 756 93T897 268V775Q804 1048 529
-1048Q363 1048 271 917T178 531Z" />
-<glyph unicode="e" horiz-adv-x="1032" d="M561 -20Q430 -20 321 50T149 244T87 517V562Q87 712 147 837T312 1032T541 1102Q722 1102 837 973T952 634V577H141V518Q141 386 196 274T349 97T561 33Q670 33 746 69T882 182L920 155Q799 -20 561 -20ZM541 1048Q383
-1048 273 931T144 631H898V644Q898 754 852 848T724 995T541 1048Z" />
-<glyph unicode="f" horiz-adv-x="645" d="M254 0V1027H66V1082H254V1240Q255 1390 329 1473T537 1557Q611 1557 665 1540L657 1488Q605 1503 538 1503Q431 1503 370 1434T308 1236V1082H594V1027H308V0H254Z" />
-<glyph unicode="g" horiz-adv-x="1123" d="M121 552Q121 811 230 956T529 1102Q650 1102 744 1047T895 884V1082H950V19Q950 -195 840 -315T541 -436Q432 -436 342 -389T187 -254L225 -218Q288 -298 363 -340T539 -383Q706 -383 799 -282T895 5V171Q839 79 744
-30T527 -20Q339 -20 230 129T121 538V552ZM176 531Q176 299 268 167T526 34Q663 34 759 97T895 276V767Q807 1048 528 1048Q361 1048 269 917T176 531Z" />
-<glyph unicode="h" horiz-adv-x="1121" d="M226 830Q279 956 382 1029T610 1102Q784 1102 868 1004T954 706V0H900V708Q899 882 829 965T607 1049Q467 1049 365 950T226 693V0H172V1536H226V830Z" />
-<glyph unicode="i" horiz-adv-x="422" d="M239 0H185V1082H239V0ZM157 1420Q157 1443 173 1459T212 1476T251 1460T268 1420T252 1381T212 1365T173 1381T157 1420Z" />
-<glyph unicode="j" horiz-adv-x="445" d="M240 1082V-129Q240 -279 165 -358T-45 -437Q-94 -437 -143 -417L-140 -365Q-92 -383 -45 -383Q67 -383 126 -317T186 -129V1082H240ZM163 1420Q163 1443 179 1459T218 1476T257 1460T274 1420T258 1381T218 1365T179
-1381T163 1420Z" />
-<glyph unicode="k" horiz-adv-x="969" d="M385 585L383 583L226 448V0H172V1536H226V507L353 627L845 1082H922L425 621L953 0H883L385 585Z" />
-<glyph unicode="l" horiz-adv-x="422" d="M239 0H185V1536H239V0Z" />
-<glyph unicode="m" horiz-adv-x="1836" d="M946 0H892V727Q891 890 821 969T596 1049Q418 1049 305 892Q238 798 216 684V0H161V1082H216V826Q271 958 373 1030T599 1102Q735 1102 821 1042T935 846Q983 963 1091 1032T1333 1102Q1508 1102 1593 1003T1680 706V0H1626V702Q1626
-880 1555 965T1330 1049Q1133 1046 1018 892Q952 803 946 720V0Z" />
-<glyph unicode="n" horiz-adv-x="1121" d="M226 830Q279 956 382 1029T610 1102Q784 1102 868 1004T954 706V0H900V708Q899 882 829 965T607 1049Q467 1049 365 950T226 693V0H172V1082H226V830Z" />
-<glyph unicode="o" horiz-adv-x="1127" d="M90 562Q90 717 149 840T317 1033T563 1102Q699 1102 807 1035T975 845T1037 568V520Q1037 364 978 241T811 49T565 -20T320 48T151 238T90 514V562ZM144 520Q144 385 197 273T346 97T565 34Q750 34 866 173T983 531V562Q983
-695 929 808T780 984T563 1048Q378 1048 261 907T144 552V520Z" />
-<glyph unicode="p" horiz-adv-x="1121" d="M999 531Q999 278 890 129T593 -20Q470 -20 374 30T224 168V-416H170V1082H224V889Q280 992 375 1047T591 1102Q781 1102 890 957T999 548V531ZM944 552Q944 785 852 916T592 1048Q456 1048 361 978T224 775V269Q266
-157 361 96T594 34Q760 34 852 166T944 552Z" />
-<glyph unicode="q" horiz-adv-x="1121" d="M122 552Q122 811 231 956T530 1102Q651 1102 746 1047T897 889V1082H951V-416H897V168Q839 77 744 29T528 -20Q340 -20 231 129T122 538V552ZM178 531Q178 301 269 168T527 34Q661 34 756 93T897 268V775Q850 910 755
-979T529 1048Q363 1048 271 917T178 531Z" />
-<glyph unicode="r" horiz-adv-x="685" d="M649 1043L579 1049Q441 1049 348 960T226 709V0H172V1082H226V857Q270 970 358 1036T579 1102Q626 1102 655 1091L649 1043Z" />
-<glyph unicode="s" horiz-adv-x="1019" d="M839 265Q839 462 503 533Q301 576 222 643T143 829Q143 948 243 1025T505 1102Q680 1102 786 1019T892 793H837Q837 902 745 975T505 1048Q363 1048 280 986T197 831Q197 758 228 717T329 642T533 577T745 504T858 405T893
-264Q893 136 788 58T513 -20Q331 -20 220 62T108 275H162Q170 161 262 98T513 34Q658 34 748 101T839 265Z" />
-<glyph unicode="t" horiz-adv-x="648" d="M293 1374V1082H539V1027H293V259Q293 144 330 89T456 34Q500 34 563 43L572 -8Q539 -20 459 -20Q341 -20 290 45T238 252V1027H38V1082H238V1374H293Z" />
-<glyph unicode="u" horiz-adv-x="1121" d="M897 0V175Q849 85 757 33T524 -20Q347 -20 259 83T168 385V1082H222V383Q224 211 300 123T522 34Q677 34 774 107T897 321V1082H952V0H897Z" />
-<glyph unicode="v" horiz-adv-x="978" d="M490 86L879 1082H937L516 0H463L43 1082H101L490 86Z" />
-<glyph unicode="w" horiz-adv-x="1550" d="M366 313L425 80L742 1082H797L1112 80L1173 313L1393 1082H1456L1141 0H1087L820 813L769 1007L714 813L451 0H397L83 1082H145L366 313Z" />
-<glyph unicode="x" horiz-adv-x="978" d="M489 602L834 1082H902L522 555L922 0H855L488 508L122 0H55L455 555L75 1082H143L489 602Z" />
-<glyph unicode="y" horiz-adv-x="978" d="M503 84L510 104L884 1082H944L460 -188L436 -248Q358 -437 178 -437Q120 -437 98 -426L97 -375Q129 -384 170 -384Q255 -384 311 -335T408 -173L474 6L43 1082H102L503 84Z" />
-<glyph unicode="z" horiz-adv-x="978" d="M160 54H930V0H87V44L798 1027H118V1082H871V1034L160 54Z" />
-<glyph unicode="{" horiz-adv-x="660" d="M642 -441Q482 -391 403 -278T323 20V261Q323 543 73 543V609Q323 609 323 889V1136Q324 1321 403 1434T642 1597L657 1552Q377 1461 377 1125V897Q377 625 166 576Q377 523 377 255V26Q377 -299 662 -395L642 -441Z" />
-<glyph unicode="|" horiz-adv-x="406" d="M235 -270H181V1456H235V-270Z" />
-<glyph unicode="}" horiz-adv-x="660" d="M0 -395Q284 -298 284 22V255Q284 523 495 576Q284 625 284 897V1124Q284 1462 5 1552L19 1597Q179 1547 257 1435T338 1141V892Q338 609 588 609V543Q338 543 338 258V21Q338 -165 260 -277T19 -441L0 -395Z" />
-<glyph unicode="~" horiz-adv-x="1412" d="M1246 752Q1246 614 1173 529T977 443Q906 443 845 471T687 586T539 696T428 720Q328 720 272 655T215 462H160Q160 605 231 689T428 774Q500 774 563 745T723 629T870 519T977 496Q1078 496 1134 563T1190 753L1246 752Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="490" />
-<glyph unicode="&#xa1;" horiz-adv-x="406" d="M179 696H233V-359H179V696ZM253 1048Q253 1025 237 1009T198 992T159 1008T142 1048T158 1087T198 1103T237 1087T253 1048Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1110" d="M576 34Q723 34 818 112T923 328H977Q969 178 864 84T604 -19V-245H549V-19Q358 -9 246 136T134 526V562Q134 802 246 946T549 1101V1318H604V1101Q767 1090 868 989T977 725H923Q916 871 821 959T574 1048Q393
-1048 291 918T188 555V520Q188 293 291 164T576 34Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1150" d="M360 667L370 336Q374 142 303 54H1060L1061 0H99V54H219Q267 68 292 148T316 336L306 667H95V721H304L295 1039Q295 1243 394 1359T661 1476Q834 1476 934 1372T1035 1089H981Q981 1248 896 1335T661 1422Q514
-1422 432 1322T349 1039L358 721H728V667H360Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1502" d="M1159 156Q1078 73 972 27T745 -20T518 26T330 154L154 -26L114 13L293 195Q149 371 149 608Q149 854 303 1032L114 1225L154 1264L342 1072Q513 1234 745 1234Q863 1234 965 1191T1148 1070L1339 1265L1380 1225L1187
-1029Q1339 851 1339 608Q1339 374 1198 199L1380 13L1339 -27L1159 156ZM204 608Q204 454 277 320T476 110T745 33Q888 33 1013 109T1211 320T1285 608Q1285 761 1213 893T1015 1103T745 1181T475 1104T277 894T204 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1038" d="M938 1456H1000L568 676H935V621H543V381H935V326H543V0H489V326H99V381H489V621H99V676H464L33 1456H95L487 738L512 687H521L547 738L938 1456Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="398" d="M172 -270V482H226V-270H172ZM226 698H172V1456H226V698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1223" d="M1094 431Q1094 326 1012 255T790 164Q932 110 991 37T1050 -149Q1050 -309 929 -402T600 -495Q374 -495 245 -383T115 -64L169 -62Q169 -242 285 -341T600 -441Q783 -441 889 -362T995 -151Q995 -63 959 -10T840
-85T607 166Q336 230 229 319T121 551Q121 660 198 731T407 822Q278 873 222 947T166 1129Q166 1286 288 1381T618 1476Q833 1476 952 1364T1072 1045H1018Q1018 1212 909 1317T618 1422Q434 1422 327 1345T220 1132Q220 1041 256 987T374 891T616 804Q824 752 914
-705T1049 593T1094 431ZM590 766Q531 779 482 796Q339 791 257 726T175 553Q175 460 214 406T347 309T693 196Q850 198 945 262T1040 428Q1040 513 999 569T865 670T590 766Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="906" d="M174 1421Q174 1444 190 1460T229 1477T268 1461T285 1421T269 1382T229 1366T190 1382T174 1421ZM619 1421Q619 1444 635 1460T674 1477T713 1461T730 1421T714 1382T674 1366T635 1382T619 1421Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1666" d="M1124 616Q1124 464 1046 383T826 302Q682 302 594 409T506 693V768Q506 941 595 1048T826 1155Q969 1155 1047 1073T1125 842H1073Q1073 973 1009 1037T826 1102T634 1010T561 763V689Q561 540 633 449T826 357Q1072
-357 1072 616H1124ZM179 729Q179 541 267 380T507 126T833 34Q1009 34 1161 128T1400 382T1487 729Q1487 916 1400 1075T1161 1328T833 1421Q660 1421 508 1330T268 1079T179 729ZM123 729Q123 931 216 1104T475 1376T833 1476T1190 1377T1449 1104T1543 729Q1543
-530 1452 358T1196 83T833 -21T471 82T214 358T123 729Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="898" d="M680 705Q662 759 658 823Q619 763 554 727T417 691Q296 691 232 748T168 900Q168 1009 251 1070T487 1132H657V1201Q657 1305 608 1363T458 1422Q349 1422 285 1378T221 1243H167Q167 1345 248 1410T458 1476Q574
-1476 643 1404T712 1200V884Q712 792 738 705H680ZM418 746Q488 746 562 793T657 899V1078H490Q222 1078 222 904Q222 746 418 746Z" />
-<glyph unicode="&#xab;" horiz-adv-x="905" d="M216 781L510 402H440L145 772V791L440 1161H510L216 781ZM503 525L797 146H727L432 516V535L727 905H797L503 525Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1101" d="M915 396H861V700H122V753H915V396Z" />
-<glyph unicode="&#xad;" horiz-adv-x="607" d="M531 639H61V693H531V639Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1674" d="M115 729Q115 931 208 1104T467 1376T825 1476T1182 1377T1441 1104T1535 729Q1535 530 1444 358T1188 83T825 -21T463 82T206 358T115 729ZM170 729Q170 543 257 383T496 128T825 34Q1001 34 1153 128T1392 382T1479
-729Q1479 916 1392 1075T1153 1328T825 1421Q649 1421 497 1328T257 1076T170 729ZM648 678V326H593V1156H832Q1121 1156 1121 916Q1121 772 968 710Q1100 671 1100 502Q1100 391 1117 342V326H1058Q1044 362 1044 502Q1044 594 1006 635T873 678H648ZM648 734H853Q949
-734 1007 784T1066 917Q1066 1015 1015 1057T846 1101H648V734Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="811" d="M699 1383H132V1436H699V1383Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="783" d="M156 1236Q156 1333 225 1404T392 1476Q488 1476 556 1405T624 1236Q624 1138 556 1069T392 999Q294 999 225 1068T156 1236ZM211 1236Q211 1159 262 1107T392 1055Q468 1055 518 1105T568 1236Q568 1318 518 1369T392
-1421Q314 1421 263 1368T211 1236Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1077" d="M569 805H988V751H569V289H515V751H72V805H515V1267H569V805ZM957 -1H122V53H957V-1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="728" d="M651 664H108V708L398 1003Q477 1080 514 1138T551 1247Q551 1324 502 1369T356 1415Q254 1415 197 1363T140 1226H86Q86 1329 161 1396T356 1464Q472 1464 538 1405T605 1248Q605 1154 492 1031L426 961L175 713H651V664Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="728" d="M270 1090H345Q446 1091 505 1135T564 1249Q564 1326 511 1370T362 1415Q271 1415 211 1369T150 1246H97Q97 1342 172 1403T362 1464Q481 1464 549 1406T618 1246Q618 1189 578 1140T463 1067Q549 1047 593 997T637
-875Q637 775 563 714T367 653Q243 653 162 716T80 881H134Q134 803 199 752T367 701T526 747T583 874Q583 1041 330 1041H270V1090Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="511" d="M315 1536H381L186 1270H126L315 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1121" d="M223 1082V421Q226 232 302 133T529 34Q705 34 794 124T899 414V1082H953V0H902L899 203Q803 -20 538 -20Q424 -20 345 30T223 171V-416H171V1082H223Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="946" d="M716 0V520H589Q439 520 328 578T158 742T99 988Q99 1201 232 1328T593 1456H770V0H716Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="472" d="M179 706Q179 729 195 745T234 762T273 746T290 706T274 667T234 651T195 667T179 706Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="490" d="M207 0L196 -76Q373 -92 373 -245Q373 -330 297 -382T88 -435L81 -386Q182 -386 250 -347T318 -245Q318 -189 280 -161T129 -121L154 0H207Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="728" d="M433 664H379V1386L131 1305V1358L424 1455H433V664Z" />
-<glyph unicode="&#xba;" horiz-adv-x="914" d="M148 1141Q148 1291 231 1383T452 1476T673 1384T757 1136V1024Q757 873 674 782T454 690Q317 690 233 781T148 1029V1141ZM202 1024Q202 893 268 819T454 744Q570 744 637 820T704 1028V1141Q704 1269 636 1345T452
-1422Q338 1422 270 1346T202 1135V1024Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="897" d="M198 940L492 560V541L198 171H128L421 550L128 940H198ZM488 940L782 560V541L488 171H418L711 550L418 940H488Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1467" d="M447 664H393V1386L145 1305V1358L438 1455H447V664ZM386 139L341 170L1052 1308L1097 1277L386 139ZM1225 253H1372V204H1225V0H1172V204H749L748 236L1165 789H1225V253ZM818 253H1172V727L1128 656L818 253Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1508" d="M343 139L298 170L1009 1308L1054 1277L343 139ZM424 664H370V1386L122 1305V1358L415 1455H424V664ZM1392 0H849V44L1139 339Q1218 416 1255 474T1292 583Q1292 660 1243 705T1097 751Q995 751 938 699T881 562H827Q827
-665 902 732T1097 800Q1213 800 1279 741T1346 584Q1346 490 1233 367L1167 297L916 49H1392V0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1586" d="M548 139L503 170L1214 1308L1259 1277L548 139ZM1365 253H1512V204H1365V0H1312V204H889L888 236L1305 789H1365V253ZM958 253H1312V727L1268 656L958 253ZM314 1090H389Q490 1091 549 1135T608 1249Q608 1326
-555 1370T406 1415Q315 1415 255 1369T194 1246H141Q141 1342 216 1403T406 1464Q525 1464 593 1406T662 1246Q662 1189 622 1140T507 1067Q593 1047 637 997T681 875Q681 775 607 714T411 653Q287 653 206 716T124 881H178Q178 803 243 752T411 701T570 747T627
-874Q627 1041 374 1041H314V1090Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="912" d="M514 695Q512 593 503 557T469 487T389 403L311 327Q232 248 197 166T162 -17Q162 -166 241 -247T461 -328Q599 -328 678 -246T762 -21H816Q814 -188 719 -284T461 -381Q296 -381 202 -281T108 -15Q108 106 160 207T361
-445Q412 485 434 526T459 626L460 695H514ZM538 1046Q538 1023 522 1007T483 990T444 1006T427 1046T443 1085T483 1101T522 1085T538 1046Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489ZM655 1589H596L401 1855H467L655 1589Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489ZM761 1855H827L632 1589H572L761 1855Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489ZM866 1593V1583H798L611 1779L426 1583H362V1597L592 1836H632L866 1593Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489ZM940 1806Q940 1724 890 1672T764 1620Q683 1620 611 1682T477 1745Q421 1745 389 1711T356 1620H301Q301 1700 351 1749T477
-1799Q555 1799 630 1737T764 1675Q818 1675 851 1711T885 1806H940Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489ZM336 1740Q336 1763 352 1779T391 1796T430 1780T447 1740T431 1701T391 1685T352 1701T336 1740ZM781 1740Q781 1763 797
-1779T836 1796T875 1780T892 1740T876 1701T836 1685T797 1701T781 1740Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1223" d="M967 435H254L92 0H33L578 1456H644L1189 0H1130L967 435ZM274 489H947L611 1391L274 489ZM614 1875Q686 1875 735 1824T785 1701T736 1580T614 1531Q545 1531 494 1578T443 1701T493 1825T614 1875ZM497 1701Q497
-1649 530 1617T614 1585T698 1617T731 1701Q731 1755 698 1788T614 1821T530 1788T497 1701Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1816" d="M1768 0H1016L998 425H371L115 0H50L931 1456H1707V1402H1011L1037 786H1625V732H1039L1067 54H1768V0ZM403 478H996L957 1398L403 478Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1327" d="M1190 446Q1169 221 1035 101T671 -20Q516 -20 397 58T211 281T144 612V837Q144 1023 209 1169T394 1396T671 1476Q899 1476 1034 1356T1190 1012H1136Q1113 1213 996 1317T671 1422Q459 1422 329 1262T198 833V619Q198
-447 256 315T422 108T671 34Q880 34 997 137T1136 446H1190ZM706 -9L695 -85Q872 -101 872 -254Q872 -339 796 -391T587 -444L580 -395Q681 -395 749 -356T817 -254Q817 -198 779 -170T628 -130L653 -9H706Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1166" d="M984 722H254V54H1086V0H200V1456H1086V1402H254V776H984V722ZM662 1589H603L408 1855H474L662 1589Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1166" d="M984 722H254V54H1086V0H200V1456H1086V1402H254V776H984V722ZM768 1855H834L639 1589H579L768 1855Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1166" d="M984 722H254V54H1086V0H200V1456H1086V1402H254V776H984V722ZM873 1593V1583H805L618 1779L433 1583H369V1597L599 1836H639L873 1593Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1166" d="M984 722H254V54H1086V0H200V1456H1086V1402H254V776H984V722ZM343 1740Q343 1763 359 1779T398 1796T437 1780T454 1740T438 1701T398 1685T359 1701T343 1740ZM788 1740Q788 1763 804 1779T843 1796T882 1780T899
-1740T883 1701T843 1685T804 1701T788 1740Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="534" d="M294 0H240V1456H294V0ZM312 1589H253L58 1855H124L312 1589Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="534" d="M294 0H240V1456H294V0ZM417 1855H483L288 1589H228L417 1855Z" />
-<glyph unicode="&#xce;" horiz-adv-x="534" d="M294 0H240V1456H294V0ZM523 1593V1583H455L268 1779L83 1583H19V1597L249 1836H289L523 1593Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="534" d="M294 0H240V1456H294V0ZM-7 1740Q-7 1763 9 1779T48 1796T87 1780T104 1740T88 1701T48 1685T9 1701T-7 1740ZM438 1740Q438 1763 454 1779T493 1796T532 1780T549 1740T533 1701T493 1685T454 1701T438 1740Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1370" d="M230 0V713H60V767H230V1456H633Q802 1456 939 1376T1154 1152T1234 828V639Q1234 457 1158 311T944 83T638 0H230ZM647 713H284V54H623Q870 54 1025 220T1180 647V820Q1180 983 1111 1116T917 1324T641 1402H284V767H647V713Z"
-/>
-<glyph unicode="&#xd1;" horiz-adv-x="1449" d="M1249 0H1195L255 1364V0H200V1456H255L1195 95V1456H1249V0ZM1054 1806Q1054 1724 1004 1672T878 1620Q797 1620 725 1682T591 1745Q535 1745 503 1711T470 1620H415Q415 1700 465 1749T591 1799Q669 1799 744
-1737T878 1675Q932 1675 965 1711T999 1806H1054Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103 1043 1262T681 1422Q456 1422
-322 1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839ZM719 1610H660L465 1876H531L719 1610Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103 1043 1262T681 1422Q456 1422
-322 1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839ZM825 1876H891L696 1610H636L825 1876Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103 1043 1262T681 1422Q456 1422
-322 1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839ZM930 1614V1604H862L675 1800L490 1604H426V1618L656 1857H696L930 1614Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103 1043 1262T681 1422Q456 1422
-322 1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839ZM1004 1827Q1004 1745 954 1693T828 1641Q747 1641 675 1703T541 1766Q485 1766 453 1732T420 1641H365Q365 1721 415 1770T541 1820Q619 1820 694 1758T828 1696Q882 1696
-915 1732T949 1827H1004Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q437 -20 285 155T133 627V837Q133 1025 200 1171T393 1396T681 1476Q844 1476 969 1397T1163 1171T1231 837V619ZM1177 839Q1177 1103 1043 1262T681 1422Q456 1422
-322 1264T188 832V619Q188 445 248 312T421 106T683 34Q911 34 1044 193T1177 627V839ZM400 1761Q400 1784 416 1800T455 1817T494 1801T511 1761T495 1722T455 1706T416 1722T400 1761ZM845 1761Q845 1784 861 1800T900 1817T939 1801T956 1761T940 1722T900 1706T861
-1722T845 1761Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1052" d="M98 36L482 429L125 793L164 832L520 468L877 832L916 793L559 429L944 36L905 -1L521 390L137 -1L98 36Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1364" d="M1231 619Q1231 430 1164 285T971 60T683 -20Q488 -20 349 92L243 -75H177L307 130Q133 306 133 629V837Q133 1025 200 1171T393 1396T681 1476Q912 1476 1063 1319L1174 1495H1240L1100 1275Q1230 1103 1231 839V619ZM188
-619Q188 335 337 176L1033 1273Q901 1422 681 1422Q456 1422 322 1264T188 832V619ZM1177 839Q1177 1076 1070 1227L378 137Q502 34 683 34Q911 34 1044 193T1177 627V839Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1365" d="M1180 1456V470Q1180 239 1046 110T683 -20T320 109T185 466V1456H239V472Q239 270 360 152T683 34T1005 152T1126 473V1456H1180ZM740 1589H681L486 1855H552L740 1589Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1365" d="M1180 1456V470Q1180 239 1046 110T683 -20T320 109T185 466V1456H239V472Q239 270 360 152T683 34T1005 152T1126 473V1456H1180ZM846 1855H912L717 1589H657L846 1855Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1365" d="M1180 1456V470Q1180 239 1046 110T683 -20T320 109T185 466V1456H239V472Q239 270 360 152T683 34T1005 152T1126 473V1456H1180ZM951 1593V1583H883L696 1779L511 1583H447V1597L677 1836H717L951 1593Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1365" d="M1180 1456V470Q1180 239 1046 110T683 -20T320 109T185 466V1456H239V472Q239 270 360 152T683 34T1005 152T1126 473V1456H1180ZM421 1740Q421 1763 437 1779T476 1796T515 1780T532 1740T516 1701T476 1685T437
-1701T421 1740ZM866 1740Q866 1763 882 1779T921 1796T960 1780T977 1740T961 1701T921 1685T882 1701T866 1740Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1223" d="M609 602L1119 1456H1185L636 553V0H582V553L33 1456H105L609 602ZM757 1844H823L628 1578H568L757 1844Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1219" d="M254 1456V1143H631Q837 1141 956 1030T1075 738Q1075 558 958 448T639 334H254V0H200V1456H254ZM254 1089V388H625Q806 388 913 486T1021 736Q1021 889 918 987T640 1089H254Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1183" d="M218 0H164V1143Q164 1334 248 1434T493 1535Q619 1535 711 1456T804 1257Q804 1157 745 1050T685 829Q685 770 727 717T871 589T1017 445T1062 297Q1062 207 1010 135T871 21T695 -21Q604 -21 513 6T383 68L408
-117Q452 82 533 57T687 32Q822 32 915 111T1008 306Q1008 371 967 428T822 561T675 698T631 831Q631 942 687 1055T744 1259Q744 1349 671 1415T503 1481Q222 1481 218 1153V0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33ZM620 1270H561L366 1536H432L620 1270Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33ZM726 1536H792L597 1270H537L726 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33ZM831 1274V1264H763L576 1460L391 1264H327V1278L557 1517H597L831 1274Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33ZM905 1486Q905 1404 855 1352T729 1300Q648 1300 576 1362T442 1425Q386 1425 354 1391T321 1300H266Q266 1380 316 1429T442 1479Q520
-1479 595 1417T729 1355Q783 1355 816 1391T850 1486H905Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33ZM301 1421Q301 1444 317 1460T356 1477T395 1461T412 1421T396 1382T356 1366T317 1382T301 1421ZM746 1421Q746 1444 762 1460T801
-1477T840 1461T857 1421T841 1382T801 1366T762 1382T746 1421Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1081" d="M871 0Q851 69 851 198Q787 94 676 37T425 -20Q275 -20 184 61T92 274Q92 423 226 512T584 604H851V762Q851 898 766 973T521 1048Q373 1048 274 972T175 784L121 786Q121 918 237 1010T521 1102Q696 1102 799 1015T905
-768V251Q905 73 933 9V0H871ZM425 33Q577 33 686 101T851 292V549H601Q369 549 246 457Q146 382 146 270Q146 171 225 102T425 33ZM579 1556Q651 1556 700 1505T750 1382T701 1261T579 1212Q510 1212 459 1259T408 1382T458 1506T579 1556ZM462 1382Q462 1330 495
-1298T579 1266T663 1298T696 1382Q696 1436 663 1469T579 1502T495 1469T462 1382Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1735" d="M1268 -20Q1121 -20 1021 47T868 230V218H869Q821 111 707 46T448 -20Q280 -20 187 62T93 284Q93 442 203 535T516 630H813V720Q813 876 741 962T521 1048Q363 1048 269 972T174 771L121 778Q121 923 232 1012T521
-1102Q662 1102 749 1028T860 814Q916 951 1019 1026T1253 1102Q1439 1102 1548 986T1657 656V577H870V500Q870 282 974 158T1268 34Q1472 34 1600 164L1630 122Q1551 43 1465 12T1268 -20ZM447 32Q528 32 606 60T741 136T813 225V575H512Q345 572 247 492T148 280Q148
-164 224 98T447 32ZM1253 1048Q1100 1048 996 935T873 632H1603V664Q1603 838 1510 943T1253 1048Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1039" d="M539 34Q686 34 781 112T886 328H940Q932 171 819 76T539 -20Q336 -20 217 127T97 526V562Q97 808 216 955T537 1102Q709 1102 821 999T940 725H886Q879 871 784 959T537 1048Q356 1048 254 918T151 555V520Q151
-293 254 164T539 34ZM575 -9L564 -85Q741 -101 741 -254Q741 -339 665 -391T456 -444L449 -395Q550 -395 618 -356T686 -254Q686 -198 648 -170T497 -130L522 -9H575Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1032" d="M561 -20Q430 -20 321 50T149 244T87 517V562Q87 712 147 837T312 1032T541 1102Q722 1102 837 973T952 634V577H141V518Q141 386 196 274T349 97T561 33Q670 33 746 69T882 182L920 155Q799 -20 561 -20ZM541 1048Q383
-1048 273 931T144 631H898V644Q898 754 852 848T724 995T541 1048ZM610 1269H551L356 1535H422L610 1269Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1032" d="M561 -20Q430 -20 321 50T149 244T87 517V562Q87 712 147 837T312 1032T541 1102Q722 1102 837 973T952 634V577H141V518Q141 386 196 274T349 97T561 33Q670 33 746 69T882 182L920 155Q799 -20 561 -20ZM541 1048Q383
-1048 273 931T144 631H898V644Q898 754 852 848T724 995T541 1048ZM716 1535H782L587 1269H527L716 1535Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1032" d="M561 -20Q430 -20 321 50T149 244T87 517V562Q87 712 147 837T312 1032T541 1102Q722 1102 837 973T952 634V577H141V518Q141 386 196 274T349 97T561 33Q670 33 746 69T882 182L920 155Q799 -20 561 -20ZM541 1048Q383
-1048 273 931T144 631H898V644Q898 754 852 848T724 995T541 1048ZM821 1273V1263H753L566 1459L381 1263H317V1277L547 1516H587L821 1273Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1032" d="M561 -20Q430 -20 321 50T149 244T87 517V562Q87 712 147 837T312 1032T541 1102Q722 1102 837 973T952 634V577H141V518Q141 386 196 274T349 97T561 33Q670 33 746 69T882 182L920 155Q799 -20 561 -20ZM541 1048Q383
-1048 273 931T144 631H898V644Q898 754 852 848T724 995T541 1048ZM291 1676Q291 1699 307 1715T346 1732T385 1716T402 1676T386 1637T346 1621T307 1637T291 1676ZM736 1676Q736 1699 752 1715T791 1732T830 1716T847 1676T831 1637T791 1621T752 1637T736 1676Z"
-/>
-<glyph unicode="&#xec;" horiz-adv-x="406" d="M235 0H181V1082H235V0ZM253 1247H194L-1 1513H65L253 1247Z" />
-<glyph unicode="&#xed;" horiz-adv-x="406" d="M235 0H181V1082H235V0ZM358 1769H424L229 1503H169L358 1769Z" />
-<glyph unicode="&#xee;" horiz-adv-x="406" d="M235 0H181V1082H235V0ZM464 1251V1241H396L209 1437L24 1241H-40V1255L190 1494H230L464 1251Z" />
-<glyph unicode="&#xef;" horiz-adv-x="406" d="M235 0H181V1082H235V0ZM-66 1398Q-66 1421 -50 1437T-11 1454T28 1438T45 1398T29 1359T-11 1343T-50 1359T-66 1398ZM379 1398Q379 1421 395 1437T434 1454T473 1438T490 1398T474 1359T434 1343T395 1359T379 1398Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1183" d="M802 1308Q923 1183 982 1014T1041 615V535Q1041 376 990 250T843 52T629 -20Q500 -20 396 43T232 218T173 465Q173 696 286 824T601 953Q714 953 815 909T977 780Q957 948 899 1069T752 1280L517 1149L489 1197L709
-1320Q571 1441 338 1527L358 1577Q610 1485 760 1348L962 1461L991 1413L802 1308ZM987 617L986 672Q940 777 837 836T601 895Q424 895 326 782T228 465Q228 350 279 250T423 94T633 38Q789 38 886 171T987 520V617Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1121" d="M226 830Q279 956 382 1029T610 1102Q784 1102 868 1004T954 706V0H900V708Q899 882 829 965T607 1049Q467 1049 365 950T226 693V0H172V1082H226V830ZM906 1484Q906 1402 856 1350T730 1298Q649 1298 577 1360T443
-1423Q387 1423 355 1389T322 1298H267Q267 1378 317 1427T443 1477Q521 1477 596 1415T730 1353Q784 1353 817 1389T851 1484H906Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1127" d="M90 562Q90 717 149 840T317 1033T563 1102Q699 1102 807 1035T975 845T1037 568V520Q1037 364 978 241T811 49T565 -20T320 48T151 238T90 514V562ZM144 520Q144 385 197 273T346 97T565 34Q750 34 866 173T983
-531V562Q983 695 929 808T780 984T563 1048Q378 1048 261 907T144 552V520ZM610 1268H551L356 1534H422L610 1268Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1127" d="M90 562Q90 717 149 840T317 1033T563 1102Q699 1102 807 1035T975 845T1037 568V520Q1037 364 978 241T811 49T565 -20T320 48T151 238T90 514V562ZM144 520Q144 385 197 273T346 97T565 34Q750 34 866 173T983
-531V562Q983 695 929 808T780 984T563 1048Q378 1048 261 907T144 552V520ZM716 1534H782L587 1268H527L716 1534Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1127" d="M90 562Q90 717 149 840T317 1033T563 1102Q699 1102 807 1035T975 845T1037 568V520Q1037 364 978 241T811 49T565 -20T320 48T151 238T90 514V562ZM144 520Q144 385 197 273T346 97T565 34Q750 34 866 173T983
-531V562Q983 695 929 808T780 984T563 1048Q378 1048 261 907T144 552V520ZM821 1272V1262H753L566 1458L381 1262H317V1276L547 1515H587L821 1272Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1127" d="M90 562Q90 717 149 840T317 1033T563 1102Q699 1102 807 1035T975 845T1037 568V520Q1037 364 978 241T811 49T565 -20T320 48T151 238T90 514V562ZM144 520Q144 385 197 273T346 97T565 34Q750 34 866 173T983
-531V562Q983 695 929 808T780 984T563 1048Q378 1048 261 907T144 552V520ZM895 1484Q895 1402 845 1350T719 1298Q638 1298 566 1360T432 1423Q376 1423 344 1389T311 1298H256Q256 1378 306 1427T432 1477Q510 1477 585 1415T719 1353Q773 1353 806 1389T840
-1484H895Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1127" d="M90 562Q90 717 149 840T317 1033T563 1102Q699 1102 807 1035T975 845T1037 568V520Q1037 364 978 241T811 49T565 -20T320 48T151 238T90 514V562ZM144 520Q144 385 197 273T346 97T565 34Q750 34 866 173T983
-531V562Q983 695 929 808T780 984T563 1048Q378 1048 261 907T144 552V520ZM291 1675Q291 1698 307 1714T346 1731T385 1715T402 1675T386 1636T346 1620T307 1636T291 1675ZM736 1675Q736 1698 752 1714T791 1731T830 1715T847 1675T831 1636T791 1620T752 1636T736
-1675Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1159" d="M1071 686H73V738H1071V686ZM529 1079Q529 1102 545 1118T584 1135T623 1119T640 1079T624 1040T584 1024T545 1040T529 1079ZM529 301Q529 324 545 340T584 357T623 341T640 301T624 262T584 246T545 262T529 301Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1121" d="M87 562Q87 717 146 840T314 1033T560 1102Q680 1102 784 1047L868 1219H931L832 1016Q927 946 980 829T1034 562V520Q1034 364 975 241T808 49T562 -20Q450 -20 352 28L268 -145H205L303 56Q200 125 144 247T87
-522V562ZM141 520Q141 388 190 280T327 107L759 995Q671 1048 560 1048Q375 1048 258 907T141 552V520ZM980 562Q980 684 935 790T806 963L376 77Q459 34 562 34Q747 34 863 173T980 531V562Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1121" d="M897 0V175Q849 85 757 33T524 -20Q347 -20 259 83T168 385V1082H222V383Q224 211 300 123T522 34Q677 34 774 107T897 321V1082H952V0H897ZM623 1270H564L369 1536H435L623 1270Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1121" d="M897 0V175Q849 85 757 33T524 -20Q347 -20 259 83T168 385V1082H222V383Q224 211 300 123T522 34Q677 34 774 107T897 321V1082H952V0H897ZM729 1536H795L600 1270H540L729 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1121" d="M897 0V175Q849 85 757 33T524 -20Q347 -20 259 83T168 385V1082H222V383Q224 211 300 123T522 34Q677 34 774 107T897 321V1082H952V0H897ZM834 1274V1264H766L579 1460L394 1264H330V1278L560 1517H600L834 1274Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1121" d="M897 0V175Q849 85 757 33T524 -20Q347 -20 259 83T168 385V1082H222V383Q224 211 300 123T522 34Q677 34 774 107T897 321V1082H952V0H897ZM304 1421Q304 1444 320 1460T359 1477T398 1461T415 1421T399 1382T359
-1366T320 1382T304 1421ZM749 1421Q749 1444 765 1460T804 1477T843 1461T860 1421T844 1382T804 1366T765 1382T749 1421Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="978" d="M503 84L510 104L884 1082H944L460 -188L436 -248Q358 -437 178 -437Q120 -437 98 -426L97 -375Q129 -384 170 -384Q255 -384 311 -335T408 -173L474 6L43 1082H102L503 84ZM668 1536H734L539 1270H479L668 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1121" d="M999 531Q999 278 890 129T593 -20Q470 -20 374 30T224 168V-416H170V1536H224V889Q280 992 375 1047T591 1102Q781 1102 890 957T999 548V531ZM944 552Q944 785 852 916T592 1048Q456 1048 361 978T224 775V269Q266
-157 361 96T594 34Q760 34 852 166T944 552Z" />
-<glyph unicode="&#xff;" horiz-adv-x="978" d="M503 84L510 104L884 1082H944L460 -188L436 -248Q358 -437 178 -437Q120 -437 98 -426L97 -375Q129 -384 170 -384Q255 -384 311 -335T408 -173L474 6L43 1082H102L503 84ZM243 1421Q243 1444 259 1460T298 1477T337
-1461T354 1421T338 1382T298 1366T259 1382T243 1421ZM688 1421Q688 1444 704 1460T743 1477T782 1461T799 1421T783 1382T743 1366T704 1382T688 1421Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1324" d="M1415 721H413V775H1415V721Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1561" d="M1446 721H110V775H1446V721Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="320" d="M207 1554L244 1522Q158 1414 155 1288V1168H101V1286Q105 1445 207 1554Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="320" d="M114 1151L77 1183Q158 1287 165 1398L166 1536H220V1419Q216 1260 114 1151Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="300" d="M84 -182L47 -150Q128 -46 135 65L136 228H190V86Q186 -73 84 -182Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="500" d="M458 1554L495 1522Q409 1414 406 1288V1168H352V1286Q356 1445 458 1554ZM387 1554L424 1522Q338 1414 335 1288V1168H281V1286Q285 1445 387 1554Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="502" d="M114 1151L77 1183Q158 1287 165 1398L166 1536H220V1419Q216 1260 114 1151ZM296 1151L259 1183Q340 1287 347 1398L348 1536H402V1419Q398 1260 296 1151Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="481" d="M84 -182L47 -150Q128 -46 135 65L136 228H190V86Q186 -73 84 -182ZM255 -182L218 -150Q299 -46 306 65L307 228H361V86Q357 -73 255 -182Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="635" d="M155 733Q155 804 200 848T321 893T442 849T489 730V703Q489 632 442 589T322 545Q250 545 203 587T155 701V733Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="604" d="M179 560L473 181H403L108 551V570L403 940H473L179 560Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="604" d="M176 940L470 560V541L176 171H106L399 550L106 940H176Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-100.ttf b/static/fonts/roboto-v18-latin-100.ttf
deleted file mode 100644
index 09cd7c01e3..0000000000
Binary files a/static/fonts/roboto-v18-latin-100.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100.woff b/static/fonts/roboto-v18-latin-100.woff
deleted file mode 100644
index a01e70821b..0000000000
Binary files a/static/fonts/roboto-v18-latin-100.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100.woff2 b/static/fonts/roboto-v18-latin-100.woff2
deleted file mode 100644
index d19e7b3256..0000000000
Binary files a/static/fonts/roboto-v18-latin-100.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100italic.eot b/static/fonts/roboto-v18-latin-100italic.eot
deleted file mode 100644
index 1f76442670..0000000000
Binary files a/static/fonts/roboto-v18-latin-100italic.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100italic.svg b/static/fonts/roboto-v18-latin-100italic.svg
deleted file mode 100644
index c51ce871be..0000000000
--- a/static/fonts/roboto-v18-latin-100italic.svg
+++ /dev/null
@@ -1,332 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1092" ><font-face
-    font-family="Roboto Thin"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="485" />
-<glyph unicode="!" horiz-adv-x="395" d="M182 401H128L309 1456H363L182 401ZM47 51Q50 71 68 88T108 105Q131 105 145 87T156 47Q153 27 134 11T94 -6Q71 -5 57 12T47 51Z" />
-<glyph unicode="&quot;" horiz-adv-x="515" d="M328 1388L277 1122H227L274 1395L295 1536H350L328 1388ZM523 1388L472 1122H422Q469 1395 491 1536H545L523 1388Z" />
-<glyph unicode="#" horiz-adv-x="1097" d="M686 410H336L193 0H137L278 410H17L24 462H296L480 986H191L198 1040H498L643 1455H700L555 1040H906L1052 1455H1108L964 1040H1208L1201 986H945L761 462H1035L1028 410H743L599 0H543L686 410ZM354 462H703L887 986H537L354
-462Z" />
-<glyph unicode="$" horiz-adv-x="1097" d="M890 344Q922 517 758 623Q702 659 584 705T405 790Q222 907 254 1110Q276 1263 391 1363T683 1476L714 1663H769L738 1476Q909 1461 989 1347T1046 1047H993Q1015 1216 937 1320T707 1424Q558 1424 446 1338T308 1112Q293
-1026 319 964T408 853T608 754T815 651Q973 535 945 346Q922 190 807 93T520 -20L489 -208H434L465 -21Q274 -11 175 104T99 409H152Q130 238 222 134T487 32Q638 34 752 122T890 344Z" />
-<glyph unicode="%" horiz-adv-x="1491" d="M532 1477Q644 1477 705 1389T748 1176L737 1110Q714 976 628 888T426 800Q315 800 252 885T207 1099L217 1163Q238 1297 327 1387T532 1477ZM259 1011Q267 940 311 898T426 855Q516 855 587 923T680 1104L694 1176Q701
-1220 696 1264Q687 1338 644 1380T532 1422Q440 1422 369 1353T275 1176L261 1099Q253 1054 259 1011ZM1122 657Q1235 657 1296 570T1339 357L1327 279Q1302 147 1215 63T1016 -21Q902 -21 841 67T798 279L809 346Q831 478 918 567T1122 657ZM852 279Q845 234 851
-191Q859 120 903 77T1016 34Q1109 34 1178 102T1271 279L1285 357Q1292 402 1288 446Q1280 519 1236 560T1122 602Q1028 602 958 534T865 347L852 279ZM341 132L299 164L1184 1299L1226 1267L341 132Z" />
-<glyph unicode="&amp;" horiz-adv-x="1220" d="M452 803Q397 896 375 953T346 1070Q334 1167 376 1265T502 1420T689 1477Q803 1477 871 1401T921 1213Q900 1069 692 918L521 794L894 258Q1027 417 1066 632H1121Q1080 387 927 215L1079 0H1015L892 175Q668 -20
-451 -20Q269 -20 164 83T83 352Q98 453 170 551T393 762L452 803ZM451 34Q662 34 860 218L481 763L424 723Q285 618 219 530T137 352Q122 260 157 188T272 75T451 34ZM400 1080Q410 966 492 835L665 959Q840 1085 865 1213Q881 1304 829 1363T689 1423Q559 1423
-474 1320T400 1080Z" />
-<glyph unicode="&apos;" horiz-adv-x="340" d="M314 1362L264 1122H213L260 1370L286 1536H341L314 1362Z" />
-<glyph unicode="(" horiz-adv-x="599" d="M708 1623L721 1578Q599 1499 494 1355T312 1009T200 590L195 564Q169 390 172 222Q174 -6 235 -174T409 -428L385 -469Q260 -375 193 -205T119 204Q112 443 166 701T327 1176Q479 1486 708 1623Z" />
-<glyph unicode=")" horiz-adv-x="614" d="M-120 -470L-133 -425Q60 -298 197 -30T388 564L393 590Q419 764 417 932Q412 1168 351 1331T179 1581L203 1622Q323 1532 392 1359T468 947Q477 664 402 363T192 -152T-120 -470Z" />
-<glyph unicode="*" horiz-adv-x="840" d="M452 1019L122 1142L147 1194L477 1061L546 1456H602L527 1064L891 1204L904 1150L529 1012L717 695L668 664L489 985L212 662L169 695L452 1019Z" />
-<glyph unicode="+" horiz-adv-x="1126" d="M591 702H1057L1049 649H582L495 146H441L527 649H80L87 702H536L623 1206H678L591 702Z" />
-<glyph unicode="," horiz-adv-x="382" d="M-20 -255L-54 -221Q53 -101 75 25L98 159H152L131 33Q102 -139 -20 -255Z" />
-<glyph unicode="-" horiz-adv-x="599" d="M524 639H66L74 693H531L524 639Z" />
-<glyph unicode="." horiz-adv-x="436" d="M47 51Q50 71 68 88T108 105Q131 105 145 87T156 47Q153 27 134 11T94 -6Q71 -5 57 12T47 51Z" />
-<glyph unicode="/" horiz-adv-x="769" d="M-25 -124H-85L777 1455H837L-25 -124Z" />
-<glyph unicode="0" horiz-adv-x="1097" d="M446 -20Q332 -20 254 37T140 205T109 460L117 556L165 840Q216 1137 352 1307T693 1477Q809 1477 887 1420T1001 1249T1030 996L1020 888L971 604Q919 309 783 145T446 -20ZM976 1106Q963 1264 891 1343T694 1423Q514
-1423 391 1270T218 834L172 564L164 479Q154 355 181 250T275 90T445 34Q624 34 746 185T917 607L959 845Q985 992 976 1106Z" />
-<glyph unicode="1" horiz-adv-x="1097" d="M537 0H483L723 1385L292 1232L300 1290L774 1460H787L537 0Z" />
-<glyph unicode="2" horiz-adv-x="1097" d="M901 0H56L62 54L715 713Q911 915 939 1085Q965 1233 887 1327T653 1422Q501 1422 385 1315T237 1045H183Q215 1231 347 1353T652 1476Q830 1476 925 1369T995 1085Q969 906 763 689L136 54H908L901 0Z" />
-<glyph unicode="3" horiz-adv-x="1097" d="M433 770H522Q695 770 820 855T971 1085Q997 1233 916 1327T683 1422Q527 1422 411 1327T261 1074L207 1075Q238 1253 372 1364T683 1476Q857 1476 954 1366T1025 1081Q1009 968 927 879T708 744Q837 708 902 613T948
-386Q921 207 787 94T467 -20Q344 -20 248 34T104 186T71 405H125Q104 247 202 141T466 34Q633 34 749 129T893 382Q919 540 821 627T519 714H426L433 770Z" />
-<glyph unicode="4" horiz-adv-x="1097" d="M792 451H1035L1028 397H783L714 0H661L729 397L45 398L49 427L899 1455L965 1456L792 451ZM139 451H738L900 1383L798 1250L139 451Z" />
-<glyph unicode="5" horiz-adv-x="1097" d="M254 763L427 1456H1116L1110 1403H469L316 819Q446 914 625 916Q747 916 833 857T957 694T977 464Q944 241 820 111T507 -20Q334 -20 236 90T146 383H200Q192 220 272 127T507 34Q643 34 743 113T893 343T923 613Q902
-730 824 795T627 862Q446 864 294 747L254 763Z" />
-<glyph unicode="6" horiz-adv-x="1097" d="M958 1476L951 1422Q669 1422 475 1240T201 733Q265 819 355 876Q483 957 632 957Q753 957 837 894T955 722T971 480Q950 342 880 224T709 43T498 -20Q366 -20 272 47T135 235T113 492L136 641Q196 1027 408 1251T958
-1476ZM625 903Q485 903 354 820T188 621L167 493Q148 368 183 260T299 92T497 33Q619 34 721 119T881 351T920 636Q903 762 825 832T625 903Z" />
-<glyph unicode="7" horiz-adv-x="1097" d="M1106 1422L264 0H208L1040 1402H200L207 1456H1110L1106 1422Z" />
-<glyph unicode="8" horiz-adv-x="1097" d="M1046 1086Q1026 967 941 878T724 744Q850 702 916 604T964 379Q936 200 792 90T450 -20Q323 -20 227 30T86 171T62 379Q84 509 178 604T424 746Q313 789 260 881T224 1086Q251 1257 383 1366T695 1476Q808 1476 896
-1426T1024 1286T1046 1086ZM908 374Q926 470 889 548T766 672T576 718Q408 718 276 622T115 374Q88 223 183 129T449 34Q621 34 750 128T908 374ZM993 1091Q1018 1230 929 1326T696 1422Q541 1422 424 1329T279 1091Q253 953 339 863T575 772Q727 772 846 861T993
-1091Z" />
-<glyph unicode="9" horiz-adv-x="1097" d="M938 717L939 725Q863 604 747 536T497 468Q352 468 259 571T156 842Q146 988 215 1143T399 1386T654 1476Q775 1476 859 1424T986 1271T1028 1042Q1026 931 987 712Q924 364 730 174T243 -20H199L207 34H231Q504 34
-686 208T938 717ZM497 522Q641 522 777 615T953 840Q972 957 974 1023Q978 1140 943 1234T835 1375T658 1422Q531 1420 426 1336T259 1107Q205 980 209 858Q212 710 290 616T497 522Z" />
-<glyph unicode=":" horiz-adv-x="363" d="M277 51Q280 71 298 88T338 105Q361 105 375 87T386 47Q383 27 364 11T324 -6Q301 -5 287 12T277 51ZM191 1013Q194 1033 212 1050T252 1067Q275 1067 289 1049T300 1009Q297 989 278 973T238 956Q215 957 201 974T191 1013Z" />
-<glyph unicode=";" horiz-adv-x="363" d="M192 1013Q195 1033 213 1050T253 1067Q276 1067 290 1049T301 1009Q298 989 279 973T239 956Q216 957 202 974T192 1013ZM225 -255L191 -221Q298 -101 320 25L343 159H397L376 33Q347 -139 225 -255Z" />
-<glyph unicode="&lt;" horiz-adv-x="1031" d="M162 664L844 321L835 262L87 641L94 691L972 1068L964 1011L162 664Z" />
-<glyph unicode="=" horiz-adv-x="1118" d="M996 843H185L193 897H1003L996 843ZM925 436H115L122 490H933L925 436Z" />
-<glyph unicode="&gt;" horiz-adv-x="1031" d="M858 670L182 1013L190 1072L938 694L931 644L54 266L62 324L858 670Z" />
-<glyph unicode="?" horiz-adv-x="876" d="M349 401Q380 571 512 699L638 812Q743 911 786 1019T817 1230Q804 1321 744 1372T592 1423Q463 1423 366 1341T234 1117H179Q213 1276 326 1376T591 1476Q738 1476 815 1372T867 1110Q849 999 782 899T587 700T414 446L403
-400L349 401ZM264 51Q267 71 285 88T325 105Q348 105 362 87T373 47Q370 27 351 11T311 -6Q288 -5 274 12T264 51Z" />
-<glyph unicode="@" horiz-adv-x="1855" d="M1255 -20Q1159 -20 1109 44T1066 210Q909 -20 704 -20Q609 -20 558 48T508 249Q508 409 587 596T787 885T1049 988Q1111 988 1164 963T1277 878L1131 301Q1119 254 1117 205Q1114 125 1150 80T1258 35Q1392 35 1492
-160T1646 523Q1671 634 1676 739Q1685 929 1622 1069T1427 1282T1105 1354Q919 1354 748 1272T439 1032T221 671T134 268Q128 73 196 -82T395 -318T707 -398Q880 -398 1044 -318L1062 -366Q911 -453 704 -453Q507 -453 364 -369T148 -121T79 249Q83 465 165 684T392
-1071T720 1325T1109 1411Q1412 1411 1575 1238T1732 753Q1727 557 1661 370T1490 81T1255 -20ZM559 192Q564 119 601 77T702 34Q817 31 926 120T1086 344L1219 852Q1160 931 1046 933Q910 933 800 826T618 527T559 192Z" />
-<glyph unicode="A" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489Z" />
-<glyph unicode="B" horiz-adv-x="1208" d="M89 0L342 1456H709Q925 1454 1032 1355T1112 1083Q1090 955 1011 869T806 752Q934 730 1006 630T1058 401Q1029 218 888 109T543 0H89ZM268 719L153 54H542Q725 54 849 147T1004 399Q1030 541 938 630T675 719H268ZM277
-773H594Q790 773 909 853T1058 1087Q1085 1233 997 1315T718 1402H387L277 773Z" />
-<glyph unicode="C" horiz-adv-x="1297" d="M1128 445Q1068 229 917 105T549 -20Q422 -20 328 40T183 214T132 469Q131 548 144 625L177 820Q226 1109 394 1292T798 1476Q1007 1476 1122 1353T1227 1012H1174Q1182 1205 1084 1313T799 1422Q667 1422 552 1352T350
-1144T233 828L196 619Q185 553 185 485Q183 354 225 250T351 90T548 34Q744 34 879 142T1074 445H1128Z" />
-<glyph unicode="D" horiz-adv-x="1310" d="M89 0L342 1456H729Q865 1454 972 1395T1142 1226T1214 979Q1219 895 1205 811L1178 650Q1147 467 1048 318T802 85T488 0H89ZM387 1402L153 54H472Q712 54 894 222T1125 661L1153 820Q1172 931 1154 1035Q1123 1202
-1010 1300T732 1402H387Z" />
-<glyph unicode="E" horiz-adv-x="1141" d="M978 722H269L153 54H959L951 0H89L342 1456H1202L1194 1402H387L278 776H985L978 722Z" />
-<glyph unicode="F" horiz-adv-x="1147" d="M992 716H268L144 0H90L342 1456H1217L1210 1402H387L277 772H1000L992 716Z" />
-<glyph unicode="G" horiz-adv-x="1374" d="M1115 156Q1042 73 907 27T605 -20Q407 -20 286 112T156 465Q153 544 166 620L206 852Q237 1031 329 1175T553 1397T838 1476Q1036 1476 1154 1364T1269 1062H1216Q1216 1234 1114 1328T838 1422Q624 1422 464 1260T259
-843T212 551T210 480Q213 277 318 156T604 34Q746 34 865 71T1062 181L1137 605H707L714 660H1201L1115 156Z" />
-<glyph unicode="H" horiz-adv-x="1405" d="M1099 0H1045L1169 722H269L144 0H90L341 1456H395L278 776H1178L1296 1456H1349L1099 0Z" />
-<glyph unicode="I" horiz-adv-x="528" d="M183 0H129L380 1456H434L183 0Z" />
-<glyph unicode="J" horiz-adv-x="1101" d="M1012 1456H1066L894 459Q856 239 724 110T408 -20Q218 -20 128 96T67 401H121Q108 321 119 254Q136 147 210 91T407 34Q570 34 688 152T839 459L1012 1456Z" />
-<glyph unicode="K" horiz-adv-x="1271" d="M505 765L238 548L144 0H90L341 1456H395L250 620L518 848L1210 1456L1294 1455L546 799L1087 0H1021L505 765Z" />
-<glyph unicode="L" horiz-adv-x="1035" d="M154 54H877L870 0H89L341 1456H396L154 54Z" />
-<glyph unicode="M" horiz-adv-x="1713" d="M416 1456L758 81L1579 1456H1659L1407 0H1353L1590 1367L770 0H728L381 1369L144 0H90L342 1456H416Z" />
-<glyph unicode="N" horiz-adv-x="1416" d="M1110 0H1058L382 1366L145 0H90L340 1456H393L1070 93L1306 1456H1360L1110 0Z" />
-<glyph unicode="O" horiz-adv-x="1333" d="M560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1201 630Q1170 446 1079 295T853 62T560 -20ZM1195
-979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979Z" />
-<glyph unicode="P" horiz-adv-x="1203" d="M250 615L144 0H90L342 1456H779Q982 1454 1090 1339T1167 1031Q1135 838 993 727T628 615H250ZM259 669H629Q819 669 949 764T1113 1029Q1143 1196 1053 1297T780 1402H387L259 669Z" />
-<glyph unicode="Q" horiz-adv-x="1333" d="M799 32L1013 -230L972 -263L744 9Q651 -20 560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1202
-637Q1165 419 1061 264T799 32ZM1195 979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979Z" />
-<glyph unicode="R" horiz-adv-x="1310" d="M737 623H247L139 0H86L337 1456H783Q915 1455 1013 1402T1156 1253T1180 1036Q1155 888 1049 779T793 636L1062 14L1060 0H1005L737 623ZM256 677H684Q849 677 972 778T1126 1036Q1156 1201 1057 1301T767 1402H382L256 677Z" />
-<glyph unicode="S" horiz-adv-x="1185" d="M1009 453Q989 544 904 604T641 718T378 826T259 955T240 1120Q257 1227 331 1307T520 1432T766 1476Q895 1476 994 1420T1139 1266T1169 1046H1115Q1140 1209 1041 1315T767 1422Q604 1422 472 1349T303 1153Q281 1080
-295 1022Q315 933 404 875T652 771Q896 702 992 600T1063 351Q1046 240 971 157T776 27T524 -20Q296 -20 170 98T71 411H125Q100 239 210 137T523 34Q686 34 818 106T994 300Q1024 383 1009 453Z" />
-<glyph unicode="T" horiz-adv-x="1197" d="M1275 1402H760L518 0H464L706 1402H193L200 1456H1282L1275 1402Z" />
-<glyph unicode="U" horiz-adv-x="1334" d="M1299 1456L1130 475Q1091 250 938 115T566 -20Q427 -20 327 41T183 215T162 469L333 1456H386L216 469Q185 277 283 156T566 34Q760 34 901 158T1078 486L1245 1456H1299Z" />
-<glyph unicode="V" horiz-adv-x="1196" d="M494 142L507 57L550 146L1228 1455H1288L535 0H470L167 1457H224L494 142Z" />
-<glyph unicode="W" horiz-adv-x="1809" d="M394 94L496 334L1003 1456H1063L1220 326L1244 94L1349 334L1814 1455H1874L1268 0H1208L1045 1218L1022 1365L949 1210L409 0H348L192 1456H250L394 94Z" />
-<glyph unicode="X" horiz-adv-x="1196" d="M619 786L1180 1455H1249L648 739L1041 0H977L611 700L25 0H-42L582 747L203 1457H268L619 786Z" />
-<glyph unicode="Y" horiz-adv-x="1196" d="M589 604L1231 1455L1299 1454L609 549L515 0H461L557 558L179 1457H248L589 604Z" />
-<glyph unicode="Z" horiz-adv-x="1197" d="M72 54H1002L994 0H-12L-5 44L1128 1403H270L277 1456L1213 1455L1208 1418L72 54Z" />
-<glyph unicode="[" horiz-adv-x="436" d="M610 1610H387L95 -258H316L309 -312H32L341 1664H616L610 1610Z" />
-<glyph unicode="\" horiz-adv-x="761" d="M203 1457H259L577 -126H521L203 1457Z" />
-<glyph unicode="]" horiz-adv-x="436" d="M157 1664H434L125 -312H-150L-143 -258H79L370 1610H150L157 1664Z" />
-<glyph unicode="^" horiz-adv-x="834" d="M541 1380L171 730H110L524 1456H575L743 728H684L541 1380Z" />
-<glyph unicode="_" horiz-adv-x="830" d="M708 -54H-114L-106 0H716L708 -54Z" />
-<glyph unicode="`" horiz-adv-x="531" d="M497 1269H441L289 1537H352L497 1269Z" />
-<glyph unicode="a" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850 1009T915
-760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33Z" />
-<glyph unicode="b" horiz-adv-x="1097" d="M473 -20Q361 -20 275 29T146 171L115 0H61L326 1536H380L264 885Q339 990 439 1046T656 1102Q761 1102 835 1050T943 898T974 675Q971 611 962 552L949 486Q897 251 771 116T473 -20ZM906 552L918 659Q926 768 900 861T811
-1001T657 1048Q524 1048 407 968T249 770L160 274Q184 158 267 96T473 34Q634 34 746 166T902 531L906 552Z" />
-<glyph unicode="c" horiz-adv-x="1018" d="M430 34Q572 34 676 115T816 327H870Q834 172 713 76T431 -20Q282 -20 190 72T78 329Q67 424 81 520L87 562Q113 721 186 847T364 1037T595 1102Q758 1102 851 996T933 725H879Q892 869 813 958T596 1048Q407 1048 282
-894T130 480L126 407Q126 231 205 133T430 34Z" />
-<glyph unicode="d" horiz-adv-x="1097" d="M111 552Q139 715 209 844T380 1037T598 1102Q712 1102 796 1045T919 883L1033 1536H1087L822 0H768L802 173Q730 82 630 31T412 -20Q306 -20 234 32T128 186T97 410Q99 467 111 552ZM152 425Q144 315 169 223T255 83T410
-34Q540 33 643 96T813 268L903 775Q882 905 803 976T598 1048Q471 1048 372 964T217 729T152 425Z" />
-<glyph unicode="e" horiz-adv-x="1011" d="M458 -20Q328 -20 234 53T99 252T77 518L85 568Q109 714 187 841T374 1035T605 1102Q769 1102 862 981T941 671L938 640L929 577H143L132 518Q118 434 131 348Q153 205 240 120T457 33Q644 31 794 181L830 153Q682 -20
-458 -20ZM605 1048Q451 1048 330 933T149 631H879L882 644Q895 716 884 788Q866 906 791 977T605 1048Z" />
-<glyph unicode="f" horiz-adv-x="636" d="M143 0L319 1027H139L146 1082H330L355 1236Q382 1383 468 1469T683 1557Q746 1557 809 1539L794 1489Q731 1505 683 1503Q578 1501 505 1428T409 1226L383 1082H660L652 1027H374L197 0H143Z" />
-<glyph unicode="g" horiz-adv-x="1099" d="M108 552Q136 715 206 844T377 1037T595 1102Q712 1102 795 1044T915 884L951 1082H1005L826 38Q788 -185 660 -310T351 -436Q146 -436 33 -252L74 -218Q177 -383 348 -383Q504 -383 616 -278T767 20L797 171Q725 80
-626 30T409 -20Q303 -20 231 32T125 186T94 410Q96 467 108 552ZM148 425Q135 243 202 139T407 34Q536 34 640 97T810 276L898 767Q878 904 800 976T595 1048Q467 1048 367 962T212 726T148 425Z" />
-<glyph unicode="h" horiz-adv-x="1097" d="M256 830Q337 961 447 1031T674 1102Q798 1102 869 1038T951 853Q957 777 943 694L823 0H769L889 694Q901 764 899 832Q894 938 837 994T672 1049Q535 1047 409 943T237 693L117 0H63L328 1536H382L256 830Z" />
-<glyph unicode="i" horiz-adv-x="419" d="M130 0H76L262 1082H316L130 0ZM294 1422Q297 1442 315 1459T355 1476Q378 1476 392 1458T403 1418Q400 1398 381 1382T341 1365Q318 1366 304 1383T294 1422Z" />
-<glyph unicode="j" horiz-adv-x="442" d="M317 1082L110 -118Q84 -269 -4 -353T-219 -437Q-257 -437 -315 -417L-305 -365Q-258 -383 -218 -383Q-116 -385 -41 -313T55 -118L263 1082H317ZM300 1422Q303 1442 321 1459T361 1476Q384 1476 398 1458T409 1418Q406
-1398 387 1382T347 1365Q324 1366 310 1383T300 1422Z" />
-<glyph unicode="k" horiz-adv-x="950" d="M376 584L373 582L193 445L117 0H63L328 1536H382L205 513L900 1081H983L416 618L822 0H756L376 584Z" />
-<glyph unicode="l" horiz-adv-x="419" d="M130 0H76L340 1536H394L130 0Z" />
-<glyph unicode="m" horiz-adv-x="1791" d="M815 0H762L886 720Q897 788 893 849Q885 946 826 998T661 1049Q521 1047 395 939T226 684L107 0H53L239 1082H294L246 826Q327 959 436 1030T663 1102Q797 1102 869 1036T946 846Q1018 963 1132 1032T1375 1102Q1500
-1102 1572 1037T1655 853Q1661 777 1647 694L1527 0H1474L1594 700Q1606 769 1603 833Q1598 939 1540 994T1373 1049Q1279 1046 1187 1002T1028 883T940 720L815 0Z" />
-<glyph unicode="n" horiz-adv-x="1097" d="M256 830Q337 961 447 1031T674 1102Q798 1102 869 1038T951 853Q957 777 943 694L823 0H769L889 694Q901 764 899 832Q894 938 837 994T672 1049Q535 1047 409 943T237 693L117 0H63L249 1082H303L256 830Z" />
-<glyph unicode="o" horiz-adv-x="1103" d="M80 562Q105 713 181 837T371 1031T620 1102Q730 1102 815 1053T950 908T1007 694Q1010 626 995 520Q970 369 894 244T704 50T456 -20Q345 -20 261 29T126 174T69 389Q65 456 80 562ZM127 348Q147 203 234 119T455 34Q612
-34 738 144T921 441Q967 596 948 734Q926 879 840 963T621 1048Q464 1048 337 937T154 641Q108 488 127 348Z" />
-<glyph unicode="p" horiz-adv-x="1097" d="M473 -20Q358 -20 272 30T146 168L43 -416H-11L247 1082H301L264 889Q335 985 434 1043T656 1102Q761 1102 835 1050T943 898T974 675Q971 611 962 552L949 486Q897 251 771 116T473 -20ZM907 552L919 659Q929 849 860
-948T657 1048Q525 1048 408 970T250 775L160 269Q183 156 267 95T473 34Q635 34 747 166T904 535L907 552Z" />
-<glyph unicode="q" horiz-adv-x="1097" d="M111 552Q157 809 286 955T598 1102Q710 1102 794 1048T919 889L955 1082H1008L750 -416H696L801 168Q728 79 629 30T412 -20Q308 -20 235 32T128 186T97 410Q99 467 111 552ZM152 425Q144 315 169 223T255 83T410 34Q540
-33 643 96T813 268L903 775Q882 902 802 975T598 1048Q479 1048 384 974T226 750T152 425Z" />
-<glyph unicode="r" horiz-adv-x="674" d="M708 1044L643 1049Q509 1049 394 950T240 709L117 0H63L249 1082H303L261 857Q329 973 427 1037T645 1102Q683 1102 721 1090L708 1044Z" />
-<glyph unicode="s" horiz-adv-x="998" d="M767 265Q803 453 493 532L382 564Q152 639 180 829Q198 952 310 1027T570 1102Q733 1102 825 1018T903 793H849Q861 907 782 977T571 1048Q443 1048 348 989T234 831Q204 672 418 605L567 562L617 545Q850 460 821 264Q802
-135 687 58T412 -20Q245 -20 145 61T59 275H112Q107 163 186 99T411 34Q549 37 649 100T767 265Z" />
-<glyph unicode="t" horiz-adv-x="639" d="M419 1374L369 1082H606L599 1027H359L222 235L218 180Q215 112 246 74T340 34Q368 34 449 43L451 -8Q405 -20 342 -20Q172 -20 165 155Q163 206 172 259L304 1027H111L119 1082H314L364 1374H419Z" />
-<glyph unicode="u" horiz-adv-x="1097" d="M766 0L800 175Q729 77 628 29T406 -20Q280 -20 207 47T121 238Q114 317 128 401L245 1082H299L180 393Q169 325 173 261Q178 153 238 94T404 34Q550 34 667 113T821 321L952 1082H1007L821 0H766Z" />
-<glyph unicode="v" horiz-adv-x="959" d="M393 88L926 1081H985L410 0H357L116 1083H172L393 88Z" />
-<glyph unicode="w" horiz-adv-x="1514" d="M306 308L321 84L801 1082H855L958 313L987 83L1088 317L1433 1081H1497L1006 0H952L832 818L818 1003L730 809L337 0H283L163 1083L223 1082L306 308Z" />
-<glyph unicode="x" horiz-adv-x="959" d="M472 603L882 1081L951 1080L499 551L802 0H738L462 507L28 0H-41L435 559L147 1083H212L472 603Z" />
-<glyph unicode="y" horiz-adv-x="959" d="M396 84L406 105L939 1081H1000L316 -182Q242 -322 166 -378T-3 -437Q-41 -437 -83 -426L-77 -375Q-26 -384 -9 -384Q124 -384 221 -236L261 -170L358 11L124 1083H181L396 84Z" />
-<glyph unicode="z" horiz-adv-x="959" d="M64 54H808L800 0H-19L-12 44L845 1027H189L197 1082L928 1081L921 1034L64 54Z" />
-<glyph unicode="{" horiz-adv-x="650" d="M463 -440Q354 -401 292 -321T218 -129Q211 -57 222 19L261 265Q270 325 264 375Q241 535 62 543L71 609Q189 615 261 685T357 885L393 1120Q450 1490 778 1597L787 1551Q647 1502 560 1391T449 1125L414 898Q374 636
-158 575Q230 552 271 497T318 364Q321 312 314 265L276 20Q265 -50 272 -114Q292 -319 488 -396L463 -440Z" />
-<glyph unicode="|" horiz-adv-x="404" d="M94 -270H40L308 1456H362L94 -270Z" />
-<glyph unicode="}" horiz-adv-x="650" d="M-156 -393Q136 -289 187 39L220 253Q260 513 476 577Q404 599 363 654T317 786Q313 837 320 885L358 1132Q368 1201 364 1266Q347 1478 152 1553L172 1596Q283 1555 344 1475T417 1282Q423 1205 411 1126L373 885Q364
-825 370 776Q379 700 431 657T572 609L563 543Q442 537 369 462T276 259L241 32Q184 -335 -143 -441L-156 -393Z" />
-<glyph unicode="~" horiz-adv-x="1380" d="M1233 751Q1207 611 1127 528T928 443Q813 443 716 537L614 640Q531 720 439 720Q343 720 278 653T188 462L133 463Q160 608 240 690T438 774Q550 774 650 681L761 570Q840 496 927 496Q1023 498 1088 565T1177 753L1233 751Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="485" />
-<glyph unicode="&#xa1;" horiz-adv-x="404" d="M189 696H243L62 -359H8L189 696ZM324 1046Q321 1026 303 1009T263 992Q240 992 226 1010T215 1050Q218 1070 237 1086T277 1103Q300 1102 314 1085T324 1046Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1087" d="M457 34Q599 34 703 113T848 327H902Q865 178 754 87T483 -19L442 -245H387L428 -19Q273 -6 189 105T107 397Q107 514 142 645T242 872Q382 1081 617 1101L657 1318H712L672 1101Q825 1085 905 983T972 725H918Q932
-868 856 958T641 1048Q523 1048 430 988T271 816T178 562Q161 459 160 407Q154 236 232 135T457 34Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1126" d="M362 667L316 343Q289 151 199 53L934 54L927 0H-7L0 54H114Q210 95 248 273L260 336L308 667H104L112 721H315L361 1039Q394 1234 510 1355T788 1476Q948 1476 1031 1370T1090 1089H1037Q1047 1158 1038 1219Q1024
-1314 959 1368T789 1422Q649 1422 548 1317T416 1039L369 721H727L720 667H362Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1467" d="M1052 155Q846 -20 620 -20Q511 -20 414 24T248 153L44 -26L8 15L214 196Q160 291 144 396Q118 564 176 733T369 1033L218 1227L261 1264L409 1073Q612 1234 828 1234Q934 1234 1027 1193T1191 1071L1411 1265L1448
-1223L1226 1028Q1340 840 1302 608Q1262 373 1093 198L1238 11L1194 -27L1052 155ZM200 608Q174 464 220 329T373 113T620 33Q785 33 936 134T1177 408T1255 747Q1241 936 1124 1058T829 1181Q686 1181 553 1105T323 894T200 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1017" d="M1056 1455H1119L567 676H920L913 621H532L490 381H869L861 326H481L424 0H371L426 326H49L57 381H435L478 621H100L108 676H465L179 1457H239L495 738L509 687H517L551 738L1056 1455Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="396" d="M16 -270L145 482H199L70 -270H16ZM238 698H184L314 1456H368L238 698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1196" d="M1046 431Q1028 328 942 259T705 163Q823 110 871 33T903 -149Q877 -307 741 -401T411 -495Q204 -495 93 -379T9 -64L63 -62Q36 -235 131 -338T410 -441Q559 -441 676 -377T833 -201Q861 -122 849 -60Q823 72 618
-139L531 166Q278 234 188 326T121 551Q137 653 219 724T445 823Q233 929 265 1129Q281 1233 350 1311T527 1433T759 1476Q958 1476 1059 1359T1132 1045H1078Q1094 1154 1060 1240T946 1374T760 1422Q597 1422 478 1351T326 1157Q307 1088 318 1039Q334 956 410
-903T639 805T867 725T983 648T1040 553T1046 431ZM520 796Q392 785 308 735T191 602T176 453Q194 380 262 331T458 242L611 196Q756 201 855 256T984 401Q1006 471 991 526Q953 664 713 738L520 796Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="889" d="M296 1422Q299 1443 317 1460T357 1477Q380 1477 394 1460T406 1420Q403 1399 384 1383T344 1366Q321 1366 307 1383T296 1422ZM728 1422Q731 1443 749 1460T789 1477Q812 1477 826 1460T837 1420Q834 1399 816 1383T776
-1366Q753 1366 739 1383T728 1422Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1626" d="M1106 615Q1080 468 992 385T772 302Q666 302 599 369T517 552Q504 648 533 788Q567 954 665 1054T897 1155Q1031 1155 1095 1069T1143 842H1092Q1099 897 1093 945Q1082 1020 1032 1061T897 1102Q785 1102 701
-1013T588 784Q562 655 569 575Q576 476 629 417T772 357Q886 357 958 424T1054 616L1106 615ZM202 559Q214 409 286 287T474 100T728 34Q930 34 1113 159T1397 491T1482 899Q1468 1049 1395 1170T1208 1356T954 1421Q745 1421 560 1290T275 945Q185 751 202 559ZM953
-1476Q1105 1476 1232 1406T1439 1206T1536 915Q1558 694 1450 470T1145 113T729 -21Q577 -21 451 49T244 250T147 544Q125 762 232 984T535 1341T953 1476Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="881" d="M686 704L684 764L688 823Q572 693 432 691Q325 691 266 749T221 900Q237 1005 328 1066T563 1132H733L747 1201Q755 1245 752 1285Q745 1350 706 1385T599 1422Q493 1422 425 1376T335 1244H280Q302 1348 389 1412T598
-1476Q709 1476 764 1400T802 1200L748 886Q733 794 743 705L686 704ZM433 746Q507 746 580 790T694 899L727 1078H569Q308 1072 276 904Q262 831 305 789T433 746Z" />
-<glyph unicode="&#xab;" horiz-adv-x="888" d="M197 777L418 401H351L126 772L128 791L477 1160L549 1159L197 777ZM475 521L696 145H629L404 516L406 535L755 904L827 903L475 521Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1078" d="M854 396H800L852 700H136L143 753H913L854 396Z" />
-<glyph unicode="&#xad;" horiz-adv-x="599" d="M524 639H66L74 693H531L524 639Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1634" d="M940 1476Q1091 1476 1218 1407T1425 1207T1522 915Q1544 690 1434 467T1130 111T715 -21Q563 -21 437 49T230 250T133 544Q117 708 175 880T352 1190T624 1401T940 1476ZM187 559Q199 410 272 288T461 100T715
-34Q863 34 1004 103T1256 300T1424 587T1468 899Q1454 1049 1381 1170T1194 1356T940 1421Q738 1421 557 1298T272 969T187 559ZM649 678L594 326H540L668 1156H897Q1027 1154 1094 1092T1145 916Q1124 780 964 709Q1081 659 1060 505Q1049 439 1050 405L1051 342L1049
-326H991Q986 362 990 398L1005 504Q1019 593 984 634T858 678H649ZM657 734H851Q940 736 1007 785T1090 917Q1124 1096 897 1101H715L657 734Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="797" d="M802 1383H251L257 1436H809L802 1383Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="770" d="M269 1236Q283 1332 362 1404T535 1476Q627 1476 683 1404T725 1236Q709 1140 633 1070T463 999Q367 999 310 1071T269 1236ZM324 1168Q333 1118 370 1087T462 1055Q522 1055 574 1090T653 1186T671 1304Q661 1357
-625 1389T536 1421Q475 1421 422 1384T340 1286T324 1168Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1055" d="M585 805H990L984 751H577L505 289H451L523 751H94L100 805H531L603 1267H656L585 805ZM836 -1H25L32 53H843L836 -1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="716" d="M644 664H116L123 708L534 1076Q629 1166 646 1247Q662 1329 611 1375Q566 1415 492 1415Q399 1415 334 1366T246 1227H192Q214 1333 297 1398T490 1464Q594 1464 654 1405T700 1248Q684 1144 551 1025L480 961L194
-713H652L644 664Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="716" d="M350 1090H417Q514 1093 581 1135T663 1249Q679 1323 633 1368T502 1414Q412 1414 349 1369T263 1247H210Q231 1344 312 1404T500 1464Q611 1464 672 1403T717 1246Q697 1129 535 1066Q612 1041 647 991T671 875Q657
-778 573 716T374 653T190 715T129 881H182Q173 798 228 750T373 701Q468 701 534 748T617 874Q631 951 581 994T415 1041H342L350 1090Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="506" d="M449 1535L517 1534L288 1271L226 1272L449 1535Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1097" d="M300 1082L190 440Q178 371 179 299Q179 175 238 105T410 34Q573 34 686 135T839 414L954 1082H1008L822 0H771L807 203Q667 -20 420 -20Q320 -20 248 27T145 171L42 -416H-10L248 1082H300Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="928" d="M608 0L697 520H595Q377 520 262 650T180 988Q214 1198 370 1327T752 1456H914L662 0H608Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="468" d="M191 708Q195 728 213 745T253 762Q276 762 290 744T301 704Q297 684 279 668T238 651Q216 652 202 669T191 708Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="485" d="M97 0L72 -77L106 -84Q236 -120 217 -245Q205 -328 127 -378T-94 -435L-93 -386Q8 -383 78 -346T162 -245Q182 -150 56 -129L0 -120L44 0H97Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="716" d="M433 664H379L503 1384L250 1306L257 1358L556 1455H567L433 664Z" />
-<glyph unicode="&#xba;" horiz-adv-x="897" d="M597 1476Q730 1476 796 1380T841 1141L823 1036Q796 879 701 785T473 690Q343 690 275 785T229 1024L246 1128Q271 1282 367 1379T597 1476ZM279 920Q287 838 338 791T473 744Q585 744 665 824T769 1034T793 1190T792
-1245Q782 1328 731 1375T598 1422Q484 1422 404 1340T301 1131T277 975T279 920Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="880" d="M248 941L471 560L468 541L121 172L49 173L400 554L182 941H248ZM530 941L753 560L750 541L403 172L331 173L682 554L464 941H530Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1433" d="M446 664H392L516 1384L263 1306L270 1358L569 1455H580L446 664ZM298 140L255 172L1140 1307L1183 1275L298 140ZM1130 253H1272L1264 204H1121L1086 0H1034L1068 204L659 205L663 236L1160 788L1221 789L1130
-253ZM738 253H1076L1158 719L1106 654L738 253Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1473" d="M256 140L213 172L1098 1307L1141 1275L256 140ZM423 664H369L493 1384L240 1306L247 1358L546 1455H557L423 664ZM1248 0H720L727 44L1138 412Q1233 502 1250 583Q1266 665 1215 711Q1170 751 1096 751Q1003 751
-938 702T850 563H796Q818 669 901 734T1094 800Q1198 800 1258 741T1304 584Q1288 480 1155 361L1084 297L798 49H1256L1248 0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1548" d="M455 140L412 172L1297 1307L1340 1275L455 140ZM1265 253H1407L1399 204H1256L1221 0H1169L1203 204L794 205L798 236L1295 788L1356 789L1265 253ZM873 253H1211L1293 719L1241 654L873 253ZM392 1090H459Q556
-1093 623 1135T705 1249Q721 1323 675 1368T544 1414Q454 1414 391 1369T305 1247H252Q273 1344 354 1404T542 1464Q653 1464 714 1403T759 1246Q739 1129 577 1066Q654 1041 689 991T713 875Q699 778 615 716T416 653T232 715T171 881H224Q215 798 270 750T415
-701Q510 701 576 748T659 874Q673 951 623 994T457 1041H384L392 1090Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="895" d="M529 695Q511 593 475 531T368 408T265 317Q144 204 95 85T62 -138Q75 -228 136 -278T296 -328Q423 -328 517 -245T644 -22H699Q664 -187 557 -284T297 -381T66 -278T12 -15Q31 101 103 211T332 444Q394 493 426
-547T476 695H529ZM614 1044Q611 1024 593 1007T553 990Q530 990 516 1008T505 1048Q508 1068 527 1084T567 1101Q590 1100 604 1083T614 1044Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489ZM808 1588H752L600 1856H663L808 1588Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489ZM948 1854L1016 1853L787 1590L725 1591L948 1854Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489ZM1013 1593L1012 1583L946 1582L800 1778L586 1584H521L522 1598L783 1836H823L1013 1593Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489ZM1117 1805Q1098 1719 1045 1670T921 1620Q879 1620 849 1639T790 1682T731 1725T662 1744Q557 1744 522 1621H467Q482
-1699 535 1749T662 1799Q703 1799 734 1779T793 1737T851 1696T921 1676Q973 1676 1009 1711T1062 1805H1117Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489ZM520 1741Q523 1762 541 1779T581 1796Q604 1796 618 1779T630 1739Q627 1718 608 1702T568 1685Q545 1685 531 1702T520
-1741ZM952 1741Q955 1762 973 1779T1013 1796Q1036 1796 1050 1779T1061 1739Q1058 1718 1040 1702T1000 1685Q977 1685 963 1702T952 1741Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1196" d="M911 435H221L-12 0H-72L706 1455L771 1456L1051 0H994L911 435ZM249 489H900L732 1388L249 489ZM625 1701Q638 1777 695 1826T818 1875Q888 1875 928 1823T959 1700Q949 1631 894 1581T767 1531Q701 1531 658 1580T625
-1701ZM679 1657Q693 1586 768 1586Q821 1586 858 1620T906 1701Q910 1724 907 1746Q900 1781 876 1800T817 1820Q751 1820 709 1766T679 1657Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1772" d="M1613 0H881L938 425H334L11 0H-56L1049 1456H1804L1797 1402H1121L1039 786H1608L1601 732H1032L941 54H1620L1613 0ZM373 478H944L1066 1391L373 478Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1297" d="M1128 445Q1068 229 917 105T549 -20Q422 -20 328 40T183 214T132 469Q131 548 144 625L177 820Q226 1109 394 1292T798 1476Q1007 1476 1122 1353T1227 1012H1174Q1182 1205 1084 1313T799 1422Q667 1422 552 1352T350
-1144T233 828L196 619Q185 553 185 485Q183 354 225 250T351 90T548 34Q744 34 879 142T1074 445H1128ZM579 -9L554 -86L588 -93Q718 -129 699 -254Q687 -337 609 -387T388 -444L389 -395Q490 -392 560 -355T644 -254Q664 -159 538 -138L482 -129L526 -9H579Z"
-/>
-<glyph unicode="&#xc8;" horiz-adv-x="1141" d="M978 722H269L153 54H959L951 0H89L342 1456H1202L1194 1402H387L278 776H985L978 722ZM815 1588H759L607 1856H670L815 1588Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1141" d="M978 722H269L153 54H959L951 0H89L342 1456H1202L1194 1402H387L278 776H985L978 722ZM955 1854L1023 1853L794 1590L732 1591L955 1854Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1141" d="M978 722H269L153 54H959L951 0H89L342 1456H1202L1194 1402H387L278 776H985L978 722ZM1020 1593L1019 1583L953 1582L807 1778L593 1584H528L529 1598L790 1836H830L1020 1593Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1141" d="M978 722H269L153 54H959L951 0H89L342 1456H1202L1194 1402H387L278 776H985L978 722ZM527 1741Q530 1762 548 1779T588 1796Q611 1796 625 1779T637 1739Q634 1718 615 1702T575 1685Q552 1685 538 1702T527 1741ZM959
-1741Q962 1762 980 1779T1020 1796Q1043 1796 1057 1779T1068 1739Q1065 1718 1047 1702T1007 1685Q984 1685 970 1702T959 1741Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="528" d="M183 0H129L380 1456H434L183 0ZM476 1588H420L268 1856H331L476 1588Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="528" d="M183 0H129L380 1456H434L183 0ZM615 1854L683 1853L454 1590L392 1591L615 1854Z" />
-<glyph unicode="&#xce;" horiz-adv-x="528" d="M183 0H129L380 1456H434L183 0ZM681 1593L680 1583L614 1582L468 1778L254 1584H189L190 1598L451 1836H491L681 1593Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="528" d="M183 0H129L380 1456H434L183 0ZM188 1741Q191 1762 209 1779T249 1796Q272 1796 286 1779T298 1739Q295 1718 276 1702T236 1685Q213 1685 199 1702T188 1741ZM620 1741Q623 1762 641 1779T681 1796Q704 1796 718
-1779T729 1739Q726 1718 708 1702T668 1685Q645 1685 631 1702T620 1741Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1340" d="M119 0L243 713H78L86 767H252L372 1456H759Q895 1454 1002 1395T1172 1226T1244 979Q1249 895 1235 811L1208 650Q1177 467 1078 318T832 85T518 0H119ZM649 713H297L183 54H502Q742 54 924 222T1155 661L1183
-820Q1202 931 1184 1035Q1153 1202 1040 1300T762 1402H417L307 767H656L649 713Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1416" d="M1110 0H1058L382 1366L145 0H90L340 1456H393L1070 93L1306 1456H1360L1110 0ZM1228 1805Q1209 1719 1156 1670T1032 1620Q990 1620 960 1639T901 1682T842 1725T773 1744Q668 1744 633 1621H578Q593 1699 646
-1749T773 1799Q814 1799 845 1779T904 1737T962 1696T1032 1676Q1084 1676 1120 1711T1173 1805H1228Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1333" d="M560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1201 630Q1170 446 1079 295T853 62T560 -20ZM1195
-979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979ZM874 1609H818L666 1877H729L874 1609Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1333" d="M560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1201 630Q1170 446 1079 295T853 62T560 -20ZM1195
-979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979ZM1014 1875L1082 1874L853 1611L791 1612L1014 1875Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1333" d="M560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1201 630Q1170 446 1079 295T853 62T560 -20ZM1195
-979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979ZM1079 1614L1078 1604L1012 1603L866 1799L652 1605H587L588 1619L849 1857H889L1079
-1614Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1333" d="M560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1201 630Q1170 446 1079 295T853 62T560 -20ZM1195
-979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979ZM1183 1826Q1164 1740 1111 1691T987 1641Q945 1641 915 1660T856 1703T797 1746T728
-1765Q623 1765 588 1642H533Q548 1720 601 1770T728 1820Q769 1820 800 1800T859 1758T917 1717T987 1697Q1039 1697 1075 1732T1128 1826H1183Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1333" d="M560 -20Q430 -20 332 39T179 211T121 465Q119 542 132 619L166 819Q199 1014 292 1166T519 1397T808 1476Q939 1476 1037 1417T1190 1244T1247 992Q1248 908 1235 831L1201 630Q1170 446 1079 295T853 62T560 -20ZM1195
-979Q1192 1186 1090 1304T808 1422Q587 1422 428 1255T221 817L186 613Q175 546 176 479Q176 274 278 154T560 34Q697 34 816 102T1022 305T1143 614L1182 833Q1195 906 1195 979ZM586 1762Q589 1783 607 1800T647 1817Q670 1817 684 1800T696 1760Q693 1739 674
-1723T634 1706Q611 1706 597 1723T586 1762ZM1018 1762Q1021 1783 1039 1800T1079 1817Q1102 1817 1116 1800T1127 1760Q1124 1739 1106 1723T1066 1706Q1043 1706 1029 1723T1018 1762Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1030" d="M-3 38L438 433L154 795L196 832L478 469L888 832L923 791L513 426L819 34L777 -1L473 389L32 -1L-3 38Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1333" d="M560 -20Q377 -20 256 91L122 -74L54 -73L217 131Q112 277 119 492L126 581L166 820Q199 1013 291 1164T518 1396T808 1476Q909 1476 998 1439T1151 1320L1291 1494L1359 1493L1184 1274Q1236 1173 1245 1061Q1254
-948 1236 838L1204 647Q1152 343 978 162T560 -20ZM174 505Q160 309 250 176L1119 1274Q1065 1351 983 1386T808 1422Q587 1422 428 1255T221 817L181 583L174 505ZM1195 1036Q1189 1141 1151 1227L286 136Q392 34 560 34Q776 34 933 192T1142 610L1180 821Q1201
-939 1195 1036Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1334" d="M1299 1456L1130 475Q1091 250 938 115T566 -20Q427 -20 327 41T183 215T162 469L333 1456H386L216 469Q185 277 283 156T566 34Q760 34 901 158T1078 486L1245 1456H1299ZM891 1588H835L683 1856H746L891 1588Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1334" d="M1299 1456L1130 475Q1091 250 938 115T566 -20Q427 -20 327 41T183 215T162 469L333 1456H386L216 469Q185 277 283 156T566 34Q760 34 901 158T1078 486L1245 1456H1299ZM1031 1854L1099 1853L870 1590L808 1591L1031
-1854Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1334" d="M1299 1456L1130 475Q1091 250 938 115T566 -20Q427 -20 327 41T183 215T162 469L333 1456H386L216 469Q185 277 283 156T566 34Q760 34 901 158T1078 486L1245 1456H1299ZM1096 1593L1095 1583L1029 1582L883 1778L669
-1584H604L605 1598L866 1836H906L1096 1593Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1334" d="M1299 1456L1130 475Q1091 250 938 115T566 -20Q427 -20 327 41T183 215T162 469L333 1456H386L216 469Q185 277 283 156T566 34Q760 34 901 158T1078 486L1245 1456H1299ZM603 1741Q606 1762 624 1779T664 1796Q687
-1796 701 1779T713 1739Q710 1718 691 1702T651 1685Q628 1685 614 1702T603 1741ZM1035 1741Q1038 1762 1056 1779T1096 1796Q1119 1796 1133 1779T1144 1739Q1141 1718 1123 1702T1083 1685Q1060 1685 1046 1702T1035 1741Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1196" d="M589 604L1231 1455L1299 1454L609 549L515 0H461L557 558L179 1457H248L589 604ZM943 1843L1011 1842L782 1579L720 1580L943 1843Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1192" d="M395 1456L341 1143H696Q888 1139 992 1028T1068 738Q1040 559 900 447T551 334H202L144 0H90L341 1456H395ZM333 1089L211 388H552Q726 388 855 484T1013 736Q1041 889 953 987T696 1089H333Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1158" d="M109 0H55L249 1126Q283 1322 384 1428T635 1535Q756 1535 834 1454T895 1257Q888 1210 870 1168T797 1035T727 908T705 829Q693 766 725 707T841 573T957 432T979 297Q958 164 837 72T572 -21Q485 -21 406 2T279
-69L309 116Q360 73 428 53T563 32Q690 32 797 110T927 306Q940 373 907 435T793 566T677 698T652 831Q660 883 680 930T748 1058T812 1178T836 1259Q852 1347 794 1413T646 1481Q517 1483 428 1396T307 1143L109 0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850
-1009T915 760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33ZM719 1269H663L511 1537H574L719 1269Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850
-1009T915 760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33ZM859 1535L927 1534L698 1271L636 1272L859 1535Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850
-1009T915 760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33ZM924 1274L923 1264L857 1263L711 1459L497 1265H432L433 1279L694 1517H734L924 1274Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850
-1009T915 760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33ZM1028 1485Q1009 1399 956 1350T832 1300Q790 1300 760 1319T701 1362T642 1405T573 1424Q468 1424 433 1301H378Q393
-1379 446 1429T573 1479Q614 1479 645 1459T704 1417T762 1376T832 1356Q884 1356 920 1391T973 1485H1028Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850
-1009T915 760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33ZM431 1422Q434 1443 452 1460T492 1477Q515 1477 529 1460T541 1420Q538 1399 519 1383T479 1366Q456 1366 442
-1383T431 1422ZM863 1422Q866 1443 884 1460T924 1477Q947 1477 961 1460T972 1420Q969 1399 951 1383T911 1366Q888 1366 874 1383T863 1422Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1059" d="M750 0Q747 88 769 198Q685 95 570 37T319 -20Q183 -20 102 64T41 274Q66 427 210 513T577 604H834L863 762Q884 895 810 971T597 1048Q461 1048 351 976T213 785L159 787Q187 926 313 1014T597 1102Q762 1102 850
-1009T915 760L816 182L809 114Q804 61 813 9L812 0H750ZM318 33Q452 31 573 97T779 292L825 549H583Q381 545 250 472T94 270Q76 171 141 103T318 33ZM536 1382Q549 1458 606 1507T729 1556Q799 1556 839 1504T870 1381Q860 1312 805 1262T678 1212Q612 1212 569
-1261T536 1382ZM590 1338Q604 1267 679 1267Q732 1267 769 1301T817 1382Q821 1405 818 1427Q811 1462 787 1481T728 1501Q662 1501 620 1447T590 1338Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1693" d="M1138 -20Q1011 -20 918 45T790 230L787 216H789Q718 105 597 43T342 -20Q190 -20 107 65T45 284Q71 445 202 537T534 630H803L819 720Q830 785 825 845Q817 941 758 994T598 1048Q452 1048 346 973T210 772L158
-779Q188 927 310 1014T598 1102Q729 1102 804 1024T878 814Q956 947 1069 1024T1308 1102Q1441 1102 1526 1029T1631 827Q1643 746 1629 661L1614 577H854L851 564L838 500Q822 415 829 331Q841 192 921 113T1137 34Q1321 34 1484 164L1509 120Q1351 -20 1138 -20ZM341
-32Q454 32 566 85T732 225L794 575H536Q363 575 244 496T99 280Q78 170 144 101T341 32ZM1308 1048Q1161 1048 1044 939T861 632H1567L1574 664Q1588 737 1580 807Q1565 920 1493 984T1308 1048Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1018" d="M430 34Q572 34 676 115T816 327H870Q834 172 713 76T431 -20Q282 -20 190 72T78 329Q67 424 81 520L87 562Q113 721 186 847T364 1037T595 1102Q758 1102 851 996T933 725H879Q892 869 813 958T596 1048Q407 1048
-282 894T130 480L126 407Q126 231 205 133T430 34ZM463 -9L438 -86L472 -93Q602 -129 583 -254Q571 -337 493 -387T272 -444L273 -395Q374 -392 444 -355T528 -254Q548 -159 422 -138L366 -129L410 -9H463Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1011" d="M458 -20Q328 -20 234 53T99 252T77 518L85 568Q109 714 187 841T374 1035T605 1102Q769 1102 862 981T941 671L938 640L929 577H143L132 518Q118 434 131 348Q153 205 240 120T457 33Q644 31 794 181L830 153Q682
--20 458 -20ZM605 1048Q451 1048 330 933T149 631H879L882 644Q895 716 884 788Q866 906 791 977T605 1048ZM698 1268H642L490 1536H553L698 1268Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1011" d="M458 -20Q328 -20 234 53T99 252T77 518L85 568Q109 714 187 841T374 1035T605 1102Q769 1102 862 981T941 671L938 640L929 577H143L132 518Q118 434 131 348Q153 205 240 120T457 33Q644 31 794 181L830 153Q682
--20 458 -20ZM605 1048Q451 1048 330 933T149 631H879L882 644Q895 716 884 788Q866 906 791 977T605 1048ZM838 1534L906 1533L677 1270L615 1271L838 1534Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1011" d="M458 -20Q328 -20 234 53T99 252T77 518L85 568Q109 714 187 841T374 1035T605 1102Q769 1102 862 981T941 671L938 640L929 577H143L132 518Q118 434 131 348Q153 205 240 120T457 33Q644 31 794 181L830 153Q682
--20 458 -20ZM605 1048Q451 1048 330 933T149 631H879L882 644Q895 716 884 788Q866 906 791 977T605 1048ZM903 1273L902 1263L836 1262L690 1458L476 1264H411L412 1278L673 1516H713L903 1273Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1011" d="M458 -20Q328 -20 234 53T99 252T77 518L85 568Q109 714 187 841T374 1035T605 1102Q769 1102 862 981T941 671L938 640L929 577H143L132 518Q118 434 131 348Q153 205 240 120T457 33Q644 31 794 181L830 153Q682
--20 458 -20ZM605 1048Q451 1048 330 933T149 631H879L882 644Q895 716 884 788Q866 906 791 977T605 1048ZM410 1677Q413 1698 431 1715T471 1732Q494 1732 508 1715T520 1675Q517 1654 498 1638T458 1621Q435 1621 421 1638T410 1677ZM842 1677Q845 1698 863
-1715T903 1732Q926 1732 940 1715T951 1675Q948 1654 930 1638T890 1621Q867 1621 853 1638T842 1677Z" />
-<glyph unicode="&#xec;" horiz-adv-x="404" d="M126 0H72L258 1082H312L126 0ZM359 1246H303L151 1514H214L359 1246Z" />
-<glyph unicode="&#xed;" horiz-adv-x="404" d="M126 0H72L258 1082H312L126 0ZM498 1768L566 1767L337 1504L275 1505L498 1768Z" />
-<glyph unicode="&#xee;" horiz-adv-x="404" d="M126 0H72L258 1082H312L126 0ZM564 1251L563 1241L497 1240L351 1436L137 1242H72L73 1256L334 1494H374L564 1251Z" />
-<glyph unicode="&#xef;" horiz-adv-x="404" d="M126 0H72L258 1082H312L126 0ZM71 1399Q74 1420 92 1437T132 1454Q155 1454 169 1437T181 1397Q178 1376 159 1360T119 1343Q96 1343 82 1360T71 1399ZM503 1399Q506 1420 524 1437T564 1454Q587 1454 601 1437T612
-1397Q609 1376 591 1360T551 1343Q528 1343 514 1360T503 1399Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1158" d="M907 1307Q1054 1097 1040 796Q1035 697 1009 551Q964 295 830 138T514 -20Q391 -20 301 45T170 224T150 465Q186 686 320 819T645 953Q759 953 847 907T983 780Q1005 1079 858 1279L605 1149L583 1199L818 1321Q705
-1442 494 1528L520 1576Q741 1486 869 1349L1086 1461L1109 1411L907 1307ZM966 617L976 672Q949 776 859 835T645 895Q506 895 399 813T237 581T204 308Q227 183 311 111T518 38Q679 38 795 179T955 556L966 617Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1097" d="M256 830Q337 961 447 1031T674 1102Q798 1102 869 1038T951 853Q957 777 943 694L823 0H769L889 694Q901 764 899 832Q894 938 837 994T672 1049Q535 1047 409 943T237 693L117 0H63L249 1082H303L256 830ZM1029
-1483Q1010 1397 957 1348T833 1298Q791 1298 761 1317T702 1360T643 1403T574 1422Q469 1422 434 1299H379Q394 1377 447 1427T574 1477Q615 1477 646 1457T705 1415T763 1374T833 1354Q885 1354 921 1389T974 1483H1029Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1103" d="M80 562Q105 713 181 837T371 1031T620 1102Q730 1102 815 1053T950 908T1007 694Q1010 626 995 520Q970 369 894 244T704 50T456 -20Q345 -20 261 29T126 174T69 389Q65 456 80 562ZM127 348Q147 203 234 119T455
-34Q612 34 738 144T921 441Q967 596 948 734Q926 879 840 963T621 1048Q464 1048 337 937T154 641Q108 488 127 348ZM697 1267H641L489 1535H552L697 1267Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1103" d="M80 562Q105 713 181 837T371 1031T620 1102Q730 1102 815 1053T950 908T1007 694Q1010 626 995 520Q970 369 894 244T704 50T456 -20Q345 -20 261 29T126 174T69 389Q65 456 80 562ZM127 348Q147 203 234 119T455
-34Q612 34 738 144T921 441Q967 596 948 734Q926 879 840 963T621 1048Q464 1048 337 937T154 641Q108 488 127 348ZM837 1533L905 1532L676 1269L614 1270L837 1533Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1103" d="M80 562Q105 713 181 837T371 1031T620 1102Q730 1102 815 1053T950 908T1007 694Q1010 626 995 520Q970 369 894 244T704 50T456 -20Q345 -20 261 29T126 174T69 389Q65 456 80 562ZM127 348Q147 203 234 119T455
-34Q612 34 738 144T921 441Q967 596 948 734Q926 879 840 963T621 1048Q464 1048 337 937T154 641Q108 488 127 348ZM902 1272L901 1262L835 1261L689 1457L475 1263H410L411 1277L672 1515H712L902 1272Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1103" d="M80 562Q105 713 181 837T371 1031T620 1102Q730 1102 815 1053T950 908T1007 694Q1010 626 995 520Q970 369 894 244T704 50T456 -20Q345 -20 261 29T126 174T69 389Q65 456 80 562ZM127 348Q147 203 234 119T455
-34Q612 34 738 144T921 441Q967 596 948 734Q926 879 840 963T621 1048Q464 1048 337 937T154 641Q108 488 127 348ZM1006 1483Q987 1397 934 1348T810 1298Q768 1298 738 1317T679 1360T620 1403T551 1422Q446 1422 411 1299H356Q371 1377 424 1427T551 1477Q592
-1477 623 1457T682 1415T740 1374T810 1354Q862 1354 898 1389T951 1483H1006Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1103" d="M80 562Q105 713 181 837T371 1031T620 1102Q730 1102 815 1053T950 908T1007 694Q1010 626 995 520Q970 369 894 244T704 50T456 -20Q345 -20 261 29T126 174T69 389Q65 456 80 562ZM127 348Q147 203 234 119T455
-34Q612 34 738 144T921 441Q967 596 948 734Q926 879 840 963T621 1048Q464 1048 337 937T154 641Q108 488 127 348ZM409 1676Q412 1697 430 1714T470 1731Q493 1731 507 1714T519 1674Q516 1653 497 1637T457 1620Q434 1620 420 1637T409 1676ZM841 1676Q844 1697
-862 1714T902 1731Q925 1731 939 1714T950 1674Q947 1653 929 1637T889 1620Q866 1620 852 1637T841 1676Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1134" d="M1056 686H86L93 738H1063L1056 686ZM596 1081Q599 1101 617 1118T657 1135Q680 1135 694 1117T705 1077Q702 1057 683 1041T643 1024Q620 1025 606 1042T596 1081ZM461 303Q464 323 482 340T522 357Q545 357 559
-339T570 299Q567 279 548 263T508 246Q485 247 471 264T461 303Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1097" d="M626 1102Q739 1102 834 1047L948 1218L1012 1217L880 1015Q1008 893 1008 685Q1008 623 999 562L992 524Q945 278 795 129T444 -20Q340 -20 249 28L135 -144L70 -143L202 57Q63 174 62 394Q60 523 100 655T218
-888T399 1045T626 1102ZM125 520Q116 465 115 409Q113 319 143 240T229 107L806 996Q726 1048 627 1048Q450 1048 311 909T130 547L125 520ZM945 562Q954 615 954 669Q954 851 850 963L275 76Q349 34 443 34Q620 34 758 172T940 535L945 562Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1097" d="M766 0L800 175Q729 77 628 29T406 -20Q280 -20 207 47T121 238Q114 317 128 401L245 1082H299L180 393Q169 325 173 261Q178 153 238 94T404 34Q550 34 667 113T821 321L952 1082H1007L821 0H766ZM722 1269H666L514
-1537H577L722 1269Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1097" d="M766 0L800 175Q729 77 628 29T406 -20Q280 -20 207 47T121 238Q114 317 128 401L245 1082H299L180 393Q169 325 173 261Q178 153 238 94T404 34Q550 34 667 113T821 321L952 1082H1007L821 0H766ZM862 1535L930
-1534L701 1271L639 1272L862 1535Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1097" d="M766 0L800 175Q729 77 628 29T406 -20Q280 -20 207 47T121 238Q114 317 128 401L245 1082H299L180 393Q169 325 173 261Q178 153 238 94T404 34Q550 34 667 113T821 321L952 1082H1007L821 0H766ZM927 1274L926
-1264L860 1263L714 1459L500 1265H435L436 1279L697 1517H737L927 1274Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1097" d="M766 0L800 175Q729 77 628 29T406 -20Q280 -20 207 47T121 238Q114 317 128 401L245 1082H299L180 393Q169 325 173 261Q178 153 238 94T404 34Q550 34 667 113T821 321L952 1082H1007L821 0H766ZM434 1422Q437
-1443 455 1460T495 1477Q518 1477 532 1460T544 1420Q541 1399 522 1383T482 1366Q459 1366 445 1383T434 1422ZM866 1422Q869 1443 887 1460T927 1477Q950 1477 964 1460T975 1420Q972 1399 954 1383T914 1366Q891 1366 877 1383T866 1422Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="959" d="M396 84L406 105L939 1081H1000L316 -182Q242 -322 166 -378T-3 -437Q-41 -437 -83 -426L-77 -375Q-26 -384 -9 -384Q124 -384 221 -236L261 -170L358 11L124 1083H181L396 84ZM803 1535L871 1534L642 1271L580 1272L803
-1535Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1097" d="M473 -20Q358 -20 272 30T146 168L43 -416H-11L326 1536H380L264 889Q335 985 434 1043T656 1102Q761 1102 835 1050T943 898T974 675Q971 611 962 552L949 486Q897 251 771 116T473 -20ZM907 552L919 659Q929 849
-860 948T657 1048Q525 1048 408 970T250 775L160 269Q183 156 267 95T473 34Q635 34 747 166T904 535L907 552Z" />
-<glyph unicode="&#xff;" horiz-adv-x="959" d="M396 84L406 105L939 1081H1000L316 -182Q242 -322 166 -378T-3 -437Q-41 -437 -83 -426L-77 -375Q-26 -384 -9 -384Q124 -384 221 -236L261 -170L358 11L124 1083H181L396 84ZM375 1422Q378 1443 396 1460T436 1477Q459
-1477 473 1460T485 1420Q482 1399 463 1383T423 1366Q400 1366 386 1383T375 1422ZM807 1422Q810 1443 828 1460T868 1477Q891 1477 905 1460T916 1420Q913 1399 895 1383T855 1366Q832 1366 818 1383T807 1422Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1294" d="M1407 721H434L442 775H1416L1407 721Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1524" d="M1440 721H142L153 775H1451L1440 721Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="320" d="M364 1554L398 1520Q292 1404 269 1273L250 1168H197L214 1272Q243 1439 364 1554Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="320" d="M209 1151L175 1185Q282 1305 304 1431L322 1536H376L359 1433Q329 1265 209 1151Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="301" d="M-51 -182L-85 -148Q19 -31 44 98L66 228H120L99 100Q69 -68 -51 -182Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="495" d="M615 1554L649 1520Q543 1404 520 1273L501 1168H448L465 1272Q494 1439 615 1554ZM539 1554L573 1520Q467 1404 444 1273L425 1168H372L389 1272Q418 1439 539 1554Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="497" d="M209 1151L175 1185Q282 1305 304 1431L322 1536H376L359 1433Q329 1265 209 1151ZM386 1151L352 1185Q459 1305 481 1431L499 1536H553L536 1433Q506 1265 386 1151Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="477" d="M-51 -182L-85 -148Q19 -31 44 98L66 228H120L99 100Q69 -68 -51 -182ZM115 -182L81 -148Q185 -31 210 98L232 228H286L265 100Q235 -68 115 -182Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="626" d="M176 733Q191 806 243 849T362 893Q433 893 472 847T503 733L498 703Q484 633 433 589T312 545Q242 545 203 588T172 703L176 733Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="596" d="M167 556L388 180H321L96 551L98 570L447 939L519 938L167 556Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="596" d="M227 941L450 560L447 541L100 172L28 173L379 554L161 941H227Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-100italic.ttf b/static/fonts/roboto-v18-latin-100italic.ttf
deleted file mode 100644
index 5538b7e1ad..0000000000
Binary files a/static/fonts/roboto-v18-latin-100italic.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100italic.woff b/static/fonts/roboto-v18-latin-100italic.woff
deleted file mode 100644
index b8aabdfe58..0000000000
Binary files a/static/fonts/roboto-v18-latin-100italic.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-100italic.woff2 b/static/fonts/roboto-v18-latin-100italic.woff2
deleted file mode 100644
index 2a25bd1a77..0000000000
Binary files a/static/fonts/roboto-v18-latin-100italic.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300.eot b/static/fonts/roboto-v18-latin-300.eot
deleted file mode 100644
index 17b7d5cd25..0000000000
Binary files a/static/fonts/roboto-v18-latin-300.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300.svg b/static/fonts/roboto-v18-latin-300.svg
deleted file mode 100644
index 4ded944a8b..0000000000
--- a/static/fonts/roboto-v18-latin-300.svg
+++ /dev/null
@@ -1,312 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1135" ><font-face
-    font-family="Roboto Light"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="498" />
-<glyph unicode="!" horiz-adv-x="462" d="M284 405H173L167 1456H291L284 405ZM153 70Q153 104 175 127T235 151T295 128T318 70Q318 37 296 15T235 -8T175 14T153 70Z" />
-<glyph unicode="&quot;" horiz-adv-x="588" d="M243 1396L223 1083H143L146 1536H243V1396ZM479 1396L459 1083H378L382 1536H479V1396Z" />
-<glyph unicode="#" horiz-adv-x="1191" d="M753 410H439L362 0H263L340 410H85V503H357L440 944H161V1040H458L537 1456H636L557 1040H872L951 1456H1051L972 1040H1201V944H954L871 503H1126V410H853L776 0H676L753 410ZM456 503H771L854 944H539L456 503Z" />
-<glyph unicode="$" d="M901 359Q901 470 829 540T575 674Q349 745 258 842T167 1095Q167 1258 267 1359T539 1475V1677H641V1475Q817 1459 913 1343T1010 1028H891Q891 1185 810 1277T587 1370Q445 1370 366 1296T286 1097Q286 977 359 910T607 783T862 669T981
-540T1021 361Q1021 197 919 97T637 -18V-208H536V-19Q335 -6 225 107T115 418H235Q235 262 326 174T580 85Q722 85 811 161T901 359Z" />
-<glyph unicode="%" horiz-adv-x="1513" d="M109 1176Q109 1306 189 1391T394 1477T598 1392T679 1170V1099Q679 971 600 886T396 800Q273 800 191 884T109 1106V1176ZM206 1099Q206 1006 257 946T396 886Q481 886 531 946T582 1103V1176Q582 1269 530 1329T394
-1390Q311 1390 259 1330T206 1170V1099ZM842 357Q842 487 922 572T1126 657T1330 573T1412 350V279Q1412 149 1332 64T1128 -21T924 63T842 284V357ZM938 279Q938 185 989 125T1128 65Q1214 65 1264 125T1315 284V357Q1315 453 1264 511T1126 570Q1042 570 990
-511T938 353V279ZM434 121L359 169L1070 1307L1145 1259L434 121Z" />
-<glyph unicode="&amp;" horiz-adv-x="1260" d="M404 794Q317 899 278 981T238 1145Q238 1298 329 1387T573 1476Q712 1476 798 1396T884 1191Q884 1047 718 908L558 784L958 318Q1049 465 1049 651H1160Q1160 403 1032 232L1231 0H1087L961 146Q882 68 779 24T560
--20Q352 -20 230 86T108 371Q108 477 170 571T390 784L404 794ZM560 81Q651 81 736 119T890 229L483 701L469 716L423 681Q227 521 227 371Q227 240 317 161T560 81ZM358 1149Q358 1027 493 861L624 961Q688 1007 729 1062T770 1191Q770 1269 716 1321T572 1374Q474
-1374 416 1311T358 1149Z" />
-<glyph unicode="&apos;" horiz-adv-x="348" d="M226 1395L209 1090H119Q124 1386 124 1536H226V1395Z" />
-<glyph unicode="(" horiz-adv-x="653" d="M140 588Q140 806 196 1011T360 1387T592 1632L621 1551Q555 1504 490 1414T374 1200T292 922T260 571Q260 362 307 169T438 -171T621 -393L592 -470Q465 -394 357 -225T195 148T140 588Z" />
-<glyph unicode=")" horiz-adv-x="667" d="M514 573Q514 353 460 150T298 -223T62 -470L33 -393Q131 -323 214 -176T346 166T394 591Q394 798 346 990T214 1334T33 1555L62 1632Q188 1555 295 1386T458 1011T514 573Z" />
-<glyph unicode="*" horiz-adv-x="869" d="M361 1000L29 1108L61 1209L393 1086L389 1456H493L485 1083L809 1210L842 1109L509 994L732 700L647 637L433 942L229 639L144 700L361 1000Z" />
-<glyph unicode="+" horiz-adv-x="1156" d="M630 740H1073V628H630V146H509V628H75V740H509V1206H630V740Z" />
-<glyph unicode="," horiz-adv-x="392" d="M131 -272L60 -220Q151 -98 154 33V188H271V63Q271 -145 131 -272Z" />
-<glyph unicode="-" horiz-adv-x="586" d="M528 592H49V693H528V592Z" />
-<glyph unicode="." horiz-adv-x="489" d="M145 72Q145 107 167 131T230 156T293 132T316 72T293 15T230 -8T168 14T145 72Z" />
-<glyph unicode="/" horiz-adv-x="813" d="M139 -125H30L638 1456H746L139 -125Z" />
-<glyph unicode="0" d="M1015 607Q1015 299 902 140T569 -20Q353 -20 238 136T120 592V853Q120 1160 234 1318T567 1476Q783 1476 897 1324T1015 874V607ZM895 868Q895 1118 814 1246T567 1374Q405 1374 323 1249T239 880V594Q239 345 323 213T569 81Q729 81 811
-210T895 588V868Z" />
-<glyph unicode="1" d="M694 0H574V1312L178 1165V1277L674 1461H694V0Z" />
-<glyph unicode="2" d="M1049 0H137V92L636 658Q760 801 808 894T856 1075Q856 1213 775 1293T552 1374Q405 1374 315 1280T224 1036H105Q105 1159 160 1260T318 1418T552 1476Q752 1476 864 1371T977 1085Q977 983 914 862T690 560L284 101H1049V0Z" />
-<glyph unicode="3" d="M403 793H527Q630 793 707 829T824 929T865 1076Q865 1216 786 1295T559 1374Q419 1374 330 1292T240 1074H120Q120 1187 177 1280T335 1425T559 1476Q757 1476 871 1368T985 1072Q985 967 919 879T736 746Q872 708 942 616T1012 395Q1012
-208 890 94T564 -20Q434 -20 326 32T158 177T98 395H218Q218 256 315 169T564 81Q719 81 805 160T892 391Q892 537 799 614T523 691H403V793Z" />
-<glyph unicode="4" d="M872 469H1099V368H872V0H752V368H67V436L741 1456H872V469ZM214 469H752V1301L699 1209L214 469Z" />
-<glyph unicode="5" d="M218 746L289 1456H1017V1345H392L341 853Q458 933 615 933Q812 933 929 805T1046 464Q1046 234 932 107T611 -20Q421 -20 303 86T168 383H283Q300 234 384 158T611 81Q767 81 846 180T926 462Q926 622 837 723T594 824Q509 824 446 803T313
-719L218 746Z" />
-<glyph unicode="6" d="M843 1467V1362H829Q568 1362 418 1209T252 782Q312 865 405 910T613 956Q805 956 918 824T1032 477Q1032 335 979 221T827 44T601 -20Q392 -20 261 131T130 523V643Q130 1034 308 1248T813 1467H843ZM594 853Q480 853 382 786T250 614V512Q250
-322 347 202T601 82Q741 82 827 193T914 473Q914 645 828 749T594 853Z" />
-<glyph unicode="7" d="M1034 1387L412 0H287L905 1354H77V1456H1034V1387Z" />
-<glyph unicode="8" d="M995 1081Q995 968 929 879T755 747Q881 704 957 608T1033 386Q1033 199 906 90T570 -20Q359 -20 233 89T106 386Q106 510 179 607T379 747Q271 789 207 878T143 1081Q143 1262 259 1369T568 1476T877 1368T995 1081ZM913 385Q913 521 816
-608T568 696T321 610T225 385T318 164T570 81Q725 81 819 163T913 385ZM875 1082Q875 1207 789 1290T568 1374Q432 1374 348 1294T263 1082Q263 954 347 876T569 798Q704 798 789 876T875 1082Z" />
-<glyph unicode="9" d="M884 674Q820 580 725 529T519 477Q395 477 300 541T153 718T101 965Q101 1109 156 1227T311 1410T541 1476Q760 1476 882 1323T1004 887V779Q1004 385 836 187T323 -11H301L302 93H344Q605 97 741 241T884 674ZM534 580Q654 580 749 651T885
-837V906Q885 1128 793 1250T543 1373Q401 1373 310 1259T219 970Q219 803 306 692T534 580Z" />
-<glyph unicode=":" horiz-adv-x="430" d="M383 72Q383 107 405 131T468 156T531 132T554 72T531 15T468 -8T406 14T383 72ZM129 995Q129 1030 151 1054T214 1079T277 1055T300 995T277 938T214 915T152 937T129 995Z" />
-<glyph unicode=";" horiz-adv-x="399" d="M118 995Q118 1030 140 1054T203 1079T266 1055T289 995T266 938T203 915T141 937T118 995ZM131 -272L60 -220Q151 -98 154 33V188H271V63Q271 -145 131 -272Z" />
-<glyph unicode="&lt;" horiz-adv-x="1047" d="M208 655L904 355V229L77 608V705L904 1083V957L208 655Z" />
-<glyph unicode="=" horiz-adv-x="1133" d="M983 829H149V935H983V829ZM983 418H149V524H983V418Z" />
-<glyph unicode="&gt;" horiz-adv-x="1061" d="M835 659L124 962V1085L969 707V610L124 231V355L835 659Z" />
-<glyph unicode="?" horiz-adv-x="930" d="M376 404Q378 522 408 594T537 763T664 901T708 990T724 1101Q724 1226 658 1297T472 1369Q352 1369 279 1301T203 1115H84Q86 1279 195 1377T472 1476Q644 1476 743 1376T843 1103Q843 995 794 901T608 680Q495 585 495
-404H376ZM360 70Q360 104 381 127T442 151Q480 151 502 128T525 70Q525 37 503 15T442 -8Q403 -8 382 14T360 70Z" />
-<glyph unicode="@" horiz-adv-x="1870" d="M1754 513Q1749 366 1700 241T1565 48T1364 -20Q1267 -20 1206 31T1125 174Q1017 -20 827 -20Q687 -20 618 101T567 427Q582 590 641 717T796 916T1001 988Q1078 988 1136 967T1271 880L1220 310Q1210 194 1249 130T1376
-66Q1499 66 1575 186T1661 513Q1680 918 1507 1122T983 1327Q772 1327 603 1222T335 923T225 478T291 35T528 -260T906 -363Q998 -363 1087 -341T1236 -284L1267 -364Q1210 -402 1108 -427T902 -453Q652 -453 472 -341T203 -17T125 478Q137 756 247 970T550 1302T987
-1420Q1242 1420 1419 1314T1681 1002T1754 513ZM673 286Q684 186 729 132T848 77Q1033 77 1121 332L1166 848Q1099 897 1008 897Q897 897 816 809T696 565T673 286Z" />
-<glyph unicode="A" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513Z" />
-<glyph unicode="B" horiz-adv-x="1255" d="M184 0V1456H614Q848 1456 969 1360T1090 1075Q1090 962 1029 879T860 759Q987 731 1064 634T1142 410Q1142 217 1018 109T671 0H184ZM307 700V104H676Q834 104 926 184T1019 408Q1019 543 931 621T686 700H307ZM307
-803H643Q797 806 881 875T966 1078Q966 1218 879 1284T614 1351H307V803Z" />
-<glyph unicode="C" horiz-adv-x="1330" d="M1215 454Q1190 224 1051 102T679 -20Q517 -20 393 61T200 290T131 630V819Q131 1013 199 1163T394 1394T688 1476Q922 1476 1057 1350T1215 1000H1091Q1045 1371 688 1371Q490 1371 373 1223T255 814V636Q255 384 369
-234T679 84Q872 84 970 176T1091 454H1215Z" />
-<glyph unicode="D" horiz-adv-x="1341" d="M184 0V1456H591Q770 1456 912 1375T1133 1141T1213 795V661Q1213 466 1134 315T912 82T582 0H184ZM307 1351V104H583Q813 104 952 256T1091 669V797Q1091 1048 954 1199T593 1351H307Z" />
-<glyph unicode="E" horiz-adv-x="1165" d="M988 698H307V104H1090V0H184V1456H1085V1351H307V802H988V698Z" />
-<glyph unicode="F" horiz-adv-x="1152" d="M986 680H307V0H184V1456H1086V1351H307V785H986V680Z" />
-<glyph unicode="G" horiz-adv-x="1400" d="M1235 173Q1171 82 1035 31T729 -20Q558 -20 425 62T219 294T145 638V822Q145 1125 298 1300T709 1476Q934 1476 1071 1362T1234 1046H1111Q1084 1206 981 1288T710 1371Q506 1371 387 1226T268 817V645Q268 479 324
-352T486 154T729 84Q888 84 1002 134Q1076 167 1112 211V587H721V691H1235V173Z" />
-<glyph unicode="H" horiz-adv-x="1449" d="M1263 0H1139V698H307V0H184V1456H307V802H1139V1456H1263V0Z" />
-<glyph unicode="I" horiz-adv-x="545" d="M334 0H211V1456H334V0Z" />
-<glyph unicode="J" horiz-adv-x="1127" d="M827 1456H951V433Q951 226 832 103T511 -20Q299 -20 185 91T71 401H194Q194 243 277 164T511 84Q650 84 737 176T827 426V1456Z" />
-<glyph unicode="K" horiz-adv-x="1292" d="M512 723L307 521V0H184V1456H307V671L1053 1456H1208L598 808L1255 0H1105L512 723Z" />
-<glyph unicode="L" horiz-adv-x="1079" d="M308 104H1027V0H184V1456H308V104Z" />
-<glyph unicode="M" horiz-adv-x="1772" d="M347 1456L884 171L1423 1456H1587V0H1464V634L1474 1284L932 0H837L297 1279L307 638V0H184V1456H347Z" />
-<glyph unicode="N" horiz-adv-x="1454" d="M1268 0H1145L308 1246V0H184V1456H308L1146 209V1456H1268V0Z" />
-<glyph unicode="O" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q439 -20 282 162T125 655V805Q125 1004 195 1157T395 1393T692 1476T988 1395T1187 1166T1260 823V649ZM1137 807Q1137 1070 1018 1219T692 1368Q489 1368 369 1219T248
-801V649Q248 390 368 239T694 87Q903 87 1020 236T1137 653V807Z" />
-<glyph unicode="P" horiz-adv-x="1261" d="M307 593V0H184V1456H680Q907 1456 1038 1340T1170 1021Q1170 816 1044 705T677 593H307ZM307 697H680Q859 697 953 782T1047 1019Q1047 1170 954 1259T688 1351H307V697Z" />
-<glyph unicode="Q" horiz-adv-x="1386" d="M1256 649Q1256 441 1183 287T973 53L1238 -178L1153 -254L856 3Q774 -20 689 -20Q523 -20 394 62T193 294T121 642V805Q121 1004 191 1157T391 1393T687 1476Q857 1476 986 1394T1185 1159T1256 806V649ZM1133 807Q1133
-1070 1014 1219T687 1368Q485 1368 365 1219T244 801V649Q244 390 363 239T689 87Q897 87 1015 236T1133 652V807Z" />
-<glyph unicode="R" horiz-adv-x="1300" d="M728 606H305V0H181V1456H654Q887 1456 1018 1343T1149 1027Q1149 887 1067 780T847 632L1211 13V0H1080L728 606ZM305 711H682Q837 711 931 799T1025 1027Q1025 1181 927 1266T652 1351H305V711Z" />
-<glyph unicode="S" horiz-adv-x="1213" d="M1008 358Q1008 479 923 549T612 683T282 822Q134 928 134 1100Q134 1267 271 1371T623 1476Q768 1476 882 1420T1060 1264T1123 1041H999Q999 1190 897 1280T623 1371Q456 1371 357 1297T258 1102Q258 991 347 921T632
-798T929 687T1081 549T1132 360Q1132 188 995 84T632 -20Q478 -20 350 35T155 189T88 416H211Q211 262 326 173T632 84Q802 84 905 159T1008 358Z" />
-<glyph unicode="T" horiz-adv-x="1223" d="M1172 1351H673V0H550V1351H52V1456H1172V1351Z" />
-<glyph unicode="U" horiz-adv-x="1346" d="M1187 1456V462Q1186 315 1122 206T942 39T674 -20Q444 -20 306 105T162 453V1456H284V471Q284 287 389 186T674 84T958 186T1063 470V1456H1187Z" />
-<glyph unicode="V" horiz-adv-x="1263" d="M623 180L631 149L640 180L1098 1456H1233L691 0H573L31 1456H165L623 180Z" />
-<glyph unicode="W" horiz-adv-x="1836" d="M453 393L498 167L553 383L869 1456H980L1292 383L1346 165L1394 393L1657 1456H1783L1410 0H1292L962 1139L925 1283L889 1139L551 0H433L61 1456H187L453 393Z" />
-<glyph unicode="X" horiz-adv-x="1253" d="M627 840L1037 1456H1184L702 738L1199 0H1051L627 636L201 0H55L553 738L70 1456H217L627 840Z" />
-<glyph unicode="Y" horiz-adv-x="1226" d="M611 662L1056 1456H1198L672 548V0H549V548L24 1456H170L611 662Z" />
-<glyph unicode="Z" horiz-adv-x="1225" d="M239 104H1138V0H90V93L954 1351H116V1456H1106V1368L239 104Z" />
-<glyph unicode="[" horiz-adv-x="491" d="M493 1562H283V-210H493V-312H163V1664H493V1562Z" />
-<glyph unicode="\" horiz-adv-x="807" d="M48 1456H165L773 -125H656L48 1456Z" />
-<glyph unicode="]" horiz-adv-x="491" d="M0 1664H331V-312H0V-210H211V1562H0V1664Z" />
-<glyph unicode="^" horiz-adv-x="852" d="M421 1298L193 729H77L376 1456H466L764 729H648L421 1298Z" />
-<glyph unicode="_" horiz-adv-x="884" d="M882 -101H1V0H882V-101Z" />
-<glyph unicode="`" horiz-adv-x="585" d="M438 1256H329L103 1536H247L438 1256Z" />
-<glyph unicode="a" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826 1012T934
-759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86Z" />
-<glyph unicode="b" d="M1027 530Q1027 277 915 129T614 -20Q388 -20 272 148L267 0H155V1536H274V925Q388 1102 612 1102Q804 1102 915 956T1027 548V530ZM907 551Q907 765 824 881T590 998Q475 998 395 942T274 776V288Q364 84 592 84Q740 84 823 201T907 551Z" />
-<glyph unicode="c" horiz-adv-x="1055" d="M556 81Q681 81 765 151T857 334H972Q967 235 910 154T759 26T556 -20Q343 -20 219 128T94 526V562Q94 722 150 845T310 1035T555 1102Q733 1102 848 996T972 717H857Q849 844 766 922T555 1000Q393 1000 304 883T214
-555V520Q214 313 303 197T556 81Z" />
-<glyph unicode="d" horiz-adv-x="1138" d="M108 551Q108 803 220 952T526 1102Q745 1102 860 929V1536H979V0H867L862 144Q747 -20 524 -20Q337 -20 223 130T108 537V551ZM229 530Q229 323 312 204T546 84Q767 84 860 279V787Q767 998 548 998Q397 998 313 880T229 530Z" />
-<glyph unicode="e" horiz-adv-x="1058" d="M575 -20Q437 -20 326 48T152 237T90 510V553Q90 709 150 834T319 1030T553 1102Q750 1102 865 968T981 600V533H209V510Q209 326 314 204T580 81Q676 81 749 116T883 228L958 171Q826 -20 575 -20ZM553 1000Q418 1000
-326 901T213 635H862V648Q857 804 773 902T553 1000Z" />
-<glyph unicode="f" horiz-adv-x="678" d="M242 0V984H63V1082H242V1213Q242 1379 326 1468T562 1557Q630 1557 689 1540L680 1440Q630 1452 571 1452Q472 1452 417 1391T362 1216V1082H620V984H362V0H242Z" />
-<glyph unicode="g" horiz-adv-x="1136" d="M108 551Q108 805 220 953T526 1102Q747 1102 862 926L868 1082H980V22Q980 -187 863 -309T546 -431Q433 -431 331 -381T169 -246L236 -174Q363 -330 538 -330Q688 -330 772 -242T859 4V140Q744 -20 524 -20Q336 -20
-222 130T108 535V551ZM229 530Q229 323 312 204T546 84Q767 84 859 282V785Q817 889 738 943T548 998Q397 998 313 880T229 530Z" />
-<glyph unicode="h" horiz-adv-x="1124" d="M275 899Q334 996 426 1049T627 1102Q801 1102 886 1004T972 710V0H853V711Q852 856 792 927T598 998Q487 998 402 929T275 741V0H156V1536H275V899Z" />
-<glyph unicode="i" horiz-adv-x="459" d="M290 0H170V1082H290V0ZM149 1395Q149 1429 171 1452T231 1476T291 1453T314 1395T292 1338T231 1315T171 1338T149 1395Z" />
-<glyph unicode="j" horiz-adv-x="467" d="M285 1082V-129Q285 -279 213 -358T1 -437Q-53 -437 -104 -418L-102 -319Q-58 -332 -12 -332Q166 -332 166 -127V1082H285ZM226 1476Q265 1476 287 1453T309 1395T287 1338T226 1315Q188 1315 167 1338T145 1395T166 1452T226
-1476Z" />
-<glyph unicode="k" horiz-adv-x="1003" d="M413 545L276 413V0H156V1536H276V553L389 675L803 1082H954L495 626L994 0H851L413 545Z" />
-<glyph unicode="l" horiz-adv-x="459" d="M290 0H170V1536H290V0Z" />
-<glyph unicode="m" horiz-adv-x="1815" d="M265 1082L269 906Q329 1004 419 1053T619 1102Q875 1102 944 892Q1002 993 1099 1047T1313 1102Q1661 1102 1668 722V0H1548V713Q1547 858 1486 928T1285 998Q1156 996 1067 915T968 716V0H848V722Q847 861 783 929T584
-998Q471 998 390 934T270 742V0H150V1082H265Z" />
-<glyph unicode="n" horiz-adv-x="1125" d="M270 1082L274 897Q335 997 426 1049T627 1102Q801 1102 886 1004T972 710V0H853V711Q852 856 792 927T598 998Q487 998 402 929T275 741V0H156V1082H270Z" />
-<glyph unicode="o" horiz-adv-x="1147" d="M90 557Q90 713 150 838T321 1032T572 1102Q788 1102 922 951T1056 549V524Q1056 367 996 242T825 48T574 -20Q359 -20 225 131T90 533V557ZM210 524Q210 330 310 206T574 81Q736 81 836 205T937 534V557Q937 681 891
-784T762 943T572 1000Q412 1000 311 875T210 546V524Z" />
-<glyph unicode="p" d="M1026 530Q1026 277 914 129T614 -20Q392 -20 274 136V-416H155V1082H266L272 929Q389 1102 611 1102Q805 1102 915 955T1026 547V530ZM906 551Q906 758 821 878T584 998Q474 998 395 945T274 791V272Q317 179 397 130T586 81Q737 81 821
-201T906 551Z" />
-<glyph unicode="q" horiz-adv-x="1142" d="M108 551Q108 805 220 953T528 1102Q747 1102 861 935L867 1082H979V-416H859V134Q741 -20 526 -20Q336 -20 222 130T108 535V551ZM229 530Q229 320 313 201T548 81Q763 81 859 268V798Q814 895 735 947T550 1000Q399
-1000 314 881T229 530Z" />
-<glyph unicode="r" horiz-adv-x="689" d="M656 980Q618 987 575 987Q463 987 386 925T275 743V0H156V1082H273L275 910Q370 1102 580 1102Q630 1102 659 1089L656 980Z" />
-<glyph unicode="s" horiz-adv-x="1037" d="M804 275Q804 364 733 418T517 502T294 572T176 669T137 807Q137 935 244 1018T518 1102Q699 1102 808 1013T918 779H798Q798 874 719 937T518 1000Q400 1000 329 948T257 811Q257 730 316 686T533 604T769 525T886 424T924
-281Q924 144 814 62T525 -20Q336 -20 219 71T101 303H221Q228 198 309 140T525 81Q650 81 727 136T804 275Z" />
-<glyph unicode="t" horiz-adv-x="658" d="M342 1359V1082H566V984H342V263Q342 173 374 129T483 85Q513 85 580 95L585 -3Q538 -20 457 -20Q334 -20 278 51T222 262V984H23V1082H222V1359H342Z" />
-<glyph unicode="u" horiz-adv-x="1125" d="M852 137Q744 -20 507 -20Q334 -20 244 80T152 378V1082H271V393Q271 84 521 84Q781 84 850 299V1082H970V0H854L852 137Z" />
-<glyph unicode="v" horiz-adv-x="985" d="M493 165L822 1082H945L541 0H444L38 1082H161L493 165Z" />
-<glyph unicode="w" horiz-adv-x="1544" d="M415 249L433 156L457 254L717 1082H819L1076 261L1104 147L1127 252L1349 1082H1473L1158 0H1056L778 858L765 917L752 857L479 0H377L63 1082H186L415 249Z" />
-<glyph unicode="x" horiz-adv-x="996" d="M496 643L788 1082H930L563 551L946 0H805L497 458L189 0H48L430 551L63 1082H204L496 643Z" />
-<glyph unicode="y" horiz-adv-x="973" d="M499 172L815 1082H944L482 -184L458 -240Q369 -437 183 -437Q140 -437 91 -423L90 -324L152 -330Q240 -330 294 -287T387 -137L440 9L32 1082H163L499 172Z" />
-<glyph unicode="z" horiz-adv-x="996" d="M235 101H938V0H87V88L743 979H107V1082H894V993L235 101Z" />
-<glyph unicode="{" horiz-adv-x="676" d="M637 -404Q469 -354 384 -241T299 59V280Q299 543 68 543V647Q299 647 299 908V1137Q300 1320 384 1433T637 1597L663 1518Q419 1440 419 1127V914Q419 668 235 595Q419 518 419 277V49Q423 -243 666 -324L637 -404Z" />
-<glyph unicode="|" horiz-adv-x="452" d="M279 -270H178V1456H279V-270Z" />
-<glyph unicode="}" horiz-adv-x="676" d="M9 -324Q252 -243 256 49V273Q256 526 449 594Q256 662 256 913V1126Q256 1442 12 1518L38 1597Q209 1546 292 1432T376 1131V908Q376 647 607 647V543Q376 543 376 280V59Q376 -128 291 -241T38 -404L9 -324Z" />
-<glyph unicode="~" horiz-adv-x="1402" d="M1254 764Q1254 615 1171 519T958 423Q886 423 824 450T670 558T535 659T441 680Q352 680 303 621T253 450L145 449Q145 598 226 692T441 787Q515 787 581 756T740 643Q807 580 855 555T958 529Q1046 529 1098 592T1150
-764H1254Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="498" />
-<glyph unicode="&#xa1;" horiz-adv-x="452" d="M174 690H285L292 -359H168L174 690ZM305 1022Q305 988 283 965T223 942T163 965T140 1022T162 1079T223 1102T283 1079T305 1022Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1115" d="M581 81Q704 81 788 150T882 334H997Q989 195 887 97T636 -17V-245H516V-16Q331 7 225 150T119 526V562Q119 784 224 929T516 1098V1318H636V1099Q791 1083 891 978T997 717H882Q874 844 791 922T580 1000Q418 1000
-329 883T239 555V520Q239 313 328 197T581 81Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1170" d="M404 645L413 368Q415 194 349 104H1094V0H97V104H195Q246 117 272 211Q292 285 290 367L281 645H93V749H277L268 1039Q268 1239 378 1357T674 1476Q856 1476 961 1371T1067 1088H944Q944 1223 869 1297T665 1371Q540
-1371 466 1283T392 1039L401 749H745V645H404Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1481" d="M1131 133Q1053 61 953 21T740 -20Q514 -20 349 132L194 -26L109 60L268 221Q144 389 144 608Q144 835 277 1006L109 1177L194 1264L361 1094Q526 1234 740 1234T1119 1092L1289 1265L1375 1177L1204 1002Q1334
-832 1334 608Q1334 393 1212 224L1375 60L1289 -27L1131 133ZM257 608Q257 470 321 350T499 161T740 91Q869 91 981 161T1157 350T1221 608Q1221 747 1156 866T979 1054T740 1122T500 1054T323 867T257 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1056" d="M527 731L892 1456H1030L631 705H944V616H586V412H944V324H586V0H463V324H109V412H463V616H109V705H422L24 1456H163L527 731Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="444" d="M159 -270V501H279V-270H159ZM279 698H159V1456H279V698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1239" d="M1119 431Q1119 331 1058 262T887 159Q978 111 1026 41T1075 -139Q1075 -303 949 -399T606 -495Q497 -495 401 -467T236 -382Q102 -268 102 -64L222 -62Q222 -218 325 -305T606 -393Q766 -393 860 -324T954 -141Q954
--64 920 -17T805 69T548 156T284 255T153 378T108 551Q108 651 166 721T331 825Q245 872 199 942T153 1120Q153 1281 282 1378T624 1476Q848 1476 972 1363T1097 1045H977Q977 1191 881 1282T624 1374Q459 1374 366 1306T273 1122Q273 1043 304 996T411 911T646
-828Q842 777 936 726T1075 603T1119 431ZM454 771Q346 758 287 700T228 553Q228 470 263 422T379 336T663 242L755 214Q867 227 933 284T999 428Q999 526 932 585T692 700L454 771Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="881" d="M137 1396Q137 1430 159 1453T219 1477T279 1454T302 1396Q302 1363 280 1340T219 1317T159 1340T137 1396ZM575 1395Q575 1429 597 1452T657 1476T717 1453T740 1395Q740 1362 718 1339T657 1316T597 1339T575 1395Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1637" d="M1121 607Q1121 455 1039 374T807 293T566 399T474 686V776Q474 950 566 1056T807 1163T1039 1083T1122 850H1023Q1023 1074 807 1074Q701 1074 637 993T573 771V680Q573 546 636 465T807 383Q913 383 967 436T1022
-607H1121ZM192 729Q192 553 273 399T502 155T817 65Q984 65 1129 154T1357 396T1441 729Q1441 907 1358 1059T1130 1300T817 1389Q646 1389 499 1298T272 1055T192 729ZM107 729Q107 931 200 1104T459 1376T817 1476T1174 1377T1432 1104T1526 729Q1526 532 1436
-360T1181 84T817 -21Q620 -21 455 82T198 358T107 729Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="906" d="M649 705Q634 748 628 799Q541 691 406 691Q289 691 223 749T157 908Q157 1018 240 1079T486 1140H625V1201Q625 1286 585 1333T464 1380Q374 1380 323 1345T271 1237L164 1243Q164 1345 247 1410T464 1476Q588 1476
-661 1405T734 1199V884Q734 792 760 705H649ZM426 786Q479 786 536 816T625 890V1058H496Q266 1058 266 912Q266 786 426 786Z" />
-<glyph unicode="&#xab;" horiz-adv-x="933" d="M247 792L523 404H418L123 783V802L418 1181H523L247 792ZM556 536L832 148H727L432 527V546L727 925H832L556 536Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1117" d="M936 386H816V670H124V776H936V386Z" />
-<glyph unicode="&#xad;" horiz-adv-x="586" d="M528 592H49V693H528V592Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1642" d="M102 729Q102 931 195 1104T454 1376T812 1476T1169 1377T1428 1104T1522 729Q1522 530 1431 358T1175 83T812 -21T450 82T193 358T102 729ZM187 729Q187 550 270 396T499 154T812 65T1125 153T1353 396T1436 729Q1436
-905 1355 1057T1129 1299T812 1389Q644 1389 499 1301T270 1060T187 729ZM650 666V321H552V1160H810Q957 1160 1036 1099T1115 912Q1115 779 974 715Q1046 689 1074 635T1102 504T1106 394T1119 337V321H1017Q1003 357 1003 503Q1003 592 966 629T838 666H650ZM650
-757H831Q912 757 964 799T1017 910Q1017 995 974 1031T824 1070H650V757Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="874" d="M756 1343H137V1440H756V1343Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="774" d="M630 1226Q630 1122 559 1051T388 980Q287 980 215 1051T143 1226T216 1402T388 1476T558 1403T630 1226ZM233 1226Q233 1159 277 1115T388 1071T497 1115T540 1226Q540 1295 497 1340T388 1385Q323 1385 278 1340T233
-1226Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1085" d="M609 829H1000V727H609V289H498V727H84V829H498V1267H609V829ZM963 0H128V101H963V0Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="740" d="M667 665H96V740L416 1054Q522 1164 522 1237Q522 1300 482 1338T362 1377Q275 1377 228 1333T181 1215H76Q76 1323 155 1394T360 1465T557 1403T628 1239Q628 1138 510 1016L455 961L229 752H667V665Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="740" d="M267 1107H353Q434 1109 481 1145T529 1241Q529 1303 486 1340T362 1377Q286 1377 238 1340T190 1245H85Q85 1341 163 1403T361 1465Q489 1465 562 1405T635 1243Q635 1187 597 1140T489 1069Q651 1027 651 880Q651
-778 572 716T363 654Q234 654 153 717T71 884H177Q177 822 229 782T366 741Q453 741 499 779T546 883Q546 1025 340 1025H267V1107Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="576" d="M315 1536H460L229 1256H124L315 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1140" d="M281 1082V446Q281 266 344 174T544 81Q676 81 753 138T859 312V1082H979V0H870L863 154Q765 -20 552 -20Q368 -20 281 105V-416H162V1082H281Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="973" d="M681 0V520H573Q423 520 312 578T142 742T83 988Q83 1201 216 1328T577 1456H801V0H681Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="503" d="M163 717Q163 752 185 776T247 800T310 776T333 717T310 659T247 635T185 658T163 717Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="498" d="M246 0L234 -64Q399 -85 399 -235Q399 -327 320 -381T105 -435L98 -357Q187 -357 243 -325T300 -237Q300 -179 257 -157T124 -127L153 0H246Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="740" d="M464 665H358V1328L126 1258V1348L450 1455H464V665Z" />
-<glyph unicode="&#xba;" horiz-adv-x="922" d="M135 1132Q135 1285 223 1380T458 1476Q605 1476 693 1381T782 1127V1033Q782 880 694 785T460 690Q313 690 224 784T135 1038V1132ZM243 1033Q243 919 299 852T460 785Q559 785 616 851T674 1037V1132Q674 1247
-616 1313T458 1380T301 1312T243 1127V1033Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="928" d="M221 944L516 560V541L221 162H115L391 550L115 944H221ZM540 944L835 560V541L540 162H434L710 550L434 944H540Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1484" d="M453 664H347V1327L115 1257V1347L439 1454H453V664ZM414 129L340 177L1051 1315L1125 1267L414 129ZM1272 275H1399V187H1272V0H1167V187H768L764 253L1161 789H1272V275ZM878 275H1167V659L1136 609L878 275Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1548" d="M370 129L296 177L1007 1315L1081 1267L370 129ZM438 664H332V1327L100 1257V1347L424 1454H438V664ZM1436 0H865V75L1185 389Q1291 499 1291 572Q1291 635 1251 673T1131 712Q1044 712 997 668T950 550H845Q845
-658 924 729T1129 800T1326 738T1397 574Q1397 473 1279 351L1224 296L998 87H1436V0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1590" d="M558 129L484 177L1195 1315L1269 1267L558 129ZM1387 275H1514V187H1387V0H1282V187H883L879 253L1276 789H1387V275ZM993 275H1282V659L1251 609L993 275ZM314 1107H400Q481 1109 528 1145T576 1241Q576 1303
-533 1340T409 1377Q333 1377 285 1340T237 1245H132Q132 1341 210 1403T408 1465Q536 1465 609 1405T682 1243Q682 1187 644 1140T536 1069Q698 1027 698 880Q698 778 619 716T410 654Q281 654 200 717T118 884H224Q224 822 276 782T413 741Q500 741 546 779T593
-883Q593 1025 387 1025H314V1107Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="940" d="M551 687Q549 564 524 505T405 352T288 228Q207 123 207 -8Q207 -137 274 -207T469 -277Q588 -277 659 -207T732 -20H852Q850 -186 745 -284T469 -383Q291 -383 190 -283T88 -10Q88 101 141 202T337 438Q422 509
-429 618L431 687H551ZM567 1022Q567 988 545 965T485 941T425 964T402 1022Q402 1055 424 1078T485 1101T545 1078T567 1022Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513ZM716 1571H607L381 1851H525L716 1571Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513ZM762 1851H907L676 1571H571L762 1851Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513ZM921 1583V1573H810L642 1756L475 1573H366V1586L604 1841H680L921 1583Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513ZM983 1809Q983 1713 927 1655T788 1596Q712 1596 640 1651T510 1706Q463 1706 432 1675T400 1588L310 1591Q310 1683 364
-1743T505 1803Q553 1803 587 1786T651 1748T711 1710T783 1693Q829 1693 861 1726T894 1815L983 1809Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513ZM343 1711Q343 1745 365 1768T425 1792T485 1769T508 1711Q508 1678 486 1655T425 1632T365 1655T343 1711ZM781 1710Q781
-1744 803 1767T863 1791T923 1768T946 1710Q946 1677 924 1654T863 1631T803 1654T781 1710Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1279" d="M970 408H309L159 0H30L581 1456H698L1249 0H1121L970 408ZM347 513H931L639 1306L347 513ZM450 1715Q450 1795 506 1850T643 1905Q722 1905 779 1850T836 1715Q836 1636 781 1582T643 1528T505 1582T450 1715ZM527
-1715Q527 1665 560 1632T643 1599Q692 1599 726 1631T760 1715Q760 1768 725 1801T643 1834Q594 1834 561 1800T527 1715Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1865" d="M1823 0H1006L989 389H393L163 0H17L898 1456H1762V1354H1068L1091 809H1680V707H1095L1121 101H1823V0ZM460 502H985L950 1331L460 502Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1330" d="M1215 454Q1190 224 1051 102T679 -20Q517 -20 393 61T200 290T131 630V819Q131 1013 199 1163T394 1394T688 1476Q922 1476 1057 1350T1215 1000H1091Q1045 1371 688 1371Q490 1371 373 1223T255 814V636Q255 384
-369 234T679 84Q872 84 970 176T1091 454H1215ZM728 -9L716 -73Q881 -94 881 -244Q881 -336 802 -390T587 -444L580 -366Q669 -366 725 -334T782 -246Q782 -188 739 -166T606 -136L635 -9H728Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1165" d="M988 698H307V104H1090V0H184V1456H1085V1351H307V802H988V698ZM693 1577H584L358 1857H502L693 1577Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1165" d="M988 698H307V104H1090V0H184V1456H1085V1351H307V802H988V698ZM739 1857H884L653 1577H548L739 1857Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1165" d="M988 698H307V104H1090V0H184V1456H1085V1351H307V802H988V698ZM898 1589V1579H787L619 1762L452 1579H343V1592L581 1847H657L898 1589Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1165" d="M988 698H307V104H1090V0H184V1456H1085V1351H307V802H988V698ZM320 1717Q320 1751 342 1774T402 1798T462 1775T485 1717Q485 1684 463 1661T402 1638T342 1661T320 1717ZM758 1716Q758 1750 780 1773T840 1797T900
-1774T923 1716Q923 1683 901 1660T840 1637T780 1660T758 1716Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="545" d="M334 0H211V1456H334V0ZM348 1577H239L13 1857H157L348 1577Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="545" d="M334 0H211V1456H334V0ZM393 1857H538L307 1577H202L393 1857Z" />
-<glyph unicode="&#xce;" horiz-adv-x="545" d="M334 0H211V1456H334V0ZM553 1589V1579H442L274 1762L107 1579H-2V1592L236 1847H312L553 1589Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="545" d="M334 0H211V1456H334V0ZM-25 1717Q-25 1751 -3 1774T57 1798T117 1775T140 1717Q140 1684 118 1661T57 1638T-3 1661T-25 1717ZM413 1716Q413 1750 435 1773T495 1797T555 1774T578 1716Q578 1683 556 1660T495 1637T435
-1660T413 1716Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1371" d="M214 0V689H33V791H214V1456H621Q800 1456 942 1375T1163 1141T1243 795V661Q1243 466 1164 315T942 82T612 0H214ZM645 689H337V104H608Q843 104 982 256T1121 669V797Q1121 1048 984 1199T623 1351H337V791H645V689Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1454" d="M1268 0H1145L308 1246V0H184V1456H308L1146 209V1456H1268V0ZM1067 1809Q1067 1713 1011 1655T872 1596Q796 1596 724 1651T594 1706Q547 1706 516 1675T484 1588L394 1591Q394 1683 448 1743T589 1803Q637 1803
-671 1786T735 1748T795 1710T867 1693Q913 1693 945 1726T978 1815L1067 1809Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q439 -20 282 162T125 655V805Q125 1004 195 1157T395 1393T692 1476T988 1395T1187 1166T1260 823V649ZM1137 807Q1137 1070 1018 1219T692 1368Q489 1368 369 1219T248
-801V649Q248 390 368 239T694 87Q903 87 1020 236T1137 653V807ZM765 1583H656L430 1863H574L765 1583Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q439 -20 282 162T125 655V805Q125 1004 195 1157T395 1393T692 1476T988 1395T1187 1166T1260 823V649ZM1137 807Q1137 1070 1018 1219T692 1368Q489 1368 369 1219T248
-801V649Q248 390 368 239T694 87Q903 87 1020 236T1137 653V807ZM811 1863H956L725 1583H620L811 1863Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q439 -20 282 162T125 655V805Q125 1004 195 1157T395 1393T692 1476T988 1395T1187 1166T1260 823V649ZM1137 807Q1137 1070 1018 1219T692 1368Q489 1368 369 1219T248
-801V649Q248 390 368 239T694 87Q903 87 1020 236T1137 653V807ZM970 1595V1585H859L691 1768L524 1585H415V1598L653 1853H729L970 1595Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q439 -20 282 162T125 655V805Q125 1004 195 1157T395 1393T692 1476T988 1395T1187 1166T1260 823V649ZM1137 807Q1137 1070 1018 1219T692 1368Q489 1368 369 1219T248
-801V649Q248 390 368 239T694 87Q903 87 1020 236T1137 653V807ZM1032 1821Q1032 1725 976 1667T837 1608Q761 1608 689 1663T559 1718Q512 1718 481 1687T449 1600L359 1603Q359 1695 413 1755T554 1815Q602 1815 636 1798T700 1760T760 1722T832 1705Q878 1705
-910 1738T943 1827L1032 1821Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q439 -20 282 162T125 655V805Q125 1004 195 1157T395 1393T692 1476T988 1395T1187 1166T1260 823V649ZM1137 807Q1137 1070 1018 1219T692 1368Q489 1368 369 1219T248
-801V649Q248 390 368 239T694 87Q903 87 1020 236T1137 653V807ZM392 1723Q392 1757 414 1780T474 1804T534 1781T557 1723Q557 1690 535 1667T474 1644T414 1667T392 1723ZM830 1722Q830 1756 852 1779T912 1803T972 1780T995 1722Q995 1689 973 1666T912 1643T852
-1666T830 1722Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1072" d="M93 179L451 544L108 894L187 974L529 624L872 974L951 894L608 544L966 179L887 100L529 464L172 100L93 179Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1386" d="M1260 649Q1260 448 1191 296T992 62T694 -20Q508 -20 375 77L274 -83H170L307 134Q125 318 125 658V805Q125 1004 195 1157T395 1393T692 1476Q916 1476 1064 1336L1171 1505H1274L1125 1268Q1259 1088 1260 807V649ZM248
-649Q248 388 370 235L1002 1237Q883 1368 692 1368Q489 1368 369 1219T248 801V649ZM1137 807Q1137 1018 1057 1160L434 171Q541 87 694 87Q903 87 1020 236T1137 653V807Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1346" d="M1187 1456V462Q1186 315 1122 206T942 39T674 -20Q444 -20 306 105T162 453V1456H284V471Q284 287 389 186T674 84T958 186T1063 470V1456H1187ZM756 1571H647L421 1851H565L756 1571Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1346" d="M1187 1456V462Q1186 315 1122 206T942 39T674 -20Q444 -20 306 105T162 453V1456H284V471Q284 287 389 186T674 84T958 186T1063 470V1456H1187ZM802 1851H947L716 1571H611L802 1851Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1346" d="M1187 1456V462Q1186 315 1122 206T942 39T674 -20Q444 -20 306 105T162 453V1456H284V471Q284 287 389 186T674 84T958 186T1063 470V1456H1187ZM961 1583V1573H850L682 1756L515 1573H406V1586L644 1841H720L961 1583Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1346" d="M1187 1456V462Q1186 315 1122 206T942 39T674 -20Q444 -20 306 105T162 453V1456H284V471Q284 287 389 186T674 84T958 186T1063 470V1456H1187ZM383 1711Q383 1745 405 1768T465 1792T525 1769T548 1711Q548 1678
-526 1655T465 1632T405 1655T383 1711ZM821 1710Q821 1744 843 1767T903 1791T963 1768T986 1710Q986 1677 964 1654T903 1631T843 1654T821 1710Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1226" d="M611 662L1056 1456H1198L672 548V0H549V548L24 1456H170L611 662ZM732 1845H877L646 1565H541L732 1845Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1214" d="M303 1456V1152H628Q771 1152 877 1101T1039 956T1096 738Q1096 553 974 441T641 324H303V0H183V1456H303ZM303 1051V425H627Q784 425 880 510T976 736T885 961T642 1051H303Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1200" d="M271 0H151V1127Q151 1327 246 1435T512 1544Q665 1544 760 1460T856 1237Q856 1179 843 1131T794 1019T746 913T733 824Q733 768 774 716T911 593T1051 454T1096 306Q1096 160 990 70T720 -20Q636 -20 545 4T414
-60L448 161Q485 132 562 106T706 80Q828 80 902 144T976 306Q976 367 932 423T797 547T659 681T613 826Q613 922 676 1034T739 1230Q739 1323 676 1382T522 1442Q275 1442 271 1136V0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826
-1012T934 759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86ZM653 1256H544L318 1536H462L653 1256Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826
-1012T934 759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86ZM699 1536H844L613 1256H508L699 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826
-1012T934 759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86ZM858 1268V1258H747L579 1441L412 1258H303V1271L541 1526H617L858 1268Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826
-1012T934 759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86ZM920 1494Q920 1398 864 1340T725 1281Q649 1281 577 1336T447 1391Q400 1391 369 1360T337 1273L247 1276Q247 1368 301 1428T442
-1488Q490 1488 524 1471T588 1433T648 1395T720 1378Q766 1378 798 1411T831 1500L920 1494Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826
-1012T934 759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86ZM280 1396Q280 1430 302 1453T362 1477T422 1454T445 1396Q445 1363 423 1340T362 1317T302 1340T280 1396ZM718 1395Q718 1429
-740 1452T800 1476T860 1453T883 1395Q883 1362 861 1339T800 1316T740 1339T718 1395Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1097" d="M839 0Q821 51 816 151Q753 69 656 25T449 -20Q293 -20 197 67T100 287Q100 445 231 537T598 629H815V752Q815 868 744 934T535 1001Q410 1001 328 937T246 783L126 784Q126 913 246 1007T541 1102Q722 1102 826
-1012T934 759V247Q934 90 967 12V0H839ZM463 86Q583 86 677 144T815 299V537H601Q422 535 321 472T220 297Q220 206 287 146T463 86ZM387 1400Q387 1480 443 1535T580 1590Q659 1590 716 1535T773 1400Q773 1321 718 1267T580 1213T442 1267T387 1400ZM464 1400Q464
-1350 497 1317T580 1284Q629 1284 663 1316T697 1400Q697 1453 662 1486T580 1519Q531 1519 498 1485T464 1400Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1732" d="M1265 -20Q1126 -20 1027 34T867 186Q807 88 693 34T440 -20Q271 -20 178 64T85 293Q85 450 195 539T511 632H781V720Q781 852 718 926T528 1000Q398 1000 315 935T232 765L113 778Q113 922 229 1012T528 1102Q653
-1102 741 1049T870 889Q930 989 1024 1045T1235 1102Q1431 1102 1543 982T1658 644V538H901V509Q901 308 997 195T1265 81Q1450 81 1589 199L1636 112Q1491 -20 1265 -20ZM458 80Q549 80 642 126T781 236V536H525Q388 536 302 475T207 309L206 289Q206 192 271
-136T458 80ZM1235 1000Q1103 1000 1013 902T904 636H1539V667Q1539 821 1459 910T1235 1000Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1055" d="M556 81Q681 81 765 151T857 334H972Q967 235 910 154T759 26T556 -20Q343 -20 219 128T94 526V562Q94 722 150 845T310 1035T555 1102Q733 1102 848 996T972 717H857Q849 844 766 922T555 1000Q393 1000 304 883T214
-555V520Q214 313 303 197T556 81ZM589 -9L577 -73Q742 -94 742 -244Q742 -336 663 -390T448 -444L441 -366Q530 -366 586 -334T643 -246Q643 -188 600 -166T467 -136L496 -9H589Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1058" d="M575 -20Q437 -20 326 48T152 237T90 510V553Q90 709 150 834T319 1030T553 1102Q750 1102 865 968T981 600V533H209V510Q209 326 314 204T580 81Q676 81 749 116T883 228L958 171Q826 -20 575 -20ZM553 1000Q418
-1000 326 901T213 635H862V648Q857 804 773 902T553 1000ZM640 1256H531L305 1536H449L640 1256Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1058" d="M575 -20Q437 -20 326 48T152 237T90 510V553Q90 709 150 834T319 1030T553 1102Q750 1102 865 968T981 600V533H209V510Q209 326 314 204T580 81Q676 81 749 116T883 228L958 171Q826 -20 575 -20ZM553 1000Q418
-1000 326 901T213 635H862V648Q857 804 773 902T553 1000ZM686 1536H831L600 1256H495L686 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1058" d="M575 -20Q437 -20 326 48T152 237T90 510V553Q90 709 150 834T319 1030T553 1102Q750 1102 865 968T981 600V533H209V510Q209 326 314 204T580 81Q676 81 749 116T883 228L958 171Q826 -20 575 -20ZM553 1000Q418
-1000 326 901T213 635H862V648Q857 804 773 902T553 1000ZM845 1268V1258H734L566 1441L399 1258H290V1271L528 1526H604L845 1268Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1058" d="M575 -20Q437 -20 326 48T152 237T90 510V553Q90 709 150 834T319 1030T553 1102Q750 1102 865 968T981 600V533H209V510Q209 326 314 204T580 81Q676 81 749 116T883 228L958 171Q826 -20 575 -20ZM553 1000Q418
-1000 326 901T213 635H862V648Q857 804 773 902T553 1000ZM267 1396Q267 1430 289 1453T349 1477T409 1454T432 1396Q432 1363 410 1340T349 1317T289 1340T267 1396ZM705 1395Q705 1429 727 1452T787 1476T847 1453T870 1395Q870 1362 848 1339T787 1316T727 1339T705
-1395Z" />
-<glyph unicode="&#xec;" horiz-adv-x="456" d="M288 0H168V1082H288V0ZM305 1244H196L-30 1524H114L305 1244Z" />
-<glyph unicode="&#xed;" horiz-adv-x="456" d="M288 0H168V1082H288V0ZM350 1780H495L264 1500H159L350 1780Z" />
-<glyph unicode="&#xee;" horiz-adv-x="456" d="M288 0H168V1082H288V0ZM510 1256V1246H399L231 1429L64 1246H-45V1259L193 1514H269L510 1256Z" />
-<glyph unicode="&#xef;" horiz-adv-x="456" d="M288 0H168V1082H288V0ZM-68 1384Q-68 1418 -46 1441T14 1465T74 1442T97 1384Q97 1351 75 1328T14 1305T-46 1328T-68 1384ZM370 1383Q370 1417 392 1440T452 1464T512 1441T535 1383Q535 1350 513 1327T452 1304T392
-1327T370 1383Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1191" d="M811 1303Q1049 1053 1055 645V535Q1055 376 999 249T842 51T615 -20Q485 -20 379 41T211 216T149 466Q149 695 268 830T587 965Q687 965 773 927T919 821Q877 1072 709 1240L484 1101L433 1174L639 1302Q502 1408
-296 1475L335 1578Q577 1506 744 1366L938 1487L989 1414L811 1303ZM935 625L933 682Q894 765 807 813T609 861Q448 861 359 756T269 466Q269 363 314 274T438 134T619 83Q760 83 847 207T935 543V625Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1125" d="M270 1082L274 897Q335 997 426 1049T627 1102Q801 1102 886 1004T972 710V0H853V711Q852 856 792 927T598 998Q487 998 402 929T275 741V0H156V1082H270ZM916 1493Q916 1397 860 1339T721 1280Q645 1280 573 1335T443
-1390Q396 1390 365 1359T333 1272L243 1275Q243 1367 297 1427T438 1487Q486 1487 520 1470T584 1432T644 1394T716 1377Q762 1377 794 1410T827 1499L916 1493Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1147" d="M90 557Q90 713 150 838T321 1032T572 1102Q788 1102 922 951T1056 549V524Q1056 367 996 242T825 48T574 -20Q359 -20 225 131T90 533V557ZM210 524Q210 330 310 206T574 81Q736 81 836 205T937 534V557Q937 681
-891 784T762 943T572 1000Q412 1000 311 875T210 546V524ZM645 1256H536L310 1536H454L645 1256Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1147" d="M90 557Q90 713 150 838T321 1032T572 1102Q788 1102 922 951T1056 549V524Q1056 367 996 242T825 48T574 -20Q359 -20 225 131T90 533V557ZM210 524Q210 330 310 206T574 81Q736 81 836 205T937 534V557Q937 681
-891 784T762 943T572 1000Q412 1000 311 875T210 546V524ZM691 1536H836L605 1256H500L691 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1147" d="M90 557Q90 713 150 838T321 1032T572 1102Q788 1102 922 951T1056 549V524Q1056 367 996 242T825 48T574 -20Q359 -20 225 131T90 533V557ZM210 524Q210 330 310 206T574 81Q736 81 836 205T937 534V557Q937 681
-891 784T762 943T572 1000Q412 1000 311 875T210 546V524ZM850 1268V1258H739L571 1441L404 1258H295V1271L533 1526H609L850 1268Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1147" d="M90 557Q90 713 150 838T321 1032T572 1102Q788 1102 922 951T1056 549V524Q1056 367 996 242T825 48T574 -20Q359 -20 225 131T90 533V557ZM210 524Q210 330 310 206T574 81Q736 81 836 205T937 534V557Q937 681
-891 784T762 943T572 1000Q412 1000 311 875T210 546V524ZM912 1493Q912 1397 856 1339T717 1280Q641 1280 569 1335T439 1390Q392 1390 361 1359T329 1272L239 1275Q239 1367 293 1427T434 1487Q482 1487 516 1470T580 1432T640 1394T712 1377Q758 1377 790 1410T823
-1499L912 1493Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1147" d="M90 557Q90 713 150 838T321 1032T572 1102Q788 1102 922 951T1056 549V524Q1056 367 996 242T825 48T574 -20Q359 -20 225 131T90 533V557ZM210 524Q210 330 310 206T574 81Q736 81 836 205T937 534V557Q937 681
-891 784T762 943T572 1000Q412 1000 311 875T210 546V524ZM272 1396Q272 1430 294 1453T354 1477T414 1454T437 1396Q437 1363 415 1340T354 1317T294 1340T272 1396ZM710 1395Q710 1429 732 1452T792 1476T852 1453T875 1395Q875 1362 853 1339T792 1316T732 1339T710
-1395Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1164" d="M1070 644H72V760H1070V644ZM495 1088Q495 1123 517 1147T579 1171T642 1147T665 1088T642 1030T579 1006T517 1029T495 1088ZM495 291Q495 326 517 350T579 374T642 350T665 291T642 233T579 210T517 233T495 291Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1140" d="M89 557Q89 713 149 838T320 1032T571 1102Q685 1102 785 1054L863 1214H957L857 1010Q951 938 1003 821T1055 557V524Q1055 368 994 242T823 48T573 -20Q465 -20 373 21L294 -140H200L299 63Q199 134 144 253T89
-524V557ZM208 524Q208 414 243 319T348 163L737 957Q662 1000 571 1000Q410 1000 309 875T208 546V524ZM935 557Q935 660 902 751T806 905L419 115Q487 81 573 81Q734 81 834 205T935 534V557Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1125" d="M852 137Q744 -20 507 -20Q334 -20 244 80T152 378V1082H271V393Q271 84 521 84Q781 84 850 299V1082H970V0H854L852 137ZM647 1256H538L312 1536H456L647 1256Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1125" d="M852 137Q744 -20 507 -20Q334 -20 244 80T152 378V1082H271V393Q271 84 521 84Q781 84 850 299V1082H970V0H854L852 137ZM693 1536H838L607 1256H502L693 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1125" d="M852 137Q744 -20 507 -20Q334 -20 244 80T152 378V1082H271V393Q271 84 521 84Q781 84 850 299V1082H970V0H854L852 137ZM852 1268V1258H741L573 1441L406 1258H297V1271L535 1526H611L852 1268Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1125" d="M852 137Q744 -20 507 -20Q334 -20 244 80T152 378V1082H271V393Q271 84 521 84Q781 84 850 299V1082H970V0H854L852 137ZM274 1396Q274 1430 296 1453T356 1477T416 1454T439 1396Q439 1363 417 1340T356 1317T296
-1340T274 1396ZM712 1395Q712 1429 734 1452T794 1476T854 1453T877 1395Q877 1362 855 1339T794 1316T734 1339T712 1395Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="973" d="M499 172L815 1082H944L482 -184L458 -240Q369 -437 183 -437Q140 -437 91 -423L90 -324L152 -330Q240 -330 294 -287T387 -137L440 9L32 1082H163L499 172ZM633 1536H778L547 1256H442L633 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1150" d="M1031 530Q1031 277 919 129T618 -20Q397 -20 279 136V-416H159V1536H279V932Q396 1102 616 1102Q808 1102 919 956T1031 548V530ZM911 551Q911 758 826 878T589 998Q479 998 400 945T279 791V270Q321 180 400 131T591
-81Q742 81 826 201T911 551Z" />
-<glyph unicode="&#xff;" horiz-adv-x="973" d="M499 172L815 1082H944L482 -184L458 -240Q369 -437 183 -437Q140 -437 91 -423L90 -324L152 -330Q240 -330 294 -287T387 -137L440 9L32 1082H163L499 172ZM214 1396Q214 1430 236 1453T296 1477T356 1454T379 1396Q379
-1363 357 1340T296 1317T236 1340T214 1396ZM652 1395Q652 1429 674 1452T734 1476T794 1453T817 1395Q817 1362 795 1339T734 1316T674 1339T652 1395Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1334" d="M1417 686H415V788H1417V686Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1580" d="M1462 686H126V788H1462V686Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="364" d="M238 1554L310 1503Q220 1385 217 1249V1121H98V1233Q98 1325 135 1410T238 1554Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="364" d="M133 1099L62 1151Q152 1272 155 1405V1536H273V1435Q273 1226 133 1099Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="353" d="M112 -231L41 -179Q124 -68 132 51L133 205H252V104Q252 -104 112 -231Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="612" d="M239 1554L311 1503Q221 1385 218 1249V1121H99V1233Q99 1325 136 1410T239 1554ZM490 1554L562 1503Q472 1385 469 1249V1121H350V1233Q350 1325 387 1410T490 1554Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="617" d="M139 1099L68 1151Q158 1272 161 1405V1536H279V1435Q279 1226 139 1099ZM383 1099L312 1151Q402 1272 405 1405V1536H523V1435Q523 1226 383 1099Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="593" d="M112 -240L41 -188Q130 -65 133 73V236H252V106Q252 -111 112 -240ZM346 -240L275 -188Q363 -66 366 73V236H486V106Q486 -111 346 -240Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="662" d="M146 752Q146 831 197 881T331 931Q413 931 464 883T517 757V717Q517 636 466 588T332 540Q248 540 197 589T146 719V752Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="609" d="M232 555L508 167H403L108 546V565L403 944H508L232 555Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="609" d="M203 944L498 560V541L203 162H97L373 550L97 944H203Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-300.ttf b/static/fonts/roboto-v18-latin-300.ttf
deleted file mode 100644
index a22188eed3..0000000000
Binary files a/static/fonts/roboto-v18-latin-300.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300.woff b/static/fonts/roboto-v18-latin-300.woff
deleted file mode 100644
index 96663f0727..0000000000
Binary files a/static/fonts/roboto-v18-latin-300.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300.woff2 b/static/fonts/roboto-v18-latin-300.woff2
deleted file mode 100644
index 52c5845a7c..0000000000
Binary files a/static/fonts/roboto-v18-latin-300.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300italic.eot b/static/fonts/roboto-v18-latin-300italic.eot
deleted file mode 100644
index 8eb2292f00..0000000000
Binary files a/static/fonts/roboto-v18-latin-300italic.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300italic.svg b/static/fonts/roboto-v18-latin-300italic.svg
deleted file mode 100644
index 758402b65f..0000000000
--- a/static/fonts/roboto-v18-latin-300italic.svg
+++ /dev/null
@@ -1,329 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1113" ><font-face
-    font-family="Roboto Light"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="493" />
-<glyph unicode="!" horiz-adv-x="458" d="M243 405H133L309 1456H433L243 405ZM56 70Q58 104 84 128T141 152Q176 153 198 129T218 70Q216 37 191 15T132 -9T76 12T56 70Z" />
-<glyph unicode="&quot;" horiz-adv-x="580" d="M361 1390L293 1083H212L287 1536H384L361 1390ZM590 1392L522 1083H440L516 1536H613L590 1392Z" />
-<glyph unicode="#" horiz-adv-x="1165" d="M695 410H396L250 0H148L295 410H48L65 503H327L484 944H214L232 1040H518L667 1456H769L619 1040H919L1069 1456H1171L1022 1040H1243L1226 944H988L831 503H1077L1061 410H798L651 0H549L695 410ZM428 503H728L886
-944H586L428 503Z" />
-<glyph unicode="$" horiz-adv-x="1111" d="M837 366Q848 465 791 538T587 670T371 785T268 916T242 1088Q255 1254 368 1356T658 1476L693 1677H795L760 1474Q914 1451 990 1335T1050 1028H932Q946 1181 882 1274T691 1370Q557 1372 466 1294T360 1090Q343 929
-489 842Q527 819 639 773T811 683Q973 565 957 369Q944 203 828 100T529 -18L496 -208H395L428 -18Q312 -7 231 50T113 203T87 418H206Q193 264 268 175T485 84Q625 82 724 161T837 366Z" />
-<glyph unicode="%" horiz-adv-x="1478" d="M206 1175Q221 1307 309 1394T521 1478Q636 1474 703 1389T762 1176L755 1109Q740 968 652 882T442 799Q329 801 260 886T199 1099L206 1175ZM296 1097Q289 1002 330 945T447 885Q529 883 586 942T657 1099L665 1177Q673
-1272 632 1330T516 1391Q435 1393 376 1332T304 1168L296 1097ZM775 356Q790 486 877 573T1089 658Q1206 654 1273 570T1331 357L1324 279Q1309 147 1220 61T1010 -22Q895 -20 827 66T768 279L775 356ZM864 277Q857 183 897 125T1015 64Q1095 62 1153 120T1226
-279L1234 358Q1241 455 1202 512T1084 571Q1000 573 942 512T872 349L864 277ZM350 122L277 175L1162 1306L1231 1258L350 122Z" />
-<glyph unicode="&amp;" horiz-adv-x="1232" d="M428 796L391 861Q308 1014 319 1137Q331 1289 432 1384T684 1477Q811 1473 887 1395T955 1199Q942 1033 726 883L576 779L887 318Q999 466 1029 651H1137Q1104 401 951 229L1103 0H971L874 144Q680 -24 462 -20Q282
--18 172 87T74 363Q83 472 162 575T428 796ZM467 82Q639 79 812 232L494 701L483 716L434 681L382 640Q211 500 195 363Q178 242 255 163T467 82ZM438 1142Q425 1023 524 862L704 992Q828 1089 839 1200Q847 1275 800 1325T676 1375Q580 1377 515 1310T438 1142Z"
-/>
-<glyph unicode="&apos;" horiz-adv-x="348" d="M344 1389L281 1090H190L266 1536H367L344 1389Z" />
-<glyph unicode="(" horiz-adv-x="643" d="M736 1633L757 1551Q597 1442 479 1245T295 773T233 240L235 174Q257 -226 454 -392L419 -469Q219 -320 151 -3Q110 190 120 392Q131 653 216 915T434 1360T736 1633Z" />
-<glyph unicode=")" horiz-adv-x="657" d="M495 577Q436 201 280 -74T-103 -471L-124 -393Q65 -264 192 -18T375 572L379 592Q403 761 401 921Q396 1152 339 1311T180 1555L215 1631Q371 1517 448 1287T514 769Q510 675 498 593L495 577Z" />
-<glyph unicode="*" horiz-adv-x="853" d="M417 1003L114 1111L161 1208L464 1084L525 1456H629L556 1087L890 1212L905 1106L561 991L727 695L638 635L484 940L234 639L156 705L417 1003Z" />
-<glyph unicode="+" horiz-adv-x="1131" d="M637 740H1067L1047 628H618L534 146H414L498 628H76L96 740H517L598 1206H718L637 740Z" />
-<glyph unicode="," horiz-adv-x="390" d="M-17 -273L-84 -218Q31 -86 53 46L77 188H193L171 44Q138 -144 -17 -273Z" />
-<glyph unicode="-" horiz-adv-x="578" d="M512 592H45L63 693H530L512 592Z" />
-<glyph unicode="." horiz-adv-x="484" d="M48 72Q51 107 76 131T137 157Q173 158 196 133T216 72Q214 37 189 15T128 -9T70 13T48 72Z" />
-<glyph unicode="/" horiz-adv-x="799" d="M13 -125H-101L764 1456H877L13 -125Z" />
-<glyph unicode="0" horiz-adv-x="1111" d="M459 -20Q342 -17 261 42T143 214T110 468L117 576L160 860Q207 1164 341 1322T692 1476Q869 1472 957 1346T1040 992Q1038 920 1029 853L989 595Q936 278 801 126T459 -20ZM924 1084Q903 1368 686 1375Q524 1380 421
-1251T281 875L237 593Q222 472 228 378Q236 235 297 159T466 80Q616 73 718 193T863 550L911 857Q930 979 924 1084Z" />
-<glyph unicode="1" horiz-adv-x="1111" d="M571 0H451L679 1308L268 1162L289 1280L797 1461H820L571 0Z" />
-<glyph unicode="2" horiz-adv-x="1111" d="M925 0H38L53 97L683 720Q882 921 901 1082Q917 1207 851 1289T656 1375Q516 1379 415 1287T287 1037L172 1036Q196 1231 331 1355T660 1477Q841 1473 940 1366T1023 1092Q1003 895 775 665L203 101H942L925 0Z" />
-<glyph unicode="3" horiz-adv-x="1111" d="M427 793L542 791Q693 791 798 870T919 1083Q933 1215 866 1293T669 1375Q531 1377 436 1295T315 1075L199 1074Q221 1253 354 1366T675 1477Q854 1473 954 1363T1038 1079Q1029 971 954 883T745 742Q855 703 910 613T956
-403Q940 212 803 94T468 -20Q282 -16 170 99T71 395H189Q177 261 255 173T474 81Q624 77 724 164T838 399Q850 527 778 603T558 689L537 690L411 691L427 793Z" />
-<glyph unicode="4" horiz-adv-x="1111" d="M825 469H1045L1027 368H808L743 0H624L688 368H27L35 435L862 1456H996L825 469ZM190 469H705L849 1289L787 1206L190 469Z" />
-<glyph unicode="5" horiz-adv-x="1111" d="M233 748L411 1456H1122L1104 1345H499L367 853Q486 934 639 932Q818 930 915 800T994 471Q974 248 843 112T508 -21Q331 -17 231 94T130 384H243Q245 243 315 164T514 80Q666 76 762 184T874 470Q888 624 818 721T613
-823Q460 827 329 720L233 748Z" />
-<glyph unicode="6" horiz-adv-x="1111" d="M955 1468L943 1363H911Q673 1358 510 1210T270 783Q422 960 643 956Q758 954 840 893T960 722T985 484Q976 382 936 287T830 121Q694 -25 501 -21Q335 -16 233 95T115 385Q106 477 139 674Q201 1047 408 1257T939 1468H955ZM618
-853Q500 855 390 786T249 615L236 511Q223 396 250 299T342 142T506 81Q601 79 678 130T805 274T868 480Q885 641 818 745T618 853Z" />
-<glyph unicode="7" horiz-adv-x="1111" d="M1127 1387L310 0H180L992 1354H191L207 1456H1135L1127 1387Z" />
-<glyph unicode="8" horiz-adv-x="1111" d="M1057 1090Q1046 972 971 884T766 743Q872 694 926 602T972 395Q957 208 815 92T465 -20Q277 -16 167 92T72 378Q83 505 168 601T400 751Q310 799 266 884T230 1072Q243 1252 374 1366T697 1476Q869 1472 970 1366T1057
-1090ZM853 394Q867 523 788 608T575 697Q421 699 314 607T191 376Q176 245 254 164T470 80Q622 76 730 163T853 394ZM937 1091Q949 1208 880 1289T690 1375Q552 1377 457 1291T348 1073Q336 955 405 877T595 797Q728 793 826 877T937 1091Z" />
-<glyph unicode="9" horiz-adv-x="1111" d="M879 673Q803 578 704 526T500 477Q386 479 304 544T185 718T159 958Q174 1103 242 1224T418 1412T654 1477Q826 1473 924 1357T1029 1032Q1032 920 1001 735Q940 375 746 184T251 -12H202L214 92H254Q500 96 654 239T879
-673ZM520 580Q634 576 736 645T898 837Q912 959 912 1008Q912 1179 845 1274T650 1374Q553 1376 474 1323T342 1172T277 963Q266 862 291 774T375 634T520 580Z" />
-<glyph unicode=":" horiz-adv-x="427" d="M287 72Q290 107 315 131T376 157Q412 158 435 133T455 72Q453 37 428 15T367 -9T309 13T287 72ZM191 995Q194 1030 219 1054T280 1080Q316 1081 339 1056T359 995Q357 960 332 938T271 914T213 936T191 995Z" />
-<glyph unicode=";" horiz-adv-x="397" d="M180 995Q183 1030 208 1054T269 1080Q305 1081 328 1056T348 995Q346 960 321 938T260 914T202 936T180 995ZM-17 -273L-84 -218Q31 -86 53 46L77 188H193L171 44Q138 -144 -17 -273Z" />
-<glyph unicode="&lt;" horiz-adv-x="1026" d="M212 652L836 352L814 231L75 612L92 708L964 1087L940 954L212 652Z" />
-<glyph unicode="=" horiz-adv-x="1109" d="M995 829H183L202 935H1014L995 829ZM923 418H112L131 524H942L923 418Z" />
-<glyph unicode="&gt;" horiz-adv-x="1039" d="M820 662L182 965L203 1083L960 704L943 607L54 227L77 358L820 662Z" />
-<glyph unicode="?" horiz-adv-x="912" d="M339 402Q352 512 400 597T547 766T686 897T752 996T784 1110Q797 1223 746 1295T587 1371Q472 1373 393 1306T287 1116L172 1115Q196 1281 313 1381T596 1477Q749 1473 834 1373T905 1111Q887 924 699 755L586 660Q480
-565 449 404L339 402ZM256 70Q259 104 283 127T342 152T399 129T419 70Q416 37 391 15T333 -9Q298 -10 276 12T256 70Z" />
-<glyph unicode="@" horiz-adv-x="1824" d="M1229 -20Q1143 -18 1087 32T1024 173Q943 64 867 20T708 -21Q616 -18 563 46T504 235Q493 408 569 599T763 890T1023 989Q1100 987 1158 959T1274 882L1139 308L1131 231Q1126 158 1156 113T1247 65Q1353 61 1433 143T1561
-380T1617 722Q1623 908 1564 1045T1383 1253T1082 1327Q842 1331 639 1193T309 802T175 274Q169 88 231 -60T414 -284T703 -362Q870 -366 1040 -284L1063 -366Q912 -455 698 -453Q507 -452 366 -369T150 -124T74 246Q74 469 153 689T375 1079T701 1336T1088 1420Q1284
-1417 1423 1337T1636 1102T1709 745Q1709 531 1646 350T1474 73T1229 -20ZM609 285Q604 189 637 134T737 75Q830 70 915 144T1040 330L1170 850Q1110 895 1028 899Q870 904 760 750T615 357L609 285Z" />
-<glyph unicode="A" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513Z" />
-<glyph unicode="B" horiz-adv-x="1227" d="M73 0L326 1456L736 1455Q945 1450 1051 1352T1141 1082Q1130 968 1058 884T863 755Q967 723 1025 631T1074 418Q1059 228 921 114T559 0H73ZM317 700L213 104L563 103Q721 103 828 186T953 416Q966 543 896 619T690
-699L317 700ZM334 803L653 802Q809 804 906 881T1018 1087Q1043 1340 733 1350L430 1351L334 803Z" />
-<glyph unicode="C" horiz-adv-x="1300" d="M1150 454Q1099 229 943 102T562 -20Q367 -16 252 118T127 481Q124 559 134 636L161 812Q192 1013 285 1168T513 1401T808 1476Q1016 1472 1133 1344T1248 999L1127 1000Q1127 1175 1043 1271T802 1372Q604 1377 465
-1225T283 803L253 603L249 513Q247 395 283 294T393 140T568 84Q742 78 859 171T1031 453L1150 454Z" />
-<glyph unicode="D" horiz-adv-x="1311" d="M73 0L326 1456L705 1455Q874 1455 998 1369T1177 1130T1210 794L1192 673Q1146 370 950 185T469 0H73ZM430 1351L213 104L473 103Q626 103 752 173T960 370T1068 658T1095 880T1089 998Q1066 1158 967 1252T711 1350L430 1351Z" />
-<glyph unicode="E" horiz-adv-x="1140" d="M977 698H317L213 104H973L955 0H73L326 1456H1203L1184 1351H430L334 802H995L977 698Z" />
-<glyph unicode="F" horiz-adv-x="1127" d="M972 680H314L195 0H73L326 1456H1204L1185 1351H430L331 785H991L972 680Z" />
-<glyph unicode="G" horiz-adv-x="1368" d="M1131 173Q1057 78 919 28T610 -20Q407 -18 281 119T143 484Q138 566 149 644L174 810Q221 1116 395 1298T829 1476Q1029 1472 1149 1357T1275 1045H1155Q1148 1197 1063 1282T824 1371Q620 1376 479 1224T296 806L272
-650Q262 585 264 516Q267 318 360 203T614 85Q871 80 1009 211L1075 587H696L714 691H1215L1131 173Z" />
-<glyph unicode="H" horiz-adv-x="1416" d="M1122 0H999L1121 698H317L195 0H73L326 1456H448L334 802H1138L1252 1456H1376L1122 0Z" />
-<glyph unicode="I" horiz-adv-x="539" d="M221 0H99L352 1456H474L221 0Z" />
-<glyph unicode="J" horiz-adv-x="1103" d="M959 1456H1082L907 433Q878 230 744 103T410 -21Q222 -17 124 95T44 401H166Q151 255 217 171T418 83Q557 79 657 174T784 431L959 1456Z" />
-<glyph unicode="K" horiz-adv-x="1263" d="M523 721L285 516L195 0H73L326 1456H448L313 680L546 890L1164 1456H1327L616 802L1110 0H972L523 721Z" />
-<glyph unicode="L" horiz-adv-x="1057" d="M214 104H912L894 0H73L326 1456H449L214 104Z" />
-<glyph unicode="M" horiz-adv-x="1729" d="M484 1456L781 174L1525 1456H1690L1437 0H1315L1426 639L1545 1269L804 0H710L408 1279L305 633L195 0H73L326 1456H484Z" />
-<glyph unicode="N" horiz-adv-x="1420" d="M1128 0H1010L413 1248L196 0H73L326 1456H444L1042 207L1259 1456H1380L1128 0Z" />
-<glyph unicode="O" horiz-adv-x="1354" d="M577 -20Q373 -16 254 121T124 489Q120 569 131 648L151 786Q196 1091 371 1284Q550 1481 813 1476Q947 1473 1047 1411T1204 1229T1265 966Q1268 880 1256 798L1233 644Q1198 438 1104 284T874 54T577 -20ZM1136 809Q1144
-872 1145 937Q1145 1059 1107 1159T993 1312T807 1369Q607 1374 466 1226T280 824Q244 619 245 521Q245 319 333 205T583 87Q796 82 935 241T1114 661L1136 809Z" />
-<glyph unicode="P" horiz-adv-x="1233" d="M298 593L195 0H73L326 1456L800 1455Q1004 1449 1115 1335T1209 1028Q1189 824 1044 708T666 592L298 593ZM316 697L671 696Q844 696 956 784T1087 1027Q1103 1175 1024 1260T797 1350L430 1351L316 697Z" />
-<glyph unicode="Q" horiz-adv-x="1354" d="M851 50L1067 -183L976 -254L734 2Q648 -19 570 -19Q437 -18 337 45T182 226T120 491Q116 573 127 649L149 798Q179 999 274 1159T506 1399T808 1476Q1012 1472 1132 1335T1261 966Q1264 880 1252 798L1226 626Q1151
-211 851 50ZM1132 808Q1140 871 1141 937Q1141 1060 1102 1161T987 1314T802 1369Q600 1374 460 1224T275 818Q240 613 240 521Q240 324 327 208T578 87Q790 82 930 239T1110 663L1132 808Z" />
-<glyph unicode="R" horiz-adv-x="1271" d="M710 606H299L193 0H70L323 1456L754 1455Q972 1455 1090 1342T1189 1035Q1174 889 1080 783T828 629L1076 14L1075 0H945L710 606ZM317 711L677 710Q831 710 940 800T1067 1036Q1084 1176 1005 1261T772 1350L428 1351L317
-711Z" />
-<glyph unicode="S" horiz-adv-x="1187" d="M936 365Q959 553 735 641L544 710L482 735Q198 856 219 1092Q228 1208 301 1296T493 1431T747 1476Q876 1473 977 1417T1129 1262T1169 1041H1046Q1060 1189 977 1278T741 1371Q583 1373 471 1299T342 1095Q329 992
-402 920T658 793Q890 719 980 616T1059 368Q1048 248 975 160T780 24T518 -20Q379 -19 268 37T101 190T56 416H178Q163 264 259 175T524 83T806 159T936 365Z" />
-<glyph unicode="T" horiz-adv-x="1196" d="M1268 1351H785L550 0H428L663 1351H179L198 1456H1287L1268 1351Z" />
-<glyph unicode="U" horiz-adv-x="1316" d="M1306 1456L1137 471Q1101 241 944 108T562 -21Q421 -18 319 44T170 218T140 469L309 1456H430L262 468Q241 299 324 195T568 84Q736 78 857 177T1011 452L1183 1456H1306Z" />
-<glyph unicode="V" horiz-adv-x="1235" d="M536 180L538 149L552 180L1196 1456H1334L580 0H463L166 1456H289L536 180Z" />
-<glyph unicode="W" horiz-adv-x="1791" d="M408 389L415 174L502 387L974 1456H1084L1220 377L1237 171L1319 397L1739 1456H1867L1277 0H1160L1017 1144L1006 1278L950 1139L444 0H327L193 1456H315L408 389Z" />
-<glyph unicode="X" horiz-adv-x="1225" d="M642 842L1135 1456H1287L703 732L1067 0H929L618 634L106 0H-45L558 744L204 1456H342L642 842Z" />
-<glyph unicode="Y" horiz-adv-x="1199" d="M600 664L1168 1456H1316L643 542L549 0H427L524 555L174 1456H311L600 664Z" />
-<glyph unicode="Z" horiz-adv-x="1198" d="M151 104H1020L1001 0H-18L-1 99L1051 1351H241L260 1456H1223L1207 1362L151 104Z" />
-<glyph unicode="[" horiz-adv-x="486" d="M630 1562H426L150 -210H354L337 -312H14L323 1664H646L630 1562Z" />
-<glyph unicode="\" horiz-adv-x="793" d="M197 1456H307L623 -125H512L197 1456Z" />
-<glyph unicode="]" horiz-adv-x="486" d="M165 1664H489L180 -312H-144L-127 -210H77L354 1562H149L165 1664Z" />
-<glyph unicode="^" horiz-adv-x="836" d="M532 1294L213 729H93L509 1456H599L762 729H653L532 1294Z" />
-<glyph unicode="_" horiz-adv-x="867" d="M736 -101H-122L-104 0H754L736 -101Z" />
-<glyph unicode="`" horiz-adv-x="577" d="M525 1256H425L249 1536H383L525 1256Z" />
-<glyph unicode="a" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603 1103Q770
-1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85Z" />
-<glyph unicode="b" horiz-adv-x="1111" d="M986 536Q951 278 822 126T501 -21Q395 -19 315 26T191 148L157 0H45L312 1536H430L317 925Q456 1108 668 1102Q823 1098 907 987T994 680Q995 616 988 557L986 536ZM869 559L876 654Q879 817 819 906T640 999Q421 1003
-297 777L215 287Q244 190 314 138T486 82Q635 79 735 197T869 559Z" />
-<glyph unicode="c" horiz-adv-x="1033" d="M465 80Q583 76 673 145T794 333H907Q877 172 750 74T459 -21Q328 -18 239 51T111 242T85 517L89 560Q101 665 140 764T246 939T403 1060T610 1102Q776 1098 874 990T966 716L853 717Q855 842 788 919T605 1000Q481 1004
-386 928T243 713T198 418Q201 257 270 171T465 80Z" />
-<glyph unicode="d" horiz-adv-x="1114" d="M94 544Q117 714 187 845T358 1041T586 1102Q682 1100 761 1058T886 929L996 1536H1114L847 0H736L763 144Q622 -26 413 -20Q262 -16 177 97T87 403Q85 465 92 523L94 544ZM214 524Q206 457 208 381Q212 244 271 166T441
-83Q552 80 636 134T778 278L865 788Q836 885 770 940T600 999Q448 1004 347 883T216 545L214 524Z" />
-<glyph unicode="e" horiz-adv-x="1036" d="M475 -20Q345 -18 250 52T111 244T79 507L82 541Q96 691 171 826T361 1033T607 1102Q728 1100 811 1036T933 858T957 606L949 533H200L197 509Q182 400 213 301T314 143T484 82Q580 79 657 119T799 226L869 169Q796 75
-696 27T475 -20ZM601 1000Q471 1005 368 908T213 635L841 634L844 649Q862 791 794 893T601 1000Z" />
-<glyph unicode="f" horiz-adv-x="668" d="M129 0L300 984H126L144 1082H317L338 1229Q363 1388 459 1475T700 1560Q758 1558 831 1540L810 1441Q754 1456 703 1456Q603 1456 538 1391T455 1210L436 1082H687L669 984H420L249 0H129Z" />
-<glyph unicode="g" horiz-adv-x="1112" d="M585 1103Q682 1100 762 1057T888 926L925 1082H1036L854 19Q835 -117 768 -221T597 -380T364 -432Q262 -430 169 -381Q75 -331 18 -242L92 -172Q195 -327 361 -331Q509 -335 608 -242T734 13L760 139Q616 -26 413 -20Q261
--16 177 96T88 403Q82 582 148 757T327 1019T585 1103ZM213 523L207 430Q204 266 264 177T441 83Q541 79 628 130T778 281L863 786Q836 883 770 939T599 999Q446 1004 346 881T213 523Z" />
-<glyph unicode="h" horiz-adv-x="1100" d="M313 899Q469 1106 681 1102Q837 1098 908 993T958 704L840 0H722L840 706Q846 763 842 816Q825 994 648 999Q543 1001 452 937T292 742L164 0H46L313 1536H431L313 899Z" />
-<glyph unicode="i" horiz-adv-x="455" d="M179 0H59L248 1082H367L179 0ZM281 1395Q286 1460 367 1477Q406 1470 422 1453T444 1395Q434 1357 415 1340T358 1314Q277 1326 281 1395Z" />
-<glyph unicode="j" horiz-adv-x="463" d="M362 1082L156 -129Q136 -280 51 -362T-167 -440Q-210 -439 -276 -419L-262 -320Q-207 -335 -174 -335Q1 -339 38 -124L244 1082H362ZM278 1395Q280 1428 303 1452T362 1477T419 1454T439 1395Q436 1361 412 1338T353
-1314Q318 1313 297 1336T278 1395Z" />
-<glyph unicode="k" horiz-adv-x="983" d="M396 543L236 408L165 0H46L313 1536H432L262 562L386 676L857 1082H1016L484 621L857 0H725L396 543Z" />
-<glyph unicode="l" horiz-adv-x="455" d="M179 0H59L326 1536H446L179 0Z" />
-<glyph unicode="m" horiz-adv-x="1771" d="M343 1082L309 906Q455 1106 676 1102Q790 1100 865 1045T959 892Q1033 993 1131 1048T1346 1102Q1500 1099 1574 1001T1636 728L1634 705L1515 0H1396L1514 707Q1520 766 1515 819Q1495 996 1313 999Q1191 1001 1089
-920T960 716L836 0H717L837 716Q866 992 634 999Q519 1001 420 927T287 743L159 0H40L228 1082H343Z" />
-<glyph unicode="n" horiz-adv-x="1101" d="M348 1082L312 897Q384 997 478 1050T681 1102Q837 1098 908 993T958 704L840 0H722L840 706Q846 763 842 816Q825 994 648 999Q543 1001 452 937T292 742L164 0H46L234 1082H348Z" />
-<glyph unicode="o" horiz-adv-x="1123" d="M75 551Q93 708 171 838T365 1037T618 1102Q752 1100 846 1029T984 834T1014 560L1012 541Q982 285 831 130T467 -20Q285 -17 176 114T69 460L72 517L75 551ZM191 517Q178 398 208 298T306 140T473 80Q581 78 670 135T818
-296T893 526L896 559Q914 752 837 874T612 1000Q452 1005 336 877T193 535L191 517Z" />
-<glyph unicode="p" horiz-adv-x="1111" d="M500 -21Q407 -19 325 18T191 136L91 -416H-27L233 1082H343L315 929Q456 1108 668 1102Q820 1098 905 989T993 680Q994 617 987 558L983 530Q958 355 889 228T721 39T500 -21ZM868 558L874 653Q877 813 816 904T635
-999Q530 1001 445 948T300 792L211 271Q243 179 312 131T479 80Q624 75 724 188T860 505L868 558Z" />
-<glyph unicode="q" horiz-adv-x="1118" d="M95 545Q130 803 260 955T587 1102Q682 1100 761 1060T888 935L923 1082H1035L775 -416H656L758 134Q619 -26 415 -20Q263 -16 178 95T88 402Q86 464 93 523L95 545ZM214 524L207 430Q204 266 263 175T442 80Q541 76
-626 125T775 267L866 799Q835 891 769 944T602 1000Q446 1005 345 879T216 545L214 524Z" />
-<glyph unicode="r" horiz-adv-x="678" d="M707 981Q668 989 628 990Q514 990 419 921T292 744L164 0H46L234 1082H351L315 910Q374 1006 457 1056T641 1104Q676 1104 723 1090L707 981Z" />
-<glyph unicode="s" horiz-adv-x="1016" d="M730 282Q746 420 562 482L390 533Q153 613 166 800Q173 935 290 1019T570 1102Q729 1100 828 1013T920 779H802Q808 876 742 937T565 1000Q451 1000 373 947T285 805Q270 676 443 624L568 588L635 565Q861 480 848 288Q840
-158 736 75T466 -19L425 -20Q316 -18 228 22T93 136T52 304L171 303Q171 201 240 142T430 81Q550 81 634 135T730 282Z" />
-<glyph unicode="t" horiz-adv-x="648" d="M465 1359L417 1082H634L617 984H400L280 262L278 200Q278 91 378 88Q409 87 475 95L470 -3Q411 -20 350 -18Q245 -16 197 55T162 263L281 984H87L105 1082H297L346 1359H465Z" />
-<glyph unicode="u" horiz-adv-x="1101" d="M764 136Q635 -26 408 -20Q255 -17 180 90T126 389L242 1082H360L245 386Q239 332 244 279Q251 187 299 137T431 84Q551 79 653 139T785 298L919 1082H1039L851 0H735L764 136Z" />
-<glyph unicode="v" horiz-adv-x="965" d="M408 169L870 1082H996L435 0H338L113 1082H231L408 169Z" />
-<glyph unicode="w" horiz-adv-x="1508" d="M342 249V164L381 257L776 1082H878L985 255L991 153L1032 256L1390 1082H1517L1023 0H921L802 858L801 918L778 857L364 0H262L147 1082L259 1083L342 249Z" />
-<glyph unicode="x" horiz-adv-x="976" d="M484 645L835 1082H983L539 545L822 0H690L464 456L94 0H-52L410 557L139 1082H271L484 645Z" />
-<glyph unicode="y" horiz-adv-x="954" d="M408 176L871 1082H1004L344 -174Q271 -320 190 -381T8 -440Q-30 -438 -88 -424L-76 -326L-16 -333Q152 -340 249 -135L325 16L116 1082H241L408 176Z" />
-<glyph unicode="z" horiz-adv-x="976" d="M147 101H825L807 0H-21L-5 94L781 979H168L186 1082H953L936 987L147 101Z" />
-<glyph unicode="{" horiz-adv-x="666" d="M476 -402Q326 -351 257 -232T206 58L237 285Q243 338 237 384Q217 531 58 542L70 645Q300 654 338 899L372 1146Q426 1495 770 1599L788 1519Q532 1432 489 1125L455 884Q419 673 228 591Q345 527 357 374Q360 329 356
-284L325 57Q317 -5 322 -63Q335 -257 506 -323L476 -402Z" />
-<glyph unicode="|" horiz-adv-x="448" d="M136 -270H35L305 1456H406L136 -270Z" />
-<glyph unicode="}" horiz-adv-x="666" d="M-136 -325Q124 -236 166 71L198 304Q234 519 434 598Q374 626 339 681T297 813Q293 858 298 904L328 1133Q335 1194 332 1253Q327 1349 282 1417T153 1518L185 1595Q331 1543 399 1425T447 1132L417 903Q411 850 417
-805Q437 657 595 649L584 545Q348 535 313 275L282 44Q228 -303 -116 -406L-136 -325Z" />
-<glyph unicode="~" horiz-adv-x="1370" d="M1240 764Q1221 609 1132 514T914 422Q795 425 681 527L591 613Q515 681 439 681Q263 684 222 451L118 449Q137 606 225 698T444 789Q560 786 672 689L767 599Q842 530 920 528Q1003 526 1061 586T1141 763L1240 764Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="493" />
-<glyph unicode="&#xa1;" horiz-adv-x="448" d="M183 690H294L118 -359H-5L183 690ZM370 1022Q368 989 344 966T285 941Q250 940 228 963T208 1022Q211 1056 235 1079T294 1103Q329 1104 351 1081T370 1022Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1092" d="M484 80Q604 76 694 145T817 333H930Q902 189 793 95T524 -18L481 -245H361L405 -14Q308 4 247 57Q130 159 112 344Q94 521 145 694T314 973T591 1099L633 1318H753L710 1097Q851 1072 926 969T996 716L883 717Q887
-841 821 918T639 1000Q470 1005 360 872T227 499L224 419Q224 261 290 173T484 80Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1145" d="M401 645L364 376Q340 200 252 102L977 104L959 0H-11L7 103L99 102Q212 144 242 367L279 645H97L115 749H294L331 1031Q358 1238 484 1359T791 1477Q955 1473 1045 1366T1119 1088H997Q1010 1211 953 1289T776
-1372Q650 1375 563 1283T453 1025L416 749H750L732 645H401Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1447" d="M1023 131Q831 -24 620 -20Q519 -18 427 20T265 132L85 -26L12 66L195 222Q114 401 141 601Q172 829 338 1010L205 1183L298 1265L429 1096Q619 1238 819 1234Q916 1232 1005 1197T1164 1092L1361 1265L1435 1171L1238
-1001Q1324 815 1296 614Q1269 399 1111 222L1241 54L1147 -28L1023 131ZM252 599Q240 507 259 417T326 256T450 138T627 89Q760 85 882 156T1085 352T1185 616Q1202 744 1159 862T1024 1050T811 1123Q681 1127 561 1060T356 868T252 599Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1034" d="M531 734L1010 1456H1153L635 705H936L920 616H573L537 412H885L869 324H523L466 0H343L400 324H56L72 412H415L451 616H107L123 705H430L174 1456H305L531 734Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="441" d="M2 -270L136 501H256L121 -270H2ZM289 698H170L302 1456H421L289 698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1212" d="M1066 439Q1049 240 793 155Q940 55 924 -131Q915 -245 848 -327T665 -454T418 -495Q210 -493 93 -378T-7 -64L112 -62Q97 -210 181 -300T423 -393Q571 -398 679 -327T803 -134Q813 -46 761 15T584 120L422 173L342
-204Q84 313 104 543Q121 742 368 829Q228 930 245 1112Q254 1224 323 1307T506 1435T753 1476Q954 1472 1061 1355T1149 1045H1031Q1045 1190 968 1280T748 1374Q589 1376 485 1307T366 1115Q344 948 542 871L777 791Q936 734 1006 650T1066 439ZM615 729L483 772Q249
-733 224 546Q211 453 267 388T488 271T668 213Q790 231 861 288T945 435Q957 526 896 592T679 709L615 729Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="865" d="M256 1396Q258 1430 284 1454T341 1478Q376 1479 398 1455T419 1396Q417 1365 392 1341T333 1316T277 1338T256 1396ZM681 1395Q683 1429 709 1453T766 1477Q801 1478 823 1454T843 1395Q841 1362 816 1339T758 1315Q724
-1315 702 1337T681 1395Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1598" d="M1101 607Q1082 455 992 372T762 292Q620 296 546 406T485 680L493 758Q513 946 615 1056T868 1164Q1005 1160 1076 1077T1137 850H1039Q1057 1071 864 1075Q758 1077 685 995T595 777L585 679Q572 550 620 468T766
-382Q964 375 1006 606L1101 607ZM219 562Q241 345 379 206T717 65Q912 61 1085 178T1355 494T1430 896Q1414 1038 1346 1150T1171 1324T932 1389Q788 1392 653 1328T411 1141T254 864T219 562ZM135 722Q157 919 270 1096T560 1377T933 1476Q1112 1474 1254 1376T1466
-1102T1513 735Q1488 529 1371 351T1079 74T716 -21Q532 -17 392 81T182 356T135 722Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="889" d="M657 703Q651 751 654 798Q555 690 427 690Q324 690 264 749T209 900Q214 1014 307 1077T560 1141L697 1140L706 1202Q710 1237 706 1269Q692 1377 583 1380Q507 1382 452 1348T377 1238L273 1244Q288 1353 375 1416T589
-1477Q706 1473 766 1398T816 1200L767 886Q752 793 762 704L657 703ZM450 784Q563 784 658 889L688 1058L562 1059Q455 1059 391 1019T319 905Q314 846 349 815T450 784Z" />
-<glyph unicode="&#xab;" horiz-adv-x="915" d="M228 786L426 404H331L106 782L108 801L456 1181H570L228 786ZM528 530L726 148H631L406 526L408 545L756 925H870L528 530Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1093" d="M872 386H753L803 670H131L150 776H940L872 386Z" />
-<glyph unicode="&#xad;" horiz-adv-x="578" d="M512 592H45L63 693H530L512 592Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1603" d="M130 722Q155 929 270 1104T559 1379T928 1476Q1105 1474 1247 1377T1461 1103T1510 735Q1492 584 1421 443T1238 195T990 32T711 -21Q527 -17 387 81T177 356T130 722ZM214 562Q236 346 374 207T712 65Q855 62
-989 125T1231 312T1389 589T1425 896Q1411 1034 1344 1147T1168 1323T927 1389Q784 1392 648 1328T407 1143T250 869T214 562ZM655 666L600 321H502L634 1160L878 1159Q1011 1154 1079 1093T1141 919Q1131 787 975 711Q1058 669 1067 571L1066 509Q1056 433 1057
-400L1059 337L1057 321H959Q954 357 956 393L962 465L967 509Q974 584 947 622T842 665L655 666ZM668 757L839 756Q921 758 979 800T1047 917Q1067 1068 877 1069L718 1070L668 757Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="858" d="M851 1343H247L263 1440H866L851 1343Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="761" d="M249 1217Q253 1323 331 1401T511 1477Q603 1475 664 1404T722 1235Q718 1129 642 1053T464 979Q368 981 307 1052T249 1217ZM339 1219Q333 1157 370 1114T466 1070Q533 1070 580 1117T633 1233Q639 1294 605 1340T508
-1386Q444 1386 395 1339T339 1219Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1062" d="M628 829H1008L991 727H612L543 289H433L502 727H100L116 829H517L586 1267H697L628 829ZM842 0H29L45 101H858L842 0Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="728" d="M659 665H103L117 745L488 1066Q598 1164 608 1247Q616 1311 580 1345T481 1380Q400 1381 350 1337T283 1216H180Q196 1332 280 1400T482 1467Q594 1465 658 1405T716 1248Q709 1133 560 1004L497 950L255 752H675L659 665Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="728" d="M345 1106H421Q510 1109 565 1149Q617 1187 623 1248Q629 1310 590 1344T485 1379Q418 1380 368 1346T299 1247L195 1246Q210 1349 291 1409T486 1467Q598 1465 666 1407T728 1251Q721 1133 559 1065Q690 1021 684
-888Q679 781 592 717T380 654Q262 656 190 718T122 885H225Q222 822 265 782T385 742Q467 742 520 782T581 890Q594 1019 417 1024L336 1025L345 1106Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="569" d="M447 1536L598 1535L330 1257L218 1256L447 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1116" d="M358 1082L253 448L247 368V321Q256 87 439 80Q561 76 657 138T784 311L916 1082H1035L847 0H739L766 154Q645 -24 441 -20Q265 -15 192 106L98 -416H-20L240 1082H358Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="954" d="M566 0L657 520L574 521Q362 523 250 650T159 980Q182 1195 334 1326T710 1457L938 1456L685 0H566Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="498" d="M178 717Q180 752 205 776T265 801Q302 801 324 777T345 717Q342 682 317 659T256 634Q220 633 198 657T178 717Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="493" d="M131 0L109 -66Q250 -92 244 -228Q239 -326 155 -380T-75 -437L-74 -358Q22 -355 79 -322T145 -231Q154 -152 51 -134L-4 -126L41 0H131Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="728" d="M462 665H357L472 1325L234 1256L251 1350L579 1455H596L462 665Z" />
-<glyph unicode="&#xba;" horiz-adv-x="904" d="M585 1477Q720 1473 794 1377T855 1132L845 1033Q826 879 728 782T485 689Q350 693 276 788T213 1033L222 1121Q239 1284 340 1382T585 1477ZM323 1031Q311 920 356 853T491 784Q587 780 654 850T737 1042L748 1133Q758
-1243 713 1310T579 1381Q479 1383 413 1312T333 1123L323 1031Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="910" d="M270 944L494 562L492 542L144 162H30L371 556L174 944H270ZM580 944L804 562L802 542L454 162H340L681 556L484 944H580Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1449" d="M450 664H345L460 1324L222 1255L239 1349L567 1454H584L450 664ZM327 130L255 183L1140 1314L1208 1265L327 130ZM1179 275H1303L1287 187H1164L1131 0H1026L1060 187H675L679 252L1154 789H1269L1179 275ZM801
-275H1074L1147 660L1108 609L801 275Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1512" d="M284 130L212 183L1097 1314L1165 1265L284 130ZM436 664H331L446 1324L208 1255L225 1349L553 1454H570L436 664ZM1290 0H734L748 80L1119 401Q1229 499 1239 582Q1247 646 1211 680T1112 715Q1031 716 981 672T914
-551H811Q827 667 911 735T1113 802Q1225 800 1289 740T1347 583Q1340 468 1191 339L1128 285L886 87H1306L1290 0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1552" d="M467 130L395 183L1280 1314L1348 1265L467 130ZM1290 275H1414L1398 187H1275L1242 0H1137L1171 187H786L790 252L1265 789H1380L1290 275ZM912 275H1185L1258 660L1219 609L912 275ZM390 1106H466Q555 1109 610
-1149Q662 1187 668 1248Q674 1310 635 1344T530 1379Q463 1380 413 1346T344 1247L240 1246Q255 1349 336 1409T531 1467Q643 1465 711 1407T773 1251Q766 1133 604 1065Q735 1021 729 888Q724 781 637 717T425 654Q307 656 235 718T167 885H270Q267 822 310 782T430
-742Q512 742 565 782T626 890Q639 1019 462 1024L381 1025L390 1106Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="922" d="M554 688Q539 580 498 507T372 359T267 265Q125 131 109 -17Q96 -136 151 -206T315 -279Q425 -283 504 -215T610 -21L727 -20Q702 -190 588 -289T307 -384Q145 -380 59 -277T-11 -18Q7 174 198 349L336 469Q415 547
-439 687L554 688ZM632 1022Q630 988 604 964T547 940Q512 939 490 963T470 1022Q473 1055 498 1078T556 1102Q590 1103 612 1080T632 1022Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513ZM861 1571H761L585 1851H719L861 1571Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513ZM947 1851L1098 1850L830 1572L718 1571L947 1851Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513ZM1067 1584L1066 1572L958 1573L829 1754L635 1574L525 1573L526 1587L796 1841H869L1067 1584Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513ZM1159 1809Q1145 1709 1089 1652T949 1594Q918 1594 893 1604T818 1649T743 1695T687 1707Q641 1707 608 1676T560 1589L471
-1592Q485 1688 542 1747T683 1805Q721 1805 752 1788T815 1749T879 1709T947 1692Q1039 1692 1075 1814L1159 1809Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513ZM522 1711Q524 1745 550 1769T607 1793Q642 1794 664 1770T685 1711Q683 1680 658 1656T599 1631T543 1653T522 1711ZM947
-1710Q949 1744 975 1768T1032 1792Q1067 1793 1089 1769T1109 1710Q1107 1677 1082 1654T1024 1630Q990 1630 968 1652T947 1710Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1251" d="M909 408H271L54 0H-79L708 1456H825L1106 0H985L909 408ZM326 513H889L745 1302L326 513ZM631 1707Q633 1790 692 1848T831 1906Q906 1906 957 1853T1007 1723Q1005 1643 947 1585T806 1527Q731 1527 680 1578T631
-1707ZM708 1709Q704 1663 730 1631T802 1599Q850 1599 887 1633T931 1721Q935 1769 908 1801T835 1834Q788 1834 750 1797T708 1709Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1819" d="M1666 0H871L922 389H350L59 0H-93L1015 1456H1859L1841 1354H1168L1096 809H1668L1650 707H1082L1002 101H1684L1666 0ZM434 502H938L1047 1320L434 502Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1300" d="M1150 454Q1099 229 943 102T562 -20Q367 -16 252 118T127 481Q124 559 134 636L161 812Q192 1013 285 1168T513 1401T808 1476Q1016 1472 1133 1344T1248 999L1127 1000Q1127 1175 1043 1271T802 1372Q604 1377
-465 1225T283 803L253 603L249 513Q247 395 283 294T393 140T568 84Q742 78 859 171T1031 453L1150 454ZM597 -9L575 -75Q716 -101 710 -237Q705 -335 621 -389T391 -446L392 -367Q488 -364 545 -331T611 -240Q620 -161 517 -143L462 -135L507 -9H597Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1140" d="M977 698H317L213 104H973L955 0H73L326 1456H1203L1184 1351H430L334 802H995L977 698ZM839 1577H739L563 1857H697L839 1577Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1140" d="M977 698H317L213 104H973L955 0H73L326 1456H1203L1184 1351H430L334 802H995L977 698ZM925 1857L1076 1856L808 1578L696 1577L925 1857Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1140" d="M977 698H317L213 104H973L955 0H73L326 1456H1203L1184 1351H430L334 802H995L977 698ZM1045 1590L1044 1578L936 1579L807 1760L613 1580L503 1579L504 1593L774 1847H847L1045 1590Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1140" d="M977 698H317L213 104H973L955 0H73L326 1456H1203L1184 1351H430L334 802H995L977 698ZM500 1717Q502 1751 528 1775T585 1799Q620 1800 642 1776T663 1717Q661 1686 636 1662T577 1637T521 1659T500 1717ZM925
-1716Q927 1750 953 1774T1010 1798Q1045 1799 1067 1775T1087 1716Q1085 1683 1060 1660T1002 1636Q968 1636 946 1658T925 1716Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="539" d="M221 0H99L352 1456H474L221 0ZM505 1577H405L229 1857H363L505 1577Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="539" d="M221 0H99L352 1456H474L221 0ZM590 1857L741 1856L473 1578L361 1577L590 1857Z" />
-<glyph unicode="&#xce;" horiz-adv-x="539" d="M221 0H99L352 1456H474L221 0ZM711 1590L710 1578L602 1579L473 1760L279 1580L169 1579L170 1593L440 1847H513L711 1590Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="539" d="M221 0H99L352 1456H474L221 0ZM166 1717Q168 1751 194 1775T251 1799Q286 1800 308 1776T329 1717Q327 1686 302 1662T243 1637T187 1659T166 1717ZM591 1716Q593 1750 619 1774T676 1798Q711 1799 733 1775T753
-1716Q751 1683 726 1660T668 1636Q634 1636 612 1658T591 1716Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1341" d="M103 0L222 689H47L65 791H240L356 1456L735 1455Q904 1455 1028 1369T1207 1130T1240 794L1222 673Q1176 370 980 185T499 0H103ZM643 689H345L243 104L503 103Q656 103 782 173T990 370T1098 658T1125 880T1119
-998Q1096 1158 997 1252T741 1350L460 1351L362 791H661L643 689Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1420" d="M1128 0H1010L413 1248L196 0H73L326 1456H444L1042 207L1259 1456H1380L1128 0ZM1240 1809Q1226 1709 1170 1652T1030 1594Q999 1594 974 1604T899 1649T824 1695T768 1707Q722 1707 689 1676T641 1589L552 1592Q566
-1688 623 1747T764 1805Q802 1805 833 1788T896 1749T960 1709T1028 1692Q1120 1692 1156 1814L1240 1809Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1354" d="M577 -20Q373 -16 254 121T124 489Q120 569 131 648L151 786Q196 1091 371 1284Q550 1481 813 1476Q947 1473 1047 1411T1204 1229T1265 966Q1268 880 1256 798L1233 644Q1198 438 1104 284T874 54T577 -20ZM1136
-809Q1144 872 1145 937Q1145 1059 1107 1159T993 1312T807 1369Q607 1374 466 1226T280 824Q244 619 245 521Q245 319 333 205T583 87Q796 82 935 241T1114 661L1136 809ZM910 1583H810L634 1863H768L910 1583Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1354" d="M577 -20Q373 -16 254 121T124 489Q120 569 131 648L151 786Q196 1091 371 1284Q550 1481 813 1476Q947 1473 1047 1411T1204 1229T1265 966Q1268 880 1256 798L1233 644Q1198 438 1104 284T874 54T577 -20ZM1136
-809Q1144 872 1145 937Q1145 1059 1107 1159T993 1312T807 1369Q607 1374 466 1226T280 824Q244 619 245 521Q245 319 333 205T583 87Q796 82 935 241T1114 661L1136 809ZM996 1863L1147 1862L879 1584L767 1583L996 1863Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1354" d="M577 -20Q373 -16 254 121T124 489Q120 569 131 648L151 786Q196 1091 371 1284Q550 1481 813 1476Q947 1473 1047 1411T1204 1229T1265 966Q1268 880 1256 798L1233 644Q1198 438 1104 284T874 54T577 -20ZM1136
-809Q1144 872 1145 937Q1145 1059 1107 1159T993 1312T807 1369Q607 1374 466 1226T280 824Q244 619 245 521Q245 319 333 205T583 87Q796 82 935 241T1114 661L1136 809ZM1116 1596L1115 1584L1007 1585L878 1766L684 1586L574 1585L575 1599L845 1853H918L1116
-1596Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1354" d="M577 -20Q373 -16 254 121T124 489Q120 569 131 648L151 786Q196 1091 371 1284Q550 1481 813 1476Q947 1473 1047 1411T1204 1229T1265 966Q1268 880 1256 798L1233 644Q1198 438 1104 284T874 54T577 -20ZM1136
-809Q1144 872 1145 937Q1145 1059 1107 1159T993 1312T807 1369Q607 1374 466 1226T280 824Q244 619 245 521Q245 319 333 205T583 87Q796 82 935 241T1114 661L1136 809ZM1208 1821Q1194 1721 1138 1664T998 1606Q967 1606 942 1616T867 1661T792 1707T736 1719Q690
-1719 657 1688T609 1601L520 1604Q534 1700 591 1759T732 1817Q770 1817 801 1800T864 1761T928 1721T996 1704Q1088 1704 1124 1826L1208 1821Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1354" d="M577 -20Q373 -16 254 121T124 489Q120 569 131 648L151 786Q196 1091 371 1284Q550 1481 813 1476Q947 1473 1047 1411T1204 1229T1265 966Q1268 880 1256 798L1233 644Q1198 438 1104 284T874 54T577 -20ZM1136
-809Q1144 872 1145 937Q1145 1059 1107 1159T993 1312T807 1369Q607 1374 466 1226T280 824Q244 619 245 521Q245 319 333 205T583 87Q796 82 935 241T1114 661L1136 809ZM571 1723Q573 1757 599 1781T656 1805Q691 1806 713 1782T734 1723Q732 1692 707 1668T648
-1643T592 1665T571 1723ZM996 1722Q998 1756 1024 1780T1081 1804Q1116 1805 1138 1781T1158 1722Q1156 1689 1131 1666T1073 1642Q1039 1642 1017 1664T996 1722Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1050" d="M17 184L428 550L155 900L242 975L512 625L906 974L974 888L580 539L865 173L779 99L495 463L85 100L17 184Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1354" d="M575 -21Q397 -17 281 77L153 -82H41L218 136Q117 292 120 516Q121 613 157 823T301 1195T567 1427Q683 1479 813 1476Q909 1474 998 1441T1153 1336L1288 1504H1399L1207 1267Q1255 1158 1265 1040Q1275 921 1258
-806L1236 663Q1203 449 1108 292T877 56T582 -21H575ZM241 544Q231 361 291 235L1081 1240Q988 1366 808 1370Q601 1375 459 1219T275 795L247 614L241 544ZM1151 986Q1151 1074 1127 1160L349 168Q437 91 582 86Q714 83 823 147T1009 343T1115 668T1147 901T1151
-986Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1316" d="M1306 1456L1137 471Q1101 241 944 108T562 -21Q421 -18 319 44T170 218T140 469L309 1456H430L262 468Q241 299 324 195T568 84Q736 78 857 177T1011 452L1183 1456H1306ZM899 1571H799L623 1851H757L899 1571Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1316" d="M1306 1456L1137 471Q1101 241 944 108T562 -21Q421 -18 319 44T170 218T140 469L309 1456H430L262 468Q241 299 324 195T568 84Q736 78 857 177T1011 452L1183 1456H1306ZM985 1851L1136 1850L868 1572L756 1571L985
-1851Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1316" d="M1306 1456L1137 471Q1101 241 944 108T562 -21Q421 -18 319 44T170 218T140 469L309 1456H430L262 468Q241 299 324 195T568 84Q736 78 857 177T1011 452L1183 1456H1306ZM1105 1584L1104 1572L996 1573L867 1754L673
-1574L563 1573L564 1587L834 1841H907L1105 1584Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1316" d="M1306 1456L1137 471Q1101 241 944 108T562 -21Q421 -18 319 44T170 218T140 469L309 1456H430L262 468Q241 299 324 195T568 84Q736 78 857 177T1011 452L1183 1456H1306ZM560 1711Q562 1745 588 1769T645 1793Q680
-1794 702 1770T723 1711Q721 1680 696 1656T637 1631T581 1653T560 1711ZM985 1710Q987 1744 1013 1768T1070 1792Q1105 1793 1127 1769T1147 1710Q1145 1677 1120 1654T1062 1630Q1028 1630 1006 1652T985 1710Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1199" d="M600 664L1168 1456H1316L643 542L549 0H427L524 555L174 1456H311L600 664ZM916 1845L1067 1844L799 1566L687 1565L916 1845Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1188" d="M444 1456L391 1152L696 1151Q819 1148 913 1097T1053 954T1088 745Q1076 617 1007 522T822 375T568 323L248 324L191 0H72L325 1456H444ZM374 1051L265 425L572 424Q729 424 840 512T968 744Q984 878 908 962T694
-1050L374 1051Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1174" d="M160 0H41L234 1127Q262 1327 371 1438T645 1544Q785 1540 866 1457T936 1246Q932 1199 917 1157T846 1023T776 894T756 814Q748 756 776 702T879 574T985 440T1013 316Q1004 167 885 71T603 -21Q523 -21 442 0T308
-62L354 161Q459 81 593 79Q710 77 796 143T896 315Q903 375 874 430T771 558T664 690T638 816Q643 865 661 908T726 1029T792 1148T817 1240Q827 1323 780 1381T647 1444Q529 1449 452 1367T352 1128L160 0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603
-1103Q770 1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85ZM745 1256H645L469 1536H603L745 1256Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603
-1103Q770 1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85ZM831 1536L982 1535L714 1257L602 1256L831 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603
-1103Q770 1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85ZM951 1269L950 1257L842 1258L713 1439L519 1259L409 1258L410 1272L680 1526H753L951
-1269Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603
-1103Q770 1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85ZM1043 1494Q1029 1394 973 1337T833 1279Q802 1279 777 1289T702 1334T627 1380T571
-1392Q525 1392 492 1361T444 1274L355 1277Q369 1373 426 1432T567 1490Q605 1490 636 1473T699 1434T763 1394T831 1377Q923 1377 959 1499L1043 1494Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603
-1103Q770 1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85ZM406 1396Q408 1430 434 1454T491 1478Q526 1479 548 1455T569 1396Q567 1365 542
-1341T483 1316T427 1338T406 1396ZM831 1395Q833 1429 859 1453T916 1477Q951 1478 973 1454T993 1395Q991 1362 966 1339T908 1315Q874 1315 852 1337T831 1395Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1074" d="M719 0Q714 38 716 76L725 151Q650 70 554 24T345 -20Q208 -18 123 66T46 279Q54 386 119 464T306 586T577 630L798 629L816 753Q828 864 768 931T591 1002Q473 1004 386 944T276 784H159Q179 926 305 1015T603
-1103Q770 1099 860 1002T934 750L844 206L836 119Q833 65 844 12L842 0H719ZM365 85Q475 81 575 137T742 298L783 537L592 538Q410 538 295 474T168 289Q159 201 214 144T365 85ZM515 1392Q517 1475 576 1533T715 1591Q790 1591 841 1538T891 1408Q889 1328 831
-1270T690 1212Q615 1212 564 1263T515 1392ZM592 1394Q588 1348 614 1316T686 1284Q734 1284 771 1318T815 1406Q819 1454 792 1486T719 1519Q672 1519 634 1482T592 1394Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1690" d="M1134 -19Q1012 -17 918 37T781 186Q700 80 584 29T336 -20Q188 -18 106 65T33 285Q45 449 174 541T510 633L765 632L777 721Q791 851 741 924T583 1001Q460 1003 372 941T260 766L145 778Q165 927 289 1017T591
-1102Q710 1100 789 1043T890 890Q1055 1106 1277 1102Q1458 1098 1550 970T1618 638L1603 538H871L866 508Q855 431 863 356Q875 232 947 159T1139 82Q1308 78 1470 199L1509 110Q1358 -23 1134 -19ZM358 80Q445 78 535 119T697 235L750 536L510 537Q366 537 266
-467T153 281Q144 186 201 133T358 80ZM1269 1001Q1141 1004 1042 913T884 636H1499Q1513 729 1504 791Q1489 888 1428 943T1269 1001Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1033" d="M465 80Q583 76 673 145T794 333H907Q877 172 750 74T459 -21Q328 -18 239 51T111 242T85 517L89 560Q101 665 140 764T246 939T403 1060T610 1102Q776 1098 874 990T966 716L853 717Q855 842 788 919T605 1000Q481
-1004 386 928T243 713T198 418Q201 257 270 171T465 80ZM473 -9L451 -75Q592 -101 586 -237Q581 -335 497 -389T267 -446L268 -367Q364 -364 421 -331T487 -240Q496 -161 393 -143L338 -135L383 -9H473Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1036" d="M475 -20Q345 -18 250 52T111 244T79 507L82 541Q96 691 171 826T361 1033T607 1102Q728 1100 811 1036T933 858T957 606L949 533H200L197 509Q182 400 213 301T314 143T484 82Q580 79 657 119T799 226L869 169Q796
-75 696 27T475 -20ZM601 1000Q471 1005 368 908T213 635L841 634L844 649Q862 791 794 893T601 1000ZM721 1256H621L445 1536H579L721 1256Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1036" d="M475 -20Q345 -18 250 52T111 244T79 507L82 541Q96 691 171 826T361 1033T607 1102Q728 1100 811 1036T933 858T957 606L949 533H200L197 509Q182 400 213 301T314 143T484 82Q580 79 657 119T799 226L869 169Q796
-75 696 27T475 -20ZM601 1000Q471 1005 368 908T213 635L841 634L844 649Q862 791 794 893T601 1000ZM807 1536L958 1535L690 1257L578 1256L807 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1036" d="M475 -20Q345 -18 250 52T111 244T79 507L82 541Q96 691 171 826T361 1033T607 1102Q728 1100 811 1036T933 858T957 606L949 533H200L197 509Q182 400 213 301T314 143T484 82Q580 79 657 119T799 226L869 169Q796
-75 696 27T475 -20ZM601 1000Q471 1005 368 908T213 635L841 634L844 649Q862 791 794 893T601 1000ZM927 1269L926 1257L818 1258L689 1439L495 1259L385 1258L386 1272L656 1526H729L927 1269Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1036" d="M475 -20Q345 -18 250 52T111 244T79 507L82 541Q96 691 171 826T361 1033T607 1102Q728 1100 811 1036T933 858T957 606L949 533H200L197 509Q182 400 213 301T314 143T484 82Q580 79 657 119T799 226L869 169Q796
-75 696 27T475 -20ZM601 1000Q471 1005 368 908T213 635L841 634L844 649Q862 791 794 893T601 1000ZM382 1396Q384 1430 410 1454T467 1478Q502 1479 524 1455T545 1396Q543 1365 518 1341T459 1316T403 1338T382 1396ZM807 1395Q809 1429 835 1453T892 1477Q927
-1478 949 1454T969 1395Q967 1362 942 1339T884 1315Q850 1315 828 1337T807 1395Z" />
-<glyph unicode="&#xec;" horiz-adv-x="452" d="M177 0H57L246 1082H365L177 0ZM661 1500H561L385 1780H519L661 1500Z" />
-<glyph unicode="&#xed;" horiz-adv-x="452" d="M177 0H57L246 1082H365L177 0ZM490 1780L641 1779L373 1501L261 1500L490 1780Z" />
-<glyph unicode="&#xee;" horiz-adv-x="452" d="M177 0H57L246 1082H365L177 0ZM611 1257L610 1245L502 1246L373 1427L179 1247L69 1246L70 1260L340 1514H413L611 1257Z" />
-<glyph unicode="&#xef;" horiz-adv-x="452" d="M177 0H57L246 1082H365L177 0ZM66 1384Q68 1418 94 1442T151 1466Q186 1467 208 1443T229 1384Q227 1353 202 1329T143 1304T87 1326T66 1384ZM491 1383Q493 1417 519 1441T576 1465Q611 1466 633 1442T653 1383Q651
-1350 626 1327T568 1303Q534 1303 512 1325T491 1383Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1165" d="M912 1301Q1049 1085 1045 800Q1042 681 1018 527T925 249T759 56Q645 -25 506 -21Q383 -17 292 46T157 220T125 458Q139 604 206 721T383 904T625 966Q713 964 793 928T927 821Q931 1059 807 1239L563 1100L523
-1179L744 1304Q634 1408 441 1476L490 1577Q708 1504 852 1367L1063 1488L1103 1409L912 1301ZM916 686Q884 770 811 815T639 862Q481 866 374 755T245 458Q227 304 302 195T516 82Q666 77 769 207T901 558L910 626L916 686Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1101" d="M348 1082L312 897Q384 997 478 1050T681 1102Q837 1098 908 993T958 704L840 0H722L840 706Q846 763 842 816Q825 994 648 999Q543 1001 452 937T292 742L164 0H46L234 1082H348ZM1039 1493Q1025 1393 969 1336T829
-1278Q798 1278 773 1288T698 1333T623 1379T567 1391Q521 1391 488 1360T440 1273L351 1276Q365 1372 422 1431T563 1489Q601 1489 632 1472T695 1433T759 1393T827 1376Q919 1376 955 1498L1039 1493Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1123" d="M75 551Q93 708 171 838T365 1037T618 1102Q752 1100 846 1029T984 834T1014 560L1012 541Q982 285 831 130T467 -20Q285 -17 176 114T69 460L72 517L75 551ZM191 517Q178 398 208 298T306 140T473 80Q581 78 670
-135T818 296T893 526L896 559Q914 752 837 874T612 1000Q452 1005 336 877T193 535L191 517ZM725 1256H625L449 1536H583L725 1256Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1123" d="M75 551Q93 708 171 838T365 1037T618 1102Q752 1100 846 1029T984 834T1014 560L1012 541Q982 285 831 130T467 -20Q285 -17 176 114T69 460L72 517L75 551ZM191 517Q178 398 208 298T306 140T473 80Q581 78 670
-135T818 296T893 526L896 559Q914 752 837 874T612 1000Q452 1005 336 877T193 535L191 517ZM811 1536L962 1535L694 1257L582 1256L811 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1123" d="M75 551Q93 708 171 838T365 1037T618 1102Q752 1100 846 1029T984 834T1014 560L1012 541Q982 285 831 130T467 -20Q285 -17 176 114T69 460L72 517L75 551ZM191 517Q178 398 208 298T306 140T473 80Q581 78 670
-135T818 296T893 526L896 559Q914 752 837 874T612 1000Q452 1005 336 877T193 535L191 517ZM931 1269L930 1257L822 1258L693 1439L499 1259L389 1258L390 1272L660 1526H733L931 1269Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1123" d="M75 551Q93 708 171 838T365 1037T618 1102Q752 1100 846 1029T984 834T1014 560L1012 541Q982 285 831 130T467 -20Q285 -17 176 114T69 460L72 517L75 551ZM191 517Q178 398 208 298T306 140T473 80Q581 78 670
-135T818 296T893 526L896 559Q914 752 837 874T612 1000Q452 1005 336 877T193 535L191 517ZM1023 1493Q1009 1393 953 1336T813 1278Q782 1278 757 1288T682 1333T607 1379T551 1391Q505 1391 472 1360T424 1273L335 1276Q349 1372 406 1431T547 1489Q585 1489
-616 1472T679 1433T743 1393T811 1376Q903 1376 939 1498L1023 1493Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1123" d="M75 551Q93 708 171 838T365 1037T618 1102Q752 1100 846 1029T984 834T1014 560L1012 541Q982 285 831 130T467 -20Q285 -17 176 114T69 460L72 517L75 551ZM191 517Q178 398 208 298T306 140T473 80Q581 78 670
-135T818 296T893 526L896 559Q914 752 837 874T612 1000Q452 1005 336 877T193 535L191 517ZM386 1396Q388 1430 414 1454T471 1478Q506 1479 528 1455T549 1396Q547 1365 522 1341T463 1316T407 1338T386 1396ZM811 1395Q813 1429 839 1453T896 1477Q931 1478
-953 1454T973 1395Q971 1362 946 1339T888 1315Q854 1315 832 1337T811 1395Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1139" d="M1047 644H76L97 760H1068L1047 644ZM564 1088Q566 1123 591 1147T651 1172Q687 1173 710 1149T731 1088Q728 1053 703 1030T642 1005Q604 1005 582 1029T564 1088ZM426 291Q428 326 453 350T513 375Q549 376 572
-352T593 291Q590 256 565 233T504 209T446 231T426 291Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1116" d="M631 1104Q741 1100 833 1054L940 1214L1040 1213L901 1008Q1015 883 1021 680Q1024 475 953 316T750 66T459 -22Q361 -21 269 21L161 -140L61 -139L198 65Q76 187 69 396Q63 592 134 756T337 1014T631 1104ZM184
-425Q181 262 257 164L775 960Q704 1002 625 1003Q502 1006 402 931T244 721T184 425ZM905 649Q908 800 840 904L324 112Q389 80 464 78Q649 74 774 235T905 649Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1101" d="M764 136Q635 -26 408 -20Q255 -17 180 90T126 389L242 1082H360L245 386Q239 332 244 279Q251 187 299 137T431 84Q551 79 653 139T785 298L919 1082H1039L851 0H735L764 136ZM739 1256H639L463 1536H597L739 1256Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1101" d="M764 136Q635 -26 408 -20Q255 -17 180 90T126 389L242 1082H360L245 386Q239 332 244 279Q251 187 299 137T431 84Q551 79 653 139T785 298L919 1082H1039L851 0H735L764 136ZM825 1536L976 1535L708 1257L596
-1256L825 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1101" d="M764 136Q635 -26 408 -20Q255 -17 180 90T126 389L242 1082H360L245 386Q239 332 244 279Q251 187 299 137T431 84Q551 79 653 139T785 298L919 1082H1039L851 0H735L764 136ZM945 1269L944 1257L836 1258L707
-1439L513 1259L403 1258L404 1272L674 1526H747L945 1269Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1101" d="M764 136Q635 -26 408 -20Q255 -17 180 90T126 389L242 1082H360L245 386Q239 332 244 279Q251 187 299 137T431 84Q551 79 653 139T785 298L919 1082H1039L851 0H735L764 136ZM400 1396Q402 1430 428 1454T485
-1478Q520 1479 542 1455T563 1396Q561 1365 536 1341T477 1316T421 1338T400 1396ZM825 1395Q827 1429 853 1453T910 1477Q945 1478 967 1454T987 1395Q985 1362 960 1339T902 1315Q868 1315 846 1337T825 1395Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="954" d="M408 176L871 1082H1004L344 -174Q271 -320 190 -381T8 -440Q-30 -438 -88 -424L-76 -326L-16 -333Q152 -340 249 -135L325 16L116 1082H241L408 176ZM767 1536L918 1535L650 1257L538 1256L767 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1126" d="M504 -21Q411 -19 329 18T196 136L96 -416H-23L316 1536H435L323 932Q463 1108 672 1102Q828 1098 912 986T998 680Q998 617 992 558L990 542Q954 279 825 126Q696 -26 504 -21ZM873 558L879 653Q882 813 822 904T640
-999Q535 1001 450 948T305 792L216 269Q248 178 317 130T484 80Q635 75 737 196T873 558Z" />
-<glyph unicode="&#xff;" horiz-adv-x="954" d="M408 176L871 1082H1004L344 -174Q271 -320 190 -381T8 -440Q-30 -438 -88 -424L-76 -326L-16 -333Q152 -340 249 -135L325 16L116 1082H241L408 176ZM342 1396Q344 1430 370 1454T427 1478Q462 1479 484 1455T505
-1396Q503 1365 478 1341T419 1316T363 1338T342 1396ZM767 1395Q769 1429 795 1453T852 1477Q887 1478 909 1454T929 1395Q927 1362 902 1339T844 1315Q810 1315 788 1337T767 1395Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1304" d="M1401 686H426L448 788H1424L1401 686Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1543" d="M1444 686H143L173 788H1474L1444 686Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="363" d="M389 1555L458 1501Q353 1380 326 1257L302 1121H184L201 1230Q231 1422 389 1555Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="363" d="M227 1097L156 1153Q262 1277 288 1402L312 1536H429L411 1422Q380 1226 227 1097Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="352" d="M-28 -232L-95 -177Q8 -58 35 66L60 205H178L160 85Q127 -101 -28 -232Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="604" d="M390 1555L459 1501Q354 1380 327 1257L303 1121H185L202 1230Q232 1422 390 1555ZM633 1555L702 1501Q597 1380 570 1257L546 1121H428L445 1230Q475 1422 633 1555Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="608" d="M233 1097L162 1153Q268 1277 294 1402L318 1536H435L417 1422Q386 1226 233 1097ZM470 1097L399 1153Q505 1277 531 1402L555 1536H672L654 1422Q623 1226 470 1097Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="585" d="M-30 -241L-97 -186Q15 -53 39 87L65 236H183L160 90Q128 -107 -30 -241ZM207 -242L131 -185Q236 -62 263 75L291 236H410L384 71Q351 -113 207 -242Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="652" d="M165 745Q171 828 224 879T358 931Q434 931 479 884T525 755L524 718Q518 637 466 588T332 538Q256 538 210 586T164 710L165 745Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="601" d="M217 549L415 167H320L95 545L97 564L445 944H559L217 549Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="601" d="M253 944L477 562L475 542L127 162H13L354 556L157 944H253Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-300italic.ttf b/static/fonts/roboto-v18-latin-300italic.ttf
deleted file mode 100644
index 4f6315e7bd..0000000000
Binary files a/static/fonts/roboto-v18-latin-300italic.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300italic.woff b/static/fonts/roboto-v18-latin-300italic.woff
deleted file mode 100644
index a3bfbe3526..0000000000
Binary files a/static/fonts/roboto-v18-latin-300italic.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-300italic.woff2 b/static/fonts/roboto-v18-latin-300italic.woff2
deleted file mode 100644
index db95c87dcb..0000000000
Binary files a/static/fonts/roboto-v18-latin-300italic.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500.eot b/static/fonts/roboto-v18-latin-500.eot
deleted file mode 100644
index 849f4a50b7..0000000000
Binary files a/static/fonts/roboto-v18-latin-500.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500.svg b/static/fonts/roboto-v18-latin-500.svg
deleted file mode 100644
index 67eecf442f..0000000000
--- a/static/fonts/roboto-v18-latin-500.svg
+++ /dev/null
@@ -1,305 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1176" ><font-face
-    font-family="Roboto Medium"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="510" />
-<glyph unicode="!" horiz-adv-x="549" d="M382 429H173L150 1456H406L382 429ZM143 115Q143 172 180 209T281 247T382 210T419 115Q419 60 383 23T281 -14T179 23T143 115Z" />
-<glyph unicode="&quot;" horiz-adv-x="664" d="M275 1399L240 1012H101V1536H275V1399ZM576 1399L541 1012H402V1536H576V1399Z" />
-<glyph unicode="#" horiz-adv-x="1250" d="M719 410H495L419 0H251L327 410H96V568H357L415 881H172V1040H445L523 1456H690L612 1040H837L915 1456H1082L1004 1040H1212V881H974L916 568H1137V410H886L810 0H643L719 410ZM525 568H749L807 881H583L525 568Z" />
-<glyph unicode="$" horiz-adv-x="1164" d="M819 380Q819 465 765 520T585 620T389 703Q156 828 156 1073Q156 1239 257 1346T531 1473V1691H691V1471Q865 1446 960 1324T1055 1005H813Q813 1131 757 1203T603 1276Q507 1276 453 1224T399 1075Q399 988 452 936T634
-836T835 749T958 658T1035 539T1062 382Q1062 213 959 108T670 -16V-211H511V-17Q313 5 207 125T100 443H343Q343 317 406 248T586 179Q700 179 759 234T819 380Z" />
-<glyph unicode="%" horiz-adv-x="1504" d="M99 1176Q99 1308 184 1392T407 1477Q547 1477 631 1393T716 1171V1099Q716 968 632 884T409 800Q274 800 187 882T99 1105V1176ZM269 1099Q269 1030 307 988T409 945Q471 945 509 987T547 1103V1176Q547 1245 509 1288T407
-1331T307 1288T269 1173V1099ZM799 357Q799 491 886 574T1108 657Q1244 657 1330 574T1417 350V279Q1417 149 1334 65T1110 -20T885 63T799 284V357ZM969 279Q969 211 1008 168T1110 124Q1174 124 1210 165T1247 282V357Q1247 427 1208 469T1108 511Q1046 511 1008
-469T969 353V279ZM459 109L334 181L1045 1319L1170 1247L459 109Z" />
-<glyph unicode="&amp;" horiz-adv-x="1309" d="M86 393Q86 494 141 578T358 779Q273 886 240 961T206 1106Q206 1277 310 1376T590 1476Q749 1476 850 1383T952 1151Q952 1060 906 984T755 831L656 759L937 427Q998 547 998 694H1209Q1209 425 1083 253L1297 0H1015L933
-97Q777 -20 561 -20T216 94T86 393ZM568 174Q691 174 798 256L480 631L449 609Q329 518 329 401Q329 300 394 237T568 174ZM434 1112Q434 1028 537 901L648 977L679 1002Q741 1057 741 1143Q741 1200 698 1240T589 1281Q518 1281 476 1233T434 1112Z" />
-<glyph unicode="&apos;" horiz-adv-x="346" d="M267 1411L241 1020H82V1536H267V1411Z" />
-<glyph unicode="(" horiz-adv-x="714" d="M128 592Q128 823 190 1030T372 1401T626 1631L674 1489Q533 1382 446 1163T350 660L349 574Q349 271 434 34T674 -328L626 -463Q492 -397 372 -233T190 138T128 592Z" />
-<glyph unicode=")" horiz-adv-x="722" d="M593 576Q593 354 532 148T347 -228T88 -463L40 -328Q190 -212 277 26T365 571V594Q365 872 289 1100T71 1467L40 1495L88 1631Q216 1569 336 1411T520 1058T592 654L593 576Z" />
-<glyph unicode="*" horiz-adv-x="905" d="M332 972L27 1060L82 1229L384 1112L369 1456H548L533 1106L830 1221L884 1049L574 961L774 695L629 589L449 877L271 598L125 700L332 972Z" />
-<glyph unicode="+" horiz-adv-x="1141" d="M686 801H1066V579H686V146H450V579H68V801H450V1206H686V801Z" />
-<glyph unicode="," horiz-adv-x="450" d="M159 -328L28 -250Q86 -159 107 -92T130 46V235H349L348 60Q347 -46 295 -152T159 -328Z" />
-<glyph unicode="-" horiz-adv-x="672" d="M596 521H71V717H596V521Z" />
-<glyph unicode="." horiz-adv-x="572" d="M276 256Q344 256 381 218T418 121Q418 64 381 27T276 -11Q211 -11 173 26T135 121T172 217T276 256Z" />
-<glyph unicode="/" horiz-adv-x="810" d="M193 -125H2L575 1456H766L193 -125Z" />
-<glyph unicode="0" horiz-adv-x="1164" d="M1058 613Q1058 299 941 140T583 -20Q347 -20 228 135T105 596V848Q105 1162 222 1319T581 1476Q820 1476 937 1323T1058 865V613ZM815 885Q815 1090 759 1185T581 1281Q462 1281 406 1191T347 908V578Q347 374 404 274T583
-174Q700 174 756 266T815 556V885Z" />
-<glyph unicode="1" horiz-adv-x="1164" d="M767 0H525V1169L168 1047V1252L736 1461H767V0Z" />
-<glyph unicode="2" horiz-adv-x="1164" d="M1088 0H109V167L594 696Q699 813 743 891T788 1049Q788 1153 730 1217T572 1281Q454 1281 389 1209T324 1012H81Q81 1145 141 1251T314 1417T574 1476Q786 1476 908 1370T1031 1075Q1031 966 970 847T768 575L412 194H1088V0Z" />
-<glyph unicode="3" horiz-adv-x="1164" d="M390 839H538Q650 840 715 897T781 1062Q781 1166 727 1223T560 1281Q462 1281 399 1225T336 1077H93Q93 1189 152 1281T318 1424T557 1476Q775 1476 899 1367T1024 1062Q1024 964 962 878T800 747Q920 706 982 618T1045
-408Q1045 212 911 96T557 -20Q347 -20 213 92T79 390H322Q322 294 386 234T560 174Q673 174 738 234T803 408Q803 523 735 585T533 647H390V839Z" />
-<glyph unicode="4" horiz-adv-x="1164" d="M931 519H1112V324H931V0H688V324H59L52 472L680 1456H931V519ZM307 519H688V1127L670 1095L307 519Z" />
-<glyph unicode="5" horiz-adv-x="1164" d="M174 722L253 1456H1035V1246H455L415 898Q516 956 643 956Q851 956 966 823T1082 465Q1082 243 954 112T603 -20Q403 -20 272 93T129 393H364Q378 287 440 231T602 174Q714 174 776 254T839 472Q839 605 770 682T580
-760Q514 760 468 743T368 674L174 722Z" />
-<glyph unicode="6" horiz-adv-x="1164" d="M865 1463V1262H835Q631 1259 509 1150T364 841Q481 964 663 964Q856 964 967 828T1079 477Q1079 255 949 118T606 -20Q388 -20 253 141T117 563V646Q117 1029 303 1246T840 1463H865ZM604 768Q524 768 458 723T360 603V529Q360
-367 428 272T604 176T775 257T838 470T774 685T604 768Z" />
-<glyph unicode="7" horiz-adv-x="1164" d="M1078 1321L496 0H241L822 1261H69V1456H1078V1321Z" />
-<glyph unicode="8" horiz-adv-x="1164" d="M1026 1072Q1026 965 971 882T821 750Q935 697 996 605T1058 397Q1058 205 928 93T582 -20Q365 -20 235 93T104 397Q104 514 166 607T340 750Q246 798 192 881T137 1072Q137 1258 257 1367T581 1476Q786 1476 906 1367T1026
-1072ZM815 409Q815 517 751 583T580 650T411 584T347 409Q347 302 409 238T582 174T753 236T815 409ZM784 1063Q784 1158 729 1219T581 1281T434 1223T380 1063Q380 963 434 904T582 845T729 904T784 1063Z" />
-<glyph unicode="9" horiz-adv-x="1164" d="M798 609Q676 480 513 480Q321 480 207 614T93 968Q93 1112 151 1229T316 1411T564 1476Q784 1476 913 1312T1042 873V805Q1042 411 864 204T333 -6H304V195H339Q554 198 669 298T798 609ZM564 670Q637 670 701 712T800
-828V923Q800 1084 734 1182T563 1280T396 1194T333 975Q333 838 396 754T564 670Z" />
-<glyph unicode=":" horiz-adv-x="543" d="M527 256Q595 256 632 218T669 121Q669 64 632 27T527 -11Q462 -11 424 26T386 121T423 217T527 256ZM271 1105Q339 1105 376 1067T413 970Q413 913 376 876T271 838Q206 838 168 875T130 970T167 1066T271 1105Z" />
-<glyph unicode=";" horiz-adv-x="487" d="M250 1105Q318 1105 355 1067T392 970Q392 913 355 876T250 838Q185 838 147 875T109 970T146 1066T250 1105ZM177 -328L46 -250Q104 -159 125 -92T148 46V235H367L366 60Q365 -46 313 -152T177 -328Z" />
-<glyph unicode="&lt;" horiz-adv-x="1041" d="M310 631L900 407V164L63 537V730L900 1102V859L310 631Z" />
-<glyph unicode="=" horiz-adv-x="1146" d="M1007 780H145V982H1007V780ZM1007 356H145V557H1007V356Z" />
-<glyph unicode="&gt;" horiz-adv-x="1066" d="M746 636L128 863V1102L992 730V537L128 165V404L746 636Z" />
-<glyph unicode="?" horiz-adv-x="996" d="M350 428Q350 561 383 640T513 813T637 948Q677 1009 677 1080Q677 1174 631 1223T494 1273Q408 1273 356 1225T303 1093H60Q62 1270 180 1373T494 1476Q695 1476 807 1374T920 1089Q920 926 768 768L645 647Q579 572
-577 428H350ZM333 117Q333 176 370 212T470 249Q534 249 571 212T608 117Q608 62 572 25T470 -12T369 25T333 117Z" />
-<glyph unicode="@" horiz-adv-x="1832" d="M1741 518Q1729 268 1618 124T1317 -21Q1136 -21 1075 133Q1024 57 957 19T815 -19Q669 -19 594 101T536 422Q552 585 615 716T776 918T984 990Q1068 990 1132 969T1284 882L1232 319Q1213 121 1346 121Q1448 121 1513
-230T1585 514Q1602 883 1443 1079T963 1275Q767 1275 616 1177T375 894T277 471Q265 230 334 56T547 -210T898 -301Q982 -301 1073 -281T1229 -227L1267 -364Q1206 -404 1103 -428T894 -453Q640 -453 458 -346T185 -34Q91 177 102 471Q114 745 225 963T528 1303T967
-1424Q1216 1424 1395 1315T1664 1000T1741 518ZM732 422Q719 286 756 216T874 145Q928 145 976 192T1054 323L1099 816Q1049 835 1002 835Q891 835 821 731T732 422Z" />
-<glyph unicode="A" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543Z" />
-<glyph unicode="B" horiz-adv-x="1292" d="M148 0V1456H647Q894 1456 1023 1357T1152 1062Q1152 962 1098 882T940 758Q1058 726 1122 638T1187 425Q1187 220 1056 110T679 0H148ZM401 657V202H682Q801 202 868 261T935 425Q935 652 703 657H401ZM401 843H649Q767
-843 833 896T900 1048Q900 1156 839 1204T647 1252H401V843Z" />
-<glyph unicode="C" horiz-adv-x="1337" d="M1259 474Q1237 241 1087 111T688 -20Q514 -20 382 62T177 297T102 650V786Q102 992 175 1149T384 1391T700 1476Q941 1476 1088 1345T1259 975H1007Q989 1132 916 1201T700 1271Q535 1271 447 1151T356 797V668Q356
-432 440 308T688 184Q837 184 912 251T1007 474H1259Z" />
-<glyph unicode="D" horiz-adv-x="1338" d="M148 0V1456H578Q771 1456 920 1370T1152 1126T1234 764V691Q1234 484 1152 327T917 85T567 0H148ZM401 1252V202H566Q765 202 871 326T980 684V765Q980 1002 877 1127T578 1252H401Z" />
-<glyph unicode="E" horiz-adv-x="1158" d="M999 650H401V202H1100V0H148V1456H1093V1252H401V850H999V650Z" />
-<glyph unicode="F" horiz-adv-x="1125" d="M987 617H401V0H148V1456H1073V1252H401V819H987V617Z" />
-<glyph unicode="G" horiz-adv-x="1394" d="M1264 189Q1185 86 1045 33T727 -20Q544 -20 403 63T186 300T106 661V775Q106 1105 264 1290T705 1476Q948 1476 1091 1356T1263 1010H1015Q973 1273 710 1273Q540 1273 452 1151T360 791V679Q360 443 459 313T736 182Q930
-182 1012 270V555H712V747H1264V189Z" />
-<glyph unicode="H" horiz-adv-x="1455" d="M1304 0H1052V647H401V0H148V1456H401V850H1052V1456H1304V0Z" />
-<glyph unicode="I" horiz-adv-x="578" d="M415 0H163V1456H415V0Z" />
-<glyph unicode="J" horiz-adv-x="1137" d="M744 1456H996V435Q996 226 866 103T521 -20Q293 -20 169 95T45 415H297Q297 299 354 241T521 182Q623 182 683 249T744 436V1456Z" />
-<glyph unicode="K" horiz-adv-x="1291" d="M566 629L401 454V0H148V1456H401V773L541 946L967 1456H1273L732 811L1304 0H1004L566 629Z" />
-<glyph unicode="L" horiz-adv-x="1108" d="M401 202H1062V0H148V1456H401V202Z" />
-<glyph unicode="M" horiz-adv-x="1793" d="M476 1456L896 340L1315 1456H1642V0H1390V480L1415 1122L985 0H804L375 1121L400 480V0H148V1456H476Z" />
-<glyph unicode="N" horiz-adv-x="1454" d="M1303 0H1050L401 1033V0H148V1456H401L1052 419V1456H1303V0Z" />
-<glyph unicode="O" horiz-adv-x="1414" d="M1310 690Q1310 476 1236 315T1025 67T708 -20Q531 -20 393 66T179 313T102 682V764Q102 977 177 1140T390 1389T706 1476T1021 1391T1234 1145T1310 771V690ZM1057 766Q1057 1008 966 1137T706 1266Q542 1266 450 1138T355
-774V690Q355 450 448 319T708 188Q876 188 966 316T1057 690V766Z" />
-<glyph unicode="P" horiz-adv-x="1309" d="M401 541V0H148V1456H705Q949 1456 1092 1329T1236 993Q1236 779 1096 660T702 541H401ZM401 744H705Q840 744 911 807T982 991Q982 1109 910 1179T712 1252H401V744Z" />
-<glyph unicode="Q" horiz-adv-x="1414" d="M1305 690Q1305 483 1240 332T1056 91L1306 -104L1142 -252L832 -7Q771 -20 701 -20Q525 -20 387 66T173 313T96 682V764Q96 977 171 1140T384 1389T699 1476Q879 1476 1016 1391T1229 1145T1305 771V690ZM1051 766Q1051
-1012 959 1139T699 1266Q536 1266 444 1138T349 775V690Q349 454 441 321T701 188Q870 188 960 316T1051 690V766Z" />
-<glyph unicode="R" horiz-adv-x="1278" d="M683 561H401V0H148V1456H660Q912 1456 1049 1343T1186 1016Q1186 870 1116 772T919 620L1246 13V0H975L683 561ZM401 764H661Q789 764 861 828T933 1005Q933 1122 867 1186T668 1252H401V764Z" />
-<glyph unicode="S" horiz-adv-x="1236" d="M909 375Q909 471 842 523T598 628T318 746Q119 871 119 1072Q119 1248 262 1362T635 1476Q787 1476 906 1420T1093 1261T1161 1031H909Q909 1145 838 1209T633 1274Q509 1274 441 1221T372 1073Q372 993 446 940T690
-836T963 721T1114 573T1162 377Q1162 195 1023 88T644 -20Q486 -20 354 38T148 200T74 440H327Q327 316 409 248T644 180Q776 180 842 233T909 375Z" />
-<glyph unicode="T" horiz-adv-x="1243" d="M1200 1252H746V0H495V1252H45V1456H1200V1252Z" />
-<glyph unicode="U" horiz-adv-x="1335" d="M1213 1456V483Q1213 251 1065 116T669 -20Q419 -20 272 113T125 484V1456H377V482Q377 336 451 259T669 182Q961 182 961 490V1456H1213Z" />
-<glyph unicode="V" horiz-adv-x="1325" d="M661 317L1031 1456H1309L785 0H540L18 1456H295L661 317Z" />
-<glyph unicode="W" horiz-adv-x="1802" d="M1290 360L1514 1456H1765L1429 0H1187L910 1063L627 0H384L48 1456H299L525 362L803 1456H1015L1290 360Z" />
-<glyph unicode="X" horiz-adv-x="1296" d="M649 930L955 1456H1247L807 734L1257 0H962L649 534L335 0H41L492 734L51 1456H343L649 930Z" />
-<glyph unicode="Y" horiz-adv-x="1248" d="M623 766L958 1456H1238L750 536V0H496V536L7 1456H288L623 766Z" />
-<glyph unicode="Z" horiz-adv-x="1233" d="M386 202H1164V0H80V164L833 1252H85V1456H1140V1296L386 202Z" />
-<glyph unicode="[" horiz-adv-x="561" d="M540 1488H375V-135H540V-324H132V1678H540V1488Z" />
-<glyph unicode="\" horiz-adv-x="856" d="M20 1456H260L868 -125H628L20 1456Z" />
-<glyph unicode="]" horiz-adv-x="561" d="M12 1678H422V-324H12V-135H179V1488H12V1678Z" />
-<glyph unicode="^" horiz-adv-x="875" d="M437 1190L259 729H53L352 1456H523L821 729H616L437 1190Z" />
-<glyph unicode="_" horiz-adv-x="924" d="M920 -191H3V0H920V-191Z" />
-<glyph unicode="`" horiz-adv-x="660" d="M521 1233H319L49 1536H326L521 1233Z" />
-<glyph unicode="a" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978 738V250Q978
-104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175Z" />
-<glyph unicode="b" horiz-adv-x="1153" d="M1074 530Q1074 278 962 129T652 -20Q462 -20 356 117L344 0H124V1536H367V978Q472 1102 650 1102Q848 1102 961 955T1074 544V530ZM831 551Q831 727 769 815T589 903Q431 903 367 765V319Q432 178 591 178Q705 178 767
-263T831 520V551Z" />
-<glyph unicode="c" horiz-adv-x="1072" d="M569 174Q660 174 720 227T784 358H1013Q1009 257 950 170T790 31T572 -20Q345 -20 212 127T79 533V558Q79 805 211 953T571 1102Q764 1102 885 990T1013 694H784Q780 787 721 847T569 907Q451 907 387 822T322 562V523Q322
-347 385 261T569 174Z" />
-<glyph unicode="d" horiz-adv-x="1156" d="M79 549Q79 799 195 950T506 1102Q678 1102 784 982V1536H1027V0H807L795 112Q686 -20 504 -20Q314 -20 197 133T79 549ZM322 528Q322 363 385 271T566 178Q715 178 784 311V773Q717 903 568 903Q450 903 386 810T322 528Z" />
-<glyph unicode="e" horiz-adv-x="1099" d="M601 -20Q370 -20 227 125T83 513V543Q83 705 145 832T321 1031T573 1102Q794 1102 914 961T1035 562V464H328Q339 330 417 252T615 174Q782 174 887 309L1018 184Q953 87 845 34T601 -20ZM572 907Q472 907 411 837T332
-642H795V660Q787 782 730 844T572 907Z" />
-<glyph unicode="f" horiz-adv-x="726" d="M210 0V902H45V1082H210V1181Q210 1361 310 1459T590 1557Q654 1557 726 1539L720 1349Q680 1357 627 1357Q453 1357 453 1178V1082H673V902H453V0H210Z" />
-<glyph unicode="g" horiz-adv-x="1161" d="M82 549Q82 801 200 951T515 1102Q700 1102 806 973L817 1082H1036V33Q1036 -180 904 -303T546 -426Q427 -426 314 -377T141 -247L256 -101Q368 -234 532 -234Q653 -234 723 -169T793 24V97Q688 -20 513 -20Q323 -20
-203 131T82 549ZM324 528Q324 365 390 272T575 178Q722 178 793 304V780Q724 903 577 903Q457 903 391 808T324 528Z" />
-<glyph unicode="h" horiz-adv-x="1137" d="M364 964Q483 1102 665 1102Q1011 1102 1016 707V0H773V698Q773 810 725 856T582 903Q436 903 364 773V0H121V1536H364V964Z" />
-<glyph unicode="i" horiz-adv-x="523" d="M383 0H140V1082H383V0ZM125 1363Q125 1419 160 1456T262 1493T364 1456T400 1363Q400 1308 364 1272T262 1235T161 1271T125 1363Z" />
-<glyph unicode="j" horiz-adv-x="513" d="M378 1082V-96Q378 -262 296 -349T54 -437Q-13 -437 -75 -420V-228Q-37 -237 11 -237Q132 -237 135 -105V1082H378ZM114 1363Q114 1419 149 1456T251 1493T353 1456T389 1363Q389 1308 353 1272T251 1235T150 1271T114 1363Z" />
-<glyph unicode="k" horiz-adv-x="1069" d="M476 464L368 353V0H125V1536H368V650L444 745L743 1082H1035L633 631L1078 0H797L476 464Z" />
-<glyph unicode="l" horiz-adv-x="523" d="M383 0H140V1536H383V0Z" />
-<glyph unicode="m" horiz-adv-x="1782" d="M353 1082L360 969Q474 1102 672 1102Q889 1102 969 936Q1087 1102 1301 1102Q1480 1102 1567 1003T1657 711V0H1414V704Q1414 807 1369 855T1220 903Q1137 903 1085 859T1011 742L1012 0H769V712Q764 903 574 903Q428
-903 367 784V0H124V1082H353Z" />
-<glyph unicode="n" horiz-adv-x="1139" d="M350 1082L357 957Q477 1102 672 1102Q1010 1102 1016 715V0H773V701Q773 804 729 853T583 903Q436 903 364 770V0H121V1082H350Z" />
-<glyph unicode="o" horiz-adv-x="1166" d="M79 551Q79 710 142 837T319 1033T581 1102Q800 1102 936 961T1084 587L1085 530Q1085 370 1024 244T848 49T583 -20Q354 -20 217 132T79 539V551ZM322 530Q322 363 391 269T583 174T774 270T843 551Q843 715 773 811T581
-907Q462 907 392 813T322 530Z" />
-<glyph unicode="p" horiz-adv-x="1153" d="M1072 530Q1072 279 958 130T652 -20Q474 -20 367 97V-416H124V1082H348L358 972Q465 1102 649 1102Q847 1102 959 955T1072 545V530ZM830 551Q830 713 766 808T581 903Q432 903 367 780V300Q433 174 583 174Q699 174
-764 267T830 551Z" />
-<glyph unicode="q" horiz-adv-x="1163" d="M79 550Q79 804 195 953T509 1102Q690 1102 796 975L810 1082H1026V-416H783V92Q677 -20 507 -20Q313 -20 196 131T79 550ZM322 529Q322 363 387 269T569 174Q713 174 783 297V789Q713 907 571 907Q455 907 389 814T322 529Z" />
-<glyph unicode="r" horiz-adv-x="720" d="M691 860Q643 868 592 868Q425 868 367 740V0H124V1082H356L362 961Q450 1102 606 1102Q658 1102 692 1088L691 860Z" />
-<glyph unicode="s" horiz-adv-x="1057" d="M731 294Q731 359 678 393T500 453T293 519Q111 607 111 774Q111 914 229 1008T529 1102Q723 1102 842 1006T962 757H719Q719 827 667 873T529 920Q449 920 399 883T348 784Q348 728 395 697T585 635T809 560T930 455T970
-307Q970 161 849 71T532 -20Q399 -20 295 28T133 160T75 341H311Q316 255 376 209T535 162Q631 162 681 198T731 294Z" />
-<glyph unicode="t" horiz-adv-x="681" d="M429 1345V1082H620V902H429V298Q429 236 453 209T541 181Q583 181 626 191V3Q543 -20 466 -20Q186 -20 186 289V902H8V1082H186V1345H429Z" />
-<glyph unicode="u" horiz-adv-x="1138" d="M780 106Q673 -20 476 -20Q300 -20 210 83T119 381V1082H362V384Q362 178 533 178Q710 178 772 305V1082H1015V0H786L780 106Z" />
-<glyph unicode="v" horiz-adv-x="1013" d="M506 308L735 1082H986L611 0H400L22 1082H274L506 308Z" />
-<glyph unicode="w" horiz-adv-x="1522" d="M1075 335L1247 1082H1484L1189 0H989L757 743L529 0H329L33 1082H270L445 343L667 1082H850L1075 335Z" />
-<glyph unicode="x" horiz-adv-x="1030" d="M513 726L719 1082H989L658 549L1000 0H732L516 370L301 0H31L373 549L43 1082H311L513 726Z" />
-<glyph unicode="y" horiz-adv-x="997" d="M503 348L723 1082H982L552 -164Q453 -437 216 -437Q163 -437 99 -419V-231L145 -234Q237 -234 283 -201T357 -88L392 5L12 1082H274L503 348Z" />
-<glyph unicode="z" horiz-adv-x="1030" d="M384 194H960V0H82V159L631 886H92V1082H939V928L384 194Z" />
-<glyph unicode="{" horiz-adv-x="687" d="M609 -360Q256 -261 249 91V304Q249 529 56 529V707Q249 707 249 933V1145Q252 1325 342 1436T609 1597L657 1457Q484 1401 478 1151V935Q478 710 305 619Q478 527 478 300V87Q484 -163 657 -219L609 -360Z" />
-<glyph unicode="|" horiz-adv-x="514" d="M341 -270H174V1456H341V-270Z" />
-<glyph unicode="}" horiz-adv-x="687" d="M27 -219Q203 -162 207 93V301Q207 532 389 618Q207 704 207 938V1145Q203 1400 27 1457L75 1597Q257 1546 346 1432T435 1132V932Q435 707 629 707V529Q435 529 435 304V107Q435 -80 346 -194T75 -360L27 -219Z" />
-<glyph unicode="~" horiz-adv-x="1361" d="M1244 786Q1244 610 1149 499T912 387Q838 387 776 415T636 511T526 596T454 613Q387 613 349 561T310 425H117Q117 596 208 705T447 815Q521 815 587 786T726 690T832 607T905 590Q972 590 1014 646T1056 786H1244Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="510" />
-<glyph unicode="&#xa1;" horiz-adv-x="542" d="M170 662H379L403 -364H146L170 662ZM409 971Q409 915 373 878T272 840Q206 840 170 877T134 971Q134 1026 170 1063T272 1101Q337 1101 373 1064T409 971Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1149" d="M591 174Q680 174 740 226T806 358H1034Q1030 222 932 120T687 -11V-245H487V-11Q304 23 202 166T100 530V558Q100 771 202 915T487 1093V1318H687V1094Q845 1066 937 958T1034 694H806Q799 790 740 848T590 907Q360
-907 344 595L343 523Q343 347 406 261T591 174Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1205" d="M509 598L516 422Q516 287 452 202H1148L1147 0H98V202H180Q219 211 240 266T262 413L255 598H94V797H249L241 1039Q241 1241 366 1358T694 1475T1013 1366T1129 1073H884Q884 1168 832 1220T685 1273Q596 1273
-545 1208T493 1039L502 797H813V598H509Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1437" d="M1085 107Q926 -20 723 -20Q521 -20 363 106L234 -26L93 118L228 255Q128 411 128 608Q128 808 237 973L93 1120L234 1264L376 1119Q531 1234 723 1234Q917 1234 1072 1117L1217 1265L1359 1120L1211 969Q1318 810
-1318 608Q1318 415 1220 259L1359 118L1217 -27L1085 107ZM313 608Q313 488 368 385T518 224T723 165T928 224T1077 386T1132 608T1078 829T929 989T723 1048T517 990T368 829T313 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1088" d="M545 847L807 1456H1076L735 742H969V590H666V452H969V301H666V0H414V301H106V452H414V590H106V742H354L11 1456H284L545 847Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="508" d="M136 -270V525H365V-270H136ZM365 698H136V1456H365V698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1272" d="M1164 455Q1164 271 993 182Q1128 82 1128 -103Q1128 -276 993 -375T624 -474Q378 -474 234 -366T90 -50L332 -49Q332 -159 410 -219T624 -279Q745 -279 815 -232T886 -105Q886 -28 819 17T565 118Q377 169 282
-224T141 356T94 542Q94 726 263 816Q198 866 164 934T130 1102Q130 1272 267 1374T635 1476Q875 1476 1009 1364T1143 1047H900Q900 1153 828 1217T635 1281Q512 1281 443 1234T373 1104Q373 1020 433 977T686 881T977 773T1119 640T1164 455ZM601 673Q520 694
-444 722Q336 682 336 558Q336 477 385 434T584 344L763 291L809 275Q924 322 924 439Q924 520 856 568T601 673Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="901" d="M93 1366Q93 1416 126 1450T219 1484T312 1450T346 1366T312 1282T219 1248T127 1282T93 1366ZM550 1365Q550 1415 583 1449T676 1483T769 1449T803 1365T769 1281T676 1247T584 1281T550 1365Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1604" d="M1118 596Q1118 444 1031 363T783 282T529 388T434 675V788Q434 962 529 1068T783 1175Q946 1175 1032 1093T1119 861H963Q963 957 917 998T783 1040Q691 1040 640 972T588 786V669Q588 551 640 484T783 417Q872
-417 917 457T962 596H1118ZM1384 729Q1384 895 1309 1037T1097 1265T797 1351Q638 1351 502 1269T287 1043T209 729T286 415T500 188T797 104T1094 189T1308 418T1384 729ZM87 729Q87 931 180 1104T439 1376T797 1476T1154 1377T1412 1104T1506 729T1413 354T1155
-81T797 -20Q604 -20 440 80T181 353T87 729Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="913" d="M608 705L591 773Q514 691 390 691Q272 691 207 752T141 919Q141 1029 225 1089T482 1150H584V1201Q584 1328 468 1328Q403 1328 367 1303T330 1229L157 1243Q157 1347 244 1411T468 1476Q605 1476 682 1404T759
-1199V883Q759 786 785 705H608ZM433 835Q473 835 515 853T584 896V1033H478Q402 1032 359 1002T316 923Q316 835 433 835Z" />
-<glyph unicode="&#xab;" horiz-adv-x="994" d="M551 537L798 138H631L343 528V547L631 937H798L551 537ZM654 537L901 138H734L446 528V547L734 937H901L654 537Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1133" d="M962 374H762V634H127V805H962V374Z" />
-<glyph unicode="&#xad;" horiz-adv-x="672" d="M596 521H71V717H596V521Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1604" d="M87 729Q87 931 180 1104T439 1376T797 1476T1154 1377T1412 1104T1506 729T1413 354T1155 81T797 -20Q604 -20 440 80T181 353T87 729ZM1384 729Q1384 895 1309 1037T1097 1265T797 1351Q638 1351 502 1269T287
-1043T209 729T286 415T500 188T797 104T1094 189T1308 418T1384 729ZM653 653V316H502V1166H783Q936 1166 1022 1099T1108 906Q1108 789 988 726Q1053 697 1079 642T1105 505T1108 389T1122 332V316H967Q954 350 954 510Q954 586 921 619T811 653H653ZM653 787H796Q865
-787 911 818T958 903Q958 973 923 1002T794 1033H653V787Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="987" d="M842 1292H155V1450H842V1292Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="778" d="M391 1476Q497 1476 574 1397T651 1208T575 1021T391 943Q282 943 205 1020T127 1208T205 1397T391 1476ZM391 1084Q444 1084 478 1119T513 1208Q513 1260 479 1298T391 1336T302 1298T266 1208T302 1120T391 1084Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1098" d="M668 899H1011V700H668V312H452V700H95V899H452V1276H668V899ZM974 1H125V197H974V1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="758" d="M690 667H78V792L363 1053Q476 1156 476 1223Q476 1265 449 1291T370 1318Q312 1318 279 1285T246 1198H60Q60 1314 144 1390T364 1467Q507 1467 585 1403T663 1224Q663 1117 557 1015L459 928L319 815H690V667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="758" d="M268 1133H349Q481 1133 481 1230Q481 1265 454 1291T365 1318Q317 1318 285 1299T252 1244H66Q66 1343 148 1405T361 1467Q504 1467 585 1407T667 1241Q667 1122 532 1071Q681 1030 681 888Q681 782 593 719T361
-656Q226 656 141 719T55 896H241Q241 858 275 832T370 805Q433 805 463 832T494 902Q494 1003 360 1004H268V1133Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="667" d="M307 1536H584L307 1233H112L307 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1211" d="M388 1082V446Q390 305 434 240T585 175Q753 175 812 296V1082H1055V0H832L825 86Q733 -21 586 -21Q465 -21 388 34V-416H146V1082H388Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="1005" d="M644 0V520H564Q334 520 202 647T69 988Q69 1201 202 1328T565 1456H854V0H644Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="578" d="M142 714Q142 772 179 811T283 850T387 811T425 714Q425 655 386 618T283 581Q218 581 180 618T142 714Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="528" d="M318 3L307 -51Q457 -78 457 -224Q457 -329 371 -388T130 -447L123 -310Q189 -310 224 -287T260 -221Q260 -176 225 -159T109 -136L141 3H318Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="758" d="M514 667H329V1237L128 1189V1335L495 1454H514V667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="935" d="M119 1121Q119 1281 214 1378T465 1476T716 1379T812 1116V1044Q812 885 718 788T467 690Q309 690 214 788T119 1049V1121ZM294 1044Q294 946 340 891T467 836Q545 836 590 890T637 1041V1121Q637 1218 591 1273T465
-1328Q387 1328 341 1274T294 1117V1044Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="994" d="M260 937L548 547V528L260 138H93L340 537L93 937H260ZM633 937L921 547V528L633 138H466L713 537L466 937H633Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1488" d="M475 664H290V1234L89 1186V1332L456 1451H475V664ZM453 117L328 189L1039 1327L1164 1255L453 117ZM1316 314H1411V163H1316V0H1129V163H771L762 284L1127 789H1316V314ZM943 314H1129V556L1115 534L943 314Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1579" d="M410 117L285 189L996 1327L1121 1255L410 117ZM466 667H281V1237L80 1189V1335L447 1454H466V667ZM1484 0H872V125L1157 386Q1270 489 1270 556Q1270 598 1243 624T1164 651Q1106 651 1073 618T1040 531H854Q854
-647 938 723T1158 800Q1301 800 1379 736T1457 557Q1457 450 1351 348L1253 261L1113 148H1484V0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1623" d="M594 117L469 189L1180 1327L1305 1255L594 117ZM1437 314H1532V163H1437V0H1250V163H892L883 284L1248 789H1437V314ZM1064 314H1250V556L1236 534L1064 314ZM316 1133H397Q529 1133 529 1230Q529 1265 502 1291T413
-1318Q365 1318 333 1299T300 1244H114Q114 1343 196 1405T409 1467Q552 1467 633 1407T715 1241Q715 1122 580 1071Q729 1030 729 888Q729 782 641 719T409 656Q274 656 189 719T103 896H289Q289 858 323 832T418 805Q481 805 511 832T542 902Q542 1003 408 1004H316V1133Z"
-/>
-<glyph unicode="&#xbf;" horiz-adv-x="996" d="M630 661Q628 537 602 465T502 313L399 207Q309 110 309 4Q309 -90 358 -136T496 -183Q584 -183 637 -133T690 0H933Q931 -177 812 -281T498 -385Q292 -385 179 -285T66 0Q66 165 221 328L313 421Q391 493 401 608L403
-661H630ZM650 972Q650 916 615 879T513 841T411 878T375 972Q375 1027 411 1064T513 1102T614 1065T650 972Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543ZM812 1543H610L340 1846H617L812 1543Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543ZM757 1846H1034L757 1543H562L757 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543ZM1030 1569V1558H835L685 1714L536 1558H343V1571L614 1847H757L1030 1569Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543ZM1052 1824Q1052 1714 989 1641T829 1568Q790 1568 762 1576T681 1615T607 1651T559 1657Q521 1657 495 1629T468 1554L319
-1562Q319 1672 382 1747T541 1822Q598 1822 678 1777T811 1732Q849 1732 876 1760T903 1836L1052 1824Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543ZM331 1676Q331 1726 364 1760T457 1794T550 1760T584 1676T550 1592T457 1558T365 1592T331 1676ZM788 1675Q788 1725
-821 1759T914 1793T1007 1759T1041 1675T1007 1591T914 1557T822 1591T788 1675Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1363" d="M963 339H399L281 0H18L568 1456H795L1346 0H1082L963 339ZM470 543H892L681 1147L470 543ZM686 1940Q779 1940 843 1879T907 1732T845 1587T686 1527Q589 1527 527 1587T464 1732T527 1878T686 1940ZM574 1732Q574
-1685 607 1653T686 1620Q733 1620 765 1652T798 1732Q798 1778 767 1811T686 1845T606 1812T574 1732Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1925" d="M1879 0H981L966 340H464L280 0H-10L825 1456H1817V1259H1171L1188 851H1736V654H1196L1216 196H1879V0ZM580 555H957L930 1203L580 555Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1337" d="M1259 474Q1237 241 1087 111T688 -20Q514 -20 382 62T177 297T102 650V786Q102 992 175 1149T384 1391T700 1476Q941 1476 1088 1345T1259 975H1007Q989 1132 916 1201T700 1271Q535 1271 447 1151T356 797V668Q356
-432 440 308T688 184Q837 184 912 251T1007 474H1259ZM775 -2L764 -56Q914 -83 914 -229Q914 -334 828 -393T587 -452L580 -315Q646 -315 681 -292T717 -226Q717 -181 682 -164T566 -141L598 -2H775Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1158" d="M999 650H401V202H1100V0H148V1456H1093V1252H401V850H999V650ZM753 1550H551L281 1853H558L753 1550Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1158" d="M999 650H401V202H1100V0H148V1456H1093V1252H401V850H999V650ZM698 1853H975L698 1550H503L698 1853Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1158" d="M999 650H401V202H1100V0H148V1456H1093V1252H401V850H999V650ZM971 1576V1565H776L626 1721L477 1565H284V1578L555 1854H698L971 1576Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1158" d="M999 650H401V202H1100V0H148V1456H1093V1252H401V850H999V650ZM272 1683Q272 1733 305 1767T398 1801T491 1767T525 1683T491 1599T398 1565T306 1599T272 1683ZM729 1682Q729 1732 762 1766T855 1800T948 1766T982
-1682T948 1598T855 1564T763 1598T729 1682Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="578" d="M415 0H163V1456H415V0ZM416 1550H214L-56 1853H221L416 1550Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="578" d="M415 0H163V1456H415V0ZM360 1853H637L360 1550H165L360 1853Z" />
-<glyph unicode="&#xce;" horiz-adv-x="578" d="M415 0H163V1456H415V0ZM634 1576V1565H439L289 1721L140 1565H-53V1578L218 1854H361L634 1576Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="578" d="M415 0H163V1456H415V0ZM-65 1683Q-65 1733 -32 1767T61 1801T154 1767T188 1683T154 1599T61 1565T-31 1599T-65 1683ZM392 1682Q392 1732 425 1766T518 1800T611 1766T645 1682T611 1598T518 1564T426 1598T392 1682Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1368" d="M178 0V652H-9V822H178V1456H608Q801 1456 950 1370T1182 1126T1264 764V691Q1264 484 1182 327T947 85T597 0H178ZM660 652H431V202H594Q797 202 903 328T1010 695V765Q1010 1002 907 1127T608 1252H431V822H660V652Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1454" d="M1303 0H1050L401 1033V0H148V1456H401L1052 419V1456H1303V0ZM1093 1824Q1093 1714 1030 1641T870 1568Q831 1568 803 1576T722 1615T648 1651T600 1657Q562 1657 536 1629T509 1554L360 1562Q360 1672 423 1747T582
-1822Q639 1822 719 1777T852 1732Q890 1732 917 1760T944 1836L1093 1824Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1414" d="M1310 690Q1310 476 1236 315T1025 67T708 -20Q531 -20 393 66T179 313T102 682V764Q102 977 177 1140T390 1389T706 1476T1021 1391T1234 1145T1310 771V690ZM1057 766Q1057 1008 966 1137T706 1266Q542 1266 450
-1138T355 774V690Q355 450 448 319T708 188Q876 188 966 316T1057 690V766ZM835 1543H633L363 1846H640L835 1543Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1414" d="M1310 690Q1310 476 1236 315T1025 67T708 -20Q531 -20 393 66T179 313T102 682V764Q102 977 177 1140T390 1389T706 1476T1021 1391T1234 1145T1310 771V690ZM1057 766Q1057 1008 966 1137T706 1266Q542 1266 450
-1138T355 774V690Q355 450 448 319T708 188Q876 188 966 316T1057 690V766ZM780 1846H1057L780 1543H585L780 1846Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1414" d="M1310 690Q1310 476 1236 315T1025 67T708 -20Q531 -20 393 66T179 313T102 682V764Q102 977 177 1140T390 1389T706 1476T1021 1391T1234 1145T1310 771V690ZM1057 766Q1057 1008 966 1137T706 1266Q542 1266 450
-1138T355 774V690Q355 450 448 319T708 188Q876 188 966 316T1057 690V766ZM1053 1569V1558H858L708 1714L559 1558H366V1571L637 1847H780L1053 1569Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1414" d="M1310 690Q1310 476 1236 315T1025 67T708 -20Q531 -20 393 66T179 313T102 682V764Q102 977 177 1140T390 1389T706 1476T1021 1391T1234 1145T1310 771V690ZM1057 766Q1057 1008 966 1137T706 1266Q542 1266 450
-1138T355 774V690Q355 450 448 319T708 188Q876 188 966 316T1057 690V766ZM1075 1824Q1075 1714 1012 1641T852 1568Q813 1568 785 1576T704 1615T630 1651T582 1657Q544 1657 518 1629T491 1554L342 1562Q342 1672 405 1747T564 1822Q621 1822 701 1777T834 1732Q872
-1732 899 1760T926 1836L1075 1824Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1414" d="M1310 690Q1310 476 1236 315T1025 67T708 -20Q531 -20 393 66T179 313T102 682V764Q102 977 177 1140T390 1389T706 1476T1021 1391T1234 1145T1310 771V690ZM1057 766Q1057 1008 966 1137T706 1266Q542 1266 450
-1138T355 774V690Q355 450 448 319T708 188Q876 188 966 316T1057 690V766ZM354 1676Q354 1726 387 1760T480 1794T573 1760T607 1676T573 1592T480 1558T388 1592T354 1676ZM811 1675Q811 1725 844 1759T937 1793T1030 1759T1064 1675T1030 1591T937 1557T845
-1591T811 1675Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1092" d="M77 364L393 686L77 1008L225 1158L540 836L856 1158L1004 1008L688 686L1004 364L856 214L540 535L225 214L77 364Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1412" d="M1314 690Q1314 476 1240 315T1029 67T711 -20Q547 -20 415 55L324 -95H155L300 143Q105 338 105 697V764Q105 977 180 1139T393 1388T709 1476Q906 1476 1049 1375L1136 1518H1303L1156 1275Q1313 1082 1314 765V690ZM358
-690Q358 483 429 355L931 1181Q844 1266 709 1266Q545 1266 453 1138T358 774V690ZM1061 766Q1061 932 1017 1046L528 242Q606 188 711 188Q880 188 970 316T1061 690V766Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1335" d="M1213 1456V483Q1213 251 1065 116T669 -20Q419 -20 272 113T125 484V1456H377V482Q377 336 451 259T669 182Q961 182 961 490V1456H1213ZM794 1543H592L322 1846H599L794 1543Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1335" d="M1213 1456V483Q1213 251 1065 116T669 -20Q419 -20 272 113T125 484V1456H377V482Q377 336 451 259T669 182Q961 182 961 490V1456H1213ZM739 1846H1016L739 1543H544L739 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1335" d="M1213 1456V483Q1213 251 1065 116T669 -20Q419 -20 272 113T125 484V1456H377V482Q377 336 451 259T669 182Q961 182 961 490V1456H1213ZM1012 1569V1558H817L667 1714L518 1558H325V1571L596 1847H739L1012 1569Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1335" d="M1213 1456V483Q1213 251 1065 116T669 -20Q419 -20 272 113T125 484V1456H377V482Q377 336 451 259T669 182Q961 182 961 490V1456H1213ZM313 1676Q313 1726 346 1760T439 1794T532 1760T566 1676T532 1592T439
-1558T347 1592T313 1676ZM770 1675Q770 1725 803 1759T896 1793T989 1759T1023 1675T989 1591T896 1557T804 1591T770 1675Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1248" d="M623 766L958 1456H1238L750 536V0H496V536L7 1456H288L623 766ZM698 1846H975L698 1543H503L698 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1226" d="M391 1456V1176H632Q876 1176 1013 1057T1150 738Q1150 539 1013 420T633 300H391V0H148V1456H391ZM391 981V495H637Q762 495 834 560T907 736T837 913T645 981H391Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1255" d="M378 0H136V1105Q136 1319 250 1438T571 1557Q758 1557 865 1464T973 1201Q973 1139 960 1090T912 985T866 896T855 824Q855 780 887 738T1009 622T1138 480T1179 336Q1179 165 1071 73T764 -20Q684 -20 599 -1T475
-44L524 239Q569 211 632 193T750 174Q847 174 892 217T937 327Q937 376 902 421T780 535T653 671T612 819Q612 907 675 1007T738 1185Q738 1266 692 1314T566 1363Q382 1363 378 1116V0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978
-738V250Q978 104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175ZM694 1233H492L222 1536H499L694 1233Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978
-738V250Q978 104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175ZM639 1536H916L639 1233H444L639 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978
-738V250Q978 104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175ZM912 1259V1248H717L567 1404L418 1248H225V1261L496 1537H639L912 1259Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978
-738V250Q978 104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175ZM934 1514Q934 1404 871 1331T711 1258Q672 1258 644 1266T563 1305T489 1341T441 1347Q403 1347 377 1319T350 1244L201 1252Q201
-1362 264 1437T423 1512Q480 1512 560 1467T693 1422Q731 1422 758 1450T785 1526L934 1514Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978
-738V250Q978 104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175ZM213 1366Q213 1416 246 1450T339 1484T432 1450T466 1366T432 1282T339 1248T247 1282T213 1366ZM670 1365Q670 1415 703 1449T796
-1483T889 1449T923 1365T889 1281T796 1247T704 1281T670 1365Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1108" d="M771 0Q755 31 743 101Q627 -20 459 -20Q296 -20 193 73T90 303Q90 476 218 568T586 661H735V732Q735 816 688 866T545 917Q462 917 409 876T356 770H113Q113 859 172 936T332 1058T559 1102Q749 1102 862 1007T978
-738V250Q978 104 1019 17V0H771ZM504 175Q576 175 639 210T735 304V508H604Q469 508 401 461T333 328Q333 258 379 217T504 175ZM568 1630Q661 1630 725 1569T789 1422T727 1277T568 1217Q471 1217 409 1277T346 1422T409 1568T568 1630ZM456 1422Q456 1375 489
-1343T568 1310Q615 1310 647 1342T680 1422Q680 1468 649 1501T568 1535T488 1502T456 1422Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1729" d="M1254 -20Q1001 -20 861 141Q796 64 689 22T448 -20Q272 -20 172 68T72 312Q72 470 191 556T543 642H734V713Q734 804 687 855T551 907Q460 907 403 863T345 752L103 771Q103 917 229 1009T553 1102Q776 1102 887
-969Q1018 1104 1218 1102Q1430 1102 1549 973T1668 608V471H973Q982 332 1058 253T1268 174Q1405 174 1512 232L1573 266L1646 100Q1576 44 1472 12T1254 -20ZM495 164Q553 164 621 193T734 266V475H538Q434 473 374 426T314 308Q314 243 360 204T495 164ZM1218
-907Q1119 907 1056 838T976 642H1428V672Q1428 785 1374 846T1218 907Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1072" d="M569 174Q660 174 720 227T784 358H1013Q1009 257 950 170T790 31T572 -20Q345 -20 212 127T79 533V558Q79 805 211 953T571 1102Q764 1102 885 990T1013 694H784Q780 787 721 847T569 907Q451 907 387 822T322
-562V523Q322 347 385 261T569 174ZM635 -2L624 -56Q774 -83 774 -229Q774 -334 688 -393T447 -452L440 -315Q506 -315 541 -292T577 -226Q577 -181 542 -164T426 -141L458 -2H635Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1099" d="M601 -20Q370 -20 227 125T83 513V543Q83 705 145 832T321 1031T573 1102Q794 1102 914 961T1035 562V464H328Q339 330 417 252T615 174Q782 174 887 309L1018 184Q953 87 845 34T601 -20ZM572 907Q472 907 411
-837T332 642H795V660Q787 782 730 844T572 907ZM682 1233H480L210 1536H487L682 1233Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1099" d="M601 -20Q370 -20 227 125T83 513V543Q83 705 145 832T321 1031T573 1102Q794 1102 914 961T1035 562V464H328Q339 330 417 252T615 174Q782 174 887 309L1018 184Q953 87 845 34T601 -20ZM572 907Q472 907 411
-837T332 642H795V660Q787 782 730 844T572 907ZM627 1536H904L627 1233H432L627 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1099" d="M601 -20Q370 -20 227 125T83 513V543Q83 705 145 832T321 1031T573 1102Q794 1102 914 961T1035 562V464H328Q339 330 417 252T615 174Q782 174 887 309L1018 184Q953 87 845 34T601 -20ZM572 907Q472 907 411
-837T332 642H795V660Q787 782 730 844T572 907ZM900 1259V1248H705L555 1404L406 1248H213V1261L484 1537H627L900 1259Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1099" d="M601 -20Q370 -20 227 125T83 513V543Q83 705 145 832T321 1031T573 1102Q794 1102 914 961T1035 562V464H328Q339 330 417 252T615 174Q782 174 887 309L1018 184Q953 87 845 34T601 -20ZM572 907Q472 907 411
-837T332 642H795V660Q787 782 730 844T572 907ZM201 1366Q201 1416 234 1450T327 1484T420 1450T454 1366T420 1282T327 1248T235 1282T201 1366ZM658 1365Q658 1415 691 1449T784 1483T877 1449T911 1365T877 1281T784 1247T692 1281T658 1365Z" />
-<glyph unicode="&#xec;" horiz-adv-x="538" d="M386 0H143V1082H386V0ZM652 1482H450L180 1785H457L652 1482Z" />
-<glyph unicode="&#xed;" horiz-adv-x="538" d="M386 0H143V1082H386V0ZM340 1785H617L340 1482H145L340 1785Z" />
-<glyph unicode="&#xee;" horiz-adv-x="538" d="M386 0H143V1082H386V0ZM614 1252V1241H419L269 1397L120 1241H-73V1254L198 1530H341L614 1252Z" />
-<glyph unicode="&#xef;" horiz-adv-x="538" d="M386 0H143V1082H386V0ZM-85 1359Q-85 1409 -52 1443T41 1477T134 1443T168 1359T134 1275T41 1241T-51 1275T-85 1359ZM372 1358Q372 1408 405 1442T498 1476T591 1442T625 1358T591 1274T498 1240T406 1274T372 1358Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1191" d="M834 1303Q1088 1038 1088 637V555Q1088 389 1025 258T848 53T593 -20Q455 -20 342 43T166 219T103 468Q103 617 159 732T319 910T554 973Q700 973 813 882Q764 1051 638 1173L434 1038L356 1147L528 1261Q402 1343
-240 1385L315 1580Q553 1530 730 1395L910 1515L988 1406L834 1303ZM845 663L844 681Q812 729 751 757T611 785Q485 785 416 701T346 468Q346 342 416 258T597 174Q708 174 776 274T845 547V663Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1139" d="M350 1082L357 957Q477 1102 672 1102Q1010 1102 1016 715V0H773V701Q773 804 729 853T583 903Q436 903 364 770V0H121V1082H350ZM940 1514Q940 1404 877 1331T717 1258Q678 1258 650 1266T569 1305T495 1341T447
-1347Q409 1347 383 1319T356 1244L207 1252Q207 1362 270 1437T429 1512Q486 1512 566 1467T699 1422Q737 1422 764 1450T791 1526L940 1514Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1166" d="M79 551Q79 710 142 837T319 1033T581 1102Q800 1102 936 961T1084 587L1085 530Q1085 370 1024 244T848 49T583 -20Q354 -20 217 132T79 539V551ZM322 530Q322 363 391 269T583 174T774 270T843 551Q843 715 773
-811T581 907Q462 907 392 813T322 530ZM703 1233H501L231 1536H508L703 1233Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1166" d="M79 551Q79 710 142 837T319 1033T581 1102Q800 1102 936 961T1084 587L1085 530Q1085 370 1024 244T848 49T583 -20Q354 -20 217 132T79 539V551ZM322 530Q322 363 391 269T583 174T774 270T843 551Q843 715 773
-811T581 907Q462 907 392 813T322 530ZM648 1536H925L648 1233H453L648 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1166" d="M79 551Q79 710 142 837T319 1033T581 1102Q800 1102 936 961T1084 587L1085 530Q1085 370 1024 244T848 49T583 -20Q354 -20 217 132T79 539V551ZM322 530Q322 363 391 269T583 174T774 270T843 551Q843 715 773
-811T581 907Q462 907 392 813T322 530ZM921 1259V1248H726L576 1404L427 1248H234V1261L505 1537H648L921 1259Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1166" d="M79 551Q79 710 142 837T319 1033T581 1102Q800 1102 936 961T1084 587L1085 530Q1085 370 1024 244T848 49T583 -20Q354 -20 217 132T79 539V551ZM322 530Q322 363 391 269T583 174T774 270T843 551Q843 715 773
-811T581 907Q462 907 392 813T322 530ZM943 1514Q943 1404 880 1331T720 1258Q681 1258 653 1266T572 1305T498 1341T450 1347Q412 1347 386 1319T359 1244L210 1252Q210 1362 273 1437T432 1512Q489 1512 569 1467T702 1422Q740 1422 767 1450T794 1526L943 1514Z"
-/>
-<glyph unicode="&#xf6;" horiz-adv-x="1166" d="M79 551Q79 710 142 837T319 1033T581 1102Q800 1102 936 961T1084 587L1085 530Q1085 370 1024 244T848 49T583 -20Q354 -20 217 132T79 539V551ZM322 530Q322 363 391 269T583 174T774 270T843 551Q843 715 773
-811T581 907Q462 907 392 813T322 530ZM222 1366Q222 1416 255 1450T348 1484T441 1450T475 1366T441 1282T348 1248T256 1282T222 1366ZM679 1365Q679 1415 712 1449T805 1483T898 1449T932 1365T898 1281T805 1247T713 1281T679 1365Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1169" d="M1079 582H67V794H1079V582ZM576 1228Q644 1228 681 1190T718 1095T681 1001T576 963Q509 963 472 1000T435 1095T472 1190T576 1228ZM435 278Q435 336 472 374T576 412Q644 412 681 374T718 278Q718 221 681 184T576
-147Q509 147 472 184T435 278Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1160" d="M79 551Q79 710 142 837T319 1033T581 1102Q687 1102 775 1068L846 1211H991L889 1003Q1085 850 1085 530Q1085 370 1024 244T848 49T583 -20Q490 -20 400 10L328 -137H183L285 70Q79 220 79 551ZM322 530Q322 374
-386 276L685 885Q638 907 581 907Q462 907 392 813T322 530ZM843 551Q843 699 785 792L489 191Q532 174 583 174Q706 174 774 270T843 551Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1138" d="M780 106Q673 -20 476 -20Q300 -20 210 83T119 381V1082H362V384Q362 178 533 178Q710 178 772 305V1082H1015V0H786L780 106ZM696 1233H494L224 1536H501L696 1233Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1138" d="M780 106Q673 -20 476 -20Q300 -20 210 83T119 381V1082H362V384Q362 178 533 178Q710 178 772 305V1082H1015V0H786L780 106ZM641 1536H918L641 1233H446L641 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1138" d="M780 106Q673 -20 476 -20Q300 -20 210 83T119 381V1082H362V384Q362 178 533 178Q710 178 772 305V1082H1015V0H786L780 106ZM914 1259V1248H719L569 1404L420 1248H227V1261L498 1537H641L914 1259Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1138" d="M780 106Q673 -20 476 -20Q300 -20 210 83T119 381V1082H362V384Q362 178 533 178Q710 178 772 305V1082H1015V0H786L780 106ZM215 1366Q215 1416 248 1450T341 1484T434 1450T468 1366T434 1282T341 1248T249 1282T215
-1366ZM672 1365Q672 1415 705 1449T798 1483T891 1449T925 1365T891 1281T798 1247T706 1281T672 1365Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="997" d="M503 348L723 1082H982L552 -164Q453 -437 216 -437Q163 -437 99 -419V-231L145 -234Q237 -234 283 -201T357 -88L392 5L12 1082H274L503 348ZM585 1536H862L585 1233H390L585 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1175" d="M1079 530Q1079 283 966 132T658 -20Q480 -20 373 97V-416H130V1536H373V983Q479 1102 655 1102Q852 1102 965 955T1079 546V530ZM836 551Q836 717 771 810T587 903Q438 903 373 780V300Q439 174 589 174Q705 174
-770 267T836 551Z" />
-<glyph unicode="&#xff;" horiz-adv-x="997" d="M503 348L723 1082H982L552 -164Q453 -437 216 -437Q163 -437 99 -419V-231L145 -234Q237 -234 283 -201T357 -88L392 5L12 1082H274L503 348ZM159 1366Q159 1416 192 1450T285 1484T378 1450T412 1366T378 1282T285
-1248T193 1282T159 1366ZM616 1365Q616 1415 649 1449T742 1483T835 1449T869 1365T835 1281T742 1247T650 1281T616 1365Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1321" d="M1432 621H414V817H1432V621Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1584" d="M1744 621H386V817H1744V621Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="448" d="M282 1562L406 1485Q315 1352 312 1208V1056H99V1194Q100 1290 151 1394T282 1562Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="444" d="M175 1024L51 1101Q141 1232 144 1378V1536H357V1398Q357 1295 305 1191T175 1024Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="462" d="M173 -298L50 -220Q135 -93 138 55V202H356V69Q355 -24 304 -128T173 -298Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="788" d="M291 1562L415 1485Q324 1352 321 1208V1056H108V1194Q109 1290 160 1394T291 1562ZM627 1562L751 1485Q660 1352 657 1208V1056H444V1194Q445 1290 496 1394T627 1562Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="795" d="M188 1024L64 1101Q154 1232 157 1378V1536H370V1398Q370 1295 318 1191T188 1024ZM522 1024L398 1101Q488 1232 491 1378V1536H704V1398Q704 1295 652 1191T522 1024Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="776" d="M177 -318L50 -240Q135 -103 138 54V255H356V69Q355 -39 300 -153Q251 -253 177 -318ZM499 -318L372 -240Q460 -98 464 52V255H682V73Q682 -26 631 -136T499 -318Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="715" d="M136 771Q136 866 196 926T357 987Q460 987 520 927T580 768V731Q580 637 521 578T358 518Q259 518 199 575T136 726V771Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="626" d="M316 537L563 138H396L108 528V547L396 937H563L316 537Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="617" d="M251 937L539 547V528L251 138H84L331 537L84 937H251Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-500.ttf b/static/fonts/roboto-v18-latin-500.ttf
deleted file mode 100644
index 55b559f619..0000000000
Binary files a/static/fonts/roboto-v18-latin-500.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500.woff b/static/fonts/roboto-v18-latin-500.woff
deleted file mode 100644
index 2633e1525d..0000000000
Binary files a/static/fonts/roboto-v18-latin-500.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500.woff2 b/static/fonts/roboto-v18-latin-500.woff2
deleted file mode 100644
index 8dceabcf6b..0000000000
Binary files a/static/fonts/roboto-v18-latin-500.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500italic.eot b/static/fonts/roboto-v18-latin-500italic.eot
deleted file mode 100644
index 148c4fa085..0000000000
Binary files a/static/fonts/roboto-v18-latin-500italic.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500italic.svg b/static/fonts/roboto-v18-latin-500italic.svg
deleted file mode 100644
index bed50dcf2e..0000000000
--- a/static/fonts/roboto-v18-latin-500italic.svg
+++ /dev/null
@@ -1,326 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1153" ><font-face
-    font-family="Roboto Medium"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="505" />
-<glyph unicode="!" horiz-adv-x="543" d="M342 429H138L294 1456H544L342 429ZM55 111Q55 170 92 208T188 248Q245 250 284 213T323 119T286 25T190 -15Q135 -17 95 18T55 111Z" />
-<glyph unicode="&quot;" horiz-adv-x="654" d="M391 1388L299 1012H161L244 1536H414L391 1388ZM683 1388L591 1012H453L536 1536H706L683 1388Z" />
-<glyph unicode="#" horiz-adv-x="1223" d="M662 410H451L306 0H136L281 410H59L87 568H337L448 881H215L243 1040H504L653 1456H822L673 1040H885L1033 1456H1202L1054 1040H1253L1225 881H997L887 568H1099L1071 410H830L685 0H516L662 410ZM507 568H718L829
-881H618L507 568Z" />
-<glyph unicode="$" horiz-adv-x="1139" d="M766 387Q775 463 735 519T577 625T387 729Q217 858 231 1065Q242 1235 356 1343T650 1473L690 1691H847L806 1469Q954 1438 1029 1317T1095 1005H859Q868 1132 826 1202T696 1276Q604 1278 542 1222T466 1068Q457 992
-497 938T653 833T832 737Q1016 607 1001 389Q990 216 872 110T565 -16L529 -211H373L410 -15Q242 11 154 132T75 444L312 443Q305 316 356 249T505 179Q610 177 682 234T766 387Z" />
-<glyph unicode="%" horiz-adv-x="1469" d="M527 1478Q658 1474 731 1389T796 1176L790 1099Q775 962 683 879T460 800Q334 802 258 887T189 1099L196 1173Q209 1310 300 1395T527 1478ZM356 1097Q349 1033 377 990T463 944Q523 942 567 985T622 1099L631 1177Q638
-1242 610 1286T523 1332Q462 1334 417 1288T364 1167L356 1097ZM1065 657Q1195 653 1268 568T1334 357L1328 279Q1314 144 1221 60T998 -21Q874 -19 797 64T726 279L731 344Q742 486 834 572T1065 657ZM893 277Q888 208 917 167T1001 123Q1062 121 1104 162T1159
-279L1169 358Q1174 430 1145 470T1061 512Q997 514 953 468T901 349L893 277ZM374 111L254 190L1133 1317L1253 1238L374 111Z" />
-<glyph unicode="&amp;" horiz-adv-x="1280" d="M56 385Q68 567 266 707L380 782Q319 894 299 964T283 1098Q295 1268 409 1374T695 1476Q788 1473 863 1432T978 1319T1013 1159Q1008 1069 956 991T785 830L664 750L878 426Q961 550 982 694L1185 695Q1161 423
-1001 250L1162 0H904L843 95Q667 -23 468 -19Q281 -17 163 94T56 385ZM484 175Q552 174 612 200T728 261L485 630L451 608Q314 512 297 393Q285 297 337 237T484 175ZM501 1105Q491 1036 539 944L562 902L661 964Q790 1046 802 1152Q808 1209 772 1245T681 1282Q609
-1282 559 1230T501 1105Z" />
-<glyph unicode="&apos;" horiz-adv-x="346" d="M385 1399L301 1020H144L225 1536H406L385 1399Z" />
-<glyph unicode="(" horiz-adv-x="703" d="M128 588Q181 953 348 1237T764 1632L800 1488Q458 1224 356 660Q319 454 318 263Q316 60 366 -91T514 -330L458 -463Q287 -357 196 -133T112 389Q114 485 126 571L128 588Z" />
-<glyph unicode=")" horiz-adv-x="710" d="M-71 -465L-108 -327Q104 -162 224 117T370 780L374 904Q374 1325 178 1497L235 1631Q350 1561 431 1435T552 1134T588 779Q579 500 490 239T255 -203T-71 -465Z" />
-<glyph unicode="*" horiz-adv-x="888" d="M383 977L103 1065L182 1226L461 1107L506 1456H682L607 1112L909 1224L933 1044L614 956L765 685L616 587L492 876L272 600L138 710L383 977Z" />
-<glyph unicode="+" horiz-adv-x="1117" d="M701 801H1070L1031 579H663L588 146H357L433 579H61L101 801H471L541 1206H772L701 801Z" />
-<glyph unicode="," horiz-adv-x="447" d="M8 -328L-119 -248Q-1 -90 26 29L63 235H276L250 74Q210 -173 8 -328Z" />
-<glyph unicode="-" horiz-adv-x="662" d="M565 521H54L89 717H600L565 521Z" />
-<glyph unicode="." horiz-adv-x="565" d="M48 117Q48 178 86 216T185 257Q244 259 283 222T323 125Q323 67 285 29T186 -12Q127 -14 88 23T48 117Z" />
-<glyph unicode="/" horiz-adv-x="796" d="M67 -125H-129L701 1456H898L67 -125Z" />
-<glyph unicode="0" horiz-adv-x="1139" d="M479 -20Q290 -16 193 110T99 465Q100 539 109 613L148 873Q197 1179 337 1330T699 1476Q887 1472 984 1348T1079 996Q1078 921 1069 848L1030 595Q979 282 841 129T479 -20ZM838 887Q851 1001 851 1049Q846 1275 686
-1282Q564 1287 490 1193T386 894L340 577Q328 474 329 414Q329 180 493 173Q719 160 784 526L838 887Z" />
-<glyph unicode="1" horiz-adv-x="1139" d="M641 0H405L607 1164L239 1042L276 1257L852 1461H888L641 0Z" />
-<glyph unicode="2" horiz-adv-x="1139" d="M962 0H11L39 177L644 758Q813 923 830 1057Q843 1152 798 1215T663 1283Q552 1287 476 1214T384 1013L148 1012Q158 1146 229 1253T419 1419T676 1476Q866 1472 976 1366T1074 1082Q1057 878 829 651L767 590L346 194H993L962
-0Z" />
-<glyph unicode="3" horiz-adv-x="1139" d="M416 839L545 838Q662 838 740 901T829 1069Q840 1168 793 1224T653 1283Q559 1285 490 1228T407 1078L170 1077Q179 1194 247 1286T424 1427T661 1476Q856 1472 968 1363T1068 1069Q1061 969 994 886T800 742Q973 662
-984 464V416Q971 220 824 98T462 -20Q339 -19 241 32T91 177T42 391L278 390Q274 294 325 236T476 174Q585 170 661 238T750 416Q762 527 705 585T539 646L386 647L416 839Z" />
-<glyph unicode="4" horiz-adv-x="1139" d="M890 519H1066L1032 324H857L800 0H563L619 324H9L30 484L800 1456H1053L890 519ZM292 519H653L766 1130L742 1096L292 519Z" />
-<glyph unicode="5" horiz-adv-x="1139" d="M186 725L377 1456H1139L1106 1246H545L442 897Q544 955 664 955Q849 953 948 819T1030 472Q1012 253 866 114T505 -21Q323 -17 210 96T90 394H317Q324 292 374 235T516 175Q627 172 702 256T793 480Q805 604 752 680T594
-759Q530 761 480 739T381 676L186 725Z" />
-<glyph unicode="6" horiz-adv-x="1139" d="M972 1464L952 1262L939 1263Q747 1265 606 1160T385 840Q517 968 686 964Q803 962 885 899T1005 725T1031 484Q1019 342 948 224T763 41T512 -21Q339 -17 231 102T108 415Q99 522 131 701Q196 1058 408 1261T949 1464H972ZM617
-769Q537 771 467 727T349 600Q338 499 339 456Q339 328 386 253T521 176Q629 173 704 257T795 477Q808 604 760 685T617 769Z" />
-<glyph unicode="7" horiz-adv-x="1139" d="M1157 1309L393 0H134L895 1261H169L200 1456H1180L1157 1309Z" />
-<glyph unicode="8" horiz-adv-x="1139" d="M1084 1080Q1066 863 828 744Q917 687 960 599T996 405Q983 213 839 95T482 -20Q288 -16 174 95T72 388Q90 631 363 756Q288 810 252 890T222 1063Q236 1251 370 1365T703 1476Q822 1473 912 1423T1048 1283T1084 1080ZM762
-417Q773 518 723 583T579 651Q473 653 398 582T311 401Q300 298 351 237T495 173Q603 171 676 240T762 417ZM846 1072Q855 1162 813 1221T687 1282Q596 1284 532 1220T456 1054Q447 960 490 903T614 844Q706 842 770 907T846 1072Z" />
-<glyph unicode="9" horiz-adv-x="1139" d="M247 194Q459 192 592 296T791 610Q655 478 503 480Q390 482 307 541T183 713T154 961Q167 1106 238 1227T424 1414T673 1476Q790 1473 876 1417T1011 1256T1066 1022Q1071 915 1043 755Q979 385 769 189T235 -7H213L232
-195L247 194ZM562 669Q636 667 702 709T816 827L829 924L833 994Q836 1124 792 1200T660 1281Q535 1285 455 1161T390 869Q397 780 442 726T562 669Z" />
-<glyph unicode=":" horiz-adv-x="537" d="M299 117Q299 178 337 216T436 257Q495 259 534 222T574 125Q574 67 536 29T437 -12Q378 -14 339 23T299 117ZM189 966Q189 1027 227 1065T326 1106Q385 1108 424 1071T464 974Q464 916 426 878T327 837Q268 835 229 872T189
-966Z" />
-<glyph unicode=";" horiz-adv-x="482" d="M169 966Q169 1027 207 1065T306 1106Q365 1108 404 1071T444 974Q444 916 406 878T307 837Q248 835 209 872T169 966ZM25 -328L-102 -248Q16 -90 43 29L80 235H293L267 74Q227 -173 25 -328Z" />
-<glyph unicode="&lt;" horiz-adv-x="1020" d="M306 626L840 402L799 170L50 543L84 736L963 1108L918 854L306 626Z" />
-<glyph unicode="=" horiz-adv-x="1122" d="M1009 780H171L207 982H1044L1009 780ZM935 356H98L133 557H971L935 356Z" />
-<glyph unicode="&gt;" horiz-adv-x="1044" d="M731 641L170 868L210 1097L985 724L951 531L47 159L91 409L731 641Z" />
-<glyph unicode="?" horiz-adv-x="976" d="M319 427Q331 552 377 640T525 814T658 936Q752 1044 734 1162Q726 1214 690 1244T597 1276Q515 1278 459 1229T385 1094L149 1093Q166 1271 294 1376T612 1477Q789 1473 890 1370T977 1097Q962 920 773 757L651 655Q557
-569 537 428L319 427ZM239 113Q239 172 276 210T372 250Q428 252 467 215T506 121Q506 60 467 24T373 -13Q317 -15 278 20T239 113Z" />
-<glyph unicode="@" horiz-adv-x="1787" d="M1190 -21Q1113 -19 1054 18T975 133Q844 -23 705 -20Q591 -18 530 72T478 323Q485 484 564 651T757 906T1002 991Q1087 989 1153 961T1287 884L1153 317L1145 257Q1138 194 1158 158T1225 119Q1314 115 1382 187T1494
-396T1544 706Q1548 840 1519 947T1429 1125Q1304 1271 1062 1275Q895 1278 748 1206T484 989T300 658T226 281Q218 108 270 -26T432 -229T701 -300Q867 -302 1040 -227L1067 -367Q929 -453 700 -453Q505 -452 360 -370T136 -132T54 235Q50 456 129 680T352 1077T679
-1338T1064 1424Q1256 1421 1397 1340T1615 1104T1696 748Q1700 537 1636 354T1456 73T1190 -21ZM671 307Q666 145 772 142Q828 139 887 192T976 322L1105 819Q1060 836 1019 838Q889 843 801 718T676 363L671 307Z" />
-<glyph unicode="A" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543Z" />
-<glyph unicode="B" horiz-adv-x="1263" d="M39 0L292 1456L739 1455Q975 1454 1093 1353T1198 1071Q1180 859 939 752Q1029 720 1078 635T1120 432Q1106 232 960 116T573 0H39ZM400 657L321 202L580 201Q697 201 779 263T876 433Q890 536 845 594T696 656L400
-657ZM432 843L659 842Q781 842 858 900T949 1057Q974 1244 760 1251L503 1252L432 843Z" />
-<glyph unicode="C" horiz-adv-x="1307" d="M1194 475Q1157 247 989 112T580 -20Q441 -17 337 46T173 229T107 502Q101 616 135 812T265 1165T502 1400T815 1476Q1032 1472 1158 1340T1293 974H1048Q1043 1130 983 1199T803 1272Q640 1277 530 1155T382 800L362
-667L353 565Q345 462 367 372T447 234T592 183Q871 172 950 473L1194 475Z" />
-<glyph unicode="D" horiz-adv-x="1308" d="M39 0L291 1456L685 1455Q867 1455 998 1365T1189 1115T1225 763L1214 684Q1184 483 1082 328T817 86T461 0H39ZM503 1252L321 202L467 201Q665 201 795 326T963 673Q989 825 982 938Q973 1083 898 1165T688 1251L503 1252Z" />
-<glyph unicode="E" horiz-adv-x="1133" d="M979 650H399L321 202H999L964 0H39L291 1456H1210L1174 1252H503L433 850H1014L979 650Z" />
-<glyph unicode="F" horiz-adv-x="1101" d="M961 617H393L286 0H39L291 1456H1191L1155 1252H503L428 819H997L961 617Z" />
-<glyph unicode="G" horiz-adv-x="1362" d="M1168 189Q1088 85 942 32T616 -20Q472 -19 362 44T188 229T114 506Q107 626 139 812T253 1142T454 1369Q614 1480 820 1476Q1039 1472 1162 1350T1302 1008L1063 1009Q1041 1266 814 1273Q644 1278 535 1154T385 794Q362
-657 360 570Q354 391 425 288T634 183Q809 179 922 270L976 555H684L718 747H1253L1168 189Z" />
-<glyph unicode="H" horiz-adv-x="1421" d="M1162 0H916L1028 647H398L286 0H39L292 1456H539L433 850H1063L1168 1456H1415L1162 0Z" />
-<glyph unicode="I" horiz-adv-x="571" d="M299 0H53L306 1456H552L299 0Z" />
-<glyph unicode="J" horiz-adv-x="1113" d="M875 1456H1121L947 435Q916 223 774 99T422 -21Q218 -17 111 100T13 416L259 415Q245 186 437 182Q537 178 608 245T701 434L875 1456Z" />
-<glyph unicode="K" horiz-adv-x="1262" d="M563 627L363 444L286 0H39L292 1456H539L422 787L575 946L1077 1456H1393L745 799L1154 0H878L563 627Z" />
-<glyph unicode="L" horiz-adv-x="1085" d="M321 202H963L927 0H39L292 1456H539L321 202Z" />
-<glyph unicode="M" horiz-adv-x="1749" d="M606 1456L819 342L1418 1456H1742L1490 0H1244L1329 493L1458 1100L858 0H680L457 1133L366 467L285 0H39L292 1456H606Z" />
-<glyph unicode="N" horiz-adv-x="1420" d="M1161 0H922L467 1043L286 0H39L292 1456H531L986 409L1168 1456H1414L1161 0Z" />
-<glyph unicode="O" horiz-adv-x="1382" d="M599 -20Q457 -17 350 48T182 236T114 517Q107 642 136 809T241 1113T422 1338Q595 1480 822 1476Q1038 1472 1166 1327T1307 935Q1313 811 1285 651T1187 356T1014 131Q836 -25 599 -20ZM1054 767L1063 873Q1069 982
-1044 1074T960 1215T809 1267Q683 1271 586 1196T428 968T357 584Q347 401 413 296T611 187Q784 182 896 317T1044 697L1054 767Z" />
-<glyph unicode="P" horiz-adv-x="1280" d="M380 541L286 0H39L292 1456L796 1455Q1024 1455 1154 1331T1267 1001Q1249 789 1094 665T688 540L380 541ZM415 744L698 742Q832 742 917 810T1020 1000Q1034 1111 979 1178T811 1251L503 1252L415 744Z" />
-<glyph unicode="Q" horiz-adv-x="1382" d="M939 86L1147 -114L973 -252L717 -8Q637 -20 590 -19Q377 -17 248 129T106 521Q100 646 129 810T237 1118T431 1350Q599 1480 815 1476Q959 1473 1066 1408T1234 1218T1302 936Q1306 850 1296 764L1284 677Q1222 275
-939 86ZM1049 768L1058 874Q1064 984 1039 1076T953 1216T802 1267Q606 1273 486 1093T351 584Q345 473 371 380T456 239T605 187Q770 180 883 308T1036 679L1049 768Z" />
-<glyph unicode="R" horiz-adv-x="1250" d="M662 561H384L286 0H39L292 1456L751 1455Q988 1455 1114 1341T1223 1024Q1212 883 1129 780T896 617L1111 15L1110 0H848L662 561ZM418 764L657 762Q786 762 872 829T974 1013Q989 1126 934 1186T767 1251L503 1252L418 764Z" />
-<glyph unicode="S" horiz-adv-x="1209" d="M844 382Q866 526 687 596L606 626Q380 705 285 813T199 1064Q207 1188 283 1282T485 1428T751 1476Q887 1473 993 1417T1155 1260T1207 1030L961 1031Q968 1145 911 1208T737 1274Q620 1276 540 1219T445 1065Q425 938
-615 865L690 838Q919 756 1010 646T1090 384Q1080 261 1009 170T813 28T536 -20Q393 -19 277 40T98 203T41 441L288 440Q280 316 349 249T547 180Q667 178 747 231T844 382Z" />
-<glyph unicode="T" horiz-adv-x="1216" d="M1278 1252H838L621 0H375L593 1252H156L192 1456H1314L1278 1252Z" />
-<glyph unicode="U" horiz-adv-x="1305" d="M1327 1456L1162 483Q1128 250 963 112T562 -22Q344 -18 218 110T102 444L105 482L270 1456H516L351 481Q333 342 392 264T574 182Q709 178 799 255T914 476L1081 1456H1327Z" />
-<glyph unicode="V" horiz-adv-x="1295" d="M593 319L1129 1456H1409L673 0H434L155 1456H417L593 319Z" />
-<glyph unicode="W" horiz-adv-x="1758" d="M1211 362L1599 1456H1850L1296 0H1060L959 1060L519 0H281L183 1456H422L470 367L909 1456H1116L1211 362Z" />
-<glyph unicode="X" horiz-adv-x="1267" d="M675 931L1053 1456H1351L802 723L1120 0H846L626 533L238 0H-61L500 745L189 1456H461L675 931Z" />
-<glyph unicode="Y" horiz-adv-x="1221" d="M627 768L1071 1456H1357L715 523L624 0H376L472 549L161 1456H422L627 768Z" />
-<glyph unicode="Z" horiz-adv-x="1206" d="M314 202H1062L1026 0H-27L4 176L913 1252H195L231 1456H1255L1225 1284L314 202Z" />
-<glyph unicode="[" horiz-adv-x="554" d="M663 1488H504L250 -135H410L380 -324H-17L296 1678H693L663 1488Z" />
-<glyph unicode="\" horiz-adv-x="840" d="M172 1456H396L712 -125H488L172 1456Z" />
-<glyph unicode="]" horiz-adv-x="554" d="M180 1678H579L266 -324H-134L-104 -135H58L312 1488H149L180 1678Z" />
-<glyph unicode="^" horiz-adv-x="859" d="M532 1188L279 729H68L484 1456H651L814 729H625L532 1188Z" />
-<glyph unicode="_" horiz-adv-x="906" d="M756 -191H-135L-101 0H790L756 -191Z" />
-<glyph unicode="`" horiz-adv-x="650" d="M598 1233H417L202 1536H456L598 1233Z" />
-<glyph unicode="a" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174Z" />
-<glyph unicode="b" horiz-adv-x="1128" d="M1031 536Q1011 371 943 238T773 40T544 -21Q363 -17 271 118L233 0H16L282 1536H520L412 977Q533 1106 699 1102Q856 1098 944 987T1038 683Q1039 623 1031 536ZM803 670Q803 779 758 840T628 904Q485 908 386 766L308
-318Q352 182 497 177Q617 174 694 269T794 537Q802 622 803 670Z" />
-<glyph unicode="c" horiz-adv-x="1050" d="M488 173Q573 171 638 222T722 357L946 358Q935 251 869 163T698 26T481 -20Q342 -18 244 52T101 245T71 521L74 556Q91 713 165 840T358 1037T620 1102Q796 1098 901 986T1006 693H784Q784 786 739 845T607 908Q468
-912 388 790T302 446Q295 177 488 173Z" />
-<glyph unicode="d" horiz-adv-x="1131" d="M68 542Q88 709 158 842T331 1040T560 1103Q725 1099 818 980L922 1536H1160L893 0H681L697 112Q571 -25 401 -21Q250 -19 160 95T62 400Q59 462 65 521L68 542ZM298 449Q291 325 336 252T472 177Q609 173 709 310L790
-775Q743 900 608 904Q472 908 389 784T298 449Z" />
-<glyph unicode="e" horiz-adv-x="1076" d="M506 -20Q365 -17 262 51T109 237T71 500L74 541Q92 706 170 837T366 1037T620 1102Q823 1098 924 951T1001 568L987 464H306Q297 335 358 256T526 175Q679 170 808 308L928 182Q860 85 749 32T506 -20ZM607 908Q419
-914 325 642L774 641L778 662Q785 708 779 752Q768 823 723 864T607 908Z" />
-<glyph unicode="f" horiz-adv-x="714" d="M99 0L256 902H95L127 1082H287L303 1198Q329 1366 438 1464T721 1560Q782 1558 862 1540L836 1350Q792 1360 747 1360Q662 1361 608 1314T539 1184L524 1082H738L706 902H493L336 0H99Z" />
-<glyph unicode="g" horiz-adv-x="1136" d="M70 542Q89 704 157 835T330 1035T568 1103Q746 1099 837 972L874 1083L1090 1082L911 30Q881 -182 733 -307T371 -427Q257 -425 155 -375T-9 -243L117 -100Q212 -231 365 -235Q481 -239 564 -172T676 21L693 97Q568
--24 409 -20Q257 -18 166 95T65 399Q62 459 70 542ZM305 521Q299 470 301 411Q303 305 349 243T480 178Q615 173 716 303L801 781Q749 900 616 904Q496 907 414 811T307 542L305 521Z" />
-<glyph unicode="h" horiz-adv-x="1113" d="M407 963Q542 1105 714 1101Q868 1099 942 992T998 696L882 0H645L763 699Q768 742 765 779Q752 901 621 904Q489 906 385 774L250 0H13L279 1536H517L407 963Z" />
-<glyph unicode="i" horiz-adv-x="517" d="M268 0H31L219 1082H456L268 0ZM253 1359Q253 1414 289 1453T386 1494Q444 1496 482 1459T521 1367Q521 1310 484 1273T388 1234Q331 1232 292 1268T253 1359Z" />
-<glyph unicode="j" horiz-adv-x="508" d="M451 1082L252 -95Q230 -263 136 -352T-109 -440Q-173 -438 -244 -421L-224 -229Q-178 -240 -140 -240Q-13 -240 13 -91L214 1082H451ZM243 1359Q243 1417 279 1454T375 1494Q433 1496 471 1460T510 1367Q510 1310 473
-1273T377 1234Q317 1234 280 1269T243 1359Z" />
-<glyph unicode="k" horiz-adv-x="1047" d="M447 462L313 343L254 0H17L283 1536H520L368 664L451 750L795 1082H1098L618 620L934 0H677L447 462Z" />
-<glyph unicode="l" horiz-adv-x="517" d="M268 0H31L298 1536H535L268 0Z" />
-<glyph unicode="m" horiz-adv-x="1739" d="M425 1083L404 968Q538 1106 724 1102Q826 1100 893 1055T985 936Q1135 1106 1329 1102Q1487 1098 1563 994T1621 701L1504 0H1267L1385 703Q1390 747 1386 784Q1370 901 1238 904Q1091 908 1006 743L1003 721L879 0H641L759
-700Q764 743 760 780Q744 901 612 904Q479 906 390 785L253 0H16L203 1082L425 1083Z" />
-<glyph unicode="n" horiz-adv-x="1115" d="M423 1083L399 956Q538 1106 720 1102Q872 1099 945 994T999 699L882 0H645L763 702Q768 745 764 782Q751 901 622 904Q487 906 385 771L250 0H13L200 1082L423 1083Z" />
-<glyph unicode="o" horiz-adv-x="1141" d="M73 545Q90 704 166 834T363 1035T629 1102Q768 1100 869 1028T1016 831T1049 553Q1033 381 956 249T758 47T490 -20Q352 -18 252 53T104 249T70 524L73 545ZM306 408Q311 303 361 240T502 173Q624 170 706 267T810 532L816
-630Q816 758 765 831T617 908Q465 912 377 759Q324 666 310 545Q302 461 306 408Z" />
-<glyph unicode="p" horiz-adv-x="1128" d="M1029 537Q1009 375 943 243T774 44T544 -21Q375 -17 278 99L181 -416H-57L203 1082L420 1083L402 971Q526 1106 697 1102Q800 1101 876 1050T992 900T1036 682Q1037 621 1029 537ZM795 558L800 631Q803 760 758 831T621
-904Q487 908 389 781L305 298Q350 177 488 173Q606 170 686 265T795 558Z" />
-<glyph unicode="q" horiz-adv-x="1138" d="M68 543Q88 714 159 846T333 1042T563 1103Q735 1099 827 974L866 1083L1080 1082L820 -416H583L681 93Q560 -24 404 -20Q249 -18 159 95T62 399Q59 462 65 522L68 543ZM303 522L298 450Q295 315 340 246T474 174Q549
-171 604 205T705 296L793 790Q741 904 611 908Q497 911 418 822T310 569L303 522Z" />
-<glyph unicode="r" horiz-adv-x="708" d="M724 860Q678 870 631 870Q475 874 383 741L253 0H16L203 1082L428 1083L404 960Q515 1107 660 1104Q693 1104 751 1089L724 860Z" />
-<glyph unicode="s" horiz-adv-x="1035" d="M663 300Q680 399 535 437T336 499Q130 587 137 767Q142 913 269 1008T575 1102Q747 1100 855 1005T962 756L727 757Q729 832 686 874T568 919Q489 919 433 880T367 778Q353 687 495 652T705 586Q903 499 896 314Q891
-211 829 135T661 18T438 -20Q261 -18 145 83T30 342L259 341Q261 254 311 209T448 163Q536 163 594 199T663 300Z" />
-<glyph unicode="t" horiz-adv-x="671" d="M547 1345L501 1082H686L655 902H469L367 296Q364 271 366 251Q372 186 446 183Q483 183 530 192L514 2Q440 -19 365 -19Q241 -17 180 65T131 284L232 902H59L91 1082H263L309 1345H547Z" />
-<glyph unicode="u" horiz-adv-x="1114" d="M685 107Q562 -24 377 -20Q272 -18 203 32T104 171T86 382L203 1082H440L322 379Q318 342 321 307Q331 183 446 178Q603 172 700 304L836 1082H1073L886 0H664L685 107Z" />
-<glyph unicode="v" horiz-adv-x="993" d="M442 311L784 1082H1037L504 0H298L100 1082H338L442 311Z" />
-<glyph unicode="w" horiz-adv-x="1486" d="M993 337L1290 1082H1528L1054 0H859L764 740L414 0H218L119 1082H343L384 348L726 1082H905L993 337Z" />
-<glyph unicode="x" horiz-adv-x="1009" d="M511 728L766 1082H1043L629 538L870 0H622L471 369L205 0H-71L356 560L123 1082H371L511 728Z" />
-<glyph unicode="y" horiz-adv-x="977" d="M440 350L780 1082H1042L401 -187Q267 -443 48 -440Q-6 -438 -75 -420L-55 -232L-12 -236Q74 -239 130 -204T224 -93L281 19L100 1082H346L440 350Z" />
-<glyph unicode="z" horiz-adv-x="1009" d="M312 194H862L828 0H-25L5 171L653 886H138L173 1082H996L967 917L312 194Z" />
-<glyph unicode="{" horiz-adv-x="676" d="M461 -359Q303 -308 225 -188T166 106L194 310Q199 355 195 394Q182 516 48 527L65 705Q264 715 295 936L326 1160Q383 1496 738 1600L773 1457Q580 1387 545 1125L516 907Q483 710 298 614Q371 559 398 478T416 309L386
-79L383 8Q380 -162 511 -220L461 -359Z" />
-<glyph unicode="|" horiz-adv-x="509" d="M196 -270H32L302 1456H466L196 -270Z" />
-<glyph unicode="}" horiz-adv-x="676" d="M-103 -219Q81 -155 122 93L156 337Q191 532 381 623Q269 697 255 841Q250 884 255 929L285 1159L289 1231Q289 1401 160 1458L215 1595Q378 1541 450 1421T504 1132L476 928Q471 882 475 844Q488 720 623 709L605 531Q405
-521 375 302L344 79Q287 -261 -68 -363L-103 -219Z" />
-<glyph unicode="~" horiz-adv-x="1330" d="M1226 788Q1214 614 1116 498T870 386Q789 388 726 425T605 520T514 596T447 614Q312 617 278 425H91Q105 600 204 710T449 816Q531 814 596 776T717 681T807 606T872 588Q940 588 986 640T1049 785L1226 788Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="505" />
-<glyph unicode="&#xa1;" horiz-adv-x="536" d="M175 662H379L225 -364H-26L175 662ZM462 975Q462 918 425 880T329 839T232 874T194 967Q194 1024 231 1062T327 1102Q385 1104 423 1067T462 975Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1125" d="M502 173Q590 171 654 223T738 357L961 358Q947 217 840 118T573 -11L526 -245H330L378 -9Q271 18 203 91T105 276T90 520L92 540Q117 769 240 914T556 1093L602 1318H797L751 1091Q883 1058 956 953T1028 693H807Q807
-790 761 846T632 907Q489 913 405 780T320 407Q320 301 366 239T502 173Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1179" d="M494 598L472 424Q455 294 366 199L1046 202L1010 0H-10L26 201L95 199Q195 235 223 413L247 598H90L125 797H276L307 1048Q323 1175 392 1274T570 1426T806 1475Q986 1471 1087 1363T1181 1072L942 1073Q947 1168
-906 1219T782 1275Q692 1277 629 1210T551 1031L522 797H824L789 598H494Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1404" d="M980 105Q798 -24 610 -20Q415 -16 280 106L128 -26L8 129L162 257Q135 342 125 428Q106 575 150 717T296 976L181 1131L332 1264L442 1121Q617 1237 795 1233Q980 1231 1116 1117L1286 1265L1407 1109L1238 967Q1300
-782 1280 615Q1254 414 1123 256L1234 107L1082 -27L980 105ZM306 599Q291 489 325 389T436 228T618 163Q731 159 835 219T1011 388T1099 616Q1114 726 1080 825T969 985T787 1049Q673 1053 568 992T392 825T306 599Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1065" d="M566 849L925 1456H1200L745 742H966L939 590H646L621 452H916L889 301H596L543 0H297L349 301H50L77 452H375L400 590H100L127 742H374L165 1456H419L566 849Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="503" d="M-20 -270L119 525H342L204 -270H-20ZM372 698H148L280 1456H504L372 698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1244" d="M1106 463Q1092 282 892 177Q989 73 976 -95Q967 -216 896 -302T704 -432T439 -474Q215 -472 90 -359T-31 -49H209Q203 -156 266 -216T449 -279Q569 -279 647 -230T739 -98Q760 22 575 87L429 135L340 170Q63 289
-84 534Q98 718 296 821Q200 930 213 1094Q227 1270 376 1374T752 1476Q966 1472 1083 1358T1192 1046L956 1047Q962 1155 904 1216T741 1280Q627 1282 549 1236Q466 1187 452 1097Q430 963 620 907T894 807Q1123 691 1106 463ZM465 723Q344 668 324 550Q302 414
-484 353L679 289L719 274Q848 333 868 447Q890 576 696 644L465 723Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="884" d="M332 1485Q386 1485 421 1452T456 1369Q456 1318 421 1284T333 1247Q277 1247 243 1281T209 1363T243 1447T332 1485ZM653 1362Q653 1415 688 1448T775 1484Q831 1484 865 1450T899 1368Q899 1317 864 1283T776 1246Q720
-1246 687 1279T653 1362Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1566" d="M1091 596Q1079 446 987 362T741 282Q595 286 513 394T445 669L455 770Q474 958 578 1068T840 1176Q989 1172 1066 1088T1139 860L987 861Q992 951 956 995T839 1042Q746 1044 685 973T609 778T594 627L596 583Q601
-508 638 464T742 417Q909 410 940 595L1091 596ZM233 571Q252 367 380 237T697 104Q881 100 1045 209T1301 506T1375 887Q1356 1089 1230 1217T912 1351Q727 1355 563 1246T306 950T233 571ZM115 722Q132 872 200 1011T381 1259T627 1423T906 1476Q1084 1474 1227
-1376T1441 1104T1492 735Q1470 534 1355 355T1067 76T702 -20Q520 -16 379 82T166 354T115 722Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="896" d="M622 703Q617 743 619 773Q526 691 417 691Q311 691 251 752T194 911Q196 1026 289 1088T551 1151L655 1150L666 1203Q670 1228 669 1250Q662 1325 586 1328Q467 1332 440 1229L268 1243Q279 1354 367 1416T586 1477Q708
-1475 778 1400T838 1200L784 853L780 795Q779 750 788 703H622ZM457 833Q526 833 616 895L643 1033H560Q478 1030 427 999T368 915Q361 877 385 855T457 833Z" />
-<glyph unicode="&#xab;" horiz-adv-x="974" d="M530 524L696 138H548L329 527L330 547L670 937H849L530 524ZM622 524L788 138H640L421 527L422 547L762 937H941L622 524Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1109" d="M895 374H699L745 634H128L159 805H970L895 374Z" />
-<glyph unicode="&#xad;" horiz-adv-x="662" d="M565 521H54L89 717H600L565 521Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1566" d="M115 722Q137 920 248 1096T534 1376T906 1476Q1084 1474 1227 1376T1441 1104T1492 735Q1470 534 1355 355T1067 76T702 -20Q520 -16 379 82T166 354T115 722ZM232 571Q244 440 307 333T470 166T697 104Q853 100
-1000 182T1248 414T1372 736Q1393 895 1341 1038T1176 1264T912 1351Q727 1355 563 1246T306 951T232 571ZM654 653L601 316H453L586 1166L846 1165Q989 1160 1063 1093T1132 913Q1125 797 988 721Q1061 675 1068 575Q1070 544 1064 484T1058 395L1062 333L1061
-315H912Q907 352 909 388Q910 421 922 516Q928 579 906 613T818 651L654 653ZM674 787L803 786Q877 788 927 821T988 909Q999 968 970 998T851 1032L713 1033L674 787Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="967" d="M926 1292H257L283 1450H951L926 1292Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="765" d="M230 1199Q232 1310 314 1394T507 1477Q606 1475 673 1399T738 1217Q734 1103 654 1022T466 942Q364 944 296 1019T230 1199ZM366 1201Q360 1157 387 1121T463 1084Q518 1084 558 1123T604 1215Q610 1264 584 1300T510
-1337Q456 1337 414 1295T366 1201Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1075" d="M696 899H1029L997 700H665L604 312H393L454 700H107L139 899H484L544 1276H755L696 899ZM852 1H27L58 197H883L852 1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="745" d="M681 667H86L110 802L452 1083Q549 1166 561 1233Q568 1274 547 1297T484 1322Q426 1322 393 1287T347 1199L165 1198Q175 1319 262 1395T480 1469Q607 1467 680 1402T748 1232Q743 1106 593 987L514 927L357 817L708
-815L681 667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="745" d="M345 1133H428Q489 1135 527 1163T573 1237Q582 1304 508 1317L485 1319Q392 1321 364 1245L178 1244Q187 1349 270 1410T478 1469Q607 1466 683 1407T755 1249Q752 1190 716 1147T597 1065Q715 1024 711 895Q708
-784 614 719T381 656Q256 658 180 723T103 898L280 897Q284 808 390 806Q444 806 485 834T534 909Q547 998 427 1003H335L345 1133Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="657" d="M437 1536H722L406 1233H200L437 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1185" d="M461 1082L359 460Q351 375 353 335Q358 178 491 175Q643 171 733 295L871 1082H1108L921 0H706L721 86Q617 -24 477 -22Q369 -22 287 35L201 -416H-35L225 1082H461Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="985" d="M530 0L620 520L564 521Q353 524 239 651T145 980Q164 1191 313 1324T688 1457L988 1456L735 0H530Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="571" d="M158 710Q158 771 196 810T294 851Q355 853 394 814T433 718Q433 659 394 621T295 580Q236 578 197 615T158 710Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="522" d="M197 4L178 -55Q240 -69 271 -111T302 -217Q300 -326 211 -385T-45 -451L-43 -310Q94 -304 110 -214Q119 -154 37 -141L-19 -135L26 2L197 4Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="745" d="M510 667H329L428 1233L224 1186L251 1339L617 1454H640L510 667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="917" d="M586 1477Q730 1473 811 1374T882 1121L876 1055Q861 891 756 788T498 689Q357 693 274 791T201 1044L207 1110Q217 1220 268 1304T403 1434T586 1477ZM373 1041Q365 944 399 890T504 834Q583 832 637 890T703 1052L711
-1122Q719 1222 685 1274T580 1329Q500 1331 446 1272T381 1113L373 1041Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="974" d="M303 937L523 549L521 528L182 138H2L321 549L156 937H303ZM665 937L885 549L883 528L544 138H364L683 549L518 937H665Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1453" d="M471 664H290L389 1230L185 1183L212 1336L578 1451H601L471 664ZM366 119L245 198L1125 1325L1245 1246L366 119ZM1222 313L1322 314L1294 163H1202L1174 0H990L1020 163H673L686 296L1118 788L1304 790L1222 313ZM875
-314H1045L1096 559L1078 535L875 314Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1542" d="M324 119L203 198L1083 1325L1203 1246L324 119ZM463 667H282L381 1233L177 1186L204 1339L570 1454H593L463 667ZM1336 0H741L765 135L1107 416Q1204 499 1216 566Q1223 607 1202 630T1139 655Q1081 655 1048 620T1002
-532L820 531Q830 652 917 728T1135 802Q1262 800 1335 735T1403 565Q1398 439 1248 320L1169 260L1012 150L1363 148L1336 0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1584" d="M503 119L382 198L1262 1325L1382 1246L503 119ZM1339 313L1439 314L1411 163H1319L1291 0H1107L1137 163H790L803 296L1235 788L1421 790L1339 313ZM992 314H1162L1213 559L1195 535L992 314ZM392 1133H475Q536
-1135 574 1163T620 1237Q629 1304 555 1317L532 1319Q439 1321 411 1245L225 1244Q234 1349 317 1410T525 1469Q654 1466 730 1407T802 1249Q799 1190 763 1147T644 1065Q762 1024 758 895Q755 784 661 719T428 656Q303 658 227 723T150 898L327 897Q331 808 437
-806Q491 806 532 834T581 909Q594 998 474 1003H382L392 1133Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="976" d="M619 662Q608 546 565 461T426 288L344 214Q224 105 210 -6Q199 -88 236 -136T351 -186Q434 -188 491 -138T566 0H803Q786 -179 656 -284T338 -386Q155 -382 55 -280T-33 -9Q-18 170 177 341L286 435Q381 521 401
-661L619 662ZM701 976Q701 917 664 880T569 840Q510 838 472 875T434 968Q434 1025 471 1063T567 1103Q625 1105 663 1068T701 976Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543ZM945 1543H764L549 1846H803L945 1543Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543ZM939 1846H1224L908 1543H702L939 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543ZM1169 1572V1555L984 1558L867 1713L694 1559L501 1555L500 1573L801 1847H937L1169 1572Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543ZM1225 1824Q1213 1705 1149 1635T990 1565Q966 1565 944 1572T868 1609T788 1649T733 1658Q654 1655 627 1554L478 1562Q488
-1676 553 1751T714 1825Q762 1824 837 1780T946 1731L971 1730Q1052 1733 1080 1835L1225 1824Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543ZM628 1795Q682 1795 717 1762T752 1679Q752 1628 717 1594T629 1557Q573 1557 539 1591T505 1673T539 1757T628 1795ZM949
-1672Q949 1725 984 1758T1071 1794Q1127 1794 1161 1760T1195 1678Q1195 1627 1160 1593T1072 1556Q1016 1556 983 1589T949 1672Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1332" d="M893 339H348L174 0H-92L694 1456H916L1198 0H950L893 339ZM452 543H860L761 1145L452 543ZM646 1724Q646 1814 712 1877T872 1941Q954 1941 1015 1883T1076 1740Q1076 1651 1010 1589T851 1526Q764 1526 705 1584T646
-1724ZM753 1726Q747 1686 772 1653T840 1620Q890 1620 926 1656T969 1738Q975 1781 951 1813T883 1845Q833 1845 796 1809T753 1726Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1877" d="M1719 0H848L892 340H413L175 0H-121L941 1456H1912L1877 1259H1251L1196 851H1729L1694 654H1170L1110 196H1754L1719 0ZM562 555H920L1005 1189L562 555Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1307" d="M1194 475Q1157 247 989 112T580 -20Q441 -17 337 46T173 229T107 502Q101 616 135 812T265 1165T502 1400T815 1476Q1032 1472 1158 1340T1293 974H1048Q1043 1130 983 1199T803 1272Q640 1277 530 1155T382 800L362
-667L353 565Q345 462 367 372T447 234T592 183Q871 172 950 473L1194 475ZM639 -1L620 -60Q682 -74 713 -116T744 -222Q742 -331 653 -390T397 -456L399 -315Q536 -309 552 -219Q561 -159 479 -146L423 -140L468 -3L639 -1Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1133" d="M979 650H399L321 202H999L964 0H39L291 1456H1210L1174 1252H503L433 850H1014L979 650ZM889 1550H708L493 1853H747L889 1550Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1133" d="M979 650H399L321 202H999L964 0H39L291 1456H1210L1174 1252H503L433 850H1014L979 650ZM883 1853H1168L852 1550H646L883 1853Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1133" d="M979 650H399L321 202H999L964 0H39L291 1456H1210L1174 1252H503L433 850H1014L979 650ZM1113 1579V1562L928 1565L811 1720L638 1566L445 1562L444 1580L745 1854H881L1113 1579Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1133" d="M979 650H399L321 202H999L964 0H39L291 1456H1210L1174 1252H503L433 850H1014L979 650ZM572 1802Q626 1802 661 1769T696 1686Q696 1635 661 1601T573 1564Q517 1564 483 1598T449 1680T483 1764T572 1802ZM893
-1679Q893 1732 928 1765T1015 1801Q1071 1801 1105 1767T1139 1685Q1139 1634 1104 1600T1016 1563Q960 1563 927 1596T893 1679Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="571" d="M299 0H53L306 1456H552L299 0ZM562 1550H381L166 1853H420L562 1550Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="571" d="M299 0H53L306 1456H552L299 0ZM555 1853H840L524 1550H318L555 1853Z" />
-<glyph unicode="&#xce;" horiz-adv-x="571" d="M299 0H53L306 1456H552L299 0ZM786 1579V1562L601 1565L484 1720L311 1566L118 1562L117 1580L418 1854H554L786 1579Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="571" d="M299 0H53L306 1456H552L299 0ZM245 1802Q299 1802 334 1769T369 1686Q369 1635 334 1601T246 1564Q190 1564 156 1598T122 1680T156 1764T245 1802ZM566 1679Q566 1732 601 1765T688 1801Q744 1801 778 1767T812
-1685Q812 1634 777 1600T689 1563Q633 1563 600 1596T566 1679Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1338" d="M69 0L182 652H-1L29 822H211L321 1456L715 1455Q897 1455 1028 1365T1219 1115T1255 763L1244 684Q1214 483 1112 328T847 86T491 0H69ZM650 652H429L351 202L497 201Q695 201 825 326T993 673Q1019 825 1012 938Q1003
-1083 928 1165T718 1251L533 1252L458 822H680L650 652Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1420" d="M1161 0H922L467 1043L286 0H39L292 1456H531L986 409L1168 1456H1414L1161 0ZM1265 1824Q1253 1705 1189 1635T1030 1565Q1006 1565 984 1572T908 1609T828 1649T773 1658Q694 1655 667 1554L518 1562Q528 1676
-593 1751T754 1825Q802 1824 877 1780T986 1731L1011 1730Q1092 1733 1120 1835L1265 1824Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1382" d="M599 -20Q457 -17 350 48T182 236T114 517Q107 642 136 809T241 1113T422 1338Q595 1480 822 1476Q1038 1472 1166 1327T1307 935Q1313 811 1285 651T1187 356T1014 131Q836 -25 599 -20ZM1054 767L1063 873Q1069
-982 1044 1074T960 1215T809 1267Q683 1271 586 1196T428 968T357 584Q347 401 413 296T611 187Q784 182 896 317T1044 697L1054 767ZM968 1543H787L572 1846H826L968 1543Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1382" d="M599 -20Q457 -17 350 48T182 236T114 517Q107 642 136 809T241 1113T422 1338Q595 1480 822 1476Q1038 1472 1166 1327T1307 935Q1313 811 1285 651T1187 356T1014 131Q836 -25 599 -20ZM1054 767L1063 873Q1069
-982 1044 1074T960 1215T809 1267Q683 1271 586 1196T428 968T357 584Q347 401 413 296T611 187Q784 182 896 317T1044 697L1054 767ZM962 1846H1247L931 1543H725L962 1846Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1382" d="M599 -20Q457 -17 350 48T182 236T114 517Q107 642 136 809T241 1113T422 1338Q595 1480 822 1476Q1038 1472 1166 1327T1307 935Q1313 811 1285 651T1187 356T1014 131Q836 -25 599 -20ZM1054 767L1063 873Q1069
-982 1044 1074T960 1215T809 1267Q683 1271 586 1196T428 968T357 584Q347 401 413 296T611 187Q784 182 896 317T1044 697L1054 767ZM1192 1572V1555L1007 1558L890 1713L717 1559L524 1555L523 1573L824 1847H960L1192 1572Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1382" d="M599 -20Q457 -17 350 48T182 236T114 517Q107 642 136 809T241 1113T422 1338Q595 1480 822 1476Q1038 1472 1166 1327T1307 935Q1313 811 1285 651T1187 356T1014 131Q836 -25 599 -20ZM1054 767L1063 873Q1069
-982 1044 1074T960 1215T809 1267Q683 1271 586 1196T428 968T357 584Q347 401 413 296T611 187Q784 182 896 317T1044 697L1054 767ZM1248 1824Q1236 1705 1172 1635T1013 1565Q989 1565 967 1572T891 1609T811 1649T756 1658Q677 1655 650 1554L501 1562Q511
-1676 576 1751T737 1825Q785 1824 860 1780T969 1731L994 1730Q1075 1733 1103 1835L1248 1824Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1382" d="M599 -20Q457 -17 350 48T182 236T114 517Q107 642 136 809T241 1113T422 1338Q595 1480 822 1476Q1038 1472 1166 1327T1307 935Q1313 811 1285 651T1187 356T1014 131Q836 -25 599 -20ZM1054 767L1063 873Q1069
-982 1044 1074T960 1215T809 1267Q683 1271 586 1196T428 968T357 584Q347 401 413 296T611 187Q784 182 896 317T1044 697L1054 767ZM651 1795Q705 1795 740 1762T775 1679Q775 1628 740 1594T652 1557Q596 1557 562 1591T528 1673T562 1757T651 1795ZM972 1672Q972
-1725 1007 1758T1094 1794Q1150 1794 1184 1760T1218 1678Q1218 1627 1183 1593T1095 1556Q1039 1556 1006 1589T972 1672Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1069" d="M35 375L398 696L147 1019L305 1158L555 837L917 1158L1044 997L681 676L932 353L774 214L523 534L162 214L35 375Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1380" d="M599 -21Q443 -17 320 56L202 -95L21 -94L215 146Q107 322 109 548L112 627Q131 895 227 1086T478 1378T823 1477Q1013 1473 1141 1374L1253 1517H1432L1236 1273Q1292 1152 1306 1024Q1323 854 1286 649T1149 287T906
-54T599 -21ZM349 522Q346 437 366 354L1003 1185Q941 1263 812 1268Q646 1273 533 1145T379 784Q353 635 349 522ZM1073 907Q1078 977 1072 1048L451 238Q514 188 610 186Q786 181 899 320T1049 710L1066 831L1073 907Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1305" d="M1327 1456L1162 483Q1128 250 963 112T562 -22Q344 -18 218 110T102 444L105 482L270 1456H516L351 481Q333 342 392 264T574 182Q709 178 799 255T914 476L1081 1456H1327ZM928 1543H747L532 1846H786L928 1543Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1305" d="M1327 1456L1162 483Q1128 250 963 112T562 -22Q344 -18 218 110T102 444L105 482L270 1456H516L351 481Q333 342 392 264T574 182Q709 178 799 255T914 476L1081 1456H1327ZM922 1846H1207L891 1543H685L922 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1305" d="M1327 1456L1162 483Q1128 250 963 112T562 -22Q344 -18 218 110T102 444L105 482L270 1456H516L351 481Q333 342 392 264T574 182Q709 178 799 255T914 476L1081 1456H1327ZM1152 1572V1555L967 1558L850 1713L677
-1559L484 1555L483 1573L784 1847H920L1152 1572Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1305" d="M1327 1456L1162 483Q1128 250 963 112T562 -22Q344 -18 218 110T102 444L105 482L270 1456H516L351 481Q333 342 392 264T574 182Q709 178 799 255T914 476L1081 1456H1327ZM611 1795Q665 1795 700 1762T735 1679Q735
-1628 700 1594T612 1557Q556 1557 522 1591T488 1673T522 1757T611 1795ZM932 1672Q932 1725 967 1758T1054 1794Q1110 1794 1144 1760T1178 1678Q1178 1627 1143 1593T1055 1556Q999 1556 966 1589T932 1672Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1221" d="M627 768L1071 1456H1357L715 523L624 0H376L472 549L161 1456H422L627 768ZM882 1846H1167L851 1543H645L882 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1199" d="M529 1456L480 1176L683 1175Q905 1174 1029 1057T1139 746Q1123 543 970 421T581 299L329 300L276 0H39L292 1456H529ZM447 981L362 495L587 493Q715 495 801 563T902 745Q916 852 860 914T698 980L447 981Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1227" d="M264 0H27L216 1105Q244 1315 372 1438T700 1558Q867 1554 962 1460T1044 1209Q1040 1160 1022 1117T956 996T894 886T873 815Q865 766 888 715T979 588T1073 456T1098 345Q1089 172 965 74T652 -21Q481 -19 368
-46L436 239Q539 173 647 173Q735 173 794 217T864 335Q872 387 847 438T752 564Q626 698 635 809Q639 866 664 912T719 1003T775 1094T808 1195Q817 1271 783 1317T678 1367Q588 1370 530 1305T451 1104L264 0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174ZM777 1233H596L381 1536H635L777 1233Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174ZM771 1536H1056L740 1233H534L771 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174ZM1001 1262V1245L816 1248L699 1403L526 1249L333 1245L332 1263L633 1537H769L1001 1262Z"
-/>
-<glyph unicode="&#xe3;" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174ZM1057 1514Q1045 1395 981 1325T822 1255Q798 1255 776 1262T700 1299T620 1339T565 1348Q486
-1345 459 1244L310 1252Q320 1366 385 1441T546 1515Q594 1514 669 1470T778 1421L803 1420Q884 1423 912 1525L1057 1514Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174ZM460 1485Q514 1485 549 1452T584 1369Q584 1318 549 1284T461 1247Q405 1247 371 1281T337
-1363T371 1447T460 1485ZM781 1362Q781 1415 816 1448T903 1484Q959 1484 993 1450T1027 1368Q1027 1317 992 1283T904 1246Q848 1246 815 1279T781 1362Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1085" d="M659 0Q647 40 649 101Q515 -24 360 -20Q219 -18 127 70T40 295Q48 466 188 564T564 662L718 660L732 734Q738 773 732 807Q712 915 589 918Q513 920 456 880T385 771L148 769Q155 869 219 944T389 1062T613 1102Q790
-1098 889 996T971 730L888 223L880 133Q877 74 895 18L894 0H659ZM415 174Q490 172 554 208T663 303L700 508L587 509Q453 509 373 459T282 320Q274 253 311 215T415 174ZM478 1414Q478 1504 544 1567T704 1631Q786 1631 847 1573T908 1430Q908 1341 842 1279T683
-1216Q596 1216 537 1274T478 1414ZM585 1416Q579 1376 604 1343T672 1310Q722 1310 758 1346T801 1428Q807 1471 783 1503T715 1535Q665 1535 628 1499T585 1416Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1687" d="M1130 -19Q1015 -19 921 22T774 140Q602 -24 349 -20Q195 -18 105 69T23 304Q33 465 163 554T524 643L715 641L728 715Q734 753 730 787Q713 904 594 907Q507 909 448 867T375 752L138 771Q145 869 206 945T377
-1063T610 1103Q825 1098 915 970Q1070 1106 1255 1102Q1449 1096 1548 961T1622 612L1601 471H932Q918 335 977 257T1152 176Q1237 174 1312 200T1462 266L1520 98Q1455 41 1350 10T1130 -19ZM402 163Q516 163 654 265L694 475L525 476Q418 473 346 426T261 300Q252
-237 291 201T402 163ZM1239 908Q1143 911 1070 844T951 641H1389L1395 674Q1402 719 1398 761Q1384 902 1239 908Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1050" d="M488 173Q573 171 638 222T722 357L946 358Q935 251 869 163T698 26T481 -20Q342 -18 244 52T101 245T71 521L74 556Q91 713 165 840T358 1037T620 1102Q796 1098 901 986T1006 693H784Q784 786 739 845T607 908Q468
-912 388 790T302 446Q295 177 488 173ZM513 -1L494 -60Q556 -74 587 -116T618 -222Q616 -331 527 -390T271 -456L273 -315Q410 -309 426 -219Q435 -159 353 -146L297 -140L342 -3L513 -1Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1076" d="M506 -20Q365 -17 262 51T109 237T71 500L74 541Q92 706 170 837T366 1037T620 1102Q823 1098 924 951T1001 568L987 464H306Q297 335 358 256T526 175Q679 170 808 308L928 182Q860 85 749 32T506 -20ZM607 908Q419
-914 325 642L774 641L778 662Q785 708 779 752Q768 823 723 864T607 908ZM754 1233H573L358 1536H612L754 1233Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1076" d="M506 -20Q365 -17 262 51T109 237T71 500L74 541Q92 706 170 837T366 1037T620 1102Q823 1098 924 951T1001 568L987 464H306Q297 335 358 256T526 175Q679 170 808 308L928 182Q860 85 749 32T506 -20ZM607 908Q419
-914 325 642L774 641L778 662Q785 708 779 752Q768 823 723 864T607 908ZM748 1536H1033L717 1233H511L748 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1076" d="M506 -20Q365 -17 262 51T109 237T71 500L74 541Q92 706 170 837T366 1037T620 1102Q823 1098 924 951T1001 568L987 464H306Q297 335 358 256T526 175Q679 170 808 308L928 182Q860 85 749 32T506 -20ZM607 908Q419
-914 325 642L774 641L778 662Q785 708 779 752Q768 823 723 864T607 908ZM978 1262V1245L793 1248L676 1403L503 1249L310 1245L309 1263L610 1537H746L978 1262Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1076" d="M506 -20Q365 -17 262 51T109 237T71 500L74 541Q92 706 170 837T366 1037T620 1102Q823 1098 924 951T1001 568L987 464H306Q297 335 358 256T526 175Q679 170 808 308L928 182Q860 85 749 32T506 -20ZM607 908Q419
-914 325 642L774 641L778 662Q785 708 779 752Q768 823 723 864T607 908ZM437 1485Q491 1485 526 1452T561 1369Q561 1318 526 1284T438 1247Q382 1247 348 1281T314 1363T348 1447T437 1485ZM758 1362Q758 1415 793 1448T880 1484Q936 1484 970 1450T1004 1368Q1004
-1317 969 1283T881 1246Q825 1246 792 1279T758 1362Z" />
-<glyph unicode="&#xec;" horiz-adv-x="532" d="M271 0H34L222 1082H459L271 0ZM743 1482H562L347 1785H601L743 1482Z" />
-<glyph unicode="&#xed;" horiz-adv-x="532" d="M271 0H34L222 1082H459L271 0ZM480 1785H765L449 1482H243L480 1785Z" />
-<glyph unicode="&#xee;" horiz-adv-x="532" d="M271 0H34L222 1082H459L271 0ZM711 1255V1238L526 1241L409 1396L236 1242L43 1238L42 1256L343 1530H479L711 1255Z" />
-<glyph unicode="&#xef;" horiz-adv-x="532" d="M271 0H34L222 1082H459L271 0ZM170 1478Q224 1478 259 1445T294 1362Q294 1311 259 1277T171 1240Q115 1240 81 1274T47 1356T81 1440T170 1478ZM491 1355Q491 1408 526 1441T613 1477Q669 1477 703 1443T737 1361Q737
-1310 702 1276T614 1239Q558 1239 525 1272T491 1355Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1165" d="M933 1300Q1024 1145 1056 983T1066 642L1054 556Q1031 389 947 251T745 45T490 -21Q363 -17 265 47T118 221T82 460Q95 604 163 724T343 911T588 974Q726 970 833 881Q829 1034 733 1172L509 1036L446 1157L630
-1265Q539 1338 374 1386L465 1580Q687 1526 835 1395L1036 1517L1098 1396L933 1300ZM834 685Q780 782 633 787Q506 789 421 698T319 460Q305 340 357 258T508 172Q626 167 707 271T814 548L834 685Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1115" d="M423 1083L399 956Q538 1106 720 1102Q872 1099 945 994T999 699L882 0H645L763 702Q768 745 764 782Q751 901 622 904Q487 906 385 771L250 0H13L200 1082L423 1083ZM1063 1514Q1051 1395 987 1325T828 1255Q804
-1255 782 1262T706 1299T626 1339T571 1348Q492 1345 465 1244L316 1252Q326 1366 391 1441T552 1515Q600 1514 675 1470T784 1421L809 1420Q890 1423 918 1525L1063 1514Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1141" d="M73 545Q90 704 166 834T363 1035T629 1102Q768 1100 869 1028T1016 831T1049 553Q1033 381 956 249T758 47T490 -20Q352 -18 252 53T104 249T70 524L73 545ZM306 408Q311 303 361 240T502 173Q624 170 706 267T810
-532L816 630Q816 758 765 831T617 908Q465 912 377 759Q324 666 310 545Q302 461 306 408ZM774 1233H593L378 1536H632L774 1233Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1141" d="M73 545Q90 704 166 834T363 1035T629 1102Q768 1100 869 1028T1016 831T1049 553Q1033 381 956 249T758 47T490 -20Q352 -18 252 53T104 249T70 524L73 545ZM306 408Q311 303 361 240T502 173Q624 170 706 267T810
-532L816 630Q816 758 765 831T617 908Q465 912 377 759Q324 666 310 545Q302 461 306 408ZM768 1536H1053L737 1233H531L768 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1141" d="M73 545Q90 704 166 834T363 1035T629 1102Q768 1100 869 1028T1016 831T1049 553Q1033 381 956 249T758 47T490 -20Q352 -18 252 53T104 249T70 524L73 545ZM306 408Q311 303 361 240T502 173Q624 170 706 267T810
-532L816 630Q816 758 765 831T617 908Q465 912 377 759Q324 666 310 545Q302 461 306 408ZM998 1262V1245L813 1248L696 1403L523 1249L330 1245L329 1263L630 1537H766L998 1262Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1141" d="M73 545Q90 704 166 834T363 1035T629 1102Q768 1100 869 1028T1016 831T1049 553Q1033 381 956 249T758 47T490 -20Q352 -18 252 53T104 249T70 524L73 545ZM306 408Q311 303 361 240T502 173Q624 170 706 267T810
-532L816 630Q816 758 765 831T617 908Q465 912 377 759Q324 666 310 545Q302 461 306 408ZM1054 1514Q1042 1395 978 1325T819 1255Q795 1255 773 1262T697 1299T617 1339T562 1348Q483 1345 456 1244L307 1252Q317 1366 382 1441T543 1515Q591 1514 666 1470T775
-1421L800 1420Q881 1423 909 1525L1054 1514Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1141" d="M73 545Q90 704 166 834T363 1035T629 1102Q768 1100 869 1028T1016 831T1049 553Q1033 381 956 249T758 47T490 -20Q352 -18 252 53T104 249T70 524L73 545ZM306 408Q311 303 361 240T502 173Q624 170 706 267T810
-532L816 630Q816 758 765 831T617 908Q465 912 377 759Q324 666 310 545Q302 461 306 408ZM457 1485Q511 1485 546 1452T581 1369Q581 1318 546 1284T458 1247Q402 1247 368 1281T334 1363T368 1447T457 1485ZM778 1362Q778 1415 813 1448T900 1484Q956 1484 990
-1450T1024 1368Q1024 1317 989 1283T901 1246Q845 1246 812 1279T778 1362Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1144" d="M1044 582H61L98 794H1082L1044 582ZM508 1091Q508 1152 547 1189T644 1229Q705 1231 744 1193T783 1099Q783 1042 746 1003T646 962Q587 960 548 996T508 1091ZM366 274Q366 331 404 371T503 413Q560 415 600 379T641
-282Q641 223 603 186T504 146Q447 144 407 180T366 274Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1135" d="M68 544Q83 662 130 767T255 951Q411 1108 634 1104Q728 1102 823 1067L920 1211L1075 1210L929 1000Q1041 868 1048 673Q1050 615 1042 532Q1022 373 945 244T745 46T475 -22Q389 -20 298 11L197 -137L42 -136L188
-73Q70 203 62 402Q59 463 66 523L68 544ZM291 399Q290 336 310 275L714 890Q676 909 623 911Q523 912 448 848T332 663T291 399ZM820 673Q821 733 803 793L403 186Q443 172 485 170Q606 167 691 262T807 532Q819 616 820 673Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1114" d="M685 107Q562 -24 377 -20Q272 -18 203 32T104 171T86 382L203 1082H440L322 379Q318 342 321 307Q331 183 446 178Q603 172 700 304L836 1082H1073L886 0H664L685 107ZM779 1233H598L383 1536H637L779 1233Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1114" d="M685 107Q562 -24 377 -20Q272 -18 203 32T104 171T86 382L203 1082H440L322 379Q318 342 321 307Q331 183 446 178Q603 172 700 304L836 1082H1073L886 0H664L685 107ZM773 1536H1058L742 1233H536L773 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1114" d="M685 107Q562 -24 377 -20Q272 -18 203 32T104 171T86 382L203 1082H440L322 379Q318 342 321 307Q331 183 446 178Q603 172 700 304L836 1082H1073L886 0H664L685 107ZM1003 1262V1245L818 1248L701 1403L528 1249L335
-1245L334 1263L635 1537H771L1003 1262Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1114" d="M685 107Q562 -24 377 -20Q272 -18 203 32T104 171T86 382L203 1082H440L322 379Q318 342 321 307Q331 183 446 178Q603 172 700 304L836 1082H1073L886 0H664L685 107ZM462 1485Q516 1485 551 1452T586 1369Q586
-1318 551 1284T463 1247Q407 1247 373 1281T339 1363T373 1447T462 1485ZM783 1362Q783 1415 818 1448T905 1484Q961 1484 995 1450T1029 1368Q1029 1317 994 1283T906 1246Q850 1246 817 1279T783 1362Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="977" d="M440 350L780 1082H1042L401 -187Q267 -443 48 -440Q-6 -438 -75 -420L-55 -232L-12 -236Q74 -239 130 -204T224 -93L281 19L100 1082H346L440 350ZM719 1536H1004L688 1233H482L719 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1150" d="M1036 536Q1016 372 948 240T778 41T550 -22Q382 -18 284 99L187 -416H-51L288 1536H525L419 982Q541 1106 704 1102Q861 1098 949 987T1043 683Q1044 623 1036 536ZM801 558L806 632Q809 759 764 829T626 904Q493
-908 395 781L310 298Q357 177 494 173Q612 170 692 265T801 558Z" />
-<glyph unicode="&#xff;" horiz-adv-x="977" d="M440 350L780 1082H1042L401 -187Q267 -443 48 -440Q-6 -438 -75 -420L-55 -232L-12 -236Q74 -239 130 -204T224 -93L281 19L100 1082H346L440 350ZM408 1485Q462 1485 497 1452T532 1369Q532 1318 497 1284T409
-1247Q353 1247 319 1281T285 1363T319 1447T408 1485ZM729 1362Q729 1415 764 1448T851 1484Q907 1484 941 1450T975 1368Q975 1317 940 1283T852 1246Q796 1246 763 1279T729 1362Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1291" d="M1402 621H412L454 817H1444L1402 621Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1546" d="M1707 621H387L443 817H1763L1707 621Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="445" d="M427 1562L546 1483Q439 1342 411 1215L382 1056H174L194 1180Q232 1411 427 1562Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="441" d="M257 1024L138 1103Q244 1242 272 1371L302 1536H510L488 1400Q451 1174 257 1024Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="458" d="M26 -298L-92 -218Q10 -81 37 48L65 202H277L258 79Q223 -145 26 -298Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="774" d="M436 1562L555 1483Q448 1342 420 1215L391 1056H183L203 1180Q241 1411 436 1562ZM762 1562L881 1483Q774 1342 746 1215L717 1056H509L529 1180Q567 1411 762 1562Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="781" d="M270 1024L151 1103Q257 1242 285 1371L315 1536H523L501 1400Q464 1174 270 1024ZM594 1024L475 1103Q581 1242 609 1371L639 1536H847L825 1400Q788 1174 594 1024Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="763" d="M27 -318L-95 -238Q16 -78 42 70L74 255H286L257 73Q239 -40 178 -143T27 -318ZM339 -318L217 -238Q333 -75 358 70L390 255H603L573 72Q555 -44 492 -144T339 -318Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="704" d="M159 764Q165 864 227 926T386 988Q477 986 533 927T589 774L587 731Q580 631 518 574T360 516Q270 516 214 574T158 723L159 764Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="617" d="M294 524L460 138H312L93 527L94 547L434 937H613L294 524Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="608" d="M294 937L514 549L512 528L173 138H-7L312 549L147 937H294Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-500italic.ttf b/static/fonts/roboto-v18-latin-500italic.ttf
deleted file mode 100644
index dcf655fb2e..0000000000
Binary files a/static/fonts/roboto-v18-latin-500italic.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500italic.woff b/static/fonts/roboto-v18-latin-500italic.woff
deleted file mode 100644
index d4d8b157f3..0000000000
Binary files a/static/fonts/roboto-v18-latin-500italic.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-500italic.woff2 b/static/fonts/roboto-v18-latin-500italic.woff2
deleted file mode 100644
index 1b9589945e..0000000000
Binary files a/static/fonts/roboto-v18-latin-500italic.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700.eot b/static/fonts/roboto-v18-latin-700.eot
deleted file mode 100644
index 0df88af13d..0000000000
Binary files a/static/fonts/roboto-v18-latin-700.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700.svg b/static/fonts/roboto-v18-latin-700.svg
deleted file mode 100644
index 11db87dd0e..0000000000
--- a/static/fonts/roboto-v18-latin-700.svg
+++ /dev/null
@@ -1,309 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1191" ><font-face
-    font-family="Roboto"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="510" />
-<glyph unicode="!" horiz-adv-x="557" d="M405 447H165L131 1456H439L405 447ZM285 289Q358 289 402 246T447 136Q447 70 403 27T285 -16Q213 -16 169 27T124 136T168 245T285 289Z" />
-<glyph unicode="&quot;" horiz-adv-x="657" d="M266 1398L226 987H64V1536H266V1398ZM591 1398L552 987H390V1536H591V1398Z" />
-<glyph unicode="#" horiz-adv-x="1220" d="M667 410H474L402 0H219L291 410H64V582H321L371 866H139V1040H402L475 1456H657L584 1040H778L851 1456H1034L961 1040H1180V866H930L880 582H1104V410H850L778 0H595L667 410ZM504 582H697L747 866H553L504 582Z" />
-<glyph unicode="$" horiz-adv-x="1175" d="M790 383Q790 465 745 513T590 603T402 684T267 777T179 901T147 1070Q147 1239 255 1347T542 1473V1687H702V1470Q879 1445 979 1323T1079 1005H790Q790 1125 741 1184T608 1244Q526 1244 481 1198T436 1069Q436 993
-480 947T643 853T840 763T970 667T1051 545T1079 385Q1079 215 973 109T681 -16V-215H522V-17Q317 5 205 128T92 457H381Q381 338 437 275T600 211Q688 211 739 257T790 383Z" />
-<glyph unicode="%" horiz-adv-x="1512" d="M95 1176Q95 1310 182 1393T410 1477Q553 1477 640 1395T727 1171V1099Q727 964 640 882T412 800Q270 800 183 882T95 1105V1176ZM287 1099Q287 1039 321 1003T412 966T501 1003T534 1102V1176Q534 1236 501 1273T410
-1310Q355 1310 321 1274T287 1172V1099ZM791 357Q791 492 879 574T1107 657Q1249 657 1336 576T1424 351V279Q1424 145 1338 63T1109 -20Q965 -20 878 63T791 283V357ZM983 279Q983 224 1019 185T1109 146Q1231 146 1231 281V357Q1231 417 1197 453T1107 490T1017
-454T983 354V279ZM469 109L328 185L1039 1323L1180 1247L469 109Z" />
-<glyph unicode="&amp;" horiz-adv-x="1344" d="M71 392Q71 493 127 579T335 770Q270 857 233 933T196 1093Q196 1263 303 1369T593 1476Q756 1476 860 1379T965 1137Q965 963 789 830L677 749L928 457Q987 573 987 713H1233Q1233 429 1102 253L1320 0H992L917
-86Q756 -20 547 -20Q331 -20 201 93T71 392ZM561 212Q665 212 758 270L471 602L450 587Q361 511 361 408Q361 321 416 267T561 212ZM455 1097Q455 1022 543 908L620 959Q679 997 701 1033T724 1119T687 1206T592 1243Q530 1243 493 1203T455 1097Z" />
-<glyph unicode="&apos;" horiz-adv-x="331" d="M275 1389L246 985H63V1536H275V1389Z" />
-<glyph unicode="(" horiz-adv-x="719" d="M124 592Q124 821 185 1028T365 1394T623 1616L679 1460Q533 1352 451 1126T369 598V567Q369 264 450 37T679 -302L623 -455Q487 -394 370 -240T190 117T124 539V592Z" />
-<glyph unicode=")" horiz-adv-x="722" d="M609 569Q609 343 544 134T357 -235T96 -455L40 -302Q182 -195 264 28T349 541V594Q349 893 268 1121T40 1463L96 1616Q232 1557 352 1402T539 1041T609 614V569Z" />
-<glyph unicode="*" horiz-adv-x="928" d="M341 962L27 1051L86 1232L397 1107L377 1456H573L553 1100L856 1223L915 1040L595 951L805 685L646 572L464 864L284 582L125 690L341 962Z" />
-<glyph unicode="+" horiz-adv-x="1118" d="M694 815H1055V554H694V146H419V554H57V815H419V1206H694V815Z" />
-<glyph unicode="," horiz-adv-x="500" d="M186 -365L35 -286L71 -221Q138 -99 140 22V246H384L383 46Q382 -65 327 -178T186 -365Z" />
-<glyph unicode="-" horiz-adv-x="794" d="M673 507H110V740H673V507Z" />
-<glyph unicode="." horiz-adv-x="595" d="M126 142Q126 211 172 254T289 297Q360 297 406 254T453 142Q453 74 407 32T289 -11Q218 -11 172 31T126 142Z" />
-<glyph unicode="/" horiz-adv-x="765" d="M202 -125H-13L523 1456H738L202 -125Z" />
-<glyph unicode="0" horiz-adv-x="1175" d="M1079 602Q1079 300 954 140T588 -20Q350 -20 224 137T95 587V855Q95 1160 221 1318T586 1476T950 1320T1079 870V602ZM790 896Q790 1077 741 1159T586 1242Q484 1242 436 1164T384 918V564Q384 386 432 300T588 213Q694
-213 741 296T790 550V896Z" />
-<glyph unicode="1" horiz-adv-x="1175" d="M801 0H512V1114L167 1007V1242L770 1458H801V0Z" />
-<glyph unicode="2" horiz-adv-x="1175" d="M1097 0H99V198L570 700Q667 806 713 885T760 1035Q760 1132 711 1187T571 1243Q473 1243 417 1176T360 998H70Q70 1131 133 1241T313 1413T576 1476Q801 1476 925 1368T1050 1063Q1050 955 994 843T802 582L471 233H1097V0Z" />
-<glyph unicode="3" horiz-adv-x="1175" d="M393 856H547Q657 856 710 911T763 1057Q763 1145 711 1194T566 1243Q483 1243 427 1198T371 1079H82Q82 1193 143 1283T315 1425T559 1476Q790 1476 921 1366T1052 1061Q1052 961 991 877T831 748Q954 704 1014 616T1075
-408Q1075 214 934 97T559 -20Q341 -20 203 95T64 399H353Q353 317 414 265T566 213Q669 213 727 267T786 412Q786 630 546 630H393V856Z" />
-<glyph unicode="4" horiz-adv-x="1175" d="M954 548H1119V315H954V0H665V315H68L55 497L662 1456H954V548ZM343 548H665V1062L646 1029L343 548Z" />
-<glyph unicode="5" horiz-adv-x="1175" d="M142 716L226 1456H1042V1215H463L427 902Q530 957 646 957Q854 957 972 828T1090 467Q1090 326 1031 215T860 42T598 -20Q466 -20 353 33T175 184T105 405H391Q400 314 454 264T597 213Q695 213 748 283T801 483Q801
-607 740 673T567 739Q464 739 400 685L372 659L142 716Z" />
-<glyph unicode="6" horiz-adv-x="1175" d="M883 1471V1233H855Q659 1230 540 1131T396 856Q512 974 689 974Q879 974 991 838T1103 480Q1103 338 1042 223T868 44T613 -20Q383 -20 242 140T100 567V671Q100 908 189 1089T446 1370T835 1471H883ZM601 742Q531 742
-474 706T390 609V521Q390 376 447 295T607 213Q700 213 757 286T815 477Q815 596 757 669T601 742Z" />
-<glyph unicode="7" horiz-adv-x="1175" d="M1089 1294L526 0H221L785 1222H61V1456H1089V1294Z" />
-<glyph unicode="8" horiz-adv-x="1175" d="M1048 1069Q1048 963 995 881T849 750Q955 699 1017 610T1079 399Q1079 205 947 93T588 -20T228 93T95 399Q95 520 157 610T324 750Q231 799 179 881T126 1069Q126 1255 250 1365T587 1476Q799 1476 923 1367T1048 1069ZM789
-420Q789 515 734 572T586 629Q494 629 439 573T384 420Q384 327 438 270T588 213Q682 213 735 268T789 420ZM759 1055Q759 1140 714 1191T587 1243Q506 1243 461 1193T416 1055Q416 968 461 915T588 862T714 915T759 1055Z" />
-<glyph unicode="9" horiz-adv-x="1175" d="M775 582Q662 471 511 471Q318 471 202 603T86 961Q86 1104 148 1223T323 1409T575 1476Q719 1476 831 1404T1005 1197T1068 888V781Q1068 417 887 209T374 -13L303 -14V227L367 228Q744 245 775 582ZM582 692Q652 692
-702 728T779 815V934Q779 1081 723 1162T573 1243Q486 1243 430 1164T374 964Q374 845 428 769T582 692Z" />
-<glyph unicode=":" horiz-adv-x="578" d="M381 142Q381 211 427 254T544 297Q615 297 661 254T708 142Q708 74 662 32T544 -11Q473 -11 427 31T381 142ZM125 961Q125 1030 171 1073T288 1116Q359 1116 405 1073T452 961Q452 893 406 851T288 808Q217 808 171 850T125
-961Z" />
-<glyph unicode=";" horiz-adv-x="537" d="M108 961Q108 1030 154 1073T271 1116Q342 1116 388 1073T435 961Q435 893 389 851T271 808Q200 808 154 850T108 961ZM208 -365L57 -286L93 -221Q160 -99 162 22V246H406L405 46Q404 -65 349 -178T208 -365Z" />
-<glyph unicode="&lt;" horiz-adv-x="1042" d="M345 618L915 417V137L54 502V738L915 1103V823L345 618Z" />
-<glyph unicode="=" horiz-adv-x="1172" d="M1030 746H136V982H1030V746ZM1030 313H136V549H1030V313Z" />
-<glyph unicode="&gt;" horiz-adv-x="1058" d="M701 621L120 824V1102L991 737V502L120 136V415L701 621Z" />
-<glyph unicode="?" horiz-adv-x="1019" d="M347 447Q347 587 381 670T505 833T626 964T656 1071Q656 1240 500 1240Q426 1240 382 1195T335 1069H45Q47 1260 168 1368T500 1476Q712 1476 829 1374T946 1084Q946 999 908 924T775 756L694 679Q618 606 607 508L603
-447H347ZM318 140Q318 207 363 250T480 294T596 251T642 140Q642 74 598 31T480 -12T363 31T318 140Z" />
-<glyph unicode="@" horiz-adv-x="1833" d="M1749 536Q1738 280 1623 130T1312 -21Q1226 -21 1164 16T1069 122Q969 -18 808 -18Q662 -18 582 105T522 430Q540 595 605 723T771 921T987 990Q1130 990 1231 924L1294 881L1243 303Q1233 224 1260 182T1348 140Q1440
-140 1502 247T1570 529Q1587 878 1430 1065T963 1253Q770 1253 619 1155T381 877T283 463Q267 109 425 -84T898 -278Q981 -278 1072 -260T1229 -210L1267 -364Q1206 -404 1103 -428T894 -453Q630 -453 444 -347T167 -33T87 463Q99 739 213 958T523 1296T967 1416Q1218
-1416 1399 1309T1670 1001T1749 536ZM744 430Q733 298 767 230T877 161Q926 161 970 204T1043 328L1085 801Q1046 814 1005 814Q890 814 827 716T744 430Z" />
-<glyph unicode="A" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543Z" />
-<glyph unicode="B" horiz-adv-x="1307" d="M130 0V1456H640Q905 1456 1042 1355T1179 1057Q1179 950 1124 869T971 749Q1083 721 1147 636T1212 428Q1212 218 1078 110T696 0H130ZM430 634V241H687Q793 241 852 291T912 431Q912 631 705 634H430ZM430 846H652Q879
-850 879 1027Q879 1126 822 1169T640 1213H430V846Z" />
-<glyph unicode="C" horiz-adv-x="1340" d="M1273 485Q1256 250 1100 115T687 -20Q407 -20 247 168T86 686V775Q86 985 160 1145T371 1390T691 1476Q943 1476 1097 1341T1275 962H975Q964 1103 897 1166T691 1230Q541 1230 467 1123T390 789V679Q390 443 461 334T687
-225Q826 225 894 288T973 485H1273Z" />
-<glyph unicode="D" horiz-adv-x="1331" d="M130 0V1456H578Q770 1456 921 1370T1158 1124T1243 761V694Q1243 491 1160 333T924 88T581 0H130ZM430 1213V241H575Q751 241 844 356T939 685V762Q939 984 847 1098T578 1213H430Z" />
-<glyph unicode="E" horiz-adv-x="1152" d="M1006 631H430V241H1106V0H130V1456H1104V1213H430V866H1006V631Z" />
-<glyph unicode="F" horiz-adv-x="1122" d="M1006 595H430V0H130V1456H1078V1213H430V837H1006V595Z" />
-<glyph unicode="G" horiz-adv-x="1395" d="M1282 184Q1201 87 1053 34T725 -20Q536 -20 394 62T174 302T94 671V770Q94 988 167 1147T379 1391T704 1476Q963 1476 1109 1353T1282 993H990Q970 1118 902 1176T713 1234Q560 1234 480 1119T399 777V684Q399 455 486
-338T741 221Q910 221 982 293V544H709V765H1282V184Z" />
-<glyph unicode="H" horiz-adv-x="1447" d="M1315 0H1015V624H430V0H130V1456H430V866H1015V1456H1315V0Z" />
-<glyph unicode="I" horiz-adv-x="597" d="M449 0H149V1456H449V0Z" />
-<glyph unicode="J" horiz-adv-x="1144" d="M717 1456H1017V448Q1017 309 956 203T782 38T529 -20Q298 -20 169 97T40 430H342Q342 323 387 272T529 221Q615 221 666 280T717 448V1456Z" />
-<glyph unicode="K" horiz-adv-x="1300" d="M586 584L430 416V0H130V1456H430V796L562 977L933 1456H1302L785 809L1317 0H960L586 584Z" />
-<glyph unicode="L" horiz-adv-x="1109" d="M430 241H1067V0H130V1456H430V241Z" />
-<glyph unicode="M" horiz-adv-x="1794" d="M522 1456L896 400L1268 1456H1662V0H1361V398L1391 1085L998 0H792L400 1084L430 398V0H130V1456H522Z" />
-<glyph unicode="N" horiz-adv-x="1446" d="M1314 0H1014L430 958V0H130V1456H430L1015 496V1456H1314V0Z" />
-<glyph unicode="O" horiz-adv-x="1414" d="M1326 695Q1326 480 1250 318T1033 68T708 -20Q527 -20 385 67T165 315T86 687V759Q86 974 163 1137T382 1388T706 1476T1029 1389T1248 1138T1326 760V695ZM1022 761Q1022 990 940 1109T706 1228Q555 1228 473 1111T390
-766V695Q390 472 472 349T708 226Q859 226 940 344T1022 690V761Z" />
-<glyph unicode="P" horiz-adv-x="1321" d="M430 513V0H130V1456H698Q862 1456 986 1396T1178 1226T1245 974Q1245 760 1099 637T693 513H430ZM430 756H698Q817 756 879 812T942 972Q942 1079 879 1145T705 1213H430V756Z" />
-<glyph unicode="Q" horiz-adv-x="1414" d="M1324 695Q1324 491 1258 341T1075 99L1317 -91L1126 -260L816 -11Q763 -20 706 -20Q525 -20 383 67T163 315T84 687V759Q84 974 161 1137T380 1388T704 1476T1027 1389T1246 1138T1324 760V695ZM1020 761Q1020 990 938
-1109T704 1228Q553 1228 471 1111T388 766V695Q388 472 470 349T706 226Q857 226 938 344T1020 690V761Z" />
-<glyph unicode="R" horiz-adv-x="1307" d="M669 533H430V0H130V1456H671Q929 1456 1069 1341T1209 1016Q1209 867 1145 768T949 609L1264 14V0H942L669 533ZM430 776H672Q785 776 847 833T909 992Q909 1095 851 1154T671 1213H430V776Z" />
-<glyph unicode="S" horiz-adv-x="1259" d="M885 382Q885 467 825 512T609 608T362 708Q114 842 114 1069Q114 1187 180 1279T371 1424T651 1476Q807 1476 929 1420T1118 1260T1186 1026H886Q886 1126 823 1181T646 1237Q536 1237 475 1191T414 1068Q414 997 485
-949T696 859Q952 782 1069 668T1186 384Q1186 195 1043 88T658 -20Q490 -20 352 41T142 210T69 458H370Q370 217 658 217Q765 217 825 260T885 382Z" />
-<glyph unicode="T" horiz-adv-x="1267" d="M1226 1213H780V0H480V1213H40V1456H1226V1213Z" />
-<glyph unicode="U" horiz-adv-x="1348" d="M1232 1456V497Q1232 258 1083 119T674 -20Q419 -20 269 115T116 486V1456H416V495Q416 352 484 287T674 221Q927 221 931 487V1456H1232Z" />
-<glyph unicode="V" horiz-adv-x="1339" d="M668 361L998 1456H1332L825 0H512L7 1456H340L668 361Z" />
-<glyph unicode="W" horiz-adv-x="1791" d="M1264 420L1460 1456H1759L1436 0H1134L897 974L660 0H358L35 1456H334L531 422L771 1456H1025L1264 420Z" />
-<glyph unicode="X" horiz-adv-x="1301" d="M651 954L924 1456H1269L845 734L1280 0H931L651 510L371 0H22L457 734L33 1456H378L651 954Z" />
-<glyph unicode="Y" horiz-adv-x="1266" d="M632 800L935 1456H1263L785 528V0H480V528L2 1456H331L632 800Z" />
-<glyph unicode="Z" horiz-adv-x="1241" d="M448 241H1182V0H73V176L793 1213H74V1456H1166V1284L448 241Z" />
-<glyph unicode="[" horiz-adv-x="569" d="M552 1471H410V-116H552V-339H120V1694H552V1471Z" />
-<glyph unicode="\" horiz-adv-x="864" d="M0 1456H295L903 -125H607L0 1456Z" />
-<glyph unicode="]" horiz-adv-x="569" d="M13 1694H445V-339H13V-116H156V1471H13V1694Z" />
-<glyph unicode="^" horiz-adv-x="895" d="M448 1186L274 729H44L343 1456H553L852 729H623L448 1186Z" />
-<glyph unicode="_" horiz-adv-x="914" d="M912 -226H1V0H912V-226Z" />
-<glyph unicode="`" horiz-adv-x="677" d="M565 1226H328L52 1536H367L565 1226Z" />
-<glyph unicode="a" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987 719V250Q988
-96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201Z" />
-<glyph unicode="b" horiz-adv-x="1153" d="M1086 531Q1086 271 975 126T665 -20Q489 -20 384 115L371 0H111V1536H400V985Q500 1102 663 1102Q861 1102 973 957T1086 547V531ZM797 552Q797 716 745 791T590 867Q452 867 400 754V327Q453 213 592 213Q732 213 776
-351Q797 417 797 552Z" />
-<glyph unicode="c" horiz-adv-x="1068" d="M561 213Q641 213 691 257T743 374H1014Q1013 264 954 173T793 31T566 -20Q334 -20 200 127T66 535V554Q66 804 199 953T564 1102Q767 1102 889 987T1014 679H743Q741 763 691 815T559 868Q458 868 407 795T355 556V526Q355
-359 406 286T561 213Z" />
-<glyph unicode="d" horiz-adv-x="1154" d="M66 549Q66 802 179 952T490 1102Q648 1102 751 984V1536H1041V0H780L766 115Q658 -20 488 -20Q297 -20 182 130T66 549ZM355 528Q355 376 408 295T562 214Q696 214 751 327V754Q697 867 564 867Q355 867 355 528Z" />
-<glyph unicode="e" horiz-adv-x="1107" d="M609 -20Q371 -20 222 126T72 515V543Q72 706 135 834T313 1032T577 1102Q799 1102 926 962T1054 565V447H365Q379 341 449 277T628 213Q795 213 889 334L1031 175Q966 83 855 32T609 -20ZM576 868Q490 868 437 810T368
-644H770V667Q768 763 718 815T576 868Z" />
-<glyph unicode="f" horiz-adv-x="734" d="M190 0V870H29V1082H190V1174Q190 1356 294 1456T587 1557Q647 1557 734 1537L731 1313Q695 1322 643 1322Q480 1322 480 1169V1082H695V870H480V0H190Z" />
-<glyph unicode="g" horiz-adv-x="1169" d="M69 549Q69 798 187 950T507 1102Q685 1102 784 980L796 1082H1058V36Q1058 -106 994 -211T812 -371T538 -426Q419 -426 306 -379T135 -256L263 -80Q371 -201 525 -201Q640 -201 704 -140T768 35V93Q668 -20 505 -20Q310
--20 190 132T69 537V549ZM358 528Q358 381 417 298T579 214Q711 214 768 313V768Q710 867 581 867Q477 867 418 782T358 528Z" />
-<glyph unicode="h" horiz-adv-x="1146" d="M393 964Q508 1102 682 1102Q1034 1102 1039 693V0H750V685Q750 778 710 822T577 867Q450 867 393 769V0H104V1536H393V964Z" />
-<glyph unicode="i" horiz-adv-x="543" d="M416 0H126V1082H416V0ZM109 1362Q109 1427 152 1469T271 1511Q345 1511 389 1469T433 1362Q433 1296 389 1254T271 1212T154 1254T109 1362Z" />
-<glyph unicode="j" horiz-adv-x="532" d="M417 1082V-59Q417 -238 322 -337T48 -437Q-27 -437 -95 -420V-191Q-43 -200 -4 -200Q127 -200 127 -61V1082H417ZM104 1362Q104 1427 147 1469T266 1511T384 1469T428 1362Q428 1296 384 1254T266 1212T149 1254T104 1362Z" />
-<glyph unicode="k" horiz-adv-x="1094" d="M504 434L400 330V0H111V1536H400V685L456 757L733 1082H1080L689 631L1114 0H782L504 434Z" />
-<glyph unicode="l" horiz-adv-x="543" d="M416 0H126V1536H416V0Z" />
-<glyph unicode="m" horiz-adv-x="1773" d="M382 1082L391 961Q506 1102 702 1102Q911 1102 989 937Q1103 1102 1314 1102Q1490 1102 1576 1000T1662 691V0H1372V690Q1372 782 1336 824T1209 867Q1079 867 1029 743L1030 0H741V689Q741 783 704 825T578 867Q455
-867 400 765V0H111V1082H382Z" />
-<glyph unicode="n" horiz-adv-x="1147" d="M377 1082L386 957Q502 1102 697 1102Q869 1102 953 1001T1039 699V0H750V692Q750 784 710 825T577 867Q455 867 394 763V0H105V1082H377Z" />
-<glyph unicode="o" horiz-adv-x="1158" d="M66 551Q66 712 128 838T306 1033T577 1102Q796 1102 934 968T1089 604L1091 530Q1091 281 952 131T579 -20T206 130T66 538V551ZM355 530Q355 376 413 295T579 213Q684 213 743 293T802 551Q802 702 743 785T577 868Q471
-868 413 786T355 530Z" />
-<glyph unicode="p" horiz-adv-x="1153" d="M1085 531Q1085 281 972 131T665 -20Q501 -20 400 94V-416H111V1082H379L389 976Q494 1102 663 1102Q863 1102 974 954T1085 546V531ZM796 552Q796 703 743 785T587 867Q451 867 400 763V320Q453 213 589 213Q796 213 796 552Z" />
-<glyph unicode="q" horiz-adv-x="1157" d="M66 551Q66 806 179 954T491 1102Q665 1102 768 969L787 1082H1041V-416H751V93Q651 -20 489 -20Q296 -20 181 130T66 551ZM355 530Q355 375 409 294T563 213Q696 213 751 319V766Q697 868 565 868Q465 868 410 787T355 530Z" />
-<glyph unicode="r" horiz-adv-x="747" d="M719 811Q660 819 615 819Q451 819 400 708V0H111V1082H384L392 953Q479 1102 633 1102Q681 1102 723 1089L719 811Z" />
-<glyph unicode="s" horiz-adv-x="1053" d="M697 299Q697 352 645 382T476 437Q90 518 90 765Q90 909 209 1005T522 1102Q728 1102 851 1005T975 753H686Q686 815 646 855T521 896Q448 896 408 863T368 779Q368 731 413 702T567 651T749 602Q978 518 978 311Q978
-163 851 72T523 -20Q387 -20 282 28T116 161T56 344H330Q334 267 387 226T529 185Q612 185 654 216T697 299Z" />
-<glyph unicode="t" horiz-adv-x="692" d="M457 1348V1082H642V870H457V330Q457 270 480 244T568 218Q616 218 653 225V6Q568 -20 478 -20Q174 -20 168 287V870H10V1082H168V1348H457Z" />
-<glyph unicode="u" horiz-adv-x="1146" d="M759 110Q652 -20 463 -20Q289 -20 198 80T104 373V1082H393V383Q393 214 547 214Q694 214 749 316V1082H1039V0H767L759 110Z" />
-<glyph unicode="v" horiz-adv-x="1035" d="M516 353L717 1082H1019L654 0H378L13 1082H315L516 353Z" />
-<glyph unicode="w" horiz-adv-x="1505" d="M1052 393L1194 1082H1473L1197 0H955L750 681L545 0H304L28 1082H307L448 394L646 1082H855L1052 393Z" />
-<glyph unicode="x" horiz-adv-x="1042" d="M523 759L705 1082H1014L706 552L1027 0H717L524 340L332 0H21L342 552L35 1082H345L523 759Z" />
-<glyph unicode="y" horiz-adv-x="1028" d="M515 409L715 1082H1025L590 -168L566 -225Q469 -437 246 -437Q183 -437 118 -418V-199L162 -200Q244 -200 284 -175T348 -92L382 -3L3 1082H314L515 409Z" />
-<glyph unicode="z" horiz-adv-x="1042" d="M443 233H972V0H74V176L583 848H89V1082H956V911L443 233Z" />
-<glyph unicode="{" horiz-adv-x="676" d="M586 -360Q226 -259 226 105V304Q226 515 48 515V722Q222 722 226 921V1133Q226 1318 316 1432T586 1597L642 1436Q566 1408 527 1339T486 1146V936Q486 710 307 619Q486 527 486 300V88Q491 -146 642 -198L586 -360Z" />
-<glyph unicode="|" horiz-adv-x="518" d="M348 -270H173V1456H348V-270Z" />
-<glyph unicode="}" horiz-adv-x="676" d="M34 -198Q186 -144 190 92V304Q190 530 373 618Q190 706 190 937V1146Q186 1379 34 1436L90 1597Q269 1547 359 1434T450 1136V921Q454 722 628 722V515Q450 515 450 306V89Q442 -261 90 -360L34 -198Z" />
-<glyph unicode="~" horiz-adv-x="1328" d="M1221 793Q1221 607 1128 491T888 375Q814 375 751 403T604 511T451 591Q393 591 357 541T321 413L106 415Q106 601 196 714T437 827Q515 827 579 797T724 690T873 612Q932 612 969 665T1007 794L1221 793Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="510" />
-<glyph unicode="&#xa1;" horiz-adv-x="578" d="M170 639H411L444 -369H137L170 639ZM452 948Q452 881 406 838T290 795T174 838T128 948T172 1058T290 1101T407 1058T452 948Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1178" d="M594 213Q674 213 724 257T776 374H1048Q1046 229 950 124T698 -11V-245H498V-12Q311 18 205 162T99 532V554Q99 772 204 917T498 1094V1318H698V1093Q861 1064 953 953T1048 679H776Q774 765 724 816T593 868Q491
-868 440 794T388 559V526Q388 358 439 286T594 213Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1217" d="M564 576L570 437Q570 314 508 241H1161V0H102V241H194Q266 259 266 420L261 576H99V812H253L246 1039Q246 1241 369 1358T700 1475Q912 1475 1033 1363T1154 1058H867Q867 1143 824 1188T699 1233Q633 1233 590
-1184T546 1039L555 812H864V576H564Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1418" d="M1073 107Q914 -20 712 -20Q509 -20 351 106L222 -26L81 118L216 255Q116 411 116 608Q116 812 225 973L81 1120L222 1264L364 1119Q519 1234 712 1234Q906 1234 1061 1117L1205 1265L1347 1120L1199 969Q1306 810
-1306 608Q1306 415 1208 259L1347 118L1205 -27L1073 107ZM302 608Q302 490 356 389T505 229T712 170Q822 170 917 228T1067 388T1121 608Q1121 727 1067 827T918 986T712 1044Q600 1044 505 986T356 828T302 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1098" d="M550 892L774 1456H1087L765 742H983V567H695V452H983V278H695V0H395V278H89V452H395V567H89V742H333L10 1456H325L550 892Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="516" d="M128 -270V525H388V-270H128ZM388 698H128V1456H388V698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1287" d="M1180 481Q1180 299 1018 210Q1153 108 1153 -78Q1153 -253 1016 -352T636 -452Q379 -452 236 -345T92 -35L381 -34Q381 -123 445 -170T636 -218Q748 -218 806 -181T864 -80Q864 -15 800 26T553 117T278 223T140
-353T94 534Q94 714 256 807Q120 910 120 1095Q120 1266 260 1371T640 1476Q887 1476 1023 1363T1159 1049H870Q870 1136 809 1189T640 1243Q530 1243 470 1204T410 1097Q410 1024 465 987T706 901T988 797T1133 666T1180 481ZM458 704Q383 662 383 563Q383 494
-424 457T590 379L812 312Q894 359 894 452Q894 514 849 553T685 633L458 704Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="956" d="M371 1365Q371 1312 332 1276T232 1239Q170 1239 132 1276T94 1365T132 1454T232 1492T332 1455T371 1365ZM581 1365Q581 1419 621 1455T720 1492Q779 1492 818 1455T858 1365Q858 1313 820 1276T720 1238T620 1275T581
-1365Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1606" d="M1117 596Q1117 444 1030 363T782 282T528 388T433 675V788Q433 962 528 1068T782 1175Q945 1175 1031 1093T1118 861H962Q962 957 916 998T782 1040Q690 1040 640 973T588 792V669Q588 552 639 485T782 417Q871
-417 916 457T961 596H1117ZM1383 729Q1383 895 1308 1037T1096 1265T796 1351Q637 1351 501 1269T286 1043T208 729T285 415T499 188T796 104T1093 189T1307 418T1383 729ZM86 729Q86 931 179 1104T438 1376T796 1476T1153 1377T1412 1104T1506 729Q1506 525 1411
-352T1152 79T796 -20Q603 -20 439 80T180 353T86 729Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="909" d="M604 705Q594 732 587 773Q510 691 386 691Q268 691 203 752T137 919Q137 1029 221 1089T478 1150H580V1201Q580 1328 464 1328Q399 1328 363 1303T326 1229L153 1243Q153 1347 240 1411T464 1476Q599 1476 677 1404T755
-1199V883Q755 786 781 705H604ZM429 835Q469 835 511 853T580 897V1033H474Q398 1032 355 1002T312 923Q312 835 429 835Z" />
-<glyph unicode="&#xab;" horiz-adv-x="1023" d="M559 524L799 125H613L333 515V534L613 924H799L559 524ZM688 524L928 125H742L462 515V534L742 924H928L688 524Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1129" d="M961 374H761V634H126V805H961V374Z" />
-<glyph unicode="&#xad;" horiz-adv-x="794" d="M673 507H110V740H673V507Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1606" d="M86 729Q86 931 179 1104T438 1376T796 1476T1153 1377T1412 1104T1506 729Q1506 525 1411 352T1152 79T796 -20Q603 -20 439 80T180 353T86 729ZM1383 729Q1383 895 1308 1037T1096 1265T796 1351Q637 1351 501
-1269T286 1043T208 729T285 415T499 188T796 104T1093 189T1307 418T1383 729ZM652 653V316H501V1166H782Q933 1166 1020 1098T1107 903Q1107 791 994 729Q1055 698 1079 643T1104 505T1107 389T1121 332V316H966Q953 350 953 510Q953 586 920 619T810 653H652ZM652
-787H788Q862 787 909 819T957 903Q957 973 922 1002T793 1033H652V787Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="1026" d="M858 1287H168V1454H858V1287Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="795" d="M126 1200Q126 1314 207 1395T398 1476Q507 1476 586 1396T666 1200T587 1007T398 928Q290 928 208 1006T126 1200ZM398 1076Q451 1076 485 1111T520 1200Q520 1252 486 1290T398 1328T309 1290T273 1200T309 1112T398
-1076Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1100" d="M677 942H1005V701H677V337H424V701H89V942H424V1285H677V942ZM977 1H113V236H977V1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="763" d="M693 667H73V805L360 1062Q416 1111 440 1153T465 1218Q465 1302 370 1302Q320 1302 291 1271T261 1193H55Q55 1309 140 1388T361 1467Q509 1467 589 1403T670 1219Q670 1149 634 1091T490 946L342 831H693V667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="763" d="M273 1137H355Q474 1137 474 1225Q474 1260 446 1281T368 1302Q326 1302 297 1287T267 1242H62Q62 1344 146 1405T362 1467Q507 1467 592 1408T678 1241Q678 1122 543 1072Q693 1031 693 888Q693 783 602 720T362
-656Q220 656 134 722T48 903H254Q254 869 288 845T374 820Q434 820 460 846T487 908Q487 1000 365 1001H273V1137Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="679" d="M298 1536H613L336 1226H101L298 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1261" d="M428 1082V459Q428 333 468 274T608 214Q757 214 813 319V1082H1102V0H833L827 68Q738 -21 602 -21Q500 -21 428 24V-416H139V1082H428Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="1003" d="M650 0V520H570Q340 520 208 647T75 988Q75 1201 208 1328T571 1456H869V0H650Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="617" d="M140 697Q140 766 186 809T303 852T420 809T467 697T420 586T303 543Q231 543 186 586T140 697Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="548" d="M345 7L334 -51Q484 -78 484 -224Q484 -334 393 -398T135 -462L128 -295Q240 -295 240 -214Q240 -172 207 -157T98 -136L129 7H345Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="763" d="M528 667H324V1215L135 1174V1332L509 1453H528V667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="936" d="M118 1121Q118 1281 213 1378T464 1476T715 1379T811 1116V1044Q811 885 717 788T466 690Q308 690 213 788T118 1049V1121ZM293 1044Q293 946 339 891T466 836Q544 836 589 890T636 1041V1121Q636 1218 590 1273T464
-1328Q386 1328 340 1274T293 1117V1044Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="1023" d="M272 923L552 533V514L272 124H85L325 523L85 923H272ZM665 923L945 533V514L665 124H478L718 523L478 923H665Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1470" d="M494 664H290V1212L101 1171V1329L475 1450H494V664ZM458 117L317 193L1028 1331L1169 1255L458 117ZM1302 326H1390V159H1302V0H1097V159H751L739 294L1096 789H1302V326ZM935 326H1097V538L1083 516L935 326Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1559" d="M416 117L275 193L986 1331L1127 1255L416 117ZM477 670H273V1218L84 1177V1335L458 1456H477V670ZM1477 0H857V138L1144 395Q1200 444 1224 486T1249 551Q1249 635 1154 635Q1104 635 1075 604T1045 526H839Q839
-642 924 721T1145 800Q1293 800 1373 736T1454 552Q1454 482 1418 424T1274 279L1126 164H1477V0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1655" d="M619 117L478 193L1189 1331L1330 1255L619 117ZM1460 326H1548V159H1460V0H1255V159H909L897 294L1254 789H1460V326ZM1093 326H1255V538L1241 516L1093 326ZM319 1137H401Q520 1137 520 1225Q520 1260 492 1281T414
-1302Q372 1302 343 1287T313 1242H108Q108 1344 192 1405T408 1467Q553 1467 638 1408T724 1241Q724 1122 589 1072Q739 1031 739 888Q739 783 648 720T408 656Q266 656 180 722T94 903H300Q300 869 334 845T420 820Q480 820 506 846T533 908Q533 1000 411 1001H319V1137Z"
-/>
-<glyph unicode="&#xbf;" horiz-adv-x="1019" d="M666 643Q666 510 635 428T525 272T417 162T374 89T359 8Q359 -149 513 -149Q590 -149 635 -104T683 22H972Q970 -170 849 -277T518 -385Q305 -385 187 -284T69 6Q69 165 222 318L319 411Q369 456 388 505T410 643H666ZM702
-949Q702 882 656 839T540 796T424 839T378 949T422 1059T540 1102T657 1059T702 949Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543ZM836 1536H599L323 1846H638L836 1536Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543ZM750 1846H1065L788 1536H553L750 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543ZM1076 1566V1554H846L692 1699L538 1554H312V1570L608 1846H776L1076 1566Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543ZM1068 1832Q1068 1719 1002 1643T841 1566Q803 1566 774 1574T692 1611T617 1645T567 1652Q532 1652 508 1627T483 1556L315
-1566Q315 1677 380 1755T541 1833Q571 1833 597 1826T684 1789T767 1754T815 1748Q850 1748 875 1772T901 1843L1068 1832Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543ZM587 1675Q587 1622 548 1586T448 1549Q386 1549 348 1586T310 1675T348 1764T448 1802T548 1765T587 1675ZM797 1675Q797
-1729 837 1765T936 1802Q995 1802 1034 1765T1074 1675Q1074 1623 1036 1586T936 1548T836 1585T797 1675Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1378" d="M952 300H426L326 0H7L549 1456H827L1372 0H1053L952 300ZM507 543H871L688 1088L507 543ZM470 1730Q470 1816 535 1875T693 1935Q785 1935 850 1877T916 1730Q916 1645 852 1587T693 1529Q596 1529 533 1588T470
-1730ZM585 1730Q585 1686 614 1655T693 1623T772 1654T801 1730Q801 1776 772 1807T693 1839T615 1808T585 1730Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1925" d="M1865 0H968L954 333H508L341 0H2L788 1456H1804V1220H1206L1221 865H1723V629H1231L1247 235H1865V0ZM633 580H944L920 1150L633 580Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1340" d="M1273 485Q1256 250 1100 115T687 -20Q407 -20 247 168T86 686V775Q86 985 160 1145T371 1390T691 1476Q943 1476 1097 1341T1275 962H975Q964 1103 897 1166T691 1230Q541 1230 467 1123T390 789V679Q390 443 461
-334T687 225Q826 225 894 288T973 485H1273ZM797 6L786 -52Q936 -79 936 -225Q936 -335 845 -399T587 -463L580 -296Q692 -296 692 -215Q692 -173 659 -158T550 -137L581 6H797Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1152" d="M1006 631H430V241H1106V0H130V1456H1104V1213H430V866H1006V631ZM779 1539H542L266 1849H581L779 1539Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1152" d="M1006 631H430V241H1106V0H130V1456H1104V1213H430V866H1006V631ZM693 1849H1008L731 1539H496L693 1849Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1152" d="M1006 631H430V241H1106V0H130V1456H1104V1213H430V866H1006V631ZM1019 1569V1557H789L635 1702L481 1557H255V1573L551 1849H719L1019 1569Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1152" d="M1006 631H430V241H1106V0H130V1456H1104V1213H430V866H1006V631ZM530 1678Q530 1625 491 1589T391 1552Q329 1552 291 1589T253 1678T291 1767T391 1805T491 1768T530 1678ZM740 1678Q740 1732 780 1768T879 1805Q938
-1805 977 1768T1017 1678Q1017 1626 979 1589T879 1551T779 1588T740 1678Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="597" d="M449 0H149V1456H449V0ZM443 1539H206L-70 1849H245L443 1539Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="597" d="M449 0H149V1456H449V0ZM356 1849H671L394 1539H159L356 1849Z" />
-<glyph unicode="&#xce;" horiz-adv-x="597" d="M449 0H149V1456H449V0ZM683 1569V1557H453L299 1702L145 1557H-81V1573L215 1849H383L683 1569Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="597" d="M449 0H149V1456H449V0ZM194 1678Q194 1625 155 1589T55 1552Q-7 1552 -45 1589T-83 1678T-45 1767T55 1805T155 1768T194 1678ZM404 1678Q404 1732 444 1768T543 1805Q602 1805 641 1768T681 1678Q681 1626 643
-1589T543 1551T443 1588T404 1678Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1361" d="M160 0V642H-20V825H160V1456H608Q800 1456 951 1370T1188 1124T1273 761V694Q1273 491 1190 333T954 88T611 0H160ZM679 642H460V241H605Q783 241 876 358T969 694V762Q969 984 877 1098T608 1213H460V825H679V642Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1446" d="M1314 0H1014L430 958V0H130V1456H430L1015 496V1456H1314V0ZM1102 1832Q1102 1719 1036 1643T875 1566Q837 1566 808 1574T726 1611T651 1645T601 1652Q566 1652 542 1627T517 1556L349 1566Q349 1677 414 1755T575
-1833Q605 1833 631 1826T718 1789T801 1754T849 1748Q884 1748 909 1772T935 1843L1102 1832Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1414" d="M1326 695Q1326 480 1250 318T1033 68T708 -20Q527 -20 385 67T165 315T86 687V759Q86 974 163 1137T382 1388T706 1476T1029 1389T1248 1138T1326 760V695ZM1022 761Q1022 990 940 1109T706 1228Q555 1228 473
-1111T390 766V695Q390 472 472 349T708 226Q859 226 940 344T1022 690V761ZM850 1536H613L337 1846H652L850 1536Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1414" d="M1326 695Q1326 480 1250 318T1033 68T708 -20Q527 -20 385 67T165 315T86 687V759Q86 974 163 1137T382 1388T706 1476T1029 1389T1248 1138T1326 760V695ZM1022 761Q1022 990 940 1109T706 1228Q555 1228 473
-1111T390 766V695Q390 472 472 349T708 226Q859 226 940 344T1022 690V761ZM764 1846H1079L802 1536H567L764 1846Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1414" d="M1326 695Q1326 480 1250 318T1033 68T708 -20Q527 -20 385 67T165 315T86 687V759Q86 974 163 1137T382 1388T706 1476T1029 1389T1248 1138T1326 760V695ZM1022 761Q1022 990 940 1109T706 1228Q555 1228 473
-1111T390 766V695Q390 472 472 349T708 226Q859 226 940 344T1022 690V761ZM1090 1566V1554H860L706 1699L552 1554H326V1570L622 1846H790L1090 1566Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1414" d="M1326 695Q1326 480 1250 318T1033 68T708 -20Q527 -20 385 67T165 315T86 687V759Q86 974 163 1137T382 1388T706 1476T1029 1389T1248 1138T1326 760V695ZM1022 761Q1022 990 940 1109T706 1228Q555 1228 473
-1111T390 766V695Q390 472 472 349T708 226Q859 226 940 344T1022 690V761ZM1082 1832Q1082 1719 1016 1643T855 1566Q817 1566 788 1574T706 1611T631 1645T581 1652Q546 1652 522 1627T497 1556L329 1566Q329 1677 394 1755T555 1833Q585 1833 611 1826T698 1789T781
-1754T829 1748Q864 1748 889 1772T915 1843L1082 1832Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1414" d="M1326 695Q1326 480 1250 318T1033 68T708 -20Q527 -20 385 67T165 315T86 687V759Q86 974 163 1137T382 1388T706 1476T1029 1389T1248 1138T1326 760V695ZM1022 761Q1022 990 940 1109T706 1228Q555 1228 473
-1111T390 766V695Q390 472 472 349T708 226Q859 226 940 344T1022 690V761ZM601 1675Q601 1622 562 1586T462 1549Q400 1549 362 1586T324 1675T362 1764T462 1802T562 1765T601 1675ZM811 1675Q811 1729 851 1765T950 1802Q1009 1802 1048 1765T1088 1675Q1088
-1623 1050 1586T950 1548T850 1585T811 1675Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1088" d="M65 373L372 686L65 999L235 1167L539 856L844 1167L1014 999L707 686L1014 373L844 205L539 515L235 205L65 373Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1411" d="M1333 695Q1333 480 1257 318T1040 68T715 -20Q551 -20 420 50L335 -95H147L290 147Q93 342 93 702V759Q93 974 170 1137T389 1388T713 1476Q888 1476 1027 1394L1101 1518H1288L1154 1291Q1333 1093 1333 754V695ZM397
-695Q397 523 446 410L893 1167Q820 1228 713 1228Q562 1228 480 1111T397 766V695ZM1030 761Q1030 912 992 1017L552 273Q622 226 715 226Q866 226 947 344T1030 690V761Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1348" d="M1232 1456V497Q1232 258 1083 119T674 -20Q419 -20 269 115T116 486V1456H416V495Q416 352 484 287T674 221Q927 221 931 487V1456H1232ZM814 1536H577L301 1846H616L814 1536Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1348" d="M1232 1456V497Q1232 258 1083 119T674 -20Q419 -20 269 115T116 486V1456H416V495Q416 352 484 287T674 221Q927 221 931 487V1456H1232ZM728 1846H1043L766 1536H531L728 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1348" d="M1232 1456V497Q1232 258 1083 119T674 -20Q419 -20 269 115T116 486V1456H416V495Q416 352 484 287T674 221Q927 221 931 487V1456H1232ZM1054 1566V1554H824L670 1699L516 1554H290V1570L586 1846H754L1054 1566Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1348" d="M1232 1456V497Q1232 258 1083 119T674 -20Q419 -20 269 115T116 486V1456H416V495Q416 352 484 287T674 221Q927 221 931 487V1456H1232ZM565 1675Q565 1622 526 1586T426 1549Q364 1549 326 1586T288 1675T326
-1764T426 1802T526 1765T565 1675ZM775 1675Q775 1729 815 1765T914 1802Q973 1802 1012 1765T1052 1675Q1052 1623 1014 1586T914 1548T814 1585T775 1675Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1266" d="M632 800L935 1456H1263L785 528V0H480V528L2 1456H331L632 800ZM693 1846H1008L731 1536H496L693 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1246" d="M422 1456V1189H652Q814 1188 933 1133T1117 975T1181 738Q1181 536 1043 414T664 287H422V0H133V1456H422ZM422 956V520H645Q762 520 827 579T892 736T829 894T653 956H422Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1292" d="M424 0H135V1101Q135 1321 259 1440T609 1559Q800 1559 915 1460T1031 1189Q1031 1081 978 994T924 830Q924 793 954 754T1073 636Q1224 502 1224 354Q1224 177 1109 79T779 -20Q698 -20 619 -4T500 36L554 265Q652
-213 773 213Q852 213 894 249T936 349Q936 395 902 438T785 548Q635 668 635 818Q635 914 690 1004T745 1174Q745 1244 701 1285T588 1327Q429 1327 424 1114V0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987
-719V250Q988 96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201ZM695 1226H458L182 1536H497L695 1226Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987
-719V250Q988 96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201ZM609 1536H924L647 1226H412L609 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987
-719V250Q988 96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201ZM935 1256V1244H705L551 1389L397 1244H171V1260L467 1536H635L935 1256Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987
-719V250Q988 96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201ZM927 1779Q927 1666 861 1590T700 1513Q662 1513 633 1521T551 1558T476 1592T426 1599Q391 1599 367 1574T342 1503L174 1513Q174 1624
-239 1702T400 1780Q430 1780 456 1773T543 1736T626 1701T674 1695Q709 1695 734 1719T760 1790L927 1779Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987
-719V250Q988 96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201ZM446 1365Q446 1312 407 1276T307 1239Q245 1239 207 1276T169 1365T207 1454T307 1492T407 1455T446 1365ZM656 1365Q656 1419 696
-1455T795 1492Q854 1492 893 1455T933 1365Q933 1313 895 1276T795 1238T695 1275T656 1365Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1098" d="M738 0Q718 39 709 97Q604 -20 436 -20Q277 -20 173 72T68 304Q68 476 195 568T564 661H697V723Q697 798 659 843T537 888Q464 888 423 853T381 757H92Q92 851 150 931T314 1056T552 1102Q752 1102 869 1002T987
-719V250Q988 96 1030 17V0H738ZM499 201Q563 201 617 229T697 306V492H589Q372 492 358 342L357 325Q357 271 395 236T499 201ZM329 1420Q329 1506 394 1565T552 1625Q644 1625 709 1567T775 1420Q775 1335 711 1277T552 1219Q455 1219 392 1278T329 1420ZM444
-1420Q444 1376 473 1345T552 1313T631 1344T660 1420Q660 1466 631 1497T552 1529T474 1498T444 1420Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1729" d="M1246 -20Q999 -20 860 127Q796 58 694 19T466 -20Q280 -20 173 69T66 319Q66 476 190 562T557 649H725V706Q725 782 685 825T567 868Q485 868 438 833T390 745L101 764Q101 913 231 1007T570 1102Q781 1102 897
-992Q1023 1104 1223 1102Q1435 1102 1556 971T1677 607V450H1009Q1020 334 1089 273T1276 212Q1353 212 1418 228T1571 289L1648 100Q1575 44 1468 12T1246 -20ZM521 192Q570 192 628 214T725 272V461H561Q466 460 411 418T355 315Q355 259 395 226T521 192ZM1223
-868Q1133 868 1079 811T1011 644H1393V672Q1393 766 1350 817T1223 868Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1068" d="M561 213Q641 213 691 257T743 374H1014Q1013 264 954 173T793 31T566 -20Q334 -20 200 127T66 535V554Q66 804 199 953T564 1102Q767 1102 889 987T1014 679H743Q741 763 691 815T559 868Q458 868 407 795T355
-556V526Q355 359 406 286T561 213ZM666 6L655 -52Q805 -79 805 -225Q805 -335 714 -399T456 -463L449 -296Q561 -296 561 -215Q561 -173 528 -158T419 -137L450 6H666Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1107" d="M609 -20Q371 -20 222 126T72 515V543Q72 706 135 834T313 1032T577 1102Q799 1102 926 962T1054 565V447H365Q379 341 449 277T628 213Q795 213 889 334L1031 175Q966 83 855 32T609 -20ZM576 868Q490 868 437
-810T368 644H770V667Q768 763 718 815T576 868ZM688 1226H451L175 1536H490L688 1226Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1107" d="M609 -20Q371 -20 222 126T72 515V543Q72 706 135 834T313 1032T577 1102Q799 1102 926 962T1054 565V447H365Q379 341 449 277T628 213Q795 213 889 334L1031 175Q966 83 855 32T609 -20ZM576 868Q490 868 437
-810T368 644H770V667Q768 763 718 815T576 868ZM602 1536H917L640 1226H405L602 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1107" d="M609 -20Q371 -20 222 126T72 515V543Q72 706 135 834T313 1032T577 1102Q799 1102 926 962T1054 565V447H365Q379 341 449 277T628 213Q795 213 889 334L1031 175Q966 83 855 32T609 -20ZM576 868Q490 868 437
-810T368 644H770V667Q768 763 718 815T576 868ZM928 1256V1244H698L544 1389L390 1244H164V1260L460 1536H628L928 1256Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1107" d="M609 -20Q371 -20 222 126T72 515V543Q72 706 135 834T313 1032T577 1102Q799 1102 926 962T1054 565V447H365Q379 341 449 277T628 213Q795 213 889 334L1031 175Q966 83 855 32T609 -20ZM576 868Q490 868 437
-810T368 644H770V667Q768 763 718 815T576 868ZM439 1365Q439 1312 400 1276T300 1239Q238 1239 200 1276T162 1365T200 1454T300 1492T400 1455T439 1365ZM649 1365Q649 1419 689 1455T788 1492Q847 1492 886 1455T926 1365Q926 1313 888 1276T788 1238T688 1275T649
-1365Z" />
-<glyph unicode="&#xec;" horiz-adv-x="561" d="M423 0H134V1082H423V0ZM425 1211H188L-88 1521H227L425 1211Z" />
-<glyph unicode="&#xed;" horiz-adv-x="561" d="M423 0H134V1082H423V0ZM338 1777H653L376 1467H141L338 1777Z" />
-<glyph unicode="&#xee;" horiz-adv-x="561" d="M423 0H134V1082H423V0ZM665 1241V1229H435L281 1374L127 1229H-99V1245L197 1521H365L665 1241Z" />
-<glyph unicode="&#xef;" horiz-adv-x="561" d="M423 0H134V1082H423V0ZM176 1350Q176 1297 137 1261T37 1224Q-25 1224 -63 1261T-101 1350T-63 1439T37 1477T137 1440T176 1350ZM386 1350Q386 1404 426 1440T525 1477Q584 1477 623 1440T663 1350Q663 1298 625
-1261T525 1223T425 1260T386 1350Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1178" d="M849 1305Q1104 1043 1105 651V577Q1105 405 1039 268T853 56T587 -20Q443 -20 328 43T149 219T84 468Q84 699 207 832T536 966Q672 966 780 890Q731 1042 614 1155L423 1033L345 1147L497 1244Q381 1316 233 1355L324
-1579Q562 1531 740 1399L911 1508L988 1394L849 1305ZM816 663Q748 746 601 746Q488 746 431 672T373 468Q373 356 433 285T591 213Q694 213 755 303T816 552V663Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1147" d="M377 1082L386 957Q502 1102 697 1102Q869 1102 953 1001T1039 699V0H750V692Q750 784 710 825T577 867Q455 867 394 763V0H105V1082H377ZM951 1779Q951 1666 885 1590T724 1513Q686 1513 657 1521T575 1558T500
-1592T450 1599Q415 1599 391 1574T366 1503L198 1513Q198 1624 263 1702T424 1780Q454 1780 480 1773T567 1736T650 1701T698 1695Q733 1695 758 1719T784 1790L951 1779Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1158" d="M66 551Q66 712 128 838T306 1033T577 1102Q796 1102 934 968T1089 604L1091 530Q1091 281 952 131T579 -20T206 130T66 538V551ZM355 530Q355 376 413 295T579 213Q684 213 743 293T802 551Q802 702 743 785T577
-868Q471 868 413 786T355 530ZM720 1226H483L207 1536H522L720 1226Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1158" d="M66 551Q66 712 128 838T306 1033T577 1102Q796 1102 934 968T1089 604L1091 530Q1091 281 952 131T579 -20T206 130T66 538V551ZM355 530Q355 376 413 295T579 213Q684 213 743 293T802 551Q802 702 743 785T577
-868Q471 868 413 786T355 530ZM634 1536H949L672 1226H437L634 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1158" d="M66 551Q66 712 128 838T306 1033T577 1102Q796 1102 934 968T1089 604L1091 530Q1091 281 952 131T579 -20T206 130T66 538V551ZM355 530Q355 376 413 295T579 213Q684 213 743 293T802 551Q802 702 743 785T577
-868Q471 868 413 786T355 530ZM960 1256V1244H730L576 1389L422 1244H196V1260L492 1536H660L960 1256Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1158" d="M66 551Q66 712 128 838T306 1033T577 1102Q796 1102 934 968T1089 604L1091 530Q1091 281 952 131T579 -20T206 130T66 538V551ZM355 530Q355 376 413 295T579 213Q684 213 743 293T802 551Q802 702 743 785T577
-868Q471 868 413 786T355 530ZM952 1779Q952 1666 886 1590T725 1513Q687 1513 658 1521T576 1558T501 1592T451 1599Q416 1599 392 1574T367 1503L199 1513Q199 1624 264 1702T425 1780Q455 1780 481 1773T568 1736T651 1701T699 1695Q734 1695 759 1719T785 1790L952
-1779Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1158" d="M66 551Q66 712 128 838T306 1033T577 1102Q796 1102 934 968T1089 604L1091 530Q1091 281 952 131T579 -20T206 130T66 538V551ZM355 530Q355 376 413 295T579 213Q684 213 743 293T802 551Q802 702 743 785T577
-868Q471 868 413 786T355 530ZM471 1365Q471 1312 432 1276T332 1239Q270 1239 232 1276T194 1365T232 1454T332 1492T432 1455T471 1365ZM681 1365Q681 1419 721 1455T820 1492Q879 1492 918 1455T958 1365Q958 1313 920 1276T820 1238T720 1275T681 1365Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1168" d="M1091 571H63V801H1091V571ZM415 1089Q415 1157 460 1199T578 1241Q649 1241 695 1200T742 1089Q742 1022 697 981T578 939Q503 939 459 981T415 1089ZM415 277Q415 345 460 387T578 429Q649 429 695 388T742 277Q742
-210 697 169T578 127Q503 127 459 169T415 277Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1156" d="M66 551Q66 712 128 838T306 1033T577 1102Q678 1102 763 1073L833 1216H994L891 1005Q1091 856 1091 530Q1091 281 952 131T579 -20Q484 -20 403 6L331 -142H170L273 70Q66 216 66 551ZM355 530Q355 400 396 322L656
-854Q620 868 577 868Q471 868 413 786T355 530ZM802 551Q802 665 765 747L509 223Q539 213 579 213Q684 213 743 293T802 551Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1146" d="M759 110Q652 -20 463 -20Q289 -20 198 80T104 373V1082H393V383Q393 214 547 214Q694 214 749 316V1082H1039V0H767L759 110ZM716 1226H479L203 1536H518L716 1226Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1146" d="M759 110Q652 -20 463 -20Q289 -20 198 80T104 373V1082H393V383Q393 214 547 214Q694 214 749 316V1082H1039V0H767L759 110ZM630 1536H945L668 1226H433L630 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1146" d="M759 110Q652 -20 463 -20Q289 -20 198 80T104 373V1082H393V383Q393 214 547 214Q694 214 749 316V1082H1039V0H767L759 110ZM956 1256V1244H726L572 1389L418 1244H192V1260L488 1536H656L956 1256Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1146" d="M759 110Q652 -20 463 -20Q289 -20 198 80T104 373V1082H393V383Q393 214 547 214Q694 214 749 316V1082H1039V0H767L759 110ZM467 1365Q467 1312 428 1276T328 1239Q266 1239 228 1276T190 1365T228 1454T328 1492T428
-1455T467 1365ZM677 1365Q677 1419 717 1455T816 1492Q875 1492 914 1455T954 1365Q954 1313 916 1276T816 1238T716 1275T677 1365Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="1028" d="M515 409L715 1082H1025L590 -168L566 -225Q469 -437 246 -437Q183 -437 118 -418V-199L162 -200Q244 -200 284 -175T348 -92L382 -3L3 1082H314L515 409ZM578 1536H893L616 1226H381L578 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1162" d="M1087 531Q1087 281 974 131T667 -20Q503 -20 403 93V-416H113V1536H403V989Q503 1102 665 1102Q863 1102 975 955T1087 545V531ZM798 552Q798 703 745 785T589 867Q457 867 403 765V318Q457 213 591 213Q798 213 798 552Z" />
-<glyph unicode="&#xff;" horiz-adv-x="1028" d="M515 409L715 1082H1025L590 -168L566 -225Q469 -437 246 -437Q183 -437 118 -418V-199L162 -200Q244 -200 284 -175T348 -92L382 -3L3 1082H314L515 409ZM415 1365Q415 1312 376 1276T276 1239Q214 1239 176 1276T138
-1365T176 1454T276 1492T376 1455T415 1365ZM625 1365Q625 1419 665 1455T764 1492Q823 1492 862 1455T902 1365Q902 1313 864 1276T764 1238T664 1275T625 1365Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1294" d="M1444 596H408V832H1444V596Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1563" d="M1746 596H365V832H1746V596Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="479" d="M286 1570L422 1491Q336 1355 333 1215V1048H104V1198Q104 1292 156 1398T286 1570Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="470" d="M194 1009L58 1088Q144 1223 147 1367V1536H377V1381Q377 1291 327 1186T194 1009Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="508" d="M202 -305L66 -226Q144 -100 147 48V229H385L384 63Q383 -26 334 -129T202 -305Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="831" d="M294 1570L430 1491Q344 1355 341 1215V1048H112V1198Q112 1292 164 1398T294 1570ZM637 1570L773 1491Q687 1355 684 1215V1048H455V1198Q455 1292 507 1398T637 1570Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="837" d="M208 1009L72 1088Q158 1223 161 1367V1536H391V1381Q391 1291 341 1186T208 1009ZM555 1009L419 1088Q505 1223 508 1367V1536H738V1381Q738 1291 688 1186T555 1009Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="825" d="M209 -325L66 -246Q144 -112 147 47V263H385L384 64Q383 -33 336 -142T209 -325ZM545 -325L402 -246Q488 -98 491 48V263H729L728 60Q726 -36 676 -145T545 -325Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="736" d="M135 766Q135 870 201 933T371 996Q479 996 543 934T610 771V728Q610 625 545 563T373 500Q268 500 202 562T135 731V766Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="638" d="M334 524L574 125H388L108 515V534L388 924H574L334 524Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="618" d="M267 923L547 533V514L267 124H80L320 523L80 923H267Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-700.ttf b/static/fonts/roboto-v18-latin-700.ttf
deleted file mode 100644
index 031bf06cb2..0000000000
Binary files a/static/fonts/roboto-v18-latin-700.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700.woff b/static/fonts/roboto-v18-latin-700.woff
deleted file mode 100644
index a0d26516a8..0000000000
Binary files a/static/fonts/roboto-v18-latin-700.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700.woff2 b/static/fonts/roboto-v18-latin-700.woff2
deleted file mode 100644
index e327dc95b6..0000000000
Binary files a/static/fonts/roboto-v18-latin-700.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700italic.eot b/static/fonts/roboto-v18-latin-700italic.eot
deleted file mode 100644
index 7dc0ff449f..0000000000
Binary files a/static/fonts/roboto-v18-latin-700italic.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700italic.svg b/static/fonts/roboto-v18-latin-700italic.svg
deleted file mode 100644
index 050bee0e4a..0000000000
--- a/static/fonts/roboto-v18-latin-700italic.svg
+++ /dev/null
@@ -1,325 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1167" ><font-face
-    font-family="Roboto"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="505" />
-<glyph unicode="!" horiz-adv-x="550" d="M369 447H134L276 1456H577L369 447ZM41 131Q39 197 83 242T195 290Q259 292 306 251T355 142Q357 76 313 30T200 -18Q130 -18 86 26T41 131Z" />
-<glyph unicode="&quot;" horiz-adv-x="647" d="M381 1382L282 987H121L208 1536H406L381 1382ZM697 1382L598 987H438L524 1536H721L697 1382Z" />
-<glyph unicode="#" horiz-adv-x="1193" d="M611 410H432L290 0H104L246 410H28L58 582H305L402 866H180L211 1040H462L606 1456H790L647 1040H827L970 1456H1156L1013 1040H1222L1192 866H953L855 582H1069L1039 410H796L655 0H469L611 410ZM490 582H669L767 866H587L490
-582Z" />
-<glyph unicode="$" horiz-adv-x="1150" d="M737 390Q747 460 714 511T579 608T409 699Q204 837 219 1062Q230 1234 348 1343T657 1473L698 1687H855L813 1467Q965 1435 1044 1315T1119 1004L836 1005Q848 1241 697 1244Q618 1246 564 1196T499 1063Q490 999 521
-950T642 858T793 778Q1032 634 1016 392Q1005 218 888 111T576 -16L537 -215H381L420 -15Q244 11 152 136T65 458L347 457Q342 336 386 275T520 212Q605 210 665 259T737 390Z" />
-<glyph unicode="%" horiz-adv-x="1477" d="M525 1478Q659 1474 736 1389T806 1176L800 1099Q786 962 692 879T465 800Q335 802 257 885T184 1099L189 1166Q200 1308 292 1394T525 1478ZM373 1095Q368 1039 391 1003T466 965T556 999T608 1099L618 1177Q625 1236
-601 1272T526 1311Q471 1313 432 1274T383 1176L373 1095ZM723 357Q735 493 829 576T1059 658Q1192 654 1270 570T1340 357L1335 290Q1324 145 1230 60T999 -21Q871 -19 791 64T718 279L723 357ZM904 277Q899 222 925 185T999 145Q1057 143 1094 179T1142 279L1152
-359Q1159 418 1134 453T1060 491Q1006 493 967 457T915 357L904 277ZM386 111L247 196L1125 1320L1262 1237L386 111Z" />
-<glyph unicode="&amp;" horiz-adv-x="1314" d="M41 385Q51 568 258 710L356 773L316 863Q264 989 271 1086Q279 1201 336 1291T488 1430T695 1476Q842 1472 936 1379T1024 1145Q1014 956 797 813L683 738L871 456Q955 576 972 714H1211Q1192 432 1018 249L1186
-0H884L829 84Q649 -23 458 -19Q268 -17 149 95T41 385ZM480 213Q567 210 689 272L475 602L451 586Q345 507 330 399Q319 316 362 266T480 213ZM518 1090Q514 1066 517 1043Q524 990 566 909L648 959Q772 1034 781 1128Q787 1178 759 1211T681 1244Q619 1246 573
-1201T518 1090Z" />
-<glyph unicode="&apos;" horiz-adv-x="331" d="M389 1373L301 985H120L207 1536H414L389 1373Z" />
-<glyph unicode="(" horiz-adv-x="707" d="M122 588Q170 945 335 1226T751 1619L799 1458Q457 1197 366 619Q335 423 333 267Q328 -144 521 -304L458 -455Q242 -335 156 -40Q99 158 105 384Q107 479 118 564L122 588Z" />
-<glyph unicode=")" horiz-adv-x="710" d="M-56 -458L-104 -300Q239 -35 329 548Q358 735 360 893Q365 1304 174 1465L237 1616Q355 1552 439 1430T564 1134T603 778Q597 500 507 238T272 -203T-56 -458Z" />
-<glyph unicode="*" horiz-adv-x="910" d="M392 966L100 1058L185 1228L472 1100L515 1456H707L627 1109L934 1227L960 1034L632 945L793 673L632 569L506 862L284 584L135 703L392 966Z" />
-<glyph unicode="+" horiz-adv-x="1094" d="M712 815H1062L1016 554H667L596 146H327L398 554H46L92 815H443L511 1206H780L712 815Z" />
-<glyph unicode="," horiz-adv-x="495" d="M31 -365L-118 -284L-45 -167Q19 -60 37 34L74 246H312L283 62Q242 -197 31 -365Z" />
-<glyph unicode="-" horiz-adv-x="780" d="M638 507H90L130 740H679L638 507Z" />
-<glyph unicode="." horiz-adv-x="587" d="M200 298Q267 300 314 257T362 147Q364 81 318 35T205 -12Q138 -14 92 28T44 137T87 250T200 298Z" />
-<glyph unicode="/" horiz-adv-x="752" d="M77 -125H-145L649 1456H872L77 -125Z" />
-<glyph unicode="0" horiz-adv-x="1150" d="M485 -20Q296 -16 193 108T87 454Q86 528 95 602L136 875Q185 1173 329 1327T698 1476Q887 1472 990 1349T1097 1004Q1098 929 1089 855L1047 584Q997 284 855 130T485 -20ZM824 1038Q824 1237 684 1244Q482 1253 427
-936L377 598Q361 492 361 422Q356 219 500 212Q703 199 758 529L811 885Q824 972 824 1038Z" />
-<glyph unicode="1" horiz-adv-x="1150" d="M674 0H392L584 1108L230 1001L274 1248L882 1458L919 1459L674 0Z" />
-<glyph unicode="2" horiz-adv-x="1150" d="M971 0H1L34 210L551 695Q710 844 762 937T801 1119Q780 1243 658 1246Q562 1248 498 1179T419 998L137 997Q145 1133 218 1244T412 1416T675 1477Q878 1473 991 1363T1091 1070Q1075 864 848 640L704 503L406 235L1008
-233L971 0Z" />
-<glyph unicode="3" horiz-adv-x="1150" d="M422 856L557 855Q660 855 729 912T810 1065Q820 1146 779 1194T656 1245T516 1201T444 1080L162 1078Q171 1254 313 1366T660 1477Q866 1473 986 1362T1095 1068Q1081 860 830 742Q928 695 973 609T1013 416Q1006 284
-932 184T734 31T466 -20Q271 -18 148 97T27 400H307Q305 319 352 268T485 214Q583 212 653 269T735 420Q748 520 700 573T552 629L386 630L422 856Z" />
-<glyph unicode="4" horiz-adv-x="1150" d="M918 548H1078L1037 315H877L822 0H540L595 315H17L37 512L780 1456H1075L918 548ZM330 550L636 548L735 1066L709 1030L330 550Z" />
-<glyph unicode="5" horiz-adv-x="1150" d="M154 720L350 1456H1146L1108 1215H549L453 900Q542 956 663 956Q850 956 952 824T1039 474Q1027 330 955 215T764 38T504 -21Q381 -20 281 35T124 188T67 406H344Q348 317 393 267T515 214Q615 211 679 287T757 491Q769
-605 723 671T581 739Q475 741 385 661L154 720Z" />
-<glyph unicode="6" horiz-adv-x="1150" d="M991 1472L969 1233L914 1232Q571 1214 419 854Q544 977 712 973Q830 971 911 907T1031 732T1058 487Q1046 344 973 226T780 42T523 -21Q380 -17 278 59T128 269T97 559L108 649Q155 1025 383 1248T953 1472H991ZM616
-743Q543 745 485 707T389 610L376 520Q371 475 372 422Q374 328 415 271T531 213Q605 210 666 261T756 398T775 573Q766 651 725 696T616 743Z" />
-<glyph unicode="7" horiz-adv-x="1150" d="M1164 1279L424 0H113L851 1222H155L192 1456H1191L1164 1279Z" />
-<glyph unicode="8" horiz-adv-x="1150" d="M1104 1077Q1090 864 854 744Q939 685 981 598T1016 408Q1005 212 857 94T491 -20Q292 -18 172 94T62 390Q76 632 347 756Q200 873 210 1061Q217 1185 283 1281T460 1428T704 1476Q893 1472 1004 1364T1104 1077ZM738
-428Q749 514 707 571T583 630Q492 632 427 571T348 411Q337 325 378 270T504 212Q596 210 660 270T738 428ZM819 1063Q828 1145 793 1193T689 1244Q610 1246 555 1192T489 1047Q480 966 513 915T618 861Q696 859 752 915T819 1063Z" />
-<glyph unicode="9" horiz-adv-x="1150" d="M763 583Q640 469 500 471Q380 472 296 535T172 710T143 954Q157 1115 245 1245T474 1437Q567 1478 678 1476Q858 1472 965 1350T1086 1023Q1090 952 1083 882L1072 796Q1023 415 801 200T230 -15H209L231 227H246Q443
-224 570 312T763 583ZM578 691Q698 687 790 814L807 935Q812 977 812 1030Q810 1126 772 1184T662 1244Q590 1245 533 1193T446 1049T424 868Q431 788 471 740T578 691Z" />
-<glyph unicode=":" horiz-adv-x="571" d="M455 298Q522 300 569 257T617 147Q619 81 573 35T460 -12Q393 -14 347 28T299 137T342 250T455 298ZM340 1117Q407 1119 454 1076T502 966Q504 900 458 854T345 807Q278 805 232 847T184 956T227 1069T340 1117Z" />
-<glyph unicode=";" horiz-adv-x="531" d="M323 1117Q390 1119 437 1076T485 966Q487 900 441 854T328 807Q261 805 215 847T167 956T210 1069T323 1117ZM52 -365L-97 -284L-24 -167Q40 -60 58 34L95 246H333L304 62Q263 -197 52 -365Z" />
-<glyph unicode="&lt;" horiz-adv-x="1021" d="M337 612L856 411L810 144L36 509L77 745L978 1110L926 817L337 612Z" />
-<glyph unicode="=" horiz-adv-x="1147" d="M1025 746H156L198 982H1067L1025 746ZM950 313H81L123 549H992L950 313Z" />
-<glyph unicode="&gt;" horiz-adv-x="1036" d="M685 627L155 830L202 1095L985 730L944 495L33 129L85 421L685 627Z" />
-<glyph unicode="?" horiz-adv-x="998" d="M321 446Q330 576 374 665T512 830T638 941Q724 1036 713 1143Q703 1240 600 1243Q529 1245 480 1198T415 1070L132 1068Q145 1258 278 1369T614 1477Q803 1473 909 1369T1002 1092Q990 922 808 769L680 663Q588 578 568
-447L321 446ZM228 134Q226 201 271 247T384 295Q448 297 495 255T544 145Q546 82 502 35T388 -14Q321 -14 276 27T228 134Z" />
-<glyph unicode="@" horiz-adv-x="1788" d="M1194 -21Q1022 -16 976 122Q850 -22 708 -19Q588 -17 526 78T471 330Q477 485 554 648T748 902T1008 991Q1081 989 1145 966T1301 883L1167 301L1160 248Q1149 143 1234 138Q1360 133 1438 286T1533 663L1536 714Q1541
-875 1491 998T1333 1185T1068 1253Q904 1256 757 1184T493 970T311 647T237 277Q228 66 311 -76Q428 -274 708 -277Q869 -279 1046 -209L1074 -367Q945 -453 709 -453Q508 -451 371 -377T154 -178T54 111Q24 336 90 582T305 1023T650 1318T1065 1416Q1358 1411
-1527 1238T1710 765Q1716 596 1670 429T1534 147Q1398 -26 1194 -21ZM690 320Q679 160 780 157Q834 154 889 206T969 326L1096 804Q1065 815 1027 817Q901 822 817 709T696 378L690 320Z" />
-<glyph unicode="A" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543Z" />
-<glyph unicode="B" horiz-adv-x="1278" d="M21 0L274 1456L728 1455Q981 1454 1108 1352T1223 1065Q1209 844 968 742Q1055 712 1103 630T1144 435Q1130 229 983 115T580 0H21ZM425 634L356 241L587 240Q695 240 768 293T855 438Q869 528 831 578T701 633L425
-634ZM461 846L660 844Q771 846 841 896T926 1035Q951 1211 741 1212L525 1213L461 846Z" />
-<glyph unicode="C" horiz-adv-x="1310" d="M1208 486Q1191 335 1105 219T881 40T583 -20Q439 -17 332 46T164 230T94 508Q87 631 119 814T235 1139T434 1364Q596 1480 804 1476Q1030 1472 1162 1337T1308 960L1016 961Q1016 1099 961 1163T790 1231Q640 1236 544
-1124T414 797Q382 588 386 484Q391 352 445 290T596 224Q730 219 810 287T917 484L1208 486Z" />
-<glyph unicode="D" horiz-adv-x="1301" d="M21 0L274 1456L692 1455Q839 1452 956 1389T1147 1206T1235 938Q1243 851 1233 760L1226 707Q1182 387 975 194T471 0H21ZM525 1213L356 241L478 240Q680 240 802 388T943 835L945 867Q948 1032 882 1120T685 1212L525 1213Z" />
-<glyph unicode="E" horiz-adv-x="1127" d="M982 631H424L356 241H1012L970 0H21L274 1456H1221L1178 1213H525L464 866H1024L982 631Z" />
-<glyph unicode="F" horiz-adv-x="1098" d="M976 595H418L314 0H21L274 1456H1196L1153 1213H525L459 837H1019L976 595Z" />
-<glyph unicode="G" horiz-adv-x="1363" d="M1188 184Q1110 85 960 32T620 -19Q471 -18 358 46T180 232T106 508Q96 652 136 846T275 1187T512 1406T818 1476Q1046 1472 1175 1348T1322 991L1040 992Q1029 1114 975 1172T814 1234Q629 1240 523 1072T401 583Q391
-412 453 318T644 222Q793 218 898 293L947 544H681L720 765H1276L1188 184Z" />
-<glyph unicode="H" horiz-adv-x="1414" d="M1173 0H880L988 624H423L314 0H21L274 1456H567L464 866H1030L1132 1456H1425L1173 0Z" />
-<glyph unicode="I" horiz-adv-x="589" d="M333 0H40L292 1456H585L333 0Z" />
-<glyph unicode="J" horiz-adv-x="1120" d="M846 1456H1139L968 448Q950 310 876 201T686 34T431 -21Q225 -17 113 101T7 431L302 430Q287 224 447 221Q534 218 595 279T674 448L846 1456Z" />
-<glyph unicode="K" horiz-adv-x="1271" d="M576 581L384 403L314 0H21L274 1456H567L455 814L604 982L1042 1456H1424L795 794L1170 0H836L576 581Z" />
-<glyph unicode="L" horiz-adv-x="1086" d="M356 241H974L932 0H21L274 1456H567L356 241Z" />
-<glyph unicode="M" horiz-adv-x="1750" d="M650 1456L829 403L1372 1456H1762L1509 0H1215L1287 415L1429 1063L871 0H670L475 1100L381 383L314 0H21L274 1456H650Z" />
-<glyph unicode="N" horiz-adv-x="1413" d="M1172 0H888L483 971L314 0H21L274 1456H557L963 483L1132 1456H1424L1172 0Z" />
-<glyph unicode="O" horiz-adv-x="1382" d="M606 -20Q461 -17 351 48T176 237T101 521Q90 685 136 871T284 1198T523 1409T821 1476Q968 1473 1078 1407T1251 1216T1323 933Q1333 757 1285 571T1136 249T900 45T606 -20ZM1021 768L1029 863Q1039 1041 982 1133T807
-1229Q624 1235 517 1067T395 597Q385 420 442 325T619 225Q776 218 879 347T1014 714L1021 768Z" />
-<glyph unicode="P" horiz-adv-x="1291" d="M404 513L314 0H21L274 1456L784 1455Q1020 1455 1155 1324T1273 982Q1257 768 1095 640T680 512L404 513ZM445 756L689 754Q807 754 885 815T978 980T945 1146T801 1212L525 1213L445 756Z" />
-<glyph unicode="Q" horiz-adv-x="1382" d="M958 95L1160 -103L960 -260L705 -12Q648 -21 599 -19Q381 -17 247 129T98 522Q89 645 116 796T206 1075T360 1293T569 1431T817 1476Q963 1473 1073 1407T1247 1217T1320 933Q1325 846 1315 759L1298 644Q1231 272 958
-95ZM1026 863Q1033 1048 976 1136T803 1229Q620 1235 513 1067T391 597Q381 420 438 325T615 225Q772 218 875 347T1010 714Q1023 810 1026 863Z" />
-<glyph unicode="R" horiz-adv-x="1278" d="M645 533H407L314 0H21L274 1456L756 1455Q998 1455 1128 1341T1244 1024Q1223 724 924 607L1129 16V0H817L645 533ZM449 776L667 774Q783 776 858 836T949 1001Q963 1098 918 1153T775 1212L525 1213L449 776Z" />
-<glyph unicode="S" horiz-adv-x="1231" d="M822 389Q843 508 705 571L512 648Q176 798 193 1061Q200 1183 273 1277T478 1424T763 1476Q974 1472 1104 1351T1232 1025H940Q945 1124 897 1179T746 1236Q646 1238 572 1191T484 1060Q465 951 630 887L762 837L838
-802Q1133 656 1114 392Q1105 263 1032 170T832 26T553 -21Q398 -18 277 44T93 219Q34 324 38 459L331 458Q317 221 564 217Q671 217 740 264T822 389Z" />
-<glyph unicode="T" horiz-adv-x="1239" d="M1296 1213H864L654 0H361L571 1213H144L187 1456H1339L1296 1213Z" />
-<glyph unicode="U" horiz-adv-x="1318" d="M1349 1456L1185 496Q1151 255 985 115T573 -21Q419 -18 306 46T138 228T101 495L264 1456H557L394 494Q387 438 393 389Q413 227 586 221Q710 217 789 289T891 495L1055 1456H1349Z" />
-<glyph unicode="V" horiz-adv-x="1309" d="M606 364L1096 1456H1432L713 0H407L145 1456H460L606 364Z" />
-<glyph unicode="W" horiz-adv-x="1747" d="M1195 423L1546 1456H1845L1304 0H1009L932 970L551 0H256L170 1456H456L485 428L877 1456H1126L1195 423Z" />
-<glyph unicode="X" horiz-adv-x="1272" d="M679 956L1022 1456H1374L839 720L1141 0H817L626 508L275 0H-81L466 748L173 1456H493L679 956Z" />
-<glyph unicode="Y" horiz-adv-x="1238" d="M640 802L1047 1456H1383L747 512L659 0H361L456 545L154 1455L463 1456L640 802Z" />
-<glyph unicode="Z" horiz-adv-x="1214" d="M378 243L1086 241L1044 0H-34L-1 191L870 1211L177 1213L220 1456H1281L1248 1269L378 243Z" />
-<glyph unicode="[" horiz-adv-x="562" d="M673 1471H535L287 -116H425L390 -339H-31L287 1694H708L673 1471Z" />
-<glyph unicode="\" horiz-adv-x="848" d="M154 1456H429L745 -125H469L154 1456Z" />
-<glyph unicode="]" horiz-adv-x="562" d="M183 1694H604L286 -339H-135L-100 -116H39L287 1471H148L183 1694Z" />
-<glyph unicode="^" horiz-adv-x="878" d="M543 1183L296 729H57L474 1456H679L843 729H632L543 1183Z" />
-<glyph unicode="_" horiz-adv-x="897" d="M743 -226H-143L-103 0H782L743 -226Z" />
-<glyph unicode="`" horiz-adv-x="667" d="M638 1226L427 1227L204 1534L495 1536L638 1226Z" />
-<glyph unicode="a" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199Z" />
-<glyph unicode="b" horiz-adv-x="1128" d="M1043 538Q1013 282 887 128T561 -21Q390 -17 301 117L260 0H3L269 1536H552L443 983Q557 1106 707 1102Q864 1100 953 990T1049 684Q1051 622 1043 538ZM763 559Q772 644 769 691Q758 865 625 868Q500 872 418 755L340
-325Q378 217 502 213Q710 207 757 515L763 559Z" />
-<glyph unicode="c" horiz-adv-x="1046" d="M477 212Q555 210 607 254T675 373L940 374Q933 260 869 169T697 27T470 -21Q273 -18 158 115T47 469L50 524L51 535Q78 799 229 953T602 1102Q785 1098 892 983T998 678H735Q735 765 697 815T583 869Q381 875 338 574Q323
-465 327 390Q337 215 477 212Z" />
-<glyph unicode="d" horiz-adv-x="1129" d="M540 1103Q691 1099 784 982L890 1536H1173L907 0H655L671 116Q550 -25 389 -21Q288 -20 212 32T95 181T49 399Q46 462 52 521L58 566Q82 732 150 858T318 1045T540 1103ZM335 521Q327 445 330 393Q340 217 472 214Q591
-209 679 326L756 756Q717 863 600 868Q497 871 429 789T335 521Z" />
-<glyph unicode="e" horiz-adv-x="1084" d="M517 -20Q375 -19 266 49T102 237T60 501L63 541Q78 699 155 831T353 1034T621 1102Q830 1098 937 949T1019 570L1003 447H340Q336 342 391 279T541 214Q695 210 811 333L940 173Q879 81 764 30T517 -20ZM607 869Q529
-871 469 820T360 643H748L754 669Q760 709 755 745Q745 803 706 835T607 869Z" />
-<glyph unicode="f" horiz-adv-x="722" d="M79 0L230 870H74L111 1082L267 1083L281 1191Q307 1364 422 1462T715 1559Q776 1557 868 1538L843 1313Q795 1325 760 1325Q685 1326 632 1287T565 1170L550 1082H759L722 870H514L363 0H79Z" />
-<glyph unicode="g" horiz-adv-x="1144" d="M57 542Q87 793 220 949T557 1103Q730 1099 815 978L852 1083L1111 1082L934 37Q905 -179 750 -305T366 -427Q254 -425 152 -379T-16 -251L124 -79Q218 -198 360 -202Q470 -206 548 -145T654 29L670 94Q552 -24 405 -20Q247
--18 154 97T52 398Q49 459 57 542ZM334 424Q334 330 373 274T488 214Q603 210 692 312L776 770Q733 864 617 868Q509 871 434 781T340 542Q333 469 334 424Z" />
-<glyph unicode="h" horiz-adv-x="1122" d="M433 962Q560 1104 726 1102Q887 1098 962 987T1019 682L905 0H623L738 685Q743 724 740 757Q730 865 614 868Q500 872 414 770L278 0H-4L262 1536H545L433 962Z" />
-<glyph unicode="i" horiz-adv-x="537" d="M301 0H17L205 1082H489L301 0ZM238 1357Q236 1424 282 1468T393 1512Q457 1514 504 1473T553 1367Q555 1305 512 1259T398 1211Q335 1209 288 1249T238 1357Z" />
-<glyph unicode="j" horiz-adv-x="526" d="M490 1082L296 -59Q273 -240 166 -341T-112 -440Q-180 -438 -262 -421L-239 -191Q-189 -202 -152 -204Q-19 -206 10 -60L206 1082H490ZM233 1357Q231 1423 275 1466T388 1512Q457 1512 501 1471T548 1367Q550 1300 506
-1257T393 1211Q330 1209 283 1249T233 1357Z" />
-<glyph unicode="k" horiz-adv-x="1071" d="M471 431L340 317L285 0H3L269 1536H552L406 702L461 761L782 1082H1144L671 617L972 0H663L471 431Z" />
-<glyph unicode="l" horiz-adv-x="537" d="M301 0H17L284 1536H567L301 0Z" />
-<glyph unicode="m" horiz-adv-x="1730" d="M453 1083L430 960Q561 1106 747 1102Q847 1100 913 1056T1002 937Q1145 1106 1338 1102Q1487 1099 1562 1000T1626 714L1624 689L1509 0H1226L1341 691Q1345 728 1344 760Q1337 865 1224 868Q1108 868 1025 744L1022
-721L896 0H614L729 689Q733 726 732 758Q725 864 613 867Q506 870 420 766L285 0H3L190 1082L453 1083Z" />
-<glyph unicode="n" horiz-adv-x="1123" d="M449 1083L425 955Q555 1106 740 1102Q893 1099 966 990T1019 688L905 0H623L739 691Q744 730 741 762Q728 864 613 867Q502 871 414 764L279 0H-3L185 1082L449 1083Z" />
-<glyph unicode="o" horiz-adv-x="1133" d="M622 1102Q765 1100 868 1029T1020 832T1055 553Q1032 295 876 136T489 -20Q348 -18 245 52T93 248T58 524Q84 792 240 950T622 1102ZM337 421Q339 325 382 270T503 212Q633 208 707 331T776 656Q772 752 730 809T608
-869Q482 873 407 751T337 421Z" />
-<glyph unicode="p" horiz-adv-x="1128" d="M1042 538Q1021 368 953 236T784 40T560 -21Q403 -17 312 96L213 -416H-69L190 1082L450 1083L431 974Q548 1106 707 1102T954 987T1048 684Q1050 622 1042 538ZM762 559L768 655Q770 752 733 809T623 868Q500 872 420
-764L339 318Q376 217 498 213Q600 210 668 292T762 559Z" />
-<glyph unicode="q" horiz-adv-x="1132" d="M540 1103Q708 1099 797 967L843 1083L1095 1082L835 -416H551L652 95Q539 -24 389 -20Q288 -19 212 33T95 183T49 400Q46 463 52 523L58 567Q82 735 150 861T318 1046T540 1103ZM331 394Q341 216 473 213Q592 209 677
-318L759 768Q720 865 602 869Q496 872 427 786T338 544Q328 441 331 394Z" />
-<glyph unicode="r" horiz-adv-x="735" d="M744 811Q686 821 649 821Q498 825 410 708L285 0H3L191 1082L456 1083L430 951Q532 1104 682 1104Q724 1104 780 1090L744 811Z" />
-<glyph unicode="s" horiz-adv-x="1031" d="M630 305Q646 385 519 421L428 444Q105 533 114 758Q119 911 249 1007T564 1102Q747 1100 860 1005T975 752L695 753Q697 892 557 894Q491 894 443 861T383 772Q368 692 504 659L544 650Q682 617 755 575T867 469T904
-318Q901 215 838 138T664 19T431 -20Q251 -18 131 83T9 346L275 344Q279 189 441 187Q519 187 569 219T630 305Z" />
-<glyph unicode="t" horiz-adv-x="681" d="M575 1348L528 1082H708L671 870H491L399 328Q393 277 407 250T475 221Q491 220 561 226L541 5Q466 -20 379 -18Q240 -16 172 69T116 299L209 870H56L93 1082H246L292 1348H575Z" />
-<glyph unicode="u" horiz-adv-x="1122" d="M673 112Q553 -23 375 -20Q219 -18 139 92T77 382L194 1082H476L357 379Q353 346 356 317Q366 217 467 214Q598 210 684 315L819 1082H1103L915 0H652L673 112Z" />
-<glyph unicode="v" horiz-adv-x="1014" d="M458 357L766 1082H1070L547 0H277L92 1082H378L458 357Z" />
-<glyph unicode="w" horiz-adv-x="1470" d="M980 394L1237 1082H1518L1063 0H827L747 677L431 0H195L115 1082H379L396 401L705 1082H909L980 394Z" />
-<glyph unicode="x" horiz-adv-x="1021" d="M524 761L751 1082H1068L676 538L895 0H609L476 338L237 0H-82L326 566L117 1082H403L524 761Z" />
-<glyph unicode="y" horiz-adv-x="1007" d="M462 412L771 1082H1085L452 -163Q384 -306 293 -373T81 -440Q34 -440 -55 -419L-34 -199L5 -201Q143 -205 207 -100L269 15L92 1082H384L462 412Z" />
-<glyph unicode="z" horiz-adv-x="1021" d="M371 235L881 233L840 0H-33L0 191L603 846L128 848L169 1082H1012L980 897L371 235Z" />
-<glyph unicode="{" horiz-adv-x="666" d="M438 -360Q280 -307 203 -187Q126 -66 144 106L172 311Q177 353 174 389Q164 502 39 513L58 720Q243 728 273 942L305 1172Q364 1497 709 1601L756 1435Q588 1370 555 1131L523 902Q489 709 300 613Q369 562 401 485T424
-309L393 73L389 16Q382 -146 499 -199L438 -360Z" />
-<glyph unicode="|" horiz-adv-x="512" d="M203 -270H31L301 1456H473L203 -270Z" />
-<glyph unicode="}" horiz-adv-x="666" d="M-94 -197Q74 -132 107 107L139 337Q173 530 365 624Q293 673 261 752T238 929L269 1165L273 1222Q280 1383 164 1437L228 1595Q389 1541 462 1421T518 1132L490 928Q485 885 488 850Q498 735 623 724L604 517Q418 507
-389 296L362 97Q311 -256 -47 -364L-94 -197Z" />
-<glyph unicode="~" horiz-adv-x="1298" d="M1203 795Q1197 677 1151 579T1027 426T848 374Q771 376 711 409T593 501T507 576T443 593Q384 593 344 546T289 413L80 415Q92 601 189 716T438 828Q515 826 576 793T710 685T841 610Q903 610 945 660T1001 794L1203 795Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="505" />
-<glyph unicode="&#xa1;" horiz-adv-x="571" d="M171 639H406L263 -369H-37L171 639ZM499 953Q501 884 455 839T344 794Q281 792 234 834T184 943Q182 1008 226 1054T339 1102Q403 1104 450 1063T499 953Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1153" d="M518 212Q596 210 649 254T717 373L983 375Q972 224 866 121T592 -11L543 -245H347L397 -9Q233 29 154 173T96 523Q121 769 246 915T572 1094L619 1318H815L768 1090Q901 1058 975 951T1048 678H784L783 712Q770
-863 636 869Q535 874 469 795T381 552Q369 442 372 391Q377 215 518 212Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1190" d="M544 576L527 429Q511 320 426 237L1066 241L1023 0H-6L37 240L112 238Q160 257 187 297T228 421L249 576H91L132 812H282L309 1033Q335 1241 471 1360T807 1475Q998 1471 1103 1359T1205 1057L925 1058Q930 1232
-789 1235Q719 1237 669 1184T603 1040L576 812H876L835 576H544Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1385" d="M972 105Q790 -24 603 -20Q403 -16 272 106L119 -26L-3 132L151 257Q94 442 114 602Q140 817 285 977L170 1134L318 1264L427 1121Q604 1237 781 1233Q966 1231 1102 1117L1272 1265L1395 1106L1226 967Q1288 781
-1268 615Q1244 412 1111 255L1222 104L1073 -27L972 105ZM295 599Q280 489 314 390T424 231T605 168Q719 164 824 224T999 390T1088 617Q1103 727 1069 826T959 983T779 1045Q664 1049 558 989T382 824T295 599Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1075" d="M578 894L892 1456H1212L773 744L981 741L948 567H670L650 452H930L899 278H620L571 0H278L327 278H29L60 452H356L377 567H80L110 742H354L165 1456H458L578 894Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="511" d="M-28 -270L111 525H365L227 -270H-28ZM394 698H140L272 1456H526L394 698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1258" d="M1126 489Q1119 387 1064 319T921 205Q1016 94 1005 -70Q997 -187 930 -273T738 -407T458 -452Q228 -450 100 -340T-24 -34H257Q253 -125 308 -171T468 -217Q577 -217 643 -179T723 -73Q743 25 587 82L490 113Q262
-183 168 280T83 526Q93 703 288 812Q192 925 202 1087Q214 1253 345 1356T686 1474L753 1476Q971 1472 1092 1360T1210 1048H930Q933 1139 884 1189T743 1242Q640 1245 571 1204T486 1090Q464 973 639 925T906 830T1050 725Q1135 629 1126 489ZM479 705Q389 650
-372 555Q348 434 516 379L595 354L725 311Q820 367 840 460Q861 570 700 630L479 705Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="937" d="M211 1362Q209 1414 247 1452T342 1493T440 1458T481 1368Q483 1315 445 1278T349 1238Q296 1236 255 1271T211 1362ZM684 1362Q682 1414 720 1452T815 1493Q871 1495 911 1459T954 1368Q954 1313 917 1276T823 1237Q768
-1235 726 1271T684 1362Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1568" d="M1089 597Q1079 447 988 363T744 282Q596 286 514 395T444 669L455 779Q474 963 577 1070T836 1176Q981 1172 1061 1089T1139 859L987 861Q1000 1038 841 1042Q748 1044 686 973T609 777T594 632T595 584Q598 511
-635 466T737 417Q906 410 937 596L1089 597ZM235 722Q213 563 264 420T429 191T692 104Q853 100 998 182T1245 413T1371 736Q1393 895 1342 1037T1178 1263T914 1351Q752 1355 603 1270T355 1036T235 722ZM114 722Q131 874 200 1014T380 1262T625 1424T902 1476Q1085
-1472 1227 1374T1441 1102T1493 735Q1472 546 1373 379T1118 107Q924 -24 705 -20Q520 -16 379 83T165 357T114 722Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="892" d="M619 702L616 774Q527 691 415 691Q310 691 249 751T187 911Q189 1026 281 1088T542 1151L648 1149L660 1204L664 1250Q661 1325 583 1328Q463 1332 436 1229L263 1242Q270 1352 357 1415T577 1477Q698 1475 770
-1400T832 1200L779 853L775 794Q774 750 783 702H619ZM448 833Q517 833 609 896L637 1033H557Q473 1030 422 999T362 915Q355 877 377 855T448 833Z" />
-<glyph unicode="&#xab;" horiz-adv-x="1002" d="M534 508L696 126L529 125L316 513L317 534L647 924H850L534 508ZM651 508L813 126L646 125L433 513L434 534L764 924H967L651 508Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1105" d="M894 374H698L744 634H127L157 805H969L894 374Z" />
-<glyph unicode="&#xad;" horiz-adv-x="780" d="M638 507H90L130 740H679L638 507Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1568" d="M114 722Q131 874 200 1014T380 1262T625 1424T902 1476Q1085 1472 1227 1374T1441 1102T1493 735Q1472 546 1373 379T1118 107Q924 -24 705 -20Q520 -16 379 83T165 357T114 722ZM235 722Q213 562 265 418T429
-191T692 104Q849 100 996 182T1245 412T1371 736Q1393 895 1342 1037T1178 1263T914 1351Q752 1355 603 1270T355 1036T235 722ZM653 653L600 316H452L585 1166L841 1165Q983 1160 1059 1092T1131 910Q1128 852 1095 807T994 723Q1062 674 1068 574Q1069 545 1063
-485T1058 396L1062 333L1061 314L913 315Q907 352 909 388Q910 431 921 516Q928 579 907 613T820 651L653 653ZM674 787L790 786Q872 789 924 821T987 909Q998 967 970 998T853 1032L712 1033L674 787Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="1005" d="M940 1287H269L296 1454H967L940 1287Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="781" d="M228 1191Q230 1308 314 1393T510 1477Q614 1475 683 1395T751 1209Q749 1093 667 1009T473 927Q368 929 297 1006T228 1191ZM371 1193Q365 1148 391 1112T465 1076Q516 1076 558 1113T609 1207Q615 1256 590 1292T518
-1329Q467 1329 424 1289T371 1193Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1077" d="M711 942H1030L992 701H674L617 337H369L426 701H101L139 942H464L518 1285H765L711 942ZM855 1H15L52 236H892L855 1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="750" d="M684 667H81L107 817L442 1087Q537 1166 549 1228Q557 1264 539 1285T485 1306Q388 1306 364 1194L160 1192Q168 1318 256 1394T473 1469Q604 1467 680 1403T755 1227Q750 1089 586 972L508 917L378 833L714 831L684 667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="750" d="M350 1137H431Q485 1139 521 1163T567 1232Q572 1266 549 1284T490 1303Q410 1303 382 1243L174 1242Q181 1348 263 1409T476 1468Q612 1465 690 1407T766 1249Q763 1131 608 1066Q666 1046 695 1001T723 895Q721
-784 626 719T386 656Q257 658 178 725T96 905L291 904Q298 822 393 822Q445 822 482 847T528 915Q544 995 434 1000H340L350 1137Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="669" d="M426 1536H753L435 1226H186L426 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1233" d="M500 1082L397 460L391 377Q384 217 516 214Q649 210 737 318L872 1082H1154L966 0H718L726 69Q620 -24 496 -22Q403 -22 327 26L240 -416H-42L218 1082H500Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="983" d="M535 0L625 520L573 521Q362 524 247 651T149 980Q168 1194 317 1325T689 1457L1002 1456L749 0H535Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="608" d="M154 692Q152 759 197 805T310 853Q375 855 422 812T472 702Q474 637 429 590T314 542Q250 540 203 581T154 692Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="542" d="M222 9L202 -55Q264 -68 295 -111T327 -217Q327 -332 231 -396T-45 -465L-37 -295Q74 -290 91 -207Q103 -146 5 -139L-30 -136L13 6L222 9Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="750" d="M524 667H324L419 1210L228 1170L258 1338L627 1453L652 1454L524 667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="918" d="M581 1477Q729 1473 810 1372T881 1121L875 1055Q859 884 755 785T501 689Q357 693 273 792T200 1044L205 1107Q218 1274 322 1377T581 1477ZM372 1041Q369 1005 372 969Q377 908 410 872T500 834Q576 831 631 887T701
-1044L712 1145L711 1194Q696 1326 583 1329Q506 1332 451 1277T381 1121L372 1041Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="1002" d="M311 923L524 536L523 514L193 124H-10L305 539L144 922L311 923ZM692 923L905 536L904 514L574 124H371L686 539L525 922L692 923Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1436" d="M490 664H290L385 1207L194 1167L224 1335L593 1450L618 1451L490 664ZM374 119L235 204L1113 1328L1250 1245L374 119ZM1208 324L1304 325L1273 159H1188L1159 0H959L987 159H652L666 309L1085 788L1288 790L1208
-324ZM866 328L1018 325L1062 541L1044 516L866 328Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1522" d="M333 119L194 204L1072 1328L1209 1245L333 119ZM474 670H274L369 1213L178 1173L208 1341L577 1456L602 1457L474 670ZM1329 0H726L752 150L1087 420Q1182 499 1194 561Q1202 597 1184 618T1130 639Q1033 639 1009
-527L805 525Q813 651 901 727T1118 802Q1249 800 1325 736T1400 560Q1395 422 1231 305L1153 250L1023 166L1359 164L1329 0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1615" d="M530 119L391 204L1269 1328L1406 1245L530 119ZM1362 324L1458 325L1427 159H1342L1313 0H1113L1141 159H806L820 309L1239 788L1442 790L1362 324ZM1020 328L1172 325L1216 541L1198 516L1020 328ZM395 1137H476Q530
-1139 566 1163T612 1232Q617 1266 594 1284T535 1303Q455 1303 427 1243L219 1242Q226 1348 308 1409T521 1468Q657 1465 735 1407T811 1249Q808 1131 653 1066Q711 1046 740 1001T768 895Q766 784 671 719T431 656Q302 658 223 725T141 905L336 904Q343 822 438
-822Q490 822 527 847T573 915Q589 995 479 1000H385L395 1137Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="998" d="M648 644Q640 522 598 433T470 271L402 214Q275 108 258 -2Q249 -66 275 -108T370 -152Q441 -154 490 -110T559 21L841 23Q828 -168 696 -278T360 -385Q174 -383 66 -281T-31 -2Q-20 159 148 309L293 430Q379 509
-402 643L648 644ZM747 954Q749 885 703 840T592 795Q528 793 481 834T432 944Q430 1013 476 1058T587 1103Q651 1105 698 1064T747 954Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543ZM966 1536L755 1537L532 1844L823 1846L966 1536Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543ZM930 1846H1257L939 1536H690L930 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543ZM1214 1570V1549L998 1554L875 1698L700 1555L471 1551V1574L792 1846L953 1847L1214 1570Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543ZM1236 1834Q1229 1716 1166 1640T1005 1563Q977 1563 952 1571T875 1608T799 1646T744 1654Q668 1651 643 1556L477 1566Q484
-1682 550 1760T713 1836Q739 1836 762 1829T841 1791T921 1753T974 1746Q1051 1749 1075 1844L1236 1834Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543ZM486 1672Q484 1724 522 1762T617 1803T715 1768T756 1678Q758 1625 720 1588T624 1548Q571 1546 530 1581T486 1672ZM959
-1672Q957 1724 995 1762T1090 1803Q1146 1805 1186 1769T1229 1678Q1229 1623 1192 1586T1098 1547Q1043 1545 1001 1581T959 1672Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1347" d="M877 300H369L219 0H-104L674 1456H945L1222 0H923L877 300ZM489 543H840L758 1085L489 543ZM651 1723Q651 1813 717 1874T874 1936Q961 1936 1022 1878T1084 1737Q1086 1651 1021 1590T861 1528Q775 1528 714 1584T651
-1723ZM764 1723Q757 1683 779 1653T844 1623Q891 1623 927 1655T972 1737Q978 1780 955 1809T892 1839Q845 1839 808 1805T764 1723Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1877" d="M1706 0H835L879 333H456L236 0H-111L904 1456H1900L1858 1220H1278L1231 865H1719L1677 629H1200L1147 235H1747L1706 0ZM615 582L913 580L986 1132L615 582Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1310" d="M1208 486Q1191 335 1105 219T881 40T583 -20Q439 -17 332 46T164 230T94 508Q87 631 119 814T235 1139T434 1364Q596 1480 804 1476Q1030 1472 1162 1337T1308 960L1016 961Q1016 1099 961 1163T790 1231Q640 1236
-544 1124T414 797Q382 588 386 484Q391 352 445 290T596 224Q730 219 810 287T917 484L1208 486ZM660 8L640 -56Q702 -69 733 -112T765 -218Q765 -333 669 -397T393 -466L401 -296Q512 -291 529 -208Q541 -147 443 -140L408 -137L451 5L660 8Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1127" d="M982 631H424L356 241H1012L970 0H21L274 1456H1221L1178 1213H525L464 866H1024L982 631ZM911 1539L700 1540L477 1847L768 1849L911 1539Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1127" d="M982 631H424L356 241H1012L970 0H21L274 1456H1221L1178 1213H525L464 866H1024L982 631ZM875 1849H1202L884 1539H635L875 1849Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1127" d="M982 631H424L356 241H1012L970 0H21L274 1456H1221L1178 1213H525L464 866H1024L982 631ZM1159 1573V1552L943 1557L820 1701L645 1558L416 1554V1577L737 1849L898 1850L1159 1573Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1127" d="M982 631H424L356 241H1012L970 0H21L274 1456H1221L1178 1213H525L464 866H1024L982 631ZM431 1675Q429 1727 467 1765T562 1806T660 1771T701 1681Q703 1628 665 1591T569 1551Q516 1549 475 1584T431 1675ZM904
-1675Q902 1727 940 1765T1035 1806Q1091 1808 1131 1772T1174 1681Q1174 1626 1137 1589T1043 1550Q988 1548 946 1584T904 1675Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="589" d="M333 0H40L292 1456H585L333 0ZM585 1539L374 1540L151 1847L442 1849L585 1539Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="589" d="M333 0H40L292 1456H585L333 0ZM548 1849H875L557 1539H308L548 1849Z" />
-<glyph unicode="&#xce;" horiz-adv-x="589" d="M333 0H40L292 1456H585L333 0ZM833 1573V1552L617 1557L494 1701L319 1558L90 1554V1577L411 1849L572 1850L833 1573Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="589" d="M333 0H40L292 1456H585L333 0ZM105 1675Q103 1727 141 1765T236 1806T334 1771T375 1681Q377 1628 339 1591T243 1551Q190 1549 149 1584T105 1675ZM578 1675Q576 1727 614 1765T709 1806Q765 1808 805 1772T848
-1681Q848 1626 811 1589T717 1550Q662 1548 620 1584T578 1675Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1331" d="M51 0L162 642H-13L20 825H194L304 1456L720 1455Q867 1453 985 1389T1177 1206T1265 938Q1273 851 1263 760L1256 707Q1212 387 1005 194T501 0H51ZM667 642H455L386 241L508 240Q710 240 832 388T973 835L975
-867Q978 1032 912 1120T715 1212L555 1213L487 825H700L667 642Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1413" d="M1172 0H888L483 971L314 0H21L274 1456H557L963 483L1132 1456H1424L1172 0ZM1269 1834Q1262 1716 1199 1640T1038 1563Q1010 1563 985 1571T908 1608T832 1646T777 1654Q701 1651 676 1556L510 1566Q517 1682
-583 1760T746 1836Q772 1836 795 1829T874 1791T954 1753T1007 1746Q1084 1749 1108 1844L1269 1834Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1382" d="M606 -20Q461 -17 351 48T176 237T101 521Q90 685 136 871T284 1198T523 1409T821 1476Q968 1473 1078 1407T1251 1216T1323 933Q1333 757 1285 571T1136 249T900 45T606 -20ZM1021 768L1029 863Q1039 1041 982
-1133T807 1229Q624 1235 517 1067T395 597Q385 420 442 325T619 225Q776 218 879 347T1014 714L1021 768ZM980 1536L769 1537L546 1844L837 1846L980 1536Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1382" d="M606 -20Q461 -17 351 48T176 237T101 521Q90 685 136 871T284 1198T523 1409T821 1476Q968 1473 1078 1407T1251 1216T1323 933Q1333 757 1285 571T1136 249T900 45T606 -20ZM1021 768L1029 863Q1039 1041 982
-1133T807 1229Q624 1235 517 1067T395 597Q385 420 442 325T619 225Q776 218 879 347T1014 714L1021 768ZM944 1846H1271L953 1536H704L944 1846Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1382" d="M606 -20Q461 -17 351 48T176 237T101 521Q90 685 136 871T284 1198T523 1409T821 1476Q968 1473 1078 1407T1251 1216T1323 933Q1333 757 1285 571T1136 249T900 45T606 -20ZM1021 768L1029 863Q1039 1041 982
-1133T807 1229Q624 1235 517 1067T395 597Q385 420 442 325T619 225Q776 218 879 347T1014 714L1021 768ZM1228 1570V1549L1012 1554L889 1698L714 1555L485 1551V1574L806 1846L967 1847L1228 1570Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1382" d="M606 -20Q461 -17 351 48T176 237T101 521Q90 685 136 871T284 1198T523 1409T821 1476Q968 1473 1078 1407T1251 1216T1323 933Q1333 757 1285 571T1136 249T900 45T606 -20ZM1021 768L1029 863Q1039 1041 982
-1133T807 1229Q624 1235 517 1067T395 597Q385 420 442 325T619 225Q776 218 879 347T1014 714L1021 768ZM1250 1834Q1243 1716 1180 1640T1019 1563Q991 1563 966 1571T889 1608T813 1646T758 1654Q682 1651 657 1556L491 1566Q498 1682 564 1760T727 1836Q753
-1836 776 1829T855 1791T935 1753T988 1746Q1065 1749 1089 1844L1250 1834Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1382" d="M606 -20Q461 -17 351 48T176 237T101 521Q90 685 136 871T284 1198T523 1409T821 1476Q968 1473 1078 1407T1251 1216T1323 933Q1333 757 1285 571T1136 249T900 45T606 -20ZM1021 768L1029 863Q1039 1041 982
-1133T807 1229Q624 1235 517 1067T395 597Q385 420 442 325T619 225Q776 218 879 347T1014 714L1021 768ZM500 1672Q498 1724 536 1762T631 1803T729 1768T770 1678Q772 1625 734 1588T638 1548Q585 1546 544 1581T500 1672ZM973 1672Q971 1724 1009 1762T1104
-1803Q1160 1805 1200 1769T1243 1678Q1243 1623 1206 1586T1112 1547Q1057 1545 1015 1581T973 1672Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1065" d="M25 386L378 699L134 1012L314 1167L556 857L904 1168L1052 986L699 672L943 360L764 204L521 514L173 205L25 386Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1379" d="M606 -21Q451 -19 327 51L215 -95L12 -94L206 150Q68 382 107 695L115 753Q145 967 244 1135T493 1391T824 1477Q993 1473 1118 1393L1217 1518L1419 1517L1236 1288Q1356 1056 1320 759L1315 719Q1273 386 1081
-181T606 -21ZM387 552Q382 480 390 408L965 1172Q914 1226 813 1231Q655 1236 551 1109T411 749Q392 621 387 552ZM1044 1020L479 268Q530 228 618 223Q765 218 867 331T1010 660T1044 1020Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1318" d="M1349 1456L1185 496Q1151 255 985 115T573 -21Q419 -18 306 46T138 228T101 495L264 1456H557L394 494Q387 438 393 389Q413 227 586 221Q710 217 789 289T891 495L1055 1456H1349ZM945 1536L734 1537L511 1844L802
-1846L945 1536Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1318" d="M1349 1456L1185 496Q1151 255 985 115T573 -21Q419 -18 306 46T138 228T101 495L264 1456H557L394 494Q387 438 393 389Q413 227 586 221Q710 217 789 289T891 495L1055 1456H1349ZM909 1846H1236L918 1536H669L909 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1318" d="M1349 1456L1185 496Q1151 255 985 115T573 -21Q419 -18 306 46T138 228T101 495L264 1456H557L394 494Q387 438 393 389Q413 227 586 221Q710 217 789 289T891 495L1055 1456H1349ZM1193 1570V1549L977 1554L854
-1698L679 1555L450 1551V1574L771 1846L932 1847L1193 1570Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1318" d="M1349 1456L1185 496Q1151 255 985 115T573 -21Q419 -18 306 46T138 228T101 495L264 1456H557L394 494Q387 438 393 389Q413 227 586 221Q710 217 789 289T891 495L1055 1456H1349ZM465 1672Q463 1724 501 1762T596
-1803T694 1768T735 1678Q737 1625 699 1588T603 1548Q550 1546 509 1581T465 1672ZM938 1672Q936 1724 974 1762T1069 1803Q1125 1805 1165 1769T1208 1678Q1208 1623 1171 1586T1077 1547Q1022 1545 980 1581T938 1672Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1238" d="M640 802L1047 1456H1383L747 512L659 0H361L456 545L154 1455L463 1456L640 802ZM875 1846H1202L884 1536H635L875 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1219" d="M559 1456L512 1189L689 1188Q923 1187 1054 1066T1170 746Q1159 605 1082 501T876 342T590 286L357 287L306 0H24L277 1456H559ZM473 956L397 520L595 519Q708 519 789 578T888 744Q902 839 852 895T705 955L473 956Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1263" d="M308 0H26L214 1101Q243 1319 382 1442T734 1559Q908 1555 1009 1455T1099 1197Q1096 1151 1080 1111T1019 995T961 889T941 821Q933 775 953 727T1034 604T1120 473T1145 363Q1136 184 1006 81T670 -21Q504 -19
-391 38L467 265Q556 210 672 212Q744 212 799 250T867 357Q875 405 854 453T766 576T674 712Q654 758 657 808Q660 853 676 892T734 1002T792 1109T812 1184Q820 1246 790 1287T696 1331Q614 1334 563 1275T495 1098L308 0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199ZM776 1226L565 1227L342 1534L633 1536L776 1226Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199ZM740 1536H1067L749 1226H500L740 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199ZM1024 1260V1239L808 1244L685 1388L510 1245L281 1241V1264L602 1536L763 1537L1024 1260Z"
-/>
-<glyph unicode="&#xe3;" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199ZM1046 1781Q1039 1663 976 1587T815 1510Q787 1510 762 1518T685 1555T609 1593T554 1601Q478
-1598 453 1503L287 1513Q294 1629 360 1707T523 1783Q549 1783 572 1776T651 1738T731 1700T784 1693Q861 1696 885 1791L1046 1781Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199ZM296 1362Q294 1414 332 1452T427 1493T525 1458T566 1368Q568 1315 530 1278T434 1238Q381
-1236 340 1271T296 1362ZM769 1362Q767 1414 805 1452T900 1493Q956 1495 996 1459T1039 1368Q1039 1313 1002 1276T908 1237Q853 1235 811 1271T769 1362Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1075" d="M629 0Q616 41 618 98Q496 -24 342 -20Q200 -18 107 72T19 296Q26 473 167 567T547 662L679 660L693 725Q699 758 696 788Q691 835 661 861T580 889Q514 891 468 857T409 757L126 756Q133 911 268 1007T603 1102Q787
-1098 891 993T978 721L895 203L890 139Q888 68 907 19L906 0H629ZM412 199Q534 195 625 305L660 492L562 493Q406 489 337 398Q312 365 306 317Q298 263 328 232T412 199ZM461 1413Q461 1503 527 1564T684 1626Q771 1626 832 1568T894 1427Q896 1341 831 1280T671
-1218Q585 1218 524 1274T461 1413ZM574 1413Q567 1373 589 1343T654 1313Q701 1313 737 1345T782 1427Q788 1470 765 1499T702 1529Q655 1529 618 1495T574 1413Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1687" d="M1123 -20Q880 -15 771 126Q601 -24 367 -20Q261 -19 178 22T52 137T15 311Q22 475 159 562T537 650L704 648L717 708Q722 741 719 770Q705 866 604 869Q534 871 481 839T415 745L134 763Q142 923 282 1015T620
-1103Q824 1098 922 993Q1073 1105 1253 1101Q1445 1097 1548 962T1628 612L1603 450H961Q951 342 1003 279T1159 214Q1240 212 1313 234T1458 290L1519 97Q1384 -20 1123 -20ZM426 191Q522 191 642 271L680 461L541 462Q442 459 376 417T299 307Q289 254 324 223T426
-191ZM1237 869Q1066 875 981 643H1350L1357 674Q1363 710 1361 745Q1354 863 1237 869Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1046" d="M477 212Q555 210 607 254T675 373L940 374Q933 260 869 169T697 27T470 -21Q273 -18 158 115T47 469L50 524L51 535Q78 799 229 953T602 1102Q785 1098 892 983T998 678H735Q735 765 697 815T583 869Q381 875 338
-574Q323 465 327 390Q337 215 477 212ZM544 8L524 -56Q586 -69 617 -112T649 -218Q649 -333 553 -397T277 -466L285 -296Q396 -291 413 -208Q425 -147 327 -140L292 -137L335 5L544 8Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1084" d="M517 -20Q375 -19 266 49T102 237T60 501L63 541Q78 699 155 831T353 1034T621 1102Q830 1098 937 949T1019 570L1003 447H340Q336 342 391 279T541 214Q695 210 811 333L940 173Q879 81 764 30T517 -20ZM607 869Q529
-871 469 820T360 643H748L754 669Q760 709 755 745Q745 803 706 835T607 869ZM757 1226L546 1227L323 1534L614 1536L757 1226Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1084" d="M517 -20Q375 -19 266 49T102 237T60 501L63 541Q78 699 155 831T353 1034T621 1102Q830 1098 937 949T1019 570L1003 447H340Q336 342 391 279T541 214Q695 210 811 333L940 173Q879 81 764 30T517 -20ZM607 869Q529
-871 469 820T360 643H748L754 669Q760 709 755 745Q745 803 706 835T607 869ZM721 1536H1048L730 1226H481L721 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1084" d="M517 -20Q375 -19 266 49T102 237T60 501L63 541Q78 699 155 831T353 1034T621 1102Q830 1098 937 949T1019 570L1003 447H340Q336 342 391 279T541 214Q695 210 811 333L940 173Q879 81 764 30T517 -20ZM607 869Q529
-871 469 820T360 643H748L754 669Q760 709 755 745Q745 803 706 835T607 869ZM1005 1260V1239L789 1244L666 1388L491 1245L262 1241V1264L583 1536L744 1537L1005 1260Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1084" d="M517 -20Q375 -19 266 49T102 237T60 501L63 541Q78 699 155 831T353 1034T621 1102Q830 1098 937 949T1019 570L1003 447H340Q336 342 391 279T541 214Q695 210 811 333L940 173Q879 81 764 30T517 -20ZM607 869Q529
-871 469 820T360 643H748L754 669Q760 709 755 745Q745 803 706 835T607 869ZM277 1362Q275 1414 313 1452T408 1493T506 1458T547 1368Q549 1315 511 1278T415 1238Q362 1236 321 1271T277 1362ZM750 1362Q748 1414 786 1452T881 1493Q937 1495 977 1459T1020
-1368Q1020 1313 983 1276T889 1237Q834 1235 792 1271T750 1362Z" />
-<glyph unicode="&#xec;" horiz-adv-x="554" d="M307 0H25L213 1082H495L307 0ZM767 1467L556 1468L333 1775L624 1777L767 1467Z" />
-<glyph unicode="&#xed;" horiz-adv-x="554" d="M307 0H25L213 1082H495L307 0ZM474 1777H801L483 1467H234L474 1777Z" />
-<glyph unicode="&#xee;" horiz-adv-x="554" d="M307 0H25L213 1082H495L307 0ZM759 1245V1224L543 1229L420 1373L245 1230L16 1226V1249L337 1521L498 1522L759 1245Z" />
-<glyph unicode="&#xef;" horiz-adv-x="554" d="M307 0H25L213 1082H495L307 0ZM31 1347Q29 1399 67 1437T162 1478T260 1443T301 1353Q303 1300 265 1263T169 1223Q116 1221 75 1256T31 1347ZM504 1347Q502 1399 540 1437T635 1478Q691 1480 731 1444T774 1353Q774
-1298 737 1261T643 1222Q588 1220 546 1256T504 1347Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1153" d="M948 1302Q1035 1147 1069 989T1082 653L1076 601Q1042 320 879 147T488 -21Q359 -18 258 44T104 218T64 460Q77 608 144 726T319 906T565 967Q694 963 802 889Q796 1029 710 1154L499 1031L437 1159L598 1248Q517
-1315 363 1357L471 1579Q694 1526 842 1399L1034 1511L1094 1382L948 1302ZM809 665Q782 706 732 727T621 748Q509 750 435 670T346 460Q334 351 377 283T506 211Q607 208 679 289T783 526L806 652L809 665Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1123" d="M449 1083L425 955Q555 1106 740 1102Q893 1099 966 990T1019 688L905 0H623L739 691Q744 730 741 762Q728 864 613 867Q502 871 414 764L279 0H-3L185 1082L449 1083ZM1069 1781Q1062 1663 999 1587T838 1510Q810
-1510 785 1518T708 1555T632 1593T577 1601Q501 1598 476 1503L310 1513Q317 1629 383 1707T546 1783Q572 1783 595 1776T674 1738T754 1700T807 1693Q884 1696 908 1791L1069 1781Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1133" d="M622 1102Q765 1100 868 1029T1020 832T1055 553Q1032 295 876 136T489 -20Q348 -18 245 52T93 248T58 524Q84 792 240 950T622 1102ZM337 421Q339 325 382 270T503 212Q633 208 707 331T776 656Q772 752 730 809T608
-869Q482 873 407 751T337 421ZM788 1226L577 1227L354 1534L645 1536L788 1226Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1133" d="M622 1102Q765 1100 868 1029T1020 832T1055 553Q1032 295 876 136T489 -20Q348 -18 245 52T93 248T58 524Q84 792 240 950T622 1102ZM337 421Q339 325 382 270T503 212Q633 208 707 331T776 656Q772 752 730 809T608
-869Q482 873 407 751T337 421ZM752 1536H1079L761 1226H512L752 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1133" d="M622 1102Q765 1100 868 1029T1020 832T1055 553Q1032 295 876 136T489 -20Q348 -18 245 52T93 248T58 524Q84 792 240 950T622 1102ZM337 421Q339 325 382 270T503 212Q633 208 707 331T776 656Q772 752 730 809T608
-869Q482 873 407 751T337 421ZM1036 1260V1239L820 1244L697 1388L522 1245L293 1241V1264L614 1536L775 1537L1036 1260Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1133" d="M622 1102Q765 1100 868 1029T1020 832T1055 553Q1032 295 876 136T489 -20Q348 -18 245 52T93 248T58 524Q84 792 240 950T622 1102ZM337 421Q339 325 382 270T503 212Q633 208 707 331T776 656Q772 752 730 809T608
-869Q482 873 407 751T337 421ZM1058 1781Q1051 1663 988 1587T827 1510Q799 1510 774 1518T697 1555T621 1593T566 1601Q490 1598 465 1503L299 1513Q306 1629 372 1707T535 1783Q561 1783 584 1776T663 1738T743 1700T796 1693Q873 1696 897 1791L1058 1781Z"
-/>
-<glyph unicode="&#xf6;" horiz-adv-x="1133" d="M622 1102Q765 1100 868 1029T1020 832T1055 553Q1032 295 876 136T489 -20Q348 -18 245 52T93 248T58 524Q84 792 240 950T622 1102ZM337 421Q339 325 382 270T503 212Q633 208 707 331T776 656Q772 752 730 809T608
-869Q482 873 407 751T337 421ZM308 1362Q306 1414 344 1452T439 1493T537 1458T578 1368Q580 1315 542 1278T446 1238Q393 1236 352 1271T308 1362ZM781 1362Q779 1414 817 1452T912 1493Q968 1495 1008 1459T1051 1368Q1051 1313 1014 1276T920 1237Q865 1235
-823 1271T781 1362Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1143" d="M1054 571H55L95 801H1095L1054 571ZM487 1084Q485 1150 530 1196T644 1242Q711 1244 757 1202T805 1094T762 983T649 938Q581 936 535 977T487 1084ZM346 272Q344 338 389 384T503 430Q570 432 616 390T664 282T621
-171T508 126Q440 124 394 165T346 272Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1131" d="M55 545Q75 707 153 837T353 1037T627 1104Q718 1103 807 1072L907 1216L1081 1215L931 1001Q1045 867 1054 673Q1056 615 1048 532Q1028 370 951 243T750 46T475 -22Q388 -21 304 7L201 -142L27 -141L177 74Q58
-205 50 402Q47 459 55 545ZM320 423Q316 371 326 320L682 860Q650 872 616 872Q489 874 412 761T320 423ZM782 651Q785 699 778 749L425 218Q455 210 484 209Q592 207 666 289T768 532Q779 608 782 651Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1122" d="M673 112Q553 -23 375 -20Q219 -18 139 92T77 382L194 1082H476L357 379Q353 346 356 317Q366 217 467 214Q598 210 684 315L819 1082H1103L915 0H652L673 112ZM796 1226L585 1227L362 1534L653 1536L796 1226Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1122" d="M673 112Q553 -23 375 -20Q219 -18 139 92T77 382L194 1082H476L357 379Q353 346 356 317Q366 217 467 214Q598 210 684 315L819 1082H1103L915 0H652L673 112ZM760 1536H1087L769 1226H520L760 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1122" d="M673 112Q553 -23 375 -20Q219 -18 139 92T77 382L194 1082H476L357 379Q353 346 356 317Q366 217 467 214Q598 210 684 315L819 1082H1103L915 0H652L673 112ZM1044 1260V1239L828 1244L705 1388L530 1245L301
-1241V1264L622 1536L783 1537L1044 1260Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1122" d="M673 112Q553 -23 375 -20Q219 -18 139 92T77 382L194 1082H476L357 379Q353 346 356 317Q366 217 467 214Q598 210 684 315L819 1082H1103L915 0H652L673 112ZM316 1362Q314 1414 352 1452T447 1493T545 1458T586
-1368Q588 1315 550 1278T454 1238Q401 1236 360 1271T316 1362ZM789 1362Q787 1414 825 1452T920 1493Q976 1495 1016 1459T1059 1368Q1059 1313 1022 1276T928 1237Q873 1235 831 1271T789 1362Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="1007" d="M462 412L771 1082H1085L452 -163Q384 -306 293 -373T81 -440Q34 -440 -55 -419L-34 -199L5 -201Q143 -205 207 -100L269 15L92 1082H384L462 412ZM710 1536H1037L719 1226H470L710 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1137" d="M1044 538Q1023 365 955 234T786 40T562 -21Q408 -17 314 95L216 -416H-67L271 1536H555L447 987Q560 1106 709 1102Q865 1100 954 990T1050 684Q1052 622 1044 538ZM764 559L770 655Q772 752 735 809T625 868Q505
-872 423 766L341 316Q378 215 500 213Q598 210 665 287T758 517L764 559Z" />
-<glyph unicode="&#xff;" horiz-adv-x="1007" d="M462 412L771 1082H1085L452 -163Q384 -306 293 -373T81 -440Q34 -440 -55 -419L-34 -199L5 -201Q143 -205 207 -100L269 15L92 1082H384L462 412ZM266 1362Q264 1414 302 1452T397 1493T495 1458T536 1368Q538
-1315 500 1278T404 1238Q351 1236 310 1271T266 1362ZM739 1362Q737 1414 775 1452T870 1493Q926 1495 966 1459T1009 1368Q1009 1313 972 1276T878 1237Q823 1235 781 1271T739 1362Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1265" d="M1409 596H402L451 832H1459L1409 596Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1526" d="M1702 596H360L425 832H1769L1702 596Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="475" d="M428 1570L562 1488Q516 1420 480 1351T428 1199L402 1048H178L198 1180Q234 1412 428 1570Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="466" d="M285 1007L142 1091Q245 1239 271 1351L304 1536H529L506 1388Q472 1167 285 1007Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="503" d="M57 -305L-77 -223Q19 -79 44 38L78 229H310L288 86Q252 -146 57 -305Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="816" d="M436 1570L570 1488Q524 1420 488 1351T436 1199L410 1048H186L206 1180Q242 1412 436 1570ZM768 1570L902 1488Q856 1420 820 1351T768 1199L742 1048H518L538 1180Q574 1412 768 1570Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="822" d="M299 1007L156 1091Q259 1239 285 1351L318 1536H543L520 1388Q486 1167 299 1007ZM635 1007L492 1091Q595 1239 621 1351L654 1536H879L856 1388Q822 1167 635 1007Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="810" d="M60 -325L-80 -244Q16 -96 44 38L84 263H316L285 72Q246 -166 60 -325ZM386 -325L245 -244Q350 -83 377 35L417 263H649L622 86Q584 -158 386 -325Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="724" d="M399 997Q498 995 557 933T617 769L616 729Q610 624 543 560T374 498Q275 500 216 563T156 720L157 754Q160 862 226 929T399 997Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="629" d="M308 508L470 126L303 125L90 513L91 534L421 924H624L308 508Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="609" d="M306 923L519 536L518 514L188 124H-15L300 539L139 922L306 923Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-700italic.ttf b/static/fonts/roboto-v18-latin-700italic.ttf
deleted file mode 100644
index c74a678184..0000000000
Binary files a/static/fonts/roboto-v18-latin-700italic.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700italic.woff b/static/fonts/roboto-v18-latin-700italic.woff
deleted file mode 100644
index a3ca246269..0000000000
Binary files a/static/fonts/roboto-v18-latin-700italic.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-700italic.woff2 b/static/fonts/roboto-v18-latin-700italic.woff2
deleted file mode 100644
index d3239a3b13..0000000000
Binary files a/static/fonts/roboto-v18-latin-700italic.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900.eot b/static/fonts/roboto-v18-latin-900.eot
deleted file mode 100644
index f68f64b318..0000000000
Binary files a/static/fonts/roboto-v18-latin-900.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900.svg b/static/fonts/roboto-v18-latin-900.svg
deleted file mode 100644
index 9efdf4e953..0000000000
--- a/static/fonts/roboto-v18-latin-900.svg
+++ /dev/null
@@ -1,302 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1206" ><font-face
-    font-family="Roboto Black"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="510" />
-<glyph unicode="!" horiz-adv-x="565" d="M429 461H156L113 1456H472L429 461ZM103 151Q103 225 156 272T290 320T423 273T477 151T424 30T290 -18T157 29T103 151Z" />
-<glyph unicode="&quot;" horiz-adv-x="649" d="M255 1398L212 969H25V1537H255V1398ZM606 1398L563 969H378V1537H606V1398Z" />
-<glyph unicode="#" horiz-adv-x="1190" d="M612 410H451L384 0H185L252 410H30V593H282L326 857H105V1040H356L425 1456H623L555 1040H716L785 1456H984L915 1040H1146V857H885L841 593H1070V410H811L744 0H545L612 410ZM481 593H642L686 857H525L481 593Z" />
-<glyph unicode="$" horiz-adv-x="1186" d="M760 386Q760 465 721 510T584 595T403 676T260 771T168 896T136 1068Q136 1237 250 1346T554 1474V1685H713V1470Q896 1443 1000 1320T1105 1006H767Q767 1110 727 1166T613 1222Q547 1222 511 1181T474 1066Q474 992
-516 949T651 866T826 784T969 687T1063 561T1097 388Q1097 217 989 109T693 -17V-218H534V-16Q316 7 200 133T83 467H420Q420 353 470 294T614 234Q682 234 721 274T760 386Z" />
-<glyph unicode="%" horiz-adv-x="1520" d="M90 1176Q90 1311 178 1394T414 1477Q564 1477 651 1395T738 1171V1099Q738 964 651 882T416 800Q269 800 180 881T90 1105V1176ZM307 1099Q307 1047 336 1015T416 982Q521 982 521 1116V1176Q521 1228 493 1261T414
-1295Q365 1295 336 1263T307 1174V1099ZM782 357Q782 493 870 575T1106 657Q1255 657 1343 576T1431 350V280Q1431 144 1344 62T1108 -20Q961 -20 872 61T782 285V357ZM998 280Q998 233 1030 198T1108 162Q1205 162 1213 254L1214 357Q1214 410 1185 442T1106 475Q1058
-475 1029 445T998 362V280ZM480 109L323 188L1034 1326L1191 1247L480 109Z" />
-<glyph unicode="&amp;" horiz-adv-x="1380" d="M311 767Q252 851 219 927T185 1084Q185 1260 299 1368T597 1477Q762 1477 870 1377T978 1127Q978 941 773 797L697 744L921 487Q976 597 976 728H1259Q1259 433 1123 255L1345 0H969L901 77Q817 27 730 3T532 -21Q316
--21 186 92T56 391Q56 492 107 574T308 765L311 767ZM554 239Q642 239 722 280L460 578L451 572Q394 502 394 414Q394 341 440 290T554 239ZM476 1088Q476 1018 552 918L619 960Q665 990 686 1022T707 1103Q707 1149 675 1183T596 1217Q540 1217 508 1182T476 1088Z"
-/>
-<glyph unicode="&apos;" horiz-adv-x="316" d="M283 1374L250 961H43V1536H283V1374Z" />
-<glyph unicode="(" horiz-adv-x="723" d="M120 592Q120 836 185 1046T364 1402T619 1606L683 1440Q543 1337 467 1119T389 606V562Q389 261 465 40T683 -284L619 -450Q481 -394 365 -246T185 109T120 547V592Z" />
-<glyph unicode=")" horiz-adv-x="721" d="M626 564Q626 329 557 118T367 -244T104 -450L40 -284Q179 -180 255 36T334 533V594Q334 895 258 1116T40 1440L104 1606Q244 1551 364 1403T554 1046T626 608V564Z" />
-<glyph unicode="*" horiz-adv-x="952" d="M352 956L26 1046L91 1235L410 1104L385 1456H599L573 1097L883 1225L948 1034L618 944L837 679L664 561L481 855L297 571L124 684L352 956Z" />
-<glyph unicode="+" horiz-adv-x="1094" d="M702 826H1043V537H702V146H387V537H45V826H387V1206H702V826Z" />
-<glyph unicode="," horiz-adv-x="552" d="M213 -392L43 -312L77 -244Q147 -114 150 4V254H420L419 37Q418 -78 360 -197T213 -392Z" />
-<glyph unicode="-" horiz-adv-x="921" d="M753 497H152V758H753V497Z" />
-<glyph unicode="." horiz-adv-x="619" d="M303 327Q383 327 436 280T489 158T436 37T303 -11Q222 -11 170 37T117 158T169 279T303 327Z" />
-<glyph unicode="/" horiz-adv-x="719" d="M210 -125H-29L468 1456H708L210 -125Z" />
-<glyph unicode="0" horiz-adv-x="1186" d="M1100 595Q1100 300 968 140T594 -20Q351 -20 218 141T85 595V861Q85 1156 217 1316T592 1476T967 1315T1100 860V595ZM763 904Q763 1061 722 1138T592 1216Q505 1216 466 1144T423 926V554Q423 391 464 316T594 240Q680
-240 721 313T763 544V904Z" />
-<glyph unicode="1" horiz-adv-x="1186" d="M836 0H498V1076L166 979V1235L805 1456H836V0Z" />
-<glyph unicode="2" horiz-adv-x="1186" d="M1105 0H89V220L557 712Q730 909 730 1025Q730 1119 689 1168T570 1217Q493 1217 445 1152T397 988H59Q59 1122 126 1235T312 1413T578 1477Q814 1477 941 1368T1069 1055Q1069 969 1037 888T938 717T720 477L532 260H1105V0Z" />
-<glyph unicode="3" horiz-adv-x="1186" d="M397 869H556Q745 869 745 1054Q745 1126 700 1171T573 1217Q506 1217 457 1178T407 1081H70Q70 1196 134 1286T311 1426T561 1477Q804 1477 943 1366T1082 1061Q1082 967 1025 884T857 748Q973 706 1039 621T1105 409Q1105
-214 955 97T561 -20Q418 -20 296 34T110 185T47 405H386Q386 338 440 289T573 240Q662 240 715 289T768 416Q768 526 713 572T561 618H397V869Z" />
-<glyph unicode="4" horiz-adv-x="1186" d="M979 569H1127V309H979V0H642V309H79L59 515L642 1453V1456H979V569ZM380 569H642V1017L621 983L380 569Z" />
-<glyph unicode="5" horiz-adv-x="1186" d="M109 712L198 1456H1049V1194H472L439 905Q475 926 533 942T648 958Q865 958 981 830T1098 469Q1098 329 1036 216T860 41T593 -20Q456 -20 336 36T148 191T81 414H419Q424 334 470 287T591 240Q761 240 761 492Q761
-725 553 725Q435 725 377 649L109 712Z" />
-<glyph unicode="6" horiz-adv-x="1186" d="M903 1477V1212H888Q699 1212 578 1122T428 870Q542 982 716 982Q905 982 1017 844T1129 482Q1129 343 1064 227T881 46T620 -20Q465 -20 343 50T153 252T83 554V689Q83 914 179 1093T455 1375T852 1477H903ZM599 724Q532
-724 487 693T420 617V516Q420 240 611 240Q688 240 739 309T791 482Q791 589 739 656T599 724Z" />
-<glyph unicode="7" horiz-adv-x="1186" d="M1101 1276L557 0H201L746 1196H52V1456H1101V1276Z" />
-<glyph unicode="8" horiz-adv-x="1186" d="M1071 1067Q1071 961 1019 880T874 750Q978 699 1039 611T1100 401Q1100 206 966 93T595 -20Q358 -20 221 93T84 401Q84 518 144 608T314 750Q221 799 168 880T115 1067Q115 1257 244 1367T592 1477Q813 1477 942 1367T1071
-1067ZM762 428Q762 518 716 566T593 615T470 567T423 428Q423 341 470 291T595 240Q670 240 716 290T762 428ZM592 1217Q524 1217 489 1173T453 1049Q453 971 489 923T595 875Q664 875 698 923T733 1049T698 1172T592 1217Z" />
-<glyph unicode="9" horiz-adv-x="1186" d="M753 563Q644 465 509 465Q311 465 195 599T79 957Q79 1097 144 1217T326 1407T586 1477Q730 1477 846 1405T1028 1200T1095 894V765Q1095 524 1001 347T731 75T323 -20H302V250L366 251Q714 268 753 563ZM600 708Q710
-708 758 803V943Q758 1083 711 1150T584 1217Q513 1217 465 1141T417 957Q417 843 466 776T600 708Z" />
-<glyph unicode=":" horiz-adv-x="615" d="M304 327Q384 327 437 280T490 158T437 37T304 -11Q223 -11 171 37T118 158T170 279T304 327ZM304 1125Q384 1125 437 1078T490 956T437 835T304 787Q223 787 171 835T118 956T170 1077T304 1125Z" />
-<glyph unicode=";" horiz-adv-x="590" d="M294 1125Q374 1125 427 1078T480 956T427 835T294 787Q213 787 161 835T108 956T160 1077T294 1125ZM238 -392L68 -312L102 -244Q172 -114 175 4V254H445L444 37Q443 -78 385 -197T238 -392Z" />
-<glyph unicode="&lt;" horiz-adv-x="1044" d="M383 609L930 425V118L46 478V744L930 1104V798L383 609Z" />
-<glyph unicode="=" horiz-adv-x="1199" d="M1054 722H128V982H1054V722ZM1054 283H128V543H1054V283Z" />
-<glyph unicode="&gt;" horiz-adv-x="1050" d="M655 612L111 797V1103L990 743V477L111 117V423L655 612Z" />
-<glyph unicode="?" horiz-adv-x="1043" d="M344 461Q344 607 377 691T484 838T596 951T635 1065Q635 1216 505 1216Q445 1216 408 1172T369 1053H31Q33 1253 157 1364T505 1476Q728 1476 850 1373T973 1080Q973 997 940 929T834 790L719 683Q670 636 651 587T630
-461H344ZM303 157Q303 231 356 278T490 326T623 279T677 157T624 36T490 -12T357 35T303 157Z" />
-<glyph unicode="@" horiz-adv-x="1834" d="M1756 550Q1746 289 1626 134T1306 -21Q1224 -21 1161 14T1063 115Q965 -17 800 -17Q704 -17 632 39T527 200T506 436Q536 686 667 838T988 990Q1135 990 1241 922L1304 880L1253 293Q1236 154 1349 154Q1434 154 1491
-262T1555 540Q1572 874 1417 1056T961 1238Q770 1238 622 1141T387 865T289 458Q273 108 429 -77T897 -263Q981 -263 1075 -244T1228 -198L1265 -364Q1204 -404 1101 -428T893 -453Q620 -453 432 -349T151 -39T69 458Q81 734 196 952T512 1290T965 1410T1400 1306T1675
-1005T1756 550ZM756 436Q745 306 776 240T878 173Q925 173 964 215T1030 335L1070 791Q1040 799 1008 799Q896 799 836 712T756 436Z" />
-<glyph unicode="A" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543Z" />
-<glyph unicode="B" horiz-adv-x="1321" d="M110 0V1456H633Q914 1456 1060 1353T1207 1054Q1207 941 1155 861T1002 743Q1116 713 1177 631T1238 431Q1238 217 1103 110T701 0H110ZM461 619V270H691Q786 270 837 313T888 436Q888 618 707 619H461ZM461 849H644Q759
-850 808 891T857 1012Q857 1104 804 1144T633 1185H461V849Z" />
-<glyph unicode="C" horiz-adv-x="1344" d="M1288 493Q1281 341 1206 225T996 44T686 -20Q399 -20 234 167T69 695V767Q69 981 143 1141T358 1389T682 1477Q947 1477 1108 1338T1291 953H941Q937 1086 874 1144T682 1202Q551 1202 490 1104T426 791V688Q426 455
-484 355T686 255Q807 255 871 312T939 493H1288Z" />
-<glyph unicode="D" horiz-adv-x="1324" d="M110 0V1456H579Q772 1456 926 1369T1166 1122T1254 764V697Q1254 497 1170 339T932 91T589 0H110ZM461 1185V270H583Q734 270 815 377T896 697V760Q896 971 815 1078T579 1185H461Z" />
-<glyph unicode="E" horiz-adv-x="1146" d="M1013 617H461V270H1113V0H110V1456H1115V1185H461V878H1013V617Z" />
-<glyph unicode="F" horiz-adv-x="1120" d="M1027 580H461V0H110V1456H1084V1185H461V850H1027V580Z" />
-<glyph unicode="G" horiz-adv-x="1396" d="M1302 180Q1221 90 1065 35T723 -20Q437 -20 266 155T83 642L82 768Q82 983 158 1143T375 1390T703 1477Q975 1477 1125 1353T1301 981H963Q945 1103 885 1155T715 1207Q583 1207 511 1095T438 775V687Q438 469 512 360T747
-250Q884 250 951 311V537H707V778H1302V180Z" />
-<glyph unicode="H" horiz-adv-x="1439" d="M1327 0H978V608H461V0H110V1456H461V878H978V1456H1327V0Z" />
-<glyph unicode="I" horiz-adv-x="618" d="M484 0H134V1456H484V0Z" />
-<glyph unicode="J" horiz-adv-x="1151" d="M690 1456H1040V457Q1040 318 976 209T796 40T538 -20Q300 -20 168 100T36 440H388Q388 340 422 295T538 250Q611 250 650 304T690 457V1456Z" />
-<glyph unicode="K" horiz-adv-x="1310" d="M605 542L461 384V0H110V1456H461V814L583 999L897 1456H1331L839 812L1331 0H915L605 542Z" />
-<glyph unicode="L" horiz-adv-x="1110" d="M461 270H1072V0H110V1456H461V270Z" />
-<glyph unicode="M" horiz-adv-x="1795" d="M571 1456L896 443L1220 1456H1682V0H1330V340L1364 1036L1012 0H780L427 1037L461 340V0H110V1456H571Z" />
-<glyph unicode="N" horiz-adv-x="1438" d="M1326 0H977L461 906V0H110V1456H461L976 550V1456H1326V0Z" />
-<glyph unicode="O" horiz-adv-x="1414" d="M1343 698Q1343 485 1264 321T1040 69T708 -20T378 65T154 310T69 675V757Q69 971 147 1134T372 1387T706 1476Q891 1476 1036 1388T1261 1138T1343 765V698ZM986 759Q986 976 914 1088T706 1201Q442 1201 427 805L426
-698Q426 484 497 369T708 254Q841 254 913 367T986 692V759Z" />
-<glyph unicode="P" horiz-adv-x="1333" d="M461 494V0H110V1456H691Q858 1456 986 1395T1185 1220T1256 962Q1256 749 1104 622T685 494H461ZM461 765H691Q793 765 846 816T900 960Q900 1062 845 1123T695 1185H461V765Z" />
-<glyph unicode="Q" horiz-adv-x="1414" d="M1345 698Q1345 496 1278 346T1093 104L1328 -82L1111 -266L798 -14Q754 -20 710 -20Q524 -20 380 66T156 312T72 680V757Q72 972 150 1135T374 1387T708 1476Q893 1476 1038 1388T1263 1138T1345 765V698ZM988 759Q988
-976 916 1088T708 1201Q569 1201 499 1090T428 765V698Q428 483 499 369T710 254Q844 254 915 367T988 692V759Z" />
-<glyph unicode="R" horiz-adv-x="1336" d="M651 514H461V0H110V1456H683Q942 1456 1088 1341T1234 1016Q1234 864 1173 764T980 602L1284 15V0H908L651 514ZM461 785H683Q783 785 833 837T884 984T833 1131T683 1185H461V785Z" />
-<glyph unicode="S" horiz-adv-x="1282" d="M861 387Q861 464 807 507T615 596T391 685Q108 824 108 1067Q108 1188 178 1280T378 1424T668 1476Q825 1476 949 1420T1143 1261T1212 1024H862Q862 1113 808 1162T660 1211Q566 1211 512 1170T457 1064Q457 1008 517
-963T728 869T976 764Q1212 628 1212 389Q1212 198 1068 89T673 -20Q496 -20 353 43T137 217T64 472H416Q416 355 476 300T673 244Q760 244 810 281T861 387Z" />
-<glyph unicode="T" horiz-adv-x="1291" d="M1253 1185H816V0H465V1185H36V1456H1253V1185Z" />
-<glyph unicode="U" horiz-adv-x="1361" d="M1252 1456V503Q1252 341 1183 223T985 42T680 -20Q414 -20 261 118T105 496V1456H458V489Q464 250 680 250Q789 250 845 310T901 505V1456H1252Z" />
-<glyph unicode="V" horiz-adv-x="1353" d="M675 396L965 1456H1357L867 0H483L-3 1456H386L675 396Z" />
-<glyph unicode="W" horiz-adv-x="1780" d="M1238 543L1405 1456H1753L1444 0H1080L885 830L694 0H331L21 1456H370L537 543L737 1456H1035L1238 543Z" />
-<glyph unicode="X" horiz-adv-x="1307" d="M653 972L891 1456H1292L885 734L1303 0H898L653 493L408 0H4L421 734L15 1456H415L653 972Z" />
-<glyph unicode="Y" horiz-adv-x="1286" d="M643 824L911 1456H1290L821 523V0H465V523L-3 1456H374L643 824Z" />
-<glyph unicode="Z" horiz-adv-x="1249" d="M504 270H1200V0H66V185L760 1185H62V1456H1193V1276L504 270Z" />
-<glyph unicode="[" horiz-adv-x="577" d="M564 1460H446V-104H564V-349H108V1706H564V1460Z" />
-<glyph unicode="\" horiz-adv-x="873" d="M-20 1456H331L939 -125H586L-20 1456Z" />
-<glyph unicode="]" horiz-adv-x="577" d="M14 1706H470V-349H14V-104H133V1460H14V1706Z" />
-<glyph unicode="^" horiz-adv-x="916" d="M460 1182L289 729H36L335 1456H584L884 729H630L460 1182Z" />
-<glyph unicode="_" horiz-adv-x="904" d="M903 -251H0V0H903V-251Z" />
-<glyph unicode="`" horiz-adv-x="695" d="M610 1222H336L54 1536H410L610 1222Z" />
-<glyph unicode="a" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493 220Q556
-220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220Z" />
-<glyph unicode="b" horiz-adv-x="1153" d="M1099 532Q1099 266 989 123T679 -20Q514 -20 413 111L399 0H97V1536H434V995Q528 1102 677 1102Q879 1102 989 957T1099 549V532ZM761 553Q761 709 720 775T592 842Q478 842 434 755V325Q477 239 594 239Q713 239 745
-355Q761 412 761 553Z" />
-<glyph unicode="c" horiz-adv-x="1064" d="M552 240Q623 240 662 278T700 386H1016Q1016 208 889 94T560 -20Q324 -20 188 128T52 538V552Q52 716 112 841T287 1034T557 1102Q768 1102 892 985T1016 668H700Q700 752 659 797T549 842Q418 842 396 675Q389 622
-389 529Q389 366 428 303T552 240Z" />
-<glyph unicode="d" horiz-adv-x="1152" d="M52 549Q52 806 163 954T473 1102Q618 1102 717 988V1536H1055V0H752L735 116Q631 -20 471 -20Q278 -20 165 128T52 549ZM389 528Q389 240 557 240Q669 240 717 334V746Q671 842 559 842Q403 842 390 590L389 528Z" />
-<glyph unicode="e" horiz-adv-x="1115" d="M618 -20Q369 -20 215 128T61 515V543Q61 709 122 836T302 1032T582 1102Q810 1102 942 961T1074 566V435H404Q422 344 483 292T641 240Q801 240 891 352L1045 170Q982 83 867 32T618 -20ZM580 842Q432 842 404 646H744V672Q746
-753 703 797T580 842Z" />
-<glyph unicode="f" horiz-adv-x="742" d="M169 0V848H12V1082H169V1168Q169 1353 278 1455T584 1557Q656 1557 742 1536L743 1288Q712 1297 660 1297Q507 1297 507 1165V1082H718V848H507V0H169Z" />
-<glyph unicode="g" horiz-adv-x="1178" d="M55 549Q55 713 109 839T264 1033T499 1102Q668 1102 763 988L775 1082H1081V41Q1081 -102 1015 -207T822 -369T530 -426Q411 -426 300 -381T129 -264L270 -66Q364 -177 518 -177Q742 -177 742 53V87Q645 -20 497 -20Q299
--20 177 131T55 537V549ZM393 528Q393 395 443 318T583 240Q692 240 742 313V768Q693 842 585 842Q495 842 444 762T393 528Z" />
-<glyph unicode="h" horiz-adv-x="1156" d="M424 966Q532 1102 700 1102Q879 1102 970 996T1063 683V0H725V675Q725 761 690 801T571 842Q467 842 424 776V0H87V1536H424V966Z" />
-<glyph unicode="i" horiz-adv-x="563" d="M450 0H112V1082H450V0ZM92 1361Q92 1433 144 1479T279 1525T414 1479T466 1361T414 1243T279 1197T144 1243T92 1361Z" />
-<glyph unicode="j" horiz-adv-x="553" d="M457 1082V-37Q456 -229 347 -333T43 -437Q-41 -437 -116 -420V-165Q-58 -174 -21 -174Q119 -174 119 -35V1082H457ZM94 1361Q94 1433 146 1479T281 1525T416 1479T468 1361T416 1243T281 1197T146 1243T94 1361Z" />
-<glyph unicode="k" horiz-adv-x="1120" d="M529 403L434 308V0H97V1537H434V721L468 766L722 1082H1126L747 637L1151 0H765L529 403Z" />
-<glyph unicode="l" horiz-adv-x="563" d="M450 0H112V1536H450V0Z" />
-<glyph unicode="m" horiz-adv-x="1764" d="M413 1082L424 955Q539 1102 733 1102Q938 1102 1010 939Q1120 1102 1328 1102Q1657 1102 1666 704V0H1328V683Q1328 766 1300 804T1198 842Q1098 842 1049 753L1050 739V0H712V681Q712 766 685 804T582 842Q485 842
-434 753V0H97V1082H413Z" />
-<glyph unicode="n" horiz-adv-x="1155" d="M404 1082L415 955Q527 1102 724 1102Q893 1102 976 1001T1063 697V0H725V683Q725 765 692 803T572 842Q473 842 425 764V0H88V1082H404Z" />
-<glyph unicode="o" horiz-adv-x="1150" d="M52 551Q52 713 115 839T296 1034T573 1102Q816 1102 956 952T1096 542V530Q1096 277 956 129T575 -20Q344 -20 204 118T53 494L52 551ZM389 530Q389 380 436 310T575 240Q755 240 759 517V551Q759 842 573 842Q404 842
-390 591L389 530Z" />
-<glyph unicode="p" horiz-adv-x="1153" d="M1099 533Q1099 281 986 131T679 -20Q530 -20 434 89V-416H97V1082H412L422 982Q519 1102 677 1102Q877 1102 988 955T1099 549V533ZM762 554Q762 842 594 842Q474 842 434 756V330Q478 240 596 240Q757 240 762 518V554Z" />
-<glyph unicode="q" horiz-adv-x="1151" d="M52 552Q52 810 164 956T473 1102Q639 1102 739 966L763 1082H1055V-416H717V90Q620 -20 471 -20Q279 -20 166 128T52 552ZM389 531Q389 240 557 240Q673 240 717 328V756Q675 842 559 842Q402 842 390 591L389 531Z" />
-<glyph unicode="r" horiz-adv-x="776" d="M749 777L638 785Q479 785 434 685V0H97V1082H413L424 943Q509 1102 661 1102Q715 1102 755 1090L749 777Z" />
-<glyph unicode="s" horiz-adv-x="1049" d="M661 304Q661 347 616 373T445 427T237 500T112 611T69 760Q69 909 192 1005T514 1102Q728 1102 858 1005T988 750H650Q650 880 513 880Q460 880 424 851T388 777Q388 732 432 704T572 658T742 615Q986 531 986 314Q986
-166 855 73T514 -20Q375 -20 266 30T96 166T35 347H350Q352 272 400 238T523 203Q592 203 626 231T661 304Z" />
-<glyph unicode="t" horiz-adv-x="703" d="M487 1351V1082H665V848H487V353Q487 292 509 268T596 244Q646 244 680 250V9Q589 -20 490 -20Q316 -20 233 62T150 311V848H12V1082H150V1351H487Z" />
-<glyph unicode="u" horiz-adv-x="1155" d="M739 117Q632 -20 450 -20Q272 -20 181 83T89 381V1082H426V379Q426 240 561 240Q677 240 726 323V1082H1065V0H749L739 117Z" />
-<glyph unicode="v" horiz-adv-x="1058" d="M526 401L697 1082H1052L699 0H355L2 1082H358L526 401Z" />
-<glyph unicode="w" horiz-adv-x="1487" d="M1029 444L1138 1082H1461L1206 0H921L742 642L562 0H277L22 1082H345L452 429L624 1082H859L1029 444Z" />
-<glyph unicode="x" horiz-adv-x="1054" d="M533 784L690 1082H1040L755 555L1054 0H702L532 320L365 0H11L311 555L27 1082H381L533 784Z" />
-<glyph unicode="y" horiz-adv-x="1061" d="M527 472L707 1082H1068L627 -181L608 -227Q514 -437 276 -437Q210 -437 137 -417V-176H181Q252 -176 289 -156T345 -82L372 -10L-4 1082H356L527 472Z" />
-<glyph unicode="z" horiz-adv-x="1054" d="M492 260H985V0H66V188L546 822H87V1082H974V900L492 260Z" />
-<glyph unicode="{" horiz-adv-x="665" d="M562 -360Q202 -259 202 105V303Q202 505 40 505V732Q202 732 202 935V1145Q205 1325 295 1436T562 1597L625 1421Q499 1373 494 1152V935Q494 711 309 619Q494 527 494 302V86Q499 -135 625 -183L562 -360Z" />
-<glyph unicode="|" horiz-adv-x="523" d="M356 -270H172V1456H356V-270Z" />
-<glyph unicode="}" horiz-adv-x="665" d="M41 -183Q167 -135 172 86V303Q172 528 358 619Q172 710 172 935V1152Q167 1373 41 1421L104 1597Q283 1547 373 1434T464 1136V935Q464 732 626 732V505Q464 505 464 304V91Q457 -261 104 -360L41 -183Z" />
-<glyph unicode="~" horiz-adv-x="1295" d="M1197 799Q1197 603 1106 485T863 367Q788 367 728 396T591 500T449 576Q399 576 366 527T332 405L94 409Q94 605 183 720T426 836Q502 836 565 807T702 703T840 628Q891 628 923 677T956 800L1197 799Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="510" />
-<glyph unicode="&#xa1;" horiz-adv-x="615" d="M171 623H444L487 -372H128L171 623ZM497 933Q497 859 444 812T310 764T177 811T123 933T176 1054T310 1102T443 1055T497 933Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1209" d="M598 240Q669 240 708 278T746 386H1062Q1062 230 965 124T710 -11V-245H510V-13Q317 15 208 158T98 534V552Q98 776 207 921T510 1095V1318H710V1093Q875 1064 968 952T1062 668H746Q746 752 705 797T595 842Q464
-842 442 675Q435 622 435 529Q435 366 474 303T598 240Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1229" d="M621 561L626 449Q626 335 567 270H1175V0H106V270H209Q266 285 269 373L270 426L265 561H103V822H257L251 1039Q251 1244 373 1359T705 1475Q929 1475 1054 1360T1180 1048H850Q850 1205 714 1205Q663 1205 632
-1165T601 1039L610 822H917V561H621Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1397" d="M1061 107Q902 -20 700 -20Q497 -20 339 106L210 -26L69 118L204 255Q104 411 104 608Q104 812 213 973L69 1120L210 1264L352 1119Q507 1234 700 1234Q894 1234 1049 1117L1193 1265L1335 1120L1187 969Q1294 810
-1294 608Q1294 415 1196 259L1335 118L1193 -27L1061 107ZM290 608Q290 490 344 390T493 231T700 173Q811 173 906 231T1055 389T1109 608Q1109 727 1055 827T906 985T700 1042Q588 1042 494 985T345 828T290 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1108" d="M554 937L741 1456H1098L792 742H997V552H725V452H997V263H725V0H375V263H72V452H375V552H72V742H316L9 1456H367L554 937Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="524" d="M119 -270V525H411V-270H119ZM411 698H119V1456H411V698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1301" d="M1196 500Q1196 323 1041 232Q1179 129 1179 -61Q1179 -238 1038 -337T648 -437Q380 -437 237 -330T94 -25H432Q432 -100 482 -138T648 -176Q841 -176 841 -62Q841 -4 784 32T547 118T277 222T140 351T94 528Q94
-704 251 798Q110 904 110 1090Q110 1264 255 1370T644 1476Q894 1476 1035 1364T1176 1051H839Q839 1126 788 1171T644 1216Q549 1216 499 1183T449 1092Q449 1026 505 992T707 921T939 846T1081 760T1167 648T1196 500ZM597 652Q535 668 480 688Q431 648 431 568Q431
-500 475 465T690 376L808 342Q864 386 864 462Q864 524 809 563T597 652Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="1013" d="M95 1365Q95 1420 138 1459T246 1498T353 1459T397 1365T354 1271T246 1232T139 1271T95 1365ZM614 1365Q614 1420 657 1459T765 1498T872 1459T916 1365T873 1271T765 1232T658 1271T614 1365Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1608" d="M1116 596Q1116 444 1029 363T781 282T527 388T432 675V788Q432 962 527 1068T781 1175Q944 1175 1030 1093T1117 861H961Q961 957 915 998T781 1040Q689 1040 639 973T587 792V669Q587 552 638 485T781 417Q870
-417 915 457T960 596H1116ZM207 729Q207 564 281 421T493 192T795 105Q959 105 1095 191T1307 420T1382 729T1307 1037T1095 1265T795 1351Q636 1351 500 1269T285 1043T207 729ZM85 729Q85 931 178 1104T437 1376T795 1476T1152 1377T1411 1104T1505 729Q1505
-525 1410 352T1151 79T795 -20Q602 -20 438 80T179 353T85 729Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="904" d="M600 705Q590 732 583 773Q506 691 382 691Q264 691 199 752T133 919Q133 1029 217 1089T474 1150H576V1201Q576 1328 460 1328Q395 1328 359 1303T322 1229L149 1243Q149 1347 236 1411T460 1476Q595 1476 673 1404T751
-1199V883Q751 786 777 705H600ZM425 835Q465 835 507 853T576 897V1033H470Q394 1032 351 1002T308 923Q308 835 425 835Z" />
-<glyph unicode="&#xab;" horiz-adv-x="1054" d="M567 515L799 116H593L321 506V525L593 915H799L567 515ZM724 515L956 116H750L478 506V525L750 915H956L724 515Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1124" d="M960 374H760V634H125V805H960V374Z" />
-<glyph unicode="&#xad;" horiz-adv-x="921" d="M753 497H152V758H753V497Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1608" d="M85 729Q85 931 178 1104T437 1376T795 1476T1152 1377T1411 1104T1505 729Q1505 525 1410 352T1151 79T795 -20Q602 -20 438 80T179 353T85 729ZM207 729Q207 564 281 421T493 192T795 105Q959 105 1095 191T1307
-420T1382 729T1307 1037T1095 1265T795 1351Q636 1351 500 1269T285 1043T207 729ZM651 653V316H500V1166H781Q935 1166 1020 1096T1106 902Q1106 792 999 732Q1057 700 1080 644T1103 506T1106 389T1120 332V316H965Q952 350 952 510Q952 586 919 619T809 653H651ZM651
-787H779Q855 787 905 818T956 903Q956 973 921 1002T792 1033H651V787Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="1065" d="M875 1285H181V1458H875V1285Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="813" d="M125 1195Q125 1312 208 1394T406 1476Q518 1476 599 1394T681 1195Q681 1079 601 999T406 918Q290 918 208 998T125 1195ZM406 1071Q459 1071 493 1107T527 1195T493 1285T406 1323T317 1286T280 1195T317 1107T406 1071Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1102" d="M688 974H1000V703H688V355H394V703H84V974H394V1293H688V974ZM979 1H101V265H979V1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="768" d="M697 667H69V814L355 1067Q405 1111 429 1153T454 1216Q454 1292 369 1292Q326 1292 301 1262T276 1189H51Q51 1307 136 1387T358 1468Q512 1468 595 1403T678 1216Q678 1141 636 1079T448 910L367 842H697V667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="768" d="M277 1141H365Q466 1141 466 1223Q466 1255 441 1273T370 1292Q335 1292 308 1279T281 1241H57Q57 1343 142 1405T363 1468Q517 1468 603 1407T690 1241Q690 1121 552 1072Q706 1031 706 889Q706 785 612 721T363
-656Q218 656 130 725T41 908H268Q268 879 297 856T379 832Q435 832 457 857T480 913Q480 998 371 999H277V1141Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="691" d="M287 1536H643L365 1222H90L287 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1313" d="M470 1082V450Q471 343 506 293T633 243Q761 243 814 334V1082H1151V0H834L829 53Q740 -21 619 -21Q534 -21 470 13V-416H132V1082H470Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="1001" d="M657 0V520H577Q347 520 215 647T82 988Q82 1201 215 1328T578 1456H886V0H657Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="657" d="M324 854Q405 854 457 806T510 685T458 564T324 516Q244 516 191 563T138 685T191 806T324 854Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="569" d="M373 10L363 -51Q513 -79 513 -224Q513 -340 414 -406T139 -472L132 -286Q220 -286 220 -209Q220 -171 189 -156T86 -136L117 10H373Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="768" d="M542 667H319V1200L143 1164V1331L523 1453H542V667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="938" d="M117 1121Q117 1281 212 1378T463 1476T714 1379T810 1116V1044Q810 885 716 788T465 690Q307 690 212 788T117 1049V1121ZM292 1044Q292 946 338 891T465 836Q543 836 588 890T635 1041V1121Q635 1218 589 1273T463
-1328Q385 1328 339 1274T292 1117V1044Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="1054" d="M284 914L556 524V505L284 115H77L309 514L77 914H284ZM697 914L969 524V505L697 115H490L722 514L490 914H697Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1452" d="M512 664H289V1197L113 1161V1328L493 1450H512V664ZM462 117L305 196L1016 1334L1173 1255L462 117ZM1288 335H1367V157H1288V0H1063V157H730L715 302L1063 789H1288V335ZM925 335H1063V526L1047 503L925 335Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1537" d="M422 117L265 196L976 1334L1133 1255L422 117ZM488 672H265V1205L89 1169V1336L469 1458H488V672ZM1470 0H842V147L1128 400Q1178 444 1202 486T1227 549Q1227 625 1142 625Q1099 625 1074 595T1049 522H824Q824
-640 909 720T1131 801Q1285 801 1368 736T1451 549Q1451 474 1409 412T1221 243L1140 175H1470V0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1689" d="M644 117L487 196L1198 1334L1355 1255L644 117ZM1486 335H1565V157H1486V0H1261V157H928L913 302L1261 789H1486V335ZM1123 335H1261V526L1245 503L1123 335ZM321 1141H409Q510 1141 510 1223Q510 1255 485 1273T414
-1292Q379 1292 352 1279T325 1241H101Q101 1343 186 1405T407 1468Q561 1468 647 1407T734 1241Q734 1121 596 1072Q750 1031 750 889Q750 785 656 721T407 656Q262 656 174 725T85 908H312Q312 879 341 856T423 832Q479 832 501 857T524 913Q524 998 415 999H321V1141Z"
-/>
-<glyph unicode="&#xbf;" horiz-adv-x="1043" d="M703 630Q703 480 673 400T570 258L504 197Q411 107 411 11Q411 -60 444 -92T531 -125Q598 -125 635 -83T675 38H1014Q1010 -163 887 -274T539 -385Q316 -385 195 -282T73 11Q73 94 111 167T241 327L326 405Q403
-471 412 558L417 630H703ZM569 765Q489 765 436 812T382 934T435 1055T569 1103Q651 1103 703 1055T756 934T704 814T569 765Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543ZM860 1532H586L304 1846H660L860 1532Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543ZM742 1846H1098L820 1532H545L742 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543ZM1124 1565V1552H858L699 1688L540 1552H280V1569L603 1846H796L1124 1565Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543ZM1085 1837Q1085 1723 1019 1644T854 1564Q788 1564 707 1606T576 1648Q544 1648 522 1626T499 1558L312 1568Q312 1679
-378 1760T542 1841Q592 1841 673 1805T775 1763T821 1758Q853 1758 876 1780T899 1848L1085 1837Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543ZM287 1675Q287 1730 330 1769T438 1808T545 1769T589 1675T546 1581T438 1542T331 1581T287 1675ZM806 1675Q806 1730
-849 1769T957 1808T1064 1769T1108 1675T1065 1581T957 1542T850 1581T806 1675Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1395" d="M937 272H456L372 0H-3L531 1456H861L1399 0H1022L937 272ZM540 543H853L696 1048L540 543ZM477 1729Q477 1815 542 1873T702 1932Q795 1932 860 1874T926 1729Q926 1644 862 1587T702 1530Q606 1530 542 1587T477
-1729ZM702 1625Q750 1625 777 1655T805 1729T778 1804T702 1835Q653 1835 626 1804T598 1729T625 1655T702 1625Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1926" d="M1851 0H954L940 329H558L406 0H16L751 1456H1790V1192H1241L1254 876H1709V612H1265L1280 264H1851V0ZM683 599H929L908 1085L683 599Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1344" d="M1288 493Q1281 341 1206 225T996 44T686 -20Q399 -20 234 167T69 695V767Q69 981 143 1141T358 1389T682 1477Q947 1477 1108 1338T1291 953H941Q937 1086 874 1144T682 1202Q551 1202 490 1104T426 791V688Q426
-455 484 355T686 255Q807 255 871 312T939 493H1288ZM818 10L808 -51Q958 -79 958 -224Q958 -340 859 -406T584 -472L577 -286Q665 -286 665 -209Q665 -171 634 -156T531 -136L562 10H818Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1146" d="M1013 617H461V270H1113V0H110V1456H1115V1185H461V878H1013V617ZM804 1532H530L248 1846H604L804 1532Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1146" d="M1013 617H461V270H1113V0H110V1456H1115V1185H461V878H1013V617ZM686 1846H1042L764 1532H489L686 1846Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1146" d="M1013 617H461V270H1113V0H110V1456H1115V1185H461V878H1013V617ZM1068 1565V1552H802L643 1688L484 1552H224V1569L547 1846H740L1068 1565Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1146" d="M1013 617H461V270H1113V0H110V1456H1115V1185H461V878H1013V617ZM231 1675Q231 1730 274 1769T382 1808T489 1769T533 1675T490 1581T382 1542T275 1581T231 1675ZM750 1675Q750 1730 793 1769T901 1808T1008 1769T1052
-1675T1009 1581T901 1542T794 1581T750 1675Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="618" d="M484 0H134V1456H484V0ZM470 1532H196L-86 1846H270L470 1532Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="618" d="M484 0H134V1456H484V0ZM351 1846H707L429 1532H154L351 1846Z" />
-<glyph unicode="&#xce;" horiz-adv-x="618" d="M484 0H134V1456H484V0ZM734 1565V1552H468L309 1688L150 1552H-110V1569L213 1846H406L734 1565Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="618" d="M484 0H134V1456H484V0ZM-103 1675Q-103 1730 -60 1769T48 1808T155 1769T199 1675T156 1581T48 1542T-59 1581T-103 1675ZM416 1675Q416 1730 459 1769T567 1808T674 1769T718 1675T675 1581T567 1542T460 1581T416 1675Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1354" d="M140 0V635H-30V826H140V1456H609Q802 1456 956 1369T1196 1122T1284 764V697Q1284 497 1200 339T962 91T619 0H140ZM700 635H491V270H613Q764 270 845 377T926 697V760Q926 971 845 1078T609 1185H491V826H700V635Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1438" d="M1326 0H977L461 906V0H110V1456H461L976 550V1456H1326V0ZM1112 1837Q1112 1723 1046 1644T881 1564Q815 1564 734 1606T603 1648Q571 1648 549 1626T526 1558L339 1568Q339 1679 405 1760T569 1841Q619 1841 700
-1805T802 1763T848 1758Q880 1758 903 1780T926 1848L1112 1837Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1414" d="M1343 698Q1343 485 1264 321T1040 69T708 -20T378 65T154 310T69 675V757Q69 971 147 1134T372 1387T706 1476Q891 1476 1036 1388T1261 1138T1343 765V698ZM986 759Q986 976 914 1088T706 1201Q442 1201 427 805L426
-698Q426 484 497 369T708 254Q841 254 913 367T986 692V759ZM865 1532H591L309 1846H665L865 1532Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1414" d="M1343 698Q1343 485 1264 321T1040 69T708 -20T378 65T154 310T69 675V757Q69 971 147 1134T372 1387T706 1476Q891 1476 1036 1388T1261 1138T1343 765V698ZM986 759Q986 976 914 1088T706 1201Q442 1201 427 805L426
-698Q426 484 497 369T708 254Q841 254 913 367T986 692V759ZM747 1846H1103L825 1532H550L747 1846Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1414" d="M1343 698Q1343 485 1264 321T1040 69T708 -20T378 65T154 310T69 675V757Q69 971 147 1134T372 1387T706 1476Q891 1476 1036 1388T1261 1138T1343 765V698ZM986 759Q986 976 914 1088T706 1201Q442 1201 427 805L426
-698Q426 484 497 369T708 254Q841 254 913 367T986 692V759ZM1129 1565V1552H863L704 1688L545 1552H285V1569L608 1846H801L1129 1565Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1414" d="M1343 698Q1343 485 1264 321T1040 69T708 -20T378 65T154 310T69 675V757Q69 971 147 1134T372 1387T706 1476Q891 1476 1036 1388T1261 1138T1343 765V698ZM986 759Q986 976 914 1088T706 1201Q442 1201 427 805L426
-698Q426 484 497 369T708 254Q841 254 913 367T986 692V759ZM1090 1837Q1090 1723 1024 1644T859 1564Q793 1564 712 1606T581 1648Q549 1648 527 1626T504 1558L317 1568Q317 1679 383 1760T547 1841Q597 1841 678 1805T780 1763T826 1758Q858 1758 881 1780T904
-1848L1090 1837Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1414" d="M1343 698Q1343 485 1264 321T1040 69T708 -20T378 65T154 310T69 675V757Q69 971 147 1134T372 1387T706 1476Q891 1476 1036 1388T1261 1138T1343 765V698ZM986 759Q986 976 914 1088T706 1201Q442 1201 427 805L426
-698Q426 484 497 369T708 254Q841 254 913 367T986 692V759ZM292 1675Q292 1730 335 1769T443 1808T550 1769T594 1675T551 1581T443 1542T336 1581T292 1675ZM811 1675Q811 1730 854 1769T962 1808T1069 1769T1113 1675T1070 1581T962 1542T855 1581T811 1675Z"
-/>
-<glyph unicode="&#xd7;" horiz-adv-x="1083" d="M53 381L352 686L53 992L246 1175L539 876L832 1175L1025 992L725 686L1025 381L832 198L539 496L246 198L53 381Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1409" d="M1354 698Q1354 485 1275 321T1051 69T719 -20Q557 -20 427 45L346 -95H139L280 150Q81 349 81 706V757Q81 972 159 1135T383 1387T717 1476Q874 1476 1004 1412L1065 1518H1273L1152 1307Q1354 1107 1354 749V698ZM997
-759Q997 892 968 988L572 299Q632 254 719 254Q853 254 924 367T997 692V759ZM437 698Q437 565 464 471L858 1158Q798 1201 717 1201Q578 1201 508 1090T437 765V698Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1361" d="M1252 1456V503Q1252 341 1183 223T985 42T680 -20Q414 -20 261 118T105 496V1456H458V489Q464 250 680 250Q789 250 845 310T901 505V1456H1252ZM835 1532H561L279 1846H635L835 1532Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1361" d="M1252 1456V503Q1252 341 1183 223T985 42T680 -20Q414 -20 261 118T105 496V1456H458V489Q464 250 680 250Q789 250 845 310T901 505V1456H1252ZM717 1846H1073L795 1532H520L717 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1361" d="M1252 1456V503Q1252 341 1183 223T985 42T680 -20Q414 -20 261 118T105 496V1456H458V489Q464 250 680 250Q789 250 845 310T901 505V1456H1252ZM1099 1565V1552H833L674 1688L515 1552H255V1569L578 1846H771L1099 1565Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1361" d="M1252 1456V503Q1252 341 1183 223T985 42T680 -20Q414 -20 261 118T105 496V1456H458V489Q464 250 680 250Q789 250 845 310T901 505V1456H1252ZM262 1675Q262 1730 305 1769T413 1808T520 1769T564 1675T521 1581T413
-1542T306 1581T262 1675ZM781 1675Q781 1730 824 1769T932 1808T1039 1769T1083 1675T1040 1581T932 1542T825 1581T781 1675Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1286" d="M643 824L911 1456H1290L821 523V0H465V523L-3 1456H374L643 824ZM686 1846H1042L764 1532H489L686 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1266" d="M455 1456V1198H660Q831 1197 956 1140T1148 979T1214 738Q1214 529 1066 405T660 278H455V0H116V1456H455ZM455 938V538H653Q756 538 815 590T875 736Q875 831 816 884T655 938H455Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1330" d="M472 0H134V1099Q134 1320 267 1440T648 1561Q844 1561 967 1457T1090 1181Q1090 1074 1043 998T995 835Q995 804 1019 771T1128 656Q1271 517 1271 368Q1271 181 1147 81T794 -20Q719 -20 644 -7T526 31L585 284Q670
-240 796 240Q856 240 895 272T935 365Q935 406 910 442T805 547T692 679T658 817Q658 920 705 1004T752 1167Q752 1226 712 1264T611 1302Q537 1302 505 1250T472 1094V0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493
-220Q556 220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220ZM695 1222H421L139 1536H495L695 1222Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493
-220Q556 220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220ZM577 1536H933L655 1222H380L577 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493
-220Q556 220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220ZM959 1255V1242H693L534 1378L375 1242H115V1259L438 1536H631L959 1255Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493
-220Q556 220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220ZM920 1784Q920 1670 854 1591T689 1511Q623 1511 542 1553T411 1595Q379 1595 357 1573T334 1505L147 1515Q147 1626 213 1707T377 1788Q427 1788 508 1752T610 1710T656 1705Q688
-1705 711 1727T734 1795L920 1784Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493
-220Q556 220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220ZM122 1365Q122 1420 165 1459T273 1498T380 1459T424 1365T381 1271T273 1232T166 1271T122 1365ZM641 1365Q641 1420 684 1459T792 1498T899 1459T943 1365T900 1271T792 1232T685
-1271T641 1365Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1087" d="M704 0Q686 33 672 97Q579 -20 412 -20Q259 -20 152 72T45 305Q45 481 175 571T553 661H657V718Q657 867 528 867Q408 867 408 749H71Q71 906 204 1004T545 1102T872 1001T995 724V245Q997 96 1041 17V0H704ZM493
-220Q556 220 597 247T657 308V481H559Q383 481 383 323Q383 277 414 249T493 220ZM312 1419Q312 1505 377 1563T537 1622Q630 1622 695 1564T761 1419Q761 1334 697 1277T537 1220Q441 1220 377 1277T312 1419ZM537 1315Q585 1315 612 1345T640 1419T613 1494T537
-1525Q488 1525 461 1494T433 1419T460 1345T537 1315Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1730" d="M1238 -20Q998 -20 858 114Q792 48 694 14T484 -20Q285 -20 173 71T61 324Q61 482 190 568T575 655H717V701Q717 767 683 804T584 842Q512 842 474 813T436 740L99 759Q99 910 233 1006T588 1102Q790 1102 907 1011Q1033
-1104 1227 1102Q1439 1102 1562 969T1685 609V435H1046Q1060 337 1121 289T1284 240Q1410 240 1507 280L1569 307L1650 101Q1583 49 1469 15T1238 -20ZM548 212Q637 212 717 275V451H578Q500 450 449 414T398 320Q398 212 548 212ZM1227 842Q1145 842 1102 794T1047
-646H1356V672Q1356 753 1323 797T1227 842Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1064" d="M552 240Q623 240 662 278T700 386H1016Q1016 208 889 94T560 -20Q324 -20 188 128T52 538V552Q52 716 112 841T287 1034T557 1102Q768 1102 892 985T1016 668H700Q700 752 659 797T549 842Q418 842 396 675Q389
-622 389 529Q389 366 428 303T552 240ZM698 10L688 -51Q838 -79 838 -224Q838 -340 739 -406T464 -472L457 -286Q545 -286 545 -209Q545 -171 514 -156T411 -136L442 10H698Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1115" d="M618 -20Q369 -20 215 128T61 515V543Q61 709 122 836T302 1032T582 1102Q810 1102 942 961T1074 566V435H404Q422 344 483 292T641 240Q801 240 891 352L1045 170Q982 83 867 32T618 -20ZM580 842Q432 842 404
-646H744V672Q746 753 703 797T580 842ZM694 1223H420L138 1537H494L694 1223Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1115" d="M618 -20Q369 -20 215 128T61 515V543Q61 709 122 836T302 1032T582 1102Q810 1102 942 961T1074 566V435H404Q422 344 483 292T641 240Q801 240 891 352L1045 170Q982 83 867 32T618 -20ZM580 842Q432 842 404
-646H744V672Q746 753 703 797T580 842ZM576 1537H932L654 1223H379L576 1537Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1115" d="M618 -20Q369 -20 215 128T61 515V543Q61 709 122 836T302 1032T582 1102Q810 1102 942 961T1074 566V435H404Q422 344 483 292T641 240Q801 240 891 352L1045 170Q982 83 867 32T618 -20ZM580 842Q432 842 404
-646H744V672Q746 753 703 797T580 842ZM958 1256V1243H692L533 1379L374 1243H114V1260L437 1537H630L958 1256Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1115" d="M618 -20Q369 -20 215 128T61 515V543Q61 709 122 836T302 1032T582 1102Q810 1102 942 961T1074 566V435H404Q422 344 483 292T641 240Q801 240 891 352L1045 170Q982 83 867 32T618 -20ZM580 842Q432 842 404
-646H744V672Q746 753 703 797T580 842ZM121 1366Q121 1421 164 1460T272 1499T379 1460T423 1366T380 1272T272 1233T165 1272T121 1366ZM640 1366Q640 1421 683 1460T791 1499T898 1460T942 1366T899 1272T791 1233T684 1272T640 1366Z" />
-<glyph unicode="&#xec;" horiz-adv-x="584" d="M462 0H123V1082H462V0ZM455 1202H181L-101 1516H255L455 1202Z" />
-<glyph unicode="&#xed;" horiz-adv-x="584" d="M462 0H123V1082H462V0ZM336 1772H692L414 1458H139L336 1772Z" />
-<glyph unicode="&#xee;" horiz-adv-x="584" d="M462 0H123V1082H462V0ZM719 1235V1222H453L294 1358L135 1222H-125V1239L198 1516H391L719 1235Z" />
-<glyph unicode="&#xef;" horiz-adv-x="584" d="M462 0H123V1082H462V0ZM-118 1345Q-118 1400 -75 1439T33 1478T140 1439T184 1345T141 1251T33 1212T-74 1251T-118 1345ZM401 1345Q401 1400 444 1439T552 1478T659 1439T703 1345T660 1251T552 1212T445 1251T401 1345Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1165" d="M862 1308Q1123 1049 1123 650V593Q1123 416 1053 275T858 57T581 -20Q433 -20 314 43T130 219T64 468Q64 701 184 831T518 961Q645 961 746 899Q697 1038 590 1140L412 1030L334 1148L470 1232Q362 1298 226 1335L334
-1579Q570 1531 749 1403L912 1504L989 1386L862 1308ZM585 240Q679 240 732 322T785 557V654Q719 720 591 720Q493 720 448 653T402 468Q402 366 452 303T585 240Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1155" d="M404 1082L415 955Q527 1102 724 1102Q893 1102 976 1001T1063 697V0H725V683Q725 765 692 803T572 842Q473 842 425 764V0H88V1082H404ZM963 1784Q963 1670 897 1591T732 1511Q666 1511 585 1553T454 1595Q422
-1595 400 1573T377 1505L190 1515Q190 1626 256 1707T420 1788Q470 1788 551 1752T653 1710T699 1705Q731 1705 754 1727T777 1795L963 1784Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1150" d="M52 551Q52 713 115 839T296 1034T573 1102Q816 1102 956 952T1096 542V530Q1096 277 956 129T575 -20Q344 -20 204 118T53 494L52 551ZM389 530Q389 380 436 310T575 240Q755 240 759 517V551Q759 842 573 842Q404
-842 390 591L389 530ZM737 1222H463L181 1536H537L737 1222Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1150" d="M52 551Q52 713 115 839T296 1034T573 1102Q816 1102 956 952T1096 542V530Q1096 277 956 129T575 -20Q344 -20 204 118T53 494L52 551ZM389 530Q389 380 436 310T575 240Q755 240 759 517V551Q759 842 573 842Q404
-842 390 591L389 530ZM619 1536H975L697 1222H422L619 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1150" d="M52 551Q52 713 115 839T296 1034T573 1102Q816 1102 956 952T1096 542V530Q1096 277 956 129T575 -20Q344 -20 204 118T53 494L52 551ZM389 530Q389 380 436 310T575 240Q755 240 759 517V551Q759 842 573 842Q404
-842 390 591L389 530ZM1001 1255V1242H735L576 1378L417 1242H157V1259L480 1536H673L1001 1255Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1150" d="M52 551Q52 713 115 839T296 1034T573 1102Q816 1102 956 952T1096 542V530Q1096 277 956 129T575 -20Q344 -20 204 118T53 494L52 551ZM389 530Q389 380 436 310T575 240Q755 240 759 517V551Q759 842 573 842Q404
-842 390 591L389 530ZM962 1784Q962 1670 896 1591T731 1511Q665 1511 584 1553T453 1595Q421 1595 399 1573T376 1505L189 1515Q189 1626 255 1707T419 1788Q469 1788 550 1752T652 1710T698 1705Q730 1705 753 1727T776 1795L962 1784Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1150" d="M52 551Q52 713 115 839T296 1034T573 1102Q816 1102 956 952T1096 542V530Q1096 277 956 129T575 -20Q344 -20 204 118T53 494L52 551ZM389 530Q389 380 436 310T575 240Q755 240 759 517V551Q759 842 573 842Q404
-842 390 591L389 530ZM164 1365Q164 1420 207 1459T315 1498T422 1459T466 1365T423 1271T315 1232T208 1271T164 1365ZM683 1365Q683 1420 726 1459T834 1498T941 1459T985 1365T942 1271T834 1232T727 1271T683 1365Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1166" d="M1103 563H59V807H1103V563ZM394 1086Q394 1157 445 1203T580 1250T715 1204T766 1086T715 969T580 922T445 968T394 1086ZM394 277Q394 348 445 394T580 441T715 395T766 277T715 160T580 113T445 159T394 277Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1151" d="M52 551Q52 713 115 839T296 1034T573 1102Q667 1102 750 1077L819 1219H996L893 1007Q1096 859 1096 530Q1096 277 956 129T575 -20Q482 -20 404 2L333 -145H156L260 70Q52 217 52 551ZM389 530Q389 434 407 373L631
-833Q605 842 573 842Q404 842 390 591L389 530ZM759 551Q759 636 742 698L523 246Q545 240 575 240Q755 240 759 517V551Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1155" d="M739 117Q632 -20 450 -20Q272 -20 181 83T89 381V1082H426V379Q426 240 561 240Q677 240 726 323V1082H1065V0H749L739 117ZM737 1222H463L181 1536H537L737 1222Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1155" d="M739 117Q632 -20 450 -20Q272 -20 181 83T89 381V1082H426V379Q426 240 561 240Q677 240 726 323V1082H1065V0H749L739 117ZM619 1536H975L697 1222H422L619 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1155" d="M739 117Q632 -20 450 -20Q272 -20 181 83T89 381V1082H426V379Q426 240 561 240Q677 240 726 323V1082H1065V0H749L739 117ZM1001 1255V1242H735L576 1378L417 1242H157V1259L480 1536H673L1001 1255Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1155" d="M739 117Q632 -20 450 -20Q272 -20 181 83T89 381V1082H426V379Q426 240 561 240Q677 240 726 323V1082H1065V0H749L739 117ZM164 1365Q164 1420 207 1459T315 1498T422 1459T466 1365T423 1271T315 1232T208 1271T164
-1365ZM683 1365Q683 1420 726 1459T834 1498T941 1459T985 1365T942 1271T834 1232T727 1271T683 1365Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="1061" d="M527 472L707 1082H1068L627 -181L608 -227Q514 -437 276 -437Q210 -437 137 -417V-176H181Q252 -176 289 -156T345 -82L372 -10L-4 1082H356L527 472ZM571 1536H927L649 1222H374L571 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1148" d="M1096 533Q1096 282 984 131T677 -20Q527 -20 433 87V-416H95V1536H433V997Q527 1102 675 1102Q872 1102 984 957T1096 550V533ZM759 554Q759 842 591 842Q475 842 433 758V327Q476 240 593 240Q754 240 759 516V554Z" />
-<glyph unicode="&#xff;" horiz-adv-x="1061" d="M527 472L707 1082H1068L627 -181L608 -227Q514 -437 276 -437Q210 -437 137 -417V-176H181Q252 -176 289 -156T345 -82L372 -10L-4 1082H356L527 472ZM116 1365Q116 1420 159 1459T267 1498T374 1459T418 1365T375
-1271T267 1232T160 1271T116 1365ZM635 1365Q635 1420 678 1459T786 1498T893 1459T937 1365T894 1271T786 1232T679 1271T635 1365Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1266" d="M1458 578H403V842H1458V578Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1541" d="M1493 578H87V842H1493V578Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="511" d="M291 1576L439 1496Q357 1348 354 1219V1042H108V1207Q109 1298 162 1402T291 1576Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="497" d="M214 1000L66 1080Q149 1224 151 1362V1536H397V1373Q397 1280 344 1175T214 1000Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="556" d="M231 -310L83 -230Q155 -105 157 50V249H415L414 59Q413 -32 360 -136T231 -310Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="875" d="M298 1576L446 1496Q364 1348 361 1219V1042H115V1207Q116 1298 169 1402T298 1576ZM649 1576L797 1496Q715 1348 712 1219V1042H466V1207Q467 1298 520 1402T649 1576Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="881" d="M228 1000L80 1080Q163 1224 165 1362V1536H411V1373Q411 1280 358 1175T228 1000ZM590 1000L442 1080Q525 1224 527 1362V1536H773V1373Q773 1280 720 1175T590 1000Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="876" d="M242 -330L83 -250Q155 -116 157 49V269H415L414 62Q414 -35 366 -145T242 -330ZM593 -330L433 -250Q515 -97 518 47V269H777L776 56Q774 -40 722 -148T593 -330Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="757" d="M134 763Q134 870 204 937T386 1004Q501 1004 570 939T641 768V726Q641 619 572 554T388 488Q275 488 206 552T134 721V763Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="650" d="M354 515L586 116H380L108 506V525L380 915H586L354 515Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="620" d="M283 914L555 524V505L283 115H76L308 514L76 914H283Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-900.ttf b/static/fonts/roboto-v18-latin-900.ttf
deleted file mode 100644
index 168ba8a4cc..0000000000
Binary files a/static/fonts/roboto-v18-latin-900.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900.woff b/static/fonts/roboto-v18-latin-900.woff
deleted file mode 100644
index 9109f3506a..0000000000
Binary files a/static/fonts/roboto-v18-latin-900.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900.woff2 b/static/fonts/roboto-v18-latin-900.woff2
deleted file mode 100644
index 442456790e..0000000000
Binary files a/static/fonts/roboto-v18-latin-900.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900italic.eot b/static/fonts/roboto-v18-latin-900italic.eot
deleted file mode 100644
index 5b5e780848..0000000000
Binary files a/static/fonts/roboto-v18-latin-900italic.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900italic.svg b/static/fonts/roboto-v18-latin-900italic.svg
deleted file mode 100644
index f8f5ab39e3..0000000000
--- a/static/fonts/roboto-v18-latin-900italic.svg
+++ /dev/null
@@ -1,324 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1181" ><font-face
-    font-family="Roboto Black"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="505" />
-<glyph unicode="!" horiz-adv-x="558" d="M395 461H128L259 1456H609L395 461ZM23 145Q21 218 74 269T205 321Q282 321 333 274T386 157Q388 82 335 32T204 -19Q129 -19 77 27T23 145Z" />
-<glyph unicode="&quot;" horiz-adv-x="640" d="M371 1382L266 969H81L170 1537H395L371 1382ZM711 1382L606 969H423L512 1537H736L711 1382Z" />
-<glyph unicode="#" horiz-adv-x="1164" d="M557 410H409L272 0H71L208 410H-5L27 593H268L357 857H145L178 1040H418L557 1456H757L618 1040H767L906 1456H1107L968 1040H1189L1157 857H908L819 593H1038L1006 410H758L622 0H421L557 410ZM469 593H617L707 857H558L469
-593Z" />
-<glyph unicode="$" horiz-adv-x="1160" d="M710 394Q719 463 691 509T585 594T437 674T314 768T232 892T208 1061Q219 1236 344 1345T669 1473L709 1685H866L824 1467Q978 1437 1063 1315T1144 1005L814 1006Q818 1122 788 1171T696 1222Q629 1222 585 1175T533
-1059Q525 996 554 951T660 866T806 785T928 688T1010 563T1034 395Q1023 221 905 113T587 -16L548 -218H392L432 -14Q251 10 152 137T58 468L386 467Q381 354 420 295T540 235Q606 235 652 277T710 394Z" />
-<glyph unicode="%" horiz-adv-x="1484" d="M529 1477Q664 1475 744 1393T816 1176L811 1109Q800 967 706 883T468 800Q335 802 254 884T179 1099L185 1174Q197 1311 292 1395T529 1477ZM391 1097Q386 1044 407 1013T471 981Q516 979 550 1011T595 1099L606 1177Q616
-1292 527 1296Q482 1298 446 1264T401 1176L391 1097ZM1058 658Q1193 656 1274 574T1347 357L1341 280Q1327 139 1232 57T998 -21Q867 -19 785 62T709 280L715 358Q723 448 769 517T890 623T1058 658ZM920 276Q918 228 939 196T1001 161Q1109 157 1128 293L1137
-359Q1142 410 1122 442T1057 476Q1010 478 974 443T930 357L920 276ZM396 111L242 198L1120 1323L1273 1237L396 111Z" />
-<glyph unicode="&amp;" horiz-adv-x="1349" d="M329 770L302 834Q246 970 254 1077Q262 1192 321 1285T480 1429T695 1477Q793 1474 872 1429T994 1306T1032 1135Q1021 940 791 793L697 733L865 486Q944 604 960 729H1234Q1215 441 1035 251L1206 0H858L808 75Q627
--24 439 -20Q314 -17 215 35T65 177T22 384Q36 612 329 770ZM474 240Q540 237 651 282L457 578L444 571Q370 485 360 405Q351 335 383 289T474 240ZM531 1082Q522 1016 573 919L642 959Q747 1024 757 1111Q762 1153 741 1185T674 1218Q623 1220 582 1181T531 1082Z"
-/>
-<glyph unicode="&apos;" horiz-adv-x="317" d="M394 1358L301 961H97L187 1536H422L394 1358Z" />
-<glyph unicode="(" horiz-adv-x="711" d="M749 1608L800 1438Q607 1294 498 1039T356 371L351 273Q336 -136 527 -284L455 -450Q334 -389 251 -270T131 22T100 380Q109 657 192 917T417 1356T749 1608Z" />
-<glyph unicode=")" horiz-adv-x="709" d="M603 569Q571 329 478 114T249 -246T-51 -452L-102 -282Q91 -134 200 121T342 786L348 884Q358 1295 171 1440L244 1606Q418 1521 514 1323T618 841L619 778Q617 682 606 597L603 569Z" />
-<glyph unicode="*" horiz-adv-x="933" d="M398 963L99 1052L190 1231L485 1097L523 1456H732L646 1106L960 1229L991 1028L653 938L823 667L648 558L521 853L295 573L134 696L398 963Z" />
-<glyph unicode="+" horiz-adv-x="1071" d="M721 826H1052L1002 537H672L603 146H296L364 537H32L82 826H414L480 1206H787L721 826Z" />
-<glyph unicode="," horiz-adv-x="545" d="M52 -391L-113 -312L-21 -149Q31 -54 44 21L85 254H349L314 46Q269 -221 52 -391Z" />
-<glyph unicode="-" horiz-adv-x="903" d="M714 497H129L174 758H759L714 497Z" />
-<glyph unicode="." horiz-adv-x="610" d="M38 152Q36 228 90 278T219 328Q293 328 345 283T399 164Q401 89 348 39T218 -12Q142 -12 91 34T38 152Z" />
-<glyph unicode="/" horiz-adv-x="707" d="M85 -125H-160L596 1456H842L85 -125Z" />
-<glyph unicode="0" horiz-adv-x="1160" d="M491 -20Q367 -17 275 38T132 201T78 446Q75 520 84 595L122 849Q168 1156 319 1318T704 1476Q894 1472 1001 1348T1117 1010Q1119 936 1110 861L1070 602Q1022 291 872 133T491 -20ZM788 906Q797 976 798 1029Q798 1212
-682 1218Q504 1227 461 913L408 553Q398 470 398 430Q393 245 513 238Q694 229 736 551L788 906Z" />
-<glyph unicode="1" horiz-adv-x="1160" d="M708 0H378L564 1070L225 974L271 1241L915 1456L952 1457L708 0Z" />
-<glyph unicode="2" horiz-adv-x="1160" d="M979 0H-8L28 232L546 713L617 784Q784 952 770 1101Q759 1217 650 1220Q573 1222 520 1158T453 989L126 987Q134 1124 209 1237T409 1415T677 1478Q890 1474 1007 1363T1109 1061Q1100 949 1036 843T848 620L696 480L470
-262L1020 260L979 0Z" />
-<glyph unicode="3" horiz-adv-x="1160" d="M426 869L573 868Q663 870 721 920T790 1062Q798 1130 763 1174T658 1219Q593 1221 543 1183T479 1082L149 1080Q155 1198 225 1289T411 1429T662 1478Q882 1473 1008 1363T1123 1068Q1110 862 854 742Q951 694 999 609T1042
-417Q1035 283 957 184T748 31T467 -20Q336 -19 230 35T66 186T10 406H338Q339 335 380 289T495 241Q578 239 642 290T718 424Q730 513 692 563T563 617L387 618L426 869Z" />
-<glyph unicode="4" horiz-adv-x="1160" d="M946 569H1089L1044 309H901L847 0H518L572 309H27L45 531L760 1453V1460L1100 1455L946 569ZM369 571L617 569L705 1021L369 571Z" />
-<glyph unicode="5" horiz-adv-x="1160" d="M121 716L323 1456H1153L1111 1194H554L465 903Q546 955 666 957Q858 957 961 824T1047 476Q1029 254 874 115T499 -21Q370 -18 265 39T101 194T44 415H372Q374 337 411 290T515 241Q597 238 651 302T720 499Q730 610
-690 667T565 725Q456 725 388 651L121 716Z" />
-<glyph unicode="6" horiz-adv-x="1160" d="M1011 1478L985 1212H955Q785 1210 657 1122T452 868Q575 985 739 981Q856 979 937 915T1056 737T1084 489Q1073 354 1002 239T815 55Q682 -24 530 -21Q381 -19 273 59T115 271T82 566L97 689Q126 910 244 1091T548 1374T950
-1478H1011ZM612 725Q500 729 419 618Q400 478 400 426Q400 338 436 290T540 240Q640 238 702 340T753 569Q746 639 709 681T612 725Z" />
-<glyph unicode="7" horiz-adv-x="1160" d="M1172 1261L454 0H94L809 1196H142L184 1456H1203L1172 1261Z" />
-<glyph unicode="8" horiz-adv-x="1160" d="M1126 1075Q1112 863 879 744Q963 684 1004 598T1038 409Q1025 208 874 92T498 -20Q400 -19 313 10T164 97Q40 211 53 393Q67 630 338 756Q190 871 200 1058Q207 1185 275 1281T457 1428T710 1477Q910 1473 1024 1362T1126
-1075ZM714 436Q723 514 690 564T588 616Q511 618 455 563T388 420Q379 338 414 290T518 239Q592 237 647 291T714 436ZM794 1057Q802 1131 773 1174T688 1218Q623 1220 579 1171T524 1041Q516 967 545 921T631 874Q694 872 739 922T794 1057Z" />
-<glyph unicode="9" horiz-adv-x="1160" d="M739 564Q625 465 496 465Q376 466 291 529T164 705T135 950Q147 1093 226 1217T427 1411T689 1477Q873 1472 984 1348T1111 1024Q1116 952 1109 881L1095 773Q1048 408 813 194T228 -21H207L234 250H280Q614 257 739
-564ZM598 707Q694 705 768 802L788 944L793 1027Q793 1117 761 1167T666 1218Q576 1220 516 1114T465 870Q469 796 503 752T598 707Z" />
-<glyph unicode=":" horiz-adv-x="607" d="M39 152Q37 228 91 278T220 328Q294 328 346 283T400 164Q402 89 349 39T219 -12Q143 -12 92 34T39 152ZM177 950Q175 1026 229 1076T358 1126Q432 1126 484 1081T538 962Q540 887 487 837T357 786Q281 786 230 832T177 950Z" />
-<glyph unicode=";" horiz-adv-x="582" d="M166 950Q164 1026 218 1076T347 1126Q421 1126 473 1081T527 962Q529 887 476 837T346 786Q270 786 219 832T166 950ZM76 -391L-89 -312L3 -149Q55 -54 68 21L109 254H373L338 46Q293 -221 76 -391Z" />
-<glyph unicode="&lt;" horiz-adv-x="1023" d="M373 603L872 419L821 124L24 485L70 751L993 1111L937 792L373 603Z" />
-<glyph unicode="=" horiz-adv-x="1173" d="M1045 722H144L190 982H1090L1045 722ZM969 283H68L114 543H1014L969 283Z" />
-<glyph unicode="&gt;" horiz-adv-x="1029" d="M638 618L142 803L193 1096L985 736L939 470L21 110L77 429L638 618Z" />
-<glyph unicode="?" horiz-adv-x="1022" d="M321 459Q333 697 474 821L557 887Q625 942 659 998T691 1129Q688 1217 598 1220Q540 1222 501 1178T445 1054L116 1052Q131 1252 269 1366T620 1477Q749 1474 845 1426T989 1291T1028 1088Q1016 919 838 774L721 681Q618
-594 596 461L321 459ZM217 150Q215 227 269 277T399 327Q476 327 527 280T580 163Q582 86 529 37T398 -13Q324 -13 272 31T217 150Z" />
-<glyph unicode="@" horiz-adv-x="1789" d="M1184 -21Q1105 -19 1047 17T965 115Q845 -21 696 -17Q585 -14 521 68T453 284Q446 454 524 627T728 897T1005 991Q1083 989 1152 964T1307 882L1168 282L1164 244Q1157 155 1234 152Q1390 145 1471 421Q1514 569 1518
-720Q1524 963 1407 1098T1059 1238Q900 1241 755 1171T495 961T311 640T237 273Q231 110 283 -12T443 -197T705 -262Q861 -264 1041 -197L1070 -367Q941 -453 704 -453Q498 -451 346 -372T111 -140T23 213Q17 440 95 664T321 1061T660 1323T1058 1410Q1319 1407
-1489 1268T1702 883Q1737 673 1677 448T1488 99T1184 -21ZM713 428Q695 346 699 274Q701 228 722 199T781 169Q830 166 880 214T956 334L1076 795Q1043 802 1023 802Q909 806 830 714T713 428Z" />
-<glyph unicode="A" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543Z" />
-<glyph unicode="B" horiz-adv-x="1291" d="M2 0L254 1456L717 1455Q991 1454 1126 1351T1249 1062Q1234 832 997 736Q1082 706 1129 628T1170 439Q1156 228 1004 114T586 0H2ZM452 619L391 270L596 269Q692 269 756 316T832 443Q860 610 704 618L452 619ZM491
-849L652 848Q875 853 902 1019Q926 1183 732 1184L550 1185L491 849Z" />
-<glyph unicode="C" horiz-adv-x="1314" d="M1222 496Q1209 343 1122 224T892 41T583 -20Q355 -15 224 127T81 512Q72 674 116 865T261 1197T498 1409T797 1477Q1035 1473 1173 1334T1324 951L983 952Q985 1085 935 1142T777 1203Q507 1212 448 783Q421 589 421
-506Q416 260 603 253Q724 249 796 312T888 492L1222 496Z" />
-<glyph unicode="D" horiz-adv-x="1294" d="M2 0L254 1456L682 1455Q871 1455 1012 1356T1212 1084Q1263 933 1243 758L1236 697Q1209 501 1106 342T841 93T491 0H2ZM550 1185L391 270L491 269Q667 269 773 405T900 821L902 854Q909 1014 852 1097T681 1184L550 1185Z" />
-<glyph unicode="E" horiz-adv-x="1122" d="M987 617H452L391 270H1024L977 0H2L254 1456H1231L1184 1185H550L496 878H1032L987 617Z" />
-<glyph unicode="F" horiz-adv-x="1096" d="M994 580H445L344 0H2L254 1456H1201L1154 1185H550L492 850H1041L994 580Z" />
-<glyph unicode="G" horiz-adv-x="1364" d="M1209 179Q1127 83 970 31T622 -19Q439 -17 313 73T133 324T104 687L112 747Q158 1086 350 1284T822 1477Q1066 1473 1197 1346T1343 979L1015 980Q1008 1097 958 1151T814 1208Q676 1213 586 1100T463 775Q435 595 443
-495Q458 254 660 251Q782 249 874 310L919 537H682L724 778H1303L1209 179Z" />
-<glyph unicode="H" horiz-adv-x="1406" d="M1184 0H844L949 608H450L344 0H2L254 1456H597L496 878H996L1096 1456H1437L1184 0Z" />
-<glyph unicode="I" horiz-adv-x="609" d="M367 0H25L278 1456H619L367 0Z" />
-<glyph unicode="J" horiz-adv-x="1126" d="M820 1456H1162L992 457Q961 238 806 107T440 -21Q229 -17 114 103T4 441L349 440V371Q353 252 464 249Q614 246 652 468L820 1456Z" />
-<glyph unicode="K" horiz-adv-x="1281" d="M587 538L409 371L344 0H2L254 1456H597L488 833L630 1006L1008 1456H1452L848 797L1183 0H792L587 538Z" />
-<glyph unicode="L" horiz-adv-x="1087" d="M391 270H984L937 0H2L254 1456H597L391 270Z" />
-<glyph unicode="M" horiz-adv-x="1751" d="M698 1456L837 446L1325 1456H1781L1529 0H1185L1247 357L1395 1015L885 0H658L493 1053L401 323L344 0H2L254 1456H698Z" />
-<glyph unicode="N" horiz-adv-x="1405" d="M1183 0H852L504 919L344 0H2L254 1456H588L935 537L1094 1456H1436L1183 0Z" />
-<glyph unicode="O" horiz-adv-x="1382" d="M603 -20Q376 -15 239 130T84 518Q74 638 103 800T206 1100T391 1328Q577 1481 819 1476Q968 1473 1079 1408T1258 1219T1336 939Q1344 828 1323 687T1244 417T1095 190T881 35T603 -20ZM993 942Q983 1192 799 1202Q657
-1209 564 1090T441 737Q422 593 427 514Q437 260 623 253Q745 247 833 340T960 612T993 942Z" />
-<glyph unicode="P" horiz-adv-x="1303" d="M430 494L344 0H2L254 1456L777 1455Q1020 1455 1159 1320T1282 970Q1270 823 1188 715T972 550T670 493L430 494ZM477 765L683 763Q813 766 882 847T937 1048Q929 1109 891 1144T789 1184L550 1185L477 765Z" />
-<glyph unicode="Q" horiz-adv-x="1382" d="M1326 699Q1297 491 1207 341T976 99L1171 -94L944 -266L686 -15Q630 -20 602 -19Q455 -18 342 48T162 238T85 522Q77 639 102 788T191 1068Q287 1263 451 1371T820 1476Q968 1473 1080 1408T1259 1217T1338 934Q1344
-847 1333 757L1326 699ZM995 942Q987 1073 939 1135T800 1202Q655 1207 564 1088T442 735Q423 595 428 513Q438 260 624 253Q759 246 850 358T976 692Q999 847 995 942Z" />
-<glyph unicode="R" horiz-adv-x="1306" d="M624 514H434L344 0H2L254 1456L768 1455Q1015 1455 1148 1340T1268 1024Q1257 866 1177 763T953 599L1149 17V0H784L624 514ZM480 785L680 783Q762 783 822 823T909 932T924 1067Q904 1178 782 1184L550 1185L480 785Z" />
-<glyph unicode="S" horiz-adv-x="1254" d="M802 394Q824 507 680 569L516 637Q171 792 188 1059Q195 1181 272 1276T485 1425T782 1476Q998 1472 1129 1350T1259 1023H919Q922 1107 884 1157T757 1210Q671 1212 605 1170T527 1057Q508 957 675 893T919 783Q1158
-640 1143 397Q1135 271 1062 176T860 29T569 -21Q451 -19 350 16T177 118Q31 253 37 473L380 472Q374 360 423 303T588 245Q674 245 731 284T802 394Z" />
-<glyph unicode="T" horiz-adv-x="1262" d="M1318 1185H894L689 0H346L552 1185H135L183 1456H1365L1318 1185Z" />
-<glyph unicode="U" horiz-adv-x="1330" d="M1368 1456L1206 506Q1171 259 1003 117T578 -21Q419 -18 302 47T130 232T92 505L254 1456H598L437 504Q431 454 435 409Q440 335 481 294T599 250Q819 243 864 505L1026 1456H1368Z" />
-<glyph unicode="V" horiz-adv-x="1322" d="M619 400L1065 1456H1457L753 0H379L135 1456H505L619 400Z" />
-<glyph unicode="W" horiz-adv-x="1737" d="M1189 547L1493 1456H1839L1311 0H957L898 825L584 0H230L157 1456H490L510 551L844 1456H1135L1189 547Z" />
-<glyph unicode="X" horiz-adv-x="1278" d="M684 974L990 1456H1396L878 720L1163 0H784L624 491L310 0H-99L431 748L155 1456H530L684 974Z" />
-<glyph unicode="Y" horiz-adv-x="1257" d="M656 826L1024 1456H1409L781 507L694 0H346L440 540L149 1455L505 1456L656 826Z" />
-<glyph unicode="Z" horiz-adv-x="1222" d="M437 272L1108 270L1061 0H-41L-6 200L833 1183L160 1185L208 1456H1307L1273 1261L437 272Z" />
-<glyph unicode="[" horiz-adv-x="570" d="M682 1460H568L324 -104H439L400 -349H-44L277 1706H721L682 1460Z" />
-<glyph unicode="\" horiz-adv-x="857" d="M135 1456H464L780 -125H449L135 1456Z" />
-<glyph unicode="]" horiz-adv-x="570" d="M186 1706H630L309 -349H-136L-97 -104H18L262 1460H147L186 1706Z" />
-<glyph unicode="^" horiz-adv-x="899" d="M554 1179L310 729H49L466 1456H709L874 729H639L554 1179Z" />
-<glyph unicode="_" horiz-adv-x="887" d="M730 -251H-148L-104 0H774L730 -251Z" />
-<glyph unicode="`" horiz-adv-x="684" d="M681 1222H434L205 1534L536 1536L681 1222Z" />
-<glyph unicode="a" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218Z" />
-<glyph unicode="b" horiz-adv-x="1128" d="M1055 539Q1024 276 900 125T574 -21Q414 -17 328 113L287 0H-11L256 1536H585L478 993Q587 1104 721 1102Q880 1100 969 989T1063 685Q1064 621 1058 560L1055 539ZM728 559Q736 620 737 675Q737 836 622 843Q520 847
-451 756L373 324Q404 241 509 239Q670 234 712 449L726 538L728 559Z" />
-<glyph unicode="c" horiz-adv-x="1042" d="M488 239Q559 237 599 278T650 386L958 387Q952 268 888 174T714 29T479 -20Q263 -16 146 135T51 527L54 551Q72 715 146 841T340 1037T610 1102Q799 1098 908 982T1014 667L706 668Q711 840 583 843Q409 849 383 550L374
-448L373 410Q373 242 488 239Z" />
-<glyph unicode="d" horiz-adv-x="1127" d="M41 543Q72 799 197 953T523 1102Q661 1098 752 986L857 1536H1187L921 0H628L642 117Q521 -25 373 -21Q217 -19 129 94T34 399Q32 462 38 522L41 543ZM369 521Q361 457 362 409Q362 243 474 240Q571 237 647 333L721
-748Q688 840 589 843Q497 845 441 764T369 521Z" />
-<glyph unicode="e" horiz-adv-x="1092" d="M525 -20Q380 -19 267 48T95 236T49 502L52 530Q79 797 237 952T626 1102Q765 1100 864 1032T1009 843T1039 572L1020 435H376Q378 350 424 297T558 241Q701 237 815 351L953 168Q892 81 783 32T543 -20H525ZM605 843Q535
-845 484 799T394 645H723L729 674Q735 709 731 740Q714 840 605 843Z" />
-<glyph unicode="f" horiz-adv-x="730" d="M59 0L206 848H54L94 1082L246 1083L259 1178Q284 1351 397 1453Q518 1561 712 1559Q762 1559 875 1537L850 1288Q804 1300 772 1300Q699 1300 652 1267T591 1170L576 1082H781L741 848H536L389 0H59Z" />
-<glyph unicode="g" horiz-adv-x="1153" d="M43 543Q62 706 132 838T309 1037T549 1103Q712 1099 795 986L830 1083L1134 1082L957 42Q927 -178 764 -305T358 -426Q250 -424 149 -383T-24 -259L132 -65Q219 -175 358 -178Q577 -182 636 55L644 88Q532 -22 397 -20Q293
--19 214 32T90 181T39 397Q35 457 43 543ZM368 436Q368 344 401 293T497 240Q590 236 666 312L751 771Q711 841 617 843Q521 845 456 762T374 542Q368 479 368 436Z" />
-<glyph unicode="h" horiz-adv-x="1131" d="M463 964Q584 1105 742 1103Q905 1099 983 984T1040 672L928 0H599L712 676Q716 710 714 740Q707 839 604 842Q515 844 446 777L308 0H-21L246 1536H575L463 964Z" />
-<glyph unicode="i" horiz-adv-x="556" d="M334 0H4L192 1082H522L334 0ZM221 1355Q219 1428 272 1477T402 1526Q479 1526 530 1482T584 1367Q586 1293 533 1245T403 1196Q328 1196 276 1239T221 1355Z" />
-<glyph unicode="j" horiz-adv-x="546" d="M528 1082L339 -34Q315 -227 193 -334T-117 -440Q-192 -438 -282 -421L-255 -165Q-200 -177 -164 -177Q-19 -179 8 -23L198 1082H528ZM223 1355Q221 1429 275 1477T404 1525Q480 1527 532 1483T586 1367T537 1247T405
-1196Q329 1196 277 1240T223 1355Z" />
-<glyph unicode="k" horiz-adv-x="1096" d="M489 399L369 295L318 0H-11L256 1537H585L433 717L473 765L772 1082H1189L729 622L1008 0H647L489 399Z" />
-<glyph unicode="l" horiz-adv-x="556" d="M334 0H4L270 1536H600L334 0Z" />
-<glyph unicode="m" horiz-adv-x="1721" d="M483 1083L461 953Q591 1106 777 1102Q875 1100 938 1056T1022 939Q1165 1106 1351 1102Q1501 1099 1573 990T1626 681L1513 0H1183L1298 682L1302 741Q1302 840 1209 843Q1122 843 1047 754L916 0H586L700 680L704 740Q704
-843 611 843Q526 843 451 754L318 0H-11L177 1082L483 1083Z" />
-<glyph unicode="n" horiz-adv-x="1130" d="M475 1083L452 953Q582 1107 765 1103Q915 1100 988 992T1042 681L928 0H598L713 683Q717 718 715 747Q708 842 603 842Q516 844 444 765L309 0H-20L168 1082L475 1083Z" />
-<glyph unicode="o" horiz-adv-x="1126" d="M618 1102Q763 1100 869 1030T1024 833T1060 553L1058 531Q1030 282 873 129T485 -20Q341 -18 236 51T81 246T44 524Q69 790 226 948T618 1102ZM373 524L370 465Q356 242 506 238Q700 232 731 553L735 644Q737 734 702
-787T597 843Q506 846 448 769T373 524Z" />
-<glyph unicode="p" horiz-adv-x="1128" d="M1056 540Q1035 370 967 238T799 41T574 -21Q432 -17 344 91L246 -416H-83L177 1082L481 1083L464 980Q573 1106 721 1102Q879 1100 967 989T1062 686Q1064 624 1056 540ZM736 674Q731 839 624 842Q520 848 451 757L374
-328Q405 241 512 239Q687 236 727 540Q736 636 736 674Z" />
-<glyph unicode="q" horiz-adv-x="1126" d="M41 546Q61 712 127 844T293 1041T522 1102Q684 1098 768 964L819 1083L1108 1082L848 -416H518L619 92Q510 -24 372 -20Q219 -18 130 95T35 402Q33 460 41 546ZM363 442Q356 353 384 298T474 240Q575 236 646 327L723
-758Q693 840 590 844Q409 847 371 546L363 442Z" />
-<glyph unicode="r" horiz-adv-x="763" d="M768 777Q715 785 666 787Q518 791 440 685L318 0H-11L177 1082L484 1083L459 941Q565 1105 709 1105Q750 1105 811 1091L768 777Z" />
-<glyph unicode="s" horiz-adv-x="1028" d="M597 310Q610 376 495 409L424 427Q250 473 169 556T93 753Q98 909 231 1006T557 1102Q748 1100 866 1005T987 749L659 750Q663 878 546 878Q496 878 453 849T402 770Q385 689 545 659Q684 626 760 583T876 475T913 321Q910
-223 849 146T673 23T422 -20Q305 -19 205 29T48 159T-11 349L295 347Q297 203 439 205Q500 205 543 232T597 310Z" />
-<glyph unicode="t" horiz-adv-x="692" d="M604 1351L557 1082H730L689 848H516L432 351Q425 300 438 274T506 246Q527 245 592 251L568 7Q485 -20 391 -18Q238 -16 162 72T100 311L188 848H54L94 1082H228L275 1351H604Z" />
-<glyph unicode="u" horiz-adv-x="1130" d="M656 118Q535 -25 364 -21Q205 -19 125 90T62 382L179 1082H508L389 378Q386 349 389 325Q396 243 486 240Q590 236 663 322L797 1082H1128L940 0H634L656 118Z" />
-<glyph unicode="v" horiz-adv-x="1036" d="M476 405L747 1082H1102L590 0H255L82 1082H420L476 405Z" />
-<glyph unicode="w" horiz-adv-x="1452" d="M967 445L1184 1082H1506L1071 0H794L732 638L447 0H168L108 1082H417L407 438L684 1082H913L967 445Z" />
-<glyph unicode="x" horiz-adv-x="1032" d="M538 786L737 1082H1093L724 540L922 0H594L480 318L269 0H-91L297 570L108 1082H439L538 786Z" />
-<glyph unicode="y" horiz-adv-x="1039" d="M484 476L764 1082H1127L493 -162Q422 -309 330 -374T109 -440Q52 -440 -36 -418L-11 -177H27Q88 -177 134 -158T211 -82L258 8L85 1082H425L484 476Z" />
-<glyph unicode="z" horiz-adv-x="1032" d="M424 262L898 260L853 0H-41L-6 202L563 820L122 822L167 1082H1030L996 885L424 262Z" />
-<glyph unicode="{" horiz-adv-x="655" d="M418 -360Q257 -306 180 -185T120 106L150 327L151 383Q144 492 29 503L52 731Q216 738 248 929L276 1132Q301 1319 405 1433T689 1600L737 1420Q669 1391 626 1324T562 1132L531 901Q497 710 302 613Q378 559 408 480T431
-309L397 24Q383 -130 485 -184L418 -360Z" />
-<glyph unicode="|" horiz-adv-x="517" d="M210 -270H30L300 1456H480L210 -270Z" />
-<glyph unicode="}" horiz-adv-x="655" d="M-85 -182Q-17 -153 26 -86T90 106L121 337Q155 527 351 625Q274 678 244 758T221 929Q253 1169 257 1214Q268 1369 168 1422L241 1596Q401 1542 475 1420T532 1132L502 911L501 855Q507 745 623 734L600 506Q436 499
-404 309L371 71Q313 -262 -37 -363L-85 -182Z" />
-<glyph unicode="~" horiz-adv-x="1266" d="M1184 800Q1176 676 1129 574T1005 418T822 366Q747 368 689 400T566 501T455 576L439 577Q383 577 347 529T299 405L69 408Q81 604 178 722T429 837Q561 834 670 721L711 678Q762 627 812 627Q921 627 952 800H1184Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="505" />
-<glyph unicode="&#xa1;" horiz-adv-x="607" d="M168 623H435L305 -372H-46L168 623ZM540 939Q542 864 489 814T358 763Q281 763 230 810T177 927Q175 1002 228 1052T359 1103Q436 1103 487 1056T540 939Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1183" d="M527 239Q598 237 638 278T690 386L998 387Q989 228 884 123T604 -11L555 -245H359L408 -10Q239 25 157 169T95 526L98 549Q127 781 254 923T584 1094L631 1318H827L779 1090Q919 1055 992 945T1060 667L752 668Q757
-837 632 844Q459 850 426 550L415 411Q410 242 527 239Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1202" d="M597 561L585 450Q570 344 488 266L1084 270L1037 0H-2L46 269L132 267Q205 294 226 392L251 561H92L138 822H288L315 1038Q340 1243 475 1361T813 1475Q1011 1471 1122 1358T1229 1047L906 1048Q909 1134 882 1170T799
-1206Q743 1208 705 1162T656 1039L631 822H930L884 561H597Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1365" d="M961 105Q777 -24 592 -20Q392 -16 261 106L108 -26L-15 132L139 257Q82 442 102 602Q128 817 274 977L158 1134L307 1264L415 1121Q592 1237 769 1233Q956 1231 1090 1117L1261 1265L1384 1106L1215 967Q1276 776
-1257 615Q1232 412 1099 255L1211 104L1061 -27L961 105ZM284 599Q268 488 302 389T413 233T594 171Q709 167 813 226T989 391T1076 617Q1091 727 1058 824T948 980T767 1043Q652 1047 547 988T371 823T284 599Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1085" d="M590 940L860 1456H1222L797 744L995 742L959 552H696L679 452H943L910 263H646L600 0H259L305 263H10L44 452H337L355 552H60L94 742H338L163 1456H499L590 940Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="518" d="M-36 -270L102 525H387L249 -270H-36ZM417 698H131L263 1456H549L417 698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1272" d="M1144 508Q1137 408 1084 342T946 227Q1044 114 1033 -53Q1018 -263 822 -364Q673 -440 471 -437Q234 -435 105 -327T-21 -24L306 -25Q304 -99 347 -137T487 -175Q677 -175 703 -55Q724 39 556 90T309 180T180 265Q71
-365 81 520Q88 620 142 688T280 803Q181 916 191 1082Q199 1203 272 1292T475 1430T756 1476Q904 1473 1010 1423T1172 1278T1226 1050H900Q902 1128 861 1170T740 1214Q667 1216 611 1191Q536 1157 521 1085Q500 985 661 938T895 859Q1159 745 1144 508ZM606 652L496
-689Q433 638 418 560Q396 450 547 399L726 341Q797 399 811 470Q833 574 669 630L606 652Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="993" d="M212 1361Q210 1416 252 1456T356 1499Q417 1499 460 1461T506 1369Q508 1312 466 1273T363 1231Q301 1231 258 1269T212 1361ZM716 1361Q714 1418 756 1457T859 1499Q920 1499 964 1461T1010 1369Q1012 1314 970
-1274T866 1231Q805 1231 762 1269T716 1361Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1570" d="M1088 597Q1078 447 987 363T743 282Q595 286 513 395T443 669L454 779Q473 963 576 1070T835 1176Q980 1172 1060 1089T1138 859L986 861Q999 1038 840 1042Q747 1044 685 973T608 777T593 632T594 584Q597 511
-634 466T736 417Q905 410 936 596L1088 597ZM230 572Q249 365 377 236T692 105Q851 101 996 182T1243 411T1370 736Q1392 895 1341 1037T1177 1263T913 1351Q730 1355 565 1248T306 951T230 572ZM113 722Q133 919 245 1097T532 1378T901 1476Q1084 1472 1226 1374T1440
-1102T1492 735Q1471 546 1372 379T1117 107Q923 -24 704 -20Q519 -16 378 83T164 357T113 722Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="887" d="M616 702L613 774Q524 691 412 691Q308 691 246 751T185 911Q185 1026 277 1088T539 1151L645 1149L658 1204Q662 1228 661 1250Q658 1325 580 1328Q460 1332 433 1229L260 1242Q267 1352 354 1415T574 1477Q695
-1475 767 1400T829 1200L776 853L772 794Q771 750 780 702H616ZM445 833Q514 833 606 896L634 1033H554Q470 1030 419 999T359 915Q352 877 374 855T445 833Z" />
-<glyph unicode="&#xab;" horiz-adv-x="1032" d="M540 499L695 117L508 116L303 505L304 525L626 915H847L540 499ZM685 499L840 117L653 116L448 505L449 525L771 915H992L685 499Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1100" d="M893 374H697L743 634H126L156 805H968L893 374Z" />
-<glyph unicode="&#xad;" horiz-adv-x="903" d="M714 497H129L174 758H759L714 497Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1570" d="M113 722Q133 919 245 1097T532 1378T901 1476Q1084 1472 1226 1374T1440 1102T1492 735Q1471 546 1372 379T1117 107Q923 -24 704 -20Q519 -16 378 83T164 357T113 722ZM234 722Q212 564 263 421T427 194T692 105Q851
-101 1000 185T1247 419T1370 736Q1392 894 1341 1037T1177 1264T913 1351Q751 1355 602 1270T354 1036T234 722ZM652 653L599 316H451L584 1166L840 1165Q979 1160 1057 1092T1130 909Q1127 855 1098 812T999 727Q1064 673 1067 574Q1068 545 1062 485T1057 396L1061
-333L1060 314L912 315Q906 352 908 388Q909 431 920 516Q927 579 906 613T819 651L652 653ZM673 787L781 786Q869 789 922 821T986 909Q997 970 969 999T852 1032L711 1033L673 787Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="1043" d="M957 1285H281L309 1458H984L957 1285Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="799" d="M226 1186Q228 1305 314 1392T518 1477Q623 1475 695 1395T765 1204Q763 1088 679 1002T479 917Q370 919 297 998T226 1186ZM377 1188Q371 1138 398 1105T472 1071Q523 1071 565 1109T615 1202Q622 1254 596 1289T525
-1324Q473 1324 430 1284T377 1188Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1079" d="M727 974H1030L987 703H685L630 355H343L398 703H96L139 974H440L490 1293H777L727 974ZM857 1H3L45 265H899L857 1Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="755" d="M688 667H77L105 826L405 1065Q525 1160 539 1226Q546 1258 531 1277T482 1296Q443 1296 416 1267T378 1190L156 1188Q162 1312 251 1392T471 1470Q610 1468 687 1402T762 1224Q758 1094 611 985L404 844L720 842L688 667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="755" d="M354 1141H436Q487 1143 519 1167T559 1230Q564 1259 544 1275T489 1292Q422 1296 396 1242L169 1241Q176 1348 260 1409T477 1469Q618 1466 699 1407T778 1249Q775 1132 617 1066Q736 1025 736 896Q734 784 635
-719T386 656Q257 658 175 726T90 910L305 909Q312 835 400 833Q446 833 481 857T523 920Q536 993 439 998H343L354 1141Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="680" d="M415 1536H782L463 1222H175L415 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1284" d="M540 1082L436 446L432 373Q432 246 546 243Q661 239 740 333L873 1082H1201L1014 0H718L724 54Q623 -22 512 -22Q436 -22 365 15L281 -416H-49L211 1082H540Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="981" d="M541 0L632 520L580 521Q369 524 254 651T156 980Q175 1194 324 1325T696 1457L1018 1456L766 0H541Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="647" d="M150 679Q148 755 202 805T331 855Q405 855 457 810T511 691Q513 616 460 566T330 515Q254 515 203 561T150 679Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="562" d="M249 12L230 -55Q292 -69 323 -112T355 -217Q355 -338 253 -403T-43 -474L-31 -286Q58 -274 72 -202Q81 -148 1 -140L-41 -136L2 9L249 12Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="755" d="M538 667H320L411 1196L234 1160L265 1337L641 1453L666 1454L538 667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="920" d="M205 1120Q222 1281 325 1381T580 1477Q728 1473 809 1372T880 1121L874 1055Q858 884 754 785T500 689Q356 693 272 792T199 1044L205 1120ZM371 1041Q368 1005 371 969Q376 908 409 872T499 834Q575 831 630 887T700
-1044L711 1145L710 1194Q695 1326 582 1329Q505 1332 450 1277T380 1121L371 1041Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="1032" d="M322 914L526 527L525 505L203 115H-19L288 530L134 913L322 914ZM723 914L927 527L926 505L604 115H382L689 530L535 913L723 914Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1418" d="M508 664H290L381 1193L204 1157L235 1334L611 1450L636 1451L508 664ZM377 119L224 206L1101 1332L1255 1245L377 119ZM1197 333L1284 334L1250 157H1174L1146 0H926L954 157H632L644 317L1053 788L1275 790L1197
-333ZM859 337L987 334L1027 529L1006 503L859 337Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1501" d="M338 119L185 206L1062 1332L1216 1245L338 119ZM486 672H268L359 1201L182 1165L213 1342L589 1458L614 1459L486 672ZM1323 0H712L740 159L1040 398Q1160 493 1174 559Q1181 591 1166 610T1117 629Q1078 629 1051
-600T1013 523L791 521Q797 645 886 725T1106 803Q1245 801 1322 735T1397 557Q1393 427 1246 318L1039 177L1355 175L1323 0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1648" d="M553 119L400 206L1277 1332L1431 1245L553 119ZM1389 333L1476 334L1442 157H1366L1338 0H1118L1146 157H824L836 317L1245 788L1467 790L1389 333ZM1051 337L1179 334L1219 529L1198 503L1051 337ZM397 1141H479Q530
-1143 562 1167T602 1230Q607 1259 587 1275T532 1292Q465 1296 439 1242L212 1241Q219 1348 303 1409T520 1469Q661 1466 742 1407T821 1249Q818 1132 660 1066Q779 1025 779 896Q777 784 678 719T429 656Q300 658 218 726T133 910L348 909Q355 835 443 833Q489
-833 524 857T566 920Q579 993 482 998H386L397 1141Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="1022" d="M679 632Q672 499 636 415T525 267L437 195Q299 76 310 -47Q317 -126 393 -129Q523 -132 555 37L885 39Q870 -160 734 -274T381 -385Q187 -383 75 -280T-25 2Q-16 168 169 319L297 421Q386 498 407 630L679 632ZM798
-940Q800 867 747 816T615 764Q540 764 488 810T434 928Q432 1003 486 1053T617 1104Q692 1104 744 1058T798 940Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543ZM989 1532H742L513 1844L844 1846L989 1532Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543ZM922 1846H1289L970 1532H682L922 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543ZM1260 1569V1547L1010 1552L880 1687L702 1553L440 1549L439 1573L787 1846H972L1260 1569Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543ZM1257 1838Q1250 1717 1184 1639T1018 1561Q982 1561 950 1575T884 1607T819 1638T754 1649Q687 1646 663 1558L475 1568Q482
-1685 549 1765T716 1844Q761 1843 836 1805T934 1762T982 1757Q1047 1760 1076 1848L1257 1838Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543ZM464 1671Q462 1726 504 1766T608 1809Q669 1809 712 1771T758 1679Q760 1622 718 1583T615 1541Q553 1541 510 1579T464
-1671ZM968 1671Q966 1728 1008 1767T1111 1809Q1172 1809 1216 1771T1262 1679Q1264 1624 1222 1584T1118 1541Q1057 1541 1014 1579T968 1671Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1363" d="M857 272H392L263 0H-114L657 1456H979L1248 0H892L857 272ZM520 543H822L758 1045L520 543ZM660 1722Q658 1810 725 1871T885 1933Q971 1933 1033 1876T1096 1736Q1096 1647 1031 1588T873 1529Q786 1529 724 1584T660
-1722ZM778 1723Q772 1683 792 1654T855 1625Q899 1625 935 1657T978 1735Q984 1774 964 1804T901 1835Q855 1835 820 1802T778 1723Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1878" d="M1693 0H821L865 329H503L298 0H-97L868 1456H1886L1840 1192H1307L1265 876H1707L1661 612H1230L1184 264H1739L1693 0ZM668 601L902 599L963 1067L668 601Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1314" d="M1222 496Q1209 343 1122 224T892 41T583 -20Q355 -15 224 127T81 512Q72 674 116 865T261 1197T498 1409T797 1477Q1035 1473 1173 1334T1324 951L983 952Q985 1085 935 1142T777 1203Q507 1212 448 783Q421 589
-421 506Q416 260 603 253Q724 249 796 312T888 492L1222 496ZM681 12L662 -55Q724 -69 755 -112T787 -217Q787 -338 685 -403T389 -474L401 -286Q490 -274 504 -202Q513 -148 433 -140L391 -136L434 9L681 12Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1122" d="M987 617H452L391 270H1024L977 0H2L254 1456H1231L1184 1185H550L496 878H1032L987 617ZM934 1532H687L458 1844L789 1846L934 1532Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1122" d="M987 617H452L391 270H1024L977 0H2L254 1456H1231L1184 1185H550L496 878H1032L987 617ZM867 1846H1234L915 1532H627L867 1846Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1122" d="M987 617H452L391 270H1024L977 0H2L254 1456H1231L1184 1185H550L496 878H1032L987 617ZM1205 1569V1547L955 1552L825 1687L647 1553L385 1549L384 1573L732 1846H917L1205 1569Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1122" d="M987 617H452L391 270H1024L977 0H2L254 1456H1231L1184 1185H550L496 878H1032L987 617ZM409 1671Q407 1726 449 1766T553 1809Q614 1809 657 1771T703 1679Q705 1622 663 1583T560 1541Q498 1541 455 1579T409
-1671ZM913 1671Q911 1728 953 1767T1056 1809Q1117 1809 1161 1771T1207 1679Q1209 1624 1167 1584T1063 1541Q1002 1541 959 1579T913 1671Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="609" d="M367 0H25L278 1456H619L367 0ZM611 1532H364L135 1844L466 1846L611 1532Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="609" d="M367 0H25L278 1456H619L367 0ZM543 1846H910L591 1532H303L543 1846Z" />
-<glyph unicode="&#xce;" horiz-adv-x="609" d="M367 0H25L278 1456H619L367 0ZM882 1569V1547L632 1552L502 1687L324 1553L62 1549L61 1573L409 1846H594L882 1569Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="609" d="M367 0H25L278 1456H619L367 0ZM86 1671Q84 1726 126 1766T230 1809Q291 1809 334 1771T380 1679Q382 1622 340 1583T237 1541Q175 1541 132 1579T86 1671ZM590 1671Q588 1728 630 1767T733 1809Q794 1809 838 1771T884
-1679Q886 1624 844 1584T740 1541Q679 1541 636 1579T590 1671Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1324" d="M32 0L142 635H-24L9 826H175L284 1456L712 1455Q901 1455 1042 1356T1242 1084Q1293 933 1273 758L1266 697Q1239 501 1136 342T871 93T521 0H32ZM686 635H484L421 270L521 269Q701 269 808 411T932 854Q939 1014
-882 1097T711 1184L580 1185L517 826H720L686 635Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1405" d="M1183 0H852L504 919L344 0H2L254 1456H588L935 537L1094 1456H1436L1183 0ZM1283 1838Q1276 1717 1210 1639T1044 1561Q1008 1561 976 1575T910 1607T845 1638T780 1649Q713 1646 689 1558L501 1568Q508 1685 575
-1765T742 1844Q787 1843 862 1805T960 1762T1008 1757Q1073 1760 1102 1848L1283 1838Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1382" d="M603 -20Q376 -15 239 130T84 518Q74 638 103 800T206 1100T391 1328Q577 1481 819 1476Q968 1473 1079 1408T1258 1219T1336 939Q1344 828 1323 687T1244 417T1095 190T881 35T603 -20ZM993 942Q983 1192 799 1202Q657
-1209 564 1090T441 737Q422 593 427 514Q437 260 623 253Q745 247 833 340T960 612T993 942ZM994 1532H747L518 1844L849 1846L994 1532Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1382" d="M603 -20Q376 -15 239 130T84 518Q74 638 103 800T206 1100T391 1328Q577 1481 819 1476Q968 1473 1079 1408T1258 1219T1336 939Q1344 828 1323 687T1244 417T1095 190T881 35T603 -20ZM993 942Q983 1192 799 1202Q657
-1209 564 1090T441 737Q422 593 427 514Q437 260 623 253Q745 247 833 340T960 612T993 942ZM927 1846H1294L975 1532H687L927 1846Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1382" d="M603 -20Q376 -15 239 130T84 518Q74 638 103 800T206 1100T391 1328Q577 1481 819 1476Q968 1473 1079 1408T1258 1219T1336 939Q1344 828 1323 687T1244 417T1095 190T881 35T603 -20ZM993 942Q983 1192 799 1202Q657
-1209 564 1090T441 737Q422 593 427 514Q437 260 623 253Q745 247 833 340T960 612T993 942ZM1265 1569V1547L1015 1552L885 1687L707 1553L445 1549L444 1573L792 1846H977L1265 1569Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1382" d="M603 -20Q376 -15 239 130T84 518Q74 638 103 800T206 1100T391 1328Q577 1481 819 1476Q968 1473 1079 1408T1258 1219T1336 939Q1344 828 1323 687T1244 417T1095 190T881 35T603 -20ZM993 942Q983 1192 799 1202Q657
-1209 564 1090T441 737Q422 593 427 514Q437 260 623 253Q745 247 833 340T960 612T993 942ZM1262 1838Q1255 1717 1189 1639T1023 1561Q987 1561 955 1575T889 1607T824 1638T759 1649Q692 1646 668 1558L480 1568Q487 1685 554 1765T721 1844Q766 1843 841 1805T939
-1762T987 1757Q1052 1760 1081 1848L1262 1838Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1382" d="M603 -20Q376 -15 239 130T84 518Q74 638 103 800T206 1100T391 1328Q577 1481 819 1476Q968 1473 1079 1408T1258 1219T1336 939Q1344 828 1323 687T1244 417T1095 190T881 35T603 -20ZM993 942Q983 1192 799 1202Q657
-1209 564 1090T441 737Q422 593 427 514Q437 260 623 253Q745 247 833 340T960 612T993 942ZM469 1671Q467 1726 509 1766T613 1809Q674 1809 717 1771T763 1679Q765 1622 723 1583T620 1541Q558 1541 515 1579T469 1671ZM973 1671Q971 1728 1013 1767T1116 1809Q1177
-1809 1221 1771T1267 1679Q1269 1624 1227 1584T1123 1541Q1062 1541 1019 1579T973 1671Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1061" d="M15 394L358 700L121 1005L326 1176L558 877L894 1175L1062 979L716 673L955 368L750 197L518 495L182 198L15 394Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1377" d="M610 -21Q458 -19 334 46L225 -95L4 -94L197 153Q57 387 96 698L101 736Q147 1073 345 1277T828 1477Q977 1475 1099 1411L1183 1518L1405 1517L1237 1304Q1376 1070 1338 762L1330 696Q1299 482 1196 315T942 62T610
--21ZM1015 991L503 293Q548 253 628 251Q767 249 856 359T980 678T1015 991ZM441 698Q422 565 419 468L929 1164Q883 1199 810 1204Q666 1209 574 1092T451 759L441 698Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1330" d="M1368 1456L1206 506Q1171 259 1003 117T578 -21Q419 -18 302 47T130 232T92 505L254 1456H598L437 504Q431 454 435 409Q440 335 481 294T599 250Q819 243 864 505L1026 1456H1368ZM965 1532H718L489 1844L820
-1846L965 1532Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1330" d="M1368 1456L1206 506Q1171 259 1003 117T578 -21Q419 -18 302 47T130 232T92 505L254 1456H598L437 504Q431 454 435 409Q440 335 481 294T599 250Q819 243 864 505L1026 1456H1368ZM898 1846H1265L946 1532H658L898 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1330" d="M1368 1456L1206 506Q1171 259 1003 117T578 -21Q419 -18 302 47T130 232T92 505L254 1456H598L437 504Q431 454 435 409Q440 335 481 294T599 250Q819 243 864 505L1026 1456H1368ZM1236 1569V1547L986 1552L856
-1687L678 1553L416 1549L415 1573L763 1846H948L1236 1569Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1330" d="M1368 1456L1206 506Q1171 259 1003 117T578 -21Q419 -18 302 47T130 232T92 505L254 1456H598L437 504Q431 454 435 409Q440 335 481 294T599 250Q819 243 864 505L1026 1456H1368ZM440 1671Q438 1726 480 1766T584
-1809Q645 1809 688 1771T734 1679Q736 1622 694 1583T591 1541Q529 1541 486 1579T440 1671ZM944 1671Q942 1728 984 1767T1087 1809Q1148 1809 1192 1771T1238 1679Q1240 1624 1198 1584T1094 1541Q1033 1541 990 1579T944 1671Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1257" d="M656 826L1024 1456H1409L781 507L694 0H346L440 540L149 1455L505 1456L656 826ZM867 1846H1234L915 1532H627L867 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1238" d="M591 1456L546 1198L697 1197Q945 1196 1081 1073T1202 746Q1191 602 1112 497T897 334T596 277L387 278L338 0H8L260 1456H591ZM501 938L432 538L606 537Q714 539 785 594T871 744Q885 832 842 882T710 937L501 938Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1300" d="M355 0H25L212 1099Q241 1320 391 1443T772 1561Q951 1557 1059 1453T1156 1188Q1153 1144 1138 1105T1079 987T1025 882T1010 827Q1002 784 1021 736T1095 612T1173 482T1194 378Q1185 192 1046 84T686 -22Q528
--20 422 28L500 284Q589 235 700 239Q767 241 812 278T869 373Q877 418 858 465T780 583T699 705T679 808Q684 879 739 983T804 1117T817 1177Q824 1231 797 1267T713 1306Q570 1312 540 1094L355 0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218ZM775 1222H528L299 1534L630 1536L775 1222Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218ZM708 1536H1075L756 1222H468L708 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218ZM1046 1259V1237L796 1242L666 1377L488 1243L226 1239L225 1263L573 1536H758L1046 1259Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218ZM1043 1785Q1036 1664 970 1586T804 1508Q768 1508 736 1522T670 1554T605 1585T540 1596Q473 1593 449 1505L261
-1515Q268 1632 335 1712T502 1791Q547 1790 622 1752T720 1709T768 1704Q833 1707 862 1795L1043 1785Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218ZM250 1361Q248 1416 290 1456T394 1499Q455 1499 498 1461T544 1369Q546 1312 504 1273T401 1231Q339 1231
-296 1269T250 1361ZM754 1361Q752 1418 794 1457T897 1499Q958 1499 1002 1461T1048 1369Q1050 1314 1008 1274T904 1231Q843 1231 800 1269T754 1361Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1064" d="M597 0Q583 39 583 98Q472 -24 318 -20Q177 -18 84 74T-3 297Q2 473 144 567T532 662L642 660L654 721L658 774Q654 865 567 868Q459 870 434 749L104 748Q109 857 175 937T354 1061T596 1102Q719 1099 811 1051T950
-916T985 716L904 207L899 145Q895 71 918 19L917 0H597ZM409 218Q510 214 586 307L619 481L534 482Q455 480 398 436T331 314Q326 273 346 247T409 218ZM446 1412Q444 1500 511 1561T671 1623Q757 1623 819 1566T882 1426Q882 1337 817 1278T659 1219Q572 1219
-510 1274T446 1412ZM564 1413Q558 1373 578 1344T641 1315Q685 1315 721 1347T764 1425Q770 1464 750 1494T687 1525Q641 1525 606 1492T564 1413Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1688" d="M1117 -20Q880 -15 769 113Q604 -24 386 -20Q214 -18 110 72T13 317Q20 482 163 569T558 656L699 655L709 704Q713 731 711 756Q704 839 618 842Q557 844 515 817T461 740L133 758Q138 862 200 939T382 1061T640
-1103Q729 1103 807 1080T936 1012Q1085 1105 1259 1101Q1389 1097 1480 1033T1612 859T1637 612L1610 435H997Q989 344 1035 295T1173 242Q1251 240 1321 259T1461 308L1524 99Q1455 42 1349 11T1117 -20ZM457 211Q533 209 636 274L672 451L560 452Q473 449 414
-412T343 312Q335 264 366 238T457 211ZM1235 844Q1086 850 1018 645H1316Q1327 700 1327 731Q1327 781 1304 811T1235 844Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1042" d="M488 239Q559 237 599 278T650 386L958 387Q952 268 888 174T714 29T479 -20Q263 -16 146 135T51 527L54 551Q72 715 146 841T340 1037T610 1102Q799 1098 908 982T1014 667L706 668Q711 840 583 843Q409 849 383
-550L374 448L373 410Q373 242 488 239ZM575 12L556 -55Q618 -69 649 -112T681 -217Q681 -338 579 -403T283 -474L295 -286Q384 -274 398 -202Q407 -148 327 -140L285 -136L328 9L575 12Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1092" d="M525 -20Q380 -19 267 48T95 236T49 502L52 530Q79 797 237 952T626 1102Q765 1100 864 1032T1009 843T1039 572L1020 435H376Q378 350 424 297T558 241Q701 237 815 351L953 168Q892 81 783 32T543 -20H525ZM605
-843Q535 845 484 799T394 645H723L729 674Q735 709 731 740Q714 840 605 843ZM763 1223H516L287 1535L618 1537L763 1223Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1092" d="M525 -20Q380 -19 267 48T95 236T49 502L52 530Q79 797 237 952T626 1102Q765 1100 864 1032T1009 843T1039 572L1020 435H376Q378 350 424 297T558 241Q701 237 815 351L953 168Q892 81 783 32T543 -20H525ZM605
-843Q535 845 484 799T394 645H723L729 674Q735 709 731 740Q714 840 605 843ZM696 1537H1063L744 1223H456L696 1537Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1092" d="M525 -20Q380 -19 267 48T95 236T49 502L52 530Q79 797 237 952T626 1102Q765 1100 864 1032T1009 843T1039 572L1020 435H376Q378 350 424 297T558 241Q701 237 815 351L953 168Q892 81 783 32T543 -20H525ZM605
-843Q535 845 484 799T394 645H723L729 674Q735 709 731 740Q714 840 605 843ZM1034 1260V1238L784 1243L654 1378L476 1244L214 1240L213 1264L561 1537H746L1034 1260Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1092" d="M525 -20Q380 -19 267 48T95 236T49 502L52 530Q79 797 237 952T626 1102Q765 1100 864 1032T1009 843T1039 572L1020 435H376Q378 350 424 297T558 241Q701 237 815 351L953 168Q892 81 783 32T543 -20H525ZM605
-843Q535 845 484 799T394 645H723L729 674Q735 709 731 740Q714 840 605 843ZM238 1362Q236 1417 278 1457T382 1500Q443 1500 486 1462T532 1370Q534 1313 492 1274T389 1232Q327 1232 284 1270T238 1362ZM742 1362Q740 1419 782 1458T885 1500Q946 1500 990 1462T1036
-1370Q1038 1315 996 1275T892 1232Q831 1232 788 1270T742 1362Z" />
-<glyph unicode="&#xec;" horiz-adv-x="576" d="M345 0H14L202 1082H533L345 0ZM539 1202H292L63 1514L394 1516L539 1202Z" />
-<glyph unicode="&#xed;" horiz-adv-x="576" d="M345 0H14L202 1082H533L345 0ZM471 1772H838L519 1458H231L471 1772Z" />
-<glyph unicode="&#xee;" horiz-adv-x="576" d="M345 0H14L202 1082H533L345 0ZM810 1239V1217L560 1222L430 1357L252 1223L-10 1219L-11 1243L337 1516H522L810 1239Z" />
-<glyph unicode="&#xef;" horiz-adv-x="576" d="M345 0H14L202 1082H533L345 0ZM14 1341Q12 1396 54 1436T158 1479Q219 1479 262 1441T308 1349Q310 1292 268 1253T165 1211Q103 1211 60 1249T14 1341ZM518 1341Q516 1398 558 1437T661 1479Q722 1479 766 1441T812
-1349Q814 1294 772 1254T668 1211Q607 1211 564 1249T518 1341Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1140" d="M961 1305Q1051 1152 1088 993T1103 656L1094 593Q1068 411 978 266T759 48T482 -21Q348 -18 243 45T85 218T44 460Q63 688 199 827T547 962Q663 960 771 898Q764 1022 684 1139L487 1027L427 1160L569 1237Q498
-1295 354 1335L481 1579Q700 1527 852 1403L1035 1507L1093 1374L961 1305ZM508 238Q604 235 669 317T759 553L778 656Q724 722 606 722Q530 723 475 678T393 546T374 384Q381 317 416 278T508 238Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1130" d="M475 1083L452 953Q582 1107 765 1103Q915 1100 988 992T1042 681L928 0H598L713 683Q717 718 715 747Q708 842 603 842Q516 844 444 765L309 0H-20L168 1082L475 1083ZM1085 1785Q1078 1664 1012 1586T846 1508Q810
-1508 778 1522T712 1554T647 1585T582 1596Q515 1593 491 1505L303 1515Q310 1632 377 1712T544 1791Q589 1790 664 1752T762 1709T810 1704Q875 1707 904 1795L1085 1785Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1126" d="M618 1102Q763 1100 869 1030T1024 833T1060 553L1058 531Q1030 282 873 129T485 -20Q341 -18 236 51T81 246T44 524Q69 790 226 948T618 1102ZM373 524L370 465Q356 242 506 238Q700 232 731 553L735 644Q737 734
-702 787T597 843Q506 846 448 769T373 524ZM804 1222H557L328 1534L659 1536L804 1222Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1126" d="M618 1102Q763 1100 869 1030T1024 833T1060 553L1058 531Q1030 282 873 129T485 -20Q341 -18 236 51T81 246T44 524Q69 790 226 948T618 1102ZM373 524L370 465Q356 242 506 238Q700 232 731 553L735 644Q737 734
-702 787T597 843Q506 846 448 769T373 524ZM737 1536H1104L785 1222H497L737 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1126" d="M618 1102Q763 1100 869 1030T1024 833T1060 553L1058 531Q1030 282 873 129T485 -20Q341 -18 236 51T81 246T44 524Q69 790 226 948T618 1102ZM373 524L370 465Q356 242 506 238Q700 232 731 553L735 644Q737 734
-702 787T597 843Q506 846 448 769T373 524ZM1075 1259V1237L825 1242L695 1377L517 1243L255 1239L254 1263L602 1536H787L1075 1259Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1126" d="M618 1102Q763 1100 869 1030T1024 833T1060 553L1058 531Q1030 282 873 129T485 -20Q341 -18 236 51T81 246T44 524Q69 790 226 948T618 1102ZM373 524L370 465Q356 242 506 238Q700 232 731 553L735 644Q737 734
-702 787T597 843Q506 846 448 769T373 524ZM1072 1785Q1065 1664 999 1586T833 1508Q797 1508 765 1522T699 1554T634 1585T569 1596Q502 1593 478 1505L290 1515Q297 1632 364 1712T531 1791Q576 1790 651 1752T749 1709T797 1704Q862 1707 891 1795L1072 1785Z"
-/>
-<glyph unicode="&#xf6;" horiz-adv-x="1126" d="M618 1102Q763 1100 869 1030T1024 833T1060 553L1058 531Q1030 282 873 129T485 -20Q341 -18 236 51T81 246T44 524Q69 790 226 948T618 1102ZM373 524L370 465Q356 242 506 238Q700 232 731 553L735 644Q737 734
-702 787T597 843Q506 846 448 769T373 524ZM279 1361Q277 1416 319 1456T423 1499Q484 1499 527 1461T573 1369Q575 1312 533 1273T430 1231Q368 1231 325 1269T279 1361ZM783 1361Q781 1418 823 1457T926 1499Q987 1499 1031 1461T1077 1369Q1079 1314 1037 1274T933
-1231Q872 1231 829 1269T783 1361Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1141" d="M1065 563H50L93 807H1107L1065 563ZM466 1080Q464 1152 516 1201T646 1251T774 1207T828 1092Q830 1020 778 971T647 921Q568 921 518 967T466 1080ZM326 271Q324 343 376 392T506 442Q586 442 636 397T688 283Q690
-211 638 162T507 112Q428 112 378 158T326 271Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1126" d="M41 544Q61 708 139 838T343 1037T623 1104Q711 1102 795 1076L894 1219L1083 1218L933 1003Q1050 872 1059 675Q1061 618 1053 532Q1023 283 864 129T471 -21Q393 -21 304 3L203 -145L13 -144L164 74Q44 203 36
-402Q33 461 41 544ZM363 527Q347 436 347 370L656 838Q639 844 608 846Q420 849 366 547L363 527ZM746 701L443 241L485 236Q578 234 639 304T728 532Q744 642 746 701Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1130" d="M656 118Q535 -25 364 -21Q205 -19 125 90T62 382L179 1082H508L389 378Q386 349 389 325Q396 243 486 240Q590 236 663 322L797 1082H1128L940 0H634L656 118ZM816 1222H569L340 1534L671 1536L816 1222Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1130" d="M656 118Q535 -25 364 -21Q205 -19 125 90T62 382L179 1082H508L389 378Q386 349 389 325Q396 243 486 240Q590 236 663 322L797 1082H1128L940 0H634L656 118ZM749 1536H1116L797 1222H509L749 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1130" d="M656 118Q535 -25 364 -21Q205 -19 125 90T62 382L179 1082H508L389 378Q386 349 389 325Q396 243 486 240Q590 236 663 322L797 1082H1128L940 0H634L656 118ZM1087 1259V1237L837 1242L707 1377L529 1243L267
-1239L266 1263L614 1536H799L1087 1259Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1130" d="M656 118Q535 -25 364 -21Q205 -19 125 90T62 382L179 1082H508L389 378Q386 349 389 325Q396 243 486 240Q590 236 663 322L797 1082H1128L940 0H634L656 118ZM291 1361Q289 1416 331 1456T435 1499Q496 1499 539
-1461T585 1369Q587 1312 545 1273T442 1231Q380 1231 337 1269T291 1361ZM795 1361Q793 1418 835 1457T938 1499Q999 1499 1043 1461T1089 1369Q1091 1314 1049 1274T945 1231Q884 1231 841 1269T795 1361Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="1039" d="M484 476L764 1082H1127L493 -162Q422 -309 330 -374T109 -440Q52 -440 -36 -418L-11 -177H27Q88 -177 134 -158T211 -82L258 8L85 1082H425L484 476ZM702 1536H1069L750 1222H462L702 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1124" d="M1053 540Q1022 285 896 130T572 -21Q429 -17 343 89L245 -416H-85L254 1536H584L478 995Q583 1104 719 1102Q876 1100 964 991T1059 685Q1061 623 1053 540ZM733 674Q733 839 621 842Q519 848 451 759L373 325Q404
-242 508 240Q685 235 724 540Q733 634 733 674Z" />
-<glyph unicode="&#xff;" horiz-adv-x="1039" d="M484 476L764 1082H1127L493 -162Q422 -309 330 -374T109 -440Q52 -440 -36 -418L-11 -177H27Q88 -177 134 -158T211 -82L258 8L85 1082H425L484 476ZM244 1361Q242 1416 284 1456T388 1499Q449 1499 492 1461T538
-1369Q540 1312 498 1273T395 1231Q333 1231 290 1269T244 1361ZM748 1361Q746 1418 788 1457T891 1499Q952 1499 996 1461T1042 1369Q1044 1314 1002 1274T898 1231Q837 1231 794 1269T748 1361Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1238" d="M1418 578H392L447 842H1473L1418 578Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1505" d="M1701 578H333L406 842H1774L1701 578Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="506" d="M431 1577L580 1494Q536 1424 501 1356T450 1209L421 1042H181L206 1203Q223 1314 285 1409T431 1577Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="492" d="M298 999L149 1082Q210 1179 238 1242T280 1373L308 1536H548L524 1379Q491 1165 298 999Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="549" d="M88 -311L-61 -228Q36 -70 59 63L91 249H343L314 69Q280 -143 88 -311Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="859" d="M438 1577L587 1494Q543 1424 508 1356T457 1209L428 1042H188L213 1203Q230 1314 292 1409T438 1577ZM778 1577L927 1494Q883 1424 848 1356T797 1209L768 1042H528L553 1203Q570 1314 632 1409T778 1577Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="865" d="M312 999L163 1082Q224 1179 252 1242T294 1373L322 1536H562L538 1379Q505 1165 312 999ZM663 999L514 1082Q575 1179 603 1242T645 1373L673 1536H913L889 1379Q856 1165 663 999Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="860" d="M91 -330L-64 -248Q30 -89 56 46L94 269H346L313 69Q274 -166 91 -330ZM432 -330L275 -248Q378 -77 403 33L445 269H698L664 68Q625 -159 432 -330Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="744" d="M156 756Q162 869 233 937T415 1005Q520 1003 583 939T647 766L646 727Q640 618 569 551T387 486Q284 488 220 552T155 718L156 756Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="641" d="M326 499L481 117L294 116L89 505L90 525L412 915H633L326 499Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="611" d="M321 914L525 527L524 505L202 115H-20L287 530L133 913L321 914Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-900italic.ttf b/static/fonts/roboto-v18-latin-900italic.ttf
deleted file mode 100644
index d1f9d3213a..0000000000
Binary files a/static/fonts/roboto-v18-latin-900italic.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900italic.woff b/static/fonts/roboto-v18-latin-900italic.woff
deleted file mode 100644
index c690e47a7a..0000000000
Binary files a/static/fonts/roboto-v18-latin-900italic.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-900italic.woff2 b/static/fonts/roboto-v18-latin-900italic.woff2
deleted file mode 100644
index b7006fb0fe..0000000000
Binary files a/static/fonts/roboto-v18-latin-900italic.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-italic.eot b/static/fonts/roboto-v18-latin-italic.eot
deleted file mode 100644
index 0280829fa2..0000000000
Binary files a/static/fonts/roboto-v18-latin-italic.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-italic.svg b/static/fonts/roboto-v18-latin-italic.svg
deleted file mode 100644
index 4d59797103..0000000000
--- a/static/fonts/roboto-v18-latin-italic.svg
+++ /dev/null
@@ -1,323 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1135" ><font-face
-    font-family="Roboto"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="502" />
-<glyph unicode="!" horiz-adv-x="521" d="M305 411H141L310 1456H500L305 411ZM67 90Q68 137 97 167T174 200Q220 202 250 172T280 96Q280 49 250 20T173 -12T97 15T67 90Z" />
-<glyph unicode="&quot;" horiz-adv-x="645" d="M393 1390L310 1042L200 1041L280 1544L416 1535L393 1390ZM655 1390L572 1042H462L542 1544L678 1535L655 1390Z" />
-<glyph unicode="#" horiz-adv-x="1233" d="M707 410H457L307 0H163L312 410H82L106 547H361L489 901H241L265 1040H539L691 1456H836L683 1040H934L1086 1456H1232L1079 1040H1275L1251 901H1029L901 547H1117L1093 410H852L703 0H557L707 410ZM505 547H755L884
-901H634L505 547Z" />
-<glyph unicode="$" horiz-adv-x="1126" d="M801 382Q811 468 758 532T579 644T377 754Q229 875 243 1071Q254 1235 361 1342T646 1473L685 1692H831L791 1470Q939 1441 1011 1321T1069 1008H890Q898 1155 847 1233T695 1315Q582 1317 509 1252T423 1075Q414 989
-460 927T644 811T852 697T955 560T981 384Q968 213 854 108T550 -17L516 -208H371L406 -15Q242 9 158 126T85 429H266Q255 298 313 220T490 140Q617 138 702 204T801 382Z" />
-<glyph unicode="%" horiz-adv-x="1465" d="M525 1478Q646 1474 717 1390T781 1176L775 1099Q760 965 670 880T454 799Q333 801 260 887T195 1099L201 1163Q214 1307 305 1393T525 1478ZM330 1097Q325 1016 359 969T458 919Q526 917 576 967T638 1099L647 1177Q654
-1253 621 1304T521 1357Q452 1359 401 1308T339 1176L330 1097ZM1070 658Q1194 654 1265 569T1328 357L1322 290Q1309 149 1219 62T1000 -22Q880 -20 807 65T741 279L747 347Q760 486 849 573T1070 658ZM876 277Q871 197 904 149T1004 98Q1074 96 1123 147T1184
-279L1193 358Q1200 433 1167 484T1067 537Q996 539 946 488T885 357L876 277ZM360 112L261 184L1142 1312L1241 1241L360 112Z" />
-<glyph unicode="&amp;" horiz-adv-x="1245" d="M71 384Q86 570 293 716L407 792L364 869Q292 1001 300 1114Q312 1279 420 1379T692 1476Q827 1474 915 1389T995 1176Q986 1004 782 861L635 763L884 382Q975 517 998 672H1159Q1132 417 978 245L1135 0H933L860
-113Q686 -23 477 -19Q288 -17 173 95T71 384ZM483 131Q617 128 767 244L496 668L453 638Q274 514 255 383Q240 275 303 204T483 131ZM478 1121Q470 1037 527 936L554 889L707 992Q814 1072 825 1177Q831 1241 790 1283T681 1325Q598 1325 542 1265T478 1121Z" />
-<glyph unicode="&apos;" horiz-adv-x="356" d="M374 1418L298 1057H170L247 1536H393L374 1418Z" />
-<glyph unicode="(" horiz-adv-x="689" d="M133 587Q166 818 255 1037T475 1410T765 1644L792 1520Q635 1403 523 1215T349 767T290 255Q290 48 343 -109T498 -358L453 -470Q286 -354 198 -127T117 393Q119 489 131 576L133 587Z" />
-<glyph unicode=")" horiz-adv-x="701" d="M547 585Q512 341 420 124T200 -243T-85 -471L-113 -356Q230 -98 345 473Q391 703 389 916Q384 1345 181 1531L228 1643Q340 1565 417 1436T531 1135T564 779Q561 682 549 596L547 585Z" />
-<glyph unicode="*" horiz-adv-x="866" d="M384 987L107 1077L175 1221L453 1108L504 1456H654L584 1112L887 1220L906 1061L591 970L738 695L610 607L479 897L257 617L143 715L384 987Z" />
-<glyph unicode="+" horiz-adv-x="1136" d="M682 781H1076L1045 606H652L572 146H390L470 606H76L107 781H500L574 1206H756L682 781Z" />
-<glyph unicode="," horiz-adv-x="400" d="M-9 -291L-113 -216Q3 -73 31 68L57 219H234L213 84Q177 -144 -9 -291Z" />
-<glyph unicode="-" horiz-adv-x="558" d="M500 543H25L52 694H527L500 543Z" />
-<glyph unicode="." horiz-adv-x="533" d="M164 210Q213 211 245 180T276 100T243 21T163 -12T84 15T53 94T84 175T164 210Z" />
-<glyph unicode="/" horiz-adv-x="829" d="M51 -125H-113L751 1456H914L51 -125Z" />
-<glyph unicode="0" horiz-adv-x="1126" d="M472 -20Q288 -16 196 110T112 475Q114 549 123 621L159 864Q207 1175 342 1328T698 1476Q884 1472 975 1349T1060 990Q1057 915 1048 843L1013 608Q960 279 826 127T472 -20ZM873 876Q887 997 886 1064Q881 1318 689
-1325Q549 1330 463 1222T342 881L299 591Q285 475 286 402Q291 137 482 130Q615 124 701 228T825 558L873 876Z" />
-<glyph unicode="1" horiz-adv-x="1126" d="M604 0H422L636 1228L249 1092L280 1268L820 1463H852L604 0Z" />
-<glyph unicode="2" horiz-adv-x="1126" d="M950 0H23L45 141L582 663L680 760Q849 929 867 1072Q880 1182 824 1251T666 1325Q535 1329 447 1249T340 1028L161 1027Q174 1161 243 1264T426 1423T673 1476Q854 1472 960 1367T1052 1093Q1035 901 831 689L739 596L271
-151H974L950 0Z" />
-<glyph unicode="3" horiz-adv-x="1126" d="M416 818L536 817Q668 817 758 886T862 1075Q875 1191 819 1257T656 1326Q542 1328 463 1260T365 1075L186 1074Q203 1254 339 1366T665 1477Q848 1473 952 1363T1043 1071Q1034 968 964 883T770 742Q869 702 918 616T959
-413Q943 216 803 96T461 -20Q274 -16 163 96T60 385L241 384Q235 272 295 204T469 131Q597 127 682 204T779 410Q790 529 725 595T531 666L392 667L416 818Z" />
-<glyph unicode="4" horiz-adv-x="1126" d="M857 489H1053L1026 338H831L772 0H590L649 338H5L26 457L826 1456H1024L857 489ZM243 489H675L805 1205L776 1163L243 489Z" />
-<glyph unicode="5" horiz-adv-x="1126" d="M219 733L404 1456H1130L1103 1285H533L421 887Q531 952 659 950Q840 948 937 814T1016 471Q997 247 857 111T508 -21Q334 -19 227 91T114 384H283Q290 264 351 198T516 130Q644 126 731 221T835 470Q849 605 788 692T609
-784Q536 786 480 762T367 693L219 733Z" />
-<glyph unicode="6" horiz-adv-x="1126" d="M955 1458L939 1301H904Q704 1297 562 1177T342 823Q478 959 660 955Q775 953 857 892T977 722T1004 482Q984 261 846 118T505 -20Q343 -16 239 99T120 407Q112 512 145 691Q214 1064 417 1261T935 1458H955ZM621 802Q524
-804 439 746T308 598L301 531L299 450Q299 368 324 291T398 174T513 133Q634 128 720 223T824 473Q834 563 813 638T744 756T621 802Z" />
-<glyph unicode="7" horiz-adv-x="1126" d="M1146 1342L355 0H157L944 1304H184L208 1456H1164L1146 1342Z" />
-<glyph unicode="8" horiz-adv-x="1126" d="M1064 1085Q1055 976 987 889T800 744Q894 690 939 600T977 402Q962 209 819 93T474 -20Q285 -16 175 97T80 385Q91 510 168 603T378 755Q300 809 263 891T233 1067Q247 1252 378 1366T700 1476Q874 1472 976 1363T1064
-1085ZM798 406Q810 519 750 594T576 674Q452 676 364 596T262 388Q250 272 310 202T482 130Q608 126 696 203T798 406ZM882 1082Q893 1183 841 1252T691 1325Q579 1327 502 1254T412 1064Q401 960 454 893T605 824Q714 822 791 894T882 1082Z" />
-<glyph unicode="9" horiz-adv-x="1126" d="M823 640Q749 562 666 524T501 487Q386 489 305 552T186 725T160 965Q173 1109 241 1229T418 1414T660 1476Q834 1472 933 1350T1040 1023Q1043 916 1015 757Q949 383 755 194T255 -2H210L226 154H263Q478 158 615 274T823
-640ZM539 640Q630 636 714 691T852 841L860 914L863 995Q859 1150 806 1234T652 1322Q528 1327 441 1227T339 975Q332 914 341 851T377 740Q431 643 539 640Z" />
-<glyph unicode=":" horiz-adv-x="491" d="M410 210Q459 211 491 180T522 100T489 21T409 -12T330 15T299 94T330 175T410 210ZM307 1093Q356 1094 388 1063T419 983T386 904T306 871T227 898T196 977T227 1058T307 1093Z" />
-<glyph unicode=";" horiz-adv-x="430" d="M284 1093Q333 1094 365 1063T396 983T363 904T283 871T204 898T173 977T204 1058T284 1093ZM3 -291L-101 -216Q15 -73 43 68L69 219H246L225 84Q189 -144 3 -291Z" />
-<glyph unicode="&lt;" horiz-adv-x="1020" d="M263 640L828 387L795 200L65 579L91 725L952 1103L916 898L263 640Z" />
-<glyph unicode="=" horiz-adv-x="1100" d="M994 814H184L212 975H1023L994 814ZM922 399H112L140 559H951L922 399Z" />
-<glyph unicode="&gt;" horiz-adv-x="1048" d="M781 654L183 913L216 1095L980 716L954 571L58 191L94 392L781 654Z" />
-<glyph unicode="?" horiz-adv-x="948" d="M321 409Q334 524 382 612T538 796L619 867Q744 978 760 1100Q772 1194 729 1253T595 1316Q493 1318 428 1262T345 1116L165 1115Q184 1280 306 1379T606 1477Q774 1473 866 1371T945 1104Q928 922 741 754L619 650Q521
-561 498 410L321 409ZM250 90Q251 137 280 167T357 200Q403 201 433 172T463 95Q463 49 433 19T356 -12Q309 -14 280 15T250 90Z" />
-<glyph unicode="@" horiz-adv-x="1794" d="M1199 -20Q1110 -18 1056 26T988 148Q852 -24 709 -21Q593 -19 537 72T493 319Q503 480 579 647T765 903T1005 990Q1144 987 1277 885L1144 327Q1134 261 1134 234Q1129 99 1226 96Q1373 90 1464 261T1566 702Q1573 882
-1520 1019T1352 1226T1067 1299Q846 1303 657 1176T346 806T211 284Q203 103 258 -39T425 -253T699 -327Q868 -331 1038 -249L1065 -366Q926 -453 697 -453Q506 -452 365 -369T147 -125T70 246Q68 463 147 688T368 1085T690 1345T1071 1431Q1265 1428 1404 1344T1617
-1099T1691 734Q1691 509 1626 333T1450 67T1199 -20ZM649 294Q644 123 761 120Q868 115 961 264L993 317L994 328L1127 834Q1075 862 1020 863Q881 868 785 728T654 351L649 294Z" />
-<glyph unicode="A" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538Z" />
-<glyph unicode="B" horiz-adv-x="1247" d="M59 0L312 1456L739 1455Q962 1455 1073 1355T1170 1076Q1152 867 907 761Q1005 723 1053 631T1093 428Q1078 231 935 116T565 0H59ZM365 681L274 157L571 156Q707 156 799 229T906 426Q920 544 865 610T692 680L365
-681ZM392 835L663 834Q790 834 877 899T980 1078Q993 1184 939 1238T758 1297L472 1298L392 835Z" />
-<glyph unicode="C" horiz-adv-x="1303" d="M1169 464Q1127 238 965 106T575 -20Q440 -17 339 46T182 229T120 494Q116 576 127 654L144 774Q191 1102 374 1291T821 1476Q1026 1472 1146 1344T1273 987H1086Q1073 1293 846 1317L813 1319Q624 1324 498 1179T334
-781L312 630L306 542Q300 358 371 250T584 137Q736 132 835 210T987 461L1169 464Z" />
-<glyph unicode="D" horiz-adv-x="1313" d="M59 0L312 1456L690 1455Q868 1455 996 1366T1181 1121T1214 770L1204 697Q1160 379 957 190T447 0H59ZM472 1298L274 157L459 156Q671 156 818 288T1010 650Q1045 834 1034 963Q1019 1118 931 1205T695 1297L472 1298Z" />
-<glyph unicode="E" horiz-adv-x="1139" d="M976 673H364L274 157H986L958 0H59L312 1456H1201L1173 1298H472L391 830H1003L976 673Z" />
-<glyph unicode="F" horiz-adv-x="1108" d="M951 643H359L247 0H59L312 1456H1188L1160 1298H472L386 800H979L951 643Z" />
-<glyph unicode="G" horiz-adv-x="1363" d="M1147 192Q1074 89 935 34T616 -20Q473 -17 366 47T198 230T128 502Q121 621 157 824T285 1175T512 1401T825 1476Q1028 1472 1148 1356T1286 1028H1100Q1089 1166 1017 1240T818 1318Q630 1325 504 1183T337 768L318
-628L315 552Q315 355 396 248T623 138Q834 133 958 242L1018 569H690L718 725H1230L1147 192Z" />
-<glyph unicode="H" horiz-adv-x="1426" d="M1146 0H958L1075 673H364L247 0H59L312 1456H500L391 830H1101L1210 1456H1399L1146 0Z" />
-<glyph unicode="I" horiz-adv-x="550" d="M260 0H73L326 1456H513L260 0Z" />
-<glyph unicode="J" horiz-adv-x="1106" d="M910 1456H1098L923 425Q894 219 756 97T412 -22Q220 -18 115 94T22 402H209Q198 282 254 211T422 137Q545 133 630 214T734 424L910 1456Z" />
-<glyph unicode="K" horiz-adv-x="1255" d="M544 675L331 484L247 0H59L312 1456H500L376 747L1118 1456H1360L683 804L1136 0H927L544 675Z" />
-<glyph unicode="L" horiz-adv-x="1079" d="M275 157H945L917 0H59L312 1456H501L275 157Z" />
-<glyph unicode="M" horiz-adv-x="1744" d="M549 1456L804 270L1472 1456H1719L1466 0H1279L1379 576L1498 1162L838 0H694L434 1185L344 557L247 0H59L312 1456H549Z" />
-<glyph unicode="N" horiz-adv-x="1426" d="M1146 0H964L444 1130L248 0H59L312 1456H494L1015 321L1212 1456H1399L1146 0Z" />
-<glyph unicode="O" horiz-adv-x="1376" d="M593 -20Q454 -17 352 47T190 235T125 515Q119 636 152 814T266 1135T463 1364Q620 1480 821 1476Q1034 1472 1157 1329T1289 940Q1293 835 1268 673T1177 372T1010 139Q834 -25 593 -20ZM1104 894Q1110 1091 1035 1199T812
-1312Q678 1316 573 1240T400 1013T314 629L311 564Q305 368 381 257T602 142Q791 137 915 278T1081 676Q1101 802 1104 894Z" />
-<glyph unicode="P" horiz-adv-x="1263" d="M346 570L247 0H59L312 1456L798 1455Q1023 1455 1145 1336T1250 1018Q1232 809 1084 689T692 569L346 570ZM373 727L697 726Q850 726 948 803T1063 1017Q1079 1140 1012 1216T817 1297L472 1298L373 727Z" />
-<glyph unicode="Q" horiz-adv-x="1376" d="M907 76L1124 -133L985 -246L731 -3Q657 -19 583 -19Q446 -18 342 47T181 236T117 516Q111 642 143 816T255 1131T446 1358Q606 1480 812 1476Q953 1473 1057 1408T1218 1220T1281 940Q1284 856 1274 773L1262 688Q1200
-257 907 76ZM1095 894Q1102 1094 1026 1201T804 1312Q670 1316 565 1240T392 1013T306 629L303 564Q299 449 330 349T428 197T594 142Q778 135 903 275T1071 670Q1092 797 1095 894Z" />
-<glyph unicode="R" horiz-adv-x="1233" d="M685 589H349L247 0H58L311 1456L749 1455Q978 1454 1098 1339T1199 1026Q1188 889 1100 785T864 628L1090 13L1089 0H889L685 589ZM376 746L652 745Q796 745 895 821T1011 1026Q1026 1151 961 1222T763 1297L472 1298L376 746Z" />
-<glyph unicode="S" horiz-adv-x="1189" d="M877 375Q899 535 711 609L538 672L480 697Q188 830 207 1071Q217 1192 290 1285T483 1428T740 1476Q872 1473 975 1417T1133 1261T1181 1034L992 1035Q1002 1169 932 1242T732 1318Q595 1320 503 1254T397 1074Q377
-925 580 848L729 795L804 763Q1086 633 1065 377Q1054 254 982 165T787 26T521 -20Q384 -19 271 38T98 196T46 423L234 422Q225 292 304 216T529 137T768 200T877 375Z" />
-<glyph unicode="T" horiz-adv-x="1195" d="M1261 1298H808L583 0H396L621 1298H168L196 1456H1289L1261 1298Z" />
-<glyph unicode="U" horiz-adv-x="1298" d="M1312 1456L1144 471Q1110 244 948 110T557 -21Q414 -18 309 43T153 216T120 470L288 1456H473L306 469Q289 316 358 229T567 137Q719 131 823 219T955 468L1123 1456H1312Z" />
-<glyph unicode="V" horiz-adv-x="1274" d="M574 257L1165 1456H1377L625 0H459L164 1456H361L574 257Z" />
-<glyph unicode="W" horiz-adv-x="1772" d="M446 449L442 273L510 445L945 1456H1104L1219 432L1229 266L1292 467L1664 1456H1857L1287 0H1116L990 1069L986 1169L944 1053L480 0H309L195 1456H378L446 449Z" />
-<glyph unicode="X" horiz-adv-x="1255" d="M666 899L1091 1456H1323L756 725L1095 0H884L626 567L188 0H-44L535 743L205 1456H413L666 899Z" />
-<glyph unicode="Y" horiz-adv-x="1203" d="M611 726L1106 1456H1330L677 533L584 0H397L493 554L168 1456H372L611 726Z" />
-<glyph unicode="Z" horiz-adv-x="1199" d="M234 157H1036L1008 0H-21L6 154L972 1298H216L244 1456H1230L1204 1305L234 157Z" />
-<glyph unicode="[" horiz-adv-x="537" d="M650 1512H465L204 -160H390L366 -312H-1L307 1664H675L650 1512Z" />
-<glyph unicode="\" horiz-adv-x="825" d="M191 1456H355L670 -125H507L191 1456Z" />
-<glyph unicode="]" horiz-adv-x="537" d="M175 1664H543L234 -312H-134L-110 -160H77L338 1512H150L175 1664Z" />
-<glyph unicode="^" horiz-adv-x="840" d="M524 1209L256 729H79L496 1456H620L783 729H625L524 1209Z" />
-<glyph unicode="_" horiz-adv-x="906" d="M763 -151H-127L-100 0H790L763 -151Z" />
-<glyph unicode="`" horiz-adv-x="624" d="M555 1242H413L208 1536H413L555 1242Z" />
-<glyph unicode="a" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140Z" />
-<glyph unicode="b" horiz-adv-x="1125" d="M1013 536Q993 370 922 237T750 40T526 -21Q330 -17 235 126L198 0H31L298 1536H479L370 962Q500 1106 686 1102Q842 1098 929 987T1021 681Q1022 617 1015 557L1013 536ZM841 641Q844 787 792 864T633 946Q464 950 347
-776L266 305Q326 140 491 136Q597 132 676 199T797 386T841 641Z" />
-<glyph unicode="c" horiz-adv-x="1050" d="M488 130Q585 128 663 186T765 340L936 341Q921 239 855 155T687 24T480 -20Q345 -18 252 50T114 241T84 517L89 567Q108 723 180 846T368 1037T624 1102Q794 1098 896 988T998 709L829 710Q827 816 770 881T616 951Q475
-954 382 846T265 544L262 518Q256 454 260 386Q267 269 326 201T488 130Z" />
-<glyph unicode="d" horiz-adv-x="1130" d="M83 543Q103 708 174 841T349 1040T578 1103Q759 1099 856 971L960 1536H1141L875 0H710L729 116Q601 -24 413 -20Q263 -16 174 97T78 402Q75 461 83 543ZM257 439Q254 296 308 217T466 136Q623 129 745 294L831 794Q771
-942 613 946Q506 949 425 882T301 693T257 439Z" />
-<glyph unicode="e" horiz-adv-x="1062" d="M499 -20Q297 -16 183 129T87 500L92 543Q109 704 187 837T379 1037T623 1102Q790 1098 885 991T989 701Q992 636 985 571L974 488H267Q249 341 315 238T514 131Q674 127 810 275L914 187Q846 89 739 34T499 -20ZM614
-951Q502 954 419 875T286 640L812 639L816 655Q832 781 776 864T614 951Z" />
-<glyph unicode="f" horiz-adv-x="700" d="M119 0L283 939H116L141 1082H307L325 1210Q351 1373 451 1465Q556 1561 719 1559Q770 1559 848 1542L826 1391Q778 1401 729 1403Q635 1403 577 1345T504 1189L488 1082H712L687 939H463L300 0H119Z" />
-<glyph unicode="g" horiz-adv-x="1125" d="M84 543Q108 720 179 850T353 1043T578 1103Q766 1099 862 961L898 1082H1064L884 23Q855 -184 716 -308T373 -427Q263 -425 163 -375T4 -238L107 -127Q205 -272 366 -276Q495 -280 584 -204T703 12L723 108Q591 -24
-414 -20Q313 -17 239 34T123 183T78 401Q76 460 84 543ZM259 440Q256 297 308 219T467 136Q629 132 746 295L831 792Q771 940 614 946Q467 950 373 826T261 491L259 440Z" />
-<glyph unicode="h" horiz-adv-x="1104" d="M369 950Q511 1105 696 1101Q848 1099 921 997T976 709L858 0H677L796 712Q802 761 797 803Q780 943 632 946Q466 950 346 772L212 0H31L298 1536H479L369 950Z" />
-<glyph unicode="i" horiz-adv-x="492" d="M227 0H47L235 1082H415L227 0ZM376 1477Q422 1479 452 1450T483 1372Q482 1325 453 1295T376 1263T299 1290T270 1366T300 1444T376 1477Z" />
-<glyph unicode="j" horiz-adv-x="484" d="M406 1082L201 -129Q181 -282 99 -362T-117 -440Q-170 -438 -236 -420L-220 -272Q-183 -281 -137 -283Q-8 -283 18 -129L225 1082H406ZM256 1366Q257 1413 285 1444T362 1477Q408 1479 438 1449T469 1372Q468 1325 438
-1295T361 1263Q316 1261 286 1291T256 1366Z" />
-<glyph unicode="k" horiz-adv-x="1017" d="M419 499L277 372L213 0H32L299 1536H480L320 618L431 730L815 1082H1050L553 621L895 0H697L419 499Z" />
-<glyph unicode="l" horiz-adv-x="492" d="M227 0H47L313 1536H494L227 0Z" />
-<glyph unicode="m" horiz-adv-x="1751" d="M388 1083L365 962Q501 1106 694 1102Q797 1100 868 1055T967 928Q1119 1106 1326 1102Q1488 1098 1565 993T1622 711L1503 0H1323L1441 713Q1447 765 1441 808Q1422 944 1263 947Q1164 949 1084 886T980 719L857 0H675L795
-712Q808 823 762 883T617 945Q448 949 348 791L211 0H30L218 1082L388 1083Z" />
-<glyph unicode="n" horiz-adv-x="1106" d="M390 1083L364 946Q510 1106 696 1102Q849 1098 922 996T976 709L858 0H677L796 712Q802 761 797 803Q780 943 632 946Q469 949 346 772L212 0H31L219 1082L390 1083Z" />
-<glyph unicode="o" horiz-adv-x="1143" d="M632 1102Q768 1100 865 1028T1008 830T1040 553L1038 531Q1019 373 944 246T750 47T489 -20Q354 -18 257 54T114 250T82 523Q97 691 173 825T368 1032T632 1102ZM264 522Q257 459 264 391Q274 273 334 203T496 130Q586
-127 662 174T790 318T857 531Q865 623 860 686Q848 807 787 877T625 951Q485 954 387 841T266 545L264 522Z" />
-<glyph unicode="p" horiz-adv-x="1125" d="M1011 536Q991 371 922 239T751 42T525 -21Q337 -17 237 106L140 -416H-41L219 1082L383 1083L363 962Q497 1106 684 1102Q840 1098 927 987T1019 681Q1020 617 1014 557L1011 536ZM833 557L838 641Q838 787 783 864T622
-946Q465 950 351 797L260 278Q321 134 479 130Q614 127 708 235T833 557Z" />
-<glyph unicode="q" horiz-adv-x="1139" d="M585 1103Q768 1099 864 972L897 1082H1064L804 -416H624L722 100Q592 -24 420 -20Q268 -18 177 95T79 400Q73 524 108 661T212 901T377 1055T585 1103ZM265 522L260 438Q257 293 312 213T472 130Q625 126 743 276L837
-808Q771 947 621 951Q484 954 390 846T265 522Z" />
-<glyph unicode="r" horiz-adv-x="682" d="M704 917L619 926Q445 926 345 769L212 0H31L219 1082L394 1083L367 957Q482 1108 638 1104Q671 1104 724 1089L704 917Z" />
-<glyph unicode="s" horiz-adv-x="1034" d="M701 293Q716 405 578 451L390 506Q152 588 160 778Q167 921 290 1012T581 1102Q745 1100 847 1007T946 763L766 764Q768 845 715 896T574 949Q480 951 412 903Q349 858 339 785Q326 691 454 648L545 623Q731 575 809
-498T881 307Q875 206 815 131T655 17T442 -20Q270 -18 158 80T50 334L231 333Q231 242 289 187T448 132Q547 130 619 173T701 293Z" />
-<glyph unicode="t" horiz-adv-x="659" d="M509 1344L463 1082H660L635 939H439L326 266Q323 240 325 218Q332 140 410 140Q443 140 498 150L484 -1Q419 -19 352 -19Q244 -17 190 60T148 269L258 939H67L92 1082H283L329 1344H509Z" />
-<glyph unicode="u" horiz-adv-x="1105" d="M718 107Q591 -24 395 -20Q240 -16 166 91T110 383L226 1082H407L290 380Q285 336 288 294Q293 222 331 181T437 137Q631 131 737 294L873 1082H1054L866 0H695L718 107Z" />
-<glyph unicode="v" horiz-adv-x="972" d="M424 253L814 1082H1005L460 0H322L110 1082H288L424 253Z" />
-<glyph unicode="w" horiz-adv-x="1503" d="M1002 256L1347 1082H1534L1041 0H894L782 818L392 0H245L128 1082H301L367 276L751 1082H897L1002 256Z" />
-<glyph unicode="x" horiz-adv-x="995" d="M496 688L790 1082H1012L578 538L842 0H645L466 404L161 0H-60L387 556L131 1082H329L496 688Z" />
-<glyph unicode="y" horiz-adv-x="950" d="M419 273L804 1082H1004L362 -180Q228 -443 18 -440Q-19 -439 -91 -422L-75 -272L-28 -277Q58 -281 120 -239T231 -101L296 23L109 1082H298L419 273Z" />
-<glyph unicode="z" horiz-adv-x="995" d="M234 151H842L815 0H-19L6 145L715 929H150L178 1082H974L950 942L234 151Z" />
-<glyph unicode="{" horiz-adv-x="682" d="M478 -365Q320 -312 246 -193T191 99L219 306Q225 355 220 397Q203 533 56 541L72 686Q289 696 321 931L352 1159Q411 1498 762 1599L789 1482Q577 1412 532 1145L498 905Q465 705 287 611Q390 534 400 392Q403 348 399
-305L368 62L366 -9L368 -40Q385 -199 519 -252L478 -365Z" />
-<glyph unicode="|" horiz-adv-x="494" d="M179 -270H33L303 1456H449L179 -270Z" />
-<glyph unicode="}" horiz-adv-x="682" d="M-116 -251Q101 -180 144 93L175 319Q206 527 401 620Q288 689 275 836Q271 878 276 923L307 1169L309 1240Q306 1424 157 1482L202 1595Q358 1542 430 1423T483 1132L456 924Q450 874 455 833Q471 698 618 690L603 545Q385
-535 353 297L325 90Q274 -264 -88 -368L-116 -251Z" />
-<glyph unicode="~" horiz-adv-x="1361" d="M1245 778Q1231 615 1134 507T896 400Q770 403 647 515L587 573Q515 640 449 640Q313 643 269 476L261 439L105 436Q121 598 218 702T457 803Q576 800 684 707L773 624Q841 563 904 563Q979 563 1031 618T1102 775L1245 778Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="502" />
-<glyph unicode="&#xa1;" horiz-adv-x="494" d="M179 684H344L175 -360H-15L179 684ZM416 999Q416 952 387 921T310 888T233 917T203 993Q204 1041 233 1070T310 1102Q356 1103 386 1074T416 999Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1096" d="M489 130Q586 128 664 185T770 340L942 341Q921 207 817 113T552 -12L506 -245H325L372 -9Q253 21 181 115T94 350Q82 461 104 594T186 833T340 1004T552 1092L597 1318H778L733 1093Q864 1061 937 960T1011 709H841Q841
-815 785 881T632 951Q480 957 381 829T268 473L267 431Q264 289 322 211T489 130Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1164" d="M440 622L412 410Q392 257 304 154L1019 157L990 0H-13L16 156L83 154Q196 195 225 416L252 622H92L119 779H275L306 1032Q331 1236 470 1359T801 1476Q969 1472 1065 1368T1153 1086L966 1087Q973 1193 924 1254T774
-1319Q664 1323 587 1241T494 1030L462 779H772L745 622H440Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1426" d="M996 110Q809 -24 619 -20Q420 -16 284 110L127 -26L18 118L177 252Q147 337 137 424Q118 574 162 718T311 980L194 1137L335 1264L449 1116Q628 1238 810 1234Q998 1232 1135 1113L1310 1265L1421 1119L1248 972Q1280
-885 1292 796Q1310 652 1270 511T1130 250L1245 100L1102 -27L996 110ZM304 599Q289 485 326 381T442 216T630 150Q747 146 854 209T1034 383T1123 617Q1137 732 1101 835T985 998T798 1063Q680 1067 572 1004T392 831T304 599Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1053" d="M552 794L965 1456H1183L702 736H950L928 611H614L585 446H900L878 322H564L508 0H319L376 322H67L89 446H397L426 611H117L139 736H399L168 1456H368L552 794Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="486" d="M-9 -270L129 521H311L173 -270H-9ZM341 698H159L291 1456H473L341 698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1228" d="M1087 439Q1069 248 858 152Q961 49 948 -120Q934 -294 790 -396T424 -496Q207 -492 86 -377T-24 -63L157 -62Q151 -147 182 -210T279 -307T432 -343Q515 -345 589 -318T709 -242T764 -123Q776 -46 723 9T531 109T312
-192Q70 307 90 543Q104 727 314 830Q215 936 228 1102Q236 1210 303 1296T489 1430Q612 1478 753 1476Q960 1472 1072 1358T1173 1045H993Q1001 1171 935 1246T745 1325Q610 1327 519 1269T412 1105Q401 1024 449 970T632 873T839 800Q1108 684 1087 439ZM616 691L462
-743Q295 696 273 545Q259 445 334 384Q384 343 513 303T707 237Q881 289 903 436Q914 509 867 565T700 663L616 691Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="840" d="M218 1369Q219 1415 248 1445T325 1478Q371 1479 401 1450T431 1373Q431 1327 401 1297T324 1265Q277 1264 248 1293T218 1369ZM635 1367Q636 1413 665 1444T741 1477Q789 1478 819 1449T848 1371Q848 1324 818 1295T741
-1263Q695 1262 665 1291T635 1367Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1571" d="M1093 597Q1079 446 986 363T744 283Q599 287 519 395T453 670L463 768Q483 957 586 1066T847 1174Q989 1170 1066 1089T1138 859L995 860Q1001 945 967 994T842 1045Q747 1047 684 975T606 775T592 617L594 582Q601
-505 640 460T748 412Q918 405 953 596L1093 597ZM230 570Q252 363 382 232T702 98Q889 94 1055 205T1313 507T1385 888Q1363 1093 1235 1222T914 1356Q725 1360 559 1248T301 948T230 570ZM119 722Q141 921 255 1099T544 1378T913 1476Q1091 1474 1233 1376T1446
-1105T1496 735Q1473 532 1359 355T1073 78T713 -21H703Q520 -17 380 81T169 352T119 722Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="898" d="M630 703L626 777Q534 691 420 691Q315 691 255 752T199 911Q204 1026 297 1088T557 1150L668 1149L677 1203Q680 1230 678 1254Q671 1333 586 1336Q530 1337 487 1313T428 1232L272 1243Q283 1352 371 1415T590
-1477Q713 1473 779 1399T836 1200L782 853L778 795Q777 750 785 704L630 703ZM460 826Q535 826 626 894L654 1037H561Q473 1034 421 1002T361 915Q356 872 383 849T460 826Z" />
-<glyph unicode="&#xab;" horiz-adv-x="942" d="M517 794L695 407H570L345 794L347 814L694 1203H846L517 794ZM581 538L759 151H634L409 538L411 558L758 947H910L581 538Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1110" d="M891 375H709L756 639H129L158 800H965L891 375Z" />
-<glyph unicode="&#xad;" horiz-adv-x="558" d="M500 543H25L52 694H527L500 543Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1572" d="M118 722Q140 921 254 1099T543 1378T912 1476Q1087 1474 1228 1379T1443 1110T1495 735Q1472 531 1357 354T1069 75T703 -22Q524 -18 384 77T171 348T118 722ZM229 569Q241 438 305 328T472 159T701 97Q888 93
-1053 203T1311 503T1385 888Q1371 1021 1307 1129T1141 1295T913 1356Q728 1360 563 1253T304 956T229 569ZM654 654L601 316H463L596 1165L853 1164Q992 1159 1066 1095T1134 916Q1131 858 1097 810T982 716Q1059 672 1068 575L1067 514Q1056 427 1058 396L1061
-332L1059 315H921Q915 352 917 388L924 460L930 514Q937 580 913 614T821 653L654 654ZM673 782L816 781Q888 783 938 817T998 910Q1008 973 976 1004T854 1038H714L673 782Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="920" d="M900 1302H247L270 1445H923L900 1302Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="752" d="M236 1207Q240 1318 320 1398T504 1477Q601 1475 664 1401T726 1225Q722 1113 643 1035T461 959Q363 961 298 1033T236 1207ZM357 1209Q351 1160 381 1124T461 1087Q515 1087 557 1127T606 1223Q612 1271 584 1310T504
-1350Q450 1350 407 1308T357 1209Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1071" d="M670 854H1023L999 703H647L582 289H418L483 703H109L134 854H507L572 1267H735L670 854ZM848 0H37L61 152H872L848 0Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="738" d="M674 667H92L112 783L467 1081Q566 1165 578 1239Q585 1287 559 1314T484 1342Q418 1343 378 1306T324 1206L170 1205Q181 1322 268 1396T483 1469Q603 1467 672 1404T737 1239Q729 1116 578 991L514 940L318 795H697L674
-667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="738" d="M343 1126L421 1125Q487 1127 533 1157T587 1242Q593 1291 562 1315T481 1340Q369 1340 340 1247H184Q195 1348 274 1408T479 1469Q605 1466 676 1407T742 1251Q735 1132 583 1066Q701 1023 697 894Q692 783 602
-719T378 656Q259 658 185 720T110 890H261Q261 840 294 813T385 785Q449 785 494 817T547 902Q560 1004 419 1009L332 1010L343 1126Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="633" d="M447 1536H678L372 1242H213L447 1536Z" />
-<glyph unicode="&#xb5;" d="M414 1082L311 458Q301 374 304 316Q314 133 460 130Q643 124 740 281L879 1082H1061L873 0H711L730 115Q619 -23 457 -21Q322 -21 242 54L153 -416H-27L233 1082H414Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="981" d="M532 0L623 520L559 521Q348 524 236 651T143 980Q157 1122 231 1231T425 1398T689 1457L966 1456L714 0H532Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="528" d="M165 726Q166 775 196 807T277 842Q325 844 357 813T389 732Q388 683 356 652T275 618Q230 616 198 645T165 726Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="502" d="M167 0L146 -55Q275 -84 271 -218Q268 -320 181 -377T-56 -437L-52 -329Q114 -323 130 -222Q142 -151 38 -139L-8 -133L38 0H167Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="738" d="M492 667H338L442 1264L222 1208L246 1343L602 1456H623L492 667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="913" d="M589 1477Q730 1473 810 1375T878 1123L871 1052Q854 886 750 786T495 689Q353 693 273 793T205 1043L212 1113Q229 1281 334 1381T589 1477ZM365 1041Q355 945 391 888T504 828Q583 825 639 882T710 1043L719 1124Q727
-1226 690 1280T581 1337Q499 1339 443 1281T373 1123L365 1041Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="941" d="M291 949L516 562L514 541L167 152H15L343 560L166 949H291ZM629 949L854 562L852 541L505 152H353L681 560L504 949H629Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1465" d="M455 664H301L405 1261L185 1205L209 1340L565 1453H586L455 664ZM354 120L256 192L1137 1320L1235 1248L354 120ZM1227 299H1331L1308 169H1205L1175 0H1021L1051 169H688L701 281L1148 789H1312L1227 299ZM865
-299H1073L1131 590L1109 560L865 299Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1551" d="M311 120L213 192L1094 1320L1192 1248L311 120ZM450 664H296L400 1261L180 1205L204 1340L560 1453H581L450 664ZM1333 0H751L771 116L1126 414Q1225 498 1237 572Q1244 620 1218 647T1143 675Q1077 676 1037 639T983
-539L829 538Q840 655 927 729T1142 802Q1262 800 1331 737T1396 572Q1388 449 1237 324L1173 273L977 128H1356L1333 0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1555" d="M477 120L379 192L1260 1320L1358 1248L477 120ZM1316 299H1420L1397 169H1294L1264 0H1110L1140 169H777L790 281L1237 789H1401L1316 299ZM954 299H1162L1220 590L1198 560L954 299ZM391 1126L469 1125Q535 1127
-581 1157T635 1242Q641 1291 610 1315T529 1340Q417 1340 388 1247H232Q243 1348 322 1408T527 1469Q653 1466 724 1407T790 1251Q783 1132 631 1066Q749 1023 745 894Q740 783 650 719T426 656Q307 658 233 720T158 890H309Q309 840 342 813T433 785Q497 785 542
-817T595 902Q608 1004 467 1009L380 1010L391 1126Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="950" d="M584 681Q572 572 531 492T384 311L287 220Q168 105 155 -10Q142 -108 189 -166T329 -226Q427 -228 493 -172T578 -21L758 -20Q739 -187 617 -288T318 -386Q145 -382 50 -281T-30 -14Q-15 169 176 344L292 446Q383
-531 408 680L584 681ZM654 1000Q654 953 625 922T548 889Q500 887 471 918T441 994Q442 1041 472 1070T548 1102Q594 1103 624 1075T654 1000Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538ZM916 1552H774L569 1846H774L916 1552Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538ZM946 1846H1177L871 1552H712L946 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538ZM1117 1574V1560L970 1562L857 1731L681 1563L528 1560V1576L806 1846H912L1117 1574Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538ZM1199 1815Q1187 1704 1126 1637T972 1570Q935 1570 905 1585T844 1620T783 1654T716 1668Q631 1665 600 1556L478 1563Q490
-1673 552 1743T708 1811Q735 1811 758 1803T835 1762T912 1720T964 1712Q1050 1712 1082 1825L1199 1815Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538ZM525 1679Q526 1725 555 1755T632 1788Q678 1789 708 1760T738 1683Q738 1637 708 1607T631 1575Q584 1574 555 1603T525
-1679ZM942 1677Q943 1723 972 1754T1048 1787Q1096 1788 1126 1759T1155 1681Q1155 1634 1125 1605T1048 1573Q1002 1572 972 1601T942 1677Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1306" d="M909 380H319L120 0H-81L710 1456H875L1163 0H978L909 380ZM402 538H881L760 1217L402 538ZM641 1721Q643 1812 707 1875T861 1938Q943 1938 1000 1880T1058 1737Q1056 1648 992 1586T838 1524Q754 1524 697 1581T641
-1721ZM737 1723Q733 1677 760 1646T830 1614Q876 1614 915 1649T961 1735Q967 1781 939 1814T869 1847Q823 1847 783 1811T737 1723Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1867" d="M1719 0H862L909 353H369L108 0H-124L982 1456H1912L1885 1304H1215L1152 833H1726L1699 682H1132L1061 151H1746L1719 0ZM496 527H932L1028 1249L496 527Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1303" d="M1169 464Q1127 238 965 106T575 -20Q440 -17 339 46T182 229T120 494Q116 576 127 654L144 774Q191 1102 374 1291T821 1476Q1026 1472 1146 1344T1273 987H1086Q1073 1293 846 1317L813 1319Q624 1324 498 1179T334
-781L312 630L306 542Q300 358 371 250T584 137Q736 132 835 210T987 461L1169 464ZM617 -9L596 -64Q725 -93 721 -227Q718 -329 631 -386T394 -446L398 -338Q564 -332 580 -231Q592 -160 488 -148L442 -142L488 -9H617Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1139" d="M976 673H364L274 157H986L958 0H59L312 1456H1201L1173 1298H472L391 830H1003L976 673ZM866 1564H724L519 1858H724L866 1564Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1139" d="M976 673H364L274 157H986L958 0H59L312 1456H1201L1173 1298H472L391 830H1003L976 673ZM896 1858H1127L821 1564H662L896 1858Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1139" d="M976 673H364L274 157H986L958 0H59L312 1456H1201L1173 1298H472L391 830H1003L976 673ZM1067 1586V1572L920 1574L807 1743L631 1575L478 1572V1588L756 1858H862L1067 1586Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1139" d="M976 673H364L274 157H986L958 0H59L312 1456H1201L1173 1298H472L391 830H1003L976 673ZM475 1691Q476 1737 505 1767T582 1800Q628 1801 658 1772T688 1695Q688 1649 658 1619T581 1587Q534 1586 505 1615T475
-1691ZM892 1689Q893 1735 922 1766T998 1799Q1046 1800 1076 1771T1105 1693Q1105 1646 1075 1617T998 1585Q952 1584 922 1613T892 1689Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="550" d="M260 0H73L326 1456H513L260 0ZM537 1564H395L190 1858H395L537 1564Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="550" d="M260 0H73L326 1456H513L260 0ZM566 1858H797L491 1564H332L566 1858Z" />
-<glyph unicode="&#xce;" horiz-adv-x="550" d="M260 0H73L326 1456H513L260 0ZM738 1586V1572L591 1574L478 1743L302 1575L149 1572V1588L427 1858H533L738 1586Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="550" d="M260 0H73L326 1456H513L260 0ZM146 1691Q147 1737 176 1767T253 1800Q299 1801 329 1772T359 1695Q359 1649 329 1619T252 1587Q205 1586 176 1615T146 1691ZM563 1689Q564 1735 593 1766T669 1799Q717 1800 747
-1771T776 1693Q776 1646 746 1617T669 1585Q623 1584 593 1613T563 1689Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1343" d="M89 0L204 666H17L44 817H231L342 1456L720 1455Q898 1455 1026 1366T1211 1121T1244 770L1234 697Q1190 379 987 190T477 0H89ZM635 666H392L304 157L489 156Q701 156 848 288T1040 650Q1075 834 1064 963Q1049
-1118 961 1205T725 1297L502 1298L418 817H662L635 666Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1426" d="M1146 0H964L444 1130L248 0H59L312 1456H494L1015 321L1212 1456H1399L1146 0ZM1251 1815Q1239 1704 1178 1637T1024 1570Q987 1570 957 1585T896 1620T835 1654T768 1668Q683 1665 652 1556L530 1563Q542 1673
-604 1743T760 1811Q787 1811 810 1803T887 1762T964 1720T1016 1712Q1102 1712 1134 1825L1251 1815Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1376" d="M593 -20Q454 -17 352 47T190 235T125 515Q119 636 152 814T266 1135T463 1364Q620 1480 821 1476Q1034 1472 1157 1329T1289 940Q1293 835 1268 673T1177 372T1010 139Q834 -25 593 -20ZM1104 894Q1110 1091 1035
-1199T812 1312Q678 1316 573 1240T400 1013T314 629L311 564Q305 368 381 257T602 142Q791 137 915 278T1081 676Q1101 802 1104 894ZM949 1554H807L602 1848H807L949 1554Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1376" d="M593 -20Q454 -17 352 47T190 235T125 515Q119 636 152 814T266 1135T463 1364Q620 1480 821 1476Q1034 1472 1157 1329T1289 940Q1293 835 1268 673T1177 372T1010 139Q834 -25 593 -20ZM1104 894Q1110 1091 1035
-1199T812 1312Q678 1316 573 1240T400 1013T314 629L311 564Q305 368 381 257T602 142Q791 137 915 278T1081 676Q1101 802 1104 894ZM979 1848H1210L904 1554H745L979 1848Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1376" d="M593 -20Q454 -17 352 47T190 235T125 515Q119 636 152 814T266 1135T463 1364Q620 1480 821 1476Q1034 1472 1157 1329T1289 940Q1293 835 1268 673T1177 372T1010 139Q834 -25 593 -20ZM1104 894Q1110 1091 1035
-1199T812 1312Q678 1316 573 1240T400 1013T314 629L311 564Q305 368 381 257T602 142Q791 137 915 278T1081 676Q1101 802 1104 894ZM1150 1576V1562L1003 1564L890 1733L714 1565L561 1562V1578L839 1848H945L1150 1576Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1376" d="M593 -20Q454 -17 352 47T190 235T125 515Q119 636 152 814T266 1135T463 1364Q620 1480 821 1476Q1034 1472 1157 1329T1289 940Q1293 835 1268 673T1177 372T1010 139Q834 -25 593 -20ZM1104 894Q1110 1091 1035
-1199T812 1312Q678 1316 573 1240T400 1013T314 629L311 564Q305 368 381 257T602 142Q791 137 915 278T1081 676Q1101 802 1104 894ZM1232 1817Q1220 1706 1159 1639T1005 1572Q968 1572 938 1587T877 1622T816 1656T749 1670Q664 1667 633 1558L511 1565Q523
-1675 585 1745T741 1813Q768 1813 791 1805T868 1764T945 1722T997 1714Q1083 1714 1115 1827L1232 1817Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1376" d="M593 -20Q454 -17 352 47T190 235T125 515Q119 636 152 814T266 1135T463 1364Q620 1480 821 1476Q1034 1472 1157 1329T1289 940Q1293 835 1268 673T1177 372T1010 139Q834 -25 593 -20ZM1104 894Q1110 1091 1035
-1199T812 1312Q678 1316 573 1240T400 1013T314 629L311 564Q305 368 381 257T602 142Q791 137 915 278T1081 676Q1101 802 1104 894ZM558 1681Q559 1727 588 1757T665 1790Q711 1791 741 1762T771 1685Q771 1639 741 1609T664 1577Q617 1576 588 1605T558 1681ZM975
-1679Q976 1725 1005 1756T1081 1789Q1129 1790 1159 1761T1188 1683Q1188 1636 1158 1607T1081 1575Q1035 1574 1005 1603T975 1679Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1069" d="M40 338L419 673L158 1009L286 1123L548 789L925 1123L1026 992L650 656L912 320L784 206L521 542L142 206L40 338Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1376" d="M590 -21Q424 -17 307 63L183 -92H32L221 140Q115 311 120 541Q121 638 145 788T229 1067T378 1289T580 1430T820 1476Q1026 1472 1155 1350L1286 1515H1436L1228 1259Q1277 1143 1287 1021Q1301 852 1258 630T1102
-249T830 23Q718 -24 590 -21ZM302 487Q304 379 335 296L1045 1204Q968 1308 812 1313Q630 1318 504 1180T334 798Q300 606 302 487ZM1109 933Q1113 1011 1102 1089L411 203Q485 145 599 141Q790 136 916 283T1083 700Q1105 847 1109 933Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1298" d="M1312 1456L1144 471Q1110 244 948 110T557 -21Q414 -18 309 43T153 216T120 470L288 1456H473L306 469Q289 316 358 229T567 137Q719 131 823 219T955 468L1123 1456H1312ZM911 1552H769L564 1846H769L911 1552Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1298" d="M1312 1456L1144 471Q1110 244 948 110T557 -21Q414 -18 309 43T153 216T120 470L288 1456H473L306 469Q289 316 358 229T567 137Q719 131 823 219T955 468L1123 1456H1312ZM941 1846H1172L866 1552H707L941 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1298" d="M1312 1456L1144 471Q1110 244 948 110T557 -21Q414 -18 309 43T153 216T120 470L288 1456H473L306 469Q289 316 358 229T567 137Q719 131 823 219T955 468L1123 1456H1312ZM1112 1574V1560L965 1562L852 1731L676
-1563L523 1560V1576L801 1846H907L1112 1574Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1298" d="M1312 1456L1144 471Q1110 244 948 110T557 -21Q414 -18 309 43T153 216T120 470L288 1456H473L306 469Q289 316 358 229T567 137Q719 131 823 219T955 468L1123 1456H1312ZM520 1679Q521 1725 550 1755T627 1788Q673
-1789 703 1760T733 1683Q733 1637 703 1607T626 1575Q579 1574 550 1603T520 1679ZM937 1677Q938 1723 967 1754T1043 1787Q1091 1788 1121 1759T1150 1681Q1150 1634 1120 1605T1043 1573Q997 1572 967 1601T937 1677Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1203" d="M611 726L1106 1456H1330L677 533L584 0H397L493 554L168 1456H372L611 726ZM892 1846H1123L817 1552H658L892 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1184" d="M491 1456L440 1163L678 1162Q886 1161 1004 1048T1107 746Q1096 616 1026 518T836 366T572 312L293 313L238 0H56L309 1456H491ZM414 1011L319 465L576 464Q715 464 812 540T926 744Q940 864 876 935T693 1010L414 1011Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1191" d="M211 0H30L220 1111Q238 1245 297 1348T449 1504T663 1555Q822 1551 909 1462T983 1225Q974 1130 893 1008T800 810Q791 755 818 701T918 573T1020 443T1046 326Q1036 162 920 69T631 -21Q453 -19 339 54L398 207Q504
-132 617 130Q718 130 787 179T868 315Q875 372 848 425T747 554T643 688T618 811Q623 870 651 918T711 1012T772 1105T809 1211Q819 1293 781 1347T662 1405Q557 1408 489 1333T400 1112L211 0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140ZM774 1242H632L427 1536H632L774 1242Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140ZM804 1536H1035L729 1242H570L804 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140ZM975 1264V1250L828 1252L715 1421L539 1253L386 1250V1266L664 1536H770L975 1264Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140ZM1057 1505Q1045 1394 984 1327T830 1260Q793 1260 763 1275T702 1310T641 1344T574 1358Q489
-1355 458 1246L336 1253Q348 1363 410 1433T566 1501Q593 1501 616 1493T693 1452T770 1410T822 1402Q908 1402 940 1515L1057 1505Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140ZM383 1369Q384 1415 413 1445T490 1478Q536 1479 566 1450T596 1373Q596 1327 566 1297T489
-1265Q442 1264 413 1293T383 1369ZM800 1367Q801 1413 830 1444T906 1477Q954 1478 984 1449T1013 1371Q1013 1324 983 1295T906 1263Q860 1262 830 1291T800 1367Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1091" d="M693 0Q686 29 686 57L689 114Q540 -24 373 -20Q230 -18 141 70T59 292Q69 464 209 560T579 657L768 656L780 742Q790 839 743 895T600 954Q507 956 436 909T348 783L166 782Q175 877 240 950T407 1064T618 1103Q787
-1099 881 1001T960 739L872 203L867 126Q865 71 879 17L877 0H693ZM409 140Q496 138 573 181T707 302L746 525L609 526Q438 526 347 472T244 319Q235 243 279 193T409 140ZM499 1411Q501 1502 565 1565T719 1628Q801 1628 858 1570T916 1427Q914 1338 850 1276T696
-1214Q612 1214 555 1271T499 1411ZM595 1413Q591 1367 618 1336T688 1304Q734 1304 773 1339T819 1425Q825 1471 797 1504T727 1537Q681 1537 641 1501T595 1413Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1687" d="M1136 -20Q1015 -18 923 28T779 160Q610 -24 334 -20Q188 -18 104 68T29 296Q39 456 166 546T510 636L736 635L748 721Q760 825 717 885T584 950Q480 952 408 899T321 759L142 778Q158 929 284 1017T596 1103Q705
-1101 786 1058T902 937Q1064 1106 1258 1102Q1385 1100 1472 1037T1596 864T1616 615L1598 497H896Q887 429 896 365Q909 258 973 196T1142 132Q1232 130 1310 160T1463 237L1516 100Q1378 -20 1136 -20ZM375 129Q445 127 524 163T670 257L713 495L510 496Q390
-496 307 440T212 292Q203 218 248 175T375 129ZM1248 952Q1138 955 1053 877T915 640H1437L1443 672Q1452 727 1445 777Q1434 857 1383 903T1248 952Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1050" d="M488 130Q585 128 663 186T765 340L936 341Q921 239 855 155T687 24T480 -20Q345 -18 252 50T114 241T84 517L89 567Q108 723 180 846T368 1037T624 1102Q794 1098 896 988T998 709L829 710Q827 816 770 881T616
-951Q475 954 382 846T265 544L262 518Q256 454 260 386Q267 269 326 201T488 130ZM485 -9L464 -64Q593 -93 589 -227Q586 -329 499 -386T262 -446L266 -338Q432 -332 448 -231Q460 -160 356 -148L310 -142L356 -9H485Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1062" d="M499 -20Q297 -16 183 129T87 500L92 543Q109 704 187 837T379 1037T623 1102Q790 1098 885 991T989 701Q992 636 985 571L974 488H267Q249 341 315 238T514 131Q674 127 810 275L914 187Q846 89 739 34T499 -20ZM614
-951Q502 954 419 875T286 640L812 639L816 655Q832 781 776 864T614 951ZM747 1242H605L400 1536H605L747 1242Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1062" d="M499 -20Q297 -16 183 129T87 500L92 543Q109 704 187 837T379 1037T623 1102Q790 1098 885 991T989 701Q992 636 985 571L974 488H267Q249 341 315 238T514 131Q674 127 810 275L914 187Q846 89 739 34T499 -20ZM614
-951Q502 954 419 875T286 640L812 639L816 655Q832 781 776 864T614 951ZM777 1536H1008L702 1242H543L777 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1062" d="M499 -20Q297 -16 183 129T87 500L92 543Q109 704 187 837T379 1037T623 1102Q790 1098 885 991T989 701Q992 636 985 571L974 488H267Q249 341 315 238T514 131Q674 127 810 275L914 187Q846 89 739 34T499 -20ZM614
-951Q502 954 419 875T286 640L812 639L816 655Q832 781 776 864T614 951ZM948 1264V1250L801 1252L688 1421L512 1253L359 1250V1266L637 1536H743L948 1264Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1062" d="M499 -20Q297 -16 183 129T87 500L92 543Q109 704 187 837T379 1037T623 1102Q790 1098 885 991T989 701Q992 636 985 571L974 488H267Q249 341 315 238T514 131Q674 127 810 275L914 187Q846 89 739 34T499 -20ZM614
-951Q502 954 419 875T286 640L812 639L816 655Q832 781 776 864T614 951ZM356 1369Q357 1415 386 1445T463 1478Q509 1479 539 1450T569 1373Q569 1327 539 1297T462 1265Q415 1264 386 1293T356 1369ZM773 1367Q774 1413 803 1444T879 1477Q927 1478 957 1449T986
-1371Q986 1324 956 1295T879 1263Q833 1262 803 1291T773 1367Z" />
-<glyph unicode="&#xec;" horiz-adv-x="501" d="M227 0H46L234 1082H415L227 0ZM711 1497H569L364 1791H569L711 1497Z" />
-<glyph unicode="&#xed;" horiz-adv-x="501" d="M227 0H46L234 1082H415L227 0ZM484 1791H715L409 1497H250L484 1791Z" />
-<glyph unicode="&#xee;" horiz-adv-x="501" d="M227 0H46L234 1082H415L227 0ZM656 1263V1249L509 1251L396 1420L220 1252L67 1249V1265L345 1535H451L656 1263Z" />
-<glyph unicode="&#xef;" horiz-adv-x="501" d="M227 0H46L234 1082H415L227 0ZM64 1368Q65 1414 94 1444T171 1477Q217 1478 247 1449T277 1372Q277 1326 247 1296T170 1264Q123 1263 94 1292T64 1368ZM481 1366Q482 1412 511 1443T587 1476Q635 1477 665 1448T694
-1370Q694 1323 664 1294T587 1262Q541 1261 511 1290T481 1366Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1174" d="M926 1299Q1103 1004 1053 633L1040 542Q1016 375 938 242T747 43T504 -21Q316 -17 204 120T111 459Q125 603 194 724T374 914T617 978Q771 974 882 863Q878 1045 772 1198L533 1050L474 1158L681 1284Q579 1370
-401 1422L471 1579Q691 1523 841 1387L1050 1517L1108 1408L926 1299ZM877 695Q821 821 651 826Q507 830 409 729T292 458Q277 319 341 226T517 129Q644 124 735 233T857 535L877 695Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1106" d="M390 1083L364 946Q510 1106 696 1102Q849 1098 922 996T976 709L858 0H677L796 712Q802 761 797 803Q780 943 632 946Q469 949 346 772L212 0H31L219 1082L390 1083ZM1048 1505Q1036 1394 975 1327T821 1260Q784
-1260 754 1275T693 1310T632 1344T565 1358Q480 1355 449 1246L327 1253Q339 1363 401 1433T557 1501Q584 1501 607 1493T684 1452T761 1410T813 1402Q899 1402 931 1515L1048 1505Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1143" d="M632 1102Q768 1100 865 1028T1008 830T1040 553L1038 531Q1019 373 944 246T750 47T489 -20Q354 -18 257 54T114 250T82 523Q97 691 173 825T368 1032T632 1102ZM264 522Q257 459 264 391Q274 273 334 203T496
-130Q586 127 662 174T790 318T857 531Q865 623 860 686Q848 807 787 877T625 951Q485 954 387 841T266 545L264 522ZM756 1242H614L409 1536H614L756 1242Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1143" d="M632 1102Q768 1100 865 1028T1008 830T1040 553L1038 531Q1019 373 944 246T750 47T489 -20Q354 -18 257 54T114 250T82 523Q97 691 173 825T368 1032T632 1102ZM264 522Q257 459 264 391Q274 273 334 203T496
-130Q586 127 662 174T790 318T857 531Q865 623 860 686Q848 807 787 877T625 951Q485 954 387 841T266 545L264 522ZM786 1536H1017L711 1242H552L786 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1143" d="M632 1102Q768 1100 865 1028T1008 830T1040 553L1038 531Q1019 373 944 246T750 47T489 -20Q354 -18 257 54T114 250T82 523Q97 691 173 825T368 1032T632 1102ZM264 522Q257 459 264 391Q274 273 334 203T496
-130Q586 127 662 174T790 318T857 531Q865 623 860 686Q848 807 787 877T625 951Q485 954 387 841T266 545L264 522ZM957 1264V1250L810 1252L697 1421L521 1253L368 1250V1266L646 1536H752L957 1264Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1143" d="M632 1102Q768 1100 865 1028T1008 830T1040 553L1038 531Q1019 373 944 246T750 47T489 -20Q354 -18 257 54T114 250T82 523Q97 691 173 825T368 1032T632 1102ZM264 522Q257 459 264 391Q274 273 334 203T496
-130Q586 127 662 174T790 318T857 531Q865 623 860 686Q848 807 787 877T625 951Q485 954 387 841T266 545L264 522ZM1039 1505Q1027 1394 966 1327T812 1260Q775 1260 745 1275T684 1310T623 1344T556 1358Q471 1355 440 1246L318 1253Q330 1363 392 1433T548
-1501Q575 1501 598 1493T675 1452T752 1410T804 1402Q890 1402 922 1515L1039 1505Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1143" d="M632 1102Q768 1100 865 1028T1008 830T1040 553L1038 531Q1019 373 944 246T750 47T489 -20Q354 -18 257 54T114 250T82 523Q97 691 173 825T368 1032T632 1102ZM264 522Q257 459 264 391Q274 273 334 203T496
-130Q586 127 662 174T790 318T857 531Q865 623 860 686Q848 807 787 877T625 951Q485 954 387 841T266 545L264 522ZM365 1369Q366 1415 395 1445T472 1478Q518 1479 548 1450T578 1373Q578 1327 548 1297T471 1265Q424 1264 395 1293T365 1369ZM782 1367Q783 1413
-812 1444T888 1477Q936 1478 966 1449T995 1371Q995 1324 965 1295T888 1263Q842 1262 812 1291T782 1367Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1144" d="M1038 600H68L101 784H1070L1038 600ZM534 1095Q534 1144 564 1176T645 1211Q693 1213 725 1182T757 1101Q756 1052 725 1021T644 988T564 1016T534 1095ZM392 278Q393 327 423 359T504 394Q552 396 584 365T616
-284Q615 235 583 204T502 171T423 199T392 278Z" />
-<glyph unicode="&#xf8;" d="M638 1104Q741 1102 832 1059L934 1208L1066 1207L922 1000Q1032 870 1039 672Q1041 617 1033 531Q1014 375 935 244T735 44T473 -22Q384 -20 291 15L189 -134L57 -133L198 72Q80 196 73 401Q71 462 77 522L79 538Q115 801 270 954T638
-1104ZM249 447Q239 315 290 224L749 922Q694 951 630 953Q473 957 369 820T249 447ZM863 701Q860 775 829 844L373 152Q423 129 480 127Q620 124 720 234T852 531Q865 626 863 701Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1105" d="M718 107Q591 -24 395 -20Q240 -16 166 91T110 383L226 1082H407L290 380Q285 336 288 294Q293 222 331 181T437 137Q631 131 737 294L873 1082H1054L866 0H695L718 107ZM760 1242H618L413 1536H618L760 1242Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1105" d="M718 107Q591 -24 395 -20Q240 -16 166 91T110 383L226 1082H407L290 380Q285 336 288 294Q293 222 331 181T437 137Q631 131 737 294L873 1082H1054L866 0H695L718 107ZM790 1536H1021L715 1242H556L790 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1105" d="M718 107Q591 -24 395 -20Q240 -16 166 91T110 383L226 1082H407L290 380Q285 336 288 294Q293 222 331 181T437 137Q631 131 737 294L873 1082H1054L866 0H695L718 107ZM961 1264V1250L814 1252L701 1421L525 1253L372
-1250V1266L650 1536H756L961 1264Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1105" d="M718 107Q591 -24 395 -20Q240 -16 166 91T110 383L226 1082H407L290 380Q285 336 288 294Q293 222 331 181T437 137Q631 131 737 294L873 1082H1054L866 0H695L718 107ZM369 1369Q370 1415 399 1445T476 1478Q522
-1479 552 1450T582 1373Q582 1327 552 1297T475 1265Q428 1264 399 1293T369 1369ZM786 1367Q787 1413 816 1444T892 1477Q940 1478 970 1449T999 1371Q999 1324 969 1295T892 1263Q846 1262 816 1291T786 1367Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="950" d="M419 273L804 1082H1004L362 -180Q228 -443 18 -440Q-19 -439 -91 -422L-75 -272L-28 -277Q58 -281 120 -239T231 -101L296 23L109 1082H298L419 273ZM733 1536H964L658 1242H499L733 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1155" d="M1020 536Q1000 370 930 237T759 40T533 -22Q347 -18 246 106L149 -416H-32L307 1536H487L381 969Q512 1106 693 1102Q851 1098 937 984T1027 681Q1028 620 1020 536ZM842 558L847 642Q847 787 791 865T631 945Q471
-949 359 797L269 278Q330 135 487 130Q624 127 718 236T842 558Z" />
-<glyph unicode="&#xff;" horiz-adv-x="950" d="M419 273L804 1082H1004L362 -180Q228 -443 18 -440Q-19 -439 -91 -422L-75 -272L-28 -277Q58 -281 120 -239T231 -101L296 23L109 1082H298L419 273ZM312 1369Q313 1415 342 1445T419 1478Q465 1479 495 1450T525
-1373Q525 1327 495 1297T418 1265Q371 1264 342 1293T312 1369ZM729 1367Q730 1413 759 1444T835 1477Q883 1478 913 1449T942 1371Q942 1324 912 1295T835 1263Q789 1262 759 1291T729 1367Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1314" d="M1396 651H423L456 802H1429L1396 651Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1561" d="M1707 651H410L453 802H1750L1707 651Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="407" d="M417 1555L517 1481Q405 1341 378 1207L354 1073H174L192 1185Q228 1407 417 1555Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="407" d="M237 1046L137 1120Q255 1267 279 1405L302 1536H480L461 1415Q425 1190 237 1046Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="405" d="M-5 -283L-104 -208Q11 -64 35 75L53 181H234L219 85Q184 -135 -5 -283Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="712" d="M425 1555L525 1481Q413 1341 386 1207L362 1073H182L200 1185Q236 1407 425 1555ZM730 1555L830 1481Q718 1341 691 1207L667 1073H487L505 1185Q541 1407 730 1555Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="719" d="M249 1046L149 1120Q267 1267 291 1405L314 1536H492L473 1415Q437 1190 249 1046ZM546 1046L446 1120Q564 1267 588 1405L611 1536H789L770 1415Q734 1190 546 1046Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="694" d="M-4 -302L-108 -227Q8 -76 35 75L65 246H245L220 90Q181 -151 -4 -302ZM283 -302L180 -227Q296 -73 322 75L352 246H533L508 90Q469 -150 283 -302Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="679" d="M161 765Q167 859 225 915T370 972Q451 972 503 918T556 775L554 733Q548 643 492 588T345 533Q263 533 212 586T160 724L161 765Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="606" d="M267 540L445 153H320L95 540L97 560L444 949H596L267 540Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="606" d="M278 949L503 562L501 541L154 152H2L330 560L153 949H278Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-italic.ttf b/static/fonts/roboto-v18-latin-italic.ttf
deleted file mode 100644
index 91cd95e286..0000000000
Binary files a/static/fonts/roboto-v18-latin-italic.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-italic.woff b/static/fonts/roboto-v18-latin-italic.woff
deleted file mode 100644
index 27c34da2a6..0000000000
Binary files a/static/fonts/roboto-v18-latin-italic.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-italic.woff2 b/static/fonts/roboto-v18-latin-italic.woff2
deleted file mode 100644
index 3791c883e8..0000000000
Binary files a/static/fonts/roboto-v18-latin-italic.woff2 and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-regular.eot b/static/fonts/roboto-v18-latin-regular.eot
deleted file mode 100644
index a0780d6e3f..0000000000
Binary files a/static/fonts/roboto-v18-latin-regular.eot and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-regular.svg b/static/fonts/roboto-v18-latin-regular.svg
deleted file mode 100644
index 627f5a368c..0000000000
--- a/static/fonts/roboto-v18-latin-regular.svg
+++ /dev/null
@@ -1,308 +0,0 @@
-<?xml version="1.0" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<svg xmlns="http://www.w3.org/2000/svg">
-<defs >
-<font id="Roboto" horiz-adv-x="1158" ><font-face
-    font-family="Roboto"
-    units-per-em="2048"
-    panose-1="2 0 0 0 0 0 0 0 0 0"
-    ascent="1900"
-    descent="-500"
-    alphabetic="0" />
-<glyph unicode=" " horiz-adv-x="507" />
-<glyph unicode="!" horiz-adv-x="527" d="M347 411H180L167 1456H361L347 411ZM160 93Q160 138 187 168T269 199T351 169T379 93T351 19T269 -11T188 18T160 93Z" />
-<glyph unicode="&quot;" horiz-adv-x="655" d="M277 1400L247 1042H136L137 1536H277V1400ZM547 1400L517 1042H406L407 1536H547V1400Z" />
-<glyph unicode="#" horiz-adv-x="1261" d="M765 410H501L421 0H278L358 410H119V547H384L453 901H195V1040H480L562 1456H705L623 1040H887L969 1456H1113L1031 1040H1235V901H1004L935 547H1160V410H909L829 0H685L765 410ZM527 547H791L860 901H596L527 547Z" />
-<glyph unicode="$" horiz-adv-x="1150" d="M856 375Q856 467 792 530T574 644Q361 709 264 813T166 1079Q166 1243 261 1348T524 1473V1692H673V1472Q841 1449 934 1331T1028 1008H844Q844 1149 777 1232T596 1315Q477 1315 414 1254T351 1082Q351 980 417 920T636
-810T874 701T1000 562T1041 377Q1041 208 940 105T655 -17V-208H507V-17Q321 0 216 115T110 429H295Q295 290 368 215T575 140Q706 140 781 203T856 375Z" />
-<glyph unicode="%" horiz-adv-x="1500" d="M105 1176Q105 1307 188 1392T403 1477Q536 1477 618 1392T701 1170V1099Q701 967 618 884T405 800Q275 800 190 883T105 1106V1176ZM243 1099Q243 1021 287 971T405 920Q476 920 519 969T563 1103V1176Q563 1254 520
-1305T403 1356T286 1305T243 1172V1099ZM814 357Q814 488 897 572T1112 657T1327 573T1411 350V279Q1411 148 1328 64T1114 -21T899 62T814 285V357ZM952 279Q952 200 996 150T1114 99Q1186 99 1229 148T1272 283V357Q1272 436 1229 486T1112 536Q1041 536 997
-487T952 353V279ZM447 110L342 176L1053 1314L1158 1248L447 110Z" />
-<glyph unicode="&amp;" horiz-adv-x="1273" d="M101 391Q101 496 159 584T383 789Q286 907 253 979T220 1122Q220 1288 318 1382T584 1476Q734 1476 832 1389T930 1168Q930 1080 886 1006T730 849L623 770L947 383Q1015 513 1015 672H1182Q1182 417 1059 249L1267
-0H1045L948 115Q874 49 775 15T572 -20Q359 -20 230 93T101 391ZM572 131Q719 131 841 243L486 668L453 644Q286 521 286 391Q286 273 362 202T572 131ZM405 1128Q405 1032 523 888L641 971Q709 1019 734 1062T759 1168Q759 1235 709 1279T583 1324Q501 1324 453
-1269T405 1128Z" />
-<glyph unicode="&apos;" horiz-adv-x="357" d="M253 1425L232 1057H103L104 1536H253V1425Z" />
-<glyph unicode="(" horiz-adv-x="700" d="M133 591Q133 817 193 1025T374 1403T623 1643L661 1521Q515 1409 422 1179T319 664L318 579Q318 193 459 -91Q544 -261 661 -357L623 -470Q490 -396 369 -222Q133 118 133 591Z" />
-<glyph unicode=")" horiz-adv-x="712" d="M567 581Q567 358 509 154T330 -224T77 -470L38 -357Q192 -239 285 9T381 561V593Q381 803 337 983T215 1307T38 1530L77 1643Q209 1570 328 1399T507 1022T567 581Z" />
-<glyph unicode="*" horiz-adv-x="882" d="M330 983L28 1073L74 1224L376 1112L367 1456H520L510 1107L807 1217L853 1065L546 974L744 703L620 609L434 897L254 616L129 707L330 983Z" />
-<glyph unicode="+" horiz-adv-x="1161" d="M670 781H1076V606H670V146H484V606H78V781H484V1206H670V781Z" />
-<glyph unicode="," horiz-adv-x="402" d="M134 -290L29 -218Q123 -87 127 52V219H308V74Q308 -27 259 -128T134 -290Z" />
-<glyph unicode="-" horiz-adv-x="565" d="M525 543H37V694H525V543Z" />
-<glyph unicode="." horiz-adv-x="539" d="M144 97Q144 145 172 177T258 209T344 177T374 97Q374 51 345 20T258 -11T173 20T144 97Z" />
-<glyph unicode="/" horiz-adv-x="844" d="M177 -125H18L626 1456H784L177 -125Z" />
-<glyph unicode="0" horiz-adv-x="1150" d="M1034 621Q1034 296 923 138T576 -20Q343 -20 231 134T115 596V843Q115 1164 226 1320T574 1476Q809 1476 920 1326T1034 861V621ZM849 874Q849 1109 783 1216T574 1324Q432 1324 367 1217T300 888V592Q300 356 368 244T576
-131Q713 131 779 237T849 571V874Z" />
-<glyph unicode="1" horiz-adv-x="1150" d="M729 0H543V1233L170 1096V1264L700 1463H729V0Z" />
-<glyph unicode="2" horiz-adv-x="1150" d="M1075 0H121V133L625 693Q737 820 779 899T822 1064Q822 1178 753 1251T569 1324Q431 1324 355 1246T278 1027H93Q93 1228 222 1352T569 1476Q772 1476 890 1370T1008 1086Q1008 871 734 574L344 151H1075V0Z" />
-<glyph unicode="3" horiz-adv-x="1150" d="M390 818H529Q660 820 735 887T810 1068Q810 1324 555 1324Q435 1324 364 1256T292 1074H107Q107 1247 233 1361T555 1476Q761 1476 878 1367T995 1064Q995 969 934 880T766 747Q886 709 951 621T1017 406Q1017 210 889
-95T556 -20T223 91T94 384H280Q280 269 355 200T556 131Q690 131 761 201T832 402Q832 529 754 597T529 667H390V818Z" />
-<glyph unicode="4" horiz-adv-x="1150" d="M902 489H1104V338H902V0H716V338H53V447L705 1456H902V489ZM263 489H716V1203L694 1163L263 489Z" />
-<glyph unicode="5" horiz-adv-x="1150" d="M206 730L280 1456H1026V1285H437L393 888Q500 951 636 951Q835 951 952 820T1069 464Q1069 239 948 110T608 -20Q415 -20 293 87T154 383H329Q346 258 418 195T608 131Q737 131 810 219T884 462Q884 608 805 696T593
-785Q472 785 403 732L354 692L206 730Z" />
-<glyph unicode="6" horiz-adv-x="1150" d="M847 1457V1300H813Q597 1296 469 1172T321 823Q436 955 635 955Q825 955 938 821T1052 475Q1052 250 930 115T601 -20Q392 -20 262 140T132 554V625Q132 1027 303 1239T814 1457H847ZM604 801Q509 801 429 744T318 601V533Q318
-353 399 243T601 133Q726 133 797 225T869 466Q869 616 797 708T604 801Z" />
-<glyph unicode="7" horiz-adv-x="1150" d="M1061 1352L458 0H264L865 1304H77V1456H1061V1352Z" />
-<glyph unicode="8" horiz-adv-x="1150" d="M1004 1076Q1004 967 947 882T791 749Q905 700 971 606T1038 393Q1038 204 911 92T575 -20Q365 -20 239 92T112 393Q112 511 176 606T355 750Q258 798 202 883T146 1076Q146 1260 264 1368T575 1476Q767 1476 885 1368T1004
-1076ZM853 397Q853 519 776 596T573 673T373 597T297 397T370 202T575 131Q705 131 779 202T853 397ZM575 1324Q466 1324 399 1257T331 1073Q331 962 397 894T575 825T752 893T819 1073T750 1254T575 1324Z" />
-<glyph unicode="9" horiz-adv-x="1150" d="M830 640Q772 571 692 529T515 487Q389 487 296 549T151 723T100 972Q100 1118 155 1235T313 1414T551 1476Q767 1476 891 1315T1016 874V820Q1016 395 848 200T341 -1H305V155H344Q573 159 696 274T830 640ZM545 640Q638
-640 716 697T831 838V912Q831 1094 752 1208T552 1322Q430 1322 356 1229T282 982Q282 833 353 737T545 640Z" />
-<glyph unicode=":" horiz-adv-x="496" d="M390 97Q390 145 418 177T504 209T590 177T620 97Q620 51 591 20T504 -11T419 20T390 97ZM135 980Q135 1028 163 1060T249 1092T335 1060T365 980Q365 934 336 903T249 872T164 903T135 980Z" />
-<glyph unicode=";" horiz-adv-x="433" d="M111 980Q111 1028 139 1060T225 1092T311 1060T341 980Q341 934 312 903T225 872T140 903T111 980ZM146 -290L41 -218Q135 -87 139 52V219H320V74Q320 -27 271 -128T146 -290Z" />
-<glyph unicode="&lt;" horiz-adv-x="1041" d="M264 644L890 391V195L72 574V720L890 1098V902L264 644Z" />
-<glyph unicode="=" horiz-adv-x="1124" d="M986 814H152V975H986V814ZM986 399H152V559H986V399Z" />
-<glyph unicode="&gt;" horiz-adv-x="1070" d="M795 650L134 909V1099L988 721V575L134 196V388L795 650Z" />
-<glyph unicode="?" horiz-adv-x="967" d="M357 410Q359 529 384 598T486 751L617 886Q701 981 701 1090Q701 1195 646 1254T486 1314Q384 1314 322 1260T260 1115H75Q77 1277 190 1376T486 1476Q675 1476 780 1375T886 1096Q886 921 724 751L615 643Q542 562 542
-410H357ZM349 93Q349 138 376 168T458 199T540 169T568 93T540 19T458 -11T377 18T349 93Z" />
-<glyph unicode="@" horiz-adv-x="1839" d="M1738 502Q1726 260 1618 120T1329 -20Q1142 -20 1089 148Q1035 63 966 22T822 -20Q680 -20 607 96T553 417Q568 582 628 711T784 915T985 989Q1066 989 1130 968T1274 883L1222 329Q1203 98 1350 98Q1463 98 1533 210T1609
-502Q1628 891 1465 1095T967 1299Q766 1299 610 1200T364 912T263 478Q251 230 323 48T542 -231T899 -328Q989 -328 1079 -306T1230 -249L1267 -364Q1205 -403 1103 -428T895 -453Q645 -453 465 -341T196 -17T118 478Q130 753 241 972T542 1311T971 1431Q1220 1431
-1398 1319T1663 996T1738 502ZM712 417Q698 275 738 199T867 123Q927 123 982 174T1074 320L1075 329L1121 832Q1065 861 1001 861Q884 861 808 742T712 417Z" />
-<glyph unicode="A" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538Z" />
-<glyph unicode="B" horiz-adv-x="1275" d="M169 0V1456H645Q882 1456 1001 1358T1121 1068Q1121 966 1063 888T905 766Q1023 733 1091 641T1160 420Q1160 224 1033 112T674 0H169ZM361 681V157H678Q812 157 889 226T967 418Q967 681 681 681H361ZM361 835H651Q777
-835 852 898T928 1069Q928 1189 858 1243T645 1298H361V835Z" />
-<glyph unicode="C" horiz-adv-x="1333" d="M1240 462Q1213 231 1070 106T688 -20Q430 -20 275 165T119 660V800Q119 1003 191 1157T397 1393T705 1476Q937 1476 1077 1347T1240 988H1047Q1022 1162 939 1240T705 1318Q521 1318 417 1182T312 795V654Q312 417 411
-277T688 137Q848 137 933 209T1047 462H1240Z" />
-<glyph unicode="D" horiz-adv-x="1343" d="M169 0V1456H580Q770 1456 916 1372T1141 1133T1222 777V684Q1222 478 1143 323T916 85T572 0H169ZM361 1298V157H563Q785 157 908 295T1032 688V773Q1032 1021 916 1158T585 1298H361Z" />
-<glyph unicode="E" horiz-adv-x="1164" d="M992 673H361V157H1094V0H169V1456H1084V1298H361V830H992V673Z" />
-<glyph unicode="F" horiz-adv-x="1132" d="M972 643H361V0H169V1456H1071V1298H361V800H972V643Z" />
-<glyph unicode="G" horiz-adv-x="1395" d="M1244 191Q1170 85 1038 33T729 -20Q551 -20 413 63T200 301T122 658V785Q122 1114 275 1295T707 1476Q935 1476 1074 1360T1244 1029H1052Q998 1318 708 1318Q515 1318 416 1183T315 790V671Q315 426 427 282T730 137Q838
-137 919 161T1053 242V569H716V725H1244V191Z" />
-<glyph unicode="H" horiz-adv-x="1460" d="M1288 0H1095V673H361V0H169V1456H361V830H1095V1456H1288V0Z" />
-<glyph unicode="I" horiz-adv-x="557" d="M375 0H183V1456H375V0Z" />
-<glyph unicode="J" horiz-adv-x="1130" d="M779 1456H972V425Q972 216 847 98T512 -20Q295 -20 174 91T53 402H245Q245 277 313 207T512 137Q631 137 704 212T779 422V1456Z" />
-<glyph unicode="K" horiz-adv-x="1284" d="M539 677L361 492V0H169V1456H361V736L1008 1456H1240L667 813L1285 0H1055L539 677Z" />
-<glyph unicode="L" horiz-adv-x="1102" d="M362 157H1052V0H169V1456H362V157Z" />
-<glyph unicode="M" horiz-adv-x="1788" d="M417 1456L893 268L1369 1456H1618V0H1426V567L1444 1179L966 0H819L342 1176L361 567V0H169V1456H417Z" />
-<glyph unicode="N" horiz-adv-x="1460" d="M1288 0H1095L362 1122V0H169V1456H362L1097 329V1456H1288V0Z" />
-<glyph unicode="O" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q533 -20 400 64T194 305T118 668V773Q118 983 191 1144T397 1390T703 1476Q878 1476 1011 1392T1217 1147T1289 773V681ZM1098 775Q1098 1034 994 1172T703 1311Q521 1311
-417 1173T309 788V681Q309 430 414 287T705 143Q891 143 993 278T1098 667V775Z" />
-<glyph unicode="P" horiz-adv-x="1292" d="M361 570V0H169V1456H706Q945 1456 1080 1334T1216 1011Q1216 799 1084 685T704 570H361ZM361 727H706Q860 727 942 799T1024 1009Q1024 1139 942 1217T717 1298H361V727Z" />
-<glyph unicode="Q" horiz-adv-x="1408" d="M1281 681Q1281 470 1214 318T1026 79L1286 -125L1155 -246L848 -2Q776 -20 696 -20Q524 -20 391 64T185 305T109 668V773Q109 983 182 1144T388 1390T694 1476Q870 1476 1003 1391T1209 1147T1281 774V681ZM1089 775Q1089
-1032 987 1171T694 1311Q513 1311 409 1173T301 788V681Q301 431 405 287T696 143T984 278T1089 667V775Z" />
-<glyph unicode="R" horiz-adv-x="1261" d="M703 589H361V0H168V1456H650Q896 1456 1028 1344T1161 1018Q1161 882 1088 781T883 630L1225 12V0H1019L703 589ZM361 746H656Q799 746 883 820T968 1018Q968 1153 888 1225T655 1298H361V746Z" />
-<glyph unicode="S" horiz-adv-x="1215" d="M598 649Q351 720 239 823T126 1079Q126 1251 263 1363T621 1476Q771 1476 888 1418T1070 1258T1135 1035H942Q942 1167 858 1242T621 1318Q479 1318 400 1256T320 1082Q320 993 395 932T652 819T936 707T1088 563T1138
-370Q1138 193 1000 87T631 -20Q481 -20 351 37T151 195T80 422H273Q273 290 370 214T631 137Q783 137 864 199T945 368T870 533T598 649Z" />
-<glyph unicode="T" horiz-adv-x="1222" d="M1175 1298H707V0H516V1298H49V1456H1175V1298Z" />
-<glyph unicode="U" horiz-adv-x="1328" d="M1194 1456V466Q1193 260 1065 129T716 -18L665 -20Q426 -20 284 109T140 464V1456H330V470Q330 312 417 225T665 137Q828 137 914 224T1001 469V1456H1194Z" />
-<glyph unicode="V" horiz-adv-x="1303" d="M651 255L1067 1456H1277L737 0H567L28 1456H237L651 255Z" />
-<glyph unicode="W" horiz-adv-x="1817" d="M483 459L511 267L552 440L840 1456H1002L1283 440L1323 264L1354 460L1580 1456H1773L1420 0H1245L945 1061L922 1172L899 1061L588 0H413L61 1456H253L483 459Z" />
-<glyph unicode="X" horiz-adv-x="1284" d="M644 898L993 1456H1219L759 734L1230 0H1002L644 568L284 0H57L529 734L68 1456H293L644 898Z" />
-<glyph unicode="Y" horiz-adv-x="1230" d="M613 725L993 1456H1211L709 543V0H517V543L15 1456H235L613 725Z" />
-<glyph unicode="Z" horiz-adv-x="1226" d="M313 157H1146V0H86V144L884 1298H99V1456H1114V1315L313 157Z" />
-<glyph unicode="[" horiz-adv-x="543" d="M523 1512H332V-160H523V-312H146V1664H523V1512Z" />
-<glyph unicode="\" horiz-adv-x="840" d="M40 1456H216L824 -125H648L40 1456Z" />
-<glyph unicode="]" horiz-adv-x="543" d="M9 1664H387V-312H9V-160H202V1512H9V1664Z" />
-<glyph unicode="^" horiz-adv-x="856" d="M426 1211L236 729H64L363 1456H490L788 729H617L426 1211Z" />
-<glyph unicode="_" horiz-adv-x="924" d="M920 -151H4V0H920V-151Z" />
-<glyph unicode="`" horiz-adv-x="633" d="M474 1242H315L57 1536H280L474 1242Z" />
-<glyph unicode="a" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141Z" />
-<glyph unicode="b" horiz-adv-x="1149" d="M1056 529Q1056 281 942 131T636 -20Q431 -20 319 125L310 0H140V1536H325V963Q437 1102 634 1102T943 953T1056 545V529ZM871 550Q871 739 798 842T588 945Q405 945 325 775V307Q410 137 590 137Q723 137 797 240T871 550Z" />
-<glyph unicode="c" horiz-adv-x="1072" d="M574 131Q673 131 747 191T829 341H1004Q999 248 940 164T783 30T574 -20Q353 -20 223 127T92 531V562Q92 720 150 843T316 1034T573 1102Q755 1102 875 993T1004 710H829Q821 815 750 882T573 950Q432 950 355 849T277
-555V520Q277 333 354 232T574 131Z" />
-<glyph unicode="d" horiz-adv-x="1155" d="M95 550Q95 799 213 950T522 1102Q712 1102 823 972V1536H1008V0H838L829 116Q718 -20 520 -20Q332 -20 214 134T95 536V550ZM280 529Q280 345 356 241T566 137Q742 137 823 295V792Q740 945 568 945Q432 945 356 840T280 529Z" />
-<glyph unicode="e" horiz-adv-x="1085" d="M589 -20Q369 -20 231 124T93 511V545Q93 706 154 832T326 1030T566 1102Q777 1102 894 963T1011 565V488H278Q282 328 371 230T599 131Q697 131 765 171T884 277L997 189Q861 -20 589 -20ZM566 950Q454 950 378 869T284
-640H826V654Q818 795 750 872T566 950Z" />
-<glyph unicode="f" horiz-adv-x="711" d="M231 0V939H60V1082H231V1193Q231 1367 324 1462T587 1557Q651 1557 714 1540L704 1390Q657 1399 604 1399Q514 1399 465 1347T416 1196V1082H647V939H416V0H231Z" />
-<glyph unicode="g" horiz-adv-x="1149" d="M96 550Q96 803 213 952T523 1102Q721 1102 832 962L841 1082H1010V26Q1010 -184 886 -305T551 -426Q434 -426 322 -376T151 -239L247 -128Q366 -275 538 -275Q673 -275 748 -199T824 15V108Q713 -20 521 -20Q331 -20
-214 133T96 550ZM282 529Q282 346 357 242T567 137Q742 137 824 296V790Q739 945 569 945Q434 945 358 840T282 529Z" />
-<glyph unicode="h" horiz-adv-x="1128" d="M325 951Q448 1102 645 1102Q988 1102 991 715V0H806V716Q805 833 753 889T589 945Q499 945 431 897T325 771V0H140V1536H325V951Z" />
-<glyph unicode="i" horiz-adv-x="497" d="M341 0H156V1082H341V0ZM141 1369Q141 1414 168 1445T250 1476T332 1445T360 1369T332 1294T250 1264T169 1294T141 1369Z" />
-<glyph unicode="j" horiz-adv-x="489" d="M331 1082V-125Q331 -437 48 -437Q-13 -437 -65 -419V-271Q-33 -279 19 -279Q81 -279 113 -246T146 -129V1082H331ZM127 1369Q127 1413 154 1444T235 1476Q289 1476 317 1445T345 1369T317 1294T235 1264T154 1294T127 1369Z" />
-<glyph unicode="k" horiz-adv-x="1038" d="M442 501L326 380V0H141V1536H326V607L425 726L762 1082H987L566 630L1036 0H819L442 501Z" />
-<glyph unicode="l" horiz-adv-x="497" d="M341 0H156V1536H341V0Z" />
-<glyph unicode="m" horiz-adv-x="1795" d="M314 1082L319 962Q438 1102 640 1102Q867 1102 949 928Q1003 1006 1089 1054T1294 1102Q1650 1102 1656 725V0H1471V714Q1471 830 1418 887T1240 945Q1137 945 1069 884T990 718V0H804V709Q804 945 573 945Q391 945
-324 790V0H139V1082H314Z" />
-<glyph unicode="n" horiz-adv-x="1130" d="M315 1082L321 946Q445 1102 645 1102Q988 1102 991 715V0H806V716Q805 833 753 889T589 945Q499 945 431 897T325 771V0H140V1082H315Z" />
-<glyph unicode="o" horiz-adv-x="1168" d="M91 551Q91 710 153 837T327 1033T582 1102Q803 1102 939 949T1076 542V529Q1076 371 1016 246T843 50T584 -20Q364 -20 228 133T91 538V551ZM277 529Q277 349 360 240T584 131Q725 131 808 241T891 551Q891 729 807
-839T582 950Q445 950 361 841T277 529Z" />
-<glyph unicode="p" horiz-adv-x="1149" d="M1054 529Q1054 282 941 131T635 -20Q438 -20 325 105V-416H140V1082H309L318 962Q431 1102 632 1102Q827 1102 940 955T1054 546V529ZM869 550Q869 733 791 839T577 945Q409 945 325 796V279Q408 131 579 131Q712 131
-790 236T869 550Z" />
-<glyph unicode="q" horiz-adv-x="1164" d="M95 550Q95 805 212 953T526 1102Q718 1102 829 973L837 1082H1007V-416H822V100Q710 -20 524 -20Q328 -20 212 132T95 537V550ZM280 529Q280 343 358 237T570 131Q735 131 822 277V807Q734 950 572 950Q438 950 359
-844T280 529Z" />
-<glyph unicode="r" horiz-adv-x="693" d="M663 916Q621 923 572 923Q390 923 325 768V0H140V1082H320L323 957Q414 1102 581 1102Q635 1102 663 1088V916Z" />
-<glyph unicode="s" horiz-adv-x="1056" d="M770 287Q770 362 714 403T517 475T294 547T172 647T132 785Q132 918 244 1010T532 1102Q716 1102 830 1007T945 764H759Q759 840 695 895T532 950Q431 950 374 906T317 791Q317 724 370 690T561 625T786 551T913 448T955
-300Q955 155 839 68T538 -20Q408 -20 308 26T152 154T95 333H280Q285 240 354 186T538 131Q643 131 706 173T770 287Z" />
-<glyph unicode="t" horiz-adv-x="669" d="M391 1344V1082H593V939H391V268Q391 203 418 171T510 138Q542 138 598 150V0Q525 -20 456 -20Q332 -20 269 55T206 268V939H9V1082H206V1344H391Z" />
-<glyph unicode="u" horiz-adv-x="1129" d="M808 107Q700 -20 491 -20Q318 -20 228 80T136 378V1082H321V383Q321 137 521 137Q733 137 803 295V1082H988V0H812L808 107Z" />
-<glyph unicode="v" horiz-adv-x="992" d="M497 251L765 1082H954L566 0H425L33 1082H222L497 251Z" />
-<glyph unicode="w" horiz-adv-x="1539" d="M1098 255L1306 1082H1491L1176 0H1026L763 820L507 0H357L43 1082H227L440 272L692 1082H841L1098 255Z" />
-<glyph unicode="x" horiz-adv-x="1015" d="M503 687L743 1082H959L605 547L970 0H756L506 405L256 0H41L406 547L52 1082H266L503 687Z" />
-<glyph unicode="y" horiz-adv-x="969" d="M494 271L746 1082H944L509 -167Q408 -437 188 -437L153 -434L84 -421V-271L134 -275Q228 -275 280 -237T367 -98L408 12L22 1082H224L494 271Z" />
-<glyph unicode="z" horiz-adv-x="1015" d="M314 151H947V0H88V136L685 929H97V1082H917V951L314 151Z" />
-<glyph unicode="{" horiz-adv-x="693" d="M632 -366Q455 -316 366 -202T276 101V300Q276 543 64 543V688Q276 688 276 930V1138Q278 1321 365 1433T632 1597L670 1482Q461 1415 461 1133V931Q461 704 294 615Q461 525 461 296V90Q464 -185 670 -251L632 -366Z" />
-<glyph unicode="|" horiz-adv-x="499" d="M324 -270H175V1456H324V-270Z" />
-<glyph unicode="}" horiz-adv-x="693" d="M19 -251Q222 -186 229 80V300Q229 531 410 615Q229 697 229 930V1133Q229 1415 20 1482L58 1597Q235 1547 324 1435T414 1137V927Q414 688 626 688V543Q414 543 414 300V98Q414 -90 324 -203T58 -366L19 -251Z" />
-<glyph unicode="~" horiz-adv-x="1393" d="M1263 777Q1263 619 1170 511T939 402Q867 402 803 428T655 529T533 621T454 639Q376 639 334 586T292 438L131 436Q131 596 223 699T454 802Q530 802 600 770T758 658T910 567L939 565Q1015 565 1062 623T1110 776L1263 777Z" />
-<glyph unicode="&#xa0;" horiz-adv-x="507" />
-<glyph unicode="&#xa1;" horiz-adv-x="499" d="M170 684H338L351 -360H157L170 684ZM358 996Q358 951 331 920T249 889T167 920T139 996T167 1071T249 1101T330 1071T358 996Z" />
-<glyph unicode="&#xa2;" horiz-adv-x="1120" d="M586 131Q686 131 760 191T842 341H1017Q1011 215 912 115T669 -12V-245H484V-11Q305 23 205 165T105 527V562Q105 774 206 916T484 1092V1318H669V1095Q819 1072 915 966T1017 710H842Q834 815 763 882T586 950Q445
-950 368 849T290 555V520Q290 333 367 232T586 131Z" />
-<glyph unicode="&#xa3;" horiz-adv-x="1190" d="M449 622L457 402Q457 248 395 157H1128L1127 0H95V157H172Q212 166 237 231T264 393V401L256 622H91V779H251L242 1039Q242 1238 364 1357T687 1476Q877 1476 988 1370T1099 1087H908Q908 1194 845 1256T670 1318Q565
-1318 500 1241T435 1039L444 779H763V622H449Z" />
-<glyph unicode="&#xa4;" horiz-adv-x="1460" d="M1103 112Q944 -20 735 -20Q528 -20 369 110L235 -26L105 109L244 250Q140 406 140 608Q140 814 252 977L105 1128L235 1264L382 1114Q540 1234 735 1234Q931 1234 1090 1113L1239 1265L1371 1128L1220 974Q1330
-811 1330 608Q1330 412 1228 253L1371 109L1239 -27L1103 112ZM311 608Q311 485 368 379T524 212T735 151T946 212T1100 379T1157 608Q1157 730 1101 835T946 1001T735 1062Q622 1062 524 1002T369 836T311 608Z" />
-<glyph unicode="&#xa5;" horiz-adv-x="1075" d="M539 793L847 1456H1060L693 736H954V611H630V446H954V322H630V0H437V322H119V446H437V611H119V736H382L15 1456H231L539 793Z" />
-<glyph unicode="&#xa6;" horiz-adv-x="491" d="M147 -270V521H333V-270H147ZM333 698H147V1456H333V698Z" />
-<glyph unicode="&#xa7;" horiz-adv-x="1256" d="M1145 431Q1145 242 959 157Q1028 108 1064 40T1100 -128Q1100 -296 970 -395T612 -495Q500 -495 400 -467T229 -382Q90 -269 90 -64L276 -62Q276 -192 366 -267T612 -343Q748 -343 831 -285T914 -130Q914 -41 843
-11T563 126Q381 174 285 229T143 362T96 551Q96 737 278 825Q212 874 177 942T141 1110Q141 1276 274 1376T630 1476Q862 1476 992 1363T1122 1045H937Q937 1170 853 1247T630 1325Q488 1325 408 1268T327 1112Q327 1043 355 1003T450 931T661 858T889 782T1030
-698T1116 585T1145 431ZM602 691Q512 715 437 742Q357 723 320 673T282 553Q282 483 309 443T402 370T611 296T797 238Q875 258 917 308T959 428Q959 516 890 570T602 691Z" />
-<glyph unicode="&#xa8;" horiz-adv-x="856" d="M101 1371Q101 1416 128 1446T210 1477T292 1447T320 1371T292 1296T210 1266T129 1296T101 1371ZM531 1369Q531 1414 558 1445T640 1476T722 1445T750 1369T722 1294T640 1264T559 1294T531 1369Z" />
-<glyph unicode="&#xa9;" horiz-adv-x="1609" d="M1119 597Q1119 444 1033 364T788 283Q631 283 537 388T442 676V786Q442 962 537 1067T788 1173Q948 1173 1034 1091T1120 860H974Q974 959 927 1001T788 1044Q694 1044 640 975T586 783V670Q586 550 640 481T788
-412Q880 412 926 454T973 597H1119ZM206 729Q206 557 286 411T503 181T801 98T1098 181T1315 410T1395 729Q1395 899 1316 1044T1100 1272T801 1356Q641 1356 503 1274T286 1045T206 729ZM91 729Q91 931 184 1104T443 1376T801 1476T1158 1377T1416 1104T1510 729Q1510
-532 1420 360T1165 84T801 -21Q604 -21 439 82T182 358T91 729Z" />
-<glyph unicode="&#xaa;" horiz-adv-x="915" d="M618 705Q606 739 600 777Q524 691 396 691Q277 691 212 753T147 918Q147 1029 230 1089T486 1149H594V1201Q594 1336 470 1336Q401 1336 362 1309T322 1231L161 1243Q161 1346 247 1411T470 1476Q603 1476 680 1405T757
-1199V883Q757 786 783 705H618ZM435 828Q478 828 522 848T594 895V1037H482Q399 1036 355 1005T310 922Q310 828 435 828Z" />
-<glyph unicode="&#xab;" horiz-adv-x="961" d="M536 804L794 407H653L358 795V814L653 1203H794L536 804ZM610 548L868 151H727L432 539V558L727 947H868L610 548Z" />
-<glyph unicode="&#xac;" horiz-adv-x="1134" d="M958 375H772V639H127V800H958V375Z" />
-<glyph unicode="&#xad;" horiz-adv-x="565" d="M525 543H37V694H525V543Z" />
-<glyph unicode="&#xae;" horiz-adv-x="1610" d="M90 729Q90 931 183 1104T442 1376T800 1476T1157 1377T1415 1104T1509 729Q1509 532 1419 360T1164 84T800 -21Q603 -21 438 82T181 358T90 729ZM205 729Q205 557 285 411T502 181T800 98Q961 98 1099 182T1315
-412T1394 729Q1394 900 1316 1044T1099 1272T800 1356Q640 1356 502 1274T285 1045T205 729ZM653 654V316H512V1165H788Q941 1165 1025 1100T1110 909Q1110 786 982 721Q1104 671 1105 517V456Q1105 370 1122 332V316H977Q963 352 963 444T960 554Q944 650 829
-654H653ZM653 782H809Q881 784 925 817T969 904Q969 977 930 1007T791 1038H653V782Z" />
-<glyph unicode="&#xaf;" horiz-adv-x="938" d="M814 1302H142V1445H814V1302Z" />
-<glyph unicode="&#xb0;" horiz-adv-x="765" d="M130 1216Q130 1320 204 1398T385 1476Q489 1476 562 1399T636 1216Q636 1110 563 1035T385 960Q280 960 205 1035T130 1216ZM385 1088Q439 1088 476 1123T513 1216Q513 1274 476 1311T385 1349Q330 1349 293 1310T255
-1216T292 1125T385 1088Z" />
-<glyph unicode="&#xb1;" horiz-adv-x="1094" d="M649 854H1013V703H649V289H482V703H97V854H482V1267H649V854ZM970 0H135V152H970V0Z" />
-<glyph unicode="&#xb2;" horiz-adv-x="751" d="M683 667H84V775L384 1057Q493 1159 493 1228Q493 1277 461 1307T369 1338Q294 1338 259 1300T223 1205H66Q66 1319 149 1393T365 1467T574 1404T651 1230Q651 1126 544 1019L460 940L284 795H683V667Z" />
-<glyph unicode="&#xb3;" horiz-adv-x="751" d="M265 1126H349Q423 1126 459 1156T495 1235Q495 1280 464 1309T362 1338Q305 1338 268 1313T230 1246H73Q73 1344 154 1405T360 1467Q497 1467 575 1407T653 1242Q653 1187 618 1142T517 1071Q666 1030 666 887Q666
-781 581 719T360 656Q228 656 145 719T62 889H220Q220 844 259 814T366 784Q436 784 472 814T509 895Q509 1008 353 1010H265V1126Z" />
-<glyph unicode="&#xb4;" horiz-adv-x="642" d="M316 1536H540L272 1242H123L316 1536Z" />
-<glyph unicode="&#xb5;" horiz-adv-x="1160" d="M339 1082V449Q340 286 391 208T559 130Q758 130 820 282V1082H1006V0H839L830 115Q737 -20 567 -20Q420 -20 339 53V-416H154V1082H339Z" />
-<glyph unicode="&#xb6;" horiz-adv-x="1001" d="M646 0V520H562Q332 520 200 647T67 988Q67 1201 200 1328T563 1456H832V0H646Z" />
-<glyph unicode="&#xb7;" horiz-adv-x="534" d="M147 729Q147 777 175 809T261 841T347 809T377 729Q377 682 348 651T261 619T176 650T147 729Z" />
-<glyph unicode="&#xb8;" horiz-adv-x="507" d="M285 0L273 -52Q426 -79 426 -225Q426 -322 346 -378T123 -435L116 -328Q195 -328 238 -302T282 -229Q282 -185 250 -164T120 -134L152 0H285Z" />
-<glyph unicode="&#xb9;" horiz-adv-x="751" d="M495 667H338V1268L122 1211V1339L477 1456H495V667Z" />
-<glyph unicode="&#xba;" horiz-adv-x="931" d="M122 1123Q122 1281 216 1378T464 1476Q619 1476 713 1380T807 1117V1043Q807 884 714 787T466 690T217 787T122 1049V1123ZM285 1043Q285 943 333 886T466 829Q549 829 596 886T644 1045V1123Q644 1222 596 1279T464
-1336Q383 1336 335 1281T285 1129V1043Z" />
-<glyph unicode="&#xbb;" horiz-adv-x="960" d="M244 949L539 560V541L244 152H102L360 550L102 949H244ZM593 949L888 560V541L593 152H451L709 550L451 949H593Z" />
-<glyph unicode="&#xbc;" horiz-adv-x="1500" d="M458 664H301V1265L85 1208V1336L440 1453H458V664ZM443 118L339 184L1050 1322L1154 1256L443 118ZM1318 299H1425V169H1318V0H1161V169H786L780 271L1157 789H1318V299ZM938 299H1161V588L1144 560L938 299Z" />
-<glyph unicode="&#xbd;" horiz-adv-x="1589" d="M399 118L295 184L1006 1322L1110 1256L399 118ZM453 664H296V1265L80 1208V1336L435 1453H453V664ZM1481 0H882V108L1182 390Q1291 492 1291 561Q1291 610 1259 640T1167 671Q1092 671 1057 633T1021 538H864Q864
-652 947 726T1163 800T1372 737T1449 563Q1449 459 1342 352L1258 273L1082 128H1481V0Z" />
-<glyph unicode="&#xbe;" horiz-adv-x="1593" d="M570 118L466 184L1177 1322L1281 1256L570 118ZM1410 299H1517V169H1410V0H1253V169H878L872 271L1249 789H1410V299ZM1030 299H1253V588L1236 560L1030 299ZM314 1126H398Q472 1126 508 1156T544 1235Q544 1280
-513 1309T411 1338Q354 1338 317 1313T279 1246H122Q122 1344 203 1405T409 1467Q546 1467 624 1407T702 1242Q702 1187 667 1142T566 1071Q715 1030 715 887Q715 781 630 719T409 656Q277 656 194 719T111 889H269Q269 844 308 814T415 784Q485 784 521 814T558
-895Q558 1008 402 1010H314V1126Z" />
-<glyph unicode="&#xbf;" horiz-adv-x="969" d="M588 680Q587 574 567 511T498 388T358 233T255 37L253 0Q253 -109 311 -166T478 -224Q578 -224 640 -168T703 -20H888Q886 -181 774 -283T478 -385Q282 -385 175 -285T68 -5Q68 168 228 343L337 456Q403 534 403
-680H588ZM596 997Q596 952 569 921T487 890T405 921T377 997Q377 1041 405 1071T487 1101T568 1071T596 997Z" />
-<glyph unicode="&#xc0;" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538ZM778 1552H619L361 1846H584L778 1552Z" />
-<glyph unicode="&#xc1;" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538ZM763 1846H987L719 1552H570L763 1846Z" />
-<glyph unicode="&#xc2;" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538ZM975 1572V1562H822L672 1732L523 1562H370V1574L616 1846H728L975 1572Z" />
-<glyph unicode="&#xc3;" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538ZM1027 1814Q1027 1706 966 1639T812 1572Q771 1572 741 1582T663 1623T593 1660T543 1667Q502 1667 473 1636T444 1555L320
-1562Q320 1669 380 1739T534 1809Q569 1809 597 1799T673 1760T746 1722T803 1713Q846 1713 874 1747T903 1826L1027 1814Z" />
-<glyph unicode="&#xc4;" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538ZM350 1681Q350 1726 377 1756T459 1787T541 1757T569 1681T541 1606T459 1576T378 1606T350 1681ZM780 1679Q780 1724
-807 1755T889 1786T971 1755T999 1679T971 1604T889 1574T808 1604T780 1679Z" />
-<glyph unicode="&#xc5;" horiz-adv-x="1336" d="M973 380H363L226 0H28L584 1456H752L1309 0H1112L973 380ZM421 538H916L668 1219L421 538ZM887 1729Q887 1642 825 1584T672 1525Q580 1525 519 1584T457 1729T518 1876T672 1937T825 1876T887 1729ZM556 1729Q556
-1682 589 1648T672 1614Q720 1614 754 1647T788 1729T755 1812T672 1847Q622 1847 589 1812T556 1729Z" />
-<glyph unicode="&#xc6;" horiz-adv-x="1914" d="M1879 0H996L981 353H417L212 0H-14L866 1456H1817V1304H1126L1146 833H1736V682H1152L1174 151H1879V0ZM518 527H974L943 1260L518 527Z" />
-<glyph unicode="&#xc7;" horiz-adv-x="1333" d="M1240 462Q1213 231 1070 106T688 -20Q430 -20 275 165T119 660V800Q119 1003 191 1157T397 1393T705 1476Q937 1476 1077 1347T1240 988H1047Q1022 1162 939 1240T705 1318Q521 1318 417 1182T312 795V654Q312
-417 411 277T688 137Q848 137 933 209T1047 462H1240ZM751 -9L739 -61Q892 -88 892 -234Q892 -331 812 -387T589 -444L582 -337Q661 -337 704 -311T748 -238Q748 -194 716 -173T586 -143L618 -9H751Z" />
-<glyph unicode="&#xc8;" horiz-adv-x="1164" d="M992 673H361V157H1094V0H169V1456H1084V1298H361V830H992V673ZM725 1564H566L308 1858H531L725 1564Z" />
-<glyph unicode="&#xc9;" horiz-adv-x="1164" d="M992 673H361V157H1094V0H169V1456H1084V1298H361V830H992V673ZM710 1858H934L666 1564H517L710 1858Z" />
-<glyph unicode="&#xca;" horiz-adv-x="1164" d="M992 673H361V157H1094V0H169V1456H1084V1298H361V830H992V673ZM922 1584V1574H769L619 1744L470 1574H317V1586L563 1858H675L922 1584Z" />
-<glyph unicode="&#xcb;" horiz-adv-x="1164" d="M992 673H361V157H1094V0H169V1456H1084V1298H361V830H992V673ZM297 1693Q297 1738 324 1768T406 1799T488 1769T516 1693T488 1618T406 1588T325 1618T297 1693ZM727 1691Q727 1736 754 1767T836 1798T918 1767T946
-1691T918 1616T836 1586T755 1616T727 1691Z" />
-<glyph unicode="&#xcc;" horiz-adv-x="557" d="M375 0H183V1456H375V0ZM385 1564H226L-32 1858H191L385 1564Z" />
-<glyph unicode="&#xcd;" horiz-adv-x="557" d="M375 0H183V1456H375V0ZM369 1858H593L325 1564H176L369 1858Z" />
-<glyph unicode="&#xce;" horiz-adv-x="557" d="M375 0H183V1456H375V0ZM582 1584V1574H429L279 1744L130 1574H-23V1586L223 1858H335L582 1584Z" />
-<glyph unicode="&#xcf;" horiz-adv-x="557" d="M375 0H183V1456H375V0ZM-43 1693Q-43 1738 -16 1768T66 1799T148 1769T176 1693T148 1618T66 1588T-15 1618T-43 1693ZM387 1691Q387 1736 414 1767T496 1798T578 1767T606 1691T578 1616T496 1586T415 1616T387 1691Z" />
-<glyph unicode="&#xd0;" horiz-adv-x="1373" d="M199 0V666H7V817H199V1456H610Q800 1456 946 1372T1171 1133T1252 777V684Q1252 478 1173 323T946 85T602 0H199ZM643 666H391V157H592Q814 157 937 294T1062 680V773Q1062 1021 946 1158T615 1298H391V817H643V666Z" />
-<glyph unicode="&#xd1;" horiz-adv-x="1460" d="M1288 0H1095L362 1122V0H169V1456H362L1097 329V1456H1288V0ZM1081 1814Q1081 1706 1020 1639T866 1572Q825 1572 795 1582T717 1623T647 1660T597 1667Q556 1667 527 1636T498 1555L374 1562Q374 1669 434 1739T588
-1809Q623 1809 651 1799T727 1760T800 1722T857 1713Q900 1713 928 1747T957 1826L1081 1814Z" />
-<glyph unicode="&#xd2;" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q533 -20 400 64T194 305T118 668V773Q118 983 191 1144T397 1390T703 1476Q878 1476 1011 1392T1217 1147T1289 773V681ZM1098 775Q1098 1034 994 1172T703 1311Q521
-1311 417 1173T309 788V681Q309 430 414 287T705 143Q891 143 993 278T1098 667V775ZM812 1554H653L395 1848H618L812 1554Z" />
-<glyph unicode="&#xd3;" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q533 -20 400 64T194 305T118 668V773Q118 983 191 1144T397 1390T703 1476Q878 1476 1011 1392T1217 1147T1289 773V681ZM1098 775Q1098 1034 994 1172T703 1311Q521
-1311 417 1173T309 788V681Q309 430 414 287T705 143Q891 143 993 278T1098 667V775ZM797 1848H1021L753 1554H604L797 1848Z" />
-<glyph unicode="&#xd4;" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q533 -20 400 64T194 305T118 668V773Q118 983 191 1144T397 1390T703 1476Q878 1476 1011 1392T1217 1147T1289 773V681ZM1098 775Q1098 1034 994 1172T703 1311Q521
-1311 417 1173T309 788V681Q309 430 414 287T705 143Q891 143 993 278T1098 667V775ZM1009 1574V1564H856L706 1734L557 1564H404V1576L650 1848H762L1009 1574Z" />
-<glyph unicode="&#xd5;" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q533 -20 400 64T194 305T118 668V773Q118 983 191 1144T397 1390T703 1476Q878 1476 1011 1392T1217 1147T1289 773V681ZM1098 775Q1098 1034 994 1172T703 1311Q521
-1311 417 1173T309 788V681Q309 430 414 287T705 143Q891 143 993 278T1098 667V775ZM1061 1816Q1061 1708 1000 1641T846 1574Q805 1574 775 1584T697 1625T627 1662T577 1669Q536 1669 507 1638T478 1557L354 1564Q354 1671 414 1741T568 1811Q603 1811 631 1801T707
-1762T780 1724T837 1715Q880 1715 908 1749T937 1828L1061 1816Z" />
-<glyph unicode="&#xd6;" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q533 -20 400 64T194 305T118 668V773Q118 983 191 1144T397 1390T703 1476Q878 1476 1011 1392T1217 1147T1289 773V681ZM1098 775Q1098 1034 994 1172T703 1311Q521
-1311 417 1173T309 788V681Q309 430 414 287T705 143Q891 143 993 278T1098 667V775ZM384 1683Q384 1728 411 1758T493 1789T575 1759T603 1683T575 1608T493 1578T412 1608T384 1683ZM814 1681Q814 1726 841 1757T923 1788T1005 1757T1033 1681T1005 1606T923
-1576T842 1606T814 1681Z" />
-<glyph unicode="&#xd7;" horiz-adv-x="1092" d="M89 329L419 665L91 1000L210 1123L539 788L868 1123L987 1000L659 665L989 329L870 206L539 543L208 206L89 329Z" />
-<glyph unicode="&#xd8;" horiz-adv-x="1408" d="M1289 681Q1289 467 1217 308T1013 64T705 -20Q534 -20 403 62L306 -93H164L308 138Q118 330 118 690V773Q118 983 191 1144T397 1390T703 1476Q917 1476 1065 1351L1168 1516H1309L1150 1261Q1287 1074 1289 780V681ZM309
-681Q309 437 407 296L971 1200Q869 1311 703 1311Q521 1311 417 1173T309 788V681ZM1098 775Q1098 957 1042 1088L493 207Q584 143 705 143Q891 143 993 278T1098 667V775Z" />
-<glyph unicode="&#xd9;" horiz-adv-x="1328" d="M1194 1456V466Q1193 260 1065 129T716 -18L665 -20Q426 -20 284 109T140 464V1456H330V470Q330 312 417 225T665 137Q828 137 914 224T1001 469V1456H1194ZM773 1552H614L356 1846H579L773 1552Z" />
-<glyph unicode="&#xda;" horiz-adv-x="1328" d="M1194 1456V466Q1193 260 1065 129T716 -18L665 -20Q426 -20 284 109T140 464V1456H330V470Q330 312 417 225T665 137Q828 137 914 224T1001 469V1456H1194ZM758 1846H982L714 1552H565L758 1846Z" />
-<glyph unicode="&#xdb;" horiz-adv-x="1328" d="M1194 1456V466Q1193 260 1065 129T716 -18L665 -20Q426 -20 284 109T140 464V1456H330V470Q330 312 417 225T665 137Q828 137 914 224T1001 469V1456H1194ZM970 1572V1562H817L667 1732L518 1562H365V1574L611
-1846H723L970 1572Z" />
-<glyph unicode="&#xdc;" horiz-adv-x="1328" d="M1194 1456V466Q1193 260 1065 129T716 -18L665 -20Q426 -20 284 109T140 464V1456H330V470Q330 312 417 225T665 137Q828 137 914 224T1001 469V1456H1194ZM345 1681Q345 1726 372 1756T454 1787T536 1757T564
-1681T536 1606T454 1576T373 1606T345 1681ZM775 1679Q775 1724 802 1755T884 1786T966 1755T994 1679T966 1604T884 1574T803 1604T775 1679Z" />
-<glyph unicode="&#xdd;" horiz-adv-x="1230" d="M613 725L993 1456H1211L709 543V0H517V543L15 1456H235L613 725ZM708 1846H932L664 1552H515L708 1846Z" />
-<glyph unicode="&#xde;" horiz-adv-x="1210" d="M352 1456V1163H631Q778 1163 888 1111T1057 961T1117 738Q1117 544 985 429T626 313H352V0H166V1456H352ZM352 1011V465H629Q771 465 851 540T931 736Q931 859 851 934T635 1011H352Z" />
-<glyph unicode="&#xdf;" horiz-adv-x="1218" d="M324 0H139V1111Q139 1319 242 1436T532 1554Q712 1554 810 1465T909 1216Q909 1091 845 990T781 819Q781 768 818 721T950 601T1087 461T1130 317Q1130 158 1029 69T745 -20Q664 -20 574 2T445 52L488 207Q537
-175 604 153T725 131Q832 131 888 178T945 307Q945 359 908 407T777 528T639 671T595 821Q595 910 664 1013T734 1201Q734 1295 682 1348T542 1402Q324 1402 324 1109V0Z" />
-<glyph unicode="&#xe0;" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141ZM687 1242H528L270 1536H493L687 1242Z" />
-<glyph unicode="&#xe1;" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141ZM672 1536H896L628 1242H479L672 1536Z" />
-<glyph unicode="&#xe2;" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141ZM884 1262V1252H731L581 1422L432 1252H279V1264L525 1536H637L884 1262Z" />
-<glyph unicode="&#xe3;" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141ZM936 1504Q936 1396 875 1329T721 1262Q680 1262 650 1272T572 1313T502 1350T452 1357Q411 1357 382 1326T353 1245L229 1252Q229 1359 289
-1429T443 1499Q478 1499 506 1489T582 1450T655 1412T712 1403Q755 1403 783 1437T812 1516L936 1504Z" />
-<glyph unicode="&#xe4;" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141ZM259 1371Q259 1416 286 1446T368 1477T450 1447T478 1371T450 1296T368 1266T287 1296T259 1371ZM689 1369Q689 1414 716 1445T798 1476T880
-1445T908 1369T880 1294T798 1264T717 1294T689 1369Z" />
-<glyph unicode="&#xe5;" horiz-adv-x="1114" d="M808 0Q792 32 782 114Q653 -20 474 -20Q314 -20 212 70T109 300Q109 469 237 562T599 656H779V741Q779 838 721 895T550 953Q451 953 384 903T317 782H131Q131 863 188 938T344 1058T561 1102Q748 1102 854 1009T964
-751V253Q964 104 1002 16V0H808ZM501 141Q588 141 666 186T779 303V525H634Q294 525 294 326Q294 239 352 190T501 141ZM796 1419Q796 1332 734 1274T581 1215Q489 1215 428 1274T366 1419T427 1566T581 1627T734 1566T796 1419ZM465 1419Q465 1372 498 1338T581
-1304Q629 1304 663 1337T697 1419T664 1502T581 1537Q531 1537 498 1502T465 1419Z" />
-<glyph unicode="&#xe6;" horiz-adv-x="1729" d="M1262 -20Q1001 -20 865 160Q800 74 687 27T433 -20Q266 -20 172 66T78 304Q78 461 191 548T526 635H749V720Q749 827 694 888T535 950Q430 950 360 895T290 759L106 778Q106 921 227 1011T535 1102Q650 1102 738
-1061T876 936Q939 1015 1026 1058T1218 1102Q1428 1102 1544 974T1660 612V497H932Q939 321 1026 226T1262 130Q1410 130 1531 206L1578 237L1642 101Q1484 -20 1262 -20ZM469 130Q541 130 620 167T749 258V495H521Q404 493 334 438T264 300Q264 223 317 177T469
-130ZM1218 950Q1103 950 1029 865T937 640H1475V671Q1475 803 1408 876T1218 950Z" />
-<glyph unicode="&#xe7;" horiz-adv-x="1072" d="M574 131Q673 131 747 191T829 341H1004Q999 248 940 164T783 30T574 -20Q353 -20 223 127T92 531V562Q92 720 150 843T316 1034T573 1102Q755 1102 875 993T1004 710H829Q821 815 750 882T573 950Q432 950 355
-849T277 555V520Q277 333 354 232T574 131ZM604 -9L592 -61Q745 -88 745 -234Q745 -331 665 -387T442 -444L435 -337Q514 -337 557 -311T601 -238Q601 -194 569 -173T439 -143L471 -9H604Z" />
-<glyph unicode="&#xe8;" horiz-adv-x="1085" d="M589 -20Q369 -20 231 124T93 511V545Q93 706 154 832T326 1030T566 1102Q777 1102 894 963T1011 565V488H278Q282 328 371 230T599 131Q697 131 765 171T884 277L997 189Q861 -20 589 -20ZM566 950Q454 950 378
-869T284 640H826V654Q818 795 750 872T566 950ZM671 1242H512L254 1536H477L671 1242Z" />
-<glyph unicode="&#xe9;" horiz-adv-x="1085" d="M589 -20Q369 -20 231 124T93 511V545Q93 706 154 832T326 1030T566 1102Q777 1102 894 963T1011 565V488H278Q282 328 371 230T599 131Q697 131 765 171T884 277L997 189Q861 -20 589 -20ZM566 950Q454 950 378
-869T284 640H826V654Q818 795 750 872T566 950ZM656 1536H880L612 1242H463L656 1536Z" />
-<glyph unicode="&#xea;" horiz-adv-x="1085" d="M589 -20Q369 -20 231 124T93 511V545Q93 706 154 832T326 1030T566 1102Q777 1102 894 963T1011 565V488H278Q282 328 371 230T599 131Q697 131 765 171T884 277L997 189Q861 -20 589 -20ZM566 950Q454 950 378
-869T284 640H826V654Q818 795 750 872T566 950ZM868 1262V1252H715L565 1422L416 1252H263V1264L509 1536H621L868 1262Z" />
-<glyph unicode="&#xeb;" horiz-adv-x="1085" d="M589 -20Q369 -20 231 124T93 511V545Q93 706 154 832T326 1030T566 1102Q777 1102 894 963T1011 565V488H278Q282 328 371 230T599 131Q697 131 765 171T884 277L997 189Q861 -20 589 -20ZM566 950Q454 950 378
-869T284 640H826V654Q818 795 750 872T566 950ZM243 1371Q243 1416 270 1446T352 1477T434 1447T462 1371T434 1296T352 1266T271 1296T243 1371ZM673 1369Q673 1414 700 1445T782 1476T864 1445T892 1369T864 1294T782 1264T701 1294T673 1369Z" />
-<glyph unicode="&#xec;" horiz-adv-x="506" d="M341 0H155V1082H341V0ZM615 1497H456L198 1791H421L615 1497Z" />
-<glyph unicode="&#xed;" horiz-adv-x="506" d="M341 0H155V1082H341V0ZM343 1791H567L299 1497H150L343 1791Z" />
-<glyph unicode="&#xee;" horiz-adv-x="506" d="M341 0H155V1082H341V0ZM556 1261V1251H403L253 1421L104 1251H-49V1263L197 1535H309L556 1261Z" />
-<glyph unicode="&#xef;" horiz-adv-x="506" d="M341 0H155V1082H341V0ZM-69 1370Q-69 1415 -42 1445T40 1476T122 1446T150 1370T122 1295T40 1265T-41 1295T-69 1370ZM361 1368Q361 1413 388 1444T470 1475T552 1444T580 1368T552 1293T470 1263T389 1293T361 1368Z" />
-<glyph unicode="&#xf0;" horiz-adv-x="1200" d="M820 1301Q1069 1037 1069 628V535Q1069 377 1011 251T844 52T602 -20Q467 -20 357 44T187 221T126 467Q126 614 182 730T341 912T574 977Q737 977 858 863Q810 1058 669 1199L451 1051L378 1150L570 1281Q438 1372
-255 1421L312 1580Q551 1526 726 1387L915 1516L988 1416L820 1301ZM884 635L882 691Q849 752 780 788T618 825Q473 825 392 730T311 467Q311 327 394 229T606 131Q731 131 807 244T884 541V635Z" />
-<glyph unicode="&#xf1;" horiz-adv-x="1130" d="M315 1082L321 946Q445 1102 645 1102Q988 1102 991 715V0H806V716Q805 833 753 889T589 945Q499 945 431 897T325 771V0H140V1082H315ZM927 1504Q927 1396 866 1329T712 1262Q671 1262 641 1272T563 1313T493 1350T443
-1357Q402 1357 373 1326T344 1245L220 1252Q220 1359 280 1429T434 1499Q469 1499 497 1489T573 1450T646 1412T703 1403Q746 1403 774 1437T803 1516L927 1504Z" />
-<glyph unicode="&#xf2;" horiz-adv-x="1168" d="M91 551Q91 710 153 837T327 1033T582 1102Q803 1102 939 949T1076 542V529Q1076 371 1016 246T843 50T584 -20Q364 -20 228 133T91 538V551ZM277 529Q277 349 360 240T584 131Q725 131 808 241T891 551Q891 729
-807 839T582 950Q445 950 361 841T277 529ZM681 1242H522L264 1536H487L681 1242Z" />
-<glyph unicode="&#xf3;" horiz-adv-x="1168" d="M91 551Q91 710 153 837T327 1033T582 1102Q803 1102 939 949T1076 542V529Q1076 371 1016 246T843 50T584 -20Q364 -20 228 133T91 538V551ZM277 529Q277 349 360 240T584 131Q725 131 808 241T891 551Q891 729
-807 839T582 950Q445 950 361 841T277 529ZM666 1536H890L622 1242H473L666 1536Z" />
-<glyph unicode="&#xf4;" horiz-adv-x="1168" d="M91 551Q91 710 153 837T327 1033T582 1102Q803 1102 939 949T1076 542V529Q1076 371 1016 246T843 50T584 -20Q364 -20 228 133T91 538V551ZM277 529Q277 349 360 240T584 131Q725 131 808 241T891 551Q891 729
-807 839T582 950Q445 950 361 841T277 529ZM878 1262V1252H725L575 1422L426 1252H273V1264L519 1536H631L878 1262Z" />
-<glyph unicode="&#xf5;" horiz-adv-x="1168" d="M91 551Q91 710 153 837T327 1033T582 1102Q803 1102 939 949T1076 542V529Q1076 371 1016 246T843 50T584 -20Q364 -20 228 133T91 538V551ZM277 529Q277 349 360 240T584 131Q725 131 808 241T891 551Q891 729
-807 839T582 950Q445 950 361 841T277 529ZM930 1504Q930 1396 869 1329T715 1262Q674 1262 644 1272T566 1313T496 1350T446 1357Q405 1357 376 1326T347 1245L223 1252Q223 1359 283 1429T437 1499Q472 1499 500 1489T576 1450T649 1412T706 1403Q749 1403 777
-1437T806 1516L930 1504Z" />
-<glyph unicode="&#xf6;" horiz-adv-x="1168" d="M91 551Q91 710 153 837T327 1033T582 1102Q803 1102 939 949T1076 542V529Q1076 371 1016 246T843 50T584 -20Q364 -20 228 133T91 538V551ZM277 529Q277 349 360 240T584 131Q725 131 808 241T891 551Q891 729
-807 839T582 950Q445 950 361 841T277 529ZM253 1371Q253 1416 280 1446T362 1477T444 1447T472 1371T444 1296T362 1266T281 1296T253 1371ZM683 1369Q683 1414 710 1445T792 1476T874 1445T902 1369T874 1294T792 1264T711 1294T683 1369Z" />
-<glyph unicode="&#xf7;" horiz-adv-x="1169" d="M1069 600H71V784H1069V600ZM461 1098Q461 1146 489 1178T575 1210T661 1178T691 1098Q691 1051 662 1020T575 989T490 1020T461 1098ZM461 281Q461 329 489 361T575 393T661 361T691 281Q691 235 662 204T575 172T490
-203T461 281Z" />
-<glyph unicode="&#xf8;" horiz-adv-x="1160" d="M91 551Q91 710 152 836T326 1032T582 1102Q692 1102 786 1060L859 1208H983L881 1003Q1076 849 1076 529Q1076 371 1014 244T840 49T584 -20Q480 -20 394 15L320 -134H196L296 69Q91 218 91 551ZM276 529Q276 335
-373 224L716 918Q654 950 582 950Q444 950 360 841T276 529ZM890 551Q890 733 803 844L463 156Q518 131 584 131Q723 131 806 240T890 535V551Z" />
-<glyph unicode="&#xf9;" horiz-adv-x="1129" d="M808 107Q700 -20 491 -20Q318 -20 228 80T136 378V1082H321V383Q321 137 521 137Q733 137 803 295V1082H988V0H812L808 107ZM673 1242H514L256 1536H479L673 1242Z" />
-<glyph unicode="&#xfa;" horiz-adv-x="1129" d="M808 107Q700 -20 491 -20Q318 -20 228 80T136 378V1082H321V383Q321 137 521 137Q733 137 803 295V1082H988V0H812L808 107ZM658 1536H882L614 1242H465L658 1536Z" />
-<glyph unicode="&#xfb;" horiz-adv-x="1129" d="M808 107Q700 -20 491 -20Q318 -20 228 80T136 378V1082H321V383Q321 137 521 137Q733 137 803 295V1082H988V0H812L808 107ZM870 1262V1252H717L567 1422L418 1252H265V1264L511 1536H623L870 1262Z" />
-<glyph unicode="&#xfc;" horiz-adv-x="1129" d="M808 107Q700 -20 491 -20Q318 -20 228 80T136 378V1082H321V383Q321 137 521 137Q733 137 803 295V1082H988V0H812L808 107ZM245 1371Q245 1416 272 1446T354 1477T436 1447T464 1371T436 1296T354 1266T273 1296T245
-1371ZM675 1369Q675 1414 702 1445T784 1476T866 1445T894 1369T866 1294T784 1264T703 1294T675 1369Z" />
-<glyph unicode="&#xfd;" horiz-adv-x="969" d="M494 271L746 1082H944L509 -167Q408 -437 188 -437L153 -434L84 -421V-271L134 -275Q228 -275 280 -237T367 -98L408 12L22 1082H224L494 271ZM599 1536H823L555 1242H406L599 1536Z" />
-<glyph unicode="&#xfe;" horiz-adv-x="1180" d="M1063 529Q1063 282 950 131T644 -20Q447 -20 334 105V-416H149V1536H334V970Q447 1102 641 1102Q836 1102 949 955T1063 546V529ZM878 550Q878 733 800 839T586 945Q418 945 334 796V279Q417 131 588 131Q721 131
-799 236T878 550Z" />
-<glyph unicode="&#xff;" horiz-adv-x="969" d="M494 271L746 1082H944L509 -167Q408 -437 188 -437L153 -434L84 -421V-271L134 -275Q228 -275 280 -237T367 -98L408 12L22 1082H224L494 271ZM186 1371Q186 1416 213 1446T295 1477T377 1447T405 1371T377 1296T295
-1266T214 1296T186 1371ZM616 1369Q616 1414 643 1445T725 1476T807 1445T835 1369T807 1294T725 1264T644 1294T616 1369Z" />
-<glyph unicode="&#x2013;" horiz-adv-x="1344" d="M1421 651H419V802H1421V651Z" />
-<glyph unicode="&#x2014;" horiz-adv-x="1599" d="M1737 651H401V802H1737V651Z" />
-<glyph unicode="&#x2018;" horiz-adv-x="409" d="M270 1555L376 1483Q283 1356 280 1209V1073H96V1189Q96 1291 144 1391T270 1555Z" />
-<glyph unicode="&#x2019;" horiz-adv-x="409" d="M153 1046L48 1118Q141 1248 144 1392V1536H327V1406Q326 1306 278 1207T153 1046Z" />
-<glyph unicode="&#x201a;" horiz-adv-x="407" d="M141 -283L36 -210Q127 -83 130 63V181H315V81Q315 -20 266 -121T141 -283Z" />
-<glyph unicode="&#x201c;" horiz-adv-x="724" d="M278 1555L384 1483Q291 1356 288 1209V1073H104V1189Q104 1291 152 1391T278 1555ZM593 1555L699 1483Q606 1356 603 1209V1073H419V1189Q419 1291 467 1391T593 1555Z" />
-<glyph unicode="&#x201d;" horiz-adv-x="731" d="M165 1046L60 1118Q153 1248 156 1392V1536H339V1406Q338 1306 290 1207T165 1046ZM472 1046L367 1118Q460 1248 463 1392V1536H646V1406Q645 1306 597 1207T472 1046Z" />
-<glyph unicode="&#x201e;" horiz-adv-x="705" d="M141 -301L36 -229Q127 -92 130 61V246H315V82Q315 -26 266 -131T141 -301ZM437 -301L332 -229Q423 -92 426 61V246H612V82Q612 -25 564 -129T437 -301Z" />
-<glyph unicode="&#x2022;" horiz-adv-x="690" d="M138 772Q138 859 193 915T341 971Q432 971 489 917T546 769V732Q546 645 491 590T342 535Q249 535 194 590T138 734V772Z" />
-<glyph unicode="&#x2039;" horiz-adv-x="614" d="M286 550L544 153H403L108 541V560L403 949H544L286 550Z" />
-<glyph unicode="&#x203a;" horiz-adv-x="614" d="M231 949L526 560V541L231 152H89L347 550L89 949H231Z" />
-</font>
-</defs>
-</svg>
diff --git a/static/fonts/roboto-v18-latin-regular.ttf b/static/fonts/roboto-v18-latin-regular.ttf
deleted file mode 100644
index b91bf3f7e3..0000000000
Binary files a/static/fonts/roboto-v18-latin-regular.ttf and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-regular.woff b/static/fonts/roboto-v18-latin-regular.woff
deleted file mode 100644
index 92dfacc618..0000000000
Binary files a/static/fonts/roboto-v18-latin-regular.woff and /dev/null differ
diff --git a/static/fonts/roboto-v18-latin-regular.woff2 b/static/fonts/roboto-v18-latin-regular.woff2
deleted file mode 100644
index 7e854e669b..0000000000
Binary files a/static/fonts/roboto-v18-latin-regular.woff2 and /dev/null differ
diff --git a/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png b/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png
index aafa4b08ed..e8c5889f49 100644
Binary files a/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png and b/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png differ
diff --git a/static/images/blog/2020-08-31-increase-kubernetes-support-one-year/support-timeline.png b/static/images/blog/2020-08-31-increase-kubernetes-support-one-year/support-timeline.png
new file mode 100644
index 0000000000..8752a5c0ca
Binary files /dev/null and b/static/images/blog/2020-08-31-increase-kubernetes-support-one-year/support-timeline.png differ
diff --git a/static/images/blog/2020-08-31-increase-kubernetes-support-one-year/versions-in-production-text-2.png b/static/images/blog/2020-08-31-increase-kubernetes-support-one-year/versions-in-production-text-2.png
new file mode 100644
index 0000000000..d10a473631
Binary files /dev/null and b/static/images/blog/2020-08-31-increase-kubernetes-support-one-year/versions-in-production-text-2.png differ
diff --git a/static/images/blog/2020-09-02-scaling-kubernetes-networking-endpointslices/endpoint-slices.png b/static/images/blog/2020-09-02-scaling-kubernetes-networking-endpointslices/endpoint-slices.png
new file mode 100644
index 0000000000..3775c51fb1
Binary files /dev/null and b/static/images/blog/2020-09-02-scaling-kubernetes-networking-endpointslices/endpoint-slices.png differ
diff --git a/static/images/docs/admin/k8s_oidc_login.svg b/static/images/docs/admin/k8s_oidc_login.svg
index f9b5bbd93d..2c1435d7e1 100644
--- a/static/images/docs/admin/k8s_oidc_login.svg
+++ b/static/images/docs/admin/k8s_oidc_login.svg
@@ -1 +1 @@
-<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="1116.4078908297458" height="517"><style xmlns="http://www.w3.org/1999/xhtml"></style><defs><clipPath id="sWsmWLPNlqtt"><path fill="none" stroke="none" d="M 0 0 L 32 0 L 32 32 L 0 32 Z"/></clipPath></defs><g transform="translate(0,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="1116.4078908297458" height="517" fill-opacity="0"/></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,204,6)"><g><g transform="translate(0,0) scale(1.69,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.591715976331361,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 169 0 Q 169 0 169 0 L 169 18 Q 169 18 169 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 169 0 Q 169 0 169 0 L 169 18 Q 169 18 169 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,206,8)"><g transform="translate(40,0) matrix(1,0,0,1,0,0) translate(-40,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="166" height="18" fill-opacity="0"/></g></g><g transform="translate(40,0) matrix(1,0,0,1,0,0) translate(-40,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="166" height="14" fill-opacity="0"/></g></g><g transform="translate(40,0) matrix(1,0,0,1,0,0) translate(-40,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="40" y="0" width="86" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="40" y="11">Identity</text><rect fill="rgb(0, 0, 0)" stroke="none" x="40" y="12" width="38" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="78" y="12" width="0" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="78" y="12" width="4" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="82" y="12" width="0" height="1"/><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="82" y="11">Provider</text><rect fill="rgb(0, 0, 0)" stroke="none" x="82" y="12" width="44" height="1"/></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,204,24)"><g><g transform="translate(0,0) scale(1.69,4.7299999999999995)"><g><g transform="scale(0.591715976331361,0.21141649048625794)"><path fill="#000000" stroke="none" d="M 84.5 0 L 84.5 472.99999999999994"/><path fill="none" stroke="#000000" d="M 84.5 0 M 84.5 0 L 84.5 4.999999999999999 M 84.5 4.999999999999999 M 84.5 6.999999999999999 L 84.5 12 M 84.5 12 M 84.5 14 L 84.5 19 M 84.5 19 M 84.5 21 L 84.5 26 M 84.5 26 M 84.5 28 L 84.5 33 M 84.5 33 M 84.5 35 L 84.5 40 M 84.5 40 M 84.5 42 L 84.5 47 M 84.5 47 M 84.5 49 L 84.5 54 M 84.5 54 M 84.5 56 L 84.5 61 M 84.5 61 M 84.5 63 L 84.5 68 M 84.5 68 M 84.5 70 L 84.5 75 M 84.5 75 M 84.5 77 L 84.5 82 M 84.5 82 M 84.5 84 L 84.5 89 M 84.5 89 M 84.5 91 L 84.5 96 M 84.5 96 M 84.5 98 L 84.5 103 M 84.5 103 M 84.5 105 L 84.5 110 M 84.5 110 M 84.5 112 L 84.5 117 M 84.5 117 M 84.5 119 L 84.5 124 M 84.5 124 M 84.5 126 L 84.5 131 M 84.5 131 M 84.5 133 L 84.5 138 M 84.5 138 M 84.5 140 L 84.5 145 M 84.5 145 M 84.5 147 L 84.5 152 M 84.5 152 M 84.5 154 L 84.5 159 M 84.5 159 M 84.5 161 L 84.5 166 M 84.5 166 M 84.5 168 L 84.5 173 M 84.5 173 M 84.5 175 L 84.5 180 M 84.5 180 M 84.5 182 L 84.5 187 M 84.5 187 M 84.5 189 L 84.5 194 M 84.5 194 M 84.5 196 L 84.5 201 M 84.5 201 M 84.5 203 L 84.5 208 M 84.5 208 M 84.5 210 L 84.5 215 M 84.5 215 M 84.5 217 L 84.5 222 M 84.5 222 M 84.5 224 L 84.5 229 M 84.5 229 M 84.5 231 L 84.5 236 M 84.5 236 M 84.5 238 L 84.5 243 M 84.5 243 M 84.5 245 L 84.5 250 M 84.5 250 M 84.5 252 L 84.5 257 M 84.5 257 M 84.5 259 L 84.5 264 M 84.5 264 M 84.5 266 L 84.5 271 M 84.5 271 M 84.5 273 L 84.5 278 M 84.5 278 M 84.5 280 L 84.5 285 M 84.5 285 M 84.5 287 L 84.5 292 M 84.5 292 M 84.5 294 L 84.5 299 M 84.5 299 M 84.5 301 L 84.5 306 M 84.5 306 M 84.5 308 L 84.5 313 M 84.5 313 M 84.5 315 L 84.5 320 M 84.5 320 M 84.5 322 L 84.5 327 M 84.5 327 M 84.5 329 L 84.5 334 M 84.5 334 M 84.5 336 L 84.5 341 M 84.5 341 M 84.5 343 L 84.5 348 M 84.5 348 M 84.5 350 L 84.5 355 M 84.5 355 M 84.5 357 L 84.5 362 M 84.5 362 M 84.5 364 L 84.5 369 M 84.5 369 M 84.5 371 L 84.5 376 M 84.5 376 M 84.5 378 L 84.5 383 M 84.5 383 M 84.5 385 L 84.5 390 M 84.5 390 M 84.5 392 L 84.5 397 M 84.5 397 M 84.5 399 L 84.5 404 M 84.5 404 M 84.5 406 L 84.5 411 M 84.5 411 M 84.5 413 L 84.5 418 M 84.5 418 M 84.5 420 L 84.5 425 M 84.5 425 M 84.5 427 L 84.5 432 M 84.5 432 M 84.5 434 L 84.5 439 M 84.5 439 M 84.5 441 L 84.5 446 M 84.5 446 M 84.5 448 L 84.5 453 M 84.5 453 M 84.5 455 L 84.5 460 M 84.5 460 M 84.5 462 L 84.5 467 M 84.5 467 M 84.5 469 L 84.5 472.99999999999994" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,620,6)"><g><g transform="translate(0,0) scale(1.2,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.8333333333333334,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,620,24)"><g><g transform="translate(0,0) scale(1.2,4.7299999999999995)"><g><g transform="scale(0.8333333333333334,0.21141649048625794)"><path fill="#000000" stroke="none" d="M 60 0 L 60 472.99999999999994"/><path fill="none" stroke="#000000" d="M 60 0 M 60 0 L 60 4.999999999999999 M 60 4.999999999999999 M 60 6.999999999999999 L 60 12 M 60 12 M 60 14 L 60 19 M 60 19 M 60 21 L 60 26 M 60 26 M 60 28 L 60 33 M 60 33 M 60 35 L 60 40 M 60 40 M 60 42 L 60 47 M 60 47 M 60 49 L 60 54 M 60 54 M 60 56 L 60 61 M 60 61 M 60 63 L 60 68 M 60 68 M 60 70 L 60 75 M 60 75 M 60 77 L 60 82 M 60 82 M 60 84 L 60 89 M 60 89 M 60 91 L 60 96 M 60 96 M 60 98 L 60 103 M 60 103 M 60 105 L 60 110 M 60 110 M 60 112 L 60 117 M 60 117 M 60 119 L 60 124 M 60 124 M 60 126 L 60 131 M 60 131 M 60 133 L 60 138 M 60 138 M 60 140 L 60 145 M 60 145 M 60 147 L 60 152 M 60 152 M 60 154 L 60 159 M 60 159 M 60 161 L 60 166 M 60 166 M 60 168 L 60 173 M 60 173 M 60 175 L 60 180 M 60 180 M 60 182 L 60 187 M 60 187 M 60 189 L 60 194 M 60 194 M 60 196 L 60 201 M 60 201 M 60 203 L 60 208 M 60 208 M 60 210 L 60 215 M 60 215 M 60 217 L 60 222 M 60 222 M 60 224 L 60 229 M 60 229 M 60 231 L 60 236 M 60 236 M 60 238 L 60 243 M 60 243 M 60 245 L 60 250 M 60 250 M 60 252 L 60 257 M 60 257 M 60 259 L 60 264 M 60 264 M 60 266 L 60 271 M 60 271 M 60 273 L 60 278 M 60 278 M 60 280 L 60 285 M 60 285 M 60 287 L 60 292 M 60 292 M 60 294 L 60 299 M 60 299 M 60 301 L 60 306 M 60 306 M 60 308 L 60 313 M 60 313 M 60 315 L 60 320 M 60 320 M 60 322 L 60 327 M 60 327 M 60 329 L 60 334 M 60 334 M 60 336 L 60 341 M 60 341 M 60 343 L 60 348 M 60 348 M 60 350 L 60 355 M 60 355 M 60 357 L 60 362 M 60 362 M 60 364 L 60 369 M 60 369 M 60 371 L 60 376 M 60 376 M 60 378 L 60 383 M 60 383 M 60 385 L 60 390 M 60 390 M 60 392 L 60 397 M 60 397 M 60 399 L 60 404 M 60 404 M 60 406 L 60 411 M 60 411 M 60 413 L 60 418 M 60 418 M 60 420 L 60 425 M 60 425 M 60 427 L 60 432 M 60 432 M 60 434 L 60 439 M 60 439 M 60 441 L 60 446 M 60 446 M 60 448 L 60 453 M 60 453 M 60 455 L 60 460 M 60 460 M 60 462 L 60 467 M 60 467 M 60 469 L 60 472.99999999999994" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,622,8)"><g transform="translate(38,0) matrix(1,0,0,1,0,0) translate(-38,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="18" fill-opacity="0"/></g></g><g transform="translate(38,0) matrix(1,0,0,1,0,0) translate(-38,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="14" fill-opacity="0"/></g></g><g transform="translate(38,0) matrix(1,0,0,1,0,0) translate(-38,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="38" y="0" width="41" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="38" y="11">Kubectl</text><rect fill="rgb(0, 0, 0)" stroke="none" x="38" y="12" width="41" height="1"/></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,15,6)"><g><g transform="translate(0,0) scale(1.2,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.8333333333333334,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,15,24)"><g><g transform="translate(0,0) scale(1.2,4.73)"><g><g transform="scale(0.8333333333333334,0.2114164904862579)"><path fill="#000000" stroke="none" d="M 60 0 L 60 473.00000000000006"/><path fill="none" stroke="#000000" d="M 60 0 M 60 0 L 60 5 M 60 5 M 60 7 L 60 12 M 60 12 M 60 14 L 60 19 M 60 19 M 60 21 L 60 26 M 60 26 M 60 28 L 60 33 M 60 33 M 60 35 L 60 40 M 60 40 M 60 42 L 60 47 M 60 47 M 60 49 L 60 54 M 60 54 M 60 56 L 60 61 M 60 61 M 60 63 L 60 68 M 60 68 M 60 70 L 60 75 M 60 75 M 60 77 L 60 82 M 60 82 M 60 84 L 60 89 M 60 89 M 60 91 L 60 96 M 60 96 M 60 98 L 60 103 M 60 103 M 60 105 L 60 110 M 60 110 M 60 112 L 60 117 M 60 117 M 60 119 L 60 124 M 60 124 M 60 126 L 60 131 M 60 131 M 60 133 L 60 138 M 60 138 M 60 140 L 60 145 M 60 145 M 60 147 L 60 152 M 60 152 M 60 154 L 60 159 M 60 159 M 60 161 L 60 166 M 60 166 M 60 168 L 60 173 M 60 173 M 60 175 L 60 180 M 60 180 M 60 182 L 60 187 M 60 187 M 60 189 L 60 194 M 60 194 M 60 196 L 60 201 M 60 201 M 60 203 L 60 208 M 60 208 M 60 210 L 60 215 M 60 215 M 60 217 L 60 222 M 60 222 M 60 224 L 60 229 M 60 229 M 60 231 L 60 236 M 60 236 M 60 238 L 60 243 M 60 243 M 60 245 L 60 250 M 60 250 M 60 252 L 60 257 M 60 257 M 60 259 L 60 264 M 60 264 M 60 266 L 60 271 M 60 271 M 60 273 L 60 278 M 60 278 M 60 280 L 60 285 M 60 285 M 60 287 L 60 292 M 60 292 M 60 294 L 60 299 M 60 299 M 60 301 L 60 306 M 60 306 M 60 308 L 60 313 M 60 313 M 60 315 L 60 320 M 60 320 M 60 322 L 60 327 M 60 327 M 60 329 L 60 334 M 60 334 M 60 336 L 60 341 M 60 341 M 60 343 L 60 348 M 60 348 M 60 350 L 60 355 M 60 355 M 60 357 L 60 362 M 60 362 M 60 364 L 60 369 M 60 369 M 60 371 L 60 376 M 60 376 M 60 378 L 60 383 M 60 383 M 60 385 L 60 390 M 60 390 M 60 392 L 60 397 M 60 397 M 60 399 L 60 404 M 60 404 M 60 406 L 60 411 M 60 411 M 60 413 L 60 418 M 60 418 M 60 420 L 60 425 M 60 425 M 60 427 L 60 432 M 60 432 M 60 434 L 60 439 M 60 439 M 60 441 L 60 446 M 60 446 M 60 448 L 60 453 M 60 453 M 60 455 L 60 460 M 60 460 M 60 462 L 60 467 M 60 467 M 60 469 L 60 473.00000000000006" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,17,8)"><g transform="translate(46,0) matrix(1,0,0,1,0,0) translate(-46,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="18" fill-opacity="0"/></g></g><g transform="translate(46,0) matrix(1,0,0,1,0,0) translate(-46,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="14" fill-opacity="0"/></g></g><g transform="translate(46,0) matrix(1,0,0,1,0,0) translate(-46,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="46" y="0" width="25" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="46" y="11">User</text><rect fill="rgb(0, 0, 0)" stroke="none" x="46" y="12" width="25" height="1"/></g></g><g transform="matrix(1,0,0,1,70.96667078087722,46)"><image width="228" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOQAAAAoCAYAAADufVZCAAABvklEQVR4Xu3bwU3DUBBF0QmNhY6gAkIHQAfQWegAaAD0kZGiKOz8oxnPiZQFLL7f3DdXMQZ24YUAAmkI7NIkEQQBBIKQlgCBRAQImagMURAgpB1AIBEBQiYqQxQECGkHEEhEgJCJyhAFAULaAQQSESBkojJEQYCQdgCBRAQImagMURAgpB1AIBEBQiYqQxQECGkHEEhEgJCJyhAlHYHbiDgu76uEI+RVMLtIUQKPEXEXEc8R8RIRH7PnIORsws6vTGAIeVgG+IyIp9liErLyusg+m8CpkN8Rv/8/PG5hx/ffZlz8XMjx9cOMCzkTgYIExs+Q433pNUXMcyFvCFlwbUSeRWDIuP/n8Pflk/J1zYu7ZV2TprO2RuDSLesUEf/AEXJrK2SeNQmcCvm1PNQZT1ynPW0l5Jr1OWtrBIaQ98uvPaaK6BNya6tjnhkE/GHADKrORKAKAbesVZqSswUBQrao2ZBVCBCySlNytiBAyBY1G7IKAUJWaUrOFgQI2aJmQ1YhQMgqTcnZggAhW9RsyCoECFmlKTlbECBki5oNWYUAIas0JWcLAoRsUbMhqxAgZJWm5GxBgJAtajZkFQI/YJsgKUEAfKYAAAAASUVORK5CYII=" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,133,39)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 87 0 L 87 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="87" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 87 0 L 87 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="87" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 84 0 L 84 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="81" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 84 0 L 84 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="81" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">1</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="20" y="11">Login</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="53" y="11">to</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="66" y="11">IdP</text></g></g><g transform="matrix(1,0,0,1,64.5,77)"><image width="232" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOgAAAAoCAYAAAD0QbbMAAAB9UlEQVR4Xu3bXUrccBiF8WO7ALuDurTuQLuCtjtwL4KXot6K0A31gz8YEXGcgSHJCf4CIReTIWee9zyTj2FOYkEAgVoCJ7XJBEMAgRBUCRAoJkDQ4uGIhgBBdQCBYgIELR6OaAgQVAcQKCZA0OLhiIYAQXUAgWICBC0ejmgIEFQHECgmQNDi4YiGAEF1AIFiAgQtHo5oCBBUBxAoJrC0oGdJxnpbzEQ0BGoILCXokPJHkm9JfiX5WUNAEASKCcwt6Jck50m+Jzl94kDQ4kJsNNqnJGP9vGP73muv37P2vvdJ7qY5zCnoxdOZcoj5L3n+7+kWBd364Ncu3T6BjpXkb5Kx/tmxfe+11+9Ze9+bl7eAcwg6LmPH5ey4rH1reUjyuPA33jEFHYy2Pvi1S7dPoGMl2eiJf3/suQQd95hfdxz+OsnVwt94xxR0nP0tCKxCYA5Bpw8yzqRvibrFS9xVhuOgCMwp6C5RCap3CBxIYAlBpyjTQ6NLP7McOB27fXgCSwo6YI+fXcbDo98fnjwACBxAYGlBD4hkFwQQmAgQVBcQKCZA0OLhiIYAQXUAgWICBC0ejmgIEFQHECgmQNDi4YiGAEF1AIFiAgQtHo5oCBBUBxAoJkDQ4uGIhgBBdQCBYgIELR6OaAgQVAcQKCZA0OLhiIbAf4Mp3SmbG3nMAAAAAElFTkSuQmCC" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,95,82)"><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 0 0 L 183 0 L 183 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="183" height="28" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 0 0 L 183 0 L 183 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="183" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 3 0 L 180 0 L 180 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="177" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 3 0 L 180 0 L 180 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="177" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">2</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Provide</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="60" y="11">acces_token</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="128" y="11">,</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="135" y="11">id_token</text></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 0 14 L 183 14 L 183 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="14" width="183" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 43 14 L 140 14 L 140 28 L 43 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="43" y="14" width="97" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 43 14 L 140 14 L 140 28 L 43 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="43" y="14" width="97" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="43" y="25">and</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="66" y="25">refresh_token</text></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,279,66)"><g><g transform="translate(0,0) scale(0.19,0.31)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,3.2258064516129035)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,65.5,97)"><g><g transform="translate(0,0) scale(0.19,0.42)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,2.380952380952381)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 42 Q 19 42 19 42 L 0 42 Q 0 42 0 42 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 42 Q 19 42 19 42 L 0 42 Q 0 42 0 42 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,870.5,6)"><g><g transform="translate(0,0) scale(1.2,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.8333333333333334,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,870.5,24)"><g><g transform="translate(0,0) scale(1.2,4.7299999999999995)"><g><g transform="scale(0.8333333333333334,0.21141649048625794)"><path fill="#000000" stroke="none" d="M 60 0 L 60 472.99999999999994"/><path fill="none" stroke="#000000" d="M 60 0 M 60 0 L 60 4.999999999999999 M 60 4.999999999999999 M 60 6.999999999999999 L 60 12 M 60 12 M 60 14 L 60 19 M 60 19 M 60 21 L 60 26 M 60 26 M 60 28 L 60 33 M 60 33 M 60 35 L 60 40 M 60 40 M 60 42 L 60 47 M 60 47 M 60 49 L 60 54 M 60 54 M 60 56 L 60 61 M 60 61 M 60 63 L 60 68 M 60 68 M 60 70 L 60 75 M 60 75 M 60 77 L 60 82 M 60 82 M 60 84 L 60 89 M 60 89 M 60 91 L 60 96 M 60 96 M 60 98 L 60 103 M 60 103 M 60 105 L 60 110 M 60 110 M 60 112 L 60 117 M 60 117 M 60 119 L 60 124 M 60 124 M 60 126 L 60 131 M 60 131 M 60 133 L 60 138 M 60 138 M 60 140 L 60 145 M 60 145 M 60 147 L 60 152 M 60 152 M 60 154 L 60 159 M 60 159 M 60 161 L 60 166 M 60 166 M 60 168 L 60 173 M 60 173 M 60 175 L 60 180 M 60 180 M 60 182 L 60 187 M 60 187 M 60 189 L 60 194 M 60 194 M 60 196 L 60 201 M 60 201 M 60 203 L 60 208 M 60 208 M 60 210 L 60 215 M 60 215 M 60 217 L 60 222 M 60 222 M 60 224 L 60 229 M 60 229 M 60 231 L 60 236 M 60 236 M 60 238 L 60 243 M 60 243 M 60 245 L 60 250 M 60 250 M 60 252 L 60 257 M 60 257 M 60 259 L 60 264 M 60 264 M 60 266 L 60 271 M 60 271 M 60 273 L 60 278 M 60 278 M 60 280 L 60 285 M 60 285 M 60 287 L 60 292 M 60 292 M 60 294 L 60 299 M 60 299 M 60 301 L 60 306 M 60 306 M 60 308 L 60 313 M 60 313 M 60 315 L 60 320 M 60 320 M 60 322 L 60 327 M 60 327 M 60 329 L 60 334 M 60 334 M 60 336 L 60 341 M 60 341 M 60 343 L 60 348 M 60 348 M 60 350 L 60 355 M 60 355 M 60 357 L 60 362 M 60 362 M 60 364 L 60 369 M 60 369 M 60 371 L 60 376 M 60 376 M 60 378 L 60 383 M 60 383 M 60 385 L 60 390 M 60 390 M 60 392 L 60 397 M 60 397 M 60 399 L 60 404 M 60 404 M 60 406 L 60 411 M 60 411 M 60 413 L 60 418 M 60 418 M 60 420 L 60 425 M 60 425 M 60 427 L 60 432 M 60 432 M 60 434 L 60 439 M 60 439 M 60 441 L 60 446 M 60 446 M 60 448 L 60 453 M 60 453 M 60 455 L 60 460 M 60 460 M 60 462 L 60 467 M 60 467 M 60 469 L 60 472.99999999999994" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,873,8)"><g transform="translate(29,0) matrix(1,0,0,1,0,0) translate(-29,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="18" fill-opacity="0"/></g></g><g transform="translate(29,0) matrix(1,0,0,1,0,0) translate(-29,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="14" fill-opacity="0"/></g></g><g transform="translate(29,0) matrix(1,0,0,1,0,0) translate(-29,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="29" y="0" width="59" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="30" y="11">API</text><rect fill="rgb(0, 0, 0)" stroke="none" x="30" y="12" width="19" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="49" y="12" width="0" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="49" y="12" width="3" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="52" y="12" width="0" height="1"/><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="52" y="11">Server</text><rect fill="rgb(0, 0, 0)" stroke="none" x="52" y="12" width="36" height="1"/></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,670.5,139)"><g><g transform="translate(0,0) scale(0.19,0.31)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,3.2258064516129035)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,80.5,119)"><image width="610" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAmIAAAAoCAYAAABdCpbFAAAC4ElEQVR4Xu3cwU3DQBBA0UlHdAAdQQdABUAH0BElQAdAA6CVHImDuYxmPbZ4kbgg7Y7zsoevOMkpPAgQIECAAAECBFoETi1TDSVAgAABAgQIEAgh5hAQIECAAAECBJoEhFgTvLEECBAgQIAAASHmDBAgQIAAAQIEmgSEWBO8sQQIECBAgAABIeYMECBAgAABAgSaBIRYE7yxBAgQIECAAAEh5gwQIECAAAECBJoEhFgTvLEECBAgQIAAASHmDBAgQIAAAQIEmgSEWBO8sQQIECBAgAABIeYMECBAgAABAgSaBIRYE7yxBAgQIECAAAEh5gwQIECAAAECBJoEhFgTvLEECBAgQIDA7gSuIuI1Ij62ujIhtpW0OQQIECBAgMDeBe4i4joiHiPiaYsgE2J7PxKujwABAgQIENhKYITY7TLsMyIeIuJ+5nAhNlPX3gQIECBAgMCRBH6H2HdEjE56i4jx/5cZT2QtxM4lOGOePQkQIECAAAECexUYnxEbf2uPKUG2FmKj+jwIECBAgAABAv9NYETY5R9P+n15Z+y5EsWtyUpNexEgQIAAAQJHFli7NTklwM5IQuzIx8W1EyBAgAABApUCv0Psa/mw/tQ7hUKs8uWzFwECBAgQIHBkgRFdN8vPV4yfsJj+e2JC7MjHxbUTIECAAAEClQIXy7ckpweYW5OVL5u9CBAgQIAAAQIJAe+IJdAsIUCAAAECBAhUCAixCkV7ECBAgAABAgQSAkIsgWYJAQIECBAgQKBCQIhVKNqDAAECBAgQIJAQEGIJNEsIECBAgAABAhUCQqxC0R4ECBAgQIAAgYSAEEugWUKAAAECBAgQqBAQYhWK9iBAgAABAgQIJASEWALNEgIECBAgQIBAhYAQq1C0BwECBAgQIEAgISDEEmiWECBAgAABAgQqBIRYhaI9CBAgQIAAAQIJASGWQLOEAAECBAgQIFAhIMQqFO1BgAABAgQIEEgI/AATdB4pebrH5AAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,292,145)"><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 0 0 L 296 0 L 296 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="296" height="28" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 0 0 L 296 0 L 296 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="296" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 3 0 L 293 0 L 293 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="290" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 3 0 L 293 0 L 293 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="290" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">3</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="20" y="11">Call</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="44" y="11">kubectl</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="85" y="11">with</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="106" y="11"> --</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="118" y="11">token</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="150" y="11">being</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="183" y="11">the</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="203" y="11">id_token</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="252" y="11">OR</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="273" y="11">add</text></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 0 14 L 296 14 L 296 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="14" width="296" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 84 14 L 212 14 L 212 28 L 84 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="84" y="14" width="128" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 84 14 L 212 14 L 212 28 L 84 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="84" y="14" width="128" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="84" y="25">tokens</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="122" y="25">to</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="132" y="25"> .</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="139" y="25">kubectl</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="177" y="25">/</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="180" y="25">config</text></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,921,170)"><g><g transform="translate(0,0) scale(0.19,2.3100000000000005)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,0.4329004329004328)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 231.00000000000006 Q 19 231.00000000000006 19 231.00000000000006 L 0 231.00000000000006 Q 0 231.00000000000006 0 231.00000000000006 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 231.00000000000006 Q 19 231.00000000000006 19 231.00000000000006 L 0 231.00000000000006 Q 0 231.00000000000006 0 231.00000000000006 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,685.5,150)"><image width="255" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAP8AAAAoCAYAAAAxMyxdAAABz0lEQVR4Xu3YwU3DQBAF0ElnlEApUAHQCXRACdABJaQT0EoJyiFyxo4dwczzJZfdtefN/njlXbgIEGgpsGtZtaIJEAjhtwkINBUQ/qaNVzYB4bcHCDQVEP6mjVc2AeG3Bwg0FRD+po1XNgHhtwcINBUQ/qaNVzYB4bcHCDQVEP6mjVc2AeG3Bwg0FRD+po1XNgHhtwcINBUQ/qaNV/afFLiPiPdbPZnw30rafQhcFviOiI+IeDn8Xp5xxQjhvwLPVAIrC4zwH6/xJ/AYEV8r3+N3OeHfSta6BOYLnIb/OPv1cBLYz19uesa58D+tfRPrESCQEnieGLX6n8C58E89QKoCgwgQWCQw9eJ9i4iRzdVOAI79i3pkEoFNBM4d+1cP/fHJhX+THlqUwCKB0/B/RsSDD36LHE0i8O8ERvhH6Mfxfnzt3/Ty5t+U1+IEZgnc3SL0jv2zemIwgXoC3vz1eqoiAikB4U8xGUSgnoDw1+upigikBIQ/xWQQgXoCwl+vpyoikBIQ/hSTQQTqCQh/vZ6qiEBKQPhTTAYRqCcg/PV6qiICKQHhTzEZRKCegPDX66mKCKQEhD/FZBCBegLCX6+nKiKQEhD+FJNBBOoJ/AAsrxophGreZAAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,725,183)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">4</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="19" y="11">Authorization</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="89" y="11">:</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="96" y="11">Bearer</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="132" y="11">...</text></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,670.5,401)"><g><g transform="translate(0,0) scale(0.19,0.34)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,2.941176470588235)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 34 Q 19 34 19 34 L 0 34 Q 0 34 0 34 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 34 Q 19 34 19 34 L 0 34 Q 0 34 0 34 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,669.5,381)"><image width="255" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAP8AAAAoCAYAAAAxMyxdAAABz0lEQVR4Xu3c0U0CURAF0EsDYgdagiXRgVqB2gF2pJVpXuIaTfRzh0nmkPD9Zs7MhWUhHOJBgMBIgcPIrjVNgECE3xIQGCog/EMHr20Cwm8HCAwVEP6hg9c2AeG3AwSGCgj/0MFrm4Dw2wECQwWEf+jgtU1A+O0AgaECwj908NomIPx2gMBQAeEfOnhtExB+O0BgqEB1+K+T3CV5G+qtbQJtBKrCv0J/n+QhyWuS5zYCCiEwVKAi/CvoK/THL+MX4R+6bdpuJbBn+E9JnpLcJvlIvv87QPhbrYBipgrsEf6fof/LdX3e95l/6sbp+5ICK3fvWwF7hX9d6t/80+U6XPgvuQLOnirw6413j/BvsOsKYHsRcNk/dd303VZgz/BvTa8XgMckV274td0DhQ0UqAj/Yl1f9a07/ut5drd/4KZpuZ1AVfi3xv3Ip90KKGiqQHX4pzrrm0A7AeFvNxIFEagREP4aZ6cQaCcg/O1GoiACNQLCX+PsFALtBIS/3UgURKBGQPhrnJ1CoJ2A8LcbiYII1AgIf42zUwi0ExD+diNREIEaAeGvcXYKgXYCwt9uJAoiUCMg/DXOTiHQTkD4241EQQRqBIS/xtkpBNoJfAJChRgp4jU/qgAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,746,387)"><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 0 0 L 131 0 L 131 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="131" height="28" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 0 0 L 131 0 L 131 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="131" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 3 0 L 128 0 L 128 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="125" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 3 0 L 128 0 L 128 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="125" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">8</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="19" y="11">Authorized</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="77" y="11"> :</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="87" y="11">perform</text></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 0 14 L 131 14 L 131 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="14" width="131" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 4 14 L 127 14 L 127 28 L 4 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="4" y="14" width="123" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 4 14 L 127 14 L 127 28 L 4 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="4" y="14" width="123" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="4" y="25">action</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="39" y="25">and</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="63" y="25">return</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="98" y="25">result</text></g></g><g transform="translate(0,0) matrix(1,0,0,1,59,418)"><g><g clip-path="url(#sWsmWLPNlqtt)"><g transform="translate(0,0) scale(0.31683168316831684,0.31683168316831684)"><g><g><path fill="rgb(0,0,0)" stroke="#000000" d="M 0 100 L 100 0" fill-opacity="0" stroke-linecap="round" stroke-miterlimit="10" stroke-width="5"/></g><g><path fill="rgb(0,0,0)" stroke="#000000" d="M 100 100 L 0 0" fill-opacity="0" stroke-linecap="round" stroke-miterlimit="10" stroke-width="5"/></g></g></g></g></g></g><g transform="matrix(1,0,0,1,71,414)"><image width="603" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAlsAAAAoCAYAAADJ7D83AAADOElEQVR4Xu3cjW3TUBQF4NMFgA1gBTZiA2ACYAMYCPE3AGwEemCjUDVSSnysV/mzFCVS7OvrL1fNcZz0JhYCBAgQIECAAIGawE2tssIECBAgQIAAAQIRtgwBAQIECBAgQKAoIGwVcZUmQIAAAQIECAhbZoAAAQIECBAgUBQQtoq4ShMgQIAAAQIEhC0zQIAAAQIECBAoCghbRVylCRAgQIAAAQLClhkgQIAAAQIECBQFhK0irtIECBAgQIAAAWHLDBAgQIAAAQIEigLCVhFXaQIECBAgQICAsGUGCBAgQIAAAQJFAWGriKs0AQIECBAgQEDYMgMECBAgQIAAgaLA3mHrSZJnSX4Uj0lpAgQIECBAgMA0AnuFrRGyXiZ5leRDkrfTCGiEAAECBAgQIFAU2CNsjWA1Qtbj5TjeCVvFV1RpAgQIECBAYCqBZth6keTNctnwZ5J1X8LWVCOgGQIECBAgQKAp0AhbpyHrrt4/Jfm4PDFC2Lqsj8/dj/WuWefa7Y/Y6yxms/RxyQzM0uvR+2j+3VSbAAEC9xJoha1x6fDpmU6+Jvm2PHe6//XxufuxyTXrXLv9EXudxWyWPi6ZgVl6PXIf35M8v3VCd0lQ3nOdo4fh/zmpZvZnqPec0632dcTX7nOScfu9NMLWWnt8wrWGLpcR75WBrUyAwEYCt0/QjhxC7zr2WTycyPz7nvyQPB5Sr3vO+whaX/YIW2Mf41eI48vxr5M8WnbqO1sbvYsoQ4AAAQIECMwv0Pxk6/To19A1gtd7v0acfzB0SIAAAQIECGwjsFfYWrsd/9B03P5ex9zmMFQhQIAAAQIECMwpsHfYmlNBVwQIECBAgACBkoCwVYJVlgABAgQIECAwBIQtc0CAAAECBAgQKAoIW0VcpQkQIECAAAECwpYZIECAAAECBAgUBYStIq7SBAgQIECAAAFhywwQIECAAAECBIoCwlYRV2kCBAgQIECAgLBlBggQIECAAAECRQFhq4irNAECBAgQIEBA2DIDBAgQIECAAIGigLBVxFWaAAECBAgQICBsmQECBAgQIECAQFFA2CriKk2AAAECBAgQELbMAAECBAgQIECgKPALDx4TOEqFdvMAAAAASUVORK5CYII=" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,320,407)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 88 0 L 88 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="88" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 88 0 L 88 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="88" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 85 0 L 85 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="82" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 85 0 L 85 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="82" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">9</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Return</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="56" y="11">result</text></g></g><g transform="matrix(1,0,0,1,920,250)"><image width="64" height="97" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABhCAYAAABmmadNAAAEBUlEQVR4Xu2ct6sVQRSHv2dAUAyNtgYQCzGCuVARFbQwI4JgKA2o2BhQjIgWRhQEY6H/gWLOKKbSQkUbCwsbFQuz8pNZWW94u/fu3eudOTuwcHl377z5fXN2dmbOOdOG8dJmXD8FgBwsYAPwHvjgrtLPn3L4n3VXmYcF7AF6AT3dVfq5K3AF+A48BB65S6CaXvIAkCSigwM0HhgDjHbXuxiM+8CTpIoa8f3/AFCt3QNjMGQ9Q4FjwIlGCK1WRysBKG3jCGAFsMSBEIwXjYbRygAirZ0dCMF4A+wFrjYKhA8A4lqnAHOAX8DqRkDwDUCkeRWwDpgBPM8CwlcA0jwAuAgcBw7UC8FnAJHm/cAQYGo9EEIAIN3LgAXukaiJQygAJHoesAiYXwuBkABIt9YhmkRtTAshNADSfQq4C5xOAyFEANItALKCe0kQQgUg3U+BscC39iCEDGCbmzFutwpAnfsD0PK7agnZAiR6h3sEdvq4HE4av9J8r97XGNDRKgDpVu9/AXZVghD6IyDNsgLtH2gpXVYsAJDo28AW4E4pASsAqr4SrQCYCGg+MMmqBUj3T/c20Hba32LFAiT4OrAbuGEVgAZB7TBvtQpgHKDBcLpVAL2BZ0AfqwAqTostDYLqeHmg+zq3/R9DsAbglds+fx09BtYAKBZhJfDYKoBLzot02SqAc8AF4LxVAIeBl8ARqwDWOOGHrAIwbwHmxwDzbwHz8wDzM0HTawE5R+Qf6GR1OWx+P0CxydoRmmbVAszvCWo3WH7Cm1YtQP6Asv0PKxsi5j1D5n2Dpr3DesyvWY4PMB0hUnH6a+k12G7vh+4YSYwQCx1AYoxgyAA08isrdYLVWGFlnq4HHpQHxv37lxCnwmfcgudskvgQH4FNQDdgcxrxoQFQrtBClzyVVn8w8QHLXbKUEilrKiGMAUqaHFy61ZWWgs8AlG4vV7eyyg+mFVx6n68A5OVVpMdM5+6uV3/TxwAdp5HlqAzt6M4FPgNr61Yd+2EzLWC2C0/pX2PDu7jzA9Tjcm3tc2GvNVZT+fZmAFCvK4lRAFQmA7dStH6kE77YPedHHYAUP01/S94AJFozM6WzRqUagEHAKHeOSPfYGSIn08up/c68APRz5h71erxlyvJW5oY8NTpBJhL91oWvyYWtOby3p8hocNIubLzX4wCUy6cwta/u2BzF7En0x9r7L/sv8rAAZWUIwqwqzVPmhgC1RMkDQCRMj4FA6HCDHjG1WqUtbQn1TYwVlmDBGOYyuMpyd/4XkDwtoJImCR+eZeraaFDNBtDo9meurwCQGaHnFRQW4HkHZm5+YQGZEXpeQWEBnndg5uYXFpAZoecVFBbgeQdmbn5hAZkRel6BeQv4DVQMomImLlfUAAAAAElFTkSuQmCC" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,902,274)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 195 0 L 195 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="195" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 195 0 L 195 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="195" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 192 0 L 192 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="189" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 192 0 L 192 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="189" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">6</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Has</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="41" y="11">the</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="61" y="11">JWT</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="89" y="11">expired</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="128" y="11">?</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="138" y="11">(</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="142" y="11">iat</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="155" y="11"> +</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="169" y="11">exp</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="188" y="11">)</text></g></g><g transform="matrix(1,0,0,1,920,325)"><image width="64" height="96" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABgCAYAAACtxXToAAADV0lEQVR4Xu2cy6tNURzHP9eMvOfKjEjIKyH8ASJCjLylKMXAY4CRR4mZEiGJkldGjLyVx5Ay9cgjijJD9NXat9259zjn7Hv2tvb+7lW7czr3nrPX97O+e+211/r9Vg/mpcdcPzWAHBywC/gKfAtH4/vvOZwz80/m4YCDwEhgRDga3w8BbgO/gKfAk/D6ObOKAXwxDwCtqjMoAJoNzABmhlc5Q0B0PAIetvqhbvz9fwBoVu+xAYSgjALmAifC8aMbYvv7jZgANNZvPLAlHOcDiGfdBhEzgLTWdQGEPjsEXOkWiLIASPROB5YDY4DV3YBQNgCJ5lXASWARcGcgIMoKQJqHAjeB58DOrBDKDCDRvAPYBIzLAqEKAKRbfYMGV6M7hVAVAAkEjRs0jmi7VAmARK8AlgEr2yVQNQDSvRsYBuxpB0IVAUj3KeAxcLoVhKoCkO5XwALg/b8gVBmAbo3TgM2uAKT7LTALeNcMQpUdIM3rAc07bHAFIN2vgTnAm/4gVN0B0rwGmA+sdQUg3feBJcCXRggODpBmTaBcAK66Atganha3uQKYAFwGJroCkO6PwCTgUxqCSx8gzReBG8AlVwAbw1yBhsi9xckBWng5GuYLLAEMD6NBrVlaApBoLbENBn4mBJwuAWn+AEwOd4S/DNwAvAgrSy9dHXAP2BueDSwdcA04B1x3dUCfyVK3PuBweCQ+4uoAewD2l4B9J2h/G7QfCNkPha0fhuwfh+0nROynxOwnRa2nxe0XRuyXxuwXR62Xx+0DJKxDZOyDpKzD5OwDJa1DZa2Dpa3D5a0TJpQ3ZJsyY500ZZs2Z504WdrUWe0moS01spZSJ08rgekMMDUDhFKnz6vVJVzx+ioL28z4rsQGChJ9Nmymkti+GYD0FhqCNq/MW2hIzLFUq6ev+aXA3ZDM1GwTFSU9PsjaUXTyvTxihLYD+8JOMf3V5Tdwq8rb6KizE4TFTVriALC/k1bK83/zcEBSX10GAqFsLa3MJkVxepqojKLkCSARqA5NnaFgKE5X179cEkUpAkBaqIRPAY5Hod4wWLoP96IdEEvD99ajBhBdkxRcodoBBQOP7nS1A6JrkoIrVDugYODRna52QHRNUnCFagcUDDy609UOiK5JCq7QHzFzn2Fi3wKvAAAAAElFTkSuQmCC" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,924,358)"><g transform="translate(3,0) matrix(1,0,0,1,0,0) translate(-3,0)"><path fill="none" stroke="none" d="M 0 0 L 112 0 L 112 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="112" height="14" fill-opacity="0"/></g></g><g transform="translate(3,0) matrix(1,0,0,1,0,0) translate(-3,0)"><path fill="none" stroke="none" d="M 0 0 L 112 0 L 112 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="112" height="14" fill-opacity="0"/></g></g><g transform="translate(3,0) matrix(1,0,0,1,0,0) translate(-3,0)"><path fill="none" stroke="none" d="M 3 0 L 109 0 L 109 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="106" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">7</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">User</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="45" y="11">Authorized</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="102" y="11">?</text></g></g><g transform="matrix(1,0,0,1,920,177)"><image width="64" height="95" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABfCAYAAABY6cGQAAAEAElEQVR4Xu2cSchNYRjHf1+JlSFTIVOxN5ZhgUyZx4wplCESsjCksGElxMJUhjIsiQ1KbFCGBUlC2MiCzFnI0P/rPV/3u9897vnuuefcc9/nPHW6de8957z/3/uc97zD87wNGLcG4/rJASTgAduALyHHV/f93wTuW9Elk/CAfUDHkKOD+/4GIAgPgPvueFeRgpgnJQEgSpEEYiQwDBjuDpUlgHEHuBnlQnH/UysApcrdowBGF2AacMwdH+MKDTs/SwCKy9gHWOOOWw6EHp2qWpYBFAqd50AMAPYCJ6tFoV4ABHr7A0uAccAs4EdcEPUGINA7HrgMrAbOx4FQrwACzeeANsDCSiHUOwDpXgCcBdoDv1oLwgcA0twO+ADoVfq9NRB8ASDNnYEXgPoQkc0nABI9BDgBDI1KwDcA0j0HWAbMjQLBRwDSrddjP2BHOQi+ApBujTTVlX74Pwg+A5gCbACmWgUg3RpWbwHuhkHw2QOkWV3m7cAEqwCkW0PpXcDtUhB89wBpHg3sCfMCCwAE4SUwGXhV7AVWAGhqTa/D41YBaLisHuIiqwC6As+AblYBSPdjYCnwpBCClTZAmg8Ab4GDVgFMd2ODGVYBqB24CoywCqAt8M1NnzUxsNQGSLQANJs3tAbgDTDGNYaNXmANQItJEmsArgH7getBI2ANgJbRrgAXrAI4DDwHjlgFsNEJP2QVgHkPMN8GmH8LmO8HmO8Jmh4LmB8Naj5QgVWjrM4HaCZoFTDTKgDNBb4GmnqB1obDpmeF9fw/BbpbXRcwvzKkNUHlIiiCrJlZmRAxvTpsPj7AdISIYoO2AhOtxggpOmwzcM8iAMUHrnfJV2H6vV4YUUiM+v6PQtV7vDK0DugJ7PyfeF/HAsowWwzMLyfeRwDKE1BEmDJSI5lPPUFlimjVR4EQkc0XAKZzhjTSO2M1a0yrvPLiFgGQUZ+Ben0EJgGXgJXAxahiS/0vbQCdgM8xCjzQveI0wpsN/IxxrcZT0wQwFjgFDK4AgrJDlf/TG9AOFbpOVSwNAKp1RWkudyVW5reGqOWsL7DWCde+AXq/V31XiaQByE1Pu31DAsFhAHq5Dow6McoC1Q4SR53wT+VoVfp7UgBU63JTASg2JTQqfUURm8EeIvr87VLdtIJb13uIbAJ2F9V6IQTtHqN1+j8Fu8hI9PtKazHOeUl4gBo7QdAOD6VM+TsClAlLAkAgTKmrArEC0LY5ganXFjSINYeQJIBAnNoDtQWqdbXsev7lJZmwNAAUCpXwQcVJC7UkkTaAWmotee8cQOaqJOUC5R6QMvDM3S73gMxVScoFyj0gZeCZu13uAZmrkpQLlHtAysAzd7vcAzJXJSkXyLwH/AOwd55gK2pFNAAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,908,203)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">5</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Is</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="29" y="11">JWT</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="57" y="11">signature</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="110" y="11">valid</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="134" y="11">?</text></g></g></g></svg>
\ No newline at end of file
+<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="1116.4078908297458" height="517"><style xmlns="http://www.w3.org/1999/xhtml"></style><defs><clipPath id="sWsmWLPNlqtt"><path fill="none" stroke="none" d="M 0 0 L 32 0 L 32 32 L 0 32 Z"/></clipPath></defs><g transform="translate(0,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="1116.4078908297458" height="517" fill-opacity="0"/></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,204,6)"><g><g transform="translate(0,0) scale(1.69,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.591715976331361,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 169 0 Q 169 0 169 0 L 169 18 Q 169 18 169 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 169 0 Q 169 0 169 0 L 169 18 Q 169 18 169 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,206,8)"><g transform="translate(40,0) matrix(1,0,0,1,0,0) translate(-40,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="166" height="18" fill-opacity="0"/></g></g><g transform="translate(40,0) matrix(1,0,0,1,0,0) translate(-40,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="166" height="14" fill-opacity="0"/></g></g><g transform="translate(40,0) matrix(1,0,0,1,0,0) translate(-40,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="40" y="0" width="86" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="40" y="11">Identity</text><rect fill="rgb(0, 0, 0)" stroke="none" x="40" y="12" width="38" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="78" y="12" width="0" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="78" y="12" width="4" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="82" y="12" width="0" height="1"/><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="82" y="11">Provider</text><rect fill="rgb(0, 0, 0)" stroke="none" x="82" y="12" width="44" height="1"/></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,204,24)"><g><g transform="translate(0,0) scale(1.69,4.7299999999999995)"><g><g transform="scale(0.591715976331361,0.21141649048625794)"><path fill="#000000" stroke="none" d="M 84.5 0 L 84.5 472.99999999999994"/><path fill="none" stroke="#000000" d="M 84.5 0 M 84.5 0 L 84.5 4.999999999999999 M 84.5 4.999999999999999 M 84.5 6.999999999999999 L 84.5 12 M 84.5 12 M 84.5 14 L 84.5 19 M 84.5 19 M 84.5 21 L 84.5 26 M 84.5 26 M 84.5 28 L 84.5 33 M 84.5 33 M 84.5 35 L 84.5 40 M 84.5 40 M 84.5 42 L 84.5 47 M 84.5 47 M 84.5 49 L 84.5 54 M 84.5 54 M 84.5 56 L 84.5 61 M 84.5 61 M 84.5 63 L 84.5 68 M 84.5 68 M 84.5 70 L 84.5 75 M 84.5 75 M 84.5 77 L 84.5 82 M 84.5 82 M 84.5 84 L 84.5 89 M 84.5 89 M 84.5 91 L 84.5 96 M 84.5 96 M 84.5 98 L 84.5 103 M 84.5 103 M 84.5 105 L 84.5 110 M 84.5 110 M 84.5 112 L 84.5 117 M 84.5 117 M 84.5 119 L 84.5 124 M 84.5 124 M 84.5 126 L 84.5 131 M 84.5 131 M 84.5 133 L 84.5 138 M 84.5 138 M 84.5 140 L 84.5 145 M 84.5 145 M 84.5 147 L 84.5 152 M 84.5 152 M 84.5 154 L 84.5 159 M 84.5 159 M 84.5 161 L 84.5 166 M 84.5 166 M 84.5 168 L 84.5 173 M 84.5 173 M 84.5 175 L 84.5 180 M 84.5 180 M 84.5 182 L 84.5 187 M 84.5 187 M 84.5 189 L 84.5 194 M 84.5 194 M 84.5 196 L 84.5 201 M 84.5 201 M 84.5 203 L 84.5 208 M 84.5 208 M 84.5 210 L 84.5 215 M 84.5 215 M 84.5 217 L 84.5 222 M 84.5 222 M 84.5 224 L 84.5 229 M 84.5 229 M 84.5 231 L 84.5 236 M 84.5 236 M 84.5 238 L 84.5 243 M 84.5 243 M 84.5 245 L 84.5 250 M 84.5 250 M 84.5 252 L 84.5 257 M 84.5 257 M 84.5 259 L 84.5 264 M 84.5 264 M 84.5 266 L 84.5 271 M 84.5 271 M 84.5 273 L 84.5 278 M 84.5 278 M 84.5 280 L 84.5 285 M 84.5 285 M 84.5 287 L 84.5 292 M 84.5 292 M 84.5 294 L 84.5 299 M 84.5 299 M 84.5 301 L 84.5 306 M 84.5 306 M 84.5 308 L 84.5 313 M 84.5 313 M 84.5 315 L 84.5 320 M 84.5 320 M 84.5 322 L 84.5 327 M 84.5 327 M 84.5 329 L 84.5 334 M 84.5 334 M 84.5 336 L 84.5 341 M 84.5 341 M 84.5 343 L 84.5 348 M 84.5 348 M 84.5 350 L 84.5 355 M 84.5 355 M 84.5 357 L 84.5 362 M 84.5 362 M 84.5 364 L 84.5 369 M 84.5 369 M 84.5 371 L 84.5 376 M 84.5 376 M 84.5 378 L 84.5 383 M 84.5 383 M 84.5 385 L 84.5 390 M 84.5 390 M 84.5 392 L 84.5 397 M 84.5 397 M 84.5 399 L 84.5 404 M 84.5 404 M 84.5 406 L 84.5 411 M 84.5 411 M 84.5 413 L 84.5 418 M 84.5 418 M 84.5 420 L 84.5 425 M 84.5 425 M 84.5 427 L 84.5 432 M 84.5 432 M 84.5 434 L 84.5 439 M 84.5 439 M 84.5 441 L 84.5 446 M 84.5 446 M 84.5 448 L 84.5 453 M 84.5 453 M 84.5 455 L 84.5 460 M 84.5 460 M 84.5 462 L 84.5 467 M 84.5 467 M 84.5 469 L 84.5 472.99999999999994" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,620,6)"><g><g transform="translate(0,0) scale(1.2,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.8333333333333334,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,620,24)"><g><g transform="translate(0,0) scale(1.2,4.7299999999999995)"><g><g transform="scale(0.8333333333333334,0.21141649048625794)"><path fill="#000000" stroke="none" d="M 60 0 L 60 472.99999999999994"/><path fill="none" stroke="#000000" d="M 60 0 M 60 0 L 60 4.999999999999999 M 60 4.999999999999999 M 60 6.999999999999999 L 60 12 M 60 12 M 60 14 L 60 19 M 60 19 M 60 21 L 60 26 M 60 26 M 60 28 L 60 33 M 60 33 M 60 35 L 60 40 M 60 40 M 60 42 L 60 47 M 60 47 M 60 49 L 60 54 M 60 54 M 60 56 L 60 61 M 60 61 M 60 63 L 60 68 M 60 68 M 60 70 L 60 75 M 60 75 M 60 77 L 60 82 M 60 82 M 60 84 L 60 89 M 60 89 M 60 91 L 60 96 M 60 96 M 60 98 L 60 103 M 60 103 M 60 105 L 60 110 M 60 110 M 60 112 L 60 117 M 60 117 M 60 119 L 60 124 M 60 124 M 60 126 L 60 131 M 60 131 M 60 133 L 60 138 M 60 138 M 60 140 L 60 145 M 60 145 M 60 147 L 60 152 M 60 152 M 60 154 L 60 159 M 60 159 M 60 161 L 60 166 M 60 166 M 60 168 L 60 173 M 60 173 M 60 175 L 60 180 M 60 180 M 60 182 L 60 187 M 60 187 M 60 189 L 60 194 M 60 194 M 60 196 L 60 201 M 60 201 M 60 203 L 60 208 M 60 208 M 60 210 L 60 215 M 60 215 M 60 217 L 60 222 M 60 222 M 60 224 L 60 229 M 60 229 M 60 231 L 60 236 M 60 236 M 60 238 L 60 243 M 60 243 M 60 245 L 60 250 M 60 250 M 60 252 L 60 257 M 60 257 M 60 259 L 60 264 M 60 264 M 60 266 L 60 271 M 60 271 M 60 273 L 60 278 M 60 278 M 60 280 L 60 285 M 60 285 M 60 287 L 60 292 M 60 292 M 60 294 L 60 299 M 60 299 M 60 301 L 60 306 M 60 306 M 60 308 L 60 313 M 60 313 M 60 315 L 60 320 M 60 320 M 60 322 L 60 327 M 60 327 M 60 329 L 60 334 M 60 334 M 60 336 L 60 341 M 60 341 M 60 343 L 60 348 M 60 348 M 60 350 L 60 355 M 60 355 M 60 357 L 60 362 M 60 362 M 60 364 L 60 369 M 60 369 M 60 371 L 60 376 M 60 376 M 60 378 L 60 383 M 60 383 M 60 385 L 60 390 M 60 390 M 60 392 L 60 397 M 60 397 M 60 399 L 60 404 M 60 404 M 60 406 L 60 411 M 60 411 M 60 413 L 60 418 M 60 418 M 60 420 L 60 425 M 60 425 M 60 427 L 60 432 M 60 432 M 60 434 L 60 439 M 60 439 M 60 441 L 60 446 M 60 446 M 60 448 L 60 453 M 60 453 M 60 455 L 60 460 M 60 460 M 60 462 L 60 467 M 60 467 M 60 469 L 60 472.99999999999994" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,622,8)"><g transform="translate(38,0) matrix(1,0,0,1,0,0) translate(-38,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="18" fill-opacity="0"/></g></g><g transform="translate(38,0) matrix(1,0,0,1,0,0) translate(-38,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="14" fill-opacity="0"/></g></g><g transform="translate(38,0) matrix(1,0,0,1,0,0) translate(-38,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="38" y="0" width="41" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="38" y="11">Kubectl</text><rect fill="rgb(0, 0, 0)" stroke="none" x="38" y="12" width="41" height="1"/></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,15,6)"><g><g transform="translate(0,0) scale(1.2,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.8333333333333334,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,15,24)"><g><g transform="translate(0,0) scale(1.2,4.73)"><g><g transform="scale(0.8333333333333334,0.2114164904862579)"><path fill="#000000" stroke="none" d="M 60 0 L 60 473.00000000000006"/><path fill="none" stroke="#000000" d="M 60 0 M 60 0 L 60 5 M 60 5 M 60 7 L 60 12 M 60 12 M 60 14 L 60 19 M 60 19 M 60 21 L 60 26 M 60 26 M 60 28 L 60 33 M 60 33 M 60 35 L 60 40 M 60 40 M 60 42 L 60 47 M 60 47 M 60 49 L 60 54 M 60 54 M 60 56 L 60 61 M 60 61 M 60 63 L 60 68 M 60 68 M 60 70 L 60 75 M 60 75 M 60 77 L 60 82 M 60 82 M 60 84 L 60 89 M 60 89 M 60 91 L 60 96 M 60 96 M 60 98 L 60 103 M 60 103 M 60 105 L 60 110 M 60 110 M 60 112 L 60 117 M 60 117 M 60 119 L 60 124 M 60 124 M 60 126 L 60 131 M 60 131 M 60 133 L 60 138 M 60 138 M 60 140 L 60 145 M 60 145 M 60 147 L 60 152 M 60 152 M 60 154 L 60 159 M 60 159 M 60 161 L 60 166 M 60 166 M 60 168 L 60 173 M 60 173 M 60 175 L 60 180 M 60 180 M 60 182 L 60 187 M 60 187 M 60 189 L 60 194 M 60 194 M 60 196 L 60 201 M 60 201 M 60 203 L 60 208 M 60 208 M 60 210 L 60 215 M 60 215 M 60 217 L 60 222 M 60 222 M 60 224 L 60 229 M 60 229 M 60 231 L 60 236 M 60 236 M 60 238 L 60 243 M 60 243 M 60 245 L 60 250 M 60 250 M 60 252 L 60 257 M 60 257 M 60 259 L 60 264 M 60 264 M 60 266 L 60 271 M 60 271 M 60 273 L 60 278 M 60 278 M 60 280 L 60 285 M 60 285 M 60 287 L 60 292 M 60 292 M 60 294 L 60 299 M 60 299 M 60 301 L 60 306 M 60 306 M 60 308 L 60 313 M 60 313 M 60 315 L 60 320 M 60 320 M 60 322 L 60 327 M 60 327 M 60 329 L 60 334 M 60 334 M 60 336 L 60 341 M 60 341 M 60 343 L 60 348 M 60 348 M 60 350 L 60 355 M 60 355 M 60 357 L 60 362 M 60 362 M 60 364 L 60 369 M 60 369 M 60 371 L 60 376 M 60 376 M 60 378 L 60 383 M 60 383 M 60 385 L 60 390 M 60 390 M 60 392 L 60 397 M 60 397 M 60 399 L 60 404 M 60 404 M 60 406 L 60 411 M 60 411 M 60 413 L 60 418 M 60 418 M 60 420 L 60 425 M 60 425 M 60 427 L 60 432 M 60 432 M 60 434 L 60 439 M 60 439 M 60 441 L 60 446 M 60 446 M 60 448 L 60 453 M 60 453 M 60 455 L 60 460 M 60 460 M 60 462 L 60 467 M 60 467 M 60 469 L 60 473.00000000000006" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,17,8)"><g transform="translate(46,0) matrix(1,0,0,1,0,0) translate(-46,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="18" fill-opacity="0"/></g></g><g transform="translate(46,0) matrix(1,0,0,1,0,0) translate(-46,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="14" fill-opacity="0"/></g></g><g transform="translate(46,0) matrix(1,0,0,1,0,0) translate(-46,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="46" y="0" width="25" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="46" y="11">User</text><rect fill="rgb(0, 0, 0)" stroke="none" x="46" y="12" width="25" height="1"/></g></g><g transform="matrix(1,0,0,1,70.96667078087722,46)"><image width="228" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOQAAAAoCAYAAADufVZCAAABvklEQVR4Xu3bwU3DUBBF0QmNhY6gAkIHQAfQWegAaAD0kZGiKOz8oxnPiZQFLL7f3DdXMQZ24YUAAmkI7NIkEQQBBIKQlgCBRAQImagMURAgpB1AIBEBQiYqQxQECGkHEEhEgJCJyhAFAULaAQQSESBkojJEQYCQdgCBRAQImagMURAgpB1AIBEBQiYqQxQECGkHEEhEgJCJyhAlHYHbiDgu76uEI+RVMLtIUQKPEXEXEc8R8RIRH7PnIORsws6vTGAIeVgG+IyIp9liErLyusg+m8CpkN8Rv/8/PG5hx/ffZlz8XMjx9cOMCzkTgYIExs+Q433pNUXMcyFvCFlwbUSeRWDIuP/n8Pflk/J1zYu7ZV2TprO2RuDSLesUEf/AEXJrK2SeNQmcCvm1PNQZT1ynPW0l5Jr1OWtrBIaQ98uvPaaK6BNya6tjnhkE/GHADKrORKAKAbesVZqSswUBQrao2ZBVCBCySlNytiBAyBY1G7IKAUJWaUrOFgQI2aJmQ1YhQMgqTcnZggAhW9RsyCoECFmlKTlbECBki5oNWYUAIas0JWcLAoRsUbMhqxAgZJWm5GxBgJAtajZkFQI/YJsgKUEAfKYAAAAASUVORK5CYII=" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,133,39)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 87 0 L 87 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="87" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 87 0 L 87 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="87" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 84 0 L 84 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="81" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 84 0 L 84 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="81" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">1</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="20" y="11">Login</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="53" y="11">to</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="66" y="11">IdP</text></g></g><g transform="matrix(1,0,0,1,64.5,77)"><image width="232" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOgAAAAoCAYAAAD0QbbMAAAB9UlEQVR4Xu3bXUrccBiF8WO7ALuDurTuQLuCtjtwL4KXot6K0A31gz8YEXGcgSHJCf4CIReTIWee9zyTj2FOYkEAgVoCJ7XJBEMAgRBUCRAoJkDQ4uGIhgBBdQCBYgIELR6OaAgQVAcQKCZA0OLhiIYAQXUAgWICBC0ejmgIEFQHECgmQNDi4YiGAEF1AIFiAgQtHo5oCBBUBxAoJrC0oGdJxnpbzEQ0BGoILCXokPJHkm9JfiX5WUNAEASKCcwt6Jck50m+Jzl94kDQ4kJsNNqnJGP9vGP73muv37P2vvdJ7qY5zCnoxdOZcoj5L3n+7+kWBd364Ncu3T6BjpXkb5Kx/tmxfe+11+9Ze9+bl7eAcwg6LmPH5ey4rH1reUjyuPA33jEFHYy2Pvi1S7dPoGMl2eiJf3/suQQd95hfdxz+OsnVwt94xxR0nP0tCKxCYA5Bpw8yzqRvibrFS9xVhuOgCMwp6C5RCap3CBxIYAlBpyjTQ6NLP7McOB27fXgCSwo6YI+fXcbDo98fnjwACBxAYGlBD4hkFwQQmAgQVBcQKCZA0OLhiIYAQXUAgWICBC0ejmgIEFQHECgmQNDi4YiGAEF1AIFiAgQtHo5oCBBUBxAoJkDQ4uGIhgBBdQCBYgIELR6OaAgQVAcQKCZA0OLhiIbAf4Mp3SmbG3nMAAAAAElFTkSuQmCC" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,95,82)"><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 0 0 L 183 0 L 183 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="183" height="28" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 0 0 L 183 0 L 183 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="183" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 3 0 L 180 0 L 180 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="177" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 3 0 L 180 0 L 180 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="177" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">2</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Provide</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="60" y="11">access_token</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="128" y="11">,</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="135" y="11">id_token</text></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 0 14 L 183 14 L 183 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="14" width="183" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 43 14 L 140 14 L 140 28 L 43 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="43" y="14" width="97" height="14" fill-opacity="0"/></g></g><g transform="translate(92,42) matrix(1,0,0,1,0,0) translate(-92,-42)"><path fill="none" stroke="none" d="M 43 14 L 140 14 L 140 28 L 43 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="43" y="14" width="97" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="43" y="25">and</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="66" y="25">refresh_token</text></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,279,66)"><g><g transform="translate(0,0) scale(0.19,0.31)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,3.2258064516129035)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,65.5,97)"><g><g transform="translate(0,0) scale(0.19,0.42)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,2.380952380952381)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 42 Q 19 42 19 42 L 0 42 Q 0 42 0 42 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 42 Q 19 42 19 42 L 0 42 Q 0 42 0 42 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,870.5,6)"><g><g transform="translate(0,0) scale(1.2,0.18)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(0.8333333333333334,5.555555555555555)"><path fill="none" stroke="none" d="M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 120 0 Q 120 0 120 0 L 120 18 Q 120 18 120 18 L 0 18 Q 0 18 0 18 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,870.5,24)"><g><g transform="translate(0,0) scale(1.2,4.7299999999999995)"><g><g transform="scale(0.8333333333333334,0.21141649048625794)"><path fill="#000000" stroke="none" d="M 60 0 L 60 472.99999999999994"/><path fill="none" stroke="#000000" d="M 60 0 M 60 0 L 60 4.999999999999999 M 60 4.999999999999999 M 60 6.999999999999999 L 60 12 M 60 12 M 60 14 L 60 19 M 60 19 M 60 21 L 60 26 M 60 26 M 60 28 L 60 33 M 60 33 M 60 35 L 60 40 M 60 40 M 60 42 L 60 47 M 60 47 M 60 49 L 60 54 M 60 54 M 60 56 L 60 61 M 60 61 M 60 63 L 60 68 M 60 68 M 60 70 L 60 75 M 60 75 M 60 77 L 60 82 M 60 82 M 60 84 L 60 89 M 60 89 M 60 91 L 60 96 M 60 96 M 60 98 L 60 103 M 60 103 M 60 105 L 60 110 M 60 110 M 60 112 L 60 117 M 60 117 M 60 119 L 60 124 M 60 124 M 60 126 L 60 131 M 60 131 M 60 133 L 60 138 M 60 138 M 60 140 L 60 145 M 60 145 M 60 147 L 60 152 M 60 152 M 60 154 L 60 159 M 60 159 M 60 161 L 60 166 M 60 166 M 60 168 L 60 173 M 60 173 M 60 175 L 60 180 M 60 180 M 60 182 L 60 187 M 60 187 M 60 189 L 60 194 M 60 194 M 60 196 L 60 201 M 60 201 M 60 203 L 60 208 M 60 208 M 60 210 L 60 215 M 60 215 M 60 217 L 60 222 M 60 222 M 60 224 L 60 229 M 60 229 M 60 231 L 60 236 M 60 236 M 60 238 L 60 243 M 60 243 M 60 245 L 60 250 M 60 250 M 60 252 L 60 257 M 60 257 M 60 259 L 60 264 M 60 264 M 60 266 L 60 271 M 60 271 M 60 273 L 60 278 M 60 278 M 60 280 L 60 285 M 60 285 M 60 287 L 60 292 M 60 292 M 60 294 L 60 299 M 60 299 M 60 301 L 60 306 M 60 306 M 60 308 L 60 313 M 60 313 M 60 315 L 60 320 M 60 320 M 60 322 L 60 327 M 60 327 M 60 329 L 60 334 M 60 334 M 60 336 L 60 341 M 60 341 M 60 343 L 60 348 M 60 348 M 60 350 L 60 355 M 60 355 M 60 357 L 60 362 M 60 362 M 60 364 L 60 369 M 60 369 M 60 371 L 60 376 M 60 376 M 60 378 L 60 383 M 60 383 M 60 385 L 60 390 M 60 390 M 60 392 L 60 397 M 60 397 M 60 399 L 60 404 M 60 404 M 60 406 L 60 411 M 60 411 M 60 413 L 60 418 M 60 418 M 60 420 L 60 425 M 60 425 M 60 427 L 60 432 M 60 432 M 60 434 L 60 439 M 60 439 M 60 441 L 60 446 M 60 446 M 60 448 L 60 453 M 60 453 M 60 455 L 60 460 M 60 460 M 60 462 L 60 467 M 60 467 M 60 469 L 60 472.99999999999994" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,873,8)"><g transform="translate(29,0) matrix(1,0,0,1,0,0) translate(-29,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="18" fill-opacity="0"/></g></g><g transform="translate(29,0) matrix(1,0,0,1,0,0) translate(-29,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="117" height="14" fill-opacity="0"/></g></g><g transform="translate(29,0) matrix(1,0,0,1,0,0) translate(-29,0)"><g><rect fill="rgb(0,0,0)" stroke="none" x="29" y="0" width="59" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="30" y="11">API</text><rect fill="rgb(0, 0, 0)" stroke="none" x="30" y="12" width="19" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="49" y="12" width="0" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="49" y="12" width="3" height="1"/><rect fill="rgb(0, 0, 0)" stroke="none" x="52" y="12" width="0" height="1"/><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="52" y="11">Server</text><rect fill="rgb(0, 0, 0)" stroke="none" x="52" y="12" width="36" height="1"/></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,670.5,139)"><g><g transform="translate(0,0) scale(0.19,0.31)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,3.2258064516129035)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 31 Q 19 31 19 31 L 0 31 Q 0 31 0 31 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,80.5,119)"><image width="610" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAmIAAAAoCAYAAABdCpbFAAAC4ElEQVR4Xu3cwU3DQBBA0UlHdAAdQQdABUAH0BElQAdAA6CVHImDuYxmPbZ4kbgg7Y7zsoevOMkpPAgQIECAAAECBFoETi1TDSVAgAABAgQIEAgh5hAQIECAAAECBJoEhFgTvLEECBAgQIAAASHmDBAgQIAAAQIEmgSEWBO8sQQIECBAgAABIeYMECBAgAABAgSaBIRYE7yxBAgQIECAAAEh5gwQIECAAAECBJoEhFgTvLEECBAgQIAAASHmDBAgQIAAAQIEmgSEWBO8sQQIECBAgAABIeYMECBAgAABAgSaBIRYE7yxBAgQIECAAAEh5gwQIECAAAECBJoEhFgTvLEECBAgQIDA7gSuIuI1Ij62ujIhtpW0OQQIECBAgMDeBe4i4joiHiPiaYsgE2J7PxKujwABAgQIENhKYITY7TLsMyIeIuJ+5nAhNlPX3gQIECBAgMCRBH6H2HdEjE56i4jx/5cZT2QtxM4lOGOePQkQIECAAAECexUYnxEbf2uPKUG2FmKj+jwIECBAgAABAv9NYETY5R9P+n15Z+y5EsWtyUpNexEgQIAAAQJHFli7NTklwM5IQuzIx8W1EyBAgAABApUCv0Psa/mw/tQ7hUKs8uWzFwECBAgQIHBkgRFdN8vPV4yfsJj+e2JC7MjHxbUTIECAAAEClQIXy7ckpweYW5OVL5u9CBAgQIAAAQIJAe+IJdAsIUCAAAECBAhUCAixCkV7ECBAgAABAgQSAkIsgWYJAQIECBAgQKBCQIhVKNqDAAECBAgQIJAQEGIJNEsIECBAgAABAhUCQqxC0R4ECBAgQIAAgYSAEEugWUKAAAECBAgQqBAQYhWK9iBAgAABAgQIJASEWALNEgIECBAgQIBAhYAQq1C0BwECBAgQIEAgISDEEmiWECBAgAABAgQqBIRYhaI9CBAgQIAAAQIJASGWQLOEAAECBAgQIFAhIMQqFO1BgAABAgQIEEgI/AATdB4pebrH5AAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,292,145)"><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 0 0 L 296 0 L 296 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="296" height="28" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 0 0 L 296 0 L 296 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="296" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 3 0 L 293 0 L 293 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="290" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 3 0 L 293 0 L 293 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="290" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">3</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="20" y="11">Call</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="44" y="11">kubectl</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="85" y="11">with</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="106" y="11"> --</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="118" y="11">token</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="150" y="11">being</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="183" y="11">the</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="203" y="11">id_token</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="252" y="11">OR</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="273" y="11">add</text></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 0 14 L 296 14 L 296 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="14" width="296" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 84 14 L 212 14 L 212 28 L 84 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="84" y="14" width="128" height="14" fill-opacity="0"/></g></g><g transform="translate(174,42) matrix(1,0,0,1,0,0) translate(-174,-42)"><path fill="none" stroke="none" d="M 84 14 L 212 14 L 212 28 L 84 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="84" y="14" width="128" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="84" y="25">tokens</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="122" y="25">to</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="132" y="25"> .</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="139" y="25">kubectl</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="177" y="25">/</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="180" y="25">config</text></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,921,170)"><g><g transform="translate(0,0) scale(0.19,2.3100000000000005)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,0.4329004329004328)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 231.00000000000006 Q 19 231.00000000000006 19 231.00000000000006 L 0 231.00000000000006 Q 0 231.00000000000006 0 231.00000000000006 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 231.00000000000006 Q 19 231.00000000000006 19 231.00000000000006 L 0 231.00000000000006 Q 0 231.00000000000006 0 231.00000000000006 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,685.5,150)"><image width="255" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAP8AAAAoCAYAAAAxMyxdAAABz0lEQVR4Xu3YwU3DQBAF0ElnlEApUAHQCXRACdABJaQT0EoJyiFyxo4dwczzJZfdtefN/njlXbgIEGgpsGtZtaIJEAjhtwkINBUQ/qaNVzYB4bcHCDQVEP6mjVc2AeG3Bwg0FRD+po1XNgHhtwcINBUQ/qaNVzYB4bcHCDQVEP6mjVc2AeG3Bwg0FRD+po1XNgHhtwcINBUQ/qaNV/afFLiPiPdbPZnw30rafQhcFviOiI+IeDn8Xp5xxQjhvwLPVAIrC4zwH6/xJ/AYEV8r3+N3OeHfSta6BOYLnIb/OPv1cBLYz19uesa58D+tfRPrESCQEnieGLX6n8C58E89QKoCgwgQWCQw9eJ9i4iRzdVOAI79i3pkEoFNBM4d+1cP/fHJhX+THlqUwCKB0/B/RsSDD36LHE0i8O8ERvhH6Mfxfnzt3/Ty5t+U1+IEZgnc3SL0jv2zemIwgXoC3vz1eqoiAikB4U8xGUSgnoDw1+upigikBIQ/xWQQgXoCwl+vpyoikBIQ/hSTQQTqCQh/vZ6qiEBKQPhTTAYRqCcg/PV6qiICKQHhTzEZRKCegPDX66mKCKQEhD/FZBCBegLCX6+nKiKQEhD+FJNBBOoJ/AAsrxophGreZAAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,725,183)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">4</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="19" y="11">Authorization</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="89" y="11">:</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="96" y="11">Bearer</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="132" y="11">...</text></g></g><g transform="translate(0.5,0.5) matrix(1,0,0,1,670.5,401)"><g><g transform="translate(0,0) scale(0.19,0.34)"><g><path fill="#FFFFFF" stroke="none" d="M 0 0 L 100 0 Q 100 0 100 0 L 100 100 Q 100 100 100 100 L 0 100 Q 0 100 0 100 L 0 0 Q 0 0 0 0 Z"/><g transform="scale(5.2631578947368425,2.941176470588235)"><path fill="none" stroke="none" d="M 0 0 L 19 0 Q 19 0 19 0 L 19 34 Q 19 34 19 34 L 0 34 Q 0 34 0 34 L 0 0 Q 0 0 0 0 Z"/><path fill="none" stroke="#000000" d="M 0 0 M 0 0 L 19 0 Q 19 0 19 0 L 19 34 Q 19 34 19 34 L 0 34 Q 0 34 0 34 L 0 0 Q 0 0 0 0 Z" stroke-miterlimit="10"/></g></g></g></g></g><g transform="matrix(1,0,0,1,669.5,381)"><image width="255" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAP8AAAAoCAYAAAAxMyxdAAABz0lEQVR4Xu3c0U0CURAF0EsDYgdagiXRgVqB2gF2pJVpXuIaTfRzh0nmkPD9Zs7MhWUhHOJBgMBIgcPIrjVNgECE3xIQGCog/EMHr20Cwm8HCAwVEP6hg9c2AeG3AwSGCgj/0MFrm4Dw2wECQwWEf+jgtU1A+O0AgaECwj908NomIPx2gMBQAeEfOnhtExB+O0BgqEB1+K+T3CV5G+qtbQJtBKrCv0J/n+QhyWuS5zYCCiEwVKAi/CvoK/THL+MX4R+6bdpuJbBn+E9JnpLcJvlIvv87QPhbrYBipgrsEf6fof/LdX3e95l/6sbp+5ICK3fvWwF7hX9d6t/80+U6XPgvuQLOnirw6413j/BvsOsKYHsRcNk/dd303VZgz/BvTa8XgMckV274td0DhQ0UqAj/Yl1f9a07/ut5drd/4KZpuZ1AVfi3xv3Ip90KKGiqQHX4pzrrm0A7AeFvNxIFEagREP4aZ6cQaCcg/O1GoiACNQLCX+PsFALtBIS/3UgURKBGQPhrnJ1CoJ2A8LcbiYII1AgIf42zUwi0ExD+diNREIEaAeGvcXYKgXYCwt9uJAoiUCMg/DXOTiHQTkD4241EQQRqBIS/xtkpBNoJfAJChRgp4jU/qgAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,746,387)"><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 0 0 L 131 0 L 131 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="131" height="28" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 0 0 L 131 0 L 131 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="131" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 3 0 L 128 0 L 128 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="125" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 3 0 L 128 0 L 128 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="125" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">8</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="19" y="11">Authorized</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="77" y="11"> :</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="87" y="11">perform</text></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 0 14 L 131 14 L 131 28 L 0 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="14" width="131" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 4 14 L 127 14 L 127 28 L 4 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="4" y="14" width="123" height="14" fill-opacity="0"/></g></g><g transform="translate(14,42) matrix(1,0,0,1,0,0) translate(-14,-42)"><path fill="none" stroke="none" d="M 4 14 L 127 14 L 127 28 L 4 28 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="4" y="14" width="123" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="4" y="25">action</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="39" y="25">and</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="63" y="25">return</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="98" y="25">result</text></g></g><g transform="translate(0,0) matrix(1,0,0,1,59,418)"><g><g clip-path="url(#sWsmWLPNlqtt)"><g transform="translate(0,0) scale(0.31683168316831684,0.31683168316831684)"><g><g><path fill="rgb(0,0,0)" stroke="#000000" d="M 0 100 L 100 0" fill-opacity="0" stroke-linecap="round" stroke-miterlimit="10" stroke-width="5"/></g><g><path fill="rgb(0,0,0)" stroke="#000000" d="M 100 100 L 0 0" fill-opacity="0" stroke-linecap="round" stroke-miterlimit="10" stroke-width="5"/></g></g></g></g></g></g><g transform="matrix(1,0,0,1,71,414)"><image width="603" height="40" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAlsAAAAoCAYAAADJ7D83AAADOElEQVR4Xu3cjW3TUBQF4NMFgA1gBTZiA2ACYAMYCPE3AGwEemCjUDVSSnysV/mzFCVS7OvrL1fNcZz0JhYCBAgQIECAAIGawE2tssIECBAgQIAAAQIRtgwBAQIECBAgQKAoIGwVcZUmQIAAAQIECAhbZoAAAQIECBAgUBQQtoq4ShMgQIAAAQIEhC0zQIAAAQIECBAoCghbRVylCRAgQIAAAQLClhkgQIAAAQIECBQFhK0irtIECBAgQIAAAWHLDBAgQIAAAQIEigLCVhFXaQIECBAgQICAsGUGCBAgQIAAAQJFAWGriKs0AQIECBAgQEDYMgMECBAgQIAAgaLA3mHrSZJnSX4Uj0lpAgQIECBAgMA0AnuFrRGyXiZ5leRDkrfTCGiEAAECBAgQIFAU2CNsjWA1Qtbj5TjeCVvFV1RpAgQIECBAYCqBZth6keTNctnwZ5J1X8LWVCOgGQIECBAgQKAp0AhbpyHrrt4/Jfm4PDFC2Lqsj8/dj/WuWefa7Y/Y6yxms/RxyQzM0uvR+2j+3VSbAAEC9xJoha1x6fDpmU6+Jvm2PHe6//XxufuxyTXrXLv9EXudxWyWPi6ZgVl6PXIf35M8v3VCd0lQ3nOdo4fh/zmpZvZnqPec0632dcTX7nOScfu9NMLWWnt8wrWGLpcR75WBrUyAwEYCt0/QjhxC7zr2WTycyPz7nvyQPB5Sr3vO+whaX/YIW2Mf41eI48vxr5M8WnbqO1sbvYsoQ4AAAQIECMwv0Pxk6/To19A1gtd7v0acfzB0SIAAAQIECGwjsFfYWrsd/9B03P5ex9zmMFQhQIAAAQIECMwpsHfYmlNBVwQIECBAgACBkoCwVYJVlgABAgQIECAwBIQtc0CAAAECBAgQKAoIW0VcpQkQIECAAAECwpYZIECAAAECBAgUBYStIq7SBAgQIECAAAFhywwQIECAAAECBIoCwlYRV2kCBAgQIECAgLBlBggQIECAAAECRQFhq4irNAECBAgQIEBA2DIDBAgQIECAAIGigLBVxFWaAAECBAgQICBsmQECBAgQIECAQFFA2CriKk2AAAECBAgQELbMAAECBAgQIECgKPALDx4TOEqFdvMAAAAASUVORK5CYII=" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,320,407)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 88 0 L 88 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="88" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 88 0 L 88 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="88" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 85 0 L 85 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="82" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 85 0 L 85 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="82" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">9</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Return</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="56" y="11">result</text></g></g><g transform="matrix(1,0,0,1,920,250)"><image width="64" height="97" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABhCAYAAABmmadNAAAEBUlEQVR4Xu2ct6sVQRSHv2dAUAyNtgYQCzGCuVARFbQwI4JgKA2o2BhQjIgWRhQEY6H/gWLOKKbSQkUbCwsbFQuz8pNZWW94u/fu3eudOTuwcHl377z5fXN2dmbOOdOG8dJmXD8FgBwsYAPwHvjgrtLPn3L4n3VXmYcF7AF6AT3dVfq5K3AF+A48BB65S6CaXvIAkCSigwM0HhgDjHbXuxiM+8CTpIoa8f3/AFCt3QNjMGQ9Q4FjwIlGCK1WRysBKG3jCGAFsMSBEIwXjYbRygAirZ0dCMF4A+wFrjYKhA8A4lqnAHOAX8DqRkDwDUCkeRWwDpgBPM8CwlcA0jwAuAgcBw7UC8FnAJHm/cAQYGo9EEIAIN3LgAXukaiJQygAJHoesAiYXwuBkABIt9YhmkRtTAshNADSfQq4C5xOAyFEANItALKCe0kQQgUg3U+BscC39iCEDGCbmzFutwpAnfsD0PK7agnZAiR6h3sEdvq4HE4av9J8r97XGNDRKgDpVu9/AXZVghD6IyDNsgLtH2gpXVYsAJDo28AW4E4pASsAqr4SrQCYCGg+MMmqBUj3T/c20Hba32LFAiT4OrAbuGEVgAZB7TBvtQpgHKDBcLpVAL2BZ0AfqwAqTostDYLqeHmg+zq3/R9DsAbglds+fx09BtYAKBZhJfDYKoBLzot02SqAc8AF4LxVAIeBl8ARqwDWOOGHrAIwbwHmxwDzbwHz8wDzM0HTawE5R+Qf6GR1OWx+P0CxydoRmmbVAszvCWo3WH7Cm1YtQP6Asv0PKxsi5j1D5n2Dpr3DesyvWY4PMB0hUnH6a+k12G7vh+4YSYwQCx1AYoxgyAA08isrdYLVWGFlnq4HHpQHxv37lxCnwmfcgudskvgQH4FNQDdgcxrxoQFQrtBClzyVVn8w8QHLXbKUEilrKiGMAUqaHFy61ZWWgs8AlG4vV7eyyg+mFVx6n68A5OVVpMdM5+6uV3/TxwAdp5HlqAzt6M4FPgNr61Yd+2EzLWC2C0/pX2PDu7jzA9Tjcm3tc2GvNVZT+fZmAFCvK4lRAFQmA7dStH6kE77YPedHHYAUP01/S94AJFozM6WzRqUagEHAKHeOSPfYGSIn08up/c68APRz5h71erxlyvJW5oY8NTpBJhL91oWvyYWtOby3p8hocNIubLzX4wCUy6cwta/u2BzF7En0x9r7L/sv8rAAZWUIwqwqzVPmhgC1RMkDQCRMj4FA6HCDHjG1WqUtbQn1TYwVlmDBGOYyuMpyd/4XkDwtoJImCR+eZeraaFDNBtDo9meurwCQGaHnFRQW4HkHZm5+YQGZEXpeQWEBnndg5uYXFpAZoecVFBbgeQdmbn5hAZkRel6BeQv4DVQMomImLlfUAAAAAElFTkSuQmCC" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,902,274)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 195 0 L 195 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="195" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 195 0 L 195 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="195" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 192 0 L 192 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="189" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 192 0 L 192 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="189" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">6</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Has</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="41" y="11">the</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="61" y="11">JWT</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="89" y="11">expired</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="128" y="11">?</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="138" y="11">(</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="142" y="11">iat</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="155" y="11"> +</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="169" y="11">exp</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="188" y="11">)</text></g></g><g transform="matrix(1,0,0,1,920,325)"><image width="64" height="96" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABgCAYAAACtxXToAAADV0lEQVR4Xu2cy6tNURzHP9eMvOfKjEjIKyH8ASJCjLylKMXAY4CRR4mZEiGJkldGjLyVx5Ay9cgjijJD9NXat9259zjn7Hv2tvb+7lW7czr3nrPX97O+e+211/r9Vg/mpcdcPzWAHBywC/gKfAtH4/vvOZwz80/m4YCDwEhgRDga3w8BbgO/gKfAk/D6ObOKAXwxDwCtqjMoAJoNzABmhlc5Q0B0PAIetvqhbvz9fwBoVu+xAYSgjALmAifC8aMbYvv7jZgANNZvPLAlHOcDiGfdBhEzgLTWdQGEPjsEXOkWiLIASPROB5YDY4DV3YBQNgCJ5lXASWARcGcgIMoKQJqHAjeB58DOrBDKDCDRvAPYBIzLAqEKAKRbfYMGV6M7hVAVAAkEjRs0jmi7VAmARK8AlgEr2yVQNQDSvRsYBuxpB0IVAUj3KeAxcLoVhKoCkO5XwALg/b8gVBmAbo3TgM2uAKT7LTALeNcMQpUdIM3rAc07bHAFIN2vgTnAm/4gVN0B0rwGmA+sdQUg3feBJcCXRggODpBmTaBcAK66Atganha3uQKYAFwGJroCkO6PwCTgUxqCSx8gzReBG8AlVwAbw1yBhsi9xckBWng5GuYLLAEMD6NBrVlaApBoLbENBn4mBJwuAWn+AEwOd4S/DNwAvAgrSy9dHXAP2BueDSwdcA04B1x3dUCfyVK3PuBweCQ+4uoAewD2l4B9J2h/G7QfCNkPha0fhuwfh+0nROynxOwnRa2nxe0XRuyXxuwXR62Xx+0DJKxDZOyDpKzD5OwDJa1DZa2Dpa3D5a0TJpQ3ZJsyY500ZZs2Z504WdrUWe0moS01spZSJ08rgekMMDUDhFKnz6vVJVzx+ioL28z4rsQGChJ9Nmymkti+GYD0FhqCNq/MW2hIzLFUq6ev+aXA3ZDM1GwTFSU9PsjaUXTyvTxihLYD+8JOMf3V5Tdwq8rb6KizE4TFTVriALC/k1bK83/zcEBSX10GAqFsLa3MJkVxepqojKLkCSARqA5NnaFgKE5X179cEkUpAkBaqIRPAY5Hod4wWLoP96IdEEvD99ajBhBdkxRcodoBBQOP7nS1A6JrkoIrVDugYODRna52QHRNUnCFagcUDDy609UOiK5JCq7QHzFzn2Fi3wKvAAAAAElFTkSuQmCC" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,924,358)"><g transform="translate(3,0) matrix(1,0,0,1,0,0) translate(-3,0)"><path fill="none" stroke="none" d="M 0 0 L 112 0 L 112 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="112" height="14" fill-opacity="0"/></g></g><g transform="translate(3,0) matrix(1,0,0,1,0,0) translate(-3,0)"><path fill="none" stroke="none" d="M 0 0 L 112 0 L 112 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="112" height="14" fill-opacity="0"/></g></g><g transform="translate(3,0) matrix(1,0,0,1,0,0) translate(-3,0)"><path fill="none" stroke="none" d="M 3 0 L 109 0 L 109 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="106" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">7</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">User</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="45" y="11">Authorized</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="102" y="11">?</text></g></g><g transform="matrix(1,0,0,1,920,177)"><image width="64" height="95" preserveAspectRatio="none" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABfCAYAAABY6cGQAAAEAElEQVR4Xu2cSchNYRjHf1+JlSFTIVOxN5ZhgUyZx4wplCESsjCksGElxMJUhjIsiQ1KbFCGBUlC2MiCzFnI0P/rPV/3u9897vnuuefcc9/nPHW6de8957z/3/uc97zD87wNGLcG4/rJASTgAduALyHHV/f93wTuW9Elk/CAfUDHkKOD+/4GIAgPgPvueFeRgpgnJQEgSpEEYiQwDBjuDpUlgHEHuBnlQnH/UysApcrdowBGF2AacMwdH+MKDTs/SwCKy9gHWOOOWw6EHp2qWpYBFAqd50AMAPYCJ6tFoV4ABHr7A0uAccAs4EdcEPUGINA7HrgMrAbOx4FQrwACzeeANsDCSiHUOwDpXgCcBdoDv1oLwgcA0twO+ADoVfq9NRB8ASDNnYEXgPoQkc0nABI9BDgBDI1KwDcA0j0HWAbMjQLBRwDSrddjP2BHOQi+ApBujTTVlX74Pwg+A5gCbACmWgUg3RpWbwHuhkHw2QOkWV3m7cAEqwCkW0PpXcDtUhB89wBpHg3sCfMCCwAE4SUwGXhV7AVWAGhqTa/D41YBaLisHuIiqwC6As+AblYBSPdjYCnwpBCClTZAmg8Ab4GDVgFMd2ODGVYBqB24CoywCqAt8M1NnzUxsNQGSLQANJs3tAbgDTDGNYaNXmANQItJEmsArgH7getBI2ANgJbRrgAXrAI4DDwHjlgFsNEJP2QVgHkPMN8GmH8LmO8HmO8Jmh4LmB8Naj5QgVWjrM4HaCZoFTDTKgDNBb4GmnqB1obDpmeF9fw/BbpbXRcwvzKkNUHlIiiCrJlZmRAxvTpsPj7AdISIYoO2AhOtxggpOmwzcM8iAMUHrnfJV2H6vV4YUUiM+v6PQtV7vDK0DugJ7PyfeF/HAsowWwzMLyfeRwDKE1BEmDJSI5lPPUFlimjVR4EQkc0XAKZzhjTSO2M1a0yrvPLiFgGQUZ+Ben0EJgGXgJXAxahiS/0vbQCdgM8xCjzQveI0wpsN/IxxrcZT0wQwFjgFDK4AgrJDlf/TG9AOFbpOVSwNAKp1RWkudyVW5reGqOWsL7DWCde+AXq/V31XiaQByE1Pu31DAsFhAHq5Dow6McoC1Q4SR53wT+VoVfp7UgBU63JTASg2JTQqfUURm8EeIvr87VLdtIJb13uIbAJ2F9V6IQTtHqN1+j8Fu8hI9PtKazHOeUl4gBo7QdAOD6VM+TsClAlLAkAgTKmrArEC0LY5ganXFjSINYeQJIBAnNoDtQWqdbXsev7lJZmwNAAUCpXwQcVJC7UkkTaAWmotee8cQOaqJOUC5R6QMvDM3S73gMxVScoFyj0gZeCZu13uAZmrkpQLlHtAysAzd7vcAzJXJSkXyLwH/AOwd55gK2pFNAAAAABJRU5ErkJggg==" transform="translate(0,0)"/></g><g transform="matrix(1,0,0,1,908,203)"><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 0 0 L 144 0 L 144 14 L 0 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="0" y="0" width="144" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g></g><g transform="translate(6,0) matrix(1,0,0,1,0,0) translate(-6,0)"><path fill="none" stroke="none" d="M 3 0 L 141 0 L 141 14 L 3 14 Z"/><g><rect fill="rgb(0,0,0)" stroke="none" x="3" y="0" width="138" height="14" fill-opacity="0"/></g><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="3" y="11">5</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="10" y="11">.</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="16" y="11">Is</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="29" y="11">JWT</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="57" y="11">signature</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="110" y="11">valid</text><text fill="rgb(0, 0, 0)" stroke="none" font-family="Arial" font-size="12px" font-style="normal" font-weight="normal" text-decoration="" line-height="14px" x="134" y="11">?</text></g></g></g></svg>
\ No newline at end of file
diff --git a/static/images/docs/components-of-kubernetes.svg b/static/images/docs/components-of-kubernetes.svg
index 0fcbe0aafe..5e7289cb00 100644
--- a/static/images/docs/components-of-kubernetes.svg
+++ b/static/images/docs/components-of-kubernetes.svg
@@ -1,774 +1,412 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
-   xmlns:dc="http://purl.org/dc/elements/1.1/"
-   xmlns:cc="http://creativecommons.org/ns#"
-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
-   xmlns:svg="http://www.w3.org/2000/svg"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   version="1.0"
-   width="4307.5pt"
-   height="1967.5pt"
-   viewBox="0 0 4307.5 1967.5"
-   preserveAspectRatio="xMidYMid meet"
-   id="svg818"
-   sodipodi:docname="components-of-kubernetes.svg"
-   inkscape:version="0.92.4 (unknown)"
-   inkscape:export-filename="/home/fale/www/kubernetes.io/static/images/docs/components-of-kubernetes.png"
-   inkscape:export-xdpi="25.07"
-   inkscape:export-ydpi="25.07">
-  <metadata
-     id="metadata824">
-    <rdf:RDF>
-      <cc:Work
-         rdf:about="">
-        <dc:format>image/svg+xml</dc:format>
-        <dc:type
-           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
-        <dc:title></dc:title>
-      </cc:Work>
-    </rdf:RDF>
-  </metadata>
-  <defs
-     id="defs822">
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker11952"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="EmptyTriangleInM">
-      <path
-         transform="matrix(-0.4,0,0,-0.4,1.8,0)"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#646464;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         id="path11950"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6867"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="EmptyTriangleOutM">
-      <path
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         id="path6865"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleInM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6761"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path6759"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#646464;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.4,0,0,-0.4,1.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleOutM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6659"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path6657"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#646464;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6475"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="EmptyTriangleOutM"
-       inkscape:collect="always">
-      <path
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         id="path6473"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleInM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6393"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path6391"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.4,0,0,-0.4,1.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleOutM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6315"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path6313"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6245"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="EmptyTriangleInM"
-       inkscape:collect="always">
-      <path
-         transform="matrix(-0.4,0,0,-0.4,1.8,0)"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         id="path6243"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6179"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="EmptyTriangleOutM"
-       inkscape:collect="always">
-      <path
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         id="path6177"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleInM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="EmptyTriangleInM"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path5581"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.4,0,0,-0.4,1.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleOutM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="EmptyTriangleOutM"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path5590"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleOutL"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="EmptyTriangleOutL"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5587"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(0.8,0,0,0.8,-4.8,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow2Lend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow2Lend"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5448"
-         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
-         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
-         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Lend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow1Lend"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5430"
-         d="M 0,0 5,-5 -12.5,0 5,5 Z"
-         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.8,0,0,-0.8,-10,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="EmptyTriangleInM"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6761-1"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         inkscape:connector-curvature="0"
-         id="path6759-3"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#646464;stroke-width:1.00000003pt;stroke-opacity:1"
-         transform="matrix(-0.4,0,0,-0.4,1.8,0)" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6867-3"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="EmptyTriangleOutM">
-      <path
-         inkscape:connector-curvature="0"
-         transform="matrix(0.4,0,0,0.4,-1.8,0)"
-         style="fill:#ffffff;fill-rule:evenodd;stroke:#646464;stroke-width:1.00000003pt;stroke-opacity:1"
-         d="M 5.77,0 -2.88,5 V -5 Z"
-         id="path6865-3" />
-    </marker>
-  </defs>
-  <sodipodi:namedview
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1"
-     objecttolerance="10"
-     gridtolerance="10"
-     guidetolerance="10"
-     inkscape:pageopacity="0"
-     inkscape:pageshadow="2"
-     inkscape:window-width="1920"
-     inkscape:window-height="1056"
-     id="namedview820"
-     showgrid="false"
-     inkscape:zoom="0.207876"
-     inkscape:cx="2596.7784"
-     inkscape:cy="1579.5621"
-     inkscape:window-x="0"
-     inkscape:window-y="0"
-     inkscape:window-maximized="1"
-     inkscape:current-layer="g816"
-     showguides="false"
-     fit-margin-top="0"
-     fit-margin-left="0"
-     fit-margin-right="0"
-     fit-margin-bottom="0">
-    <inkscape:grid
-       type="xygrid"
-       id="grid5230"
-       originx="-512.24999"
-       originy="-122.25" />
-  </sodipodi:namedview>
-  <g
-     transform="matrix(0.1,0,0,-0.1,-512.25,2089.75)"
-     id="g816"
-     style="fill:#000000;stroke:none">
-    <rect
-       style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:300, 300;stroke-dashoffset:0;stroke-opacity:1;paint-order:normal"
-       id="rect5408"
-       width="17720"
-       x="5160"
-       y="-20860"
-       transform="scale(1,-1)"
-       ry="374.16977"
-       height="19600" />
-    <rect
-       style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:300, 300;stroke-dashoffset:0;stroke-opacity:1;paint-order:normal"
-       id="rect5380"
-       width="23629.967"
-       height="9317.7373"
-       x="24530.031"
-       y="-11497.74"
-       transform="scale(1,-1)"
-       ry="374.16977" />
-    <path
-       d="m 36544,20020 c -204,-17 -443,-67 -641,-134 -334,-113 -671,-313 -916,-546 l -88,-83 -42,30 c -54,39 -186,105 -263,131 -61,21 -185,46 -284,57 -79,9 -279,-12 -379,-41 -419,-119 -740,-481 -801,-901 l -12,-83 -37,-5 c -101,-17 -282,-68 -388,-110 -508,-203 -918,-651 -1067,-1167 -103,-358 -96,-737 20,-1087 77,-229 203,-446 366,-631 261,-296 636,-508 1029,-581 l 114,-22 3035,-8 c 2987,-8 3037,-8 3180,11 369,51 611,168 841,408 187,195 296,404 356,682 28,129 25,390 -6,529 -60,273 -188,502 -386,689 -203,192 -452,314 -732,358 l -111,18 -11,120 c -23,235 -68,444 -139,642 -133,369 -317,665 -592,948 -408,421 -963,695 -1547,765 -123,15 -384,21 -499,11 z m 371,-230 c 231,-20 433,-64 629,-137 346,-129 624,-310 878,-571 270,-277 448,-572 564,-932 25,-80 50,-154 55,-165 24,-52 59,-322 65,-502 l 7,-188 95,3 c 313,11 608,-107 830,-330 90,-91 135,-150 190,-248 20,-36 39,-67 43,-70 4,-3 18,-34 32,-70 84,-223 95,-465 31,-700 -114,-420 -473,-744 -904,-815 -71,-12 -558,-14 -3060,-14 -1727,-1 -3032,3 -3110,8 -230,16 -414,67 -620,172 -249,126 -446,302 -601,535 -310,467 -352,1081 -108,1580 249,509 751,855 1294,892 l 100,7 6,140 c 8,158 28,243 85,358 53,105 112,184 202,268 124,116 285,200 442,230 88,16 272,14 354,-5 151,-35 336,-138 440,-245 l 49,-50 115,120 c 495,517 1201,788 1897,729 z"
-       id="path58"
-       style="fill:#3966a0;fill-opacity:1"
-       inkscape:connector-curvature="0" />
-    <path
-       d="m 5860,17027 v -1473 l 58,-24 c 31,-13 84,-36 117,-51 88,-40 293,-112 430,-152 l 120,-35 3,-60 3,-60 142,-60 c 215,-90 441,-169 540,-187 l 37,-7 v -63 -62 l 68,-28 c 37,-16 94,-41 127,-56 247,-111 643,-217 985,-264 179,-25 591,-31 777,-11 440,47 781,140 1248,340 541,233 910,327 1397,356 537,32 1137,-83 1672,-320 63,-27 117,-50 120,-50 3,0 6,671 6,1490 v 1490 h -365 -365 v 190 190 h -360 -360 v 190 190 H 9060 5860 Z m 6320,1243 v -150 H 9385 6590 v -1371 -1371 l -27,6 c -122,29 -376,116 -555,192 l -68,29 v 1408 1407 h 3120 3120 z m 730,-380 v -150 l -2797,-2 -2798,-3 -3,-1367 c -2,-1084 -5,-1368 -15,-1368 -44,0 -422,131 -564,196 l -73,33 v 1399 c 0,769 3,1402 7,1405 3,4 1410,7 3125,7 h 3118 z m 720,-1621 c 0,-1109 -3,-1390 -12,-1386 -275,113 -408,158 -635,216 -316,80 -567,112 -888,112 -547,0 -986,-98 -1586,-354 -486,-208 -812,-298 -1231,-343 -208,-22 -623,-15 -818,15 -355,53 -670,142 -987,278 l -83,35 v 1409 1409 h 3120 3120 z"
-       id="path166"
-       style="fill:#3966a0;fill-opacity:1"
-       inkscape:connector-curvature="0" />
-    <g
-       transform="translate(7600,0.00221901)"
-       id="g898-5-7">
-      <path
-         inkscape:connector-curvature="0"
-         id="path566-3-0"
-         d="m 26504.798,6814.2167 c -327.613,0.08 -367.013,-3.213 -394.952,-17.212 -19.958,-10.001 -41.912,-32.0019 -51.891,-52.0019 -16.963,-33 -17.949,-117.005 -17.949,-1330.005 0,-1213 0.986,-1297.005 17.949,-1330.005 34.925,-72 21.961,-70.998 622.671,-67.998 525.87,3 535.852,3.009 563.793,24.009 14.968,10.999 33.918,31.999 39.905,45 9.977,19 12.98,312.99 12.98,1329.99 v 1306.011 l -22.949,33.999 c -12.973,18.9999 -37.931,38.9959 -56.89,45.9959 -24.946,9 -178.617,11.997 -553.809,11.997 -59.373,0.127 -112.057,0.21 -158.858,0.217 z m -34.306,-101.0159 c 62.444,0.105 130.807,0.08 202.153,-0.202 l 519.884,-3.003 0.629,-271.348 h -1050.643 c 1.164,165.372 2.614,268.124 4.254,269.356 2.245,3 136.39,4.872 323.723,5.2 z m -328.65,-379.35 h 1051.564 l 0.644,-280.093 h -1053.23 c 0.307,98.573 0.591,200.227 1.023,280.093 z m -1.403,-384.888 h 1053.844 l 0.644,-277.193 H 26140.06 c 0.105,95.046 0.172,190.883 0.381,277.193 z m -0.494,-381.987 h 1055.232 l 0.337,-145.972 c 1.996,-1034 0,-1291.013 -9.969,-1298.013 -14.968,-9 -1005.835,-10.992 -1029.784,-1.992 -13.97,6 -15.976,129.003 -15.976,1293.003 0,54.104 0.127,100.532 0.157,152.974 z"
-         style="fill:#2c5aa0;stroke-width:0.99892712" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path568-5-9"
-         d="m 26938.07,5409.9978 v -35 h 74.839 74.839 v 35 35 h -74.839 -74.839 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path570-6-3"
-         d="m 26619.754,5023.9978 c -191.588,-38 -252.457,-291 -100.783,-421 97.789,-85 230.504,-78 323.305,15 73.841,74 90.805,143 60.869,243 -35.923,120 -155.666,189 -283.391,163 z m 154.668,-129 c 84.817,-84 51.888,-216 -63.863,-251 -34.925,-10 -47.897,-9 -86.814,5 -115.751,45 -128.723,200 -22.95,267 51.888,32 127.725,22 173.627,-21 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path586-2-6"
-         d="m 27614.616,6778.9977 c -60.869,-32.9999 -57.876,31 -57.876,-1178.9999 0,-1221 -3.991,-1147 63.863,-1179 29.936,-14 96.792,-16 604.7,-16 h 569.776 l -2.994,-47 -2.993,-48 -206.557,-5 c -193.583,-5 -208.551,-6 -227.511,-26 -48.894,-48 -47.897,-172 0,-224 l 27.94,-30 h 742.405 c 687.522,0 743.402,2 762.361,18 33.927,27 43.906,56 43.906,122 0,68 -16.964,110 -51.889,128 -14.967,8 -89.807,13 -222.521,15 l -199.571,2 v 50 50 l 593.724,5 c 326.298,3 594.721,6 596.717,8 0.998,1 10.976,17 21.953,35 19.957,31 19.957,53 19.957,1139 0,695 -3.991,1116 -9.979,1132 -4.989,14 -23.948,35 -41.909,46 -32.93,19.9999 -50.891,19.9999 -1514.745,19.9999 -1291.225,-1 -1485.807,-3 -1508.757,-16 z m 2973.609,-1175.9999 1.995,-1098 h -1466.847 -1466.847 v 1093 c 0,602 2.993,1097 6.985,1100 2.993,4 662.576,6 1463.854,5 l 1457.866,-3 z m -1225.367,-1243 v -44 l -51.888,-3 c -28.938,-2 -136.706,-2 -239.485,0 l -187.597,3 v 44 44 l 52.886,3 c 27.94,2 135.708,2 239.485,0 l 186.599,-3 z m 473.982,-200 v -40 h -708.478 -708.477 l -2.994,28 c -6.985,61 -56.877,57 713.467,55 l 706.482,-3 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path588-9-0"
-         d="m 27796.225,5699.9978 v -855 h 1327.148 1327.148 v 855 855 h -1327.148 -1327.148 z" />
-      <path
-         sodipodi:nodetypes="cccccccc"
-         style="fill:#3771c8;stroke-width:0.70368761"
-         id="path588-7-2-2"
-         d="m 27796.225,5699.9978 v -855 l 261.544,0.245 1055.626,1709.755 v 0 h -658.585 -658.585 z"
-         inkscape:connector-curvature="0" />
-    </g>
-    <g
-       id="g5228"
-       transform="matrix(0.95383647,0,0,1.0010929,1796.8907,29.157905)"
-       style="stroke:#3966a0;stroke-opacity:1">
-      <rect
-         transform="scale(1,-1)"
-         ry="374.16959"
-         y="-10460.273"
-         x="33341.402"
-         height="1579.6681"
-         width="4799.4004"
-         id="rect540-1"
-         style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75.66401672;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1;paint-order:normal" />
-      <text
-         transform="scale(0.99999997,-0.99999997)"
-         xml:space="preserve"
-         style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1"
-         x="34273.75"
-         y="-9385.6641"
-         id="text1130-0"><tspan
-           sodipodi:role="line"
-           id="tspan1128-1"
-           x="34273.75"
-           y="-9385.6641"
-           style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:800px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1">kubelet</tspan></text>
-    </g>
-    <g
-       id="g5228-9"
-       transform="matrix(0.95383647,0,0,1.0010929,2021.6822,-1771.7122)">
-      <rect
-         transform="scale(1,-1)"
-         ry="374.16959"
-         y="-10142.432"
-         x="33173.938"
-         height="1207.8866"
-         width="4799.3984"
-         id="rect540-1-0"
-         style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75.66401672;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1;paint-order:normal" />
-      <text
-         transform="scale(1,-1)"
-         xml:space="preserve"
-         style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-         x="33439.191"
-         y="-9318.832"
-         id="text1130-0-5"><tspan
-           sodipodi:role="line"
-           id="tspan1128-1-6"
-           x="33439.191"
-           y="-9318.832"
-           style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:800px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5">kube-proxy</tspan></text>
-    </g>
-    <g
-       transform="translate(15557.264,28.971911)"
-       id="g898-5-7-7">
-      <path
-         inkscape:connector-curvature="0"
-         id="path566-3-0-4"
-         d="m 26504.798,6814.2167 c -327.613,0.08 -367.013,-3.213 -394.952,-17.212 -19.958,-10.001 -41.912,-32.0019 -51.891,-52.0019 -16.963,-33 -17.949,-117.005 -17.949,-1330.005 0,-1213 0.986,-1297.005 17.949,-1330.005 34.925,-72 21.961,-70.998 622.671,-67.998 525.87,3 535.852,3.009 563.793,24.009 14.968,10.999 33.918,31.999 39.905,45 9.977,19 12.98,312.99 12.98,1329.99 v 1306.011 l -22.949,33.999 c -12.973,18.9999 -37.931,38.9959 -56.89,45.9959 -24.946,9 -178.617,11.997 -553.809,11.997 -59.373,0.127 -112.057,0.21 -158.858,0.217 z m -34.306,-101.0159 c 62.444,0.105 130.807,0.08 202.153,-0.202 l 519.884,-3.003 0.629,-271.348 h -1050.643 c 1.164,165.372 2.614,268.124 4.254,269.356 2.245,3 136.39,4.872 323.723,5.2 z m -328.65,-379.35 h 1051.564 l 0.644,-280.093 h -1053.23 c 0.307,98.573 0.591,200.227 1.023,280.093 z m -1.403,-384.888 h 1053.844 l 0.644,-277.193 H 26140.06 c 0.105,95.046 0.172,190.883 0.381,277.193 z m -0.494,-381.987 h 1055.232 l 0.337,-145.972 c 1.996,-1034 0,-1291.013 -9.969,-1298.013 -14.968,-9 -1005.835,-10.992 -1029.784,-1.992 -13.97,6 -15.976,129.003 -15.976,1293.003 0,54.104 0.127,100.532 0.157,152.974 z"
-         style="fill:#2c5aa0;stroke-width:0.99892712" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path568-5-9-0"
-         d="m 26938.07,5409.9978 v -35 h 74.839 74.839 v 35 35 h -74.839 -74.839 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path570-6-3-6"
-         d="m 26619.754,5023.9978 c -191.588,-38 -252.457,-291 -100.783,-421 97.789,-85 230.504,-78 323.305,15 73.841,74 90.805,143 60.869,243 -35.923,120 -155.666,189 -283.391,163 z m 154.668,-129 c 84.817,-84 51.888,-216 -63.863,-251 -34.925,-10 -47.897,-9 -86.814,5 -115.751,45 -128.723,200 -22.95,267 51.888,32 127.725,22 173.627,-21 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path586-2-6-4"
-         d="m 27614.616,6778.9977 c -60.869,-32.9999 -57.876,31 -57.876,-1178.9999 0,-1221 -3.991,-1147 63.863,-1179 29.936,-14 96.792,-16 604.7,-16 h 569.776 l -2.994,-47 -2.993,-48 -206.557,-5 c -193.583,-5 -208.551,-6 -227.511,-26 -48.894,-48 -47.897,-172 0,-224 l 27.94,-30 h 742.405 c 687.522,0 743.402,2 762.361,18 33.927,27 43.906,56 43.906,122 0,68 -16.964,110 -51.889,128 -14.967,8 -89.807,13 -222.521,15 l -199.571,2 v 50 50 l 593.724,5 c 326.298,3 594.721,6 596.717,8 0.998,1 10.976,17 21.953,35 19.957,31 19.957,53 19.957,1139 0,695 -3.991,1116 -9.979,1132 -4.989,14 -23.948,35 -41.909,46 -32.93,19.9999 -50.891,19.9999 -1514.745,19.9999 -1291.225,-1 -1485.807,-3 -1508.757,-16 z m 2973.609,-1175.9999 1.995,-1098 h -1466.847 -1466.847 v 1093 c 0,602 2.993,1097 6.985,1100 2.993,4 662.576,6 1463.854,5 l 1457.866,-3 z m -1225.367,-1243 v -44 l -51.888,-3 c -28.938,-2 -136.706,-2 -239.485,0 l -187.597,3 v 44 44 l 52.886,3 c 27.94,2 135.708,2 239.485,0 l 186.599,-3 z m 473.982,-200 v -40 h -708.478 -708.477 l -2.994,28 c -6.985,61 -56.877,57 713.467,55 l 706.482,-3 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path588-9-0-7"
-         d="m 27796.225,5699.9978 v -855 h 1327.148 1327.148 v 855 855 h -1327.148 -1327.148 z" />
-      <path
-         sodipodi:nodetypes="cccccccc"
-         style="fill:#3771c8;stroke-width:0.70368761"
-         id="path588-7-2-2-4"
-         d="m 27796.225,5699.9978 v -855 l 261.544,0.245 1055.626,1709.755 v 0 h -658.585 -658.585 z"
-         inkscape:connector-curvature="0" />
-    </g>
-    <g
-       id="g5228-8"
-       transform="matrix(0.9538365,0,0,1.0010929,9754.1549,58.127911)"
-       style="stroke:#3966a0;stroke-opacity:1">
-      <rect
-         transform="scale(1,-1)"
-         ry="374.16959"
-         y="-10460.273"
-         x="33341.402"
-         height="1579.6681"
-         width="4799.4004"
-         id="rect540-1-5"
-         style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75.66401672;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1;paint-order:normal" />
-      <text
-         transform="scale(0.99999997,-0.99999997)"
-         xml:space="preserve"
-         style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1"
-         x="34273.75"
-         y="-9385.6641"
-         id="text1130-0-8"><tspan
-           sodipodi:role="line"
-           id="tspan1128-1-2"
-           x="34273.75"
-           y="-9385.6641"
-           style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:800px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1">kubelet</tspan></text>
-    </g>
-    <g
-       id="g5228-9-6"
-       transform="matrix(0.9538365,0,0,1.0010929,9978.9469,-1742.7421)"
-       style="stroke:#3966a0;stroke-opacity:1">
-      <rect
-         transform="scale(1,-1)"
-         ry="374.16959"
-         y="-10142.432"
-         x="33173.938"
-         height="1207.8866"
-         width="4799.3984"
-         id="rect540-1-0-0"
-         style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75.66401672;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1;paint-order:normal" />
-      <text
-         transform="scale(1,-1)"
-         xml:space="preserve"
-         style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1"
-         x="33439.191"
-         y="-9318.832"
-         id="text1130-0-5-6"><tspan
-           sodipodi:role="line"
-           id="tspan1128-1-6-6"
-           x="33439.191"
-           y="-9318.832"
-           style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:800px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1">kube-proxy</tspan></text>
-    </g>
-    <g
-       transform="translate(234.5822,-154.259)"
-       id="g898-5-7-4">
-      <path
-         inkscape:connector-curvature="0"
-         id="path566-3-0-6"
-         d="m 26504.798,6814.2167 c -327.613,0.08 -367.013,-3.213 -394.952,-17.212 -19.958,-10.001 -41.912,-32.0019 -51.891,-52.0019 -16.963,-33 -17.949,-117.005 -17.949,-1330.005 0,-1213 0.986,-1297.005 17.949,-1330.005 34.925,-72 21.961,-70.998 622.671,-67.998 525.87,3 535.852,3.009 563.793,24.009 14.968,10.999 33.918,31.999 39.905,45 9.977,19 12.98,312.99 12.98,1329.99 v 1306.011 l -22.949,33.999 c -12.973,18.9999 -37.931,38.9959 -56.89,45.9959 -24.946,9 -178.617,11.997 -553.809,11.997 -59.373,0.127 -112.057,0.21 -158.858,0.217 z m -34.306,-101.0159 c 62.444,0.105 130.807,0.08 202.153,-0.202 l 519.884,-3.003 0.629,-271.348 h -1050.643 c 1.164,165.372 2.614,268.124 4.254,269.356 2.245,3 136.39,4.872 323.723,5.2 z m -328.65,-379.35 h 1051.564 l 0.644,-280.093 h -1053.23 c 0.307,98.573 0.591,200.227 1.023,280.093 z m -1.403,-384.888 h 1053.844 l 0.644,-277.193 H 26140.06 c 0.105,95.046 0.172,190.883 0.381,277.193 z m -0.494,-381.987 h 1055.232 l 0.337,-145.972 c 1.996,-1034 0,-1291.013 -9.969,-1298.013 -14.968,-9 -1005.835,-10.992 -1029.784,-1.992 -13.97,6 -15.976,129.003 -15.976,1293.003 0,54.104 0.127,100.532 0.157,152.974 z"
-         style="fill:#2c5aa0;stroke-width:0.99892712" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path568-5-9-2"
-         d="m 26938.07,5409.9978 v -35 h 74.839 74.839 v 35 35 h -74.839 -74.839 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path570-6-3-8"
-         d="m 26619.754,5023.9978 c -191.588,-38 -252.457,-291 -100.783,-421 97.789,-85 230.504,-78 323.305,15 73.841,74 90.805,143 60.869,243 -35.923,120 -155.666,189 -283.391,163 z m 154.668,-129 c 84.817,-84 51.888,-216 -63.863,-251 -34.925,-10 -47.897,-9 -86.814,5 -115.751,45 -128.723,200 -22.95,267 51.888,32 127.725,22 173.627,-21 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path586-2-6-9"
-         d="m 27614.616,6778.9977 c -60.869,-32.9999 -57.876,31 -57.876,-1178.9999 0,-1221 -3.991,-1147 63.863,-1179 29.936,-14 96.792,-16 604.7,-16 h 569.776 l -2.994,-47 -2.993,-48 -206.557,-5 c -193.583,-5 -208.551,-6 -227.511,-26 -48.894,-48 -47.897,-172 0,-224 l 27.94,-30 h 742.405 c 687.522,0 743.402,2 762.361,18 33.927,27 43.906,56 43.906,122 0,68 -16.964,110 -51.889,128 -14.967,8 -89.807,13 -222.521,15 l -199.571,2 v 50 50 l 593.724,5 c 326.298,3 594.721,6 596.717,8 0.998,1 10.976,17 21.953,35 19.957,31 19.957,53 19.957,1139 0,695 -3.991,1116 -9.979,1132 -4.989,14 -23.948,35 -41.909,46 -32.93,19.9999 -50.891,19.9999 -1514.745,19.9999 -1291.225,-1 -1485.807,-3 -1508.757,-16 z m 2973.609,-1175.9999 1.995,-1098 h -1466.847 -1466.847 v 1093 c 0,602 2.993,1097 6.985,1100 2.993,4 662.576,6 1463.854,5 l 1457.866,-3 z m -1225.367,-1243 v -44 l -51.888,-3 c -28.938,-2 -136.706,-2 -239.485,0 l -187.597,3 v 44 44 l 52.886,3 c 27.94,2 135.708,2 239.485,0 l 186.599,-3 z m 473.982,-200 v -40 h -708.478 -708.477 l -2.994,28 c -6.985,61 -56.877,57 713.467,55 l 706.482,-3 z" />
-      <path
-         inkscape:connector-curvature="0"
-         style="fill:#2c5aa0;stroke-width:0.99892706"
-         id="path588-9-0-6"
-         d="m 27796.225,5699.9978 v -855 h 1327.148 1327.148 v 855 855 h -1327.148 -1327.148 z" />
-      <path
-         sodipodi:nodetypes="cccccccc"
-         style="fill:#3771c8;stroke-width:0.70368761"
-         id="path588-7-2-2-0"
-         d="m 27796.225,5699.9978 v -855 l 261.544,0.245 1055.626,1709.755 v 0 h -658.585 -658.585 z"
-         inkscape:connector-curvature="0" />
-    </g>
-    <g
-       id="g5228-7"
-       transform="matrix(0.9538365,0,0,1.0010929,-5568.5268,-125.103)"
-       style="stroke:#3966a0;stroke-opacity:1">
-      <rect
-         transform="scale(1,-1)"
-         ry="374.16959"
-         y="-10460.273"
-         x="33341.402"
-         height="1579.6681"
-         width="4799.4004"
-         id="rect540-1-01"
-         style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75.66401672;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1;paint-order:normal" />
-      <text
-         transform="scale(0.99999997,-0.99999997)"
-         xml:space="preserve"
-         style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1"
-         x="34273.75"
-         y="-9385.6641"
-         id="text1130-0-0"><tspan
-           sodipodi:role="line"
-           id="tspan1128-1-1"
-           x="34273.75"
-           y="-9385.6641"
-           style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:800px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1">kubelet</tspan></text>
-    </g>
-    <g
-       id="g5228-9-3"
-       transform="matrix(0.9538365,0,0,1.0010929,-5343.7348,-1925.973)"
-       style="stroke:#3966a0;stroke-opacity:1">
-      <rect
-         transform="scale(1,-1)"
-         ry="374.16959"
-         y="-10142.432"
-         x="33173.938"
-         height="1207.8866"
-         width="4799.3984"
-         id="rect540-1-0-7"
-         style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:75.66401672;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1;paint-order:normal" />
-      <text
-         transform="scale(1,-1)"
-         xml:space="preserve"
-         style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1"
-         x="33439.191"
-         y="-9318.832"
-         id="text1130-0-5-7"><tspan
-           sodipodi:role="line"
-           id="tspan1128-1-6-2"
-           x="33439.191"
-           y="-9318.832"
-           style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:800px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke:#3966a0;stroke-width:7.5;stroke-opacity:1">kube-proxy</tspan></text>
-    </g>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="33737.383"
-       y="-2473.6172"
-       id="text5384"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         id="tspan5382"
-         x="33737.383"
-         y="-2473.6172"
-         style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:700px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab Bold';fill:#646464;fill-opacity:1;stroke-width:7.5">Kubernetes Nodes</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="6566.0039"
-       y="-19571.555"
-       id="text5384-3"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         id="tspan5382-7"
-         x="6566.0039"
-         y="-19571.555"
-         style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:699.99993896px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab Bold';fill:#646464;fill-opacity:1;stroke-width:7.5">Kubernetes Control Plane</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="35042.906"
-       y="-16825.971"
-       id="text5406"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         id="tspan5404"
-         x="35042.906"
-         y="-16825.971"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:700px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5">Cloud</tspan></text>
-    <path
-       style="fill:#3966a0;fill-opacity:1;stroke-width:0.99999994"
-       inkscape:connector-curvature="0"
-       d="m 14260,17027 v -1473 l 58,-24 c 31,-13 84,-36 117,-51 88,-40 293,-112 430,-152 l 120,-35 3,-60 3,-60 142,-60 c 215,-90 441,-169 540,-187 l 37,-7 v -63 -62 l 68,-28 c 37,-16 94,-41 127,-56 247,-111 643,-217 985,-264 179,-25 591,-31 777,-11 440,47 781,140 1248,340 541,233 910,327 1397,356 537,32 1137,-83 1672,-320 63,-27 117,-50 120,-50 3,0 6,671 6,1490 v 1490 h -365 -365 v 190 190 h -360 -360 v 190 190 h -3200 -3200 z m 6320,1243 v -150 h -2795 -2795 v -1371 -1371 l -27,6 c -122,29 -376,116 -555,192 l -68,29 v 1408 1407 h 3120 3120 z m 730,-380 v -150 l -2797,-2 -2798,-3 -3,-1367 c -2,-1084 -5,-1368 -15,-1368 -44,0 -422,131 -564,196 l -73,33 v 1399 c 0,769 3,1402 7,1405 3,4 1410,7 3125,7 h 3118 z m 720,-1621 c 0,-1109 -3,-1390 -12,-1386 -275,113 -408,158 -635,216 -316,80 -567,112 -888,112 -547,0 -986,-98 -1586,-354 -486,-208 -812,-298 -1231,-343 -208,-22 -623,-15 -818,15 -355,53 -670,142 -987,278 l -83,35 v 1409 1409 h 3120 3120 z"
-       id="path166-4" />
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#EmptyTriangleOutM)"
-       d="m 22025.844,16908.074 9467.602,-36.445"
-       id="path5425"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="15908.43"
-       y="-16740.76"
-       id="text5945"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         id="tspan5943"
-         x="15908.43"
-         y="-16740.76"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5">cloud-controller</tspan><tspan
-         sodipodi:role="line"
-         x="15908.43"
-         y="-15765.76"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5"
-         id="tspan5953">manager</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="7517.4902"
-       y="-16773.648"
-       id="text5945-1"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         id="tspan5943-8"
-         x="7517.4902"
-         y="-16773.648"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5">kube-controller</tspan><tspan
-         sodipodi:role="line"
-         x="7517.4902"
-         y="-15798.648"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5"
-         id="tspan5953-3">manager</tspan></text>
-    <path
-       style="fill:#3966a0;fill-opacity:1;stroke-width:0.99999994"
-       inkscape:connector-curvature="0"
-       d="m 13887.5,5553.486 v -1473 l 58,-24 c 31,-13 84,-36 117,-51 88,-40 293,-112 430,-152 l 120,-35 3,-60 3,-60 142,-60 c 215,-90 441,-169 540,-187 l 37,-7 v -63 -62 l 68,-28 c 37,-16 94,-41 127,-56 247,-111 643,-217 985,-264 179,-25 591,-31 777,-11 440,47 781,140 1248,340 541,233 910,327 1397,356 537,32 1137,-83 1672,-320 63,-27 117,-50 120,-50 3,0 6,671 6,1490 v 1490 h -365 -365 v 190 190 h -360 -360 v 190 190 h -3200 -3200 z m 6320,1243 v -150 h -2795 -2795 v -1371 -1371 l -27,6 c -122,29 -376,116 -555,192 l -68,29 v 1408 1407 h 3120 3120 z m 730,-380 v -150 l -2797,-2 -2798,-3 -3,-1367 c -2,-1084 -5,-1368 -15,-1368 -44,0 -422,131 -564,196 l -73,33 v 1399 c 0,769 3,1402 7,1405 3,4 1410,7 3125,7 h 3118 z m 720,-1621 c 0,-1109 -3,-1390 -12,-1386 -275,113 -408,158 -635,216 -316,80 -567,112 -888,112 -547,0 -986,-98 -1586,-354 -486,-208 -812,-298 -1231,-343 -208,-22 -623,-15 -818,15 -355,53 -670,142 -987,278 l -83,35 v 1409 1409 h 3120 3120 z"
-       id="path166-42" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="15666.416"
-       y="-4661.1484"
-       id="text5945-1-2"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         x="15666.416"
-         y="-4661.1484"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5"
-         id="tspan5953-3-5">kube-scheduler</tspan></text>
-    <path
-       style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:112.5;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:normal"
-       d="M 13912.5,11649.886 15878.523,12330 H 21825 V 9592.5 h -7912.5 z"
-       id="rect6014"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cccccc" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="15070.075"
-       y="-10632.383"
-       id="text5945-1-2-1"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         x="15070.075"
-         y="-10632.383"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5"
-         id="tspan5953-3-5-7">kube-api-server</tspan></text>
-    <path
-       id="rect6035-5"
-       style="fill:#ffffff;fill-opacity:1;stroke:#3966a0;stroke-width:112.5;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:normal"
-       d="m 9190.8111,9543.844 c 1459.5379,0 2634.5449,-501.379 2634.5449,-1124.168 v -15.703 c 0,-622.7888 -1175.007,-1124.1678 -2634.5449,-1124.1678 -1459.538,0 -2634.5453,501.379 -2634.5453,1124.1678 v 15.703 c 0,622.789 1175.0073,1124.168 2634.5453,1124.168 z m 0.145,1.252 c 1459.5379,0 2634.5449,-501.379 2634.5449,-1124.1686 v -765.703 c 0,-622.789 -1175.007,-1124.168 -2634.5449,-1124.168 -1459.538,0 -2634.5453,501.379 -2634.5453,1124.168 v 765.703 c 0,622.7896 1175.0073,1124.1686 2634.5453,1124.1686 z m 3.0355,1.373 c 1459.5374,0 2634.5444,-501.379 2634.5444,-1124.1691 V 6947.7535 c 0,-622.789 -1175.007,-1124.168 -2634.5444,-1124.168 -1459.538,0 -2634.5453,501.379 -2634.5453,1124.168 v 1474.5464 c 0,622.7901 1175.0073,1124.1691 2634.5453,1124.1691 z m 0,0 c 1459.5374,0 2634.5444,-501.379 2634.5444,-1124.169 V 6197.754 c 0,-622.789 -1175.007,-1124.168 -2634.5444,-1124.168 -1459.5379,0 -2634.5452,501.379 -2634.5452,1124.168 V 8422.3 c 0,622.79 1175.0073,1124.169 2634.5452,1124.169 z m -1.7187,-7.832 c 1459.5381,0 2634.5451,-501.379 2634.5451,-1124.1679 V 3828.2589 c 0,-622.7888 -1175.007,-1124.1676 -2634.5451,-1124.1676 -1459.5381,0 -2634.5454,501.3788 -2634.5454,1124.1676 v 4586.2102 c 0,622.7889 1175.0073,1124.1679 2634.5454,1124.1679 z"
-       inkscape:connector-curvature="0" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:300px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3966a0;fill-opacity:1;stroke:none;stroke-width:7.5"
-       x="8409.7988"
-       y="-3744.3438"
-       id="text5945-1-2-1-9"
-       transform="scale(1,-1)"><tspan
-         sodipodi:role="line"
-         x="8409.7988"
-         y="-3744.3438"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:780px;font-family:'Roboto Slab';-inkscape-font-specification:'Roboto Slab';fill:#3966a0;fill-opacity:1;stroke-width:7.5"
-         id="tspan5953-3-5-7-8">etcd</tspan></text>
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#EmptyTriangleInM);marker-end:url(#marker6179)"
-       d="m 18364.313,12303.007 v 2291.03"
-       id="path6119"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker6245);marker-end:url(#marker6315)"
-       d="m 11473.186,15081.106 3129.871,-3129.87"
-       id="path6235"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker6393);marker-end:url(#marker6475)"
-       d="M 13890.493,9849.6218 11295.427,9154.2765"
-       id="path6383"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker11952);marker-end:url(#marker6659)"
-       d="M 18183.917,9579.0278 V 7035.444"
-       id="path6555"
-       inkscape:connector-curvature="0" />
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker6761);marker-end:url(#marker6867)"
-       d="m 26175.46,9687.2655 -2381.227,18.0396 -18.039,1389.0489 h -1966.317"
-       id="path6751"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cccc" />
-    <path
-       style="fill:none;stroke:#646464;stroke-width:112.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker6761-1);marker-end:url(#marker6867-3)"
-       d="m 26175.46,7576.6317 -2381.227,18.04 -18.039,3499.6823 h -1966.317"
-       id="path6751-7"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cccc" />
+<?xml version="1.0" encoding="UTF-8"?>
+<svg id="svg277" width="331.31mm" height="154.79mm" version="1.1" viewBox="0 0 1252.2 585.04" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
+ <title id="title3597">Kubernetes components</title>
+ <metadata id="metadata2">
+  <rdf:RDF>
+   <cc:Work rdf:about="Components of Kubernetes">
+    <dc:format>image/svg+xml</dc:format>
+    <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
+    <dc:title>Kubernetes components</dc:title>
+    <dc:creator>
+     <cc:Agent>
+      <dc:title>Cloud Native Computing Foundation</dc:title>
+     </cc:Agent>
+    </dc:creator>
+   </cc:Work>
+  </rdf:RDF>
+ </metadata>
+ <defs id="defs4">
+  <marker id="Arrow2Mend" overflow="visible" orient="auto">
+   <path id="path1645" transform="scale(-.6)" d="m8.7186 4.0337-10.926-4.0177 10.926-4.0177c-1.7455 2.3721-1.7354 5.6175-6e-7 8.0354z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
+  </marker>
+  <style id="style2">.cls-1{font-size:254.54px;font-family:'Open Sans', sans-serif;}.cls-10,.cls-2,.cls-3,.cls-5,.cls-6,.cls-7,.cls-9{fill:none;}.cls-3,.cls-9{stroke:blue;}.cls-10,.cls-3{stroke-miterlimit:10;}.cls-4{fill-opacity:0;}.cls-4,.cls-8{fill-rule:evenodd;}.cls-5{stroke:#b14d9d;}.cls-5,.cls-6,.cls-7,.cls-9{stroke-linejoin:round;}.cls-5,.cls-6{stroke-width:2px;stroke-dasharray:8 6;}.cls-6{stroke:#009444;}.cls-10,.cls-7{stroke:#000;}.cls-8{fill:#e6e6e6;}.cls-11{fill:#326ce5;}.cls-12,.cls-22{font-size:12px;}.cls-12,.cls-13,.cls-15,.cls-16,.cls-17,.cls-18,.cls-19,.cls-20,.cls-21,.cls-23{fill:#fff;}.cls-12,.cls-15,.cls-16,.cls-17,.cls-18,.cls-19,.cls-20,.cls-21,.cls-22,.cls-23{font-family:'Open Sans', sans-serif;}.cls-14,.cls-15,.cls-16,.cls-17,.cls-18,.cls-19,.cls-20,.cls-21,.cls-23{isolation:isolate;}.cls-15{font-size:11.77px;}.cls-16{font-size:11.14px;}.cls-17{font-size:11.07px;}.cls-18{font-size:10.36px;}.cls-19{font-size:10.71px;}.cls-20{font-size:10.06px;}.cls-21{font-size:11.31px;}.cls-23{font-size:9.71px;}</style>
+ </defs>
+ <g id="layer3" transform="translate(-138.94 -55.356)">
+  <rect id="rect1045" x="154.05" y="70.474" width="956.24" height="544.24" ry="34.593" fill="#6d6d6d" fill-opacity=".43" opacity=".869" aria-labelledby="text274"/>
+ </g>
+ <text id="text6" class="cls-1" transform="scale(1.546 .64685)" x="306.19925" y="1883.1586" stroke-width="1.546"/>
+ <path id="path16" class="cls-4" d="m31.924 98.833a58 58 0 0 1 58-58h231.91a58 58 0 0 1 58 58v325.17a58 58 0 0 1-58 58h-231.92a58 58 0 0 1-58-58z"/>
+ <path id="path22" class="cls-4" d="m397.77 90.003h445.41"/>
+ <path id="path28" class="cls-8" d="m485.69 245.09-1 0.22-1.75 1.68-1.37 2.74-0.77 3.82v259.51l0.77 3.8 1.37 3 1.75 1.47 1 0.2h127.41l1.07-0.2 1.76-1.47 1.27-3 0.78-3.8v-259.51l-0.78-3.82-1.27-2.74-1.74-1.68-1.07-0.22z"/>
+ <path id="path30" class="cls-8" d="m646.39 245.09-1 0.22-1.76 1.68-1.36 2.74-0.78 3.82v259.51l0.78 3.8 1.36 3 1.76 1.47 1 0.2h127.41l1.07-0.2 1.75-1.47 1.28-3 0.77-3.8v-259.51l-0.77-3.82-1.28-2.74-1.75-1.68-1.07-0.22z"/>
+ <path id="path32" class="cls-8" d="m807.08 245.09-1 0.22-1.75 1.68-1.37 2.74-0.78 3.82v259.51l0.78 3.8 1.37 3 1.75 1.47 1 0.2h127.41l1.07-0.2 1.76-1.47 1.2699-3 0.78-3.8v-259.51l-0.78-3.82-1.2699-2.74-1.76-1.68-1.07-0.22z"/>
+ <path id="path46" class="cls-4" d="m364.66 245.27h176.52v60.85h176.52"/>
+ <path id="path58" class="cls-4" d="m307.86 148.15v59.85"/>
+ <path id="path60" class="cls-7" d="m299.16 202.69 0.58757-59.984" marker-end="url(#Arrow2Mend)" stroke-dasharray="4.5, 4.5" stroke-width="1.5"/>
+ <g id="g1766" transform="translate(-128.38 -37.947)">
+  <path id="path66" class="cls-4" d="m282 172.21 109.39 95.84"/>
+  <path id="path68" class="cls-7" d="m287.05 176.63 106.47 81.098"/>
+  <path id="path70" class="cls-10" d="m288.26 175.24-5-2 2.6 4.73z"/>
+ </g>
+ <g id="g1925" transform="translate(-127.95 -38.269)">
+  <path id="path74" class="cls-4" d="m280.16 398.2 106.68-89.49"/>
+  <path id="path76" class="cls-7" d="m285.33 393.89 113.97-88.512"/>
+  <path id="path78" class="cls-10" d="m284.16 392.48-2.7 4.67 5.08-1.84z"/>
+ </g>
+ <path id="path86" class="cls-4" d="m84.814 348.83h70.14v70.17h-70.14z"/>
+ <g id="g1930" transform="translate(-125.69 -31.966)">
+  <path id="path110" class="cls-4" d="m431.68 332.24v59.89"/>
+  <path id="path112" class="cls-7" d="m431.58 327 0.0987 58.471"/>
+  <path id="path116" class="cls-10" d="m429.83 385.42 1.85 5.07 1.85-5.07z"/>
+ </g>
+ <path id="path120" class="cls-4" d="m79.344 459.47h258v21.9h-258z"/>
+ <path id="path122" class="cls-4" d="m364.66 245.27h352.52"/>
+ <g id="g1244" transform="translate(-189.24 210.02)">
+  <g id="g3835">
+   <path id="path126-1" class="cls-11" d="m994.86-151.53-3.7358 0.22237-6.7823 1.9013-3.0687 1.8901-3.0798 2.1347-5.2702 5.4703-1.7344 3.0798-1.7123 3.5357-1.7456 7.3604-0.2224 4.0471v1.412l-3.5913 1.6566-5.915 4.7365-2.4016 3.3355-2.0013 3.569-2.4016 7.5828-0.2113 4.2584 0.2113 3.569 1.5343 6.6711 1.5344 3.0687 1.7678 3.0798 4.6031 4.9811 2.6128 1.9013 3.0799 1.6566 6.1374 1.6678 3.3355 0.22237h62.942l2.8463-0.22237 5.4702-1.4343 2.6351-1.6455 2.4128-1.4343 4.1694-4.2584 1.5344-2.6017 1.3342-2.8574 1.5121-5.9262v-3.3355l-0.2113-4.2917-2.4015-7.3382-2.2237-3.569-2.8464-2.8241-6.1374-4.2806-3.5134-0.94507 0.6449-3.1021 0.2335-3.3355-0.2335-3.569-2.4016-6.3931-2.2237-2.6128-2.4127-2.3682-5.915-2.6128-3.3357-0.24461h-2.4126l-4.603 1.6678-1.9791 1.1897-1.9681-3.0798-4.9921-5.4369-3.0465-2.1125-3.0686-1.8901-7.0159-1.9013z" fill="#326ce5" stroke-width="1.1118"/>
+   <path id="path3753" d="m989.51-127.57q-1.8828 0-2.9766 1.2578-1.0859 1.25-1.0859 3.4297 0 2.2422 1.0469 3.4688 1.0547 1.2188 3 1.2188 1.1953 0 2.7266-0.42968v1.1641q-1.1875 0.44531-2.9297 0.44531-2.5234 0-3.8984-1.5312-1.3672-1.5312-1.3672-4.3516 0-1.7656 0.65625-3.0938 0.66406-1.3281 1.9062-2.0469 1.25-0.71875 2.9375-0.71875 1.7969 0 3.1406 0.65625l-0.5625 1.1406q-1.2969-0.60938-2.5938-0.60938z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3755" d="m995.81-117.17h-1.2969v-12.156h1.2969z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3757" d="m1006-121.46q0 2.0938-1.0546 3.2734-1.0547 1.1719-2.9141 1.1719-1.1484 0-2.0391-0.53906-0.89063-0.53906-1.375-1.5469-0.48438-1.0078-0.48438-2.3594 0-2.0938 1.0469-3.2578 1.0469-1.1719 2.9063-1.1719 1.7969 0 2.8515 1.1953 1.0625 1.1953 1.0625 3.2344zm-6.5234 0q0 1.6406 0.6563 2.5 0.6562 0.85937 1.9296 0.85937 1.2735 0 1.9297-0.85156 0.6641-0.85937 0.6641-2.5078 0-1.6328-0.6641-2.4766-0.6562-0.85157-1.9453-0.85157-1.2734 0-1.9219 0.83594-0.6484 0.83594-0.6484 2.4922z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3759" d="m1009.5-125.73v5.5547q0 1.0469 0.4766 1.5625 0.4765 0.51562 1.4922 0.51562 1.3437 0 1.9609-0.73437 0.625-0.73438 0.625-2.3984v-4.5h1.2969v8.5625h-1.0703l-0.1875-1.1484h-0.07q-0.3985 0.63282-1.1094 0.96875-0.7031 0.33594-1.6094 0.33594-1.5625 0-2.3437-0.74219-0.7735-0.74218-0.7735-2.375v-5.6016z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3761" d="m1023.9-118.32h-0.07q-0.8985 1.3047-2.6875 1.3047-1.6797 0-2.6172-1.1484-0.9297-1.1484-0.9297-3.2656t0.9375-3.2891q0.9375-1.1719 2.6094-1.1719 1.7422 0 2.6719 1.2656h0.1015l-0.055-0.61719-0.031-0.60156v-3.4844h1.2969v12.156h-1.0547zm-2.5938 0.21875q1.3282 0 1.9219-0.71875 0.6016-0.72656 0.6016-2.3359v-0.27344q0-1.8203-0.6094-2.5938-0.6016-0.78125-1.9297-0.78125-1.1406 0-1.75 0.89062-0.6015 0.88282-0.6015 2.5 0 1.6406 0.6015 2.4766 0.6016 0.83593 1.7656 0.83593z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3763" d="m978.42-97.015q-0.83593 0-1.5312-0.30469-0.6875-0.3125-1.1562-0.95312h-0.0937q0.0937 0.75 0.0937 1.4219v3.5234h-1.2969v-12.406h1.0547l0.17968 1.1719h0.0625q0.5-0.70313 1.1641-1.0156 0.66406-0.3125 1.5234-0.3125 1.7031 0 2.625 1.1641 0.92969 1.1641 0.92969 3.2656 0 2.1094-0.94531 3.2812-0.9375 1.1641-2.6094 1.1641zm-0.1875-7.7734q-1.3125 0-1.8984 0.72657-0.58594 0.72656-0.60157 2.3125v0.28906q0 1.8047 0.60157 2.5859 0.60156 0.77344 1.9297 0.77344 1.1094 0 1.7344-0.89844 0.63281-0.89844 0.63281-2.4766 0-1.6016-0.63281-2.4531-0.625-0.85938-1.7656-0.85938z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3765" d="m988.16-105.89q0.57031 0 1.0234 0.0937l-0.17969 1.2031q-0.53125-0.11719-0.9375-0.11719-1.0391 0-1.7812 0.84375-0.73438 0.84375-0.73438 2.1016v4.5938h-1.2969v-8.5625h1.0703l0.14844 1.5859h0.0625q0.47656-0.83594 1.1484-1.2891 0.67187-0.45313 1.4766-0.45313z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3767" d="m998.17-101.46q0 2.0937-1.0547 3.2734-1.0547 1.1719-2.9141 1.1719-1.1484 0-2.0391-0.53906-0.89062-0.53906-1.375-1.5469-0.48437-1.0078-0.48437-2.3594 0-2.0938 1.0469-3.2578 1.0469-1.1719 2.9062-1.1719 1.7969 0 2.8516 1.1953 1.0625 1.1953 1.0625 3.2344zm-6.5234 0q0 1.6406 0.65625 2.5t1.9297 0.85938q1.2734 0 1.9297-0.85156 0.66406-0.85938 0.66406-2.5078 0-1.6328-0.66406-2.4766-0.65625-0.85157-1.9453-0.85157-1.2734 0-1.9219 0.83594-0.64843 0.83594-0.64843 2.4922z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3769" d="m1002.3-97.172-3.25-8.5625h1.3906l1.8438 5.0781q0.625 1.7812 0.7343 2.3125h0.062q0.086-0.41406 0.5391-1.7109 0.4609-1.3047 2.0547-5.6797h1.3906l-3.25 8.5625z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3771" d="m1009.8-97.172h-1.2969v-8.5625h1.2969zm-1.4062-10.883q0-0.44531 0.2187-0.64844 0.2188-0.21094 0.5469-0.21094 0.3125 0 0.5391 0.21094 0.2265 0.21094 0.2265 0.64844t-0.2265 0.65625q-0.2266 0.21094-0.5391 0.21094-0.3281 0-0.5469-0.21094-0.2187-0.21875-0.2187-0.65625z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3773" d="m1018.4-98.32h-0.07q-0.8985 1.3047-2.6875 1.3047-1.6797 0-2.6172-1.1484-0.9297-1.1484-0.9297-3.2656 0-2.1172 0.9375-3.2891 0.9375-1.1719 2.6094-1.1719 1.7421 0 2.6718 1.2656h0.1016l-0.055-0.61719-0.031-0.60156v-3.4844h1.2968v12.156h-1.0547zm-2.5938 0.21875q1.3281 0 1.9219-0.71875 0.6016-0.72656 0.6016-2.3359v-0.27344q0-1.8203-0.6094-2.5938-0.6016-0.78125-1.9297-0.78125-1.1406 0-1.75 0.89062-0.6016 0.88282-0.6016 2.5 0 1.6406 0.6016 2.4766 0.6016 0.83594 1.7656 0.83594z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3775" d="m1026-97.015q-1.8984 0-3-1.1562-1.0937-1.1562-1.0937-3.2109 0-2.0703 1.0156-3.2891 1.0234-1.2188 2.7422-1.2188 1.6094 0 2.5469 1.0625 0.9375 1.0547 0.9375 2.7891v0.82032h-5.8985q0.039 1.5078 0.7578 2.2891 0.7266 0.78125 2.0391 0.78125 1.3828 0 2.7344-0.57812v1.1562q-0.6875 0.29688-1.3047 0.42188-0.6094 0.13281-1.4766 0.13281zm-0.3515-7.7891q-1.0313 0-1.6485 0.67187-0.6093 0.67188-0.7187 1.8594h4.4765q0-1.2266-0.5468-1.875-0.5469-0.65625-1.5625-0.65625z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3777" d="m1035.2-105.89q0.5704 0 1.0235 0.0937l-0.1797 1.2031q-0.5313-0.11719-0.9375-0.11719-1.0391 0-1.7813 0.84375-0.7343 0.84375-0.7343 2.1016v4.5938h-1.2969v-8.5625h1.0703l0.1484 1.5859h0.062q0.4766-0.83594 1.1485-1.2891 0.6719-0.45313 1.4765-0.45313z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3779" d="m1001.4-77.172-1.4218-3.6328h-4.5781l-1.4062 3.6328h-1.3438l4.5156-11.469h1.1172l4.4922 11.469zm-1.8359-4.8281-1.3281-3.5391q-0.25782-0.67188-0.53125-1.6484-0.17188 0.75-0.49219 1.6484l-1.3438 3.5391z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3781" d="m1011.6-85.265q0 1.7344-1.1875 2.6719-1.1796 0.92969-3.3828 0.92969h-1.3437v4.4922h-1.3281v-11.422h2.9609q4.2812 0 4.2812 3.3281zm-5.914 2.4609h1.1953q1.7656 0 2.5547-0.57031 0.789-0.57031 0.789-1.8281 0-1.1328-0.7421-1.6875-0.7422-0.55469-2.3125-0.55469h-1.4844z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
+   <path id="path3783" d="m1014-77.172v-11.422h1.3281v11.422z" fill="#fff" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/>
   </g>
+ </g>
+ <g id="layer1-3" transform="translate(-279.71 93.814)" data-name="layer1">
+  <g id="g70-3" data-name="g70">
+   <path id="path3055-3" class="cls-11" d="m1150.2 328.44a4.79 4.79 0 0 0-1.82 0.46l-24.77 11.83a4.71 4.71 0 0 0-2.56 3.19l-6.1 26.59a4.66 4.66 0 0 0 0.65 3.6 3.28 3.28 0 0 0 0.27 0.38l17.08 21.32a4.75 4.75 0 0 0 3.71 1.76h27.5a4.74 4.74 0 0 0 3.7-1.77l17.14-21.32a4.68 4.68 0 0 0 0.92-4l-6.13-26.58a4.69 4.69 0 0 0-2.56-3.19l-24.77-11.83a4.82 4.82 0 0 0-2.26-0.44z" data-name="path3055"/>
+   <path id="path3054-2-9-3" class="cls-13" d="m1150.2 326.51a5.09 5.09 0 0 0-1.91 0.49l-26.15 12.49a5 5 0 0 0-2.71 3.37l-6.46 28.07a4.9 4.9 0 0 0 0.68 3.8c0.09 0.14 0.18 0.27 0.28 0.4l18.1 22.5a5 5 0 0 0 3.91 1.87h29a5 5 0 0 0 3.91-1.86l18.1-22.51a5 5 0 0 0 1-4.2l-6.46-28.07a5 5 0 0 0-2.7-3.36l-26.16-12.5a5.07 5.07 0 0 0-2.43-0.49zm0 1.93a4.76 4.76 0 0 1 2.29 0.46l24.78 11.83a4.69 4.69 0 0 1 2.56 3.19l6.13 26.59a4.66 4.66 0 0 1-0.92 4l-17.07 21.29a4.74 4.74 0 0 1-3.7 1.77h-27.5a4.76 4.76 0 0 1-3.71-1.77l-17.14-21.32a3.28 3.28 0 0 1-0.27-0.38 4.66 4.66 0 0 1-0.65-3.6l6.12-26.59a4.69 4.69 0 0 1 2.56-3.18l24.77-11.84a4.79 4.79 0 0 1 1.82-0.46z" data-name="path3054-2-9"/>
+  </g>
+  <g id="text2066-3" class="cls-14" data-name="text2066">
+   <text id="text149" class="cls-15" transform="translate(1130.9 391.73)">k-proxy</text>
+  </g>
+  <path id="path1994-3" class="cls-13" d="m1150.4 338.69c-0.58 0-16.66 7.89-16.87 8.29-0.51 1-4.17 17.86-4 18.23 0.12 0.21 2.76 3.55 5.85 7.42l5.63 7h18.53l5.9-7.37 5.89-7.36-2.06-9c-1.13-5-2.15-9.13-2.25-9.23-0.29-0.28-16.36-8-16.67-8zm0.82 3.95 3.79 1.1-3.79 1.1-3.79-1.1zm-3.79 1.52 3.55 1.06v4.93l-3.53-2zm7.58 0v4l-3.53 2v-4.93zm-9.17 6.73 3.79 1.1-3.79 1.1-3.79-1.1zm9.22 0 3.79 1.1-3.79 1.1-3.8-1.1zm-13 1.52 3.55 1.06v4.93l-3.54-1.95zm7.58 0v4l-3.53 1.95v-4.93zm1.63 0 3.55 1.06v4.93l-3.53-1.95zm7.59 0v4l-3.53 1.95v-4.93zm-14.39 6.32c1.13 0 0.25 1.18 1.54 1.79s1.64-1 2.5 0.26-0.76 0.93-0.64 2.44 1.67 0.94 1 2.31-1.19-0.2-2.43 0.66 0 1.92-1.48 2-0.43-1.13-1.79-1.78-1.65 1-2.51-0.27 0.76-0.93 0.64-2.43-1.67-0.94-1-2.31 1.19 0.2 2.43-0.66 0-1.92 1.49-2zm9.74 1.52c2 0.05 0.06 1.95 1.9 2.77s2-1.89 3.34-0.43-1.34 1.42-0.62 3.31 2.72 0 2.66 2.05-2 0.06-2.77 1.9 1.89 1.95 0.43 3.34-1.42-1.34-3.3-0.62 0 2.72-2.06 2.66-0.06-2-1.9-2.77-2 1.89-3.34 0.43 1.34-1.42 0.62-3.31-2.72 0-2.66-2.05 2-0.06 2.77-1.9-1.89-1.95-0.43-3.34 1.42 1.34 3.31 0.62 0.02-2.72 2.04-2.66zm-9.65 1.05a2.22 2.22 0 1 0 2.22 2.22 2.22 2.22 0 0 0-2.23-2.22zm9.44 2a4.43 4.43 0 1 0 4.43 4.43 4.43 4.43 0 0 0-4.45-4.42z" data-name="path1994"/>
+ </g>
+ <g id="layer1-6" transform="translate(-279.73 93.814)" data-name="layer1">
+  <g id="g70-6" data-name="g70">
+   <path id="path3055-6" class="cls-11" d="m1150.3 239.22a4.45 4.45 0 0 0-1.72 0.43l-23.45 11.21a4.46 4.46 0 0 0-2.43 3l-5.78 25.17a4.45 4.45 0 0 0 0.6 3.41c0.08 0.12 0.17 0.24 0.26 0.35l16.26 20.21a4.53 4.53 0 0 0 3.51 1.67h26a4.46 4.46 0 0 0 3.49-1.67l16.23-20.18a4.42 4.42 0 0 0 0.86-3.77l-5.79-25.17a4.46 4.46 0 0 0-2.43-3l-23.45-11.2a4.56 4.56 0 0 0-2.16-0.46z" data-name="path3055"/>
+   <path id="path3054-2-9-6" class="cls-13" d="m1150.2 237.39a4.71 4.71 0 0 0-1.81 0.47l-24.76 11.82a4.72 4.72 0 0 0-2.57 3.19l-6.1 26.57a4.62 4.62 0 0 0 0.64 3.6 3.28 3.28 0 0 0 0.27 0.38l17.13 21.31a4.78 4.78 0 0 0 3.71 1.76h27.48a4.74 4.74 0 0 0 3.7-1.77l17.13-21.31a4.66 4.66 0 0 0 0.92-4l-6.12-26.58a4.69 4.69 0 0 0-2.56-3.18l-24.76-11.83a4.82 4.82 0 0 0-2.3-0.43zm0 1.83a4.56 4.56 0 0 1 2.18 0.43l23.45 11.2a4.46 4.46 0 0 1 2.43 3l5.79 25.17a4.42 4.42 0 0 1-0.86 3.77l-16.24 20.21a4.5 4.5 0 0 1-3.51 1.68h-26a4.49 4.49 0 0 1-3.49-1.68l-16.23-20.19c-0.09-0.11-0.18-0.23-0.26-0.35a4.41 4.41 0 0 1-0.6-3.41l5.78-25.17a4.48 4.48 0 0 1 2.43-3l23.45-11.21a4.45 4.45 0 0 1 1.72-0.43z" data-name="path3054-2-9"/>
+  </g>
+  <g id="text2066-6" class="cls-14" data-name="text2066">
+   <text id="text173" class="cls-16" transform="translate(1132.2 299.14)">kubelet</text>
+  </g>
+  <path id="path1994-6" class="cls-13" d="m1150.4 248.92c-0.54 0-15.77 7.47-16 7.85-0.48 0.93-4 16.91-3.74 17.25s2.61 3.37 5.54 7l5.33 6.67h17.55l11.16-14-2-8.56c-1.08-4.71-2-8.64-2.14-8.74-0.27-0.26-15.48-7.55-15.78-7.56zm0.78 3.74 3.59 1-3.59 1-3.59-1zm-3.59 1.44 3.36 1v4.67l-3.34-1.85zm7.18 0v3.82l-3.35 1.85v-4.67zm-8.68 6.38 3.59 1-3.59 1-3.59-1zm8.72 0 3.59 1-3.59 1-3.59-1zm-12.31 1.43 3.36 1v4.68l-3.35-1.86zm7.18 0v3.82l-3.34 1.86v-4.68zm1.54 0 3.36 1v4.68l-3.35-1.86zm7.18 0v3.82l-3.34 1.86v-4.68zm-13.62 6c1.07 0 0.24 1.11 1.45 1.69s1.57-0.93 2.38 0.25-0.73 0.88-0.61 2.31 1.58 0.89 1 2.18-1.13-0.19-2.31 0.62 0 1.82-1.4 1.94-0.4-1.07-1.7-1.69-1.56 0.93-2.37-0.25 0.73-0.88 0.61-2.31-1.58-0.88-1-2.18 1.13 0.19 2.31-0.62 0-1.82 1.4-1.94zm9.22 1.43c1.91 0.05 0.06 1.85 1.8 2.63s1.85-1.8 3.16-0.41-1.26 1.34-0.58 3.13 2.57 0 2.52 1.94-1.85 0.06-2.63 1.8 1.8 1.85 0.41 3.16-1.35-1.26-3.13-0.58 0 2.57-2 2.52 0-1.85-1.8-2.63-1.84 1.8-3.15 0.41 1.26-1.34 0.58-3.13-2.57 0-2.52-1.94 1.84-0.06 2.62-1.81-1.79-1.84-0.4-3.15 1.34 1.26 3.13 0.58 0.08-2.58 1.97-2.53zm-9.14 1a2.1 2.1 0 1 0 2.1 2.1 2.1 2.1 0 0 0-2.1-2.11zm8.94 1.9a4.2 4.2 0 1 0 4.2 4.19 4.2 4.2 0 0 0-4.2-4.2z" data-name="path1994"/>
+ </g>
+ <g id="g1954" transform="translate(-123.82 -40.997)">
+  <path id="path108" class="cls-4" d="m380.16 400h70v70.14h-70z"/>
+  <g id="layer1-7" transform="translate(-31.839)" data-name="layer1">
+   <g id="g70-7" data-name="g70">
+    <path id="path3055-7" class="cls-11" d="m446.67 398.6a4.4 4.4 0 0 0-1.67 0.4l-23.39 11.14a4.41 4.41 0 0 0-2.41 3l-5.77 25a4.4 4.4 0 0 0 0.6 3.39l0.26 0.36 16.14 20.11a4.5 4.5 0 0 0 3.5 1.66h25.95a4.5 4.5 0 0 0 3.5-1.66l16.18-20.06a4.38 4.38 0 0 0 0.86-3.74l-5.78-25a4.41 4.41 0 0 0-2.42-3l-23.38-11.2a4.52 4.52 0 0 0-2.17-0.4z" data-name="path3055"/>
+    <path id="path3054-2-9-7" class="cls-13" d="m446.66 396.79a4.75 4.75 0 0 0-1.81 0.46l-24.68 11.75a4.66 4.66 0 0 0-2.56 3.16l-6.09 26.41a4.66 4.66 0 0 0 0.64 3.58l0.27 0.37 17.09 21.17a4.72 4.72 0 0 0 3.69 1.75h27.4a4.78 4.78 0 0 0 3.69-1.75l17.07-21.18a4.62 4.62 0 0 0 0.92-3.95l-6.1-26.4a4.69 4.69 0 0 0-2.55-3.17l-24.64-11.75a4.75 4.75 0 0 0-2.34-0.45zm0 1.81a4.52 4.52 0 0 1 2.17 0.43l23.38 11.13a4.41 4.41 0 0 1 2.42 3l5.78 25a4.38 4.38 0 0 1-0.86 3.74l-16.17 20.1a4.5 4.5 0 0 1-3.5 1.66h-25.95a4.5 4.5 0 0 1-3.5-1.66l-16.18-20.05c-0.09-0.12-0.18-0.23-0.26-0.36a4.38 4.38 0 0 1-0.6-3.38l5.76-25a4.45 4.45 0 0 1 2.42-3l23.43-11.21a4.59 4.59 0 0 1 1.71-0.43z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-7" class="cls-14" data-name="text2066">
+    <text id="text181" class="cls-17" transform="translate(432.3,458.13)">sched</text>
+   </g>
+   <path id="path1984" class="cls-13" d="m446.83 409.62c-0.54 0-15.73 7.42-15.92 7.81-0.48 0.91-3.94 16.79-3.73 17.14s2.6 3.34 5.53 7l5.31 6.63h17.49l5.56-6.92 5.57-6.93-1.95-8.51c-1.07-4.68-2-8.59-2.12-8.68-0.28-0.26-15.44-7.51-15.74-7.52zm0.93 7.78c0.74 0 0.81 1.15 2.39 1.26 2.05 0.16 1.83-1.75 3.4-0.42s-0.35 1.42 0.14 3.41 2.24 1.2 1.46 3.1-1.47 0.11-3.22 1.19-0.45 2.49-2.51 2.34-0.55-1.36-2.12-2.69-2.52 0.34-3-1.65 1.13-0.95 1.91-2.84-1.11-2.28 0.64-3.36a2.41 2.41 0 0 1 0.56-0.28 1 1 0 0 1 0.36-0.06zm2.06 2.25a2.88 2.88 0 0 0-0.88 0.12 3 3 0 1 0 0.88-0.12zm-11.82 5.1a2.68 2.68 0 0 1 0.59 0.11c1.89 0.58 0 1.57 1.31 3s2.48-0.4 2.92 1.52-1.38 0.76-2 2.64 1.58 1.94 0.13 3.28-1.35-0.81-3.27-0.36-0.9 2.33-2.79 1.75 0-1.57-1.31-3-2.48 0.4-2.92-1.52 1.38-0.76 2-2.64-1.58-1.94-0.14-3.28 1.35 0.81 3.28 0.37c1.68-0.39 1.1-1.89 2.19-1.87zm14.05 2.06a1.87 1.87 0 0 1 0.67 0.16c2.18 0.84-0.69 2.14 1 3.75s2.86-1.31 3.8 0.82-2 1-1.95 3.36 2.95 1.09 2.1 3.26-2.15-0.68-3.76 1 1.31 2.85-0.83 3.79-1-2-3.37-1.95-1.1 2.94-3.27 2.1 0.69-2.14-1-3.75-2.87 1.3-3.81-0.83 2-1 2-3.35-2.95-1.1-2.11-3.27 2.15 0.69 3.77-1-1.31-2.86 0.82-3.8 1 2 3.37 1.95c2 0 1.35-2.26 2.61-2.25zm-15.28 1a3 3 0 1 0 3 3 3 3 0 0 0-2.97-3zm12.81 2.85a4.38 4.38 0 1 0 4.42 4.34 4.38 4.38 0 0 0-4.39-4.34z"/>
+  </g>
+  <g id="layer1-8" transform="translate(-31.839)" data-name="layer1">
+   <g id="g70-8" data-name="g70">
+    <path id="path3055-8" class="cls-11" d="m456.51 406.53a4.54 4.54 0 0 0-1.71 0.43l-23.39 11.14a4.45 4.45 0 0 0-2.42 3l-5.76 25a4.38 4.38 0 0 0 0.6 3.38c0.08 0.13 0.17 0.24 0.26 0.36l16.18 20a4.5 4.5 0 0 0 3.5 1.66h26a4.5 4.5 0 0 0 3.5-1.66l16.18-20.06a4.42 4.42 0 0 0 0.86-3.74l-5.78-25a4.41 4.41 0 0 0-2.42-3l-23.43-11.04a4.52 4.52 0 0 0-2.17-0.47z" data-name="path3055"/>
+    <path id="path3054-2-9-8" class="cls-13" d="m456.5 404.72a4.75 4.75 0 0 0-1.81 0.46l-24.69 11.75a4.67 4.67 0 0 0-2.55 3.16l-6.09 26.41a4.66 4.66 0 0 0 0.64 3.58c0.09 0.12 0.17 0.25 0.27 0.37l17.09 21.17a4.72 4.72 0 0 0 3.69 1.75h27.39a4.75 4.75 0 0 0 3.69-1.75l17.08-21.18a4.65 4.65 0 0 0 0.92-3.95l-6.1-26.4a4.66 4.66 0 0 0-2.56-3.16l-24.68-11.76a4.77 4.77 0 0 0-2.29-0.45zm0 1.81a4.52 4.52 0 0 1 2.17 0.43l23.38 11.13a4.41 4.41 0 0 1 2.42 3l5.78 25a4.39 4.39 0 0 1-0.87 3.74l-16.16 20.07a4.5 4.5 0 0 1-3.5 1.66h-26a4.51 4.51 0 0 1-3.5-1.67l-16.18-20c-0.09-0.12-0.18-0.23-0.26-0.35a4.42 4.42 0 0 1-0.61-3.39l5.77-25a4.44 4.44 0 0 1 2.42-3l23.44-11.15a4.54 4.54 0 0 1 1.71-0.43z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-8" class="cls-14" data-name="text2066">
+    <text id="text189" class="cls-17" transform="translate(442.14,466.07)">sched</text>
+   </g>
+   <path id="path1984-2" class="cls-13" d="m456.67 417.55c-0.54 0-15.73 7.43-15.93 7.81-0.47 0.91-3.93 16.8-3.72 17.14s2.6 3.34 5.53 7l5.31 6.63h17.49l5.56-6.92 5.57-6.93-2-8.51c-1.07-4.68-2-8.58-2.13-8.68-0.27-0.26-15.43-7.51-15.73-7.52zm0.93 7.78c0.74 0 0.81 1.15 2.38 1.26 2.06 0.16 1.84-1.75 3.41-0.42s-0.35 1.42 0.14 3.41 2.23 1.2 1.45 3.1-1.46 0.11-3.21 1.19-0.46 2.49-2.51 2.34-0.55-1.36-2.12-2.69-2.52 0.34-3-1.65 1.12-0.94 1.91-2.84-1.11-2.28 0.64-3.36a2.41 2.41 0 0 1 0.56-0.28 1.34 1.34 0 0 1 0.36-0.06zm2 2.25a3 3 0 1 0 2.84 2.11 3 3 0 0 0-2.79-2.11zm-11.78 5.1a2.68 2.68 0 0 1 0.59 0.11c1.89 0.58 0 1.57 1.31 3s2.48-0.4 2.92 1.52-1.38 0.76-2 2.64 1.58 1.94 0.14 3.28-1.35-0.8-3.27-0.36-0.9 2.33-2.79 1.75 0-1.56-1.31-3-2.48 0.4-2.92-1.52 1.38-0.76 2-2.64-1.59-1.94-0.14-3.28 1.35 0.81 3.27 0.37c1.69-0.39 1.11-1.88 2.2-1.87zm14.05 2.06a1.87 1.87 0 0 1 0.67 0.16c2.17 0.84-0.69 2.14 1 3.75s2.87-1.31 3.81 0.82-2 1-2 3.36 2.95 1.09 2.11 3.26-2.15-0.68-3.76 1 1.3 2.85-0.83 3.79-1-2-3.37-1.95-1.1 2.94-3.28 2.1 0.69-2.14-1-3.75-2.86 1.3-3.8-0.83 2-1 2-3.35-3-1.1-2.11-3.27 2.15 0.69 3.77-1-1.31-2.86 0.82-3.8 1 2 3.37 1.95c2 0 1.35-2.26 2.61-2.25zm-15.28 1a3 3 0 1 0 3 3 3 3 0 0 0-2.95-3zm12.8 2.85a4.38 4.38 0 1 0 4.4 4.37 4.39 4.39 0 0 0-4.35-4.37z" data-name="path1984"/>
+  </g>
+  <g id="layer1-9" transform="translate(-31.839)" data-name="layer1">
+   <g id="g70-9" data-name="g70">
+    <path id="path3055-9" class="cls-11" d="m465.45 413.24a4.4 4.4 0 0 0-1.71 0.43l-23.38 11.13a4.43 4.43 0 0 0-2.42 3l-5.77 25a4.36 4.36 0 0 0 0.61 3.39 2.8 2.8 0 0 0 0.25 0.35l16.18 20.06a4.5 4.5 0 0 0 3.5 1.66h26a4.5 4.5 0 0 0 3.5-1.66l16.18-20.06a4.35 4.35 0 0 0 0.86-3.74l-5.77-25a4.44 4.44 0 0 0-2.42-3l-23.39-11.13a4.49 4.49 0 0 0-2.22-0.43z" data-name="path3055"/>
+    <path id="path3054-2-9-9" class="cls-13" d="m465.44 411.43a4.73 4.73 0 0 0-1.81 0.45l-24.63 11.76a4.66 4.66 0 0 0-2.56 3.16l-6.09 26.4a4.65 4.65 0 0 0 0.64 3.58l0.27 0.37 17.09 21.18a4.72 4.72 0 0 0 3.69 1.75h27.4a4.76 4.76 0 0 0 3.69-1.76l17.08-21.17a4.64 4.64 0 0 0 0.91-3.95l-6.12-26.4a4.69 4.69 0 0 0-2.55-3.17l-24.69-11.75a4.75 4.75 0 0 0-2.32-0.45zm0 1.81a4.52 4.52 0 0 1 2.17 0.43l23.39 11.13a4.42 4.42 0 0 1 2.41 3l5.78 25a4.35 4.35 0 0 1-0.86 3.74l-16.18 20.06a4.5 4.5 0 0 1-3.5 1.66h-26a4.5 4.5 0 0 1-3.5-1.66l-16.15-20.05c-0.09-0.11-0.18-0.23-0.26-0.35a4.4 4.4 0 0 1-0.6-3.39l5.77-25a4.43 4.43 0 0 1 2.42-3l23.38-11.13a4.4 4.4 0 0 1 1.71-0.43z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-9" class="cls-14" data-name="text2066">
+    <text id="text197" class="cls-17" transform="translate(451.08,472.77)">sched</text>
+   </g>
+   <path id="path1984-3" class="cls-13" d="m465.61 424.26c-0.54 0-15.72 7.42-15.92 7.8-0.48 0.92-3.93 16.8-3.73 17.14s2.61 3.35 5.53 7l5.31 6.62h17.49l5.57-6.93 5.56-6.92-1.95-8.51c-1.07-4.68-2-8.59-2.12-8.68-0.28-0.26-15.44-7.51-15.74-7.52zm0.93 7.78c0.74 0 0.81 1.14 2.39 1.26 2.05 0.15 1.83-1.75 3.4-0.43s-0.35 1.43 0.14 3.42 2.24 1.2 1.46 3.1-1.47 0.1-3.22 1.18-0.45 2.5-2.51 2.34-0.55-1.35-2.12-2.68-2.52 0.34-3-1.65 1.13-0.95 1.91-2.85-1.11-2.28 0.64-3.36a2.78 2.78 0 0 1 0.56-0.27 1 1 0 0 1 0.36-0.06zm2.06 2.24a2.89 2.89 0 0 0-0.88 0.13 3 3 0 1 0 0.88-0.13zm-11.78 5.11a2.21 2.21 0 0 1 0.58 0.11c1.89 0.58 0 1.57 1.32 3s2.47-0.4 2.91 1.52-1.37 0.76-1.95 2.64 1.58 1.94 0.13 3.28-1.34-0.81-3.27-0.37-0.89 2.34-2.78 1.76 0-1.57-1.32-3-2.47 0.4-2.92-1.52 1.38-0.76 2-2.64-1.58-1.94-0.14-3.28 1.35 0.81 3.28 0.36c1.68-0.38 1.1-1.88 2.2-1.86zm14 2.06a2 2 0 0 1 0.67 0.15c2.18 0.85-0.69 2.15 1 3.75s2.86-1.3 3.8 0.83-2 1-1.95 3.36 2.95 1.09 2.1 3.26-2.15-0.69-3.76 1 1.31 2.85-0.83 3.79-1-2-3.37-1.95-1.1 2.94-3.27 2.1 0.69-2.15-1-3.75-2.86 1.3-3.81-0.83 2-1 2-3.36-2.95-1.09-2.11-3.26 2.15 0.69 3.77-1-1.31-2.85 0.83-3.79 1 2 3.36 1.95c2.05-0.05 1.36-2.26 2.61-2.25zm-15.28 1a3 3 0 1 0 3 3 3 3 0 0 0-2.96-3zm12.81 2.85a4.38 4.38 0 1 0 4.39 4.37 4.37 4.37 0 0 0-4.35-4.37z" data-name="path1984"/>
+  </g>
+ </g>
+ <text id="text255" class="cls-22" x="216.71268" y="485.55911" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1053" font-family="'Open Sans'" font-size="14.667px" font-weight="bold" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Control Plane</tspan></text>
+ <text id="text257" class="cls-22" x="549.05597" y="275.27713" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1312" font-family="'Open Sans'" font-size="14.667px" font-weight="bold" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Node</tspan></text>
+ <text id="text259" x="-123.81744" y="664.74402"/>
+ <g id="layer1-15" transform="translate(-151.54 -61.332)" data-name="layer1">
+  <g id="g70-16" data-name="g70">
+   <path id="path3055-16" class="cls-11" d="m276.45 411.42a4.3 4.3 0 0 0-1.63 0.32l-22.3 9a4 4 0 0 0-2.37 2.55l-6.15 21.76a3.65 3.65 0 0 0 0.48 3 3.46 3.46 0 0 0 0.22 0.31l14.64 18.08a4.36 4.36 0 0 0 3.23 1.57l24.41 0.8a4.35 4.35 0 0 0 3.33-1.35l15.79-17.06a3.67 3.67 0 0 0 0.93-3.25l-4.71-22.09a4 4 0 0 0-2.19-2.71l-21.66-10.48a4.51 4.51 0 0 0-2.02-0.45z" data-name="path3055"/>
+   <path id="path3054-2-9-16" class="cls-13" d="m276.49 409.83a4.7 4.7 0 0 0-1.71 0.35l-23.56 9.52a4.18 4.18 0 0 0-2.49 2.69l-6.49 22.94a3.85 3.85 0 0 0 0.5 3.16 2 2 0 0 0 0.24 0.33l15.45 19.09a4.59 4.59 0 0 0 3.41 1.65l25.76 0.85a4.62 4.62 0 0 0 3.52-1.42l16.68-18a3.86 3.86 0 0 0 1-3.43l-5-23.32a4.17 4.17 0 0 0-2.31-2.85l-22.86-11.09a4.78 4.78 0 0 0-2.14-0.47zm0 1.59a4.51 4.51 0 0 1 2 0.44l21.66 10.48a4 4 0 0 1 2.19 2.71l4.7 22.09a3.63 3.63 0 0 1-0.92 3.25l-15.79 17.07a4.38 4.38 0 0 1-3.33 1.34l-24.4-0.8a4.34 4.34 0 0 1-3.23-1.57l-14.67-18.08-0.23-0.31a3.69 3.69 0 0 1-0.47-3l6.15-21.73a4 4 0 0 1 2.36-2.55l22.31-9a4.73 4.73 0 0 1 1.63-0.32z" data-name="path3054-2-9"/>
+  </g>
+  <g id="text2066-16" class="cls-14" data-name="text2066">
+   <text id="text264" class="cls-23" transform="matrix(1.0794 .035808 -.033155 .99945 265.24 463.26)">etcd</text>
+  </g>
+  <path id="path2078" class="cls-13" d="m276.28 421.08c-0.51 0-15 6-15.2 6.34-0.48 0.79-4.19 14.59-4 14.9s2.36 3 5 6.29l4.8 6 8.22 0.28 8.23 0.27 5.43-5.89 5.43-5.9-1.58-7.51c-0.87-4.14-1.66-7.59-1.75-7.67-0.25-0.24-14.29-7.06-14.57-7.08z"/>
+  <path id="path4590" class="cls-11" d="m291.05 440.37h-0.46a6.3 6.3 0 0 1-2.62-0.66 21 21 0 0 0 0.5-4.32 23.86 23.86 0 0 0-2.91-3.42 5.77 5.77 0 0 1 2.2-2l0.4-0.21-0.3-0.33a15.84 15.84 0 0 0-5.42-3.94l-0.42-0.19-0.12 0.41a5.43 5.43 0 0 1-1.58 2.49 25.41 25.41 0 0 0-4.3-1.81 25 25 0 0 0-4.39 1.52 5.44 5.44 0 0 1-1.42-2.58l-0.09-0.42-0.43 0.16a16 16 0 0 0-5.69 3.53l-0.31 0.31 0.38 0.23a5.7 5.7 0 0 1 2.05 2.18 23.53 23.53 0 0 0-3.12 3.2 21.37 21.37 0 0 0 0.2 4.37 6.36 6.36 0 0 1-2.64 0.48 3.44 3.44 0 0 1-0.46 0h-0.45v0.43a13.9 13.9 0 0 0 1.93 6.13l0.22 0.38 0.36-0.27a6.23 6.23 0 0 1 2.86-1.13 22.92 22.92 0 0 0 2.3 3.74 26.46 26.46 0 0 0 4.55 1.2 5.11 5.11 0 0 1-0.48 2.89l-0.18 0.39 0.44 0.11a16.83 16.83 0 0 0 3.43 0.46l3.44-0.24 0.45-0.07-0.16-0.4a5.15 5.15 0 0 1-0.28-2.92 25.82 25.82 0 0 0 4.6-0.9 21.72 21.72 0 0 0 2.54-3.58 6.07 6.07 0 0 1 2.8 1.33l0.34 0.28 0.25-0.36a13.91 13.91 0 0 0 2.33-6l0.06-0.42zm-10.73 4.83a20 20 0 0 1-9.83-0.33 17.16 17.16 0 0 1-2-4.18 16.22 16.22 0 0 1-0.74-4.55 18.44 18.44 0 0 1 3.67-3 19.34 19.34 0 0 1 4.42-2.05 19.57 19.57 0 0 1 4.26 2.34 18.38 18.38 0 0 1 3.48 3.29 16.19 16.19 0 0 1-1.05 4.47 17.09 17.09 0 0 1-2.21 4.01zm-3.32-7.39a2.08 2.08 0 0 0 4.15 0.14 2.08 2.08 0 0 0-4.15-0.14zm-2.69-0.09a2.08 2.08 0 1 1-2-2 2 2 0 0 1 2 2z"/>
+ </g>
+ <text id="text274" class="cls-22" x="480.11725" y="47.03083" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1314" fill="#ffffff" font-family="'Open Sans'" font-size="21.333px" font-weight="bold">Kubernetes cluster</tspan></text>
+ <g id="g2018" transform="translate(-123.82 -40.997)">
+  <g id="layer1-10-1" transform="translate(-42.645 -4.995)" data-name="layer1">
+   <g id="g70-10-2" data-name="g70">
+    <path id="path3055-10-5" class="cls-11" d="m463.61 257.22a4.39 4.39 0 0 0-1.6 0.4l-21.81 10.43a4.15 4.15 0 0 0-2.26 2.8l-5.38 23.41a4.12 4.12 0 0 0 0.57 3.17 3.43 3.43 0 0 0 0.24 0.33l15.09 18.77a4.19 4.19 0 0 0 3.26 1.55h24.21a4.19 4.19 0 0 0 3.26-1.55l15.09-18.78a4.12 4.12 0 0 0 0.81-3.5l-5.39-23.4a4.16 4.16 0 0 0-2.26-2.81l-21.81-10.42a4.16 4.16 0 0 0-2.02-0.4z" data-name="path3055"/>
+    <path id="path3054-2-9-10-7" class="cls-13" d="m463.6 255.53a4.48 4.48 0 0 0-1.69 0.42l-23 11a4.39 4.39 0 0 0-2.39 3l-5.68 24.71a4.33 4.33 0 0 0 0.6 3.34c0.08 0.12 0.16 0.24 0.25 0.35l15.94 19.82a4.43 4.43 0 0 0 3.44 1.64h25.53a4.43 4.43 0 0 0 3.45-1.64l15.95-19.85a4.39 4.39 0 0 0 0.85-3.7l-5.69-24.71a4.41 4.41 0 0 0-2.38-3l-23-11a4.35 4.35 0 0 0-2.18-0.38zm0 1.69a4.17 4.17 0 0 1 2 0.41l21.84 10.37a4.19 4.19 0 0 1 2.26 2.81l5.39 23.4a4.12 4.12 0 0 1-0.81 3.5l-15.09 18.78a4.19 4.19 0 0 1-3.26 1.55h-24.21a4.19 4.19 0 0 1-3.26-1.56l-15.09-18.77a3.43 3.43 0 0 1-0.24-0.33 4.12 4.12 0 0 1-0.57-3.17l5.38-23.41a4.17 4.17 0 0 1 2.26-2.8l21.8-10.37a4.21 4.21 0 0 1 1.6-0.41z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-10-2" class="cls-14" data-name="text2066">
+    <text id="text205-6" class="cls-18" transform="translate(457.08,312.94)">api</text>
+   </g>
+   <path id="path1984-4-0" class="cls-13" d="m463.76 267.54c-0.51 0-14.67 6.94-14.86 7.3-0.44 0.86-3.66 15.72-3.47 16s2.43 3.13 5.15 6.54l5 6.2h16.31l5.19-6.49 5.19-6.48-1.81-8c-1-4.38-1.9-8-2-8.13-0.25-0.24-14.4-7-14.67-7zm0.87 7.28c0.68 0 0.75 1.07 2.22 1.18 1.91 0.14 1.71-1.64 3.17-0.4s-0.32 1.33 0.13 3.2 2.09 1.12 1.36 2.89-1.37 0.1-3 1.11-0.42 2.34-2.34 2.19-0.51-1.27-2-2.51-2.35 0.32-2.8-1.54 1.05-0.89 1.78-2.67-1-2.13 0.6-3.14a2.28 2.28 0 0 1 0.52-0.26 0.88 0.88 0 0 1 0.34-0.05zm1.91 2.1a2.86 2.86 0 0 0-0.82 0.12 2.77 2.77 0 1 0 0.82-0.12zm-11 4.78a1.84 1.84 0 0 1 0.55 0.1c1.76 0.54 0 1.47 1.22 2.81s2.31-0.37 2.73 1.43-1.29 0.71-1.83 2.47 1.47 1.81 0.13 3.07-1.26-0.76-3.06-0.34-0.83 2.18-2.59 1.64 0-1.47-1.23-2.82-2.31 0.37-2.72-1.42 1.29-0.71 1.83-2.47-1.48-1.82-0.13-3.07 1.26 0.75 3.05 0.34c1.57-0.36 1-1.76 2.05-1.74zm13.1 1.92a2.08 2.08 0 0 1 0.63 0.15c2 0.79-0.65 2 0.93 3.51s2.67-1.22 3.55 0.77-1.88 1-1.83 3.14 2.75 1 2 3.06-2-0.65-3.51 0.93 1.21 2.67-0.78 3.55-1-1.87-3.14-1.83-1 2.75-3.05 2 0.64-2-0.94-3.51-2.67 1.22-3.54-0.78 1.87-1 1.82-3.14-2.75-1-2-3.05 2 0.64 3.51-0.93-1.22-2.67 0.77-3.55 1 1.87 3.14 1.82c1.91 0 1.26-2.12 2.43-2.11zm-14.25 0.94a2.78 2.78 0 1 0 2.78 2.78 2.77 2.77 0 0 0-2.77-2.78zm12 2.66a4.1 4.1 0 1 0 4.09 4.1 4.1 4.1 0 0 0-4.13-4.1z" data-name="path1984"/>
+  </g>
+  <g id="layer1-10" transform="translate(-33.895 4.515)" data-name="layer1">
+   <g id="g70-10" data-name="g70">
+    <path id="path3055-10" class="cls-11" d="m463.61 257.22a4.39 4.39 0 0 0-1.6 0.4l-21.81 10.43a4.15 4.15 0 0 0-2.26 2.8l-5.38 23.41a4.12 4.12 0 0 0 0.57 3.17 3.43 3.43 0 0 0 0.24 0.33l15.09 18.77a4.19 4.19 0 0 0 3.26 1.55h24.21a4.19 4.19 0 0 0 3.26-1.55l15.09-18.78a4.12 4.12 0 0 0 0.81-3.5l-5.39-23.4a4.16 4.16 0 0 0-2.26-2.81l-21.81-10.42a4.16 4.16 0 0 0-2.02-0.4z" data-name="path3055"/>
+    <path id="path3054-2-9-10" class="cls-13" d="m463.6 255.53a4.48 4.48 0 0 0-1.69 0.42l-23 11a4.39 4.39 0 0 0-2.39 3l-5.68 24.71a4.33 4.33 0 0 0 0.6 3.34c0.08 0.12 0.16 0.24 0.25 0.35l15.94 19.82a4.43 4.43 0 0 0 3.44 1.64h25.53a4.43 4.43 0 0 0 3.45-1.64l15.95-19.85a4.39 4.39 0 0 0 0.85-3.7l-5.69-24.71a4.41 4.41 0 0 0-2.38-3l-23-11a4.35 4.35 0 0 0-2.18-0.38zm0 1.69a4.17 4.17 0 0 1 2 0.41l21.84 10.37a4.19 4.19 0 0 1 2.26 2.81l5.39 23.4a4.12 4.12 0 0 1-0.81 3.5l-15.09 18.78a4.19 4.19 0 0 1-3.26 1.55h-24.21a4.19 4.19 0 0 1-3.26-1.56l-15.09-18.77a3.43 3.43 0 0 1-0.24-0.33 4.12 4.12 0 0 1-0.57-3.17l5.38-23.41a4.17 4.17 0 0 1 2.26-2.8l21.8-10.37a4.21 4.21 0 0 1 1.6-0.41z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-10" class="cls-14" data-name="text2066">
+    <text id="text205" class="cls-18" transform="translate(457.08,312.94)">api</text>
+   </g>
+   <path id="path1984-4" class="cls-13" d="m463.76 267.54c-0.51 0-14.67 6.94-14.86 7.3-0.44 0.86-3.66 15.72-3.47 16s2.43 3.13 5.15 6.54l5 6.2h16.31l5.19-6.49 5.19-6.48-1.81-8c-1-4.38-1.9-8-2-8.13-0.25-0.24-14.4-7-14.67-7zm0.87 7.28c0.68 0 0.75 1.07 2.22 1.18 1.91 0.14 1.71-1.64 3.17-0.4s-0.32 1.33 0.13 3.2 2.09 1.12 1.36 2.89-1.37 0.1-3 1.11-0.42 2.34-2.34 2.19-0.51-1.27-2-2.51-2.35 0.32-2.8-1.54 1.05-0.89 1.78-2.67-1-2.13 0.6-3.14a2.28 2.28 0 0 1 0.52-0.26 0.88 0.88 0 0 1 0.34-0.05zm1.91 2.1a2.86 2.86 0 0 0-0.82 0.12 2.77 2.77 0 1 0 0.82-0.12zm-11 4.78a1.84 1.84 0 0 1 0.55 0.1c1.76 0.54 0 1.47 1.22 2.81s2.31-0.37 2.73 1.43-1.29 0.71-1.83 2.47 1.47 1.81 0.13 3.07-1.26-0.76-3.06-0.34-0.83 2.18-2.59 1.64 0-1.47-1.23-2.82-2.31 0.37-2.72-1.42 1.29-0.71 1.83-2.47-1.48-1.82-0.13-3.07 1.26 0.75 3.05 0.34c1.57-0.36 1-1.76 2.05-1.74zm13.1 1.92a2.08 2.08 0 0 1 0.63 0.15c2 0.79-0.65 2 0.93 3.51s2.67-1.22 3.55 0.77-1.88 1-1.83 3.14 2.75 1 2 3.06-2-0.65-3.51 0.93 1.21 2.67-0.78 3.55-1-1.87-3.14-1.83-1 2.75-3.05 2 0.64-2-0.94-3.51-2.67 1.22-3.54-0.78 1.87-1 1.82-3.14-2.75-1-2-3.05 2 0.64 3.51-0.93-1.22-2.67 0.77-3.55 1 1.87 3.14 1.82c1.91 0 1.26-2.12 2.43-2.11zm-14.25 0.94a2.78 2.78 0 1 0 2.78 2.78 2.77 2.77 0 0 0-2.77-2.78zm12 2.66a4.1 4.1 0 1 0 4.09 4.1 4.1 4.1 0 0 0-4.13-4.1z" data-name="path1984"/>
+  </g>
+  <g id="layer1-10-14" transform="translate(-25.145 14.025)" data-name="layer1">
+   <g id="g70-10-1" data-name="g70">
+    <path id="path3055-10-53" class="cls-11" d="m463.61 257.22a4.39 4.39 0 0 0-1.6 0.4l-21.81 10.43a4.15 4.15 0 0 0-2.26 2.8l-5.38 23.41a4.12 4.12 0 0 0 0.57 3.17 3.43 3.43 0 0 0 0.24 0.33l15.09 18.77a4.19 4.19 0 0 0 3.26 1.55h24.21a4.19 4.19 0 0 0 3.26-1.55l15.09-18.78a4.12 4.12 0 0 0 0.81-3.5l-5.39-23.4a4.16 4.16 0 0 0-2.26-2.81l-21.81-10.42a4.16 4.16 0 0 0-2.02-0.4z" data-name="path3055"/>
+    <path id="path3054-2-9-10-5" class="cls-13" d="m463.6 255.53a4.48 4.48 0 0 0-1.69 0.42l-23 11a4.39 4.39 0 0 0-2.39 3l-5.68 24.71a4.33 4.33 0 0 0 0.6 3.34c0.08 0.12 0.16 0.24 0.25 0.35l15.94 19.82a4.43 4.43 0 0 0 3.44 1.64h25.53a4.43 4.43 0 0 0 3.45-1.64l15.95-19.85a4.39 4.39 0 0 0 0.85-3.7l-5.69-24.71a4.41 4.41 0 0 0-2.38-3l-23-11a4.35 4.35 0 0 0-2.18-0.38zm0 1.69a4.17 4.17 0 0 1 2 0.41l21.84 10.37a4.19 4.19 0 0 1 2.26 2.81l5.39 23.4a4.12 4.12 0 0 1-0.81 3.5l-15.09 18.78a4.19 4.19 0 0 1-3.26 1.55h-24.21a4.19 4.19 0 0 1-3.26-1.56l-15.09-18.77a3.43 3.43 0 0 1-0.24-0.33 4.12 4.12 0 0 1-0.57-3.17l5.38-23.41a4.17 4.17 0 0 1 2.26-2.8l21.8-10.37a4.21 4.21 0 0 1 1.6-0.41z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-10-7" class="cls-14" data-name="text2066">
+    <text id="text205-7" class="cls-18" transform="translate(457.08,312.94)">api</text>
+   </g>
+   <path id="path1984-4-3" class="cls-13" d="m463.76 267.54c-0.51 0-14.67 6.94-14.86 7.3-0.44 0.86-3.66 15.72-3.47 16s2.43 3.13 5.15 6.54l5 6.2h16.31l5.19-6.49 5.19-6.48-1.81-8c-1-4.38-1.9-8-2-8.13-0.25-0.24-14.4-7-14.67-7zm0.87 7.28c0.68 0 0.75 1.07 2.22 1.18 1.91 0.14 1.71-1.64 3.17-0.4s-0.32 1.33 0.13 3.2 2.09 1.12 1.36 2.89-1.37 0.1-3 1.11-0.42 2.34-2.34 2.19-0.51-1.27-2-2.51-2.35 0.32-2.8-1.54 1.05-0.89 1.78-2.67-1-2.13 0.6-3.14a2.28 2.28 0 0 1 0.52-0.26 0.88 0.88 0 0 1 0.34-0.05zm1.91 2.1a2.86 2.86 0 0 0-0.82 0.12 2.77 2.77 0 1 0 0.82-0.12zm-11 4.78a1.84 1.84 0 0 1 0.55 0.1c1.76 0.54 0 1.47 1.22 2.81s2.31-0.37 2.73 1.43-1.29 0.71-1.83 2.47 1.47 1.81 0.13 3.07-1.26-0.76-3.06-0.34-0.83 2.18-2.59 1.64 0-1.47-1.23-2.82-2.31 0.37-2.72-1.42 1.29-0.71 1.83-2.47-1.48-1.82-0.13-3.07 1.26 0.75 3.05 0.34c1.57-0.36 1-1.76 2.05-1.74zm13.1 1.92a2.08 2.08 0 0 1 0.63 0.15c2 0.79-0.65 2 0.93 3.51s2.67-1.22 3.55 0.77-1.88 1-1.83 3.14 2.75 1 2 3.06-2-0.65-3.51 0.93 1.21 2.67-0.78 3.55-1-1.87-3.14-1.83-1 2.75-3.05 2 0.64-2-0.94-3.51-2.67 1.22-3.54-0.78 1.87-1 1.82-3.14-2.75-1-2-3.05 2 0.64 3.51-0.93-1.22-2.67 0.77-3.55 1 1.87 3.14 1.82c1.91 0 1.26-2.12 2.43-2.11zm-14.25 0.94a2.78 2.78 0 1 0 2.78 2.78 2.77 2.77 0 0 0-2.77-2.78zm12 2.66a4.1 4.1 0 1 0 4.09 4.1 4.1 4.1 0 0 0-4.13-4.1z" data-name="path1984"/>
+  </g>
+ </g>
+ <g id="g2066" transform="translate(-123.82 -40.997)">
+  <path id="path84" class="cls-4" d="m396.5 106.15h70v70.14h-70z"/>
+  <g id="layer1-11" transform="translate(-31.326 -2.8445)" data-name="layer1">
+   <g id="g70-11" data-name="g70">
+    <path id="path3055-11" class="cls-11" d="m462.48 109.72a4.33 4.33 0 0 0-1.65 0.42l-22.55 10.77a4.29 4.29 0 0 0-2.33 2.9l-5.56 24.19a4.22 4.22 0 0 0 0.59 3.28 2.62 2.62 0 0 0 0.24 0.34l15.61 19.38a4.29 4.29 0 0 0 3.37 1.61h25a4.34 4.34 0 0 0 3.37-1.6l15.6-19.41a4.22 4.22 0 0 0 0.83-3.6l-5.57-24.19a4.27 4.27 0 0 0-2.33-2.9l-22.55-10.77a4.31 4.31 0 0 0-2.07-0.42z" data-name="path3055"/>
+    <path id="path3054-2-9-11" class="cls-13" d="m462.47 108a4.56 4.56 0 0 0-1.74 0.44l-23.8 11.37a4.53 4.53 0 0 0-2.47 3.06l-5.87 25.55a4.49 4.49 0 0 0 0.62 3.46l0.26 0.36 16.47 20.48a4.57 4.57 0 0 0 3.56 1.7h26.42a4.56 4.56 0 0 0 3.56-1.69l16.46-20.49a4.44 4.44 0 0 0 0.88-3.81l-5.88-25.55a4.5 4.5 0 0 0-2.46-3.06l-23.8-11.37a4.57 4.57 0 0 0-2.21-0.45zm0 1.75a4.31 4.31 0 0 1 2.09 0.42l22.55 10.77a4.27 4.27 0 0 1 2.33 2.9l5.56 24.16a4.21 4.21 0 0 1-0.83 3.62l-15.58 19.38a4.31 4.31 0 0 1-3.37 1.6h-25a4.33 4.33 0 0 1-3.38-1.61l-15.6-19.4c-0.09-0.11-0.17-0.22-0.25-0.34a4.26 4.26 0 0 1-0.58-3.28l5.56-24.2a4.29 4.29 0 0 1 2.33-2.9l22.55-10.77a4.33 4.33 0 0 1 1.65-0.42z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-11" class="cls-14" data-name="text2066">
+    <text id="text213" class="cls-19" transform="translate(449.46,167.32)">c-c-m</text>
+   </g>
+   <path id="path1984-5" class="cls-13" d="m462.64 120.39c-0.53 0-15.17 7.18-15.36 7.55-0.46 0.88-3.79 16.25-3.59 16.58s2.51 3.23 5.33 6.76l5.12 6.4h16.86l5.36-6.7 5.37-6.7-1.88-8.23c-1-4.53-2-8.31-2.05-8.4-0.27-0.25-14.89-7.26-15.17-7.27zm0.9 7.52c0.7 0 0.78 1.11 2.29 1.22 2 0.15 1.77-1.69 3.28-0.41s-0.33 1.38 0.14 3.31 2.16 1.15 1.4 3-1.41 0.1-3.1 1.15-0.43 2.41-2.41 2.26-0.54-1.31-2.05-2.6-2.43 0.34-2.9-1.59 1.08-0.92 1.83-2.75-1.06-2.21 0.63-3.25a2.45 2.45 0 0 1 0.54-0.27 0.92 0.92 0 0 1 0.35-0.06zm2 2.17a3 3 0 0 0-0.84 0.12 2.88 2.88 0 1 0 0.84-0.12zm-11.38 4.92a2.47 2.47 0 0 1 0.56 0.11c1.82 0.56 0 1.51 1.27 2.91s2.38-0.38 2.81 1.47-1.33 0.73-1.89 2.56 1.53 1.87 0.13 3.17-1.29-0.78-3.15-0.35-0.86 2.25-2.68 1.69 0-1.51-1.27-2.91-2.39 0.38-2.82-1.47 1.33-0.73 1.89-2.56-1.53-1.87-0.13-3.17 1.3 0.78 3.15 0.36c1.63-0.38 1.07-1.82 2.13-1.81zm13.54 2a1.81 1.81 0 0 1 0.64 0.14c2.1 0.82-0.66 2.08 1 3.63s2.77-1.26 3.67 0.8-1.93 1-1.88 3.25 2.84 1.06 2 3.16-2.07-0.67-3.63 1 1.26 2.76-0.8 3.67-1-1.94-3.25-1.89-1.06 2.85-3.16 2 0.67-2.07-1-3.63-2.76 1.27-3.67-0.79 1.94-1 1.89-3.25-2.85-1.06-2-3.16 2.07 0.67 3.63-1-1.26-2.76 0.8-3.67 1 1.93 3.24 1.88c2 0 1.31-2.19 2.52-2.17zm-14.7 1a2.88 2.88 0 1 0 2.87 2.88 2.88 2.88 0 0 0-2.87-2.88zm12.35 2.76a4.23 4.23 0 1 0 4.24 4.23 4.23 4.23 0 0 0-4.28-4.25z" data-name="path1984"/>
+  </g>
+  <g id="layer1-11-3" transform="translate(-22.232 5.3355)" data-name="layer1">
+   <g id="g70-11-2" data-name="g70">
+    <path id="path3055-11-0" class="cls-11" d="m462.48 109.72a4.33 4.33 0 0 0-1.65 0.42l-22.55 10.77a4.29 4.29 0 0 0-2.33 2.9l-5.56 24.19a4.22 4.22 0 0 0 0.59 3.28 2.62 2.62 0 0 0 0.24 0.34l15.61 19.38a4.29 4.29 0 0 0 3.37 1.61h25a4.34 4.34 0 0 0 3.37-1.6l15.6-19.41a4.22 4.22 0 0 0 0.83-3.6l-5.57-24.19a4.27 4.27 0 0 0-2.33-2.9l-22.55-10.77a4.31 4.31 0 0 0-2.07-0.42z" data-name="path3055"/>
+    <path id="path3054-2-9-11-7" class="cls-13" d="m462.47 108a4.56 4.56 0 0 0-1.74 0.44l-23.8 11.37a4.53 4.53 0 0 0-2.47 3.06l-5.87 25.55a4.49 4.49 0 0 0 0.62 3.46l0.26 0.36 16.47 20.48a4.57 4.57 0 0 0 3.56 1.7h26.42a4.56 4.56 0 0 0 3.56-1.69l16.46-20.49a4.44 4.44 0 0 0 0.88-3.81l-5.88-25.55a4.5 4.5 0 0 0-2.46-3.06l-23.8-11.37a4.57 4.57 0 0 0-2.21-0.45zm0 1.75a4.31 4.31 0 0 1 2.09 0.42l22.55 10.77a4.27 4.27 0 0 1 2.33 2.9l5.56 24.16a4.21 4.21 0 0 1-0.83 3.62l-15.58 19.38a4.31 4.31 0 0 1-3.37 1.6h-25a4.33 4.33 0 0 1-3.38-1.61l-15.6-19.4c-0.09-0.11-0.17-0.22-0.25-0.34a4.26 4.26 0 0 1-0.58-3.28l5.56-24.2a4.29 4.29 0 0 1 2.33-2.9l22.55-10.77a4.33 4.33 0 0 1 1.65-0.42z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-11-4" class="cls-14" data-name="text2066">
+    <text id="text213-7" class="cls-19" transform="translate(449.46,167.32)">c-c-m</text>
+   </g>
+   <path id="path1984-5-6" class="cls-13" d="m462.64 120.39c-0.53 0-15.17 7.18-15.36 7.55-0.46 0.88-3.79 16.25-3.59 16.58s2.51 3.23 5.33 6.76l5.12 6.4h16.86l5.36-6.7 5.37-6.7-1.88-8.23c-1-4.53-2-8.31-2.05-8.4-0.27-0.25-14.89-7.26-15.17-7.27zm0.9 7.52c0.7 0 0.78 1.11 2.29 1.22 2 0.15 1.77-1.69 3.28-0.41s-0.33 1.38 0.14 3.31 2.16 1.15 1.4 3-1.41 0.1-3.1 1.15-0.43 2.41-2.41 2.26-0.54-1.31-2.05-2.6-2.43 0.34-2.9-1.59 1.08-0.92 1.83-2.75-1.06-2.21 0.63-3.25a2.45 2.45 0 0 1 0.54-0.27 0.92 0.92 0 0 1 0.35-0.06zm2 2.17a3 3 0 0 0-0.84 0.12 2.88 2.88 0 1 0 0.84-0.12zm-11.38 4.92a2.47 2.47 0 0 1 0.56 0.11c1.82 0.56 0 1.51 1.27 2.91s2.38-0.38 2.81 1.47-1.33 0.73-1.89 2.56 1.53 1.87 0.13 3.17-1.29-0.78-3.15-0.35-0.86 2.25-2.68 1.69 0-1.51-1.27-2.91-2.39 0.38-2.82-1.47 1.33-0.73 1.89-2.56-1.53-1.87-0.13-3.17 1.3 0.78 3.15 0.36c1.63-0.38 1.07-1.82 2.13-1.81zm13.54 2a1.81 1.81 0 0 1 0.64 0.14c2.1 0.82-0.66 2.08 1 3.63s2.77-1.26 3.67 0.8-1.93 1-1.88 3.25 2.84 1.06 2 3.16-2.07-0.67-3.63 1 1.26 2.76-0.8 3.67-1-1.94-3.25-1.89-1.06 2.85-3.16 2 0.67-2.07-1-3.63-2.76 1.27-3.67-0.79 1.94-1 1.89-3.25-2.85-1.06-2-3.16 2.07 0.67 3.63-1-1.26-2.76 0.8-3.67 1 1.93 3.24 1.88c2 0 1.31-2.19 2.52-2.17zm-14.7 1a2.88 2.88 0 1 0 2.87 2.88 2.88 2.88 0 0 0-2.87-2.88zm12.35 2.76a4.23 4.23 0 1 0 4.24 4.23 4.23 4.23 0 0 0-4.28-4.25z" data-name="path1984"/>
+  </g>
+  <g id="layer1-11-8" transform="translate(-13.136 13.515)" data-name="layer1">
+   <g id="g70-11-1" data-name="g70">
+    <path id="path3055-11-8" class="cls-11" d="m462.48 109.72a4.33 4.33 0 0 0-1.65 0.42l-22.55 10.77a4.29 4.29 0 0 0-2.33 2.9l-5.56 24.19a4.22 4.22 0 0 0 0.59 3.28 2.62 2.62 0 0 0 0.24 0.34l15.61 19.38a4.29 4.29 0 0 0 3.37 1.61h25a4.34 4.34 0 0 0 3.37-1.6l15.6-19.41a4.22 4.22 0 0 0 0.83-3.6l-5.57-24.19a4.27 4.27 0 0 0-2.33-2.9l-22.55-10.77a4.31 4.31 0 0 0-2.07-0.42z" data-name="path3055"/>
+    <path id="path3054-2-9-11-9" class="cls-13" d="m462.47 108a4.56 4.56 0 0 0-1.74 0.44l-23.8 11.37a4.53 4.53 0 0 0-2.47 3.06l-5.87 25.55a4.49 4.49 0 0 0 0.62 3.46l0.26 0.36 16.47 20.48a4.57 4.57 0 0 0 3.56 1.7h26.42a4.56 4.56 0 0 0 3.56-1.69l16.46-20.49a4.44 4.44 0 0 0 0.88-3.81l-5.88-25.55a4.5 4.5 0 0 0-2.46-3.06l-23.8-11.37a4.57 4.57 0 0 0-2.21-0.45zm0 1.75a4.31 4.31 0 0 1 2.09 0.42l22.55 10.77a4.27 4.27 0 0 1 2.33 2.9l5.56 24.16a4.21 4.21 0 0 1-0.83 3.62l-15.58 19.38a4.31 4.31 0 0 1-3.37 1.6h-25a4.33 4.33 0 0 1-3.38-1.61l-15.6-19.4c-0.09-0.11-0.17-0.22-0.25-0.34a4.26 4.26 0 0 1-0.58-3.28l5.56-24.2a4.29 4.29 0 0 1 2.33-2.9l22.55-10.77a4.33 4.33 0 0 1 1.65-0.42z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-11-3" class="cls-14" data-name="text2066">
+    <text id="text213-72" class="cls-19" transform="translate(449.46,167.32)">c-c-m</text>
+   </g>
+   <path id="path1984-5-7" class="cls-13" d="m462.64 120.39c-0.53 0-15.17 7.18-15.36 7.55-0.46 0.88-3.79 16.25-3.59 16.58s2.51 3.23 5.33 6.76l5.12 6.4h16.86l5.36-6.7 5.37-6.7-1.88-8.23c-1-4.53-2-8.31-2.05-8.4-0.27-0.25-14.89-7.26-15.17-7.27zm0.9 7.52c0.7 0 0.78 1.11 2.29 1.22 2 0.15 1.77-1.69 3.28-0.41s-0.33 1.38 0.14 3.31 2.16 1.15 1.4 3-1.41 0.1-3.1 1.15-0.43 2.41-2.41 2.26-0.54-1.31-2.05-2.6-2.43 0.34-2.9-1.59 1.08-0.92 1.83-2.75-1.06-2.21 0.63-3.25a2.45 2.45 0 0 1 0.54-0.27 0.92 0.92 0 0 1 0.35-0.06zm2 2.17a3 3 0 0 0-0.84 0.12 2.88 2.88 0 1 0 0.84-0.12zm-11.38 4.92a2.47 2.47 0 0 1 0.56 0.11c1.82 0.56 0 1.51 1.27 2.91s2.38-0.38 2.81 1.47-1.33 0.73-1.89 2.56 1.53 1.87 0.13 3.17-1.29-0.78-3.15-0.35-0.86 2.25-2.68 1.69 0-1.51-1.27-2.91-2.39 0.38-2.82-1.47 1.33-0.73 1.89-2.56-1.53-1.87-0.13-3.17 1.3 0.78 3.15 0.36c1.63-0.38 1.07-1.82 2.13-1.81zm13.54 2a1.81 1.81 0 0 1 0.64 0.14c2.1 0.82-0.66 2.08 1 3.63s2.77-1.26 3.67 0.8-1.93 1-1.88 3.25 2.84 1.06 2 3.16-2.07-0.67-3.63 1 1.26 2.76-0.8 3.67-1-1.94-3.25-1.89-1.06 2.85-3.16 2 0.67-2.07-1-3.63-2.76 1.27-3.67-0.79 1.94-1 1.89-3.25-2.85-1.06-2-3.16 2.07 0.67 3.63-1-1.26-2.76 0.8-3.67 1 1.93 3.24 1.88c2 0 1.31-2.19 2.52-2.17zm-14.7 1a2.88 2.88 0 1 0 2.87 2.88 2.88 2.88 0 0 0-2.87-2.88zm12.35 2.76a4.23 4.23 0 1 0 4.24 4.23 4.23 4.23 0 0 0-4.28-4.25z" data-name="path1984"/>
+  </g>
+ </g>
+ <g id="g2042" transform="translate(-123.82 -40.997)">
+  <path id="path82" class="cls-4" d="m208.7 106.15h70v70.14h-70z"/>
+  <g id="layer1-12" transform="translate(-45.575 -4.91)" data-name="layer1">
+   <g id="g70-12" data-name="g70">
+    <path id="path3055-12" class="cls-11" d="m275.24 108.5a4.33 4.33 0 0 0-1.62 0.39l-22.18 10.11a4 4 0 0 0-2.29 2.72l-5.47 22.72a3.83 3.83 0 0 0 0.57 3.08l0.24 0.32 15.35 18.22a4.37 4.37 0 0 0 3.32 1.51h24.62a4.3 4.3 0 0 0 3.31-1.51l15.35-18.21a3.9 3.9 0 0 0 0.82-3.4l-5.48-22.72a4.08 4.08 0 0 0-2.3-2.72l-22.18-10.12a4.41 4.41 0 0 0-2.06-0.39z" data-name="path3055"/>
+    <path id="path3054-2-9-12" class="cls-13" d="m275.23 106.85a4.62 4.62 0 0 0-1.71 0.42l-23.41 10.67a4.32 4.32 0 0 0-2.43 2.88l-5.77 24a4 4 0 0 0 0.61 3.25c0.08 0.12 0.16 0.23 0.25 0.34l16.23 19.21a4.61 4.61 0 0 0 3.51 1.59h26a4.58 4.58 0 0 0 3.5-1.6l16.2-19.23a4 4 0 0 0 0.86-3.58l-5.78-24a4.26 4.26 0 0 0-2.42-2.87l-23.41-10.68a4.79 4.79 0 0 0-2.23-0.4zm0 1.65a4.41 4.41 0 0 1 2.06 0.39l22.19 10.11a4.08 4.08 0 0 1 2.3 2.72l5.48 22.72a3.9 3.9 0 0 1-0.82 3.4l-15.35 18.21a4.3 4.3 0 0 1-3.31 1.51h-24.62a4.37 4.37 0 0 1-3.32-1.51l-15.35-18.22-0.24-0.32a3.83 3.83 0 0 1-0.57-3.08l5.47-22.71a4 4 0 0 1 2.29-2.73l22.18-10.11a4.33 4.33 0 0 1 1.62-0.39z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-12" class="cls-14" data-name="text2066">
+    <text id="text221" class="cls-20" transform="matrix(1.05,0,0,1,266.83,162.57)">c-m</text>
+   </g>
+   <path id="path1984-6" class="cls-13" d="m275.4 118.51c-0.52 0-14.92 6.74-15.11 7.09-0.45 0.83-3.73 15.25-3.53 15.57s2.47 3 5.24 6.34l5 6h16.59l5.28-6.29 5.27-6.29-1.84-7.73c-1-4.25-1.93-7.8-2-7.88-0.26-0.24-14.64-6.82-14.92-6.83zm0.88 7.06c0.7 0 0.77 1 2.26 1.15 1.95 0.14 1.74-1.59 3.23-0.39s-0.33 1.3 0.13 3.11 2.12 1.08 1.38 2.81-1.39 0.1-3 1.08-0.43 2.26-2.37 2.12-0.53-1.23-2-2.44-2.39 0.31-2.85-1.5 1.06-0.86 1.81-2.58-1.05-2.07 0.61-3.05a2.71 2.71 0 0 1 0.53-0.25 1.16 1.16 0 0 1 0.34-0.06zm2 2a2.94 2.94 0 0 0-0.84 0.12 2.68 2.68 0 0 0-1.89 3.36 2.85 2.85 0 0 0 3.52 1.8 2.67 2.67 0 0 0 1.89-3.36 2.8 2.8 0 0 0-2.73-1.88zm-11.18 4.64a2 2 0 0 1 0.56 0.1c1.79 0.52 0 1.42 1.25 2.73s2.34-0.36 2.76 1.39-1.3 0.68-1.85 2.39 1.5 1.76 0.12 3-1.27-0.73-3.1-0.33-0.85 2.12-2.64 1.59 0-1.42-1.25-2.73-2.34 0.36-2.76-1.38 1.3-0.69 1.85-2.4-1.5-1.76-0.13-3 1.28 0.74 3.11 0.33c1.6-0.35 1-1.7 2.08-1.69zm13.32 1.87a2.06 2.06 0 0 1 0.64 0.14c2.06 0.77-0.66 2 0.95 3.41s2.71-1.19 3.61 0.75-1.91 0.93-1.86 3.05 2.8 1 2 3-2-0.62-3.57 0.91 1.24 2.59-0.79 3.44-1-1.82-3.19-1.77-1 2.67-3.11 1.9 0.65-1.94-0.95-3.4-2.71 1.18-3.61-0.75 1.91-0.94 1.86-3-2.8-1-2-3 2 0.63 3.57-0.9-1.24-2.59 0.79-3.44 1 1.81 3.19 1.77c1.94 0 1.28-2.06 2.47-2zm-14.49 0.91a2.7 2.7 0 1 0 2.83 2.7 2.77 2.77 0 0 0-2.88-2.69zm12.07 2.62a4 4 0 1 0 4.16 4 4.07 4.07 0 0 0-4.16-4z" data-name="path1984"/>
+  </g>
+  <g id="layer1-12-3" transform="translate(-37.33 5.74)" data-name="layer1">
+   <g id="g70-12-4" data-name="g70">
+    <path id="path3055-12-0" class="cls-11" d="m275.24 108.5a4.33 4.33 0 0 0-1.62 0.39l-22.18 10.11a4 4 0 0 0-2.29 2.72l-5.47 22.72a3.83 3.83 0 0 0 0.57 3.08l0.24 0.32 15.35 18.22a4.37 4.37 0 0 0 3.32 1.51h24.62a4.3 4.3 0 0 0 3.31-1.51l15.35-18.21a3.9 3.9 0 0 0 0.82-3.4l-5.48-22.72a4.08 4.08 0 0 0-2.3-2.72l-22.18-10.12a4.41 4.41 0 0 0-2.06-0.39z" data-name="path3055"/>
+    <path id="path3054-2-9-12-9" class="cls-13" d="m275.23 106.85a4.62 4.62 0 0 0-1.71 0.42l-23.41 10.67a4.32 4.32 0 0 0-2.43 2.88l-5.77 24a4 4 0 0 0 0.61 3.25c0.08 0.12 0.16 0.23 0.25 0.34l16.23 19.21a4.61 4.61 0 0 0 3.51 1.59h26a4.58 4.58 0 0 0 3.5-1.6l16.2-19.23a4 4 0 0 0 0.86-3.58l-5.78-24a4.26 4.26 0 0 0-2.42-2.87l-23.41-10.68a4.79 4.79 0 0 0-2.23-0.4zm0 1.65a4.41 4.41 0 0 1 2.06 0.39l22.19 10.11a4.08 4.08 0 0 1 2.3 2.72l5.48 22.72a3.9 3.9 0 0 1-0.82 3.4l-15.35 18.21a4.3 4.3 0 0 1-3.31 1.51h-24.62a4.37 4.37 0 0 1-3.32-1.51l-15.35-18.22-0.24-0.32a3.83 3.83 0 0 1-0.57-3.08l5.47-22.71a4 4 0 0 1 2.29-2.73l22.18-10.11a4.33 4.33 0 0 1 1.62-0.39z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-12-6" class="cls-14" data-name="text2066">
+    <text id="text221-8" class="cls-20" transform="matrix(1.05,0,0,1,266.83,162.57)">c-m</text>
+   </g>
+   <path id="path1984-6-2" class="cls-13" d="m275.4 118.51c-0.52 0-14.92 6.74-15.11 7.09-0.45 0.83-3.73 15.25-3.53 15.57s2.47 3 5.24 6.34l5 6h16.59l5.28-6.29 5.27-6.29-1.84-7.73c-1-4.25-1.93-7.8-2-7.88-0.26-0.24-14.64-6.82-14.92-6.83zm0.88 7.06c0.7 0 0.77 1 2.26 1.15 1.95 0.14 1.74-1.59 3.23-0.39s-0.33 1.3 0.13 3.11 2.12 1.08 1.38 2.81-1.39 0.1-3 1.08-0.43 2.26-2.37 2.12-0.53-1.23-2-2.44-2.39 0.31-2.85-1.5 1.06-0.86 1.81-2.58-1.05-2.07 0.61-3.05a2.71 2.71 0 0 1 0.53-0.25 1.16 1.16 0 0 1 0.34-0.06zm2 2a2.94 2.94 0 0 0-0.84 0.12 2.68 2.68 0 0 0-1.89 3.36 2.85 2.85 0 0 0 3.52 1.8 2.67 2.67 0 0 0 1.89-3.36 2.8 2.8 0 0 0-2.73-1.88zm-11.18 4.64a2 2 0 0 1 0.56 0.1c1.79 0.52 0 1.42 1.25 2.73s2.34-0.36 2.76 1.39-1.3 0.68-1.85 2.39 1.5 1.76 0.12 3-1.27-0.73-3.1-0.33-0.85 2.12-2.64 1.59 0-1.42-1.25-2.73-2.34 0.36-2.76-1.38 1.3-0.69 1.85-2.4-1.5-1.76-0.13-3 1.28 0.74 3.11 0.33c1.6-0.35 1-1.7 2.08-1.69zm13.32 1.87a2.06 2.06 0 0 1 0.64 0.14c2.06 0.77-0.66 2 0.95 3.41s2.71-1.19 3.61 0.75-1.91 0.93-1.86 3.05 2.8 1 2 3-2-0.62-3.57 0.91 1.24 2.59-0.79 3.44-1-1.82-3.19-1.77-1 2.67-3.11 1.9 0.65-1.94-0.95-3.4-2.71 1.18-3.61-0.75 1.91-0.94 1.86-3-2.8-1-2-3 2 0.63 3.57-0.9-1.24-2.59 0.79-3.44 1 1.81 3.19 1.77c1.94 0 1.28-2.06 2.47-2zm-14.49 0.91a2.7 2.7 0 1 0 2.83 2.7 2.77 2.77 0 0 0-2.88-2.69zm12.07 2.62a4 4 0 1 0 4.16 4 4.07 4.07 0 0 0-4.16-4z" data-name="path1984"/>
+  </g>
+  <g id="layer1-12-6" transform="translate(-29.085 16.39)" data-name="layer1">
+   <g id="g70-12-42" data-name="g70">
+    <path id="path3055-12-3" class="cls-11" d="m275.24 108.5a4.33 4.33 0 0 0-1.62 0.39l-22.18 10.11a4 4 0 0 0-2.29 2.72l-5.47 22.72a3.83 3.83 0 0 0 0.57 3.08l0.24 0.32 15.35 18.22a4.37 4.37 0 0 0 3.32 1.51h24.62a4.3 4.3 0 0 0 3.31-1.51l15.35-18.21a3.9 3.9 0 0 0 0.82-3.4l-5.48-22.72a4.08 4.08 0 0 0-2.3-2.72l-22.18-10.12a4.41 4.41 0 0 0-2.06-0.39z" data-name="path3055"/>
+    <path id="path3054-2-9-12-0" class="cls-13" d="m275.23 106.85a4.62 4.62 0 0 0-1.71 0.42l-23.41 10.67a4.32 4.32 0 0 0-2.43 2.88l-5.77 24a4 4 0 0 0 0.61 3.25c0.08 0.12 0.16 0.23 0.25 0.34l16.23 19.21a4.61 4.61 0 0 0 3.51 1.59h26a4.58 4.58 0 0 0 3.5-1.6l16.2-19.23a4 4 0 0 0 0.86-3.58l-5.78-24a4.26 4.26 0 0 0-2.42-2.87l-23.41-10.68a4.79 4.79 0 0 0-2.23-0.4zm0 1.65a4.41 4.41 0 0 1 2.06 0.39l22.19 10.11a4.08 4.08 0 0 1 2.3 2.72l5.48 22.72a3.9 3.9 0 0 1-0.82 3.4l-15.35 18.21a4.3 4.3 0 0 1-3.31 1.51h-24.62a4.37 4.37 0 0 1-3.32-1.51l-15.35-18.22-0.24-0.32a3.83 3.83 0 0 1-0.57-3.08l5.47-22.71a4 4 0 0 1 2.29-2.73l22.18-10.11a4.33 4.33 0 0 1 1.62-0.39z" data-name="path3054-2-9"/>
+   </g>
+   <g id="text2066-12-5" class="cls-14" data-name="text2066">
+    <text id="text221-0" class="cls-20" transform="matrix(1.05,0,0,1,266.83,162.57)">c-m</text>
+   </g>
+   <path id="path1984-6-7" class="cls-13" d="m275.4 118.51c-0.52 0-14.92 6.74-15.11 7.09-0.45 0.83-3.73 15.25-3.53 15.57s2.47 3 5.24 6.34l5 6h16.59l5.28-6.29 5.27-6.29-1.84-7.73c-1-4.25-1.93-7.8-2-7.88-0.26-0.24-14.64-6.82-14.92-6.83zm0.88 7.06c0.7 0 0.77 1 2.26 1.15 1.95 0.14 1.74-1.59 3.23-0.39s-0.33 1.3 0.13 3.11 2.12 1.08 1.38 2.81-1.39 0.1-3 1.08-0.43 2.26-2.37 2.12-0.53-1.23-2-2.44-2.39 0.31-2.85-1.5 1.06-0.86 1.81-2.58-1.05-2.07 0.61-3.05a2.71 2.71 0 0 1 0.53-0.25 1.16 1.16 0 0 1 0.34-0.06zm2 2a2.94 2.94 0 0 0-0.84 0.12 2.68 2.68 0 0 0-1.89 3.36 2.85 2.85 0 0 0 3.52 1.8 2.67 2.67 0 0 0 1.89-3.36 2.8 2.8 0 0 0-2.73-1.88zm-11.18 4.64a2 2 0 0 1 0.56 0.1c1.79 0.52 0 1.42 1.25 2.73s2.34-0.36 2.76 1.39-1.3 0.68-1.85 2.39 1.5 1.76 0.12 3-1.27-0.73-3.1-0.33-0.85 2.12-2.64 1.59 0-1.42-1.25-2.73-2.34 0.36-2.76-1.38 1.3-0.69 1.85-2.4-1.5-1.76-0.13-3 1.28 0.74 3.11 0.33c1.6-0.35 1-1.7 2.08-1.69zm13.32 1.87a2.06 2.06 0 0 1 0.64 0.14c2.06 0.77-0.66 2 0.95 3.41s2.71-1.19 3.61 0.75-1.91 0.93-1.86 3.05 2.8 1 2 3-2-0.62-3.57 0.91 1.24 2.59-0.79 3.44-1-1.82-3.19-1.77-1 2.67-3.11 1.9 0.65-1.94-0.95-3.4-2.71 1.18-3.61-0.75 1.91-0.94 1.86-3-2.8-1-2-3 2 0.63 3.57-0.9-1.24-2.59 0.79-3.44 1 1.81 3.19 1.77c1.94 0 1.28-2.06 2.47-2zm-14.49 0.91a2.7 2.7 0 1 0 2.83 2.7 2.77 2.77 0 0 0-2.88-2.69zm12.07 2.62a4 4 0 1 0 4.16 4 4.07 4.07 0 0 0-4.16-4z" data-name="path1984"/>
+  </g>
+ </g>
+ <text id="text257-0" class="cls-22" x="709.74622" y="273.9754" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1312-5" font-family="'Open Sans'" font-size="14.667px" font-weight="bold" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Node</tspan></text>
+ <text id="text257-0-8" class="cls-22" x="870.43634" y="273.14334" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1312-5-0" font-family="'Open Sans'" font-size="14.667px" font-weight="bold" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Node</tspan></text>
+ <g id="g1782" transform="translate(-123.82 -40.997)">
+  <path id="path24" class="cls-7" d="m482.2 151.95h391.95" stroke-width="1.5"/>
+  <path id="path26" d="m872.31 157.19 13.46-4.84-13.46-4.83z"/>
+ </g>
+ <g id="g3988" transform="translate(-123.82 664.74)">
+  <g id="g3990"></g>
+ </g>
+ <g id="g4014" transform="translate(-123.82 664.74)">
+  <g id="g4016"></g>
+ </g>
+ <path id="path4857" d="m468.32 368.91v100.33h47.605v-1h-46.605v-99.334z" color="#000000" color-rendering="auto" dominant-baseline="auto" fill-rule="evenodd" image-rendering="auto" shape-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+ <path id="path4853" d="m346.1 259.99c-323.35-210.23-161.68-105.11 0 0z" color="#000000" color-rendering="auto" dominant-baseline="auto" fill-rule="evenodd" image-rendering="auto" shape-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+ <path id="path3934" d="m629.76 369.61v100.33h45.238v-1h-44.238v-99.334z" color="#000000" color-rendering="auto" dominant-baseline="auto" fill-rule="evenodd" image-rendering="auto" shape-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+ <g id="layer1" transform="translate(-312.21 93.814)">
+  <g id="g70">
+   <path id="path3055" class="cls-11" d="m861.36 328.44a4.79 4.79 0 0 0-1.82 0.46l-24.77 11.83a4.71 4.71 0 0 0-2.56 3.19l-6.12 26.59a4.66 4.66 0 0 0 0.65 3.6 3.28 3.28 0 0 0 0.27 0.38l17.14 21.32a4.75 4.75 0 0 0 3.71 1.76h27.5a4.74 4.74 0 0 0 3.7-1.77l17.14-21.32a4.68 4.68 0 0 0 0.92-4l-6.12-26.56a4.69 4.69 0 0 0-2.56-3.19l-24.79-11.83a4.76 4.76 0 0 0-2.29-0.46z"/>
+   <path id="path3054-2-9" class="cls-13" d="m861.34 326.51a5.09 5.09 0 0 0-1.91 0.49l-26.15 12.49a5 5 0 0 0-2.71 3.37l-6.45 28.07a4.9 4.9 0 0 0 0.68 3.8c0.09 0.14 0.18 0.27 0.28 0.4l18.1 22.5a5 5 0 0 0 3.91 1.87h29a5 5 0 0 0 3.91-1.86l18.1-22.51a5 5 0 0 0 1-4.2l-6.46-28.07a5 5 0 0 0-2.7-3.36l-26.17-12.5a5.07 5.07 0 0 0-2.43-0.49zm0 1.93a4.76 4.76 0 0 1 2.29 0.46l24.78 11.83a4.69 4.69 0 0 1 2.56 3.19l6.12 26.59a4.63 4.63 0 0 1-0.91 4l-17.12 21.29a4.75 4.75 0 0 1-3.71 1.77h-27.49a4.75 4.75 0 0 1-3.71-1.77l-17.15-21.31a3.28 3.28 0 0 1-0.27-0.38 4.66 4.66 0 0 1-0.65-3.6l6.11-26.59a4.73 4.73 0 0 1 2.57-3.18l24.77-11.84a4.79 4.79 0 0 1 1.82-0.46z"/>
+  </g>
+  <g id="text2066" class="cls-14">
+   <text id="text133" class="cls-15" transform="translate(841.97,391.73)">k-proxy</text>
+  </g>
+  <path id="path1994" class="cls-13" d="m861.53 338.69c-0.58 0-16.66 7.89-16.87 8.29-0.51 1-4.17 17.86-4 18.23 0.13 0.21 2.77 3.55 5.86 7.42l5.63 7h18.53l5.9-7.37 5.89-7.36-2.06-9c-1.13-5-2.15-9.13-2.25-9.23-0.29-0.28-16.36-8-16.67-8zm0.82 3.95 3.79 1.1-3.79 1.1-3.79-1.1zm-3.79 1.52 3.55 1.06v4.93l-3.53-2zm7.58 0v4l-3.53 2v-4.93zm-9.14 6.73 3.79 1.1-3.79 1.1-3.79-1.1zm9.22 0 3.78 1.11-3.79 1.1-3.8-1.1zm-13 1.52 3.55 1.06v4.93l-3.54-1.95zm7.58 0v4l-3.53 1.95v-4.93zm1.63 0 3.55 1.06v4.93l-3.53-1.95zm7.59 0v4l-3.54 1.95v-4.93zm-14.39 6.32c1.13 0 0.25 1.18 1.53 1.79s1.65-1 2.51 0.26-0.76 0.93-0.64 2.44 1.67 0.94 1 2.31-1.19-0.2-2.43 0.66 0 1.92-1.48 2-0.43-1.13-1.79-1.78-1.65 1-2.51-0.27 0.76-0.93 0.64-2.43-1.67-0.94-1-2.31 1.19 0.2 2.43-0.66 0-1.92 1.49-2zm9.74 1.52c2 0.05 0.06 1.95 1.9 2.77s1.95-1.89 3.34-0.43-1.34 1.42-0.62 3.31 2.72 0 2.66 2.05-2 0.06-2.77 1.9 1.89 1.95 0.43 3.34-1.42-1.34-3.31-0.62 0 2.72-2.05 2.66-0.06-2-1.9-2.77-2 1.89-3.34 0.43 1.34-1.42 0.62-3.31-2.72 0-2.66-2.05 2-0.06 2.77-1.9-1.89-1.95-0.43-3.34 1.42 1.34 3.31 0.62-0.01-2.72 2.01-2.66zm-9.65 1.05a2.22 2.22 0 1 0 2.21 2.22 2.22 2.22 0 0 0-2.25-2.22zm9.44 2a4.43 4.43 0 1 0 4.43 4.43 4.43 4.43 0 0 0-4.47-4.42z"/>
+ </g>
+ <g id="layer1-4" transform="translate(-312.22 93.814)" data-name="layer1">
+  <g id="g70-4" data-name="g70">
+   <path id="path3055-4" class="cls-11" d="m861.37 239.22a4.45 4.45 0 0 0-1.72 0.43l-23.45 11.21a4.46 4.46 0 0 0-2.43 3l-5.77 25.19a4.46 4.46 0 0 0 0.61 3.41c0.08 0.12 0.17 0.24 0.26 0.35l16.21 20.19a4.52 4.52 0 0 0 3.51 1.67h26a4.46 4.46 0 0 0 3.51-1.67l16.23-20.18a4.42 4.42 0 0 0 0.86-3.77l-5.79-25.17a4.46 4.46 0 0 0-2.43-3l-23.45-11.2a4.56 4.56 0 0 0-2.15-0.46z" data-name="path3055"/>
+   <path id="path3054-2-9-4" class="cls-13" d="m861.36 237.39a4.71 4.71 0 0 0-1.81 0.47l-24.77 11.82a4.74 4.74 0 0 0-2.56 3.19l-6.1 26.57a4.62 4.62 0 0 0 0.64 3.6 3.28 3.28 0 0 0 0.27 0.38l17.13 21.31a4.78 4.78 0 0 0 3.71 1.76h27.48a4.74 4.74 0 0 0 3.7-1.77l17.13-21.31a4.66 4.66 0 0 0 0.92-4l-6.1-26.55a4.72 4.72 0 0 0-2.56-3.18l-24.76-11.83a4.82 4.82 0 0 0-2.32-0.46zm0 1.83a4.49 4.49 0 0 1 2.17 0.43l23.47 11.2a4.48 4.48 0 0 1 2.43 3l5.79 25.15a4.42 4.42 0 0 1-0.86 3.77l-16.23 20.23a4.5 4.5 0 0 1-3.51 1.68h-26a4.49 4.49 0 0 1-3.51-1.67l-16.23-20.19c-0.09-0.11-0.18-0.23-0.26-0.35a4.42 4.42 0 0 1-0.61-3.41l5.79-25.17a4.46 4.46 0 0 1 2.43-3l23.45-11.21a4.45 4.45 0 0 1 1.72-0.43z" data-name="path3054-2-9"/>
+  </g>
+  <g id="text2066-4" class="cls-14" data-name="text2066">
+   <text id="text157" class="cls-16" transform="translate(843.3,299.14)">kubelet</text>
+  </g>
+  <path id="path1994-4" class="cls-13" d="m861.53 248.92c-0.54 0-15.77 7.47-16 7.85-0.48 0.93-3.95 16.91-3.74 17.25s2.61 3.37 5.54 7l5.33 6.67h17.55l11.16-14-1.95-8.56c-1.08-4.71-2-8.64-2.14-8.74-0.27-0.26-15.48-7.55-15.78-7.56zm0.78 3.74 3.59 1-3.59 1-3.59-1zm-3.59 1.44 3.36 1v4.67l-3.34-1.85zm7.18 0v3.82l-3.35 1.85v-4.67zm-8.68 6.38 3.59 1-3.59 1-3.59-1zm8.72 0 3.59 1-3.59 1-3.59-1zm-12.31 1.43 3.36 1v4.68l-3.35-1.86zm7.18 0v3.82l-3.35 1.86v-4.68zm1.54 0 3.36 1v4.68l-3.35-1.86zm7.18 0v3.82l-3.34 1.86v-4.68zm-13.62 6c1.07 0 0.24 1.11 1.45 1.69s1.56-0.93 2.38 0.25-0.73 0.88-0.61 2.31 1.58 0.89 1 2.18-1.13-0.19-2.31 0.62 0 1.82-1.4 1.94-0.4-1.07-1.7-1.69-1.56 0.93-2.37-0.25 0.73-0.88 0.61-2.31-1.59-0.88-1-2.18 1.12 0.19 2.3-0.62 0-1.82 1.41-1.94zm9.22 1.43c1.91 0.05 0.06 1.85 1.8 2.63s1.85-1.8 3.16-0.41-1.26 1.34-0.58 3.13 2.57 0 2.52 1.94-1.85 0.06-2.63 1.8 1.79 1.85 0.41 3.16-1.35-1.26-3.13-0.58 0 2.57-1.95 2.52-0.05-1.85-1.8-2.63-1.84 1.8-3.15 0.41 1.26-1.34 0.58-3.13-2.58 0-2.52-1.94 1.84-0.06 2.62-1.81-1.79-1.84-0.4-3.15 1.34 1.26 3.13 0.58 0.03-2.58 1.94-2.53zm-9.14 1a2.1 2.1 0 1 0 2.1 2.1 2.1 2.1 0 0 0-2.09-2.11zm8.94 1.9a4.2 4.2 0 1 0 4.2 4.19 4.2 4.2 0 0 0-4.2-4.2z" data-name="path1994"/>
+ </g>
+ <g id="layer1-5" transform="translate(-288.32 93.814)" data-name="layer1">
+  <g id="g70-5" data-name="g70">
+   <path id="path3055-5" class="cls-11" d="m998.15 239.22a4.45 4.45 0 0 0-1.72 0.43l-23.43 11.21a4.45 4.45 0 0 0-2.42 3l-5.79 25.17a4.42 4.42 0 0 0 0.61 3.41 2.88 2.88 0 0 0 0.26 0.35l16.2 20.21a4.52 4.52 0 0 0 3.51 1.67h26a4.49 4.49 0 0 0 3.51-1.67l16.22-20.18a4.42 4.42 0 0 0 0.9-3.82l-5.79-25.17a4.48 4.48 0 0 0-2.43-3l-23.46-11.2a4.49 4.49 0 0 0-2.17-0.41z" data-name="path3055"/>
+   <path id="path3054-2-9-5" class="cls-13" d="m998.13 237.39a4.81 4.81 0 0 0-1.81 0.47l-24.76 11.82a4.71 4.71 0 0 0-2.56 3.19l-6.11 26.57a4.7 4.7 0 0 0 0.64 3.6l0.27 0.38 17.14 21.31a4.76 4.76 0 0 0 3.7 1.76h27.48a4.76 4.76 0 0 0 3.71-1.77l17.17-21.31a4.66 4.66 0 0 0 0.91-4l-6.11-26.58a4.73 4.73 0 0 0-2.57-3.18l-24.76-11.83a4.77 4.77 0 0 0-2.34-0.43zm0 1.83a4.52 4.52 0 0 1 2.17 0.43l23.46 11.2a4.48 4.48 0 0 1 2.43 3l5.81 25.15a4.42 4.42 0 0 1-0.87 3.77l-16.22 20.23a4.53 4.53 0 0 1-3.51 1.68h-26a4.49 4.49 0 0 1-3.51-1.67l-16.23-20.19a2.88 2.88 0 0 1-0.26-0.35 4.42 4.42 0 0 1-0.61-3.41l5.79-25.17a4.44 4.44 0 0 1 2.42-3l23.46-11.21a4.45 4.45 0 0 1 1.72-0.43z" data-name="path3054-2-9"/>
+  </g>
+  <g id="text2066-5" class="cls-14" data-name="text2066">
+   <text id="text165" class="cls-16" transform="translate(980.08,299.14)">kubelet</text>
+  </g>
+  <path id="path1994-5" class="cls-13" d="m998.31 248.92c-0.55 0-15.78 7.47-16 7.85-0.48 0.93-4 16.91-3.75 17.25s2.62 3.37 5.55 7l5.33 6.67h17.56l5.59-7 5.58-7-2-8.56c-1.07-4.71-2-8.64-2.13-8.74-0.28-0.26-15.48-7.55-15.78-7.56zm0.77 3.74 3.59 1-3.59 1-3.58-1zm-3.58 1.44 3.36 1v4.67l-3.34-1.85zm7.17 0v3.82l-3.34 1.85v-4.67zm-8.67 6.38 3.59 1-3.59 1-3.59-1zm8.72 0 3.59 1-3.59 1-3.59-1zm-12.31 1.43 3.36 1v4.68l-3.34-1.86zm7.18 0v3.82l-3.35 1.86v-4.68zm1.54 0 3.36 1v4.68l-3.34-1.86zm7.18 0v3.82l-3.35 1.86v-4.68zm-13.62 6c1.06 0 0.24 1.11 1.45 1.69s1.56-0.93 2.37 0.25-0.72 0.88-0.61 2.31 1.59 0.89 1 2.18-1.13-0.19-2.31 0.62 0 1.82-1.4 1.94-0.41-1.07-1.7-1.69-1.56 0.93-2.37-0.25 0.72-0.88 0.61-2.31-1.59-0.88-1-2.18 1.12 0.19 2.3-0.62 0-1.82 1.41-1.94zm9.22 1.43c1.91 0.05 0.06 1.85 1.8 2.63s1.84-1.8 3.16-0.41-1.27 1.34-0.59 3.13 2.58 0 2.52 1.94-1.84 0.06-2.62 1.8 1.79 1.85 0.4 3.16-1.34-1.26-3.12-0.58 0 2.57-2 2.52-0.06-1.85-1.8-2.63-1.85 1.8-3.16 0.41 1.27-1.34 0.58-3.13-2.57 0-2.51-1.94 1.84-0.06 2.62-1.81-1.79-1.84-0.41-3.15 1.35 1.26 3.13 0.58 0.09-2.58 2-2.53zm-9.14 1a2.1 2.1 0 1 0 2.1 2.1 2.1 2.1 0 0 0-2.1-2.11zm8.94 1.9a4.2 4.2 0 1 0 4.19 4.19 4.2 4.2 0 0 0-4.19-4.2z" data-name="path1994"/>
+ </g>
+ <g id="layer1-3-3" transform="translate(-440.4 93.814)" data-name="layer1">
+  <g id="g70-3-0" data-name="g70">
+   <path id="path3055-3-4" class="cls-11" d="m1150.2 328.44a4.79 4.79 0 0 0-1.82 0.46l-24.77 11.83a4.71 4.71 0 0 0-2.56 3.19l-6.1 26.59a4.66 4.66 0 0 0 0.65 3.6 3.28 3.28 0 0 0 0.27 0.38l17.08 21.32a4.75 4.75 0 0 0 3.71 1.76h27.5a4.74 4.74 0 0 0 3.7-1.77l17.14-21.32a4.68 4.68 0 0 0 0.92-4l-6.13-26.58a4.69 4.69 0 0 0-2.56-3.19l-24.77-11.83a4.82 4.82 0 0 0-2.26-0.44z" data-name="path3055"/>
+   <path id="path3054-2-9-3-0" class="cls-13" d="m1150.2 326.51a5.09 5.09 0 0 0-1.91 0.49l-26.15 12.49a5 5 0 0 0-2.71 3.37l-6.46 28.07a4.9 4.9 0 0 0 0.68 3.8c0.09 0.14 0.18 0.27 0.28 0.4l18.1 22.5a5 5 0 0 0 3.91 1.87h29a5 5 0 0 0 3.91-1.86l18.1-22.51a5 5 0 0 0 1-4.2l-6.46-28.07a5 5 0 0 0-2.7-3.36l-26.16-12.5a5.07 5.07 0 0 0-2.43-0.49zm0 1.93a4.76 4.76 0 0 1 2.29 0.46l24.78 11.83a4.69 4.69 0 0 1 2.56 3.19l6.13 26.59a4.66 4.66 0 0 1-0.92 4l-17.07 21.29a4.74 4.74 0 0 1-3.7 1.77h-27.5a4.76 4.76 0 0 1-3.71-1.77l-17.14-21.32a3.28 3.28 0 0 1-0.27-0.38 4.66 4.66 0 0 1-0.65-3.6l6.12-26.59a4.69 4.69 0 0 1 2.56-3.18l24.77-11.84a4.79 4.79 0 0 1 1.82-0.46z" data-name="path3054-2-9"/>
+  </g>
+  <g id="text2066-3-0" class="cls-14" data-name="text2066">
+   <text id="text149-5" class="cls-15" transform="translate(1130.9 391.73)">k-proxy</text>
+  </g>
+  <path id="path1994-3-5" class="cls-13" d="m1150.4 338.69c-0.58 0-16.66 7.89-16.87 8.29-0.51 1-4.17 17.86-4 18.23 0.12 0.21 2.76 3.55 5.85 7.42l5.63 7h18.53l5.9-7.37 5.89-7.36-2.06-9c-1.13-5-2.15-9.13-2.25-9.23-0.29-0.28-16.36-8-16.67-8zm0.82 3.95 3.79 1.1-3.79 1.1-3.79-1.1zm-3.79 1.52 3.55 1.06v4.93l-3.53-2zm7.58 0v4l-3.53 2v-4.93zm-9.17 6.73 3.79 1.1-3.79 1.1-3.79-1.1zm9.22 0 3.79 1.1-3.79 1.1-3.8-1.1zm-13 1.52 3.55 1.06v4.93l-3.54-1.95zm7.58 0v4l-3.53 1.95v-4.93zm1.63 0 3.55 1.06v4.93l-3.53-1.95zm7.59 0v4l-3.53 1.95v-4.93zm-14.39 6.32c1.13 0 0.25 1.18 1.54 1.79s1.64-1 2.5 0.26-0.76 0.93-0.64 2.44 1.67 0.94 1 2.31-1.19-0.2-2.43 0.66 0 1.92-1.48 2-0.43-1.13-1.79-1.78-1.65 1-2.51-0.27 0.76-0.93 0.64-2.43-1.67-0.94-1-2.31 1.19 0.2 2.43-0.66 0-1.92 1.49-2zm9.74 1.52c2 0.05 0.06 1.95 1.9 2.77s2-1.89 3.34-0.43-1.34 1.42-0.62 3.31 2.72 0 2.66 2.05-2 0.06-2.77 1.9 1.89 1.95 0.43 3.34-1.42-1.34-3.3-0.62 0 2.72-2.06 2.66-0.06-2-1.9-2.77-2 1.89-3.34 0.43 1.34-1.42 0.62-3.31-2.72 0-2.66-2.05 2-0.06 2.77-1.9-1.89-1.95-0.43-3.34 1.42 1.34 3.31 0.62 0.02-2.72 2.04-2.66zm-9.65 1.05a2.22 2.22 0 1 0 2.22 2.22 2.22 2.22 0 0 0-2.23-2.22zm9.44 2a4.43 4.43 0 1 0 4.43 4.43 4.43 4.43 0 0 0-4.45-4.42z" data-name="path1994"/>
+ </g>
+ <g id="g4896" transform="translate(-138.94 -55.356)" fill-rule="evenodd" shape-rendering="auto">
+  <g id="g4885">
+   <path id="path4847" d="m594.91 274.99v27.163h-107.08v1h108.08v-27.163h333.33v250.34h49.326v-1h-48.326v-100.37h48.326v-1h-48.326v-148.98z" color="#000000" color-rendering="auto" dominant-baseline="auto" image-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+   <path id="path4845" d="m488.78 300.07c-0.0266-2e-3 -0.0532 2e-3 -0.0781 0.0117l-6.5547 2.4102c-0.16295 0.0605-0.16295 0.29102 0 0.35156l6.5547 2.4121c0.1731 0.063 0.32383-0.13521 0.21679-0.28515-0.99512-1.3865-0.9987-3.2444 0-4.6016 0.0885-0.11937 0.01-0.28934-0.13867-0.29882z" color="#000000" color-rendering="auto" dominant-baseline="auto" image-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+  </g>
+  <g id="g4877">
+   <path id="path4861" d="m489.69 329.63v1h117.52v94.564h47.605v-1h-46.605v-94.564z" color="#000000" color-rendering="auto" dominant-baseline="auto" image-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+   <path id="path4859" d="m490.78 327.54c-0.014 2e-3 -0.0277 5e-3 -0.041 0.01l-6.5547 2.4121c-0.16295 0.0605-0.16295 0.29102 0 0.35156l6.5547 2.4102c0.17312 0.0631 0.32387-0.13522 0.2168-0.28516-0.99512-1.3865-1.0007-3.2444-2e-3 -4.6016 0.0968-0.13239-0.011-0.31652-0.17382-0.29687z" color="#000000" color-rendering="auto" dominant-baseline="auto" image-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+  </g>
+  <g id="g4881">
+   <path id="path4855" d="m607.02 287.07v27.763h-117.48v1h118.48v-27.763h160.68v137.39h45.271v-1h-44.271v-137.39z" color="#000000" color-rendering="auto" dominant-baseline="auto" image-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+   <path id="path4851" d="m492.11 312.75c-0.014 2e-3 -0.0278 5e-3 -0.041 0.01l-6.5547 2.4102c-0.16655 0.059-0.16655 0.29453 0 0.35352l6.5547 2.4102c0.17311 0.0631 0.32385-0.13522 0.21679-0.28516-0.99512-1.3865-0.9987-3.2444 0-4.6016 0.0978-0.13318-0.012-0.31859-0.17578-0.29688z" color="#000000" color-rendering="auto" dominant-baseline="auto" image-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+  </g>
+ </g>
+ <rect id="rect1051" x="40.959" y="40.872" width="351.71" height="459.79" ry="18.916" fill="none" opacity=".95" stroke="#336de5" stroke-dasharray="20.8, 2.6" stroke-miterlimit="1.414" stroke-width="2.6"/>
+ <g id="g4560">
+  <text id="text270" class="cls-22" x="1148.4604" y="500.68777" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1047" font-family="'Open Sans'" font-size="14.667px" font-weight="600" text-align="end" text-anchor="end" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Control plane</tspan></text>
+  <text id="text270-1" class="cls-22" x="1148.0236" y="456.87979" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1047-7" font-family="'Open Sans'" font-size="14.667px" font-weight="600" text-align="end" text-anchor="end" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Scheduler</tspan></text>
+  <g id="use1797" transform="translate(-137.57 -55.356)">
+   <g id="g1691" transform="matrix(.71919 0 0 .71919 992.05 180.04)" data-name="layer1">
+    <g id="g1683" data-name="g70">
+     <path id="path1679" class="cls-11" d="m465.45 413.24a4.4 4.4 0 0 0-1.71 0.43l-23.38 11.13a4.43 4.43 0 0 0-2.42 3l-5.77 25a4.36 4.36 0 0 0 0.61 3.39 2.8 2.8 0 0 0 0.25 0.35l16.18 20.06a4.5 4.5 0 0 0 3.5 1.66h26a4.5 4.5 0 0 0 3.5-1.66l16.18-20.06a4.35 4.35 0 0 0 0.86-3.74l-5.77-25a4.44 4.44 0 0 0-2.42-3l-23.39-11.13a4.49 4.49 0 0 0-2.22-0.43z" data-name="path3055"/>
+     <path id="path1681" class="cls-13" d="m465.44 411.43a4.73 4.73 0 0 0-1.81 0.45l-24.63 11.76a4.66 4.66 0 0 0-2.56 3.16l-6.09 26.4a4.65 4.65 0 0 0 0.64 3.58l0.27 0.37 17.09 21.18a4.72 4.72 0 0 0 3.69 1.75h27.4a4.76 4.76 0 0 0 3.69-1.76l17.08-21.17a4.64 4.64 0 0 0 0.91-3.95l-6.12-26.4a4.69 4.69 0 0 0-2.55-3.17l-24.69-11.75a4.75 4.75 0 0 0-2.32-0.45zm0 1.81a4.52 4.52 0 0 1 2.17 0.43l23.39 11.13a4.42 4.42 0 0 1 2.41 3l5.78 25a4.35 4.35 0 0 1-0.86 3.74l-16.18 20.06a4.5 4.5 0 0 1-3.5 1.66h-26a4.5 4.5 0 0 1-3.5-1.66l-16.15-20.05c-0.09-0.11-0.18-0.23-0.26-0.35a4.4 4.4 0 0 1-0.6-3.39l5.77-25a4.43 4.43 0 0 1 2.42-3l23.38-11.13a4.4 4.4 0 0 1 1.71-0.43z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g1687" class="cls-14" data-name="text2066">
+     <text id="text1685" class="cls-17" transform="translate(451.08,472.77)">sched</text>
+    </g>
+    <path id="path1689" class="cls-13" d="m465.61 424.26c-0.54 0-15.72 7.42-15.92 7.8-0.48 0.92-3.93 16.8-3.73 17.14s2.61 3.35 5.53 7l5.31 6.62h17.49l5.57-6.93 5.56-6.92-1.95-8.51c-1.07-4.68-2-8.59-2.12-8.68-0.28-0.26-15.44-7.51-15.74-7.52zm0.93 7.78c0.74 0 0.81 1.14 2.39 1.26 2.05 0.15 1.83-1.75 3.4-0.43s-0.35 1.43 0.14 3.42 2.24 1.2 1.46 3.1-1.47 0.1-3.22 1.18-0.45 2.5-2.51 2.34-0.55-1.35-2.12-2.68-2.52 0.34-3-1.65 1.13-0.95 1.91-2.85-1.11-2.28 0.64-3.36a2.78 2.78 0 0 1 0.56-0.27 1 1 0 0 1 0.36-0.06zm2.06 2.24a2.89 2.89 0 0 0-0.88 0.13 3 3 0 1 0 0.88-0.13zm-11.78 5.11a2.21 2.21 0 0 1 0.58 0.11c1.89 0.58 0 1.57 1.32 3s2.47-0.4 2.91 1.52-1.37 0.76-1.95 2.64 1.58 1.94 0.13 3.28-1.34-0.81-3.27-0.37-0.89 2.34-2.78 1.76 0-1.57-1.32-3-2.47 0.4-2.92-1.52 1.38-0.76 2-2.64-1.58-1.94-0.14-3.28 1.35 0.81 3.28 0.36c1.68-0.38 1.1-1.88 2.2-1.86zm14 2.06a2 2 0 0 1 0.67 0.15c2.18 0.85-0.69 2.15 1 3.75s2.86-1.3 3.8 0.83-2 1-1.95 3.36 2.95 1.09 2.1 3.26-2.15-0.69-3.76 1 1.31 2.85-0.83 3.79-1-2-3.37-1.95-1.1 2.94-3.27 2.1 0.69-2.15-1-3.75-2.86 1.3-3.81-0.83 2-1 2-3.36-2.95-1.09-2.11-3.26 2.15 0.69 3.77-1-1.31-2.85 0.83-3.79 1 2 3.36 1.95c2.05-0.05 1.36-2.26 2.61-2.25zm-15.28 1a3 3 0 1 0 3 3 3 3 0 0 0-2.96-3zm12.81 2.85a4.38 4.38 0 1 0 4.39 4.37 4.37 4.37 0 0 0-4.35-4.37z" data-name="path1984"/>
+   </g>
+  </g>
+  <text id="text270-1-1-5" class="cls-22" x="1148.0236" y="106.06998" font-family="'Open Sans'" font-size="14.667px" font-weight="600" text-anchor="end" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"><tspan id="tspan4599" x="1148.0236" y="106.06998" text-align="end">Cloud controller</tspan><tspan id="tspan4601" x="1148.0236" y="124.40336" text-align="end">manager</tspan><tspan id="tspan4603" x="1148.0236" y="142.73674" font-style="italic" text-align="end">(optional)</tspan></text>
+  <g id="use1603" transform="translate(-138.94 -54.387)">
+   <g id="g2359" transform="matrix(.7857 0 0 .7857 963.45 64.034)" data-name="layer1">
+    <g id="g2351" data-name="g70">
+     <path id="path2347" class="cls-11" d="m462.48 109.72a4.33 4.33 0 0 0-1.65 0.42l-22.55 10.77a4.29 4.29 0 0 0-2.33 2.9l-5.56 24.19a4.22 4.22 0 0 0 0.59 3.28 2.62 2.62 0 0 0 0.24 0.34l15.61 19.38a4.29 4.29 0 0 0 3.37 1.61h25a4.34 4.34 0 0 0 3.37-1.6l15.6-19.41a4.22 4.22 0 0 0 0.83-3.6l-5.57-24.19a4.27 4.27 0 0 0-2.33-2.9l-22.55-10.77a4.31 4.31 0 0 0-2.07-0.42z" data-name="path3055"/>
+     <path id="path2349" class="cls-13" d="m462.47 108a4.56 4.56 0 0 0-1.74 0.44l-23.8 11.37a4.53 4.53 0 0 0-2.47 3.06l-5.87 25.55a4.49 4.49 0 0 0 0.62 3.46l0.26 0.36 16.47 20.48a4.57 4.57 0 0 0 3.56 1.7h26.42a4.56 4.56 0 0 0 3.56-1.69l16.46-20.49a4.44 4.44 0 0 0 0.88-3.81l-5.88-25.55a4.5 4.5 0 0 0-2.46-3.06l-23.8-11.37a4.57 4.57 0 0 0-2.21-0.45zm0 1.75a4.31 4.31 0 0 1 2.09 0.42l22.55 10.77a4.27 4.27 0 0 1 2.33 2.9l5.56 24.16a4.21 4.21 0 0 1-0.83 3.62l-15.58 19.38a4.31 4.31 0 0 1-3.37 1.6h-25a4.33 4.33 0 0 1-3.38-1.61l-15.6-19.4c-0.09-0.11-0.17-0.22-0.25-0.34a4.26 4.26 0 0 1-0.58-3.28l5.56-24.2a4.29 4.29 0 0 1 2.33-2.9l22.55-10.77a4.33 4.33 0 0 1 1.65-0.42z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g2355" class="cls-14" data-name="text2066">
+     <text id="text2353" class="cls-19" transform="translate(449.46,167.32)">c-c-m</text>
+    </g>
+    <path id="path2357" class="cls-13" d="m462.64 120.39c-0.53 0-15.17 7.18-15.36 7.55-0.46 0.88-3.79 16.25-3.59 16.58s2.51 3.23 5.33 6.76l5.12 6.4h16.86l5.36-6.7 5.37-6.7-1.88-8.23c-1-4.53-2-8.31-2.05-8.4-0.27-0.25-14.89-7.26-15.17-7.27zm0.9 7.52c0.7 0 0.78 1.11 2.29 1.22 2 0.15 1.77-1.69 3.28-0.41s-0.33 1.38 0.14 3.31 2.16 1.15 1.4 3-1.41 0.1-3.1 1.15-0.43 2.41-2.41 2.26-0.54-1.31-2.05-2.6-2.43 0.34-2.9-1.59 1.08-0.92 1.83-2.75-1.06-2.21 0.63-3.25a2.45 2.45 0 0 1 0.54-0.27 0.92 0.92 0 0 1 0.35-0.06zm2 2.17a3 3 0 0 0-0.84 0.12 2.88 2.88 0 1 0 0.84-0.12zm-11.38 4.92a2.47 2.47 0 0 1 0.56 0.11c1.82 0.56 0 1.51 1.27 2.91s2.38-0.38 2.81 1.47-1.33 0.73-1.89 2.56 1.53 1.87 0.13 3.17-1.29-0.78-3.15-0.35-0.86 2.25-2.68 1.69 0-1.51-1.27-2.91-2.39 0.38-2.82-1.47 1.33-0.73 1.89-2.56-1.53-1.87-0.13-3.17 1.3 0.78 3.15 0.36c1.63-0.38 1.07-1.82 2.13-1.81zm13.54 2a1.81 1.81 0 0 1 0.64 0.14c2.1 0.82-0.66 2.08 1 3.63s2.77-1.26 3.67 0.8-1.93 1-1.88 3.25 2.84 1.06 2 3.16-2.07-0.67-3.63 1 1.26 2.76-0.8 3.67-1-1.94-3.25-1.89-1.06 2.85-3.16 2 0.67-2.07-1-3.63-2.76 1.27-3.67-0.79 1.94-1 1.89-3.25-2.85-1.06-2-3.16 2.07 0.67 3.63-1-1.26-2.76 0.8-3.67 1 1.93 3.24 1.88c2 0 1.31-2.19 2.52-2.17zm-14.7 1a2.88 2.88 0 1 0 2.87 2.88 2.88 2.88 0 0 0-2.87-2.88zm12.35 2.76a4.23 4.23 0 1 0 4.24 4.23 4.23 4.23 0 0 0-4.28-4.25z" data-name="path1984"/>
+   </g>
+  </g>
+  <text id="text270-1-1-5-8" class="cls-22" x="1148.0236" y="186.10117" font-family="'Open Sans'" font-size="14.667px" font-weight="600" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"><tspan id="tspan4605" x="1148.0236" y="186.10117" text-align="end" text-anchor="end">Controller</tspan><tspan id="tspan4607" x="1148.0236" y="204.43454"><tspan id="tspan4609" text-align="end" text-anchor="end">manage</tspan>r</tspan></text>
+  <g id="use1635" transform="translate(-138.44 -53.418)">
+   <g id="g1625" transform="matrix(.78345 0 0 .78345 1111.2 130.81)" data-name="layer1">
+    <g id="g1617" data-name="g70">
+     <path id="path1613" class="cls-11" d="m275.24 108.5a4.33 4.33 0 0 0-1.62 0.39l-22.18 10.11a4 4 0 0 0-2.29 2.72l-5.47 22.72a3.83 3.83 0 0 0 0.57 3.08l0.24 0.32 15.35 18.22a4.37 4.37 0 0 0 3.32 1.51h24.62a4.3 4.3 0 0 0 3.31-1.51l15.35-18.21a3.9 3.9 0 0 0 0.82-3.4l-5.48-22.72a4.08 4.08 0 0 0-2.3-2.72l-22.18-10.12a4.41 4.41 0 0 0-2.06-0.39z" data-name="path3055"/>
+     <path id="path1615" class="cls-13" d="m275.23 106.85a4.62 4.62 0 0 0-1.71 0.42l-23.41 10.67a4.32 4.32 0 0 0-2.43 2.88l-5.77 24a4 4 0 0 0 0.61 3.25c0.08 0.12 0.16 0.23 0.25 0.34l16.23 19.21a4.61 4.61 0 0 0 3.51 1.59h26a4.58 4.58 0 0 0 3.5-1.6l16.2-19.23a4 4 0 0 0 0.86-3.58l-5.78-24a4.26 4.26 0 0 0-2.42-2.87l-23.41-10.68a4.79 4.79 0 0 0-2.23-0.4zm0 1.65a4.41 4.41 0 0 1 2.06 0.39l22.19 10.11a4.08 4.08 0 0 1 2.3 2.72l5.48 22.72a3.9 3.9 0 0 1-0.82 3.4l-15.35 18.21a4.3 4.3 0 0 1-3.31 1.51h-24.62a4.37 4.37 0 0 1-3.32-1.51l-15.35-18.22-0.24-0.32a3.83 3.83 0 0 1-0.57-3.08l5.47-22.71a4 4 0 0 1 2.29-2.73l22.18-10.11a4.33 4.33 0 0 1 1.62-0.39z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g1621" class="cls-14" data-name="text2066">
+     <text id="text1619" class="cls-20" transform="matrix(1.05,0,0,1,266.83,162.57)">c-m</text>
+    </g>
+    <path id="path1623" class="cls-13" d="m275.4 118.51c-0.52 0-14.92 6.74-15.11 7.09-0.45 0.83-3.73 15.25-3.53 15.57s2.47 3 5.24 6.34l5 6h16.59l5.28-6.29 5.27-6.29-1.84-7.73c-1-4.25-1.93-7.8-2-7.88-0.26-0.24-14.64-6.82-14.92-6.83zm0.88 7.06c0.7 0 0.77 1 2.26 1.15 1.95 0.14 1.74-1.59 3.23-0.39s-0.33 1.3 0.13 3.11 2.12 1.08 1.38 2.81-1.39 0.1-3 1.08-0.43 2.26-2.37 2.12-0.53-1.23-2-2.44-2.39 0.31-2.85-1.5 1.06-0.86 1.81-2.58-1.05-2.07 0.61-3.05a2.71 2.71 0 0 1 0.53-0.25 1.16 1.16 0 0 1 0.34-0.06zm2 2a2.94 2.94 0 0 0-0.84 0.12 2.68 2.68 0 0 0-1.89 3.36 2.85 2.85 0 0 0 3.52 1.8 2.67 2.67 0 0 0 1.89-3.36 2.8 2.8 0 0 0-2.73-1.88zm-11.18 4.64a2 2 0 0 1 0.56 0.1c1.79 0.52 0 1.42 1.25 2.73s2.34-0.36 2.76 1.39-1.3 0.68-1.85 2.39 1.5 1.76 0.12 3-1.27-0.73-3.1-0.33-0.85 2.12-2.64 1.59 0-1.42-1.25-2.73-2.34 0.36-2.76-1.38 1.3-0.69 1.85-2.4-1.5-1.76-0.13-3 1.28 0.74 3.11 0.33c1.6-0.35 1-1.7 2.08-1.69zm13.32 1.87a2.06 2.06 0 0 1 0.64 0.14c2.06 0.77-0.66 2 0.95 3.41s2.71-1.19 3.61 0.75-1.91 0.93-1.86 3.05 2.8 1 2 3-2-0.62-3.57 0.91 1.24 2.59-0.79 3.44-1-1.82-3.19-1.77-1 2.67-3.11 1.9 0.65-1.94-0.95-3.4-2.71 1.18-3.61-0.75 1.91-0.94 1.86-3-2.8-1-2-3 2 0.63 3.57-0.9-1.24-2.59 0.79-3.44 1 1.81 3.19 1.77c1.94 0 1.28-2.06 2.47-2zm-14.49 0.91a2.7 2.7 0 1 0 2.83 2.7 2.77 2.77 0 0 0-2.88-2.69zm12.07 2.62a4 4 0 1 0 4.16 4 4.07 4.07 0 0 0-4.16-4z" data-name="path1984"/>
+   </g>
+  </g>
+  <text id="text270-1-2" class="cls-22" x="1147.3718" y="327.01175" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1047-7-2" font-family="'Open Sans'" font-size="14.667px" font-style="italic" font-weight="600" text-align="end" text-anchor="end" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">kubelet</tspan></text>
+  <g id="use1733" transform="translate(-139.16 -55.212)">
+   <g id="g1659" transform="matrix(.76104 0 0 .76104 567.17 163.65)" data-name="layer1">
+    <g id="g1651" data-name="g70">
+     <path id="path1647" class="cls-11" d="m998.15 239.22a4.45 4.45 0 0 0-1.72 0.43l-23.43 11.21a4.45 4.45 0 0 0-2.42 3l-5.79 25.17a4.42 4.42 0 0 0 0.61 3.41 2.88 2.88 0 0 0 0.26 0.35l16.2 20.21a4.52 4.52 0 0 0 3.51 1.67h26a4.49 4.49 0 0 0 3.51-1.67l16.22-20.18a4.42 4.42 0 0 0 0.9-3.82l-5.79-25.17a4.48 4.48 0 0 0-2.43-3l-23.46-11.2a4.49 4.49 0 0 0-2.17-0.41z" data-name="path3055"/>
+     <path id="path1649" class="cls-13" d="m998.13 237.39a4.81 4.81 0 0 0-1.81 0.47l-24.76 11.82a4.71 4.71 0 0 0-2.56 3.19l-6.11 26.57a4.7 4.7 0 0 0 0.64 3.6l0.27 0.38 17.14 21.31a4.76 4.76 0 0 0 3.7 1.76h27.48a4.76 4.76 0 0 0 3.71-1.77l17.17-21.31a4.66 4.66 0 0 0 0.91-4l-6.11-26.58a4.73 4.73 0 0 0-2.57-3.18l-24.76-11.83a4.77 4.77 0 0 0-2.34-0.43zm0 1.83a4.52 4.52 0 0 1 2.17 0.43l23.46 11.2a4.48 4.48 0 0 1 2.43 3l5.81 25.15a4.42 4.42 0 0 1-0.87 3.77l-16.22 20.23a4.53 4.53 0 0 1-3.51 1.68h-26a4.49 4.49 0 0 1-3.51-1.67l-16.23-20.19a2.88 2.88 0 0 1-0.26-0.35 4.42 4.42 0 0 1-0.61-3.41l5.79-25.17a4.44 4.44 0 0 1 2.42-3l23.46-11.21a4.45 4.45 0 0 1 1.72-0.43z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g1655" class="cls-14" data-name="text2066">
+     <text id="text1653" class="cls-16" transform="translate(980.08,299.14)">kubelet</text>
+    </g>
+    <path id="path1657" class="cls-13" d="m998.31 248.92c-0.55 0-15.78 7.47-16 7.85-0.48 0.93-4 16.91-3.75 17.25s2.62 3.37 5.55 7l5.33 6.67h17.56l5.59-7 5.58-7-2-8.56c-1.07-4.71-2-8.64-2.13-8.74-0.28-0.26-15.48-7.55-15.78-7.56zm0.77 3.74 3.59 1-3.59 1-3.58-1zm-3.58 1.44 3.36 1v4.67l-3.34-1.85zm7.17 0v3.82l-3.34 1.85v-4.67zm-8.67 6.38 3.59 1-3.59 1-3.59-1zm8.72 0 3.59 1-3.59 1-3.59-1zm-12.31 1.43 3.36 1v4.68l-3.34-1.86zm7.18 0v3.82l-3.35 1.86v-4.68zm1.54 0 3.36 1v4.68l-3.34-1.86zm7.18 0v3.82l-3.35 1.86v-4.68zm-13.62 6c1.06 0 0.24 1.11 1.45 1.69s1.56-0.93 2.37 0.25-0.72 0.88-0.61 2.31 1.59 0.89 1 2.18-1.13-0.19-2.31 0.62 0 1.82-1.4 1.94-0.41-1.07-1.7-1.69-1.56 0.93-2.37-0.25 0.72-0.88 0.61-2.31-1.59-0.88-1-2.18 1.12 0.19 2.3-0.62 0-1.82 1.41-1.94zm9.22 1.43c1.91 0.05 0.06 1.85 1.8 2.63s1.84-1.8 3.16-0.41-1.27 1.34-0.59 3.13 2.58 0 2.52 1.94-1.84 0.06-2.62 1.8 1.79 1.85 0.4 3.16-1.34-1.26-3.12-0.58 0 2.57-2 2.52-0.06-1.85-1.8-2.63-1.85 1.8-3.16 0.41 1.27-1.34 0.58-3.13-2.57 0-2.51-1.94 1.84-0.06 2.62-1.81-1.79-1.84-0.41-3.15 1.35 1.26 3.13 0.58 0.09-2.58 2-2.53zm-9.14 1a2.1 2.1 0 1 0 2.1 2.1 2.1 2.1 0 0 0-2.1-2.11zm8.94 1.9a4.2 4.2 0 1 0 4.19 4.19 4.2 4.2 0 0 0-4.19-4.2z" data-name="path1994"/>
+   </g>
+  </g>
+  <text id="text270-1-2-2" class="cls-22" x="1147.021" y="390.25568" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1047-7-2-9" font-family="'Open Sans'" font-size="14.667px" font-style="italic" font-weight="600" text-align="end" text-anchor="end" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">kube-proxy</tspan></text>
+  <g id="use1765" transform="translate(-137.85 -54.676)">
+   <g id="g1675" transform="matrix(.68635 0 0 .68635 641.76 185.86)" data-name="layer1">
+    <g id="g1667" data-name="g70">
+     <path id="path1663" class="cls-11" d="m998.13 328.44a4.75 4.75 0 0 0-1.81 0.46l-24.77 11.83a4.72 4.72 0 0 0-2.57 3.19l-6.11 26.59a4.7 4.7 0 0 0 0.64 3.6l0.27 0.38 17.15 21.32a4.73 4.73 0 0 0 3.7 1.76h27.5a4.76 4.76 0 0 0 3.71-1.77l17.16-21.32a4.67 4.67 0 0 0 0.91-4l-6.12-26.58a4.69 4.69 0 0 0-2.56-3.19l-24.78-11.83a4.77 4.77 0 0 0-2.32-0.44z" data-name="path3055"/>
+     <path id="path1665" class="cls-13" d="m998.12 326.51a5.09 5.09 0 0 0-1.91 0.49l-26.16 12.49a5 5 0 0 0-2.7 3.37l-6.45 28.07a4.9 4.9 0 0 0 0.67 3.8c0.09 0.14 0.19 0.27 0.29 0.4l18.1 22.5a5 5 0 0 0 3.91 1.87h29a5 5 0 0 0 3.91-1.86l18.09-22.51a4.92 4.92 0 0 0 1-4.2l-6.46-28.07a5 5 0 0 0-2.71-3.36l-26.15-12.5a5.1 5.1 0 0 0-2.43-0.49zm0 1.93a4.77 4.77 0 0 1 2.3 0.46l24.78 11.83a4.69 4.69 0 0 1 2.56 3.19l6.12 26.59a4.66 4.66 0 0 1-0.91 4l-17.14 21.32a4.76 4.76 0 0 1-3.71 1.77h-27.5a4.74 4.74 0 0 1-3.7-1.77l-17.15-21.32-0.27-0.38a4.66 4.66 0 0 1-0.64-3.6l6.14-26.61a4.72 4.72 0 0 1 2.56-3.18l24.78-11.84a4.75 4.75 0 0 1 1.81-0.46z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g1671" class="cls-14" data-name="text2066">
+     <text id="text1669" class="cls-15" transform="translate(978.75,391.73)">k-proxy</text>
+    </g>
+    <path id="path1673" class="cls-13" d="m998.31 338.69c-0.58 0-16.67 7.89-16.88 8.29-0.5 1-4.16 17.86-3.95 18.23 0.13 0.21 2.76 3.55 5.86 7.42l5.63 7h18.53l5.89-7.37 5.9-7.36-2.06-9c-1.14-5-2.15-9.13-2.26-9.23-0.29-0.28-16.35-8-16.66-8zm0.81 3.95 3.8 1.1-3.8 1.1-3.79-1.1zm-3.79 1.52 3.55 1.06v4.93l-3.54-2zm7.59 0v4l-3.54 2v-4.93zm-9.17 6.73 3.79 1.1-3.79 1.1-3.75-1.09zm9.21 0 3.79 1.1-3.79 1.1-3.79-1.1zm-13 1.52 3.55 1.06v4.93l-3.51-1.95zm7.58 0v4l-3.54 1.99v-4.93zm1.63 0 3.55 1.06v4.93l-3.53-1.95zm7.58 0v4l-3.53 1.95v-4.93zm-14.39 6.32c1.13 0 0.26 1.18 1.54 1.79s1.65-1 2.51 0.26-0.77 0.93-0.64 2.44 1.67 0.94 1 2.31-1.19-0.2-2.44 0.66 0 1.92-1.48 2-0.42-1.13-1.79-1.78-1.65 1-2.51-0.27 0.77-0.93 0.65-2.43-1.68-0.94-1-2.31 1.19 0.2 2.44-0.66 0-1.92 1.48-2zm9.75 1.52c2 0.05 0.06 1.95 1.9 2.77s2-1.89 3.33-0.43-1.33 1.42-0.61 3.31 2.72 0 2.66 2.05-1.95 0.06-2.77 1.9 1.89 1.95 0.43 3.34-1.42-1.34-3.31-0.62 0 2.72-2 2.66-0.06-2-1.9-2.77-2 1.89-3.34 0.43 1.33-1.42 0.61-3.31-2.71 0-2.66-2.05 2-0.06 2.78-1.9-1.9-1.95-0.43-3.34 1.42 1.34 3.3 0.62-0.01-2.72 2.01-2.66zm-9.66 1.05a2.22 2.22 0 1 0 2.22 2.22 2.22 2.22 0 0 0-2.22-2.22zm9.45 2a4.43 4.43 0 1 0 4.43 4.43 4.43 4.43 0 0 0-4.43-4.42z" data-name="path1994"/>
+   </g>
+  </g>
+  <g id="g2164" transform="translate(-137.51 -337.4)" font-family="'Open Sans'" font-size="14.667px">
+   <text id="text270-1-2-9" class="cls-22" x="1159.5905" y="587.27118" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"><tspan id="tspan2127" x="1159.5905" y="587.27118" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/><tspan id="tspan2129" x="1159.5905" y="605.60455" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">(persistence store)</tspan></text>
+   <text id="text270-1-2-9-0" class="cls-22" x="1255.2429" y="571.36078" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"><tspan id="tspan2127-4" x="1255.2429" y="571.36078" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal"/><tspan id="tspan2129-1" x="1255.2429" y="589.69415" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">etcd</tspan></text>
+  </g>
+  <g id="use1668" transform="translate(-138.38 -53.843)">
+   <g id="g1643" transform="matrix(.78889 0 0 .78889 1109.7 -42.901)" data-name="layer1">
+    <g id="g1633" data-name="g70">
+     <path id="path1629" class="cls-11" d="m276.45 411.42a4.3 4.3 0 0 0-1.63 0.32l-22.3 9a4 4 0 0 0-2.37 2.55l-6.15 21.76a3.65 3.65 0 0 0 0.48 3 3.46 3.46 0 0 0 0.22 0.31l14.64 18.08a4.36 4.36 0 0 0 3.23 1.57l24.41 0.8a4.35 4.35 0 0 0 3.33-1.35l15.79-17.06a3.67 3.67 0 0 0 0.93-3.25l-4.71-22.09a4 4 0 0 0-2.19-2.71l-21.66-10.48a4.51 4.51 0 0 0-2.02-0.45z" data-name="path3055"/>
+     <path id="path1631" class="cls-13" d="m276.49 409.83a4.7 4.7 0 0 0-1.71 0.35l-23.56 9.52a4.18 4.18 0 0 0-2.49 2.69l-6.49 22.94a3.85 3.85 0 0 0 0.5 3.16 2 2 0 0 0 0.24 0.33l15.45 19.09a4.59 4.59 0 0 0 3.41 1.65l25.76 0.85a4.62 4.62 0 0 0 3.52-1.42l16.68-18a3.86 3.86 0 0 0 1-3.43l-5-23.32a4.17 4.17 0 0 0-2.31-2.85l-22.86-11.09a4.78 4.78 0 0 0-2.14-0.47zm0 1.59a4.51 4.51 0 0 1 2 0.44l21.66 10.48a4 4 0 0 1 2.19 2.71l4.7 22.09a3.63 3.63 0 0 1-0.92 3.25l-15.79 17.07a4.38 4.38 0 0 1-3.33 1.34l-24.4-0.8a4.34 4.34 0 0 1-3.23-1.57l-14.67-18.08-0.23-0.31a3.69 3.69 0 0 1-0.47-3l6.15-21.73a4 4 0 0 1 2.36-2.55l22.31-9a4.73 4.73 0 0 1 1.63-0.32z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g1637" class="cls-14" data-name="text2066">
+     <text id="text1635" class="cls-23" transform="matrix(1.0794 .035808 -.033155 .99945 265.24 463.26)">etcd</text>
+    </g>
+    <path id="path1639" class="cls-13" d="m276.28 421.08c-0.51 0-15 6-15.2 6.34-0.48 0.79-4.19 14.59-4 14.9s2.36 3 5 6.29l4.8 6 8.22 0.28 8.23 0.27 5.43-5.89 5.43-5.9-1.58-7.51c-0.87-4.14-1.66-7.59-1.75-7.67-0.25-0.24-14.29-7.06-14.57-7.08z"/>
+    <path id="path1641" class="cls-11" d="m291.05 440.37h-0.46a6.3 6.3 0 0 1-2.62-0.66 21 21 0 0 0 0.5-4.32 23.86 23.86 0 0 0-2.91-3.42 5.77 5.77 0 0 1 2.2-2l0.4-0.21-0.3-0.33a15.84 15.84 0 0 0-5.42-3.94l-0.42-0.19-0.12 0.41a5.43 5.43 0 0 1-1.58 2.49 25.41 25.41 0 0 0-4.3-1.81 25 25 0 0 0-4.39 1.52 5.44 5.44 0 0 1-1.42-2.58l-0.09-0.42-0.43 0.16a16 16 0 0 0-5.69 3.53l-0.31 0.31 0.38 0.23a5.7 5.7 0 0 1 2.05 2.18 23.53 23.53 0 0 0-3.12 3.2 21.37 21.37 0 0 0 0.2 4.37 6.36 6.36 0 0 1-2.64 0.48 3.44 3.44 0 0 1-0.46 0h-0.45v0.43a13.9 13.9 0 0 0 1.93 6.13l0.22 0.38 0.36-0.27a6.23 6.23 0 0 1 2.86-1.13 22.92 22.92 0 0 0 2.3 3.74 26.46 26.46 0 0 0 4.55 1.2 5.11 5.11 0 0 1-0.48 2.89l-0.18 0.39 0.44 0.11a16.83 16.83 0 0 0 3.43 0.46l3.44-0.24 0.45-0.07-0.16-0.4a5.15 5.15 0 0 1-0.28-2.92 25.82 25.82 0 0 0 4.6-0.9 21.72 21.72 0 0 0 2.54-3.58 6.07 6.07 0 0 1 2.8 1.33l0.34 0.28 0.25-0.36a13.91 13.91 0 0 0 2.33-6l0.06-0.42zm-10.73 4.83a20 20 0 0 1-9.83-0.33 17.16 17.16 0 0 1-2-4.18 16.22 16.22 0 0 1-0.74-4.55 18.44 18.44 0 0 1 3.67-3 19.34 19.34 0 0 1 4.42-2.05 19.57 19.57 0 0 1 4.26 2.34 18.38 18.38 0 0 1 3.48 3.29 16.19 16.19 0 0 1-1.05 4.47 17.09 17.09 0 0 1-2.21 4.01zm-3.32-7.39a2.08 2.08 0 0 0 4.15 0.14 2.08 2.08 0 0 0-4.15-0.14zm-2.69-0.09a2.08 2.08 0 1 1-2-2 2 2 0 0 1 2 2z"/>
+   </g>
+  </g>
+  <text id="text257-0-8-7" class="cls-22" x="1148.4604" y="550.76685" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1312-5-0-5" font-family="'Open Sans'" font-size="14.667px" font-weight="600" text-align="end" text-anchor="end" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Node</tspan></text>
+  <path id="path2202" class="cls-8" d="m1168.6 519.39-1 0.22-1.75 1.68-1.37 2.74-0.78 3.82v33.602l0.78 3.8 1.37 3 1.75 1.47 1 0.2h38.909l1.07-0.2 1.76-1.47 1.2699-3 0.78-3.8v-33.602l-0.78-3.82-1.2699-2.74-1.76-1.68-1.07-0.22z"/>
+  <text id="text270-1-1" class="cls-22" x="1076.4661" y="67.477371" font-family="'Open Sans', sans-serif" font-size="12px"><tspan id="tspan1047-7-1" font-family="'Open Sans'" font-size="14.667px" font-weight="600" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">API server</tspan></text>
+  <g id="use1518" transform="translate(-137.9 -55.356)">
+   <g id="g1609" transform="matrix(.78098 0 0 .78098 964.75 -113.64)" data-name="layer1">
+    <g id="g1601" data-name="g70">
+     <path id="path1597" class="cls-11" d="m463.61 257.22a4.39 4.39 0 0 0-1.6 0.4l-21.81 10.43a4.15 4.15 0 0 0-2.26 2.8l-5.38 23.41a4.12 4.12 0 0 0 0.57 3.17 3.43 3.43 0 0 0 0.24 0.33l15.09 18.77a4.19 4.19 0 0 0 3.26 1.55h24.21a4.19 4.19 0 0 0 3.26-1.55l15.09-18.78a4.12 4.12 0 0 0 0.81-3.5l-5.39-23.4a4.16 4.16 0 0 0-2.26-2.81l-21.81-10.42a4.16 4.16 0 0 0-2.02-0.4z" data-name="path3055"/>
+     <path id="path1599" class="cls-13" d="m463.6 255.53a4.48 4.48 0 0 0-1.69 0.42l-23 11a4.39 4.39 0 0 0-2.39 3l-5.68 24.71a4.33 4.33 0 0 0 0.6 3.34c0.08 0.12 0.16 0.24 0.25 0.35l15.94 19.82a4.43 4.43 0 0 0 3.44 1.64h25.53a4.43 4.43 0 0 0 3.45-1.64l15.95-19.85a4.39 4.39 0 0 0 0.85-3.7l-5.69-24.71a4.41 4.41 0 0 0-2.38-3l-23-11a4.35 4.35 0 0 0-2.18-0.38zm0 1.69a4.17 4.17 0 0 1 2 0.41l21.84 10.37a4.19 4.19 0 0 1 2.26 2.81l5.39 23.4a4.12 4.12 0 0 1-0.81 3.5l-15.09 18.78a4.19 4.19 0 0 1-3.26 1.55h-24.21a4.19 4.19 0 0 1-3.26-1.56l-15.09-18.77a3.43 3.43 0 0 1-0.24-0.33 4.12 4.12 0 0 1-0.57-3.17l5.38-23.41a4.17 4.17 0 0 1 2.26-2.8l21.8-10.37a4.21 4.21 0 0 1 1.6-0.41z" data-name="path3054-2-9"/>
+    </g>
+    <g id="g1605" class="cls-14" data-name="text2066">
+     <text id="text1603" class="cls-18" transform="translate(457.08,312.94)">api</text>
+    </g>
+    <path id="path1607" class="cls-13" d="m463.76 267.54c-0.51 0-14.67 6.94-14.86 7.3-0.44 0.86-3.66 15.72-3.47 16s2.43 3.13 5.15 6.54l5 6.2h16.31l5.19-6.49 5.19-6.48-1.81-8c-1-4.38-1.9-8-2-8.13-0.25-0.24-14.4-7-14.67-7zm0.87 7.28c0.68 0 0.75 1.07 2.22 1.18 1.91 0.14 1.71-1.64 3.17-0.4s-0.32 1.33 0.13 3.2 2.09 1.12 1.36 2.89-1.37 0.1-3 1.11-0.42 2.34-2.34 2.19-0.51-1.27-2-2.51-2.35 0.32-2.8-1.54 1.05-0.89 1.78-2.67-1-2.13 0.6-3.14a2.28 2.28 0 0 1 0.52-0.26 0.88 0.88 0 0 1 0.34-0.05zm1.91 2.1a2.86 2.86 0 0 0-0.82 0.12 2.77 2.77 0 1 0 0.82-0.12zm-11 4.78a1.84 1.84 0 0 1 0.55 0.1c1.76 0.54 0 1.47 1.22 2.81s2.31-0.37 2.73 1.43-1.29 0.71-1.83 2.47 1.47 1.81 0.13 3.07-1.26-0.76-3.06-0.34-0.83 2.18-2.59 1.64 0-1.47-1.23-2.82-2.31 0.37-2.72-1.42 1.29-0.71 1.83-2.47-1.48-1.82-0.13-3.07 1.26 0.75 3.05 0.34c1.57-0.36 1-1.76 2.05-1.74zm13.1 1.92a2.08 2.08 0 0 1 0.63 0.15c2 0.79-0.65 2 0.93 3.51s2.67-1.22 3.55 0.77-1.88 1-1.83 3.14 2.75 1 2 3.06-2-0.65-3.51 0.93 1.21 2.67-0.78 3.55-1-1.87-3.14-1.83-1 2.75-3.05 2 0.64-2-0.94-3.51-2.67 1.22-3.54-0.78 1.87-1 1.82-3.14-2.75-1-2-3.05 2 0.64 3.51-0.93-1.22-2.67 0.77-3.55 1 1.87 3.14 1.82c1.91 0 1.26-2.12 2.43-2.11zm-14.25 0.94a2.78 2.78 0 1 0 2.78 2.78 2.77 2.77 0 0 0-2.77-2.78zm12 2.66a4.1 4.1 0 1 0 4.09 4.1 4.1 4.1 0 0 0-4.13-4.1z" data-name="path1984"/>
+   </g>
+  </g>
+  <path id="path4387" d="m1156.2 495.21v1.5h9v-1.5zm10.5 0v1.5h9v-1.5zm10.5 0v1.5h9v-1.5zm10.5 0v1.5h9v-1.5zm10.5 0v1.5h9v-1.5zm10.5 0v1.5h9v-1.5zm10.5 0v1.5h5.3809v-1.5z" color="#000000" color-rendering="auto" dominant-baseline="auto" fill="#326ce5" fill-rule="evenodd" image-rendering="auto" shape-rendering="auto" solid-color="#000000" stop-color="#000000" style="font-feature-settings:normal;font-variant-alternates:normal;font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-position:normal;font-variation-settings:normal;inline-size:0;isolation:auto;mix-blend-mode:normal;shape-margin:0;shape-padding:0;text-decoration-color:#000000;text-decoration-line:none;text-decoration-style:solid;text-indent:0;text-orientation:mixed;text-transform:none;white-space:normal"/>
+ </g>
 </svg>
diff --git a/static/images/docs/node-capacity.svg b/static/images/docs/node-capacity.svg
new file mode 100644
index 0000000000..0bbacfade6
--- /dev/null
+++ b/static/images/docs/node-capacity.svg
@@ -0,0 +1,27 @@
+<svg width="580" height="400" xmlns="http://www.w3.org/2000/svg">
+    <g>
+        <title>background</title>
+        <rect x="-1" y="-1" width="506.34798" height="349.82619" id="canvas_background" fill="#fff" opacity="0"/>
+        <g id="canvasGrid" display="none">
+            <rect opacity="0" id="svg_4" width="100%" height="100%" x="0" y="0" stroke-width="0" fill="url(#gridpattern)"/>
+        </g>
+    </g>
+    <g>
+        <title>Layer 1</title>
+        <rect fill="#326ce5" stroke="#000" stroke-width="1.5" x="126.27611" y="84.45079" width="336.49766" height="242.99831" id="svg_1"/>
+        <rect fill="#DDDDDD" stroke-width="0.5" x="127.2761" y="261.05662" width="95.3" height="66" id="svg_2" stroke="#000"/>
+        <rect fill="#BBBBBB" stroke-opacity="null" x="222.4421" y="261.28292" width="108.3" height="66" id="svg_3" stroke="#000"/>
+        <rect fill="#ffffff" stroke-width="0.5" stroke-opacity="null" x="330.77469" y="261.28292" width="131" height="66" id="svg_5" stroke="#000"/>
+        <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="126.25112" y="28.72775" id="svg_6" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(3.8729541301727295,0,0,0.698510413795276,-358.40104965794853,12.1371268265946) " stroke="#000"/>
+        <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="96.33037" y="92.52907" id="svg_9" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.6039765318373469,0,0,0.6213608286284256,43.920523540443796,7.5797796894100635) " stroke="#000">Node Capacity</text>
+        <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="146.65172" y="483.69046" id="svg_10" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">kube-reserved</text>
+        <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="333.31931" y="486.27149" id="svg_11" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">system-reserved</text>
+        <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="559.50522" y="487.562" id="svg_12" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">eviction-threshold</text>
+        <text fill="#ffffff" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="246.31519" y="182.62777" id="svg_14" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.8530217831379474,0,0,0.8530217831379474,32.26513711483058,11.272510077186126) " stroke="#000">allocatable</text>
+        <text fill="#ffffff" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="191.56677" y="217.51295" id="svg_15" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.6610298739213645,0,0,0.6148439389614191,97.43948566238379,61.05811172356589) " stroke="#000">(available for pods)</text>
+        <line fill="none" stroke="#000" stroke-width="null" stroke-opacity="null" fill-opacity="null" x1="221.6918" y1="348.02537" x2="222.35847" y2="348.02537" id="svg_19" transform="rotate(0.9628710746765137 222.02513122558057,348.0253906249988) "/>
+        <line stroke="#000" stroke-linecap="square" id="svg_8" y2="261.50152" x2="462.85834" y1="261.50152" x1="125.8955" fill-opacity="null" stroke-opacity="null" fill="none"/>
+        <line stroke="#000" stroke-linecap="square" id="svg_13" y2="328.33922" x2="331.2413" y1="261.98921" x1="331.2413" fill-opacity="null" stroke-opacity="null" fill="none"/>
+        <line stroke="#000" stroke-linecap="square" id="svg_17" y2="327.36391" x2="222.00652" y1="261.50155" x1="222.00652" fill-opacity="null" stroke-opacity="null" fill="none"/>
+    </g>
+</svg>
diff --git a/static/images/kccnc-na-virtual-2020-white.svg b/static/images/kccnc-na-virtual-2020-white.svg
new file mode 100644
index 0000000000..70521bcbd3
--- /dev/null
+++ b/static/images/kccnc-na-virtual-2020-white.svg
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 400 310"><defs><style>.cls-1,.cls-3,.cls-4{fill:#fff;}.cls-2{clip-path:url(#clip-path);}.cls-3{fill-rule:evenodd;}.cls-4{opacity:0.8;isolation:isolate;}.cls-5{clip-path:url(#clip-path-2);}.cls-6{clip-path:url(#clip-path-3);}</style><clipPath id="clip-path"><rect class="cls-1" x="9.79569" y="160.14195" width="79.43065" height="0.62791"/></clipPath><clipPath id="clip-path-2"><rect class="cls-1" x="156.72669" y="7.71674" width="0.62791" height="127.77975"/></clipPath><clipPath id="clip-path-3"><rect class="cls-1" x="311.56937" y="160.14195" width="79.43063" height="0.62791"/></clipPath></defs><path class="cls-1" d="M182.85914,292.7358c-2.75067.8255-5.67764.01808-8.47133,1.153-1.73309.704-3.83641.47478-5.76619.72173a51.703,51.703,0,0,0-10.93781,2.2342c-1.39641.4972-3.08706.11218-4.37493,1.18247l-1.14184.0788c-2.23233.46022-4.4743.87884-6.69352,1.3953a12.00353,12.00353,0,0,1-4.40508.22346c-2.55954-.363-4.96021-1.72828-5.32526-4.69871a12.46421,12.46421,0,0,1,.56191-2.631c.562-1.26055,1.44726-2.23838,3.08173-1.8056a22.20373,22.20373,0,0,0,14.27343-.87211,15.32231,15.32231,0,0,1,3.60928-.5241c5.06278-.6694,10.07491-1.6633,15.11688-2.42086,1.81337-.27246,3.55694-1.27722,5.47883-.836a.79779.79779,0,0,0,1.04849-.00724l.14693.01145.961-.34946c2.41577-.18432,4.81756-.70972,7.25777-.29726-.10143.16087-.19153.45384-.3059.46363-5.31268.45443-10.61389,1.26824-15.84564,2.07582-4.38932.67754-9.12251.6529-13.00451,2.91895,2.45069.58278,4.90179-1.04768,7.57118-.75214a11.7403,11.7403,0,0,0,5.28506-.89721,4.13532,4.13532,0,0,1,1.5067-.297,33.46744,33.46744,0,0,0,7.65976-.35154c1.85775-.3605,3.91222.10543,5.69145-.4254,2.25143-.6717,4.61072-.18716,6.75667-.96413,2.17339-.7869,4.41631-.63867,6.6251-.85215,2.96669-.28673,6.0817.13761,8.9068-.60441,4.64955-1.22116,9.3232.05839,13.97967-.84027,2.98819-.5767,6.21508.09883,9.33571.18838,4.31323.12381,8.63351.11554,12.93875.36828a58.4628,58.4628,0,0,1,10.88111,1.90691c-.0353-.50785-.07086-.85819-.47369-1.01452-2.46458-.95641-5.12283-1.08012-7.66215-1.83-3.38536-.99973-7.008-.9158-10.56771-1.00534-3.44061-.08655-6.86841-.59916-10.30947-.77728-2.79033-.14444-5.55153.51251-8.38267.39333-1.11964-.04714-2.45271.4514-3.743.48778-2.04523.05767-4.13848-.30707-6.08974-.14288-2.76425.23258-5.46213,1.17921-8.33121,1.19733-3.49668.022-6.9426.94777-10.46127.84278-.62972-.0188-1.30176.89267-1.89219-.06787.294-.69805.83041-.74234,1.54316-.83213,3.45633-.4354,6.93774-.8554,10.386-1.11178,3.5222-.26185,7.06311-.51951,10.59283-.77839a167.95962,167.95962,0,0,1,17.79043-.52812c4.14395.13459,8.32393.07867,12.47009.30473,5.28883.28838,10.42484,1.6301,15.5819,2.802,2.22519.50565,4.365,1.36551,5.51326,3.1266,1.86808,2.8651,4.50519,5.56431,3.66638,9.59586-.2598,1.24855-1.39494,1.721-1.7762,2.78229a1.30229,1.30229,0,0,1-1.06562-.01013c-.61683-.44553-.39145-1.08773-.18648-1.71427.77168-2.35866.37043-4.13232-1.46435-5.04045a15.37869,15.37869,0,0,0-3.59213-1.73715c-2.51758-.46387-4.9-1.50451-7.53111-1.52914-3.28585-.03074-6.37844-1.46357-9.677-1.57377-6.57169-.21955-13.17257-.79794-19.70591.04417-5.45019.7025-10.96656-.05688-16.33781.9181-4.86822.88367-9.824.86986-14.69049,1.89C186.9668,292.32135,184.84792,292.29622,182.85914,292.7358Zm34.48914-5.88095c-1.34993-.26488-2.70471-.6201-4.07.1797C214.73388,287.91541,216.04367,287.43361,217.34828,286.85485Zm-22.2821,1.76452c-1.79915-1.06345-2.72813-.01212-4.31567.67292Zm45.55217-1.438c-.79763-.49884-1.57308-1.21069-2.627-.4719C238.97416,286.45015,239.64291,287.411,240.61835,287.18141Z"/><g id="_45W0Vf" data-name="45W0Vf"><path class="cls-1" d="M65.13117,261.64292c1.17711-1.01283,1.45974-2.4479,1.816-3.848a14.09752,14.09752,0,0,1,.42878-1.63177c.16824-.43392.197-1.27014.82222-1.06879.64188.2067.097.8886.0666,1.36234-.01669.2602-.332.48664-.0466.8396.76763-.95236.45028-2.33512,1.33907-3.20061.22555-.21963.33787-.65922.72631-.52562.49426.17.34062.63439.213.96427a11.49129,11.49129,0,0,0-.94717,4.05373,89.585,89.585,0,0,0,3.0952-10.48112c-.38562.20141-.5068.90394-1.05136.56859-.38671-.23814-.30245-.65578-.20218-1.023.29629-1.08494.58748-2.17208.92335-3.245.123-.39305.35479-.91066.87563-.63481.4143.21942.17694.655-.02986.98663-.22493.36072-.4747.72228-.07809,1.22958,4.08468-10.49916,8.9534-20.60378,13.20189-30.99562a31.94413,31.94413,0,0,0-4.59581,6.34126,1.62,1.62,0,0,0-.19726,1.351c.14121.37645.16438.804-.23459.9999a1.3228,1.3228,0,0,0-.824,1.80617c.04523.1344-.08613.47208-.16936.48413-1.10613.16023-1.37285,1.30045-2.14644,1.92731-.33259-.68774.03119-1.17288.198-1.67957,2.989-9.08027,7.60089-17.475,11.12975-26.32813.8526-2.139,3.63071-4.46927,6.74843-3.28245,3.03833,1.1566,4.48411,3.54879,2.18949,7.11553A93.02406,93.02406,0,0,0,93.35,212.02766q-5.10369,10.11359-9.85526,20.39928a85.14615,85.14615,0,0,0-3.661,8.64469c-1.02965,3.07091-2.286,6.08455-3.142,9.24876-1.08789,4.02143-2.00366,8.09786-3.2244,12.08775-.22019.71969-.82036,1.79419-.12985,2.21837.73242.44992,1.29278-.65608,1.87594-1.143a232.55139,232.55139,0,0,0,18.073-16.32478A205.354,205.354,0,0,0,112.7974,224.043c3.93176-5.47065,8.12925-10.805,10.74317-17.11608.2154-.52008.49109-1.01619.69024-1.54182a8.70229,8.70229,0,0,0-.938-8.68662c-.4877-.67565-1.23287-1.37608-.56973-2.24628a1.8782,1.8782,0,0,1,2.45785-.769.57956.57956,0,0,0,.40744.0729,3.37865,3.37865,0,0,1,3.88938.72558,8.41282,8.41282,0,0,1,2.97219,4.975,9.33851,9.33851,0,0,1-.0961,3.358c-.94171,4.75725-3.4034,8.85289-5.8864,12.8677a157.91346,157.91346,0,0,1-11.345,15.70674c-2.98279,3.71444-5.86112,7.5303-8.96529,11.14093A163.3825,163.3825,0,0,1,81.215,266.44684a14.355,14.355,0,0,1-8.96827,3.10882,5.476,5.476,0,0,1-3.3076-1.22782,8.50068,8.50068,0,0,1-2.94543-4.96374,5.44965,5.44965,0,0,0-.86254-1.43942Zm60.6383-49.749A364.51451,364.51451,0,0,1,100.1558,244.992,175.84107,175.84107,0,0,0,125.76947,211.894Z"/><path class="cls-1" d="M246.31671,253.71493a7.60084,7.60084,0,0,0,5.48771-2.82968c2.18274-3.007,4.95052-5.62446,6.35089-9.18737a6.43858,6.43858,0,0,1,1.35127-1.95694c2.07854-2.20389,4.1546-4.415,6.33266-6.51879a36.7786,36.7786,0,0,1,7.59631-5.55393c2.09313-1.17508,6.02472-.5308,7.24226,2.34335.14877.35124.25617.72386.68486.82241,1.47751.33969,2.2626,1.69466,3.53131,2.4006,1.59734.8888,2.08081,3.93807,1.30566,5.615-1.63407,3.53491-3.22863,7.088-4.84736,10.63005-1.20872,2.64486-2.43234,5.283-3.38773,8.03448-.16654.47961-.519.98543-.14678,1.464.41429.53274,1.0335.34543,1.56948.20232a20.58581,20.58581,0,0,0,4.97-2.295c1.38-.8018,2.71559-1.68672,4.13143-2.4175.69894-.36076,1.50317-1.13365,2.33471-.12323.14124.17163.34047.10421.51411.01811.68112-.33775,1.1978-.99615,2.06539.04018.3746.44745,1.3092-.328,1.30133-1.281-.014-1.6867-.301-3.412.18246-5.049,1.74067-5.89316,3.435-11.816,6.4258-17.23749,1.02311-1.85461,1.71118-3.88461,2.84712-5.65424a109.07039,109.07039,0,0,1,7.185-10.35832c1.35863-1.65989,2.77349-3.31372,4.0028-5.103.66642-.97,2.00347-1.37912,2.56362-2.54512-.19606-.26084-.76279.22134-.7569-.305a1.20736,1.20736,0,0,1,.97321-1.08637,4.2886,4.2886,0,0,0,2.96362-2.60963,11.06412,11.06412,0,0,1,2.38551-3.54883,16.83619,16.83619,0,0,1,2.44-2.33111c2.17837-1.82468,4.77491-2.21264,6.90742-1.02557,1.85906,1.03485,3.18634,4.21761,2.76087,6.67571a17.84584,17.84584,0,0,1-1.84756,4.99411c-5.09979,10.0783-12.11306,18.737-19.82462,26.88562a42.84422,42.84422,0,0,1-4.45008,4.5028c-1.12045.87949-2.2771,1.68171-3.8476,1.10068-.69943-.25876-.88612.3544-1.07467.822a39.01837,39.01837,0,0,0-1.53017,4.6788,46.60438,46.60438,0,0,0-1.95428,10.31622,3.222,3.222,0,0,0,3.12474,3.66311,16.74643,16.74643,0,0,0,8.3926-1.98953,53.9576,53.9576,0,0,0,11.01792-7.52967c.564-.46871,1.274-1.62893,2.05016-.68568.70968.86247-.25072,1.57908-.95249,2.16375-1.91547,1.59589-3.98817,2.97427-6.02233,4.4066a2.7249,2.7249,0,0,0-1.42482,1.856,6.37939,6.37939,0,0,0,3.04361-1.13009c2.27853-1.59917,4.71314-3.1195,6.173-5.64848.13706-.23744.30163-.59106.61923-.41943.45142.244.19147.66076.06918.99391a17.914,17.914,0,0,1-9.06546,9.91041,26.16687,26.16687,0,0,0-3.5026,2.35341c-3.07437,2.27591-6.55849,2.64545-10.19451,2.24739a4.63833,4.63833,0,0,1-3.84191-2.51978c-1.23245-2.38728-3.25564-4.23439-4.51193-6.60421-.50851-.95924-.88014-.79044-1.6165-.08215-3.62725,3.489-7.39887,6.70861-12.30759,8.45444a6.65213,6.65213,0,0,1-7.43383-1.77013,13.75055,13.75055,0,0,1-3.36529-5.43363,8.30548,8.30548,0,0,1,.3397-5.79517c-.79506.14027-1.045.67621-1.36848,1.057a113.12729,113.12729,0,0,1-10.09983,10.57192c-4.7986,4.35944-9.00925,1.52776-10.89864-3.27609-.94731-2.40853-.74955-2.48632-.12279-4.071-.19094-.17063-.37224-.04764-.48492.075-2.19154,2.3849-5.08951,3.83181-7.63192,5.74964a19.38666,19.38666,0,0,1-4.60313,2.41206c-3.86827,1.53668-6.63072.58825-9.29682-2.60448-2.29024-2.74264-2.71975-5.83131-2.65626-9.1585.00764-.40015.23732-.92641-.24719-1.14374-.47852-.21463-.73386.29551-1.02707.56677-4.55156,4.21091-9.30019,8.19275-14.11874,12.09029-2.4008,1.94192-4.888,2.12008-6.65188.47355a14.8734,14.8734,0,0,1-2.47689-3.73734c-.51523-.90761-.70386-.80836-1.46539-.22039-2.65339,2.04864-5.19055,4.33893-8.7052,4.89725a10.14048,10.14048,0,0,1-10.86852-5.28113c-1.12058-2.04911-2.67118-3.8894-3.13989-6.26057-.66183-3.34811.147-6.57071,1.18692-9.67174a100.95623,100.95623,0,0,1,7.42912-16.083,86.662,86.662,0,0,1,5.92312-9.90338c.28558-.38995.77014-.84684.44421-1.37967-.31507-.51509-.94484-.33862-1.43426-.29835-1.77513.14606-3.5435.37594-5.31909.51421a12.40936,12.40936,0,0,1-3.64116-.22357,5.01761,5.01761,0,0,1-3.92354-4.8695c.01577-.53974.28562-1.06425.86139-.61126,2.66514,2.09679,5.75091,1.21249,8.67807,1.24106,2.012.01963,4.02971-.22124,6.04461-.00212a2.90883,2.90883,0,0,0,2.754-1.29172c2.20862-2.692,3.314-5.97228,4.95857-8.96147a26.05873,26.05873,0,0,1,3.49014-5.26885c1.39812-1.51483,1.82932-3.57492,3.1048-5.16334,1.386-1.72608,2.72993-1.61749,4.72992-.67036,1.61605.76529,1.83349,2.11637,2.482,3.283.84956,1.52819.47288,2.94764-.69036,4.38116-2.21445,2.729-4.18855,5.65185-6.30049,8.46567-1.03294,1.37624-1.794,2.98822-3.36106,3.922-.54237.32318-.384.70656.12319.92233a2.31551,2.31551,0,0,0,.95193.19484c3.33478-.11343,6.65628.21169,9.98513.27754a4.92863,4.92863,0,0,0,1.12055-.07123,2.44071,2.44071,0,0,1,3.27284,1.96391c.07722.26945.10085.55382.15932.82915.45812,2.15737.16338,2.31-1.96359,2.074a68.08089,68.08089,0,0,0-8.64552-.63673c-2.611.04337-5.22736-.05059-7.83625-.18387a1.62178,1.62178,0,0,0-1.633.78856,57.48442,57.48442,0,0,1-4.51516,5.90311c-.7573.85336-1.71562,1.88423-1.42783,3.30834.05837.28882-.04272.45472-.35005.45415-.24369-.00045-.60219.0369-.58611.26339.14809,2.08606-2.35771,2.61948-2.60217,4.487-.03947.30148-.28124.5658-.05609.89005a.74037.74037,0,0,1-.15379,1.018c-1.75671,1.72944-2.38072,4.16016-3.79259,6.10323a.97259.97259,0,0,0-.24537,1.03309,3.63764,3.63764,0,0,1-.9506,4.40657,1.49407,1.49407,0,0,0-.571,1.53723c.213,2.13315-.6555,4.147-.88133,6.24453a35.90734,35.90734,0,0,0-.21616,4.071q.02019,3.30795,3.34888,2.81719a12.66617,12.66617,0,0,0,3.4832-1.09222,66.78573,66.78573,0,0,0,11.47037-6.84067,12.16727,12.16727,0,0,0,3.63358-4.92078,14.04923,14.04923,0,0,1,1.81278-2.94491,10.96234,10.96234,0,0,0,1.64417-2.7746,47.28294,47.28294,0,0,1,6.14255-10.40917,3.919,3.919,0,0,1,5.9-.97752c1.72534,1.18492,2.08919,3.89306.70977,6.07946a35.76622,35.76622,0,0,1-5.44844,6.98123c-3.343,3.17482-5.31163,7.24143-7.57072,11.12692-.65973,1.1347-1.21743,2.32871-1.82233,3.49532-.12575.24251-.39586.5049-.203.76057.2386.31631.61049.1672.90386.02611a9.67008,9.67008,0,0,0,1.098-.62829,34.20123,34.20123,0,0,0,6.20526-5.0708c4.05453-4.29681,8.25478-8.451,12.23423-12.82468a140.835,140.835,0,0,1,10.96984-11.03618c.94021-.828,1.92919-1.544,3.29116-1.02173.35121.13467.91835.34921.83463.65172-.37943,1.371.59013,1.279,1.40952,1.58688a2.4894,2.4894,0,0,1,1.35992,2.44,7.68544,7.68544,0,0,1-1.66658,5.51425,122.584,122.584,0,0,0-8.81869,12.87159A59.17844,59.17844,0,0,0,230.612,257.494c-.18952.408-.46633.90793-.09576,1.32606.40331.455.98484.27991,1.45741.12388a22.64367,22.64367,0,0,0,4.72437-2.17591c3.08209-1.88528,6.30723-3.53866,9.23262-5.67932.3318-.24279.73721-.63676,1.12521-.329.47844.37952-.08813.60732-.2886.8764a.37008.37008,0,0,0-.05422.24357C248.172,252.65631,246.69814,252.94264,246.31671,253.71493Zm32.214-19.6287a5.8035,5.8035,0,0,0-3.14636,1.20908,57.80465,57.80465,0,0,0-10.15881,9.05406,75.16566,75.16566,0,0,0-9.65677,12.5989,16.67242,16.67242,0,0,0-1.21051,2.53421c-.17391.43467-.65448,1.0202-.07756,1.3946.556.36083,1.10558-.10268,1.47724-.50989,2.419-2.65016,5.5064-4.609,7.66068-7.55022a10.19034,10.19034,0,0,1,3.08322-2.44871c1.02032-.61978,1.00725-2.77777,2.153-3.30392,1.41888-.65156,1.57053-2.08238,2.54479-2.83271,1.33857-1.03088,1.82253-3.0626,3.83736-3.27967.04872-.00525.13249-.16516.11529-.23075-.27121-1.0346.18783-1.24109,1.109-1.05834.20745.04115.41025-.3047.3335-.52962-.2774-.81288.2989-1.20692.75488-1.66213a7.508,7.508,0,0,0,1.47508-2.36852C279.166,234.33547,279.02966,234.047,278.53069,234.08623Zm28.54735,1.3373a3.59894,3.59894,0,0,0,1.40145-1.16943c1.854-2.05552,3.67922-4.137,5.53323-6.19253a107.77688,107.77688,0,0,0,16.54735-23.53222c.2704-.53581.97-1.25681.3357-1.7098-.46478-.33194-.99507.50563-1.43658.89464-3.8632,3.40364-6.68709,7.70374-9.93576,11.63334a71.09473,71.09473,0,0,0-4.76856,6.83113c-2.44059,3.77953-4.69656,7.67233-7.11595,11.46252A2.55389,2.55389,0,0,0,307.078,235.42353ZM215.93,256a62.73047,62.73047,0,0,0,16.34351-15.40892c-.56124-.00558-.83742.38259-1.15955.68724-2.17337,2.05544-4.2458,4.23042-6.53463,6.14731-2.13429,1.78747-3.66125,4.41759-6.67309,5.05674a.27871.27871,0,0,0-.17207.20378C217.7946,254.1477,216.60578,254.92717,215.93,256Zm-37.77165-7.92828c3.41336-10.92087,9.12028-20.69042,15.19593-30.27488A98.146,98.146,0,0,0,178.15839,248.07173Zm127.86983-20.66a159.684,159.684,0,0,1,16.54147-22.51966c-.99868-.05185-1.83244.01269-2.10427.85536a10.6516,10.6516,0,0,1-2.22378,3.37758c-2.52694,3.08966-4.85943,6.31961-7.06388,9.64062A73.48176,73.48176,0,0,0,306.02822,227.41174Z"/><path class="cls-1" d="M163.84774,230.72032c1.47827-1.03737,2.96-2.06988,4.43386-3.11345a16.82059,16.82059,0,0,1,4.906-2.71421c1.37058-.3993,2.76877-.68754,3.88346.64986a1.63985,1.63985,0,0,0,.61483.31544c1.65365.71728,2.19531,1.69242,1.66466,3.46831a15.59941,15.59941,0,0,1-5.82219,8.73389,27.23293,27.23293,0,0,1-3.09309,1.947c-.46177.239-1.2237,1.13036-1.64386-.17892-.03048-.095-.51083-.044-.78182-.06378-.34187-.02489-.75858.43986-1.00573-.03752-.181-.34958.11084-.71663.2972-1.04071,1.14383-1.989,2.78324-3.67319,3.60611-5.85928.12644-.33591.45654-.60654.32684-1.09427a48.76316,48.76316,0,0,0-7.66795,5.67369,69.96105,69.96105,0,0,0-9.67624,10.20039,7.54036,7.54036,0,0,1-2.634,2.4929,1.67483,1.67483,0,0,0-.59083.58c-2.18058,3.28348-4.36925,6.56192-6.51135,9.87046a11.05409,11.05409,0,0,0-1.80374,4.2459,4.37352,4.37352,0,0,1-1.05,1.97241c-.58693.72606-1.151.79946-1.549-.19565-.08123-.20312.02146-.59444-.26141-.58368-1.74452.06636-2.01879-1.46862-2.72762-2.49364-.39892-.57685-.7356-.66267-1.22521-.19594-2.50788,2.39066-5.96091,2.73478-8.97353,3.97374-3.07209,1.26341-7.21142-.90017-8.62727-3.88872-.32216-.68-.56056-1.40532-1.5127-1.45461-.36906-.01911-.50452-.38808-.60306-.70631a11.176,11.176,0,0,1,.09606-7.955,166.864,166.864,0,0,1,11.1045-21.15781,25.25762,25.25762,0,0,0,1.83572-3.48406,2.78854,2.78854,0,0,1,3.654-1.59083c3.004,1.05287,4.62964,5.58943,2.86612,8.26974-3.3,5.01563-6.83346,9.894-9.7028,15.17442-1.5068,2.773-3.28629,5.48947-3.604,8.77525a2.31933,2.31933,0,0,1-.124.40086c-.15786.54221-.97992.99471-.41491,1.61666.51673.56881,1.24145.20442,1.8643.05289a56.28646,56.28646,0,0,0,14.84213-6.325,3.04944,3.04944,0,0,0,1.15079-1.38347c1.20923-2.39686,2.81169-4.54615,4.24086-6.80543,2.75834-4.3605,5.28989-8.86458,8.05316-13.22181a74.79837,74.79837,0,0,0,4.39914-7.68782c.98436-2.0533,2.39463-2.69838,4.60936-2.33964a4.42663,4.42663,0,0,1,3.918,3.84357C164.80451,228.60872,163.92385,229.47739,163.84774,230.72032Zm-14.9916,18.50041c-.404-.04714-.60391.22976-.79129.48-2.52812,3.37663-4.58016,7.059-6.80837,10.62823-.20327.32561-.37489.76958.01952,1.00732.56189.33871.72637-.252.88686-.58711a28.47054,28.47054,0,0,1,2.29124-4.01422c1.36307-1.95655,2.66095-3.95946,3.94638-5.96838C148.67917,250.331,149.137,249.88519,148.85614,249.22073Zm-5.73451,2.90021c3.06947-3.53646,5.03688-7.7706,7.40289-11.7524A71.2109,71.2109,0,0,0,143.12163,252.12094ZM123.296,243.93781a44.5916,44.5916,0,0,0-5.32542,11.919.94284.94284,0,0,0,.55755,1.28722C119.31379,252.3805,121.26917,248.16668,123.296,243.93781Z"/><path class="cls-1" d="M141.934,204.69485c2.51158.0548,5.693,2.75284,6.06371,4.98a3.09709,3.09709,0,0,1-.99872,2.66363q-2.904,3.14418-5.85974,6.2404a2.60577,2.60577,0,0,1-3.65137.49111,4.74316,4.74316,0,0,1-2.16808-4.78068,16.40107,16.40107,0,0,1,3.90388-8.11012A4.37831,4.37831,0,0,1,141.934,204.69485Z"/><path class="cls-1" d="M72.94038,241.79119c1.23442-2.68495,1.47128-5.958,3.19818-8.69622.24586-.38985.58457-.88785,1.09626-.6726.63555.26737.22377.80536.07,1.20031q-1.67283,4.29588-3.39067,8.57411c-.11876.29552-.11868.85163-.66452.68475C72.873,242.7664,72.96354,242.34669,72.94038,241.79119Z"/></g><path id="SVGID" class="cls-1" d="M9.79569,160.142H89.22634v.62791H9.79569Z"/><rect class="cls-1" x="9.79569" y="160.14195" width="79.43065" height="0.62791"/><rect class="cls-1" x="9.79569" y="160.14195" width="79.43065" height="0.62791"/><g class="cls-2"><path class="cls-1" d="M9.79569,160.142H89.22634v.62791H9.79569Z"/></g><path class="cls-1" d="M118.42417,116.91033c.6907-.18838,1.507-.37675,2.57443-.56512a18.59291,18.59291,0,0,1,3.26514-.25116,7.55453,7.55453,0,0,1,2.88839.43954,4.41452,4.41452,0,0,1,1.82093,1.31861,4.969,4.969,0,0,1,.94187,2.00932,11.11709,11.11709,0,0,1,.314,2.57443V130.222h-3.83025v-7.34654a5.24264,5.24264,0,0,0-.50233-2.63722,2.05566,2.05566,0,0,0-1.88373-.7535,4.44736,4.44736,0,0,0-.87907.0628c-.314,0-.56512.06279-.81629.06279V130.222h-3.893V116.91033Zm-7.15817,6.3419a5.21687,5.21687,0,0,0-.69071-2.8256,2.63918,2.63918,0,0,0-4.14421,0,4.71514,4.71514,0,0,0-.75349,2.8256,5.06033,5.06033,0,0,0,.75349,2.88839,2.54494,2.54494,0,0,0,4.14421,0,5.4538,5.4538,0,0,0,.69071-2.88839m3.95583,0a8.82514,8.82514,0,0,1-.43953,2.95117,6.7201,6.7201,0,0,1-1.3814,2.32327,6.28366,6.28366,0,0,1-4.89771,2.00931,7.72767,7.72767,0,0,1-2.7628-.50233,6.30257,6.30257,0,0,1-2.13489-1.507,6.53167,6.53167,0,0,1-1.3814-2.32327,8.92012,8.92012,0,0,1,0-5.90235,6.83643,6.83643,0,0,1,1.3814-2.26048,6.12582,6.12582,0,0,1,2.13489-1.4442,6.46383,6.46383,0,0,1,2.7-.50233,7.38321,7.38321,0,0,1,2.7.50233,7.12057,7.12057,0,0,1,2.1349,1.4442,6.8361,6.8361,0,0,1,1.3814,2.26048,7.4931,7.4931,0,0,1,.56511,2.95118M94.06126,130.536c-2.95118,0-5.21166-.81629-6.71864-2.44885-1.56978-1.63257-2.32327-3.95583-2.32327-6.9698a11.46548,11.46548,0,0,1,.69071-4.01863,8.11545,8.11545,0,0,1,4.8977-4.77212,10.20675,10.20675,0,0,1,3.70467-.62791,10.58481,10.58481,0,0,1,2.0721.18838c.62791.12558,1.193.25116,1.63257.37675a12.3576,12.3576,0,0,1,1.193.43953,2.24816,2.24816,0,0,1,.6907.37675l-1.193,3.26513a7.86277,7.86277,0,0,0-1.94653-.75349,10.17117,10.17117,0,0,0-2.51164-.31395,5.83363,5.83363,0,0,0-1.82093.31395,3.7566,3.7566,0,0,0-1.56978,1.00466,6.06081,6.06081,0,0,0-1.13024,1.75815,8.27048,8.27048,0,0,0-.43953,2.63723,9.09326,9.09326,0,0,0,.25116,2.32326,5.79423,5.79423,0,0,0,.87907,1.88373,4.72777,4.72777,0,0,0,1.63257,1.25582,5.58649,5.58649,0,0,0,2.38606.43954,11.36385,11.36385,0,0,0,1.56977-.12558,6.33292,6.33292,0,0,0,1.25582-.25116,8.21258,8.21258,0,0,0,.94187-.314,3.841,3.841,0,0,1,.75349-.31395l1.13024,3.26513a7.65578,7.65578,0,0,1-2.44885.94186,12.13136,12.13136,0,0,1-3.57908.43954M78.5519,121.93363a2.51963,2.51963,0,0,0-.18838-.94186,3.38338,3.38338,0,0,0-.43953-.81629,2.51241,2.51241,0,0,0-.7535-.62791,2.99894,2.99894,0,0,0-1.13024-.25116,2.15042,2.15042,0,0,0-1.13024.25116,1.71423,1.71423,0,0,0-.75349.56511,2.93736,2.93736,0,0,0-.50233.87908,4.70378,4.70378,0,0,0-.25116,1.00466h5.14886Zm-9.1047,1.4442a8.56339,8.56339,0,0,1,.56512-3.20235,5.95146,5.95146,0,0,1,1.507-2.26048,6.30705,6.30705,0,0,1,2.07211-1.3814,6.73327,6.73327,0,0,1,2.44885-.43954,6.10609,6.10609,0,0,1,4.64654,1.75815,7.39706,7.39706,0,0,1,1.69535,5.27445v.75349c0,.25116-.06279.50233-.06279.6907H73.46582a2.33408,2.33408,0,0,0,1.13024,1.88373,4.83381,4.83381,0,0,0,2.63722.69071,11.05637,11.05637,0,0,0,2.07211-.18838,7.87593,7.87593,0,0,0,1.69536-.50233l.50233,3.13955a5.607,5.607,0,0,1-.81629.314,6.67027,6.67027,0,0,1-1.193.25116c-.43953.06279-.87907.12558-1.3814.18837a11.60372,11.60372,0,0,1-1.4442.0628,8.1179,8.1179,0,0,1-3.20234-.56512,5.95143,5.95143,0,0,1-2.26047-1.507,5.1351,5.1351,0,0,1-1.31861-2.26048,7.16735,7.16735,0,0,1-.43954-2.7m-2.57443-.0628a8.81173,8.81173,0,0,1-.50233,2.95118,6.83627,6.83627,0,0,1-1.3814,2.26048,6.0735,6.0735,0,0,1-2.26048,1.44419,8.91279,8.91279,0,0,1-3.014.50233,13.14177,13.14177,0,0,1-1.507-.06279l-1.507-.18838a11.5875,11.5875,0,0,1-1.44419-.25116c-.43954-.12558-.87908-.18837-1.193-.314V110.44287l3.89305-.62791v6.84422a8.89227,8.89227,0,0,1,1.3814-.43954,5.86859,5.86859,0,0,1,1.507-.12558,6.48654,6.48654,0,0,1,2.57443.50233,4.74739,4.74739,0,0,1,1.88373,1.4442,6.37458,6.37458,0,0,1,1.13025,2.26048,9.20573,9.20573,0,0,1,.43953,3.014m-3.95584-.12558c0-2.51164-.94186-3.76746-2.7628-3.76746a7.69381,7.69381,0,0,0-1.193.12558,7.31007,7.31007,0,0,0-.94187.37675v7.09539a2.5875,2.5875,0,0,0,.75349.06279c.314,0,.62791.0628.94187.0628a2.79547,2.79547,0,0,0,2.38606-1.06745,4.92514,4.92514,0,0,0,.81628-2.88839m-12.68378,6.53026c-.6907.18838-1.507.37675-2.57443.56512a18.59191,18.59191,0,0,1-3.26513.25116,7.55431,7.55431,0,0,1-2.88839-.43954,4.41437,4.41437,0,0,1-1.82094-1.31861,5.39566,5.39566,0,0,1-.94187-2.00931,10.7026,10.7026,0,0,1-.31395-2.57444v-7.6605h3.83025v7.15817a5.69963,5.69963,0,0,0,.50233,2.7,1.94725,1.94725,0,0,0,1.88373.81628,4.44827,4.44827,0,0,0,.87908-.06279c.31395,0,.56512-.0628.81628-.0628V116.47081h3.893v13.24891Zm-17.95823.43954c-.37675-.56512-.81629-1.25582-1.31861-1.94653a23.52555,23.52555,0,0,0-1.63257-2.0721c-.56512-.69071-1.193-1.31862-1.82094-2.00931a22.93836,22.93836,0,0,0-1.88373-1.69536v7.6605H21.53761V112.01266H25.619v6.84421c1.06745-1.13024,2.1349-2.26048,3.20234-3.5163,1.06745-1.193,2.0721-2.32326,3.014-3.32792h4.83491c-1.25582,1.44419-2.44885,2.88839-3.70467,4.207-1.25582,1.3814-2.57443,2.7-3.95584,4.08142a33.935,33.935,0,0,1,4.207,4.26979,55.59986,55.59986,0,0,1,3.893,5.46282H32.27488Z"/><path class="cls-3" d="M64.92621,50.28905l-2.26048.50233c0-.31395-.06279-.62791-.06279-.94186a13.00267,13.00267,0,0,1,1.88374-6.78144l4.39537,3.893a.86665.86665,0,0,0,.25116.18838,7.16075,7.16075,0,0,0-.50233,2.07211c-.12558.06279-.314.06279-.43953.12558Zm8.53958-13.3117v6.15352a5.444,5.444,0,0,0-1.69536.87908c-.18837-.12558-.37674-.314-.56512-.43954l-4.45816-3.13955a12.38724,12.38724,0,0,1,6.71864-3.4535M42.88656,51.16813c2.1349-9.35587,3.95584-17.26754,6.09073-26.6234.94186-4.207,1.56977-5.33724,5.4-7.53492,5.27444-3.07676,9.23028-5.27445,14.88147-8.53958,3.5163-2.00932,4.207-1.88373,4.207,2.44885V32.64477a16.97465,16.97465,0,0,0-10.29773,5.21166l-1.88373-1.31861a.9076.9076,0,0,1-.43954-.62792,3.05822,3.05822,0,0,0-1.00465-1.507,2.05443,2.05443,0,0,0-2.57443,3.20234,2.17556,2.17556,0,0,0,1.00465.50233c.25117.06279.50233.06279.75349.12558a1.55136,1.55136,0,0,1,.56512.25117l1.75815,1.56977A17.19125,17.19125,0,0,0,58.396,49.72393c0,.62791.06279,1.25582.12558,1.88373l-3.83025.81629a3.86229,3.86229,0,0,0-.81629.06279l-.56512.18837c-2.51164.50233-5.02328,1.06745-7.59771,1.63257-3.45351.81628-3.57909.12558-2.8256-3.13955M77.924,43.13087V36.97735a13.20354,13.20354,0,0,1,6.71863,3.39072l-4.8349,3.4535c-.06279.06279-.12558.12558-.18838.12558a6.9777,6.9777,0,0,0-1.69535-.81628m10.80005,7.221-6.02794-1.3814a5.94548,5.94548,0,0,0-.50233-1.88374c.06279-.06279.12558-.12558.18837-.12558l4.45817-3.95583a13.11966,13.11966,0,0,1,1.94653,6.84422,1.224,1.224,0,0,0-.0628.50233M80.87513,17.13539c3.26513,1.56977,5.5884,2.7,8.85354,4.26979,4.52095,2.19768,9.04191,4.39537,13.62565,6.53026,1.13024,4.8977,2.26048,9.7954,3.32793,14.6931.6907,2.95118,1.00466,4.52095,1.69535,7.40935,1.06745,4.58374.94187,4.96049-3.76746,3.893L92.9938,51.29371a12.09766,12.09766,0,0,0,.0628-1.507,16.832,16.832,0,0,0-3.014-9.73261l1.63257-1.507a1.39375,1.39375,0,0,1,.6907-.314,3.28647,3.28647,0,0,0,1.69536-.62791,2.05443,2.05443,0,1,0-2.57444-3.20234h0a2.55658,2.55658,0,0,0-.75349.87907c-.12558.25117-.18837.43954-.31395.6907a.97652.97652,0,0,1-.37675.50233L88.1589,37.79363A17.14455,17.14455,0,0,0,77.86117,32.582V19.33307c.06279-3.07676.314-3.4535,3.014-2.19768M76.85651,56.69373a6.9541,6.9541,0,0,1-1.193.12558,6.82329,6.82329,0,0,1-1.13024-.06279l-.18838.37675-2.7628,5.08607a13.03831,13.03831,0,0,0,4.14421.6907,13.73173,13.73173,0,0,0,4.207-.6907l-2.7628-5.02328a2.20284,2.20284,0,0,1-.314-.50233m4.8977-3.32793,6.028,1.3814a13.02464,13.02464,0,0,1-4.89771,5.96515l-2.38606-5.77677A9.83674,9.83674,0,0,0,81.7542,53.3658M63.6076,54.68441l6.02793-1.3814a8.34534,8.34534,0,0,0,1.31861,1.63257l-.18837.37674-2.19769,5.4a12.934,12.934,0,0,1-4.96049-6.02794M112.96134,65.2961c-2.88839,3.57908-4.207,5.27444-7.09539,8.85353-3.26513,4.08142-5.90235,7.40934-9.16749,11.49076-2.32327,2.95117-4.01862,3.014-7.84888,3.014H62.47735c-5.02328,0-5.4,0-8.47679-3.893-3.07676-3.83026-5.46282-6.84423-8.47679-10.67448-2.38606-3.014-3.014-3.76746-5.4-6.78143-3.70468-4.64654-4.33259-6.34189,1.44419-7.59771l17.83265-4.01863A17.63262,17.63262,0,0,0,66.87272,64.731l-.81628,1.88373a1.10809,1.10809,0,0,1-.50233.56512,2.84756,2.84756,0,0,0-1.25582,1.31861,2.064,2.064,0,0,0,3.70217,1.826l.0025-.00508a3.35314,3.35314,0,0,0,.31395-1.13024,3.05654,3.05654,0,0,0-.06279-.75349,1.13214,1.13214,0,0,1,.12558-.62791l1.00466-1.82094A17.56482,17.56482,0,0,0,75.60067,67.117a16.65224,16.65224,0,0,0,6.2791-1.193L82.88443,67.745a1.02757,1.02757,0,0,1,.12558.75349,2.82517,2.82517,0,0,0,.25116,1.75815A2.064,2.064,0,1,0,86.96946,68.443l-.00362-.00737a2.623,2.623,0,0,0-.6907-.94187,3.81153,3.81153,0,0,0-.62791-.43953.77987.77987,0,0,1-.37675-.50233l-.81629-2.00931a17.22194,17.22194,0,0,0,7.40934-9.04191l19.6536,4.45816c3.95583,1.06745,3.70466,2.44885,1.44419,5.33724"/><path class="cls-3" d="M77.924,43.13087V36.97735a13.20354,13.20354,0,0,1,6.71864,3.39072l-4.8349,3.4535c-.06279.06279-.12558.12558-.18838.12558a6.9777,6.9777,0,0,0-1.69535-.81628m10.80005,7.221-6.02794-1.3814a5.94548,5.94548,0,0,0-.50233-1.88374c.06279-.06279.12558-.12558.18837-.12558l4.45817-3.95583a13.11966,13.11966,0,0,1,1.94653,6.84422,1.224,1.224,0,0,0-.0628.50233M80.87513,17.13539c3.26513,1.56977,5.5884,2.7,8.85354,4.26979,4.52095,2.19768,9.04191,4.39537,13.62565,6.53026,1.13024,4.8977,2.26048,9.7954,3.32793,14.6931.6907,2.95118,1.00466,4.52095,1.69535,7.40935,1.06745,4.58374.94187,4.96049-3.76746,3.893L92.9938,51.29371a12.09766,12.09766,0,0,0,.0628-1.507,16.832,16.832,0,0,0-3.014-9.73261l1.63257-1.507a1.39375,1.39375,0,0,1,.6907-.314,3.28647,3.28647,0,0,0,1.69536-.62791,2.05443,2.05443,0,1,0-2.57444-3.20234h0a2.55658,2.55658,0,0,0-.75349.87907c-.12558.25117-.18837.43954-.31395.6907a.97652.97652,0,0,1-.37675.50233L88.1589,37.79363A17.14455,17.14455,0,0,0,77.86117,32.582V19.33307c.06279-3.07676.314-3.4535,3.014-2.19768m.87907,36.23042,6.028,1.3814a13.02459,13.02459,0,0,1-4.89771,5.96515l-2.38606-5.77677a9.83674,9.83674,0,0,0,1.25582-1.56978m-6.09072,9.48145V56.81932a7.69407,7.69407,0,0,0,1.193-.12558,1.57324,1.57324,0,0,0,.25116.43953l2.76281,5.02329a13.732,13.732,0,0,1-4.207.6907m37.29787,2.44885c-2.88839,3.57908-4.207,5.27444-7.09539,8.85353-3.26513,4.08142-5.90235,7.40934-9.16749,11.49076-2.32327,2.95117-4.01862,3.014-7.84888,3.014H75.72628V67.117a16.65208,16.65208,0,0,0,6.2791-1.193L83.01,67.745a1.02758,1.02758,0,0,1,.12558.75349,2.8251,2.8251,0,0,0,.25116,1.75815,2.064,2.064,0,0,0,3.70467-1.82094,2.62266,2.62266,0,0,0-.6907-.94186,3.81262,3.81262,0,0,0-.62791-.43954.77979.77979,0,0,1-.37675-.50233l-.81629-2.00931a17.222,17.222,0,0,0,7.40934-9.04191l19.6536,4.45817c3.83025,1.06744,3.57908,2.44885,1.31861,5.33723"/><path class="cls-1" d="M258.63652,64.54261H248.21321V88.90553h24.30013V78.48222H258.63652Zm52.17935.06279V78.48222h-13.814l-.12559-.12558V88.90553h24.36292V64.54261H310.75306ZM248.21323,40.17969h10.48611l-.0628-.06279V26.24009h13.814l.06279.12558V15.81678H248.21323Zm48.663-24.36292V26.24009h13.93962V40.1797H321.2392V15.81678Z"/><path class="cls-4" d="M295.62043,40.17969,281.68082,26.24008h15.19543V15.81678H272.51334V26.36567l13.87682,13.814Zm-12.5582,24.36292h-9.23029l11.55355,11.55355,2.38605,2.38606H272.51332V88.90553h24.36292V78.35663l-6.907-6.907Zm27.75364-24.36292V55.37511l-2.38605-2.38606L296.87627,41.49829v9.23028l6.96981,6.907,6.907,6.907H321.2392V40.17969Zm-38.30253,13.814-13.814-13.814H248.15043V64.54261h10.48611V49.34719L272.51336,63.224Z"/><path class="cls-1" d="M197.22691,115.46613l-2.63723,3.13955a6.1729,6.1729,0,0,0-4.521-2.32326,5.04262,5.04262,0,0,0-5.02608,5.05912q.00024.07629.0028.15254a5.02144,5.02144,0,0,0,5.02328,5.27444,6.64,6.64,0,0,0,4.521-2.13489l2.7,2.82559a10.99377,10.99377,0,0,1-7.40933,3.26514,9.096,9.096,0,0,1-9.41865-9.23028c0-5.21166,4.14421-9.1047,9.607-9.1047a10.80648,10.80648,0,0,1,7.15818,3.07675Zm2.19768,15.06985V111.5103h4.45817V130.536Zm22.10245-6.907c0,4.26979-3.014,7.09539-7.53492,7.09539s-7.59772-2.8256-7.59772-7.09539,3.014-7.0326,7.59772-7.0326c4.52094,0,7.5349,2.76281,7.5349,7.0326Zm-10.67447.06279c0,2.13489,1.25582,3.57909,3.07675,3.57909s3.07676-1.4442,3.07676-3.57909-1.25582-3.57908-3.07676-3.57908-3.07677,1.44418-3.07677,3.57908Zm26.56059,6.84422H232.955V128.2755a4.89546,4.89546,0,0,1-4.521,2.44885c-3.014,0-4.96049-2.07211-4.96049-5.27445V116.722h4.45817v7.47213c0,1.63257.87907,2.63722,2.32327,2.63722,1.69537,0,2.7-1.3814,2.7-3.26513V116.722h4.45816Zm17.4559,0H250.4109V128.715a5.11865,5.11865,0,0,1-4.14422,2.00932c-3.89305,0-6.46746-2.8884-6.46746-7.15818,0-4.207,2.51164-7.03259,6.34189-7.03259a5.10338,5.10338,0,0,1,4.26979,2.00931v-7.03259h4.45816V130.536Zm-4.45816-6.84422c0-2.13489-1.25583-3.57908-3.07676-3.57908s-3.07676,1.44419-3.07676,3.57908,1.25582,3.64188,3.07676,3.64188C249.21787,127.27085,250.4109,125.82665,250.4109,123.69176Z"/><path class="cls-1" d="M271.13193,130.536l-8.28842-11.05122V130.536h-4.26978V112.57774h4.01862l8.28842,11.114v-11.114h4.26979V130.536Zm19.842-9.0419v9.0419h-4.33257V128.9662a5.0266,5.0266,0,0,1-4.207,1.82094c-2.95119,0-4.77212-1.82094-4.77212-4.33258,0-2.63722,1.88373-4.14421,5.33723-4.207h3.64188v-.18838c0-1.3814-.87907-2.19768-2.7-2.19768a10.57188,10.57188,0,0,0-4.14421,1.13024l-1.25582-2.95118a14.39254,14.39254,0,0,1,6.40469-1.56978C288.77622,116.53358,290.9739,118.41731,290.9739,121.49408Zm-4.33257,4.39537v-1.25582h-2.8256c-1.31862,0-2.00932.43953-2.00932,1.507,0,1.00466.6907,1.63257,1.94652,1.63257A2.87035,2.87035,0,0,0,286.64133,125.88945Zm16.32566,3.95583a7.90152,7.90152,0,0,1-3.70466.94187c-2.7,0-4.58374-1.507-4.58374-4.39537v-6.09073h-1.94653v-2.88839h1.94653V113.5824H299.074v3.83026h3.64187v2.95118H299.074v5.4c0,1.06744.43954,1.56977,1.25582,1.507a5.20081,5.20081,0,0,0,1.69537-.43954Zm6.78143-17.07915a2.29467,2.29467,0,0,1-2.20125,2.38443q-.061.00245-.122.00163a2.35487,2.35487,0,0,1,0-4.70933,2.20773,2.20773,0,0,1,2.32328,2.32326ZM305.16468,130.536V116.722h4.39537v13.814Zm11.30238,0-5.21164-13.814h4.58373l2.95119,9.79541,3.014-9.79541h4.39539L320.988,130.536Zm24.42571-5.714h-9.73261a3.23048,3.23048,0,0,0,3.26514,2.57444,4.93343,4.93343,0,0,0,3.32792-1.3814l2.32327,2.26048a7.84034,7.84034,0,0,1-6.02792,2.44884c-4.521,0-7.34656-2.82559-7.34656-7.03259,0-4.26979,2.95119-7.09539,7.221-7.09539,4.83492,0,7.221,3.20235,6.96979,8.22563Zm-4.26978-2.38606a2.60547,2.60547,0,0,0-2.7-2.82559c-1.56978,0-2.57442,1.13024-2.88837,2.82559H336.623Z"/><path class="cls-1" d="M358.97658,115.46613l-2.63723,3.13955a6.17283,6.17283,0,0,0-4.521-2.32326,5.04262,5.04262,0,0,0-5.02608,5.05912q.00024.07629.0028.15254a5.02146,5.02146,0,0,0,5.02328,5.27444,6.64,6.64,0,0,0,4.521-2.13489l2.7,2.82559a10.99368,10.99368,0,0,1-7.40933,3.26514,9.096,9.096,0,0,1-9.41866-9.23028c0-5.21166,4.1442-9.1047,9.607-9.1047A10.93762,10.93762,0,0,1,358.97658,115.46613ZM374.486,123.629c0,4.26979-3.014,7.09539-7.53493,7.09539s-7.59769-2.8256-7.59769-7.09539,3.014-7.0326,7.59769-7.0326C371.472,116.59637,374.486,119.35918,374.486,123.629Zm-10.6117.06279c0,2.13489,1.25582,3.57909,3.07677,3.57909s3.07678-1.4442,3.07678-3.57909-1.25582-3.57908-3.07678-3.57908-3.07673,1.44418-3.07673,3.57908ZM391,121.808V130.536h-4.39537v-7.47213a2.36269,2.36269,0,0,0-2.44887-2.63722,2.812,2.812,0,0,0-2.82559,2.8256v7.34654H376.872v-13.814h4.45815v2.26048a5.09662,5.09662,0,0,1,4.64655-2.44885c3.014-.06279,5.02328,2.00931,5.02328,5.21166Z"/><path id="SVGID-2" class="cls-1" d="M156.72669,7.71673h.62792V135.49647h-.62792Z"/><rect class="cls-1" x="156.72669" y="7.71674" width="0.62791" height="127.77975"/><rect class="cls-1" x="156.72669" y="7.71674" width="0.62791" height="127.77975"/><g class="cls-5"><path class="cls-1" d="M156.72669,7.71673h.62792V135.49647h-.62792Z"/></g><path class="cls-1" d="M117.02917,167.77105h-3.76746L107.171,157.22216h-.06279c.12558,1.88373.18837,3.20233.18837,4.01863v6.59306h-2.63722v-14.0024h3.76746l6.09073,10.48609h.0628c-.12558-1.82093-.12558-3.07675-.12558-3.83025v-6.59306H117.092v13.87682Zm12.99774-5.33724a5.64546,5.64546,0,0,1-1.3814,4.08142,4.92818,4.92818,0,0,1-3.83025,1.44419,5.38941,5.38941,0,0,1-2.7-.69071,4.56776,4.56776,0,0,1-1.82094-1.94652,6.2032,6.2032,0,0,1-.62791-2.95119,5.64546,5.64546,0,0,1,1.3814-4.08142,5.16082,5.16082,0,0,1,3.83026-1.44419,5.38943,5.38943,0,0,1,2.7.6907,4.56765,4.56765,0,0,1,1.82093,1.94653,6.20315,6.20315,0,0,1,.62791,2.95117Zm-7.34655,0a4.65582,4.65582,0,0,0,.50233,2.38606,1.94717,1.94717,0,0,0,1.69536.81627,1.87861,1.87861,0,0,0,1.69536-.81627,5.91809,5.91809,0,0,0,0-4.77213,2.16874,2.16874,0,0,0-3.39072,0A4.09317,4.09317,0,0,0,122.68036,162.43381Zm15.76056-5.52561a4.76464,4.76464,0,0,1,1.00466.0628l-.25116,2.7628a3.27256,3.27256,0,0,0-.87907-.12558,3.406,3.406,0,0,0-2.19769.6907,2.65137,2.65137,0,0,0-.75349,2.00932v5.46283h-2.88839V157.0966h2.19768l.43954,1.82093h.12558a3.65917,3.65917,0,0,1,1.31861-1.44419,3.32231,3.32231,0,0,1,1.88374-.56512Zm7.40934,8.728a7.37941,7.37941,0,0,0,1.82094-.314v2.19769a6.90473,6.90473,0,0,1-2.7.50232,3.44268,3.44268,0,0,1-2.57444-.87907,3.88816,3.88816,0,0,1-.81628-2.63723V159.357h-1.3814v-1.25582l1.63257-1.00466.81628-2.26048h1.88373v2.26048h3.014v2.19768h-3.014v5.14887a1.1846,1.1846,0,0,0,.37675.94186,1.51325,1.51325,0,0,0,.94187.25116Zm13.87682,2.13489h-2.88839v-6.21631c0-1.56977-.56512-2.32326-1.69536-2.32326a1.92007,1.92007,0,0,0-1.75815.81628,4.94,4.94,0,0,0-.56511,2.7v5.02328h-2.88839V152.88958h2.88839v3.014c0,.25116,0,.81629-.0628,1.63257l-.12558.94187h.12558a3.31322,3.31322,0,0,1,3.07676-1.56978,3.85772,3.85772,0,0,1,2.88839,1.00466,4.12535,4.12535,0,0,1,1.00466,2.88839v6.96979Zm16.828,0-1.00466-3.32792h-5.08608l-1.00466,3.32792h-3.20235l4.96049-14.0024h3.64187l4.96049,14.0024Zm-1.69537-5.83956c-.94186-3.014-1.44418-4.70932-1.56977-5.08607s-.18837-.69071-.25116-.94187c-.18837.81629-.81628,2.8256-1.82094,6.02794Zm16.01171,5.83956H187.983v-6.21631a3.48158,3.48158,0,0,0-.37675-1.75815,1.379,1.379,0,0,0-1.193-.56511,1.77247,1.77247,0,0,0-1.63257.81628,5.69948,5.69948,0,0,0-.50232,2.7v5.02328H181.39V157.09658h2.19769l.37675,1.3814h.18837a2.74891,2.74891,0,0,1,1.25582-1.13024,4.615,4.615,0,0,1,1.88373-.43954,3.3708,3.3708,0,0,1,3.26514,1.56978h.25116a2.74881,2.74881,0,0,1,1.25582-1.13024,4.61467,4.61467,0,0,1,1.88373-.43954,3.7777,3.7777,0,0,1,2.7628.94187,4.12823,4.12823,0,0,1,.94187,3.014v6.96981h-2.95119v-6.21631a3.48177,3.48177,0,0,0-.37675-1.75815,1.379,1.379,0,0,0-1.193-.56512,1.75249,1.75249,0,0,0-1.56978.75349,4.19367,4.19367,0,0,0-.50232,2.44885v5.27444Zm14.44194.18837a5.00852,5.00852,0,0,1-5.46283-5.46283,5.86477,5.86477,0,0,1,1.31862-4.14421,4.65154,4.65154,0,0,1,3.70466-1.4442,4.593,4.593,0,0,1,3.51631,1.31862,5.06785,5.06785,0,0,1,1.25582,3.57908v1.44419h-6.907a2.86755,2.86755,0,0,0,.7535,1.94653,2.71976,2.71976,0,0,0,1.94653.6907,8.525,8.525,0,0,0,1.82094-.18836,12.58565,12.58565,0,0,0,1.82093-.62791v2.26048a7.17159,7.17159,0,0,1-1.63257.56511C206.88314,167.89662,206.19243,167.95942,205.31336,167.95942Zm-.37675-8.97912a1.80163,1.80163,0,0,0-1.44419.56511,2.61711,2.61711,0,0,0-.62791,1.69536h4.08142a2.51313,2.51313,0,0,0-.56512-1.69536,1.8016,1.8016,0,0,0-1.44418-.56511Zm13.12332-2.07211a4.76468,4.76468,0,0,1,1.00466.0628l-.25116,2.7628a3.27262,3.27262,0,0,0-.87907-.12558,3.406,3.406,0,0,0-2.19769.69069,2.65148,2.65148,0,0,0-.7535,2.00932v5.46283h-2.88839V157.09658h2.19769l.43954,1.82093h.12559a3.65919,3.65919,0,0,1,1.31862-1.44419,3.32236,3.32236,0,0,1,1.88373-.56512Zm2.7628-2.57443c0-.94187.50232-1.4442,1.56978-1.4442s1.56977.50233,1.56977,1.4442a1.477,1.477,0,0,1-.37675,1.06744,1.69986,1.69986,0,0,1-1.193.37675c-1.00468,0-1.56978-.50231-1.56978-1.44417Zm3.07676,13.43727H221.0111V157.09656h2.88839Zm7.34656.18837c-3.32792,0-4.96049-1.82094-4.96049-5.46283a5.60687,5.60687,0,0,1,1.38141-4.14421,5.11552,5.11552,0,0,1,3.89305-1.4442,7.21214,7.21214,0,0,1,3.32792.75349l-.87907,2.26048c-.43955-.18837-.87907-.314-1.25582-.43953a3.94294,3.94294,0,0,0-1.193-.18838q-2.2605,0-2.26048,3.20235c0,2.0721.7535,3.13955,2.26048,3.13955a4.33528,4.33528,0,0,0,1.56978-.25116,5.05135,5.05135,0,0,0,1.44418-.6907v2.51164a4.81115,4.81115,0,0,1-1.44418.62791,14.84056,14.84056,0,0,1-1.88373.12559Zm12.5582-.18837-.56511-1.44418h-.0628a3.81949,3.81949,0,0,1-1.507,1.25582,4.58766,4.58766,0,0,1-2.00932.37675,3.53989,3.53989,0,0,1-2.44885-.87907,3.48582,3.48582,0,0,1-.87907-2.51164,2.80979,2.80979,0,0,1,1.193-2.51165,6.8063,6.8063,0,0,1,3.57909-.87907l1.88374-.06279v-.43955a1.46009,1.46009,0,0,0-1.63257-1.63257,7.5674,7.5674,0,0,0-3.014.75349l-.94186-1.94648a8.87333,8.87333,0,0,1,4.08141-.94187,5.24626,5.24626,0,0,1,3.32792.94187,3.46776,3.46776,0,0,1,1.13023,2.8256v7.09538h-2.13489Zm-.87907-4.96049-1.13023.0628a3.61328,3.61328,0,0,0-1.88373.43954,1.32957,1.32957,0,0,0-.62791,1.25583c0,.81627.50232,1.25582,1.44418,1.25582a2.34754,2.34754,0,0,0,1.63258-.56512,2.1219,2.1219,0,0,0,.62791-1.56978v-.87907Z"/><path class="cls-1" d="M262.98775,167.65552h-9.68233v-2.037l3.47681-3.51482q1.54435-1.58205,2.018-2.19278a4.81342,4.81342,0,0,0,.68187-1.13257,2.87467,2.87467,0,0,0,.20846-1.07984,1.57526,1.57526,0,0,0-.45928-1.2411,1.78244,1.78244,0,0,0-1.227-.40716,3.53388,3.53388,0,0,0-1.563.36914,8.09015,8.09015,0,0,0-1.582,1.05163l-1.59185-1.885a10.36724,10.36724,0,0,1,1.69609-1.2319,6.2542,6.2542,0,0,1,1.468-.55433,7.53511,7.53511,0,0,1,1.78133-.19377,5.275,5.275,0,0,1,2.29273.47339,3.65734,3.65734,0,0,1,1.544,1.32633,3.52561,3.52561,0,0,1,.54942,1.9518,4.787,4.787,0,0,1-.336,1.79543,6.89585,6.89585,0,0,1-1.04243,1.71939,25.41809,25.41809,0,0,1-2.48652,2.51037l-1.78133,1.67709v.13245h6.03506Z"/><path class="cls-1" d="M273.9866,160.73013a9.65324,9.65324,0,0,1-1.189,5.37158,4.12587,4.12587,0,0,1-3.66134,1.74331,4.0773,4.0773,0,0,1-3.61417-1.79973,9.51557,9.51557,0,0,1-1.2178-5.31516,9.74317,9.74317,0,0,1,1.18469-5.40469,4.60492,4.60492,0,0,1,7.27064.08033A9.53694,9.53694,0,0,1,273.9866,160.73013Zm-6.774,0a10.77282,10.77282,0,0,0,.44089,3.65218,1.52569,1.52569,0,0,0,1.4827,1.10375,1.5413,1.5413,0,0,0,1.47779-1.11785,14.78859,14.78859,0,0,0-.0049-7.29946,1.53411,1.53411,0,0,0-2.95069,0A10.7369,10.7369,0,0,0,267.21265,160.73013Z"/><path class="cls-1" d="M285.13753,167.65552H275.4552v-2.037l3.47681-3.51482q1.54436-1.58205,2.018-2.19278a4.81342,4.81342,0,0,0,.68187-1.13257,2.87467,2.87467,0,0,0,.20846-1.07984,1.57526,1.57526,0,0,0-.45928-1.2411,1.78244,1.78244,0,0,0-1.227-.40716,3.53388,3.53388,0,0,0-1.563.36914,8.09015,8.09015,0,0,0-1.582,1.05163l-1.59185-1.885a10.36724,10.36724,0,0,1,1.69609-1.2319,6.2542,6.2542,0,0,1,1.468-.55433,7.53511,7.53511,0,0,1,1.78133-.19377,5.275,5.275,0,0,1,2.29273.47339,3.65747,3.65747,0,0,1,1.544,1.32633,3.52577,3.52577,0,0,1,.54942,1.9518,4.787,4.787,0,0,1-.336,1.79543,6.89585,6.89585,0,0,1-1.04243,1.71939,25.41809,25.41809,0,0,1-2.48652,2.51037l-1.78133,1.67709v.13245h6.03506Z"/><path class="cls-1" d="M296.13638,160.73013a9.65324,9.65324,0,0,1-1.189,5.37158A4.12585,4.12585,0,0,1,291.286,167.845a4.0773,4.0773,0,0,1-3.61417-1.79973,9.516,9.516,0,0,1-1.2178-5.31516,9.74352,9.74352,0,0,1,1.18469-5.40469,4.60492,4.60492,0,0,1,7.27064.08033A9.53658,9.53658,0,0,1,296.13638,160.73013Zm-6.77395,0a10.77282,10.77282,0,0,0,.44089,3.65218,1.52569,1.52569,0,0,0,1.4827,1.10375,1.54128,1.54128,0,0,0,1.47779-1.11785,14.78859,14.78859,0,0,0-.0049-7.29946,1.53411,1.53411,0,0,0-2.95069,0A10.7369,10.7369,0,0,0,289.36243,160.73013Z"/><path id="SVGID-3" class="cls-1" d="M311.56937,160.142H391v.62791H311.56937Z"/><rect class="cls-1" x="311.56937" y="160.14195" width="79.43063" height="0.62791"/><rect class="cls-1" x="311.56937" y="160.14195" width="79.43063" height="0.62791"/><g class="cls-6"><path class="cls-1" d="M311.56937,160.142H391v.62791H311.56937Z"/></g></svg>
\ No newline at end of file
diff --git a/static/images/pencil.png b/static/images/pencil.png
index 300600da05..4f0000f639 100644
Binary files a/static/images/pencil.png and b/static/images/pencil.png differ
diff --git a/static/images/training/kubernetes-cks-white.svg b/static/images/training/kubernetes-cks-white.svg
new file mode 100644
index 0000000000..872c0c6a76
--- /dev/null
+++ b/static/images/training/kubernetes-cks-white.svg
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   id="Layer_1"
+   data-name="Layer 1"
+   viewBox="0 0 242.72101 230.32488"
+   version="1.1">
+  <metadata
+     id="metadata55">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <defs
+     id="defs4">
+    <style
+       id="style2">.cls-1{fill:#ffffff;}.cls-2{fill:#fff;}</style>
+  </defs>
+  <path
+     id="path6"
+     style="fill:#ffffff;fill-opacity:1"
+     d="M 121.31445 0.15625 A 15.35 15.35 0 0 0 115.7207 1.1933594 C 113.1617 2.1355594 110.77583 3.4702219 108.31641 4.6386719 C 104.15534 6.6156019 99.967996 8.538515 95.822266 10.546875 C 92.141239 12.330075 88.4513 14.093991 84.751953 15.837891 C 80.853213 17.667661 76.985096 19.565141 73.103516 21.431641 C 69.958746 22.943841 66.818779 24.463301 63.667969 25.962891 C 59.261969 28.060001 54.842683 30.129662 50.439453 32.232422 C 47.185243 33.786502 43.955089 35.392759 40.699219 36.943359 C 37.455079 38.488359 34.136169 39.888737 31.005859 41.654297 A 15.06024 15.06024 0 0 0 23.488281 51.681641 C 21.130921 61.739241 18.842524 71.813419 16.527344 81.880859 C 12.131297 100.99677 7.7303719 120.11056 3.3261719 139.22461 A 16.28845 16.28845 0 0 0 6.6191406 153.95898 C 15.972961 165.52184 25.29763 177.10689 34.595703 188.71484 C 44.107123 200.54089 53.622299 212.36543 63.138672 224.1875 A 15.46263 15.46263 0 0 0 75.673828 230.16016 C 90.801948 230.17468 105.93041 230.17513 121.05859 230.16406 C 136.24193 230.16406 151.42597 230.16423 166.60938 230.16211 A 15.955 15.955 0 0 0 179.41797 224.16211 C 180.61725 222.72241 181.76906 221.24377 182.94336 219.7832 C 191.44325 209.21098 199.94336 198.63849 208.44336 188.06641 C 212.98627 182.41608 217.53005 176.76614 222.07227 171.11523 C 226.89764 165.09717 231.73645 159.0882 236.51758 153.03516 A 14.74845 14.74845 0 0 0 239.4043 140.47266 C 237.99848 133.65839 236.31263 126.90204 234.75391 120.11914 C 233.00451 112.50623 231.25834 104.8923 229.51758 97.277344 C 227.78888 89.76959 226.05407 82.264099 224.31055 74.759766 C 222.56934 67.198366 220.84998 59.630922 219.10547 52.070312 A 15.98227 15.98227 0 0 0 213.37891 42.919922 A 27.62639 27.62639 0 0 0 207.81641 39.810547 C 191.71099 32.103087 175.60044 24.409522 159.48242 16.728516 C 148.98883 11.719516 138.50555 6.6865575 127.99609 1.7109375 A 15.35 15.35 0 0 0 121.31445 0.15625 z M 115.71875 10.974609 A 7.67609 7.67609 0 0 0 115.13281 13.927734 L 115.13281 14.083984 C 115.13281 14.602044 115.08099 15.223223 115.13281 15.689453 A 51.42016 51.42016 0 0 0 116.01367 21.648438 C 116.5318 26.000307 116.99835 29.677362 116.6875 33.044922 A 6.86316 6.86316 0 0 1 114.66602 36.310547 L 114.51172 38.951172 A 78.13842 78.13842 0 0 0 103.16406 40.712891 A 80.46711 80.46711 0 0 0 62.183594 64.130859 C 61.510064 63.664609 60.266977 62.784391 59.904297 62.525391 C 58.764467 62.680791 57.676268 63.042849 56.173828 62.162109 A 57.36049 57.36049 0 0 1 47.730469 54.546875 A 46.57671 46.57671 0 0 0 43.585938 50.142578 C 43.223267 49.831728 42.600037 49.365527 42.185547 49.054688 A 7.62207 7.62207 0 0 0 39.058594 47.558594 C 39.116084 47.528804 39.166559 47.494074 39.224609 47.464844 C 43.439939 45.342544 47.726015 43.358756 51.984375 41.322266 C 55.600465 39.592886 59.223634 37.879571 62.839844 36.150391 C 66.604004 34.350344 70.365233 32.545615 74.125 30.736328 C 77.79052 28.982548 81.459386 27.231881 85.128906 25.486328 C 88.967893 23.651615 92.805945 21.814416 96.642578 19.974609 C 100.30774 18.223089 103.95825 16.441894 107.64648 14.740234 C 110.34295 13.496234 112.95538 12.060549 115.71875 10.974609 z M 127.13477 11.115234 C 129.07091 11.895444 130.91043 12.914424 132.79688 13.808594 C 147.43811 20.748534 162.06445 27.723389 176.67383 34.730469 C 185.00449 38.706549 193.33433 42.683843 201.66406 46.662109 C 202.2259 46.930849 202.77973 47.212993 203.32617 47.507812 A 7.73718 7.73718 0 0 0 200.51367 48.898438 C 200.09924 49.261108 199.52777 49.675478 199.11328 49.986328 A 54.40181 54.40181 0 0 0 194.96875 54.390625 A 60.78441 60.78441 0 0 1 186.52539 62.058594 C 185.3338 62.783944 183.5193 62.524476 182.74219 62.472656 L 180.35938 64.183594 A 82.56748 82.56748 0 0 0 128.29102 39.003906 C 128.2392 38.174986 128.18854 36.673281 128.13672 36.207031 A 4.966 4.966 0 0 1 126.06445 33.046875 C 125.80545 29.679315 126.27099 26.052128 126.78906 21.648438 A 51.40933 51.40933 0 0 0 127.66992 15.689453 L 127.66992 13.927734 A 7.62668 7.62668 0 0 0 127.13477 11.115234 z M 32.035156 55.851562 A 7.52023 7.52023 0 0 0 34.310547 58.845703 C 34.362367 58.845703 34.364196 58.898437 34.416016 58.898438 C 34.830446 59.209288 35.348257 59.674564 35.710938 59.933594 C 37.524228 61.228824 39.129155 61.956057 40.890625 62.992188 A 64.22916 64.22916 0 0 1 50.216797 69.519531 A 6.61353 6.61353 0 0 1 51.460938 73.146484 L 53.480469 74.958984 A 81.06587 81.06587 0 0 0 40.683594 131.5332 L 38.041016 132.31055 A 9.08477 9.08477 0 0 1 35.347656 135.05664 C 32.135506 136.09283 28.509159 136.45563 24.105469 136.92188 A 48.436 48.436 0 0 0 18.095703 137.38867 C 17.629393 137.49225 16.95557 137.64633 16.4375 137.75 L 16.28125 137.75 A 7.42737 7.42737 0 0 0 12.820312 139.64453 A 19.2735 19.2735 0 0 1 13.234375 137.07812 C 15.874045 125.80815 18.420782 114.51721 21.013672 103.23633 C 23.010385 94.549248 25.014697 85.863494 27.025391 77.179688 C 28.599311 70.362977 30.117974 63.533748 31.771484 56.736328 C 31.845574 56.431758 31.944916 56.144723 32.035156 55.851562 z M 210.49219 55.953125 A 17.04647 17.04647 0 0 1 210.98633 57.712891 C 211.59394 60.486941 212.22479 63.255797 212.86133 66.023438 C 213.65381 69.468927 214.46634 72.909116 215.26367 76.353516 C 216.4295 81.390196 217.63155 86.420653 218.73633 91.470703 C 219.3689 94.362036 220.01372 97.250345 220.66992 100.13672 C 221.26526 102.7591 221.91028 105.37567 222.53516 107.99414 C 223.71088 112.92059 224.80029 117.86804 225.93359 122.80469 C 226.88366 126.94336 227.8537 131.0766 228.79688 135.2168 C 229.1164 136.61963 229.46882 138.01507 229.64844 139.43945 A 7.33852 7.33852 0 0 0 226.3125 137.64648 C 225.79438 137.54285 225.01807 137.33605 224.5 137.23242 A 48.42223 48.42223 0 0 0 218.49023 136.76562 C 214.08648 136.29932 210.46015 135.9365 207.24805 134.90039 C 205.95283 134.38226 205.021 132.82977 204.55469 132.15625 L 202.01562 131.42969 A 81.19509 81.19509 0 0 0 200.7207 102.1582 A 79.90643 79.90643 0 0 0 188.95898 75.009766 C 189.63244 74.439886 190.82489 73.352904 191.1875 72.990234 A 4.95661 4.95661 0 0 1 192.37891 69.416016 A 60.43964 60.43964 0 0 1 201.70508 62.835938 A 50.54343 50.54343 0 0 0 206.9375 59.779297 C 207.35199 59.468447 207.86963 59.002246 208.33594 58.691406 A 7.4635 7.4635 0 0 0 210.49219 55.953125 z M 64.083984 73.787109 L 178.47656 73.787109 L 178.47656 101.14258 L 64.083984 101.14258 L 64.083984 73.787109 z M 76.740234 80.96875 A 6.9587 6.9587 0 0 0 76.517578 80.974609 A 6.71541 6.71541 0 0 0 69.626953 87.814453 L 69.626953 87.865234 A 6.68023 6.68023 0 0 0 76.414062 94.652344 A 6.8215 6.8215 0 0 0 81.855469 92.269531 L 79.990234 90.404297 A 4.82362 4.82362 0 0 1 76.517578 91.958984 A 3.932 3.932 0 0 1 72.683594 87.814453 L 72.683594 87.761719 A 3.93368 3.93368 0 0 1 76.517578 83.617188 A 4.72225 4.72225 0 0 1 79.886719 85.119141 L 81.75 82.996094 A 6.9587 6.9587 0 0 0 76.746094 80.96875 A 6.9587 6.9587 0 0 0 76.740234 80.96875 z M 84.185547 81.181641 L 84.185547 94.445312 L 94.289062 94.445312 L 94.289062 91.802734 L 87.087891 91.802734 L 87.087891 89.056641 L 93.355469 89.056641 L 93.355469 86.466797 L 87.087891 86.466797 L 87.087891 83.773438 L 94.185547 83.773438 L 94.185547 81.181641 L 84.185547 81.181641 z M 109.62305 81.181641 L 109.62305 83.876953 L 113.66406 83.876953 L 113.66406 94.445312 L 116.56641 94.445312 L 116.56641 83.876953 L 120.60742 83.876953 L 120.60742 81.181641 L 109.62305 81.181641 z M 122.99023 81.181641 L 122.99023 94.445312 L 125.89258 94.445312 L 125.89258 81.181641 L 122.99023 81.181641 z M 129.20703 81.181641 L 129.20703 94.445312 L 132.10938 94.445312 L 132.10938 89.263672 L 138.48047 89.263672 L 138.48047 86.621094 L 132.10938 86.621094 L 132.10938 83.824219 L 139.31055 83.824219 L 139.31055 81.181641 L 129.20703 81.181641 z M 141.79688 81.181641 L 141.79688 94.445312 L 144.69727 94.445312 L 144.69727 81.181641 L 141.79688 81.181641 z M 148.01367 81.181641 L 148.01367 94.445312 L 158.11719 94.445312 L 158.11719 91.802734 L 150.91602 91.802734 L 150.91602 89.056641 L 157.13281 89.056641 L 157.13281 86.466797 L 150.91602 86.466797 L 150.91602 83.773438 L 158.01367 83.773438 L 158.01367 81.181641 L 148.01367 81.181641 z M 160.70703 81.181641 L 160.70703 94.445312 L 165.88867 94.445312 C 170.03339 94.445312 172.93359 91.544653 172.93359 87.814453 C 172.93359 84.032453 170.03339 81.181641 165.88867 81.181641 L 160.70703 81.181641 z M 103.35352 81.222656 A 5.27661 5.27661 0 0 0 102.99219 81.234375 L 96.931641 81.234375 L 96.931641 94.445312 L 99.832031 94.445312 L 99.832031 90.197266 L 102.16406 90.197266 L 105.01367 94.445312 L 108.43164 94.445312 L 105.16797 89.730469 A 4.08546 4.08546 0 0 0 108.01758 85.636719 L 108.01758 85.585938 A 4.1457 4.1457 0 0 0 106.87891 82.580078 A 5.27661 5.27661 0 0 0 103.35352 81.222656 z M 166.05273 83.767578 A 3.80749 3.80749 0 0 1 169.87695 87.761719 L 169.87695 87.814453 A 3.76658 3.76658 0 0 1 165.88867 91.75 L 163.60742 91.75 L 163.60742 83.773438 L 163.60742 83.771484 L 165.88867 83.771484 A 3.80749 3.80749 0 0 1 166.05273 83.767578 z M 99.832031 83.773438 L 102.73242 83.773438 C 104.13124 83.773436 105.01367 84.394243 105.01367 85.689453 L 105.01367 85.740234 C 105.01367 86.880024 104.18398 87.605469 102.78516 87.605469 L 99.832031 87.605469 L 99.832031 83.773438 z M 67.296875 105.08398 L 67.296875 114.51172 C 67.607725 114.14903 67.9704 113.78648 68.28125 113.42383 C 68.64391 113.06114 68.954775 112.6986 69.265625 112.33594 C 69.576475 111.97328 69.887484 111.61163 70.146484 111.30078 A 9.18153 9.18153 0 0 0 70.871094 110.4707 L 74.652344 110.4707 C 73.875224 111.35144 73.151101 112.1799 72.425781 112.95703 C 71.700461 113.73416 70.923719 114.56364 70.042969 115.39258 A 17.48825 17.48825 0 0 1 71.388672 116.79102 A 20.88481 20.88481 0 0 1 72.736328 118.44922 C 73.150798 119.01912 73.565074 119.59027 73.927734 120.16016 C 74.238584 120.73006 74.549544 121.24662 74.808594 121.71289 L 71.130859 121.71289 C 70.923629 121.35024 70.664366 120.93696 70.353516 120.4707 C 70.042666 120.00444 69.730772 119.58933 69.419922 119.12305 A 12.60786 12.60786 0 0 0 68.384766 117.82812 A 10.03021 10.03021 0 0 0 67.296875 116.79102 L 67.296875 121.76562 L 64.083984 121.76562 L 64.083984 105.60156 L 67.296875 105.08398 z M 92.216797 105.08398 L 92.216797 110.73047 A 9.66558 9.66558 0 0 1 93.355469 110.36719 A 8.59557 8.59557 0 0 1 94.599609 110.26367 A 5.54358 5.54358 0 0 1 96.722656 110.67773 A 3.917 3.917 0 0 1 98.277344 111.86914 A 5.25965 5.25965 0 0 1 99.210938 113.73438 A 8.94591 8.94591 0 0 1 99.521484 116.16992 A 7.27054 7.27054 0 0 1 99.107422 118.60547 A 4.9 4.9 0 0 1 97.966797 120.4707 A 5.01107 5.01107 0 0 1 96.101562 121.66211 A 7.35379 7.35379 0 0 1 93.615234 122.07617 A 9.576 9.576 0 0 1 92.423828 122.02539 L 91.179688 121.86914 A 8.14215 8.14215 0 0 1 89.988281 121.66211 C 89.625621 121.55854 89.314766 121.50595 89.003906 121.40234 L 89.003906 105.60156 L 92.216797 105.08398 z M 151.84766 107.15625 L 151.84766 110.4707 L 155.68164 110.4707 L 155.68164 113.11328 L 151.84766 113.11328 L 151.84766 117.10352 A 2.95332 2.95332 0 0 0 152.21094 118.70898 A 1.55615 1.55615 0 0 0 153.66016 119.33008 A 7.72774 7.72774 0 0 0 154.74805 119.22656 A 5.46473 5.46473 0 0 0 155.73242 118.96875 L 156.19922 121.45508 A 7.61767 7.61767 0 0 1 154.9043 121.86914 A 8.90684 8.90684 0 0 1 153.14258 122.02539 A 5.3061 5.3061 0 0 1 150.9668 121.66211 A 3.11632 3.11632 0 0 1 149.56836 120.67773 A 3.91329 3.91329 0 0 1 148.84375 119.12305 A 8.34758 8.34758 0 0 1 148.63477 117.10352 L 148.63477 107.62109 L 151.84766 107.15625 z M 174.10547 109.94531 A 5.19975 5.19975 0 0 1 174.29688 109.94531 A 5.19975 5.19975 0 0 1 174.48828 109.95312 A 12.05967 12.05967 0 0 1 176.45703 110.16016 A 11.59653 11.59653 0 0 1 177.95898 110.57422 L 177.38867 113.0625 A 8.00883 8.00883 0 0 0 176.19727 112.69922 A 6.22792 6.22792 0 0 0 174.74609 112.54297 C 173.76174 112.54297 173.24414 112.80315 173.24414 113.37305 A 0.76815 0.76815 0 0 0 173.29688 113.73438 A 1.37337 1.37337 0 0 0 173.55469 114.04688 A 2.265 2.265 0 0 0 174.07422 114.35742 A 4.331 4.331 0 0 0 174.90234 114.71875 A 11.73628 11.73628 0 0 1 176.66406 115.49609 A 3.75042 3.75042 0 0 1 177.75195 116.32617 A 2.71652 2.71652 0 0 1 178.32227 117.31055 A 4.53434 4.53434 0 0 1 178.47656 118.55273 A 2.85966 2.85966 0 0 1 177.23438 121.0918 A 6.39067 6.39067 0 0 1 173.6582 121.97266 A 11.10508 11.10508 0 0 1 171.17188 121.71289 A 9.97006 9.97006 0 0 1 169.77344 121.29883 L 170.29102 118.70898 A 8.81565 8.81565 0 0 0 171.94922 119.22656 A 6.436 6.436 0 0 0 173.6582 119.43359 A 3.61452 3.61452 0 0 0 174.90234 119.2793 C 175.16138 119.17568 175.26562 118.9155 175.26562 118.44922 C 175.26564 118.19018 175.10969 117.98262 174.79883 117.77539 A 9.969 9.969 0 0 0 173.34766 117.10352 A 10.51216 10.51216 0 0 1 172.00195 116.5332 A 5.24887 5.24887 0 0 1 170.96484 115.80664 A 2.5739 2.5739 0 0 1 170.29102 114.82227 A 3.74278 3.74278 0 0 1 170.0332 113.42383 A 3.075 3.075 0 0 1 171.22461 110.88477 A 5.19975 5.19975 0 0 1 174.10547 109.94531 z M 107.08398 110.15234 A 4.9202 4.9202 0 0 1 110.60742 111.61133 A 6.10323 6.10323 0 0 1 112.00781 115.96289 L 112.00781 116.58398 C 112.00781 116.79121 111.95508 116.99876 111.95508 117.25781 L 104.70117 117.25781 A 2.15407 2.15407 0 0 0 105.63477 118.8125 A 3.74781 3.74781 0 0 0 107.81055 119.38281 A 9.53979 9.53979 0 0 0 109.51953 119.22656 A 6.49862 6.49862 0 0 0 110.91992 118.8125 L 111.33398 121.40234 A 3.05129 3.05129 0 0 1 110.66016 121.66211 C 110.40111 121.71392 110.08921 121.81733 109.72656 121.86914 C 109.36391 121.92095 109.00236 121.97358 108.58789 122.02539 A 9.171 9.171 0 0 1 107.39648 122.07617 A 7.06566 7.06566 0 0 1 104.75391 121.60938 A 5.35172 5.35172 0 0 1 102.88867 120.36719 A 5.53273 5.53273 0 0 1 101.80078 118.50195 A 7.69869 7.69869 0 0 1 101.9043 113.52734 A 5.75618 5.75618 0 0 1 103.0957 111.66211 A 4.32 4.32 0 0 1 104.80664 110.52344 A 5.55551 5.55551 0 0 1 106.82617 110.16016 A 4.9202 4.9202 0 0 1 107.08398 110.15234 z M 141.33008 110.15234 A 4.92016 4.92016 0 0 1 144.85352 111.61133 A 6.10314 6.10314 0 0 1 146.25195 115.96289 L 146.25195 116.58398 A 3.186 3.186 0 0 1 146.20117 117.25781 L 138.94727 117.25781 A 2.154 2.154 0 0 0 139.88086 118.8125 A 3.74771 3.74771 0 0 0 142.05664 119.38281 A 9.53894 9.53894 0 0 0 143.76562 119.22656 A 6.49872 6.49872 0 0 0 145.16406 118.8125 L 145.57812 121.40234 A 2.03139 2.03139 0 0 1 144.90625 121.66211 C 144.64721 121.71392 144.33533 121.81732 143.97266 121.86914 C 143.60999 121.92096 143.24844 121.97358 142.83398 122.02539 A 9.17082 9.17082 0 0 1 141.64062 122.07617 A 7.06563 7.06563 0 0 1 139 121.60938 A 5.87983 5.87983 0 0 1 137.13477 120.36719 A 5.53278 5.53278 0 0 1 136.04688 118.50195 A 7.69864 7.69864 0 0 1 136.15039 113.52734 A 5.75615 5.75615 0 0 1 137.3418 111.66211 A 4.3199 4.3199 0 0 1 139.05078 110.52344 A 5.55537 5.55537 0 0 1 141.07227 110.16016 A 4.92016 4.92016 0 0 1 141.33008 110.15234 z M 162.98438 110.15234 A 4.92016 4.92016 0 0 1 166.50977 111.61133 A 6.10314 6.10314 0 0 1 167.9082 115.96289 L 167.9082 116.58398 A 3.18657 3.18657 0 0 1 167.85742 117.25781 L 160.60352 117.25781 A 2.154 2.154 0 0 0 161.53516 118.8125 A 3.74774 3.74774 0 0 0 163.71094 119.38281 A 9.539 9.539 0 0 0 165.42188 119.22656 A 6.49844 6.49844 0 0 0 166.82031 118.8125 L 167.23438 121.40234 A 2.03132 2.03132 0 0 1 166.56055 121.66211 C 166.30151 121.71392 165.99158 121.81732 165.62891 121.86914 C 165.26624 121.92096 164.90275 121.97358 164.48828 122.02539 A 9.17067 9.17067 0 0 1 163.29688 122.07617 A 7.06563 7.06563 0 0 1 160.6543 121.60938 A 5.87971 5.87971 0 0 1 158.79102 120.36719 A 5.53295 5.53295 0 0 1 157.70117 118.50195 A 7.69855 7.69855 0 0 1 157.80664 113.52734 A 5.7558 5.7558 0 0 1 158.99805 111.66211 A 4.3199 4.3199 0 0 1 160.70703 110.52344 A 5.55535 5.55535 0 0 1 162.72656 110.16016 A 4.92016 4.92016 0 0 1 162.98438 110.15234 z M 128.67383 110.15625 A 6.40885 6.40885 0 0 1 130.76172 110.52344 A 3.64232 3.64232 0 0 1 132.26367 111.61133 A 4.45192 4.45192 0 0 1 133.04102 113.26953 A 9.17277 9.17277 0 0 1 133.30078 115.39258 L 133.30078 121.71289 L 130.08789 121.71289 L 130.08789 115.70312 A 4.32568 4.32568 0 0 0 129.67383 113.52734 A 1.65382 1.65382 0 0 0 128.17188 112.90625 C 127.96464 112.90625 127.70431 112.95703 127.44531 112.95703 A 2.73691 2.73691 0 0 0 126.77344 113.00977 L 126.77344 121.71289 L 123.56055 121.71289 L 123.56055 110.78125 C 124.13045 110.62578 124.85466 110.52261 125.68359 110.36719 A 14.95922 14.95922 0 0 1 128.37891 110.16016 A 6.40885 6.40885 0 0 1 128.67383 110.15625 z M 119.15625 110.21289 C 119.31168 110.21289 119.51834 110.26367 119.77734 110.26367 A 3.38479 3.38479 0 0 0 120.50391 110.26367 A 3.49821 3.49821 0 0 1 121.22852 110.36719 A 4.31811 4.31811 0 0 1 121.85156 110.57422 L 121.33203 113.2168 C 121.07299 113.165 120.71032 113.11339 120.34766 113.00977 A 8.59724 8.59724 0 0 0 119.10547 112.90625 C 118.89824 112.90625 118.63791 112.95898 118.37891 112.95898 A 1.9323 1.9323 0 0 0 117.75781 113.0625 L 117.75781 121.71289 L 114.54492 121.71289 L 114.54492 111.04102 A 13.80307 13.80307 0 0 1 116.56641 110.4707 A 12.88372 12.88372 0 0 1 119.15625 110.21289 z M 76.207031 110.41992 L 79.419922 110.41992 L 79.419922 116.32617 A 4.70262 4.70262 0 0 0 79.833984 118.55273 A 1.56769 1.56769 0 0 0 81.335938 119.22656 C 81.543167 119.22656 81.8035 119.17578 82.0625 119.17578 A 2.73691 2.73691 0 0 0 82.734375 119.12305 L 82.734375 110.41992 L 85.947266 110.41992 L 85.947266 121.35156 C 85.377366 121.50702 84.651196 121.61021 83.822266 121.76562 A 14.95919 14.95919 0 0 1 81.128906 121.97266 A 6.40882 6.40882 0 0 1 78.746094 121.60938 A 3.64251 3.64251 0 0 1 77.244141 120.52148 A 4.452 4.452 0 0 1 76.466797 118.86328 A 8.83053 8.83053 0 0 1 76.207031 116.74023 L 76.207031 110.4707 L 76.207031 110.41992 z M 106.99023 112.80078 A 1.77427 1.77427 0 0 0 106.87891 112.80273 A 2.47475 2.47475 0 0 0 105.94531 113.00977 A 1.41447 1.41447 0 0 0 105.32422 113.47656 A 1.48767 1.48767 0 0 0 104.91016 114.15039 A 6.44516 6.44516 0 0 0 104.70117 114.97852 L 108.95117 114.97852 A 4.13006 4.13006 0 0 0 108.79492 114.20117 A 1.70608 1.70608 0 0 0 108.43164 113.52734 A 1.52316 1.52316 0 0 0 107.81055 113.00977 A 1.77427 1.77427 0 0 0 106.99023 112.80078 z M 141.23438 112.80078 A 1.77423 1.77423 0 0 0 141.12305 112.80273 A 2.4748 2.4748 0 0 0 140.19141 113.00977 A 1.41432 1.41432 0 0 0 139.56836 113.47656 A 1.48748 1.48748 0 0 0 139.1543 114.15039 A 6.443 6.443 0 0 0 138.94727 114.97852 L 143.19531 114.97852 A 4.12765 4.12765 0 0 0 143.04102 114.20117 A 1.70619 1.70619 0 0 0 142.67773 113.52734 A 1.52328 1.52328 0 0 0 142.05664 113.00977 A 1.77423 1.77423 0 0 0 141.23438 112.80078 z M 162.89062 112.80078 A 1.77422 1.77422 0 0 0 162.7793 112.80273 A 2.47475 2.47475 0 0 0 161.84766 113.00977 A 1.41438 1.41438 0 0 0 161.22461 113.47656 A 1.48772 1.48772 0 0 0 160.81055 114.15039 A 6.4463 6.4463 0 0 0 160.60352 114.97852 L 164.85156 114.97852 A 4.12765 4.12765 0 0 0 164.69531 114.20117 A 1.70619 1.70619 0 0 0 164.33398 113.52734 A 1.52328 1.52328 0 0 0 163.71094 113.00977 A 1.77422 1.77422 0 0 0 162.89062 112.80078 z M 93.683594 112.95508 A 3.18847 3.18847 0 0 0 92.941406 113.0625 A 1.36142 1.36142 0 0 0 92.164062 113.42383 L 92.164062 119.22656 C 92.319493 119.22656 92.526156 119.2793 92.785156 119.2793 A 3.43048 3.43048 0 0 0 93.5625 119.33008 A 2.23921 2.23921 0 0 0 95.53125 118.44922 A 3.82185 3.82185 0 0 0 96.205078 116.06641 C 96.205078 113.99408 95.428221 112.95898 93.925781 112.95898 A 3.18847 3.18847 0 0 0 93.683594 112.95508 z M 64.083984 128.19141 L 178.47656 128.19141 L 178.47656 165.53516 L 64.083984 165.53516 L 64.083984 128.19141 z M 106.77734 133.72656 A 5.74768 5.74768 0 0 0 106.57617 133.73242 A 5.66177 5.66177 0 0 0 100.76758 139.49414 L 100.76758 139.52539 A 5.62285 5.62285 0 0 0 106.48047 145.25391 A 5.69665 5.69665 0 0 0 111.04883 143.26562 L 109.48828 141.68945 A 4.0184 4.0184 0 0 1 106.56055 142.99414 A 3.30866 3.30866 0 0 1 103.33008 139.49414 L 103.33008 139.46094 A 3.30045 3.30045 0 0 1 106.56055 135.99219 A 4.11021 4.11021 0 0 1 109.4082 137.25 L 110.96875 135.45117 A 5.74768 5.74768 0 0 0 106.77734 133.72656 z M 83.197266 133.76367 C 80.920856 133.76367 79.296875 135.10157 79.296875 137.12305 L 79.296875 137.1543 C 79.296875 139.36621 80.746094 139.9878 82.990234 140.56055 C 84.852544 141.03806 85.234375 141.35595 85.234375 141.97656 L 85.234375 142.00781 C 85.234375 142.66011 84.628953 143.05859 83.626953 143.05859 A 5.108 5.108 0 0 1 80.300781 141.70508 L 78.851562 143.43945 A 7.087 7.087 0 0 0 83.578125 145.22266 C 85.981445 145.22266 87.667969 143.98194 87.667969 141.76953 L 87.667969 141.73828 C 87.667969 139.79638 86.394536 138.9834 84.134766 138.39453 C 82.208986 137.90137 81.732422 137.66358 81.732422 136.93164 L 81.732422 136.89844 C 81.732422 136.35742 82.225584 135.92773 83.164062 135.92773 A 5.227 5.227 0 0 1 86.060547 137.02734 L 87.333984 135.17969 A 6.44831 6.44831 0 0 0 83.197266 133.76367 z M 131.2793 133.91406 A 4.44053 4.44053 0 0 0 130.92578 133.92383 L 125.83203 133.92383 L 125.83203 145.06445 L 128.2832 145.06445 L 128.2832 141.49805 L 130.20898 141.49805 L 132.5957 145.06445 L 135.46094 145.06445 L 132.74023 141.08594 A 3.46 3.46 0 0 0 135.12695 137.63086 L 135.12695 137.59961 A 3.498 3.498 0 0 0 134.17188 135.05273 A 4.44053 4.44053 0 0 0 131.2793 133.91406 z M 90.199219 133.92383 L 90.199219 145.06445 L 98.681641 145.06445 L 98.681641 142.88281 L 92.632812 142.88281 L 92.632812 140.54297 L 97.886719 140.54297 L 97.886719 138.36328 L 92.632812 138.36328 L 92.632812 136.10352 L 98.601562 136.10352 L 98.601562 133.92383 L 90.199219 133.92383 z M 113.22852 133.92383 L 113.22852 140.28906 C 113.22852 143.56738 115.05859 145.2383 118.05078 145.23828 C 121.04199 145.23828 122.93555 143.58298 122.93555 140.20898 L 122.93555 133.92383 L 120.48438 133.92383 L 120.48438 140.30469 C 120.48434 142.07129 119.57812 142.97852 118.08203 142.97852 C 116.58594 142.97852 115.67773 142.03906 115.67773 140.22461 L 115.67773 133.92383 L 113.22852 133.92383 z M 137.84766 133.92383 L 137.84766 145.06445 L 140.29883 145.06445 L 140.29883 133.92383 L 137.84766 133.92383 z M 142.68555 133.92383 L 142.68555 136.18359 L 146.07617 136.18359 L 146.07617 145.06445 L 148.52734 145.06445 L 148.52734 136.18359 L 151.91797 136.18359 L 151.91797 133.92383 L 142.68555 133.92383 z M 153.04688 133.92383 L 157.32617 140.67188 L 157.32617 145.06445 L 159.77734 145.06445 L 159.77734 140.62305 L 164.05859 133.92383 L 161.27344 133.92383 L 158.56836 138.39453 L 155.91016 133.92383 L 153.04688 133.92383 z M 128.2832 136.13477 L 130.71875 136.13477 C 131.91211 136.13477 132.64453 136.67627 132.64453 137.72656 L 132.64453 137.75781 C 132.64453 138.69727 131.95899 139.33398 130.76562 139.33398 L 128.2832 139.33398 L 128.2832 136.13477 z M 37.472656 144.12305 C 38.871456 144.01941 40.320496 145.00348 41.097656 145.41797 L 43.84375 144.95117 A 80.64786 80.64786 0 0 0 56.123047 168.67969 L 56.486328 169.14648 A 82.647 82.647 0 0 0 80.005859 190.12891 L 78.867188 192.875 A 6.0599 6.0599 0 0 1 79.435547 196.39844 A 63.33945 63.33945 0 0 1 73.738281 206.60352 A 53.00188 53.00188 0 0 0 70.369141 211.62891 C 70.110141 212.09521 69.800046 212.82178 69.541016 213.33984 A 7.67415 7.67415 0 0 0 68.847656 215.97461 A 19.54273 19.54273 0 0 1 67.373047 214.32422 C 63.393367 209.29046 59.342476 204.31225 55.322266 199.31055 C 51.440426 194.48113 47.557981 189.65325 43.675781 184.82422 C 39.359561 179.46063 35.040836 174.09869 30.720703 168.73828 C 26.597543 163.60864 22.480314 158.47326 18.369141 153.33398 C 17.444771 152.17926 16.450014 151.07556 15.583984 149.87695 A 7.47652 7.47652 0 0 0 19.080078 149.92578 L 19.183594 149.92578 A 0.18092 0.18092 0 0 0 19.287109 149.87305 C 19.805169 149.76947 20.478088 149.61539 20.892578 149.51172 A 49.02742 49.02742 0 0 0 26.541016 147.33594 C 30.685666 145.83349 34.105076 144.58936 37.472656 144.12305 z M 204.74023 144.22266 A 4.85783 4.85783 0 0 1 205.07227 144.22656 C 208.43976 144.6928 211.85919 145.93701 216.00391 147.43945 A 51.26675 51.26675 0 0 0 221.65039 149.61523 C 222.11664 149.71886 222.73778 149.87485 223.25586 149.97852 A 0.18067 0.18067 0 0 1 223.35938 150.0293 L 223.46289 150.0293 A 7.641 7.641 0 0 0 226.7207 150.00586 C 225.70343 151.37012 224.53338 152.62928 223.49609 153.97852 C 222.05572 155.85212 220.58008 157.69873 219.09961 159.54102 C 217.42682 161.62256 215.72259 163.679 214.04883 165.75977 C 211.86676 168.4726 209.71038 171.20593 207.52734 173.91797 C 205.37677 176.5896 203.19678 179.23646 201.04883 181.91016 C 199.54283 183.78473 198.0841 185.69726 196.57617 187.57031 C 195.10705 189.39514 193.58454 191.17768 192.11719 193.00391 C 190.63099 194.85352 189.20216 196.74891 187.71484 198.59766 C 186.02942 200.69282 184.29114 202.74487 182.60547 204.83984 C 181.13757 206.664 179.7466 208.55072 178.25586 210.35547 C 176.75928 212.16712 175.41638 214.125 173.79883 215.81055 C 173.77124 215.8393 173.74255 215.8641 173.71484 215.89258 A 7.59352 7.59352 0 0 0 173.00195 213.33984 C 172.74295 212.82178 172.43287 212.09521 172.17383 211.62891 A 52.06088 52.06088 0 0 0 168.80664 206.65625 C 166.42346 202.92603 164.45337 199.86932 163.26172 196.70898 C 162.74366 195.10298 163.36585 194.06745 163.72852 193.03125 A 19.27116 19.27116 0 0 1 162.69336 190.49219 A 82.53323 82.53323 0 0 0 186.31641 169.35352 L 186.41992 169.19922 A 82.79132 82.79132 0 0 0 198.85547 145.05664 C 199.68439 145.16028 201.08261 145.41791 201.54883 145.52148 A 4.85783 4.85783 0 0 1 204.74023 144.22266 z M 110.69922 148.72656 A 5.74768 5.74768 0 0 0 110.49805 148.73242 A 5.66177 5.66177 0 0 0 104.68945 154.49414 L 104.68945 154.52539 A 5.62285 5.62285 0 0 0 110.40234 160.25391 A 5.69663 5.69663 0 0 0 114.9707 158.26562 L 113.41016 156.68945 A 4.01841 4.01841 0 0 1 110.48242 157.99414 A 3.30866 3.30866 0 0 1 107.25195 154.49414 L 107.25195 154.46094 A 3.30045 3.30045 0 0 1 110.48242 150.99219 A 4.11017 4.11017 0 0 1 113.33008 152.25 L 114.89062 150.45117 A 5.74768 5.74768 0 0 0 110.69922 148.72656 z M 76.089844 148.76367 C 73.813434 148.76367 72.191406 150.10157 72.191406 152.12305 L 72.191406 152.1543 C 72.191406 154.36621 73.638672 154.9878 75.882812 155.56055 C 77.745113 156.03806 78.126953 156.35595 78.126953 156.97656 L 78.126953 157.00781 C 78.126953 157.66011 77.521481 158.05859 76.519531 158.05859 A 5.108 5.108 0 0 1 73.193359 156.70508 L 71.746094 158.43945 A 7.087 7.087 0 0 0 76.472656 160.22266 C 78.875976 160.22266 80.5625 158.98194 80.5625 156.76953 L 80.5625 156.73828 C 80.5625 154.79638 79.289057 153.9834 77.029297 153.39453 C 75.103507 152.90137 74.625 152.66358 74.625 151.93164 L 74.625 151.89844 C 74.625 151.35742 75.120124 150.92773 76.058594 150.92773 A 5.227 5.227 0 0 1 78.955078 152.02734 L 80.228516 150.17969 A 6.44828 6.44828 0 0 0 76.089844 148.76367 z M 155.61719 148.76367 C 153.34082 148.76367 151.7168 150.10157 151.7168 152.12305 L 151.7168 152.1543 C 151.7168 154.36621 153.16601 154.9878 155.41016 155.56055 C 157.27246 156.03806 157.6543 156.35595 157.6543 156.97656 L 157.6543 157.00781 C 157.6543 157.66011 157.04887 158.05859 156.04688 158.05859 A 5.108 5.108 0 0 1 152.7207 156.70508 L 151.27148 158.43945 A 7.087 7.087 0 0 0 155.99805 160.22266 C 158.40137 160.22266 160.08789 158.98194 160.08789 156.76953 L 160.08789 156.73828 C 160.08789 154.79638 158.81446 153.9834 156.55469 153.39453 C 154.62891 152.90137 154.15234 152.66358 154.15234 151.93164 L 154.15234 151.89844 C 154.15234 151.35742 154.6455 150.92773 155.58398 150.92773 A 5.227 5.227 0 0 1 158.48047 152.02734 L 159.75391 150.17969 A 6.4483 6.4483 0 0 0 155.61719 148.76367 z M 126.89062 148.84375 L 122.11523 160.06445 L 124.61523 160.06445 L 125.63281 157.56445 L 130.34375 157.56445 L 131.36328 160.06445 L 133.92383 160.06445 L 129.15039 148.84375 L 126.89062 148.84375 z M 83.091797 148.92383 L 83.091797 160.06445 L 85.542969 160.06445 L 85.542969 156.7207 L 87.404297 156.7207 C 89.903327 156.7207 91.908203 155.38477 91.908203 152.80664 L 91.908203 152.77539 C 91.908203 150.49951 90.301761 148.92383 87.644531 148.92383 L 83.091797 148.92383 z M 94.121094 148.92383 L 94.121094 160.06445 L 102.60352 160.06445 L 102.60352 157.88281 L 96.556641 157.88281 L 96.556641 155.54297 L 101.80859 155.54297 L 101.80859 153.36328 L 96.556641 153.36328 L 96.556641 151.10352 L 102.52539 151.10352 L 102.52539 148.92383 L 94.121094 148.92383 z M 117.4375 148.92383 L 117.4375 160.06445 L 119.88867 160.06445 L 119.88867 148.92383 L 117.4375 148.92383 z M 136.04297 148.92383 L 136.04297 160.06445 L 144.04688 160.06445 L 144.04688 157.83594 L 138.49414 157.83594 L 138.49414 148.92383 L 136.04297 148.92383 z M 146.40234 148.92383 L 146.40234 160.06445 L 148.85352 160.06445 L 148.85352 148.92383 L 146.40234 148.92383 z M 161.58398 148.92383 L 161.58398 151.18359 L 164.97461 151.18359 L 164.97461 160.06445 L 167.42578 160.06445 L 167.42578 151.18359 L 170.81445 151.18359 L 170.81445 148.92383 L 161.58398 148.92383 z M 85.542969 151.13477 L 87.4375 151.13477 C 88.66308 151.13477 89.425781 151.72412 89.425781 152.82227 L 89.425781 152.85352 A 1.72468 1.72468 0 0 1 87.484375 154.54102 L 85.542969 154.54102 L 85.542969 151.13477 z M 127.98828 151.78711 L 129.46875 155.40039 L 126.50781 155.40039 L 127.98828 151.78711 z M 92.388672 196.24219 A 80.59625 80.59625 0 0 0 139.48242 199.60938 A 74.131 74.131 0 0 0 150.25781 196.3457 C 150.67229 197.07098 151.3983 198.41858 151.60547 198.78125 A 4.96252 4.96252 0 0 1 154.81836 200.75 A 55.78238 55.78238 0 0 1 159.11719 211.31836 A 52.38662 52.38662 0 0 0 160.93164 217.07031 C 161.13886 217.53661 161.44989 218.20953 161.70898 218.67578 A 7.64068 7.64068 0 0 0 162.94727 220.51758 C 149.06535 220.55125 135.18279 220.53125 121.30078 220.53125 C 110.97534 220.53125 100.64962 220.53048 90.324219 220.53125 C 86.873552 220.53235 83.423323 220.54256 79.972656 220.55859 C 79.845576 220.55914 79.727362 220.54108 79.601562 220.53906 A 7.56336 7.56336 0 0 0 80.835938 218.72656 C 81.094938 218.26026 81.406061 217.5874 81.613281 217.12109 A 52.388 52.388 0 0 0 83.425781 211.37109 C 85.083681 207.22644 86.015372 202.82294 88.294922 200.12891 A 5.06922 5.06922 0 0 1 90.990234 198.83203 L 92.388672 196.24219 z " />
+</svg>
diff --git a/static/js/jquery-ui-1.12.1.min.js b/static/js/jquery-ui-1.12.1.min.js
deleted file mode 100644
index 117cb35e43..0000000000
--- a/static/js/jquery-ui-1.12.1.min.js
+++ /dev/null
@@ -1,13 +0,0 @@
-/*! jQuery UI - v1.12.1 - 2016-09-14
-* http://jqueryui.com
-* Includes: widget.js, position.js, data.js, disable-selection.js, effect.js, effects/effect-blind.js, effects/effect-bounce.js, effects/effect-clip.js, effects/effect-drop.js, effects/effect-explode.js, effects/effect-fade.js, effects/effect-fold.js, effects/effect-highlight.js, effects/effect-puff.js, effects/effect-pulsate.js, effects/effect-scale.js, effects/effect-shake.js, effects/effect-size.js, effects/effect-slide.js, effects/effect-transfer.js, focusable.js, form-reset-mixin.js, jquery-1-7.js, keycode.js, labels.js, scroll-parent.js, tabbable.js, unique-id.js, widgets/accordion.js, widgets/autocomplete.js, widgets/button.js, widgets/checkboxradio.js, widgets/controlgroup.js, widgets/datepicker.js, widgets/dialog.js, widgets/draggable.js, widgets/droppable.js, widgets/menu.js, widgets/mouse.js, widgets/progressbar.js, widgets/resizable.js, widgets/selectable.js, widgets/selectmenu.js, widgets/slider.js, widgets/sortable.js, widgets/spinner.js, widgets/tabs.js, widgets/tooltip.js
-* Copyright jQuery Foundation and other contributors; Licensed MIT */
-
-(function(t){"function"==typeof define&&define.amd?define(["jquery"],t):t(jQuery)})(function(t){function e(t){for(var e=t.css("visibility");"inherit"===e;)t=t.parent(),e=t.css("visibility");return"hidden"!==e}function i(t){for(var e,i;t.length&&t[0]!==document;){if(e=t.css("position"),("absolute"===e||"relative"===e||"fixed"===e)&&(i=parseInt(t.css("zIndex"),10),!isNaN(i)&&0!==i))return i;t=t.parent()}return 0}function s(){this._curInst=null,this._keyEvent=!1,this._disabledInputs=[],this._datepickerShowing=!1,this._inDialog=!1,this._mainDivId="ui-datepicker-div",this._inlineClass="ui-datepicker-inline",this._appendClass="ui-datepicker-append",this._triggerClass="ui-datepicker-trigger",this._dialogClass="ui-datepicker-dialog",this._disableClass="ui-datepicker-disabled",this._unselectableClass="ui-datepicker-unselectable",this._currentClass="ui-datepicker-current-day",this._dayOverClass="ui-datepicker-days-cell-over",this.regional=[],this.regional[""]={closeText:"Done",prevText:"Prev",nextText:"Next",currentText:"Today",monthNames:["January","February","March","April","May","June","July","August","September","October","November","December"],monthNamesShort:["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"],dayNames:["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],dayNamesShort:["Sun","Mon","Tue","Wed","Thu","Fri","Sat"],dayNamesMin:["Su","Mo","Tu","We","Th","Fr","Sa"],weekHeader:"Wk",dateFormat:"mm/dd/yy",firstDay:0,isRTL:!1,showMonthAfterYear:!1,yearSuffix:""},this._defaults={showOn:"focus",showAnim:"fadeIn",showOptions:{},defaultDate:null,appendText:"",buttonText:"...",buttonImage:"",buttonImageOnly:!1,hideIfNoPrevNext:!1,navigationAsDateFormat:!1,gotoCurrent:!1,changeMonth:!1,changeYear:!1,yearRange:"c-10:c+10",showOtherMonths:!1,selectOtherMonths:!1,showWeek:!1,calculateWeek:this.iso8601Week,shortYearCutoff:"+10",minDate:null,maxDate:null,duration:"fast",beforeShowDay:null,beforeShow:null,onSelect:null,onChangeMonthYear:null,onClose:null,numberOfMonths:1,showCurrentAtPos:0,stepMonths:1,stepBigMonths:12,altField:"",altFormat:"",constrainInput:!0,showButtonPanel:!1,autoSize:!1,disabled:!1},t.extend(this._defaults,this.regional[""]),this.regional.en=t.extend(!0,{},this.regional[""]),this.regional["en-US"]=t.extend(!0,{},this.regional.en),this.dpDiv=n(t("<div id='"+this._mainDivId+"' class='ui-datepicker ui-widget ui-widget-content ui-helper-clearfix ui-corner-all'></div>"))}function n(e){var i="button, .ui-datepicker-prev, .ui-datepicker-next, .ui-datepicker-calendar td a";return e.on("mouseout",i,function(){t(this).removeClass("ui-state-hover"),-1!==this.className.indexOf("ui-datepicker-prev")&&t(this).removeClass("ui-datepicker-prev-hover"),-1!==this.className.indexOf("ui-datepicker-next")&&t(this).removeClass("ui-datepicker-next-hover")}).on("mouseover",i,o)}function o(){t.datepicker._isDisabledDatepicker(m.inline?m.dpDiv.parent()[0]:m.input[0])||(t(this).parents(".ui-datepicker-calendar").find("a").removeClass("ui-state-hover"),t(this).addClass("ui-state-hover"),-1!==this.className.indexOf("ui-datepicker-prev")&&t(this).addClass("ui-datepicker-prev-hover"),-1!==this.className.indexOf("ui-datepicker-next")&&t(this).addClass("ui-datepicker-next-hover"))}function a(e,i){t.extend(e,i);for(var s in i)null==i[s]&&(e[s]=i[s]);return e}function r(t){return function(){var e=this.element.val();t.apply(this,arguments),this._refresh(),e!==this.element.val()&&this._trigger("change")}}t.ui=t.ui||{},t.ui.version="1.12.1";var h=0,l=Array.prototype.slice;t.cleanData=function(e){return function(i){var s,n,o;for(o=0;null!=(n=i[o]);o++)try{s=t._data(n,"events"),s&&s.remove&&t(n).triggerHandler("remove")}catch(a){}e(i)}}(t.cleanData),t.widget=function(e,i,s){var n,o,a,r={},h=e.split(".")[0];e=e.split(".")[1];var l=h+"-"+e;return s||(s=i,i=t.Widget),t.isArray(s)&&(s=t.extend.apply(null,[{}].concat(s))),t.expr[":"][l.toLowerCase()]=function(e){return!!t.data(e,l)},t[h]=t[h]||{},n=t[h][e],o=t[h][e]=function(t,e){return this._createWidget?(arguments.length&&this._createWidget(t,e),void 0):new o(t,e)},t.extend(o,n,{version:s.version,_proto:t.extend({},s),_childConstructors:[]}),a=new i,a.options=t.widget.extend({},a.options),t.each(s,function(e,s){return t.isFunction(s)?(r[e]=function(){function t(){return i.prototype[e].apply(this,arguments)}function n(t){return i.prototype[e].apply(this,t)}return function(){var e,i=this._super,o=this._superApply;return this._super=t,this._superApply=n,e=s.apply(this,arguments),this._super=i,this._superApply=o,e}}(),void 0):(r[e]=s,void 0)}),o.prototype=t.widget.extend(a,{widgetEventPrefix:n?a.widgetEventPrefix||e:e},r,{constructor:o,namespace:h,widgetName:e,widgetFullName:l}),n?(t.each(n._childConstructors,function(e,i){var s=i.prototype;t.widget(s.namespace+"."+s.widgetName,o,i._proto)}),delete n._childConstructors):i._childConstructors.push(o),t.widget.bridge(e,o),o},t.widget.extend=function(e){for(var i,s,n=l.call(arguments,1),o=0,a=n.length;a>o;o++)for(i in n[o])s=n[o][i],n[o].hasOwnProperty(i)&&void 0!==s&&(e[i]=t.isPlainObject(s)?t.isPlainObject(e[i])?t.widget.extend({},e[i],s):t.widget.extend({},s):s);return e},t.widget.bridge=function(e,i){var s=i.prototype.widgetFullName||e;t.fn[e]=function(n){var o="string"==typeof n,a=l.call(arguments,1),r=this;return o?this.length||"instance"!==n?this.each(function(){var i,o=t.data(this,s);return"instance"===n?(r=o,!1):o?t.isFunction(o[n])&&"_"!==n.charAt(0)?(i=o[n].apply(o,a),i!==o&&void 0!==i?(r=i&&i.jquery?r.pushStack(i.get()):i,!1):void 0):t.error("no such method '"+n+"' for "+e+" widget instance"):t.error("cannot call methods on "+e+" prior to initialization; "+"attempted to call method '"+n+"'")}):r=void 0:(a.length&&(n=t.widget.extend.apply(null,[n].concat(a))),this.each(function(){var e=t.data(this,s);e?(e.option(n||{}),e._init&&e._init()):t.data(this,s,new i(n,this))})),r}},t.Widget=function(){},t.Widget._childConstructors=[],t.Widget.prototype={widgetName:"widget",widgetEventPrefix:"",defaultElement:"<div>",options:{classes:{},disabled:!1,create:null},_createWidget:function(e,i){i=t(i||this.defaultElement||this)[0],this.element=t(i),this.uuid=h++,this.eventNamespace="."+this.widgetName+this.uuid,this.bindings=t(),this.hoverable=t(),this.focusable=t(),this.classesElementLookup={},i!==this&&(t.data(i,this.widgetFullName,this),this._on(!0,this.element,{remove:function(t){t.target===i&&this.destroy()}}),this.document=t(i.style?i.ownerDocument:i.document||i),this.window=t(this.document[0].defaultView||this.document[0].parentWindow)),this.options=t.widget.extend({},this.options,this._getCreateOptions(),e),this._create(),this.options.disabled&&this._setOptionDisabled(this.options.disabled),this._trigger("create",null,this._getCreateEventData()),this._init()},_getCreateOptions:function(){return{}},_getCreateEventData:t.noop,_create:t.noop,_init:t.noop,destroy:function(){var e=this;this._destroy(),t.each(this.classesElementLookup,function(t,i){e._removeClass(i,t)}),this.element.off(this.eventNamespace).removeData(this.widgetFullName),this.widget().off(this.eventNamespace).removeAttr("aria-disabled"),this.bindings.off(this.eventNamespace)},_destroy:t.noop,widget:function(){return this.element},option:function(e,i){var s,n,o,a=e;if(0===arguments.length)return t.widget.extend({},this.options);if("string"==typeof e)if(a={},s=e.split("."),e=s.shift(),s.length){for(n=a[e]=t.widget.extend({},this.options[e]),o=0;s.length-1>o;o++)n[s[o]]=n[s[o]]||{},n=n[s[o]];if(e=s.pop(),1===arguments.length)return void 0===n[e]?null:n[e];n[e]=i}else{if(1===arguments.length)return void 0===this.options[e]?null:this.options[e];a[e]=i}return this._setOptions(a),this},_setOptions:function(t){var e;for(e in t)this._setOption(e,t[e]);return this},_setOption:function(t,e){return"classes"===t&&this._setOptionClasses(e),this.options[t]=e,"disabled"===t&&this._setOptionDisabled(e),this},_setOptionClasses:function(e){var i,s,n;for(i in e)n=this.classesElementLookup[i],e[i]!==this.options.classes[i]&&n&&n.length&&(s=t(n.get()),this._removeClass(n,i),s.addClass(this._classes({element:s,keys:i,classes:e,add:!0})))},_setOptionDisabled:function(t){this._toggleClass(this.widget(),this.widgetFullName+"-disabled",null,!!t),t&&(this._removeClass(this.hoverable,null,"ui-state-hover"),this._removeClass(this.focusable,null,"ui-state-focus"))},enable:function(){return this._setOptions({disabled:!1})},disable:function(){return this._setOptions({disabled:!0})},_classes:function(e){function i(i,o){var a,r;for(r=0;i.length>r;r++)a=n.classesElementLookup[i[r]]||t(),a=e.add?t(t.unique(a.get().concat(e.element.get()))):t(a.not(e.element).get()),n.classesElementLookup[i[r]]=a,s.push(i[r]),o&&e.classes[i[r]]&&s.push(e.classes[i[r]])}var s=[],n=this;return e=t.extend({element:this.element,classes:this.options.classes||{}},e),this._on(e.element,{remove:"_untrackClassesElement"}),e.keys&&i(e.keys.match(/\S+/g)||[],!0),e.extra&&i(e.extra.match(/\S+/g)||[]),s.join(" ")},_untrackClassesElement:function(e){var i=this;t.each(i.classesElementLookup,function(s,n){-1!==t.inArray(e.target,n)&&(i.classesElementLookup[s]=t(n.not(e.target).get()))})},_removeClass:function(t,e,i){return this._toggleClass(t,e,i,!1)},_addClass:function(t,e,i){return this._toggleClass(t,e,i,!0)},_toggleClass:function(t,e,i,s){s="boolean"==typeof s?s:i;var n="string"==typeof t||null===t,o={extra:n?e:i,keys:n?t:e,element:n?this.element:t,add:s};return o.element.toggleClass(this._classes(o),s),this},_on:function(e,i,s){var n,o=this;"boolean"!=typeof e&&(s=i,i=e,e=!1),s?(i=n=t(i),this.bindings=this.bindings.add(i)):(s=i,i=this.element,n=this.widget()),t.each(s,function(s,a){function r(){return e||o.options.disabled!==!0&&!t(this).hasClass("ui-state-disabled")?("string"==typeof a?o[a]:a).apply(o,arguments):void 0}"string"!=typeof a&&(r.guid=a.guid=a.guid||r.guid||t.guid++);var h=s.match(/^([\w:-]*)\s*(.*)$/),l=h[1]+o.eventNamespace,c=h[2];c?n.on(l,c,r):i.on(l,r)})},_off:function(e,i){i=(i||"").split(" ").join(this.eventNamespace+" ")+this.eventNamespace,e.off(i).off(i),this.bindings=t(this.bindings.not(e).get()),this.focusable=t(this.focusable.not(e).get()),this.hoverable=t(this.hoverable.not(e).get())},_delay:function(t,e){function i(){return("string"==typeof t?s[t]:t).apply(s,arguments)}var s=this;return setTimeout(i,e||0)},_hoverable:function(e){this.hoverable=this.hoverable.add(e),this._on(e,{mouseenter:function(e){this._addClass(t(e.currentTarget),null,"ui-state-hover")},mouseleave:function(e){this._removeClass(t(e.currentTarget),null,"ui-state-hover")}})},_focusable:function(e){this.focusable=this.focusable.add(e),this._on(e,{focusin:function(e){this._addClass(t(e.currentTarget),null,"ui-state-focus")},focusout:function(e){this._removeClass(t(e.currentTarget),null,"ui-state-focus")}})},_trigger:function(e,i,s){var n,o,a=this.options[e];if(s=s||{},i=t.Event(i),i.type=(e===this.widgetEventPrefix?e:this.widgetEventPrefix+e).toLowerCase(),i.target=this.element[0],o=i.originalEvent)for(n in o)n in i||(i[n]=o[n]);return this.element.trigger(i,s),!(t.isFunction(a)&&a.apply(this.element[0],[i].concat(s))===!1||i.isDefaultPrevented())}},t.each({show:"fadeIn",hide:"fadeOut"},function(e,i){t.Widget.prototype["_"+e]=function(s,n,o){"string"==typeof n&&(n={effect:n});var a,r=n?n===!0||"number"==typeof n?i:n.effect||i:e;n=n||{},"number"==typeof n&&(n={duration:n}),a=!t.isEmptyObject(n),n.complete=o,n.delay&&s.delay(n.delay),a&&t.effects&&t.effects.effect[r]?s[e](n):r!==e&&s[r]?s[r](n.duration,n.easing,o):s.queue(function(i){t(this)[e](),o&&o.call(s[0]),i()})}}),t.widget,function(){function e(t,e,i){return[parseFloat(t[0])*(u.test(t[0])?e/100:1),parseFloat(t[1])*(u.test(t[1])?i/100:1)]}function i(e,i){return parseInt(t.css(e,i),10)||0}function s(e){var i=e[0];return 9===i.nodeType?{width:e.width(),height:e.height(),offset:{top:0,left:0}}:t.isWindow(i)?{width:e.width(),height:e.height(),offset:{top:e.scrollTop(),left:e.scrollLeft()}}:i.preventDefault?{width:0,height:0,offset:{top:i.pageY,left:i.pageX}}:{width:e.outerWidth(),height:e.outerHeight(),offset:e.offset()}}var n,o=Math.max,a=Math.abs,r=/left|center|right/,h=/top|center|bottom/,l=/[\+\-]\d+(\.[\d]+)?%?/,c=/^\w+/,u=/%$/,d=t.fn.position;t.position={scrollbarWidth:function(){if(void 0!==n)return n;var e,i,s=t("<div style='display:block;position:absolute;width:50px;height:50px;overflow:hidden;'><div style='height:100px;width:auto;'></div></div>"),o=s.children()[0];return t("body").append(s),e=o.offsetWidth,s.css("overflow","scroll"),i=o.offsetWidth,e===i&&(i=s[0].clientWidth),s.remove(),n=e-i},getScrollInfo:function(e){var i=e.isWindow||e.isDocument?"":e.element.css("overflow-x"),s=e.isWindow||e.isDocument?"":e.element.css("overflow-y"),n="scroll"===i||"auto"===i&&e.width<e.element[0].scrollWidth,o="scroll"===s||"auto"===s&&e.height<e.element[0].scrollHeight;return{width:o?t.position.scrollbarWidth():0,height:n?t.position.scrollbarWidth():0}},getWithinInfo:function(e){var i=t(e||window),s=t.isWindow(i[0]),n=!!i[0]&&9===i[0].nodeType,o=!s&&!n;return{element:i,isWindow:s,isDocument:n,offset:o?t(e).offset():{left:0,top:0},scrollLeft:i.scrollLeft(),scrollTop:i.scrollTop(),width:i.outerWidth(),height:i.outerHeight()}}},t.fn.position=function(n){if(!n||!n.of)return d.apply(this,arguments);n=t.extend({},n);var u,p,f,g,m,_,v=t(n.of),b=t.position.getWithinInfo(n.within),y=t.position.getScrollInfo(b),w=(n.collision||"flip").split(" "),k={};return _=s(v),v[0].preventDefault&&(n.at="left top"),p=_.width,f=_.height,g=_.offset,m=t.extend({},g),t.each(["my","at"],function(){var t,e,i=(n[this]||"").split(" ");1===i.length&&(i=r.test(i[0])?i.concat(["center"]):h.test(i[0])?["center"].concat(i):["center","center"]),i[0]=r.test(i[0])?i[0]:"center",i[1]=h.test(i[1])?i[1]:"center",t=l.exec(i[0]),e=l.exec(i[1]),k[this]=[t?t[0]:0,e?e[0]:0],n[this]=[c.exec(i[0])[0],c.exec(i[1])[0]]}),1===w.length&&(w[1]=w[0]),"right"===n.at[0]?m.left+=p:"center"===n.at[0]&&(m.left+=p/2),"bottom"===n.at[1]?m.top+=f:"center"===n.at[1]&&(m.top+=f/2),u=e(k.at,p,f),m.left+=u[0],m.top+=u[1],this.each(function(){var s,r,h=t(this),l=h.outerWidth(),c=h.outerHeight(),d=i(this,"marginLeft"),_=i(this,"marginTop"),x=l+d+i(this,"marginRight")+y.width,C=c+_+i(this,"marginBottom")+y.height,D=t.extend({},m),I=e(k.my,h.outerWidth(),h.outerHeight());"right"===n.my[0]?D.left-=l:"center"===n.my[0]&&(D.left-=l/2),"bottom"===n.my[1]?D.top-=c:"center"===n.my[1]&&(D.top-=c/2),D.left+=I[0],D.top+=I[1],s={marginLeft:d,marginTop:_},t.each(["left","top"],function(e,i){t.ui.position[w[e]]&&t.ui.position[w[e]][i](D,{targetWidth:p,targetHeight:f,elemWidth:l,elemHeight:c,collisionPosition:s,collisionWidth:x,collisionHeight:C,offset:[u[0]+I[0],u[1]+I[1]],my:n.my,at:n.at,within:b,elem:h})}),n.using&&(r=function(t){var e=g.left-D.left,i=e+p-l,s=g.top-D.top,r=s+f-c,u={target:{element:v,left:g.left,top:g.top,width:p,height:f},element:{element:h,left:D.left,top:D.top,width:l,height:c},horizontal:0>i?"left":e>0?"right":"center",vertical:0>r?"top":s>0?"bottom":"middle"};l>p&&p>a(e+i)&&(u.horizontal="center"),c>f&&f>a(s+r)&&(u.vertical="middle"),u.important=o(a(e),a(i))>o(a(s),a(r))?"horizontal":"vertical",n.using.call(this,t,u)}),h.offset(t.extend(D,{using:r}))})},t.ui.position={fit:{left:function(t,e){var i,s=e.within,n=s.isWindow?s.scrollLeft:s.offset.left,a=s.width,r=t.left-e.collisionPosition.marginLeft,h=n-r,l=r+e.collisionWidth-a-n;e.collisionWidth>a?h>0&&0>=l?(i=t.left+h+e.collisionWidth-a-n,t.left+=h-i):t.left=l>0&&0>=h?n:h>l?n+a-e.collisionWidth:n:h>0?t.left+=h:l>0?t.left-=l:t.left=o(t.left-r,t.left)},top:function(t,e){var i,s=e.within,n=s.isWindow?s.scrollTop:s.offset.top,a=e.within.height,r=t.top-e.collisionPosition.marginTop,h=n-r,l=r+e.collisionHeight-a-n;e.collisionHeight>a?h>0&&0>=l?(i=t.top+h+e.collisionHeight-a-n,t.top+=h-i):t.top=l>0&&0>=h?n:h>l?n+a-e.collisionHeight:n:h>0?t.top+=h:l>0?t.top-=l:t.top=o(t.top-r,t.top)}},flip:{left:function(t,e){var i,s,n=e.within,o=n.offset.left+n.scrollLeft,r=n.width,h=n.isWindow?n.scrollLeft:n.offset.left,l=t.left-e.collisionPosition.marginLeft,c=l-h,u=l+e.collisionWidth-r-h,d="left"===e.my[0]?-e.elemWidth:"right"===e.my[0]?e.elemWidth:0,p="left"===e.at[0]?e.targetWidth:"right"===e.at[0]?-e.targetWidth:0,f=-2*e.offset[0];0>c?(i=t.left+d+p+f+e.collisionWidth-r-o,(0>i||a(c)>i)&&(t.left+=d+p+f)):u>0&&(s=t.left-e.collisionPosition.marginLeft+d+p+f-h,(s>0||u>a(s))&&(t.left+=d+p+f))},top:function(t,e){var i,s,n=e.within,o=n.offset.top+n.scrollTop,r=n.height,h=n.isWindow?n.scrollTop:n.offset.top,l=t.top-e.collisionPosition.marginTop,c=l-h,u=l+e.collisionHeight-r-h,d="top"===e.my[1],p=d?-e.elemHeight:"bottom"===e.my[1]?e.elemHeight:0,f="top"===e.at[1]?e.targetHeight:"bottom"===e.at[1]?-e.targetHeight:0,g=-2*e.offset[1];0>c?(s=t.top+p+f+g+e.collisionHeight-r-o,(0>s||a(c)>s)&&(t.top+=p+f+g)):u>0&&(i=t.top-e.collisionPosition.marginTop+p+f+g-h,(i>0||u>a(i))&&(t.top+=p+f+g))}},flipfit:{left:function(){t.ui.position.flip.left.apply(this,arguments),t.ui.position.fit.left.apply(this,arguments)},top:function(){t.ui.position.flip.top.apply(this,arguments),t.ui.position.fit.top.apply(this,arguments)}}}}(),t.ui.position,t.extend(t.expr[":"],{data:t.expr.createPseudo?t.expr.createPseudo(function(e){return function(i){return!!t.data(i,e)}}):function(e,i,s){return!!t.data(e,s[3])}}),t.fn.extend({disableSelection:function(){var t="onselectstart"in document.createElement("div")?"selectstart":"mousedown";return function(){return this.on(t+".ui-disableSelection",function(t){t.preventDefault()})}}(),enableSelection:function(){return this.off(".ui-disableSelection")}});var c="ui-effects-",u="ui-effects-style",d="ui-effects-animated",p=t;t.effects={effect:{}},function(t,e){function i(t,e,i){var s=u[e.type]||{};return null==t?i||!e.def?null:e.def:(t=s.floor?~~t:parseFloat(t),isNaN(t)?e.def:s.mod?(t+s.mod)%s.mod:0>t?0:t>s.max?s.max:t)}function s(i){var s=l(),n=s._rgba=[];return i=i.toLowerCase(),f(h,function(t,o){var a,r=o.re.exec(i),h=r&&o.parse(r),l=o.space||"rgba";return h?(a=s[l](h),s[c[l].cache]=a[c[l].cache],n=s._rgba=a._rgba,!1):e}),n.length?("0,0,0,0"===n.join()&&t.extend(n,o.transparent),s):o[i]}function n(t,e,i){return i=(i+1)%1,1>6*i?t+6*(e-t)*i:1>2*i?e:2>3*i?t+6*(e-t)*(2/3-i):t}var o,a="backgroundColor borderBottomColor borderLeftColor borderRightColor borderTopColor color columnRuleColor outlineColor textDecorationColor textEmphasisColor",r=/^([\-+])=\s*(\d+\.?\d*)/,h=[{re:/rgba?\(\s*(\d{1,3})\s*,\s*(\d{1,3})\s*,\s*(\d{1,3})\s*(?:,\s*(\d?(?:\.\d+)?)\s*)?\)/,parse:function(t){return[t[1],t[2],t[3],t[4]]}},{re:/rgba?\(\s*(\d+(?:\.\d+)?)\%\s*,\s*(\d+(?:\.\d+)?)\%\s*,\s*(\d+(?:\.\d+)?)\%\s*(?:,\s*(\d?(?:\.\d+)?)\s*)?\)/,parse:function(t){return[2.55*t[1],2.55*t[2],2.55*t[3],t[4]]}},{re:/#([a-f0-9]{2})([a-f0-9]{2})([a-f0-9]{2})/,parse:function(t){return[parseInt(t[1],16),parseInt(t[2],16),parseInt(t[3],16)]}},{re:/#([a-f0-9])([a-f0-9])([a-f0-9])/,parse:function(t){return[parseInt(t[1]+t[1],16),parseInt(t[2]+t[2],16),parseInt(t[3]+t[3],16)]}},{re:/hsla?\(\s*(\d+(?:\.\d+)?)\s*,\s*(\d+(?:\.\d+)?)\%\s*,\s*(\d+(?:\.\d+)?)\%\s*(?:,\s*(\d?(?:\.\d+)?)\s*)?\)/,space:"hsla",parse:function(t){return[t[1],t[2]/100,t[3]/100,t[4]]}}],l=t.Color=function(e,i,s,n){return new t.Color.fn.parse(e,i,s,n)},c={rgba:{props:{red:{idx:0,type:"byte"},green:{idx:1,type:"byte"},blue:{idx:2,type:"byte"}}},hsla:{props:{hue:{idx:0,type:"degrees"},saturation:{idx:1,type:"percent"},lightness:{idx:2,type:"percent"}}}},u={"byte":{floor:!0,max:255},percent:{max:1},degrees:{mod:360,floor:!0}},d=l.support={},p=t("<p>")[0],f=t.each;p.style.cssText="background-color:rgba(1,1,1,.5)",d.rgba=p.style.backgroundColor.indexOf("rgba")>-1,f(c,function(t,e){e.cache="_"+t,e.props.alpha={idx:3,type:"percent",def:1}}),l.fn=t.extend(l.prototype,{parse:function(n,a,r,h){if(n===e)return this._rgba=[null,null,null,null],this;(n.jquery||n.nodeType)&&(n=t(n).css(a),a=e);var u=this,d=t.type(n),p=this._rgba=[];return a!==e&&(n=[n,a,r,h],d="array"),"string"===d?this.parse(s(n)||o._default):"array"===d?(f(c.rgba.props,function(t,e){p[e.idx]=i(n[e.idx],e)}),this):"object"===d?(n instanceof l?f(c,function(t,e){n[e.cache]&&(u[e.cache]=n[e.cache].slice())}):f(c,function(e,s){var o=s.cache;f(s.props,function(t,e){if(!u[o]&&s.to){if("alpha"===t||null==n[t])return;u[o]=s.to(u._rgba)}u[o][e.idx]=i(n[t],e,!0)}),u[o]&&0>t.inArray(null,u[o].slice(0,3))&&(u[o][3]=1,s.from&&(u._rgba=s.from(u[o])))}),this):e},is:function(t){var i=l(t),s=!0,n=this;return f(c,function(t,o){var a,r=i[o.cache];return r&&(a=n[o.cache]||o.to&&o.to(n._rgba)||[],f(o.props,function(t,i){return null!=r[i.idx]?s=r[i.idx]===a[i.idx]:e})),s}),s},_space:function(){var t=[],e=this;return f(c,function(i,s){e[s.cache]&&t.push(i)}),t.pop()},transition:function(t,e){var s=l(t),n=s._space(),o=c[n],a=0===this.alpha()?l("transparent"):this,r=a[o.cache]||o.to(a._rgba),h=r.slice();return s=s[o.cache],f(o.props,function(t,n){var o=n.idx,a=r[o],l=s[o],c=u[n.type]||{};null!==l&&(null===a?h[o]=l:(c.mod&&(l-a>c.mod/2?a+=c.mod:a-l>c.mod/2&&(a-=c.mod)),h[o]=i((l-a)*e+a,n)))}),this[n](h)},blend:function(e){if(1===this._rgba[3])return this;var i=this._rgba.slice(),s=i.pop(),n=l(e)._rgba;return l(t.map(i,function(t,e){return(1-s)*n[e]+s*t}))},toRgbaString:function(){var e="rgba(",i=t.map(this._rgba,function(t,e){return null==t?e>2?1:0:t});return 1===i[3]&&(i.pop(),e="rgb("),e+i.join()+")"},toHslaString:function(){var e="hsla(",i=t.map(this.hsla(),function(t,e){return null==t&&(t=e>2?1:0),e&&3>e&&(t=Math.round(100*t)+"%"),t});return 1===i[3]&&(i.pop(),e="hsl("),e+i.join()+")"},toHexString:function(e){var i=this._rgba.slice(),s=i.pop();return e&&i.push(~~(255*s)),"#"+t.map(i,function(t){return t=(t||0).toString(16),1===t.length?"0"+t:t}).join("")},toString:function(){return 0===this._rgba[3]?"transparent":this.toRgbaString()}}),l.fn.parse.prototype=l.fn,c.hsla.to=function(t){if(null==t[0]||null==t[1]||null==t[2])return[null,null,null,t[3]];var e,i,s=t[0]/255,n=t[1]/255,o=t[2]/255,a=t[3],r=Math.max(s,n,o),h=Math.min(s,n,o),l=r-h,c=r+h,u=.5*c;return e=h===r?0:s===r?60*(n-o)/l+360:n===r?60*(o-s)/l+120:60*(s-n)/l+240,i=0===l?0:.5>=u?l/c:l/(2-c),[Math.round(e)%360,i,u,null==a?1:a]},c.hsla.from=function(t){if(null==t[0]||null==t[1]||null==t[2])return[null,null,null,t[3]];var e=t[0]/360,i=t[1],s=t[2],o=t[3],a=.5>=s?s*(1+i):s+i-s*i,r=2*s-a;return[Math.round(255*n(r,a,e+1/3)),Math.round(255*n(r,a,e)),Math.round(255*n(r,a,e-1/3)),o]},f(c,function(s,n){var o=n.props,a=n.cache,h=n.to,c=n.from;l.fn[s]=function(s){if(h&&!this[a]&&(this[a]=h(this._rgba)),s===e)return this[a].slice();var n,r=t.type(s),u="array"===r||"object"===r?s:arguments,d=this[a].slice();return f(o,function(t,e){var s=u["object"===r?t:e.idx];null==s&&(s=d[e.idx]),d[e.idx]=i(s,e)}),c?(n=l(c(d)),n[a]=d,n):l(d)},f(o,function(e,i){l.fn[e]||(l.fn[e]=function(n){var o,a=t.type(n),h="alpha"===e?this._hsla?"hsla":"rgba":s,l=this[h](),c=l[i.idx];return"undefined"===a?c:("function"===a&&(n=n.call(this,c),a=t.type(n)),null==n&&i.empty?this:("string"===a&&(o=r.exec(n),o&&(n=c+parseFloat(o[2])*("+"===o[1]?1:-1))),l[i.idx]=n,this[h](l)))})})}),l.hook=function(e){var i=e.split(" ");f(i,function(e,i){t.cssHooks[i]={set:function(e,n){var o,a,r="";if("transparent"!==n&&("string"!==t.type(n)||(o=s(n)))){if(n=l(o||n),!d.rgba&&1!==n._rgba[3]){for(a="backgroundColor"===i?e.parentNode:e;(""===r||"transparent"===r)&&a&&a.style;)try{r=t.css(a,"backgroundColor"),a=a.parentNode}catch(h){}n=n.blend(r&&"transparent"!==r?r:"_default")}n=n.toRgbaString()}try{e.style[i]=n}catch(h){}}},t.fx.step[i]=function(e){e.colorInit||(e.start=l(e.elem,i),e.end=l(e.end),e.colorInit=!0),t.cssHooks[i].set(e.elem,e.start.transition(e.end,e.pos))}})},l.hook(a),t.cssHooks.borderColor={expand:function(t){var e={};return f(["Top","Right","Bottom","Left"],function(i,s){e["border"+s+"Color"]=t}),e}},o=t.Color.names={aqua:"#00ffff",black:"#000000",blue:"#0000ff",fuchsia:"#ff00ff",gray:"#808080",green:"#008000",lime:"#00ff00",maroon:"#800000",navy:"#000080",olive:"#808000",purple:"#800080",red:"#ff0000",silver:"#c0c0c0",teal:"#008080",white:"#ffffff",yellow:"#ffff00",transparent:[null,null,null,0],_default:"#ffffff"}}(p),function(){function e(e){var i,s,n=e.ownerDocument.defaultView?e.ownerDocument.defaultView.getComputedStyle(e,null):e.currentStyle,o={};if(n&&n.length&&n[0]&&n[n[0]])for(s=n.length;s--;)i=n[s],"string"==typeof n[i]&&(o[t.camelCase(i)]=n[i]);else for(i in n)"string"==typeof n[i]&&(o[i]=n[i]);return o}function i(e,i){var s,o,a={};for(s in i)o=i[s],e[s]!==o&&(n[s]||(t.fx.step[s]||!isNaN(parseFloat(o)))&&(a[s]=o));return a}var s=["add","remove","toggle"],n={border:1,borderBottom:1,borderColor:1,borderLeft:1,borderRight:1,borderTop:1,borderWidth:1,margin:1,padding:1};t.each(["borderLeftStyle","borderRightStyle","borderBottomStyle","borderTopStyle"],function(e,i){t.fx.step[i]=function(t){("none"!==t.end&&!t.setAttr||1===t.pos&&!t.setAttr)&&(p.style(t.elem,i,t.end),t.setAttr=!0)}}),t.fn.addBack||(t.fn.addBack=function(t){return this.add(null==t?this.prevObject:this.prevObject.filter(t))}),t.effects.animateClass=function(n,o,a,r){var h=t.speed(o,a,r);return this.queue(function(){var o,a=t(this),r=a.attr("class")||"",l=h.children?a.find("*").addBack():a;l=l.map(function(){var i=t(this);return{el:i,start:e(this)}}),o=function(){t.each(s,function(t,e){n[e]&&a[e+"Class"](n[e])})},o(),l=l.map(function(){return this.end=e(this.el[0]),this.diff=i(this.start,this.end),this}),a.attr("class",r),l=l.map(function(){var e=this,i=t.Deferred(),s=t.extend({},h,{queue:!1,complete:function(){i.resolve(e)}});return this.el.animate(this.diff,s),i.promise()}),t.when.apply(t,l.get()).done(function(){o(),t.each(arguments,function(){var e=this.el;t.each(this.diff,function(t){e.css(t,"")})}),h.complete.call(a[0])})})},t.fn.extend({addClass:function(e){return function(i,s,n,o){return s?t.effects.animateClass.call(this,{add:i},s,n,o):e.apply(this,arguments)}}(t.fn.addClass),removeClass:function(e){return function(i,s,n,o){return arguments.length>1?t.effects.animateClass.call(this,{remove:i},s,n,o):e.apply(this,arguments)}}(t.fn.removeClass),toggleClass:function(e){return function(i,s,n,o,a){return"boolean"==typeof s||void 0===s?n?t.effects.animateClass.call(this,s?{add:i}:{remove:i},n,o,a):e.apply(this,arguments):t.effects.animateClass.call(this,{toggle:i},s,n,o)}}(t.fn.toggleClass),switchClass:function(e,i,s,n,o){return t.effects.animateClass.call(this,{add:i,remove:e},s,n,o)}})}(),function(){function e(e,i,s,n){return t.isPlainObject(e)&&(i=e,e=e.effect),e={effect:e},null==i&&(i={}),t.isFunction(i)&&(n=i,s=null,i={}),("number"==typeof i||t.fx.speeds[i])&&(n=s,s=i,i={}),t.isFunction(s)&&(n=s,s=null),i&&t.extend(e,i),s=s||i.duration,e.duration=t.fx.off?0:"number"==typeof s?s:s in t.fx.speeds?t.fx.speeds[s]:t.fx.speeds._default,e.complete=n||i.complete,e}function i(e){return!e||"number"==typeof e||t.fx.speeds[e]?!0:"string"!=typeof e||t.effects.effect[e]?t.isFunction(e)?!0:"object"!=typeof e||e.effect?!1:!0:!0}function s(t,e){var i=e.outerWidth(),s=e.outerHeight(),n=/^rect\((-?\d*\.?\d*px|-?\d+%|auto),?\s*(-?\d*\.?\d*px|-?\d+%|auto),?\s*(-?\d*\.?\d*px|-?\d+%|auto),?\s*(-?\d*\.?\d*px|-?\d+%|auto)\)$/,o=n.exec(t)||["",0,i,s,0];return{top:parseFloat(o[1])||0,right:"auto"===o[2]?i:parseFloat(o[2]),bottom:"auto"===o[3]?s:parseFloat(o[3]),left:parseFloat(o[4])||0}}t.expr&&t.expr.filters&&t.expr.filters.animated&&(t.expr.filters.animated=function(e){return function(i){return!!t(i).data(d)||e(i)}}(t.expr.filters.animated)),t.uiBackCompat!==!1&&t.extend(t.effects,{save:function(t,e){for(var i=0,s=e.length;s>i;i++)null!==e[i]&&t.data(c+e[i],t[0].style[e[i]])},restore:function(t,e){for(var i,s=0,n=e.length;n>s;s++)null!==e[s]&&(i=t.data(c+e[s]),t.css(e[s],i))},setMode:function(t,e){return"toggle"===e&&(e=t.is(":hidden")?"show":"hide"),e},createWrapper:function(e){if(e.parent().is(".ui-effects-wrapper"))return e.parent();var i={width:e.outerWidth(!0),height:e.outerHeight(!0),"float":e.css("float")},s=t("<div></div>").addClass("ui-effects-wrapper").css({fontSize:"100%",background:"transparent",border:"none",margin:0,padding:0}),n={width:e.width(),height:e.height()},o=document.activeElement;try{o.id}catch(a){o=document.body}return e.wrap(s),(e[0]===o||t.contains(e[0],o))&&t(o).trigger("focus"),s=e.parent(),"static"===e.css("position")?(s.css({position:"relative"}),e.css({position:"relative"})):(t.extend(i,{position:e.css("position"),zIndex:e.css("z-index")}),t.each(["top","left","bottom","right"],function(t,s){i[s]=e.css(s),isNaN(parseInt(i[s],10))&&(i[s]="auto")}),e.css({position:"relative",top:0,left:0,right:"auto",bottom:"auto"})),e.css(n),s.css(i).show()},removeWrapper:function(e){var i=document.activeElement;return e.parent().is(".ui-effects-wrapper")&&(e.parent().replaceWith(e),(e[0]===i||t.contains(e[0],i))&&t(i).trigger("focus")),e}}),t.extend(t.effects,{version:"1.12.1",define:function(e,i,s){return s||(s=i,i="effect"),t.effects.effect[e]=s,t.effects.effect[e].mode=i,s},scaledDimensions:function(t,e,i){if(0===e)return{height:0,width:0,outerHeight:0,outerWidth:0};var s="horizontal"!==i?(e||100)/100:1,n="vertical"!==i?(e||100)/100:1;return{height:t.height()*n,width:t.width()*s,outerHeight:t.outerHeight()*n,outerWidth:t.outerWidth()*s}},clipToBox:function(t){return{width:t.clip.right-t.clip.left,height:t.clip.bottom-t.clip.top,left:t.clip.left,top:t.clip.top}},unshift:function(t,e,i){var s=t.queue();e>1&&s.splice.apply(s,[1,0].concat(s.splice(e,i))),t.dequeue()},saveStyle:function(t){t.data(u,t[0].style.cssText)},restoreStyle:function(t){t[0].style.cssText=t.data(u)||"",t.removeData(u)},mode:function(t,e){var i=t.is(":hidden");return"toggle"===e&&(e=i?"show":"hide"),(i?"hide"===e:"show"===e)&&(e="none"),e},getBaseline:function(t,e){var i,s;switch(t[0]){case"top":i=0;break;case"middle":i=.5;break;case"bottom":i=1;break;default:i=t[0]/e.height}switch(t[1]){case"left":s=0;break;case"center":s=.5;break;case"right":s=1;break;default:s=t[1]/e.width}return{x:s,y:i}},createPlaceholder:function(e){var i,s=e.css("position"),n=e.position();return e.css({marginTop:e.css("marginTop"),marginBottom:e.css("marginBottom"),marginLeft:e.css("marginLeft"),marginRight:e.css("marginRight")}).outerWidth(e.outerWidth()).outerHeight(e.outerHeight()),/^(static|relative)/.test(s)&&(s="absolute",i=t("<"+e[0].nodeName+">").insertAfter(e).css({display:/^(inline|ruby)/.test(e.css("display"))?"inline-block":"block",visibility:"hidden",marginTop:e.css("marginTop"),marginBottom:e.css("marginBottom"),marginLeft:e.css("marginLeft"),marginRight:e.css("marginRight"),"float":e.css("float")}).outerWidth(e.outerWidth()).outerHeight(e.outerHeight()).addClass("ui-effects-placeholder"),e.data(c+"placeholder",i)),e.css({position:s,left:n.left,top:n.top}),i},removePlaceholder:function(t){var e=c+"placeholder",i=t.data(e);i&&(i.remove(),t.removeData(e))},cleanUp:function(e){t.effects.restoreStyle(e),t.effects.removePlaceholder(e)},setTransition:function(e,i,s,n){return n=n||{},t.each(i,function(t,i){var o=e.cssUnit(i);o[0]>0&&(n[i]=o[0]*s+o[1])}),n}}),t.fn.extend({effect:function(){function i(e){function i(){r.removeData(d),t.effects.cleanUp(r),"hide"===s.mode&&r.hide(),a()}function a(){t.isFunction(h)&&h.call(r[0]),t.isFunction(e)&&e()}var r=t(this);s.mode=c.shift(),t.uiBackCompat===!1||o?"none"===s.mode?(r[l](),a()):n.call(r[0],s,i):(r.is(":hidden")?"hide"===l:"show"===l)?(r[l](),a()):n.call(r[0],s,a)}var s=e.apply(this,arguments),n=t.effects.effect[s.effect],o=n.mode,a=s.queue,r=a||"fx",h=s.complete,l=s.mode,c=[],u=function(e){var i=t(this),s=t.effects.mode(i,l)||o;i.data(d,!0),c.push(s),o&&("show"===s||s===o&&"hide"===s)&&i.show(),o&&"none"===s||t.effects.saveStyle(i),t.isFunction(e)&&e()};return t.fx.off||!n?l?this[l](s.duration,h):this.each(function(){h&&h.call(this)}):a===!1?this.each(u).each(i):this.queue(r,u).queue(r,i)},show:function(t){return function(s){if(i(s))return t.apply(this,arguments);var n=e.apply(this,arguments);return n.mode="show",this.effect.call(this,n)
-}}(t.fn.show),hide:function(t){return function(s){if(i(s))return t.apply(this,arguments);var n=e.apply(this,arguments);return n.mode="hide",this.effect.call(this,n)}}(t.fn.hide),toggle:function(t){return function(s){if(i(s)||"boolean"==typeof s)return t.apply(this,arguments);var n=e.apply(this,arguments);return n.mode="toggle",this.effect.call(this,n)}}(t.fn.toggle),cssUnit:function(e){var i=this.css(e),s=[];return t.each(["em","px","%","pt"],function(t,e){i.indexOf(e)>0&&(s=[parseFloat(i),e])}),s},cssClip:function(t){return t?this.css("clip","rect("+t.top+"px "+t.right+"px "+t.bottom+"px "+t.left+"px)"):s(this.css("clip"),this)},transfer:function(e,i){var s=t(this),n=t(e.to),o="fixed"===n.css("position"),a=t("body"),r=o?a.scrollTop():0,h=o?a.scrollLeft():0,l=n.offset(),c={top:l.top-r,left:l.left-h,height:n.innerHeight(),width:n.innerWidth()},u=s.offset(),d=t("<div class='ui-effects-transfer'></div>").appendTo("body").addClass(e.className).css({top:u.top-r,left:u.left-h,height:s.innerHeight(),width:s.innerWidth(),position:o?"fixed":"absolute"}).animate(c,e.duration,e.easing,function(){d.remove(),t.isFunction(i)&&i()})}}),t.fx.step.clip=function(e){e.clipInit||(e.start=t(e.elem).cssClip(),"string"==typeof e.end&&(e.end=s(e.end,e.elem)),e.clipInit=!0),t(e.elem).cssClip({top:e.pos*(e.end.top-e.start.top)+e.start.top,right:e.pos*(e.end.right-e.start.right)+e.start.right,bottom:e.pos*(e.end.bottom-e.start.bottom)+e.start.bottom,left:e.pos*(e.end.left-e.start.left)+e.start.left})}}(),function(){var e={};t.each(["Quad","Cubic","Quart","Quint","Expo"],function(t,i){e[i]=function(e){return Math.pow(e,t+2)}}),t.extend(e,{Sine:function(t){return 1-Math.cos(t*Math.PI/2)},Circ:function(t){return 1-Math.sqrt(1-t*t)},Elastic:function(t){return 0===t||1===t?t:-Math.pow(2,8*(t-1))*Math.sin((80*(t-1)-7.5)*Math.PI/15)},Back:function(t){return t*t*(3*t-2)},Bounce:function(t){for(var e,i=4;((e=Math.pow(2,--i))-1)/11>t;);return 1/Math.pow(4,3-i)-7.5625*Math.pow((3*e-2)/22-t,2)}}),t.each(e,function(e,i){t.easing["easeIn"+e]=i,t.easing["easeOut"+e]=function(t){return 1-i(1-t)},t.easing["easeInOut"+e]=function(t){return.5>t?i(2*t)/2:1-i(-2*t+2)/2}})}();var f=t.effects;t.effects.define("blind","hide",function(e,i){var s={up:["bottom","top"],vertical:["bottom","top"],down:["top","bottom"],left:["right","left"],horizontal:["right","left"],right:["left","right"]},n=t(this),o=e.direction||"up",a=n.cssClip(),r={clip:t.extend({},a)},h=t.effects.createPlaceholder(n);r.clip[s[o][0]]=r.clip[s[o][1]],"show"===e.mode&&(n.cssClip(r.clip),h&&h.css(t.effects.clipToBox(r)),r.clip=a),h&&h.animate(t.effects.clipToBox(r),e.duration,e.easing),n.animate(r,{queue:!1,duration:e.duration,easing:e.easing,complete:i})}),t.effects.define("bounce",function(e,i){var s,n,o,a=t(this),r=e.mode,h="hide"===r,l="show"===r,c=e.direction||"up",u=e.distance,d=e.times||5,p=2*d+(l||h?1:0),f=e.duration/p,g=e.easing,m="up"===c||"down"===c?"top":"left",_="up"===c||"left"===c,v=0,b=a.queue().length;for(t.effects.createPlaceholder(a),o=a.css(m),u||(u=a["top"===m?"outerHeight":"outerWidth"]()/3),l&&(n={opacity:1},n[m]=o,a.css("opacity",0).css(m,_?2*-u:2*u).animate(n,f,g)),h&&(u/=Math.pow(2,d-1)),n={},n[m]=o;d>v;v++)s={},s[m]=(_?"-=":"+=")+u,a.animate(s,f,g).animate(n,f,g),u=h?2*u:u/2;h&&(s={opacity:0},s[m]=(_?"-=":"+=")+u,a.animate(s,f,g)),a.queue(i),t.effects.unshift(a,b,p+1)}),t.effects.define("clip","hide",function(e,i){var s,n={},o=t(this),a=e.direction||"vertical",r="both"===a,h=r||"horizontal"===a,l=r||"vertical"===a;s=o.cssClip(),n.clip={top:l?(s.bottom-s.top)/2:s.top,right:h?(s.right-s.left)/2:s.right,bottom:l?(s.bottom-s.top)/2:s.bottom,left:h?(s.right-s.left)/2:s.left},t.effects.createPlaceholder(o),"show"===e.mode&&(o.cssClip(n.clip),n.clip=s),o.animate(n,{queue:!1,duration:e.duration,easing:e.easing,complete:i})}),t.effects.define("drop","hide",function(e,i){var s,n=t(this),o=e.mode,a="show"===o,r=e.direction||"left",h="up"===r||"down"===r?"top":"left",l="up"===r||"left"===r?"-=":"+=",c="+="===l?"-=":"+=",u={opacity:0};t.effects.createPlaceholder(n),s=e.distance||n["top"===h?"outerHeight":"outerWidth"](!0)/2,u[h]=l+s,a&&(n.css(u),u[h]=c+s,u.opacity=1),n.animate(u,{queue:!1,duration:e.duration,easing:e.easing,complete:i})}),t.effects.define("explode","hide",function(e,i){function s(){b.push(this),b.length===u*d&&n()}function n(){p.css({visibility:"visible"}),t(b).remove(),i()}var o,a,r,h,l,c,u=e.pieces?Math.round(Math.sqrt(e.pieces)):3,d=u,p=t(this),f=e.mode,g="show"===f,m=p.show().css("visibility","hidden").offset(),_=Math.ceil(p.outerWidth()/d),v=Math.ceil(p.outerHeight()/u),b=[];for(o=0;u>o;o++)for(h=m.top+o*v,c=o-(u-1)/2,a=0;d>a;a++)r=m.left+a*_,l=a-(d-1)/2,p.clone().appendTo("body").wrap("<div></div>").css({position:"absolute",visibility:"visible",left:-a*_,top:-o*v}).parent().addClass("ui-effects-explode").css({position:"absolute",overflow:"hidden",width:_,height:v,left:r+(g?l*_:0),top:h+(g?c*v:0),opacity:g?0:1}).animate({left:r+(g?0:l*_),top:h+(g?0:c*v),opacity:g?1:0},e.duration||500,e.easing,s)}),t.effects.define("fade","toggle",function(e,i){var s="show"===e.mode;t(this).css("opacity",s?0:1).animate({opacity:s?1:0},{queue:!1,duration:e.duration,easing:e.easing,complete:i})}),t.effects.define("fold","hide",function(e,i){var s=t(this),n=e.mode,o="show"===n,a="hide"===n,r=e.size||15,h=/([0-9]+)%/.exec(r),l=!!e.horizFirst,c=l?["right","bottom"]:["bottom","right"],u=e.duration/2,d=t.effects.createPlaceholder(s),p=s.cssClip(),f={clip:t.extend({},p)},g={clip:t.extend({},p)},m=[p[c[0]],p[c[1]]],_=s.queue().length;h&&(r=parseInt(h[1],10)/100*m[a?0:1]),f.clip[c[0]]=r,g.clip[c[0]]=r,g.clip[c[1]]=0,o&&(s.cssClip(g.clip),d&&d.css(t.effects.clipToBox(g)),g.clip=p),s.queue(function(i){d&&d.animate(t.effects.clipToBox(f),u,e.easing).animate(t.effects.clipToBox(g),u,e.easing),i()}).animate(f,u,e.easing).animate(g,u,e.easing).queue(i),t.effects.unshift(s,_,4)}),t.effects.define("highlight","show",function(e,i){var s=t(this),n={backgroundColor:s.css("backgroundColor")};"hide"===e.mode&&(n.opacity=0),t.effects.saveStyle(s),s.css({backgroundImage:"none",backgroundColor:e.color||"#ffff99"}).animate(n,{queue:!1,duration:e.duration,easing:e.easing,complete:i})}),t.effects.define("size",function(e,i){var s,n,o,a=t(this),r=["fontSize"],h=["borderTopWidth","borderBottomWidth","paddingTop","paddingBottom"],l=["borderLeftWidth","borderRightWidth","paddingLeft","paddingRight"],c=e.mode,u="effect"!==c,d=e.scale||"both",p=e.origin||["middle","center"],f=a.css("position"),g=a.position(),m=t.effects.scaledDimensions(a),_=e.from||m,v=e.to||t.effects.scaledDimensions(a,0);t.effects.createPlaceholder(a),"show"===c&&(o=_,_=v,v=o),n={from:{y:_.height/m.height,x:_.width/m.width},to:{y:v.height/m.height,x:v.width/m.width}},("box"===d||"both"===d)&&(n.from.y!==n.to.y&&(_=t.effects.setTransition(a,h,n.from.y,_),v=t.effects.setTransition(a,h,n.to.y,v)),n.from.x!==n.to.x&&(_=t.effects.setTransition(a,l,n.from.x,_),v=t.effects.setTransition(a,l,n.to.x,v))),("content"===d||"both"===d)&&n.from.y!==n.to.y&&(_=t.effects.setTransition(a,r,n.from.y,_),v=t.effects.setTransition(a,r,n.to.y,v)),p&&(s=t.effects.getBaseline(p,m),_.top=(m.outerHeight-_.outerHeight)*s.y+g.top,_.left=(m.outerWidth-_.outerWidth)*s.x+g.left,v.top=(m.outerHeight-v.outerHeight)*s.y+g.top,v.left=(m.outerWidth-v.outerWidth)*s.x+g.left),a.css(_),("content"===d||"both"===d)&&(h=h.concat(["marginTop","marginBottom"]).concat(r),l=l.concat(["marginLeft","marginRight"]),a.find("*[width]").each(function(){var i=t(this),s=t.effects.scaledDimensions(i),o={height:s.height*n.from.y,width:s.width*n.from.x,outerHeight:s.outerHeight*n.from.y,outerWidth:s.outerWidth*n.from.x},a={height:s.height*n.to.y,width:s.width*n.to.x,outerHeight:s.height*n.to.y,outerWidth:s.width*n.to.x};n.from.y!==n.to.y&&(o=t.effects.setTransition(i,h,n.from.y,o),a=t.effects.setTransition(i,h,n.to.y,a)),n.from.x!==n.to.x&&(o=t.effects.setTransition(i,l,n.from.x,o),a=t.effects.setTransition(i,l,n.to.x,a)),u&&t.effects.saveStyle(i),i.css(o),i.animate(a,e.duration,e.easing,function(){u&&t.effects.restoreStyle(i)})})),a.animate(v,{queue:!1,duration:e.duration,easing:e.easing,complete:function(){var e=a.offset();0===v.opacity&&a.css("opacity",_.opacity),u||(a.css("position","static"===f?"relative":f).offset(e),t.effects.saveStyle(a)),i()}})}),t.effects.define("scale",function(e,i){var s=t(this),n=e.mode,o=parseInt(e.percent,10)||(0===parseInt(e.percent,10)?0:"effect"!==n?0:100),a=t.extend(!0,{from:t.effects.scaledDimensions(s),to:t.effects.scaledDimensions(s,o,e.direction||"both"),origin:e.origin||["middle","center"]},e);e.fade&&(a.from.opacity=1,a.to.opacity=0),t.effects.effect.size.call(this,a,i)}),t.effects.define("puff","hide",function(e,i){var s=t.extend(!0,{},e,{fade:!0,percent:parseInt(e.percent,10)||150});t.effects.effect.scale.call(this,s,i)}),t.effects.define("pulsate","show",function(e,i){var s=t(this),n=e.mode,o="show"===n,a="hide"===n,r=o||a,h=2*(e.times||5)+(r?1:0),l=e.duration/h,c=0,u=1,d=s.queue().length;for((o||!s.is(":visible"))&&(s.css("opacity",0).show(),c=1);h>u;u++)s.animate({opacity:c},l,e.easing),c=1-c;s.animate({opacity:c},l,e.easing),s.queue(i),t.effects.unshift(s,d,h+1)}),t.effects.define("shake",function(e,i){var s=1,n=t(this),o=e.direction||"left",a=e.distance||20,r=e.times||3,h=2*r+1,l=Math.round(e.duration/h),c="up"===o||"down"===o?"top":"left",u="up"===o||"left"===o,d={},p={},f={},g=n.queue().length;for(t.effects.createPlaceholder(n),d[c]=(u?"-=":"+=")+a,p[c]=(u?"+=":"-=")+2*a,f[c]=(u?"-=":"+=")+2*a,n.animate(d,l,e.easing);r>s;s++)n.animate(p,l,e.easing).animate(f,l,e.easing);n.animate(p,l,e.easing).animate(d,l/2,e.easing).queue(i),t.effects.unshift(n,g,h+1)}),t.effects.define("slide","show",function(e,i){var s,n,o=t(this),a={up:["bottom","top"],down:["top","bottom"],left:["right","left"],right:["left","right"]},r=e.mode,h=e.direction||"left",l="up"===h||"down"===h?"top":"left",c="up"===h||"left"===h,u=e.distance||o["top"===l?"outerHeight":"outerWidth"](!0),d={};t.effects.createPlaceholder(o),s=o.cssClip(),n=o.position()[l],d[l]=(c?-1:1)*u+n,d.clip=o.cssClip(),d.clip[a[h][1]]=d.clip[a[h][0]],"show"===r&&(o.cssClip(d.clip),o.css(l,d[l]),d.clip=s,d[l]=n),o.animate(d,{queue:!1,duration:e.duration,easing:e.easing,complete:i})});var f;t.uiBackCompat!==!1&&(f=t.effects.define("transfer",function(e,i){t(this).transfer(e,i)})),t.ui.focusable=function(i,s){var n,o,a,r,h,l=i.nodeName.toLowerCase();return"area"===l?(n=i.parentNode,o=n.name,i.href&&o&&"map"===n.nodeName.toLowerCase()?(a=t("img[usemap='#"+o+"']"),a.length>0&&a.is(":visible")):!1):(/^(input|select|textarea|button|object)$/.test(l)?(r=!i.disabled,r&&(h=t(i).closest("fieldset")[0],h&&(r=!h.disabled))):r="a"===l?i.href||s:s,r&&t(i).is(":visible")&&e(t(i)))},t.extend(t.expr[":"],{focusable:function(e){return t.ui.focusable(e,null!=t.attr(e,"tabindex"))}}),t.ui.focusable,t.fn.form=function(){return"string"==typeof this[0].form?this.closest("form"):t(this[0].form)},t.ui.formResetMixin={_formResetHandler:function(){var e=t(this);setTimeout(function(){var i=e.data("ui-form-reset-instances");t.each(i,function(){this.refresh()})})},_bindFormResetHandler:function(){if(this.form=this.element.form(),this.form.length){var t=this.form.data("ui-form-reset-instances")||[];t.length||this.form.on("reset.ui-form-reset",this._formResetHandler),t.push(this),this.form.data("ui-form-reset-instances",t)}},_unbindFormResetHandler:function(){if(this.form.length){var e=this.form.data("ui-form-reset-instances");e.splice(t.inArray(this,e),1),e.length?this.form.data("ui-form-reset-instances",e):this.form.removeData("ui-form-reset-instances").off("reset.ui-form-reset")}}},"1.7"===t.fn.jquery.substring(0,3)&&(t.each(["Width","Height"],function(e,i){function s(e,i,s,o){return t.each(n,function(){i-=parseFloat(t.css(e,"padding"+this))||0,s&&(i-=parseFloat(t.css(e,"border"+this+"Width"))||0),o&&(i-=parseFloat(t.css(e,"margin"+this))||0)}),i}var n="Width"===i?["Left","Right"]:["Top","Bottom"],o=i.toLowerCase(),a={innerWidth:t.fn.innerWidth,innerHeight:t.fn.innerHeight,outerWidth:t.fn.outerWidth,outerHeight:t.fn.outerHeight};t.fn["inner"+i]=function(e){return void 0===e?a["inner"+i].call(this):this.each(function(){t(this).css(o,s(this,e)+"px")})},t.fn["outer"+i]=function(e,n){return"number"!=typeof e?a["outer"+i].call(this,e):this.each(function(){t(this).css(o,s(this,e,!0,n)+"px")})}}),t.fn.addBack=function(t){return this.add(null==t?this.prevObject:this.prevObject.filter(t))}),t.ui.keyCode={BACKSPACE:8,COMMA:188,DELETE:46,DOWN:40,END:35,ENTER:13,ESCAPE:27,HOME:36,LEFT:37,PAGE_DOWN:34,PAGE_UP:33,PERIOD:190,RIGHT:39,SPACE:32,TAB:9,UP:38},t.ui.escapeSelector=function(){var t=/([!"#$%&'()*+,./:;<=>?@[\]^`{|}~])/g;return function(e){return e.replace(t,"\\$1")}}(),t.fn.labels=function(){var e,i,s,n,o;return this[0].labels&&this[0].labels.length?this.pushStack(this[0].labels):(n=this.eq(0).parents("label"),s=this.attr("id"),s&&(e=this.eq(0).parents().last(),o=e.add(e.length?e.siblings():this.siblings()),i="label[for='"+t.ui.escapeSelector(s)+"']",n=n.add(o.find(i).addBack(i))),this.pushStack(n))},t.fn.scrollParent=function(e){var i=this.css("position"),s="absolute"===i,n=e?/(auto|scroll|hidden)/:/(auto|scroll)/,o=this.parents().filter(function(){var e=t(this);return s&&"static"===e.css("position")?!1:n.test(e.css("overflow")+e.css("overflow-y")+e.css("overflow-x"))}).eq(0);return"fixed"!==i&&o.length?o:t(this[0].ownerDocument||document)},t.extend(t.expr[":"],{tabbable:function(e){var i=t.attr(e,"tabindex"),s=null!=i;return(!s||i>=0)&&t.ui.focusable(e,s)}}),t.fn.extend({uniqueId:function(){var t=0;return function(){return this.each(function(){this.id||(this.id="ui-id-"+ ++t)})}}(),removeUniqueId:function(){return this.each(function(){/^ui-id-\d+$/.test(this.id)&&t(this).removeAttr("id")})}}),t.widget("ui.accordion",{version:"1.12.1",options:{active:0,animate:{},classes:{"ui-accordion-header":"ui-corner-top","ui-accordion-header-collapsed":"ui-corner-all","ui-accordion-content":"ui-corner-bottom"},collapsible:!1,event:"click",header:"> li > :first-child, > :not(li):even",heightStyle:"auto",icons:{activeHeader:"ui-icon-triangle-1-s",header:"ui-icon-triangle-1-e"},activate:null,beforeActivate:null},hideProps:{borderTopWidth:"hide",borderBottomWidth:"hide",paddingTop:"hide",paddingBottom:"hide",height:"hide"},showProps:{borderTopWidth:"show",borderBottomWidth:"show",paddingTop:"show",paddingBottom:"show",height:"show"},_create:function(){var e=this.options;this.prevShow=this.prevHide=t(),this._addClass("ui-accordion","ui-widget ui-helper-reset"),this.element.attr("role","tablist"),e.collapsible||e.active!==!1&&null!=e.active||(e.active=0),this._processPanels(),0>e.active&&(e.active+=this.headers.length),this._refresh()},_getCreateEventData:function(){return{header:this.active,panel:this.active.length?this.active.next():t()}},_createIcons:function(){var e,i,s=this.options.icons;s&&(e=t("<span>"),this._addClass(e,"ui-accordion-header-icon","ui-icon "+s.header),e.prependTo(this.headers),i=this.active.children(".ui-accordion-header-icon"),this._removeClass(i,s.header)._addClass(i,null,s.activeHeader)._addClass(this.headers,"ui-accordion-icons"))},_destroyIcons:function(){this._removeClass(this.headers,"ui-accordion-icons"),this.headers.children(".ui-accordion-header-icon").remove()},_destroy:function(){var t;this.element.removeAttr("role"),this.headers.removeAttr("role aria-expanded aria-selected aria-controls tabIndex").removeUniqueId(),this._destroyIcons(),t=this.headers.next().css("display","").removeAttr("role aria-hidden aria-labelledby").removeUniqueId(),"content"!==this.options.heightStyle&&t.css("height","")},_setOption:function(t,e){return"active"===t?(this._activate(e),void 0):("event"===t&&(this.options.event&&this._off(this.headers,this.options.event),this._setupEvents(e)),this._super(t,e),"collapsible"!==t||e||this.options.active!==!1||this._activate(0),"icons"===t&&(this._destroyIcons(),e&&this._createIcons()),void 0)},_setOptionDisabled:function(t){this._super(t),this.element.attr("aria-disabled",t),this._toggleClass(null,"ui-state-disabled",!!t),this._toggleClass(this.headers.add(this.headers.next()),null,"ui-state-disabled",!!t)},_keydown:function(e){if(!e.altKey&&!e.ctrlKey){var i=t.ui.keyCode,s=this.headers.length,n=this.headers.index(e.target),o=!1;switch(e.keyCode){case i.RIGHT:case i.DOWN:o=this.headers[(n+1)%s];break;case i.LEFT:case i.UP:o=this.headers[(n-1+s)%s];break;case i.SPACE:case i.ENTER:this._eventHandler(e);break;case i.HOME:o=this.headers[0];break;case i.END:o=this.headers[s-1]}o&&(t(e.target).attr("tabIndex",-1),t(o).attr("tabIndex",0),t(o).trigger("focus"),e.preventDefault())}},_panelKeyDown:function(e){e.keyCode===t.ui.keyCode.UP&&e.ctrlKey&&t(e.currentTarget).prev().trigger("focus")},refresh:function(){var e=this.options;this._processPanels(),e.active===!1&&e.collapsible===!0||!this.headers.length?(e.active=!1,this.active=t()):e.active===!1?this._activate(0):this.active.length&&!t.contains(this.element[0],this.active[0])?this.headers.length===this.headers.find(".ui-state-disabled").length?(e.active=!1,this.active=t()):this._activate(Math.max(0,e.active-1)):e.active=this.headers.index(this.active),this._destroyIcons(),this._refresh()},_processPanels:function(){var t=this.headers,e=this.panels;this.headers=this.element.find(this.options.header),this._addClass(this.headers,"ui-accordion-header ui-accordion-header-collapsed","ui-state-default"),this.panels=this.headers.next().filter(":not(.ui-accordion-content-active)").hide(),this._addClass(this.panels,"ui-accordion-content","ui-helper-reset ui-widget-content"),e&&(this._off(t.not(this.headers)),this._off(e.not(this.panels)))},_refresh:function(){var e,i=this.options,s=i.heightStyle,n=this.element.parent();this.active=this._findActive(i.active),this._addClass(this.active,"ui-accordion-header-active","ui-state-active")._removeClass(this.active,"ui-accordion-header-collapsed"),this._addClass(this.active.next(),"ui-accordion-content-active"),this.active.next().show(),this.headers.attr("role","tab").each(function(){var e=t(this),i=e.uniqueId().attr("id"),s=e.next(),n=s.uniqueId().attr("id");e.attr("aria-controls",n),s.attr("aria-labelledby",i)}).next().attr("role","tabpanel"),this.headers.not(this.active).attr({"aria-selected":"false","aria-expanded":"false",tabIndex:-1}).next().attr({"aria-hidden":"true"}).hide(),this.active.length?this.active.attr({"aria-selected":"true","aria-expanded":"true",tabIndex:0}).next().attr({"aria-hidden":"false"}):this.headers.eq(0).attr("tabIndex",0),this._createIcons(),this._setupEvents(i.event),"fill"===s?(e=n.height(),this.element.siblings(":visible").each(function(){var i=t(this),s=i.css("position");"absolute"!==s&&"fixed"!==s&&(e-=i.outerHeight(!0))}),this.headers.each(function(){e-=t(this).outerHeight(!0)}),this.headers.next().each(function(){t(this).height(Math.max(0,e-t(this).innerHeight()+t(this).height()))}).css("overflow","auto")):"auto"===s&&(e=0,this.headers.next().each(function(){var i=t(this).is(":visible");i||t(this).show(),e=Math.max(e,t(this).css("height","").height()),i||t(this).hide()}).height(e))},_activate:function(e){var i=this._findActive(e)[0];i!==this.active[0]&&(i=i||this.active[0],this._eventHandler({target:i,currentTarget:i,preventDefault:t.noop}))},_findActive:function(e){return"number"==typeof e?this.headers.eq(e):t()},_setupEvents:function(e){var i={keydown:"_keydown"};e&&t.each(e.split(" "),function(t,e){i[e]="_eventHandler"}),this._off(this.headers.add(this.headers.next())),this._on(this.headers,i),this._on(this.headers.next(),{keydown:"_panelKeyDown"}),this._hoverable(this.headers),this._focusable(this.headers)},_eventHandler:function(e){var i,s,n=this.options,o=this.active,a=t(e.currentTarget),r=a[0]===o[0],h=r&&n.collapsible,l=h?t():a.next(),c=o.next(),u={oldHeader:o,oldPanel:c,newHeader:h?t():a,newPanel:l};e.preventDefault(),r&&!n.collapsible||this._trigger("beforeActivate",e,u)===!1||(n.active=h?!1:this.headers.index(a),this.active=r?t():a,this._toggle(u),this._removeClass(o,"ui-accordion-header-active","ui-state-active"),n.icons&&(i=o.children(".ui-accordion-header-icon"),this._removeClass(i,null,n.icons.activeHeader)._addClass(i,null,n.icons.header)),r||(this._removeClass(a,"ui-accordion-header-collapsed")._addClass(a,"ui-accordion-header-active","ui-state-active"),n.icons&&(s=a.children(".ui-accordion-header-icon"),this._removeClass(s,null,n.icons.header)._addClass(s,null,n.icons.activeHeader)),this._addClass(a.next(),"ui-accordion-content-active")))},_toggle:function(e){var i=e.newPanel,s=this.prevShow.length?this.prevShow:e.oldPanel;this.prevShow.add(this.prevHide).stop(!0,!0),this.prevShow=i,this.prevHide=s,this.options.animate?this._animate(i,s,e):(s.hide(),i.show(),this._toggleComplete(e)),s.attr({"aria-hidden":"true"}),s.prev().attr({"aria-selected":"false","aria-expanded":"false"}),i.length&&s.length?s.prev().attr({tabIndex:-1,"aria-expanded":"false"}):i.length&&this.headers.filter(function(){return 0===parseInt(t(this).attr("tabIndex"),10)}).attr("tabIndex",-1),i.attr("aria-hidden","false").prev().attr({"aria-selected":"true","aria-expanded":"true",tabIndex:0})},_animate:function(t,e,i){var s,n,o,a=this,r=0,h=t.css("box-sizing"),l=t.length&&(!e.length||t.index()<e.index()),c=this.options.animate||{},u=l&&c.down||c,d=function(){a._toggleComplete(i)};return"number"==typeof u&&(o=u),"string"==typeof u&&(n=u),n=n||u.easing||c.easing,o=o||u.duration||c.duration,e.length?t.length?(s=t.show().outerHeight(),e.animate(this.hideProps,{duration:o,easing:n,step:function(t,e){e.now=Math.round(t)}}),t.hide().animate(this.showProps,{duration:o,easing:n,complete:d,step:function(t,i){i.now=Math.round(t),"height"!==i.prop?"content-box"===h&&(r+=i.now):"content"!==a.options.heightStyle&&(i.now=Math.round(s-e.outerHeight()-r),r=0)}}),void 0):e.animate(this.hideProps,o,n,d):t.animate(this.showProps,o,n,d)},_toggleComplete:function(t){var e=t.oldPanel,i=e.prev();this._removeClass(e,"ui-accordion-content-active"),this._removeClass(i,"ui-accordion-header-active")._addClass(i,"ui-accordion-header-collapsed"),e.length&&(e.parent()[0].className=e.parent()[0].className),this._trigger("activate",null,t)}}),t.ui.safeActiveElement=function(t){var e;try{e=t.activeElement}catch(i){e=t.body}return e||(e=t.body),e.nodeName||(e=t.body),e},t.widget("ui.menu",{version:"1.12.1",defaultElement:"<ul>",delay:300,options:{icons:{submenu:"ui-icon-caret-1-e"},items:"> *",menus:"ul",position:{my:"left top",at:"right top"},role:"menu",blur:null,focus:null,select:null},_create:function(){this.activeMenu=this.element,this.mouseHandled=!1,this.element.uniqueId().attr({role:this.options.role,tabIndex:0}),this._addClass("ui-menu","ui-widget ui-widget-content"),this._on({"mousedown .ui-menu-item":function(t){t.preventDefault()},"click .ui-menu-item":function(e){var i=t(e.target),s=t(t.ui.safeActiveElement(this.document[0]));!this.mouseHandled&&i.not(".ui-state-disabled").length&&(this.select(e),e.isPropagationStopped()||(this.mouseHandled=!0),i.has(".ui-menu").length?this.expand(e):!this.element.is(":focus")&&s.closest(".ui-menu").length&&(this.element.trigger("focus",[!0]),this.active&&1===this.active.parents(".ui-menu").length&&clearTimeout(this.timer)))},"mouseenter .ui-menu-item":function(e){if(!this.previousFilter){var i=t(e.target).closest(".ui-menu-item"),s=t(e.currentTarget);i[0]===s[0]&&(this._removeClass(s.siblings().children(".ui-state-active"),null,"ui-state-active"),this.focus(e,s))}},mouseleave:"collapseAll","mouseleave .ui-menu":"collapseAll",focus:function(t,e){var i=this.active||this.element.find(this.options.items).eq(0);e||this.focus(t,i)},blur:function(e){this._delay(function(){var i=!t.contains(this.element[0],t.ui.safeActiveElement(this.document[0]));i&&this.collapseAll(e)})},keydown:"_keydown"}),this.refresh(),this._on(this.document,{click:function(t){this._closeOnDocumentClick(t)&&this.collapseAll(t),this.mouseHandled=!1}})},_destroy:function(){var e=this.element.find(".ui-menu-item").removeAttr("role aria-disabled"),i=e.children(".ui-menu-item-wrapper").removeUniqueId().removeAttr("tabIndex role aria-haspopup");this.element.removeAttr("aria-activedescendant").find(".ui-menu").addBack().removeAttr("role aria-labelledby aria-expanded aria-hidden aria-disabled tabIndex").removeUniqueId().show(),i.children().each(function(){var e=t(this);e.data("ui-menu-submenu-caret")&&e.remove()})},_keydown:function(e){var i,s,n,o,a=!0;switch(e.keyCode){case t.ui.keyCode.PAGE_UP:this.previousPage(e);break;case t.ui.keyCode.PAGE_DOWN:this.nextPage(e);break;case t.ui.keyCode.HOME:this._move("first","first",e);break;case t.ui.keyCode.END:this._move("last","last",e);break;case t.ui.keyCode.UP:this.previous(e);break;case t.ui.keyCode.DOWN:this.next(e);break;case t.ui.keyCode.LEFT:this.collapse(e);break;case t.ui.keyCode.RIGHT:this.active&&!this.active.is(".ui-state-disabled")&&this.expand(e);break;case t.ui.keyCode.ENTER:case t.ui.keyCode.SPACE:this._activate(e);break;case t.ui.keyCode.ESCAPE:this.collapse(e);break;default:a=!1,s=this.previousFilter||"",o=!1,n=e.keyCode>=96&&105>=e.keyCode?""+(e.keyCode-96):String.fromCharCode(e.keyCode),clearTimeout(this.filterTimer),n===s?o=!0:n=s+n,i=this._filterMenuItems(n),i=o&&-1!==i.index(this.active.next())?this.active.nextAll(".ui-menu-item"):i,i.length||(n=String.fromCharCode(e.keyCode),i=this._filterMenuItems(n)),i.length?(this.focus(e,i),this.previousFilter=n,this.filterTimer=this._delay(function(){delete this.previousFilter},1e3)):delete this.previousFilter}a&&e.preventDefault()},_activate:function(t){this.active&&!this.active.is(".ui-state-disabled")&&(this.active.children("[aria-haspopup='true']").length?this.expand(t):this.select(t))},refresh:function(){var e,i,s,n,o,a=this,r=this.options.icons.submenu,h=this.element.find(this.options.menus);this._toggleClass("ui-menu-icons",null,!!this.element.find(".ui-icon").length),s=h.filter(":not(.ui-menu)").hide().attr({role:this.options.role,"aria-hidden":"true","aria-expanded":"false"}).each(function(){var e=t(this),i=e.prev(),s=t("<span>").data("ui-menu-submenu-caret",!0);a._addClass(s,"ui-menu-icon","ui-icon "+r),i.attr("aria-haspopup","true").prepend(s),e.attr("aria-labelledby",i.attr("id"))}),this._addClass(s,"ui-menu","ui-widget ui-widget-content ui-front"),e=h.add(this.element),i=e.find(this.options.items),i.not(".ui-menu-item").each(function(){var e=t(this);a._isDivider(e)&&a._addClass(e,"ui-menu-divider","ui-widget-content")}),n=i.not(".ui-menu-item, .ui-menu-divider"),o=n.children().not(".ui-menu").uniqueId().attr({tabIndex:-1,role:this._itemRole()}),this._addClass(n,"ui-menu-item")._addClass(o,"ui-menu-item-wrapper"),i.filter(".ui-state-disabled").attr("aria-disabled","true"),this.active&&!t.contains(this.element[0],this.active[0])&&this.blur()},_itemRole:function(){return{menu:"menuitem",listbox:"option"}[this.options.role]},_setOption:function(t,e){if("icons"===t){var i=this.element.find(".ui-menu-icon");this._removeClass(i,null,this.options.icons.submenu)._addClass(i,null,e.submenu)}this._super(t,e)},_setOptionDisabled:function(t){this._super(t),this.element.attr("aria-disabled",t+""),this._toggleClass(null,"ui-state-disabled",!!t)},focus:function(t,e){var i,s,n;this.blur(t,t&&"focus"===t.type),this._scrollIntoView(e),this.active=e.first(),s=this.active.children(".ui-menu-item-wrapper"),this._addClass(s,null,"ui-state-active"),this.options.role&&this.element.attr("aria-activedescendant",s.attr("id")),n=this.active.parent().closest(".ui-menu-item").children(".ui-menu-item-wrapper"),this._addClass(n,null,"ui-state-active"),t&&"keydown"===t.type?this._close():this.timer=this._delay(function(){this._close()},this.delay),i=e.children(".ui-menu"),i.length&&t&&/^mouse/.test(t.type)&&this._startOpening(i),this.activeMenu=e.parent(),this._trigger("focus",t,{item:e})},_scrollIntoView:function(e){var i,s,n,o,a,r;this._hasScroll()&&(i=parseFloat(t.css(this.activeMenu[0],"borderTopWidth"))||0,s=parseFloat(t.css(this.activeMenu[0],"paddingTop"))||0,n=e.offset().top-this.activeMenu.offset().top-i-s,o=this.activeMenu.scrollTop(),a=this.activeMenu.height(),r=e.outerHeight(),0>n?this.activeMenu.scrollTop(o+n):n+r>a&&this.activeMenu.scrollTop(o+n-a+r))},blur:function(t,e){e||clearTimeout(this.timer),this.active&&(this._removeClass(this.active.children(".ui-menu-item-wrapper"),null,"ui-state-active"),this._trigger("blur",t,{item:this.active}),this.active=null)},_startOpening:function(t){clearTimeout(this.timer),"true"===t.attr("aria-hidden")&&(this.timer=this._delay(function(){this._close(),this._open(t)},this.delay))},_open:function(e){var i=t.extend({of:this.active},this.options.position);clearTimeout(this.timer),this.element.find(".ui-menu").not(e.parents(".ui-menu")).hide().attr("aria-hidden","true"),e.show().removeAttr("aria-hidden").attr("aria-expanded","true").position(i)},collapseAll:function(e,i){clearTimeout(this.timer),this.timer=this._delay(function(){var s=i?this.element:t(e&&e.target).closest(this.element.find(".ui-menu"));s.length||(s=this.element),this._close(s),this.blur(e),this._removeClass(s.find(".ui-state-active"),null,"ui-state-active"),this.activeMenu=s},this.delay)},_close:function(t){t||(t=this.active?this.active.parent():this.element),t.find(".ui-menu").hide().attr("aria-hidden","true").attr("aria-expanded","false")},_closeOnDocumentClick:function(e){return!t(e.target).closest(".ui-menu").length},_isDivider:function(t){return!/[^\-\u2014\u2013\s]/.test(t.text())},collapse:function(t){var e=this.active&&this.active.parent().closest(".ui-menu-item",this.element);e&&e.length&&(this._close(),this.focus(t,e))},expand:function(t){var e=this.active&&this.active.children(".ui-menu ").find(this.options.items).first();e&&e.length&&(this._open(e.parent()),this._delay(function(){this.focus(t,e)}))},next:function(t){this._move("next","first",t)},previous:function(t){this._move("prev","last",t)},isFirstItem:function(){return this.active&&!this.active.prevAll(".ui-menu-item").length},isLastItem:function(){return this.active&&!this.active.nextAll(".ui-menu-item").length},_move:function(t,e,i){var s;this.active&&(s="first"===t||"last"===t?this.active["first"===t?"prevAll":"nextAll"](".ui-menu-item").eq(-1):this.active[t+"All"](".ui-menu-item").eq(0)),s&&s.length&&this.active||(s=this.activeMenu.find(this.options.items)[e]()),this.focus(i,s)},nextPage:function(e){var i,s,n;return this.active?(this.isLastItem()||(this._hasScroll()?(s=this.active.offset().top,n=this.element.height(),this.active.nextAll(".ui-menu-item").each(function(){return i=t(this),0>i.offset().top-s-n}),this.focus(e,i)):this.focus(e,this.activeMenu.find(this.options.items)[this.active?"last":"first"]())),void 0):(this.next(e),void 0)},previousPage:function(e){var i,s,n;return this.active?(this.isFirstItem()||(this._hasScroll()?(s=this.active.offset().top,n=this.element.height(),this.active.prevAll(".ui-menu-item").each(function(){return i=t(this),i.offset().top-s+n>0}),this.focus(e,i)):this.focus(e,this.activeMenu.find(this.options.items).first())),void 0):(this.next(e),void 0)},_hasScroll:function(){return this.element.outerHeight()<this.element.prop("scrollHeight")},select:function(e){this.active=this.active||t(e.target).closest(".ui-menu-item");var i={item:this.active};this.active.has(".ui-menu").length||this.collapseAll(e,!0),this._trigger("select",e,i)},_filterMenuItems:function(e){var i=e.replace(/[\-\[\]{}()*+?.,\\\^$|#\s]/g,"\\$&"),s=RegExp("^"+i,"i");return this.activeMenu.find(this.options.items).filter(".ui-menu-item").filter(function(){return s.test(t.trim(t(this).children(".ui-menu-item-wrapper").text()))})}}),t.widget("ui.autocomplete",{version:"1.12.1",defaultElement:"<input>",options:{appendTo:null,autoFocus:!1,delay:300,minLength:1,position:{my:"left top",at:"left bottom",collision:"none"},source:null,change:null,close:null,focus:null,open:null,response:null,search:null,select:null},requestIndex:0,pending:0,_create:function(){var e,i,s,n=this.element[0].nodeName.toLowerCase(),o="textarea"===n,a="input"===n;
-this.isMultiLine=o||!a&&this._isContentEditable(this.element),this.valueMethod=this.element[o||a?"val":"text"],this.isNewMenu=!0,this._addClass("ui-autocomplete-input"),this.element.attr("autocomplete","off"),this._on(this.element,{keydown:function(n){if(this.element.prop("readOnly"))return e=!0,s=!0,i=!0,void 0;e=!1,s=!1,i=!1;var o=t.ui.keyCode;switch(n.keyCode){case o.PAGE_UP:e=!0,this._move("previousPage",n);break;case o.PAGE_DOWN:e=!0,this._move("nextPage",n);break;case o.UP:e=!0,this._keyEvent("previous",n);break;case o.DOWN:e=!0,this._keyEvent("next",n);break;case o.ENTER:this.menu.active&&(e=!0,n.preventDefault(),this.menu.select(n));break;case o.TAB:this.menu.active&&this.menu.select(n);break;case o.ESCAPE:this.menu.element.is(":visible")&&(this.isMultiLine||this._value(this.term),this.close(n),n.preventDefault());break;default:i=!0,this._searchTimeout(n)}},keypress:function(s){if(e)return e=!1,(!this.isMultiLine||this.menu.element.is(":visible"))&&s.preventDefault(),void 0;if(!i){var n=t.ui.keyCode;switch(s.keyCode){case n.PAGE_UP:this._move("previousPage",s);break;case n.PAGE_DOWN:this._move("nextPage",s);break;case n.UP:this._keyEvent("previous",s);break;case n.DOWN:this._keyEvent("next",s)}}},input:function(t){return s?(s=!1,t.preventDefault(),void 0):(this._searchTimeout(t),void 0)},focus:function(){this.selectedItem=null,this.previous=this._value()},blur:function(t){return this.cancelBlur?(delete this.cancelBlur,void 0):(clearTimeout(this.searching),this.close(t),this._change(t),void 0)}}),this._initSource(),this.menu=t("<ul>").appendTo(this._appendTo()).menu({role:null}).hide().menu("instance"),this._addClass(this.menu.element,"ui-autocomplete","ui-front"),this._on(this.menu.element,{mousedown:function(e){e.preventDefault(),this.cancelBlur=!0,this._delay(function(){delete this.cancelBlur,this.element[0]!==t.ui.safeActiveElement(this.document[0])&&this.element.trigger("focus")})},menufocus:function(e,i){var s,n;return this.isNewMenu&&(this.isNewMenu=!1,e.originalEvent&&/^mouse/.test(e.originalEvent.type))?(this.menu.blur(),this.document.one("mousemove",function(){t(e.target).trigger(e.originalEvent)}),void 0):(n=i.item.data("ui-autocomplete-item"),!1!==this._trigger("focus",e,{item:n})&&e.originalEvent&&/^key/.test(e.originalEvent.type)&&this._value(n.value),s=i.item.attr("aria-label")||n.value,s&&t.trim(s).length&&(this.liveRegion.children().hide(),t("<div>").text(s).appendTo(this.liveRegion)),void 0)},menuselect:function(e,i){var s=i.item.data("ui-autocomplete-item"),n=this.previous;this.element[0]!==t.ui.safeActiveElement(this.document[0])&&(this.element.trigger("focus"),this.previous=n,this._delay(function(){this.previous=n,this.selectedItem=s})),!1!==this._trigger("select",e,{item:s})&&this._value(s.value),this.term=this._value(),this.close(e),this.selectedItem=s}}),this.liveRegion=t("<div>",{role:"status","aria-live":"assertive","aria-relevant":"additions"}).appendTo(this.document[0].body),this._addClass(this.liveRegion,null,"ui-helper-hidden-accessible"),this._on(this.window,{beforeunload:function(){this.element.removeAttr("autocomplete")}})},_destroy:function(){clearTimeout(this.searching),this.element.removeAttr("autocomplete"),this.menu.element.remove(),this.liveRegion.remove()},_setOption:function(t,e){this._super(t,e),"source"===t&&this._initSource(),"appendTo"===t&&this.menu.element.appendTo(this._appendTo()),"disabled"===t&&e&&this.xhr&&this.xhr.abort()},_isEventTargetInWidget:function(e){var i=this.menu.element[0];return e.target===this.element[0]||e.target===i||t.contains(i,e.target)},_closeOnClickOutside:function(t){this._isEventTargetInWidget(t)||this.close()},_appendTo:function(){var e=this.options.appendTo;return e&&(e=e.jquery||e.nodeType?t(e):this.document.find(e).eq(0)),e&&e[0]||(e=this.element.closest(".ui-front, dialog")),e.length||(e=this.document[0].body),e},_initSource:function(){var e,i,s=this;t.isArray(this.options.source)?(e=this.options.source,this.source=function(i,s){s(t.ui.autocomplete.filter(e,i.term))}):"string"==typeof this.options.source?(i=this.options.source,this.source=function(e,n){s.xhr&&s.xhr.abort(),s.xhr=t.ajax({url:i,data:e,dataType:"json",success:function(t){n(t)},error:function(){n([])}})}):this.source=this.options.source},_searchTimeout:function(t){clearTimeout(this.searching),this.searching=this._delay(function(){var e=this.term===this._value(),i=this.menu.element.is(":visible"),s=t.altKey||t.ctrlKey||t.metaKey||t.shiftKey;(!e||e&&!i&&!s)&&(this.selectedItem=null,this.search(null,t))},this.options.delay)},search:function(t,e){return t=null!=t?t:this._value(),this.term=this._value(),t.length<this.options.minLength?this.close(e):this._trigger("search",e)!==!1?this._search(t):void 0},_search:function(t){this.pending++,this._addClass("ui-autocomplete-loading"),this.cancelSearch=!1,this.source({term:t},this._response())},_response:function(){var e=++this.requestIndex;return t.proxy(function(t){e===this.requestIndex&&this.__response(t),this.pending--,this.pending||this._removeClass("ui-autocomplete-loading")},this)},__response:function(t){t&&(t=this._normalize(t)),this._trigger("response",null,{content:t}),!this.options.disabled&&t&&t.length&&!this.cancelSearch?(this._suggest(t),this._trigger("open")):this._close()},close:function(t){this.cancelSearch=!0,this._close(t)},_close:function(t){this._off(this.document,"mousedown"),this.menu.element.is(":visible")&&(this.menu.element.hide(),this.menu.blur(),this.isNewMenu=!0,this._trigger("close",t))},_change:function(t){this.previous!==this._value()&&this._trigger("change",t,{item:this.selectedItem})},_normalize:function(e){return e.length&&e[0].label&&e[0].value?e:t.map(e,function(e){return"string"==typeof e?{label:e,value:e}:t.extend({},e,{label:e.label||e.value,value:e.value||e.label})})},_suggest:function(e){var i=this.menu.element.empty();this._renderMenu(i,e),this.isNewMenu=!0,this.menu.refresh(),i.show(),this._resizeMenu(),i.position(t.extend({of:this.element},this.options.position)),this.options.autoFocus&&this.menu.next(),this._on(this.document,{mousedown:"_closeOnClickOutside"})},_resizeMenu:function(){var t=this.menu.element;t.outerWidth(Math.max(t.width("").outerWidth()+1,this.element.outerWidth()))},_renderMenu:function(e,i){var s=this;t.each(i,function(t,i){s._renderItemData(e,i)})},_renderItemData:function(t,e){return this._renderItem(t,e).data("ui-autocomplete-item",e)},_renderItem:function(e,i){return t("<li>").append(t("<div>").text(i.label)).appendTo(e)},_move:function(t,e){return this.menu.element.is(":visible")?this.menu.isFirstItem()&&/^previous/.test(t)||this.menu.isLastItem()&&/^next/.test(t)?(this.isMultiLine||this._value(this.term),this.menu.blur(),void 0):(this.menu[t](e),void 0):(this.search(null,e),void 0)},widget:function(){return this.menu.element},_value:function(){return this.valueMethod.apply(this.element,arguments)},_keyEvent:function(t,e){(!this.isMultiLine||this.menu.element.is(":visible"))&&(this._move(t,e),e.preventDefault())},_isContentEditable:function(t){if(!t.length)return!1;var e=t.prop("contentEditable");return"inherit"===e?this._isContentEditable(t.parent()):"true"===e}}),t.extend(t.ui.autocomplete,{escapeRegex:function(t){return t.replace(/[\-\[\]{}()*+?.,\\\^$|#\s]/g,"\\$&")},filter:function(e,i){var s=RegExp(t.ui.autocomplete.escapeRegex(i),"i");return t.grep(e,function(t){return s.test(t.label||t.value||t)})}}),t.widget("ui.autocomplete",t.ui.autocomplete,{options:{messages:{noResults:"No search results.",results:function(t){return t+(t>1?" results are":" result is")+" available, use up and down arrow keys to navigate."}}},__response:function(e){var i;this._superApply(arguments),this.options.disabled||this.cancelSearch||(i=e&&e.length?this.options.messages.results(e.length):this.options.messages.noResults,this.liveRegion.children().hide(),t("<div>").text(i).appendTo(this.liveRegion))}}),t.ui.autocomplete;var g=/ui-corner-([a-z]){2,6}/g;t.widget("ui.controlgroup",{version:"1.12.1",defaultElement:"<div>",options:{direction:"horizontal",disabled:null,onlyVisible:!0,items:{button:"input[type=button], input[type=submit], input[type=reset], button, a",controlgroupLabel:".ui-controlgroup-label",checkboxradio:"input[type='checkbox'], input[type='radio']",selectmenu:"select",spinner:".ui-spinner-input"}},_create:function(){this._enhance()},_enhance:function(){this.element.attr("role","toolbar"),this.refresh()},_destroy:function(){this._callChildMethod("destroy"),this.childWidgets.removeData("ui-controlgroup-data"),this.element.removeAttr("role"),this.options.items.controlgroupLabel&&this.element.find(this.options.items.controlgroupLabel).find(".ui-controlgroup-label-contents").contents().unwrap()},_initWidgets:function(){var e=this,i=[];t.each(this.options.items,function(s,n){var o,a={};return n?"controlgroupLabel"===s?(o=e.element.find(n),o.each(function(){var e=t(this);e.children(".ui-controlgroup-label-contents").length||e.contents().wrapAll("<span class='ui-controlgroup-label-contents'></span>")}),e._addClass(o,null,"ui-widget ui-widget-content ui-state-default"),i=i.concat(o.get()),void 0):(t.fn[s]&&(a=e["_"+s+"Options"]?e["_"+s+"Options"]("middle"):{classes:{}},e.element.find(n).each(function(){var n=t(this),o=n[s]("instance"),r=t.widget.extend({},a);if("button"!==s||!n.parent(".ui-spinner").length){o||(o=n[s]()[s]("instance")),o&&(r.classes=e._resolveClassesValues(r.classes,o)),n[s](r);var h=n[s]("widget");t.data(h[0],"ui-controlgroup-data",o?o:n[s]("instance")),i.push(h[0])}})),void 0):void 0}),this.childWidgets=t(t.unique(i)),this._addClass(this.childWidgets,"ui-controlgroup-item")},_callChildMethod:function(e){this.childWidgets.each(function(){var i=t(this),s=i.data("ui-controlgroup-data");s&&s[e]&&s[e]()})},_updateCornerClass:function(t,e){var i="ui-corner-top ui-corner-bottom ui-corner-left ui-corner-right ui-corner-all",s=this._buildSimpleOptions(e,"label").classes.label;this._removeClass(t,null,i),this._addClass(t,null,s)},_buildSimpleOptions:function(t,e){var i="vertical"===this.options.direction,s={classes:{}};return s.classes[e]={middle:"",first:"ui-corner-"+(i?"top":"left"),last:"ui-corner-"+(i?"bottom":"right"),only:"ui-corner-all"}[t],s},_spinnerOptions:function(t){var e=this._buildSimpleOptions(t,"ui-spinner");return e.classes["ui-spinner-up"]="",e.classes["ui-spinner-down"]="",e},_buttonOptions:function(t){return this._buildSimpleOptions(t,"ui-button")},_checkboxradioOptions:function(t){return this._buildSimpleOptions(t,"ui-checkboxradio-label")},_selectmenuOptions:function(t){var e="vertical"===this.options.direction;return{width:e?"auto":!1,classes:{middle:{"ui-selectmenu-button-open":"","ui-selectmenu-button-closed":""},first:{"ui-selectmenu-button-open":"ui-corner-"+(e?"top":"tl"),"ui-selectmenu-button-closed":"ui-corner-"+(e?"top":"left")},last:{"ui-selectmenu-button-open":e?"":"ui-corner-tr","ui-selectmenu-button-closed":"ui-corner-"+(e?"bottom":"right")},only:{"ui-selectmenu-button-open":"ui-corner-top","ui-selectmenu-button-closed":"ui-corner-all"}}[t]}},_resolveClassesValues:function(e,i){var s={};return t.each(e,function(n){var o=i.options.classes[n]||"";o=t.trim(o.replace(g,"")),s[n]=(o+" "+e[n]).replace(/\s+/g," ")}),s},_setOption:function(t,e){return"direction"===t&&this._removeClass("ui-controlgroup-"+this.options.direction),this._super(t,e),"disabled"===t?(this._callChildMethod(e?"disable":"enable"),void 0):(this.refresh(),void 0)},refresh:function(){var e,i=this;this._addClass("ui-controlgroup ui-controlgroup-"+this.options.direction),"horizontal"===this.options.direction&&this._addClass(null,"ui-helper-clearfix"),this._initWidgets(),e=this.childWidgets,this.options.onlyVisible&&(e=e.filter(":visible")),e.length&&(t.each(["first","last"],function(t,s){var n=e[s]().data("ui-controlgroup-data");if(n&&i["_"+n.widgetName+"Options"]){var o=i["_"+n.widgetName+"Options"](1===e.length?"only":s);o.classes=i._resolveClassesValues(o.classes,n),n.element[n.widgetName](o)}else i._updateCornerClass(e[s](),s)}),this._callChildMethod("refresh"))}}),t.widget("ui.checkboxradio",[t.ui.formResetMixin,{version:"1.12.1",options:{disabled:null,label:null,icon:!0,classes:{"ui-checkboxradio-label":"ui-corner-all","ui-checkboxradio-icon":"ui-corner-all"}},_getCreateOptions:function(){var e,i,s=this,n=this._super()||{};return this._readType(),i=this.element.labels(),this.label=t(i[i.length-1]),this.label.length||t.error("No label found for checkboxradio widget"),this.originalLabel="",this.label.contents().not(this.element[0]).each(function(){s.originalLabel+=3===this.nodeType?t(this).text():this.outerHTML}),this.originalLabel&&(n.label=this.originalLabel),e=this.element[0].disabled,null!=e&&(n.disabled=e),n},_create:function(){var t=this.element[0].checked;this._bindFormResetHandler(),null==this.options.disabled&&(this.options.disabled=this.element[0].disabled),this._setOption("disabled",this.options.disabled),this._addClass("ui-checkboxradio","ui-helper-hidden-accessible"),this._addClass(this.label,"ui-checkboxradio-label","ui-button ui-widget"),"radio"===this.type&&this._addClass(this.label,"ui-checkboxradio-radio-label"),this.options.label&&this.options.label!==this.originalLabel?this._updateLabel():this.originalLabel&&(this.options.label=this.originalLabel),this._enhance(),t&&(this._addClass(this.label,"ui-checkboxradio-checked","ui-state-active"),this.icon&&this._addClass(this.icon,null,"ui-state-hover")),this._on({change:"_toggleClasses",focus:function(){this._addClass(this.label,null,"ui-state-focus ui-visual-focus")},blur:function(){this._removeClass(this.label,null,"ui-state-focus ui-visual-focus")}})},_readType:function(){var e=this.element[0].nodeName.toLowerCase();this.type=this.element[0].type,"input"===e&&/radio|checkbox/.test(this.type)||t.error("Can't create checkboxradio on element.nodeName="+e+" and element.type="+this.type)},_enhance:function(){this._updateIcon(this.element[0].checked)},widget:function(){return this.label},_getRadioGroup:function(){var e,i=this.element[0].name,s="input[name='"+t.ui.escapeSelector(i)+"']";return i?(e=this.form.length?t(this.form[0].elements).filter(s):t(s).filter(function(){return 0===t(this).form().length}),e.not(this.element)):t([])},_toggleClasses:function(){var e=this.element[0].checked;this._toggleClass(this.label,"ui-checkboxradio-checked","ui-state-active",e),this.options.icon&&"checkbox"===this.type&&this._toggleClass(this.icon,null,"ui-icon-check ui-state-checked",e)._toggleClass(this.icon,null,"ui-icon-blank",!e),"radio"===this.type&&this._getRadioGroup().each(function(){var e=t(this).checkboxradio("instance");e&&e._removeClass(e.label,"ui-checkboxradio-checked","ui-state-active")})},_destroy:function(){this._unbindFormResetHandler(),this.icon&&(this.icon.remove(),this.iconSpace.remove())},_setOption:function(t,e){return"label"!==t||e?(this._super(t,e),"disabled"===t?(this._toggleClass(this.label,null,"ui-state-disabled",e),this.element[0].disabled=e,void 0):(this.refresh(),void 0)):void 0},_updateIcon:function(e){var i="ui-icon ui-icon-background ";this.options.icon?(this.icon||(this.icon=t("<span>"),this.iconSpace=t("<span> </span>"),this._addClass(this.iconSpace,"ui-checkboxradio-icon-space")),"checkbox"===this.type?(i+=e?"ui-icon-check ui-state-checked":"ui-icon-blank",this._removeClass(this.icon,null,e?"ui-icon-blank":"ui-icon-check")):i+="ui-icon-blank",this._addClass(this.icon,"ui-checkboxradio-icon",i),e||this._removeClass(this.icon,null,"ui-icon-check ui-state-checked"),this.icon.prependTo(this.label).after(this.iconSpace)):void 0!==this.icon&&(this.icon.remove(),this.iconSpace.remove(),delete this.icon)},_updateLabel:function(){var t=this.label.contents().not(this.element[0]);this.icon&&(t=t.not(this.icon[0])),this.iconSpace&&(t=t.not(this.iconSpace[0])),t.remove(),this.label.append(this.options.label)},refresh:function(){var t=this.element[0].checked,e=this.element[0].disabled;this._updateIcon(t),this._toggleClass(this.label,"ui-checkboxradio-checked","ui-state-active",t),null!==this.options.label&&this._updateLabel(),e!==this.options.disabled&&this._setOptions({disabled:e})}}]),t.ui.checkboxradio,t.widget("ui.button",{version:"1.12.1",defaultElement:"<button>",options:{classes:{"ui-button":"ui-corner-all"},disabled:null,icon:null,iconPosition:"beginning",label:null,showLabel:!0},_getCreateOptions:function(){var t,e=this._super()||{};return this.isInput=this.element.is("input"),t=this.element[0].disabled,null!=t&&(e.disabled=t),this.originalLabel=this.isInput?this.element.val():this.element.html(),this.originalLabel&&(e.label=this.originalLabel),e},_create:function(){!this.option.showLabel&!this.options.icon&&(this.options.showLabel=!0),null==this.options.disabled&&(this.options.disabled=this.element[0].disabled||!1),this.hasTitle=!!this.element.attr("title"),this.options.label&&this.options.label!==this.originalLabel&&(this.isInput?this.element.val(this.options.label):this.element.html(this.options.label)),this._addClass("ui-button","ui-widget"),this._setOption("disabled",this.options.disabled),this._enhance(),this.element.is("a")&&this._on({keyup:function(e){e.keyCode===t.ui.keyCode.SPACE&&(e.preventDefault(),this.element[0].click?this.element[0].click():this.element.trigger("click"))}})},_enhance:function(){this.element.is("button")||this.element.attr("role","button"),this.options.icon&&(this._updateIcon("icon",this.options.icon),this._updateTooltip())},_updateTooltip:function(){this.title=this.element.attr("title"),this.options.showLabel||this.title||this.element.attr("title",this.options.label)},_updateIcon:function(e,i){var s="iconPosition"!==e,n=s?this.options.iconPosition:i,o="top"===n||"bottom"===n;this.icon?s&&this._removeClass(this.icon,null,this.options.icon):(this.icon=t("<span>"),this._addClass(this.icon,"ui-button-icon","ui-icon"),this.options.showLabel||this._addClass("ui-button-icon-only")),s&&this._addClass(this.icon,null,i),this._attachIcon(n),o?(this._addClass(this.icon,null,"ui-widget-icon-block"),this.iconSpace&&this.iconSpace.remove()):(this.iconSpace||(this.iconSpace=t("<span> </span>"),this._addClass(this.iconSpace,"ui-button-icon-space")),this._removeClass(this.icon,null,"ui-wiget-icon-block"),this._attachIconSpace(n))},_destroy:function(){this.element.removeAttr("role"),this.icon&&this.icon.remove(),this.iconSpace&&this.iconSpace.remove(),this.hasTitle||this.element.removeAttr("title")},_attachIconSpace:function(t){this.icon[/^(?:end|bottom)/.test(t)?"before":"after"](this.iconSpace)},_attachIcon:function(t){this.element[/^(?:end|bottom)/.test(t)?"append":"prepend"](this.icon)},_setOptions:function(t){var e=void 0===t.showLabel?this.options.showLabel:t.showLabel,i=void 0===t.icon?this.options.icon:t.icon;e||i||(t.showLabel=!0),this._super(t)},_setOption:function(t,e){"icon"===t&&(e?this._updateIcon(t,e):this.icon&&(this.icon.remove(),this.iconSpace&&this.iconSpace.remove())),"iconPosition"===t&&this._updateIcon(t,e),"showLabel"===t&&(this._toggleClass("ui-button-icon-only",null,!e),this._updateTooltip()),"label"===t&&(this.isInput?this.element.val(e):(this.element.html(e),this.icon&&(this._attachIcon(this.options.iconPosition),this._attachIconSpace(this.options.iconPosition)))),this._super(t,e),"disabled"===t&&(this._toggleClass(null,"ui-state-disabled",e),this.element[0].disabled=e,e&&this.element.blur())},refresh:function(){var t=this.element.is("input, button")?this.element[0].disabled:this.element.hasClass("ui-button-disabled");t!==this.options.disabled&&this._setOptions({disabled:t}),this._updateTooltip()}}),t.uiBackCompat!==!1&&(t.widget("ui.button",t.ui.button,{options:{text:!0,icons:{primary:null,secondary:null}},_create:function(){this.options.showLabel&&!this.options.text&&(this.options.showLabel=this.options.text),!this.options.showLabel&&this.options.text&&(this.options.text=this.options.showLabel),this.options.icon||!this.options.icons.primary&&!this.options.icons.secondary?this.options.icon&&(this.options.icons.primary=this.options.icon):this.options.icons.primary?this.options.icon=this.options.icons.primary:(this.options.icon=this.options.icons.secondary,this.options.iconPosition="end"),this._super()},_setOption:function(t,e){return"text"===t?(this._super("showLabel",e),void 0):("showLabel"===t&&(this.options.text=e),"icon"===t&&(this.options.icons.primary=e),"icons"===t&&(e.primary?(this._super("icon",e.primary),this._super("iconPosition","beginning")):e.secondary&&(this._super("icon",e.secondary),this._super("iconPosition","end"))),this._superApply(arguments),void 0)}}),t.fn.button=function(e){return function(){return!this.length||this.length&&"INPUT"!==this[0].tagName||this.length&&"INPUT"===this[0].tagName&&"checkbox"!==this.attr("type")&&"radio"!==this.attr("type")?e.apply(this,arguments):(t.ui.checkboxradio||t.error("Checkboxradio widget missing"),0===arguments.length?this.checkboxradio({icon:!1}):this.checkboxradio.apply(this,arguments))}}(t.fn.button),t.fn.buttonset=function(){return t.ui.controlgroup||t.error("Controlgroup widget missing"),"option"===arguments[0]&&"items"===arguments[1]&&arguments[2]?this.controlgroup.apply(this,[arguments[0],"items.button",arguments[2]]):"option"===arguments[0]&&"items"===arguments[1]?this.controlgroup.apply(this,[arguments[0],"items.button"]):("object"==typeof arguments[0]&&arguments[0].items&&(arguments[0].items={button:arguments[0].items}),this.controlgroup.apply(this,arguments))}),t.ui.button,t.extend(t.ui,{datepicker:{version:"1.12.1"}});var m;t.extend(s.prototype,{markerClassName:"hasDatepicker",maxRows:4,_widgetDatepicker:function(){return this.dpDiv},setDefaults:function(t){return a(this._defaults,t||{}),this},_attachDatepicker:function(e,i){var s,n,o;s=e.nodeName.toLowerCase(),n="div"===s||"span"===s,e.id||(this.uuid+=1,e.id="dp"+this.uuid),o=this._newInst(t(e),n),o.settings=t.extend({},i||{}),"input"===s?this._connectDatepicker(e,o):n&&this._inlineDatepicker(e,o)},_newInst:function(e,i){var s=e[0].id.replace(/([^A-Za-z0-9_\-])/g,"\\\\$1");return{id:s,input:e,selectedDay:0,selectedMonth:0,selectedYear:0,drawMonth:0,drawYear:0,inline:i,dpDiv:i?n(t("<div class='"+this._inlineClass+" ui-datepicker ui-widget ui-widget-content ui-helper-clearfix ui-corner-all'></div>")):this.dpDiv}},_connectDatepicker:function(e,i){var s=t(e);i.append=t([]),i.trigger=t([]),s.hasClass(this.markerClassName)||(this._attachments(s,i),s.addClass(this.markerClassName).on("keydown",this._doKeyDown).on("keypress",this._doKeyPress).on("keyup",this._doKeyUp),this._autoSize(i),t.data(e,"datepicker",i),i.settings.disabled&&this._disableDatepicker(e))},_attachments:function(e,i){var s,n,o,a=this._get(i,"appendText"),r=this._get(i,"isRTL");i.append&&i.append.remove(),a&&(i.append=t("<span class='"+this._appendClass+"'>"+a+"</span>"),e[r?"before":"after"](i.append)),e.off("focus",this._showDatepicker),i.trigger&&i.trigger.remove(),s=this._get(i,"showOn"),("focus"===s||"both"===s)&&e.on("focus",this._showDatepicker),("button"===s||"both"===s)&&(n=this._get(i,"buttonText"),o=this._get(i,"buttonImage"),i.trigger=t(this._get(i,"buttonImageOnly")?t("<img/>").addClass(this._triggerClass).attr({src:o,alt:n,title:n}):t("<button type='button'></button>").addClass(this._triggerClass).html(o?t("<img/>").attr({src:o,alt:n,title:n}):n)),e[r?"before":"after"](i.trigger),i.trigger.on("click",function(){return t.datepicker._datepickerShowing&&t.datepicker._lastInput===e[0]?t.datepicker._hideDatepicker():t.datepicker._datepickerShowing&&t.datepicker._lastInput!==e[0]?(t.datepicker._hideDatepicker(),t.datepicker._showDatepicker(e[0])):t.datepicker._showDatepicker(e[0]),!1}))},_autoSize:function(t){if(this._get(t,"autoSize")&&!t.inline){var e,i,s,n,o=new Date(2009,11,20),a=this._get(t,"dateFormat");a.match(/[DM]/)&&(e=function(t){for(i=0,s=0,n=0;t.length>n;n++)t[n].length>i&&(i=t[n].length,s=n);return s},o.setMonth(e(this._get(t,a.match(/MM/)?"monthNames":"monthNamesShort"))),o.setDate(e(this._get(t,a.match(/DD/)?"dayNames":"dayNamesShort"))+20-o.getDay())),t.input.attr("size",this._formatDate(t,o).length)}},_inlineDatepicker:function(e,i){var s=t(e);s.hasClass(this.markerClassName)||(s.addClass(this.markerClassName).append(i.dpDiv),t.data(e,"datepicker",i),this._setDate(i,this._getDefaultDate(i),!0),this._updateDatepicker(i),this._updateAlternate(i),i.settings.disabled&&this._disableDatepicker(e),i.dpDiv.css("display","block"))},_dialogDatepicker:function(e,i,s,n,o){var r,h,l,c,u,d=this._dialogInst;return d||(this.uuid+=1,r="dp"+this.uuid,this._dialogInput=t("<input type='text' id='"+r+"' style='position: absolute; top: -100px; width: 0px;'/>"),this._dialogInput.on("keydown",this._doKeyDown),t("body").append(this._dialogInput),d=this._dialogInst=this._newInst(this._dialogInput,!1),d.settings={},t.data(this._dialogInput[0],"datepicker",d)),a(d.settings,n||{}),i=i&&i.constructor===Date?this._formatDate(d,i):i,this._dialogInput.val(i),this._pos=o?o.length?o:[o.pageX,o.pageY]:null,this._pos||(h=document.documentElement.clientWidth,l=document.documentElement.clientHeight,c=document.documentElement.scrollLeft||document.body.scrollLeft,u=document.documentElement.scrollTop||document.body.scrollTop,this._pos=[h/2-100+c,l/2-150+u]),this._dialogInput.css("left",this._pos[0]+20+"px").css("top",this._pos[1]+"px"),d.settings.onSelect=s,this._inDialog=!0,this.dpDiv.addClass(this._dialogClass),this._showDatepicker(this._dialogInput[0]),t.blockUI&&t.blockUI(this.dpDiv),t.data(this._dialogInput[0],"datepicker",d),this},_destroyDatepicker:function(e){var i,s=t(e),n=t.data(e,"datepicker");s.hasClass(this.markerClassName)&&(i=e.nodeName.toLowerCase(),t.removeData(e,"datepicker"),"input"===i?(n.append.remove(),n.trigger.remove(),s.removeClass(this.markerClassName).off("focus",this._showDatepicker).off("keydown",this._doKeyDown).off("keypress",this._doKeyPress).off("keyup",this._doKeyUp)):("div"===i||"span"===i)&&s.removeClass(this.markerClassName).empty(),m===n&&(m=null))},_enableDatepicker:function(e){var i,s,n=t(e),o=t.data(e,"datepicker");n.hasClass(this.markerClassName)&&(i=e.nodeName.toLowerCase(),"input"===i?(e.disabled=!1,o.trigger.filter("button").each(function(){this.disabled=!1}).end().filter("img").css({opacity:"1.0",cursor:""})):("div"===i||"span"===i)&&(s=n.children("."+this._inlineClass),s.children().removeClass("ui-state-disabled"),s.find("select.ui-datepicker-month, select.ui-datepicker-year").prop("disabled",!1)),this._disabledInputs=t.map(this._disabledInputs,function(t){return t===e?null:t}))},_disableDatepicker:function(e){var i,s,n=t(e),o=t.data(e,"datepicker");n.hasClass(this.markerClassName)&&(i=e.nodeName.toLowerCase(),"input"===i?(e.disabled=!0,o.trigger.filter("button").each(function(){this.disabled=!0}).end().filter("img").css({opacity:"0.5",cursor:"default"})):("div"===i||"span"===i)&&(s=n.children("."+this._inlineClass),s.children().addClass("ui-state-disabled"),s.find("select.ui-datepicker-month, select.ui-datepicker-year").prop("disabled",!0)),this._disabledInputs=t.map(this._disabledInputs,function(t){return t===e?null:t}),this._disabledInputs[this._disabledInputs.length]=e)},_isDisabledDatepicker:function(t){if(!t)return!1;for(var e=0;this._disabledInputs.length>e;e++)if(this._disabledInputs[e]===t)return!0;return!1},_getInst:function(e){try{return t.data(e,"datepicker")}catch(i){throw"Missing instance data for this datepicker"}},_optionDatepicker:function(e,i,s){var n,o,r,h,l=this._getInst(e);return 2===arguments.length&&"string"==typeof i?"defaults"===i?t.extend({},t.datepicker._defaults):l?"all"===i?t.extend({},l.settings):this._get(l,i):null:(n=i||{},"string"==typeof i&&(n={},n[i]=s),l&&(this._curInst===l&&this._hideDatepicker(),o=this._getDateDatepicker(e,!0),r=this._getMinMaxDate(l,"min"),h=this._getMinMaxDate(l,"max"),a(l.settings,n),null!==r&&void 0!==n.dateFormat&&void 0===n.minDate&&(l.settings.minDate=this._formatDate(l,r)),null!==h&&void 0!==n.dateFormat&&void 0===n.maxDate&&(l.settings.maxDate=this._formatDate(l,h)),"disabled"in n&&(n.disabled?this._disableDatepicker(e):this._enableDatepicker(e)),this._attachments(t(e),l),this._autoSize(l),this._setDate(l,o),this._updateAlternate(l),this._updateDatepicker(l)),void 0)},_changeDatepicker:function(t,e,i){this._optionDatepicker(t,e,i)},_refreshDatepicker:function(t){var e=this._getInst(t);e&&this._updateDatepicker(e)},_setDateDatepicker:function(t,e){var i=this._getInst(t);i&&(this._setDate(i,e),this._updateDatepicker(i),this._updateAlternate(i))},_getDateDatepicker:function(t,e){var i=this._getInst(t);return i&&!i.inline&&this._setDateFromField(i,e),i?this._getDate(i):null},_doKeyDown:function(e){var i,s,n,o=t.datepicker._getInst(e.target),a=!0,r=o.dpDiv.is(".ui-datepicker-rtl");if(o._keyEvent=!0,t.datepicker._datepickerShowing)switch(e.keyCode){case 9:t.datepicker._hideDatepicker(),a=!1;break;case 13:return n=t("td."+t.datepicker._dayOverClass+":not(."+t.datepicker._currentClass+")",o.dpDiv),n[0]&&t.datepicker._selectDay(e.target,o.selectedMonth,o.selectedYear,n[0]),i=t.datepicker._get(o,"onSelect"),i?(s=t.datepicker._formatDate(o),i.apply(o.input?o.input[0]:null,[s,o])):t.datepicker._hideDatepicker(),!1;case 27:t.datepicker._hideDatepicker();break;case 33:t.datepicker._adjustDate(e.target,e.ctrlKey?-t.datepicker._get(o,"stepBigMonths"):-t.datepicker._get(o,"stepMonths"),"M");break;case 34:t.datepicker._adjustDate(e.target,e.ctrlKey?+t.datepicker._get(o,"stepBigMonths"):+t.datepicker._get(o,"stepMonths"),"M");break;case 35:(e.ctrlKey||e.metaKey)&&t.datepicker._clearDate(e.target),a=e.ctrlKey||e.metaKey;break;case 36:(e.ctrlKey||e.metaKey)&&t.datepicker._gotoToday(e.target),a=e.ctrlKey||e.metaKey;break;case 37:(e.ctrlKey||e.metaKey)&&t.datepicker._adjustDate(e.target,r?1:-1,"D"),a=e.ctrlKey||e.metaKey,e.originalEvent.altKey&&t.datepicker._adjustDate(e.target,e.ctrlKey?-t.datepicker._get(o,"stepBigMonths"):-t.datepicker._get(o,"stepMonths"),"M");break;case 38:(e.ctrlKey||e.metaKey)&&t.datepicker._adjustDate(e.target,-7,"D"),a=e.ctrlKey||e.metaKey;break;case 39:(e.ctrlKey||e.metaKey)&&t.datepicker._adjustDate(e.target,r?-1:1,"D"),a=e.ctrlKey||e.metaKey,e.originalEvent.altKey&&t.datepicker._adjustDate(e.target,e.ctrlKey?+t.datepicker._get(o,"stepBigMonths"):+t.datepicker._get(o,"stepMonths"),"M");break;case 40:(e.ctrlKey||e.metaKey)&&t.datepicker._adjustDate(e.target,7,"D"),a=e.ctrlKey||e.metaKey;break;default:a=!1}else 36===e.keyCode&&e.ctrlKey?t.datepicker._showDatepicker(this):a=!1;a&&(e.preventDefault(),e.stopPropagation())},_doKeyPress:function(e){var i,s,n=t.datepicker._getInst(e.target);return t.datepicker._get(n,"constrainInput")?(i=t.datepicker._possibleChars(t.datepicker._get(n,"dateFormat")),s=String.fromCharCode(null==e.charCode?e.keyCode:e.charCode),e.ctrlKey||e.metaKey||" ">s||!i||i.indexOf(s)>-1):void 0},_doKeyUp:function(e){var i,s=t.datepicker._getInst(e.target);if(s.input.val()!==s.lastVal)try{i=t.datepicker.parseDate(t.datepicker._get(s,"dateFormat"),s.input?s.input.val():null,t.datepicker._getFormatConfig(s)),i&&(t.datepicker._setDateFromField(s),t.datepicker._updateAlternate(s),t.datepicker._updateDatepicker(s))}catch(n){}return!0},_showDatepicker:function(e){if(e=e.target||e,"input"!==e.nodeName.toLowerCase()&&(e=t("input",e.parentNode)[0]),!t.datepicker._isDisabledDatepicker(e)&&t.datepicker._lastInput!==e){var s,n,o,r,h,l,c;s=t.datepicker._getInst(e),t.datepicker._curInst&&t.datepicker._curInst!==s&&(t.datepicker._curInst.dpDiv.stop(!0,!0),s&&t.datepicker._datepickerShowing&&t.datepicker._hideDatepicker(t.datepicker._curInst.input[0])),n=t.datepicker._get(s,"beforeShow"),o=n?n.apply(e,[e,s]):{},o!==!1&&(a(s.settings,o),s.lastVal=null,t.datepicker._lastInput=e,t.datepicker._setDateFromField(s),t.datepicker._inDialog&&(e.value=""),t.datepicker._pos||(t.datepicker._pos=t.datepicker._findPos(e),t.datepicker._pos[1]+=e.offsetHeight),r=!1,t(e).parents().each(function(){return r|="fixed"===t(this).css("position"),!r}),h={left:t.datepicker._pos[0],top:t.datepicker._pos[1]},t.datepicker._pos=null,s.dpDiv.empty(),s.dpDiv.css({position:"absolute",display:"block",top:"-1000px"}),t.datepicker._updateDatepicker(s),h=t.datepicker._checkOffset(s,h,r),s.dpDiv.css({position:t.datepicker._inDialog&&t.blockUI?"static":r?"fixed":"absolute",display:"none",left:h.left+"px",top:h.top+"px"}),s.inline||(l=t.datepicker._get(s,"showAnim"),c=t.datepicker._get(s,"duration"),s.dpDiv.css("z-index",i(t(e))+1),t.datepicker._datepickerShowing=!0,t.effects&&t.effects.effect[l]?s.dpDiv.show(l,t.datepicker._get(s,"showOptions"),c):s.dpDiv[l||"show"](l?c:null),t.datepicker._shouldFocusInput(s)&&s.input.trigger("focus"),t.datepicker._curInst=s))
-}},_updateDatepicker:function(e){this.maxRows=4,m=e,e.dpDiv.empty().append(this._generateHTML(e)),this._attachHandlers(e);var i,s=this._getNumberOfMonths(e),n=s[1],a=17,r=e.dpDiv.find("."+this._dayOverClass+" a");r.length>0&&o.apply(r.get(0)),e.dpDiv.removeClass("ui-datepicker-multi-2 ui-datepicker-multi-3 ui-datepicker-multi-4").width(""),n>1&&e.dpDiv.addClass("ui-datepicker-multi-"+n).css("width",a*n+"em"),e.dpDiv[(1!==s[0]||1!==s[1]?"add":"remove")+"Class"]("ui-datepicker-multi"),e.dpDiv[(this._get(e,"isRTL")?"add":"remove")+"Class"]("ui-datepicker-rtl"),e===t.datepicker._curInst&&t.datepicker._datepickerShowing&&t.datepicker._shouldFocusInput(e)&&e.input.trigger("focus"),e.yearshtml&&(i=e.yearshtml,setTimeout(function(){i===e.yearshtml&&e.yearshtml&&e.dpDiv.find("select.ui-datepicker-year:first").replaceWith(e.yearshtml),i=e.yearshtml=null},0))},_shouldFocusInput:function(t){return t.input&&t.input.is(":visible")&&!t.input.is(":disabled")&&!t.input.is(":focus")},_checkOffset:function(e,i,s){var n=e.dpDiv.outerWidth(),o=e.dpDiv.outerHeight(),a=e.input?e.input.outerWidth():0,r=e.input?e.input.outerHeight():0,h=document.documentElement.clientWidth+(s?0:t(document).scrollLeft()),l=document.documentElement.clientHeight+(s?0:t(document).scrollTop());return i.left-=this._get(e,"isRTL")?n-a:0,i.left-=s&&i.left===e.input.offset().left?t(document).scrollLeft():0,i.top-=s&&i.top===e.input.offset().top+r?t(document).scrollTop():0,i.left-=Math.min(i.left,i.left+n>h&&h>n?Math.abs(i.left+n-h):0),i.top-=Math.min(i.top,i.top+o>l&&l>o?Math.abs(o+r):0),i},_findPos:function(e){for(var i,s=this._getInst(e),n=this._get(s,"isRTL");e&&("hidden"===e.type||1!==e.nodeType||t.expr.filters.hidden(e));)e=e[n?"previousSibling":"nextSibling"];return i=t(e).offset(),[i.left,i.top]},_hideDatepicker:function(e){var i,s,n,o,a=this._curInst;!a||e&&a!==t.data(e,"datepicker")||this._datepickerShowing&&(i=this._get(a,"showAnim"),s=this._get(a,"duration"),n=function(){t.datepicker._tidyDialog(a)},t.effects&&(t.effects.effect[i]||t.effects[i])?a.dpDiv.hide(i,t.datepicker._get(a,"showOptions"),s,n):a.dpDiv["slideDown"===i?"slideUp":"fadeIn"===i?"fadeOut":"hide"](i?s:null,n),i||n(),this._datepickerShowing=!1,o=this._get(a,"onClose"),o&&o.apply(a.input?a.input[0]:null,[a.input?a.input.val():"",a]),this._lastInput=null,this._inDialog&&(this._dialogInput.css({position:"absolute",left:"0",top:"-100px"}),t.blockUI&&(t.unblockUI(),t("body").append(this.dpDiv))),this._inDialog=!1)},_tidyDialog:function(t){t.dpDiv.removeClass(this._dialogClass).off(".ui-datepicker-calendar")},_checkExternalClick:function(e){if(t.datepicker._curInst){var i=t(e.target),s=t.datepicker._getInst(i[0]);(i[0].id!==t.datepicker._mainDivId&&0===i.parents("#"+t.datepicker._mainDivId).length&&!i.hasClass(t.datepicker.markerClassName)&&!i.closest("."+t.datepicker._triggerClass).length&&t.datepicker._datepickerShowing&&(!t.datepicker._inDialog||!t.blockUI)||i.hasClass(t.datepicker.markerClassName)&&t.datepicker._curInst!==s)&&t.datepicker._hideDatepicker()}},_adjustDate:function(e,i,s){var n=t(e),o=this._getInst(n[0]);this._isDisabledDatepicker(n[0])||(this._adjustInstDate(o,i+("M"===s?this._get(o,"showCurrentAtPos"):0),s),this._updateDatepicker(o))},_gotoToday:function(e){var i,s=t(e),n=this._getInst(s[0]);this._get(n,"gotoCurrent")&&n.currentDay?(n.selectedDay=n.currentDay,n.drawMonth=n.selectedMonth=n.currentMonth,n.drawYear=n.selectedYear=n.currentYear):(i=new Date,n.selectedDay=i.getDate(),n.drawMonth=n.selectedMonth=i.getMonth(),n.drawYear=n.selectedYear=i.getFullYear()),this._notifyChange(n),this._adjustDate(s)},_selectMonthYear:function(e,i,s){var n=t(e),o=this._getInst(n[0]);o["selected"+("M"===s?"Month":"Year")]=o["draw"+("M"===s?"Month":"Year")]=parseInt(i.options[i.selectedIndex].value,10),this._notifyChange(o),this._adjustDate(n)},_selectDay:function(e,i,s,n){var o,a=t(e);t(n).hasClass(this._unselectableClass)||this._isDisabledDatepicker(a[0])||(o=this._getInst(a[0]),o.selectedDay=o.currentDay=t("a",n).html(),o.selectedMonth=o.currentMonth=i,o.selectedYear=o.currentYear=s,this._selectDate(e,this._formatDate(o,o.currentDay,o.currentMonth,o.currentYear)))},_clearDate:function(e){var i=t(e);this._selectDate(i,"")},_selectDate:function(e,i){var s,n=t(e),o=this._getInst(n[0]);i=null!=i?i:this._formatDate(o),o.input&&o.input.val(i),this._updateAlternate(o),s=this._get(o,"onSelect"),s?s.apply(o.input?o.input[0]:null,[i,o]):o.input&&o.input.trigger("change"),o.inline?this._updateDatepicker(o):(this._hideDatepicker(),this._lastInput=o.input[0],"object"!=typeof o.input[0]&&o.input.trigger("focus"),this._lastInput=null)},_updateAlternate:function(e){var i,s,n,o=this._get(e,"altField");o&&(i=this._get(e,"altFormat")||this._get(e,"dateFormat"),s=this._getDate(e),n=this.formatDate(i,s,this._getFormatConfig(e)),t(o).val(n))},noWeekends:function(t){var e=t.getDay();return[e>0&&6>e,""]},iso8601Week:function(t){var e,i=new Date(t.getTime());return i.setDate(i.getDate()+4-(i.getDay()||7)),e=i.getTime(),i.setMonth(0),i.setDate(1),Math.floor(Math.round((e-i)/864e5)/7)+1},parseDate:function(e,i,s){if(null==e||null==i)throw"Invalid arguments";if(i="object"==typeof i?""+i:i+"",""===i)return null;var n,o,a,r,h=0,l=(s?s.shortYearCutoff:null)||this._defaults.shortYearCutoff,c="string"!=typeof l?l:(new Date).getFullYear()%100+parseInt(l,10),u=(s?s.dayNamesShort:null)||this._defaults.dayNamesShort,d=(s?s.dayNames:null)||this._defaults.dayNames,p=(s?s.monthNamesShort:null)||this._defaults.monthNamesShort,f=(s?s.monthNames:null)||this._defaults.monthNames,g=-1,m=-1,_=-1,v=-1,b=!1,y=function(t){var i=e.length>n+1&&e.charAt(n+1)===t;return i&&n++,i},w=function(t){var e=y(t),s="@"===t?14:"!"===t?20:"y"===t&&e?4:"o"===t?3:2,n="y"===t?s:1,o=RegExp("^\\d{"+n+","+s+"}"),a=i.substring(h).match(o);if(!a)throw"Missing number at position "+h;return h+=a[0].length,parseInt(a[0],10)},k=function(e,s,n){var o=-1,a=t.map(y(e)?n:s,function(t,e){return[[e,t]]}).sort(function(t,e){return-(t[1].length-e[1].length)});if(t.each(a,function(t,e){var s=e[1];return i.substr(h,s.length).toLowerCase()===s.toLowerCase()?(o=e[0],h+=s.length,!1):void 0}),-1!==o)return o+1;throw"Unknown name at position "+h},x=function(){if(i.charAt(h)!==e.charAt(n))throw"Unexpected literal at position "+h;h++};for(n=0;e.length>n;n++)if(b)"'"!==e.charAt(n)||y("'")?x():b=!1;else switch(e.charAt(n)){case"d":_=w("d");break;case"D":k("D",u,d);break;case"o":v=w("o");break;case"m":m=w("m");break;case"M":m=k("M",p,f);break;case"y":g=w("y");break;case"@":r=new Date(w("@")),g=r.getFullYear(),m=r.getMonth()+1,_=r.getDate();break;case"!":r=new Date((w("!")-this._ticksTo1970)/1e4),g=r.getFullYear(),m=r.getMonth()+1,_=r.getDate();break;case"'":y("'")?x():b=!0;break;default:x()}if(i.length>h&&(a=i.substr(h),!/^\s+/.test(a)))throw"Extra/unparsed characters found in date: "+a;if(-1===g?g=(new Date).getFullYear():100>g&&(g+=(new Date).getFullYear()-(new Date).getFullYear()%100+(c>=g?0:-100)),v>-1)for(m=1,_=v;;){if(o=this._getDaysInMonth(g,m-1),o>=_)break;m++,_-=o}if(r=this._daylightSavingAdjust(new Date(g,m-1,_)),r.getFullYear()!==g||r.getMonth()+1!==m||r.getDate()!==_)throw"Invalid date";return r},ATOM:"yy-mm-dd",COOKIE:"D, dd M yy",ISO_8601:"yy-mm-dd",RFC_822:"D, d M y",RFC_850:"DD, dd-M-y",RFC_1036:"D, d M y",RFC_1123:"D, d M yy",RFC_2822:"D, d M yy",RSS:"D, d M y",TICKS:"!",TIMESTAMP:"@",W3C:"yy-mm-dd",_ticksTo1970:1e7*60*60*24*(718685+Math.floor(492.5)-Math.floor(19.7)+Math.floor(4.925)),formatDate:function(t,e,i){if(!e)return"";var s,n=(i?i.dayNamesShort:null)||this._defaults.dayNamesShort,o=(i?i.dayNames:null)||this._defaults.dayNames,a=(i?i.monthNamesShort:null)||this._defaults.monthNamesShort,r=(i?i.monthNames:null)||this._defaults.monthNames,h=function(e){var i=t.length>s+1&&t.charAt(s+1)===e;return i&&s++,i},l=function(t,e,i){var s=""+e;if(h(t))for(;i>s.length;)s="0"+s;return s},c=function(t,e,i,s){return h(t)?s[e]:i[e]},u="",d=!1;if(e)for(s=0;t.length>s;s++)if(d)"'"!==t.charAt(s)||h("'")?u+=t.charAt(s):d=!1;else switch(t.charAt(s)){case"d":u+=l("d",e.getDate(),2);break;case"D":u+=c("D",e.getDay(),n,o);break;case"o":u+=l("o",Math.round((new Date(e.getFullYear(),e.getMonth(),e.getDate()).getTime()-new Date(e.getFullYear(),0,0).getTime())/864e5),3);break;case"m":u+=l("m",e.getMonth()+1,2);break;case"M":u+=c("M",e.getMonth(),a,r);break;case"y":u+=h("y")?e.getFullYear():(10>e.getFullYear()%100?"0":"")+e.getFullYear()%100;break;case"@":u+=e.getTime();break;case"!":u+=1e4*e.getTime()+this._ticksTo1970;break;case"'":h("'")?u+="'":d=!0;break;default:u+=t.charAt(s)}return u},_possibleChars:function(t){var e,i="",s=!1,n=function(i){var s=t.length>e+1&&t.charAt(e+1)===i;return s&&e++,s};for(e=0;t.length>e;e++)if(s)"'"!==t.charAt(e)||n("'")?i+=t.charAt(e):s=!1;else switch(t.charAt(e)){case"d":case"m":case"y":case"@":i+="0123456789";break;case"D":case"M":return null;case"'":n("'")?i+="'":s=!0;break;default:i+=t.charAt(e)}return i},_get:function(t,e){return void 0!==t.settings[e]?t.settings[e]:this._defaults[e]},_setDateFromField:function(t,e){if(t.input.val()!==t.lastVal){var i=this._get(t,"dateFormat"),s=t.lastVal=t.input?t.input.val():null,n=this._getDefaultDate(t),o=n,a=this._getFormatConfig(t);try{o=this.parseDate(i,s,a)||n}catch(r){s=e?"":s}t.selectedDay=o.getDate(),t.drawMonth=t.selectedMonth=o.getMonth(),t.drawYear=t.selectedYear=o.getFullYear(),t.currentDay=s?o.getDate():0,t.currentMonth=s?o.getMonth():0,t.currentYear=s?o.getFullYear():0,this._adjustInstDate(t)}},_getDefaultDate:function(t){return this._restrictMinMax(t,this._determineDate(t,this._get(t,"defaultDate"),new Date))},_determineDate:function(e,i,s){var n=function(t){var e=new Date;return e.setDate(e.getDate()+t),e},o=function(i){try{return t.datepicker.parseDate(t.datepicker._get(e,"dateFormat"),i,t.datepicker._getFormatConfig(e))}catch(s){}for(var n=(i.toLowerCase().match(/^c/)?t.datepicker._getDate(e):null)||new Date,o=n.getFullYear(),a=n.getMonth(),r=n.getDate(),h=/([+\-]?[0-9]+)\s*(d|D|w|W|m|M|y|Y)?/g,l=h.exec(i);l;){switch(l[2]||"d"){case"d":case"D":r+=parseInt(l[1],10);break;case"w":case"W":r+=7*parseInt(l[1],10);break;case"m":case"M":a+=parseInt(l[1],10),r=Math.min(r,t.datepicker._getDaysInMonth(o,a));break;case"y":case"Y":o+=parseInt(l[1],10),r=Math.min(r,t.datepicker._getDaysInMonth(o,a))}l=h.exec(i)}return new Date(o,a,r)},a=null==i||""===i?s:"string"==typeof i?o(i):"number"==typeof i?isNaN(i)?s:n(i):new Date(i.getTime());return a=a&&"Invalid Date"==""+a?s:a,a&&(a.setHours(0),a.setMinutes(0),a.setSeconds(0),a.setMilliseconds(0)),this._daylightSavingAdjust(a)},_daylightSavingAdjust:function(t){return t?(t.setHours(t.getHours()>12?t.getHours()+2:0),t):null},_setDate:function(t,e,i){var s=!e,n=t.selectedMonth,o=t.selectedYear,a=this._restrictMinMax(t,this._determineDate(t,e,new Date));t.selectedDay=t.currentDay=a.getDate(),t.drawMonth=t.selectedMonth=t.currentMonth=a.getMonth(),t.drawYear=t.selectedYear=t.currentYear=a.getFullYear(),n===t.selectedMonth&&o===t.selectedYear||i||this._notifyChange(t),this._adjustInstDate(t),t.input&&t.input.val(s?"":this._formatDate(t))},_getDate:function(t){var e=!t.currentYear||t.input&&""===t.input.val()?null:this._daylightSavingAdjust(new Date(t.currentYear,t.currentMonth,t.currentDay));return e},_attachHandlers:function(e){var i=this._get(e,"stepMonths"),s="#"+e.id.replace(/\\\\/g,"\\");e.dpDiv.find("[data-handler]").map(function(){var e={prev:function(){t.datepicker._adjustDate(s,-i,"M")},next:function(){t.datepicker._adjustDate(s,+i,"M")},hide:function(){t.datepicker._hideDatepicker()},today:function(){t.datepicker._gotoToday(s)},selectDay:function(){return t.datepicker._selectDay(s,+this.getAttribute("data-month"),+this.getAttribute("data-year"),this),!1},selectMonth:function(){return t.datepicker._selectMonthYear(s,this,"M"),!1},selectYear:function(){return t.datepicker._selectMonthYear(s,this,"Y"),!1}};t(this).on(this.getAttribute("data-event"),e[this.getAttribute("data-handler")])})},_generateHTML:function(t){var e,i,s,n,o,a,r,h,l,c,u,d,p,f,g,m,_,v,b,y,w,k,x,C,D,I,T,P,M,S,H,z,O,A,N,W,E,F,L,R=new Date,B=this._daylightSavingAdjust(new Date(R.getFullYear(),R.getMonth(),R.getDate())),Y=this._get(t,"isRTL"),j=this._get(t,"showButtonPanel"),q=this._get(t,"hideIfNoPrevNext"),K=this._get(t,"navigationAsDateFormat"),U=this._getNumberOfMonths(t),V=this._get(t,"showCurrentAtPos"),$=this._get(t,"stepMonths"),X=1!==U[0]||1!==U[1],G=this._daylightSavingAdjust(t.currentDay?new Date(t.currentYear,t.currentMonth,t.currentDay):new Date(9999,9,9)),Q=this._getMinMaxDate(t,"min"),J=this._getMinMaxDate(t,"max"),Z=t.drawMonth-V,te=t.drawYear;if(0>Z&&(Z+=12,te--),J)for(e=this._daylightSavingAdjust(new Date(J.getFullYear(),J.getMonth()-U[0]*U[1]+1,J.getDate())),e=Q&&Q>e?Q:e;this._daylightSavingAdjust(new Date(te,Z,1))>e;)Z--,0>Z&&(Z=11,te--);for(t.drawMonth=Z,t.drawYear=te,i=this._get(t,"prevText"),i=K?this.formatDate(i,this._daylightSavingAdjust(new Date(te,Z-$,1)),this._getFormatConfig(t)):i,s=this._canAdjustMonth(t,-1,te,Z)?"<a class='ui-datepicker-prev ui-corner-all' data-handler='prev' data-event='click' title='"+i+"'><span class='ui-icon ui-icon-circle-triangle-"+(Y?"e":"w")+"'>"+i+"</span></a>":q?"":"<a class='ui-datepicker-prev ui-corner-all ui-state-disabled' title='"+i+"'><span class='ui-icon ui-icon-circle-triangle-"+(Y?"e":"w")+"'>"+i+"</span></a>",n=this._get(t,"nextText"),n=K?this.formatDate(n,this._daylightSavingAdjust(new Date(te,Z+$,1)),this._getFormatConfig(t)):n,o=this._canAdjustMonth(t,1,te,Z)?"<a class='ui-datepicker-next ui-corner-all' data-handler='next' data-event='click' title='"+n+"'><span class='ui-icon ui-icon-circle-triangle-"+(Y?"w":"e")+"'>"+n+"</span></a>":q?"":"<a class='ui-datepicker-next ui-corner-all ui-state-disabled' title='"+n+"'><span class='ui-icon ui-icon-circle-triangle-"+(Y?"w":"e")+"'>"+n+"</span></a>",a=this._get(t,"currentText"),r=this._get(t,"gotoCurrent")&&t.currentDay?G:B,a=K?this.formatDate(a,r,this._getFormatConfig(t)):a,h=t.inline?"":"<button type='button' class='ui-datepicker-close ui-state-default ui-priority-primary ui-corner-all' data-handler='hide' data-event='click'>"+this._get(t,"closeText")+"</button>",l=j?"<div class='ui-datepicker-buttonpane ui-widget-content'>"+(Y?h:"")+(this._isInRange(t,r)?"<button type='button' class='ui-datepicker-current ui-state-default ui-priority-secondary ui-corner-all' data-handler='today' data-event='click'>"+a+"</button>":"")+(Y?"":h)+"</div>":"",c=parseInt(this._get(t,"firstDay"),10),c=isNaN(c)?0:c,u=this._get(t,"showWeek"),d=this._get(t,"dayNames"),p=this._get(t,"dayNamesMin"),f=this._get(t,"monthNames"),g=this._get(t,"monthNamesShort"),m=this._get(t,"beforeShowDay"),_=this._get(t,"showOtherMonths"),v=this._get(t,"selectOtherMonths"),b=this._getDefaultDate(t),y="",k=0;U[0]>k;k++){for(x="",this.maxRows=4,C=0;U[1]>C;C++){if(D=this._daylightSavingAdjust(new Date(te,Z,t.selectedDay)),I=" ui-corner-all",T="",X){if(T+="<div class='ui-datepicker-group",U[1]>1)switch(C){case 0:T+=" ui-datepicker-group-first",I=" ui-corner-"+(Y?"right":"left");break;case U[1]-1:T+=" ui-datepicker-group-last",I=" ui-corner-"+(Y?"left":"right");break;default:T+=" ui-datepicker-group-middle",I=""}T+="'>"}for(T+="<div class='ui-datepicker-header ui-widget-header ui-helper-clearfix"+I+"'>"+(/all|left/.test(I)&&0===k?Y?o:s:"")+(/all|right/.test(I)&&0===k?Y?s:o:"")+this._generateMonthYearHeader(t,Z,te,Q,J,k>0||C>0,f,g)+"</div><table class='ui-datepicker-calendar'><thead>"+"<tr>",P=u?"<th class='ui-datepicker-week-col'>"+this._get(t,"weekHeader")+"</th>":"",w=0;7>w;w++)M=(w+c)%7,P+="<th scope='col'"+((w+c+6)%7>=5?" class='ui-datepicker-week-end'":"")+">"+"<span title='"+d[M]+"'>"+p[M]+"</span></th>";for(T+=P+"</tr></thead><tbody>",S=this._getDaysInMonth(te,Z),te===t.selectedYear&&Z===t.selectedMonth&&(t.selectedDay=Math.min(t.selectedDay,S)),H=(this._getFirstDayOfMonth(te,Z)-c+7)%7,z=Math.ceil((H+S)/7),O=X?this.maxRows>z?this.maxRows:z:z,this.maxRows=O,A=this._daylightSavingAdjust(new Date(te,Z,1-H)),N=0;O>N;N++){for(T+="<tr>",W=u?"<td class='ui-datepicker-week-col'>"+this._get(t,"calculateWeek")(A)+"</td>":"",w=0;7>w;w++)E=m?m.apply(t.input?t.input[0]:null,[A]):[!0,""],F=A.getMonth()!==Z,L=F&&!v||!E[0]||Q&&Q>A||J&&A>J,W+="<td class='"+((w+c+6)%7>=5?" ui-datepicker-week-end":"")+(F?" ui-datepicker-other-month":"")+(A.getTime()===D.getTime()&&Z===t.selectedMonth&&t._keyEvent||b.getTime()===A.getTime()&&b.getTime()===D.getTime()?" "+this._dayOverClass:"")+(L?" "+this._unselectableClass+" ui-state-disabled":"")+(F&&!_?"":" "+E[1]+(A.getTime()===G.getTime()?" "+this._currentClass:"")+(A.getTime()===B.getTime()?" ui-datepicker-today":""))+"'"+(F&&!_||!E[2]?"":" title='"+E[2].replace(/'/g,"&#39;")+"'")+(L?"":" data-handler='selectDay' data-event='click' data-month='"+A.getMonth()+"' data-year='"+A.getFullYear()+"'")+">"+(F&&!_?"&#xa0;":L?"<span class='ui-state-default'>"+A.getDate()+"</span>":"<a class='ui-state-default"+(A.getTime()===B.getTime()?" ui-state-highlight":"")+(A.getTime()===G.getTime()?" ui-state-active":"")+(F?" ui-priority-secondary":"")+"' href='#'>"+A.getDate()+"</a>")+"</td>",A.setDate(A.getDate()+1),A=this._daylightSavingAdjust(A);T+=W+"</tr>"}Z++,Z>11&&(Z=0,te++),T+="</tbody></table>"+(X?"</div>"+(U[0]>0&&C===U[1]-1?"<div class='ui-datepicker-row-break'></div>":""):""),x+=T}y+=x}return y+=l,t._keyEvent=!1,y},_generateMonthYearHeader:function(t,e,i,s,n,o,a,r){var h,l,c,u,d,p,f,g,m=this._get(t,"changeMonth"),_=this._get(t,"changeYear"),v=this._get(t,"showMonthAfterYear"),b="<div class='ui-datepicker-title'>",y="";if(o||!m)y+="<span class='ui-datepicker-month'>"+a[e]+"</span>";else{for(h=s&&s.getFullYear()===i,l=n&&n.getFullYear()===i,y+="<select class='ui-datepicker-month' data-handler='selectMonth' data-event='change'>",c=0;12>c;c++)(!h||c>=s.getMonth())&&(!l||n.getMonth()>=c)&&(y+="<option value='"+c+"'"+(c===e?" selected='selected'":"")+">"+r[c]+"</option>");y+="</select>"}if(v||(b+=y+(!o&&m&&_?"":"&#xa0;")),!t.yearshtml)if(t.yearshtml="",o||!_)b+="<span class='ui-datepicker-year'>"+i+"</span>";else{for(u=this._get(t,"yearRange").split(":"),d=(new Date).getFullYear(),p=function(t){var e=t.match(/c[+\-].*/)?i+parseInt(t.substring(1),10):t.match(/[+\-].*/)?d+parseInt(t,10):parseInt(t,10);return isNaN(e)?d:e},f=p(u[0]),g=Math.max(f,p(u[1]||"")),f=s?Math.max(f,s.getFullYear()):f,g=n?Math.min(g,n.getFullYear()):g,t.yearshtml+="<select class='ui-datepicker-year' data-handler='selectYear' data-event='change'>";g>=f;f++)t.yearshtml+="<option value='"+f+"'"+(f===i?" selected='selected'":"")+">"+f+"</option>";t.yearshtml+="</select>",b+=t.yearshtml,t.yearshtml=null}return b+=this._get(t,"yearSuffix"),v&&(b+=(!o&&m&&_?"":"&#xa0;")+y),b+="</div>"},_adjustInstDate:function(t,e,i){var s=t.selectedYear+("Y"===i?e:0),n=t.selectedMonth+("M"===i?e:0),o=Math.min(t.selectedDay,this._getDaysInMonth(s,n))+("D"===i?e:0),a=this._restrictMinMax(t,this._daylightSavingAdjust(new Date(s,n,o)));t.selectedDay=a.getDate(),t.drawMonth=t.selectedMonth=a.getMonth(),t.drawYear=t.selectedYear=a.getFullYear(),("M"===i||"Y"===i)&&this._notifyChange(t)},_restrictMinMax:function(t,e){var i=this._getMinMaxDate(t,"min"),s=this._getMinMaxDate(t,"max"),n=i&&i>e?i:e;return s&&n>s?s:n},_notifyChange:function(t){var e=this._get(t,"onChangeMonthYear");e&&e.apply(t.input?t.input[0]:null,[t.selectedYear,t.selectedMonth+1,t])},_getNumberOfMonths:function(t){var e=this._get(t,"numberOfMonths");return null==e?[1,1]:"number"==typeof e?[1,e]:e},_getMinMaxDate:function(t,e){return this._determineDate(t,this._get(t,e+"Date"),null)},_getDaysInMonth:function(t,e){return 32-this._daylightSavingAdjust(new Date(t,e,32)).getDate()},_getFirstDayOfMonth:function(t,e){return new Date(t,e,1).getDay()},_canAdjustMonth:function(t,e,i,s){var n=this._getNumberOfMonths(t),o=this._daylightSavingAdjust(new Date(i,s+(0>e?e:n[0]*n[1]),1));return 0>e&&o.setDate(this._getDaysInMonth(o.getFullYear(),o.getMonth())),this._isInRange(t,o)},_isInRange:function(t,e){var i,s,n=this._getMinMaxDate(t,"min"),o=this._getMinMaxDate(t,"max"),a=null,r=null,h=this._get(t,"yearRange");return h&&(i=h.split(":"),s=(new Date).getFullYear(),a=parseInt(i[0],10),r=parseInt(i[1],10),i[0].match(/[+\-].*/)&&(a+=s),i[1].match(/[+\-].*/)&&(r+=s)),(!n||e.getTime()>=n.getTime())&&(!o||e.getTime()<=o.getTime())&&(!a||e.getFullYear()>=a)&&(!r||r>=e.getFullYear())},_getFormatConfig:function(t){var e=this._get(t,"shortYearCutoff");return e="string"!=typeof e?e:(new Date).getFullYear()%100+parseInt(e,10),{shortYearCutoff:e,dayNamesShort:this._get(t,"dayNamesShort"),dayNames:this._get(t,"dayNames"),monthNamesShort:this._get(t,"monthNamesShort"),monthNames:this._get(t,"monthNames")}},_formatDate:function(t,e,i,s){e||(t.currentDay=t.selectedDay,t.currentMonth=t.selectedMonth,t.currentYear=t.selectedYear);var n=e?"object"==typeof e?e:this._daylightSavingAdjust(new Date(s,i,e)):this._daylightSavingAdjust(new Date(t.currentYear,t.currentMonth,t.currentDay));return this.formatDate(this._get(t,"dateFormat"),n,this._getFormatConfig(t))}}),t.fn.datepicker=function(e){if(!this.length)return this;t.datepicker.initialized||(t(document).on("mousedown",t.datepicker._checkExternalClick),t.datepicker.initialized=!0),0===t("#"+t.datepicker._mainDivId).length&&t("body").append(t.datepicker.dpDiv);var i=Array.prototype.slice.call(arguments,1);return"string"!=typeof e||"isDisabled"!==e&&"getDate"!==e&&"widget"!==e?"option"===e&&2===arguments.length&&"string"==typeof arguments[1]?t.datepicker["_"+e+"Datepicker"].apply(t.datepicker,[this[0]].concat(i)):this.each(function(){"string"==typeof e?t.datepicker["_"+e+"Datepicker"].apply(t.datepicker,[this].concat(i)):t.datepicker._attachDatepicker(this,e)}):t.datepicker["_"+e+"Datepicker"].apply(t.datepicker,[this[0]].concat(i))},t.datepicker=new s,t.datepicker.initialized=!1,t.datepicker.uuid=(new Date).getTime(),t.datepicker.version="1.12.1",t.datepicker,t.ui.ie=!!/msie [\w.]+/.exec(navigator.userAgent.toLowerCase());var _=!1;t(document).on("mouseup",function(){_=!1}),t.widget("ui.mouse",{version:"1.12.1",options:{cancel:"input, textarea, button, select, option",distance:1,delay:0},_mouseInit:function(){var e=this;this.element.on("mousedown."+this.widgetName,function(t){return e._mouseDown(t)}).on("click."+this.widgetName,function(i){return!0===t.data(i.target,e.widgetName+".preventClickEvent")?(t.removeData(i.target,e.widgetName+".preventClickEvent"),i.stopImmediatePropagation(),!1):void 0}),this.started=!1},_mouseDestroy:function(){this.element.off("."+this.widgetName),this._mouseMoveDelegate&&this.document.off("mousemove."+this.widgetName,this._mouseMoveDelegate).off("mouseup."+this.widgetName,this._mouseUpDelegate)},_mouseDown:function(e){if(!_){this._mouseMoved=!1,this._mouseStarted&&this._mouseUp(e),this._mouseDownEvent=e;var i=this,s=1===e.which,n="string"==typeof this.options.cancel&&e.target.nodeName?t(e.target).closest(this.options.cancel).length:!1;return s&&!n&&this._mouseCapture(e)?(this.mouseDelayMet=!this.options.delay,this.mouseDelayMet||(this._mouseDelayTimer=setTimeout(function(){i.mouseDelayMet=!0},this.options.delay)),this._mouseDistanceMet(e)&&this._mouseDelayMet(e)&&(this._mouseStarted=this._mouseStart(e)!==!1,!this._mouseStarted)?(e.preventDefault(),!0):(!0===t.data(e.target,this.widgetName+".preventClickEvent")&&t.removeData(e.target,this.widgetName+".preventClickEvent"),this._mouseMoveDelegate=function(t){return i._mouseMove(t)},this._mouseUpDelegate=function(t){return i._mouseUp(t)},this.document.on("mousemove."+this.widgetName,this._mouseMoveDelegate).on("mouseup."+this.widgetName,this._mouseUpDelegate),e.preventDefault(),_=!0,!0)):!0}},_mouseMove:function(e){if(this._mouseMoved){if(t.ui.ie&&(!document.documentMode||9>document.documentMode)&&!e.button)return this._mouseUp(e);if(!e.which)if(e.originalEvent.altKey||e.originalEvent.ctrlKey||e.originalEvent.metaKey||e.originalEvent.shiftKey)this.ignoreMissingWhich=!0;else if(!this.ignoreMissingWhich)return this._mouseUp(e)}return(e.which||e.button)&&(this._mouseMoved=!0),this._mouseStarted?(this._mouseDrag(e),e.preventDefault()):(this._mouseDistanceMet(e)&&this._mouseDelayMet(e)&&(this._mouseStarted=this._mouseStart(this._mouseDownEvent,e)!==!1,this._mouseStarted?this._mouseDrag(e):this._mouseUp(e)),!this._mouseStarted)},_mouseUp:function(e){this.document.off("mousemove."+this.widgetName,this._mouseMoveDelegate).off("mouseup."+this.widgetName,this._mouseUpDelegate),this._mouseStarted&&(this._mouseStarted=!1,e.target===this._mouseDownEvent.target&&t.data(e.target,this.widgetName+".preventClickEvent",!0),this._mouseStop(e)),this._mouseDelayTimer&&(clearTimeout(this._mouseDelayTimer),delete this._mouseDelayTimer),this.ignoreMissingWhich=!1,_=!1,e.preventDefault()},_mouseDistanceMet:function(t){return Math.max(Math.abs(this._mouseDownEvent.pageX-t.pageX),Math.abs(this._mouseDownEvent.pageY-t.pageY))>=this.options.distance},_mouseDelayMet:function(){return this.mouseDelayMet},_mouseStart:function(){},_mouseDrag:function(){},_mouseStop:function(){},_mouseCapture:function(){return!0}}),t.ui.plugin={add:function(e,i,s){var n,o=t.ui[e].prototype;for(n in s)o.plugins[n]=o.plugins[n]||[],o.plugins[n].push([i,s[n]])},call:function(t,e,i,s){var n,o=t.plugins[e];if(o&&(s||t.element[0].parentNode&&11!==t.element[0].parentNode.nodeType))for(n=0;o.length>n;n++)t.options[o[n][0]]&&o[n][1].apply(t.element,i)}},t.ui.safeBlur=function(e){e&&"body"!==e.nodeName.toLowerCase()&&t(e).trigger("blur")},t.widget("ui.draggable",t.ui.mouse,{version:"1.12.1",widgetEventPrefix:"drag",options:{addClasses:!0,appendTo:"parent",axis:!1,connectToSortable:!1,containment:!1,cursor:"auto",cursorAt:!1,grid:!1,handle:!1,helper:"original",iframeFix:!1,opacity:!1,refreshPositions:!1,revert:!1,revertDuration:500,scope:"default",scroll:!0,scrollSensitivity:20,scrollSpeed:20,snap:!1,snapMode:"both",snapTolerance:20,stack:!1,zIndex:!1,drag:null,start:null,stop:null},_create:function(){"original"===this.options.helper&&this._setPositionRelative(),this.options.addClasses&&this._addClass("ui-draggable"),this._setHandleClassName(),this._mouseInit()},_setOption:function(t,e){this._super(t,e),"handle"===t&&(this._removeHandleClassName(),this._setHandleClassName())},_destroy:function(){return(this.helper||this.element).is(".ui-draggable-dragging")?(this.destroyOnClear=!0,void 0):(this._removeHandleClassName(),this._mouseDestroy(),void 0)},_mouseCapture:function(e){var i=this.options;return this.helper||i.disabled||t(e.target).closest(".ui-resizable-handle").length>0?!1:(this.handle=this._getHandle(e),this.handle?(this._blurActiveElement(e),this._blockFrames(i.iframeFix===!0?"iframe":i.iframeFix),!0):!1)},_blockFrames:function(e){this.iframeBlocks=this.document.find(e).map(function(){var e=t(this);return t("<div>").css("position","absolute").appendTo(e.parent()).outerWidth(e.outerWidth()).outerHeight(e.outerHeight()).offset(e.offset())[0]})},_unblockFrames:function(){this.iframeBlocks&&(this.iframeBlocks.remove(),delete this.iframeBlocks)},_blurActiveElement:function(e){var i=t.ui.safeActiveElement(this.document[0]),s=t(e.target);s.closest(i).length||t.ui.safeBlur(i)},_mouseStart:function(e){var i=this.options;return this.helper=this._createHelper(e),this._addClass(this.helper,"ui-draggable-dragging"),this._cacheHelperProportions(),t.ui.ddmanager&&(t.ui.ddmanager.current=this),this._cacheMargins(),this.cssPosition=this.helper.css("position"),this.scrollParent=this.helper.scrollParent(!0),this.offsetParent=this.helper.offsetParent(),this.hasFixedAncestor=this.helper.parents().filter(function(){return"fixed"===t(this).css("position")}).length>0,this.positionAbs=this.element.offset(),this._refreshOffsets(e),this.originalPosition=this.position=this._generatePosition(e,!1),this.originalPageX=e.pageX,this.originalPageY=e.pageY,i.cursorAt&&this._adjustOffsetFromHelper(i.cursorAt),this._setContainment(),this._trigger("start",e)===!1?(this._clear(),!1):(this._cacheHelperProportions(),t.ui.ddmanager&&!i.dropBehaviour&&t.ui.ddmanager.prepareOffsets(this,e),this._mouseDrag(e,!0),t.ui.ddmanager&&t.ui.ddmanager.dragStart(this,e),!0)},_refreshOffsets:function(t){this.offset={top:this.positionAbs.top-this.margins.top,left:this.positionAbs.left-this.margins.left,scroll:!1,parent:this._getParentOffset(),relative:this._getRelativeOffset()},this.offset.click={left:t.pageX-this.offset.left,top:t.pageY-this.offset.top}},_mouseDrag:function(e,i){if(this.hasFixedAncestor&&(this.offset.parent=this._getParentOffset()),this.position=this._generatePosition(e,!0),this.positionAbs=this._convertPositionTo("absolute"),!i){var s=this._uiHash();if(this._trigger("drag",e,s)===!1)return this._mouseUp(new t.Event("mouseup",e)),!1;this.position=s.position}return this.helper[0].style.left=this.position.left+"px",this.helper[0].style.top=this.position.top+"px",t.ui.ddmanager&&t.ui.ddmanager.drag(this,e),!1},_mouseStop:function(e){var i=this,s=!1;return t.ui.ddmanager&&!this.options.dropBehaviour&&(s=t.ui.ddmanager.drop(this,e)),this.dropped&&(s=this.dropped,this.dropped=!1),"invalid"===this.options.revert&&!s||"valid"===this.options.revert&&s||this.options.revert===!0||t.isFunction(this.options.revert)&&this.options.revert.call(this.element,s)?t(this.helper).animate(this.originalPosition,parseInt(this.options.revertDuration,10),function(){i._trigger("stop",e)!==!1&&i._clear()}):this._trigger("stop",e)!==!1&&this._clear(),!1},_mouseUp:function(e){return this._unblockFrames(),t.ui.ddmanager&&t.ui.ddmanager.dragStop(this,e),this.handleElement.is(e.target)&&this.element.trigger("focus"),t.ui.mouse.prototype._mouseUp.call(this,e)},cancel:function(){return this.helper.is(".ui-draggable-dragging")?this._mouseUp(new t.Event("mouseup",{target:this.element[0]})):this._clear(),this},_getHandle:function(e){return this.options.handle?!!t(e.target).closest(this.element.find(this.options.handle)).length:!0},_setHandleClassName:function(){this.handleElement=this.options.handle?this.element.find(this.options.handle):this.element,this._addClass(this.handleElement,"ui-draggable-handle")},_removeHandleClassName:function(){this._removeClass(this.handleElement,"ui-draggable-handle")},_createHelper:function(e){var i=this.options,s=t.isFunction(i.helper),n=s?t(i.helper.apply(this.element[0],[e])):"clone"===i.helper?this.element.clone().removeAttr("id"):this.element;return n.parents("body").length||n.appendTo("parent"===i.appendTo?this.element[0].parentNode:i.appendTo),s&&n[0]===this.element[0]&&this._setPositionRelative(),n[0]===this.element[0]||/(fixed|absolute)/.test(n.css("position"))||n.css("position","absolute"),n},_setPositionRelative:function(){/^(?:r|a|f)/.test(this.element.css("position"))||(this.element[0].style.position="relative")},_adjustOffsetFromHelper:function(e){"string"==typeof e&&(e=e.split(" ")),t.isArray(e)&&(e={left:+e[0],top:+e[1]||0}),"left"in e&&(this.offset.click.left=e.left+this.margins.left),"right"in e&&(this.offset.click.left=this.helperProportions.width-e.right+this.margins.left),"top"in e&&(this.offset.click.top=e.top+this.margins.top),"bottom"in e&&(this.offset.click.top=this.helperProportions.height-e.bottom+this.margins.top)},_isRootNode:function(t){return/(html|body)/i.test(t.tagName)||t===this.document[0]},_getParentOffset:function(){var e=this.offsetParent.offset(),i=this.document[0];return"absolute"===this.cssPosition&&this.scrollParent[0]!==i&&t.contains(this.scrollParent[0],this.offsetParent[0])&&(e.left+=this.scrollParent.scrollLeft(),e.top+=this.scrollParent.scrollTop()),this._isRootNode(this.offsetParent[0])&&(e={top:0,left:0}),{top:e.top+(parseInt(this.offsetParent.css("borderTopWidth"),10)||0),left:e.left+(parseInt(this.offsetParent.css("borderLeftWidth"),10)||0)}},_getRelativeOffset:function(){if("relative"!==this.cssPosition)return{top:0,left:0};var t=this.element.position(),e=this._isRootNode(this.scrollParent[0]);return{top:t.top-(parseInt(this.helper.css("top"),10)||0)+(e?0:this.scrollParent.scrollTop()),left:t.left-(parseInt(this.helper.css("left"),10)||0)+(e?0:this.scrollParent.scrollLeft())}
-},_cacheMargins:function(){this.margins={left:parseInt(this.element.css("marginLeft"),10)||0,top:parseInt(this.element.css("marginTop"),10)||0,right:parseInt(this.element.css("marginRight"),10)||0,bottom:parseInt(this.element.css("marginBottom"),10)||0}},_cacheHelperProportions:function(){this.helperProportions={width:this.helper.outerWidth(),height:this.helper.outerHeight()}},_setContainment:function(){var e,i,s,n=this.options,o=this.document[0];return this.relativeContainer=null,n.containment?"window"===n.containment?(this.containment=[t(window).scrollLeft()-this.offset.relative.left-this.offset.parent.left,t(window).scrollTop()-this.offset.relative.top-this.offset.parent.top,t(window).scrollLeft()+t(window).width()-this.helperProportions.width-this.margins.left,t(window).scrollTop()+(t(window).height()||o.body.parentNode.scrollHeight)-this.helperProportions.height-this.margins.top],void 0):"document"===n.containment?(this.containment=[0,0,t(o).width()-this.helperProportions.width-this.margins.left,(t(o).height()||o.body.parentNode.scrollHeight)-this.helperProportions.height-this.margins.top],void 0):n.containment.constructor===Array?(this.containment=n.containment,void 0):("parent"===n.containment&&(n.containment=this.helper[0].parentNode),i=t(n.containment),s=i[0],s&&(e=/(scroll|auto)/.test(i.css("overflow")),this.containment=[(parseInt(i.css("borderLeftWidth"),10)||0)+(parseInt(i.css("paddingLeft"),10)||0),(parseInt(i.css("borderTopWidth"),10)||0)+(parseInt(i.css("paddingTop"),10)||0),(e?Math.max(s.scrollWidth,s.offsetWidth):s.offsetWidth)-(parseInt(i.css("borderRightWidth"),10)||0)-(parseInt(i.css("paddingRight"),10)||0)-this.helperProportions.width-this.margins.left-this.margins.right,(e?Math.max(s.scrollHeight,s.offsetHeight):s.offsetHeight)-(parseInt(i.css("borderBottomWidth"),10)||0)-(parseInt(i.css("paddingBottom"),10)||0)-this.helperProportions.height-this.margins.top-this.margins.bottom],this.relativeContainer=i),void 0):(this.containment=null,void 0)},_convertPositionTo:function(t,e){e||(e=this.position);var i="absolute"===t?1:-1,s=this._isRootNode(this.scrollParent[0]);return{top:e.top+this.offset.relative.top*i+this.offset.parent.top*i-("fixed"===this.cssPosition?-this.offset.scroll.top:s?0:this.offset.scroll.top)*i,left:e.left+this.offset.relative.left*i+this.offset.parent.left*i-("fixed"===this.cssPosition?-this.offset.scroll.left:s?0:this.offset.scroll.left)*i}},_generatePosition:function(t,e){var i,s,n,o,a=this.options,r=this._isRootNode(this.scrollParent[0]),h=t.pageX,l=t.pageY;return r&&this.offset.scroll||(this.offset.scroll={top:this.scrollParent.scrollTop(),left:this.scrollParent.scrollLeft()}),e&&(this.containment&&(this.relativeContainer?(s=this.relativeContainer.offset(),i=[this.containment[0]+s.left,this.containment[1]+s.top,this.containment[2]+s.left,this.containment[3]+s.top]):i=this.containment,t.pageX-this.offset.click.left<i[0]&&(h=i[0]+this.offset.click.left),t.pageY-this.offset.click.top<i[1]&&(l=i[1]+this.offset.click.top),t.pageX-this.offset.click.left>i[2]&&(h=i[2]+this.offset.click.left),t.pageY-this.offset.click.top>i[3]&&(l=i[3]+this.offset.click.top)),a.grid&&(n=a.grid[1]?this.originalPageY+Math.round((l-this.originalPageY)/a.grid[1])*a.grid[1]:this.originalPageY,l=i?n-this.offset.click.top>=i[1]||n-this.offset.click.top>i[3]?n:n-this.offset.click.top>=i[1]?n-a.grid[1]:n+a.grid[1]:n,o=a.grid[0]?this.originalPageX+Math.round((h-this.originalPageX)/a.grid[0])*a.grid[0]:this.originalPageX,h=i?o-this.offset.click.left>=i[0]||o-this.offset.click.left>i[2]?o:o-this.offset.click.left>=i[0]?o-a.grid[0]:o+a.grid[0]:o),"y"===a.axis&&(h=this.originalPageX),"x"===a.axis&&(l=this.originalPageY)),{top:l-this.offset.click.top-this.offset.relative.top-this.offset.parent.top+("fixed"===this.cssPosition?-this.offset.scroll.top:r?0:this.offset.scroll.top),left:h-this.offset.click.left-this.offset.relative.left-this.offset.parent.left+("fixed"===this.cssPosition?-this.offset.scroll.left:r?0:this.offset.scroll.left)}},_clear:function(){this._removeClass(this.helper,"ui-draggable-dragging"),this.helper[0]===this.element[0]||this.cancelHelperRemoval||this.helper.remove(),this.helper=null,this.cancelHelperRemoval=!1,this.destroyOnClear&&this.destroy()},_trigger:function(e,i,s){return s=s||this._uiHash(),t.ui.plugin.call(this,e,[i,s,this],!0),/^(drag|start|stop)/.test(e)&&(this.positionAbs=this._convertPositionTo("absolute"),s.offset=this.positionAbs),t.Widget.prototype._trigger.call(this,e,i,s)},plugins:{},_uiHash:function(){return{helper:this.helper,position:this.position,originalPosition:this.originalPosition,offset:this.positionAbs}}}),t.ui.plugin.add("draggable","connectToSortable",{start:function(e,i,s){var n=t.extend({},i,{item:s.element});s.sortables=[],t(s.options.connectToSortable).each(function(){var i=t(this).sortable("instance");i&&!i.options.disabled&&(s.sortables.push(i),i.refreshPositions(),i._trigger("activate",e,n))})},stop:function(e,i,s){var n=t.extend({},i,{item:s.element});s.cancelHelperRemoval=!1,t.each(s.sortables,function(){var t=this;t.isOver?(t.isOver=0,s.cancelHelperRemoval=!0,t.cancelHelperRemoval=!1,t._storedCSS={position:t.placeholder.css("position"),top:t.placeholder.css("top"),left:t.placeholder.css("left")},t._mouseStop(e),t.options.helper=t.options._helper):(t.cancelHelperRemoval=!0,t._trigger("deactivate",e,n))})},drag:function(e,i,s){t.each(s.sortables,function(){var n=!1,o=this;o.positionAbs=s.positionAbs,o.helperProportions=s.helperProportions,o.offset.click=s.offset.click,o._intersectsWith(o.containerCache)&&(n=!0,t.each(s.sortables,function(){return this.positionAbs=s.positionAbs,this.helperProportions=s.helperProportions,this.offset.click=s.offset.click,this!==o&&this._intersectsWith(this.containerCache)&&t.contains(o.element[0],this.element[0])&&(n=!1),n})),n?(o.isOver||(o.isOver=1,s._parent=i.helper.parent(),o.currentItem=i.helper.appendTo(o.element).data("ui-sortable-item",!0),o.options._helper=o.options.helper,o.options.helper=function(){return i.helper[0]},e.target=o.currentItem[0],o._mouseCapture(e,!0),o._mouseStart(e,!0,!0),o.offset.click.top=s.offset.click.top,o.offset.click.left=s.offset.click.left,o.offset.parent.left-=s.offset.parent.left-o.offset.parent.left,o.offset.parent.top-=s.offset.parent.top-o.offset.parent.top,s._trigger("toSortable",e),s.dropped=o.element,t.each(s.sortables,function(){this.refreshPositions()}),s.currentItem=s.element,o.fromOutside=s),o.currentItem&&(o._mouseDrag(e),i.position=o.position)):o.isOver&&(o.isOver=0,o.cancelHelperRemoval=!0,o.options._revert=o.options.revert,o.options.revert=!1,o._trigger("out",e,o._uiHash(o)),o._mouseStop(e,!0),o.options.revert=o.options._revert,o.options.helper=o.options._helper,o.placeholder&&o.placeholder.remove(),i.helper.appendTo(s._parent),s._refreshOffsets(e),i.position=s._generatePosition(e,!0),s._trigger("fromSortable",e),s.dropped=!1,t.each(s.sortables,function(){this.refreshPositions()}))})}}),t.ui.plugin.add("draggable","cursor",{start:function(e,i,s){var n=t("body"),o=s.options;n.css("cursor")&&(o._cursor=n.css("cursor")),n.css("cursor",o.cursor)},stop:function(e,i,s){var n=s.options;n._cursor&&t("body").css("cursor",n._cursor)}}),t.ui.plugin.add("draggable","opacity",{start:function(e,i,s){var n=t(i.helper),o=s.options;n.css("opacity")&&(o._opacity=n.css("opacity")),n.css("opacity",o.opacity)},stop:function(e,i,s){var n=s.options;n._opacity&&t(i.helper).css("opacity",n._opacity)}}),t.ui.plugin.add("draggable","scroll",{start:function(t,e,i){i.scrollParentNotHidden||(i.scrollParentNotHidden=i.helper.scrollParent(!1)),i.scrollParentNotHidden[0]!==i.document[0]&&"HTML"!==i.scrollParentNotHidden[0].tagName&&(i.overflowOffset=i.scrollParentNotHidden.offset())},drag:function(e,i,s){var n=s.options,o=!1,a=s.scrollParentNotHidden[0],r=s.document[0];a!==r&&"HTML"!==a.tagName?(n.axis&&"x"===n.axis||(s.overflowOffset.top+a.offsetHeight-e.pageY<n.scrollSensitivity?a.scrollTop=o=a.scrollTop+n.scrollSpeed:e.pageY-s.overflowOffset.top<n.scrollSensitivity&&(a.scrollTop=o=a.scrollTop-n.scrollSpeed)),n.axis&&"y"===n.axis||(s.overflowOffset.left+a.offsetWidth-e.pageX<n.scrollSensitivity?a.scrollLeft=o=a.scrollLeft+n.scrollSpeed:e.pageX-s.overflowOffset.left<n.scrollSensitivity&&(a.scrollLeft=o=a.scrollLeft-n.scrollSpeed))):(n.axis&&"x"===n.axis||(e.pageY-t(r).scrollTop()<n.scrollSensitivity?o=t(r).scrollTop(t(r).scrollTop()-n.scrollSpeed):t(window).height()-(e.pageY-t(r).scrollTop())<n.scrollSensitivity&&(o=t(r).scrollTop(t(r).scrollTop()+n.scrollSpeed))),n.axis&&"y"===n.axis||(e.pageX-t(r).scrollLeft()<n.scrollSensitivity?o=t(r).scrollLeft(t(r).scrollLeft()-n.scrollSpeed):t(window).width()-(e.pageX-t(r).scrollLeft())<n.scrollSensitivity&&(o=t(r).scrollLeft(t(r).scrollLeft()+n.scrollSpeed)))),o!==!1&&t.ui.ddmanager&&!n.dropBehaviour&&t.ui.ddmanager.prepareOffsets(s,e)}}),t.ui.plugin.add("draggable","snap",{start:function(e,i,s){var n=s.options;s.snapElements=[],t(n.snap.constructor!==String?n.snap.items||":data(ui-draggable)":n.snap).each(function(){var e=t(this),i=e.offset();this!==s.element[0]&&s.snapElements.push({item:this,width:e.outerWidth(),height:e.outerHeight(),top:i.top,left:i.left})})},drag:function(e,i,s){var n,o,a,r,h,l,c,u,d,p,f=s.options,g=f.snapTolerance,m=i.offset.left,_=m+s.helperProportions.width,v=i.offset.top,b=v+s.helperProportions.height;for(d=s.snapElements.length-1;d>=0;d--)h=s.snapElements[d].left-s.margins.left,l=h+s.snapElements[d].width,c=s.snapElements[d].top-s.margins.top,u=c+s.snapElements[d].height,h-g>_||m>l+g||c-g>b||v>u+g||!t.contains(s.snapElements[d].item.ownerDocument,s.snapElements[d].item)?(s.snapElements[d].snapping&&s.options.snap.release&&s.options.snap.release.call(s.element,e,t.extend(s._uiHash(),{snapItem:s.snapElements[d].item})),s.snapElements[d].snapping=!1):("inner"!==f.snapMode&&(n=g>=Math.abs(c-b),o=g>=Math.abs(u-v),a=g>=Math.abs(h-_),r=g>=Math.abs(l-m),n&&(i.position.top=s._convertPositionTo("relative",{top:c-s.helperProportions.height,left:0}).top),o&&(i.position.top=s._convertPositionTo("relative",{top:u,left:0}).top),a&&(i.position.left=s._convertPositionTo("relative",{top:0,left:h-s.helperProportions.width}).left),r&&(i.position.left=s._convertPositionTo("relative",{top:0,left:l}).left)),p=n||o||a||r,"outer"!==f.snapMode&&(n=g>=Math.abs(c-v),o=g>=Math.abs(u-b),a=g>=Math.abs(h-m),r=g>=Math.abs(l-_),n&&(i.position.top=s._convertPositionTo("relative",{top:c,left:0}).top),o&&(i.position.top=s._convertPositionTo("relative",{top:u-s.helperProportions.height,left:0}).top),a&&(i.position.left=s._convertPositionTo("relative",{top:0,left:h}).left),r&&(i.position.left=s._convertPositionTo("relative",{top:0,left:l-s.helperProportions.width}).left)),!s.snapElements[d].snapping&&(n||o||a||r||p)&&s.options.snap.snap&&s.options.snap.snap.call(s.element,e,t.extend(s._uiHash(),{snapItem:s.snapElements[d].item})),s.snapElements[d].snapping=n||o||a||r||p)}}),t.ui.plugin.add("draggable","stack",{start:function(e,i,s){var n,o=s.options,a=t.makeArray(t(o.stack)).sort(function(e,i){return(parseInt(t(e).css("zIndex"),10)||0)-(parseInt(t(i).css("zIndex"),10)||0)});a.length&&(n=parseInt(t(a[0]).css("zIndex"),10)||0,t(a).each(function(e){t(this).css("zIndex",n+e)}),this.css("zIndex",n+a.length))}}),t.ui.plugin.add("draggable","zIndex",{start:function(e,i,s){var n=t(i.helper),o=s.options;n.css("zIndex")&&(o._zIndex=n.css("zIndex")),n.css("zIndex",o.zIndex)},stop:function(e,i,s){var n=s.options;n._zIndex&&t(i.helper).css("zIndex",n._zIndex)}}),t.ui.draggable,t.widget("ui.resizable",t.ui.mouse,{version:"1.12.1",widgetEventPrefix:"resize",options:{alsoResize:!1,animate:!1,animateDuration:"slow",animateEasing:"swing",aspectRatio:!1,autoHide:!1,classes:{"ui-resizable-se":"ui-icon ui-icon-gripsmall-diagonal-se"},containment:!1,ghost:!1,grid:!1,handles:"e,s,se",helper:!1,maxHeight:null,maxWidth:null,minHeight:10,minWidth:10,zIndex:90,resize:null,start:null,stop:null},_num:function(t){return parseFloat(t)||0},_isNumber:function(t){return!isNaN(parseFloat(t))},_hasScroll:function(e,i){if("hidden"===t(e).css("overflow"))return!1;var s=i&&"left"===i?"scrollLeft":"scrollTop",n=!1;return e[s]>0?!0:(e[s]=1,n=e[s]>0,e[s]=0,n)},_create:function(){var e,i=this.options,s=this;this._addClass("ui-resizable"),t.extend(this,{_aspectRatio:!!i.aspectRatio,aspectRatio:i.aspectRatio,originalElement:this.element,_proportionallyResizeElements:[],_helper:i.helper||i.ghost||i.animate?i.helper||"ui-resizable-helper":null}),this.element[0].nodeName.match(/^(canvas|textarea|input|select|button|img)$/i)&&(this.element.wrap(t("<div class='ui-wrapper' style='overflow: hidden;'></div>").css({position:this.element.css("position"),width:this.element.outerWidth(),height:this.element.outerHeight(),top:this.element.css("top"),left:this.element.css("left")})),this.element=this.element.parent().data("ui-resizable",this.element.resizable("instance")),this.elementIsWrapper=!0,e={marginTop:this.originalElement.css("marginTop"),marginRight:this.originalElement.css("marginRight"),marginBottom:this.originalElement.css("marginBottom"),marginLeft:this.originalElement.css("marginLeft")},this.element.css(e),this.originalElement.css("margin",0),this.originalResizeStyle=this.originalElement.css("resize"),this.originalElement.css("resize","none"),this._proportionallyResizeElements.push(this.originalElement.css({position:"static",zoom:1,display:"block"})),this.originalElement.css(e),this._proportionallyResize()),this._setupHandles(),i.autoHide&&t(this.element).on("mouseenter",function(){i.disabled||(s._removeClass("ui-resizable-autohide"),s._handles.show())}).on("mouseleave",function(){i.disabled||s.resizing||(s._addClass("ui-resizable-autohide"),s._handles.hide())}),this._mouseInit()},_destroy:function(){this._mouseDestroy();var e,i=function(e){t(e).removeData("resizable").removeData("ui-resizable").off(".resizable").find(".ui-resizable-handle").remove()};return this.elementIsWrapper&&(i(this.element),e=this.element,this.originalElement.css({position:e.css("position"),width:e.outerWidth(),height:e.outerHeight(),top:e.css("top"),left:e.css("left")}).insertAfter(e),e.remove()),this.originalElement.css("resize",this.originalResizeStyle),i(this.originalElement),this},_setOption:function(t,e){switch(this._super(t,e),t){case"handles":this._removeHandles(),this._setupHandles();break;default:}},_setupHandles:function(){var e,i,s,n,o,a=this.options,r=this;if(this.handles=a.handles||(t(".ui-resizable-handle",this.element).length?{n:".ui-resizable-n",e:".ui-resizable-e",s:".ui-resizable-s",w:".ui-resizable-w",se:".ui-resizable-se",sw:".ui-resizable-sw",ne:".ui-resizable-ne",nw:".ui-resizable-nw"}:"e,s,se"),this._handles=t(),this.handles.constructor===String)for("all"===this.handles&&(this.handles="n,e,s,w,se,sw,ne,nw"),s=this.handles.split(","),this.handles={},i=0;s.length>i;i++)e=t.trim(s[i]),n="ui-resizable-"+e,o=t("<div>"),this._addClass(o,"ui-resizable-handle "+n),o.css({zIndex:a.zIndex}),this.handles[e]=".ui-resizable-"+e,this.element.append(o);this._renderAxis=function(e){var i,s,n,o;e=e||this.element;for(i in this.handles)this.handles[i].constructor===String?this.handles[i]=this.element.children(this.handles[i]).first().show():(this.handles[i].jquery||this.handles[i].nodeType)&&(this.handles[i]=t(this.handles[i]),this._on(this.handles[i],{mousedown:r._mouseDown})),this.elementIsWrapper&&this.originalElement[0].nodeName.match(/^(textarea|input|select|button)$/i)&&(s=t(this.handles[i],this.element),o=/sw|ne|nw|se|n|s/.test(i)?s.outerHeight():s.outerWidth(),n=["padding",/ne|nw|n/.test(i)?"Top":/se|sw|s/.test(i)?"Bottom":/^e$/.test(i)?"Right":"Left"].join(""),e.css(n,o),this._proportionallyResize()),this._handles=this._handles.add(this.handles[i])},this._renderAxis(this.element),this._handles=this._handles.add(this.element.find(".ui-resizable-handle")),this._handles.disableSelection(),this._handles.on("mouseover",function(){r.resizing||(this.className&&(o=this.className.match(/ui-resizable-(se|sw|ne|nw|n|e|s|w)/i)),r.axis=o&&o[1]?o[1]:"se")}),a.autoHide&&(this._handles.hide(),this._addClass("ui-resizable-autohide"))},_removeHandles:function(){this._handles.remove()},_mouseCapture:function(e){var i,s,n=!1;for(i in this.handles)s=t(this.handles[i])[0],(s===e.target||t.contains(s,e.target))&&(n=!0);return!this.options.disabled&&n},_mouseStart:function(e){var i,s,n,o=this.options,a=this.element;return this.resizing=!0,this._renderProxy(),i=this._num(this.helper.css("left")),s=this._num(this.helper.css("top")),o.containment&&(i+=t(o.containment).scrollLeft()||0,s+=t(o.containment).scrollTop()||0),this.offset=this.helper.offset(),this.position={left:i,top:s},this.size=this._helper?{width:this.helper.width(),height:this.helper.height()}:{width:a.width(),height:a.height()},this.originalSize=this._helper?{width:a.outerWidth(),height:a.outerHeight()}:{width:a.width(),height:a.height()},this.sizeDiff={width:a.outerWidth()-a.width(),height:a.outerHeight()-a.height()},this.originalPosition={left:i,top:s},this.originalMousePosition={left:e.pageX,top:e.pageY},this.aspectRatio="number"==typeof o.aspectRatio?o.aspectRatio:this.originalSize.width/this.originalSize.height||1,n=t(".ui-resizable-"+this.axis).css("cursor"),t("body").css("cursor","auto"===n?this.axis+"-resize":n),this._addClass("ui-resizable-resizing"),this._propagate("start",e),!0},_mouseDrag:function(e){var i,s,n=this.originalMousePosition,o=this.axis,a=e.pageX-n.left||0,r=e.pageY-n.top||0,h=this._change[o];return this._updatePrevProperties(),h?(i=h.apply(this,[e,a,r]),this._updateVirtualBoundaries(e.shiftKey),(this._aspectRatio||e.shiftKey)&&(i=this._updateRatio(i,e)),i=this._respectSize(i,e),this._updateCache(i),this._propagate("resize",e),s=this._applyChanges(),!this._helper&&this._proportionallyResizeElements.length&&this._proportionallyResize(),t.isEmptyObject(s)||(this._updatePrevProperties(),this._trigger("resize",e,this.ui()),this._applyChanges()),!1):!1},_mouseStop:function(e){this.resizing=!1;var i,s,n,o,a,r,h,l=this.options,c=this;return this._helper&&(i=this._proportionallyResizeElements,s=i.length&&/textarea/i.test(i[0].nodeName),n=s&&this._hasScroll(i[0],"left")?0:c.sizeDiff.height,o=s?0:c.sizeDiff.width,a={width:c.helper.width()-o,height:c.helper.height()-n},r=parseFloat(c.element.css("left"))+(c.position.left-c.originalPosition.left)||null,h=parseFloat(c.element.css("top"))+(c.position.top-c.originalPosition.top)||null,l.animate||this.element.css(t.extend(a,{top:h,left:r})),c.helper.height(c.size.height),c.helper.width(c.size.width),this._helper&&!l.animate&&this._proportionallyResize()),t("body").css("cursor","auto"),this._removeClass("ui-resizable-resizing"),this._propagate("stop",e),this._helper&&this.helper.remove(),!1},_updatePrevProperties:function(){this.prevPosition={top:this.position.top,left:this.position.left},this.prevSize={width:this.size.width,height:this.size.height}},_applyChanges:function(){var t={};return this.position.top!==this.prevPosition.top&&(t.top=this.position.top+"px"),this.position.left!==this.prevPosition.left&&(t.left=this.position.left+"px"),this.size.width!==this.prevSize.width&&(t.width=this.size.width+"px"),this.size.height!==this.prevSize.height&&(t.height=this.size.height+"px"),this.helper.css(t),t},_updateVirtualBoundaries:function(t){var e,i,s,n,o,a=this.options;o={minWidth:this._isNumber(a.minWidth)?a.minWidth:0,maxWidth:this._isNumber(a.maxWidth)?a.maxWidth:1/0,minHeight:this._isNumber(a.minHeight)?a.minHeight:0,maxHeight:this._isNumber(a.maxHeight)?a.maxHeight:1/0},(this._aspectRatio||t)&&(e=o.minHeight*this.aspectRatio,s=o.minWidth/this.aspectRatio,i=o.maxHeight*this.aspectRatio,n=o.maxWidth/this.aspectRatio,e>o.minWidth&&(o.minWidth=e),s>o.minHeight&&(o.minHeight=s),o.maxWidth>i&&(o.maxWidth=i),o.maxHeight>n&&(o.maxHeight=n)),this._vBoundaries=o},_updateCache:function(t){this.offset=this.helper.offset(),this._isNumber(t.left)&&(this.position.left=t.left),this._isNumber(t.top)&&(this.position.top=t.top),this._isNumber(t.height)&&(this.size.height=t.height),this._isNumber(t.width)&&(this.size.width=t.width)},_updateRatio:function(t){var e=this.position,i=this.size,s=this.axis;return this._isNumber(t.height)?t.width=t.height*this.aspectRatio:this._isNumber(t.width)&&(t.height=t.width/this.aspectRatio),"sw"===s&&(t.left=e.left+(i.width-t.width),t.top=null),"nw"===s&&(t.top=e.top+(i.height-t.height),t.left=e.left+(i.width-t.width)),t},_respectSize:function(t){var e=this._vBoundaries,i=this.axis,s=this._isNumber(t.width)&&e.maxWidth&&e.maxWidth<t.width,n=this._isNumber(t.height)&&e.maxHeight&&e.maxHeight<t.height,o=this._isNumber(t.width)&&e.minWidth&&e.minWidth>t.width,a=this._isNumber(t.height)&&e.minHeight&&e.minHeight>t.height,r=this.originalPosition.left+this.originalSize.width,h=this.originalPosition.top+this.originalSize.height,l=/sw|nw|w/.test(i),c=/nw|ne|n/.test(i);return o&&(t.width=e.minWidth),a&&(t.height=e.minHeight),s&&(t.width=e.maxWidth),n&&(t.height=e.maxHeight),o&&l&&(t.left=r-e.minWidth),s&&l&&(t.left=r-e.maxWidth),a&&c&&(t.top=h-e.minHeight),n&&c&&(t.top=h-e.maxHeight),t.width||t.height||t.left||!t.top?t.width||t.height||t.top||!t.left||(t.left=null):t.top=null,t},_getPaddingPlusBorderDimensions:function(t){for(var e=0,i=[],s=[t.css("borderTopWidth"),t.css("borderRightWidth"),t.css("borderBottomWidth"),t.css("borderLeftWidth")],n=[t.css("paddingTop"),t.css("paddingRight"),t.css("paddingBottom"),t.css("paddingLeft")];4>e;e++)i[e]=parseFloat(s[e])||0,i[e]+=parseFloat(n[e])||0;return{height:i[0]+i[2],width:i[1]+i[3]}},_proportionallyResize:function(){if(this._proportionallyResizeElements.length)for(var t,e=0,i=this.helper||this.element;this._proportionallyResizeElements.length>e;e++)t=this._proportionallyResizeElements[e],this.outerDimensions||(this.outerDimensions=this._getPaddingPlusBorderDimensions(t)),t.css({height:i.height()-this.outerDimensions.height||0,width:i.width()-this.outerDimensions.width||0})},_renderProxy:function(){var e=this.element,i=this.options;this.elementOffset=e.offset(),this._helper?(this.helper=this.helper||t("<div style='overflow:hidden;'></div>"),this._addClass(this.helper,this._helper),this.helper.css({width:this.element.outerWidth(),height:this.element.outerHeight(),position:"absolute",left:this.elementOffset.left+"px",top:this.elementOffset.top+"px",zIndex:++i.zIndex}),this.helper.appendTo("body").disableSelection()):this.helper=this.element},_change:{e:function(t,e){return{width:this.originalSize.width+e}},w:function(t,e){var i=this.originalSize,s=this.originalPosition;return{left:s.left+e,width:i.width-e}},n:function(t,e,i){var s=this.originalSize,n=this.originalPosition;return{top:n.top+i,height:s.height-i}},s:function(t,e,i){return{height:this.originalSize.height+i}},se:function(e,i,s){return t.extend(this._change.s.apply(this,arguments),this._change.e.apply(this,[e,i,s]))},sw:function(e,i,s){return t.extend(this._change.s.apply(this,arguments),this._change.w.apply(this,[e,i,s]))},ne:function(e,i,s){return t.extend(this._change.n.apply(this,arguments),this._change.e.apply(this,[e,i,s]))},nw:function(e,i,s){return t.extend(this._change.n.apply(this,arguments),this._change.w.apply(this,[e,i,s]))}},_propagate:function(e,i){t.ui.plugin.call(this,e,[i,this.ui()]),"resize"!==e&&this._trigger(e,i,this.ui())},plugins:{},ui:function(){return{originalElement:this.originalElement,element:this.element,helper:this.helper,position:this.position,size:this.size,originalSize:this.originalSize,originalPosition:this.originalPosition}}}),t.ui.plugin.add("resizable","animate",{stop:function(e){var i=t(this).resizable("instance"),s=i.options,n=i._proportionallyResizeElements,o=n.length&&/textarea/i.test(n[0].nodeName),a=o&&i._hasScroll(n[0],"left")?0:i.sizeDiff.height,r=o?0:i.sizeDiff.width,h={width:i.size.width-r,height:i.size.height-a},l=parseFloat(i.element.css("left"))+(i.position.left-i.originalPosition.left)||null,c=parseFloat(i.element.css("top"))+(i.position.top-i.originalPosition.top)||null;i.element.animate(t.extend(h,c&&l?{top:c,left:l}:{}),{duration:s.animateDuration,easing:s.animateEasing,step:function(){var s={width:parseFloat(i.element.css("width")),height:parseFloat(i.element.css("height")),top:parseFloat(i.element.css("top")),left:parseFloat(i.element.css("left"))};n&&n.length&&t(n[0]).css({width:s.width,height:s.height}),i._updateCache(s),i._propagate("resize",e)}})}}),t.ui.plugin.add("resizable","containment",{start:function(){var e,i,s,n,o,a,r,h=t(this).resizable("instance"),l=h.options,c=h.element,u=l.containment,d=u instanceof t?u.get(0):/parent/.test(u)?c.parent().get(0):u;d&&(h.containerElement=t(d),/document/.test(u)||u===document?(h.containerOffset={left:0,top:0},h.containerPosition={left:0,top:0},h.parentData={element:t(document),left:0,top:0,width:t(document).width(),height:t(document).height()||document.body.parentNode.scrollHeight}):(e=t(d),i=[],t(["Top","Right","Left","Bottom"]).each(function(t,s){i[t]=h._num(e.css("padding"+s))}),h.containerOffset=e.offset(),h.containerPosition=e.position(),h.containerSize={height:e.innerHeight()-i[3],width:e.innerWidth()-i[1]},s=h.containerOffset,n=h.containerSize.height,o=h.containerSize.width,a=h._hasScroll(d,"left")?d.scrollWidth:o,r=h._hasScroll(d)?d.scrollHeight:n,h.parentData={element:d,left:s.left,top:s.top,width:a,height:r}))},resize:function(e){var i,s,n,o,a=t(this).resizable("instance"),r=a.options,h=a.containerOffset,l=a.position,c=a._aspectRatio||e.shiftKey,u={top:0,left:0},d=a.containerElement,p=!0;d[0]!==document&&/static/.test(d.css("position"))&&(u=h),l.left<(a._helper?h.left:0)&&(a.size.width=a.size.width+(a._helper?a.position.left-h.left:a.position.left-u.left),c&&(a.size.height=a.size.width/a.aspectRatio,p=!1),a.position.left=r.helper?h.left:0),l.top<(a._helper?h.top:0)&&(a.size.height=a.size.height+(a._helper?a.position.top-h.top:a.position.top),c&&(a.size.width=a.size.height*a.aspectRatio,p=!1),a.position.top=a._helper?h.top:0),n=a.containerElement.get(0)===a.element.parent().get(0),o=/relative|absolute/.test(a.containerElement.css("position")),n&&o?(a.offset.left=a.parentData.left+a.position.left,a.offset.top=a.parentData.top+a.position.top):(a.offset.left=a.element.offset().left,a.offset.top=a.element.offset().top),i=Math.abs(a.sizeDiff.width+(a._helper?a.offset.left-u.left:a.offset.left-h.left)),s=Math.abs(a.sizeDiff.height+(a._helper?a.offset.top-u.top:a.offset.top-h.top)),i+a.size.width>=a.parentData.width&&(a.size.width=a.parentData.width-i,c&&(a.size.height=a.size.width/a.aspectRatio,p=!1)),s+a.size.height>=a.parentData.height&&(a.size.height=a.parentData.height-s,c&&(a.size.width=a.size.height*a.aspectRatio,p=!1)),p||(a.position.left=a.prevPosition.left,a.position.top=a.prevPosition.top,a.size.width=a.prevSize.width,a.size.height=a.prevSize.height)},stop:function(){var e=t(this).resizable("instance"),i=e.options,s=e.containerOffset,n=e.containerPosition,o=e.containerElement,a=t(e.helper),r=a.offset(),h=a.outerWidth()-e.sizeDiff.width,l=a.outerHeight()-e.sizeDiff.height;e._helper&&!i.animate&&/relative/.test(o.css("position"))&&t(this).css({left:r.left-n.left-s.left,width:h,height:l}),e._helper&&!i.animate&&/static/.test(o.css("position"))&&t(this).css({left:r.left-n.left-s.left,width:h,height:l})}}),t.ui.plugin.add("resizable","alsoResize",{start:function(){var e=t(this).resizable("instance"),i=e.options;t(i.alsoResize).each(function(){var e=t(this);e.data("ui-resizable-alsoresize",{width:parseFloat(e.width()),height:parseFloat(e.height()),left:parseFloat(e.css("left")),top:parseFloat(e.css("top"))})})},resize:function(e,i){var s=t(this).resizable("instance"),n=s.options,o=s.originalSize,a=s.originalPosition,r={height:s.size.height-o.height||0,width:s.size.width-o.width||0,top:s.position.top-a.top||0,left:s.position.left-a.left||0};t(n.alsoResize).each(function(){var e=t(this),s=t(this).data("ui-resizable-alsoresize"),n={},o=e.parents(i.originalElement[0]).length?["width","height"]:["width","height","top","left"];t.each(o,function(t,e){var i=(s[e]||0)+(r[e]||0);i&&i>=0&&(n[e]=i||null)}),e.css(n)})},stop:function(){t(this).removeData("ui-resizable-alsoresize")}}),t.ui.plugin.add("resizable","ghost",{start:function(){var e=t(this).resizable("instance"),i=e.size;e.ghost=e.originalElement.clone(),e.ghost.css({opacity:.25,display:"block",position:"relative",height:i.height,width:i.width,margin:0,left:0,top:0}),e._addClass(e.ghost,"ui-resizable-ghost"),t.uiBackCompat!==!1&&"string"==typeof e.options.ghost&&e.ghost.addClass(this.options.ghost),e.ghost.appendTo(e.helper)},resize:function(){var e=t(this).resizable("instance");e.ghost&&e.ghost.css({position:"relative",height:e.size.height,width:e.size.width})},stop:function(){var e=t(this).resizable("instance");e.ghost&&e.helper&&e.helper.get(0).removeChild(e.ghost.get(0))}}),t.ui.plugin.add("resizable","grid",{resize:function(){var e,i=t(this).resizable("instance"),s=i.options,n=i.size,o=i.originalSize,a=i.originalPosition,r=i.axis,h="number"==typeof s.grid?[s.grid,s.grid]:s.grid,l=h[0]||1,c=h[1]||1,u=Math.round((n.width-o.width)/l)*l,d=Math.round((n.height-o.height)/c)*c,p=o.width+u,f=o.height+d,g=s.maxWidth&&p>s.maxWidth,m=s.maxHeight&&f>s.maxHeight,_=s.minWidth&&s.minWidth>p,v=s.minHeight&&s.minHeight>f;s.grid=h,_&&(p+=l),v&&(f+=c),g&&(p-=l),m&&(f-=c),/^(se|s|e)$/.test(r)?(i.size.width=p,i.size.height=f):/^(ne)$/.test(r)?(i.size.width=p,i.size.height=f,i.position.top=a.top-d):/^(sw)$/.test(r)?(i.size.width=p,i.size.height=f,i.position.left=a.left-u):((0>=f-c||0>=p-l)&&(e=i._getPaddingPlusBorderDimensions(this)),f-c>0?(i.size.height=f,i.position.top=a.top-d):(f=c-e.height,i.size.height=f,i.position.top=a.top+o.height-f),p-l>0?(i.size.width=p,i.position.left=a.left-u):(p=l-e.width,i.size.width=p,i.position.left=a.left+o.width-p))}}),t.ui.resizable,t.widget("ui.dialog",{version:"1.12.1",options:{appendTo:"body",autoOpen:!0,buttons:[],classes:{"ui-dialog":"ui-corner-all","ui-dialog-titlebar":"ui-corner-all"},closeOnEscape:!0,closeText:"Close",draggable:!0,hide:null,height:"auto",maxHeight:null,maxWidth:null,minHeight:150,minWidth:150,modal:!1,position:{my:"center",at:"center",of:window,collision:"fit",using:function(e){var i=t(this).css(e).offset().top;0>i&&t(this).css("top",e.top-i)}},resizable:!0,show:null,title:null,width:300,beforeClose:null,close:null,drag:null,dragStart:null,dragStop:null,focus:null,open:null,resize:null,resizeStart:null,resizeStop:null},sizeRelatedOptions:{buttons:!0,height:!0,maxHeight:!0,maxWidth:!0,minHeight:!0,minWidth:!0,width:!0},resizableRelatedOptions:{maxHeight:!0,maxWidth:!0,minHeight:!0,minWidth:!0},_create:function(){this.originalCss={display:this.element[0].style.display,width:this.element[0].style.width,minHeight:this.element[0].style.minHeight,maxHeight:this.element[0].style.maxHeight,height:this.element[0].style.height},this.originalPosition={parent:this.element.parent(),index:this.element.parent().children().index(this.element)},this.originalTitle=this.element.attr("title"),null==this.options.title&&null!=this.originalTitle&&(this.options.title=this.originalTitle),this.options.disabled&&(this.options.disabled=!1),this._createWrapper(),this.element.show().removeAttr("title").appendTo(this.uiDialog),this._addClass("ui-dialog-content","ui-widget-content"),this._createTitlebar(),this._createButtonPane(),this.options.draggable&&t.fn.draggable&&this._makeDraggable(),this.options.resizable&&t.fn.resizable&&this._makeResizable(),this._isOpen=!1,this._trackFocus()},_init:function(){this.options.autoOpen&&this.open()},_appendTo:function(){var e=this.options.appendTo;return e&&(e.jquery||e.nodeType)?t(e):this.document.find(e||"body").eq(0)},_destroy:function(){var t,e=this.originalPosition;this._untrackInstance(),this._destroyOverlay(),this.element.removeUniqueId().css(this.originalCss).detach(),this.uiDialog.remove(),this.originalTitle&&this.element.attr("title",this.originalTitle),t=e.parent.children().eq(e.index),t.length&&t[0]!==this.element[0]?t.before(this.element):e.parent.append(this.element)},widget:function(){return this.uiDialog
-},disable:t.noop,enable:t.noop,close:function(e){var i=this;this._isOpen&&this._trigger("beforeClose",e)!==!1&&(this._isOpen=!1,this._focusedElement=null,this._destroyOverlay(),this._untrackInstance(),this.opener.filter(":focusable").trigger("focus").length||t.ui.safeBlur(t.ui.safeActiveElement(this.document[0])),this._hide(this.uiDialog,this.options.hide,function(){i._trigger("close",e)}))},isOpen:function(){return this._isOpen},moveToTop:function(){this._moveToTop()},_moveToTop:function(e,i){var s=!1,n=this.uiDialog.siblings(".ui-front:visible").map(function(){return+t(this).css("z-index")}).get(),o=Math.max.apply(null,n);return o>=+this.uiDialog.css("z-index")&&(this.uiDialog.css("z-index",o+1),s=!0),s&&!i&&this._trigger("focus",e),s},open:function(){var e=this;return this._isOpen?(this._moveToTop()&&this._focusTabbable(),void 0):(this._isOpen=!0,this.opener=t(t.ui.safeActiveElement(this.document[0])),this._size(),this._position(),this._createOverlay(),this._moveToTop(null,!0),this.overlay&&this.overlay.css("z-index",this.uiDialog.css("z-index")-1),this._show(this.uiDialog,this.options.show,function(){e._focusTabbable(),e._trigger("focus")}),this._makeFocusTarget(),this._trigger("open"),void 0)},_focusTabbable:function(){var t=this._focusedElement;t||(t=this.element.find("[autofocus]")),t.length||(t=this.element.find(":tabbable")),t.length||(t=this.uiDialogButtonPane.find(":tabbable")),t.length||(t=this.uiDialogTitlebarClose.filter(":tabbable")),t.length||(t=this.uiDialog),t.eq(0).trigger("focus")},_keepFocus:function(e){function i(){var e=t.ui.safeActiveElement(this.document[0]),i=this.uiDialog[0]===e||t.contains(this.uiDialog[0],e);i||this._focusTabbable()}e.preventDefault(),i.call(this),this._delay(i)},_createWrapper:function(){this.uiDialog=t("<div>").hide().attr({tabIndex:-1,role:"dialog"}).appendTo(this._appendTo()),this._addClass(this.uiDialog,"ui-dialog","ui-widget ui-widget-content ui-front"),this._on(this.uiDialog,{keydown:function(e){if(this.options.closeOnEscape&&!e.isDefaultPrevented()&&e.keyCode&&e.keyCode===t.ui.keyCode.ESCAPE)return e.preventDefault(),this.close(e),void 0;if(e.keyCode===t.ui.keyCode.TAB&&!e.isDefaultPrevented()){var i=this.uiDialog.find(":tabbable"),s=i.filter(":first"),n=i.filter(":last");e.target!==n[0]&&e.target!==this.uiDialog[0]||e.shiftKey?e.target!==s[0]&&e.target!==this.uiDialog[0]||!e.shiftKey||(this._delay(function(){n.trigger("focus")}),e.preventDefault()):(this._delay(function(){s.trigger("focus")}),e.preventDefault())}},mousedown:function(t){this._moveToTop(t)&&this._focusTabbable()}}),this.element.find("[aria-describedby]").length||this.uiDialog.attr({"aria-describedby":this.element.uniqueId().attr("id")})},_createTitlebar:function(){var e;this.uiDialogTitlebar=t("<div>"),this._addClass(this.uiDialogTitlebar,"ui-dialog-titlebar","ui-widget-header ui-helper-clearfix"),this._on(this.uiDialogTitlebar,{mousedown:function(e){t(e.target).closest(".ui-dialog-titlebar-close")||this.uiDialog.trigger("focus")}}),this.uiDialogTitlebarClose=t("<button type='button'></button>").button({label:t("<a>").text(this.options.closeText).html(),icon:"ui-icon-closethick",showLabel:!1}).appendTo(this.uiDialogTitlebar),this._addClass(this.uiDialogTitlebarClose,"ui-dialog-titlebar-close"),this._on(this.uiDialogTitlebarClose,{click:function(t){t.preventDefault(),this.close(t)}}),e=t("<span>").uniqueId().prependTo(this.uiDialogTitlebar),this._addClass(e,"ui-dialog-title"),this._title(e),this.uiDialogTitlebar.prependTo(this.uiDialog),this.uiDialog.attr({"aria-labelledby":e.attr("id")})},_title:function(t){this.options.title?t.text(this.options.title):t.html("&#160;")},_createButtonPane:function(){this.uiDialogButtonPane=t("<div>"),this._addClass(this.uiDialogButtonPane,"ui-dialog-buttonpane","ui-widget-content ui-helper-clearfix"),this.uiButtonSet=t("<div>").appendTo(this.uiDialogButtonPane),this._addClass(this.uiButtonSet,"ui-dialog-buttonset"),this._createButtons()},_createButtons:function(){var e=this,i=this.options.buttons;return this.uiDialogButtonPane.remove(),this.uiButtonSet.empty(),t.isEmptyObject(i)||t.isArray(i)&&!i.length?(this._removeClass(this.uiDialog,"ui-dialog-buttons"),void 0):(t.each(i,function(i,s){var n,o;s=t.isFunction(s)?{click:s,text:i}:s,s=t.extend({type:"button"},s),n=s.click,o={icon:s.icon,iconPosition:s.iconPosition,showLabel:s.showLabel,icons:s.icons,text:s.text},delete s.click,delete s.icon,delete s.iconPosition,delete s.showLabel,delete s.icons,"boolean"==typeof s.text&&delete s.text,t("<button></button>",s).button(o).appendTo(e.uiButtonSet).on("click",function(){n.apply(e.element[0],arguments)})}),this._addClass(this.uiDialog,"ui-dialog-buttons"),this.uiDialogButtonPane.appendTo(this.uiDialog),void 0)},_makeDraggable:function(){function e(t){return{position:t.position,offset:t.offset}}var i=this,s=this.options;this.uiDialog.draggable({cancel:".ui-dialog-content, .ui-dialog-titlebar-close",handle:".ui-dialog-titlebar",containment:"document",start:function(s,n){i._addClass(t(this),"ui-dialog-dragging"),i._blockFrames(),i._trigger("dragStart",s,e(n))},drag:function(t,s){i._trigger("drag",t,e(s))},stop:function(n,o){var a=o.offset.left-i.document.scrollLeft(),r=o.offset.top-i.document.scrollTop();s.position={my:"left top",at:"left"+(a>=0?"+":"")+a+" "+"top"+(r>=0?"+":"")+r,of:i.window},i._removeClass(t(this),"ui-dialog-dragging"),i._unblockFrames(),i._trigger("dragStop",n,e(o))}})},_makeResizable:function(){function e(t){return{originalPosition:t.originalPosition,originalSize:t.originalSize,position:t.position,size:t.size}}var i=this,s=this.options,n=s.resizable,o=this.uiDialog.css("position"),a="string"==typeof n?n:"n,e,s,w,se,sw,ne,nw";this.uiDialog.resizable({cancel:".ui-dialog-content",containment:"document",alsoResize:this.element,maxWidth:s.maxWidth,maxHeight:s.maxHeight,minWidth:s.minWidth,minHeight:this._minHeight(),handles:a,start:function(s,n){i._addClass(t(this),"ui-dialog-resizing"),i._blockFrames(),i._trigger("resizeStart",s,e(n))},resize:function(t,s){i._trigger("resize",t,e(s))},stop:function(n,o){var a=i.uiDialog.offset(),r=a.left-i.document.scrollLeft(),h=a.top-i.document.scrollTop();s.height=i.uiDialog.height(),s.width=i.uiDialog.width(),s.position={my:"left top",at:"left"+(r>=0?"+":"")+r+" "+"top"+(h>=0?"+":"")+h,of:i.window},i._removeClass(t(this),"ui-dialog-resizing"),i._unblockFrames(),i._trigger("resizeStop",n,e(o))}}).css("position",o)},_trackFocus:function(){this._on(this.widget(),{focusin:function(e){this._makeFocusTarget(),this._focusedElement=t(e.target)}})},_makeFocusTarget:function(){this._untrackInstance(),this._trackingInstances().unshift(this)},_untrackInstance:function(){var e=this._trackingInstances(),i=t.inArray(this,e);-1!==i&&e.splice(i,1)},_trackingInstances:function(){var t=this.document.data("ui-dialog-instances");return t||(t=[],this.document.data("ui-dialog-instances",t)),t},_minHeight:function(){var t=this.options;return"auto"===t.height?t.minHeight:Math.min(t.minHeight,t.height)},_position:function(){var t=this.uiDialog.is(":visible");t||this.uiDialog.show(),this.uiDialog.position(this.options.position),t||this.uiDialog.hide()},_setOptions:function(e){var i=this,s=!1,n={};t.each(e,function(t,e){i._setOption(t,e),t in i.sizeRelatedOptions&&(s=!0),t in i.resizableRelatedOptions&&(n[t]=e)}),s&&(this._size(),this._position()),this.uiDialog.is(":data(ui-resizable)")&&this.uiDialog.resizable("option",n)},_setOption:function(e,i){var s,n,o=this.uiDialog;"disabled"!==e&&(this._super(e,i),"appendTo"===e&&this.uiDialog.appendTo(this._appendTo()),"buttons"===e&&this._createButtons(),"closeText"===e&&this.uiDialogTitlebarClose.button({label:t("<a>").text(""+this.options.closeText).html()}),"draggable"===e&&(s=o.is(":data(ui-draggable)"),s&&!i&&o.draggable("destroy"),!s&&i&&this._makeDraggable()),"position"===e&&this._position(),"resizable"===e&&(n=o.is(":data(ui-resizable)"),n&&!i&&o.resizable("destroy"),n&&"string"==typeof i&&o.resizable("option","handles",i),n||i===!1||this._makeResizable()),"title"===e&&this._title(this.uiDialogTitlebar.find(".ui-dialog-title")))},_size:function(){var t,e,i,s=this.options;this.element.show().css({width:"auto",minHeight:0,maxHeight:"none",height:0}),s.minWidth>s.width&&(s.width=s.minWidth),t=this.uiDialog.css({height:"auto",width:s.width}).outerHeight(),e=Math.max(0,s.minHeight-t),i="number"==typeof s.maxHeight?Math.max(0,s.maxHeight-t):"none","auto"===s.height?this.element.css({minHeight:e,maxHeight:i,height:"auto"}):this.element.height(Math.max(0,s.height-t)),this.uiDialog.is(":data(ui-resizable)")&&this.uiDialog.resizable("option","minHeight",this._minHeight())},_blockFrames:function(){this.iframeBlocks=this.document.find("iframe").map(function(){var e=t(this);return t("<div>").css({position:"absolute",width:e.outerWidth(),height:e.outerHeight()}).appendTo(e.parent()).offset(e.offset())[0]})},_unblockFrames:function(){this.iframeBlocks&&(this.iframeBlocks.remove(),delete this.iframeBlocks)},_allowInteraction:function(e){return t(e.target).closest(".ui-dialog").length?!0:!!t(e.target).closest(".ui-datepicker").length},_createOverlay:function(){if(this.options.modal){var e=!0;this._delay(function(){e=!1}),this.document.data("ui-dialog-overlays")||this._on(this.document,{focusin:function(t){e||this._allowInteraction(t)||(t.preventDefault(),this._trackingInstances()[0]._focusTabbable())}}),this.overlay=t("<div>").appendTo(this._appendTo()),this._addClass(this.overlay,null,"ui-widget-overlay ui-front"),this._on(this.overlay,{mousedown:"_keepFocus"}),this.document.data("ui-dialog-overlays",(this.document.data("ui-dialog-overlays")||0)+1)}},_destroyOverlay:function(){if(this.options.modal&&this.overlay){var t=this.document.data("ui-dialog-overlays")-1;t?this.document.data("ui-dialog-overlays",t):(this._off(this.document,"focusin"),this.document.removeData("ui-dialog-overlays")),this.overlay.remove(),this.overlay=null}}}),t.uiBackCompat!==!1&&t.widget("ui.dialog",t.ui.dialog,{options:{dialogClass:""},_createWrapper:function(){this._super(),this.uiDialog.addClass(this.options.dialogClass)},_setOption:function(t,e){"dialogClass"===t&&this.uiDialog.removeClass(this.options.dialogClass).addClass(e),this._superApply(arguments)}}),t.ui.dialog,t.widget("ui.droppable",{version:"1.12.1",widgetEventPrefix:"drop",options:{accept:"*",addClasses:!0,greedy:!1,scope:"default",tolerance:"intersect",activate:null,deactivate:null,drop:null,out:null,over:null},_create:function(){var e,i=this.options,s=i.accept;this.isover=!1,this.isout=!0,this.accept=t.isFunction(s)?s:function(t){return t.is(s)},this.proportions=function(){return arguments.length?(e=arguments[0],void 0):e?e:e={width:this.element[0].offsetWidth,height:this.element[0].offsetHeight}},this._addToManager(i.scope),i.addClasses&&this._addClass("ui-droppable")},_addToManager:function(e){t.ui.ddmanager.droppables[e]=t.ui.ddmanager.droppables[e]||[],t.ui.ddmanager.droppables[e].push(this)},_splice:function(t){for(var e=0;t.length>e;e++)t[e]===this&&t.splice(e,1)},_destroy:function(){var e=t.ui.ddmanager.droppables[this.options.scope];this._splice(e)},_setOption:function(e,i){if("accept"===e)this.accept=t.isFunction(i)?i:function(t){return t.is(i)};else if("scope"===e){var s=t.ui.ddmanager.droppables[this.options.scope];this._splice(s),this._addToManager(i)}this._super(e,i)},_activate:function(e){var i=t.ui.ddmanager.current;this._addActiveClass(),i&&this._trigger("activate",e,this.ui(i))},_deactivate:function(e){var i=t.ui.ddmanager.current;this._removeActiveClass(),i&&this._trigger("deactivate",e,this.ui(i))},_over:function(e){var i=t.ui.ddmanager.current;i&&(i.currentItem||i.element)[0]!==this.element[0]&&this.accept.call(this.element[0],i.currentItem||i.element)&&(this._addHoverClass(),this._trigger("over",e,this.ui(i)))},_out:function(e){var i=t.ui.ddmanager.current;i&&(i.currentItem||i.element)[0]!==this.element[0]&&this.accept.call(this.element[0],i.currentItem||i.element)&&(this._removeHoverClass(),this._trigger("out",e,this.ui(i)))},_drop:function(e,i){var s=i||t.ui.ddmanager.current,n=!1;return s&&(s.currentItem||s.element)[0]!==this.element[0]?(this.element.find(":data(ui-droppable)").not(".ui-draggable-dragging").each(function(){var i=t(this).droppable("instance");return i.options.greedy&&!i.options.disabled&&i.options.scope===s.options.scope&&i.accept.call(i.element[0],s.currentItem||s.element)&&v(s,t.extend(i,{offset:i.element.offset()}),i.options.tolerance,e)?(n=!0,!1):void 0}),n?!1:this.accept.call(this.element[0],s.currentItem||s.element)?(this._removeActiveClass(),this._removeHoverClass(),this._trigger("drop",e,this.ui(s)),this.element):!1):!1},ui:function(t){return{draggable:t.currentItem||t.element,helper:t.helper,position:t.position,offset:t.positionAbs}},_addHoverClass:function(){this._addClass("ui-droppable-hover")},_removeHoverClass:function(){this._removeClass("ui-droppable-hover")},_addActiveClass:function(){this._addClass("ui-droppable-active")},_removeActiveClass:function(){this._removeClass("ui-droppable-active")}});var v=t.ui.intersect=function(){function t(t,e,i){return t>=e&&e+i>t}return function(e,i,s,n){if(!i.offset)return!1;var o=(e.positionAbs||e.position.absolute).left+e.margins.left,a=(e.positionAbs||e.position.absolute).top+e.margins.top,r=o+e.helperProportions.width,h=a+e.helperProportions.height,l=i.offset.left,c=i.offset.top,u=l+i.proportions().width,d=c+i.proportions().height;switch(s){case"fit":return o>=l&&u>=r&&a>=c&&d>=h;case"intersect":return o+e.helperProportions.width/2>l&&u>r-e.helperProportions.width/2&&a+e.helperProportions.height/2>c&&d>h-e.helperProportions.height/2;case"pointer":return t(n.pageY,c,i.proportions().height)&&t(n.pageX,l,i.proportions().width);case"touch":return(a>=c&&d>=a||h>=c&&d>=h||c>a&&h>d)&&(o>=l&&u>=o||r>=l&&u>=r||l>o&&r>u);default:return!1}}}();t.ui.ddmanager={current:null,droppables:{"default":[]},prepareOffsets:function(e,i){var s,n,o=t.ui.ddmanager.droppables[e.options.scope]||[],a=i?i.type:null,r=(e.currentItem||e.element).find(":data(ui-droppable)").addBack();t:for(s=0;o.length>s;s++)if(!(o[s].options.disabled||e&&!o[s].accept.call(o[s].element[0],e.currentItem||e.element))){for(n=0;r.length>n;n++)if(r[n]===o[s].element[0]){o[s].proportions().height=0;continue t}o[s].visible="none"!==o[s].element.css("display"),o[s].visible&&("mousedown"===a&&o[s]._activate.call(o[s],i),o[s].offset=o[s].element.offset(),o[s].proportions({width:o[s].element[0].offsetWidth,height:o[s].element[0].offsetHeight}))}},drop:function(e,i){var s=!1;return t.each((t.ui.ddmanager.droppables[e.options.scope]||[]).slice(),function(){this.options&&(!this.options.disabled&&this.visible&&v(e,this,this.options.tolerance,i)&&(s=this._drop.call(this,i)||s),!this.options.disabled&&this.visible&&this.accept.call(this.element[0],e.currentItem||e.element)&&(this.isout=!0,this.isover=!1,this._deactivate.call(this,i)))}),s},dragStart:function(e,i){e.element.parentsUntil("body").on("scroll.droppable",function(){e.options.refreshPositions||t.ui.ddmanager.prepareOffsets(e,i)})},drag:function(e,i){e.options.refreshPositions&&t.ui.ddmanager.prepareOffsets(e,i),t.each(t.ui.ddmanager.droppables[e.options.scope]||[],function(){if(!this.options.disabled&&!this.greedyChild&&this.visible){var s,n,o,a=v(e,this,this.options.tolerance,i),r=!a&&this.isover?"isout":a&&!this.isover?"isover":null;r&&(this.options.greedy&&(n=this.options.scope,o=this.element.parents(":data(ui-droppable)").filter(function(){return t(this).droppable("instance").options.scope===n}),o.length&&(s=t(o[0]).droppable("instance"),s.greedyChild="isover"===r)),s&&"isover"===r&&(s.isover=!1,s.isout=!0,s._out.call(s,i)),this[r]=!0,this["isout"===r?"isover":"isout"]=!1,this["isover"===r?"_over":"_out"].call(this,i),s&&"isout"===r&&(s.isout=!1,s.isover=!0,s._over.call(s,i)))}})},dragStop:function(e,i){e.element.parentsUntil("body").off("scroll.droppable"),e.options.refreshPositions||t.ui.ddmanager.prepareOffsets(e,i)}},t.uiBackCompat!==!1&&t.widget("ui.droppable",t.ui.droppable,{options:{hoverClass:!1,activeClass:!1},_addActiveClass:function(){this._super(),this.options.activeClass&&this.element.addClass(this.options.activeClass)},_removeActiveClass:function(){this._super(),this.options.activeClass&&this.element.removeClass(this.options.activeClass)},_addHoverClass:function(){this._super(),this.options.hoverClass&&this.element.addClass(this.options.hoverClass)},_removeHoverClass:function(){this._super(),this.options.hoverClass&&this.element.removeClass(this.options.hoverClass)}}),t.ui.droppable,t.widget("ui.progressbar",{version:"1.12.1",options:{classes:{"ui-progressbar":"ui-corner-all","ui-progressbar-value":"ui-corner-left","ui-progressbar-complete":"ui-corner-right"},max:100,value:0,change:null,complete:null},min:0,_create:function(){this.oldValue=this.options.value=this._constrainedValue(),this.element.attr({role:"progressbar","aria-valuemin":this.min}),this._addClass("ui-progressbar","ui-widget ui-widget-content"),this.valueDiv=t("<div>").appendTo(this.element),this._addClass(this.valueDiv,"ui-progressbar-value","ui-widget-header"),this._refreshValue()},_destroy:function(){this.element.removeAttr("role aria-valuemin aria-valuemax aria-valuenow"),this.valueDiv.remove()},value:function(t){return void 0===t?this.options.value:(this.options.value=this._constrainedValue(t),this._refreshValue(),void 0)},_constrainedValue:function(t){return void 0===t&&(t=this.options.value),this.indeterminate=t===!1,"number"!=typeof t&&(t=0),this.indeterminate?!1:Math.min(this.options.max,Math.max(this.min,t))},_setOptions:function(t){var e=t.value;delete t.value,this._super(t),this.options.value=this._constrainedValue(e),this._refreshValue()},_setOption:function(t,e){"max"===t&&(e=Math.max(this.min,e)),this._super(t,e)},_setOptionDisabled:function(t){this._super(t),this.element.attr("aria-disabled",t),this._toggleClass(null,"ui-state-disabled",!!t)},_percentage:function(){return this.indeterminate?100:100*(this.options.value-this.min)/(this.options.max-this.min)},_refreshValue:function(){var e=this.options.value,i=this._percentage();this.valueDiv.toggle(this.indeterminate||e>this.min).width(i.toFixed(0)+"%"),this._toggleClass(this.valueDiv,"ui-progressbar-complete",null,e===this.options.max)._toggleClass("ui-progressbar-indeterminate",null,this.indeterminate),this.indeterminate?(this.element.removeAttr("aria-valuenow"),this.overlayDiv||(this.overlayDiv=t("<div>").appendTo(this.valueDiv),this._addClass(this.overlayDiv,"ui-progressbar-overlay"))):(this.element.attr({"aria-valuemax":this.options.max,"aria-valuenow":e}),this.overlayDiv&&(this.overlayDiv.remove(),this.overlayDiv=null)),this.oldValue!==e&&(this.oldValue=e,this._trigger("change")),e===this.options.max&&this._trigger("complete")}}),t.widget("ui.selectable",t.ui.mouse,{version:"1.12.1",options:{appendTo:"body",autoRefresh:!0,distance:0,filter:"*",tolerance:"touch",selected:null,selecting:null,start:null,stop:null,unselected:null,unselecting:null},_create:function(){var e=this;this._addClass("ui-selectable"),this.dragged=!1,this.refresh=function(){e.elementPos=t(e.element[0]).offset(),e.selectees=t(e.options.filter,e.element[0]),e._addClass(e.selectees,"ui-selectee"),e.selectees.each(function(){var i=t(this),s=i.offset(),n={left:s.left-e.elementPos.left,top:s.top-e.elementPos.top};t.data(this,"selectable-item",{element:this,$element:i,left:n.left,top:n.top,right:n.left+i.outerWidth(),bottom:n.top+i.outerHeight(),startselected:!1,selected:i.hasClass("ui-selected"),selecting:i.hasClass("ui-selecting"),unselecting:i.hasClass("ui-unselecting")})})},this.refresh(),this._mouseInit(),this.helper=t("<div>"),this._addClass(this.helper,"ui-selectable-helper")},_destroy:function(){this.selectees.removeData("selectable-item"),this._mouseDestroy()},_mouseStart:function(e){var i=this,s=this.options;this.opos=[e.pageX,e.pageY],this.elementPos=t(this.element[0]).offset(),this.options.disabled||(this.selectees=t(s.filter,this.element[0]),this._trigger("start",e),t(s.appendTo).append(this.helper),this.helper.css({left:e.pageX,top:e.pageY,width:0,height:0}),s.autoRefresh&&this.refresh(),this.selectees.filter(".ui-selected").each(function(){var s=t.data(this,"selectable-item");s.startselected=!0,e.metaKey||e.ctrlKey||(i._removeClass(s.$element,"ui-selected"),s.selected=!1,i._addClass(s.$element,"ui-unselecting"),s.unselecting=!0,i._trigger("unselecting",e,{unselecting:s.element}))}),t(e.target).parents().addBack().each(function(){var s,n=t.data(this,"selectable-item");return n?(s=!e.metaKey&&!e.ctrlKey||!n.$element.hasClass("ui-selected"),i._removeClass(n.$element,s?"ui-unselecting":"ui-selected")._addClass(n.$element,s?"ui-selecting":"ui-unselecting"),n.unselecting=!s,n.selecting=s,n.selected=s,s?i._trigger("selecting",e,{selecting:n.element}):i._trigger("unselecting",e,{unselecting:n.element}),!1):void 0}))},_mouseDrag:function(e){if(this.dragged=!0,!this.options.disabled){var i,s=this,n=this.options,o=this.opos[0],a=this.opos[1],r=e.pageX,h=e.pageY;return o>r&&(i=r,r=o,o=i),a>h&&(i=h,h=a,a=i),this.helper.css({left:o,top:a,width:r-o,height:h-a}),this.selectees.each(function(){var i=t.data(this,"selectable-item"),l=!1,c={};i&&i.element!==s.element[0]&&(c.left=i.left+s.elementPos.left,c.right=i.right+s.elementPos.left,c.top=i.top+s.elementPos.top,c.bottom=i.bottom+s.elementPos.top,"touch"===n.tolerance?l=!(c.left>r||o>c.right||c.top>h||a>c.bottom):"fit"===n.tolerance&&(l=c.left>o&&r>c.right&&c.top>a&&h>c.bottom),l?(i.selected&&(s._removeClass(i.$element,"ui-selected"),i.selected=!1),i.unselecting&&(s._removeClass(i.$element,"ui-unselecting"),i.unselecting=!1),i.selecting||(s._addClass(i.$element,"ui-selecting"),i.selecting=!0,s._trigger("selecting",e,{selecting:i.element}))):(i.selecting&&((e.metaKey||e.ctrlKey)&&i.startselected?(s._removeClass(i.$element,"ui-selecting"),i.selecting=!1,s._addClass(i.$element,"ui-selected"),i.selected=!0):(s._removeClass(i.$element,"ui-selecting"),i.selecting=!1,i.startselected&&(s._addClass(i.$element,"ui-unselecting"),i.unselecting=!0),s._trigger("unselecting",e,{unselecting:i.element}))),i.selected&&(e.metaKey||e.ctrlKey||i.startselected||(s._removeClass(i.$element,"ui-selected"),i.selected=!1,s._addClass(i.$element,"ui-unselecting"),i.unselecting=!0,s._trigger("unselecting",e,{unselecting:i.element})))))}),!1}},_mouseStop:function(e){var i=this;return this.dragged=!1,t(".ui-unselecting",this.element[0]).each(function(){var s=t.data(this,"selectable-item");i._removeClass(s.$element,"ui-unselecting"),s.unselecting=!1,s.startselected=!1,i._trigger("unselected",e,{unselected:s.element})}),t(".ui-selecting",this.element[0]).each(function(){var s=t.data(this,"selectable-item");i._removeClass(s.$element,"ui-selecting")._addClass(s.$element,"ui-selected"),s.selecting=!1,s.selected=!0,s.startselected=!0,i._trigger("selected",e,{selected:s.element})}),this._trigger("stop",e),this.helper.remove(),!1}}),t.widget("ui.selectmenu",[t.ui.formResetMixin,{version:"1.12.1",defaultElement:"<select>",options:{appendTo:null,classes:{"ui-selectmenu-button-open":"ui-corner-top","ui-selectmenu-button-closed":"ui-corner-all"},disabled:null,icons:{button:"ui-icon-triangle-1-s"},position:{my:"left top",at:"left bottom",collision:"none"},width:!1,change:null,close:null,focus:null,open:null,select:null},_create:function(){var e=this.element.uniqueId().attr("id");this.ids={element:e,button:e+"-button",menu:e+"-menu"},this._drawButton(),this._drawMenu(),this._bindFormResetHandler(),this._rendered=!1,this.menuItems=t()},_drawButton:function(){var e,i=this,s=this._parseOption(this.element.find("option:selected"),this.element[0].selectedIndex);this.labels=this.element.labels().attr("for",this.ids.button),this._on(this.labels,{click:function(t){this.button.focus(),t.preventDefault()}}),this.element.hide(),this.button=t("<span>",{tabindex:this.options.disabled?-1:0,id:this.ids.button,role:"combobox","aria-expanded":"false","aria-autocomplete":"list","aria-owns":this.ids.menu,"aria-haspopup":"true",title:this.element.attr("title")}).insertAfter(this.element),this._addClass(this.button,"ui-selectmenu-button ui-selectmenu-button-closed","ui-button ui-widget"),e=t("<span>").appendTo(this.button),this._addClass(e,"ui-selectmenu-icon","ui-icon "+this.options.icons.button),this.buttonItem=this._renderButtonItem(s).appendTo(this.button),this.options.width!==!1&&this._resizeButton(),this._on(this.button,this._buttonEvents),this.button.one("focusin",function(){i._rendered||i._refreshMenu()})},_drawMenu:function(){var e=this;this.menu=t("<ul>",{"aria-hidden":"true","aria-labelledby":this.ids.button,id:this.ids.menu}),this.menuWrap=t("<div>").append(this.menu),this._addClass(this.menuWrap,"ui-selectmenu-menu","ui-front"),this.menuWrap.appendTo(this._appendTo()),this.menuInstance=this.menu.menu({classes:{"ui-menu":"ui-corner-bottom"},role:"listbox",select:function(t,i){t.preventDefault(),e._setSelection(),e._select(i.item.data("ui-selectmenu-item"),t)},focus:function(t,i){var s=i.item.data("ui-selectmenu-item");null!=e.focusIndex&&s.index!==e.focusIndex&&(e._trigger("focus",t,{item:s}),e.isOpen||e._select(s,t)),e.focusIndex=s.index,e.button.attr("aria-activedescendant",e.menuItems.eq(s.index).attr("id"))}}).menu("instance"),this.menuInstance._off(this.menu,"mouseleave"),this.menuInstance._closeOnDocumentClick=function(){return!1},this.menuInstance._isDivider=function(){return!1}},refresh:function(){this._refreshMenu(),this.buttonItem.replaceWith(this.buttonItem=this._renderButtonItem(this._getSelectedItem().data("ui-selectmenu-item")||{})),null===this.options.width&&this._resizeButton()},_refreshMenu:function(){var t,e=this.element.find("option");this.menu.empty(),this._parseOptions(e),this._renderMenu(this.menu,this.items),this.menuInstance.refresh(),this.menuItems=this.menu.find("li").not(".ui-selectmenu-optgroup").find(".ui-menu-item-wrapper"),this._rendered=!0,e.length&&(t=this._getSelectedItem(),this.menuInstance.focus(null,t),this._setAria(t.data("ui-selectmenu-item")),this._setOption("disabled",this.element.prop("disabled")))},open:function(t){this.options.disabled||(this._rendered?(this._removeClass(this.menu.find(".ui-state-active"),null,"ui-state-active"),this.menuInstance.focus(null,this._getSelectedItem())):this._refreshMenu(),this.menuItems.length&&(this.isOpen=!0,this._toggleAttr(),this._resizeMenu(),this._position(),this._on(this.document,this._documentClick),this._trigger("open",t)))},_position:function(){this.menuWrap.position(t.extend({of:this.button},this.options.position))},close:function(t){this.isOpen&&(this.isOpen=!1,this._toggleAttr(),this.range=null,this._off(this.document),this._trigger("close",t))},widget:function(){return this.button},menuWidget:function(){return this.menu},_renderButtonItem:function(e){var i=t("<span>");return this._setText(i,e.label),this._addClass(i,"ui-selectmenu-text"),i},_renderMenu:function(e,i){var s=this,n="";t.each(i,function(i,o){var a;o.optgroup!==n&&(a=t("<li>",{text:o.optgroup}),s._addClass(a,"ui-selectmenu-optgroup","ui-menu-divider"+(o.element.parent("optgroup").prop("disabled")?" ui-state-disabled":"")),a.appendTo(e),n=o.optgroup),s._renderItemData(e,o)})},_renderItemData:function(t,e){return this._renderItem(t,e).data("ui-selectmenu-item",e)},_renderItem:function(e,i){var s=t("<li>"),n=t("<div>",{title:i.element.attr("title")});return i.disabled&&this._addClass(s,null,"ui-state-disabled"),this._setText(n,i.label),s.append(n).appendTo(e)},_setText:function(t,e){e?t.text(e):t.html("&#160;")},_move:function(t,e){var i,s,n=".ui-menu-item";this.isOpen?i=this.menuItems.eq(this.focusIndex).parent("li"):(i=this.menuItems.eq(this.element[0].selectedIndex).parent("li"),n+=":not(.ui-state-disabled)"),s="first"===t||"last"===t?i["first"===t?"prevAll":"nextAll"](n).eq(-1):i[t+"All"](n).eq(0),s.length&&this.menuInstance.focus(e,s)},_getSelectedItem:function(){return this.menuItems.eq(this.element[0].selectedIndex).parent("li")},_toggle:function(t){this[this.isOpen?"close":"open"](t)},_setSelection:function(){var t;this.range&&(window.getSelection?(t=window.getSelection(),t.removeAllRanges(),t.addRange(this.range)):this.range.select(),this.button.focus())},_documentClick:{mousedown:function(e){this.isOpen&&(t(e.target).closest(".ui-selectmenu-menu, #"+t.ui.escapeSelector(this.ids.button)).length||this.close(e))}},_buttonEvents:{mousedown:function(){var t;window.getSelection?(t=window.getSelection(),t.rangeCount&&(this.range=t.getRangeAt(0))):this.range=document.selection.createRange()},click:function(t){this._setSelection(),this._toggle(t)},keydown:function(e){var i=!0;switch(e.keyCode){case t.ui.keyCode.TAB:case t.ui.keyCode.ESCAPE:this.close(e),i=!1;break;case t.ui.keyCode.ENTER:this.isOpen&&this._selectFocusedItem(e);break;case t.ui.keyCode.UP:e.altKey?this._toggle(e):this._move("prev",e);break;case t.ui.keyCode.DOWN:e.altKey?this._toggle(e):this._move("next",e);break;case t.ui.keyCode.SPACE:this.isOpen?this._selectFocusedItem(e):this._toggle(e);break;case t.ui.keyCode.LEFT:this._move("prev",e);break;case t.ui.keyCode.RIGHT:this._move("next",e);break;case t.ui.keyCode.HOME:case t.ui.keyCode.PAGE_UP:this._move("first",e);break;case t.ui.keyCode.END:case t.ui.keyCode.PAGE_DOWN:this._move("last",e);break;default:this.menu.trigger(e),i=!1}i&&e.preventDefault()}},_selectFocusedItem:function(t){var e=this.menuItems.eq(this.focusIndex).parent("li");e.hasClass("ui-state-disabled")||this._select(e.data("ui-selectmenu-item"),t)},_select:function(t,e){var i=this.element[0].selectedIndex;this.element[0].selectedIndex=t.index,this.buttonItem.replaceWith(this.buttonItem=this._renderButtonItem(t)),this._setAria(t),this._trigger("select",e,{item:t}),t.index!==i&&this._trigger("change",e,{item:t}),this.close(e)},_setAria:function(t){var e=this.menuItems.eq(t.index).attr("id");this.button.attr({"aria-labelledby":e,"aria-activedescendant":e}),this.menu.attr("aria-activedescendant",e)},_setOption:function(t,e){if("icons"===t){var i=this.button.find("span.ui-icon");this._removeClass(i,null,this.options.icons.button)._addClass(i,null,e.button)}this._super(t,e),"appendTo"===t&&this.menuWrap.appendTo(this._appendTo()),"width"===t&&this._resizeButton()},_setOptionDisabled:function(t){this._super(t),this.menuInstance.option("disabled",t),this.button.attr("aria-disabled",t),this._toggleClass(this.button,null,"ui-state-disabled",t),this.element.prop("disabled",t),t?(this.button.attr("tabindex",-1),this.close()):this.button.attr("tabindex",0)},_appendTo:function(){var e=this.options.appendTo;return e&&(e=e.jquery||e.nodeType?t(e):this.document.find(e).eq(0)),e&&e[0]||(e=this.element.closest(".ui-front, dialog")),e.length||(e=this.document[0].body),e},_toggleAttr:function(){this.button.attr("aria-expanded",this.isOpen),this._removeClass(this.button,"ui-selectmenu-button-"+(this.isOpen?"closed":"open"))._addClass(this.button,"ui-selectmenu-button-"+(this.isOpen?"open":"closed"))._toggleClass(this.menuWrap,"ui-selectmenu-open",null,this.isOpen),this.menu.attr("aria-hidden",!this.isOpen)},_resizeButton:function(){var t=this.options.width;return t===!1?(this.button.css("width",""),void 0):(null===t&&(t=this.element.show().outerWidth(),this.element.hide()),this.button.outerWidth(t),void 0)},_resizeMenu:function(){this.menu.outerWidth(Math.max(this.button.outerWidth(),this.menu.width("").outerWidth()+1))},_getCreateOptions:function(){var t=this._super();return t.disabled=this.element.prop("disabled"),t},_parseOptions:function(e){var i=this,s=[];e.each(function(e,n){s.push(i._parseOption(t(n),e))}),this.items=s},_parseOption:function(t,e){var i=t.parent("optgroup");return{element:t,index:e,value:t.val(),label:t.text(),optgroup:i.attr("label")||"",disabled:i.prop("disabled")||t.prop("disabled")}},_destroy:function(){this._unbindFormResetHandler(),this.menuWrap.remove(),this.button.remove(),this.element.show(),this.element.removeUniqueId(),this.labels.attr("for",this.ids.element)}}]),t.widget("ui.slider",t.ui.mouse,{version:"1.12.1",widgetEventPrefix:"slide",options:{animate:!1,classes:{"ui-slider":"ui-corner-all","ui-slider-handle":"ui-corner-all","ui-slider-range":"ui-corner-all ui-widget-header"},distance:0,max:100,min:0,orientation:"horizontal",range:!1,step:1,value:0,values:null,change:null,slide:null,start:null,stop:null},numPages:5,_create:function(){this._keySliding=!1,this._mouseSliding=!1,this._animateOff=!0,this._handleIndex=null,this._detectOrientation(),this._mouseInit(),this._calculateNewMax(),this._addClass("ui-slider ui-slider-"+this.orientation,"ui-widget ui-widget-content"),this._refresh(),this._animateOff=!1
-},_refresh:function(){this._createRange(),this._createHandles(),this._setupEvents(),this._refreshValue()},_createHandles:function(){var e,i,s=this.options,n=this.element.find(".ui-slider-handle"),o="<span tabindex='0'></span>",a=[];for(i=s.values&&s.values.length||1,n.length>i&&(n.slice(i).remove(),n=n.slice(0,i)),e=n.length;i>e;e++)a.push(o);this.handles=n.add(t(a.join("")).appendTo(this.element)),this._addClass(this.handles,"ui-slider-handle","ui-state-default"),this.handle=this.handles.eq(0),this.handles.each(function(e){t(this).data("ui-slider-handle-index",e).attr("tabIndex",0)})},_createRange:function(){var e=this.options;e.range?(e.range===!0&&(e.values?e.values.length&&2!==e.values.length?e.values=[e.values[0],e.values[0]]:t.isArray(e.values)&&(e.values=e.values.slice(0)):e.values=[this._valueMin(),this._valueMin()]),this.range&&this.range.length?(this._removeClass(this.range,"ui-slider-range-min ui-slider-range-max"),this.range.css({left:"",bottom:""})):(this.range=t("<div>").appendTo(this.element),this._addClass(this.range,"ui-slider-range")),("min"===e.range||"max"===e.range)&&this._addClass(this.range,"ui-slider-range-"+e.range)):(this.range&&this.range.remove(),this.range=null)},_setupEvents:function(){this._off(this.handles),this._on(this.handles,this._handleEvents),this._hoverable(this.handles),this._focusable(this.handles)},_destroy:function(){this.handles.remove(),this.range&&this.range.remove(),this._mouseDestroy()},_mouseCapture:function(e){var i,s,n,o,a,r,h,l,c=this,u=this.options;return u.disabled?!1:(this.elementSize={width:this.element.outerWidth(),height:this.element.outerHeight()},this.elementOffset=this.element.offset(),i={x:e.pageX,y:e.pageY},s=this._normValueFromMouse(i),n=this._valueMax()-this._valueMin()+1,this.handles.each(function(e){var i=Math.abs(s-c.values(e));(n>i||n===i&&(e===c._lastChangedValue||c.values(e)===u.min))&&(n=i,o=t(this),a=e)}),r=this._start(e,a),r===!1?!1:(this._mouseSliding=!0,this._handleIndex=a,this._addClass(o,null,"ui-state-active"),o.trigger("focus"),h=o.offset(),l=!t(e.target).parents().addBack().is(".ui-slider-handle"),this._clickOffset=l?{left:0,top:0}:{left:e.pageX-h.left-o.width()/2,top:e.pageY-h.top-o.height()/2-(parseInt(o.css("borderTopWidth"),10)||0)-(parseInt(o.css("borderBottomWidth"),10)||0)+(parseInt(o.css("marginTop"),10)||0)},this.handles.hasClass("ui-state-hover")||this._slide(e,a,s),this._animateOff=!0,!0))},_mouseStart:function(){return!0},_mouseDrag:function(t){var e={x:t.pageX,y:t.pageY},i=this._normValueFromMouse(e);return this._slide(t,this._handleIndex,i),!1},_mouseStop:function(t){return this._removeClass(this.handles,null,"ui-state-active"),this._mouseSliding=!1,this._stop(t,this._handleIndex),this._change(t,this._handleIndex),this._handleIndex=null,this._clickOffset=null,this._animateOff=!1,!1},_detectOrientation:function(){this.orientation="vertical"===this.options.orientation?"vertical":"horizontal"},_normValueFromMouse:function(t){var e,i,s,n,o;return"horizontal"===this.orientation?(e=this.elementSize.width,i=t.x-this.elementOffset.left-(this._clickOffset?this._clickOffset.left:0)):(e=this.elementSize.height,i=t.y-this.elementOffset.top-(this._clickOffset?this._clickOffset.top:0)),s=i/e,s>1&&(s=1),0>s&&(s=0),"vertical"===this.orientation&&(s=1-s),n=this._valueMax()-this._valueMin(),o=this._valueMin()+s*n,this._trimAlignValue(o)},_uiHash:function(t,e,i){var s={handle:this.handles[t],handleIndex:t,value:void 0!==e?e:this.value()};return this._hasMultipleValues()&&(s.value=void 0!==e?e:this.values(t),s.values=i||this.values()),s},_hasMultipleValues:function(){return this.options.values&&this.options.values.length},_start:function(t,e){return this._trigger("start",t,this._uiHash(e))},_slide:function(t,e,i){var s,n,o=this.value(),a=this.values();this._hasMultipleValues()&&(n=this.values(e?0:1),o=this.values(e),2===this.options.values.length&&this.options.range===!0&&(i=0===e?Math.min(n,i):Math.max(n,i)),a[e]=i),i!==o&&(s=this._trigger("slide",t,this._uiHash(e,i,a)),s!==!1&&(this._hasMultipleValues()?this.values(e,i):this.value(i)))},_stop:function(t,e){this._trigger("stop",t,this._uiHash(e))},_change:function(t,e){this._keySliding||this._mouseSliding||(this._lastChangedValue=e,this._trigger("change",t,this._uiHash(e)))},value:function(t){return arguments.length?(this.options.value=this._trimAlignValue(t),this._refreshValue(),this._change(null,0),void 0):this._value()},values:function(e,i){var s,n,o;if(arguments.length>1)return this.options.values[e]=this._trimAlignValue(i),this._refreshValue(),this._change(null,e),void 0;if(!arguments.length)return this._values();if(!t.isArray(arguments[0]))return this._hasMultipleValues()?this._values(e):this.value();for(s=this.options.values,n=arguments[0],o=0;s.length>o;o+=1)s[o]=this._trimAlignValue(n[o]),this._change(null,o);this._refreshValue()},_setOption:function(e,i){var s,n=0;switch("range"===e&&this.options.range===!0&&("min"===i?(this.options.value=this._values(0),this.options.values=null):"max"===i&&(this.options.value=this._values(this.options.values.length-1),this.options.values=null)),t.isArray(this.options.values)&&(n=this.options.values.length),this._super(e,i),e){case"orientation":this._detectOrientation(),this._removeClass("ui-slider-horizontal ui-slider-vertical")._addClass("ui-slider-"+this.orientation),this._refreshValue(),this.options.range&&this._refreshRange(i),this.handles.css("horizontal"===i?"bottom":"left","");break;case"value":this._animateOff=!0,this._refreshValue(),this._change(null,0),this._animateOff=!1;break;case"values":for(this._animateOff=!0,this._refreshValue(),s=n-1;s>=0;s--)this._change(null,s);this._animateOff=!1;break;case"step":case"min":case"max":this._animateOff=!0,this._calculateNewMax(),this._refreshValue(),this._animateOff=!1;break;case"range":this._animateOff=!0,this._refresh(),this._animateOff=!1}},_setOptionDisabled:function(t){this._super(t),this._toggleClass(null,"ui-state-disabled",!!t)},_value:function(){var t=this.options.value;return t=this._trimAlignValue(t)},_values:function(t){var e,i,s;if(arguments.length)return e=this.options.values[t],e=this._trimAlignValue(e);if(this._hasMultipleValues()){for(i=this.options.values.slice(),s=0;i.length>s;s+=1)i[s]=this._trimAlignValue(i[s]);return i}return[]},_trimAlignValue:function(t){if(this._valueMin()>=t)return this._valueMin();if(t>=this._valueMax())return this._valueMax();var e=this.options.step>0?this.options.step:1,i=(t-this._valueMin())%e,s=t-i;return 2*Math.abs(i)>=e&&(s+=i>0?e:-e),parseFloat(s.toFixed(5))},_calculateNewMax:function(){var t=this.options.max,e=this._valueMin(),i=this.options.step,s=Math.round((t-e)/i)*i;t=s+e,t>this.options.max&&(t-=i),this.max=parseFloat(t.toFixed(this._precision()))},_precision:function(){var t=this._precisionOf(this.options.step);return null!==this.options.min&&(t=Math.max(t,this._precisionOf(this.options.min))),t},_precisionOf:function(t){var e=""+t,i=e.indexOf(".");return-1===i?0:e.length-i-1},_valueMin:function(){return this.options.min},_valueMax:function(){return this.max},_refreshRange:function(t){"vertical"===t&&this.range.css({width:"",left:""}),"horizontal"===t&&this.range.css({height:"",bottom:""})},_refreshValue:function(){var e,i,s,n,o,a=this.options.range,r=this.options,h=this,l=this._animateOff?!1:r.animate,c={};this._hasMultipleValues()?this.handles.each(function(s){i=100*((h.values(s)-h._valueMin())/(h._valueMax()-h._valueMin())),c["horizontal"===h.orientation?"left":"bottom"]=i+"%",t(this).stop(1,1)[l?"animate":"css"](c,r.animate),h.options.range===!0&&("horizontal"===h.orientation?(0===s&&h.range.stop(1,1)[l?"animate":"css"]({left:i+"%"},r.animate),1===s&&h.range[l?"animate":"css"]({width:i-e+"%"},{queue:!1,duration:r.animate})):(0===s&&h.range.stop(1,1)[l?"animate":"css"]({bottom:i+"%"},r.animate),1===s&&h.range[l?"animate":"css"]({height:i-e+"%"},{queue:!1,duration:r.animate}))),e=i}):(s=this.value(),n=this._valueMin(),o=this._valueMax(),i=o!==n?100*((s-n)/(o-n)):0,c["horizontal"===this.orientation?"left":"bottom"]=i+"%",this.handle.stop(1,1)[l?"animate":"css"](c,r.animate),"min"===a&&"horizontal"===this.orientation&&this.range.stop(1,1)[l?"animate":"css"]({width:i+"%"},r.animate),"max"===a&&"horizontal"===this.orientation&&this.range.stop(1,1)[l?"animate":"css"]({width:100-i+"%"},r.animate),"min"===a&&"vertical"===this.orientation&&this.range.stop(1,1)[l?"animate":"css"]({height:i+"%"},r.animate),"max"===a&&"vertical"===this.orientation&&this.range.stop(1,1)[l?"animate":"css"]({height:100-i+"%"},r.animate))},_handleEvents:{keydown:function(e){var i,s,n,o,a=t(e.target).data("ui-slider-handle-index");switch(e.keyCode){case t.ui.keyCode.HOME:case t.ui.keyCode.END:case t.ui.keyCode.PAGE_UP:case t.ui.keyCode.PAGE_DOWN:case t.ui.keyCode.UP:case t.ui.keyCode.RIGHT:case t.ui.keyCode.DOWN:case t.ui.keyCode.LEFT:if(e.preventDefault(),!this._keySliding&&(this._keySliding=!0,this._addClass(t(e.target),null,"ui-state-active"),i=this._start(e,a),i===!1))return}switch(o=this.options.step,s=n=this._hasMultipleValues()?this.values(a):this.value(),e.keyCode){case t.ui.keyCode.HOME:n=this._valueMin();break;case t.ui.keyCode.END:n=this._valueMax();break;case t.ui.keyCode.PAGE_UP:n=this._trimAlignValue(s+(this._valueMax()-this._valueMin())/this.numPages);break;case t.ui.keyCode.PAGE_DOWN:n=this._trimAlignValue(s-(this._valueMax()-this._valueMin())/this.numPages);break;case t.ui.keyCode.UP:case t.ui.keyCode.RIGHT:if(s===this._valueMax())return;n=this._trimAlignValue(s+o);break;case t.ui.keyCode.DOWN:case t.ui.keyCode.LEFT:if(s===this._valueMin())return;n=this._trimAlignValue(s-o)}this._slide(e,a,n)},keyup:function(e){var i=t(e.target).data("ui-slider-handle-index");this._keySliding&&(this._keySliding=!1,this._stop(e,i),this._change(e,i),this._removeClass(t(e.target),null,"ui-state-active"))}}}),t.widget("ui.sortable",t.ui.mouse,{version:"1.12.1",widgetEventPrefix:"sort",ready:!1,options:{appendTo:"parent",axis:!1,connectWith:!1,containment:!1,cursor:"auto",cursorAt:!1,dropOnEmpty:!0,forcePlaceholderSize:!1,forceHelperSize:!1,grid:!1,handle:!1,helper:"original",items:"> *",opacity:!1,placeholder:!1,revert:!1,scroll:!0,scrollSensitivity:20,scrollSpeed:20,scope:"default",tolerance:"intersect",zIndex:1e3,activate:null,beforeStop:null,change:null,deactivate:null,out:null,over:null,receive:null,remove:null,sort:null,start:null,stop:null,update:null},_isOverAxis:function(t,e,i){return t>=e&&e+i>t},_isFloating:function(t){return/left|right/.test(t.css("float"))||/inline|table-cell/.test(t.css("display"))},_create:function(){this.containerCache={},this._addClass("ui-sortable"),this.refresh(),this.offset=this.element.offset(),this._mouseInit(),this._setHandleClassName(),this.ready=!0},_setOption:function(t,e){this._super(t,e),"handle"===t&&this._setHandleClassName()},_setHandleClassName:function(){var e=this;this._removeClass(this.element.find(".ui-sortable-handle"),"ui-sortable-handle"),t.each(this.items,function(){e._addClass(this.instance.options.handle?this.item.find(this.instance.options.handle):this.item,"ui-sortable-handle")})},_destroy:function(){this._mouseDestroy();for(var t=this.items.length-1;t>=0;t--)this.items[t].item.removeData(this.widgetName+"-item");return this},_mouseCapture:function(e,i){var s=null,n=!1,o=this;return this.reverting?!1:this.options.disabled||"static"===this.options.type?!1:(this._refreshItems(e),t(e.target).parents().each(function(){return t.data(this,o.widgetName+"-item")===o?(s=t(this),!1):void 0}),t.data(e.target,o.widgetName+"-item")===o&&(s=t(e.target)),s?!this.options.handle||i||(t(this.options.handle,s).find("*").addBack().each(function(){this===e.target&&(n=!0)}),n)?(this.currentItem=s,this._removeCurrentsFromItems(),!0):!1:!1)},_mouseStart:function(e,i,s){var n,o,a=this.options;if(this.currentContainer=this,this.refreshPositions(),this.helper=this._createHelper(e),this._cacheHelperProportions(),this._cacheMargins(),this.scrollParent=this.helper.scrollParent(),this.offset=this.currentItem.offset(),this.offset={top:this.offset.top-this.margins.top,left:this.offset.left-this.margins.left},t.extend(this.offset,{click:{left:e.pageX-this.offset.left,top:e.pageY-this.offset.top},parent:this._getParentOffset(),relative:this._getRelativeOffset()}),this.helper.css("position","absolute"),this.cssPosition=this.helper.css("position"),this.originalPosition=this._generatePosition(e),this.originalPageX=e.pageX,this.originalPageY=e.pageY,a.cursorAt&&this._adjustOffsetFromHelper(a.cursorAt),this.domPosition={prev:this.currentItem.prev()[0],parent:this.currentItem.parent()[0]},this.helper[0]!==this.currentItem[0]&&this.currentItem.hide(),this._createPlaceholder(),a.containment&&this._setContainment(),a.cursor&&"auto"!==a.cursor&&(o=this.document.find("body"),this.storedCursor=o.css("cursor"),o.css("cursor",a.cursor),this.storedStylesheet=t("<style>*{ cursor: "+a.cursor+" !important; }</style>").appendTo(o)),a.opacity&&(this.helper.css("opacity")&&(this._storedOpacity=this.helper.css("opacity")),this.helper.css("opacity",a.opacity)),a.zIndex&&(this.helper.css("zIndex")&&(this._storedZIndex=this.helper.css("zIndex")),this.helper.css("zIndex",a.zIndex)),this.scrollParent[0]!==this.document[0]&&"HTML"!==this.scrollParent[0].tagName&&(this.overflowOffset=this.scrollParent.offset()),this._trigger("start",e,this._uiHash()),this._preserveHelperProportions||this._cacheHelperProportions(),!s)for(n=this.containers.length-1;n>=0;n--)this.containers[n]._trigger("activate",e,this._uiHash(this));return t.ui.ddmanager&&(t.ui.ddmanager.current=this),t.ui.ddmanager&&!a.dropBehaviour&&t.ui.ddmanager.prepareOffsets(this,e),this.dragging=!0,this._addClass(this.helper,"ui-sortable-helper"),this._mouseDrag(e),!0},_mouseDrag:function(e){var i,s,n,o,a=this.options,r=!1;for(this.position=this._generatePosition(e),this.positionAbs=this._convertPositionTo("absolute"),this.lastPositionAbs||(this.lastPositionAbs=this.positionAbs),this.options.scroll&&(this.scrollParent[0]!==this.document[0]&&"HTML"!==this.scrollParent[0].tagName?(this.overflowOffset.top+this.scrollParent[0].offsetHeight-e.pageY<a.scrollSensitivity?this.scrollParent[0].scrollTop=r=this.scrollParent[0].scrollTop+a.scrollSpeed:e.pageY-this.overflowOffset.top<a.scrollSensitivity&&(this.scrollParent[0].scrollTop=r=this.scrollParent[0].scrollTop-a.scrollSpeed),this.overflowOffset.left+this.scrollParent[0].offsetWidth-e.pageX<a.scrollSensitivity?this.scrollParent[0].scrollLeft=r=this.scrollParent[0].scrollLeft+a.scrollSpeed:e.pageX-this.overflowOffset.left<a.scrollSensitivity&&(this.scrollParent[0].scrollLeft=r=this.scrollParent[0].scrollLeft-a.scrollSpeed)):(e.pageY-this.document.scrollTop()<a.scrollSensitivity?r=this.document.scrollTop(this.document.scrollTop()-a.scrollSpeed):this.window.height()-(e.pageY-this.document.scrollTop())<a.scrollSensitivity&&(r=this.document.scrollTop(this.document.scrollTop()+a.scrollSpeed)),e.pageX-this.document.scrollLeft()<a.scrollSensitivity?r=this.document.scrollLeft(this.document.scrollLeft()-a.scrollSpeed):this.window.width()-(e.pageX-this.document.scrollLeft())<a.scrollSensitivity&&(r=this.document.scrollLeft(this.document.scrollLeft()+a.scrollSpeed))),r!==!1&&t.ui.ddmanager&&!a.dropBehaviour&&t.ui.ddmanager.prepareOffsets(this,e)),this.positionAbs=this._convertPositionTo("absolute"),this.options.axis&&"y"===this.options.axis||(this.helper[0].style.left=this.position.left+"px"),this.options.axis&&"x"===this.options.axis||(this.helper[0].style.top=this.position.top+"px"),i=this.items.length-1;i>=0;i--)if(s=this.items[i],n=s.item[0],o=this._intersectsWithPointer(s),o&&s.instance===this.currentContainer&&n!==this.currentItem[0]&&this.placeholder[1===o?"next":"prev"]()[0]!==n&&!t.contains(this.placeholder[0],n)&&("semi-dynamic"===this.options.type?!t.contains(this.element[0],n):!0)){if(this.direction=1===o?"down":"up","pointer"!==this.options.tolerance&&!this._intersectsWithSides(s))break;this._rearrange(e,s),this._trigger("change",e,this._uiHash());break}return this._contactContainers(e),t.ui.ddmanager&&t.ui.ddmanager.drag(this,e),this._trigger("sort",e,this._uiHash()),this.lastPositionAbs=this.positionAbs,!1},_mouseStop:function(e,i){if(e){if(t.ui.ddmanager&&!this.options.dropBehaviour&&t.ui.ddmanager.drop(this,e),this.options.revert){var s=this,n=this.placeholder.offset(),o=this.options.axis,a={};o&&"x"!==o||(a.left=n.left-this.offset.parent.left-this.margins.left+(this.offsetParent[0]===this.document[0].body?0:this.offsetParent[0].scrollLeft)),o&&"y"!==o||(a.top=n.top-this.offset.parent.top-this.margins.top+(this.offsetParent[0]===this.document[0].body?0:this.offsetParent[0].scrollTop)),this.reverting=!0,t(this.helper).animate(a,parseInt(this.options.revert,10)||500,function(){s._clear(e)})}else this._clear(e,i);return!1}},cancel:function(){if(this.dragging){this._mouseUp(new t.Event("mouseup",{target:null})),"original"===this.options.helper?(this.currentItem.css(this._storedCSS),this._removeClass(this.currentItem,"ui-sortable-helper")):this.currentItem.show();for(var e=this.containers.length-1;e>=0;e--)this.containers[e]._trigger("deactivate",null,this._uiHash(this)),this.containers[e].containerCache.over&&(this.containers[e]._trigger("out",null,this._uiHash(this)),this.containers[e].containerCache.over=0)}return this.placeholder&&(this.placeholder[0].parentNode&&this.placeholder[0].parentNode.removeChild(this.placeholder[0]),"original"!==this.options.helper&&this.helper&&this.helper[0].parentNode&&this.helper.remove(),t.extend(this,{helper:null,dragging:!1,reverting:!1,_noFinalSort:null}),this.domPosition.prev?t(this.domPosition.prev).after(this.currentItem):t(this.domPosition.parent).prepend(this.currentItem)),this},serialize:function(e){var i=this._getItemsAsjQuery(e&&e.connected),s=[];return e=e||{},t(i).each(function(){var i=(t(e.item||this).attr(e.attribute||"id")||"").match(e.expression||/(.+)[\-=_](.+)/);i&&s.push((e.key||i[1]+"[]")+"="+(e.key&&e.expression?i[1]:i[2]))}),!s.length&&e.key&&s.push(e.key+"="),s.join("&")},toArray:function(e){var i=this._getItemsAsjQuery(e&&e.connected),s=[];return e=e||{},i.each(function(){s.push(t(e.item||this).attr(e.attribute||"id")||"")}),s},_intersectsWith:function(t){var e=this.positionAbs.left,i=e+this.helperProportions.width,s=this.positionAbs.top,n=s+this.helperProportions.height,o=t.left,a=o+t.width,r=t.top,h=r+t.height,l=this.offset.click.top,c=this.offset.click.left,u="x"===this.options.axis||s+l>r&&h>s+l,d="y"===this.options.axis||e+c>o&&a>e+c,p=u&&d;return"pointer"===this.options.tolerance||this.options.forcePointerForContainers||"pointer"!==this.options.tolerance&&this.helperProportions[this.floating?"width":"height"]>t[this.floating?"width":"height"]?p:e+this.helperProportions.width/2>o&&a>i-this.helperProportions.width/2&&s+this.helperProportions.height/2>r&&h>n-this.helperProportions.height/2},_intersectsWithPointer:function(t){var e,i,s="x"===this.options.axis||this._isOverAxis(this.positionAbs.top+this.offset.click.top,t.top,t.height),n="y"===this.options.axis||this._isOverAxis(this.positionAbs.left+this.offset.click.left,t.left,t.width),o=s&&n;return o?(e=this._getDragVerticalDirection(),i=this._getDragHorizontalDirection(),this.floating?"right"===i||"down"===e?2:1:e&&("down"===e?2:1)):!1},_intersectsWithSides:function(t){var e=this._isOverAxis(this.positionAbs.top+this.offset.click.top,t.top+t.height/2,t.height),i=this._isOverAxis(this.positionAbs.left+this.offset.click.left,t.left+t.width/2,t.width),s=this._getDragVerticalDirection(),n=this._getDragHorizontalDirection();return this.floating&&n?"right"===n&&i||"left"===n&&!i:s&&("down"===s&&e||"up"===s&&!e)},_getDragVerticalDirection:function(){var t=this.positionAbs.top-this.lastPositionAbs.top;return 0!==t&&(t>0?"down":"up")},_getDragHorizontalDirection:function(){var t=this.positionAbs.left-this.lastPositionAbs.left;return 0!==t&&(t>0?"right":"left")},refresh:function(t){return this._refreshItems(t),this._setHandleClassName(),this.refreshPositions(),this},_connectWith:function(){var t=this.options;return t.connectWith.constructor===String?[t.connectWith]:t.connectWith},_getItemsAsjQuery:function(e){function i(){r.push(this)}var s,n,o,a,r=[],h=[],l=this._connectWith();if(l&&e)for(s=l.length-1;s>=0;s--)for(o=t(l[s],this.document[0]),n=o.length-1;n>=0;n--)a=t.data(o[n],this.widgetFullName),a&&a!==this&&!a.options.disabled&&h.push([t.isFunction(a.options.items)?a.options.items.call(a.element):t(a.options.items,a.element).not(".ui-sortable-helper").not(".ui-sortable-placeholder"),a]);for(h.push([t.isFunction(this.options.items)?this.options.items.call(this.element,null,{options:this.options,item:this.currentItem}):t(this.options.items,this.element).not(".ui-sortable-helper").not(".ui-sortable-placeholder"),this]),s=h.length-1;s>=0;s--)h[s][0].each(i);return t(r)},_removeCurrentsFromItems:function(){var e=this.currentItem.find(":data("+this.widgetName+"-item)");this.items=t.grep(this.items,function(t){for(var i=0;e.length>i;i++)if(e[i]===t.item[0])return!1;return!0})},_refreshItems:function(e){this.items=[],this.containers=[this];var i,s,n,o,a,r,h,l,c=this.items,u=[[t.isFunction(this.options.items)?this.options.items.call(this.element[0],e,{item:this.currentItem}):t(this.options.items,this.element),this]],d=this._connectWith();if(d&&this.ready)for(i=d.length-1;i>=0;i--)for(n=t(d[i],this.document[0]),s=n.length-1;s>=0;s--)o=t.data(n[s],this.widgetFullName),o&&o!==this&&!o.options.disabled&&(u.push([t.isFunction(o.options.items)?o.options.items.call(o.element[0],e,{item:this.currentItem}):t(o.options.items,o.element),o]),this.containers.push(o));for(i=u.length-1;i>=0;i--)for(a=u[i][1],r=u[i][0],s=0,l=r.length;l>s;s++)h=t(r[s]),h.data(this.widgetName+"-item",a),c.push({item:h,instance:a,width:0,height:0,left:0,top:0})},refreshPositions:function(e){this.floating=this.items.length?"x"===this.options.axis||this._isFloating(this.items[0].item):!1,this.offsetParent&&this.helper&&(this.offset.parent=this._getParentOffset());var i,s,n,o;for(i=this.items.length-1;i>=0;i--)s=this.items[i],s.instance!==this.currentContainer&&this.currentContainer&&s.item[0]!==this.currentItem[0]||(n=this.options.toleranceElement?t(this.options.toleranceElement,s.item):s.item,e||(s.width=n.outerWidth(),s.height=n.outerHeight()),o=n.offset(),s.left=o.left,s.top=o.top);if(this.options.custom&&this.options.custom.refreshContainers)this.options.custom.refreshContainers.call(this);else for(i=this.containers.length-1;i>=0;i--)o=this.containers[i].element.offset(),this.containers[i].containerCache.left=o.left,this.containers[i].containerCache.top=o.top,this.containers[i].containerCache.width=this.containers[i].element.outerWidth(),this.containers[i].containerCache.height=this.containers[i].element.outerHeight();return this},_createPlaceholder:function(e){e=e||this;var i,s=e.options;s.placeholder&&s.placeholder.constructor!==String||(i=s.placeholder,s.placeholder={element:function(){var s=e.currentItem[0].nodeName.toLowerCase(),n=t("<"+s+">",e.document[0]);return e._addClass(n,"ui-sortable-placeholder",i||e.currentItem[0].className)._removeClass(n,"ui-sortable-helper"),"tbody"===s?e._createTrPlaceholder(e.currentItem.find("tr").eq(0),t("<tr>",e.document[0]).appendTo(n)):"tr"===s?e._createTrPlaceholder(e.currentItem,n):"img"===s&&n.attr("src",e.currentItem.attr("src")),i||n.css("visibility","hidden"),n},update:function(t,n){(!i||s.forcePlaceholderSize)&&(n.height()||n.height(e.currentItem.innerHeight()-parseInt(e.currentItem.css("paddingTop")||0,10)-parseInt(e.currentItem.css("paddingBottom")||0,10)),n.width()||n.width(e.currentItem.innerWidth()-parseInt(e.currentItem.css("paddingLeft")||0,10)-parseInt(e.currentItem.css("paddingRight")||0,10)))}}),e.placeholder=t(s.placeholder.element.call(e.element,e.currentItem)),e.currentItem.after(e.placeholder),s.placeholder.update(e,e.placeholder)},_createTrPlaceholder:function(e,i){var s=this;e.children().each(function(){t("<td>&#160;</td>",s.document[0]).attr("colspan",t(this).attr("colspan")||1).appendTo(i)})},_contactContainers:function(e){var i,s,n,o,a,r,h,l,c,u,d=null,p=null;for(i=this.containers.length-1;i>=0;i--)if(!t.contains(this.currentItem[0],this.containers[i].element[0]))if(this._intersectsWith(this.containers[i].containerCache)){if(d&&t.contains(this.containers[i].element[0],d.element[0]))continue;d=this.containers[i],p=i}else this.containers[i].containerCache.over&&(this.containers[i]._trigger("out",e,this._uiHash(this)),this.containers[i].containerCache.over=0);if(d)if(1===this.containers.length)this.containers[p].containerCache.over||(this.containers[p]._trigger("over",e,this._uiHash(this)),this.containers[p].containerCache.over=1);else{for(n=1e4,o=null,c=d.floating||this._isFloating(this.currentItem),a=c?"left":"top",r=c?"width":"height",u=c?"pageX":"pageY",s=this.items.length-1;s>=0;s--)t.contains(this.containers[p].element[0],this.items[s].item[0])&&this.items[s].item[0]!==this.currentItem[0]&&(h=this.items[s].item.offset()[a],l=!1,e[u]-h>this.items[s][r]/2&&(l=!0),n>Math.abs(e[u]-h)&&(n=Math.abs(e[u]-h),o=this.items[s],this.direction=l?"up":"down"));if(!o&&!this.options.dropOnEmpty)return;if(this.currentContainer===this.containers[p])return this.currentContainer.containerCache.over||(this.containers[p]._trigger("over",e,this._uiHash()),this.currentContainer.containerCache.over=1),void 0;o?this._rearrange(e,o,null,!0):this._rearrange(e,null,this.containers[p].element,!0),this._trigger("change",e,this._uiHash()),this.containers[p]._trigger("change",e,this._uiHash(this)),this.currentContainer=this.containers[p],this.options.placeholder.update(this.currentContainer,this.placeholder),this.containers[p]._trigger("over",e,this._uiHash(this)),this.containers[p].containerCache.over=1}},_createHelper:function(e){var i=this.options,s=t.isFunction(i.helper)?t(i.helper.apply(this.element[0],[e,this.currentItem])):"clone"===i.helper?this.currentItem.clone():this.currentItem;return s.parents("body").length||t("parent"!==i.appendTo?i.appendTo:this.currentItem[0].parentNode)[0].appendChild(s[0]),s[0]===this.currentItem[0]&&(this._storedCSS={width:this.currentItem[0].style.width,height:this.currentItem[0].style.height,position:this.currentItem.css("position"),top:this.currentItem.css("top"),left:this.currentItem.css("left")}),(!s[0].style.width||i.forceHelperSize)&&s.width(this.currentItem.width()),(!s[0].style.height||i.forceHelperSize)&&s.height(this.currentItem.height()),s},_adjustOffsetFromHelper:function(e){"string"==typeof e&&(e=e.split(" ")),t.isArray(e)&&(e={left:+e[0],top:+e[1]||0}),"left"in e&&(this.offset.click.left=e.left+this.margins.left),"right"in e&&(this.offset.click.left=this.helperProportions.width-e.right+this.margins.left),"top"in e&&(this.offset.click.top=e.top+this.margins.top),"bottom"in e&&(this.offset.click.top=this.helperProportions.height-e.bottom+this.margins.top)},_getParentOffset:function(){this.offsetParent=this.helper.offsetParent();var e=this.offsetParent.offset();return"absolute"===this.cssPosition&&this.scrollParent[0]!==this.document[0]&&t.contains(this.scrollParent[0],this.offsetParent[0])&&(e.left+=this.scrollParent.scrollLeft(),e.top+=this.scrollParent.scrollTop()),(this.offsetParent[0]===this.document[0].body||this.offsetParent[0].tagName&&"html"===this.offsetParent[0].tagName.toLowerCase()&&t.ui.ie)&&(e={top:0,left:0}),{top:e.top+(parseInt(this.offsetParent.css("borderTopWidth"),10)||0),left:e.left+(parseInt(this.offsetParent.css("borderLeftWidth"),10)||0)}},_getRelativeOffset:function(){if("relative"===this.cssPosition){var t=this.currentItem.position();return{top:t.top-(parseInt(this.helper.css("top"),10)||0)+this.scrollParent.scrollTop(),left:t.left-(parseInt(this.helper.css("left"),10)||0)+this.scrollParent.scrollLeft()}}return{top:0,left:0}},_cacheMargins:function(){this.margins={left:parseInt(this.currentItem.css("marginLeft"),10)||0,top:parseInt(this.currentItem.css("marginTop"),10)||0}},_cacheHelperProportions:function(){this.helperProportions={width:this.helper.outerWidth(),height:this.helper.outerHeight()}},_setContainment:function(){var e,i,s,n=this.options;"parent"===n.containment&&(n.containment=this.helper[0].parentNode),("document"===n.containment||"window"===n.containment)&&(this.containment=[0-this.offset.relative.left-this.offset.parent.left,0-this.offset.relative.top-this.offset.parent.top,"document"===n.containment?this.document.width():this.window.width()-this.helperProportions.width-this.margins.left,("document"===n.containment?this.document.height()||document.body.parentNode.scrollHeight:this.window.height()||this.document[0].body.parentNode.scrollHeight)-this.helperProportions.height-this.margins.top]),/^(document|window|parent)$/.test(n.containment)||(e=t(n.containment)[0],i=t(n.containment).offset(),s="hidden"!==t(e).css("overflow"),this.containment=[i.left+(parseInt(t(e).css("borderLeftWidth"),10)||0)+(parseInt(t(e).css("paddingLeft"),10)||0)-this.margins.left,i.top+(parseInt(t(e).css("borderTopWidth"),10)||0)+(parseInt(t(e).css("paddingTop"),10)||0)-this.margins.top,i.left+(s?Math.max(e.scrollWidth,e.offsetWidth):e.offsetWidth)-(parseInt(t(e).css("borderLeftWidth"),10)||0)-(parseInt(t(e).css("paddingRight"),10)||0)-this.helperProportions.width-this.margins.left,i.top+(s?Math.max(e.scrollHeight,e.offsetHeight):e.offsetHeight)-(parseInt(t(e).css("borderTopWidth"),10)||0)-(parseInt(t(e).css("paddingBottom"),10)||0)-this.helperProportions.height-this.margins.top])},_convertPositionTo:function(e,i){i||(i=this.position);var s="absolute"===e?1:-1,n="absolute"!==this.cssPosition||this.scrollParent[0]!==this.document[0]&&t.contains(this.scrollParent[0],this.offsetParent[0])?this.scrollParent:this.offsetParent,o=/(html|body)/i.test(n[0].tagName);return{top:i.top+this.offset.relative.top*s+this.offset.parent.top*s-("fixed"===this.cssPosition?-this.scrollParent.scrollTop():o?0:n.scrollTop())*s,left:i.left+this.offset.relative.left*s+this.offset.parent.left*s-("fixed"===this.cssPosition?-this.scrollParent.scrollLeft():o?0:n.scrollLeft())*s}},_generatePosition:function(e){var i,s,n=this.options,o=e.pageX,a=e.pageY,r="absolute"!==this.cssPosition||this.scrollParent[0]!==this.document[0]&&t.contains(this.scrollParent[0],this.offsetParent[0])?this.scrollParent:this.offsetParent,h=/(html|body)/i.test(r[0].tagName);return"relative"!==this.cssPosition||this.scrollParent[0]!==this.document[0]&&this.scrollParent[0]!==this.offsetParent[0]||(this.offset.relative=this._getRelativeOffset()),this.originalPosition&&(this.containment&&(e.pageX-this.offset.click.left<this.containment[0]&&(o=this.containment[0]+this.offset.click.left),e.pageY-this.offset.click.top<this.containment[1]&&(a=this.containment[1]+this.offset.click.top),e.pageX-this.offset.click.left>this.containment[2]&&(o=this.containment[2]+this.offset.click.left),e.pageY-this.offset.click.top>this.containment[3]&&(a=this.containment[3]+this.offset.click.top)),n.grid&&(i=this.originalPageY+Math.round((a-this.originalPageY)/n.grid[1])*n.grid[1],a=this.containment?i-this.offset.click.top>=this.containment[1]&&i-this.offset.click.top<=this.containment[3]?i:i-this.offset.click.top>=this.containment[1]?i-n.grid[1]:i+n.grid[1]:i,s=this.originalPageX+Math.round((o-this.originalPageX)/n.grid[0])*n.grid[0],o=this.containment?s-this.offset.click.left>=this.containment[0]&&s-this.offset.click.left<=this.containment[2]?s:s-this.offset.click.left>=this.containment[0]?s-n.grid[0]:s+n.grid[0]:s)),{top:a-this.offset.click.top-this.offset.relative.top-this.offset.parent.top+("fixed"===this.cssPosition?-this.scrollParent.scrollTop():h?0:r.scrollTop()),left:o-this.offset.click.left-this.offset.relative.left-this.offset.parent.left+("fixed"===this.cssPosition?-this.scrollParent.scrollLeft():h?0:r.scrollLeft())}},_rearrange:function(t,e,i,s){i?i[0].appendChild(this.placeholder[0]):e.item[0].parentNode.insertBefore(this.placeholder[0],"down"===this.direction?e.item[0]:e.item[0].nextSibling),this.counter=this.counter?++this.counter:1;var n=this.counter;
-this._delay(function(){n===this.counter&&this.refreshPositions(!s)})},_clear:function(t,e){function i(t,e,i){return function(s){i._trigger(t,s,e._uiHash(e))}}this.reverting=!1;var s,n=[];if(!this._noFinalSort&&this.currentItem.parent().length&&this.placeholder.before(this.currentItem),this._noFinalSort=null,this.helper[0]===this.currentItem[0]){for(s in this._storedCSS)("auto"===this._storedCSS[s]||"static"===this._storedCSS[s])&&(this._storedCSS[s]="");this.currentItem.css(this._storedCSS),this._removeClass(this.currentItem,"ui-sortable-helper")}else this.currentItem.show();for(this.fromOutside&&!e&&n.push(function(t){this._trigger("receive",t,this._uiHash(this.fromOutside))}),!this.fromOutside&&this.domPosition.prev===this.currentItem.prev().not(".ui-sortable-helper")[0]&&this.domPosition.parent===this.currentItem.parent()[0]||e||n.push(function(t){this._trigger("update",t,this._uiHash())}),this!==this.currentContainer&&(e||(n.push(function(t){this._trigger("remove",t,this._uiHash())}),n.push(function(t){return function(e){t._trigger("receive",e,this._uiHash(this))}}.call(this,this.currentContainer)),n.push(function(t){return function(e){t._trigger("update",e,this._uiHash(this))}}.call(this,this.currentContainer)))),s=this.containers.length-1;s>=0;s--)e||n.push(i("deactivate",this,this.containers[s])),this.containers[s].containerCache.over&&(n.push(i("out",this,this.containers[s])),this.containers[s].containerCache.over=0);if(this.storedCursor&&(this.document.find("body").css("cursor",this.storedCursor),this.storedStylesheet.remove()),this._storedOpacity&&this.helper.css("opacity",this._storedOpacity),this._storedZIndex&&this.helper.css("zIndex","auto"===this._storedZIndex?"":this._storedZIndex),this.dragging=!1,e||this._trigger("beforeStop",t,this._uiHash()),this.placeholder[0].parentNode.removeChild(this.placeholder[0]),this.cancelHelperRemoval||(this.helper[0]!==this.currentItem[0]&&this.helper.remove(),this.helper=null),!e){for(s=0;n.length>s;s++)n[s].call(this,t);this._trigger("stop",t,this._uiHash())}return this.fromOutside=!1,!this.cancelHelperRemoval},_trigger:function(){t.Widget.prototype._trigger.apply(this,arguments)===!1&&this.cancel()},_uiHash:function(e){var i=e||this;return{helper:i.helper,placeholder:i.placeholder||t([]),position:i.position,originalPosition:i.originalPosition,offset:i.positionAbs,item:i.currentItem,sender:e?e.element:null}}}),t.widget("ui.spinner",{version:"1.12.1",defaultElement:"<input>",widgetEventPrefix:"spin",options:{classes:{"ui-spinner":"ui-corner-all","ui-spinner-down":"ui-corner-br","ui-spinner-up":"ui-corner-tr"},culture:null,icons:{down:"ui-icon-triangle-1-s",up:"ui-icon-triangle-1-n"},incremental:!0,max:null,min:null,numberFormat:null,page:10,step:1,change:null,spin:null,start:null,stop:null},_create:function(){this._setOption("max",this.options.max),this._setOption("min",this.options.min),this._setOption("step",this.options.step),""!==this.value()&&this._value(this.element.val(),!0),this._draw(),this._on(this._events),this._refresh(),this._on(this.window,{beforeunload:function(){this.element.removeAttr("autocomplete")}})},_getCreateOptions:function(){var e=this._super(),i=this.element;return t.each(["min","max","step"],function(t,s){var n=i.attr(s);null!=n&&n.length&&(e[s]=n)}),e},_events:{keydown:function(t){this._start(t)&&this._keydown(t)&&t.preventDefault()},keyup:"_stop",focus:function(){this.previous=this.element.val()},blur:function(t){return this.cancelBlur?(delete this.cancelBlur,void 0):(this._stop(),this._refresh(),this.previous!==this.element.val()&&this._trigger("change",t),void 0)},mousewheel:function(t,e){if(e){if(!this.spinning&&!this._start(t))return!1;this._spin((e>0?1:-1)*this.options.step,t),clearTimeout(this.mousewheelTimer),this.mousewheelTimer=this._delay(function(){this.spinning&&this._stop(t)},100),t.preventDefault()}},"mousedown .ui-spinner-button":function(e){function i(){var e=this.element[0]===t.ui.safeActiveElement(this.document[0]);e||(this.element.trigger("focus"),this.previous=s,this._delay(function(){this.previous=s}))}var s;s=this.element[0]===t.ui.safeActiveElement(this.document[0])?this.previous:this.element.val(),e.preventDefault(),i.call(this),this.cancelBlur=!0,this._delay(function(){delete this.cancelBlur,i.call(this)}),this._start(e)!==!1&&this._repeat(null,t(e.currentTarget).hasClass("ui-spinner-up")?1:-1,e)},"mouseup .ui-spinner-button":"_stop","mouseenter .ui-spinner-button":function(e){return t(e.currentTarget).hasClass("ui-state-active")?this._start(e)===!1?!1:(this._repeat(null,t(e.currentTarget).hasClass("ui-spinner-up")?1:-1,e),void 0):void 0},"mouseleave .ui-spinner-button":"_stop"},_enhance:function(){this.uiSpinner=this.element.attr("autocomplete","off").wrap("<span>").parent().append("<a></a><a></a>")},_draw:function(){this._enhance(),this._addClass(this.uiSpinner,"ui-spinner","ui-widget ui-widget-content"),this._addClass("ui-spinner-input"),this.element.attr("role","spinbutton"),this.buttons=this.uiSpinner.children("a").attr("tabIndex",-1).attr("aria-hidden",!0).button({classes:{"ui-button":""}}),this._removeClass(this.buttons,"ui-corner-all"),this._addClass(this.buttons.first(),"ui-spinner-button ui-spinner-up"),this._addClass(this.buttons.last(),"ui-spinner-button ui-spinner-down"),this.buttons.first().button({icon:this.options.icons.up,showLabel:!1}),this.buttons.last().button({icon:this.options.icons.down,showLabel:!1}),this.buttons.height()>Math.ceil(.5*this.uiSpinner.height())&&this.uiSpinner.height()>0&&this.uiSpinner.height(this.uiSpinner.height())},_keydown:function(e){var i=this.options,s=t.ui.keyCode;switch(e.keyCode){case s.UP:return this._repeat(null,1,e),!0;case s.DOWN:return this._repeat(null,-1,e),!0;case s.PAGE_UP:return this._repeat(null,i.page,e),!0;case s.PAGE_DOWN:return this._repeat(null,-i.page,e),!0}return!1},_start:function(t){return this.spinning||this._trigger("start",t)!==!1?(this.counter||(this.counter=1),this.spinning=!0,!0):!1},_repeat:function(t,e,i){t=t||500,clearTimeout(this.timer),this.timer=this._delay(function(){this._repeat(40,e,i)},t),this._spin(e*this.options.step,i)},_spin:function(t,e){var i=this.value()||0;this.counter||(this.counter=1),i=this._adjustValue(i+t*this._increment(this.counter)),this.spinning&&this._trigger("spin",e,{value:i})===!1||(this._value(i),this.counter++)},_increment:function(e){var i=this.options.incremental;return i?t.isFunction(i)?i(e):Math.floor(e*e*e/5e4-e*e/500+17*e/200+1):1},_precision:function(){var t=this._precisionOf(this.options.step);return null!==this.options.min&&(t=Math.max(t,this._precisionOf(this.options.min))),t},_precisionOf:function(t){var e=""+t,i=e.indexOf(".");return-1===i?0:e.length-i-1},_adjustValue:function(t){var e,i,s=this.options;return e=null!==s.min?s.min:0,i=t-e,i=Math.round(i/s.step)*s.step,t=e+i,t=parseFloat(t.toFixed(this._precision())),null!==s.max&&t>s.max?s.max:null!==s.min&&s.min>t?s.min:t},_stop:function(t){this.spinning&&(clearTimeout(this.timer),clearTimeout(this.mousewheelTimer),this.counter=0,this.spinning=!1,this._trigger("stop",t))},_setOption:function(t,e){var i,s,n;return"culture"===t||"numberFormat"===t?(i=this._parse(this.element.val()),this.options[t]=e,this.element.val(this._format(i)),void 0):(("max"===t||"min"===t||"step"===t)&&"string"==typeof e&&(e=this._parse(e)),"icons"===t&&(s=this.buttons.first().find(".ui-icon"),this._removeClass(s,null,this.options.icons.up),this._addClass(s,null,e.up),n=this.buttons.last().find(".ui-icon"),this._removeClass(n,null,this.options.icons.down),this._addClass(n,null,e.down)),this._super(t,e),void 0)},_setOptionDisabled:function(t){this._super(t),this._toggleClass(this.uiSpinner,null,"ui-state-disabled",!!t),this.element.prop("disabled",!!t),this.buttons.button(t?"disable":"enable")},_setOptions:r(function(t){this._super(t)}),_parse:function(t){return"string"==typeof t&&""!==t&&(t=window.Globalize&&this.options.numberFormat?Globalize.parseFloat(t,10,this.options.culture):+t),""===t||isNaN(t)?null:t},_format:function(t){return""===t?"":window.Globalize&&this.options.numberFormat?Globalize.format(t,this.options.numberFormat,this.options.culture):t},_refresh:function(){this.element.attr({"aria-valuemin":this.options.min,"aria-valuemax":this.options.max,"aria-valuenow":this._parse(this.element.val())})},isValid:function(){var t=this.value();return null===t?!1:t===this._adjustValue(t)},_value:function(t,e){var i;""!==t&&(i=this._parse(t),null!==i&&(e||(i=this._adjustValue(i)),t=this._format(i))),this.element.val(t),this._refresh()},_destroy:function(){this.element.prop("disabled",!1).removeAttr("autocomplete role aria-valuemin aria-valuemax aria-valuenow"),this.uiSpinner.replaceWith(this.element)},stepUp:r(function(t){this._stepUp(t)}),_stepUp:function(t){this._start()&&(this._spin((t||1)*this.options.step),this._stop())},stepDown:r(function(t){this._stepDown(t)}),_stepDown:function(t){this._start()&&(this._spin((t||1)*-this.options.step),this._stop())},pageUp:r(function(t){this._stepUp((t||1)*this.options.page)}),pageDown:r(function(t){this._stepDown((t||1)*this.options.page)}),value:function(t){return arguments.length?(r(this._value).call(this,t),void 0):this._parse(this.element.val())},widget:function(){return this.uiSpinner}}),t.uiBackCompat!==!1&&t.widget("ui.spinner",t.ui.spinner,{_enhance:function(){this.uiSpinner=this.element.attr("autocomplete","off").wrap(this._uiSpinnerHtml()).parent().append(this._buttonHtml())},_uiSpinnerHtml:function(){return"<span>"},_buttonHtml:function(){return"<a></a><a></a>"}}),t.ui.spinner,t.widget("ui.tabs",{version:"1.12.1",delay:300,options:{active:null,classes:{"ui-tabs":"ui-corner-all","ui-tabs-nav":"ui-corner-all","ui-tabs-panel":"ui-corner-bottom","ui-tabs-tab":"ui-corner-top"},collapsible:!1,event:"click",heightStyle:"content",hide:null,show:null,activate:null,beforeActivate:null,beforeLoad:null,load:null},_isLocal:function(){var t=/#.*$/;return function(e){var i,s;i=e.href.replace(t,""),s=location.href.replace(t,"");try{i=decodeURIComponent(i)}catch(n){}try{s=decodeURIComponent(s)}catch(n){}return e.hash.length>1&&i===s}}(),_create:function(){var e=this,i=this.options;this.running=!1,this._addClass("ui-tabs","ui-widget ui-widget-content"),this._toggleClass("ui-tabs-collapsible",null,i.collapsible),this._processTabs(),i.active=this._initialActive(),t.isArray(i.disabled)&&(i.disabled=t.unique(i.disabled.concat(t.map(this.tabs.filter(".ui-state-disabled"),function(t){return e.tabs.index(t)}))).sort()),this.active=this.options.active!==!1&&this.anchors.length?this._findActive(i.active):t(),this._refresh(),this.active.length&&this.load(i.active)},_initialActive:function(){var e=this.options.active,i=this.options.collapsible,s=location.hash.substring(1);return null===e&&(s&&this.tabs.each(function(i,n){return t(n).attr("aria-controls")===s?(e=i,!1):void 0}),null===e&&(e=this.tabs.index(this.tabs.filter(".ui-tabs-active"))),(null===e||-1===e)&&(e=this.tabs.length?0:!1)),e!==!1&&(e=this.tabs.index(this.tabs.eq(e)),-1===e&&(e=i?!1:0)),!i&&e===!1&&this.anchors.length&&(e=0),e},_getCreateEventData:function(){return{tab:this.active,panel:this.active.length?this._getPanelForTab(this.active):t()}},_tabKeydown:function(e){var i=t(t.ui.safeActiveElement(this.document[0])).closest("li"),s=this.tabs.index(i),n=!0;if(!this._handlePageNav(e)){switch(e.keyCode){case t.ui.keyCode.RIGHT:case t.ui.keyCode.DOWN:s++;break;case t.ui.keyCode.UP:case t.ui.keyCode.LEFT:n=!1,s--;break;case t.ui.keyCode.END:s=this.anchors.length-1;break;case t.ui.keyCode.HOME:s=0;break;case t.ui.keyCode.SPACE:return e.preventDefault(),clearTimeout(this.activating),this._activate(s),void 0;case t.ui.keyCode.ENTER:return e.preventDefault(),clearTimeout(this.activating),this._activate(s===this.options.active?!1:s),void 0;default:return}e.preventDefault(),clearTimeout(this.activating),s=this._focusNextTab(s,n),e.ctrlKey||e.metaKey||(i.attr("aria-selected","false"),this.tabs.eq(s).attr("aria-selected","true"),this.activating=this._delay(function(){this.option("active",s)},this.delay))}},_panelKeydown:function(e){this._handlePageNav(e)||e.ctrlKey&&e.keyCode===t.ui.keyCode.UP&&(e.preventDefault(),this.active.trigger("focus"))},_handlePageNav:function(e){return e.altKey&&e.keyCode===t.ui.keyCode.PAGE_UP?(this._activate(this._focusNextTab(this.options.active-1,!1)),!0):e.altKey&&e.keyCode===t.ui.keyCode.PAGE_DOWN?(this._activate(this._focusNextTab(this.options.active+1,!0)),!0):void 0},_findNextTab:function(e,i){function s(){return e>n&&(e=0),0>e&&(e=n),e}for(var n=this.tabs.length-1;-1!==t.inArray(s(),this.options.disabled);)e=i?e+1:e-1;return e},_focusNextTab:function(t,e){return t=this._findNextTab(t,e),this.tabs.eq(t).trigger("focus"),t},_setOption:function(t,e){return"active"===t?(this._activate(e),void 0):(this._super(t,e),"collapsible"===t&&(this._toggleClass("ui-tabs-collapsible",null,e),e||this.options.active!==!1||this._activate(0)),"event"===t&&this._setupEvents(e),"heightStyle"===t&&this._setupHeightStyle(e),void 0)},_sanitizeSelector:function(t){return t?t.replace(/[!"$%&'()*+,.\/:;<=>?@\[\]\^`{|}~]/g,"\\$&"):""},refresh:function(){var e=this.options,i=this.tablist.children(":has(a[href])");e.disabled=t.map(i.filter(".ui-state-disabled"),function(t){return i.index(t)}),this._processTabs(),e.active!==!1&&this.anchors.length?this.active.length&&!t.contains(this.tablist[0],this.active[0])?this.tabs.length===e.disabled.length?(e.active=!1,this.active=t()):this._activate(this._findNextTab(Math.max(0,e.active-1),!1)):e.active=this.tabs.index(this.active):(e.active=!1,this.active=t()),this._refresh()},_refresh:function(){this._setOptionDisabled(this.options.disabled),this._setupEvents(this.options.event),this._setupHeightStyle(this.options.heightStyle),this.tabs.not(this.active).attr({"aria-selected":"false","aria-expanded":"false",tabIndex:-1}),this.panels.not(this._getPanelForTab(this.active)).hide().attr({"aria-hidden":"true"}),this.active.length?(this.active.attr({"aria-selected":"true","aria-expanded":"true",tabIndex:0}),this._addClass(this.active,"ui-tabs-active","ui-state-active"),this._getPanelForTab(this.active).show().attr({"aria-hidden":"false"})):this.tabs.eq(0).attr("tabIndex",0)},_processTabs:function(){var e=this,i=this.tabs,s=this.anchors,n=this.panels;this.tablist=this._getList().attr("role","tablist"),this._addClass(this.tablist,"ui-tabs-nav","ui-helper-reset ui-helper-clearfix ui-widget-header"),this.tablist.on("mousedown"+this.eventNamespace,"> li",function(e){t(this).is(".ui-state-disabled")&&e.preventDefault()}).on("focus"+this.eventNamespace,".ui-tabs-anchor",function(){t(this).closest("li").is(".ui-state-disabled")&&this.blur()}),this.tabs=this.tablist.find("> li:has(a[href])").attr({role:"tab",tabIndex:-1}),this._addClass(this.tabs,"ui-tabs-tab","ui-state-default"),this.anchors=this.tabs.map(function(){return t("a",this)[0]}).attr({role:"presentation",tabIndex:-1}),this._addClass(this.anchors,"ui-tabs-anchor"),this.panels=t(),this.anchors.each(function(i,s){var n,o,a,r=t(s).uniqueId().attr("id"),h=t(s).closest("li"),l=h.attr("aria-controls");e._isLocal(s)?(n=s.hash,a=n.substring(1),o=e.element.find(e._sanitizeSelector(n))):(a=h.attr("aria-controls")||t({}).uniqueId()[0].id,n="#"+a,o=e.element.find(n),o.length||(o=e._createPanel(a),o.insertAfter(e.panels[i-1]||e.tablist)),o.attr("aria-live","polite")),o.length&&(e.panels=e.panels.add(o)),l&&h.data("ui-tabs-aria-controls",l),h.attr({"aria-controls":a,"aria-labelledby":r}),o.attr("aria-labelledby",r)}),this.panels.attr("role","tabpanel"),this._addClass(this.panels,"ui-tabs-panel","ui-widget-content"),i&&(this._off(i.not(this.tabs)),this._off(s.not(this.anchors)),this._off(n.not(this.panels)))},_getList:function(){return this.tablist||this.element.find("ol, ul").eq(0)},_createPanel:function(e){return t("<div>").attr("id",e).data("ui-tabs-destroy",!0)},_setOptionDisabled:function(e){var i,s,n;for(t.isArray(e)&&(e.length?e.length===this.anchors.length&&(e=!0):e=!1),n=0;s=this.tabs[n];n++)i=t(s),e===!0||-1!==t.inArray(n,e)?(i.attr("aria-disabled","true"),this._addClass(i,null,"ui-state-disabled")):(i.removeAttr("aria-disabled"),this._removeClass(i,null,"ui-state-disabled"));this.options.disabled=e,this._toggleClass(this.widget(),this.widgetFullName+"-disabled",null,e===!0)},_setupEvents:function(e){var i={};e&&t.each(e.split(" "),function(t,e){i[e]="_eventHandler"}),this._off(this.anchors.add(this.tabs).add(this.panels)),this._on(!0,this.anchors,{click:function(t){t.preventDefault()}}),this._on(this.anchors,i),this._on(this.tabs,{keydown:"_tabKeydown"}),this._on(this.panels,{keydown:"_panelKeydown"}),this._focusable(this.tabs),this._hoverable(this.tabs)},_setupHeightStyle:function(e){var i,s=this.element.parent();"fill"===e?(i=s.height(),i-=this.element.outerHeight()-this.element.height(),this.element.siblings(":visible").each(function(){var e=t(this),s=e.css("position");"absolute"!==s&&"fixed"!==s&&(i-=e.outerHeight(!0))}),this.element.children().not(this.panels).each(function(){i-=t(this).outerHeight(!0)}),this.panels.each(function(){t(this).height(Math.max(0,i-t(this).innerHeight()+t(this).height()))}).css("overflow","auto")):"auto"===e&&(i=0,this.panels.each(function(){i=Math.max(i,t(this).height("").height())}).height(i))},_eventHandler:function(e){var i=this.options,s=this.active,n=t(e.currentTarget),o=n.closest("li"),a=o[0]===s[0],r=a&&i.collapsible,h=r?t():this._getPanelForTab(o),l=s.length?this._getPanelForTab(s):t(),c={oldTab:s,oldPanel:l,newTab:r?t():o,newPanel:h};e.preventDefault(),o.hasClass("ui-state-disabled")||o.hasClass("ui-tabs-loading")||this.running||a&&!i.collapsible||this._trigger("beforeActivate",e,c)===!1||(i.active=r?!1:this.tabs.index(o),this.active=a?t():o,this.xhr&&this.xhr.abort(),l.length||h.length||t.error("jQuery UI Tabs: Mismatching fragment identifier."),h.length&&this.load(this.tabs.index(o),e),this._toggle(e,c))},_toggle:function(e,i){function s(){o.running=!1,o._trigger("activate",e,i)}function n(){o._addClass(i.newTab.closest("li"),"ui-tabs-active","ui-state-active"),a.length&&o.options.show?o._show(a,o.options.show,s):(a.show(),s())}var o=this,a=i.newPanel,r=i.oldPanel;this.running=!0,r.length&&this.options.hide?this._hide(r,this.options.hide,function(){o._removeClass(i.oldTab.closest("li"),"ui-tabs-active","ui-state-active"),n()}):(this._removeClass(i.oldTab.closest("li"),"ui-tabs-active","ui-state-active"),r.hide(),n()),r.attr("aria-hidden","true"),i.oldTab.attr({"aria-selected":"false","aria-expanded":"false"}),a.length&&r.length?i.oldTab.attr("tabIndex",-1):a.length&&this.tabs.filter(function(){return 0===t(this).attr("tabIndex")}).attr("tabIndex",-1),a.attr("aria-hidden","false"),i.newTab.attr({"aria-selected":"true","aria-expanded":"true",tabIndex:0})},_activate:function(e){var i,s=this._findActive(e);s[0]!==this.active[0]&&(s.length||(s=this.active),i=s.find(".ui-tabs-anchor")[0],this._eventHandler({target:i,currentTarget:i,preventDefault:t.noop}))},_findActive:function(e){return e===!1?t():this.tabs.eq(e)},_getIndex:function(e){return"string"==typeof e&&(e=this.anchors.index(this.anchors.filter("[href$='"+t.ui.escapeSelector(e)+"']"))),e},_destroy:function(){this.xhr&&this.xhr.abort(),this.tablist.removeAttr("role").off(this.eventNamespace),this.anchors.removeAttr("role tabIndex").removeUniqueId(),this.tabs.add(this.panels).each(function(){t.data(this,"ui-tabs-destroy")?t(this).remove():t(this).removeAttr("role tabIndex aria-live aria-busy aria-selected aria-labelledby aria-hidden aria-expanded")}),this.tabs.each(function(){var e=t(this),i=e.data("ui-tabs-aria-controls");i?e.attr("aria-controls",i).removeData("ui-tabs-aria-controls"):e.removeAttr("aria-controls")}),this.panels.show(),"content"!==this.options.heightStyle&&this.panels.css("height","")},enable:function(e){var i=this.options.disabled;i!==!1&&(void 0===e?i=!1:(e=this._getIndex(e),i=t.isArray(i)?t.map(i,function(t){return t!==e?t:null}):t.map(this.tabs,function(t,i){return i!==e?i:null})),this._setOptionDisabled(i))},disable:function(e){var i=this.options.disabled;if(i!==!0){if(void 0===e)i=!0;else{if(e=this._getIndex(e),-1!==t.inArray(e,i))return;i=t.isArray(i)?t.merge([e],i).sort():[e]}this._setOptionDisabled(i)}},load:function(e,i){e=this._getIndex(e);var s=this,n=this.tabs.eq(e),o=n.find(".ui-tabs-anchor"),a=this._getPanelForTab(n),r={tab:n,panel:a},h=function(t,e){"abort"===e&&s.panels.stop(!1,!0),s._removeClass(n,"ui-tabs-loading"),a.removeAttr("aria-busy"),t===s.xhr&&delete s.xhr};this._isLocal(o[0])||(this.xhr=t.ajax(this._ajaxSettings(o,i,r)),this.xhr&&"canceled"!==this.xhr.statusText&&(this._addClass(n,"ui-tabs-loading"),a.attr("aria-busy","true"),this.xhr.done(function(t,e,n){setTimeout(function(){a.html(t),s._trigger("load",i,r),h(n,e)},1)}).fail(function(t,e){setTimeout(function(){h(t,e)},1)})))},_ajaxSettings:function(e,i,s){var n=this;return{url:e.attr("href").replace(/#.*$/,""),beforeSend:function(e,o){return n._trigger("beforeLoad",i,t.extend({jqXHR:e,ajaxSettings:o},s))}}},_getPanelForTab:function(e){var i=t(e).attr("aria-controls");return this.element.find(this._sanitizeSelector("#"+i))}}),t.uiBackCompat!==!1&&t.widget("ui.tabs",t.ui.tabs,{_processTabs:function(){this._superApply(arguments),this._addClass(this.tabs,"ui-tab")}}),t.ui.tabs,t.widget("ui.tooltip",{version:"1.12.1",options:{classes:{"ui-tooltip":"ui-corner-all ui-widget-shadow"},content:function(){var e=t(this).attr("title")||"";return t("<a>").text(e).html()},hide:!0,items:"[title]:not([disabled])",position:{my:"left top+15",at:"left bottom",collision:"flipfit flip"},show:!0,track:!1,close:null,open:null},_addDescribedBy:function(e,i){var s=(e.attr("aria-describedby")||"").split(/\s+/);s.push(i),e.data("ui-tooltip-id",i).attr("aria-describedby",t.trim(s.join(" ")))},_removeDescribedBy:function(e){var i=e.data("ui-tooltip-id"),s=(e.attr("aria-describedby")||"").split(/\s+/),n=t.inArray(i,s);-1!==n&&s.splice(n,1),e.removeData("ui-tooltip-id"),s=t.trim(s.join(" ")),s?e.attr("aria-describedby",s):e.removeAttr("aria-describedby")},_create:function(){this._on({mouseover:"open",focusin:"open"}),this.tooltips={},this.parents={},this.liveRegion=t("<div>").attr({role:"log","aria-live":"assertive","aria-relevant":"additions"}).appendTo(this.document[0].body),this._addClass(this.liveRegion,null,"ui-helper-hidden-accessible"),this.disabledTitles=t([])},_setOption:function(e,i){var s=this;this._super(e,i),"content"===e&&t.each(this.tooltips,function(t,e){s._updateContent(e.element)})},_setOptionDisabled:function(t){this[t?"_disable":"_enable"]()},_disable:function(){var e=this;t.each(this.tooltips,function(i,s){var n=t.Event("blur");n.target=n.currentTarget=s.element[0],e.close(n,!0)}),this.disabledTitles=this.disabledTitles.add(this.element.find(this.options.items).addBack().filter(function(){var e=t(this);return e.is("[title]")?e.data("ui-tooltip-title",e.attr("title")).removeAttr("title"):void 0}))},_enable:function(){this.disabledTitles.each(function(){var e=t(this);e.data("ui-tooltip-title")&&e.attr("title",e.data("ui-tooltip-title"))}),this.disabledTitles=t([])},open:function(e){var i=this,s=t(e?e.target:this.element).closest(this.options.items);s.length&&!s.data("ui-tooltip-id")&&(s.attr("title")&&s.data("ui-tooltip-title",s.attr("title")),s.data("ui-tooltip-open",!0),e&&"mouseover"===e.type&&s.parents().each(function(){var e,s=t(this);s.data("ui-tooltip-open")&&(e=t.Event("blur"),e.target=e.currentTarget=this,i.close(e,!0)),s.attr("title")&&(s.uniqueId(),i.parents[this.id]={element:this,title:s.attr("title")},s.attr("title",""))}),this._registerCloseHandlers(e,s),this._updateContent(s,e))},_updateContent:function(t,e){var i,s=this.options.content,n=this,o=e?e.type:null;return"string"==typeof s||s.nodeType||s.jquery?this._open(e,t,s):(i=s.call(t[0],function(i){n._delay(function(){t.data("ui-tooltip-open")&&(e&&(e.type=o),this._open(e,t,i))})}),i&&this._open(e,t,i),void 0)},_open:function(e,i,s){function n(t){l.of=t,a.is(":hidden")||a.position(l)}var o,a,r,h,l=t.extend({},this.options.position);if(s){if(o=this._find(i))return o.tooltip.find(".ui-tooltip-content").html(s),void 0;i.is("[title]")&&(e&&"mouseover"===e.type?i.attr("title",""):i.removeAttr("title")),o=this._tooltip(i),a=o.tooltip,this._addDescribedBy(i,a.attr("id")),a.find(".ui-tooltip-content").html(s),this.liveRegion.children().hide(),h=t("<div>").html(a.find(".ui-tooltip-content").html()),h.removeAttr("name").find("[name]").removeAttr("name"),h.removeAttr("id").find("[id]").removeAttr("id"),h.appendTo(this.liveRegion),this.options.track&&e&&/^mouse/.test(e.type)?(this._on(this.document,{mousemove:n}),n(e)):a.position(t.extend({of:i},this.options.position)),a.hide(),this._show(a,this.options.show),this.options.track&&this.options.show&&this.options.show.delay&&(r=this.delayedShow=setInterval(function(){a.is(":visible")&&(n(l.of),clearInterval(r))},t.fx.interval)),this._trigger("open",e,{tooltip:a})}},_registerCloseHandlers:function(e,i){var s={keyup:function(e){if(e.keyCode===t.ui.keyCode.ESCAPE){var s=t.Event(e);s.currentTarget=i[0],this.close(s,!0)}}};i[0]!==this.element[0]&&(s.remove=function(){this._removeTooltip(this._find(i).tooltip)}),e&&"mouseover"!==e.type||(s.mouseleave="close"),e&&"focusin"!==e.type||(s.focusout="close"),this._on(!0,i,s)},close:function(e){var i,s=this,n=t(e?e.currentTarget:this.element),o=this._find(n);return o?(i=o.tooltip,o.closing||(clearInterval(this.delayedShow),n.data("ui-tooltip-title")&&!n.attr("title")&&n.attr("title",n.data("ui-tooltip-title")),this._removeDescribedBy(n),o.hiding=!0,i.stop(!0),this._hide(i,this.options.hide,function(){s._removeTooltip(t(this))}),n.removeData("ui-tooltip-open"),this._off(n,"mouseleave focusout keyup"),n[0]!==this.element[0]&&this._off(n,"remove"),this._off(this.document,"mousemove"),e&&"mouseleave"===e.type&&t.each(this.parents,function(e,i){t(i.element).attr("title",i.title),delete s.parents[e]}),o.closing=!0,this._trigger("close",e,{tooltip:i}),o.hiding||(o.closing=!1)),void 0):(n.removeData("ui-tooltip-open"),void 0)},_tooltip:function(e){var i=t("<div>").attr("role","tooltip"),s=t("<div>").appendTo(i),n=i.uniqueId().attr("id");return this._addClass(s,"ui-tooltip-content"),this._addClass(i,"ui-tooltip","ui-widget ui-widget-content"),i.appendTo(this._appendTo(e)),this.tooltips[n]={element:e,tooltip:i}},_find:function(t){var e=t.data("ui-tooltip-id");return e?this.tooltips[e]:null},_removeTooltip:function(t){t.remove(),delete this.tooltips[t.attr("id")]},_appendTo:function(t){var e=t.closest(".ui-front, dialog");return e.length||(e=this.document[0].body),e},_destroy:function(){var e=this;t.each(this.tooltips,function(i,s){var n=t.Event("blur"),o=s.element;n.target=n.currentTarget=o[0],e.close(n,!0),t("#"+i).remove(),o.data("ui-tooltip-title")&&(o.attr("title")||o.attr("title",o.data("ui-tooltip-title")),o.removeData("ui-tooltip-title"))}),this.liveRegion.remove()}}),t.uiBackCompat!==!1&&t.widget("ui.tooltip",t.ui.tooltip,{options:{tooltipClass:null},_tooltip:function(){var t=this._superApply(arguments);return this.options.tooltipClass&&t.tooltip.addClass(this.options.tooltipClass),t}}),t.ui.tooltip});
\ No newline at end of file
diff --git a/static/js/script.js b/static/js/script.js
index f1d33c2caf..929881fb34 100644
--- a/static/js/script.js
+++ b/static/js/script.js
@@ -9,40 +9,6 @@
 var body;
 
 //helper functions
-function copyCode(elem){
-     if (document.getElementById(elem)) {
-         // create hidden text element, if it doesn't already exist
-         var targetId = "_hiddenCopyText_";
-             // must use a temporary form element for the selection and copy
-             target = document.getElementById(targetId);
-             if (!target) {
-                 var target = document.createElement("textarea");
-                 target.style.position = "absolute";
-                 target.style.left = "-9999px";
-                 target.style.top = "0";
-                 target.id = targetId;
-                 document.body.appendChild(target);
-             }
-             target.value = document.getElementById(elem).innerText;
-         // select the content
-         target.select();
-
-         // copy the selection
-         var succeed;
-         try {
-             succeed = document.execCommand("copy");
-         } catch(e) {
-             swal("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard.");
-             succeed = false;
-         }
-         if (succeed) swal("Copied to clipboard: ",elem);
-         return succeed;
-     } else {
-         swal("Oops!",elem + " not found when trying to copy code");
-         return false;
-     }
- }
-
 function booleanAttributeValue(element, attribute, defaultValue){
     // returns true if an attribute is present with no value
     // e.g. booleanAttributeValue(element, 'data-modal', false);
diff --git a/static/js/search.js b/static/js/search.js
index 2a4a03aff8..a76524b327 100644
--- a/static/js/search.js
+++ b/static/js/search.js
@@ -17,7 +17,7 @@
 
         for(var i = 1; i <= 10; i++){
             if(i > pages) break;
-            pageAnchors += '<a class="bing-page-anchor" href="/docs/search/?q='+searchTerm+'&page='+i+'">';
+            pageAnchors += '<a class="bing-page-anchor" href="/search/?q='+searchTerm+'&page='+i+'">';
             pageAnchors += (currentPage == i) ? '<b>'+i+'</b>' : i;
             pageAnchors += '</a>';
         }
diff --git a/themes/docsy b/themes/docsy
index 5d5e6402c9..0f6717470e 160000
--- a/themes/docsy
+++ b/themes/docsy
@@ -1 +1 @@
-Subproject commit 5d5e6402c901492f325af4117adbd151bf869c52
+Subproject commit 0f6717470e74b274e9f554a5ebf2465f2123d6a9